RE: h2 Connection Preface

See my answers below,

Hervé.

> -----Original Message-----
> From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]
> Sent: mardi 9 septembre 2014 17:51
> To: Simpson, Robby (GE Energy Management); ietf-http-wg@w3.org
> Subject: RE: h2 Connection Preface
> 
> I agree with concerns 1, 2 and 3. By Robby's interpretations the statements in
> 3.5 and 6.5.3 seem mutually exclusive.
> 
> However, a different view is that 6.5 and 6.5.3 implicitly states rules for ACK
> that do allow such behaviour. It is not immediately clear if all SETTINGS are
> ACK'd or only those containing 'updated' parameters.
> 
> > SETTINGS parameters are acknowledged by the receiving peer.
> 
> > Most values in SETTINGS benefit from or require an understanding of when
> the peer has received and applied the changed parameter values.
> 
> In other words, is it implied that no ACK is required if an end point sends a
> SETTINGS frame with parameters identical to a previous SETTINGS frame. No
> change was made, so there was nothing to ACK?

This sentence is intended to provide background for the reason why a SETTINGS ack is required by the spec.
So even when the SETTINGS parameters are identical to those of the previous SETTINGS frame, section 6.5.3 is applied and a SETTINGS frame with the ACK flag set is sent.

> Does this argument extend to the preface SETTINGS frame containing
> parameters identical to the defined initial values?

The preface SETTINGS frame is always ACK'd.

> Are empty settings frames never ACK'd?

All SETTINGS frame are ACK'd, otherwise, the sender of a SETTINGS frame can no longer match received SETTINGS ACKs to sent SETTINGS.
 
> 
> Concern 3)
> >   In some configurations, it is
> >   possible for the server to transmit SETTINGS before the client,
> >   providing an opportunity to avoid this issue.
> 
> Before the client does what? If SETTINGS are part of the client preface or
> HTTP/1.1 upgrade request (HTTP2-Settings header), in the h2c perspective, I
> am unable to see how the server can send SETTINGS before the client.

It should read "before the client sends additional frames".

> >   The client sends the client connection preface
> >   immediately upon receipt of a 101 Switching Protocols response (indicating
> a successful upgrade),
> >   or as the first application data octets of a TLS connection.
> 
> This seems to imply that even over TLS the client sends a connection preface
> first, although it could be argued the statement is made from the client
> perspective. Perhaps it is hinting that after TLS connection either client or
> server can send a SETTINGS frame first?
> 
> Lucas
> 
> 
>

Received on Tuesday, 9 September 2014 16:34:39 UTC