Bundling of Domain Names and DNAME

John C Klensin klensin at jck.com
Fri Dec 4 16:15:27 CET 2009



--On Friday, December 04, 2009 08:47 -0500 Andrew Sullivan
<ajs at shinkuro.com> wrote:

> On Fri, Dec 04, 2009 at 08:36:50AM -0500, Vint Cerf wrote:
>> Vaggelis,
>> 
>> extensions of DNS in the XNAME direction would require
>> creation of a   new WG for this purpose.
> 
> It wouldn't require a new WG: that's exactly what DNSEXT
> exists for. So I think that's why Vaggelis has sent a note to
> namedroppers.  It'd probably make sense to take that topic
> over there and leave idnabis out of the discussion, since the
> reason for the extension (mirroring part of a tree to do DNS
> variants) is just one of the possible uses of such a
> mechanism, were it possible to design it safely.  (For the same
> reason, I send this only to the idnabis list, and not to that
> of dnsext.)

Andrew,

I've been trying to listen to this discussion rather than
contribute further to the noise by saying things over again that
I've said many times already.  I may try to summarize at some
point but, to the degree to which the discussion has spun over
to DNSEXT and Namedroppers, two observations...

(1) I strongly believe that it would be good to explore aliasing
models for the DNS that respond better to user expectations and
particular requirements in IDN and similar areas than DNAME or
CNAME. Vaggelis's suggestion for an alias that would work at the
same level, not below that level in the tree ("xNAME") certainly
falls into that category.   I believe that such mechanisms would
be broadly useful, as you suggest above.   

(2) The disadvantage of such "new RR"-based mechanisms is that
they  would take a long time to deploy, at least if the
universal deployment of EDNS0 and DNSSEC are indicative.  That
doesn't mean that they would not be worth discussing, but the
implications of delay need to be understood by everyone
involved.  If DNSEXT is going to go down that path, I'd
encourage the WG --and the broader community-- to consider the
other question that the IDNABIS WG was absolutely forbidden to
consider and that the original IDNA WG rejected early on,
precisely because it would take too long to deploy.  That
question involves the set of approaches that would move some
significant fraction of the matching rules for non-ASCII domains
to the server side, just as some significant fraction of the
undecorated Latin matching rules were placed on the server side
in the original DNS spec by its ASCII case-insensitive matching.
Long-term, moving more of the work to the server side would also
make it possible to consider eliminating the use of ACE forms,
with the advantages that the plenary in Hiroshima suggested as
well as making most of the requirement for symmetry between the
ACE (now A-label) and U-label forms moot.

I think most of us understand by now that it would not be
possible to move every desirable IDN matching rule to the server
side.  For example, if two different languages use the same
script in different ways or the actual rules require language
knowledge or context, any matching rules will almost certainly
have to be left as a localization matter.  The differences
between German and Swedish usage for ä (U+00E4) and ö (U+00F6)
would almost certainly prevent server-side matching involving
those characters and "æ" (U+00E6) or "ae", or "œ" (U+0153) or
"oe" even if rules in German itself did not.  Interactions with
Japanese and Korean might prohibit server-side matching of
Traditional and Simplified Chinese (matching Simplified to
Traditional might work, but a one-way situation would require
significant study).  But certainly one could handle matching of
strings that were the same after NFC (or NFC) normalization and
the many thousands of equivalences that are obvious to everyone
who looks carefully, including the Greek Tonos issue, character
forms that depend on initial, medial, final, or isolated
contexts, and so on.

Certainly neither agreeing to the details of such an approach
nor deploying it would be quick.  It also would leave us with
the new challenge of working out a transition between IDNA2008
and a (presumably UTF-8 based) server-side solution; a
transition that would make some of the difficult issues with,
e.g., Eszett transition and different resolution forms look like
a picnic.  But, if DNSEXT (or some other WG) is going to start
examining RRs with different properties in order to address IDN
issues, I hope that the question of how long they would take to
define and deploy would be examined in the context of how long
it would take to define and deploy a more server-oriented IDN
solution.   If the likely times were similar, the payoffs of the
latter might enough larger to justify the added investment.

Just my opinion.

    john




More information about the Idna-update mailing list