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

<!-- draft submitted in xml v3 -->

<!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.2 (Ruby 3.2.2) -->

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

  <front>
    <title abbrev="TAPS Architecture">Architecture and Requirements for Transport Services</title>

    <seriesInfo name="Internet-Draft" value="draft-ietf-taps-arch-19"/> name="RFC" value="9621"/>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly" role="editor">
      <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>
    <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="A." surname="Brunstrom" fullname="Anna Brunstrom">
      <organization>Karlstad University</organization>
      <address>
        <postal>
          <street>Universitetsgatan 2</street>
          <city>651 88 Karlstad</city>
          <country>Sweden</country>
        </postal>
        <email>anna.brunstrom@kau.se</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="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>
          <country>United Kingdom</country>
        </postal>
        <email>csp@csperkins.org</email>
      </address>
    </author>
    <date year="2023" month="November" day="09"/>
    <area>Transport</area>
    <workgroup>TAPS Working Group</workgroup>
    <keyword>Internet-Draft</keyword> year="2024" 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>. -->

    <abstract>
      <?line 68?>

<t>This document describes an architecture for exposing transport protocol features to applications for network communication. This system that 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, applications and describes how a Transport Services Implementation can use multiple IP addresses, multiple protocols, and multiple paths, paths and can 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 Services API and a Transport Services Implementation.</t>
    </abstract>
  </front>
  <middle>
    <?line 72?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Many application programming interfaces Application Programming Interfaces (APIs) to provide transport interfaces to networks have been deployed, perhaps the most widely known and imitated being the BSD Socket <xref target="POSIX"/> interface (Socket API). API) <xref target="POSIX"/>.
The naming of objects and functions across these APIs is not consistent and varies varies, depending on the protocol being used.
For example, the concept of sending and receiving streams of data is conceptually the same for both an unencrypted Transmission Control Protocol (TCP) stream and operating on an encrypted Transport Layer Security (TLS) stream <xref target="RFC8446"/> stream over TCP, but applications cannot use the same socket <tt>send()</tt> and <tt>recv()</tt> calls on top of both kinds of connections.
Similarly, terminology for the implementation of transport protocols varies based on the context of the protocols themselves: terms such as "flow", "stream", "message", and "connection" can take on many different meanings.
This variety can lead to confusion when trying to understand the similarities and differences between protocols, protocols and how applications can use them effectively.</t> effectively.
</t>
      <t>The goal of the Transport Services System architecture is to provide a flexible
and reusable system with a common interface for transport protocols.
An application uses the Transport Services System through an abstract Connection (we use capitalization to distinguish these from the underlying connections of, e.g., for example, TCP).
This provides
flexible connection establishment allowing an application to request or require a set of properties.</t>
      <t>As applications adopt this interface, they will benefit from a wide set of transport features that can evolve over time, time
and will ensure that the system providing the interface 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.</t>
      <t>This architecture can also support applications by offering racing mechanisms (attempting multiple IP addresses, protocols, or network paths in parallel), which otherwise need to be implemented in each application separately (see <xref target="racing"/>). Racing selects one or more candidates candidates, each with equivalent protocol stacks Protocol Stacks that are used to identify
an optimal combination of a transport protocol instance such as TCP, UDP, or another transport, together with configuration of parameters and
interfaces.
A Connection represents an object that, once established, can be used to send and receive messages.
A Connection can also be created from another Connection, by cloning, and then forms a part of a Connection Group whose Connections share properties.</t> properties.

</t>
      <t>This document was developed in parallel with the specification of the Transport Services API <xref target="I-D.ietf-taps-interface"/> target="RFC9622"/> and implementation guidelines <xref target="I-D.ietf-taps-impl"/>. target="RFC9623"/>. Although following the Transport Services architecture does not require all APIs and implementations to be identical, a common minimal set of features represented in a consistent fashion will enable applications to be easily ported from one implementation of the Transport Services System to another.</t>
      <section anchor="background">
        <name>Background</name>
        <t>The architecture of the Transport Services System is based on the survey of services provided by IETF transport protocols and congestion control mechanisms <xref target="RFC8095"/>, target="RFC8095"/> and the distilled minimal set of the features offered by transport protocols <xref target="RFC8923"/>. These documents identified common features and patterns across all transport protocols developed thus far in the IETF.</t>
        <t>Since transport security is an increasingly relevant aspect of using transport protocols on the Internet, this document also considers the impact of transport security protocols on the feature-set feature set exposed by Transport Services <xref target="RFC8922"/>.</t>
        <t>One of the key insights to come from identifying the minimal set of features provided by transport protocols <xref target="RFC8923"/> was that features either require (1)&nbsp;require application interaction and guidance (referred to in that document as Functional or Optimizing Features), Features) or else can (2)&nbsp;can be handled automatically by an implementation of the Transport Services System (referred to as Automatable Features). Among the identified Functional and Optimizing Features, some are common across all or nearly all transport protocols, while others present features that, if specified, would only be useful with a subset of protocols, but would not harm the functionality of other protocols. For example, some protocols can deliver messages faster more quickly for applications that do not require messages to arrive in the order in which they were sent. This functionality needs to be explicitly allowed by the application, since reordering messages would be undesirable in many cases.</t>
      </section>
      <section anchor="overview">
        <name>Overview</name>
        <t>This document describes
        <t>The following sections describe the Transport Services System in three sections:</t> System:</t>
        <ul spacing="normal">
          <li>
            <t><xref target="model"/> describes how the Transport Services API model differs from that of traditional socket-based APIs. Specifically, it offers asynchronous event-driven interaction, the use of messages for data transfer, and the flexibility to use different transport protocols and paths without requiring major changes to the application.</t>
          </li>
          <li>
            <t><xref target="requirements"/> explains the fundamental requirements for a Transport Services System. These principles are intended to make sure that transport protocols can continue to be enhanced and evolve without requiring significant changes by application developers.</t>
          </li>
          <li>
            <t><xref target="concepts"/> presents the Transport Services Implementation and defines the concepts that are used by the API <xref target="I-D.ietf-taps-interface"/> target="RFC9622"/> and described in the implementation guidelines <xref target="I-D.ietf-taps-impl"/>. target="RFC9623"/>. This introduces the Preconnection, which allows applications to configure Connection Properties.</t>
          </li>
        </ul>
      </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 anchor="glossary-of-key-terms">
        <name>Glossary of Key Terms</name>
        <t>This subsection provides a glossary of key terms related to the Transport Services architecture. It provides a short description of key terms that are later defined later in this document.</t>
        <ul
        <dl spacing="normal">
          <li>
            <t>Application:

            <dt>Application:</dt><dd> An entity that uses the transport layer for end-to-end delivery of data across the network <xref target="RFC8095"/>.</t>
          </li>
          <li>
            <t>Cached State: target="RFC8095"/>.</dd>

            <dt>Cached State:</dt><dd> The state and history that the Transport Services Implementation keeps for each set of the associated Endpoints that have been used previously.</t>
          </li>
          <li>
            <t>Candidate Path: previously.</dd>

            <dt>Candidate Path:</dt><dd> One path that is available to an application and conforms to the Selection Properties and System Policy during racing.</t>
          </li>
          <li>
            <t>Candidate racing.</dd>

            <dt>Candidate Protocol Stack: Stack:</dt><dd> One Protocol Stack that can be used by an application for a Connection during racing.</t>
          </li>
          <li>
            <t>Client: racing.</dd>

            <dt>Client:</dt><dd> The peer responsible for initiating a Connection.</t>
          </li>
          <li>
            <t>Clone: Connection.</dd>

            <dt>Clone:</dt><dd> A Connection that was created from another Connection, Connection and that forms a part of a Connection Group.</t>
          </li>
          <li>
            <t>Connection: Group.</dd>

            <dt>Connection:</dt><dd> Shared state of two or more Endpoints that persists across Messages that are transmitted and received between these Endpoints <xref target="RFC8303"/>. When this document (and and other Transport Services documents) documents use the capitalized "Connection" term, it refers to a Connection object that is being offered by the Transport Services system, as opposed to more generic uses of the word "connection".</t>
          </li>
          <li>
            <t>Connection Context: "connection".</dd>

            <dt>Connection Context:</dt><dd> A set of stored properties across Connections, such as cached protocol state, cached path state, and heuristics, which can include one or more Connection Groups.</t>
          </li>
          <li>
            <t>Connection Group: Groups.</dd>

            <dt>Connection Group:</dt><dd> A set of Connections that share properties and caches.</t>
          </li>
          <li>
            <t>Connection Property: caches.</dd>

            <dt>Connection Property:</dt><dd> A Transport Property that controls per-Connection behavior of a Transport Services implementation.</t>
          </li>
          <li>
            <t>Endpoint: Implementation.</dd>

            <dt>Endpoint:</dt><dd> An entity that communicates with one or more other endpoints using a transport protocol.</t>
          </li>
          <li>
            <t>Endpoint Identifier: protocol.</dd>

            <dt>Endpoint Identifier:</dt><dd> An identifier that specifies one side of a Connection (local or remote), such as a hostname or URL.</t>
          </li>
          <li>
            <t>Equivalent URL.</dd>

            <dt>Equivalent Protocol Stacks: Stacks:</dt><dd> Protocol Stacks that can be safely swapped or raced in parallel during establishment of a Connection.</t>
          </li>
          <li>
            <t>Event: Connection.</dd>

            <dt>Event:</dt><dd> A primitive that is invoked by an Endpoint <xref target="RFC8303"/>.</t>
          </li>
          <li>
            <t>Framer: target="RFC8303"/>.</dd>

            <dt>Framer:</dt><dd> A data translation layer that can be added to a Connection to define how application-layer Messages are transmitted over a Protocol Stack.</t>
          </li>
          <li>
            <t>Local Endpoint: Stack.</dd>

            <dt>Local Endpoint:</dt><dd> The local Endpoint.</t>
          </li>
          <li>
            <t>Local Endpoint.</dd>

            <dt>Local Endpoint Identifier: Identifier:</dt><dd> A representation of the application's identifier for itself that it uses for a Connection.</t>
          </li>
          <li>
            <t>Message: Connection.</dd>

            <dt>Message:</dt><dd> A unit of data that can be transferred between two Endpoints over a Connection.</t>
          </li>
          <li>
            <t>Message Property: Connection.</dd>

            <dt>Message Property:</dt><dd> A property that can be used to specify details about Message transmission, transmission or obtain details about the transmission after receiving a Message.</t>
          </li>
          <li>
            <t>Parameter: Message.</dd>

            <dt>Parameter:</dt><dd> A value passed between an application and a transport protocol by a primitive <xref target="RFC8303"/>.</t>
          </li>
          <li>
            <t>Path: target="RFC8303"/>.</dd>

            <dt>Path:</dt><dd> A representation of an available set of properties that a Local Endpoint can use to communicate with a Remote Endpoint.</t>
          </li>
          <li>
            <t>Peer: Endpoint.</dd>

            <dt>Peer:</dt><dd> An Endpoint application party to a Connection.</t>
          </li>
          <li>
            <t>Preconnection: an Connection.</dd>

            <dt>Preconnection:</dt><dd> An object that represents a Connection that has not yet been established.</t>
          </li>
          <li>
            <t>Preference: established.</dd>

            <dt>Preference:</dt><dd> A preference to prohibit, avoid, ignore, prefer, for prohibiting, avoiding, ignoring, preferring, or require requiring a specific Transport Feature.</t>
          </li>
          <li>
            <t>Primitive: transport feature.</dd>

            <dt>Primitive:</dt><dd> A function call that is used to locally communicate between an application and an Endpoint, which is related to one or more Transport Features transport features <xref target="RFC8303"/>.</t>
          </li>
          <li>
            <t>Protocol Instance: target="RFC8303"/>.</dd>

            <dt>Protocol Instance:</dt><dd> A single instance of one protocol, including any state necessary to establish connectivity or send and receive Messages.</t>
          </li>
          <li>
            <t>Protocol Stack: Messages.</dd>

            <dt>Protocol Stack:</dt><dd> A set of Protocol Instances that are used together to establish connectivity or send and receive Messages.</t>
          </li>
          <li>
            <t>Racing: Messages.</dd>

            <dt>Racing:</dt><dd> The attempt to select between multiple Protocol Stacks based on the Selection and Connection Properties communicated by the application, along with any Security Parameters.</t>
          </li>
          <li>
            <t>Remote Endpoint: Parameters.</dd>

            <dt>Remote Endpoint:</dt><dd> The peer that a local Endpoint can communicate with when a Connection is established.</t>
          </li>
          <li>
            <t>Remote established.</dd>

            <dt>Remote Endpoint Identifier: Identifier:</dt><dd> A representation of the application's identifier for a peer that can participate in establishing a Connection.</t>
          </li>
          <li>
            <t>Rendezvous: Connection.</dd>

            <dt>Rendezvous:</dt><dd> The action of establishing a peer-to-peer Connection with a Remote Endpoint.</t>
          </li>
          <li>
            <t>Security Parameters: Endpoint.</dd>

            <dt>Security Parameters:</dt><dd> Parameters that define an application's requirements for authentication and encryption on a Connection.</t>
          </li>
          <li>
            <t>Server: Connection.</dd>

            <dt>Selection Property:</dt><dd> A Transport Property that can be set to influence the selection of paths between the Local and Remote Endpoints.</dd>

            <dt>Server:</dt><dd> The peer responsible for responding to a Connection initiation.</t>
          </li>
          <li>
            <t>Socket: initiation.</dd>

            <dt>Socket:</dt><dd> The combination of a destination IP address and a destination port number <xref target="RFC8303"/>.</t>
          </li>
          <li>
            <t>System Policy: target="RFC8303"/>.</dd>

            <dt>System Policy:</dt><dd> The input from an operating system or other global preferences that can constrain or influence how an implementation will gather Candidate Paths and Protocol Stacks and race the candidates during establishment of a Connection.</t>
          </li>
          <li>
            <t>Selection Property: A Transport Property that can be set to influence the selection of paths between the Local and Remote Endpoints.</t>
          </li>
          <li>
            <t>Transport Feature: Connection.</dd>

            <dt>Transport Feature:</dt><dd> A specific end-to-end feature that the transport layer provides to an application.</t>
          </li>
          <li>
            <t>Transport Property: application.</dd>

            <dt>Transport Property:</dt><dd> A property that expresses requirements, prohibitions of a transport protocol and preferences the services it provides <xref target="RFC8095"/>.</t>
          </li>
          <li>
            <t>Transport Service: target="RFC8095"/>.</dd>

            <dt>Transport Service:</dt><dd> A set of transport features, without an association to not associated with any given framing protocol, that provides a complete service to an application.</t>
          </li>
          <li>
            <t>Transport application.</dd>

            <dt>Transport Services Implementation: This consists of all Implementation:</dt><dd> All objects and protocol instances used internally to a system or library to implement the functionality needed to provide a transport service across a network, as required by the abstract interface.</t>
          </li>
          <li>
            <t>Transport interface.</dd>

            <dt>Transport Services System: System:</dt><dd> The Transport Services Implementation and the Transport Services API.</t>
          </li>
        </ul> API.</dd>

        </dl>
      </section>
    </section>
    <section anchor="model">
      <name>API Model</name>
      <t>The traditional model of using sockets can be represented as follows (see figure 1):</t> <xref target="fig-sockets"/>):</t>
      <ul spacing="normal">
        <li>
          <t>Applications create connections and transfer data using the Socket API.</t>
        </li>
        <li>
          <t>The Socket API provides the interface to the implementations of TCP and UDP
(typically implemented in the system's kernel).</t>
        </li>
        <li>
          <t>TCP and UDP in the kernel send and receive data over the available network-layer interfaces.</t>
        </li>
        <li>
          <t>Sockets are bound directly to transport-layer and network-layer addresses,
obtained via a separate resolution step, usually performed by a
system-provided DNS stub resolver.</t>
        </li>
      </ul>
      <figure anchor="fig-sockets">
        <name>Socket API Model</name>
        <artwork><![CDATA[
+-----------------------------------------------------+
|                    Application                      |
+-----------------------------------------------------+
        |                 |                  |
  +------------+     +------------+    +--------------+
  |  DNS stub Stub  |     | Stream API |    | Datagram API |
  |  resolver  Resolver  |     +------------+    +--------------+
  +------------+          |                  |
                    +---------------------------------+
                    |    TCP                UDP       |
                    |    Kernel Networking Stack      |
                    +---------------------------------+
                                    |
+-----------------------------------------------------+
|               Network Layer               Network-Layer Interface               |
+-----------------------------------------------------+
]]></artwork>
      </figure>
      <t>The architecture of the Transport Services System is an evolution of this general model of interaction. It both modernizes the API presented to applications by the transport layer and enriches the capabilities of the Transport Services Implementation below this API.</t>
      <figure anchor="fig-taps">
        <name>Transport Services API Model</name>
        <artwork><![CDATA[
+-----------------------------------------------------+
|                    Application                      |
+-----------------------------------------------------+
                          |
+-----------------------------------------------------+
|              Transport Services API                 |
+-----------------------------------------------------+
                          |
+-----------------------------------------------------+
|          Transport Services Implementation          |
|  (Using: DNS, UDP, TCP, SCTP, DCCP, TLS, QUIC, etc) |
+-----------------------------------------------------+
                          |
+-----------------------------------------------------+
|               Network Layer Interface               |
+-----------------------------------------------------+

]]></artwork>
      </figure>
      <t>The Transport Services API <xref target="I-D.ietf-taps-interface"/> target="RFC9622"/> defines the interface for an application to create Connections and transfer data. It combines interfaces for multiple interaction patterns into a unified whole (see figure 2). <xref target="fig-taps"/>).
