<font face="georgia,serif">What we're planning on is following the transitional recommendations for the interim, which means preserving the 4 characters in display and interchange, and only mapping those them on lookup.</font><div>
<font class="Apple-style-span" face="georgia, serif"><br></font></div><div><font class="Apple-style-span" face="georgia, serif"><b>Note: </b>UTS #46 has three features, and it is important to distinguish between them. S</font><span class="Apple-style-span" style="font-family: georgia, serif; ">ome of you already know this, but just to clarify... </span></div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><ol><li><font class="Apple-style-span" face="georgia, serif"><b>A non-transitional mapping. </b>This does lowercase, width mappings, etc. consistent with how IDNA2003 works. It is intended for compatibility with IDNA2003 mappings and preserving user expectations. An implementation using it can be fully compliant to IDNA2008.</font></li>
<li><font class="Apple-style-span" face="georgia, serif"><b>A transitional mapping. </b>This is #1, plus IDNA-2003-compatible support for the 4 characters changed by IDNA2008. It is not IDNA2008 compatible, and is intended to be used transitionally, and then only for lookup, not display or interchange.</font></li>
<li><font class="Apple-style-span" face="georgia, serif"><b>A transitional validity test. </b>This is basically a union of the characters allowed in IDNA2003 and IDNA2008. It is intended for transitional use by client software. As registries move to only allowing IDNA2008 characters, the need for this will go away.</font></li>
</ol></div><div><div><div><font face="georgia, serif">As to the migration away from a transitional mapping (#2):</font></div><div><ul><li><span class="Apple-style-span" style="font-family: georgia, serif; ">If a registry guarantees that transitional labels are bundled with their non-transitional counterparts, it becomes possible for clients (browsers, search engines) to support the non-transitional mapping (#1) for those labels in all cases, without problems with incompatibility, usability, or security.</span></li>
<li><span class="Apple-style-span" style="font-family: georgia, serif; ">If enough registries do that, it would become possible to 'flip the switch' and move to <meta http-equiv="content-type" content="text/html; charset=utf-8">non-transitional mapping (#1) for all labels.</span></li>
</ul></div><div><font face="georgia, serif">Mark<br>
<br><i>— Il meglio è l’inimico del bene —</i></font><br>
<br><br><div class="gmail_quote">On Thu, Feb 24, 2011 at 16:39, Gihan Dias <span dir="ltr"><<a href="mailto:gihan@uom.lk" target="_blank">gihan@uom.lk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





  

<div bgcolor="#ffffff" text="#000000"><div>
On 24-02-2011 22:33, Mark Davis ☕ wrote:
<blockquote type="cite"><font face="georgia,serif">At Google, we'll be applying
the UTS#46 mappings both in the Chrome browser and to URLs found in
other contexts such as search.</font>
  <div><font face="georgia,serif"><br clear="all">
  </font></div>
</blockquote>
</div>Mark,<br>
It's very important to Indic users that the ZW(N)J characters are *not*
deleted in the specific contexts given in IDNA2008. I hope this is
accommodated in Chrome and Google search.<br>
<br>
Thanks and Regards,<br>
<br>
Gihan<br>

</div>


<br>_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no" target="_blank">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
<br></blockquote></div><br></div></div>
</div>