At 19:05 04/02/26, Keith Moore wrote:
>> 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. 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, 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.
>>> - 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.
>>
>> You can't really give detailed instructions in a standard about how
>> individual readers or browsers are supposed to behave.
>
>no, but I don't think a paragraph or two is too much.
There is now some text about formats in the draft, although that's
mostly about that (and how) different formats can be returned.
I really don't want to add something like "hey, if it's HTML,
you better show that in a browser" or so, because it really sounds
too trivial, and implementations usually get it right anyway.
Regards, Martin.