On Wed October 27 2004 13:38, Keith Moore wrote:
1. I can certainly see using this field as providing a way to pass
along a message to others (who might not have received a copy of the
message) without actually having to send them a copy. Instead of
forwarding the message to them, paste the URL into the message text.
Well I suppose it is possible. It sure sounds like a heck of a lot of
effort compared to simply invoking a "forward message" function
in an MUA -- first convince the MUA to display the Archived-At
field, then select the text (w/o the angle brackets) and copy it
somewhere, start composition of a new message, paste the copied
URI text into the message body (if possible; one may have to resort
to re-keyboarding it), edit the URI if it was line-folded in the field,
fill out the message header fields, add text explaining that the copied
text is a URI, then send the message. At the receiving end, the
recipient will have to go through similar contortions to make use of
that URI -- figure out what the URI means, undo any line folding,
quoted-printable encoding, etc., guess what application might
support the particular scheme, fire up an instance of that
application, copy and paste (or re-keyboard) the URI into that
application. And to make use of the retrieved message -- assuming
that everything has worked flawlessly up to that point, that
application may have to save the message to a file and the user
may have to open or import that file in an MUA to make use of it.
2. Another thing that would be extremely useful is to be able to see a
message in context - in relation to other messages in the same
discussion. So if an archive points to a message in a read-only IMAP
mailbox, the context could be supplied by other messages in that
mailbox. Or if an archive points to a HTML document on an HTTP server,
the context could be supplied by "next in thread" style links. In this
case the Archived-at field serves as much to point to a collection
of messages as to a particular message within that collection.
Yes, context is useful, but that context is provided by the
related messages and the archive infrastructure (or, if I have
access to the messages in an MUA, by that MUAs features).
List-Archive can point to such an archive. Nor is Archived-At
necessary to get a starting point at a particular message;
a URI could be obtained from any suitable mechanism, and
since Archived-At is defined only for a specific message, it
seems rather wasteful to send an entire message if the only
thing desired is a URI. There are also other ways to
identify a particular message; given that message's
msg-id, one could find it in the archive via IMAP's (or
some archive interface's) search function, possibly
directly via an MID URI.
I think you've made a start at identifying some uses. However,
I'm still concerned about the imbalance between the rather
limited utility within the framework (viz. Archived-At is only
available when the entire message is available (excluding the
unusual combination of circumstances mentioned earlier today))
vs. the incompatibility with the existing message/partial
fragmentation/reassembly algorithm and implementations
and the security issues.