jiebi/CodeConvo huggingface dataset:
Change:
arch doc sec 4.1.4: "When receiving Messages, Message Properties can contain information about the received Message, such as metadata generated at the receiver and information signalled by the remote endpoint." Maybe provide an example here...?
Suggestion: ECN, which is information given from UDP in the form of such metadata.
QUIC stream identifier example works
Final message is in API, just use that
LGTM modulo one nit - but see if you agree with my suggestion. If you don't, I'm ok with this anyway.

Discussion:
Endpoint.  When receiving Messages, Message Properties can contain information about the received Message, such as metadata generated at the receiver and information signalled by the remote endpoint. <ins> For example, a Message can be marked with a Message Property indicating that it is the final message on a connection if the peer sent a TCP FIN. </ins> Send: The action to transmit a Message over a Connection to the remote system.  The interface to Send MAY include Message
Change:
Addresses
I wondering if we should to talk a bit more about authentication in the the arch doc. The API doc has the concept of security parameters, however there is no discussion about this in the arch document. Also, just double-checking: private keys and certificates/identify can be set as a security parameter of a pre-connection. However, is that really a connection parameter or rather a local endpoint property?
To match the API, add Security Properties to Section 4.1.2.
Try to associate with the endpoint?
Add to figure 4 too
I think?

Discussion:
Properties after Connection establishment take effect on a best- effort basis. <ins> Security Parameters: Security Parameters define an application's requirements for authentication and encryption on a Connection. They are used by Transport Security protocols (such as those described in I-D.ietf-taps-transport-security) to establish secure Connections.  Examples of parameters that can be set include local identities, private keys, supported cryptographic algorithms, and requirements for validating trust of remote identities.  Security Parameters are primarily associated with a Preconnection object, but properties related to identities can be associated directly with Endpoints. </ins> 4.1.3. Initiate: The primary action that an application can take to
Change:
: added a statement about data arriving before Receive is issued; : removed the confusing sentence; : carried out replacements suggested by NAME
This issue comes from other discussion at the interim of what it means to map to DSCP classes, and proposes to fix two topics. Replace reference OLD: DSCP Less than Best Effort [LE-PHB] PHB NEW: DSCP Less than Best Effort [RFC8622] PHB — Low Latency/Interactive: The current advice is wrong. An endpoint never should be assigning EF without understanding the implication of CAC and policing. OLD: Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD assign the DSCP Expedited Forwarding [RFC3246] PHB; NEW: Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD assign a DSCP Assured Forwarding (AF41,AF42,AF43,AF44) [RFC2597] PHB. Inelastic traffic that is expected to conform to the configured network service rate could be mapped to the DSCP Expedited Forwarding [RFC3246] or [RFC5865] PHBs. —
The new text resolve this issue.
I'm not sure I understand this sentence (in sec 8. - Receiving Data): "As with sending, the type of the Message to be passed is dependent on the implementation, and on the constraints on the Protocol Stacks implied by the Connection's transport parameters." Especially, what's meant by "type of Message"?

Discussion:
an asynchronous operation, in which each call to Receive enqueues a request to receive new data from the connection.  Once data has been received, or an error is encountered, an event will be delivered to <del> complete the Receive request (see receive-events). As with sending, the type of the Message to be passed is dependent on the implementation, and on the constraints on the Protocol Stacks implied by the Connection's Transport Properties. </del> <ins> complete any pending Receive requests (see receive-events).  If Messages arrive at the transport system before Receive requests are issued, ensuing Receive requests will first operate on these Messages before awaiting any further Messages. </ins> 8.1.

or to assign the traffic to a lower-effort service.  Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling SHOULD assign the DSCP Less <del> than Best Effort LE-PHB PHB. </del> <ins> than Best Effort RFC8622 PHB. </ins> The application is interactive, and prefers loss to latency. Response time should be optimized at the expense of bandwidth

supported by the underlying transport; and so on.  Transport system implementations that map the requested capacity profile onto per-connection DSCP signaling without multiplexing SHOULD <del> assign the DSCP Expedited Forwarding RFC3246 PHB. </del> <ins> assign a DSCP Assured Forwarding (AF41,AF42,AF43,AF44) RFC2597 PHB.  Inelastic traffic that is expected to conform to the configured network service rate could be mapped to the DSCP Expedited Forwarding RFC3246 or RFC5865 PHBs. </ins> The application prefers loss to latency but is not interactive. Response time should be optimized at the expense of bandwidth
Change:
You cannot have references in the abstract. Initially I only wanted to remove that reference but then I also took the opportunity to rewrite the abstract a bit to not only talk about the architecture but an TAPS system and the interface that this guide helps with its implementation.
LGTM (I fixed a tiny nit directly with a commit)Thanks looks good.

