Question:
Starting to address This is an early review, to check if we like the structure. I'd also like help filling out the SCTP section!
I can also help with SCTP, which I would do in the same style that I suggest above (for TCP, in my example of "Abort") - also later.
We've updated Implementation mapping details for most protocols with , but we didn't tackle SCTP yet.
I'm fine with this being assigned to me. However, it's more than just writing the SCTP text. Here's the relevant part of what I wrote in PR : I don't suggest to delete much of the text that's there but definitely amend it with the RFC reference at least for what's covered in RFC 8303. There's a very direct line from this type of text in RFC 8303 to the original specs, so I do believe that should be helpful. That's (obviously) post-Montreal though!
NAME please send a PR along these lines.
LGTM modulo mwelzl changes.I think this is a good step forward. This said, I think we should describe things focusing on the transport's API call to be made (in line with the spec - that's why we have RFCs 8303 and 8304) rather than protocol internals. E.g., rather than saying that Abort on a TCP connection transmits a RST, I think we should simply say that Abort calls ABORT.TCP [RFC 8303, Section 4.1]. I can take care of these things, later. I'd still like to focus more on the API doc at this time.

9. <ins> Each protocol that can run as part of a Transport Services implementation defines both its API mapping as well as implementation details. API mappings for a protocol apply most to Connections in which the given protocol is the "top" of the Protocol Stack.  For example, the mapping of the "Send" function for TCP applies to Connections in which the application directly sends over TCP.  If HTTP/2 is used on top of TCP, the HTTP/2 mappings take precendence. Each protocol has a notion of Connectedness.  Possible values for Connectedness are: Unconnected.  Unconnected protocols do not establish explicit state between endpoints, and do not perform a handshake during Connection establishment. Connected.  Connected protocols establish state between endpoints, and perform a handshake during Connection establishment.  The handshake may be 0-RTT to send data or resume a session, but bidirectional traffic is required to confirm connectedness. Multiplexing Connected.  Multiplexing Connected protocols share properties with Connected protocols, but also explictly support opening multiple application-level flows.  This means that they can support cloning new Connection objects without a new explicit handshake. Protocols also define a notion of Data Unit.  Possible values for Data Unit are: Byte-stream.  Byte-stream protocols do not define any Message boundaries of their own apart from the end of a stream in each direction. Datagram.  Datagram protocols define Message boundaries at the same level of transmission, such that only complete (not partial) Messages are supported. Message.  Message protocols support Message boundaries that can be sent and received either as complete or partial Messages.  Maximum Message lengths can be defined, and Messages can be partially reliable. </ins> 9.1. <del> Connection lifetime for TCP translates fairly simply into the the abstraction presented to an application.  When the TCP three-way handshake is complete, its layer of the Protocol Stack can be considered Ready (established).  This event will cause racing of Protocol Stack options to complete if TCP is the top-level protocol, at which point the application can be notified that the Connection is Ready to send and receive. If the application sends a Close, that can translate to a graceful termination of the TCP connection, which is performed by sending a FIN to the remote endpoint.  If the application sends an Abort, then the TCP state can be closed abruptly, leading to a RST being sent to the peer. Without a layer of framing (a top-level protocol in the established Protocol Stack that preserves message boundaries, or an application- supplied deframer) on top of TCP, the receiver side of the transport system implementation can only treat the incoming stream of bytes as a single Message, terminated by a FIN when the Remote Endpoint closes the Connection. </del> <ins> Connectedness: Connected Data Unit: Byte-stream API mappings for TCP are as follows: TCP connections between two hosts map directly to Connection objects. Calling "Initiate" on a TCP Connection causes it to reserve a local port, and send a SYN to the Remote Endpoint. Early idempotent data is sent on a TCP Connection in the SYN, as TCP Fast Open data. A TCP Connection is ready once the three-way handshake is complete. TCP can throw various errors during connection setup. Specifically, it is important to handle a RST being sent by the peer during the handshake. Once established, TCP throws errors whenever the connection is disconnected, such as due to receive a RST from the peer; or hitting a TCP retransmission timeout. Calling "Listen" for TCP binds a local port and prepares it to receive inbound SYN packets from peers. TCP Listeners will deliver new connections once they have replied to an inbound SYN with a SYN-ACK. Calling "Clone" on a TCP Connection creates a new Connection with equivalent parameters.  The two Connections are otherwise independent. TCP does not on its own preserve Message boundaries.  Calling "Send" on a TCP connection lays out the bytes on the TCP send stream without any other delineation.  Any Message marked as Final will cause TCP to send a FIN once the Message has been completely written. TCP delivers a stream of bytes without any Message delineation. All data delivered in the "Received" or "ReceivedPartial" event will be part of a single stream-wide Message that is marked Final (unless a MessageFramer is used).  EndOfMessage will be delivered when the TCP Connection has received a FIN from the peer. Calling "Close" on a TCP Connection indicates that the Connection should be gracefully closed by sending a FIN to the peer and waiting for a FIN-ACK before delivering the "Closed" event. Calling "Abort" on a TCP Connection indicates that the Connection should be immediately closed by sending a RST to the peer. </ins> 9.2. <del> UDP as a direct transport does not provide any handshake or connectivity state, so the notion of the transport protocol becoming Ready or established is degenerate.  Once the system has validated that there is a route on which to send and receive UDP datagrams, the protocol is considered Ready.  Similarly, a Close or Abort has no meaning to the on-the-wire protocol, but simply leads to the local state being torn down. </del> <ins> Connectedness: Unconnected </ins> <del> When sending and receiving messages over UDP, each Message should correspond to a single UDP datagram.  The Message can contain metadata about the packet, such as the ECN bits applied to the packet. </del> <ins> Data Unit: Datagram </ins> <del> 9.3. </del> <ins> API mappings for UDP are as follows: </ins> <del> To support sender-side stream schedulers (which are implemented on the sender side), a receiver-side Transport System should always support message interleaving RFC8260. </del> <ins> UDP connections represent a pair of specific IP addresses and ports on two hosts. </ins> <del> SCTP messages can be very large.  To allow the reception of large messages in pieces, a "partial flag" can be used to inform a (native SCTP) receiving application that a message is incomplete.  After receiving the "partial flag", this application would know that the next receive calls will only deliver remaining parts of the same message (i.e., no messages or partial messages will arrive on other streams until the message is complete) (see Section 8.1.20 in RFC6458).  The "partial flag" can therefore facilitate the implementation of the receiver buffer in the receiving application, at the cost of limiting multiplexing and temporarily creating head- of-line blocking delay at the receiver. </del> <ins> Calling "Initiate" on a UDP Connection causes it to reserve a local port, but does not generate any traffic. </ins> <del> When a Transport System transfers a Message, it seems natural to map the Message object to SCTP messages in order to support properties such as "Ordered" or "Lifetime" (which maps onto partially reliable delivery with a SCTP_PR_SCTP_TTL policy RFC6458).  However, since multiplexing of Connections onto SCTP streams may happen, and would be hidden from the application, the Transport System requires a per- stream receiver buffer anyway, so this potential benefit is lost and the "partial flag" becomes unnecessary for the system. </del> <ins> Early data on a UDP Connection does not have any special meaning. The data is sent whenever the Connection is Ready. </ins> <del> The problem of long messages either requiring large receiver-side buffers or getting in the way of multiplexing is addressed by message interleaving RFC8260, which is yet another reason why a receivers- side transport system supporting SCTP should implement this mechanism. </del> <ins> A UDP Connection is ready once the system has reserved a local port and has a path to send to the Remote Endpoint. </ins> <del> 9.4. </del> <ins> UDP Connections can only generate errors on initiation due to port conflicts on the local system. Once in use, UDP throws errors upon receiving ICMP notifications indicating failures in the network. Calling "Listen" for UDP binds a local port and prepares it to receive inbound UDP datagrams from peers. UDP Listeners will deliver new connections once they have received traffic from a new Remote Endpoint. Calling "Clone" on a UDP Connection creates a new Connection with equivalent parameters.  The two Connections are otherwise independent. Calling "Send" on a UDP connection sends the data as the payload of a complete UDP datagram.  Marking Messages as Final does not change anything in the datagram's contents. UDP only delivers complete Messages to "Received", each of which represents a single datagram received in a UDP packet. Calling "Close" on a UDP Connection releases the local port reservation. Calling "Abort" on a UDP Connection is identical to calling "Close". 9.3. </ins> The mapping of a TLS stream abstraction into the application is <del> equivalent to the contract provided by TCP (see tcp).  The Ready state should be determined by the completion of the TLS handshake, which involves potentially several more round trips beyond the TCP handshake.  The application should not be notified that the Connection is Ready until TLS is established. </del> <ins> equivalent to the contract provided by TCP (see tcp), and builds upon many of the actions of TCP connections. Connectedness: Connected Data Unit: Byte-stream Connection objects represent a single TLS connection running over a TCP connection between two hosts. Calling "Initiate" on a TLS Connection causes it to first initiate a TCP connection.  Once the TCP protocol is Ready, the TLS handshake will be performed as a client (starting by sending a "client_hello", and so on). Early idempotent data is supported by TLS 1.3, and sends encrypted application data in the first TLS message when performing session resumption.  For older versions of TLS, or if a session is not being resumed, the initial data will be delayed until the TLS handshake is complete.  TCP Fast Option can also be enabled automatically. A TLS Connection is ready once the underlying TCP connection is Ready, and TLS handshake is also complete and keys have been established to encrypt application data. In addition to TCP initiation errors, TLS can generate errors during its handshake.  Examples of error include a failure of the peer to successfully authenticate, the peer rejecting the local authentication, or a failure to match versions or algorithms. TLS connections will generate TCP errors, or errors due to failures to rekey or decrypt received messages. Calling "Listen" for TLS listens on TCP, and sets up received connections to perform server-side TLS handshakes. TLS Listeners will deliver new connections once they have successfully completed both TCP and TLS handshakes. As with TCP, calling "Clone" on a TLS Connection creates a new Connection with equivalent parameters.  The two Connections are otherwise independent. Like TCP, TLS does not preserve message boundaries.  Although application data is framed natively in TLS, there is not a general guarantee that these TLS messages represent semantically meaningful application stream boundaries.  Rather, sending data on a TLS Connection only guarantees that the application data will be transmitted in an encrypted form.  Marking Messages as Final causes a "close_notify" to be generated once the data has been written. Like TCP, TLS delivers a stream of bytes without any Message delineation.  The data is decrypted prior to being delivered to the application.  If a "close_notify" is received, the stream-wide Message will be delivered with EndOfMessage set. Calling "Close" on a TLS Connection indicates that the Connection should be gracefully closed by sending a "close_notify" to the peer and waiting for a corresponding "close_notify" before delivering the "Closed" event. Calling "Abort" on a TCP Connection indicates that the Connection should be immediately closed by sending a "close_notify", optionally preceded by "user_canceled", to the peer. Implementations do not need to wait to receive "close_notify" before delivering the "Closed" event. 9.4. DTLS follows the same behavior as TLS (tls), with the notable exception of not inheriting behavior directly from TCP.  Differences from TLS are detailed below, and all cases not explicitly mentioned should be considered the same as TLS. Connectedness: Connected Data Unit: Datagram Connection objects represent a single DTLS connection running over a set of UDP ports between two hosts. Calling "Initiate" on a DTLS Connection causes it reserve a UDP local port, and begin sending handshake messages to the peer over UDP.  These messages are reliable, and will be automatically retransmitted. A DTLS Connection is ready once the TLS handshake is complete and keys have been established to encrypt application data. Sending over DTLS does preserve message boundaries in the same way that UDP datagrams do.  Marking a Message as Final does send a "close_notify" like TLS. Receiving over DTLS delivers one decrypted Message for each received DTLS datagram.  If a "close_notify" is received, a Message will be delivered that is marked as Final. </ins> 9.5.


