Draft: draft-ietf-taps-arch

Commentary: Addresses  's great comments from ! 
 TAPS Architecture - Additional comments on rev -03 ( detailed read - through ) . Note : This adds to my previous set of review issues - these could be handled at the same time . Section 1 : Can we make reading easier : “ This flexibility does not only enable faster deployment of new feature and protocols , but it can also support applications with racing and fallback mechanisms which otherwise need to be implemented in each application separately . ” suggest : “ This flexibility enables faster deployment of new feature and protocols , . It can also support applications with racing and fallback mechanisms , which otherwise need to be implemented in each application separately . ” ” — “ Although following the Transport Services Architecture does of course not mean that “ do we need /of  ( this reads oddly ) . — “ from one system to the another ” should be : “ from one system to another ” Section 1.1 : “ The model of using sockets for networking can be represented as follows ” could we insert “ traditional ” or “ existing ” or something like that before “ model ” , since a new reader may not realise this is the description of what exists rather what this document develops ? — “ , which provides the interface to the implementations of UDP and TCP ( typically implemented in the system 's kernel ) , which in turn send data over the available network layer interfaces . ” Two “ , which ” in a long sentence , could we write : “ . This API provides the interface to the implementations of UDP and TCP ( typically implemented in the system 's kernel ) , which in turn send data over the available network layer interfaces . ” — “ The Implementation ” Is capitalised “ I ” needed ? — “ for mapping the API into the various available transport ” Is this “ into ” or “ to ” - I think the interface maps to these ? — “ There are a few key departures that Transport Services makes from the sockets API : ” a “ few key ” seems odd to me in a spec . “ There are key differences between the architecture of the Transport Services system and the architecture of the sockets API : ” - or something like that ? Section 1.2 : “ and changes to available network links ” : insert “ the ” and “ to ” so it does not mean that it makes the change : “ and changes in the available network links ” — Section 1.3 : “ HTTP/1.1 uses character delimiters to segment messages over a stream ; TLS record headers carry a version , content type , and length ; and HTTP/2 uses ” I think this needs text needs several references to the specs ? Section 3 : “ The following considerations were used in the design of this architecture . ” If these were only a list of considerations , then we we do not need “ RFC2119 ” language after all in this section . If they are actually the basis of the architecture , then we need to change the words “ considerations ” to “ requirements ” or something . I actually think it is helpful for the basis for the design should be expressed in RFC2119 language . I suggest the best option could be simply to omit the sentence ? — “ that include some transport security protocol are eligible to be used . ” The word “ some ” is wrong , and also “ protocol ” . I think this should be “ a transport security function ” ? — Section 3.3 : “ The abstract API definition [ I - D.ietf - taps - interface ] describes this interface and is aimed at application developers . ” “ aimed at ” seems odd because of “ and ” and “ aimed ” . “ The abstract API definition [ I - D.ietf - taps - interface ] describes this interface . This is expected to be utilised by application developers . ” — “ It is expected that all implementations of Transport Services will offer the entire mandatory API , but that some features will not be functional in certain implementations . ” This seems to me to still be possible to read the “ mandatory ” part os optional , which ca n’t be . Is it also OK to say this instead : “ It is expected that all implementations of Transport Services system will offer the entire mandatory API . However , some features provided below the API may not be functional in certain implementations . ” — “ All implementations are REQUIRED to offer sufficient APIs to use the distilled minimal set of features offered by transport protocols ... “ What does the plural “ APIs ” mean ? I suggest we write : “ All implementations are REQUIRED to offer an API that is sufficient to provide the distilled minimal set of features offered by transport protocols … ” — “ , but it is possible that some very constrained devices might not have , for example , a full TCP implementation beneath the API . ” I ’m not fond of RFC2119 constructs that include an exception clause . Could we write this instead ? “ For example , it is possible that some very constrained devices might not have , for example , a full TCP implementation beneath the API [ ] . ” This ref is I believe in cross - WG WGLC and should now be stable . — “ It is expected that this document will be updated and supplemented as new protocols and protocol features are developed . ” could we replace “ this document ” by the [ REF ] , to avoid the possibility of misreading / misquoting it as the architecture document itself ? — “ defines new protocols that require any changes to a remote system . ” to me the first part here is that there is no implementation work required at the RECEIVER . I think that should be clear . — “ The Transport Services system MUST be deployable on one side only . ” I think the second point is that it can be deployed in this way which places design constraints on the system , specifically that the SENDER is a one - sided system . Is it possible we could put this in a separate para instead , e.g. “ The Transport Services system MUST be deployable on one side only . A Transport Services system implemented at the sending endpoint can communicate with a remote endpoint on any existing system that implements the transport protocol(s ) selected by the TAPS System . Similarly a Transport Services system at a listening endpoint can communicate using a using a transport protocol at a sending endpoint implemented in an existing system . ” Section 4.1 : “ establish communication and send and receive data . ”   after “ communication ” or “ then ” after first “ and ” — “ A Preconnection can be fully specified and represent a single possible Connection ” is this /represents/ ? — “ The Remote Endpoint MUST be specified in the Preconnection is used to Initiate connections . ” seems broken English , Is this : “ The Remote Endpoint MUST be specified if a Preconnection is used to Initiate connections . ” — in 4.1.2 : “ Changes made to Connection Properties after establishment take effect on a best - effort basis . ” My understanding was that this does not change the protocol selection , but can change the way the protocol uses the path . If I was correct , then it would be good to add a sentence to say this . — In 4.1.3 : “ prepare any required local or remote state to be able to send and/or receive Messages . ” what becomes able ? “ prepare any required local or remote state to enable the endpoint to send and/or receive Messages . ” — In 4.1.4 : “ If a received Message is incomplete or corrupted , it might or might not be usable by certain applications . ” I agree this is possible , but I ’d like to assert this really must not be the default and it is important to highlight that . Is it possible to say : “ If a received Message is incomplete or corrupted , the default action is to not pass the data to the application . A certain application can override this default and the data might or might not be usable by that application . ” — “ Message Properties can be used to annotate specific Messages . “ I agree , however I think it is really important to say that these annotations for sending exist only within the Local Endpoint and doe not cause additional bytes to be communicated to the Remote Endpoint . For example , they could change the DSCP , for instance . [ [ We need to choose words carefully , because the the DSCP is actually communicated across the path and could be sent end - to - end , but it is not additional data to the message on the wire . ] ] — “ When receiving Messages , Message Properties can contain per - protocol properties . ” Again , I think it is important to say the Remote Endpoint can add per - protocol properties to the messages it receives . — “ properties specific to how the Message 's content is to be sent . “ I think we should delete the apostrophe , or alternatively we could write “ content of the message ” . — “ Status of the Send operation can be delivered back to the application in an event ( Section 4.1.5 ) . ” could be : “ The Status of the Send operation can be delivered back to the sending application in an event ( Section 4.1.5 ) . “ — In 4.1.5 : “ This list of events that can be delivered to an application is not exhaustive , but gives the top - level categories of events . ” Could be : “ This section provides the top - level categories of events events that can be delivered to an application . This list is not exhaustive . ” — In 4.2 : “ The Transport System Implementation Concepts ” We do not need to define this as a capitalised term . — “ are allowed be multiplexed ” insert /to/ before /be/. — “ Applications can use can use their explicitly defined ” please rephrase : “ An application can explicitly define “ — “ including any state it has necessary ” please remove /it has/ — “ and a Transport Services system 's policies and heuristics . ” could we instead write : “ and the heuristics or policies of the Transport Services system . ” — In 4.2.3 : “ Transitioning between different   is in some cases controlled by properties that only change when application code is updated . “ - is this statement about the present case , or the case with TAPS , this is not clear , but I think the former ? — “ This functionality can be a powerful driver of new protocol adoption , but needs to ” I agree - is it protocol or stack functionality , I think this could be better as : “ This functionality in the API can be a powerful driver of new protocol adoption , but needs to ” — “ Both stacks MUST offer the same transport services ” this could use a reference to mindset perhaps ? — Could better with a reference . We could use [ RFC8303 ] and [ RFC8304 ] to contrast the two ? — “ However , if the application does not require reliability , then a Protocol Stack that adds unnecessary reliability might be allowed as an equivalent   as long as it does not conflict with any other application - requested properties . ” allowing or not allowing seems odd , could we write : “ However , if the application does not require reliability , then a Protocol Stack that adds reliability could be regarded as an equivalent   providing this would not conflict with other application - requested properties . ” — In 4.2.4 : “ properties of the Implementation ” implementation should not be capitalised . — “ Transport System Implementation ” implementation should not be capitalised . — “ The interface to specify these Groups ” -groups should not be capitalised . — Normative references : [ I - D.ietf - taps - interface ] [ RFC8174 ] [ RFC2119 ] 
 This was done ! 
 LGTM modulo two minor comments .
