Draft: draft-ietf-quic-http

Commentary: Open to discussion about whether all of these are ID_ERROR or not . 
 I 've tried to improve the readability of this section a bit ; I turned  's suggested parallel paragraphs around to talk about why client and server would send the frame ( and the corresponding responses ) instead of talking about behavior on receipt . Please take a fresh look , and 
 I think there are some edge cases with the CANCELPUSH frame that we do n't explain : reception of a CANCELPUSH frame with ID greater than the current push limit reception of CANCEL_PUSH with ID that has already been used 
 I 'd also add a CANCELPUSH from the client for a PUSHID that has not been promised . 
 CANCEL_PUSH with a reused ID is probably indistinguishable from receiving one for a stream that 's already open ; you SHOULD reset the stream ( which is a no - op if the stream is already full transferred ) .
Paragraph (version A):
When a server receives this frame, it aborts sending the response for
the identified server push.  If the server has not yet started to
send the server push, it can use the receipt of a CANCEL_PUSH frame
to avoid opening a push stream.  If the push stream has been opened
by the server, the server SHOULD abruptly terminate that stream.
Paragraph (version A):
A server can send the CANCEL_PUSH frame to indicate that it will not
be fulfilling a promise prior to creation of a push stream.  Once the
push stream has been created, sending CANCEL_PUSH has no effect on
the state of the push stream.  The server SHOULD abruptly terminate
the push stream instead.
Paragraph (version B):
When a client sends CANCEL_PUSH, it is indicating that it does not
wish to receive the promised resource.  The server SHOULD abort
sending the resource, but the mechanism to do so depends on the state
of the corresponding push stream.  If the server has not yet created
a push stream, it does not create one.  If the push stream is open,
the server SHOULD abruptly terminate that stream.  If the push stream
has already ended, the server MAY still abruptly terminate the stream
or MAY take no action.
Paragraph (version B):
When a server sends CANCEL_PUSH, it is indicating that it will not be
fulfilling a promise and has not created a push stream.  The client
should not expect the corresponding promise to be fulfilled.
Paragraph (version B):
Sending CANCEL_PUSH has no direct effect on the state of existing
push streams.  A server SHOULD NOT send a CANCEL_PUSH when it has
already created a corresponding push stream, and a client SHOULD NOT
send a CANCEL_PUSH when it has already received a corresponding push
stream.
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).
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.
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
HTTP_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 HTTP_ID_ERROR.
Paragraph (version A):
The MAX_PUSH_ID frame (type=0xD) is used by clients to control the
number of server pushes that the server can initiate.  This sets the
maximum value for a Push ID that the server can use in a PUSH_PROMISE
frame.  Consequently, this also limits the number of push streams
that the server can initiate in addition to the limit maintained by
the QUIC transport.
Paragraph (version B):
The MAX_PUSH_ID frame (type=0xD) is used by clients to control the
number of server pushes that the server can initiate.  This sets the
maximum value for a Push ID that the server can use in PUSH_PROMISE
and CANCEL_PUSH frames.  Consequently, this also limits the number of
push streams that the server can initiate in addition to the limit
maintained by the QUIC transport.