ned+ietf-822(_at_)mrochek(_dot_)com wrote:
Arnt Gulbrandsen <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> writes:
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.
There are details that ought to be specified in any case. Even with an
overall per-message message header field, there ought to be a specification
for field semantics and handling if the message is split for transport
(via MIME message/partial). Likewise for at least some instances of
message/external-body (most likely the specification would be that the
indication should be ignored in the MIME-part fields for
message/external-body, since most external-body access-types represent
some form of archive).
As noted by Arnt, the indication in any event is only a recommendation;
fretting over what to do about parts of multipart/related etc. is just
that; fretting.
If the semantics of a Content-Disposition field archive recommendation
parameter are defined to be meaningful only when applied to an entire
message (i.e. in the message header or in the MIME-part header of a
message type) then the "problem" of what do do for "per-part archive
suggestions" goes away -- ignore them except in the specific case where
the part in question is a message.
Ambiguity (in the absence of a clear specification of semantics and
applicability) about applicability of an archive recommendation will
exist if it appears in a MIME-part header whether it is in a MIME field
such as Content-Disposition, an extension field such as "Archive", or
a user-defined field such as "X-No-Archive". However, handling of
MIME fields is already fairly well defined in the cases of message
splitting for transport (message/partial) and in MIME-part fields (in
particular, MIME fields are defined to have meaning in entities,
whereas non-MIME fields may be discarded at gateways; that has
ramifications for individual messages encapsulated as entities
within a MIME multipart/digest wrapper).