Hypertext Transfer Protocol Version 2 (HTTP/2)
draft-ietf-httpbis-http2-17

[Ballot discuss]
(1-4 cleared)

(5) Section 10.4: "Pushed responses for which an origin server is not authoritative (see Section 10.1) are never cached or used."
This seems like a rather important point, for which I can't find any normative text.  It seems like in Section 8.2.1, the client should be REQUIRED to verify that the ":authority" field in the PUSH_PROMISE contains a value for which the client would have been willing to re-use the connection (as specified in Section 9.1).

[Ballot comment]

The first point below was a DISCUSS but is now a comment
as Martin pointed out http/1.1 has the same issue so it's not
new here really.

Just a quick one, I'm not sure if it's me reading it wrong
or a bug... happy to clear and let you fix once we've
figured it out anyway.

8.2.2 says that clients MUST validate that a proxy is
configured for the correspondsing request. Since you say
MUST, don't you need to say what exacftly is meant there?
If that is somewhere here, I'm not seeing it. I realise that
some of that may be controversial, but if so, I think saying
that would be better than leaving it dangling (Note that
I've also a comment below about 10.1 not saying enough, if
the fix for this were to be a new paragraph or two about
when pushed stuff is ok, then you might handle my comment on
10.1 here, and that might be better, not sure.)
(Putting this one first as I'd really like an answer
but will not be blocking on it no matter how much I
dislike the answer:-)

--- OLD COMMENTS below


- 6.1, and elsewhere, I just want to check that the 256
octet limit on padding isn't too restrictive a design. Is it
still possible to say arrange that every response from a
server has the same size? (Say from a server that is only
used for serving images and where there could be a 2KB
variation in file size or something.) I think that can work
via HEADERS and CONTINUATIONs but wanted to check the limits
of flexibility here. I'm similarly interested in the limits
within which a client can add padding to a request, but I
think the same trick works if it works at all.

- 3.1: a question on the text to be removed about
draft-specific identifiers - did the WG consider how to
handle drafts produced from now until the RFC issues?  I've
not yet looked to see if there are normative dependencies
that might lengthen that process, but if there might be it
could be useful to discuss in the WG if it turns out there
are a bunch of discusses that might take a while and a few
versions to sort out. If the IESG eval is clean enough and
there are no delaying normative refs then that's probably
not needed.

- 3.2, the last para before 3.2.1 is hard to read, maybe it
was added late but it seems to use concepts not yet
explained at that point (e.g. half-closed) Maybe a forward
ref to Figure 2 would be enough to fix.

- 5.3.4, "can be moved" in 1st sentence - I don't get why
it's ok to not say MUST or SHOULD there, iff the change is
as a result of a peer's action. Shouldn't a 404 for a
dependecy have a predictable impact on the overall page
load?

- 6.10, odd that there's no padding here

- 8.1, a bit of abnf here might have helped, ah well

- 8.1.2.3, I assume the underscors in "_:authority_" are a
typo, if not they are possibly confusing

- end of p57, does the last para mean that a header field
value can be split betwee a HEADERS frame and the subsequent
CONTINUATION frame (with possible padding in between when
looked at on-the-wire)? If so, then I think you might want
to be clearer about that since I could see it leading to
interop issues. 

- p64, DNS-ID is what (dNSName?)? And "Common Name" might be
better as commonName, but both probably need a reference.
(I don't care about nitty capitalisations, but wouldn't some
coders need to reference?)

- 9.1, which TLS library allows a client to know that it'll
shortly be time to re-key? Doing so is doable, as e.g. NTP
has a mechanism like that for pre-announcing leap seconds
I'm told. Buti I'm not sure anyone actually does it at all
today.

- 9.2.1 - the renegotiation text is confusing. First para on
that starts with "MUST be disable" next one says "MAY use"
for client cert confid. I think adding something like "Other
than as noted below" before the start of  the 1st renego
para (the 3rd para of 9.2.1) might fix this, but could be
some more editing would be better.

- 9.2.2 - Isn't it sad that there are so many undesirable
TLS ciphersuites. Sorry about that;-)

- 10.1 - I think this could be a lot clearer about which
pushed things are to be thrown away and I think being
clearer about that might avoid some future problems.

- 10.5.1 has a few typos, no harm being nice to the RFC
editor and fixing those if you're pushing out a -17

- 10.7 - what general purpose padding does TLS1.2 provide?
I'm sad that this section is so negative - does that
indicate that people haven't really tried this out so much?
While it is clear there can be failed attempts at using
padding to thwart traffic analysis I think having this
mechanism defined so we can in future learn how to better
mitigate traffic analysis is a good thing and we ought not
be so down on that.

- For the record, I'm also sad that this isn't all and only
over TLS with the option of opportunistic security for http:
schemed URIs but I accept that the wg debated that and
decided for this.

[Ballot discuss]

Just a quick one, I'm not sure if it's me reading it wrong
or a bug... happy to clear and let you fix once we've
figured it out anyway.

8.2.2 says that clients MUST validate that a proxy is
configured for the correspondsing request. Since you say
MUST, don't you need to say what exacftly is meant there?
If that is somewhere here, I'm not seeing it. I realise that
some of that may be controversial, but if so, I think saying
that would be better than leaving it dangling (Note that
I've also a comment below about 10.1 not saying enough, if
the fix for this were to be a new paragraph or two about
when pushed stuff is ok, then you might handle my comment on
10.1 here, and that might be better, not sure.)

[Ballot comment]

(Putting this one first as I'd really like an answer
but will not be blocking on it no matter how much I
dislike the answer:-)

- 6.1, and elsewhere, I just want to check that the 256
octet limit on padding isn't too restrictive a design. Is it
still possible to say arrange that every response from a
server has the same size? (Say from a server that is only
used for serving images and where there could be a 2KB
variation in file size or something.) I think that can work
via HEADERS and CONTINUATIONs but wanted to check the limits
of flexibility here. I'm similarly interested in the limits
within which a client can add padding to a request, but I
think the same trick works if it works at all.

- 3.1: a question on the text to be removed about
draft-specific identifiers - did the WG consider how to
handle drafts produced from now until the RFC issues?  I've
not yet looked to see if there are normative dependencies
that might lengthen that process, but if there might be it
could be useful to discuss in the WG if it turns out there
are a bunch of discusses that might take a while and a few
versions to sort out. If the IESG eval is clean enough and
there are no delaying normative refs then that's probably
not needed.

- 3.2, the last para before 3.2.1 is hard to read, maybe it
was added late but it seems to use concepts not yet
explained at that point (e.g. half-closed) Maybe a forward
ref to Figure 2 would be enough to fix.

