John C Klensin klensin at
Mon Jul 28 15:48:44 CEST 2008

--On Monday, 28 July, 2008 03:49 -0700 Mark Davis
<mark.davis at> wrote:

> My purpose is not to see the mapping incorporated into the
> protocol document; it is rather to provide a separate but
> concrete specification of what that mapping should be, along
> the lines of what is in
> That is, supply a mapping that is essentially the same as the
> one used in IDNA2003, but logically and consistently extended
> to the repertoire of any Unicode version, much like what
> Tables is doing in terms of rules.
> My concern is that if we don't supply a precise specification
> of what a compatible mapping would be, we will end up with all
> kinds of spurious differences among mappings.
> The open issue in my mind as to the draft document I put
> together is whether it has to be absolutely compatible with
> IDNA2003, or whether we can get rid of the small set of
> exclusions (Section 3.3 Exclusions) and the mapping errors
> (Section
> 3.4.3. Retain Corrigendum #4: Five Unihan Canonical Mapping
> Errors), which would be rather nice to do.


I am pretty much in agreement with Patrik.  I see it as very
useful to give guidance about mapping, both in terms of a
relative of your document and in terms of more guidelines in
Rationale.  But, like him, I suspect that the best guidance may
be different for different types of situations.  Even in the web
context, the right advice might be a little different when
addressed to browser implementers, document-writers and their
tools, and systems processing, searching, analyzing the document

My other goal, quite explicitly, is to get us on a migration
path today URIs/IRIs  that require no mapping to interpret or
resolve, rather than directly or indirectly locking in most of
the IDNA2003 mappings forever.   And, however unfortunately, we
have only two tools to accomplish that:

	* explanations as to why mapping-free URIs are a better
	idea (regardless of what the marketing or graphic design
	department, or their equivalent, might want  and
	* having a situation in which, in the most general case,
	mapping-dependent URIs are not guaranteed to always work
	smoothly and as predicted, and actually having them fail
	sometimes.  Note that "fail" here could be "browser will
	render only the post-mapping form, no matter what goes
	in" rather than "link resolution will fail" and, again,
	might be different for different contexts.

More information about the Idna-update mailing list