W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: h2 Connection Preface

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 9 Sep 2014 15:37:15 -0700
Message-ID: <CABkgnnWY0Dveahz5X4xWFOnwnd7QUn7quoqjvcmdpD_n4nzNAA@mail.gmail.com>
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.


> 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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC