Re: [Idna-update] [Ext] FWD: Expiration impending: <draft-klensin-idna-rfc5891bis-01.txt>

[Asmus Freytag <[e-mail]>]

On 3/5/2018 1:23 PM, Suzanne Woolf wrote:
> Patrik,
>
> That was before my time on the IAB, sorry.
>
> But as it happens, I’m looking at an update to the IAB statement, so 
> have been pondering this very question. Do you think that 
> https://www.ietf.org/id/draft-klensin-idna-5892upd-unicode70-05.txt covers 
> the options reasonably well?

There is one statement here (and it's the premise of the whole affair) 
that is actually not 100% correct:

    Unicode 7.0.0 introduces the new code point U+08A1, ARABIC LETTER BEH
    WITH HAMZA ABOVE.  As can be deduced from the name, it is/*visually identical*/  to the glyph that can be formed from a combining sequence
    consisting of the code point for ARABIC LETTER BEH (U+0628) and the
    code point for Combining Hamza Above (U+0654).

(/*emphasis */added)

In fact, in many (all?) fonts that do support this code point, there's a 
noticeable difference between the combining sequence and the precomposed 
character. Here is one example:



similar systematic differences, although slight, obtain in many cases of 
combining sequences that /appear at first to be identical/ to 
precomposed Latin code points without being normalized:


where the right side is 'o' + 0x0337   [this case has been in Unicode 
since IDNA2008 first started]

Obviously much depends on the font, but because the entire premise rests 
on the *absolute identical appearance* of the sequences to the code 
points in question, I think we need to take a step back here.

Perhaps, one difference since the time this was first raised is that the 
code point 08A1 is now supported in a number of fonts, which may not 
have been the case immediately after Unicode 7.0 was released and it may 
not have been apparent that the precomposed code point would be treated 
differently from a sequence that was so apparently made up from the same 
elements.

To put this into perspective: there are thousands of PVALID Chinese 
characters for which the distinctions are equally subtle, just saying. 
(And no, for the most part, they are not variants of each other). Yet 
this didn't stop IDNA from tracking many thousands of Han additions over 
the years.

I think the best thing for the IAB is to find a way to climb down from 
seeing this as an earth-shattering crisis and accepting such near 
similarities as unavoidable consequences of trying to implement mnemonic 
identifiers that are readable to the world population.

The right way forward is simply not to leap to the assumption that 
action on the protocol level is called for for these cases, but that 
they are in some ways the end points of a continuum that includes cases 
like .com/.corn and apple.com/app1e.com.

The right way forward also means that one cannot blithely assume that 
identifiers are always made from a small set of very distinct shapes 
(like most of the Latin alphabet) and to perhaps find ways to mitigate 
the worst cases.

A./


>
>
> Thanks,
> Suzanne
> ("member of, not speaking for, the IAB")
>
>> On Mar 5, 2018, at 3:22 PM, Patrik Fältström <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> I did send the question, and gave choices, to IAB on July 9 2014.
>>
>> Message-Id: <[e-mail] 
>> <mailto:[e-mail]>>
>>
>> Since then the question has been stalled waiting for consensus on how 
>> to move forward.
>>
>>   Patrik
>>
>> On 5 Mar 2018, at 21:02, Andrew Sullivan wrote:
>>
>>> Does the IAB know that, and have an opinion?
>>>
>>> A
>>>
>>> -- 
>>> Please excuse my clumbsy thums
>>>
>>>
>>>
>>> ----------
>>> On March 5, 2018 14:38:48 Patrik Fältström <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>>
>>>> On 5 Mar 2018, at 20:15, Kim Davies wrote:
>>>>
>>>>> Quoting John C Klensin on Monday March 05, 2018:
>>>>>
>>>>>> Given that there has been no discussion of this draft in the
>>>>>> last few months, that there seems to be no interest in it in the
>>>>>> IESG (although we have not pressed hard on it specifically), and
>>>>>> that the possibly-complementary
>>>>>> draft-freytag-troublesome-characters draft has already expired,
>>>>>> I'm just going to let this expire unless someone gives me a good
>>>>>> reason why not in the next few minutes (if a revision is not
>>>>>> posted today, the draft will expire because, without special
>>>>>> permission, nothing can be posted between tomorrow and the start
>>>>>> of IETF).
>>>>>>
>>>>>> I hope no one interprets this as complete lack of interest in
>>>>>> pursuing IDN issues, or even clarification of the IDNA
>>>>>> standards, in the IETF.
>>>>>
>>>>>
>>>>> With the expiry of these efforts, I am concerned more generally 
>>>>> that the standing IAB guidance in
>>>>> https://www.iab.org/documents/correspondence-reports-documents/2015-2/iab-statement-on-identifiers-and-unicode-7-0-0/
>>>>> has kept the pre-computed IDNA tables published at IANA downgraded 
>>>>> to Unicode 6.3.0 for a number of years. It seems appropriate to 
>>>>> revisit publishing tables against contemporary Unicode editions if 
>>>>> there is no active work on publishing clarifying RFCs in this regard.
>>>>
>>>> Speaking as the by IAB appointed expert that do approve new tables, 
>>>> I simply can not unless there are some guidance and agreement in 
>>>> the IETF on how to move forward.
>>>>
>>>> The few people involved that spend time on these issues makes it 
>>>> hard to draw conclusions on "the right path forward". This given 
>>>> the situation we are in, as described by John.
>>>>
>>>>   Patrik
>>>>
>>>>
>>>>
>>>> ----------
>>>> _______________________________________________
>>>> IDNA-UPDATE mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/idna-update
>>>>
>> _______________________________________________
>> IDNA-UPDATE mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/idna-update
>
>
>
> _______________________________________________
> IDNA-UPDATE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idna-update