<< Beyond that, I'd prefer to see us concentrate on ways to avoid this
<< problem until and unless we see a real requirement. "Users want to"
<< doesn't carry a lot of weight with me here--users want DWIM behavior all
<< over the place, even if that implies deducing that the same uttered
<< sentence means radically things on different days, depending only on
<< their subconscious state.
< 1) We should be able to do something about problems we see _before_ the
< situation gets so bad that users begin to complain loudly.
I know of at least one commercial email vendor who already has paying
commercial (and international) customers requiring this in a future release
of their service. I'd much rather that there were a method in place before
this email vendor has to come up with its own methods. I know that this
email vendor WILL be doing this at some point; the only question is how.
How's that for a "real requirement"?
(Given a lack of direction from the ietf, this email vendor may very well go
the route of using rfc 1342 for addresses; I don't know. This same vendor
has been providing multipart and binary message support for years, and it's
now faced with back tracking to support MIME. The problem is that the market
demand is there, and the needs WILL be filled, but without standards,
creativity is a must.)
Tony Hansen
hansen(_at_)pegasus(_dot_)att(_dot_)com,
tony(_at_)attmail(_dot_)com
att!pegasus!hansen, attmail!tony