[snip interesting stuff]
In this mode of operation, the distinction between Transport Protocol
and Message Format becomes crystal clear. There must be a sharp line
drawn between the message and the method of delivery, such that the
message is independent of the method of delivery.
[drawing on some discussions on ietf-822]
Indeed, independent of its context. You could encounter data tagged as
(e.g.) "message/mail-ng" at the end of any URI and make sense of it.
Then the mail transport problem could look a lot like "passing around
lists of URIs", "retrieving URIs" and possibly "cacheing the contents of
URIs" (you could almost envisage NNTP-ish "IHAVE" conversations as the
initial transport, followed by URI-chasing to get contents. If you
actually prefer to pass the data in-line as happens today in SMTP, you
can always use the "same document" stuff in URIs).
Its an interesting viewpoint and may provide another way to look at the
online/offline instant messaging/store-and-forward and single/multihop
discussions (let alone message-ids, list archives, use bittorrent-like
technology to get your mailing list traffic, etc etc).
There are still many arguments worth having over demarcation, and
whether any given function is better performed in one component or the
other. For example, should "delivery confirmation" be a transport
function, or should it be represented as a special message? It's a bit
of both at the moment, and that's arguably a problem.
Well, in the above view, the definition of delivery would be split into:
a - informed recipients' system that a mail is ready to be pulled (passed
URI, "notified"?)
b - the mail has been pulled by an entity bearing the credentials of the
recip ("delivery" - this would be of interest to the sender I guess)
jb