I have been selected as the Applications Area Directorate reviewer
for this draft (for background on APPSDIR, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document
shepherd or AD before posting a new version of the draft.
Document: draft-ietf-httpbis-p2-semantics-24
Title: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Reviewer: S. Moonesamy
Review Date: October 28, 2013
IETF Last Call Date: October 21, 2013
Summary: This draft is almost ready for publication as a Proposed Standard.
This document defines the semantics of HTTP/1.1 messages, as
expressed by request methods, request header fields, response status
codes, and response header fields, along with the payload of messages
(metadata and body content) and mechanisms for content negotiation.
The draft is well-written and clear.
Major Issues:
In Section 3.1.1.5:
'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.
Minor Issues:
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.
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.
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.
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.
Nits:
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".
I suggest changing the RFC 1305 reference in Section 7.1.1.1 to RFC 5905.
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.
Regards,
S. Moonesamy