Eszett and IDNAv2 vs IDNA2008

[Andrew Sullivan]

`On Thu, Mar 12, 2009 at 09:49:11PM -0700, Erik van der Poel wrote:

> I suppose DNAME would work too. I'm under the impression that DNAME is
> newer than CNAME, and that CNAME therefore has better support. 

If the client does not support DNAME, then the server synthesizes a
CNAME and delivers that, so that DNAME-oblivious clients don't see
DNAME answers.  DNAME is indeed newer than CNAME, since CNAME is
defined in STD 13.  There are things wrong with DNAME for this
purpose, but the availability of support isn't it.  (The Microsoft DNS
servers are, from my understanding, admittedly awkward to use with DNAME.)

> the DNS system and find their way into HTML files, where they would
> cause interoperability problems, as I have explained so many times.
> (MSIE7 does not let users click through links containing xn-- names
> that cannot be the result of an IDNA2003 transformation.) 

What that really means, however, is that MSIE7 is stuck at IDNA2003,
full stop.  We have three choices, therefore:

1.  Do nothing, and live with IDNA2003 forever.  If we thought this
was an option, we'd not have chartered the new work, I think.

2.  Adopt a new prefix.  This is hardly better than (1), because MSIE7
users will now see the A-label form all the time.  I don't really see
why that's supposed to be better.

3.  Decide that MSIE7 loses.  I think this is the right answer.
IDNA-using web sites who want to use IDNA2008 and support MSIE7 will
basically either have to detect MSIE7 and present links differently to
them, detect MSIE7 and warn such users, "Your browser won't be able to
follow some links on this page," or just accept that MSIE7 users get a
less good experience.  Users who are interested in a good IDNA2008
experience will start using another browser, and sites who really want
the IDNA2008 new features (and we keep being assured people _do_ want
them) will warn their users not to use MSIE7.

Note that it's exactly problems like MSIE7 deciding not to follow some
links "for the user's own good" that makes me oppose the earlier
language we had in the IDNA2008 drafts permitting more or less
arbitrary client-side mapping: I don't think
application-by-application decisions of this sort are safe, desirable,
or even wise.  Instead they're a recipe for mistakes, user confusion,
and bad behaviour.

A

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