Re: [quicwg/base-drafts] Define terms for application actions (#2857)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> @@ -505,11 +505,11 @@ this limit are not guaranteed to be accepted.
 
 ### Request Cancellation and Rejection {#request-cancellation}
 
-Clients can cancel requests by aborting the stream (QUIC RESET_STREAM and/or
-STOP_SENDING frames, as appropriate) with an error code of
-HTTP_REQUEST_CANCELLED ({{http-error-codes}}).  When the client cancels a
-response, it indicates that this response is no longer of interest.
-Implementations SHOULD cancel requests by aborting both directions of a stream.
+Clients can cancel requests by resetting 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 terminating both directions of a

The terms "clean termination" and "abrupt termination" are given as synonyms for "end the stream" and "reset the stream" in -transport line 361.  I should specify the termination type here.

> -least one unidirectional stream for the HTTP control stream plus the number of
-unidirectional streams required by mandatory extensions (such as QPACK) by
-setting an appropriate value for the QUIC transport parameter
-`initial_max_uni_streams` (three being the minimum value required for the base
-HTTP/3 protocol and QPACK), and SHOULD use a value of 1,024 or greater for the
-QUIC transport parameter `initial_max_stream_data_uni`.
+Endpoints that excessively restrict the number or flow control window of these
+streams will increase the chance that the remote peer reaches the limit early
+and becomes blocked. In particular, implementations should consider that remote
+peers may wish to exercise reserved stream behavior ({{stream-grease}}) with
+some of the unidirectional streams they are permitted to use. To avoid blocking,
+both clients and servers MUST allow the peer to create at least one
+unidirectional stream for the HTTP control stream plus the number of
+unidirectional streams required by mandatory extensions (three being the minimum
+number required for the base HTTP/3 protocol and QPACK), and SHOULD provide at
+least 1,024 bytes of flow control credit to each stream.

Good point.  I personally think they're equivalent, but I believe our consensus was to require it to be in the transport parameters.  I added a phrase to clarify this.

> @@ -345,6 +345,31 @@ the relative priority of streams.  When deciding which streams to dedicate
 resources to, the implementation SHOULD use the information provided by the
 application.
 
+## Required Operations on Streams
+
+There are certain operations which an application MUST be able to perform when
+interacting with QUIC streams.  This document does not specify an API, but
+any implementation of this version of QUIC MUST expose the ability to perform
+the operations described in this section on a QUIC stream.
+
+On the sending part of a stream:
+
+- Attempt to write data, understanding when stream flow control credit
+  ({{data-flow-control}}) has successfully been reserved to send the written
+  data or possibly discovering that the stream has been closed because the peer

Already created this list, but didn't adjust this bullet point.  Fixed.

> @@ -1101,6 +1132,41 @@ suggested structure:
 -->
 
 
+## Required Operations on Connections
+
+There are certain operations which an application MUST be able to perform when
+interacting with the QUIC transport.  This document does not specify an API, but
+any implementation of this version of QUIC MUST expose the ability to perform
+the operations described in this section on a QUIC connection.
+
+When implementing the client role, applications need to be able to:
+
+- open a connection, which begins the exchange described in {{handshake}};
+- enable 0-RTT; and
+- be informed when 0-RTT has been accepted or rejected by a server.

The client needs to know because rejection resets the state of all streams; the client has to know whether to start over.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2857#discussion_r304095084