Draft: draft-ietf-taps-arch

Commentary: Note that Security Considerations and Acknowledgments changes are newline - rewrap only .
Paragraph (version A):
This document provides an overview of the architecture of Transport
Services, a model for exposing transport protocol features to
applications for network communication.  In contrast to what is
provided by most existing Application Programming Interfaces (APIs),
Transport Services is based on an asynchronous, event-driven
interaction pattern; it uses messages for representing data transfer
to applications; and it assumes an implementation that can use
multiple IP addresses, multiple protocols, and multiple paths, and
provide multiple application streams.  This document further defines
the common set of terminology and concepts to be used in definitions
of Transport Services APIs and implementations.
Paragraph (version B):
This document proposal an architecture for exposing transport
protocol features to applications for network communication, the
Transport Services architecture.  In contrast to what is provided by
most existing Application Programming Interfaces (APIs), Transport
Services is based on an asynchronous, event-driven interaction
pattern; it uses messages for representing data transfer to
applications; and it assumes an implementation that can use multiple
IP addresses, multiple protocols, 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 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 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 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 in that document 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):
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 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: this implies that a Transport
Services system MUST be deployable on only one side of a connection.
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):
Remote Endpoint: The Remote Endpoint represents the application's
identifier for a peer that can participate in a transport
connection.  For example, the combination of a DNS name for the
peer and a service name/port.
Paragraph (version A):
Local Endpoint: The Local Endpoint represents the application's
identifier for itself that it uses for transport connections.  For
example, a local IP address and port.
Paragraph (version B):
Remote Endpoint: The Remote Endpoint represents the application's
identifier for a peer that can participate in a transport
connection; for example, the combination of a DNS name for the
peer and a service name/port.
Paragraph (version B):
Local Endpoint: The Local Endpoint represents the application's
identifier for itself that it uses for transport connections; for
example, a local IP address and port.
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.  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: 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 multiple Messages sent on a
stream-based transport can be treated as a single Message by the
application on the other side, and vice versa.