Question:
Starting to address This is an early review, to check if we like the structure. I'd also like help filling out the SCTP section!
I can also help with SCTP, which I would do in the same style that I suggest above (for TCP, in my example of "Abort") - also later.
We've updated Implementation mapping details for most protocols with , but we didn't tackle SCTP yet.
I'm fine with this being assigned to me. However, it's more than just writing the SCTP text. Here's the relevant part of what I wrote in PR : I don't suggest to delete much of the text that's there but definitely amend it with the RFC reference at least for what's covered in RFC 8303. There's a very direct line from this type of text in RFC 8303 to the original specs, so I do believe that should be helpful. That's (obviously) post-Montreal though!
NAME please send a PR along these lines.
LGTM modulo mwelzl changes.I think this is a good step forward. This said, I think we should describe things focusing on the transport's API call to be made (in line with the spec - that's why we have RFCs 8303 and 8304) rather than protocol internals. E.g., rather than saying that Abort on a TCP connection transmits a RST, I think we should simply say that Abort calls ABORT.TCP [RFC 8303, Section 4.1]. I can take care of these things, later. I'd still like to focus more on the API doc at this time.

Message representing the body, and the Headers being provided in Message metadata. <ins> Connectedness: Multiplexing Connected Data Unit: Message Connection objects represent a flow of HTTP messages between a client and a server, which may be an HTTP/1.1 connection over TCP, or a single stream in an HTTP/2 connection. Calling "Initiate" on an HTTP connection intiates a TCP or TLS connection as a client. Calling "Clone" on an HTTP Connection opens a new stream on an existing HTTP/2 connection when possible.  If the underlying version does not support multiplexed streams, calling "Clone" simply creates a new parallel connection. When an application sends an HTTP Message, it is expected to provide HTTP header values as a MessageContext in a canonical form, along with any associated HTTP message body as the Message data.  The HTTP header values are encoded in the specific version format upon sending. HTTP Connections deliver Messages in which HTTP header values attached to MessageContexts, and HTTP bodies in Message data. Calling "Close" on an HTTP Connection will only close the underlying TLS or TCP connection if the HTTP version does not support multiplexing.  For HTTP/2, for example, closing the connection only closes a specific stream. </ins> 9.6. QUIC provides a multi-streaming interface to an encrypted transport.


Question:
Starting to address This is an early review, to check if we like the structure. I'd also like help filling out the SCTP section!
I can also help with SCTP, which I would do in the same style that I suggest above (for TCP, in my example of "Abort") - also later.
We've updated Implementation mapping details for most protocols with , but we didn't tackle SCTP yet.
I'm fine with this being assigned to me. However, it's more than just writing the SCTP text. Here's the relevant part of what I wrote in PR : I don't suggest to delete much of the text that's there but definitely amend it with the RFC reference at least for what's covered in RFC 8303. There's a very direct line from this type of text in RFC 8303 to the original specs, so I do believe that should be helpful. That's (obviously) post-Montreal though!
NAME please send a PR along these lines.
LGTM modulo mwelzl changes.I think this is a good step forward. This said, I think we should describe things focusing on the transport's API call to be made (in line with the spec - that's why we have RFCs 8303 and 8304) rather than protocol internals. E.g., rather than saying that Abort on a TCP connection transmits a RST, I think we should simply say that Abort calls ABORT.TCP [RFC 8303, Section 4.1]. I can take care of these things, later. I'd still like to focus more on the API doc at this time.

Closing a single QUIC stream, presented to the application as a Connection, does not imply closing the underlying QUIC connection itself.  Rather, the implementation may choose to close the QUIC <del> connection once all streams have been closed (possibly after some </del> <ins> connection once all streams have been closed (often after some </ins> timeout), or after an individual stream Connection sends an Abort. <del> Messages over a direct QUIC stream should be represented similarly to the TCP stream (one Message per direction, see tcp), unless a framing mapping is used on top of QUIC. </del> <ins> Connectedness: Multiplexing Connected Data Unit: Stream Connection objects represent a single QUIC stream on a QUIC connection. </ins> 9.7.


Question:
Starting to address This is an early review, to check if we like the structure. I'd also like help filling out the SCTP section!
I can also help with SCTP, which I would do in the same style that I suggest above (for TCP, in my example of "Abort") - also later.
We've updated Implementation mapping details for most protocols with , but we didn't tackle SCTP yet.
I'm fine with this being assigned to me. However, it's more than just writing the SCTP text. Here's the relevant part of what I wrote in PR : I don't suggest to delete much of the text that's there but definitely amend it with the RFC reference at least for what's covered in RFC 8303. There's a very direct line from this type of text in RFC 8303 to the original specs, so I do believe that should be helpful. That's (obviously) post-Montreal though!
NAME please send a PR along these lines.
LGTM modulo mwelzl changes.I think this is a good step forward. This said, I think we should describe things focusing on the transport's API call to be made (in line with the spec - that's why we have RFCs 8303 and 8304) rather than protocol internals. E.g., rather than saying that Abort on a TCP connection transmits a RST, I think we should simply say that Abort calls ABORT.TCP [RFC 8303, Section 4.1]. I can take care of these things, later. I'd still like to focus more on the API doc at this time.

over the streams can be represented similarly to the TCP stream (one Message per direction, see tcp). <ins> Connectedness: Multiplexing Connected Data Unit: Stream Connection objects represent a single HTTP/2 stream on a HTTP/2 connection. 9.8. To support sender-side stream schedulers (which are implemented on the sender side), a receiver-side Transport System should always support message interleaving RFC8260. SCTP messages can be very large.  To allow the reception of large messages in pieces, a "partial flag" can be used to inform a (native SCTP) receiving application that a message is incomplete.  After receiving the "partial flag", this application would know that the next receive calls will only deliver remaining parts of the same message (i.e., no messages or partial messages will arrive on other streams until the message is complete) (see Section 8.1.20 in RFC6458).  The "partial flag" can therefore facilitate the implementation of the receiver buffer in the receiving application, at the cost of limiting multiplexing and temporarily creating head- of-line blocking delay at the receiver. When a Transport System transfers a Message, it seems natural to map the Message object to SCTP messages in order to support properties such as "Ordered" or "Lifetime" (which maps onto partially reliable delivery with a SCTP_PR_SCTP_TTL policy RFC6458).  However, since multiplexing of Connections onto SCTP streams may happen, and would be hidden from the application, the Transport System requires a per- stream receiver buffer anyway, so this potential benefit is lost and the "partial flag" becomes unnecessary for the system. The problem of long messages either requiring large receiver-side buffers or getting in the way of multiplexing is addressed by message interleaving RFC8260, which is yet another reason why a receivers- side transport system supporting SCTP should implement this mechanism. </ins> 10. RFC-EDITOR: Please remove this section before publication.


