Nathaniel Borenstein wrote:
-- internationalization, esp. of addresses
This is a problem that has to be solved in the Internet Mail framework,
too. I don't consider this to be a primary goal, Hopefully it's
possible to separate the core protocols from higher-layer issues such as
address presentation.
-- enhanced tracing mechanisms
I don't think tracing is *that* important. It works rather well
already, as long as we stay within the mail domain. The trouble starts
when a media boundary is crossed (regular SMTP server vs. trojan mail
relay), and this is not something that can be cured within the system.
-- generalized challenge/response mechanisms
-- structured local-part syntax
-- transport-level authentication
-- Cleaner separation of header, envelope, and body
-- economic mechanisms (postage, attention bonds)
This are technical details; I don't really see their immediate
importance per se. I guess some of them need some infrastructure
support and can be built on top of the core protocols.
-- binary transport (phasing out C-T-E's)
Okay, I agree. This is one of the technical issues that I think is
worthwhile to address because it's rather obvious that many applications
need it. The following is in the same category:
-- partial retransmit of incomplete messages
This is crucial for a binary transport protocol.
-- transmission and delivery in a distributed transaction
The idea is to prevent duplicate messages as well as lost ones (nowadays
a minor wart of SMTP).
On the more non-technical side, I'd love to see the following:
-- signal delivery problems as soon as the mail is sent
This means that I get an error message as soon as a hit the "Send"
button, independent of message size and destination. At this time,
warning messages should be displayed, too (remote site unreachable,
receiver is out of office). I think this is an important feature from a
user perspective. Better error handling can help the network as a whole
because it tends to reduce the number of messages in transit.
There are two likely consequences if we adopted this goal:
-- favor connected over disconnected operation
-- separate routing/signaling from transport
The first part is quite controversial, of course. However, I don't
think it's a good idea to optimize for disconnected operation at this
time. The number of users who write messages off-line *and* have some
mechanism for unattended, automatic delivery (e.g. period UUCP call-out)
is negligible; it doesn't make sense to optimize the protocol for them.
Most off-line message composers explicitly trigger and attend the
dial-out operation that delivers their email.
A separate routing protocol adds a lot of complexity, but I think we
need it, for better error handling, load balancing and more efficient
forwarding (by re-routing the message to the new destination, especially
important if we support binary transport).