<p dir="ltr"><br>
2013. 8. 20. 오전 5:33에 "Anne van Kesteren" <<a href="mailto:annevk@annevk.nl">annevk@annevk.nl</a>>님이 작성:<br>
><br>
> On Mon, Aug 19, 2013 at 6:31 PM, Mark Davis ☕ <<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>> wrote:<br>
> > Rather than promoting different, arbitrary modifications of IDNA2003, I<br>
> > would recommend instead using the TR46 specification, which provides a<br>
> > migration path from IDNA2003 to IDNA2008. It is, with some small exceptions,<br>
> > compatible with IDNA2003.<br>
><br>
> Last I checked with implementers there was not much interest in that.</p>
<p dir="ltr">Chrome is interested. It is very long overdue.<br></p>
<p dir="ltr">> And to be clear, it's not different and arbitrary. The modifications<br>
> have been in place since IDNA2003 support landed in browsers. As<br>
> should have been clear to the original authors of IDNA2003 too. Nobody<br>
> is going to arbitrarily freeze their Unicode implementation.<br>
><br>
> (Aside: ToASCII in IDNA2003 applies to domain labels. It applying to<br>
> domain names in UTS #46 is somewhat confusing.)<br>
><br>
><br>
> On Mon, Aug 19, 2013 at 9:32 PM, Shawn Steele<br>
> <<a href="mailto:Shawn.Steele@microsoft.com">Shawn.Steele@microsoft.com</a>> wrote:<br>
> > I concur.  We use the IDNA2008 + TR46 behavior.<br>
><br>
> Interesting. Last I checked Internet Explorer that was not the case.<br>
> Since which version is this deployed? Does it depend on the operating<br>
> system? What variation of TR46 is implemented?<br>
><br>
><br>
> On Mon, Aug 19, 2013 at 11:36 PM, Vint Cerf <<a href="mailto:vint@google.com">vint@google.com</a>> wrote:<br>
> > It seems to me that we would serve the community well if we work towards a<br>
> > well-defined and timely transition to IDNA2008. It has a key property of<br>
> > independence from any particular version of UNICODE (which was the primary<br>
> > reason for moving in that direction). It also has a canonical representation<br>
> > of domain labels which is also a powerful standardizing element. We are all<br>
> > aware of the potential for some backward incompatibility with IDNA2003 but<br>
> > the committee that developed IDNA2008 discussed these issues at length and<br>
> > obviously concluded that the features of IDNA2008 were superior over all to<br>
> > the status quo. It is a disservice in the long run to delay adoption of the<br>
> > newer design, especially given the huge expansion of the TLD space - all<br>
> > these TLDs should be developed and evolved on the IDNA2008 principles.<br>
><br>
> I don't think the committee has carefully considered the compatibility<br>
> impact. Deployed domains would become invalid. Long-standing practice<br>
> of case folding (e.g. the idea that <a href="http://EXAMPLE.COM/">http://EXAMPLE.COM/</a> and<br>
> <a href="http://example.com/">http://example.com/</a> are identical) is suddenly something that is no<br>
> longer decided upon by IDNA but needs to be decided somehow at the<br>
> application-level. And when the Unicode consortium provided such<br>
> profiling for applications in the form of<br>
> <a href="http://unicode.org/reports/tr46/">http://unicode.org/reports/tr46/</a> that was frowned upon. It's not at<br>
> all clear what the transition path is envisioned here.<br>
><br>
><br>
> --<br>
> <a href="http://annevankesteren.nl/">http://annevankesteren.nl/</a><br>
><br>
</p>