Diff: rfc9622.original.xml

	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 " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<?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="Transport Services API">The Transport Services Application Pr
	ansport Services</title>	ogramming Interface</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-taps-interface-26"/>
		<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.S." 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>


	<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>


	<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 not associated with an object are actions on the API; they are equivalen
	actions on a per-application global context.</t>	t 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 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">

	<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 for 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
	does not provide these.</t>	transport does not itself provide the required framing.</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 335 ¶
	</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 427 ¶
	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>

	<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
	using the Transport Services API, and send a request as well as receive a respon	to a remote application using the Transport Services API, send a
	se on each of them.	request, and receive a response for each of the two Connections.
	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 480 ¶
	//---- 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>


	</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	<t>Allowing different components of a Transport Services
	ion to pass Transport	Implementation to pass Transport Properties (e.g., between a
	Properties, e.g., between a language frontend and a policy manager,	language frontend and a policy manager) or to enable a Transport
	or as a representation of properties retrieved from a file or other storage.</t>	Services Implementation to represent properties retrieved from
		a file or other storage to the application.</t>
	</li>	</li>
	<li>	<li>

	<t>Making the code of different Transport Services Implementations l	<t>Making the code of different Transport Services Implementations
	ook similar.	look similar. While individual programming languages might
	While individual programming languages might preclude strict adherence to the	preclude strict adherence to the naming convention of representing
	aforementioned naming convention (for instance, by prohibiting the use of hyphen	property names as case-insensitive strings
	s	(for instance, by prohibiting the use of hyphens in symbols),
	in symbols), users interacting with multiple implementations will still benefit	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>


	</ul>	</ul>
	<t>Transport Property Names are hierarchically organized in the	<t>Transport Property Names are hierarchically organized in the
	form [<Namespace>.]<PropertyName>.</t>	form [<Namespace>.]<PropertyName>.</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 dot character (
	</tt> MUST be omitted for well-known,	"<tt>.</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.
	>	</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.	<t>For IETF protocols, the name of a Protocol-specific Property <bcp
	An IETF protocol Namespace does not start with an underscore character.</t>	14>MUST</bcp14> be specified in an RFC from the IETF Stream (after IETF review).
		An IETF protocol Namespace does not start with an underscore character ("<tt>_
		</tt>").</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 682 ¶
	<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	<t>Actions, events, and errors in implementations of the Transport Ser
	vices API SHOULD use	vices API <bcp14>SHOULD</bcp14> use
	the names given for them in the document, subject to capitalization,	the names assigned to them in this 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.</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 o
	emote Endpoint Identifer	r Remote 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) gro
	ticast group and destination port number.	up 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 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 t specifiers.</t>	<t>Note that the Transport Services API has separate specifier calls f 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 t specifiers.</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>


	<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 trigger the Transport Services Im
	address as the Remote Endpoint Identifer will join the multicast group, and also	plementation to join the multicast group and also
	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 913 ¶
	<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 949 ¶
	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 1086 ¶
	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>


	<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 per-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 or 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)).</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 1300 ¶
	<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 1367 ¶
	<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 1410 ¶	skipping to change at line 1436 ¶
	<t>Empty (not setting a preference for any interface)</t>	<t>Empty (not setting a preference for any interface)</t>
	</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 be implemented to
	interface and interface type available on the system.</t>	make one preference available for each interface and interface type
	<t>The set of valid interface types is implementation- and system-spec	available on the system.
	ific. For
		</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 1477 ¶
	<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
	or for making one preference available for each interface and interface type	be implemented to
		make 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>

	<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 1858 ¶
	<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 1923 ¶
	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>

	<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 using
	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<></tt> event:</t>	<tt>RendezvousDone<></tt> event:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	Preconnection -> RendezvousDone<Connection>	Preconnection -> RendezvousDone<Connection>
	]]></artwork>	]]></artwork>
	<t>The <tt>RendezvousDone<></tt> event occurs when a Connection is established with the	<t>The <tt>RendezvousDone<></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<></tt> eve nt, and is	resulting Connection is contained within the <tt>RendezvousDone<></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<></tt> event, described in <xref target= "conn-path-change"/>, will be	those endpoints. A <tt>PathChange<></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>

	<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 2398 ¶
	</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>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	failed when trying to reliably deliver data to the Remote Endpoint. Adjustments
	is property	to this property
	will only take effect when the underlying stack supports reliability. If this pr	will only take effect if the underlying stack supports reliability. If this prop
	operty has the enumerated	erty 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	the Local Endpoint sends a keep-alive packet to the Remote Endpoint. Adjustments
	his property	to this property
	will only take effect when the underlying stack supports sending keep-alive pack	will only take effect if the underlying stack supports sending keep-alive packet
	ets.	s.
	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 2449 ¶
	<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 <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"?

		-->

	<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 algorithm (see <xref target="RFC1122" sectionFormat="of" section="4.2.3.4"/>)); 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 2659 ¶
	<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>
	<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	<t>Note that this does not guarantee that information will not leak be
	estimates). Note that this property could degrade Connection performance.</t>	cause
		implementations might not be able to fully isolate all caches (e.g.,
		RTT 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 2727 ¶
	<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 2767 ¶
	<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	<t>Each Message has an optional Message Context, which allows adding Mes
	to inspect meta-data related to the Message sent. Framers can be used to extend	sage Properties, to identify <tt>Send</tt> events related to a specific Message
	or modify the Message data with additional information that can be processed at	or to inspect metadata related to the Message sent. Framers can be used to exten
	the receiver to detect message boundaries.</t>	d or modify the Message data with additional information that can be processed a
		t the 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 2898 ¶
	</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 2942 ¶
	\| +-----------------+ \|	\| +-----------------+ \|
	\| \| \| \|	\| \| \| \|
	+----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 2995 ¶
	...	...
	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	<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 and then allow the end of t
	Message to still be sent.</t>	he Message 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 3038 ¶
	<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 3063 ¶
	</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 3085 ¶
	</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 3141 ¶
	</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 3164 ¶
	<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 3189 ¶
	<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 3238 ¶
	</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 3263 ¶
	<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	<aside><t>Note: noSegmentation is used when it is desired to send a
	a single network packet.</t>	Message within
		a single network packet.</t></aside>

	</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.
	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. Another example would be 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	<t>The Transport Services API should allow the application to correlat
	e which <tt>Send</tt> action resulted	e a <tt>Send</tt> event to the particular call to <tt>Send</tt> that triggered t
	in a particular <tt>Send</tt> event. The manner in which this correlation is ind	he event. The manner in which this correlation is indicated
	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 3403 ¶
	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 <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>
	<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
	in a particular <tt>Receive</tt> event. The manner in which this correlation is	e a <tt>Receive</tt> event to the particular call to <tt>Receive</tt> that trigg
	indicated	ered the 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 3741 ¶
	<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<></tt> occurs when a Connection created with <tt>In itiate</tt> or	<t><tt>Ready<></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<></tt> occurs when a Connection create d with <tt>Listen</tt>	<t><tt>ConnectionReceived<></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 3795 ¶
	<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<></tt> events will occur on a Connection in the orde r in which the Messages	<t><tt>Sent<></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<></tt> will never occur on a Connection before i	<t><tt>Received<></tt> will never occur on a Connection before i
	t is Established; i.e.	t is Established, i.e.,
	before a <tt>Ready<></tt> event on that Connection, or a <tt>ConnectionRec	before a <tt>Ready<></tt> event on that Connection or a <tt>ConnectionRece
	eived<></tt> or	ived<></tt> or
	<tt>RendezvousDone<></tt> containing that Connection.</t>	<tt>RendezvousDone<></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<></tt> event, an <tt>EstablishmentError<></tt> or <tt>Con nectionError<></tt> will not occur on that Connection. To	<tt>Closed<></tt> event, an <tt>EstablishmentError<></tt> or <tt>Con nectionError<></tt> will not occur on that Connection. To
	ensure this ordering, <tt>Closed<></tt> will not occur on a Connection whi le other	ensure this ordering, <tt>Closed<></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,	<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	underlying communication actions to the application itself. The Transport Servic
	es API is designed such that protocol and path selection	es API is designed such that protocol and path
	can be limited to a small and controlled set if the application requires this or	selection can be
	to implement a security policy.	limited to a small and controlled set if required by the application
	can be limited to a small and controlled set if required by the application to p	to perform a function or to provide security.
	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"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc
		e.RFC.1122.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
		<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. Actions could be implemented as either functions
	method calls, for instance, and events could be implemented via event queues,	or method calls.
	handler functions or classes, communicating sequential processes, or other	For instance, actions could be implemented via event queues, 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	<t>The objects described in <xref target="notation"/> can also be repres
	different ways depending on which programming language is used. Objects	ented in
	like Preconnections, Connections, and Listeners can be long-lived, and	different ways, depending on which programming language is used. Objects
	benefit from using object-oriented constructs. Note that in C, these	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>


	<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 is to gener
		ate 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>:</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>

	<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>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">preserveOrder</td>	<td align="left">preserveOrder</td>

	<td align="left">require</td>	<td align="left">Require</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">congestionControl</td>	<td align="left">congestionControl</td>

	<td align="left">require</td>	<td align="left">Require</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">preserveMsgBoundaries</td>	<td align="left">preserveMsgBoundaries</td>

	<td align="left">no preference</td>	<td align="left">No Preference</td>
	</tr>	</tr>
	</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>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">preserveOrder</td>	<td align="left">preserveOrder</td>

	<td align="left">require</td>	<td align="left">Require</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">congestionControl</td>	<td align="left">congestionControl</td>

	<td align="left">require</td>	<td align="left">Require</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">preserveMsgBoundaries</td>	<td align="left">preserveMsgBoundaries</td>

	<td align="left">require</td>	<td align="left">Require</td>
	</tr>	</tr>
	</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>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">preserveOrder</td>	<td align="left">preserveOrder</td>

	<td align="left">avoid</td>	<td align="left">Avoid</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">congestionControl</td>	<td align="left">congestionControl</td>

	<td align="left">no preference</td>	<td align="left">No Preference</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="left">preserveMsgBoundaries</td>	<td align="left">preserveMsgBoundaries</td>

	<td align="left">require</td>	<td align="left">Require</td>
	</tr>	</tr>
	<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 <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.
		This list is a subset of the transport features in
		<xref target="RFC8923" sectionFormat="of" section="A"/>, which refers to the pri
		mitives in "pass 2". See <xref target="RFC8303" section="4" sectionFormat="of"/
		>) for 1) further details on the implementation with TCP, MPTCP, UDP, UDP-Lite,
		SCTP, and LEDBAT and 2) how to facilitate finding the specifications for impleme
		nting
	the services listed below with these protocols.</t>	the services listed below with these protocols.</t>

	<ul spacing="normal">	<ul>
	<li>
	<t>Connect:	<li>Connect:
	<tt>Initiate</tt> action (<xref target="initiate"/>).</t>	<tt>Initiate</tt> action (<xref target="initiate"/>).</li>
	</li>
	<li>	<li>Listen:
	<t>Listen:	<tt>Listen</tt> action (<xref target="listen"/>).</li>
	<tt>Listen</tt> action (<xref target="listen"/>).</t>
	</li>	<li>Specify number of attempts and/or timeout for the first establishm
	<li>	ent Message:
	<t>Specify number of attempts and/or timeout for the first establishme	<tt>timeout</tt> parameter of <tt>Initiate</tt> (<xref target="initiate"/>) or <
	nt Message:	tt>InitiateWithSend</tt> action (<xref target="initiate-and-send"/>).</li>
	<tt>timeout</tt> parameter of <tt>Initiate</tt> (<xref target="initiate"/>) or <
	tt>InitiateWithSend</tt> action (<xref target="initiate-and-send"/>).</t>	<li>Disable MPTCP:
	</li>	<tt>multipath</tt> property (<xref target="multipath-mode"/>).</li>
	<li>
	<t>Disable MPTCP:	<li>Hand over a Message to reliably transfer (possibly multiple times)
	<tt>multipath</tt> property (<xref target="multipath-mode"/>).</t>	before connection establishment:
	</li>	<tt>InitiateWithSend</tt> action (<xref target="initiate-and-send"/>).</li>
	<li>
	<t>Hand over a Message to reliably transfer (possibly multiple times)	<li>Change timeout for aborting connection (using retransmit limit or
	before connection establishment:	time value):
	<tt>InitiateWithSend</tt> action (<xref target="initiate-and-send"/>).</t>	<tt>connTimeout</tt> property, using a time value (<xref target="conn-timeout"/>
	</li>	).</li>
	<li>
	<t>Change timeout for aborting connection (using retransmit limit or t	<li>Timeout event when data could not be delivered for too long:
	ime value):	<tt>ConnectionError</tt> event (<xref target="termination"/>).</li>
	<tt>connTimeout</tt> property, using a time value (<xref target="conn-timeout"/>
	).</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>Timeout event when data could not be delivered for too long:
	<tt>ConnectionError</tt> event (<xref target="termination"/>).</t>	<li>Notification of ICMP error message arrival:
	</li>	<tt>softErrorNotify</tt> (<xref target="prop-soft-error"/>) and <tt>SoftError</t
	<li>	t> event (<xref target="soft-errors"/>).</li>
	<t>Suggest timeout to the peer:
	See "TCP-specific Properties: User Timeout Option (UTO)" (<xref target="tcp-uto"	<li>Choose a scheduler to operate between streams of an association:
	/>).</t>	<tt>connScheduler</tt> property (<xref target="conn-scheduler"/>).</li>
	</li>
	<li>	<li>Configure priority or weight for a scheduler:
	<t>Notification of ICMP error message arrival:	<tt>connPriority</tt> property (<xref target="conn-priority"/>).</li>
	<tt>softErrorNotify</tt> (<xref target="prop-soft-error"/>) and <tt>SoftError</t
	t> event (<xref target="soft-errors"/>).</t>	<li>"Specify checksum coverage used by the sender" and "Disable checks
	</li>	um when sending":
	<li>	<tt>msgChecksumLen</tt> property (<xref target="msg-checksum"/>) and <tt>fullChe
	<t>Choose a scheduler to operate between streams of an association:	cksumSend</tt> property (<xref target="prop-checksum-control-send"/>).</li>
	<tt>connScheduler</tt> property (<xref target="conn-scheduler"/>).</t>
	</li>	<li>"Specify minimum checksum coverage required by receiver" and "Disa
	<li>	ble checksum requirement when receiving":
	<t>Configure priority or weight for a scheduler:	<tt>recvChecksumLen</tt> property (<xref target="conn-recv-checksum"/>) and <tt>
	<tt>connPriority</tt> property (<xref target="conn-priority"/>).</t>	fullChecksumRecv</tt> property (<xref target="prop-checksum-control-receive"/>).
	</li>	</li>
	<li>
	<t>"Specify checksum coverage used by the sender" and "Disable checksu	<li>Specify DF field:
	m when sending":	<tt>noFragmentation</tt> property (<xref target="send-singular"/>).</li>
	<tt>msgChecksumLen</tt> property (<xref target="msg-checksum"/>) and <tt>fullChe
	cksumSend</tt> property (<xref target="prop-checksum-control-send"/>).</t>	<li>Get maximum transport-message size that may be sent using a non-fr
	</li>	agmented IP packet from the configured interface:
	<li>	<tt>singularTransmissionMsgMaxLen</tt> property (<xref target="conn-max-msg-notf
	<t>"Specify minimum checksum coverage required by receiver" and "Disab	rag"/>).</li>
	le checksum requirement when receiving":
	<tt>recvChecksumLen</tt> property (<xref target="conn-recv-checksum"/>) and <tt>	<li>Get maximum transport-message size that may be received from the c
	fullChecksumRecv</tt> property (<xref target="prop-checksum-control-receive"/>).	onfigured interface:
	</t>	<tt>recvMsgMaxLen</tt> property (<xref target="conn-max-msg-recv"/>).</li>
	</li>
	<li>	<li>Obtain ECN field:
	<t>"Specify DF field":	This is a read-only Message Property of the MessageContext object (see
	<tt>noFragmentation</tt> property (<xref target="send-singular"/>).</t>	"<xref target="receive-ecn" format="title"/>" (<xref target="receive-ecn" format
	</li>	="default"/>)).</li>
	<li>
	<t>Get max. transport-message size that may be sent using a non-fragme	<li>"Specify DSCP field", "Disable Nagle algorithm", and "Enable and c
	nted IP packet from the configured interface:	onfigure a <tt>Low Extra Delay Background Transfer</tt>":
	<tt>singularTransmissionMsgMaxLen</tt> property (<xref target="conn-max-msg-notf	as suggested in <xref section="5.5" sectionFormat="of" target="RFC8923"/>, these
	rag"/>).</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>Get max. transport-message size that may be received from the confi	<xref target="send-profile"/>).</li>
	gured interface:
	<tt>recvMsgMaxLen</tt> property (<xref target="conn-max-msg-recv"/>).</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>Obtain ECN field:	line with the discussion in <xref section="5.2" sectionFormat="of" target="RFC89
	This is a read-only Message Property of the MessageContext object (see "UDP(-Lit	23"/> (see also <xref target="termination"/>).</li>
	e)-specific Property: ECN" <xref target="receive-ecn"/>).</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>"Specify DSCP field", "Disable Nagle algorithm", "Enable and config	ta, not causing an event informing the application on the other side":
	ure a <tt>Low Extra Delay Background Transfer</tt>":	these are offered by the <tt>Abort</tt> action without promising that these are
	as suggested in <xref section="5.5" sectionFormat="of" target="RFC8923"/>, these	signaled to the other side. If they are, a <tt>ConnectionError</tt> event will b
	transport features are collectively offered via the <tt>connCapacityProfile</tt	e invoked at the peer (<xref target="termination"/>).</li>
	> property (<xref target="prop-cap-profile"/>). Per-Message control ("Request no
	t to bundle messages") is offered via the <tt>msgCapacityProfile</tt> property (	<li>"Reliably transfer data, with congestion control", "Reliably trans
	<xref target="send-profile"/>).</t>	fer a message, with congestion control", and "Unreliably transfer a message":
	</li>	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
	<t>Close after reliably delivering all remaining data, causing an even	"/>) property and the <tt>msgReliable</tt> Message Property (<xref target="msg-r
	t informing the application on the other side:	eliable-message"/>). Transmitting data as a Message or without delimiters is con
	this is offered by the <tt>Close</tt> action with slightly changed semantics in	trolled via Message Framers (<xref target="framing"/>). The choice of congestion
	line with the discussion in <xref section="5.2" sectionFormat="of" target="RFC89	control is provided via the <tt>congestionControl</tt> property (<xref target="
	23"/> (<xref target="termination"/>).</t>	prop-cc"/>).</li>
	</li>
	<li>	<li>Configurable Message Reliability:
	<t>"Abort without delivering remaining data, causing an event informin	the <tt>msgLifetime</tt> Message Property implements a time-based way to configu
	g the application on the other side" and "Abort without delivering remaining dat	re message reliability (<xref target="msg-lifetime"/>).</li>
	a, not causing an event informing the application on the other side":
	this is offered by the <tt>Abort</tt> action without promising that this is sign	<li>"Ordered message delivery (potentially slower than unordered)" and
	aled to the other side. If it is, a <tt>ConnectionError</tt> event will be invok	"Unordered message delivery (potentially faster than ordered)":
	ed at the peer (<xref target="termination"/>).</t>	these two transport features are controlled via the Message Property <tt>msgOrde
	</li>	red</tt> (<xref target="msg-ordered"/>).</li>
	<li>
	<t>"Reliably transfer data, with congestion control", "Reliably transf	<li>Request not to delay the acknowledgement (SACK) of a message:
	er a message, with congestion control" and "Unreliably transfer a message":	should the protocol support it, this is one of the transport features the Transp
	data is transferred via the <tt>Send</tt> action (<xref target="sending"/>). Rel	ort Services system can apply when an application uses the <tt>connCapacityProfi
	iability is controlled via the <tt>reliability</tt> (<xref target="prop-reliable	le</tt> Property (<xref target="prop-cap-profile"/>) or the <tt>msgCapacityProfi
	"/>) property and the <tt>msgReliable</tt> Message Property (<xref target="msg-r	le</tt> Message Property (<xref target="send-profile"/>) with value <tt>Low Late
	eliable-message"/>). Transmitting data as a Message or without delimiters is con	ncy/Interactive</tt>.</li>
	trolled via Message Framers (<xref target="framing"/>). The choice of congestion
	control is provided via the <tt>congestionControl</tt> property (<xref target="	<li>Receive data (with no message delimiting):
	prop-cc"/>).</t>	<tt>Receive</tt> action (<xref target="receiving-action"/>) and <tt>Received</tt
	</li>	> event (<xref target="receive-complete"/>).</li>
	<li>
	<t>Configurable Message Reliability:	<li>Receive a message:
	the <tt>msgLifetime</tt> Message Property implements a time-based way to configu	<tt>Receive</tt> action (<xref target="receiving-action"/>) and <tt>Received</tt
	re message reliability (<xref target="msg-lifetime"/>).</t>	> event (<xref target="receive-complete"/>) using Message Framers (<xref target=
	</li>	"framing"/>).</li>
	<li>
	<t>"Ordered message delivery (potentially slower than unordered)" and	<li>Information about partial message arrival:
	"Unordered message delivery (potentially faster than ordered)":	<tt>Receive</tt> action (<xref target="receiving-action"/>) and <tt>ReceivedPart
	these two transport features are controlled via the Message Property <tt>msgOrde	ial</tt> event (<xref target="receive-partial"/>).</li>
	red</tt> (<xref target="msg-ordered"/>).</t>
	</li>	<li>Notification of send failures:
	<li>	<tt>Expired</tt> event (<xref target="expired"/>) and <tt>SendError</tt> event (
	<t>Request not to delay the acknowledgment (SACK) of a message:	<xref target="send-error"/>).</li>
	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	<li>Notification that the stack has no more user data to send:
	le</tt> Property (<xref target="prop-cap-profile"/>) or the <tt>msgCapacityProfi	applications can obtain this information via the <tt>Sent</tt> event (<xref targ
	le</tt> Message Property (<xref target="send-profile"/>) with value <tt>Low Late	et="sent"/>).</li>
	ncy/Interactive</tt>.</t>
	</li>	<li>Notification to a receiver that a partial message delivery has bee
	<li>	n aborted:
	<t>Receive data (with no message delimiting):	<tt>ReceiveError</tt> event (<xref target="receive-error"/>).</li>
	<tt>Receive</tt> action (<xref target="receiving-action"/>) and <tt>Received</tt
	> event (<xref target="receive-complete"/>).</t>	<li>Notification of Excessive Retransmissions (early warning below abo
	</li>	rtion threshold):
	<li>	<tt>SoftError</tt> event (<xref target="soft-errors"/>).</li>
	<t>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"/>).</t>
	</li>
	<li>
	<t>Information about partial message arrival:
	<tt>Receive</tt> action (<xref target="receiving-action"/>) and <tt>ReceivedPart
	ial</tt> event (<xref target="receive-partial"/>).</t>
	</li>
	<li>
	<t>Notification of send failures:
	<tt>Expired</tt> event (<xref target="expired"/>) and <tt>SendError</tt> event (
	<xref target="send-error"/>).</t>
	</li>
	<li>
	<t>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"/>).</t>
	</li>
	<li>
	<t>Notification to a receiver that a partial message delivery has been
	aborted:
	<tt>ReceiveError</tt> event (<xref target="receive-error"/>).</t>
	</li>
	<li>
	<t>Notification of Excessive Retransmissions (early warning below abor
	tion threshold):
	<tt>SoftError</tt> event (<xref target="soft-errors"/>).</t>
	</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
	WX/yhFgACmS5gSq4qkAKardj32EfYPdZdt9kn2TPNfNkVgFk6zL2F/E5wrYa
	rMrKy8lzP78zHo9dV3bL4ig7rrLjads1+azLjtfrZTnLu7Kuspf5tmiyF1VX
	NIt8VmRdnZ03edWu66bLzormupwVrcun06a4PsrOj0/PwsNuXs+qfAWjz5t8
	0Y3LoluMu3zdjkt9ZPzwczfPu+LIwfeKy7rZHmVtN3euXDdHWdds2u7h/ftf
	3n/oburm3WVTb9bylb/Cv8vqMvsGf3Pvii08MD/ij1dFN36Gn3Su7fJq/kO+
	rCuYxhamui6Psu+7ejbKWlhCUyxa+K/tCv/jb87lm+6qbo5clo3hf7OsrNqj
	7OkE17xaFcsl/chretqUeRX/oW4uj7Jv6vpyWWRnN2X3U9Es4fPZN6vpt/RA
	U+NeF/Oyqxv6oVjl5fIow535YydDTWZX9Dc4jaLoYEDYhPx6/M1muRyfLvPu
	p+wB/X1WdrBbT+7ff5z9j01TyluzelN1uI1mAvFyXk2yvxbLn+xaXsHbebE0
	v/dmSmv7riqvi6aFD2f1InvTLutopqdvsqf1j9mD+0/uZ0+XZTWHozBTvf/o
	wedZeMvP9HXd3ORbux8rnM9N8cdyUU42ZT2p6ngJbyfZ8+ryKm/mnVnF26Jo
	i/gPNOvXsLvL8sdoqg8ePsiOl9OmvLzqsr/K13maL+s2+ybvaiCMk+Psy8/u
	P3oYzxd2oSvm2VkHJNviRhyvCtj/vH+ihcxlAhQZr+CbSfZ1XjZXm6a1S/im
	njcwdPynga0/nhbNvCiqaE3PinXedKui6vAR2IeyKmBi1WX01NdN3sKVfl1P
	gUqfbsrlXJ/g5evQo+z46cPH2aPvnid0Nas7ISq/Wri4zfaPRXM5yafzapLP
	Jpt39Hegy6PsquvWR59+enNzM4kf+bRHmH/aFFfL4qaU4ZU6m3/N0z/RpjyH
	bW/buoppB56evPNP/7GQhyazehXthL49Pl4uiyK6Vd8WzU/1ZVE1eZdcq2+K
	ZpVX23jmJ5PstEB+1Jppn9RwBaLfBw7ym2XeXtY30bzOZld1vcS/ntSr9aZD
	Nnc2K4sKWGqYoryZZd88eJg9+fOfB2n0T/DuXJYt+zNr13+E/+VpTWBK8VJO
	gdmVcI8sezi9Kpflep2dRX+j1Zwdn2Znz2N+VcBfivFZV6yvigr39wxY2//7
	fxXZF+MHj8wKHtz/7LMvsqfAo8pq1yb7aa95Dn/saAL9C3UOR5Bvllsz7fN6
	tdqaX2nCKNwKEBOzSTTpN1UhfzrNm3cJRzjZwHbBMdTAEfJluaibqsyRMzx4
	/PGcoVvjhP6Y48eIJF1Vw2o7oAqUOy/GzyZBUObN7OoIpGG12P1MuVov8de3
	X5988dlnn+N/np+cjk/efHf68sXrb47o4yLm7826Zgl/RWY538yQsl7CXKvZ
	NuuuQJJeXgHNbWBm8xHcARCleAmKetNmrzbLrhx/vQSKg/fhqeqyaElFgP/s
	QFzc4/2E9RYtzpe/i//z4vnz59mL11+/OXnzCsi2nuZLL6ezs+1qXbflZpUd
	fPPiMEMx317Va/xX9vD+gyeHNEyQy/g/Yz80HT2Q5Yt2ma/8r3z8Z/mi/LfN
	Mvpb8mYkCi3DScVh780/TbJvS1AgrpJX/9SUsCugGER/TV5+Bi/nqIzE7z7L
	r8t59JfkPRAax82q7PLLInn1m6aorktgY+kD/a365l+LtlWWb3arK4BbRX8k
	xYwOwTk3Ho+zXDRE586vyjYD9W5D0mZetLOmnALJw8L1oSw3auQaCAnVGyQ4
	r/yBhDl9MUKVsrsCzVLVSrcknbO7yrusqHIQUy09ANe+mNFocLH80zg0qHP1
	Ej8+d0BSSELZGhg3zHALi4M5LJfbDEZr4JqWqwK4GE4fPu7HX+QtTAoWsl7W
	W1yTg29UxU08uv9XtijybtPAi6BkXdUbGLr4t02JsjYD0sGrIctyZhda/DCs
	Y13MQLEBPoEzWNRLuFO8wr5mnSEDAJ4yw6+56RZnAESC38nbbTWDO1vB7RzB
	6mpYKG/LqoQz5G1awXECMcCXX3QZrBn3HtSyOc6ugcWSSg+zfHr2DPTh2bui
	433JeULAnlYwUGnVf3w87D6d1QiewKNHGoQJEU3cXBVNAb/M1zW83iKPXM7l
	DLNFA3xvhRwFOW58ZrTPNUwTrtFy6JwnTIyrcj5fFs59grykqYGb4R6npKmb
	/ZGkmR3ALhwyDQbqxi0Jj8DmrMGsIG3L4Z+uQJkcL4tr4By3nCSMuQDlbA6j
	uffv/6HP8z98gKs+NEq7BUJdZe1mjb+D5fUxVJDV13ixPvrq8KnBdMMdoiM3
	593KgRMV8Jk7fq2l085+wWkbe7TlI8nn9bqD/5RbfAOcL5uCoFqUTFtZDr/N
	kWXw4fhh/b2lYWY42+t6eV3IzgTmoN8foxWzxjsD58wcow0DEFuiE3HhYuKP
	+CSODtMsV+VPQDawD9PiCjh83WRT0MDnGZwNPmpo0TEXKXhDcWt0s2Z1BaYY
	bsDoY1kOr2exLH4sp6BCgdq5k+llwvT8LiFZ+JMY0YxwVUJ9duqwOtRnF2Rv
	ZHDJiEXB8wugoGk+e+dWBU6zbFe4hCuQsFkNk21uyhZpglnSFI8MjBgQPEB2
	qNjQXtBFyYoc3jGfnLiB+/FC35FZ5UCTC1DxaG/yd0igW7zRJZpZqFQhq1uC
	MuOE5eHJCdMQBlFWTGmep8B/X8GFgxG+AkKr6mrdEItYo36WXW6Q8rra+enT
	Vuy5zDBefg26IZ5K9v79H/rqHbADZGyDEkIGAVsbvt76udP9ioWWF6B4pqTR
	8hHreeIZ9G8K3Sci1Cpfblu+G0Dqyr3+AHrnk/tffvbhwyiTf3358BH+C6nH
	//IQWdqOJVhJDORVRmfo4OQsM0LjCEgmH2AWGZprRQPMGIkUX+dXpnCJ6RAi
	RlLDGP7NvHPIz0s4AeUCO6eaL9taN6GNbhvdTWQ++RbHR6bSEDX4gYISgxsP
	OlmXI+vrcEH+6ODH2buRKyaXE1KP9L6Bco2mI3ylvSJOU2dLUDeLihcTjl5W
	BWpmfQPyCAQ0kDpfSQf7V7Ik37TRV80k8ftIlvOyBbndgOygy5KhMdAAn4Y3
	R3BZZzkOUTIjbdCgKDIcIGdGAzT7ySfZOdhyYDot68strfl1zeeavf+kkv/8
	sJO4cbtxHiKCiQ8Az1qhcQVqQPZm+q8kYmjfmaugnDfiHadGMhvk/lfwxvFM
	5UjRew7uBLEE5sywtJqHx/eeXyNTHoWP8N+YH4J8oCOIP80MDQ4DVoIM38rq
	5fYruh9jtDdBAe/wXPMWdDAkhjkviCeRy4xx8wqahTADVh3xVHUj/fxwVlNS
	UaaoZ4yID25a2UDLzY5wG48r+YrIxaYgA9avEh76j//4D7EYeM+zo3+SvTw4
	pD/uHSZvmpz8HbKj0YDf/+3OQyL34UNiAbpvhpOBseTQ8MBoXrSfQ6sb/55P
	/He/H5gJyJEWbw5pF+YAv/JDosDu8rIafAw9D3lgAvzCOpDBzRUyODTLWH61
	m8Wi/FGJIs/+bSOW9wpdFfgEqhk1sOeJXYksnwa+P+IPPPjDKJtMJofyCC9x
	6AlZtt4v1rrgS+tcSNlOGElfiBQZAjLd8XQ7vs6Xm8JrPROnVy8l86rWc8Ev
	6EiiHgEH+Ar/Y0t/RJUHhsUNMx/FjUS6GNvbd8mOBjyI4scOdoZvMO+oDJAy
	AWBx5p9j5LtLNNRmNTDxA+THIA5h1U07Au0WhTX+E27ghw+HxCDlssMvNGlg
	XEAFS3IF8TF784EnAhZYh9Q8diQOIsE3Vs4cFC+40lYp2pCpTmoU6TL0Hctl
	zHxGeGagoNboRprRZFFXjJQUnQ1s1l8LFnMr1JnwUNHmjngOKLEoNLbroiUe
	8rSul0VeYQgGhRqukBQufIsp4aJrNsUFbvIFaIVtcTGB19ARdFk0vddK/p1f
	bfHJ1xtypvWeBC6zzKrNaho9fdahJmofxv0Gmxd0Gq9Sfnf+9fgJzeI0O57P
	4U8thcJenF4/FmXmiy8ffPiAc4bfPpffHj+kH3N+A99/XuHk6NhgAFB6V+WS
	+B3tD36K+TLpsKVMSRgJ2JB0bhld8hFcTZijGojCPHhdRlajvL8EhQ/NLf40
	am/wMZzNOXrwaCF1A3oh/IUiZ3hqaA2qJcanQjMcRTsDlIIuS7T+87Eq5HPS
	NXAp8G94DmUTvMdKysWB2YFRdtoUYAmgw/rwArldcmLIE4GJ4RaEtdHWwH+X
	cyVOmEADc1rXrL3RczCYrvIYZQpGPUD6wewuvv/bOfzlYkQqZLzFuawVB6bv
	wGd/Kpoaz3UFijyMWizF7EJXRjQ/nAlvNY4/IUFA4kxuJDzC7JkiZdd5U5Ii
	D0zqsrsiUkQHM7y1qYaOg46fpwH61oL2rdNNkc+3wHNk3e5r1MPAxqDlAc+6
	qm9UUVD3BvC8WbFGp0ufZ8DylmAtbtAf4HCtM9hlHoyYsf7Rcx+yli7x1Dt0
	2YrJLpzCmwnKD/FTK+ChxBNZATyLrClY0Vtj5bIm8w7YO8Zv2+zeq+/Ozu+N
	+P9nr9/Qf799/ufvXrx9/gz/++zb45cv/X/oE2ffvvnuJfzdyX+FN0/evHr1
	/PUzfhl+zZKfXh3/8z1msPfenJ6/ePP6+OU9VZKcN/mQd7A6Rwwcrorck0gz
	fXpymj1AxvEPwCQePnjwJTAJ/seTB188/vDB3VxhXA0/VlfAH/ifLNzW6yJv
	iPiWILTyddnlZHLDpYcThmMGusD9zN5co3IMVrrQBqrIz/iI3n+yBqY3w8vd
	ik4th2eeDe7HIcPWuyZUb3FhSJrqCiyYa1bqCrBY60aOVZwZwckFTFkpx4/g
	gt8r2+n3OpeJmmejaTo1vY4c6WV7jGJUW5CRoZqIN4sYQQOf3O7wIaNby/t7
	4E3Zt1M1E8/QMhJ1SLxOrFbTd4J/uRbpf4muh3UNEhhYwojPln2q3r7mT7SF
	n4TL2ABjibXKQfUI7oEBpQVpBtmiriZyWYEligyYfEDexI4s1qbsggUJ13ZJ
	u48DJtJ/wG1orDHWDmRR+DZStZzUhM9pUwW3Nxr1eZej55VdEB2I8dW4hsOp
	IkdES7tGKgeMKnPJdRfZg95gDKoSuxp0Y1gmWMh8cVFzWta4MJrFK3aFyodE
	XMElq8HCbtkJFU1FnthIUMRqh6DGovE9z0QHpG8B0cq/2B+Ku7LBRIjllix2
	H+TIgJ7hLEB26S4xGfBeWR1u19pGkZ+X2UpTIOMn55gces7hBRQJm4ZEC7p+
	5PDnG3LX9beMlNXxHF1KVbxsb0wHf0cUveGIAK3izPs6pkV3UxTI21CEoLcj
	8gLL/qJCVbIhk/mIJ7KiKbo7UVvN9D1xZYsxbreIva6kEInGforbi1uEn3gG
	+i9Q7cHp9TM0guxnRN/77LPPUZsXd7ZePFrQ8x9xG8rOO2RIUfH3zkvM4GUm
	kZGzFTEifq88CVM1ytlmmVuHfElmVSckjmZglfCe3fNoCzhgdO9a514LqknT
	dmNSPAa8e7uHA4JZlJebxkvtWbNddxgqWcOmgyWBNoP3IFq6DhMJFuIaMx7Q
	UwXkNWuAHwYtNJzdntnQ03wx9abxAOjkHOTjnKFCuptRthqQWXhlzUeRoGtL
	QZRR1vp4+D1gH0g691gc2DcPWOehD7RANBI7WGwqse757qVuR9KBFxuQBfn8
	Oq8wWiued8vGDZuVnZDgQlvY4wONAJng2QZ09Wbr3HGVRLdK+B2NEb23/tJK
	8ETXCfcqeGdAgZ+ZheJ+23MCZh49ofb7wfv3oBqNI34C++K8cWH8IYkPGgZD
	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==


		<!-- [rfced] Please let us know if any changes are needed for the
		following:

		a) The following terms were used inconsistently in this document. We
		chose to use the latter forms. Please let us know any objections.

		keep alive / keep-alive

		Parameters / parameters (where used generally, e.g., "of
		parameters") (per the rest of this document and the rest of this
		cluster of documents)

		protocol selection properties (1 instance) /
		Protocol Selection Properties (1 instance) (We also found
		24 instances of "Selection Properties".)
		(also per the rest of this cluster)

		b) The following terms appear to be used inconsistently in this
		document. Please let us know which form is preferred.

		enumerated / Enumerated (and enumeration / Enumeration)

		namespace / Namespace (in running text)

		preference / Preference

		type / Type (NOTE MW says ok with type)

		Type Selection Property / Selection Property

		user timeout value / User Timeout value (MW wants User Timeout value"

		c) Are "transport system" and "Transport System" used interchangeably
		with "Transport Services system" and "Transport Services System"?

		We do not see "transport system" or "Transport System" in the other
		two documents in this cluster.

		Please review and let us know any updates in Old/New format (or if
		easier, please feel free to update in the XML itself).

		-->

		<!--[rfced] This document used the <tt> element extensively (and a few
		<em> tags). Please review the list of terms found at
		https://www.rfc-editor.org/authors/rfc9622.tt.txt where we have
		listed the terms as well as if we believe there is possible
		inconsistent use.

		We recommend that the authors make updates to the <tt> tags in
		the xml file itself because of the magnitude.

		-->

		<!--[rfced] Please review the use of the slash "/" character when it
		communicates "and", "or", or "and/or" and consider if using one
		of those alternatives would be clearer for the reader.
	-->	-->

	</rfc>	</rfc>

End of changes. 472 change blocks.
	3150 lines changed or deleted	1430 lines changed or added
This html diff was produced by rfcdiff 1.48.