Re: [Idna-update] [I18nrp] Last Call: <draft-faltstrom-unicode11-05.txt> (IDNA2008 and Unicode 11.0.0) to Informational RFC

["Asmus Freytag (c)" <[e-mail]>]

On 12/6/2018 9:39 PM, John C Klensin wrote:
> Part of the problem with the IDNA RFCs is that the requirement
> for registry conservatism and responsibility is too scattered
> through several documents to come across as important as I think
> we all believe it is.   draft-klensin-idna-rfc5891bis (now
> expired, but waiting in the wings) was intended to address that
> issue.  I haven't looked at the text for a while but strongly
> suspect it does not identify and stress labels being
> "re-enterable" and "retypable" as you suggest.   It should.  If
> you don't mind taking a look at it, I'd appreciate recommended
> text.   Or, if that isn't convenient, I'll try to remember to
> say something when I next open the document.

To "typable", you might add "processable" and "renderable", not to 
mention "human-readable". (Where multiple languages/scripts are 
supported, "typable" should obviously mean"typable by a native user of 
that language/script").

Allowing certain specialized or historical forms that are not part of 
the modern orthographic repertoire would allow characters that are 
unlikely to be supported by keyboards (or even fonts). (Some such 
characters are effectively not recognized by modern readers, or simply 
mistaken for more familiar characters).

Allowing "do not use" sequences renders labels not processable by 
processes that do expect data to not contain effectively deprecated 
content.  (They are also structurally unsound, see next).

Allowing structurally unsound sequences for any of the fifteen or so 
complex scripts risks data not being renderable, as neither layout 
systems or fonts are (universally) expecting to deal with them (or do it 
differently in unpredictable ways). T

Allowing arbitrary sequences can lead to strings that human readers are 
not prepared to recognize because they violate deep-seated assumption of 
what is possible. Linearly progressing, non-connecting scripts tend to 
not have that issue; ASCII certainly doesn't, but already with Latin 
combining marks you enter territory where fully random sequences can't 
be supported.

Then you get into the issue of substitutable code points/labels that 
should not be simultaneously allowed (aka "blocked" variants) -- the 
other type of variants ("allocatable") is more of a usability issue, 
which for some scripts can be critical but is not strictly required 
under the heading of "Conservatism".

Allowing two labels that even reasonably observant readers will 
substitute for one another, because different abstract text elements in 
Unicode may have identical (or very near identical) appearance when 
presented in typical user interfaces, adds no value, only security 
risks. (Yes this is a subset of the wider issue of labels that are 
merely similar, but that's not an excuse to take well-known an 
unambiguous cases off the table at the policy level).

Spelling out these considerations would go beyond what is currently 
scattered through the IDNA RFCs, but would be a first step to putting 
the Registries on notice what their responsibility actually entails.

Now that we have the Root Zone LGR giving practical examples (and the 
emerging reference LGRs doing the same for the second level), there's 
less excuse for registries not doing the right thing - good approximate 
solutions exist.

A./