because at the time we hadn't figured out how to solve the various
problems associated with having multiple representations of
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?
No, but that would be a really lousy way to implement searching for
non-ASCII text in message headers. If I were implementing such
a search function, I'd build an index of decoded and canonicalized
header text rather than trying to match the query string against
the 2047 encoding.
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.
Copy and paste is also an issue for 2047. The only difference is that
since 2047 doesn't apply to addresses, but only to human-readable text,
a transliteration bug is less likely to cause your mail to go to the
wrong address. But such bugs do sometimes cause names or subjects to
But there are copy-and-paste issues even for ASCII URLs, due to %-encoding
(if you're copying from a poorly "decoded" form of the URL) and line
wrapping. Perhaps in hindsight URLs could have been designed differently.
But with so many people writing so many implementations of things that
handle URLs, subtleties tend to get overlooked by large numbers of
implementors. That's also the worst problem with doing IDNs, but it would
exist no matter what scheme were chosen.