- 5.3.4, "can be moved" in 1st sentence - I don't get why
it's ok to not say MUST or SHOULD there, iff the change is
as a result of a peer's action. Shouldn't a 404 for a
dependecy have a predictable impact on the overall page
load?

- 6.10, odd that there's no padding here

- 8.1, a bit of abnf here might have helped, ah well

- 8.1.2.3, I assume the underscors in "_:authority_" are a
typo, if not they are possibly confusing

- end of p57, does the last para mean that a header field
value can be split betwee a HEADERS frame and the subsequent
CONTINUATION frame (with possible padding in between when
looked at on-the-wire)? If so, then I think you might want
to be clearer about that since I could see it leading to
interop issues. 

- p64, DNS-ID is what (dNSName?)? And "Common Name" might be
better as commonName, but both probably need a reference.
(I don't care about nitty capitalisations, but wouldn't some
coders need to reference?)

- 9.1, which TLS library allows a client to know that it'll
shortly be time to re-key? Doing so is doable, as e.g. NTP
has a mechanism like that for pre-announcing leap seconds
I'm told. Buti I'm not sure anyone actually does it at all
today.

- 9.2.1 - the renegotiation text is confusing. First para on
that starts with "MUST be disable" next one says "MAY use"
for client cert confid. I think adding something like "Other
than as noted below" before the start of  the 1st renego
para (the 3rd para of 9.2.1) might fix this, but could be
some more editing would be better.

- 9.2.2 - Isn't it sad that there are so many undesirable
TLS ciphersuites. Sorry about that;-)

- 10.1 - I think this could be a lot clearer about which
pushed things are to be thrown away and I think being
clearer about that might avoid some future problems.

- 10.5.1 has a few typos, no harm being nice to the RFC
editor and fixing those if you're pushing out a -17

- 10.7 - what general purpose padding does TLS1.2 provide?
I'm sad that this section is so negative - does that
indicate that people haven't really tried this out so much?
While it is clear there can be failed attempts at using
padding to thwart traffic analysis I think having this
mechanism defined so we can in future learn how to better
mitigate traffic analysis is a good thing and we ought not
be so down on that.

- For the record, I'm also sad that this isn't all and only
over TLS with the option of opportunistic security for http:
schemed URIs but I accept that the wg debated that and
decided for this.

[Ballot comment]
This is a very minor point, but this text

  In particular, HTTP/1.0 allowed only one request to be outstanding at
  a time on a given TCP connection.  HTTP/1.1 added request pipelining,
  but this only partially addressed request concurrency and still
  suffers from head-of-line blocking.  Therefore, HTTP/1.1 clients that
  need to make many requests typically use multiple connections to a
  server in order to achieve concurrency and thereby reduce latency.
 
doesn't seem quite right to me. HTTP/1.0 (without persistent connections) closed TCP connections to give an indication that the resource represented by the URL had been completely transferred. "one request to be outstanding at a time on a given TCP connection" sounds like you could send a second request on that TCP connection after you receive a response to the first request, but that's not possible. And HTTP/1.0 clients certainly opened multiple connections to a server as well. Could you look at this text one more time?

In this text

  Endpoints MUST NOT exceed the limit set by their peer.  An endpoint
  that receives a HEADERS frame that causes their advertised concurrent
  stream limit to be exceeded MUST treat this as a stream error
  (Section 5.4.2) of type PROTOCOL_ERROR or REFUSED_STREAM.
 
I'm wondering why both of these stream error types are appropriate here. Is there any guidance about when to choose one type or the other?

In this text:

  After sending a SETTINGS frame that reduces the initial flow control
  window size, a receiver has two options for handling streams that
  exceed flow control limits:

  1.  The receiver can immediately send RST_STREAM with
      FLOW_CONTROL_ERROR error code for the affected streams.

  2.  The receiver can accept the streams and tolerate the resulting
      head of line blocking, sending WINDOW_UPDATE frames as it
      consumes data.
     
I found myself wondering how a receiver would choose between these options. Is there any guidance you could provide?

For this reference:

  [TCP]      Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.
             
perhaps https://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-08, currently in the RFC Editor's queue, would be more appropriate?

[Ballot discuss]
I agree with the other ADs who have complimented the authors on the readability of this spec. I have what I'm assuming to be a very easy Discuss question to resolve, along with a small number of nits as Comments. I expect to be a Yes very soon.

I'm confused between these two statements:

  1.  Flow control is specific to a connection; i.e., it is "hop-by-
      hop", not "end-to-end".

and

  Both types of flow control are hop-by-hop; that is, only between the
  two endpoints.
 
Could you help me get unconfused?

[Ballot comment]
This is a very minor point, but this text

  In particular, HTTP/1.0 allowed only one request to be outstanding at
  a time on a given TCP connection.  HTTP/1.1 added request pipelining,
  but this only partially addressed request concurrency and still
  suffers from head-of-line blocking.  Therefore, HTTP/1.1 clients that
  need to make many requests typically use multiple connections to a
  server in order to achieve concurrency and thereby reduce latency.
 
doesn't seem quite right to me. HTTP/1.0 (without persistent connections) closed TCP connections to give an indication that the resource represented by the URL had been completely transferred. "one request to be outstanding at a time on a given TCP connection" sounds like you could send a second request on that TCP connection after you receive a response to the first request, but that's not possible. And HTTP/1.0 clients certainly opened multiple connections to a server as well. Could you look at this text one more time?

In this text

  Endpoints MUST NOT exceed the limit set by their peer.  An endpoint
  that receives a HEADERS frame that causes their advertised concurrent
  stream limit to be exceeded MUST treat this as a stream error
  (Section 5.4.2) of type PROTOCOL_ERROR or REFUSED_STREAM.
 
I'm wondering why either of two stream error types are appropriate here. Is there any guidance about when to choose one type or the other?

In this text:

  After sending a SETTINGS frame that reduces the initial flow control
  window size, a receiver has two options for handling streams that
  exceed flow control limits:

  1.  The receiver can immediately send RST_STREAM with
      FLOW_CONTROL_ERROR error code for the affected streams.

  2.  The receiver can accept the streams and tolerate the resulting
      head of line blocking, sending WINDOW_UPDATE frames as it
      consumes data.
     
I found myself wondering how a receiver would choose between these options. Is there any guidance you could provide?

For this reference:

  [TCP]      Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.
             
perhaps https://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-08, currently in the RFC Editor's queue, would be more appropriate?

