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

["Patrik Fältström " <[e-mail]>]

On 4 Dec 2018, at 2:33, Asmus Freytag wrote:

> What I see Patrik's document reflecting is the inherent limitation of the normalization algorithm: it folds alternate encodings of the same abstract entity, but does not purport to be a universal glyph folding.

This is why I continue to believe IETF must investigate _every_ individual code point where decisions could be made to include exceptions in 5892.

> Given that the set of PVALID code points has long included both code points and sequences that have identical glyphs, it was surprising that the process was stopped for something that was merely a set of close lookalikes.

I do not understand what you mean by "sequence" because a sequence can never be PVALID, only individual code points. If you imply "sequence of code points, each having derived property value PVALID" then I understand.

The reason is simple, pure coincidence. If I exaggerate. And I am sure we will see more things like these.

And for IETF it does not matter as we have to evaluate code points manually. Most of these I catch when I evaluate differences when caluclating derived property values from new versions of unicode. But sometimes the catch is when people just look at the newly added/changed code points.

Detail: no incompatible changes for Unicode 12.0.0 from Unicode 11.0.0, at least not at the current beta of Unicode 12.0.0.

> Perhaps it might be possible to edit the text of Section 4.1 to make sure that the "repertoire" mentioned is to be understood as the repertoire for "any particular zone" as opposed to something like the set of PVALID code points.

Please send text :-)

Yes, the goal of this document is to emphasize what have already been said many many times, that it is not recommended to allow all PVALID code points (in any combination) in the registration policy in _any_ zone. Instead a subset is to be chosen using the conservatism principle explained by IAB, by SSAC and in IDNA2008.

   Patrik