Hi,

looking at <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-03.html#content-disposition>:

---- B.1 Content-Disposition

The Content-Disposition response-header field has been proposed as a means for the origin server to suggest a default filename if the user requests that the content is saved to a file. This usage is derived from the definition of Content-Disposition in [RFC1806].

content-disposition = "Content-Disposition" ":" disposition-type *( ";" disposition-parm ) disposition-type = "attachment" | disp-extension-token disposition-parm = filename-parm | disp-extension-parm filename-parm = "filename" "=" quoted-string disp-extension-token = token disp-extension-parm = token "=" ( token | quoted-string )

An example is

Content-Disposition: attachment; filename="fname.ext"

The receiving user agent SHOULD NOT respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply to HTTP implementations at this time. The filename SHOULD be treated as a terminal component only.

If this header is used in a response with the application/octet-stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a `save response as...' dialog.

See Section 8.2 for Content-Disposition security issues.

----

It seems that certain vendors do not "get" that RFC1806 was updated by RFC2183, which in turn was updated by RFC2231 (defining I18N).

So I think we need to

1) s/1806/2183/g (this is editorial, methinks)

2) Clarify that I18N is defined in by RFC2231

3) Specify a profile of RFC2231 that makes sense for Content-Disposition as used over HTTP (as opposed to mail), such as:

3a) No Continuations (<http://greenbytes.de/tech/webdav/rfc2231.html#rfc.section.3>)

3b) Support <http://greenbytes.de/tech/webdav/rfc2231.html#rfc.section.3>, but only use UTF-8 encoding in producers.

Feedback appreciated,

Julian