Re: [idn] WG last call summary

["Eric A. Hall" <ehall@ehsco.com>]

Dave Crocker wrote:

> The transition issues for IDNA that actually pertain to Internet
> protocol behavior have been described repeatedly and are identical
> with the kind of changes that were required to adopt MIME.

I can see why you'd want to say that, but it's a poor analogy.

MIME imposed structure on unstructured data by using a subset of values,
and specifically limiting itself to particular technologies. I mean, even
RFC2047 only allowed some particular kinds of data (mostly unstructured)
to be extended, and marked structured data as off-limits. Conversely, IDNA
modifies structured data-elements, and applies to all technologies.
Resistance is futile, you will be transliterated.

A much better analogy for IDNs in general is IPv6, where every
participating protocol, data-element and application that uses the
previous data-format has to be modified if it wants to use the new
data-format. But since IDNA seeks to avoid these costs, in the end, the
protocols, data-elements and applications don't actually obtain any real
benefits from internationalization; it's all just a facade, taped onto the
surface of the Internet, sometimes in harmful ways given the artifacts of
mandatory transliteration. In this regard, the best analogy would be what
IPv6 *DIDN'T* do: pass IPv6 inside of IPv4 options and call the work
finished. That's pretty much what IDNA does.

As for breakage, it will undoubtedly occur, including in those places that
Dan mentions, but it will also happen inside protocols and namespaces.
Message-IDs will absolutely get corrupted and reinserted into the
messaging system, Kerberos and NetBIOS will get broken and then get panic
fixes, etc.

> The example given had nothing to do with Internet protocols, but rather
> with how to transition the software on a computer system to support a
> richer set of characters.  That is, of course, an interesting problem,
> but it is not part of IETF scope.

Dan's argument is actually the easiest to deal with, since it can be
addressed with the judicious and cautious use of "MAY" along with the
appropriate warnings.

Extending all known data-structures which happen to make use of DNS domain
names as key elements is the larger problem, and it is certainly within
the scope of the IETF.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/