Standardizing on IDNA 2003 in the URL Standard
vint at google.com
Fri Aug 23 13:01:36 CEST 2013
thanks for the refinement. Is it possible that the browser makers would
agree to discuss a plan and schedule to achieve these various objectives?
My impression regarding the 4 deviation characters is that the Arabic users
would benefit from IDN2008 treatment of the zero width characters so that
seems to have some priority. The sharp-S continues to foster debate but it
is a legitimate character and is used in normal cases and seems to deserve
support. The trailing sigma question continues to produce controversy
although the IDNA2008 committee finally concluded it deserved support.
On Fri, Aug 23, 2013 at 6:19 AM, Mark Davis ☕ <mark at macchiato.com> wrote:
> There are two different issues.
> A. The mapping is purely a client-side issue, and is allowed by IDNA2008.
> So that is not a problem for compatibility.
> The most important feature of 'no mapping' IMO is on the registry side: to
> make certain that registries either disallow mapping during the
> registration process, or that they very clearly show that the resulting
> domain name is different than what the user typed. While an orthogonal
> issue to the client-side we're discussing here, it is worth a separate
> B. The transitional incompatibilities are:
> 1. Non-letter support
> 2. 4 deviation characters
> Both of these are just dependent on registry adoption. The faster that
> happens, the shorter the transition period can be. Note the transition for
> each of these is independent, and can proceed on a different timescale.
> Moreover, terminating the transition period doesn't need all registries to
> buy in.
> 1. The TR46 non-letter support can be dropped in clients once the
> major registries disallow non-IDNA2008 URLs. I say URLs, because the
> registries need to not only disallow them in SLDs (eg http://☃.com),
> they *also* need to forbid their subregistries from having them in
> Nth-level domains (that is, disallow http://☃.blogspot.ch/ =
> 2. The TR46 deviation character support can be dropped in clients once
> the major registries that allow them provide a bundle or block approach to
> labels that include them, so that new clients can be guaranteed that URLs
> won't go to a different location than they would under IDNA2003. The
> bundle/block needs to last while there are a significant number of IDNA2003
> clients out in the world. Because newer browsers have automatic updates,
> this can be far faster than it would have been a few years ago.
> Mark <https://plus.google.com/114199149796022210033>
> *— Il meglio è l’inimico del bene —*
> On Fri, Aug 23, 2013 at 11:49 AM, Vint Cerf <vint at google.com> wrote:
>> If we go down the IDNA2008 + TR46 path, I think we ought to be very
>> explicit about a date certain to drop TR46 treatment so as to eliminate
>> mapping and to instantiate the uniqueness properties of IDNA2008. Is that
>> possible and what timeframe makes sense? The longer we wait, the harder it
>> will be to get there.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Idna-update