Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
draft-ietf-httpbis-p1-messaging-26

[Ballot comment]
In 2.7.3:

  Characters other
  than those in the "reserved" set are equivalent to their percent-
  encoded octets (see [RFC3986], Section 2.1): the normal form is to
  not encode them.

There's no explicit reference for the definition of a reserved set; this could be easily fixed thusly:

  Characters other
  than those in the "reserved" set  (see [RFC3986], Section 2.2)
  are equivalent to their percent-
  encoded octets (see [RFC3986], Section 2.1): the normal form is to
  not encode them.

Given that they follow each other, the reader will probably find the information either way, but it might be better to include both references.

Section 3, Page 20, second paragraph:

  A recipient MUST parse an HTTP message as a sequence of octets in an
  encoding that is a superset of US-ASCII [USASCII].  Parsing an HTTP
  message as a stream of Unicode characters, without regard for the
  specific encoding, creates security vulnerabilities due to the
  varying ways that string processing libraries handle invalid
  multibyte character sequences that contain the octet LF (%x0A).

I don't understand what this means.  I think I can guess what it means, but that's probably dangerous. What I think it means is that my reader should process the stream as UTF-8, storing it in a normalized Unicode format, either failing to process the request or doing something "sensible" when bad UTF-8 sequences are encountered, and the normalized Unicode should then be passed to the parser that parses the header lines. Is that roughly what's meant? If so, I think it could be more clearly stated.

The list rule exception mentioned in section 1.2 confused the hell out of me until I got to section 7.  Why is section 7 not a subsection of section 2?  I assume the answer is "because it's long, and would suck the wind out of the document if it were at the beginning," which is fine, but if so, it would be nice if the text in 1.2 did a *bit* more foreshadowing.  E.g.:

  This specification uses the Augmented Backus-Naur Form (ABNF)
  notation of [RFC5234] with an extension defined in
  Section 7 that adds compact support for comma-separated lists
  with the addition of a # token to the usual ABNF token set, similar
  to the * token.  Appendix B shows the collected ABNF with the list
  rule expanded.


BTW, none of the hassling I have done here in these DISCUSSes and comments should be construed as a lack of enthusiasm for this document.  It's really obvious that a lot of care went into this document—I'm seeing all kinds of really good advice based on practice in terms of how not to do an implementation that will be vulnerable to a variety of issues.  I am very enthusiastic about this document.  Thank you very much for doing it.

Former DISCUSSes, which have been addressed:

Point 1:

In 2.7.1, end of last paragraph:
  Before making use of an "http" URI
  reference received from an untrusted source, a recipient ought to
  parse for userinfo and treat its presence as an error; it is likely
  being used to obscure the authority for the sake of phishing attacks.

Why no normative language here?  I'm assuming this was deliberate, but it seems like the wrong call.  Why not propose that the recipient reject this out of hand, unless there's some strong reason not to?    I expect that you will explain why you made this decision and it will make sense to me, in which case that will resolve this DISCUSS point; otherwise, changing "ought to" to "SHOULD" would also satisfy.  The referenced section of RFC 3986 has some good text on why this is important, but this document doesn't repeat much of it, so I'm concerned that a new reader wouldn't really get the significance of this advice.

Point 2:

In 5.5, suppose I connect to foo.example.org on port 80, and send the following:
  GET / HTTP/1.1
  Host: foo.example.org:8080

This produces an effective URI of http://foo.example.org:8080/.  What is the server supposed to do at this point?
The obvious way to resolve this DISCUSS point is to update the text to address this problem.  I think this example has the same property that leads you to require a 301 or 400 status in section 3.1.1.

Point 3:

In 3.2.4, paragraph 1:
  server MUST reject any received request message that contains
  whitespace between a header field-name and colon with a response code
  of 400 (Bad Request).  A proxy MUST remove any such whitespace from a
  response message before forwarding the message downstream.

Why the different handling in the two cases?  Is it really less bad (and hence salvageable in the response?  What if a user agent receives such whitespace?  I expect you'll address this point by explaining why this is an issue in requests and not in responses, or else by at least adding text about how user agents should deal with this situation.  I am asking this question based on the inconsistency I see here, not any special insight I have into the problem, so I'm assuming there's a straightforward explanation.

[Ballot discuss]

Well, the IESG discussed this and didn't have a
better plan, so chair/authors - whatcha think?

There was originally supposed to be a separate
deliverable to describe the security properties of
HTTP, but that's not happening. I think its fair to
say that the security considerations here (or across
the entire set) don't really do all of that as well.
I think that does leave a gap. However, I'm not sure
what to do about that, since I don't believe there's
any real chance of getting anyone to address this gap
- its been tried and apparently failed, and with lots
of security work in HTTP/2.0, its extremely unlikely
that a victim will be found for this un-fun task.

That said, I do think it'd be worthwhile if the
authors made an attempt to fill that gap by spending
some cycles on finding a good set of references to
HTTP security topics and adding those to the security
considerations sections of p1 and/or p2.

Now, I'm sure that the authors won't want to do that
(who ever wants to do a state-of-the-art study? even
a tiny one like this) so the point I want to DISCUSS
is whether or not that's a reasonable ask.

[Ballot comment]
- p16 says you additionally define an absolute-path
but the "it" in "in that it allows" is ambiguous - do
you mean the additional thing allows // or that 3986
allows // but the additional thing doesn't? (I think
the latter, am I right?:-)

- 2.7.3 doesn't say whether
http://example.com/home.html is the same as or
different from http://example.com/HOME.html.
Wouldn't it be good to explicitly tell people that
you're not saying they are the same, but that in some
cases they might be treated as being the same? That
is, I don't get why its better to just make that
implicit. If the reason is just that this is a
rathole you wanted to avoid, I'll buy that.

- 3.1.1: did 2.5 say "ubounded length"? I don't
recall it saying that, maybe what you mean is "longer
than is supported"?

