jiebi/CodeConvo huggingface dataset:
Change:
Adding this issue from Fernando via the TAPS list: The terminology employed in this subsection seems a bit confusing, or at least deviates from what we normally use in v6-circles. I suggest taking a look at RFC7721 -- certainly not flawless, but it was 6man's shot to try to agree on terminology. For example, I don't think we use "permanent" and "stable" interchangeably. e.g. the "Local" in "useTemporaryLocalAddress" might be misleading to some. -- e.g. could be interpreted as related with link-locals or ULAs. Aside, I believe there's much more to dig regarding address properties. e.g., we have given it a shot at: URL e.g., the choice of ipv6 addresses has more than one dimension... and there are tradeoffs involved, which IMHO deserve discussion. And aside from the regular address systems normally configure, if one were to specify an API one would probably want to provide a mechanism for apps to be able to request sole/single-use addresses (.e.g., one address per app or container).
"Local" has a meaning in the TAPS context, I don't think we need to change it for universalization with the full set of IPv6 terminology. There's also not much point in going all the way down the rabbithole for this particular property, given that we don't do so for any other -- this document is meant as a universal interface to networking for the future, not an unbounded treatise on the future of networking. That said, the linked draft does seem to address the issues here and it's fairly alive, so no harm in adding an informative reference to it.
I agree with the comments of NAME and NAME

Discussion:
use of temporary addresses, the resulting Connection cannot use IPv4, because temporary addresses do not exist in IPv4.  Second, temporary local addresses might involve trading off privacy for performance. <del> For instance, temporary addresses can interfere with resumption mechanisms that some protocols rely on to reduce initial latency. </del> <ins> For instance, temporary addresses (e.g., RFC8981) can interfere with resumption mechanisms that some protocols rely on to reduce initial latency. </ins> 6.2.14.
Change:
Clarified one use of word "API" comes just after discussion of the socket API. Tried to fix specialised features to say they define additional requirements. Minor changes to wording, with no intended changes to substance.
LGTM but I made one very small comment

Discussion:
system objects that may be temporarily unavailable. Separate from events, callbacks are also provided for asynchronous <del> interactions with the Transport Services API, which are not directly </del> <ins> interactions with the Transport Services API that are not directly </ins> related to events on the network or network interfaces. 2.2.
Change:
Review the use of and markdown in the API document, and make it consistent.
A fantastic PR! The best ever!

Discussion:
Preference)".  Instances take a sequence of values each valid for the corresponding value type. <del> Array: Denoted []Type, an instance takes a value for each of zero or more elements in a sequence of the given Type.  An array may be of fixed or variable length. </del> <ins> Array: Denoted "[]Type", an instance takes a value for each of zero or more elements in a sequence of the given Type.  An array may be of fixed or variable length. </ins> Collection: An unordered grouping of one or more values of the same type.

The following API calls can be used to configure a Preconnection before calling Initiate(): <del> "RemoteSpecifier.WithMulticastGroupIPv4(GroupAddress) RemoteSpecifier.WithMulticastGroupIPv6(GroupAddress) RemoteSpecifier.WithPort(PortNumber) RemoteSpecifier.WithTTL(TTL) " </del> Calling Listen() on a Preconnection with a multicast group specified on the Remote Endpoint will join the multicast group to receive messages.  This Listener will create one Connection for each Remote

MessagContext on the messages received (see msg-ctx for further details). <del> "LocalSpecifier.WithSingleSourceMulticastGroupIPv4(GroupAddress, SourceAddress) LocalSpecifier.WithSingleSourceMulticastGroupIPv6(GroupAddress, SourceAddress) LocalSpecifier.WithAnySourceMulticastGroupIPv4(GroupAddress) LocalSpecifier.WithAnySourceMulticastGroupIPv6(GroupAddress) LocalSpecifier.WithPort(PortNumber) LocalSpecifier.WithTTL(TTL) " </del> Calling Rendezvous() on a Preconnection with an any-source multicast group address as the Remote Endpoint will join the multicast group, and also indicates that the resulting connection can be used to send

Rendezvous() on a Preconnection with a source-specific multicast group address as the Local Endpoint results in an EstablishmentError. <del> "RemoteSpecifier.WithMulticastGroupIPv4(GroupAddress) RemoteSpecifier.WithMulticastGroupIPv6(GroupAddress) RemoteSpecifier.WithPort(PortNumber) RemoteSpecifier.WithTTL(TTL) LocalSpecifier.WithAnySourceMulticastGroupIPv4(GroupAddress) LocalSpecifier.WithAnySourceMulticastGroupIPv6(GroupAddress) LocalSpecifier.WithPort(PortNumber) LocalSpecifier.WithTTL(TTL) " </del> See multicast-examples for more examples. 6.1.2.

