ietf-822
[Top] [All Lists]

the gap regarding Archived-At

2004-10-28 13:38:43

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