- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 20 Jul 2008 18:36:34 +0200
- To: ietf-http-wg@w3.org
Hi,
So far, I didn't see any feedback on this.
In the meantime I noticed that Content-Disposition really is a second
rate header in RFC2616:
- it isn't mentioned in "7.1 Entity Header Fields"
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.7.1>), and
- more importantly, it doesn't appear in RFC 2068 at all (so how did it
get into the Draft Standard?)
Considering that, it's seems best to remove all mentions of C-D from
Part 3, and to create a separate spec that describes the use of
Content-Disposition within HTTP.
Feedback appreciated,
Julian
Julian Reschke wrote:
>
> Julian Reschke wrote:
>> So I think we need to
>>
>> 1) s/1806/2183/g (this is editorial, methinks)
>
> Done in <http://www3.tools.ietf.org/wg/httpbis/trac/changeset/269>.
>
>> 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.
>> ...
>
> and 4)
>
> Copy over more of RFC2183, for instance "disposition=inline" (which I
> think the major browsers understand).
>
> An alternative to all this would be to throw out Content-Disposition,
> and move it ("C-D as used as HTTP header") into a separate spec. If we
> did that, would we want to make at a WG work item?
>
> BR, Julian
Received on Sunday, 20 July 2008 16:37:16 UTC