jiebi/CodeConvo huggingface dataset:
In the following cases, failure should be detected during pre- establishment: <del> A request by an application for Protocol Properties that cannot be </del> <ins> A request by an application for properties that cannot be </ins> satisfied by any of the available protocols.  For example, if an application requires "perMsgReliability", but no such feature is available in any protocol on the host running the transport system this should result in an error, e.g., when SCTP is not supported by the operating system. <del> A request by an application for Protocol Properties that are in conflict with each other, i.e., the required and prohibited properties cannot be satisfied by the same protocol.  For example, if an application prohibits "reliability" but then requires </del> <ins> A request by an application for properties that are in conflict with each other, i.e., the required and prohibited properties cannot be satisfied by the same protocol.  For example, if an application prohibits "reliability" but then requires </ins> "perMsgReliability", this mismatch should result in an error. To avoid allocating resources that are not finally needed, it is
implementation should store the properties in storage common to all protocols, and notify all protocol instances in the Protocol Stack whenever the properties have been modified by the application.  For <del> protocol-specfic properties, such as the User Timeout that applies to TCP, the Transport Services implementation only needs to update the relevant protocol instance. </del> <ins> Protocol-specific Properties, such as the User Timeout that applies to TCP, the Transport Services implementation only needs to update the relevant protocol instance. </ins> If an error is encountered in setting a property (for example, if the application tries to set a TCP-specific property on a Connection that
SHOULD be made accessible through a unified set of calls using the Transport Services API.  As a baseline, any Transport Services API SHOULD allow access to the minimal set of features offered by <del> transport protocols RFC8923. </del> <ins> transport protocols RFC8923.  If that minimal set is updated or expanded in the future, the Transport Services API ought to be extended to match. </ins> An application can specify constraints and preferences for the protocols, features, and network interfaces it will use via
setting Connection and Message Properties in Pre-Establishment) or have been omitted for brevity and simplicity. <ins> In this diagram, the lifetime of a Connection object is broken into three phases: Pre-Establishment, the Established state, and Termination. Pre-Establishment is based around a Preconnection object, that contains various sub-objects that describe the properties and parameters of desired Connections (Local and Remote Endpoints, Transport Properties, and Security Parameters).  A Preconnection can be used to start listening for inbound connections, in which case a Listener object is created, or can be used to establish a new connection directly using Initiate() (for outbound connections) or Rendezvous() (for peer-to-peer connections). Once a Connection is in the Established state, an application can send and receive Message objects, and receive state updates. Closing or aborting a connection, either locally or from the peer, can terminate a connection. </ins> 4.1.1. Endpoint: An endpoint represents an identifier for one side of a
application. Framer: A Framer is a data translation layer that can be added to <del> a Connection to define how application-layer Messages are transmitted over a Protocol Stack.  This is particularly relevant when using a protocol that otherwise presents unstructured streams, such as TCP. </del> <ins> a Connection.  Framers allow extending a Connection's protocol stack to define how to encapsulate or encode outbound Messages, and how to decapsulate or decode inbound data into Messages.  In this way, message boundaries can be preserved when using a Connection object, even with a protocol that otherwise presents unstructured streams, such as TCP.  This is designed based on the fact that many of the current application protocols evolved over TCP, which does not provide message boundary preservation, and since many of these protocols require message boundaries to function, each application layer protocol has defined its own framing.  For example, when an HTTP application sends and receives HTTP messages over a byte-stream transport, it must parse the boundaries of HTTP messages from the stream of bytes. </ins> 4.1.6.
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 <del> 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). </del> <ins> and/or received from a remote endpoint (i.e., depending on the kind of transport, connections can be bi-directional or unidirectional). 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). </ins> Once a Connection is established, data can be sent on it in the form of Messages.  The interface supports the preservation of message
5.2.4. <ins> Type: Enum This property specifies whether an application wants to use the connection for sending and/or receiving data.  Possible values are: The connection must support sending and receiving data The connection must support sending data. The connection must support receiving data In case a unidirectional connection is requested, but the system should fall back to bidirectional transport if unidirectional connections are not supported by the transport protocol. 5.2.5. </ins> Type: Preference This property specifies whether an application would like to supply a
The status of the Connection, which can be one of the following: Establishing, Established, Closing, or Closed. <ins> Whether the connection can be used to send data.  A connection can not be used for sending if the connection was created unidirectional receive only or if a message with the final property was sent over this connection. Whether the connection can be used to receive data.  A connection can not be used for reading if the connection was created unidirectional send only or if a message with the final property received was received.  The latter is only supported by certain transport protocols, e.g., by TCP as half-closed connection. </ins> Transport Features of the protocols that conform to the Required and Prohibited Transport Preferences, which might be selected by the transport system during Establishment.  These features
Changing one of these Protocol Properties on one Connection in the group changes it for all others.  Per-Message Protocol Properties, however, are not entangled.  For example, changing "Timeout for <del> aborting Connection" (see timeout) on one Connection in a group will automatically change this Protocol Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- </del> <ins> aborting Connection" (see conn-timeout) on one Connection in a group will automatically change this Protocol Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- </ins> lifetime) of a Message will only affect a single Message on a single Connection, entangled or not.
9. <del> The application can set per-connection Protocol Properties (see protocol-props).  Certain Procotol Properties may be read-only, on a protocol- and property-specific basis.  ~~~ Connection.SetProperty(property, value) ~~~ </del> <ins> 9.1. The application can set per-connection Properties.  Certain Connection Properties may be read-only, on a protocol- and property- specific basis.  ~~~ Connection.SetProperty(property, value) ~~~ </ins> At any point, the application can query Connection Properties.  ~~~ ConnectionProperties := Connection.GetProperties() ~~~
12. <del> Having discussed Transport Properties in connection-props and listed a number of Message Properties ("Ordered", "Idempotent" etc.) in message-props, we now provide a complete overview of a transport system's defined Transport Properties. Properties are structured in two ways: </del> <ins> Having discussed Selection Properties in selection-props, Connection Properties connection-props, and Message Properties (message-props), we now provide a complete overview of a transport system's defined Transport Properties. </ins> <del> By how they influence the transport system, which leads to a classification into "Selection Properties", "Protocol Properties", "Control Properties" and "Intents". </del> <ins> Transport Properties are structured by the phase and object they are applied: - Selection Properties apply to Preconnections - see selection-props - Connections Properties apply to Connections - see connection-props - Messages Properties apply to Messages - see </ins> <del> By the object they can be applied to: Preconnections, see connection-props, Connections, see introspection, and Messages, see message-props. Because some properties can be applied or queried on multiple objects, all Transport Properties are organized within a single namespace. </del> <ins> All Transport Properties are organized within a single namespace. This enables setting them as defaults in earlier stages and querying them in later stages: - Connections Properties can be set on Preconnections - Message Properties can be set on Preconnections and Connections - The effect of Selection Properties can be queried on Connections and Messages. </ins> Note that it is possible for a set of specified Transport Properties to be internally inconsistent, or to be inconsistent with the later
12.2. <del> Transport Properties - whether they apply to connections, preconnections, or messages - differ in the way they affect the transport system and protocols exposed through the transport system. The classification proposed below emphasizes two aspects of how properties affect the transport system, so applications know what to expect: Whether properties affect protocols exposed through the transport system (Protocol Properties) or the transport system itself (Control Properties) Whether properties have a clearly defined behavior that is likely to be invariant across implementations and environments (Protocol Properties and Control Properties) or whether the properties are interpreted by the transport system to provide a best effort service that matches the application needs as closely as possible (Intents). </del> <ins> [TODO: This section is mostly obsolete due to our consensus on how to structure properties - double-check whether text needs to be moved and delete this section afterwards] </ins> 12.2.1.
12.3.11. <del> Control Property [TODO: Discuss] Boolean Preconnection, Connection This property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold.  When set to true, the effect is twofold: The application may receive events in case excessive retransmissions.  In addition, the transport system considers this as a preference to use transports stacks that can provide this notification.  This is not a strict requirement.  If set to false, no notification of excessive retransmissions will be sent and this transport feature is ignored for protocol selection. The default is to have this option. </del> <ins> Boolean Connection Property - see conn-retrans-notify. </ins> 12.3.12. <del> Control Property [TODO: Discuss] Integer Preconnection, Connection This property specifies after how many retransmissions to inform the application about "Excessive Retransmissions". </del> <ins> Integer Connection Property - see </ins> 12.3.13. <del> Control Property [TODO: Discuss] Boolean Preconnection, Connection This property specifies whether an application considers it useful to be informed when an ICMP error message arrives that does not force termination of a connection.  When set to true, received ICMP errors will be available as SoftErrors.  Note that even if a protocol supporting this property is selected, not all ICMP errors will necessarily be delivered, so applications cannot rely on receiving them.  Setting this option also implies a preference to prefer transports stacks that can provide this notification.  If not set, no events will be sent for ICMP soft error message and this transport feature is ignored for protocol selection. This property applies to Connections and Connection Groups.  The default is not to have this option. </del> <ins> Boolean Connection Property - see </ins> 12.3.14.
12.3.21. <del> Protocol Property (Generic) Integer Connection This Property is a non-negative integer representing the relative inverse priority of this Connection relative to other Connections in the same Connection Group.  It has no effect on Connections not part of a Connection Group.  As noted in groups, this property is not entangled when Connections are cloned. </del> <ins> Integer Connection Property - see </ins> 12.3.22. [TODO: Discuss: should we remove this?  Whether we need this or the other depends on how we want to implement multi-streaming.  We don't <del> need both, so we should make a decision.] </del> <ins> need both, so we should make a decision. @mwelzl - These are really two different things @philsbln] </ins> Integer Message Property - see msg-niceness.
12.3.23. <del> Control Property [TODO: Discuss] Integer Preconnection, Connection This property specifies how long to wait before aborting a Connection during establishment, or before deciding that a Connection has failed after establishment.  It is given in seconds. </del> <ins> Integer Connection Property - see </ins> 12.3.24. <del> Protocol Property (Generic) / Control Property [TODO: Discuss] Enum Preconnection, Connection This property specifies which scheduler should be used among Connections within a Connection Group, see groups.  The set of schedulers can be taken from I-D.ietf-tsvwg-sctp-ndata. </del> <ins> Enum Connection Property - see </ins> 12.3.25. <del> Protocol Property (Generic) Integer Connection (read only) This property represents the maximum Message size that can be sent before or during Connection establishment, see also msg-idempotent. It is given in Bytes.  This property is read-only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.26. <del> Protocol Property (Generic) Integer Connection (read only) This property, if applicable, represents the maximum Message size that can be sent without incurring network-layer fragmentation or transport layer segmentation at the sender.  This property is read- only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.27. <del> Protocol Property (Generic) Integer Connection (read only) This property represents the maximum Message size that can be sent. This property is read-only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.28. <del> Protocol Property (Generic) Integer Connection (read only) This numeric property represents the maximum Message size that can be received.  This property is read-only. </del> <ins> Integer Connection Property (read-only) - see </ins> 12.3.29.
used to fine-tune the eventually established connection.  These Connection Properties can also be used to monitor and fine-tune established connections.  The behavior of the selected protocol <del> stack(s) when sending Messages is controlled by Message Context Properties message-props. Collectively, Selection, Connection, and Message Context Properties can be referred to as Transport Properties.  All Transport Properties, regardless of the phase in which they are used, are organized within a single namespace.  This enables setting them as defaults in earlier stages and querying them in later stages: - Connection Properties can be set on Preconnections - Message Properties can be set on Preconnections and Connections - The effect of Selection Properties can be queried on Connections and Messages </del> <ins> stack(s) when sending Messages is controlled by Message Properties message-props. Collectively, Selection, Connection, and Message Properties can be referred to as Transport Properties.  All Transport Properties, regardless of the phase in which they are used, are organized within a single namespace.  This enables setting them as defaults in earlier stages and querying them in later stages: - Connection Properties can be set on Preconnections - Message Properties can be set on Preconnections and Connections - The effect of Selection Properties can be queried on Connections and Messages </ins> Transport Properties can have one of a set of data types:
Applications may need to annotate the Messages they send with extra information to control how data is scheduled and processed by the <del> transport protocols in the Connection.  A messageContext object contains parameters for sending Messages, and can be passed to the </del> <ins> transport protocols in the Connection.  A MessageContext object contains properties for sending Messages, and can be passed to the </ins> Send Action.  Note that these properties are per-Message, not per- Send if partial Messages are sent (send-partial).  All data blocks associated with a single Message share properties.  For example, it
allow the end of a Message to still be sent. The simpler form of Send that does not take any messageContext is <del> equivalent to passing a default messageContext with not values added. </del> <ins> equivalent to passing a default MessageContext with not values added. </ins> If an application wants to override Message Properties for a specific <del> message, it can acquire an empty messageContext Object and add all </del> <ins> message, it can acquire an empty MessageContext Object and add all </ins> desired Message Properties to that Object.  It can then reuse the same messageContext Object for sending multiple Messages with the same properties. <del> Parameters may be added to a messageContext object only before the </del> <ins> Properties may be added to a MessageContext object only before the </ins> context is used for sending.  Once a messageContext has been used <del> with a Send call, modifying any of its parameters is invalid. </del> <ins> with a Send call, modifying any of its properties is invalid. </ins> Message Properties may be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given Message is
The following example sends a Message in two separate calls to Send. <del> All messageData 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. </del> <ins> 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. </ins> 7.5.
Abstract This document provides an overview of the architecture of Transport <del> Services, a system for exposing the features of transport protocols to applications.  This architecture serves as a basis for Application Programming Interfaces (APIs) and implementations that provide flexible transport networking services.  It defines the common set of terminology and concepts to be used in more detailed discussion of Transport Services. </del> <ins> Services, a model for exposing transport protocol features to applications for network communication.  In contrast to what is provided by most existing Application Programming Interfaces (APIs), it is based on an asynchronous, event-driven interaction pattern; it uses messages for 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.  This document further defines the common set of terminology and concepts to be used in definitions of APIs and implementations. </ins> 1.
applications adopt this interface, they will benefit from a wide set of transport features that can evolve over time, and ensure that the system providing the interface can optimize its behavior based on the <del> application requirements and network conditions. </del> <ins> application requirements and network conditions, without requiring a change to the application.  Further, this flexibility does not only enable faster deployment of new feature and protocols, it can also support applications with racing and fallback mechanisms which today usually need to be implemented in each application separately. </ins> This document is developed in parallel with the specification of the Transport Services API I-D.ietf-taps-interface and Implementation I- <del> D.ietf-taps-impl documents. </del> <ins> D.ietf-taps-impl documents.  Although following the Transport Services Architecture does of course not mean that all APIs and implementations have to be identical, agreeing on a common minimal set of features and representing them in a similar fashion improves the ability to easily port applications from one system to the another. </ins> 1.1.
3. During pre-establishment the application specifies the Endpoints to <del> be used for communication as well as its preferences regarding Protocol and Path Selection.  The implementation stores these objects and properties as part of the Preconnection object for use during connection establishment.  For Protocol and Path Selection Properties that are not provided by the application, the implementation must use the default values specified in the Transport Services API (I-D.ietf- taps-interface). </del> <ins> be used for communication as well as its preferences via Selection Properties and, if desired, also Connection Properties.  Generally, Connection Properties should be configured as early as possible, as they may serve as input to decisions that are made by the implementation (the Capacity Profile may guide usage of a protocol offering scavenger-type congestion control, for example).  In the remainder of this document, we only refer to Selection Properties because they are the more typical case and have to be handled by all implementations. The implementation stores these objects and properties as part of the Preconnection object for use during connection establishment.  For Selection Properties that are not provided by the application, the implementation must use the default values specified in the Transport Services API (I-D.ietf-taps-interface). </ins> 3.1.
3.2. <del> The properties specified during pre-establishment has a close </del> <ins> The properties specified during pre-establishment have a close </ins> connection to system policy.  The implementation is responsible for combining and reconciling several different sources of preferences when establishing Connections.  These include, but are not limited to: Application preferences, i.e., preferences specified during the <del> pre-establishment such as Local Endpoint, Remote Endpoint, Path Selection Properties, and Protocol Selection Properties. </del> <ins> pre-establishment via Selection Properties. </ins> Dynamic system policy, i.e., policy compiled from internally and externally acquired information about available network