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.
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. (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.) 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)
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.
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.
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.
Keith