Keith Moore wrote:
that may be the only thing *you* care about, but DSNs were designed to
provide a partial response (i.e. the best indication that could
be provided) even if the destination mailer doesn't support them.
Part of my argument is that they were designed that way *partially*
because the current envelope-exchange environment requires it.
I don't really think so. One of the things I (and several other folks)
didn't like about the return-receipt-to header behavior is that it wasn't
reliable - you couldn't simply add the header field and expect it to
give you a notificaiton.
We need a new message format if we want to allow UTF-8 directly in
the message headers.
provides no benefit to users besides minimal bandwidth savings.
You don't think UTF-8 in Received header fields would benefit admins who
have to deal with email from International sources?
let's put it this way - I get a lot of spam from international sources,
and the domain names in the received headers aren't very useful as it
is. how much more useful will they be in utf-8? they'll just be more
varied and less likely to be understood. and the domain names are about
the only parts of a received field that could make use of utf-8.
Using something like the XML structured approach, it is simple enough to
define all recipients as groups:
<PrimaryRecipient>
<DisplayName>Local Admins</DisplayName>
<Mailbox>fred(_at_)local</Mailbox>
<Mailbox>joe(_at_)remote</Mailbox>
</PrimaryRecipient>
that's just great. you've more than doubled the amount of space that
this one header would require, you haven't added a shred of functionality,
and you've made headers considerably more difficult to read than at present.
This doesn't even take into consideration the multitude of codecs
and encoding forms that people have to deploy.
if the folks doing audio and video can't agree on a small number of
I'm talking about header field codecs. 2047, 2231, etc.
I agree that it would be better if message headers had been designed
from the start being able to transmit arbitrary content transparently,
but the number of encoders/decoders that we're likely to see is
somewhat less than a multitude. And I'd far rather have to deal with
a small number of these frobs than to replace the entire mail system
and have to suffer through all of this transition pain again.
(yes, again - some of us have already had to suffer through transitions
from uucp, mail-11, bitnet, multiple flavors of x.400, all-for-nothing,
notes, etc.)
Flowing and quoting in body parts would be nice, and would be easier
first, someone needs to demonstrate that it can be made to work well
by defining a new content-type (or a variant of an existing
content-type) that does this. once that's done, there's no need for a
new message format.
Whether or not it needs (or benefits from) a new message depends on the
necessary support services. You can do both of those today with HTML if
you are willing to live in the current framework.
you can display this stuff with HTML. however I've yet to see an effective
interface for replying to an HTML message while editing the previous message
to remove extraneous parts, adding additional text, and keeping straight
which parts were from earlier messages. (granted I don't play with Windows
or Mac software very often, so it's possible that one exists that I haven't
seen)
Keith