Re: Problems of Internationalized Mail Address eXtensions (IMAX)

[...]
   > Won't care? _Won't care_?

   Yes, won't care.  The difference between <display-name> and <addr-spec>
   (using the constructs from Section 3.4 of RFC 2822) is that the former
   is unambiguously user text (in the RFC 2277 sense) and the latter can be
   treated much more like a protocol element.  I agree that it is nice to
   often be able to guess usernames or use heuristics about their meaning,
   but it's not necessary.  (One could argue that it would also be nice to
   know what MAIL FROM or Content-Disposition means in your native tongue
   rather than treating them as abstract protocol elements, which they
   obviously are.)

E-mail administrators are frequently looking at logs to track what
happened to certain e-mail messages. They're given e-mail addresses
like "bob sent this" or "joe was expecting this".

Any MTA that didn't give facilities to do this sort of tracking
(either through a program or reading logs or whatever) is clearly
substandard. MTAs written after Punycode or whatever has come into
widespread use would have to decode it for administrators, because
administrators will not be given Punycode addresses by users. (Well,
maybe sometime they will? But one hopes not by non-technical users.)

It is silly to think that administrators can do their job effectively
by treating them as "abstract protocol elements".

MTA administrators dealing with addresses outside their native
language/alphabet may well prefer to deal with Punycode
addresses. Designing a usable system for an administrator to deal with
many languages/scripts is probably pretty hard.

Now, this fact doesn't mean that we _have_ to use UTF-8 in SMTP or in
message headers. It just means that MTAs and other internal
infrastructure _will_ become aware of any encodings.

Larry