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