Arnt Gulbrandsen wrote:
Keith Moore writes:
seems reasonable at least from a theoretical perspective. from a
practical perspective, I wonder if it's at all realistic to request
that email not be archived, or that some part of a message not be
archived.
A good question, but I think it's beside the point. If the existing
non-standard field is reasonably widely used, both by message writers
and archivers, isn't that in itself reason enough to standadize it?
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 seems to have some existing defacto support within Usenet. HTTP has
similar considerations, addressed by the standardized Cache-Control [HTTP,
RFC 2616, section 14.9] header field, which has all sorts of bells and
whistles.
The usefor working group is discussing possible standardization of the Archive
field. There are a few issues:
1. uses other than Usenet should probably be considered; a general solution
that encompasses Usenet-specific needs and similar needs of other
applications
of RFC [2]822 Internet Message Format is probably superior to an application-
specific field.
2. There has been a proposal to use RFC 2231 (MIME
Content-Type/Content-Disposition)
parameters with Archive. That would be a precedent (use of RFC 2231
parameters with non-MIME fields). [Although that's been discussed w.r.t.
Keith's Auto-Submitted field draft -- mea culpa]
3. Message parts vs. the message as a whole. Clearly Content-Disposition can
apply in either case (as detailed in RFC 2183 w.r.t. composite media types).
While non-MIME fields could be included in MIME-part headers, there is no
reason to expect that they would be interpreted appropriately there.
4. HTTP's Cache-Control might subsume the unofficial Archive and RFC 1036
[2.2.4]
Expires fields. Cache-Control has a plethora of options (w/o the complexity
of RFC 2231 parsing). But I'm not sure that the name is sufficiently generic
for
general RFC [2]822 use, and as it is not a MIME field, it lacks some of the
potential flexibility of a Content-Disposition parameter.
As there has been some recent discussion here w.r.t. Content-Disposition
parameters,
I thought I'd run the concept of an archive/no-archive parameter to the
Content-Disposition field up the flagpole here to see how much resistance there
might be.