<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.7 (Ruby 3.2.2) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-taps-interface-26" number="9622" updates="" obsoletes="" submissionType="IETF"  category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.20.0 --> version="3" xml:lang="en">

  <front>
    <title abbrev="TAPS Interface">An Abstract Application-Layer Interface to Transport Services</title>

<!-- [rfced] We had a few questions/comments regarding the title of
     the document:

a) We see the document title uses "Application Layer Interface" while
the Abstract uses "Application Programming Interface (API)".  We do
not see any other uses of "application-layer interface" in the
document.  Please review and let us know if any updates are desirable.

b) We see "TAPS Interface" is used as the short title.  We do not see
TAPS used or expanded in the document anywhere else.  Should it be?
(Note - RFC 9621 we have added the expansion to the mention of the
working group in the Acknowledgments.)

c) FYI - Because "Application Layer" is used as a modifier in
attributive position in the document title, we hyphenated it.  Please
let us know any objections.

Original:
 An Abstract Application Layer Interface to Transport Services</title> Services

Currently:
  An Abstract Application-Layer Interface to Transport Services -->

    <seriesInfo name="Internet-Draft" value="draft-ietf-taps-interface-26"/> name="RFC" value="9622"/>
    <author initials="B." surname="Trammell" fullname="Brian Trammell" role="editor">
      <organization>Google Switzerland GmbH</organization>
      <address>
        <postal>
          <street>Gustav-Gull-Platz 1</street>
          <city>8004 Zurich</city>
          <city>Zurich</city><code>8004</code>
          <country>Switzerland</country>
        </postal>
        <email>ietf@trammell.ch</email>
      </address>
    </author>
    <author initials="M." surname="Welzl" fullname="Michael Welzl" role="editor">
      <organization>University of Oslo</organization>
      <address>
        <postal>
          <street>PO Box 1080 Blindern</street>
          <city>0316  Oslo</city>
          <city>Oslo</city><code>0316</code>
          <country>Norway</country>
        </postal>
        <email>michawe@ifi.uio.no</email>
      </address>
    </author>
    <author initials="R." surname="Enghardt" fullname="Reese Enghardt">
      <organization>Netflix</organization>
      <address>
        <postal>
          <street>121 Albright Way</street>
          <city>Los Gatos, CA 95032</city> Gatos</city><region>CA</region><code>95032</code>
          <country>United States of America</country>
        </postal>
        <email>ietf@tenghardt.net</email>
      </address>
    </author>
    <author initials="G." surname="Fairhurst" fullname="Godred Fairhurst">
      <organization>University of Aberdeen</organization>
      <address>
        <postal>
          <street>Fraser Noble Building</street>
          <city>Aberdeen, AB24 3UE</city>
          <country>United Kingdom</country>
<!--  <country>Scotland</country> Changed to United Kingdom,
      per RFCs 9268 and 9435 -->
        </postal>
        <email>gorry@erg.abdn.ac.uk</email>
        <uri>http://www.erg.abdn.ac.uk/</uri>
        <uri>https://erg.abdn.ac.uk/</uri>
      </address>
    </author>
    <author initials="M." surname="Kuehlewind" surname="Kühlewind" fullname="Mirja Kuehlewind"> Kühlewind">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Ericsson-Allee 1</street>
          <city>Herzogenrath</city>
          <country>Germany</country>
        </postal>
        <email>mirja.kuehlewind@ericsson.com</email>
      </address>
    </author>
    <author initials="C." initials="C. S." surname="Perkins" fullname="Colin S. Perkins">
      <organization>University of Glasgow</organization>
      <address>
        <postal>
          <street>School of Computing Science</street>
          <city>Glasgow  G12 8QQ</city>
          <city>Glasgow</city><code>G12 8QQ</code>
          <country>United Kingdom</country>
        </postal>
        <email>csp@csperkins.org</email>
      </address>
    </author>
    <author initials="P." surname="Tiesel" fullname="Philipp S. Tiesel">
      <organization>SAP SE</organization>
      <address>
        <postal>
          <street>George-Stephenson-Straße 7-13</street>
          <city>10557 Berlin</city>
          <city>Berlin</city><code>10557</code>
          <country>Germany</country>
        </postal>
        <email>philipp@tiesel.net</email>
      </address>
    </author>

<!-- [rfced] In this document and in draft-ietf-taps-impl, we
see "P. Tiesel" on the first page but "Philipp S. Tiesel" in the
Authors' Addresses section.  How should Philipp's name be listed in
published RFCs going forward - "P. Tiesel" and "Philipp Tiesel", or
"P. S. Tiesel" and "Philipp S. Tiesel"?

Original (both documents):
 P. Tiesel
...
 Philipp S. Tiesel -->

    <author initials="T." surname="Pauly" fullname="Tommy Pauly">
      <organization>Apple Inc.</organization>
      <address>
        <postal>
          <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>
        </postal>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <date year="2024" month="March" day="17"/>
    <workgroup>TAPS Working Group</workgroup>
    <keyword>Internet-Draft</keyword> month="November"/>
    <area>WIT</area>
    <workgroup>taps</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->

<keyword>example</keyword>

    <abstract>
      <?line 117?>
<t>This document describes an abstract application programming interface, API, Application Programming Interface (API) to the transport
layer that enables the selection of transport protocols and
network paths dynamically at runtime. This API enables faster deployment
of new protocols and protocol features without requiring changes to the
applications. The specified API follows the Transport Services architecture
by providing asynchronous, atomic transmission of messages. It is intended to replace the
BSD sockets Socket API as the common interface to the
transport layer, in an environment where endpoints could select from
multiple network paths and potential transport protocols.</t>
    </abstract>
  </front>
  <middle>
    <?line 129?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>This document specifies an abstract application programming interface Application Programming Interface (API) that describes the interface component of
the high-level Transport Services architecture defined in
<xref target="I-D.ietf-taps-arch"/>. target="RFC9621"/>. A Transport Services system supports
asynchronous, atomic transmission of messages over transport protocols and
network paths dynamically selected at runtime, in environments where an endpoint
selects from multiple network paths and potential transport protocols.</t>
      <t>Applications that adopt this API will benefit from a wide set of
transport features that can evolve over time. This protocol-independent API ensures that the system
providing the API can optimize its behavior based on the application
requirements and network conditions, without requiring changes to the
applications.  This flexibility enables faster deployment of new features and
protocols,
protocols and can support applications by offering racing and fallback
mechanisms, which otherwise need to be separately implemented in each application.
Transport Services Implementations are free to take any desired form as long
as the API specification in this document is honored; a nonprescriptive non-prescriptive guide to
implementing a Transport Services system is available (see <xref target="I-D.ietf-taps-impl"/>.</t> target="RFC9623"/>).</t>
      <t>The Transport Services system derives specific path and protocol selection
properties Protocol Selection
Properties and supported transport features from the analysis provided in
<xref target="RFC8095"/>, <xref target="RFC8923"/>, and
<xref target="RFC8922"/>. The Transport Services API enables an implementation
to dynamically choose a transport protocol rather
than statically binding applications to a protocol at
compile time. The Transport Services API also provides
applications with a way to override transport selection and instantiate a specific stack,
e.g., to support servers wishing to listen to a specific protocol. However, forcing a
choice to use a specific transport stack is discouraged for general use, use because it can reduce portability.</t>
      <section anchor="notation">
        <name>Terminology and Notation</name>
        <t>The Transport Services API is described in terms of</t> of:</t>
        <ul spacing="normal">
          <li>
            <t>Objects with which an application can interact;</t>
          </li>
          <li>
            <t>Actions the application can perform on these objects;</t>
          </li>
          <li>
            <t>Events, which an object can send to an application to be processed asynchronously; and</t>
          </li>
          <li>
            <t>Parameters associated with these actions and events.</t>
          </li>
        </ul>
        <t>The following notations, which can be combined, are used in this document:</t>
        <ul spacing="normal">
          <li>
            <t>An

            <li><t>An action that creates an object:</t>
          </li> object:</t></li>
        </ul>
        <artwork><![CDATA[
      Object := Action()
]]></artwork>

        <ul spacing="normal">
          <li>
            <t>An
            <li><t>An action that creates an array of objects:</t>
          </li> objects:</t></li>
	</ul>
        <artwork><![CDATA[
      []Object := Action()
]]></artwork>

        <ul spacing="normal">
          <li>
            <t>An
            <li><t>An action that is performed on an object:</t>
          </li> object:</t></li>
	</ul>
        <artwork><![CDATA[
      Object.Action()
]]></artwork>

        <ul spacing="normal">
          <li>
            <t>An
            <li><t>An object sends an event:</t>
          </li> event:</t></li>
	</ul>

        <artwork><![CDATA[
      Object -> Event<>
]]></artwork>

        <ul spacing="normal">
          <li>
            <t>An
            <li><t>An action takes a set of Parameters; parameters; an event contains a set of Parameters.
action parameters.
Action and event parameters whose names are suffixed with a question mark are optional.</t>
          </li> optional:</t></li>
	</ul>

       <artwork><![CDATA[
      Action(param0, param1?, ...)
      Event<param0, param1?, ...>
]]></artwork>

<!--[rfced] Could this text be reworded as follows?

Original:
Actions associated with no object are actions on the API;...

Perhaps:
Actions not associated with an object are actions on the API;..
-->

        <t>Objects that are passed as parameters to actions use call-by-value behavior.
Actions associated with no object are actions on the API; they are equivalent to actions on a per-application global context.</t>
        <t>Events are sent to the application or application-supplied code (e.g. framers, (e.g., framers;
see <xref target="framing"/>) for processing; the details of event interfaces are platform-
and implementation-specific, specific to the platform or
implementation and can be implemented using
other forms of asynchronous processing, as idiomatic for the
implementing platform.</t>
        <t>We also make use of the following basic types:</t>
        <ul
        <dl spacing="normal">
          <li>
            <t>Boolean:

            <dt>Boolean:</dt><dd> Instances take the value <tt>true</tt> or <tt>false</tt>.</t>
          </li>
          <li>
            <t>Integer: <tt>false</tt>.</dd>

            <dt>Integer:</dt><dd> Instances take integer values.</t>
          </li>
          <li>
            <t>Numeric: values.</dd>

            <dt>Numeric:</dt><dd> Instances take real number values.</t>
          </li>
          <li>
            <t>String: values.</dd>

            <dt>String:</dt><dd> Instances are represented in UTF-8.</t>
          </li>
          <li>
            <t>IP Address: UTF-8.</dd>

            <dt>IP Address:</dt><dd> An IPv4 address <xref target="RFC791"/> or IPv6 address <xref target="RFC4291"/> address.</t>
          </li>
          <li>
            <t>Enumeration: target="RFC4291"/>.</dd>

            <dt>Enumeration:</dt><dd> A family of types in which each instance takes one of a fixed,
predefined set of values specific to a given enumerated type.</t>
          </li>
          <li>
            <t>Tuple: type.</dd>

            <dt>Tuple:</dt><dd> An ordered grouping of multiple value types, represented as a
comma-separated list in parentheses, e.g., <tt>(Enumeration, Preference)</tt>.
Instances take a sequence of values values, each valid for the corresponding value
type.</t>
          </li>
          <li>
            <t>Array:
type.</dd>

            <dt>Array:</dt><dd> Denoted <tt>[]Type</tt>, an instance takes a value for each of zero or more
elements in a sequence of the given Type. An array can be of fixed or
variable length.</t>
          </li>
          <li>
            <t>Set: length.</dd>

            <dt>Set:</dt><dd> An unordered grouping of one or more different values of the same type.</t>
          </li>
        </ul> type.</dd>

        </dl>
        <t>For guidance on how these abstract concepts can be implemented in languages
in accordance with language-specific design patterns and platform features,
see <xref target="implmapping"/>.</t>
      </section>
      <section anchor="specification-of-requirements">
        <name>Specification of Requirements</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
        "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
        "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
        "<bcp14>SHOULD NOT</bcp14>",
        "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
        "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in BCP 14 BCP&nbsp;14
        <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="principles">
      <name>Overview of the API Design</name>
      <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
defined in <xref target="I-D.ietf-taps-arch"/>. target="RFC9621"/>. The API defined in this document
provides:</t>
<ul spacing="normal">

<!--[rfced] Please review the use of "written to"; should this be
     "written for"?

Original:
This enables applications written to a single API to make use of
transport protocols in terms of the features they provide.

Perhaps:
This enables applications written for a single API to make use of
transport protocols in terms of the features they provide.
-->

        <li>
          <t>A Transport Services system that
can offer a variety of transport protocols, independent
of the Protocol Stacks that will be used at
runtime. To the degree possible, all common features of these protocol
stacks Protocol
Stacks are made available to the application in a
transport-independent way.
This enables applications written to a single API
to make use of transport protocols in terms of the features
they provide.</t>
        </li>
        <li>
          <t>A unified API to datagram and stream-oriented transports, allowing
the use of a common API for Connection establishment and closing.</t>
        </li>
        <li>
          <t>Message-orientation,
          <t>Message orientation, as opposed to stream orientation, using
application-assisted framing and deframing where the underlying transport
does not provide these.

<!-- [rfced] Section 2: To what does "these" refer in this sentence
     (framing and deframing)?

Original:
 *  Message-orientation, as opposed to stream-orientation, using
    application-assisted framing and deframing where the underlying
    transport does not provide these.</t> these. -->

</t>
        </li>
        <li>
          <t>Asynchronous Connection establishment, transmission, and reception.
This allows concurrent operations during establishment and event-driven
application interactions with the transport layer.</t>
        </li>
        <li>
          <t>Selection between alternate network paths, using additional information about the
networks over which a Connection can operate (e.g. (e.g., Provisioning Domain (PvD)
information <xref target="RFC7556"/>) where available.</t>
        </li>
        <li>
          <t>Explicit support for transport-specific features to be applied, when that
particular transport is part of a chosen Protocol Stack.</t>
        </li>
        <li>
          <t>Explicit support for security properties as first-order transport features.</t>
        </li>
        <li>
          <t>Explicit support for configuration of cryptographic identities and transport
security parameters persistent across multiple Connections.</t>
        </li>
        <li>
          <t>Explicit support for multistreaming and multipath transport protocols, and
the grouping of related Connections into Connection Groups through "cloning"
of Connections (see <xref target="groups"/>). This function allows applications to take full advantage of new
transport protocols supporting these features.</t>
        </li>
      </ul>
    </section>
    <section anchor="api-summary">
      <name>API Summary</name>
      <t>An application primarily interacts with this API through two objects:
Preconnections and Connections. A Preconnection object (<xref target="pre-establishment"/>)
represents a set of properties and constraints on the selection and configuration of
paths and protocols to establish a Connection with an Endpoint. A Connection object
represents an instance of a transport Protocol Stack on which data can be sent to and/or
received from a Remote Endpoint (i.e., a logical connection that, depending on the
kind of transport, can be bi-directional bidirectional or unidirectional, and that can use a stream
protocol or a datagram protocol). Connections are presented consistently to the
application, irrespective of whether the underlying transport is connection-less connectionless or
connection-oriented.
connection oriented. Connections can be created from Preconnections in three ways:</t>
      <ul spacing="normal">
        <li>
          <t>by initiating
          <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>
          <t>by listening
          <t>listening on the Preconnection (i.e., creating a Listener based on the Preconnection, passively opening, as in a server; see Listen() in <xref target="listen"/>),</t> target="listen"/>), or</t>
        </li>
        <li>
          <t>or by a
          <t>a rendezvous for the Preconnection (i.e., peer to peer peer-to-peer connection establishment; see Rendezvous() in <xref target="rendezvous"/>).</t>
        </li>
      </ul>
      <t>Once a Connection is established, data can be sent and received on it in the form of
Messages. The API supports the preservation of message boundaries both via both
explicit Protocol Stack support, support and via application support through a
Message Framer that finds message boundaries in a stream. Messages are
received asynchronously through event handlers registered by the application.
Errors and other notifications also happen asynchronously on the Connection.
It is not necessary for an application to handle all events; some events can
have implementation-specific default handlers.</t>
      <t>The application SHOULD NOT <bcp14>SHOULD NOT</bcp14>
assume that ignoring events (e.g., errors) is always safe.</t>
      <section anchor="usage-examples">
        <name>Usage Examples</name>
        <t>The following usage examples illustrate how an application might use the
Transport Services API to:</t> to act as:</t>
        <ul spacing="normal">
          <li>
            <t>Act as a
            <t>a server, by listening for incoming Connections, receiving requests,
and sending responses, responses; see <xref target="server-example"/>.</t>
          </li>
          <li>
            <t>Act as a
            <t>a client, by connecting to a Remote Endpoint using <tt>Initiate</tt>, sending
requests, and receiving responses, responses; see <xref target="client-example"/>.</t>
          </li>
          <li>
            <t>Act as a
            <t>a peer, by connecting to a Remote Endpoint using Rendezvous while
simultaneously waiting for incoming Connections, sending Messages, and
receiving Messages, Messages; see <xref target="peer-example"/>.</t>
          </li>
        </ul>
        <t>The examples in this section presume that a transport protocol is available
between the Local and Remote Endpoints and that this protocol provides Reliable Data Transfer, Preservation reliable data transfer, preservation of
Data Ordering,
data ordering, and Preservation preservation of Message Boundaries. message boundaries. In this case, the
application can choose to receive only complete Messages.</t>
        <t>If none of the available transport protocols provides Preservation provide preservation of Message
Boundaries, message
boundaries, but there is a transport protocol that provides a reliable ordered
byte-stream, an application could receive this byte-stream as partial
Messages and transform it into application-layer Messages.  Alternatively,
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>
        <section anchor="server-example">
          <name>Server Example</name>
          <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>
          <artwork><![CDATA[
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithInterface("any")
LocalSpecifier.WithService("https")

TransportProperties := NewTransportProperties()
TransportProperties.Require(preserveMsgBoundaries)
// Reliable Data Transfer data transfer and Preserve Order preserve order are Required required by default

SecurityParameters := NewSecurityParameters()
SecurityParameters.Set(serverCertificate, myCertificate)

// Specifying a Remote Endpoint is optional when using Listen
Preconnection := NewPreconnection(LocalSpecifier,
                                  TransportProperties,
                                  SecurityParameters)

Listener := Preconnection.Listen()

Listener -> ConnectionReceived<Connection>

// Only receive complete messages in a Conn.Received handler
Connection.Receive()

Connection -> Received<messageDataRequest, messageContext>

//---- Receive event handler begin ----
Connection.Send(messageDataResponse)
Connection.Close()

// Stop listening for incoming Connections
// (this example supports only one Connection)
Listener.Stop()
//---- Receive event handler end ----
]]></artwork>
        </section>
        <section anchor="client-example">
          <name>Client Example</name>
          <t>This

<!--[rfced] Could this sentence be rephrased as follows?

Original:
   This is an example of how an application might open two Connections
   to a remote application using the Transport Services API, and send
   a request as well as receive a response on each of them.

Perhaps:
   This is an example of how an application might open two Connections
   to a remote application using the Transport Services API, send a
   request, and receive a response for each of the two Connections.
-->

          <t>This is an example of how an application might open two Connections to a remote application
using the Transport Services API and send a request as well as receive a response on each of them.
The code designated with comments as "Ready event handler" could, e.g., for example, be implemented
as a callback function, for example. function. This function would receive the Connection that it expects
to operate on ("Connection" and "Connection2" in the example), example) handed over using the variable
name "C".</t>
          <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithHostName("example.com")
RemoteSpecifier.WithService("https")

TransportProperties := NewTransportProperties()
TransportProperties.Require(preserve-msg-boundaries)
// Reliable Data Transfer data transfer and Preserve Order preserve order are Required required by default

SecurityParameters := NewSecurityParameters()
TrustCallback := NewCallback({
  // Verify the identity of the Remote Endpoint, Endpoint and return the result
})
SecurityParameters.SetTrustVerificationCallback(TrustCallback)

// Specifying a Local Endpoint is optional when using Initiate
Preconnection := NewPreconnection(RemoteSpecifier,
                                  TransportProperties,
                                  SecurityParameters)

Connection := Preconnection.Initiate()
Connection2 := Connection.Clone()

Connection -> Ready<>
Connection2 -> Ready<>

//---- Ready event handler for any Connection C begin ----
C.Send(messageDataRequest)

// Only receive complete messages
C.Receive()
//---- Ready event handler for any Connection C end ----

Connection -> Received<messageDataResponse, messageContext>
Connection2 -> Received<messageDataResponse, messageContext>

// Close the Connection in a Receive event handler
Connection.Close()
Connection2.Close()
]]></artwork>
          <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 or not this Connection was closed or not. closed. Hence, in the above example, it would be correct for the client to initiate a third Connection to the example.com server by continuing as follows:</t>
          <artwork><![CDATA[
//.. carry out adjustments to the Preconnection, if desired
Connection3 := Preconnection.Initiate()
]]></artwork>
        </section>
        <section anchor="peer-example">
          <name>Peer Example</name>
          <t>This is an example of how an application might establish a Connection with a
peer using <tt>Rendezvous</tt>, send a Message, and receive a Message.</t>
          <artwork><![CDATA[
// Configure local candidates: a port on the Local Endpoint
// and via a STUN Session Traversal Utilities for NAT (STUN) server
HostCandidate := NewLocalEndpoint()
HostCandidate.WithPort(9876)

StunCandidate := NewLocalEndpoint()
StunCandidate.WithStunServer(address, port, credentials)

LocalCandidates = [HostCandidate, StunCandidate]

TransportProperties := // ...Configure transport properties
SecurityParameters  := // ...Configure security properties

Preconnection := NewPreconnection(LocalCandidates,
                                  [], // No remote candidates yet
                                  TransportProperties,
                                  SecurityParameters)

// Resolve the LocalCandidates.  The Preconnection.Resolve()
// call resolves both local and remote candidates but, since candidates; however,
// because the remote candidates have not yet been specified, the
// the ResolvedRemote list returned will be empty and is not
// used.
ResolvedLocal, ResolvedRemote = Preconnection.Resolve()

// Application-specific code goes here to send the ResolvedLocal
// list to the peer via some out-of-band signalling signaling channel (e.g.,
// in a SIP message) message).
...

// Application-specific code goes here to receive RemoteCandidates
// (type []RemoteEndpoint, a list of RemoteEndpoint objects) from
// the peer via the signalling channel signaling channel.
...

// Add remote candidates and initiate the rendezvous:
Preconnection.AddRemote(RemoteCandidates)
Preconnection.Rendezvous()

Preconnection -> RendezvousDone<Connection>

//---- RendezvousDone event handler begin ----
Connection.Send(messageDataRequest)
Connection.Receive()
//---- RendezvousDone event handler end ----

Connection -> Received<messageDataResponse, messageContext>

// If new Remote Endpoint candidates are received from the
// peer over the signalling channel, signaling channel -- for example example, if using
// Trickle ICE, Interactive Connectivity Establishment (ICE) --
// then add them to the Connection:
Connection.AddRemote(NewRemoteCandidates)

// On a PathChange<> event, resolve the Local Endpoint Identifiers to
// see if a new Local Endpoint has become available and, if
// so, send to the peer as a new candidate and add to the
// Connection:
Connection -> PathChange<>

//---- PathChange event handler begin ----
ResolvedLocal, ResolvedRemote = Preconnection.Resolve()
if ResolvedLocal has changed:
  // Application-specific code goes here to send the
  // ResolvedLocal list to the peer via signalling the signaling channel
  ...

  // Add the new Local Endpoints to the Connection:
  Connection.AddLocal(ResolvedLocal)
//---- PathChange event handler end ----

// Close the Connection in a Receive event handler handler:
Connection.Close()
]]></artwork>

<!-- [rfced] Section 3.1.3: Should "if ResolvedLocal has changed:" be
     set off as a comment?

Original:
 if ResolvedLocal has changed:

Possibly:
 // If ResolvedLocal has changed: -->

        </section>
      </section>
    </section>
    <section anchor="transport-properties">
      <name>Transport Properties</name>
      <t>Each application using the Transport Services API declares its preferences
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"/>, target="RFC9621"/>, at each stage
of the lifetime of a Connection.</t>
      <t>Transport Properties are divided into Selection, Connection, and Message
Properties.</t>
      <t>Selection Properties (see <xref target="selection-props"/>) can only be set
during pre-establishment. preestablishment. They are only used to specify which paths and
Protocol Stacks can be used and are preferred by the application.
Calling <tt>Initiate</tt> on a Preconnection creates an outbound Connection,
and the Selection Properties remain readable from the
Connection,
Connection but become immutable. Selection Properties
can be set on Preconnections, and the effect of Selection Properties
can be queried on Connections and Messages.</t>
      <t>Connection Properties (see <xref target="connection-props"/>) are used to inform
decisions made during establishment and to fine-tune the established
Connection. They can be set during pre-establishment, preestablishment and can be
changed later. Connection Properties can be set on Connections and
Preconnections; when set on Preconnections, they act as an initial
default for the resulting Connections.</t>
      <t>Message Properties (see <xref target="message-props"/>) control the behavior of the
selected protocol stack(s) Protocol Stack(s) when sending Messages. Message Properties
can be set on Messages, Connections, and Preconnections; when set on
the latter two, they act as an initial default for the Messages sent
over those Connections.</t>
      <t>Note that configuring Connection Properties and Message Properties on
Preconnections is preferred over setting them later. Early specification of
Connection Properties allows their use as additional input to the selection
process. Protocol-specific Properties, which enable configuration of specialized
features of a specific protocol (see <xref section="3.2" sectionFormat="of" target="I-D.ietf-taps-arch"/>) target="RFC9621"/>), are not
used as an input to the selection process, but process; they only support configuration if
the respective protocol has been selected.</t>
      <section anchor="property-names">
        <name>Transport Property Names</name>
        <t>Transport Properties are referred to by property names, represented as case-insensitive strings. These names serve two purposes:</t>
        <ul spacing="normal">
          <li>
            <t>Allowing different components of a Transport Services Implementation to pass Transport
