W3C home > Mailing lists > Public > uri@w3.org > August 2013

Re: Standardizing on IDNA 2003 in the URL Standard

From: 신정식 <jshin1987@gmail.com>
Date: Tue, 20 Aug 2013 07:46:27 -0700
Message-ID: <CAE1ONj_ggrGFYUXM1nTSAJY7oqWF2Knscznwsrp_95SMHY7xwA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Peter Saint-Andre <stpeter@stpeter.im>, "www-tag.w3.org" <www-tag@w3.org>, "uri@w3.org" <uri@w3.org>, "public-iri@w3.org" <public-iri@w3.org>, "idna-update@alvestrand.no" <idna-update@alvestrand.no>, Mark Davis ☕ <mark@macchiato.com>, Vint Cerf <vint@google.com>, Shawn Steele <Shawn.Steele@microsoft.com>
2013. 8. 20. 오전 5:33에 "Anne van Kesteren" <annevk@annevk.nl>님이 작성:
>
> On Mon, Aug 19, 2013 at 6:31 PM, Mark Davis ☕ <mark@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
exceptions,
> > 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@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@google.com> wrote:
> > It seems to me that we would serve the community well if we work
towards a
> > well-defined and timely transition to IDNA2008. It has a key property of
> > independence from any particular version of UNICODE (which was the
primary
> > reason for moving in that direction). It also has a canonical
representation
> > of domain labels which is also a powerful standardizing element. We are
all
> > aware of the potential for some backward incompatibility with IDNA2003
but
> > the committee that developed IDNA2008 discussed these issues at length
and
> > obviously concluded that the features of IDNA2008 were superior over
all to
> > the status quo. It is a disservice in the long run to delay adoption of
the
> > 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.
>
>
> --
> http://annevankesteren.nl/
>
Received on Tuesday, 20 August 2013 14:47:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:16 UTC