APPSDIR review of draft-ietf-httpbis-p2-semantics-24
|Reported by:||julian.reschke@…||Owned by:||draft-ietf-httpbis-p2-semantics@…|
|Component:||p2-semantics||Severity:||In IETF LC|
Description (last modified by fielding@…)
In Section 126.96.36.199:
'If a Content-Type header field is not present, the recipient MAY either assume a media type of "application/octet-stream" ([RFC2046], Section 4.5.1) or examine the data to determine its type.' According to RFC 2046, the "octet-stream" subtype is used to indicate that a body contains arbitrary data. The RFC 2119 "may" leaves it to the implementor to make an assumption. I suggest turning this into a recommendation so that the assumption is clear to the implementor. There is a discussion of MIME sniffing in draft-ietf-websec-mime-sniff-03. There has been discussion about MIME or Content sniffing over the years. I am aware that some browsers do MIME sniffing. I understand that it is sometimes needed to make the Web work. However, it can lead to security vulnerabilities. The paragraph which follows the one quoted above discusses about that. I listed this as a major issue for the attention of the Applications Area Directors. - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0357.html
In Section 5.5.1:
'The "From" header field contains an Internet email address for a human user who controls the requesting user agent. The address ought to be machine-usable, as defined by "mailbox" in Section 3.4 of [RFC5322]:' The above text is similar to text which was in RFC 2068 and RFC 2616. The "mailbox" may also contain a display name whereas the "addr-spec" (see Section 3.4.1) is an Internet mail address. I listed this issue as minor to flag it for the attention of the HTTPbis Working Group. (#504)
In Section 5.5.3:
"a sender MUST NOT generate advertising or other non-essential information within the product identifier"
I suggest having the text as guidance together with an explanation instead of a RFC 2119 prohibition.
WONTFIX: This is a social requirement suitable for RFC 2119 terms
In Section 7.1.1:
"The preferred format is a fixed-length and single-zone subset of the date and time specification used by the Internet Message Format [RFC5322]" The ABNF imports obs-date from RFC 5322. "GMT" is defined in "obs-zone" (see RFC 5322). There is the following in the section:
"For example, messages are occasionally forwarded over HTTP from a non-HTTP source that might generate any of the date and time specifications defined by the Internet Message Format." I listed this as a minor issue. I am not suggesting any change as "GMT" is used in other header fields. I'll defer to the HTTPbis Working Group as to whether there should be a note about "GMT" with an explanation that although "GMT" is deprecated the use is widespread. -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0351.html
Section 8.1 defines a HTTP Method Registry where registration requires IETF Review. I took a quick look at Issue #364. Section 4.2 discusses about common method properties, e.g. cacheable. The fields in Section 8.1.1 does not include cacheable.
There are considerations for new methods in Section 8.1.2. I gather that the working group understands that someone will have to review the specification and raise an issue if the considerations are not followed.
The table in Section 8.1.3 only mentions the section number. There is an assumption that the specification text is in this draft. I suggest also adding a reference for the RFC number. As a note for the reader, draft-ietf-httpbis-method-registrations-13 also registers some HTTP methods.
The above assumption also applies to Section 8.2. I suggest updating the existing registrations at http://www.iana.org/assignments/http-status-codes/ so that the HTTP Status Code Registry is compliant with Section 8.2.1. -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0352.html
In Section 5.5.2:
"Referer allows servers to generate back-links to other resources for"
"information disclosure in Referer ought to restrict their changes to" I'll defer to the editors as to whether to add "header field". - see 
I suggest changing the RFC 1305 reference in Section 188.8.131.52 to RFC 5905. (#499)
In Section 8.3.1:
'Authors of specifications defining new fields are advised to keep the name as short as practical and to not prefix the name with "X-" unless the header field will never be used on the Internet.' I suggest adding a reference to BCP 178. 
Change History (17)
comment:14 Changed 3 years ago by julian.reschke@…
- Severity changed from In WG Last Call to In IETF LC
comment:16 Changed 3 years ago by fielding@…
- Resolution set to incorporated
- Status changed from new to closed