WG Review: Internationalized Domain Names in Applications (Revised) (idnabis)

John C Klensin klensin at jck.com
Thu Apr 10 14:58:23 CEST 2008

--On Thursday, 10 April, 2008 09:46 +0200 Patrik Fältström
<patrik at frobbit.se> wrote:

> FWIW: Me too. I think it was the right thing to do, but I
> think we NOW can get version independence.

Let me add a little bit to this.  While there were other things
about the original version of IDNA that I was unhappy with, I
too believed that explicit dependence on Unicode 3.2, and
built-in normative tables, were the right thing to do.
Subsequent experience has convinced me otherwise.  The problems,
IMO, were not just the issues with new characters and changed
properties that Ken mentions (although those are certainly
important, as is the observation that we never did a revision to
4.0, etc.).  

What was at least as important was that the context of use of
IDNA often involved the use of libraries for handling Unicode,
libraries that were not part of IDNA-specific packages and that
hence changed, largely invisibly to the IDNA code, as they were
updated to reflect new Unicode versions.  We could remain
rigidly connected to 3.2 and fight that tide or we could learn
to ride with it; the latter seemed to be the preferable choice.
Even had we made version to version upgrades in IDNA, we would
have run into some of the same problems that lead to discussions
of incompatible changes on this list.  Character properties are
not often changed from Unicode version to version, and the
changes are almost always in obscure, marginal, cases, but, as
Ken points out, they occasionally do occur.  New characters
might be added with case pairings; an IDNA lookup implementation
based on one version of Unicode might handle those code points
differently than a registration implementation based on another.
I think that, when IDNA2003 (RFC 3490 and friends) were being
agreed upon, we had different expectations about immutability of
Unicode properties and decisions than turned out to be
realistic.  At least in my case, those expectations resulted in
part from misunderstandings of what the term "stability" meant
in the Unicode context and of what changes would be made
post-3.2.   All of this was complicated by the "include anything
not explicitly forbidden" and "look up anything" models of
IDNA2003 with the consequent mappings (some of which proved very
confusing to users and registrants alike).  Those rules created
a much larger number of cases to be concerned about, opened the
door to types of abuse from which applications implementers
could protect their users only by adopting application-specific
rules about when to display (or not display) native characters
and that, in turn, made it harder for the end-user to get
predictable behavior and for registrants to know how their
domain names would be handled.

Certainly it would be possible to specify a Unicode
version-specific upgrade to version 5.0 (or, now, 5.1) and fix
those problems, and certainly some people will debate (and have
debated) how important a few of them are to fix.  However, once
even a significant fraction of the other issues are addressed,
version-independence is relatively easily obtained.   Given how
long it seems to take to get anything through the IETF these
days, it seems worthwhile to avoid having to generate a new
standards-track RFC (possibly including chartering yet another
WG or to keep one standing) each time a new Unicode revision
appears (as Ken points out, there are more characters (and more
scripts) coming down the road) or putting the IETF in the
uncomfortable position of preventing users of some scripts from
having IDNs just because we haven't gotten the energy together
to deal with a new Unicode version.


> On 9 apr 2008, at 17.17, Vint Cerf wrote:
>> i find myself in the second group at the present.
>> v
>> On Apr 9, 2008, at 11:12 AM, Paul Hoffman wrote:
>>> At 5:15 PM -0400 4/8/08, Vint Cerf wrote:
>>>> It is believed that the first attempt in 2003 did not
>>>> adequately   deal with several key issues including Unicode
>>>> version-independence.
>>> IDNA2003 was not supposed to deal with version-independence.
>>> Just   the opposite: we explicitly chose to be
>>> version-dependent. Some of   us think that was still the
>>> correct thing to do. Some of us also   think that
>>> version-independence would be fine.
>>> _______________________________________________
>>> Idna-update mailing list
>>> Idna-update at alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/idna-update
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update

More information about the Idna-update mailing list