Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
draft-ietf-httpbis-p2-semantics-26

Thank you for doing this important work.

Before recommending approval, I would like to briefly discuss with the other ADs on the call about the topic of mentioning injection attacks (in general) in the security considerations section, maybe Section 9.3.

2: Even after reading sections 4 & 5, I find the last paragraph of this section almost incomprehensible. Especially given that it's got a normative protocol instruction in it (SHOULD NOT), I think it could use a rewrite.

3.3

   a representation in the payload of a POST request (Section 4.3.3)
   represents an anonymous resource for providing data to be processed,
   such as the information that a user entered within an HTML form.

"anonymous resource"? I don't know what that means.

5: Why are you listing (and not providing semantics) for things that are not in this document?

Cache-Control
Host
Pragma
Range
TE
Age
Expires
Warning
All Conditionals
All Authentication

5.3.1: Do you really want to allow a weight of "0." or "1." with no trailing digits? Instead maybe:

     qvalue = ( "0" [ "." 1*3DIGIT ] )
            / ( "1" [ "." 1*3("0") ] )


5.3.2: Completely bored ABNF dorking:

     media-range    = ( "*/*"
                      / ( type "/" ( subtype / "*") )
                      ) *( OWS ";" OWS parameter )

7.1.1.1: IMF-fixdate format differs from 5322 in case-sensitivity and the use of "GMT" instead of "+0000". You should at least note that.

In general this document reads more like a book on how HTTP is used than a specification.  But the taxonomy of semantic elements is useful and the specification is ultimately there, so OK.

I agree with Stephen's comment that it would be useful to include Origin here in the list of "request context" headers.

COMMENT 1: 
Section 5.1.1 defines an entirely new, secondary handshake using a header field.  I realize this might be necessary for backward compatibility, but it seems so wrong.


COMMENT 2:
In Section 5.3.5, "A user agent that does not provide such control to the user MUST NOT send an Accept-Language header field."
This seems unnecessary, and unrealistic.  For example, on my Mac, Safari sends "Accept-Language: en-us", but as far as I can tell, there is no way to change the value.

0) Abstract: Maybe would add stateless in front of protocol in the description.

1) s4.1: Same comment as on p1 about 'ought to' register methods with IANA.

2) s4.3.3/4/5: What Stephen said about authorization.  I'm surprised that there's nothing about just accepting things without knowing whence they came.

3) s4.3.7/8: Is it allowed for an HTTP server to just not respond to a OPTIONS/TRACE method? I.e., I'd rather not tell you what I support - kind of like not replying to ping messages?  Or is a 501 response always returned.

4) s5.3.2: r/an optional "q" parameter/an OPTIONAL "q" parameter - makes the text match the ABNF

5) s5.5.3: So what happens if this isn't followed:

   a sender MUST NOT generate
   advertising or other non-essential information within the product
   identifier.

6) s6.1: Is it worth mentioning that the reason-phrase can also be not sent?  I think that's elsewhere but it might be worth mentioning again.

7) s6.4.6: What does a client do if it gets one of these in an HTTP 1.1 response?

8) s4.2.1/s8: "safe" was probably not the greatest of choices - readonly would have been better.  But, I guess this is water under the bridge at this point.

Why is there no mention of RFC 6454? That defines the Origin
header field, which I think is widely implemented. There are
a number of ways in which that could have been done (e.g.
just a ref, or changing the IANA registry to point to here
and update 6454) but making no mention of it at all seems
wrong. Please consider whether it'd be worth including
that header field here in some form or other.

- 4.3.5 makes no mention of authorization, I would have
thought that'd be useful here since mostly DELETE does
require some authz when DELETE is allowed.

- 4.3.6 makes no mention of TLS - is CONNECT really used
without TLS? Seems odd to not mention (what I think) is the
main use-case for this method at all.

- 5.5.2: CSRF attack could do with a reference and expansion
of the acronym

The paragraph crossing the page break at the bottom of page 16:

   For example, if a client makes a PUT request on a negotiated resource
   and the origin server accepts that PUT (without redirection), then
   the new state of that resource is expected to be consistent with the
   one representation supplied in that PUT; the Content-Location cannot
   be used as a form of reverse content selection identifier to update
   only one of the negotiated representations.  If the user agent had
   wanted the latter semantics, it would have applied the PUT directly
   to the Content-Location URI.

It's good that there's an example here, but this creates more questions than it answers: if I do a PUT to a particular URI, for which there are currently multiple representations of the document in different languages, based on a GET that had a specific language representation, is the semantics being specified here that the other language representations go away?   That's kind of what it sounds like. This text makes sense for different content encodings like JSON and XML, where the server might be able to generate one from the other, but it's giving me a headache thinking about it in terms of natural language. Am I missing the point here? If so, could this be clarified, or did I just not drink enough coffee this morning?

I'm left entirely unclear as to what a 300 response would look like based in the text in 3.4.2 and 6.4.1.   Am I missing something?