Changing the xn-- prefix

Simon Josefsson simon at
Tue Mar 18 22:00:05 CET 2008

Harald Tveit Alvestrand <harald at> writes:

> Simon Josefsson skrev:
>> Harald Tveit Alvestrand <harald at> writes:
>>> Simon,
>>> Simon Josefsson skrev:
>>>> I note that using a new prefix instead of xn-- would avoid this problem.
>>>> Specifications and implementations that use IDNA2003 continue to use
>>>> xn-- and will work fine within its limitations.  New specifications and
>>>> implementations that support IDNABIS will use another prefix and also
>>>> work fine.
>>>> I'm not suggesting we adopt this approach, but I haven't
>>>> seen the disadvantages of changing the prefix clearly expressed yet.
>>>> There is a cost in maintaining both IDNA2003 and IDNABIS encodings of
>>>> strings during a transition-period.  Whether that cost is higher or
>>>> lower than the complexity in re-using the old prefix for something that
>>>> won't be fully backwards compatible is not clear to me.
>>> section 9.3.3 of draft-klensin-idnabis-issues-07 tries to describe (in
>>> just a few sentences) the cost drivers that (I think) makes a prefix
>>> change a very expensive proposition, both in terms of work for the DNS
>>> operators and in terms of ongoing execution-time costs of application.
>>> That argument convinced me; if you find any part of that unclear, or
>>> disagree with the conclusions, feedback on the text would be welcome.
>> The section didn't convince me.  It seems to repeatedly assert that the
>> costs are "considerable" without going into technical details.
>> There are some claims that look substantive:
>>    Even if they wanted to do so, all registries could not convert all
>>    IDNA2003 ("xn--") registrations to a new form at the same time
>> I don't see why registries would need to convert anything at the same
>> time?  Supporting IDNABIS will be a gradual process for the few
>> registries that support IDNA2003 today.  I don't think any registry will
>> support IDNABIS the same day it is published.  There is no change
>> everything at the same time.
>>    systems that needed to support both labels
>>    with old prefixes and labels with new ones would first process a
>>    putative label under the IDNA200X rules and try to look it up and
>>    then, if it were not found, would process the label under IDNA2003
>>    rules and look it up again.
>> IDNABIS could say that for backwards compatible reasons, when you create
>> a domain xp--foo in your zone (for some non-ASCII string), the software
>> needs to make sure there is a xn--foo for the corresponding IDNA2003
>> name too, if there is an equivalent IDNA2003 name.
>> Yes, this require some special text intended for people creating and
>> maintaining zone files.  However, such text is need anyway.  The process
>> of populating a zone file for non-ASCII domains is complicated and there
>> are many fine details that cause problems.
> So you agree that there is a cost in supporting both xn-- and xp-- 
> versions of all IDN labels (and, of course, xn-- and xp-- versions of
> the zones when the names are non-terminal labels), but you disagree
> that this cost will be significant.
> Did I interpret your statement correctly?

Not quite.  I don't know whether the cost is significant or not.
Frankly, I think we must compare the cost of changing the prefix to the
cost of the other alternatives before we can say anything useful.

Wouldn't you agree that keeping the same prefix and making substantial
backwards incompatible changes would have a significant cost?  People
like Mark who keeps a decoded form of the hostname in a local database
will have problems knowing whether the name was encoded using IDNA2003

>>    That process could significantly slow down all processing that
>>    involved IDNs in the DNS especially since, in principle, a
>>    fully-qualified name could contain a mixture of labels that were
>>    registered with the old and new prefixes, a situation that would make
>>    the use of DNS caching very difficult.
>> That is false for the CNAME approach.
> What do you mean by the "CNAME approach"? (draft name?)
> CNAMEs don't work for nonterminals - you need DNAMEs for that.

If there is interest in investigating an approach to minimize the costs
associated with changing the prefix in draft form, I could help work on

I think there are at least two options to minimize costs associated with
changing the prefix:

1) For every new IDNABIS name that is registered with a new prefix, also
register the IDNA2003 name (with the xn-- prefix), with the same DNS
data (A/NS/etc).  It won't be possible to register all names, and
mapping the IDNABIS names to IDNA2003 names can be non-trivial -- but if
we limit ourselves to the PR-29 problem and assume that IDNABIS will
allow ß in names, the mapping from IDNABIS strings to IDNA2003 strings
is trivial.

2) Use CNAME+DNAME to map the IDNA2003 names to IDNABIS names (or vice
versa).  On second thought, this may cause more problem than the first
alternative, as the CNAME/DNAME semantics doesn't map completely to the
IDNA2003/IDNABIS differences.

> And I still don't understand how you avoid doing 2 lookups before you
> conclude that a name really doesn't exist, no matter how many CNAMEs
> you have lying around.

Old applications that only support IDNA2003 will only lookup IDNA2003
names.  It will get a IDNA2003 name iff such a name exists.

New applications will only lookup IDNABIS names, with the new prefix.
It will get a IDNABIS name iff such a name exists.

There is only a problem if the registry forget to add a IDNA2003 name
for every IDNABIS name.

>>    In addition, looking up the same input string as two separate
>>    A-labels would create some potential for confusion and attacks, since
>>    they could, in principle, resolve to different targets.
>> This threat doesn't seem applicable to the CNAME approach.
>> I'm not proposing that we should change the prefix here, but I'd like to
>> understand the disadvantages in doing so.  There are some advantages:
>> Other backwards incompatible changes appear to be considered at this
>> point, such as using a newer Unicode version or changing how ß is
>> handled.  It will be simple to make those other backwards incompatible
>> changes if we change the prefix.
> Other thread.... but note that if incompatible changes are accepted, they will also complicate the process of populating both the xn-- 
> namespace and the xp-- namespace.

Definitely.  But then the problem is reduced to mapping new strings to
old strings during registration time.


More information about the Idna-update mailing list