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
initiative.
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/ = xn--n3h.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@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.
>
> v
>
>
>
>