Harald(_dot_)T(_dot_)Alvestrand(_at_)uninett(_dot_)no writes:
If something is orthogonal to the Content-disposition: header,
to the degree that it makes sense to have
Content-disposition: inline; filename=foo
Content-disposition: foo; filename=bar
then it is IMHO much cleaner to have
Content-disposition: inline; filename=foo
Content-foo-handling-directive: filename=bar
That is, don't mess with the Content-disposition header.
You are probably right about that. One practical complication,
though, is that disposition types will be as easily registered
with IANA as content types, while new Content-* header fields can't
be registered at all. An RFC that defines the new header must be
written and accepted and published.
Considering the present chaos as regards non-standardized header
names, and the following provision of RFC 822, IANA registration
of new header names is both needed and justified, in my opinion.
: 4.7.4. EXTENSION-FIELD
:
: A limited number of common fields have been defined in
: this document. As network mail requirements dictate, addi-
: tional fields may be standardized. To provide user-defined
: fields with a measure of safety, in name selection, such
: extension-fields will never have names that begin with the
: string "X-".
:
: Names of Extension-fields are registered with the Network
: Information Center, SRI International, Menlo Park, California.
For a start all headers defined in RFCs published after RFC 822
should be registered. A useful starting point for that task is,
I think, the document "Internet Standardized Message
Attributes", written by Jacob Palme and published in
comp.mail.headers 14 Nov 1994 in message
<Pine(_dot_)SUN(_dot_)3(_dot_)91(_dot_)941114152059(_dot_)27699G-100000(_at_)ester>.
--
Olle Jarnefors, Royal Institute of Technology, Stockholm
<ojarnef(_at_)admin(_dot_)kth(_dot_)se>