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