Re: Transport Protocol vs. Message Format

At 18:33 04/02/26 +1100, Brett Watson wrote:

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

First, you can, with the mailto: URI function you describe below.
See e.g. http://lists.w3.org/Archives/Public/public-ietf-w3c/2004Feb/0000.html
for an example (look for "Respond" at the top, and please try this out,
but stop short before actually hitting the SEND button). We include
Subject, In-Reply-To, and References headers, but no other headers,
and no body (which you would have to copy, but that's not that a big
deal).


And by the way, one reason I'm talking about this here is that I recently
have written draft-duerst-archived-at-00.txt, and have received some
comments in directions similar to the ones here about message/rfc822.
For discussions of that draft, please use the [email protected] mailing
list (and copy me!).


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

That's a really phony answer.


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

Yes. There are various practical problems, such as length issues
and internationalization issues, for this to work fully, but in theory
and for simple examples or with some limitations, it's easy to make
it work (see above).


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

There is nothing in the current design and standards that would in
any way inhibit this. For practical reasons, you could do both
content negotiation as well as have a link on the HTML page to
a specific URI for the message/rfc822 format.

I.e. http://www.example.com/archive/mylist/timespan/0123
would be the generic reference (for which a browser would get back
text/html because it obviously is better at dealing with HTML than
with message/rfc822),
http://www.example.com/archive/mylist/timespan/0123.html
is the non-negotiated message in HTML form, and
http://www.example.com/archive/mylist/timespan/0123.msg
(or whatever that extension is) is the message/rfc822 form.

There is obviously no need to change the browser, you just need
to configure it. What is needed is archives that offer data this
way, and MUAs that can be invoked this way. If you are interested
in this functionality, I suggest you start implementing. Adding
it e.g. to hypermail (http://www.hypermail.org/) should be rather
straightforward.

And there is obviously also no need to make the message/rfc822
format the only format returned; for many purposes (in particular
browsing the archive), HTML usually works much better.


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

None of the browsers should have to do that natively. And all browsers
come with configurations for dealing with arbitrary content types,
to invoke plugins or external applications. So the browsers are really
not the problem.

[There are lots of things that in the long term could be different
from today's browsers and MUAs, and how they are integrated, and
of course this list is very much about such long term things,
but for the short term, if you want this functionality, you should
start with mailing list archive software and MUAs.]


Regards,    Martin.