Draft: draft-ietf-quic-http

Commentary: Either s / HTTP / H3 / g or s / HTTP_//g . Because these are n't really HTTP errors , they are HTTP/3 errors . 
 Er , reconsider the existing HTTP _ prefix on h3 error code names so that they are not confused with HTTP status codes . 
 will cause a name clash between for the Transport error code and the HTTP/3 error code . The name clash is not a massive problem but I think it using a prefix is more preferable . 
 Section 8.2 says : However , this directly contradicts TLS 1.3 , which says : In order to say this , this document would need to Update 8446 , and even then it does n't make sense because the presumptive point of this rule is to detect attempts to negotiate QUIC with non - QUIC TLS endpoints , which do n't need to conform to this RFC ( and may predate it ) . 
 I do n't think QUIC can tell anyone what do with regard to any protocol that is not QUIC . And since QUIC v1 carries its own TLS record wrapping it makes even less sense . 
 I agree with the problem statement , however I wonder if this opens a session ticket obtained using TLS13 - over - TCP to be used in QUIC . Is that what we want ? 
 why would this text have an impact on that ? Could n't I negotiate TLS 1.3 over TCP w/o extension and then send the resume over QUIC w/ extension ? 
 The point here is to insist on the alert if the extension is understood . This was n't intended to supersede 8446 . 
 My bad . I was confused with the earlier versions of the QUIC - TLS draft that had the transport_parameters extension in the session tickets . 
 I think you could phrase that , but is it useful , given that we ca n't rely on it ? 
 Probably not . I 'm OK with culling the text .
