DNS Improvements (was: RE: Bundling of Domain Names and DNAME)

[John C Klensin]

Shawn,

We should take this discussion off the IDNABIS list to reduce
noise and avoid further distractions from getting its work done.
Even if we had consensus today to go ahead with one or the other
as soon as possible (and that consensus, as Andrew has hinted,
definitely does not exist in the broader community or gets
immediately tied up with "DNS2" and other forms of hand waving),
I don't think that any of those who want to _use_ IDNs are
willing to postpone their plans and wait a decade (or probably
much more) for a better solution.

"Knowing" what will come that far off is impossible anyway --
just too long a time to even get something specified to know how
it will work out.  And it would need to be a different WG for an
unrelated reason: either of those proposals would require (or
risk) deep modifications to the DNS --exactly the situation IDNA
was intended to avoid-- and it is very clear that the needed
expertise is just not present in this WG in adequate proportions.

IMO, for this WG, there are only two big questions, even if one
assumes significant new DNS capabilities in the future that
would help support IDNs:

	* Is IDNA2008 significantly better than IDNA2003 (and,
	given proposals on the table or the absence thereof,
	that is IDNA2003 and Unicode 3.2)?
	
	* Given a "yes" answer to that question, are there ways
	to tune the IDNA2008 specs in specific, known, areas
	that would make people more comfortable with the
	[remaining] changes and/or the consensus more solid.

If one wants to get started on more dramatic long-term work, the
most efficient way to proceed is almost certainly to get this
work done, published, and behind us as quickly as possible.

   john


--On Friday, December 04, 2009 19:58 +0000 Shawn Steele
<Shawn.Steele at microsoft.com> wrote:

>> (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.
> 
> This would go a long way to addressing some of my concerns.  I
> have additional unvoiced concerns that some languages have
> alternate spellings, and there are sometimes conventions which
> make it difficult to allow a "correct" and a "short-hand" form
> without good XNAME type support.  I think this would help a
> lot.
> 
>>  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,
> 
> Very much agree.  It'll take even longer to deploy if we never
> start :)
> 
>> Long-term, moving more of the work to the server side would
>> also make it possible to consider eliminating the use of ACE
>> forms,
> 
> Very, Very Much Agree.  We have interesting problems because
> we support ACE and UTF-8 differently.  A standard specifying
> out UTF-8 and IDN played together would go a long way to
> solving those problems.
> 
> Given the complexity it should probably be another WG though
> so we can get done with the current version of IDN.  It might
> help if we "knew" something was coming in the future for some
> of these scenarios.
> 
> -Shawn