> 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@annevk.nl> wrote:
> On Wed, Aug 21, 2013 at 4:01 PM, Mark Davis ☕ <mark@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/
>