jiebi/CodeConvo huggingface dataset:
Change:
This is mostly typos and rewording, plus converting some diagrams so that aasvg can do a better job.
Thank you for improvements. I will merge them now and then place some fixups.

Discussion:
The following list provides an abstract description of the flow depicted in enrollfigure. <del> CA Certs Request: The pledge optionally requests the latest </del> <ins> CA Certs Request [1]: The pledge optionally requests the latest </ins> relevant CA certificates.  This ensures that the pledge has the complete set of current CA certificates beyond the pinned-domain- cert (which is contained in the voucher and may be just the domain registrar certificate). <del> CA Certs Response: It MUST contain the current root CA </del> <ins> CA Certs Response [2]: It MUST contain the current root CA </ins> certificate, which typically is the LDevID trust anchor, and any additional certificates that the pledge may need to validate certificates. <del> Attribute Request: Typically, the automated bootstrapping occurs without local administrative configuration of the pledge. </del> <ins> Attribute Request [3]: Typically, the automated bootstrapping occurs without local administrative configuration of the pledge. </ins> Nevertheless, there are cases in which the pledge may also include additional attributes specific to the target domain into the certification request.  To get these attributes in advance, the attribute request can be used. <del> Attribute Response: It MUST contain the attributes to be included in the subsequent certification request. </del> <ins> Attribute Response [4]: It MUST contain the attributes to be included in the subsequent certification request. </ins> <del> Certificate Request: This certification request MUST contain the authenticated self-contained object ensuring both proof-of- </del> <ins> Certificate Request [5]: This certification request MUST contain the authenticated self-contained object ensuring both proof-of- </ins> possession of the corresponding private key and proof-of-identity of the requester. <del> Certificate Response: The certification response message MUST </del> <ins> Certificate Response [6]: The certification response message MUST </ins> contain on success the requested certificate and MAY include further information, like certificates of intermediate CAs. <del> Certificate Confirm: An optional confirmation sent after the </del> <ins> Certificate Confirm [7]: An optional confirmation sent after the </ins> requested certificate has been received and validated.  It contains a positive or negative confirmation by the pledge whether the certificate was successfully enrolled and fits its needs. <del> PKI/Registrar Confirm: An acknowledgment by the PKI or registrar that MUST be sent on reception of the Cert Confirm. </del> <ins> PKI/Registrar Confirm [8]: An acknowledgment by the PKI or registrar that MUST be sent on reception of the Cert Confirm. </ins> The generic messages described above may be implemented using various enrollment protocols supporting authenticated self-contained objects,
Change:
Preconnections are mutable, until they are not. The second paragraph of section 2 states "bundles of properties an application can both read and write", which seems to conflict with this. Para should lead with the fact of mutable mutability over the preconnection lifecycle, not "is mutable".
The Connection/Listener makes a deep copy that is now immutable, but the original object is still mutable.

Discussion:
Once a Preconnection has been used to create an outbound Connection or a Listener, the implementation should ensure that the copy of the <del> properties held by the Connection or Listener is not affected when the application makes changes to a Preconnection object.  This may involve the implementation performing a deep-copy, copying the object with all the objects that it references. </del> <ins> properties held by the Connection or Listener cannot be mutated by the application making changes to the original Preconnection object. This may involve the implementation performing a deep-copy, copying the object with all the objects that it references. </ins> Once the Connection is established, Transport Services implementation maps actions and events to the details of the chosen Protocol Stack.
Change:
In the impl draft, I'm supposed to build a tree based on, in order (1) "path": AFAICT this means "interface". The -api draft provides in interface preference framework in 4.2.11. (BTW if it really means interface maybe we should say 'interface'). (2) Protocol: almost all of 4.2 in -api explains how to express this. (with an assist in -impl 4.1.3 explaining how to handle PREFER vs. AVOID) (3) "derived endpoint" I gather this is basically multiple addresses coming back from remote endpoint resolution. But where is the construct in -api that allows applications to express a preference here?
I'm not sure we want to add anything to the API here. There are existing preferences that can bias towards IPv6, such as preferring or requiring . I think we can just detail that in the implementation draft.
Thanks, LGTM!

Discussion:
hostnames.  Each of these hostnames might resolve to one or more addresses, which would create multiple layers of branching. <ins> Applications can influence which derived endpoints are allowed and preferred via Selection Properties set on the Preconnection.  For example, setting a preference for "useTemporaryLocalAddress" would prefer the use of IPv6 over IPv4, and requiring "useTemporaryLocalAddress" would eliminate IPv4 options, since IPv4 does not support temporary addresses. </ins> 4.1.1.2. If a client has multiple network paths available to it, e.g., a
Change:
in architecture.
Per slide 14 in Thorben Krüger's presentation at IETF 113: URL, clarify that the API is defined in terms of events to be general, not because you have to implement an event system if you're going to implement TAPS.
LGTM

