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

Tiny minset appendix update #1439

Merged
merged 1 commit into from Nov 1, 2023
Merged

Tiny minset appendix update #1439

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
11 changes: 6 additions & 5 deletions draft-ietf-taps-interface.md
View file
Open in desktop
Expand Up @@ -3139,7 +3139,7 @@ an event will be delivered to complete any pending `Receive` requests (see {{rec
If Messages arrive at the Transport Services system before `Receive` requests are issued,
ensuing `Receive` requests will first operate on these Messages before awaiting any further Messages.

### Enqueuing Receives
### Enqueuing Receives {#receiving-action}

`Receive` takes two parameters to specify the length of data that an application
is willing to receive, both of which are optional and have default values if not
Expand Down Expand Up @@ -3691,7 +3691,8 @@ coverage, see {{prop-checksum-control-send}} and {{prop-checksum-control-receive
# Relationship to the Minimal Set of Transport Services for End Systems

{{?RFC8923}} identifies a minimal set of transport services that end systems should offer. These services make all non-security-related transport features of TCP, MPTCP, UDP, UDP-Lite, SCTP and LEDBAT available that 1) require interaction with the application, and 2) do not get in the way of a possible implementation over TCP (or, with limitations, UDP). The following text explains how this minimal set is reflected in the present API. For brevity, it is based on the list in Section 4.1 of {{?RFC8923}}, updated according to the discussion in Section 5 of {{?RFC8923}}. The present API covers all elements of this section.
This list is a subset of the transport features in Appendix A of {{?RFC8923}}, which refers to the primitives in "pass 2" (Section 4) of {{?RFC8303}} for further details on the implementation with TCP, MPTCP, UDP, UDP-Lite, SCTP and LEDBAT.
This list is a subset of the transport features in Appendix A of {{?RFC8923}}, which refers to the primitives in "pass 2" (Section 4) of {{?RFC8303}} for further details on the implementation with TCP, MPTCP, UDP, UDP-Lite, SCTP and LEDBAT. This facilitates finding the specifications for implementing
the services listed below with these protocols.

* Connect:
`Initiate` action ({{initiate}}).
Expand Down Expand Up @@ -3766,13 +3767,13 @@ these two transport features are controlled via the Message Property `msgOrdered
should the protocol support it, this is one of the transport features the Transport Services system can apply when an application uses the `connCapacityProfile` Property ({{prop-cap-profile}}) or the `msgCapacityProfile` Message Property ({{send-profile}}) with value `Low Latency/Interactive`.

* Receive data (with no message delimiting):
`Receive` action ({{receiving}}) and `Received` event ({{receive-complete}}).
`Receive` action ({{receiving-action}}) and `Received` event ({{receive-complete}}).

* Receive a message:
`Receive` action ({{receiving}}) and `Received` event ({{receive-complete}}), using Message Framers ({{framing}}).
`Receive` action ({{receiving-action}}) and `Received` event ({{receive-complete}}), using Message Framers ({{framing}}).

* Information about partial message arrival:
`Receive` action ({{receiving}}) and `ReceivedPartial` event ({{receive-partial}}).
`Receive` action ({{receiving-action}}) and `ReceivedPartial` event ({{receive-partial}}).

* Notification of send failures:
`Expired` event ({{expired}}) and `SendError` event ({{send-error}}).
Expand Down