Re: [I18ndir] [art] Fwd: New Version Notification for draft-bray-unichars-04.txt

[Rob Sayre <[e-mail]>]

On Tue, Sep 19, 2023 at 2:09 PM Asmus Freytag <[e-mail]> wrote:

> Unicode, in other words, has to be universal covering ALL possible uses of
> a "string". The same is not true for a protocol that defines a record with
> data fields. Those fields don't need to be able to accommodate ill-formed
> data.
>

It depends on whether the document is prescriptive or descriptive. I agree
that a prescriptive document should require well-formed Unicode. This
document (wisely) no longer uses RFC 2119 terms. So, it is descriptive.
JSON has always allowed ill-formed Unicode data, and it will never change.
Usually, these come through in escape sequences transmitted via well-formed
UTF-8, or they are only used locally in JavaScript.

There are other ways to look at the problem. Maybe the tension between
making good recommendations vs inaccurate descriptions of actual internet
traffic. Or, Postel's Law, etc.

I thought "unicode-code-points = %x0-10FFFF" was pretty sharp, because that
is the limit for IETF protocols. It's what JSON does. It's infuriating
Unicode, but the IETF can't legislate it away. It can only make better
things, like I-JSON or CBOR.

thanks,
Rob