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.