At 08:15 23/02/04 -0500, Keith Moore wrote:
There are limits on what you can do with HTML and HTTP. Being able to
access the archived message from IMAP is potentially a lot better, but
(as with many things) even IMAP needs some tweaking to make it work well
for this.
How many people actually use IMAP? (I don't.)
why does it matter what they use to read their mail, as long as the right
thing happens when they click on an IMAP URI?
lots of MUAs do support IMAP. whether they support the ability to
reference messages via IMAP URLs is a different question.
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?
(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.)
#g
--
[1] http://www.ietf.org/rfc/rfc3205.txt
------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact