- From: John C Klensin <klensin@jck.com>
- Date: Thu, 16 Jan 2014 12:46:21 -0500
- To: Gervase Markham <gerv@mozilla.org>
- cc: "PUBLIC-IRI@W3.ORG" <public-iri@w3.org>, uri@w3.org, IDNA update work <idna-update@alvestrand.no>, "www-tag.w3.org" <www-tag@w3.org>
--On Thursday, January 16, 2014 11:36 +0000 Gervase Markham <gerv@mozilla.org> wrote: >... >> If that was all that had changed, I might be more optimistic. >> I refer you to my earlier email about simple things as >> lowercasing. > > And I refer you to my comments above. Problems like > lowercasing (for better or worse) are punted by IDNA2008 and > are labelled as an application-level problem. In practice, > what everyone should do for best interoperability is implement > the same application-level mappings, and implement ones which > are as compatible as possible with IDNA2003. Hence.... UTS46. Two things: While there are certainly people who find other aspects of UTR46 distasteful, there are, IMO, only two core objections, neither of which relates to UTR46 as a simple mapping layer for user input. One is that UTR 46 specifies, as transitional, some relationships that map IDNA2008-permitted characters into other IDNA2008-permitted characters (an effective blocking function for the former set) without spelling out plausible and relatively short term plans for ending that blocking situation. The use of mappings that hide or block IDNA2008-permitted labels unquestionable violates the intent of IDNA2008 and the intent of making those characters available. The other is that, after earning the scars of many years of experience with a variety of systems and user interfaces, some of us have concluded that the use of unambiguous and stable canonical forms "on the wire" and in contexts that are supposed to be persistent is really important. The distinction between mapping for something typed or otherwise specified directly by the user and a mapping requirement for domains or URLs/URIs stored in documents, search or DNS examination programs, and the like keeps getting lost in this set of discussions, but is really, seriously, important. best, john And, again,
Received on Thursday, 16 January 2014 17:46:49 UTC