Hello Bruce,
At 23:07 04/10/27, Bruce Lilly wrote:
>On Tue October 26 2004 18:05, Keith Moore wrote:
>
>> Or a least, if a message is going to point to an
>> archive of itself, it should be a faithful archive.
>
>That raises several new issues with Martin's draft. They can be
>summarized as "what is the utility of the proposed field; who
>will use it, under what circumstances, and for what purpose(s)?".
>Note that that is not a question about syntax, or about semantics,
>or about validity, but about utility.
>
>I also discuss a security issue towards the end of this message.
>
>Some details about the utility issues:
They have been discussed at length in other messages, so I
won't answer here again. However, given the fact that the
question of usage has come up over and over again, I have
added a new section, "Usage Considerations", to my internal
draft.
It currently reads:
>>>>>>>>
It may at first seem strange to have a pointer to an archived form of a
message in a header field of that same message. After all, if one has the
message, why would one need a pointer to it? It turns out that such
pointers can be extremely useful. This section describes some of the
scenarios for their use.
One may want to refer to messages in a non-message context, such as on a
Web page or in an instant messaging context. In such a case, being able to
take the URI out of the Archived-At header avoids having to search the
correct message in the archive.
One may want to refer to other messages in a message context. While
refering to a single message is often done by replying to that message,
when referring to more than one message, providing a pointer to these
messages is a widespread practice. The Archived-At header makes it easier
to provide these pointers.
One may want to find related messages, for which one may need to go to the
archive if one has not received potentially related messages. Also, it may
often be easier to find related messages in an archive than in an email
client. The Archived-At header makes it easier to find the starting point
in the archive to find related messages.
Please note that in the above usage scenarios, it is mostly the human
reader, rather than the email client software, that makes use of the URI in
the Archived-At header. However, this does not rule out the use of the URI
in the Archived-At header by the email client or other software if such use
is found helpful.
>>>>>>>>
Comments appreciated (actual suggested text preferred).
>2. There is only one circumstance that I can think of where one
> might have the proposed field but not the entire message. And
> that depends for proper operation on specification of issues
> which are not currently specified in the draft under
> discussion. The situation would be a message/partial fragment
> numbered 1 containing the encapsulated message header in the
> absence of one or more fragments (RFC 2046).
Thanks for providing these details. I'm personally not really
very much concerned with split-up messages, and so I would
be fine with some short warning saying that the Archived-At
header field may not work as expected in the case of message/
partial. Alternatively, I can say that in the case of split/
reassembled messages, one might get two headers, one pointing
to the original whole message, and another to the first part,
and one should be careful to take the right one.
>If a
>message is so large that fragmentation would occur, putting the
>message on a server and sending retrieval instructions would be
>preferable in most instances, and there are existing mechanisms
>to handle that scenario (simply sending a URI as text, or using
>message/external-body).
Agreed! If you think that's helpful, I can say that the intent
of the Archived-At header isn't to replace these mechanism.
>Providing a pointer to a message from
>some media other than that message is not unreasonable, and
>there are a number of standardized mechanisms for that. However,
>either something is fundamentally wrong with the concept of
>putting a pointer to a message within the referenced message or
>the author needs to provide some explanation in the draft as to
>how and why he deems that to be a useful capability.
I don't think I had to add these explanations, but I have
added something anyway, see above.
>Self-reference can lead to security issues.
Thanks for mentioning that, I hadn't thought about it.
I have added a paragraph reading:
>>>>>>>>
Because the Archived-At header field points to some archived form of the
message itself, which in turn may contain the Archived-At field, there is a
potential for a denial-of-service attack on the server pointed to by the
URI in the Archived-At header field if the archived form of the message is
downloaded automatically, and further URIs in that message are followed and
downloaded recursively without checking for already downloaded resources.
However, this kind of scenario can easily be avoided by implementations.
First, the URI in the Archived-At header field should not be dereferenced
automatically, and second, appropriate measures for loop detection should
be used.
>>>>>>>>
to my internal draft. Any suggestions for improvement are welcome
(actual text highly preferred).
Given that the Archived-At header should usually not be downloaded
automatically, and that even if that would be found useful in some
case, the denial-of-service attack can still easily be avoided
by a reasonable implementation, and that on top of that, it's not
in the interest of the downloader to waste resources either,
I think having this warning in the security section should be
good enough to cover this point.
If you know about other security issues, again, actual text
I can put into the draft directly is preferred.
Regards, Martin.