Properties, e.g., between a language frontend front end and a policy manager, manager
or as a representation of properties retrieved from a file or other storage.</t>
          </li>
          <li>
            <t>Making the code of different Transport Services Implementations look similar.
While individual programming languages might preclude strict adherence to the
aforementioned naming convention (for instance, by prohibiting the use of hyphens
in symbols), users interacting with multiple implementations will still benefit
from the consistency resulting from the use of visually similar symbols.</t>
          </li>

<!-- [rfced] Section 4.1: We had trouble following the text in this
     bullet list.  In the first bullet, what does "as a
     representation" refer to?  In the second bullet, what does "the
     aforementioned naming convention" refer to?

Original:
 *  Allowing different components of a Transport Services
    Implementation to pass Transport Properties, e.g., between a
    language frontend and a policy manager, or as a representation of
    properties retrieved from a file or other storage.

 *  Making the code of different Transport Services Implementations
    look similar.  While individual programming languages might
    preclude strict adherence to the aforementioned naming convention
    (for instance, by prohibiting the use of hyphens in symbols),
    users interacting with multiple implementations will still benefit
    from the consistency resulting from the use of visually similar
    symbols. -->

        </ul>
        <t>Transport Property Names are hierarchically organized in the
form [&lt;Namespace&gt;.]&lt;PropertyName&gt;.</t>
        <ul spacing="normal">
          <li>
            <t>The optional Namespace component and its trailing character <tt>.</tt> <bcp14>MUST</bcp14> be omitted for well-known,
generic properties, i.e., for properties that are not specific to a protocol.

<!-- [rfced] Section 4.1: May we update this use of the period as
     follows (both for the ease of the reader and for consistency with
     the RFC series)?

If yes to quoting, may we also change 'underscore _ character' a few
lines later to 'underscore ("_") character'?

Original:
 *  The optional Namespace component and its trailing character . MUST
    be omitted for well-known, generic properties, i.e., for
    properties that are not specific to a protocol.</t> protocol.

Possibly:
 *  The optional Namespace component and its trailing dot character (".")
    MUST be omitted for well-known, generic properties, i.e., for
    properties that are not specific to a protocol. -->

</t>
          </li>
          <li>
            <t>Protocol-specific Properties MUST <bcp14>MUST</bcp14> use the protocol acronym as the Namespace (e.g., a
Connection that uses TCP could support a TCP-specific Transport Property, such as the TCP user timeout User Timeout
value, in a Protocol-specific Property called <tt>tcp.userTimeoutValue</tt> (see <xref target="tcp-uto"/>)).</t>
          </li>
          <li>
            <t>Vendor
            <t>Vendor-specific or implementation specific implementation-specific properties MUST <bcp14>MUST</bcp14> be placed in a Namespace starting with the underscore <tt>_</tt> character
 and SHOULD <bcp14>SHOULD</bcp14> use a string identifying the vendor or implementation.</t>
          </li>
          <li>
            <t>For

<!--[rfced] May we update this text to make it as clear to the reader
     as possible?  Should further specification about what type of
     review the IETF gives be listed (or by whom/what role in the
     IETF)?  Note also our other query regarding the "underscore
     character".

Original:

   *  For IETF protocols, the name of a Protocol-specific Property MUST
      be specified in an IETF document published in the RFC Series after
      IETF review.  An IETF protocol Namespace does not start with an
      underscore character.

Perhaps:

   *  For IETF protocols, the name of a Protocol-specific Property MUST
      be specified in an RFC from the IETF Stream (after
      IETF review).  An IETF protocol Namespace does not start with an
      underscore character.

-->

            <t>For IETF protocols, the name of a Protocol-specific Property <bcp14>MUST</bcp14> be specified in an IETF document published in the RFC Series after IETF review.
An IETF protocol Namespace does not start with an underscore character.</t>
          </li>
        </ul>
        <t>Namespaces for each of the keywords provided in the IANA protocol numbers "Protocol Numbers" registry
(see https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml) <eref brackets="angle" target="https://www.iana.org/assignments/protocol-numbers/"/>) are reserved
for Protocol-specific Properties and MUST NOT <bcp14>MUST NOT</bcp14> be used for vendor vendor-specific or implementation-specific properties.
Terms listed as keywords keywords, as in the protocol numbers registry SHOULD "Protocol Numbers" registry, <bcp14>SHOULD</bcp14> be avoided as any part of a vendor- vendor-specific or
implementation-specific property name.</t>
        <t>Though Transport Property Names are case-insensitive, case insensitive, it is recommended to use camelCase to improve readability.
Implementations may transpose Transport Property Names into snake_case or PascalCase to blend into the language environment.</t>
      </section>
      <section anchor="property-types">
        <name>Transport Property Types</name>
        <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,
and they use the Preference Enumeration, which takes one of five possible values
(Prohibit, Avoid, No Preference, Prefer, or Require) denoting the level of preference
for a given property during protocol selection.</t>
      </section>
    </section>
    <section anchor="scope-of-interface-defn">
      <name>Scope of the API Definition</name>
      <t>This document defines a language- and platform-independent API of a
Transport Services system. Given the wide variety of languages and language
conventions used to write applications that use the transport layer to connect
to other applications over the Internet, this independence makes this API
necessarily abstract.</t>
      <t>There is no interoperability benefit in tightly defining how the API is
presented to application programmers across diverse platforms. However,
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
apply their knowledge to another platform. That said, implementations have
significant freedom in presenting this API to programmers, balancing the
conventions of the protocol with the shape of the API. We make the following
recommendations:</t>
      <ul spacing="normal">
        <li>
          <t>Actions, events, and errors in implementations of the Transport Services API <bcp14>SHOULD</bcp14> use
the names given for them in the document, subject to capitalization,
punctuation, and other typographic conventions in the language of the
implementation, unless the implementation itself uses different names for
substantially equivalent objects for networking by convention.

<!-- [rfced] Section 5:  Does "names given for them in the document"
mean "names assigned to them in this document" or something else?
Please clarify.

Original:
 *  Actions, events, and errors in implementations of the Transport
    Services API SHOULD use the names given for them in the document,
    subject to capitalization, punctuation, and other typographic
    conventions in the language of the implementation, unless the
    implementation itself uses different names for substantially
    equivalent objects for networking by convention.</t> convention. -->

</t>
        </li>
        <li>
          <t>Transport Services systems SHOULD <bcp14>SHOULD</bcp14> implement each Selection Property,
Connection Property, and Message Context Property specified in this document.
These features SHOULD <bcp14>SHOULD</bcp14> be implemented even when when, in a specific implementation implementation, it
will always result in no operation, e.g. e.g., there is no action when the API
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 protocol,
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 order
for Connections over TCP. Similarly, the <tt>msgLifetime</tt> Message Property can be
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>
<!-- Above-quoted text is DNE text from Section 9.1.3.1 -->
        </li>
        <li>
          <t>Implementations can use other representations for Transport Property Names,
e.g., by providing constants, but should provide a straight-forward straightforward mapping
between their representation and the property names specified here.</t>
        </li>
      </ul>
    </section>
    <section anchor="pre-establishment">
      <name>Pre-Establishment
      <name>Preestablishment Phase</name>
      <t>The pre-establishment preestablishment phase allows applications to specify properties for
the Connections that they are about to make, make or to query the API about potential
Connections they could make.</t>
      <t>A Preconnection object represents a potential Connection. It is a passive object
(a data structure) that merely maintains the state that
describes the properties of a Connection that might exist in the future.  This state
comprises Local Endpoint and Remote Endpoint objects that denote the endpoints
of the potential Connection (see <xref target="endpointspec"/>), the Selection Properties
(see <xref target="selection-props"/>), any preconfigured Connection Properties
(<xref target="connection-props"/>), and the security parameters (see
<xref target="security-parameters"/>):</t>
      <artwork><![CDATA[
   Preconnection := NewPreconnection([]LocalEndpoint,
                                     []RemoteEndpoint,
                                     TransportProperties,
                                     SecurityParameters)
]]></artwork>
      <t>At least one Local Endpoint MUST <bcp14>MUST</bcp14> be specified if the Preconnection is used to <tt>Listen</tt>
for incoming Connections, but the list of Local Endpoints MAY <bcp14>MAY</bcp14> be empty if
the Preconnection is used to <tt>Initiate</tt>
connections. If no Local Endpoint is specified, the Transport Services system will
assign an ephemeral local port to the Connection on the appropriate interface(s).
At least one Remote Endpoint MUST <bcp14>MUST</bcp14> be specified if the Preconnection is used
to <tt>Initiate</tt> Connections, but the list of Remote Endpoints MAY <bcp14>MAY</bcp14> be empty if
the Preconnection is used to <tt>Listen</tt> for incoming Connections.
At least one Local Endpoint and one Remote Endpoint MUST <bcp14>MUST</bcp14> be specified if a
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 the application
 is indicating that all of the Local Endpoints are eligible to be used for Connections. For
 example, their Endpoint Identifiers might correspond to different interfaces on a multi-homed
host, multihomed
host or their Endpoint Identifiers might correspond to local interfaces and a STUN server that
can be resolved to a server reflexive server-reflexive address for a Preconnection used to
make a peer-to-peer <tt>Rendezvous</tt>.</t>
      <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
offer an equivalent service, service and that the Transport Services system can choose
any of them for a Connection.
For example, a Remote Endpoint might represent various network
interfaces of a host, or a server reflexive server-reflexive address that can be used to
reach a host, or a set of hosts that provide equivalent local balanced
service.</t>
      <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
(see <xref target="initiate"/>) will internally resolve that name to a list of concrete
Endpoint Identifers. Identifiers. Specifying multiple Remote Endpoints on a Preconnection allows
applications to override this for more detailed control.</t>
      <t>If Message Framers are used (see <xref target="framing"/>), they MUST <bcp14>MUST</bcp14> be added to the
Preconnection during pre-establishment.</t> preestablishment.</t>
      <section anchor="endpointspec">
        <name>Specifying Endpoints</name>
        <t>The Transport Services API uses the Local Endpoint and Remote Endpoint objects
to refer to the endpoints of a Connection. Endpoints can be created
as either remote or local:</t>
        <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint()
LocalSpecifier := NewLocalEndpoint()
]]></artwork>
        <t>A single Endpoint object represents the identity of a network host. That endpoint
can be more or less specific specific, depending on which Endpoint Identifiers are set. For example,
an Endpoint that only specifies a hostname can, in fact, finally correspond
to several different IP addresses on different hosts.</t>
        <t>An Endpoint object can be configured with the following identifiers:</t>
        <ul spacing="normal">
          <li>
            <t>HostName (string):</t>
          </li>

           <li><t>HostName (string):</t></li>
	</ul>
        <artwork><![CDATA[
RemoteSpecifier.WithHostName("example.com")
]]></artwork>

        <ul spacing="normal">
          <li>
            <t>Port
            <li><t>Port (a 16-bit unsigned Integer):</t>
          </li> Integer):</t></li>
	</ul>
        <artwork><![CDATA[
RemoteSpecifier.WithPort(443)
]]></artwork>

        <ul spacing="normal">
          <li>
            <t>Service
            <li><t>Service (an identifier string that maps to a port; either a service
name associated with a port number, from https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml, number (from <eref brackets="angle"
target="https://www.iana.org/assignments/service-names-port-numbers/"/>) or a DNS SRV service name to be resolved):</t>
          </li> resolved):</t></li>
	</ul>
        <artwork><![CDATA[
RemoteSpecifier.WithService("https")
]]></artwork>

        <ul spacing="normal">
          <li>
            <t>IP
            <li><t>IP address (an IPv4 or IPv6 address type; note that the examples here show the human-readable form of the IP addresses, but the functions can take a binary encoding of the addresses):</t>
          </li> addresses):</t></li>
	</ul>
       <artwork><![CDATA[
RemoteSpecifier.WithIPAddress(192.0.2.21)
]]></artwork>

       <artwork><![CDATA[
RemoteSpecifier.WithIPAddress(2001:db8:4920:e29d:a420:7461:7073:a)
]]></artwork>

        <ul spacing="normal">
          <li>
            <t>Interface
            <li><t>Interface identifier (which can be a string name or other platform-specific identifier), e.g., to qualify link-local addresses (see <xref target="ifspec"/> for details):</t>
          </li> details):</t></li>
	</ul>

        <artwork><![CDATA[
LocalSpecifier.WithInterface("en0")
]]></artwork>

        <t>The <tt>Resolve</tt> action on a Preconnection can be used to obtain a list of
available local interfaces.</t>
        <t>Note that an IPv6 address specified with a scope zone ID (e.g. (e.g., <tt>fe80::2001:db8%en0</tt>)
is equivalent to <tt>WithIPAddress</tt> with an unscoped address and <tt>WithInterface </tt> together.</t>
        <t>Applications creating Endpoint objects using <tt>WithHostName</tt> SHOULD <bcp14>SHOULD</bcp14> provide fully-qualified
domain names Fully Qualified
Domain Names (FQDNs). Not providing an FQDN will result in the Transport Services Implementation
needing to use DNS search domains for name resolution, which might lead to inconsistent or unpredictable
behavior.</t>
        <t>The design of the API MUST NOT <bcp14>MUST NOT</bcp14> permit an Endpoint object 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
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
that IP address. If, on the other hand, a Remote Endpoint specifies a hostname
but no addresses, the Transport Services Implementation can perform name resolution and attempt
using any address derived from the original hostname of the Remote Endpoint.
Note that multiple Remote Endpoints can be added to a Preconnection, as discussed
in <xref target="add-endpoints"/>.</t>
        <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 Connection. Privacy
considerations for the timing of this resolution are given in <xref target="privacy-security"/>.</t>
        <t>The <tt>Resolve</tt> action on a Preconnection can be used by the application to force
early binding when required, for example example, with some Network Address Translator
(NAT) traversal protocols (see <xref target="rendezvous"/>).</t>
        <section anchor="using-multicast-endpoints">
          <name>Using Multicast Endpoints</name>
          <t>To use multicast, a Preconnection is first created with the Local/Remote Endpoint Identifer Identifier
specifying the any-source multicast Any-Source Multicast (ASM) or source-specific multicast Source-Specific Multicast (SSM) multicast group and destination port number.
This is then followed by a call to either <tt>Initiate</tt>, <tt>Listen</tt>, or
<tt>Rendezvous</tt>
<tt>Rendezvous</tt>, depending on whether the resulting Connection is to be
used to send messages to the multicast group, receive messages from
the group, or, for an any-source multicast group, to or both send and
receive messages.</t> messages (as is the case for an ASM group).</t>
          <t>Note that the Transport Services API has separate specifier calls for multicast groups to avoid introducing filter properties for single-source multicast and seeks to avoid confusion that can be caused by overloading the unicast specifiers.</t> specifiers.

<!-- [rfced] We had two questions related to the abbreviation SSM:

a) Section 6.1.1: Please confirm that "single-source multicast",
rather than "SSM" (for "Source-Specific Multicast"), is correct here.

Original:
 Note that the Transport Services API has separate specifier calls for
 multicast groups to avoid introducing filter properties for single-
 source multicast and seeks to avoid confusion that can be caused by
 overloading the unicast specifiers.

b) Is "multicast" in "multicast group" redundant following the
expansions of ASM and SSM here?  See also clarification of the slash
character.

Original:
   To use multicast, a Preconnection is first created with the Local/
   Remote Endpoint Identifer specifying the any-source multicast (ASM)
   or source-specific multicast (SSM) multicast group and destination
   port number.

Perhaps:
   To use multicast, a Preconnection is first created with the Local or [?]
   Remote Endpoint Identifier specifying the Any-Source Multicast (ASM)
   or Source-Specific Multicast (SSM) group and destination
   port number.
	  -->

</t>
          <t>Calling <tt>Initiate</tt> on that Preconnection creates a Connection that can be
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 created this
way are send-only, send-only and do not join the multicast group. The resulting
Connection will have a Local Endpoint identifying the local interface to
which the Connection is bound and a Remote Endpoint identifying the
multicast group.</t>
          <t>The following API calls can be used to configure a Preconnection before calling <tt>Initiate</tt>:</t>
          <artwork><![CDATA[
RemoteSpecifier.WithMulticastGroupIP(GroupAddress)
RemoteSpecifier.WithPort(PortNumber)
RemoteSpecifier.WithHopLimit(HopLimit)
]]></artwork>

<!--[rfced] In the following, what will join the multicast group?
     Note, other similar instances exist (e.g., Calling Listen...).

Original:

   Calling Rendezvous on a Preconnection with an any-source multicast
   group address as the Remote Endpoint Identifer will
   join the multicast group, and also indicates that the resulting
   Connection can be used to send Messages to the multicast group.

-->

          <t>Calling <tt>Listen</tt> on a Preconnection with a multicast group specified on the Remote
Endpoint will join the multicast group to receive Messages. This Listener
will create one Connection for each Remote Endpoint sending to the group,
with the Local Endpoint Identifer Identifier specified as a group address. The set of Connection
objects created forms a Connection Group.
The receiving interface can be restricted by passing it as part of the LocalSpecifier 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 header 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 before calling <tt>Listen</tt>:</t>
          <artwork><![CDATA[
LocalSpecifier.WithSingleSourceMulticastGroupIP(GroupAddress,
                                                SourceAddress)
LocalSpecifier.WithAnySourceMulticastGroupIP(GroupAddress)
LocalSpecifier.WithPort(PortNumber)
]]></artwork>
          <t>Calling <tt>Rendezvous</tt> on a Preconnection with an any-source multicast ASM group
address as the Remote Endpoint Identifer Identifier will join the multicast group, and also
indicates that the resulting Connection can be used to send Messages to the
	  multicast group. The <tt>Rendezvous</tt> call will return both a both:</t>
	  <ol><li>a Connection that
can be used to send to the group, group and that acts the same as a Connection
returned by calling <tt>Initiate</tt> with a multicast Remote Endpoint, and a Endpoint and</li> <li>a
Listener that acts as if <tt>Listen</tt> had been called with a multicast Remote
Endpoint.
Calling
Endpoint.</li></ol>
<t>Calling <tt>Rendezvous</tt> on a Preconnection with a source-specific multicast an SSM
group address as the Local Endpoint Identifer Identifier results in an <tt>EstablishmentError</tt>.</t>
          <t>The following API calls can be used to configure a Preconnection before calling <tt>Rendezvous</tt>:</t>
          <artwork><![CDATA[
RemoteSpecifier.WithMulticastGroupIP(GroupAddress)
RemoteSpecifier.WithPort(PortNumber)
RemoteSpecifier.WithHopLimit(HopLimit)
LocalSpecifier.WithAnySourceMulticastGroupIP(GroupAddress)
LocalSpecifier.WithPort(PortNumber)
LocalSpecifier.WithHopLimit(HopLimit)
]]></artwork>
          <t>See <xref target="multicast-examples"/> for more examples.</t>
        </section>
        <section anchor="ifspec">
          <name>Constraining Interfaces for Endpoints</name>
          <t>Note that this API has multiple ways to constrain and prioritize endpoint candidates based on the network interface:</t>
          <ul spacing="normal">
            <li>
              <t>Specifying an interface on a Remote Endpoint qualifies the scope zone of the Remote Endpoint, e.g., for link-local addresses.</t>
            </li>
            <li>
              <t>Specifying an interface on a Local Endpoint explicitly binds all candidates derived from this Endpoint to use the specified interface.</t>
            </li>
            <li>
              <t>Specifying an interface using the <tt>interface</tt> Selection Property (<xref target="prop-interface"/>) or indirectly via the <tt>pvd</tt> Selection Property (<xref target="prop-pvd"/>) influences the selection among the available candidates.</t>
            </li>
          </ul>
          <t>While specifying an Interface on an Endpoint restricts the candidates available for Connection establishment in the Pre-Establishment Phase, preestablishment phase, the Selection Properties prioritize and constrain the Connection establishment.</t>
        </section>
        <section anchor="protocol-specific-endpoints">
          <name>Protocol-Specific Endpoints</name>
          <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
on two different port numbers numbers, depending on which protocol is used.</t>
          <t>To scope an Endpoint to apply conditionally to a specific transport
protocol (such as defining an alternate port to use when QUIC
is selected, as opposed to TCP), an Endpoint can be
associated with a protocol identifier. Protocol identifiers are
objects or enumeration values provided by the Transport
Services API, which API that will vary based on which protocols are
implemented in a particular system.</t>
          <artwork><![CDATA[
AlternateRemoteSpecifier.WithProtocol(QUIC)
]]></artwork>
          <t>The following example shows a case where <tt>example.com</tt> has a server
running on port 443, 443 with an alternate port of 8443 for QUIC. Both
endpoints can be passed when creating a Preconnection.</t>
          <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithHostName("example.com")
RemoteSpecifier.WithPort(443)

QUICRemoteSpecifier := NewRemoteEndpoint()
QUICRemoteSpecifier.WithHostName("example.com")
QUICRemoteSpecifier.WithPort(8443)
QUICRemoteSpecifier.WithProtocol(QUIC)

RemoteSpecifiers := [ RemoteSpecifier, QUICRemoteSpecifier ]
]]></artwork>
        </section>
        <section anchor="endpoint-examples">
          <name>Endpoint Examples</name>
          <t>The following examples of Endpoints show common usage patterns.</t>

          <t>Specify a Remote Endpoint using a hostname "example.com" and a service name "https", which tells the system to use the default port for HTTPS (443):</t>
          <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithHostName("example.com")
RemoteSpecifier.WithService("https")
]]></artwork>

          <t>Specify a Remote Endpoint using an IPv6 address and remote port:</t>
          <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithIPAddress(2001:db8:4920:e29d:a420:7461:7073:a)
RemoteSpecifier.WithPort(443)
]]></artwork>

          <t>Specify a Remote Endpoint using an IPv4 address and remote port:</t>
          <artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithIPAddress(192.0.2.21)
RemoteSpecifier.WithPort(443)
]]></artwork>

          <t>Specify a Local Endpoint using a local interface name and no local port, port
to let the system assign an ephemeral local port:</t>
          <artwork><![CDATA[
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithInterface("en0")
]]></artwork>

          <t>Specify a Local Endpoint using a local interface name and local port:</t>
          <artwork><![CDATA[
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithInterface("en0")
LocalSpecifier.WithPort(443)
]]></artwork>

          <t>As an alternative to specifying an interface name for the Local Endpoint, an application
can express more fine-grained preferences using the <tt>Interface Instance or Type</tt>
Selection Property, Property; see <xref target="prop-interface"/>. However, if the application specifies Selection
Properties that are inconsistent with the Local Endpoint, this will result in an error once the
	  application attempts to open a Connection.</t>

          <t>Specify a Local Endpoint using a STUN server:</t>
          <artwork><![CDATA[
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithStunServer(address, port, credentials)
]]></artwork>
        </section>
        <section anchor="multicast-examples">
          <name>Multicast Examples</name>
          <t>The following examples show how multicast groups can be used.</t>
          <t>Join an Any-Source Multicast ASM group in receive-only mode, bound to a known
port on a named local interface:</t>
          <artwork><![CDATA[
   RemoteSpecifier := NewRemoteEndpoint()

   LocalSpecifier := NewLocalEndpoint()
   LocalSpecifier.WithAnySourceMulticastGroupIP(233.252.0.0)
   LocalSpecifier.WithPort(5353)
   LocalSpecifier.WithInterface("en0")

   TransportProperties := ...
   SecurityParameters  := ...

   Preconnection := NewPreconnection(LocalSpecifier,
                                     RemoteSpecifier,
                                     TransportProperties,
                                     SecurityProperties)
   Listener := Preconnection.Listen()
]]></artwork>
          <t>Join a Source-Specific Multicast an SSM group in receive-only mode, bound to a known
port on a named local interface:</t>
          <artwork><![CDATA[
   RemoteSpecifier := NewRemoteEndpoint()

   LocalSpecifier := NewLocalEndpoint()

   LocalSpecifier.WithSingleSourceMulticastGroupIP(233.252.0.0,
                                                   198.51.100.10)
   LocalSpecifier.WithPort(5353)
   LocalSpecifier.WithInterface("en0")

   TransportProperties := ...
   SecurityParameters  := ...

   Preconnection := NewPreconnection(LocalSpecifier,
                                     RemoteSpecifier,
                                     TransportProperties,
                                     SecurityProperties)
   Listener := Preconnection.Listen()
]]></artwork>
          <t>Create a Source-Specific Multicast an SSM group as a sender:</t>
          <artwork><![CDATA[
   RemoteSpecifier := NewRemoteEndpoint()
   RemoteSpecifier.WithMulticastGroupIP(233.251.240.1)
   RemoteSpecifier.WithPort(5353)
   RemoteSpecifier.WithHopLimit(8)

   LocalSpecifier := NewLocalEndpoint()
   LocalSpecifier.WithIPAddress(192.0.2.22)
   LocalSpecifier.WithInterface("en0")

   TransportProperties := ...
   SecurityParameters  := ...

   Preconnection := NewPreconnection(LocalSpecifier,
                                     RemoteSpecifier,
                                     TransportProperties,
                                     SecurityProperties)
   Connection := Preconnection.Initiate()
]]></artwork>
          <t>Join an any-source multicast ASM group as both a sender and a receiver:</t>
          <artwork><![CDATA[
   RemoteSpecifier := NewRemoteEndpoint()
   RemoteSpecifier.WithMulticastGroupIP(233.252.0.0)
   RemoteSpecifier.WithPort(5353)
   RemoteSpecifier.WithHopLimit(8)

   LocalSpecifier := NewLocalEndpoint()
   LocalSpecifier.WithAnySourceMulticastGroupIP(233.252.0.0)
   LocalSpecifier.WithIPAddress(192.0.2.22)
   LocalSpecifier.WithPort(5353)
   LocalSpecifier.WithInterface("en0")

   TransportProperties := ...
   SecurityParameters  := ...

   Preconnection := NewPreconnection(LocalSpecifier,
                                     RemoteSpecifier,
                                     TransportProperties,
                                     SecurityProperties)
   Connection, Listener := Preconnection.Rendezvous()
]]></artwork>
        </section>
      </section>
      <section anchor="selection-props">
        <name>Specifying Transport Properties</name>

