Subject: I-D Action:draft-ietf-httpbis-content-disp-00.txt

From: [email-masked]
Date: Fri, 3 Sep 2010 17:00:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Hypertext Transfer Protocol Bis Working Group of the IETF.

	Title           : Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)
	Author(s)       : J. Reschke
	Filename        : draft-ietf-httpbis-content-disp-00.txt
	Pages           : 13
	Date            : 2010-09-03

HTTP/1.1 defines the Content-Disposition response header field, but
points out that it is not part of the HTTP/1.1 Standard.  This
specification takes over the definition and registration of Content-
Disposition, as used in HTTP, and clarifies internationalization
aspects.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-httpbis-content-disp-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 04 Sep 2010 12:17:35 +0200

Hi,

the draft below is essentially identical with 
draft-reschke-rfc2183-in-http-03 
(<http://greenbytes.de/tech/webdav/draft-reschke-rfc2183-in-http-03.html>), 
except for a boilerplate change with respect to the changed status (such 
as the issue tracker URI).

I think this draft can go to WG LC soon. In the meantime I'm looking for 
feedback specifically on:

1) Section 3.3, Security Considerations 
(<http://tools.ietf.org/html/draft-ietf-httpbis-content-disp-00#section-3.3>): 
I'm sure more can be added.

2) Section 3.5, Extensibility 
(<http://tools.ietf.org/html/draft-ietf-httpbis-content-disp-00#section-3.5>): 
the original MIME spec for Content-Disposition defines a registry for 
values and parameters, which has been used in other protocols as well. I 
*think* the registry procedure should be updated to clarify this, but 
this seems to be a job for a future RFC2183bis.

3) Appendix C.4, Implementations 
(<http://tools.ietf.org/html/draft-ietf-httpbis-content-disp-00#appendix-C.4>): 
this reports on the behavior of existing implementations; at some point 
we'll need to make a conscious decision about whether this should go 
into the final spec.

UA implementers: 
<http://tools.ietf.org/html/draft-ietf-httpbis-content-disp-00#section-3.3> 
proposes:

    "filename" and "filename*" behave the same, except that "filename*"
    uses the encoding defined in [RFC5987], allowing the use of
    characters not present in the ISO-8859-1 character set
    ([ISO-8859-1]).  When both "filename" and "filename*" are present, a
    recipient SHOULD pick "filename*" and ignore "filename" - this will
    make it possible to send the same header value to clients that do not
    support "filename*".

Unfortunately, UAs are very shaky here, so they'll need fixes to make 
this possible. See <http://greenbytes.de/tech/tc2231/#attfnboth>:

- FF3 and Opera pick "filename" over "filename*" (Konqueror gets this right)

and <http://greenbytes.de/tech/tc2231/#attfnboth2>:

- MSIE8 and Chrome fail to pick "filename", apparently being confused by 
"filename*".

For all of these, I have reported the bugs already (the ones with public 
bug trackers have the issue links in the test document).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 04 Sep 2010 13:10:45 +0200

On 04.09.2010 12:17, Julian Reschke wrote:
> ...

I forgot to mention: with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/987>, 
Content-Disposition has been removed from Part 3, and issue 123 can be 
closed.

Best regards, Julian

---

From: Henrik Nordström <[email-masked]>
Date: Sun, 05 Sep 2010 23:58:15 +0200

3.2.  Disposition Type

   Other disposition types SHOULD be handled the same way as
   "attachment" (see also [RFC2183], Section 2.8).

Shouldn't that read "Unknown disposition types"?
or to be verbosely explicit "Unknown or unhandled disposition types"?

Seems odd to block future extensions like this. RFC2183 also speaks
about unknown disposition types, not other.

I do not see HTTP being very much different than other message
interchange forms in this regard. Worth noting as a reflection is that a
very large proportion of deployed HTTP agents do not have screen output
at all but present their output in other manners.

>From a quick eyeball over the IANA registry many of the entries there
may be applied in an HTTP context as-is, depending on the client
application and not protocol. Not just the initial "inline" and
"attachment" types. Which makes me question the wording of 3.5 as well a
bit, but it's quite good as it is.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Sep 2010 15:28:27 +0200

> about unknown disposition types, not other.

Yup. Fixed with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/989>.

> bit, but it's quite good as it is.

It currently says:

"3.5 Extensibility

Note that Section 9 of [RFC2183] defines IANA registries both for 
disposition types and disposition parameters. This registry is shared by 
different protocols using Content-Disposition, such as MIME and HTTP. 
Therefore, not all registered values may make sense in the context of HTTP."

Do we need to change something here?

Best regards, Julian

---

From: Henrik Nordström <[email-masked]>
Date: Mon, 06 Sep 2010 18:53:31 +0200

> Do we need to change something here?

No. Reacted on it mostly in combination with the "Other .." in 3.2.

Regards
Henrik