xn--p1ai

[Mark Davis ☕]

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.

*Note: *UTS #46 has three features, and it is important to distinguish
between them. Some of you already know this, but just to clarify...

   1. *A non-transitional mapping. *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.
   2. *A transitional mapping. *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.
   3. *A transitional validity test. *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.

As to the migration away from a transitional mapping (#2):

   - 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.
   - If enough registries do that, it would become possible to 'flip the
   switch' and move to non-transitional mapping (#1) for all labels.

Mark

*— Il meglio è l’inimico del bene —*


On Thu, Feb 24, 2011 at 16:39, Gihan Dias <gihan at uom.lk> wrote:

>  On 24-02-2011 22:33, Mark Davis ☕ wrote:
>
> 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.
>
>  Mark,
> 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.
>
> Thanks and Regards,
>
> Gihan
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20110225/2caea521/attachment.html>