[Ballot discuss]
(1) Section 3.2: "A server MUST ignore a "h2" token in an Upgrade header field."
What is the reasoning behind this exclusion?  This seems to unnecessarily rule out the use of TLS, especially given that the server can opt out by choosing "h2c".

(2) Figure 1 seems really confusing.  If the reader notices the phrase "9 octets of the frame header", he'll probably come to the right conclusion, but it also seems likely that some readers will infer from the layout that the header is 12 octets long, with the fields aligned to word boundaries.  Just eliminating the header with the bit positions would help a lot.  Likewise for the figures in Section 6.

(3) Section 9.1.1: "For "http" resources..."
This seems to imply that requests for "http" resources can only be carried over bare TCP, which seems wrong given the presence of the ":scheme" pseudo-header.  Proposed text:

OLD: "For "http" resources, this depends on the host having resolved to the same IP address."
NEW: "For TCP connections without TLS, this depends on the host having resolved to the same IP address."

(4) Section 9.1.1: "For "https" resources..."
The salient requirement here is that the certificate provided by the server MUST pass any checks that the client would have done if it were initiating the connection afresh.  In addition to the name check here, that would include things like HPKP.  Suggested text:

OLD: "For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI."
NEW: "For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI.  The certificate presented by the server MUST satisfy any checks that the client would perform when forming a new TLS connection for the host in the URI (e.g. HPKP checks [HPKP])."

(5) Section 10.4: "Pushed responses for which an origin server is not authoritative (see Section 10.1) are never cached or used."
This seems like a rather important point, for which I can't find any normative text.  It seems like in Section 8.2.1, the client should be REQUIRED to verify that the ":authority" field in the PUSH_PROMISE contains a value for which the client would have been willing to re-use the connection (as specified in Section 9.1).

[Ballot comment]
Section 2.1:
The definitions of "client" and "server" here are a bit lean.  For example, one might read them and conclude that the client and server roles are independent of who sends requests and responses.  It would be good to clarify these roles, updating the definition in RFC 7230: "An HTTP "client" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests.  An HTTP "server" is a program that accepts connections in order to service HTTP requests by sending HTTP responses."

Section 2.1: "across a virtual channel"
What is a virtual channel?  Can this phrase just be deleted?

Section 3.1: "CREF1: RFC Editor's Note:"
It seems like it could be useful to leave in a variant of this note, describing the variant identifiers used by pre-RFC versions of the protocol.  (And thus removing the RFC 2119 language.)

Section 3.4: "the sever MUST send"

Section 4.1: "R: A reserved 1-bit field."
I was mystified by the purpose of this field until I realized that it's only there because stream IDs are 31 bits (to make room for the Exclusive flag, I guess).  Might help this read more smoothly to note something to that effect here.

Section 5.1:
When I initially read Figure 2, I thought that "H/", "ES/", etc. designated types of frames (or frames + flags).  If, as they appear, they indicate alternatives, it would be clearer to add a space before the "/".

Section 8.1.2.3: "_:authority_"
Remove the underscores?

Section 10.3: "if they are translater verbatim"

[Ballot comment]
3.2 says:

  A server MUST ignore a "h2" token in an Upgrade header field.
  Presence of a token with "h2" implies HTTP/2 over TLS, which is
  instead negotiated as described in Section 3.3.

And 3.3 says:

  HTTP/2 over TLS uses the "h2" application token.  The "h2c" token
  MUST NOT be sent by a client or selected by a server.

Why isn't the presence of an "h2" Upgrade token on a clear text connection, or an "h2c" application token on a TLS connection, grounds for slamming the connection? Seems like something nefarious might be going on in either case. Seems like "MUST NOT send, MUST be a connection error if received" seems like the right thing to do.

4.2 says:

  An endpoint MUST send a FRAME_SIZE_ERROR error if a frame exceeds the
  size defined in SETTINGS_MAX_FRAME_SIZE, any limit defined for the
  frame type, or it is too small to contain mandatory frame data.

But later 5.1 says:

      Receiving any frames other than [blah blah blah]
      on a stream in this state MUST be treated as a connection error
      (Section 5.4.1) of type PROTOCOL_ERROR.

The MUSTs in there appear contradictory. If I get a frame with the wrong type for my current state that is *also* a bogus size, is there a requirement that I do PROTOCOL_ERROR, or FRAME_SIZE_ERROR, or is the choice of error code not really a requirement at all? I suspect that the "MUST be treated as a connection error" is the key and *not* the particular error code. I would re-word to simply say, "The FRAME_SIZE_ERROR error is sent when a frame exceeds..." in 4.2. In 5.1 and elsewhere, you could say something like:

      Receiving any frames other than [blah blah blah]
      on a stream in this state MUST be treated as a connection error
      (Section 5.4.1). Error type PROTOCOL_ERROR can be used for this
      condition.

I just think we'll regret when the protocol police come around saying, "But it said you MUST use such-and-so error code, and he didn't, so it's fine if my implementation does X", where X is a thoroughly idiotic thing.

4.3:

Earlier in the section, you say:

  A complete header block consists of either:

  o  a single HEADERS or PUSH_PROMISE frame, with the END_HEADERS flag
      set, or

  o  a HEADERS or PUSH_PROMISE frame with the END_HEADERS flag cleared
      and one or more CONTINUATION frames, where the last CONTINUATION
      frame has the END_HEADERS flag set.

So you've defined that the last frame (or the only frame if there's no continuation) has the END_HEADERS set. Cool. But then later you make a point to say:

  The last frame in
  a sequence of HEADERS or CONTINUATION frames MUST have the
  END_HEADERS flag set.  The last frame in a sequence of PUSH_PROMISE
  or CONTINUATION frames MUST have the END_HEADERS flag set.

I don't get the MUSTs. What is the situation that I need to look out for here? Is there a circumstance where an implementation might think it's OK to send the last frame without END_HEADERS set? Seems to me those two sentences can be deleted, but maybe I'm missing something.

Also unnecessarily MUSTy:

OLD
  An
  endpoint receiving HEADERS, PUSH_PROMISE or CONTINUATION frames MUST
  reassemble header blocks and perform decompression even if the frames
  are to be discarded.
NEW
  Hence, an endpoint receiving HEADERS, PUSH_PROMISE or CONTINUATION
  frames needs to reassemble header blocks and perform decompression
  even if the frames are to be discarded.
END

5.1:

  open:
      [...]

      From this state either endpoint can send a frame with an
      END_STREAM flag set, which causes the stream to transition into
      one of the "half closed" states: [...].

      Either endpoint can send a RST_STREAM frame from this state,
      causing it to transition immediately to "closed".