- 3.2.1: nit: this mentions the "core standard" - I
wondered if you meant p1 only or the whole set of
RFCs we're reviewing now.

- 3.2.2 says a server MUST not interpret a request
until all headers are received - does that also mean
that a server MUST NOT barf on a bad request until
the end of the headers?  That'd seem wrong, or does
"interpret" not include the server concluding that
the request is really crap?

- 3.3: I just didn't get the last para, not sure if
that implies its unclear or I didn't read carefully
enough:-)

- 5.4: I like the Host header being a MUST but would
be a bit sad if I have to type that when I telnet to
port 80 to check a server. You probably don't want
to, but I'd be happy if you added some kind of text
saying that servers might want to keep allowing that
exceptional case.

- 5.7.1: I should check the syntax of "token" but is
the SHOULD NOT in the last para here something you
can do algoritmically or would you likely need a list
of pseudonyms?  If the latter, that might be worth
noting.

- section 7: I didn't get that one either at first
glance, but then I did:-) Could do with some more
text saying why it there if you had some or an
example.

- 10: wow - the acks section to ack them all!
impressed you could keep track.

- Please see the secdir review which makes some good
points. [1] I've not yet had a chance to read that
myself, sorry.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04487.html

[Ballot discuss]
Edited to remove process nits...

OMG this was well written! Kudos to all involved!

0) In reference to OWS in the ABNF, isn't the correct ABNF syntax to include optional fields in [] - See s3.8 of RFC 5234?  Sure the text says it's optional but aren't you mixing formal syntax and informal text.  I guess this is sometimes done in ABNF for omitting fields but if you've got a mechanism to indicate a field is optional I don't understand why you're not using it.

This might be a parsing error on my part:

1) s4.1.2: WRT to the server generating an empty trailer, I don't follow #2.  Isn't it trying to say  a server generates an empty trailer unless the trailer field consists of metadata the server requires be present (i.e., the server doesn't want the metadata dropped):

OLD:

  A server MUST generate an empty trailer with the chunked transfer
  coding unless at least one of the following is true:

  1. ....

  2.  the trailer fields consist entirely of optional metadata and the
      recipient could use the message (in a manner acceptable to the
      generating server) without receiving that metadata.  In other
      words, the generating server is willing to accept the possibility
      that the trailer fields might be silently discarded along the
      path to the client.

NEW:

  A server MUST generate an empty trailer with the chunked transfer
  coding unless at least one of the following is true:

  ...

  2.  the trailer fields contains metadata that the
      recipient needs to use the message (in a manner acceptable to the
      generating server).  In other
      words, the generating server isn't willing to accept the possibility
      that the trailer fields might be silently discarded along the
      path to the client.

[Ballot discuss]
OMG this was well written! Kudos to all involved!

0) In reference to OWS in the ABNF, isn't the correct ABNF syntax to include optional fields in [] - See s3.8 of RFC 5234?  Sure the text says it's optional but aren't you mixing formal syntax and informal text.  I guess this is sometimes done in ABNF for omitting fields but if you've got a mechanism to indicate a field is optional I don't understand why you're not using it.

This might be a parsing error on my part:

1) s4.1.2: WRT to the server generating an empty trailer, I don't follow #2.  Isn't it trying to say  a server generates an empty trailer unless the trailer field consists of metadata the server requires be present (i.e., the server doesn't want the metadata dropped):

OLD:

  A server MUST generate an empty trailer with the chunked transfer
  coding unless at least one of the following is true:

  1. ....

  2.  the trailer fields consist entirely of optional metadata and the
      recipient could use the message (in a manner acceptable to the
      generating server) without receiving that metadata.  In other
      words, the generating server is willing to accept the possibility
      that the trailer fields might be silently discarded along the
      path to the client.

NEW:

  A server MUST generate an empty trailer with the chunked transfer
  coding unless at least one of the following is true:

  ...

  2.  the trailer fields contains metadata that the
      recipient needs to use the message (in a manner acceptable to the
      generating server).  In other
      words, the generating server isn't willing to accept the possibility
      that the trailer fields might be silently discarded along the
      path to the client.

**ALERT**

PROCESS NIT/WINDMILL TILT - Very, very little chance I'll be holding on to these two beyond the call.

A) I really hate to make this a discuss but after having seen and been schooled by the applications area in the art of media type registrations, I'm *shocked* to find that there are *no* security considerations, no interoperability concerns, and no applications that use this media type documented in the media type application!?  Shouldn't the security considerations at least point to the security considerations of this draft, and the interoperability section point to say "See [RFC-to-Be]" and the application that use this draft be something like "lots" ;)

B) s8.6: This has to have been discussed @ length so this might be quick:

I'm a little concerned by the FCFS nature of the registry that doesn't require a specification - well I'm most concerned about the lack of security review if there's no specification.  Is everybody else okay with this?

[Ballot comment]
Caveat: I know this is a bis draft but since you hacked it up for clarity, I figured I'd give you both barrels when reading it (i.e., it goes to "11" on the nits scale).  With that said, I would not like to see any of my comments hold progression of this draft up for a microsecond.  Feel free to consider these *if* you're making other changes before progressing to Approved or during AUTH48.

*) Support Stephen's discuss.

0) abstract: The WWW global initiative is a reference to this: http://www.w3.org/Summary.html , which hasn't been updated since ~1991/2?  Maybe we can drop the reference to that and just say:

  HTTP has been very widely used since 1990.
 
  Or:
 
  HTTP is the foundation of [this thing you might of heard of called]
  the World Wide Web architecture.

2) Abstract & s1: to match s2.1:
    r/an application-level request/response protocol
    /an application-level stateless request/response protocol

3) (no action required) Thanks for the collected ABNF in Appendix B.

