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?

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

Are empty settings frames never ACK'd? 

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.

>   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 15:51:18 UTC