IETF DataTracker: draft-ietf-taps-arch
This version adds Section 2.4 discussing coexistence with the Sockets
API and makes minor editorial clarifications throughout.
This version includes only minor editorial fixes.
This version adds a glossary and includes various clarifications
to address AD review comments.
This version updates the references. There are no content changes.
This version includes minor editorial fixes.
This version clarifies that the API is defined in terms of an
event-driven model, but that other asynchronous implementation styles
are permitted. It also clarifies that constraints on permitted versions
are permitted when considering fallback for unsupported security
protocols, and discusses what certificates can be used in such fallback
This version includes fixes to better explain the intent of the
transport services architecture and how it differs from the BSD Sockets
API, to clarify the terminology used, and to highlight the flexible
implementation choices given that this is an abstract rather than
It expands the discussion of Connection Groups, the relation between
connections in a connection group, and the use of connection contexts.
It adds a discussion of privacy issues around connection racing to
the security considerations.
And, finally, this version also updates the use of normative language,
and includes a number of minor clarifications and corrections throughout.
This version clarifies that a Connection is an abstraction
that represents the communication in the Transport Services API. In
some cases this corresponds to a protocol-level connection;
in other cases the underlying protocol may be connectionless.
This version makes a minor clarification around the management of
This version breaks the discussion of Endpoint Objects out into
a separate section, updates the references, and makes some minor
This version of the Transport Services Architecture is a relatively
minor update. It updates the discussion of the need to provide common
APIs for common features, and of selection of equivalent protocol
stacks, and makes a small number of editorial clarifications
This version expands on the motivation for the transport services framework.
It clarifies the role of the framer, the use of InitiateWithSend(),
the use of connection groups, and the use of security parameters. It adds
some discussion of security parameter racing when this is signalled as
acceptable by the application. It includes editorial fixes throughout, and
updates the examples and acknowledgements.
This version of the draft makes minor clarifications throughout, in
preparation for working group last call.
This version expands and improves the Background and Overview sections;
clarifies the relation to the traditional Berkeley Sockets API;
improves the diagram showing the lifetime of a connection; and
includes a number of small clarifications and fixes throughout.
This version is a minor update that clarifies that connection pooling
is in scope for the TAPS architecture.
This version updates the introductory remarks to clarify the goals of
the work; expands discussion of the benefits of using a message-based
abstraction; adopts RFC
2119 terms for normative requirements where appropriate; updates
terminology around preferences and properties; expands the discussion
of connection groups; and updates the security considerations.
This version adds an overview diagram, explains the event-driven and
message-oriented nature of the API, and its intent to support flexible
implementation. A number of editorial fixes are also made.
This version adds discussion of protocol stack equivalence for
connection racing, in particular around the equivalence of the
various security protocols. It also includes some clarifications
around how an endpoint can be identified in the pre-establishment
phase, and better defines the terminology around candidates for
This draft was adopted as a work item of the TAPS working group at IETF
101 in London in March 2018.
This revision includes a number of clarifications around rendezvous
behaviour, and Message Framing, Parsing, and Serialization.
This draft replaces