APPSDIR review of draft-ietf-httpbis-p2-semantics-24

[S Moonesamy <[e-mail]>]

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