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

Andrew Sullivan ajs at shinkuro.com
Tue Feb 22 16:04:42 CET 2011


On Tue, Feb 22, 2011 at 09:33:46AM +0100, Simon Josefsson wrote:
> 
> 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.

This is nonsense.  As others have pointed out, we do not and never had
an algorithm that produces stable output regardless of Unicode
version.  There is exactly one way to do that, and it is to peg the
entire system to a single version of Unicode.  We tried that in the
past, and it doesn't work, because users' systems change versions of
Unicode without the protocol being able to tell.

> 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.

No, they won't.  See John's message.

This degree of instability was absolutely, always, implicit in the
IDNA2008 approach.  If the Unicode consortium is going to continue to
issue changes to Unicode -- and it had better, since there are still
characters that need encoding, &c. -- then there will be differences
that can be experienced.  That's a feature, not a bug.

In this particular case especially, nobody ought ever to encounter the
character in question anyway.  The ability to treat this case
differently from (per impossibile) a category change for the character
"n" is actually one of the benefits of the WG's decision to treat
these matters case by case.

(All this said, I don't actually personally care one way or the other,
since software is obviously going to have to look at the table of
exceptions.  But for reasons of overhead, it seems to me clearly
better not to make that table bigger than it really needs to be.)

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.


More information about the Idna-update mailing list