Re: [idn] WG last call summary

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

Keith Moore wrote:

> because at the time we hadn't figured out how to solve the various
> problems associated with having multiple representations of
> machine-readable text.
> 
> today we have a much better idea for how to do that.

At least IDNA only has one conversion form. Still, the point is valid that
something as precise and scope-limited as 2047 only worked well within the
scope it was intended for, namely presentation of unstructured header
fields within a specific service. I mean, I don't know of any email
clients that perform 2047 encoding on search string input, do you?

> I agree with Dave that IDNA is very similar to things we did with MIME
> in both the header and the message body

The notion of transliterate-for-display-so-we-don't-upgrade is similar,
but the scopes are completely different. If you are using a 2047-capable
email client, copy-n-paste between From: and To: is practically guaranteed
to work out. But all IDN approaches introduce copy-n-paste between web
browsers, email clients, WHOIS clients, ad nauseum. That also introduces
all kinds of other issues, like, "is that i18n URL I copied actually a
legal URL? [not today, no]" That's why this is closer to IPv6 than MIME.

Just to be clear, my position on this subject remains that IDNA is a
necessary and useful transfer encoding for legacy systems that need access
to i18n domain name data, but that the mandatory transliteration of all
domain names as any kind of solution to the problem is just reckless.
These problems won't go away until they are accepted and designed for.

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