Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

No normative language for connection/stream operations #3935

Merged
merged 3 commits into from Sep 1, 2020
Merged

No normative language for connection/stream operations #3935

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
8a1cc17
No normative language for connection/stream operations
martinthomson Jul 21, 2020
d20c030
This will require wrapping :(
martinthomson Jul 22, 2020
04986a2
wrap
martinthomson Jul 22, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
43 changes: 24 additions & 19 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -428,14 +428,16 @@ A QUIC implementation SHOULD provide ways in which an application can indicate
the relative priority of streams. An implementation uses information provided
by the application to determine how to allocate resources to active streams.

## Required Operations on Streams {#stream-operations}
## Operations on Streams {#stream-operations}

There are certain operations that 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.
This document does not define an API for QUIC, but instead defines a set of
functions on streams that application protocols can rely upon. An application
protocol can assume that an implementation of QUIC provides an interface that
martinthomson marked this conversation as resolved.
Show resolved Hide resolved
martinthomson marked this conversation as resolved.
Show resolved Hide resolved
includes the operations described in this section. An implementation designed
for use with a specific application protocol might provide only those operations
that are used by that protocol.

On the sending part of a stream, application protocols need to be able to:
On the sending part of a stream, an application protocol can:

- write data, understanding when stream flow control credit
({{data-flow-control}}) has successfully been reserved to send the written
Expand All @@ -445,16 +447,17 @@ On the sending part of a stream, application protocols need to be able to:
- reset the stream (abrupt termination), resulting in a RESET_STREAM frame
({{frame-reset-stream}}) if the stream was not already in a terminal state.

On the receiving part of a stream, application protocols need to be able to:
On the receiving part of a stream, an application protocol can:

- read data; and
- abort reading of the stream and request closure, possibly resulting in a
STOP_SENDING frame ({{frame-stop-sending}}).

Applications also need to be informed of state changes on streams, including
when the peer has opened or reset a stream, when a peer aborts reading on a
stream, when new data is available, and when data can or cannot be written to
the stream due to flow control.
An application protocol can also request to be informed of state changes on
streams, including when the peer has opened or reset a stream, when a peer
aborts reading on a stream, when new data is available, and when data can or
cannot be written to the stream due to flow control.


# Stream States {#stream-states}

Expand Down Expand Up @@ -1302,20 +1305,22 @@ Server deployments that use this simple form of load balancing MUST avoid the
creation of a stateless reset oracle; see {{reset-oracle}}.


## Required Operations on Connections
## Operations on Connections

There are certain operations that 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.
This document does not define an API for QUIC, but instead defines a set of
functions for QUIC connections that application protocols can rely upon. An
application protocol can assume that an implementation of QUIC provides an
martinthomson marked this conversation as resolved.
Show resolved Hide resolved
interface that includes the operations described in this section. An
implementation designed for use with a specific application protocol might
provide only those operations that are used by that protocol.

When implementing the client role, applications need to be able to:
When implementing the client role, an application protocol can:

- open a connection, which begins the exchange described in {{handshake}};
- enable Early Data when available; and
- be informed when Early Data has been accepted or rejected by a server.

When implementing the server role, applications need to be able to:
When implementing the server role, an application protocol can:

- listen for incoming connections, which prepares for the exchange described in
{{handshake}};
Expand All @@ -1325,7 +1330,7 @@ When implementing the server role, applications need to be able to:
client's resumption ticket and enable rejecting Early Data based on that
information.

In either role, applications need to be able to:
In either role, an application protocol can:

- configure minimum values for the initial number of permitted streams of each
type, as communicated in the transport parameters ({{transport-parameters}});
Expand Down