Standardizing on IDNA 2003 in the URL Standard

[Mark Davis ☕]

> It's also not true for URLs in resources that depend on the mapping to
happen.

TR46 really has 3 parts:

   1. transitional handling for the 4 ambiguous characters
   2. inclusion of symbols
   3. client-side mapping (aka lowercasing)

Parts #1 and #2 are transitional in supporting IDNA2003 on the path to
IDNA2008.

Part #3 (client-side mapping) is something that is permitted by IDNA2008,
and is thus optional for even a fully IDNA2008-compliant implementation.



Mark <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**


On Wed, Aug 21, 2013 at 5:45 PM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Wed, Aug 21, 2013 at 4:01 PM, Mark Davis ☕ <mark at macchiato.com> wrote:
> > I agree with that, and it is the scenario envisioned for TR46. That is,
> once
> > all (significant) registries move to IDNA2008, then then clients can
> impose
> > stricter controls on the characters, excluding the characters that are
> > disallowed in IDNA2008. Because the registries will have moved, the
> number
> > of failing URLs would be acceptable.
>
> I doubt that would be true for subdomains. E.g. I know people using
> http://☺.example.com/ as domain (forgot whether that particular code
> point is excluded, but you get the idea).
>
> It's also not true for URLs in resources that depend on the mapping to
> happen. Especially for uppercase/lowercase I would expect that to be
> fairly common. And in URLs in resources should remain
> locale-insensitive. That they depend on encodings to some extent is
> bad enough.
>
>
> --
> http://annevankesteren.nl/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20130821/d33e36d5/attachment-0001.html>