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

[Ballot comment]

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.

[Ballot comment]
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.

[Ballot discuss]
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.

[Ballot comment]
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?

[Ballot discuss]
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 injunction attacks (in general) in the security considerations section, maybe Section 9.3.

[Ballot comment]
*) I'll not repeats the OWS discuss point from p1.  If it gets changed there I assume it will get changed here.  If not then this can be ignored.

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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

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.

[Ballot comment]
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

[Ballot discuss]
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. Perhaps this was discussed though, was it?

(I didn't see the mail for this, maybe I hit the wrong button,
so sorry if you get a dup.)

[Ballot comment]
- 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

[Ballot discuss]

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. Perhaps this was discussed though, was it?

[Ballot comment]

- 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

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-httpbis-p2-semantics-24.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

NOTE: several entries that are part of the fourth action (Content-Coding registrations) have draft-ietf-httpbis-p1-messaging as their reference. If we're to update those entries with an RFC number once draft-ietf-httpbis-p1-messaging has been assigned one, these entries need to be requested in the IANA Considerations section for draft-ietf-httpbis-p1-messaging, rather than this document. We have no other mechanism to ensure that reference updates aren't overlooked.

IANA understands that, upon approval of this document, there are four actions which IANA must complete. The third action must be approved by the designated expert for Permanent Message Header Field Names.

First, a new registry called the HTTP Method Registry will be created at

http://www.iana.org/assignments/http-methods

The registration rule for this name space is IETF Review as defined in RFC 5226.  The column names are "Method," "Safe" (a Y/N column), "Idempotent" (a Y/N column), and "Reference."

The initial registrations are

+---------+------+------------+---------------+
| Method  | Safe | Idempotent | Reference    |
+---------+------+------------+---------------+
| CONNECT | no  | no        | [ RFC-to-be ] |
| DELETE  | no  | yes        | [ RFC-to-be ] |
| GET    | yes  | yes        | [ RFC-to-be ] |
| HEAD    | yes  | yes        | [ RFC-to-be ] |
| OPTIONS | yes  | yes        | [ RFC-to-be ] |
| POST    | no  | no        | [ RFC-to-be ] |
| PUT    | no  | yes        | [ RFC-to-be ] |
| TRACE  | yes  | yes        | [ RFC-to-be ] |
+---------+------+------------+---------------+

Second, the HTTP Status Code Registry, located at

http://www.iana.org/assignments/http-status-codes/

is revised as follows:

The registration procedure is changed to IETF Review as defined in RFC 5226.

The following values in the existing registry are updated as follows:

+-------+-------------------------------+----------------+
| Value | Description                  | Reference      |
+-------+-------------------------------+----------------+
| 100  | Continue                      |  [ RFC-to-be ] |
| 101  | Switching Protocols          |  [ RFC-to-be ] |
| 200  | OK                            |  [ RFC-to-be ] |
| 201  | Created                      |  [ RFC-to-be ] |
| 202  | Accepted                      |  [ RFC-to-be ] |
| 203  | Non-Authoritative Information |  [ RFC-to-be ] |
| 204  | No Content                    |  [ RFC-to-be ] |
| 205  | Reset Content                |  [ RFC-to-be ] |
| 300  | Multiple Choices              |  [ RFC-to-be ] |
| 301  | Moved Permanently            |  [ RFC-to-be ] |
| 302  | Found                        |  [ RFC-to-be ] |
| 303  | See Other                    |  [ RFC-to-be ] |
| 305  | Use Proxy                    |  [ RFC-to-be ] |
| 306  | (Unused)                      |  [ RFC-to-be ] |
| 307  | Temporary Redirect            |  [ RFC-to-be ] |
| 400  | Bad Request                  |  [ RFC-to-be ] |
| 402  | Payment Required              |  [ RFC-to-be ] |
| 403  | Forbidden                    |  [ RFC-to-be ] |
| 404  | Not Found                    |  [ RFC-to-be ] |
| 405  | Method Not Allowed            |  [ RFC-to-be ] |
| 406  | Not Acceptable                |  [ RFC-to-be ] |
| 408  | Request Timeout              |  [ RFC-to-be ] |
| 409  | Conflict                      |  [ RFC-to-be ] |
| 410  | Gone                          |  [ RFC-to-be ] |
| 411  | Length Required              |  [ RFC-to-be ] |
| 413  | Payload Too Large            |  [ RFC-to-be ] |
| 414  | URI Too Long                  |  [ RFC-to-be ] |
| 415  | Unsupported Media Type        |  [ RFC-to-be ] |
| 417  | Expectation Failed            |  [ RFC-to-be ] |
| 426  | Upgrade Required              |  [ RFC-to-be ] |
| 500  | Internal Server Error        |  [ RFC-to-be ] |
| 501  | Not Implemented              |  [ RFC-to-be ] |
| 502  | Bad Gateway                  |  [ RFC-to-be ] |
| 503  | Service Unavailable          |  [ RFC-to-be ] |
| 504  | Gateway Timeout              |  [ RFC-to-be ] |
| 505  | HTTP Version Not Supported    |  [ RFC-to-be ] |
+-------+-------------------------------+----------------+

Third, in the Permanent Message Header Field Names registry at

http://www.iana.org/assignments/message-headers

