At 12:29 04/02/26, Charles Lindsey wrote:
>Keith Moore writes:
>>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.
>I think the problem you are raising is a generic URI problem, and not just
>a problem with this particular header.
>AIUI, a URI gives you access to a "resource"; i.e. it tells you where to
>find it. It tells you nothing about what to do with it when you have got
>it, except what is implicit in the "scheme".
Yes. In many contexts, that's considered a feature. For example, it allows
to serve the same content in a new format from the same location.
>Now one of the possible benefits of the 'http' scheme is that the object
>that comes back should have a Content-Type header. And what we want is for
>this Content-Type to be message/rfc822.
>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". Then whatever system asked for the
>Archived-At object to be retrieved has a decent chance of being able to
>display and process it like an email.
I don't think my draft should say anything normatively about what
should come back. Saying that it should be message/rfc822 would be
against something like 100% of current practice and running code.
I don't think that it's a bad idea, quite to the contrary, but with
(as far as I know) currently 0 email messages served that way, and
(again as far as I know) 0 email agents able to get such a message
and then use it e.g. to reply to it, I think it would be strongly
against the IETF principles to require or recommend this.
>>Either way, this document probably needs to say some things about
It now does; I have added a section talking about formats of an
archived message, and mentioned message/rfc822 as well as HTML,
plain text, and content negotiation.
>>- 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
>You can't really give detailed instructions in a standard about how
>individual readers or browsers are supposed to behave. The general
>intention is that all readers/browsers that recognize Content-Type headers
>are supposed to use the best available tool for handling that Content-Type
>(possibly even using a special plugin). Naturally, some current systems
>make a better job of this than others :-( .
I agree with Charles here.