Arnt Gulbrandsen <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> writes:
Is there a single (or a very few) interoperably used fields, in
practice? I've heard of X-No-Archive and Archive - who supports those
two?
Archive is very sparsely used, and I'm not sure if it's really used by
anyone in an interoperable fashion. X-No-Archive is widely respected by a
variety of software, most notably Google Groups.
It should be considered purely a request, IMO, since the definition of
archive is iffy and it's hard to really formalize policy without getting
into very complex rules engines.
Agreed. Among other things, there are going to be cases where every message
sent to a given destination need to be archived for legal purposes.
Note that X-No-Archive applies to the entire message. The implications of
a Content-Disposition parameter that could be applied to arbitrarily
nested parts of a complex MIME message and not visible in the top-level
headers for an implementor trying to honor it are a bit troubling to me.
Without it being trivial to determine the archivability of a message, I
expect many archives wouldn't bother.
Excellent point. A per-message archive: yes/no sort of field is something that
can be implemented with minimal fuss in many cases and makes considerable sense
as a suggestion to archival agents. Per-part archive suggestions, OTOH, are
going to be a royal pain to implement: Consider the implications of marking all
parts of a multipart as do-not-archive (do you then remove the multipart
entirely?), the implications of marking one part that happens to be essential
in a multipart/related (might as well drop the whole thing, but how do you know
that?), what to do when a part of a signed message is removed, and so on. I
certainly wouldn't bother to implement this mess.
I will also point out that archiving is really an operation done in parallel to
normal message processing. As such, it really doesn't make sense for it to be a
content-disposition paramater, as it has nothing to do with the "normal"
message disposition process.
Ned