Discussion:
they are equivalent to Actions on a per-application global context. Events are sent to the application or application-supplied code (e.g. <del> framers, see framing) for processing; the details of event processing are platform- and implementation-specific. </del> <ins> framers, see framing) for processing; the details of event interfaces are platform- and implementation-specific, and may be implemented using other forms of asynchronous processing, as idiomatic for the implementing platform. </ins> We also make use of the following basic types:

an asynchronous interface using the Socket API generally uses a try- and-fail model.  If the application wants to read, but data has not yet been received from the peer, the call to read will fail.  The <del> application then waits and can try again later.  In contrast to the Socket API, all interaction using the Transport Services API is expected to be asynchronous and use an event-driven model (see events).  For example, an application first issues a call to receive new data from the connection.  When delivered data becomes available, this data is delivered to the application using asynchronous events that contain the data.  Error handling is also asynchronous; a failure to send data results in an asynchronous error event. </del> <ins> application then waits and can try again later. In contrast to the Socket API, all interaction using the Transport Services API is expected to be asynchronous.  The API is defined around an event-driven model (see events) in order to model this asynchronous interaction, though other forms of asynchronous communication may be available to applications depending on the platform implementing the interface. For example, an application first issues a call to receive new data from the connection.  When delivered data becomes available, this data is delivered to the application using asynchronous events that contain the data.  Error handling is also asynchronous; a failure to send data results in an asynchronous error event. </ins> This API also delivers events regarding the lifetime of a connection and changes in the available network links, which were not previously
Change:
This pull requests fixes two minor typos in draft-ietf-taps-URL that I noticed during detailed reading of the draft.

Discussion:
the ability to associate deadlines with messages, for applications that care about timing; <del> the ability control reliability, which messages to retransmit when there is packet loss, and how best to make use of the data that arrived; </del> <ins> the ability to control reliability, which messages to retransmit when there is packet loss, and how best to make use of the data that arrived; </ins> the ability to automatically assign messages and connections to underlying transport connections to utilize multi-streaming and

and System-implementation concepts, which are intended to be <del> internally used by aTransport Services implementation. </del> <ins> internally used by a Transport Services implementation. </ins> The following diagram summarizes the top-level concepts in the architecture and how they relate to one another.
Change:
Raising this issue as part of my review of the the Implementation Draft. Quoting from Section 4.1 "Structuring Candidates as a Tree" ~ Feedback: While it is understood that "connection attempt" is here used to refer to a given node in the tree, rather than the actual (stateful) process of attempting to connect to the given endpoint (using the given parameters), it does not make for easy reading. Similarly, it is possible to grasp how an "aggregate set" can be "viewed" as "a single connection establishment", but the language could be clearer here as well. Couldn't an "attempt" that has succeeded and is "ready to use" be referred to differently? Couldn't "candidate" or "option" be substituted for "attempt" to improve readability? Proposal:
Seems quite close to me
Yes, I like this proposed text.

Discussion:
endpoint, path (labeled here by interface), and protocol.  The above example can now be written more succinctly as: <del> When an implementation views this aggregate set of connection attempts as a single connection establishment, it only will use one of the leaf nodes to transfer data.  Thus, when a single leaf node becomes ready to use, then the entire connection attempt is ready to use by the application.  Another way to represent this is that every leaf node updates the state of its parent node when it becomes ready, until the trunk node of the tree is ready, which then notifies the application that the connection as a whole is ready to use. </del> <ins> When an implementation is asked to establish a single connection, only one of the leaf nodes in the candidate set is needed to transfer data.  Thus, once a single leaf node becomes ready to use, then the connection establishment tree is considered ready.  One way to implement this is by having every leaf node update the state of its parent node when it becomes ready, until the trunk node of the tree is ready, which then notifies the application that the connection as a whole is ready to use. </ins> A connection establishment tree may be degenerate, and only have a single leaf node, such as a connection attempt to an IP address over
Change:
The guidance applies to any connectionless transport.
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
LGTM

Discussion:
convenience functions to simplify use of Selection Properties: see preference-conv for examples.  In addition, implementations MAY provide a mechanism to create TransportProperties objects that are <del> preconfigured for common use cases as outlined in property-profiles. </del> <ins> preconfigured for common use cases, as outlined in property-profiles. </ins> Transport Properties for an established connection can be queried via the Connection object, as outlined in introspection.