You should probably define the silly state of a RST_STREAM frame with and END_STREAM flag set on it. I presume that you immediately go to "closed", but if you implemented it in a goofy way, you may end up in "half closed".

A clarifying bit:

OLD
  half closed (local):
      A stream that is in the "half closed (local)" state cannot be used
      for sending frames.  Only WINDOW_UPDATE, PRIORITY and RST_STREAM
      frames can be sent in this state.
NEW
  half closed (local):
      A stream that is in the "half closed (local)" state cannot be used
      for sending frames other than WINDOW_UPDATE, PRIORITY and
      RST_STREAM.
END

Also:

      If an endpoint receives additional frames for a stream that is in
      this state, other than WINDOW_UPDATE, PRIORITY or RST_STREAM, it
      MUST respond with a stream error (Section 5.4.2) of type
      STREAM_CLOSED.

I think it would be good to introduce some language somewhere, maybe here (and in other places throughout section 6 referring to stream errors) or maybe in 5.4, that says that you MUST respond with a stream error *unless the frame in question would also constitute a connection error, in which case you MUST respond with a connection error*.

5.4.3: I'm not clear on how to implement a "MUST assume". What is it that the implementation MUST do?

8.2.2: I was actually a little surprised to see the SETTINGS_MAX_CONCURRENT_STREAMS suggestion. I would have thought that using window size would be much more obvious. Any reason you chose to discuss one instead of the other?

11.3: No advice or criteria to use for the expert reviewer?

[Ballot comment]
Nice work on this draft!  It is very well written and easy to read.  There was also a lot of thought put into tough security questions like compression and the use of cipher suites in working group sessions, which is very much appreciated.  I have a few non-blocking comments that are mostly editorial.

Editorial consideration: Section 9.2.2 

Thanks for adjusting the language in this section and in Appendix A to avoid confusion, making the WG consensus clear that the blacklist usage is a "SHOULD NOT", changing the word prohibited to "blacklist" works for me.

Followup from last IETF meting and my previous comment:
Section 9.2.2 - I'll note first that there is clear WG consensus for using blacklists.  I'm not expecting a change here, but wanted to note that I think you may run into supportability/cost issues in the future with this approach.

In the current text, any cipher suite that's new (not yet blacklisted) can be supported, which includes regional cipher suites.  Since we are in the midst of a push for crypto and seeing the response from those who monitor, including governments, this opens up room for requirements to be set country by country outside of the protocol.

[Ballot comment]
Thanks for all of your work on this. I'm not thrilled with the decisions around TLS and opportunistic security, but I understand how we got here.

= Section 3.1 =
It might be worth keeping this sentence from the text that is marked for deletion:

"Examples and text throughout the rest of this document use "h2" as a
  matter of editorial convenience only."

= Section 3.2 =
"A server that supports HTTP/2 can accept the upgrade with a 101
  (Switching Protocols) response."

Is there a reason why this behavior is not normatively described? Is there some other response that clients should expect that has the same semantic?

= Section 5.1 =
"WINDOW_UPDATE or RST_STREAM frames can be received in this state
      for a short period after a DATA or HEADERS frame containing an
      END_STREAM flag is sent. ...
      endpoints MAY choose to treat frames that arrive a significant
      time after sending END_STREAM as a connection error
      (Section 5.4.1) of type PROTOCOL_ERROR."

Can some ballpark guidance be given about how long "a short period" and "a significant time" are expected to be? Or how an implementation might calibrate these values?

s/Frame of unknown types/Frames of unknown types/

= Section 5.2.2 =
"Deployments that do not require this capability can advertise a flow
  control window of the maximum size, incrementing the available space
  when new data is received."

I found this a little vague. Does this mean deployments can advertise a flow control window of size 2^31-1 and then locally increment available memory as new data is received? Would be good to state here both what the maximum size is and what is meant by "available space."

= Section 6.8 =
s/the remote can know/the remote peer can know/

= Section 8.2 =

s/that is not cacheable, unsafe or that/that is not cacheable, safe or that/

= Section 10.7 =
"Intermediaries SHOULD retain padding for DATA frames, but MAY drop
  padding for HEADERS and PUSH_PROMISE frames.  A valid reason for an
  intermediary to change the amount of padding of frames is to improve
  the protections that padding provides."

The different recommendations for different frame types here are a bit puzzling. Why are intermediaries expected to be able to improve padding-based protection for HEADERS and PUSH_PROMISE frames more so than for DATA frames?

= Section 10.8 =

Is there anything more you could say about possible mitigations for the fingerprinting issue? Or there might not be, absent some coordination between endpoints, which would likewise be useful to note.

[Ballot comment]
Nice work on this draft!  It is very well written and easy to read.  There was also a lot of thought put into tough security questions like compression and the use of cipher suites in working group sessions, which is very much appreciated.  I have a few non-blocking comments that are mostly editorial.

Editorial suggestion: 3.3, 2nd paragraph:
  HTTP/2 over TLS uses the "h2" application token.  The "h2c" token
  MUST NOT be sent by a client or selected by a server.

It might be helpful to show an example using the application token so the differences between the upgrade token specific to h2c is readily seen from the use of the application token for h2.  There is a similar statement in 3.2 and I think this would prevent any confusion, but that might just be me, so ignore if you think it's clear enough.

Editorial consideration: Section 9.2
Towards the end, would a reference to https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/ be helpful?  I think it would and suggest towards the end as this draft is specific on requirements and you'd want those to stand out.

Editorial consideration: Section 9.2.2 
There is a conflict in the document in that this section says the list in Appendix A SHOULD NOT be used.  The next sentence says the list in the Appendix is prohibited and in Appendix A, the following text appears:
The following cipher suites are prohibited for use in HTTP/2 over TLS.

Is there a reason why the first sentence doesn't say MUST NOT?

Then the following sentences says:
  Consequently, when clients offer a cipher suite that is not
  prohibited, they have to be prepared to use that cipher suite with
  HTTP/2.

Followup from last IETF meting:
Section 9.2.2 - I'll note first that there is clear WG consensus for using blacklists.
Is there a limit to what must be supported?
I do think you'd be better off in the long run with a list of permitted cipher suites instead of a blacklist.  The blacklist included is lengthy and repeats a pattern in information security where you start out with a blacklist and later switch to a white list for manageability (firewalls, AV, etc.).  I see you have the start of a kind-of whitelist with one cipher suite being required (MTI):
To avoid this problem, deployments of HTTP/2
  that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  [TLS-ECDHE] with the P256 elliptic curve [FIPS186].

Any cipher suite that's new (not yet blacklisted), which includes regional cipher suites can be supported in other words.  With the government focus on crypto at the moment this opens up room for requirements to be set country by country outside of the protocol.  Good luck to the vendors, I think it could be difficult in time.

IESG/Authors/WG Chairs:

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

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are eight actions which must be completed.

IANA has questions about some of the requested actions that require Expert Review
according to the relevant defining RFCs.

First, in the Application-Layer Protocol Negotiation (ALPN) Protocol IDs subregistry of the Transport Layer Security (TLS) Extensions registry located at:

http://www.iana.org/assignments/tls-extensiontype-values/

two new protocol IDs will be registered as follows:

Protocol: HTTP/2 over TLS
Identification Sequence: 0x68 0x32 ("h2")
Reference: [ RFC-to-be ]

Protocol: HTTP/2 over TCP
Identification Sequence: 0x68 0x32 0x63 ("h2c")
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 5226) registry, we will initiate the required Expert Review via a separate request.  Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, a new entry is created in the IANA matrix located at:

https://www.iana.org/protocols

called "Hypertext Transfer Protocol (HTTP) 2 Parameters" 

Third, in the new IANA Matrix registry created in action two above, a new registry will be created called the HTTP/2 Frame Type registry. Maintainence of the registry for values 0x00 and 0xef is done via IETF Review or IESG Approval as defined by RFC 5226. Values between 0xf0 and 0xff are reserved for experimental use.

There are initial values in this new registry as follows:

+---------------+------+----------------+
| Frame Type    | Code | Reference      |
+---------------+------+----------------+
| DATA          | 0x0  | [ RFC-to-be ]  |
| HEADERS      | 0x1  | [ RFC-to-be ]  |
| PRIORITY      | 0x2  | [ RFC-to-be ]  |
| RST_STREAM    | 0x3  | [ RFC-to-be ]  |
| SETTINGS      | 0x4  | [ RFC-to-be ]  |
| PUSH_PROMISE  | 0x5  | [ RFC-to-be ]  |
| PING          | 0x6  | [ RFC-to-be ]  |
| GOAWAY        | 0x7  | [ RFC-to-be ]  |
| WINDOW_UPDATE | 0x8  | [ RFC-to-be ]  |
| CONTINUATION  | 0x9  | [ RFC-to-be ]  |
+---------------+------+----------------+

Fourth, also in the new IANA Matrix registry created in action two above, a new registry will be created called the HTTP/2 Settings Registry. Maintenance of the registry for values 0x0000 to 0xefff is done through Expert Review as defined in RFC 5226. Values between 0xf000 and 0xffff are reserved for experimental use.

There are initial registrations in the new registry as follows:

+------------------------+------+---------------+---------------+
| Name                  | Code | Initial Value | Reference    |
+------------------------+------+---------------+---------------+
| HEADER_TABLE_SIZE      | 0x1  | 4096          | [ RFC-to-be ] |
| ENABLE_PUSH            | 0x2  | 1            | [ RFC-to-be ] |
| MAX_CONCURRENT_STREAMS | 0x3  | (infinite)    | [ RFC-to-be ] |
| INITIAL_WINDOW_SIZE    | 0x4  | 65535        | [ RFC-to-be ] |
| MAX_FRAME_SIZE        | 0x5  | 16384        | [ RFC-to-be ] |
| MAX_HEADER_LIST_SIZE  | 0x6  | (infinite)    | [ RFC-to-be ] |
+------------------------+------+---------------+---------------+

Fifth, also in the new IANA Matrix registry created in action two above, a new registry will be created called the HTTP/2 Error Code registry. Maintenance of the registry is done through Expert Review as defined in RFC 5226.

There are initial registrations in the new registry as follows:

+---------------------+------+----------------------+---------------+
| Name                | Code | Description          | Reference    |
+---------------------+------+----------------------+---------------+
| NO_ERROR            | 0x0  | Graceful shutdown    | [ RFC-to-be ] |
| PROTOCOL_ERROR      | 0x1  | Protocol error      | [ RFC-to-be ] |
|                    |      | detected            |              |
| INTERNAL_ERROR      | 0x2  | Implementation fault | [ RFC-to-be ] |
| FLOW_CONTROL_ERROR  | 0x3  | Flow control limits  | [ RFC-to-be ] |
|                    |      | exceeded            |              |
| SETTINGS_TIMEOUT    | 0x4  | Settings not        | [ RFC-to-be ] |
|                    |      | acknowledged        |              |
| STREAM_CLOSED      | 0x5  | Frame received for  | [ RFC-to-be ] |
|                    |      | closed stream        |              |
| FRAME_SIZE_ERROR    | 0x6  | Frame size incorrect | [ RFC-to-be ] |
| REFUSED_STREAM      | 0x7  | Stream not processed | [ RFC-to-be ] |
| CANCEL              | 0x8  | Stream cancelled    | [ RFC-to-be ] |
| COMPRESSION_ERROR  | 0x9  | Compression state    | [ RFC-to-be ] |
|                    |      | not updated          |              |
| CONNECT_ERROR      | 0xa  | TCP connection error | [ RFC-to-be ] |
|                    |      | for CONNECT method  |              |
| ENHANCE_YOUR_CALM  | 0xb  | Processing capacity  | [ RFC-to-be ] |
|                    |      | exceeded            |              |
| INADEQUATE_SECURITY | 0xc  | Negotiated TLS      | [ RFC-to-be ] |
|                    |      | parameters not      |              |
|                    |      | acceptable          |              |
| HTTP_1_1_REQUIRED  | 0xd  | Use HTTP/1.1 for the | [ RFC-to-be ] |
|                    |      | request              |              |
+---------------------+------+----------------------+---------------+

Sixth, in the Permanent Message Header Field Registry of the Message Headers registry located at:

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

a new header field will be registered as follows:

Header Field Name: HTTP2-Settings
Template:
Protocol: http
Status: Standard
Reference: [ RFC-to-be ]

This registry is maintained via Expert Review and Expert review will need to be completed for this registration before your document can be approved for publication as an RFC.

Seventh, in the Hypertext Transfer Protocol (HTTP) Method Registry located at:

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

a new method will be registered as follows:

Method Name: PRI
Safe: No
Idempotent: No
Reference: [ RFC-to-be ]

Question: just to double check if the new requested method "PRI" is an abbreviation.
It appears that RFC7231 does not require a full name.


Eighth, in the Hypertext Transfer Protocol (HTTP) Status Code Registry located at:

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

a new status code will be registered as follows:

Value: 421
Description: Misdirected Request
Reference: [ RFC-to-be ]

IANA understands that these eight actions are the only ones 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. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

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 version 2) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol WG
(httpbis) to consider the following document:
- 'Hypertext Transfer Protocol version 2'
  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 2015-01-14. 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


  This specification describes an optimized expression of the semantics
  of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more
  efficient use of network resources and a reduced perception of
  latency by introducing header field compression and allowing multiple
  concurrent messages on the same connection.  It also introduces
  unsolicited push of representations from servers to clients.

  This specification is an alternative to, but does not obsolete, the
  HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.




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

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1737/
  http://datatracker.ietf.org/ipr/2122/
  http://datatracker.ietf.org/ipr/1692/
  http://datatracker.ietf.org/ipr/2506/

# Summary

Mark Nottingham is the Document Shepherd and Working Group Chair. Barry
Leiba is the responsible Area Director.

This specification describes an optimized expression of the semantics of
the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more efficient
use of network resources and a reduced perception of latency by
introducing header field compression and allowing multiple concurrent
messages on the same connection. It also introduces unsolicited push of
representations from servers to clients.

This specification is an alternative to, but does not obsolete, the
HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.

We intend this to be published as a Proposed Standard.


# Review and Consensus

We have enjoyed active participation from a broad community, including
browser vendors, intermediaries (such as CDN and proxy vendors), server
vendors and protocol library authors; this includes both commercial
vendors and open source libraries.

Our current implementation list is at:
  https://github.com/http2/http2-spec/wiki/Implementations
 
Additionally, we have had participation and review from the
non-implementing HTTP community itself. We have substantial external
interest from the Web performance community as well.

We have also coordinated with the W3C, giving them regular updates
through the liaison and the TAG.

Process-wise, we were chartered to do this work in August 2012, with a
submission deadline of November 2014. We have treated that date
seriously, so as to bound the commitment of the developers and
implementers involved. As a result, we had a fairly high frequency of
interim meetings (six in two years), used both to discuss issues and to
hold interop events.

Perhaps inevitably, there have been a number of contentious issues in
the development of HTTP/2. The most notable is listed below; a full
listing of design issues can be found at:
  https://github.com/http2/http2-spec/issues?q=is%3Aissue+label%3Adesign

## Requiring Encryption




HTTP/2 used SPDY as a starting point, and SPDY was only ever implemented
over TLS for HTTPS URLs.

There were many in the Working Group who felt that this constraint
should be explicit in the new protocol. They were motivated not only by
the Snowden revelations, but also other common (and currently passive)
attacks upon HTTP, such as "FireSheep" coffee shop sniffing and the
Google "drive-by wifi" sniffing attacks.

Implementing the protocol over TLS also improves interoperability, since
middleboxes aren't generally able to manipulate the plaintext -- a
perennial problem for HTTP evolution and conformance.

The Working Group had a wide-ranging discussion about this topic, mostly
during and between the August 2013 (Berlin) and January 2014 (Zurich)
meetings.

We considered requiring the use of TLS (through https:// URIs) for
HTTP/2. However, some members of the community pushed back against this,
on the grounds that it would be too onerous for some uses of HTTP (not
necessarily CPU; cost and administration of certificates was cited as a
burden, as was the follow-on disruption to applications, since
transitioning from HTTP to HTTPS often requires non-trivial content
changes, due to the way that the browser security model works).

As a result, we decided to document the use of HTTP/2 for both https://
and http:// URLs, the latter in cleartext (the "h2c" protocol ID),
leaving it up to implementations to decide what they support.

The WG also discussed an "Opportunistic Security" approach to using TLS
for http:// URIs (but without authentication). This was a bit
controversial too, as some community members felt that having another,
weaker kind of security defined harms the long-term deployment of "full"
TLS.

After discussion in June 2014 (New York) we agreed to adopt this
document as an optional extension, but only with Experimental status:
. It's expected
that we'll ship it shortly after HTTP/2.

Overall, I would characterize the WG a having a somewhat uneasy (but
also pragmatic) consensus on this outcome.

To date, we've had one browser implementation express an intent to
requiring https:// URLs for HTTP/2 (i.e., no http://), one interested in
https:// as well as Opportunistic Security for http:// URLs (but not
cleartext http://), and one that is interested in https:// as well as
cleartext http://.

Note that most of the justification for our decision not to require
https:// for HTTP/2 seems to be predicated on this part of our charter
:

"The resulting specification(s) are expected to meet these goals for
common existing deployments of HTTP[.]"

... i.e., it was argued and accepted, based on this text, that requiring
people who can't use https:// to just stay on HTTP/1.1 was unacceptable.
This charter text was written before BCP188 (and the incidents leading
up to it), and also predates the IAB statement on Internet Confidentiality.


# Intellectual Property

Mike Belshe and Martin Thomson have confirmed that they have no direct,
personal knowledge of IPR related to this document.

Roberto Peon is currently working with Google's legal team to update
their disclosure . This
declaration has been brought to the Working Group's attention.

See
for a full list of disclosures regarding this document.


# Other Points

This document has the following downward references:

* FIPS186 (Non-RFC) - not in downref registry
* RFC2818 (Informational) - in downref registry
* RFC5289 (Informational) - not in downref registry

IDNits reports a few warnings; these appear to be spurious.

This document creates three new registries:

* HTTP/2 Frame Type
* HTTP/2 Settings
* HTTP/2 Error Code

The Working Group discussed and selected these policies in the process
of creating these fields; the choices of policy were not contentious.
IANA is advised to select experts that are familiar with HTTP/2 and its
operation, and with ties to the HTTP community.

# Summary

Mark Nottingham is the Document Shepherd and Working Group Chair. Barry
Leiba is the responsible Area Director.

This specification describes an optimized expression of the semantics of
the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more efficient
use of network resources and a reduced perception of latency by
introducing header field compression and allowing multiple concurrent
messages on the same connection. It also introduces unsolicited push of
representations from servers to clients.

This specification is an alternative to, but does not obsolete, the
HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.

We intend this to be published as a Proposed Standard.


# Review and Consensus

We have enjoyed active participation from a broad community, including
browser vendors, intermediaries (such as CDN and proxy vendors), server
vendors and protocol library authors; this includes both commercial
vendors and open source libraries.

Our current implementation list is at:
  https://github.com/http2/http2-spec/wiki/Implementations
 
Additionally, we have had participation and review from the
non-implementing HTTP community itself. We have substantial external
interest from the Web performance community as well.

We have also coordinated with the W3C, giving them regular updates
through the liaison and the TAG.

Process-wise, we were chartered to do this work in August 2012, with a
submission deadline of November 2014. We have treated that date
seriously, so as to bound the commitment of the developers and
implementers involved. As a result, we had a fairly high frequency of
interim meetings (six in two years), used both to discuss issues and to
hold interop events.

Perhaps inevitably, there have been a number of contentious issues in
the development of HTTP/2. The most notable is listed below; a full
listing of design issues can be found at:
  https://github.com/http2/http2-spec/issues?q=is%3Aissue+label%3Adesign

## Requiring Encryption




HTTP/2 used SPDY as a starting point, and SPDY was only ever implemented
over TLS for HTTPS URLs.

There were many in the Working Group who felt that this constraint
should be explicit in the new protocol. They were motivated not only by
the Snowden revelations, but also other common (and currently passive)
attacks upon HTTP, such as "FireSheep" coffee shop sniffing and the
Google "drive-by wifi" sniffing attacks.

Implementing the protocol over TLS also improves interoperability, since
middleboxes aren't generally able to manipulate the plaintext -- a
perennial problem for HTTP evolution and conformance.

The Working Group had a wide-ranging discussion about this topic, mostly
during and between the August 2013 (Berlin) and January 2014 (Zurich)
meetings.

We considered requiring the use of TLS (through https:// URIs) for
HTTP/2. However, some members of the community pushed back against this,
on the grounds that it would be too onerous for some uses of HTTP (not
necessarily CPU; cost and administration of certificates was cited as a
burden, as was the follow-on disruption to applications, since
transitioning from HTTP to HTTPS often requires non-trivial content
changes, due to the way that the browser security model works).

As a result, we decided to document the use of HTTP/2 for both https://
and http:// URLs, the latter in cleartext (the "h2c" protocol ID),
leaving it up to implementations to decide what they support.

The WG also discussed an "Opportunistic Security" approach to using TLS
for http:// URIs (but without authentication). This was a bit
controversial too, as some community members felt that having another,
weaker kind of security defined harms the long-term deployment of "full"
TLS.

After discussion in June 2014 (New York) we agreed to adopt this
document as an optional extension, but only with Experimental status:
. It's expected
that we'll ship it shortly after HTTP/2.

Overall, I would characterize the WG a having a somewhat uneasy (but
also pragmatic) consensus on this outcome.

To date, we've had one browser implementation express an intent to
requiring https:// URLs for HTTP/2 (i.e., no http://), one interested in
https:// as well as Opportunistic Security for http:// URLs (but not
cleartext http://), and one that is interested in https:// as well as
cleartext http://.

Note that most of the justification for our decision not to require
https:// for HTTP/2 seems to be predicated on this part of our charter
:

"The resulting specification(s) are expected to meet these goals for
common existing deployments of HTTP[.]"

... i.e., it was argued and accepted, based on this text, that requiring
people who can't use https:// to just stay on HTTP/1.1 was unacceptable.
This charter text was written before BCP188 (and the incidents leading
up to it), and also predates the IAB statement on Internet Confidentiality.


# Intellectual Property

Mike Belshe and Martin Thomson have confirmed that they has no direct,
personal knowledge of IPR related to this document.

Roberto Peon is currently working with Google's legal team to update
their disclosure . This
declaration has been brought to the Working Group's attention.

See
for a full list of disclosures regarding this document.


# Other Points

This document has the following downward references:

* FIPS186 (Non-RFC) - not in downref registry
* RFC2818 (Informational) - in downref registry
* RFC5289 (Informational) - not in downref registry

IDNits reports a few warnings; these appear to be spurious.

This document creates three new registries:

* HTTP/2 Frame Type
* HTTP/2 Settings
* HTTP/2 Error Code

The Working Group discussed and selected these policies in the process
of creating these fields; the choices of policy were not contentious.
IANA is advised to select experts that are familiar with HTTP/2 and its
operation, and with ties to the HTTP community.

# Summary

Mark Nottingham is the Document Shepherd and Working Group Chair. Barry
Leiba is the responsible Area Director.

This specification describes an optimized expression of the semantics of
the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more efficient
use of network resources and a reduced perception of latency by
introducing header field compression and allowing multiple concurrent
messages on the same connection. It also introduces unsolicited push of
representations from servers to clients.

This specification is an alternative to, but does not obsolete, the
HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.

We intend this to be published as a Proposed Standard.


# Review and Consensus

We have enjoyed active participation from a broad community, including
browser vendors, intermediaries (such as CDN and proxy vendors), server
vendors and protocol library authors; this includes both commercial
vendors and open source libraries.

Our current implementation list is at:
  https://github.com/http2/http2-spec/wiki/Implementations
 
Additionally, we have had participation and review from the
non-implementing HTTP community itself. We have substantial external
interest from the Web performance community as well.

We have also coordinated with the W3C, giving them regular updates
through the liaison and the TAG.

Process-wise, we were chartered to do this work in August 2012, with a
submission deadline of November 2014. We have treated that date
seriously, so as to bound the commitment of the developers and
implementers involved. As a result, we had a fairly high frequency of
interim meetings (six in two years), used both to discuss issues and to
hold interop events.

Perhaps inevitably, there have been a number of contentious issues in
the development of HTTP/2. The most notable is listed below; a full
listing of design issues can be found at:
  https://github.com/http2/http2-spec/issues?q=is%3Aissue+label%3Adesign

## Requiring Encryption




HTTP/2 used SPDY as a starting point, and SPDY was only ever implemented
over TLS for HTTPS URLs.

There were many in the Working Group who felt that this constraint
should be explicit in the new protocol. They were motivated not only by
the Snowden revelations, but also other common (and currently passive)
attacks upon HTTP, such as "FireSheep" coffee shop sniffing and the
Google "drive-by wifi" sniffing attacks.

Implementing the protocol over TLS also improves interoperability, since
middleboxes aren't generally able to manipulate the plaintext -- a
perennial problem for HTTP evolution and conformance.

The Working Group had a wide-ranging discussion about this topic, mostly
during and between the August 2013 (Berlin) and January 2014 (Zurich)
meetings.

We considered requiring the use of TLS (through https:// URIs) for
HTTP/2. However, some members of the community pushed back against this,
on the grounds that it would be too onerous for some uses of HTTP (not
necessarily CPU; cost and administration of certificates was cited as a
burden, as was the follow-on disruption to applications, since
transitioning from HTTP to HTTPS often requires non-trivial content
changes, due to the way that the browser security model works).

As a result, we decided to document the use of HTTP/2 for both https://
and http:// URLs, the latter in cleartext (the "h2c" protocol ID),
leaving it up to implementations to decide what they support.

The WG also discussed an "Opportunistic Security" approach to using TLS
for http:// URIs (but without authentication). This was a bit
controversial too, as some community members felt that having another,
weaker kind of security defined harms the long-term deployment of "full"
TLS.

After discussion in June 2014 (New York) we agreed to adopt this
document as an optional extension, but only with Experimental status:
. It's expected
that we'll ship it shortly after HTTP/2.

Overall, I would characterize the WG a having a somewhat uneasy (but
also pragmatic) consensus on this outcome.

To date, we've had one browser implementation express an intent to
requiring https:// URLs for HTTP/2 (i.e., no http://), one interested in
https:// as well as Opportunistic Security for http:// URLs (but not
cleartext http://), and one that is interested in https:// as well as
cleartext http://.

Note that most of the justification for our decision not to require
https:// for HTTP/2 seems to be predicated on this part of our charter
:

"The resulting specification(s) are expected to meet these goals for
common existing deployments of HTTP[.]"

... i.e., it was argued and accepted, based on this text, that requiring
people who can't use https:// should just stay on HTTP/1.1 was
unacceptable. This charter text was written before BCP188 (and the
incidents leading up to it), and also predates the IAB statement on
Internet Confidentiality.


# Intellectual Property

Mike Belshe and Martin Thomson have confirmed that they has no direct,
personal knowledge of IPR related to this document.

Roberto Peon is currently working with Google's legal team to update
their disclosure . This
declaration has been brought to the Working Group's attention.

See
for a full list of disclosures regarding this document.


# Other Points

This document has the following downward references:

* FIPS186 (Non-RFC) - not in downref registry
* RFC2818 (Informational) - in downref registry
* RFC5289 (Informational) - not in downref registry

IDNits reports a few warnings; these appear to be spurious.

This document creates three new registries:

* HTTP/2 Frame Type
* HTTP/2 Settings
* HTTP/2 Error Code

The Working Group discussed and selected these policies in the process
of creating these fields; the choices of policy were not contentious.
IANA is advised to select experts that are familiar with HTTP/2 and its
operation, and with ties to the HTTP community.

# Summary

Mark Nottingham is the Document Shepherd and Working Group Chair. Barry Leiba is the responsible Area Director.

This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent messages on the same connection. It also introduces unsolicited push of representations from servers to clients.

This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.

We intend this to be published as a Proposed Standard.


# Review and Consensus

We have enjoyed active participation from a broad community, including browser vendors, intermediaries (such as CDN and proxy vendors), server vendors and protocol library authors; this includes both commercial vendors and open source libraries.

Our current implementation list is at:
  https://github.com/http2/http2-spec/wiki/Implementations
 
Additionally, we have had participation and review from the non-implementing HTTP community itself. We have substantial external interest from the Web performance community as well.

We have also coordinated with the W3C, giving them regular updates through the liaison and the TAG.

Process-wise, we were chartered to do this work in August 2012, with a submission deadline of November 2014. We have treated that date seriously, so as to bound the commitment of the developers and implementers involved. As a result, we had a fairly high frequency of interim meetings (six in two years), used both to discuss issues and to hold interop events.

Perhaps inevitably, there have been a number of contentious issues in the development of HTTP/2. The most notable is listed below; a full listing of design issues can be found at:
  https://github.com/http2/http2-spec/issues?q=is%3Aissue+label%3Adesign

## Requiring Encryption




HTTP/2 used SPDY as a starting point, and SPDY was only ever implemented over TLS for HTTPS URLs.

There were many in the Working Group who felt that this constraint should be explicit in the new protocol. They were motivated not only by the Snowden revelations, but also other common (and currently passive) attacks upon HTTP, such as "FireSheep" coffee shop sniffing and the Google "drive-by wifi" sniffing attacks.

Implementing the protocol over TLS also improves interoperability, since middleboxes aren't generally able to manipulate the plaintext -- a perennial problem for HTTP evolution and conformance.

The Working Group had a wide-ranging discussion about this topic, mostly during and between the August 2013 (Berlin) and January 2014 (Zurich) meetings.

We considered requiring the use of TLS (through https:// URIs) for HTTP/2. However, some members of the community pushed back against this, on the grounds that it would be too onerous for some uses of HTTP (not necessarily CPU; cost and administration of certificates was cited as a burden, as was the follow-on disruption to applications, since transitioning from HTTP to HTTPS often requires non-trivial content changes, due to the way that the browser security model works).

As a result, we decided to document the use of HTTP/2 for both https:// and http:// URLs, the latter in cleartext (the "h2c" protocol ID), leaving it up to implementations to decide what they support.

The WG also discussed an "Opportunistic Security" approach to using TLS for http:// URIs (but without authentication). This was a bit controversial too, as some community members felt that having another, weaker kind of security defined harms the long-term deployment of "full" TLS.

After discussion in June 2014 (New York) we agreed to adopt this document as an optional extension, but only with Experimental status: . It's expected that we'll ship it shortly after HTTP/2.

Overall, I would characterize the WG a having a somewhat uneasy (but also pragmatic) consensus on this outcome.

To date, we've had one browser implementation express an intent to requiring https:// URLs for HTTP/2 (i.e., no http://), one interested in https:// as well as Opportunistic Security for http:// URLs (but not cleartext http://), and one that is interested in https:// as well as cleartext http://.

Note that most of the justification for our decision not to require https:// for HTTP/2 seems to be predicated on this part of our charter :

"The resulting specification(s) are expected to meet these goals for common existing deployments of HTTP[.]"

... i.e., it was argued and accepted, based on this text, that requiring people who can't use https:// should just stay on HTTP/1.1 was unacceptable. This charter text was written before BCP188 (and the incidents leading up to it), and also predates the IAB statement on Internet Confidentiality.


# Intellectual Property

Mike Belshe and Martin Thomson have confirmed that they has no direct, personal knowledge of IPR related to this document.

Roberto Peon is currently working with Google's legal team to update their disclosure . This declaration has been brought to the Working Group's attention.

See  for a full list of disclosures regarding this document.


# Other Points

This document has the following downward references:

* FIPS186 (Non-RFC) - not in downref registry
* RFC2818 (Informational) - in downref registry
* RFC5289 (Informational) - not in downref registry

IDNits reports a few warnings; these appear to be spurious.

This document creates three new registries:

* HTTP/2 Frame Type
* HTTP/2 Settings
* HTTP/2 Error Code

The Working Group discussed and selected these policies in the process of creating these fields; the choices of policy were not contentious. IANA is advised to select experts that are familiar with HTTP/2 and its operation, and with ties to the HTTP community.