Re: [art] Refreshed draft-bray-unichars

["Manger, James" <[e-mail]>]

Thanks for trying to write a short RFC to simplify future RFCs, Tim. But https://www.ietf.org/archive/id/draft-bray-unichars-02.html fails its main purpose.

The one and only “must” is in §3.1. This “Unicode code points” section says:

  1.  “it has been adopted by JSON [RFC8259]”
  2.  “it cannot be serialized into legal UTF-8”
  3.  “Implementors must be prepared to deal with these sorts of problematic code points.”
But RFC8259 says:

  1.  “MUST be encoded using UTF-8”

Implementers cannot “deal with” stuff that “must be UTF-8” and “cannot be UTF-8”.
And the main point is not to burden future RFCs that have text fields with this historical dilemma.

I suggest dropping §3.1. “Unicode Code Points”. If you really want to define unicode-code-points, move it to an appendix, drop the JSON references, and highlight that it cannot be encoded in UTF-8 so is not suitable for text.

draft-bormann-dispatch-modern-network-unicode<https://www.ietf.org/archive/id/draft-bormann-dispatch-modern-network-unicode-03.html> looks like a better approach.
(it’s uchar production should exclude each plane’s xFFFE xFFFF non-chars since it excludes FFFE FFFF)


Other comments on draft-bray-unichars-02:

Not sure how “xml-chars” is useful. What sort of new RFCs would use “xml-chars” since they shouldn’t be redefining XML.

How about renaming “useful-assignables” as “unicode-chars”? It is the item we most want new RFCs to use so give it the nicest name.

Typo in all the “repeat per plane” ABNF bits.
WRONG  %x1000-1FFFD
RIGHT %x10000-1FFFD

--
James Manger


General