Transport Protocol vs. Message Format

The message to which this is a followup contains many astute and pertinent 
observations by Markus Stumpf and Bruce Lilly: if I were to quote the 
important parts, I'd repeat 90% of the message, so I'll spare you that. 
Instead, to elaborate on the significance of the message, I'll pose a 
specific question, and then answer it by showing how it rests on a general 
principle.

"Why can't I reply to an email presented to me on a web page?"

It's a fair question, and one I face every time I want to reply to a message 
that I've read on the web-archive of a mailing list (which happens often 
enough). The most accurate answer I can think of for this question is as 
follows.

"The message has been translated into HTML, and has lost its essential email 
properties. Despite the fact that it is presented on the computer screen in a 
manner similar to that used by your MUA, replying to such an email is little 
different from replying to a paper print-out of an email."

It's slightly better than replying to a printed-out email, because I have 
better cut-and-paste facilities between my browser and MUA than I do between 
the MUA and a piece of paper, but that's about the end of it.

If we wanted to improve on this situation, there are two approaches we could 
take. The first and (IMHO) lesser approach is to do a better job of 
email-to-HTML translation. We already have the "mailto:" URI (RFC 2368) which 
allows the MUA to be invoked from an HTML page with a complete draft message 
loaded and ready in exactly the same way that the MUA's own "reply" function 
works. So long as the browser is willing to respect the "In-Reply-To:" field 
(and maybe others: see RFC 2368, section 4), the effect of using an 
appropriately-constructed "mailto:" URI could be indistinguishable from a 
"genuine" reply. Interesting, no?

But this is really a cheat. We are effectively constructing a response 
template and storing it in a URI on the page. There is duplication of 
information here: the human-readable view of the message, and the 
machine-readable reply template stashed in the "mailto:" URI. In an ideal 
world, your browser would be sent (and handle appropriately) the original 
email itself, in MIME type message/rfc822, rather than a translation of that 
document into text/html or similar. Upon receipt of such a document, a 
browser ought to invoke an MUA message viewer component (perhaps in embedded 
mode) in much the same way it would invoke a PDF viewer for the 
application/pdf MIME type.

So this brings us to the distinction between Transport Protocol and Message 
Format: a distinction which has been a reasonably well-established principle 
in mail since at least RFCs 821 and 822, but arguably never exploited to its 
full potential. The previous paragraph concludes with a 
trivially-implementable instance of message/rfc822 over HTTP, which is not a 
replacement for 822 over SMTP, but would be a very useful thing in its own 
right if the idea were supported in browsers today. (None of the browsers 
I've seen know how to handle message/rfc822 when presented with it.) 
Conversely, you can't transport anything over SMTP *except* message/rfc822 -- 
a limitation which has been overcome in practice by extending message/rfc822 
into a wrapper for arbitrary sub-types.

Now let me stretch your imagination just a little further. Dispose entirely of 
SMTP and traditional MUAs from your mind at the moment, and consider how some 
browsers allow you to browse through more abstract things than an HTML 
document. Many allow you to navigate a local filesystem hierarchy, or a 
remote FTP hierarchy, for example, although the metadata associated with the 
contents of these things will vary. Imagine that the browser also allowed you 
to navigate through a storage hierarchy that looked a lot like a filesystem 
(local or remote), but also included sender and recipient mail addresses for 
each item. Such a repository could store any kind of data type, including 
(but not limited to) message/rfc822.

That is what I believe mail-ng looks like, from the user's perspective.

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