xd- with C/DNAME (was: Re: The Two Lookups Approach (was Re: Parsing the issuesand finding a middle ground -- another attempt))

Erik van der Poel erikv at google.com
Mon Mar 16 22:06:11 CET 2009

On Mon, Mar 16, 2009 at 12:05 PM, John C Klensin <klensin at jck.com> wrote:
> I'm not going to comment further on this until I see one or more
> specific proposals.  I hope those proposals will respond to the
> issues Andrew has raised as well as the ones I have.  However...

I'm confused about your "However". I will try to write an Internet
Draft, but in the meantime, let me answer this specific email, in

> --On Monday, March 16, 2009 09:54 -0700 Erik van der Poel
> <erikv at google.com> wrote:
>> Also, if it is true that the current expectation is that
>> CNAME/DNAME are typically hidden from the user, I think that
>> might be an argument for a new prefix, which basically says
>> "this is an exceptional circumstance, please process according
>> to special rule set R".
> This is one of the specific areas in which I'm having a problem
> forming a mental picture of what you are actually suggesting.

The client MUST do whatever MUSTs are currently associated with
CNAME/DNAME, MAY do whatever MAYs are associated, etc.

In addition, the client MAY do extra things if the CNAME/DNAME is to a
domain name that includes an xu-- label. In other words, the xu--
prefix would trigger additional behavior.

> Certainly it would be no problem for a registry to analyze an
> incoming non-ASCII string and say, "this is odd, give it a
> different prefix when it is stuffed into the zone".

Yes, the registry would form a bundle via CNAME and/or DNAME, and the
target of the CNAME/DNAME would contain a label with the xu-- prefix,
followed by some Punycode. This Punycode is decoded to Unicode, and
that Unicode is then run through IDNA2003, IDNA2008, etc, and used for
display, etc, as I outlined (with details to follow).

> But to look up such a label, the application needs to start with
> an arbitrary string of Unicode characters and decide how to
> encode it and what prefix it gets.  Is your expectation that
> each application, as part of IDNAx processing, will maintain a
> table of odd characters, potentially with different mapping
> rules and prefixes for each group?

No, the mapping rules would cover an entire version of Unicode, just
like IDNA2003 covered the entire range of Unicode 3.2.

And there would be two IDNA prefixes forever: xn-- and xu--.

> I suppose that would be
> possible, but it is the sort of thing that experience indicates
> that people routinely get wrong, leading to the sort of
> interoperability problems that cannot be predicted or easily
> diagnosed.

The client would initially perform a normal IDN lookup. It would first
use whatever most recent version of IDNA it has. My suggestion does
assume that IDNA2008, IDNA2013, etc would include mapping as a first
class citizen. (But of course, the IDNA specs do not necessarily have
to be published in 5 year intervals -- that's just an example.)

Anyway, I can see now that email just isn't going to work. I will have
to write an Internet Draft.


More information about the Idna-update mailing list