Re: [I18ndir] draft-faltstrom-unicode12

[Asmus Freytag <[e-mail]>]

On 6/21/2019 7:36 PM, John C Klensin wrote:
>
> --On Saturday, June 22, 2019 03:28 +0200 Patrik Fältström
> <[e-mail]> wrote:
>
>> On 22 Jun 2019, at 2:39, John C Klensin wrote:
>>
>>> So, while we can sit on that until Alexey finishes his
>>> writeup if you (Pete, Peter, Alexey, directorate
>>> participants) like, it will come back to get us sooner or
>>> later.  And this is another reason why these documents are
>>> fairly seriously intertwined.
>> 1. draft-faltstrom-unicode12 have two main issues:
>>
>> 1.1. It does not address Unicode 12.1 (easy fix)
>>
>> 1.2. It suggests a resolution to the divergence between
>> Unicode and IETF due to incompatible changes in Unicode that
>> makes IETF follow the Unicode Standard by allowing derived
>> property values to change (better to let 5892 rules be fixed).
>>
>> 2. draft-klensin-idna-unicode-review do suggest the derived
>> property value stay fixed, which implies 5892 algorithm must
>> be updated in the case Unicode do changes in the future like
>> has happened before as described in draft-faltstrom-unicode12.

If some character buried in some archaic script changes from punctuation
to letter and would become PVALID, then, at first glance, I'd say who cares
one way or another.

For modern use scripts, the code point with changed status could present
a spoofing opportunity that would now need to be addressed, even if it
doesn't affect registered labels. (Remote, but a possibility).

It could also be a code point in an emerging script, where disallowing it
could seriously cripple support for some user community. In that case,
the reason for the property change may have been precisely to recognize
that it is a member of an alphabet (part of an orthography, whatever).

Can't see the value of mandating a "one-size-fits-all" approach here.

The inverse case (new value: DISALLOWED) is clearer about the need for
always grandfathering via an exception.

For new code points, I can see some modern-use scripts where new code
points can cause unexpected issues that potentially would have a
practical impact. The vast majority of additions are in scripts that,
other than vanity labels, would not be expected to see significant use,
therefore, I'd say who cares one way or another to get the fine details
"perfect". (And the same goes for extensions to Chinese: at this point,
they are practically all in the long tail. . . and have no use other than
for spoofing a more frequent code point.)

>>
>> Because [1.2] and [2] above are incompatible with each other,
>> text in them should and I would say MUST match each other.
>>
>> What we have as a fact is that IETF have already accepted
>> actions based on draft-faltstrom-unicode12 until Unicode 12.0
>> at least so applying draft-klensin-idna-unicode-review to the
>> review process can not happen for earlier versions.
> In case it wasn't clear, we are in complete agreement.
>
> Thanks,
>     john
>
>