<!--[rfced] Is the meaning of this text "on a per-Connection and
     per-Message level"?

Original:
...the detailed operation of the selected Protocol Stacks on a per-
Connection and Message level.

Perhaps:
...the detailed operation of the selected Protocol Stacks on a
per-Connection and per-Message level.
-->

        <t>A Preconnection object holds properties reflecting the application's
requirements and preferences for the transport. These include Selection
Properties for selecting Protocol Stacks and paths, as well as Connection
Properties and Message Properties for configuration of the detailed operation
of the selected Protocol Stacks on a per-Connection and Message level.</t>
        <t>The protocol(s) and path(s) selected as candidates during establishment are
determined and configured using these properties. Since there could be paths
over which some transport protocols are unable to operate, or Remote Endpoints
that support only specific network addresses or transports, transport protocol
selection is necessarily tied to path selection. This could involve choosing
between multiple local interfaces that are connected to different access
networks.</t>
        <t>When additional information (such as Provisioning Domain (PvD) PvD information
<xref target="RFC7556"/>) is available about the networks over which an endpoint can operate,
this can inform the selection between alternate network paths.
Path information can include PMTU, the Path MTU (PMTU), the set of supported DSCPs, Differentiated Services Code Points (DSCPs),
expected usage, cost, etc. The usage of this information by the Transport
Services System is generally independent of the specific mechanism/protocol
used to receive the information (e.g., zero-conf, DHCP, or IPv6 Router Advertisements (RAs)).

<!-- [rfced] Section 6.2: For ease of the reader, we expanded "RAs" as
     "Router Advertisements".  If this is incorrect, please provide
     the correct definition.

Original:
 The usage of this information by
 the Transport Services System is generally independent of the
 specific mechanism/protocol used to receive the information (e.g.
 zero-conf, DHCP, or IPv6 RA).</t> RA).

Currently:
 The usage of this information by the Transport Services System
 is generally independent of the specific mechanism/protocol used to
 receive the information (e.g., zero-conf, DHCP, or IPv6 Router
 Advertisements (RAs)). -->

</t>
        <t>Most Selection Properties are represented as Preferences, which can
take one of five values:</t>
        <table anchor="tab-pref-levels">
          <name>Selection Property Preference Levels</name>
          <thead>
            <tr>
              <th align="left">Preference</th>
              <th align="left">Effect</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Require</td>
              <td align="left">Select only protocols/paths providing the property, fail otherwise</td> property; otherwise, fail</td>
            </tr>
            <tr>
              <td align="left">Prefer</td>
              <td align="left">Prefer protocols/paths providing the property, proceed otherwise</td> property; otherwise, proceed</td>
            </tr>
            <tr>
              <td align="left">No Preference</td>
              <td align="left">No preference</td>
            </tr>
            <tr>
              <td align="left">Avoid</td>
              <td align="left">Prefer protocols/paths not providing the property, proceed otherwise</td> property; otherwise, proceed</td>
            </tr>
            <tr>
              <td align="left">Prohibit</td>
              <td align="left">Select only protocols/paths not providing the property, fail otherwise</td> property; otherwise, fail</td>
            </tr>
          </tbody>
        </table>
        <t>The implementation MUST <bcp14>MUST</bcp14> ensure an outcome that is consistent with all application
requirements expressed using Require and Prohibit. While preferences
expressed using Prefer and Avoid influence protocol and path selection as well,
outcomes can vary vary, even given the same Selection Properties, because the available
protocols and paths can differ across systems and contexts. However,
implementations are RECOMMENDED <bcp14>RECOMMENDED</bcp14> to seek to provide a consistent outcome
to an application, when provided with the same set of Selection Properties.</t>
        <t>Note that application preferences can conflict with each other. For
example, if an application indicates a preference for a specific path by
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
path. In such cases, applications can expect properties that determine path
selection to be prioritized over properties that determine protocol selection.
The transport system SHOULD <bcp14>SHOULD</bcp14> determine the preferred path first, regardless of
protocol preferences. This ordering is chosen to provide consistency across
implementations,
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
preference might be based on a user's preference to avoid being charged
more for a cellular data plan).</t>
        <t>Selection and Connection Properties, as well as defaults for Message
Properties, can be added to a Preconnection to configure the selection process
and to further configure the eventually selected Protocol Stack(s). They are
collected into a TransportProperties object to be passed into a Preconnection
object:</t>
        <artwork><![CDATA[
TransportProperties := NewTransportProperties()
]]></artwork>
        <t>Individual properties are then set on the TransportProperties object.
Setting a Transport Property to a value overrides the previous value of this Transport Property.</t>
        <artwork><![CDATA[
TransportProperties.Set(property, value)
]]></artwork>
        <t>To aid readability, implementations MAY <bcp14>MAY</bcp14> provide additional convenience functions to simplify the use of Selection Properties: see <xref target="preference-conv"/> for examples.
In addition, implementations MAY <bcp14>MAY</bcp14> provide a mechanism to create TransportProperties objects that
are preconfigured for common use cases, as outlined in <xref target="property-profiles"/>.</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 either being explicitly configured
via a Preconnection, by configuration being configured after establishment, or by inheriting them
from an antecedent via cloning; see <xref target="groups"/> for more.</t> more details.</t>
        <t><xref target="connection-props"/> provides a list of Connection Properties, while Selection
Properties are listed in the subsections below. Selection Properties are
only considered during establishment, establishment and can not cannot be changed after a Connection
is established. After a Connection is established, At which point, Selection Properties can only
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> where:</t>
	<ul><li><tt>true</tt> means
that the selected Protocol Stack supports the feature or uses the path associated
with the Selection Property, and <tt>false</tt> and</li>
<li><tt>false</tt> means that the Protocol Stack does not
	support the feature or use the path. Implementations path.</li></ul>
	<t>Implementations
of Transport Services systems could alternatively use the two Preference values <tt>Require</tt>
and <tt>Prohibit</tt> Preference values to represent <tt>true</tt> and <tt>false</tt>, respectively.
Other types of Selection Properties remain unchanged when they are made available for
reading after a Connection is established.</t>
        <t>An implementation of the Transport Services API needs to provide sensible defaults for Selection
Properties. The default values for each property below represent a
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 using the
default set of Properties might not succeed in establishing a Connection. Using
the same default values for independent Transport Services systems can be beneficial
when applications are ported between different implementations/platforms, even if this
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 <bcp14>RECOMMENDED</bcp14> to clearly
document any differences.</t>
        <section anchor="prop-reliable">
          <name>Reliable Data Transfer (Connection)</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>reliability</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Preference</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Require</t>
            </dd>
          </dl>
          <t>This property specifies whether the application needs to use a transport
protocol that ensures that
all data is received at the Remote Endpoint in order order, without loss or duplication.
When reliable data transfer is enabled, this
also entails being notified when a Connection is closed or aborted.</t>
        </section>
        <section anchor="prop-boundaries">
          <name>Preservation of Message Boundaries</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>preserveMsgBoundaries</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Preference</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>No Preference</t>
            </dd>
          </dl>
          <t>This property specifies whether the application needs or prefers to use a transport
protocol that preserves message boundaries.</t>
        </section>
        <section anchor="prop-partially-reliable">
          <name>Configure Per-Message Reliability</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>perMsgReliability</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Preference</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>No Preference</t>
            </dd>
          </dl>
          <t>This property specifies whether an application considers it useful to specify different
reliability requirements for individual Messages in a Connection.</t>
        </section>
        <section anchor="prop-ordering">
          <name>Preservation of Data Ordering</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>preserveOrder</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Preference</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Require</t>
            </dd>
          </dl>
          <t>This property specifies whether the application wishes to use a transport
protocol that can ensure that data is received by the application at the Remote Endpoint in the same order as it was sent.</t>
        </section>
        <section anchor="prop-0rtt">
          <name>Use 0-RTT Session Establishment with a Safely Replayable Message</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>zeroRttMsg</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Preference</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>No Preference</t>
            </dd>
          </dl>
          <t>This property specifies whether an application would like to supply a Message to
the transport protocol before connection establishment that establishment, which will then be
reliably transferred to the Remote Endpoint before or during connection
establishment. This Message can potentially be received multiple times (i.e.,
multiple copies of the Message data could be passed to the Remote Endpoint).
See also <xref target="msg-safelyreplayable"/>.</t>
        </section>
        <section anchor="prop-multistream">
          <name>Multistream Connections in a Group</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>multistreaming</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Preference</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Prefer</t>
            </dd>
          </dl>
          <t>This property specifies whether the application would prefer multiple Connections
within a Connection Group to be provided by streams of a single underlying
transport connection connection, where possible.</t>
        </section>
        <section anchor="prop-checksum-control-send">
          <name>Full Checksum Coverage on Sending</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>fullChecksumSend</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Preference</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Require</t>
            </dd>
          </dl>
          <t>This property specifies the application's need for protection against
corruption for all data transmitted on this Connection. Disabling this property could enable
the application to influence the sender checksum coverage after Connection establishment (see <xref target="msg-checksum"/>).</t>
        </section>
        <section anchor="prop-checksum-control-receive">
          <name>Full Checksum Coverage on Receiving</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>fullChecksumRecv</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Preference</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Require</t>
            </dd>
          </dl>
          <t>This property specifies the application's need for protection against
corruption for all data received on this Connection. Disabling this property could enable
the application to influence the required minimum receiver checksum coverage after Connection establishment (see <xref target="conn-recv-checksum"/>).</t>
        </section>
        <section anchor="prop-cc">
          <name>Congestion control</name> Control</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>congestionControl</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Preference</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Require</t>
            </dd>
          </dl>
          <t>This property specifies whether or not the application would like the Connection to be
congestion controlled or not. controlled. Note that if a Connection is not congestion
controlled, an application using such a Connection SHOULD <bcp14>SHOULD</bcp14> itself perform
congestion control in accordance with <xref target="RFC2914"/> or use a circuit breaker in
accordance with <xref target="RFC8084"/>, whichever is appropriate. Also note that reliability
is usually combined with congestion control in protocol implementations, implementations rendering "reliable but not congestion controlled" controlled", a request that is unlikely to
succeed. If the Connection is congestion controlled, performing additional congestion control
in the application can have negative performance implications.</t>
        </section>
        <section anchor="keep-alive">
          <name>Keep alive</name>
          <name>Keep-Alive Packets</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>keepAlive</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Preference</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>No Preference</t>
            </dd>
          </dl>
          <t>This property specifies whether or not the application would like the Connection to send
keep-alive packets or not. packets. Note that if a Connection determines that keep-alive
packets are being sent, the application SHOULD itself <bcp14>SHOULD</bcp14> avoid generating additional keep-alive
messages. Note that that, when supported, the system will use the default period
for generation of the keep alive-packets. keep-alive packets. (See also <xref target="keep-alive-timeout"/>).</t> target="keep-alive-timeout"/>.)</t>
        </section>
        <section anchor="prop-interface">
          <name>Interface Instance or Type</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>interface</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Set of (Preference, Enumeration)</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Empty (not setting a preference for any interface)</t>
            </dd>
          </dl>
          <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
<tt>Avoid</tt>. Note that marking a specific interface as <tt>Require</tt> strictly limits path
selection to that single interface, and often leads to less flexible and resilient
connection establishment.</t>
          <t>In contrast to other Selection Properties, this property is a set of
tuples of (Enumerated) interface identifier and preference. It can either be
implemented directly as such, or for making one preference available for each
interface and interface type available on the system.</t> system.

<!-- [rfced] Sections 6.2.11 and 6.2.12: Please review the following
     text for clarity specifically making the two options connected by
     "either" symmetrical grammatically.

Original:
It can either be implemented directly as such, or for making one
preference available for each interface and interface type available
on the system.

Perhaps:
It can be implemented either 1) directly as such or 2) for making one
preference available for each interface and interface type that is
available on the system.

Perhaps:
It can either be implemented directly as such or be implemented to
make one preference available for each interface and interface type
available on the system.
-->

</t>
          <t>The set of valid interface types is implementation- and system-specific. 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
available; whereas whereas, on a desktop computer, <tt>Wi-Fi</tt> and <tt>Wired
Ethernet</tt> interface types might be available. An implementation should provide all types
that are supported on the local system, system to allow
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
<tt>Cellular</tt> interface type for both systems, since an application might wish to
always prohibit cellular.</t>
          <t>The set of interface types is expected to change over time as new access
technologies become available. The taxonomy of interface types on a given
Transport Services system is implementation-specific.</t> implementation specific.</t>
          <t>Interface types SHOULD NOT <bcp14>SHOULD NOT</bcp14> be treated as a proxy for properties of interfaces interfaces,
such as metered or unmetered network access. If an application needs to prohibit
metered interfaces, this should be specified via Provisioning Domain attributes
(see <xref target="prop-pvd"/>) or another specific property.</t>
          <t>Note that this property is not used to specify an interface scope zone for a particular Endpoint. <xref target="ifspec"/> provides details about how to qualify endpoint candidates on a per-interface basis.</t>
        </section>
        <section anchor="prop-pvd">
          <name>Provisioning Domain Instance or Type</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>pvd</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Set of (Preference, Enumeration)</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Empty (not setting a preference for any PvD)</t>
            </dd>
          </dl>
          <t>Similar to <tt>interface</tt> (see <xref target="prop-interface"/>), this property
allows the application to control path selection by selecting which specific
Provisioning Domain (PvD)
PvD or categories of PVDs PvDs it wants to
<tt>Require</tt>, <tt>Prohibit</tt>, <tt>Prefer</tt>, or <tt>Avoid</tt>. Provisioning Domains define
consistent sets of network properties that might be more specific than network
interfaces <xref target="RFC7556"/>.</t>
          <t>As with interface instances and types, this property is a set of tuples of (Enumerated)
PvD identifier and preference. It can either be implemented directly as such,
or for making one preference available for each interface and interface type
available on the system.</t>
          <t>The identification of a specific PvD is implementation- and system-specific. specific to the implementation or system.
<xref target="RFC8801"/> defines how to use an FQDN to identify a PvD when advertised by
a network, but systems might also use other locally-relevant locally relevant identifiers
such as string names or Integers to identify PvDs. As with requiring specific
interfaces, requiring a specific PvD strictly limits the path selection.</t>
          <t>Categories or types of PvDs are also defined to be implementation- and
system-specific. specific to the implementation or system. These can be useful to identify a service that is provided by a
PvD. For example, if an application wants to use a PvD that provides a
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
particular instance. While this does restrict path selection, it is broader than
requiring specific PvD instances or interface instances, instances and should be preferred
over these options.</t>
        </section>
        <section anchor="use-temporary-local-address">
          <name>Use Temporary Local Address</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>useTemporaryLocalAddress</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Preference</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Avoid for Listeners and Rendezvous Connections. Connections; Prefer for other Connections.</t> Connections</t>
            </dd>
          </dl>
          <t>This property allows the application to express a preference for the use of
temporary local addresses, sometimes called "privacy" addresses <xref target="RFC8981"/>.
Temporary addresses are generally used to prevent linking connections over time
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
application Requires the use of temporary addresses, the resulting Connection
cannot use IPv4, IPv4 because temporary addresses do not exist in IPv4. Second,
temporary local addresses might involve trading off privacy for performance.
For instance, temporary addresses (e.g., <xref target="RFC8981"/>) can interfere with resumption mechanisms
that some protocols rely on to reduce initial latency.</t>
        </section>
        <section anchor="multipath-mode">
          <name>Multipath Transport</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>multipath</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Enumeration</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Disabled for Connections created through initiate and rendezvous, rendezvous; Passive for Listeners</t>
            </dd>
          </dl>
          <t>This property specifies whether whether, and how how, applications want to take advantage of
transferring data across multiple paths between the same end hosts.
Using multiple paths allows Connections to migrate between interfaces or aggregate bandwidth
as availability and performance properties change.
Possible values are:</t> are as follows:</t>
          <dl>
            <dt>Disabled:</dt>
            <dd>
              <t>The Connection will not use multiple paths once established, even if the chosen transport supports using multiple paths.</t>
            </dd>
            <dt>Active:</dt>
            <dd>
              <t>The Connection will negotiate the use of multiple paths if the chosen transport supports this.</t> it.</t>
            </dd>
            <dt>Passive:</dt>
            <dd>
              <t>The Connection will support the use of multiple paths if the Remote Endpoint requests it.</t>
            </dd>
          </dl>
          <t>The policy for using multiple paths is specified using the separate <tt>multipathPolicy</tt> property, property; see <xref target="multipath-policy"/> below. target="multipath-policy"/>.
To enable the peer endpoint to initiate additional paths towards toward a local address other than the one initially used, it is necessary to set the <tt>advertisesAltaddr</tt> property (see <xref target="altaddr"/> below).</t> target="altaddr"/>).</t>
          <t>Setting this property to <tt>Active</tt> can have privacy implications: implications.  It enables the transport to establish connectivity using alternate paths that might result in users being linkable across the multiple paths, even if the <tt>advertisesAltaddr</tt> property (see <xref target="altaddr"/> below) target="altaddr"/>) is set to <tt>false</tt>.</t>
          <t>Note that Multipath Transport has no corresponding Selection Property 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.
The <tt>Disabled</tt> value implies a requirement not to use multiple paths in parallel but does not prevent choosing a protocol that is capable of using multiple paths, e.g., it does not prevent choosing TCP, TCP but prevents sending the <tt>MP_CAPABLE</tt> option in the TCP handshake.</t>
        </section>
        <section anchor="altaddr">
          <name>Advertisement of Alternative Addresses</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>advertisesAltaddr</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Boolean</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t><tt>false</tt></t>
            </dd>
          </dl>
          <t>This property specifies whether alternative addresses, e.g., of other interfaces, ought to be advertised to the
peer endpoint by the Protocol Stack. Advertising these addresses enables the peer 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 result in users being linkable across the multiple paths.
Also, note that setting this to <tt>false</tt> does not prevent the local Transport Services system from <em>establishing</em> connectivity using alternate paths (see <xref target="multipath-mode"/> above); target="multipath-mode"/>); it only prevents <em>proactive advertisement</em> of addresses.</t>
        </section>
        <section anchor="direction-of-communication">
          <name>Direction of communication</name> Communication</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>direction</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Enumeration</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Bidirectional</t>
            </dd>
          </dl>
          <t>This property specifies whether an application wants to use the Connection for sending and/or receiving data.  Possible values are:</t> are as follows:</t>
          <dl>
            <dt>Bidirectional:</dt>
            <dd>
              <t>The Connection must support sending and receiving data</t> data.</t>
            </dd>
            <dt>Unidirectional send:</dt>
            <dd>
              <t>The Connection must support sending data, and the application cannot use the Connection to receive any data</t> data.</t>
            </dd>
            <dt>Unidirectional receive:</dt>
            <dd>
              <t>The Connection must support receiving data, and the application cannot use the Connection to send any data</t> data.</t>
            </dd>
          </dl>
          <t>Since unidirectional communication can be
supported by transports offering bidirectional communication, specifying
unidirectional communication might cause a transport stack that supports
bidirectional communication to be selected.</t>
        </section>
        <section anchor="prop-soft-error">
          <name>Notification of ICMP soft error message arrival</name> Soft Error Message Arrival</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>softErrorNotify</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Preference</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>No Preference</t>
            </dd>
          </dl>
          <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
connection. When set to <tt>true</tt>, received ICMP errors are available as
<tt>SoftError</tt> events, 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
upon receiving them <xref target="RFC8085"/>.</t>
        </section>
        <section anchor="active-read-before-send">
          <name>Initiating side is not Side Is Not the first First to write</name> Write</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>activeReadBeforeSend</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Preference</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>No Preference</t>
            </dd>
          </dl>
          <t>The most common client-server communication pattern involves the
client actively opening a Connection, then sending data to the server. The
server listens (passive open), reads, and then answers. This property
	  specifies whether an application wants to diverge from this pattern -- either by actively either:</t>
	  <ol><li>actively opening with <tt>Initiate</tt>, immediately followed by reading, or passively reading or</li>
	  <li>passively opening with <tt>Listen</tt>,
	  immediately followed by writing. This writing.</li>
	</ol>
	<t>This property is ignored when establishing
connections using <tt>Rendezvous</tt>.
Requiring this property limits the choice of mappings to underlying protocols,
which can reduce
efficiency. For example, it prevents the Transport Services system from mapping
Connections to SCTP Stream Control Transmission Protocol (SCTP) streams, where
the first transmitted data takes the role of an active an active open signal.</t>
        </section>
      </section>
      <section anchor="security-parameters">
        <name>Specifying Security Parameters and Callbacks</name>
        <t>Most security parameters, e.g., TLS ciphersuites, local identity and private key, etc.,
can be configured statically. Others are dynamically configured during Connection establishment.
Security parameters and callbacks are partitioned based on their place in the lifetime
of Connection establishment. Similar to Transport Properties, both parameters and callbacks
are inherited during cloning (see <xref target="groups"/>).</t>
        <t>This document specifies an abstract API, which could appear to conflict with the need
for security parameters to be unambiguous. The Transport Services System SHOULD <bcp14>SHOULD</bcp14> provide reasonable,
secure defaults for each enumerated security parameter, such that users of the system
only need to specify parameters required to establish a secure connection
(e.g., <tt>serverCertificate</tt>, <tt>serverCertificate</tt> or <tt>clientCertificate</tt>). Specifying security parameters
from enumerated values (e.g., specific ciphersuites) might constrain which transport
protocols can be selected during Connection establishment.</t>
        <t>Security configuration parameters are specified in the pre-establishment preestablishment phase
and are created as follows:</t>
        <artwork><![CDATA[
SecurityParameters := NewSecurityParameters()
]]></artwork>
        <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 parameters and/or
values of enumerations (e.g., ciphersuites) used in the security parameters are system-
and implementation-specific, specific to the system or
implementation and ought to be chosen to follow the principle of least
surprise for users of the platform / language platform/language environment in question.</t>
        <t>For security parameters that are enumerations of known values, such as TLS
ciphersuites, implementations are responsible for exposing the set of values
they support. For security parameters that are not simple value types, such
as certificates and keys, implementations are responsible for exposing
types appropriate for the platform / language platform/language environment.</t>
        <t>Applications SHOULD <bcp14>SHOULD</bcp14> use common safe defaults for values such as TLS ciphersuites
whenever possible. However, as discussed in <xref target="RFC8922"/>, many transport security protocols
require specific security parameters and constraints from the client at the time of
configuration and actively during a handshake.</t>
        <t>The set of security parameters defined here is not exhaustive, but illustrative.
Implementations SHOULD <bcp14>SHOULD</bcp14> expose an equivalent to the parameters listed below to allow for
sufficient configuration of security parameters, but the details are expected
to vary based on platform and implementation constraints. Applications MUST <bcp14>MUST</bcp14> be able
to constrain the security protocols and versions that the Transport Services System
will use.</t>
        <t>Representation of security parameters in implementations ought to parallel
that chosen for Transport Property names as suggested in <xref target="scope-of-interface-defn"/>.</t>
        <t>Connections that use Transport Services SHOULD <bcp14>SHOULD</bcp14> use security in general. However, for
compatibility with endpoints that do not support transport security protocols (such
as a TCP endpoint that does not support TLS), applications can initialize their
security parameters to indicate that security can be disabled, disabled or can be opportunistic.
If security is disabled, the Transport Services system will not attempt to add
transport security automatically. If security is opportunistic, it will allow
Connections without transport security, but it will still attempt to use unauthenticated
security if available.</t>
        <artwork><![CDATA[
SecurityParameters := NewDisabledSecurityParameters()

SecurityParameters := NewOpportunisticSecurityParameters()
]]></artwork>
        <section anchor="allowed-security-protocols">
          <name>Allowed security protocols</name> Security Protocols</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>allowedSecurityProtocols</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Implementation-specific enumeration of security protocol names and/or versions.</t> versions</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Implementation-specific best available security protocols</t>
            </dd>
          </dl>
          <t>This property allows applications to restrict which security protocols and security protocol versions can be used in the protocol stack. Protocol Stack. Applications MUST <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 with unknown or weak security properties.</t>
          <artwork><![CDATA[
SecurityParameters.Set(allowedSecurityProtocols, [ tls_1_2, tls_1_3 ])
]]></artwork>
        </section>
        <section anchor="certificate-bundles">
          <name>Certificate bundles</name> Bundles</name>
          <dl>
            <dt>Names:</dt>
            <dd>
              <t>serverCertificate, clientCertificate</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Array of certificate objects</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Empty array</t>
            </dd>
          </dl>
          <t>One or more certificate bundles identifying the Local Endpoint, whether Endpoint as a server certificate or a client certificate. Multiple bundles may
