Re: [idn] WG last call summary

[Keith Moore <moore@cs.utk.edu>]

> > 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?

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 
be garbled.

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.  

Keith