Re: Transport Protocol vs. Message Format

[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