Question:
Maybe add the ASN source address (set source address), source filter (add remote addresses)? Maybe also add that for sending, you specify the group as remote and the socket becomes write-only? Should we require specifying direction? This would be slightly harder to use, but future proof in case someone implements reliable ASN on TAPS…
We need unidirectional connections. You know, for multicast. And ICN. And unidirectional streaming protocols.
This is a dup of , which has more discussion
I am re-opening this ticket as only dealt with unidirectional streams in unicast context (added with PR ): Current status: The current model for unidirectional streams supports half-closed connections and QUIC style unidirectional streams so far. We don't know yet whether it is sufficient to have canread/canwrite property on the connection level to model unidirectional connections We don't have pre-connection methods to create multicast sessions yet
there's a selection property for this, tagged discuss, which we haven't discussed yet. I'm moving this down to the appendix as part of my restructuring in my work on
If help is still wanted here, I'm maybe up for an attempt or 2 at adding multicast support. Has there been some prior discussion I can review about rough ideas on pre-connection methods for multicast sessions, or should I just try making something up?
lgtm

to force early binding when required, for example with some Network Address Translator (NAT) traversal protocols (see rendezvous). <ins> Specifying a multicast group address on the Local Endpoint will indicate to the transport system that the resulting connection will be used to receive multicast messages.  The Remote Endpoint can be used to filter by specific senders.  This will restrict the application to establishing the Preconnection by calling Listen(). The accepted Connections are receive-only. Similarly, specifying a multicast group address on the Remote Endpoint will indicate that the resulting connection will be used to send multicast messages. </ins> 5.2. A Preconnection Object holds properties reflecting the application's


Question:
I'm not quite sure what I meant by "Only full coverage is guaranteed, any other requests are advisory". I assume we mean that even if a partial checksum is requested you get full coverage because requesting partial coverage and getting no checksum doesn't seem right...?
Exactly, and you made it clearer. Thanks!

Integer (non-negative with -1 as special value) <del> full coverage </del> <ins> -1 (full coverage) </ins> This property specifies the minimum length of the section of the Message, starting from byte 0, that the application requires to be


Question:
I'm not quite sure what I meant by "Only full coverage is guaranteed, any other requests are advisory". I assume we mean that even if a partial checksum is requested you get full coverage because requesting partial coverage and getting no checksum doesn't seem right...?
Exactly, and you made it clearer. Thanks!

to specify options for simple integrity protection via checksums.  A value of 0 means that no checksum is required, and -1 means that the entire Message is protected by a checksum.  Only full coverage is <del> guaranteed, any other requests are advisory. </del> <ins> guaranteed, any other requests are advisory, meaning that full coverage is applied anyway. </ins> 7.4.7.


Question:
In the "Specifying Endpoints" section, added a reference to the Selection Property that does a similar thing but with more fine-grained control. It wasn't clear to me what is the best place to add this, so I put it right below the first example of specifying an interface name for the Local Endpoint to say that you can also do it differently. If you have better suggestions, please let me know. To the ListenError and RendezvousError, I added text mentioning the "reconcile Endpoints and Properties" pitfall. I think this is probably more general, i.e., there might be more sources of errors than just local interface, so I kept it generic.
For Local Address Preference we only have the option to prefer stable or temporary. However, I guess we would also need a way to e.g. specify that stable is required, no?
Is this addressed by PR ?
I don't think so.
When reading the current API draft, I was wondering the following: If an application wants to specify one or multiple local network interfaces, it can either set the Local Endpoint(s) or it can set the "Interface Instance or Type" Selection Property. I think both ways are valid and should exist, but I'm wondering if we should specify anything on the interaction of these two ways to do a similar thing. For example, should we explicitly mention the Selection Property in Section 5.1 ("Specifying Endpoints"), to make readers aware that there is a "better" way to do this, which allows more flexibility? Also, if an application specifies conflicting things, I guess this leads to an InitiateError, ListenError, or RendezvousError. Our current text already says this for the InitiateError: But should we make this particular issue more explicit here and/or should we add it for the ListenError or RendezvousError?
I think so, yes! Regarding the error in case of a conflict: I think so, yes - to all your questions: make it more explicit, state it in the description of both the ListenError and RendezvousError. Just my 2 cents
Thank you - works for me!

Specify a Local Endpoint using a local interface name and local port: <ins> As an alternative to specifying an interface name for the Local Endpoint, an application can express more fine-grained preferences using the "Interface Instance or Type" Selection Property, see prop- interface.  However, if the application specifies Selection Properties which are inconsistent with the Local Endpoint, this will result in an error once the application attempts to open a Connection. </ins> Specify a Local Endpoint using a STUN server: Specify a Local Endpoint using a Any-Source Multicast group to join


Question:
In the "Specifying Endpoints" section, added a reference to the Selection Property that does a similar thing but with more fine-grained control. It wasn't clear to me what is the best place to add this, so I put it right below the first example of specifying an interface name for the Local Endpoint to say that you can also do it differently. If you have better suggestions, please let me know. To the ListenError and RendezvousError, I added text mentioning the "reconcile Endpoints and Properties" pitfall. I think this is probably more general, i.e., there might be more sources of errors than just local interface, so I kept it generic.
For Local Address Preference we only have the option to prefer stable or temporary. However, I guess we would also need a way to e.g. specify that stable is required, no?
Is this addressed by PR ?
I don't think so.
When reading the current API draft, I was wondering the following: If an application wants to specify one or multiple local network interfaces, it can either set the Local Endpoint(s) or it can set the "Interface Instance or Type" Selection Property. I think both ways are valid and should exist, but I'm wondering if we should specify anything on the interaction of these two ways to do a similar thing. For example, should we explicitly mention the Selection Property in Section 5.1 ("Specifying Endpoints"), to make readers aware that there is a "better" way to do this, which allows more flexibility? Also, if an application specifies conflicting things, I guess this leads to an InitiateError, ListenError, or RendezvousError. Our current text already says this for the InitiateError: But should we make this particular issue more explicit here and/or should we add it for the ListenError or RendezvousError?
I think so, yes! Regarding the error in case of a conflict: I think so, yes - to all your questions: make it more explicit, state it in the description of both the ListenError and RendezvousError. Just my 2 cents
Thank you - works for me!

higher value.  By default, this value is Infinite.  The caller is also able to reset the value to Infinite at any point. <del> A ListenError occurs either when the Properties of the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </del> <ins> A ListenError occurs either when the Properties and Security Parameters of the Preconnection cannot be fulfilled for listening or cannot be reconciled with the Local Endpoint (and/or Remote Endpoint, if specified), when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </ins> A Stopped Event occurs after the Listener has stopped listening.


Question:
In the "Specifying Endpoints" section, added a reference to the Selection Property that does a similar thing but with more fine-grained control. It wasn't clear to me what is the best place to add this, so I put it right below the first example of specifying an interface name for the Local Endpoint to say that you can also do it differently. If you have better suggestions, please let me know. To the ListenError and RendezvousError, I added text mentioning the "reconcile Endpoints and Properties" pitfall. I think this is probably more general, i.e., there might be more sources of errors than just local interface, so I kept it generic.
For Local Address Preference we only have the option to prefer stable or temporary. However, I guess we would also need a way to e.g. specify that stable is required, no?
Is this addressed by PR ?
I don't think so.
When reading the current API draft, I was wondering the following: If an application wants to specify one or multiple local network interfaces, it can either set the Local Endpoint(s) or it can set the "Interface Instance or Type" Selection Property. I think both ways are valid and should exist, but I'm wondering if we should specify anything on the interaction of these two ways to do a similar thing. For example, should we explicitly mention the Selection Property in Section 5.1 ("Specifying Endpoints"), to make readers aware that there is a "better" way to do this, which allows more flexibility? Also, if an application specifies conflicting things, I guess this leads to an InitiateError, ListenError, or RendezvousError. Our current text already says this for the InitiateError: But should we make this particular issue more explicit here and/or should we add it for the ListenError or RendezvousError?
I think so, yes! Regarding the error in case of a conflict: I think so, yes - to all your questions: make it more explicit, state it in the description of both the ListenError and RendezvousError. Just my 2 cents
Thank you - works for me!

contained within the RendezvousDone<> Event, and is ready to use as soon as it is passed to the application via the Event. <del> An RendezvousError occurs either when the Preconnection cannot be fulfilled for listening, when the Local Endpoint or Remote Endpoint cannot be resolved, when no transport-layer connection can be established to the Remote Endpoint, or when the application is prohibited from rendezvous by policy. </del> <ins> An RendezvousError occurs either when the Properties and Security Parameters of the Preconnection cannot be fulfilled for rendezvous or cannot be reconciled with the Local and/or Remote Endpoints, when the Local Endpoint or Remote Endpoint cannot be resolved, when no transport-layer connection can be established to the Remote Endpoint, or when the application is prohibited from rendezvous by policy. </ins> When using some NAT traversal protocols, e.g., Interactive Connectivity Establishment (ICE) RFC5245, it is expected that the