address other than the one initially used, it is necessary to set the "advertisesAltaddr" property (see altaddr below). <del> Setting this property to "Active", can have privacy implications: It </del> <ins> Setting this property to "Active" can have privacy implications: It </ins> enables the transport to establish connectivity using alternate paths that might result in users being linkable across the multiple paths, even if the "advertisesAltaddr" property (see altaddr below) is set
Change:
Fix-up multicast
Fixing the sequence of some examples vs. the text describing them, and referring to examples ("The following API calls can be used ...")
Also a great PR! :) Seriously, thanks!

Discussion:
MessagContext on the messages received (see msg-ctx for further details). <ins> The following API calls can be used to configure a Preconnection before calling Listen(): </ins> Calling Rendezvous() on a Preconnection with an any-source multicast group address as the Remote Endpoint will join the multicast group, and also indicates that the resulting connection can be used to send

Rendezvous() on a Preconnection with a source-specific multicast group address as the Local Endpoint results in an EstablishmentError. <ins> The following API calls can be used to configure a Preconnection before calling Rendezvous(): </ins> See multicast-examples for more examples. 6.1.2.
Change:
URL The use of Cap 'C' in the first sentence for connection is confusing. The Connection object is created after the incoming connections are accepted. The Cap C makes it assume that it not that case and create an expectation that the remote is also a TAPS implementation.

Discussion:
process of identifying options for connecting, such as resolution of the Remote Endpoint, occurs in response to the Initiate call. <del> Listen: Enables a listener to accept incoming Connections.  The </del> <ins> Listen: Enables a listener to accept incoming connections.  The </ins> Listener will then create Connection objects as incoming connections are accepted (events).  Listeners by default register with multiple paths, protocols, and Local Endpoints, unless
Change:
URL If an application wishes to use a special feature then if might need to adjust itself if that special feature is not applicable to the Connection Object it gets/ gets created for. Should there be no requirement(at least recommendation) on getting this information back? The application can ask a specialized feature in a way that it gets what it wants or the communication MUST fail. In such case the should be a requirement on the application to be specific about it or?
The API solves this in two ways: We have a preference-type that allows the application to explicitly state that it requires/prefers/does-not-care/wants-to-avoid/prohibits each feature. After the establishment, the application can query each feature and gets a boolean back whether it is present or not. Should we add this as a forward reference here or at least hint at the solution?
Hint at the solution sounds like a very good approach to me.

Discussion:
set of allowable protocol features without changing the core implementation. <ins> To control these specialized features, the application can declare its preference - whether the presence of a specific feature is prohibited, should be avoided, can be ignored, is preferred, or is required in the Pre-Establishment phase.  An implementation of a Transport Services API would honor this preference and allow the application to query the availability of each specialized feature after a successful establishment. </ins> 3.3. A Transport Services implementation can select Protocol Stacks based
Change:
URL Here it seems we are defining "equivalent" twice. I would rather write - >Equivalent Protocol Stacks are defined as stacks that can provide the same Transport Properties and interface expectations as requested by the application. and the equivalent stacks can be swapped or raced. Also in the example - it is not clear that swapping and racing in important, however, application provided properties are. Apart from this I also think the title and content is mismatching. I found the last paragraph talking about swapping and racing focusing on security. Here we are imposing requirements on swapping and racing. These are very important for the security consideration and to me should get its own title and section separated from selection of equivalence.
LGTM!Looks good

Discussion:
3.3. <del> A Transport Services implementation can select Protocol Stacks based on the Selection and Connection Properties communicated by the application, along with any security parameters.  If two different Protocol Stacks can be safely swapped, or raced in parallel (see racing), then they are considered to be "equivalent".  Equivalent Protocol Stacks are defined as stacks that can provide the same Transport Properties and interface expectations as requested by the application. </del> <ins> A Transport Services implementation can attempt and select between multiple Protocol Stacks based on the Selection and Connection Properties communicated by the application, along with any security parameters.  The implementation can only attempt to use multiple Protocol Stacks when they are "equivalent", which means that the stacks can provide the same Transport Properties and interface expectations as requested by the application.  Equivalent Protocol Stacks can be safely swapped or raced in parallel (see racing) during connection establishment. </ins> The following two examples show non-equivalent Protocol Stacks:
Change:
URL I think we should add a similar ranking consideration description as we have for Network paths. Otherwise, I am not sure how to rank the protocol option.
I think here as well that the options should be ranked based on preference, system policy, and performance. I made a pull request to add it.
LGTM, lets of others have any opinion about it..
I agree with NAME
WFM

