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/