Question:
Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!

The Transport Services architecture evolves this general model of interaction, aiming to both modernize the API surface presented to applications by the transport layer and enrich the capabilities of <del> the Transport System implementation.  It combines interfaces for </del> <ins> the Transport Services implementation.  It combines interfaces for </ins> multiple interaction patterns into a unified whole.  By combining name resolution with connection establishment and data transfer in a single API, it allows for more flexible implementations to provide


Question:
Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!

make use of the data that arrived; the ability to manage dependencies between messages, when the <del> Transport System could decide to not deliver a message, either following packet loss or because it has missed a deadline.  In particular, this can avoid (re-)sending data that relies on a </del> <ins> Transport Services system could decide to not deliver a message, either following packet loss or because it has missed a deadline. In particular, this can avoid (re-)sending data that relies on a </ins> previous transmission that was never received. the ability to automatically assign messages and connections to


Question:
Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!

Transport Properties: Transport Properties allow the application to express their requirements, prohibitions, and preferences and <del> configure the Transport System.  There are three kinds of </del> <ins> configure the Transport Services system.  There are three kinds of </ins> Transport Properties: Selection Properties (preestablishment) that can only be


Question:
Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!

Connection Properties: The Connection Properties are used to configure protocol-specific options and control per-connection <del> behavior of the Transport System; for example, a protocol-specific Connection Property can express that if UDP is used, the implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but can be used in this way by an implementation during connection establishment.  Connection Properties are specified on a Preconnection prior to Connection establishment, and can be modified on the Connection later. Changes made to Connection Properties after Connection establishment take effect on a best-effort basis. </del> <ins> behavior of the Transport Services system; for example, a protocol-specific Connection Property can express that if UDP is used, the implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but can be used in this way by an implementation during connection establishment.  Connection Properties are specified on a Preconnection prior to Connection establishment, and can be modified on the Connection later.  Changes made to Connection Properties after Connection establishment take effect on a best- effort basis. </ins> 4.1.3.


Question:
Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!

Properties when sending.) Abort: The action the application takes on a Connection to <del> indicate a Close and also indicate that the Transport System SHOULD NOT attempt to deliver any outstanding data.  This is intended for immediate termination of a connection, without </del> <ins> indicate a Close and also indicate that the Transport Services system SHOULD NOT attempt to deliver any outstanding data.  This is intended for immediate termination of a connection, without </ins> cleaning up state. 4.2.


Question:
Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!

protocols are not incorrectly swapped, Transport Services systems SHOULD only automatically generate equivalent Protocol Stacks when the transport security protocols within the stacks are identical. <del> Specifically, a Transport System would consider protocols </del> <ins> Specifically, a Transport Services system would consider protocols </ins> identical only if they are of the same type and version.  For example, the same version of TLS running over two different transport Protocol Stacks are considered equivalent, whereas TLS


Question:
Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!

protocol state, cached path state, and heuristics, may be shared (e.g. across multiple connections in an application).  This provides efficiency and convenience for the application, since the Transport <del> System implementation can automatically optimize behavior. </del> <ins> Services implementation can automatically optimize behavior. </ins> There are several reasons, however, that an application might want to explicitly isolate some Connections.  These reasons include:


Question:
this should
Right there was a typo: Replacing the last 2 sentences, the last sentence ought to be: " Endpoints should avoid IP fragmentation ({{!RFC8304}}) and when used with transports running over IP version 4 the Don't Fragment bit will be set." These are two separate issues that a stack implementor has to decide to do: (1) Decide if the endpoint will fragment; (2) decide if the path can fragment the fragments. In some OS this will be bundled together, in other OS they will not.
Discussed on the interim call. The name probably could be much better. We also want to model in the text the atomicity property of UDP transfers.
This text is broken: section 5.1 / o Singular Transmission: when this is true, the application requests to avoid transport-layer segmentation or network-layer fragmentation. Some transports implement network-layer fragmentation avoidance (Path MTU Discovery) without exposing this functionality to the application; in this case, only transport- layer segmentation should be avoided, by fitting the message into a single transport-layer segment or otherwise failing. Otherwise, network-layer fragmentation should be avoided--e.g. by requesting the IP Don't Fragment bit to be set in case of UDP(-Lite) and IPv4 (SET_DF in [RFC8304]). / we need to rewrite
Waiting to see exactly how DPLPMTUD finishes WGLC ... will be ready for text in Jan.
Reads much better except the last broken sentence

than -1, it sets the minimum protection in protocols that allow limiting the checksum length (e.g.  UDP-Lite). <del> Singular Transmission: when this is true, the application requests to avoid transport-layer segmentation or network-layer fragmentation.  Some transports implement network-layer fragmentation avoidance (Path MTU Discovery) without exposing this functionality to the application; in this case, only transport- layer segmentation should be avoided, by fitting the message into a single transport-layer segment or otherwise failing.  Otherwise, network-layer fragmentation should be avoided--e.g. by requesting the IP Don't Fragment bit to be set in case of UDP(-Lite) and IPv4 (SET_DF in RFC8304). </del> <ins> Singular Transmission: When set, this property limits the message size to the Maximum Message Size Before Fragmentation or Segmentation (see Section 10.1.7 of I-D.ietf-taps-interface). Messages larger than this size generate an error.  Setting this avoids transport-layer segmentation or network-layer fragmentation.  When used with transports running over IP version 4 the Don't Fragment bit will be set to avoid on-path IP fragmentation (RFC8304). </ins> 5.1.2.


