rfc9621.original.xml   rfc9621.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!-- draft submitted in xml v3 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.2 (Ruby 3.2.2 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
) --> -ietf-taps-arch-19" number="9621" updates="" obsoletes="" submissionType="IETF"
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"
-ietf-taps-arch-19" category="std" consensus="true" tocInclude="true" sortRefs=" version="3" xml:lang="en">
true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.18.2 -->
<front> <front>
<title abbrev="TAPS Architecture">Architecture and Requirements for Transpor <title abbrev="Transport Services Architecture">Architecture and Requirement
t Services</title> s for Transport Services</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-taps-arch-19"/>
<seriesInfo name="RFC" value="9621"/>
<author initials="T." surname="Pauly" fullname="Tommy Pauly" role="editor"> <author initials="T." surname="Pauly" fullname="Tommy Pauly" role="editor">
<organization>Apple Inc.</organization> <organization>Apple Inc.</organization>
<address> <address>
<postal> <postal>
<street>One Apple Park Way</street> <street>One Apple Park Way</street>
<city>Cupertino, California 95014</city> <city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>tpauly@apple.com</email> <email>tpauly@apple.com</email>
</address> </address>
</author> </author>
<author initials="B." surname="Trammell" fullname="Brian Trammell" role="edi tor"> <author initials="B." surname="Trammell" fullname="Brian Trammell" role="edi tor">
<organization>Google Switzerland GmbH</organization> <organization>Google Switzerland GmbH</organization>
<address> <address>
<postal> <postal>
<street>Gustav-Gull-Platz 1</street> <street>Gustav-Gull-Platz 1</street>
<city>8004 Zurich</city> <city>Zurich</city>
<code>8004</code>
<country>Switzerland</country> <country>Switzerland</country>
</postal> </postal>
<email>ietf@trammell.ch</email> <email>ietf@trammell.ch</email>
</address> </address>
</author> </author>
<author initials="A." surname="Brunstrom" fullname="Anna Brunstrom"> <author initials="A." surname="Brunstrom" fullname="Anna Brunstrom">
<organization>Karlstad University</organization> <organization>Karlstad University</organization>
<address> <address>
<postal> <postal>
<street>Universitetsgatan 2</street> <street>Universitetsgatan 2</street>
skipping to change at line 54 skipping to change at line 60
</postal> </postal>
<email>anna.brunstrom@kau.se</email> <email>anna.brunstrom@kau.se</email>
</address> </address>
</author> </author>
<author initials="G." surname="Fairhurst" fullname="Godred Fairhurst"> <author initials="G." surname="Fairhurst" fullname="Godred Fairhurst">
<organization>University of Aberdeen</organization> <organization>University of Aberdeen</organization>
<address> <address>
<postal> <postal>
<street>Fraser Noble Building</street> <street>Fraser Noble Building</street>
<city>Aberdeen, AB24 3UE</city> <city>Aberdeen, AB24 3UE</city>
<country>Scotland</country> <country>United Kingdom</country>
<!-- <country>Scotland</country> Changed to United Kingdom,
per RFCs 9268 and 9435 -->
</postal> </postal>
<email>gorry@erg.abdn.ac.uk</email> <email>gorry@erg.abdn.ac.uk</email>
<uri>http://www.erg.abdn.ac.uk/</uri> <uri>https://erg.abdn.ac.uk/</uri>
</address> </address>
</author> </author>
<author initials="C." surname="Perkins" fullname="Colin Perkins"> <author initials="C. S." surname="Perkins" fullname="Colin S. Perkins">
<organization>University of Glasgow</organization> <organization>University of Glasgow</organization>
<address> <address>
<postal> <postal>
<street>School of Computing Science</street> <street>School of Computing Science</street>
<city>Glasgow G12 8QQ</city> <city>Glasgow G12 8QQ</city>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>csp@csperkins.org</email> <email>csp@csperkins.org</email>
</address> </address>
</author> </author>
<date year="2023" month="November" day="09"/> <date year="2024" month="December"/>
<area>Transport</area> <area>WIT</area>
<workgroup>TAPS Working Group</workgroup> <workgroup>taps</workgroup>
<keyword>Internet-Draft</keyword>
<!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on <https://www.rfc-editor.org/search>. -->
<abstract> <abstract>
<?line 68?>
<t>This document describes an architecture for exposing transport protocol featu res to applications for network communication. This system exposes transport pro tocol features to applications for network communication. The Transport Services Application Programming Interface (API) is based on an asynchronous, event-driv en interaction pattern. This API uses messages for representing data transfer to applications, and describes how a Transport Services Implementation can use mul tiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams. This document provides the architecture and requirements. It defines common terminology and concepts to be used in definitions of a Transp ort Service API and a Transport Services Implementation.</t> <t>This document describes an architecture that exposes transport protocol featu res to applications for network communication. The Transport Services Applicatio n Programming Interface (API) is based on an asynchronous, event-driven interact ion pattern. This API uses Messages for representing data transfer to applicatio ns and describes how a Transport Services Implementation can use multiple IP add resses, multiple protocols, and multiple paths and can provide multiple applicat ion streams. This document provides the architecture and requirements. It define s common terminology and concepts to be used in definitions of a Transport Servi ces API and a Transport Services Implementation.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 72?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Many application programming interfaces (APIs) to provide transport int <t>Many Application Programming Interfaces (APIs) to provide transport int
erfaces to networks have been deployed, perhaps the most widely known and imitat erfaces to networks have been deployed, perhaps the most widely known and imitat
ed being the BSD Socket <xref target="POSIX"/> interface (Socket API). ed being the Socket interface (Socket API) <xref target="POSIX"/>.
The naming of objects and functions across these APIs is not consistent and vari The naming of objects and functions across these APIs is not consistent and vari
es depending on the protocol being used. es, depending on the protocol being used.
For example, sending and receiving streams of data is conceptually the same for For example, the concept of sending and receiving streams of data is the same fo
both an unencrypted Transmission Control Protocol (TCP) stream and operating on r both an unencrypted Transmission Control Protocol (TCP) stream and operating o
an encrypted Transport Layer Security (TLS) <xref target="RFC8446"/> stream over n an encrypted Transport Layer Security (TLS) stream <xref target="RFC8446"/> ov
TCP, but applications cannot use the same socket <tt>send()</tt> and <tt>recv() er TCP, but applications cannot use the same socket <tt>send()</tt> and <tt>recv
</tt> calls on top of both kinds of connections. ()</tt> calls on top of both kinds of connections.
Similarly, terminology for the implementation of transport protocols varies base d on the context of the protocols themselves: terms such as "flow", "stream", "m essage", and "connection" can take on many different meanings. Similarly, terminology for the implementation of transport protocols varies base d on the context of the protocols themselves: terms such as "flow", "stream", "m essage", and "connection" can take on many different meanings.
This variety can lead to confusion when trying to understand the similarities an This variety can lead to confusion when trying to understand the similarities an
d differences between protocols, and how applications can use them effectively.< d differences between protocols and how applications can use them effectively.
/t> </t>
<t>The goal of the Transport Services System architecture is to provide a flexible <t>The goal of the Transport Services System architecture is to provide a flexible
and reusable system with a common interface for transport protocols. and reusable system with a common interface for transport protocols.
An application uses the Transport Services System through an abstract Connection (we use capitalization to distinguish these from the underlying connections of, e.g., TCP). An application uses the Transport Services System through an abstract Connection (we use capitalization to distinguish these from the underlying connections of, for example, TCP).
This provides This provides
flexible connection establishment allowing an application to request or require flexible Connection establishment allowing an application to request or require
a set of properties.</t> a set of Properties.</t>
<t>As applications adopt this interface, they will benefit from a wide set <t>As applications adopt this interface, they will benefit from a wide set
of transport features that can evolve over time, of transport features that can evolve over time
and ensure that the system providing the interface can optimize its behavior bas and will ensure that the system providing the interface can optimize its behavio
ed on the application requirements r based on the application requirements
and network conditions, without requiring changes to the applications. This flex ibility enables faster deployment of new features and protocols.</t> and network conditions, without requiring changes to the applications. This flex ibility enables faster deployment of new features and protocols.</t>
<t>This architecture can also support applications by offering racing mech <t>This architecture can also support applications by offering racing mech
anisms (attempting multiple IP addresses, protocols, or network paths in paralle anisms (attempting multiple IP addresses, protocols, or network paths in paralle
l), which otherwise need to be implemented in each application separately (see < l), which otherwise need to be implemented in each application separately (see <
xref target="racing"/>). Racing selects one or more candidates each with equival xref target="racing"/>). Racing selects one or more candidates, each with equiva
ent protocol stacks that are used to identify lent Protocol Stacks that are used to identify
an optimal combination of transport protocol instance such as TCP, UDP, or anoth an optimal combination of a transport protocol instance such as TCP, UDP, or ano
er transport, together with configuration of parameters and ther transport, together with configuration of parameters and
interfaces. interfaces.
A Connection represents an object that, once established, can be used to send an A Connection represents an object that, once established, can be used to send an
d receive messages. d receive Messages.
A Connection can also be created from another Connection, by cloning, and then f A Connection can also be created from another Connection, by cloning, and then f
orms a part of a Connection Group whose Connections share properties.</t> orms a part of a Connection Group whose Connections share Properties.
<t>This document was developed in parallel with the specification of the T
ransport Services API <xref target="I-D.ietf-taps-interface"/> and implementatio </t>
n guidelines <xref target="I-D.ietf-taps-impl"/>. Although following the Transpo <t>This document was developed in parallel with the specification of the T
rt Services architecture does not require all APIs and implementations to be ide ransport Services API <xref target="RFC9622"/> and implementation guidelines <xr
ntical, a common minimal set of features represented in a consistent fashion wil ef target="RFC9623"/>. Although following the Transport Services Architecture do
l enable applications to be easily ported from one implementation of the Transpo es not require all APIs and implementations to be identical, a common minimal se
rt Services System to another.</t> t of features represented in a consistent fashion will enable applications to be
easily ported from one implementation of the Transport Services System to anoth
er.</t>
<section anchor="background"> <section anchor="background">
<name>Background</name> <name>Background</name>
<t>The architecture of the Transport Services System is based on the sur <t>The architecture of the Transport Services System is based on the sur
vey of services provided by IETF transport protocols and congestion control mech vey of services provided by IETF transport protocols and congestion control mech
anisms <xref target="RFC8095"/>, and the distilled minimal set of the features o anisms <xref target="RFC8095"/> and the distilled minimal set of the features of
ffered by transport protocols <xref target="RFC8923"/>. These documents identifi fered by transport protocols <xref target="RFC8923"/>. These documents identifie
ed common features and patterns across all transport protocols developed thus fa d common features and patterns across all transport protocols developed thus far
r in the IETF.</t> in the IETF.</t>
<t>Since transport security is an increasingly relevant aspect of using <t>Since transport security is an increasingly relevant aspect of using
transport protocols on the Internet, this document also considers the impact of transport protocols on the Internet, this document also considers the impact of
transport security protocols on the feature-set exposed by Transport Services <x transport security protocols on the feature set exposed by Transport Services <x
ref target="RFC8922"/>.</t> ref target="RFC8922"/>.</t>
<t>One of the key insights to come from identifying the minimal set of f <t>One of the key insights to come from identifying the minimal set of f
eatures provided by transport protocols <xref target="RFC8923"/> was that featur eatures provided by transport protocols <xref target="RFC8923"/> was that featur
es either require application interaction and guidance (referred to in that docu es either (1)&nbsp;require application interaction and guidance (referred to in
ment as Functional or Optimizing Features), or else can be handled automatically that document as Functional or Optimizing Features) or (2)&nbsp;can be handled a
by an implementation of the Transport Services System (referred to as Automatab utomatically by an implementation of the Transport Services System (referred to
le Features). Among the identified Functional and Optimizing Features, some are as Automatable Features). Among the identified Functional and Optimizing Feature
common across all or nearly all transport protocols, while others present featur s, some are common across all or nearly all transport protocols, while others pr
es that, if specified, would only be useful with a subset of protocols, but woul esent features that, if specified, would only be useful with a subset of protoco
d not harm the functionality of other protocols. For example, some protocols can ls, but would not harm the functionality of other protocols. For example, some p
deliver messages faster for applications that do not require messages to arrive rotocols can deliver messages more quickly for applications that do not require
in the order in which they were sent. This functionality needs to be explicitly messages to arrive in the order in which they were sent. This functionality need
allowed by the application, since reordering messages would be undesirable in m s to be explicitly allowed by the application, since reordering messages would b
any cases.</t> e undesirable in many cases.</t>
</section> </section>
<section anchor="overview"> <section anchor="overview">
<name>Overview</name> <name>Overview</name>
<t>This document describes the Transport Services System in three sectio ns:</t> <t>The following sections describe the Transport Services System:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t><xref target="model"/> describes how the Transport Services API m odel differs from that of traditional socket-based APIs. Specifically, it offers asynchronous event-driven interaction, the use of messages for data transfer, a nd the flexibility to use different transport protocols and paths without requir ing major changes to the application.</t> <t><xref target="model"/> describes how the Transport Services API m odel differs from that of socket-based APIs. Specifically, it offers asynchronou s event-driven interaction, the use of Messages for data transfer, and the flexi bility to use different transport protocols and paths without requiring major ch anges to the application.</t>
</li> </li>
<li> <li>
<t><xref target="requirements"/> explains the fundamental requiremen ts for a Transport Services System. These principles are intended to make sure t hat transport protocols can continue to be enhanced and evolve without requiring significant changes by application developers.</t> <t><xref target="requirements"/> explains the fundamental requiremen ts for a Transport Services System. These principles are intended to make sure t hat transport protocols can continue to be enhanced and evolve without requiring significant changes by application developers.</t>
</li> </li>
<li> <li>
<t><xref target="concepts"/> presents the Transport Services Impleme ntation and defines the concepts that are used by the API <xref target="I-D.ietf -taps-interface"/> and described in the implementation guidelines <xref target=" I-D.ietf-taps-impl"/>. This introduces the Preconnection, which allows applicati ons to configure Connection Properties.</t> <t><xref target="concepts"/> presents the Transport Services Impleme ntation and defines the concepts that are used by the API <xref target="RFC9622" /> and described in the implementation guidelines <xref target="RFC9623"/>. This introduces the Preconnection, which allows applications to configure Connection Properties.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="specification-of-requirements"> <section anchor="specification-of-requirements">
<name>Specification of Requirements</name> <name>Specification of Requirements</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP 14 "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, "<bcp14>SHOULD NOT</bcp14>",
they appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section> </section>
<section anchor="glossary-of-key-terms"> <section anchor="glossary-of-key-terms">
<name>Glossary of Key Terms</name> <name>Glossary of Key Terms</name>
<t>This subsection provides a glossary of key terms related to the Trans <t>This subsection provides a glossary of key terms related to the Trans
port Services architecture. It provides a short description of key terms that ar port Services Architecture. It provides a short description of key terms that ar
e later defined in this document.</t> e defined later in this document.</t>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t>Application: An entity that uses the transport layer for end-to-e <dt>Application:</dt><dd> An entity that uses the transport layer fo
nd delivery of data across the network <xref target="RFC8095"/>.</t> r end-to-end delivery of data across the network <xref target="RFC8095"/>.</dd>
</li>
<li> <dt>Cached State:</dt><dd> The state and history that the Transport
<t>Cached State: The state and history that the Transport Services I Services Implementation keeps for each set of the associated Endpoints that have
mplementation keeps for each set of the associated Endpoints that have been used been used previously.</dd>
previously.</t>
</li> <dt>Candidate Path:</dt><dd> One path that is available to an applic
<li> ation and conforms to the Selection Properties and System Policy during racing.<
<t>Candidate Path: One path that is available to an application and /dd>
conforms to the Selection Properties and System Policy during racing.</t>
</li> <dt>Candidate Protocol Stack:</dt><dd> One Protocol Stack that can b
<li> e used by an application for a Connection during racing.</dd>
<t>Candidate Protocol Stack: One Protocol Stack that can be used by
an application for a Connection during racing.</t> <dt>Client:</dt><dd> The peer responsible for initiating a Connectio
</li> n.</dd>
<li>
<t>Client: The peer responsible for initiating a Connection.</t> <dt>Clone:</dt><dd> A Connection that was created from another Conne
</li> ction and that forms a part of a Connection Group.</dd>
<li>
<t>Clone: A Connection that was created from another Connection, and <dt>Connection:</dt><dd> Shared state of two or more Endpoints that
forms a part of a Connection Group.</t> persists across Messages that are transmitted and received between these Endpoin
</li> ts <xref target="RFC8303"/>. When this document and other Transport Services doc
<li> uments use the capitalized "Connection" term, it refers to a Connection object t
<t>Connection: Shared state of two or more Endpoints that persists a hat is being offered by the Transport Services System, as opposed to more generi
cross Messages that are transmitted and received between these Endpoints <xref t c uses of the word "connection".</dd>
arget="RFC8303"/>. When this document (and other Transport Services documents) u
se the capitalized "Connection" term, it refers to a Connection object that is b <dt>Connection Context:</dt><dd> A set of stored Properties across C
eing offered by the Transport Services system, as opposed to more generic uses o onnections, such as cached protocol state, cached path state, and heuristics, wh
f the word "connection".</t> ich can include one or more Connection Groups.</dd>
</li>
<li> <dt>Connection Group:</dt><dd> A set of Connections that share Prope
<t>Connection Context: A set of stored properties across Connections rties and caches.</dd>
, such as cached protocol state, cached path state, and heuristics, which can in
clude one or more Connection Groups.</t> <dt>Connection Property:</dt><dd> A Transport Property that controls
</li> per-Connection behavior of a Transport Services Implementation.</dd>
<li>
<t>Connection Group: A set of Connections that share properties and <dt>Endpoint:</dt><dd> An entity that communicates with one or more
caches.</t> other Endpoints using a transport protocol.</dd>
</li>
<li> <dt>Endpoint Identifier:</dt><dd> An identifier that specifies one s
<t>Connection Property: A Transport Property that controls per-Conne ide of a Connection (local or remote), such as a hostname or URL.</dd>
ction behavior of a Transport Services implementation.</t>
</li> <dt>Equivalent Protocol Stacks:</dt><dd> Protocol Stacks that can be
<li> safely swapped or raced in parallel during establishment of a Connection.</dd>
<t>Endpoint: An entity that communicates with one or more other endp
oints using a transport protocol.</t> <dt>Event:</dt><dd> A primitive that is invoked by an Endpoint <xref
</li> target="RFC8303"/>.</dd>
<li>
<t>Endpoint Identifier: An identifier that specifies one side of a C <dt>Framer:</dt><dd> A data translation layer that can be added to a
onnection (local or remote), such as a hostname or URL.</t> Connection to define how application-layer Messages are transmitted over a Prot
</li> ocol Stack.</dd>
<li>
<t>Equivalent Protocol Stacks: Protocol Stacks that can be safely sw <dt>Local Endpoint:</dt><dd> The local Endpoint.</dd>
apped or raced in parallel during establishment of a Connection.</t>
</li> <dt>Local Endpoint Identifier:</dt><dd> A representation of the appl
<li> ication's identifier for itself that it uses for a Connection.</dd>
<t>Event: A primitive that is invoked by an Endpoint <xref target="R
FC8303"/>.</t> <dt>Message:</dt><dd> A unit of data that can be transferred between
</li> two Endpoints over a Connection.</dd>
<li>
<t>Framer: A data translation layer that can be added to a Connectio <dt>Message Property:</dt><dd> A property that can be used to specif
n to define how application-layer Messages are transmitted over a Protocol Stack y details about Message transmission or obtain details about the transmission af
.</t> ter receiving a Message.</dd>
</li>
<li> <dt>Parameter:</dt><dd> A value passed between an application and a
<t>Local Endpoint: The local Endpoint.</t> transport protocol by a primitive <xref target="RFC8303"/>.</dd>
</li>
<li> <dt>Path:</dt><dd> A representation of an available set of Propertie
<t>Local Endpoint Identifier: A representation of the application's s that a Local Endpoint can use to communicate with a Remote Endpoint.</dd>
identifier for itself that it uses for a Connection.</t>
</li> <dt>Peer:</dt><dd> An Endpoint application party to a Connection.</d
<li> d>
<t>Message: A unit of data that can be transferred between two Endpo
ints over a Connection.</t> <dt>Preconnection:</dt><dd> An object that represents a Connection t
</li> hat has not yet been established.</dd>
<li>
<t>Message Property: A property that can be used to specify details <dt>Preference:</dt><dd> A preference for prohibiting, avoiding, ign
about Message transmission, or obtain details about the transmission after recei oring, preferring, or requiring a specific transport feature.</dd>
ving a Message.</t>
</li> <dt>Primitive:</dt><dd> A function call that is used to locally comm
<li> unicate between an application and an Endpoint, which is related to one or more
<t>Parameter: A value passed between an application and a transport transport features <xref target="RFC8303"/>.</dd>
protocol by a primitive <xref target="RFC8303"/>.</t>
</li> <dt>Protocol Instance:</dt><dd> A single instance of one protocol, i
<li> ncluding any state necessary to establish connectivity or send and receive Messa
<t>Path: A representation of an available set of properties that a L ges.</dd>
ocal Endpoint can use to communicate with a Remote Endpoint.</t>
</li> <dt>Protocol Stack:</dt><dd> A set of protocol instances that are us
<li> ed together to establish connectivity or send and receive Messages.</dd>
<t>Peer: An Endpoint application party to a Connection.</t>
</li> <dt>Racing:</dt><dd> The attempt to select between multiple Protocol
<li> Stacks based on the Selection and Connection Properties communicated by the app
<t>Preconnection: an object that represents a Connection that has no lication, along with any Security Parameters.</dd>
t yet been established.</t>
</li> <dt>Remote Endpoint:</dt><dd> The peer that a Local Endpoint can com
<li> municate with when a Connection is established.</dd>
<t>Preference: A preference to prohibit, avoid, ignore, prefer, or r
equire a specific Transport Feature.</t> <dt>Remote Endpoint Identifier:</dt><dd> A representation of the app
</li> lication's identifier for a peer that can participate in establishing a Connecti
<li> on.</dd>
<t>Primitive: A function call that is used to locally communicate be
tween an application and an Endpoint, which is related to one or more Transport <dt>Rendezvous:</dt><dd> The action of establishing a peer-to-peer C
Features <xref target="RFC8303"/>.</t> onnection with a Remote Endpoint.</dd>
</li>
<li> <dt>Security Parameters:</dt><dd> Parameters that define an applicat
<t>Protocol Instance: A single instance of one protocol, including a ion's requirements for authentication and encryption on a Connection.</dd>
ny state necessary to establish connectivity or send and receive Messages.</t>
</li> <dt>Selection Property:</dt><dd> A Transport Property that can be se
<li> t to influence the selection of paths between the Local and Remote Endpoints.</d
<t>Protocol Stack: A set of Protocol Instances that are used togethe d>
r to establish connectivity or send and receive Messages.</t>
</li> <dt>Server:</dt><dd> The peer responsible for responding to a Connec
<li> tion initiation.</dd>
<t>Racing: The attempt to select between multiple Protocol Stacks ba
sed on the Selection and Connection Properties communicated by the application, <dt>Socket:</dt><dd> The combination of a destination IP address and
along with any Security Parameters.</t> a destination port number <xref target="RFC8303"/>.</dd>
</li>
<li> <dt>System Policy:</dt><dd> The input from an operating system or ot
<t>Remote Endpoint: The peer that a local Endpoint can communicate w her global preferences that can constrain or influence how an implementation wil
ith when a Connection is established.</t> l gather Candidate Paths and Candidate Protocol Stacks and race the candidates d
</li> uring establishment of a Connection.</dd>
<li>
<t>Remote Endpoint Identifier: A representation of the application's <dt>Transport Feature:</dt><dd> A specific end-to-end feature that t
identifier for a peer that can participate in establishing a Connection.</t> he transport layer provides to an application.</dd>
</li>
<li> <dt>Transport Property:</dt><dd> A property of a transport protocol
<t>Rendezvous: The action of establishing a peer-to-peer Connection and the services it provides <xref target="RFC8095"/>.</dd>
with a Remote Endpoint.</t>
</li> <dt>Transport Service:</dt><dd> A set of transport features, not ass
<li> ociated with any given framing protocol, that provides a complete service to an
<t>Security Parameters: Parameters that define an application's requ application.</dd>
irements for authentication and encryption on a Connection.</t>
</li> <dt>Transport Services API:</dt><dd>The abstract interface <xref targ
<li> et="RFC9622" format="default"/> to a Transport Services Implementation <xref tar
<t>Server: The peer responsible for responding to a Connection initi get="RFC9623" format="default"/>.</dd>
ation.</t>
</li> <dt>Transport Services Implementation:</dt><dd> All objects and prot
<li> ocol instances used internally to a system or library to implement the functiona
<t>Socket: The combination of a destination IP address and a destina lity needed to provide a transport service across a network, as required by the
tion port number <xref target="RFC8303"/>.</t> abstract interface.</dd>
</li>
<li> <dt>Transport Services System:</dt><dd> The Transport Services Imple
<t>System Policy: The input from an operating system or other global mentation and the Transport Services API.</dd>
preferences that can constrain or influence how an implementation will gather C
andidate Paths and Protocol Stacks and race the candidates during establishment </dl>
of a Connection.</t>
</li>
<li>
<t>Selection Property: A Transport Property that can be set to influ
ence the selection of paths between the Local and Remote Endpoints.</t>
</li>
<li>
<t>Transport Feature: A specific end-to-end feature that the transpo
rt layer provides to an application.</t>
</li>
<li>
<t>Transport Property: A property that expresses requirements, prohi
bitions and preferences <xref target="RFC8095"/>.</t>
</li>
<li>
<t>Transport Service: A set of transport features, without an associ
ation to any given framing protocol, that provides a complete service to an appl
ication.</t>
</li>
<li>
<t>Transport Services Implementation: This consists of all objects a
nd protocol instances used internally to a system or library to implement the fu
nctionality needed to provide a transport service across a network, as required
by the abstract interface.</t>
</li>
<li>
<t>Transport Services System: The Transport Services Implementation
and the Transport Services API.</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="model"> <section anchor="model">
<name>API Model</name> <name>API Model</name>
<t>The traditional model of using sockets can be represented as follows (s ee figure 1):</t> <t>The model of using sockets can be represented as follows (see <xref tar get="fig-sockets"/>):</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Applications create connections and transfer data using the Socket API.</t> <t>Applications create connections and transfer data using the Socket API.</t>
</li> </li>
<li> <li>
<t>The Socket API provides the interface to the implementations of TCP and UDP <t>The Socket API provides the interface to the implementations of TCP and UDP
(typically implemented in the system's kernel).</t> (typically implemented in the system's kernel).</t>
</li> </li>
<li> <li>
<t>TCP and UDP in the kernel send and receive data over the available network-layer interfaces.</t> <t>TCP and UDP in the kernel send and receive data over the available network-layer interfaces.</t>
skipping to change at line 292 skipping to change at line 270
</li> </li>
</ul> </ul>
<figure anchor="fig-sockets"> <figure anchor="fig-sockets">
<name>Socket API Model</name> <name>Socket API Model</name>
<artwork><![CDATA[ <artwork><![CDATA[
+-----------------------------------------------------+ +-----------------------------------------------------+
| Application | | Application |
+-----------------------------------------------------+ +-----------------------------------------------------+
| | | | | |
+------------+ +------------+ +--------------+ +------------+ +------------+ +--------------+
| DNS stub | | Stream API | | Datagram API | | DNS Stub | | Stream API | | Datagram API |
| resolver | +------------+ +--------------+ | Resolver | +------------+ +--------------+
+------------+ | | +------------+ | |
+---------------------------------+ +---------------------------------+
| TCP UDP | | TCP UDP |
| Kernel Networking Stack | | Kernel Networking Stack |
+---------------------------------+ +---------------------------------+
| |
+-----------------------------------------------------+ +-----------------------------------------------------+
| Network Layer Interface | | Network-Layer Interface |
+-----------------------------------------------------+ +-----------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The architecture of the Transport Services System is an evolution of th is general model of interaction. It both modernizes the API presented to applica tions by the transport layer and enriches the capabilities of the Transport Serv ices Implementation below this API.</t> <t>The architecture of the Transport Services System is an evolution of th is general model of interaction. It both modernizes the API presented to applica tions by the transport layer and enriches the capabilities of the Transport Serv ices Implementation below this API.</t>
<t>The Transport Services API <xref target="RFC9622"/> defines the interfa
ce for an application to create Connections and transfer data. It combines inter
faces for multiple interaction patterns into a unified whole (see <xref target="
fig-taps"/>).
This offers generic functions and also the protocol-specific mappings for TCP, U
DP, UDP-Lite, and other protocol layers. These mappings are extensible. Future d
ocuments could define similar mappings for new layers and for other transport pr
otocols, such as QUIC <xref target="RFC9000"/>.</t>
<figure anchor="fig-taps"> <figure anchor="fig-taps">
<name>Transport Services API Model</name> <name>Transport Services API Model</name>
<artwork><![CDATA[ <artwork><![CDATA[
+-----------------------------------------------------+ +-----------------------------------------------------+
| Application | | Application |
+-----------------------------------------------------+ +-----------------------------------------------------+
| |
+-----------------------------------------------------+ +-----------------------------------------------------+
| Transport Services API | | Transport Services API |
+-----------------------------------------------------+ +-----------------------------------------------------+
| |
+-----------------------------------------------------+ +-----------------------------------------------------+
| Transport Services Implementation | | Transport Services Implementation |
| (Using: DNS, UDP, TCP, SCTP, DCCP, TLS, QUIC, etc) | | (Using DNS, UDP, TCP, SCTP, DCCP, TLS, QUIC, etc.) |
+-----------------------------------------------------+ +-----------------------------------------------------+
| |
+-----------------------------------------------------+ +-----------------------------------------------------+
| Network Layer Interface | | Network-Layer Interface |
+-----------------------------------------------------+ +-----------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The Transport Services API <xref target="I-D.ietf-taps-interface"/> def <t>By combining name resolution with Connection establishment and data transfer
ines the interface for an application to create Connections and transfer data. I in a single API, it allows for more flexible implementations to provide path and
t combines interfaces for multiple interaction patterns into a unified whole (se transport protocol agility on the application's behalf.</t>
e figure 2). <t>The Transport Services Implementation <xref target="RFC9623"/> is the c
This offers generic functions and also the protocol-specific mappings for TCP, U omponent of the Transport Services System that implements the transport-layer pr
DP, UDP-Lite, and other protocol layers. These mapping are extensible. Future do otocols and other functions needed to send and receive data. It is responsible f
cuments could define similar mappings for new layers and for other transport pro or mapping the API to a specific available transport Protocol Stack and managing
tocols, such as QUIC <xref target="RFC9000"/>. the available network interfaces and paths.</t>
By combining name resolution with connection establishment and data transfer in <t>There are key differences between the architecture of the Transport Ser
a single API, it allows for more flexible implementations to provide path and tr vices System and the architecture of the Socket API. The API of the Transport Se
ansport protocol agility on the application's behalf.</t> rvices System:</t>
<t>The Transport Services Implementation <xref target="I-D.ietf-taps-impl"
/> is the component of the Transport Services System that implements the transpo <ul spacing="normal">
rt layer protocols and other functions needed to send and receive data. It is re <li>is asynchronous and event-driven;</li>
sponsible for mapping the API to a specific available transport Protocol Stack a <li>uses Messages for representing data transfer to applications;</li>
nd managing the available network interfaces and paths.</t> <li>describes how a Transport Services Implementation can resolve Endpoint Ide
<t>There are key differences between the architecture of the Transport Ser ntifiers to use multiple IP addresses, multiple protocols, and multiple paths an
vices System and the architecture of the Socket API: the API of the Transport Se d to provide multiple application streams.</li>
rvices System is asynchronous and event-driven; it uses messages for representin </ul>
g data transfer to applications; and it describes how a Transport Services Imple
mentation can resolve Endpoint Identifiers to use multiple IP addresses, multipl
e protocols, multiple paths, and provide multiple application streams.</t>
<section anchor="event-driven-api"> <section anchor="event-driven-api">
<name>Event-Driven API</name> <name>Event-Driven API</name>
<t>Originally, the Socket API presented a blocking interface for establi shing connections and transferring data. However, most modern applications inter act with the network asynchronously. Emulation of an asynchronous interface usin g the Socket API can use 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. T he application then waits and can try again later.</t> <t>Originally, the Socket API presented a blocking interface for establi shing connections and transferring data. However, most modern applications inter act with the network asynchronously. Emulation of an asynchronous interface usin g the Socket API can use 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. Th e application then waits and can try again later.</t>
<t>In contrast to the Socket API, all interactions using the Transport S ervices API are expected to be asynchronous. The API is defined around an event- driven model (see <xref target="events"/>), which models this asynchronous inter action. Other forms of asynchronous communication could also be available to app lications, depending on the platform implementing the interface.</t> <t>In contrast to the Socket API, all interactions using the Transport S ervices API are expected to be asynchronous. The API is defined around an event- driven model (see <xref target="events"/>), which models this asynchronous inter action. Other forms of asynchronous communication could also be available to app lications, depending on the platform implementing the interface.</t>
<t>For example, when an application that uses the Transport Services API wants to receive data, it issues an asynchronous 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, resulting in asynchronous error events.</t> <t>For example, when an application that uses the Transport Services API wants to receive data, it issues an asynchronous 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, resulting in asynchronous error events.</t>
<t>This API also delivers events regarding the lifetime of a connection and changes in the available network links, which were not previously made expli cit in the Socket API.</t> <t>This API also delivers events regarding the lifetime of a connection and changes in the available network links, which were not previously made expli cit in the Socket API.</t>
<t>Using asynchronous events allows for a more natural interaction model when establishing connections and transferring data. Events in time more closel y reflect the nature of interactions over networks, as opposed to how the Socket API represents network resources as file system objects that may be temporarily unavailable.</t> <t>Using asynchronous events allows for a more natural interaction model when establishing connections and transferring data. Events in time more closel y reflect the nature of interactions over networks, as opposed to how the Socket API represents network resources as file system objects that may be temporarily unavailable.</t>
<t>Separate from events, callbacks are also provided for asynchronous in teractions with the Transport Services API that are not directly related to even ts on the network or network interfaces.</t> <t>Separate from events, callbacks are also provided for asynchronous in teractions with the Transport Services API that are not directly related to even ts on the network or network interfaces.</t>
</section> </section>
<section anchor="data-transfer-using-messages"> <section anchor="data-transfer-using-messages">
<name>Data Transfer Using Messages</name> <name>Data Transfer Using Messages</name>
<t>The Socket API provides a message interface for datagram protocols li <t>The Socket API provides a message interface for datagram protocols li
ke UDP, but provides an unstructured stream abstraction for TCP. While TCP has t ke UDP but provides an unstructured stream abstraction for TCP. While TCP has th
he ability to send and receive data as a byte-stream, most applications need to e ability to send and receive data as a byte-stream, most applications need to i
interpret structure within this byte-stream. For example, HTTP/1.1 uses characte nterpret structure within this byte-stream. For example, HTTP/1.1 uses character
r delimiters to segment messages over a byte-stream <xref target="RFC9112"/>; TL delimiters to segment messages over a byte-stream <xref target="RFC9112"/>; TLS
S record headers carry a version, content type, and length <xref target="RFC8446 record headers carry a version, content type, and length <xref target="RFC8446"
"/>; and HTTP/2 uses frames to segment its headers and bodies <xref target="RFC9 />; and HTTP/2 uses frames to segment its headers and bodies <xref target="RFC91
113"/>.</t> 13"/>.</t>
<t>The Transport Services API represents data as messages, so that it mo <t>The Transport Services API represents data as Messages, so that it mo
re closely matches the way applications use the network. A message-based abstrac re closely matches the way applications use the network. A Message-based abstrac
tion provides many benefits, such as:</t> tion provides many benefits, such as:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>providing additional information to the Protocol Stack;</t> <t>providing additional information to the Protocol Stack;</t>
</li> </li>
<li> <li>
<t>the ability to associate deadlines with messages, for application s that care about timing;</t> <t>the ability to associate deadlines with Messages, for application s that care about timing;</t>
</li> </li>
<li> <li>
<t>the ability to control reliability, which messages to retransmit when there is packet loss, and how best to make use of the data that arrived;</t > <t>the ability to control reliability, which Messages to retransmit when there is packet loss, and how best to make use of the data that arrived;</t >
</li> </li>
<li> <li>
<t>the ability to automatically assign messages and connections to u nderlying transport connections to utilize multi-streaming and pooled connection s.</t> <t>the ability to automatically assign Messages and connections to u nderlying transport connections to utilize multistreaming and create Pooled Conn ections.</t>
</li> </li>
</ul> </ul>
<t>Allowing applications to interact with messages is backwards-compatib le with existing protocols and APIs because it does not change the wire format o f any protocol. Instead, it provides the Protocol Stack with additional informat ion to allow it to make better use of modern transport services, while simplifyi ng the application's role in parsing data. For protocols that inherently use a s treaming abstraction, framers (<xref target="datatransfer"/>) bridge the gap bet ween the two abstractions.</t> <t>Allowing applications to interact with Messages is backward-compatibl e with existing protocols and APIs because it does not change the wire format of any protocol. Instead, it provides the Protocol Stack with additional informati on to allow it to make better use of modern Transport Services, while simplifyin g the application's role in parsing data. For protocols that inherently use a st reaming abstraction, Framers (<xref target="datatransfer"/>) bridge the gap betw een the two abstractions.</t>
</section> </section>
<section anchor="flexible-implementation"> <section anchor="flexible-implementation">
<name>Flexible Implementation</name> <name>Flexible Implementation</name>
<t>The Socket API for protocols like TCP is generally limited to connect ing to a single address over a single interface (IP source address). <t>The Socket API for protocols like TCP is generally limited to connect ing to a single address over a single interface (IP source address).
It also presents a single stream to the application. Software layers built upon this API often propagate this limitation of a single-address single-stream model . The Transport Services architecture is designed:</t> It also presents a single stream to the application. Software layers built upon this API often propagate this limitation of a single-address single-stream model . The Transport Services Architecture is designed to:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>to handle multiple candidate endpoints, protocols, and paths;</t> <t>handle multiple candidate endpoints, protocols, and paths;</t>
</li> </li>
<li> <li>
<t>to support candidate protocol racing to select the most optimal s tack in each situation;</t> <t>support candidate protocol racing to select the most optimal stac k in each situation;</t>
</li> </li>
<li> <li>
<t>to support multipath and multistreaming protocols;</t> <t>support multipath and multistreaming protocols;</t>
</li> </li>
<li> <li>
<t>to provide state caching and application control over it.</t> <t>provide state caching and application control over it.</t>
</li> </li>
</ul> </ul>
<t>A Transport Services Implementation is intended to be flexible at con <t>A Transport Services Implementation is intended to be flexible at Con
nection establishment time, considering many different options and trying to sel nection establishment time, considering many different options and trying to sel
ect the most optimal combinations by racing them and measuring the results (see ect the most optimal combinations by racing them and measuring the results (see
<xref target="gathering"/> and <xref target="racing"/>). This requires applicati Sections&nbsp;<xref target="gathering" format="counter"/> and <xref target="raci
ons to specify identifiers for the Local and Remote Endpoint that are higher-lev ng" format="counter"/>). This requires applications to specify identifiers for t
el than IP addresses, such as a hostname or URL, which are used by a Transport S he Local and Remote Endpoint that are at a higher level than IP addresses, such
ervices Implementation for resolution, path selection, and racing. An implementa as a hostname or URL. These identifiers are used by a Transport Services Implem
tion can further implement fallback mechanisms if connection establishment of on entation for resolution, path selection, and racing. An implementation can furth
e protocol fails or performance is detected to be unsatisfactory.</t> er implement fallback mechanisms if connection establishment for one protocol fa
<t>Information used in connection establishment (e.g. cryptographic resu ils or performance is determined to be unsatisfactory.
mption tokens, information about usability of certain protocols on the path, res </t>
ults of racing in previous connections) are cached in the Transport Services Imp <t>Information used in Connection establishment (e.g., cryptographic res
lementation. Applications have control over whether this information is used for umption tokens, information about usability of certain protocols on the path, re
a specific establishment, in order to allow tradeoffs between efficiency and li sults of racing in previous connections) is cached in the Transport Services Imp
nkability.</t> lementation. Applications have control over whether this information is used for
<t>Flexibility after connection establishment is also important. Transpo a specific establishment, in order to allow trade-offs between efficiency and l
rt protocols that can migrate between multiple network-layer interfaces need to inkability.</t>
be able to process and react to interface changes. Protocols that support multip <t>Flexibility after Connection establishment is also important. Transpo
le application-layer streams need to support initiating and receiving new stream rt protocols that can migrate between multiple network-layer interfaces need to
s using existing connections.</t> be able to process and react to interface changes. Protocols that support multip
le application-layer streams need to support initiating and receiving new stream
s using existing connections.</t>
</section> </section>
<section anchor="coexistence"> <section anchor="coexistence">
<name>Coexistence</name> <name>Coexistence</name>
<t>While the architecture of the Transport Services System is designed a s an enhanced replacement for the Socket API, it need not replace it entirely on a system or platform; indeed, coexistence has been recommended for incremental deployability <xref target="RFC8170"/>. The architecture is therefore designed s uch that it can run alongside (or, indeed, on top of) an existing Socket API imp lementation; only applications built to the Transport Services API are managed b y the system's Transport Services Implementation.</t> <t>While the architecture of the Transport Services System is designed a s an enhanced replacement for the Socket API, it need not replace it entirely on a system or platform; indeed, coexistence has been recommended for incremental deployability <xref target="RFC8170"/>. The architecture is therefore designed s uch that it can run alongside (or, indeed, on top of) an existing Socket API imp lementation; only applications built on the Transport Services API are managed b y the system's Transport Services Implementation.</t>
</section> </section>
</section> </section>
<section anchor="requirements"> <section anchor="requirements">
<name>API and Implementation Requirements</name> <name>API and Implementation Requirements</name>
<t>One goal of the architecture is to redefine the interface between appli <t>One goal of the architecture is to redefine the interface between appli
cations and transports in a way that allows the transport layer to evolve and im cations and transports in a way that allows the transport layer to evolve and im
prove without fundamentally changing the contract with the application. This req prove without fundamentally changing the contract with the application. This req
uires a careful consideration of how to expose the capabilities of protocols. Th uires careful consideration of how to expose the capabilities of protocols. The
e architecture also encompasses system policies that can influence and inform ho architecture also encompasses system policies that can influence and inform how
w transport protocols use a network path or interface.</t> transport protocols use a network path or interface.</t>
<t>There are several ways the Transport Services System can offer flexibil <t>There are several ways the Transport Services System can offer flexibil
ity to an application: it can provide access to transport protocols and protocol ity to an application. It can:</t>
features; it can use these protocols across multiple paths that could have diff <ul spacing="normal">
erent performance and functional characteristics; and it can communicate with di <li>provide access to transport protocols and protocol features;</li>
fferent remote systems to optimize performance, robustness to failure, or some o <li>use these protocols across multiple paths that could have different perfor
ther metric. Beyond these, if the Transport Services API remains the same over t mance and functional characteristics;</li>
ime, new protocols and features can be added to the Transport Services Implement <li>communicate with different remote systems to optimize performance, robustn
ation without requiring changes in applications for adoption. Similarly, this ca ess to failure, or some other metric.</li>
n provide a common basis for utilizing information about a network path or inter </ul>
face, enabling evolution below the transport layer.</t> <t>Beyond these, if the Transport Services API remains the same over time, new
<t>The normative requirements described in this section allow Transport Se protocols and features can be added to the Transport Services Implementation wit
rvices APIs and Transport Services Implementation to provide this functionality hout requiring changes in applications for adoption. Similarly, this can provide
without causing incompatibility or introducing security vulnerabilities.</t> a common basis for utilizing information about a network path or interface, ena
bling evolution below the transport layer.</t>
<t>The normative requirements described in this section allow Transport Se
rvices APIs and the Transport Services Implementation to provide this functional
ity without causing incompatibility or introducing security vulnerabilities.</t>
<section anchor="provide-common-apis-for-common-features"> <section anchor="provide-common-apis-for-common-features">
<name>Provide Common APIs for Common Features</name> <name>Provide Common APIs for Common Features</name>
<t>Any functionality that is common across multiple transport protocols <t>Any functionality that is common across multiple transport protocols
SHOULD be made accessible through a unified set of calls using the Transport Ser <bcp14>SHOULD</bcp14> be made accessible through a unified set of calls using th
vices API. As a baseline, any Transport Services API SHOULD allow access to the e Transport Services API. As a baseline, any Transport Services API <bcp14>SHOUL
minimal set of features offered by transport protocols <xref target="RFC8923"/>. D</bcp14> allow access to the minimal set of features offered by transport proto
If that minimal set is updated or expanded in the future, the Transport Service cols <xref target="RFC8923"/>. If that minimal set is updated or expanded in the
s API ought to be extended to match.</t> future, the Transport Services API ought to be extended to match.</t>
<t>An application can specify constraints and preferences for the protoc <t>An application can specify constraints and preferences for the protoc
ols, features, and network interfaces it will use via Properties. Properties are ols, features, and network interfaces it will use via Properties. Properties are
used by an application to declare its preferences for how the transport service used by an application to declare its preferences for how the transport service
should operate at each stage in the lifetime of a connection. Transport Propert should operate at each stage in the lifetime of a connection. Transport Propert
ies are subdivided into Selection Properties, which specify which paths and Prot ies are subdivided into the following:</t>
ocol Stacks can be used and are preferred by the application; Connection Propert <ul spacing="normal">
ies, which inform decisions made during connection establishment and fine-tune t <li>Selection Properties, which specify which paths and Protocol Stacks can be
he established connection; and Message Properties, set on individual Messages.</ used and are preferred by the application;</li>
t> <li>Connection Properties, which inform decisions made during Connection estab
<t>It is RECOMMENDED that the Transport Services API offers properties t lishment and fine-tune the established connection; and</li>
hat are common to multiple transport protocols. This enables a Transport Service <li>Message Properties, which can be set on individual Messages.</li>
s System to appropriately select between protocols that offer equivalent feature </ul>
s. Similarly, it is RECOMMENDED that the Properties offered by the Transport Ser <t>It is <bcp14>RECOMMENDED</bcp14> that the Transport Services API offe
vices API are applicable to a variety of network layer interfaces and paths, wh r Properties that are common to multiple transport protocols. This enables a Tra
ich permits racing of different network paths without affecting the applications nsport Services System to appropriately select between protocols that offer equi
using the API. Each is expected to have a default value.</t> valent features. Similarly, it is <bcp14>RECOMMENDED</bcp14> that the Properties
<t>It is RECOMMENDED that the default values for Properties are selected offered by the Transport Services API be applicable to a variety of network-lay
to ensure correctness for the widest set of applications, while providing the w er interfaces and paths, to permit racing of different network paths without aff
idest set of options for selection. For example, since both applications that re ecting the applications using the API. Each is expected to have a default value.
quire reliability and those that do not require reliability can function correct </t>
ly when a protocol provides reliability, reliability ought to be enabled by defa <t>It is <bcp14>RECOMMENDED</bcp14> that the default values for Properti
ult. As another example, the default value for a Property regarding the selectio es be selected to ensure correctness for the widest set of applications, while p
n of network interfaces ought to permit as many interfaces as possible.</t> roviding the widest set of options for selection. For example, since both applic
<t>Applications using the Transport Services API need to be designed to ations that require reliability and those that do not require reliability can fu
be robust to the automated selection provided by the Transport Services System. nction correctly when a protocol provides reliability, reliability ought to be e
This automated selection is constrained by the properties and preferences expres nabled by default. As another example, the default value for a Property regardin
sed by the application and requires applications to explicitly set properties th g the selection of network interfaces ought to permit as many interfaces as poss
at define any necessary constraints on protocol, path, and interface selection.< ible.</t>
/t> <t>Applications using the Transport Services API need to be designed to
be robust to the automated selection provided by the Transport Services System.
This automated selection is constrained by the preferences expressed by the appl
ication and requires applications to explicitly set Properties that define any n
ecessary constraints on protocol, path, and interface selection.</t>
</section> </section>
<section anchor="allow-access-to-specialized-features"> <section anchor="allow-access-to-specialized-features">
<name>Allow Access to Specialized Features</name> <name>Allow Access to Specialized Features</name>
<t>There are applications that will need to control fine-grained details <t>There are applications that will need to control fine-grained details
of transport protocols to optimize their behavior and ensure compatibility with of transport protocols to optimize their behavior and ensure compatibility with
remote systems. It is therefore RECOMMENDED that the Transport Services API and remote systems. It is therefore <bcp14>RECOMMENDED</bcp14> that the Transport S
the Transport Services Implementation permit more specialized protocol features ervices API and the Transport Services Implementation permit more specialized pr
to be used.</t> otocol features to be used.</t>
<t>A specialized feature could be needed by an application only when usi <t>Some specialized features could be needed by an application only when
ng a specific protocol, and not when using others. For example, if an applicatio using a specific protocol and not when using others. For example, if an applica
n is using TCP, it could require control over the User Timeout Option for TCP <x tion is using TCP, it could require control over the User Timeout Option for TCP
ref target="RFC5482"/>; these options would not take effect for other transport <xref target="RFC5482"/>. Such features would not take effect for other transpo
protocols. In such cases, the API ought to expose the features in such a way tha rt protocols. In such cases, the API ought to expose the features in such a way
t they take effect when a particular protocol is selected, but do not imply that that they take effect when a particular protocol is selected but do not imply th
only that protocol could be used. For example, if the API allows an application at only that protocol could be used. For example, if the API allows an applicati
to specify a preference to use the User Timeout Option, communication would not on to specify a preference for using the User Timeout Option, communication woul
fail when a protocol such as UDP is selected.</t> d not fail when a protocol such as UDP is selected.</t>
<t>Other specialized features, however, can also be strictly required by an application and thus further constrain the set of protocols that can be used . For example, if an application requires support for automatic handover or fail over for a connection, only Protocol Stacks that provide this feature are eligib le to be used, e.g., Protocol Stacks that include a multipath protocol or a prot ocol 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 cor e/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 cha nging the core implementation.</t> <t>Other specialized features, however, can also be strictly required by an application and thus further constrain the set of protocols that can be used . For example, if an application requires support for automatic handover or fail over for a connection, only Protocol Stacks that provide this feature are eligib le to be used, e.g., Protocol Stacks that include a multipath protocol or a prot ocol 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 cor e/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 cha nging the core implementation.</t>
<t>To control these specialized features, the application can declare it s preference – whether the presence of a specific feature is prohibited, should be avoided, can be ignored, is preferred, or is required in the pre-establishmen t phase. An implementation of a Transport Services API would honor this preferen ce and allow the application to query the availability of each specialized featu re after a successful establishment.</t> <t>To control these specialized features, the application can declare it s preference: whether the presence of a specific feature is prohibited, should b e avoided, can be ignored, is preferred, or is required in the preestablishment phase. An implementation of a Transport Services API would honor this preference and allow the application to query the availability of each specialized feature after successful establishment.</t>
</section> </section>
<section anchor="equivalence"> <section anchor="equivalence">
<name>Select Between Equivalent Protocol Stacks</name> <name>Select Between Equivalent Protocol Stacks</name>
<t>A Transport Services Implementation can attempt and select between mu ltiple Protocol Stacks based on the Selection and Connection Properties communic ated by the application, along with any Security Parameters. The implementation can only attempt to use multiple Protocol Stacks when they are "equivalent", whi ch means that the stacks can provide the same Transport Properties and interface expectations as requested by the application. Equivalent Protocol Stacks can be safely swapped or raced in parallel (see <xref target="racing"/>) during connec tion establishment.</t> <t>A Transport Services Implementation can attempt to use, and select be tween, multiple Protocol Stacks based on the Selection and Connection Properties communicated by the application, along with any Security Parameters. The implem entation can only attempt to use multiple Protocol Stacks when they are "equival ent", which means that the stacks can provide the same Transport Properties and interface expectations as requested by the application. Equivalent Protocol Stac ks can be safely swapped or raced in parallel (see <xref target="racing"/>) duri ng Connection establishment.</t>
<t>The following two examples show non-equivalent Protocol Stacks:</t> <t>The following two examples show non-equivalent Protocol Stacks:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If the application requires preservation of message boundaries, a Protocol Stack that runs UDP as the top-level interface to the application is n ot equivalent to a Protocol Stack that runs TCP as the top-level interface. A UD P stack would allow an application to read out message boundaries based on datag rams sent from the remote system, whereas TCP does not preserve message boundari es on its own, but needs a framing protocol on top to determine message boundari es.</t> <t>If the application requires preservation of Message boundaries, a Protocol Stack that runs UDP as the top-level interface to the application is n ot equivalent to a Protocol Stack that runs TCP as the top-level interface. A UD P stack would allow an application to read out Message boundaries based on datag rams sent from the remote system, whereas TCP does not preserve Message boundari es on its own but needs a framing protocol on top to determine Message boundarie s.</t>
</li> </li>
<li> <li>
<t>If the application specifies that it requires reliable transmissi on 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.</t> <t>If the application specifies that it requires reliable transmissi on 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.</t>
</li> </li>
</ul> </ul>
<t>The following example shows Equivalent Protocol Stacks:</t> <t>The following example shows equivalent Protocol Stacks:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If the application does not require reliable transmission of data , then a Protocol Stack that adds reliability could be regarded as an Equivalent Protocol Stack as long as providing this would not conflict with any other appl ication-requested properties.</t> <t>If the application does not require reliable transmission of data , then a Protocol Stack that adds reliability could be regarded as an equivalent Protocol Stack as long as providing this would not conflict with any other appl ication-requested Properties.</t>
</li> </li>
</ul> </ul>
<t>A Transport Services Implementation can race different security <t>A Transport Services Implementation can race different security
protocols, e.g., if the System Policy is explicitly configured to consider them equivalent. protocols, e.g., if the System Policy is explicitly configured to consider them equivalent.
A Transport Services implementation SHOULD only race Protocol Stacks where the t A Transport Services Implementation <bcp14>SHOULD</bcp14> only race Protocol Sta
ransport security protocols within the stacks are identical. cks where the transport security protocols within the stacks are identical.
To ensure that security protocols are not incorrectly swapped, a Transport Servi To ensure that security protocols are not incorrectly swapped, a Transport Servi
ces Implementation MUST only select Protocol Stacks that meet application requir ces Implementation <bcp14>MUST</bcp14> only select Protocol Stacks that meet app
ements (<xref target="RFC8922"/>). lication requirements <xref target="RFC8922"/>.
A Transport Services Implementation MUST NOT automatically fall back from secure A Transport Services Implementation <bcp14>MUST NOT</bcp14> automatically fall b
protocols to insecure protocols, or to weaker versions of secure protocols. ack from secure protocols to insecure protocols or fall back to weaker versions
A Transport Services Implementation MAY allow applications to explicitly specify of secure protocols.
which versions of a protocol ought to be permitted, e.g., to allow a minimum ve A Transport Services Implementation <bcp14>MAY</bcp14> allow applications to exp
rsion of TLS 1.2 in case TLS 1.3 is not available.</t> licitly specify which versions of a protocol ought to be permitted, e.g., to all
<t>A Transport Services Implementation MAY specify security properties r ow a minimum version of TLS 1.2 if TLS 1.3 is not available.</t>
elating to how the system operates (e.g., requirements, prohibitions, and prefer <t>A Transport Services Implementation <bcp14>MAY</bcp14> specify securi
ences for the use of DNS Security Extensions (DNSSEC) or DNS over HTTPS (DoH)).< ty Properties relating to how the system operates (e.g., requirements, prohibiti
/t> ons, and preferences for the use of DNS Security Extensions (DNSSEC) or DNS over
HTTPS (DoH)).</t>
</section> </section>
<section anchor="maintain-interoperability"> <section anchor="maintain-interoperability">
<name>Maintain Interoperability</name> <name>Maintain Interoperability</name>
<t>It is important to note that neither the Transport Services API <xref <t>It is important to note that neither the Transport Services API <xref
target="I-D.ietf-taps-interface"/> nor the guidelines for implementation of the target="RFC9622"/> nor the guidelines for implementation of the Transport Servi
Transport Service System <xref target="I-D.ietf-taps-impl"/> define new protoco ces System <xref target="RFC9623"/> define new protocols or protocol capabilitie
ls or protocol capabilities that affect what is communicated across the network. s that affect what is communicated across the network. A Transport Services Syst
A Transport Services System MUST NOT require that a peer on the other side of a em <bcp14>MUST NOT</bcp14> require that a peer on the other side of a connection
connection uses the same API or implementation. A Transport Services Implementa use the same API or implementation. A Transport Services Implementation acting
tion acting as a connection initiator is able to communicate with any existing E as a connection initiator is able to communicate with any existing Endpoint that
ndpoint that implements the transport protocol(s) and all the required propertie implements the transport protocol(s) and all the required Properties selected.
s selected. Similarly, a Transport Services Implementation acting as a Listener Similarly, a Transport Services Implementation acting as a Listener can receive
can receive connections for any protocol that is supported from an existing init connections for any protocol that is supported from an existing initiator that i
iator that implements the protocol, independent of whether the initiator uses th mplements the protocol, independently of whether or not the initiator uses the T
e Transport Services System or not.</t> ransport Services System.</t>
<t>A Transport Services Implemenation makes decisions that select protoc <t>A Transport Services Implementation makes decisions that select proto
ols and interfaces. In normal use, a given version of a Transport Services Syste cols and interfaces. In normal use, a given version of a Transport Services Syst
m SHOULD result in consistent protocol and interface selection decisions for the em <bcp14>SHOULD</bcp14> result in consistent protocol and interface selection d
same network conditions given the same set of Properties. This is intended to p ecisions for the same network conditions, given the same set of Properties. This
rovide predictable outcomes to the application using the API.</t> is intended to provide predictable outcomes to the application using the API.</
t>
</section> </section>
<section anchor="support-monitoring"> <section anchor="support-monitoring">
<name>Support Monitoring</name> <name>Support Monitoring</name>
<t>The Transport Services API increases the layer of abstraction for app lications, and it enables greater automation below the API. Such increased <t>The Transport Services API increases the layer of abstraction for app lications, and it enables greater automation below the API. Such increased
abstraction comes at the cost of increased complexity when application programme abstraction comes at the cost of increased complexity when application programme
rs, users or system administrators rs, users, or system administrators
try to understand why any issues and failures may be happening. Transport Servic try to understand why any issues and failures may be happening.
es systems should therefore offer monitoring functions that A Transport Services System should therefore offer monitoring functions that
provide relevant debug and diagnostics information. For example, such monitoring functions could indicate the protocol(s) in use, the provide relevant debug and diagnostics information. For example, such monitoring functions could indicate the protocol(s) in use, the
number of open connections per protocol, and any statistics that these protocols may offer.</t> number of open connections per protocol, and any statistics that these protocols may offer.</t>
</section> </section>
</section> </section>
<section anchor="concepts"> <section anchor="concepts">
<name>Transport Services Architecture and Concepts</name> <name>Transport Services Architecture and Concepts</name>
<t>This section of the document describes the architecture non-normatively <t>This section describes the architecture non-normatively and explains th
and explains the operation of a Transport Services Implementation. The concepts e operation of a Transport Services Implementation. The concepts defined in this
defined in this document are intended primarily for use in the documents and sp document are intended primarily for use in the documents and specifications tha
ecifications that describe the Transport Services System. This includes the arch t describe the Transport Services System. This includes the architecture, the Tr
itecture, the Transport Services API and the associated Transport Services Imple ansport Services API, and the associated Transport Services Implementation. Whil
mentation. While the specific terminology can be used in some implementations, i e the specific terminology can be used in some implementations, it is expected t
t is expected that there will remain a variety of terms used by running code.</t hat there will remain a variety of terms used by running code.</t>
> <t>The architecture divides the concepts for the Transport Services System
<t>The architecture divides the concepts for Transport Services System int into two categories:</t>
o two categories:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>API concepts, which are intended to be exposed to applications; and </t> <t>API concepts, which are intended to be exposed to applications; and </t>
</li> </li>
<li> <li>
<t>System-implementation concepts, which are intended to be internally used by a Transport Services Implementation.</t> <t>System-implementation concepts, which are intended to be internally used by a Transport Services Implementation.</t>
</li> </li>
</ol> </ol>
<t>The following diagram summarizes the top-level concepts in a Transport Services System and how they relate to one another.</t> <t>The following diagram summarizes the top-level concepts in a Transport Services System and how they relate to one another.</t>
<figure anchor="fig-abstractions"> <figure anchor="fig-abstractions">
<name>Concepts and Relationships in the Architecture of the Transport Se rvices System</name> <name>Concepts and Relationships in the Architecture of the Transport Se rvices System</name>
skipping to change at line 496 skipping to change at line 491
| | | | | |
| (Candidate Racing) | +-----------------+ | | (Candidate Racing) | +-----------------+ |
| | | System | | | | | System | |
| | | Policy | | | | | Policy | |
| +----------v-----+ +-----------------+ | | +----------v-----+ +-----------------+ |
| | Protocol | | | | Protocol | |
+-------------+ Stack(s) +----------------------+ +-------------+ Stack(s) +----------------------+
+-------+--------+ +-------+--------+
V V
+-----------------------------------------------------+ +-----------------------------------------------------+
| Network Layer Interface | | Network-Layer Interface |
+-----------------------------------------------------+ +-----------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The Transport Services Implementation includes the Cached State and Sys tem Policy.</t> <t>The Transport Services Implementation includes the Cached State and Sys tem Policy.</t>
<t>The System Policy provides input from an operating system or other glob <t>The System Policy provides input from an operating system or other glob
al preferences that can constrain or influence how an implementation will gather al preferences that can constrain or influence how an implementation will gather
Candidate Paths and Protocol Stacks and race the candidates when establishing a Candidate Paths and Protocol Stacks and race the candidates when establishing a
Connection. As the details of System Policy configuration and enforcement are l Connection. As the details of System Policy configuration and enforcement are l
argely platform- and implementation- dependent, and do not affect application-le argely dependent on the platform and implementation and do not affect applicatio
vel interoperability, the Transport Services API <xref target="I-D.ietf-taps-int n-level interoperability, the Transport Services API <xref target="RFC9622"/> do
erface"/> does not specify an interface for reading or writing System Policy.</t es not specify an interface for reading or writing System Policy.</t>
> <t>The Cached State is the state and history that the Transport Services I
<t>The Cached State is the state and history that the Transport Services I mplementation keeps for each set of associated Endpoints that have previously be
mplementation keeps for each set of associated Endpoints that have previously be en used. An application ought to explicitly request any required or preferred Pr
en used. An application ought to explicitly request any required or desired prop operties via the Transport Services API.</t>
erties via the Transport Services API.</t>
<section anchor="transport-services-api-concepts"> <section anchor="transport-services-api-concepts">
<name>Transport Services API Concepts</name> <name>Transport Services API Concepts</name>
<t>Fundamentally, a Transport Services API needs to provide Connection o bjects (<xref target="objects"/>) that allow applications to establish communica tion, and then send and receive data. These could be exposed as handles or refer enced objects, depending on the chosen programming language.</t> <t>Fundamentally, a Transport Services API needs to provide Connection o bjects (<xref target="objects"/>) that allow applications to establish communica tion and then send and receive data. These could be exposed as handles or refere nced objects, depending on the chosen programming language.</t>
<t>Beyond the Connection objects, there are several high-level groups of actions that any Transport Services API needs to provide:</t> <t>Beyond the Connection objects, there are several high-level groups of actions that any Transport Services API needs to provide:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Pre-establishment (<xref target="preestablishment"/>) encompasses the properties that an application can pass to describe its intent, requirement s, prohibitions, and preferences for its networking operations. These properties apply to multiple transport protocols, unless otherwise specified. Properties s pecified during pre-establishment can have a large impact on the rest of the int erface: they modify how establishment occurs, they influence the expectations ar ound data transfer, and they determine the set of events that will be supported. </t> <t>Preestablishment (<xref target="preestablishment"/>) encompasses the Properties that an application can pass to describe its intent, requirements , prohibitions, and preferences for its networking operations. These Properties apply to multiple transport protocols, unless otherwise specified. Properties sp ecified during preestablishment can have a large impact on the rest of the inter face: they modify how establishment occurs, influence the expectations around da ta transfer, and determine the set of events that will be supported.</t>
</li> </li>
<li> <li>
<t>Establishment (<xref target="establishment"/>) focuses on the act ions that an application takes on the Connection objects to prepare for data tra nsfer.</t> <t>Establishment (<xref target="establishment"/>) focuses on the act ions that an application takes on the Connection objects to prepare for data tra nsfer.</t>
</li> </li>
<li> <li>
<t>Data Transfer (<xref target="datatransfer"/>) consists of how an application represents the data to be sent and received, the functions required to send and receive that data, and how the application is notified of the status of its data transfer.</t> <t>Data transfer (<xref target="datatransfer"/>) consists of how an application represents the data to be sent and received, the functions required to send and receive that data, and how the application is notified of the status of its data transfer.</t>
</li> </li>
<li> <li>
<t>Event Handling (<xref target="events"/>) defines categories of no tifications that an application can receive during the lifetime of a Connection. Events also provide opportunities for the application to interact with the unde rlying transport by querying state or updating maintenance options.</t> <t>Event handling (<xref target="events"/>) defines categories of no tifications that an application can receive during the lifetime of a Connection. Events also provide opportunities for the application to interact with the unde rlying transport by querying state or updating maintenance options.</t>
</li> </li>
<li> <li>
<t>Termination (<xref target="termination"/>) focuses on the methods by which data transmission is stopped, and connection state is torn down.</t> <t>Termination (<xref target="termination"/>) focuses on the methods by which data transmission is stopped and connection state is torn down.</t>
</li> </li>
</ul> </ul>
<t>The diagram below provides a high-level view of the actions and event s during the lifetime of a Connection object. Note that some actions are alterna tives (e.g., whether to initiate a connection or to listen for incoming connecti ons), while others are optional (e.g., setting Connection and Message Properties in pre-establishment) or have been omitted for brevity and simplicity.</t> <t>The diagram below provides a high-level view of the actions and event s during the lifetime of a Connection object. Note that some actions are alterna tives (e.g., whether to initiate a connection or listen for incoming connections ), while others are optional (e.g., setting Connection and Message Properties in preestablishment) or have been omitted for brevity and simplicity.</t>
<figure anchor="fig-lifetime"> <figure anchor="fig-lifetime">
<name>The lifetime of a Connection object</name> <name>The Lifetime of a Connection Object</name>
<artwork><![CDATA[ <artwork><![CDATA[
Pre-establishment : Established : Termination
----------------- : ----------- : ----------- Preestablishment : Established : Termination
: : ----------------- : ----------- : -----------
+-- Local Endpoint : Message : : :
+-- Remote Endpoint : Receive() | : +-- Local Endpoint : Message :
+-- Transport Properties : Send() | : +-- Remote Endpoint : Receive() | :
+-- Security Parameters : | : +-- Transport Properties : Send() | :
| : | : +-- Security Parameters : | :
| InitiateWithSend() | Close() : | : | :
| +---------------+ Initiate() +-----+------+ Abort() : | InitiateWithSend() | Close() :
+---+ Preconnection |------------->| Connection |-----------> Closed | +---------------+ Initiate() +-----+------+ Abort() :
+---------------+ Rendezvous() +------------+ : +---+ Preconnection |------------->| Connection |-----------> Closed
Listen() | : | | : +---------------+ Rendezvous() +------------+ :
| : | v : Listen() | : | | :
v : | Connection : | : | v :
+----------+ : | Ready : v : | Connection :
| Listener |----------------------+ : +----------+ : | Ready :
+----------+ Connection Received : | Listener |----------------------+ :
: : +----------+ Connection Received :
: :
]]></artwork> ]]></artwork>
</figure> </figure>
<t>In this diagram, the lifetime of a Connection object is divided into three phases: <t>In this diagram, the lifetime of a Connection object is divided into three phases:
pre-establishment, the Established state, and Termination.</t> preestablishment, the Established state, and termination of a Connection.</t>
<t>Pre-establishment is based around a Preconnection object, that contai <t>Preestablishment is based around a Preconnection object containing va
ns various rious
sub-objects that describe the properties and parameters of desired Connections sub-objects that describe the Properties and parameters of desired Connections
(Local and Remote Endpoints, Transport Properties, and Security Parameters). (Local and Remote Endpoints, Transport Properties, and Security Parameters).
A Preconnection can be used to start listening for inbound connections, A Preconnection can be used to start listening for inbound connections --
in which case a Listener object is created, or can be used to establish a new in which case a Listener object is created -- or can be used to establish a new
connection directly using <tt>Initiate</tt> (for outbound connections) or <tt>Re ndezvous</tt> connection directly using <tt>Initiate</tt> (for outbound connections) or <tt>Re ndezvous</tt>
(for peer-to-peer connections).</t> (for peer-to-peer connections).</t>
<!-- [rfced] Please review usage of <tt> in this document, and let us
know if any updates are needed. For example, we see
"to initiate a connection" (no <tt>) and "to Initiate a Connection"
in the XML file. -->
<t>Once a Connection is in the Established state, an application can sen d and receive <t>Once a Connection is in the Established state, an application can sen d and receive
Message objects, and receive state updates.</t> Message objects and can receive state updates.</t>
<t>Closing or aborting a connection, either locally or from the peer, ca <t>Closing or aborting a Connection, either locally or from the peer, ca
n terminate n terminate
a connection.</t> a Connection.</t>
<section anchor="endpoint-objects"> <section anchor="endpoint-objects">
<name>Endpoint Objects</name> <name>Endpoint Objects</name>
<t>An Endpoint Identifier specifies one side of a transport connection . <t>An Endpoint Identifier specifies one side of a transport connection .
Endpoints can be Local Endpoints or Remote Endpoints, and the Endpoint Identif iers can respectively represent an identity Endpoints can be Local Endpoints or Remote Endpoints, and the Endpoint Identif iers can respectively represent an identity
that the application uses for the source or destination of a connection. that the application uses for the source or destination of a connection.
An Endpoint Identifier can be specified at various levels of abstraction. An Endpoint Identifier can be specified at various levels of abstraction.
An Endpoint Identifier at a higher level of abstraction (such as a hostname) c an be resolved to more concrete identities An Endpoint Identifier at a higher level of abstraction (such as a hostname) c an be resolved to more concrete identities
(such as IP addresses). A Remote Endpoint Identifier can also represent a mult icast group or anycast address. (such as IP addresses). A Remote Endpoint Identifier can also represent a mult icast group or anycast address.
In the case of multicast, this selects a multicast transport for communication In the case of multicast, a multicast transport will be selected for communica
.</t> tion.</t>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t>Remote Endpoint Identifier: The Remote Endpoint Identifier repr <dt>Remote Endpoint Identifier:</dt><dd>The Remote Endpoint Identi
esents the application's identifier for a peer that can participate in a transpo fier represents the application's identifier for a peer that can participate in
rt connection; for example, the combination of a DNS name for the peer and a ser a transport connection, for example, the combination of a DNS name for the peer
vice name/port.</t> and a service name/port.</dd>
</li>
<li> <dt>Local Endpoint Identifier:</dt><dd>The Local Endpoint Identifi
<t>Local Endpoint Identifier: The Local Endpoint Identifier repres er represents the application's identifier for itself that it uses for transport
ents the application's identifier for itself that it uses for transport connecti connections, for example, a local IP address and port.</dd>
ons; for example, a local IP address and port.</t> </dl>
</li>
</ul>
</section> </section>
<section anchor="objects"> <section anchor="objects">
<name>Connections and Related Objects</name> <name>Connections and Related Objects</name>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t>Connection: A Connection object represents one or more active t <dt>Connection:</dt><dd>A Connection object represents one or more
ransport protocol instances that can send and/or receive Messages between Local active transport protocol instances that can send and/or receive Messages betwe
and Remote Endpoints. It is an abstraction that represents the communication. Th en Local and Remote Endpoints. It is an abstraction that represents the communic
e Connection object holds state pertaining to the underlying transport protocol ation. The Connection object holds state pertaining to the underlying transport
instances and any ongoing data transfers. For example, an active Connection can protocol instances and any ongoing data transfers. For example, an active Connec
represent a connection-oriented protocol such as TCP, or can represent a fully-s tion can represent a connection-oriented protocol such as TCP, or it can represe
pecified 5-tuple for a connectionless protocol such as UDP, where the Connection nt a fully specified 5-tuple for a connectionless protocol such as UDP, where th
remains an abstraction at the endpoints. It can also represent a pool of transp e Connection remains an abstraction at the endpoints. It can also represent a po
ort protocol instances, e.g., a set of TCP and QUIC connections to equivalent en ol of transport protocol instances, e.g., a set of TCP and QUIC connections to e
dpoints, or a stream of a multi-streaming transport protocol instance. Connectio quivalent endpoints, or a stream of a multistreaming transport protocol instance
ns can be created from a Preconnection or by a Listener.</t> . Connections can be created from a Preconnection or by a Listener.</dd>
</li>
<li> <dt>Preconnection:</dt><dd>A Preconnection object is a representat
<t>Preconnection: A Preconnection object is a representation of a ion of a Connection that has not yet been established. It has state that describ
Connection that has not yet been established. It has state that describes parame es parameters of the Connection: the Local Endpoint Identifier from which that C
ters of the Connection: the Local Endpoint Identifier from which that Connection onnection will be established, the Remote Endpoint Identifier to which it will c
will be established, the Remote Endpoint Identifier (<xref target="preestablish onnect, and Transport Properties that influence the paths and protocols a Connec
ment"/>) to which it will connect, and Transport Properties that influence the p tion will use. A Preconnection can be either fully specified (representing a sin
aths and protocols a Connection will use. A Preconnection can be either fully sp gle possible Connection) or partially specified (representing a family of possib
ecified (representing a single possible Connection), or it can be partially spec le Connections). The Local Endpoint (<xref target="preestablishment"/>) is requi
ified (representing a family of possible Connections). The Local Endpoint (<xref red for a Preconnection used to <tt>Listen</tt> for incoming Connections but is
target="preestablishment"/>) is required for a Preconnection used to <tt>Listen optional if it is used to <tt>Initiate</tt> a Connection. The Remote Endpoint Id
</tt> for incoming Connections, but optional if it is used to <tt>Initiate</tt> entifier is required in a Preconnection that is used to <tt>Initiate</tt> a Conn
a Connection. The Remote Endpoint Identifier is required in a Preconnection that ection but is optional if it is used to <tt>Listen</tt> for incoming Connections
used to <tt>Initiate</tt> a Connection, but is optional if it is used to <tt>Li . The Local Endpoint Identifier and the Remote Endpoint Identifier are both requ
sten</tt> for incoming Connections. The Local Endpoint Identifier and the Remote ired if a peer-to-peer <tt>Rendezvous</tt> is to occur based on the Preconnectio
Endpoint Identifier are both required if a peer-to-peer <tt>Rendezvous</tt> is n.</dd>
to occur based on the Preconnection.</t>
</li> <dt>Transport Properties:</dt><dd><t>Transport Properties allow th
<li> e application to express requirements, prohibitions, and preferences and configu
<t>Transport Properties: Transport Properties allow the applicatio re a Transport Services Implementation. There are three kinds of Transport Prop
n to express their requirements, prohibitions, and preferences and configure a T erties: </t>
ransport Services Implementation. There are three kinds of Transport Properties <dl spacing="normal">
: </t>
<ul spacing="normal"> <dt>Selection Properties (<xref target="preestablishment"/>):<
<li> /dt><dd>Selection Properties can only be specified on a Preconnection.</dd>
<t>Selection Properties (<xref target="preestablishment"/>): S
election Properties can only be specified on a Preconnection.</t> <dt>Connection Properties (<xref target="preestablishment"/>):
</li> </dt><dd>Connection Properties can be specified on a Preconnection and changed o
<li> n the Connection.</dd>
<t>Connection Properties (<xref target="preestablishment"/>):
Connection Properties can be specified on a Preconnection and changed on the Con <dt>Message Properties (<xref target="datatransfer"/>):</dt><d
nection.</t> d>Message Properties can be specified as defaults on a Preconnection or a Connec
</li> tion and can also be specified during data transfer to affect specific Messages.
<li> </dd>
<t>Message Properties (<xref target="datatransfer"/>): Message </dl>
Properties can be specified as defaults on a Preconnection or a Connection, and </dd>
can also be specified during data transfer to affect specific Messages.</t>
</li> <dt>Listener:</dt><dd>A Listener object accepts incoming transport
</ul> protocol connections from Remote Endpoints and generates corresponding Connecti
</li> on objects. It is created from a Preconnection object that specifies the type of
<li> incoming Connections it will accept.</dd>
<t>Listener: A Listener object accepts incoming transport protocol </dl>
connections from Remote Endpoints and generates corresponding Connection object
s. It is created from a Preconnection object that specifies the type of incoming
Connections it will accept.</t>
</li>
</ul>
</section> </section>
<section anchor="preestablishment"> <section anchor="preestablishment">
<name>Pre-establishment</name> <name>Preestablishment</name>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t>Selection Properties: The Selection Properties consist of the p <dt>Selection Properties:</dt><dd>Selection Properties consist of
roperties that an application can set to influence the selection of paths betwee the Properties that an application can set to influence the selection of paths b
n the Local and Remote Endpoints, to influence the selection of transport protoc etween the Local and Remote Endpoints, influence the selection of transport prot
ols, or to configure the behavior of generic transport protocol features. These ocols, or configure the behavior of generic transport protocol features. These P
properties can take the form of requirements, prohibitions, or preferences. Exam roperties can take the form of requirements, prohibitions, or preferences. Examp
ples of properties that influence path selection include the interface type (suc les of Properties that influence path selection include the interface type (such
h as a Wi-Fi connection, or a Cellular LTE connection), requirements around the as a Wi-Fi connection or a Cellular LTE connection), requirements around the la
largest Message that can be sent, or preferences for throughput and latency. Exa rgest Message that can be sent, or preferences for throughput and latency. Examp
mples of properties that influence protocol selection and configuration of trans les of Properties that influence protocol selection and configuration of transpo
port protocol features include reliability, multipath support, and fast open sup rt protocol features include reliability, multipath support, and support for TCP
port.</t> Fast Open.</dd>
</li>
<li> <dt>Connection Properties:</dt><dd>Connection Properties are used
<t>Connection Properties: The Connection Properties are used to co to configure protocol-specific options and control per-connection behavior of a
nfigure protocol-specific options and control per-connection behavior of a Trans Transport Services Implementation; for example, a protocol-specific Connection P
port Services Implementation; for example, a protocol-specific Connection Proper roperty can express that if TCP is used, the implementation ought to use the Use
ty can express that if TCP is used, the implementation ought to use the User Tim r Timeout Option. Note that the presence of such a property does not require tha
eout Option. Note that the presence of such a property does not require that a s t a specific protocol be used. In general, these Properties do not explicitly de
pecific protocol will be used. In general, these properties do not explicitly de termine the selection of paths or protocols but can be used by an implementation
termine the selection of paths or protocols, but can be used by an implementatio during Connection establishment. Connection Properties are specified on a Preco
n during connection establishment. Connection Properties are specified on a Prec nnection prior to Connection establishment and can be modified on the Connection
onnection prior to Connection establishment, and can be modified on the Connecti later. Changes made to Connection Properties after Connection establishment tak
on later. Changes made to Connection Properties after Connection establishment t e effect on a best-effort basis.</dd>
ake effect on a best-effort basis.</t>
</li> <dt>Security Parameters:</dt><dd>Security Parameters define an app
<li> lication's requirements for authentication and encryption on a Connection. They
<t>Security Parameters: Security Parameters define an application' are used by transport security protocols (such as those described in <xref targe
s requirements for authentication and encryption on a Connection. They are used t="RFC8922"/>) to establish secure Connections. Examples of parameters that can
by Transport Security protocols (such as those described in <xref target="RFC892 be set include local identities, private keys, supported cryptographic algorithm
2"/>) to establish secure Connections. Examples of parameters that can be set in s, and requirements for validating trust of remote identities. Security Paramete
clude local identities, private keys, supported cryptographic algorithms, and re rs are primarily associated with a Preconnection object, but Properties related
quirements for validating trust of remote identities. Security Parameters are pr to identities can be associated directly with Endpoints.</dd>
imarily associated with a Preconnection object, but properties related to identi </dl>
ties can be associated directly with Endpoints.</t>
</li>
</ul>
</section> </section>
<section anchor="establishment"> <section anchor="establishment">
<name>Establishment Actions</name> <name>Establishment Actions</name>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t>Initiate: The primary action that an application can take to cr <dt>Initiate:</dt><dd>The primary action that an application can t
eate a Connection to a Remote Endpoint, and prepare any required local or remote ake to create a Connection to a Remote Endpoint and prepare any required local o
state to enable the transmission of Messages. For some protocols, this will ini r remote state to enable the transmission of Messages. For some protocols, this
tiate a client-to-server style handshake; for other protocols, this will just es will initiate a client-to-server-style handshake; for other protocols, this will
tablish local state (e.g., with connectionless protocols such as UDP). The proce just establish local state (e.g., with connectionless protocols such as UDP). T
ss of identifying options for connecting, such as resolution of the Remote Endpo he process of identifying options for connecting, such as resolution of the Remo
int Identifier, occurs in response to the <tt>Initiate</tt> call.</t> te Endpoint Identifier, occurs in response to calling <tt>Initiate</tt>.</dd>
</li>
<li> <dt>Listen:</dt><dd>Enables a Listener to accept incoming connecti
<t>Listen: Enables a Listener to accept incoming connections. The ons. The Listener will then create Connection objects as incoming connections ar
Listener will then create Connection objects as incoming connections are accepte e accepted (<xref target="events"/>). Listeners by default register with multipl
d (<xref target="events"/>). Listeners by default register with multiple paths, e paths, protocols, and Local Endpoints, unless constrained by Selection Propert
protocols, and Local Endpoints, unless constrained by Selection Properties and/o ies and/or the specified Local Endpoint Identifier(s). Connections can be accept
r the specified Local Endpoint Identifier(s). Connections can be accepted on any ed on any of the available paths or endpoints.</dd>
of the available paths or endpoints.</t>
</li> <dt>Rendezvous:</dt><dd>The action of establishing a peer-to-peer
<li> connection with a Remote Endpoint. It simultaneously attempts to initiate a conn
<t>Rendezvous: The action of establishing a peer-to-peer connectio ection to
n with a
Remote Endpoint. It simultaneously attempts to initiate a connection to
a Remote Endpoint while listening for an incoming connection from that a Remote Endpoint while listening for an incoming connection from that
Endpoint. The process of identifying options for the connection, such Endpoint. The process of identifying options for the connection, such
as resolution of the Remote Endpoint Identifier(s), occurs in response to the <t t>Rendezvous</tt> call. as resolution of the Remote Endpoint Identifier(s), occurs in response to callin g <tt>Rendezvous</tt>.
As with Listeners, the set of local paths and endpoints is constrained As with Listeners, the set of local paths and endpoints is constrained
by Selection Properties. If successful, the <tt>Rendezvous</tt> call generates a nd asynchronously returns a by Selection Properties. If successful, calling <tt>Rendezvous</tt> generates an d asynchronously returns a
Connection object to represent the established peer-to-peer connection. Connection object to represent the established peer-to-peer connection.
The processes by which connections are initiated during a <tt>Rendezvous</tt> The processes by which connections are initiated during a <tt>Rendezvous</tt>
action will depend on the set of Local and Remote Endpoints configured on action will depend on the set of Local and Remote Endpoints configured on
the Preconnection. For example, if the Local and Remote Endpoints are TCP the Preconnection. For example, if the Local and Remote Endpoints are TCP
host candidates, then a TCP simultaneous open <xref target="RFC9293"/> might be performed. host candidates, then a TCP simultaneous open <xref target="RFC9293"/> might be performed.
However, if the set of Local Endpoints includes server reflexive However, if the set of Local Endpoints includes server-reflexive
candidates, such as those provided by STUN (Session Traversal Utilities candidates, such as those provided by STUN (Session Traversal Utilities
for NAT) <xref target="RFC5389"/>, a <tt>Rendezvous</tt> action will race for NAT) <xref target="RFC8489"/>, a <tt>Rendezvous</tt> action will race
candidates in the style of the ICE (Interactive Connection Establishment) candidates in the style of the ICE (Interactive Connectivity Establishment)
algorithm <xref target="RFC8445"/> to perform NAT algorithm <xref target="RFC8445"/> to perform NAT
binding discovery and initiate a peer-to-peer connection.</t> binding discovery and initiate a peer-to-peer connection.</dd>
</li> </dl>
</ul>
</section> </section>
<section anchor="datatransfer"> <section anchor="datatransfer">
<name>Data Transfer Objects and Actions</name> <name>Data Transfer Objects and Actions</name>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t>Message: A Message object is a unit of data that can be represe <dt>Message:</dt><dd>A Message object is a unit of data that can b
nted as bytes that can be transferred between two endpoints over a transport con e represented as bytes that can be transferred between two endpoints over a tran
nection. The bytes within a Message are assumed to be ordered. If an application sport connection. The bytes within a Message are assumed to be ordered. If an ap
does not care about the order in which a peer receives two distinct spans of by plication does not care about the order in which a peer receives two distinct sp
tes, those spans of bytes are considered independent Messages. Messages are sent ans of bytes, those spans of bytes are considered independent Messages. Messages
in the payload of IP packets. One packet can carry one or more Messages or part are sent in the payload of IP packets. One packet can carry one or more Message
s of a Message.</t> s or parts of a Message.</dd>
</li>
<li> <dt>Message Properties:</dt><dd>Message Properties are used to spe
<t>Message Properties: Message Properties are used to specify deta cify details about Message transmission. They can be specified directly on indiv
ils about Message transmission. They can be specified directly on individual Mes idual Messages or can be set on a Preconnection or Connection as defaults. These
sages, or can be set on a Preconnection or Connection as defaults. These propert Properties might only apply to how a Message is sent (such as how the transport
ies might only apply to how a Message is sent (such as how the transport will tr will treat prioritization and reliability) but can also include Properties that
eat prioritization and reliability), but can also include properties that specif specific protocols encode and communicate to the Remote Endpoint. When receivin
ic protocols encode and communicate to the Remote Endpoint. When receiving Messa g Messages, Message Properties can contain information about the received Messag
ges, Message Properties can contain information about the received Message, such e, such as metadata generated at the receiver and information signaled by the Re
as metadata generated at the receiver and information signalled by the Remote E mote Endpoint. For example, a Message can be marked with a Message Property indi
ndpoint. For example, a Message can be marked with a Message Property indicating cating that it is the final Message on a Connection.</dd>
that it is the final Message on a Connection.</t>
</li> <dt>Send:</dt><dd>The <tt>Send</tt> action transmits a Message ove
<li> r a Connection to the Remote Endpoint. The interface to <tt>Send</tt> can accept
<t>Send: The action to transmit a Message over a Connection to the Message Properties specific to how the Message content is to be sent. The statu
Remote Endpoint. The interface to <tt>Send</tt> can accept Message Properties s s of the <tt>Send</tt> action is delivered back to the sending application in an
pecific to how the Message content is to be sent. The status of the <tt>Send</tt event (<xref target="events"/>).</dd>
> operation is delivered back to the sending application in an event (<xref targ
et="events"/>).</t> <dt>Receive:</dt><dd>The <tt>Receive</tt> action indicates that th
</li> e application is ready to asynchronously accept a Message over a Connection from
<li> a Remote Endpoint, while the Message content itself will be delivered in an eve
<t>Receive: An action that indicates that the application is ready nt (<xref target="events"/>). The interface to <tt>Receive</tt> can include Mess
to asynchronously accept a Message over a Connection from a Remote Endpoint, wh age Properties specific to the Message that is to be delivered to the applicatio
ile the Message content itself will be delivered in an event (<xref target="even n.</dd>
ts"/>). The interface to <tt>Receive</tt> can include Message Properties specifi
c to the Message that is to be delivered to the application.</t> <dt>Framer:</dt><dd>A Framer is a data translation layer that can
</li> be added to a Connection. Framers allow extending a Connection's Protocol Stack
<li> to define how to encapsulate or encode outbound Messages and how to decapsulate
<t>Framer: A Framer is a data translation layer that can be added or decode inbound data into Messages. In this way, Message boundaries can be pre
to a Connection. Framers allow extending a Connection's Protocol Stack to define served when using a Connection object, even with a protocol that otherwise prese
how to encapsulate or encode outbound Messages, and how to decapsulate or decod nts unstructured streams, such as TCP. This is designed based on the fact that m
e inbound data into Messages. In this way, message boundaries can be preserved w any of the current application protocols evolved over TCP, which does not provid
hen using a Connection object, even with a protocol that otherwise presents unst e Message boundary preservation, and since many of these protocols require Messa
ructured streams, such as TCP. This is designed based on the fact that many of t ge boundaries to function, each application-layer protocol has defined its own f
he current application protocols evolved over TCP, which does not provide messag raming. For example, when an HTTP application sends and receives HTTP Messages o
e boundary preservation, and since many of these protocols require message bound ver a byte-stream transport, it must parse the boundaries of HTTP Messages from
aries to function, each application layer protocol has defined its own framing. the stream of bytes.</dd>
For example, when an HTTP application sends and receives HTTP messages over a by </dl>
te-stream transport, it must parse the boundaries of HTTP messages from the stre
am of bytes.</t>
</li>
</ul>
</section> </section>
<section anchor="events"> <section anchor="events">
<name>Event Handling</name> <name>Event Handling</name>
<t>The following categories of events can be delivered to an applicati on:</t> <t>The following categories of events can be delivered to an applicati on:</t>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t>Connection Ready: Signals to an application that a given Connec <dt>Connection Ready:</dt><dd>Signals to an application that a giv
tion is ready to send and/or receive Messages. If the Connection relies on hands en Connection is ready to send and/or receive Messages. If the Connection relies
hakes to establish state between peers, then it is assumed that these steps have on handshakes to establish state between peers, then it is assumed that these s
been taken.</t> teps have been taken.</dd>
</li>
<li> <dt>Connection Closed:</dt><dd>Signals to an application that a gi
<t>Connection Closed: Signals to an application that a given Conne ven Connection is no longer usable for sending or receiving Messages. The event
ction is no longer usable for sending or receiving Messages. The event delivers delivers a reason or error to the application that describes the nature of the t
a reason or error to the application that describes the nature of the terminatio ermination.</dd>
n.</t>
</li> <dt>Connection Received:</dt><dd>Signals to an application that a
<li> given Listener has received a Connection.</dd>
<t>Connection Received: Signals to an application that a given Lis
tener has received a Connection.</t> <dt>Message Received:</dt><dd>Delivers received Message content to
</li> the application, based on a <tt>Receive</tt> action. To allow an application to
<li> limit the occurrence of such events, each call to <tt>Receive</tt> will be pair
<t>Message Received: Delivers received Message content to the appl ed with a single <tt>Receive</tt> event. This can include an error if the <tt>Re
ication, based on a <tt>Receive</tt> action. To allow an application to limit th ceive</tt> action cannot be satisfied, e.g., due to the Connection being closed.
e occurrence of such events, each call to <tt>Receive</tt> will be paired with a </dd>
single <tt>Receive</tt> event. This can include an error if the <tt>Receive</tt
> action cannot be satisfied, e.g., due to the Connection being closed.</t> <dt>Message Sent:</dt><dd>Notifies the application of the status o
</li> f its <tt>Send</tt> action. This might indicate a failure if the Message cannot
<li> be sent or might indicate that the Message has been processed by the Transport S
<t>Message Sent: Notifies the application of the status of its <tt ervices System.</dd>
>Send</tt> 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 S <dt>Path Properties Changed:</dt><dd>Notifies the application that
ystem.</t> a Property of the Connection has changed that might influence how and where dat
</li> a is sent and/or received.</dd>
<li> </dl>
<t>Path Properties Changed: Notifies the application that a proper
ty of the Connection has changed that might influence how and where data is sent
and/or received.</t>
</li>
</ul>
</section> </section>
<section anchor="termination"> <section anchor="termination">
<name>Termination Actions</name> <name>Termination Actions</name>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t>Close: The action an application takes on a Connection to indic <dt>Close:</dt><dd>The action an application takes on a Connection
ate that it no longer intends to send data, is no longer willing to receive data to indicate that it no longer intends to send data or is no longer willing to r
, and that the protocol should signal this state to the Remote Endpoint if the t eceive data. The protocol should signal this state to the Remote Endpoint if th
ransport protocol allows this. (Note that this is distinct from the concept of " e transport protocol permits it. (Note that this is distinct from the concept of
half-closing" a bidirectional connection, such as when a FIN is sent in one dire "half-closing" a bidirectional connection, such as when a FIN is sent in one di
ction of a TCP connection <xref target="RFC9293"/>. The end of a stream can also rection of a TCP connection <xref target="RFC9293"/>. The end of a stream can al
be indicated using Message Properties when sending.)</t> so be indicated using Message Properties when sending.)</dd>
</li>
<li> <dt>Abort:</dt><dd> The action the application takes on a Connecti
<t>Abort: The action the application takes on a Connection to indi on
cate a <tt>Close</tt> and also indicate that the Transport Services System shoul to indicate that the Transport Services System
d not attempt to deliver any outstanding data, and immediately drop the connecti should not attempt to deliver any outstanding data and that it should
on. This is intended for immediate, usually abnormal, termination of a connectio immediately close and drop the connection. This is intended for immediate, us
n.</t> ually abnormal, termination of a connection.</dd>
</li> </dl>
</ul>
</section> </section>
<section anchor="connection-groups"> <section anchor="connection-groups">
<name>Connection Groups</name> <name>Connection Groups</name>
<t>A Connection Group is a set of Connections that shares Connection P <t>A Connection Group is a set of Connections that shares Connection P
roperties and cached state generated by protocols. roperties and Cached State generated by protocols.
A Connection Group represents state for managing Connections within a single app A Connection Group represents state for managing Connections within a single app
lication, and does not require end-to-end protocol signaling. For transport prot lication and does not require end-to-end protocol signaling. For transport proto
ocols that support multiplexing, only Connections within the same Connection Gro cols that support multiplexing, only Connections within the same Connection Grou
up are allowed to be multiplexed together.</t> p are allowed to be multiplexed together.</t>
<t>The API allows a Connection to be created from another Connection. This adds the new Connection to the Connection Group. A change to one of the Con nection Properties on any Connection in the Connection Group automatically chang es the Connection Property for all others. All Connections in a Connection Group share the same set of Connection Properties except for the Connection Priority. These Connection Properties are said to be entangled.</t> <t>The API allows a Connection to be created from another Connection. This adds the new Connection to the Connection Group. A change to one of the Con nection Properties on any Connection in the Connection Group automatically chang es the Connection Property for all others. All Connections in a Connection Group share the same set of Connection Properties except for the Connection Priority. These Connection Properties are said to be entangled.</t>
<t>Passive Connections can also be added to a Connection Group, e.g., when a Listener receives a new Connection that is just a new stream of an alread y active multi-streaming protocol <t>Passive Connections can also be added to a Connection Group, e.g., when a Listener receives a new Connection that is just a new stream of an alread y-active multistreaming protocol
instance.</t> instance.</t>
<t>While Connection Groups are managed by the Transport Services Imple mentation, an application can define different Connection Contexts for different Connection Groups to explicitly control caching boundaries, as discussed in <xr ef target="conn-context"/>.</t> <t>While Connection Groups are managed by the Transport Services Imple mentation, an application can define different Connection Contexts for different Connection Groups to explicitly control caching boundaries, as discussed in <xr ef target="conn-context"/>.</t>
</section> </section>
</section> </section>
<section anchor="transport-services-implementation"> <section anchor="transport-services-implementation">
<name>Transport Services Implementation</name> <name>Transport Services Implementation</name>
<t>This section defines the key architectural concepts for the Transport Services Implementation within the Transport Services System.</t> <t>This section defines the key architectural concepts for the Transport Services Implementation within the Transport Services System.</t>
<t>The Transport Services System consists of the Transport Services Impl ementation and the Transport Services API. <t>The Transport Services System consists of the Transport Services Impl ementation and the Transport Services API.
The Transport Services Implementation consists of all objects and protocol insta nces used internally to a system or library to implement the functionality neede d to provide a transport service across a network, as required by the abstract i nterface.</t> The Transport Services Implementation consists of all objects and protocol insta nces used internally to a system or library to implement the functionality neede d to provide a transport service across a network, as required by the abstract i nterface.</t>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t>Path: Represents an available set of properties that a Local Endp <dt>Path:</dt><dd>Represents an available set of Properties that a L
oint can use to communicate with a Remote Endpoint, such as routes, addresses, a ocal Endpoint can use to communicate with a Remote Endpoint, such as routes, add
nd physical and virtual network interfaces.</t> resses, and physical and virtual network interfaces.</dd>
</li>
<li> <dt>Protocol Instance:</dt><dd>A single instance of one protocol, in
<t>Protocol Instance: A single instance of one protocol, including a cluding any state necessary to establish connectivity or send and receive Messag
ny state necessary to establish connectivity or send and receive Messages.</t> es.</dd>
</li>
<li> <dt>Protocol Stack:</dt><dd>A set of protocol instances (including r
<t>Protocol Stack: A set of Protocol Instances (including relevant a elevant application, security, transport, or Internet protocols) that are used t
pplication, security, transport, or Internet protocols) that are used together t ogether to establish connectivity or send and receive Messages. A single stack c
o establish connectivity or send and receive Messages. A single stack can be sim an be simple (e.g., one application stream carried TCP running over IP) or compl
ple (a single transport protocol instance over IP), or it can be complex (multip ex (e.g,. multiple application streams carried over a multipath transport protoc
le application protocol streams going through a single security and transport pr ol using multiple subflows over IP).</dd>
otocol, over IP; or, a multi-path transport protocol over multiple transport sub
-flows).</t> <dt>Candidate Path:</dt><dd>One path that is available to an applica
</li> tion and conforms to the Selection Properties and System Policy, of which there
<li> can be several. Candidate Paths are identified during the gathering phase (<xref
<t>Candidate Path: One path that is available to an application and target="gathering"/>) and can be used during the racing phase (<xref target="ra
conforms to the Selection Properties and System Policy, of which there can be se cing"/>).</dd>
veral. Candidate Paths are identified during the gathering phase (<xref target="
gathering"/>) and can be used during the racing phase (<xref target="racing"/>). <dt>Candidate Protocol Stack:</dt><dd>One Protocol Stack that can be
</t> used by an application for a connection, for which there can be several candida
</li> tes. Candidate Protocol Stacks are identified during the gathering phase (<xref
<li> target="gathering"/>) and are started during the racing phase (<xref target="rac
<t>Candidate Protocol Stack: One Protocol Stack that can be used by ing"/>).</dd>
an application for a Connection, for which there can be several candidates. Cand
idate Protocol Stacks are identified during the gathering phase (<xref target="g <dt>System Policy:</dt><dd>The input from an operating system or oth
athering"/>) and are started during the racing phase (<xref target="racing"/>).< er global preferences that can constrain or influence how an implementation will
/t> gather Candidate Paths and Candidate Protocol Stacks (<xref target="gathering"/
</li> >) and race the candidates during establishment (<xref target="racing"/>). Speci
<li> fic aspects of the System Policy apply to either all Connections or only certain
<t>System Policy: The input from an operating system or other global Connections, depending on the runtime context and Properties of the Connection.
preferences that can constrain or influence how an implementation will gather c </dd>
andidate paths and Protocol Stacks (<xref target="gathering"/>) and race the can
didates during establishment (<xref target="racing"/>). Specific aspects of the <dt>Cached State:</dt><dd>The state and history that the implementat
System Policy either apply to all Connections or only certain ones, depending on ion keeps for each set of associated Endpoints that have been used previously. T
the runtime context and properties of the Connection.</t> his can include DNS results, TLS session state, previous success and quality of
</li> transport protocols over certain paths, as well as other information. This cach
<li> ing does not imply that the same decisions are necessarily made for subsequent c
<t>Cached State: The state and history that the implementation keeps onnections; rather, it means that Cached State is used by a Transport Services I
for each set of associated Endpoints that have been used previously. This can i mplementation to inform functions such as choosing the candidates to be raced, s
nclude DNS results, TLS session state, previous success and quality of transport electing appropriate transport parameters, etc. An application <bcp14>SHOULD NOT
protocols over certain paths, as well as other information. This caching does </bcp14> rely on specific caching behavior; instead, it ought to explicitly requ
not imply that the same decisions are necessarily made for subsequent connection est any required or preferred Properties via the Transport Services API.
s, rather, it means that cached state is used by a Transport Services Implementa
tion to inform functions such as choosing the candidates to be raced, selecting </dd>
appropriate transport parameters, etc. An application SHOULD NOT rely on specifi </dl>
c caching behaviour, instead it ought to explicitly request any required or desi
red properties via the Transport Services API.</t>
</li>
</ul>
<section anchor="gathering"> <section anchor="gathering">
<name>Candidate Gathering</name> <name>Candidate Gathering</name>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t>Candidate Path Selection: Candidate Path Selection represents t <dt>Candidate Path Selection:</dt><dd>Candidate Path Selection rep
he act of choosing one or more paths that are available to use based on the Sele resents the act of choosing one or more paths that are available to use based on
ction Properties and any available Local and Remote Endpoint Identifiers provide the Selection Properties and any available Local and Remote Endpoint Identifier
d by the application, as well as the policies and heuristics of a Transport Serv s provided by the application, as well as the policies and heuristics of a Trans
ices implementation.</t> port Services Implementation.</dd>
</li>
<li> <dt>Candidate Protocol Selection:</dt><dd>Candidate Protocol Selec
<t>Candidate Protocol Selection: Candidate Protocol Selection repr tion represents the act of choosing one or more sets of Protocol Stacks that are
esents the act of choosing one or more sets of Protocol Stacks that are availabl available to use based on the Transport Properties provided by the application,
e to use based on the Transport Properties provided by the application, and the and the heuristics or policies within the Transport Services Implementation.</d
heuristics or policies within the Transport Services Implementation.</t> d>
</li> </dl>
</ul>
</section> </section>
<section anchor="racing"> <section anchor="racing">
<name>Candidate Racing</name> <name>Candidate Racing</name>
<t>Connection establishment attempts for a set of candidates may be pe rformed simultaneously, synchronously, serially, or using some combination of al l of these. We refer to this process as racing, borrowing terminology from Happy Eyeballs <xref target="RFC8305"/>.</t> <t>Connection establishment attempts for a set of candidates may be pe rformed simultaneously, synchronously, serially, or using some combination of al l of these. We refer to this process as racing, borrowing terminology from Happy Eyeballs <xref target="RFC8305"/>.</t>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t>Protocol Option Racing: Protocol Option Racing is the act of at <dt>Protocol Option Racing:</dt><dd>Protocol Option Racing is the
tempting to establish, or scheduling attempts to establish, multiple Protocol St act of attempting to establish, or scheduling attempts to establish, multiple Pr
acks that differ based on the composition of protocols or the options used for p otocol Stacks that differ based on the composition of protocols or the options u
rotocols.</t> sed for protocols.</dd>
</li>
<li> <dt>Path Racing:</dt><dd>Path Racing is the act of attempting to e
<t>Path Racing: Path Racing is the act of attempting to establish, stablish, or scheduling attempts to establish, multiple Protocol Stacks that dif
or scheduling attempts to establish, multiple Protocol Stacks that differ based fer based on a selection from the available paths. Since different paths will ha
on a selection from the available Paths. Since different Paths will have distin ve distinct configurations (see <xref target="RFC7556"/>)
ct configurations (see <xref target="RFC7556"/>) for local addresses and DNS servers, attempts across different paths will perfor
for local addresses and DNS servers, attempts across different Paths will perfor m separate DNS resolution steps, which can lead to further racing of the resolve
m separate DNS resolution steps, which can lead to further racing of the resolve d Remote Endpoint Identifiers.</dd>
d Remote Endpoint Identifiers.</t>
</li> <dt>Remote Endpoint Racing:</dt><dd>Remote Endpoint Racing is the
<li> act of attempting to establish, or scheduling attempts to establish, multiple Pr
<t>Remote Endpoint Racing: Remote Endpoint Racing is the act of at otocol Stacks that differ based on the specific representation of the Remote End
tempting to establish, or scheduling attempts to establish, multiple Protocol St point Identifier, such as a particular IP address that was resolved from a DNS h
acks that differ based on the specific representation of the Remote Endpoint Ide ostname.</dd>
ntifier, such as a particular IP address that was resolved from a DNS hostname.< </dl>
/t>
</li>
</ul>
</section> </section>
<section anchor="conn-context"> <section anchor="conn-context">
<name>Separating Connection Contexts</name> <name>Separating Connection Contexts</name>
<t>A Transport Services Implementation can by default share stored pro perties across Connections within an application, such as cached protocol state, cached path state, and heuristics. This provides efficiency and convenience for the application, since the Transport Services System can automatically optimize behavior.</t> <t>A Transport Services Implementation can by default share stored Pro perties across Connections within an application, such as cached protocol state, cached path state, and heuristics. This provides efficiency and convenience for the application, since the Transport Services System can automatically optimize behavior.</t>
<t>The Transport Services API can allow applications to explicitly def ine Connection Contexts that force separation of Cached State and Protocol Stack s. <t>The Transport Services API can allow applications to explicitly def ine Connection Contexts that force separation of Cached State and Protocol Stack s.
For example, a web browser application could use Connection Contexts with separa te caches when implementing different tabs. Possible reasons to isolate Connecti ons using separate Connection Contexts include:</t> For example, a web browser application could use Connection Contexts with separa te caches when implementing different tabs. Possible reasons to isolate Connecti ons using separate Connection Contexts include privacy concerns regarding:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Privacy concerns about re-using cached protocol state that can lead to linkability. Sensitive state could include TLS session state <xref targe t="RFC8446"/> and HTTP cookies <xref target="RFC6265"/>. These concerns could be addressed using Connection Contexts with separate caches, such as for different browser tabs.</t> <t>reusing cached protocol state, as this can lead to linkability. Sensitive state could include TLS session state <xref target="RFC8446"/> and HT TP cookies <xref target="RFC6265"/>. These concerns could be addressed using Con nection Contexts with separate caches, such as for different browser tabs.</t>
</li> </li>
<li> <li>
<t>Privacy concerns about allowing Connections to multiplex togeth er, which can tell a Remote Endpoint that all of the Connections are coming from the same application. Using Connection Contexts avoids the Connections being mu ltiplexed in a HTTP/2 or QUIC stream.</t> <t>allowing Connections to multiplex together, which can tell a Re mote Endpoint that all of the Connections are coming from the same application. Using Connection Contexts avoids the Connections being multiplexed in an HTTP/2 or QUIC stream.</t>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no actions for IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="security-and-privacy-considerations"> <section anchor="security-and-privacy-considerations">
<name>Security and Privacy Considerations</name> <name>Security and Privacy Considerations</name>
<t>The Transport Services System does not recommend use of specific securi ty <t>The Transport Services System does not recommend the use of specific se curity
protocols or algorithms. Its goal is to offer ease of use for existing protocols protocols or algorithms. Its goal is to offer ease of use for existing protocols
by providing a generic security-related interface. Each provided interface by providing a generic security-related interface. Each provided interface
translates to an existing protocol-specific interface provided by supported translates to an existing protocol-specific interface provided by supported
security protocols. For example, trust verification callbacks are common parts security protocols. For example, trust verification callbacks are common parts
of TLS APIs; a Transport Services API exposes similar functionality of TLS APIs; a Transport Services API exposes similar functionality
<xref target="RFC8922"/>.</t> <xref target="RFC8922"/>.</t>
<t>As described above in <xref target="equivalence"/>, if a Transport Serv ices Implementation races <t>As described above in <xref target="equivalence"/>, if a Transport Serv ices Implementation races
between two different Protocol Stacks, both need to use the same security protoc ols between two different Protocol Stacks, both need to use the same security protoc ols
and options. However, a Transport Services Implementation can race different sec urity and options. However, a Transport Services Implementation can race different sec urity
protocols, e.g., if the application explicitly specifies that it considers them protocols, e.g., if the application explicitly specifies that it considers them
equivalent.</t> equivalent.</t>
<t>The application controls whether <t>The application controls whether
information from previous racing attempts, or other information information from previous racing attempts or other information
about past communications that was cached by about past communications that was cached by
the Transport Services System is used during establishment. the Transport Services System is used during establishment.
This allows applications to make This allows applications to make
tradeoffs between efficiency (through racing) and privacy (via information that trade-offs between efficiency (through racing) and privacy (via information that
might leak from the cache toward an on-path observer). Some applications have might leak from the cache toward an on-path observer). Some applications have
features (e.g. "incognito mode") that align with this functionality.</t> features (e.g., "incognito mode") that align with this functionality.</t>
<t>Applications need to ensure that they use security APIs appropriately. In cases <t>Applications need to ensure that they use security APIs appropriately. In cases
where applications use an interface to provide sensitive keying material, e.g., where applications use an interface to provide sensitive keying material, e.g.,
access to private keys or copies of pre-shared keys (PSKs), key use needs to be access to private keys or copies of pre-shared keys (PSKs), key use needs to be
validated and scoped to the intended protocols and roles. For example, if an validated and scoped to the intended protocols and roles. For example, if an
application provides a certificate to only be used as client authentication for application provides a certificate to only be used as client authentication for
outbound TLS and QUIC connections, the Transport Services System MUST NOT use th is outbound TLS and QUIC connections, the Transport Services System <bcp14>MUST NOT </bcp14> use this
automatically in other contexts (such as server authentication for inbound automatically in other contexts (such as server authentication for inbound
connections, or in other another security protocol handshake that is not equival connections or in other security protocol handshakes that are not equivalent to
ent to TLS).</t> TLS).
<t>A Transport Services System MUST NOT automatically fall back from
secure protocols to insecure protocols, or to weaker versions of secure </t>
protocols (see <xref target="equivalence"/>). For example, if an application req <t>A Transport Services System <bcp14>MUST NOT</bcp14> automatically fall
uests a specific version of TLS, back from
secure protocols to insecure protocols or fall back to weaker versions of secure
protocols (see <xref target="equivalence"/>). For example, if an application req
uests a specific version of TLS
but the desired version of TLS is not available, its connection will fail. but the desired version of TLS is not available, its connection will fail.
As described in <xref target="equivalence"/>, the Transport Services API can all ow applications As described in <xref target="equivalence"/>, the Transport Services API can all ow applications
to specify minimum versions that are allowed to be used by the Transport Service s System.</t> to specify minimum versions that are allowed to be used by the Transport Service s System.</t>
</section> </section>
<section anchor="acknowledgements">
<name>Acknowledgements</name>
<t>This work has received funding from the European Union's Horizon 2020 r
esearch
and innovation programme under grant agreements No. 644334 (NEAT), No. 688421
(MAMI) and No 815178 (5GENESIS).</t>
<t>This work has been supported by Leibniz Prize project funds of DFG - Ge
rman
Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ FE 570/4-1).</t>
<t>This work has been supported by the UK Engineering and Physical Science
s
Research Council under grant EP/R04144X/1.</t>
<t>Thanks to Reese Enghardt, Max Franke, Mirja Kuehlewind, Jonathan Lennox
, and
Michael Welzl for the discussions and feedback that helped shape the architectur
e
of the system described here.
Particular thanks is also due to Philipp S. Tiesel and Christopher A. Wood,
who were both co-authors of this specification as it progressed
through the TAPS working group.
Thanks as well to Stuart Cheshire, Josh Graessley, David Schinazi,
and Eric Kinnear for their implementation and design efforts, including Happy
Eyeballs, that heavily influenced this work.</t>
</section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<front> 19.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
le> 74.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="POSIX">
<reference anchor="POSIX" target="https://ieeexplore.ieee.org/document/1
0555529">
<front> <front>
<title>IEEE Std. 1003.1-2008 Standard for Information Technology -- Portable Operating System Interface (POSIX). Open group Technical Standard: Bas e Specifications, Issue 7</title> <title>IEEE/Open Group Standard for Information Technology - Portabl e Operating System Interface (POSIX(TM)) Base Specifications, Issue 8</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2008"/> <date year="2024"/>
</front>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="8446"/> <seriesInfo name="IEEE Std" value="1003.1-2024"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2024.10555529"/>
</reference> </reference>
<reference anchor="I-D.ietf-taps-interface">
<front>
<title>An Abstract Application Layer Interface to Transport Services
</title>
<author fullname="Brian Trammell" initials="B." surname="Trammell">
<organization>Google Switzerland GmbH</organization>
</author>
<author fullname="Michael Welzl" initials="M." surname="Welzl">
<organization>University of Oslo</organization>
</author>
<author fullname="Reese Enghardt" initials="R." surname="Enghardt">
<organization>Netflix</organization>
</author>
<author fullname="Gorry Fairhurst" initials="G." surname="Fairhurst"
>
<organization>University of Aberdeen</organization>
</author>
<author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind"
>
<organization>Ericsson</organization>
</author>
<author fullname="Colin Perkins" initials="C." surname="Perkins">
<organization>University of Glasgow</organization>
</author>
<author fullname="Philipp S. Tiesel" initials="P. S." surname="Tiese
l">
<organization>SAP SE</organization>
</author>
<author fullname="Tommy Pauly" initials="T." surname="Pauly">
<organization>Apple Inc.</organization>
</author>
<date day="6" month="July" year="2023"/>
<abstract>
<t> This document describes an abstract application programming
interface, API, to the transport layer that enables the selection of
transport protocols and network paths dynamically at runtime. This
API enables faster deployment of new protocols and protocol features
without requiring changes to the applications. The specified API
follows the Transport Services architecture by providing
asynchronous, atomic transmission of messages. It is intended to
replace the BSD sockets API as the common interface to the transport
layer, in an environment where endpoints could select from multiple
interfaces and potential transport protocols.
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
</abstract> 46.xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-taps-interface-22" <!-- draft-ietf-taps-interface (RFC 9622) -->
/> <reference anchor="RFC9622" target="https://www.rfc-editor.org/info/rfc9622">
</reference> <front>
<reference anchor="I-D.ietf-taps-impl"> <title>An Abstract Application Programming Interface (API) for Transport Service
s</title>
<author initials="B." surname="Trammell" fullname="Brian Trammell" role="editor"
>
<organization>Google Switzerland GmbH</organization>
</author>
<author initials="M." surname="Welzl" fullname="Michael Welzl" role="editor">
<organization>University of Oslo</organization>
</author>
<author initials="R." surname="Enghardt" fullname="Reese Enghardt">
<organization>Netflix</organization>
</author>
<author initials="G." surname="Fairhurst" fullname="Gorry Fairhurst">
<organization>University of Aberdeen</organization>
</author>
<author initials="M." surname="Kühlewind" fullname="Mirja Kühlewind">
<organization>Ericsson</organization>
</author>
<author initials="C. S." surname="Perkins" fullname="Colin Perkins">
<organization>University of Glasgow</organization>
</author>
<author initials="P." surname="Tiesel" fullname="Philipp S. Tiesel">
<organization>SAP SE</organization>
</author>
<author initials="T." surname="Pauly" fullname="Tommy Pauly">
<organization>Apple Inc.</organization>
</author>
<date month="December" year="2024"/>
</front>
<seriesInfo name="RFC" value="9622"/>
<seriesInfo name="DOI" value="10.17487/RFC9622"/>
</reference>
<!-- draft-ietf-taps-impl (RFC 9623) -->
<reference anchor="RFC9623" target="https://www.rfc-editor.org/info/rfc9
623">
<front> <front>
<title>Implementing Interfaces to Transport Services</title> <title>Implementing Interfaces to Transport Services</title>
<author fullname="Anna Brunstrom" initials="A." surname="Brunstrom"> <author fullname="Anna Brunstrom" initials="A." surname="Brunstrom" role="editor">
<organization>Karlstad University</organization> <organization>Karlstad University</organization>
</author> </author>
<author fullname="Tommy Pauly" initials="T." surname="Pauly"> <author fullname="Tommy Pauly" initials="T." surname="Pauly" role="e ditor">
<organization>Apple Inc.</organization> <organization>Apple Inc.</organization>
</author> </author>
<author fullname="Reese Enghardt" initials="R." surname="Enghardt"> <author fullname="Reese Enghardt" initials="R." surname="Enghardt">
<organization>Netflix</organization> <organization>Netflix</organization>
</author> </author>
<author fullname="Philipp S. Tiesel" initials="P. S." surname="Tiese l"> <author fullname="Philipp S. Tiesel" initials="P." surname="Tiesel">
<organization>SAP SE</organization> <organization>SAP SE</organization>
</author> </author>
<author fullname="Michael Welzl" initials="M." surname="Welzl"> <author fullname="Michael Welzl" initials="M." surname="Welzl">
<organization>University of Oslo</organization> <organization>University of Oslo</organization>
</author> </author>
<date day="5" month="June" year="2023"/> <date month="December" year="2024"/>
<abstract>
<t> The Transport Services system enables applications to use tr
ansport
protocols flexibly for network communication and defines a protocol-
independent Transport Services Application Programming Interface
(API) that is based on an asynchronous, event-driven interaction
pattern. This document serves as a guide to implementing such a
system.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-taps-impl-16"/>
</reference>
<reference anchor="RFC8095">
<front>
<title>Services Provided by IETF Transport Protocols and Congestion
Control Mechanisms</title>
<author fullname="G. Fairhurst" initials="G." role="editor" surname=
"Fairhurst"/>
<author fullname="B. Trammell" initials="B." role="editor" surname="
Trammell"/>
<author fullname="M. Kuehlewind" initials="M." role="editor" surname
="Kuehlewind"/>
<date month="March" year="2017"/>
<abstract>
<t>This document describes, surveys, and classifies the protocol m
echanisms provided by existing IETF protocols, as background for determining a c
ommon set of transport services. It examines the Transmission Control Protocol (
TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User D
atagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP
), the Internet Control Message Protocol (ICMP), the Real-Time Transport Protoco
l (RTP), File Delivery over Unidirectional Transport / Asynchronous Layered Codi
ng (FLUTE/ALC) for Reliable Multicast, NACK- Oriented Reliable Multicast (NORM),
Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transpor
t Protocol (HTTP), when HTTP is used as a pseudotransport. This survey provides
background for the definition of transport services within the TAPS working grou
p.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8095"/>
<seriesInfo name="DOI" value="10.17487/RFC8095"/>
</reference>
<reference anchor="RFC8923">
<front>
<title>A Minimal Set of Transport Services for End Systems</title>
<author fullname="M. Welzl" initials="M." surname="Welzl"/>
<author fullname="S. Gjessing" initials="S." surname="Gjessing"/>
<date month="October" year="2020"/>
<abstract>
<t>This document recommends a minimal set of Transport Services of
fered by end systems and gives guidance on choosing among the available mechanis
ms and protocols. It is based on the set of transport features in RFC 8303.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8923"/>
<seriesInfo name="DOI" value="10.17487/RFC8923"/>
</reference>
<reference anchor="RFC8922">
<front>
<title>A Survey of the Interaction between Security Protocols and Tr
ansport Services</title>
<author fullname="T. Enghardt" initials="T." surname="Enghardt"/>
<author fullname="T. Pauly" initials="T." surname="Pauly"/>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<author fullname="K. Rose" initials="K." surname="Rose"/>
<author fullname="C. Wood" initials="C." surname="Wood"/>
<date month="October" year="2020"/>
<abstract>
<t>This document provides a survey of commonly used or notable net
work security protocols, with a focus on how they interact and integrate with ap
plications and transport protocols. Its goal is to supplement efforts to define
and catalog Transport Services by describing the interfaces required to add secu
rity protocols. This survey is not limited to protocols developed within the sco
pe or context of the IETF, and those included represent a superset of features a
Transport Services system may need to support.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8922"/>
<seriesInfo name="DOI" value="10.17487/RFC8922"/>
</reference>
<reference anchor="RFC8303">
<front>
<title>On the Usage of Transport Features Provided by IETF Transport
Protocols</title>
<author fullname="M. Welzl" initials="M." surname="Welzl"/>
<author fullname="M. Tuexen" initials="M." surname="Tuexen"/>
<author fullname="N. Khademi" initials="N." surname="Khademi"/>
<date month="February" year="2018"/>
<abstract>
<t>This document describes how the transport protocols Transmissio
n Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Pro
tocol (SCTP), User Datagram Protocol (UDP), and Lightweight User Datagram Protoc
ol (UDP-Lite) expose services to applications and how an application can configu
re and use the features that make up these services. It also discusses the servi
ce provided by the Low Extra Delay Background Transport (LEDBAT) congestion cont
rol mechanism. The description results in a set of transport abstractions that c
an be exported in a transport services (TAPS) API.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8303"/>
<seriesInfo name="DOI" value="10.17487/RFC8303"/>
</reference>
<reference anchor="RFC9000">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I
yengar"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communica
tion, low-latency connection establishment, and network path migration. QUIC inc
ludes security measures that ensure confidentiality, integrity, and availability
in a range of deployment circumstances. Accompanying documents describe the int
egration of TLS for key negotiation, loss detection, and an exemplary congestion
control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="RFC9112">
<front>
<title>HTTP/1.1</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname
="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document specifies the HTTP/1.1 message syntax, message parsing, connectio
n management, and related security concerns.</t>
<t>This document obsoletes portions of RFC 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="99"/>
<seriesInfo name="RFC" value="9112"/>
<seriesInfo name="DOI" value="10.17487/RFC9112"/>
</reference>
<reference anchor="RFC9113">
<front>
<title>HTTP/2</title>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<author fullname="C. Benfield" initials="C." role="editor" surname="
Benfield"/>
<date month="June" year="2022"/>
<abstract>
<t>This specification describes an optimized expression of the sem
antics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2
(HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced
latency by introducing field compression and allowing multiple concurrent excha
nges on the same connection.</t>
<t>This document obsoletes RFCs 7540 and 8740.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9113"/>
<seriesInfo name="DOI" value="10.17487/RFC9113"/>
</reference>
<reference anchor="RFC8170">
<front>
<title>Planning for Protocol Adoption and Subsequent Transitions</ti
tle>
<author fullname="D. Thaler" initials="D." role="editor" surname="Th
aler"/>
<date month="May" year="2017"/>
<abstract>
<t>Over the many years since the introduction of the Internet Prot
ocol, we have seen a number of transitions throughout the protocol stack, such a
s deploying a new protocol, or updating or replacing an existing protocol. Many
protocols and technologies were not designed to enable smooth transition to alte
rnatives or to easily deploy extensions; thus, some transitions, such as the int
roduction of IPv6, have been difficult. This document attempts to summarize some
basic principles to enable future transitions, and it also summarizes what make
s for a good transition plan.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8170"/>
<seriesInfo name="DOI" value="10.17487/RFC8170"/>
</reference>
<reference anchor="RFC5482">
<front>
<title>TCP User Timeout Option</title>
<author fullname="L. Eggert" initials="L." surname="Eggert"/>
<author fullname="F. Gont" initials="F." surname="Gont"/>
<date month="March" year="2009"/>
<abstract>
<t>The TCP user timeout controls how long transmitted data may rem
ain unacknowledged before a connection is forcefully closed. It is a local, per-
connection parameter. This document specifies a new TCP option -- the TCP User T
imeout Option -- that allows one end of a TCP connection to advertise its curren
t user timeout value. This information provides advice to the other end of the T
CP connection to adapt its user timeout accordingly. Increasing the user timeout
s on both ends of a TCP connection allows it to survive extended periods without
end-to-end connectivity. Decreasing the user timeouts allows busy servers to ex
plicitly notify their clients that they will maintain the connection state only
for a short time without connectivity. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5482"/>
<seriesInfo name="DOI" value="10.17487/RFC5482"/>
</reference>
<reference anchor="RFC9293">
<front>
<title>Transmission Control Protocol (TCP)</title>
<author fullname="W. Eddy" initials="W." role="editor" surname="Eddy
"/>
<date month="August" year="2022"/>
<abstract>
<t>This document specifies the Transmission Control Protocol (TCP)
. TCP is an important transport-layer protocol in the Internet protocol stack, a
nd it has continuously evolved over decades of use and growth of the Internet. O
ver this time, a number of changes have been made to TCP as it was specified in
RFC 793, though these have only been documented in a piecemeal fashion. This doc
ument collects and brings those changes together with the protocol specification
from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093,
6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 11
22, and it should be considered as a replacement for the portions of those docum
ents dealing with TCP requirements. It also updates RFC 5961 by adding a small c
larification in reset handling while in the SYN-RECEIVED state. The TCP header c
ontrol bits from RFC 793 have also been updated based on RFC 3168.</t>
</abstract>
</front>
<seriesInfo name="STD" value="7"/>
<seriesInfo name="RFC" value="9293"/>
<seriesInfo name="DOI" value="10.17487/RFC9293"/>
</reference>
<reference anchor="RFC5389">
<front>
<title>Session Traversal Utilities for NAT (STUN)</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
<author fullname="R. Mahy" initials="R." surname="Mahy"/>
<author fullname="P. Matthews" initials="P." surname="Matthews"/>
<author fullname="D. Wing" initials="D." surname="Wing"/>
<date month="October" year="2008"/>
<abstract>
<t>Session Traversal Utilities for NAT (STUN) is a protocol that s
erves as a tool for other protocols in dealing with Network Address Translator (
NAT) traversal. It can be used by an endpoint to determine the IP address and po
rt allocated to it by a NAT. It can also be used to check connectivity between t
wo endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works
with many existing NATs, and does not require any special behavior from them.</t
>
<t>STUN is not a NAT traversal solution by itself. Rather, it is a
tool to be used in the context of a NAT traversal solution. This is an importan
t change from the previous version of this specification (RFC 3489), which prese
nted STUN as a complete solution.</t>
<t>This document obsoletes RFC 3489. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5389"/>
<seriesInfo name="DOI" value="10.17487/RFC5389"/>
</reference>
<reference anchor="RFC8445">
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for
Network Address Translator (NAT) Traversal</title>
<author fullname="A. Keranen" initials="A." surname="Keranen"/>
<author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
<date month="July" year="2018"/>
<abstract>
<t>This document describes a protocol for Network Address Translat
or (NAT) traversal for UDP-based communication. This protocol is called Interact
ive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Uti
lities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TUR
N).</t>
<t>This document obsoletes RFC 5245.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8445"/>
<seriesInfo name="DOI" value="10.17487/RFC8445"/>
</reference>
<reference anchor="RFC8305">
<front>
<title>Happy Eyeballs Version 2: Better Connectivity Using Concurren
cy</title>
<author fullname="D. Schinazi" initials="D." surname="Schinazi"/>
<author fullname="T. Pauly" initials="T." surname="Pauly"/>
<date month="December" year="2017"/>
<abstract>
<t>Many communication protocols operating over the modern Internet
use hostnames. These often resolve to multiple IP addresses, each of which may
have different performance and connectivity characteristics. Since specific addr
esses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal
on a network, clients that attempt multiple connections in parallel have a chanc
e of establishing a connection more quickly. This document specifies requirement
s for algorithms that reduce this user-visible delay and provides an example alg
orithm, referred to as "Happy Eyeballs". This document obsoletes the original al
gorithm description in RFC 6555.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8305"/>
<seriesInfo name="DOI" value="10.17487/RFC8305"/>
</reference>
<reference anchor="RFC7556">
<front>
<title>Multiple Provisioning Domain Architecture</title>
<author fullname="D. Anipko" initials="D." role="editor" surname="An
ipko"/>
<date month="June" year="2015"/>
<abstract>
<t>This document is a product of the work of the Multiple Interfac
es Architecture Design team. It outlines a solution framework for some of the is
sues experienced by nodes that can be attached to multiple networks simultaneous
ly. The framework defines the concept of a Provisioning Domain (PvD), which is a
consistent set of network configuration information. PvD-aware nodes learn PvD-
specific information from the networks they are attached to and/or other sources
. PvDs are used to enable separation and configuration consistency in the presen
ce of multiple concurrent connections.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7556"/>
<seriesInfo name="DOI" value="10.17487/RFC7556"/>
</reference>
<reference anchor="RFC6265">
<front>
<title>HTTP State Management Mechanism</title>
<author fullname="A. Barth" initials="A." surname="Barth"/>
<date month="April" year="2011"/>
<abstract>
<t>This document defines the HTTP Cookie and Set-Cookie header fie
lds. These header fields can be used by HTTP servers to store state (called cook
ies) at HTTP user agents, letting the servers maintain a stateful session over t
he mostly stateless HTTP protocol. Although cookies have many historical infelic
ities that degrade their security and privacy, the Cookie and Set-Cookie header
fields are widely used on the Internet. This document obsoletes RFC 2965. [STAND
ARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="6265"/> <seriesInfo name="RFC" value="9623"/>
<seriesInfo name="DOI" value="10.17487/RFC6265"/> <seriesInfo name="DOI" value="10.17487/RFC9623"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
95.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89
23.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89
22.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
03.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
00.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
12.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
13.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
70.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.54
82.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
93.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
89.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
45.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
05.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.75
56.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62
65.xml"/>
</references> </references>
</references> </references>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>This work has received funding from the European Union's Horizon 2020 r
esearch
and innovation programme under grant agreements No. 644334 (NEAT), No. 688421
(MAMI), and No. 815178 (5GENESIS).</t>
<t>This work has been supported by:</t>
<ul>
<li>Leibniz Prize project funds from the DFG - German
Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ FE 570/4-1).</li>
<li>the UK Engineering and Physical Sciences
Research Council under grant EP/R04144X/1.</li>
</ul>
<t>Thanks to <contact fullname="Reese Enghardt"/>, <contact fullname="Max
Franke"/>, <contact fullname="Mirja Kühlewind"/>, <contact fullname="Jonathan Le
nnox"/>, and
<contact fullname="Michael Welzl"/> for the discussions and feedback that helped
shape the architecture
of the system described here.
Particular thanks are also due to <contact fullname="Philipp S. Tiesel"/> and <c
ontact fullname="Christopher A. Wood"/>,
who were both coauthors of this specification as it progressed
through the Transport Services (TAPS) Working Group.
Thanks as well to <contact fullname="Stuart Cheshire"/>, <contact fullname="Josh
Graessley"/>, <contact fullname="David Schinazi"/>,
and <contact fullname="Eric Kinnear"/> for their implementation and design effor
ts, including Happy
Eyeballs, that heavily influenced this work.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA9V965bbVpbefz4FIv2YqhZJS7LcbZeTSZdLJbnGklytkuKZ
yUpikARJdIEABwCrRMvKyjvkDfMk2ddz9jkAWCX39OpprdVtiSRwbvvs+/72
ZDIZtXlbZCfJaT1f5202b3d1lqTlInmb/dsur7NNVrZNsqzq5F2dls22qtvk
Kqtv8nnWjNLZrM5uTpJ3p5dXwRtGi2pepht476JOl+0kz9rlpE23zSSFX02e
fDNapG12MprD/6+qen+SNO1iNMq39UnS1rumffr48TePn47SOktP/Mij26q+
XtXVbitj/gT/zstV8hI/G11ne/jB4iS5KNusLrN28hxHH42aFlb0v9KiKmFG
e5j4Nj9J/ntbzcdJA6+ts2UDf9tv8C//YzRKd+26qk9GSTKB/yVJXjYw3jS5
THfFnj7htb2rNpu9+bSucCezRd5WNX1Q1SvY2e22yGBK8yl91sBwWXuS/Fhm
8tVlWl8nP6X8jnnewm6c7bZZ3eZlNU7O0iKH7S/zNPnmq8dPnvGvql3Z4ra9
L2HLF8lVCxvZJNUyOd1kdT5P6VfZJs0L2NAtzvCPKQ42nVebcF3fTXF/N5us
KMzSvqvztAy/6F/dy6pawRqubvP2l6wukHJebmbf2/Hx8P/Yyqum83WwDS/h
sNObyctdUUwui7T9JXli9uHrx4+fJf+6gxWtw3Wb8cLlnE5h7rsSXk8L1fWc
lmUafUHT/yGtC5jAAjfyJqsbGDWYnvs4a5tVCmSUPDXT+/1XT5Kvv3YviaeY
LbLSbkQKk5jOdBJ/vE530yYLp/9ymrxI83q9q5vWTP9ltajhmMOvaAF+3nT6
s6xeZDKqruF5tk3rFi8y/uS8XOVlBkRSroJfvajTJquTN9UMjvO7XV4s9Be8
Vn31ODn97umz5Mv359Fy51Urx+EWDFe73v8xq1fTdLYop+l8urum7+FET5J1
225Pvvji9vZ2Gv7ki3BPzuDmZXjPG7MjZ1WRl8HnPdvxskibVXUbrPNqvq6q
Ar89qzbbXYvs42qeZ+U8M6uVJ5Pk5ZOnydd/+lPvrfsBnl0INcmK5832j/A/
ntYUpgRMrYTru0lbmNgJ/fTyx6uLf+a/Jomw3wcX5+fncI0X0+TJ48dfTp9M
gAN+jfe6XKT1ghjwhb6ogpuZzddlVVSrfTKZJJfAxFI8tx9h5JSXtG/abMOc
cJnOs+SIhj2eJvijMiEuyq8BdlG4keDqAx0kV9tsni/hGxwNmONF0+yy5A8P
ZNa7Gtb6n80BVvBOeiWu+YsULnVe/qP8mFh9gusZjSYw23QGZ5HOgS+/W+dN
AqJiR8S5yJp5nc+Aj8E1S608wtVnH7ZVgytrnRza1hXwcDjMZZbi75qkrRJk
czpvehDkAIoNOL3NZlfKV8D0cOyGd4nejY//e70665GWxO3lN8llXa2QI+KC
zBmdXl4cJzCvGZzBIoHf4U40+3K+rquy2sFBZDewVZNFDdRUwvWAJ2En8Y3b
tEWhJwuDFyU7XNIma5p0lfF862wLS4EX4LBwLCmveAn3PlremHQAfyJruAtp
36IuNiBV8Ph4XXOYMIybbHZFm5Pcu0zSBTCvBiYz9h/r/spA/vO0Xctn8JOb
fGFeZeZHtzndNLJaR0LyDJwWHEEaqzS1UWmmyQVS3BJ4YUPnBy+F/YMD4VuF
v59XwBS2LZ39LMN1LWDL+amcqQDYSM+20PbjG+6xZVO+FJt8sSiy0eghkkNd
LXZ0qqPR67TcByvfGsrJlXIaIp3mGGeq++aJ2fwMvheihTNNbzJYV4Yr2hbV
PluME+Afa1DTaP82VdMmt/CqYp9cl9VtSUvKNzkqGwt4km4j/PC7q+fJVTW/
ztrk40diM58++UGTI/kOiXs6wssBLByfhc2rZn+GA2rozctdOeddTed11dAk
GtrLBu9EWbV4Ik0OVxaOGp+4SescFgXTz8oFvbGkCbnby3PEg5uOXhATSXHz
QdmTB5gs5ll+g/8SqsKJ0e3IG6WBXVrALuC7GxA/dJlmVbvG+7krQXbU+y3u
CZ32Jm8aPKmzCk+ywLvOszl6d3Z5LIPQyJVj13zVoxfR4b1K93A9r7I5yEyQ
akfvXl0dwzb/17cvzr5+9uz3sNPywgoEXwIjjJPZrg15FdxK3D28mG4JDR/K
zz//jHtxdAx/oTnBf2FDbvgDkAxFQ7tabXFXaM0g2ha0R7A3ZcZHNh1dAWEU
oAjtx8E9wp3CMfOQT8DTXWbb6IE69odPwiht9oF0F3u2RB6bJituMtARcEhg
57s5HEmTPFgW1e2DcfKAtwb/JnzwAfOWB37qD4hntel1hgNu8Lot8iWwRCSy
TZaWcDzNlEUVTQ8OAZ8oMtAa4TrBm5Y7Ou/bNVwl0A/oWlRAFwvQRFCs8qbz
/gDfyJjcdRS8ljO4k3gRI7ZIXDc6SD1FkFrw/BzVimI/HdG9WlVpofvUw3hE
Jwj4Yt5YnpEmyyL7kIMqMeKbsWtIrxA5CUo37K+yS3/D6ZC7xzkdnZYB7yKJ
dHhyLUi63YouluoJeJHksJKjW+LDsBFbYENF/gu/GJawyFHnWO3yZi2MYwlK
No1GJ1HQuRiShY0CcTpdTcd4a47liFWCjHQjzCNJ1qCaBSOQsIG7Ud0yEwlW
CZNBSQM/TkjmktCBbWsyImIYgYy7DPZndNqEB5wuqm0Lk4aZuO0d4yL2sPkF
MrQSpE/La0uJO+t7/QF4nWWdtkQz2U0F94RZRJtvsjEdb1Y2SAL0KyJRPgLe
AmXu/pTxRTA7oONf4OMWqRZESI6s0N5XuxVW4tKQXmMC/iuaBlJVBSyLf0yn
tE7LFUur6I0q8fl08gJZYlYijcJnKUy/FmGm5k6Z3fr9ELVCqZNPPLgOuMa0
aCpgJVvay+B0ZmhVLMl2SoAy8T+bDCebN8B9jlAD22yJnw/oP+Z+G/WRlB7U
LMBOA6LKimPYlDXYvAmw26y+zYGYwWRbiB7iWCmrI1mKTM/qRmjvgYgGgXXU
ZBkIC57rp0+g/b/laQPfJLlblRnOZFPx2hf5ghwJ9E667XgmN2khyhXLMbgF
82uhrrQWxQjmBsQIquVyP1JCAW4EvGKWlweYPtp4wCSBvpR7kwx7//yS9igt
aQ/8g3AbqlVGn9EEkf/mq13thsDFbzKgBDrvkVd+gB1ZVuKUYbI3WBGhNcG4
OB132VEvQrqY+ZWiyDS6Q+bU7GgMR07w7BxEER4ZX11Zlv/tGKlrXlQob5j7
tyhP0OSDCeKqWtY2zevJ7QWkAsaL+Rjk4BqPJWA0oZ58m6LWBJIDfrGwlMd7
SszAWoAHhAqquqCOXEyeT72Xz206qCesNAbSH7g0aJWkencfhZ9++jRNTgvk
CiAJlpXy2YEZBBd4UWWsKjq+C1yTVMjuPFSxZ7oFXWfshRsoMES/wlwdC3FU
w/uWWpUUGNCaFAHk1MyVQv7Bw2Vpk8PdxEUoOeA17NGQDkvKSqkIjvfhQ7Db
5+QbBZonZSDYljvflkdaF0iGm4ycKI3+UkTjAgn14vzdi14NTuwmuAp8AUQH
NmxSdNfH33z16ZMjdBbfQIGLeOfxS7f7xH15Bn2Dy6u/efolUtA70gKU5htl
T3m20EMOBQMb0M76QMLpG8Tfm3a9Q6lTIyHgNHFT4CyucmQf/tFGdfecOA18
WyMJlCsgghr48E2KygTeN1rwbsDL0ejRqHd7zHqCu9TEaIgcUfFUrTudR9qB
m07nxbIdE9x5donQTvcQjdvop7DRoxH6suWoroFogKPnqzXbzbDToompdNCb
PHTDLJnddcjEyEgOuceznBiru/5GMFp3CZ44siGSPEd1BnRVixQr+Y1+X5vk
hZimqF7XyY+sBOFCXsiwxySssqLJVFQAuS+QnNNdW6HTbk4W5GxPJPCZVz2Y
H0znlN9JDMbNAFgm0LQobZ7UzdRxzT1zxyDIJiNJLvfC3ABSU9CsG7oPpKrA
PIgT4ekRdwx10HGSL1WgoDS9rXYFchrcEBKqy12hxkWzm3lFWYdAi5YfQtYO
0o0V+6Vbmzh8Wah6FS8JjX5cpickPCgUQ6gUezcZK5Fo0YSsm0kiEC3uITyV
Gl1yygmqGq4g/oPVONbfgXOh4tCqChtMHvU7JyA+4MB5y5te3cpdCDVhWA7x
mTqjwVgXlfnwVs3Y8mnymgglF+t2Dmy+YZHx4w0SWnY77Im9Q2jgausMl8Wa
x8loNIELuqlgX+F2hv7DAwoEPSAWcaOGW6qMiy0FZBXks5iwoEKhPvWO6gI9
D3nLIqIJvKaDTtMxm4cNca/AUxo4R72UsmYHmvgoX5yzYEgcsnrftXI26Z9h
pGFbZ8qbaW0o2FMkjjQvG70Ai5QYSRHYWky/wyenwnELE5mjndLQ9cetKRfM
ZjboETH2Yc/i8AKhgM/LXaakW66Ro7JyLFZnd+UgHko6NNg1Xf8sdHOqlK0b
2QZ1xsIWOL19gKIinzR7stnTKw4lcesGBoxcsXvps0rYC73wv0HBfSdGPjl7
ZWqXYE8Yi4C5B/GApqNJquFjVX/0NXqdH274VazF27A+64kosTFs3iQPXr+/
eofOMvxv8uZH+vvb8z+9v3h7/hz/fvX96atX7i/8ixH848f3r+R7/Jt/8uzH
16/P3zznh+HTJPro9em/sENu9ODHy3cXP745ffWAdzTQa2qlLjoGOH3Um8mC
Mafw3dll8uTZ6OPH/wTawdMnT76Bo+J/fP3kD89QVVhj8JLcrih46J8j4syw
sxlrcSjjxLWELji0pNDvDUIl4/18WYBgTGsSNj/Ao+/Q7yjskyTXXJ30HIdI
k5V5AreaPZWg95ExKLf+DquGghXmnTCrWrn0Vk/Wv9zRNY5RC+0vOhtLF8sE
pTBKnqDegMwNX+Hcdf7yF+SNpnhcuZi01SSj20BCdO/85t5/73wcVuufwrhn
6XytiQsnFDFr8K/s9gRboKr33jF19x2/zrItcz1yXRjbIW1AauS02eflYlvl
pd58H/+g+w90dZODtEBvKs5PnCHJJbBvTtdARs6PoiZ/k+YFCVYyxALmJUYQ
2+5yxFfkcQnvKP1QZOllBY/vk8XOeJeiiajH5Ar9Lzyl8DPv8Jt5phbNjSWD
YRndEYsc9pUPZZuRLg2bDzo9LhYfp+gXxy3sm/hZyrEJnCA0KVTU7/SAUBTo
TocHjeM+O0mu0NuxEPrBU7+tnE8rOnKUJ0BczsZ77TQ4vTItR3DaNgscPAvn
omffsn+vEPaXj8nm/IliAAH7OiKWQ2vtoWNnnh678IzzbcOoD85MoAJvN+k4
ZA6w2ml3x/iwyJ7POMjmTeb+q8RuX2J31ZatPpT/uH2rrMR0IuYEcqFQVgQB
lPA8KOyVfWiRCOQa4m2mC+bpnrff+KzGzv03Z85gvY1tNnYf4x2Uj4hXZEC+
DZhXjYrLOdvYxW6RBe7NmIyaaN4vOa/Mzdo61GhLY68aX3OcVvwqueGYNWM2
XD+VW8qekQZpcmKedU71/tByE6kaOLISY4eB+7yEjBXQYEOYJjNHyex4SHtU
PTtIcqG2ZU3jOVOzll0SM499y+iL6Nzio6KasyUNikjVZsf+8FOwFJoWU3zw
6/dvX9HQ3gcd8rvmJP4g4IBNukQneHOLAn5B46XzyN8p3C+M7EQTpjncEE88
RZUZ2APaenrP8vKmuna81u1TwBjgDS/QLY17ZoyLgnkyS1U79XQhaniwcRjm
ImEeRwYn/AbHzmJORoGfNNosnNQrOglPQMjzi+Cz7q9CCvAe0cCZYSb3D40l
EhIgbZMVS9lA0TNiuYTjynpwFCDj1ukXdqfUSKstjwYJ4Dm0LL731cFV3YYX
NHL5E12DgM5aEPywxTO0afQ1rQn8kyuomsHPyujXTpfSFIF02ZJ81QSEVF+I
U7zUQAbODeh/hxpI05h19qgdfdeXKNMQbkyZrOH0nSQO4PScTvxSpGZMHi5I
XVkGpP6dt3TlA/K6zISXuFcECS9pzdZ2fISBsXQSBXGC8E5HG1mnHCTYw5JI
AzTBHnm1xOaZLvRfEitf57O8BflzU+ULEMirEtjpWH42joK+YoAZTi5+Nx5H
zgSHUYcQZV047qL0R7cSuJnd0kN04HdTBWMemB1WEnTm1nRpRGnpQsJ1JCnR
iZ35CB564ErvYhuLHOYY+V40NDiIjC0imIXbdxdmvyFXXt0Nsb12IbZJRxV2
QrszzW6YUoKHv31wDqEyr5SQL8cEUcF3Z+IiwLGECsIs3irA0XoNeXvi/Y5A
TGxfyf2CbXa5Qo6B8LTDi2f0e7nGRfcad+4v5bgE9wmoKro80UB/ubhIzTRx
VsgR8nm+xVnl5u72GSRv0aH1yw3YdXJgcx02egyHQIOWhjLrG2ZbPft8Yv4u
LmOW1+EN/Yemx1u3w3hva++wpIPRfMvOylAhxC0dNNP43wtJRwoPTSw4eRO5
VflNUbw+RS9Dqx/4ZAaRNfZL4h/lbjODqcTcI7BxeaC83O40j6U0mXCShIIi
lO7pqqhmQJaeBxsdD4NdIO6ABsgqXYKIRDZEylEnykJR2VXKRmdg3fNq4ntK
1x/zXtgmc7kR99UYOwb/YXNAVNas5RiUroVise5NlN6AEzbWqIhfrtkJiJSu
fYe3E7dUqWS8OBKx8V6X2Ovjk2tjh0c4zrBKlX3YciZMQP5jJ1I5BYqSdPxp
x56jjklk2H83B8qnF1EqNfuCRJdGZrmimMCy5oxUL7nYXeBdbnAvgJraTMPh
d23CgKPqhN2+kjTA+cMYZTNpsJ3EmEYzjzHsy3moeJ39RSnyWS3y1NF8T3wM
Q0ws+326nw0L87o09qeeO/ILyHF58aOpec4xPrB6vvgnQynxPZ764SgRemDJ
Pf+aokUfH3KYib3YNkzE0SQXSueoUaNXzGZwpI2klzScKiUO9SfHJ5FvVJ1X
QQIhTVcT6Mkwkdg9CnaX80w7E3wSpqn7BDvxFMZJKrCQd2eXNNr755ejJDlq
91uJJ0e5YD6LD0TMNWYJFMc0vn9ef8bfdjUdWgcnCuJBO+1fyEEsTZtVpQKE
zc4ZZqAkC6CWecuk6mhMnjV5gPqJy5CD1bHlBOu5yVPKmuRsNhRnVbHjDLc2
245hszkrGxgMOg3FAoc38A5MXCLB8zdX8Mhuxq+4oYSZ/+3+jEaPJr/lz6PR
r0nPH1vl0fvn1988nntD9519wyRJMNAj+rj70aPuMPA6t2fy7l9BLFKaOdLv
r/zJcyAVrEXgz/g53WJ97l7j9czz0LK6f+7e0Ue9z9EAeDmiP3hPDo1Hz/3A
N+gNkzIVXZET/q8wz874/240K7OXMgNfivTvNZ69aB9PkofAYSfKkKn27b88
MIyROPuDT78xgU0SnXfesIAPyYVthYKJ/1NcjWoa8Nu6zH8RnsxMWqVEXPol
QjDWj1hlx1pVDTSn25SSBXLvPb9bCM6ygpIlchV6f8+s6q9IugOpJH83a7ib
Esx48NzR+4bcDsCZJT2aEqWvzt7B/z8/w7+/ewVf/en9xdk4ydr58X/ctdOf
vwXraam4jfnOAAEFPOi3JDzbXJOwRqZbKCJa5dkhrZK4FNvlmSkLYbeBczP1
1ILSj9FU2JWcC3i7ruCXVtN9qnUvkjalAT9Ti4f6IWaW2uKriTMgN7AgrJBi
iAiXuQ//N3mVa5AuTMtjdtloDpK8gZTH7EObsQdjmrzYSUK35u/OKatNHCpS
ThWOj8Ue/HINJSdR9YBNKtSYE14YsTK/efz4MVqZ3+1lw3FiFI0y2qeWHQxU
BaH2G5TWUpq4uEqBeCiCKzk9S/XAumqjngx1tdYo9OmoI/TwpytOSuvW4PwD
1+kUy+kgRUdsZyBjiUrF2EO0rUpxetxVzIU+bH17fy5JmCvHx+Wpz9usvYYK
XQ3ya4euL6UpleVsMCvNmtQN67SwiRRUlJyWsK3ylo4hZC+iy/LjPa45mRYT
cvqK/NrP1m3ULu57ymtPJ26591KWbIIkZ+v5JMlvXVjuN9aPf8vlFu1vLCEX
K6LPh9xo4uVnlJj/5vJyyvmi0O/kOWePwvaORj/WORAGp5y2sWnvfAvJrIDP
gzptzlCyjuchf0KtWzxNvq9u4WzqMRdks6YaKqTK+331jhKpPeViP03OYblB
dM9SgZ9mnx/DxfXw1PcTmOxkCXeCFeuT5KLjyE9u05KLAGAzF5zETUTTib65
JBtXsokO7bEo0RgM43ewDxdHZZCFQJhiZOI2zVvNy6BaXGCM6B6mRDg4zQup
SEmb1uVluQWOyRVn5Ghj9mFAEWChhaUbrjzPbilPE3+IGUGSh5dSkQ5bKyYv
mQ0Uqdijb5pPn1wlIH3bsFnQPTQ1Z35k9kkpVHjA9ocBSIUIU61NC5PZAhyI
bnE9bCaO4Bl7p1QUdjpIvOeoUaT8BBmGA9trKMgzfRKgOQKSNB0S9tTCv0eN
gGjOUZZx0nO2lmQvZiK2ZxmWrJj8Pi2zEUAA//Nuxram0HRyzzVmAbSXiv+N
7/Z5XcNGUa0IMYqGjyTE/ACWgkyKGEn0cnqch9AiPyJLfInM1E2hzlZp7ep6
i3yZYSkwhy6MOkO3R5KyZa5d4QezvXYZV1TZgBfap1CC8Fz4QgZ9j3WKjt4P
7pVRjlJWj0p05qfB5ZT7QqT1uRz1nMfBWeEOcPVrUTUZVWQtC04ikGGzyGkg
CSUKoxHnzWmlg2GcJhVB9w8F3K4m3QEWmvsSe40EEL1sUiqQwRBzVac1Vg3u
SncYWGqmzlEib96+MV2CGcewqACycTok68RD/KPx8mPgPrpYOp628/GarAI5
QWEVulpT62wdxyhc0YfIo6EWwTShwXZWWPv85qnqJZFoXahH0muVRX6dsU2C
8se/AYE7QMzvSJlaOFQOCWxopixYNMgm8IDQTbhOBVrG14D0O9AplW22b7MJ
v1iEdyC1taTbZbUnbj50EJqvbV4TFTR9/+7d5RdPpk+Yj8KlxalTxneBeSWi
LDXZasNgFqLKSUKUea+aP0+ePP306Vv0I+ByMNFzDWIX3zNPa5SmCaFrYdIB
wXJgnGm/FSuvyMoVkI/FJmE1kKb5VNK8MDweTAslto6Cv55Vi9yF/WBGFEI+
ZIyb66V7r0vFmi+XZhZc803aOj/dbboPT0YzcYVop8mpvlFqjyyZOJKi6ioB
aPDm5clo9DsDqQCaqoapcoPnJbIktEK+hScjanPZ7HDG6YIrTOjS+hX3l67N
iRVwFlqOsc6el2uxLtznXD526ocpdQNKldRCgTwhiwexM1K6qVjw4PFLZhnr
WlRPJKVWKv+Un6ACtOhbbVA7CWvPV6WfimTZ+yTdyiJ9eNMu/k2bY241K/5C
/woFtK2qIgveihgdDucjqsAJ1W43Lyqlnl/fgrBtJmgtwxMoOxlP4QPjlER2
L1Wog+qR4g6h2aRl7CyJmUxzhkLbcGEcUptL0KV8J9Ky8wgFKzJsOZ1lkAhJ
9OI79MTAaEWOojVybHx0osauCrRBpdAU+UZJLxXXIYLQarw0RpZmUX3wtpZr
qqlDgUcWhzkmf/XGzE2Abxx9/IjvUlEPenMyq/OFbNwq3QbGN6aHmteIJHqh
LpjQHu0IoWUwXRIvKBp8qAEmzexX8YGIljQLRxxBmkcjvNhl0jnQLLBqWUXQ
nx5PRxetSnOX2SgPChvvKSKEqS/bW64GIs/YbJcXoHlvq9IFGeBoW0Yf2oK9
1Gb8RcFQXy4TiIea6MzlnzIyaWOD0Hcx5BBWpa7AFqIwOypNVCztbXGXbuPT
0wPwFOdw+ZafV7QW/5zzjAlOi0/Qww0iYawQJQRn4pBUmrzd0aKjV/Pc1AVH
//JE6aYmD6lzgTMesUZAOYy1FpTfEg3kWI91eg//iEADaZ3mzDgP03bYL0mw
Pw4egOtPA6yramt15v0dm2byxCggptu8FnfVJksbTpTCR9mCadS65SwsgqSh
HwcINWTESMJJt+pR07Bz4xBSjLHBRCivt67zFYw8KbC6FD8tI+/RYB2CK8Y0
5aL38WZJIp74jsdSv6IJXWPNMsPSK6qm6PrClruarHqf2rMU/d6iauTL4aOP
0nLJgdLguiRzgnJ36Va21pEB+jHMogF2hNV45D3xskLBEAcHPUJorYQSGBGw
cAu7R2Sw2Yqsuc7QvWDlD6snCDmWa0H/PKvJYu5gVeA+jh1dwS+FAOm3bIVa
MX7M8AZcQyTW6N3QjGEGENULBncW1B8OL3Apr1+J5m2zCeuz7ewO4doFKMAJ
Xsxiyqrl0juLsyU8iOi0DEmJdrdsDzpZTDk6lxIMHod6FnI0JduUUAh6Srpd
LuImX9U2xdyx5qE8IItQpZ4keO9ck0WBVc5bpzUxoBh7GaZOR9FCq4Dlhq5Z
GVeRGnVQfcSWJgbQjugI0ofYS+M0sVDbA03grKLvCBJ4xMbf5/vsjZQjhlL6
2ngwWApYP99l4V3WDQnqF62LsSbot/gZMrwabRdKBvbpf+qQ+xZWv8gIrcov
gExWdbJWmw3LDa7inHMCJvBMxkzTeycW3JM/PBYYnS5kIKpnS7Sn3BqJc6qp
RT78XcmZ6VQDdlTVYze/SgElj2lf9CCMkhXywW+5ZDtMwiA1Zrh+Wr2zFMXx
mYsuO+4+wKwPHZBrxNUDcPyPDwOIBobDsVCMPYCLdSZxzDBI7Ao6AkxAG/Jr
OJyIJisLNfaV9UXWyB1DYRSBvgKlxKMxGOgIrCrBq6jSml3kNpwQKJSRgCbT
EgFcVLdwKiO5wiqBEurNiDFILR0yI3YFJIwGFOUMKzwhJpG76iOu9tRsaVoo
8WEevIfDsT1hofc4edy7rn0Er8G4C5wj7PZdUCgEjoiqVIwRErq9T/R2uBTc
OXFImyYZw4fEUNTf6jvETdFYUBtJ3w0jXup9Rpc/STGv9VkVwILwooqn/iSu
r3Uhvd7CEP9GrumU06KVOdBIMxjI7mq2AxVLVo86yQ6rqLD6BnF6OBK8ydo6
n0+T77J9xUHQJiM0oQO3vkYsdgFIIahbD3tJYiDcXgdUFFde3i9baxi8Mo+u
MekCC9aywSozcLmUEW5pQnGYZmmT84PstGAFJ1aYDlDzmGHoSNy5zDhNMOtw
DHGzlQpXHxapRJgnCHihEQPSXfpPgzf57n20wNVddCTdZfSP8CaoX0U0xdoh
qTC6pVTm3OwKNMmV5bB4v5RxzniTaZK4x/JvLYEDawzso3AeWpQX4mS5y9Z3
hQUTZZZxSITvO1lrDurW5edIFQOjLt8VewTtlJzMaUNIM2NyCA1cCZkEH5Rh
OethGLbPgtq7kGJe+zLUgbcLCgwwfH9Kqoco30vK7hkfuse4Oa2DxLLIRO18
jcZyGFDEG6TWoSsMcjUVvp5ENS7jTvDFIhaj1ui26OrE0DNyXExLNzA7AZxH
PQi7QaXb84JQltqmM6F150ZqPUazZrA0KpAiE5/dFC1HPw7G8qyOH02z2c0W
OYeEKEmsD55EbV7dVf7XdrBiylZMk6+D4BIUuq5bufhtf8Gjq1dlQQ7bljfE
QekCSfnVwfwr1Kwm7U7UK1OeaB5jcRaVgdPodBNQq6AN2gE5++rPEecbGRyj
5BBKDfvWlgyMF5VNe7g9pOkDLEQ0LoU5PgDrJdF7GKnOGQA4KkqNDD1WWAzE
r16EQD7lw0s2RHU3zohTyYUENN3AwaoTXLPEl2Pr0nn8lDq2CDKPUW22+xEa
wKkgIbCyKwBjvPSuZ9ryWmKs5ymXS9vMDtKbsOJxmcJZcT3+YXoIfsrXPL6E
dDoSOWUw7nlVY1SV1CLlVIjy3bTKocP0DHa7h5Dd4e/Vr7ekuuZCOUOIjEhQ
gtzRoBM60mJ2ExaSjDRW67vAiPaX7MLSynZencBvESiBsBAXswiCT/ZFgTig
u0DEJrvM0lAwhdy6OscgHhlXexnmRASFlj1iwE2BiY8ijSh1LZ3CTa9YwKOI
6ieyAU5hPCjOrOZ/sq7s3PscFiOFQSccoKYeslSEm/S9QwoTSXD6N0WAN1Zy
aT1nH3NPTMeVrhvXQFwimcbM0VVN7w1cgBXqledlY/EFsu2nlrSndNL5KIaX
nDrNh3DxBGPJK3ze8uveApL/ekLqBSRBs5L9UqyPgd4W1hCCvcprD/VjwPhD
vZZMq9Cg0pRX74L5HGF0oMIyUsiFxClo3pjd6pij6i2mJiuj0+DHWlM8V0BS
yeft6kcOk8/BEDmvqT9o0s6q1v6OYWcjdpYv49fnev0oRT1XY1gZVuDVxf15
j73Q3oFKhYLjx63NBxHV96tnX1OuBBvgymQ9SC11FOEWHYcT0TF2y94zQmYd
qxjy3MY4UNym5/KMcQW1iGVoh1UeS3AJO8yW97XFjRM+kpjJHBz9bvI6OhEt
g+an3DHSYXf2XCeugJUdDVgVyTSCVNF8i55dH0d5i36DKfk0FiMav6FCV79G
xKim/e8hTtjxtWbYWrz+Bj0PnN7ki597kFYYBVyCNB6RgOVJCGTsXVaDexgN
4BioOrgFKoLTIihuSjQLn+J+0N9ZxFkcUTrKXqSs0OaW20pJrUW+ykVDk8lq
t5TeFyniWmoCpe5UGMND/2V9/DZIIzEHDrwckpGND5jEckWrQ5AMAu+FJIuY
w3HxziD39T5RIQZ4pzHcSzQDUlAL2Y1aZ19ESPNjZ0r6ZIGZpE0M1QhtqgVF
PNvGOQgi89YkiaiSiLtDi+rya+dMCX2+dVx8gu4gL+qYz/Xfn1j0M7J2n7Wb
/L//839N2CyTVIa5mK6O5yspckceAodAAhRjmDKWK1R3XGcOBmHC/JfG25zk
TcwNfEGu/cGySWg1btfAe/sisEMofJSdzA7VqqwkBGjWyWVT6miLTvTfdlkt
ChMTn4t3sm3fI0E5vIfw6KTDoL89WIHA/bK5952Ye8PAecnHh87sm2ef7pd5
QNxRAI9wff+hEY8YZKa7AI4kedimoJQknrnmt+3pgj/wlvIDnxiXqoZI1897
QjxrFTd0vy8m0FrZ4NS4T6N9pHp3YXroeD8DATHuEXSXh0W8xKYty22lIowB
k4ETlpNsGLRxNEomffUiTtgRU6hv3A3UZF/ClqAWceMOmqHYqruShb8k6rbV
VpI9OjAbkXqI3NvMmWTB4AiEpzE4AoovnAMnFt1KpUXBqESdTmEpnMuu7Vmj
vzea1twk3FtBaxkCy4DKLLCzCM3OJRDKXmZ9A+DK0Zi6LVkJZOGaduBwNGBL
Apa7+/W9jwCle87VQ4JqfNidNBv46vdSWETBeSTBUnbPgTV53GGP7bMPfAXs
PpJZe5VxlrmGCrT1HFofeD+mfsekLmROVN4cwiUd2IlOd6LftH72Hy4WTeho
UdHIPg2XdjA4S/ye+GjaBA6k3JoxCGMN0289s2VDxqZkeC61DXrb3bfYDw/B
O+80eDMyDnpWPMXECAGz2U2nzgQHiq9mOkWkOS3N3+5p/9wiaSFBExIYNMce
6VBnHbd9p7uOy+V34oH0Im06NUUty7bi63mFqpcY91IPmjD18b3S0AjRn1Yi
QrtXid9kWdvHkVmFPrJdf44H9rBvXET+D1O5MYONkqSZl9GKs9BXkpfxp6TN
wTe3Gdi4tVYiNNyjKvzpPSd3+i8DZoR1TwXBDzuoMWmsb5IdJ623l7yxwvGx
3UZfQ9BOr66SJ9OnlEuHnbf531+qSLLVPvddk07ZEpLqG1SrI7mdGnTSVCIO
MTWcujc+gNE27ngC1VUteeKIHuSUsnMu6sddO4Ivrs7PjvEk8Tdkr2J5yBV8
VX1/fMxq7Gs0bdBOI1AImhczOfW3uyw2XEZZtXJzSmn+dMABdhC5oZRVmPYd
lCl1v3ZNypiG6ufFNg1TEEwyeZgdw0xeHTk+7Oz04m6ThQGzWablrqLKHoH9
JOxIUc6Zt3vQbqMDulJN0mXJPxXvzMD4Mcgbx2DSJny/ZO6xwabmeBc/GASQ
yxcL03sHcQZ0f48wC5TNMtGexCo018M5jGwA7D4M1q7qFeXeoTcodbXNQRUK
2/n7yCWSOy+P75HgF+v3p2+13keKOXZYsSuJv9bW9q+4RyNerNmr7sxJ58Vj
pUhjArUixkjQhNk2pvwP3Z6UakJhddxlxmI0vPFQqFOkM2cASyayNmL0sBj9
MQEzVWVcRNXd7rQyJ/cLDzPs4v/cxydMyneQHUBeoDwROYOeypXFg3XDGn9k
U14cfq8rOLUKLbKDRXDSVVCOVfTfZaeeMQweSkKXRpZXBEbj/YtBrhAFRq92
FJfnoRYj+3apmm7Fm9S0XDYrPxX8zA8U1FiHGY64W9TSHg4eUf0wWo6xSsG+
WKDQxHFgF5pRyziXprn27XpPl8lVhC80mazRAto1akol5dj3bJ9mqolzyQdW
ODy+cQdgcEmQwkd6yq6J4yKb7TjxeJGnq7KivDmbsRWHXXdU2d/zflbmMQVh
zvU4WcDG8pLvDHw+EshdivRmZcBntgZfhU9bYbg5pc/5LYIUQtw0WjoQ4uhh
L8EFeZrsxuGWWh8fuj5d2hXJR1QpGtvfYy7I/ET3gUtCKzjYHLQ9E7TgA0wi
dtm+W5u+X0MNkcIeaIiXzzXXS+aY6j30iETkBLMdtlz4ktd2r0iseM67+3Aw
OcpBwvj2RvfYBp/M7jytbM5XRbXaBwk8GGDCPMwIkEjTQXxqhJAQFS0XhWRf
hlkd3JZKM6PqXVmyg2kh6bZRC9/cVy+6M6Pg23CyPaYwoR8Kb8uqQmcEmOBP
poxbIu+wJTxRBZV2O+1DsRk9ncowk9idePeLDWjvZ1QNdfwOyE6wrL3ZbZAm
FabQ+57cPtHWH0YSErVf6/YTaQbgmwlbwMH7YFb2w6/1wnfeC3QQx+yMKh/8
z/Cf/oOJwtZ1Rv01+I//HgfCSEDvz6k82fycgQ3giTBu4H7igJCiAcw/oyfp
Kbp8shm/fv7045/DrtzwXsh/JjePzM8fuY9lw+Bz74FHweJO2+y/HKUnqsQQ
xaPgZfHU+UmfAdazrv4/8mQfoCN9EZLHo+jJQZJ9RL/lTjy03F8jkh2eUGfM
Q+P8OvTF0H5+1q7IXe7OkP90Z/VIn+wHmPw1/Iu05pNPfh26yD1Pcju/6Mkj
D7b/Uus+j+812zvG7P2yMyZ36zi+7w7da532AD5vh8RpOfikmdmNTOyes6V/
Oa9eMjil7v2g20NuQLoSg2TdvR8dZjF8hf7b3w1saA9qqAULUPRQp/JyvTGj
qjXrfOtQk04/p17wAOBoXP9t9UXbRjPpdJMUPSJ0mLtMy7/bDhxdzKeg9wZm
gnLip8vHC3dAgwQ+hydDE00qMhkqoV6h5aGllRMtoTPLmSTO0cK2laRQic8u
qFn18UHjzDyo3x9GmNUwkkuoKiMgJAwrUnpcndzWOVdX9lBGQD6C7/lX6MN6
Rw9WAxvm2rFSLkaQIGiy4dQ3L4EnCf+JNw9hoLDpeejYw6qN4e1ml8vAUehN
H41e2JrJAb9gkKS0daVGUZNOiqbIXzHm7ms5u7EI06XKZMK5puTlEDTqO7Lr
XVhQbZy0EbiNhjuVyaVe6Mx6IP/mmOnt/TT4TZGWqx01qhv52ryedY7FNrTl
lAjCIHdiRZ04iUZsq80DpUzx3hK+0mUnoQe2F8gq+Az32daTRsnNMnAnkQl/
zZFvMerzVpx97efHSHKPAUf7q44Mh4Zss623W26gcag4ZJzsyoKAZHCfb/PG
mfZ4h0yiiftU8zu6SVC4WilzIAaIDA/LgIUK6qxxuW2O25ywKSk5asj3I+yJ
+XxXMxXso7ZGYbILg2IGoLKOxPcm7cAkuVloRZItmPGiHvQp0sV5TBMdglhW
c25uK0iHIRWG2Rrk5ZYf9txookkE5PNYdG4pNJsQ664Hs8i2BVp300UM0BnJ
NxqAc1W18kmRVFm2eH+i4459iHXss6KEA+Mf6EmQYfoREkA5saOp5oq8FqyW
QBaT7xXa8siAmjqIdO+uoYoLGiHwpPXcR8fkPLxMWP9mVYFzRZT0GIgE1li3
2FA0N5HLKC+nC6nbiy0223MyH+lN3IC65rJHRtghPsG9ETlTlLbmnTH7YV+M
F6CHJDdZu64WBLLDbia/1Zovgm7WtpJsgAAVTSZFoAM15p/cqnNJXUrs4fe4
iJY73+TZrQMxMJCacvHucQJyOabJGxekJa+iexsV+pOPDJ29LvbswlaVRq2y
MFzIqQAFBXwUzqLaRHAex1ofxVUCNBqfA0ghGQl4CZ2VmXN/YaBAy4Q8kyLZ
vpF8Jf12cUIz1GqkVIph0eaM2hL518hsi1kx/jkRU8YxMTXK5c+JpSN+Ucec
CV4Uf+5fZL455AQ5OfAdfT9CkzDuB9vzsO5uz8MxdJN5+C3f/KPjrm0rD/em
WLqRr4DxHXi4J4u0u+a+h4c9Er/h4Qsh95+A78iEo4fPEMISPpaHYzv3kXkJ
/Iq/fqTfnc5gd/jhR/RB0EU3CR1X//irvRb2u3/kWSyYWrpT8G033RTM9Nzi
4Q8HyzvHYnfuV/P/4cMDO9t9+ObQw9GXwcNm/eHDj/qW1Bn5Ldhh++7Iv/oc
gQFXYY83tX9kM8G3CqPe9+fkL7vYPV4Rx/O1n8rdcgC9HBcadWMBNL6P/CA0
JVuu3q5Buees/eZk1GHL/FLLOEkOsnQ0XBO4cZf35pp5q0Dt0R3hKUmLSIH0
bijcBeQ+anazSQDiHAQD42JKz2kw51PMVtMNZnQ03N1z3MvueI09vIwy9sKV
xC3OW6xeYZlK4WgSq9zQz0jV8QgkIasilLFmEl78aXFjG67AiIbxBi0il9yO
zIQcpDQnRPysfOzn5Ihq6HZtZzYkgX/2/ObnEf00aOdrf46lYFSgETUxFqdd
L810cSYiFXqkAs1ZvVa/Zh2MwTBQAUTWKc6ZFNkxe7BswZbksWnPb6zuCjsj
UHsDoeNsFGA+oCvjoZefP/KMCC6jp52GSc6uqK2Opn714edOgYd4B44cayjt
yanQpVQNV/c29JCOH2gNcsDfGTrk2KJftnsY2zmiwtwZo8ULZCr7gNqgkXG4
jIHd0LoJZyynrd7shHTiJsqqOfAuyq5jwEl+Nk7IOeqiTR77LqXUAYUBTyou
UYU71WriMF51bAWqr7AwlseYiDfchdtXOZp9ZifDHBtjkE8m4RQ1+kBejEu9
EIdQKnjA+pCgGHGGVRO8zhMSHlLgwyJj6FC7cBQpBxYSGcR/SRPxfoL/ll2Z
Fk6g0yAb81gJKNQBy2TSDDB1IC74/Rf4blpxpB/HCx78+rPWC0Z5VixdxYW/
JX242NE6tRd81O9bFvCQIBLDJgtvpQWAcJvk40N1buKC/a+xV3NXupt1IRPS
plgp8YO+dle+NbI7T2XJX5BTkxmv4ra4ErUDrbKlrB6vhrmiAoARbHtIwnRk
3SWtq2LRCOffMoipZF0P+hJ6VqcpW1W5qjo9l+Kq97TUHTsLRby95v7QJ+h3
KVtb0q/MhIrkq7rz8HIH0mjimeNXk3bn6lbNq8kh2VeTPTY1E2aSitgWbb4w
+yw4o17mhbjt/bgLfjM1HT9V96E2Rab+bxFIvKkEMwjUjObKgNd092MM+QPj
T4M7I1xetCQJwsV6Zs3pQqpdTcXTPQ9uU59uSoTsN8gwK7PpEn+JWjEZsCTa
bvwBU3GgzDaR6hoeKHciG+ZjtFzWIOmtZlbqxzXzYL57QAwM+PqxVISBpMQ9
LPs0jiDpLqMYQOil9nBXJpO5M+MdVQ/3q9eizNHlMZrFUdBNzSG5K3qMGeKY
65gdcgCJrvTw25ZAkAUl3/W8sDme9kmagX20BdQKn2OXqXr9z0yoP4fuODMq
Fxk6B1y+lFxC9wKv7ode3DvUgKjCO56fdpo6NAZPDftgDs/uruX17qnVB0UH
PrASbqDers16lqK5OGPG2jqCJktBlrDMOtgCdjr3EPzJQFHyUOG6AP7gV3n9
WcEvcUtL29F75ezidkrkkM3967xcELfpXQr6Un/Xi2M3QNgn/T92ReKBHVB1
6GrKA/ZXsA+NOFDvHlsd3dEMzsOiG4OSufQ4rbtRppO+n3XtnkaBs5q+2RAb
sNdHe+459JQ43NhtF8l5Ei4R2YDs/c7JPJRwsXcB8Ss51VXuYI/UDaptUNrE
+h5NmDE4WkIcqLmH6CKKBYgaq+rhYYHN8+Moh6l5zqhJktRDdNiGE0+8LlGw
u26pjw87FIU71UfDbEf0UzeHGFVm3yP+jdoShWGsVAyQ0lhE2g4rh5xWh9/V
G+LmYI9nH/iUA8+Ch7RrcQ8heETDTnydfCgIl0ShUoSaxDYCB3ga1eo5ljZN
zhX0gDF+BpSIsOODA8oJouhMIMYf8FM+eZGHGD5047KiICCnV+/OzbfHYSKC
Oi65EqheYdxe77xFIGrIUxquSqxYQqbd7jiojKZdOd/fe8FO8Q+gPsKsq35l
3cBb8S4FaIAeWUii/GOp9qG+JJgIwx9PQ5uzczH6mbADbw1ITafmO17bPikK
jgPvmBhGYGnzHqKuY313B+1Omas1vEDGI1hqJyKGa2q7CCgui+oA5JYN1jKP
8BA9gjm21Tl0AA2kqLQD3uYUe07uuigVAGns64/0JCSRziR6xekfHeZjezKx
LmedzgzcFW3FXTAnB8jkoKDe1jnzq7OBN3thiaDQmDiT98l0aVqbnAmeOKHf
hq+10yJ8oKEhA1g4mjO2ZZvAB5TEgDDjUxYmnbDBSW9c1AE0xh2+LBsSrLI1
Ax04RgC0hF1h6PzKrqa/D2CU7eXpwCI4hslQpAFCeQBWEIYdBC0gUN0D1ubX
GbJLD3PG/jHvikVRkd+gmXyd7amPkBbyhh1w0gLTXdr1xoUIov26SYtcskfa
eseCWmBe/GjT3jNhuGUtWjM5l1w5PRDFkq6YAT6A9KV04zlsfP9OF6mhl3s3
mkQfAuI7FUXn48Ou+qLmGHNmnv4+sd63HpWEpXYl2ljk1kDgnkjrcOYIJWcF
2aJ8kOQzZCydVkqiuCiWtbcIm8VpquR/o3wWw3wYQCWnVtI+c6VAXxvacATG
gw1s9kVGiZjNGlbzrcGI7H3Xn5EWPAnztHmymjKDBzHgg2usE06M/60050G1
lC3QPackitZc+bhZufKdsXwzK9Uhh+3ZsaT/4X1k9bpx8EvGEMcgl9H6T+BV
CnXtdH88VtKPexN9xPTWH9OOUWqsUEhPtl7a9L6JM5JoJPSqmKS1qXt/Y3CH
EW0HP66lCWTUad6cJZJgFCtzyZsujZ6ZXq/mLr5tU7yZxS80W3+EPp4ej6Nb
GjHjvcvuciCITp5m5k7/ziR08E1NnQCOEvEHAq/ChEZJTC5kWTU5blxaZpwF
LvBszXD6V1vBmzr3XLK9wgg25cZ3DloDqmlrYprsc7jPzZDaVKed4+3AGX3e
/TjCDLUDV8R6eviSJFjcQFvpiHFsU2KZL3ifpTvECNwZXjRAZ9TMwaMMjvtn
YkxnilGYjtIUvwUtHu/SKOlePYHeEt89OfhNzH2AfHDl5mgykw4ZX14lGOd5
SMP0gERpl7gE57qr9iW7OGy+WoApSrrr+tp6YXEPvBHnDGo7vAuDwKbOxcF/
oVJvbwgbO9Ig+ek3X376hNCp61bQh9CUxfznJPlecW1lFsHy/AxcRZHIJmqB
/gHTGpJgOqG2tTWI41fv3r9Jjq4yFpGgsyGIB4zxvhU4G3gTXps3p++OFT/5
y6+/+fRpHJ1OcDZY+xNMIXEwWig85XpdnJ0nRxfaxTyMfgV6yDEevepfvk31
V7B9DOlOPgCYIl6OnD1Bi7yZI0jRXqBEHC8apFPSf8JMbw2K4iu8LhS45ZDF
ilqBLq8wnYTDOZiwrMhwgV7qLhO77bCtd6i46iiEYaxeGgRt9Dkb3IW2N+eD
7h2/VJDMUjc/EpZNs9u4gndqaEgWXgfL2Pc0Nr2o1/JI4nKKJFAvMdyGZrog
EBzyFqYMvkUTGgsphp9Kaw2GfiNjwCPieNXNxYa5MqVsHThsui+qlNLcLy6l
pzX8Hpu6SYNrKnyjfug2Wu1eiLZoWreCESYfT80JBw6JHmes9URohZcWs/G2
OW+O0UzFeOp4cp2mXvX2NLEZWtL5pMfZa7OjvWe4x6nGjMi169srzpinmVxQ
LJ3x1u19w/obqm5sTcOt+8U2FXA+oWNv63N3SzHPYudUxx3RUCXQIhMvjkeZ
EtHbUVJ+WmdaeoB8we/egDNd8gJ72nVxKY1kasrTnreCLZfSDVcBu9AwuDxT
J77JncBr5itEmPAgsZ3Jh2kCbsrqgkjra28lRuvZKwgNZ/pzMolUCi7z0hNS
x5Znf0K5CPRF7XNH3TP8o8x+QiuudyXvQq9plfyMQ/zMFMD2Qc+BeLATD3rn
NqGiUi6JpIlXlAfyFS6kA/FIHnuGOnwWeCS49QTMWYmYZeERFNCUhOZ1o3VI
zqpg5ZqO9oRqHo3pq/g/BmA4KsqpKb8YjaNQA5O9OLTFEsLomMq3DiOms0Wc
UqSePL/4wcX1nJes9Wfp3Mj39Y4zs5NRqDTtk6Jz6KJq0dYy1gPKVP4by1If
jOK6be2YaYSm6wMYOqheSMd5DpFyW7K4Avkfmg5iq0Om156Y5TzdNrtCKoaE
Gbn8Vs9eXEEW9Q+zz8A/8RlN0KUlUW60l3Gaan2bove8i/+r+QQCEbwIG3B0
NPcxHbEyihC8zpcfulypHVobOyp/X2jv3bHNMfLYaa7dTRDDXqYaTdsYUxWs
JcKJjRDElK3fcNok0TvlMUnRlMdD5iqwaDv2Aej0WKp20Ottxg5gstTj3bOv
2M9SSu/GXAhtJ8u05rZvnRpEKkZjVgDmiHMzcFpJgJkhwHKGgXGTctzwbzZO
JeHbj+qRZCt5aUuITht0L4HWIlEBixG9jN7lMpF9IhSpXer6C8v+Pj4UbhBD
GoWlf1JRJgQZ3OqogWoU26ECi5PkimRg0/29BiQYxy9M+XbM81Du4FRxnIN8
tULgs50DLyrVZs+ca7uWqZ1eivh0SrMHYANzftuYWjJ0cpZxKIurbn7jesuK
8J6zmnqsS96eCiu3dKveMANnxi6HwpllacN6IRgVHOzoJIuE2WL4dZlaJIw2
qMKIzpS1o3sv0zn+1uSAEd2qo42oCPHvf65rihUyJ/O6Sxt7JpUacZaqtVQN
Yr0XOao9ZPLMmYuZoBrfAGEX5GIJpKUK3W1KbmvhwZIz5n9GbxG+agUsimc6
KvEExPPGHwtCeoPogGg5aMLkYufUYnNIs4xuMdFjsLugJrUnGEL06Q8BjkNf
9bDoVm4PcfpsSTgIxFRRHXUJRovVmWs8Oy2d1qqkYp9wLdHVm3SPrmmUe4mh
Z6OicGRucWCxCrGrunQnU5Lmomk90kKVlx1CqSwkcZalfOMKvg3HWggDtsXF
3ttga4zpuuHBBar5ULV7rJcbUEq2BjxbYfC7xrFUrikPOA/SsSRCW7QKrRBx
IWdNIWBMTjZxWJlxEZo+36rQRk9qgWuUngNXO7IRblFB1MXg5NuccT/w0B6s
02I5mXPdzgOUpDmb1Tl3yo48wajfSGeqFxdv3HkhSk6ZJe5JSQ84u7R+aevW
E/ZbLqQ7Dgtcm2alh7EQra1Hkb5ViBBUKI7x7KkGNDTLYrq98/CB9REJ/SyQ
yk1MGAevk54r4eX4XiwiYjgwsWsJ31VzxwStdgNSU3qbLmpsSRE44nvQeBnA
W55CeNkdZc6mM8YeHgcYfJ1CoajYIXlJeCUIihx/yIaFeFht4IUdEOsU01oG
YveUDjB3JWfG9p+ZcPe0b1RTm8DP4npBZU1XcZqZc96J0Agb6hB+UZTLARuI
Ls7MNqHnm+h0095Gh6a/lwuIfaAgIvmFeiZFEgFraDrrY4AA17Nj5pv1fKBP
VoQTIJgGtvlcRLidZHtpFXoW0w711SB1Jbvt8UjEE8Ssb22/xTiaXR5vjlqi
blYv6+R9yMKDhgnaVL7/zQxRizqDtkM8hb8HOYbRVeYxiCr95neI1848+0DM
UINfwY/IRbdXb+CBvJk0d4irJVxuIEOUWpegDYeO+yZgcr2mOC9BdRThtk4R
dHZQ2jlH8R9QQJ2/NRUdOCibBRJMiCs8lMxHrq5jNGJU3Q6XoCXTVTyoYIS5
YL3lpuI78D1SrEWAiuoHyR7p/YXMJoTO0sw15Du4rqC1EknD+a5pNJUGWeJk
ziOBWBpCywqXEgFAK+YLbsM1Zfk4eLzUANgqgd2NNWZ4xyG97d1BQTQ3kDv3
G/ZAC1VCEhsYL258Y8ali2tiRD2FYALJ7MCE6TJ4oL4in9UpI6O7LDd2oYgb
IqUWQdJ91QCT2ZiPFitKY4lUgarG2okst23cpU7LdL1SFfkEtDInlJCaXW6B
74cZJh3HaQxI87tmoANE12PpUlNAZyD61UJYyftZ75tcw683ed1i+KPb3VnK
q2TrL2Tr0XMoAlNPg6DWy7DnAlpZ5DUTfPXM9C2OMNz4XhI0jJjfQbF4kAYf
uhFpLq4BQTjPJjnys3CA9IGM13YwY+v7qQRCs8yMCFc8Oh+HWjk4nt+yFL+H
3BJNw03c9fLIqSQHyufYhXVxGddCSV+B5Mhl3vT5BdX9mHAZpeQ3e13Idcqh
y92ZxVhH/xYGH7u6P0pF7pkz/bgHtA2hIZaonbDXP4TAPJEIY7t2IirsTNrt
PIu5CBUiq4tuMpQ2FEI/jrktCBffoU3pgn+EzjftQnO6blW2ngMHXCmeLyNx
oO/ffYRZlybPlejIPMrtBv1zrv1gvDXRDcBNip3rUVPdnj69y069Cn4yvAkm
52A6OJm/dGdII0LIjc/ZmeAoTyS+8jfEcXUbZZKO4m3qW3wfrqtsQgfI0e8A
923HqFBKcBFObIcAr1Jx6QLQaaQN45agJTLnwmzk5n2wl/WuJEwaUXxUNjtd
Plb0hXQ9pOqJCyMOAKrm/w7oqQ4y1eCo9ngAEaaAm+UgcMyrK3g7Z+sIyok+
rLlfNOF/26XambbP0iNGp5soGY/o+siwmkkgKcP2JzovVjqdxWnajjtrxPfo
oe53Ik4xtZky4cl3vZs1CAFbBmAGYyAuHJkDG74/a2Bi583nNGSQoiXMD/KY
iqp2zNdV5fr3GHJmQ4caro61ZoGjwkBDNeURmU11edxg0rTzDvyttDvi/l2c
zOEipE6H57KTHa4crjN2FsWUob86cO5DwyIdxHvy8aG/9F1x54XVyeA3HbyL
OXe/1v222TfMfZzaEohOVCUHehBHghL3wz86mLQXoNfYPLhOqMDcBvJrIn/S
wdYZ8DvuwzNUJ9RpyN0vGnu3svPt52wnsJ4m0DNtm8i7N7i3qvjwRolVZTel
9vt12NbrdE8JaZJbAABBiiAZjQbrZFzmMWsM2m/dX2rpKOXSLKPUZbjoNg8D
732dM1o0NREiuVxtujAyReFizNPkp4xxmVmx4x7ozJMbUQ/GYLDXtfRfNh18
SAv4HnZ2n5zvMxD3wKUl0/HLx1+R6W6sCq73kv05Gfhcs32EXGSHxIfvdo/W
1yCD3ZF/36Zwmx8NdtrmeCG5L0JSQgUf6FM3yggf9hNoVjZx86WtA/MxG7dA
/4+/4apSU8Dmgg3+PpHSjf0Hy6AtLuvipHqR2HfxiqCustF23njkf/jqq9+D
1jTCXeHEcGcZ031DlYBTflFu69LE/O8dWZNkG6ykwaslWoVmvFMMe+zA4cqk
QCFE6RA1KQOi3Irq5ECuDvDXXowoPdD+z//GFOvkcheApS9kZctlfAEww1NR
ra9BYWKoa60yuPGF6HgOiiEm/O+KzyiqZ3fuQurU5p1692/XbGpf2H+MOm2o
MwgJ9UUfysgnoToU62bGXielVD+mml+P4OiFhCi6Dr44Wy5RYJTzvVrIN1mZ
ky3TA/Q8lhSfw7EqckUH3njkOZv8F1+EPuxmpAZk5Fa+o8+w+Hj7jopOnRpU
6MUTcup0/4hodDqKMj9vs1kyA7HRhB28pUnArukfn/xu7srTmUhY0eknnCuv
HAMuD5zMpQLPcLoIV/MA2YYFWY1KRX1/3wzEiKG26pdYaMldPMD0KDUlus4m
/KJeUvKWrnIkuPPXkkWM5ZQlihiH1ajtF9l06lhLvngA+CttPKVIzavqGsmf
v/39099/JSHcJvOzdf0YlBdr6Pa+O+8vTejx13OlzR/ep1QTsIIYpW8y8MF5
+ywfb0mJ7fAubVvRtYU1C5+CJj5lDA07m6KZvB9ce3pT5Ys44tVI3okNAlJs
Cw/gi6fI0gnOi/19yAmTi9M3FDelcgC+ehKZcH0fGQXLgZLjvuJT9PiVdQ3q
nnZfd4iBmMAqurPRTSp9sp2o6Da9pzwWVy2MVXLovcSiY4b8IbmTCQ4jvo4x
BKRbsHvNaKYdfzipU6EydMCJFvx6P35yjs4Hp627L0aaMJtpQlZnOA9Y4JN+
rdrvyqJH3Sb3UbIjVz+DbuJaAlBW1Mw53nArK8ZxbEbSSB24LTZtHGLE3AKl
QZ0dezuH0ZGRrRjHvseNKSiHu3OTcSzMQcNhK54xAzTdLTnRDQCHYapvjIIV
cu0xQ0BhsMYiNUiINt62EdKlNhfwFV/3mRPB+6WBltmlQ42wSmaNlRpGelm4
G84K0gIcusGbkQfU05afgfihYGSjsP8jW95AzMN5p0SBVGVt7N2b5pkRs7ot
AoMEaI1GgxIxMduPDkt/dRT1OSenzEc05SAS7tgVG+/MIoPL6vFxjIpypIGI
WprUsYeRecwRel7sRlCxKqeHgRC7NolKuBQY8TatF+QCLjk0Uc1Yu0e/aRUy
Xk40HTm8FaohTx5goewK2xEjLkX2wPUlylelNsKA9QbXBm+Kfa+SLUjUXe1z
gaj/qSdfvKjWE4Yuy4uScGWbEae6BbPFh4MmVyaG2TjhfZ3tue1GS1a3kO4o
ZYcmPeJBGqjuqdrmCmeTTUidXfCXR5dXP2B17rXM3LUdmmUjwWjIONrVwEt8
/YFpH2z7ngN1ZzGHQ84BpBqGq7QLB3pVmfNJYgkDku2kgxPjCcToGkArI1dD
gPywD95ysO2YEPzr91fvyM/IjCcHDhMov+gvZ9e/SmpXySX1o91ZaZXCKJgH
fS4v03ycDoPzKdYuLkbgMB6gE7YH1no81Ko+Xla4miVqL1S8g9dpJNAgJpkJ
Hb/xp4pIdQvXEOYsHeuJjvinRoyLPR5IjeM+Soha/ZCDtrFQOjJMwrJuPJpJ
MZk6bcPvdaOcY2FMmbZBRT4sHZNqp6Gs65Nywx7gAetmZGoXsYH7Zrfx++S9
iEFm1+6embgPk9P5dVndFtlixdApotBRRD/IAQdWtQg00PMdmqkw5fdlTpU6
34OG9QvsxtPHTx+jWZ1hXsqIa+zK6sZdTO5Qz8i9CfwDb9+qzgS65U01TX7/
7NmXXz5Ljt6cn74DzkEfff31s6dPRkevT19fMHd/UyVfP/nqyR++To6+enn+
5vzqgig3nD6FdDyEDGzJqyyflfkvqID+QoRIdcG4OqK65y9eJpPkZQaiohy9
lUUAjWFODzuGX1Ztu6wxSvlTXqyzYqOvnFzWGYz99PGTJ8nRix/+NXlxnnz1
h8dfPJs8uc/EcE/f/wAWwQqsV3b8k6KsORdXJOqAqbtZncGs5nkR7OT55Rdv
Hz978uzZP3/xhAZNy2u6e28zNJ7g7cCaF+04eZ1+wBKs8hrI+XVe/zlNfthl
6yIDi2YxTv4JZBLQVglrg7P7QM6C0WuwYdKsSH7Kil8K5wWQBKdckbyWwN9n
LpoMG4Q8HdjOlpUv26B8pCnsot27i4Niazq69J6blteRSwMqSaS/XIPVud0m
V2AbgvTJOMRwtkaXRrVFJng6TX6qqsUYJCEyGQUFnVcTZK2VQu7mTdh9njBN
WiZWsixHql/QjTq9vEq08RxhvE91ozVKAZO7anfYBOIMDM11jj3o/6lq1snL
OoUXFtl+nDxPQUTBsa7zMv0lH9NNOUeL4ge4L1la6w7ndRzdpBxTKvRKGHiq
sZkz5LQeqdN6rOcAoxWmcdyCl43LmI7+P44Pipe/CgEA
</rfc> </rfc>
 End of changes. 117 change blocks. 
1783 lines changed or deleted 984 lines changed or added

This html diff was produced by rfcdiff 1.48.