Draft: draft-ietf-quic-http

Commentary: Generalizes HTTPPUSHLIMITEXCEEDED to HTTPLIMIT_EXCEEDED and mandates use of that error code where a PRIORITY frame attempts to prioritize a stream the client is n't permitted to open yet . This has the effect of bounding priority tree state to requests the client could initiate ( though might not have yet ) . 
 RFC 7540 at some length , especially what to do with priority information after a stream is closed . In addition to this , in HTTP/3 , we have to deal with priority information before a stream is opened . That is : just how large is the tree allowed to grow before the referenced streams ' frames begin to come in ? The draft should provide some recommendations . I can think of two ways to do limit this " front - loaded " state : the stream when a PRIORITY frame referencing it arrives on the control stream . This will invoke the stream limit checks . number of priority entries to number -- perhaps a function of the total number of maximum unidirectional and bidirectional streams . 
 Just clarifying : this would be advice to implementations , nothing normative , right ? 
 I do n't know . I think I will be happy as long as something is put into the draft . 
 Assuming that PRIORITY can only reference a stream that already " exists " client - side , the maximum number would be the number of permitted client - initiated bidirectional streams . Perhaps the requirements should simply be that PRIORITY can not reference a stream that the client is n't permitted to open ? I do n't really want to " actually open " the stream when the PRIORITY frame arrives , but checking that it 's less than the MAXSTREAMID on receipt seems like a reasonable server - side check .
Paragraph (version A):
When a PRIORITY frame claims to reference a request, the associated
ID MUST identify a client-initiated bidirectional stream.  A server
MUST treat receipt of PRIORITY frame with a Stream ID of any other
type as a connection error of type HTTP_MALFORMED_FRAME.
Paragraph (version A):
A PRIORITY frame that references a non-existent Push ID or a
Placeholder ID greater than the server's limit MUST be treated as an
HTTP_MALFORMED_FRAME error.
Paragraph (version B):
When a PRIORITY frame claims to reference a request, the associated
ID MUST identify a client-initiated bidirectional stream.  A server
MUST treat receipt of a PRIORITY frame identifying a stream of any
other type as a connection error of type HTTP_MALFORMED_FRAME.
Paragraph (version B):
A PRIORITY frame that references a non-existent Push ID, a
Placeholder ID greater than the server's limit, or a Stream ID the
client is not yet permitted to open MUST be treated as an
HTTP_LIMIT_EXCEEDED error.
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_PUSH_LIMIT_EXCEEDED.
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 HTTP_LIMIT_EXCEEDED.
Paragraph (version A):
A Push ID greater than the current maximum Push ID was referenced.
Paragraph (version B):
A Stream ID, Push ID, or Placeholder ID greater than the current
maximum for that identifier was referenced.