W3C home > Mailing lists > Public > www-tag@w3.org > January 2014

Re: Standardizing on IDNA 2003 in the URL Standard

From: Simon Josefsson <simon@josefsson.org>
Date: Tue, 21 Jan 2014 16:32:29 +0100
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Gervase Markham <gerv@mozilla.org>, John C Klensin <klensin@jck.com>, yaojk <yaojk@cnnic.cn>, Paul Hoffman <paul.hoffman@vpnc.org>, "PUBLIC-IRI\@W3.ORG" <public-iri@w3.org>, "uri\@w3.org" <uri@w3.org>, IDNA update work <idna-update@alvestrand.no>, "www-tag.w3.org" <www-tag@w3.org>
Message-ID: <87k3dt73le.fsf@latte.josefsson.org>
Anne van Kesteren <annevk@annevk.nl> writes:

> On Thu, Jan 16, 2014 at 11:36 AM, Gervase Markham <gerv@mozilla.org> wrote:
>> On 16/01/14 11:17, Anne van Kesteren wrote:
>>> It's not worse if it's fully backwards compatible and mostly
>>> interoperable across all major clients. At that point the standard is
>>> just wrong.
>>
>> And having a standard fixed to Unicode 3.2 is not also "just wrong"?
>
> The point is that in practice, it isn't fixed to Unicode 3.2. I have
> yet to encounter an IDNA2003 implementation that does that.

GNU Libidn fixes the Unicode tables to Unicode 3.2.  Even to the point
that I don't include the PR29 "fix" to the NFKC algorithm that came
later, because that would break the letter and spirit of IDNA2003, see
for example:

http://www.gnu.org/software/libidn/manual/libidn.html#PR29-discussion

However there is nothing that prevents anyone from proposing an update
to IDNA2003 that uses a newer (but also hard-coded) Unicode version.
The IDNABIS WG chose not to go down that route, though, so it may be
hard to gain consensus around that approach, but IDNA2008 adoption seems
to (IMHO) be marginal, inconsistent and insufficient so there may be
room for re-consideration.

/Simon
Received on Tuesday, 21 January 2014 15:33:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:00 UTC