the entries below will be updated as follows:

  +-------------------+----------+----------+-----------------+
  | Header Field Name | Protocol | Status  | Reference      |
  +-------------------+----------+----------+-----------------+
  | Accept            | http    | standard | Section 5.3.2  |
  | Accept-Charset    | http    | standard | Section 5.3.3  |
  | Accept-Encoding  | http    | standard | Section 5.3.4  |
  | Accept-Language  | http    | standard | Section 5.3.5  |
  | Allow            | http    | standard | Section 7.4.1  |
  | Content-Encoding  | http    | standard | Section 3.1.2.2 |
  | Content-Language  | http    | standard | Section 3.1.3.2 |
  | Content-Location  | http    | standard | Section 3.1.4.2 |
  | Content-Type      | http    | standard | Section 3.1.1.5 |
  | Date              | http    | standard | Section 7.1.1.2 |
  | Expect            | http    | standard | Section 5.1.1  |
  | From              | http    | standard | Section 5.5.1  |
  | Location          | http    | standard | Section 7.1.2  |
  | MIME-Version      | http    | standard | Appendix A.1    |
  | Max-Forwards      | http    | standard | Section 5.1.2  |
  | Referer          | http    | standard | Section 5.5.2  |
  | Retry-After      | http    | standard | Section 7.1.3  |
  | Server            | http    | standard | Section 7.4.2  |
  | User-Agent        | http    | standard | Section 5.5.3  |
  | Vary              | http    | standard | Section 7.1.4  |
  +-------------------+----------+----------+-----------------+


Fourth, HTTP Content-Coding registry (for which an author and the shepherd are designated experts) of the Hypertext Transfer Protocol (HTTP) Parameters registry located at:

http://www.iana.org/assignments/http-parameters/

is modified as follows:

The registration rules for the registry are changed to IETF Review as defined in RFC 5226.

These values in the existing registry are updated as follows:

+------------+--------------------------------------+---------------------------------+
| Name      | Description                          | Reference                      |
+------------+--------------------------------------+---------------------------------+
| compress  | UNIX "compress" data format [Welch]  | draft-ietf-httpbis-p1-messaging |
|            |                                      |                                |
| deflate    | "deflate" compressed data            | draft-ietf-httpbis-p1-messaging |
|            | ([RFC1951]) inside the "zlib" data  |                                |
|            | format ([RFC1950])                  |                                |
| gzip      | GZIP file format [RFC1952]          | draft-ietf-httpbis-p1-messaging |
|            |                                      |                                |
| identity  | Reserved (synonym for "no encoding"  | [ RFC-to-be ]                  |
|            | in Accept-Encoding)                  |                                |
| x-compress | Deprecated (alias for compress)      | draft-ietf-httpbis-p1-messaging |
|            |                                      |                                |
| x-gzip    | Deprecated (alias for gzip)          | draft-ietf-httpbis-p1-messaging |
|            |                                      |                                |
+------------+--------------------------------------+---------------------------------+

IANA understands that these are the only actions required to be completed upon approval of this document. 
 

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol Bis
WG (httpbis) to consider the following document:
- 'Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-11-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Hypertext Transfer Protocol (HTTP) is an application-level
  protocol for distributed, collaborative, hypertext information
  systems.  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.


Note that this document is part of a set, which should be reviewed together:

* draft-ietf-httpbis-p1-messaging
* draft-ietf-httpbis-p2-semantics
* draft-ietf-httpbis-p4-conditional
* draft-ietf-httpbis-p5-range
* draft-ietf-httpbis-p6-cache
* draft-ietf-httpbis-p7-auth
* draft-ietf-httpbis-method-registrations
* draft-ietf-httpbis-authscheme-registrations

The following normative references should be noted as "downward references":
RFC 1950, "ZLIB Compressed Data Format Specification version 3.3"
RFC 1951, "DEFLATE Compressed Data Format Specification version 1.3"
RFC 1952, "GZIP file format specification version 4.3"
Welch, T., "A Technique for High Performance Data Compression"

In addition, the obsolete reference to RFC 1305 will be updated to point to RFC 5905.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/

Once IESG evaluation begins, IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics/ballot/

No IPR declarations have been submitted directly on this I-D.

1. Summary

Document: draft-ietf-httpbis-p2-semantics-24
Document Shepherd: Mark Nottingham
Responsible Area Director: Barry Leiba
Publication Type: Proposed Standard

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
distributed, collaborative, hypertext information systems. 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.

Note that this document is part of a set, which should be reviewed together:

* draft-ietf-httpbis-p1-messaging
* draft-ietf-httpbis-p2-semantics
* draft-ietf-httpbis-p4-conditional
* draft-ietf-httpbis-p5-range
* draft-ietf-httpbis-p6-cache
* draft-ietf-httpbis-p7-auth
* draft-ietf-httpbis-method-registrations
* draft-ietf-httpbis-authscheme-registrations


2. Review and Consensus

As chartered, this work was very constrained; the WG sought only to clarify
RFC2616, making significant technical changes only where there were
considerably interoperability or security issues.

While the bulk of the work was done by a core team of editors, it has been
reviewed by a substantial number of implementers, and design issues enjoyed
input from many of them.

It has been through two Working Group Last Calls, with multiple reviewers each
time. We have also discussed this work with external groups (e.g., the W3C TAG).

3. Intellectual Property

There are no IPR disclosures against this document. The authors have confirmed
that they have no direct, personal knowledge of IPR related to this document
that has not been disclosed.

4. Other Points

Downward references:
* RFC1950
* RFC1951 (already in downref registry)
* RFC1952
* "Welch"

New registries created:

* HTTP Method registry. IETF Review is required to assure that registrations
  are appropriate, as HTTP methods are purposefully constrained.
 
Updated registries:

* HTTP Status Code registry policy remains at IETF Review, and the registration
  procedures are now defined by this document.

* The Content Coding Registry policy is changed from First Come First Served to
  IETF Review, and registration procedures are now defined by this document.
  the policy was changed to assure adequate review.

There is also an informational reference to RFC1305, which has been obsoleted
by RFC5905. This will be addressed in an update.