be provided to allow selection among different protocol stacks Protocol Stacks that may
require differently formatted bundles. The form and format of the
certificate bundle is implementation-specific. are implementation specific. Note that if the private
keys associated with a bundle are not available, e.g., since they are stored in hardware
security modules Hardware
Security Modules (HSMs), handshake callbacks are necessary. See below for details.</t>
          <artwork><![CDATA[
SecurityParameters.Set(serverCertificate, myCertificateBundle[])
SecurityParameters.Set(clientCertificate, myCertificateBundle[])
]]></artwork>
        </section>
        <section anchor="pinned-server-certificate">
          <name>Pinned server certificate</name> Server Certificate</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>pinnedServerCertificate</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Array of certificate chain objects</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Empty array</t>
            </dd>
          </dl>
          <t>Zero or more certificate chains to use as pinned server
certificates, such that connecting will fail if the presented server
certificate does not match one of the supplied pinned certificates.
The form and format of the certificate chain is implementation-specific.</t> are implementation specific.</t>
          <artwork><![CDATA[
SecurityParameters.Set(pinnedServerCertificate, yourCertificateChain[])
]]></artwork>
        </section>
        <section anchor="application-layer-protocol-negotiation">
          <name>Application-layer protocol negotiation</name>
          <name>Application-Layer Protocol Negotiation</name>

<!--[rfced] May we lowercase "Strings" in the following to match the
     capping schemes of the other similar subsections?

Original:
Type:  Array of Strings

Perhaps:
Type:  Array of strings
-->

          <dl>
            <dt>Name:</dt>
            <dd>
              <t>alpn</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Array of Strings</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Automatic selection</t>
            </dd>
          </dl>
          <t>Application-layer protocol negotiation
          <t>Application-Layer Protocol Negotiation (ALPN) values: used to indicate which
application-layer protocols are negotiated by the security protocol layer.
See <xref target="ALPN"/> target="RFC7301"/> for a definition of the ALPN field. Note that the Transport
Services System can provide ALPN values automatically, automatically based on
the protocols being used, if not explicitly specified by the application.</t>
          <artwork><![CDATA[
SecurityParameters.Set(alpn, ["h2"])
]]></artwork>
        </section>
        <section anchor="groups-ciphersuites-and-signature-algorithms">
          <name>Groups, ciphersuites, Ciphersuites, and signature algorithms</name> Signature Algorithms</name>
          <dl>
            <dt>Names:</dt>
            <dd>
              <t>supportedGroup, ciphersuite, signatureAlgorithm</t>
            </dd>
            <dt>Types:</dt>
            <dd>
              <t>Arrays of implementation-specific enumerations</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Automatic selection</t>
            </dd>
          </dl>
          <t>These are used to restrict what cryptographic parameters
are used by underlying transport security protocols. When not specified,
these algorithms should use known and safe defaults for the system.</t>
          <artwork><![CDATA[
SecurityParameters.Set(supportedGroup, secp256r1)
SecurityParameters.Set(ciphersuite, TLS_AES_128_GCM_SHA256)
SecurityParameters.Set(signatureAlgorithm, ecdsa_secp256r1_sha256)
]]></artwork>
        </section>
        <section anchor="session-cache-options">
          <name>Session cache options</name> Cache Options</name>
          <dl>
            <dt>Names:</dt>
            <dd>
              <t>maxCachedSessions, cachedSessionLifetimeSeconds</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Integer</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Automatic selection</t>
            </dd>
          </dl>
          <t>These values are used to tune session cache capacity and lifetime, lifetime and
can be extended to include other policies.</t>
          <artwork><![CDATA[
SecurityParameters.Set(maxCachedSessions, 16)
SecurityParameters.Set(cachedSessionLifetimeSeconds, 3600)
]]></artwork>
        </section>
        <section anchor="pre-shared-key">
          <name>Pre-shared key</name>
          <name>Pre-Shared Key</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>preSharedKey</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Key and identity (platform-specific)</t> (platform specific)</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>None</t>
            </dd>
          </dl>
          <t>Used to install pre-shared keying material established
out-of-band.
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
Remote Endpoint. Note that the use of a pre-shared key will tend to select a single
security protocol, and therefore protocol and, therefore, directly select a single underlying protocol stack. Protocol Stack.
A Transport Services API could express <tt>None</tt> in an environment-typical way, e.g., as a Union type or special value.</t>
          <artwork><![CDATA[
SecurityParameters.Set(preSharedKey, key, myIdentity)
]]></artwork>
        </section>
        <section anchor="connection-establishment-callbacks">
          <name>Connection Establishment Callbacks</name>
          <t>Security decisions, especially pertaining to trust, are not static. Once configured,
parameters can also be supplied during Connection establishment. These are best
handled as client-provided callbacks.
Callbacks block the progress of the Connection establishment, which distinguishes them
from other events in the transport system. How callbacks and events are implemented is specific to each implementation.
Security handshake callbacks that could be invoked during Connection establishment include:</t>
          <ul spacing="normal">
            <li>
              <t>Trust verification callback: Invoked when a Remote Endpoint's trust must be verified before the
handshake protocol can continue. For example, the application could verify an X.509 certificate
as described in <xref target="RFC5280"/>.</t>
            </li>
          </ul>
          <artwork><![CDATA[
TrustCallback := NewCallback({
  // Handle trust, the trust and return the result
})
SecurityParameters.SetTrustVerificationCallback(TrustCallback)
]]></artwork>
          <ul spacing="normal">
            <li>
              <t>Identity challenge callback: Invoked when a private key operation is required, e.g., when
local authentication is requested by a Remote Endpoint.</t>
            </li>
          </ul>
          <artwork><![CDATA[
ChallengeCallback := NewCallback({
  // Handle the challenge
})
SecurityParameters.SetIdentityChallengeCallback(ChallengeCallback)
]]></artwork>
        </section>
      </section>
    </section>
    <section anchor="establishment">
      <name>Establishing Connections</name>
      <t>Before a Connection can be used for data transfer, it needs to be established.
Establishment ends the pre-establishment preestablishment phase; all transport properties and
cryptographic parameter specification must be complete before establishment,
as these will be used to select candidate Paths and Protocol Stacks
for the Connection. Establishment can be active, using the <tt>Initiate</tt> action;
passive, using the <tt>Listen</tt> action; or simultaneous for peer-to-peer, peer-to-peer connections, using
the <tt>Rendezvous</tt> action. These actions are described in the subsections below.</t>
      <section anchor="initiate">
        <name>Active Open: Initiate</name>
        <t>Active open is the action of establishing a Connection to a Remote Endpoint presumed
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 API through the
<tt>Initiate</tt> action:</t>
        <artwork><![CDATA[
Connection := Preconnection.Initiate(timeout?)
]]></artwork>
        <t>The timeout parameter specifies how long to wait before aborting Active open.
Before calling <tt>Initiate</tt>, the caller must have populated a Preconnection
object with a Remote Endpoint object to identify the endpoint, optionally a Local Endpoint
object (if not specified, the system will attempt to determine a
suitable Local Endpoint), as well as all properties
necessary for candidate selection.</t>
        <t>The <tt>Initiate</tt> action returns a Connection object. Once <tt>Initiate</tt> has been
called, any changes to the Preconnection MUST NOT <bcp14>MUST NOT</bcp14> have any effect on the
Connection. However, the Preconnection can be reused, e.g., to <tt>Initiate</tt>
	another Connection.</t>

<!--[rfced] Please confirm that "multiple candidates" is intended
     instead of "multiple connections" (or Connections?).  Or is
     another rephrase desirable (e.g., "could be sent multiple times
     or using multiple candidates")?

Original:
...note that any data marked as "safely replayable" that is sent while
the Connection is being established could be sent multiple times or on
multiple candidates.

-->

        <t>Once <tt>Initiate</tt> is called, the candidate Protocol Stack(s) can cause one or more
candidate transport-layer connections to be created to the specified Remote
Endpoint. The caller could immediately begin sending Messages on the Connection
(see <xref target="sending"/>) after calling <tt>Initiate</tt>; note that any data marked as "safely replayable" that is sent
while the Connection is being established could be sent multiple times or on
multiple candidates.</t>
        <t>The following events can be sent by the Connection after <tt>Initiate</tt> is called:</t>
        <artwork><![CDATA[
Connection -> Ready<>
]]></artwork>
        <t>The <tt>Ready</tt> event occurs after <tt>Initiate</tt> has established a transport-layer
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
the <tt>Ready</tt> event for Connections established using <tt>Initiate</tt>.</t>
        <artwork><![CDATA[
Connection -> EstablishmentError<reason?>
]]></artwork>
        <t>An <tt>EstablishmentError</tt> occurs either when the when:</t>
   <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
available Paths and/or Protocol Stacks meeting the constraints is empty) or
reconciled with the Local and/or Remote Endpoints; when a remote Endpoints,</li>
    <li>a Remote Endpoint Identifier cannot be resolved; or when no resolved, or</li>
    <li>no transport-layer connection can be established to
the Remote Endpoint (e.g., because the Remote Endpoint is not accepting
connections, the application is prohibited from opening a Connection by the
operating system, or the establishment attempt has timed out for any other reason).</t> reason).</li>
   </ul>
        <t>Connection establishment
and transmission of the first Message can be combined in a single action (<xref target="initiate-and-send"/>).</t>
      </section>
      <section anchor="listen">
        <name>Passive Open: Listen</name>
        <t>Passive open is the action of waiting for Connections from Remote Endpoints,
commonly used by servers in client-server interactions. Passive open is
supported by the Transport Services API through the <tt>Listen</tt> action and returns a Listener object:</t>
        <artwork><![CDATA[
Listener := Preconnection.Listen()
]]></artwork>
        <t>Before calling <tt>Listen</tt>, the caller must have initialized the Preconnection
during the pre-establishment preestablishment phase with a Local Endpoint object, as well
as all properties necessary for Protocol Stack selection. A Remote Endpoint
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,
any changes to the Preconnection MUST NOT <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>
        <artwork><![CDATA[
Listener.Stop()
]]></artwork>
        <t>Listening continues until the global context shuts down, down or until the Stop
action is performed on the Listener object.</t>
        <artwork><![CDATA[
Listener -> ConnectionReceived<Connection>
]]></artwork>
        <t>The <tt>ConnectionReceived</tt> event occurs when a when:</t>
        <ul spacing="normal">
         <li>a Remote Endpoint has established or cloned (e.g., by creating a new stream in a multi-stream transport; see <xref target="groups"/>) a
transport-layer connection to this Listener (for Connection-oriented
transport protocols), or when the or</li>
         <li>the first Message has been received from the
Remote Endpoint (for Connectionless protocols or streams of a multi-streaming transport), transport) causing a new Connection to be
created. The
created.</li>
	</ul>
        <t>The resulting Connection is contained within the <tt>ConnectionReceived</tt>
event,
event and is ready to use as soon as it is passed to the application via the
event.</t>
        <artwork><![CDATA[
Listener.SetNewConnectionLimit(value)
]]></artwork>
        <t>If the caller wants to rate-limit the number of inbound Connections that will be delivered,
it can set a cap using <tt>SetNewConnectionLimit</tt>. This mechanism allows a server to
protect itself from being drained of resources. Each time a new Connection is delivered
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 sets the
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>
        <artwork><![CDATA[
Listener -> EstablishmentError<reason?>
]]></artwork>
        <t>An <tt>EstablishmentError</tt> occurs either when the when:</t>
        <ul spacing="normal">
         <li>the Properties and security parameters of the Preconnection cannot be fulfilled for listening or cannot be reconciled with the Local Endpoint (and/or Remote Endpoint, if specified), when the specified),</li>
         <li>the Local Endpoint (or Remote Endpoint, if specified) cannot
be resolved, or when the or</li>
         <li>the application is prohibited from listening by policy.</t> policy.</li>
	</ul>
        <artwork><![CDATA[
Listener -> Stopped<>
]]></artwork>
        <t>A <tt>Stopped</tt> event occurs after the Listener has stopped listening.</t>
      </section>
      <section anchor="rendezvous">
        <name>Peer-to-Peer Establishment: Rendezvous</name>
        <t>Simultaneous peer-to-peer Connection establishment is supported by the
<tt>Rendezvous</tt> action:</t>
        <artwork><![CDATA[
Preconnection.Rendezvous()
]]></artwork>
        <t>A Preconnection object used in a <tt>Rendezvous</tt> MUST <bcp14>MUST</bcp14> have both the
Local Endpoint candidates and the Remote Endpoint candidates specified,
along with the Transport Properties and security parameters needed for
Protocol Stack selection, selection before the <tt>Rendezvous</tt> action is initiated.</t>
        <t>The <tt>Rendezvous</tt> action listens on the Local Endpoint
candidates for an incoming Connection from the Remote Endpoint candidates,
while also simultaneously trying to establish a Connection from the Local
Endpoint candidates to the Remote Endpoint candidates.</t>
        <t>If there are multiple Local Endpoints or Remote Endpoints configured, then
initiating a <tt>Rendezvous</tt> action will cause the Transport Services
Implementation to systematically probe the reachability
of those endpoint candidates following an approach such as that used in
Interactive Connectivity Establishment (ICE) <xref target="RFC8445"/>.</t>
        <t>If the endpoints are suspected to be behind a NAT, and the Local Endpoint
supports a method of discovering NAT bindings, such as Session Traversal
Utilities for NAT (STUN) STUN <xref target="RFC8489"/> or Traversal Using Relays around NAT
(TURN) <xref target="RFC8656"/>, then the <tt>Resolve</tt> action on the Preconnection can be
used to discover such bindings:</t>
        <artwork><![CDATA[
[]LocalEndpoint, []RemoteEndpoint := Preconnection.Resolve()
]]></artwork>
        <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
a <tt>Rendezvous</tt> for the Preconnection will listen for incoming Connections, Connections
and to which it will attempt to establish Connections.</t>
        <t>Note that the set of Local Endpoints returned by <tt>Resolve</tt> might or might not
contain information about all possible local interfaces interfaces, depending on how the
Preconnection is configured. The set of available local interfaces can also
change over time 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-peer Connection
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>
the Preconnection, Preconnection and pass the resulting list of Local Endpoint candidates to
the peer via a signalling signaling protocol, for example example, as part of an ICE exchange <xref target="RFC8445"/>
exchange
within SIP <xref target="RFC3261"/> or WebRTC <xref target="RFC7478"/>.  The peer will then,
via the same signalling signaling channel, return the Remote Endpoint candidates.
The set of Remote Endpoint candidates are is then configured onto on the Preconnection:</t>
        <artwork><![CDATA[
Preconnection.AddRemote([]RemoteEndpoint)
]]></artwork>
        <t>The <tt>Rendezvous</tt> action is initiated, and causes the Transport Services
Implementation to begin connectivity checks, once
        <t>Once the application has
added both the Local Endpoint candidates and the Remote Endpoint candidates
retrieved from the peer via the signalling signaling channel to the Preconnection.</t> 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 object via a
<tt>RendezvousDone&lt;&gt;</tt> event:</t>
        <artwork><![CDATA[
Preconnection -> RendezvousDone<Connection>
]]></artwork>
        <t>The <tt>RendezvousDone&lt;&gt;</tt> event occurs when a Connection is established with the
Remote Endpoint. For Connection-oriented transports, this occurs when the
transport-layer connection is established; for Connectionless transports,
it occurs when the first Message is received from the Remote Endpoint. The
resulting Connection is contained within the <tt>RendezvousDone&lt;&gt;</tt> event, event and is
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
NOT <bcp14>MUST
NOT</bcp14> have any effect on existing Connections.</t>
        <t>An <tt>EstablishmentError</tt> occurs either when the when:</t>
        <ul spacing="normal">
         <li>the Properties and Security
Parameters of the Preconnection cannot be fulfilled for rendezvous or
cannot be reconciled with the Local and/or Remote Endpoints, when the Endpoints,</li>
         <li>the Local
Endpoint or Remote Endpoint cannot be resolved, when no resolved,</li>
         <li>no transport-layer
connection can be established to the Remote Endpoint, or when the or</li>
         <li>the
application is prohibited from rendezvous by policy:</t> policy.</li>
	</ul>
        <artwork><![CDATA[
Preconnection -> EstablishmentError<reason?>
]]></artwork>
      </section>
      <section anchor="groups">
        <name>Connection Groups</name>
        <t>Connection Groups can be created using the <tt>Clone</tt> action:</t>
        <artwork><![CDATA[
Connection := Connection.Clone(framer?, connectionProperties?)
]]></artwork>
        <t>Calling <tt>Clone</tt> on a Connection yields a Connection Group containing two Connections: the parent
Connection on which <tt>Clone</tt> was called, 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.
Calling <tt>Clone</tt> on any of these Connections adds another Connection to
the Connection Group. Connections in a Connection Group share all
Connection Properties except <tt>connPriority</tt> (see <xref target="conn-priority"/>),
and these Connection Properties are entangled: Changing changing one of the
Connection Properties on one Connection in the Connection Group
automatically changes the Connection Property for all others. For example, changing
<tt>connTimeout</tt> (see
<xref target="conn-timeout"/>) on one Connection in a Connection Group will automatically
make the same change to this Connection Property for all other Connections in the Connection Group.
Like all other Properties, <tt>connPriority</tt> is copied
to the new Connection when calling <tt>Clone</tt>, but but, in this case, a later change to the
<tt>connPriority</tt> on one Connection does not change it on the
other Connections in the same Connection Group.</t>
        <t>The optional <tt>connectionProperties</tt> parameter allows passing
Transport Properties that control the behavior of the underlying stream or connection to be created, e.g., Protocol-specific Properties to request specific stream IDs for SCTP or QUIC.</t>
        <t>Message Properties set on a Connection also apply only to that Connection.</t>
        <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
stack of Message Framers associated with a Connection is copied to
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
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 Connection Group.
Calling <tt>GroupedConnections</tt> on a specific Connection returns a set of all Connections
in the same group.</t>
        <artwork><![CDATA[
[]Connection := Connection.GroupedConnections()
]]></artwork>
        <t>Connections will belong to the same group if the application previously called <tt>Clone</tt>.
Passive Connections can also be added to the same group -- group, e.g., when a Listener
receives a new Connection that is just a new stream of an already active already-active multi-streaming
protocol instance.</t>
        <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 Connection Group are
multiplexed together, giving them similar treatment not only inside Endpoints,
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
transport connection, depending on the underlying Protocol Stack. When <tt>Clone</tt> leads to
the opening of multiple such connections,
the Transport Services system will ensure consistency of
Connection Properties by uniformly applying them to all underlying connections
in a group. Even in such a case, there are possibilities it is possible for a Transport Services system
to implement prioritization within a Connection Group (see <xref target="TCP-COUPLING"/> and <xref target="RFC8699"/>.</t> target="RFC8699"/>).</t>
        <t>Attempts to clone a Connection can result in a <tt>CloneError</tt>:</t>
        <artwork><![CDATA[
Connection -> CloneError<reason?>
]]></artwork>
        <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
part of any Connection Group. For example, this can occur when the Transport Services
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 applied
to the Connection that sends the <tt>CloneError</tt>).</t>
        <t>The <tt>connPriority</tt> Connection Property operates on Connections in a Connection Group
using the same approach as that used in <xref target="msg-priority"/>: when allocating available network
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 higher Priority values. Capacity will be shared among these Connections according to
the <tt>connScheduler</tt> property (<xref target="conn-scheduler"/>).
See <xref target="priority-in-taps"/> for more.</t> more details.</t>
      </section>
      <section anchor="add-endpoints">
        <name>Adding and Removing Endpoints on a Connection</name>
        <t>Transport protocols that are explicitly multipath aware are expected to automatically
manage the set of Remote Endpoints that they are communicating with, with and the paths to
those endpoints. A <tt>PathChange&lt;&gt;</tt> event, described in <xref target="conn-path-change"/>, will be
generated when the path changes.</t>
        <t>In
        <t>However, in some cases, however, it is necessary to explicitly indicate to a Connection that
a new Remote Endpoint has become available for use, use or to indicate that a Remote
Endpoint is no longer available. This is most common in the case of peer to peer peer-to-peer
connections using Trickle ICE <xref target="RFC8838"/>.</t>
        <t>The <tt>AddRemote</tt> action can be used to add one or more new Remote Endpoints
to a Connection:</t>
        <artwork><![CDATA[
Connection.AddRemote([]RemoteEndpoint)
]]></artwork>
        <t>Endpoints that are already known to the Connection are ignored. A call to
<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
underlying transport protocol.</t>
        <t>Similarly, the <tt>RemoveRemote</tt> action can be used to tell a Connection to
stop using one or more Remote Endpoints:</t>
        <artwork><![CDATA[
Connection.RemoveRemote([]RemoteEndpoint)
]]></artwork>
        <t>Removing all known Remote Endpoints can have the effect of aborting the
connection. The effect of removing the active Remote Endpoint(s) depends
on the underlying transport: multipath aware multipath-aware transports might be able to
switch to a new path if other reachable Remote Endpoints exist, exist or the
connection might abort.</t>
        <t>Similarly, the <tt>AddLocal</tt> and <tt>RemoveLocal</tt> actions can be used to add
and remove Local Endpoints to/from to or from a Connection.</t>
      </section>
    </section>
    <section anchor="introspection">
      <name>Managing Connections</name>
      <t>During pre-establishment preestablishment and after establishment, (Pre-)Connections Preconnections or Connections can be configured and queried using Connection
Properties, and asynchronous information could be available about the state of the
Connection via <tt>SoftError</tt> events.</t>
      <t>Connection Properties represent the configuration and state of the selected
Protocol Stack(s) backing a Connection. These Connection Properties can be
generic, applying
generic (applying regardless of transport protocol, protocol) or specific, applicable specific (applicable to a
single implementation of a single transport Protocol Stack. Stack). Generic Connection
Properties are defined in <xref target="connection-props"/> below.</t> target="connection-props"/>.</t>
      <t>Protocol-specific Properties are defined in a transport- and
implementation-specific way that is specific to the transport or implementation to
permit more specialized protocol features to be used.
Too much reliance by an application on Protocol-specific Properties can significantly reduce the flexibility
of a transport services Transport Services system to make appropriate
selection and configuration choices. Therefore, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that
Generic Connection Properties are be used for properties common across different protocols and that
Protocol-specific Connection Properties are only used where specific protocols or properties are necessary.</t>
      <t>The application can set and query Connection Properties on a per-Connection
basis. Connection Properties that are not read-only can be set during
pre-establishment
preestablishment (see <xref target="selection-props"/>), as well as on Connections directly using
the <tt>SetProperty</tt> action:</t>
      <artwork><![CDATA[
ErrorCode := Connection.SetProperty(property, value)
]]></artwork>
      <t>If an error is encountered in setting a property (for example, if the application tries to set a TCP-specific property on a Connection that is not using TCP), the application MUST <bcp14>MUST</bcp14> be informed about this error via the <tt>ErrorCode</tt> Object. Such errors MUST NOT <bcp14>MUST NOT</bcp14> cause the Connection to be terminated.
