Re: Why are we here? What are our goals?

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).