Question:
Fig. 4 isn't fully consistent with sec. 12 in the API document. A few things that stood out to me: InitiateWithSend() is missing. I can see that this isn't trying to cover everything, but randomly leaving some things out makes it all a bit confusing IMO... "Connection Received" reads as if it should really be the "ConnectionReceived<>" event in the API doc. So I would put these events there and use the "<>" to indicate them. Same with "Closed"... this is actually an event, so why not write it as such, with the "<>"? RendezvousDone is missing... should we include all events or not? Of course that would then also require adding Sent, Received, ... maybe it would be better to indicate that events are events, but put a statement somewhere saying that not all events are shown. In the same vein, I would replace "Connection Ready" with "Ready<>" "Conn. Finished" reads as if it might be an event, but this event doesn't exist... I would just remove this
I've added InitiateWithSend(), and removed Conn. Finished; you're right, these are confusing. This diagram does not use the API draft's event notation, and I'm not sure it makes sense to introduce it here -- it would require a bit more expository text only to make a diagram that is an attempt to provide a high-level view provide a... less high-level view. (The expository text now says "... some actions ... have been omitted for brevity and simplicity" and I think that's the right approach.)
Agreed!
lgtm

actions are alternatives (e.g., whether to initiate a connection or to listen for incoming connections), while others are optional (e.g., setting Connection and Message Properties in Pre-Establishment) or <del> have been omitted for brevity. </del> <ins> have been omitted for brevity and simplicity. </ins> 4.1.1.


Question:
Following the discussion in , explain why TCP UTO is included as a Protocol-Specific Property, while other properties are not. Also, some minor consistency fixes.
Thanks for doing this!Thanks

10.2. <del> These properties specifies configurations for the User Timeout Option </del> <ins> These properties specify configurations for the User Timeout Option </ins> (UTO), in case TCP becomes the chosen transport protocol. Implementation is optional and of course only sensible if TCP is implemented in the transport system. <del> All of the below parameters are optional (e.g., it is possible to </del> <ins> These TCP-specific properties are included here because the feature "Suggest timeout to the peer" is part of the minimal set of transport services I-D.ietf-taps-minset, where this feature was categorized as "functional".  This means that when an implementation offers this feature, it has to expose an interface to it to the application. Otherwise, the implementation might violate assumptions by the application, which could cause the application to fail. All of the below properties are optional (e.g., it is possible to </ins> specify "User Timeout Enabled" as true, but not specify an Advertised User Timeout value; in this case, the TCP default will be used).


Question:
Following the discussion in , explain why TCP UTO is included as a Protocol-Specific Property, while other properties are not. Also, some minor consistency fixes.
Thanks for doing this!Thanks

Integer <del> Default: :the TCP default </del> <ins> the TCP default </ins> This time value is advertised via the TCP User Timeout Option (UTO) RFC5482 at the remote endpoint to adapt its own "Timeout for aborting


Question:
... as suggested by NAME
The section on partial send says: "All data sent with the same MessageContext object will be treated as belonging to the same Message, and will constitute an in-order series until the endOfMessage is marked. Once the end of the Message is marked, the MessageContext object may be re-used as a new Message with identical parameters." Can we reconsider for a second if that is really the way we want to design this? This is really implicit and therefore an easy source for errors. I guess we could alternatively use an explicit message identifier...? Or the send action always return an identifier and for subsequent sends we input this identifier again? Or someone has a smarter idea?
I don't have my head buried in code like some others here (NAME NAME , ..), so I guess that these folks should speak up - but just from reading this, I agree that the current design sounds like an easy source for errors.
I'd prefer to just remove the part that mentions reusing the same object. That's an implementation detail (and a perf optimization). The rest seems correct.

All data sent with the same MessageContext object will be treated as belonging to the same Message, and will constitute an in-order series <del> until the endOfMessage is marked.  Once the end of the Message is marked, the MessageContext object may be re-used as a new Message with identical parameters. </del> <ins> until the endOfMessage is marked. </ins> 7.7.


Question:
Fixing three oddities in the abstract, issue
Odd English: /where endpoints have multiple interfaces and potential transport protocols to select from/where endpoints could select from multiple interfaces and potential transport protocols./ We use the words /abstract programming interface/ and the acronym /API/ but never tie these two together. I am not huge fan of: /lowest common denominator interface/ ... as an engineer, this sounds like a good thing, although /lowest/ isn't that clear, so I wonder if we can find a better term?
Resolved in PR
LGTM modulo one nit

Abstract <del> This document describes an abstract programming interface, API, to the transport layer, following the Transport Services Architecture. It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime.  It is intended to replace the traditional BSD sockets API as the common interface to the transport layer, in an environment where endpoints could select from multiple interfaces and potential transport protocols. </del> <ins> This document describes an abstract application programming interface, API, to the transport layer, following the Transport Services Architecture.  It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime.  It is intended to replace the traditional BSD sockets API as the common interface to the transport layer, in an environment where endpoints could select from multiple interfaces and potential transport protocols. </ins> 1.


Question:
Changes to address Issue
Message Properties This isn’t really about /removing/ we need to express this differently, not sure what you wish to say: For example, TCP cannot remove bytes from its send buffer, while in case of SCTP, such control over the SCTP send buffer can be exercised using the partial reliability extension [RFC8303]. and: /Final: when this is true, it means that a transport connection can be closed immediately after its transmission./ I think this is: /Final: when this is true, it means that a transport connection can be closed immediately after transmission of the message./
See PR Update draft-ietf-taps-URL
Looks good, just some more nits on top

5.1.1. Lifetime: this should be implemented by removing the Message from <del> its queue of pending Messages after the Lifetime has expired.  A </del> <ins> the queue of pending Messages after the Lifetime has expired.  A </ins> queue of pending Messages within the transport system implementation that have yet to be handed to the Protocol Stack can always support this property, but once a Message has been sent into the send buffer of a protocol, only certain protocols may <del> support de-queueing a message.  For example, TCP cannot remove bytes from its send buffer, while in case of SCTP, such control over the SCTP send buffer can be exercised using the partial reliability extension RFC8303.  When there is no standing queue of Messages within the system, and the Protocol Stack does not support removing a Message from its buffer, this property may be ignored. </del> <ins> support removing a message.  For example, an implementation cannot cannot remove bytes from a TCP send buffer, while it can remove data from a SCTP send buffer using the partial reliability extension RFC8303.  When there is no standing queue of Messages within the system, and the Protocol Stack does not support the removal of a Message from the stack's send buffer, this property may be ignored. </ins> Priority: this represents the ability to prioritize a Message over other Messages.  This can be implemented by the system re-ordering


Question:
Changes to address Issue
Message Properties This isn’t really about /removing/ we need to express this differently, not sure what you wish to say: For example, TCP cannot remove bytes from its send buffer, while in case of SCTP, such control over the SCTP send buffer can be exercised using the partial reliability extension [RFC8303]. and: /Final: when this is true, it means that a transport connection can be closed immediately after its transmission./ I think this is: /Final: when this is true, it means that a transport connection can be closed immediately after transmission of the message./
See PR Update draft-ietf-taps-URL
Looks good, just some more nits on top

could choose to send Messages of different Priority on streams of different priority. <del> Ordered: when this is false, it disables the requirement of in- </del> <ins> Ordered: when this is false, this disables the requirement of in- </ins> order-delivery for protocols that support configurable ordering. <del> Safely Replayable: when this is true, it means that the Message </del> <ins> Safely Replayable: when this is true, this means that the Message </ins> can be used by mechanisms that might transfer it multiple times - e.g., as a result of racing multiple transports or as part of TCP Fast Open. <del> Final: when this is true, it means that a transport connection can be closed immediately after its transmission. </del> <ins> Final: when this is true, this means that a transport connection can be closed immediately after transmission of the message. </ins> Corruption Protection Length: when this is set to any value other than -1, it sets the minimum protection in protocols that allow


Question:
I think this helps, but one of the confusions is the distinction between a framing to provide a message-oriented API, and the use of framers underneath that API to change the representation of messages on the wire. I wonder if some of the difficulties we've had with framers is that some of us have been using the term to represent one of these concepts, and some the other? One is the concept of a framer that accumulates data and returns an object from a call, rather than returning a byte array containing a (partial) HTTP response. That's the API-level framer. The other is the sort of framer that performs TLS encryption on the HTTP request, after has been called. This transforms data, below the API. Do we need two different terms?
NAME - personally, I always thought that Framers can do both of these things; if this wasn't clear enough before, then I think your part 1 (returning an HTTPResponse object) was clear from before, and now this PR makes it clear that they also intercept the send call to transform data afterwards. So IMHO that's just the clarification that was needed.
Sorry! Obviously I only wanted to comment, but hit the wrong button :)
I know we moved some text about framers into the implementation doc but that really doesn't seem right when I look at it now. The section about framers in the implementation doc is the only section that defines an interface which probably is already an indication that just moving this text there was not right. However, also the text in the API doc seems now incomplete. I think we should move it back and rather define some real simple examples framers in the implementation document (just a prefixed length field (as many UDP mapping use) or maybe even an example implementation for STARTTLS). Further after moving it back we could figure out if really all parts of the interface are necessary or if there would be a more minimal interface that we could use. E.g. I'm not sure about the FailConnection() call or at least I think this could need more explanation.
Also I think it would be good to the section on framers earlier in the doc. I will open a separate section to propose some restructuring (as I also think it would be good to have the connection properties earlier).
I think the real problem with framers is that we left them vague to avoid having to worry about all the implications they bring with them (which are a lot as they impact almost every stage of the life of a connection) but also to not limit what implementations can do with them by making them very rigid. But I do agree that the text in API feels somewhat incomplete. Maybe one solution would be to explain what a framer should at least be able to do in the interface draft without specifying the actual API that is in implementation. I think we all agree at when a framer should be able to interact with the connection just not how that interaction is supposed to look like (as that is highly implementation specific).
I disagree that we should move the text back into the API document, since the group was very clear before that the details should be moved to implementation. The boundary we defined was to leave in the API: (a) the definition of what a framer is and why it's used and (b) the interface an application uses to add a framer to the connection. The API text should be complete with regards to how a user of a framer performs actions. What specific text would we want to add here?
First as I say that's the only piece of additional interface we define in the implementation draft which already is a sign that it's maybe not ideal. But for the API draft the part of how a framer interact with the transport is really unclear and looking at the part of interface, that now defined in the implementation doc, makes it really clear. I disagree that this part of the interface can or should be left to the implementation. The fact that you have to call the framer before you start any transmission and the events a framer should be aware of are generic and nothing implementation specific.
In the implementation draft we say: "A Message Framer is primarily defined by the set of code that handles events for a framer implementation" My assumption is that a custom framer implementation could be part of the application logic and therefore we need to define this interface as well. However looking at the implementation draft I guess I now confused myself about how this actually works. Why is the sending logic asynchronous? Isn't this something that happens iteratively when the application calls send(). How would that actually work? I thought the application could just call URL() and then the connection could call URL() and that would simply return a modified message... can you give an example for sending and receiving based on the interfaces currently defined in the implementation draft? Also please note that while I think the interface definition belongs in API draft, however, there are comments about copying and curser handling which should/could probably say in the implementation draft.
Interim: Add to -interface: Explain that framer(s) is in between the rest of the protocol stack and the application Intercepts calls to start/stop and send/receive And just leave as is, and have another framers document in the future once we get more details.
I think it'll be helpful to be a bit clearer on the timing here, see comment.Thanks a lot for doing this - to me, this looks really good. It makes things much clearer for readers of this document.I think this should clarify it, thanks!

boundaries to function, each application layer protocol has defined its own framing. <ins> To use a Message Framer, the application adds it to its Preconnection object.  Then, the Message Framer can intercept all calls to Send() or Receive() on a Connection to add Message semantics, in addition to interacting with the setup and teardown of the Connection.  A Framer can start sending data before the application sends data if the framing protocol requires a prefix or handshake (see RFC8229 for an example of such a framing protocol). </ins> Note that while Message Framers add the most value when placed above a protocol that otherwise does not preserve message boundaries, they can also be used with datagram- or message-based protocols.  In these


Question:
sec 4.2.2 "implementations MUST provide a method for the application to determine the entire set of possible values for each property." Is this meant to be a requirement for a machine-readable API for learning the enum, or merely a requirement for documentation? i.e. is it satisfied if the values are in the man page or comments of the C header file?
As a by-note, isn't this a great place to use "REQUIRED" and say whether it is required to specify or required to support :-).
Proposal: Just remove "however, implementations MUST provide a method for the application to determine the entire set of possible values for each property." This is too implementation- and language- specific.

Enumeration: can take one value of a finite set of values, dependent on the property itself.  The representation is <del> implementation dependent; however, implementations MUST provide a method for the application to determine the entire set of possible values for each property. </del> <ins> implementation dependent. </ins> Preference: can take one of five values (Prohibit, Avoid, Ignore, Prefer, Require) for the level of preference of a given property


Question:
There are many ways to do this, but this one mimics the "private browsing" paradigm" as I understand it.
Can you say more? I read as specifically about flushing state, not Connection Group vs. Connection issues generally. This is not literally "flushing" the state but I've update taps-interface to reflect this design while, I think, preserving the spirit of the original text.
Connection Groups used to be about state and context sharing as well as entanglement. Now it's about entanglement. We need to rename Connection Groups ("connection contexts"?) in the architecture to replace the existing "group" concept, and to retain "connection group" in the API for entanglement.
Seems like this could be 360 degrees of rotation in our thinking? (which could be OK, NEAT was written to specify both contexts and flow groups). Let's try some definitions here and see if we converge...
I think brings this back in synch again so no need to rename, possibly the last part of this section in architecture should be removed though as we do not have fine-grained control
Section 9.1 of taps-impl loosely refers to the need for an interface to "flush protocol state" to preserve anonymity, but such a capability is not in taps-interface.
I don't like this text: "Applications must have a way to flush protocol cache state if desired. This may be necessary, for example, if application-layer identifiers rotate and clients wish to avoid linkability via trackable TLS tickets or TFO cookies." Those of you who know me, would immediately see a "MUST"..."if desired." and a "may be necessary". My suggestion is that this digs too deep, and we should remove the text. I could also live with something more neutral though: Note: There are case where applications need to flush protocol cache state, for example, if application-layer identifiers rotate and a client wishes to avoid linkability of trackable TLS tickets or TFO cookies.
I'm fine to have the more neutral sentence proposed by Gorry. I don't think we should specify an interface for it but I think it's good to mention.
I agree that the best approach is to make it more neutral. The other option would be to say that this interface is implementation specific. For sure, we do not want it in the API I think.
I have no opinion on Gorry's comment, but I'm a bit mystified by the "shouldn't be in the API doc" argument. Perhaps I'm not understanding the purpose of taps-interface? I thought it was a qualitative description of the controls offered to the application, which this clearly would be!
I would define taps as an interface to control network connections. So flushing state is a good thing in some scenarios for privacy but not really needed to handle network connections.
See also -- this surfaced that we have drifted on connection group versus context, which we need to fix in arch.
Martin to write a PR against API to propose a context API that would provide the intent of this functionality. Alternative is to NOP this in the API doc ("connection contexts are too implementation specific to expose in a general way" or similar)
A second alternative is a one-bit fix: a selection property that requires a given connection to be in a separate connection context (which implies a separate connection group) from other connections created in the preconnection.
A very nice approach IMO, thanks for doing thisI like this approach for the simplicity, but it still solves only half of the problem we have with connection groups vs. connection contexts. I am fine with merging this, but IMHO it does not fully Thanks NAME looks good to me now.

7.1.10. <ins> isolateSession Boolean false When set to true, this property will initiate new Connections using as little cached information (such as session tickets or cookies) as possible from previous connections that are not entangled with it. Any state generated by this Connection will only be shared with entangled connections.  Cloned Connections will use saved state from within the Connection Group. Note that this does not guarantee no leakage of information, as implementations may not be able to fully isolate all caches (e.g. RTT estimates).  Note that this property may degrade connection performance. 7.1.11. </ins> The following generic Connection Properties are read-only, i.e. they cannot be changed by an application. <del> 7.1.10.1. </del> <ins> 7.1.11.1. </ins> zeroRttMsgMaxLen


Question:
There are many ways to do this, but this one mimics the "private browsing" paradigm" as I understand it.
Can you say more? I read as specifically about flushing state, not Connection Group vs. Connection issues generally. This is not literally "flushing" the state but I've update taps-interface to reflect this design while, I think, preserving the spirit of the original text.
Connection Groups used to be about state and context sharing as well as entanglement. Now it's about entanglement. We need to rename Connection Groups ("connection contexts"?) in the architecture to replace the existing "group" concept, and to retain "connection group" in the API for entanglement.
Seems like this could be 360 degrees of rotation in our thinking? (which could be OK, NEAT was written to specify both contexts and flow groups). Let's try some definitions here and see if we converge...
I think brings this back in synch again so no need to rename, possibly the last part of this section in architecture should be removed though as we do not have fine-grained control
Section 9.1 of taps-impl loosely refers to the need for an interface to "flush protocol state" to preserve anonymity, but such a capability is not in taps-interface.
I don't like this text: "Applications must have a way to flush protocol cache state if desired. This may be necessary, for example, if application-layer identifiers rotate and clients wish to avoid linkability via trackable TLS tickets or TFO cookies." Those of you who know me, would immediately see a "MUST"..."if desired." and a "may be necessary". My suggestion is that this digs too deep, and we should remove the text. I could also live with something more neutral though: Note: There are case where applications need to flush protocol cache state, for example, if application-layer identifiers rotate and a client wishes to avoid linkability of trackable TLS tickets or TFO cookies.
I'm fine to have the more neutral sentence proposed by Gorry. I don't think we should specify an interface for it but I think it's good to mention.
I agree that the best approach is to make it more neutral. The other option would be to say that this interface is implementation specific. For sure, we do not want it in the API I think.
I have no opinion on Gorry's comment, but I'm a bit mystified by the "shouldn't be in the API doc" argument. Perhaps I'm not understanding the purpose of taps-interface? I thought it was a qualitative description of the controls offered to the application, which this clearly would be!
I would define taps as an interface to control network connections. So flushing state is a good thing in some scenarios for privacy but not really needed to handle network connections.
See also -- this surfaced that we have drifted on connection group versus context, which we need to fix in arch.
Martin to write a PR against API to propose a context API that would provide the intent of this functionality. Alternative is to NOP this in the API doc ("connection contexts are too implementation specific to expose in a general way" or similar)
A second alternative is a one-bit fix: a selection property that requires a given connection to be in a separate connection context (which implies a separate connection group) from other connections created in the preconnection.
A very nice approach IMO, thanks for doing thisI like this approach for the simplicity, but it still solves only half of the problem we have with connection groups vs. connection contexts. I am fine with merging this, but IMHO it does not fully Thanks NAME looks good to me now.

before or during Connection establishment, see also msg- safelyreplayable.  It is given in Bytes. <del> 7.1.10.2. </del> <ins> 7.1.11.2. </ins> singularTransmissionMsgMaxLen


Question:
There are many ways to do this, but this one mimics the "private browsing" paradigm" as I understand it.
Can you say more? I read as specifically about flushing state, not Connection Group vs. Connection issues generally. This is not literally "flushing" the state but I've update taps-interface to reflect this design while, I think, preserving the spirit of the original text.
Connection Groups used to be about state and context sharing as well as entanglement. Now it's about entanglement. We need to rename Connection Groups ("connection contexts"?) in the architecture to replace the existing "group" concept, and to retain "connection group" in the API for entanglement.
Seems like this could be 360 degrees of rotation in our thinking? (which could be OK, NEAT was written to specify both contexts and flow groups). Let's try some definitions here and see if we converge...
I think brings this back in synch again so no need to rename, possibly the last part of this section in architecture should be removed though as we do not have fine-grained control
Section 9.1 of taps-impl loosely refers to the need for an interface to "flush protocol state" to preserve anonymity, but such a capability is not in taps-interface.
I don't like this text: "Applications must have a way to flush protocol cache state if desired. This may be necessary, for example, if application-layer identifiers rotate and clients wish to avoid linkability via trackable TLS tickets or TFO cookies." Those of you who know me, would immediately see a "MUST"..."if desired." and a "may be necessary". My suggestion is that this digs too deep, and we should remove the text. I could also live with something more neutral though: Note: There are case where applications need to flush protocol cache state, for example, if application-layer identifiers rotate and a client wishes to avoid linkability of trackable TLS tickets or TFO cookies.
I'm fine to have the more neutral sentence proposed by Gorry. I don't think we should specify an interface for it but I think it's good to mention.
I agree that the best approach is to make it more neutral. The other option would be to say that this interface is implementation specific. For sure, we do not want it in the API I think.
I have no opinion on Gorry's comment, but I'm a bit mystified by the "shouldn't be in the API doc" argument. Perhaps I'm not understanding the purpose of taps-interface? I thought it was a qualitative description of the controls offered to the application, which this clearly would be!
I would define taps as an interface to control network connections. So flushing state is a good thing in some scenarios for privacy but not really needed to handle network connections.
See also -- this surfaced that we have drifted on connection group versus context, which we need to fix in arch.
Martin to write a PR against API to propose a context API that would provide the intent of this functionality. Alternative is to NOP this in the API doc ("connection contexts are too implementation specific to expose in a general way" or similar)
A second alternative is a one-bit fix: a selection property that requires a given connection to be in a separate connection context (which implies a separate connection group) from other connections created in the preconnection.
A very nice approach IMO, thanks for doing thisI like this approach for the simplicity, but it still solves only half of the problem we have with connection groups vs. connection contexts. I am fine with merging this, but IMHO it does not fully Thanks NAME looks good to me now.

Packet Size (MPS) as described in Datagram PLPMTUD I-D.ietf-tsvwg- datagram-plpmtud. <del> 7.1.10.3. </del> <ins> 7.1.11.3. </ins> sendMsgMaxLen


Question:
There are many ways to do this, but this one mimics the "private browsing" paradigm" as I understand it.
Can you say more? I read as specifically about flushing state, not Connection Group vs. Connection issues generally. This is not literally "flushing" the state but I've update taps-interface to reflect this design while, I think, preserving the spirit of the original text.
Connection Groups used to be about state and context sharing as well as entanglement. Now it's about entanglement. We need to rename Connection Groups ("connection contexts"?) in the architecture to replace the existing "group" concept, and to retain "connection group" in the API for entanglement.
Seems like this could be 360 degrees of rotation in our thinking? (which could be OK, NEAT was written to specify both contexts and flow groups). Let's try some definitions here and see if we converge...
I think brings this back in synch again so no need to rename, possibly the last part of this section in architecture should be removed though as we do not have fine-grained control
Section 9.1 of taps-impl loosely refers to the need for an interface to "flush protocol state" to preserve anonymity, but such a capability is not in taps-interface.
I don't like this text: "Applications must have a way to flush protocol cache state if desired. This may be necessary, for example, if application-layer identifiers rotate and clients wish to avoid linkability via trackable TLS tickets or TFO cookies." Those of you who know me, would immediately see a "MUST"..."if desired." and a "may be necessary". My suggestion is that this digs too deep, and we should remove the text. I could also live with something more neutral though: Note: There are case where applications need to flush protocol cache state, for example, if application-layer identifiers rotate and a client wishes to avoid linkability of trackable TLS tickets or TFO cookies.
I'm fine to have the more neutral sentence proposed by Gorry. I don't think we should specify an interface for it but I think it's good to mention.
I agree that the best approach is to make it more neutral. The other option would be to say that this interface is implementation specific. For sure, we do not want it in the API I think.
I have no opinion on Gorry's comment, but I'm a bit mystified by the "shouldn't be in the API doc" argument. Perhaps I'm not understanding the purpose of taps-interface? I thought it was a qualitative description of the controls offered to the application, which this clearly would be!
I would define taps as an interface to control network connections. So flushing state is a good thing in some scenarios for privacy but not really needed to handle network connections.
See also -- this surfaced that we have drifted on connection group versus context, which we need to fix in arch.
Martin to write a PR against API to propose a context API that would provide the intent of this functionality. Alternative is to NOP this in the API doc ("connection contexts are too implementation specific to expose in a general way" or similar)
A second alternative is a one-bit fix: a selection property that requires a given connection to be in a separate connection context (which implies a separate connection group) from other connections created in the preconnection.
A very nice approach IMO, thanks for doing thisI like this approach for the simplicity, but it still solves only half of the problem we have with connection groups vs. connection contexts. I am fine with merging this, but IMHO it does not fully Thanks NAME looks good to me now.

This property represents the maximum Message size that an application can send. <del> 7.1.10.4. </del> <ins> 7.1.11.4. </ins> recvMsgMaxLen


Question:
Note, the change to the API draft here is a purely editorial detail that I fixed here in passing: the multipath selection property was renamed and this fixes the text referring to it.
"what we discussed" - you mean in , where I say that I stumbled over a sentence? This PR does update that sentence (simply removing "with migration support" from it because any multipath protocol can do that).
no, i meant what we discussed at the interim about using the handover, interactive, aggregate terminology. but i saw that this was not so easily done and we are all happy with your solution, so all good :)
Before distinguishing between protocols that do "multipath" and "migrating between paths", it might help to define these terms. This is tripping is up in QUIC, and IIRC the original "Multipath TCP" was pretty much the migration case. Something like, "In this section we distinguish between 'multipath' protocols and protocols that allow migration between paths. The first means ..."
This is in section 7.2 of taps-impl.
We define multipath (by policy in section 6.1.7 handover, interactive, aggregate) in the API doc. Section 4.2 in Implementation should use these definitions.
I wanted to fix this now, but stumbled over the following sentence in the implementation draft: This talks about the protocol below the transport services system; do multipath-supporting protocols with no migration support exist? I struggle to imagine a scheduler that wouldn't make this happen... e.g. lowest latency scheduling, but with the exception: if a path becomes completely unavailable, keep going? :-) Looking at the three policies in section 6.1.7 of our API, clearly, migration should work with all of them (and "Handover" is limited in that it doesn't do anything else, but it's gotta be a subset of the others anyway, I'd say). Am I missing something? Just checking...
I think the example of no migration support would be a multipath protocol that is not able to add new paths, so SCTP without support for the ADD_ADDR extension perhaps? Not sure this is a case we need to worry about though...
Ah, a multipath protocol that doesn't do multipath :-)
Well, it can do multipath with the paths you give it from the beginning :) Possibly something else was intended with the text from the beginning, but this is what I could think of...
Looks good to me!Thanks for fixing the nits!

