<div dir="ltr">Mark,<div><br></div><div>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. </div>
<div><br></div><div>vint</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 23, 2013 at 6:19 AM, Mark Davis ☕ <span dir="ltr"><<a href="mailto:mark@macchiato.com" target="_blank">mark@macchiato.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:'times new roman',serif">There are two different issues.</div>
<div class="gmail_default" style="font-family:'times new roman',serif"><br></div><div class="gmail_default" style="font-family:'times new roman',serif">
A. The mapping is purely a client-side issue, and is allowed by IDNA2008. So that is not a problem for compatibility.</div><div class="gmail_default" style="font-family:'times new roman',serif"><br></div><div class="gmail_default" style="font-family:'times new roman',serif">

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.</div>

<div class="gmail_default" style="font-family:'times new roman',serif"> </div><div class="gmail_default" style="font-family:'times new roman',serif"><br></div><div class="gmail_default" style="font-family:'times new roman',serif">

B. The transitional incompatibilities are:</div><div class="gmail_default"><div style="font-family:'times new roman',serif"><ol><li>Non-letter support</li><li>4 deviation characters</li></ol><div>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.</div>

</div><ol><li style="font-family:'times new roman',serif">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 <i>also</i> need to forbid their subregistries from having them in Nth-level domains (that is, disallow http://☃.<a href="http://blogspot.ch/" target="_blank">blogspot.ch/</a> = <a href="http://xn--n3h.blogspot.ch" target="_blank">xn--n3h.blogspot.ch</a>).</li>

<li><span style="font-family:'times new roman',serif">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.</span></li>

</ol></div></div><div class="gmail_extra"><div class="im"><br clear="all"><div><font face="'times new roman', serif"><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">
<div>
</div></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><br></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">

<a href="https://plus.google.com/114199149796022210033" target="_blank">Mark</a></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><i><br></i></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">

<i>— Il meglio è l’inimico del bene —</i></div></font><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div></div>
<br><br></div><div class="im"><div class="gmail_quote">On Fri, Aug 23, 2013 at 11:49 AM, Vint Cerf <span dir="ltr"><<a href="mailto:vint@google.com" target="_blank">vint@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><br><div class="gmail_extra">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.</div>

<span><font color="#888888">
<div class="gmail_extra"><br></div><div class="gmail_extra">v</div><div class="gmail_extra"><br><br><div class="gmail_quote"><br></div></div></font></span></div>
</blockquote></div><br></div></div>
</blockquote></div><br></div>