<html>
<body>
Dear Andrew,<br>
there are browsers brands enough on the market, and some in open source,
for the users to be able to use the ones supporting their usage mode. Do
not forget that <b>IDNA is not for everyone, but for those longing for
it</b>. For the time being IDNA is "xn--". There are
money, interest, etc. enough in specifiying and supporting
"x.--" or "..--", for the browsers not to be an
issue. The only issue is the delay of this WG/IDNABIS in revising
"xn--" since most de facto accepted "xn--" as the
Engish ASCII default proposition. <br>
People who do not want to support the users' usage are of no interest for
anyone in a network, how big they can be. <br>
jfc<br><br>
At 14:43 13/03/2009, Andrew Sullivan wrote:<br>
<blockquote type=cite class=cite cite="">`On Thu, Mar 12, 2009 at
09:49:11PM -0700, Erik van der Poel wrote:<br><br>
> I suppose DNAME would work too. I'm under the impression that DNAME
is<br>
> newer than CNAME, and that CNAME therefore has better support.
<br><br>
If the client does not support DNAME, then the server synthesizes a<br>
CNAME and delivers that, so that DNAME-oblivious clients don't see<br>
DNAME answers. DNAME is indeed newer than CNAME, since CNAME
is<br>
defined in STD 13. There are things wrong with DNAME for this<br>
purpose, but the availability of support isn't it. (The Microsoft
DNS<br>
servers are, from my understanding, admittedly awkward to use with
DNAME.)<br><br>
> the DNS system and find their way into HTML files, where they
would<br>
> cause interoperability problems, as I have explained so many
times.<br>
> (MSIE7 does not let users click through links containing xn--
names<br>
> that cannot be the result of an IDNA2003 transformation.) <br><br>
What that really means, however, is that MSIE7 is stuck at IDNA2003,<br>
full stop. We have three choices, therefore:<br><br>
1. Do nothing, and live with IDNA2003 forever. If we thought
this<br>
was an option, we'd not have chartered the new work, I think.<br><br>
2. Adopt a new prefix. This is hardly better than (1),
because MSIE7<br>
users will now see the A-label form all the time. I don't really
see<br>
why that's supposed to be better.<br><br>
3. Decide that MSIE7 loses. I think this is the right
answer.<br>
IDNA-using web sites who want to use IDNA2008 and support MSIE7 will<br>
basically either have to detect MSIE7 and present links differently
to<br>
them, detect MSIE7 and warn such users, "Your browser won't be able
to<br>
follow some links on this page," or just accept that MSIE7 users get
a<br>
less good experience. Users who are interested in a good
IDNA2008<br>
experience will start using another browser, and sites who really
want<br>
the IDNA2008 new features (and we keep being assured people _do_
want<br>
them) will warn their users not to use MSIE7.<br><br>
Note that it's exactly problems like MSIE7 deciding not to follow
some<br>
links "for the user's own good" that makes me oppose the
earlier<br>
language we had in the IDNA2008 drafts permitting more or less<br>
arbitrary client-side mapping: I don't think<br>
application-by-application decisions of this sort are safe,
desirable,<br>
or even wise. Instead they're a recipe for mistakes, user
confusion,<br>
and bad behaviour.<br><br>
A<br><br>
-- <br>
Andrew Sullivan<br>
ajs@shinkuro.com<br>
Shinkuro, Inc.<br>
_______________________________________________<br>
Idna-update mailing list<br>
Idna-update@alvestrand.no<br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" eudora="autourl">
http://www.alvestrand.no/mailman/listinfo/idna-update</a></blockquote>
</body>
</html>