Paragraph (version A):
If an endpoint receives an invalid sequence of frames on either a
request or a push stream, it MUST respond with a connection error of
type HTTP_FRAME_UNEXPECTED (errors).  In particular, a DATA frame
before any HEADERS frame, or a HEADERS or DATA frame after the
trailing HEADERS frame is considered invalid.
Paragraph (version B):
If an endpoint receives an invalid sequence of frames on either a
request or a push stream, it MUST respond with a connection error of
type H3_FRAME_UNEXPECTED (errors).  In particular, a DATA frame
before any HEADERS frame, or a HEADERS or DATA frame after the
trailing HEADERS frame is considered invalid.
Paragraph (version A):
When a stream is closed, this indicates the end of an HTTP message.
Because some messages are large or unbounded, endpoints SHOULD begin
processing partial HTTP messages once enough of the message has been
received to make progress.  If a client stream terminates without
enough of the HTTP message to provide a complete response, the server
SHOULD abort its response with the error code
HTTP_REQUEST_INCOMPLETE.
Paragraph (version A):
A server can send a complete response prior to the client sending an
entire request if the response does not depend on any portion of the
request that has not been sent and received.  When this is true, a
server MAY abort reading the request stream with error code
HTTP_EARLY_RESPONSE, send a complete response, and cleanly close the
sending part of the stream.  Clients MUST NOT discard complete
responses as a result of having their request terminated abruptly,
though clients can always discard responses at their discretion for
other reasons.
Paragraph (version B):
When a stream is closed, this indicates the end of an HTTP message.
Because some messages are large or unbounded, endpoints SHOULD begin
processing partial HTTP messages once enough of the message has been
received to make progress.  If a client stream terminates without
enough of the HTTP message to provide a complete response, the server
SHOULD abort its response with the error code H3_REQUEST_INCOMPLETE.
Paragraph (version B):
A server can send a complete response prior to the client sending an
entire request if the response does not depend on any portion of the
request that has not been sent and received.  When this is true, a
server MAY abort reading the request stream with error code
H3_EARLY_RESPONSE, send a complete response, and cleanly close the
sending part of the stream.  Clients MUST NOT discard complete
responses as a result of having their request terminated abruptly,
though clients can always discard responses at their discretion for
other reasons.
Paragraph (version A):
Clients can cancel requests by resetting and aborting the request
stream with an error code of HTTP_REQUEST_CANCELLED (http-error-
codes).  When the client aborts reading a response, it indicates that
this response is no longer of interest.  Implementations SHOULD
cancel requests by abruptly terminating any directions of a stream
that are still open.
Paragraph (version A):
When the server rejects a request without performing any application
processing, it SHOULD abort its response stream with the error code
HTTP_REQUEST_REJECTED.  In this context, "processed" means that some
data from the stream was passed to some higher layer of software that
might have taken some action as a result.  The client can treat
requests rejected by the server as though they had never been sent at
all, thereby allowing them to be retried later on a new connection.
Servers MUST NOT use the HTTP_REQUEST_REJECTED error code for
requests which were partially or fully processed.  When a server
abandons a response after partial processing, it SHOULD abort its
response stream with the error code HTTP_REQUEST_CANCELLED.
Paragraph (version A):
When a client resets a request with the error code
HTTP_REQUEST_CANCELLED, a server MAY abruptly terminate the response
using the error code HTTP_REQUEST_REJECTED if no processing was
performed.  Clients MUST NOT use the HTTP_REQUEST_REJECTED error
code, except when a server has requested closure of the request
stream with this error code.
Paragraph (version B):
Clients can cancel requests by resetting and aborting the request
stream with an error code of H3_REQUEST_CANCELLED (http-error-codes).
When the client aborts reading a response, it indicates that this
response is no longer of interest.  Implementations SHOULD cancel
requests by abruptly terminating any directions of a stream that are
still open.
Paragraph (version B):
When the server rejects a request without performing any application
processing, it SHOULD abort its response stream with the error code
H3_REQUEST_REJECTED.  In this context, "processed" means that some
data from the stream was passed to some higher layer of software that
might have taken some action as a result.  The client can treat
requests rejected by the server as though they had never been sent at
all, thereby allowing them to be retried later on a new connection.
Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests
which were partially or fully processed.  When a server abandons a
response after partial processing, it SHOULD abort its response
stream with the error code H3_REQUEST_CANCELLED.
Paragraph (version B):
When a client resets a request with the error code
H3_REQUEST_CANCELLED, a server MAY abruptly terminate the response
using the error code H3_REQUEST_REJECTED if no processing was
performed.  Clients MUST NOT use the H3_REQUEST_REJECTED error code,
except when a server has requested closure of the request stream with
this error code.
Paragraph (version A):
Intermediaries that process HTTP requests or responses (i.e., any
intermediary not acting as a tunnel) MUST NOT forward a malformed
request or response.  Malformed requests or responses that are
detected MUST be treated as a stream error (errors) of type
HTTP_GENERAL_PROTOCOL_ERROR.
Paragraph (version B):
Intermediaries that process HTTP requests or responses (i.e., any
intermediary not acting as a tunnel) MUST NOT forward a malformed
request or response.  Malformed requests or responses that are
detected MUST be treated as a stream error (errors) of type
H3_GENERAL_PROTOCOL_ERROR.
Paragraph (version A):
Once the CONNECT method has completed, only DATA frames are permitted
to be sent on the stream.  Extension frames MAY be used if
specifically permitted by the definition of the extension.  Receipt
of any other frame type MUST be treated as a connection error of type
HTTP_FRAME_UNEXPECTED.
Paragraph (version B):
Once the CONNECT method has completed, only DATA frames are permitted
to be sent on the stream.  Extension frames MAY be used if
specifically permitted by the definition of the extension.  Receipt
of any other frame type MUST be treated as a connection error of type
H3_FRAME_UNEXPECTED.
Paragraph (version A):
A TCP connection error is signaled by abruptly terminating the
stream.  A proxy treats any error in the TCP connection, which
includes receiving a TCP segment with the RST bit set, as a stream
error of type HTTP_CONNECT_ERROR (http-error-codes).
Correspondingly, if a proxy detects an error with the stream or the
QUIC connection, it MUST close the TCP connection.  If the underlying
TCP implementation permits it, the proxy SHOULD send a TCP segment
with the RST bit set.
Paragraph (version B):
A TCP connection error is signaled by abruptly terminating the
stream.  A proxy treats any error in the TCP connection, which
includes receiving a TCP segment with the RST bit set, as a stream
error of type H3_CONNECT_ERROR (http-error-codes).  Correspondingly,
if a proxy detects an error with the stream or the QUIC connection,
it MUST close the TCP connection.  If the underlying TCP
implementation permits it, the proxy SHOULD send a TCP segment with
the RST bit set.
Paragraph (version A):
Server push is only enabled on a connection when a client sends a
MAX_PUSH_ID frame (see frame-max-push-id).  A server cannot use
server push until it receives a MAX_PUSH_ID frame.  A client sends
additional MAX_PUSH_ID frames to control the number of pushes that a
server can promise.  A server SHOULD use Push IDs sequentially,
starting at 0.  A client MUST treat receipt of a push stream with a
Push ID that is greater than the maximum Push ID as a connection
error of type HTTP_ID_ERROR.
Paragraph (version B):
Server push is only enabled on a connection when a client sends a
MAX_PUSH_ID frame (see frame-max-push-id).  A server cannot use
server push until it receives a MAX_PUSH_ID frame.  A client sends
additional MAX_PUSH_ID frames to control the number of pushes that a
server can promise.  A server SHOULD use Push IDs sequentially,
starting at 0.  A client MUST treat receipt of a push stream with a
Push ID that is greater than the maximum Push ID as a connection
error of type H3_ID_ERROR.
Paragraph (version A):
If a promised server push is not needed by the client, the client
SHOULD send a CANCEL_PUSH frame.  If the push stream is already open
or opens after sending the CANCEL_PUSH frame, the client can abort
reading the stream with an error code of HTTP_REQUEST_CANCELLED.
This asks the server not to transfer additional data and indicates
that it will be discarded upon receipt.
Paragraph (version B):
If a promised server push is not needed by the client, the client
SHOULD send a CANCEL_PUSH frame.  If the push stream is already open
or opens after sending the CANCEL_PUSH frame, the client can abort
reading the stream with an error code of H3_REQUEST_CANCELLED.  This
asks the server not to transfer additional data and indicates that it
will be discarded upon receipt.
Paragraph (version A):
Once all accepted requests have been processed, the server can permit
the connection to become idle, or MAY initiate an immediate closure
of the connection.  An endpoint that completes a graceful shutdown
SHOULD use the HTTP_NO_ERROR code when closing the connection.
Paragraph (version B):
Once all accepted requests have been processed, the server can permit
the connection to become idle, or MAY initiate an immediate closure
of the connection.  An endpoint that completes a graceful shutdown
SHOULD use the H3_NO_ERROR code when closing the connection.
Paragraph (version A):
HTTP/3 does not use server-initiated bidirectional streams, though an
extension could define a use for these streams.  Clients MUST treat
receipt of a server-initiated bidirectional stream as a connection
error of type HTTP_STREAM_CREATION_ERROR unless such an extension has
been negotiated.
Paragraph (version B):
HTTP/3 does not use server-initiated bidirectional streams, though an
extension could define a use for these streams.  Clients MUST treat
receipt of a server-initiated bidirectional stream as a connection
error of type H3_STREAM_CREATION_ERROR unless such an extension has
been negotiated.
Paragraph (version A):
If the stream header indicates a stream type which is not supported
by the recipient, the remainder of the stream cannot be consumed as
the semantics are unknown.  Recipients of unknown stream types MAY
abort reading of the stream with an error code of
HTTP_STREAM_CREATION_ERROR, but MUST NOT consider such streams to be
a connection error of any kind.
Paragraph (version B):
If the stream header indicates a stream type which is not supported
by the recipient, the remainder of the stream cannot be consumed as
the semantics are unknown.  Recipients of unknown stream types MAY
abort reading of the stream with an error code of
H3_STREAM_CREATION_ERROR, but MUST NOT consider such streams to be a
connection error of any kind.
Paragraph (version A):
Each side MUST initiate a single control stream at the beginning of
the connection and send its SETTINGS frame as the first frame on this
stream.  If the first frame of the control stream is any other frame
type, this MUST be treated as a connection error of type
HTTP_MISSING_SETTINGS.  Only one control stream per peer is
permitted; receipt of a second stream which claims to be a control
stream MUST be treated as a connection error of type
HTTP_STREAM_CREATION_ERROR.  The sender MUST NOT close the control
stream, and the receiver MUST NOT request that the sender close the
control stream.  If either control stream is closed at any point,
this MUST be treated as a connection error of type
HTTP_CLOSED_CRITICAL_STREAM.
Paragraph (version B):
Each side MUST initiate a single control stream at the beginning of
the connection and send its SETTINGS frame as the first frame on this
stream.  If the first frame of the control stream is any other frame
type, this MUST be treated as a connection error of type
H3_MISSING_SETTINGS.  Only one control stream per peer is permitted;
receipt of a second stream which claims to be a control stream MUST
be treated as a connection error of type H3_STREAM_CREATION_ERROR.
The sender MUST NOT close the control stream, and the receiver MUST
NOT request that the sender close the control stream.  If either
control stream is closed at any point, this MUST be treated as a
connection error of type H3_CLOSED_CRITICAL_STREAM.
Paragraph (version A):
Only servers can push; if a server receives a client-initiated push
stream, this MUST be treated as a connection error of type
HTTP_STREAM_CREATION_ERROR.
Paragraph (version A):
Each Push ID MUST only be used once in a push stream header.  If a
push stream header includes a Push ID that was used in another push
stream header, the client MUST treat this as a connection error of
type HTTP_ID_ERROR.
Paragraph (version B):
Only servers can push; if a server receives a client-initiated push
stream, this MUST be treated as a connection error of type
H3_STREAM_CREATION_ERROR.
Paragraph (version B):
Each Push ID MUST only be used once in a push stream header.  If a
push stream header includes a Push ID that was used in another push
stream header, the client MUST treat this as a connection error of
type H3_ID_ERROR.
Paragraph (version A):
Each frame's payload MUST contain exactly the fields identified in
its description.  A frame payload that contains additional bytes
after the identified fields or a frame payload that terminates before
the end of the identified fields MUST be treated as a connection
error of type HTTP_FRAME_ERROR.
Paragraph (version A):
When a stream terminates cleanly, if the last frame on the stream was
truncated, this MUST be treated as a connection error (errors) of
type HTTP_FRAME_ERROR.  Streams which terminate abruptly may be reset
at any point in a frame.
Paragraph (version B):
Each frame's payload MUST contain exactly the fields identified in
its description.  A frame payload that contains additional bytes
after the identified fields or a frame payload that terminates before
the end of the identified fields MUST be treated as a connection
error of type H3_FRAME_ERROR.
Paragraph (version B):
When a stream terminates cleanly, if the last frame on the stream was
truncated, this MUST be treated as a connection error (errors) of
type H3_FRAME_ERROR.  Streams which terminate abruptly may be reset
at any point in a frame.
Paragraph (version A):
DATA frames MUST be associated with an HTTP request or response.  If
a DATA frame is received on a control stream, the recipient MUST
respond with a connection error (errors) of type
HTTP_FRAME_UNEXPECTED.
Paragraph (version B):
DATA frames MUST be associated with an HTTP request or response.  If
a DATA frame is received on a control stream, the recipient MUST
respond with a connection error (errors) of type H3_FRAME_UNEXPECTED.
Paragraph (version A):
HEADERS frames can only be sent on request / push streams.  If a
HEADERS frame is received on a control stream, the recipient MUST
respond with a connection error (errors) of type
HTTP_FRAME_UNEXPECTED.
Paragraph (version B):
HEADERS frames can only be sent on request / push streams.  If a
HEADERS frame is received on a control stream, the recipient MUST
respond with a connection error (errors) of type H3_FRAME_UNEXPECTED.
Paragraph (version A):
A CANCEL_PUSH frame is sent on the control stream.  Receiving a
CANCEL_PUSH frame on a stream other than the control stream MUST be
treated as a connection error of type HTTP_FRAME_UNEXPECTED.
Paragraph (version A):
The CANCEL_PUSH frame carries a Push ID encoded as a variable-length
integer.  The Push ID identifies the server push that is being
cancelled (see frame-push-promise).  If a CANCEL_PUSH frame is
received which references a Push ID greater than currently allowed on
the connection, this MUST be treated as a connection error of type
HTTP_ID_ERROR.
Paragraph (version A):
If the client receives a CANCEL_PUSH frame, that frame might identify
a Push ID that has not yet been mentioned by a PUSH_PROMISE frame due
to reordering.  If a server receives a CANCEL_PUSH frame for a Push
ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST
be treated as a connection error of type HTTP_ID_ERROR.
Paragraph (version B):
A CANCEL_PUSH frame is sent on the control stream.  Receiving a
CANCEL_PUSH frame on a stream other than the control stream MUST be
treated as a connection error of type H3_FRAME_UNEXPECTED.
Paragraph (version B):
The CANCEL_PUSH frame carries a Push ID encoded as a variable-length
integer.  The Push ID identifies the server push that is being
cancelled (see frame-push-promise).  If a CANCEL_PUSH frame is
received which references a Push ID greater than currently allowed on
the connection, this MUST be treated as a connection error of type
H3_ID_ERROR.
Paragraph (version B):
If the client receives a CANCEL_PUSH frame, that frame might identify
a Push ID that has not yet been mentioned by a PUSH_PROMISE frame due
to reordering.  If a server receives a CANCEL_PUSH frame for a Push
ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST
be treated as a connection error of type H3_ID_ERROR.
Paragraph (version A):
SETTINGS frames always apply to a connection, never a single stream.
A SETTINGS frame MUST be sent as the first frame of each control
stream (see control-streams) by each peer, and MUST NOT be sent
subsequently.  If an endpoint receives a second SETTINGS frame on the
control stream, the endpoint MUST respond with a connection error of
type HTTP_FRAME_UNEXPECTED.
Paragraph (version A):
SETTINGS frames MUST NOT be sent on any stream other than the control
stream.  If an endpoint receives a SETTINGS frame on a different
stream, the endpoint MUST respond with a connection error of type
HTTP_FRAME_UNEXPECTED.
Paragraph (version B):
SETTINGS frames always apply to a connection, never a single stream.
A SETTINGS frame MUST be sent as the first frame of each control
stream (see control-streams) by each peer, and MUST NOT be sent
subsequently.  If an endpoint receives a second SETTINGS frame on the
control stream, the endpoint MUST respond with a connection error of
type H3_FRAME_UNEXPECTED.
Paragraph (version B):
SETTINGS frames MUST NOT be sent on any stream other than the control
stream.  If an endpoint receives a SETTINGS frame on a different
stream, the endpoint MUST respond with a connection error of type
H3_FRAME_UNEXPECTED.
Paragraph (version A):
The same setting identifier MUST NOT occur more than once in the
SETTINGS frame.  A receiver MAY treat the presence of duplicate
setting identifiers as a connection error of type
HTTP_SETTINGS_ERROR.
Paragraph (version B):
The same setting identifier MUST NOT occur more than once in the
SETTINGS frame.  A receiver MAY treat the presence of duplicate
setting identifiers as a connection error of type H3_SETTINGS_ERROR.
Paragraph (version A):
A server MAY accept 0-RTT and subsequently provide different settings
in its SETTINGS frame.  If 0-RTT data is accepted by the server, its
SETTINGS frame MUST NOT reduce any limits or alter any values that
might be violated by the client with its 0-RTT data.  The server MUST
include all settings which differ from their default values.  If a
server accepts 0-RTT, but then sends a SETTINGS frame which reduces a
setting the client understands or omits a value that was previously
specified to have a non-default value, this MUST be treated as a
connection error of type HTTP_SETTINGS_ERROR.
Paragraph (version B):
A server MAY accept 0-RTT and subsequently provide different settings
in its SETTINGS frame.  If 0-RTT data is accepted by the server, its
SETTINGS frame MUST NOT reduce any limits or alter any values that
might be violated by the client with its 0-RTT data.  The server MUST
include all settings which differ from their default values.  If a
server accepts 0-RTT, but then sends a SETTINGS frame which reduces a
setting the client understands or omits a value that was previously
specified to have a non-default value, this MUST be treated as a
connection error of type H3_SETTINGS_ERROR.
Paragraph (version A):
A server MUST NOT use a Push ID that is larger than the client has
provided in a MAX_PUSH_ID frame (frame-max-push-id).  A client MUST
treat receipt of a PUSH_PROMISE frame that contains a larger Push ID
than the client has advertised as a connection error of
HTTP_ID_ERROR.
Paragraph (version A):
A server MUST NOT use the same Push ID in multiple PUSH_PROMISE
frames.  A client MUST treat receipt of a Push ID which has already
been promised as a connection error of type HTTP_ID_ERROR.
Paragraph (version A):
If a PUSH_PROMISE frame is received on the control stream, the client
MUST respond with a connection error (errors) of type
HTTP_FRAME_UNEXPECTED.
Paragraph (version A):
A client MUST NOT send a PUSH_PROMISE frame.  A server MUST treat the
receipt of a PUSH_PROMISE frame as a connection error of type
HTTP_FRAME_UNEXPECTED.
Paragraph (version B):
A server MUST NOT use a Push ID that is larger than the client has
provided in a MAX_PUSH_ID frame (frame-max-push-id).  A client MUST
treat receipt of a PUSH_PROMISE frame that contains a larger Push ID
than the client has advertised as a connection error of H3_ID_ERROR.
Paragraph (version B):
A server MUST NOT use the same Push ID in multiple PUSH_PROMISE
frames.  A client MUST treat receipt of a Push ID which has already
been promised as a connection error of type H3_ID_ERROR.
Paragraph (version B):
If a PUSH_PROMISE frame is received on the control stream, the client
MUST respond with a connection error (errors) of type
H3_FRAME_UNEXPECTED.
Paragraph (version B):
A client MUST NOT send a PUSH_PROMISE frame.  A server MUST treat the
receipt of a PUSH_PROMISE frame as a connection error of type
H3_FRAME_UNEXPECTED.
Paragraph (version A):
The GOAWAY frame is always sent on the control stream.  It carries a
QUIC Stream ID for a client-initiated bidirectional stream encoded as
a variable-length integer.  A client MUST treat receipt of a GOAWAY
frame containing a Stream ID of any other type as a connection error
of type HTTP_ID_ERROR.
Paragraph (version A):
Clients do not need to send GOAWAY to initiate a graceful shutdown;
they simply stop making new requests.  A server MUST treat receipt of
a GOAWAY frame on any stream as a connection error (errors) of type
HTTP_FRAME_UNEXPECTED.
Paragraph (version A):
The GOAWAY frame applies to the connection, not a specific stream.  A
client MUST treat a GOAWAY frame on a stream other than the control
stream as a connection error (errors) of type HTTP_FRAME_UNEXPECTED.
Paragraph (version B):
The GOAWAY frame is always sent on the control stream.  It carries a
QUIC Stream ID for a client-initiated bidirectional stream encoded as
a variable-length integer.  A client MUST treat receipt of a GOAWAY
frame containing a Stream ID of any other type as a connection error
of type H3_ID_ERROR.
Paragraph (version B):
Clients do not need to send GOAWAY to initiate a graceful shutdown;
they simply stop making new requests.  A server MUST treat receipt of
a GOAWAY frame on any stream as a connection error (errors) of type
H3_FRAME_UNEXPECTED.
Paragraph (version B):
The GOAWAY frame applies to the connection, not a specific stream.  A
client MUST treat a GOAWAY frame on a stream other than the control
stream as a connection error (errors) of type H3_FRAME_UNEXPECTED.
Paragraph (version A):
The MAX_PUSH_ID frame is always sent on the control stream.  Receipt
of a MAX_PUSH_ID frame on any other stream MUST be treated as a
connection error of type HTTP_FRAME_UNEXPECTED.
Paragraph (version A):
A server MUST NOT send a MAX_PUSH_ID frame.  A client MUST treat the
receipt of a MAX_PUSH_ID frame as a connection error of type
HTTP_FRAME_UNEXPECTED.
Paragraph (version B):
The MAX_PUSH_ID frame is always sent on the control stream.  Receipt
of a MAX_PUSH_ID frame on any other stream MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED.
Paragraph (version B):
A server MUST NOT send a MAX_PUSH_ID frame.  A client MUST treat the
receipt of a MAX_PUSH_ID frame as a connection error of type
H3_FRAME_UNEXPECTED.
Paragraph (version A):
The MAX_PUSH_ID frame carries a single variable-length integer that
identifies the maximum value for a Push ID that the server can use
(see frame-push-promise).  A MAX_PUSH_ID frame cannot reduce the
maximum Push ID; receipt of a MAX_PUSH_ID that contains a smaller
value than previously received MUST be treated as a connection error
of type HTTP_ID_ERROR.
Paragraph (version B):
The MAX_PUSH_ID frame carries a single variable-length integer that
identifies the maximum value for a Push ID that the server can use
(see frame-push-promise).  A MAX_PUSH_ID frame cannot reduce the
maximum Push ID; receipt of a MAX_PUSH_ID that contains a smaller
value than previously received MUST be treated as a connection error
of type H3_ID_ERROR.
Paragraph (version A):
The DUPLICATE_PUSH frame is always sent on a request stream.  Receipt
of a DUPLICATE_PUSH frame on any other stream MUST be treated as a
connection error of type HTTP_FRAME_UNEXPECTED.
Paragraph (version A):
A client MUST NOT send a DUPLICATE_PUSH frame.  A server MUST treat
the receipt of a DUPLICATE_PUSH frame as a connection error of type
HTTP_FRAME_UNEXPECTED.
Paragraph (version B):
The DUPLICATE_PUSH frame is always sent on a request stream.  Receipt
of a DUPLICATE_PUSH frame on any other stream MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED.
Paragraph (version B):
A client MUST NOT send a DUPLICATE_PUSH frame.  A server MUST treat
the receipt of a DUPLICATE_PUSH frame as a connection error of type
H3_FRAME_UNEXPECTED.
Paragraph (version A):
The DUPLICATE_PUSH frame carries a single variable-length integer
that identifies the Push ID of a resource that the server has
previously promised (see frame-push-promise), though that promise
might not be received before this frame.  A server MUST NOT use a
Push ID that is larger than the client has provided in a MAX_PUSH_ID
frame (frame-max-push-id).  A client MUST treat receipt of a
DUPLICATE_PUSH that contains a larger Push ID than the client has
advertised as a connection error of type HTTP_ID_ERROR.
Paragraph (version B):
The DUPLICATE_PUSH frame carries a single variable-length integer
that identifies the Push ID of a resource that the server has
previously promised (see frame-push-promise), though that promise
might not be received before this frame.  A server MUST NOT use a
Push ID that is larger than the client has provided in a MAX_PUSH_ID
frame (frame-max-push-id).  A client MUST treat receipt of a
DUPLICATE_PUSH that contains a larger Push ID than the client has
advertised as a connection error of type H3_ID_ERROR.
Paragraph (version A):
Frame types which were used in HTTP/2 where there is no corresponding
HTTP/3 frame have also been reserved (iana-frames).  These frame
types MUST NOT be sent, and receipt MAY be treated as an error of
type HTTP_FRAME_UNEXPECTED.
Paragraph (version B):
Frame types which were used in HTTP/2 where there is no corresponding
HTTP/3 frame have also been reserved (iana-frames).  These frame
types MUST NOT be sent, and receipt MAY be treated as an error of
type H3_FRAME_UNEXPECTED.