Possible ambiguity for Handling Reserved HTTP/2 Settings parameters type values

[LPardue]

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 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.

[LPardue]

I overlooked that @kaduk already made the point about 0x0 in #4782.

[MikeBishop]

The intent is to reserve things that are defined in 7540; things reserved by other extensions might later be defined for HTTP/3, so there shouldn't be any assumptions. Let's make that requirement crisper to apply specifically to those values explicitly reserved.

[LPardue]

WfM

[kaduk]

I wonder if we should ask IANA if they can tell how it came to be that 0x0 was marked as reserved with 7540 as the reference even though we are failing to see what part of 7540 should be effectuating that.