rfc9622.original.xml   rfc9622.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!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.7 (Ruby 3.2.2 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
) --> -ietf-taps-interface-26" number="9622" updates="" obsoletes="" submissionType="I
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs=
-ietf-taps-interface-26" category="std" consensus="true" tocInclude="true" sortR "true" version="3" xml:lang="en">
efs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.20.0 -->
<front> <front>
<title abbrev="TAPS Interface">An Abstract Application Layer Interface to Tr <title abbrev="TAPS Interface">An Abstract Application-Layer Interface to Tr
ansport Services</title> ansport Services</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-taps-interface-26"/>
<!-- [rfced] We had a few questions/comments regarding the title of
the document:
a) We see the document title uses "Application Layer Interface" while
the Abstract uses "Application Programming Interface (API)". We do
not see any other uses of "application-layer interface" in the
document. Please review and let us know if any updates are desirable.
b) We see "TAPS Interface" is used as the short title. We do not see
TAPS used or expanded in the document anywhere else. Should it be?
(Note - RFC 9621 we have added the expansion to the mention of the
working group in the Acknowledgments.)
c) FYI - Because "Application Layer" is used as a modifier in
attributive position in the document title, we hyphenated it. Please
let us know any objections.
Original:
An Abstract Application Layer Interface to Transport Services
Currently:
An Abstract Application-Layer Interface to Transport Services -->
<seriesInfo name="RFC" value="9622"/>
<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="M." surname="Welzl" fullname="Michael Welzl" role="editor" > <author initials="M." surname="Welzl" fullname="Michael Welzl" role="editor" >
<organization>University of Oslo</organization> <organization>University of Oslo</organization>
<address> <address>
<postal> <postal>
<street>PO Box 1080 Blindern</street> <street>PO Box 1080 Blindern</street>
<city>0316 Oslo</city> <city>Oslo</city><code>0316</code>
<country>Norway</country> <country>Norway</country>
</postal> </postal>
<email>michawe@ifi.uio.no</email> <email>michawe@ifi.uio.no</email>
</address> </address>
</author> </author>
<author initials="R." surname="Enghardt" fullname="Reese Enghardt"> <author initials="R." surname="Enghardt" fullname="Reese Enghardt">
<organization>Netflix</organization> <organization>Netflix</organization>
<address> <address>
<postal> <postal>
<street>121 Albright Way</street> <street>121 Albright Way</street>
<city>Los Gatos, CA 95032</city> <city>Los Gatos</city><region>CA</region><code>95032</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>ietf@tenghardt.net</email> <email>ietf@tenghardt.net</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="M." surname="Kuehlewind" fullname="Mirja Kuehlewind"> <author initials="M." surname="Kühlewind" fullname="Mirja Kühlewind">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Ericsson-Allee 1</street> <street>Ericsson-Allee 1</street>
<city>Herzogenrath</city> <city>Herzogenrath</city>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>mirja.kuehlewind@ericsson.com</email> <email>mirja.kuehlewind@ericsson.com</email>
</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</city><code>G12 8QQ</code>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>csp@csperkins.org</email> <email>csp@csperkins.org</email>
</address> </address>
</author> </author>
<author initials="P." surname="Tiesel" fullname="Philipp S. Tiesel"> <author initials="P." surname="Tiesel" fullname="Philipp S. Tiesel">
<organization>SAP SE</organization> <organization>SAP SE</organization>
<address> <address>
<postal> <postal>
<street>George-Stephenson-Straße 7-13</street> <street>George-Stephenson-Straße 7-13</street>
<city>10557 Berlin</city> <city>Berlin</city><code>10557</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>philipp@tiesel.net</email> <email>philipp@tiesel.net</email>
</address> </address>
</author> </author>
<!-- [rfced] In this document and in draft-ietf-taps-impl, we
see "P. Tiesel" on the first page but "Philipp S. Tiesel" in the
Authors' Addresses section. How should Philipp's name be listed in
published RFCs going forward - "P. Tiesel" and "Philipp Tiesel", or
"P. S. Tiesel" and "Philipp S. Tiesel"?
Original (both documents):
P. Tiesel
...
Philipp S. Tiesel -->
<author initials="T." surname="Pauly" fullname="Tommy Pauly"> <author initials="T." surname="Pauly" fullname="Tommy Pauly">
<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>
<date year="2024" month="March" day="17"/> <date year="2024" month="November"/>
<workgroup>TAPS Working Group</workgroup> <area>WIT</area>
<keyword>Internet-Draft</keyword> <workgroup>taps</workgroup>
<abstract>
<?line 117?>
<t>This document describes an abstract application programming interface, API, t <!-- [rfced] Please insert any keywords (beyond those that appear in
o the transport the title) for use on https://www.rfc-editor.org/search.
-->
<keyword>example</keyword>
<abstract>
<t>This document describes an abstract Application Programming Interface (API) t
o the transport
layer that enables the selection of transport protocols and layer that enables the selection of transport protocols and
network paths dynamically at runtime. This API enables faster deployment network paths dynamically at runtime. This API enables faster deployment
of new protocols and protocol features without requiring changes to the of new protocols and protocol features without requiring changes to the
applications. The specified API follows the Transport Services architecture applications. The specified API follows the Transport Services architecture
by providing asynchronous, atomic transmission of messages. It is intended to re place the by providing asynchronous, atomic transmission of messages. It is intended to re place the
BSD sockets API as the common interface to the BSD Socket API as the common interface to the
transport layer, in an environment where endpoints could select from transport layer, in an environment where endpoints could select from
multiple network paths and potential transport protocols.</t> multiple network paths and potential transport protocols.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 129?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>This document specifies an abstract application programming interface ( API) that describes the interface component of <t>This document specifies an abstract Application Programming Interface ( API) that describes the interface component of
the high-level Transport Services architecture defined in the high-level Transport Services architecture defined in
<xref target="I-D.ietf-taps-arch"/>. A Transport Services system supports <xref target="RFC9621"/>. A Transport Services system supports
asynchronous, atomic transmission of messages over transport protocols and asynchronous, atomic transmission of messages over transport protocols and
network paths dynamically selected at runtime, in environments where an endpoint network paths dynamically selected at runtime, in environments where an endpoint
selects from multiple network paths and potential transport protocols.</t> selects from multiple network paths and potential transport protocols.</t>
<t>Applications that adopt this API will benefit from a wide set of <t>Applications that adopt this API will benefit from a wide set of
transport features that can evolve over time. This protocol-independent API ensu res that the system transport features that can evolve over time. This protocol-independent API ensu res that the system
providing the API can optimize its behavior based on the application providing the API can optimize its behavior based on the application
requirements and network conditions, without requiring changes to the requirements and network conditions, without requiring changes to the
applications. This flexibility enables faster deployment of new features and applications. This flexibility enables faster deployment of new features and
protocols, and can support applications by offering racing and fallback protocols and can support applications by offering racing and fallback
mechanisms, which otherwise need to be separately implemented in each applicatio n. mechanisms, which otherwise need to be separately implemented in each applicatio n.
Transport Services Implementations are free to take any desired form as long Transport Services Implementations are free to take any desired form as long
as the API specification in this document is honored; a nonprescriptive guide to as the API specification in this document is honored; a non-prescriptive guide t
implementing a Transport Services system is available <xref target="I-D.ietf-tap o
s-impl"/>.</t> implementing a Transport Services system is available (see <xref target="RFC9623
<t>The Transport Services system derives specific path and protocol select "/>).</t>
ion <t>The Transport Services system derives specific path and Protocol Select
properties and supported transport features from the analysis provided in ion
Properties and supported transport features from the analysis provided in
<xref target="RFC8095"/>, <xref target="RFC8923"/>, and <xref target="RFC8095"/>, <xref target="RFC8923"/>, and
<xref target="RFC8922"/>. The Transport Services API enables an implementation <xref target="RFC8922"/>. The Transport Services API enables an implementation
to dynamically choose a transport protocol rather to dynamically choose a transport protocol rather
than statically binding applications to a protocol at than statically binding applications to a protocol at
compile time. The Transport Services API also provides compile time. The Transport Services API also provides
applications with a way to override transport selection and instantiate a specif ic stack, applications with a way to override transport selection and instantiate a specif ic stack,
e.g., to support servers wishing to listen to a specific protocol. However, forc ing a e.g., to support servers wishing to listen to a specific protocol. However, forc ing a
choice to use a specific transport stack is discouraged for general use, because it can reduce portability.</t> choice to use a specific transport stack is discouraged for general use because it can reduce portability.</t>
<section anchor="notation"> <section anchor="notation">
<name>Terminology and Notation</name> <name>Terminology and Notation</name>
<t>The Transport Services API is described in terms of</t> <t>The Transport Services API is described in terms of:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Objects with which an application can interact;</t> <t>Objects with which an application can interact;</t>
</li> </li>
<li> <li>
<t>Actions the application can perform on these objects;</t> <t>Actions the application can perform on these objects;</t>
</li> </li>
<li> <li>
<t>Events, which an object can send to an application to be processe d asynchronously; and</t> <t>Events, which an object can send to an application to be processe d asynchronously; and</t>
</li> </li>
<li> <li>
<t>Parameters associated with these actions and events.</t> <t>Parameters associated with these actions and events.</t>
</li> </li>
</ul> </ul>
<t>The following notations, which can be combined, are used in this docu ment:</t> <t>The following notations, which can be combined, are used in this docu ment:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>
<t>An action that creates an object:</t> <li><t>An action that creates an object:</t></li>
</li>
</ul> </ul>
<artwork><![CDATA[ <artwork><![CDATA[
Object := Action() Object := Action()
]]></artwork> ]]></artwork>
<ul spacing="normal"> <ul spacing="normal">
<li> <li><t>An action that creates an array of objects:</t></li>
<t>An action that creates an array of objects:</t> </ul>
</li>
</ul>
<artwork><![CDATA[ <artwork><![CDATA[
[]Object := Action() []Object := Action()
]]></artwork> ]]></artwork>
<ul spacing="normal"> <ul spacing="normal">
<li> <li><t>An action that is performed on an object:</t></li>
<t>An action that is performed on an object:</t> </ul>
</li>
</ul>
<artwork><![CDATA[ <artwork><![CDATA[
Object.Action() Object.Action()
]]></artwork> ]]></artwork>
<ul spacing="normal"> <ul spacing="normal">
<li> <li><t>An object sends an event:</t></li>
<t>An object sends an event:</t> </ul>
</li>
</ul>
<artwork><![CDATA[ <artwork><![CDATA[
Object -> Event<> Object -> Event<>
]]></artwork> ]]></artwork>
<ul spacing="normal"> <ul spacing="normal">
<li> <li><t>An action takes a set of parameters; an event contains a set
<t>An action takes a set of Parameters; an event contains a set of P of parameters.
arameters. Action and event parameters whose names are suffixed with a question mark are op
action and event parameters whose names are suffixed with a question mark are op tional:</t></li>
tional.</t> </ul>
</li>
</ul> <artwork><![CDATA[
<artwork><![CDATA[
Action(param0, param1?, ...) Action(param0, param1?, ...)
Event<param0, param1?, ...> Event<param0, param1?, ...>
]]></artwork> ]]></artwork>
<!--[rfced] Could this text be reworded as follows?
Original:
Actions associated with no object are actions on the API;...
Perhaps:
Actions not associated with an object are actions on the API;..
-->
<t>Objects that are passed as parameters to actions use call-by-value be havior. <t>Objects that are passed as parameters to actions use call-by-value be havior.
Actions associated with no object are actions on the API; they are equivalent to actions on a per-application global context.</t> Actions associated with no object are actions on the API; they are equivalent to actions on a per-application global context.</t>
<t>Events are sent to the application or application-supplied code (e.g. <t>Events are sent to the application or application-supplied code (e.g.
framers, , framers;
see <xref target="framing"/>) for processing; the details of event interfaces ar see <xref target="framing"/>) for processing; the details of event interfaces ar
e platform- e specific to the platform or
and implementation-specific, and can be implemented using implementation and can be implemented using
other forms of asynchronous processing, as idiomatic for the other forms of asynchronous processing, as idiomatic for the
implementing platform.</t> implementing platform.</t>
<t>We also make use of the following basic types:</t> <t>We also make use of the following basic types:</t>
<ul spacing="normal"> <dl spacing="normal">
<li>
<t>Boolean: Instances take the value <tt>true</tt> or <tt>false</tt> <dt>Boolean:</dt><dd> Instances take the value <tt>true</tt> or <tt>
.</t> false</tt>.</dd>
</li>
<li> <dt>Integer:</dt><dd> Instances take integer values.</dd>
<t>Integer: Instances take integer values.</t>
</li> <dt>Numeric:</dt><dd> Instances take real number values.</dd>
<li>
<t>Numeric: Instances take real number values.</t> <dt>String:</dt><dd> Instances are represented in UTF-8.</dd>
</li>
<li> <dt>IP Address:</dt><dd> An IPv4 address <xref target="RFC791"/> or
<t>String: Instances are represented in UTF-8.</t> IPv6 address <xref target="RFC4291"/>.</dd>
</li>
<li> <dt>Enumeration:</dt><dd> A family of types in which each instance t
<t>IP Address: An IPv4 <xref target="RFC791"/> or IPv6 <xref target= akes one of a fixed,
"RFC4291"/> address.</t> predefined set of values specific to a given enumerated type.</dd>
</li>
<li> <dt>Tuple:</dt><dd> An ordered grouping of multiple value types, rep
<t>Enumeration: A family of types in which each instance takes one o resented as a
f a fixed,
predefined set of values specific to a given enumerated type.</t>
</li>
<li>
<t>Tuple: An ordered grouping of multiple value types, represented a
s a
comma-separated list in parentheses, e.g., <tt>(Enumeration, Preference)</tt>. comma-separated list in parentheses, e.g., <tt>(Enumeration, Preference)</tt>.
Instances take a sequence of values each valid for the corresponding value Instances take a sequence of values, each valid for the corresponding value
type.</t> type.</dd>
</li>
<li> <dt>Array:</dt><dd> Denoted <tt>[]Type</tt>, an instance takes a val
<t>Array: Denoted <tt>[]Type</tt>, an instance takes a value for eac ue for each of zero or more
h of zero or more
elements in a sequence of the given Type. An array can be of fixed or elements in a sequence of the given Type. An array can be of fixed or
variable length.</t> variable length.</dd>
</li>
<li> <dt>Set:</dt><dd> An unordered grouping of one or more different val
<t>Set: An unordered grouping of one or more different values of the ues of the same type.</dd>
same type.</t>
</li> </dl>
</ul>
<t>For guidance on how these abstract concepts can be implemented in lan guages <t>For guidance on how these abstract concepts can be implemented in lan guages
in accordance with language-specific design patterns and platform features, in accordance with language-specific design patterns and platform features,
see <xref target="implmapping"/>.</t> see <xref target="implmapping"/>.</t>
</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", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> < "<bcp14>SHOULD NOT</bcp14>",
xref target="RFC8174"/> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<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> </section>
<section anchor="principles"> <section anchor="principles">
<name>Overview of the API Design</name> <name>Overview of the API Design</name>
<t>The design of the API specified in this document is based on a set of <t>The design of the API specified in this document is based on a set of
principles, themselves an elaboration on the architectural design principles principles, themselves an elaboration on the architectural design principles
defined in <xref target="I-D.ietf-taps-arch"/>. The API defined in this document defined in <xref target="RFC9621"/>. The API defined in this document
provides:</t> provides:</t>
<ul spacing="normal"> <ul spacing="normal">
<!--[rfced] Please review the use of "written to"; should this be
"written for"?
Original:
This enables applications written to a single API to make use of
transport protocols in terms of the features they provide.
Perhaps:
This enables applications written for a single API to make use of
transport protocols in terms of the features they provide.
-->
<li> <li>
<t>A Transport Services system that <t>A Transport Services system that
can offer a variety of transport protocols, independent can offer a variety of transport protocols, independent
of the Protocol Stacks that will be used at of the Protocol Stacks that will be used at
runtime. To the degree possible, all common features of these protocol runtime. To the degree possible, all common features of these Protocol
stacks are made available to the application in a Stacks are made available to the application in a
transport-independent way. transport-independent way.
This enables applications written to a single API This enables applications written to a single API
to make use of transport protocols in terms of the features to make use of transport protocols in terms of the features
they provide.</t> they provide.</t>
</li> </li>
<li> <li>
<t>A unified API to datagram and stream-oriented transports, allowing <t>A unified API to datagram and stream-oriented transports, allowing
use of a common API for Connection establishment and closing.</t> the use of a common API for Connection establishment and closing.</t>
</li> </li>
<li> <li>
<t>Message-orientation, as opposed to stream-orientation, using <t>Message orientation, as opposed to stream orientation, using
application-assisted framing and deframing where the underlying transport application-assisted framing and deframing where the underlying transport
does not provide these.</t> does not provide these.
<!-- [rfced] Section 2: To what does "these" refer in this sentence
(framing and deframing)?
Original:
* Message-orientation, as opposed to stream-orientation, using
application-assisted framing and deframing where the underlying
transport does not provide these. -->
</t>
</li> </li>
<li> <li>
<t>Asynchronous Connection establishment, transmission, and reception. <t>Asynchronous Connection establishment, transmission, and reception.
This allows concurrent operations during establishment and event-driven This allows concurrent operations during establishment and event-driven
application interactions with the transport layer.</t> application interactions with the transport layer.</t>
</li> </li>
<li> <li>
<t>Selection between alternate network paths, using additional informa tion about the <t>Selection between alternate network paths, using additional informa tion about the
networks over which a Connection can operate (e.g. Provisioning Domain (PvD) networks over which a Connection can operate (e.g., Provisioning Domain (PvD)
information <xref target="RFC7556"/>) where available.</t> information <xref target="RFC7556"/>) where available.</t>
</li> </li>
<li> <li>
<t>Explicit support for transport-specific features to be applied, whe n that <t>Explicit support for transport-specific features to be applied, whe n that
particular transport is part of a chosen Protocol Stack.</t> particular transport is part of a chosen Protocol Stack.</t>
</li> </li>
<li> <li>
<t>Explicit support for security properties as first-order transport f eatures.</t> <t>Explicit support for security properties as first-order transport f eatures.</t>
</li> </li>
<li> <li>
skipping to change at line 331 skipping to change at line 400
</ul> </ul>
</section> </section>
<section anchor="api-summary"> <section anchor="api-summary">
<name>API Summary</name> <name>API Summary</name>
<t>An application primarily interacts with this API through two objects: <t>An application primarily interacts with this API through two objects:
Preconnections and Connections. A Preconnection object (<xref target="pre-establ ishment"/>) Preconnections and Connections. A Preconnection object (<xref target="pre-establ ishment"/>)
represents a set of properties and constraints on the selection and configuratio n of represents a set of properties and constraints on the selection and configuratio n of
paths and protocols to establish a Connection with an Endpoint. A Connection obj ect paths and protocols to establish a Connection with an Endpoint. A Connection obj ect
represents an instance of a transport Protocol Stack on which data can be sent t o and/or represents an instance of a transport Protocol Stack on which data can be sent t o and/or
received from a Remote Endpoint (i.e., a logical connection that, depending on t he received from a Remote Endpoint (i.e., a logical connection that, depending on t he
kind of transport, can be bi-directional or unidirectional, and that can use a s tream kind of transport, can be bidirectional or unidirectional, and that can use a st ream
protocol or a datagram protocol). Connections are presented consistently to the protocol or a datagram protocol). Connections are presented consistently to the
application, irrespective of whether the underlying transport is connection-less application, irrespective of whether the underlying transport is connectionless
or or
connection-oriented. Connections can be created from Preconnections in three way connection oriented. Connections can be created from Preconnections in three way
s:</t> s:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>by initiating the Preconnection (i.e., creating a Connection from t he Preconnection, actively opening, as in a client; see Initiate() in <xref targ et="initiate"/>),</t> <t>initiating the Preconnection (i.e., creating a Connection from the Preconnection, actively opening, as in a client; see Initiate() in <xref target= "initiate"/>),</t>
</li> </li>
<li> <li>
<t>by listening on the Preconnection (i.e., creating a Listener based on the Preconnection, passively opening, as in a server; see Listen() in <xref t arget="listen"/>),</t> <t>listening on the Preconnection (i.e., creating a Listener based on the Preconnection, passively opening, as in a server; see Listen() in <xref targ et="listen"/>), or</t>
</li> </li>
<li> <li>
<t>or by a rendezvous for the Preconnection (i.e., peer to peer establ ishment; see Rendezvous() in <xref target="rendezvous"/>).</t> <t>a rendezvous for the Preconnection (i.e., peer-to-peer connection e stablishment; see Rendezvous() in <xref target="rendezvous"/>).</t>
</li> </li>
</ul> </ul>
<t>Once a Connection is established, data can be sent and received on it i n the form of <t>Once a Connection is established, data can be sent and received on it i n the form of
Messages. The API supports the preservation of message boundaries both Messages. The API supports the preservation of message boundaries via both
via explicit Protocol Stack support, and via application support through a explicit Protocol Stack support and application support through a
Message Framer that finds message boundaries in a stream. Messages are Message Framer that finds message boundaries in a stream. Messages are
received asynchronously through event handlers registered by the application. received asynchronously through event handlers registered by the application.
Errors and other notifications also happen asynchronously on the Connection. Errors and other notifications also happen asynchronously on the Connection.
It is not necessary for an application to handle all events; some events can It is not necessary for an application to handle all events; some events can
have implementation-specific default handlers.</t> have implementation-specific default handlers.</t>
<t>The application SHOULD NOT <t>The application <bcp14>SHOULD NOT</bcp14>
assume that ignoring events (e.g., errors) is always safe.</t> assume that ignoring events (e.g., errors) is always safe.</t>
<section anchor="usage-examples"> <section anchor="usage-examples">
<name>Usage Examples</name> <name>Usage Examples</name>
<t>The following usage examples illustrate how an application might use the <t>The following usage examples illustrate how an application might use the
Transport Services API to:</t> Transport Services API to act as:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Act as a server, by listening for incoming Connections, receiving <t>a server, by listening for incoming Connections, receiving reques
requests, ts,
and sending responses, see <xref target="server-example"/>.</t> and sending responses; see <xref target="server-example"/>.</t>
</li> </li>
<li> <li>
<t>Act as a client, by connecting to a Remote Endpoint using <tt>Ini <t>a client, by connecting to a Remote Endpoint using <tt>Initiate</
tiate</tt>, sending tt>, sending
requests, and receiving responses, see <xref target="client-example"/>.</t> requests, and receiving responses; see <xref target="client-example"/>.</t>
</li> </li>
<li> <li>
<t>Act as a peer, by connecting to a Remote Endpoint using Rendezvou s while <t>a peer, by connecting to a Remote Endpoint using Rendezvous while
simultaneously waiting for incoming Connections, sending Messages, and simultaneously waiting for incoming Connections, sending Messages, and
receiving Messages, see <xref target="peer-example"/>.</t> receiving Messages; see <xref target="peer-example"/>.</t>
</li> </li>
</ul> </ul>
<t>The examples in this section presume that a transport protocol is ava ilable <t>The examples in this section presume that a transport protocol is ava ilable
between the Local and Remote Endpoints that provides Reliable Data Transfer, Pre between the Local and Remote Endpoints and that this protocol provides reliable
servation of data transfer, preservation of
Data Ordering, and Preservation of Message Boundaries. In this case, the data ordering, and preservation of message boundaries. In this case, the
application can choose to receive only complete Messages.</t> application can choose to receive only complete Messages.</t>
<t>If none of the available transport protocols provides Preservation of <t>If none of the available transport protocols provide preservation of
Message message
Boundaries, but there is a transport protocol that provides a reliable ordered boundaries, but there is a transport protocol that provides a reliable ordered
byte-stream, an application could receive this byte-stream as partial byte-stream, an application could receive this byte-stream as partial
Messages and transform it into application-layer Messages. Alternatively, Messages and transform it into application-layer Messages. Alternatively,
an application might provide a Message Framer, which can transform a an application might provide a Message Framer, which can transform a
sequence of Messages into a byte-stream and vice versa (<xref target="framing"/> ).</t> sequence of Messages into a byte-stream and vice versa (<xref target="framing"/> ).</t>
<section anchor="server-example"> <section anchor="server-example">
<name>Server Example</name> <name>Server Example</name>
<t>This is an example of how an application might listen for incoming Connections <t>This is an example of how an application might listen for incoming Connections
using the Transport Services API, receive a request, and send a response.</t> using the Transport Services API, receive a request, and send a response.</t>
<artwork><![CDATA[ <artwork><![CDATA[
LocalSpecifier := NewLocalEndpoint() LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithInterface("any") LocalSpecifier.WithInterface("any")
LocalSpecifier.WithService("https") LocalSpecifier.WithService("https")
TransportProperties := NewTransportProperties() TransportProperties := NewTransportProperties()
TransportProperties.Require(preserveMsgBoundaries) TransportProperties.Require(preserveMsgBoundaries)
// Reliable Data Transfer and Preserve Order are Required by default // Reliable data transfer and preserve order are required by default
SecurityParameters := NewSecurityParameters() SecurityParameters := NewSecurityParameters()
SecurityParameters.Set(serverCertificate, myCertificate) SecurityParameters.Set(serverCertificate, myCertificate)
// Specifying a Remote Endpoint is optional when using Listen // Specifying a Remote Endpoint is optional when using Listen
Preconnection := NewPreconnection(LocalSpecifier, Preconnection := NewPreconnection(LocalSpecifier,
TransportProperties, TransportProperties,
SecurityParameters) SecurityParameters)
Listener := Preconnection.Listen() Listener := Preconnection.Listen()
skipping to change at line 423 skipping to change at line 492
Connection -> Received<messageDataRequest, messageContext> Connection -> Received<messageDataRequest, messageContext>
//---- Receive event handler begin ---- //---- Receive event handler begin ----
Connection.Send(messageDataResponse) Connection.Send(messageDataResponse)
Connection.Close() Connection.Close()
// Stop listening for incoming Connections // Stop listening for incoming Connections
// (this example supports only one Connection) // (this example supports only one Connection)
Listener.Stop() Listener.Stop()
//---- Receive event handler end ---- //---- Receive event handler end ----
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="client-example"> <section anchor="client-example">
<name>Client Example</name> <name>Client Example</name>
<!--[rfced] Could this sentence be rephrased as follows?
Original:
This is an example of how an application might open two Connections
to a remote application using the Transport Services API, and send
a request as well as receive a response on each of them.
Perhaps:
This is an example of how an application might open two Connections
to a remote application using the Transport Services API, send a
request, and receive a response for each of the two Connections.
-->
<t>This is an example of how an application might open two Connections to a remote application <t>This is an example of how an application might open two Connections to a remote application
using the Transport Services API, and send a request as well as receive a respon using the Transport Services API and send a request as well as receive a respons
se on each of them. e on each of them.
The code designated with comments as "Ready event handler" could, e.g., be imple The code designated with comments as "Ready event handler" could, for example, b
mented e implemented
as a callback function, for example. This function would receive the Connection as a callback function. This function would receive the Connection that it expec
that it expects ts
to operate on ("Connection" and "Connection2" in the example), handed over using to operate on ("Connection" and "Connection2" in the example) handed over using
the variable the variable
name "C".</t> name "C".</t>
<artwork><![CDATA[ <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithHostName("example.com") RemoteSpecifier.WithHostName("example.com")
RemoteSpecifier.WithService("https") RemoteSpecifier.WithService("https")
TransportProperties := NewTransportProperties() TransportProperties := NewTransportProperties()
TransportProperties.Require(preserve-msg-boundaries) TransportProperties.Require(preserve-msg-boundaries)
// Reliable Data Transfer and Preserve Order are Required by default // Reliable data transfer and preserve order are required by default
SecurityParameters := NewSecurityParameters() SecurityParameters := NewSecurityParameters()
TrustCallback := NewCallback({ TrustCallback := NewCallback({
// Verify identity of the Remote Endpoint, return the result // Verify the identity of the Remote Endpoint and return the result
}) })
SecurityParameters.SetTrustVerificationCallback(TrustCallback) SecurityParameters.SetTrustVerificationCallback(TrustCallback)
// Specifying a Local Endpoint is optional when using Initiate // Specifying a Local Endpoint is optional when using Initiate
Preconnection := NewPreconnection(RemoteSpecifier, Preconnection := NewPreconnection(RemoteSpecifier,
TransportProperties, TransportProperties,
SecurityParameters) SecurityParameters)
Connection := Preconnection.Initiate() Connection := Preconnection.Initiate()
Connection2 := Connection.Clone() Connection2 := Connection.Clone()
skipping to change at line 475 skipping to change at line 557
//---- Ready event handler for any Connection C end ---- //---- Ready event handler for any Connection C end ----
Connection -> Received<messageDataResponse, messageContext> Connection -> Received<messageDataResponse, messageContext>
Connection2 -> Received<messageDataResponse, messageContext> Connection2 -> Received<messageDataResponse, messageContext>
// Close the Connection in a Receive event handler // Close the Connection in a Receive event handler
Connection.Close() Connection.Close()
Connection2.Close() Connection2.Close()
]]></artwork> ]]></artwork>
<t>A Preconnection serves as a template for creating a Connection via initiating, listening, or via rendezvous. Once a Connection has been created, <t>A Preconnection serves as a template for creating a Connection via initiating, listening, or via rendezvous. Once a Connection has been created,
changes made to the Preconnection that was used to create it do not affect this Connection. Preconnections are reusable after being used to create a Connection, whether this Connection was closed or not. Hence, in the above example, it woul d be correct for the client to initiate a third Connection to the example.com se rver by continuing as follows:</t> changes made to the Preconnection that was used to create it do not affect this Connection. Preconnections are reusable after being used to create a Connection, whether or not this Connection was closed. Hence, in the above example, it woul d be correct for the client to initiate a third Connection to the example.com se rver by continuing as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
//.. carry out adjustments to the Preconnection, if desired //.. carry out adjustments to the Preconnection, if desired
Connection3 := Preconnection.Initiate() Connection3 := Preconnection.Initiate()
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="peer-example"> <section anchor="peer-example">
<name>Peer Example</name> <name>Peer Example</name>
<t>This is an example of how an application might establish a Connecti on with a <t>This is an example of how an application might establish a Connecti on with a
peer using <tt>Rendezvous</tt>, send a Message, and receive a Message.</t> peer using <tt>Rendezvous</tt>, send a Message, and receive a Message.</t>
<artwork><![CDATA[ <artwork><![CDATA[
// Configure local candidates: a port on the Local Endpoint // Configure local candidates: a port on the Local Endpoint
// and via a STUN server // and via a Session Traversal Utilities for NAT (STUN) server
HostCandidate := NewLocalEndpoint() HostCandidate := NewLocalEndpoint()
HostCandidate.WithPort(9876) HostCandidate.WithPort(9876)
StunCandidate := NewLocalEndpoint() StunCandidate := NewLocalEndpoint()
StunCandidate.WithStunServer(address, port, credentials) StunCandidate.WithStunServer(address, port, credentials)
LocalCandidates = [HostCandidate, StunCandidate] LocalCandidates = [HostCandidate, StunCandidate]
TransportProperties := // ...Configure transport properties TransportProperties := // ...Configure transport properties
SecurityParameters := // ...Configure security properties SecurityParameters := // ...Configure security properties
Preconnection := NewPreconnection(LocalCandidates, Preconnection := NewPreconnection(LocalCandidates,
[], // No remote candidates yet [], // No remote candidates yet
TransportProperties, TransportProperties,
SecurityParameters) SecurityParameters)
// Resolve the LocalCandidates. The Preconnection.Resolve() // Resolve the LocalCandidates. The Preconnection.Resolve()
// call resolves both local and remote candidates but, since // call resolves both local and remote candidates; however,
// the remote candidates have not yet been specified, the // because the remote candidates have not yet been specified,
// ResolvedRemote list returned will be empty and is not // the ResolvedRemote list returned will be empty and is not
// used. // used.
ResolvedLocal, ResolvedRemote = Preconnection.Resolve() ResolvedLocal, ResolvedRemote = Preconnection.Resolve()
// Application-specific code goes here to send the ResolvedLocal // Application-specific code goes here to send the ResolvedLocal
// list to peer via some out-of-band signalling channel (e.g., // list to the peer via some out-of-band signaling channel (e.g.,
// in a SIP message) // in a SIP message).
... ...
// Application-specific code goes here to receive RemoteCandidates // Application-specific code goes here to receive RemoteCandidates
// (type []RemoteEndpoint, a list of RemoteEndpoint objects) from // (type []RemoteEndpoint, a list of RemoteEndpoint objects) from
// the peer via the signalling channel // the peer via the signaling channel.
... ...
// Add remote candidates and initiate the rendezvous: // Add remote candidates and initiate the rendezvous:
Preconnection.AddRemote(RemoteCandidates) Preconnection.AddRemote(RemoteCandidates)
Preconnection.Rendezvous() Preconnection.Rendezvous()
Preconnection -> RendezvousDone<Connection> Preconnection -> RendezvousDone<Connection>
//---- RendezvousDone event handler begin ---- //---- RendezvousDone event handler begin ----
Connection.Send(messageDataRequest) Connection.Send(messageDataRequest)
Connection.Receive() Connection.Receive()
//---- RendezvousDone event handler end ---- //---- RendezvousDone event handler end ----
Connection -> Received<messageDataResponse, messageContext> Connection -> Received<messageDataResponse, messageContext>
// If new Remote Endpoint candidates are received from the // If new Remote Endpoint candidates are received from the
// peer over the signalling channel, for example if using // peer over the signaling channel -- for example, if using
// Trickle ICE, then add them to the Connection: // Trickle Interactive Connectivity Establishment (ICE) --
// then add them to the Connection:
Connection.AddRemote(NewRemoteCandidates) Connection.AddRemote(NewRemoteCandidates)
// On a PathChange<> event, resolve the Local Endpoint Identifiers to // On a PathChange<> event, resolve the Local Endpoint Identifiers to
// see if a new Local Endpoint has become available and, if // see if a new Local Endpoint has become available and, if
// so, send to the peer as a new candidate and add to the // so, send to the peer as a new candidate and add to the
// Connection: // Connection:
Connection -> PathChange<> Connection -> PathChange<>
//---- PathChange event handler begin ---- //---- PathChange event handler begin ----
ResolvedLocal, ResolvedRemote = Preconnection.Resolve() ResolvedLocal, ResolvedRemote = Preconnection.Resolve()
if ResolvedLocal has changed: if ResolvedLocal has changed:
// Application-specific code goes here to send the // Application-specific code goes here to send the
// ResolvedLocal list to peer via signalling channel // ResolvedLocal list to the peer via the signaling channel
... ...
// Add the new Local Endpoints to the Connection: // Add the new Local Endpoints to the Connection:
Connection.AddLocal(ResolvedLocal) Connection.AddLocal(ResolvedLocal)
//---- PathChange event handler end ---- //---- PathChange event handler end ----
// Close the Connection in a Receive event handler // Close the Connection in a Receive event handler:
Connection.Close() Connection.Close()
]]></artwork> ]]></artwork>
<!-- [rfced] Section 3.1.3: Should "if ResolvedLocal has changed:" be
set off as a comment?
Original:
if ResolvedLocal has changed:
Possibly:
// If ResolvedLocal has changed: -->
</section> </section>
</section> </section>
</section> </section>
<section anchor="transport-properties"> <section anchor="transport-properties">
<name>Transport Properties</name> <name>Transport Properties</name>
<t>Each application using the Transport Services API declares its preferen ces <t>Each application using the Transport Services API declares its preferen ces
for how the Transport Services system is to operate. This is done by using for how the Transport Services system is to operate. This is done by using
Transport Properties, as defined in <xref target="I-D.ietf-taps-arch"/>, at each stage Transport Properties, as defined in <xref target="RFC9621"/>, at each stage
of the lifetime of a Connection.</t> of the lifetime of a Connection.</t>
<t>Transport Properties are divided into Selection, Connection, and Messag e <t>Transport Properties are divided into Selection, Connection, and Messag e
Properties.</t> Properties.</t>
<t>Selection Properties (see <xref target="selection-props"/>) can only be set <t>Selection Properties (see <xref target="selection-props"/>) can only be set
during pre-establishment. They are only used to specify which paths and during preestablishment. They are only used to specify which paths and
Protocol Stacks can be used and are preferred by the application. Protocol Stacks can be used and are preferred by the application.
Calling <tt>Initiate</tt> on a Preconnection creates an outbound Connection, Calling <tt>Initiate</tt> on a Preconnection creates an outbound Connection,
and the Selection Properties remain readable from the and the Selection Properties remain readable from the
Connection, but become immutable. Selection Properties Connection but become immutable. Selection Properties
can be set on Preconnections, and the effect of Selection Properties can be set on Preconnections, and the effect of Selection Properties
can be queried on Connections and Messages.</t> can be queried on Connections and Messages.</t>
<t>Connection Properties (see <xref target="connection-props"/>) are used to inform <t>Connection Properties (see <xref target="connection-props"/>) are used to inform
decisions made during establishment and to fine-tune the established decisions made during establishment and to fine-tune the established
Connection. They can be set during pre-establishment, and can be Connection. They can be set during preestablishment and can be
changed later. Connection Properties can be set on Connections and changed later. Connection Properties can be set on Connections and
Preconnections; when set on Preconnections, they act as an initial Preconnections; when set on Preconnections, they act as an initial
default for the resulting Connections.</t> default for the resulting Connections.</t>
<t>Message Properties (see <xref target="message-props"/>) control the beh avior of the <t>Message Properties (see <xref target="message-props"/>) control the beh avior of the
selected protocol stack(s) when sending Messages. Message Properties selected Protocol Stack(s) when sending Messages. Message Properties
can be set on Messages, Connections, and Preconnections; when set on can be set on Messages, Connections, and Preconnections; when set on
the latter two, they act as an initial default for the Messages sent the latter two, they act as an initial default for the Messages sent
over those Connections.</t> over those Connections.</t>
<t>Note that configuring Connection Properties and Message Properties on <t>Note that configuring Connection Properties and Message Properties on
Preconnections is preferred over setting them later. Early specification of Preconnections is preferred over setting them later. Early specification of
Connection Properties allows their use as additional input to the selection Connection Properties allows their use as additional input to the selection
process. Protocol-specific Properties, which enable configuration of specialized process. Protocol-specific Properties, which enable configuration of specialized
features of a specific protocol (see <xref section="3.2" sectionFormat="of" targ features of a specific protocol (see <xref section="3.2" sectionFormat="of" targ
et="I-D.ietf-taps-arch"/>) are not et="RFC9621"/>), are not
used as an input to the selection process, but only support configuration if used as input to the selection process; they only support configuration if
the respective protocol has been selected.</t> the respective protocol has been selected.</t>
<section anchor="property-names"> <section anchor="property-names">
<name>Transport Property Names</name> <name>Transport Property Names</name>
<t>Transport Properties are referred to by property names, represented a s case-insensitive strings. These names serve two purposes:</t> <t>Transport Properties are referred to by property names, represented a s case-insensitive strings. These names serve two purposes:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Allowing different components of a Transport Services Implementat ion to pass Transport <t>Allowing different components of a Transport Services Implementat ion to pass Transport
Properties, e.g., between a language frontend and a policy manager, Properties, e.g., between a language front end and a policy manager
or as a representation of properties retrieved from a file or other storage.</t> or as a representation of properties retrieved from a file or other storage.</t>
</li> </li>
<li> <li>
<t>Making the code of different Transport Services Implementations l ook similar. <t>Making the code of different Transport Services Implementations l ook similar.
While individual programming languages might preclude strict adherence to the While individual programming languages might preclude strict adherence to the
aforementioned naming convention (for instance, by prohibiting the use of hyphen s aforementioned naming convention (for instance, by prohibiting the use of hyphen s
in symbols), users interacting with multiple implementations will still benefit in symbols), users interacting with multiple implementations will still benefit
from the consistency resulting from the use of visually similar symbols.</t> from the consistency resulting from the use of visually similar symbols.</t>
</li> </li>
<!-- [rfced] Section 4.1: We had trouble following the text in this
bullet list. In the first bullet, what does "as a
representation" refer to? In the second bullet, what does "the
aforementioned naming convention" refer to?
Original:
* Allowing different components of a Transport Services
Implementation to pass Transport Properties, e.g., between a
language frontend and a policy manager, or as a representation of
properties retrieved from a file or other storage.
* Making the code of different Transport Services Implementations
look similar. While individual programming languages might
preclude strict adherence to the aforementioned naming convention
(for instance, by prohibiting the use of hyphens in symbols),
users interacting with multiple implementations will still benefit
from the consistency resulting from the use of visually similar
symbols. -->
</ul> </ul>
<t>Transport Property Names are hierarchically organized in the <t>Transport Property Names are hierarchically organized in the
form [&lt;Namespace&gt;.]&lt;PropertyName&gt;.</t> form [&lt;Namespace&gt;.]&lt;PropertyName&gt;.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The optional Namespace component and its trailing character <tt>. <t>The optional Namespace component and its trailing character <tt>.
</tt> MUST be omitted for well-known, </tt> <bcp14>MUST</bcp14> be omitted for well-known,
generic properties, i.e., for properties that are not specific to a protocol.</t generic properties, i.e., for properties that are not specific to a protocol.
>
<!-- [rfced] Section 4.1: May we update this use of the period as
follows (both for the ease of the reader and for consistency with
the RFC series)?
If yes to quoting, may we also change 'underscore _ character' a few
lines later to 'underscore ("_") character'?
Original:
* The optional Namespace component and its trailing character . MUST
be omitted for well-known, generic properties, i.e., for
properties that are not specific to a protocol.
Possibly:
* The optional Namespace component and its trailing dot character (".")
MUST be omitted for well-known, generic properties, i.e., for
properties that are not specific to a protocol. -->
</t>
</li> </li>
<li> <li>
<t>Protocol-specific Properties MUST use the protocol acronym as the <t>Protocol-specific Properties <bcp14>MUST</bcp14> use the protocol
Namespace (e.g., a acronym as the Namespace (e.g., a
Connection that uses TCP could support a TCP-specific Transport Property, such a Connection that uses TCP could support a TCP-specific Transport Property, such a
s the TCP user timeout s the TCP User Timeout
value, in a Protocol-specific Property called <tt>tcp.userTimeoutValue</tt> (see <xref target="tcp-uto"/>)).</t> value, in a Protocol-specific Property called <tt>tcp.userTimeoutValue</tt> (see <xref target="tcp-uto"/>)).</t>
</li> </li>
<li> <li>
<t>Vendor or implementation specific properties MUST be placed in a <t>Vendor-specific or implementation-specific properties <bcp14>MUST
Namespace starting with the underscore <tt>_</tt> character </bcp14> be placed in a Namespace starting with the underscore <tt>_</tt> charac
and SHOULD use a string identifying the vendor or implementation.</t> ter
and <bcp14>SHOULD</bcp14> use a string identifying the vendor or implementation
.</t>
</li> </li>
<li> <li>
<t>For IETF protocols, the name of a Protocol-specific Property MUST
be specified in an IETF document published in the RFC Series after IETF review. <!--[rfced] May we update this text to make it as clear to the reader
as possible? Should further specification about what type of
review the IETF gives be listed (or by whom/what role in the
IETF)? Note also our other query regarding the "underscore
character".
Original:
* For IETF protocols, the name of a Protocol-specific Property MUST
be specified in an IETF document published in the RFC Series after
IETF review. An IETF protocol Namespace does not start with an
underscore character.
Perhaps:
* For IETF protocols, the name of a Protocol-specific Property MUST
be specified in an RFC from the IETF Stream (after
IETF review). An IETF protocol Namespace does not start with an
underscore character.
-->
<t>For IETF protocols, the name of a Protocol-specific Property <bcp
14>MUST</bcp14> be specified in an IETF document published in the RFC Series aft
er IETF review.
An IETF protocol Namespace does not start with an underscore character.</t> An IETF protocol Namespace does not start with an underscore character.</t>
</li> </li>
</ul> </ul>
<t>Namespaces for each of the keywords provided in the IANA protocol num <t>Namespaces for each of the keywords provided in the "Protocol Numbers
bers registry " registry
(see https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml) a (see <eref brackets="angle" target="https://www.iana.org/assignments/protocol-nu
re reserved mbers/"/>) are reserved
for Protocol-specific Properties and MUST NOT be used for vendor or implementati for Protocol-specific Properties and <bcp14>MUST NOT</bcp14> be used for vendor-
on-specific properties. specific or implementation-specific properties.
Terms listed as keywords as in the protocol numbers registry SHOULD be avoided a Terms listed as keywords, as in the "Protocol Numbers" registry, <bcp14>SHOULD</
s any part of a vendor- or bcp14> be avoided as any part of a vendor-specific or
implementation-specific property name.</t> implementation-specific property name.</t>
<t>Though Transport Property Names are case-insensitive, it is recommend ed to use camelCase to improve readability. <t>Though Transport Property Names are case insensitive, it is recommend ed to use camelCase to improve readability.
Implementations may transpose Transport Property Names into snake_case or Pascal Case to blend into the language environment.</t> Implementations may transpose Transport Property Names into snake_case or Pascal Case to blend into the language environment.</t>
</section> </section>
<section anchor="property-types"> <section anchor="property-types">
<name>Transport Property Types</name> <name>Transport Property Types</name>
<t>Each Transport Property has one of the basic types described in <xref target="notation"/>.</t> <t>Each Transport Property has one of the basic types described in <xref target="notation"/>.</t>
<t>Most Selection Properties (see <xref target="selection-props"/>) are of the Enumeration type, <t>Most Selection Properties (see <xref target="selection-props"/>) are of the Enumeration type,
and use the Preference Enumeration, which takes one of five possible values and they use the Preference Enumeration, which takes one of five possible values
(Prohibit, Avoid, No Preference, Prefer, or Require) denoting the level of prefe rence (Prohibit, Avoid, No Preference, Prefer, or Require) denoting the level of prefe rence
for a given property during protocol selection.</t> for a given property during protocol selection.</t>
</section> </section>
</section> </section>
<section anchor="scope-of-interface-defn"> <section anchor="scope-of-interface-defn">
<name>Scope of the API Definition</name> <name>Scope of the API Definition</name>
<t>This document defines a language- and platform-independent API of a <t>This document defines a language- and platform-independent API of a
Transport Services system. Given the wide variety of languages and language Transport Services system. Given the wide variety of languages and language
conventions used to write applications that use the transport layer to connect conventions used to write applications that use the transport layer to connect
to other applications over the Internet, this independence makes this API to other applications over the Internet, this independence makes this API
skipping to change at line 668 skipping to change at line 823
<t>There is no interoperability benefit in tightly defining how the API is <t>There is no interoperability benefit in tightly defining how the API is
presented to application programmers across diverse platforms. However, presented to application programmers across diverse platforms. However,
maintaining the "shape" of the abstract API across different platforms reduces maintaining the "shape" of the abstract API across different platforms reduces
the effort for programmers who learn to use the Transport Services API to then the effort for programmers who learn to use the Transport Services API to then
apply their knowledge to another platform. That said, implementations have apply their knowledge to another platform. That said, implementations have
significant freedom in presenting this API to programmers, balancing the significant freedom in presenting this API to programmers, balancing the
conventions of the protocol with the shape of the API. We make the following conventions of the protocol with the shape of the API. We make the following
recommendations:</t> recommendations:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Actions, events, and errors in implementations of the Transport Ser vices API SHOULD use <t>Actions, events, and errors in implementations of the Transport Ser vices API <bcp14>SHOULD</bcp14> use
the names given for them in the document, subject to capitalization, the names given for them in the document, subject to capitalization,
punctuation, and other typographic conventions in the language of the punctuation, and other typographic conventions in the language of the
implementation, unless the implementation itself uses different names for implementation, unless the implementation itself uses different names for
substantially equivalent objects for networking by convention.</t> substantially equivalent objects for networking by convention.
<!-- [rfced] Section 5: Does "names given for them in the document"
mean "names assigned to them in this document" or something else?
Please clarify.
Original:
* Actions, events, and errors in implementations of the Transport
Services API SHOULD use the names given for them in the document,
subject to capitalization, punctuation, and other typographic
conventions in the language of the implementation, unless the
implementation itself uses different names for substantially
equivalent objects for networking by convention. -->
</t>
</li> </li>
<li> <li>
<t>Transport Services systems SHOULD implement each Selection Property , <t>Transport Services systems <bcp14>SHOULD</bcp14> implement each Sel ection Property,
Connection Property, and Message Context Property specified in this document. Connection Property, and Message Context Property specified in this document.
These features SHOULD be implemented even when in a specific implementation it These features <bcp14>SHOULD</bcp14> be implemented even when, in a specific imp
will always result in no operation, e.g. there is no action when the API lementation, it
will always result in no operation, e.g., there is no action when the API
specifies a Property that is not available in a transport protocol implemented specifies a Property that is not available in a transport protocol implemented
on a specific platform. For example, if TCP is the only underlying transport pro tocol, on a specific platform. For example, if TCP is the only underlying transport pro tocol,
the Message Property <tt>msgOrdered</tt> can be implemented (trivially, as a no- op) as the Message Property <tt>msgOrdered</tt> can be implemented (trivially, as a no- op) as
disabling the requirement for ordering will not have any effect on delivery orde r disabling the requirement for ordering will not have any effect on delivery orde r
for Connections over TCP. Similarly, the <tt>msgLifetime</tt> Message Property c an be for Connections over TCP. Similarly, the <tt>msgLifetime</tt> Message Property c an be
implemented but ignored, as the description of this Property states that "it is not implemented but ignored, as the description of this Property (<xref target="msg- lifetime"/>) states that "it is not
guaranteed that a Message will not be sent when its Lifetime has expired".</t> guaranteed that a Message will not be sent when its Lifetime has expired".</t>
<!-- Above-quoted text is DNE text from Section 9.1.3.1 -->
</li> </li>
<li> <li>
<t>Implementations can use other representations for Transport Propert y Names, <t>Implementations can use other representations for Transport Propert y Names,
e.g., by providing constants, but should provide a straight-forward mapping e.g., by providing constants, but should provide a straightforward mapping
between their representation and the property names specified here.</t> between their representation and the property names specified here.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="pre-establishment"> <section anchor="pre-establishment">
<name>Pre-Establishment Phase</name> <name>Preestablishment Phase</name>
<t>The pre-establishment phase allows applications to specify properties f <t>The preestablishment phase allows applications to specify properties fo
or r
the Connections that they are about to make, or to query the API about potential the Connections that they are about to make or to query the API about potential
Connections they could make.</t> Connections they could make.</t>
<t>A Preconnection object represents a potential Connection. It is a passi ve object <t>A Preconnection object represents a potential Connection. It is a passi ve object
(a data structure) that merely maintains the state that (a data structure) that merely maintains the state that
describes the properties of a Connection that might exist in the future. This s tate describes the properties of a Connection that might exist in the future. This s tate
comprises Local Endpoint and Remote Endpoint objects that denote the endpoints comprises Local Endpoint and Remote Endpoint objects that denote the endpoints
of the potential Connection (see <xref target="endpointspec"/>), the Selection P roperties of the potential Connection (see <xref target="endpointspec"/>), the Selection P roperties
(see <xref target="selection-props"/>), any preconfigured Connection Properties (see <xref target="selection-props"/>), any preconfigured Connection Properties
(<xref target="connection-props"/>), and the security parameters (see (<xref target="connection-props"/>), and the security parameters (see
<xref target="security-parameters"/>):</t> <xref target="security-parameters"/>):</t>
<artwork><![CDATA[ <artwork><![CDATA[
Preconnection := NewPreconnection([]LocalEndpoint, Preconnection := NewPreconnection([]LocalEndpoint,
[]RemoteEndpoint, []RemoteEndpoint,
TransportProperties, TransportProperties,
SecurityParameters) SecurityParameters)
]]></artwork> ]]></artwork>
<t>At least one Local Endpoint MUST be specified if the Preconnection is u <t>At least one Local Endpoint <bcp14>MUST</bcp14> be specified if the Pre
sed to <tt>Listen</tt> connection is used to <tt>Listen</tt>
for incoming Connections, but the list of Local Endpoints MAY be empty if for incoming Connections, but the list of Local Endpoints <bcp14>MAY</bcp14> be
empty if
the Preconnection is used to <tt>Initiate</tt> the Preconnection is used to <tt>Initiate</tt>
connections. If no Local Endpoint is specified, the Transport Services system wi ll connections. If no Local Endpoint is specified, the Transport Services system wi ll
assign an ephemeral local port to the Connection on the appropriate interface(s) . assign an ephemeral local port to the Connection on the appropriate interface(s) .
At least one Remote Endpoint MUST be specified if the Preconnection is used At least one Remote Endpoint <bcp14>MUST</bcp14> be specified if the Preconnecti
to <tt>Initiate</tt> Connections, but the list of Remote Endpoints MAY be empty on is used
if to <tt>Initiate</tt> Connections, but the list of Remote Endpoints <bcp14>MAY</b
cp14> be empty if
the Preconnection is used to <tt>Listen</tt> for incoming Connections. the Preconnection is used to <tt>Listen</tt> for incoming Connections.
At least one Local Endpoint and one Remote Endpoint MUST be specified if a At least one Local Endpoint and one Remote Endpoint <bcp14>MUST</bcp14> be speci fied if a
peer-to-peer <tt>Rendezvous</tt> is to occur based on the Preconnection.</t> peer-to-peer <tt>Rendezvous</tt> is to occur based on the Preconnection.</t>
<t>If more than one Local Endpoint is specified on a Preconnection, then t he application <t>If more than one Local Endpoint is specified on a Preconnection, then t he application
is indicating that all of the Local Endpoints are eligible to be used for Conne ctions. For is indicating that all of the Local Endpoints are eligible to be used for Conne ctions. For
example, their Endpoint Identifiers might correspond to different interfaces on example, their Endpoint Identifiers might correspond to different interfaces on
a multi-homed a multihomed
host, or their Endpoint Identifiers might correspond to local interfaces and a S host or their Endpoint Identifiers might correspond to local interfaces and a ST
TUN server that UN server that
can be resolved to a server reflexive address for a Preconnection used to can be resolved to a server-reflexive address for a Preconnection used to
make a peer-to-peer <tt>Rendezvous</tt>.</t> make a peer-to-peer <tt>Rendezvous</tt>.</t>
<t>If more than one Remote Endpoint is specified on the Preconnection, the <t>If more than one Remote Endpoint is specified on the Preconnection, the
application is indicating that it expects all of the Remote Endpoints to application is indicating that it expects all of the Remote Endpoints to
offer an equivalent service, and that the Transport Services system can choose offer an equivalent service and that the Transport Services system can choose
any of them for a Connection. any of them for a Connection.
For example, a Remote Endpoint might represent various network For example, a Remote Endpoint might represent various network
interfaces of a host, or a server reflexive address that can be used to interfaces of a host, or a server-reflexive address that can be used to
reach a host, or a set of hosts that provide equivalent local balanced reach a host, or a set of hosts that provide equivalent local balanced
service.</t> service.</t>
<t>In most cases, it is expected that a single Remote Endpoint will be <t>In most cases, it is expected that a single Remote Endpoint will be
specified by name, and a later call to <tt>Initiate</tt> on the Preconnection specified by name, and a later call to <tt>Initiate</tt> on the Preconnection
(see <xref target="initiate"/>) will internally resolve that name to a list of c oncrete (see <xref target="initiate"/>) will internally resolve that name to a list of c oncrete
Endpoint Identifers. Specifying multiple Remote Endpoints on a Preconnection all ows Endpoint Identifiers. Specifying multiple Remote Endpoints on a Preconnection al lows
applications to override this for more detailed control.</t> applications to override this for more detailed control.</t>
<t>If Message Framers are used (see <xref target="framing"/>), they MUST b <t>If Message Framers are used (see <xref target="framing"/>), they <bcp14
e added to the >MUST</bcp14> be added to the
Preconnection during pre-establishment.</t> Preconnection during preestablishment.</t>
<section anchor="endpointspec"> <section anchor="endpointspec">
<name>Specifying Endpoints</name> <name>Specifying Endpoints</name>
<t>The Transport Services API uses the Local Endpoint and Remote Endpoin t objects <t>The Transport Services API uses the Local Endpoint and Remote Endpoin t objects
to refer to the endpoints of a Connection. Endpoints can be created to refer to the endpoints of a Connection. Endpoints can be created
as either remote or local:</t> as either remote or local:</t>
<artwork><![CDATA[ <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier := NewRemoteEndpoint()
LocalSpecifier := NewLocalEndpoint() LocalSpecifier := NewLocalEndpoint()
]]></artwork> ]]></artwork>
<t>A single Endpoint object represents the identity of a network host. T hat endpoint <t>A single Endpoint object represents the identity of a network host. T hat endpoint
can be more or less specific depending on which Endpoint Identifiers are set. Fo r example, can be more or less specific, depending on which Endpoint Identifiers are set. F or example,
an Endpoint that only specifies a hostname can, in fact, finally correspond an Endpoint that only specifies a hostname can, in fact, finally correspond
to several different IP addresses on different hosts.</t> to several different IP addresses on different hosts.</t>
<t>An Endpoint object can be configured with the following identifiers:< /t> <t>An Endpoint object can be configured with the following identifiers:< /t>
<ul spacing="normal"> <ul spacing="normal">
<li>
<t>HostName (string):</t> <li><t>HostName (string):</t></li>
</li> </ul>
</ul>
<artwork><![CDATA[ <artwork><![CDATA[
RemoteSpecifier.WithHostName("example.com") RemoteSpecifier.WithHostName("example.com")
]]></artwork> ]]></artwork>
<ul spacing="normal"> <ul spacing="normal">
<li> <li><t>Port (a 16-bit unsigned Integer):</t></li>
<t>Port (a 16-bit unsigned Integer):</t> </ul>
</li>
</ul>
<artwork><![CDATA[ <artwork><![CDATA[
RemoteSpecifier.WithPort(443) RemoteSpecifier.WithPort(443)
]]></artwork> ]]></artwork>
<ul spacing="normal"> <ul spacing="normal">
<li> <li><t>Service (an identifier string that maps to a port; either a s
<t>Service (an identifier string that maps to a port; either a servi ervice
ce name associated with a port number (from <eref brackets="angle"
name associated with a port number, from https://www.iana.org/assignments/servic target="https://www.iana.org/assignments/service-names-port-numbers/"/>) or a DN
e-names-port-numbers/service-names-port-numbers.xhtml, or a DNS SRV service name S SRV service name to be resolved):</t></li>
to be resolved):</t> </ul>
</li>
</ul>
<artwork><![CDATA[ <artwork><![CDATA[
RemoteSpecifier.WithService("https") RemoteSpecifier.WithService("https")
]]></artwork> ]]></artwork>
<ul spacing="normal"> <ul spacing="normal">
<li> <li><t>IP address (an IPv4 or IPv6 address type; note that the examp
<t>IP address (an IPv4 or IPv6 address type; note that the examples les here show the human-readable form of the IP addresses, but the functions can
here show the human-readable form of the IP addresses, but the functions can tak take a binary encoding of the addresses):</t></li>
e a binary encoding of the addresses):</t> </ul>
</li> <artwork><![CDATA[
</ul>
<artwork><![CDATA[
RemoteSpecifier.WithIPAddress(192.0.2.21) RemoteSpecifier.WithIPAddress(192.0.2.21)
]]></artwork> ]]></artwork>
<artwork><![CDATA[
<artwork><![CDATA[
RemoteSpecifier.WithIPAddress(2001:db8:4920:e29d:a420:7461:7073:a) RemoteSpecifier.WithIPAddress(2001:db8:4920:e29d:a420:7461:7073:a)
]]></artwork> ]]></artwork>
<ul spacing="normal"> <ul spacing="normal">
<li> <li><t>Interface identifier (which can be a string name or other pla
<t>Interface identifier (which can be a string name or other platfor tform-specific identifier), e.g., to qualify link-local addresses (see <xref tar
m-specific identifier), e.g., to qualify link-local addresses (see <xref target= get="ifspec"/> for details):</t></li>
"ifspec"/> for details):</t> </ul>
</li>
</ul>
<artwork><![CDATA[ <artwork><![CDATA[
LocalSpecifier.WithInterface("en0") LocalSpecifier.WithInterface("en0")
]]></artwork> ]]></artwork>
<t>The <tt>Resolve</tt> action on a Preconnection can be used to obtain a list of <t>The <tt>Resolve</tt> action on a Preconnection can be used to obtain a list of
available local interfaces.</t> available local interfaces.</t>
<t>Note that an IPv6 address specified with a scope zone ID (e.g. <tt>fe 80::2001:db8%en0</tt>) <t>Note that an IPv6 address specified with a scope zone ID (e.g., <tt>f e80::2001:db8%en0</tt>)
is equivalent to <tt>WithIPAddress</tt> with an unscoped address and <tt>WithInt erface </tt> together.</t> is equivalent to <tt>WithIPAddress</tt> with an unscoped address and <tt>WithInt erface </tt> together.</t>
<t>Applications creating Endpoint objects using <tt>WithHostName</tt> SH <t>Applications creating Endpoint objects using <tt>WithHostName</tt> <b
OULD provide fully-qualified cp14>SHOULD</bcp14> provide Fully Qualified
domain names (FQDNs). Not providing an FQDN will result in the Transport Service Domain Names (FQDNs). Not providing an FQDN will result in the Transport Service
s Implementation s Implementation
needing to use DNS search domains for name resolution, which might lead to incon sistent or unpredictable needing to use DNS search domains for name resolution, which might lead to incon sistent or unpredictable
behavior.</t> behavior.</t>
<t>The design of the API MUST NOT permit an Endpoint object to be config ured with multiple Endpoint Identifiers of the same type. <t>The design of the API <bcp14>MUST NOT</bcp14> permit an Endpoint obje ct to be configured with multiple Endpoint Identifiers of the same type.
For example, an Endpoint object cannot specify two IP addresses. Two separate IP addresses For example, an Endpoint object cannot specify two IP addresses. Two separate IP addresses
are represented as two Endpoint objects. If a Preconnection specifies a Remote are represented as two Endpoint objects. If a Preconnection specifies a Remote
Endpoint with a specific IP address set, it will only establish Connections to Endpoint with a specific IP address set, it will only establish Connections to
that IP address. If, on the other hand, a Remote Endpoint specifies a hostname that IP address. If, on the other hand, a Remote Endpoint specifies a hostname
but no addresses, the Transport Services Implementation can perform name resolut ion and attempt but no addresses, the Transport Services Implementation can perform name resolut ion and attempt
using any address derived from the original hostname of the Remote Endpoint. using any address derived from the original hostname of the Remote Endpoint.
Note that multiple Remote Endpoints can be added to a Preconnection, as discusse d Note that multiple Remote Endpoints can be added to a Preconnection, as discusse d
in <xref target="add-endpoints"/>.</t> in <xref target="add-endpoints"/>.</t>
<t>The Transport Services system resolves names internally, when the <tt >Initiate</tt>, <t>The Transport Services system resolves names internally, when the <tt >Initiate</tt>,
<tt>Listen</tt>, or <tt>Rendezvous</tt> method is called to establish a Connecti on. Privacy <tt>Listen</tt>, or <tt>Rendezvous</tt> method is called to establish a Connecti on. Privacy
considerations for the timing of this resolution are given in <xref target="priv acy-security"/>.</t> considerations for the timing of this resolution are given in <xref target="priv acy-security"/>.</t>
<t>The <tt>Resolve</tt> action on a Preconnection can be used by the app lication to force <t>The <tt>Resolve</tt> action on a Preconnection can be used by the app lication to force
early binding when required, for example with some Network Address Translator early binding when required, for example, with some Network Address Translator
(NAT) traversal protocols (see <xref target="rendezvous"/>).</t> (NAT) traversal protocols (see <xref target="rendezvous"/>).</t>
<section anchor="using-multicast-endpoints"> <section anchor="using-multicast-endpoints">
<name>Using Multicast Endpoints</name> <name>Using Multicast Endpoints</name>
<t>To use multicast, a Preconnection is first created with the Local/R <t>To use multicast, a Preconnection is first created with the Local/R
emote Endpoint Identifer emote Endpoint Identifier
specifying the any-source multicast (ASM) or source-specific multicast (SSM) mul specifying the Any-Source Multicast (ASM) or Source-Specific Multicast (SSM) mul
ticast group and destination port number. ticast group and destination port number.
This is then followed by a call to either <tt>Initiate</tt>, <tt>Listen</tt>, or This is then followed by a call to either <tt>Initiate</tt>, <tt>Listen</tt>, or
<tt>Rendezvous</tt> depending on whether the resulting Connection is to be <tt>Rendezvous</tt>, depending on whether the resulting Connection is to be
used to send messages to the multicast group, receive messages from used to send messages to the multicast group, receive messages from
the group, or, for an any-source multicast group, to both send and the group, or both send and
receive messages.</t> receive messages (as is the case for an ASM group).</t>
<t>Note that the Transport Services API has separate specifier calls f <t>Note that the Transport Services API has separate specifier calls f
or multicast groups to avoid introducing filter properties for single-source mul or multicast groups to avoid introducing filter properties for single-source mul
ticast and seeks to avoid confusion that can be caused by overloading the unicas ticast and seeks to avoid confusion that can be caused by overloading the unicas
t specifiers.</t> t specifiers.
<!-- [rfced] We had two questions related to the abbreviation SSM:
a) Section 6.1.1: Please confirm that "single-source multicast",
rather than "SSM" (for "Source-Specific Multicast"), is correct here.
Original:
Note that the Transport Services API has separate specifier calls for
multicast groups to avoid introducing filter properties for single-
source multicast and seeks to avoid confusion that can be caused by
overloading the unicast specifiers.
b) Is "multicast" in "multicast group" redundant following the
expansions of ASM and SSM here? See also clarification of the slash
character.
Original:
To use multicast, a Preconnection is first created with the Local/
Remote Endpoint Identifer specifying the any-source multicast (ASM)
or source-specific multicast (SSM) multicast group and destination
port number.
Perhaps:
To use multicast, a Preconnection is first created with the Local or [?]
Remote Endpoint Identifier specifying the Any-Source Multicast (ASM)
or Source-Specific Multicast (SSM) group and destination
port number.
-->
</t>
<t>Calling <tt>Initiate</tt> on that Preconnection creates a Connectio n that can be <t>Calling <tt>Initiate</tt> on that Preconnection creates a Connectio n that can be
used to send Messages to the multicast group. The Connection object that is used to send Messages to the multicast group. The Connection object that is
created will support <tt>Send</tt> but not <tt>Receive</tt>. Any Connections cre ated this created will support <tt>Send</tt> but not <tt>Receive</tt>. Any Connections cre ated this
way are send-only, and do not join the multicast group. The resulting way are send-only and do not join the multicast group. The resulting
Connection will have a Local Endpoint identifying the local interface to Connection will have a Local Endpoint identifying the local interface to
which the Connection is bound and a Remote Endpoint identifying the which the Connection is bound and a Remote Endpoint identifying the
multicast group.</t> multicast group.</t>
<t>The following API calls can be used to configure a Preconnection be fore calling <tt>Initiate</tt>:</t> <t>The following API calls can be used to configure a Preconnection be fore calling <tt>Initiate</tt>:</t>
<artwork><![CDATA[ <artwork><![CDATA[
RemoteSpecifier.WithMulticastGroupIP(GroupAddress) RemoteSpecifier.WithMulticastGroupIP(GroupAddress)
RemoteSpecifier.WithPort(PortNumber) RemoteSpecifier.WithPort(PortNumber)
RemoteSpecifier.WithHopLimit(HopLimit) RemoteSpecifier.WithHopLimit(HopLimit)
]]></artwork> ]]></artwork>
<!--[rfced] In the following, what will join the multicast group?
Note, other similar instances exist (e.g., Calling Listen...).
Original:
Calling Rendezvous on a Preconnection with an any-source multicast
group address as the Remote Endpoint Identifer will
join the multicast group, and also indicates that the resulting
Connection can be used to send Messages to the multicast group.
-->
<t>Calling <tt>Listen</tt> on a Preconnection with a multicast group s pecified on the Remote <t>Calling <tt>Listen</tt> on a Preconnection with a multicast group s pecified on the Remote
Endpoint will join the multicast group to receive Messages. This Listener Endpoint will join the multicast group to receive Messages. This Listener
will create one Connection for each Remote Endpoint sending to the group, will create one Connection for each Remote Endpoint sending to the group,
with the Local Endpoint Identifer specified as a group address. The set of Conne ction with the Local Endpoint Identifier specified as a group address. The set of Conn ection
objects created forms a Connection Group. objects created forms a Connection Group.
The receiving interface can be restricted by passing it as part of the LocalSpec ifier or queried through the Message Context on the Messages received (see <xref target="msg-ctx"/> for further details).</t> The receiving interface can be restricted by passing it as part of the LocalSpec ifier or queried through the Message Context on the Messages received (see <xref target="msg-ctx"/> for further details).</t>
<t>Specifying WithHopLimit sets the Time To Live (TTL) field in the he ader of IPv4 packets or the Hop Count field in the header of IPv6 packets.</t> <t>Specifying WithHopLimit sets the Time To Live (TTL) field in the he ader of IPv4 packets or the Hop Count field in the header of IPv6 packets.</t>
<t>The following API calls can be used to configure a Preconnection be fore calling <tt>Listen</tt>:</t> <t>The following API calls can be used to configure a Preconnection be fore calling <tt>Listen</tt>:</t>
<artwork><![CDATA[ <artwork><![CDATA[
LocalSpecifier.WithSingleSourceMulticastGroupIP(GroupAddress, LocalSpecifier.WithSingleSourceMulticastGroupIP(GroupAddress,
SourceAddress) SourceAddress)
LocalSpecifier.WithAnySourceMulticastGroupIP(GroupAddress) LocalSpecifier.WithAnySourceMulticastGroupIP(GroupAddress)
LocalSpecifier.WithPort(PortNumber) LocalSpecifier.WithPort(PortNumber)
]]></artwork> ]]></artwork>
<t>Calling <tt>Rendezvous</tt> on a Preconnection with an any-source m <t>Calling <tt>Rendezvous</tt> on a Preconnection with an ASM group
ulticast group address as the Remote Endpoint Identifier will join the multicast group, and als
address as the Remote Endpoint Identifer will join the multicast group, and also o
indicates that the resulting Connection can be used to send Messages to the indicates that the resulting Connection can be used to send Messages to the
multicast group. The <tt>Rendezvous</tt> call will return both a Connection that multicast group. The <tt>Rendezvous</tt> call will return both:</t>
can be used to send to the group, that acts the same as a Connection <ol><li>a Connection that
returned by calling <tt>Initiate</tt> with a multicast Remote Endpoint, and a can be used to send to the group and that acts the same as a Connection
returned by calling <tt>Initiate</tt> with a multicast Remote Endpoint and</li>
<li>a
Listener that acts as if <tt>Listen</tt> had been called with a multicast Remote Listener that acts as if <tt>Listen</tt> had been called with a multicast Remote
Endpoint. Endpoint.</li></ol>
Calling <tt>Rendezvous</tt> on a Preconnection with a source-specific multicast <t>Calling <tt>Rendezvous</tt> on a Preconnection with an SSM
group address as the Local Endpoint Identifer results in an <tt>EstablishmentErr group address as the Local Endpoint Identifier results in an <tt>EstablishmentEr
or</tt>.</t> ror</tt>.</t>
<t>The following API calls can be used to configure a Preconnection be fore calling <tt>Rendezvous</tt>:</t> <t>The following API calls can be used to configure a Preconnection be fore calling <tt>Rendezvous</tt>:</t>
<artwork><![CDATA[ <artwork><![CDATA[
RemoteSpecifier.WithMulticastGroupIP(GroupAddress) RemoteSpecifier.WithMulticastGroupIP(GroupAddress)
RemoteSpecifier.WithPort(PortNumber) RemoteSpecifier.WithPort(PortNumber)
RemoteSpecifier.WithHopLimit(HopLimit) RemoteSpecifier.WithHopLimit(HopLimit)
LocalSpecifier.WithAnySourceMulticastGroupIP(GroupAddress) LocalSpecifier.WithAnySourceMulticastGroupIP(GroupAddress)
LocalSpecifier.WithPort(PortNumber) LocalSpecifier.WithPort(PortNumber)
LocalSpecifier.WithHopLimit(HopLimit) LocalSpecifier.WithHopLimit(HopLimit)
]]></artwork> ]]></artwork>
<t>See <xref target="multicast-examples"/> for more examples.</t> <t>See <xref target="multicast-examples"/> for more examples.</t>
skipping to change at line 897 skipping to change at line 1110
<li> <li>
<t>Specifying an interface on a Remote Endpoint qualifies the scop e zone of the Remote Endpoint, e.g., for link-local addresses.</t> <t>Specifying an interface on a Remote Endpoint qualifies the scop e zone of the Remote Endpoint, e.g., for link-local addresses.</t>
</li> </li>
<li> <li>
<t>Specifying an interface on a Local Endpoint explicitly binds al l candidates derived from this Endpoint to use the specified interface.</t> <t>Specifying an interface on a Local Endpoint explicitly binds al l candidates derived from this Endpoint to use the specified interface.</t>
</li> </li>
<li> <li>
<t>Specifying an interface using the <tt>interface</tt> Selection Property (<xref target="prop-interface"/>) or indirectly via the <tt>pvd</tt> Se lection Property (<xref target="prop-pvd"/>) influences the selection among the available candidates.</t> <t>Specifying an interface using the <tt>interface</tt> Selection Property (<xref target="prop-interface"/>) or indirectly via the <tt>pvd</tt> Se lection Property (<xref target="prop-pvd"/>) influences the selection among the available candidates.</t>
</li> </li>
</ul> </ul>
<t>While specifying an Interface on an Endpoint restricts the candidat es available for Connection establishment in the Pre-Establishment Phase, the Se lection Properties prioritize and constrain the Connection establishment.</t> <t>While specifying an Interface on an Endpoint restricts the candidat es available for Connection establishment in the preestablishment phase, the Sel ection Properties prioritize and constrain the Connection establishment.</t>
</section> </section>
<section anchor="protocol-specific-endpoints"> <section anchor="protocol-specific-endpoints">
<name>Protocol-Specific Endpoints</name> <name>Protocol-Specific Endpoints</name>
<t>An Endpoint can have an alternative definition when using different protocols. <t>An Endpoint can have an alternative definition when using different protocols.
For example, a server that supports both TLS/TCP and QUIC could be accessible For example, a server that supports both TLS/TCP and QUIC could be accessible
on two different port numbers depending on which protocol is used.</t> on two different port numbers, depending on which protocol is used.</t>
<t>To scope an Endpoint to apply conditionally to a specific transport <t>To scope an Endpoint to apply conditionally to a specific transport
protocol (such as defining an alternate port to use when QUIC protocol (such as defining an alternate port to use when QUIC
is selected, as opposed to TCP), an Endpoint can be is selected, as opposed to TCP), an Endpoint can be
associated with a protocol identifier. Protocol identifiers are associated with a protocol identifier. Protocol identifiers are
objects or enumeration values provided by the Transport objects or enumeration values provided by the Transport
Services API, which will vary based on which protocols are Services API that will vary based on which protocols are
implemented in a particular system.</t> implemented in a particular system.</t>
<artwork><![CDATA[ <artwork><![CDATA[
AlternateRemoteSpecifier.WithProtocol(QUIC) AlternateRemoteSpecifier.WithProtocol(QUIC)
]]></artwork> ]]></artwork>
<t>The following example shows a case where <tt>example.com</tt> has a server <t>The following example shows a case where <tt>example.com</tt> has a server
running on port 443, with an alternate port of 8443 for QUIC. Both running on port 443 with an alternate port of 8443 for QUIC. Both
endpoints can be passed when creating a Preconnection.</t> endpoints can be passed when creating a Preconnection.</t>
<artwork><![CDATA[ <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithHostName("example.com") RemoteSpecifier.WithHostName("example.com")
RemoteSpecifier.WithPort(443) RemoteSpecifier.WithPort(443)
QUICRemoteSpecifier := NewRemoteEndpoint() QUICRemoteSpecifier := NewRemoteEndpoint()
QUICRemoteSpecifier.WithHostName("example.com") QUICRemoteSpecifier.WithHostName("example.com")
QUICRemoteSpecifier.WithPort(8443) QUICRemoteSpecifier.WithPort(8443)
QUICRemoteSpecifier.WithProtocol(QUIC) QUICRemoteSpecifier.WithProtocol(QUIC)
skipping to change at line 933 skipping to change at line 1146
QUICRemoteSpecifier.WithHostName("example.com") QUICRemoteSpecifier.WithHostName("example.com")
QUICRemoteSpecifier.WithPort(8443) QUICRemoteSpecifier.WithPort(8443)
QUICRemoteSpecifier.WithProtocol(QUIC) QUICRemoteSpecifier.WithProtocol(QUIC)
RemoteSpecifiers := [ RemoteSpecifier, QUICRemoteSpecifier ] RemoteSpecifiers := [ RemoteSpecifier, QUICRemoteSpecifier ]
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="endpoint-examples"> <section anchor="endpoint-examples">
<name>Endpoint Examples</name> <name>Endpoint Examples</name>
<t>The following examples of Endpoints show common usage patterns.</t> <t>The following examples of Endpoints show common usage patterns.</t>
<t>Specify a Remote Endpoint using a hostname "example.com" and a serv ice name "https", which tells the system to use the default port for HTTPS (443) :</t> <t>Specify a Remote Endpoint using a hostname "example.com" and a serv ice name "https", which tells the system to use the default port for HTTPS (443) :</t>
<artwork><![CDATA[ <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithHostName("example.com") RemoteSpecifier.WithHostName("example.com")
RemoteSpecifier.WithService("https") RemoteSpecifier.WithService("https")
]]></artwork> ]]></artwork>
<t>Specify a Remote Endpoint using an IPv6 address and remote port:</t > <t>Specify a Remote Endpoint using an IPv6 address and remote port:</t >
<artwork><![CDATA[ <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithIPAddress(2001:db8:4920:e29d:a420:7461:7073:a) RemoteSpecifier.WithIPAddress(2001:db8:4920:e29d:a420:7461:7073:a)
RemoteSpecifier.WithPort(443) RemoteSpecifier.WithPort(443)
]]></artwork> ]]></artwork>
<t>Specify a Remote Endpoint using an IPv4 address and remote port:</t > <t>Specify a Remote Endpoint using an IPv4 address and remote port:</t >
<artwork><![CDATA[ <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithIPAddress(192.0.2.21) RemoteSpecifier.WithIPAddress(192.0.2.21)
RemoteSpecifier.WithPort(443) RemoteSpecifier.WithPort(443)
]]></artwork> ]]></artwork>
<t>Specify a Local Endpoint using a local interface name and no local
port, <t>Specify a Local Endpoint using a local interface name and no local
port
to let the system assign an ephemeral local port:</t> to let the system assign an ephemeral local port:</t>
<artwork><![CDATA[ <artwork><![CDATA[
LocalSpecifier := NewLocalEndpoint() LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithInterface("en0") LocalSpecifier.WithInterface("en0")
]]></artwork> ]]></artwork>
<t>Specify a Local Endpoint using a local interface name and local por t:</t> <t>Specify a Local Endpoint using a local interface name and local por t:</t>
<artwork><![CDATA[ <artwork><![CDATA[
LocalSpecifier := NewLocalEndpoint() LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithInterface("en0") LocalSpecifier.WithInterface("en0")
LocalSpecifier.WithPort(443) LocalSpecifier.WithPort(443)
]]></artwork> ]]></artwork>
<t>As an alternative to specifying an interface name for the Local End point, an application <t>As an alternative to specifying an interface name for the Local End point, an application
can express more fine-grained preferences using the <tt>Interface Instance or Ty pe</tt> can express more fine-grained preferences using the <tt>Interface Instance or Ty pe</tt>
Selection Property, see <xref target="prop-interface"/>. However, if the applica tion specifies Selection Selection Property; see <xref target="prop-interface"/>. However, if the applica tion specifies Selection
Properties that are inconsistent with the Local Endpoint, this will result in an error once the Properties that are inconsistent with the Local Endpoint, this will result in an error once the
application attempts to open a Connection.</t> application attempts to open a Connection.</t>
<t>Specify a Local Endpoint using a STUN server:</t> <t>Specify a Local Endpoint using a STUN server:</t>
<artwork><![CDATA[ <artwork><![CDATA[
LocalSpecifier := NewLocalEndpoint() LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithStunServer(address, port, credentials) LocalSpecifier.WithStunServer(address, port, credentials)
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="multicast-examples"> <section anchor="multicast-examples">
<name>Multicast Examples</name> <name>Multicast Examples</name>
<t>The following examples show how multicast groups can be used.</t> <t>The following examples show how multicast groups can be used.</t>
<t>Join an Any-Source Multicast group in receive-only mode, bound to a known <t>Join an ASM group in receive-only mode, bound to a known
port on a named local interface:</t> port on a named local interface:</t>
<artwork><![CDATA[ <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier := NewRemoteEndpoint()
LocalSpecifier := NewLocalEndpoint() LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithAnySourceMulticastGroupIP(233.252.0.0) LocalSpecifier.WithAnySourceMulticastGroupIP(233.252.0.0)
LocalSpecifier.WithPort(5353) LocalSpecifier.WithPort(5353)
LocalSpecifier.WithInterface("en0") LocalSpecifier.WithInterface("en0")
TransportProperties := ... TransportProperties := ...
SecurityParameters := ... SecurityParameters := ...
Preconnection := NewPreconnection(LocalSpecifier, Preconnection := NewPreconnection(LocalSpecifier,
RemoteSpecifier, RemoteSpecifier,
TransportProperties, TransportProperties,
SecurityProperties) SecurityProperties)
Listener := Preconnection.Listen() Listener := Preconnection.Listen()
]]></artwork> ]]></artwork>
<t>Join a Source-Specific Multicast group in receive-only mode, bound to a known <t>Join an SSM group in receive-only mode, bound to a known
port on a named local interface:</t> port on a named local interface:</t>
<artwork><![CDATA[ <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier := NewRemoteEndpoint()
LocalSpecifier := NewLocalEndpoint() LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithSingleSourceMulticastGroupIP(233.252.0.0, LocalSpecifier.WithSingleSourceMulticastGroupIP(233.252.0.0,
198.51.100.10) 198.51.100.10)
LocalSpecifier.WithPort(5353) LocalSpecifier.WithPort(5353)
LocalSpecifier.WithInterface("en0") LocalSpecifier.WithInterface("en0")
TransportProperties := ... TransportProperties := ...
SecurityParameters := ... SecurityParameters := ...
Preconnection := NewPreconnection(LocalSpecifier, Preconnection := NewPreconnection(LocalSpecifier,
RemoteSpecifier, RemoteSpecifier,
TransportProperties, TransportProperties,
SecurityProperties) SecurityProperties)
Listener := Preconnection.Listen() Listener := Preconnection.Listen()
]]></artwork> ]]></artwork>
<t>Create a Source-Specific Multicast group as a sender:</t> <t>Create an SSM group as a sender:</t>
<artwork><![CDATA[ <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithMulticastGroupIP(233.251.240.1) RemoteSpecifier.WithMulticastGroupIP(233.251.240.1)
RemoteSpecifier.WithPort(5353) RemoteSpecifier.WithPort(5353)
RemoteSpecifier.WithHopLimit(8) RemoteSpecifier.WithHopLimit(8)
LocalSpecifier := NewLocalEndpoint() LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithIPAddress(192.0.2.22) LocalSpecifier.WithIPAddress(192.0.2.22)
LocalSpecifier.WithInterface("en0") LocalSpecifier.WithInterface("en0")
TransportProperties := ... TransportProperties := ...
SecurityParameters := ... SecurityParameters := ...
Preconnection := NewPreconnection(LocalSpecifier, Preconnection := NewPreconnection(LocalSpecifier,
RemoteSpecifier, RemoteSpecifier,
TransportProperties, TransportProperties,
SecurityProperties) SecurityProperties)
Connection := Preconnection.Initiate() Connection := Preconnection.Initiate()
]]></artwork> ]]></artwork>
<t>Join an any-source multicast group as both a sender and a receiver: </t> <t>Join an ASM group as both a sender and a receiver:</t>
<artwork><![CDATA[ <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithMulticastGroupIP(233.252.0.0) RemoteSpecifier.WithMulticastGroupIP(233.252.0.0)
RemoteSpecifier.WithPort(5353) RemoteSpecifier.WithPort(5353)
RemoteSpecifier.WithHopLimit(8) RemoteSpecifier.WithHopLimit(8)
LocalSpecifier := NewLocalEndpoint() LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithAnySourceMulticastGroupIP(233.252.0.0) LocalSpecifier.WithAnySourceMulticastGroupIP(233.252.0.0)
LocalSpecifier.WithIPAddress(192.0.2.22) LocalSpecifier.WithIPAddress(192.0.2.22)
LocalSpecifier.WithPort(5353) LocalSpecifier.WithPort(5353)
skipping to change at line 1063 skipping to change at line 1283
Preconnection := NewPreconnection(LocalSpecifier, Preconnection := NewPreconnection(LocalSpecifier,
RemoteSpecifier, RemoteSpecifier,
TransportProperties, TransportProperties,
SecurityProperties) SecurityProperties)
Connection, Listener := Preconnection.Rendezvous() Connection, Listener := Preconnection.Rendezvous()
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
<section anchor="selection-props"> <section anchor="selection-props">
<name>Specifying Transport Properties</name> <name>Specifying Transport Properties</name>
<!--[rfced] Is the meaning of this text "on a per-Connection and
per-Message level"?
Original:
...the detailed operation of the selected Protocol Stacks on a per-
Connection and Message level.
Perhaps:
...the detailed operation of the selected Protocol Stacks on a
per-Connection and per-Message level.
-->
<t>A Preconnection object holds properties reflecting the application's <t>A Preconnection object holds properties reflecting the application's
requirements and preferences for the transport. These include Selection requirements and preferences for the transport. These include Selection
Properties for selecting Protocol Stacks and paths, as well as Connection Properties for selecting Protocol Stacks and paths, as well as Connection
Properties and Message Properties for configuration of the detailed operation Properties and Message Properties for configuration of the detailed operation
of the selected Protocol Stacks on a per-Connection and Message level.</t> of the selected Protocol Stacks on a per-Connection and Message level.</t>
<t>The protocol(s) and path(s) selected as candidates during establishme nt are <t>The protocol(s) and path(s) selected as candidates during establishme nt are
determined and configured using these properties. Since there could be paths determined and configured using these properties. Since there could be paths
over which some transport protocols are unable to operate, or Remote Endpoints over which some transport protocols are unable to operate, or Remote Endpoints
that support only specific network addresses or transports, transport protocol that support only specific network addresses or transports, transport protocol
selection is necessarily tied to path selection. This could involve choosing selection is necessarily tied to path selection. This could involve choosing
between multiple local interfaces that are connected to different access between multiple local interfaces that are connected to different access
networks.</t> networks.</t>
<t>When additional information (such as Provisioning Domain (PvD) inform ation <t>When additional information (such as PvD information
<xref target="RFC7556"/>) is available about the networks over which an endpoint can operate, <xref target="RFC7556"/>) is available about the networks over which an endpoint can operate,
this can inform the selection between alternate network paths. this can inform the selection between alternate network paths.
Path information can include PMTU, set of supported DSCPs, Path information can include the Path MTU (PMTU), the set of supported Different iated Services Code Points (DSCPs),
expected usage, cost, etc. The usage of this information by the Transport expected usage, cost, etc. The usage of this information by the Transport
Services System is generally independent of the specific mechanism/protocol Services System is generally independent of the specific mechanism/protocol
used to receive the information (e.g. zero-conf, DHCP, or IPv6 RA).</t> used to receive the information (e.g., zero-conf, DHCP, or IPv6 Router Advertise
ments (RAs)).
<!-- [rfced] Section 6.2: For ease of the reader, we expanded "RAs" as
"Router Advertisements". If this is incorrect, please provide
the correct definition.
Original:
The usage of this information by
the Transport Services System is generally independent of the
specific mechanism/protocol used to receive the information (e.g.
zero-conf, DHCP, or IPv6 RA).
Currently:
The usage of this information by the Transport Services System
is generally independent of the specific mechanism/protocol used to
receive the information (e.g., zero-conf, DHCP, or IPv6 Router
Advertisements (RAs)). -->
</t>
<t>Most Selection Properties are represented as Preferences, which can <t>Most Selection Properties are represented as Preferences, which can
take one of five values:</t> take one of five values:</t>
<table anchor="tab-pref-levels"> <table anchor="tab-pref-levels">
<name>Selection Property Preference Levels</name> <name>Selection Property Preference Levels</name>
<thead> <thead>
<tr> <tr>
<th align="left">Preference</th> <th align="left">Preference</th>
<th align="left">Effect</th> <th align="left">Effect</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Require</td> <td align="left">Require</td>
<td align="left">Select only protocols/paths providing the propert y, fail otherwise</td> <td align="left">Select only protocols/paths providing the propert y; otherwise, fail</td>
</tr> </tr>
<tr> <tr>
<td align="left">Prefer</td> <td align="left">Prefer</td>
<td align="left">Prefer protocols/paths providing the property, pr oceed otherwise</td> <td align="left">Prefer protocols/paths providing the property; ot herwise, proceed</td>
</tr> </tr>
<tr> <tr>
<td align="left">No Preference</td> <td align="left">No Preference</td>
<td align="left">No preference</td> <td align="left">No preference</td>
</tr> </tr>
<tr> <tr>
<td align="left">Avoid</td> <td align="left">Avoid</td>
<td align="left">Prefer protocols/paths not providing the property , proceed otherwise</td> <td align="left">Prefer protocols/paths not providing the property ; otherwise, proceed</td>
</tr> </tr>
<tr> <tr>
<td align="left">Prohibit</td> <td align="left">Prohibit</td>
<td align="left">Select only protocols/paths not providing the pro perty, fail otherwise</td> <td align="left">Select only protocols/paths not providing the pro perty; otherwise, fail</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The implementation MUST ensure an outcome that is consistent with all application <t>The implementation <bcp14>MUST</bcp14> ensure an outcome that is cons istent with all application
requirements expressed using Require and Prohibit. While preferences requirements expressed using Require and Prohibit. While preferences
expressed using Prefer and Avoid influence protocol and path selection as well, expressed using Prefer and Avoid influence protocol and path selection as well,
outcomes can vary given the same Selection Properties, because the available outcomes can vary, even given the same Selection Properties, because the availab le
protocols and paths can differ across systems and contexts. However, protocols and paths can differ across systems and contexts. However,
implementations are RECOMMENDED to seek to provide a consistent outcome implementations are <bcp14>RECOMMENDED</bcp14> to seek to provide a consistent o utcome
to an application, when provided with the same set of Selection Properties.</t> to an application, when provided with the same set of Selection Properties.</t>
<t>Note that application preferences can conflict with each other. For <t>Note that application preferences can conflict with each other. For
example, if an application indicates a preference for a specific path by example, if an application indicates a preference for a specific path by
specifying an interface, but also a preference for a protocol, a situation specifying an interface, but also a preference for a protocol, a situation
might occur in which the preferred protocol is not available on the preferred might occur in which the preferred protocol is not available on the preferred
path. In such cases, applications can expect properties that determine path path. In such cases, applications can expect properties that determine path
selection to be prioritized over properties that determine protocol selection. selection to be prioritized over properties that determine protocol selection.
The transport system SHOULD determine the preferred path first, regardless of The transport system <bcp14>SHOULD</bcp14> determine the preferred path first, r egardless of
protocol preferences. This ordering is chosen to provide consistency across protocol preferences. This ordering is chosen to provide consistency across
implementations, based on the fact that it is more common for the use of a implementations; this is based on the fact that it is more common for the use of a
given network path to determine cost to the user (i.e., an interface type given network path to determine cost to the user (i.e., an interface type
preference might be based on a user's preference to avoid being charged preference might be based on a user's preference to avoid being charged
more for a cellular data plan).</t> more for a cellular data plan).</t>
<t>Selection and Connection Properties, as well as defaults for Message <t>Selection and Connection Properties, as well as defaults for Message
Properties, can be added to a Preconnection to configure the selection process Properties, can be added to a Preconnection to configure the selection process
and to further configure the eventually selected Protocol Stack(s). They are and to further configure the eventually selected Protocol Stack(s). They are
collected into a TransportProperties object to be passed into a Preconnection collected into a TransportProperties object to be passed into a Preconnection
object:</t> object:</t>
<artwork><![CDATA[ <artwork><![CDATA[
TransportProperties := NewTransportProperties() TransportProperties := NewTransportProperties()
]]></artwork> ]]></artwork>
<t>Individual properties are then set on the TransportProperties object. <t>Individual properties are then set on the TransportProperties object.
Setting a Transport Property to a value overrides the previous value of this Tra nsport Property.</t> Setting a Transport Property to a value overrides the previous value of this Tra nsport Property.</t>
<artwork><![CDATA[ <artwork><![CDATA[
TransportProperties.Set(property, value) TransportProperties.Set(property, value)
]]></artwork> ]]></artwork>
<t>To aid readability, implementations MAY provide additional convenienc <t>To aid readability, implementations <bcp14>MAY</bcp14> provide additi
e functions to simplify use of Selection Properties: see <xref target="preferenc onal convenience functions to simplify the use of Selection Properties: see <xre
e-conv"/> for examples. f target="preference-conv"/> for examples.
In addition, implementations MAY provide a mechanism to create TransportProperti In addition, implementations <bcp14>MAY</bcp14> provide a mechanism to create Tr
es objects that ansportProperties objects that
are preconfigured for common use cases, as outlined in <xref target="property-pr ofiles"/>.</t> are preconfigured for common use cases, as outlined in <xref target="property-pr ofiles"/>.</t>
<t>Transport Properties for an established Connection can be queried via the Connection object, as outlined in <xref target="introspection"/>.</t> <t>Transport Properties for an established Connection can be queried via the Connection object, as outlined in <xref target="introspection"/>.</t>
<t>A Connection gets its Transport Properties either by being explicitly <t>A Connection gets its Transport Properties by either being explicitly
configured configured
via a Preconnection, by configuration after establishment, or by inheriting them via a Preconnection, being configured after establishment, or inheriting them
from an antecedent via cloning; see <xref target="groups"/> for more.</t> from an antecedent via cloning; see <xref target="groups"/> for more details.</t
>
<t><xref target="connection-props"/> provides a list of Connection Prope rties, while Selection <t><xref target="connection-props"/> provides a list of Connection Prope rties, while Selection
Properties are listed in the subsections below. Selection Properties are Properties are listed in the subsections below. Selection Properties are
only considered during establishment, and can not be changed after a Connection only considered during establishment and cannot be changed after a Connection
is established. After a Connection is established, Selection Properties can only is established. At which point, Selection Properties can only
be read to check the properties used by the Connection. Upon reading, the be read to check the properties used by the Connection. Upon reading, the
Preference type of a Selection Property changes into Boolean, where <tt>true</tt Preference type of a Selection Property changes into Boolean, where:</t>
> means <ul><li><tt>true</tt> means
that the selected Protocol Stack supports the feature or uses the path associate d that the selected Protocol Stack supports the feature or uses the path associate d
with the Selection Property, and <tt>false</tt> means that the Protocol Stack do with the Selection Property, and</li>
es not <li><tt>false</tt> means that the Protocol Stack does not
support the feature or use the path. Implementations support the feature or use the path.</li></ul>
of Transport Services systems could alternatively use the two Preference values <t>Implementations
<tt>Require</tt> of Transport Services systems could alternatively use the <tt>Require</tt>
and <tt>Prohibit</tt> to represent <tt>true</tt> and <tt>false</tt>, respectivel and <tt>Prohibit</tt> Preference values to represent <tt>true</tt> and <tt>false
y. </tt>, respectively.
Other types of Selection Properties remain unchanged when they are made availabl e for Other types of Selection Properties remain unchanged when they are made availabl e for
reading after a Connection is established.</t> reading after a Connection is established.</t>
<t>An implementation of the Transport Services API needs to provide sens ible defaults for Selection <t>An implementation of the Transport Services API needs to provide sens ible defaults for Selection
Properties. The default values for each property below represent a Properties. The default values for each property below represent a
configuration that can be implemented over TCP. If these default values are used configuration that can be implemented over TCP. If these default values are used
and TCP is not supported by a Transport Services system, then an application usi ng the and TCP is not supported by a Transport Services system, then an application usi ng the
default set of Properties might not succeed in establishing a Connection. Using default set of Properties might not succeed in establishing a Connection. Using
the same default values for independent Transport Services systems can be benefi cial the same default values for independent Transport Services systems can be benefi cial
when applications are ported between different implementations/platforms, even i f this when applications are ported between different implementations/platforms, even i f this
default could lead to a Connection failure when TCP is not available. If default default could lead to a Connection failure when TCP is not available. If default
values other than those suggested below are used, it is RECOMMENDED to clearly values other than those suggested below are used, it is <bcp14>RECOMMENDED</bcp1 4> to clearly
document any differences.</t> document any differences.</t>
<section anchor="prop-reliable"> <section anchor="prop-reliable">
<name>Reliable Data Transfer (Connection)</name> <name>Reliable Data Transfer (Connection)</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>reliability</t> <t>reliability</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Preference</t> <t>Preference</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Require</t> <t>Require</t>
</dd> </dd>
</dl> </dl>
<t>This property specifies whether the application needs to use a tran sport <t>This property specifies whether the application needs to use a tran sport
protocol that ensures that protocol that ensures that
all data is received at the Remote Endpoint in order without loss or duplication . all data is received at the Remote Endpoint in order, without loss or duplicatio n.
When reliable data transfer is enabled, this When reliable data transfer is enabled, this
also entails being notified when a Connection is closed or aborted.</t> also entails being notified when a Connection is closed or aborted.</t>
</section> </section>
<section anchor="prop-boundaries"> <section anchor="prop-boundaries">
<name>Preservation of Message Boundaries</name> <name>Preservation of Message Boundaries</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>preserveMsgBoundaries</t> <t>preserveMsgBoundaries</t>
</dd> </dd>
skipping to change at line 1273 skipping to change at line 1527
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Preference</t> <t>Preference</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>No Preference</t> <t>No Preference</t>
</dd> </dd>
</dl> </dl>
<t>This property specifies whether an application would like to supply a Message to <t>This property specifies whether an application would like to supply a Message to
the transport protocol before connection establishment that will then be the transport protocol before connection establishment, which will then be
reliably transferred to the Remote Endpoint before or during connection reliably transferred to the Remote Endpoint before or during connection
establishment. This Message can potentially be received multiple times (i.e., establishment. This Message can potentially be received multiple times (i.e.,
multiple copies of the Message data could be passed to the Remote Endpoint). multiple copies of the Message data could be passed to the Remote Endpoint).
See also <xref target="msg-safelyreplayable"/>.</t> See also <xref target="msg-safelyreplayable"/>.</t>
</section> </section>
<section anchor="prop-multistream"> <section anchor="prop-multistream">
<name>Multistream Connections in Group</name> <name>Multistream Connections in a Group</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>multistreaming</t> <t>multistreaming</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Preference</t> <t>Preference</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Prefer</t> <t>Prefer</t>
</dd> </dd>
</dl> </dl>
<t>This property specifies whether the application would prefer multip le Connections <t>This property specifies whether the application would prefer multip le Connections
within a Connection Group to be provided by streams of a single underlying within a Connection Group to be provided by streams of a single underlying
transport connection where possible.</t> transport connection, where possible.</t>
</section> </section>
<section anchor="prop-checksum-control-send"> <section anchor="prop-checksum-control-send">
<name>Full Checksum Coverage on Sending</name> <name>Full Checksum Coverage on Sending</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>fullChecksumSend</t> <t>fullChecksumSend</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
skipping to change at line 1340 skipping to change at line 1594
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Require</t> <t>Require</t>
</dd> </dd>
</dl> </dl>
<t>This property specifies the application's need for protection again st <t>This property specifies the application's need for protection again st
corruption for all data received on this Connection. Disabling this property cou ld enable corruption for all data received on this Connection. Disabling this property cou ld enable
the application to influence the required minimum receiver checksum coverage aft er Connection establishment (see <xref target="conn-recv-checksum"/>).</t> the application to influence the required minimum receiver checksum coverage aft er Connection establishment (see <xref target="conn-recv-checksum"/>).</t>
</section> </section>
<section anchor="prop-cc"> <section anchor="prop-cc">
<name>Congestion control</name> <name>Congestion Control</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>congestionControl</t> <t>congestionControl</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Preference</t> <t>Preference</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Require</t> <t>Require</t>
</dd> </dd>
</dl> </dl>
<t>This property specifies whether the application would like the Conn <t>This property specifies whether or not the application would like t
ection to be he Connection to be
congestion controlled or not. Note that if a Connection is not congestion congestion controlled. Note that if a Connection is not congestion
controlled, an application using such a Connection SHOULD itself perform controlled, an application using such a Connection <bcp14>SHOULD</bcp14> itself
perform
congestion control in accordance with <xref target="RFC2914"/> or use a circuit breaker in congestion control in accordance with <xref target="RFC2914"/> or use a circuit breaker in
accordance with <xref target="RFC8084"/>, whichever is appropriate. Also note th at reliability accordance with <xref target="RFC8084"/>, whichever is appropriate. Also note th at reliability
is usually combined with congestion control in protocol implementations, is usually combined with congestion control in protocol implementations renderin
rendering "reliable but not congestion controlled" a request that is unlikely to g "reliable but not congestion controlled", a request that is unlikely to
succeed. If the Connection is congestion controlled, performing additional conge stion control succeed. If the Connection is congestion controlled, performing additional conge stion control
in the application can have negative performance implications.</t> in the application can have negative performance implications.</t>
</section> </section>
<section anchor="keep-alive"> <section anchor="keep-alive">
<name>Keep alive</name> <name>Keep-Alive Packets</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>keepAlive</t> <t>keepAlive</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Preference</t> <t>Preference</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>No Preference</t> <t>No Preference</t>
</dd> </dd>
</dl> </dl>
<t>This property specifies whether the application would like the Conn <t>This property specifies whether or not the application would like t
ection to send he Connection to send
keep-alive packets or not. Note that if a Connection determines that keep-alive keep-alive packets. Note that if a Connection determines that keep-alive
packets are being sent, the application SHOULD itself avoid generating additiona packets are being sent, the application itself <bcp14>SHOULD</bcp14> avoid gener
l keep-alive ating additional keep-alive
messages. Note that when supported, the system will use the default period messages. Note that, when supported, the system will use the default period
for generation of the keep alive-packets. (See also <xref target="keep-alive-tim for generation of the keep-alive packets. (See also <xref target="keep-alive-tim
eout"/>).</t> eout"/>.)</t>
</section> </section>
<section anchor="prop-interface"> <section anchor="prop-interface">
<name>Interface Instance or Type</name> <name>Interface Instance or Type</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>interface</t> <t>interface</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
skipping to change at line 1411 skipping to change at line 1664
</dd> </dd>
</dl> </dl>
<t>This property allows the application to select any specific network interfaces <t>This property allows the application to select any specific network interfaces
or categories of interfaces it wants to <tt>Require</tt>, <tt>Prohibit</tt>, <tt >Prefer</tt>, or or categories of interfaces it wants to <tt>Require</tt>, <tt>Prohibit</tt>, <tt >Prefer</tt>, or
<tt>Avoid</tt>. Note that marking a specific interface as <tt>Require</tt> stric tly limits path <tt>Avoid</tt>. Note that marking a specific interface as <tt>Require</tt> stric tly limits path
selection to that single interface, and often leads to less flexible and resilie nt selection to that single interface, and often leads to less flexible and resilie nt
connection establishment.</t> connection establishment.</t>
<t>In contrast to other Selection Properties, this property is a set o f <t>In contrast to other Selection Properties, this property is a set o f
tuples of (Enumerated) interface identifier and preference. It can either be tuples of (Enumerated) interface identifier and preference. It can either be
implemented directly as such, or for making one preference available for each implemented directly as such, or for making one preference available for each
interface and interface type available on the system.</t> interface and interface type available on the system.
<t>The set of valid interface types is implementation- and system-spec
ific. For <!-- [rfced] Sections 6.2.11 and 6.2.12: Please review the following
text for clarity specifically making the two options connected by
"either" symmetrical grammatically.
Original:
It can either be implemented directly as such, or for making one
preference available for each interface and interface type available
on the system.
Perhaps:
It can be implemented either 1) directly as such or 2) for making one
preference available for each interface and interface type that is
available on the system.
Perhaps:
It can either be implemented directly as such or be implemented to
make one preference available for each interface and interface type
available on the system.
-->
</t>
<t>The set of valid interface types is specific to the implementation
or system. For
example, on a mobile device, there could be <tt>Wi-Fi</tt> and <tt>Cellular</tt> interface types example, on a mobile device, there could be <tt>Wi-Fi</tt> and <tt>Cellular</tt> interface types
available; whereas on a desktop computer, <tt>Wi-Fi</tt> and <tt>Wired available; whereas, on a desktop computer, <tt>Wi-Fi</tt> and <tt>Wired
Ethernet</tt> interface types might be available. An implementation should provi de all types Ethernet</tt> interface types might be available. An implementation should provi de all types
that are supported on the local system, to allow that are supported on the local system to allow
applications to be written generically. For example, if a single implementation applications to be written generically. For example, if a single implementation
is used on both mobile devices and desktop devices, it ought to define the is used on both mobile devices and desktop devices, it ought to define the
<tt>Cellular</tt> interface type for both systems, since an application might wi sh to <tt>Cellular</tt> interface type for both systems, since an application might wi sh to
always prohibit cellular.</t> always prohibit cellular.</t>
<t>The set of interface types is expected to change over time as new a ccess <t>The set of interface types is expected to change over time as new a ccess
technologies become available. The taxonomy of interface types on a given technologies become available. The taxonomy of interface types on a given
Transport Services system is implementation-specific.</t> Transport Services system is implementation specific.</t>
<t>Interface types SHOULD NOT be treated as a proxy for properties of <t>Interface types <bcp14>SHOULD NOT</bcp14> be treated as a proxy for
interfaces properties of interfaces,
such as metered or unmetered network access. If an application needs to prohibit such as metered or unmetered network access. If an application needs to prohibit
metered interfaces, this should be specified via Provisioning Domain attributes metered interfaces, this should be specified via Provisioning Domain attributes
(see <xref target="prop-pvd"/>) or another specific property.</t> (see <xref target="prop-pvd"/>) or another specific property.</t>
<t>Note that this property is not used to specify an interface scope z one for a particular Endpoint. <xref target="ifspec"/> provides details about ho w to qualify endpoint candidates on a per-interface basis.</t> <t>Note that this property is not used to specify an interface scope z one for a particular Endpoint. <xref target="ifspec"/> provides details about ho w to qualify endpoint candidates on a per-interface basis.</t>
</section> </section>
<section anchor="prop-pvd"> <section anchor="prop-pvd">
<name>Provisioning Domain Instance or Type</name> <name>Provisioning Domain Instance or Type</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
skipping to change at line 1448 skipping to change at line 1723
<dd> <dd>
<t>Set of (Preference, Enumeration)</t> <t>Set of (Preference, Enumeration)</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Empty (not setting a preference for any PvD)</t> <t>Empty (not setting a preference for any PvD)</t>
</dd> </dd>
</dl> </dl>
<t>Similar to <tt>interface</tt> (see <xref target="prop-interface"/>) , this property <t>Similar to <tt>interface</tt> (see <xref target="prop-interface"/>) , this property
allows the application to control path selection by selecting which specific allows the application to control path selection by selecting which specific
Provisioning Domain (PvD) or categories of PVDs it wants to PvD or categories of PvDs it wants to
<tt>Require</tt>, <tt>Prohibit</tt>, <tt>Prefer</tt>, or <tt>Avoid</tt>. Provisi oning Domains define <tt>Require</tt>, <tt>Prohibit</tt>, <tt>Prefer</tt>, or <tt>Avoid</tt>. Provisi oning Domains define
consistent sets of network properties that might be more specific than network consistent sets of network properties that might be more specific than network
interfaces <xref target="RFC7556"/>.</t> interfaces <xref target="RFC7556"/>.</t>
<t>As with interface instances and types, this property is a set of tu ples of (Enumerated) <t>As with interface instances and types, this property is a set of tu ples of (Enumerated)
PvD identifier and preference. It can either be implemented directly as such, PvD identifier and preference. It can either be implemented directly as such,
or for making one preference available for each interface and interface type or for making one preference available for each interface and interface type
available on the system.</t> available on the system.</t>
<t>The identification of a specific PvD is implementation- and system- specific. <t>The identification of a specific PvD is specific to the implementat ion or system.
<xref target="RFC8801"/> defines how to use an FQDN to identify a PvD when adver tised by <xref target="RFC8801"/> defines how to use an FQDN to identify a PvD when adver tised by
a network, but systems might also use other locally-relevant identifiers a network, but systems might also use other locally relevant identifiers
such as string names or Integers to identify PvDs. As with requiring specific such as string names or Integers to identify PvDs. As with requiring specific
interfaces, requiring a specific PvD strictly limits the path selection.</t> interfaces, requiring a specific PvD strictly limits the path selection.</t>
<t>Categories or types of PvDs are also defined to be implementation- <t>Categories or types of PvDs are also defined to be specific to the
and implementation or system. These can be useful to identify a service that is prov
system-specific. These can be useful to identify a service that is provided by a ided by a
PvD. For example, if an application wants to use a PvD that provides a PvD. For example, if an application wants to use a PvD that provides a
Voice-Over-IP service on a Cellular network, it can use the relevant PvD type to Voice-Over-IP (VoIP) service on a Cellular network, it can use the relevant PvD type to
require a PvD that provides this service, without needing to look up a require a PvD that provides this service, without needing to look up a
particular instance. While this does restrict path selection, it is broader than particular instance. While this does restrict path selection, it is broader than
requiring specific PvD instances or interface instances, and should be preferred requiring specific PvD instances or interface instances and should be preferred
over these options.</t> over these options.</t>
</section> </section>
<section anchor="use-temporary-local-address"> <section anchor="use-temporary-local-address">
<name>Use Temporary Local Address</name> <name>Use Temporary Local Address</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>useTemporaryLocalAddress</t> <t>useTemporaryLocalAddress</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Preference</t> <t>Preference</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Avoid for Listeners and Rendezvous Connections. Prefer for othe r Connections.</t> <t>Avoid for Listeners and Rendezvous Connections; Prefer for othe r Connections</t>
</dd> </dd>
</dl> </dl>
<t>This property allows the application to express a preference for th e use of <t>This property allows the application to express a preference for th e use of
temporary local addresses, sometimes called "privacy" addresses <xref target="RF C8981"/>. temporary local addresses, sometimes called "privacy" addresses <xref target="RF C8981"/>.
Temporary addresses are generally used to prevent linking connections over time Temporary addresses are generally used to prevent linking connections over time
when a stable address, sometimes called "permanent" address, is not needed. when a stable address, sometimes called a "permanent" address, is not needed.
There are some caveats to note when specifying this property. First, if an There are some caveats to note when specifying this property. First, if an
application Requires the use of temporary addresses, the resulting Connection application Requires the use of temporary addresses, the resulting Connection
cannot use IPv4, because temporary addresses do not exist in IPv4. Second, cannot use IPv4 because temporary addresses do not exist in IPv4. Second,
temporary local addresses might involve trading off privacy for performance. temporary local addresses might involve trading off privacy for performance.
For instance, temporary addresses (e.g., <xref target="RFC8981"/>) can interfere with resumption mechanisms For instance, temporary addresses (e.g., <xref target="RFC8981"/>) can interfere with resumption mechanisms
that some protocols rely on to reduce initial latency.</t> that some protocols rely on to reduce initial latency.</t>
</section> </section>
<section anchor="multipath-mode"> <section anchor="multipath-mode">
<name>Multipath Transport</name> <name>Multipath Transport</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>multipath</t> <t>multipath</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Enumeration</t> <t>Enumeration</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Disabled for Connections created through initiate and rendezvou s, Passive for Listeners</t> <t>Disabled for Connections created through initiate and rendezvou s; Passive for Listeners</t>
</dd> </dd>
</dl> </dl>
<t>This property specifies whether and how applications want to take a dvantage of <t>This property specifies whether, and how, applications want to take advantage of
transferring data across multiple paths between the same end hosts. transferring data across multiple paths between the same end hosts.
Using multiple paths allows Connections to migrate between interfaces or aggrega te bandwidth Using multiple paths allows Connections to migrate between interfaces or aggrega te bandwidth
as availability and performance properties change. as availability and performance properties change.
Possible values are:</t> Possible values are as follows:</t>
<dl> <dl>
<dt>Disabled:</dt> <dt>Disabled:</dt>
<dd> <dd>
<t>The Connection will not use multiple paths once established, ev en if the chosen transport supports using multiple paths.</t> <t>The Connection will not use multiple paths once established, ev en if the chosen transport supports using multiple paths.</t>
</dd> </dd>
<dt>Active:</dt> <dt>Active:</dt>
<dd> <dd>
<t>The Connection will negotiate the use of multiple paths if the chosen transport supports this.</t> <t>The Connection will negotiate the use of multiple paths if the chosen transport supports it.</t>
</dd> </dd>
<dt>Passive:</dt> <dt>Passive:</dt>
<dd> <dd>
<t>The Connection will support the use of multiple paths if the Re mote Endpoint requests it.</t> <t>The Connection will support the use of multiple paths if the Re mote Endpoint requests it.</t>
</dd> </dd>
</dl> </dl>
<t>The policy for using multiple paths is specified using the separate <t>The policy for using multiple paths is specified using the separate
<tt>multipathPolicy</tt> property, see <xref target="multipath-policy"/> below. <tt>multipathPolicy</tt> property; see <xref target="multipath-policy"/>.
To enable the peer endpoint to initiate additional paths towards a local address To enable the peer endpoint to initiate additional paths toward a local address
other than the one initially used, it is necessary to set the <tt>advertisesAlt other than the one initially used, it is necessary to set the <tt>advertisesAlta
addr</tt> property (see <xref target="altaddr"/> below).</t> ddr</tt> property (see <xref target="altaddr"/>).</t>
<t>Setting this property to <tt>Active</tt> can have privacy implicati <t>Setting this property to <tt>Active</tt> can have privacy implicati
ons: It enables the transport to establish connectivity using alternate paths th ons. It enables the transport to establish connectivity using alternate paths t
at might result in users being linkable across the multiple paths, even if the < hat might result in users being linkable across the multiple paths, even if the
tt>advertisesAltaddr</tt> property (see <xref target="altaddr"/> below) is set t <tt>advertisesAltaddr</tt> property (see <xref target="altaddr"/>) is set to <tt
o <tt>false</tt>.</t> >false</tt>.</t>
<t>Note that Multipath Transport has no corresponding Selection Proper ty of type Preference. <t>Note that Multipath Transport has no corresponding Selection Proper ty of type Preference.
Enumeration values other than <tt>Disabled</tt> are interpreted as a preference for choosing protocols that can make use of multiple paths. Enumeration values other than <tt>Disabled</tt> are interpreted as a preference for choosing protocols that can make use of multiple paths.
The <tt>Disabled</tt> value implies a requirement not to use multiple paths in p arallel but does not prevent choosing a protocol that is capable of using multip le paths, e.g., it does not prevent choosing TCP, but prevents sending the <tt>M P_CAPABLE</tt> option in the TCP handshake.</t> The <tt>Disabled</tt> value implies a requirement not to use multiple paths in p arallel but does not prevent choosing a protocol that is capable of using multip le paths, e.g., it does not prevent choosing TCP but prevents sending the <tt>MP _CAPABLE</tt> option in the TCP handshake.</t>
</section> </section>
<section anchor="altaddr"> <section anchor="altaddr">
<name>Advertisement of Alternative Addresses</name> <name>Advertisement of Alternative Addresses</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>advertisesAltaddr</t> <t>advertisesAltaddr</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Boolean</t> <t>Boolean</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t><tt>false</tt></t> <t><tt>false</tt></t>
</dd> </dd>
</dl> </dl>
<t>This property specifies whether alternative addresses, e.g., of oth er interfaces, ought to be advertised to the <t>This property specifies whether alternative addresses, e.g., of oth er interfaces, ought to be advertised to the
peer endpoint by the Protocol Stack. Advertising these addresses enables the pee r endpoint to establish additional connectivity, e.g., for Connection migration or using multiple paths.</t> peer endpoint by the Protocol Stack. Advertising these addresses enables the pee r endpoint to establish additional connectivity, e.g., for Connection migration or using multiple paths.</t>
<t>Note that this can have privacy implications because it might resul t in users being linkable across the multiple paths. <t>Note that this can have privacy implications because it might resul t in users being linkable across the multiple paths.
Also, note that setting this to <tt>false</tt> does not prevent the local Transp ort Services system from <em>establishing</em> connectivity using alternate path s (see <xref target="multipath-mode"/> above); it only prevents <em>proactive ad vertisement</em> of addresses.</t> Also, note that setting this to <tt>false</tt> does not prevent the local Transp ort Services system from <em>establishing</em> connectivity using alternate path s (see <xref target="multipath-mode"/>); it only prevents <em>proactive advertis ement</em> of addresses.</t>
</section> </section>
<section anchor="direction-of-communication"> <section anchor="direction-of-communication">
<name>Direction of communication</name> <name>Direction of Communication</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>direction</t> <t>direction</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Enumeration</t> <t>Enumeration</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Bidirectional</t> <t>Bidirectional</t>
</dd> </dd>
</dl> </dl>
<t>This property specifies whether an application wants to use the Con nection for sending and/or receiving data. Possible values are:</t> <t>This property specifies whether an application wants to use the Con nection for sending and/or receiving data. Possible values are as follows:</t>
<dl> <dl>
<dt>Bidirectional:</dt> <dt>Bidirectional:</dt>
<dd> <dd>
<t>The Connection must support sending and receiving data</t> <t>The Connection must support sending and receiving data.</t>
</dd> </dd>
<dt>Unidirectional send:</dt> <dt>Unidirectional send:</dt>
<dd> <dd>
<t>The Connection must support sending data, and the application c annot use the Connection to receive any data</t> <t>The Connection must support sending data, and the application c annot use the Connection to receive any data.</t>
</dd> </dd>
<dt>Unidirectional receive:</dt> <dt>Unidirectional receive:</dt>
<dd> <dd>
<t>The Connection must support receiving data, and the application cannot use the Connection to send any data</t> <t>The Connection must support receiving data, and the application cannot use the Connection to send any data.</t>
</dd> </dd>
</dl> </dl>
<t>Since unidirectional communication can be <t>Since unidirectional communication can be
supported by transports offering bidirectional communication, specifying supported by transports offering bidirectional communication, specifying
unidirectional communication might cause a transport stack that supports unidirectional communication might cause a transport stack that supports
bidirectional communication to be selected.</t> bidirectional communication to be selected.</t>
</section> </section>
<section anchor="prop-soft-error"> <section anchor="prop-soft-error">
<name>Notification of ICMP soft error message arrival</name> <name>Notification of ICMP Soft Error Message Arrival</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>softErrorNotify</t> <t>softErrorNotify</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Preference</t> <t>Preference</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>No Preference</t> <t>No Preference</t>
</dd> </dd>
</dl> </dl>
<t>This property specifies whether an application considers it useful to be <t>This property specifies whether an application considers it useful to be
informed when an ICMP error message arrives that does not force termination of a informed when an ICMP error message arrives that does not force termination of a
connection. When set to <tt>true</tt>, received ICMP errors are available as connection. When set to <tt>true</tt>, received ICMP errors are available as
<tt>SoftError</tt> events, see <xref target="soft-errors"/>. Note that even if a protocol supporting this property is selected, <tt>SoftError</tt> events; see <xref target="soft-errors"/>. Note that even if a protocol supporting this property is selected,
not all ICMP errors will necessarily be delivered, so applications cannot rely not all ICMP errors will necessarily be delivered, so applications cannot rely
upon receiving them <xref target="RFC8085"/>.</t> upon receiving them <xref target="RFC8085"/>.</t>
</section> </section>
<section anchor="active-read-before-send"> <section anchor="active-read-before-send">
<name>Initiating side is not the first to write</name> <name>Initiating Side Is Not the First to Write</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>activeReadBeforeSend</t> <t>activeReadBeforeSend</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Preference</t> <t>Preference</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>No Preference</t> <t>No Preference</t>
</dd> </dd>
</dl> </dl>
<t>The most common client-server communication pattern involves the <t>The most common client-server communication pattern involves the
client actively opening a Connection, then sending data to the server. The client actively opening a Connection, then sending data to the server. The
server listens (passive open), reads, and then answers. This property server listens (passive open), reads, and then answers. This property
specifies whether an application wants to diverge from this pattern -- either specifies whether an application wants to diverge from this pattern by
by actively opening with <tt>Initiate</tt>, immediately followed by reading, or either:</t>
passively opening with <tt>Listen</tt>, <ol><li>actively opening with <tt>Initiate</tt>, immediately followed b
immediately followed by writing. This property is ignored when establishing y reading or</li>
<li>passively opening with <tt>Listen</tt>,
immediately followed by writing.</li>
</ol>
<t>This property is ignored when establishing
connections using <tt>Rendezvous</tt>. connections using <tt>Rendezvous</tt>.
Requiring this property limits the choice of mappings to underlying protocols, Requiring this property limits the choice of mappings to underlying protocols,
which can reduce which can reduce
efficiency. For example, it prevents the Transport Services system from mapping efficiency. For example, it prevents the Transport Services system from mapping
Connections to SCTP streams, where Connections to Stream Control Transmission Protocol (SCTP) streams, where
the first transmitted data takes the role of an active open signal.</t> the first transmitted data takes the role of an active open signal.</t>
</section> </section>
</section> </section>
<section anchor="security-parameters"> <section anchor="security-parameters">
<name>Specifying Security Parameters and Callbacks</name> <name>Specifying Security Parameters and Callbacks</name>
<t>Most security parameters, e.g., TLS ciphersuites, local identity and private key, etc., <t>Most security parameters, e.g., TLS ciphersuites, local identity and private key, etc.,
can be configured statically. Others are dynamically configured during Connectio n establishment. can be configured statically. Others are dynamically configured during Connectio n establishment.
Security parameters and callbacks are partitioned based on their place in the li fetime Security parameters and callbacks are partitioned based on their place in the li fetime
of Connection establishment. Similar to Transport Properties, both parameters an d callbacks of Connection establishment. Similar to Transport Properties, both parameters an d callbacks
are inherited during cloning (see <xref target="groups"/>).</t> are inherited during cloning (see <xref target="groups"/>).</t>
<t>This document specifies an abstract API, which could appear to confli ct with the need <t>This document specifies an abstract API, which could appear to confli ct with the need
for security parameters to be unambiguous. The Transport Services System SHOULD provide reasonable, for security parameters to be unambiguous. The Transport Services System <bcp14> SHOULD</bcp14> provide reasonable,
secure defaults for each enumerated security parameter, such that users of the s ystem secure defaults for each enumerated security parameter, such that users of the s ystem
only need to specify parameters required to establish a secure connection only need to specify parameters required to establish a secure connection
(e.g., <tt>serverCertificate</tt>, <tt>clientCertificate</tt>). Specifying secur ity parameters (e.g., <tt>serverCertificate</tt> or <tt>clientCertificate</tt>). Specifying sec urity parameters
from enumerated values (e.g., specific ciphersuites) might constrain which trans port from enumerated values (e.g., specific ciphersuites) might constrain which trans port
protocols can be selected during Connection establishment.</t> protocols can be selected during Connection establishment.</t>
<t>Security configuration parameters are specified in the pre-establishm ent phase <t>Security configuration parameters are specified in the preestablishme nt phase
and are created as follows:</t> and are created as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
SecurityParameters := NewSecurityParameters() SecurityParameters := NewSecurityParameters()
]]></artwork> ]]></artwork>
<t>Specific parameters are added using a call to <tt>Set()</tt> on the < tt>SecurityParameters</tt>.</t> <t>Specific parameters are added using a call to <tt>Set()</tt> on the < tt>SecurityParameters</tt>.</t>
<t>As with the rest of the Transport Services API, the exact names of pa rameters and/or <t>As with the rest of the Transport Services API, the exact names of pa rameters and/or
values of enumerations (e.g., ciphersuites) used in the security parameters are values of enumerations (e.g., ciphersuites) used in the security parameters are
system- specific to the system or
and implementation-specific, and ought to be chosen to follow the principle of l implementation and ought to be chosen to follow the principle of least
east surprise for users of the platform/language environment in question.</t>
surprise for users of the platform / language environment in question.</t>
<t>For security parameters that are enumerations of known values, such a s TLS <t>For security parameters that are enumerations of known values, such a s TLS
ciphersuites, implementations are responsible for exposing the set of values ciphersuites, implementations are responsible for exposing the set of values
they support. For security parameters that are not simple value types, such they support. For security parameters that are not simple value types, such
as certificates and keys, implementations are responsible for exposing as certificates and keys, implementations are responsible for exposing
types appropriate for the platform / language environment.</t> types appropriate for the platform/language environment.</t>
<t>Applications SHOULD use common safe defaults for values such as TLS c <t>Applications <bcp14>SHOULD</bcp14> use common safe defaults for value
iphersuites s such as TLS ciphersuites
whenever possible. However, as discussed in <xref target="RFC8922"/>, many trans port security protocols whenever possible. However, as discussed in <xref target="RFC8922"/>, many trans port security protocols
require specific security parameters and constraints from the client at the time of require specific security parameters and constraints from the client at the time of
configuration and actively during a handshake.</t> configuration and actively during a handshake.</t>
<t>The set of security parameters defined here is not exhaustive, but il lustrative. <t>The set of security parameters defined here is not exhaustive, but il lustrative.
Implementations SHOULD expose an equivalent to the parameters listed below to al low for Implementations <bcp14>SHOULD</bcp14> expose an equivalent to the parameters lis ted below to allow for
sufficient configuration of security parameters, but the details are expected sufficient configuration of security parameters, but the details are expected
to vary based on platform and implementation constraints. Applications MUST be a ble to vary based on platform and implementation constraints. Applications <bcp14>MU ST</bcp14> be able
to constrain the security protocols and versions that the Transport Services Sys tem to constrain the security protocols and versions that the Transport Services Sys tem
will use.</t> will use.</t>
<t>Representation of security parameters in implementations ought to par allel <t>Representation of security parameters in implementations ought to par allel
that chosen for Transport Property names as suggested in <xref target="scope-of- interface-defn"/>.</t> that chosen for Transport Property names as suggested in <xref target="scope-of- interface-defn"/>.</t>
<t>Connections that use Transport Services SHOULD use security in genera l. However, for <t>Connections that use Transport Services <bcp14>SHOULD</bcp14> use sec urity in general. However, for
compatibility with endpoints that do not support transport security protocols (s uch compatibility with endpoints that do not support transport security protocols (s uch
as a TCP endpoint that does not support TLS), applications can initialize their as a TCP endpoint that does not support TLS), applications can initialize their
security parameters to indicate that security can be disabled, or can be opportu nistic. security parameters to indicate that security can be disabled or opportunistic.
If security is disabled, the Transport Services system will not attempt to add If security is disabled, the Transport Services system will not attempt to add
transport security automatically. If security is opportunistic, it will allow transport security automatically. If security is opportunistic, it will allow
Connections without transport security, but will still attempt to use unauthenti cated Connections without transport security, but it will still attempt to use unauthe nticated
security if available.</t> security if available.</t>
<artwork><![CDATA[ <artwork><![CDATA[
SecurityParameters := NewDisabledSecurityParameters() SecurityParameters := NewDisabledSecurityParameters()
SecurityParameters := NewOpportunisticSecurityParameters() SecurityParameters := NewOpportunisticSecurityParameters()
]]></artwork> ]]></artwork>
<section anchor="allowed-security-protocols"> <section anchor="allowed-security-protocols">
<name>Allowed security protocols</name> <name>Allowed Security Protocols</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>allowedSecurityProtocols</t> <t>allowedSecurityProtocols</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Implementation-specific enumeration of security protocol names and/or versions.</t> <t>Implementation-specific enumeration of security protocol names and/or versions</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Implementation-specific best available security protocols</t> <t>Implementation-specific best available security protocols</t>
</dd> </dd>
</dl> </dl>
<t>This property allows applications to restrict which security protoc ols and security protocol versions can be used in the protocol stack. Applicatio ns MUST be able to constrain the security protocols used by this or an equivalen t mechanism, in order to prevent the use of security protocols with unknown or w eak security properties.</t> <t>This property allows applications to restrict which security protoc ols and security protocol versions can be used in the Protocol Stack. Applicatio ns <bcp14>MUST</bcp14> be able to constrain the security protocols used by this or an equivalent mechanism, in order to prevent the use of security protocols wi th unknown or weak security properties.</t>
<artwork><![CDATA[ <artwork><![CDATA[
SecurityParameters.Set(allowedSecurityProtocols, [ tls_1_2, tls_1_3 ]) SecurityParameters.Set(allowedSecurityProtocols, [ tls_1_2, tls_1_3 ])
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="certificate-bundles"> <section anchor="certificate-bundles">
<name>Certificate bundles</name> <name>Certificate Bundles</name>
<dl> <dl>
<dt>Names:</dt> <dt>Names:</dt>
<dd> <dd>
<t>serverCertificate, clientCertificate</t> <t>serverCertificate, clientCertificate</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Array of certificate objects</t> <t>Array of certificate objects</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Empty array</t> <t>Empty array</t>
</dd> </dd>
</dl> </dl>
<t>One or more certificate bundles identifying the Local Endpoint, whe <t>One or more certificate bundles identifying the Local Endpoint as a
ther server certificate or a client certificate. Multiple bundles may
as a server certificate or a client certificate. Multiple bundles may be provided to allow selection among different Protocol Stacks that may
be provided to allow selection among different protocol stacks that may
require differently formatted bundles. The form and format of the require differently formatted bundles. The form and format of the
certificate bundle is implementation-specific. Note that if the private certificate bundle are implementation specific. Note that if the private
keys associated with a bundle are not available, e.g., since they are stored in keys associated with a bundle are not available, e.g., since they are stored in
hardware Hardware
security modules (HSMs), handshake callbacks are necessary. See below for detail Security Modules (HSMs), handshake callbacks are necessary. See below for detail
s.</t> s.</t>
<artwork><![CDATA[ <artwork><![CDATA[
SecurityParameters.Set(serverCertificate, myCertificateBundle[]) SecurityParameters.Set(serverCertificate, myCertificateBundle[])
SecurityParameters.Set(clientCertificate, myCertificateBundle[]) SecurityParameters.Set(clientCertificate, myCertificateBundle[])
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="pinned-server-certificate"> <section anchor="pinned-server-certificate">
<name>Pinned server certificate</name> <name>Pinned Server Certificate</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>pinnedServerCertificate</t> <t>pinnedServerCertificate</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Array of certificate chain objects</t> <t>Array of certificate chain objects</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Empty array</t> <t>Empty array</t>
</dd> </dd>
</dl> </dl>
<t>Zero or more certificate chains to use as pinned server <t>Zero or more certificate chains to use as pinned server
certificates, such that connecting will fail if the presented server certificates, such that connecting will fail if the presented server
certificate does not match one of the supplied pinned certificates. certificate does not match one of the supplied pinned certificates.
The form and format of the certificate chain is implementation-specific.</t> The form and format of the certificate chain are implementation specific.</t>
<artwork><![CDATA[ <artwork><![CDATA[
SecurityParameters.Set(pinnedServerCertificate, yourCertificateChain[]) SecurityParameters.Set(pinnedServerCertificate, yourCertificateChain[])
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="application-layer-protocol-negotiation"> <section anchor="application-layer-protocol-negotiation">
<name>Application-layer protocol negotiation</name> <name>Application-Layer Protocol Negotiation</name>
<!--[rfced] May we lowercase "Strings" in the following to match the
capping schemes of the other similar subsections?
Original:
Type: Array of Strings
Perhaps:
Type: Array of strings
-->
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>alpn</t> <t>alpn</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Array of Strings</t> <t>Array of Strings</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Automatic selection</t> <t>Automatic selection</t>
</dd> </dd>
</dl> </dl>
<t>Application-layer protocol negotiation (ALPN) values: used to indic ate which <t>Application-Layer Protocol Negotiation (ALPN) values: used to indic ate which
application-layer protocols are negotiated by the security protocol layer. application-layer protocols are negotiated by the security protocol layer.
See <xref target="ALPN"/> for definition of the ALPN field. Note that the Transp See <xref target="RFC7301"/> for a definition of the ALPN field. Note that the T
ort ransport
Services System can provide ALPN values automatically, based on Services System can provide ALPN values automatically based on
the protocols being used, if not explicitly specified by the application.</t> the protocols being used, if not explicitly specified by the application.</t>
<artwork><![CDATA[ <artwork><![CDATA[
SecurityParameters.Set(alpn, ["h2"]) SecurityParameters.Set(alpn, ["h2"])
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="groups-ciphersuites-and-signature-algorithms"> <section anchor="groups-ciphersuites-and-signature-algorithms">
<name>Groups, ciphersuites, and signature algorithms</name> <name>Groups, Ciphersuites, and Signature Algorithms</name>
<dl> <dl>
<dt>Names:</dt> <dt>Names:</dt>
<dd> <dd>
<t>supportedGroup, ciphersuite, signatureAlgorithm</t> <t>supportedGroup, ciphersuite, signatureAlgorithm</t>
</dd> </dd>
<dt>Types:</dt> <dt>Types:</dt>
<dd> <dd>
<t>Arrays of implementation-specific enumerations</t> <t>Arrays of implementation-specific enumerations</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
skipping to change at line 1827 skipping to change at line 2114
<t>These are used to restrict what cryptographic parameters <t>These are used to restrict what cryptographic parameters
are used by underlying transport security protocols. When not specified, are used by underlying transport security protocols. When not specified,
these algorithms should use known and safe defaults for the system.</t> these algorithms should use known and safe defaults for the system.</t>
<artwork><![CDATA[ <artwork><![CDATA[
SecurityParameters.Set(supportedGroup, secp256r1) SecurityParameters.Set(supportedGroup, secp256r1)
SecurityParameters.Set(ciphersuite, TLS_AES_128_GCM_SHA256) SecurityParameters.Set(ciphersuite, TLS_AES_128_GCM_SHA256)
SecurityParameters.Set(signatureAlgorithm, ecdsa_secp256r1_sha256) SecurityParameters.Set(signatureAlgorithm, ecdsa_secp256r1_sha256)
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="session-cache-options"> <section anchor="session-cache-options">
<name>Session cache options</name> <name>Session Cache Options</name>
<dl> <dl>
<dt>Names:</dt> <dt>Names:</dt>
<dd> <dd>
<t>maxCachedSessions, cachedSessionLifetimeSeconds</t> <t>maxCachedSessions, cachedSessionLifetimeSeconds</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Integer</t> <t>Integer</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Automatic selection</t> <t>Automatic selection</t>
</dd> </dd>
</dl> </dl>
<t>These values are used to tune session cache capacity and lifetime, and <t>These values are used to tune session cache capacity and lifetime a nd
can be extended to include other policies.</t> can be extended to include other policies.</t>
<artwork><![CDATA[ <artwork><![CDATA[
SecurityParameters.Set(maxCachedSessions, 16) SecurityParameters.Set(maxCachedSessions, 16)
SecurityParameters.Set(cachedSessionLifetimeSeconds, 3600) SecurityParameters.Set(cachedSessionLifetimeSeconds, 3600)
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="pre-shared-key"> <section anchor="pre-shared-key">
<name>Pre-shared key</name> <name>Pre-Shared Key</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>preSharedKey</t> <t>preSharedKey</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Key and identity (platform-specific)</t> <t>Key and identity (platform specific)</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>None</t> <t>None</t>
</dd> </dd>
</dl> </dl>
<t>Used to install pre-shared keying material established <t>Used to install pre-shared keying material established
out-of-band. Each instance of pre-shared keying material is associated with some identity out of band. Each instance of pre-shared keying material is associated with some identity
that typically identifies its use or has some protocol-specific meaning to the that typically identifies its use or has some protocol-specific meaning to the
Remote Endpoint. Note that use of a pre-shared key will tend to select a single Remote Endpoint. Note that the use of a pre-shared key will tend to select a sin
security protocol, and therefore directly select a single underlying protocol st gle
ack. security protocol and, therefore, directly select a single underlying Protocol S
tack.
A Transport Services API could express <tt>None</tt> in an environment-typical w ay, e.g., as a Union type or special value.</t> A Transport Services API could express <tt>None</tt> in an environment-typical w ay, e.g., as a Union type or special value.</t>
<artwork><![CDATA[ <artwork><![CDATA[
SecurityParameters.Set(preSharedKey, key, myIdentity) SecurityParameters.Set(preSharedKey, key, myIdentity)
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="connection-establishment-callbacks"> <section anchor="connection-establishment-callbacks">
<name>Connection Establishment Callbacks</name> <name>Connection Establishment Callbacks</name>
<t>Security decisions, especially pertaining to trust, are not static. Once configured, <t>Security decisions, especially pertaining to trust, are not static. Once configured,
parameters can also be supplied during Connection establishment. These are best parameters can also be supplied during Connection establishment. These are best
handled as client-provided callbacks. handled as client-provided callbacks.
skipping to change at line 1892 skipping to change at line 2179
Security handshake callbacks that could be invoked during Connection establishme nt include:</t> Security handshake callbacks that could be invoked during Connection establishme nt include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Trust verification callback: Invoked when a Remote Endpoint's t rust must be verified before the <t>Trust verification callback: Invoked when a Remote Endpoint's t rust must be verified before the
handshake protocol can continue. For example, the application could verify an X. 509 certificate handshake protocol can continue. For example, the application could verify an X. 509 certificate
as described in <xref target="RFC5280"/>.</t> as described in <xref target="RFC5280"/>.</t>
</li> </li>
</ul> </ul>
<artwork><![CDATA[ <artwork><![CDATA[
TrustCallback := NewCallback({ TrustCallback := NewCallback({
// Handle trust, return the result // Handle the trust and return the result
}) })
SecurityParameters.SetTrustVerificationCallback(TrustCallback) SecurityParameters.SetTrustVerificationCallback(TrustCallback)
]]></artwork> ]]></artwork>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Identity challenge callback: Invoked when a private key operati on is required, e.g., when <t>Identity challenge callback: Invoked when a private key operati on is required, e.g., when
local authentication is requested by a Remote Endpoint.</t> local authentication is requested by a Remote Endpoint.</t>
</li> </li>
</ul> </ul>
<artwork><![CDATA[ <artwork><![CDATA[
ChallengeCallback := NewCallback({ ChallengeCallback := NewCallback({
// Handle challenge // Handle the challenge
}) })
SecurityParameters.SetIdentityChallengeCallback(ChallengeCallback) SecurityParameters.SetIdentityChallengeCallback(ChallengeCallback)
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
</section> </section>
<section anchor="establishment"> <section anchor="establishment">
<name>Establishing Connections</name> <name>Establishing Connections</name>
<t>Before a Connection can be used for data transfer, it needs to be estab lished. <t>Before a Connection can be used for data transfer, it needs to be estab lished.
Establishment ends the pre-establishment phase; all transport properties and Establishment ends the preestablishment phase; all transport properties and
cryptographic parameter specification must be complete before establishment, cryptographic parameter specification must be complete before establishment,
as these will be used to select candidate Paths and Protocol Stacks as these will be used to select candidate Paths and Protocol Stacks
for the Connection. Establishment can be active, using the <tt>Initiate</tt> act ion; for the Connection. Establishment can be active, using the <tt>Initiate</tt> act ion;
passive, using the <tt>Listen</tt> action; or simultaneous for peer-to-peer, usi ng passive, using the <tt>Listen</tt> action; or simultaneous for peer-to-peer conn ections, using
the <tt>Rendezvous</tt> action. These actions are described in the subsections b elow.</t> the <tt>Rendezvous</tt> action. These actions are described in the subsections b elow.</t>
<section anchor="initiate"> <section anchor="initiate">
<name>Active Open: Initiate</name> <name>Active Open: Initiate</name>
<t>Active open is the action of establishing a Connection to a Remote En dpoint presumed <t>Active open is the action of establishing a Connection to a Remote En dpoint presumed
to be listening for incoming Connection requests. Active open is used by clients in to be listening for incoming Connection requests. Active open is used by clients in
client-server interactions. Active open is supported by the Transport Services A PI through the client-server interactions. Active open is supported by the Transport Services A PI through the
<tt>Initiate</tt> action:</t> <tt>Initiate</tt> action:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection := Preconnection.Initiate(timeout?) Connection := Preconnection.Initiate(timeout?)
]]></artwork> ]]></artwork>
<t>The timeout parameter specifies how long to wait before aborting Acti ve open. <t>The timeout parameter specifies how long to wait before aborting Acti ve open.
Before calling <tt>Initiate</tt>, the caller must have populated a Preconnection Before calling <tt>Initiate</tt>, the caller must have populated a Preconnection
object with a Remote Endpoint object to identify the endpoint, optionally a Loca l Endpoint object with a Remote Endpoint object to identify the endpoint, optionally a Loca l Endpoint
object (if not specified, the system will attempt to determine a object (if not specified, the system will attempt to determine a
suitable Local Endpoint), as well as all properties suitable Local Endpoint), as well as all properties
necessary for candidate selection.</t> necessary for candidate selection.</t>
<t>The <tt>Initiate</tt> action returns a Connection object. Once <tt>In itiate</tt> has been <t>The <tt>Initiate</tt> action returns a Connection object. Once <tt>In itiate</tt> has been
called, any changes to the Preconnection MUST NOT have any effect on the called, any changes to the Preconnection <bcp14>MUST NOT</bcp14> have any effect on the
Connection. However, the Preconnection can be reused, e.g., to <tt>Initiate</tt> Connection. However, the Preconnection can be reused, e.g., to <tt>Initiate</tt>
another Connection.</t> another Connection.</t>
<!--[rfced] Please confirm that "multiple candidates" is intended
instead of "multiple connections" (or Connections?). Or is
another rephrase desirable (e.g., "could be sent multiple times
or using multiple candidates")?
Original:
...note that any data marked as "safely replayable" that is sent while
the Connection is being established could be sent multiple times or on
multiple candidates.
-->
<t>Once <tt>Initiate</tt> is called, the candidate Protocol Stack(s) can cause one or more <t>Once <tt>Initiate</tt> is called, the candidate Protocol Stack(s) can cause one or more
candidate transport-layer connections to be created to the specified Remote candidate transport-layer connections to be created to the specified Remote
Endpoint. The caller could immediately begin sending Messages on the Connection Endpoint. The caller could immediately begin sending Messages on the Connection
(see <xref target="sending"/>) after calling <tt>Initiate</tt>; note that any da ta marked as "safely replayable" that is sent (see <xref target="sending"/>) after calling <tt>Initiate</tt>; note that any da ta marked as "safely replayable" that is sent
while the Connection is being established could be sent multiple times or on while the Connection is being established could be sent multiple times or on
multiple candidates.</t> multiple candidates.</t>
<t>The following events can be sent by the Connection after <tt>Initiate </tt> is called:</t> <t>The following events can be sent by the Connection after <tt>Initiate </tt> is called:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection -> Ready<> Connection -> Ready<>
]]></artwork> ]]></artwork>
<t>The <tt>Ready</tt> event occurs after <tt>Initiate</tt> has establish ed a transport-layer <t>The <tt>Ready</tt> event occurs after <tt>Initiate</tt> has establish ed a transport-layer
connection on at least one usable candidate Protocol Stack over at least one connection on at least one usable candidate Protocol Stack over at least one
candidate Path. No <tt>Receive</tt> events (see <xref target="receiving"/>) will occur before candidate Path. No <tt>Receive</tt> events (see <xref target="receiving"/>) will occur before
the <tt>Ready</tt> event for Connections established using <tt>Initiate</tt>.</t > the <tt>Ready</tt> event for Connections established using <tt>Initiate</tt>.</t >
<artwork><![CDATA[ <artwork><![CDATA[
Connection -> EstablishmentError<reason?> Connection -> EstablishmentError<reason?>
]]></artwork> ]]></artwork>
<t>An <tt>EstablishmentError</tt> occurs either when the set of transpor <t>An <tt>EstablishmentError</tt> occurs when:</t>
t properties and security <ul spacing="normal">
<li>the set of transport properties and security
parameters cannot be fulfilled on a Connection for initiation (e.g., the set of parameters cannot be fulfilled on a Connection for initiation (e.g., the set of
available Paths and/or Protocol Stacks meeting the constraints is empty) or available Paths and/or Protocol Stacks meeting the constraints is empty) or
reconciled with the Local and/or Remote Endpoints; when a remote Endpoint Identi reconciled with the Local and/or Remote Endpoints,</li>
fier <li>a Remote Endpoint Identifier cannot be resolved, or</li>
cannot be resolved; or when no transport-layer connection can be established to <li>no transport-layer connection can be established to
the Remote Endpoint (e.g., because the Remote Endpoint is not accepting the Remote Endpoint (e.g., because the Remote Endpoint is not accepting
connections, the application is prohibited from opening a Connection by the connections, the application is prohibited from opening a Connection by the
operating system, or the establishment attempt has timed out for any other reaso operating system, or the establishment attempt has timed out for any other reaso
n).</t> n).</li>
</ul>
<t>Connection establishment <t>Connection establishment
and transmission of the first Message can be combined in a single action (<xref target="initiate-and-send"/>).</t> and transmission of the first Message can be combined in a single action (<xref target="initiate-and-send"/>).</t>
</section> </section>
<section anchor="listen"> <section anchor="listen">
<name>Passive Open: Listen</name> <name>Passive Open: Listen</name>
<t>Passive open is the action of waiting for Connections from Remote End points, <t>Passive open is the action of waiting for Connections from Remote End points,
commonly used by servers in client-server interactions. Passive open is commonly used by servers in client-server interactions. Passive open is
supported by the Transport Services API through the <tt>Listen</tt> action and r eturns a Listener object:</t> supported by the Transport Services API through the <tt>Listen</tt> action and r eturns a Listener object:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Listener := Preconnection.Listen() Listener := Preconnection.Listen()
]]></artwork> ]]></artwork>
<t>Before calling <tt>Listen</tt>, the caller must have initialized the Preconnection <t>Before calling <tt>Listen</tt>, the caller must have initialized the Preconnection
during the pre-establishment phase with a Local Endpoint object, as well during the preestablishment phase with a Local Endpoint object, as well
as all properties necessary for Protocol Stack selection. A Remote Endpoint as all properties necessary for Protocol Stack selection. A Remote Endpoint
can optionally be specified, to constrain what Connections are accepted.</t> can optionally be specified, to constrain what Connections are accepted.</t>
<t>The <tt>Listen</tt> action returns a Listener object. Once <tt>Listen </tt> has been called, <t>The <tt>Listen</tt> action returns a Listener object. Once <tt>Listen </tt> has been called,
any changes to the Preconnection MUST NOT have any effect on the Listener. The any changes to the Preconnection <bcp14>MUST NOT</bcp14> have any effect on the Listener. The
Preconnection can be disposed of or reused, e.g., to create another Listener.</t > Preconnection can be disposed of or reused, e.g., to create another Listener.</t >
<artwork><![CDATA[ <artwork><![CDATA[
Listener.Stop() Listener.Stop()
]]></artwork> ]]></artwork>
<t>Listening continues until the global context shuts down, or until the Stop <t>Listening continues until the global context shuts down or until the Stop
action is performed on the Listener object.</t> action is performed on the Listener object.</t>
<artwork><![CDATA[ <artwork><![CDATA[
Listener -> ConnectionReceived<Connection> Listener -> ConnectionReceived<Connection>
]]></artwork> ]]></artwork>
<t>The <tt>ConnectionReceived</tt> event occurs when a Remote Endpoint h <t>The <tt>ConnectionReceived</tt> event occurs when:</t>
as established or cloned (e.g., by creating a new stream in a multi-stream trans <ul spacing="normal">
port; see <xref target="groups"/>) a <li>a Remote Endpoint has established or cloned (e.g., by creating a ne
w stream in a multi-stream transport; see <xref target="groups"/>) a
transport-layer connection to this Listener (for Connection-oriented transport-layer connection to this Listener (for Connection-oriented
transport protocols), or when the first Message has been received from the transport protocols), or</li>
Remote Endpoint (for Connectionless protocols or streams of a multi-streaming tr <li>the first Message has been received from the
ansport), causing a new Connection to be Remote Endpoint (for Connectionless protocols or streams of a multi-streaming tr
created. The resulting Connection is contained within the <tt>ConnectionReceived ansport) causing a new Connection to be
</tt> created.</li>
event, and is ready to use as soon as it is passed to the application via the </ul>
<t>The resulting Connection is contained within the <tt>ConnectionReceiv
ed</tt>
event and is ready to use as soon as it is passed to the application via the
event.</t> event.</t>
<artwork><![CDATA[ <artwork><![CDATA[
Listener.SetNewConnectionLimit(value) Listener.SetNewConnectionLimit(value)
]]></artwork> ]]></artwork>
<t>If the caller wants to rate-limit the number of inbound Connections t hat will be delivered, <t>If the caller wants to rate-limit the number of inbound Connections t hat will be delivered,
it can set a cap using <tt>SetNewConnectionLimit</tt>. This mechanism allows a s erver to it can set a cap using <tt>SetNewConnectionLimit</tt>. This mechanism allows a s erver to
protect itself from being drained of resources. Each time a new Connection is de livered protect itself from being drained of resources. Each time a new Connection is de livered
by the <tt>ConnectionReceived</tt> event, the value is automatically decremented . Once the by the <tt>ConnectionReceived</tt> event, the value is automatically decremented . Once the
value reaches zero, no further Connections will be delivered until the caller se ts the value reaches zero, no further Connections will be delivered until the caller se ts the
limit to a higher value. By default, this value is Infinite. The caller is also able to reset limit to a higher value. By default, this value is Infinite. The caller is also able to reset
the value to Infinite at any point.</t> the value to Infinite at any point.</t>
<artwork><![CDATA[ <artwork><![CDATA[
Listener -> EstablishmentError<reason?> Listener -> EstablishmentError<reason?>
]]></artwork> ]]></artwork>
<t>An <tt>EstablishmentError</tt> occurs either when the Properties and <t>An <tt>EstablishmentError</tt> occurs when:</t>
security parameters of the Preconnection cannot be fulfilled for listening or ca <ul spacing="normal">
nnot be reconciled with the Local Endpoint (and/or Remote Endpoint, if specified <li>the Properties and security parameters of the Preconnection cannot
), when the Local Endpoint (or Remote Endpoint, if specified) cannot be fulfilled for listening or cannot be reconciled with the Local Endpoint (and/
be resolved, or when the application is prohibited from listening by policy.</t> or Remote Endpoint, if specified),</li>
<li>the Local Endpoint (or Remote Endpoint, if specified) cannot
be resolved, or</li>
<li>the application is prohibited from listening by policy.</li>
</ul>
<artwork><![CDATA[ <artwork><![CDATA[
Listener -> Stopped<> Listener -> Stopped<>
]]></artwork> ]]></artwork>
<t>A <tt>Stopped</tt> event occurs after the Listener has stopped listen ing.</t> <t>A <tt>Stopped</tt> event occurs after the Listener has stopped listen ing.</t>
</section> </section>
<section anchor="rendezvous"> <section anchor="rendezvous">
<name>Peer-to-Peer Establishment: Rendezvous</name> <name>Peer-to-Peer Establishment: Rendezvous</name>
<t>Simultaneous peer-to-peer Connection establishment is supported by th e <t>Simultaneous peer-to-peer Connection establishment is supported by th e
<tt>Rendezvous</tt> action:</t> <tt>Rendezvous</tt> action:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Preconnection.Rendezvous() Preconnection.Rendezvous()
]]></artwork> ]]></artwork>
<t>A Preconnection object used in a <tt>Rendezvous</tt> MUST have both t he <t>A Preconnection object used in a <tt>Rendezvous</tt> <bcp14>MUST</bcp 14> have both the
Local Endpoint candidates and the Remote Endpoint candidates specified, Local Endpoint candidates and the Remote Endpoint candidates specified,
along with the Transport Properties and security parameters needed for along with the Transport Properties and security parameters needed for
Protocol Stack selection, before the <tt>Rendezvous</tt> action is initiated.</t > Protocol Stack selection before the <tt>Rendezvous</tt> action is initiated.</t>
<t>The <tt>Rendezvous</tt> action listens on the Local Endpoint <t>The <tt>Rendezvous</tt> action listens on the Local Endpoint
candidates for an incoming Connection from the Remote Endpoint candidates, candidates for an incoming Connection from the Remote Endpoint candidates,
while also simultaneously trying to establish a Connection from the Local while also simultaneously trying to establish a Connection from the Local
Endpoint candidates to the Remote Endpoint candidates.</t> Endpoint candidates to the Remote Endpoint candidates.</t>
<t>If there are multiple Local Endpoints or Remote Endpoints configured, then <t>If there are multiple Local Endpoints or Remote Endpoints configured, then
initiating a <tt>Rendezvous</tt> action will cause the Transport Services initiating a <tt>Rendezvous</tt> action will cause the Transport Services
Implementation to systematically probe the reachability Implementation to systematically probe the reachability
of those endpoint candidates following an approach such as that used in of those endpoint candidates following an approach such as that used in
Interactive Connectivity Establishment (ICE) <xref target="RFC8445"/>.</t> Interactive Connectivity Establishment (ICE) <xref target="RFC8445"/>.</t>
<t>If the endpoints are suspected to be behind a NAT, and the Local Endp oint <t>If the endpoints are suspected to be behind a NAT, and the Local Endp oint
supports a method of discovering NAT bindings, such as Session Traversal supports a method of discovering NAT bindings, such as STUN <xref target="RFC848
Utilities for NAT (STUN) <xref target="RFC8489"/> or Traversal Using Relays arou 9"/> or Traversal Using Relays around NAT
nd NAT
(TURN) <xref target="RFC8656"/>, then the <tt>Resolve</tt> action on the Preconn ection can be (TURN) <xref target="RFC8656"/>, then the <tt>Resolve</tt> action on the Preconn ection can be
used to discover such bindings:</t> used to discover such bindings:</t>
<artwork><![CDATA[ <artwork><![CDATA[
[]LocalEndpoint, []RemoteEndpoint := Preconnection.Resolve() []LocalEndpoint, []RemoteEndpoint := Preconnection.Resolve()
]]></artwork> ]]></artwork>
<t>The <tt>Resolve</tt> call returns lists of Local Endpoints and Remote Endpoints <t>The <tt>Resolve</tt> call returns lists of Local Endpoints and Remote Endpoints
that represent the concrete addresses, local and server reflexive, on which that represent the concrete addresses, local and server reflexive, on which
a <tt>Rendezvous</tt> for the Preconnection will listen for incoming Connections , a <tt>Rendezvous</tt> for the Preconnection will listen for incoming Connections
and to which it will attempt to establish Connections.</t> and to which it will attempt to establish Connections.</t>
<t>Note that the set of Local Endpoints returned by <tt>Resolve</tt> mig ht or might not <t>Note that the set of Local Endpoints returned by <tt>Resolve</tt> mig ht or might not
contain information about all possible local interfaces depending on how the contain information about all possible local interfaces, depending on how the
Preconnection is configured. The set of available local interfaces can also Preconnection is configured. The set of available local interfaces can also
change over time so care needs to be taken when using stored interface names.</t > change over time, so care needs to be taken when using stored interface names.</ t>
<t>An application that uses <tt>Rendezvous</tt> to establish a peer-to-p eer Connection <t>An application that uses <tt>Rendezvous</tt> to establish a peer-to-p eer Connection
in the presence of NATs will configure the Preconnection object with at least in the presence of NATs will configure the Preconnection object with at least
one Local Endpoint that supports NAT binding discovery. It will then <tt>Resolve </tt> one Local Endpoint that supports NAT binding discovery. It will then <tt>Resolve </tt>
the Preconnection, and pass the resulting list of Local Endpoint candidates to the Preconnection and pass the resulting list of Local Endpoint candidates to
the peer via a signalling protocol, for example as part of an ICE <xref target=" the peer via a signaling protocol, for example, as part of an ICE exchange <xref
RFC8445"/> target="RFC8445"/>
exchange within SIP <xref target="RFC3261"/> or WebRTC <xref target="RFC7478"/>. within SIP <xref target="RFC3261"/> or WebRTC <xref target="RFC7478"/>. The pee
The peer will then, r will then,
via the same signalling channel, return the Remote Endpoint candidates. via the same signaling channel, return the Remote Endpoint candidates.
The set of Remote Endpoint candidates are then configured onto the Preconnection The set of Remote Endpoint candidates is then configured on the Preconnection:</
:</t> t>
<artwork><![CDATA[ <artwork><![CDATA[
Preconnection.AddRemote([]RemoteEndpoint) Preconnection.AddRemote([]RemoteEndpoint)
]]></artwork> ]]></artwork>
<t>The <tt>Rendezvous</tt> action is initiated, and causes the Transport <t>Once the application has
Services
Implementation to begin connectivity checks, once the application has
added both the Local Endpoint candidates and the Remote Endpoint candidates added both the Local Endpoint candidates and the Remote Endpoint candidates
retrieved from the peer via the signalling channel to the Preconnection.</t> retrieved from the peer via the signaling channel to the Preconnection,
the <tt>Rendezvous</tt> action is initiated and causes the Transport Services
Implementation to begin connectivity checks.</t>
<t>If successful, the <tt>Rendezvous</tt> action returns a Connection ob ject via a <t>If successful, the <tt>Rendezvous</tt> action returns a Connection ob ject via a
<tt>RendezvousDone&lt;&gt;</tt> event:</t> <tt>RendezvousDone&lt;&gt;</tt> event:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Preconnection -> RendezvousDone<Connection> Preconnection -> RendezvousDone<Connection>
]]></artwork> ]]></artwork>
<t>The <tt>RendezvousDone&lt;&gt;</tt> event occurs when a Connection is established with the <t>The <tt>RendezvousDone&lt;&gt;</tt> event occurs when a Connection is established with the
Remote Endpoint. For Connection-oriented transports, this occurs when the Remote Endpoint. For Connection-oriented transports, this occurs when the
transport-layer connection is established; for Connectionless transports, transport-layer connection is established; for Connectionless transports,
it occurs when the first Message is received from the Remote Endpoint. The it occurs when the first Message is received from the Remote Endpoint. The
resulting Connection is contained within the <tt>RendezvousDone&lt;&gt;</tt> eve nt, and is resulting Connection is contained within the <tt>RendezvousDone&lt;&gt;</tt> eve nt and is
ready to use as soon as it is passed to the application via the event. ready to use as soon as it is passed to the application via the event.
Changes made to a Preconnection after <tt>Rendezvous</tt> has been called MUST Changes made to a Preconnection after <tt>Rendezvous</tt> has been called <bcp14
NOT have any effect on existing Connections.</t> >MUST
<t>An <tt>EstablishmentError</tt> occurs either when the Properties and NOT</bcp14> have any effect on existing Connections.</t>
Security <t>An <tt>EstablishmentError</tt> occurs when:</t>
<ul spacing="normal">
<li>the Properties and Security
Parameters of the Preconnection cannot be fulfilled for rendezvous or Parameters of the Preconnection cannot be fulfilled for rendezvous or
cannot be reconciled with the Local and/or Remote Endpoints, when the Local cannot be reconciled with the Local and/or Remote Endpoints,</li>
Endpoint or Remote Endpoint cannot be resolved, when no transport-layer <li>the Local
connection can be established to the Remote Endpoint, or when the Endpoint or Remote Endpoint cannot be resolved,</li>
application is prohibited from rendezvous by policy:</t> <li>no transport-layer
connection can be established to the Remote Endpoint, or</li>
<li>the
application is prohibited from rendezvous by policy.</li>
</ul>
<artwork><![CDATA[ <artwork><![CDATA[
Preconnection -> EstablishmentError<reason?> Preconnection -> EstablishmentError<reason?>
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="groups"> <section anchor="groups">
<name>Connection Groups</name> <name>Connection Groups</name>
<t>Connection Groups can be created using the <tt>Clone</tt> action:</t> <t>Connection Groups can be created using the <tt>Clone</tt> action:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection := Connection.Clone(framer?, connectionProperties?) Connection := Connection.Clone(framer?, connectionProperties?)
]]></artwork> ]]></artwork>
<t>Calling <tt>Clone</tt> on a Connection yields a Connection Group cont aining two Connections: the parent <t>Calling <tt>Clone</tt> on a Connection yields a Connection Group cont aining two Connections: the parent
Connection on which <tt>Clone</tt> was called, and a resulting cloned Connection . Connection on which <tt>Clone</tt> was called and a resulting cloned Connection.
The new Connection is actively opened, and it will locally send a <tt>Ready</tt> event or an <tt>EstablishmentError</tt> event. The new Connection is actively opened, and it will locally send a <tt>Ready</tt> event or an <tt>EstablishmentError</tt> event.
Calling <tt>Clone</tt> on any of these Connections adds another Connection to Calling <tt>Clone</tt> on any of these Connections adds another Connection to
the Connection Group. Connections in a Connection Group share all the Connection Group. Connections in a Connection Group share all
Connection Properties except <tt>connPriority</tt> (see <xref target="conn-prior ity"/>), Connection Properties except <tt>connPriority</tt> (see <xref target="conn-prior ity"/>),
and these Connection Properties are entangled: Changing one of the and these Connection Properties are entangled: changing one of the
Connection Properties on one Connection in the Connection Group Connection Properties on one Connection in the Connection Group
automatically changes the Connection Property for all others. For example, chang ing automatically changes the Connection Property for all others. For example, chang ing
<tt>connTimeout</tt> (see <tt>connTimeout</tt> (see
<xref target="conn-timeout"/>) on one Connection in a Connection Group will auto matically <xref target="conn-timeout"/>) on one Connection in a Connection Group will auto matically
make the same change to this Connection Property for all other Connections in th e Connection Group. make the same change to this Connection Property for all other Connections in th e Connection Group.
Like all other Properties, <tt>connPriority</tt> is copied Like all other Properties, <tt>connPriority</tt> is copied
to the new Connection when calling <tt>Clone</tt>, but in this case, a later cha nge to the to the new Connection when calling <tt>Clone</tt>, but, in this case, a later ch ange to the
<tt>connPriority</tt> on one Connection does not change it on the <tt>connPriority</tt> on one Connection does not change it on the
other Connections in the same Connection Group.</t> other Connections in the same Connection Group.</t>
<t>The optional <tt>connectionProperties</tt> parameter allows passing <t>The optional <tt>connectionProperties</tt> parameter allows passing
Transport Properties that control the behavior of the underlying stream or conne ction to be created, e.g., Protocol-specific Properties to request specific stre am IDs for SCTP or QUIC.</t> Transport Properties that control the behavior of the underlying stream or conne ction to be created, e.g., Protocol-specific Properties to request specific stre am IDs for SCTP or QUIC.</t>
<t>Message Properties set on a Connection also apply only to that Connec tion.</t> <t>Message Properties set on a Connection also apply only to that Connec tion.</t>
<t>A new Connection created by <tt>Clone</tt> can have a Message Framer assigned via the optional <t>A new Connection created by <tt>Clone</tt> can have a Message Framer assigned via the optional
<tt>framer</tt> parameter of the <tt>Clone</tt> action. If this parameter is not supplied, the <tt>framer</tt> parameter of the <tt>Clone</tt> action. If this parameter is not supplied, the
stack of Message Framers associated with a Connection is copied to stack of Message Framers associated with a Connection is copied to
the cloned Connection when calling <tt>Clone</tt>. Then, a cloned Connection the cloned Connection when calling <tt>Clone</tt>. Then, a cloned Connection
has the same stack of Message Framers as the Connection from which they has the same stack of Message Framers as the Connection from which they
are cloned, but these Framers can internally maintain per-Connection state.</t> are cloned, but these Framers can internally maintain per-Connection state.</t>
<t>It is also possible to check which Connections belong to the same Con nection Group. <t>It is also possible to check which Connections belong to the same Con nection Group.
Calling <tt>GroupedConnections</tt> on a specific Connection returns a set of al l Connections Calling <tt>GroupedConnections</tt> on a specific Connection returns a set of al l Connections
in the same group.</t> in the same group.</t>
<artwork><![CDATA[ <artwork><![CDATA[
[]Connection := Connection.GroupedConnections() []Connection := Connection.GroupedConnections()
]]></artwork> ]]></artwork>
<t>Connections will belong to the same group if the application previous ly called <tt>Clone</tt>. <t>Connections will belong to the same group if the application previous ly called <tt>Clone</tt>.
Passive Connections can also be added to the same group -- e.g., when a Listener Passive Connections can also be added to the same group, e.g., when a Listener
receives a new Connection that is just a new stream of an already active multi-s receives a new Connection that is just a new stream of an already-active multi-s
treaming treaming
protocol instance.</t> protocol instance.</t>
<t>If the underlying protocol supports multi-streaming, it is natural to use this <t>If the underlying protocol supports multi-streaming, it is natural to use this
functionality to implement <tt>Clone</tt>. In that case, Connections in a Connec tion Group are functionality to implement <tt>Clone</tt>. In that case, Connections in a Connec tion Group are
multiplexed together, giving them similar treatment not only inside Endpoints, multiplexed together, giving them similar treatment not only inside Endpoints,
but also across the end-to-end Internet path.</t> but also across the end-to-end Internet path.</t>
<t>Note that calling <tt>Clone</tt> can result in on-the-wire signaling, e.g., to open a new <t>Note that calling <tt>Clone</tt> can result in on-the-wire signaling, e.g., to open a new
transport connection, depending on the underlying Protocol Stack. When <tt>Clone </tt> leads to transport connection, depending on the underlying Protocol Stack. When <tt>Clone </tt> leads to
the opening of multiple such connections, the opening of multiple such connections,
the Transport Services system will ensure consistency of the Transport Services system will ensure consistency of
Connection Properties by uniformly applying them to all underlying connections Connection Properties by uniformly applying them to all underlying connections
in a group. Even in such a case, there are possibilities for a Transport Service in a group. Even in such a case, it is possible for a Transport Services system
s system to implement prioritization within a Connection Group (see <xref target="TCP-COU
to implement prioritization within a Connection Group <xref target="TCP-COUPLING PLING"/> and <xref target="RFC8699"/>).</t>
"/> <xref target="RFC8699"/>.</t>
<t>Attempts to clone a Connection can result in a <tt>CloneError</tt>:</ t> <t>Attempts to clone a Connection can result in a <tt>CloneError</tt>:</ t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection -> CloneError<reason?> Connection -> CloneError<reason?>
]]></artwork> ]]></artwork>
<t>A <tt>CloneError</tt> can also occur later, after <tt>Clone</tt> was successfully called. In this case, <t>A <tt>CloneError</tt> can also occur later, after <tt>Clone</tt> was successfully called. In this case,
it informs the application that the Connection that sends the <tt>CloneError</tt > is no longer a it informs the application that the Connection that sends the <tt>CloneError</tt > is no longer a
part of any Connection Group. For example, this can occur when the Transport Ser vices part of any Connection Group. For example, this can occur when the Transport Ser vices
system is unable to implement entanglement (a Connection Property was changed on a different system is unable to implement entanglement (a Connection Property was changed on a different
Connection in the Connection Group, but this change could not be successfully ap plied Connection in the Connection Group, but this change could not be successfully ap plied
to the Connection that sends the <tt>CloneError</tt>).</t> to the Connection that sends the <tt>CloneError</tt>).</t>
<t>The <tt>connPriority</tt> Connection Property operates on Connections in a Connection Group <t>The <tt>connPriority</tt> Connection Property operates on Connections in a Connection Group
using the same approach as in <xref target="msg-priority"/>: when allocating ava ilable network using the same approach as that used in <xref target="msg-priority"/>: when allo cating available network
capacity among Connections in a Connection Group, sends on Connections with capacity among Connections in a Connection Group, sends on Connections with
numerically lower Priority values will be prioritized over sends on Connections that have numerically lower Priority values will be prioritized over sends on Connections that have
numerically higher Priority values. Capacity will be shared among these Connecti ons according to numerically higher Priority values. Capacity will be shared among these Connecti ons according to
the <tt>connScheduler</tt> property (<xref target="conn-scheduler"/>). the <tt>connScheduler</tt> property (<xref target="conn-scheduler"/>).
See <xref target="priority-in-taps"/> for more.</t> See <xref target="priority-in-taps"/> for more details.</t>
</section> </section>
<section anchor="add-endpoints"> <section anchor="add-endpoints">
<name>Adding and Removing Endpoints on a Connection</name> <name>Adding and Removing Endpoints on a Connection</name>
<t>Transport protocols that are explicitly multipath aware are expected to automatically <t>Transport protocols that are explicitly multipath aware are expected to automatically
manage the set of Remote Endpoints that they are communicating with, and the pat hs to manage the set of Remote Endpoints that they are communicating with and the path s to
those endpoints. A <tt>PathChange&lt;&gt;</tt> event, described in <xref target= "conn-path-change"/>, will be those endpoints. A <tt>PathChange&lt;&gt;</tt> event, described in <xref target= "conn-path-change"/>, will be
generated when the path changes.</t> generated when the path changes.</t>
<t>In some cases, however, it is necessary to explicitly indicate to a C <t>However, in some cases, it is necessary to explicitly indicate to a C
onnection that onnection that
a new Remote Endpoint has become available for use, or to indicate that a Remote a new Remote Endpoint has become available for use or indicate that a Remote
Endpoint is no longer available. This is most common in the case of peer to peer Endpoint is no longer available. This is most common in the case of peer-to-peer
connections using Trickle ICE <xref target="RFC8838"/>.</t> connections using Trickle ICE <xref target="RFC8838"/>.</t>
<t>The <tt>AddRemote</tt> action can be used to add one or more new Remo te Endpoints <t>The <tt>AddRemote</tt> action can be used to add one or more new Remo te Endpoints
to a Connection:</t> to a Connection:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection.AddRemote([]RemoteEndpoint) Connection.AddRemote([]RemoteEndpoint)
]]></artwork> ]]></artwork>
<t>Endpoints that are already known to the Connection are ignored. A cal l to <t>Endpoints that are already known to the Connection are ignored. A cal l to
<tt>AddRemote</tt> makes the new Remote Endpoints available to the Connection, <tt>AddRemote</tt> makes the new Remote Endpoints available to the Connection,
but whether the Connection makes use of those Endpoints will depend on the but whether the Connection makes use of those Endpoints will depend on the
underlying transport protocol.</t> underlying transport protocol.</t>
<t>Similarly, the <tt>RemoveRemote</tt> action can be used to tell a Con nection to <t>Similarly, the <tt>RemoveRemote</tt> action can be used to tell a Con nection to
stop using one or more Remote Endpoints:</t> stop using one or more Remote Endpoints:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection.RemoveRemote([]RemoteEndpoint) Connection.RemoveRemote([]RemoteEndpoint)
]]></artwork> ]]></artwork>
<t>Removing all known Remote Endpoints can have the effect of aborting t he <t>Removing all known Remote Endpoints can have the effect of aborting t he
connection. The effect of removing the active Remote Endpoint(s) depends connection. The effect of removing the active Remote Endpoint(s) depends
on the underlying transport: multipath aware transports might be able to on the underlying transport: multipath-aware transports might be able to
switch to a new path if other reachable Remote Endpoints exist, or the switch to a new path if other reachable Remote Endpoints exist or the
connection might abort.</t> connection might abort.</t>
<t>Similarly, the <tt>AddLocal</tt> and <tt>RemoveLocal</tt> actions can be used to add <t>Similarly, the <tt>AddLocal</tt> and <tt>RemoveLocal</tt> actions can be used to add
and remove Local Endpoints to/from a Connection.</t> and remove Local Endpoints to or from a Connection.</t>
</section> </section>
</section> </section>
<section anchor="introspection"> <section anchor="introspection">
<name>Managing Connections</name> <name>Managing Connections</name>
<t>During pre-establishment and after establishment, (Pre-)Connections can be configured and queried using Connection <t>During preestablishment and after establishment, Preconnections or Conn ections can be configured and queried using Connection
Properties, and asynchronous information could be available about the state of t he Properties, and asynchronous information could be available about the state of t he
Connection via <tt>SoftError</tt> events.</t> Connection via <tt>SoftError</tt> events.</t>
<t>Connection Properties represent the configuration and state of the sele cted <t>Connection Properties represent the configuration and state of the sele cted
Protocol Stack(s) backing a Connection. These Connection Properties can be Protocol Stack(s) backing a Connection. These Connection Properties can be
generic, applying regardless of transport protocol, or specific, applicable to a generic (applying regardless of transport protocol) or specific (applicable to a
single implementation of a single transport Protocol Stack. Generic Connection single implementation of a single transport Protocol Stack). Generic Connection
Properties are defined in <xref target="connection-props"/> below.</t> Properties are defined in <xref target="connection-props"/>.</t>
<t>Protocol-specific Properties are defined in a transport- and <t>Protocol-specific Properties are defined in a way that is specific to t
implementation-specific way to he transport or implementation to
permit more specialized protocol features to be used. permit more specialized protocol features to be used.
Too much reliance by an application on Protocol-specific Properties can signific antly reduce the flexibility Too much reliance by an application on Protocol-specific Properties can signific antly reduce the flexibility
of a transport services system to make appropriate of a Transport Services system to make appropriate
selection and configuration choices. Therefore, it is RECOMMENDED that selection and configuration choices. Therefore, it is <bcp14>RECOMMENDED</bcp14>
Generic Connection Properties are used for properties common across different pr that
otocols and that Generic Connection Properties be used for properties common across different pro
tocols and that
Protocol-specific Connection Properties are only used where specific protocols o r properties are necessary.</t> Protocol-specific Connection Properties are only used where specific protocols o r properties are necessary.</t>
<t>The application can set and query Connection Properties on a per-Connec tion <t>The application can set and query Connection Properties on a per-Connec tion
basis. Connection Properties that are not read-only can be set during basis. Connection Properties that are not read-only can be set during
pre-establishment (see <xref target="selection-props"/>), as well as on Connecti ons directly using preestablishment (see <xref target="selection-props"/>), as well as on Connectio ns directly using
the <tt>SetProperty</tt> action:</t> the <tt>SetProperty</tt> action:</t>
<artwork><![CDATA[ <artwork><![CDATA[
ErrorCode := Connection.SetProperty(property, value) ErrorCode := Connection.SetProperty(property, value)
]]></artwork> ]]></artwork>
<t>If an error is encountered in setting a property (for example, if the a pplication tries to set a TCP-specific property on a Connection that is not usin g TCP), the application MUST be informed about this error via the <tt>ErrorCode< /tt> Object. Such errors MUST NOT cause the Connection to be terminated. <t>If an error is encountered in setting a property (for example, if the a pplication tries to set a TCP-specific property on a Connection that is not usin g TCP), the application <bcp14>MUST</bcp14> be informed about this error via the <tt>ErrorCode</tt> Object. Such errors <bcp14>MUST NOT</bcp14> cause the Connec tion to be terminated.
Note that changing one of the Connection Properties on one Connection in a Conne ction Group Note that changing one of the Connection Properties on one Connection in a Conne ction Group
will also change it for all other Connections of that group; see further <xref t will also change it for all other Connections of that group; see <xref target="g
arget="groups"/>.</t> roups"/>.</t>
<t>At any point, the application can query Connection Properties.</t> <t>At any point, the application can query Connection Properties.</t>
<!--[rfced] Please review if the last line should be included in the
artwork tag.
Original:
At any point, the application can query Connection Properties.
ConnectionProperties := Connection.GetProperties()
value := ConnectionProperties.Get(property)
if ConnectionProperties.Has(boolean_or_preference_property) then ...
Depending on the status of the Connection, the queried Connection
Properties will include different information:
Perhaps:
At any point, the application can query Connection Properties.
ConnectionProperties := Connection.GetProperties()
value := ConnectionProperties.Get(property)
If ConnectionProperties.Has(boolean_or_preference_property), then,
depending on the status of the Connection, the queried Connection
Properties will include different information:
-->
<artwork><![CDATA[ <artwork><![CDATA[
ConnectionProperties := Connection.GetProperties() ConnectionProperties := Connection.GetProperties()
value := ConnectionProperties.Get(property) value := ConnectionProperties.Get(property)
if ConnectionProperties.Has(boolean_or_preference_property) then ... if ConnectionProperties.Has(boolean_or_preference_property) then...
]]></artwork> ]]></artwork>
<t>Depending on the status of the Connection, the queried Connection <t>Depending on the status of the Connection, the queried Connection
Properties will include different information:</t> Properties will include different information:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The Connection state, which can be one of the following: <t>The Connection state, which can be one of the following:
Establishing, Established, Closing, or Closed (see <xref target="conn-state"/>). </t> Establishing, Established, Closing, or Closed (see <xref target="conn-state"/>). </t>
</li> </li>
<li> <li>
<t>Whether the Connection can be used to send data (see <xref target=" conn-send-data"/>). <t>Whether the Connection can be used to send data (see <xref target=" conn-send-data"/>).
A Connection can not be used A Connection cannot be used
for sending if the Connection was created with the Selection Property for sending if the Connection was created with the Selection Property
<tt>direction</tt> set to <tt>unidirectional receive</tt> or if a Message <tt>direction</tt> set to <tt>unidirectional receive</tt> or if a Message
marked as <tt>Final</tt> was sent over this Connection. See also <xref target="m sg-final"/>.</t> marked as <tt>Final</tt> was sent over this Connection. See also <xref target="m sg-final"/>.</t>
</li> </li>
<li> <li>
<t>Whether the Connection can be used to receive data (see <xref targe t="conn-receive-data"/>). <t>Whether the Connection can be used to receive data (see <xref targe t="conn-receive-data"/>).
A Connection cannot be A Connection cannot be
used for receiving if the Connection was created with the Selection Property used for receiving if the Connection was created with the Selection Property
<tt>direction</tt> set to <tt>unidirectional send</tt> or if a Message <tt>direction</tt> set to <tt>unidirectional send</tt> or if a Message
marked as <tt>Final</tt> was received. See <xref target="receiving-final-message marked as <tt>Final</tt> was received (see <xref target="receiving-final-message
s"/>. The latter s"/>). The latter
is only supported by certain transport protocols, e.g., by TCP as half-closed is only supported by certain transport protocols, e.g., by TCP as a half-closed
connection.</t> connection.</t>
</li> </li>
<li> <li>
<t>For Connections that are Established, Closing, or Closed: <t>For Connections that are Established, Closing, or Closed:
Connection Properties (<xref target="connection-props"/>) of the Connection Properties (<xref target="connection-props"/>) of the
actual protocols that were selected and instantiated, and Selection actual protocols that were selected and instantiated, and Selection
Properties that the application specified on the Preconnection. Properties that the application specified on the Preconnection.
Selection Properties of type <tt>Preference</tt> will be exposed as boolean valu es Selection Properties of type <tt>Preference</tt> will be exposed as boolean valu es
indicating whether or not the property applies to the selected transport. indicating whether or not the property applies to the selected transport.
Note that the instantiated Protocol Stack might not match all Note that the instantiated Protocol Stack might not match all
Protocol Selection Properties that the application specified on the Protocol Selection Properties that the application specified on the
Preconnection.</t> Preconnection.</t>
</li> </li>
<li> <li>
<t>For Connections that are Established: Transport Services system imp lementations <t>For Connections that are Established: Transport Services system imp lementations
ought to provide information concerning the ought to provide information concerning the
path(s) used by the Protocol Stack. This can be derived from local PVD informati on, path(s) used by the Protocol Stack. This can be derived from local PvD informati on,
measurements by the Protocol Stack, or other sources. measurements by the Protocol Stack, or other sources.
For example, a Transport System that is configured to receive and process PVD in formation For example, a transport system that is configured to receive and process PvD in formation
<xref target="RFC7556"/> could also provide network configuration information fo r the chosen path(s).</t> <xref target="RFC7556"/> could also provide network configuration information fo r the chosen path(s).</t>
</li> </li>
</ul> </ul>
<section anchor="connection-props"> <section anchor="connection-props">
<name>Generic Connection Properties</name> <name>Generic Connection Properties</name>
<t>Generic Connection Properties are defined independent of the chosen P <t>Generic Connection Properties are defined independently of the chosen
rotocol Stack Protocol Stack; therefore, they are available on all Connections.</t>
and therefore available on all Connections.</t>
<t>Many Connection Properties have a corresponding Selection Property th at <t>Many Connection Properties have a corresponding Selection Property th at
enables applications to express their preference for protocols providing a suppo rting transport feature.</t> enables applications to express their preference for protocols providing a suppo rting transport feature.</t>
<section anchor="conn-recv-checksum"> <section anchor="conn-recv-checksum">
<name>Required Minimum Corruption Protection Coverage for Receiving</n ame> <name>Required Minimum Corruption Protection Coverage for Receiving</n ame>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>recvChecksumLen</t> <t>recvChecksumLen</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
skipping to change at line 2346 skipping to change at line 2690
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Numeric (positive) or <tt>Disabled</tt></t> <t>Numeric (positive) or <tt>Disabled</tt></t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t><tt>Disabled</tt></t> <t><tt>Disabled</tt></t>
</dd> </dd>
</dl> </dl>
<!--[rfced] Would the following update be acceptable? Something seems
off about "adjusting...will only take effect".
Original:
Adjusting this property will only take effect when the underlying
stack supports sending keep-alive packets.
Perhaps:
Adjustments to this property will only take effect when the underlying
stack supports sending keep-alive packets.
-->
<t>If this property is Numeric, it specifies how long to wait before d eciding that an active Connection has <t>If this property is Numeric, it specifies how long to wait before d eciding that an active Connection has
failed when trying to reliably deliver data to the Remote Endpoint. Adjusting th is property failed when trying to reliably deliver data to the Remote Endpoint. Adjusting th is property
will only take effect when the underlying stack supports reliability. If this pr operty has the enumerated will only take effect when the underlying stack supports reliability. If this pr operty has the enumerated
value <tt>Disabled</tt>, it means that no timeout is scheduled. A Transport Serv ices API value <tt>Disabled</tt>, it means that no timeout is scheduled. A Transport Serv ices API
could express <tt>Disabled</tt> in an environment-typical way, e.g., as a Union type or special value.</t> could express <tt>Disabled</tt> in an environment-typical way, e.g., as a Union type or special value.</t>
</section> </section>
<section anchor="keep-alive-timeout"> <section anchor="keep-alive-timeout">
<name>Timeout for keep alive packets</name> <name>Timeout for Keep-Alive Packets</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>keepAliveTimeout</t> <t>keepAliveTimeout</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Numeric (positive) or <tt>Disabled</tt></t> <t>Numeric (positive) or <tt>Disabled</tt></t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t><tt>Disabled</tt></t> <t><tt>Disabled</tt></t>
</dd> </dd>
</dl> </dl>
<t>A Transport Services API can request a protocol that supports sendi ng keep alive packets (<xref target="keep-alive"/>). <t>A Transport Services API can request a protocol that supports sendi ng keep-alive packets (<xref target="keep-alive"/>).
If this property is Numeric, it specifies the maximum length of time an idle Con nection (one for which no transport If this property is Numeric, it specifies the maximum length of time an idle Con nection (one for which no transport
packets have been sent) ought to wait before packets have been sent) ought to wait before
the Local Endpoint sends a keep-alive packet to the Remote Endpoint. Adjusting t his property the Local Endpoint sends a keep-alive packet to the Remote Endpoint. Adjusting t his property
will only take effect when the underlying stack supports sending keep-alive pack ets. will only take effect when the underlying stack supports sending keep-alive pack ets.
Guidance on setting this value for connection-less transports is Guidance on setting this value for connectionless transports is
provided in <xref target="RFC8085"/>. provided in <xref target="RFC8085"/>.
A value greater than the Connection timeout (<xref target="conn-timeout"/>) or t he enumerated value <tt>Disabled</tt> will disable the sending of keep-alive pac kets. A Transport Services API A value greater than the Connection timeout (<xref target="conn-timeout"/>) or t he enumerated value <tt>Disabled</tt> will disable the sending of keep-alive pac kets. A Transport Services API
could express <tt>Disabled</tt> in an environment-typical way, e.g., as a Union type or special value.</t> could express <tt>Disabled</tt> in an environment-typical way, e.g., as a Union type or special value.</t>
</section> </section>
<section anchor="conn-scheduler"> <section anchor="conn-scheduler">
<name>Connection Group Transmission Scheduler</name> <name>Connection Group Transmission Scheduler</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>connScheduler</t> <t>connScheduler</t>
skipping to change at line 2396 skipping to change at line 2754
<dd> <dd>
<t>Enumeration</t> <t>Enumeration</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Weighted Fair Queueing (see <xref section="3.6" sectionFormat=" of" target="RFC8260"/>)</t> <t>Weighted Fair Queueing (see <xref section="3.6" sectionFormat=" of" target="RFC8260"/>)</t>
</dd> </dd>
</dl> </dl>
<t>This property specifies which scheduler is used among Connections w ithin <t>This property specifies which scheduler is used among Connections w ithin
a Connection Group to apportion the available capacity according to Connection p riorities a Connection Group to apportion the available capacity according to Connection p riorities
(see <xref target="groups"/> and <xref target="conn-priority"/>). A set of sched ulers is (see Sections&nbsp;<xref target="groups" format="counter"/> and <xref target="co nn-priority" format="counter"/>). A set of schedulers is
described in <xref target="RFC8260"/>.</t> described in <xref target="RFC8260"/>.</t>
</section> </section>
<section anchor="prop-cap-profile"> <section anchor="prop-cap-profile">
<name>Capacity Profile</name> <name>Capacity Profile</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>connCapacityProfile</t> <t>connCapacityProfile</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Enumeration</t> <t>Enumeration</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Default Profile (Best Effort)</t> <t>Default Profile (Best Effort)</t>
</dd> </dd>
</dl> </dl>
<t>This property specifies the desired network treatment for traffic s ent by the <t>This property specifies the desired network treatment for traffic s ent by the
application and the tradeoffs the application is prepared to make in path and application and the trade-offs the application is prepared to make in path and
protocol selection to receive that desired treatment. When the capacity profile protocol selection to receive that desired treatment. When the capacity profile
is set to a value other than Default, the Transport Services system SHOULD selec is set to a value other than Default, the Transport Services system <bcp14>SHOUL
t paths D</bcp14> select paths
and configure protocols to optimize the tradeoff between delay, delay variation, and configure protocols to optimize the trade-off between delay, delay variation
and , and
efficient use of the available capacity based on the capacity profile specified. How this is realized efficient use of the available capacity based on the capacity profile specified. How this is realized
is implementation-specific. The capacity profile MAY also be used is implementation specific. The capacity profile <bcp14>MAY</bcp14> also be used
to set markings on the wire for Protocol Stacks supporting this. to set markings on the wire for Protocol Stacks supporting this action.
Recommendations for use with DSCP are provided below for each profile; note that Recommendations for use with DSCPs are provided below for each profile; note tha
t
when a Connection is multiplexed, the guidelines in <xref section="6" sectionFor mat="of" target="RFC7657"/> apply.</t> when a Connection is multiplexed, the guidelines in <xref section="6" sectionFor mat="of" target="RFC7657"/> apply.</t>
<t>The following values are valid for the capacity profile:</t> <t>The following values are valid for the capacity profile:</t>
<dl> <dl>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>The application provides no information about its expected capa city <t>The application provides no information about its expected capa city
profile. Transport Services systems that profile. Transport Services systems that
map the requested capacity profile onto per-connection DSCP signaling map the requested capacity profile to per-connection DSCP signaling
SHOULD assign the DSCP Default Forwarding <xref target="RFC2474"/> Per Hop Beh <bcp14>SHOULD</bcp14> assign the DSCP Default Forwarding Per Hop Behavior (PHB
aviour (PHB).</t> ) <xref target="RFC2474"/>.</t>
</dd> </dd>
<dt>Scavenger:</dt> <dt>Scavenger:</dt>
<dd> <dd>
<t>The application is not interactive. It expects to send <t>The application is not interactive. It expects to send
and/or receive data without any urgency. This can, for example, be used to and/or receive data without any urgency. This can, for example, be used to
select Protocol Stacks with scavenger transmission control and/or to assign select Protocol Stacks with scavenger transmission control and/or to assign
the traffic to a lower-effort service. Transport Services systems that the traffic to a lower-effort service. Transport Services systems that
map the requested capacity profile onto per-connection DSCP signaling map the requested capacity profile to per-connection DSCP signaling
SHOULD assign the DSCP Less than Best Effort <bcp14>SHOULD</bcp14> assign the DSCP "Less than best effort" PHB
<xref target="RFC8622"/> PHB.</t> <xref target="RFC8622"/>.</t>
</dd> </dd>
<dt>Low Latency/Interactive:</dt> <dt>Low Latency/Interactive:</dt>
<!--[rfced] We had a few questions about the following text:
Original:
This can be used by the system to disable the coalescing of multiple
small Messages into larger packets (Nagle's algorithm);..
a) How may we clarify the use of "This"?
b) Should a citation point the reader to more information on Nagle's
algorithm?
-->
<dd> <dd>
<t>The application is interactive, and prefers loss to <t>The application is interactive and prefers loss to
latency. Response time SHOULD be optimized at the expense of delay variation latency. Response time <bcp14>SHOULD</bcp14> be optimized at the expense of de
lay variation
and efficient use of the available capacity when sending on this Connection. T his can be and efficient use of the available capacity when sending on this Connection. T his can be
used by the system to disable the coalescing of multiple small Messages into used by the system to disable the coalescing of multiple small Messages into
larger packets (Nagle's algorithm); to prefer immediate acknowledgment from larger packets (Nagle's algorithm); to prefer immediate acknowledgement from
the peer endpoint when supported by the underlying transport; and so on. the peer endpoint when supported by the underlying transport; and so on.
Transport Services systems that map the requested capacity profile onto per-co nnection DSCP signaling without multiplexing SHOULD assign a DSCP Assured Forwar ding (AF41,AF42,AF43,AF44) <xref target="RFC2597"/> PHB. Inelastic traffic that is expected to conform to the configured network service rate could be mapped to the DSCP Expedited Forwarding <xref target="RFC3246"/> or <xref target="RFC5865 "/> PHBs.</t> Transport Services systems that map the requested capacity profile to per-conn ection DSCP signaling without multiplexing <bcp14>SHOULD</bcp14> assign a DSCP A ssured Forwarding (AF41,AF42,AF43,AF44) PHB <xref target="RFC2597"/>. Inelastic traffic that is expected to conform to the configured network service rate could be mapped to the DSCP Expedited Forwarding PHBs <xref target="RFC3246"/> or PHB s as discussed in <xref target="RFC5865"/>.</t>
</dd> </dd>
<dt>Low Latency/Non-Interactive:</dt> <dt>Low Latency/Non-Interactive:</dt>
<dd> <dd>
<t>The application prefers loss to latency, but is <t>The application prefers loss to latency but is
not interactive. Response time SHOULD be optimized at the expense of delay not interactive. Response time <bcp14>SHOULD</bcp14> be optimized at the expen
se of delay
variation and efficient use of the available capacity when sending on this Con nection. Transport variation and efficient use of the available capacity when sending on this Con nection. Transport
system implementations that map the requested capacity profile onto system implementations that map the requested capacity profile to
per-connection DSCP signaling without multiplexing SHOULD assign a DSCP per-connection DSCP signaling without multiplexing <bcp14>SHOULD</bcp14> assig
Assured Forwarding (AF21,AF22,AF23,AF24) <xref target="RFC2597"/> PHB.</t> n a DSCP
Assured Forwarding (AF21,AF22,AF23,AF24) PHB <xref target="RFC2597"/>.</t>
</dd> </dd>
<dt>Constant-Rate Streaming:</dt> <dt>Constant-Rate Streaming:</dt>
<dd> <dd>
<t>The application expects to send/receive data at a <t>The application expects to send/receive data at a
constant rate after Connection establishment. Delay and delay variation SHOULD constant rate after Connection establishment. Delay and delay variation <bcp14 >SHOULD</bcp14>
be minimized at the expense of efficient use of the available capacity. be minimized at the expense of efficient use of the available capacity.
This implies that the Connection might fail if the Path is unable to maintain the desired rate. This implies that the Connection might fail if the Path is unable to maintain the desired rate.
A transport can interpret this capacity profile as preferring a circuit A transport can interpret this capacity profile as preferring a circuit
breaker <xref target="RFC8084"/> to a rate-adaptive congestion controller. Tra nsport breaker <xref target="RFC8084"/> to a rate-adaptive congestion controller. Tra nsport
system implementations that map the requested capacity profile onto system implementations that map the requested capacity profile to
per-connection DSCP signaling without multiplexing SHOULD assign a DSCP per-connection DSCP signaling without multiplexing <bcp14>SHOULD</bcp14> assig
Assured Forwarding (AF31,AF32,AF33,AF34) <xref target="RFC2597"/> PHB.</t> n a DSCP
Assured Forwarding (AF31,AF32,AF33,AF34) PHB <xref target="RFC2597"/>.</t>
</dd> </dd>
<dt>Capacity-Seeking:</dt> <dt>Capacity-Seeking:</dt>
<dd> <dd>
<t>The application expects to send/receive data at the <t>The application expects to send/receive data at the
maximum rate allowed by its congestion controller over a relatively long maximum rate allowed by its congestion controller over a relatively long
period of time. Transport Services systems that map the requested period of time. Transport Services systems that map the requested
capacity profile onto per-connection DSCP signaling without multiplexing capacity profile to per-connection DSCP signaling without multiplexing
SHOULD assign a DSCP Assured Forwarding (AF11,AF12,AF13,AF14) <xref target="RF <bcp14>SHOULD</bcp14> assign a DSCP Assured Forwarding (AF11,AF12,AF13,AF14) P
C2597"/> PHB HB <xref target="RFC2597"/>
per <xref section="4.8" sectionFormat="of" target="RFC4594"/>.</t> per <xref section="4.8" sectionFormat="of" target="RFC4594"/>.</t>
</dd> </dd>
</dl> </dl>
<t>The capacity profile for a selected Protocol Stack may be modified on a <t>The capacity profile for a selected Protocol Stack may be modified on a
per-Message basis using the Transmission Profile Message Property; see per-Message basis using the Transmission Profile Message Property; see
<xref target="send-profile"/>.</t> <xref target="send-profile"/>.</t>
</section> </section>
<section anchor="multipath-policy"> <section anchor="multipath-policy">
<name>Policy for using Multipath Transports</name> <name>Policy for Using Multipath Transports</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>multipathPolicy</t> <t>multipathPolicy</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Enumeration</t> <t>Enumeration</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>Handover</t> <t>Handover</t>
</dd> </dd>
</dl> </dl>
<t>This property specifies the local policy for transferring data acro ss multiple paths between the same end hosts if Multipath Transport is not set t o Disabled (see <xref target="multipath-mode"/>). Possible values are:</t> <t>This property specifies the local policy for transferring data acro ss multiple paths between the same end hosts if Multipath Transport is not set t o Disabled (see <xref target="multipath-mode"/>). Possible values are as follows :</t>
<dl> <dl>
<dt>Handover:</dt> <dt>Handover:</dt>
<dd> <dd>
<t>The Connection ought only to attempt to migrate between differe nt paths when the original path is lost or becomes unusable. The thresholds used to declare a path unusable are implementation specific.</t> <t>The Connection ought only to attempt to migrate between differe nt paths when the original path is lost or becomes unusable. The thresholds used to declare a path unusable are implementation specific.</t>
</dd> </dd>
<dt>Interactive:</dt> <dt>Interactive:</dt>
<dd> <dd>
<t>The Connection ought only to attempt to minimize the latency fo r interactive traffic patterns by transmitting data across multiple paths when t his is beneficial. <t>The Connection ought only to attempt to minimize the latency fo r interactive traffic patterns by transmitting data across multiple paths when t his is beneficial.
The goal of minimizing the latency will be balanced against the cost of each of these paths. Depending on the cost of the The goal of minimizing the latency will be balanced against the cost of each of these paths. Depending on the cost of the
lower-latency path, the scheduling might choose to use a higher-latency path. Tr affic can be scheduled such that data may be transmitted lower-latency path, the scheduling might choose to use a higher-latency path. Tr affic can be scheduled such that data may be transmitted
on multiple paths in parallel to achieve a lower latency. The specific schedulin g algorithm is implementation-specific.</t> on multiple paths in parallel to achieve a lower latency. The specific schedulin g algorithm is implementation specific.</t>
</dd> </dd>
<dt>Aggregate:</dt> <dt>Aggregate:</dt>
<dd> <dd>
<t>The Connection ought to attempt to use multiple paths in parall el to maximize available capacity and possibly overcome the capacity limitations of the individual paths. The actual strategy is implementation specific.</t> <t>The Connection ought to attempt to use multiple paths in parall el to maximize available capacity and possibly overcome the capacity limitations of the individual paths. The actual strategy is implementation specific.</t>
</dd> </dd>
</dl> </dl>
<t>Note that this is a local choice – the Remote Endpoint can choose a different policy.</t> <t>Note that this is a local choice: the Remote Endpoint can choose a different policy.</t>
</section> </section>
<section anchor="bounds-on-send-or-receive-rate"> <section anchor="bounds-on-send-or-receive-rate">
<name>Bounds on Send or Receive Rate</name> <name>Bounds on Send or Receive Rate</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>minSendRate / minRecvRate / maxSendRate / maxRecvRate</t> <t>minSendRate / minRecvRate / maxSendRate / maxRecvRate</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Numeric (positive) or <tt>Unlimited</tt> / Numeric (positive) o r <tt>Unlimited</tt> / Numeric (positive) or <tt>Unlimited</tt> / Numeric (posit ive) or <tt>Unlimited</tt></t> <t>Numeric (positive) or <tt>Unlimited</tt> / Numeric (positive) o r <tt>Unlimited</tt> / Numeric (positive) or <tt>Unlimited</tt> / Numeric (posit ive) or <tt>Unlimited</tt></t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t><tt>Unlimited</tt> / <tt>Unlimited</tt> / <tt>Unlimited</tt> / <tt>Unlimited</tt></t> <t><tt>Unlimited</tt> / <tt>Unlimited</tt> / <tt>Unlimited</tt> / <tt>Unlimited</tt></t>
</dd> </dd>
</dl> </dl>
<t>Numeric values of these properties specify an upper-bound rate that a transfer is not expected to <t>Numeric values of these properties specify an upper-bound rate that a transfer is not expected to
exceed (even if flow control and congestion control allow higher rates), and/or a exceed (even if flow control and congestion control allow higher rates) and/or a
lower-bound application-layer rate below which the application does not deem lower-bound application-layer rate below which the application does not deem
it will be useful. These rate values are measured at the application layer, i.e. it will be useful. These rate values are measured at the application layer, i.e.
do not consider the header overhead , do not consider the header overhead
from protocols used by the Transport Services system. The values are specified i from protocols used by the Transport Services system. The values are specified i
n bits per second, n bits per second
and assumed to be measured over one-second time intervals. E.g., specifying a ma and assumed to be measured over one-second time intervals. For example, specifyi
xSendRate of X bits per second ng a maxSendRate of X bits per second
means that, from the moment at which the property value is chosen, not more than means that, from the moment at which the property value is chosen, not more than
X bits will be send in any X bits will be sent in any
following second. The enumerated value <tt>Unlimited</tt> indicates that no boun d is specified. following second. The enumerated value <tt>Unlimited</tt> indicates that no boun d is specified.
A Transport Services API could express <tt>Unlimited</tt> in an environment-typi cal way, e.g., as a Union type or special value.</t> A Transport Services API could express <tt>Unlimited</tt> in an environment-typi cal way, e.g., as a Union type or special value.</t>
</section> </section>
<section anchor="group-connection-limit"> <section anchor="group-connection-limit">
<name>Group Connection Limit</name> <name>Group Connection Limit</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>groupConnLimit</t> <t>groupConnLimit</t>
</dd> </dd>
skipping to change at line 2595 skipping to change at line 2967
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t><tt>false</tt></t> <t><tt>false</tt></t>
</dd> </dd>
</dl> </dl>
<t>When set to <tt>true</tt>, this property will initiate new Connecti ons using as little <t>When set to <tt>true</tt>, this property will initiate new Connecti ons using as little
cached information (such as session tickets or cookies) as possible from cached information (such as session tickets or cookies) as possible from
previous Connections that are not in the same Connection Group. Any state genera ted by this previous Connections that are not in the same Connection Group. Any state genera ted by this
Connection will only be shared with Connections in the same Connection Group. Cl oned Connections Connection will only be shared with Connections in the same Connection Group. Cl oned Connections
will use saved state from within the Connection Group. will use saved state from within the Connection Group.
This is used for separating Connection Contexts as specified in <xref section="4 This is used for separating Connection Contexts as specified in <xref s
.2.3" sectionFormat="of" target="I-D.ietf-taps-arch"/>.</t> ection="4.2.3" sectionFormat="of" target="RFC9621"/>.</t>
<!--[rfced] May we update as follows or does this update change the
meaning?
Original:
Note that this does not guarantee no leakage of information, as
implementations might not be able to fully isolate all caches (e.g.
RTT estimates).
Perhaps:
Note that this does not guarantee that information has not leaked, as
implementations might not be able to fully isolate all caches (e.g.,
RTT estimates).
-->
<t>Note that this does not guarantee no leakage of information, as <t>Note that this does not guarantee no leakage of information, as
implementations might not be able to fully isolate all caches (e.g. RTT implementations might not be able to fully isolate all caches (e.g., RTT
estimates). Note that this property could degrade Connection performance.</t> estimates). Note that this property could degrade Connection performance.</t>
</section> </section>
<section anchor="read-only-conn-prop"> <section anchor="read-only-conn-prop">
<name>Read-only Connection Properties</name> <name>Read-Only Connection Properties</name>
<t>The following generic Connection Properties are read-only, i.e. the <t>The following generic Connection Properties are read-only, i.e., th
y cannot be changed by an application.</t> ey cannot be changed by an application.</t>
<section anchor="conn-state"> <section anchor="conn-state">
<name>Connection state</name> <name>Connection State</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>connState</t> <t>connState</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Enumeration</t> <t>Enumeration</t>
</dd> </dd>
</dl> </dl>
<t>This property informs about the current state of the Connection. Possible values are: <tt>Establishing</tt>, <tt>Established</tt>, <tt>Closing</t t> or <tt>Closed</tt>; for more details on Connection state, see <xref target="s tate-ordering"/>.</t> <t>This property provides information about the current state of the Connection. Possible values are <tt>Establishing</tt>, <tt>Established</tt>, <t t>Closing</tt>, or <tt>Closed</tt>. For more details on Connection state, see <x ref target="state-ordering"/>.</t>
</section> </section>
<section anchor="conn-send-data"> <section anchor="conn-send-data">
<name>Can Send Data</name> <name>Can Send Data</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>canSend</t> <t>canSend</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
skipping to change at line 2662 skipping to change at line 3049
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Integer (non-negative) or <tt>Not applicable</tt></t> <t>Integer (non-negative) or <tt>Not applicable</tt></t>
</dd> </dd>
</dl> </dl>
<t>This property, if applicable, represents the maximum Message size that can be <t>This property, if applicable, represents the maximum Message size that can be
sent without incurring network-layer fragmentation at the sender. sent without incurring network-layer fragmentation at the sender.
It is specified as a number of bytes and is less than or equal to the It is specified as a number of bytes and is less than or equal to the
Maximum Message Size on Send. Maximum Message Size on Send.
It exposes a readable value to the application It exposes a readable value to the application
based on the Maximum Packet Size (MPS). The value of this property can change ov er time (and can be updated by Datagram PLPMTUD <xref target="RFC8899"/>). based on the Maximum Packet Size (MPS). The value of this property can change ov er time (and can be updated via Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) <xref target="RFC8899"/>).
This value allows a sending stack to avoid unwanted fragmentation at the This value allows a sending stack to avoid unwanted fragmentation at the
network-layer or segmentation by the transport layer before network layer or segmentation by the transport layer before
choosing the message size and/or after a <tt>SendError</tt> occurs indicating choosing the message size and/or after a <tt>SendError</tt> occurs indicating
an attempt to send a Message that is too large. A Transport Services API an attempt to send a Message that is too large. A Transport Services API
could express <tt>Not applicable</tt> in an environment-typical way, e.g., as a Union type or special value (e.g., 0).</t> could express <tt>Not applicable</tt> in an environment-typical way, e.g., as a Union type or special value (e.g., 0).</t>
</section> </section>
<section anchor="conn-max-msg-send"> <section anchor="conn-max-msg-send">
<name>Maximum Message Size on Send</name> <name>Maximum Message Size on Send</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>sendMsgMaxLen</t> <t>sendMsgMaxLen</t>
skipping to change at line 2702 skipping to change at line 3089
<dd> <dd>
<t>Integer (non-negative)</t> <t>Integer (non-negative)</t>
</dd> </dd>
</dl> </dl>
<t>This property represents the maximum Message size that an applica tion can receive. <t>This property represents the maximum Message size that an applica tion can receive.
It is specified as the number of bytes. A value of 0 indicates that receiving is not possible.</t> It is specified as the number of bytes. A value of 0 indicates that receiving is not possible.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="tcp-uto"> <section anchor="tcp-uto">
<name>TCP-specific Properties: User Timeout Option (UTO)</name> <name>TCP-Specific Properties: User Timeout Option (UTO)</name>
<t>These properties specify configurations for the TCP User Timeout Opti on (UTO). <t>These properties specify configurations for the TCP User Timeout Opti on (UTO).
This is a TCP-specific property, that is only used This is a TCP-specific property that is only used
in the case that TCP becomes the chosen transport protocol in the case that TCP becomes the chosen transport protocol.
and useful only if TCP is implemented in the Transport Services system. It is useful only if TCP is implemented in the Transport Services system.
Protocol-specific options could also be defined for other transport protocols.</ t> Protocol-specific options could also be defined for other transport protocols.</ t>
<t>These are included here because the feature <tt>Suggest <t>These properties are included here because the feature <tt>Suggest
timeout to the peer</tt> is part of the minimal set of transport services timeout to the peer</tt> is part of the minimal set of Transport Services
<xref target="RFC8923"/>, where this feature was categorized as "functional". <xref target="RFC8923"/>, where this feature was categorized as "functional".
This means that when a Transport Services system offers this feature, This means that when a Transport Services system offers this feature,
the Transport Services API has to expose an interface to the application. Otherw ise, the implementation might the Transport Services API has to expose an interface to the application. Otherw ise, the implementation might
violate assumptions by the application, which could cause the application to violate assumptions by the application, which could cause the application to
fail.</t> fail.</t>
<t>All of the below properties are optional (e.g., it is possible to spe cify <tt>User Timeout Enabled</tt> as <tt>true</tt>, <t>All of the below properties are optional (e.g., it is possible to spe cify <tt>User Timeout Enabled</tt> as <tt>true</tt>
but not specify an Advertised User Timeout value; in this case, the TCP default will be used). but not specify an Advertised User Timeout value; in this case, the TCP default will be used).
These properties reflect the API extension specified in <xref section="3" sectio nFormat="of" target="RFC5482"/>.</t> These properties reflect the API extension specified in <xref section="3" sectio nFormat="of" target="RFC5482"/>.</t>
<section anchor="advertised-user-timeout"> <section anchor="advertised-user-timeout">
<name>Advertised User Timeout</name> <name>Advertised User Timeout</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>tcp.userTimeoutValue</t> <t>tcp.userTimeoutValue</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Integer (positive)</t> <t>Integer (positive)</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>the TCP default</t> <t>the TCP default</t>
</dd> </dd>
</dl> </dl>
<t>This time value is advertised via the TCP User Timeout Option (UTO) <xref target="RFC5482"/> to the Remote Endpoint which can use it to adapt its o wn <tt>Timeout for aborting Connection</tt> (see <xref target="conn-timeout"/>) value.</t> <t>This time value is advertised via the TCP User Timeout Option (UTO) <xref target="RFC5482"/> to the Remote Endpoint, which can use it to adapt its own <tt>Timeout for aborting the Connection</tt> (see <xref target="conn-timeout "/>) value.</t>
</section> </section>
<section anchor="user-timeout-enabled"> <section anchor="user-timeout-enabled">
<name>User Timeout Enabled</name> <name>User Timeout Enabled</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>tcp.userTimeoutEnabled</t> <t>tcp.userTimeoutEnabled</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Boolean</t> <t>Boolean</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t><tt>false</tt></t> <t><tt>false</tt></t>
</dd> </dd>
</dl> </dl>
<t>This property controls whether the TCP UTO option is enabled for a <t>This property controls whether the TCP UTO is enabled for a
connection. This applies to both sending and receiving.</t> connection. This applies to both sending and receiving.</t>
</section> </section>
<section anchor="timeout-changeable"> <section anchor="timeout-changeable">
<name>Timeout Changeable</name> <name>Timeout Changeable</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>tcp.userTimeoutChangeable</t> <t>tcp.userTimeoutChangeable</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Boolean</t> <t>Boolean</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t><tt>true</tt></t> <t><tt>true</tt></t>
</dd> </dd>
</dl> </dl>
<t>This property controls whether the TCP <tt>connTimeout</tt> (see <x ref target="conn-timeout"/>) <t>This property controls whether the TCP <tt>connTimeout</tt> (see <x ref target="conn-timeout"/>)
can be changed can be changed
based on a UTO option received from the remote peer. This boolean becomes <tt>fa lse</tt> when based on a UTO received from the remote peer. This boolean becomes <tt>false</tt > when
<tt>connTimeout</tt> (see <xref target="conn-timeout"/>) is used.</t> <tt>connTimeout</tt> (see <xref target="conn-timeout"/>) is used.</t>
</section> </section>
</section> </section>
<section anchor="connection-lifecycle-events"> <section anchor="connection-lifecycle-events">
<name>Connection Lifecycle Events</name> <name>Connection Lifecycle Events</name>
<t>During the lifetime of a Connection there are events that can occur w hen configured.</t> <t>During the lifetime of a Connection there are events that can occur w hen configured.</t>
<section anchor="soft-errors"> <section anchor="soft-errors">
<name>Soft Errors</name> <name>Soft Errors</name>
<t>Asynchronous introspection is also possible, via the <tt>SoftError< /tt> event. This event <t>Asynchronous introspection is also possible, via the <tt>SoftError< /tt> event. This event
informs the application about the receipt and contents of an ICMP error message related to the Connection. This will only happen if the underlying Protocol Stac k supports access to soft errors; however, even if the underlying stack supports it, there informs the application about the receipt and contents of an ICMP error message related to the Connection. This will only happen if the underlying Protocol Stac k supports access to soft errors; however, even if the underlying stack supports it, there
is no guarantee that a soft error will be signaled.</t> is no guarantee that a soft error will be signaled.</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection -> SoftError<> Connection -> SoftError<>
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="conn-path-change"> <section anchor="conn-path-change">
<name>Path change</name> <name>Path Change</name>
<t>This event notifies the application when at least one of the paths underlying a Connection has changed. Changes occur <t>This event notifies the application when at least one of the paths underlying a Connection has changed. Changes occur
on a single path when the PMTU changes as well as when multiple paths are used on a single path when the PMTU changes as well as when multiple paths are used
and paths are added or removed, the set of local endpoints changes, or a handove r has been performed.</t> and paths are added or removed, the set of local endpoints changes, or a handove r has been performed.</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection -> PathChange<> Connection -> PathChange<>
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
</section> </section>
<section anchor="datatransfer"> <section anchor="datatransfer">
<name>Data Transfer</name> <name>Data Transfer</name>
<t>Data is sent and received as Messages, which allows the application <t>Data is sent and received as Messages, which allows the application
to communicate the boundaries of the data being transferred.</t> to communicate the boundaries of the data being transferred.</t>
<section anchor="msg"> <section anchor="msg">
<name>Messages and Framers</name> <name>Messages and Framers</name>
<t>Each Message has an optional Message Context, which allows adding Mes
sage Properties, identify <tt>Send</tt> events related to a specific Message or <!--[rfced] In the following, please review the use of "identify Send
to inspect meta-data related to the Message sent. Framers can be used to extend events". Is there text missing before or after? Otherwise,
or modify the Message data with additional information that can be processed at who/what is the subject of the verb "identify"? Please rephrase.
the receiver to detect message boundaries.</t>
Original:
Each Message has an optional Message Context, which allows adding
Message Properties, identify Send events related to a specific
Message or to inspect meta-data related to the Message sent.
-->
<t>Each Message has an optional Message Context, which allows adding Mes
sage Properties, identify <tt>Send</tt> events related to a specific Message or
to inspect metadata related to the Message sent. Framers can be used to extend o
r modify the Message data with additional information that can be processed at t
he receiver to detect message boundaries.</t>
<section anchor="msg-ctx"> <section anchor="msg-ctx">
<name>Message Contexts</name> <name>Message Contexts</name>
<t>Using the MessageContext object, the application can set and retrie <t>Using the MessageContext object, the application can set and retrie
ve meta-data of the Message, including Message Properties (see <xref target="mes ve metadata of the Message, including Message Properties (see <xref target="mess
sage-props"/>) and framing meta-data (see <xref target="framing-meta"/>). age-props"/>) and framing metadata (see <xref target="framing-meta"/>).
Therefore, a MessageContext object can be passed to the <tt>Send</tt> action and Therefore, a MessageContext object can be passed to the <tt>Send</tt> action and
is returned by each <tt>Send</tt> and <tt>Receive</tt> related event.</t> is returned by each event related to <tt>Send</tt> and <tt>Receive</tt>.</t>
<t>Message Properties can be set and queried using the Message Context :</t> <t>Message Properties can be set and queried using the Message Context :</t>
<artwork><![CDATA[ <artwork><![CDATA[
MessageContext.add(property, value) MessageContext.add(property, value)
PropertyValue := MessageContext.get(property) PropertyValue := MessageContext.get(property)
]]></artwork> ]]></artwork>
<t>These Message Properties can be generic properties or Protocol-spec ific Properties.</t> <t>These Message Properties can be generic properties or Protocol-spec ific Properties.</t>
<t>For MessageContexts returned by <tt>Send</tt> events (see <xref tar get="send-events"/>) and <tt>Receive</tt> events (see <xref target="receive-even ts"/>), the application can query information about the Local and Remote Endpoin t:</t> <t>For MessageContexts returned by <tt>Send</tt> events (see <xref tar get="send-events"/>) and <tt>Receive</tt> events (see <xref target="receive-even ts"/>), the application can query information about the Local and Remote Endpoin t:</t>
<artwork><![CDATA[ <artwork><![CDATA[
RemoteEndpoint := MessageContext.GetRemoteEndpoint() RemoteEndpoint := MessageContext.GetRemoteEndpoint()
LocalEndpoint := MessageContext.GetLocalEndpoint() LocalEndpoint := MessageContext.GetLocalEndpoint()
skipping to change at line 2832 skipping to change at line 3231
</section> </section>
<section anchor="framing"> <section anchor="framing">
<name>Message Framers</name> <name>Message Framers</name>
<t>Although most applications communicate over a network using well-fo rmed <t>Although most applications communicate over a network using well-fo rmed
Messages, the boundaries and metadata of the Messages are often not Messages, the boundaries and metadata of the Messages are often not
directly communicated by the transport protocol itself. For example, directly communicated by the transport protocol itself. For example,
HTTP applications send and receive HTTP messages over a byte-stream HTTP applications send and receive HTTP messages over a byte-stream
transport, requiring that the boundaries of HTTP messages be parsed transport, requiring that the boundaries of HTTP messages be parsed
from the stream of bytes.</t> from the stream of bytes.</t>
<t>Message Framers allow extending a Connection's Protocol Stack to de fine <t>Message Framers allow extending a Connection's Protocol Stack to de fine
how to encapsulate or encode outbound Messages, and how to decapsulate how to encapsulate or encode outbound Messages and how to decapsulate
or decode inbound data into Messages. Message Framers allow message or decode inbound data into Messages. Message Framers allow message
boundaries to be preserved when using a Connection object, even when boundaries to be preserved when using a Connection object, even when
using byte-stream transports. This is designed based on the fact using byte-stream transports. This is designed based on the fact
that many of the current application protocols evolved over TCP, which that many of the application protocols in use at the time of writing evolved ove
does not provide message boundary preservation, and since many of these r TCP, which
protocols require message boundaries to function, each application layer does not provide message boundary preservation; because many of these
protocols require message boundaries to function, each application-layer
protocol has defined its own framing.</t> protocol has defined its own framing.</t>
<t>To use a Message Framer, the application adds it to its Preconnecti on object. <t>To use a Message Framer, the application adds it to its Preconnecti on object.
Then, the Message Framer can intercept all calls to <tt>Send</tt> or <tt>Receive </tt> Then, the Message Framer can intercept all calls to <tt>Send</tt> or <tt>Receive </tt>
on a Connection to add Message semantics, in addition to interacting with on a Connection to add Message semantics, in addition to interacting with
the setup and teardown of the Connection. A Framer can start sending data the setup and teardown of the Connection. A Framer can start sending data
before the application sends data if the framing protocol requires a prefix before the application sends data if the framing protocol requires a prefix
or handshake (see <xref target="RFC9329"/> for an example of such a framing prot ocol).</t> or handshake (see <xref target="RFC9329"/> for an example of such a framing prot ocol).</t>
<figure anchor="fig-framer-stack"> <figure anchor="fig-framer-stack">
<name>Protocol Stack showing a Message Framer</name> <name>Protocol Stack Showing a Message Framer</name>
<artwork><![CDATA[ <artwork><![CDATA[
Initiate() Send() Receive() Close() Initiate() Send() Receive() Close()
| | ^ | | | ^ |
| | | | | | | |
+----v----------v---------+----------v-----+ +----v----------v---------+----------v-----+
| Connection | | Connection |
+----+----------+---------^----------+-----+ +----+----------+---------^----------+-----+
| | | | | | | |
| +-----------------+ | | +-----------------+ |
| | Messages | | | | Messages | |
skipping to change at line 2876 skipping to change at line 3275
| +-----------------+ | | +-----------------+ |
| | | | | | | |
+----v----------v---------+----------v-----+ +----v----------v---------+----------v-----+
| Transport Protocol Stack | | Transport Protocol Stack |
+------------------------------------------+ +------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Note that while Message Framers add the most value when placed abov e <t>Note that while Message Framers add the most value when placed abov e
a protocol that otherwise does not preserve message boundaries, they can a protocol that otherwise does not preserve message boundaries, they can
also be used with datagram- or message-based protocols. In these cases, also be used with datagram- or message-based protocols. In these cases,
they add a transformation to further encode or encapsulate, they add a transformation to further encode or encapsulate
and can potentially support packing multiple application-layer Messages and can potentially support packing multiple application-layer Messages
into individual transport datagrams.</t> into individual transport datagrams.</t>
<t>The API to implement a Message Framer can vary depending on the imp <t>The API to implement a Message Framer can vary, depending on the im
lementation; plementation;
guidance on implementing Message Framers can be found in <xref target="I-D.ietf- guidance on implementing Message Framers can be found in <xref target="RFC9623"/
taps-impl"/>.</t> >.</t>
<section anchor="adding-message-framers-to-pre-connections"> <section anchor="adding-message-framers-to-preconnections">
<name>Adding Message Framers to Pre-Connections</name> <name>Adding Message Framers to Preconnections</name>
<t>The Message Framer object can be added to one or more Preconnecti ons <t>The Message Framer object can be added to one or more Preconnecti ons
to run on top of transport protocols. Multiple Framers can be added to a Preconn ection; to run on top of transport protocols. Multiple Framers can be added to a Preconn ection;
in this case, the Framers operate as a framing stack, i.e. the last one added ru ns in this case, the Framers operate as a framing stack, i.e., the last one added r uns
first when framing outbound Messages, and last when parsing inbound data.</t> first when framing outbound Messages, and last when parsing inbound data.</t>
<t>The following example adds a basic HTTP Message Framer to a Preco nnection:</t> <t>The following example adds a basic HTTP Message Framer to a Preco nnection:</t>
<artwork><![CDATA[ <artwork><![CDATA[
framer := NewHTTPMessageFramer() framer := NewHTTPMessageFramer()
Preconnection.AddFramer(framer) Preconnection.AddFramer(framer)
]]></artwork> ]]></artwork>
<t>Since Message Framers pass from Preconnection to Listener or Conn ection, addition of <t>Since Message Framers pass from Preconnection to Listener or Conn ection, addition of
Framers must happen before any operation that might result in the creation of a Connection.</t> Framers must happen before any operation that might result in the creation of a Connection.</t>
</section> </section>
<section anchor="framing-meta"> <section anchor="framing-meta">
<name>Framing Meta-Data</name> <name>Framing Metadata</name>
<t>When sending Messages, applications can add Framer-specific <t>When sending Messages, applications can add Framer-specific
properties to a MessageContext (<xref target="msg-ctx"/>) with the <tt>add</tt> action. properties to a MessageContext (<xref target="msg-ctx"/>) with the <tt>add</tt> action.
To avoid naming conflicts, the property To avoid naming conflicts, the property
names SHOULD be prefixed with a namespace referencing the names <bcp14>SHOULD</bcp14> be prefixed with a namespace referencing the
framer implementation or the protocol it implements as described framer implementation or the protocol it implements as described
in <xref target="property-names"/>.</t> in <xref target="property-names"/>.</t>
<t>This mechanism can be used, for example, to set the type of a Mes sage for a TLV format. <t>This mechanism can be used, for example, to set the type of a Mes sage for a TLV format.
The namespace of values is custom for each unique Message Framer.</t> The namespace of values is custom for each unique Message Framer.</t>
<artwork><![CDATA[ <artwork><![CDATA[
messageContext := NewMessageContext() messageContext := NewMessageContext()
messageContext.add(framer, key, value) messageContext.add(framer, key, value)
Connection.Send(messageData, messageContext) Connection.Send(messageData, messageContext)
]]></artwork> ]]></artwork>
<t>When an application receives a MessageContext in a <tt>Receive</t t> event, <t>When an application receives a MessageContext in a <tt>Receive</t t> event,
skipping to change at line 2929 skipping to change at line 3328
... ...
messageContext := NewMessageContext() messageContext := NewMessageContext()
messageContext.add(httpFramer, "accept", "text/html") messageContext.add(httpFramer, "accept", "text/html")
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
<section anchor="message-props"> <section anchor="message-props">
<name>Message Properties</name> <name>Message Properties</name>
<t>Applications needing to annotate the Messages they send with extra information <t>Applications needing to annotate the Messages they send with extra information
(for example, to control how data is scheduled and processed by the transport pr otocols supporting the (for example, to control how data is scheduled and processed by the transport pr otocols supporting the
Connection) can include this information in the Message Context passed to the <t Connection) can include this information in the Message Context passed
t>Send</tt> action. For other uses of the Message Context, see <xref target="msg to the <tt>Send</tt> action. For other uses of the Message Context, see <xref ta
-ctx"/>.</t> rget="msg-ctx"/>.</t>
<t>Message Properties are per-Message, not per-<tt>Send</tt> if partia
l Messages <!--[rfced] Please review our updates to the following text to ensure
we have maintained the intended meaning.
Original:
For example, it would not make sense to have the beginning of a
Message expire, but allow the end of a Message to still be sent.
Current:
For example, it would not make sense to have the beginning of a
Message expire but allow the end of the Message to still be sent.
-->
<t>Message Properties are per-Message, not per-<tt>Send</tt>, if parti
al Messages
are sent (<xref target="send-partial"/>). All data blocks associated with a sing le Message are sent (<xref target="send-partial"/>). All data blocks associated with a sing le Message
share properties specified in the Message Contexts. For example, it would not share properties specified in the Message Contexts. For example, it would not
make sense to have the beginning of a Message expire, but allow the end of a make sense to have the beginning of a Message expire but allow the end of the Me
Message to still be sent.</t> ssage to still be sent.</t>
<t>A MessageContext object contains metadata for the Messages to be se nt or received.</t> <t>A MessageContext object contains metadata for the Messages to be se nt or received.</t>
<artwork><![CDATA[ <artwork><![CDATA[
messageData := "hello" messageData := "hello"
messageContext := NewMessageContext() messageContext := NewMessageContext()
messageContext.add(parameter, value) messageContext.add(parameter, value)
Connection.Send(messageData, messageContext) Connection.Send(messageData, messageContext)
]]></artwork> ]]></artwork>
<t>The simpler form of <tt>Send</tt>, which does not take any MessageC ontext, is equivalent to passing a default MessageContext without adding any Mes sage Properties.</t> <t>The simpler form of <tt>Send</tt>, which does not take any MessageC ontext, is equivalent to passing a default MessageContext without adding any Mes sage Properties.</t>
<t>If an application wants to override Message Properties for a specif ic Message, <t>If an application wants to override Message Properties for a specif ic Message,
it can acquire an empty MessageContext object and add all desired Message it can acquire an empty MessageContext object and add all desired Message
skipping to change at line 2972 skipping to change at line 3384
<tt>reliability</tt> is set to <tt>Require</tt> and a protocol <tt>reliability</tt> is set to <tt>Require</tt> and a protocol
with configurable per-Message reliability is used, setting with configurable per-Message reliability is used, setting
<tt>msgReliable</tt> to <tt>false</tt> for a particular Message will <tt>msgReliable</tt> to <tt>false</tt> for a particular Message will
allow this Message to be sent without any reliability guarantees. Changing allow this Message to be sent without any reliability guarantees. Changing
the <tt>msgReliable</tt> Message Property is only possible for the <tt>msgReliable</tt> Message Property is only possible for
Connections that were established enabling the Selection Property Connections that were established enabling the Selection Property
<tt>perMsgReliability</tt>. If the contradicting Message Property <tt>perMsgReliability</tt>. If the contradicting Message Property
cannot be supported by the Connection (such as requiring reliability cannot be supported by the Connection (such as requiring reliability
on a Connection that uses an unreliable protocol), the <tt>Send</tt> action on a Connection that uses an unreliable protocol), the <tt>Send</tt> action
will result in a <tt>SendError</tt> event.</t> will result in a <tt>SendError</tt> event.</t>
<t>The following Message Properties are supported:</t> <t>The Message Properties in the following subsections are supported.< /t>
<section anchor="msg-lifetime"> <section anchor="msg-lifetime">
<name>Lifetime</name> <name>Lifetime</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>msgLifetime</t> <t>msgLifetime</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Numeric (positive)</t> <t>Numeric (positive)</t>
skipping to change at line 2997 skipping to change at line 3409
</dd> </dd>
</dl> </dl>
<t>The Lifetime specifies how long a particular Message can wait in the Transport Services system <t>The Lifetime specifies how long a particular Message can wait in the Transport Services system
before it is sent to the before it is sent to the
Remote Endpoint. After this time, it is irrelevant and no longer needs to be Remote Endpoint. After this time, it is irrelevant and no longer needs to be
(re-)transmitted. This is a hint to the Transport Services system -- it is not g uaranteed (re-)transmitted. This is a hint to the Transport Services system -- it is not g uaranteed
that a Message will not be sent when its Lifetime has expired.</t> that a Message will not be sent when its Lifetime has expired.</t>
<t>Setting a Message's Lifetime to infinite indicates that the appli cation does <t>Setting a Message's Lifetime to infinite indicates that the appli cation does
not wish to apply a time constraint on the transmission of the Message, but it d oes not express a need for not wish to apply a time constraint on the transmission of the Message, but it d oes not express a need for
reliable delivery; reliability is adjustable per Message via the <tt>perMsgRelia bility</tt> reliable delivery; reliability is adjustable per Message via the <tt>perMsgRelia bility</tt>
property (see <xref target="msg-reliable-message"/>). The type and units of Life time are implementation-specific.</t> property (see <xref target="msg-reliable-message"/>). The type and units of Life time are implementation specific.</t>
</section> </section>
<section anchor="msg-priority"> <section anchor="msg-priority">
<name>Priority</name> <name>Priority</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>msgPriority</t> <t>msgPriority</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
skipping to change at line 3019 skipping to change at line 3431
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>100</t> <t>100</t>
</dd> </dd>
</dl> </dl>
<t>This property specifies the priority of a Message, relative to ot her Messages sent over the <t>This property specifies the priority of a Message, relative to ot her Messages sent over the
same Connection. A numerically lower value represents a higher priority.</t> same Connection. A numerically lower value represents a higher priority.</t>
<t>A Message with Priority 2 will yield to a Message with Priority 1 , which will <t>A Message with Priority 2 will yield to a Message with Priority 1 , which will
yield to a Message with Priority 0, and so on. Priorities can be used as a yield to a Message with Priority 0, and so on. Priorities can be used as a
sender-side scheduling construct only, or be used to specify priorities on the sender-side scheduling construct only or be used to specify priorities on the
wire for Protocol Stacks supporting prioritization.</t> wire for Protocol Stacks supporting prioritization.</t>
<t>Note that this property is not a per-Message override of <tt>conn <t>Note that this property is not a per-Message override of <tt>conn
Priority</tt> Priority</tt>;
- see <xref target="conn-priority"/>. The priority properties might interact, bu see <xref target="conn-priority"/>. The priority properties might interact, but
t can be used they can be used
independently and be realized by different mechanisms; see <xref target="priorit y-in-taps"/>.</t> independently and be realized by different mechanisms; see <xref target="priorit y-in-taps"/>.</t>
</section> </section>
<section anchor="msg-ordered"> <section anchor="msg-ordered">
<name>Ordered</name> <name>Ordered</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>msgOrdered</t> <t>msgOrdered</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Boolean</t> <t>Boolean</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>the queried Boolean value of the Selection Property <tt>prese rveOrder</tt> (<xref target="prop-ordering"/>)</t> <t>the queried Boolean value of the Selection Property <tt>prese rveOrder</tt> (<xref target="prop-ordering"/>)</t>
</dd> </dd>
</dl> </dl>
<t>The order in which Messages were submitted for transmission via t he <tt>Send</tt> action will be preserved on delivery via <tt>Receive</tt> event s for all Messages on a Connection that have this Message Property set to <tt>tr ue</tt>.</t> <t>The order in which Messages were submitted for transmission via t he <tt>Send</tt> action will be preserved on delivery via <tt>Receive</tt> event s for all Messages on a Connection that have this Message Property set to <tt>tr ue</tt>.</t>
<t>If <tt>false</tt>, the Message is delivered to the receiving appl ication without preserving the ordering. <t>If <tt>false</tt>, the Message is delivered to the receiving appl ication without preserving the ordering.
This property is used for protocols that support preservation of data ordering, This property is used for protocols that support preservation of data ordering
see <xref target="prop-ordering"/>, but allow out-of-order delivery for certain (see <xref target="prop-ordering"/>) but allow out-of-order delivery for certain
Messages, e.g., by multiplexing independent Messages onto Messages, e.g., by multiplexing independent Messages onto
different streams.</t> different streams.</t>
<t>If it is not configured by the application before sending, this p roperty's default value <t>If it is not configured by the application before sending, this p roperty's default value
will be based on the Selection Property <tt>preserveOrder</tt> of the Connection will be based on the Selection Property <tt>preserveOrder</tt> of the Connection
associated with the <tt>Send</tt> action.</t> associated with the <tt>Send</tt> action.</t>
</section> </section>
<section anchor="msg-safelyreplayable"> <section anchor="msg-safelyreplayable">
<name>Safely Replayable</name> <name>Safely Replayable</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
skipping to change at line 3075 skipping to change at line 3487
</dl> </dl>
<t>If <tt>true</tt>, <tt>safelyReplayable</tt> specifies that a Mess age is safe to send to the Remote Endpoint <t>If <tt>true</tt>, <tt>safelyReplayable</tt> specifies that a Mess age is safe to send to the Remote Endpoint
more than once for a single <tt>Send</tt> action. It marks the data as safe for more than once for a single <tt>Send</tt> action. It marks the data as safe for
certain 0-RTT establishment techniques, where retransmission of the 0-RTT data certain 0-RTT establishment techniques, where retransmission of the 0-RTT data
could cause the remote application to receive the Message multiple times.</t> could cause the remote application to receive the Message multiple times.</t>
<t>For protocols that do not protect against duplicated Messages, <t>For protocols that do not protect against duplicated Messages,
e.g., UDP, all Messages need to be marked as "safely replayable" by enabling thi s property. e.g., UDP, all Messages need to be marked as "safely replayable" by enabling thi s property.
To enable protocol selection to choose such a protocol, To enable protocol selection to choose such a protocol,
<tt>safelyReplayable</tt> needs to be added to the TransportProperties passed to the <tt>safelyReplayable</tt> needs to be added to the TransportProperties passed to the
Preconnection. If such a protocol was chosen, disabling <tt>safelyReplayable</tt > on Preconnection. If such a protocol was chosen, disabling <tt>safelyReplayable</tt > on
individual Messages MUST result in a <tt>SendError</tt>.</t> individual Messages <bcp14>MUST</bcp14> result in a <tt>SendError</tt>.</t>
</section> </section>
<section anchor="msg-final"> <section anchor="msg-final">
<name>Final</name> <name>Final</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>final</t> <t>final</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
skipping to change at line 3098 skipping to change at line 3510
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t><tt>false</tt></t> <t><tt>false</tt></t>
</dd> </dd>
</dl> </dl>
<t>If <tt>true</tt>, this indicates a Message is the last that <t>If <tt>true</tt>, this indicates a Message is the last that
the application will send on a Connection. This allows underlying protocols the application will send on a Connection. This allows underlying protocols
to indicate to the Remote Endpoint that the Connection has been effectively to indicate to the Remote Endpoint that the Connection has been effectively
closed in the sending direction. For example, TCP-based Connections can closed in the sending direction. For example, TCP-based Connections can
send a FIN once a Message marked as Final has been completely sent, send a FIN once a Message marked as Final has been completely sent,
indicated by marking endOfMessage. Protocols that do not support signalling indicated by marking endOfMessage. Protocols that do not support signaling
the end of a Connection in a given direction will ignore this property.</t> the end of a Connection in a given direction will ignore this property.</t>
<t>A Final Message must always be sorted to the end of a list of Mes sages. <t>A Final Message must always be sorted to the end of a list of Mes sages.
The Final property overrides Priority and any other property that would re-order The Final property overrides Priority and any other property that would reorder
Messages. If another Message is sent after a Message marked as Final has already Messages. If another Message is sent after a Message marked as Final has already
been sent on a Connection, the <tt>Send</tt> action for the new Message will cau se a <tt>SendError</tt> event.</t> been sent on a Connection, the <tt>Send</tt> action for the new Message will cau se a <tt>SendError</tt> event.</t>
</section> </section>
<section anchor="msg-checksum"> <section anchor="msg-checksum">
<name>Sending Corruption Protection Length</name> <name>Sending Corruption Protection Length</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>msgChecksumLen</t> <t>msgChecksumLen</t>
</dd> </dd>
skipping to change at line 3123 skipping to change at line 3535
<dd> <dd>
<t>Integer (non-negative) or <tt>Full Coverage</tt></t> <t>Integer (non-negative) or <tt>Full Coverage</tt></t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t><tt>Full Coverage</tt></t> <t><tt>Full Coverage</tt></t>
</dd> </dd>
</dl> </dl>
<t>If this property is an Integer, it specifies the minimum length o f the section of a sent Message, <t>If this property is an Integer, it specifies the minimum length o f the section of a sent Message,
starting from byte 0, that the application requires to be delivered without starting from byte 0, that the application requires to be delivered without
corruption due to lower layer errors. It is used to specify options for simple corruption due to lower-layer errors. It is used to specify options for simple
integrity protection via checksums. A value of 0 means that no checksum integrity protection via checksums. A value of 0 means that no checksum
needs to be calculated, and the enumerated value <tt>Full Coverage</tt> means needs to be calculated, and the enumerated value <tt>Full Coverage</tt> means
that the entire Message needs to be protected by a checksum. Only <tt>Full Cover age</tt> is that the entire Message needs to be protected by a checksum. Only <tt>Full Cover age</tt> is
guaranteed, any other requests are advisory, which may result in <tt>Full Covera ge</tt> being applied.</t> guaranteed: any other requests are advisory, which may result in <tt>Full Covera ge</tt> being applied.</t>
</section> </section>
<section anchor="msg-reliable-message"> <section anchor="msg-reliable-message">
<name>Reliable Data Transfer (Message)</name> <name>Reliable Data Transfer (Message)</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>msgReliable</t> <t>msgReliable</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Boolean</t> <t>Boolean</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>the queried Boolean value of the Selection Property <tt>relia bility</tt> (<xref target="prop-reliable"/>)</t> <t>the queried Boolean value of the Selection Property <tt>relia bility</tt> (<xref target="prop-reliable"/>)</t>
</dd> </dd>
</dl> </dl>
<t>When true, this property specifies that a Message should be sent <t>When <tt>true</tt>, this property specifies that a Message should
in such a way be sent in such a way
that the transport protocol ensures all data is received by the Remote Endpoint. that the transport protocol ensures that all data is received by the Remote Endp
oint.
Changing the <tt>msgReliable</tt> property on Messages Changing the <tt>msgReliable</tt> property on Messages
is only possible for Connections that were established enabling the Selection Pr operty <tt>perMsgReliability</tt>. is only possible for Connections that were established enabling the Selection Pr operty <tt>perMsgReliability</tt>.
When this is not the case, changing <tt>msgReliable</tt> will generate an error. </t> When this is not the case, changing <tt>msgReliable</tt> will generate an error. </t>
<t>Disabling this property indicates that the Transport Services sys tem could disable retransmissions <t>Disabling this property indicates that the Transport Services sys tem could disable retransmissions
or other reliability mechanisms for this particular Message, but such disabling is not guaranteed.</t> or other reliability mechanisms for this particular Message, but such disabling is not guaranteed.</t>
<t>If it is not configured by the application before sending, this p roperty's default value <t>If it is not configured by the application before sending, this p roperty's default value
will be based on the Selection Property <tt>reliability</tt> of the Connection will be based on the Selection Property <tt>reliability</tt> of the Connection
associated with the <tt>Send</tt> action.</t> associated with the <tt>Send</tt> action.</t>
</section> </section>
<section anchor="send-profile"> <section anchor="send-profile">
skipping to change at line 3172 skipping to change at line 3584
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Enumeration</t> <t>Enumeration</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t>inherited from the Connection Property <tt>connCapacityProfil e</tt> (<xref target="prop-cap-profile"/>)</t> <t>inherited from the Connection Property <tt>connCapacityProfil e</tt> (<xref target="prop-cap-profile"/>)</t>
</dd> </dd>
</dl> </dl>
<t>This enumerated property specifies the application's preferred tr adeoffs for <t>This enumerated property specifies the application's preferred tr ade-offs for
sending this Message; it is a per-Message override of the <tt>connCapacityProfil e</tt> sending this Message; it is a per-Message override of the <tt>connCapacityProfil e</tt>
Connection Property (see <xref target="prop-cap-profile"/>). Connection Property (see <xref target="prop-cap-profile"/>).
If it is not configured by the application before sending, this property's defau lt value If it is not configured by the application before sending, this property's defau lt value
will be based on the Connection Property <tt>connCapacityProfile</tt> of the Con nection will be based on the Connection Property <tt>connCapacityProfile</tt> of the Con nection
associated with the <tt>Send</tt> action.</t> associated with the <tt>Send</tt> action.</t>
</section> </section>
<section anchor="send-singular"> <section anchor="send-singular">
<name>No Network-Layer Fragmentation</name> <name>No Network-Layer Fragmentation</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
skipping to change at line 3197 skipping to change at line 3609
<dd> <dd>
<t>Boolean</t> <t>Boolean</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t><tt>false</tt></t> <t><tt>false</tt></t>
</dd> </dd>
</dl> </dl>
<t>This property specifies that a Message should be sent and receive d <t>This property specifies that a Message should be sent and receive d
without network-layer fragmentation, if possible. It can be used without network-layer fragmentation, if possible. It can be used
to avoid network layer fragmentation when transport segmentation is preferred.</ t> to avoid network-layer fragmentation when transport segmentation is preferred.</ t>
<t>This only takes effect when the transport uses a network layer th at supports this functionality. <t>This only takes effect when the transport uses a network layer th at supports this functionality.
When it does take effect, setting this property to When it does take effect, setting this property to
<tt>true</tt> will cause the sender to avoid network-layer source fragmentation. <tt>true</tt> will cause the sender to avoid network-layer source fragmentation.
When using IPv4, this will result in the Don't Fragment bit being set in the IP header.</t> When using IPv4, this will result in the Don't Fragment (DF) bit being set in th e IP header.</t>
<t>Attempts to send a Message with this property that result in a si ze greater than the <t>Attempts to send a Message with this property that result in a si ze greater than the
transport's current estimate of its maximum packet size (<tt>singularTransmissio nMsgMaxLen</tt>) transport's current estimate of its maximum packet size (<tt>singularTransmissio nMsgMaxLen</tt>)
can result in transport segmentation when permitted, or in a <tt>SendError</tt>. can result in transport segmentation when permitted or in a <tt>SendE
</t> rror</tt>.</t>
<t>Note: noSegmentation is used when it is desired to only send a Me
ssage within <!--[rfced] May we rephrase this text as follows? Or does this edit
change the meaning?
Original:
Note: noSegmentation is used when it is desired to only send a
Message within a single network packet.
Perhaps:
Note: noSegmentation is used when only sending a
Message within a single network packet is desired.
-->
<t>Note: noSegmentation is used when it is desired to only sending a
Message within
a single network packet.</t> a single network packet.</t>
<!-- [rfced] Please review whether the "Note:" items in this document
should be in the <aside> element. <aside> is defined as "a container
for content that is semantically less important or tangential to the
content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
For example:
Note: noSegmentation is used when it is desired to only send a
Message within a single network packet.
-->
</section> </section>
<section anchor="no-transport-fragmentation"> <section anchor="no-transport-fragmentation">
<name>No Segmentation</name> <name>No Segmentation</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>noSegmentation</t> <t>noSegmentation</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t>Boolean</t> <t>Boolean</t>
</dd> </dd>
<dt>Default:</dt> <dt>Default:</dt>
<dd> <dd>
<t><tt>false</tt></t> <t><tt>false</tt></t>
</dd> </dd>
</dl> </dl>
<t>When set to <tt>true</tt>, this property requests the transport l <t>When set to <tt>true</tt>, this property requests that the transp
ayer ort layer not provide segmentation of Messages larger than the
to not provide segmentation of Messages larger than the maximum size permitted by the network layer and that it avoid network-layer sour
maximum size permitted by the network layer, and also ce fragmentation of Messages.
to avoid network-layer source fragmentation of Messages.
When running over IPv4, setting this property to When running over IPv4, setting this property to
<tt>true</tt> will result in a sending endpoint setting the <tt>true</tt> will result in a sending endpoint setting the
Don't Fragment bit in the IPv4 header of packets generated by the Don't Fragment bit in the IPv4 header of packets generated by the
transport layer.</t> transport layer.</t>
<t>An <t>An
attempt to send a Message that results in a size greater than the attempt to send a Message that results in a size greater than the
transport's current estimate of its maximum packet size (<tt>singularTransmissio nMsgMaxLen</tt>) transport's current estimate of its maximum packet size (<tt>singularTransmissio nMsgMaxLen</tt>)
will result in a <tt>SendError</tt>. will result in a <tt>SendError</tt>.
This only takes effect when the transport and network layer This only takes effect when the transport and network layers
support this functionality.</t> support this functionality.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sending"> <section anchor="sending">
<name>Sending Data</name> <name>Sending Data</name>
<t>Once a Connection has been established, it can be used for sending Me ssages. <t>Once a Connection has been established, it can be used for sending Me ssages.
By default, <tt>Send</tt> enqueues a complete Message, By default, <tt>Send</tt> enqueues a complete Message
and takes optional per-Message properties (see <xref target="send-basic"/>). All <tt>Send</tt> actions and takes optional per-Message properties (see <xref target="send-basic"/>). All <tt>Send</tt> actions
are asynchronous, and deliver events (see <xref target="send-events"/>). Sending partial are asynchronous and deliver events (see <xref target="send-events"/>). Sending partial
Messages for streaming large data is also supported (see <xref target="send-part ial"/>).</t> Messages for streaming large data is also supported (see <xref target="send-part ial"/>).</t>
<t>Messages are sent on a Connection using the <tt>Send</tt> action:</t> <t>Messages are sent on a Connection using the <tt>Send</tt> action:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection.Send(messageData, messageContext?, endOfMessage?) Connection.Send(messageData, messageContext?, endOfMessage?)
]]></artwork> ]]></artwork>
<t>where <tt>messageData</tt> is the data object to send, and <tt>messag eContext</tt> allows <t>where <tt>messageData</tt> is the data object to send and <tt>message Context</tt> allows
adding Message Properties, identifying <tt>Send</tt> events related to a specifi c adding Message Properties, identifying <tt>Send</tt> events related to a specifi c
Message or inspecting meta-data related to the Message sent (see <xref target="m sg-ctx"/>).</t> Message or inspecting metadata related to the Message sent (see <xref target="ms g-ctx"/>).</t>
<t>The optional endOfMessage parameter supports partial sending and is d escribed in <t>The optional endOfMessage parameter supports partial sending and is d escribed in
<xref target="send-partial"/>.</t> <xref target="send-partial"/>.</t>
<section anchor="send-basic"> <section anchor="send-basic">
<name>Basic Sending</name> <name>Basic Sending</name>
<t>The most basic form of sending on a Connection involves enqueuing a single Data <t>The most basic form of sending on a Connection involves enqueuing a single Data
block as a complete Message with default Message Properties.</t> block as a complete Message with default Message Properties.</t>
<artwork><![CDATA[ <artwork><![CDATA[
messageData := "hello" messageData := "hello"
Connection.Send(messageData) Connection.Send(messageData)
]]></artwork> ]]></artwork>
<t>The interpretation of a Message to be sent is dependent on the impl <t>The interpretation of a Message to be sent is dependent on the impl
ementation, and ementation and
on the constraints on the Protocol Stacks implied by the Connection’s transport on the constraints on the Protocol Stacks implied by the Connection's t
properties. ransport properties.
<!--[rfced] Would this update be accurate?
Original:
For example, a Message could be the payload of a single datagram for a
UDP Connection; or an HTTP Request for an HTTP Connection.
Perhaps:
For example, a Message could be the payload of a single datagram for a
UDP Connection. Another example would be an HTTP Request for an HTTP
Connection.
-->
For example, a Message could be the payload of For example, a Message could be the payload of
a single datagram for a UDP Connection; or an HTTP Request for an HTTP a single datagram for a UDP Connection; or an HTTP Request for an HTTP
Connection.</t> Connection.</t>
<t>Some transport protocols can deliver arbitrarily sized Messages, bu t other <t>Some transport protocols can deliver arbitrarily sized Messages, bu t other
protocols constrain the maximum Message size. Applications can query the protocols constrain the maximum Message size. Applications can query the
Connection Property <tt>sendMsgMaxLen</tt> (<xref target="conn-max-msg-send"/>) to determine the maximum size Connection Property <tt>sendMsgMaxLen</tt> (<xref target="conn-max-msg-send"/>) to determine the maximum size
allowed for a single Message. If a Message is too large to fit in the Maximum Me ssage allowed for a single Message. If a Message is too large to fit in the Maximum Me ssage
Size for the Connection, the <tt>Send</tt> will fail with a <tt>SendError</tt> e vent (<xref target="send-error"/>). For Size for the Connection, the <tt>Send</tt> will fail with a <tt>SendError</tt> e vent (<xref target="send-error"/>). For
example, it is invalid to send a Message over a UDP connection that is larger th an example, it is invalid to send a Message over a UDP connection that is larger th an
the available datagram sending size.</t> the available datagram sending size.</t>
</section> </section>
<section anchor="send-events"> <section anchor="send-events">
<name>Send Events</name> <name>Send Events</name>
<t>Like all actions in Transport Services API, the <tt>Send</tt> actio n is asynchronous. There are <t>Like all actions in the Transport Services API, the <tt>Send</tt> a ction is asynchronous. There are
several events that can be delivered in response to sending a Message. several events that can be delivered in response to sending a Message.
Exactly one event (<tt>Sent</tt>, <tt>Expired</tt>, or <tt>SendError</tt>) will be delivered in response Exactly one event (<tt>Sent</tt>, <tt>Expired</tt>, or <tt>SendError</tt>) will be delivered in response
to each call to <tt>Send</tt>.</t> to each call to <tt>Send</tt>.</t>
<t>Note that if partial <tt>Send</tt> calls are used (<xref target="se nd-partial"/>), there will still be exactly <t>Note that, if partial <tt>Send</tt> calls are used (<xref target="s end-partial"/>), there will still be exactly
one <tt>Send</tt> event delivered for each call to <tt>Send</tt>. For example, i f a Message one <tt>Send</tt> event delivered for each call to <tt>Send</tt>. For example, i f a Message
expired while two requests to <tt>Send</tt> data for that Message are outstandin g, expired while two requests to <tt>Send</tt> data for that Message are outstandin g,
there will be two <tt>Expired</tt> events delivered.</t> there will be two <tt>Expired</tt> events delivered.</t>
<t>The Transport Services API should allow the application to correlat e which <tt>Send</tt> action resulted <t>The Transport Services API should allow the application to correlat e which <tt>Send</tt> action resulted
in a particular <tt>Send</tt> event. The manner in which this correlation is ind icated in a particular <tt>Send</tt> event. The manner in which this correlation is ind icated
is implementation-specific.</t> is implementation specific.</t>
<section anchor="sent"> <section anchor="sent">
<name>Sent</name> <name>Sent</name>
<artwork><![CDATA[ <artwork><![CDATA[
Connection -> Sent<messageContext> Connection -> Sent<messageContext>
]]></artwork> ]]></artwork>
<t>The <tt>Sent</tt> event occurs when a previous <tt>Send</tt> call has completed, i.e., when <t>The <tt>Sent</tt> event occurs when a previous <tt>Send</tt> call has completed, i.e., when
the data derived from the Message has been passed down or through the the data derived from the Message has been passed down or through the
underlying Protocol Stack and is no longer the responsibility of underlying Protocol Stack and is no longer the responsibility of
the Transport Services API. The exact disposition of the Message (i.e., the Transport Services API. The exact disposition of the Message (i.e.,
whether it has actually been transmitted, moved into a buffer on the network whether it has actually been transmitted, moved into a buffer on the network
interface, moved into a kernel buffer, and so on) when the <tt>Sent</tt> event o ccurs interface, moved into a kernel buffer, and so on) when the <tt>Sent</tt> event o ccurs
is implementation-specific. The <tt>Sent</tt> event contains a reference to the Message is implementation specific. The <tt>Sent</tt> event contains a reference to the Message
Context of the Message to which it applies.</t> Context of the Message to which it applies.</t>
<t><tt>Sent</tt> events allow an application to obtain an understand ing of the amount <t><tt>Sent</tt> events allow an application to obtain an understand ing of the amount
of buffering it creates. That is, if an application calls the <tt>Send</tt> acti on multiple of buffering it creates. That is, if an application calls the <tt>Send</tt> acti on multiple
times without waiting for a <tt>Sent</tt> event, it has created more buffer insi de the times without waiting for a <tt>Sent</tt> event, it has created more buffer insi de the
Transport Services system than an application that always waits for the <tt>Sent </tt> event before Transport Services system than an application that always waits for the <tt>Sent </tt> event before
calling the next <tt>Send</tt> action.</t> calling the next <tt>Send</tt> action.</t>
</section> </section>
<section anchor="expired"> <section anchor="expired">
<name>Expired</name> <name>Expired</name>
<artwork><![CDATA[ <artwork><![CDATA[
Connection -> Expired<messageContext> Connection -> Expired<messageContext>
]]></artwork> ]]></artwork>
<t>The <tt>Expired</tt> event occurs when a previous <tt>Send</tt> a <t>The <tt>Expired</tt> event occurs when a previous <tt>Send</tt> a
ction expired before completion; ction expired before completion,
i.e. when the Message was not sent before its Lifetime (see <xref target="msg-li i.e., when the Message was not sent before its Lifetime (see <xref target="msg-l
fetime"/>) ifetime"/>)
expired. This is separate from <tt>SendError</tt>, as it is an expected behavior for expired. This is separate from <tt>SendError</tt>, as it is an expected behavior for
partially reliable transports. The <tt>Expired</tt> event contains a reference t o the partially reliable transports. The <tt>Expired</tt> event contains a reference t o the
Message Context of the Message to which it applies.</t> Message Context of the Message to which it applies.</t>
</section> </section>
<section anchor="send-error"> <section anchor="send-error">
<name>SendError</name> <name>SendError</name>
<artwork><![CDATA[ <artwork><![CDATA[
Connection -> SendError<messageContext, reason?> Connection -> SendError<messageContext, reason?>
]]></artwork> ]]></artwork>
<t>A <tt>SendError</tt> occurs when a Message was not sent due to an error condition: <t>A <tt>SendError</tt> occurs when a Message was not sent due to an error condition:
skipping to change at line 3338 skipping to change at line 3790
Protocol Stack to handle, some failure of the underlying Protocol Stack, or a Protocol Stack to handle, some failure of the underlying Protocol Stack, or a
set of Message Properties not consistent with the Connection's transport set of Message Properties not consistent with the Connection's transport
properties. The <tt>SendError</tt> contains a reference to the Message Context o f the properties. The <tt>SendError</tt> contains a reference to the Message Context o f the
Message to which it applies.</t> Message to which it applies.</t>
</section> </section>
</section> </section>
<section anchor="send-partial"> <section anchor="send-partial">
<name>Partial Sends</name> <name>Partial Sends</name>
<t>It is not always possible for an application to send all data assoc iated with <t>It is not always possible for an application to send all data assoc iated with
a Message in a single <tt>Send</tt> action. The Message data might be too large for a Message in a single <tt>Send</tt> action. The Message data might be too large for
the application to hold in memory at one time, or the length of the Message the application to hold in memory at one time or the length of the Message
might be unknown or unbounded.</t> might be unknown or unbounded.</t>
<t>Partial Message sending is supported by passing an endOfMessage Boo lean <t>Partial Message sending is supported by passing an endOfMessage Boo lean
parameter to the <tt>Send</tt> action. This value is always <tt>true</tt> by def ault, and parameter to the <tt>Send</tt> action. This value is always <tt>true</tt> by def ault, and
the simpler forms of <tt>Send</tt> are equivalent to passing <tt>true</tt> for e ndOfMessage.</t> the simpler forms of <tt>Send</tt> are equivalent to passing <tt>true</tt> for e ndOfMessage.</t>
<t>The following example sends a Message in two separate calls to <tt> Send</tt>.</t> <t>The following example sends a Message in two separate calls to <tt> Send</tt>:</t>
<artwork><![CDATA[ <artwork><![CDATA[
messageContext := NewMessageContext() messageContext := NewMessageContext()
messageContext.add(parameter, value) messageContext.add(parameter, value)
messageData := "hel" messageData := "hel"
endOfMessage := false endOfMessage := false
Connection.Send(messageData, messageContext, endOfMessage) Connection.Send(messageData, messageContext, endOfMessage)
messageData := "lo" messageData := "lo"
endOfMessage := true endOfMessage := true
Connection.Send(messageData, messageContext, endOfMessage) Connection.Send(messageData, messageContext, endOfMessage)
]]></artwork> ]]></artwork>
<t>All data sent with the same MessageContext object will be treated a s belonging <t>All data sent with the same MessageContext object will be treated a s belonging
to the same Message, and will constitute an in-order series until the to the same Message and will constitute an in-order series until the
endOfMessage is marked.</t> endOfMessage is marked.</t>
</section> </section>
<section anchor="send-batching"> <section anchor="send-batching">
<name>Batching Sends</name> <name>Batching Sends</name>
<t>To reduce the overhead of sending multiple small Messages on a Conn ection, the <t>To reduce the overhead of sending multiple small Messages on a Conn ection, the
application could batch several <tt>Send</tt> actions together. This provides a hint to application could batch several <tt>Send</tt> actions together. This provides a hint to
the system that the sending of these Messages ought to be coalesced when possibl e, the system that the sending of these Messages ought to be coalesced when possibl e
and that sending any of the batched Messages can be delayed until the last Messa ge and that sending any of the batched Messages can be delayed until the last Messa ge
in the batch is enqueued.</t> in the batch is enqueued.</t>
<t>The semantics for starting and ending a batch can be implementation -specific, but need <t>The semantics for starting and ending a batch can be implementation specific but need
to allow multiple <tt>Send</tt> actions to be enqueued.</t> to allow multiple <tt>Send</tt> actions to be enqueued.</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection.StartBatch() Connection.StartBatch()
Connection.Send(messageData) Connection.Send(messageData)
Connection.Send(messageData) Connection.Send(messageData)
Connection.EndBatch() Connection.EndBatch()
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="initiate-and-send"> <section anchor="initiate-and-send">
<name>Send on Active Open: InitiateWithSend</name> <name>Send on Active Open: InitiateWithSend</name>
<t>For application-layer protocols where the Connection initiator also sends the <t>For application-layer protocols where the Connection initiator also sends the
first Message, the <tt>InitiateWithSend</tt> action combines Connection initiati on with first Message, the <tt>InitiateWithSend</tt> action combines Connection initiati on with
a first Message sent:</t> a first Message sent:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection := Preconnection.InitiateWithSend(messageData, Connection := Preconnection.InitiateWithSend(messageData,
messageContext?, messageContext?,
timeout?) timeout?)
]]></artwork> ]]></artwork>
<t>Whenever possible, a MessageContext should be provided to declare t he Message passed to <tt>InitiateWithSend</tt> <t>Whenever possible, a MessageContext should be provided to declare t he Message passed to <tt>InitiateWithSend</tt>
as "safely replayable" using the <tt>safelyReplayable</tt> property. This allows the Transport Services system to make use of 0-RTT establishment in case this i s supported as "safely replayable" using the <tt>safelyReplayable</tt> property. This allows the Transport Services system to make use of 0-RTT establishment in case this i s supported
by the available Protocol Stacks. When the selected stack(s) do not support tran smitting data upon connection by the available Protocol Stacks. When the selected stack or stacks do not suppo rt transmitting data upon connection
establishment, <tt>InitiateWithSend</tt> is identical to <tt>Initiate</tt> follo wed by <tt>Send</tt>.</t> establishment, <tt>InitiateWithSend</tt> is identical to <tt>Initiate</tt> follo wed by <tt>Send</tt>.</t>
<t>Neither partial sends nor send batching are supported by <tt>Initia teWithSend</tt>.</t> <t>Neither partial sends nor send batching are supported by <tt>Initia teWithSend</tt>.</t>
<t>The events that are sent after <tt>InitiateWithSend</tt> are equiva lent to those <t>The events that are sent after <tt>InitiateWithSend</tt> are equiva lent to those
that would be sent by an invocation of <tt>Initiate</tt> followed immediately by an that would be sent by an invocation of <tt>Initiate</tt> followed immediately by an
invocation of <tt>Send</tt>, with the caveat that a send failure that occurs bec ause invocation of <tt>Send</tt>, with the caveat that a send failure that occurs bec ause
the Connection could not be established will not result in a the Connection could not be established will not result in a
<tt>SendError</tt> separate from the <tt>EstablishmentError</tt> signaling the f ailure of Connection <tt>SendError</tt> separate from the <tt>EstablishmentError</tt> signaling the f ailure of Connection
establishment.</t> establishment.</t>
</section> </section>
<section anchor="priority-in-taps"> <section anchor="priority-in-taps">
<name>Priority and the Transport Services API</name> <name>Priority and the Transport Services API</name>
<t>The Transport Services API provides two properties to allow a sende r <t>The Transport Services API provides two properties to allow a sende r
to signal the relative priority of data transmission: <tt>msgPriority</tt> to signal the relative priority of data transmission: <tt>msgPriority</tt>
<xref target="msg-priority"/> and <tt>connPriority</tt> <xref target ="conn-priority"/>. (see <xref target="msg-priority"/>) and <tt>connPriority</tt> (see < xref target="conn-priority"/>).
These properties are designed to allow the expression These properties are designed to allow the expression
and implementation of a wide variety of approaches to transmission priority in and implementation of a wide variety of approaches to transmission priority in
the transport and application layer, including those which do not appear on the transport and application layers, including those that do not appear on
the wire (affecting only sender-side transmission scheduling) as well as those the wire (affecting only sender-side transmission scheduling) as well as those
that do (e.g. <xref target="RFC9218"/>. that do (e.g., <xref target="RFC9218"/>).
A Transport Services system gives no guarantees about how its expression of A Transport Services system gives no guarantees about how its expression of
relative priorities will be realized.</t> relative priorities will be realized.</t>
<t>The Transport Services API does order <tt>connPriority</tt> over <t>The Transport Services API does order <tt>connPriority</tt> over
<tt>msgPriority</tt>. In the absence of other externalities <tt>msgPriority</tt>. In the absence of other externalities
(e.g., transport-layer flow control), a priority 1 Message on a priority 0 (e.g., transport-layer flow control), a priority 1 Message on a priority 0
Connection will be sent before a priority 0 Message on a priority 1 Connection will be sent before a priority 0 Message on a priority 1
Connection in the same group.</t> Connection in the same group.</t>
</section> </section>
</section> </section>
<section anchor="receiving"> <section anchor="receiving">
<name>Receiving Data</name> <name>Receiving Data</name>
<t>Once a Connection is established, it can be used for receiving data ( unless the <t>Once a Connection is established, it can be used for receiving data ( unless the
<tt>direction</tt> property is set to <tt>unidirectional send</tt>). As with <tt>direction</tt> property is set to <tt>unidirectional send</tt>). As with
sending, the data is received in Messages. Receiving is an asynchronous sending, the data is received in Messages. Receiving is an asynchronous
operation, in which each call to <tt>Receive</tt> enqueues a request to receive new operation in which each call to <tt>Receive</tt> enqueues a request to receive n ew
data from the Connection. Once data has been received, or an error is encountere d, data from the Connection. Once data has been received, or an error is encountere d,
an event will be delivered to complete any pending <tt>Receive</tt> requests (se e <xref target="receive-events"/>). an event will be delivered to complete any pending <tt>Receive</tt> requests (se e <xref target="receive-events"/>).
If Messages arrive at the Transport Services system before <tt>Receive</tt> requ ests are issued, If Messages arrive at the Transport Services system before <tt>Receive</tt> requ ests are issued,
ensuing <tt>Receive</tt> requests will first operate on these Messages before aw aiting any further Messages.</t> ensuing <tt>Receive</tt> requests will first operate on these Messages before aw aiting any further Messages.</t>
<section anchor="receiving-action"> <section anchor="receiving-action">
<name>Enqueuing Receives</name> <name>Enqueuing Receives</name>
<t><tt>Receive</tt> takes two parameters to specify the length of data that an application <t><tt>Receive</tt> takes two parameters to specify the length of data that an application
is willing to receive, both of which are optional and have default values if not is willing to receive, both of which are optional and have default values if not
specified.</t> specified.</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection.Receive(minIncompleteLength?, maxLength?) Connection.Receive(minIncompleteLength?, maxLength?)
]]></artwork> ]]></artwork>
<t>By default, <tt>Receive</tt> will try to deliver complete Messages in a single event (<xref target="receive-complete"/>).</t> <t>By default, <tt>Receive</tt> will try to deliver complete Messages in a single event (<xref target="receive-complete"/>).</t>
<t>The application can set a minIncompleteLength value to indicate the smallest partial <t>The application can set a minIncompleteLength value to indicate the smallest partial
Message data size in bytes to be delivered in response to this <tt>Receive</tt>. By default, Message data size in bytes to be delivered in response to this <tt>Receive</tt>. By default,
this value is infinite, which means that only complete Messages should be delive this value is infinite, which means that only complete Messages should be delive
red (see <xref target="receive-partial"/> red. See Sections&nbsp;<xref target="receive-partial" format="counter"/>
and <xref target="framing"/> for more information on how this is accomplished). and <xref target="framing" format="counter"/> for more information on how this i
s accomplished.
If this value is set to some smaller value, the associated receive event will be triggered If this value is set to some smaller value, the associated receive event will be triggered
only when at least that many bytes are available, or the Message is complete wit only:</t>
h fewer <ol>
bytes, or the system needs to free up memory. Applications SHOULD always <li>when at least that many bytes are available,</li>
<li>the Message is complete with fewer
bytes, or</li><li>the system needs to free up memory.</li></ol>
<t>Applications <bcp14>SHOULD</bcp14> always
check the length of the data delivered to the receive event and not assume check the length of the data delivered to the receive event and not assume
it will be as long as minIncompleteLength in the case of shorter complete Messag es it will be as long as minIncompleteLength in the case of shorter complete Messag es
or memory issues.</t> or memory issues.</t>
<t>The maxLength argument indicates the maximum size of a Message in b ytes <t>The maxLength argument indicates the maximum size of a Message in b ytes
that the application is currently prepared to receive. The default that the application is currently prepared to receive. The default
value for maxLength is infinite. If an incoming Message is larger than the value for maxLength is infinite. If an incoming Message is larger than the
minimum of this size and the maximum Message size on receive for minimum of this size and the maximum Message size on receive for
the Connection's Protocol Stack, it will be delivered via <tt>ReceivedPartial</t t> the Connection's Protocol Stack, it will be delivered via <tt>ReceivedPartial</t t>
events (<xref target="receive-partial"/>).</t> events (<xref target="receive-partial"/>).</t>
<t>Note that maxLength does not guarantee that the application will re ceive that many <t>Note that maxLength does not guarantee that the application will re ceive that many
bytes if they are available; the Transport Services API could return <tt>Receive dPartial</tt> events with less bytes if they are available; the Transport Services API could return <tt>Receive dPartial</tt> events with less
data than maxLength according to implementation constraints. Note also that maxL ength data than maxLength according to implementation constraints. Note also that maxL ength
and minIncompleteLength are intended only to manage buffering, and are not inter preted and minIncompleteLength are intended only to manage buffering and are not interp reted
as a receiver preference for Message reordering.</t> as a receiver preference for Message reordering.</t>
</section> </section>
<section anchor="receive-events"> <section anchor="receive-events">
<name>Receive Events</name> <name>Receive Events</name>
<t>Each call to <tt>Receive</tt> will be paired with a single <tt>Rece ive</tt> event. This allows an application <t>Each call to <tt>Receive</tt> will be paired with a single <tt>Rece ive</tt> event. This allows an application
to provide backpressure to the transport stack when it is temporarily not ready to receive Messages. to provide backpressure to the transport stack when it is temporarily not ready to receive Messages.
For example, an application that will later be able to handle multiple receive e vents at the same time For example, an application that will later be able to handle multiple receive e vents at the same time
can make multiple calls to <tt>Receive</tt> without waiting for, or processing, any receive events. An application can make multiple calls to <tt>Receive</tt> without waiting for, or processing, any receive events. An application
that is temporarily unable to process received events for a connection could ref rain from calling <tt>Receive</tt> that is temporarily unable to process received events for a connection could ref rain from calling <tt>Receive</tt>
or delay calling it. This would lead to a build-up of unread data, which, in tur or could delay calling it. This would lead to a buildup of unread data, which, i
n, could result in n turn, could result in
backpressure to the sender via a transport protocol's flow control.</t> backpressure to the sender via a transport protocol's flow control.</t>
<!--[rfced] This sentence does not seem to parse. Please rephrase.
Original:
The Transport Services API should allow the application to correlate
which call to Receive resulted in a particular Receive event.
-->
<t>The Transport Services API should allow the application to correlat e which call to <tt>Receive</tt> resulted <t>The Transport Services API should allow the application to correlat e which call to <tt>Receive</tt> resulted
in a particular <tt>Receive</tt> event. The manner in which this correlation is indicated in a particular <tt>Receive</tt> event. The manner in which this correlation is indicated
is implementation-specific.</t> is implementation specific.</t>
<section anchor="receive-complete"> <section anchor="receive-complete">
<name>Received</name> <name>Received</name>
<artwork><![CDATA[ <artwork><![CDATA[
Connection -> Received<messageData, messageContext> Connection -> Received<messageData, messageContext>
]]></artwork> ]]></artwork>
<t>A <tt>Received</tt> event indicates the delivery of a complete Me ssage. <t>A <tt>Received</tt> event indicates the delivery of a complete Me ssage.
It contains two objects, the received bytes as <tt>messageData</tt>, and the met adata and properties of the received Message as <tt>messageContext</tt>.</t> It contains two objects: the received bytes as <tt>messageData</tt> and the meta data and properties of the received Message as <tt>messageContext</tt>.</t>
<t>The <tt>messageData</tt> value provides access to the bytes that were received for this Message, along with the length of the byte array. <t>The <tt>messageData</tt> value provides access to the bytes that were received for this Message, along with the length of the byte array.
The <tt>messageContext</tt> value is provided to enable retrieving metadata abou t the Message and referring to the Message. The MessageContext object is describ ed in <xref target="msg-ctx"/>.</t> The <tt>messageContext</tt> value is provided to enable retrieving metadata abou t the Message and referring to the Message. The MessageContext object is describ ed in <xref target="msg-ctx"/>.</t>
<t>See <xref target="framing"/> for handling Message framing in situ ations where the Protocol <t>See <xref target="framing"/> regarding how to handle Message fram ing in situations where the Protocol
Stack only provides a byte-stream transport.</t> Stack only provides a byte-stream transport.</t>
</section> </section>
<section anchor="receive-partial"> <section anchor="receive-partial">
<name>ReceivedPartial</name> <name>ReceivedPartial</name>
<artwork><![CDATA[ <artwork><![CDATA[
Connection -> ReceivedPartial<messageData, messageContext, Connection -> ReceivedPartial<messageData, messageContext,
endOfMessage> endOfMessage>
]]></artwork> ]]></artwork>
<t>If a complete Message cannot be delivered in one event, one part of the Message <t>If a complete Message cannot be delivered in one event, one part of the Message
can be delivered with a <tt>ReceivedPartial</tt> event. To continue to receive m ore can be delivered with a <tt>ReceivedPartial</tt> event. To continue to receive m ore
of the same Message, the application must invoke <tt>Receive</tt> again.</t> of the same Message, the application must invoke <tt>Receive</tt> again.</t>
<t>Multiple invocations of <tt>ReceivedPartial</tt> deliver data for the same Message by <t>Multiple invocations of <tt>ReceivedPartial</tt> deliver data for the same Message by
passing the same MessageContext, until the endOfMessage flag is delivered or a passing the same MessageContext until the endOfMessage flag is delivered or a
<tt>ReceiveError</tt> occurs. All partial blocks of a single Message are delive red in <tt>ReceiveError</tt> occurs. All partial blocks of a single Message are delive red in
order without gaps. This event does not support delivering non-contiguous partia l order without gaps. This event does not support delivering non-contiguous partia l
Messages. If, for example, Message A is divided into three pieces (A1, A2, A3) a nd Messages. For example, if Message A is divided into three pieces (A1, A2, A3),
Message B is divided into three pieces (B1, B2, B3), and preserveOrder is not Re quired, Message B is divided into three pieces (B1, B2, B3), and preserveOrder is not Re quired,
the <tt>ReceivedPartial</tt> could deliver them in a sequence like this: A1, B1, the <tt>ReceivedPartial</tt> could deliver them in a sequence like this: A1, B1,
B2, A2, A3, B3, B2, A2, A3, B3.
because the MessageContext allows the application to identify the pieces as belo This is because the MessageContext allows the application to identify the pieces
nging as belonging
to Message A and B, respectively. However, a sequence like: A1, A3 will never oc to Message A and B, respectively. However, a sequence like A1, A3 wil
cur.</t> l never occur.</t>
<t>If the minIncompleteLength in the Receive request was set to be i nfinite (indicating <t>If the minIncompleteLength in the Receive request was set to be i nfinite (indicating
a request to receive only complete Messages), the <tt>ReceivedPartial</tt> event could still be a request to receive only complete Messages), the <tt>ReceivedPartial</tt> event could still be
delivered if one of the following conditions is true:</t> delivered if one of the following conditions is true:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>the underlying Protocol Stack supports message boundary prese rvation, and <t>the underlying Protocol Stack supports message boundary prese rvation and
the size of the Message is larger than the buffers available for a single the size of the Message is larger than the buffers available for a single
Message;</t> Message;</t>
</li> </li>
<li> <li>
<t>the underlying Protocol Stack does not support message bounda ry <t>the underlying Protocol Stack does not support message bounda ry
preservation, and the Message Framer (see <xref target="framing"/>) cannot deter mine preservation and the Message Framer (see <xref target="framing"/>) cannot determ ine
the end of the Message using the buffer space it has available; or</t> the end of the Message using the buffer space it has available; or</t>
</li> </li>
<li> <li>
<t>the underlying Protocol Stack does not support message bounda ry <t>the underlying Protocol Stack does not support message bounda ry
preservation, and no Message Framer was supplied by the application</t> preservation and no Message Framer was supplied by the application.</t>
</li> </li>
</ul> </ul>
<t>Note that in the absence of message boundary preservation or <t>Note that, in the absence of message boundary preservation or
a Message Framer, all bytes received on the Connection will be represented as on e a Message Framer, all bytes received on the Connection will be represented as on e
large Message of indeterminate length.</t> large Message of indeterminate length.</t>
<t>In the following example, an application only wants to receive up to 1000 bytes <t>In the following example, an application only wants to receive up to 1000 bytes
at a time from a Connection. If a 1500-byte Message arrives, it would receive at a time from a Connection. If a 1500-byte Message arrives, it would receive
the Message in two separate <tt>ReceivedPartial</tt> events.</t> the Message in two separate <tt>ReceivedPartial</tt> events.</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection.Receive(1, 1000) Connection.Receive(1, 1000)
// Receive first 1000 bytes, message is incomplete // Receive the first 1000 bytes; message is incomplete
Connection -> ReceivedPartial<messageData(1000 bytes), Connection -> ReceivedPartial<messageData(1000 bytes),
messageContext, false> messageContext, false>
Connection.Receive(1, 1000) Connection.Receive(1, 1000)
// Receive last 500 bytes, message is now complete // Receive the last 500 bytes; message is now complete
Connection -> ReceivedPartial<messageData(500 bytes), Connection -> ReceivedPartial<messageData(500 bytes),
messageContext, true> messageContext, true>
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="receive-error"> <section anchor="receive-error">
<name>ReceiveError</name> <name>ReceiveError</name>
<artwork><![CDATA[ <artwork><![CDATA[
Connection -> ReceiveError<messageContext, reason?> Connection -> ReceiveError<messageContext, reason?>
]]></artwork> ]]></artwork>
<t>A <tt>ReceiveError</tt> occurs when data is received by the under <t>A <tt>ReceiveError</tt> occurs when:</t>
lying Protocol Stack <ul spacing="normal">
that cannot be fully retrieved or parsed, and when it is useful for the applicat <li>data is received by the underlying Protocol Stack
ion that cannot be fully retrieved or parsed, and</li>
to be notified of such errors. For example, a <tt>ReceiveError</tt> can <li>it is useful for the application
to be notified of such errors.</li>
</ul>
<t>For example, a <tt>ReceiveError</tt> can
indicate that a Message (identified via the <tt>messageContext</tt> value) indicate that a Message (identified via the <tt>messageContext</tt> value)
that was being partially received previously, but had not that was being partially received previously, but had not
completed, encountered an error and will not be completed. This can be useful completed, encountered an error and will not be completed. This can be useful
for an application, which might wish to use this error as a hint to remove for an application, which might wish to use this error as a hint to remove
previously received Message parts from memory. As another example, previously received Message parts from memory. As another example,
if an incoming Message does not fulfill the <tt>recvChecksumLen</tt> property if an incoming Message does not fulfill the <tt>recvChecksumLen</tt> property
(see <xref target="conn-recv-checksum"/>), (see <xref target="conn-recv-checksum"/>),
an application can use this error as a hint to inform the peer application an application can use this error as a hint to inform the peer application
to adjust the <tt>msgChecksumLen</tt> property (see <xref target="msg-checksum"/ >).</t> to adjust the <tt>msgChecksumLen</tt> property (see <xref target="msg-checksum"/ >).</t>
<t>In contrast, internal protocol reception errors (e.g., loss causi ng retransmissions <t>In contrast, internal protocol reception errors (e.g., loss causi ng retransmissions
in TCP) are not signalled by this event. Conditions that irrevocably lead to in TCP) are not signaled by this event. Conditions that irrevocably lead to
the termination of the Connection are signaled using <tt>ConnectionError</tt> the termination of the Connection are signaled using <tt>ConnectionError</tt>
(see <xref target="termination"/>).</t> (see <xref target="termination"/>).</t>
</section> </section>
</section> </section>
<section anchor="recv-meta"> <section anchor="recv-meta">
<name>Receive Message Properties</name> <name>Receive Message Properties</name>
<t>Each Message Context could contain metadata from protocols in the P rotocol Stack; <t>Each Message Context could contain metadata from protocols in the P rotocol Stack;
which metadata is available is Protocol Stack dependent. These are exposed throu gh additional read-only Message Properties that can be queried from the MessageC ontext object (see <xref target="msg-ctx"/>) passed by the receive event. which metadata is available is Protocol Stack dependent. These are exposed throu gh additional read-only Message Properties that can be queried from the MessageC ontext object (see <xref target="msg-ctx"/>) passed by the receive event.
The following metadata values are supported:</t> The metadata values in the following subsections are supported.</t>
<section anchor="receive-ecn"> <section anchor="receive-ecn">
<name>UDP(-Lite)-specific Property: ECN</name> <name>Property Specific to UDP and UDP-Lite: ECN</name>
<t>When available, Message metadata carries the value of the Explici t Congestion <t>When available, Message metadata carries the value of the Explici t Congestion
Notification (ECN) field. This information can be used for logging and debugging Notification (ECN) field. This information can be used for logging and debugging
, as well as building applications that need access to information about
and for building applications that need access to information about
the transport internals for their own operation. This property is specific to UD P the transport internals for their own operation. This property is specific to UD P
and UDP-Lite because these protocols do not implement congestion control, and UDP-Lite, because these protocols do not implement congestion control; hence
and hence expose this functionality to the application (see <xref target="RFC829 , they expose this functionality to the application (see <xref target="RFC8293"/
3"/>, >,
following the guidance in <xref target="RFC8085"/>)</t> following the guidance in <xref target="RFC8085"/>).</t>
</section> </section>
<section anchor="receive-early"> <section anchor="receive-early">
<name>Early Data</name> <name>Early Data</name>
<t>In some cases it can be valuable to know whether data was read as part of early <t>In some cases, it can be valuable to know whether data was read a s part of early
data transfer (before Connection establishment has finished). This is useful if data transfer (before Connection establishment has finished). This is useful if
applications need to treat early data separately, applications need to treat early data separately,
e.g., if early data has different security properties than data sent after e.g., if early data has different security properties than data sent after
connection establishment. In the case of TLS 1.3, client early data can be repla yed connection establishment. In the case of TLS 1.3, client early data can be repla yed
maliciously (see <xref target="RFC8446"/>). Thus, receivers might wish to perfor m additional maliciously (see <xref target="RFC8446"/>). Thus, receivers might wish to perfor m additional
checks for early data to ensure it is safely replayable. If TLS 1.3 is available checks for early data to ensure that it is safely replayable. If TLS 1.3 is avai lable
and the recipient Message was sent as part of early data, the corresponding meta data carries and the recipient Message was sent as part of early data, the corresponding meta data carries
a flag indicating as such. If early data is enabled, applications should check t his metadata a flag indicating as such. If early data is enabled, applications should check t his metadata
field for Messages received during Connection establishment and respond accordin gly.</t> field for Messages received during Connection establishment and respond accordin gly.</t>
</section> </section>
<section anchor="receiving-final-messages"> <section anchor="receiving-final-messages">
<name>Receiving Final Messages</name> <name>Receiving Final Messages</name>
<t>The Message Context can indicate whether or not this Message is <t>The Message Context can indicate whether or not this Message is
the Final Message on a Connection. For any Message that is marked as Final, the Final Message on a Connection. For any Message that is marked as Final,
the application can assume that there will be no more Messages received on the the application can assume that there will be no more Messages received on the
Connection once the Message has been completely delivered. This corresponds Connection once the Message has been completely delivered. This corresponds
to the <tt>final</tt> property that can be marked on a sent Message, see <xref t to the <tt>final</tt> property that can be marked on a sent Message; see <xref t
arget="msg-final"/>.</t> arget="msg-final"/>.</t>
<t>Some transport protocols and peers do not support signaling of th <t>Some transport protocols and peers do not support signaling of th
e <tt>final</tt> property. e <tt>final</tt> property. Therefore,
Applications therefore SHOULD NOT rely on receiving a Message marked Final to k applications <bcp14>SHOULD NOT</bcp14> rely on receiving a Message marked Final
now to know
that the sending endpoint is done sending on a Connection.</t> that the sending endpoint is done sending on a Connection.</t>
<t>Any calls to <tt>Receive</tt> once the Final Message has been del ivered will result in errors.</t> <t>Any calls to <tt>Receive</tt> once the Final Message has been del ivered will result in errors.</t>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="termination"> <section anchor="termination">
<name>Connection Termination</name> <name>Connection Termination</name>
<t>A Connection can be terminated i) by the Local Endpoint (i.e., the appl <t>A Connection can be terminated:</t>
ication calls the <tt>Close</tt>, <tt>CloseGroup</tt>, <tt>Abort</tt> or <tt>Abo <ol>
rtGroup</tt> action), ii) by the Remote Endpoint (i.e., the remote application c <li>by the Local Endpoint (i.e., the application calls the <tt>Close</tt>
alls the <tt>Close</tt>, <tt>CloseGroup</tt>, <tt>Abort</tt> or <tt>AbortGroup</ , <tt>CloseGroup</tt>, <tt>Abort</tt>, or <tt>AbortGroup</tt> action),</li>
tt> action), or iii) because of an error (e.g., a timeout). A local call of the <li>by the Remote Endpoint (i.e., the remote application calls the <tt>Cl
<tt>Close</tt> action will ose</tt>, <tt>CloseGroup</tt>, <tt>Abort</tt>, or <tt>AbortGroup</tt> action), o
cause the Connection to either send a <tt>Closed</tt> event or a <tt>ConnectionE r</li>
rror</tt> event, and a local call of <li>because of an error (e.g., a timeout).</li>
the <tt>CloseGroup</tt> action will cause all of the Connections in the group to </ol>
either send a <tt>Closed</tt> event <t>A local call of the <tt>Close</tt> action will
cause the Connection to send either a <tt>Closed</tt> event or a <tt>ConnectionE
rror</tt> event; a local call of
the <tt>CloseGroup</tt> action will cause all of the Connections in the group to
send either a <tt>Closed</tt> event
or a <tt>ConnectionError</tt> event. A local call of the <tt>Abort</tt> action w ill cause the Connection to send or a <tt>ConnectionError</tt> event. A local call of the <tt>Abort</tt> action w ill cause the Connection to send
a <tt>ConnectionError</tt> event, indicating local <tt>Abort</tt> as a reason, a nd a local call of the <tt>AbortGroup</tt> action a <tt>ConnectionError</tt> event, indicating local <tt>Abort</tt> as a reason; a local call of the <tt>AbortGroup</tt> action
will cause all of the Connections in the group to send a <tt>ConnectionError</tt > event, indicating local <tt>Abort</tt> will cause all of the Connections in the group to send a <tt>ConnectionError</tt > event, indicating local <tt>Abort</tt>
as a reason.</t> as a reason.</t>
<t>Remote action calls map to events similar to local calls (e.g., a remot e <tt>Close</tt> causes the <t>Remote action calls map to events similar to local calls (e.g., a remot e <tt>Close</tt> causes the
Connection to either send a <tt>Closed</tt> event or a <tt>ConnectionError</tt> event), but, different from local action calls, Connection to send either a <tt>Closed</tt> event or a <tt>ConnectionError</tt> event), but in contrast to local action calls,
it is not guaranteed that such events will indeed be invoked. When an applicatio n needs to free resources it is not guaranteed that such events will indeed be invoked. When an applicatio n needs to free resources
associated with a Connection, it ought not to therefore rely on the invocation o associated with a Connection, it ought not rely on the invocation of such events
f such events due to due to
termination calls from the Remote Endpoint, but instead use the local terminatio termination calls from the Remote Endpoint; instead, it should use the local ter
n actions.</t> mination actions.</t>
<t><tt>Close</tt> terminates a Connection after satisfying all the require ments that were <t><tt>Close</tt> terminates a Connection after satisfying all the require ments that were
specified regarding the delivery of Messages that the application has already specified regarding the delivery of Messages that the application has already
given to the Transport Services system. Upon successfully satisfying all these given to the Transport Services system. Upon successfully satisfying all these
requirements, the Connection will send the <tt>Closed</tt> event. For example, i f reliable delivery was requested requirements, the Connection will send the <tt>Closed</tt> event. For example, i f reliable delivery was requested
for a Message handed over before calling <tt>Close</tt>, the <tt>Closed</tt> eve nt will signify for a Message handed over before calling <tt>Close</tt>, the <tt>Closed</tt> eve nt will signify
that this Message has indeed been delivered. This action does not affect any oth er Connection that this Message has indeed been delivered. This action does not affect any oth er Connection
in the same Connection Group.</t> in the same Connection Group.</t>
<t>An application MUST NOT assume that it can receive any further data on a Connection <t>An application <bcp14>MUST NOT</bcp14> assume that it can receive any f urther data on a Connection
for which it has called <tt>Close</tt>, even if such data is already in flight.< /t> for which it has called <tt>Close</tt>, even if such data is already in flight.< /t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection.Close() Connection.Close()
]]></artwork> ]]></artwork>
<t>The <tt>Closed</tt> event informs the application that a <tt>Close</tt> action has successfully <t>The <tt>Closed</tt> event informs the application that a <tt>Close</tt> action has successfully
completed, or that the Remote Endpoint has closed the Connection. completed or that the Remote Endpoint has closed the Connection.
There is no guarantee that a remote <tt>Close</tt> will be signaled.</t> There is no guarantee that a remote <tt>Close</tt> will be signaled.</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection -> Closed<> Connection -> Closed<>
]]></artwork> ]]></artwork>
<t><tt>Abort</tt> terminates a Connection without delivering any remaining Messages. This action does <t><tt>Abort</tt> terminates a Connection without delivering any remaining Messages. This action does
not affect any other Connection that is entangled with this one in a Connection Group. not affect any other Connection that is entangled with this one in a Connection Group.
When the <tt>Abort</tt> action has finished, the Connection will send a <tt>Conn ectionError</tt> event, When the <tt>Abort</tt> action has finished, the Connection will send a <tt>Conn ectionError</tt> event,
indicating local <tt>Abort</tt> as a reason.</t> indicating local <tt>Abort</tt> as a reason.</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection.Abort() Connection.Abort()
skipping to change at line 3661 skipping to change at line 4137
<artwork><![CDATA[ <artwork><![CDATA[
Connection.CloseGroup() Connection.CloseGroup()
]]></artwork> ]]></artwork>
<t><tt>AbortGroup</tt> terminates a Connection and any other Connections t hat are <t><tt>AbortGroup</tt> terminates a Connection and any other Connections t hat are
in the same Connection Group without delivering any remaining Messages. in the same Connection Group without delivering any remaining Messages.
When the <tt>AbortGroup</tt> action has finished, all Connections in the group w ill When the <tt>AbortGroup</tt> action has finished, all Connections in the group w ill
send a <tt>ConnectionError</tt> event, indicating local <tt>Abort</tt> as a reas on.</t> send a <tt>ConnectionError</tt> event, indicating local <tt>Abort</tt> as a reas on.</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection.AbortGroup() Connection.AbortGroup()
]]></artwork> ]]></artwork>
<t>A <tt>ConnectionError</tt> informs the application that: 1) data could <t>A <tt>ConnectionError</tt> informs the application that:</t>
not be delivered to the <ol><li>data could not be delivered to the
peer after a timeout, peer after a timeout
or 2) the Connection has been aborted (e.g., because the peer has called <tt>Abo or</li><li>the Connection has been aborted (e.g., because the peer has cal
rt</tt>). led <tt>Abort</tt>).</li></ol>
There is no guarantee that an <tt>Abort</tt> from the peer will be signaled.</t> <t>There is no guarantee that an <tt>Abort</tt> from the peer will be sign
aled.</t>
<artwork><![CDATA[ <artwork><![CDATA[
Connection -> ConnectionError<reason?> Connection -> ConnectionError<reason?>
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="state-ordering"> <section anchor="state-ordering">
<name>Connection State and Ordering of Operations and Events</name> <name>Connection State and Ordering of Operations and Events</name>
<t>This Transport Services API is designed to be independent of an impleme ntation's <t>This Transport Services API is designed to be independent of an impleme ntation's
concurrency model. The details of how exactly actions are handled, and how concurrency model. The exact details regarding how actions are handled, and how
events are dispatched, are implementation dependent.</t> events are dispatched, are implementation dependent.</t>
<t>Some transitions of Connection states are associated with events:</t> <t>Some transitions of Connection states are associated with events:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t><tt>Ready&lt;&gt;</tt> occurs when a Connection created with <tt>In itiate</tt> or <t><tt>Ready&lt;&gt;</tt> occurs when a Connection created with <tt>In itiate</tt> or
<tt>InitiateWithSend</tt> transitions to Established state.</t> <tt>InitiateWithSend</tt> transitions to Established state.</t>
</li> </li>
<li> <li>
<t><tt>ConnectionReceived&lt;&gt;</tt> occurs when a Connection create d with <tt>Listen</tt> <t><tt>ConnectionReceived&lt;&gt;</tt> occurs when a Connection create d with <tt>Listen</tt>
transitions to Established state.</t> transitions to Established state.</t>
skipping to change at line 3714 skipping to change at line 4191
<artwork><![CDATA[ <artwork><![CDATA[
(*) (**) (*) (**)
Establishing -----> Established -----> Closing ------> Closed Establishing -----> Established -----> Closing ------> Closed
| ^ | ^
| | | |
+---------------------------------------------------+ +---------------------------------------------------+
EstablishmentError<> EstablishmentError<>
(*) Ready<>, ConnectionReceived<>, RendezvousDone<> (*) Ready<>, ConnectionReceived<>, RendezvousDone<>
(**) Closed<>, ConnectionError<> (**) Closed<>, ConnectionError<>
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The Transport Services API provides the following guarantees about the ordering of <t>The Transport Services API provides the following guarantees about the ordering of
operations:</t> operations:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t><tt>Sent&lt;&gt;</tt> events will occur on a Connection in the orde r in which the Messages <t><tt>Sent&lt;&gt;</tt> events will occur on a Connection in the orde r in which the Messages
were sent (i.e., delivered to the kernel or to the network interface, were sent (i.e., delivered to the kernel or to the network interface,
depending on implementation).</t> depending on the implementation).</t>
</li> </li>
<li> <li>
<t><tt>Received&lt;&gt;</tt> will never occur on a Connection before i <t><tt>Received&lt;&gt;</tt> will never occur on a Connection before i
t is Established; i.e. t is Established, i.e.,
before a <tt>Ready&lt;&gt;</tt> event on that Connection, or a <tt>ConnectionRec before a <tt>Ready&lt;&gt;</tt> event on that Connection or a <tt>ConnectionRece
eived&lt;&gt;</tt> or ived&lt;&gt;</tt> or
<tt>RendezvousDone&lt;&gt;</tt> containing that Connection.</t> <tt>RendezvousDone&lt;&gt;</tt> containing that Connection.</t>
</li> </li>
<li> <li>
<t>No events will occur on a Connection after it is closed; i.e., afte r a <t>No events will occur on a Connection after it is closed, i.e., afte r a
<tt>Closed&lt;&gt;</tt> event, an <tt>EstablishmentError&lt;&gt;</tt> or <tt>Con nectionError&lt;&gt;</tt> will not occur on that Connection. To <tt>Closed&lt;&gt;</tt> event, an <tt>EstablishmentError&lt;&gt;</tt> or <tt>Con nectionError&lt;&gt;</tt> will not occur on that Connection. To
ensure this ordering, <tt>Closed&lt;&gt;</tt> will not occur on a Connection whi le other ensure this ordering, <tt>Closed&lt;&gt;</tt> will not occur on a Connection whi le other
events on the Connection are still locally outstanding (i.e., known to the events on the Connection are still locally outstanding (i.e., known to the
Transport Services API and waiting to be dealt with by the application).</t> Transport Services API and waiting to be dealt with by the application).</t>
</li> </li>
</ul> </ul>
</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.
Later versions of this document might create IANA registries for generic transpo <t>This document has no IANA actions.</t>
rt property names and transport property namespaces (see <xref target="property-
names"/>).</t> <t>Future works might create IANA registries for generic transport propert
y names and transport property namespaces (see <xref target="property-names"/>).
</t>
</section> </section>
<section anchor="privacy-security"> <section anchor="privacy-security">
<name>Privacy and Security Considerations</name> <name>Privacy and Security Considerations</name>
<t>This document describes a generic API for interacting with a Transport Services system. <t>This document describes a generic API for interacting with a Transport Services system.
Part of this API includes configuration details for transport security protocols , as discussed Part of this API includes configuration details for transport security protocols , as discussed
in <xref target="security-parameters"/>. It does not recommend use (or disuse) o f specific in <xref target="security-parameters"/>. It does not recommend use (or disuse) o f specific
algorithms or protocols. Any API-compatible transport security protocol ought to work in a Transport Services system. algorithms or protocols. Any API-compatible transport security protocol ought to work in a Transport Services system.
Security considerations for these protocols are discussed in the respective spec ifications.</t> Security considerations for these protocols are discussed in the respective spec ifications.</t>
<t><xref target="I-D.ietf-taps-arch"/> provides general security considera tions and requirements for any system that implements the Transport Services arc hitecture. These include recommendations of relevance to the API, e.g. regarding the use of keying material.</t> <t><xref target="RFC9621"/> provides general security considerations and r equirements for any system that implements the Transport Services architecture. These include recommendations of relevance to the API, e.g., regarding the use o f keying material.</t>
<t>The described API is used to exchange information between an applicatio n and the Transport Services system. While <t>The described API is used to exchange information between an applicatio n and the Transport Services system. While
it is not necessarily expected that both systems are implemented by the same aut hority, it is expected it is not necessarily expected that both systems are implemented by the same aut hority, it is expected
that the Transport Services Implementation is either provided as a library that that the Transport Services Implementation is provided as a library either that
is selected by the application is selected by the application
from a trusted party, or that it is part of the operating system that the applic from a trusted party or that it is part of the operating system that the applica
ation also relies on for tion also relies on for
other tasks.</t> other tasks.</t>
<t>In either case, the Transport Services API is an internal interface tha t is used to exchange information locally between two systems. <t>In either case, the Transport Services API is an internal interface tha t is used to exchange information locally between two systems.
However, as the Transport Services system is responsible for network communicati on, it is in the position to However, as the Transport Services system is responsible for network communicati on, it is in the position to
potentially share any information provided by the application with the network o r another communication peer. potentially share any information provided by the application with the network o r another communication peer.
Most of the information provided over the Transport Services API are useful to c Most of the information provided over the Transport Services API is useful to co
onfigure and select protocols and paths nfigure and select protocols and paths
and are not necessarily privacy-sensitive. Still, some information could be priv and is not necessarily privacy sensitive. Still, some information could be priva
acy sensitive because cy sensitive because
it might reveal usage characteristics and habits of the user of an application.< /t> it might reveal usage characteristics and habits of the user of an application.< /t>
<t>Of course any communication over a network reveals usage characteristic s, because all <t>Of course, any communication over a network reveals usage characteristi cs, because all
packets, as well as their timing and size, are part of the network-visible wire image <xref target="RFC8546"/>. However, packets, as well as their timing and size, are part of the network-visible wire image <xref target="RFC8546"/>. However,
the selection of a protocol and its configuration also impacts which information is visible, potentially in the selection of a protocol and its configuration also impacts which information is visible, potentially in
clear text, and which other entities can access it. How Transport Services syste ms ought to choose protocols depending on the security properties required is ou t of scope of this specification, as it is limited to transport protocols. The c hoice of a security protocol can be informed by the survey provided in <xref tar get="RFC8922"/>.</t> clear text, and which other entities can access it. How Transport Services syste ms ought to choose protocols -- depending on the security properties required -- is out of scope for this specification, as it is limited to transport protocols . The choice of a security protocol can be informed by the survey provided in <x ref target="RFC8922"/>.</t>
<t>In most cases, information provided for protocol and path selection <t>In most cases, information provided for protocol and path selection
does not directly translate to information that can be observed by network devic es on the path. does not directly translate to information that can be observed by network devic es on the path.
However, there might be specific configuration However, there might be specific configuration
information that is intended for path exposure, e.g., a DiffServ codepoint setti ng, that is either provided information that is intended for path exposure, e.g., a Diffserv codepoint setti ng that is either provided
directly by the application or indirectly configured for a traffic profile.</t> directly by the application or indirectly configured for a traffic profile.</t>
<t>Applications should be aware that a single communication attempt can le <t>Applications should be aware that a single communication attempt can le
ad to more than one connection establishment procedure. ad to more than one connection establishment procedure. For example,
This is the case, for example, when the Transport Services system also executes this is the case when:</t>
name resolution, when support mechanisms such as <ul>
TURN or ICE are used to establish connectivity, if protocols or paths are raced, <li>the Transport Services system also executes name resolution,</li>
or if a path fails and <li>support mechanisms such as
fallback or re-establishment is supported in the Transport Services system. Appl TURN or ICE are used to establish connectivity if protocols or paths are raced o
ications should take special r if a path fails and
fallback or re-establishment is supported in the Transport Services syste
m.</li>
</ul>
<t>Applications should take special
care when using 0-RTT session resumption (see <xref target="prop-0rtt"/>), as ea rly data sent across multiple paths during care when using 0-RTT session resumption (see <xref target="prop-0rtt"/>), as ea rly data sent across multiple paths during
connection establishment could reveal information that can be used to correlate endpoints on these paths.</t> connection establishment could reveal information that can be used to correlate endpoints on these paths.</t>
<t>Applications should also take care to not assume that all data received using the Transport Services API is always <t>Applications should also take care to not assume that all data received using the Transport Services API is always
complete or well-formed. Specifically, Messages that are received partially <xre f target="receive-partial"/> could be a source complete or well-formed. Specifically, Messages that are received partially (see <xref target="receive-partial"/> )could be a source
of truncation attacks if applications do not distinguish between partial Message s and complete Messages.</t> of truncation attacks if applications do not distinguish between partial Message s and complete Messages.</t>
<t>The Transport Services API explicitly does not require the application to resolve names, though there is <t>The Transport Services API explicitly does not require the application to resolve names, though there is
a tradeoff between early and late binding of addresses to names. Early binding a trade-off between early and late binding of addresses to names. Early binding
allows the Transport Services Implementation to reduce Connection setup latency, allows the Transport Services Implementation to reduce Connection setup latency.
at the cost This is at the cost
of potentially limited scope for alternate path discovery during Connection of potentially limited scope for alternate path discovery during Connection
establishment, as well as potential additional information leakage about establishment as well as potential additional information leakage about
application interest when used with a resolution method (such as DNS without application interest when used with a resolution method (such as DNS without
TLS) which does not protect query confidentiality. TLS) that does not protect query confidentiality.
Names used with the Transport Services API SHOULD be fully-qualified domain name Names used with the Transport Services API <bcp14>SHOULD</bcp14> be FQDNs;
s (FQDNs); not providing an FQDN will result in the Transport Services Implement not providing an FQDN will result in the Transport Services Implementation need
ation needing to to use DNS search domains for name resolution, which might lead ing to use DNS search domains for name resolution, which might lead to inconsist
to inconsistent or unpredictable behavior.</t> ent or unpredictable behavior.</t>
<t>These communication activities are not different from what is used toda
y. However, <!--[rfced] In the following text:
Original:
The Transport Services API is designed such that protocol and path
selection can be limited to a small and controlled set if the
application requires this or to implement a security policy. can be
limited to a small and controlled set if required by the application
to perform a function or to provide security.
a) we assume the period after "policy" is in error. We have deleted.
Please let us know any objections.
b) What is the subject of "implement"?
Perhaps:
The Transport Services API is designed such that, if required by the application
:
*protocol and path selection can be limited to a small and controlled
set, or
*the implementation of a security policy can be limited to a small and
controlled set to perform a function or to provide security.
-->
<t>These communication activities are not different from what is used at t
he time of writing. However,
the goal of a Transport Services system is to support the goal of a Transport Services system is to support
such mechanisms as a generic service within the transport layer. This enables ap plications to more dynamically such mechanisms as a generic service within the transport layer. This enables ap plications to more dynamically
benefit from innovations and new protocols in the transport, although it reduces transparency of the benefit from innovations and new protocols in the transport, although it reduces transparency of the
underlying communication actions to the application itself. The Transport Servic es API is designed such that protocol and path selection underlying communication actions to the application itself. The Transport Servic es API is designed such that protocol and path selection
can be limited to a small and controlled set if the application requires this or to implement a security policy. can be limited to a small and controlled set, if the application requires this, or to implement a security policy
can be limited to a small and controlled set if required by the application to p erform a function or to provide security. can be limited to a small and controlled set if required by the application to p erform a function or to provide security.
Further, Further,
introspection on the properties of Connection objects allows an application to d etermine which protocol(s) and path(s) are in use. introspection on the properties of Connection objects allows an application to d etermine which protocol(s) and path(s) are in use.
A Transport Services system SHOULD provide a facility logging the communication A Transport Services system <bcp14>SHOULD</bcp14> provide a facility logging the
events of each Connection.</t> communication events of each Connection.</t>
</section>
<section anchor="acknowledgments">
<name>Acknowledgments</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) and No. 688421 (MA
MI).</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>This work has been supported by the Research Council of Norway under it
s "Toppforsk"
programme through the "OCARINA" project.</t>
<t>Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric Kin
near for
their implementation and design efforts, including Happy Eyeballs, that heavily
influenced this work. Thanks to Laurent Chuat and Jason Lee for initial work on
the Post Sockets interface, from which this work has evolved. Thanks to
Maximilian Franke for asking good questions based on implementation experience
and for contributing text, e.g., on multicast.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC7301" to="ALPN"/>
<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="I-D.ietf-taps-arch">
<front>
<title>Architecture and Requirements for Transport Services</title>
<author fullname="Tommy Pauly" initials="T." surname="Pauly">
<organization>Apple Inc.</organization>
</author>
<author fullname="Brian Trammell" initials="B." surname="Trammell">
<organization>Google Switzerland GmbH</organization>
</author>
<author fullname="Anna Brunstrom" initials="A." surname="Brunstrom">
<organization>Karlstad University</organization>
</author>
<author fullname="Gorry Fairhurst" initials="G." surname="Fairhurst"
>
<organization>University of Aberdeen</organization>
</author>
<author fullname="Colin Perkins" initials="C." surname="Perkins">
<organization>University of Glasgow</organization>
</author>
<date day="9" month="November" year="2023"/>
<abstract>
<t> This document describes an architecture for exposing transpo
rt
protocol features to applications for network communication. This
system exposes transport protocol features to applications for
network communication. The Transport Services Application
Programming Interface (API) is based on an asynchronous, event-driven
interaction pattern. This API uses messages for representing data
transfer to applications, and describes how a Transport Services
Implementation can use multiple 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
Transport Service API and a Transport Services Implementation.
</t> <!-- draft-ietf-taps-arch (RFC 9621) -->
</abstract> <reference anchor="RFC9621" target="https://www.rfc-editor.org/info/RFC96
</front> 21">
<seriesInfo name="Internet-Draft" value="draft-ietf-taps-arch-19"/> <front>
</reference> <title>Architecture and Requirements for Transport Services</title>
<reference anchor="RFC2119"> <author initials="T." surname="Pauly" fullname="Tommy Pauly" role="ed
<front> itor">
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <organization>Apple Inc.</organization>
le> </author>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <author initials="B." surname="Trammell" fullname="Brian Trammell" ro
<date month="March" year="1997"/> le="editor">
<abstract> <organization>Google Switzerland GmbH</organization>
<t>In many standards track documents several words are used to sig </author>
nify the requirements in the specification. These words are often capitalized. T <author initials="A." surname="Brunstrom" fullname="Anna Brunstrom">
his document defines these words as they should be interpreted in IETF documents <organization>Karlstad University</organization>
. This document specifies an Internet Best Current Practices for the Internet Co </author>
mmunity, and requests discussion and suggestions for improvements.</t> <author initials="G." surname="Fairhurst" fullname="Gorry Fairhurst">
</abstract> <organization>University of Aberdeen</organization>
</front> </author>
<seriesInfo name="BCP" value="14"/> <author initials="C. S." surname="Perkins" fullname="Colin S. Perkins
<seriesInfo name="RFC" value="2119"/> ">
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <organization>University of Glasgow</organization>
</reference> </author>
<reference anchor="RFC8174"> <date month="November" year="2024"/>
<front> </front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti <seriesInfo name="RFC" value="9621"/>
tle> <seriesInfo name="DOI" value="10.17487/RFC9621"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/> </reference>
<date month="May" year="2017"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<t>RFC 2119 specifies common key words that may be used in protoco 19.xml"/>
l specifications. This document aims to reduce the ambiguity by clarifying that <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
only UPPERCASE usage of the key words have the defined special meanings.</t> 74.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.73
</front> 01.xml"/>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="ALPN">
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Neg
otiation Extension</title>
<author fullname="S. Friedl" initials="S." surname="Friedl"/>
<author fullname="A. Popov" initials="A." surname="Popov"/>
<author fullname="A. Langley" initials="A." surname="Langley"/>
<author fullname="E. Stephan" initials="E." surname="Stephan"/>
<date month="July" year="2014"/>
<abstract>
<t>This document describes a Transport Layer Security (TLS) extens
ion for application-layer protocol negotiation within the TLS handshake. For ins
tances in which multiple application protocols are supported on the same TCP or
UDP port, this extension allows the application layer to negotiate which protoco
l will be used within the TLS connection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7301"/>
<seriesInfo name="DOI" value="10.17487/RFC7301"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="I-D.ietf-taps-impl">
<front>
<title>Implementing Interfaces to Transport Services</title>
<author fullname="Anna Brunstrom" initials="A." surname="Brunstrom">
<organization>Karlstad University</organization>
</author>
<author fullname="Tommy Pauly" initials="T." surname="Pauly">
<organization>Apple Inc.</organization>
</author>
<author fullname="Reese Enghardt" initials="R." surname="Enghardt">
<organization>Netflix</organization>
</author>
<author fullname="Philipp S. Tiesel" initials="P. S." surname="Tiese
l">
<organization>SAP SE</organization>
</author>
<author fullname="Michael Welzl" initials="M." surname="Welzl">
<organization>University of Oslo</organization>
</author>
<date day="14" month="December" year="2023"/>
<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> <!-- draft-ietf-taps-impl ( RFC 9623) -->
</abstract> <reference anchor="RFC9623" target="https://www.rfc-editor.org/info/rfc9
</front> 623">
<seriesInfo name="Internet-Draft" value="draft-ietf-taps-impl-18"/> <front>
</reference> <title>Implementing Interfaces to Transport Services</title>
<reference anchor="RFC7556"> <author initials="A." surname="Brunstrom" fullname="Anna Brunstrom" r
<front> ole="editor">
<title>Multiple Provisioning Domain Architecture</title> <organization>Karlstad University</organization>
<author fullname="D. Anipko" initials="D." role="editor" surname="An </author>
ipko"/> <author initials="T." surname="Pauly" fullname="Tommy Pauly" role="ed
<date month="June" year="2015"/> itor">
<abstract> <organization>Apple Inc.</organization>
<t>This document is a product of the work of the Multiple Interfac </author>
es Architecture Design team. It outlines a solution framework for some of the is <author initials="R." surname="Enghardt" fullname="Reese Enghardt">
sues experienced by nodes that can be attached to multiple networks simultaneous <organization>Netflix</organization>
ly. The framework defines the concept of a Provisioning Domain (PvD), which is a </author>
consistent set of network configuration information. PvD-aware nodes learn PvD- <author initials="P. S." surname="Tiesel" fullname="Philipp S. Tiesel
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 <organization>SAP SE</organization>
ce of multiple concurrent connections.</t> </author>
</abstract> <author initials="M." surname="Welzl" fullname="Michael Welzl">
</front> <organization>University of Oslo</organization>
<seriesInfo name="RFC" value="7556"/> </author>
<seriesInfo name="DOI" value="10.17487/RFC7556"/> <date month="November" year="2024"/>
</reference> </front>
<reference anchor="TCP-COUPLING"> <seriesInfo name="RFC" value="9623"/>
<seriesInfo name="DOI" value="10.17487/RFC9623"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.75
56.xml"/>
<reference anchor="TCP-COUPLING" target="https://ieeexplore.ieee.org/doc
ument/8406887">
<front> <front>
<title>ctrlTCP: Reducing Latency through Coupled, Heterogeneous Mult i-Flow TCP Congestion Control</title> <title>ctrlTCP: Reducing latency through coupled, heterogeneous mult i-flow TCP congestion control</title>
<author initials="S." surname="Islam" fullname="Safiqul Islam"> <author initials="S." surname="Islam" fullname="Safiqul Islam">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Welzl" fullname="Michael Welzl"> <author initials="M." surname="Welzl" fullname="Michael Welzl">
<organization/> <organization/>
</author> </author>
<author initials="K." surname="Hiorth" fullname="Kristian Hiorth"> <author initials="K." surname="Hiorth" fullname="Kristian Hiorth">
<organization/> <organization/>
</author> </author>
<author initials="D." surname="Hayes" fullname="David Hayes"> <author initials="D." surname="Hayes" fullname="David Hayes">
<organization/> <organization/>
</author> </author>
<author initials="G." surname="Armitage" fullname="Grenville Armitag e"> <author initials="G." surname="Armitage" fullname="Grenville Armitag e">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Gjessing" fullname="Stein Gjessing"> <author initials="S." surname="Gjessing" fullname="Stein Gjessing">
<organization/> <organization/>
</author> </author>
<date year="2018"/> <date year="2018"/>
</front> </front>
<seriesInfo name="IEEE INFOCOM Global Internet Symposium (GI) workshop <refcontent>IEEE INFOCOM 2018 - IEEE Conference on Computer Communicat
(GI 2018)" value=""/> ions Workshops (INFOCOM WKSHPS)</refcontent>
</reference> <seriesInfo name="DOI" value="10.1109/INFCOMW.2018.8406887"/>
<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="RFC791">
<front>
<title>Internet Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel"/>
<date month="September" year="1981"/>
</front>
<seriesInfo name="STD" value="5"/>
<seriesInfo name="RFC" value="791"/>
<seriesInfo name="DOI" value="10.17487/RFC0791"/>
</reference>
<reference anchor="RFC4291">
<front>
<title>IP Version 6 Addressing Architecture</title>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<date month="February" year="2006"/>
<abstract>
<t>This specification defines the addressing architecture of the I
P Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, te
xt representations of IPv6 addresses, definition of IPv6 unicast addresses, anyc
ast addresses, and multicast addresses, and an IPv6 node's required addresses.</
t>
<t>This document obsoletes RFC 3513, "IP Version 6 Addressing Arch
itecture". [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4291"/>
<seriesInfo name="DOI" value="10.17487/RFC4291"/>
</reference>
<reference anchor="RFC2914">
<front>
<title>Congestion Control Principles</title>
<author fullname="S. Floyd" initials="S." surname="Floyd"/>
<date month="September" year="2000"/>
<abstract>
<t>The goal of this document is to explain the need for congestion
control in the Internet, and to discuss what constitutes correct congestion con
trol. This document specifies an Internet Best Current Practices for the Interne
t Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="41"/>
<seriesInfo name="RFC" value="2914"/>
<seriesInfo name="DOI" value="10.17487/RFC2914"/>
</reference>
<reference anchor="RFC8084">
<front>
<title>Network Transport Circuit Breakers</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<date month="March" year="2017"/>
<abstract>
<t>This document explains what is meant by the term "network trans
port Circuit Breaker". It describes the need for Circuit Breakers (CBs) for netw
ork tunnels and applications when using non-congestion- controlled traffic and e
xplains where CBs are, and are not, needed. It also defines requirements for bui
lding a CB and the expected outcomes of using a CB within the Internet.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="208"/>
<seriesInfo name="RFC" value="8084"/>
<seriesInfo name="DOI" value="10.17487/RFC8084"/>
</reference>
<reference anchor="RFC8801">
<front>
<title>Discovering Provisioning Domain Names and Data</title>
<author fullname="P. Pfister" initials="P." surname="Pfister"/>
<author fullname="É. Vyncke" surname="É. Vyncke"/>
<author fullname="T. Pauly" initials="T." surname="Pauly"/>
<author fullname="D. Schinazi" initials="D." surname="Schinazi"/>
<author fullname="W. Shao" initials="W." surname="Shao"/>
<date month="July" year="2020"/>
<abstract>
<t>Provisioning Domains (PvDs) are defined as consistent sets of n
etwork configuration information. PvDs allows hosts to manage connections to mul
tiple networks and interfaces simultaneously, such as when a home router provide
s connectivity through both a broadband and cellular network provider.</t>
<t>This document defines a mechanism for explicitly identifying Pv
Ds through a Router Advertisement (RA) option. This RA option announces a PvD id
entifier, which hosts can compare to differentiate between PvDs. The option can
directly carry some information about a PvD and can optionally point to PvD Addi
tional Information that can be retrieved using HTTP over TLS.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8801"/>
<seriesInfo name="DOI" value="10.17487/RFC8801"/>
</reference>
<reference anchor="RFC8981">
<front>
<title>Temporary Address Extensions for Stateless Address Autoconfig
uration in IPv6</title>
<author fullname="F. Gont" initials="F." surname="Gont"/>
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="R. Draves" initials="R." surname="Draves"/>
<date month="February" year="2021"/>
<abstract>
<t>This document describes an extension to IPv6 Stateless Address
Autoconfiguration that causes hosts to generate temporary addresses with randomi
zed interface identifiers for each prefix advertised with autoconfiguration enab
led. Changing addresses over time limits the window of time during which eavesdr
oppers and other information collectors may trivially perform address-based netw
ork-activity correlation when the same address is employed for multiple transact
ions by the same host. Additionally, it reduces the window of exposure of a host
as being accessible via an address that becomes revealed as a result of active
communication. This document obsoletes RFC 4941.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8981"/>
<seriesInfo name="DOI" value="10.17487/RFC8981"/>
</reference>
<reference anchor="RFC8085">
<front>
<title>UDP Usage Guidelines</title>
<author fullname="L. Eggert" initials="L." surname="Eggert"/>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="G. Shepherd" initials="G." surname="Shepherd"/>
<date month="March" year="2017"/>
<abstract>
<t>The User Datagram Protocol (UDP) provides a minimal message-pas
sing transport that has no inherent congestion control mechanisms. This document
provides guidelines on the use of UDP for the designers of applications, tunnel
s, and other protocols that use UDP. Congestion control guidelines are a primary
focus, but the document also provides guidance on other topics, including messa
ge sizes, reliability, checksums, middlebox traversal, the use of Explicit Conge
stion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports
.</t>
<t>Because congestion control is critical to the stable operation
of the Internet, applications and other protocols that choose to use UDP as an I
nternet transport must employ mechanisms to prevent congestion collapse and to e
stablish some degree of fairness with concurrent traffic. They may also need to
implement additional mechanisms, depending on how they use UDP.</t>
<t>Some guidance is also applicable to the design of other protoco
ls (e.g., protocols layered directly on IP or via IP-based tunnels), especially
when these protocols do not themselves provide congestion control.</t>
<t>This document obsoletes RFC 5405 and adds guidelines for multic
ast UDP usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
<reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper"/>
<author fullname="S. Santesson" initials="S." surname="Santesson"/>
<author fullname="S. Farrell" initials="S." surname="Farrell"/>
<author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="W. Polk" initials="W." surname="Polk"/>
<date month="May" year="2008"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif
icate revocation list (CRL) for use in the Internet. An overview of this approac
h and model is provided as an introduction. The X.509 v3 certificate format is d
escribed in detail, with additional information regarding the format and semanti
cs of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with stan
dard and Internet-specific extensions. An algorithm for X.509 certification path
validation is described. An ASN.1 module and examples are provided in the appen
dices. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</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="RFC8489">
<front>
<title>Session Traversal Utilities for NAT (STUN)</title>
<author fullname="M. Petit-Huguenin" initials="M." surname="Petit-Hu
guenin"/>
<author fullname="G. Salgueiro" initials="G." surname="Salgueiro"/>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
<author fullname="D. Wing" initials="D." surname="Wing"/>
<author fullname="R. Mahy" initials="R." surname="Mahy"/>
<author fullname="P. Matthews" initials="P." surname="Matthews"/>
<date month="February" year="2020"/>
<abstract>
<t>Session Traversal Utilities for NAT (STUN) is a protocol that s
erves as a tool for other protocols in dealing with NAT traversal. It can be use
d by an endpoint to determine the IP address and port allocated to it by a NAT.
It can also be used to check connectivity between two endpoints and as a keep-al
ive protocol to maintain NAT bindings. STUN works with many existing NATs and do
es 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.</t>
<t>This document obsoletes RFC 5389.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8489"/>
<seriesInfo name="DOI" value="10.17487/RFC8489"/>
</reference>
<reference anchor="RFC8656">
<front>
<title>Traversal Using Relays around NAT (TURN): Relay Extensions to
Session Traversal Utilities for NAT (STUN)</title>
<author fullname="T. Reddy" initials="T." role="editor" surname="Red
dy"/>
<author fullname="A. Johnston" initials="A." role="editor" surname="
Johnston"/>
<author fullname="P. Matthews" initials="P." surname="Matthews"/>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
<date month="February" year="2020"/>
<abstract>
<t>If a host is located behind a NAT, it can be impossible for tha
t host to communicate directly with other hosts (peers) in certain situations. I
n these situations, it is necessary for the host to use the services of an inter
mediate node that acts as a communication relay. This specification defines a pr
otocol, called "Traversal Using Relays around NAT" (TURN), that allows the host
to control the operation of the relay and to exchange packets with its peers usi
ng the relay. TURN differs from other relay control protocols in that it allows
a client to communicate with multiple peers using a single relay address.</t>
<t>The TURN protocol was designed to be used as part of the Intera
ctive Connectivity Establishment (ICE) approach to NAT traversal, though it can
also be used without ICE.</t>
<t>This document obsoletes RFCs 5766 and 6156.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8656"/>
<seriesInfo name="DOI" value="10.17487/RFC8656"/>
</reference>
<reference anchor="RFC3261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne
"/>
<author fullname="G. Camarillo" initials="G." surname="Camarillo"/>
<author fullname="A. Johnston" initials="A." surname="Johnston"/>
<author fullname="J. Peterson" initials="J." surname="Peterson"/>
<author fullname="R. Sparks" initials="R." surname="Sparks"/>
<author fullname="M. Handley" initials="M." surname="Handley"/>
<author fullname="E. Schooler" initials="E." surname="Schooler"/>
<date month="June" year="2002"/>
<abstract>
<t>This document describes Session Initiation Protocol (SIP), an a
pplication-layer control (signaling) protocol for creating, modifying, and termi
nating sessions with one or more participants. These sessions include Internet t
elephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3261"/>
<seriesInfo name="DOI" value="10.17487/RFC3261"/>
</reference>
<reference anchor="RFC7478">
<front>
<title>Web Real-Time Communication Use Cases and Requirements</title
>
<author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
<author fullname="S. Hakansson" initials="S." surname="Hakansson"/>
<author fullname="G. Eriksson" initials="G." surname="Eriksson"/>
<date month="March" year="2015"/>
<abstract>
<t>This document describes web-based real-time communication use c
ases. Requirements on the browser functionality are derived from the use cases.<
/t>
<t>This document was developed in an initial phase of the work wit
h rather minor updates at later stages. It has not really served as a tool in de
ciding features or scope for the WG's efforts so far. It is being published to r
ecord the early conclusions of the WG. It will not be used as a set of rigid gui
delines that specifications and implementations will be held to in the future.</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="7478"/>
<seriesInfo name="DOI" value="10.17487/RFC7478"/>
</reference>
<reference anchor="RFC8699">
<front>
<title>Coupled Congestion Control for RTP Media</title>
<author fullname="S. Islam" initials="S." surname="Islam"/>
<author fullname="M. Welzl" initials="M." surname="Welzl"/>
<author fullname="S. Gjessing" initials="S." surname="Gjessing"/>
<date month="January" year="2020"/>
<abstract>
<t>When multiple congestion-controlled Real-time Transport Protoco
l (RTP) sessions traverse the same network bottleneck, combining their controls
can improve the total on-the-wire behavior in terms of delay, loss, and fairness
. This document describes such a method for flows that have the same sender, in
a way that is as flexible and simple as possible while minimizing the number of
changes needed to existing RTP applications. This document also specifies how to
apply the method for the Network-Assisted Dynamic Adaptation (NADA) congestion
control algorithm and provides suggestions on how to apply it to other congestio
n control algorithms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8699"/>
<seriesInfo name="DOI" value="10.17487/RFC8699"/>
</reference>
<reference anchor="RFC8838">
<front>
<title>Trickle ICE: Incremental Provisioning of Candidates for the I
nteractive Connectivity Establishment (ICE) Protocol</title>
<author fullname="E. Ivov" initials="E." surname="Ivov"/>
<author fullname="J. Uberti" initials="J." surname="Uberti"/>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<date month="January" year="2021"/>
<abstract>
<t>This document describes "Trickle ICE", an extension to the Inte
ractive Connectivity Establishment (ICE) protocol that enables ICE agents to beg
in connectivity checks while they are still gathering candidates, by incremental
ly exchanging candidates over time instead of all at once. This method can consi
derably accelerate the process of establishing a communication session.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8838"/>
<seriesInfo name="DOI" value="10.17487/RFC8838"/>
</reference>
<reference anchor="RFC8260">
<front>
<title>Stream Schedulers and User Message Interleaving for the Strea
m Control Transmission Protocol</title>
<author fullname="R. Stewart" initials="R." surname="Stewart"/>
<author fullname="M. Tuexen" initials="M." surname="Tuexen"/>
<author fullname="S. Loreto" initials="S." surname="Loreto"/>
<author fullname="R. Seggelmann" initials="R." surname="Seggelmann"/
>
<date month="November" year="2017"/>
<abstract>
<t>The Stream Control Transmission Protocol (SCTP) is a message-or
iented transport protocol supporting arbitrarily large user messages. This docum
ent adds a new chunk to SCTP for carrying payload data. This allows a sender to
interleave different user messages that would otherwise result in head-of-line b
locking at the sender. The interleaving of user messages is required for WebRTC
data channels.</t>
<t>Whenever an SCTP sender is allowed to send user data, it may ch
oose from multiple outgoing SCTP streams. Multiple ways for performing this sele
ction, called stream schedulers, are defined in this document. A stream schedule
r can choose to either implement, or not implement, user message interleaving.</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="8260"/>
<seriesInfo name="DOI" value="10.17487/RFC8260"/>
</reference>
<reference anchor="RFC7657">
<front>
<title>Differentiated Services (Diffserv) and Real-Time Communicatio
n</title>
<author fullname="D. Black" initials="D." role="editor" surname="Bla
ck"/>
<author fullname="P. Jones" initials="P." surname="Jones"/>
<date month="November" year="2015"/>
<abstract>
<t>This memo describes the interaction between Differentiated Serv
ices (Diffserv) network quality-of-service (QoS) functionality and real- time ne
twork communication, including communication based on the Real-time Transport Pr
otocol (RTP). Diffserv is based on network nodes applying different forwarding t
reatments to packets whose IP headers are marked with different Diffserv Codepoi
nts (DSCPs). WebRTC applications, as well as some conferencing applications, hav
e begun using the Session Description Protocol (SDP) bundle negotiation mechanis
m to send multiple traffic streams with different QoS requirements using the sam
e network 5-tuple. The results of using multiple DSCPs to obtain different QoS t
reatments within a single network 5-tuple have transport protocol interactions,
particularly with congestion control functionality (e.g., reordering). In additi
on, DSCP markings may be changed or removed between the traffic source and desti
nation. This memo covers the implications of these Diffserv aspects for real-tim
e network communication, including WebRTC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7657"/>
<seriesInfo name="DOI" value="10.17487/RFC7657"/>
</reference>
<reference anchor="RFC2474">
<front>
<title>Definition of the Differentiated Services Field (DS Field) in
the IPv4 and IPv6 Headers</title>
<author fullname="K. Nichols" initials="K." surname="Nichols"/>
<author fullname="S. Blake" initials="S." surname="Blake"/>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<author fullname="D. Black" initials="D." surname="Black"/>
<date month="December" year="1998"/>
<abstract>
<t>This document defines the IP header field, called the DS (for d
ifferentiated services) field. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2474"/>
<seriesInfo name="DOI" value="10.17487/RFC2474"/>
</reference>
<reference anchor="RFC8622">
<front>
<title>A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated S
ervices</title>
<author fullname="R. Bless" initials="R." surname="Bless"/>
<date month="June" year="2019"/>
<abstract>
<t>This document specifies properties and characteristics of a Low
er- Effort Per-Hop Behavior (LE PHB). The primary objective of this LE PHB is to
protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from
LE traffic in congestion situations, i.e., when resources become scarce, BE traf
fic has precedence over LE traffic and may preempt it. Alternatively, packets fo
rwarded by the LE PHB can be associated with a scavenger service class, i.e., th
ey scavenge otherwise-unused resources only. There are numerous uses for this PH
B, e.g., for background traffic of low precedence, such as bulk data transfers w
ith low priority in time, non-time-critical backups, larger software updates, we
b search engines while gathering information from web servers and so on. This do
cument recommends a standard Differentiated Services Code Point (DSCP) value for
the LE PHB.</t>
<t>This specification obsoletes RFC 3662 and updates the DSCP reco
mmended in RFCs 4594 and 8325 to use the DSCP assigned in this specification.</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="8622"/>
<seriesInfo name="DOI" value="10.17487/RFC8622"/>
</reference>
<reference anchor="RFC2597">
<front>
<title>Assured Forwarding PHB Group</title>
<author fullname="J. Heinanen" initials="J." surname="Heinanen"/>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<author fullname="W. Weiss" initials="W." surname="Weiss"/>
<author fullname="J. Wroclawski" initials="J." surname="Wroclawski"/
>
<date month="June" year="1999"/>
<abstract>
<t>This document defines a general use Differentiated Services (DS
) Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2597"/>
<seriesInfo name="DOI" value="10.17487/RFC2597"/>
</reference>
<reference anchor="RFC3246">
<front>
<title>An Expedited Forwarding PHB (Per-Hop Behavior)</title>
<author fullname="B. Davie" initials="B." surname="Davie"/>
<author fullname="A. Charny" initials="A." surname="Charny"/>
<author fullname="J.C.R. Bennet" initials="J.C.R." surname="Bennet"/
>
<author fullname="K. Benson" initials="K." surname="Benson"/>
<author fullname="J.Y. Le Boudec" initials="J.Y." surname="Le Boudec
"/>
<author fullname="W. Courtney" initials="W." surname="Courtney"/>
<author fullname="S. Davari" initials="S." surname="Davari"/>
<author fullname="V. Firoiu" initials="V." surname="Firoiu"/>
<author fullname="D. Stiliadis" initials="D." surname="Stiliadis"/>
<date month="March" year="2002"/>
<abstract>
<t>This document defines a PHB (per-hop behavior) called Expedited
Forwarding (EF). The PHB is a basic building block in the Differentiated Servic
es architecture. EF is intended to provide a building block for low delay, low j
itter and low loss services by ensuring that the EF aggregate is served at a cer
tain configured rate. This document obsoletes RFC 2598. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3246"/>
<seriesInfo name="DOI" value="10.17487/RFC3246"/>
</reference>
<reference anchor="RFC5865">
<front>
<title>A Differentiated Services Code Point (DSCP) for Capacity-Admi
tted Traffic</title>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<author fullname="J. Polk" initials="J." surname="Polk"/>
<author fullname="M. Dolly" initials="M." surname="Dolly"/>
<date month="May" year="2010"/>
<abstract>
<t>This document requests one Differentiated Services Code Point (
DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-ti
me traffic. This traffic class conforms to the Expedited Forwarding Per-Hop Beha
vior. This traffic is also admitted by the network using a Call Admission Contro
l (CAC) procedure involving authentication, authorization, and capacity admissio
n. This differs from a real-time traffic class that conforms to the Expedited Fo
rwarding Per-Hop Behavior but is not subject to capacity admission or subject to
very coarse capacity admission. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5865"/>
<seriesInfo name="DOI" value="10.17487/RFC5865"/>
</reference>
<reference anchor="RFC4594">
<front>
<title>Configuration Guidelines for DiffServ Service Classes</title>
<author fullname="J. Babiarz" initials="J." surname="Babiarz"/>
<author fullname="K. Chan" initials="K." surname="Chan"/>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<date month="August" year="2006"/>
<abstract>
<t>This document describes service classes configured with Diffser
v and recommends how they can be used and how to construct them using Differenti
ated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs
), and Active Queue Management (AQM) mechanisms. There is no intrinsic requireme
nt that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a cert
ain service class, but as a policy and for interoperability it is useful to appl
y them consistently. This memo provides information for the Internet community.<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="4594"/>
<seriesInfo name="DOI" value="10.17487/RFC4594"/>
</reference>
<reference anchor="RFC8899">
<front>
<title>Packetization Layer Path MTU Discovery for Datagram Transport
s</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
<author fullname="T. Jones" initials="T." surname="Jones"/>
<author fullname="M. Tüxen" initials="M." surname="Tüxen"/>
<author fullname="I. Rüngeler" initials="I." surname="Rüngeler"/>
<author fullname="T. Völker" initials="T." surname="Völker"/>
<date month="September" year="2020"/>
<abstract>
<t>This document specifies Datagram Packetization Layer Path MTU D
iscovery (DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for
datagram Packetization Layers (PLs). It allows a PL, or a datagram application t
hat uses a PL, to discover whether a network path can support the current size o
f datagram. This can be used to detect and reduce the message size when a sender
encounters a packet black hole. It can also probe a network path to discover wh
ether the maximum packet size can be increased. This provides functionality for
datagram transports that is equivalent to the PLPMTUD specification for TCP, spe
cified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines t
o refer to this method for use with UDP datagrams and updates SCTP.</t>
<t>The document provides implementation notes for incorporating Da
tagram PMTUD into IETF datagram transports or applications that use datagram tra
nsports.</t>
<t>This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 80
85, and RFC 8261.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8899"/>
<seriesInfo name="DOI" value="10.17487/RFC8899"/>
</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="RFC9329">
<front>
<title>TCP Encapsulation of Internet Key Exchange Protocol (IKE) and
IPsec Packets</title>
<author fullname="T. Pauly" initials="T." surname="Pauly"/>
<author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
<date month="November" year="2022"/>
<abstract>
<t>This document describes a method to transport Internet Key Exch
ange Protocol (IKE) and IPsec packets over a TCP connection for traversing netwo
rk middleboxes that may block IKE negotiation over UDP. This method, referred to
as "TCP encapsulation", involves sending both IKE packets for Security Associat
ion (SA) establishment and Encapsulating Security Payload (ESP) packets over a T
CP connection. This method is intended to be used as a fallback option when IKE
cannot be negotiated over UDP.</t>
<t>TCP encapsulation for IKE and IPsec was defined in RFC 8229. Th
is document clarifies the specification for TCP encapsulation by including addit
ional clarifications obtained during implementation and deployment of this metho
d. This documents obsoletes RFC 8229.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9329"/>
<seriesInfo name="DOI" value="10.17487/RFC9329"/>
</reference>
<reference anchor="RFC9218">
<front>
<title>Extensible Prioritization Scheme for HTTP</title>
<author fullname="K. Oku" initials="K." surname="Oku"/>
<author fullname="L. Pardue" initials="L." surname="Pardue"/>
<date month="June" year="2022"/>
<abstract>
<t>This document describes a scheme that allows an HTTP client to
communicate its preferences for how the upstream server prioritizes responses to
its requests, and also allows a server to hint to a downstream intermediary how
its responses should be prioritized when they are forwarded. This document defi
nes the Priority header field for communicating the initial priority in an HTTP
version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizi
ng responses. These share a common format structure that is designed to provide
future extensibility.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9218"/>
<seriesInfo name="DOI" value="10.17487/RFC9218"/>
</reference>
<reference anchor="RFC8293">
<front>
<title>A Framework for Multicast in Network Virtualization over Laye
r 3</title>
<author fullname="A. Ghanwani" initials="A." surname="Ghanwani"/>
<author fullname="L. Dunbar" initials="L." surname="Dunbar"/>
<author fullname="M. McBride" initials="M." surname="McBride"/>
<author fullname="V. Bannai" initials="V." surname="Bannai"/>
<author fullname="R. Krishnan" initials="R." surname="Krishnan"/>
<date month="January" year="2018"/>
<abstract>
<t>This document provides a framework for supporting multicast tra
ffic in a network that uses Network Virtualization over Layer 3 (NVO3). Both inf
rastructure multicast and application-specific multicast are discussed. It descr
ibes the various mechanisms that can be used for delivering such traffic as well
as the data plane and control plane considerations for each of the mechanisms.<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="8293"/>
<seriesInfo name="DOI" value="10.17487/RFC8293"/>
</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>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC8546">
<front>
<title>The Wire Image of a Network Protocol</title>
<author fullname="B. Trammell" initials="B." surname="Trammell"/>
<author fullname="M. Kuehlewind" initials="M." surname="Kuehlewind"/
>
<date month="April" year="2019"/>
<abstract>
<t>This document defines the wire image, an abstraction of the inf
ormation available to an on-path non-participant in a networking protocol. This
abstraction is intended to shed light on the implications that increased encrypt
ion has for network functions that use the wire image.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8546"/>
<seriesInfo name="DOI" value="10.17487/RFC8546"/>
</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>
<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.79
1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.42
91.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.29
14.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
84.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.88
01.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89
81.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
85.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
80.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.84
89.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
56.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.32
61.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.74
78.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
99.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.88
38.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
60.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.76
57.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.24
74.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
22.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.25
97.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.32
46.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58
65.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.45
94.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.88
99.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.93
29.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
18.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
93.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
46.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.85
46.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
03.xml"/>
</references> </references>
</references> </references>
<?line 3730?>
<section anchor="implmapping"> <section anchor="implmapping">
<name>Implementation Mapping</name> <name>Implementation Mapping</name>
<t>The way the concepts from this abstract API map into concrete APIs in a
<!--[rfced] This sentence packs in a lot of info. Perhaps breaking it
up and a bit of a reorder would be best for the ease of the
reader?
Original:
Actions could be implemented as functions or method calls, for
instance, and events could be implemented via event queues, handler
functions or classes, communicating sequential processes, or other
asynchronous calling conventions.
Perhaps:
For instance, actions could be implemented as functions or method
calls. Event queues, handler functions or classes, communicating
sequential processes, or other asynchronous calling conventions could
implement events.
-->
<t>The way the concepts from this abstract API map to concrete APIs in a
given language on a given platform largely depends on the features and norms of given language on a given platform largely depends on the features and norms of
the language and the platform. Actions could be implemented as functions or the language and the platform. For instance, actions could be implemented as fu
method calls, for instance, and events could be implemented via event queues, nctions or
method calls and events could be implemented via event queues,
handler functions or classes, communicating sequential processes, or other handler functions or classes, communicating sequential processes, or other
asynchronous calling conventions.</t> asynchronous calling conventions.</t>
<section anchor="types"> <section anchor="types">
<name>Types</name> <name>Types</name>
<t>The basic types mentioned in <xref target="notation"/> typically have natural <t>The basic types mentioned in <xref target="notation"/> typically have natural
correspondences in practical programming languages, perhaps constrained by correspondences in practical programming languages, perhaps constrained by
implementation-specific limitations. For example:</t> implementation-specific limitations. For example:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>An Integer can typically be represented in C by an <tt>int</tt> o r <tt>long</tt>, subject <t>Typically, an Integer can be represented in C by an <tt>int</tt> or <tt>long</tt>; this is subject
to the underlying platform's ranges for each.</t> to the underlying platform's ranges for each.</t>
</li> </li>
<li> <li>
<t>In C, a Tuple may be represented as a <tt>struct</tt> with one me mber for each of <t>In C, a Tuple may be represented as a <tt>struct</tt> with one me mber for each of
the value types in the ordered grouping. In Python, by contrast, a Tuple may the value types in the ordered grouping. However, in Python, a Tuple may
be represented as a <tt>tuple</tt>, a sequence of dynamically-typed be represented as a <tt>tuple</tt>, which is a sequence of dynamically typed
elements.</t> elements.</t>
</li> </li>
<li> <li>
<t>A Set may be represented as a <tt>std::set</tt> in C++ or as a <t t>set</tt> in <t>A Set may be represented as a <tt>std::set</tt> in C++ or as a <t t>set</tt> in
Python. In C, it may be represented as an array or as a higher-level data Python. In C, it may be represented as an array or as a higher-level data
structure with appropriate accessors defined.</t> structure with appropriate accessors defined.</t>
</li> </li>
</ul> </ul>
<t>The objects described in <xref target="notation"/> can similarly be r
epresented in <!--[rfced] In this text, may we update as follows to avoid
different ways depending on which programming language is used. Objects "similarly...in different"?
like Preconnections, Connections, and Listeners can be long-lived, and
benefit from using object-oriented constructs. Note that in C, these Original:
The objects described in Section 1.1 can similarly be represented in
different ways...
Current:
The objects described in Section 1.1 can also be represented in
different ways...
-->
<t>The objects described in <xref target="notation"/> can also be repres
ented in
different ways, depending on which programming language is used. Objects
like Preconnections, Connections, and Listeners can be long-lived and
benefit from using object-oriented constructs. Note that, in C, these
objects may need to provide a way to release or free their underlying objects may need to provide a way to release or free their underlying
memory when the application is done using them. For example, since a memory when the application is done using them. For example, since a
Preconnection can be used to initiate multiple Connections, it is the Preconnection can be used to initiate multiple Connections, it is the
responsibility of the application to clean up the Preconnection memory responsibility of the application to clean up the Preconnection memory
if necessary.</t> if necessary.</t>
</section> </section>
<section anchor="events-and-errors"> <section anchor="events-and-errors">
<name>Events and Errors</name> <name>Events and Errors</name>
<!--[rfced] Please review our updates to this run-on sentence and
confirm we have not shifted the meaning (or please suggest
another rephrase if we have).
Original:
However, implementations of this API may report errors synchronously,
according to the error handling idioms of the implementation platform,
where they can be immediately detected, such as by generating an
exception when attempting to initiate a Connection with inconsistent
Transport Properties.
Current:
However, implementations of this API may report errors synchronously.
This is done according to the error-handling idioms of the
implementation platform, where they can be immediately detected. An
example of this being generating an exception when attempting to
initiate a Connection with inconsistent Transport Properties.
-->
<t>This specification treats events and errors similarly. Errors, just a s any <t>This specification treats events and errors similarly. Errors, just a s any
other events, may occur asynchronously in network applications. However, other events, may occur asynchronously in network applications. However,
implementations of this API may report errors synchronously, implementations of this API may report errors synchronously.
according to the error handling idioms of the implementation This is done according to the error-handling idioms of the implementation
platform, where they can be immediately detected, such as by generating an platform, where they can be immediately detected. An example of this being gener
ating an
exception when attempting to initiate a Connection with inconsistent exception when attempting to initiate a Connection with inconsistent
Transport Properties. An error can provide an optional reason to the Transport Properties. An error can provide an optional reason to the
application with further details about why the error occurred.</t> application with further details about why the error occurred.</t>
</section> </section>
<section anchor="time-duration"> <section anchor="time-duration">
<name>Time Duration</name> <name>Time Duration</name>
<t>Time duration types are implementation-specific. <t>Time duration types are implementation specific.
For instance, it could be a number of seconds, number of milliseconds, or a <tt> For instance, it could be a number of seconds, a number of milliseconds, or a <t
struct timeval</tt> in C or a user-defined <tt>Duration</tt> class in C++.</t> t>struct timeval</tt> in C; in C++, it could be a user-defined <tt>Duration</tt
> class.</t>
</section> </section>
</section> </section>
<section anchor="convenience-functions"> <section anchor="convenience-functions">
<name>Convenience Functions</name> <name>Convenience Functions</name>
<section anchor="preference-conv"> <section anchor="preference-conv">
<name>Adding Preference Properties</name> <name>Adding Preference Properties</name>
<t>TransportProperties will frequently need to set <t>TransportProperties will frequently need to set
Selection Properties of type <tt>Preference</tt>, therefore implementations can Selection Properties of type <tt>Preference</tt>; therefore, implementations can
provide special actions provide special actions
for adding each preference level i.e, <tt>TransportProperties.Set(some_property, for adding each preference level, i.e., <tt>TransportProperties.Set(some_propert
avoid) y, avoid)</tt>
is equivalent to </tt>TransportProperties.Avoid(some_property)`:</t> is equivalent to <tt>TransportProperties.Avoid(some_property)</tt>:
<!-- [rfced] Appendix B.1: We found a spacing issue and an
extraneous "`" character in this sentence. We corrected these items,
but we would also like to confirm that the ", avoid)" portion is
correct. We ask because we do not see "avoid)" used anywhere else
in this document. Please also note that we made adjustments to the
<tt> settings.
Please review, and let us know if further updates are needed.
Original:
TransportProperties will frequently need to set Selection Properties
of type Preference, therefore implementations can provide special
actions for adding each preference level i.e,
TransportProperties.Set(some_property, avoid) is equivalent
toTransportProperties.Avoid(some_property)`:
Currently:
TransportProperties will frequently need to set Selection Properties
of type Preference; therefore, implementations can provide special
actions for adding each preference level, i.e.,
TransportProperties.Set(some_property, avoid) is equivalent to
TransportProperties.Avoid(some_property): -->
</t>
<artwork><![CDATA[ <artwork><![CDATA[
TransportProperties.Require(property) TransportProperties.Require(property)
TransportProperties.Prefer(property) TransportProperties.Prefer(property)
TransportProperties.NoPreference(property) TransportProperties.NoPreference(property)
TransportProperties.Avoid(property) TransportProperties.Avoid(property)
TransportProperties.Prohibit(property) TransportProperties.Prohibit(property)
]]></artwork> ]]></artwork>
</section> </section>
<section anchor="property-profiles"> <section anchor="property-profiles">
<name>Transport Property Profiles</name> <name>Transport Property Profiles</name>
<t>To ease the use of the Transport Services API, implementations <t>To ease the use of the Transport Services API, implementations
can provide a mechanism to create Transport Property objects (see <xref target=" selection-props"/>) can provide a mechanism to create Transport Property objects (see <xref target=" selection-props"/>)
that are preconfigured with frequently used sets of properties; the following ar that are preconfigured with frequently used sets of properties; the following su
e bsections list those that are
in common use in current applications:</t> in common use in applications at the time of writing.</t>
<!--[rfced] Please review/confirm the use of "require" instead of
"required" or "Require" in the Value column of B.2.1, B.2.2, and
B.2.3.-->
<section anchor="reliable-inorder-stream"> <section anchor="reliable-inorder-stream">
<name>reliable-inorder-stream</name> <name>reliable-inorder-stream</name>
<t>This profile provides reliable, in-order transport service with <t>This profile provides reliable, in-order transport service with
congestion control. congestion control.
TCP is an example of a protocol that provides this service. TCP is an example of a protocol that provides this service.
It should consist of the following properties:</t> It should consist of the following properties:</t>
<table anchor="tabrio"> <table anchor="tabrio">
<name>reliable-inorder-stream preferences</name> <name>reliable-inorder-stream Preferences</name>
<thead> <thead>
<tr> <tr>
<th align="left">Property</th> <th align="left">Property</th>
<th align="left">Value</th> <th align="left">Value</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">reliability</td> <td align="left">reliability</td>
<td align="left">require</td> <td align="left">require</td>
skipping to change at line 4605 skipping to change at line 4647
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="reliable-message"> <section anchor="reliable-message">
<name>reliable-message</name> <name>reliable-message</name>
<t>This profile provides message-preserving, reliable, in-order <t>This profile provides message-preserving, reliable, in-order
transport service with congestion control. transport service with congestion control.
SCTP is an example of a protocol that provides this service. SCTP is an example of a protocol that provides this service.
It should consist of the following properties:</t> It should consist of the following properties:</t>
<table anchor="tabrm"> <table anchor="tabrm">
<name>reliable-message preferences</name> <name>reliable-message Preferences</name>
<thead> <thead>
<tr> <tr>
<th align="left">Property</th> <th align="left">Property</th>
<th align="left">Value</th> <th align="left">Value</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">reliability</td> <td align="left">reliability</td>
<td align="left">require</td> <td align="left">require</td>
skipping to change at line 4639 skipping to change at line 4681
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="unreliable-datagram"> <section anchor="unreliable-datagram">
<name>unreliable-datagram</name> <name>unreliable-datagram</name>
<t>This profile provides a datagram transport service without any <t>This profile provides a datagram transport service without any
reliability guarantee. reliability guarantee.
An example of a protocol that provides this service is UDP. An example of a protocol that provides this service is UDP.
It consists of the following properties:</t> It consists of the following properties:</t>
<table anchor="tabud"> <table anchor="tabud">
<name>unreliable-datagram preferences</name> <name>unreliable-datagram Preferences</name>
<thead> <thead>
<tr> <tr>
<th align="left">Property</th> <th align="left">Property</th>
<th align="left">Value</th> <th align="left">Value</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">reliability</td> <td align="left">reliability</td>
<td align="left">avoid</td> <td align="left">avoid</td>
skipping to change at line 4673 skipping to change at line 4715
<tr> <tr>
<td align="left">safelyReplayable</td> <td align="left">safelyReplayable</td>
<td align="left">true</td> <td align="left">true</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Applications that choose this Transport Property Profile would <t>Applications that choose this Transport Property Profile would
avoid the additional latency that could be introduced avoid the additional latency that could be introduced
by retransmission or reordering in a transport protocol.</t> by retransmission or reordering in a transport protocol.</t>
<t>Applications that choose this Transport Property Profile to reduce latency <t>Applications that choose this Transport Property Profile to reduce latency
should also consider setting an appropriate capacity profile Property, should also consider setting an appropriate capacity profile Property
see <xref target="prop-cap-profile"/> and might benefit from controlling checksu (see <xref target="prop-cap-profile"/>) and might benefit from controlling check
m sum
coverage, see <xref target="prop-checksum-control-send"/> and <xref target="prop coverage (see Sections&nbsp;<xref target="prop-checksum-control-send" format="co
-checksum-control-receive"/>.</t> unter"/> and <xref target="prop-checksum-control-receive" format="counter"/>).</
t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="relationship-to-the-minimal-set-of-transport-services-for-e nd-systems"> <section anchor="relationship-to-the-minimal-set-of-transport-services-for-e nd-systems">
<name>Relationship to the Minimal Set of Transport Services for End System s</name> <name>Relationship to the Minimal Set of Transport Services for End System s</name>
<t><xref target="RFC8923"/> identifies a minimal set of transport services <t><xref target="RFC8923"/> identifies a minimal set of Transport Services
that end systems should offer. These services make all non-security-related tra that end systems should offer. These services make all non-security-related tra
nsport features of TCP, MPTCP, UDP, UDP-Lite, SCTP and LEDBAT available that 1) nsport features of TCP, Multipath TCP (MPTCP), UDP, UDP-Lite, SCTP, and Low Extr
require interaction with the application, and 2) do not get in the way of a poss a Delay Background Transport (LEDBAT) available that:</t>
ible implementation over TCP (or, with limitations, UDP). The following text exp <ol>
lains how this minimal set is reflected in the present API. For brevity, it is b <li>require interaction with the application and</li>
ased on the list in <xref section="4.1" sectionFormat="of" target="RFC8923"/>, <li>do not get in the way of a possible implementation over TCP (or, with
updated according to the discussion in <xref section="5" sectionFormat="of" targ limitations, UDP).</li>
et="RFC8923"/>. The present API covers all elements of this section. </ol>
This list is a subset of the transport features in Appendix A of <xref target="R <t>The following text explains how this minimal set is reflected in the pr
FC8923"/>, which refers to the primitives in "pass 2" (Section 4) of <xref targe esent API. For brevity, it is based on the list in <xref section="4.1" sectionF
t="RFC8303"/> for further details on the implementation with TCP, MPTCP, UDP, UD ormat="of" target="RFC8923"/> and updated according to the discussion in <xref s
P-Lite, SCTP and LEDBAT. This facilitates finding the specifications for impleme ection="5" sectionFormat="of" target="RFC8923"/>. The present API covers all ele
nting ments of this section.
the services listed below with these protocols.</t> This list is a subset of the transport features in
<ul spacing="normal"> <xref target="RFC8923" sectionFormat="of" section="A"/>, which refers to the pri
<li> mitives in "pass 2" (see <xref target="RFC8303" section="4" sectionFormat="of"/>
<t>Connect: ) for further details on the implementation with TCP, MPTCP, UDP, UDP-Lite, SCTP
<tt>Initiate</tt> action (<xref target="initiate"/>).</t> , and LEDBAT. This facilitates finding the specifications for implementing
</li> the services listed below with these protocols.
<li>
<t>Listen: <!-- [rfced] Appendix C: The first sentence here does not parse;
<tt>Listen</tt> action (<xref target="listen"/>).</t> it appears that one or more words are missing. In the second
</li> sentence, it is not clear what "This" refers to.
<li> If the suggested text is not correct, please provide clarifying text.
<t>Specify number of attempts and/or timeout for the first establishme
nt Message: Original:
<tt>timeout</tt> parameter of <tt>Initiate</tt> (<xref target="initiate"/>) or < This list is a subset of the transport features in
tt>InitiateWithSend</tt> action (<xref target="initiate-and-send"/>).</t> Appendix A of [RFC8923], which refers to the primitives in "pass 2"
</li> (Section 4) of [RFC8303] for further details on the implementation
<li> with TCP, MPTCP, UDP, UDP-Lite, SCTP and LEDBAT. This facilitates
<t>Disable MPTCP: finding the specifications for implementing the services listed below
<tt>multipath</tt> property (<xref target="multipath-mode"/>).</t> with these protocols.
</li>
<li> Suggested (guessing that "This" refers to Section 4 of [RFC8303]):
<t>Hand over a Message to reliably transfer (possibly multiple times) This list is a subset of the transport features in
before connection establishment: Appendix A of [RFC8923], which refers to the primitives in "pass 2".
<tt>InitiateWithSend</tt> action (<xref target="initiate-and-send"/>).</t> See Section 4 of [RFC8303] for 1) further details regarding how to
</li> implement pass 2 with TCP, MPTCP, UDP, UDP-Lite, SCTP, and LEDBAT
<li> and 2) how to facilitate finding the specifications for implementing
<t>Change timeout for aborting connection (using retransmit limit or t the services listed below with these protocols. -->
ime value):
<tt>connTimeout</tt> property, using a time value (<xref target="conn-timeout"/> </t>
).</t> <ul>
</li>
<li> <li>Connect:
<t>Timeout event when data could not be delivered for too long: <tt>Initiate</tt> action (<xref target="initiate"/>).</li>
<tt>ConnectionError</tt> event (<xref target="termination"/>).</t>
</li> <li>Listen:
<li> <tt>Listen</tt> action (<xref target="listen"/>).</li>
<t>Suggest timeout to the peer:
See "TCP-specific Properties: User Timeout Option (UTO)" (<xref target="tcp-uto" <li>Specify number of attempts and/or timeout for the first establishm
/>).</t> ent Message:
</li> <tt>timeout</tt> parameter of <tt>Initiate</tt> (<xref target="initiate"/>) or <
<li> tt>InitiateWithSend</tt> action (<xref target="initiate-and-send"/>).</li>
<t>Notification of ICMP error message arrival:
<tt>softErrorNotify</tt> (<xref target="prop-soft-error"/>) and <tt>SoftError</t <li>Disable MPTCP:
t> event (<xref target="soft-errors"/>).</t> <tt>multipath</tt> property (<xref target="multipath-mode"/>).</li>
</li>
<li> <li>Hand over a Message to reliably transfer (possibly multiple times)
<t>Choose a scheduler to operate between streams of an association: before connection establishment:
<tt>connScheduler</tt> property (<xref target="conn-scheduler"/>).</t> <tt>InitiateWithSend</tt> action (<xref target="initiate-and-send"/>).</li>
</li>
<li> <li>Change timeout for aborting connection (using retransmit limit or
<t>Configure priority or weight for a scheduler: time value):
<tt>connPriority</tt> property (<xref target="conn-priority"/>).</t> <tt>connTimeout</tt> property, using a time value (<xref target="conn-timeout"/>
</li> ).</li>
<li>
<t>"Specify checksum coverage used by the sender" and "Disable checksu <li>Timeout event when data could not be delivered for too long:
m when sending": <tt>ConnectionError</tt> event (<xref target="termination"/>).</li>
<tt>msgChecksumLen</tt> property (<xref target="msg-checksum"/>) and <tt>fullChe
cksumSend</tt> property (<xref target="prop-checksum-control-send"/>).</t> <li>Suggest timeout to the peer:
</li> See "<xref target="tcp-uto" format="title"/>" (<xref target="tcp-uto" format="de
<li> fault"/>).</li>
<t>"Specify minimum checksum coverage required by receiver" and "Disab
le checksum requirement when receiving": <li>Notification of ICMP error message arrival:
<tt>recvChecksumLen</tt> property (<xref target="conn-recv-checksum"/>) and <tt> <tt>softErrorNotify</tt> (<xref target="prop-soft-error"/>) and <tt>SoftError</t
fullChecksumRecv</tt> property (<xref target="prop-checksum-control-receive"/>). t> event (<xref target="soft-errors"/>).</li>
</t>
</li> <li>Choose a scheduler to operate between streams of an association:
<li> <tt>connScheduler</tt> property (<xref target="conn-scheduler"/>).</li>
<t>"Specify DF field":
<tt>noFragmentation</tt> property (<xref target="send-singular"/>).</t> <li>Configure priority or weight for a scheduler:
</li> <tt>connPriority</tt> property (<xref target="conn-priority"/>).</li>
<li>
<t>Get max. transport-message size that may be sent using a non-fragme <li>"Specify checksum coverage used by the sender" and "Disable checks
nted IP packet from the configured interface: um when sending":
<tt>singularTransmissionMsgMaxLen</tt> property (<xref target="conn-max-msg-notf <tt>msgChecksumLen</tt> property (<xref target="msg-checksum"/>) and <tt>fullChe
rag"/>).</t> cksumSend</tt> property (<xref target="prop-checksum-control-send"/>).</li>
</li>
<li> <li>"Specify minimum checksum coverage required by receiver" and "Disa
<t>Get max. transport-message size that may be received from the confi ble checksum requirement when receiving":
gured interface: <tt>recvChecksumLen</tt> property (<xref target="conn-recv-checksum"/>) and <tt>
<tt>recvMsgMaxLen</tt> property (<xref target="conn-max-msg-recv"/>).</t> fullChecksumRecv</tt> property (<xref target="prop-checksum-control-receive"/>).
</li> </li>
<li>
<t>Obtain ECN field: <li>"Specify DF field":
This is a read-only Message Property of the MessageContext object (see "UDP(-Lit <tt>noFragmentation</tt> property (<xref target="send-singular"/>).</li>
e)-specific Property: ECN" <xref target="receive-ecn"/>).</t>
</li> <!-- [rfced] Appendix C: It appears that some actions in this list
<li> are quoted because more than one action is listed. However, as
<t>"Specify DSCP field", "Disable Nagle algorithm", "Enable and config "Specify DF field" is the only single action item in the list that is
ure a <tt>Low Extra Delay Background Transfer</tt>": quoted (as compared to, for example, the unquoted Disable MPTCP and
as suggested in <xref section="5.5" sectionFormat="of" target="RFC8923"/>, these Obtain ECN field items), may we remove the quotes here?
transport features are collectively offered via the <tt>connCapacityProfile</tt
> property (<xref target="prop-cap-profile"/>). Per-Message control ("Request no Also, could "Request not to bundle messages" be changed to
t to bundle messages") is offered via the <tt>msgCapacityProfile</tt> property ( a request not to bundle messages
<xref target="send-profile"/>).</t> (no quotes)?
</li>
<li> Original:
<t>Close after reliably delivering all remaining data, causing an even * "Specify DF field": noFragmentation property (Section 9.1.3.9).
t informing the application on the other side: ...
this is offered by the <tt>Close</tt> action with slightly changed semantics in Per-Message control ("Request not to bundle
line with the discussion in <xref section="5.2" sectionFormat="of" target="RFC89 messages") is offered via the msgCapacityProfile property
23"/> (<xref target="termination"/>).</t> (Section 9.1.3.8). -->
</li>
<li> <li>Get maximum transport-message size that may be sent using a non-fr
<t>"Abort without delivering remaining data, causing an event informin agmented IP packet from the configured interface:
g the application on the other side" and "Abort without delivering remaining dat <tt>singularTransmissionMsgMaxLen</tt> property (<xref target="conn-max-msg-notf
a, not causing an event informing the application on the other side": rag"/>).</li>
this is offered by the <tt>Abort</tt> action without promising that this is sign
aled to the other side. If it is, a <tt>ConnectionError</tt> event will be invok <li>Get maximum transport-message size that may be received from the c
ed at the peer (<xref target="termination"/>).</t> onfigured interface:
</li> <tt>recvMsgMaxLen</tt> property (<xref target="conn-max-msg-recv"/>).</li>
<li>
<t>"Reliably transfer data, with congestion control", "Reliably transf <li>Obtain ECN field:
er a message, with congestion control" and "Unreliably transfer a message": This is a read-only Message Property of the MessageContext object (see
data is transferred via the <tt>Send</tt> action (<xref target="sending"/>). Rel "<xref target="receive-ecn" format="title"/>" (<xref target="receive-ecn" format
iability is controlled via the <tt>reliability</tt> (<xref target="prop-reliable ="default"/>)).</li>
"/>) property and the <tt>msgReliable</tt> Message Property (<xref target="msg-r
eliable-message"/>). Transmitting data as a Message or without delimiters is con <li>"Specify DSCP field", "Disable Nagle algorithm", and "Enable and c
trolled via Message Framers (<xref target="framing"/>). The choice of congestion onfigure a <tt>Low Extra Delay Background Transfer</tt>":
control is provided via the <tt>congestionControl</tt> property (<xref target=" as suggested in <xref section="5.5" sectionFormat="of" target="RFC8923"/>, these
prop-cc"/>).</t> transport features are collectively offered via the <tt>connCapacityProfile</tt
</li> > property (<xref target="prop-cap-profile"/>). Per-Message control ("Request no
<li> t to bundle messages") is offered via the <tt>msgCapacityProfile</tt> property (
<t>Configurable Message Reliability: <xref target="send-profile"/>).</li>
the <tt>msgLifetime</tt> Message Property implements a time-based way to configu
re message reliability (<xref target="msg-lifetime"/>).</t> <li>Close after reliably delivering all remaining data, causing an eve
</li> nt informing the application on the other side:
<li> this is offered by the <tt>Close</tt> action with slightly changed semantics in
<t>"Ordered message delivery (potentially slower than unordered)" and line with the discussion in <xref section="5.2" sectionFormat="of" target="RFC89
"Unordered message delivery (potentially faster than ordered)": 23"/> (see also <xref target="termination"/>).</li>
these two transport features are controlled via the Message Property <tt>msgOrde
red</tt> (<xref target="msg-ordered"/>).</t> <!--[rfced] It seems this bullet is discussing two options: should
</li> "this" be made "these"?
<li>
<t>Request not to delay the acknowledgment (SACK) of a message: Original:
should the protocol support it, this is one of the transport features the Transp
ort Services system can apply when an application uses the <tt>connCapacityProfi "Abort without delivering remaining data, causing an event
le</tt> Property (<xref target="prop-cap-profile"/>) or the <tt>msgCapacityProfi informing the application on the other side" and "Abort without
le</tt> Message Property (<xref target="send-profile"/>) with value <tt>Low Late delivering remaining data, not causing an event informing the
ncy/Interactive</tt>.</t> application on the other side": this is offered by the Abort action
</li> without promising that this is signaled to the other side.
<li>
<t>Receive data (with no message delimiting): Perhaps:
<tt>Receive</tt> action (<xref target="receiving-action"/>) and <tt>Received</tt
> event (<xref target="receive-complete"/>).</t> "Abort without delivering remaining data, causing an event
</li> informing the application on the other side" and "Abort without
<li> delivering remaining data, not causing an event informing the
<t>Receive a message: application on the other side": these are offered by the Abort action
<tt>Receive</tt> action (<xref target="receiving-action"/>) and <tt>Received</tt without promising that these are signaled to the other side.
> event (<xref target="receive-complete"/>), using Message Framers (<xref target -->
="framing"/>).</t>
</li> <li>"Abort without delivering remaining data, causing an event informi
<li> ng the application on the other side" and "Abort without delivering remaining da
<t>Information about partial message arrival: ta, not causing an event informing the application on the other side":
<tt>Receive</tt> action (<xref target="receiving-action"/>) and <tt>ReceivedPart this is offered by the <tt>Abort</tt> action without promising that this is sign
ial</tt> event (<xref target="receive-partial"/>).</t> aled to the other side. If it is, a <tt>ConnectionError</tt> event will be invok
</li> ed at the peer (<xref target="termination"/>).</li>
<li>
<t>Notification of send failures: <li>"Reliably transfer data, with congestion control", "Reliably trans
<tt>Expired</tt> event (<xref target="expired"/>) and <tt>SendError</tt> event ( fer a message, with congestion control", and "Unreliably transfer a message":
<xref target="send-error"/>).</t> data is transferred via the <tt>Send</tt> action (<xref target="sending"/>). Rel
</li> iability is controlled via the <tt>reliability</tt> (<xref target="prop-reliable
<li> "/>) property and the <tt>msgReliable</tt> Message Property (<xref target="msg-r
<t>Notification that the stack has no more user data to send: eliable-message"/>). Transmitting data as a Message or without delimiters is con
applications can obtain this information via the <tt>Sent</tt> event (<xref targ trolled via Message Framers (<xref target="framing"/>). The choice of congestion
et="sent"/>).</t> control is provided via the <tt>congestionControl</tt> property (<xref target="
</li> prop-cc"/>).</li>
<li>
<t>Notification to a receiver that a partial message delivery has been <li>Configurable Message Reliability:
aborted: the <tt>msgLifetime</tt> Message Property implements a time-based way to configu
<tt>ReceiveError</tt> event (<xref target="receive-error"/>).</t> re message reliability (<xref target="msg-lifetime"/>).</li>
</li>
<li> <li>"Ordered message delivery (potentially slower than unordered)" and
<t>Notification of Excessive Retransmissions (early warning below abor "Unordered message delivery (potentially faster than ordered)":
tion threshold): these two transport features are controlled via the Message Property <tt>msgOrde
<tt>SoftError</tt> event (<xref target="soft-errors"/>).</t> red</tt> (<xref target="msg-ordered"/>).</li>
</li>
<li>Request not to delay the acknowledgement (SACK) of a message:
should the protocol support it, this is one of the transport features the Transp
ort Services system can apply when an application uses the <tt>connCapacityProfi
le</tt> Property (<xref target="prop-cap-profile"/>) or the <tt>msgCapacityProfi
le</tt> Message Property (<xref target="send-profile"/>) with value <tt>Low Late
ncy/Interactive</tt>.</li>
<li>Receive data (with no message delimiting):
<tt>Receive</tt> action (<xref target="receiving-action"/>) and <tt>Received</tt
> event (<xref target="receive-complete"/>).</li>
<li>Receive a message:
<tt>Receive</tt> action (<xref target="receiving-action"/>) and <tt>Received</tt
> event (<xref target="receive-complete"/>) using Message Framers (<xref target=
"framing"/>).</li>
<li>Information about partial message arrival:
<tt>Receive</tt> action (<xref target="receiving-action"/>) and <tt>ReceivedPart
ial</tt> event (<xref target="receive-partial"/>).</li>
<li>Notification of send failures:
<tt>Expired</tt> event (<xref target="expired"/>) and <tt>SendError</tt> event (
<xref target="send-error"/>).</li>
<li>Notification that the stack has no more user data to send:
applications can obtain this information via the <tt>Sent</tt> event (<xref targ
et="sent"/>).</li>
<li>Notification to a receiver that a partial message delivery has bee
n aborted:
<tt>ReceiveError</tt> event (<xref target="receive-error"/>).</li>
<li>Notification of Excessive Retransmissions (early warning below abo
rtion threshold):
<tt>SoftError</tt> event (<xref target="soft-errors"/>).</li>
</ul> </ul>
</section> </section>
<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) and No. 688421 (MA
MI).</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>
<li>the Research Council of Norway under its "Toppforsk"
programme through the "OCARINA" project.</li></ul>
<t>Thanks to <contact fullname="Stuart Cheshire"/>, <contact fullname="Jos
h Graessley"/>, <contact fullname="David Schinazi"/>, and <contact fullname="Eri
c Kinnear"/> for
their implementation and design efforts, including Happy Eyeballs, that heavily
influenced this work. Thanks to <contact fullname="Laurent Chuat"/> and <contact
fullname="Jason Lee"/> for initial work on
the Post Sockets interface, from which this work has evolved. Thanks to
<contact fullname="Maximilian Franke"/> for asking good questions based on imple
mentation experience
and for contributing text, e.g., on multicast.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+y9+3IjR3Y3+H8+RbkVGya/AKC+SWpR45lhs1tSf9MXTpOa <!-- [rfced] Please let us know if any changes are needed for the
WX/yhFgACmS5gSq4qkAKardj32EfYPdZdt9kn2TPNfNkVgFk6zL2F/E5wrYa following:
rMrKy8lzP78zHo9dV3bL4ig7rrLjads1+azLjtfrZTnLu7Kuspf5tmiyF1VX
NIt8VmRdnZ03edWu66bLzormupwVrcun06a4PsrOj0/PwsNuXs+qfAWjz5t8 a) The following terms were used inconsistently in this document. We
0Y3LoluMu3zdjkt9ZPzwczfPu+LIwfeKy7rZHmVtN3euXDdHWdds2u7h/ftf chose to use the latter forms. Please let us know any objections.
3n/oburm3WVTb9bylb/Cv8vqMvsGf3Pvii08MD/ij1dFN36Gn3Su7fJq/kO+
rCuYxhamui6Psu+7ejbKWlhCUyxa+K/tCv/jb87lm+6qbo5clo3hf7OsrNqj keep alive / keep-alive
7OkE17xaFcsl/chretqUeRX/oW4uj7Jv6vpyWWRnN2X3U9Es4fPZN6vpt/RA
U+NeF/Oyqxv6oVjl5fIow535YydDTWZX9Dc4jaLoYEDYhPx6/M1muRyfLvPu Parameters / parameters (where used generally, e.g., "of
p+wB/X1WdrBbT+7ff5z9j01TyluzelN1uI1mAvFyXk2yvxbLn+xaXsHbebE0 parameters") (per the rest of this document and the rest of this
v/dmSmv7riqvi6aFD2f1InvTLutopqdvsqf1j9mD+0/uZ0+XZTWHozBTvf/o cluster of documents)
wedZeMvP9HXd3ORbux8rnM9N8cdyUU42ZT2p6ngJbyfZ8+ryKm/mnVnF26Jo
i/gPNOvXsLvL8sdoqg8ePsiOl9OmvLzqsr/K13maL+s2+ybvaiCMk+Psy8/u protocol selection properties (1 instance) /
P3oYzxd2oSvm2VkHJNviRhyvCtj/vH+ihcxlAhQZr+CbSfZ1XjZXm6a1S/im Protocol Selection Properties (1 instance) (We also found
njcwdPynga0/nhbNvCiqaE3PinXedKui6vAR2IeyKmBi1WX01NdN3sKVfl1P 24 instances of "Selection Properties".)
gUqfbsrlXJ/g5evQo+z46cPH2aPvnid0Nas7ISq/Wri4zfaPRXM5yafzapLP (also per the rest of this cluster)
Jpt39Hegy6PsquvWR59+enNzM4kf+bRHmH/aFFfL4qaU4ZU6m3/N0z/RpjyH
bW/buoppB56evPNP/7GQhyazehXthL49Pl4uiyK6Vd8WzU/1ZVE1eZdcq2+K PVD / PvD
ZpVX23jmJ5PstEB+1Jppn9RwBaLfBw7ym2XeXtY30bzOZld1vcS/ntSr9aZD
Nnc2K4sKWGqYoryZZd88eJg9+fOfB2n0T/DuXJYt+zNr13+E/+VpTWBK8VJO remote Endpoint Identifier / Remote Endpoint Identifier
gdmVcI8sezi9Kpflep2dRX+j1Zwdn2Znz2N+VcBfivFZV6yvigr39wxY2//7
fxXZF+MHj8wKHtz/7LMvsqfAo8pq1yb7aa95Dn/saAL9C3UOR5Bvllsz7fN6 sockets API / Socket API (per the rest of this cluster)
tdqaX2nCKNwKEBOzSTTpN1UhfzrNm3cJRzjZwHbBMdTAEfJluaibqsyRMzx4
/PGcoVvjhP6Y48eIJF1Vw2o7oAqUOy/GzyZBUObN7OoIpGG12P1MuVov8de3 Transport System (1 instance / transport system (4 instances)
X5988dlnn+N/np+cjk/efHf68sXrb47o4yLm7826Zgl/RWY538yQsl7CXKvZ
NuuuQJJeXgHNbWBm8xHcARCleAmKetNmrzbLrhx/vQSKg/fhqeqyaElFgP/s b) The following terms appear to be used inconsistently in this
QFzc4/2E9RYtzpe/i//z4vnz59mL11+/OXnzCsi2nuZLL6ezs+1qXbflZpUd document. Please let us know which form is preferred.
fPPiMEMx317Va/xX9vD+gyeHNEyQy/g/Yz80HT2Q5Yt2ma/8r3z8Z/mi/LfN
Mvpb8mYkCi3DScVh780/TbJvS1AgrpJX/9SUsCugGER/TV5+Bi/nqIzE7z7L boolean value / Boolean value
r8t59JfkPRAax82q7PLLInn1m6aorktgY+kD/a365l+LtlWWb3arK4BbRX8k
xYwOwTk3Ho+zXDRE586vyjYD9W5D0mZetLOmnALJw8L1oSw3auQaCAnVGyQ4 enumerated / Enumerated (and enumeration / Enumeration)
r/yBhDl9MUKVsrsCzVLVSrcknbO7yrusqHIQUy09ANe+mNFocLH80zg0qHP1
Ej8+d0BSSELZGhg3zHALi4M5LJfbDEZr4JqWqwK4GE4fPu7HX+QtTAoWsl7W namespace / Namespace (in running text)
W1yTg29UxU08uv9XtijybtPAi6BkXdUbGLr4t02JsjYD0sGrIctyZhda/DCs
Y13MQLEBPoEzWNRLuFO8wr5mnSEDAJ4yw6+56RZnAESC38nbbTWDO1vB7RzB preference / Preference
6mpYKG/LqoQz5G1awXECMcCXX3QZrBn3HtSyOc6ugcWSSg+zfHr2DPTh2bui
433JeULAnlYwUGnVf3w87D6d1QiewKNHGoQJEU3cXBVNAb/M1zW83iKPXM7l type / Type
DLNFA3xvhRwFOW58ZrTPNUwTrtFy6JwnTIyrcj5fFs59grykqYGb4R6npKmb
/ZGkmR3ALhwyDQbqxi0Jj8DmrMGsIG3L4Z+uQJkcL4tr4By3nCSMuQDlbA6j Type Selection Property / Selection Property
uffv/6HP8z98gKs+NEq7BUJdZe1mjb+D5fUxVJDV13ixPvrq8KnBdMMdoiM3
593KgRMV8Jk7fq2l085+wWkbe7TlI8nn9bqD/5RbfAOcL5uCoFqUTFtZDr/N user timeout value / User Timeout value
kWXw4fhh/b2lYWY42+t6eV3IzgTmoN8foxWzxjsD58wcow0DEFuiE3HhYuKP
+CSODtMsV+VPQDawD9PiCjh83WRT0MDnGZwNPmpo0TEXKXhDcWt0s2Z1BaYY c) Are "transport system" and "Transport System" used interchangeably
bsDoY1kOr2exLH4sp6BCgdq5k+llwvT8LiFZ+JMY0YxwVUJ9duqwOtRnF2Rv with "Transport Services system" and "Transport Services System"?
ZHDJiEXB8wugoGk+e+dWBU6zbFe4hCuQsFkNk21uyhZpglnSFI8MjBgQPEB2
qNjQXtBFyYoc3jGfnLiB+/FC35FZ5UCTC1DxaG/yd0igW7zRJZpZqFQhq1uC We do not see "transport system" or "Transport System" in the other
MuOE5eHJCdMQBlFWTGmep8B/X8GFgxG+AkKr6mrdEItYo36WXW6Q8rra+enT two documents in this cluster.
Vuy5zDBefg26IZ5K9v79H/rqHbADZGyDEkIGAVsbvt76udP9ioWWF6B4pqTR
8hHreeIZ9G8K3Sci1Cpfblu+G0Dqyr3+AHrnk/tffvbhwyiTf3358BH+C6nH Please review and let us know any updates in Old/New format (or if
//IQWdqOJVhJDORVRmfo4OQsM0LjCEgmH2AWGZprRQPMGIkUX+dXpnCJ6RAi easier, please feel free to update in the XML itself).
RlLDGP7NvHPIz0s4AeUCO6eaL9taN6GNbhvdTWQ++RbHR6bSEDX4gYISgxsP
OlmXI+vrcEH+6ODH2buRKyaXE1KP9L6Bco2mI3ylvSJOU2dLUDeLihcTjl5W d) We have capped Transport Services to match other uses in the
BWpmfQPyCAQ0kDpfSQf7V7Ik37TRV80k8ftIlvOyBbndgOygy5KhMdAAn4Y3 cluster. Please review the remaining uses of "transport service" and
R3BZZzkOUTIjbdCgKDIcIGdGAzT7ySfZOdhyYDot68strfl1zeeavf+kkv/8 let us know if these need to be capped as well.
sJO4cbtxHiKCiQ8Az1qhcQVqQPZm+q8kYmjfmaugnDfiHadGMhvk/lfwxvFM
5UjRew7uBLEE5sywtJqHx/eeXyNTHoWP8N+YH4J8oCOIP80MDQ4DVoIM38rq e) Just a general FYI that, with the high number of capped terms,
5fYruh9jtDdBAe/wXPMWdDAkhjkviCeRy4xx8wqahTADVh3xVHUj/fxwVlNS there will likely be further capitalization questions coming as AUTH48
UaaoZ4yID25a2UDLzY5wG48r+YrIxaYgA9avEh76j//4D7EYeM+zo3+SvTw4 continues.
pD/uHSZvmpz8HbKj0YDf/+3OQyL34UNiAbpvhpOBseTQ8MBoXrSfQ6sb/55P -->
/He/H5gJyJEWbw5pF+YAv/JDosDu8rIafAw9D3lgAvzCOpDBzRUyODTLWH61
m8Wi/FGJIs/+bSOW9wpdFfgEqhk1sOeJXYksnwa+P+IPPPjDKJtMJofyCC9x <!--[rfced] Please note that we have expanded abbreviations in this
6AlZtt4v1rrgS+tcSNlOGElfiBQZAjLd8XQ7vs6Xm8JrPROnVy8l86rWc8Ev document. Please review and let us know any objections.
6EiiHgEH+Ar/Y0t/RJUHhsUNMx/FjUS6GNvbd8mOBjyI4scOdoZvMO+oDJAy Examples include:
AWBx5p9j5LtLNNRmNTDxA+THIA5h1U07Au0WhTX+E27ghw+HxCDlssMvNGlg
XEAFS3IF8TF784EnAhZYh9Q8diQOIsE3Vs4cFC+40lYp2pCpTmoU6TL0Hctl Path MTU (PMTU)
zHxGeGagoNboRprRZFFXjJQUnQ1s1l8LFnMr1JnwUNHmjngOKLEoNLbroiUe Differentiated Services Code Points (DSCPs)
8rSul0VeYQgGhRqukBQufIsp4aJrNsUFbvIFaIVtcTGB19ARdFk0vddK/p1f Stream Control Transmission Protocol (SCTP)
bfHJ1xtypvWeBC6zzKrNaho9fdahJmofxv0Gmxd0Gq9Sfnf+9fgJzeI0O57P Datagram Packetization Layer Path MTU Discovery (DPLPMTUD)
4U8thcJenF4/FmXmiy8ffPiAc4bfPpffHj+kH3N+A99/XuHk6NhgAFB6V+WS Multipath TCP (MPTCP)
+B3tD36K+TLpsKVMSRgJ2JB0bhld8hFcTZijGojCPHhdRlajvL8EhQ/NLf40 Low Extra Delay Background Transport (LEDBAT)
am/wMZzNOXrwaCF1A3oh/IUiZ3hqaA2qJcanQjMcRTsDlIIuS7T+87Eq5HPS Don’t Fragment (DF)
NXAp8G94DmUTvMdKysWB2YFRdtoUYAmgw/rwArldcmLIE4GJ4RaEtdHWwH+X -->
cyVOmEADc1rXrL3RczCYrvIYZQpGPUD6wewuvv/bOfzlYkQqZLzFuawVB6bv
wGd/Kpoaz3UFijyMWizF7EJXRjQ/nAlvNY4/IUFA4kxuJDzC7JkiZdd5U5Ii <!--[rfced] This document used the <tt> element extensively (and a few
D0zqsrsiUkQHM7y1qYaOg46fpwH61oL2rdNNkc+3wHNk3e5r1MPAxqDlAc+6 <em> tags). Please review the list of terms found at
qm9UUVD3BvC8WbFGp0ufZ8DylmAtbtAf4HCtM9hlHoyYsf7Rcx+yli7x1Dt0 https://www.rfc-editor.org/authors/rfc9622.tt.txt where we have
2YrJLpzCmwnKD/FTK+ChxBNZATyLrClY0Vtj5bIm8w7YO8Zv2+zeq+/Ozu+N listed the terms as well as if we believe there is possible
+P9nr9/Qf799/ufvXrx9/gz/++zb45cv/X/oE2ffvvnuJfzdyX+FN0/evHr1 inconsistent use.
/PUzfhl+zZKfXh3/8z1msPfenJ6/ePP6+OU9VZKcN/mQd7A6Rwwcrorck0gz
fXpymj1AxvEPwCQePnjwJTAJ/seTB188/vDB3VxhXA0/VlfAH/ifLNzW6yJv We recommend that the authors make updates to the <tt> tags in
iPiWILTyddnlZHLDpYcThmMGusD9zN5co3IMVrrQBqrIz/iI3n+yBqY3w8vd the xml file itself because of the magnitude.
ik4th2eeDe7HIcPWuyZUb3FhSJrqCiyYa1bqCrBY60aOVZwZwckFTFkpx4/g
gt8r2+n3OpeJmmejaTo1vY4c6WV7jGJUW5CRoZqIN4sYQQOf3O7wIaNby/t7 -->
4E3Zt1M1E8/QMhJ1SLxOrFbTd4J/uRbpf4muh3UNEhhYwojPln2q3r7mT7SF
n4TL2ABjibXKQfUI7oEBpQVpBtmiriZyWYEligyYfEDexI4s1qbsggUJ13ZJ <!--[rfced] Please review the use of the slash "/" character when it
u48DJtJ/wG1orDHWDmRR+DZStZzUhM9pUwW3Nxr1eZej55VdEB2I8dW4hsOp communicates "and", "or", or "and/or" and consider if using one
IkdES7tGKgeMKnPJdRfZg95gDKoSuxp0Y1gmWMh8cVFzWta4MJrFK3aFyodE of those alternatives would be clearer for the reader.
XMElq8HCbtkJFU1FnthIUMRqh6DGovE9z0QHpG8B0cq/2B+Ku7LBRIjllix2 -->
H+TIgJ7hLEB26S4xGfBeWR1u19pGkZ+X2UpTIOMn55gces7hBRQJm4ZEC7p+
5PDnG3LX9beMlNXxHF1KVbxsb0wHf0cUveGIAK3izPs6pkV3UxTI21CEoLcj <!-- [rfced] Please review the "Inclusive Language" portion of the
8gLL/qJCVbIhk/mIJ7KiKbo7UVvN9D1xZYsxbreIva6kEInGforbi1uEn3gG online Style Guide
+i9Q7cHp9TM0guxnRN/77LPPUZsXd7ZePFrQ8x9xG8rOO2RIUfH3zkvM4GUm <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
kZGzFTEifq88CVM1ytlmmVuHfElmVSckjmZglfCe3fNoCzhgdO9a514LqknT and let us know if any changes are needed. Updates of this
dmNSPAa8e7uHA4JZlJebxkvtWbNddxgqWcOmgyWBNoP3IFq6DhMJFuIaMx7Q nature typically result in more precise language, which is
UwXkNWuAHwYtNJzdntnQ03wx9abxAOjkHOTjnKFCuptRthqQWXhlzUeRoGtL helpful for readers.
QZRR1vp4+D1gH0g691gc2DcPWOehD7RANBI7WGwqse757qVuR9KBFxuQBfn8
Oq8wWiued8vGDZuVnZDgQlvY4wONAJng2QZ09Wbr3HGVRLdK+B2NEb23/tJK Note that our script did not flag any words in particular, but this
8ETXCfcqeGdAgZ+ZheJ+23MCZh49ofb7wfv3oBqNI34C++K8cWH8IYkPGgZD should still be reviewed as a best practice.
7ZVihaJMxL7SlCCdCSD5nYLd9R+P+QL7Tiqw1Dg6hWs4SRcQTdRYEXQfw8nE
VxKny4wIJZrq3OpigPl9CoYBMmZgpnMNT70tVmC1+NlkB+WkADsqz5b1JXqt
M7O5yDFGGct0omPaHveuRD3SCOaRfntajuegYM+El8L9AdFrfmFZ4UNg4gem
2+XDPeQLCTJafwYatzeAfBjebsQz5Fu+3A4Eo0C5InsOX76mTQWGSM6LXVIS
GWLYiDEoLy1aWeYnVRjiaan7kxyQsucJSZNWidoZaEjswJjiHSnRGa9RvJjG
5YhoUA7pGPrxUZLonRG5qK4xmAXEXnk3DKrXsyXO/KsMecgL/m5xcMiascyj
gLsz4pmxnz+c/q1ze0kvFEmwMZkdevN2TI9jDTw9Hksnx1ORqWE0E6wXYKxw
fD9do76i1vvgDNcFHnfN/z/iE/ypt34c/VwYGTmsc2/wQkZ7j6qtjoRitncN
VTOiC4gvdHz8BUcAgZe88nkSan1ohJ0eIxJvrr0slIB6BopJNUeDAgynurty
12WeFSq/Ei4hA/Ldwwctm1ZZp8w41xlhuuZKs2HAHgITeeDjfGJ0gSeq4tLl
DHwnDj74D7FX8grmtEQ53RSXeLroo5huU0tj4p43Td0wz2WvI6iv3rRv2WN4
haZslX5P6C+c2sRxRgoqwPATzrnZEu30oyg8PbKeOAACtFKvCvkHHrW7yq+L
Xf5TVMpz0Bb8MiV+Yr8S3AYO7sQG3S0Ub7isalaR+VMH7O4qaB8OKXK7RAaS
tfmiIGn8SfYdnc7zH/MVmbxJqGZDfy3krxnYkBuUeyAL0JGTrH1F6cnIn5GV
7oiPdTXHcNB/3vqbO4q5Bm4sWOE1qU+GVY7kYlDUvqDIQosuSLLJRN6wD468
fazw8BfGsgj085jPM1+jz+v151BlX+ix1n+h3O9ipJ9EW1onY27v4GT4ezsm
g2zmI6YSuA9K9CUaHG2JimZOSZDossnLbv9+6q7pNVRVNCwh/IVXgJO08yeK
CRQi7o9WuB3yIk+fg1Fwm0/g1PTC2/eyRs0C9zNZvng01LECf16yE/MZslKi
uwVu5GnMBx39+Q3aFiw7YOTkEV1s9tRzqwmIO17SLMc4cqIlEOeWID9lqRED
Y4cZhuiXYFH4LYTNerHAFAzvqTWukgFN2q9wxzRdmCaQDVudoOLgjg7tdLxr
KAVl38TR66bbrhgzYx71ItOUEafrow0xj0uIDdOiXODoamqR3CIxhtRsnBKc
OxnEWXYsJjeJ+ZEbZDDqgMizWOrYaHL4bO6sd9zPjacSL4EkHTyHWQs5Wgch
XEa+4U+Ik8GEhVtK9l7J7kX+DT+ykzVK+sOu2+j4Wu/IraTsU93/XDnOyPM+
+o25jQRW6QKJPxtmffRP2evihn7Um3RwmDw0+SsYHr4k6uBeXm3vDT4j0zq4
h+USLTwT+P1pMJX4kwN/gQ8P/DoRX/uBaDDFq/YykPih+/TTHXfd3uWCrzgp
+zIeqQciVp07E4vfpDLwPPt/gGn2f5ycFd0BC5UTnDdpFMAZVlvzT9gQmC3v
2ZZ13JSJl62PhLOvhY+f1dfYppUJRr8dxKcy8hnSu/9nYMvv8lp/C2B1XmOH
qUXzmqj+bZ4Z/97Q+VtR8n4Xfvo97dYbZJpK4Z55rsKVFUV6oiOoiuSMoiZ/
w88bpRsm4D8rAyIBvdVLJL+dcPidpjPGtF15KVY8QVO/hMngA/bLZ3AJD6LB
+TYe2odOliApDoQ6unp9B6UHHz0ghqs8xmv7JGZQnITHD/2uT3D8g8P9S0HG
QQvhDAricieko/xsLofGGflnrI1L3LbhG2BzSG9neRF/o+NCYXNToEOqjRgi
bzcq7xo1xQjQhBQUyongCE9I5UC3PHtP2uze2yKfb+PducdST8PGcWzSsf4o
CaPejTbisC3vU+piu0mEqD04UeE7NMnQrYWZhOoaRov0Xnj0HkcAww8P76mJ
KB8+HNEa0IBEgRV2WQO+DhN2YIh7aAbg0TN3SqUF/2rERfIYyYJv67Z7DcMd
3NNlw8beG3727yM3xqv2cjz9T5Yc51gPfKL0wQ/qPw/eA9+FSf0FdNHFVv3T
W1ULE1GBcr/bNHzCqFDDZD7sEk30WRpX7pj/ZjShAQHFCvdt8kntnztIqIQA
/t4i6iSaXSykgg/LPPYQn4uZdTUoSYBT/O730Yvm58BwewxFPAZbe+1PInEy
IEWI5x3eQULC20H6fewkgiC4i9hkVtuXm70t+ZiXcYUkH1POSJJ/UH4NiVYz
B/8bCbc0DEB3vmXTuytWmCXCSTfDTlP0ggWX6yhI7hH6FfGvwfk3yfqOv6sc
iyrgHomjd+S0EoKi5hIrj6fIofu85bA9PMLvopiY1+SNyhcLjGWQfmA2I3Ug
czrZpiUOmC860mLYwxMNbGc8Mh7vaHSaEcapKY0IpzHJvkUTa6RiKJ/W114Y
jXC6LPqmkiY160LaFGsbMAX1I+NxXJXNPBKOtRVvKGDEcyTuEjiSDdeZaY2a
5Ml++ulkAlK6aYC5brAW51+BCbLUH9pxmOtCKy4MJT3ay0GC6nRa/ALzcG8s
yJEPWnxQwfMjXqhgDFsPlLGRJ7obODJFpopsSfwezOV5icWT7RG6oFABq60D
RuUBvuudwdnZ+Xev5QQcyv8THWWHmRk9Q5rAKXzp4MsnX3wOrO2s21S3jRA9
w7oE/MIW+YEkN44yiSxhSiIVaZGpgiP5V9vsn7Lvo+mMsmjsv+3USWAHJpNJ
2MDIxyLPDSkJQ+8OBMDdXY2+sJa7yMbv/zbCr7+uVf8OJ55ti+7vLJRJE2up
is3TWFgPRzTiiyaPk0wjfRtVoJrSujCMIWTMVJ+ub7oBaoA7MyvwZVaf0mfI
GY+sFDaDGbRPOmN3X5jyXBQzyi1lnYxsCU6tAhHScdUIRwrwRWSvE6ev02pH
6WgpZwkLxhGObYq3xgjInLnElBzO26mlqoN0R/MtHIAmq0EsvL0UjQBmOK4X
4ymZV2gVLZdanFcVSwkd4OskfM9enKq4PnRAxx8zM+VFvNpw1mzXbtcFUGhs
Z1BkGWdN6Zf2LxrzP+SiXDlTvzKKw/cWEyY8H6IRLm0S0cMkotw1SS2YwAA8
n4N0MYcuPcMQGUzvNSlG+udnoGKmnhDR3OwjP9MDIbrjoH/kLt/5dbRC3PsX
XKyZOsHsOZCKYhMP5PLR8XLJ6+D5RiY3ym/Of4M3z5ty9g4BNE6e01WuMGmL
vAIq/MOyjuwuhYP2RrA9a9bFgUpP8+7qhLS43/2et26k3GlAhGYvSCqhLYTa
B46CMZUS8zVwc5KnWWGc4W0NcQKYBeoo9G498sVc/hqQNouD+Z0lAqd117qj
w6vGg7UL8qQYftxNhj+XxZWLmGPRqlkxnh+xkfyRHJBfigft88A+l8gy4hP8
SSaTgVNphygny2LaoVcOoikc3rqZ4a79SoYQqaWfGMea0WbefxIyAYMG8sG5
50ndcnabhw605dkyx/xBrBpf+1qK1uGtlHz//fXEwdMlDjPKnwZmBLo93+Wh
NYw4o/22FG3EGWCHYEtII+JiWZaLAtOfOVvKRvoHP0bcaV5qJTHM2OeLjiKT
CS+bhueMhwqdR5ofZkY90BC1/I3OAlNHODMUzX1KC+mcJL/2EtZIY+JyM3pc
7Tm+KFuJifnsM5cmh0vmCaeFI6PgHCk4xF1pFSdyb0IknDPwYyFnqzI3Hfni
7D65XNSVwW1pCsp7hSHmxPS8NLA7jQFPYY/larXpKPF1cDzn02vItolNY00v
gwvFpjQQxL5BQKQ2JWfmRLll4dzxtM2l7R+3yQjz5+1LXskQxtClg4tFmcDi
INiZ/gxv4CUYgxHDHMPkF1m+wJRi9mIXTdkSPnFSzDP0jjQ2cc0uLN7gZF+S
/Myv2Ju44zC4vkQyIipRzJZOk2LUa8Be0CRSAvuuIeH+potSYm4YI0HRcB7s
grmD8xgiAY4Ar8tBe6iTj9MmfB7TbqoLeRQnKfHt2R+CallSMRPGVHbtT5bu
jw90twQPxMoTSpR4u17XneRmaMJqvKURBwwUbn+uqzT/tmwNB6FPw1o0TXGl
hPQ8bxCsJSm32nFxcg87VDacAdrG+ffrjS+RjYAjMFVr4pPbgvpgxYgUO1K9
ST+TnF7Jl+VPcJlsGcwAgoGS2pks4NHkIT45KJb4xqOVuJESZTrNoXVoXSyz
POLymoEXz7ZkZB+Ttepn5p2PStkCd5CKum32miq5sTiLfxhTafeHPWLRnzUW
EHiHxpZrwnu1mphGMy7BTqjakubYUu0rm/6+kpzjMRhFXG8aLHbhrNdjTUwL
tYce2EhO5VaYFdID87YNT4L+ZulBo31SBeKLDFEMESIVC8psXYNQ3AJzruCP
FN2oRf/2S/ZUtLbCDRZcmOzqRUk5OJKk2HZ1Qw67cfYqf6e6F6m7ME5Y9x3g
ZJZ1/Q5TwsB0aLDE5q+YJYY1Y6jHbODeWDQpX2fp02xAr9vM+XyQ38yvWLFT
OyLLcuA2XI5dow5WcbkD0OQ1/5YdcEyb89JHQhxX5bT0SctSInW1JfRFqnFB
gNtpvWwPsdAGLSVfw4N1SugM9dUYZbJg8sS0nQFYghF9srNP+J5tjfzwf5ap
XJfthnGkeON0OkOKod4WvAVXYNVRQSGjuNTNZV4h0xCXuKNspH/5/l9+R6+s
81nx+8m//O1ffqdD4c//8nsqKkEfmA+9+ccNhBe5LNAUacAsFBsGdwjI52Jy
kVE1Ktb6rrBajiuUMWA+flfVNxUSKkGjMOfyZM8pz4ILoMTqoRTQQRYXdHvc
FoQF2cNgeTqSFmowbGZwm7YrBW8Ly5Ss1TyyqngiMEhLgI6Cz6bITgQh6T/d
Pyawkzdo1ghwHQyAlEXYOaCcUh30csPRi3z3WrbkfcTi7W62nuAI5zzAX/Dt
C+X+8MfxpquBxR/i1vwFGAZe7iah1kh8RFs1JaSFGZNObnYG7lETboEvQ2hn
WI198cNFIAP0ziKRSKKwr5kg2Dh2Qmx9SsCOCeLksXz7xfPzr22tEtnFuVpO
e3ZLFxPV8IKUowF9Ge96I6qqxo7efn2CLI2kCwWq6PmmwDJi5GLHVTwls0G+
SJF2ylfRmF3yO4TKj77XRqX2HZd4c4W3QY+iP7w4fn0cvsw4DpqI3mwdkQCl
NgiEcAnCAWFrP8XahUsGn/vUw7XJ+70fJj9edavloUhXkoVzMqf33jNS0KQQ
3dt0+NauEx4PkODEnVON7JKrReHK+L3IW92FnRugBId1hNc1bRxpNltTKciz
wWIMd8t0WIWgFGNK/9/Lf1O9gqKOJWUIUZqP4Egy5MuqWJ7knLILc2gwWMnG
pkBBpZJ0hRBZ/PW22D0Pcgy0Vf6u+AGngzt+mrcU4eCPgYZZif+AFXvRLAw2
4U7F7JzAOYxiRlgY6rIZeAF1PpNrbCBQYiCA9+89tBXmc7+q227YLN/trSD3
A3/GQGvQx9jUV/YfsDayCIODdfAIYmRBCqxUowvEhDs4FQVilB0jgY0wrhUG
VTAPCslLDs8hrBYrP4TdMeQlqWT6Fl0tRSjxtOet4xSQjoANzmbwWIxqsCBj
jLDCWvwrxldC7wCw0Bg6LMaiRcu9NUrmOEKs6AE64g0aKq1gZ9ok+4bWgHMi
SEmDHxD0O/yA/ssFbS0kGWCVfZEUgor4HSqfpvQBltSUtEZqbPS2d94rkPKI
UwrC6mYFle+3vtLTaZkNVoMqVghXG3CKe1WzYkieQ8GKVFRNZFOoxC63vMN4
juqJZJA2F2ySOCfd68QEccbVv3PCQA/4R22AqnPoqELsLCWve+1Vvi7u+QR/
36YCofh0ONXh/YCCR9c68UNpJbGdzM1VDcSbN5WysT0+WeYvFVUqbMVsRuUP
tJfLggs9+Zg8iBIonXDCbY5XKlWrMULqUHyRpV51hFE5B7W5rLSekpdf+q+b
iYPenwO5zWSHIoqTXfJ3zCs2tIvmeiH0NQM8dLZAyXnuzlPV2iL2rRSCgkcY
AVwMVqaAjX4OO3YyaFBSoM32KfMK8basVC7qvUZ9k2uM8WowPEr5E7M6rKbH
fNCNwjn48jTglr5i3W6SDO6FhfiosmQlYC5VVHOKDye6JhgLxXLB+nMgP17K
gpCAYMKC7ojWi0Euk4grrVXwDAhQa2vmSDBOu5hSq3vo58SqVk/EbEexyh+0
d+t6kqhiEHO7IWIYVsKWoBv9xMIMIaGw141rE1UP6e0iDEg2ptTRsRWJL1V1
QKpgD0IoxqkU+00hFRSzxMA9h+UociAld/mwH81rqHrKJCRngoTjtSh/t78O
8VFKcEILqGRC4aDBUDWzfmMkhJ/4/rbZxaq9fMOlQxdD4E0HYG9cEz2NJCxZ
j+s1KAto589LzEVTrmmghInQaqnS4t3GraAsDVQk1UtfAWtfImPe8tNo6UfY
KiJ2YK2T7IxteZwJfg5n/lICQBf9hYnnO4tWg743KrAkgErevLki6dYCWlS2
hi65rwKd571SzxSN7w3YIDBmMdeyOJ2BX63WAjNNwu3T2ZJSV/y4xvy0e4QF
l3AzLZFnlhI7ovgS79Je8ZzF9WWR29FrgoxB3I/tFZneoQiLcBBA1o4X2Bin
mWcCqAWjmWq+Mp2Lj7rE7kJzmz2GFKh04+dR1OP0CvVpVIVT+AYuR+z9nq3p
jR0QFxorM4Y4MsU4+BpAtDnaJjgvDDtE+ib8NwaHtl7N4Ec8YLiLB8NYDO0l
DjDpp6cKSkWERhHAx21ch2uTcy2QV3iIA0ZEwBPaEJC7QMSDUMYietVcpF9B
l0sowMUQ8mZTklCpjMa5iz8K3B6J5w1+TcG8aWTCK25KlD9JlsNAgaeXOYJo
X9WSmeMB+jWKO7Qfaqb4h+F0sf5/Z7jR7bRrRmy60rFw3t58ODjiDgajeiG2
OAQzg591+Fn+0zj8CV4NMK+3JwV+/7coWfIuuXmUF5hkXd3ttZ+ZDLgjH5AT
sztUbDHfq+qlzAw4kRTlzG5LGayXCy6AunC7q56lVtYnmaUpHq+O/zkk9ElU
Zff3fBzcQH1g3TCW+g4UVcTZhXsyI1AaOPYbUQrxGjRNArTmjEeGYEiTUQxQ
P5xPQ0lt3gg9aA8n8W6nN+/jtttFy9+/x70i7o/bZDnUnVVyk71UxCCGd1wu
51qPu3pM6UI221qzVWZAyXuwSrjQm0AyCd19YEaWEAbyJyRdLUm+cNwVZU7/
JNUJ1YflUm2YlI4JhHhZXpYCxmedgnbvUEF0QUNkeT2YtcbcPkCdEjSeNygM
XjAtiQI146t6BaRyVWOhJRtMHzM6E7tFIqbgm0lAZ6klCqhk380FIpAfaArq
KIEaJCeKcw1MQm5Ca27FqK87iWDodAeKe6Pj7ZFIH0lg4GhDNaA95T4cQu0E
MLKyllvL/MTgJ+3nNwHKwKHYk/pJ2SqbIRWZE/3CZj5Fr7eQEwpBKsR6dJZK
UKPwlLHnvDz809SnyYDtT7lq8fsdl1i0CUqE3RemKHZKAGHKNuGpVnCqbUeu
5Fb9x3wAQVcX1Ml00ZIE7sKpT1mlHQnBUtoD56/HXHOIOlQlMdBK/AXau4ps
9JBnmrMpzySv/BYGmyHwq0tvGsYXbOGfj6b26GogrYs1aJdq0KF3BNW7eoRg
AhRnrC3MteGbE8M2tCH16SBFKZd0F+XSQAyFT2ON57UzPc6A+tJqw+refxJp
iHu7OpDjZCChd4/y6ij1fcHu0Uh57aUcmknFWGBYY1yUYsnRV2BniXyPPqpq
905IEFIjJ/SdLMeaIeRfMhWrucfHxHsnnkTfV0lWRPSAs8fbbLCODEwcxwAG
BQPD4HexJ8MZgDy+BZwbY7wqOCG6GjALCu8C2wFesSj5CgVJ4yiB+JrUqyDP
XpwqA2KJFv5CHGZCAIbpTvluFt5k8F7NAKxUhsWRz1JrqOEOUJT2cPiA99Zb
S+sHLKzKwPZ78Pl4CixsU6ECCbMQ7Pp9I1NN1uPHj/xYcglguMpMWSPJbP/l
a21PA29/pfSaq/jhSvO0i4JUmnH8cMRJGLfGTWVEzkgaU+6yRlB3/4ljqSIf
nr0+y87e/kXn5tmmURz27U+vel22KdAJ7RQB8isIv5dg23XxVVb5hLvOwiaR
q7DVEMXVZpVX45D9yrBvHEAxFBl0bAUYYP4hqPVTIPIG+2fN6rkAipI6qa/v
W+iLU2kwcPDgy4eT+5OHk4cPZLW3v/Lw/v0HR/Ppk6PHXz68f1Q8/HJ+lD+G
//ri8ecPjr64/8WjozzsnG9QZ8jrIGoL4xMXOOlA86R8iCx4a/0Ih5rERS4Z
bIKK6GLVu7HUivk7rWJ2wU4CklzSBUO3Zz9ATlHdVzJA8XEhOf8X6vEdyoyO
tBjgGuiECYLbBadvqvpGCZtMZ4G+guIhF4xikNlPqJ2+eCbowheL4sn9oyM9
of8Npn9x6FDLiVqVXEQHemESKWjQuf8oyr+LaEuyCxjgksqG02Z4vqy65+eR
slbL3C7UVa8KHELQbsd8mrBKN2dsZPYaHnz952evwbjFfk2262SV4R9YdQrO
+h1qcOxKddjmTRDY0KGKrKMtMMMr409LSASJknjHxkayBfAJrjAndPvcs44B
TrFpRjnrBPRMe87sAMH3SR1r7E7VWWBYFTrMw1KZ41W7QaHab9cQK/aDoi3k
gW0pPdMyJBD9N7XviRf9yaX9TNCDDg+npEBuk/TGWInOrMcZvZuJXZmAYcUt
xplLUc1JNQgV1pErtnZ0o8KrOIuRKubMbq6o8Kpv7AxpGw75MkZ9Aqe+E8lF
bb0SwmIrokOcgk5Qc9BI07VyQ71QNwdUBmY/5g96FWjYepwYlrLbElBWrAp4
z1uRc/u1DfZbcpRTAs+Ovcp7h5aAvqi30lQaMXRGIWxmwBedeoRIskc+mhVw
n5qKcCVfbyfOMmaGA9ubbR3dz7mHmtc0euyHqaKTconCcTTaZ4VWu+ZxxurM
9Qv+WInQr7ih+o66AU2qoJR57Q9IuyKBs3lcA0mXgsp8X4tmLqyc9x8kZ924
g9fH54cY7yO8u6XBHRSpmGLZfkJwoVT2gIQyQ1+bJxFYLfPJlf5t1FtnKQDv
HurYK8YkZD9N75Y3WMWq9imLQPnjtt40M/O57OD47NUhEgP/JegF5pEzfCT8
m7DQpRNCC6JJMkCCZjrxGA7kjmP9nU8p97a8aLwWGdQSp4uIM7F4AqL0UEWL
uBunhfNlXZg/5iHRxLJMFhRgAv2DVC2Nj8oDNTdZJByKob2Ux/DbWGLfStK7
SweONJI9WRQYtfRyofWGKO5gGyDzw6fZosAEL2QE1C+ZcrVLxIdM4nRisfYX
wchhxTszGArITetjV2qq5Xr10I+xrHPfGXdT8VB+ylTbNVgARwPuqIHrBc0k
whyd6qv9p8rQCNbRL5Kf8wVcuFOYAy+Z0RdYEn6RsTzqkBnR+V1gX6htJAT1
deokhB1BpfPcfIySk51YAjnzr7XoUIMz9HRsS3loUhzC7znCk3TkROlF6SzJ
gUktbMuY0uJe6zlg42FdOtcU6Zh7ICM5Jvq516l67GxaLCiluEcOewwrzzmp
b8OL0wP6/8KdhyHTyCjH//OaWNIuDLb1S5BV3YH+hxglnlY1fjIgfkSFStli
z3/dV73gUHcRg0V+sHjlZevB3h0NIMBDMYphSMju6VvCPeWSMKNysSAZkCBm
NZSKIpxf1b3zK22/bSbh1DzxyPyUqhfd5m+YmJjwFTLZdF33QQkqomEmQ2F6
fKxT2NwofhP8dLAHWm3q+16YRBzNhJLj8fzDgyho5WN7OZ51P4p5u9g0JHPU
zMXS5CBdLS3hjkjFBGaegHx/iad5cH7+8hBYcbH0WfFXYOcUVDxJro91PnuH
r4oSBePBXDeY2rPzpc/1pd/iYgrt7zboz0iCnJEA2XtD7xjptkFvGtRf8IGP
Aye+w5cHX+2xhvjOW71j573fpwE4b+e3Q7aDuV57eYGEQJZt7STCVYRsmmHF
JznrIQHZY+mZ6Nth0aShifFPAIqkzfTEsRv6WsRgxOUyk/vQskszGsl5PKDp
dkAm9LlsD+SRNimA5oZPYuHFIrDwq3wuQHJs3uwY2QUT7+MoYrcC7SK2qVSx
k+fyybZS9nMR5XBRc4aL3+K2mzX+1xDEv/GdH3hmlzZwxvJAv6kw/q2IBorR
6G9i8J1opyPG/vSRW3zextLEhRrbA2XQ/r1vgRJn+UB5YGmKVNZgN5c/hThZ
hONlUy002uTFLBxzNo6wTCsjg+tqQD1UP6Lc5+Aq3YXAyv5kXPWQI3ly6wSS
S6J9V8Seb6WRpl9w4s+BjQyRrpD9b1Of5Wt7ZxKwXC78jxcDidjcGqteh/IV
DEBT5g03ZoJpK97Wxfp6vncM+Du+XVaLJeHwy5aHdlmrWs167/kOO4Hdnals
uY3W9CLaXeOpVFWLv2Lhpfzge1swlj4aP5RzujuJ0FJw1CEstVv64elPQlmf
dp+1fhUbYkSmKJnQvj0h6mTzUHxkoHpNoYn6dnrJGyaFJuCKk5g8f3n2KSaK
42r+/N2LE8lWRTfgjNp0o++6Zqhv86XgPGmHwru27weD46HjiC9gFM/lqhyq
MlCcB+7TZZy9oZGfgWCQSl9f+GO2qvBJc3iDaKdwZY4aljAuQtpfE3bgMPaF
i+0+ENH0S/NO9gA9YSO+1OtIjQs8DlMyJ62Ufd2p+AMDVkGMjs6bSirONUb7
PKOMd5s/mXRWzm1bRykgY4GpbTiKQTEoYx7g1pnYVxDiHqf+irKtKZ9GWlRe
mJD1BQkGJUHXbCptGUan9Pjxo1HQUeMTBC79BP5OVxmnMcmeYkerInVYo6mF
B3SlsLuM6psm6/0dAdBDiN3hxO/41YFH93551/P09Sf0+Z2PxMebLoKAUL/P
UmjvbGgxfxMIMuBw/vbs6jTlQ+FwtEGvoJC4dM/lXlTa2DuYrTv7I5n0j2h7
xGMU5QBIRN8XohaogpKckt7MQegq1I5v9/nt+fnpWUaH+nFpOb86mD4rebdt
SxI4NsipuKRfvoSPzAS4QyLK3Zb0+O+xJJsP8VEzTxRAJdHU3cnZMjD/qjZ5
3iPMT1oWnSXJ/Znhg86On9UDyKQ4/PzV/HYT22UihTM4blN1KdT89FRkmrGG
/+JVpj2xyG0AijyRHNlOBMN2iVofQYd5KESreAfN9YVv2NpQcf9FHyNw67uu
Jdp4qEDWBP2oQaMPSvsRDRhh5kFdoryEHT5UKdVOUihw5WjBg7SeFb1UZolT
K7JjlSUIi7fSkcnu/oX0ckeQcC+oTGhTJdL7TwYs5p3yi0QW/m8vpGU8GrAH
/73mbTyutmP2BZhvs5+FIBDJl0tBGKCxOaIoUdSDFGHC83GK2Z4T8c7TSxgq
ie7IAPHRO21377lbfBsPHz2aPPwM+ef9XS/T1f3s0WePdj3Qu/9uuCYJp4x4
roN1R5n+9W71VR/faau/2X+/6ir/Im/h7X26iPaZHMVdHezQ/9lIcgfV7HXw
G7L8eP8+/M+DL59MPnsweXD/Pvzv/yLs4f/5TyPsE21schtpiy2KpfAfTZ/9
J4edzExqDyYPHwOt7HwtppW9XuYnv5hdD6i2D/8Xjf46NHoSLW1//xjVB3ZH
45BCJYDFZCqGrDDk35pqg9z+T6fZX6RifAzB/wyu/b+uxB2vxGgPC4/aZ4hu
bqMaOzDt0wr+naAKV/WSwf0CKOuCXtVIRDBm/rF1Bp2klWhVMO18qqhOSYFs
wbgi/NRBE4zy1gr9ZArKTt9AyPaR7XVpYs23wzJTH7MUy5jdV1KT5/FqFEzB
g16n0yFFDp4eG35mP0uQahOF3hD3YXvol4H/7QcnCOAQ5xoENW8KN8eLsSJD
WsIpmtnubenWglMgxouYohgM1lAF7SLjX7Nnj7Jih5ptUxUiY0CHfgSCIxdn
QzsbLIlqzmY+NmnKxprwOUwE733ahVAYQsQY2LOu5BgELsLAz3EWFS+xrK6p
CJTqdjHpTjFXfLy1Vz/trX+5FkVSxM3RHScr4QAcd04JcNuYCZUL2IbEW04x
YoGplXg6z7g44+D0+tmhfdy9f/+Ht1+ffPHZZ59TTNCG5QRQJQR4BcCHzw0d
DjYCowfkpDd7JZ9JgosexdnHD/SEiDImDttxRAviofjqnr46/26kiWFy4LBd
z85OToEN+srgDTdem1EdctHNOBOF/dWaOm4/sTumc+Z7YhBCL4W8LASg3lSf
mVEgPH/ZrjyEqM8ptV1mowOjQqCfiqYe46UaZc++PTkd+XK1t8eHezEgB+o4
Avxia3qwOypDs1iOHNo6IiH37xYJ8t+z5wzq9Ev/599p6LH5n+gfv+R/eGjF
lKSPyQYxB/CM5FPutRGKkDoDcjTKFkDuXFJyU7aFmbVsCP+i/7jrqIQQX8yT
gf3QEUam/gl/Xae//uxNZzhOHXrH9KuoOuv2JfidYczPWzd93/jJxv+7e3+U
fQJSZ4x7MCYRBryx7JbFP90byGYw+/eSnr0nLsAEI45qtYqqpUwl6n1CHUoU
1S31t2Lah3UpR6qG+Ja9zFPi454RvCcTQXW3jXfS9+Q08LVjyamXXAwDxy2y
2iZmsOoxcrIIZrMUZr70MKOUCjfEKRBBnxLr49QOZySuajk0LgsgxchU6ECR
/ZjnalE3UwxHatn8/OTNq1fPXz97/oyT+Ip3gkQpSGW2Bo9X5AgJ0x6AFBv5
8HsApMR1iiQYWm5cmxnhiQZdkRA2gOkuEVCfhmbQaaqWJBAWi9KXNAkNqZO5
vbcMz+ElAp3hdGsrZmx8g2uGMRVzaBQP+Uc4FwJR6aStO2HelJpZwJdLOz/Y
rI4YuLCu4kcdTnCSvagYkl2gNiI8CQmr4C1fJ0ELrxXSOo3mxPWPIQdHGo/s
eX8A1vfcqvEaZpMy1PBmsnLcb6pqwrKby7yZE8JBvQgpKYYCRHfz8IbIEbAt
S2Up1fYp4OuQ0vsoTohDUINMAWNKiUVJ1FzNE+lukDu+ulYLIvXPLw+1GE1+
JZT8A24MEEXJsFzUGfJhEpkWYV45vfyPtiNYKMPh1sOIxX4JFMGhMyLAGfAb
Skch4Lr1Mq8Oo9ZZedRFKm0GpoaSROjZCOo34xrdVs4Y55vGCuWae7E4bbwk
2fTx4wQ8K10kho0qROLynbsc/CxPlRVNZ8iBEFX6SmKLPB5jx/CD4g3a4Yp4
XdwM/EWN7RdRixCr+nWmdVOkw/YmOoFj6yTfZgBykuZNGqEHj1G8weKa4ILk
j6I/94eY7FzgBL58ECQ/DaSJSvDZcm7B3vtwxwhM5qVGsHoY7rZkdukBF1DS
4AAYzpQ7NiQejnwcV28Dat/Xkngbcm5fBEPrlokF3d+07959HMwAnbR3M+Y0
Owokw6bwDLlFGbkMvfV0O9Gzgg1rpKR3yA8jhYWmC9lAZr8Wtmgaaa+wbWAO
VAqIgg0fo+8f2/cuseYEwVIHZyVVmtOtcB+TgRt2w3F366S4ebpNXCnclyLp
mVbT4GUFX/H9bVaOe/wg5+rAICMjDr8xW5Kh/JWQBUeITRo2rG0IUVKPvzVA
Tzv44Q2phYPOJyQC6e8g+amI/qyVgNNiWd8MN9LjxMWKt4zqpWGIIRdO6CAn
aLbaRY53LqqbQPSJQCqT7Lj3SBY/Mhqem3ZMdFNu5kDX4qqYvbOGQFm0UZ21
rQX/bl1zz0FYDsOzGaWfGhUT2NGAccCrk/4PT+t6WeSsSWLGY9dgc5gV/CSe
oz2+tpCCS3KdUasJMUIBqEhgh9zTUPk2lDtC8BwL0PZ0AqHqJvmudk5x6tbq
f99/fpKCDqMDcQ/8N3uqTP4Nt6lkr+lNZJpK9uuFWDoXJGYv1Na5YL+G4srJ
zppFjkzvsyUIiDed4KpzXuG+XpPA0IVEFW2AS2Cp9WKUO+6ERAZoOSFUxodK
DMT9cPMIOtJaZZD6meCXI6Vm6Fqz10mzE2UnfR2lh1mm6212MXcxb7OF0TZh
OIBpv1iI9zX5luK40aEJxDjBhXjHGZXN76QUbdFcDfef9T0gxQozZ8jqJ39r
Rl6E0sgf1kGim06uUm/WDeyZdbrtI23eJ+47gW0CHVFPZM6QyJX1izfSIGbG
N+lT3xGCuxdwclfZ+rXzXVJcmYj20MGBt5VmYLbfEy+dnAzkZK3SeQBhLLk/
ZLu5BE7Gk0VC0UNVOMTEyp4tCZTC+Y4mCEqiy2PIIkqrelssS7pA2CmcdxSt
/YMw/0NpbTNu5NEP3KHpyB1l/BOpa6BzwHXGHwPbcO4Zrwp/FtYhnVY82YeU
OAu6YAnNXz3uljVQW9AxsF1LnQRYnQKDg0yV0pTdCoftVaRXbPeR4Y+u7iU6
OhBwamO66/6VUT1kt2jsTncLuQtFKOaclOfIjkfiKZetqDXY6YZRoK6SvDsy
NpdU14AK2pRI0hegUJcpz6E0svMUE3vypvSNh8ZT/4s5n7U0qXrVXoY3bj2p
yCv5c8+LmqTgIHc4Op1mq/gVWVhNKHcTO+60aMa6DW8D/ek+UOkEWnhD9ApL
gK14+xFU+5F7kfBI1cZQ/cU9WGyWFtfesxtnLlIWuRqF56nV50tty17u5hC5
0KV+o04N2SF1cgzQCT36293kG5S+d6AHcjSxq5a9Q+lNHgDj2X25vTjhW57T
Ydzk3ILXw+cU2f3x2/NzECUt4ZDERWZSSXSWL1BJeluAONgSI1BKlL2933Sd
2VeM5rztOqC535jQblj8lO84h3pDFVqhfwUhaQ2FV32R7q6yO9p/yjEmHWBa
CKkut579NR77tbf7Mjrx0kaaVqh50euWDgvW+RLelrYQ4F7r/ux9ABXbbrTi
BXP+11m9lpYIFpKBKMgEn9t256QPJ1SOSyycMRpaOvXGHzpZuD4nue1A71xF
mC2l4E8oVazCc4Y4zK+o9dxGIPzzz7h00heEQg1+m8x0yVRJ+InMX723oeaN
56uNlhmSNnSpcYHCbPU62VvaMU727usN0NQJmoHtBncPIV4vyS19JqWJsnkz
eWYsWMVjzLEy24j4gzoOvvrL2Vcv0YREmvb96tTleYlYg51DrNoNt5ohB4tq
HrQV0ui1lgZIVtd9Zhrt2HkwlbI+4dLD5Cb0EiNie5USznST4G3ZSDaCdpbT
WggSeTeAie0+m7ceS2XX6cg93XFA8P71f5UD8hzltzsdRYEDQ6gqV5uVTwn8
2QeG1wr3+Hrg2OBdNBFE8cDT8Kc0M+cx84+d8FO/ocA3Yin2JTJ62qw34yVr
waAtE2aoBmgXPY0ZLajwuguvp9VAYqhyOowdRLufcQs2gXccmBLpWjOgojkV
BZEqwOkyD7988PjDB3XDgIApm9kGlIsp8Mh3aBdUbvjFJ/efwIuSlIGRU8q4
CZ1BJtkxip8ASmwNLSrQ3ghO9mpKblgae3jqIQSYxKoc4QiSWL7nDRtFJBs8
mXuU1PpvYJ96eDPsbQfHSxXgTox89USkNs7QkCPdeHIGRE795GFX9tpuhLL7
qrjkCjIZjTac3P9i7csV+VNRrIED4JPvP3kH/xjTP8ztwB+P8bff2kzaezeQ
rbswP4vcdMvV8AFD8SmGQZwOgq4DNkrbguvI4pnFF4Mjg5z21CWnZAb3yINm
bmTqei/TyBZJkkrZq9wFaqy5obJ+Lzjm3vmjGyskVXZgNLUwl7H0Dw+ccXdt
n3LIUMIXSMH/FkjhjF1cB7azremXexgRyHPqoHNA7i8fcktj+9U2fOcwpSLp
izYgZ9hPTa/3chxDTqHDGBLwk8u6EaXY5BuSFcRtSoJjd2S8uvTfOFuBy6Qc
lQt7wKucm07a1ox+q3PjL84Y/GOJcN8rDAX10wQ4eZM1SpMWQR2CQDRW5Fyj
yVIgnxqRUHoi1RS3wBvRkN5lyHAXEWIlOcfR2cM2nCETy/yy9R1MXLfRYvgD
PfdifmhWbeDS44xkagdHlq0EvGLcB4/fgoYpyCqKW1HUKX/H6As2lyhBTUFP
sjM7X82TnIB+4ofHlTgPEHvXcH3SNwlkNekHzgieNIAHo0rSZCjTYFVPS/KQ
c7ubJAX44q/l+OtS4gQnkmBwkX4+wK5/xYZELnnP86J919VrlIHrTYcFt9GA
f0W9yz3Hb8K96A0bMiOMG7YfFEi7KqIdTLPyybrBiS4by3m93nNe8yXudWaB
L2M7ZyRs4nUl4mRt+y1BvZUVz8xpD65awNOivW4VO5d2SH4jTzGCFXacWLKQ
pBm3c/OJthholv3qI5zMrEg1LN5L9O6gFiA9WNeaHKi5IzGtDVBZ6OhTS+RO
GlSXjOpWFTeaBA06/lVVL+tLZGvTglL5zEFSwlD+Y13Vq+3Qx4iAKOFmd8/u
Abr3tI7MJB5RZCaCwU/R0cLAlDnnhNU/btU4MS0bDZvWXG2qOmENeFPpP3zq
Oi2dgdirYQ+57rnTd8M3hKkJQUet1TDuPZQlnnfAtEEhDJ0Y1wY3ioQXM9GQ
5BZSQBK4MctMUSB6SD+tOLdZTAb2S/LfAh6OB8+z7SF89F3AMyVnnfp2hE4T
QwBmvoQifH2at2XrHar9bdmlQuC+GJfq9fw3Vhswh9856aBLQtxghx0MwxMc
JrLN7dYw1IRIkk+nW1MfI6Ubcvxud6lBTw85/cuzSANxd9BAMq+BDHxIgKUK
Z7JJCScVPuaT6pKsQy8DKNMtoFdh1G2gKZqtkZgQfAWZXUb2C2Uw+yXGsEeX
yIZ1CQcb9jFaRLZXi3AfqUVk+7QIt1+L0EnPvN5u9EJa1d00CSlGefLk/gO4
23ysrV5msrSlfQj6WwROGpOD4AscXJtf4ylzNonzXbCkT7JEiPnsyXYIbZlJ
dnPoqLjOA1o14it5Jm263pBB9oL7N7XRdGAywKqVRNgPRBaX3hXLmcOfkw1L
tWafaGKSY92JuVgmqQJnwA2RcY28i3PRPAZOwfX0Oa6WC+AYErwyO65ITeoL
sI7iHOl4QJ1J4hZqgLADBddsuwPCAtxfauwf9QaOdPzi1H+S+LbqLeGEy843
2mb/m5wjDYy8mtoTSrb+wOdYRmp/Rg0Im44zy7p+l2HJrzMySe+95vxLs3tK
YuEjTE5Ng/bTpiasZeQ4rk8kfGk8U6FQYI/XsIkU5HrI6GbliU6xXlsvCEa7
zosVaD1YM8BQL1J7GwQY7KF/hh7xT9ziF+FSBmQoWkfaSj8+rR2Ne5xKFcTC
d5Cyf727RayAPz1ZGbKsXecXneCEjqj+kCNKgt57T1qH3DM1g8KYvnzyACVA
2MLwBLUf8SViquVg7ix1uCyrd3EYrA0qrqSoZGS2+n5ggzMr0MMFA94LT4le
haSK2QPnZGuRgVJTm71r0EjpppFTkT0zoRQhElJwazlvnu5rBCAkQrq1qetd
fxtGcvv6ANJOWhXhuwgNZqpRBnZTGhv4Jub4BmZAIvbkaPdpCnPXGkww+aXR
2iKTQ2V1PPgKGX5T79RocDIHDDVraeBQqhLxUuJ+C7NvNyuON/hUYK1NxbMI
hTbU7p2pF+7rhm51SV3TsSlpNdvaOCNxkGCtCPgR/jpGsJc0sEgOFn9VjbIZ
3VUOc/Q7D5u2E4xvrw1Pxd2iN3mUnUpv++i+3yV+PSeJHpnFKA3IFUSN8ubI
ublU0/lYM8GnYvRG6pF8QJMLljSRy8f8C/oO9YTkFjnJC8JP7NJhAkA/1BFF
hzNKICrfl5dYUYJ/h2XclHPY6dxXzHISB2ltxhdtVE82bSfuVAKiJk3vCA5H
TgRP5zz2C5PPVC9Psg6C+4pycUOaWuFrWUINjaazbgY2BXVbStXcOQfQN5ga
DBtIJnTrl5HlwJeEfnZ9yqa97v1QmnogcQo0MrQCvgZK45s/tOq4NXQAhvPt
cS78vTqlkS5MEWMbALzpRvK3QHvlpG0sbyikhh1ngp2rvTVKUUO9XcG3zpPq
6pu8mbcewk+RFKP8QC7nFd4hYkdVDK1b37LXmHfywqvI7fGywzHDYtR0zPkP
ugau9+m6fkgULU+ml4sQkFE+a2MwR2i78DawAAlUEXUCU+l4jRdJkOcCzCxv
SzDfAvYdFjZpuh1KWhajzCfwc/F5xzfk5+wIUUzBjRk5zznyewxxbQTWrWrT
3xbnOpC4jmIV1dWgYk3c8z4asaGCC2UcF4IgCBu2xj7T3gsVKUWKS2CkkU+9
oj7rg5eNS/HMp7gWiA6Zah9M7hpxqq4eYlYYlcxRQyqWZJNpkrvXk/zsDHiz
r9TN12yBLgavsSLCl/uGPcfKevyy/KUN7Wtwfa9Ofzg5Pj1++vL5hWjOvjvl
ySl1HGyvYI9EOh8r5awECeDYIFoeB93xE6WfIKl7RBcktlQrRNJaqOwO0tXM
wChlvDMwQ6Yba4J6vzCV33n7WTp6xAxLsu/iSoWJ34eAAhJ0J3vre9zP9ACM
AsCeCViUfyMgWEqTq2GYpffdkHv5k1dFy1/KWyYO4/cjE8BvLesMDKNPoyGE
sNszTbVLP9g8+h/uwjQPUilFeuMHdJZeF4dfUXiAq/flUvwAJJbPhIoMkf9A
vp3QY4GuwTNyPYnjBwvXqEcba5xK73N95nbN9GnpH86XH58Paf0KSXidIX4q
aUQ7/7RuTIso1C0nWTasm0VzGtBYVps24M+YTyTjO/ddZUeiR+86HA7AJv9A
MoQqh/2EAkUdoTKAoTnIA7dNI17Jz5iItCzUWTA40CaeS0Q9iusfVasE5B60
6jiJZbp7jJGxdd3ej/G9ZzaQW7WVqrGibgxuzweFk2o1mVZbvK5j/+iLk1en
YBQuOgHt1fT3vEH25NO38IkxPWFkB/5IzXpo0P+kTHYMYhOGjS9sqHhRA+vx
tf7K8qh5asbpKsFlbEL46E+TsmZkmVRWNgp5e+FD4ugMkEWtuzjT/bngsu9W
tfSwm1gra7IZVB80SoecdV/ptZ0pHFXzgLFiJySGUgCNmmJwFtNTqCtsW/ew
FXAU9Ai4Ddc76kXDctWQN/YZxR4kq4WsBvIYYnRaXEBUIUjtXGHTMMaMESpm
49S7fsxZ2WkeLT/xFh54Sn+/Uy5tj6gwloKNZLlweUZJGWPpZRLfEGkYoF4a
EqOOX5C5oHNkXVRpmZiUo1mGqKnc/CFyXTv5KNXTwgYfrMVRgUMejqietPX8
Cwm3vcE2oll0MdzdJc0cjxZoPXQG0hWOxxKtcegXT5dGPiPbo7ZcwW3C/15u
o8a2vgIWXVe8mN4w2t7W7Rrkhmugk2VSZOayqhu9xla3cNZbKR3hTS+viXvr
HdfxHTFBC9C8yWsPBgVsHjzKwtknjgczZOQ8UpU4xVyxwBo+8ocl8QSjwO+o
3bQak3zaJc6es5PzU81rl+JgZ+6QSeNmUgPNnz/X1GyG5NX/83+LmkSg6gj/
ny/5llpwREVezAzAJAFnAO+YEqAfIiXyM1jHJM98ENgv/VMW/qSK8fnLs2xW
rmHq7QbuO/wu6HIUq1F3FMqUDhPptoyGNtL+egZ1oMWQkKSiUJUus9b5tspX
/Lt9Wqo6dndROuvPWSrQdclUhYmhFHwdadQAqJQNQo2QW5T14nJBnnAXV9cn
lSQmIj4EODDijJZdE3JsPRNYQFihwAKoCq2wAIcan/BlloFfIJ+YYqupWWdb
AknR9Xpd8BRj2KGOUPYKzoEcOHDRKzZwGlM4A7h/nOwyQPlnEUyOZjBh/lRN
xtjI0fhJATPFgAsfjR6Yw4hTqUlislWk4Hf0QYYhoHx8k95hVuBz4pPu7zIb
UyEkDvcL5uQneHykPFGOAEsK++PhxF62gc1jzAezOFHu5Ts+6mZv0qFqhL5t
mMAs9UrXfNGxhxC49XaE6xGXelvabGymTulBm8ZxdcAam6BRfTcBSIb0I+b9
rYDODCDcMuZM/w8HUWsRArCKJsUYPdoXQluuXyDCy+GFpgdc9Me9MJkTEiTy
8InDtfccTAKmD5dEgu6L5PqCDecLpxe2bZc/3PhMN62B2BhiUY2S85g2dUce
mGSnGtdJAI3ijZfjAiOHnAMwuWWB/TrbTQO/toV4o80t0kLz7NNsmVeXG1Sf
i+q6bOpK++CRY5tj/1/vYhOanhjtBXyC2gAI4ctNBioB+eFi+TEE5MYuS7aL
GR1nXRs3uaaQbig9stiq8sxCe+8sKdeJPikeRcmdwflhaGUWrjmza5BhHzlJ
x4kRpsjCB4dv2XIkWKuqC0clUB5Wc7FAMGajQoxmfyMKpFAv1X34qrjQNwaB
ssp2thEgKR9wfPgQS0ZWaDsbu9Rvq7Ihn9/g+dkghdtWiDhp1lqLTDVwtiMo
9bJeJFAUxGdUjxUul0d+UZPoOfR1zUahILWYLcWPV2B146DsmgX7aYPTw18m
LkE20UOg06WEIFw07HpReZA08z0B1WHkBE3JJcyQdiPKZddHZR5UuKaChesz
Dak1KyeuImxh3O3Pk1afi9jtn2QRhRFWJTpiqcjMtmSNGVaE2Ai007JKq1Ay
O5UCp9UXE2wjJ4Aj+5aNZJheNs/21JXPIW7hgHgJBtDFmH9TcprCWRCFU8bn
uF6EXMUx0AhjSUXqumgdg2sL99Ivoaw0G8NcMDx3zBqHhUi0liEffXc7cVNY
kJS9V47BlikGTBGC4NyO/B06FHCDwwFoRYnfYaNS0n3dDv1P8SbVsawqBGsf
c4nNjDjnkn6r6btgesP1msFdMmdctuaN/TaUDz9LFym6SPO5G9iZfNPVq2BI
JB+MpkNWHA3NefL2tDX/qv8FvoccIe7o5TAnJABQkDdo1ne0U/Owleje8Xni
tyhFGuYaVI52v/bGLm+3YkWhIzHMB7h48MvwMwa2X59Q38yLYe0kal8a3Wv1
bsltZB+48o9J5ODZNfYU1bbgcBtawGDiVloG4RPkJJV4mLf1p+65nW1H7tVj
9d5JYGoXb83uwlsDKlnJ2R+RrPEZPqOAI2MSvkzawsDQxHY2FetkMPRNkb+L
ngsYtsOESoCKuwhklH2fdcv2hwc/PBzJfzzK/maozxhPcJ2qOXX/RLJryb+c
Wl2jrGdzBRo8bpqcwtZGVVOEw4Hs9hwfd+5NRVn0jIvan43PNVUlM+2AJz45
Z9rVxhMg7FLWaMzvE4nNL8OXVjnh0/kMVq8kpP2w+72bmcw0JwHGUQXMP0o+
OMR5JyWEv8h2u9cN+O9iBLj+XuyrRomrQcXiQFePQzU56zdEliFV8/bXWN1J
rXZsYKi1tqu5lgRUvGZ+g1iDnkhX9XyD+3fw7dmrFqSaVwITF49PQ8H0vUI0
MVQSRI/aT+IDtLjamn8+pQV9D8S9Y4Ae5e4cwN+O07KqiDWnVGVqPOiRs3Ry
t9wKYBhldfvd+B9FUw9eDno/JE23Mg1t12xtJeurUccK+YpBYhLuuqcXbRvQ
HyToL0CgCIpdFd7jgzgz6JeQGdhPT9xu+h7Yjr3FVnsoY8cRjLJtvbE/nOBX
ovM1UmG8zLcGFd/nt0Wx63y5rgZO9oyqAeJzPFb1J3CPyIbc873s4Pjl6etD
7cngM4i90kdy0ubkJoPpdZMMPY+V1Beh9B6D3bx//w/42X/C8pZHVHXBV9M3
r5dzw4eyRVks55bpRGpjr2cGYfmI95He15C61REDcLazElwzLiShbSGGogeI
DZ6xPiLUbUJzXYGAvHf18J4lCoK9aUeJM51UEHTqE+pmvsRqi+5qFUlLjU7T
CNEAo/Dusb7KhNR6SuKCwNv1uDvQGZdtKDxgomMhH2i2666+bPL1VeTVc/4V
2EsTmdln+EiAlowbPQrs/EIz8NukxQnIrljXoQ3tOU2igqJ90iDZa5jX+uFn
nzcPdrN/expgfv1w/PzshwcPn/zwzcmrH86+PYa3d77bPzwQk7N5m//gv/sD
SDwawtORoojN8tmVr74w5LLKfzzBP83lQcI+N/9+KZEOTnW3uj4XG92VDBIE
UHKNbCrkBnZ+mFI30zCRBlmI7DVCVPzYYcRPWBE34eEkMsp0vVVHHVjvg91b
vm8rRtmjz+/ft3IaQ9mgmBTkFYww7c7o5z8VJjniTwWv0kfGDtRF4+/bYRLh
rkCgf+fZMCh7S2odYD5KmWfAbBtM3TdJ2NigA50amCY+yZ5zeZ0Wjy72DVL2
1TaqHdBpC2Dxdi0xOV+nxkDbZHI0lG0alRwEnoKow1LShApnkj1tubs2KEim
K6BwBcPtKxyFFKu7HqvwkfaGIeF8oWLy5lBMWOw4d7wLnFdAmaQA6AKP7EKb
YQc/7li2K7vJfUYhGQ7fVZSxQ0DSUswMT9HVuUX5MCQ24rjqavtCjsgaWiEC
FMMK+sivCQXN4fNyRQqZC+bkgSoDGoweWbPB+hzvOqeg7SR7g4QVwrMjZxxH
M2q13nJakuptt0WosiBM0OB3qN0vObAkqR3eYPLq/sSFePZ0WQeY70tOXO9B
AyUA5ewImKP3pLrcCGKkR2xnpiMxfzHa09Yg5Oqz9gdQnrxBwV1TLxty/mcU
j6QrGolhE8Mesm1EtZbaO8xleXf7vioLPXJuDDSN+XWgvobMMB0e2T0PKKVh
yTX9x5YpgVP04Ps8Cnm66Zbh1Q6z9vdJ2t3ABgOFxykVvVw+WhqNS0X6//vk
s/tfRtYQ9fVoZ005teGKzx4+uU/eW24FAfNTqhAvmf7z4L3Lsk8/zb4l0lLK
bgqQuJWpInMfdkkLGvwvZvv8yNFn5TqOM72faHgsl0V1Wezeb5MyEdoyMhIp
B7GVj+DzTio0guPRPCzQzdv+Icoenehs7rZPfvK7N0YX2hv5oPeL8qrAnmLy
xcyUiII/OMdZYjH4lHXGkQVhYZLJ0+uhKqZFjMgeM0YQK77ryFCo+yuGYrF4
pqbvptuh4/q7nofEVkp/Qdqnci9aUsyQkMBZoyWJNw2alIgujyaRnXJJWdXr
1OlUvbUQg/GKtfXNjCNgof4opIbRH+vqKyfZX9FTkvmlz5AkKzHVO68KLLnl
gseiGXf1GP+/vEzmlk3nkgE865+F0Gp0zdn+T7tTcM4TVwNlb9ZFdaRZipiE
qGVOH7TAjPOlSqnn9dnjOxHiGVs9LfVaU8Ulh9+m0kGDJCWDJ8PxJsxYa8Mm
WTINNX9YuKGAcXEKI4Wncq1cTt6OM5R35jP4mkrkzr3TlUwNM9vdHaoF5+wP
2kNHArYYMunRvCAoLGvWIG7y0sPzEuQ4bpFZz0TvN/JGSvkzGYrkwkEW0vAd
4oqKer1ZctrJYN8jdT6mpxfaJ3lkAcr38E5etp5IC8oTD7AOfSCugWCEGmNS
okshQBR6auUObUIKBcQDH0Z9q1jjVw7jQkndgmNscv0tKMP50M0VsdbGNC1t
mVh7M++g9j4tCiyZVlzL0NFEYtxxeyyKbSAEER0IPl5w/05Ox3GW+/hoaH8Y
YUVNwW4XlnCY3OPn5hT5J0IgTxdQasW6Uoznk2nLLdZIKOm+DiEBF97wnF68
XbM4hXMacp40E9h7hpjeXDBtzgP1Sq9ekys7LS7LkFvs4dYln8nUsUsmoDyJ
peAM4Nq/L1+ZMiAtfCDkPFak7zG8dBbwpe/5Wjd0yrobwZRI8TSlXZLp5uT1
UGogkgBlI7xCZXCyPQaSUCsnLNGQrCv7dLZQ8mUmwKsdOu0+Bxv/PsO88u3v
fh8Y1QX9Irn53MSw7Q+Kd8CuME8pwQL+1YQCTwlWREYbCt/upDtGXrBvuFiU
oxWM86RyA60i0BRQn5+PR08chhsxMk9VsWqWmFbY22VJVrVf92RoCyN9gSob
fsfZnH+QbT2usov+Qxe6uYIYpG10PArRDiXKu/sSK1IaRy02y0XJcL0JdDhL
3dI7tIV/+C8aFCGvMGEAOtGZslVR+L7vNlUJkeIwUIKoUo4Y14z6pvuUQmbl
MmraJPwr1e2bRA698FA/LqwSNAssTpiTPnXDvs49zEjvjD1bwd5PxZ5si+3F
2utdIH1iZrNi3SWJ+H1LrQyQe6h9k7E8UD0hV9mJOYOZsgJVKCpq0vJdxCZe
ROQjmO7YeQgyFgJMhYdRqk48DHdl5Ex6djyKG4Bz7C3sP+vjU20u5/1CIkEP
sNsc35IxDMpFLILz6rEoWPFkjRjUTlYIP3isgR1aJ6pEqjXai0pbmZLRyHHu
n4K8ECwaqojkldinNCaTcD9Da0y1fakxVN1CYTiyqOGk/7WnT/JfNC8l1fu0
pGRY6wtJS/O+JuHED7LHkFOtMFa/bKtBVMJcTwnLYiUs4exBE8uO06Nz3KXe
65QWCnEUZ4RQvMSSAiU+03Wkmr7zgaPYeQyq4Onzqt6pjuR+qXrnP8j1T4M6
3bxs19xpaJFR3Wui4km7SlXv/IgxCU3Ounqt9PLSm1vqUkJQ8K6kjiHZ5bKe
cjU3torO2qtNh9USN9WIQS71ORzR5V63EeiUgKqabmZC0yAewzmJxJ7/Lvxk
FY/+g4kWMuxs6+kiqPsvqWZFefmW949ZLqKVSm8Q4mOkeY3lFy9C0kaToEa6
PfKF6AL2xy/8IOZWY8SBqygVtdfrBdMzaiP/Y97rydGXV2pKcBocSL9JcMwh
YouOB9skxK47iicejkjlD7vVbw/AOj2r7ENoUgIrj55xUQDEMzF0yI4OmQMR
5JUD5cxkUbR1XUlzIKrdsy1irJyVxqg8Wu9iFB367PzHX2IJ3IFtdCvQ+MJI
ffUgFqSMqWCOa4A2qykSO6LEUi+sGKHIN+WJikqdoN+hmoUlGWvVKwdndSE1
gKFdraboac4LaC7STkOx4Ikk2O6YN7zpMEVUkjYNddGmGBfj9aZHipmmOlUn
om73XWRxI/AiSbIAhkga8eALV8UD4Ycb9OEDC8LWSwjA4DtBx4mlyd4ZTiQn
Q9ihOKwcCjqerspLHIkjQ9nTrYavBeTTz/ZFRYkTRWRr4iqovbskHmLKTefC
KuEnfS8TS9H6hy2r+7UtgdNhxd/mHYu+1hMqPWsAeUPwwLF/xCvTu3T1wFqG
tXbK/fBS+nAUpp6+f+u7Mh9nlPuYLd6iU4e1TbcCKTVwQijO1iCB9DzgDvIv
gwZvJOAoaMsPh4+Jfiv+W/z/MREcWXTF958EgLYPhBAc3MDWBbwnPtV3ZroB
J7FolrE2GR5TDeE4IRtx2mnKbh77n0nLIQ2H6jTx08khG/hmhZ9IRZR5xCSm
5OT99LQ32I561wVgYEWqHdilbI5M2G3Ip05JbmK8ePVx4DEtWa+HSNyZpUlD
7yEXt6/n2b0zI/EsEVeysQLq7baVULMt0Rwan2bnhjZ+R0+4yPHE0lCQKr1v
Kl4xqRSp/WXD3DhE5cqAhpAPbisx/WBt982spMiIQjxkG3vBA8xgqsiyIGa0
Iw8xR6xDGkIYD341Rg5ASJ0rXxmmKRZ4ExhUXirJda8JzycOFR28OHl+qGVh
jx8zIoToFaGIhZsTtAFSn/rhgoKEXrTXx+cBuyUhMI/Qh63sYV0k47EiDf1l
uA54OZuW5Pc0NYSa8gT7imYwEMV3HW6Pdp7Htw7Ozr97Hab+5EvunuRf4QbA
2NYTU+LyhjQfeNEdnH/3Nrz4OSJwCwyE3DXi5P6o62pYWqFSqdE7XREvQNcj
LO37v9GmBBny/d+YAj0Z96xomcPBYeTjlHlRfayahni/SaKmdM4ouTGhO+n/
pG2hxRs2Q2g3i+21VKeXam9NQS1SrrkZh6SNxhdDo5LxPtE9YR60K4LWjtij
U0u2hi/hCUGWwDdiON84bVR8kOlG8E6x7AmbyJXYGBzQttJOlP+MQWikOpGw
/8ldoChOgoYQUDy5iTQjojOyeM9iLi2PYU1OZhv8l71xNcvG9fpXAI+dcWZu
CIAjlETFmoc0KdNMe0V5pgodblcewR0L12jj80zY9Q5Z70IVeVtIKhrcMdGK
/ZoHKCMK5Inf3KGnPRHQEUySZRf+0m0Jxz70FfWH7HpfZT6F9phJB2EYtnaA
eGIJxNnEuH4023KB5lja7LKRlAlTAgyl0+cNHzNCGT2P+KwrfpSDFVvz7MWp
PPDo4ecPmJv9tZi+PT/RbgGPv3iCKENEPzQRv+iRE1OSkWrN1PAbVbGM0mD2
iVFDm3sUoZzPtLIAHnB9BjxNg3rd8XzOgx+kvDDmeHu1npGAbRDt3lkKc1Au
Qrjj7ocjxr1N1XZQoR3jE6gKuYdIblchHRxDUxbWJxJois6vd3SDDjzMjsBS
yA01cgGTabRTU9wTKGZKtur4M7iCv/u9WBZDZ8cBuOjxYdfYjjETx1hs1FuX
mKrW/XzSr4fdVAbITYxo+ykcaY8zLP74V9mAW8oMj96RZPDEBWY7TO/Sn9m3
+nG+qB27qp4o9ws9UZl4ok7Ed7zK5wX7K2IikOCqpbbEB022l9vhYSYQ9kQN
mPxSV4NmrrnTn+lqCJYuRgPv4mvYERdMfQrBpOk/nPUDhKNd0UHX00CT6OAQ
lUUeCXeLR8JsgXdJ7OICt3qOyM9giJoLYrL3n4iDOorxyR81bCcZGCYp7WRJ
qdh7MptMAgk9fLBAOmj+MDIXPdCMZjqdaHBKPpCGoLdYopRwT+5oLTeUZnhT
W1o+Yr6eY8GmnaQqz/5j2Do+pOTMKZSs7EACAjYtBhlr3xUawcDpSKpGSxsa
wcpMUyXI5h+8c8oIBnan2sq9aos4ojXHfepl86jqlO7fJO1zPrDFVCOA+rfd
RXPvQYcqwEa4wAM+bUqsqdleRP2N1/Ir9qtyIp+jeUdshFBuuhyjxPOjjLhg
Ka2OpJx2+EU62zipJs3y4RW52PvsY3RXQ1Pa+ibTtKdtkl89k+k5Wv45Z+vx
6p2sPnQvHZ7iwJaz8WVn6QjE2yuXorVq+OjWaafHPEgL7iU2rw3vWIy15HRJ
Nq5LztHs+jeCeN0spluBgZHm3LO8xZIk6ozRROspXPKx/q75ElZ5r/QpcTtX
S9vWXzJdZ40e8ypTJnVhki8lpEIJu3Dogx5Hrc6lbmv46WkB4resG5WEpiRG
wod1GhQM7FeDuae9kh/7ydr3cQ4oQTz0i2fsriFURPj/f/7uxQksW3UkMwhZ
HAk5coQD5NWWoaS1r2uUJ3icnr5KDrT2hWd5oO7cq2dfk2TAuihQt4u5V3/0
NNwFyw67/7KDsSCS/tSkW+mDZYBoWWr+qGPQXxgjnsJQSX2qByKtKxPtCYVB
cifNEq3d/vPuinPQxVDcPav0npJ+IIB1V8WWSjx5dA9k1Ib3fS8bTozArnrk
XMH2iGZQrDbCwqgXnY9peUcLde4Ey0w+au8VJoj7grNd18uLLvp3MTcDiJT3
9GpeDtaSemiAJ5lXnb3Tl3KR2c23UxvpT0A9ewOBxN7K6CNaXW/1NwQGKdnH
Ljq3Hr/PTrLj26ottmj7X0F4WV+EYvJOnBgz7UB4XfJL/xXzeKJUBfZ75Eu2
ScQXnYTwPeRhaHzm/c+D5XvqCUrG8S1KsLw2Xwa4drCJFptqxte65BYjvior
3JcXshAWDbcrJghcoTGGH2krLwk+ZIStYD3ScqvwociUfCML4mYlYWDbJLDp
RnoImlYAoLSh1w11N3LoVwW3f4ucn8nlF7hb7TYAFjKMNL4hGDdyLtB2+TQd
yh2jczN5HtZlFvk3k3NJ+zZQCbfOQ5tsO+asEsU1fUDIWx4+1VK5922oUUXV
CrYnt+acoTa6Qy2j6vMS3bmY8I+ixB8Ng7LYtcziS57L7c6eE5R3JcEJoZAQ
aWJ+ZaMT+e4luIj6RDctfxL4Z7bzB6jt/fvzk9PxyZvvTl++eP3Nhw8+ePHl
l9w+lH3lJIyJJ/dLqQJB5HJArOgPZliHv6fJANG7gaVwvjLpUyN1DhgTJ7ip
PK+SK6faGHpU2PE+0JBPPfwp12l9aVc0K5K/VJ2CIt4FH+x2wAZJKhalrwev
x1vxA57F0Nh5U2kaRjhZNSI4xpYPKslk+5EOKXnPHuPHnsYOhVllbqljSMK+
uBKiDc9ZD1F1+W67eKhB5VgfHloIp/+yFXQr53SmGxbKHR/FzFuu+Fy1l8Zo
OxJJtEQ7lgOyPmKibXUD5AChKt06hZEsOZkuXj9H8BhinCEUFloiPBfFP9B8
H3958fgo9jc0KO0wKp/RyJL8kwwNBrGuRD8iNfK8sAGLezarG2knymUCeFpn
iHiwWRZR2ykxCFv9GyU6n0ljZ57GuARRkWPmILf5rZtCi/Dmvv0IepdIwJmQ
erLJ7z8B9WLso8cfnLFVkhZRgnipGCy+nUyW3+TCX20n99QsrVBlNbG/XmRf
WQeDT5mmAZK7EQLX2iLNxdF3rMzLLrC2gF2ixuOaVCqztwFb4fCFxKiyHKNj
3MhOi4H1e2r+Uw94ba5JEdgrragaaLxm9ivAN9ZJbSOs27EyNpR6mna5V+hg
TtxPYSE1fTW4MWMO6zEQOQkQ8wBN3wZhYLgwAqooBNWuiPyZ2g3gHK7IO5iQ
iZY9efSEhBxxIx858uENWyfMKJK27mtoC1qXbFdPBt4eoEpIjL1UrOgyLE2f
2RJeADdGQKISmGtnl7Ty/QCGpm3Oqzc6q4/aVyL5Mg+rLVaJvsOgRKOs46kj
YxCxR2/uxPeJR6glCUoATyj2n0tH9Y+JWxBz0+Tg7ZmlC++fj/3iriPynAo3
mg+ln/mjrgFStiU+sQhVrLgbJuhGkdfwWKNfII2F7ZvkE1iQyJvbur767Hf3
qMf6TFci31pejt61wLrQDK/F3qLXykUoocF0omV/HznuotU5NpogHcxx2QPn
CxRKcYwL4pZy3PqLsS7ja+i4kgSf7SVldPWn5E+wBEGyJnuFTL2PGFCiS4sS
kOAHkCjPuBqkXwlCXnRSQBMskAME9zlMDeK4YwW+/G8bENM+9GAcJ9YlSV9p
t9XsqqkrjJbYpBFfOmmaCFEeCUmqjsAke85k9ED1+wzFdVDGsukl8SSQ2vYz
votAkm2ItImIDWlZl9brD39ZUp9IpBFsvZpV2Me2mS8VmKXHOEYeEWeh74GQ
EW6WO6nNSoCtKe1f/tRZj2dkdn7Dkxk+LcEbWGgZGItqCR6jgtSG3qpur6sz
GcgWkBJUxC7QtZt8SwnwWCneMYsTNB7SHr1zY1EQOJjvzNFS9+26BuYww17Q
y5LgnqbbtHEQn9DuiVMmP8gewqsgDFHpEU2Ba0ztCtmHUaeyxADHdsbUTzkg
3zsDaso48IYSuVUP45MyWJNqNG+fn7x59er562fPn7Gy0j/CdOc9Eojtf8w6
hnhM+niqmpIBH+hv0O5PhVo8auETHIVRaco6fskraaKrJG3suJRCGMx2x8dJ
lY59pG6at2U72fFC1PaAOnLR3H29dSf4Qa7PKX3V+TK+CzFeQWLPeKwtg/hx
VnRqCybxWeJlJ/W8SByi5o2D0Pg4KW1BxC3q/Ia5GRUwVXSA8c3TDpi5MXAW
1pAf8JZi2k2rjYsJW31sj1VM2aqvR6s/f6PtXg/7BbOKBO0b2CnDx7nTIjTC
cOH35CJ7I8V8Z3i9pdebL8wL2cWRzkS5ftLmDtmDcQP2o5W7qewuoUAnUOqY
buhjXbtDe/RJmAe5zbgWTetlQk0aOatCQcoASFRe7bshvWp2s6zE6e5pDP52
cCglPdEzZthvCIKNqeDQlYvhp77N24MpN9P9oW5+CH2Qf/DvclrcZDJhOn6W
Ok9RMG8GoMt4J1T5GBZkdB4KmRiYndE94N79t7TnJqkCvmWUoPgHEvE55Ucu
izCbRuFfGOM5WVLvE5Li+N9Yq2ji7PQVrp7+b+gGHrJDEh2RUhIIwSIaCH3e
+CsNloGllIwgLi4cBf5sO7CWPaInH5tEBH3uTr9HNoxz4ftvXvgmkZvBtqYX
uAPU2lGCZvB2gOC4+Bpu5lLcnpRjQWm7caScgavpZrHDa4Ev0e246+ZpE9be
/skf9m0h7yD8wYvU0CHyN95DPKq7b6Cm0PF+GaAM3rCx9ASl3ptI9UvqkgjD
YfIfysGo8mjGuIcDqqlvfgdPYdMN+PRVvlyMZ0TnMJ6xAfGI4gxEI4VvuTF4
xYZZ8sGQVnqodkKGYnWTL1P32Q0pJ9ojjNJ+KIpmE2T9ScEoqeKQMt+AdFMP
VD0gKfXOveQ+WYR4eRH6d154Fya31aGjFdapjZ0y9TORN06oHvZKG4+Gfg9r
7gnvO3PKgv1B4sziYgC7D2lFv0/5FxRyTC/KzENDS7zTdtEoxc+glaM9Qa+k
Vw58I3TLESjs2PiE3W8qdV5k5Bw40D5lO9qtn2vcg+pYm5C1ykUJp395Zr8x
wvta5BiGWxGMzeCoRPasJWhJL7wXhVuiQJlYGKJwGaM86jhN1hLq2emkYGzJ
kv8MK3q0NyJlFMg2SbwgsVHs5mkRizQekq3jgsn9Bsr7T3rX193BpgnWJDuJ
SGAs7BziTdUMNkG+DQ4GypeJEhUw0SYJeZmPSz7MrG64yRnJzz5TZ9OpoAhX
v+GKouR23F7TX3610oRV8f6zvm6bIPuzF7tXexG/1a6Or8qqXG1WsISm2ax1
Yp3M8QQlKwYAFpRVqwKMTwLF4PWYM/s3K9OaGH8/kZ9fFlUPDTs7qOAEq+KS
moUhLhBIpA1tLX/uIoJ07v3NpwOZdrhY/cGjk/kbUPTwnFeyyFCmP91iMK1k
YCEWgD5niu6HdsQk5xXXnBMaqC4X4Y2DRPeFhL7pEmzYTd7MAySZj1Jl5L6Z
yXI0YmiR8LPUtKVM97hPHkH7onlIMCTh8Ewie8XXpGNGriFa/IuuNO5SfRxj
KePD9wl4WhlqSLdfwz0B5UNcmsgAhNixjN/vEbce8CmhvVae6cnyx5yXAwjw
1ITZ2lKssK74VLLjtPOZ0+JoUeo87HTy7V8LfzoBkPbxR7kzPuwarouN/t52
V6KL8eD+/bRtU0nZQ+YNP473ZqrY0pkwUUS6s2uKJb+NySv7Ui576eUYdukH
eBXrYYHMrw3QDDoHKi/DqFlVi+/fJU4RvFM+y8BOVb9Kj6j3UU3hUZ9RUEsK
zT/mWKFNPbMpd+WkmIQUYJG/uml3tO93prLu39eBXLvXdXa5yYGhd0UhWC2m
vZekoLKDOKl08ZPGxV3CsVZfuT0JNAqzSHG0eAPVSNgTzjYdgvAqSMo0/flY
Qz5RIJuuhSZRx7dCXg6X4jVTVnaATUKD8NDOb4ncMD8PiQwZLJEXu1BXEeed
0wAYGDJLCr9rrmPDNj0+Bu2r8smvPCUoFEIwEaTlwWISoOU5Jvrxt2xze4Yt
pDxd9BBLkMyHu6O8Y0I60EQ+/jy5n00yrW6FZqsG9iyOnLCBtEdGFGDdjBws
sldJeKCY6zAcmksw//3IvyrftcT2rijWIJrwiFhaoQKJP47pxwGKwz8e499+
PbLb3QIh97DG7GFlBTSuxFWfy8BSwJYNayEXxN0pnDSi/EfSiBBWvLsiEUAo
QMDGEK7cEPUBsrkF1Tehc8tWTDmdDcN/YGEaCpjDYD2ZC0R+7KSsk9N58iws
RTWLv9vVsHscTQEY2Debcs7NP4I73CAHLaK0/nFSwIiVgr7bQmgL7HUtHuOS
nD5oEeW9JDS9YQcDhSbNDoUq3CvOOeB/ikkvTtLF0GL/k29uLx3z3KJP+mwr
FRchxSoWGP7BcHefh25M0TX9a4HKK+zc1zkYVn/eFBvCyRI335lM5tHkc9ww
OrqHn9+HvU81rnCvpCWmn6sClPdT5lhJdwNZqB2VY6CYFC0hmJ8hBc9kpNkR
NFuuaBXtWNUgMur7xVp46Nr1WWdNdDvQIIJXr6elUwFTcYGYNO8/wf0YwxTR
4sCfkoPRN+SF249H/tN/4eApssrniwUi0e0+A9wymD2ZtuqLCJnh5Hto8gV3
2fY4yVHFphor8Ny8qBeLfq4sfblY5+I4oWhtyZ4MClGHRHpv6xv/CvcYlin6
qUlaN2dxyebKTpIBUwikmVhm4ryG6/csQJrtS+uWZsvSAoES8ZyNJdsebpSw
DsxGOhv7nQBG3t0gk58j3suI/x820GbkYG5AVfj+3D4XapCIfcvtoSUHrx/3
hukk5w12i8L5bl93zfOhAV8d/7MvzKCohgQp0SeOODI6E0rh7yOUtpFTBWYz
cW8xvw++PxdfjaT3sfv+2Rl6uBvToDR00KSmNTIvgzXuBqv1Tf0DH/ElyCTQ
5qpCUnmVUXk29cXnn32BNx5TRnpQ4aa/GPxnOQ/euGTDjpzLMn8ds+yo55OQ
lZHJ1odzKSkTSrJKdXD0lPLwk92kyhomhSvWNLXQjqV3qgSHgaF8k2ZFW++L
MNCdzqTPdWg0Ij2iDOZrdtSQW4s43cPHXzyGDTyFG/Ztvc6esmm1AUv89Nun
6KiEIWeg8GBi5vDWiJVZBngosm95P1oNy2HEgWvboziTNtFGv86mucTii+A8
jsBPRiZWBYPJ3U4Jl5uR6YRjVOeZVDHKPJDD0C7BaHLxF9JpKWdDflwQA9ak
lf8Cx/iSnaPACY2A8I7qJ58/fIhn+e1TOreXcAVf5lTQ8qkB79p5iuYEBdaG
/K8tbEbb8q4vebgJqKrkoGP4fp3ttPCsdJ6pVwvIoGLemHBQpojsriyUGEZr
Q99JANSEHDQQqd1Ffa6R1RBndQ5K7KxXQrRCt7d3ZMKm8MIbpCdvkLzOL5fF
P7ahj+ThV9JZe4G6kPZsAO0F80RBgbxkkdzUKyE3SlsOnlRaXQq2PZTY+RVn
44HUovDZLST56xCkv6aeQZNzP6LRnN85bluKsRhGc3D89eMHI/g/D/H/PML/
81jR0h5+9uUXQrLZiwoIBNvSh6sosRubsY8yHPv2is1kwjqqAcl1JdTakDoJ
G7EOFYo01+cw7JygKnps8dHDx58zYJJ0DHvy+Wc8z7Z3t16DQL71fiV3SW+S
lJFjEK7HRH/2HYPB/C37le+YN4azHdHEj6I6FJG/Dt1hTsIg5T1EynuIlPcQ
Ke/hEOU5DqJTfHf8FqnmTKtAhw8zkW2fRiIN/WUc4KcBmQw5gdhoO0krw2fE
G/GsEi4pq4UBpxLZ2XHydzxj4hlXolFGcWib3k+RDtuD+5QSwm1pmi/AtkZI
Q8XXmB9iKj+1cBuugBaYpcSQt3JBGg7qzcpmtimRyqZwEO+KJjgUUFshEU2g
1Pk8X5NjcoalI21n5PySsOb/pyPYR0iwj5BgHyHBPtpJsDK/8VlRvPvZlMoR
ffWPMami+swyqGQo0/7GSneaTCMnFPogxQW2p2RQTuRat6pM/Y3Hq/MrSaie
HrVXRj3AjX+AG/8AN/7BwMbz+owd8njyRC2Rx599+dhXFfVWwFW8Ps8kzR/J
qdPDqp775I8ck7vHGgykjF2DXRT5i9RpkKBgbClj0nEXKO+oUKfGKSExiR2H
w77y5SLnwav3/hNfRTJm7Cbj6fB/4rFu93Jgd0gknP0ODc4QWYf5aYtG4g1M
uJyd7XU2LrVTg91HlTAb8KpGOFPgYgPr87ga7G9QX596xcLS4WDI7Qy7JlAS
wbQE21HXhWtMUiXZN6xoIwaBFFgs3TbvZQiZ5rQY78wF9fISU9OkJoc0CMJZ
4pI7ZMncSop9Ad1VU7RXNQJMeSzZYrakcjIeQp+P281G+Uczqh80Gs3HrKsK
vhRRcgSoNcAHq363puy6ivN9mKTZ77znlGVj2EUyLaoCxV6+ZCirS9DpSZvn
Weh10XloBtk0X6KnG8ToZY55XaJJMmIneSw8HBV9FOVzknWrTyMDZWNRP4Jv
SEcpdjPiWyxRZ1c1lsopmJ7EhaM3iWPS5mjGvYabGC6AHWrcpI2Yht837Ohd
pbtFnroG6+MJwQKWhlCRauAGew43L4DthHl7+ybb44Ry7vjyEmOx3W5SiakE
l79/piSSkI6GXMJom/JN3JIkotrTyLFDfRFyk0ZeUGrgdTnfyFVqJfGE0yCx
p05XXG77y7R3wmYEMgHmwq64LiX7//6P/3MoksMdBPnwc3vVFaEfOfJTxJMm
19zZ/9/ely3HkR1ZvsdXhIEPBagys7hU9UikumQsLiW2uGAIUGqbhx4EMiOB
MCYyoIxMkCiKZv0b83vzJXP9+HL93ohMgLV062HKTCYCiIi7+/Xl+HFkTioE
KXyNsmKi2G2W9AD01G/op/DYlf5UffR/qz7q326M7r1bYsoo0vHNf90zaSgx
efeWP4V5kUZEJMeT68igsIRIcgomdjhxXLVk5RKS9ZIx0EQ0OYlXl/BR+zV4
O+blnJybzps0oCOxFqXAD5AZHIzU81SJxOBeOHVNWETlYqAPGD1SotUZzGJW
1xdFE8uthHM13yw03Q7fcU5QgVia9eA/iZYZBBI+zxiOFowy7DI9r6uZ6H30
T653Hr3o3t2yVeXjE+c6FOGu4fSfkrZ5CdqD0LIAqYLiRsVzBQdlA4D62S7r
MT/LFjJumPB1qvSCaJwsO5sU/miEPfLveXtFDPiPIsHqRSuF5txKmN5iJVUY
WTliBDDDSKgaOTdhzAv1kpP8ltdF9FFz45IH3Atwul2vGfQRk8Dbp3FFJCY7
QvBpXDP58K8X2OSwnhP+KOYTZRdCdPRn+f2thdI2QXEz1kUOpCTBGySyB6C2
EtdcQI1ddUxTTqOnrOiLmt4eSLX5qlNqnyPlZ2q3FTYiSiLS4uiHvFMn8eGs
4pAvqwQqGXYcTbUaXCRjYdqtfrZWzgqXIZ2ew0DZWg5rV6/VYJTCWpPy1tH1
32gXvujaBbw4UvTh052GfxPEBX7z2Tak/EGejBvyB04sSLfdPMgWQuT+jd1k
nI6yXm246rTfg5JXJbXFU34zteMqms71ekGFXUnhSuJK+1q4QnocJBx7noHC
aN+HW+0AXhM1SLBdlb9tOD2AHYw7QHfl4+W15HlHfhEI9abz0McIP4mEMthT
t4b3MR9UUjeMQS2kGHbVVa355swRGFG+faCgMoRY5lFHweoqR9494Rp/4CFM
rh1vzN+fPKAN/WL8dNLU6znAfuNqNT2H2Zxpf3YJG04RFCZ19Z6McBRHiwkO
odkidzzFrJHIxFAywZJsSyDwp1wyDGX8yrfHxwVpGhfQKCZl1ifbgHzQZvUZ
RbMT2ATXLhRePAbHa47vtkQEywIeC6aivfycx1rPbsxMsK+IlrEmEp3IVa3E
Vb1cdO5mAprhvaHoGOQJZsiYdaLzJg6JDEIsFGGRTyEIVyjnCeGBd4IPOQEc
5XGYjSAPTlwyDv0oqVvIVDvh3K2TRz0YaZocrYmWklZNP4zb1Qx1brAjZWIq
MRmeklmos2JJj25mKlgOA1IunRO5CjV1dI1dvVpuI4PZloSZdFBtGd/HJLEw
6aY8/Rv31DtDrbOvxBeq3rQjMkKl7OzzVXXmmCRWYdrdzzKqoGiOKQMz7Ot5
eN4NjDbAJmgH3nv3qjsLLd42b+Q1VVw2mouTbDqQpR7/PIoo+BQGqUPr2E9j
yk8BlJB6UpslnQQ62xJYE+tknkyClcqhUOVEaFejgMWNnSeiSI3LhQWzKcr/
902lhSmKwTUQwxhtcApgBw90NavsMA4UIigS7I1++ZCBl/jw/qvDowNnm1iK
QLLNejVz9rlYCO+oy5lelrTBg9QNTbw8fHX87qmRThGz4oHcV9yOK2nJviVG
a5Kr5KptqOwjVeCELtqf8iJdFVx87iGxxWIYhh8TdCp8Eeodu/DbQU1UxKuI
QCZ0LS2aEFMsCxLU0akjhPBJYhHVsW5bDp9/gWKY7fNfRzvUSrh3Dya7zro6
YLLjjFre7iyHH299dnOxdetzmbGyMOmHnIH8nKVKOU4aQR5ddlNmQlqSu+Sb
yLV20+SoJM/mh9Lgsqy4/5b5EaH+60yRy2IfmKSU8iOqOw/Ld11oQvH5bzhX
bf/d8ZuDMGvr6eV4s25Zgxr2UyX5pJ3B1iiRfOuXoya8hYpkZCfSyGiUehpU
evgrNaGBhXXMGe0nuMM7w+4moR+e42XvP2UFe7dLaIBFhynTO59wexoTW+eW
BDyQdT/RSUVsg3ktZiUYd8KojP9E0kODdNuckeOuUPC5XB9k9J9weZuYRoiY
AggH1ikdlXIaFSLp/3D/Aaga0SwuEm2Pi3OEE9CuOIrflXuRS3pPltBlnghK
cjvStZ0DVeJb2cp5TG4gZL+0cn+WGplHNbeh1Mw3NNEfGuEnzj3jMGCKYHGy
rUKuOlk6uX3ct4wuBIsalyIh1GmRUETxhMVCp539oBkzktU4EJEuxYgc0bse
pZPkwDxbCpqfaCHYcgfNIaKA0Un8eHZFjZHekLwOQfEoq/qgJ1PKLXtf7Ayn
MjvkkheI92hJglVaLzsXacjt0gcaYv7u29/ftwDulj5GCRzkzCT0YSV/+Cv1
fUAQm8ct8XVkgxIBDb0nlr2OPVAuop0SSqFUGMW2AqyRVIZ2iNS2JpAHwAhE
uXji856qfpJdWq3FpZF4F9HQrtg6dfb3W3mHMgtF3Y/eJME0Hb+Rbcx0VBx6
xpgygsim83wVKBqnVzcTIsodlaWFMb0sfXbrwPwjO8eGo3LrofWrx/RXo1Cu
RDb7o5Ze+ZnpVzxb8X4hCS1zoxwgem3JQkB2DhSyGdgY4j2a9OpLvWzm9fR6
GiTKMzhhjSUSQeXwRxyILEeX/qhMw851m5GAR9yiLBsxNZbPmLLr050u/DRm
Aq+gKDxOiSEdcWWvyMUo8oLl3I8yX/h3sY0aPfpBMPeXaw1wrTEUrTz56lBY
yNR4ABIo4it7wNzoMzwnIOZSgWVbqf9j0loF5nEIdZojnpVHkdFYw3LZ57LU
t2YtHPsFcw1Hr51EAOPHY8gG8CIsUZ/S3qZX66gzriayMFsSvKNwljPExbLC
rRNhL34R+NqXGqaeWotD5W6QycY7j/zvk1IL7mHPFThYwnoJFEiseReMVKsa
5Wj68EAWo1fSxIKLnuqvuPYHoP3EzSq5G6IncXw8Vn6WpkDmUoHYASa1FfsT
B+WWSfe82Tzrd9ildKzx2093yJ2j4VwidqU/N8KdFQUmq1+K81b1REzy3IcA
3LFSfbPiguhbtWos5MyojNPa4iYEWZLjHfHk1AEtafPpTjCcQg+fEeJEjRua
CBIVquHo78WBnXW0Yh71fgGkoBMR9wtUoCNQZIkwcgfVpdTrB5StG/KFKmxX
8M7lx9ssMYgVX6LHudeg2MyYg3lGHfFvWvYHhiBj9REQH5QThp4YuZYlXDG8
ac19FaicrYuyv2QzKPM+nq4/hrl/Z24QeUyeknqmw3SCSryppVfdRKWcIyMx
QobXyIBm/JdI0kXfpnJRQA7Zp+Vp+cOY/iAeJaNCrYZHYfOYVOuUfSHs2uKU
88WtgYTSp5inWfjqdDtITb+hAlyOMLRPgux3gnRVCD7T/k/C5ujzeSrA8a9K
wJi9dJZQL2oB2a6HkHTd1PCF09NdWtyQkR9GTTHTtOmsOHhy8IwddTkb8690
qeO8po+qf9ye3kVu2c9Ko2etqmiuaMt09+vGZ3P5Y71On9k/KJLq88PvJI9o
bSp/GKMMlP1Mas6CPM9n58z2n3BDeekr2GNN9+AdRdfWmC+OIgr1TFDTPNCx
GTipYlfO16iTui6Mlta1POt7VS37NVgn9WKeVn8p/nx8fJiOg32k8RIq8Yiy
DurQyDMlUfhYQmkEjHSzMlaO/i2UfgwHfkXXtWnPsY4WO7/iybUybcAtsejO
FYyvulxHg/glv0yBMvUt0epWl90GDgGaieWUuHrDbmSwSlyZCtjcD4JP1XeK
8E74sQUFHb+CtaIsLHt50q8th07LwAs3J0qfVJOPRolKJPyeYBRF2EOVhOHA
D7mFcGQHsSwF5T2g3F8SZJgHkVoIut1Km1pcMUsrFQBVfYVKvbwDghEl93xk
1FHOueyeu9bRxaxk0vOmtW+7q4vYEu+i3odkutQdNWLp34OIxXxvUlSMbU5s
cznL5IZTjGu6Vn0JhhqvbOfTV9KiwLwuuOKEzzart2jJJajayuHyBWd1i/Rt
V1G+shrsTTUu7xHVmQuieJyS9rQ0xYQ1IkEvS6pBIRouFW4j/FldrWY0AQPh
4se+r8EoWUXPO+3tQhh38nlhthDe/cKrKxqBrYCsZAdOlbASHwuhSuvOKUtf
bhHyufzhwf0/CGsRxVFYPoEJgUuQ5Z8+YOVb/qN0kxcCZtk/KEvER/APmVj8
G0HtIOpL/PeP0v6L//wP98tdz/0jee7rcfjvamz/xX9+nf/y68K/y/+55c7+
02+7z8R//kf+y69v32P/K/dx/dzgc/g/u4z8H37e937DGeX9TBSg//Qz+oMT
4P+MM5rU3PU3a/7t2/33tT+1nx6Wd+bN2ZgLz44luNysF/W/7uW+lnNG8eTi
eu+zhz2FG2mRS2CYoAKV7cRDztfs5aKaMm/9VV3krE+tBhZKd8HxLT1wMY0M
LFR4Wgu2H2cScB+X0R015vs4xoW4NiDZAFwPq8AHqesK/Y6GZ2ss86q+rLxe
w8BkEuaXLTnFGq6Gzn4mZIjDbFPPSR/erYe8gFbj0hKiWqljkoAW4gRJOcBe
4eEpWJBX1/3immnQ5lFx5nie7G/eQM3M+TnDjEGNkyLj6G2NR1hJt/wrodtU
J8cj/TCkrP+poWrVZH0Rp0Q1QMmt1QaVSqjm02CBGFIVdR2yUVkLVfrdR0U/
uqOvSllCBhroldkxNbFC2sqFuuy4hdDFrpg3q06CefraFpUYb/PxCao7As9O
D+4xnOhNDiWqQprglK2AbHr7AxUDkIUDGXGv6w/0prwoMp6Mbc8/HRZZ/sIv
imV3BI0zX3pyN7DnPtXqQme0DHCZcFmPos7Vzgv9zAXVARavsShLUG0vBdLH
EoXRlLEoKVRuIhzir+WFobBln8tivCIfiyDTEveKYX2Xfm93o8w4raAsyrjN
WVA4ZwLmP/PN7DNTP/mhPh9EIvyT8CkrBk56NIOBltxVihuEltdi3BolXPhz
aCaSBLBCWFsJcPz9kuK8SqqszKiyA/IySSv9vtq38Qn4iY01q4Bo0I6M0ZAk
wiKYTQ7fprvw3sGM2EXYiWBZA7jjmPy1/u3Lv5YsojnRLw4nPCw4TDqzYauE
7WbEQ8Fw//sm35jiWL5IV4NPQLpEYfunT8EfNRdL5n0dXVJub0E5ltdoT43K
9BtyZLCxMvyKq4md7RWuspv6iVDi1grmLtr2Pc9kzaUQ5CqumE8LxME9d++O
CYEXzQ31gNzv+Cb3P+FdbxAWGhI8Elvj3SoLJRgAYwonUY53OclIq/Odr9eX
z28ST1QX5WevZGxhVO5x5sde+Bf9/Zvz9cVi78BFdgach5/upK7bonjs5QJR
OAtxHWDOGjpwLNlBCYFLCKc0NLuqEgr6/fycaHoZuU5mGtiwDFHHZr/LWZXx
e3la4wOxqLkiDGc5OseiyNXMdbvLr8weMQbsbLoYLOmFNcQVrgJx2KkMkrGY
F88ZV/QLaTPsQ4LsNDFuwhzHiP3sayo8P8GUgEQbibjNoiX+qDxLxoJmWlgE
6Q59zFYTsU55uCGrCE3ZelpYuQCbXgcKj3Ub60ae1mfNUoubR1FYf7xsyMvP
dd0XoIrjLHd6LDK6ByGwjkln5J9/vC0u0ILDo4teUcWaxT3a6nfKSN41S0UG
rs5w7PbO69CtvZ9/IClzI3SFzuPPFqx0PXS4q1a4MpBYhe2hsTMzOcCeSrpE
2rcREBl/3zShDyiI2GKHs4GkMJ9sQo3ITAsbXw8IjImWIUuCvRXXr4Trb0Uu
voGNL/wRmfyON8CUfXrk3Lm4XOcD0uVGRiXZPCjQypQturEPE2WFjTSpJvaC
G1nTjbWqFbmFzJ7BdgpfQskMIdtRpungC5d+dvqBGaenD49J8pDMhzbVG5Mv
Ht+XSfmG1NTelyz2HI3KKpViIzMJmaNDJLzm3A33TNJouVZA2A9a5lXsC2mA
/JWTgSUvkrytG6dBZiCG13Qe/FoA11A3NJCC937cUrqvBQy7ygqZmoM7lvRI
VHff837yoSJP+0mIdTIPgmGFr3HR/CRQdqV7b6LD+TLa0bG0iJbc9Oal31FK
BRauN0ptJgtkHfvhQ39CepSSCyZVjNPxAbOBsDwzzlvzgjvI4kJVjwCGTByX
BabOfs32URfwSbgf39DvKPXVgFjJJRHBZBP4aVO3DkY7sNmGp2RrbaZ09NdU
+KKz8ooi5frrA+WlmjVcFKG/d66ZVLXR9AtPgKN7QMPKSpWHC1UlZ5f1zCLF
dq3lEjS/nOfFiaOPPykjG+2JFJHhUHj0ZxWYLUNs0wL6jruvRV1Y6LULWs63
TJYfvkuNCHaNxT0UlSllDLn1WywKvfsbw6/4W9pTavrWYzkFAQc1Wm4z6UVv
1RQwHlNN25W7ln3hsDrmvPEm1KMyUNztJPzfK22YZ1vY+mu3UQaAE9dFTBrs
MSa6TWUptDFs6qajHwqiUUBDJezpUmoYRAtYgu/JtcA5q9HnkObLKDgiddls
0WptJA/FN/FS4YWMVlG0oedf6s70oV2Z9AmSMyjzJF1r7pW1MVAQYnD70ekD
y/1NuH6NajEwuxMtimyNPsn9fK31DKkvCuZugnW4qK8qAW1Ram0LTldXGKfY
pwrcjgEnRmaJXMca3QGgH4+lvSSTdya3b3LuNFWXTxkpQxSwtDkkLYI1dNKO
j6ygrHziK/co3L68EHnGSR4GJF21oIY/hGMlhOkLsuXxIcv/tzorCeNtDkYC
1+Q66r+ab1VxASg62LbvpXbH9aNchFUoSqCCzmbIYKf9cx1vqv1o5WlDWnIR
5tixuoCQXbJsGHFq89ZnrPIkRDg2rgIRtTJQgCj8+teqP5QSl/kSQ1Wc9H51
IdOEfTnPYFpWF3nkeHttIUuQ6lcXcuYeX+U2J/d5H+O+TpTJ7Ll7ainhurnx
8bsjx0mrv3Y6/EaqNVYFp4mOiVbGs0zxNt6INj8S7dMSiiUxIzL+a3XE2/CX
61s/aTL5tpR5kQFVcn2bTUZG5NSVrjopxqVDk8c6A7yJbS84rZI91IokEAKP
OEOFK9m3YJKr09pI4OmCi8RR5lXtHkkv+jWK9ESIvigHouWf0vMgj+xOAqAt
rii+H3zdTRUzA8X+TjSohxZOyAWD0gkxi/2AbyL8gm4V3nfRVkQ90s0pi/dI
B6gSLoLdPZZR8dsR+NMuTaDhnR7kTqtQW8uD+oF4aJziZUNN+EBYBRZtLgWu
wIhBT6LHLKYZJo4BUeRkFKpL6dxN+sXQfEF7X9XVgpMOKgS2YODg5HujQndS
skDe3RR6M27n/Mc4n6gMI5VwY4TEyt8mVKi+LKWb6nVbxM2tPDKYw3g5e2O0
l16m9q9Yuhkfy1ddat4WkQjQwbZusX97tk+xw6KtkljTUTUnmtS39eWiusbt
yQeyw+9X9mufY4w/xTdumYBEO09YaU7yT5wkd1ai4pCeFp62TO7hBK0i8lu1
WpjTnKSZ5/cFV5zoIjq+kjZI09Atc3f89vg45UMu10G+IXTTaR4lQa37mg2/
CxhVnlgoiUJpfqGrSxJPpHmoSMdQXG92gsSXc8mFGI03crbhr9cujlvwzn/3
9HCUShRXZDMWp97jFSrjBtgD9DpaT56micKBbN3HyFxSd0VIBgXWpc+MioGN
4AtMmnspUZadiZJ4+LOYMFltWYOc6SqsaEy6T4MZ6AWVrIwICJurV++OjrcZ
Vha9BS0qnyIudx6PDn7+8vMiAQ/VyJPDYcF9lHropeyQRMG5yS4OzeDjfA3n
QrIdVggKhFNLhtMih1i6zW3JjkXQMBdcYNzYlxRoqAXTM38HJYqzDPQGPeFs
hMzh+YvXfM7jVMS9ywtg3Zi29NE17eaOw5MyKAhsqT1D4Yo3c/O+HA4eM72v
OP9qoY4KjXT06lCyz80GKfRbQxUdSTfmbsfTT1jzxYfqGojpjt0JsgzWYpBM
yGYyDDK0Fv5S9MOZGyrWoATc+1oUf3uSXSaQWCvh9DHUOs5TtUxMhZi/JLwc
uxajWhApynVhJeryLTngyTAHGXGVJUYvS9RhzwZfbLLHhmsqv+SSe5Jy06+e
HH79T1k82ZUKxDmaRhxJ55SXoDQRopfGD6ALAcbJHhq05Q2vuxZGA1UDRdMr
XGXjGZPZKE0v4cY48RHXatP1rCNlTYC/H0Yy4cvqM7VCdEFI+9V1yNkv0pqX
+lThb4pgi04Bg5uNrHjYf0Wl4zfkguxVMe6K6LIZuYMmbPKannjVhGN9rUYt
ESfHqyX/JifwccL1TPe4ukezXMN9GcKB7O+eTyPZ5/qR38DMSnzWamRpb2Bk
ccG1cMvlVIVb9cHuXOMl2PDNUi/5ICrjWg6kwtRLImntOMooGAXLuRTVPfcC
Fk983eHUIx3la7QviiGvdJ/28Eu90kPeq4nMnTgWETc+rwUeaOWS0y5DciqH
og+MPDVdKBNLfS/gTRWLtZZRqhl3hcEtvN8uOgxE0gu5SerfZVsPyxyVtp5v
9J/CMEt2/C8wywytkRd5fKOen093kgIK6dX1pYUem2VYmUb5ZXONLg5v2q8i
GQ+2LzxpJTqdEN7in3Sr8pXVW6FLxGo/klmmKqP3cjyS1d7uG8P8DnW6GBre
vvM0pIOZ/BdvrdtP/i/YY6/b8rWQtb3ETZ7yCMoGU3ZAt8OWbfLkzyIgua18
95nxhbqedjD/AfRndFiKEXEFJwW2KlmaQ9yBUjY88ii5vzVuhyqW1Coed72S
x/ErHMLL2k0rTTNbkvEuwWf+N47ncGzEVVW2YG0msNdtwUaj15LV5BLAtZ8A
mcKu3aymdToP0jhDN14cXn0rOzkLLtLHn4aju7btQ/zioq+Q91GeeaE4SjJ2
mJ3P6v/kLvxsTEx5Fo1uEK3lRZtjRupXnSU1KicteG9De0rZJgWu8aH9k50E
mCfMCeMGPLwzGB1fr9gljGDBgIeAvPx0gI6yTcUQH1lsyeBcaa7B4npollC7
WDxcuq14XO6AZ0ygy3Zs3R8nq50cb//Wr0Y+bcpvejA4fXPdJtmkycw6+1YL
Htqi64JiJW32VSonp40NAwIl98TAjlOQWtcY5WojIEiKkPHBuNVhTLawXGd1
rMK+NtzrwHGyQ3T1rdU8mFvdx4wW250FHjodubBbdnNicve6/54jtguxMPkC
MYuYvF/1Qp02Q9K1cH4CybOQhQnHQUB5g56tqLozmb8LKHpgW9w4P1zrtT8y
/oXl36neOd0K6qKK5jtsWIzVGFe8juPCd56/AYk2BiBOLn0GHFeOsWmkdf3A
WLKLDSIitgSjbE4hHq3x8uN0mnEF/H+EwvhPO6xzET9mkOg8yBXhg8mYHuZU
PDdicf80Shx9fxJsLvvyT9yLJ+pa5VgUgxnl4PDEnaRfPhFXanEL6hsYZjez
3xhyGlcJU2slzCs72G88pIEzeQTxY9vJz0NpAOeojShg3XO6NS6/JnSpyFdT
qW1+QMKXbhpRJHlzci+QlMlpYYqFdvU9M08qKAg6OS8MXpFr7ykS1Qkiz8lv
+TmSTMwUGp0Cn3fAxXfsK4fpthqSLqVrAP6GqdMQ42AKJKMMW63jpQgaq4qe
gwm4UuYAxOz//uf/6VIHiA038bLHfhoEFXiR6nrRVuRgjvqFJn5KXO3d00PX
3qOS8/eRK/OWb3nN6aff+YksiiMUxRpI/iAhqtKoWoVLb1WtGlJ9gDOIEVzy
BcCT4MgjbLrYWTpAzBtEYp4bxwQ16yTRxJlbCZUyrNxpj3j584FSPQXNY1kn
rVOrhRYhSeKRFmZ4kSFkjZMa2b7x2s84jwtwHqtrfIsDHTcqaqV65Lj3lFvm
CbxAkPNhfxQ+JQRhJy5S39cahBWGNsM0AyQ0iabGUSkrmGabyfjFaX2EbpCa
YFZDlRtyDRXFy+Y9l56oYi2PYT7ZoUgCYN7x9gMehvkQi44I+0gkZryIiTO8
gQ0glY/bKBZtNYtnHytQ81CWrUwwdWGNsguMwDuBXeBW4sBAIYMtkaaKjEHC
WkX2kAQu5JKLHGY9suINJBgJ5aBEBzUpp+b+F9R/fz25rlkGY9afHK4cp6UQ
7KFk6QfNzBkCxobicnyqKKhBfbRZU71ieFIK1+tT/pZNrC6e9VXuuy2Ew+Jl
iOlKWUAeWYCgC2LnfLqXWFHlHNMEkOqnjRFXF9Vy6SFEnMMtX5d9aQHJotlV
zVDDWms+GevPg/SP4Q9/TFWT7+NlxftRllWI84XM2Yr0uE3E1I1yqc44m3zE
RESmGxEgJ6FC1dWL1IkcpGciGlriFdi0SPBup9kUdSPiaxk8gWPRiPc43FBb
PNJhiaV2Ge1p8hoz7rgHPi33MaZCuWIbTrvh8ovI4FFfkNr1oJJk5qcq3EWE
DtIbWgyPwsirs6ff16tlvZCXHDjxIFoyAwu0a1OUvUW11LnKMqrrTEEsLEcn
nYrwFO/RZq3MvmHX+a8rpVWWKkZOilOAZoBRp1xZObJW8Pui3SzXlIHDg4cD
f82J8DVkMS4NzdhNqeQWUiUtPYMKjwFJemeoNIKBI+zZap0I7fxIF5dbnTF7
g6xgg5qC2JPbAxywg/Oxw3vJcXpqO9LiJ8uiBS4YNiC7JSzBoGNWZFo45iI8
B0+6PLXjsKey8YbzLtOq4lqc2HL4GzBQEJeE7VRTsSutVmzDTAHozhKxbIHP
B3ovRGi8FMiS4lrujkQJDfH0L2MFTMu9ofCA3G0LzS1Z1BkxWn86dpwUs7y+
6KQY7ADdNvUFytUWUc2PZktI2Oyqa5d/krV8PFTuRFZxcBUkSK/xPRop01c8
/MLSKDE/iQ8AGSh9qj2i9qJrvyPNnjTOzcqCL1sFPBPtFsLGO5B9YqU+s+Sv
hPfP1tiRWkShqFN2C5mYrXRx40qXh6JzHYEQTaNxomIVUuYDyG0WDklEuC9A
eSk0NJ3FcApnJTjG5AzXeOyGw6WYgewmTckvaA8jRkvYLqB3XtRBKF4TnS0p
gZz3IlsgRZ7oVWJNbJbvl3LBb5gaBirYYZr27ou7JElSlsi8TB0T6nOODorh
bH5XvgieJ0y5OF9Pne+NdjA2tMvE7mIqNtOjD6ZYy8egAXus2Dbumw77Ilk4
UlhNymWEgL+U/aOfoj7k1tgrktkNv4X//ktcaKkHbaAZcp3krdDc/ZJGWA7q
6egSgbA94TtaCnLjQyMlfRLQvbb3OutkHDkjj0Kz3qylHImgy7sajJRBmWkW
EBTJSIlYBsg3rZ1dradUeC8VEqfy28+goww30mbKngOtYuzdYYYC7i525QHA
oisSvYl9OtRWqQZu6hEOm+8MWq8cHwm+uCS1wsl+A4CYo04rWsc+aUl15GiH
E9RNNapldQDYs+3rPDkuUvTWOXucFV5dE0uzTjsjXlUIiZeEx9qop9BMQKPP
FG+1AOOoI2bE87vS3BZtm11Py1riyEzuqsvTm1pY1LEjuaOaeoHtsb+TTOL2
f3y2nOn3jNX4SIC/jwHDLd9c1suHRpn5t3CA8MCnO1oSdlxRwL9GRTFU3u2R
xEWXm9YRqlNnLT6EpJWuFRlIO5OpxuyYQYLnHTEdNCidp82y7ga+rAko4UZM
PgmZ0IsHkOhJQeF5m4kQKnrEkbv+yyMLX/a21Pn4k6NdokPqCmb0KBUiMkJO
6kxoihfVKk0diLD4/iQXW9D9LsbSh8MbUDlBje+Gg4XWwSNDCASCcQ7kUzRL
rfElJoCqBIXCasxpmHm/J+Xf1BDhRIN6xpR3RP+ZwbXNfFdu23JziV1mkJmk
V6OhnUn9Q/RmyuUg7ZETufo9tTq555jOIomikDrIscFSr4A0xxpf6LUtUsw7
Jy1QxrjroZPU02PWlPZQOIS3Ria4si2FWaYWwhgaXnNxUc/od+QWoXeK7B20
PIoX87S6qqu14nswbrUOmMeFLRmpgFZkomSqbEQQpA4raTnPLlxceHU/NSSx
o5/5BdbHgOLXTe/slidbNoYq/h5Ev93/VAa52st+3OmTtPuX9MSMpI/dLoLi
oeuHey9eMcnk9Zm+2OcegfkQWNCYJ8oWeUwQ5aBmkks6kEXarxtWoUyw8I1b
V9fwvSGNG5g08uZlTH7kJP5ATpcrIlOV/OTL8GUuLE1b1qdW2eAadj6mMf8e
IbgvcYGtbyRLbJRdXtYVOe7wLSTs7lecr4IYpEBuNCk46UnMED7wlWncAQuN
cF1sobm+f+/3NHeDZUZFWp6BYM8XANLiz0R9QA6VOJ3k+MwXvak7U3c1OXe3
CxyQMtZqs2UnPbRIdosS1YYudbCew1oxmpco+VfAUxBfi9S9ixgjwdfRlhCO
uIMRnE+a0h2jSUv/+7u9wu4mroRq0z275Rv3ikR/iNr+GZdoL4Cg1xRXwX9Y
zusgAoSUyxuwHzFplqujbJZSULguTiwVyKHHHZXLZtnYE3JnnBCWg72bCoEd
RVyCR7C7LNeJGxY7zXzkqzCG0lEMS6RBnZiFHDEqErXx2YrL+kPBkZs+aFhI
rfBniwRoZ0cSMWb3FDT2KTmIKW5DFoJ46PqhMURmJMZPdoNyCvsSMBJc2las
BFBeBzmh6EV5I7Zddt1AOyB/6LoN9ZxSDLZ0h8OxUFmVr7dd5gaU7m11YtMQ
leErYolwCz0zNMRbZed0m3fMmnTYw64vjCfC5aLOgs6n6qReHr5A+tVsC4GA
CoOkzO+ICwCG94RwylfDRFENSlFPkM8dOfuJbdCoCvtmkhL5XzTLF0tdec7d
+tOIIu3yb9GiE5SVjRtTv6ZQf2sAgxwp0iWONQuP6+7RxyOOZrD2UjnQz1gB
PCZTnos5T+cpg1SJh4MC/M1SCpPneVlZKJpp23S4k9LNQrFO/GLK7mIpRzGx
Cldef1aizRGbz06WhZVxy1shKKnrgCCL5+okHJ3SRDWookeNQp7y2Uy7LLIR
vmWeMyEbkZId0VGqUimVHetVc3YGFgmMMC1hF4uhSAX4lTM5zPPpvDs2QVBy
5/WHcFHiVXtY5IUlj81XNdVhF89qhkIRXmR2VxbIKhvwtUqYdZCcQYfLXERr
rnZbE/+iTkCQvUyc1A3uTl9qmdxO52SJDJyPAiz28A5D2ikFvJ3BMHlnG7Hq
YtJQCofJKOFkf8esLX+oGoOYLlBMJmwzHrxW0oa/WwvB8n7BhrMOuQ0vyaug
2Lvw8LxmAFIsqZatbEWtP78VWlRGimTzrydRijzy0QxdbZ7+YyZu85NCYZkD
x+0gQYHEYRuNUlZKMp9ggdwq8YCcBN7OQux3nZ6IR7vMnamkDVOdsf5A1HzF
uSGFqND7Zem3UBAGK+UmzuwFh4iblBg3XEzp4CGChrY5F96m6lFIsllcs3ti
SWtoIWlBiAu3pQH7qLAka0BS3e8yRpHmsdZa+HvkQCnumHJZRzxTpoxIicW+
2mVEMVWjebgu6pNyxKQumeyudpyNp2HrwYCA/d1muGmuwuESEChG2AoCj43t
anbtlb+oj6SgwoHwOIazAJTckUly2DB6UBOB1qlKBoUdXHJTbJX37o0YQnEz
14MBQDQL/bQs8nXWWBDL2bxpJNTNwmbpaDBR+tV0b0/W47FweibmgCZCS1YE
gCv+tGL/tv2p0TVlP82CIgKCNmkWs/EGVSWICrDi8gtym0Obp9M3snbFP1IM
rb0kBJHYqQbwmEFseavt10VT9Xf8dkRVf7f/+qAqlVbuiJrGNxS51+f/6L3H
mUM4Bu/1aQUepPej8RXhbszv3QkFki1+Tbo7h7akzoLLX15zndwExB5z4Y1I
W7jYM9ZU+45B77oewF22QIqS53s3Ro6sJjICMteWOfyByXK0bLbm+sa4G3QU
cx2mChDYC4KlVl1Pki4Y9N60Re8YF0IaKYaqyHmeBCtEaeNFmiHl9cnt4/6Y
RNazCGOGiM+o4o98ZVRRiCH2vAqipVcok71Zb0Q1jOEV1R4KBlxwenkM1Q3W
Asw3tobh4/6OSIXt21ve2rXLb4p6+PConIgXQ/u8jOSpiZ1jWNoR/km9ziEI
PaSu4p2HdZCwmlyvoFmyWaZXAVkqyhGdBoVziQZuFnJ+v/e3MciXKJ1Fr6fo
HmeEQa8/aowmDPe+6bC4heIPtoS6Ry4omsSi54vqLGV1A+DGupHAiThhSIMV
UnSAWUUSyLp4e+MCFexA1Gv3rLrUMpQCHVZlVIMx8jKNiChUsBBnG8Kh5blF
pLNnFVm0F48xsIaPOsCV63Oysy6bmq6k/cf3RuXj++F/D1DJ1mzrH25474fw
3g/hvR8eHIxEUjqeNQX0COPybMQ0xb1lFR4EWdzwzIXm/P19A6VxQUB2kn8P
S+qptso9ptZHhQRF/EZXyTNcCxwas5bWpr/JmHLIQ5xCGt8PI3gSlKZpUv5Z
q9dn3eWePn4g0ReEKrF1JkJmU++yLlURVh+iVn9hx4Zxzu7LzUhdHXQ4Djsp
lAJ5+LzLcijKvXC7d+5r2EcEj8Hl4KAg6MrDovjdbjhbzJu60KO7tRBqEJkM
QfqpzoGFfXNUrJPOhUJ9LklhxRkf3djF3lnMuxo+1q/a6rsnZW/Sit+UBCPS
2xJhZIjCU+U/EcPMgrzlckmKu46mZjCkf5sBLdt8PNiOm8skncpbAz7ZohcG
2bneNIp+rVnSflk3Mo2oz/sQgznCqcv4pbBjC4byWdBjDvpKnnnSsVl5ooO5
zHb2NiuNXWNa8ENPWzA0wk/37t69K34axHGB6YUpk9LJ4Vq/993du2Ooa/HC
IAd75wrMyOeLZN9n4Lht/oPtHuIgnainB0XxzTcmb9jfHkdg2gsbCCpJbq/+
7MdvHdyk+uSINiDtvi9u3XlAnL4b7PoShtkXd/67n913EoLfG67I9EoFOptf
YyvW2b9wM9x5SEVh58Q24qatQqLQbC7RLucbBonDKGCliKuRC/YvekDC9Rse
Nr0sc6ucwknEFZa0YLEyoWVZltlwptWycKGAhPxkX67wRhyC663WzoFAOXC/
u9TsxXWcG4X4E3c1QdfOKy7v5DJ6XOAtBuQMBClzZs+LahdDnmGCij6e2cIL
AAcrQ/xGgT7SiCfDJ1bUK6oGrh3uW6Q0PinbaL70zggJrYZJM+zntasi9HiO
eBDNbGjkytH8xahsse9ItOmpyBH4+QARyjz+s2t0HP5grayuV/lWYuZ6WeuE
d9CFiX0+d+wKC3muS9FRhsuSo/G+GDeVj0NmB3ZnKSH6Rdt1oIdpUIAi5eqi
xMonhwfmChXCSz1uqt1P6AJQVYmvx1VYwWD0nBIxPPutGKwhl5NLwHLyAXAm
NEEYT0Zbxz/zsdEVcV/i8See1oE8AkinK62bCYdrjvnXwn/wsriaY7TXIuCx
GUrDflRoJE1earym1uS+/5gDDqdCxwZV/fES7KiaGafVRqsF3K5jXM8DQ/OJ
qsrNl6fhZf6KHi2AYgVFjiZ+0UkGbbdBSvx2sEDIu6eH++OXQZ0/MDebJVU/
LJ89ee3vi+lSa5m6sJuO1JqbkhIh7rKEc/DZRzpIQVw/oRzBDgfqNaSynMz9
0N5BUAPqhSUauVBkDt1YtGdnigye1acb/MSIZfoz3K/GwqiWPdNSEodydH75
RuBryhBLekwtWawJ1hQlTygyIyKyI0hEJzN8P8wxehX+H1NdOnOxq92eFbRT
LNA8tYlSzy6P7xzqLG/Esk+Voh4xL/VkKxHA6ff3//Dg8+dREbcKPWwVnblI
Mz139/ffgRqO09yqcGOnuJuwJeiXnyHWEPNFXWyHs6H1Vz88ZZyUmrmJnfIB
dXUqaMrqK8IXi4iHA0OmIC2cEEqRqWSMkFXKYWnLUROdoJkXyR5QCm3kGXCD
mqnACm24gYV/u5n7v1MzjmG+DopOVp0BdmDMegDgs5hu6bbBtDSce/zyqLw3
eTAqp8G2WSZdk/lkCHA9Ky4qOkp8+fql/fbbf5EaKEQZozGwLrvcQ3dxx0XR
xeHsTlLGrVk4ZhGHkBo8ORIZloT0O5GmhVqjoQ/NZePYbsWfQNOTLbvERzAl
Vtc1EWUiWwhPDoeZeSBACh+0OvTHDaCxQmZZuWUJgmgUv4nVKwsIIB8rdArs
bLNimuItO5E90+h4jI8urlMPL30h4Y/OqpnbTQfdSHRPPTmhW8we6upHNB1E
VspJ3aMQR46AKympYbOM/nnUSzlDcUhAFSw27RL7g4UO2Eh/sthM9rYFWMC9
KTnE+x1JAUSBtb1gtRJPQM3uFC5/ucp42mVOs+zKwzLV++ddDCfwKNZ0eAYJ
xV2+dN6bSVrBF9MFAaYQktdviJce5BO+bEe8S3kEvJ4iOoteSo+xkZGblHxj
W0h5wCd2PRR/teVId44tivfSJ4xfYjuFXe2PwrHTGz/d8bof2YkeLc4LZU6Q
WdkcqE7zsiXQvnL6SsZ/7zpzeeZPiKyeWDvwjx8JLUo/PT4Na3UCAg/8k/8g
SSsHQbTHJnOefNfmQAGIX940oSjRvOgB7Txac6LwV5pyQojSoOrQnCAOq1uO
m/a1aorog3ZTTRKckxskfZjfjGnmSLzP9XeN4nCVwqT5IjafjCsheo8d9WzK
opMD0HtTx4pdHdsyJzLv/f7054TaLHYM3N0s3JB9nLEl5AIZnB7Xk2R6ii+f
HpuXL+xj4foYjqjsbs3Wwu69qHgBGAnRNRcNRe9BFa9j6eJWlEOgew6D6HLR
/ks22gE8HiOnXMEw4s74jqNWcY9LuhRmVnLqKHCJajcE062WWq0U/ZtJGlLm
D0jBf0HGgVey6zHzpgmcVDAUCZS4jFsn5FWw01qmOTe+h5z1X3hTm2fdTMJM
KknhvWW3Jo1ZdzVPkf+K5DQSF4isl4nZrGAqpyN14bWOWe6qhaaoIGR2EVOY
CBAQkb/hgbNKkF8ZJsKUgEEQmy8sweU28moxOZR7Ur6j7K8wc2StsTuw3+Ou
LnyfR4PeeWzLKLwi8U/OhtSrXiiGCgJcUgy6cpclo9SugJdiGg5FDen90G9V
uhQ0iWZuRPhOo6OZsv3rb2IFkPHAzFHG2TCueIFLi/LJFG5SfpS8ihRMxUVz
SEHxGp9YdOpv8Eh3plxMNQ5MkTExgMWFHVI2IzQJNNdME28UlIxbI/TVggyW
fgAB7+87Qr9sWtmWH4i3suc2uzbP2WqwreV9rUpvNaQgYEQL8QIleRTUp5V4
/XNIZ0+QWqaMeNPIP9Z3xvMA/yj+dr2Hth1qje27yD0j6C6qZpmwnPY2UnHD
RjKDgZBZFM40ynLwvQrbRX+HWe5ndkF7q33Hkd1+Axa3uaX7ewjP6B5KNJmz
VTWtWchsFZpJLZ7+9Z0X4JRJyKIMWxWAquDr35g6pI5dAu/oJLGMBREAlpHV
VQ2YR9ihKqNrVEuRj7MqsmjlDnHRGPkyUcgKYvfTJ7xDpSCBOtmmsBTpgqWy
zjbAkNqYnMFgOgns2ESFM1m7Iu5jK/VCb9a9ill2uBi4OuNEM8AbeVq2yBZ0
zjaH1+O+fEdo9u9OCfwFJzY/SelEpsep2rFWbC78XPXyFocrmcTHA03sEtMP
y3sH4vTyScV5SkXBwRkpZSXW0ojMhvsHuTAxg7Y6FXZjKSzpcDv4nL+qeLQH
u0X60mbF9DZ8aEC0D0j2dFr+mEZWU9v6aM1FYGZcilW8D2/UBc3uikjFSU/H
+ptS+mALHlgI7DUlGPqyY7/lEF0Cyf2qI6cmJ3xMr8uLNizOpJQUj3XVLCCv
KHFIWCqNaYOCEHIi2XwKD2naBNBqTXfJtCKjgULNLiDjHTeNofbchGEKJEko
0+S5vYdFMSZfSNA4/vh9ztTlnRVCR8NSKabat6uiHErm910K0/nMJcOjTxO0
GxswePLtO/ESNFsnhNu5VWNvadJ+umo33dNwT39BQ/HF2zem+sqORrIP8Rv8
DROHWuxoPMQH8LMWzLUaBoPzal/G5beW2olJfzJ6tnz1bu7OrsGKFVi69Nol
awe4TKbNarq5IHrGqaVwxajNrBFi3nNFGBprmWz+vM6h+OT1wEVeB+bYqFxf
eX7gVdRpkeg9izL5r8igKfu/O7iBSmX/d787KJJ5H9N/3yfbSX71RDSYsfu5
nnGT/7ihnaH//uPnv/oPfvXr8Zf/9/UAfGdoSxcFzZ4IpFE5JCFGZX6UC5pP
sxFGvTvl+2S1Pj0s78ybMwLyLmWPrJv1ov7Xvd5V85R3195uFgxHg5HszR4v
Av25jTdXEaOnIohBhfv9SeLB4b2Za3aiymTVvl1UgY431/yuoze3l5Ip/K6t
kdRpJYpICBu+wzeOeNXT2+hAhWuU3znettd3o9ykW9ft+Edg6w3tGWFCvJnE
fyb2l3dC5T615CrB9dSX/AKcYMMg+R6G87q9xQqw1sWDYDv4kbANiz5GTcd7
wJzJW0X5alCkGqrJepH3uDwm4SkhSrZDtRC570D/Q6mpALJrZqkvdfh9jCcA
FAAmQx8mL1+ku9ZtxryKoqKW244NMFuS9Kb54tVCaPL6mFZGzpQvHr9GGIVI
TuTsiGY3a6cbi4QHNVXVLbIQ6a1J8RIJfRQLVl1pnbzIBidfndzQqj4js7KR
uiGoWkOAhrxUwXW5DHYNK6Db/kio4c5XbKM/jfEnxgWBqOeqmjJPz5GG1tPB
MkcPPTXW4PvnfAI0v4dsFO0yzfgcd2uYg4pJY8Slu93xCDJMmyfoyaCoqTsr
KKc6KWu8AIe4alMRHcABRRDjBv12uiF7tQDMQp8aR44HMrRfuFQMIkS7uCBb
jSyVfco/bLrwzwN4lLX4SLU4IxqVc/IUON43SpW8ps4jQy70N6Ha7XcykgKK
JNw9RbZO03SdBCeTgFtEu+fRqwyP6Qw2lErd158+vRg/nTT1eg42pnG1mp5/
/hwvHC6jtIiDyDrBoXjnyZ5L/NtTJJpE38qPRs02VE42iBiFgclOiGsT84ZW
9aK+qhxlLQocgF4o9ZpL4O99DccL1WRaNZVmbsYsNTHQtFBv/RHFQlOShtNw
cdX9wMYOxit1rv+NJJ+LqSwpC6XjDFqjbsZEgTCEX+tSyyzC0eDfqDZBf6f1
0JIU+p0YwB7o0IvUzqPXhJJNcwThdVg0p6tqdW2eSGOTG8gDENT7erXpUM8y
HOfr6NblvvkMNVFIyBDIODSTSSWnGEUImNWTGARYV19X3fuOEZ7SdS7uumXA
sq5AeAgK1PQOG97OVddLSFcfkHxeoEkRM4NuIv4DPFuI+iVdRRUh2tybpcGE
tcKImhqNxP2Ky5ZInxnO3J3D4l5eJ321VRwowGlppNosjqkYQL4H8KxMildt
Z2s22EYriVxbL9+VoqE521mqgzLDPzZUjgKp1udd4dkG/DmJVxJMJ+K6OCIt
QSi2EwhjpITky87eMV69Rq/iVVi/sCk2nG8ZZjVcXEFEdKBGZY6eUyIaU+ru
jovMpTIg7Mc3c2p21fGipBMqNWF04rnJbrjN6C0L61xILbtRSqlGyMh1c6Go
TMqZYjeOP2daxe+q4R0HOrfmgpoUENt3BGKL2W3Ma2vle2HU2oUFrrp1fifj
lAYJFfrfaSDKrQNR1jRC3Ok3b7MspgtimuNMB04xoJcFth6eA8wPgCjGj1L6
f+jo9gPmiHan522bAj69ccGj7GMK5Q5DgQ2ypOjan4a/RsoTf3M6+v1FWAkt
ONbHN3GedOhSM621JH2uDSjDLqbOyfnN6qq+jgcuIkb/cP8+QFVBCKJoGPCg
o+FjOneKih2zuM6FaUDMskYxGRrFQrwR/pse/dWeIgcUndWNPat5RWSWqSEn
IhnOFiMuCt1NtlTRaw+yUDhKMBbqPjC5QZjwlU/giafNfE5bInwuLLevHjmK
AbX0ritsxAPiEnqsPTCNtY05GhTmaE6dl2rIFN8dgD2egrZsZYFJCSyl0kFL
D9DEKq0FkH5AuZJraBuylcMyM9KYCgXjKtA1SxK22ND2GwqHuf4Ydif5K8ho
AEpjseH9ji/EnEIrUc6F5rvi+N3b1zRrL548i1WW6FLVHtswrlhrmbsTKuvK
Kg9FB6VWLGQQLfgcuj/lic6DCDlFzj/RCo4z7lzPoN/cMOKMd0rWDPWEsTkJ
rkv9+RAr/jJfrwYGCah3wXkkvkr23dV6jXpSQUQksGcCrk5XlGNibC08aoa7
bkUwG3UJrqptJ1InPPKKKHJRT2Qn7W3ZrUwdRMPHsNetI8+SHaxk84Y9jZmr
O5QvYfLSFGUCLYS7bMzSLlzjKlgXlJOVQlsqz5ARs7kGmJ/irV9JzVrwFqw2
y3jOuETgPIUoC+x0Rvfv8mxDO1V1Pc39j8yIy1k/1Xo3DUwt6Ri0DaKxibum
H5dr+cgRjSQZ7SS6tCwUYmNFZRXgrZO8xahnWPTTxpjoq9mM+G2YLA8fnEh+
gTxU7OaszqyFtfHy+/hPvd5couXlNKyeqPLTcCvR9PtbX+9JvlUhRhdQyde8
LWG2tgAC9eDfORm1U4esCZ8hlCjwdfUeSbfIOUnY1JDj1631hEcIWhR8hFc/
b4nfj+Vc+fT1kQZPiuOXRwdGoStrS0KNdFsupIiLY8YdRHXd13DixLZ2HB1B
MWt+5vjvm/ANAMNmLQWtxSG0//x/Pn3dHTxytaKlaAj9Yagy+c1LTWA95Xzh
JEUadleTlS6ts6E/cE3EJEe9zSjx0GrWoBbKZdhIzXQN+JeWLOJj1PWuR74x
lFWZj2qCX/yQmnGz6jpTas/aasG61077bG2FeQsstrvkKu/n6vhVqTeOGc1L
SwvbB1Iiuiw1Sm732XWYOxZ6xWn4MlW2xHCa5bK9cs6VZf2hn3BnDRIEQYRE
s5bzqSWAKo4bS/Uehz/pz7D0LBdIQeWvF3PWYW8R1sa0QW7v0jjlvnJ6cyWF
PFi8IgOLsAHEhtHMe50S6dmpJzrhxUsU7Da8E87clzZopsCAXujTeiwdTDoR
C7VzBybFc0bvEYQqtMFOOORnsIKcUE75/A2msxrmr2PGVi2uyudNp5uI/nXG
8W8w/NHJ2E20LaJGBxBGVk25nKCm/7FU99tGHfhz5klOAhx3ysdTctGHSUW5
dnWgw0w4r1zySphCSBrDdTzb0KyEIb9bAgIRjvKq+Sm0d//u/bskalgIkSoY
Twr1nMJoFwKzIogZ7YWzVS1ux9ftpPyXb7998ODbcv/1s8fHPE/47e9//+39
e+X+q8evXjCRre8o8CxJMYKXdXO6bH4iT/pPWEPkkNI4MBlPn/9Yjssfw/JU
y+Ktdvc5iDCoqw/LH9v1eo681L81i/N6caGfHB+u6tD2/bv3Qnee/+V/lc+f
ld/9j7vffDu+d5uO0ey9+0v5jGhtakU4zcrD8+sOFRqOpg0lNHaxV09Cr8I6
J3P27PCbt3e/vfftt//+zb1bNtr7XpiG1+0qaH3yZfIc7B23l5fh3HTv94q4
Wq7uZbn35snjty9eP97TSUXz1fI9RNPRekPejSfhijhvyPL7tzZoaj+uqqDh
LOqgejwNt8gsDDLI5Oqnht0Kz0he/yXsE/I2CA1ps8rhLpzaSjKsrOdzIqzx
RPl/Dmfvunx2XZ8CGs/y7bwOrQXJHRSNBQiBZiyNaKZQuVF6/bLa4KJ6cr6p
OG3t3wh8FFa8llhJA92FPXJMvH9IJv1RC8+Pi5LqZWfcfrYqNYqBz1y7BYoj
hxNMWkBY1veicHXvETVug0IDmDXk/mklwL5sWsijvMKWsWxfyMrmdMMRNa5J
BQO8ldqTwfSkZRuPx+DWRDgt/eqrMJ0NCqBTcxf8k0S/acewoFlSgr6h9MmI
OCWi03DQ6M6hvAowVdGDREZKv1VgJwDviyqo8paex7+7DFoqBDeoYpABd4kK
JCKO53VF0Qe5daUGGlbEvqa+fv3UBFWEUDtbrQ/vsK9ixjBdVIXokpxjIevP
sBPeriJSB79FzBccomb2+VHBAK9V0kQ5XVDqejfywhqIU+KtwlZTLCfTM3M4
1lPhG64+TC61J3GiO3fK4+tLzaHkMvVr+kV5wQ+phypoaMJEQH9nDYeZzpc0
v2RVW6Yh5BG9domA4ZS7B9kAQKTMe+hq2Irn1aUrag7xU2zhsOS7XmJcHhQM
EMTjZfkizOkZggdL18uMWSj064lUgjlplpJqRrRhJ6MgBHFHE1yrzeG9ujvC
5bWieILm+07PJ6H1F+Gr5LE63pAD4KLqNQtl8ySMcjNdM3krvEAX9cUpF+fj
C5fQHWhZuNSxFh60ET4FHCqhcKnVw+uw+4KKfnrtyDFcPwCLGOjJmh44SdjP
iAo/6q9japvwQrUE+WiYj4OSsd41vNnDh0HfOsEsf/11qfwgJ/LL8Dnu8ERm
rNn6tSXzYNonzoP1Ua/Gi3Bc2F8RvsXTuVkJSzlqqlyuGqA94WImGpBZ0MKX
ViJEtbCMy9Ltb3Dcc1bX0O4poqGC0ouJH9oUt95uV1tmUr7hHhTgxktqdnUe
gtSx9GC4ImXSqsIbtup4wbUlSF9KzAz23PAYxy3Jeeo0H68wU8onrQRfT0bs
QSp0VmgtNMU/6o2Q4Ijc1ci2X3G6F1+78YgUwppubsmM5Bx5tuZbushw/eH3
VIOkSGYkd4Np+bboa0smTAidzymlKaufPaTzU7xiCfKv82wlhHiHOHY0XMV5
6AoTZj2EEnlFm0oCCUyP0BnBM90CzEljG2sir49KUOJgx19LOJRfG2E1GHXj
RTliLeae92aos5BTEdolWAz6bNjTZDJor/zXR0VCTo4MCMArjc+1mTXthUXP
0qYKlZOjSOx6HcsNxsJaZO1MkS2kTpggwhiXIBVBivqjMvpIMQP41JU0XbdC
L4UncU24IteHrnDuY6sYXC3jTl/GSh6MJ1cwUi/mahlcAmBhoN6H82s3X1i6
lZTILI+JTe6pRkQK/DjTmBvL+T5o2/E3P08Ui2btXaPLDW4RFNOcUq7/yP3q
gkqY2O8Z9sbiAMj/K8q+x6WIP1EsdCwiszzR/p6wCiJiXXPXwzaFJlk+V2UF
I308mzE7mXHHJyRFkVOeoJRXpCXqErnnuIrMijWcRZRK4SIpjiyeeZjyO4dZ
LE9iuycSn2LYYHYi/MJLZECdJpylyKPArexo8Pn+aSZhDU4G+j0J9+M+xa7/
tyK1gpS+apvZAZFzp3XqBt9/TA+nXzg4kXKPQ88LReu+PTz4FM/JDQ+9buPU
3fAo9/KmNtvzIH/X7jGh1St7Z/Ka/kExN94ggnGTOFzH5WPrSnOuOqNFGnZf
jfLFLpJTHn2AuAQYtjfQJb0UJQxkvi7qFyV1CTEdYvS4PDSayBIi7l3cXl3N
fpXoH3qU4X4l24l0/JZp1ugnrgySyHkmoLJc23GzhGoo3NhyIcnkRcyXPk5m
sNT49Wi26P4s+tRJk+L4yaGVpeeyzymWQB2ECmgGwAjfBLG7UsawXO4z0cZZ
CYMr/xEXoYclL/8KzVhw5f94uBU67v9ET8oEsEKQfVNjN/zNjAx515Nxqp7w
TN34zVfd2Q9MoEpSC08uWy9hZGgEN19Xp6umVZj5lvV273aEOE+2hjAqbtsT
8uexdA6B9f4+KYb3yQDF1qQ4enL8/zfKb7VR/JO6Py5620PpUwf2BdXSkKfI
hCIrZdvWqEp9YouYIIWHdFY/W5a6MKHU+C/dALRv3j091EoQtAG6f7odgNvc
vrlrB2RP7tgBgwLg9lsh/JgXMnbdIEbbTKhsZrppBjZEvm8yPibCJjAWa53m
ReZXOZMgFzwLsL5iKFdCy/I584zRtFCsC1WRU6pORoZYFkxjGVcJMisHQXxJ
d2MkXHpXeAiFAqQVgCTxG/M3TKvLaioAMHxOvz8qHIokPKVajdShVeiUM+I1
dgV3nTCgFgiiOyIu/pz8dSyvcEVz/vC2RyRIA6hZQaxqXEimO28urRoI1QWj
2EINATygZJGC/IySDRimR4BzwbA9CM0btW/HhQLxsY4/1pMlskgE0lfQn8x7
S34WhY3b0yiMVCEnZWmpDGMGx/gkCnP80gieHI7KV4f4vyBgRkYnOSpxX8HR
8uzpD4+PHaUpunXvwE6aZUB43G3CBUyfuW9Fuc9qi82TA4WFoCYZ5iWCCUxK
KtY+VXHi0mHR2Yn+HnDA1hFPEs0dAVEQt7dKg36+gU+eC8xbwcfsyyI9mT0w
p0RFHCHnFjiAj7xB/Y8y7KYjMbm+ndyjscTlHpWbyxkmv+c3kJwFhmW4b3yX
foFH5jpWYrcjVGruxwjZjHQhAGp26HZFzlvdY0nw3jZC6EIQDuSs+1g+puf8
plWQA2Sfhc3D4b4Axhhv7xGDbHl/r9y3yThw33lw94FUvsm9AzKb2aJjmW+/
NQV/IEFc5B/OBRYEYGmSA8JxCG0PFTHO3SGiWQM9DpWx0s3s4bUTqgMhfpWH
hUsElgOw/+mTOmA4Cel34qkMD0uGtXsUzS31wSOpwhpdFOLZgafsm3aljATG
SM7s9il8ToBaoT15+iQWe80Ku6edhcN/oI58b2Dj0BuRqNzxp00HyYDlCg2z
E7Jan3v26k+f7NdjSu7Xl/9MKymgcWORbFXbvnaMrSIkrqOTk0bYHRhF0hZE
oVunLxrWE86P8JMOrgcJF2lb+xmD9ppFVCnrJWTtoRP0zrGtiblB+PXKPUy9
oofH0rR2SF72DCi7OC2wS9oWnvHQ/DAnB7XVY9QOe3FzdobSK9Kknvu6Xj1E
Uau9sNQ9emfSPct3lDWgXX0jiNF3x28O9tDW9HK8WbfaTsLVHHbniyevDsVN
qOo66kdUizCCrp1zfifeusYGxmVOf5DSA58Z63BypM+6ccbHurjG0IEqLele
A9ui9ZkVdegJc5ZG/UD4Bl7VI3053fBYQ/uwNWnJIVanHCBRKDxS2UXfke/H
wuy9z+s39Ot7KkVUwSlVQ2J3i8LtUftvD3O1p+fXXmH4M4dv9h4WOzjpe3z0
PPuE4dM3+Lz5V3bpaNkotBRrfzQet6ScxNvG41L2eGxGkEqj21oDwCY55//v
D/JteOI2gzQtMxvn0+fMUU79WbbPwwjtPkw/S7M0JolBtRH1Mz8i+PhxEm93
M3ZRY0hKpCJqB11CZQ7pinNpLEzli8OSk3AiQsm57wydQUdRenDsTJFgjb1C
GdaBGQy9G9NOCUKK2vs5HY8oqhv6Rqt1m77Qc9qRN6dg/idyeqzDQ8sxqLYz
8Fv8bAfT/t6NbPh7vkb9dNnfGkdB/+XNMYp7+3VFyRWWokt/esblDgXmpwlo
5cnLoMs8+xhmuHyKKqM/hCWmWHl47lgu15Ow78CZBamvwV9TSyff5aotq0UD
ymSFi3ix4AxcymdHVNgVM6E1eCJWodiYQyfHW4RBxz+sV2OrFCh+gv29t1Ih
TAgzTzdcUFaw6nsHyG/KO0DSbFf7OGKubQhtMJsxE4GpJp5dC7hjZddiznGt
rVEtEyJBVUzT8kuMZIB2TPb0w0LLo2v3RXD3SHoJbQpiQ8rcgcZCPvWLaomk
vrCOCyAn1TDbanpM7qdrvEUx2AM11RDB2K85fBHkt26L1v8Xtbd9vnMCYO5L
2B5B6hnhhb5sNUxEX4otgEQeluRoO0GaUXwJuaxmGID+a8t6vO0pylIReNgT
TYKi/0qlZ2b7e7wi75Z9xdxeDrOotJv6x+Tg5Zq3aBg432+dZxH87IZTtted
8zGqfuqmQyETPcSKXKOjLoMNR6YnvUV7yR3EXOxAlPm1bjJG2xgR/irZloS1
XnUDHU8Lv6GMeyyal6dL9mc9qWjrJWjqMR2Sn9Nc32QTTfrjpvthoVP1spnX
pPAPTJXjNGBLZcz+EIHAxPtGr2/vKZZ5Xsjnbeu+EeCWvmPcuPtJ9newxbUc
4mYpYK8D24/trT4yr7q1fsQ+gZHTNfah3X6V9fZhb25o6mQoJzpWaUOHmt1T
XO0bUilBjpf7R4+f/OWAfWIXashrrt559ENYbmJDpdlUcsVSlgOj2Z0PORXY
vaCUMhC+cnNvubwPd1/epXgrBi/eoUOZXcAsktgyhjLzkv3Q37xQz+NVfSLT
zFzCOK/7eI0qSbidcQF+HLLGY9Vek0dmFYz5d6bp5/W796PGZlXCbaWFzjiu
32/QlHoNdosX6s+LvBCR5fn17euf08+s1Or+QLLisKUPqlDKdKXdGRp/9vGy
WSXjrvk30aQPb/RMetoqavn324n1LVB7S5iMkJIEcgMtSEOfeZhW9KET0bJV
sM7LRvkbbZ32Zj3cj7a0PFIhC6l6C2GSK6cWjUuTDz8tu7hlpp99JKQebcq3
aZW3cp/TKT9UK+hS7PZkHxcmL6zMebuYheNyO4fK/wPNfYd/1KoCAA==
--> -->
</rfc> </rfc>
 End of changes. 453 change blocks. 
3091 lines changed or deleted 1974 lines changed or added

This html diff was produced by rfcdiff 1.48.