mail archives won't get better without specifications for how to make
them better.
I feel as if we're each missing the other's point. Mine was two-fold:
(a) that a new facility that depended on IMAP might not be easy to get
deployed. Maybe. I was asking a question rather than making an
assertion.
(b) that I didn't see the need for any fundamental change to
draft-duerst-archived-at-00.txt to allow IMAP to used in conjunction
with the new header.
So it seems I'm missing something in your position that makes mention
of IMAP important to this specification?
Let me put it another way.
1. I really don't think we should standardize a header field pointer to
mail archives that depends on HTML and HTTP.
2. IMAP seems like the best protocol available for the purpose of
accessing mail archives, so I think that IMAP should be cited in
any standard for such archives.
3. However, I don't think that we should limit such a standard to be
used exclusively with IMAP or any other protocol. Clearly it's much
easier to deploy HTTP archvies than IMAP archives.
There's a conflict between what is easy to deploy and what would be
a desirable state to encourage. I don't want to insist that we only
approve a header that works in that more desirable state - I just
want to make sure there's a clear upgrade path to that more desirable
state.
(Also, RFC3205 [1] notwithstanding, I do tend to wonder what it is
that IMAP offers in this context that isn't performed equally well
using an HTTP-based implementation. With respect to section 2.5 of
RFC 3205, HTTP seems pretty appropriate on all counts, given that most
email archives are accessed today using HTTP. Accessing email
archives seems to be a function that fits right into HTTP's core
competence.)
HTML archives of mail suck, for reasons that RFC 3205 didn't even begin
to touch on. You don't want to have to use a different interface to read
mail achives than to read ordinary mail. You want the same kinds of
sorting, searching, (re)filing, address book handling, annotation,
replying, etc. available to mail archived elsewhere as for your personal
mail archives. HTTP could be used as a mailbox access protocol, but
it lacks most of the features needed - it is less functional than POP
for that purpose.
Here are some problems with using HTTP to access mail archives:
- Most MUAs don't know how to access messages using HTTP, which pretty
much limits access to web browsers. See below.
- There are no conventions for the mapping of HTTP URLs onto commonly
understood abstractions for groups of email messages such as
folders. There is no way to list all messages in a folder, or to
search through a folder for messages matching a particular pattern,
etc. WEBDAV might provide some of the missing functionality,
but it still needs to be defined how to use it for email.
Here are some problems with representing mail messages in HTML:
- it discards the fact that the resource was a mail message
- it translates valuable semantic content into mere text
(more specific examples below)
- mail readers won't know what to do with it other than to display it.
they can't reply to it, refile it, etc.
- server-side mail interfaces are slow, and cannot take advantage
of client-side context such as address books, preferences for
how outgoing mail is sent, how replies are composed, etc.
- can't do duplicate message suppression when the same message
appears from multiple sources