okay, I find myself coming to some somewhat uncomfortable conclusions:
1. There really are significant differences between
a) how email clients would use archived-at,
b) how humans would use it to cut-and-paste into HTML, and
c) how web browsers would use it.
These differences are significant enough that I'm wondering if we
really do want separate archived-at fields for web use and email use,
or tags on the archived-at field that indicates whether the message
is in original format and/or if other messages in the same collection
can also be accessed.
2. For archived-at to be useful by email clients generally requires
one or two of the following, in addition to the obvious client
support for the protocol and server support for the message format:
- mail archives that support IMAP access (or possibly NNTP)
- a specification for making collections of mail messages available
via HTTP (maybe WebDav) and/or FTP
- mail archives that follow the aforementioned specification
and as much as I'd like to believe that email client vendors would
enthusiastically add support for these, market conditions don't seem
to favor supporting new functionality standards in email clients
right now.
3. The obvious compromise that makes sense in the short term (let
archives be in other formats besides message/rfc822, and don't
require message/rfc822 support) is harmful in the long term.
4. There's a real tendency for the web to degrade other services.
Partly this is because it's easy to prototype new services using
the web, and partly this is because once those services are
prototyped, the limitations of web browsers, HTTP, and HTML
impose a more significant barrier to the functionality that
can be supported than existed in the original environment.
Best compromise I see at this point: Define some sort of
keywords for archived-at. e.g.
Archived-at: "<" URI ">" *(";" keyword [ "=" value ] )
where keywords might include
"native" message available in native message/rfc822 format
(either because that's the only format available
at this URI or via content-negotiation)
"collection" other messages in the same collection are also
accessible, where the collection is defined by
the IMAP folder, NNTP newsgroup, FTP directory,
WebDav collection, etc. indicated by the URI.
the value associated with this keyword would
indicate the name of the collection associated
with the URI (since a message might appear in
more than one collection)
This would (a) let tools record locations of ordinary HTTP/HTML archives
such as are (too) often the only format available today, (b) encourage
archives to provide messages in their original format without requiring
them to do so, (c) give implementors a hint that better functionality
can be had, (d) give email readers a clue as to whether they could
actually make use of the URI internally or whether they needed to pass
it to a separate browser (this is a common problem in HTML also) and (e)
leave room for expanded functionality without needing to define a new
header field. And if you don't use any keywords, they don't take up
space.
It might be better to defer the definition of any keywords to a
separate document, because I can imagine needing to define specifics
of how collections look within the context of various protocols.
I can also imagine needing to define things like collections that
consist of a directory of several mbox files, each containing
multiple messages.
Keith