Eszett and IDNAv2 vs IDNA2008

[Andrew Sullivan]

On Sat, Mar 14, 2009 at 09:28:49PM -0700, Erik van der Poel wrote:
> If users' copies of MSIE were automatically updated so that users
> could click through xn-- links containing Eszett or newly assigned
> characters, I would probably be less concerned about this, though some
> users may have unwisely turned off automatic updates. Other apps may
> also have problems with such xn-- names, so I'm still uncomfortable.

But really, there are only two possible answers here:

1.  Apps that currently only support IDNA2003 will be updated to
support something other than IDNA2003, and then they'll be able to use
the new features.

2.  Apps that currently only support IDNA2003 will _not_ be updated to
support something other than IDNA2003.

What you seem to be saying is that we need to do something for (2),
because of the potential difficulty users with such applications may
face.  I argue that, if we have to do something, the _only_ thing we
ought to do is signal a protocol change.  The protocol change is
signalled by the change in the prefix.  Full stop.  

But we've been over the ground of "new prefix", and the answer was
no.  We decided that some time ago, during chartering, and
specifically said that if we needed to revisit that assumption we'd
stop work and go back to figuring out the charter.  You, however, seem
to want it both ways:
 
> I'm not suggesting a new prefix for /all/ labels. I'm suggesting a new
> prefix only for labels containing the problematic characters: Eszett,
> Final Sigma, IDNA2003 "map to nothing" characters (including
> ZWJ/ZWNJ), the Unicode 5.1 lower-case counterparts of characters that
> only had an upper-case in Unicode 3.2, and the new normalized versions
> of the five CJK characters that had their normalizations changed after
> Unicode 3.2:

This answer makes my teeth hurt.  What you're suggesting is that
IDNAng (just to give us a generic term that does not pick out any
particular strategy) needs to be a bag on the side of the bag on the
side that IDNA2003 is to the DNS.  I'm not sure I even see what
problem we are now trying to solve with these epicycles.

> Note that xd-- labels would not be generated by clients that are
> looking up Unicode labels. They would convert Unicode labels to xn--
> labels before looking them up.

I think if you have a real, complete proposal, you need to write an
I-D that lays it all out.  I think I no longer understand what the
problem is you're trying to solve, and I don't know what I am trading
away (aside from the obvious loss of consistency and what simplicity
remained in IDNA) if I take your solution instead of others.

> I'm a bit surprised that you've come to this conclusion. I would like
> to think that we are all in this business for the /users/. It is not
> the user's fault that they are using MSIE (though it is their fault if
> they turn off automatic updates).

I am in the business for users, but _all_ users: the future ones as
well as the current.  It seems to me that what you're doing is
granting pride of place to one browser according to the way it happens
to work today.  We've been down this road before with various
protocols (not least of which, by the way, is DNS).  I think that we
have to weigh the value of making things always work for those users
against the inconvenience and difficulty charged to other users of the
system.

> Many ordinary users stick with one browser. Very few users are aware
> of IDNA or browsers that have better support for IDNA.

Then by definition, they don't care about this.  Frankly, if a user
doesn't care about their IDNA experience, then I don't care whether
their IDNA experience is good, either.

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