Paragraph (version A):
The goal of the Transport Services architecture is to provide a
common, flexible, and reusable interface for transport protocols.  As
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
application requirements and network conditions, without requiring
changes to the applications.  This flexibility does not only enable
faster deployment of new feature and protocols, but it can also
support applications with racing and fallback mechanisms which
otherwise need to be implemented in each application separately.
Paragraph (version A):
This document is developed in parallel with the specification of the
Transport Services API I-D.ietf-taps-interface and Implementation
Guidelines I-D.ietf-taps-impl.  Although following the Transport
Services Architecture does of course not mean that all APIs and
implementations have to be identical, a common minimal set of
features represented in a consistent fashion will enable applications
to be easily ported from one system to the another.
Paragraph (version A):
The model of using sockets for networking can be represented as
follows: applications create connections and transfer data using the
socket API, which provides the interface to the implementations of
UDP and TCP (typically implemented in the system's kernel), which in
turn send data over the available network layer interfaces.
Paragraph (version B):
The goal of the Transport Services architecture is to provide a
common, flexible, and reusable interface for transport protocols.  As
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
application requirements and network conditions, without requiring
changes to the applications.  This flexibility enables faster
deployment of new features and protocols.  It can also support
applications by offering racing and fallback mechanisms, which
otherwise need to be implemented in each application separately.
Paragraph (version B):
This document is developed in parallel with the specification of the
Transport Services API I-D.ietf-taps-interface and Implementation
Guidelines I-D.ietf-taps-impl.  Although following the Transport
Services Architecture does not require that all APIs and
implementations are identical, a common minimal set of features
represented in a consistent fashion will enable applications to be
easily ported from one system to another.
Paragraph (version B):
Applications create connections and transfer data using the socket
API.
Paragraph (version B):
The socket API provides the interface to the implementations of
TCP and UDP (typically implemented in the system's kernel).
Paragraph (version B):
TCP and UDP in the kernel send and receive data over the available
network layer interfaces.
Paragraph (version A):
The Transport Services API I-D.ietf-taps-interface defines the
mechanism for an application to create network connections and
transfer data.  The Implementation I-D.ietf-taps-impl is responsible
for mapping the API into the various available transport protocols
and managing the available network interfaces and paths.
Paragraph (version A):
There are a few key departures that Transport Services makes from the
sockets API: it presents an asynchronous, event-driven API; 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.
Paragraph (version B):
The Transport Services API I-D.ietf-taps-interface defines the
mechanism for an application to create network connections and
transfer data.  The implementation I-D.ietf-taps-impl is responsible
for mapping the API to the various available transport protocols and
managing the available network interfaces and paths.
Paragraph (version B):
There are key differences between the architecture of the Transport
Services system and the architecture of the sockets API: it presents
an asynchronous, event-driven API; 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.
Paragraph (version A):
The Transport Services API also delivers events regarding the
lifetime of a connection and changes to available network links,
which were not previously made explicit in sockets.
Paragraph (version B):
The Transport Services API also delivers events regarding the
lifetime of a connection and changes in the available network links,
which were not previously made explicit in sockets.
Paragraph (version A):
Sockets provide a message interface for datagram protocols like UDP,
but provide an unstructured stream abstraction for TCP.  While TCP
does indeed provide the ability to send and receive data as streams,
most applications need to interpret structure within these streams.
For example, HTTP/1.1 uses character delimiters to segment messages
over a stream; TLS record headers carry a version, content type, and
length; and HTTP/2 uses frames to segment its headers and bodies.
Paragraph (version B):
Sockets provide a message interface for datagram protocols like UDP,
but provide an unstructured stream abstraction for TCP.  While TCP
does indeed provide the ability to send and receive data as streams,
most applications need to interpret structure within these streams.
For example, HTTP/1.1 uses character delimiters to segment messages
over a stream RFC7230; TLS record headers carry a version, content
type, and length RFC8446; and HTTP/2 uses frames to segment its
headers and bodies RFC7540.
Paragraph (version A):
One of the key insights to come from identifying the minimal set of
features provided by transport protocols I-D.ietf-taps-minset was
that features either require application interaction and guidance
(referred to as Functional Features), or else can be handled
automatically by a system implementing Transport Services (referred
to as Automatable Features).  Among the Functional Features, some
were common across all or nearly all transport protocols, while
others could be seen as features that, if specified, would only be
useful with a subset of protocols, but would not harm the
functionality of other protocols.  For example, some protocols can
deliver messages faster for applications that do not require messages
to arrive in the order in which they were sent.  However, this
functionality needs to be explicitly allowed by the application,
since reordering messages would be undesirable in many cases.
Paragraph (version B):
One of the key insights to come from identifying the minimal set of
features provided by transport protocols I-D.ietf-taps-minset was
that features either require application interaction and guidance
(referred to as Functional or Optimizing Features), or else can be
handled automatically by a system implementing Transport Services
(referred to as Automatable Features).  Among the Functional and
Optimizing Features, some were common across all or nearly all
transport protocols, while others could be seen as features that, if
specified, would only be useful with a subset of protocols, but would
not harm the functionality of other protocols.  For example, some
protocols can deliver messages faster for applications that do not
require messages to arrive in the order in which they were sent.
However, this functionality needs to be explicitly allowed by the
application, since reordering messages would be undesirable in many
cases.
Paragraph (version A):
There are several degrees in which a Transport Services system can
offer flexibility to an application: it can provide access to
multiple sets of protocols and protocol features; it can use these
protocols across multiple paths that could have different performance
and functional characteristics; and it can communicate with different
remote systems to optimize performance, robustness to failure, or
some other metric.  Beyond these, if the API for the system remains
the same over time, new protocols and features could be added to the
system's implementation without requiring changes in applications for
adoption.
Paragraph (version A):
The following considerations were used in the design of this
architecture.
Paragraph (version B):
There are several degrees in which a Transport Services system is
intended to offer flexibility to an application: it can provide
access to multiple sets of protocols and protocol features; it can
use these protocols across multiple paths that could have different
performance and functional characteristics; and it can communicate
with different remote systems to optimize performance, robustness to
failure, or some other metric.  Beyond these, if the API for the
system remains the same over time, new protocols and features could
be added to the system's implementation without requiring changes in
applications for adoption.
Paragraph (version A):
There are applications that will need to control fine-grained details
of transport protocols to optimize their behavior and ensure
compatibility with remote systems.  A Transport Services system
therefore SHOULD also permit more specialized protocol features to be
used.  The interface for these specialized options should be exposed
differently from the common options to ensure flexibility.
Paragraph (version B):
There are applications that will need to control fine-grained details
of transport protocols to optimize their behavior and ensure
compatibility with remote systems.  A Transport Services system
therefore SHOULD also permit more specialized protocol features to be
used.  The interface for these specialized options ought to be
exposed differently from the common options to ensure flexibility.
Paragraph (version A):
Other specialized features, however, could be strictly required by an
application and thus constrain the set of protocols that can be used.
For example, if an application requires encryption of its transport
data, only protocol stacks that include some transport security
protocol are eligible to be used.  A Transport Services API MUST
allow applications to define such requirements and constrain the
system's options.  Since such options are not part of the core/common
features, it will generally be simple for an application to modify
its set of constraints and change the set of allowable protocol
features without changing the core implementation.
Paragraph (version B):
Other specialized features, however, could be strictly required by an
application and thus constrain the set of protocols that can be used.
For example, if an application requires encryption of its transport
data, only protocol stacks that include a transport security function
are eligible to be used.  A Transport Services API MUST allow
applications to define such requirements and constrain the system's
options.  Since such options are not part of the core/common
features, it will generally be simple for an application to modify
its set of constraints and change the set of allowable protocol
features without changing the core implementation.
Paragraph (version A):
The Transport Services API is envisioned as the abstract model for a
family of APIs that share a common way to expose transport features
and encourage flexibility.  The abstract API definition I-D.ietf-
taps-interface describes this interface and is aimed at application
developers.
Paragraph (version A):
Implementations that provide the Transport Services API I-D.ietf-
taps-impl will vary due to system-specific support and the needs of
the deployment scenario.  It is expected that all implementations of
Transport Services will offer the entire mandatory API, but that some
features will not be functional in certain implementations.  All
implementations are REQUIRED to offer sufficient APIs to use the
distilled minimal set of features offered by transport protocols I-
D.ietf-taps-minset, including API support for TCP and UDP transport,
but it is possible that some very constrained devices might not have,
for example, a full TCP implementation beneath the API.
Paragraph (version A):
To preserve flexibility and compatibility with future protocols, top-
level features in the Transport Services API SHOULD avoid referencing
particular transport protocols.  The mappings of these API features
to specific implementations of each feature is explained in the I-
D.ietf-taps-impl along with the implications of the feature on
existing protocols.  It is expected that this document will be
updated and supplemented as new protocols and protocol features are
developed.
Paragraph (version A):
It is important to note that neither the Transport Services API I-
D.ietf-taps-interface nor the Implementation document I-D.ietf-taps-
impl defines new protocols that require any changes to a remote
system.  The Transport Services system MUST be deployable on one side
only.
Paragraph (version B):
The Transport Services API is envisioned as the abstract model for a
family of APIs that share a common way to expose transport features
and encourage flexibility.  The abstract API definition I-D.ietf-
taps-interface describes this interface and how it can be exposed to
application developers.
Paragraph (version B):
Implementations that provide the Transport Services API I-D.ietf-
taps-impl will vary due to system-specific support and the needs of
the deployment scenario.  It is expected that all implementations of
Transport Services will offer the entire mandatory API.  All
implementations are REQUIRED to offer an API that is sufficient to
use the distilled minimal set of features offered by transport
protocols I-D.ietf-taps-minset, including API support for TCP and UDP
transport.  However, some features provided by this API will not be
functional in certain implementations.  For example, it is possible
that some very constrained devices might not have a full TCP
implementation beneath the API.
Paragraph (version B):
To preserve flexibility and compatibility with future protocols, top-
level features in the Transport Services API SHOULD avoid referencing
particular transport protocols.  The mappings of these API features
to specific implementations of each feature is explained in the I-
D.ietf-taps-impl along with the implications of the feature on
existing protocols.  It is expected that I-D.ietf-taps-interface will
be updated and supplemented as new protocols and protocol features
are developed.
Paragraph (version B):
It is important to note that neither the Transport Services API I-
D.ietf-taps-interface nor the Implementation document I-D.ietf-taps-
impl define new protocols or protocol capabilities that affect what
is communicated across the network.  The Transport Services system
MUST be deployable on one side only.  A Transport Services system
acting as a connection initiator can communicate with any existing
system that implements the transport protocol(s) selected by the
Transport Services system.  Similarly, a Transport Services system
acting as a listener can receive connections for any protocol that is
supported by the system, from existing initiators.
Paragraph (version A):
Fundamentally, a Transport Services API needs to provide basic
objects (objects) that allow applications to establish communication
and send and receive data.  These could be exposed as handles or
referenced objects, depending on the language.
Paragraph (version B):
Fundamentally, a Transport Services API needs to provide basic
objects (objects) that allow applications to establish communication,
and then send and receive data.  These could be exposed as handles or
referenced objects, depending on the language.
Paragraph (version A):
Preconnection: A Preconnection object is a representation of a
potential connection.  It has state that describes parameters of a
Connection that might exist in the future: the Local Endpoint from
which that Connection will be established, the Remote Endpoint
(preestablishment) to which it will connect, and Selection
Properties (preestablishment) that influence the paths and
protocols a Connection will use.  A Preconnection can be fully
specified and represent a single possible Connection, or it can be
partially specified such that it represents a family of possible
Connections.  The Local Endpoint (preestablishment) MUST be
specified if the Preconnection is used to Listen for incoming
connections.  The Local Endpoint is OPTIONAL if it is used to
Initiate connections.  The Remote Endpoint MUST be specified in
the Preconnection is used to Initiate connections.  The Remote
Endpoint 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 Rendezvous is to occur based on the
Preconnection.
Paragraph (version B):
Preconnection: A Preconnection object is a representation of a
potential connection.  It has state that describes parameters of a
Connection that might exist in the future: the Local Endpoint from
which that Connection will be established, the Remote Endpoint
(preestablishment) to which it will connect, and Selection
Properties (preestablishment) that influence the paths and
protocols a Connection will use.  A Preconnection can be fully
specified such that it represents a single possible Connection, or
it can be partially specified such that it represents a family of
possible Connections.  The Local Endpoint (preestablishment) MUST
be specified if the Preconnection is used to Listen for incoming
connections.  The Local Endpoint is OPTIONAL if it is used to
Initiate connections.  The Remote Endpoint MUST be specified in
the Preconnection that is used to Initiate connections.  The
Remote Endpoint 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 Rendezvous is to occur based on the
Preconnection.
Paragraph (version A):
best-effort basis.
Paragraph (version A):
Initiate: The primary action that an application can take to
create a Connection to a Remote Endpoint, and prepare any required
local or remote state to be able to send and/or receive Messages.
For some protocols, this will initiate a client-to-server style
handshake; for other protocols, this will just establish local
state.  The process of identifying options for connecting, such as
resolution of the Remote Endpoint, occurs in response the Initiate
call.
Paragraph (version B):
best-effort basis.  Such changes do not affect protocol or path
selection, but only modify the manner in which a connection sends
and receives data.
Paragraph (version B):
Initiate: The primary action that an application can take to
create a Connection to a Remote Endpoint, and prepare any required
local or remote state to enable the transmission of Messages.  For
some protocols, this will initiate a client-to-server style
handshake; for other protocols, this will just establish local
state.  The process of identifying options for connecting, such as
resolution of the Remote Endpoint, occurs in response the Initiate
call.
Paragraph (version A):
Message: A Message object is a unit of data that can be
represented as bytes that can be transferred between two systems
over a transport connection.  The bytes within a Message are
assumed to be ordered within the Message.  If an application does
not care about the order in which a peer receives two distinct
spans of bytes, those spans of bytes are considered independent
Messages.  If a received Message is incomplete or corrupted, it
might or might not be usable by certain applications.  Boundaries
of a Message might or might not be understood or transmitted by
transport protocols.  Specifically, what one application considers
to be two Messages sent on a stream-based transport can be treated
as a single Message by the application on the other side.
Paragraph (version A):
Message Properties: Message Properties can be used to annotate
specific Messages.  These properties can specify how the transport
will send the Message (for prioritization and reliability), along
with any per-protocol properties to send with the Message.
Message Properties MAY be set on a Preconnection to define
defaults properties for sending.  When receiving Messages, Message
Properties can contain per-protocol properties.
Paragraph (version A):
Send: The action to transmit a Message or partial Message over a
Connection to the remote system.  The interface to Send MAY
include Message Properties specific to how the Message's content
is to be sent.  Status of the Send operation can be delivered back
to the application in an event (events).
Paragraph (version B):
Message: A Message object is a unit of data that can be
represented as bytes that can be transferred between two systems
over a transport connection.  The bytes within a Message are
assumed to be ordered within the Message.  If an application does
not care about the order in which a peer receives two distinct
spans of bytes, those spans of bytes are considered independent
Messages.  Boundaries of a Message might or might not be
understood or transmitted by transport protocols.  Specifically,
what one application considers to be two Messages sent on a
stream-based transport can be treated as a single Message by the
application on the other side.
Paragraph (version B):
Message Properties: Message Properties can be used to annotate
specific Messages.  These properties might only apply to how
Message is sent (such as how the transport will treat
prioritization and reliability), but can also include properties
that specific protocols encode and communicate to the Remote
Endpoint.  Message Properties MAY be set on a Preconnection to
define defaults properties for sending.  When receiving Messages,
Message Properties can contain per-protocol properties for
properties that are sent between the endpoints.
Paragraph (version B):
Send: The action to transmit a Message or partial Message over a
Connection to the remote system.  The interface to Send MAY
include Message Properties specific to how the Message content is
to be sent.  The status of the Send operation can be delivered
back to the sending application in an event (events).
Paragraph (version A):
This list of events that can be delivered to an application is not
exhaustive, but gives the top-level categories of events.  The API
MAY expand this list.
Paragraph (version B):
This section provides the top-level categories of events events that
can be delivered to an application.  This list is not exhaustive.
Paragraph (version A):
The Transport System Implementation Concepts define the set of
objects used internally to a system or library to implement the
functionality needed to provide a transport service across a network,
as required by the abstract interface.
Paragraph (version A):
Connection Group: A set of Connections that share properties and
caches.  For multiplexing transport protocols, only Connections
within the same Connection Group are allowed be multiplexed
together.  Applications can use their explicitly defined
Connection Groups to control caching boundaries, as discussed in
groups.
Paragraph (version A):
Protocol Instance: A single instance of one protocol, including
any state it has necessary to establish connectivity or send and
receive Messages.
Paragraph (version B):
This section defines the set of objects used internally to a system
or library to implement the functionality needed to provide a
transport service across a network, as required by the abstract
interface.
Paragraph (version B):
Connection Group: A set of Connections that share properties and
caches.  For multiplexing transport protocols, only Connections
within the same Connection Group are allowed to be multiplexed
together.  An application can explicitly define Connection Groups
to control caching boundaries, as discussed in groups.
Paragraph (version B):
Protocol Instance: A single instance of one protocol, including
any state necessary to establish connectivity or send and receive
Messages.
Paragraph (version A):
Protocol Selection: Protocol Selection represents the act of
choosing one or more sets of protocol options that are available
to use based on the Transport Properties provided by the
application, and a Transport Services system's policies and
heuristics.
Paragraph (version B):
Protocol Selection: Protocol Selection represents the act of
choosing one or more sets of protocol options that are available
to use based on the Transport Properties provided by the
application, and the heuristics or policies within the Transport
Services system.
Paragraph (version A):
The Transport Services architecture defines a mechanism that allows
applications to easily use different network paths and Protocol
Stacks.  Transitioning between different Protocol Stacks is in some
cases controlled by properties that only change when application code
is updated.  For example, an application can enable the use of a
multipath or multistreaming transport protocol by modifying the
properties in its Pre-Connection configuration.  In some cases,
however, the Transport Services system will be able to automatically
change Protocol Stacks without an update to the application, either
by selecting a new stack entirely, or by racing multiple candidate
Protocol Stacks during connection establishment.  This functionality
can be a powerful driver of new protocol adoption, but needs to be
constrained carefully to avoid unexpected behavior that can lead to
functional or security problems.
Paragraph (version B):
The Transport Services architecture defines a mechanism that allows
applications to easily use different network paths and Protocol
Stacks.  In some cases, changing which Protocol Stacks or network
paths are used will require updating the preferences expressed by the
application that uses the Transport Services system.  For example, an
application can enable the use of a multipath or multistreaming
transport protocol by modifying the properties in its Pre-Connection
configuration.  In some cases, however, the Transport Services system
will be able to automatically change Protocol Stacks without an
update to the application, either by selecting a new stack entirely,
or by racing multiple candidate Protocol Stacks during connection
establishment.  This functionality in the API can be a powerful
driver of new protocol adoption, but needs to be constrained
carefully to avoid unexpected behavior that can lead to functional or
security problems.
Paragraph (version A):
Both stacks MUST offer the same transport services, as required by
the application.  For example, if an application specifies that it
requires reliable transmission of data, then a Protocol Stack
using UDP without any reliability layer on top would not be
allowed to replace a Protocol Stack using TCP.  However, if the
application does not require reliability, then a Protocol Stack
that adds unnecessary reliability might be allowed as an
equivalent Protocol Stack as long as it does not conflict with any
other application-requested properties.
Paragraph (version B):
Both stacks MUST offer the transport services that are required by
the application.  For example, if an application specifies that it
requires reliable transmission of data, then a Protocol Stack
using UDP without any reliability layer on top would not be
allowed to replace a Protocol Stack using TCP.  However, if the
application does not require reliability, then a Protocol Stack
that adds reliability could be regarded as an equivalent Protocol
Stack as long providing this would not conflict with any other
application-requested properties.
Paragraph (version B):
Moreover, Transport Services systems MUST NOT automatically fall back
from secure protocols to insecure protocols, or to weaker versions of
secure protocols.  For example, if a client requests TLS, but the
desired version of TLS is not available, its connection will fail.