>> So what Martins draft needs to say is something like "If the scheme
of the
>> URI is 'http', then the entity that is returned SHOULD have the
>> Content-Type message/rfc822".
>
>Maybe. I'd like to encourage more archives to support native format
access. I do think it' s reasonable for a standard for accessing mail
archives to behave predictably (as in, provide some minimum format for
the sake of interoperability), and that it's reasonable to give mail
readers the message in a format that they can use. I'm concerned that
simply saying "SHOULD use 822" will alienate those that don't.
"SHOULD provide 822; MAY provide HTML or other formats if the access
protocol supports content-negotiation seems about right to me.
As explained in my answer to Charles, I don't want to recommend stuff
that I haven't seen implemented.
The reason you haven't seen it implemented is that you are looking at
archives with web browsers. Internet email readers don't currently
have a way of accessing archives (except perhaps for read-only IMAP),
so there aren't many archives that are set up for use by email readers.
But all internet email readers support message/rfc822 to some degree,
whereas not all of them support HTML or other formats.
I think making messages available as
message/rfc822 is a great idea at least on paper, but in W3Cs case,
things are currently working quite well with serving the messages
just as HTML,
Apparently you don't expect much from email archives. IMHO you should
be able to do anything with an archived message that you can do with a
message you received in your inbox - read it with any mail reader,
reply to it, forward it (as a message) to somewhere else, search it as
if it were a message, display or save any of its body parts, follow
threads to other messages (including those in your inbox), etc. In
addition, HTML has proven to be a poor format for use in email because
of numerous security risks associated with scripts, objects, and
referenced images along with the expectation that these are invoked or
displayed without user consent.
If you are designing a way to allow email messages to reference
archives, it makes good sense to make those messages usable by email
readers.
and I don't want to give potential users the impression
that they have to support message/rfc822 or they better won't use
Archived-At at all.
That's very close to the the impression that they should get. More
precisely:
a) those who use archived-at should take pains to archive their
messages faithfully (meaning in the original format) and in such a way
as to be readable by the vast majority of mail readers (i.e. in
message/rfc822), and
b) If you want interoperability the last thing you want to do is to
burden email readers with having to support arbitrary formats for
archived messages.