Local Endpoint sends a keep-alive packet to the Remote Endpoint. Adjusting this Property will only take effect when the underlying stack supports sending keep-alive packets.  Guidance on setting this <del> value for datagram transports is provided in RFC8085.  A value </del> <ins> value for connection-less transports is provided in RFC8085.  A value </ins> greater than the connection timeout (conn-timeout) or the enumerated value "Disabled" will disable the sending of keep-alive packets.

characteristics and habits of the user of an application. Of course any communication over a network reveals usage <del> characteristics, as all packets, as well as their timing and size, are part of the network-visible wire image RFC8546.  However, the selection of a protocol and its configuration also impacts which </del> <ins> characteristics, because all packets, as well as their timing and size, are part of the network-visible wire image RFC8546.  However, the selection of a protocol and its configuration also impacts which </ins> information is visible, potentially in clear text, and which other entities can access it.  In most cases, information provided for protocol and path selection should not directly translate to
Change:
This seems otherwise inconsistent: for the noFragmentation property, we say that, in case of IPv4, setting this will result in setting the "Don't Fragment" bit. the noSegmentation property is described as avoiding fragmentation AND avoiding segmentation. So logically, this should also result in setting the "Don't Fragment" bit in case of IPv4. Generally, I'm not sure how an implementer should interpret the "can" here, in contrast with the "will" in the "Don't Fragment" case above... the textual difference seems to hint that this could be implemented differently, but then, how?

Discussion:
This only takes effect when the transport uses a network layer that supports this functionality.  When it does take effect, setting this property to true will cause the sender to avoid network-layer source <del> frgementation.  When using IPv4, this will result in the Don't </del> <ins> fragmentation.  When using IPv4, this will result in the Don't </ins> Fragment bit being set in the IP header. Attempts to send a message with this property that result in a size

provide segmentation of messages larger than the maximum size permitted by the network layer, and also to avoid network-layer source fragmentation of messages.  When running over IPv4, setting <del> this property to true can result in a sending endpount setting the </del> <ins> this property to true will result in a sending endpount setting the </ins> Don't Fragment bit in the IPv4 header of packets generated by the <del> transport layer.  An attempt to send a message that results in a size greater than the transport's current estimate of its maximum packet size (singularTransmissionMsgMaxLen) will result in a SendError. This only takes effect when the transport and network layer support this functionality. </del> <ins> transport layer. An attempt to send a message that results in a size greater than the transport's current estimate of its maximum packet size ("singularTransmissionMsgMaxLen") will result in a "SendError".  This only takes effect when the transport and network layer support this functionality. </ins> 9.2.
Change:
There are still a few s and similar scattered throughout the document. Find them and fix them, or move them to post-London issues.

