Re: [quicwg/base-drafts] Move server's SETTINGS to transport parameters (#2958)

[Lucas Pardue <[e-mail]>]

LPardue requested changes on this pull request.

Some nits. Also for completeness you'll want to fixup the QPACK spec's reference to SETTINGS frame as well.

> +sending peer, which can be used by the receiving peer. However, a negotiation
+can be implied by the use of settings - each peer uses settings to advertise a
+set of supported values. The definition of the setting would describe how each
+peer combines the two sets to conclude which choice will be used.  The settings
+mechanism does not provide a mechanism to identify when the choice takes effect.
+
+Different values for the same parameter can be advertised by each peer. For
+example, a client might be willing to consume a very large response header,
+while servers are more cautious about request size.
+
+The same setting identifier MUST NOT occur more than once in settings.
+A receiver MAY treat the presence of duplicate setting identifiers as a
+connection error of type HTTP_SETTINGS_ERROR.
+
+Each parameter consists of a setting identifier and a value, both encoded as
+QUCI variable-length integers, as shown in {{fig-ext-settings}}. A settings

```suggestion
QUIC variable-length integers, as shown in {{fig-ext-settings}}. A settings
```

>  | DATA           | No             | Yes            | Yes         | {{frame-data}}           |
 | HEADERS        | No             | Yes            | Yes         | {{frame-headers}}        |
 | CANCEL_PUSH    | Yes            | No             | No          | {{frame-cancel-push}}    |
-| SETTINGS       | Yes (1)        | No             | No          | {{frame-settings}}       |
 | PUSH_PROMISE   | No             | Yes            | No          | {{frame-push-promise}}   |
 | GOAWAY         | Yes            | No             | No          | {{frame-goaway}}         |
 | MAX_PUSH_ID    | Yes            | No             | No          | {{frame-max-push-id}}    |

Note that the side effect of this change is that is removes the only remaining instance of (1), which is described underneath the table ("Certain frames can only occur as the first frame of a particular stream type"). So we probably want to remove that foot note as part of this PR.

> @@ -1498,9 +1479,8 @@ protocol elements.  Implementations MUST discard frames and unidirectional
 streams that have unknown or unsupported types.  This means that any of these
 extension points can be safely used by extensions without prior arrangement or
 negotiation.  However, where a known frame type is required to be in a specific
-location, such as the SETTINGS frame as the first frame of the control stream
-(see {{control-streams}}), an unknown frame type does not satisfy that
-requirement and SHOULD be treated as an error.
+location, an unknown frame type does not satisfy that requirement and SHOULD be
+treated as an error.

With removing of SETTINGS there is no other case in the core HTTP/3 document that requires specific frame location. So I think this whole "However" clause can just be removed and make the text clearer.

> @@ -1529,6 +1529,33 @@ handshake or by frames sent in 1-RTT packets.  A server MAY treat use of updated
 transport parameters in 0-RTT as a connection error of type PROTOCOL_VIOLATION.
 
 
+### Application Parameters {#app-params}
+
+The transport parameter application_layer_parameters is used by the application
+protocol to exchange application-specific parameters concurrently with the
+cryptographic and transport handshake. The contents of an application parameter
+are opaque to QUIC transport and their semantic meaning is defined by their
+application protocol.
+
+Each application protocol MAY specify use of application parameters to be sent
+by one of or both the client and server. If not specified, an application
+parameter MUST NOT be sent for tht application's ALPN. For each application

```suggestion
parameter MUST NOT be sent for that application's ALPN. For each application
```

-- 
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/2958#pullrequestreview-302756814