4) s2.1: What's the difference between a native application and a mobile app?  Isn't a mobile app on a mobile phone a native application for that mobile phone?

5) s2.3: Maybe worth explaining what a public network access points might by adding: (e.g., accessing the Internet from a hotel).

6) s2.3: Mentions proxies are done through a local configuration rules: Should we note these might be set by an administrator and that users should be aware of these settings?

7) s2.3: Would it be better to say proprietary:
    r/Some non-standard HTTP extensions (e.g., [RFC4559])
    /Some proprietary HTTP extensions (e.g., [RFC4559])

8) s2.6: Shouldn't we be future proofing this protocol to address the two digit version bug :)  Never mind I got to A.2 and find out folks can't handle two digit versions consistently.

9) s2.7: Does there need to be a statement that all entities MUST support URIs as defined in RFC 3986?  There's some language earlier about relying upon URIs etc. but there isn't a specific MUST support.

A) s2.7: Maybe add the following before the list:

  The following provide references for the URI syntax used in this document:

B) s2.7.1, 2nd para: r/optional/OPTIONAL in reference to the query.  It would make the text match the ABNF syntax ;)

C) s2.7.1, 2nd para last sentence: Mentions the path and query component but omits the fragment component - but the fragment is in the http-URI exhibit above.  Maybe worth including in the sentence for completeness.

D) s2.7.1: Please expand WWW on first use ;)
  [Actually, I'd ask the RFC editor to include it in there list of abbreviations:
  http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt so that no one
  will ever see this comment ever again.]

E) s2.7.1: Is Internet Name = registered or domain names? and is Internet address = IP number?  Those terms are used later so maybe:

    its registered name or IP address


  The
  "http" URI scheme makes use of the delegated nature of Internet domain names
  and IP addresses to establish a naming authority (whatever entity has
  the ability to place an HTTP server at that Internet domain name or IP address)
  and allows that authority to determine which domain names are valid and how
  they might be used.

Then again this might all of been carefully crafter to avoid some long running debate that I am unaware of in which case this should be ignored.

F) 2.7.2: Personally, I'd drop the [RFC0793] reference for the TCP port, it's already in the http schema and you reference that scheme from this scheme.

10) s3, 1st para: r/optional/OPTIONAL - would make the text match the ABNF.

11) s3.1.2: If clients are going to be ignoring the reason-phrase, should p1 or p2 say something about not emitting it?  I mean what with all the need for speed from web search engines/browsers shouldn't we be trying to not send stuff that's going to promptly be ignored?

12) s3.2: r/optional/OPTIONAL x2 - would make the text match the ABNF

13) s3.2.3: should optional and required be replaced by their 2119 keywords?

14) s3.3.1: (see #2) What does a client do if the server chunks more than once, if a server sends a Transfer-Encoding header when it shouldn't have?

15) s4.1.2: "The above requirement" is a little vague is that the MUST immediately preceding the last paragraph?  Maybe:

  The requirement to generate an empty trailer prevents .....

16) s4.1.3: Pseudo-code needs error conditions for handing the MUST NOTs ;)

17) s4.2.2: r/incorrect/non-standard or non-conformant

18) s5.3: Is the origin-form before the 2nd paragraph supposed to be there?  Oh wait those are supposed to be subsections?  Can't you just call it 5.3.1 origin-form, 5.3.2 absolute-form, etc.?

19) s5.7.2: might be worth putting a reference in to Part6 after the first use of non-transform cache-control ... granted I did figure out where it was defined after remembering the

1A) s5.7.2 and s2.3: s2.3 mentions privacy proxies and s5.7.2 says the following about proxies without qualifying the type of proxy:

  A proxy MUST NOT modify header fields that provide information about
  the end points of the communication chain, the resource state, or the
  selected representation.

So does that essentially mean privacy filters proxies are non-conformant?

1B) s6.7: OPTIONAL?:

  its acceptance
  and use by the server is optional

1C) Seems like you should just provide the form.  I'm wondering whether the POC includes an actually method of contact or not?  Having seen this done in the past, it's probably worth being pedantic and saying that they can change the registration but they need to tell IANA they're doing so.

[Ballot discuss]

There was originally supposed to be a separate
deliverable to describe the security properties of
HTTP, but that's not happening. I think its fair to
say that the security considerations here (or across
the entire set) don't really do all of that as well.
I think that does leave a gap. However, I'm not sure
what to do about that, since I don't believe there's
any real chance of getting anyone to address this gap
- its been tried and apparently failed, and with lots
of security work in HTTP/2.0, its extremely unlikely
that a victim will be found for this un-fun task.

That said, I do think it'd be worthwhile if the
authors made an attempt to fill that gap by spending
some cycles on finding a good set of references to
HTTP security topics and adding those to the security
considerations sections of p1 and/or p2.

Now, I'm sure that the authors won't want to do that
(who ever wants to do a state-of-the-art study? even
a tiny one like this) so the point I want to DISCUSS
with the IESG initially and then with the chair and
authors is whether or not that's a reasonable ask.
(So, authors, no need to chime in just yet.)

[Ballot comment]

- p16 says you additionally define an absolute-path
but the "it" in "in that it allows" is ambiguous - do
you mean the additional thing allows // or that 3986
allows // but the additional thing doesn't? (I think
the latter, am I right?:-)

- 2.7.3 doesn't say whether
http://example.com/home.html is the same as or
different from http://example.com/HOME.html.
Wouldn't it be good to explicitly tell people that
you're not saying they are the same, but that in some
cases they might be treated as being the same? That
is, I don't get why its better to just make that
implicit. If the reason is just that this is a
rathole you wanted to avoid, I'll buy that.

- 3.1.1: did 2.5 say "ubounded length"? I don't
recall it saying that, maybe what you mean is "longer
than is supported"?

- 3.2.1: nit: this mentions the "core standard" - I
wondered if you meant p1 only or the whole set of
RFCs we're reviewing now.