Discussion:
This approach is commonly used for connections with optional proxy server configurations.  A single connection might have several options available: an HTTP-based proxy, a SOCKS-based proxy, or no <del> proxy.  These options should be ranked and attempted in succession. </del> <ins> proxy.  As above, these options should be ranked based on preference, system policy, and performance and attempted in succession. </ins> This approach also allows a client to attempt different sets of application and transport protocols that, when available, could
Change:
I'm happy to do this! But while we're at it, isn't the "a" a bit awkward? Wouldn't this read even better as: "An Endpoint MUST NOT be configured with multiple identifiers of the same type." I just pushed that suggestion.
URL This seems to me as a strong claim without using normative language. Shall we use normative language here?
Agree, although then I think we need to explain "set" so that we create an RFC2119 sentence with meaning when read on its own. Is this anywhere near: An Endpoint MUST NOT set multiple identifiers of the same type. And... is the /that is/ correct? or is this an example of something that is not allowed?
I'd say it's an example, although also the most likely such case. Suggest: replace "That is," with "Thus,"
If this is just an example then lets just be explicit about it.
I like the change. Is the English clunky, could it be: An Endpoint MUST NOT be configured with multiple identifiers of a same type.

Discussion:
"WithIPv6Address" with an unscoped address and "WithInterface " together. <del> An Endpoint cannot have multiple identifiers of a same type set. That is, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a Preconnection specifies a Remote Endpoint with a specific IP address set, it will only establish Connections to that IP address.  If, on the other hand, the Remote Endpoint specifies a hostname but no addresses, the Connection can perform name resolution and attempt using any address derived from the original hostname of the Remote Endpoint.  Note that multiple Remote Endpoints can be added to a Preconnection, as discussed in add-endpoints. </del> <ins> An Endpoint MUST NOT be configured with multiple identifiers of the same type.  For example, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a Preconnection specifies a Remote Endpoint with a specific IP address set, it will only establish Connections to that IP address.  If, on the other hand, the Remote Endpoint specifies a hostname but no addresses, the Connection can perform name resolution and attempt using any address derived from the original hostname of the Remote Endpoint.  Note that multiple Remote Endpoints can be added to a Preconnection, as discussed in add-endpoints. </ins> The Transport Services system resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a
Change:
/transport/ should be /connection state/
This resolves one small part of Zahed's review.
These comments are good to be addressed to improve the document, however, they can be done as part of IETF last call as well
Fixes proposed in PRs , , , ,
LGTM

Discussion:
updating maintenance options. Termination (termination) focuses on the methods by which data <del> transmission is stopped, and state is torn down in the transport. </del> <ins> transmission is stopped, and connection state is torn down. </ins> The diagram below provides a high-level view of the actions and events during the lifetime of a Connection object.  Note that some
Change:
Review comment: Section 4.1.2 : I would describe the object first and then the transport properties. In the current arrangement when properties are described it mentions Connection which is described just later. Also transport properties here are kind of repetition of what we have in Section 3.1. reordered descriptions, which also to me at least, seems to make the text on properties better relate to the action
These comments are good to be addressed to improve the document, however, they can be done as part of IETF last call as well
Fixes proposed in PRs , , , ,
LGTM

Discussion:
4.1.2. <ins> Connection: A Connection object represents one or more active transport protocol instances that can send and/or receive Messages between Local and Remote Endpoints.  It is an abstraction that represents the communication.  The Connection object holds state pertaining to the underlying transport protocol instances and any ongoing data transfers.  For example, an active Connection can represent a connection-oriented protocol such as TCP, or can represent a fully-specified 5-tuple for a connectionless protocol such as UDP, where the Connection remains an abstraction at the endpoints.  It can also represent a pool of transport protocol instances, e.g., a set of TCP and QUIC connections to equivalent endpoints, or a stream of a multi-streaming transport protocol instance.  Connections can be created from a Preconnection or by a Listener. </ins> Preconnection: A Preconnection object is a representation of a Connection that has not yet been established.  It has state that describes parameters of the Connection: the Local Endpoint from

can also be specified during data transfer to affect specific Messages. <del> Connection: A Connection object represents one or more active transport protocol instances that can send and/or receive Messages between Local and Remote Endpoints.  It is an abstraction that represents the communication.  The Connection object holds state pertaining to the underlying transport protocol instances and any ongoing data transfers.  For example, an active Connection can represent a connection-oriented protocol such as TCP, or can represent a fully-specified 5-tuple for a connectionless protocol such as UDP, where the Connection remains an abstraction at the endpoints.  It can also represent a pool of transport protocol instances, e.g., a set of TCP and QUIC connections to equivalent endpoints, or a stream of a multi-streaming transport protocol instance.  Connections can be created from a Preconnection or by a Listener. </del> Listener: A Listener object accepts incoming transport protocol connections from Remote Endpoints and generates corresponding Connection objects.  It is created from a Preconnection object
Change:
These comments are good to be addressed to improve the document, however, they can be done as part of IETF last call as well
Fixes proposed in PRs , , , ,
LGTM

