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.
yes it's a generic problem with URIs (or to look at it a different way,
a design choice made for URIs)
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".
some would say that making assumptions about the nature of the resource
based on the "scheme" is a bad idea.
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.
- 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.
Keith