Discussion:
Abstract <del> The Transport Services architecture I-D.ietf-taps-arch defines a system that allows applications to use transport networking protocols flexibly.  This document serves as a guide to implementation on how to build such a system. </del> <ins> The Transport Services (TAPS) system enables applications to use transport protocols flexibly for network communication and defines a protocol-independent TAPS Application Programming Interface (API) that is based on an asynchronous, event-driven interaction pattern. This document serves as a guide to implementation on how to build such a system. </ins> 1.
Change:
and spell out ICE.
I also updated a later reference and added references for STUN and TURN in this same PR now.

Discussion:
4.1.1. Both Local and Remote Endpoint Candidates must be discovered during <del> connection establishment.  To support ICE, or similar protocols, that involve out-of-band indirect signalling to exchange candidates with the Remote Endpoint, it's important to be able to query the set of candidate Local Endpoints, and give the protocol stack a set of candidate Remote Endpoints, before it attempts to establish connections. </del> <ins> connection establishment.  To support Interactive Connectivity Establishment (ICE) RFC8445, or similar protocols, that involve out- of-band indirect signalling to exchange candidates with the Remote Endpoint, it's important to be able to query the set of candidate Local Endpoints, and give the protocol stack a set of candidate Remote Endpoints, before it attempts to establish connections. </ins> 4.1.1.1.

If NAT traversal is required, the process of gathering Local Endpoints becomes broadly equivalent to the ICE candidate gathering <del> phase RFC5245.  The endpoint determines its server reflexive Local Endpoints (i.e., the translated address of a local, on the other side of a NAT) and relayed locals (e.g., via a TURN server or other relay), for each interface and network protocol.  These are added to the set of candidate Local Endpoints for this connection. </del> <ins> phase (see Section 5.1.1. of RFC8445).  The endpoint determines its server reflexive Local Endpoints (i.e., the translated address of a local, on the other side of a NAT, e.g via a STUN sever RFC5389) and relayed locals (e.g., via a TURN server RFC5766 or other relay), for each interface and network protocol.  These are added to the set of candidate Local Endpoints for this connection. </ins> Gathering Local Endpoints is primarily a local operation, although it might involve exchanges with a STUN server to derive server reflexive locals, or with a TURN server or other relay to derive relayed <del> locals.  It does not involve communication with the Remote Endpoint. </del> <ins> locals.  However, it does not involve communication with the Remote Endpoint. </ins> 4.1.1.2.
Change:
I would further recommend to move this section into 4 somewhere as this section is more about connection establishment than sending messages
LGTM

Discussion:
by setting the "Safely Replayable" send parameter to true when sending the data.  In general, 0-RTT data may be replayed (for example, if a TCP SYN contains data, and the SYN is retransmitted, <del> the data will be retransmitted as well), but racing means that different leaf nodes have the opportunity to send the same data independently.  If data is truly safely replayable, this should be permissible. </del> <ins> the data will be retransmitted as well but may be considered as a new connection instead of a retransmission).  Also, when racing connections, different leaf nodes have the opportunity to send the same data independently.  If data is truly safely replayable, this should be permissible. </ins> Once the application has provided its 0-RTT data, an implementation should keep a copy of this data and provide it to each new leaf node

distributed pre-shared keys (PSKs).  Implementations should be aware of security concerns around using these tokens across multiple addresses or paths when racing.  In the case of TLS, any given ticket <del> or PSK should only be used on one leaf node.  If implementations have multiple tickets available from a previous connection, each leaf node attempt must use a different ticket.  In effect, each leaf node will send the same early application data, yet encoded (encrypted) differently on the wire. </del> <ins> or PSK should only be used on one leaf node, since servers will likely reject duplicate tickets in order to prevent replays (see section-8.1 RFC8446).  If implementations have multiple tickets available from a previous connection, each leaf node attempt can use a different ticket.  In effect, each leaf node will send the same early application data, yet encoded (encrypted) differently on the wire. </ins> 6.
Change:
Section 10 of impl draft: "Below, primitives in the style of "CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL" (e.g., "CONNECT.SCTP") refer to the primitives with the same name in section 4 of [RFC8303]." I know it's specified like this in RFC8303 but PRIMITIVENAME does not seem to be explained or used. Maybe I didn't look careful enough but to be honest I also didn't find the use of this nomenclature from RFC8303 very helpful...
Just to answer the comment of usefulness of this nomenclature: this allows back-tracking to the relevant spec., which (I believe) is valuable for people implementing a TAPS system. In the example of CONNECT.SCTP, RFC 8303 describes this as consisting of: Interleaving' (optional), followed by 'Associate' Initialize and Associate are obvious; naturally, they come from RFC 4960. Considering to use 'Enable/Disable Interleaving' (which is very important for a TAPS system - to implement priorities between streams) is perhaps less obvious, and the text points back at RFC 8260.