Handover This property specifies the local policy for transferring data across <del> multiple paths between the same end hosts if Parallel Use of Multiple Paths is not set to Disabled (see multipath-mode).  Possible values are: </del> <ins> multiple paths between the same end hosts if Multipath Transport is not set to Disabled (see multipath-mode).  Possible values are: </ins> The connection ought only to attempt to migrate between different paths when the original path is lost or becomes unusable.  The


Question:
Note, the change to the API draft here is a purely editorial detail that I fixed here in passing: the multipath selection property was renamed and this fixes the text referring to it.
"what we discussed" - you mean in , where I say that I stumbled over a sentence? This PR does update that sentence (simply removing "with migration support" from it because any multipath protocol can do that).
no, i meant what we discussed at the interim about using the handover, interactive, aggregate terminology. but i saw that this was not so easily done and we are all happy with your solution, so all good :)
Before distinguishing between protocols that do "multipath" and "migrating between paths", it might help to define these terms. This is tripping is up in QUIC, and IIRC the original "Multipath TCP" was pretty much the migration case. Something like, "In this section we distinguish between 'multipath' protocols and protocols that allow migration between paths. The first means ..."
This is in section 7.2 of taps-impl.
We define multipath (by policy in section 6.1.7 handover, interactive, aggregate) in the API doc. Section 4.2 in Implementation should use these definitions.
I wanted to fix this now, but stumbled over the following sentence in the implementation draft: This talks about the protocol below the transport services system; do multipath-supporting protocols with no migration support exist? I struggle to imagine a scheduler that wouldn't make this happen... e.g. lowest latency scheduling, but with the exception: if a path becomes completely unavailable, keep going? :-) Looking at the three policies in section 6.1.7 of our API, clearly, migration should work with all of them (and "Handover" is limited in that it doesn't do anything else, but it's gotta be a subset of the others anyway, I'd say). Am I missing something? Just checking...
I think the example of no migration support would be a multipath protocol that is not able to add new paths, so SCTP without support for the ADD_ADDR extension perhaps? Not sure this is a case we need to worry about though...
Ah, a multipath protocol that doesn't do multipath :-)
Well, it can do multipath with the paths you give it from the beginning :) Possibly something else was intended with the text from the beginning, but this is what I could think of...
Looks good to me!Thanks for fixing the nits!

