I have had a number of things come up, and can't pay attention to IDNA
this week, but I don't think this direction is positive at all. <br><br>I had thought that we were making some progress towards having a uniform single mapping handling at least case and width, which users really want (Cf the CJK presentation at the latest IETF meeting). Mapping is not just a UI issue. Having arbitrary mappings, subject to "application context" just makes a messy situation worse: if program 1 sees href="<span class="changedspan"><a title="http://ÖBB.at" rel="nofollow" href="http://%c3%96bb.at/"><span>http://ÖBB.at</span></a>" and goes to </span><span class="changedspan"> <a title="http://öbb.at" rel="nofollow" href="http://%c3%b6bb.at/"><span>
http://öbb.at</span></a>, but program 2 goes to the different </span><a><span class="changedspan"></span></a><a href="http://oebb.at/"><span>http://oebb.at</span></a>,
we have a horrible interoperability problem. <br><br>In HTML5, for
example, href="<span class="changedspan"><a title="http://ÖBB.at" rel="nofollow" href="http://%c3%96bb.at/"><span>http://ÖBB.at</span></a>" is valid and interpreted according to IDNA2003. Because of that, there is no ambiguity in IDNA2003, it goes to </span><span class="changedspan"></span><span class="changedspan"> <a title="http://öbb.at" rel="nofollow" href="http://%c3%b6bb.at/"><span>
http://öbb.at</span></a>. End of story, no ambiguity.</span><br><br>Luckily, HTML5 is designed around
compatibility, and I strongly suspect it would contine to support
IDNA2003 mappings (cc'ing Ian to get his take) under IDNA2003. It would have to glue
these together in some fashion with IDNA2008 support (such as by using <a href="http://www.unicode.org/reports/tr46">http://www.unicode.org/reports/tr46</a>). But communicating with a different program that takes a different tack on resolving the domain name would cause a severe interoperability problem. Why on earth do people think this kind of fragmentation of the Internet is a good thing?<br>
<br>Re some thoughts on compatibility:<br><a href="http://www.alvestrand.no/pipermail/idna-update/2009-April/004400.html">http://www.alvestrand.no/pipermail/idna-update/2009-April/004400.html</a><br><br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Tue, Apr 14, 2009 at 07:16, Vint Cerf <span dir="ltr"><<a href="mailto:vint@google.com">vint@google.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;">
This exchanges has been very helpful in outlining what I think are two views and maybe even a compromise position for the WG to consider.<br><br>Plainly we have agreed that mapping should be available to ease the introduction of IDNA2008. We have also agreed that the canonical forms of IDN labels (U-label and A-label that are equivalent under the punycode and reverse-punycode mappings) are extremely valuable fixed points in the protocol.<br>
<br>The dialogue among Paul Hoffman, Andrew Sullivan, Pete Resnick and Patrik Faltstrom suggests to me that a definition of Mapping (prior to lookup) should be undertaken by the WG but that its use might be determined by application context. If that compromise is adopted, the Mapping would be recommended in cases where IDNA2003 compatibility is desired/needed but that mapping on lookup is not absolutely required under all circumstances. <br>
<br>If we take that path, it will be very helpful to have not only the definition of the mapping but also advice about conditions underwhich it seems strongly advisable to apply. <br><font color="#888888"><br>vint</font><div>
<div></div><div class="h5"><br><br><div><span class="gmail_quote">On 4/14/09, <b class="gmail_sendername">Andrew Sullivan</b> <<a href="mailto:ajs@shinkuro.com" target="_blank">ajs@shinkuro.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, Apr 13, 2009 at 09:03:48PM -0500, Pete Resnick wrote:<br> <br> > IDNA 2003 can be found in [MAPPING]." What I think is not fine is for<br> > the protocol document to say, "You MUST map user input with<br>
> [MAPPING]." That will codify a particular version of [MAPPING] that<br> > may not be suitable for some cases and makes one particular user<br> > input method a requirement for protocol conformance. That I don't<br>
> like.<br> <br> <br>Pete's outline was so close to what I'd say that any additional<br> comment from me would be gilding the lily. So, what he said.<br> <br><br> a<br> <br> --<br> Andrew Sullivan<br> <a href="mailto:ajs@shinkuro.com" target="_blank">ajs@shinkuro.com</a><br>
Shinkuro, Inc.<br> _______________________________________________<br> <br>Idna-update mailing list<br> <a href="mailto:Idna-update@alvestrand.no" target="_blank">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>
</div></div><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>
<br></blockquote></div><br>