Discussion:
the Remote Endpoint if the transport protocol allows this.  (Note that this is distinct from the concept of "half-closing" a bidirectional connection, such as when a FIN is sent in one <del> direction of a TCP connection ?RFC9293.  The end of a stream can </del> <ins> direction of a TCP connection RFC9293.  The end of a stream can </ins> also be indicated using Message Properties when sending.) Abort: The action the application takes on a Connection to
Change:
Don't just rely on the cache .
URL I think we should be very specific that the application SHOULD not expect certain caching behavior or MAY expect a minimum set of information cached. This is also related to the expectancy from application to expect same protocol given same properties and security parameter each time. will such input generate same consistent out put from one TAPS system?
I suggest adding this explicitly - something like: This caching does not imply that the same decisions are necessarily made for subsequent connections, rather, it means that cached state is used by the Transport Services architecture to inform functions such as choosing the candidates to be raced, selecting appropriate transport parameters, etc.
See PR on request required properties , which could close this issue.
Thought resolved by merged PR in latest editor version.
NAME Does the merged text in master address issue ?
LGTM, Thansk.
Very nice (IMHO)!

Discussion:
choosing the candidates to be raced, selecting appropriate transport parameters, etc.  An application SHOULD NOT depend on specific caching behaviour, instead it ought to explicitly request <del> any requid or desired properties via the Transport Services API. </del> <ins> any required or desired properties via the Transport Services API. </ins> 4.2.1.
Change:
Responding to review and tighter wording for the Arch draft: Undefined "transport object"
URL Where is this transport object defined?

Discussion:
notified of the status of its data transfer. Event Handling (events) defines categories of notifications that <del> an application can receive during the lifetime of transport objects.  Events also provide opportunities for the application to interact with the underlying transport by querying state or updating maintenance options. </del> <ins> an application can receive during the lifetime of a Connection. Events also provide opportunities for the application to interact with the underlying transport by querying state or updating maintenance options. </ins> Termination (termination) focuses on the methods by which data transmission is stopped, and connection state is torn down.
Change:
Fixes Issue
URL We have given example but we haven't really defined how the format should be written or how one should interpret in the example. Here "Any Stream" means any protocol that supports streaming ... but it would take quit some time to get to that point . It is also confusing that an "Any" is used with comma (,) and another is without a comma... To understand the example correctly, I suggest we either keep the examples on to a level where this is already described or describe how we are formatting the expression in this document as we described tree structure with numeric ( for example 1 , 1,1 ).
Perhaps we can just write HTTP and Stream without the Any part? Alternatively we could add a specific interface, e.g Wi-Fi, to avoid the first Any. And then also clarify the description of the example and what is raced. The notation is described earlier in the text, so I assume that is not the problem?
If you propose the changes then I can perhaps understand it better about the modified example.
NAME does PR solve the issue for you?
Thanks for the PR. I put two comments as input. I am fine merging it once Tommy's questions are resolved.

Discussion:
identified by concatenating its integer to it's parents identifier with a dot in between, such as "1.1" and "1.2".  Each node will be summarized by a tuple of three elements: endpoint, path (labeled here <del> by interface), and protocol.  The above example can now be written more succinctly as: </del> <ins> by interface), and protocol.  In protocol stacks, the layers are separated by '/' and ordered top-down.  The above example can now be written more succinctly as: </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
Change:
URL In this section - can we be clear on stating what properties we are taking about and what the caches. see the first line of the section. the second paragraph should at least mention why the connection is cloned. We haven't introduced the cloning before. we need to discuss the relation with Connection Context, does a Connection group have same connection context? My current understanding is if the Connection Context is separate then those Connections wont be grouped. But I fear that this can create confusion.
Latest merged master fixes bullet 2. The others need new text.
LGTM! Many thanks for doing this

Discussion:
4.1.8. <del> A Connection Group is a set of Connections that shares properties and caches.  A Connection Group represents state for managing Connections within a single application, and does not require end-to-end protocol signaling.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed together. </del> <ins> A Connection Group is a set of Connections that shares Connection Properties and cached state generated by protocols.  A Connection Group represents state for managing Connections within a single application, and does not require end-to-end protocol signaling.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed together. </ins> The API allows a Connection to be created from another Connection. This adds the new Connection to the Connection Group.  A change to

of an already active multi-streaming protocol instance. While Connection Groups are managed by the Transport Services system, <del> an application can define Connection Contexts to control caching boundaries, as discussed in conn-context. </del> <ins> an application can define different Connection Contexts for different Connection Groups to explicitly control caching boundaries, as discussed in conn-context. </ins> 4.2.