Draft: draft-ietf-taps-interface

Commentary: Align with Architecture on Transport Services 
 This is a request for a PR to align the API to this , and related Transport Services API : The application interface ( not the word interface where we can avoid this , to avoid confusion with network interfaces ) Transport Services implementation : The library / code below the API Transport Services system : The entire package of API and implementation Transport Services architecture .
Paragraph (version A):
This document specifies an abstract application programming interface
(API) that specifies the interface component of the high-level
architecture for transport services defined in I-D.ietf-taps-arch.
The Transport Services Architecture supports asynchronous, atomic
transmission of messages over transport protocols and network paths
dynamically selected at runtime, in environments where an endpoint
selects from multiple interfaces and potential transport protocols.
Paragraph (version A):
Applications that adopt this interface will benefit from a wide set
of transport features that can evolve over time.  This protocol-
independent API ensures 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, and can support applications by offering racing and
fallback mechanisms, which otherwise need to be separately
implemented in each application.
Paragraph (version B):
This document specifies an abstract application programming interface
(API) that specifies the interface component of the high-level
Transport Services architecture defined in I-D.ietf-taps-arch.  A
Transport Services system supports asynchronous, atomic transmission
of messages over transport protocols and network paths dynamically
selected at runtime, in environments where an endpoint selects from
multiple interfaces and potential transport protocols.
Paragraph (version B):
Applications that adopt this API will benefit from a wide set of
transport features that can evolve over time.  This protocol-
independent API ensures that the system providing the API 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, and can support applications by offering racing and
fallback mechanisms, which otherwise need to be separately
implemented in each application.
Paragraph (version A):
This API derives specific path and protocol selection properties and
supported transport features from the analysis provided in RFC8095,
RFC8923, and RFC8922.  The design encourages implementations that
provide the interface to dynamically choose a transport protocol
rather than statically binding applications to a protocol at compile
time.  Nevertheless, the Transport Services API also provides
applications with a way to override transport selection and
instantiate a specific stack, e.g., to support servers wishing to
listen to a specific protocol.  However, forcing a specific transport
stack choice is discouraged for general use, because it can reduce
portability.
Paragraph (version B):
The Transport Services system derives specific path and protocol
selection properties and supported transport features from the
analysis provided in RFC8095, RFC8923, and RFC8922.  The Transport
Services API enables an implementation to dynamically choose a
transport protocol rather than statically binding applications to a
protocol at compile time.  The Transport Services API also provides
applications with a way to override transport selection and
instantiate a specific stack, e.g., to support servers wishing to
listen to a specific protocol.  However, forcing a choice to use a
specific transport stack is discouraged for general use, because it
can reduce portability.
Paragraph (version A):
Actions associated with no Object are Actions on the abstract
interface itself; they are equivalent to Actions on a per-application
global context.
Paragraph (version B):
Actions associated with no Object are Actions on the API; they are
equivalent to Actions on a per-application global context.
Paragraph (version A):
Access to a variety of transport protocols, independent of the
Protocol Stacks that will be used at runtime.  All common features
of these protocol stacks are made available to the application in
a transport-independent way to the degree possible.  This enables
applications written to a single API to make use of transport
protocols in terms of the features they provide.
Paragraph (version A):
A unified interface to datagram and stream-oriented transports,
allowing use of a common API for connection establishment and
closing.
Paragraph (version B):
A Transport Services system can offer a variety of transport
protocols, independent of the Protocol Stacks that will be used at
runtime.  All common features of these protocol stacks are made
available to the application in a transport-independent way to the
degree possible.  This enables applications written to a single
API to make use of transport protocols in terms of the features
they provide.
Paragraph (version B):
A unified API to datagram and stream-oriented transports, allowing
use of a common API for connection establishment and closing.
Paragraph (version A):
Once a Connection is established, data can be sent and received on it
in the form of Messages.  The interface supports the preservation of
message boundaries both via explicit Protocol Stack support, and via
application support through a Message Framer that finds message
boundaries in a stream.  Messages are received asynchronously through
event handlers registered by the application.  Errors and other
notifications also happen asynchronously on the Connection.  It is
not necessary for an application to handle all Events; some Events
may have implementation-specific default handlers.  The application
should not assume that ignoring Events (e.g., Errors) is always safe.
Paragraph (version B):
Once a Connection is established, data can be sent and received on it
in the form of Messages.  The API supports the preservation of
message boundaries both via explicit Protocol Stack support, and via
application support through a Message Framer that finds message
boundaries in a stream.  Messages are received asynchronously through
event handlers registered by the application.  Errors and other
notifications also happen asynchronously on the Connection.  It is
not necessary for an application to handle all Events; some Events
may have implementation-specific default handlers.  The application
should not assume that ignoring Events (e.g., Errors) is always safe.
Paragraph (version A):
This is an example of how an application might listen for incoming
Connections using the Transport Services Interface, and receive a
request, and send a response.
Paragraph (version A):
This is an example of how an application might open two Connections
to a remote application using the Transport Services Interface, and
send a request as well as receive a response on each of them.
Paragraph (version B):
This is an example of how an application might listen for incoming
Connections using the Transport Services API, and receive a request,
and send a response.
Paragraph (version B):
This is an example of how an application might open two Connections
to a remote application using the Transport Services API, and send a
request as well as receive a response on each of them.
Paragraph (version A):
Each application using the Transport Services Interface declares its
preferences for how the transport service should operate.  This is
done by using Transport Properties, as defined in I-D.ietf-taps-arch,
at each stage of the lifetime of a connection.
Paragraph (version B):
Each application using the Transport Services API declares its
preferences for how the Transport Services system should operate.
This is done by using Transport Properties, as defined in I-D.ietf-
taps-arch, at each stage of the lifetime of a connection.
Paragraph (version A):
Allowing different components of a TAPS implementation to pass
Transport Properties, e.g., between a language frontend and a
policy manager, or as a representation of properties retrieved
from a file or other storage.
Paragraph (version A):
Making the code of different TAPS implementations look similar.
While individual programming languages may preclude strict
adherence to the aforementioned naming convention (for instance,
by prohibiting the use of hyphens in symbols), users interacting
with multiple implementations will still benefit from the
consistency resulting from the use of visually similar symbols.
Paragraph (version B):
Allowing different components of a Transport Services
implementation to pass Transport Properties, e.g., between a
language frontend and a policy manager, or as a representation of
properties retrieved from a file or other storage.
Paragraph (version B):
Making the code of different Transport Services implementations
look similar.  While individual programming languages may preclude
strict adherence to the aforementioned naming convention (for
instance, by prohibiting the use of hyphens in symbols), users
interacting with multiple implementations will still benefit from
the consistency resulting from the use of visually similar
symbols.
Paragraph (version A):
This document defines a language- and platform-independent interface
to a Transport Services system.  Given the wide variety of languages
and language conventions used to write applications that use the
transport layer to connect to other applications over the Internet,
this independence makes this interface necessarily abstract.
Paragraph (version A):
There is no interoperability benefit in tightly defining how the
interface is presented to application programmers across diverse
platforms.  However, maintaining the "shape" of the abstract
interface across different platforms reduces the effort for
programmers who learn the transport services interface to then apply
their knowledge to another platform.
Paragraph (version A):
Actions, Events, and Errors in implementations of this interface
SHOULD use the names given for them in the document, subject to
capitalization, punctuation, and other typographic conventions in
the language of the implementation, unless the implementation
itself uses different names for substantially equivalent objects
for networking by convention.
Paragraph (version A):
Implementations of this interface SHOULD implement each Selection
Property, Connection Property, and Message Context Property
specified in this document.  Each interface SHOULD be implemented
even when in a specific implementation/platform it will always
result in no operation, e.g. there is no action when the API
specifies a Property that is not available in a transport protocol
implemented on a specific platform.  For example, if TCP is the
only underlying transport protocol, the Message Property
"msgOrdered" can be implemented (trivially, as a no-op) as
disabling the requirement for ordering will not have any effect on
delivery order for Connections over TCP.  Similarly, the "msg-
lifetime" Message Property can be implemented but ignored, as the
description of this Property states that "it is not guaranteed
that a Message will not be sent when its Lifetime has expired".
Paragraph (version B):
This document defines a language- and platform-independent API of a
Transport Services system.  Given the wide variety of languages and
language conventions used to write applications that use the
transport layer to connect to other applications over the Internet,
this independence makes this API necessarily abstract.
Paragraph (version B):
There is no interoperability benefit in tightly defining how the API
is presented to application programmers across diverse platforms.
However, maintaining the "shape" of the abstract API across different
platforms reduces the effort for programmers who learn to use the
Transport Services API to then apply their knowledge to another
platform.
Paragraph (version B):
Actions, Events, and Errors in implementations of the Transport
Services API SHOULD use the names given for them in the document,
subject to capitalization, punctuation, and other typographic
conventions in the language of the implementation, unless the
implementation itself uses different names for substantially
equivalent objects for networking by convention.
Paragraph (version B):
Transport Services systems SHOULD implement each Selection
Property, Connection Property, and Message Context Property
specified in this document.  The Transport Services API SHOULD be
implemented even when in a specific implementation/platform it
will always result in no operation, e.g. there is no action when
the API specifies a Property that is not available in a transport
protocol implemented on a specific platform.  For example, if TCP
is the only underlying transport protocol, the Message Property
"msgOrdered" can be implemented (trivially, as a no-op) as
disabling the requirement for ordering will not have any effect on
delivery order for Connections over TCP.  Similarly, the "msg-
lifetime" Message Property can be implemented but ignored, as the
description of this Property states that "it is not guaranteed
that a Message will not be sent when its Lifetime has expired".
Paragraph (version A):
The Transport Services API resolves names internally, when the
Initiate(), Listen(), or Rendezvous() method is called to establish a
Connection.  Privacy considerations for the timing of this resolution
are given in privacy-security.
Paragraph (version B):
The Transport Services system resolves names internally, when the
Initiate(), Listen(), or Rendezvous() method is called to establish a
Connection.  Privacy considerations for the timing of this resolution
are given in privacy-security.
Paragraph (version A):
Specifying a multicast group address on a Local Endpoint will
indicate to the transport system that the resulting connection will
be used to receive multicast messages.  The Remote Endpoint can be
used to filter incoming multicast from specific senders.  Such a
Preconnection will only support calling Listen(), not Initiate().
Calling Listen() will cause the Transport Services system to register
for receiving multicast, such as issuing an IGMP join RFC3376 or
using MLD for IPV6 RFC4604.  Any Connections that are accepted from
this Listener are receive-only.
Paragraph (version B):
Specifying a multicast group address on a Local Endpoint will
indicate to the Transport Services system that the resulting
connection will be used to receive multicast messages.  The Remote
Endpoint can be used to filter incoming multicast from specific
senders.  Such a Preconnection will only support calling Listen(),
not Initiate().  Calling Listen() will cause the Transport Services
system to register for receiving multicast, such as issuing an IGMP
join RFC3376 or using MLD for IPV6 RFC4604.  Any Connections that are
accepted from this Listener are receive-only.
Paragraph (version A):
An implementation of this interface must provide sensible defaults
for Selection Properties.  The default values for each property below
represent a configuration that can be implemented over TCP.  If these
default values are used and TCP is not supported by a Transport
Services implementation, then an application using the default set of
Properties might not succeed in establishing a connection.  Using the
same default values for independent Transport Services
implementations can be beneficial when applications are ported
between different implementations/platforms, even if this default
could lead to a connection failure when TCP is not available.  If
default values other than those suggested below are used, it is
RECOMMENDED to clearly document any differences.
Paragraph (version B):
An implementation of the Transport Services API must provide sensible
defaults for Selection Properties.  The default values for each
property below represent a configuration that can be implemented over
TCP.  If these default values are used and TCP is not supported by a
Transport Services system, then an application using the default set
of Properties might not succeed in establishing a connection.  Using
the same default values for independent Transport Services
implementations can be beneficial when applications are ported
between different implementations/platforms, even if this default
could lead to a connection failure when TCP is not available.  If
default values other than those suggested below are used, it is
RECOMMENDED to clearly document any differences.
Paragraph (version A):
A Transport Services system can request a protocol that supports
sending keep alive packets keep-alive.  This property specifies the
maximum length of time an idle connection (one for which no transport
packets have been sent) should wait before the Local Endpoint sends a
keep-alive packet to the Remote Endpoint.  Adjusting this Property
will only take effect when the underlying stack supports sending
keep-alive packets.  Guidance on setting this value for datagram
transports is provided in RFC8085.  A value greater than the
connection timeout (conn-timeout), or the special value "Disabled",
will disable the sending of keep-alive packets.
Paragraph (version B):
A Transport Services API can request a protocol that supports sending
keep alive packets keep-alive.  This property specifies the maximum
length of time an idle connection (one for which no transport packets
have been sent) should wait before the Local Endpoint sends a keep-
alive packet to the Remote Endpoint.  Adjusting this Property will
only take effect when the underlying stack supports sending keep-
alive packets.  Guidance on setting this value for datagram
transports is provided in RFC8085.  A value greater than the
connection timeout (conn-timeout), or the special value "Disabled",
will disable the sending of keep-alive packets.
Paragraph (version A):
This property specifies the desired network treatment for traffic
sent by the application and the tradeoffs the application is prepared
to make in path and protocol selection to receive that desired
treatment.  When the capacity profile is set to a value other than
Default, the Transport Services system SHOULD select paths and
configure protocols to optimize the tradeoff between delay, delay
variation, and efficient use of the available capacity based on the
capacity profile specified.  How this is realized is implementation-
specific.  The Capacity Profile MAY also be used to set markings on
the wire for Protocol Stacks supporting this.  Recommendations for
use with DSCP are provided below for each profile; note that when a
Connection is multiplexed, the guidelines in Section 6 of RFC7657
apply.
Paragraph (version B):
This property specifies the desired network treatment for traffic
sent by the application and the tradeoffs the application is prepared
to make in path and protocol selection to receive that desired
treatment.  When the capacity profile is set to a value other than
Default, z Transport Services system SHOULD select paths and
configure protocols to optimize the tradeoff between delay, delay
variation, and efficient use of the available capacity based on the
capacity profile specified.  How this is realized is implementation-
specific.  The Capacity Profile MAY also be used to set markings on
the wire for Protocol Stacks supporting this.  Recommendations for
use with DSCP are provided below for each profile; note that when a
Connection is multiplexed, the guidelines in Section 6 of RFC7657
apply.
Paragraph (version A):
The application provides no information about its expected
capacity profile.  Transport Services system implementations that
map the requested capacity profile onto per-connection DSCP
signaling SHOULD assign the DSCP Default Forwarding RFC2474 Per
Hop Behaviour (PHB).
Paragraph (version A):
The application is not interactive.  It expects to send and/or
receive data without any urgency.  This can, for example, be used
to select protocol stacks with scavenger transmission control and/
or to assign the traffic to a lower-effort service.  Transport
Services system implementations that map the requested capacity
profile onto per-connection DSCP signaling SHOULD assign the DSCP
Less than Best Effort RFC8622 PHB.
Paragraph (version B):
The application provides no information about its expected
capacity profile.  Transport Services implementations that map the
requested capacity profile onto per-connection DSCP signaling
SHOULD assign the DSCP Default Forwarding RFC2474 Per Hop
Behaviour (PHB).
Paragraph (version B):
The application is not interactive.  It expects to send and/or
receive data without any urgency.  This can, for example, be used
to select protocol stacks with scavenger transmission control and/
or to assign the traffic to a lower-effort service.  Transport
Services implementations that map the requested capacity profile
onto per-connection DSCP signaling SHOULD assign the DSCP Less
than Best Effort RFC8622 PHB.
Paragraph (version A):
The application is interactive, and prefers loss to latency.
Response time should be optimized at the expense of delay
variation and efficient use of the available capacity when sending
on this connection.  This can be used by the system to disable the
coalescing of multiple small Messages into larger packets (Nagle's
algorithm); to prefer immediate acknowledgment from the peer
endpoint when supported by the underlying transport; and so on.
Transport Services system implementations that map the requested
capacity profile onto per-connection DSCP signaling without
multiplexing SHOULD assign a DSCP Assured Forwarding
(AF41,AF42,AF43,AF44) RFC2597 PHB.  Inelastic traffic that is
expected to conform to the configured network service rate could
be mapped to the DSCP Expedited Forwarding RFC3246 or RFC5865
PHBs.
Paragraph (version B):
The application is interactive, and prefers loss to latency.
Response time should be optimized at the expense of delay
variation and efficient use of the available capacity when sending
on this connection.  This can be used by the system to disable the
coalescing of multiple small Messages into larger packets (Nagle's
algorithm); to prefer immediate acknowledgment from the peer
endpoint when supported by the underlying transport; and so on.
Transport Services implementations that map the requested capacity
profile onto per-connection DSCP signaling without multiplexing
SHOULD assign a DSCP Assured Forwarding (AF41,AF42,AF43,AF44)
RFC2597 PHB.  Inelastic traffic that is expected to conform to the
configured network service rate could be mapped to the DSCP
Expedited Forwarding RFC3246 or RFC5865 PHBs.
Paragraph (version A):
The application expects to send/receive data at the maximum rate
allowed by its congestion controller over a relatively long period
of time.  Transport Services system implementations that map the
requested capacity profile onto per-connection DSCP signaling
without multiplexing SHOULD assign a DSCP Assured Forwarding
(AF11,AF12,AF13,AF14) RFC2597 PHB per Section 4.8 of RFC4594.
Paragraph (version B):
The application expects to send/receive data at the maximum rate
allowed by its congestion controller over a relatively long period
of time.  Transport Services implementations that map the
requested capacity profile onto per-connection DSCP signaling
without multiplexing SHOULD assign a DSCP Assured Forwarding
(AF11,AF12,AF13,AF14) RFC2597 PHB per Section 4.8 of RFC4594.
Paragraph (version A):
These TCP-specific properties are included here because the feature
"Suggest timeout to the peer" is part of the minimal set of transport
services RFC8923, where this feature was categorized as "functional".
This means that when an implementation offers this feature, it has to
expose an interface to it to the application.  Otherwise, the
implementation might violate assumptions by the application, which
could cause the application to fail.
Paragraph (version B):
These TCP-specific properties are included here because the feature
"Suggest timeout to the peer" is part of the minimal set of transport
services RFC8923, where this feature was categorized as "functional".
This means that when an Transport Services implementation offers this
feature, the Transport Services API has to expose an interface to the
application.  Otherwise, the implementation might violate assumptions
by the application, which could cause the application to fail.
Paragraph (version A):
The Lifetime specifies how long a particular Message can wait to be
sent to the Remote Endpoint before it is irrelevant and no longer
needs to be (re-)transmitted.  This is a hint to the Transport
Services system - it is not guaranteed that a Message will not be
sent when its Lifetime has expired.
Paragraph (version B):
The Lifetime specifies how long a particular Message can wait to be
sent to the Remote Endpoint before it is irrelevant and no longer
needs to be (re-)transmitted.  This is a hint to the Transport
Services implementation - it is not guaranteed that a Message will
not be sent when its Lifetime has expired.
Paragraph (version A):
Like all Actions in this interface, the Send Action is asynchronous.
There are several Events that can be delivered in response to Sending
a Message.  Exactly one Event (Sent, Expired, or SendError) will be
delivered in response to each call to Send.
Paragraph (version B):
Like all Actions in Transport Services API, the Send Action is
asynchronous.  There are several Events that can be delivered in
response to Sending a Message.  Exactly one Event (Sent, Expired, or
SendError) will be delivered in response to each call to Send.
Paragraph (version A):
The interface should allow the application to correlate which Send
Action resulted in a particular Send Event.  The manner in which this
correlation is indicated is implementation-specific.
Paragraph (version A):
The Sent Event occurs when a previous Send Action has completed,
i.e., when the data derived from the Message has been passed down or
through the underlying Protocol Stack and is no longer the
responsibility of this interface.  The exact disposition of the
Message (i.e., whether it has actually been transmitted, moved into a
buffer on the network interface, moved into a kernel buffer, and so
on) when the Sent Event occurs is implementation-specific.  The Sent
Event contains a reference to the Message Context of the Message to
which it applies.
Paragraph (version B):
The Transport Services API should allow the application to correlate
which Send Action resulted in a particular Send Event.  The manner in
which this correlation is indicated is implementation-specific.
Paragraph (version B):
The Sent Event occurs when a previous Send Action has completed,
i.e., when the data derived from the Message has been passed down or
through the underlying Protocol Stack and is no longer the
responsibility of the Transport Services API.  The exact disposition
of the Message (i.e., whether it has actually been transmitted, moved
into a buffer on the network interface, moved into a kernel buffer,
and so on) when the Sent Event occurs is implementation-specific.
The Sent Event contains a reference to the Message Context of the
Message to which it applies.
Paragraph (version A):
The Transport Services interface provides two properties to allow a
sender to signal the relative priority of data transmission: the
Priority Message Property msg-priority, and the Connection Priority
Connection Property conn-priority.  These properties are designed to
allow the expression and implementation of a wide variety of
approaches to transmission priority in the transport and application
layer, including those which do not appear on the wire (affecting
only sender-side transmission scheduling) as well as those that do
(e.g.  I-D.ietf-httpbis-priority.
Paragraph (version B):
The Transport Services API provides two properties to allow a sender
to signal the relative priority of data transmission: the Priority
Message Property msg-priority, and the Connection Priority Connection
Property conn-priority.  These properties are designed to allow the
expression and implementation of a wide variety of approaches to
transmission priority in the transport and application layer,
including those which do not appear on the wire (affecting only
sender-side transmission scheduling) as well as those that do (e.g.
I-D.ietf-httpbis-priority.
Paragraph (version A):
The Transport Services interface does order Connection Priority over
the Priority Message Property.  In the absense of other externalities
(e.g., transport-layer flow control), a priority 1 Message on a
priority 0 Connection will be sent before a priority 0 Message on a
priority 1 Connection in the same group.
Paragraph (version B):
The Transport Services API does order Connection Priority over the
Priority Message Property.  In the absense of other externalities
(e.g., transport-layer flow control), a priority 1 Message on a
priority 0 Connection will be sent before a priority 0 Message on a
priority 1 Connection in the same group.
Paragraph (version A):
Note that maxLength does not guarantee that the application will
receive that many bytes if they are available; the interface could
return ReceivedPartial events with less data than maxLength according
to implementation constraints.  Note also that maxLength and
minIncompleteLength are intended only to manage buffering, and are
not interpreted as a receiver preference for message reordering.
Paragraph (version B):
Note that maxLength does not guarantee that the application will
receive that many bytes if they are available; the Transport Services
API could return ReceivedPartial events with less data than maxLength
according to implementation constraints.  Note also that maxLength
and minIncompleteLength are intended only to manage buffering, and
are not interpreted as a receiver preference for message reordering.
Paragraph (version A):
The interface should allow the application to correlate which call to
Receive resulted in a particular Receive Event.  The manner in which
this correlation is indicated is implementation-specific.
Paragraph (version B):
The Transport Services API should allow the application to correlate
which call to Receive resulted in a particular Receive Event.  The
manner in which this correlation is indicated is implementation-
specific.
Paragraph (version A):
This interface is designed to be independent of an implementation's
concurrency model.  The details of how exactly actions are handled,
and how events are dispatched, are implementation dependent.
Paragraph (version B):
This Transport Services API is designed to be independent of an
implementation's concurrency model.  The details of how exactly
actions are handled, and how events are dispatched, are
implementation dependent.
Paragraph (version A):
No events will occur on a Connection after it is Closed; i.e.,
after a Closed<> event, an EstablishmentError<> or
ConnectionError<> will not occur on that connection.  To ensure
this ordering, Closed<> will not occur on a Connection while other
events on the Connection are still locally outstanding (i.e.,
known to the interface and waiting to be dealt with by the
application).
Paragraph (version B):
No events will occur on a Connection after it is Closed; i.e.,
after a Closed<> event, an EstablishmentError<> or
ConnectionError<> will not occur on that connection.  To ensure
this ordering, Closed<> will not occur on a Connection while other
events on the Connection are still locally outstanding (i.e.,
known to the Transport Services API and waiting to be dealt with
by the application).
Paragraph (version A):
This document describes a generic API for interacting with a
transport services (TAPS) system.  Part of this API includes
configuration details for transport security protocols, as discussed
in security-parameters.  It does not recommend use (or disuse) of
specific algorithms or protocols.  Any API-compatible transport
security protocol ought to work in a TAPS system.  Security
considerations for these protocols are discussed in the respective
specifications.
Paragraph (version B):
This document describes a generic API for interacting with a
Transport Services system.  Part of this API includes configuration
details for transport security protocols, as discussed in security-
parameters.  It does not recommend use (or disuse) of specific
algorithms or protocols.  Any API-compatible transport security
protocol ought to work in a Transport Services system.  Security
considerations for these protocols are discussed in the respective
specifications.
Paragraph (version A):
The interface explicitly does not require the application to resolve
names, though there is a tradeoff between early and late binding of
addresses to names.  Early binding allows the API implementation to
reduce connection setup latency, at the cost of potentially limited
scope for alternate path discovery during Connection establishment,
as well as potential additional information leakage about application
interest when used with a resolution method (such as DNS without TLS)
which does not protect query confidentiality.
Paragraph (version B):
The Transport Services API explicitly does not require the
application to resolve names, though there is a tradeoff between
early and late binding of addresses to names.  Early binding allows
the API implementation to reduce connection setup latency, at the
cost of potentially limited scope for alternate path discovery during
Connection establishment, as well as potential additional information
leakage about application interest when used with a resolution method
(such as DNS without TLS) which does not protect query
confidentiality.
Paragraph (version A):
application itself.  The TAPS API is designed such that protocol and
path selection can be limited to a small and controlled set if
required by the application for functional or security purposes.