I-D Action:draft-faltstrom-5892bis-02.txt

"Martin J. Dürst" duerst at it.aoyama.ac.jp
Tue Feb 22 12:06:41 CET 2011


Hello Simon,

On 2011/02/22 17:33, Simon Josefsson wrote:
> Andrew Sullivan<ajs at shinkuro.com>  writes:
>
>> On Mon, Feb 21, 2011 at 03:43:20PM -0800, Mark Davis ? wrote:
>>> The short-term issue is draft-faltstrom-5892bis-02.txt. I was asked to state
>>> why I think it is incorrect. It is because is no compelling reason to break
>>> stability of identifiers in IDNA for this one character. Instead, the
>>> character U+19DA NEW TAI LUE THAM DIGIT ONE should be added as PVALID in
>>> Section G.
>>
>> There's no compelling reason to add it either, though, given that
>> everyone seems to agree that the chances of it actually being anywhere
>> in the wild is almost certainly 0.  So why add an exception for a
>> corner case?
>
> To have an algorithm that produce stable output regardless of Unicode
> version it is used with.  If you don't see any merit in that goal, I
> understand why you don't see any compelling reasons for adding it.

Sorry, but it seems you are forgetting that we are discussing (a) one 
character that, if we go by the current draft-faltstrom-5892bis-02, 
would change from allowed to disallowed, but not (b) the two characters 
that change from disallowed to allowed, nor (c) the many, many more 
characters that change from unassigned to allowed.

Because of (c), it is not actually true that the algorithm produces 
stable output regardless of Unicode version, in particular not on the 
registration side. I understand that Mark is just concerned about (a) 
based on the principle "once an identifier character, always an 
identifier character", but from a security viewpoint, both (a) as well 
as (b) and (c) may cause problems.


> I don't understand what you mean here.  To me it will be a lot of work
> if we _don't_ add the exception -- applications need a mapping layer to
> deal with the newly introduced backwards incompatibility in IDNA2008.

Can you be more specific? Applications just get updated. A newer version 
of the application will allow more characters ((b) and (c) above). But 
you can't go back and fix non-updated applications (other than by 
updating them). And you don't want to prohibit the new characters just 
because some other application may not yet be updated. Some for (a).

If somebody had one of these characters, they will get into trouble, but 
then our common understanding is that currently no such data exists 
(other than if you create it just to prove a point), so nobody will get 
in trouble. Even if they did, I'm not sure a mapping layer would help, 
or how it would look. Maybe you can give some details.

I'm not saying that I couldn't be convinced that we better keep the 
character in (a) allowed, but I agree with Patrick that we indeed had 
this discussion earlier, and I don't think it's worth spending tons of 
time on a single character that we all assume is currently unused.

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst at it.aoyama.ac.jp


More information about the Idna-update mailing list