This offers generic functions and also the protocol-specific mappings for TCP, UDP, UDP-Lite, and other protocol layers. These mapping mappings are extensible. Future documents could define similar mappings for new layers and for other transport protocols, such as QUIC <xref target="RFC9000"/>.
By target="RFC9000"/>.</t>
      <figure anchor="fig-taps">
        <name>Transport Services API Model</name>
        <artwork><![CDATA[
+-----------------------------------------------------+
|                    Application                      |
+-----------------------------------------------------+
                          |
+-----------------------------------------------------+
|              Transport Services API                 |
+-----------------------------------------------------+
                          |
+-----------------------------------------------------+
|          Transport Services Implementation          |
|  (Using DNS, UDP, TCP, SCTP, DCCP, TLS, QUIC, etc.) |
+-----------------------------------------------------+
                          |
+-----------------------------------------------------+
|               Network-Layer Interface               |
+-----------------------------------------------------+
]]></artwork>
      </figure>
<t>By combining name resolution with connection establishment and data transfer in a single API, it allows for more flexible implementations to provide path and transport protocol agility on the application's behalf.</t>
      <t>The Transport Services Implementation <xref target="I-D.ietf-taps-impl"/> target="RFC9623"/> is the component of the Transport Services System that implements the transport layer transport-layer protocols and other functions needed to send and receive data. It is responsible for mapping the API to a specific available transport Protocol Stack and managing the available network interfaces and paths.</t>
      <t>There are key differences between the architecture of the Transport Services System and the architecture of the Socket API: the API. The API of the Transport Services System is System:</t>

<ul spacing="normal">
  <li>is asynchronous and event-driven; it uses driven by events;</li>
  <li>uses messages for representing data transfer to applications; and it describes applications;</li>
  <li>describes how a Transport Services Implementation can resolve Endpoint Identifiers to use multiple IP addresses, multiple protocols, and multiple paths, paths and to provide multiple application streams.</t> streams.</li>
</ul>
      <section anchor="event-driven-api">
        <name>Event-Driven API</name>
        <t>Originally, the Socket API presented a blocking interface for establishing connections and transferring data. However, most modern applications interact with the network asynchronously. Emulation of an asynchronous interface using the Socket API can use a try-and-fail model: If if the application wants to read, read but data has not yet been received from the peer, the call to read will fail. The application then waits and can try again later.</t>
        <t>In contrast to the Socket API, all interactions using the Transport Services API are expected to be asynchronous. The API is defined around an event-driven model (see <xref target="events"/>), which models this asynchronous interaction. Other forms of asynchronous communication could also be available to applications, depending on the platform implementing the interface.</t>
        <t>For example, when an application that uses the Transport Services API wants to receive data, it issues an asynchronous call to receive new data from the Connection. When delivered data becomes available, this data is delivered to the application using asynchronous events that contain the data. Error handling is also asynchronous, resulting in asynchronous error events.</t>
        <t>This API also delivers events regarding the lifetime of a connection and changes in the available network links, which were not previously made explicit in the Socket API.</t>
        <t>Using asynchronous events allows for a more natural interaction model when establishing connections and transferring data. Events in time more closely reflect the nature of interactions over networks, as opposed to how the Socket API represents network resources as file system objects that may be temporarily unavailable.</t>
        <t>Separate from events, callbacks are also provided for asynchronous interactions with the Transport Services API that are not directly related to events on the network or network interfaces.</t>
      </section>
      <section anchor="data-transfer-using-messages">
        <name>Data Transfer Using Messages</name>
        <t>The Socket API provides a message interface for datagram protocols like UDP, UDP but provides an unstructured stream abstraction for TCP. While TCP has the ability to send and receive data as a byte-stream, most applications need to interpret structure within this byte-stream. For example, HTTP/1.1 uses character delimiters to segment messages over a byte-stream <xref target="RFC9112"/>; TLS record headers carry a version, content type, and length <xref target="RFC8446"/>; and HTTP/2 uses frames to segment its headers and bodies <xref target="RFC9113"/>.</t>
        <t>The Transport Services API represents data as messages, so that it more closely matches the way applications use the network. A message-based abstraction provides many benefits, such as:</t>
        <ul spacing="normal">
          <li>
            <t>providing additional information to the Protocol Stack;</t>
          </li>
          <li>
            <t>the ability to associate deadlines with messages, for applications that care about timing;</t>
          </li>
          <li>
            <t>the ability to control reliability, which messages to retransmit when there is packet loss, and how best to make use of the data that arrived;</t>
          </li>
          <li>
            <t>the ability to automatically assign messages and connections to underlying transport connections to utilize multi-streaming and pooled connections.</t>
          </li>
        </ul>
        <t>Allowing applications to interact with messages is backwards-compatible backward-compatible with existing protocols and APIs because it does not change the wire format of any protocol. Instead, it provides the Protocol Stack with additional information to allow it to make better use of modern transport services, Transport Services, while simplifying the application's role in parsing data. For protocols that inherently use a streaming abstraction, framers (<xref target="datatransfer"/>) bridge the gap between the two abstractions.</t>
      </section>
      <section anchor="flexible-implementation">
        <name>Flexible Implementation</name>
        <t>The Socket API for protocols like TCP is generally limited to connecting to a single address over a single interface (IP source address).
It also presents a single stream to the application. Software layers built upon this API often propagate this limitation of a single-address single-stream model. The Transport Services architecture is designed:</t> designed to:</t>
        <ul spacing="normal">
          <li>
            <t>to handle
            <t>handle multiple candidate endpoints, protocols, and paths;</t>
          </li>
          <li>
            <t>to support
            <t>support candidate protocol racing to select the most optimal stack in each situation;</t>
          </li>
          <li>
            <t>to support
            <t>support multipath and multistreaming protocols;</t>
          </li>
          <li>
            <t>to provide
            <t>provide state caching and application control over it.</t>
          </li>
        </ul>
        <t>A Transport Services Implementation is intended to be flexible at connection establishment time, considering many different options and trying to select the most optimal combinations by racing them and measuring the results (see <xref target="gathering"/> Sections&nbsp;<xref target="gathering" format="counter"/> and <xref target="racing"/>). target="racing" format="counter"/>). This requires applications to specify identifiers for the Local and Remote Endpoint that are higher-level at a higher level than IP addresses, such as a hostname or URL, which URL.  These identifiers are used by a Transport Services Implementation for resolution, path selection, and racing. An implementation can further implement fallback mechanisms if connection establishment of for one protocol fails or performance is detected determined to be unsatisfactory.</t> unsatisfactory.
</t>
        <t>Information used in connection establishment (e.g. (e.g., cryptographic resumption tokens, information about usability of certain protocols on the path, results of racing in previous connections) are is cached in the Transport Services Implementation. Applications have control over whether this information is used for a specific establishment, in order to allow tradeoffs trade-offs between efficiency and linkability.</t>
        <t>Flexibility after connection establishment is also important. Transport protocols that can migrate between multiple network-layer interfaces need to be able to process and react to interface changes. Protocols that support multiple application-layer streams need to support initiating and receiving new streams using existing connections.</t>
      </section>
      <section anchor="coexistence">
        <name>Coexistence</name>
        <t>While the architecture of the Transport Services System is designed as an enhanced replacement for the Socket API, it need not replace it entirely on a system or platform; indeed, coexistence has been recommended for incremental deployability <xref target="RFC8170"/>. The architecture is therefore designed such that it can run alongside (or, indeed, on top of) an existing Socket API implementation; only applications built to on the Transport Services API are managed by the system's Transport Services Implementation.</t>
      </section>
    </section>
    <section anchor="requirements">
      <name>API and Implementation Requirements</name>
      <t>One goal of the architecture is to redefine the interface between applications and transports in a way that allows the transport layer to evolve and improve without fundamentally changing the contract with the application. This requires a careful consideration of how to expose the capabilities of protocols. The architecture also encompasses system policies that can influence and inform how transport protocols use a network path or interface.</t>
      <t>There are several ways the Transport Services System can offer flexibility to an application: it can provide application.  It can:</t>
 <ul spacing="normal">
  <li>provide access to transport protocols and protocol features; it can use features;</li>
  <li>use these protocols across multiple paths that could have different performance and functional characteristics; and it can communicate characteristics;</li>
  <li>communicate with different remote systems to optimize performance, robustness to failure, or some other metric. Beyond metric.</li>
 </ul>
 <t>Beyond these, if the Transport Services API remains the same over time, new protocols and features can be added to the Transport Services Implementation without requiring changes in applications for adoption. Similarly, this can provide a common basis for utilizing information about a network path or interface, enabling evolution below the transport layer.</t>
      <t>The normative requirements described in this section allow Transport Services APIs and the Transport Services Implementation to provide this functionality without causing incompatibility or introducing security vulnerabilities.</t>
      <section anchor="provide-common-apis-for-common-features">
        <name>Provide Common APIs for Common Features</name>
        <t>Any functionality that is common across multiple transport protocols SHOULD <bcp14>SHOULD</bcp14> be made accessible through a unified set of calls using the Transport Services API. As a baseline, any Transport Services API SHOULD <bcp14>SHOULD</bcp14> allow access to the minimal set of features offered by transport protocols <xref target="RFC8923"/>. If that minimal set is updated or expanded in the future, the Transport Services API ought to be extended to match.</t>
        <t>An application can specify constraints and preferences for the protocols, features, and network interfaces it will use via Properties. Properties are used by an application to declare its preferences for how the transport service should operate at each stage in the lifetime of a connection. Transport Properties are subdivided into Selection the following:</t>
 <ul spacing="normal">
  <li>Selection Properties, which specify which paths and Protocol Stacks can be used and are preferred by the application; Connection application;</li>
  <li>Connection Properties, which inform decisions made during connection establishment and fine-tune the established connection; and Message and</li>
  <li>Message Properties, which can be set on individual Messages.</t> Messages.</li>
 </ul>
        <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the Transport Services API offers offer properties that are common to multiple transport protocols. This enables a Transport Services System to appropriately select between protocols that offer equivalent features. Similarly, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the Properties offered by the Transport Services API are be applicable to a variety of network layer network-layer interfaces and paths, which permits to permit racing of different network paths without affecting the applications using the API. Each is expected to have a default value.</t>
        <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the default values for Properties are be selected to ensure correctness for the widest set of applications, while providing the widest set of options for selection. For example, since both applications that require reliability and those that do not require reliability can function correctly when a protocol provides reliability, reliability ought to be enabled by default. As another example, the default value for a Property regarding the selection of network interfaces ought to permit as many interfaces as possible.</t>
        <t>Applications using the Transport Services API need to be designed to be robust to the automated selection provided by the Transport Services System. This automated selection is constrained by the properties and preferences expressed by the application and requires applications to explicitly set properties that define any necessary constraints on protocol, path, and interface selection.</t>
      </section>
      <section anchor="allow-access-to-specialized-features">
        <name>Allow Access to Specialized Features</name>
        <t>There are applications that will need to control fine-grained details of transport protocols to optimize their behavior and ensure compatibility with remote systems. It is therefore RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the Transport Services API and the Transport Services Implementation permit more specialized protocol features to be used.</t>
        <t>A
        <t>Some specialized feature features could be needed by an application only when using a specific protocol, protocol and not when using others. For example, if an application is using TCP, it could require control over the User Timeout Option for TCP <xref target="RFC5482"/>; these options target="RFC5482"/>. Such features would not take effect for other transport protocols. In such cases, the API ought to expose the features in such a way that they take effect when a particular protocol is selected, selected but do not imply that only that protocol could be used. For example, if the API allows an application to specify a preference to use for using the User Timeout Option, communication would not fail when a protocol such as UDP is selected.</t>
        <t>Other specialized features, however, can also be strictly required by an application and thus further constrain the set of protocols that can be used. For example, if an application requires support for automatic handover or failover for a connection, only Protocol Stacks that provide this feature are eligible to be used, e.g., Protocol Stacks that include a multipath protocol or a protocol that supports connection migration. A Transport Services API needs to allow applications to define such requirements and constrain the options available to a Transport Services Implementation. Since such options are not part of the core/common features, it will generally be simple for an application to modify its set of constraints and change the set of allowable protocol features without changing the core implementation.</t>
        <t>To control these specialized features, the application can declare its preference – preference: whether the presence of a specific feature is prohibited, should be avoided, can be ignored, is preferred, or is required in the pre-establishment preestablishment phase. An implementation of a Transport Services API would honor this preference and allow the application to query the availability of each specialized feature after a successful establishment.</t>
      </section>
      <section anchor="equivalence">
        <name>Select Between Equivalent Protocol Stacks</name>
        <t>A Transport Services Implementation can attempt to use, and select between between, multiple Protocol Stacks based on the Selection and Connection Properties communicated by the application, along with any Security Parameters. The implementation can only attempt to use multiple Protocol Stacks when they are "equivalent", which means that the stacks can provide the same Transport Properties and interface expectations as requested by the application. Equivalent Protocol Stacks can be safely swapped or raced in parallel (see <xref target="racing"/>) during connection establishment.</t>
        <t>The following two examples show non-equivalent Protocol Stacks:</t>
        <ul spacing="normal">
          <li>
            <t>If the application requires preservation of message boundaries, a Protocol Stack that runs UDP as the top-level interface to the application is not equivalent to a Protocol Stack that runs TCP as the top-level interface. A UDP stack would allow an application to read out message boundaries based on datagrams sent from the remote system, whereas TCP does not preserve message boundaries on its own, own but needs a framing protocol on top to determine message boundaries.</t>
          </li>
          <li>
            <t>If the application specifies that it requires reliable transmission of data, then a Protocol Stack using UDP without any reliability layer on top would not be allowed to replace a Protocol Stack using TCP.</t>
          </li>
        </ul>
        <t>The following example shows Equivalent equivalent Protocol Stacks:</t>
        <ul spacing="normal">
          <li>
            <t>If the application does not require reliable transmission of data, then a Protocol Stack that adds reliability could be regarded as an Equivalent equivalent Protocol Stack as long as providing this would not conflict with any other application-requested properties.</t>
          </li>
        </ul>
        <t>A Transport Services Implementation can race different security
protocols, e.g., if the System Policy is explicitly configured to consider them equivalent.
A Transport Services implementation SHOULD Implementation <bcp14>SHOULD</bcp14> only race Protocol Stacks where the transport security protocols within the stacks are identical.
To ensure that security protocols are not incorrectly swapped, a Transport Services Implementation MUST <bcp14>MUST</bcp14> only select Protocol Stacks that meet application requirements (<xref target="RFC8922"/>). <xref target="RFC8922"/>.
A Transport Services Implementation MUST NOT <bcp14>MUST NOT</bcp14> automatically fall back from secure protocols to insecure protocols, protocols or fall back to weaker versions of secure protocols.
A Transport Services Implementation MAY <bcp14>MAY</bcp14> allow applications to explicitly specify which versions of a protocol ought to be permitted, e.g., to allow a minimum version of TLS 1.2 in case if TLS 1.3 is not available.</t>
        <t>A Transport Services Implementation MAY <bcp14>MAY</bcp14> specify security properties relating to how the system operates (e.g., requirements, prohibitions, and preferences for the use of DNS Security Extensions (DNSSEC) or DNS over HTTPS (DoH)).</t>
      </section>
      <section anchor="maintain-interoperability">
        <name>Maintain Interoperability</name>
        <t>It is important to note that neither the Transport Services API <xref target="I-D.ietf-taps-interface"/> target="RFC9622"/> nor the guidelines for implementation of the Transport Service Services System <xref target="I-D.ietf-taps-impl"/> target="RFC9623"/> define new protocols or protocol capabilities that affect what is communicated across the network. A Transport Services System MUST NOT <bcp14>MUST NOT</bcp14> require that a peer on the other side of a connection uses use the same API or implementation. A Transport Services Implementation acting as a connection initiator is able to communicate with any existing Endpoint that implements the transport protocol(s) and all the required properties selected. Similarly, a Transport Services Implementation acting as a Listener can receive connections for any protocol that is supported from an existing initiator that implements the protocol, independent independently of whether or not the initiator uses the Transport Services System or not.</t> System.</t>
        <t>A Transport Services Implemenation Implementation makes decisions that select protocols and interfaces. In normal use, a given version of a Transport Services System SHOULD <bcp14>SHOULD</bcp14> result in consistent protocol and interface selection decisions for the same network conditions conditions, given the same set of Properties. This is intended to provide predictable outcomes to the application using the API.</t>
      </section>
      <section anchor="support-monitoring">
        <name>Support Monitoring</name>
        <t>The Transport Services API increases the layer of abstraction for applications, and it enables greater automation below the API. Such increased
abstraction comes at the cost of increased complexity when application programmers, users users, or system administrators
try to understand why any issues and failures may be happening. Transport Services systems should therefore offer monitoring functions that
provide relevant debug and diagnostics information. For example, such monitoring functions could indicate the protocol(s) in use, the
number of open connections per protocol, and any statistics that these protocols may offer.</t>
      </section>
    </section>
    <section anchor="concepts">
      <name>Transport Services Architecture and Concepts</name>
      <t>This section of the document describes the architecture non-normatively and explains the operation of a Transport Services Implementation. The concepts defined in this document are intended primarily for use in the documents and specifications that describe the Transport Services System. This includes the architecture, the Transport Services API API, and the associated Transport Services Implementation. While the specific terminology can be used in some implementations, it is expected that there will remain a variety of terms used by running code.</t>
      <t>The architecture divides the concepts for the Transport Services System into two categories:</t>
      <ol spacing="normal" type="1"><li>
          <t>API concepts, which are intended to be exposed to applications; and</t>
        </li>
        <li>
          <t>System-implementation concepts, which are intended to be internally used by a Transport Services Implementation.</t>
        </li>
      </ol>
      <t>The following diagram summarizes the top-level concepts in a Transport Services System and how they relate to one another.</t>
      <figure anchor="fig-abstractions">
        <name>Concepts and Relationships in the Architecture of the Transport Services System</name>
        <artwork><![CDATA[
  +-----------------------------------------------------+
  |                    Application                      |
  +-+----------------+------^-------+--------^----------+
    |                |      |       |        |
  pre-               |     data     |      events
  establishment      |   transfer   |        |
    |        establishment  |   termination  |
    |                |      |       |        |
    |             +--v------v-------v+       |
  +-v-------------+   Connection(s)  +-------+----------+
  |  Transport    +--------+---------+                  |
  |  Services              |                            |
  |  API                   |  +-------------+           |
  +------------------------+--+  Framer(s)  |-----------+
                           |  +-------------+
  +------------------------|----------------------------+
  |  Transport             |                            |
  |  System                |        +-----------------+ |
  |  Implementation        |        |     Cached      | |
  |                        |        |      State      | |
  |  (Candidate Gathering) |        +-----------------+ |
  |                        |                            |
  |  (Candidate Racing)    |        +-----------------+ |
  |                        |        |     System      | |
  |                        |        |     Policy      | |
  |             +----------v-----+  +-----------------+ |
  |             |    Protocol    |                      |
  +-------------+    Stack(s)    +----------------------+
                +-------+--------+
                        V
+-----------------------------------------------------+
|               Network Layer               Network-Layer Interface               |
+-----------------------------------------------------+
]]></artwork>
      </figure>

      <t>The Transport Services Implementation includes the Cached State and System Policy.</t>
      <t>The System Policy provides input from an operating system or other global preferences that can constrain or influence how an implementation will gather Candidate Paths and Protocol Stacks and race the candidates when establishing a Connection. As the details of System Policy configuration and enforcement are largely platform- dependent on the platform and implementation- dependent, implementation and do not affect application-level interoperability, the Transport Services API <xref target="I-D.ietf-taps-interface"/> target="RFC9622"/> does not specify an interface for reading or writing System Policy.</t>
      <t>The Cached State is the state and history that the Transport Services Implementation keeps for each set of associated Endpoints that have previously been used. An application ought to explicitly request any required or desired properties via the Transport Services API.</t>
      <section anchor="transport-services-api-concepts">
        <name>Transport Services API Concepts</name>
        <t>Fundamentally, a Transport Services API needs to provide Connection objects (<xref target="objects"/>) that allow applications to establish communication, communication and then send and receive data. These could be exposed as handles or referenced objects, depending on the chosen programming language.</t>
        <t>Beyond the Connection objects, there are several high-level groups of actions that any Transport Services API needs to provide:</t>
        <ul spacing="normal">
          <li>
            <t>Pre-establishment
            <t>Preestablishment (<xref target="preestablishment"/>) encompasses the properties that an application can pass to describe its intent, requirements, prohibitions, and preferences for its networking operations. These properties apply to multiple transport protocols, unless otherwise specified. Properties specified during pre-establishment preestablishment can have a large impact on the rest of the interface: they modify how establishment occurs, they influence the expectations around data transfer, and they determine the set of events that will be supported.</t>
          </li>
          <li>
            <t>Establishment (<xref target="establishment"/>) focuses on the actions that an application takes on the Connection objects to prepare for data transfer.</t>
          </li>
          <li>
            <t>Data Transfer transfer (<xref target="datatransfer"/>) consists of how an application represents the data to be sent and received, the functions required to send and receive that data, and how the application is notified of the status of its data transfer.</t>
          </li>
          <li>
            <t>Event Handling handling (<xref target="events"/>) defines categories of notifications that an application can receive during the lifetime of a Connection. Events also provide opportunities for the application to interact with the underlying transport by querying state or updating maintenance options.</t>
          </li>
          <li>
            <t>Termination (<xref target="termination"/>) focuses on the methods by which data transmission is stopped, stopped and connection state is torn down.</t>
          </li>
        </ul>
        <t>The diagram below provides a high-level view of the actions and events during the lifetime of a Connection object. Note that some actions are alternatives (e.g., whether to initiate a connection or to listen for incoming connections), while others are optional (e.g., setting Connection and Message Properties in pre-establishment) preestablishment) or have been omitted for brevity and simplicity.</t>
        <figure anchor="fig-lifetime">
          <name>The lifetime Lifetime of a Connection object</name> Object</name>
          <artwork><![CDATA[
     Pre-establishment

     Preestablishment     :       Established             : Termination
    -----------------     :       -----------             : -----------
                          :                               :
+-- Local Endpoint        :           Message             :
+-- Remote Endpoint       :    Receive() |                :
+-- Transport Properties  :       Send() |                :
+-- Security Parameters   :              |                :
|                         :              |                :
|               InitiateWithSend()       |        Close() :
|   +---------------+   Initiate() +-----+------+ Abort() :
+---+ Preconnection |------------->| Connection |-----------> Closed
    +---------------+ Rendezvous() +------------+         :
   Listen() |             :           |     |             :
            |             :           |     v             :
            v             :           | Connection        :
    +----------+          :           |   Ready           :
    | Listener |----------------------+                   :
    +----------+  Connection Received                     :
                          :                               :
]]></artwork>
        </figure>
        <t>In this diagram, the lifetime of a Connection object is divided into three phases:
