Draft: draft-ietf-quic-http

Commentary: I still do n't feel like this flows quite right , so suggestions appreciated . 
 better be clarify Implementation means Client / Server or both . are some of similar terms reset cancel reject abort ( abruptly ) terminate it seems better to make them more clarify what each of them describes and how they can be done . 
 " Implementations , " throughout the document , refers to both clients and servers . Do you have a suggested place to clarify this ? " reset " and " abrupt termination " are synonyms for the same operation in " cancel " and " reject " are separate actions an implementation can take , described in It looks like " abort " is used with relatively little context -- I 'll try to clean that up a bit . It 's intended to refer to " abort reading , " another operation in . 
 thought this section says about client , but suddenly appears . Clients can cancel requests by ~ When the client aborts reading a response ~ Implementations SHOULD cancel requests by ~ so I think this is also a client ( that says about cancel response ) . but you mean this says both client / server ? server can cancel request too ? SGTM I 'll try to clean that up a bit 
 Yes , servers can cancel a request ; that is , indicate that for some reason they will not be processing it any further . But perhaps it would be clearer to separately state that in a paragraph about server behavior . 
 Thank you for improving the specs !
Paragraph (version A):
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 A):
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
that 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 A):
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):
If a stream is cancelled after receiving a complete response, the
client MAY ignore the cancellation and use the response.  However, if
a stream is cancelled after receiving a partial response, the
response SHOULD NOT be used.  Automatically retrying such requests is
not possible, unless this is otherwise permitted (e.g., idempotent
actions like GET, PUT, or DELETE).
Paragraph (version B):
Once a request stream has been opened, the request MAY be cancelled
by either endpoint.  Clients cancel requests if the response is no
longer of interest; servers cancel requests if they are unable to or
choose not to respond.  When possible, it is RECOMMENDED that servers
send an HTTP response with an appropriate status code rather than
canceling a request it has already begun processing.
Paragraph (version B):
Implementations SHOULD cancel requests by abruptly terminating any
directions of a stream that are still open.  This means resetting the
sending parts of streams and aborting reading on receiving parts of
streams; see Section 2.4 of QUIC-TRANSPORT.
Paragraph (version B):
When the server cancels a request without performing any application
processing, the request is considered "rejected."  The server 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.
Paragraph (version B):
Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests
that 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):
Client SHOULD use the error code H3_REQUEST_CANCELLED to cancel
requests.  Upon receipt of this error code, 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 B):
If a stream is canceled after receiving a complete response, the
client MAY ignore the cancellation and use the response.  However, if
a stream is cancelled after receiving a partial response, the
response SHOULD NOT be used.  Automatically retrying such requests is
not possible, unless this is otherwise permitted (e.g., idempotent
actions like GET, PUT, or DELETE).
Paragraph (version A):
Even when a connection is not idle, either endpoint can decide to
stop using the connection and initiate a graceful connection close.
Endpoints initiate the graceful shutdown of a connection by sending a
GOAWAY frame (frame-goaway).  The GOAWAY frame contains an identifier
that indicates to the receiver the range of requests or pushes that
were or might be processed in this connection.  The server sends a
client-initiated bidirectional Stream ID; the client sends a Push ID.
Requests or pushes with the indicated identifier or greater are
rejected by the sender of the GOAWAY.  This identifier MAY be zero if
no requests or pushes were processed.
Paragraph (version B):
Even when a connection is not idle, either endpoint can decide to
stop using the connection and initiate a graceful connection close.
Endpoints initiate the graceful shutdown of a connection by sending a
GOAWAY frame (frame-goaway).  The GOAWAY frame contains an identifier
that indicates to the receiver the range of requests or pushes that
were or might be processed in this connection.  The server sends a
client-initiated bidirectional Stream ID; the client sends a Push ID.
Requests or pushes with the indicated identifier or greater are
rejected (request-cancellation) by the sender of the GOAWAY.  This
identifier MAY be zero if no requests or pushes were processed.