Note that changing one of the Connection Properties on one Connection in a Connection Group
will also change it for all other Connections of that group; see further <xref target="groups"/>.</t>
<t>At any point, the application can query Connection Properties.</t>
      <artwork><![CDATA[

<!--[rfced] Please review if the last line should be included in the
     artwork tag.

Original:

 At any point, the application can query Connection Properties.

   ConnectionProperties := Connection.GetProperties()
   value := ConnectionProperties.Get(property)
   if ConnectionProperties.Has(boolean_or_preference_property) then ...

   Depending on the status of the Connection, the queried Connection
   Properties will include different information:

Perhaps:

 At any point, the application can query Connection Properties.

   ConnectionProperties := Connection.GetProperties()
   value := ConnectionProperties.Get(property)

   If ConnectionProperties.Has(boolean_or_preference_property), then,
   depending on the status of the Connection, the queried Connection
   Properties will include different information:
-->
      <artwork><![CDATA[
ConnectionProperties := Connection.GetProperties()
value := ConnectionProperties.Get(property)
if ConnectionProperties.Has(boolean_or_preference_property) then...
]]></artwork>
      <t>Depending on the status of the Connection, the queried Connection
Properties will include different information:</t>
      <ul spacing="normal">
        <li>
          <t>The Connection state, which can be one of the following:
Establishing, Established, Closing, or Closed (see <xref target="conn-state"/>).</t>
        </li>
        <li>
          <t>Whether the Connection can be used to send data (see <xref target="conn-send-data"/>).
A Connection can not cannot be used
for sending if the Connection was created with the Selection Property
<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="msg-final"/>.</t>
        </li>
        <li>
          <t>Whether the Connection can be used to receive data (see <xref target="conn-receive-data"/>).
A Connection cannot be
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
marked as <tt>Final</tt> was received. See received (see <xref target="receiving-final-messages"/>. target="receiving-final-messages"/>). The latter
is only supported by certain transport protocols, e.g., by TCP as a half-closed
connection.</t>
        </li>
        <li>
          <t>For Connections that are Established, Closing, or Closed:
Connection Properties (<xref target="connection-props"/>) of the
actual protocols that were selected and instantiated, and Selection
Properties that the application specified on the Preconnection.
Selection Properties of type <tt>Preference</tt> will be exposed as boolean values
indicating whether or not the property applies to the selected transport.
Note that the instantiated Protocol Stack might not match all
Protocol Selection Properties that the application specified on the
Preconnection.</t>
        </li>
        <li>
          <t>For Connections that are Established: Transport Services system implementations
ought to provide information concerning the
path(s) used by the Protocol Stack. This can be derived from local PVD PvD information,
measurements by the Protocol Stack, or other sources.
For example, a Transport System transport system that is configured to receive and process PVD PvD information
<xref target="RFC7556"/> could also provide network configuration information for the chosen path(s).</t>
        </li>
      </ul>
      <section anchor="connection-props">
        <name>Generic Connection Properties</name>
        <t>Generic Connection Properties are defined independent independently of the chosen Protocol Stack
and therefore Stack; therefore, they are available on all Connections.</t>
        <t>Many Connection Properties have a corresponding Selection Property that
enables applications to express their preference for protocols providing a supporting transport feature.</t>
        <section anchor="conn-recv-checksum">
          <name>Required Minimum Corruption Protection Coverage for Receiving</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>recvChecksumLen</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Integer (non-negative) or <tt>Full Coverage</tt></t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t><tt>Full Coverage</tt></t>
            </dd>
          </dl>
          <t>If this property is an Integer, it specifies the minimum number of bytes in a received
Message that need to be covered by a checksum.
A receiving endpoint will not forward Messages that have less coverage
to the application. The application is responsible for handling
any corruption within the non-protected part of the Message <xref target="RFC8085"/>.
A special value of 0 means that a received packet might also have a zero checksum field,
and the enumerated value <tt>Full Coverage</tt> means
that the entire Message needs to be protected by a checksum. An implementation
is supposed to express <tt>Full Coverage</tt> in an environment-typical way, e.g., as a Union type or special value.</t>
        </section>
        <section anchor="conn-priority">
          <name>Connection Priority</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>connPriority</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Integer (non-negative)</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>100</t>
            </dd>
          </dl>
          <t>This property is a non-negative Integer representing the
priority of this Connection
relative to other Connections in the same
Connection Group. A numerically lower value reflects a higher priority. It has no effect
on Connections not part of a Connection
Group. As noted in <xref target="groups"/>, this property is not entangled when Connections
are cloned, i.e., changing the Priority on one Connection in a Connection Group
does not change it on the other Connections in the same Connection Group.
No guarantees of a specific behavior regarding Connection Priority are given;
a Transport Services system could ignore this property. See <xref target="priority-in-taps"/> for more details.</t>
        </section>
        <section anchor="conn-timeout">
          <name>Timeout for Aborting Connection</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>connTimeout</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Numeric (positive) or <tt>Disabled</tt></t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t><tt>Disabled</tt></t>
            </dd>
          </dl>

<!--[rfced] Would the following update be acceptable?  Something seems
     off about "adjusting...will only take effect".

Original:
   Adjusting this property will only take effect when the underlying
   stack supports sending keep-alive packets.

Perhaps:
   Adjustments to this property will only take effect when the underlying
   stack supports sending keep-alive packets.

-->

          <t>If this property is Numeric, it specifies how long to wait before deciding that an active Connection has
failed when trying to reliably deliver data to the Remote Endpoint. Adjusting this property
will only take effect when the underlying stack supports reliability. If this property has the enumerated
value <tt>Disabled</tt>, it means that no timeout is scheduled. A Transport Services API
could express <tt>Disabled</tt> in an environment-typical way, e.g., as a Union type or special value.</t>
        </section>
        <section anchor="keep-alive-timeout">
          <name>Timeout for keep alive packets</name> Keep-Alive Packets</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>keepAliveTimeout</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Numeric (positive) or <tt>Disabled</tt></t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t><tt>Disabled</tt></t>
            </dd>
          </dl>
          <t>A Transport Services API can request a protocol that supports sending keep alive keep-alive packets (<xref target="keep-alive"/>).
If this property is Numeric, it specifies the maximum length of time an idle Connection (one for which no transport
packets have been sent) ought to wait before
the Local Endpoint sends a keep-alive packet to the Remote Endpoint. Adjusting this property
will only take effect when the underlying stack supports sending keep-alive packets.
Guidance on setting this value for connection-less connectionless transports is
provided in <xref target="RFC8085"/>.
A value greater than the Connection timeout (<xref target="conn-timeout"/>) or the enumerated value <tt>Disabled</tt> will disable the sending of keep-alive packets. A Transport Services API
could express <tt>Disabled</tt> in an environment-typical way, e.g., as a Union type or special value.</t>
        </section>
        <section anchor="conn-scheduler">
          <name>Connection Group Transmission Scheduler</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>connScheduler</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Enumeration</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Weighted Fair Queueing (see <xref section="3.6" sectionFormat="of" target="RFC8260"/>)</t>
            </dd>
          </dl>
          <t>This property specifies which scheduler is used among Connections within
a Connection Group to apportion the available capacity according to Connection priorities
(see <xref target="groups"/> Sections&nbsp;<xref target="groups" format="counter"/> and <xref target="conn-priority"/>). target="conn-priority" format="counter"/>). A set of schedulers is
described in <xref target="RFC8260"/>.</t>
        </section>
        <section anchor="prop-cap-profile">
          <name>Capacity Profile</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>connCapacityProfile</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Enumeration</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Default Profile (Best Effort)</t>
            </dd>
          </dl>
          <t>This property specifies the desired network treatment for traffic sent by the
application and the tradeoffs trade-offs the application is prepared to make in path and
protocol selection to receive that desired treatment. When the capacity profile
is set to a value other than Default, the Transport Services system SHOULD <bcp14>SHOULD</bcp14> select paths
and configure protocols to optimize the tradeoff trade-off between delay, delay variation, and
efficient use of the available capacity based on the capacity profile specified. How this is realized
is implementation-specific. implementation specific. The capacity profile MAY <bcp14>MAY</bcp14> also be used
to set markings on the wire for Protocol Stacks supporting this. this action.
Recommendations for use with DSCP DSCPs are provided below for each profile; note that
when a Connection is multiplexed, the guidelines in <xref section="6" sectionFormat="of" target="RFC7657"/> apply.</t>
          <t>The following values are valid for the capacity profile:</t>
          <dl>
            <dt>Default:</dt>
            <dd>
              <t>The application provides no information about its expected capacity
  profile. Transport Services systems that
  map the requested capacity profile onto to per-connection DSCP signaling
  SHOULD
  <bcp14>SHOULD</bcp14> assign the DSCP Default Forwarding <xref target="RFC2474"/> Per Hop Behaviour (PHB).</t> Behavior (PHB) <xref target="RFC2474"/>.</t>
            </dd>
            <dt>Scavenger:</dt>
            <dd>
              <t>The application is not interactive. It expects to send
  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
  the traffic to a lower-effort service. Transport Services systems that
  map the requested capacity profile onto to per-connection DSCP signaling
  SHOULD
  <bcp14>SHOULD</bcp14> assign the DSCP Less "Less than Best Effort best effort" PHB
  <xref target="RFC8622"/> PHB.</t> target="RFC8622"/>.</t>
            </dd>
            <dt>Low Latency/Interactive:</dt>

<!--[rfced] We had a few questions about the following text:

Original:
This can be used by the system to disable the coalescing of multiple
small Messages into larger packets (Nagle's algorithm);..

a) How may we clarify the use of "This"?

b) Should a citation point the reader to more information on Nagle's
algorithm?

-->

            <dd>
              <t>The application is interactive, interactive and prefers loss to
  latency. Response time SHOULD <bcp14>SHOULD</bcp14> be optimized at the expense of delay variation
  and efficient use of the available capacity when sending on this Connection. This can be
  used by the system to disable the coalescing of multiple small Messages into
  larger packets (Nagle's algorithm); to prefer immediate acknowledgment acknowledgement from
  the peer endpoint when supported by the underlying transport; and so on.
  Transport Services systems that map the requested capacity profile onto to per-connection DSCP signaling without multiplexing SHOULD <bcp14>SHOULD</bcp14> assign a DSCP Assured Forwarding (AF41,AF42,AF43,AF44) PHB <xref target="RFC2597"/> PHB. 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 PHBs as discussed in <xref target="RFC5865"/> PHBs.</t> target="RFC5865"/>.</t>
            </dd>
            <dt>Low Latency/Non-Interactive:</dt>
            <dd>
              <t>The application prefers loss to latency, latency but is
  not interactive. Response time SHOULD <bcp14>SHOULD</bcp14> be optimized at the expense of delay
  variation and efficient use of the available capacity when sending on this Connection. Transport
  system implementations that map the requested capacity profile onto to
  per-connection DSCP signaling without multiplexing SHOULD <bcp14>SHOULD</bcp14> assign a DSCP
  Assured Forwarding (AF21,AF22,AF23,AF24) PHB <xref target="RFC2597"/> PHB.</t> target="RFC2597"/>.</t>
            </dd>
            <dt>Constant-Rate Streaming:</dt>
            <dd>
              <t>The application expects to send/receive data at a
  constant rate after Connection establishment. Delay and delay variation SHOULD <bcp14>SHOULD</bcp14>
  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.
  A transport can interpret this capacity profile as preferring a circuit
  breaker <xref target="RFC8084"/> to a rate-adaptive congestion controller. Transport
  system implementations that map the requested capacity profile onto to
  per-connection DSCP signaling without multiplexing SHOULD <bcp14>SHOULD</bcp14> assign a DSCP
  Assured Forwarding (AF31,AF32,AF33,AF34) PHB <xref target="RFC2597"/> PHB.</t> target="RFC2597"/>.</t>
            </dd>
            <dt>Capacity-Seeking:</dt>
            <dd>
              <t>The application expects to send/receive data at the
  maximum rate allowed by its congestion controller over a relatively long
  period of time. Transport Services systems that map the requested
  capacity profile onto to per-connection DSCP signaling without multiplexing
  SHOULD
  <bcp14>SHOULD</bcp14> assign a DSCP Assured Forwarding (AF11,AF12,AF13,AF14) PHB <xref target="RFC2597"/> PHB
  per <xref section="4.8" sectionFormat="of" target="RFC4594"/>.</t>
            </dd>
          </dl>
          <t>The capacity profile for a selected Protocol Stack may be modified on a
per-Message basis using the Transmission Profile Message Property; see
<xref target="send-profile"/>.</t>
        </section>
        <section anchor="multipath-policy">
          <name>Policy for using Using Multipath Transports</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>multipathPolicy</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Enumeration</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>Handover</t>
            </dd>
          </dl>
          <t>This property specifies the local policy for transferring data across multiple paths between the same end hosts if Multipath Transport is not set to Disabled (see <xref target="multipath-mode"/>). Possible values are:</t> are as follows:</t>
          <dl>
            <dt>Handover:</dt>
            <dd>
              <t>The Connection ought only to attempt to migrate between different paths when the original path is lost or becomes unusable. The thresholds used to declare a path unusable are implementation specific.</t>
            </dd>
            <dt>Interactive:</dt>
            <dd>
              <t>The Connection ought only to attempt to minimize the latency for interactive traffic patterns by transmitting data across multiple paths when this 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
lower-latency path, the scheduling might choose to use a higher-latency path. Traffic can be scheduled such that data may be transmitted
on multiple paths in parallel to achieve a lower latency. The specific scheduling algorithm is implementation-specific.</t> implementation specific.</t>
            </dd>
            <dt>Aggregate:</dt>
            <dd>
              <t>The Connection ought to attempt to use multiple paths in parallel to maximize available capacity and possibly overcome the capacity limitations of the individual paths. The actual strategy is implementation specific.</t>
            </dd>
          </dl>
          <t>Note that this is a local choice – choice: the Remote Endpoint can choose a different policy.</t>
        </section>
        <section anchor="bounds-on-send-or-receive-rate">
          <name>Bounds on Send or Receive Rate</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>minSendRate / minRecvRate / maxSendRate / maxRecvRate</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Numeric (positive) or <tt>Unlimited</tt> / Numeric (positive) or <tt>Unlimited</tt> / Numeric (positive) or <tt>Unlimited</tt> / Numeric (positive) or <tt>Unlimited</tt></t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t><tt>Unlimited</tt> / <tt>Unlimited</tt> / <tt>Unlimited</tt> / <tt>Unlimited</tt></t>
            </dd>
          </dl>
          <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), rates) and/or a
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. i.e., do not consider the header overhead
from protocols used by the Transport Services system. The values are specified in bits per second, second
and assumed to be measured over one-second time intervals. E.g., For example, specifying a maxSendRate of X bits per second
means that, from the moment at which the property value is chosen, not more than X bits will be send sent in any
following second. The enumerated value <tt>Unlimited</tt> indicates that no bound is specified.
A Transport Services API could express <tt>Unlimited</tt> in an environment-typical way, e.g., as a Union type or special value.</t>
        </section>
        <section anchor="group-connection-limit">
          <name>Group Connection Limit</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>groupConnLimit</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Numeric (positive) or <tt>Unlimited</tt></t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t><tt>Unlimited</tt></t>
            </dd>
          </dl>
          <t>If this property is Numeric, it controls the number of Connections that can be accepted from
a peer as new members of the Connection's group. Similar to <tt>SetNewConnectionLimit</tt>,
this limits the number of <tt>ConnectionReceived</tt> events that will occur, but constrained
to the group of the Connection associated with this property. For a multi-streaming transport,
this limits the number of allowed streams.  A Transport Services API
could express <tt>Unlimited</tt> in an environment-typical way, e.g., as a Union type or special value.</t>
        </section>
        <section anchor="isolate-session">
          <name>Isolate Session</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>isolateSession</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Boolean</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t><tt>false</tt></t>
            </dd>
          </dl>
          <t>When set to <tt>true</tt>, this property will initiate new Connections using as little
cached information (such as session tickets or cookies) as possible from
previous Connections that are not in the same Connection Group. Any state generated by this
Connection will only be shared with Connections in the same Connection Group. Cloned Connections
will use saved state from within the Connection Group.
	  This is used for separating Connection Contexts as specified in <xref section="4.2.3" sectionFormat="of" target="I-D.ietf-taps-arch"/>.</t>
          <t>Note target="RFC9621"/>.</t>

<!--[rfced] May we update as follows or does this update change the
     meaning?

Original:
Note that this does not guarantee no leakage of information, as
implementations might not be able to fully isolate all caches (e.g.
RTT estimates).

Perhaps:
Note that this does not guarantee that information has not leaked, as
implementations might not be able to fully isolate all caches (e.g.,
RTT estimates).
-->

          <t>Note that this does not guarantee no leakage of information, as
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 anchor="read-only-conn-prop">
          <name>Read-only
          <name>Read-Only Connection Properties</name>
          <t>The following generic Connection Properties are read-only, i.e. i.e., they cannot be changed by an application.</t>
          <section anchor="conn-state">
            <name>Connection state</name> State</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>connState</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Enumeration</t>
              </dd>
            </dl>
            <t>This property informs provides information about the current state of the Connection. Possible values are: are <tt>Establishing</tt>, <tt>Established</tt>, <tt>Closing</tt> <tt>Closing</tt>, or <tt>Closed</tt>; for <tt>Closed</tt>. For more details on Connection state, see <xref target="state-ordering"/>.</t>
          </section>
          <section anchor="conn-send-data">
            <name>Can Send Data</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>canSend</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Boolean</t>
              </dd>
            </dl>
            <t>This property can be queried to learn whether the Connection can be used to send data.</t>
          </section>
          <section anchor="conn-receive-data">
            <name>Can Receive Data</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>canReceive</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Boolean</t>
              </dd>
            </dl>
            <t>This property can be queried to learn whether the Connection can be used to receive data.</t>
          </section>
          <section anchor="conn-max-msg-notfrag">
            <name>Maximum Message Size Before Fragmentation or Segmentation</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>singularTransmissionMsgMaxLen</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Integer (non-negative) or <tt>Not applicable</tt></t>
              </dd>
            </dl>
            <t>This property, if applicable, represents the maximum Message size that can be
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
Maximum Message Size on Send.
It exposes a readable value to the application
based on the Maximum Packet Size (MPS). The value of this property can change over time (and can be updated by via Datagram PLPMTUD Packetization Layer Path MTU Discovery (DPLPMTUD) <xref target="RFC8899"/>).
This value allows a sending stack to avoid unwanted fragmentation at the
network-layer
network layer or segmentation by the transport layer before
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
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 anchor="conn-max-msg-send">
            <name>Maximum Message Size on Send</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>sendMsgMaxLen</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Integer (non-negative)</t>
              </dd>
            </dl>
            <t>This property represents the maximum Message size that an application can send.
It is specified as the number of bytes. A value of 0 indicates that sending is not possible.</t>
          </section>
          <section anchor="conn-max-msg-recv">
            <name>Maximum Message Size on Receive</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>recvMsgMaxLen</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Integer (non-negative)</t>
              </dd>
            </dl>
            <t>This property represents the maximum Message size that an application can receive.
It is specified as the number of bytes. A value of 0 indicates that receiving is not possible.</t>
          </section>
        </section>
      </section>
      <section anchor="tcp-uto">
        <name>TCP-specific
        <name>TCP-Specific Properties: User Timeout Option (UTO)</name>
        <t>These properties specify configurations for the TCP User Timeout Option (UTO).
This is a TCP-specific property, property that is only used
in the case that TCP becomes the chosen transport protocol
and protocol.
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>
        <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 Transport Services
<xref target="RFC8923"/>, where this feature was categorized as "functional".
This means that when a Transport Services system offers this feature,
the Transport Services API has to expose an interface to the application. Otherwise, the implementation might
violate assumptions by the application, which could cause the application to
fail.</t>
        <t>All of the below properties are optional (e.g., it is possible to specify <tt>User Timeout Enabled</tt> as <tt>true</tt>, <tt>true</tt>
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" sectionFormat="of" target="RFC5482"/>.</t>
        <section anchor="advertised-user-timeout">
          <name>Advertised User Timeout</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>tcp.userTimeoutValue</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Integer (positive)</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t>the TCP default</t>
            </dd>
          </dl>
          <t>This time value is advertised via the TCP User Timeout Option (UTO) <xref target="RFC5482"/> to the Remote Endpoint 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 anchor="user-timeout-enabled">
          <name>User Timeout Enabled</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>tcp.userTimeoutEnabled</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Boolean</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t><tt>false</tt></t>
            </dd>
          </dl>
          <t>This property controls whether the TCP UTO option is enabled for a
connection. This applies to both sending and receiving.</t>
        </section>
        <section anchor="timeout-changeable">
          <name>Timeout Changeable</name>
          <dl>
            <dt>Name:</dt>
            <dd>
              <t>tcp.userTimeoutChangeable</t>
            </dd>
            <dt>Type:</dt>
            <dd>
              <t>Boolean</t>
            </dd>
            <dt>Default:</dt>
            <dd>
              <t><tt>true</tt></t>
            </dd>
          </dl>
          <t>This property controls whether the TCP <tt>connTimeout</tt> (see <xref target="conn-timeout"/>)
can be changed
based on a UTO option received from the remote peer. This boolean becomes <tt>false</tt> when
<tt>connTimeout</tt> (see <xref target="conn-timeout"/>) is used.</t>
        </section>
      </section>
      <section anchor="connection-lifecycle-events">
        <name>Connection Lifecycle Events</name>
        <t>During the lifetime of a Connection there are events that can occur when configured.</t>
        <section anchor="soft-errors">
          <name>Soft Errors</name>
          <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 Stack 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>
          <artwork><![CDATA[
Connection -> SoftError<>
]]></artwork>
        </section>
        <section anchor="conn-path-change">
          <name>Path change</name> Change</name>
          <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
and paths are added or removed, the set of local endpoints changes, or a handover has been performed.</t>
          <artwork><![CDATA[
Connection -> PathChange<>
]]></artwork>
        </section>
      </section>
    </section>
    <section anchor="datatransfer">
      <name>Data Transfer</name>
      <t>Data is sent and received as Messages, which allows the application
to communicate the boundaries of the data being transferred.</t>
      <section anchor="msg">
        <name>Messages and Framers</name>

<!--[rfced] In the following, please review the use of "identify Send
     events".  Is there text missing before or after?  Otherwise,
     who/what is the subject of the verb "identify"?  Please rephrase.

Original:
   Each Message has an optional Message Context, which allows adding
   Message Properties, identify Send events related to a specific
   Message or to inspect meta-data related to the Message sent.

-->

        <t>Each Message has an optional Message Context, which allows adding Message Properties, identify <tt>Send</tt> events related to a specific Message or to inspect meta-data metadata related to the Message sent. Framers can be used to extend or modify the Message data with additional information that can be processed at the receiver to detect message boundaries.</t>
        <section anchor="msg-ctx">
          <name>Message Contexts</name>
          <t>Using the MessageContext object, the application can set and retrieve meta-data metadata of the Message, including Message Properties (see <xref target="message-props"/>) and framing meta-data metadata (see <xref target="framing-meta"/>).
Therefore, a MessageContext object can be passed to the <tt>Send</tt> action and is returned by each event related to <tt>Send</tt> and <tt>Receive</tt> related event.</t> <tt>Receive</tt>.</t>
          <t>Message Properties can be set and queried using the Message Context:</t>
          <artwork><![CDATA[
MessageContext.add(property, value)
PropertyValue := MessageContext.get(property)
]]></artwork>
          <t>These Message Properties can be generic properties or Protocol-specific Properties.</t>
          <t>For MessageContexts returned by <tt>Send</tt> events (see <xref target="send-events"/>) and <tt>Receive</tt> events (see <xref target="receive-events"/>), the application can query information about the Local and Remote Endpoint:</t>
          <artwork><![CDATA[
RemoteEndpoint := MessageContext.GetRemoteEndpoint()
LocalEndpoint := MessageContext.GetLocalEndpoint()
]]></artwork>
        </section>
        <section anchor="framing">
          <name>Message Framers</name>
          <t>Although most applications communicate over a network using well-formed
Messages, the boundaries and metadata of the Messages are often not
directly communicated by the transport protocol itself. For example,
HTTP applications send and receive HTTP messages over a byte-stream
transport, requiring that the boundaries of HTTP messages be parsed
from the stream of bytes.</t>
          <t>Message Framers allow extending a Connection's Protocol Stack to define
how to encapsulate or encode outbound Messages, Messages and how to decapsulate
or decode inbound data into Messages. Message Framers allow message
boundaries to be preserved when using a Connection object, even when
using byte-stream transports. This is designed based on the fact
that many of the current application protocols in use at the time of writing evolved over TCP, which
does not provide message boundary preservation, and since preservation; because many of these
protocols require message boundaries to function, each application layer application-layer
protocol has defined its own framing.</t>
          <t>To use a Message Framer, the application adds it to its Preconnection object.
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
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
or handshake (see <xref target="RFC9329"/> for an example of such a framing protocol).</t>
          <figure anchor="fig-framer-stack">
            <name>Protocol Stack showing Showing a Message Framer</name>
            <artwork><![CDATA[
  Initiate()   Send()   Receive()   Close()
      |          |         ^          |
      |          |         |          |
 +----v----------v---------+----------v-----+
 |                Connection                |
 +----+----------+---------^----------+-----+
      |          |         |          |
      |      +-----------------+      |
      |      |    Messages     |      |
      |      +-----------------+      |
      |          |         |          |
 +----v----------v---------+----------v-----+
 |                Framer(s)                 |
 +----+----------+---------^----------+-----+
      |          |         |          |
      |      +-----------------+      |
      |      |   Byte-stream   |      |
      |      +-----------------+      |
      |          |         |          |
 +----v----------v---------+----------v-----+
 |         Transport Protocol Stack         |
 +------------------------------------------+
]]></artwork>
          </figure>
          <t>Note that while Message Framers add the most value when placed above
a protocol that otherwise does not preserve message boundaries, they can
also be used with datagram- or message-based protocols. In these cases,
they add a transformation to further encode or encapsulate, encapsulate
and can potentially support packing multiple application-layer Messages
into individual transport datagrams.</t>
          <t>The API to implement a Message Framer can vary vary, depending on the implementation;
guidance on implementing Message Framers can be found in <xref target="I-D.ietf-taps-impl"/>.</t> target="RFC9623"/>.</t>
          <section anchor="adding-message-framers-to-pre-connections"> anchor="adding-message-framers-to-preconnections">
            <name>Adding Message Framers to Pre-Connections</name> Preconnections</name>
            <t>The Message Framer object can be added to one or more Preconnections
to run on top of transport protocols. Multiple Framers can be added to a Preconnection;
in this case, the Framers operate as a framing stack, i.e. i.e., the last one added runs
first when framing outbound Messages, and last when parsing inbound data.</t>
            <t>The following example adds a basic HTTP Message Framer to a Preconnection:</t>
            <artwork><![CDATA[
framer := NewHTTPMessageFramer()
Preconnection.AddFramer(framer)
]]></artwork>
            <t>Since Message Framers pass from Preconnection to Listener or Connection, addition of
Framers must happen before any operation that might result in the creation of a Connection.</t>
          </section>
          <section anchor="framing-meta">
            <name>Framing Meta-Data</name> Metadata</name>
            <t>When sending Messages, applications can add Framer-specific
properties to a MessageContext (<xref target="msg-ctx"/>) with the <tt>add</tt> action.
To avoid naming conflicts, the property
names SHOULD <bcp14>SHOULD</bcp14> be prefixed with a namespace referencing the
framer implementation or the protocol it implements as described
in <xref target="property-names"/>.</t>
            <t>This mechanism can be used, for example, to set the type of a Message for a TLV format.
The namespace of values is custom for each unique Message Framer.</t>
            <artwork><![CDATA[
messageContext := NewMessageContext()
messageContext.add(framer, key, value)
Connection.Send(messageData, messageContext)
]]></artwork>
            <t>When an application receives a MessageContext in a <tt>Receive</tt> event,
it can also look to see if a value was set by a specific Message Framer.</t>
            <artwork><![CDATA[
messageContext.get(framer, key) -> value
]]></artwork>
            <t>For example, if an HTTP Message Framer is used, the values could correspond
to HTTP headers:</t>
            <artwork><![CDATA[
httpFramer := NewHTTPMessageFramer()
...
messageContext := NewMessageContext()
messageContext.add(httpFramer, "accept", "text/html")
]]></artwork>
          </section>
        </section>
        <section anchor="message-props">
          <name>Message Properties</name>
          <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 protocols supporting the
	  Connection) can include this information in the Message Context passed to the <tt>Send</tt> action. For other uses of the Message Context, see <xref target="msg-ctx"/>.</t>