- 3.2.2 says a server MUST not interpret a request
until all headers are received - does that also mean
that a server MUST NOT barf on a bad request until
the end of the headers?  That'd seem wrong, or does
"interpret" not include the server concluding that
the request is really crap?

- 3.3: I just didn't get the last para, not sure if
that implies its unclear or I didn't read carefully
enough:-)

- 5.4: I like the Host header being a MUST but would
be a bit sad if I have to type that when I telnet to
port 80 to check a server. You probably don't want
to, but I'd be happy if you added some kind of text
saying that servers might want to keep allowing that
exceptional case.

- 5.7.1: I should check the syntax of "token" but is
the SHOULD NOT in the last para here something you
can do algoritmically or would you likely need a list
of pseudonyms?  If the latter, that might be worth
noting.

- section 7: I didn't get that one either at first
glance, but then I did:-) Could do with some more
text saying why it there if you had some or an
example.

- 10: wow - the acks section to ack them all!
impressed you could keep track.

- Please see the secdir review which makes some good
points. [1] I've not yet had a chance to read that
myself, sorry.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04487.html

[Ballot comment]
In 2.7.3:

  Characters other
  than those in the "reserved" set are equivalent to their percent-
  encoded octets (see [RFC3986], Section 2.1): the normal form is to
  not encode them.

There's no explicit reference for the definition of a reserved set; this could be easily fixed thusly:

  Characters other
  than those in the "reserved" set  (see [RFC3986], Section 2.2)
  are equivalent to their percent-
  encoded octets (see [RFC3986], Section 2.1): the normal form is to
  not encode them.

Given that they follow each other, the reader will probably find the information either way, but it might be better to include both references.

Section 3, Page 20, second paragraph:

  A recipient MUST parse an HTTP message as a sequence of octets in an
  encoding that is a superset of US-ASCII [USASCII].  Parsing an HTTP
  message as a stream of Unicode characters, without regard for the
  specific encoding, creates security vulnerabilities due to the
  varying ways that string processing libraries handle invalid
  multibyte character sequences that contain the octet LF (%x0A).

I don't understand what this means.  I think I can guess what it means, but that's probably dangerous. What I think it means is that my reader should process the stream as UTF-8, storing it in a normalized Unicode format, either failing to process the request or doing something "sensible" when bad UTF-8 sequences are encountered, and the normalized Unicode should then be passed to the parser that parses the header lines. Is that roughly what's meant? If so, I think it could be more clearly stated.

The list rule exception mentioned in section 1.2 confused the hell out of me until I got to section 7.  Why is section 7 not a subsection of section 2?  I assume the answer is "because it's long, and would suck the wind out of the document if it were at the beginning," which is fine, but if so, it would be nice if the text in 1.2 did a *bit* more foreshadowing.  E.g.:

  This specification uses the Augmented Backus-Naur Form (ABNF)
  notation of [RFC5234] with an extension defined in
  Section 7 that adds compact support for comma-separated lists
  with the addition of a # token to the usual ABNF token set, similar
  to the * token.  Appendix B shows the collected ABNF with the list
  rule expanded.


BTW, none of the hassling I have done here in these DISCUSSes and comments should be construed as a lack of enthusiasm for this document.  It's really obvious that a lot of care went into this document—I'm seeing all kinds of really good advice based on practice in terms of how not to do an implementation that will be vulnerable to a variety of issues.  I am very enthusiastic about this document.  Thank you very much for doing it.

[Ballot discuss]
Point 1:

In 2.7.1, end of last paragraph:
  Before making use of an "http" URI
  reference received from an untrusted source, a recipient ought to
  parse for userinfo and treat its presence as an error; it is likely
  being used to obscure the authority for the sake of phishing attacks.

Why no normative language here?  I'm assuming this was deliberate, but it seems like the wrong call.  Why not propose that the recipient reject this out of hand, unless there's some strong reason not to?    I expect that you will explain why you made this decision and it will make sense to me, in which case that will resolve this DISCUSS point; otherwise, changing "ought to" to "SHOULD" would also satisfy.  The referenced section of RFC 3986 has some good text on why this is important, but this document doesn't repeat much of it, so I'm concerned that a new reader wouldn't really get the significance of this advice.

Point 2:

In 5.5, suppose I connect to foo.example.org on port 80, and send the following:
  GET / HTTP/1.1
  Host: foo.example.org:8080

This produces an effective URI of http://foo.example.org:8080/.  What is the server supposed to do at this point?
The obvious way to resolve this DISCUSS point is to update the text to address this problem.  I think this example has the same property that leads you to require a 301 or 400 status in section 3.1.1.

Point 3:

In 3.2.4, paragraph 1:
  server MUST reject any received request message that contains
  whitespace between a header field-name and colon with a response code
  of 400 (Bad Request).  A proxy MUST remove any such whitespace from a
  response message before forwarding the message downstream.

Why the different handling in the two cases?  Is it really less bad (and hence salvageable in the response?  What if a user agent receives such whitespace?  I expect you'll address this point by explaining why this is an issue in requests and not in responses, or else by at least adding text about how user agents should deal with this situation.  I am asking this question based on the inconsistency I see here, not any special insight I have into the problem, so I'm assuming there's a straightforward explanation.

[Ballot comment]
In 2.7.3:

  Characters other
  than those in the "reserved" set are equivalent to their percent-
  encoded octets (see [RFC3986], Section 2.1): the normal form is to
  not encode them.

There's no explicit reference for the definition of a reserved set; this could be easily fixed thusly:

  Characters other
  than those in the "reserved" set  (see [RFC3986], Section 2.2)
  are equivalent to their percent-
  encoded octets (see [RFC3986], Section 2.1): the normal form is to
  not encode them.

Given that they follow each other, the reader will probably find the information either way, but it might be better to include both references.

Section 3, Page 20, second paragraph:

  A recipient MUST parse an HTTP message as a sequence of octets in an
  encoding that is a superset of US-ASCII [USASCII].  Parsing an HTTP
  message as a stream of Unicode characters, without regard for the
  specific encoding, creates security vulnerabilities due to the
  varying ways that string processing libraries handle invalid
  multibyte character sequences that contain the octet LF (%x0A).

I don't understand what this means.  I think I can guess what it means, but that's probably dangerous.  What I think it means is that my reader should process the stream as UTF-8, storing it in a normalized Unicode format, either failing to process the request or doing something "sensible" when bad UTF-8 sequences are encountered, and the normalized Unicode should then be passed to the parser that parses the header lines.  Is that roughly what's meant?  If so, I think it could be more clearly stated.

The list rule exception mentioned in section 1.2 confused the hell out of me until I got to section 7.  Why is section 7 not a subsection of section 2?  I assume the answer is "because it's long, and would suck the wind out of the document if it were at the beginning," which is fine, but if so, it would be nice if the text in 1.2 did a *bit* more foreshadowing.  E.g.:

  This specification uses the Augmented Backus-Naur Form (ABNF)
  notation of [RFC5234] with an extension defined in
  Section 7 that adds compact support for comma-separated lists
  with the addition of a # token to the usual ABNF token set, similar
  to the * token.  Appendix B shows the collected ABNF with the list
  rule expanded.


BTW, none of the hassling I have done here in these DISCUSSes and comments should be construed as a lack of enthusiasm for this document.  It's really obvious that a lot of care went into this document—I'm seeing all kinds of really good advice based on practice in terms of how not to do an implementation that will be vulnerable to a variety of issues.  I am very enthusiastic about this document.  Thank you very much for doing it.

[Ballot comment]
In general, this is a very nice introduction to the HTTP architecture.  Thanks!

COMMENT 1:
"""
The above categories ... are indistinguishable from a man-in-the-middle attack.
"""
It seems worth noting that "captive portal" is not equivalent to the other two terms; it's a special case.  I would also expand the last sentence to explain a little more why the two are equivalent, and to clarify that the distinction is technical (since one could make moral distinctions between a MitM and a porn-filtering proxy):

OLD: "They are indistinguishable from a man-in-the-middle attack."
NEW: "Because these entities intercept and modify packets without the consent of either endpoint, these entities are indistinguishable at a protocol level from a man-in-the-middle attack."


COMMENT 2:
"""
A sender MUST NOT generate protocol elements that convey a
  meaning that is known by that sender to be false.
"""
This seems optimistic. 


COMMENT 3:
In Section 3.2.2, are the scare quotes around "good practice" necessary?


COMMENT 4:
In Section 3.2.3, "to white-out invalid or unwanted protocol elements" -- what does it mean to "white out" protocol elements?  To replace them with whitespace?  Why not just remove them?


COMMENT 5 (almost a DISCUSS):
In Section 4.1.2: Suppose you have an intermediary that decodes the chunked encoding of an inbound message and generates a new message with known length (Content-Length present).  It seems like you need to specify what happens to trailer fields in this case.  The answer seems to be that they're just appended to the header, but AFAICT, that's not specified in the text.

[Ballot comment]
Throughout the document (and the other documents in the series): I now understand that you intend a two stage parse for header fields and have that represented in the ABNF as a separate overall message syntax and a header field value syntax. That's fine, but I would ask that you make this clearer somewhere in section 3 of the p1 document. You talk about the parsing, but I think it is well worth describing that there are two levels of ABNF, and that the ABNF rule name corresponds to the header field name. It is fine to do it this way, but it's not the way that ABNF has been used in the past, so best to make it crystal clear.

Specific comments:

1:

  This HTTP/1.1 specification obsoletes and moves to historic status
  RFC 2616, its predecessor RFC 2068, and RFC 2145 (on HTTP
  versioning).
 
Please, no, it doesn't (and shouldn't) move any of these documents to Historic (even if it were capitalized correctly ;-) ). It obsoletes them. Please strike "and moves to historic status". (I'm happy to give you the long explanation of why moving to Historic is not the right thing if you like.)

Also, an editorial nit: I find the "we" affectation distracting. Sounds like an academic paper. 11 occurrences in this document. "This document" or "this specification" (or simply switching to the passive voice) are much more IETF-like.

2.3 (Editorial nit) "...upstream to downstream. Likewise, we use...". It's not "Likewise" here. "Upstream" and "downstream" are only about the direction of the message and don't have anything to do with who sent/received it. "Inbound" and "outbound" refer to direction based on who it's coming from (UA or OS). Strike "Likewise".

2.5, para 8 (and ff): I'm not a fan of the "MUST..., unless..." construct. People get into stupid conformance arguments over such things. I prefer "MUST either..., or ..." or "SHOULD..., the primary exception being...".

2.7.1, para 6: Why "MAY"? What else could it do? Is this a protocol option of some sort?
para 7: The concept of "establishing authority" is not well explained here. What's the import of it?
para 8: Why "ought to"? That seems like a fine candidate for a "SHOULD": You're giving implementation advice to avoid damage.


3.2.4:

  A proxy MUST remove any such whitespace from a
  response message before forwarding the message downstream.

Really? Wouldn't that cause the aforementioned "security vulnerability"?

  A field value is preceded by optional whitespace (OWS)...

"...and/or followed...", right?

3.2.6: This is your only use of the term "escape". A bit imprecise. I suggest reusing the quoted-pair text for quoted-cpair.

3.3.1: "encoding parameters MAY be provided by other header fields". I think MAY is wrong there. "Can"?

3.3.2:

  A sender MUST NOT send a Content-Length header field in any message
  that contains a Transfer-Encoding header field.

Why not? Can there not ever be a Transfer-Encoding that has no implicit length? I read 3.3.3 sub 3 and I still don't get it.

4.1: I presume chunk-size can't be "0" even though the ABNF allows it?

4.1.1: quoted-string doesn't allow folding, does it? Why do you need a new quoted-str-nf?

5.5, first paragraph: Why do you have "MUST reconstruct" instead of "reconstructs", or simply reversing the sense of the whole paragraph and say, "An 'effective request URI' is a reconstruction of the user agent's original target URI"? I haven't found anything in the documents that says that effective request URIs are going to be passed as protocol parameters, but rather they are for local processing and comparison. Given that, the "MUST reconstruct" seems inappropriate.

5.7.1: s/The received-by field/The received-by token OR The received-by portion of the Via header field

5.7.2:

  A non-transforming proxy MUST NOT modify the message payload (Section
  3.3 of [Part2]).  A transforming proxy MUST NOT modify the payload of
  a message that contains the no-transform cache-control directive.

I get the second sentence. But isn't the first a definition of a non-transforming proxy? Is so, I think you should change "MUST NOT" to "will not" or "does not".

6.3:

  A server MAY assume that an HTTP/1.1 client intends to maintain a
  persistent connection until a close connection option is received in
  a request.
  [...]
  Clients and servers SHOULD NOT assume that a persistent connection is
  maintained for HTTP versions less than 1.1 unless it is explicitly
  signaled.

I'm not sure how to implement the option/requirement of "assume". :-) What is it that you want/expect/permit the implementation to do/not do?

6.4: A "SHOULD" should not be used to "encourage" something. This seems like an utterly empty piece of normative text. "Be nice" without other guidance doesn't seem to lead to any useful interoperability.

7:

  Thus, a sender MUST expand the list construct as follows:
  [...]
  a recipient MUST expand the list construct as follows:
 
The two MUSTs here strike me as goofy. Implementations of senders and recipients do not "expand" ABNF rules; they produce and parse text. Saying things like the following would make sense to me:

  In any production that uses the list construct, a sender MUST NOT
  produce empty list elements. In other words, senders MUST produce
  lists that satisfy the following syntax: [...]
 
  In other words, a recipient MUST accept lists that satisfy the
  following syntax: [...]

[Ballot discuss]
This will go to "Yes" as soon as this issue is addressed; this is an incredibly well-written document. And I think this is easily addressed:

Throughout the document (and the other documents in the series), the ABNF for the header fields does not include the name of the header field. For instance, in 3.3.1, you have:

  Transfer-Encoding = 1#transfer-coding

But the proper syntax for TE would be:

  Transfer-Encoding = "Transfer-Encoding:" OWS 1#transfer-coding

If you want to come up with a different syntax, where the rule name itself gets included with a colon and optional whitespace before the right hand side of the rule I suppose you could do that, but that's going to be seriously weird mixing of ABNF with something magic and new.

[Ballot comment]
1:

  This HTTP/1.1 specification obsoletes and moves to historic status
  RFC 2616, its predecessor RFC 2068, and RFC 2145 (on HTTP
  versioning).
 
Please, no, it doesn't (and shouldn't) move any of these documents to Historic (even if it were capitalized correctly ;-) ). It obsoletes them. Please strike "and moves to historic status". (I'm happy to give you the long explanation of why moving to Historic is not the right thing if you like.)

Also, an editorial nit: I find the "we" affectation distracting. Sounds like an academic paper. 11 occurrences in this document. "This document" or "this specification" (or simply switching to the passive voice) are much more IETF-like.

2.3 (Editorial nit) "...upstream to downstream. Likewise, we use...". It's not "Likewise" here. "Upstream" and "downstream" are only about the direction of the message and don't have anything to do with who sent/received it. "Inbound" and "outbound" refer to direction based on who it's coming from (UA or OS). Strike "Likewise".

2.5, para 8 (and ff): I'm not a fan of the "MUST..., unless..." construct. People get into stupid conformance arguments over such things. I prefer "MUST either..., or ..." or "SHOULD..., the primary exception being...".

2.7.1, para 6: Why "MAY"? What else could it do? Is this a protocol option of some sort?
para 7: The concept of "establishing authority" is not well explained here. What's the import of it?
para 8: Why "ought to"? That seems like a fine candidate for a "SHOULD": You're giving implementation advice to avoid damage.


3.2.4:

  A proxy MUST remove any such whitespace from a
  response message before forwarding the message downstream.

Really? Wouldn't that cause the aforementioned "security vulnerability"?

  A field value is preceded by optional whitespace (OWS)...

"...and/or followed...", right?

3.2.6: This is your only use of the term "escape". A bit imprecise. I suggest reusing the quoted-pair text for quoted-cpair.

3.3.1: "encoding parameters MAY be provided by other header fields". I think MAY is wrong there. "Can"?

3.3.2:

  A sender MUST NOT send a Content-Length header field in any message
  that contains a Transfer-Encoding header field.

Why not? Can there not ever be a Transfer-Encoding that has no implicit length? I read 3.3.3 sub 3 and I still don't get it.

4.1: I presume chunk-size can't be "0" even though the ABNF allows it?

4.1.1: quoted-string doesn't allow folding, does it? Why do you need a new quoted-str-nf?

5.5, first paragraph: Why do you have "MUST reconstruct" instead of "reconstructs", or simply reversing the sense of the whole paragraph and say, "An 'effective request URI' is a reconstruction of the user agent's original target URI"? I haven't found anything in the documents that says that effective request URIs are going to be passed as protocol parameters, but rather they are for local processing and comparison. Given that, the "MUST reconstruct" seems inappropriate.

5.7.1: s/The received-by field/The received-by token OR The received-by portion of the Via header field

5.7.2:

  A non-transforming proxy MUST NOT modify the message payload (Section
  3.3 of [Part2]).  A transforming proxy MUST NOT modify the payload of
  a message that contains the no-transform cache-control directive.

I get the second sentence. But isn't the first a definition of a non-transforming proxy? Is so, I think you should change "MUST NOT" to "will not" or "does not".

6.3:

  A server MAY assume that an HTTP/1.1 client intends to maintain a
  persistent connection until a close connection option is received in
  a request.
  [...]
  Clients and servers SHOULD NOT assume that a persistent connection is
  maintained for HTTP versions less than 1.1 unless it is explicitly
  signaled.

I'm not sure how to implement the option/requirement of "assume". :-) What is it that you want/expect/permit the implementation to do/not do?

6.4: A "SHOULD" should not be used to "encourage" something. This seems like an utterly empty piece of normative text. "Be nice" without other guidance doesn't seem to lead to any useful interoperability.

7:

  Thus, a sender MUST expand the list construct as follows:
  [...]
  a recipient MUST expand the list construct as follows:
 
The two MUSTs here strike me as goofy. Implementations of senders and recipients do not "expand" ABNF rules; they produce and parse text. Saying things like the following would make sense to me:

  In any production that uses the list construct, a sender MUST NOT
  produce empty list elements. In other words, senders MUST produce
  lists that satisfy the following syntax: [...]
 
  In other words, a recipient MUST accept lists that satisfy the
  following syntax: [...]

[Ballot comment]
Thanks Tom Nadewu for your OPS-DIR review. I know how much you spent on this one!

I see the HEAD request, which I didn't know about:

  Transfer-Encoding MAY be sent in a response to a HEAD request or in a
  304 (Not Modified) response (Section 4.1 of [Part4]) to a GET
  request

I was wondering: where is the list of valid HTTP operations defined?

1 GET
The GET method is used to retrieve information from the given server using a given URI. Requests using GET should only retrieve data and should have no other effect on the data.
2 HEAD
Same as GET, but only transfer the status line and header section.
3 POST
A POST request is used to send data to the server, for example customer information, file upload etc using HTML forms.
4 PUT
Replace all current representations of the target resource with the uploaded content.
5 DELETE
Remove all current representations of the target resource given by URI.
6 CONNECT
Establish a tunnel to the server identified by a given URI.
7 OPTIONS
Describe the communication options for the target resource.
8 TRACE
Perform a message loop-back test along the path to the target resource.

I finally found it (my mistake was that I was searching for "operation" in the document while the correct term is "method"):

  The request methods defined by this specification can be found in
  Section 4 of [Part2], along with information regarding the HTTP
  method registry and considerations for defining new methods.

This points to:

            http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25

      4.3.  Method Definitions . . . . . . . . . . . . . . . . . . . 24
      4.3.1.  GET  . . . . . . . . . . . . . . . . . . . . . . . . . 24
      4.3.2.  HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25
      4.3.3.  POST . . . . . . . . . . . . . . . . . . . . . . . . . 25
      4.3.4.  PUT  . . . . . . . . . . . . . . . . . . . . . . . . . 26
      4.3.5.  DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29
      4.3.6.  CONNECT  . . . . . . . . . . . . . . . . . . . . . . . 30
      4.3.7.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . 31
      4.3.8.  TRACE  . . . . . . . . . . . . . . . . . . . . . . . . 32


Anyway, an extra sentence, such as the following one, would have helped me:
    "Existing methods are GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE"

Also change "HEAD request" to "HEAD request method. Similar remark for "GET request"

[Ballot comment]
Thanks Tom Nadewu for your OPS-DIR review. I know how much you spent on this one!

I see the HEAD request, which I didn't know about:

  Transfer-Encoding MAY be sent in a response to a HEAD request or in a
  304 (Not Modified) response (Section 4.1 of [Part4]) to a GET
  request

I was wondering: where is the list of valid HTTP operations defined?

1 GET
The GET method is used to retrieve information from the given server using a given URI. Requests using GET should only retrieve data and should have no other effect on the data.
2 HEAD
Same as GET, but only transfer the status line and header section.
3 POST
A POST request is used to send data to the server, for example customer information, file upload etc using HTML forms.
4 PUT
Replace all current representations of the target resource with the uploaded content.
5 DELETE
Remove all current representations of the target resource given by URI.
6 CONNECT
Establish a tunnel to the server identified by a given URI.
7 OPTIONS
Describe the communication options for the target resource.
8 TRACE
Perform a message loop-back test along the path to the target resource.

I finally found it (my mistake was that I was searching for "operation" in the document while the correct term is "method"):

  The request methods defined by this specification can be found in
  Section 4 of [Part2], along with information regarding the HTTP
  method registry and considerations for defining new methods.

This points to:

            http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25

      4.3.  Method Definitions . . . . . . . . . . . . . . . . . . . 24
      4.3.1.  GET  . . . . . . . . . . . . . . . . . . . . . . . . . 24
      4.3.2.  HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25
      4.3.3.  POST . . . . . . . . . . . . . . . . . . . . . . . . . 25
      4.3.4.  PUT  . . . . . . . . . . . . . . . . . . . . . . . . . 26
      4.3.5.  DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29
      4.3.6.  CONNECT  . . . . . . . . . . . . . . . . . . . . . . . 30
      4.3.7.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . 31
      4.3.8.  TRACE  . . . . . . . . . . . . . . . . . . . . . . . . 32


Anyway, an extra sentence, such as the following one, would have helped me:
    "Existing methods are GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE"
Also change "HEAD request" to "HEAD request method. Similar remark for "GET request"

[Ballot comment]
to ops-dir review noted (consistent with respect to usage in the document) but otherwise inconsistent employment of the term coding vs encoding in http 1.0 vs 1.1 vs here. I guess it's to much to ask that the name of the header field and the term of art employed to describe it be consistent.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-httpbis-p1-messaging-24.  Authors should review the comments and questions below.  Please report any inaccuracies and respond to both questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has questions about one of the actions requested in the IANA Considerations section. In addition, IANA must ask the designated expert for Permanent Message Header Field Names and URI Schemes to review the proposed changes to those registries.

IANA understands that, upon approval of this document, there are seven actions IANA must complete.

First, in the Permanent Message Header Field Names registry in the Message Headers registry at

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

the following message headers will be updated to reflect the new information provided below:

+-------------------+----------+----------+---------------+
| Header Field Name | Protocol | Status  | Reference    |
+-------------------+----------+----------+---------------+
| Connection        | http    | standard | [ RFC-to-be ] |
| Content-Length    | http    | standard | [ RFC-to-be ] |
| Host              | http    | standard | [ RFC-to-be ] |
| TE                | http    | standard | [ RFC-to-be ] |
| Trailer          | http    | standard | [ RFC-to-be ] |
| Transfer-Encoding | http    | standard | [ RFC-to-be ] |
| Upgrade          | http    | standard | [ RFC-to-be ] |
| Via              | http    | standard | [ RFC-to-be ] |
+-------------------+----------+----------+---------------+

Second, also in the Permanent Message Header Field Names registry in the Message Headers registry at

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

the header field name "Close" shall be registered as "reserved", as follows:

+-------------------+----------+----------+---------------+
| Header Field Name | Protocol | Status  | Reference    |
+-------------------+----------+----------+---------------+
| Close            | http    | reserved | [ RFC-to-be ] |
+-------------------+----------+----------+---------------+

Third, in the Permanent URI Schemes registry in the Uniform Resource Identifier (URI) Schemes page at

http://www.iana.org/assignments/uri-schemes/

the following pair of entries for permanent URI schemes will be updated as follows:

+------------+------------------------------------+---------------+
| URI Scheme | Description                        | Reference    |
+------------+------------------------------------+---------------+
| http      | Hypertext Transfer Protocol        | [ RFC-to-be ] |
| https      | Hypertext Transfer Protocol Secure | [ RFC-to-be ] |
+------------+------------------------------------+---------------+

Fourth, in the Message Media Types registry at

http://www.iana.org/assignments/media-types/message

the existing media type

message/http

will be updated with a reference pointing to [ RFC-to-be ] and source material from section 8.3.1 of the current document.

Fifth, in the Application Media Types registry at

http://www.iana.org/assignments/media-types/application

the existing media type

application/http

will be updated with a reference pointing to [ RFC-to-be ] and source material from section 8.3.2 of the current document.

Sixth, in the Transfer Coding registry in the Hypertext Transfer Protocol (HTTP) Parameters page at

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

the registration procedure will be changed to IETF Review as defined by RFC 5226.

The existing registry entries will be updated as follows:

+------------+--------------------------------------+---------------+
| Name      | Description                          | Reference    |
+------------+--------------------------------------+---------------+
| chunked    | Transfer in a series of chunks      | [ RFC-to-be ] |
| compress  | UNIX "compress" data format [Welch]  | [ RFC-to-be ] |
| deflate    | "deflate" compressed data            | [ RFC-to-be ] |
|            | ([RFC1951]) inside the "zlib" data  | [ RFC-to-be ] |
|            | format ([RFC1950])                  | [ RFC-to-be ] |
| gzip      | GZIP file format [RFC1952]          | [ RFC-to-be ] |
| x-compress | Deprecated (alias for compress)      | [ RFC-to-be ] |
| x-gzip    | Deprecated (alias for gzip)          | [ RFC-to-be ] |
+------------+--------------------------------------+---------------+

Seventh, the Hypertext Transfer Protocol (HTTP) Upgrade Token Registry at

http://www.iana.org/assignments/http-upgrade-tokens/

will be updated with the registration below:

+-------+----------------------+----------------------+---------------+
| Value | Description          | Expected Version    | Reference    |
|      |                      | Tokens              |              |
+-------+----------------------+----------------------+---------------+
| HTTP  | Hypertext Transfer  | any DIGIT.DIGIT      | [ RFC-to-be ] |
|      | Protocol            | (e.g, "2.0")        |              |
+-------+----------------------+----------------------+---------------+

IANA Question -> In addition to adding an "Expected Version Tokens" column, should IANA also create a "Change Controller" (or similar) column? The last sentence of section 8.5.2 designates the IESG as the party responsible for this registration, and includes an email address, but it isn't in the table.

IANA Question -> Does the table above replace the current Upgrade Token registry?  If it simply adds the entry "HTTP" to the registry, how should IANA fill in the new "Expected Version Tokens" column for the current registry entries TLS/1.0 and WebSocket?


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): Message Syntax and Routing) 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): Message Syntax and Routing'
  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.  HTTP has been in use by the World Wide Web global
  information initiative since 1990.  This document provides an
  overview of HTTP architecture and its associated terminology, defines
  the "http" and "https" Uniform Resource Identifier (URI) schemes,
  defines the HTTP/1.1 message syntax and parsing requirements, and
  describes general security concerns for implementations.


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"


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

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


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

1. Summary

Document: draft-ietf-httpbis-p1-messaging-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. HTTP has been in use
by the World Wide Web global information initiative since 1990. This document
provides an overview of HTTP architecture and its associated terminology,
defines the "http" and "https" Uniform Resource Identifier (URI) schemes,
defines the HTTP/1.1 message syntax and parsing requirements, and describes
general security concerns for implementations.

The Working Group has chosen Proposed Standard because this is a substantial
revision of the text, compared to RFC2616. We anticipate moving to Internet
Standard subsequently.

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).

We were not able to get consensus on text to add regarding Security
Considerations for interception of unencrypted HTTP traffic.

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: None.

Updated registries:

* The Transfer Encoding 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.

* The Upgrade Token Registry policy remains at First Come First Served, but
  registration procedures are now defined by this document.