pre-establishment,
preestablishment, the Established state, and Termination.</t>
        <t>Pre-establishment termination of a connection.</t>
        <t>Preestablishment is based around a Preconnection object, that contains object containing various
sub-objects that describe the properties and parameters of desired Connections
(Local and Remote Endpoints, Transport Properties, and Security Parameters).
A Preconnection can be used to start listening for inbound connections, connections --
in which case a Listener object is created, created -- or can be used to establish a new
connection directly using <tt>Initiate</tt> (for outbound connections) or <tt>Rendezvous</tt>
(for peer-to-peer connections).</t>

<!-- [rfced] Please review usage of <tt> in this document, and let us
know if any updates are needed.  For example, we see
"to initiate a connection" (no <tt>) and "to Initiate a Connection"
in the XML file. -->

        <t>Once a Connection is in the Established state, an application can send and receive
Message objects, objects and can receive state updates.</t>
        <t>Closing or aborting a connection, either locally or from the peer, can terminate
a connection.</t>
        <section anchor="endpoint-objects">
          <name>Endpoint Objects</name>
          <t>An Endpoint Identifier specifies one side of a transport connection.
  Endpoints can be Local Endpoints or Remote Endpoints, and the Endpoint Identifiers can respectively represent an identity
  that the application uses for the source or destination of a connection.
  An Endpoint Identifier can be specified at various levels of abstraction.
  An Endpoint Identifier at a higher level of abstraction (such as a hostname) can be resolved to more concrete identities
  (such as IP addresses). A Remote Endpoint Identifier can also represent a multicast group or anycast address.
  In the case of multicast, this selects a multicast transport will be selected for communication.</t>
          <ul
          <dl spacing="normal">
            <li>
              <t>Remote

              <dt>Remote Endpoint Identifier: The Identifier:</dt><dd>The Remote Endpoint Identifier represents the application's identifier for a peer that can participate in a transport connection; connection, for example, the combination of a DNS name for the peer and a service name/port.</t>
            </li>
            <li>
              <t>Local name/port.</dd>

              <dt>Local Endpoint Identifier: The Identifier:</dt><dd>The Local Endpoint Identifier represents the application's identifier for itself that it uses for transport connections; connections, for example, a local IP address and port.</t>
            </li>
          </ul> port.</dd>
            </dl>

        </section>
        <section anchor="objects">
          <name>Connections and Related Objects</name>
          <ul
          <dl spacing="normal">
            <li>
              <t>Connection: A

              <dt>Connection:</dt><dd>A Connection object represents one or more active transport protocol instances that can send and/or receive Messages between Local and Remote Endpoints. It is an abstraction that represents the communication. The Connection object holds state pertaining to the underlying transport protocol instances and any ongoing data transfers. For example, an active Connection can represent a connection-oriented protocol such as TCP, or it can represent a fully-specified fully specified 5-tuple for a connectionless protocol such as UDP, where the Connection remains an abstraction at the endpoints. It can also represent a pool of transport protocol instances, e.g., a set of TCP and QUIC connections to equivalent endpoints, or a stream of a multi-streaming transport protocol instance. Connections can be created from a Preconnection or by a Listener.</t>
            </li>
            <li>
              <t>Preconnection: A Listener.</dd>

              <dt>Preconnection:</dt><dd>A Preconnection object is a representation of a Connection that has not yet been established. It has state that describes parameters of the Connection: the Local Endpoint Identifier from which that Connection will be established, the Remote Endpoint Identifier (<xref target="preestablishment"/>) to which it will connect, and Transport Properties that influence the paths and protocols a Connection will use. A Preconnection can be either fully specified (representing a single possible Connection), Connection) or it can be partially specified (representing a family of possible Connections). The Local Endpoint (<xref target="preestablishment"/>) is required for a Preconnection used to <tt>Listen</tt> for incoming Connections, Connections but is optional if it is used to <tt>Initiate</tt> a Connection. The Remote Endpoint Identifier is required in a Preconnection that is used to <tt>Initiate</tt> a Connection, Connection but is optional if it is used to <tt>Listen</tt> for incoming Connections. The Local Endpoint Identifier and the Remote Endpoint Identifier are both required if a peer-to-peer <tt>Rendezvous</tt> is to occur based on the Preconnection.</t>
            </li>
            <li>
              <t>Transport Properties: Transport Preconnection.</dd>

              <dt>Transport Properties:</dt><dd><t>Transport Properties allow the application to express their requirements, prohibitions, and preferences and configure a Transport Services Implementation.  There are three kinds of Transport Properties: </t>
              <ul
              <dl spacing="normal">
                <li>
                  <t>Selection

                  <dt>Selection Properties (<xref target="preestablishment"/>): Selection target="preestablishment"/>):</dt><dd>Selection Properties can only be specified on a Preconnection.</t>
                </li>
                <li>
                  <t>Connection Preconnection.</dd>

                  <dt>Connection Properties (<xref target="preestablishment"/>): Connection target="preestablishment"/>):</dt><dd>Connection Properties can be specified on a Preconnection and changed on the Connection.</t>
                </li>
                <li>
                  <t>Message Connection.</dd>

                  <dt>Message Properties (<xref target="datatransfer"/>): Message target="datatransfer"/>):</dt><dd>Message Properties can be specified as defaults on a Preconnection or a Connection, Connection and can also be specified during data transfer to affect specific Messages.</t>
                </li>
              </ul>
            </li>
            <li>
              <t>Listener: A Messages.</dd>
		</dl>
	      </dd>

              <dt>Listener:</dt><dd>A Listener object accepts incoming transport protocol connections from Remote Endpoints and generates corresponding Connection objects. It is created from a Preconnection object that specifies the type of incoming Connections it will accept.</t>
            </li>
          </ul> accept.</dd>
           </dl>

        </section>
        <section anchor="preestablishment">
          <name>Pre-establishment</name>
          <ul
          <name>Preestablishment</name>
          <dl spacing="normal">
            <li>
              <t>Selection Properties: The Selection

              <dt>Selection Properties:</dt><dd>Selection Properties consist of the properties that an application can set to influence the selection of paths between the Local and Remote Endpoints, to influence the selection of transport protocols, or to configure the behavior of generic transport protocol features. These properties can take the form of requirements, prohibitions, or preferences. Examples of properties that influence path selection include the interface type (such as a Wi-Fi connection, connection or a Cellular LTE connection), requirements around the largest Message that can be sent, or preferences for throughput and latency. Examples of properties that influence protocol selection and configuration of transport protocol features include reliability, multipath support, and fast open support.</t>
            </li>
            <li>
              <t>Connection Properties: The Connection support for TCP Fast Open.</dd>

              <dt>Connection Properties:</dt><dd>Connection Properties are used to configure protocol-specific options and control per-connection behavior of a Transport Services Implementation; for example, a protocol-specific Connection Property can express that if TCP is used, the implementation ought to use the User Timeout Option. Note that the presence of such a property does not require that a specific protocol will be used. In general, these properties do not explicitly determine the selection of paths or protocols, protocols but can be used by an implementation during connection establishment. Connection Properties are specified on a Preconnection prior to Connection establishment, establishment and can be modified on the Connection later. Changes made to Connection Properties after Connection establishment take effect on a best-effort basis.</t>
            </li>
            <li>
              <t>Security Parameters: Security basis.</dd>

              <dt>Security Parameters:</dt><dd>Security Parameters define an application's requirements for authentication and encryption on a Connection. They are used by Transport Security transport security protocols (such as those described in <xref target="RFC8922"/>) to establish secure Connections. Examples of parameters that can be set include local identities, private keys, supported cryptographic algorithms, and requirements for validating trust of remote identities. Security Parameters are primarily associated with a Preconnection object, but properties related to identities can be associated directly with Endpoints.</t>
            </li>
          </ul> Endpoints.</dd>
            </dl>

        </section>
        <section anchor="establishment">
          <name>Establishment Actions</name>
          <ul
          <dl spacing="normal">
            <li>
              <t>Initiate: The

              <dt>Initiate:</dt><dd>The primary action that an application can take to create a Connection to a Remote Endpoint, Endpoint and prepare any required local or remote state to enable the transmission of Messages. For some protocols, this will initiate a client-to-server style client-to-server-style handshake; for other protocols, this will just establish local state (e.g., with connectionless protocols such as UDP). The process of identifying options for connecting, such as resolution of the Remote Endpoint Identifier, occurs in response to the <tt>Initiate</tt> call.</t>
            </li>
            <li>
              <t>Listen: Enables call.</dd>

              <dt>Listen:</dt><dd>Enables a Listener to accept incoming connections. The Listener will then create Connection objects as incoming connections are accepted (<xref target="events"/>). Listeners by default register with multiple paths, protocols, and Local Endpoints, unless constrained by Selection Properties and/or the specified Local Endpoint Identifier(s). Connections can be accepted on any of the available paths or endpoints.</t>
            </li>
            <li>
              <t>Rendezvous: The endpoints.</dd>

              <dt>Rendezvous:</dt><dd>The action of establishing a peer-to-peer connection with a Remote Endpoint. It simultaneously attempts to initiate a connection to
