I am far from as sanguine as you are about this change. If we could pull a magic switch that converted everyone (registries and all lookup programs) from 2003 to 2008 at once, these 4 characters wouldn't be a problem. Sadly, we are going to have a mixture for the indefinite future, and having an IRI go to two different locations depending on the particular program -- or version or program -- in use: that is a very significant interoperability and security problem.<br>
<br clear="all">Along the lines of what you are talking about, I think one way to solve
the problem is to have a requirement on registries in the protocol,
that whenever two strings differ only by these characters, that they
must either bundle or block.<br>
<br>
Mark<br>
<br><br><div class="gmail_quote">On Tue, Dec 23, 2008 at 12:00, Shawn Steele <span dir="ltr"><<a href="mailto:Shawn.Steele@microsoft.com">Shawn.Steele@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Erik said:<br>
<br>
> Absolutely. However, the A-labels corresponding to U-labels that<br>
> contain eszett, final sigma, ZWJ and ZWNJ do not currently work in<br>
> IE7. We just have to pray that Microsoft will fix that, and that<br>
> users' copies of IE7 will be updated. If so, we don't need another<br>
> prefix.<br>
<br>
I'm not sure that prayer will be as effective as sending someone at Microsoft an email (like me) :) I would hope that I don't seem unapproachable.<br>
<br>
Of course, IDNA2003 currently prohibits eszett, etc., so at this point there's nothing to "fix".<br>
<br>
It isn't clear to me (I haven't been paying a lot of attention in the last few weeks) that the backward compatibility issues have been resolved. This is a "breaking" change for people who think they've registered a name with an eszett already. A link with ß will change to ss, and changing that will break that link.<br>
<br>
In practice I cannot imagine myself registering an eszett form of a domain name without also registering the ss form of the name, regardless of spelling conventions. If nothing else there are enough IDNA2003 implementation in the wild that that'd be the only way I (as a web site owner) could guarantee that people would hit my site as intended.<br>
<br>
From a browser perspective, it seems that if I encountered an eszett I'd have to use the 2008 rules, and if those don't succeed, fall back to the 2003 rules.<br>
<br>
Just to randomize the conversation: I can see where ß and ss can differ linguistically, but in practice I can't see how they can resolve to different domains. <CrazyIdea>So it seems like I (as a domain owner) need the distinction primarily for display, not for resolution. In other words: how about allowing PTR records or maybe a special CNAME or something that resolves a name to its preferred display form, undoing any mappings that were encoded?</CrazyIdea><br>
<br>
- Shawn<br>
<br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</blockquote></div><br>