When a path change occurs, e.g., when the IP address of an interface changes or a new interface becomes available, the Transport Services <del> implementation is responsible for notifying the application of the change.  The path change may interrupt connectivity on a path for an active connection or provide an opportunity for a transport that supports multipath or migration to adapt to the new paths. </del> <ins> implementation is responsible for notifying the Protocol Instance of the change.  The path change may interrupt connectivity on a path for an active connection or provide an opportunity for a transport that supports multipath or migration to adapt to the new paths.  Note that, from the Transport Services API point of view, migration is considered a part of multipath connectivity; it is just a limiting policy on multipath usage.  If the "multipath" Selection Property is set to "Disabled", migration is disallowed. </ins> For protocols that do not support multipath or migration, the Protocol Instances should be informed of the path change, but should


Question:
Note, the change to the API draft here is a purely editorial detail that I fixed here in passing: the multipath selection property was renamed and this fixes the text referring to it.
"what we discussed" - you mean in , where I say that I stumbled over a sentence? This PR does update that sentence (simply removing "with migration support" from it because any multipath protocol can do that).
no, i meant what we discussed at the interim about using the handover, interactive, aggregate terminology. but i saw that this was not so easily done and we are all happy with your solution, so all good :)
Before distinguishing between protocols that do "multipath" and "migrating between paths", it might help to define these terms. This is tripping is up in QUIC, and IIRC the original "Multipath TCP" was pretty much the migration case. Something like, "In this section we distinguish between 'multipath' protocols and protocols that allow migration between paths. The first means ..."
This is in section 7.2 of taps-impl.
We define multipath (by policy in section 6.1.7 handover, interactive, aggregate) in the API doc. Section 4.2 in Implementation should use these definitions.
I wanted to fix this now, but stumbled over the following sentence in the implementation draft: This talks about the protocol below the transport services system; do multipath-supporting protocols with no migration support exist? I struggle to imagine a scheduler that wouldn't make this happen... e.g. lowest latency scheduling, but with the exception: if a path becomes completely unavailable, keep going? :-) Looking at the three policies in section 6.1.7 of our API, clearly, migration should work with all of them (and "Handover" is limited in that it doesn't do anything else, but it's gotta be a subset of the others anyway, I'd say). Am I missing something? Just checking...
I think the example of no migration support would be a multipath protocol that is not able to add new paths, so SCTP without support for the ADD_ADDR extension perhaps? Not sure this is a case we need to worry about though...
Ah, a multipath protocol that doesn't do multipath :-)
Well, it can do multipath with the paths you give it from the beginning :) Possibly something else was intended with the text from the beginning, but this is what I could think of...
Looks good to me!Thanks for fixing the nits!

