- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 9 Sep 2014 15:37:15 -0700
- To: "Simpson, Robby (GE Energy Management)" <robby.simpson@ge.com>
- Cc: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 9 September 2014 11:43, Simpson, Robby (GE Energy Management) <robby.simpson@ge.com> wrote: > Then it sounds like 6.5.3 needs some re-wording and that would resolve my > 2nd concern. When I see "no other frame processing" and "MUST immediately > emit" I think that no other frames are sent until the ACK is sent and that > essentially everything stops when a SETTINGS frame is received. And what > you are saying is that the server MUST send its SETTINGS frame prior to > sending an ACK for the client's SETTINGS frame. Let's show that in context, because the immediately applies to the processing, not the receipt. Any other requirement is a little ridiculous, because your interpretation doesn't allow for the packets already in flight, which can't be taken back. > A piggyback ACK, if possible, would help here. ? >>> Bottom line: I think we need text regarding the acknowledgement of >>> SETTINGS during the connection preface. https://github.com/http2/http2-spec/commit/293e6d041fd9a903ee6dd10b4eee62e0dd618e76 > OK. So the "configurations" in this case are the various "starting" > mechanisms (i.e., HTTP Upgrade, TLS, Prior Knowledge), specifically HTTP > Upgrade. Perhaps "some configurations" should be changed to state the > HTTP Upgrade starting mechanism specifically. TLS 1.3 might allow the server to send application data first. Might. Enumerating the options like this doesn't seem to be particularly useful here. For one, it runs the risk of proscribing behaviour.
Received on Tuesday, 9 September 2014 22:37:44 UTC