Draft: draft-ietf-taps-arch

Commentary: This is the second sldie trying to unravel what things are called . 
 This is a PR that came out of my unvoiced frustration with the terms . In particular when we talk about a " system " or and " endpoint " ; what do we call the thing below the API : the " transport system " , and what is the architecture ( the whole thing ) . I do n't much mind if we use " Transport System " or " Transport Services System " ... hopefully that change would be small . Is this PR sane ? 
 Please be kind . This issue comes with a PR , but any clarification of language comes with pain . We have a terminology soup in ARCH , in particular : ( 1 ) we currently talk about a " system " in different ways ; ( 2 ) we talk about what is below the API in various ways ( I 'd like to call this the " Transport System " , but we could instead call it the " Transport Services System " if that longer form seems better ( 3 ) The term architecture should only refer to the API and " Transport System " together . Please look at the linked PR ....
Paragraph (version A):
This document describes an architecture for exposing transport
protocol features to applications for network communication, the
Transport Services architecture.  The Transport Services Application
Programming Interface (API) is based on an asynchronous, event-driven
interaction pattern.  This API uses messages for representing data
transfer to applications, and describes how implementations can use
multiple IP addresses, multiple protocols, and multiple paths, and
provide multiple application streams.  This document further defines
common terminology and concepts to be used in definitions of
Transport Services APIs and implementations.
Paragraph (version B):
This document describes an architecture for exposing transport
protocol features to applications for network communication, a
Transport Services system.  The Transport Services Application
Programming Interface (API) is based on an asynchronous, event-driven
interaction pattern.  This API uses messages for representing data
transfer to applications, and describes how implementations can use
multiple IP addresses, multiple protocols, and multiple paths, and
provide multiple application streams.  This document further defines
common terminology and concepts to be used in definitions of a
Transport Service API and a Transport Services implementation.
Paragraph (version A):
model describes how the API model of Transport Services differs
from traditional socket-based APIs.  Specifically, it offers
asynchronous event-driven interaction, the use of messages for
data transfer, and the flexibility to use different transport
protocols and paths without requiring major changes to the
application.
Paragraph (version B):
model describes how the API model of Transport Services
architecture differs from traditional socket-based APIs.
Specifically, it offers asynchronous event-driven interaction, the
use of messages for data transfer, and the flexibility to use
different transport protocols and paths without requiring major
changes to the application.
Paragraph (version A):
concepts presents the Transport Services architecture diagram and
defines the concepts that are used by both the API and
implementation documents.  The Preconnection allows applications
to configure Connection Properties.
Paragraph (version B):
concepts presents the Transport Services architecture diagram and
defines the concepts that are used by both the API I-D.ietf-taps-
interface and implementation guidelines I-D.ietf-taps-impl.  The
Preconnection allows applications to configure Connection
Properties.
Paragraph (version A):
The Transport Services architecture evolves this general model of
interaction, aiming to both modernize the API surface presented to
applications by the transport layer and enrich the capabilities of
the Transport Services implementation.
Paragraph (version B):
The Transport Services architecture evolves this general model of
interaction, to both modernize the API surface presented to
applications by the transport layer and to enrich the capabilities of
the implementation below the API.
Paragraph (version A):
The Transport Services API I-D.ietf-taps-interface defines the
interface for an application to create network connections and
transfer data.  It combines interfaces for multiple interaction
patterns into a unified whole.  By combining name resolution with
connection establishment and data transfer in a single API, it allows
for more flexible implementations to provide path and transport
protocol agility on the application's behalf.  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 A):
There are key differences between the architecture of the Transport
Services system and the architecture of the Socket API: the API of
the Transport Services architecture is asynchronous and event-driven;
it uses messages for representing data transfer to applications; and
it describes how implementations can use multiple IP addresses,
multiple protocols, multiple paths, and provide multiple application
streams.
Paragraph (version A):
Originally, sockets presented a blocking interface for establishing
connections and transferring data.  However, most modern applications
interact with the network asynchronously.  Emulation of an
asynchronous interface using sockets 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 application
then waits and can try again later.  In contrast to sockets, 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.
Paragraph (version A):
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):
Using asynchronous events allows for a more natural interaction model
when establishing connections and transferring data.  Events in time
more closely reflect the nature of interactions over networks, as
opposed to how sockets represent network resources as file system
objects that may be temporarily unavailable.
Paragraph (version B):
The Transport Services API I-D.ietf-taps-interface defines the
interface for an application to create network connections and
transfer data.  It combines interfaces for multiple interaction
patterns into a unified whole.  By combining name resolution with
connection establishment and data transfer in a single API, it allows
for more flexible implementations to provide path and transport
protocol agility on the application's behalf.
Paragraph (version B):
The Transport Services implementation I-D.ietf-taps-impl implements
the transport layer protocols and other functions needed to send and
receive data.  It is is responsible for mapping the API to a specific
available transport protocol stack and managing the available network
interfaces and paths.
Paragraph (version B):
There are key differences between the Transport Services architecture
and the architecture of the Socket API: the API of the Transport
Services architecture is asynchronous and event-driven; it uses
messages for representing data transfer to applications; and it
describes how implementations can use multiple IP addresses, multiple
protocols, multiple paths, and provide multiple application streams.
Paragraph (version B):
Originally, the Socket API presented a blocking interface for
establishing connections and transferring data.  However, most modern
applications interact with the network asynchronously.  Emulation of
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
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.
Paragraph (version B):
This API also delivers events regarding the lifetime of a connection
and changes in the available network links, which were not previously
made explicit in the Socket API.
Paragraph (version B):
Using asynchronous events allows for a more natural interaction model
when establishing connections and transferring data.  Events in time
more closely reflect the nature of interactions over networks, as
opposed to how the Socket API represent network resources as file
system objects that may be temporarily unavailable.
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 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 B):
The Socket API provides 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):
the ability to manage dependencies between messages, when the
Transport Services system could decide to not deliver a message,
either following packet loss or because it has missed a deadline.
In particular, this can avoid (re-)sending data that relies on a
previous transmission that was never received.
Paragraph (version B):
the ability to manage dependencies between messages, when a
Transport Services implementation could decide to not deliver a
message, either following packet loss or because it has missed a
deadline.  In particular, this can avoid (re-)sending data that
relies on a previous transmission that was never received.
Paragraph (version A):
Transport Services implementations are meant to be flexible at
connection establishment time, considering many different options and
trying to select the most optimal combinations by racing them and
measuring the results (see gathering and racing).  This requires
applications to provide higher-level endpoints than IP addresses,
such as hostnames and URLs, which are used by a Transport Services
implementation for resolution, path selection, and racing.  Transport
Services implementations can further implement fallback mechanisms if
connection establishment of one protocol fails or performance is
detected to be unsatisfactory.
Paragraph (version B):
A Transport Services implementation is intended to be flexible at
connection establishment time, considering many different options and
trying to select the most optimal combinations by racing them and
measuring the results (see gathering and racing).  This requires
applications to provide higher-level endpoints than IP addresses,
such as hostnames and URLs, which are used by a Transport Services
implementation for resolution, path selection, and racing.  An
implementation can further implement fallback mechanisms if
connection establishment of one protocol fails or performance is
detected to be unsatisfactory.
Paragraph (version A):
A goal of the Transport Services architecture is to redefine the
interface between applications and transports in a way that allows
the transport layer to evolve and improve without fundamentally
changing the contract with the application.  This requires a careful
consideration of how to expose the capabilities of protocols.  This
architecture also ecompasses system policies that can influence and
inform how transport protocols use a network path or interface.
Paragraph (version A):
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 can be
added to the system's implementation without requiring changes in
applications for adoption.  Similarly, this can provide a common
basis for utilizing information about a network path or interface,
enabling evolution below the transport layer.
Paragraph (version A):
The normative requirements described in this section allow Transport
Services APIs and Implementations to provide this functionality
without causing incompatibility or introducing security
vulnerabilities.
Paragraph (version B):
A goal of the Transport Services architecture is to redefine the
interface between applications and transports in a way that allows
the transport layer to evolve and improve without fundamentally
changing the contract with the application.  This requires a careful
consideration of how to expose the capabilities of protocols.  This
architecture also encompasses system policies that can influence and
inform how transport protocols use a network path or interface.
Paragraph (version B):
There are several ways the 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 Transport Services API remains the same over
time, new protocols and features can be added to the Transport
Services implementation without requiring changes in applications for
adoption.  Similarly, this can provide a common basis for utilizing
information about a network path or interface, enabling evolution
below the transport layer.
Paragraph (version B):
The normative requirements described in this section allow Transport
Services APIs and Transport Services implementation to provide this
functionality without causing incompatibility or introducing security
vulnerabilities.
Paragraph (version B):
Any functionality that is common across multiple transport protocols
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
transport protocols RFC8923.
Paragraph (version A):
It is RECOMMENDED that the Transport Services API offers properties
that are common to multiple transport protocols.  This enables the
system to appropriately select between protocols that offer
equivalent features.  Similarly, it is RECOMMENDED that the
Properties offered by the Transport Services are applicable to a
variety of network layer interfaces and paths, which permits racing
of different network paths without affecting the applications using
the system.  Each is expected to have a default value.
Paragraph (version B):
It is RECOMMENDED that the Transport Services API offers properties
that are common to multiple transport protocols.  This enables a
Transport Services implementation to appropriately select between
protocols that offer equivalent features.  Similarly, it is
RECOMMENDED that the Properties offered by the Transport Services API
are applicable to a variety of network layer interfaces and paths,
which permits racing of different network paths without affecting the
applications using the API.  Each is expected to have a default
value.
Paragraph (version A):
Applications using a Transport Services system interface are REQUIRED
to be robust to the automated selection provided by the system.  This
automated selection is constrained by the properties and preferences
expressed by the application and requires applications to explictly
set properties that define any necssary constraints on protocol,
path, and interface selection.
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.  It is therefore RECOMMENDED that
a Transport Services system permit more specialized protocol features
to be used.
Paragraph (version B):
Applications using the Transport Services API are REQUIRED to be
robust to the automated selection provided by the Transport Services
implementation.  This automated selection is constrained by the
properties and preferences expressed by the application and requires
applications to explictly set properties that define any necssary
constraints on protocol, path, and interface selection.
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.  It is therefore RECOMMENDED that
the Transport Services API and the Transport Services implementation
permit more specialized protocol features to be used.
Paragraph (version A):
Other specialized features, however, can be strictly required by an
application and thus constrain the set of protocols that can be used.
For example, if an application requires support for automatic
handover or failover for a connection, only protocol stacks that
provide this feature are eligible to be used, e.g., protocol stacks
that include a multipath protocol or a protocol that supports
connection migration.  A Transport Services API needs to 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, can be strictly required by an
application and thus constrain the set of protocols that can be used.
For example, if an application requires support for automatic
handover or failover for a connection, only protocol stacks that
provide this feature are eligible to be used, e.g., protocol stacks
that include a multipath protocol or a protocol that supports
connection migration.  A Transport Services API needs to allow
applications to define such requirements and constrain the options
available to a Transport Services implementation.  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):
To ensure that security protocols are not incorrectly swapped,
Transport Services systems MUST only select Protocol Stacks that meet
application requirements (RFC8922).  Systems SHOULD only race
Protocol Stacks where the transport security protocols within the
stacks are identical.  Transport Services systems MUST NOT
automatically fall back from secure protocols to insecure protocols,
or to weaker versions of secure protocols.  A Transport Services
system MAY allow applications to explicitly specify that fallback to
a specific other version of a protocol is allowed, e.g., to allow
fallback to TLS 1.2 if TLS 1.3 is not available.
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 define new protocols or protocol capabilities that affect what
is communicated across the network.  Use of a Transport Services
system MUST NOT require that a peer on the other side of a connection
uses the same API or implementation.  A Transport Services system
acting as a connection initiator is able to communicate with any
existing system that implements the transport protocol(s) and all the
required properties 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 that implement the protocol, independent of
whether the initiator uses a Transport Services system or not.
Paragraph (version A):
The Transport Services system makes decisions that select protocols
and interfaces.  In normal use, a Transport Services system SHOULD
result in consistent protocol and interface selection decisions for
the same network conditions given the same set of Properties.  This
is intended to provide predictable outcomes to the application using
the API.
Paragraph (version A):
This section and the remainder of this document describe the
architecture non-normatively.  The concepts defined in this document
are intended primarily for use in the documents and specifications
that describe the Transport Services architecture and API.  While the
specific terminology can be used in some implementations, it is
expected that there will remain a variety of terms used by running
code.
Paragraph (version A):
System-implementation concepts, which are intended to be
internally used when building systems that implement Transport
Services.
Paragraph (version B):
To ensure that security protocols are not incorrectly swapped, a
Transport Services implementation MUST only select Protocol Stacks
that meet application requirements (RFC8922).  A Transport Services
implementation SHOULD only race Protocol Stacks where the transport
security protocols within the stacks are identical.  A Transport
Services implementation MUST NOT automatically fall back from secure
protocols to insecure protocols, or to weaker versions of secure
protocols.  A Transport Services implementation MAY allow
applications to explicitly specify that fallback to a specific other
version of a protocol \, e.g., to allow fallback to TLS 1.2 if TLS
1.3 is not available.
Paragraph (version B):
It is important to note that neither the Transport Services API I-
D.ietf-taps-interface nor the guidelines for the Transport Service
implementation I-D.ietf-taps-impl define new protocols or protocol
capabilities that affect what is communicated across the network.  A
Transport Services system MUST NOT require that a peer on the other
side of a connection uses the same API or implementation.  A
Transport Services implementation acting as a connection initiator is
able to communicate with any existing endpoint that implements the
transport protocol(s) and all the required properties selected.
Similarly, a Transport Services implementation acting as a listener
can receive connections for any protocol that is supported from an
existing initiator that implements the protocol, independent of
whether the initiator uses the Transport Services architecture or
not.
Paragraph (version B):
A Transport Services system makes decisions that select protocols and
interfaces.  In normal use, a Transport Services system SHOULD result
in consistent protocol and interface selection decisions for the same
network conditions given the same set of Properties.  This is
intended to provide predictable outcomes to the application using the
API.
Paragraph (version B):
This section and the remainder of this document describe the
architecture non-normatively.  The concepts defined in this document
are intended primarily for use in the documents and specifications
that describe the Transport Services system.  This includes the
architecture, the Transport Services API and the associated Transport
Services implementation.  While the specific terminology can be used
in some implementations, it is expected that there will remain a
variety of terms used by running code.
Paragraph (version B):
System-implementation concepts, which are intended to be
internally used by aTransport Services implementation.
Paragraph (version A):
Selection Properties (preestablishment) that can only be
specified on a Preconnection.
Paragraph (version A):
Connection Properties (preestablishment) that can be specified
on a Preconnection and changed on the Connection.
Paragraph (version A):
Message Properties (datatransfer) that can be specified as
defaults on a Preconnection or a Connection, and can also be
specified during data transfer to affect specific Messages.
Paragraph (version B):
Selection Properties (preestablishment): Selection Properties
can only be specified on a Preconnection.
Paragraph (version B):
Connection Properties (preestablishment): Connection Properties
can be specified on a Preconnection and changed on the
Connection.
Paragraph (version B):
Message Properties (datatransfer): Message Properties can be
specified as defaults on a Preconnection or a Connection, and
can also be specified during data transfer to affect specific
Messages.
Paragraph (version A):
Listener: A Listener object accepts incoming transport protocol
connections from remote systems and generates corresponding
Connection objects.  It is created from a Preconnection object
that specifies the type of incoming Connections it will accept.
Paragraph (version B):
Listener: A Listener object accepts incoming transport protocol
connections from Remote Endpoints and generates corresponding
Connection objects.  It is created from a Preconnection object
that specifies the type of incoming Connections it will accept.
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.  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.
Paragraph (version B):
Message: A Message object is a unit of data that can be
represented as bytes that can be transferred between two endpoints
over a transport connection.  The bytes within a Message are
assumed to be ordered.  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.
Paragraph (version A):
Send: The action to transmit a Message over a Connection to the
remote system.  The interface to Send can accept Message
Properties specific to how the Message content is to be sent.  The
status of the Send operation is delivered back to the sending
application in an event (events).
Paragraph (version A):
Receive: An action that indicates that the application is ready to
asynchronously accept a Message over a Connection from a remote
system, while the Message content itself will be delivered in an
event (events).  The interface to Receive can include Message
Properties specific to the Message that is to be delivered to the
application.
Paragraph (version A):
Framer: A Framer is a data translation layer that can be added to
a Connection to define how application-layer Messages are
transmitted over a transport protocol.  This is particularly
relevant for protocols that otherwise present unstructured
streams, such as TCP.
Paragraph (version B):
Send: The action to transmit a Message over a Connection to the
Remote Endpoint.  The interface to Send can accept Message
Properties specific to how the Message content is to be sent.  The
status of the Send operation is delivered back to the sending
application in an Event (events).
Paragraph (version B):
Receive: An action that indicates that the application is ready to
asynchronously accept a Message over a Connection from a Remote
Endpoint, while the Message content itself will be delivered in an
Event (events).  The interface to Receive can include Message
Properties specific to the Message that is to be delivered to the
application.
Paragraph (version B):
Framer: A Framer is a data translation layer that can be added to
a Connection to define how application-layer Messages are
transmitted over a transport stack.  This is particularly relevant
when using a protocol that otherwise presents unstructured
streams, such as TCP.
Paragraph (version A):
Message Sent: Notifies the application of the status of its Send
action.  This might indicate a failure if the Message cannot be
sent, or an indication that the Message has been processed by the
protocol stack.
Paragraph (version A):
Path Properties Changed: Notifies the application that some
property of the Connection has changed that might influence how
and where data is sent and/or received.
Paragraph (version A):
Abort: The action the application takes on a Connection to
indicate a Close and also indicate that the Transport Services
system should not attempt to deliver any outstanding data, and
immediately drop the connection.  This is intended for immediate,
usually abnormal, termination of a connection.
Paragraph (version B):
Message Sent: Notifies the application of the status of its Send
action.  This might indicate a failure if the Message cannot be
sent, or an indication that the Message has been processed by the
Transport Services system.
Paragraph (version B):
Path Properties Changed: Notifies the application that a property
of the Connection has changed that might influence how and where
data is sent and/or received.
Paragraph (version B):
Abort: The action the application takes on a Connection to
indicate a Close and also indicate that a Transport Services
system should not attempt to deliver any outstanding data, and
immediately drop the connection.  This is intended for immediate,
usually abnormal, termination of a connection.
Paragraph (version A):
A Connection Group is a set of Connections that shares properties and
caches.  A 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.
Paragraph (version B):
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.
Paragraph (version A):
While Connection Groups are managed by the transport system, an
application can define Connection Contexts to control caching
boundaries, as discussed in conn-context.
Paragraph (version A):
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 A):
Path: Represents an available set of properties that a local
system can use to communicate with a remote system, such as
routes, addresses, and physical and virtual network interfaces.
Paragraph (version B):
While Connection Groups are managed by the Transport Services system,
an application can define Connection Contexts to control caching
boundaries, as discussed in conn-context.
Paragraph (version B):
This section defines the key concepts of the Transport Services
architecture.
Paragraph (version B):
Transport Service implementaion: This consists of all objects and
protocol instances 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):
Transport Service system: This consists of the Transport Service
implementaion and the Transport Services API.
Paragraph (version B):
Path: Represents an available set of properties that a local
endpoint can use to communicate with a Remote Endpoint, such as
routes, addresses, and physical and virtual network interfaces.
Paragraph (version A):
Candidate Path Selection: Candidate Path Selection represents the
act of choosing one or more paths that are available to use based
on the Selection Properties and any available Local and Remote
Endpoints provided by the application, as well as the policies and
heuristics of a Transport Services system.
Paragraph (version A):
Candidate Protocol Selection: Candidate Protocol Selection
represents the act of choosing one or more sets of Protocol Stacks
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 B):
Candidate Path Selection: Candidate Path Selection represents the
act of choosing one or more paths that are available to use based
on the Selection Properties and any available Local and Remote
Endpoints provided by the application, as well as the policies and
heuristics of a Transport Services implementation.
Paragraph (version B):
Candidate Protocol Selection: Candidate Protocol Selection
represents the act of choosing one or more sets of Protocol Stacks
that are available to use based on the Transport Properties
provided by the application, and the heuristics or policies within
the Transport Services implementation.
Paragraph (version A):
The Transport Services architecture does not recommend use of
specific security protocols or algorithms.  Its goal is to offer ease
of use for existing protocols by providing a generic security-related
interface.  Each provided interface translates to an existing
protocol-specific interface provided by supported security protocols.
For example, trust verification callbacks are common parts of TLS
APIs.  Transport Services APIs will expose similar functionality
RFC8922.
Paragraph (version A):
As described above in equivalence, if a Transport Services system
races between two different Protocol Stacks, both need to use the
same security protocols and options.  However, a Transport Services
system can race different security protocols, e.g., if the
application explicitly specifies that it considers them equivalent.
Paragraph (version A):
Whether information from previous racing attempts, or other
information cached by the Transport Services implementation about
past communications, is used during establishment is under
application control.  This allows applications to make tradeoffs
between efficiency (through racing) and privacy (via information that
might leak from the cache toward an on-path observer).  Some
applications have native concepts (e.g. "incognito mode") that align
with this functionality.
Paragraph (version B):
The Transport Services architecture does not recommend use of
specific security protocols or algorithms.  Its goal is to offer ease
of use for existing protocols by providing a generic security-related
interface.  Each provided interface translates to an existing
protocol-specific interface provided by supported security protocols.
For example, trust verification callbacks are common parts of TLS
APIs; a Transport Services API exposes similar functionality RFC8922.
Paragraph (version B):
As described above in equivalence, if a Transport Services
implementation races between two different Protocol Stacks, both need
to use the same security protocols and options.  However, a Transport
Services implementation can race different security protocols, e.g.,
if the application explicitly specifies that it considers them
equivalent.
Paragraph (version B):
The application controls whether information from previous racing
attempts, or other information about past communications that was
cached by the Transport Services system is used during establishment.
This allows applications to make tradeoffs between efficiency
(through racing) and privacy (via information that might leak from
the cache toward an on-path observer).  Some applications have native
concepts (e.g. "incognito mode") that align with this functionality.
Paragraph (version B):
A Transport Services system must not automatically fall back from
secure protocols to insecure protocols, or to weaker versions of
secure protocols (see equivalence).  For example, if an application
requests a specific version of TLS, but the desired version of TLS is
not available, its connection will fail.  Applications are thus
responsible for implementing security protocol fallback or version
fallback by creating multiple Connections, if so desired.