Standards and localization (was Dot-mapping)

[John C Klensin]

--On Saturday, 08 December, 2007 09:04 -0800 Erik van der Poel
<erikv at google.com> wrote:

> John,
> 
> There certainly is a danger, but I don't think it's limited to
> the non-ASCII dots, nor would I draw the same conclusion.
> 
> If we had the string mit.edu in an email, where the 'm' was
> full-width and .edu was operated by an unscrupulous or
> error-prone registry operator, cutting and pasting that string
> into an IDNA-unaware browser would take the user to the wrong
> MIT.
>...
 
Erik,

I tend to agree with Gervase -- there is little point in going
over the spoofing problems again unless someone has something
new to say.  

But the dot problem is a very special case (it is no accident
that the conversion/matching rule is a special case in 3490 and
not, e.g., part of nameprep).  _All_ other pieces of the IDNA
puzzle are transparent to competently-written software that is
not IDNA-aware.      Either those systems "see" the A-labels
(punycode) or they see some sequence of octets (for which RFC
2181 specifies and clarifies handling).  But variant periods
require than software that is not IDNA-aware be IDNA-aware to
parse the domain names into labels.  

To preserve them as something that can be passed between
systems, we need to retrofit the entire structure that is based
on the DNS.  That is not about spoofing, or registry behavior,
or bad guys, although it opens up some possibilities for them.
It is about the fundamentals of DNS interoperability and
interoperability of IDNA with the DNS.

I also note that those dots in IDNA2003 are the only reason why
the protocol needs to deal with full domain names at all and not
just with labels.   That added bit of complexity is probably
something we should have spotted as a warning sign, but, for
whatever reason, we didn't do so until now.

    john