<!--[rfced] Please review our updates to the following text to ensure
     we have maintained the intended meaning.

Original:
For example, it would not make sense to have the beginning of a
Message expire, but allow the end of a Message to still be sent.

Current:
For example, it would not make sense to have the beginning of a
Message expire but allow the end of the Message to still be sent.

-->

          <t>Message Properties are per-Message, not per-<tt>Send</tt> per-<tt>Send</tt>, if partial Messages
are sent (<xref target="send-partial"/>). All data blocks associated with a single Message
share properties specified in the Message Contexts. For example, it would not
make sense to have the beginning of a Message expire, expire but allow the end of a the Message to still be sent.</t>
          <t>A MessageContext object contains metadata for the Messages to be sent or received.</t>
          <artwork><![CDATA[
messageData := "hello"
messageContext := NewMessageContext()
messageContext.add(parameter, value)
Connection.Send(messageData, messageContext)
]]></artwork>
          <t>The simpler form of <tt>Send</tt>, which does not take any MessageContext, is equivalent to passing a default MessageContext without adding any Message Properties.</t>
          <t>If an application wants to override Message Properties for a specific Message,
it can acquire an empty MessageContext object and add all desired Message
Properties to that object. It can then reuse the same MessageContext object
for sending multiple Messages with the same properties.</t>
          <t>Properties can be added to a MessageContext object only before the context is used
for sending. Once a MessageContext has been used with a <tt>Send</tt> action, further modifications
to the MessageContext object do not have any effect on this <tt>Send</tt> call. Message Properties
that are not added to a MessageContext object before using the context for sending will either
take a specific default value or be configured based on Selection or Connection Properties
of the Connection that is associated with the <tt>Send</tt> call.
This initialization behavior is defined per Message Property below.</t>
          <t>The Message Properties could be inconsistent with the properties of the Protocol Stacks
underlying the Connection on which a given Message is sent. For example,
a Protocol Stack must be able to provide ordering if the <tt>msgOrdered</tt>
property of a Message is enabled. Sending a Message with Message Properties
inconsistent with the Selection Properties of the Connection yields an error.</t>
          <t>If a Message Property contradicts a Connection Property, and
if this per-Message behavior can be supported, it overrides the Connection
Property for the specific Message. For example, if
<tt>reliability</tt> is set to <tt>Require</tt> and a protocol
with configurable per-Message reliability is used, setting
<tt>msgReliable</tt> to <tt>false</tt> for a particular Message will
allow this Message to be sent without any reliability guarantees. Changing
the <tt>msgReliable</tt> Message Property is only possible for
Connections that were established enabling the Selection Property
<tt>perMsgReliability</tt>. If the contradicting Message Property
cannot be supported by the Connection (such as requiring reliability
on a Connection that uses an unreliable protocol), the <tt>Send</tt> action
will result in a <tt>SendError</tt> event.</t>
          <t>The following Message Properties in the following subsections are supported:</t> supported.</t>
          <section anchor="msg-lifetime">
            <name>Lifetime</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>msgLifetime</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Numeric (positive)</t>
              </dd>
              <dt>Default:</dt>
              <dd>
                <t>infinite</t>
              </dd>
            </dl>
            <t>The Lifetime specifies how long a particular Message can wait in the Transport Services system
before it is sent to the
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 guaranteed
that a Message will not be sent when its Lifetime has expired.</t>
            <t>Setting a Message's Lifetime to infinite indicates that the application does
not wish to apply a time constraint on the transmission of the Message, but it does not express a need for
reliable delivery; reliability is adjustable per Message via the <tt>perMsgReliability</tt>
property (see <xref target="msg-reliable-message"/>). The type and units of Lifetime are implementation-specific.</t> implementation specific.</t>
          </section>
          <section anchor="msg-priority">
            <name>Priority</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>msgPriority</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Integer (non-negative)</t>
              </dd>
              <dt>Default:</dt>
              <dd>
                <t>100</t>
              </dd>
            </dl>
            <t>This property specifies the priority of a Message, relative to other Messages sent over the
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
yield to a Message with Priority 0, and so on. Priorities can be used as a
sender-side scheduling construct only, only or be used to specify priorities on the
wire for Protocol Stacks supporting prioritization.</t>
            <t>Note that this property is not a per-Message override of <tt>connPriority</tt>
- <tt>connPriority</tt>;
see <xref target="conn-priority"/>. The priority properties might interact, but they can be used
independently and be realized by different mechanisms; see <xref target="priority-in-taps"/>.</t>
          </section>
          <section anchor="msg-ordered">
            <name>Ordered</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>msgOrdered</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Boolean</t>
              </dd>
              <dt>Default:</dt>
              <dd>
                <t>the queried Boolean value of the Selection Property <tt>preserveOrder</tt> (<xref target="prop-ordering"/>)</t>
              </dd>
            </dl>
            <t>The order in which Messages were submitted for transmission via the <tt>Send</tt> action will be preserved on delivery via <tt>Receive</tt> events for all Messages on a Connection that have this Message Property set to <tt>true</tt>.</t>
            <t>If <tt>false</tt>, the Message is delivered to the receiving application without preserving the ordering.
This property is used for protocols that support preservation of data ordering,
see ordering
(see <xref target="prop-ordering"/>, target="prop-ordering"/>) but allow out-of-order delivery for certain Messages, e.g., by multiplexing independent Messages onto
different streams.</t>
            <t>If it is not configured by the application before sending, this property's default value
will be based on the Selection Property <tt>preserveOrder</tt> of the Connection
associated with the <tt>Send</tt> action.</t>
          </section>
          <section anchor="msg-safelyreplayable">
            <name>Safely Replayable</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>safelyReplayable</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Boolean</t>
              </dd>
              <dt>Default:</dt>
              <dd>
                <t><tt>false</tt></t>
              </dd>
            </dl>
            <t>If <tt>true</tt>, <tt>safelyReplayable</tt> specifies that a Message 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
certain 0-RTT establishment techniques, where retransmission of the 0-RTT data
could cause the remote application to receive the Message multiple times.</t>
            <t>For protocols that do not protect against duplicated Messages,
e.g., UDP, all Messages need to be marked as "safely replayable" by enabling this property.
To enable protocol selection to choose such a protocol,
<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
individual Messages MUST <bcp14>MUST</bcp14> result in a <tt>SendError</tt>.</t>
          </section>
          <section anchor="msg-final">
            <name>Final</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>final</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Boolean</t>
              </dd>
              <dt>Default:</dt>
              <dd>
                <t><tt>false</tt></t>
              </dd>
            </dl>
            <t>If <tt>true</tt>, this indicates a Message is the last that
the application will send on a Connection. This allows underlying protocols
to indicate to the Remote Endpoint that the Connection has been effectively
closed in the sending direction. For example, TCP-based Connections can
send a FIN once a Message marked as Final has been completely sent,
indicated by marking endOfMessage. Protocols that do not support signalling signaling
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 Messages.
The Final property overrides Priority and any other property that would re-order reorder
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 cause a <tt>SendError</tt> event.</t>
          </section>
          <section anchor="msg-checksum">
            <name>Sending Corruption Protection Length</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>msgChecksumLen</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Integer (non-negative) or <tt>Full Coverage</tt></t>
              </dd>
              <dt>Default:</dt>
              <dd>
                <t><tt>Full Coverage</tt></t>
              </dd>
            </dl>
            <t>If this property is an Integer, it specifies the minimum length of the section of a sent Message,
starting from byte 0, that the application requires to be delivered without
corruption due to lower layer lower-layer errors. It is used to specify options for simple
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
that the entire Message needs to be protected by a checksum. Only <tt>Full Coverage</tt> is
guaranteed,
guaranteed: any other requests are advisory, which may result in <tt>Full Coverage</tt> being applied.</t>
          </section>
          <section anchor="msg-reliable-message">
            <name>Reliable Data Transfer (Message)</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>msgReliable</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Boolean</t>
              </dd>
              <dt>Default:</dt>
              <dd>
                <t>the queried Boolean value of the Selection Property <tt>reliability</tt> (<xref target="prop-reliable"/>)</t>
              </dd>
            </dl>
            <t>When true, <tt>true</tt>, this property specifies that a Message should be sent in such a way
that the transport protocol ensures that all data is received by the Remote Endpoint.
Changing the <tt>msgReliable</tt> property on Messages
is only possible for Connections that were established enabling the Selection Property <tt>perMsgReliability</tt>.
When this is not the case, changing <tt>msgReliable</tt> will generate an error.</t>
            <t>Disabling this property indicates that the Transport Services system could disable retransmissions
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 property's default value
will be based on the Selection Property <tt>reliability</tt> of the Connection
associated with the <tt>Send</tt> action.</t>
          </section>
          <section anchor="send-profile">
            <name>Message Capacity Profile Override</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>msgCapacityProfile</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Enumeration</t>
              </dd>
              <dt>Default:</dt>
              <dd>
                <t>inherited from the Connection Property <tt>connCapacityProfile</tt> (<xref target="prop-cap-profile"/>)</t>
              </dd>
            </dl>
            <t>This enumerated property specifies the application's preferred tradeoffs trade-offs for
sending this Message; it is a per-Message override of the <tt>connCapacityProfile</tt>
Connection Property (see <xref target="prop-cap-profile"/>).
If it is not configured by the application before sending, this property's default value
will be based on the Connection Property <tt>connCapacityProfile</tt> of the Connection
associated with the <tt>Send</tt> action.</t>
          </section>
          <section anchor="send-singular">
            <name>No Network-Layer Fragmentation</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>noFragmentation</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Boolean</t>
              </dd>
              <dt>Default:</dt>
              <dd>
                <t><tt>false</tt></t>
              </dd>
            </dl>
            <t>This property specifies that a Message should be sent and received
without network-layer fragmentation, if possible. It can be used
to avoid network layer network-layer fragmentation when transport segmentation is preferred.</t>
            <t>This only takes effect when the transport uses a network layer that supports this functionality.
When it does take effect, setting this property to
<tt>true</tt> will cause the sender to avoid network-layer source fragmentation.
When using IPv4, this will result in the Don't Fragment (DF) bit being set in the IP header.</t>
            <t>Attempts to send a Message with this property that result in a size greater than the
transport's current estimate of its maximum packet size (<tt>singularTransmissionMsgMaxLen</tt>)
	    can result in transport segmentation when permitted, permitted or in a <tt>SendError</tt>.</t>
            <t>Note:

<!--[rfced] May we rephrase this text as follows?  Or does this edit
     change the meaning?

Original:
   Note: noSegmentation is used when it is desired to only send a
   Message within a single network packet.

Perhaps:
   Note: noSegmentation is used when only sending a
   Message within a single network packet is desired.

-->

            <t>Note: noSegmentation is used when it is desired to only sending a Message within
a single network packet.</t>

<!-- [rfced] Please review whether the "Note:" items in this document
should be in the <aside> element.  <aside> is defined as "a container
for content that is semantically less important or tangential to the
content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).

For example:

   Note: noSegmentation is used when it is desired to only send a
   Message within a single network packet.

 -->

          </section>
          <section anchor="no-transport-fragmentation">
            <name>No Segmentation</name>
            <dl>
              <dt>Name:</dt>
              <dd>
                <t>noSegmentation</t>
              </dd>
              <dt>Type:</dt>
              <dd>
                <t>Boolean</t>
              </dd>
              <dt>Default:</dt>
              <dd>
                <t><tt>false</tt></t>
              </dd>
            </dl>
            <t>When set to <tt>true</tt>, this property requests that the transport layer
to not provide segmentation of Messages larger than the
maximum size permitted by the network layer, layer and also
to that it avoid network-layer source fragmentation of Messages.
When running over IPv4, setting this property to
<tt>true</tt> will result in a sending endpoint setting the
Don't Fragment bit in the IPv4 header of packets generated by the
transport layer.</t>
            <t>An
attempt to send a Message that results in a size greater than the
transport's current estimate of its maximum packet size (<tt>singularTransmissionMsgMaxLen</tt>)
will result in a <tt>SendError</tt>.
This only takes effect when the transport and network layer layers
support this functionality.</t>
          </section>
        </section>
      </section>
      <section anchor="sending">
        <name>Sending Data</name>
        <t>Once a Connection has been established, it can be used for sending Messages.
By default, <tt>Send</tt> enqueues a complete Message, Message
and takes optional per-Message properties (see <xref target="send-basic"/>). All <tt>Send</tt> actions
are asynchronous, asynchronous and deliver events (see <xref target="send-events"/>). Sending partial
Messages for streaming large data is also supported (see <xref target="send-partial"/>).</t>
        <t>Messages are sent on a Connection using the <tt>Send</tt> action:</t>
        <artwork><![CDATA[
Connection.Send(messageData, messageContext?, endOfMessage?)
]]></artwork>
        <t>where <tt>messageData</tt> is the data object to send, send and <tt>messageContext</tt> allows
adding Message Properties, identifying <tt>Send</tt> events related to a specific
Message or inspecting meta-data metadata related to the Message sent (see <xref target="msg-ctx"/>).</t>
        <t>The optional endOfMessage parameter supports partial sending and is described in
<xref target="send-partial"/>.</t>
        <section anchor="send-basic">
          <name>Basic Sending</name>
          <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>
          <artwork><![CDATA[
messageData := "hello"
Connection.Send(messageData)
]]></artwork>
          <t>The interpretation of a Message to be sent is dependent on the implementation, implementation and
	  on the constraints on the Protocol Stacks implied by the Connection’s Connection's transport properties.

<!--[rfced] Would this update be accurate?

Original:
For example, a Message could be the payload of a single datagram for a
UDP Connection; or an HTTP Request for an HTTP Connection.

Perhaps:
For example, a Message could be the payload of a single datagram for a
UDP Connection.  Another example would be an HTTP Request for an HTTP
Connection.

-->

For example, a Message could be the payload of
a single datagram for a UDP Connection; or an HTTP Request for an HTTP
Connection.</t>
          <t>Some transport protocols can deliver arbitrarily sized Messages, but other
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
allowed for a single Message. If a Message is too large to fit in the Maximum Message
Size for the Connection, the <tt>Send</tt> will fail with a <tt>SendError</tt> event (<xref target="send-error"/>). For
example, it is invalid to send a Message over a UDP connection that is larger than
the available datagram sending size.</t>
        </section>
        <section anchor="send-events">
          <name>Send Events</name>
          <t>Like all actions in the Transport Services API, the <tt>Send</tt> action is asynchronous. There are
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
to each call to <tt>Send</tt>.</t>
          <t>Note that that, if partial <tt>Send</tt> calls are used (<xref target="send-partial"/>), there will still be exactly
one <tt>Send</tt> event delivered for each call to <tt>Send</tt>. For example, if a Message
expired while two requests to <tt>Send</tt> data for that Message are outstanding,
there will be two <tt>Expired</tt> events delivered.</t>
          <t>The Transport Services API should allow the application to correlate which <tt>Send</tt> action resulted
in a particular <tt>Send</tt> event. The manner in which this correlation is indicated
is implementation-specific.</t> implementation specific.</t>
          <section anchor="sent">
            <name>Sent</name>
            <artwork><![CDATA[
Connection -> Sent<messageContext>
]]></artwork>
            <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
underlying Protocol Stack and is no longer the responsibility of
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
interface, moved into a kernel buffer, and so on) when the <tt>Sent</tt> event occurs
is implementation-specific. implementation specific. The <tt>Sent</tt> event contains a reference to the Message
Context of the Message to which it applies.</t>
            <t><tt>Sent</tt> events allow an application to obtain an understanding of the amount
of buffering it creates. That is, if an application calls the <tt>Send</tt> action multiple
times without waiting for a <tt>Sent</tt> event, it has created more buffer inside the
Transport Services system than an application that always waits for the <tt>Sent</tt> event before
calling the next <tt>Send</tt> action.</t>
          </section>
          <section anchor="expired">
            <name>Expired</name>
            <artwork><![CDATA[
Connection -> Expired<messageContext>
]]></artwork>
            <t>The <tt>Expired</tt> event occurs when a previous <tt>Send</tt> action expired before completion;
i.e. completion,
i.e., when the Message was not sent before its Lifetime (see <xref target="msg-lifetime"/>)
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 to the
Message Context of the Message to which it applies.</t>
          </section>
          <section anchor="send-error">
            <name>SendError</name>
            <artwork><![CDATA[
Connection -> SendError<messageContext, reason?>
]]></artwork>
            <t>A <tt>SendError</tt> occurs when a Message was not sent due to an error condition:
an attempt to send a Message that is too large for the system and
Protocol Stack to handle, some failure of the underlying Protocol Stack, or a
set of Message Properties not consistent with the Connection's transport
properties. The <tt>SendError</tt> contains a reference to the Message Context of the
Message to which it applies.</t>
          </section>
        </section>
        <section anchor="send-partial">
          <name>Partial Sends</name>
          <t>It is not always possible for an application to send all data associated with
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, time or the length of the Message
might be unknown or unbounded.</t>
          <t>Partial Message sending is supported by passing an endOfMessage Boolean
parameter to the <tt>Send</tt> action. This value is always <tt>true</tt> by default, and
the simpler forms of <tt>Send</tt> are equivalent to passing <tt>true</tt> for endOfMessage.</t>
          <t>The following example sends a Message in two separate calls to <tt>Send</tt>.</t> <tt>Send</tt>:</t>
          <artwork><![CDATA[
messageContext := NewMessageContext()
messageContext.add(parameter, value)

messageData := "hel"
endOfMessage := false
Connection.Send(messageData, messageContext, endOfMessage)

messageData := "lo"
endOfMessage := true
Connection.Send(messageData, messageContext, endOfMessage)
]]></artwork>
          <t>All data sent with the same MessageContext object will be treated as belonging
to the same Message, Message and will constitute an in-order series until the
endOfMessage is marked.</t>
        </section>
        <section anchor="send-batching">
          <name>Batching Sends</name>
          <t>To reduce the overhead of sending multiple small Messages on a Connection, the
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 possible, possible
and that sending any of the batched Messages can be delayed until the last Message
in the batch is enqueued.</t>
          <t>The semantics for starting and ending a batch can be implementation-specific, implementation specific but need
to allow multiple <tt>Send</tt> actions to be enqueued.</t>
          <artwork><![CDATA[
Connection.StartBatch()
Connection.Send(messageData)
Connection.Send(messageData)
Connection.EndBatch()
]]></artwork>
        </section>
        <section anchor="initiate-and-send">
          <name>Send on Active Open: InitiateWithSend</name>
          <t>For application-layer protocols where the Connection initiator also sends the
first Message, the <tt>InitiateWithSend</tt> action combines Connection initiation with
a first Message sent:</t>
          <artwork><![CDATA[
Connection := Preconnection.InitiateWithSend(messageData,
                                             messageContext?,
                                             timeout?)
]]></artwork>
          <t>Whenever possible, a MessageContext should be provided to declare the 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 is supported
by the available Protocol Stacks. When the selected stack(s) stack or stacks do not support transmitting data upon connection
establishment, <tt>InitiateWithSend</tt> is identical to <tt>Initiate</tt> followed by <tt>Send</tt>.</t>
          <t>Neither partial sends nor send batching are supported by <tt>InitiateWithSend</tt>.</t>
          <t>The events that are sent after <tt>InitiateWithSend</tt> are equivalent to those
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 because
the Connection could not be established will not result in a
<tt>SendError</tt> separate from the <tt>EstablishmentError</tt> signaling the failure of Connection
establishment.</t>
        </section>
        <section anchor="priority-in-taps">
          <name>Priority and the Transport Services API</name>
          <t>The Transport Services API provides two properties to allow a sender
to signal the relative priority of data transmission: <tt>msgPriority</tt>
            (see <xref target="msg-priority"/> target="msg-priority"/>) and <tt>connPriority</tt> (see <xref target="conn-priority"/>. target="conn-priority"/>).
These properties are designed to allow the expression
and implementation of a wide variety of approaches to transmission priority in
the transport and application layer, layers, including those which that do not appear on
the wire (affecting only sender-side transmission scheduling) as well as those
that do (e.g. (e.g., <xref target="RFC9218"/>. target="RFC9218"/>).
A Transport Services system gives no guarantees about how its expression of
relative priorities will be realized.</t>
          <t>The Transport Services API does order <tt>connPriority</tt> over
<tt>msgPriority</tt>. In the absence of other externalities
(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 in the same group.</t>
        </section>
      </section>
      <section anchor="receiving">
        <name>Receiving Data</name>
        <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
sending, the data is received in Messages. Receiving is an asynchronous
operation,
operation in which each call to <tt>Receive</tt> enqueues a request to receive new
data from the Connection. Once data has been received, or an error is encountered,
an event will be delivered to complete any pending <tt>Receive</tt> requests (see <xref target="receive-events"/>).
If Messages arrive at the Transport Services system before <tt>Receive</tt> requests are issued,
ensuing <tt>Receive</tt> requests will first operate on these Messages before awaiting any further Messages.</t>
        <section anchor="receiving-action">
          <name>Enqueuing Receives</name>
          <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
specified.</t>
          <artwork><![CDATA[
Connection.Receive(minIncompleteLength?, maxLength?)
]]></artwork>
          <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
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 delivered (see <xref target="receive-partial"/> delivered. See Sections&nbsp;<xref target="receive-partial" format="counter"/>
and <xref target="framing"/> target="framing" format="counter"/> for more information on how this is accomplished). accomplished.
If this value is set to some smaller value, the associated receive event will be triggered
only when
	  only:</t>
	  <ol>
	    <li>when at least that many bytes are available, or the available,</li>
	    <li>the Message is complete with fewer
	  bytes, or the or</li><li>the system needs to free up memory. Applications SHOULD memory.</li></ol>
	  <t>Applications <bcp14>SHOULD</bcp14> always
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 Messages
or memory issues.</t>
          <t>The maxLength argument indicates the maximum size of a Message in bytes
that the application is currently prepared to receive. The default
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
the Connection's Protocol Stack, it will be delivered via <tt>ReceivedPartial</tt>
events (<xref target="receive-partial"/>).</t>
          <t>Note that maxLength does not guarantee that the application will receive that many
bytes if they are available; the Transport Services API could return <tt>ReceivedPartial</tt> events with less
data than maxLength according to implementation constraints. Note also that maxLength
and minIncompleteLength are intended only to manage buffering, buffering and are not interpreted
as a receiver preference for Message reordering.</t>
        </section>
        <section anchor="receive-events">
          <name>Receive Events</name>

          <t>Each call to <tt>Receive</tt> will be paired with a single <tt>Receive</tt> event. This allows an application
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 events at the same time
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 refrain from calling <tt>Receive</tt>
or could delay calling it. This would lead to a build-up buildup of unread data, which, in turn, could result in
	  backpressure to the sender via a transport protocol's flow control.</t>

<!--[rfced] This sentence does not seem to parse.  Please rephrase.

Original:
   The Transport Services API should allow the application to correlate
   which call to Receive resulted in a particular Receive event.

-->

          <t>The Transport Services API should allow the application to correlate which call to <tt>Receive</tt> resulted
in a particular <tt>Receive</tt> event. The manner in which this correlation is indicated
is implementation-specific.</t> implementation specific.</t>
          <section anchor="receive-complete">
            <name>Received</name>
            <artwork><![CDATA[
Connection -> Received<messageData, messageContext>
]]></artwork>
            <t>A <tt>Received</tt> event indicates the delivery of a complete Message.
It contains two objects, objects: the received bytes as <tt>messageData</tt>, <tt>messageData</tt> and the metadata 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.
The <tt>messageContext</tt> value is provided to enable retrieving metadata about the Message and referring to the Message. The MessageContext object is described in <xref target="msg-ctx"/>.</t>
            <t>See <xref target="framing"/> for handling regarding how to handle Message framing in situations where the Protocol
Stack only provides a byte-stream transport.</t>
          </section>
          <section anchor="receive-partial">
            <name>ReceivedPartial</name>
            <artwork><![CDATA[
Connection -> ReceivedPartial<messageData, messageContext,
                              endOfMessage>
]]></artwork>
            <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 more
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
passing the same MessageContext, MessageContext until the endOfMessage flag is delivered or a
 <tt>ReceiveError</tt> occurs. All partial blocks of a single Message are delivered in
order without gaps. This event does not support delivering non-contiguous partial
Messages. If, for For example, if Message A is divided into three pieces (A1, A2, A3) and A3),
Message B is divided into three pieces (B1, B2, B3), and preserveOrder is not Required,
the <tt>ReceivedPartial</tt> could deliver them in a sequence like this: A1, B1, B2, A2, A3, B3, B3.
This is because the MessageContext allows the application to identify the pieces as belonging
	    to Message A and B, respectively. However, a sequence like: like A1, A3 will never occur.</t>

            <t>If the minIncompleteLength in the Receive request was set to be infinite (indicating
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>
            <ul spacing="normal">
              <li>
                <t>the underlying Protocol Stack supports message boundary preservation, preservation and
the size of the Message is larger than the buffers available for a single
Message;</t>
              </li>
              <li>
                <t>the underlying Protocol Stack does not support message boundary
preservation,
preservation and the Message Framer (see <xref target="framing"/>) cannot determine
the end of the Message using the buffer space it has available; or</t>
              </li>
              <li>
                <t>the underlying Protocol Stack does not support message boundary
preservation,
preservation and no Message Framer was supplied by the application</t> application.</t>
              </li>
            </ul>
            <t>Note that that, in the absence of message boundary preservation or
a Message Framer, all bytes received on the Connection will be represented as one
large Message of indeterminate length.</t>
            <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
the Message in two separate <tt>ReceivedPartial</tt> events.</t>
            <artwork><![CDATA[
Connection.Receive(1, 1000)

// Receive the first 1000 bytes, bytes; message is incomplete
Connection -> ReceivedPartial<messageData(1000 bytes),
                              messageContext, false>

Connection.Receive(1, 1000)

// Receive the last 500 bytes, bytes; message is now complete
Connection -> ReceivedPartial<messageData(500 bytes),
                              messageContext, true>
]]></artwork>
          </section>
          <section anchor="receive-error">
            <name>ReceiveError</name>
            <artwork><![CDATA[
Connection -> ReceiveError<messageContext, reason?>
]]></artwork>
            <t>A <tt>ReceiveError</tt> occurs when data when:</t>
            <ul spacing="normal">
             <li>data is received by the underlying Protocol Stack
that cannot be fully retrieved or parsed, and when it and</li>
             <li>it is useful for the application
to be notified of such errors. For errors.</li>
	    </ul>
            <t>For example, a <tt>ReceiveError</tt> can
indicate that a Message (identified via the <tt>messageContext</tt> value)
that was being partially received previously, but had not
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
previously received Message parts from memory. As another example,
if an incoming Message does not fulfill the <tt>recvChecksumLen</tt> property
(see <xref target="conn-recv-checksum"/>),
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>
            <t>In contrast, internal protocol reception errors (e.g., loss causing retransmissions
in TCP) are not signalled signaled by this event. Conditions that irrevocably lead to
the termination of the Connection are signaled using <tt>ConnectionError</tt>
(see <xref target="termination"/>).</t>
          </section>
        </section>
        <section anchor="recv-meta">
          <name>Receive Message Properties</name>
          <t>Each Message Context could contain metadata from protocols in the Protocol Stack;
which metadata is available is Protocol Stack dependent. These are exposed through additional read-only Message Properties that can be queried from the MessageContext object (see <xref target="msg-ctx"/>) passed by the receive event.
The following metadata values in the following subsections are supported:</t> supported.</t>
          <section anchor="receive-ecn">
            <name>UDP(-Lite)-specific Property:
            <name>Property Specific to UDP and UDP-Lite: ECN</name>
            <t>When available, Message metadata carries the value of the Explicit Congestion
Notification (ECN) field. This information can be used for logging and debugging,
and for debugging as well as building applications that need access to information about
the transport internals for their own operation. This property is specific to UDP
and UDP-Lite UDP-Lite, because these protocols do not implement congestion control,
and hence control; hence, they expose this functionality to the application (see <xref target="RFC8293"/>,
following the guidance in <xref target="RFC8085"/>)</t> target="RFC8085"/>).</t>
          </section>
          <section anchor="receive-early">
            <name>Early Data</name>
            <t>In some cases cases, it can be valuable to know whether data was read as part of early
data transfer (before Connection establishment has finished). This is useful if
applications need to treat early data separately,
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 replayed
maliciously (see <xref target="RFC8446"/>). Thus, receivers might wish to perform additional
checks for early data to ensure that it is safely replayable. If TLS 1.3 is available
and the recipient Message was sent as part of early data, the corresponding metadata carries
a flag indicating as such. If early data is enabled, applications should check this metadata
field for Messages received during Connection establishment and respond accordingly.</t>
          </section>
          <section anchor="receiving-final-messages">
            <name>Receiving Final Messages</name>
            <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 application can assume that there will be no more Messages received on the
Connection once the Message has been completely delivered. This corresponds
to the <tt>final</tt> property that can be marked on a sent Message, Message; see <xref target="msg-final"/>.</t>
            <t>Some transport protocols and peers do not support signaling of the <tt>final</tt> property.
Applications therefore  SHOULD NOT  Therefore,
applications <bcp14>SHOULD NOT</bcp14> rely on receiving a Message marked Final to know
that the sending endpoint is done sending on a Connection.</t>
            <t>Any calls to <tt>Receive</tt> once the Final Message has been delivered will result in errors.</t>
          </section>
        </section>
      </section>
    </section>
    <section anchor="termination">
      <name>Connection Termination</name>
      <t>A Connection can be terminated i) by terminated:</t>
      <ol>
	<li>by the Local Endpoint (i.e., the application calls the <tt>Close</tt>, <tt>CloseGroup</tt>, <tt>Abort</tt> <tt>Abort</tt>, or <tt>AbortGroup</tt> action), ii) by action),</li>
	<li>by the Remote Endpoint (i.e., the remote application calls the <tt>Close</tt>, <tt>CloseGroup</tt>, <tt>Abort</tt> <tt>Abort</tt>, or <tt>AbortGroup</tt> action), or iii) because or</li>
	<li>because of an error (e.g., a timeout). A timeout).</li>
      </ol>
      <t>A local call of the <tt>Close</tt> action will
