Hello Keith (and others),
Sorry for taking so long to answer this message. I put out
draft-duerst-archived-at-01.txt before the last IETF, but
was unable to answer to your mails because they temporarily
got lost when I moved to a new PC. In the meantime, I have
been able to recover these.
At 18:01 04/02/24, Keith Moore wrote:
>> >>Good point. But it is not really restricted to lists. There are
>> >>other potential applications, which are not related to mailing lists.
>> >>So starting with List-* would be confusing.
>> >
>> >Maybe it should only start with List- when added by a list.
>>
>> Although I expect this header to mostly be used in connection
>> with mailing lists, the archiving functionality is really not
>> at all tied to mailing lists. Also, what would be the benefit
>> of having Archived-At and List-Archived-At for the user who
>> wants to find an archived copy of the message?
>
>Having different fields for different parties adding an archived-at
>field would allow the recipient to determine which party added that
>information. That way, if the information is misleading or inaccurate
>or the archive is not properly maintained, the recipient has some idea
>of who is responsible.
There are really several scenarios here for things going wrong:
1) The header is added 'correctly', but the archiving system is
amiss. In that case, you'll get something like an HTTP 404,
and hopefully, that's good enough to know how to follow on
further. You can find an example of such a message at
http://www.w3.org/mid/1057271304(_dot_)1612458(_dot_)44(_dot_)camel(_at_)dirk(_dot_)dm93(_dot_)org
(just created a phony messageid to get you there).
2) The header is added wrongly, most possibly pointing to something
completely different than the archive or the archive resolution
system. In that case, you just don't have a clue. Let's assume
that e.g. our mailing list software added
http://wrong.example.org/mid/1057271304(_dot_)16158(_dot_)44(_dot_)camel(_at_)dirk(_dot_)dm93(_dot_)org
instead of
http://www.w3.org/mid/1057271304(_dot_)16158(_dot_)44(_dot_)camel(_at_)dirk(_dot_)dm93(_dot_)org(_dot_)
Knowing this is a mailing list wouldn't help you at all;
complaining to wrong.example.org wouldn't help you either.
Also, please note that 1) is quite a bit harder to get right
than 2), at least in the scenarios that I know about.
>> In our implementation, the URI you get with Archived-At is
>> completely independent of any particular mailing list, and
>> is the same for all mailing lists in case of cross-posting.
>
>The question is not so much whether the archive is associated with
>a list, as what party supplied the information.
For that, you would need to have a two-part header field, one part
being the URI pointing to the message, and the other being a
pointer to the supplier. But in general, the pointer to the
message should identify the supplier of the info, because there
has to be some coordination between where the message is archived
and who put a pointer to that location in the message.
On the other hand, if somebody wants to cheat/confuse recipients,
they will be able to fake a two-part field as easily as a one-part
field, so adding a separate part doesn't really help, I think.
>(though I'd also assert
>that it's useful to see how a message fit into the conversation of
>a particular list, even if the message was posted to more than one
>list.)
Yes. But you can easily do that by going to the actual archived message
(in particular if that's in HTML with various links to other messages).
Also, please note that in the system we have running, there is only
one Archived-At per message, even if the message gets sent to various
W3C lists. To find out that the message went to other lists, you either
get a 'multiple choice' page if there are several lists with lowest
confidentiality (e.g. it went to several public lists), or you get
directly to the message in the archive of the list with the lowest
confidentiality (assuming of course that you have access rights
to that level of confidentiality). If you need to check out other
mailing lists, that can always be done looking at the headers of
the actual message. This is definitely not perfect, but it works
quite well in most cases.
>That and sometimes you want to filter out certain kinds
>of header fields (e.g. you want to remove List- fields from messages
>that were re-submitted to other lists)
In the cases of the Archived-At header, that would usually not be the
case. You would just add another header, and end up with two headers.
>> >But it seems like we're finding more and more cases where it's a bad idea
>> >to have a header field without very clear rules on who is allowed to set
>> >that field. We've seen this with Reply-To and Sender and also with Carl
>> >Malamud's Solicitation field proposal.
I have added a very clear sentence saying that the field MUST only be
created if the message is actually being made available at the URI given
in the header field. Do you think that this should say anything more?
>> These are certainly good examples. But I think there is a difference
>> between a header that can be added several times (as the Archived-At
>> header) and a header that can only be added once (as I think is the
>> case with the above examples).
>
>> Or in other words: The rules are very clear, anybody who archives
>> the message can add an Archived-At header, and nobody should
>> overwrite existing ones. I clarified this in the draft.
>
>Being able to have multiple instances of the field does help, but it still
>begs the question of which intermediary added the field.
See above. I don't think this is an issue for legitimately added
headers, and I don't think there is anything we can do about
forgeries,...
>> >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.
>>
>> Very good idea. I have mentioned this in the draft. I thought
>> that the IMAP URI scheme only allows to address folders,
>> but that's not at all the case.
>
>I'll look forward to seeing the next draft.
I'll send out the new draft (draft-duerst-archived-at-02.txt) in a
separate mail.
Regards, Martin.