a Remote Endpoint while listening for an incoming connection from that
Endpoint.  The process of identifying options for the connection, such
as resolution of the Remote Endpoint Identifier(s), occurs in response to the <tt>Rendezvous</tt> call.
As with Listeners, the set of local paths and endpoints is constrained
by Selection Properties. If successful, the <tt>Rendezvous</tt> call generates and asynchronously returns a
Connection object to represent the established peer-to-peer connection.
The processes by which connections are initiated during a <tt>Rendezvous</tt>
action will depend on the set of Local and Remote Endpoints configured on
the Preconnection. For example, if the Local and Remote Endpoints are TCP
host candidates, then a TCP simultaneous open <xref target="RFC9293"/> might be performed.
However, if the set of Local Endpoints includes server reflexive server-reflexive
candidates, such as those provided by STUN (Session Traversal Utilities
for NAT) <xref target="RFC5389"/>, target="RFC8489"/>, a <tt>Rendezvous</tt> action will race
candidates in the style of the ICE (Interactive Connection Connectivity Establishment)
algorithm <xref target="RFC8445"/> to perform NAT
binding discovery and initiate a peer-to-peer connection.</t>
            </li>
          </ul> connection.</dd>
          </dl>

        </section>
        <section anchor="datatransfer">
          <name>Data Transfer Objects and Actions</name>
          <ul
          <dl spacing="normal">
            <li>
              <t>Message: A

              <dt>Message:</dt><dd>A Message object is a unit of data that can be represented as bytes that can be transferred between two endpoints over a transport connection. The bytes within a Message are assumed to be ordered. If an application does not care about the order in which a peer receives two distinct spans of bytes, those spans of bytes are considered independent Messages. Messages are sent in the payload of IP packets. One packet can carry one or more Messages or parts of a Message.</t>
            </li>
            <li>
              <t>Message Properties: Message Message.</dd>

              <dt>Message Properties:</dt><dd>Message Properties are used to specify details about Message transmission. They can be specified directly on individual Messages, Messages or can be set on a Preconnection or Connection as defaults. These properties might only apply to how a Message is sent (such as how the transport will treat prioritization and reliability), reliability) but can also include properties that specific protocols encode and communicate to the Remote Endpoint. When receiving Messages, Message Properties can contain information about the received Message, such as metadata generated at the receiver and information signalled signaled by the Remote Endpoint. For example, a Message can be marked with a Message Property indicating that it is the final Message on a Connection.</t>
            </li>
            <li>
              <t>Send: The Connection.</dd>

              <dt>Send:</dt><dd>The Send action to transmit transmits a Message over a Connection to the Remote Endpoint. The interface to <tt>Send</tt> can accept Message Properties specific to how the Message content is to be sent. The status of the <tt>Send</tt> operation is delivered back to the sending application in an event (<xref target="events"/>).</t>
            </li>
            <li>
              <t>Receive: An target="events"/>).</dd>

              <dt>Receive:</dt><dd>The Receive action that indicates that the application is ready to asynchronously accept a Message over a Connection from a Remote Endpoint, while the Message content itself will be delivered in an event (<xref target="events"/>). The interface to <tt>Receive</tt> can include Message Properties specific to the Message that is to be delivered to the application.</t>
            </li>
            <li>
              <t>Framer: A application.</dd>

              <dt>Framer:</dt><dd>A Framer is a data translation layer that can be added to a Connection. 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. In this way, message boundaries can be preserved when using a Connection object, even with a protocol that otherwise presents unstructured streams, such as TCP. This is designed based on the fact that many of the current application protocols evolved over TCP, which does not provide message boundary preservation, and since many of these protocols require message boundaries to function, each application layer application-layer protocol has defined its own framing. For example, when an HTTP application sends and receives HTTP messages over a byte-stream transport, it must parse the boundaries of HTTP messages from the stream of bytes.</t>
            </li>
          </ul> bytes.</dd>
          </dl>

        </section>
        <section anchor="events">
          <name>Event Handling</name>
          <t>The following categories of events can be delivered to an application:</t>
          <ul
          <dl spacing="normal">
            <li>
              <t>Connection Ready: Signals

              <dt>Connection Ready:</dt><dd>Signals to an application that a given Connection is ready to send and/or receive Messages. If the Connection relies on handshakes to establish state between peers, then it is assumed that these steps have been taken.</t>
            </li>
            <li>
              <t>Connection Closed: Signals taken.</dd>

              <dt>Connection Closed:</dt><dd>Signals to an application that a given Connection is no longer usable for sending or receiving Messages. The event delivers a reason or error to the application that describes the nature of the termination.</t>
            </li>
            <li>
              <t>Connection Received: Signals termination.</dd>

              <dt>Connection Received:</dt><dd>Signals to an application that a given Listener has received a Connection.</t>
            </li>
            <li>
              <t>Message Received: Delivers Connection.</dd>

              <dt>Message Received:</dt><dd>Delivers received Message content to the application, based on a <tt>Receive</tt> action. To allow an application to limit the occurrence of such events, each call to <tt>Receive</tt> will be paired with a single <tt>Receive</tt> event. This can include an error if the <tt>Receive</tt> action cannot be satisfied, e.g., due to the Connection being closed.</t>
            </li>
            <li>
              <t>Message Sent: Notifies closed.</dd>

              <dt>Message Sent:</dt><dd>Notifies the application of the status of its <tt>Send</tt> action. This might indicate a failure if the Message cannot be sent, sent or an indication might indicate that the Message has been processed by the Transport Services System.</t>
            </li>
            <li>
              <t>Path System.</dd>

              <dt>Path Properties Changed: Notifies Changed:</dt><dd>Notifies the application that a property of the Connection has changed that might influence how and where data is sent and/or received.</t>
            </li>
          </ul> received.</dd>
            </dl>

        </section>
        <section anchor="termination">
          <name>Termination Actions</name>
          <ul
          <dl spacing="normal">
            <li>
              <t>Close: The

              <dt>Close:</dt><dd>The action an application takes on a Connection to indicate that it no longer intends to send data, data or is no longer willing to receive data, and that the data.  The protocol should signal this state to the Remote Endpoint if the transport protocol allows this. permits it. (Note that this is distinct from the concept of "half-closing" a bidirectional connection, such as when a FIN is sent in one direction of a TCP connection <xref target="RFC9293"/>. The end of a stream can also be indicated using Message Properties when sending.)</t>
            </li>
            <li>
              <t>Abort: sending.)</dd>

              <dt>Abort:</dt><dd> The action the application takes on a Connection
  to indicate a <tt>Close</tt> and also indicate that the Transport Services System
  should not attempt to deliver any outstanding data, data and that it should
  immediately close and drop the connection.  This is intended for immediate, usually abnormal, termination of a connection.</t>
            </li>
          </ul> connection.</dd>
            </dl>

        </section>
        <section anchor="connection-groups">
          <name>Connection Groups</name>
          <t>A Connection Group is a set of Connections that shares Connection Properties and cached state generated by protocols.
A Connection Group represents state for managing Connections within a single application, application and does not require end-to-end protocol signaling. For transport protocols that support multiplexing, only Connections within the same Connection Group are allowed to be multiplexed together.</t>
          <t>The API allows a Connection to be created from another Connection. This adds the new Connection to the Connection Group. A change to one of the Connection Properties on any Connection in the Connection Group automatically changes the Connection Property for all others. All Connections in a Connection Group share the same set of Connection Properties except for the Connection Priority. These Connection Properties are said to be entangled.</t>
          <t>Passive Connections can also be added to a Connection Group, e.g., when a Listener receives a new Connection that is just a new stream of an already active already-active multi-streaming protocol
instance.</t>
          <t>While Connection Groups are managed by the Transport Services Implementation, an application can define different Connection Contexts for different Connection Groups to explicitly control caching boundaries, as discussed in <xref target="conn-context"/>.</t>
        </section>
      </section>
      <section anchor="transport-services-implementation">
        <name>Transport Services Implementation</name>
        <t>This section defines the key architectural concepts for the Transport Services Implementation within the Transport Services System.</t>
        <t>The Transport Services System consists of the Transport Services Implementation and the Transport Services API.
The Transport Services Implementation consists of all objects and protocol instances used internally to a system or library to implement the functionality needed to provide a transport service across a network, as required by the abstract interface.</t>
        <ul
        <dl spacing="normal">
          <li>
            <t>Path: Represents

            <dt>Path:</dt><dd>Represents an available set of properties that a Local Endpoint can use to communicate with a Remote Endpoint, such as routes, addresses, and physical and virtual network interfaces.</t>
          </li>
          <li>
            <t>Protocol Instance: A interfaces.</dd>

            <dt>Protocol Instance:</dt><dd>A single instance of one protocol, including any state necessary to establish connectivity or send and receive Messages.</t>
          </li>
          <li>
            <t>Protocol Stack: A Messages.</dd>

            <dt>Protocol Stack:</dt><dd>A set of Protocol Instances (including relevant application, security, transport, or Internet protocols) that are used together to establish connectivity or send and receive Messages. A single stack can be simple (a single transport protocol instance (e.g., one application stream carried TCP running over IP), IP) or it can be complex (multiple (e.g,. multiple application protocol streams going through a single security and transport protocol, carried over IP; or, a multi-path multipath transport protocol over using multiple transport sub-flows).</t>
          </li>
          <li>
            <t>Candidate Path: One subflows over IP).</dd>

            <dt>Candidate Path:</dt><dd>One path that is available to an application and conforms to the Selection Properties and System Policy, of which there can be several. Candidate Paths are identified during the gathering phase (<xref target="gathering"/>) and can be used during the racing phase (<xref target="racing"/>).</t>
          </li>
          <li>
            <t>Candidate target="racing"/>).</dd>

            <dt>Candidate Protocol Stack: One Stack:</dt><dd>One Protocol Stack that can be used by an application for a Connection, for which there can be several candidates. Candidate Protocol Stacks are identified during the gathering phase (<xref target="gathering"/>) and are started during the racing phase (<xref target="racing"/>).</t>
          </li>
          <li>
            <t>System Policy: The target="racing"/>).</dd>

            <dt>System Policy:</dt><dd>The input from an operating system or other global preferences that can constrain or influence how an implementation will gather candidate paths and Protocol Stacks (<xref target="gathering"/>) and race the candidates during establishment (<xref target="racing"/>). Specific aspects of the System Policy either apply to either all Connections or only certain ones, Connections, depending on the runtime context and properties of the Connection.</t>
          </li>
          <li>
            <t>Cached State: The Connection.</dd>

            <dt>Cached State:</dt><dd>The state and history that the implementation keeps for each set of associated Endpoints that have been used previously. This can include DNS results, TLS session state, previous success and quality of transport protocols over certain paths, as well as other information.  This caching does not imply that the same decisions are necessarily made for subsequent connections, connections; rather, it means that cached state is used by a Transport Services Implementation to inform functions such as choosing the candidates to be raced, selecting appropriate transport parameters, etc. An application SHOULD NOT <bcp14>SHOULD NOT</bcp14> rely on specific caching behaviour, instead behavior; instead, it ought to explicitly request any required or desired properties via the Transport Services API.</t>
          </li>
        </ul> API.

</dd>
        </dl>
        <section anchor="gathering">
          <name>Candidate Gathering</name>
          <ul
          <dl spacing="normal">
            <li>
              <t>Candidate

              <dt>Candidate Path Selection: Candidate Selection:</dt><dd>Candidate Path Selection represents the act of choosing one or more paths that are available to use based on the Selection Properties and any available Local and Remote Endpoint Identifiers provided by the application, as well as the policies and heuristics of a Transport Services implementation.</t>
            </li>
            <li>
              <t>Candidate Implementation.</dd>

              <dt>Candidate Protocol Selection: Candidate Selection:</dt><dd>Candidate Protocol Selection represents the act of choosing one or more sets of Protocol Stacks that are available to use based on the Transport Properties provided by the application, and the heuristics or policies within the Transport Services Implementation.</t>
            </li>
          </ul> Implementation.</dd>
            </dl>

        </section>
        <section anchor="racing">
          <name>Candidate Racing</name>
          <t>Connection establishment attempts for a set of candidates may be performed simultaneously, synchronously, serially, or using some combination of all of these. We refer to this process as racing, borrowing terminology from Happy Eyeballs <xref target="RFC8305"/>.</t>
          <ul
          <dl spacing="normal">
            <li>
              <t>Protocol

              <dt>Protocol Option Racing: Protocol Racing:</dt><dd>Protocol Option Racing is the act of attempting to establish, or scheduling attempts to establish, multiple Protocol Stacks that differ based on the composition of protocols or the options used for protocols.</t>
            </li>
            <li>
              <t>Path Racing: Path protocols.</dd>

              <dt>Path Racing:</dt><dd>Path Racing is the act of attempting to establish, or scheduling attempts to establish, multiple Protocol Stacks that differ based on a selection from the available Paths. Since different Paths will have distinct configurations (see <xref target="RFC7556"/>)
for local addresses and DNS servers, attempts across different Paths will perform separate DNS resolution steps, which can lead to further racing of the resolved Remote Endpoint Identifiers.</t>
            </li>
            <li>
              <t>Remote Identifiers.</dd>

              <dt>Remote Endpoint Racing: Remote Racing:</dt><dd>Remote Endpoint Racing is the act of attempting to establish, or scheduling attempts to establish, multiple Protocol Stacks that differ based on the specific representation of the Remote Endpoint Identifier, such as a particular IP address that was resolved from a DNS hostname.</t>
            </li>
          </ul> hostname.</dd>
          </dl>
        </section>
        <section anchor="conn-context">
          <name>Separating Connection Contexts</name>
          <t>A Transport Services Implementation can by default share stored properties across Connections within an application, such as cached protocol state, cached path state, and heuristics. This provides efficiency and convenience for the application, since the Transport Services System can automatically optimize behavior.</t>
          <t>The Transport Services API can allow applications to explicitly define Connection Contexts that force separation of Cached State and Protocol Stacks.
For example, a web browser application could use Connection Contexts with separate caches when implementing different tabs. Possible reasons to isolate Connections using separate Connection Contexts include:</t> include privacy concerns regarding:</t>
          <ul spacing="normal">
            <li>
              <t>Privacy concerns about re-using
              <t>reusing cached protocol state that state, as this can lead to linkability. Sensitive state could include TLS session state <xref target="RFC8446"/> and HTTP cookies <xref target="RFC6265"/>. These concerns could be addressed using Connection Contexts with separate caches, such as for different browser tabs.</t>
            </li>
            <li>
              <t>Privacy concerns about allowing
              <t>allowing Connections to multiplex together, which can tell a Remote Endpoint that all of the Connections are coming from the same application. Using Connection Contexts avoids the Connections being multiplexed in a an HTTP/2 or QUIC stream.</t>
            </li>
          </ul>
        </section>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no actions for IANA.</t> IANA actions.</t>
    </section>
    <section anchor="security-and-privacy-considerations">
      <name>Security and Privacy Considerations</name>
      <t>The Transport Services System does not recommend the use of specific security
protocols or algorithms. Its goal is to offer ease of use for existing protocols
by providing a generic security-related interface. Each provided interface
translates to an existing protocol-specific interface provided by supported
security protocols. For example, trust verification callbacks are common parts
of TLS APIs; a Transport Services API exposes similar functionality
<xref target="RFC8922"/>.</t>
      <t>As described above in <xref target="equivalence"/>, if a Transport Services Implementation races
between two different Protocol Stacks, both need to use the same security protocols
and options. However, a Transport Services Implementation can race different security
protocols, e.g., if the application explicitly specifies that it considers them
equivalent.</t>
      <t>The application controls whether
information from previous racing attempts, attempts or other information
about past communications that was cached by
the Transport Services System is used during establishment.
This allows applications to make
tradeoffs
trade-offs between efficiency (through racing) and privacy (via information that
might leak from the cache toward an on-path observer). Some applications have
features (e.g. (e.g., "incognito mode") that align with this functionality.</t>
      <t>Applications need to ensure that they use security APIs appropriately. In cases
where applications use an interface to provide sensitive keying material, e.g.,
access to private keys or copies of pre-shared keys (PSKs), key use needs to be
validated and scoped to the intended protocols and roles. For example, if an
application provides a certificate to only be used as client authentication for
outbound TLS and QUIC connections, the Transport Services System MUST NOT <bcp14>MUST NOT</bcp14> use this
automatically in other contexts (such as server authentication for inbound
connections,
connections or in other another security protocol handshake handshakes that is are not equivalent to TLS).</t> TLS).

</t>
      <t>A Transport Services System MUST NOT <bcp14>MUST NOT</bcp14> automatically fall back from
secure protocols to insecure protocols, protocols or fall back to weaker versions of secure
protocols (see <xref target="equivalence"/>). For example, if an application requests a specific version of TLS, TLS
but the desired version of TLS is not available, its connection will fail.
As described in <xref target="equivalence"/>, the Transport Services API can allow applications
to specify minimum versions that are allowed to be used by the Transport Services System.</t>
    </section>
    <section anchor="acknowledgements">
      <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), No. 688421
(MAMI) and No 815178 (5GENESIS).</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>Thanks to Reese Enghardt, Max Franke, Mirja Kuehlewind, Jonathan Lennox, and
Michael Welzl for the discussions and feedback that helped shape the architecture
of the system described here.
Particular thanks is also due to Philipp S. Tiesel and Christopher A. Wood,
who were both co-authors of this specification as it progressed
through the TAPS working group.
Thanks as well to Stuart Cheshire, Josh Graessley, David Schinazi,
and Eric Kinnear for their implementation and design efforts, including Happy
Eyeballs, that heavily influenced this work.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs
	<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"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>

