[Top] [All Lists]

Re: Suggestion : New Content-Disposition parameters...

2004-07-18 12:48:56

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

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

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 
   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 
   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 
   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 
   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 
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.