- 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>
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:26 UTC