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

[Rob Sayre <[e-mail]>]

On Tue, Sep 19, 2023 at 9:37 PM Carsten Bormann <[e-mail]> wrote:

> On 19. Sep 2023, at 23:30, Rob Sayre <[e-mail]> wrote:
> >
> > It depends on whether the document is prescriptive or descriptive.
>
> As we have heard, it is neither.
> It is intended as a reference document for defining new protocols.
> It fails at doing this properly.
>

I think what's in it now is pretty good, if incomplete and unrealistic in
omitting "%x0-10FFFF".



> > I thought "unicode-code-points = %x0-10FFFF" was pretty sharp, because
> that is the limit for IETF protocols. It's what JSON does.
>
> (ECMA’s view of JSON.  IETF has made clear that usage of code points that
> are not valid for Unicode characters generates unpredictable results, which
> is, from a protocol design or RFC 9431 point of view, indistinguishable
> from not valid.)
>

No... this is in both documents. They are meant to specify the same "JSON
text". I understand that you want something different, but it didn't happen.


> > It's infuriating Unicode,
>
> (It’s not Unicode at all.)
>

It's code points, as in ECMA 404 and the errata report that prompted this
document.


> > but the IETF can't legislate it away. It can only make better things,
> like I-JSON or CBOR.
>
> Right.  So why even discuss this item of toxic waste in a document that is
> intended to guide development of new protocols?
>

Well, it depends on whether you need to interoperate with the Web. This can
mean not only detecting the "toxic waste" code points, but accepting them.
That seems straightforward to me. I think the other protocols and subsets
are a better idea in other situations.

thanks,
Rob