Standardizing on IDNA 2003 in the URL Standard
John C Klensin
klensin at jck.com
Thu Jan 16 18:46:21 CET 2014
--On Thursday, January 16, 2014 11:36 +0000 Gervase Markham
<gerv at 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
> 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.
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.
More information about the Idna-update