[Last-Call] Re: Last Call: <draft-bray-unichars-10.txt> (Unicode Character Repertoire Subsets): W3C I18N Review

[Tim Bray <tbray@xxxxxxxxxxxxxx>]

Thanks for that, Addison, and to the others whose input you are forwarding, assuming that’s not all you.  A couple of the points have branched off into separate threads but I’ll consolidate other reactions here.

On Feb 10, 2025 at 1:08:49 PM, Addison Phillips <addisoni18n@xxxxxxxxx> wrote:

#1980: Quibbles about characters and code points

https://datatracker.ietf.org/doc/draft-bray-unichars/

There are 1,114,112 code points; as of Unicode 15.1 (2023), fewer
than 150,000 have been assigned to characters. It is difficult to
specify that unassigned code points should be avoided because they
regularly become assigned when new characters are added to Unicode.

Section 2 of the I-D provides a description of characters and code points for local use in the document. The above quoted paragraph might be improved by:

• mention the hex size of the code point space (0x10FFFF or 0x10FFFD if you prefer) next to or instead of the weird decimal number.

Or perhaps 17⨉2¹⁶.

• the phrase "It is difficult to specify that unassigned code points should be avoided" understates the problem. We explicitly do not want to forbid unassigned code points that later do become assigned.

Perhaps “Since unassigned code points regularly become become assigned when new characters are added to Unicode, it is usually not a good practice to specify that unassigned code points should be avoided”?

[Generally the opinions I’m expressing here are weakly helpful, feel free to disagree/improve or suggest doing nothing.]

#1981: "Transformation Formats" might be clearer as "character encoding"?

Unicode describes a variety of "transformation formats", ways to
marshal code points into byte sequences.

Section 2.1 is labelled "Transformation Formats" and uses that term instead of the more familiar "character encoding" or "character encoding form". It is the case that "UTF" stands for "Unicode Transformation Format" and is part of the name of Unicode's character encodings, but that seems like a good footnote rather than something to be used in general.

I have the impression that “transformation formats” is the standard idiomatic Unicode terminology, would prefer to stay with that unless someone else wants to jump in here.

#1982: C1 controls, Unicode line endings

Section 2.2.2 introduces control codes and talks specifically about the C0 controls. The C1 controls are mentioned en passant in section 3:

Hmm, in 2.2.2.2 we could expand the first sentence too say "Aside from the useful controls, both the C0 and C1 control coes codes are mostly obsolete and…” 

Tbh this one doesn’t trouble me much. Other opinions?

Also, the poorly supported U+2028/2029 line endings aren't mentioned.

I think that’d be a distraction in the context of this document. There’s lots of smelly stuff in there.

replacing problematic code points, ideally with "�" (U+FFFD,
REPLACEMENT CHARACTER), although some popular software platforms,
notably Java, use "?".

This is probably incorrect.

Discussion so far makes me want to simply end this sentence at the comma before “although”. 

#1984: Security consideration statement perhaps too bold?

Note that the Unicode-character subsets specified in this document
include a successively-decreasing number of problematic code points,
and thus should be less and less susceptible to vulnerabilities. The
Section 4.3 subset, "Unicode Assignables", excludes all of them.

Saying that the Section 4.3 subset excludes "all of them" suggests that no exploits remain. The preceding paragraph mentions RFC8264's security considerations applies here also, and that document is somewhat thorough. Since homographs cannot be eliminated, maybe this should say something slightly different? Perhaps:

Note that the Unicode-character subsets specified in this document
successively exclude an increasing number of problematic code points,
and thus should be less and less susceptible to many of these exploits.
The Section 4.3 subset, "Unicode Assignables", excludes all of the
functionally problematic code points.

OK, but I’d probably say “these” instead of “the functionally”.

I should mention, however, that UTS#55 probably should be mentioned/considered. "Trojan Source" attacks using bidi formatting characters can affect protocol text and document formats. This is probably a gap that needs mentioning. Mentioning homographs and confusables is probably worth a couple of words?

Agreed on mentioning UTF#55. But I really don’t want to start going down the slippery slope of all the deceive-the-eye attack flavors in this doc. The referenced docs (including #55) say the right things at the appropriate length.

• T

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx