Hypertext Transfer Protocol Version 2 (HTTP/2)
draft-ietf-httpbis-http2-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-05-09
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-04-27
|
17 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-04-16
|
17 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2015-04-16
|
17 | (System) | RFC Editor state changed to AUTH from EDIT |
2015-03-16
|
17 | Elwyn Davies | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies. |
2015-03-03
|
17 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2015-03-02
|
17 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2015-02-24
|
17 | (System) | RFC Editor state changed to EDIT from IESG |
2015-02-23
|
17 | (System) | RFC Editor state changed to IESG from EDIT |
2015-02-20
|
17 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2015-02-19
|
17 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-02-19
|
17 | (System) | RFC Editor state changed to EDIT |
2015-02-19
|
17 | (System) | Announcement was received by RFC Editor |
2015-02-17
|
17 | Barry Leiba | Notification list changed to httpbis-chairs@ietf.org, draft-ietf-httpbis-http2@ietf.org from mnot@mnot.net, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, draft-ietf-httpbis-http2.all@ietf.org |
2015-02-17
|
17 | (System) | IANA Action state changed to In Progress |
2015-02-17
|
17 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-02-17
|
17 | Cindy Morgan | IESG has approved the document |
2015-02-17
|
17 | Cindy Morgan | Closed "Approve" ballot |
2015-02-17
|
17 | Cindy Morgan | Ballot approval text was generated |
2015-02-17
|
17 | Barry Leiba | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2015-02-10
|
17 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-02-10
|
17 | Martin Thomson | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2015-02-10
|
17 | Martin Thomson | New version available: draft-ietf-httpbis-http2-17.txt |
2015-01-31
|
16 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2015-01-30
|
16 | Richard Barnes | [Ballot Position Update] Position for Richard Barnes has been changed to Yes from Discuss |
2015-01-28
|
16 | Richard Barnes | [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." … [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). |
2015-01-28
|
16 | Richard Barnes | Ballot discuss text updated for Richard Barnes |
2015-01-26
|
16 | Stephen Farrell | [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 … [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. |
2015-01-26
|
16 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2015-01-23
|
16 | Spencer Dawkins | [Ballot comment] Thanks for working through my Discuss and comments! Clearing now ... |
2015-01-23
|
16 | Spencer Dawkins | [Ballot Position Update] Position for Spencer Dawkins has been changed to No Objection from Discuss |
2015-01-22
|
16 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2015-01-22
|
16 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Chris Lonvick. |
2015-01-22
|
16 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-01-22
|
16 | Amy Vezza | Changed consensus to Yes from Unknown |
2015-01-22
|
16 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2015-01-22
|
16 | Stephen Farrell | [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 … [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.) |
2015-01-22
|
16 | Stephen Farrell | [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 … [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. |
2015-01-22
|
16 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2015-01-22
|
16 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-01-22
|
16 | Benoît Claise | [Ballot comment] Thank you for a very well-written writeup, which helped the review. Same remark as Richard regarding figure 1 |
2015-01-22
|
16 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-01-21
|
16 | Joel Jaeggli | [Ballot comment] This has been a long time in coming, thank you. |
2015-01-21
|
16 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-01-21
|
16 | Spencer Dawkins | [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 … [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? |
2015-01-21
|
16 | Spencer Dawkins | Ballot comment text updated for Spencer Dawkins |
2015-01-21
|
16 | Spencer Dawkins | [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 … [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? |
2015-01-21
|
16 | Spencer Dawkins | [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 … [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? |
2015-01-21
|
16 | Spencer Dawkins | [Ballot Position Update] New position, Discuss, has been recorded for Spencer Dawkins |
2015-01-21
|
16 | Richard Barnes | [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 … [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). |
2015-01-21
|
16 | Richard Barnes | [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 … [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" |
2015-01-21
|
16 | Richard Barnes | [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes |
2015-01-21
|
16 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2015-01-21
|
16 | Pete Resnick | [Ballot comment] 3.2 says: A server MUST ignore a "h2" token in an Upgrade header field. Presence of a token with "h2" implies … [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? |
2015-01-21
|
16 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2015-01-21
|
16 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2015-01-21
|
16 | Kathleen Moriarty | [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 … [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. |
2015-01-21
|
16 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to Yes from No Objection |
2015-01-21
|
16 | Martin Stiemerling | [Ballot comment] An excellent document. Alissa spotted already what I would have remarked about the "short period" in Section 5.1. |
2015-01-21
|
16 | Martin Stiemerling | [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling |
2015-01-20
|
16 | Alissa Cooper | [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 … [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. |
2015-01-20
|
16 | Alissa Cooper | [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper |
2015-01-20
|
16 | Kathleen Moriarty | [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 … [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. |
2015-01-20
|
16 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-01-17
|
16 | Barry Leiba | Ballot has been issued |
2015-01-17
|
16 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2015-01-17
|
16 | Barry Leiba | Created "Approve" ballot |
2015-01-17
|
16 | Barry Leiba | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2015-01-15
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2015-01-15
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2015-01-14
|
16 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2015-01-13
|
16 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2015-01-13
|
16 | Pearl Liang | 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 … 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. |
2015-01-04
|
16 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mahalingam Mani |
2015-01-04
|
16 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mahalingam Mani |
2015-01-02
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2015-01-02
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2015-01-02
|
16 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2015-01-02
|
16 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2014-12-31
|
16 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-12-31
|
16 | Amy Vezza | 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) … 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/ |
2014-12-31
|
16 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-12-31
|
16 | Amy Vezza | Last call announcement was changed |
2014-12-29
|
16 | Barry Leiba | Placed on agenda for telechat - 2015-01-22 |
2014-12-29
|
16 | Barry Leiba | Last call was requested |
2014-12-29
|
16 | Barry Leiba | Last call announcement was generated |
2014-12-29
|
16 | Barry Leiba | Ballot approval text was generated |
2014-12-29
|
16 | Barry Leiba | IESG state changed to Last Call Requested from AD Evaluation |
2014-12-18
|
(System) | Posted related IPR disclosure: Google Inc.'s Statement about IPR related to draft-ietf-httpbis-http2-16 and draft-ietf-httpbis-header-compression-10 | |
2014-12-17
|
16 | Barry Leiba | IESG state changed to AD Evaluation from Publication Requested |
2014-12-17
|
16 | Barry Leiba | Ballot writeup was changed |
2014-12-17
|
16 | Barry Leiba | # Summary Mark Nottingham is the Document Shepherd and Working Group Chair. Barry Leiba is the responsible Area Director. This specification describes an optimized expression … # 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. |
2014-12-17
|
16 | Barry Leiba | # Summary Mark Nottingham is the Document Shepherd and Working Group Chair. Barry Leiba is the responsible Area Director. This specification describes an optimized expression … # 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. |
2014-12-17
|
16 | Barry Leiba | # Summary Mark Nottingham is the Document Shepherd and Working Group Chair. Barry Leiba is the responsible Area Director. This specification describes an optimized expression … # 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. |
2014-12-17
|
16 | Barry Leiba | Ballot writeup was generated |
2014-12-16
|
16 | Mark Nottingham | # Summary Mark Nottingham is the Document Shepherd and Working Group Chair. Barry Leiba is the responsible Area Director. This specification describes an optimized expression … # 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. |
2014-12-16
|
16 | Mark Nottingham | State Change Notice email list changed to mnot@mnot.net, httpbis-chairs@tools.ietf.org, ietf-http-wg@w3.org, draft-ietf-httpbis-http2.all@tools.ietf.org |
2014-12-16
|
16 | Mark Nottingham | Responsible AD changed to Barry Leiba |
2014-12-16
|
16 | Mark Nottingham | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2014-12-16
|
16 | Mark Nottingham | IESG state changed to Publication Requested |
2014-12-16
|
16 | Mark Nottingham | IESG process started in state Publication Requested |
2014-12-15
|
16 | Mark Nottingham | Changed document writeup |
2014-12-15
|
16 | Mark Nottingham | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2014-12-15
|
16 | Mark Nottingham | Changed document writeup |
2014-11-29
|
16 | Martin Thomson | New version available: draft-ietf-httpbis-http2-16.txt |
2014-10-27
|
15 | Martin Thomson | New version available: draft-ietf-httpbis-http2-15.txt |
2014-10-06
|
14 | Mark Nottingham | Changed document writeup |
2014-10-06
|
14 | Mark Nottingham | Changed document writeup |
2014-10-06
|
14 | Mark Nottingham | Document shepherd changed to Mark Nottingham |
2014-07-31
|
14 | Mark Nottingham | IETF WG state changed to In WG Last Call from WG Document |
2014-07-30
|
14 | Martin Thomson | New version available: draft-ietf-httpbis-http2-14.txt |
2014-07-01
|
13 | Mark Nottingham | This document now replaces draft-mbelshe-httpbis-spdy instead of None |
2014-07-01
|
13 | Mark Nottingham | Intended Status changed to Proposed Standard from None |
2014-06-17
|
13 | Martin Thomson | New version available: draft-ietf-httpbis-http2-13.txt |
2014-04-23
|
12 | Martin Thomson | New version available: draft-ietf-httpbis-http2-12.txt |
2014-04-03
|
11 | Martin Thomson | New version available: draft-ietf-httpbis-http2-11.txt |
2014-02-13
|
10 | Martin Thomson | New version available: draft-ietf-httpbis-http2-10.txt |
2013-12-04
|
09 | Martin Thomson | New version available: draft-ietf-httpbis-http2-09.txt |
2013-11-11
|
08 | Martin Thomson | New version available: draft-ietf-httpbis-http2-08.txt |
2013-10-21
|
07 | Martin Thomson | New version available: draft-ietf-httpbis-http2-07.txt |
2013-08-21
|
06 | Martin Thomson | New version available: draft-ietf-httpbis-http2-06.txt |
2013-08-12
|
05 | Martin Thomson | New version available: draft-ietf-httpbis-http2-05.txt |
2013-07-09
|
(System) | Posted related IPR disclosure: Microsoft Corporation's Statement about IPR related to draft-ietf-httpbis-http2-04 | |
2013-07-08
|
04 | Martin Thomson | New version available: draft-ietf-httpbis-http2-04.txt |
2013-05-29
|
03 | Martin Thomson | New version available: draft-ietf-httpbis-http2-03.txt |
2013-04-03
|
02 | Martin Thomson | New version available: draft-ietf-httpbis-http2-02.txt |
2013-01-21
|
01 | Martin Thomson | New version available: draft-ietf-httpbis-http2-01.txt |
2012-11-29
|
00 | Martin Thomson | New version available: draft-ietf-httpbis-http2-00.txt |