IDNAbis compatibility

John C Klensin klensin at
Tue Apr 3 19:28:26 CEST 2007

--On Tuesday, 03 April, 2007 09:49 -0700 Mark Davis
<mark.davis at> wrote:

> IDNA2003 eliminates any inconsistency by specifying an exact
> folding, one that is a language-independent folding.

Or, put differently, one that is a compromise among
language-related issues and that hence ends up being correct for
some languages and incorrect for others.

> IDNAbis, as currently proposed,
> drops any notion or folding (or leaves it up to the
> application). think that
> there is rough consensus that we shouldn't have had folding in
> IDNA2003, but
> my concern is that if we drop it on the floor in IDNAbis, that
> we will get
> inconsistency between applications and/or too high a level of
> breakage.
> I mentioned the possibility of separating folding into a
> separate RFC; that
> may be a way to deal with it. Applications that wanted
> consistent folding
> could adhere to the RFC on IDNA folding; ones that didn't want
> folding, or
> wanted their own, wouldn't claim conformance to that separate
> RFC.

As long as this is strictly a discussion about the "lookup",
rather than "registration", side of things, and it doesn't
affect what is normative in URIs or IRIs used between systems,
that would certainly work.   Of course, such applications would
be faced with a three-way choice when localization was

	(i) Don't fold
	(ii) Fold according to the new RFC, presumably
	consistently with IDNA2003 updated if necessary to
	reflect Unicode 5.0 (or 5.1) or updated from time to
	time to reflect new versions of Unicode.  Of course, if
	no new case-sensitive characters are added, those
	updates would be trivial.
	(iii) Fold according to local conventions as required by
	the local language(s).

This raises some issues which we at least need to understand
before adopting that approach.  The first is that complete
consistency cannot be guaranteed, simply because the three
choices exist.  Note that we can do nothing to eliminate the
third choice: implementations will do what they need to do to
gain local acceptance and make local sense.   Second, unless we
are careful, (ii) would reintroduce version dependency.  That
would be unfortunate, but, if it were in a supplemental option,
rather than the base protocol, I don't see it as a showstopper.


More information about the Idna-update mailing list