Graham,
I think the answer is that something else has been bugging me about this
proposal that I'm only starting to get a handle on. I got some more
idea about it this morning when I woke up.
As I was saying earlier, there's something perverse in asking an email
reader to fire up a web browser to read an email message. Part of the
reason that this is perverse, of course, is that the email reader is
tailor-made to do things with email messages and the web browser is not.
Unless the MUA and web browser are very tightly coupled (which seems to
be the case less often these days) this seems like a suboptimal
arrangement.
And yes, HTTP can be used to download email messages, and HTTP content
negotiation can be used to allow a mail user agent to pick between
getting the message in message/rfc822 format and text/html format (or
some other format). If the message is in rfc822 format it should stay
in the mail reader; if it's in html format it should probably go to the
web browser (Just like web browsers make poor mail readers; mail readers
make poor web browsers. Even if they support HTML they probably don't
support scripting, tabs, cookie management, security, history - things
that we have come to expect in order to use the web effectively, even
to read email archives). But at the time the MUA decides what to do
with the URI, it doesn't know whether it should download the message
itself or hand it off to a web browser.
So I'm currently thinking that Archived-At needs to supply more
information: namely the content types that are available. An
alternative might be to use a HEAD request to find out what
content-types are available.
Either way, this document probably needs to say some things about
- use of different representations of email messages, with native
(message/rfc822) format being strongly encouraged as the primary
format and HTML as a useful alternative.
- use of HTTP vs. IMAP (maybe also mentioning POP or even NNTP)
as an access protocol
- how a mail reader (or for that matter a web browser) should decide
whether to handle the message itself or hand it off to a different
tool.
- (maybe) organization of mail archives.
Some of this I understand Martin has already written, but I haven't
seen the revised document yet.
You asked me to comment on specific text that you suggested. The reason
I didn't do so was because I sensed that the issues needed more thought
and that it was premature to try to write specific text.
I do accept that there's a limit to how far this document should try to
go to address these issues - this is after all a document about a new
header field, not about how to set up email archives. My guess is that
about one paragraph for each of the above points is about right.
We could of course write a separate document on the subject of mail
archives, and perhaps we should. But we don't want to hold up this
document waiting for a recommendation for mail archives that we can
agree on.
I think there's a real danger that your quest for something else will
impede the standardization of a Really Useful Feature, for which there
is running code. I think I have heard you subscribe to the idea that
the best is the enemy of the good in standards development ... I think
this could be a shining case in point.
I don't think it's too much to ask to discuss a Really Useful Feature
for a few days to try to understand its broader implications before we
try to promote some particular way of implementing it. Email header
fields are a data model, and there's a large body of experience that
data models are really difficult to get right. We want standards to be
stable, and we want them to be flexible enough to use for a long time.
We're not going to get that by standardizing the first idea that comes
to mind -- even if it's easy to implement and there's running code and
that running code is found to have some utility.
It may be that we place too much emphasis on running code. Any
programmer who has been around for a few years knows that a lot of code
that is "running" - maybe most of it - even if it is found to be useful,
often has a slapdash quality that won't necessarily hold up to the
strain of widespread use. Also there's an important difference between
running code in the form of a prototype and running code that implements
a well-designed specification. The prototype is useful as a
proof-of-concept and to identify flaws in the initial design, but it's
rarely suitable for widespread deployment. The running code that IETF
demands as a condition of advancement to Draft Standard serves a
different purpose - it is a check on the clarity and precision of the
specification, and that implementation is not too onerous.
--
He not busy being born, is busy dying. - Bob Dylan