Another Transition Plan Proposal

John C Klensin klensin at jck.com
Fri Dec 11 00:54:15 CET 2009



--On Thursday, December 10, 2009 15:12 -0800 Gervase Markham
<gerv at mozilla.org> wrote:

> On 10/12/09 13:33, John C Klensin wrote:
>>> 1) Make the characters final-sigma and sharp-S usable ASAP.
>>> 2) Avoid as much as possible the situation where the same URL
>>> goes to  two locations in two different clients.
>> 
>> I note that you say "URL" here.
> 
> Yes; shorthand from my world. Sorry about that :-)
> 
>> A strategy that necessarily "sticks" mail-related URLs with
>> constraints that come mostly from web deployment may not be an
>> optimal strategy.  And it might be ignored as a result.
> 
> Let me then rephrase 2) as:
> 
> 2) Avoid as much as possible the situation where the same
> domain is resolved to two different IP addresses (not
> controlled by the same  entity) by two different
> clients/resolvers.
> 
> Specifying this principle in a watertight way which covers all
> the bases  might require further elaboration, but I hope
> everyone knows what I mean.

I think I know what you mean.  "Same domain" is going to give a
lot of people heartache.  

>...
>> But Eszett is complex enough that I'm not sure that I even
>> understand what the above is proposing.
> 
> Actually, what happens could be even simpler than that. What
> would be  the downside, apart from perhaps the increase in
> size of the zone file,  of just doing bundling for every
> possible instance of the characters?
> 
> So as well as the obviously-correct cases, hassle.com would
> also have an  alias as haßle.com. No-one will ever type
> haßle.com into their browser,  but that's OK. Similarly,
> γλώσσα.com would also have γλώςςα.com, which  is
> entirely wrong. But again, no-one would type it, so it just
> sits  there. The price of having some obviously-odd domain
> names in the file  is that we make sure that all the edge
> cases are covered, and we don't  have to draw a line between
> "this one over here needs an alias, and this  one over there
> does not".

In the context of how I understand the DNS works, there is no
"sit there".  Let's talk haßle.com as an example first.  First
of all, I'm not sure what "alias" means.   Clearly it can be
delegated to someone, presumably whomever is the registrant for
"hassle.com", but that imposes costs on that registrant -- they
have to maintain a separate zone file, either as a duplicate of
the "hassle" one or set up to use wildcards or another mechanism
to be sure that any query, for any RR TYPE, yields the
equivalent of "no one home" (deliberately stated in language
that can't be confused with the DNS or any other protocol).  Or
we can try to make an alias with DNAME.  But there we run into
problems if the owner of hassle.com actually expects
http://hassle.com/ (as distinct from http://www.hassle.com/ to
work, because http://haßle.com/ won't work, at least without
some other measures.  And, again, to determine which ones need
to work and how requires asking the registrants and/or signing
them up for more work (which also requires asking them).

That gets to Cary's note and a situation he explained better
than I can.

Also note that, if "Mississippi" were a label in a domain
concerned with German, any simple mechanical operation would be
required to bundle with it, not only Mißißippi, but also
Mißissippi and Missißippi because any one of the three of them
might turn out to be the correct spelling.   As we have
discovered with other situations in which variant bundling has
been deployed, the combinations explode rather quickly -- the
registry is not limited to dealing with one extra label per
label that contains "ss".

> Also, this is such a simple substitution that a script could
> be written  to do it, or an option to do it automatically
> could even be included in  DNS resolvers. All this would make
> it much more likely that people would  do it.

Let me see if I can explain it this way, at the risk of making
Andrew and a few others hysterical even before they say "DNS2".
Let's assume that the DNS had, in additional to or instead of
DNAME and CNAME, a special MagicRemapping RR.  Its Data would be
another domain name, just like CNAME.  It would never appear in
a query and, again like CNAME, could be the only RR associated
with a given node.  If a query appeared for that node (for any
QTYPE) and a MagicRemapping record appeared at that node, the
client would get back, not an answer, but a special, dedicated,
error message that said "See this instead" with the name in the
DATA field.  The client would then be _required_ to repeat the
query with that string substituted.   There are a few additional
issues with how to specify this, especially in the context of
caching and the fact that we normally query for FQDNs, not
individual labels, but you get the point: This is a true,
string-substitution, alias, not a cross-tree pointer.  It would
not require delegation records, understanding of "below alias in
tree" relationships, etc.  And it cannot be done because it is
fundamental design choice -- one would either need to turn the
clock back to before 1034/1035 or forward to a radically
redesigned DNS2.

But, without that, "alias" turns out to be a complicated concept
for which mere string substitution doesn't do the job... unless
one is willing to have all of the strings thus generated produce
lame delegations or pointers back to the registry, which are
among the conditions your note assumes are to be avoided.

>...
> I am not closely acquainted with the technical details, but if
> two  domains are, in my terminology, "bundled", it means that
> they both  resolve to the same (set of) IP address(es) in all
> circumstances.

The difficulty, unfortunately, is that talking seriously about
"aliases" as a means of bundling requires understanding those
technical details.  The comments above are probably just a hint
because, as soon as you take the alternative of delegation
records to the same servers, there are issues about keeping the
zone files synchronized... and that is all of the zone files,
all the way down the tree from that node.

>> Cary and others may be able to calibrate this better, but my
>> understanding from discussions with various ccTLD operators
>> that sunrise procedures have been much more effective, much
>> more widely used, and _far_ less complicated to administer
>> than JET-like variant procedures, especially when there is a
>> reasonable expectation that one "form" and another may diverge
>> over time.
> 
> You mean give owners of domains in .gr six months to register
> the  final-sigma versions of their existing domains, should
> they choose to,  rather than enforce bundling? That sounds
> like it would be more  expensive in terms of administration
> and publicity.

Again, Cary or others who are closer to how those decisions have
worked out can comment if he note is not already clear, but I
would guess not.   Experience in other domains indicates that
maintaining bundled variants requires rather significant changes
to operational systems (note that the IETF-Standard
registrar-registry protocols do not support them).  By contrast,
handling an additional registration that has to be checked,
once, for its relationship to existing ones is fairly simple.
Publicity is another matter, but, because assigning extra names
to registrants would almost certainly require asking them, I
think one is stuck with that either way.

See Cary's note for the other aspects of this.  While some
domains have used variant-style bundling (more or less what you
are suggesting, but with fairly sophisticated determination of
what names are linked), it has always turned out to be more
complicated than most of those who say "bundling" seem to
realize.
 
>> Please also don't forget the fact that there are German and
>> Greek registrations in various gTLDs.  I don't know whether
>> the same principles would usefully apply, but I think we need
>> to at least consider the issue rather than assuming it is
>> limited to ccTLD registries whose primary language of
>> interest is Greek or German.
> 
> Of course. My view is that registries who don't want to break
> the world  for their customers using these characters will do
> the  search-and-augment (like a search-and-replace, but with
> additions :-) on  their zone files. Other ones will get
> shouted at when their customers  domains stop working in some
> browsers.

Except one then starts permitting, e.g., ß in strings that have
nothing to do with German and putting it in front of people who,
absent other clues and seeing what they expect to see, might
consider it visually confusable with Greek beta or even Latin
"b".  Solving the transition problem by making a gift to the
phishers does not seem to me to be optimal.

>...

    john




More information about the Idna-update mailing list