[quicwg/base-drafts] Possible ambiguity for Handling Reserved HTTP/2 Settings parameters type values (#4809)

[Lucas Pardue <[e-mail]>]

https://tools.ietf.org/html/draft-ietf-quic-http-33#section-7.2.4.1 says:

>    Setting identifiers which were used in HTTP/2 where there is no
>    corresponding HTTP/3 setting have also been reserved
>    (Section 11.2.2).  These settings MUST NOT be sent, and their receipt
>    MUST be treated as a connection error of type H3_SETTINGS_ERROR.

The table of defined HTTP/3 settings is in https://tools.ietf.org/html/draft-ietf-quic-http-33#section-11.2.2

```
  +========================+=======+=================+===========+
     | Setting Name           | Value | Specification   | Default   |
     +========================+=======+=================+===========+
     | Reserved               |  0x2  | N/A             | N/A       |
     +------------------------+-------+-----------------+-----------+
     | Reserved               |  0x3  | N/A             | N/A       |
     +------------------------+-------+-----------------+-----------+
     | Reserved               |  0x4  | N/A             | N/A       |
     +------------------------+-------+-----------------+-----------+
     | Reserved               |  0x5  | N/A             | N/A       |
     +------------------------+-------+-----------------+-----------+
     | MAX_FIELD_SECTION_SIZE |  0x6  | Section 7.2.4.1 | Unlimited |
     +------------------------+-------+-----------------+-----------+
 ```

The [HTTP/2 settings IANA registry](https://www.iana.org/assignments/http2-parameters/http2-parameters.xhtml#settings) diverges a little bit from everything that is stated in RFC 7540. `0x0` is stated as reserved in IANA but no mention of it in RFC 7540. Therefore it is ambiguous if an HTTP/3 implementation should reject this Type value.

The range `0xf000-0xffff` is reserved for HTTP/2 experimental use. Its not clear if I should reject those too.

IANA also includes some extension settings: `0x8` (RFC 8441), 0x10 (MS-HTTP2E). I might expect `0x8` to be reused by some extension that defines Websocket over H3. `0x10` seems like something that is not reusable?

And finally, we have Extensible Priorities that defines SETTINGS_DEPRECATE_HTTP2_PRIORITIES and wants to claim `0x9`. I don't expect any need to also define that in HTTP/3 settings, unless the purpose is to prohibit it.

In summary, I don't think there is a huge problem. Maybe we can editorialize our way out of the ambiguity. However, I'd really like to avoid H/3 connections instantly failing due to implementations disagreeing about this rejection requirement.


-- 
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/issues/4809