I think this conversation is devolving a bit. There were many controversial
topics and a huge number of exchanges during the course of the development
of IDNA2008. Dredging them up and repeating them here will not do anyone
any good, and the flood of emails just cause listeners to tune out.
So I'd like to bump up a level, and get back to the real questions, which
is how to move the clients (browsers, search engines, etc.) forward.
There are three major options for clients:
1. Move immediately to IDNA2008.
2. Stay on IDNA2003.
3. Move to TR46+IDNA2008 as a transition to IDNA2008.
Recent history has shown that the major clients are reluctant to do #1
because of compatibility concerns. I don't think anyone really wants #2,
because it has an archaic Unicode version, but people are sticking with
that if they see #1 as the only other choice.
That effectively leaves #3. And certainly major players like IE have shown
that it can be deployed effectively.
Mark <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**
On Thu, Aug 22, 2013 at 1:11 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Thu, Aug 22, 2013 at 12:02 PM, Gervase Markham <gerv@mozilla.org>
> wrote:
> > It's not been possible to register names like ☺☺☺.com for some time now;
> > that's a big clue.
>
> I don't think it is. There's sites out that rely on underscore working
> in subdomains. You cannot register a domain name with an underscore.
>
>
> > (Are your friends really using http://xn--74h.example.com/ ?)
>
> Yeah (with "example" replaced). Renders fine in Safari, too.
>
>
> > IIRC, we must have broken a load of URLs when we decided that %-encoding
> > in URLs should always be interpreted as UTF-8 (in RFC 3986), whereas
> > beforehand it depended on the charset of the page or form producing the
> > link. Why did we do that? Because the new way was better for the future,
> > and some breakage was acceptable to attain that goal.
>
> Actually, I don't think we did. And the reason for that is that the
> non-ASCII usage was primarily in the query string. And as it happens,
> we still use the character encoding to go from code points to
> percent-escaped byte code points there. The IETF STD doesn't admit to
> this, which is part of the reason why we have
> http://url.spec.whatwg.org/ now.
>
>
> --
> http://annevankesteren.nl/
>