implementation should not aggressively close connections in these scenarios. <del> If the Protocol Stack includes a transport protocol that also supports multipath connectivity with migration support, the Transport Services implementation should also inform the Protocol Instance of potentially new paths that become permissible based on the Selection Properties passed by the application.  A protocol can then establish new subflows over new paths while an active path is still available or, if migration is supported, also after a break has been detected, and should attempt to tear down subflows over paths that are no longer used.  The Transport Services API provides an interface to set a multipath policy that indicates when and how different paths should </del> <ins> If the Protocol Stack includes a transport protocol that supports multipath connectivity, the Transport Services implementation should also inform the Protocol Instance of potentially new paths that become permissible based on the "multipath" Selection Property and the "multipath-policy" Connection Property choices made by the application.  A protocol can then establish new subflows over new paths while an active path is still available or, if migration is supported, also after a break has been detected, and should attempt to tear down subflows over paths that are no longer used.  The Transport Services API's Connection Property "multipath-policy" allows an application to indicate when and how different paths should </ins> be used.  However, detailed handling of these policies is still <del> implementation-specific.  The decision about when to create a new </del> <ins> implementation-specific.  For example, if the "multipath" Selection Property is set to "active", the decision about when to create a new </ins> path or to announce a new path or set of paths to the remote endpoint, e.g., in the form of additional IP addresses, is <del> implementation-specific or could be be supported by future API extensions.  If the Protocol Stack includes a transport protocol that does not support multipath, but does support migrating between paths, the update to the set of available paths can trigger the connection to be migrated. In case of Pooled Connections pooled-connections, the transport system may add connections over new paths or different protocols to the pool if permissible based on the multipath policy and Selection </del> <ins> implementation-specific.  If the Protocol Stack includes a transport protocol that does not support multipath, but does support migrating between paths, the update to the set of available paths can trigger the connection to be migrated. In case of Pooled Connections pooled-connections, the Transport Services implementation may add connections over new paths to the pool if permissible based on the multipath policy and Selection </ins> Properties.  In case a previously used path becomes unavailable, the transport system may disconnect all connections that require this path, but should not disconnect the pooled connection object exposed


Question:
Section 7.2.6. says " for example, if a transport stack that only provides a single in-order reliable stream is selected, prioritization information can only be ignored." I don't think this is entirely true as you can still decide in which order you schedule independent messages on one stream.
I don't get this. The sentence says "in-order". Scheduling them from buffer A into buffer B in accordance with priorities won't help when everything leaves buffer B in a fixed sequence.
How about a less complex sentence: ..."for example, if the transport system selects a stack that only provides a single in-order reliable stream, the prioritization information is ignored."
message on the taps "layer" are independent. so the order an application calls send on these message doesn't have to be the same order the messages are send on an "in-order stream"
Oh, now I see what you mean. Hmmm... looking at the text, it seems that we could just delete this sentence and the problem is solved?
I think what was intended with the example was to show that the set priorities may not have any effect. Perhaps we should instead just add "and the set priorities may not have any effect" if we want to be explicit? Removing it also works though.
I think just add that!
I'm for removing it (I think I wrote this sentence btw :-) ). Giving this example just throws off someone who thinks about this case like Mirja did here - even if we say "may not apply", the reader may (correctly) think "but why, in this case they CAN well apply!". So I don't find that helpful. For context, the full current statement is: and I believe that we say everything we need to say if we just change this into:
I like simple examples, this one wasn't great so this is OK.

(e.g.  I-D.ietf-httpbis-priority. A Transport Services system gives no guarantees about how its <del> expression of relative priorities will be realized; for example, if a transport stack that only provides a single in-order reliable stream is selected, prioritization information can only be ignored. However, the Transport Services system will seek to ensure that performance of relatively-prioritized connections and messages is not worse with respect to those connections and messages than an equivalent configuration in which all prioritization properties are left at their defaults. </del> <ins> expression of relative priorities will be realized.  However, the Transport Services system will seek to ensure that performance of relatively-prioritized connections and messages is not worse with respect to those connections and messages than an equivalent configuration in which all prioritization properties are left at their defaults. </ins> The Transport Services interface does order Connection Priority over the Priority Message Property.  In the absense of other externalities


Question:
I am sure this has been discussed, but reading now it seems strange to me to use "Prefer" as the default for a Selection Property that affects how the application interacts with the API. Using "Prefer" means that I do not know what service I will get when using the default settings? In this case I do not know if I get messages or not if I use the defaults.
This should be Ignore as a default.

Preference <del> Prefer </del> <ins> Ignore </ins> This property specifies whether the application needs or prefers to use a transport protocol that preserves message boundaries.


Question:
Interface, Section 2, "A unified interface to datagram and connection-oriented transports, allowing use of a common API for connection-establishment and closing". Should this be "…to datagram and stream-oriented transports"? At what point do we explain that and are also used for connectionless protocols? This change would finesse the question here, leaving it for Section 3, or we can restructure the draft to clarify earlier.
Yes to (1): Datagram protocols can be connection-oriented or not; however the point here seems to be either: /interface to datagram and stream-oriented transports/ or /interface to both connection-less and connection-oriented transports/ ... I'd favour the first, it's clear enough and doesn't use terms that we later re-use. Also to (2): I think we could insert a specific sentence after: " A Connection represents an instance of a transport Protocol Stack on which data can be sent to and/or received from a Remote Endpoint (i.e., depending on the kind of transport, connections can be bi-directional or unidirectional). " That explicitly says something like: "This connections are presently consistently to the application, irrespective of whether the underlying transport is connection-less and connection-oriented."

applications written to a single API to make use of transport protocols in terms of the features they provide. <del> A unified interface to datagram and connection-oriented transports, allowing use of a common API for connection- establishment and closing. </del> <ins> A unified interface to datagram and stream-oriented transports, allowing use of a common API for connection establishment and closing. </ins> Message-orientation, as opposed to stream-orientation, using application-assisted framing and deframing where the underlying


Question:
Interface, Section 2, "A unified interface to datagram and connection-oriented transports, allowing use of a common API for connection-establishment and closing". Should this be "…to datagram and stream-oriented transports"? At what point do we explain that and are also used for connectionless protocols? This change would finesse the question here, leaving it for Section 3, or we can restructure the draft to clarify earlier.
Yes to (1): Datagram protocols can be connection-oriented or not; however the point here seems to be either: /interface to datagram and stream-oriented transports/ or /interface to both connection-less and connection-oriented transports/ ... I'd favour the first, it's clear enough and doesn't use terms that we later re-use. Also to (2): I think we could insert a specific sentence after: " A Connection represents an instance of a transport Protocol Stack on which data can be sent to and/or received from a Remote Endpoint (i.e., depending on the kind of transport, connections can be bi-directional or unidirectional). " That explicitly says something like: "This connections are presently consistently to the application, irrespective of whether the underlying transport is connection-less and connection-oriented."

and/or received from a Remote Endpoint (i.e., a logical connection that, depending on the kind of transport, can be bi-directional or unidirectional, and that can use a stream protocol or a datagram <del> protocol).  Connections can be created from Preconnections in three ways: by initiating the Preconnection (i.e., actively opening, as in a client; initiate), through listening on the Preconnection (i.e., passively opening, as in a server listen), or rendezvousing on the Preconnection (i.e., peer to peer establishment; rendezvous). </del> <ins> protocol).  Connections are presented consistently to the application, irrespective of whether the underlying transport is connection-less or connection-oriented.  Connections can be created from Preconnections in three ways: by initiating the Preconnection (i.e., actively opening, as in a client; initiate), through listening on the Preconnection (i.e., passively opening, as in a server listen), or rendezvousing on the Preconnection (i.e., peer to peer establishment; rendezvous). </ins> Once a Connection is established, data can be sent and received on it in the form of Messages.  The interface supports the preservation of