<!-- [rfced] The 2008 version of [POSIX] is marked "Superseded".
There is a 2017 revision (https://ieeexplore.ieee.org/document/8277153)
and a 2024 revision (https://ieeexplore.ieee.org/document/10555529).
Please let us know if you would like 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 update this reference to signify the requirements in the specification. These words are often capitalized. This document defines one
of these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices revisions; if yes, please let us know which revision is
appropriate for the Internet Community, and requests discussion and suggestions this document.

Original (double dash changed to single in order to avoid xml2rfc's
  "Double hyphen within comment" error):
 [POSIX]    "IEEE Std. 1003.1-2008 Standard for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference> Information Technology
            - Portable Operating System Interface (POSIX).  Open
            group Technical Standard: Base Specifications, Issue 7",
            2008. -->

        <reference anchor="RFC8174"> anchor="POSIX" target="https://ieeexplore.ieee.org/document/4694976">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <title>IEEE Standard for Information Technology -- Portable Operating System Interface (POSIX(R))</title>
            <author>
              <organization/>
            </author>
            <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> year="2008"/>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/> name="IEEE Std" value="1003.1-2008"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/> value="10.1109/IEEESTD.2008.4694976"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>

<!-- Note to PE: XML for 2017 and 2024 versions of [POSIX]:
        <reference anchor="POSIX"> anchor="POSIX" target="https://ieeexplore.ieee.org/document/8277153">
          <front>
            <title>IEEE Std. 1003.1-2008 Standard for Information Technology -- - Portable Operating System Interface (POSIX).  Open group Technical Standard: (POSIX(TM)) Base Specifications, Issue 7</title>
            <author>
              <organization/>
            </author>
            <date year="2008"/> year="2018"/>
          </front>
          <seriesInfo name="IEEE Std" value="1003.1-2017"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8277153"/>
        </reference>

        <reference anchor="RFC8446"> anchor="POSIX" target="https://ieeexplore.ieee.org/document/10555529">
          <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
            <title>IEEE/Open Group Standard for TLS 1.2 implementations.</t>
            </abstract> Information Technology - Portable Operating System Interface (POSIX(TM)) Base Specifications, Issue 8</title>
            <author>
              <organization/>
            </author>
            <date year="2024"/>
          </front>
          <seriesInfo name="RFC" value="8446"/> name="IEEE Std" value="1003.1-2024"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/> value="10.1109/IEEESTD.2024.10555529"/>
        </reference> -->

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

<!-- draft-ietf-taps-interface (RFC 9622) -->
<reference anchor="I-D.ietf-taps-interface"> anchor="RFC9622" target="https://www.rfc-editor.org/info/rfc9622">
<front>
<title>An Abstract Application Layer Application-Layer Interface to Transport Services</title>
<author initials="B." surname="Trammell" fullname="Brian Trammell" initials="B." surname="Trammell"> role="editor">
<organization>Google Switzerland GmbH</organization>
</author>
<author initials="M." surname="Welzl" fullname="Michael Welzl" initials="M." surname="Welzl"> role="editor">
<organization>University of Oslo</organization>
</author>
<author fullname="Reese Enghardt" initials="R." surname="Enghardt"> surname="Enghardt" fullname="Reese Enghardt">
<organization>Netflix</organization>
</author>
<author fullname="Gorry Fairhurst" initials="G." surname="Fairhurst"> surname="Fairhurst" fullname="Gorry Fairhurst">
<organization>University of Aberdeen</organization>
</author>
<author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind"> surname="Kühlewind" fullname="Mirja Kühlewind">
<organization>Ericsson</organization>
</author>
<author initials="C. S." surname="Perkins" fullname="Colin Perkins" initials="C." surname="Perkins"> Perkins">
<organization>University of Glasgow</organization>
</author>
<author initials="P." surname="Tiesel" fullname="Philipp S. Tiesel" initials="P. S." surname="Tiesel"> Tiesel">
<organization>SAP SE</organization>
</author>
<author fullname="Tommy Pauly" initials="T." surname="Pauly"> surname="Pauly" fullname="Tommy Pauly">
<organization>Apple Inc.</organization>
</author>
<date day="6" month="July" year="2023"/>
            <abstract>
              <t>   This document describes an abstract application programming
   interface, API, to the transport layer that enables the selection of
   transport protocols and network paths dynamically at runtime.  This
   API enables faster deployment of new protocols and protocol features
   without requiring changes to the applications.  The specified API
   follows the Transport Services architecture by providing
   asynchronous, atomic transmission of messages.  It is intended to
   replace the BSD sockets API as the common interface to the transport
   layer, in an environment where endpoints could select from multiple
   interfaces and potential transport protocols.

              </t>
            </abstract> month="November" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-taps-interface-22"/> name="RFC" value="9622"/>
<seriesInfo name="DOI" value="10.17487/RFC9622"/>
</reference>

<!-- 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 fullname="Anna Brunstrom" initials="A." surname="Brunstrom"> surname="Brunstrom" role="editor">
              <organization>Karlstad University</organization>
            </author>
            <author fullname="Tommy Pauly" initials="T." surname="Pauly"> surname="Pauly" role="editor">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="Reese Enghardt" initials="R." surname="Enghardt">
              <organization>Netflix</organization>
            </author>
            <author fullname="Philipp S. Tiesel" initials="P. S." initials="P." surname="Tiesel">
              <organization>SAP SE</organization>
            </author>
            <author fullname="Michael Welzl" initials="M." surname="Welzl">
              <organization>University of Oslo</organization>
            </author>
            <date day="5" month="June" 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-16"/>
        </reference>
        <reference anchor="RFC8095">
          <front>
            <title>Services Provided by IETF Transport Protocols and Congestion Control Mechanisms</title>
            <author fullname="G. Fairhurst" initials="G." role="editor" surname="Fairhurst"/>
            <author fullname="B. Trammell" initials="B." role="editor" surname="Trammell"/>
            <author fullname="M. Kuehlewind" initials="M." role="editor" surname="Kuehlewind"/>
            <date month="March" year="2017"/>
            <abstract>
              <t>This document describes, surveys, and classifies the protocol 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> month="November" year="2024"/>
          </front>
	  <seriesInfo name="RFC" value="8095"/> value="9623"/>
	  <seriesInfo name="DOI" value="10.17487/RFC8095"/> value="10.17487/RFC9623"/>
        </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>

	<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.8303.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9112.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9113.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8170.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.9293.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.8445.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8305.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7556.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6265.xml"/>

      </references>
    </references>
    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <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 work has received funding from 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 on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define European Union's Horizon 2020 research
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, innovation programme under grant agreements No. 644334 (NEAT), No. 688421
(MAMI), and those included represent a superset of features a Transport Services system may need to support.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8922"/>
          <seriesInfo name="DOI" value="10.17487/RFC8922"/>
        </reference>
        <reference anchor="RFC8303">
          <front>
            <title>On the Usage of Transport Features Provided by IETF Transport Protocols</title>
            <author fullname="M. Welzl" initials="M." surname="Welzl"/>
            <author fullname="M. Tuexen" initials="M." surname="Tuexen"/>
            <author fullname="N. Khademi" initials="N." surname="Khademi"/>
            <date month="February" year="2018"/>
            <abstract> No. 815178 (5GENESIS).</t>
<t>This document describes how work has been supported by:</t>
<ul>
  <li>Leibniz Prize project funds from the transport protocols Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), DFG - German
Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ FE 570/4-1).</li>
      <li>the UK Engineering and Lightweight User Datagram Protocol (UDP-Lite) expose services Physical Sciences
      Research Council under grant EP/R04144X/1.</li>
</ul>
      <t>Thanks 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>
        <reference anchor="RFC9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, <contact fullname="Reese Enghardt"/>, <contact fullname="Max Franke"/>, <contact fullname="Mirja Kühlewind"/>, <contact fullname="Jonathan Lennox"/>, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="RFC9112">
          <front>
            <title>HTTP/1.1</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol
<contact fullname="Michael Welzl"/> for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, discussions and related security concerns.</t>
              <t>This document obsoletes portions of RFC 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="99"/>
          <seriesInfo name="RFC" value="9112"/>
          <seriesInfo name="DOI" value="10.17487/RFC9112"/>
        </reference>
        <reference anchor="RFC9113">
          <front>
            <title>HTTP/2</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <author fullname="C. Benfield" initials="C." role="editor" surname="Benfield"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>This specification describes an optimized expression of feedback that helped shape the semantics architecture
of the Hypertext Transfer Protocol (HTTP), referred system described here.
Particular thanks are also due to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.</t>
              <t>This document obsoletes RFCs 7540 and 8740.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9113"/>
          <seriesInfo name="DOI" value="10.17487/RFC9113"/>
        </reference>
        <reference anchor="RFC8170">
          <front>
            <title>Planning for Protocol Adoption and Subsequent Transitions</title>
            <author fullname="D. Thaler" initials="D." role="editor" surname="Thaler"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols <contact fullname="Philipp S. Tiesel"/> and technologies <contact fullname="Christopher A. Wood"/>,
who were not designed to enable smooth transition to alternatives or to easily deploy extensions; thus, some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and it also summarizes what makes for a good transition plan.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8170"/>
          <seriesInfo name="DOI" value="10.17487/RFC8170"/>
        </reference>
        <reference anchor="RFC5482">
          <front>
            <title>TCP User Timeout Option</title>
            <author fullname="L. Eggert" initials="L." surname="Eggert"/>
            <author fullname="F. Gont" initials="F." surname="Gont"/>
            <date month="March" year="2009"/>
            <abstract>
              <t>The TCP user timeout controls how long transmitted data may 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 coauthors 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="RFC9293">
          <front>
            <title>Transmission Control Protocol (TCP)</title>
            <author fullname="W. Eddy" initials="W." role="editor" surname="Eddy"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP specification as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with progressed
through the protocol specification from RFC 793. This document obsoletes RFC 793, Transport Services (TAPS) Working Group.
Thanks as well as RFCs 879, 2873, 6093, 6429, 6528, to <contact fullname="Stuart Cheshire"/>, <contact fullname="Josh Graessley"/>, <contact fullname="David Schinazi"/>,
and <contact fullname="Eric Kinnear"/> for their implementation and 6691 design efforts, including Happy
Eyeballs, that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions heavily influenced this work.</t>
    </section>
  </back>

<!-- [rfced] Please review the "Inclusive Language" portion of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="7"/>
          <seriesInfo name="RFC" value="9293"/>
          <seriesInfo name="DOI" value="10.17487/RFC9293"/>
        </reference>
        <reference anchor="RFC5389">
          <front>
            <title>Session Traversal Utilities for NAT (STUN)</title>
            <author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
            <author fullname="R. Mahy" initials="R." surname="Mahy"/>
            <author fullname="P. Matthews" initials="P." surname="Matthews"/>
            <author fullname="D. Wing" initials="D." surname="Wing"/>
            <date month="October" year="2008"/>
            <abstract>
              <t>Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to 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,
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and does not require let us know if any special behavior from them.</t>
              <t>STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version changes are needed.  Updates of this specification (RFC 3489), nature
typically result in more precise language, which presented STUN as a complete solution.</t>
              <t>This document obsoletes RFC 3489. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5389"/>
          <seriesInfo name="DOI" value="10.17487/RFC5389"/>
        </reference>
        <reference anchor="RFC8445">
          <front>
            <title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal</title>
            <author fullname="A. Keranen" initials="A." surname="Keranen"/>
            <author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
            <author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
            <date month="July" year="2018"/>
            <abstract>
              <t>This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities helpful 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="RFC8305">
          <front>
            <title>Happy Eyeballs Version 2: Better Connectivity Using Concurrency</title>
            <author fullname="D. Schinazi" initials="D." surname="Schinazi"/>
            <author fullname="T. Pauly" initials="T." surname="Pauly"/>
            <date month="December" year="2017"/>
            <abstract>
              <t>Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may
readers.

In addition, please consider whether "tradition" should be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements updated
for algorithms clarity (possibly "commonly used", "typical", or
"long-established").  While the NIST website
(https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1)
indicates that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8305"/>
          <seriesInfo name="DOI" value="10.17487/RFC8305"/>
        </reference>
        <reference anchor="RFC7556">
          <front>
            <title>Multiple Provisioning Domain Architecture</title>
            <author fullname="D. Anipko" initials="D." role="editor" surname="Anipko"/>
            <date month="June" year="2015"/>
            <abstract>
              <t>This document term 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 potentially biased, it is also ambiguous.
"Tradition" 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>
          </front>
          <seriesInfo name="RFC" value="7556"/>
          <seriesInfo name="DOI" value="10.17487/RFC7556"/>
        </reference>
        <reference anchor="RFC6265">
          <front>
            <title>HTTP State Management Mechanism</title>
            <author fullname="A. Barth" initials="A." surname="Barth"/>
            <date month="April" year="2011"/>
            <abstract>
              <t>This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on subjective term, as it is not the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6265"/>
          <seriesInfo name="DOI" value="10.17487/RFC6265"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9V965bbVpbefz4FIv2YqhZJS7LcbZeTSZdLJbnGklytkuKZ