Discussion:
Message lengths can be defined, and Messages can be partially reliable. <del> Below, primitives in the style of "CATEGORY.[SUBCATEGORY].PRIMITIVENAME.PROTOCOL" (e.g., "CONNECT.SCTP") refer to the primitives with the same name in section 4 of RFC8303.  For further implementation details, the description of these primitives in RFC8303 points to section 3, which refers back to the specifications for each protocol.  This back-tracking method applies to all elements of I-D.ietf-taps-minset (see appendix D of I- D.ietf-taps-interface): they are listed in appendix A of I-D.ietf- taps-minset with an implementation hint in the same style, pointing back to section 4 of RFC8303. </del> <ins> Below, terms in capitals with a dot (e.g., "CONNECT.SCTP") refer to the primitives with the same name in section 4 of RFC8303.  For further implementation details, the description of these primitives in RFC8303 points to section 3 of RFC8303 and section 3 of RFC8304, which refers back to the relevant specifications for each protocol. This back-tracking method applies to all elements of I-D.ietf-taps- minset (see appendix D of I-D.ietf-taps-interface): they are listed in appendix A of I-D.ietf-taps-minset with an implementation hint in the same style, pointing back to section 4 of RFC8303. </ins> 10.1.
Change:
Done.
Impl draft section 4.6 (Implementing listeners): "If no Local Endpoint is specified, the implementation should either use an ephemeral port or generate an error." Do we need an interface for the application to indicate that an ephemeral port should be used?
It's implicit in the old socket API - accept just gives me a new socket, which I can use to continue communication, but I don't see the port numbers associated with this socket and never have to say that they are ephermal. I believe it's similarly implicit in ours. So ... what's missing?
The text above says "use an ephemeral port or generate an error". So when would you throw an error? If the assumption is that always an ephemeral port should be used (no matter actually how the underlying interfaces works) that should be stated (in the API doc).
If you do not use an "ephemeral port", and choose to specify the port - then you may get the error if it can't be completed.
... or if the system is out of resources for some reasons. Just like "accept" can fail in the normal socket API.
That too.
NAME requested that I adapt the "error" text in the implementation draft too. In doing so, I noticed: I don't understand NAME comment above, about choosing the specify the port. I think this kind of error was possible with sockets somehow, but this text talks about not specifying a Local Endpoint. Technically, I think not specifying a Local Endpoint yet specifying a port is not possible.Regarding my own comment, any call may fail for reasons such as the system being out of resources; I think mentioning this in the text here doesn't add any value though. As a result, I'll remove the part about the error from the text in my update to PR .
This seems like what was agreed.This change is fine. You also need to adapt the implementation doc to remove the "or" part: "either use an ephemeral port or generate an error."

Discussion:
The Local Endpoint MUST be specified if the Preconnection is used to Listen() for incoming Connections, but is OPTIONAL if it is used to <del> Initiate() connections.  The Remote Endpoint MUST be specified if the </del> <ins> Initiate() connections.  If no Local Endpoint is specified, the Transport System will assign an ephemeral local port to the Connection.  The Remote Endpoint MUST be specified if the </ins> Preconnection is used to Initiate() Connections, but is OPTIONAL if it is used to Listen() for incoming Connections.  The Local Endpoint and the Remote Endpoint MUST both be specified if a peer-to-peer

When an implementation is asked to Listen, it registers with the system to wait for incoming traffic to the Local Endpoint.  If no <del> Local Endpoint is specified, the implementation should either use an ephemeral port or generate an error. </del> <ins> Local Endpoint is specified, the implementation should use an ephemeral port. </ins> If the Selection Properties do not require a single network interface or path, but allow the use of multiple paths, the Listener object
Change:
I chose boolean, because, when querying, it only matters whether a Selection Property was chosen or not (I believe).
From Kyle Rose: NAME says: I think this isn't very controversial, I believe we should just do this as he suggested. This issue is just a reminder for myself to do this.
Thanks