Discussion:
4. <del> [EDITOR'S NOTE: write three paragraph summary here; see https://github.com/taps-api/drafts/issues/93] </del> <ins> The Transport Services Interface is the basic common abstract application programming interface to the Transport Services Architecture defined in TAPS-ARCH.  An application primarily interacts with this interface through two objects, Preconnections and Connections.  A Preconnection represents a set of parameters and constraints on the selection and configuration of paths and protocols to establish a connection with a remote endpoint.  A Connection represents a transport protocol stack on which data can be sent to and received from a remote endpoint.  Connections can be created from Preconnections in three ways: by initiating the Preconnection (i.e., actively opening, as in a client), through listening on the Preconnection (i.e., passively opening, as in a server), or rendezvousing on the Preconnection (i.e. peer to peer establishment). Once a Connection is established, data can be sent on it in the form of Messages.  The interface supports the preservation of message boundaries both via explicit protocol stack support, and via application support through a deframing callback which finds message boundaries in a stream.  Messages are received asynchronously through a callback registered by the application.  Error and other notifications also happen asynchronously on the Connection. </ins> In the following sections, we describe the details of application interaction with Objects through Actions and Events in each phase of <del> a connection, following the phases described in TAPS-ARCH. </del> <ins> a connection, following the phases described in TAPS-ARCH.  An example interface sketch in Go is shown in appendix-api-sketch. </ins> 5.

Endpoint or a Remote Endpoint in cases where this is required, for example with some NAT traversal protocols (see rendezvous). <del> [NOTE: the API needs MUST be explicit about when name resolution occurs, since the act of resolving a name leaks information, and there may be security implications if this happens unexpectedly.] </del> 5.2. A Preconnection object holds parameters reflecting the application's

connections.  This list can be passed to a peer via a signalling protocol, such as SIP or WebRTC, to configure the remote. <del> [NOTE: This API is sufficient for TCP-style simultaneous open, but should be considered experimental for ICE-like protocols.] </del> 6.4. Groups of Connections can be created using Clone action:
Change:
First cut at new text
UDP, ConnectionError: Would those soft errors contain additional information about the ICMP error code, and can an application expect to find the (partial) original datagram in the error?
This is a good question! - on the one hand, the additional info can be valuable - for example to validate an ICMP message, as suggested for validating ICMP for a DPLPMTUD probe - but on the other hand, this info is often not provided by existing APIs.
I figure that a practical thing to state would be that the information is provided if it is accessible on a platform. Having text that describes this as matter of implementation quality would help TAPS implementers push for (eg. MSG_ERRQUEUE style) provisions in their platforms.
If the system makes this information available, we could mention that you could pass it up.
See a proposal in
The pointer to the PR with the specific proposal to address this issue got a "thumbs up" from the NAME who wrote the review. So, this PR should have closed this issue. Doing it manually.

Discussion:
Once in use, UDP throws "soft errors" (ERROR.UDP(-Lite)) upon receiving ICMP notifications indicating failures in the network. <ins> Additional information can also be provided when this is available to the system (e.g.  ICMP error code and quoted packet header). </ins> LISTEN.UDP.  Calling "Listen" for UDP binds a local port and prepares it to receive inbound UDP datagrams from peers.
Change:
Framers: The paragraphs in Defining Message Framers and later might be formal language or pseudocode, I can't tell. It might help if the introduction stated something around names and signatures of signals and functions being expressed in pseudocode, and that identifiers in implementations are expected to be similar to those but following the conventions of the language
We should reference section 1.1 of the API document which defines the notation used.

Discussion:
the main Connection implementation that delivers events to the custom framer implementation whenever data is ready to be parsed or framed. <ins> The API examples in this section use the notation conventions for the Transport Services API defined in Section 1.1 of I-D.ietf-taps- interface. </ins> The Transport Services implementation needs to ensure that all of the events and actions taken on a Message Framer are synchronized to ensure consistent behavior.  For example, some of the actions defined
Change:
(More out of curiosity, with no expectation that this would find its way into the text unless you think I've hit a bug): In UDP Multicast Receive, which kind of ICMP notifications can come in there that would constitute a ConnectionError -- given that this transport does not send (and would thus usually not trigger any)?
Section 10.4 for multicast receive mentions ICMP errors. You could have errors on initiate for joining a multicast group, etc, but it likely doesn't make sense to have ICMP errors mentioned here.
Suggest we can close this issue.
LGTMSeems like we do not loose anything by removing this. The change WFM.

Discussion:
Calling "AbortGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all <del> Connections in the same ConnectionGroup.  ## UDP-Lite </del> <ins> Connections in the same ConnectionGroup. 10.4. </ins> Connectedness: Connectionless

UDP-Lite, such as "msgChecksumLen", "fullChecksumSend", "recvChecksumLen", and "fullChecksumRecv". <del> 10.4. </del> <ins> 10.5. </ins> Connectedness: Connectionless

A UDP Multicast Receive Connection is ready once the system has received traffic for the appropriate group and port. <del> UDP Multicast Receive Connections generate an InitiateError if Initiate is called. Once in use, UDP throws "soft errors" (ERROR.UDP(-Lite)) upon receiving ICMP notifications indicating failures in the network. </del> <ins> UDP Multicast Receive Connections generate an InitiateError indicating that joining a multicast group failed if Initiate is called. </ins> LISTEN.UDP.  Calling "Listen" for UDP Multicast Receive binds a local port, prepares it to receive inbound UDP datagrams from

(ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all Connections in the same ConnectionGroup. <del> 10.5. </del> <ins> 10.6. </ins> Connectedness: Connected
Change:
"In effect, each leaf node will send the same early application data, yet encoded (encrypted) differently on the wire.": There has been a warning on the privacy implications of using the same token on different paths; doesn't sending an identical 0-RTT message racingly on multiple transports cause similar correlation issues?
This may be better to put in the privacy and security considerations section of the API document, particularly that doing cleartext 0-RTT data that races can be recognized on the path (as opposed to being in TLS which fixes this).
Similarly, connection racing overall can let a server observe that a client has multiple addresses and what they are, etc.
LGTM; note that I left a tiny comment.

Discussion:
resolution, when support mechanisms such as TURN or ICE are used to establish connectivity, if protocols or paths are raised, or if a path fails and fallback or re-establishment is supported in the <del> Transport Services system. </del> <ins> Transport Services system.  Applications should take special care when using 0-RTT session resumption (see prop-0rtt), as early data sent across multiple paths during connection establishment may reveal information that can be used to correlate endpoints on these paths. </ins> Applications should also take care to not assume that all data received using the Transport Services API is always complete or well-