Changing the xn-- prefix

Harald Tveit Alvestrand harald at
Tue Mar 18 20:06:20 CET 2008

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?
>    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.

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.
>    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.


More information about the Idna-update mailing list