So I know this is late, so I'm not filing an issue pending the advice of
the recipients here.

Section 4.1.1.1:



(4.a1)   Pseudo-header fields are not HTTP fields.  Endpoints MUST NOT

(4.a2)   generate pseudo-header fields other than those defined in this

(4.a3)   document, except as negotiated via an extension; see Section
9 <https://tools.ietf.org/html/draft-ietf-quic-http-31#section-9>.



Section 9 describes a list of registries for an expanding properties:
9 <https://tools.ietf.org/html/draft-ietf-quic-http-31#section-9>.
Extensions to HTTP/3

(9.a1)   HTTP/3 permits extension of the protocol.  Within the limitations

(9.a2)   described in this section, protocol extensions can be used to provide

(9.a3)   additional services or alter any aspect of the protocol.  Extensions

(9.a4)   are effective only within the scope of a single HTTP/3 connection.



(9.b1)   This applies to the protocol elements defined in this document.  This

(9.b2)   does not affect the *existing options for extending HTTP*, such as

(9.b3)   defining new methods, status codes, or *fields*.



(9.c1)   Extensions are permitted to use new frame types (Section 7.2
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-7.2>),
new

(9.c2)   settings (Section 7.2.4.1
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-7.2.4.1>),
new error codes (Section 8
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-8>), or
new

(9.c3)   unidirectional stream types (Section 6.2
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-6.2>).
Registries are

(9.c4)   established for managing these extension points: frame types

(9.c5)   (Section 11.2.1
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-11.2.1>),
settings (Section 11.2.2
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-11.2.2>),
error codes

(9.c6)   (Section 11.2.3
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-11.2.3>),
and stream types (Section 11.2.4
<https://tools.ietf.org/html/draft-ietf-quic-http-31#section-11.2.4>).


If 4.1.1.1 is accurate, then shouldn't there be a registry for HTTP/3
pseudoheaders? IIUC pseudoheader extensions are not possible in HTTP
or HTTP/2, so this is an H3-specific registry.


Martin

Reply via email to