Discussion:
Preference: can take one of five values (Prohibit, Avoid, Ignore, Prefer, Require) for the level of preference of a given property <del> during protocol selection; see selection-props. </del> <ins> during protocol selection; see selection-props.  When querying, a Preference is of type Boolean, with "true" indicating that the Selection Property has been applied. </ins> For types Integer and Numeric, special values can be defined per property; it is up to implementations how these special values are

Selection Properties are listed in the subsections below.  Note that many properties are only considered during establishment, and can not be changed after a Connection is established; however, they can be <del> queried.  Querying a Selection Property after establishment yields the value "Require" for properties of the selected protocol and path, Avoid for properties avoided during selection, and Ignore for all other properties. </del> <ins> queried.  The return type of a queried Selection Property is Boolean, where "true" means that the Selection Property has been applied and "false" means that the Selection Property has not been applied.  Note that "true" does not mean that a request has been honored.  For example, if "Congestion control" was requested with preference level "Prefer", but congestion control could not be supported, querying the "congestionControl" property yields the value "false".  If preference level "Avoid" was used for "Congestion control", and, as requested, the Connection is not congestion controlled, querying the "congestionControl" property also yields the value "false". </ins> An implementation of this interface must provide sensible defaults for Selection Properties.  The defaults given for each property below
Change:
I inserted the text that I quoted in this issue, with a minor tweak.
List discussion: Kyle: NAME
I agree with the conclusion of NAME above - in which case we should leave things as they are. Other views?
I agree that if the application does nothing then communication should be reliable. But I understand Kyle's comment as asking about the relationship to the selection property Reliable Data Transfer (Connection). If you for example set that to Avoid and the TAPS system selects SCTP as the protocol, then if you do not set Reliable Data Transfer (Message) on a message I assume it will be sent as an unreliable message. So in that sense the reliability of a message defaults to whatever is set for the connection, unless it is overridden by setting Reliable Data Transfer (Message). And the default for Reliable Data Transfer (Connection) is Require so what NAME writes still holds but it is a different thing.
So if we agree upon Reliable Data Transfer (Connection), then it would seem less confusing for Reliable Data Transfer (Message) - to use the same logic. Does an apps writer need to know the data will be sent as an unreliable message? (I'm not sure I like "avoid reliable data transfer" as a meaningful concatenation of keywords BTW:-).
Let's see what needs to be done. Suggestion: the only textual change would be to add the following, at the beginning of Section 7.5, just before "The following Message Properties are supported": "Connection Properties describe the default behavior for all Messages on a Connection. If a Message Property contradicts a Connection Property, it overrides the Connection Property for the specific Message. For example, if "Reliable Data Transfer (Connection)" is set to "Avoid" and a protocol with configurable per-Message reliability is used, setting "Reliable Data Transfer (Message)" to "Prefer" for a particular Message will ensure that this Message is reliably delivered. If the underlying protocol can not support this per-Message behavior, this Message Property choice will yield an error."
Thanks! No more comments now :)

Discussion:
Sending a Message with Message Properties inconsistent with the Selection Properties of the Connection yields an error. <ins> Connection Properties describe the default behavior for all Messages on a Connection.  If a Message Property contradicts a Connection Property, and if this per-Message behavior can be supported, it overrides the Connection Property for the specific Message.  For example, if "Reliable Data Transfer (Connection)" is set to "Require" and a protocol with configurable per-Message reliability is used, setting "Reliable Data Transfer (Message)" to "false" for a particular Message will allow this Message to be unreliably delivered.  Note that changing the Reliable Data Transfer property on Messages is only possible for Connections that were established with the Selection Property "Configure Per-Message Reliability" enabled. </ins> The following Message Properties are supported: 7.5.1.
Change:
Address
I think the word /assumes/ is not a good choice of word in the arch draft. OLD: and it assumes an implementation that can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams NEW: and it can provide benefit when an implementation can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams.
Done
Exactly what I expected to see!

Discussion:
Transport Services architecture.  The Transport Services Application Programming Interface (API) is based on an asynchronous, event-driven interaction pattern.  It uses messages for representing data transfer <del> to applications, and it assumes an implementation that can use </del> <ins> to applications, and it describes how implementations can use </ins> multiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams.  This document further defines common terminology and concepts to be used in definitions of

There are key differences between the architecture of the Transport Services system and the architecture of the Socket API: the Transport Services API is asynchronous and event-driven; it uses messages for <del> representing data transfer to applications; and it assumes an implementation that can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams. </del> <ins> representing data transfer to applications; and it describes how implementations can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams. </ins> 2.1.