- 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