At 04:30 04/10/28, Bruce Lilly wrote:
>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 --
Yes, but can you forward more than one message in a single message?
>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.
The description above assumes worst-case scenarios. Many mail
clients these days make it very easy to click on an URI in header
or body. Operating systems are configured to invoke the right
application, depending on the URI scheme. And so on. The copy/paste
is still tedious, but I can assure you that it's a lot less
tedious with the Archived-At header than before, where one had
to hunt-and-peck through an archive to find the right mail.
>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,
Could you be a bit more specific here?
>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.
Sorry, but I don't get that. If the only thing desired is an URI,
you send the URI. The message is sent with the Archived-At because
the recipient wants to read the message, AND be able to put a link
to it in another mail or web page, or tell somebody else to look
at it.
>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.
One could, of course. But clicking on a link is so much
faster than having to find the right search page and copy/paste
the MID.
>I think you've made a start at identifying some uses.
I'm not concerned about identifying uses. I'm very sure
there are some good uses, because I'm using it daily,
as do other people such as Graham.
What we probably have made a start at is at getting you
to understand these uses.
>However,
>I'm still concerned about the imbalance between the rather
>limited utility within the framework
Within what 'framework'? The framework for IETF specs is
the Internet, and in that framework, it's definitely very
usable.
>(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
Could you be more specific about this?
>and implementations and the security issues.
I'll reply to these separately.
Regards, Martin.