Eszett and IDNAv2 vs IDNA2008

[JFC Morfin]

Dear Andrew,
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 IDNA is not for everyone, but for 
those longing for it. 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.
People who do not want to support the users' usage are of no interest 
for anyone in a network, how big they can be.
jfc

At 14:43 13/03/2009, Andrew Sullivan wrote:
>`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.
>_______________________________________________
>Idna-update mailing list
>Idna-update at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/idna-update
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090313/e342f674/attachment.htm