Subject: [quicwg/base-drafts] Replace SETTINGS with EXTENDED_SETTINGS (#80)

From: Mike Bishop <[email-masked]>
Date: Fri, 09 Dec 2016 13:28:49 -0800

[EXTENDED_SETTINGS](https://tools.ietf.org/html/draft-bishop-httpbis-extended-settings-01) was proposed in the HTTP WG as an extension providing an alternative to the HTTP/2 SETTINGS frame.  While feedback was that it was "the design we should have had for HTTP/2... more general, saves space in most cases, and includes a flag to request acknowledgment", there was also a feeling that as an extension it was overkill since most things that needed settings already used SETTINGS.  The advice was to hold it for HTTP/QUIC and make it the default SETTINGS frame there.  So here it is.

Note that while it uses a slightly different ACK mechanism than HTTP/2 SETTINGS, it's subject to the same timing issues as HTTP/2 SETTINGS ACK over QUIC, namely that you can't know when the setting change has been applied on each stream.  This pull request doesn't fix that; it's tracked by #75 still.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/80

-- Commit Summary --

  * Replace SETTINGS with EXTENDED_SETTINGS

-- File Changes --

    M draft-ietf-quic-http.md (183)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/80.patch
https://github.com/quicwg/base-drafts/pull/80.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/80

---

From: Martin Thomson <[email-masked]>
Date: Fri, 09 Dec 2016 14:18:37 -0800

martinthomson commented on this pull request.

This looks good enough to merge.  A few nits though.

> -  frames with ACK bit set, as in HTTP/2, or rely on transport- level
-  acknowledgment.
+The SETTINGS frame (type=0x4) conveys configuration parameters that affect how 
+endpoints communicate, such as preferences and constraints on peer behavior, and 
+is substantially different from {{!RFC7540}}. Individually, a SETTINGS parameter 
+can also be referred to as a "setting". 
+
+SETTINGS parameters are not negotiated; they describe characteristics of the 
+sending peer, which are used by the receiving peer. However, a negotiation can 
+be implied by the use of SETTINGS -- a peer uses SETTINGS to advertise a set of 
+supported values. The recipient can then choose which entries from this list are 
+also acceptable and proceed with the value it has chosen. (This choice could be 
+announced in a field of an extension frame, or in a value in SETTINGS.) 
+
+Different values for the same parameter can be advertised by each peer. For 
+example, a server might support many different signing algorithms, while a 

I wouldn't use signature algorithms as an example here.

> +Different values for the same parameter can be advertised by each peer. For 
+example, a server might support many different signing algorithms, while a 
+resource constrained client has only one or two that it can validate. 
+
+A SETTINGS frame MAY be sent at any time by either endpoint over the lifetime 
+of the connection. 
+
+Each parameter in a SETTINGS frame replaces any existing value for that 
+parameter. Parameters are processed in the order in which they appear, and a 
+receiver of a SETTINGS frame does not need to maintain any state other than the 
+current value of its parameters. Therefore, the value of a SETTINGS parameter is 
+the last value that is seen by a receiver.
+
+The SETTINGS frame defines the following flag: 
+
+  REQUEST_ACK (0x1):

I think that this will be formatted strangely.  You should confirm with [the manual](http://kramdown.gettalong.org/syntax.html) and maybe check the build output.

> +The payload of a SETTINGS frame consists of zero or more parameters, each 
+consisting of an unsigned 16-bit setting identifier and a length-prefixed binary 
+value.
+
+~~~~~~~~~~~~~~~
++-------------------------------+-+-------------+---------------+
+|        Identifier (16)        |B|        Length (15)          |
++-------------------------------+-+-------------+---------------+
+|                          Contents (?)                       ...
++---------------------------------------------------------------+
+~~~~~~~~~~~~~~~
+{: #fig-ext-settings title="SETTINGS value format"}
+
+A zero-length content indicates that the setting value is a Boolean given by the 
+B bit. If Length is not zero, the B bit MUST be zero, and MUST be ignored by 
+receivers. The initial value of each setting is "false." 

> The initial value of a Boolean setting is "false".

> @@ -447,13 +497,12 @@ superseded by QUIC transport parameters in HTTP-over-QUIC. Below is a listing of
 how each HTTP/2 SETTINGS parameter is mapped: 
 
   SETTINGS_HEADER_TABLE_SIZE:
-  : Sent in SETTINGS frame.
+  : An integer with a maximum value of 2^32 - 1.

We need a definition of how to encode integers in the field.  Do we permit leading zero octets?

   SETTINGS_ENABLE_PUSH:
-  : Sent in SETTINGS frame (TBD, currently set using QUIC "SPSH" connection
-    option)
+  : A Boolean

This is unfortunate.  Your change to booleans has made this have a new default.

Nit: missing period.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/80#pullrequestreview-12319111

---

From: Mike Bishop <[email-masked]>
Date: Fri, 09 Dec 2016 15:10:20 -0800

@MikeBishop pushed 1 commit.

6915f0e  Use a different example

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/80/files/a48d8c22ab62ef630f5badbd772dea481969c76a..6915f0e463202608728fa6a72647143ea95d4e91

---

From: Mike Bishop <[email-masked]>
Date: Fri, 09 Dec 2016 15:12:12 -0800

MikeBishop commented on this pull request.

Build output looks fine to me -- is there something specific you're concerned about?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 09 Dec 2016 15:19:38 -0800

You indented here, but I don't believe that this will result in any indenting for the REQUEST_ACK line.

---

From: Mike Bishop <[email-masked]>
Date: Fri, 09 Dec 2016 15:32:24 -0800

b5ec771  Martin's other feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/80/files/6915f0e463202608728fa6a72647143ea95d4e91..b5ec771730359cc59a36e504bdff7777270cd458

---

From: Mike Bishop <[email-masked]>
Date: Fri, 09 Dec 2016 15:32:57 -0800

Updated to address your comments, @martinthomson .

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/80#issuecomment-266152285

---

From: Mike Bishop <[email-masked]>
Date: Fri, 09 Dec 2016 16:31:06 -0800

Ah, I see.  It's indented in the HTML, but not indented in the TXT.  That's consistent with the rest of the document, and with RFC 7540, which uses the same non-indentation for definition lists.  I'm inclined to leave it; if it distresses you, feel free to suggest a change.  ;-)

---

From: Mike Bishop <[email-masked]>
Date: Mon, 12 Dec 2016 14:08:07 -0800

@MikeBishop pushed 2 commits.

7166f37  Merge branch 'master' into extended_settings
9d08e3d  Diagram format for #54 again.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/80/files/b5ec771730359cc59a36e504bdff7777270cd458..9d08e3d465204a29305327b936d9041503336c6c

---

From: Patrick McManus <[email-masked]>
Date: Thu, 15 Dec 2016 13:47:59 -0800

mcmanus approved this pull request.

I think this is definitely a positive change.. included a few minor comments for consideration.

> @@ -437,16 +437,76 @@ Frame type 0x3 is reserved.
 
 ### SETTINGS {#frame-settings}
 
-The SETTINGS frame (type=0x04) is unmodified from {{!RFC7540}} (so far). It MUST 
-only be sent on the connection control stream (Stream 3). 
+The SETTINGS frame (type=0x4) conveys configuration parameters that affect how 
+endpoints communicate, such as preferences and constraints on peer behavior, and 
+is substantially different from {{!RFC7540}}. Individually, a SETTINGS parameter 
+can also be referred to as a "setting". 
+
+SETTINGS parameters are not negotiated; they describe characteristics of the 
+sending peer, which are used by the receiving peer. However, a negotiation can 

s/are/may be/

> @@ -437,16 +437,76 @@ Frame type 0x3 is reserved.
 
 ### SETTINGS {#frame-settings}
 
-The SETTINGS frame (type=0x04) is unmodified from {{!RFC7540}} (so far). It MUST 
-only be sent on the connection control stream (Stream 3). 

s/in/in its own/

> @@ -455,13 +515,13 @@ superseded by QUIC transport parameters in HTTP-over-QUIC. Below is a listing of

now that these are variable length does it need a max size? We can merge extended settings and talk about that as a different issue too

+Once all values have been processed, if the REQUEST_ACK flag was set, the 
+recipient MUST immediately emit a SETTINGS_ACK frame listing the identifiers 

"immediately" has such a real time feel to it - while the requirement is really about ordering of when the new settings can have an impact on the semantics of future I/O.. it should probably be written like that

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/80#pullrequestreview-13226636

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Dec 2016 14:17:22 -0800

334bca2  Wording changes for Patrick

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/80/files/9d08e3d465204a29305327b936d9041503336c6c..334bca26acf447258e33fc35d8a937ea00b16599

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Dec 2016 14:18:08 -0800

a5b2ff0  Possible SETTINGS_ACK proposal (#84)

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/80/files/334bca26acf447258e33fc35d8a937ea00b16599..a5b2ff055b6e11dce2c9ed2c34117cd9b366bcea

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Dec 2016 14:22:49 -0800

Well, I think that's already a ridiculous size for a header table (64KB should be enough for anyone!), but I defined it that way mostly to retain parity with HTTP/2.  For existing settings which are defined as integers already, might as well keep the same valid range where reasonable.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Dec 2016 14:32:56 -0800

10851ab  More of Patrick's and Martin's feedback.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/80/files/a5b2ff055b6e11dce2c9ed2c34117cd9b366bcea..10851ab18092eefe01c5d23d43ed87f126d4aefc

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Dec 2016 14:41:20 -0800

Merged #80.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/80#event-895979590