Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)
draft-ietf-httpbis-content-disp-09
Yes
(Peter Saint-Andre)
No Objection
(Jari Arkko)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
Note: This ballot was opened for revision 09 and is now closed.
Alexey Melnikov Former IESG member
Yes
Yes
(2011-03-16)
Unknown
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 Former IESG member
(was Discuss)
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2011-03-16)
Unknown
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?
Dan Romascanu Former IESG member
No Objection
No Objection
(2011-03-14)
Unknown
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.
David Harrington Former IESG member
(was Discuss)
No Objection
No Objection
(2011-03-14)
Unknown
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.
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(2011-03-14)
Unknown
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.
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
(was Discuss, No Objection, Discuss)
No Objection
No Objection
(2011-03-17)
Unknown
#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?
Stewart Bryant Former IESG member
(was Discuss)
No Objection
No Objection
(2011-03-14)
Unknown
"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.