cause the Connection to either send either a <tt>Closed</tt> event or a <tt>ConnectionError</tt> event, and event; a local call of
the <tt>CloseGroup</tt> action will cause all of the Connections in the group to either send either a <tt>Closed</tt> event
or a <tt>ConnectionError</tt> event. A local call of the <tt>Abort</tt> action will cause the Connection to send
a <tt>ConnectionError</tt> event, indicating local <tt>Abort</tt> as a reason, and 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>
as a reason.</t>
      <t>Remote action calls map to events similar to local calls (e.g., a remote <tt>Close</tt> causes the
Connection to either send either a <tt>Closed</tt> event or a <tt>ConnectionError</tt> event), but, different from but in contrast to local action calls,
it is not guaranteed that such events will indeed be invoked. When an application needs to free resources
associated with a Connection, it ought not to therefore rely on the invocation of such events due to
termination calls from the Remote Endpoint, but instead Endpoint; instead, it should use the local termination actions.</t>
      <t><tt>Close</tt> terminates a Connection after satisfying all the requirements that were
specified regarding the delivery of Messages that the application has already
given to the Transport Services system. Upon successfully satisfying all these
requirements, the Connection will send the <tt>Closed</tt> event. For example, if reliable delivery was requested
for a Message handed over before calling <tt>Close</tt>, the <tt>Closed</tt> event will signify
that this Message has indeed been delivered. This action does not affect any other Connection
in the same Connection Group.</t>
      <t>An application MUST NOT <bcp14>MUST NOT</bcp14> assume that it can receive any further data on a Connection
for which it has called <tt>Close</tt>, even if such data is already in flight.</t>
      <artwork><![CDATA[
Connection.Close()
]]></artwork>
      <t>The <tt>Closed</tt> event informs the application that a <tt>Close</tt> action has successfully
completed,
completed or that the Remote Endpoint has closed the Connection.
There is no guarantee that a remote <tt>Close</tt> will be signaled.</t>
      <artwork><![CDATA[
Connection -> Closed<>
]]></artwork>
      <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.
When the <tt>Abort</tt> action has finished, the Connection will send a <tt>ConnectionError</tt> event,
indicating local <tt>Abort</tt> as a reason.</t>
      <artwork><![CDATA[
Connection.Abort()
]]></artwork>
      <t><tt>CloseGroup</tt> gracefully terminates a Connection and any other Connections in the
same Connection Group. For example, all of the Connections in a
group might be streams of a single session for a multistreaming protocol; closing the entire
group will close the underlying session. See also <xref target="groups"/>. All Connections in the group
will send a <tt>Closed</tt> event when the <tt>CloseGroup</tt> action was successful.
As with <tt>Close</tt>, any Messages
remaining to be processed on a Connection will be handled prior to closing.</t>
      <artwork><![CDATA[
Connection.CloseGroup()
]]></artwork>
      <t><tt>AbortGroup</tt> terminates a Connection and any other Connections that are
in the same Connection Group without delivering any remaining Messages.
When the <tt>AbortGroup</tt> action has finished, all Connections in the group will
send a <tt>ConnectionError</tt> event, indicating local <tt>Abort</tt> as a reason.</t>
      <artwork><![CDATA[
Connection.AbortGroup()
]]></artwork>
      <t>A <tt>ConnectionError</tt> informs the application that: 1) data that:</t>
      <ol><li>data could not be delivered to the
peer after a timeout,
or 2) the timeout
      or</li><li>the Connection has been aborted (e.g., because the peer has called <tt>Abort</tt>).
There <tt>Abort</tt>).</li></ol>
      <t>There is no guarantee that an <tt>Abort</tt> from the peer will be signaled.</t>
      <artwork><![CDATA[
Connection -> ConnectionError<reason?>
]]></artwork>
    </section>
    <section anchor="state-ordering">
      <name>Connection State and Ordering of Operations and Events</name>
      <t>This Transport Services API is designed to be independent of an implementation's
concurrency model.  The exact details of regarding how exactly actions are handled, and how
events are dispatched, are implementation dependent.</t>
      <t>Some transitions of Connection states are associated with events:</t>
      <ul spacing="normal">
        <li>
          <t><tt>Ready&lt;&gt;</tt> occurs when a Connection created with <tt>Initiate</tt> or
<tt>InitiateWithSend</tt> transitions to Established state.</t>
        </li>
        <li>
          <t><tt>ConnectionReceived&lt;&gt;</tt> occurs when a Connection created with <tt>Listen</tt>
transitions to Established state.</t>
        </li>
        <li>
          <t><tt>RendezvousDone&lt;&gt;</tt> occurs when a Connection created with <tt>Rendezvous</tt>
transitions to Established state.</t>
        </li>
        <li>
          <t><tt>Closed&lt;&gt;</tt> occurs when a Connection transitions to Closed state without error.</t>
        </li>
        <li>
          <t><tt>EstablishmentError&lt;&gt;</tt> occurs when a Connection created with <tt>Initiate</tt> transitions
from Establishing state to Closed state due to an error.</t>
        </li>
        <li>
          <t><tt>ConnectionError&lt;&gt;</tt> occurs when a Connection transitions to Closed state due to
an error in all other circumstances.</t>
        </li>
      </ul>
      <t>The following diagram shows the possible states of a Connection and the
events that occur upon a transition from one state to another.</t>
      <figure anchor="fig-connstates">
        <name>Connection State Diagram</name>
        <artwork><![CDATA[
              (*)                               (**)
Establishing -----> Established -----> Closing ------> Closed
     |                                                   ^
     |                                                   |
     +---------------------------------------------------+
                  EstablishmentError<>

(*) Ready<>, ConnectionReceived<>, RendezvousDone<>
(**) Closed<>, ConnectionError<>
]]></artwork>
      </figure>
      <t>The Transport Services API  provides the following guarantees about the ordering of
 operations:</t>
      <ul spacing="normal">
        <li>
          <t><tt>Sent&lt;&gt;</tt> events will occur on a Connection in the order in which the Messages
were sent (i.e., delivered to the kernel or to the network interface,
depending on the implementation).</t>
        </li>
        <li>
          <t><tt>Received&lt;&gt;</tt> will never occur on a Connection before it is Established; i.e. Established, i.e.,
before a <tt>Ready&lt;&gt;</tt> event on that Connection, Connection or a <tt>ConnectionReceived&lt;&gt;</tt> or
<tt>RendezvousDone&lt;&gt;</tt> containing that Connection.</t>
        </li>
        <li>
          <t>No events will occur on a Connection after it is closed; closed, i.e., after a
<tt>Closed&lt;&gt;</tt> event, an <tt>EstablishmentError&lt;&gt;</tt> or <tt>ConnectionError&lt;&gt;</tt> will not occur on that Connection. To
ensure this ordering, <tt>Closed&lt;&gt;</tt> will not occur on a Connection while other
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>
        </li>
      </ul>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>

<t>This document has no actions for IANA.
Later versions of this document IANA actions.</t>

      <t>Future works might create IANA registries for generic transport property names and transport property namespaces (see <xref target="property-names"/>).</t>
    </section>
    <section anchor="privacy-security">
      <name>Privacy and Security Considerations</name>
      <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
in <xref target="security-parameters"/>. It does not recommend use (or disuse) of specific
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 specifications.</t>
      <t><xref target="I-D.ietf-taps-arch"/> target="RFC9621"/> provides general security considerations and requirements for any system that implements the Transport Services architecture. These include recommendations of relevance to the API, e.g. e.g., regarding the use of keying material.</t>
      <t>The described API is used to exchange information between an application and the Transport Services system. While
it is not necessarily expected that both systems are implemented by the same authority, it is expected
that the Transport Services Implementation is either provided as a library either that is selected by the application
from a trusted party, party or that it is part of the operating system that the application also relies on for
other tasks.</t>
      <t>In either case, the Transport Services API is an internal interface that is used to exchange information locally between two systems.
However, as the Transport Services system is responsible for network communication, it is in the position to
potentially share any information provided by the application with the network or another communication peer.
Most of the information provided over the Transport Services API are is useful to configure and select protocols and paths
and are is not necessarily privacy-sensitive. privacy sensitive. Still, some information could be privacy sensitive because
it might reveal usage characteristics and habits of the user of an application.</t>
      <t>Of course course, any communication over a network reveals usage characteristics, because all
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
clear text, and which other entities can access it. How Transport Services systems ought to choose protocols -- depending on the security properties required -- is out of scope of for this specification, as it is limited to transport protocols. The choice of a security protocol can be informed by the survey provided in <xref target="RFC8922"/>.</t>
      <t>In most cases, information provided for protocol and path selection
does not directly translate to information that can be observed by network devices on the path.
However, there might be specific configuration
information that is intended for path exposure, e.g., a DiffServ Diffserv codepoint setting, setting that is either provided
directly by the application or indirectly configured for a traffic profile.</t>
      <t>Applications should be aware that a single communication attempt can lead to more than one connection establishment procedure.
This is the case, for  For example, when
      this is the case when:</t>
      <ul>
	<li>the Transport Services system also executes name resolution, when support resolution,</li>
	<li>support mechanisms such as
TURN or ICE are used to establish connectivity, connectivity if protocols or paths are raced, raced or if a path fails and
	fallback or re-establishment is supported in the Transport Services system. Applications system.</li>
      </ul>
      <t>Applications should take special
care when using 0-RTT session resumption (see <xref target="prop-0rtt"/>), as early data sent across multiple paths during
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
complete or well-formed. Specifically, Messages that are received partially (see <xref target="receive-partial"/> could )could be a source
of truncation attacks if applications do not distinguish between partial Messages and complete Messages.</t>
      <t>The Transport Services API explicitly does not require the application to resolve names, though there is
a tradeoff trade-off between early and late binding of addresses to names. Early binding
allows the Transport Services Implementation to reduce Connection setup latency, latency. This is at the cost
of potentially limited scope for alternate path discovery during Connection
establishment,
establishment as well as potential additional information leakage about
application interest when used with a resolution method (such as DNS without
TLS) which that does not protect query confidentiality.
      Names used with the Transport Services API SHOULD <bcp14>SHOULD</bcp14> be fully-qualified domain names (FQDNs); FQDNs; not providing an FQDN will result in the Transport Services Implementation needing to to use DNS search domains for name resolution, which might lead to inconsistent or unpredictable behavior.</t>

<!--[rfced] In the following text:

Original:
The Transport Services API is designed such that protocol and path
selection can be limited to a small and controlled set if the
application requires this or to implement a security policy. can be
limited to a small and controlled set if required by the application
to perform a function or to provide security.

a) we assume the period after "policy" is in error.  We have deleted.
Please let us know any objections.

b) What is the subject of "implement"?

Perhaps:
The Transport Services API is designed such that, if required by the application:

*protocol and path selection can be limited to a small and controlled
set, or

*the implementation of a security policy can be limited to a small and
controlled set to perform a function or to provide security.

-->

      <t>These communication activities are not different from what is used today. at the time of writing. However,
the goal of a Transport Services system is to support
such mechanisms as a generic service within the transport layer. This enables applications to more dynamically
benefit from innovations and new protocols in the transport, although it reduces transparency of the
underlying communication actions to the application itself. The Transport Services API is designed such that protocol and path selection
can be limited to a small and controlled set set, if the application requires this this, or to implement a security policy. policy
can be limited to a small and controlled set if required by the application to perform a function or to provide security.
Further,
introspection on the properties of Connection objects allows an application to determine which protocol(s) and path(s) are in use.
A Transport Services system SHOULD <bcp14>SHOULD</bcp14> provide a facility logging the 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 research and
innovation programme under grant agreements No. 644334 (NEAT) and No. 688421 (MAMI).</t>
      <t>This work has been supported by Leibniz Prize project funds of DFG - German
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 Sciences
Research Council under grant EP/R04144X/1.</t>
      <t>This work has been supported by the Research Council of Norway under its "Toppforsk"
programme through the "OCARINA" project.</t>
      <t>Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric Kinnear 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>

  </middle>
  <back>
    <displayreference target="RFC7301" to="ALPN"/>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>

<!-- draft-ietf-taps-arch (RFC 9621) -->
	<reference anchor="I-D.ietf-taps-arch"> anchor="RFC9621" target="https://www.rfc-editor.org/info/RFC9621">
	  <front>
	    <title>Architecture and Requirements for Transport Services</title>
	    <author initials="T." surname="Pauly" fullname="Tommy Pauly" initials="T." surname="Pauly"> role="editor">
	      <organization>Apple Inc.</organization>
	    </author>
	    <author initials="B." surname="Trammell" fullname="Brian Trammell" initials="B." surname="Trammell"> role="editor">
	      <organization>Google Switzerland GmbH</organization>
	    </author>
	    <author fullname="Anna Brunstrom" initials="A." surname="Brunstrom"> surname="Brunstrom" fullname="Anna Brunstrom">
	      <organization>Karlstad University</organization>
	    </author>
	    <author fullname="Gorry Fairhurst" initials="G." surname="Fairhurst"> surname="Fairhurst" fullname="Gorry Fairhurst">
	      <organization>University of Aberdeen</organization>
	    </author>
	    <author initials="C. S." surname="Perkins" fullname="Colin Perkins" initials="C." surname="Perkins"> S. Perkins">
	      <organization>University of Glasgow</organization>
	    </author>
	    <date day="9" month="November" year="2023"/>
            <abstract>
              <t>   This document describes an architecture for exposing transport
   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>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-taps-arch-19"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract> year="2024"/>
	  </front>
	  <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/> value="9621"/>
	  <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="ALPN">
          <front>
            <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation 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) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7301"/>
          <seriesInfo name="DOI" value="10.17487/RFC7301"/> value="10.17487/RFC9621"/>
	</reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/>

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>

