Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)
draft-ietf-httpbis-content-disp-09

Note: This ballot was opened for revision 09 and is now closed.

Alexey Melnikov Yes

Comment (2011-03-16 for -)
No email
send info
In answer to David's DISCUSS:

1) This document doesn't need to update or obsolete RFC 2183, because RFC 2183 specifies Content-Disposition header field for email only. This draft is a standalone version for HTTP.

2) This document is not obsoleting/updating any other HTTPBIS WG I-D.

3) Yes, both filename and filename*  are allowed. That is intentional (for backward compatibility)

4) The editor answered this, but there was a small edit in the document to add the cross reference.

(Peter Saint-Andre) (was Discuss) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) (was Discuss) No Objection

Comment (2011-03-14)
No email
send info
"RFC 2616 defines the Content-Disposition response header field"

I think that you need to say the  Content-Disposition response header field of what. Same for Intro.

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

Comment (2011-03-16 for -)
No email
send info
I have no objection to the publication of this document. There are a couple f small points that I think would benefit from attention first.

---

Section 2 says that BNF from RFC 2616 is used.
Section 3 metnions "ABNF". Is this the same (in which case please use
consistent terminology) or different (in which case please supply a
reference for ABNF).

(See also Peter's Discuss

---

Section 4.3 contains a number of bullets. The first one uses RFC 2119
language to specify behavior, but the remaining bullets use apple-pie
language. Do you need to upgrade all bullets to RFC 2119?

(David Harrington) (was Discuss) No Objection

Comment (2011-03-14)
No email
send info
1) I agree with Stewart's DISCUSS. I found the discussion of the last segment of the filename to be confusing.

2) I agree with Stewart's concern about some additional security considerations that are not documented.

(Russ Housley) No Objection

(Dan Romascanu) No Objection

Comment (2011-03-14 for -)
No email
send info
Why would Appendix C4 be removed at publication? I believe that it actually includes important information about the status of the implementations, and clarifies the reasons of some of the choices made by editors and the WG. 

(Robert Sparks) No Objection

Comment (2011-03-14 for -)
No email
send info
Consider adding "At the time of publication of this document, " to the front of the sentence starting with the purl.org URL at the end of Appendix D. Using a tool like purl.org helps make it easier to manage moving content around, but won't guarantee that that the content isn't a dangling reference or that it contains relative content in 20 years.

(Sean Turner) (was Discuss, No Objection, Discuss) No Objection

Comment (2011-03-17)
No email
send info
#1) Sec 4.1 contains the following phrase:

   Furthermore note that the format used for ext-value allows specifying
   a natural language;

It would greatly help to include an "natural language (e.g., <insert text here>);"

#3) Sec 8.2: Should the registration template include:

   Related information: none

#5) App D contains the following:

     [[fallbackbug: Firefox is known to
      pick the wrong parameter; a bug fix is scheduled for Firefox 5.
      --jre]]

Is this supposed to be removed?