The discussion to date hasn't really addressed a or c, it
has focused on b.
I'm not sure why you think that. I've addressed a on more than one
occasion.
1. Comments: archived at
http://www.imc.org/ietf-822/mail-archive/msg05043.html
The Comments field has been around since at least RFC 724
and therefore is more likely to be displayed by existing MUAs
than Archived-At. A message may contain an arbitrary
number of Comments fields. However, it does not solve the
problem of the incompatibility with RFC 2046 message/partial.
could you explain that supposed incompatibility again? not that I'm
really worried about it as (a) I haven't seen a message/partial since
the early 1990s (even then it was only as a test) and (b) somehow I
doubt that most MUAs can reassemble message/partials anyway.
Both methods use existing mechanisms explicitly designed for human
use. As both methods involve content which is not subject to
automatic retrieval of content, both avoid the security trap
implicit in (possibly automated use of) Archived-At.
I don't see why in the world an MUA would download the URI in an
Archived-At field, because it already has the message on hand. (no, I
don't consider message/partial a threat in this regard).
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.
That information may be implicit in the specific URI scheme indicated.
yes, it might - but generally, it's not implicit in the URI scheme.
An imap scheme certainly indicates that the format is message/rfc822
I've certainly seen IMAP servers that would provide arbitrary contents.
Whether that was a bug or a feature, I was never sure.
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)
Accessing such an archive requires access credentials, which
would have to be communicated (probably possible within
the URI).
IIRC, IMAP was specifically designed to be able to provide read-only
access to archives. But it's been awhile.
- a specification for making collections of mail messages available
via HTTP (maybe WebDav) and/or FTP
multipart/digest is an existing media type, which can be
transferred via HTTP and/or ftp, which *is* a collection
of messages.
yup, but as an archive format, it's pretty pessimal. you can't easily
locate a particular message within the file, nor can you append new
messages to the file. that might be why nobody uses it for that
purpose. (okay, it's a big Internet. _somebody_ might use it)
[...]
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.
There may be a more fundamental issue: IMAP (or NNTP) access
requires either handling a URI or configuration of the necessary
parameters which would be conveyed in a URI (host name, port,
user credentials). Certainly MUAs that provide IMAP client
functionality could be used without any additional design, but
the user would need to get the parameters from somewhere and
configure his MUA(s) accordingly. MUAs don't typically handle
generic URIs directly (mailto URIs are a notable exception), but
instead may hand them off to a browser (which in turn might
invoke an MUA for an imap scheme URI).
Parsing an IMAP URI is not rocket science, and doesn't need more than a
couple of hundred lines of code. Somehow I don't think this is the
limiting factor.
(Actually I think that all MUAs should allow their mailboxes and
submission servers to be specified using URLs - it's much simpler and
less error-prone than giving users lots of blanks with misleading
labels to fill in.)
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
[...]
"collection" other messages in the same collection are also
[...]
I think the issue of a list of URIs might be revisited (and not
necessarily in a structured field), so that multiple access
methods to a given message could be specified (that does
not preclude multiple fields to indicate multiple places where
copies may be archived, except of course if comments in the
Message-ID field are used).
I don't see the point in specifying multiple ways to do the same thing.
There's a good argument for allowing multiple Archived-At fields
because the originator, the recipient's MTA, and any number of
intermediaries might archive a message - it's much cleaner to just let
each of them add a separate field. Given that I don't see any need to
have multiple URIs within a field also.
And if you don't use any keywords, they don't take up
space.
The code needed to parse them takes space in the MUA.
only for MUAs that care about them. as for RFC 2231, I agree that they
can get ugly, but I think this will be rare. and the MUA ought to have
code to handle RFC 2231 anyway.
Keith