<!-- draft-ietf-taps-impl ( RFC 9623) -->
        <reference anchor="I-D.ietf-taps-impl"> anchor="RFC9623" target="https://www.rfc-editor.org/info/rfc9623">
	  <front>
	    <title>Implementing Interfaces to Transport Services</title>
	    <author initials="A." surname="Brunstrom" fullname="Anna Brunstrom" initials="A." surname="Brunstrom"> role="editor">
	      <organization>Karlstad University</organization>
	    </author>
	    <author initials="T." surname="Pauly" fullname="Tommy Pauly" initials="T." surname="Pauly"> role="editor">
	      <organization>Apple Inc.</organization>
	    </author>
	    <author fullname="Reese Enghardt" initials="R." surname="Enghardt"> surname="Enghardt" fullname="Reese Enghardt">
	      <organization>Netflix</organization>
	    </author>
	    <author fullname="Philipp S. Tiesel" initials="P. S." surname="Tiesel"> surname="Tiesel" fullname="Philipp S. Tiesel">
	      <organization>SAP SE</organization>
	    </author>
	    <author fullname="Michael Welzl" initials="M." surname="Welzl"> surname="Welzl" fullname="Michael Welzl">
	      <organization>University of Oslo</organization>
	    </author>
	    <date day="14" month="December" year="2023"/>
            <abstract>
              <t>   The Transport Services system enables applications to use transport
   protocols flexibly for network communication and defines a protocol-
   independent Transport Services Application Programming Interface
   (API) that is based on an asynchronous, event-driven interaction
   pattern.  This document serves as a guide to implementing such a
   system.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-taps-impl-18"/>
        </reference>
        <reference anchor="RFC7556">
          <front>
            <title>Multiple Provisioning Domain Architecture</title>
            <author fullname="D. Anipko" initials="D." role="editor" surname="Anipko"/>
            <date month="June" year="2015"/>
            <abstract>
              <t>This document is a product of the work of the Multiple Interfaces Architecture Design team. It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously. The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information. PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources. PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.</t>
            </abstract> month="November" year="2024"/>
	  </front>
	  <seriesInfo name="RFC" value="7556"/> value="9623"/>
	  <seriesInfo name="DOI" value="10.17487/RFC7556"/> value="10.17487/RFC9623"/>
	</reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7556.xml"/>

        <reference anchor="TCP-COUPLING"> anchor="TCP-COUPLING" target="https://ieeexplore.ieee.org/document/8406887">
          <front>
            <title>ctrlTCP: Reducing Latency latency through Coupled, Heterogeneous Multi-Flow coupled, heterogeneous multi-flow TCP Congestion Control</title> congestion control</title>
            <author initials="S." surname="Islam" fullname="Safiqul Islam">
              <organization/>
            </author>
            <author initials="M." surname="Welzl" fullname="Michael Welzl">
              <organization/>
            </author>
            <author initials="K." surname="Hiorth" fullname="Kristian Hiorth">
              <organization/>
            </author>
            <author initials="D." surname="Hayes" fullname="David Hayes">
              <organization/>
            </author>
            <author initials="G." surname="Armitage" fullname="Grenville Armitage">
              <organization/>
            </author>
            <author initials="S." surname="Gjessing" fullname="Stein Gjessing">
              <organization/>
            </author>
            <date year="2018"/>
          </front>
          <seriesInfo name="IEEE
          <refcontent>IEEE INFOCOM Global Internet Symposium (GI) workshop (GI 2018)" value=""/>
        </reference>
        <reference anchor="RFC8095">
          <front>
            <title>Services Provided by IETF Transport Protocols and Congestion Control Mechanisms</title>
            <author fullname="G. Fairhurst" initials="G." role="editor" surname="Fairhurst"/>
            <author fullname="B. Trammell" initials="B." role="editor" surname="Trammell"/>
            <author fullname="M. Kuehlewind" initials="M." role="editor" surname="Kuehlewind"/>
            <date month="March" year="2017"/>
            <abstract>
              <t>This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Real-Time Transport Protocol (RTP), File Delivery over Unidirectional Transport / Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, NACK- Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport. This survey provides background for the definition of transport services within the TAPS working group.</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 offered by end systems and gives guidance on choosing among the available mechanisms 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 Transport 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 network security protocols, with a focus 2018 - IEEE Conference on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog Transport Services by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope 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"/> Computer Communications Workshops (INFOCOM WKSHPS)</refcontent>
          <seriesInfo name="DOI" value="10.17487/RFC8922"/> value="10.1109/INFCOMW.2018.8406887"/>
        </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 IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t>
              <t>This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [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 control. This document specifies an Internet Best Current Practices for the Internet 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 transport Circuit Breaker". It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion- controlled traffic and explains where CBs are, and are not, needed. It also defines requirements for building 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 network configuration information. PvDs allows hosts to manage connections to multiple networks and interfaces simultaneously, such as when a home router provides connectivity through both a broadband and cellular network provider.</t>
              <t>This document defines a mechanism for explicitly identifying PvDs through a Router Advertisement (RA) option.

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8095.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8923.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8922.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.791.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2914.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8084.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8801.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8981.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8489.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8656.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7478.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8699.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8838.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8260.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7657.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8622.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2597.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3246.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5865.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4594.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8899.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5482.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9329.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9218.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8293.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8546.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8303.xml"/>

      </references>
    </references>

    <section anchor="implmapping">
      <name>Implementation Mapping</name>

<!--[rfced] This RA option announces a PvD identifier, which hosts can compare to differentiate between PvDs. The option can directly carry some information about a PvD and can optionally point to PvD Additional 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 Autoconfiguration sentence packs 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 randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions 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-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.</t>
              <t>Because congestion control is critical to the stable operation lot of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish 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 protocols (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 multicast 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 Certificate 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 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [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 Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).</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-Huguenin"/>
            <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 serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to info.  Perhaps breaking it by a NAT. It can also be used to check connectivity between two endpoints and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs
     up and does not require any special behavior from them.</t>
              <t>STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context bit 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="Reddy"/>
            <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 reorder would be impossible for that host to communicate directly with other hosts (peers) in certain situations. In these situations, it is necessary best for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called "Traversal Using Relays around NAT" (TURN), that allows the host to control the operation ease of the relay and to exchange packets with its peers using 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
     reader?

Original:
Actions could be used implemented as part of the Interactive 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 application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one functions or more participants. These sessions include Internet telephone method 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 cases. Requirements on the browser functionality are derived from the use cases.</t>
              <t>This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WG's efforts so far. It is being published to record the early conclusions of the WG. It will not be used as a set of rigid guidelines that specifications
instance, and implementations will events could 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 Protocol (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 congestion 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 Interactive 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 Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to begin connectivity checks while they are still gathering candidates, by incrementally exchanging candidates over time instead of all at once. This method can considerably 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 Stream 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-oriented transport protocol supporting arbitrarily large user messages. This document 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 blocking 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 choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined in this document. A stream scheduler can choose to either implement, implemented via event queues, handler
functions 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 Communication</title>
            <author fullname="D. Black" initials="D." role="editor" surname="Black"/>
            <author fullname="P. Jones" initials="P." surname="Jones"/>
            <date month="November" year="2015"/>
            <abstract>
              <t>This memo describes the interaction between Differentiated Services (Diffserv) network quality-of-service (QoS) functionality and real- time network communication, including communication based on the Real-time Transport Protocol (RTP). Diffserv is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different Diffserv Codepoints (DSCPs). WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple. The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple have transport protocol interactions, particularly with congestion control functionality (e.g., reordering). In addition, DSCP markings may be changed classes, communicating sequential processes, or removed between the traffic source and destination. This memo covers the implications of these Diffserv aspects for real-time 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 differentiated 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 Services</title>
            <author fullname="R. Bless" initials="R." surname="Bless"/>
            <date month="June" year="2019"/>
            <abstract>
              <t>This document specifies properties and characteristics of a Lower- 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 traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can other
asynchronous calling conventions.

Perhaps:
For instance, actions could be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such implemented as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LE PHB.</t>
              <t>This specification obsoletes RFC 3662 and updates the DSCP recommended 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 Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain 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-Admitted 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-time traffic. This traffic class conforms to the Expedited Forwarding Per-Hop Behavior. This traffic is also admitted by the network using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission. This differs from a real-time traffic class that conforms to the Expedited Forwarding Per-Hop Behavior but is not subject to capacity admission functions 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 Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply 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 Transports</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 Discovery (DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It allows a PL,
calls.  Event queues, handler functions or a datagram application that uses a PL, to discover whether a network path can support the current size of 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 whether the maximum packet size can be increased. This provides functionality for datagram transports that is equivalent to the PLPMTUD specification for TCP, specified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines to refer to this method for use with UDP datagrams and updates SCTP.</t>
              <t>The document provides implementation notes for incorporating Datagram PMTUD into IETF datagram transports classes, communicating
sequential processes, or applications that use datagram transports.</t>
              <t>This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, 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 remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts 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 explicitly 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 Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association (SA) establishment and Encapsulating Security Payload (ESP) packets over a TCP 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. This document clarifies the specification for TCP encapsulation by including additional clarifications obtained during implementation and deployment of this method. 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 defines 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 reprioritizing 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 Layer 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 traffic in a network that uses Network Virtualization over Layer 3 (NVO3). Both infrastructure multicast and application-specific multicast are discussed. It describes 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</title>
            <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 Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</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 information available to an on-path non-participant in a networking protocol. This abstraction is intended to shed light on the implications that increased encryption 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 Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Lightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The description results in a set of transport abstractions that can be exported in a transport services (TAPS) API.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8303"/>
          <seriesInfo name="DOI" value="10.17487/RFC8303"/>
        </reference>
      </references>
    </references>
    <?line 3730?>

<section anchor="implmapping">
      <name>Implementation Mapping</name> asynchronous calling conventions could
implement events.

-->

      <t>The way the concepts from this abstract API map into to concrete APIs in a
given language on a given platform largely depends on the features and norms of
the language and the platform. Actions  For instance, actions could be implemented as functions or
method calls, for instance, calls and events could be implemented via event queues,
handler functions or classes, communicating sequential processes, or other
asynchronous calling conventions.</t>
      <section anchor="types">
        <name>Types</name>
        <t>The basic types mentioned in <xref target="notation"/> typically have natural
correspondences in practical programming languages, perhaps constrained by
implementation-specific limitations. For example:</t>
        <ul spacing="normal">
          <li>
            <t>An
            <t>Typically, an Integer can typically be represented in C by an <tt>int</tt> or <tt>long</tt>, <tt>long</tt>; this is subject
to the underlying platform's ranges for each.</t>
          </li>
          <li>
            <t>In C, a Tuple may be represented as a <tt>struct</tt> with one member for each of
the value types in the ordered grouping. In However, in Python, by contrast, a Tuple may
be represented as a <tt>tuple</tt>, which is a sequence of dynamically-typed dynamically typed
elements.</t>
          </li>
          <li>
            <t>A Set may be represented as a <tt>std::set</tt> in C++ or as a <tt>set</tt> in
Python. In C, it may be represented as an array or as a higher-level data
structure with appropriate accessors defined.</t>
          </li>
        </ul>

<!--[rfced] In this text, may we update as follows to avoid
    "similarly...in different"?

Original:

   The objects described in Section 1.1 can similarly be represented in
   different ways...

Current:
   The objects described in Section 1.1 can also be represented in
   different ways...
-->

        <t>The objects described in <xref target="notation"/> can similarly also be represented in
different ways ways, depending on which programming language is used. Objects
like Preconnections, Connections, and Listeners can be long-lived, long-lived and
benefit from using object-oriented constructs. Note that that, in C, these
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
Preconnection can be used to initiate multiple Connections, it is the
responsibility of the application to clean up the Preconnection memory
if necessary.</t>
      </section>
      <section anchor="events-and-errors">
        <name>Events and Errors</name>

<!--[rfced] Please review our updates to this run-on sentence and
     confirm we have not shifted the meaning (or please suggest
     another rephrase if we have).

Original:
However, implementations of this API may report errors synchronously,
according to the error handling idioms of the implementation platform,
where they can be immediately detected, such as by generating an
exception when attempting to initiate a Connection with inconsistent
Transport Properties.

Current:
However, implementations of this API may report errors synchronously.
This is done according to the error-handling idioms of the
implementation platform, where they can be immediately detected. An
example of this being generating an exception when attempting to
initiate a Connection with inconsistent Transport Properties.

-->

        <t>This specification treats events and errors similarly. Errors, just as any
other events, may occur asynchronously in network applications. However,
implementations of this API may report errors synchronously, synchronously.
This is done according to the error handling error-handling idioms of the implementation
platform, where they can be immediately detected, such as by detected. An example of this being generating an
exception when attempting to initiate a Connection with inconsistent
Transport Properties. An error can provide an optional reason to the
application with further details about why the error occurred.</t>
      </section>
      <section anchor="time-duration">
        <name>Time Duration</name>
        <t>Time duration types are implementation-specific. implementation specific.
For instance, it could be a number of seconds, a number of milliseconds, or a <tt>struct timeval</tt> in C or C;  in C++, it could be a user-defined <tt>Duration</tt> class in C++.</t> class.</t>
      </section>
    </section>
    <section anchor="convenience-functions">
      <name>Convenience Functions</name>
      <section anchor="preference-conv">
        <name>Adding Preference Properties</name>
        <t>TransportProperties will frequently need to set
Selection Properties of type <tt>Preference</tt>, <tt>Preference</tt>; therefore, implementations can provide special actions
for adding each preference level, i.e., <tt>TransportProperties.Set(some_property, avoid)</tt>
is equivalent to <tt>TransportProperties.Avoid(some_property)</tt>:

<!-- [rfced] Appendix B.1:  We found a spacing issue and an
extraneous "`" character in this sentence.  We corrected these items,
but we would also like to confirm that the ", avoid)" portion is
correct.  We ask because we do not see "avoid)" used anywhere else
in this document.  Please also note that we made adjustments to the
<tt> settings.

Please review, and let us know if further updates are needed.

Original:
 TransportProperties will frequently need to set Selection Properties
 of type Preference, therefore implementations can provide special
 actions for adding each preference level i.e, <tt>TransportProperties.Set(some_property,
 TransportProperties.Set(some_property, avoid) is equivalent
 toTransportProperties.Avoid(some_property)`:

Currently:
 TransportProperties will frequently need to set Selection Properties
 of type Preference; therefore, implementations can provide special
 actions for adding each preference level, i.e.,
 TransportProperties.Set(some_property, avoid) is equivalent to </tt>TransportProperties.Avoid(some_property)`:</t>
 TransportProperties.Avoid(some_property): -->

</t>
        <artwork><![CDATA[
TransportProperties.Require(property)
TransportProperties.Prefer(property)
TransportProperties.NoPreference(property)
TransportProperties.Avoid(property)
TransportProperties.Prohibit(property)
]]></artwork>
      </section>
      <section anchor="property-profiles">
        <name>Transport Property Profiles</name>
        <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"/>)
that are preconfigured with frequently used sets of properties; the following subsections list those that are
	in common use in current applications:</t> applications at the time of writing.</t>

<!--[rfced] Please review/confirm the use of "require" instead of
     "required" or "Require" in the Value column of B.2.1, B.2.2, and
     B.2.3.-->

        <section anchor="reliable-inorder-stream">
          <name>reliable-inorder-stream</name>
          <t>This profile provides reliable, in-order transport service with
congestion control.
TCP is an example of a protocol that provides this service.
It should consist of the following properties:</t>
          <table anchor="tabrio">
            <name>reliable-inorder-stream preferences</name> Preferences</name>
            <thead>
              <tr>
                <th align="left">Property</th>
                <th align="left">Value</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">reliability</td>
                <td align="left">require</td>
              </tr>
              <tr>
                <td align="left">preserveOrder</td>
                <td align="left">require</td>
              </tr>
              <tr>
                <td align="left">congestionControl</td>
                <td align="left">require</td>
              </tr>
              <tr>
                <td align="left">preserveMsgBoundaries</td>
                <td align="left">no preference</td>
              </tr>
            </tbody>
          </table>
        </section>
        <section anchor="reliable-message">
          <name>reliable-message</name>
          <t>This profile provides message-preserving, reliable, in-order
transport service with congestion control.
SCTP is an example of a protocol that provides this service.
It should consist of the following properties:</t>
          <table anchor="tabrm">
            <name>reliable-message preferences</name> Preferences</name>
            <thead>
              <tr>
                <th align="left">Property</th>
                <th align="left">Value</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">reliability</td>
                <td align="left">require</td>
              </tr>
              <tr>
                <td align="left">preserveOrder</td>
                <td align="left">require</td>
              </tr>
              <tr>
                <td align="left">congestionControl</td>
                <td align="left">require</td>
              </tr>
              <tr>
                <td align="left">preserveMsgBoundaries</td>
                <td align="left">require</td>
              </tr>
            </tbody>
          </table>
        </section>
        <section anchor="unreliable-datagram">
          <name>unreliable-datagram</name>
          <t>This profile provides a datagram transport service without any
reliability guarantee.
An example of a protocol that provides this service is UDP.
It consists of the following properties:</t>
          <table anchor="tabud">
            <name>unreliable-datagram preferences</name> Preferences</name>
            <thead>
              <tr>
                <th align="left">Property</th>
                <th align="left">Value</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">reliability</td>
                <td align="left">avoid</td>
              </tr>
              <tr>
                <td align="left">preserveOrder</td>
                <td align="left">avoid</td>
              </tr>
              <tr>
                <td align="left">congestionControl</td>
                <td align="left">no preference</td>
              </tr>
              <tr>
                <td align="left">preserveMsgBoundaries</td>
                <td align="left">require</td>
              </tr>
              <tr>
                <td align="left">safelyReplayable</td>
                <td align="left">true</td>
              </tr>
            </tbody>
          </table>
          <t>Applications that choose this Transport Property Profile would
avoid the additional latency that could be introduced
by retransmission or reordering in a transport protocol.</t>
          <t>Applications that choose this Transport Property Profile to reduce latency
should also consider setting an appropriate capacity profile Property,
see Property
(see <xref target="prop-cap-profile"/> target="prop-cap-profile"/>) and might benefit from controlling checksum
coverage, see <xref target="prop-checksum-control-send"/>
coverage (see Sections&nbsp;<xref target="prop-checksum-control-send" format="counter"/> and <xref target="prop-checksum-control-receive"/>.</t> target="prop-checksum-control-receive" format="counter"/>).</t>
        </section>
      </section>
    </section>
    <section anchor="relationship-to-the-minimal-set-of-transport-services-for-end-systems">
      <name>Relationship to the Minimal Set of Transport Services for End Systems</name>
      <t><xref target="RFC8923"/> identifies a minimal set of transport services Transport Services that end systems should offer. These services make all non-security-related transport features of TCP, MPTCP, Multipath TCP (MPTCP), UDP, UDP-Lite, SCTP SCTP, and LEDBAT Low Extra Delay Background Transport (LEDBAT) available that 1) require that:</t>
      <ol>
	<li>require interaction with the application, and 2) do application and</li>
	<li>do not get in the way of a possible implementation over TCP (or, with limitations, UDP). The UDP).</li>
      </ol>
      <t>The following text explains how this minimal set is reflected in the present API. For brevity, it is based on the list in  <xref section="4.1" sectionFormat="of" target="RFC8923"/>, target="RFC8923"/> and updated according to the discussion in <xref section="5" sectionFormat="of" target="RFC8923"/>. The present API covers all elements of this section.
This list is a subset of the transport features in
<xref target="RFC8923" sectionFormat="of" section="A"/>, which refers to the primitives in "pass 2" (see <xref target="RFC8303" section="4" sectionFormat="of"/>) for further details on the implementation with TCP, MPTCP, UDP, UDP-Lite, SCTP, and LEDBAT. This facilitates finding the specifications for implementing
the services listed below with these protocols.

<!-- [rfced] Appendix C:  The first sentence here does not parse;
it appears that one or more words are missing.  In the second
sentence, it is not clear what "This" refers to.
If the suggested text is not correct, please provide clarifying text.

Original:
 This list is a subset of the transport features in
 Appendix A of <xref target="RFC8923"/>, [RFC8923], which refers to the primitives in "pass 2"
 (Section 4) of <xref target="RFC8303"/> [RFC8303] for further details on the implementation
 with TCP, MPTCP, UDP, UDP-Lite, SCTP and LEDBAT.  This facilitates
 finding the specifications for implementing the services listed below
 with these protocols.</t>
      <ul spacing="normal">
        <li>
          <t>Connect: protocols.

Suggested (guessing that "This" refers to Section 4 of [RFC8303]):
 This list is a subset of the transport features in
 Appendix A of [RFC8923], which refers to the primitives in "pass 2".
 See Section 4 of [RFC8303] for 1) further details regarding how to
 implement pass 2 with TCP, MPTCP, UDP, UDP-Lite, SCTP, and LEDBAT
 and 2) how to facilitate finding the specifications for implementing
 the services listed below with these protocols. -->

</t>
      <ul>

          <li>Connect:
<tt>Initiate</tt> action (<xref target="initiate"/>).</t>
        </li>
        <li>
          <t>Listen: target="initiate"/>).</li>

          <li>Listen:
<tt>Listen</tt> action (<xref target="listen"/>).</t>
        </li>
        <li>
          <t>Specify target="listen"/>).</li>

          <li>Specify number of attempts and/or timeout for the first establishment Message:
<tt>timeout</tt> parameter of <tt>Initiate</tt> (<xref target="initiate"/>) or <tt>InitiateWithSend</tt> action (<xref target="initiate-and-send"/>).</t>
        </li>
        <li>
          <t>Disable target="initiate-and-send"/>).</li>

          <li>Disable MPTCP:
<tt>multipath</tt> property (<xref target="multipath-mode"/>).</t>
        </li>
        <li>
          <t>Hand target="multipath-mode"/>).</li>

          <li>Hand over a Message to reliably transfer (possibly multiple times) before connection establishment:
<tt>InitiateWithSend</tt> action (<xref target="initiate-and-send"/>).</t>
        </li>
        <li>
          <t>Change target="initiate-and-send"/>).</li>

          <li>Change timeout for aborting connection (using retransmit limit or time value):
<tt>connTimeout</tt> property, using a time value (<xref target="conn-timeout"/>).</t>
        </li>
        <li>
          <t>Timeout target="conn-timeout"/>).</li>

          <li>Timeout event when data could not be delivered for too long:
<tt>ConnectionError</tt> event (<xref target="termination"/>).</t>
        </li>
        <li>
          <t>Suggest target="termination"/>).</li>

          <li>Suggest timeout to the peer:
See "TCP-specific Properties: User Timeout Option (UTO)" "<xref target="tcp-uto" format="title"/>" (<xref target="tcp-uto"/>).</t>
        </li>
        <li>
          <t>Notification target="tcp-uto" format="default"/>).</li>

          <li>Notification of ICMP error message arrival:
<tt>softErrorNotify</tt> (<xref target="prop-soft-error"/>) and <tt>SoftError</tt> event (<xref target="soft-errors"/>).</t>
        </li>
        <li>
          <t>Choose target="soft-errors"/>).</li>

          <li>Choose a scheduler to operate between streams of an association:
<tt>connScheduler</tt> property (<xref target="conn-scheduler"/>).</t>
        </li>
        <li>
          <t>Configure target="conn-scheduler"/>).</li>

          <li>Configure priority or weight for a scheduler:
<tt>connPriority</tt> property (<xref target="conn-priority"/>).</t>
        </li>
        <li>
          <t>"Specify target="conn-priority"/>).</li>

          <li>"Specify checksum coverage used by the sender" and "Disable checksum when sending":
<tt>msgChecksumLen</tt> property (<xref target="msg-checksum"/>) and <tt>fullChecksumSend</tt> property (<xref target="prop-checksum-control-send"/>).</t>
        </li>
        <li>
          <t>"Specify target="prop-checksum-control-send"/>).</li>

          <li>"Specify minimum checksum coverage required by receiver" and "Disable checksum requirement when receiving":
<tt>recvChecksumLen</tt> property (<xref target="conn-recv-checksum"/>) and <tt>fullChecksumRecv</tt> property (<xref target="prop-checksum-control-receive"/>).</t>
        </li>
        <li>
          <t>"Specify target="prop-checksum-control-receive"/>).</li>

          <li>"Specify DF field":
<tt>noFragmentation</tt> property (<xref target="send-singular"/>).</t>
        </li>
        <li>
          <t>Get max. target="send-singular"/>).</li>

<!-- [rfced] Appendix C:  It appears that some actions in this list
are quoted because more than one action is listed.  However, as
"Specify DF field" is the only single action item in the list that is
quoted (as compared to, for example, the unquoted Disable MPTCP and
Obtain ECN field items), may we remove the quotes here?

Also, could "Request not to bundle messages" be changed to
a request not to bundle messages
(no quotes)?

Original:
  *  "Specify DF field": noFragmentation property (Section 9.1.3.9).
...
 Per-Message control ("Request not to bundle
 messages") is offered via the msgCapacityProfile property
 (Section 9.1.3.8). -->

          <li>Get maximum transport-message size that may be sent using a non-fragmented IP packet from the configured interface:
<tt>singularTransmissionMsgMaxLen</tt> property (<xref target="conn-max-msg-notfrag"/>).</t>
        </li>
        <li>
          <t>Get max. target="conn-max-msg-notfrag"/>).</li>

          <li>Get maximum transport-message size that may be received from the configured interface:
<tt>recvMsgMaxLen</tt> property (<xref target="conn-max-msg-recv"/>).</t>
        </li>
        <li>
          <t>Obtain target="conn-max-msg-recv"/>).</li>

          <li>Obtain ECN field:
This is a read-only Message Property of the MessageContext object (see "UDP(-Lite)-specific Property: ECN" <xref target="receive-ecn"/>).</t>
        </li>
        <li>
          <t>"Specify
"<xref target="receive-ecn" format="title"/>" (<xref target="receive-ecn" format="default"/>)).</li>

          <li>"Specify DSCP field", "Disable Nagle algorithm", and "Enable and configure a <tt>Low Extra Delay Background Transfer</tt>":
as suggested in <xref section="5.5" sectionFormat="of" target="RFC8923"/>, these transport features are collectively offered via the <tt>connCapacityProfile</tt> property (<xref target="prop-cap-profile"/>). Per-Message control ("Request not to bundle messages") is offered via the <tt>msgCapacityProfile</tt> property (<xref target="send-profile"/>).</t>
        </li>
        <li>
          <t>Close target="send-profile"/>).</li>

          <li>Close after reliably delivering all remaining data, causing an event informing the application on the other side:
this is offered by the <tt>Close</tt> action with slightly changed semantics in line with the discussion in <xref section="5.2" sectionFormat="of" target="RFC8923"/> (<xref target="termination"/>).</t>
        </li>
        <li>
          <t>"Abort (see also <xref target="termination"/>).</li>

<!--[rfced] It seems this bullet is discussing two options: should
     "this" be made "these"?

Original:

   "Abort without delivering remaining data, causing an event
   informing the application on the other side" and "Abort without
   delivering remaining data, not causing an event informing the
   application on the other side":  this is offered by the Abort action
   without promising that this is signaled to the other side.

Perhaps:

   "Abort without delivering remaining data, causing an event
   informing the application on the other side" and "Abort without
   delivering remaining data, not causing an event informing the
   application on the other side":  these are offered by the Abort action
      without promising that these are signaled to the other side.
-->

          <li>"Abort without delivering remaining data, causing an event informing the application on the other side" and "Abort without delivering remaining data, 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 signaled to the other side. If it is, a <tt>ConnectionError</tt> event will be invoked at the peer (<xref target="termination"/>).</t>
        </li>
        <li>
          <t>"Reliably target="termination"/>).</li>

          <li>"Reliably transfer data, with congestion control", "Reliably transfer a message, with congestion control" control", and "Unreliably transfer a message":
data is transferred via the <tt>Send</tt> action (<xref target="sending"/>). Reliability is controlled via the <tt>reliability</tt> (<xref target="prop-reliable"/>) property and the <tt>msgReliable</tt> Message Property (<xref target="msg-reliable-message"/>). Transmitting data as a Message or without delimiters is controlled via Message Framers (<xref target="framing"/>). The choice of congestion control is provided via the <tt>congestionControl</tt> property (<xref target="prop-cc"/>).</t>
        </li>
        <li>
          <t>Configurable target="prop-cc"/>).</li>

          <li>Configurable Message Reliability:
the <tt>msgLifetime</tt> Message Property implements a time-based way to configure message reliability (<xref target="msg-lifetime"/>).</t>
        </li>
        <li>
          <t>"Ordered target="msg-lifetime"/>).</li>

          <li>"Ordered message delivery (potentially slower than unordered)" and "Unordered message delivery (potentially faster than ordered)":
these two transport features are controlled via the Message Property <tt>msgOrdered</tt> (<xref target="msg-ordered"/>).</t>
        </li>
        <li>
          <t>Request target="msg-ordered"/>).</li>

          <li>Request not to delay the acknowledgment acknowledgement (SACK) of a message:
should the protocol support it, this is one of the transport features the Transport Services system can apply when an application uses the <tt>connCapacityProfile</tt> Property (<xref target="prop-cap-profile"/>) or the <tt>msgCapacityProfile</tt> Message Property (<xref target="send-profile"/>) with value <tt>Low Latency/Interactive</tt>.</t>
        </li>
        <li>
          <t>Receive Latency/Interactive</tt>.</li>

          <li>Receive data (with no message delimiting):
<tt>Receive</tt> action (<xref target="receiving-action"/>) and <tt>Received</tt> event (<xref target="receive-complete"/>).</t>
        </li>
        <li>
          <t>Receive target="receive-complete"/>).</li>

          <li>Receive a message:
<tt>Receive</tt> action (<xref target="receiving-action"/>) and <tt>Received</tt> event (<xref target="receive-complete"/>), target="receive-complete"/>) using Message Framers (<xref target="framing"/>).</t>
        </li>
        <li>
          <t>Information target="framing"/>).</li>

          <li>Information about partial message arrival:
<tt>Receive</tt> action (<xref target="receiving-action"/>) and <tt>ReceivedPartial</tt> event (<xref target="receive-partial"/>).</t>
        </li>
        <li>
          <t>Notification target="receive-partial"/>).</li>

          <li>Notification of send failures:
<tt>Expired</tt> event (<xref target="expired"/>) and <tt>SendError</tt> event (<xref target="send-error"/>).</t>
        </li>
        <li>
          <t>Notification target="send-error"/>).</li>

          <li>Notification that the stack has no more user data to send:
applications can obtain this information via the <tt>Sent</tt> event (<xref target="sent"/>).</t>
        </li>
        <li>
          <t>Notification target="sent"/>).</li>

          <li>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 target="receive-error"/>).</li>

          <li>Notification of Excessive Retransmissions (early warning below abortion threshold):
	  <tt>SoftError</tt> event (<xref target="soft-errors"/>).</t>
        </li> target="soft-errors"/>).</li>

      </ul>
    </section>

    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>This work has received funding from the European Union's Horizon 2020 research and
innovation programme under grant agreements No. 644334 (NEAT) and No. 688421 (MAMI).</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="Josh Graessley"/>, <contact fullname="David Schinazi"/>, and <contact fullname="Eric 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 implementation experience
and for contributing text, e.g., on multicast.</t>
    </section>

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

 PVD / PvD

 remote Endpoint Identifier / Remote Endpoint Identifier

 sockets API / Socket API (per the rest of this cluster)

 Transport System (1 instance / transport system (4 instances)

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

 boolean value / Boolean value

 enumerated / Enumerated (and enumeration / Enumeration)

 namespace / Namespace (in running text)

 preference / Preference

 type / Type

 Type Selection Property / Selection Property

 user timeout value / 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).

d) We have capped Transport Services to match other uses in the
cluster.  Please review the remaining uses of "transport service" and
let us know if these need to be capped as well.

e) Just a general FYI that, with the high number of capped terms,
there will likely be further capitalization questions coming as AUTH48
continues.
-->

<!--[rfced] Please note that we have expanded abbreviations in this
     document.  Please review and let us know any objections.
     Examples include:

Path MTU (PMTU)
Differentiated Services Code Points (DSCPs)
Stream Control Transmission Protocol (SCTP)
Datagram Packetization Layer Path MTU Discovery (DPLPMTUD)
Multipath TCP (MPTCP)
Low Extra Delay Background Transport (LEDBAT)
Don’t Fragment (DF)
-->

<!--[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.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the
     online Style Guide
     <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
     and let us know if any changes are needed.  Updates of this
     nature typically result in more precise language, which is
     helpful for readers.

Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.

-->

</rfc>