yUpikARJdIEABwCrRMvKyjvkDfMk2ddz9jkAWCX39OpprdVtiSRwbvvs+/72
ZDIZtXlbZCfJaT1f5202b3d1lqTlInmb/dsur7NNVrZNsqzq5F2dls22qtvk
Kqtv8nnWjNLZrM5uTpJ3p5dXwRtGi2pepht476JOl+0kz9rlpE23zSSFX02e
fDNapG12MprD/6+qen+SNO1iNMq39UnS1rumffr48TePn47SOktP/Mij26q+
XtXVbitj/gT/zstV8hI/G11ne/jB4iS5KNusLrN28hxHH42aFlb0v9KiKmFG
e5j4Nj9J/ntbzcdJA6+ts2UDf9tv8C//YzRKd+26qk9GSTKB/yVJXjYw3jS5
THfFnj7htb2rNpu9+bSucCezRd5WNX1Q1SvY2e22yGBK8yl91sBwWXuS/Fhm
8tVlWl8nP6X8jnnewm6c7bZZ3eZlNU7O0iKH7S/zNPnmq8dPnvGvql3Z4ra9
L2HLF8lVCxvZJNUyOd1kdT5P6VfZJs0L2NAtzvCPKQ42nVebcF3fTXF/N5us
KMzSvqvztAy/6F/dy6pawRqubvP2l6wukHJebmbf2/Hx8P/Yyqum83WwDS/h
sNObyctdUUwui7T9JXli9uHrx4+fJf+6gxWtw3Wb8cLlnE5h7rsSXk8L1fWc
lmUafUHT/yGtC5jAAjfyJqsbGDWYnvs4a5tVCmSUPDXT+/1XT5Kvv3YviaeY
LbLSbkQKk5jOdBJ/vE530yYLp/9ymrxI83q9q5vWTP9ltajhmMOvaAF+3nT6
s6xeZDKqruF5tk3rFi8y/uS8XOVlBkRSroJfvajTJquTN9UMjvO7XV4s9Be8
Vn31ODn97umz5Mv359Fy51Urx+EWDFe73v8xq1fTdLYop+l8urum7+FET5J1
225Pvvji9vZ2Gv7ki3BPzuDmZXjPG7MjZ1WRl8HnPdvxskibVXUbrPNqvq6q
Ar89qzbbXYvs42qeZ+U8M6uVJ5Pk5ZOnydd/+lPvrfsBnl0INcmK5832j/A/
ntYUpgRMrYTru0lbmNgJ/fTyx6uLf+a/Jomw3wcX5+fncI0X0+TJ48dfTp9M
gAN+jfe6XKT1ghjwhb6ogpuZzddlVVSrfTKZJJfAxFI8tx9h5JSXtG/abMOc
cJnOs+SIhj2eJvijMiEuyq8BdlG4keDqAx0kV9tsni/hGxwNmONF0+yy5A8P
ZNa7Gtb6n80BVvBOeiWu+YsULnVe/qP8mFh9gusZjSYw23QGZ5HOgS+/W+dN
AqJiR8S5yJp5nc+Aj8E1S608wtVnH7ZVgytrnRza1hXwcDjMZZbi75qkrRJk
czpvehDkAIoNOL3NZlfKV8D0cOyGd4nejY//e70665GWxO3lN8llXa2QI+KC
zBmdXl4cJzCvGZzBIoHf4U40+3K+rquy2sFBZDewVZNFDdRUwvWAJ2En8Y3b
tEWhJwuDFyU7XNIma5p0lfF862wLS4EX4LBwLCmveAn3PlremHQAfyJruAtp
36IuNiBV8Ph4XXOYMIybbHZFm5Pcu0zSBTCvBiYz9h/r/spA/vO0Xctn8JOb
fGFeZeZHtzndNLJaR0LyDJwWHEEaqzS1UWmmyQVS3BJ4YUPnBy+F/YMD4VuF
v59XwBS2LZ39LMN1LWDL+amcqQDYSM+20PbjG+6xZVO+FJt8sSiy0eghkkNd
LXZ0qqPR67TcByvfGsrJlXIaIp3mGGeq++aJ2fwMvheihTNNbzJYV4Yr2hbV
PluME+Afa1DTaP82VdMmt/CqYp9cl9VtSUvKNzkqGwt4km4j/PC7q+fJVTW/
ztrk40diM58++UGTI/kOiXs6wssBLByfhc2rZn+GA2rozctdOeddTed11dAk
GtrLBu9EWbV4Ik0OVxaOGp+4SescFgXTz8oFvbGkCbnby3PEg5uOXhATSXHz
QdmTB5gs5ll+g/8SqsKJ0e3IG6WBXVrALuC7GxA/dJlmVbvG+7krQXbU+y3u
CZ32Jm8aPKmzCk+ywLvOszl6d3Z5LIPQyJVj13zVoxfR4b1K93A9r7I5yEyQ
akfvXl0dwzb/17cvzr5+9uz3sNPywgoEXwIjjJPZrg15FdxK3D28mG4JDR/K
zz//jHtxdAx/oTnBf2FDbvgDkAxFQ7tabXFXaM0g2ha0R7A3ZcZHNh1dAWEU
oAjtx8E9wp3CMfOQT8DTXWbb6IE69odPwiht9oF0F3u2RB6bJituMtARcEhg
57s5HEmTPFgW1e2DcfKAtwb/JnzwAfOWB37qD4hntel1hgNu8Lot8iWwRCSy
TZaWcDzNlEUVTQ8OAZ8oMtAa4TrBm5Y7Ou/bNVwl0A/oWlRAFwvQRFCs8qbz
/gDfyJjcdRS8ljO4k3gRI7ZIXDc6SD1FkFrw/BzVimI/HdG9WlVpofvUw3hE
Jwj4Yt5YnpEmyyL7kIMqMeKbsWtIrxA5CUo37K+yS3/D6ZC7xzkdnZYB7yKJ
dHhyLUi63YouluoJeJHksJKjW+LDsBFbYENF/gu/GJawyFHnWO3yZi2MYwlK
No1GJ1HQuRiShY0CcTpdTcd4a47liFWCjHQjzCNJ1qCaBSOQsIG7Ud0yEwlW
CZNBSQM/TkjmktCBbWsyImIYgYy7DPZndNqEB5wuqm0Lk4aZuO0d4yL2sPkF
MrQSpE/La0uJO+t7/QF4nWWdtkQz2U0F94RZRJtvsjEdb1Y2SAL0KyJRPgLe
AmXu/pTxRTA7oONf4OMWqRZESI6s0N5XuxVW4tKQXmMC/iuaBlJVBSyLf0yn
tE7LFUur6I0q8fl08gJZYlYijcJnKUy/FmGm5k6Z3fr9ELVCqZNPPLgOuMa0
aCpgJVvay+B0ZmhVLMl2SoAy8T+bDCebN8B9jlAD22yJnw/oP+Z+G/WRlB7U
LMBOA6LKimPYlDXYvAmw26y+zYGYwWRbiB7iWCmrI1mKTM/qRmjvgYgGgXXU
ZBkIC57rp0+g/b/laQPfJLlblRnOZFPx2hf5ghwJ9E667XgmN2khyhXLMbgF
82uhrrQWxQjmBsQIquVyP1JCAW4EvGKWlweYPtp4wCSBvpR7kwx7//yS9igt
aQ/8g3AbqlVGn9EEkf/mq13thsDFbzKgBDrvkVd+gB1ZVuKUYbI3WBGhNcG4
OB132VEvQrqY+ZWiyDS6Q+bU7GgMR07w7BxEER4ZX11Zlv/tGKlrXlQob5j7
tyhP0OSDCeKqWtY2zevJ7QWkAsaL+Rjk4BqPJWA0oZ58m6LWBJIDfrGwlMd7
SszAWoAHhAqquqCOXEyeT72Xz206qCesNAbSH7g0aJWkencfhZ9++jRNTgvk
CiAJlpXy2YEZBBd4UWWsKjq+C1yTVMjuPFSxZ7oFXWfshRsoMES/wlwdC3FU
w/uWWpUUGNCaFAHk1MyVQv7Bw2Vpk8PdxEUoOeA17NGQDkvKSqkIjvfhQ7Db
5+QbBZonZSDYljvflkdaF0iGm4ycKI3+UkTjAgn14vzdi14NTuwmuAp8AUQH
NmxSdNfH33z16ZMjdBbfQIGLeOfxS7f7xH15Bn2Dy6u/efolUtA70gKU5htl
T3m20EMOBQMb0M76QMLpG8Tfm3a9Q6lTIyHgNHFT4CyucmQf/tFGdfecOA18
WyMJlCsgghr48E2KygTeN1rwbsDL0ejRqHd7zHqCu9TEaIgcUfFUrTudR9qB
m07nxbIdE9x5donQTvcQjdvop7DRoxH6suWoroFogKPnqzXbzbDToompdNCb
PHTDLJnddcjEyEgOuceznBiru/5GMFp3CZ44siGSPEd1BnRVixQr+Y1+X5vk
hZimqF7XyY+sBOFCXsiwxySssqLJVFQAuS+QnNNdW6HTbk4W5GxPJPCZVz2Y
H0znlN9JDMbNAFgm0LQobZ7UzdRxzT1zxyDIJiNJLvfC3ABSU9CsG7oPpKrA
PIgT4ekRdwx10HGSL1WgoDS9rXYFchrcEBKqy12hxkWzm3lFWYdAi5YfQtYO
0o0V+6Vbmzh8Wah6FS8JjX5cpickPCgUQ6gUezcZK5Fo0YSsm0kiEC3uITyV
Gl1yygmqGq4g/oPVONbfgXOh4tCqChtMHvU7JyA+4MB5y5te3cpdCDVhWA7x
mTqjwVgXlfnwVs3Y8mnymgglF+t2Dmy+YZHx4w0SWnY77Im9Q2jgausMl8Wa
x8loNIELuqlgX+F2hv7DAwoEPSAWcaOGW6qMiy0FZBXks5iwoEKhPvWO6gI9
D3nLIqIJvKaDTtMxm4cNca/AUxo4R72UsmYHmvgoX5yzYEgcsnrftXI26Z9h
pGFbZ8qbaW0o2FMkjjQvG70Ai5QYSRHYWky/wyenwnELE5mjndLQ9cetKRfM
ZjboETH2Yc/i8AKhgM/LXaakW66Ro7JyLFZnd+UgHko6NNg1Xf8sdHOqlK0b
2QZ1xsIWOL19gKIinzR7stnTKw4lcesGBoxcsXvps0rYC73wv0HBfSdGPjl7
ZWqXYE8Yi4C5B/GApqNJquFjVX/0NXqdH274VazF27A+64kosTFs3iQPXr+/
eofOMvxv8uZH+vvb8z+9v3h7/hz/fvX96atX7i/8ixH848f3r+R7/Jt/8uzH
16/P3zznh+HTJPro9em/sENu9ODHy3cXP745ffWAdzTQa2qlLjoGOH3Um8mC
Mafw3dll8uTZ6OPH/wTawdMnT76Bo+J/fP3kD89QVVhj8JLcrih46J8j4syw
sxlrcSjjxLWELji0pNDvDUIl4/18WYBgTGsSNj/Ao+/Q7yjskyTXXJ30HIdI
k5V5AreaPZWg95ExKLf+DquGghXmnTCrWrn0Vk/Wv9zRNY5RC+0vOhtLF8sE
pTBKnqDegMwNX+Hcdf7yF+SNpnhcuZi01SSj20BCdO/85t5/73wcVuufwrhn
6XytiQsnFDFr8K/s9gRboKr33jF19x2/zrItcz1yXRjbIW1AauS02eflYlvl
pd58H/+g+w90dZODtEBvKs5PnCHJJbBvTtdARs6PoiZ/k+YFCVYyxALmJUYQ
2+5yxFfkcQnvKP1QZOllBY/vk8XOeJeiiajH5Ar9Lzyl8DPv8Jt5phbNjSWD
YRndEYsc9pUPZZuRLg2bDzo9LhYfp+gXxy3sm/hZyrEJnCA0KVTU7/SAUBTo
TocHjeM+O0mu0NuxEPrBU7+tnE8rOnKUJ0BczsZ77TQ4vTItR3DaNgscPAvn
omffsn+vEPaXj8nm/IliAAH7OiKWQ2vtoWNnnh678IzzbcOoD85MoAJvN+k4
ZA6w2ml3x/iwyJ7POMjmTeb+q8RuX2J31ZatPpT/uH2rrMR0IuYEcqFQVgQB
lPA8KOyVfWiRCOQa4m2mC+bpnrff+KzGzv03Z85gvY1tNnYf4x2Uj4hXZEC+
DZhXjYrLOdvYxW6RBe7NmIyaaN4vOa/Mzdo61GhLY68aX3OcVvwqueGYNWM2
XD+VW8qekQZpcmKedU71/tByE6kaOLISY4eB+7yEjBXQYEOYJjNHyex4SHtU
PTtIcqG2ZU3jOVOzll0SM499y+iL6Nzio6KasyUNikjVZsf+8FOwFJoWU3zw
6/dvX9HQ3gcd8rvmJP4g4IBNukQneHOLAn5B46XzyN8p3C+M7EQTpjncEE88
RZUZ2APaenrP8vKmuna81u1TwBjgDS/QLY17ZoyLgnkyS1U79XQhaniwcRjm
ImEeRwYn/AbHzmJORoGfNNosnNQrOglPQMjzi+Cz7q9CCvAe0cCZYSb3D40l
EhIgbZMVS9lA0TNiuYTjynpwFCDj1ukXdqfUSKstjwYJ4Dm0LL731cFV3YYX
NHL5E12DgM5aEPywxTO0afQ1rQn8kyuomsHPyujXTpfSFIF02ZJ81QSEVF+I
U7zUQAbODeh/hxpI05h19qgdfdeXKNMQbkyZrOH0nSQO4PScTvxSpGZMHi5I
XVkGpP6dt3TlA/K6zISXuFcECS9pzdZ2fISBsXQSBXGC8E5HG1mnHCTYw5JI
AzTBHnm1xOaZLvRfEitf57O8BflzU+ULEMirEtjpWH42joK+YoAZTi5+Nx5H
zgSHUYcQZV047qL0R7cSuJnd0kN04HdTBWMemB1WEnTm1nRpRGnpQsJ1JCnR
iZ35CB564ErvYhuLHOYY+V40NDiIjC0imIXbdxdmvyFXXt0Nsb12IbZJRxV2
QrszzW6YUoKHv31wDqEyr5SQL8cEUcF3Z+IiwLGECsIs3irA0XoNeXvi/Y5A
TGxfyf2CbXa5Qo6B8LTDi2f0e7nGRfcad+4v5bgE9wmoKro80UB/ubhIzTRx
VsgR8nm+xVnl5u72GSRv0aH1yw3YdXJgcx02egyHQIOWhjLrG2ZbPft8Yv4u
LmOW1+EN/Yemx1u3w3hva++wpIPRfMvOylAhxC0dNNP43wtJRwoPTSw4eRO5
VflNUbw+RS9Dqx/4ZAaRNfZL4h/lbjODqcTcI7BxeaC83O40j6U0mXCShIIi
lO7pqqhmQJaeBxsdD4NdIO6ABsgqXYKIRDZEylEnykJR2VXKRmdg3fNq4ntK
1x/zXtgmc7kR99UYOwb/YXNAVNas5RiUroVise5NlN6AEzbWqIhfrtkJiJSu
fYe3E7dUqWS8OBKx8V6X2Ovjk2tjh0c4zrBKlX3YciZMQP5jJ1I5BYqSdPxp
x56jjklk2H83B8qnF1EqNfuCRJdGZrmimMCy5oxUL7nYXeBdbnAvgJraTMPh
d23CgKPqhN2+kjTA+cMYZTNpsJ3EmEYzjzHsy3moeJ39RSnyWS3y1NF8T3wM
Q0ws+326nw0L87o09qeeO/ILyHF58aOpec4xPrB6vvgnQynxPZ764SgRemDJ
Pf+aokUfH3KYib3YNkzE0SQXSueoUaNXzGZwpI2klzScKiUO9SfHJ5FvVJ1X
QQIhTVcT6Mkwkdg9CnaX80w7E3wSpqn7BDvxFMZJKrCQd2eXNNr755ejJDlq
91uJJ0e5YD6LD0TMNWYJFMc0vn9ef8bfdjUdWgcnCuJBO+1fyEEsTZtVpQKE
zc4ZZqAkC6CWecuk6mhMnjV5gPqJy5CD1bHlBOu5yVPKmuRsNhRnVbHjDLc2
245hszkrGxgMOg3FAoc38A5MXCLB8zdX8Mhuxq+4oYSZ/+3+jEaPJr/lz6PR
r0nPH1vl0fvn1988nntD9519wyRJMNAj+rj70aPuMPA6t2fy7l9BLFKaOdLv
r/zJcyAVrEXgz/g53WJ97l7j9czz0LK6f+7e0Ue9z9EAeDmiP3hPDo1Hz/3A
N+gNkzIVXZET/q8wz874/240K7OXMgNfivTvNZ69aB9PkofAYSfKkKn27b88
MIyROPuDT78xgU0SnXfesIAPyYVthYKJ/1NcjWoa8Nu6zH8RnsxMWqVEXPol
QjDWj1hlx1pVDTSn25SSBXLvPb9bCM6ygpIlchV6f8+s6q9IugOpJH83a7ib
Esx48NzR+4bcDsCZJT2aEqWvzt7B/z8/w7+/ewVf/en9xdk4ydr58X/ctdOf
vwXraam4jfnOAAEFPOi3JDzbXJOwRqZbKCJa5dkhrZK4FNvlmSkLYbeBczP1
1ILSj9FU2JWcC3i7ruCXVtN9qnUvkjalAT9Ti4f6IWaW2uKriTMgN7AgrJBi
iAiXuQ//N3mVa5AuTMtjdtloDpK8gZTH7EObsQdjmrzYSUK35u/OKatNHCpS
ThWOj8Ue/HINJSdR9YBNKtSYE14YsTK/efz4MVqZ3+1lw3FiFI0y2qeWHQxU
BaH2G5TWUpq4uEqBeCiCKzk9S/XAumqjngx1tdYo9OmoI/TwpytOSuvW4PwD
1+kUy+kgRUdsZyBjiUrF2EO0rUpxetxVzIU+bH17fy5JmCvHx+Wpz9usvYYK
XQ3ya4euL6UpleVsMCvNmtQN67SwiRRUlJyWsK3ylo4hZC+iy/LjPa45mRYT
cvqK/NrP1m3ULu57ymtPJ26591KWbIIkZ+v5JMlvXVjuN9aPf8vlFu1vLCEX
K6LPh9xo4uVnlJj/5vJyyvmi0O/kOWePwvaORj/WORAGp5y2sWnvfAvJrIDP
gzptzlCyjuchf0KtWzxNvq9u4WzqMRdks6YaKqTK+331jhKpPeViP03OYblB
dM9SgZ9mnx/DxfXw1PcTmOxkCXeCFeuT5KLjyE9u05KLAGAzF5zETUTTib65
JBtXsokO7bEo0RgM43ewDxdHZZCFQJhiZOI2zVvNy6BaXGCM6B6mRDg4zQup
SEmb1uVluQWOyRVn5Ghj9mFAEWChhaUbrjzPbilPE3+IGUGSh5dSkQ5bKyYv
mQ0Uqdijb5pPn1wlIH3bsFnQPTQ1Z35k9kkpVHjA9ocBSIUIU61NC5PZAhyI
bnE9bCaO4Bl7p1QUdjpIvOeoUaT8BBmGA9trKMgzfRKgOQKSNB0S9tTCv0eN
gGjOUZZx0nO2lmQvZiK2ZxmWrJj8Pi2zEUAA//Nuxram0HRyzzVmAbSXiv+N
7/Z5XcNGUa0IMYqGjyTE/ACWgkyKGEn0cnqch9AiPyJLfInM1E2hzlZp7ep6
i3yZYSkwhy6MOkO3R5KyZa5d4QezvXYZV1TZgBfap1CC8Fz4QgZ9j3WKjt4P
7pVRjlJWj0p05qfB5ZT7QqT1uRz1nMfBWeEOcPVrUTUZVWQtC04ikGGzyGkg
CSUKoxHnzWmlg2GcJhVB9w8F3K4m3QEWmvsSe40EEL1sUiqQwRBzVac1Vg3u
SncYWGqmzlEib96+MV2CGcewqACycTok68RD/KPx8mPgPrpYOp628/GarAI5
QWEVulpT62wdxyhc0YfIo6EWwTShwXZWWPv85qnqJZFoXahH0muVRX6dsU2C
8se/AYE7QMzvSJlaOFQOCWxopixYNMgm8IDQTbhOBVrG14D0O9AplW22b7MJ
v1iEdyC1taTbZbUnbj50EJqvbV4TFTR9/+7d5RdPpk+Yj8KlxalTxneBeSWi
LDXZasNgFqLKSUKUea+aP0+ePP306Vv0I+ByMNFzDWIX3zNPa5SmCaFrYdIB
wXJgnGm/FSuvyMoVkI/FJmE1kKb5VNK8MDweTAslto6Cv55Vi9yF/WBGFEI+
ZIyb66V7r0vFmi+XZhZc803aOj/dbboPT0YzcYVop8mpvlFqjyyZOJKi6ioB
aPDm5clo9DsDqQCaqoapcoPnJbIktEK+hScjanPZ7HDG6YIrTOjS+hX3l67N
iRVwFlqOsc6el2uxLtznXD526ocpdQNKldRCgTwhiwexM1K6qVjw4PFLZhnr
WlRPJKVWKv+Un6ACtOhbbVA7CWvPV6WfimTZ+yTdyiJ9eNMu/k2bY241K/5C
/woFtK2qIgveihgdDucjqsAJ1W43Lyqlnl/fgrBtJmgtwxMoOxlP4QPjlER2
L1Wog+qR4g6h2aRl7CyJmUxzhkLbcGEcUptL0KV8J9Ky8wgFKzJsOZ1lkAhJ
9OI79MTAaEWOojVybHx0osauCrRBpdAU+UZJLxXXIYLQarw0RpZmUX3wtpZr
qqlDgUcWhzkmf/XGzE2Abxx9/IjvUlEPenMyq/OFbNwq3QbGN6aHmteIJHqh
LpjQHu0IoWUwXRIvKBp8qAEmzexX8YGIljQLRxxBmkcjvNhl0jnQLLBqWUXQ
nx5PRxetSnOX2SgPChvvKSKEqS/bW64GIs/YbJcXoHlvq9IFGeBoW0Yf2oK9
1Gb8RcFQXy4TiIea6MzlnzIyaWOD0Hcx5BBWpa7AFqIwOypNVCztbXGXbuPT
0wPwFOdw+ZafV7QW/5zzjAlOi0/Qww0iYawQJQRn4pBUmrzd0aKjV/Pc1AVH
//JE6aYmD6lzgTMesUZAOYy1FpTfEg3kWI91eg//iEADaZ3mzDgP03bYL0mw
Pw4egOtPA6yramt15v0dm2byxCggptu8FnfVJksbTpTCR9mCadS65SwsgqSh
HwcINWTESMJJt+pR07Bz4xBSjLHBRCivt67zFYw8KbC6FD8tI+/RYB2CK8Y0
5aL38WZJIp74jsdSv6IJXWPNMsPSK6qm6PrClruarHqf2rMU/d6iauTL4aOP
0nLJgdLguiRzgnJ36Va21pEB+jHMogF2hNV45D3xskLBEAcHPUJorYQSGBGw
cAu7R2Sw2Yqsuc7QvWDlD6snCDmWa0H/PKvJYu5gVeA+jh1dwS+FAOm3bIVa
MX7M8AZcQyTW6N3QjGEGENULBncW1B8OL3Apr1+J5m2zCeuz7ewO4doFKMAJ
Xsxiyqrl0juLsyU8iOi0DEmJdrdsDzpZTDk6lxIMHod6FnI0JduUUAh6Srpd
LuImX9U2xdyx5qE8IItQpZ4keO9ck0WBVc5bpzUxoBh7GaZOR9FCq4Dlhq5Z
GVeRGnVQfcSWJgbQjugI0ofYS+M0sVDbA03grKLvCBJ4xMbf5/vsjZQjhlL6
2ngwWApYP99l4V3WDQnqF62LsSbot/gZMrwabRdKBvbpf+qQ+xZWv8gIrcov
gExWdbJWmw3LDa7inHMCJvBMxkzTeycW3JM/PBYYnS5kIKpnS7Sn3BqJc6qp
RT78XcmZ6VQDdlTVYze/SgElj2lf9CCMkhXywW+5ZDtMwiA1Zrh+Wr2zFMXx
mYsuO+4+wKwPHZBrxNUDcPyPDwOIBobDsVCMPYCLdSZxzDBI7Ao6AkxAG/Jr
OJyIJisLNfaV9UXWyB1DYRSBvgKlxKMxGOgIrCrBq6jSml3kNpwQKJSRgCbT
EgFcVLdwKiO5wiqBEurNiDFILR0yI3YFJIwGFOUMKzwhJpG76iOu9tRsaVoo
8WEevIfDsT1hofc4edy7rn0Er8G4C5wj7PZdUCgEjoiqVIwRErq9T/R2uBTc
OXFImyYZw4fEUNTf6jvETdFYUBtJ3w0jXup9Rpc/STGv9VkVwILwooqn/iSu
r3Uhvd7CEP9GrumU06KVOdBIMxjI7mq2AxVLVo86yQ6rqLD6BnF6OBK8ydo6
n0+T77J9xUHQJiM0oQO3vkYsdgFIIahbD3tJYiDcXgdUFFde3i9baxi8Mo+u
MekCC9aywSozcLmUEW5pQnGYZmmT84PstGAFJ1aYDlDzmGHoSNy5zDhNMOtw
DHGzlQpXHxapRJgnCHihEQPSXfpPgzf57n20wNVddCTdZfSP8CaoX0U0xdoh
qTC6pVTm3OwKNMmV5bB4v5RxzniTaZK4x/JvLYEDawzso3AeWpQX4mS5y9Z3
hQUTZZZxSITvO1lrDurW5edIFQOjLt8VewTtlJzMaUNIM2NyCA1cCZkEH5Rh
OethGLbPgtq7kGJe+zLUgbcLCgwwfH9Kqoco30vK7hkfuse4Oa2DxLLIRO18
jcZyGFDEG6TWoSsMcjUVvp5ENS7jTvDFIhaj1ui26OrE0DNyXExLNzA7AZxH
PQi7QaXb84JQltqmM6F150ZqPUazZrA0KpAiE5/dFC1HPw7G8qyOH02z2c0W
OYeEKEmsD55EbV7dVf7XdrBiylZMk6+D4BIUuq5bufhtf8Gjq1dlQQ7bljfE
QekCSfnVwfwr1Kwm7U7UK1OeaB5jcRaVgdPodBNQq6AN2gE5++rPEecbGRyj
5BBKDfvWlgyMF5VNe7g9pOkDLEQ0LoU5PgDrJdF7GKnOGQA4KkqNDD1WWAzE
r16EQD7lw0s2RHU3zohTyYUENN3AwaoTXLPEl2Pr0nn8lDq2CDKPUW22+xEa
wKkgIbCyKwBjvPSuZ9ryWmKs5ymXS9vMDtKbsOJxmcJZcT3+YXoIfsrXPL6E
dDoSOWUw7nlVY1SV1CLlVIjy3bTKocP0DHa7h5Dd4e/Vr7ekuuZCOUOIjEhQ
gtzRoBM60mJ2ExaSjDRW67vAiPaX7MLSynZencBvESiBsBAXswiCT/ZFgTig
u0DEJrvM0lAwhdy6OscgHhlXexnmRASFlj1iwE2BiY8ijSh1LZ3CTa9YwKOI
6ieyAU5hPCjOrOZ/sq7s3PscFiOFQSccoKYeslSEm/S9QwoTSXD6N0WAN1Zy
aT1nH3NPTMeVrhvXQFwimcbM0VVN7w1cgBXqledlY/EFsu2nlrSndNL5KIaX
nDrNh3DxBGPJK3ze8uveApL/ekLqBSRBs5L9UqyPgd4W1hCCvcprD/VjwPhD
vZZMq9Cg0pRX74L5HGF0oMIyUsiFxClo3pjd6pij6i2mJiuj0+DHWlM8V0BS
yeft6kcOk8/BEDmvqT9o0s6q1v6OYWcjdpYv49fnev0oRT1XY1gZVuDVxf15
j73Q3oFKhYLjx63NBxHV96tnX1OuBBvgymQ9SC11FOEWHYcT0TF2y94zQmYd
qxjy3MY4UNym5/KMcQW1iGVoh1UeS3AJO8yW97XFjRM+kpjJHBz9bvI6OhEt
g+an3DHSYXf2XCeugJUdDVgVyTSCVNF8i55dH0d5i36DKfk0FiMav6FCV79G
xKim/e8hTtjxtWbYWrz+Bj0PnN7ki597kFYYBVyCNB6RgOVJCGTsXVaDexgN
4BioOrgFKoLTIihuSjQLn+J+0N9ZxFkcUTrKXqSs0OaW20pJrUW+ykVDk8lq
t5TeFyniWmoCpe5UGMND/2V9/DZIIzEHDrwckpGND5jEckWrQ5AMAu+FJIuY
w3HxziD39T5RIQZ4pzHcSzQDUlAL2Y1aZ19ESPNjZ0r6ZIGZpE0M1QhtqgVF
PNvGOQgi89YkiaiSiLtDi+rya+dMCX2+dVx8gu4gL+qYz/Xfn1j0M7J2n7Wb
/L//839N2CyTVIa5mK6O5yspckceAodAAhRjmDKWK1R3XGcOBmHC/JfG25zk
TcwNfEGu/cGySWg1btfAe/sisEMofJSdzA7VqqwkBGjWyWVT6miLTvTfdlkt
ChMTn4t3sm3fI0E5vIfw6KTDoL89WIHA/bK5952Ye8PAecnHh87sm2ef7pd5
QNxRAI9wff+hEY8YZKa7AI4kedimoJQknrnmt+3pgj/wlvIDnxiXqoZI1897
QjxrFTd0vy8m0FrZ4NS4T6N9pHp3YXroeD8DATHuEXSXh0W8xKYty22lIowB
k4ETlpNsGLRxNEomffUiTtgRU6hv3A3UZF/ClqAWceMOmqHYqruShb8k6rbV
VpI9OjAbkXqI3NvMmWTB4AiEpzE4AoovnAMnFt1KpUXBqESdTmEpnMuu7Vmj
vzea1twk3FtBaxkCy4DKLLCzCM3OJRDKXmZ9A+DK0Zi6LVkJZOGaduBwNGBL
Apa7+/W9jwCle87VQ4JqfNidNBv46vdSWETBeSTBUnbPgTV53GGP7bMPfAXs
PpJZe5VxlrmGCrT1HFofeD+mfsekLmROVN4cwiUd2IlOd6LftH72Hy4WTeho
UdHIPg2XdjA4S/ye+GjaBA6k3JoxCGMN0289s2VDxqZkeC61DXrb3bfYDw/B
O+80eDMyDnpWPMXECAGz2U2nzgQHiq9mOkWkOS3N3+5p/9wiaSFBExIYNMce
6VBnHbd9p7uOy+V34oH0Im06NUUty7bi63mFqpcY91IPmjD18b3S0AjRn1Yi
QrtXid9kWdvHkVmFPrJdf44H9rBvXET+D1O5MYONkqSZl9GKs9BXkpfxp6TN
wTe3Gdi4tVYiNNyjKvzpPSd3+i8DZoR1TwXBDzuoMWmsb5IdJ623l7yxwvGx
3UZfQ9BOr66SJ9OnlEuHnbf531+qSLLVPvddk07ZEpLqG1SrI7mdGnTSVCIO
MTWcujc+gNE27ngC1VUteeKIHuSUsnMu6sddO4Ivrs7PjvEk8Tdkr2J5yBV8
VX1/fMxq7Gs0bdBOI1AImhczOfW3uyw2XEZZtXJzSmn+dMABdhC5oZRVmPYd
lCl1v3ZNypiG6ufFNg1TEEwyeZgdw0xeHTk+7Oz04m6ThQGzWablrqLKHoH9
JOxIUc6Zt3vQbqMDulJN0mXJPxXvzMD4Mcgbx2DSJny/ZO6xwabmeBc/GASQ
yxcL03sHcQZ0f48wC5TNMtGexCo018M5jGwA7D4M1q7qFeXeoTcodbXNQRUK
2/n7yCWSOy+P75HgF+v3p2+13keKOXZYsSuJv9bW9q+4RyNerNmr7sxJ58Vj
pUhjArUixkjQhNk2pvwP3Z6UakJhddxlxmI0vPFQqFOkM2cASyayNmL0sBj9
MQEzVWVcRNXd7rQyJ/cLDzPs4v/cxydMyneQHUBeoDwROYOeypXFg3XDGn9k
U14cfq8rOLUKLbKDRXDSVVCOVfTfZaeeMQweSkKXRpZXBEbj/YtBrhAFRq92
FJfnoRYj+3apmm7Fm9S0XDYrPxX8zA8U1FiHGY64W9TSHg4eUf0wWo6xSsG+
WKDQxHFgF5pRyziXprn27XpPl8lVhC80mazRAto1akol5dj3bJ9mqolzyQdW
ODy+cQdgcEmQwkd6yq6J4yKb7TjxeJGnq7KivDmbsRWHXXdU2d/zflbmMQVh
zvU4WcDG8pLvDHw+EshdivRmZcBntgZfhU9bYbg5pc/5LYIUQtw0WjoQ4uhh
L8EFeZrsxuGWWh8fuj5d2hXJR1QpGtvfYy7I/ET3gUtCKzjYHLQ9E7TgA0wi
dtm+W5u+X0MNkcIeaIiXzzXXS+aY6j30iETkBLMdtlz4ktd2r0iseM67+3Aw
OcpBwvj2RvfYBp/M7jytbM5XRbXaBwk8GGDCPMwIkEjTQXxqhJAQFS0XhWRf
hlkd3JZKM6PqXVmyg2kh6bZRC9/cVy+6M6Pg23CyPaYwoR8Kb8uqQmcEmOBP
poxbIu+wJTxRBZV2O+1DsRk9ncowk9idePeLDWjvZ1QNdfwOyE6wrL3ZbZAm
FabQ+57cPtHWH0YSErVf6/YTaQbgmwlbwMH7YFb2w6/1wnfeC3QQx+yMKh/8
z/Cf/oOJwtZ1Rv01+I//HgfCSEDvz6k82fycgQ3giTBu4H7igJCiAcw/oyfp
Kbp8shm/fv7045/DrtzwXsh/JjePzM8fuY9lw+Bz74FHweJO2+y/HKUnqsQQ
xaPgZfHU+UmfAdazrv4/8mQfoCN9EZLHo+jJQZJ9RL/lTjy03F8jkh2eUGfM
Q+P8OvTF0H5+1q7IXe7OkP90Z/VIn+wHmPw1/Iu05pNPfh26yD1Pcju/6Mkj
D7b/Uus+j+812zvG7P2yMyZ36zi+7w7da532AD5vh8RpOfikmdmNTOyes6V/
Oa9eMjil7v2g20NuQLoSg2TdvR8dZjF8hf7b3w1saA9qqAULUPRQp/JyvTGj
qjXrfOtQk04/p17wAOBoXP9t9UXbRjPpdJMUPSJ0mLtMy7/bDhxdzKeg9wZm
gnLip8vHC3dAgwQ+hydDE00qMhkqoV6h5aGllRMtoTPLmSTO0cK2laRQic8u
qFn18UHjzDyo3x9GmNUwkkuoKiMgJAwrUnpcndzWOVdX9lBGQD6C7/lX6MN6
Rw9WAxvm2rFSLkaQIGiy4dQ3L4EnCf+JNw9hoLDpeejYw6qN4e1ml8vAUehN
H41e2JrJAb9gkKS0daVGUZNOiqbIXzHm7ms5u7EI06XKZMK5puTlEDTqO7Lr
XVhQbZy0EbiNhjuVyaVe6Mx6IP/mmOnt/TT4TZGWqx01qhv52ryedY7FNrTl
lAjCIHdiRZ04iUZsq80DpUzx3hK+0mUnoQe2F8gq+Az32daTRsnNMnAnkQl/
zZFvMerzVpx97efHSHKPAUf7q44Mh4Zss623W26gcag4ZJzsyoKAZHCfb/PG
mfZ4h0yiiftU8zu6SVC4WilzIAaIDA/LgIUK6qxxuW2O25ywKSk5asj3I+yJ
+XxXMxXso7ZGYbILg2IGoLKOxPcm7cAkuVloRZItmPGiHvQp0sV5TBMdglhW
c25uK0iHIRWG2Rrk5ZYf9txookkE5PNYdG4pNJsQ664Hs8i2BVp300UM0BnJ
NxqAc1W18kmRVFm2eH+i4459iHXss6KEA+Mf6EmQYfoREkA5saOp5oq8FqyW
QBaT7xXa8siAmjqIdO+uoYoLGiHwpPXcR8fkPLxMWP9mVYFzRZT0GIgE1li3
2FA0N5HLKC+nC6nbiy0223MyH+lN3IC65rJHRtghPsG9ETlTlLbmnTH7YV+M
F6CHJDdZu64WBLLDbia/1Zovgm7WtpJsgAAVTSZFoAM15p/cqnNJXUrs4fe4
iJY73+TZrQMxMJCacvHucQJyOabJGxekJa+iexsV+pOPDJ29LvbswlaVRq2y
MFzIqQAFBXwUzqLaRHAex1ofxVUCNBqfA0ghGQl4CZ2VmXN/YaBAy4Q8kyLZ
vpF8Jf12cUIz1GqkVIph0eaM2hL518hsi1kx/jkRU8YxMTXK5c+JpSN+Ucec
CV4Uf+5fZL455AQ5OfAdfT9CkzDuB9vzsO5uz8MxdJN5+C3f/KPjrm0rD/em
WLqRr4DxHXi4J4u0u+a+h4c9Er/h4Qsh95+A78iEo4fPEMISPpaHYzv3kXkJ
/Iq/fqTfnc5gd/jhR/RB0EU3CR1X//irvRb2u3/kWSyYWrpT8G033RTM9Nzi
4Q8HyzvHYnfuV/P/4cMDO9t9+ObQw9GXwcNm/eHDj/qW1Bn5Ldhh++7Iv/oc
gQFXYY83tX9kM8G3CqPe9+fkL7vYPV4Rx/O1n8rdcgC9HBcadWMBNL6P/CA0
JVuu3q5Buees/eZk1GHL/FLLOEkOsnQ0XBO4cZf35pp5q0Dt0R3hKUmLSIH0
bijcBeQ+anazSQDiHAQD42JKz2kw51PMVtMNZnQ03N1z3MvueI09vIwy9sKV
xC3OW6xeYZlK4WgSq9zQz0jV8QgkIasilLFmEl78aXFjG67AiIbxBi0il9yO
zIQcpDQnRPysfOzn5Ihq6HZtZzYkgX/2/ObnEf00aOdrf46lYFSgETUxFqdd
L810cSYiFXqkAs1ZvVa/Zh2MwTBQAUTWKc6ZFNkxe7BswZbksWnPb6zuCjsj
UHsDoeNsFGA+oCvjoZefP/KMCC6jp52GSc6uqK2Opn714edOgYd4B44cayjt
yanQpVQNV/c29JCOH2gNcsDfGTrk2KJftnsY2zmiwtwZo8ULZCr7gNqgkXG4
jIHd0LoJZyynrd7shHTiJsqqOfAuyq5jwEl+Nk7IOeqiTR77LqXUAYUBTyou
UYU71WriMF51bAWqr7AwlseYiDfchdtXOZp9ZifDHBtjkE8m4RQ1+kBejEu9
EIdQKnjA+pCgGHGGVRO8zhMSHlLgwyJj6FC7cBQpBxYSGcR/SRPxfoL/ll2Z
Fk6g0yAb81gJKNQBy2TSDDB1IC74/Rf4blpxpB/HCx78+rPWC0Z5VixdxYW/
JX242NE6tRd81O9bFvCQIBLDJgtvpQWAcJvk40N1buKC/a+xV3NXupt1IRPS
plgp8YO+dle+NbI7T2XJX5BTkxmv4ra4ErUDrbKlrB6vhrmiAoARbHtIwnRk
3SWtq2LRCOffMoipZF0P+hJ6VqcpW1W5qjo9l+Kq97TUHTsLRby95v7QJ+h3
KVtb0q/MhIrkq7rz8HIH0mjimeNXk3bn6lbNq8kh2VeTPTY1E2aSitgWbb4w
+yw4o17mhbjt/bgLfjM1HT9V96E2Rab+bxFIvKkEMwjUjObKgNd092MM+QPj
T4M7I1xetCQJwsV6Zs3pQqpdTcXTPQ9uU59uSoTsN8gwK7PpEn+JWjEZsCTa
bvwBU3GgzDaR6hoeKHciG+ZjtFzWIOmtZlbqxzXzYL57QAwM+PqxVISBpMQ9
LPs0jiDpLqMYQOil9nBXJpO5M+MdVQ/3q9eizNHlMZrFUdBNzSG5K3qMGeKY
65gdcgCJrvTw25ZAkAUl3/W8sDme9kmagX20BdQKn2OXqXr9z0yoP4fuODMq
Fxk6B1y+lFxC9wKv7ode3DvUgKjCO56fdpo6NAZPDftgDs/uruX17qnVB0UH
PrASbqDers16lqK5OGPG2jqCJktBlrDMOtgCdjr3EPzJQFHyUOG6AP7gV3n9
WcEvcUtL29F75ezidkrkkM3967xcELfpXQr6Un/Xi2M3QNgn/T92ReKBHVB1
6GrKA/ZXsA+NOFDvHlsd3dEMzsOiG4OSufQ4rbtRppO+n3XtnkaBs5q+2RAb
sNdHe+459JQ43NhtF8l5Ei4R2YDs/c7JPJRwsXcB8Ss51VXuYI/UDaptUNrE
+h5NmDE4WkIcqLmH6CKKBYgaq+rhYYHN8+Moh6l5zqhJktRDdNiGE0+8LlGw
u26pjw87FIU71UfDbEf0UzeHGFVm3yP+jdoShWGsVAyQ0lhE2g4rh5xWh9/V
G+LmYI9nH/iUA8+Ch7RrcQ8heETDTnydfCgIl0ShUoSaxDYCB3ga1eo5ljZN
zhX0gDF+BpSIsOODA8oJouhMIMYf8FM+eZGHGD5047KiICCnV+/OzbfHYSKC
Oi65EqheYdxe77xFIGrIUxquSqxYQqbd7jiojKZdOd/fe8FO8Q+gPsKsq35l
3cBb8S4FaIAeWUii/GOp9qG+JJgIwx9PQ5uzczH6mbADbw1ITafmO17bPikK
jgPvmBhGYGnzHqKuY313B+1Omas1vEDGI1hqJyKGa2q7CCgui+oA5JYN1jKP
8BA9gjm21Tl0AA2kqLQD3uYUe07uuigVAGns64/0JCSRziR6xekfHeZjezKx
LmedzgzcFW3FXTAnB8jkoKDe1jnzq7OBN3thiaDQmDiT98l0aVqbnAmeOKHf
hq+10yJ8oKEhA1g4mjO2ZZvAB5TEgDDjUxYmnbDBSW9c1AE0xh2+LBsSrLI1
Ax04RgC0hF1h6PzKrqa/D2CU7eXpwCI4hslQpAFCeQBWEIYdBC0gUN0D1ubX
GbJLD3PG/jHvikVRkd+gmXyd7amPkBbyhh1w0gLTXdr1xoUIov26SYtcskfa
eseCWmBe/GjT3jNhuGUtWjM5l1w5PRDFkq6YAT6A9KV04zlsfP9OF6mhl3s3
mkQfAuI7FUXn48Ou+qLmGHNmnv4+sd63HpWEpXYl2ljk1kDgnkjrcOYIJWcF
2aJ8kOQzZCydVkqiuCiWtbcIm8VpquR/o3wWw3wYQCWnVtI+c6VAXxvacATG
gw1s9kVGiZjNGlbzrcGI7H3Xn5EWPAnztHmymjKDBzHgg2usE06M/60050G1
lC3QPackitZc+bhZufKdsXwzK9Uhh+3ZsaT/4X1k9bpx8EvGEMcgl9H6T+BV
CnXtdH88VtKPexN9xPTWH9OOUWqsUEhPtl7a9L6JM5JoJPSqmKS1qXt/Y3CH
EW0HP66lCWTUad6cJZJgFCtzyZsujZ6ZXq/mLr5tU7yZxS80W3+EPp4ej6Nb
GjHjvcvuciCITp5m5k7/ziR08E1NnQCOEvEHAq/ChEZJTC5kWTU5blxaZpwF
LvBszXD6V1vBmzr3XLK9wgg25cZ3DloDqmlrYprsc7jPzZDaVKed4+3AGX3e
/TjCDLUDV8R6eviSJFjcQFvpiHFsU2KZL3ifpTvECNwZXjRAZ9TMwaMMjvtn
YkxnilGYjtIUvwUtHu/SKOlePYHeEt89OfhNzH2AfHDl5mgykw4ZX14lGOd5
SMP0gERpl7gE57qr9iW7OGy+WoApSrrr+tp6YXEPvBHnDGo7vAuDwKbOxcF/
oVJvbwgbO9Ig+ek3X376hNCp61bQh9CUxfznJPlecW1lFsHy/AxcRZHIJmqB
/gHTGpJgOqG2tTWI41fv3r9Jjq4yFpGgsyGIB4zxvhU4G3gTXps3p++OFT/5
y6+/+fRpHJ1OcDZY+xNMIXEwWig85XpdnJ0nRxfaxTyMfgV6yDEevepfvk31
V7B9DOlOPgCYIl6OnD1Bi7yZI0jRXqBEHC8apFPSf8JMbw2K4iu8LhS45ZDF
ilqBLq8wnYTDOZiwrMhwgV7qLhO77bCtd6i46iiEYaxeGgRt9Dkb3IW2N+eD
7h2/VJDMUjc/EpZNs9u4gndqaEgWXgfL2Pc0Nr2o1/JI4nKKJFAvMdyGZrog
EBzyFqYMvkUTGgsphp9Kaw2GfiNjwCPieNXNxYa5MqVsHThsui+qlNLcLy6l
pzX8Hpu6SYNrKnyjfug2Wu1eiLZoWreCESYfT80JBw6JHmes9URohZcWs/G2
OW+O0UzFeOp4cp2mXvX2NLEZWtL5pMfZa7OjvWe4x6nGjMi169srzpinmVxQ
LJ3x1u19w/obqm5sTcOt+8U2FXA+oWNv63N3SzHPYudUxx3RUCXQIhMvjkeZ
EtHbUVJ+WmdaeoB8we/egDNd8gJ72nVxKY1kasrTnreCLZfSDVcBu9AwuDxT
J77JncBr5itEmPAgsZ3Jh2kCbsrqgkjra28lRuvZKwgNZ/pzMolUCi7z0hNS
x5Znf0K5CPRF7XNH3TP8o8x+QiuudyXvQq9plfyMQ/zMFMD2Qc+BeLATD3rn
NqGiUi6JpIlXlAfyFS6kA/FIHnuGOnwWeCS49QTMWYmYZeERFNCUhOZ1o3VI
zqpg5ZqO9oRqHo3pq/g/BmA4KsqpKb8YjaNQA5O9OLTFEsLomMq3DiOms0Wc
UqSePL/4wcX1nJes9Wfp3Mj39Y4zs5NRqDTtk6Jz6KJq0dYy1gPKVP4by1If
jOK6be2YaYSm6wMYOqheSMd5DpFyW7K4Avkfmg5iq0Om156Y5TzdNrtCKoaE
Gbn8Vs9eXEEW9Q+zz8A/8RlN0KUlUW60l3Gaan2bove8i/+r+QQCEbwIG3B0
NPcxHbEyihC8zpcfulypHVobOyp/X2jv3bHNMfLYaa7dTRDDXqYaTdsYUxWs
JcKJjRDElK3fcNok0TvlMUnRlMdD5iqwaDv2Aej0WKp20Ottxg5gstTj3bOv
2M9SSu/GXAhtJ8u05rZvnRpEKkZjVgDmiHMzcFpJgJkhwHKGgXGTctzwbzZO
JeHbj+qRZCt5aUuITht0L4HWIlEBixG9jN7lMpF9IhSpXer6C8v+Pj4UbhBD
GoWlf1JRJgQZ3OqogWoU26ECi5PkimRg0/29BiQYxy9M+XbM81Du4FRxnIN8
tULgs50DLyrVZs+ca7uWqZ1eivh0SrMHYANzftuYWjJ0cpZxKIurbn7jesuK
8J6zmnqsS96eCiu3dKveMANnxi6HwpllacN6IRgVHOzoJIuE2WL4dZlaJIw2
qMKIzpS1o3sv0zn+1uSAEd2qo42oCPHvf65rihUyJ/O6Sxt7JpUacZaqtVQN
Yr0XOao9ZPLMmYuZoBrfAGEX5GIJpKUK3W1KbmvhwZIz5n9GbxG+agUsimc6
KvEExPPGHwtCeoPogGg5aMLkYufUYnNIs4xuMdFjsLugJrUnGEL06Q8BjkNf
9bDoVm4PcfpsSTgIxFRRHXUJRovVmWs8Oy2d1qqkYp9wLdHVm3SPrmmUe4mh
Z6OicGRucWCxCrGrunQnU5Lmomk90kKVlx1CqSwkcZalfOMKvg3HWggDtsXF
3ttga4zpuuHBBar5ULV7rJcbUEq2BjxbYfC7xrFUrikPOA/SsSRCW7QKrRBx
IWdNIWBMTjZxWJlxEZo+36rQRk9qgWuUngNXO7IRblFB1MXg5NuccT/w0B6s
02I5mXPdzgOUpDmb1Tl3yo48wajfSGeqFxdv3HkhSk6ZJe5JSQ84u7R+aevW
E/ZbLqQ7Dgtcm2alh7EQra1Hkb5ViBBUKI7x7KkGNDTLYrq98/CB9REJ/SyQ
yk1MGAevk54r4eX4XiwiYjgwsWsJ31VzxwStdgNSU3qbLmpsSRE44nvQeBnA
W55CeNkdZc6mM8YeHgcYfJ1CoajYIXlJeCUIihx/yIaFeFht4IUdEOsU01oG
YveUDjB3JWfG9p+ZcPe0b1RTm8DP4npBZU1XcZqZc96J0Agb6hB+UZTLARuI
Ls7MNqHnm+h0095Gh6a/lwuIfaAgIvmFeiZFEgFraDrrY4AA17Nj5pv1fKBP
VoQTIJgGtvlcRLidZHtpFXoW0w711SB1Jbvt8UjEE8Ssb22/xTiaXR5vjlqi
blYv6+R9yMKDhgnaVL7/zQxRizqDtkM8hb8HOYbRVeYxiCr95neI1848+0DM
UINfwY/IRbdXb+CBvJk0d4irJVxuIEOUWpegDYeO+yZgcr2mOC9BdRThtk4R
dHZQ2jlH8R9QQJ2/NRUdOCibBRJMiCs8lMxHrq5jNGJU3Q6XoCXTVTyoYIS5
YL3lpuI78D1SrEWAiuoHyR7p/YXMJoTO0sw15Du4rqC1EknD+a5pNJUGWeJk
ziOBWBpCywqXEgFAK+YLbsM1Zfk4eLzUANgqgd2NNWZ4xyG97d1BQTQ3kDv3
G/ZAC1VCEhsYL258Y8ali2tiRD2FYALJ7MCE6TJ4oL4in9UpI6O7LDd2oYgb
IqUWQdJ91QCT2ZiPFitKY4lUgarG2okst23cpU7LdL1SFfkEtDInlJCaXW6B
74cZJh3HaQxI87tmoANE12PpUlNAZyD61UJYyftZ75tcw683ed1i+KPb3VnK
q2TrL2Tr0XMoAlNPg6DWy7DnAlpZ5DUTfPXM9C2OMNz4XhI0jJjfQbF4kAYf
uhFpLq4BQTjPJjnys3CA9IGM13YwY+v7qQRCs8yMCFc8Oh+HWjk4nt+yFL+H
3BJNw03c9fLIqSQHyufYhXVxGddCSV+B5Mhl3vT5BdX9mHAZpeQ3e13Idcqh
y92ZxVhH/xYGH7u6P0pF7pkz/bgHtA2hIZaonbDXP4TAPJEIY7t2IirsTNrt
PIu5CBUiq4tuMpQ2FEI/jrktCBffoU3pgn+EzjftQnO6blW2ngMHXCmeLyNx
oO/ffYRZlybPlejIPMrtBv1zrv1gvDXRDcBNip3rUVPdnj69y069Cn4yvAkm
52A6OJm/dGdII0LIjc/ZmeAoTyS+8jfEcXUbZZKO4m3qW3wfrqtsQgfI0e8A
923HqFBKcBFObIcAr1Jx6QLQaaQN45agJTLnwmzk5n2wl/WuJEwaUXxUNjtd
Plb0hXQ9pOqJCyMOAKrm/w7oqQ4y1eCo9ngAEaaAm+UgcMyrK3g7Z+sIyok+
rLlfNOF/26XambbP0iNGp5soGY/o+siwmkkgKcP2JzovVjqdxWnajjtrxPfo
oe53Ik4xtZky4cl3vZs1CAFbBmAGYyAuHJkDG74/a2Bi583nNGSQoiXMD/KY
iqp2zNdV5fr3GHJmQ4caro61ZoGjwkBDNeURmU11edxg0rTzDvyttDvi/l2c
zOEipE6H57KTHa4crjN2FsWUob86cO5DwyIdxHvy8aG/9F1x54XVyeA3HbyL
OXe/1v222TfMfZzaEohOVCUHehBHghL3wz86mLQXoNfYPLhOqMDcBvJrIn/S
wdYZ8DvuwzNUJ9RpyN0vGnu3svPt52wnsJ4m0DNtm8i7N7i3qvjwRolVZTel
9vt12NbrdE8JaZJbAABBiiAZjQbrZFzmMWsM2m/dX2rpKOXSLKPUZbjoNg8D
732dM1o0NREiuVxtujAyReFizNPkp4xxmVmx4x7ozJMbUQ/GYLDXtfRfNh18
SAv4HnZ2n5zvMxD3wKUl0/HLx1+R6W6sCq73kv05Gfhcs32EXGSHxIfvdo/W
1yCD3ZF/36Zwmx8NdtrmeCG5L0JSQgUf6FM3yggf9hNoVjZx86WtA/MxG7dA
/4+/4apSU8Dmgg3+PpHSjf0Hy6AtLuvipHqR2HfxiqCustF23njkf/jqq9+D
1jTCXeHEcGcZ031DlYBTflFu69LE/O8dWZNkG6ykwaslWoVmvFMMe+zA4cqk
QCFE6RA1KQOi3Irq5ECuDvDXXowoPdD+z//GFOvkcheApS9kZctlfAEww1NR
ra9BYWKoa60yuPGF6HgOiiEm/O+KzyiqZ3fuQurU5p1692/XbGpf2H+MOm2o
MwgJ9UUfysgnoToU62bGXielVD+mml+P4OiFhCi6Dr44Wy5RYJTzvVrIN1mZ
ky3TA/Q8lhSfw7EqckUH3njkOZv8F1+EPuxmpAZk5Fa+o8+w+Hj7jopOnRpU
6MUTcup0/4hodDqKMj9vs1kyA7HRhB28pUnArukfn/xu7srTmUhY0eknnCuv
HAMuD5zMpQLPcLoIV/MA2YYFWY1KRX1/3wzEiKG26pdYaMldPMD0KDUlus4m
/KJeUvKWrnIkuPPXkkWM5ZQlihiH1ajtF9l06lhLvngA+CttPKVIzavqGsmf
v/39099/JSHcJvOzdf0YlBdr6Pa+O+8vTejx13OlzR/ep1QTsIIYpW8y8MF5
+ywfb0mJ7fAubVvRtYU1C5+CJj5lDA07m6KZvB9ce3pT5Ys44tVI3okNAlJs
Cw/gi6fI0gnOi/19yAmTi9M3FDelcgC+ehKZcH0fGQXLgZLjvuJT9PiVdQ3q
nnZfd4iBmMAqurPRTSp9sp2o6Da9pzwWVy2MVXLovcSiY4b8IbmTCQ4jvo4x
BKRbsHvNaKYdfzipU6EydMCJFvx6P35yjs4Hp627L0aaMJtpQlZnOA9Y4JN+
rdrvyqJH3Sb3UbIjVz+DbuJaAlBW1Mw53nArK8ZxbEbSSB24LTZtHGLE3AKl
QZ0dezuH0ZGRrRjHvseNKSiHu3OTcSzMQcNhK54xAzTdLTnRDQCHYapvjIIV
cu0xQ0BhsMYiNUiINt62EdKlNhfwFV/3mRPB+6WBltmlQ42wSmaNlRpGelm4
G84K0gIcusGbkQfU05afgfihYGSjsP8jW95AzMN5p0SBVGVt7N2b5pkRs7ot
AoMEaI1GgxIxMduPDkt/dRT1OSenzEc05SAS7tgVG+/MIoPL6vFxjIpypIGI
WprUsYeRecwRel7sRlCxKqeHgRC7NolKuBQY8TatF+QCLjk0Uc1Yu0e/aRUy
Xk40HTm8FaohTx5goewK2xEjLkX2wPUlylelNsKA9QbXBm+Kfa+SLUjUXe1z
gaj/qSdfvKjWE4Yuy4uScGWbEae6BbPFh4MmVyaG2TjhfZ3tue1GS1a3kO4o
ZYcmPeJBGqjuqdrmCmeTTUidXfCXR5dXP2B17rXM3LUdmmUjwWjIONrVwEt8
/YFpH2z7ngN1ZzGHQ84BpBqGq7QLB3pVmfNJYgkDku2kgxPjCcToGkArI1dD
gPywD95ysO2YEPzr91fvyM/IjCcHDhMov+gvZ9e/SmpXySX1o91ZaZXCKJgH
fS4v03ycDoPzKdYuLkbgMB6gE7YH1no81Ko+Xla4miVqL1S8g9dpJNAgJpkJ
Hb/xp4pIdQvXEOYsHeuJjvinRoyLPR5IjeM+Soha/ZCDtrFQOjJMwrJuPJpJ
MZk6bcPvdaOcY2FMmbZBRT4sHZNqp6Gs65Nywx7gAetmZGoXsYH7Zrfx++S9
iEFm1+6embgPk9P5dVndFtlixdApotBRRD/IAQdWtQg00PMdmqkw5fdlTpU6
34OG9QvsxtPHTx+jWZ1hXsqIa+zK6sZdTO5Qz8i9CfwDb9+qzgS65U01TX7/
7NmXXz5Ljt6cn74DzkEfff31s6dPRkevT19fMHd/UyVfP/nqyR++To6+enn+
5vzqgig3nD6FdDyEDGzJqyyflfkvqID+QoRIdcG4OqK65y9eJpPkZQaiohy9
lUUAjWFODzuGX1Ztu6wxSvlTXqyzYqOvnFzWGYz99PGTJ8nRix/+NXlxnnz1
h8dfPJs8uc/EcE/f/wAWwQqsV3b8k6KsORdXJOqAqbtZncGs5nkR7OT55Rdv
Hz978uzZP3/xhAZNy2u6e28zNJ7g7cCaF+04eZ1+wBKs8hrI+XVe/zlNfthl
6yIDi2YxTv4JZBLQVglrg7P7QM6C0WuwYdKsSH7Kil8K5wWQBKdckbyWwN9n
LpoMG4Q8HdjOlpUv26B8pCnsot27i4Niazq69J6blteRSwMqSaS/XIPVud0m
V2AbgvTJOMRwtkaXRrVFJng6TX6qqsUYJCEyGQUFnVcTZK2VQu7mTdh9njBN
WiZWsixHql/QjTq9vEq08RxhvE91ozVKAZO7anfYBOIMDM11jj3o/6lq1snL
OoUXFtl+nDxPQUTBsa7zMv0lH9NNOUeL4ge4L1la6w7ndRzdpBxTKvRKGHiq
sZkz5LQeqdN6rOcAoxWmcdyCl43LmI7+P44Pipe/CgEA same for everyone. -->

</rfc>