<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.8 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-trammell-taps-interface-00" category="info">

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

    <author initials="B." surname="Trammell" fullname="Brian Trammell" role="editor">
      <organization>ETH Zurich</organization>
      <address>
        <postal>
          <street>Gloriastrasse 35</street>
          <city>8092 Zurich</city>
          <country>Switzerland</country>
        </postal>
        <email>ietf@trammell.ch</email>
      </address>
    </author>
    <author initials="M." surname="Welzl" fullname="Michael Welzl" role="editor">
      <organization>University of Oslo</organization>
      <address>
        <postal>
          <street>PO Box 1080 Blindern</street>
          <city>0316  Oslo</city>
          <country>Norway</country>
        </postal>
        <email>michawe@ifi.uio.no</email>
      </address>
    </author>
    <author initials="T." surname="Enghardt" fullname="Theresa Enghardt">
      <organization>TU Berlin</organization>
      <address>
        <postal>
          <street>Marchstraße 23</street>
          <city>10587 Berlin</city>
          <country>Germany</country>
        </postal>
        <email>theresa@inet.tu-berlin.de</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>Scotland</country>
        </postal>
        <email>gorry@erg.abdn.ac.uk</email>
        <uri>http://www.erg.abdn.ac.uk/</uri>
      </address>
    </author>
    <author initials="M." surname="Kuehlewind" fullname="Mirja Kuehlewind">
      <organization>ETH Zurich</organization>
      <address>
        <postal>
          <street>Gloriastrasse 35</street>
          <city>8092 Zurich</city>
          <country>Switzerland</country>
        </postal>
        <email>mirja.kuehlewind@tik.ee.ethz.ch</email>
      </address>
    </author>
    <author initials="C." surname="Perkins" fullname="Colin 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>
    <author initials="P." surname="Tiesel" fullname="Philipp S. Tiesel">
      <organization>TU Berlin</organization>
      <address>
        <postal>
          <street>Marchstraße 23</street>
          <city>10587 Berlin</city>
          <country>Germany</country>
        </postal>
        <email>philipp@inet.tu-berlin.de</email>
      </address>
    </author>
    <author initials="C." surname="Wood" fullname="Chris Wood">
      <organization>Apple Inc.</organization>
      <address>
        <postal>
          <street>1 Infinite Loop</street>
          <city>Cupertino, California 95014</city>
          <country>United States of America</country>
        </postal>
        <email>cawood@apple.com</email>
      </address>
    </author>

    <date year="2018" month="March" day="01"/>

    <area>Transport</area>
    <workgroup>TAPS Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document describes an abstract programming interface to the transport
layer, following the Transport Services Architecture. It supports the
asynchronous, atomic transmission of messages over transport protocols and
network paths dynamically selected at runtime. It is intended to replace the
traditional BSD sockets API as the lowest common denominator interface to the
transport layer, in an environment where endpoints have multiple interfaces
and potential transport protocols to select from.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The BSD Unix Sockets API’s SOCK_STREAM abstraction, by bringing network
sockets into the UNIX programming model, allowing anyone who knew how to write
programs that dealt with sequential-access files to also write network
applications, was a revolution in simplicity. It would not be an overstatement
to say that this simple API is the reason the Internet won the protocol wars
of the 1980s. SOCK_STREAM is tied to the Transmission Control Protocol (TCP),
specified in 1981 <xref target="RFC0793"/>. TCP has scaled remarkably well over the past
three and a half decades, but its total ubiquity has hidden an uncomfortable
fact: the network is not really a file, and stream abstractions are too
simplistic for many modern application programming models.</t>

<t>In the meantime, the nature of Internet access, and the variety of Internet
transport protocols, is evolving. The challenges that new protocols and access
paradigms present to the sockets API and to programming models based on them
inspire the design principles of a new approach, which we outline in <xref target="principles"/>.</t>

<t>As a first step to realizing this design, <xref target="TAPS-ARCH"/>
describes a high-level architecture for transport services. This document
builds a modern abstract programming interface atop this architecture,
deriving specific path and protocol selection properties and supported
transport features from the analysis provided in <xref target="RFC8095"/> and
<xref target="I-D.ietf-taps-minset"/>.</t>

</section>
<section anchor="terminology-and-notation" title="Terminology and Notation">

<t>This API is described in terms of Objects, which an application can interact
with; Actions the application can perform on these Objects; Events, which an
Object can send to an application asynchronously; and Parameters associated
with these Actions and Events.</t>

<t>The following notations, which can be combined, are used in this document:</t>

<t><list style="symbols">
  <t>An Action creates an Object:
~~~
Object := Action()
~~~</t>
  <t>An Action is performed on an Object:
~~~
Object.Action()
~~~</t>
  <t>An Object sends an Event:
~~~
Object -&gt; Event&lt;&gt;
~~~</t>
  <t>An Action takes a set of Parameters; an Event contains a set of Parameters:
~~~
Action(parameter, parameter, …) / Event&lt;parameter, parameter, …&gt;
~~~</t>
</list></t>

<t>Actions associated with no Object are Actions on the abstract interface
itself; they are equivalent to Actions on a per-application global context.</t>

<t>How these abstract concepts map into concrete implementations of this API in a
given language on a given platform is largely dependent on the features of the
language and the platform. Actions could be implemented as functions or method
calls, for instance, and Events could be implemented via callback passing or
other asynchronous calling conventions. The method for registering callbacks
and handlers is left as an implementation detail, with the caveat that the
interface for receiving Messages must require the application to invoke the
Connection.Receive() Action once per Message to be received (see
<xref target="receiving"/>).</t>

<t>This specification treats Events and errors similarly, as errors, just as any
other Events, may occur asynchronously in network applications. However, it is
recommended that implementations of this interface also return errors
immediately, according to the error handling idioms of the implementation
platform, for errors which can be immediately detected, such as inconsistency
in transport parameters.</t>

</section>
<section anchor="principles" title="Interface Design Principles">

<t>We begin with the architectural design principles defined in <xref target="TAPS-ARCH"/>;
from these, we derive and elaborate a set of principles on which the design of
the interface is based. The interface defined in this document provides:</t>

<t><list style="symbols">
  <t>A single interface to a variety of transport protocols to be
used in a variety of application design patterns, independent of the
properties of the application and the Protocol Stacks that will be used at
runtime, such that  all common specialized features of these protocol
stacks are made available to the application as necessary in a
transport-independent way, to enable applications written to a single API
to make use of transport protocols in terms of the features they provide;</t>
  <t>Explicit support for security properties as first-order
transport features, and for long-term caching of cryptographic identities and
parameters for associations among endpoints;</t>
  <t>Asynchronous Connection establishment,
transmission, and reception, allowing most application interactions with the
transport layer to be Event-driven, in line with developments in modern
platforms and programming languages;</t>
  <t>Explicit support for multistreaming and multipath transport protocols, and
the grouping of related Connections into Connection Groups through cloning
of Connections, to allow applications to take full advantage of new
transport protocols supporting these features; and</t>
  <t>Atomic transmission of data, using application-assisted framing and deframing
where the underlying transport does not provide these.</t>
</list></t>

</section>
<section anchor="api-summary" title="API Summary">

<t>The Transport Services Interface is the basic common abstract application
programming interface to the Transport Services Architecture defined in
<xref target="TAPS-ARCH"/>. An application primarily interacts with this interface through
two Objects, Preconnections and Connections. A Preconnection represents a set of
parameters and constraints on the selection and configuration of paths and
protocols to establish a Connection with a remote endpoint. A Connection
represents a transport Protocol Stack on which data can be sent to and received
from a remote endpoint. Connections can be created from Preconnections in three
ways: by initiating the Preconnection (i.e., actively opening, as in a client),
through listening on the Preconnection (i.e., passively opening, as in a
server), or rendezvousing on the Preconnection (i.e. peer to peer establishment).</t>

<t>Once a Connection is established, data can be sent on it in the form of
Messages. The interface supports the preservation of message boundaries both via
explicit Protocol Stack support, and via application support through a deframing
callback which finds message boundaries in a stream. Messages are received
asynchronously through a callback registered by the application. Errors and other notifications also happen asynchronously on the Connection.</t>

<t>In the following sections, we describe the details of application interaction
with Objects through Actions and Events in each phase of a Connection, following
the phases described in <xref target="TAPS-ARCH"/>.</t>

</section>
<section anchor="pre-establishment-phase" title="Pre-Establishment Phase">

<t>The pre-establishment phase allows applications to specify parameters for
the Connections they’re about to make, or to query the API about potential
connections they could make.</t>

<t>A Preconnection Object represents a potential Connection. It has state that
describes parameters of a Connection that might exist in the future.  This
state comprises Local Endpoint and Remote Endpoint Objects that denote the
endpoints of the potential Connection (see <xref target="endpointspec"/>), the transport
parameters (see <xref target="transport-params"/>), and the security parameters (see
<xref target="security-parameters"/>):</t>

<figure><artwork><![CDATA[
   Preconnection := NewPreconnection(LocalEndpoint,
                                     RemoteEndpoint,
                                     TransportParams,
                                     SecurityParams)
]]></artwork></figure>

<t>The Local Endpoint MUST be specified if the Preconnection is used to Listen()
for incoming Connections, but is OPTIONAL if it is used to Initiate()
connections. The Remote Endpoint MUST be specified in the Preconnection is used
to Initiate() Connections, but is OPTIONAL if it is used to Listen() for
incoming Connections.
The Local Endpoint and the Remote Endpoint MUST both be specified if a
peer-to-peer Rendezvous is to occur based on the Preconnection.</t>

<t>Framers (see <xref target="send-framing"/>) and deframers (see <xref target="receive-framing"/>), if
necessary, should be bound to the Preconnection during pre-establishment.</t>

<t>Preconnections, as Connections, can be cloned, in order to establish Connection
groups before Connection initiation; see <xref target="groups"/> for details.</t>

<section anchor="endpointspec" title="Specifying Endpoints">

<t>The transport services API uses the Local Endpoint and Remote Endpoint types
to refer to the endpoints of a transport connection.
Subtypes of these represent various different types of endpoint identifiers,
such as IP addresses, DNS names, and interface names, as well as port numbers
and service names.</t>

<figure><artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithHostname("example.com")
RemoteSpecifier.WithService("https")
]]></artwork></figure>

<figure><artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithIPv6Address(2001:db8:4920:e29d:a420:7461:7073:0a)
RemoteSpecifier.WithPort(443)
]]></artwork></figure>

<figure><artwork><![CDATA[
RemoteSpecifier := NewRemoteEndpoint()
RemoteSpecifier.WithIPv4Address(192.0.2.21)
RemoteSpecifier.WithPort(443)
]]></artwork></figure>

<figure><artwork><![CDATA[
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithInterface("en0")
LocalSpecifier.WithPort(443)
]]></artwork></figure>

<figure><artwork><![CDATA[
LocalSpecifier := NewLocalEndpoint()
LocalSpecifier.WithStunServer(address, port, credentials)
]]></artwork></figure>

<t>Implementations may also support additional endpoint representations and
provide a single NewEndpoint() call that takes different endpoint representations.</t>

<t>Multiple endpoint identifiers can be specified for each Local Endpoint
and RemoteEndoint.  For example, a Local Endpoint could be configured with
two interface names, or a Remote Endpoint could be specified via both IPv4
and IPv6 addresses.  The multiple identifiers refer to the same endpoint.</t>

<t>The transport services API will resolve names internally, when the Initiate(),
Listen(), or Rendezvous() method is called establish a Connection.
The API does not need the application to resolve names, and premature name
resolution can damage performance by limiting the scope for alternate path
discovery during Connection establishment.
The Resolve() method is, however, provided to resolve a Local Endpoint or a
Remote Endpoint in cases where this is required, for example with some NAT
traversal protocols (see <xref target="rendezvous"/>).</t>

</section>
<section anchor="transport-params" title="Specifying Transport Parameters">

<t>A Preconnection Object holds parameters reflecting the application’s
requirements and preferences for the transport. These include protocol and path
selection parameters, as well as Generic and Specific Protocol Properties for
configuration of the detailed operation of the selected Protocol Stacks.</t>

<t>All Transport Parameters are organized within a single namespace shared with
Send Parameters (see <xref target="send-params"/>). All transport parameters take
paremeter-specific values. Protocol and Path Selection properties additionally
take one of five preference levels, though not all preference levels make sense
with all such properties. Note that it is possible for a set of specified transport
parameters to be internally inconsistent, or for preferences to be inconsistent
with the later use of the API by the application. Application developers should
reduce inconsistency by only using the most stringent preference levels when
failure to meet a preference would break the application’s functionality (e.g.
the Reliable Data Transfer preference, which is a core assumption of many
application protocols). Implementations of this interface should also raise
errors in configuration as early as possible, to help ensure these
inconsistencies are caught early in the development process.</t>

<t>The protocol(s) and path(s) selected as candidates during Connection
establishment are determined by a set of properties. Since there could be
paths over which some transport protocols are unable to operate, or remote
endpoints that support only specific network addresses or transports,
transport protocol selection is necessarily tied to path selection. This may
involve choosing between multiple local interfaces that are connected to
different access networks.</t>

<t>To reflect the needs of an individual Connection, they can be
specified with five different preference levels:</t>

<texttable>
      <ttcol align='left'>Preference</ttcol>
      <ttcol align='left'>Effect</ttcol>
      <c>Require</c>
      <c>Select only protocols/paths providing the property, fail otherwise</c>
      <c>Prefer</c>
      <c>Prefer protocols/paths providing the property, proceed otherwise</c>
      <c>Ignore</c>
      <c>Cancel any default preference for this property</c>
      <c>Avoid</c>
      <c>Prefer protocols/paths not providing the property, proceed otherwise</c>
      <c>Prohibit</c>
      <c>Select only protocols/paths not providing the property, fail otherwise</c>
</texttable>

<t>An implementation of this interface must provide sensible defaults for protocol
and path selection properties. The defaults given for each property below
represent a configuration that can be implemented over TCP. An alternate set of
default Protocol Selection Properties would represent a configuration that can
be implemented over UDP.</t>

<t>The following properties can be used during Protocol and Path selection:</t>

<t><list style="symbols">
  <t>Reliable Data Transfer:
This boolean property specifies whether the application needs the
transport protocol to ensure that data is received completely and without
corruption on the other side. This also entails being notified when a
Connection is closed or aborted. This property applies to Connections and
Connection Groups.  This is a strict requirement. The default is to
enable Reliable Data Transfer.</t>
  <t>Preservation of data ordering:
This boolean property specifies whether the application needs the
transport protocol to assure that data is received by the application on
the other end in the same order as it was sent. This property applies to
Connections and Connection Groups. This is a strict requirement. The
default is to preserve data ordering.</t>
  <t>Configure reliability on a per-Message basis:
This boolean property specifies whether an application considers it
useful to indicate its reliability requirements on a per-Message basis.
This property applies to Connections and Connection Groups. This is not a
strict requirement.  The default is to not have this option.</t>
  <t>Use 0-RTT session establishment with an idempotent Message:
This boolean property specifies whether an application would like to
supply a Message to the transport protocol before Connection
establishment, which will then be reliably transferred to the other side
before or during Connection establishment, potentially multiple times.
See also <xref target="send-idempotent"/>.  This is a strict requirement. The default
is to not have this option.</t>
  <t>Multiplex Connections:
This boolean property specifies that the application would prefer multiple
Connections between the same endpoints within a Connection Group to be
multiplexed onto a single underlying transport connection where possible,
for reasons of efficiency. This is not a strict requirement. The default is
to not have this option.</t>
  <t>Notification of excessive retransmissions:
This boolean property specifies whether an application considers it
useful to be informed in case sent data was retransmitted more often than
a certain threshold. This property
applies to Connections and Connection Groups. This is not a strict
requirement. The default is to have this option.</t>
  <t>Notification of ICMP error message arrival:
This boolean property specifies whether an application considers it
useful to be informed when an ICMP error message arrives. This property
applies to Connections and Connection Groups. This is not a strict
requirement. The default is to have this option.</t>
  <t>Control checksum coverage on sending or receiving:
This boolean property specifies whether the application considers it
useful to enable / disable / configure a checksum when sending data,
or decide whether to require a checksum or not when receiving data.
This property applies to Connections and Connection Groups. This is not a
strict requirement, as it signifies a reduction in reliability. The
default is full checksum coverage without being able to change it, and
requiring a checksum when receiving.</t>
  <t>Interface Type:
This enumerated property specifies which kind of access network interface,
e.g., WiFi, Ethernet, or LTE, to prefer over others for this Connection, in
case they are available. In general, Interface Types should be used only with
the <spanx style="verb">Prefer</spanx> and <spanx style="verb">Prohibit</spanx> preference level. Specifically, using the
<spanx style="verb">Require</spanx> preference level for Interface Type may limit path selection in a
way that is detrimental to connectivity. The default is to use the default
interface configured in the system policy.</t>
  <t>Capacity Profile:
This enumerated property specifies the application’s expectation of the
dominating traffic pattern for this Connection. The Capacity Profile should
only be used with the <spanx style="verb">Prefer</spanx> preference level; other preference levels make
no sense for profiles. The following values are valid for Capacity Profile:  <list style="hanging">
      <t hangText='Default:'>
      The application makes no representation about its expected
capacity profile. No special optimizations of the tradeoff between
delay, delay variation, and bandwidth efficiency should be made when selecting and
configuring stacks.</t>
      <t hangText='Interactive/Low Latency:'>
      The application is interactive. Response time (latency) should be optimized at
the expense of bandwidth efficiency and delay variation. This can be used by
the system to disable the coalescing of multiple small Messages into larger
packets (Nagle’s algorithm), to prefer lower-latency paths, signal a
preference for lower-latency, higher-loss treatment, and so on.</t>
      <t hangText='Constant Rate:'>
      The application expects to send/receive data at a constant rate after
Connection establishment. Delay and delay variation should be optimized at the
expense of bandwidth efficiency. This implies that the Connection may fail
if the desired rate cannot be maintained across the Path. A transport
may interpret this capacity profile as preferring a circuit breaker
<xref target="RFC8084"/> to a rate adaptive congestion controller.</t>
      <t hangText='Scavenger/Bulk:'>
      The application is not interactive. It expects to send/receive a large
amount of data, without any urgency. This can be used to select protocol
stacks with scavenger transmission control, to signal a preference for
less-than-best-effort treatment, and so on.</t>
    </list></t>
</list></t>

<t>In addition to protocol and path selection properties, the transport parameters
may also contain Generic and/or Specific Protocol Properties (see
<xref target="protocol-props"/>). These properties will be passed to the selected candidate
Protocol Stack(s) to configure them before candidate Connection establishment.</t>

<section anchor="transport-parameters-object" title="Transport Parameters Object">

<t>All transport parameters used in the pre-establishment phase are collected
in a TransportParameters Object that is passed to the Preconnection Object.</t>

<figure><artwork><![CDATA[
TransportParameters := NewTransportParameters()
]]></artwork></figure>

<t>The Individual parameters are then added to the TransportParameters Object.
While Protocol Properties use the <spanx style="verb">add</spanx> call, Transport Preferences use
special calls for the levels defined in <xref target="transport-params"/>.</t>

<figure><artwork><![CDATA[
TransportParameters.Add(parameter, value)

TransportParameters.Require(preference)
TransportParameters.Prefer(preference)
TransportParameters.Ignore(preference)
TransportParameters.Avoid(preference)
TransportParameters.Prohibit(preference)
]]></artwork></figure>

<t>For an existing Connection, the Transport Parameters can be queried any time
by using the following call on the Connection Object:</t>

<figure><artwork><![CDATA[
TransportParameters := Connection.GetTransportParameters()
]]></artwork></figure>

<t>Note that most properties are only considered for Connection establishment and
can not be changed after a Connection is established; however, they can be
queried. See <xref target="introspection"/>.</t>

<t>A Connection gets its Transport Parameters either by being explicitly configured
via a Preconnection, or by inheriting them from an antecedent via cloning; see
<xref target="groups"/> for more.</t>

</section>
</section>
<section anchor="security-parameters" title="Specifying Security Parameters and Callbacks">

<t>Common parameters such as TLS ciphersuites are known to implementations. Clients SHOULD
use common safe defaults for these values whenever possible. However, as discussed in
<xref target="I-D.pauly-taps-transport-security"/>, many transport security protocols require specific
security parameters and constraints from the client at the time of configuration and
actively during a handshake. These configuration parameters are created as follows</t>

<figure><artwork><![CDATA[
SecurityParameters := NewSecurityParameters()
]]></artwork></figure>

<t>Security configuration parameters and sample usage follow:</t>

<t><list style="symbols">
  <t>Local identity and private keys: Used to perform private key operations and prove one’s
identity to the Remote Endpoint. (Note, if private keys are not available, e.g., since they are
stored in HSMs, handshake callbacks MUST be used. See below for details.)</t>
</list></t>

<figure><artwork><![CDATA[
SecurityParameters.AddIdentity(identity)
SecurityParameters.AddPrivateKey(privateKey, publicKey)
]]></artwork></figure>

<t><list style="symbols">
  <t>Supported algorithms: Used to restrict what parameters are used by underlying transport security protocols.
When not specified, these algorithms SHOULD default to known and safe defaults for the system. Parameters include:
ciphersuites, supported groups, and signature algorithms.</t>
</list></t>

<figure><artwork><![CDATA[
SecurityParameters.AddSupportedGroup(22)    // secp256k1
SecurityParameters.AddCiphersuite(0xCCA9)   // TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
SecurityParameters.AddSignatureAlgorithm(7) // ed25519
]]></artwork></figure>

<t><list style="symbols">
  <t>Session cache: Used to tune cache capacity, lifetime, re-use,
and eviction policies, e.g., LRU or FIFO.</t>
</list></t>

<figure><artwork><![CDATA[
SecurityParameters.SetSessionCacheCapacity(1024)     // 1024 elements
SecurityParameters.SetSessionCacheLifetime(24*60*60) // 24 hours
SecurityParameters.SetSessionCacheReuse(1)           // One-time use
]]></artwork></figure>

<t><list style="symbols">
  <t>Pre-shared keying material: Used to install pre-shared keying material established
out-of-band. Each pre-shared keying material is associated with some identity that typically identifies
its use or has some protocol-specific meaning to the Remote Endpoint.</t>
</list></t>

<figure><artwork><![CDATA[
SecurityParameters.AddPreSharedKey(key, identity)
]]></artwork></figure>

<t>Security decisions, especially pertaining to trust, are not static. Thus, once configured,
parameters must also be supplied during live handshakes. These are best handled as
client-provided callbacks. Security handshake callbacks include:</t>

<t><list style="symbols">
  <t>Trust verification callback: Invoked when a Remote Endpoint’s trust must be validated before the
handshake protocol can proceed.</t>
</list></t>

<figure><artwork><![CDATA[
TrustCallback := NewCallback({
  // Handle trust, return the result
})
SecurityParameters.SetTrustVerificationCallback(trustCallback)
]]></artwork></figure>

<t><list style="symbols">
  <t>Identity challenge callback: Invoked when a private key operation is required, e.g., when
local authentication is requested by a remote.</t>
</list></t>

<figure><artwork><![CDATA[
ChallengeCallback := NewCallback({
  // Handle challenge
})
SecurityParameters.SetIdentityChallengeCallback(challengeCallback)
]]></artwork></figure>

<t>Like transport parameters, security parameters are inherited during cloning (see
<xref target="groups"/>).</t>

</section>
</section>
<section anchor="establishing-connections" title="Establishing Connections">

<t>Before a Connection can be used for data transfer, it must be established.
Establishment ends the pre-establishment phase; all transport and
cryptographic parameter specification must be complete before establishment,
as these parameters will be used to select candidate Paths and Protocol Stacks
for the Connection. Establishment may be active, using the Initiate() Action;
passive, using the Listen() Action; or simultaneous for peer-to-peer, using
the Rendezvous() Action. These Actions are described in the subsections below.</t>

<section anchor="initiate" title="Active Open: Initiate">

<t>Active open is the Action of establishing a Connection to a Remote Endpoint presumed
to be listening for incoming Connection requests. Active open is used by clients in
client-server interactions. Active open is supported by this interface through the
Initiate Action:</t>

<figure><artwork><![CDATA[
Connection := Preconnection.Initiate()
]]></artwork></figure>

<t>Before calling Initiate, the caller must have populated a Preconnection
Object with a Remote Endpoint specifier, optionally a Local Endpoint
specifier (if not specified, the system will attempt to determine a
suitable Local Endpoint), as well as all parameters
necessary for candidate selection. After calling Initiate, no further
parameters may be bound to the Connection. The Initiate() call consumes
the Preconnection and creates a Connection Object. A Preconnection can
only be initiated once.</t>

<t>Once Initiate is called, the candidate Protocol Stack(s) may cause one or more
candidate transport-layer connections to be created to the specified remote
endpoint. The caller may immediately begin sending Messages on the Connection
(see <xref target="sending"/>) after calling Initate(); note that any idempotent data sent
while the Connection is being established may be sent multiple times or on
multiple candidates.</t>

<t>The following Events may be sent by the Connection after Initiate() is called:</t>

<figure><artwork><![CDATA[
Connection -> Ready<>
]]></artwork></figure>

<t>The Ready Event occurs after Initiate has established a transport-layer
connection on at least one usable candidate Protocol Stack over at least one
candidate Path. No Receive Events (see <xref target="receiving"/>) will occur before
the Ready Event for Connections established using Initiate.</t>

<figure><artwork><![CDATA[
Connection -> InitiateError<>
]]></artwork></figure>

<t>An InitiateError occurs either when the set of transport and cryptographic
parameters cannot be fulfilled on a Connection for initiation (e.g. the set of
available Paths and/or Protocol Stacks meeting the constraints is empty) or
reconciled with the local and/or remote endpoints; when the remote specifier
cannot be resolved; or when no transport-layer connection can be established
to the remote endpoint (e.g. because the remote endpoint is not accepting
connections, or the application is prohibited from opening a Connection by the
operating system).</t>

</section>
<section anchor="listen" title="Passive Open: Listen">

<t>Passive open is the Action of waiting for Connections from remote endpoints,
commonly used by servers in client-server interactions. Passive open is
supported by this interface through the Listen Action:</t>

<figure><artwork><![CDATA[
Preconnection.Listen()
]]></artwork></figure>

<t>Before calling Listen, the caller must have initialized the Preconnection
during the pre-establishment phase with a Local Endpoint specifier, as well
as all parameters necessary for Protocol Stack selection. A Remote Endpoint
may optionally be specified, to constrain what Connections are accepted.
The Listen() Action consumes the Preconnection. Once Listen() has been
called, no further parameters may be bound to the Preconnection, and no
subsequent establishment call may be made on the Preconnection.</t>

<figure><artwork><![CDATA[
Preconnection -> ConnectionReceived<Connection>
]]></artwork></figure>

<t>The ConnectionReceived Event occurs when a Remote Endpoint has established a
transport-layer connection to this Preconnection (for Connection-oriented
transport protocols), or when the first Message has been received from the
Remote Endpoint (for Connectionless protocols), causing a new Connection to be
created. The resulting Connection is contained within the ConnectionReceived
event, and is ready to use as soon as it is passed to the application via the
event.</t>

<figure><artwork><![CDATA[
Preconnection -> ListenError<>
]]></artwork></figure>

<t>A ListenError occurs either when the Preconnection cannot be fulfilled for
listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot
be resolved, or when the application is prohibited from listening by policy.</t>

</section>
<section anchor="rendezvous" title="Peer-to-Peer Establishment: Rendezvous">

<t>Simultaneous peer-to-peer Connection establishment is supported by the
Rendezvous() Action:</t>

<figure><artwork><![CDATA[
Preconnection.Rendezvous()
]]></artwork></figure>

<t>The Preconnection Object must be specified with both a Local Endpoint and a
Remote Endpoint, and also the transport and security parameters needed for
Protocol Stack selection. The Rendezvous() Action causes the Preconnection
to listen on the Local Endpoint for an incoming Connection from the
Remote Endpoint, while simultaneously trying to establish a Connection from
the Local Endpoint to the Remote Endpoint.
This corresponds to a TCP simultaneous open, for example.</t>

<t>The Rendezvous() Action consumes the Preconnection. Once Rendezvous() has
been called, no further parameters may be bound to the Preconnection, and
no subsequent establishment call may be made on the Preconnection.</t>

<figure><artwork><![CDATA[
Preconnection -> RendezvousDone<Connection>
]]></artwork></figure>

<t>The RendezvousDone&lt;&gt; Event occurs when a Connection is established with the
Remote Endpoint. For Connection-oriented transports, this occurs when the
transport-layer connection is established; for Connectionless transports,
it occurs when the first Message is received from the Remote Endpoint. The
resulting Connection is contained within the RendezvousDone&lt;&gt; Event, and is
ready to use as soon as it is passed to the application via the Event.</t>

<figure><artwork><![CDATA[
Preconnection -> RendezvousError<msgRef, error>
]]></artwork></figure>

<t>An RendezvousError occurs either when the Preconnection cannot be fulfilled
for listening, when the Local Endpoint or Remote Endpoint cannot be resolved,
when no transport-layer connection can be established to the Remote Endpoint,
or when the application is prohibited from rendezvous by policy.</t>

<t>When using some NAT traversal protocols, e.g., ICE <xref target="RFC5245"/>, it is
expected that the Local Endpoint will be configured with some method of
discovering NAT bindings, e.g., a STUN server. In this case, the
Local Endpoint may resolve to a mixture of local and server reflexive
addresses. The Resolve() method on the Preconnection can be used to
discover these bindings:</t>

<figure><artwork><![CDATA[
PreconnectionBindings := Preconnection.Resolve()
]]></artwork></figure>

<t>The Resolve() call returns a list of Preconnection Objects, that represent
the concrete addresses, local and server reflexive, on which a Rendezvous()
for the Preconnection will listen for incoming Connections. This list can
be passed to a peer via a signalling protocol, such as SIP or WebRTC, to
configure the remote.</t>

</section>
<section anchor="groups" title="Connection Groups">

<t>Groups of Preconnections or Connections can be created using the Clone Action:</t>

<figure><artwork><![CDATA[
Preconnection := Preconnection.Clone()

Connection := Connection.Clone()
]]></artwork></figure>

<t>Calling Clone on a Connection yields a group of two Connections: the parent
Connection on which Clone was called, and the resulting clone Connection. These
connections are “entangled” with each other, and become part of a Connection
group. Calling Clone on any of these two Connections adds a third Connection to
the group, and so on. Connections in a Connection Group share all their
properties, and changing the properties on one Connection in the group changes
the property for all others.</t>

<t>Calling Clone on a Preconnection yields a Preconnection with the same
parameters, which is entangled with the parent Preconnection: all the
Connections created from entangled Preconnections will be entangled as if they
had been cloned, and will belong to the same Connection Group.</t>

<t>Establishing a Connection from a cloned Preconnection will not cause
Connections for other entangled Preconnections to be established; each such
Connection must be established separately. Changes to the parameters of a
Preconnection entangled with a Preconnection from which a Connection has
already been established will fail. Calling Clone on a Preconnection may be
taken by the system an implicit signal that Protocol Stacks supporting
multiplexed Connections for efficient Connection Grouping are preferred by the
application.</t>

<t>There is only one Protocol Property that is not entangled, i.e., it is a
separate per-Connection Property for individual Connections in the group:
niceness. Niceness works as in <xref target="send-niceness"/>: when allocating available
network capacity among Connections in a Connection Group, sends on Connections
with higher Niceness values will be prioritized over sends on Connections with
lower Niceness values. An ideal transport system implementation would assign
the Connection the capacity share (M-N) x C / M, where N is the Connection’s
Niceness value, M is the maximum Niceness value used by all Connections in the
group and C is the total available capacity. However, the niceness setting is
purely advisory, and no guarantees are given about capacity allocation and
each implementation is free to implement exact capacity allocation as it sees
fit.</t>

</section>
</section>
<section anchor="sending" title="Sending Data">

<t>Once a Connection has been established, it can be used for sending data. Data
is sent by passing a Message Object and additional parameters
<xref target="send-params"/> to the Send Action on an established Connection:</t>

<figure><artwork><![CDATA[
Connection.Send(Message, sendParameters)
]]></artwork></figure>

<t>The type of the Message to be passed is dependent on the implementation, and
on the constraints on the Protocol Stacks implied by the Connection’s
transport parameters. It may itself contain an array of octets to be
transmitted in the transport protocol payload, or be transformable to an array
of octets by a sender-side framer (see <xref target="send-framing"/>).</t>

<t>Some transport protocols can deliver arbitrarily sized Messages, but other
protocols constrain the maximum Message size. Applications can query the
protocol property Maximum Message Size on Send to determine the maximum size.</t>

<t>There may also be system and Protocol Stack dependent limits on the size of
a Message which can be transmitted atomically. For that reason, the Message
object passed to the Send action may also be a partial Message, either
representing the whole data object and information about the range of bytes
to send from it, or an object referring back to the larger whole Message.
The details of partial Message sending are implementation-dependent.</t>

<t>If Send is called on a Connection which has not yet been established, an
Initiate Action will be implicitly performed simultaneously with the Send.
Used together with the Idempotent property (see <xref target="send-idempotent"/>), this can
be used to send data during establishment for 0-RTT session resumption on
Protocol Stacks that support it.</t>

<t>Like all Actions in this interface, the Send Action is asynchronous.</t>

<figure><artwork><![CDATA[
Connection -> Sent<msgRef>
]]></artwork></figure>

<t>The Sent Event occurs when a previous Send Action has completed, i.e., when the
data derived from the Message has been passed down or through the underlying
Protocol Stack and is no longer the responsibility of the implementation of
this interface. The exact disposition of the Message when the Sent Event occurs is
specific to the implementation and the constraints on the Protocol Stacks
implied by the Connection’s transport parameters. The Sent Event contains an
implementation-specific reference to the Message to which it applies.</t>

<t>Sent Events allow an application to obtain an understanding of the amount
of buffering it creates. That is, if an application calls the Send Action multiple
times without waiting for a Sent Event, it has created more buffer inside the
transport system than an application that only issues a Send after this Event fires.</t>

<figure><artwork><![CDATA[
Connection -> Expired<msgRef>
]]></artwork></figure>

<t>The Expired Event occurs when a previous Send Action expired before completion;
i.e. when the Message was not sent before its Lifetime (see <xref target="send-lifetime"/>)
expired. This is separate from SendError, as it is an expected behavior for
partially reliable transports. The Expired Event contains an
implementation-specific reference to the Message to which it applies.</t>

<figure><artwork><![CDATA[
Connection -> SendError<msgRef>
]]></artwork></figure>

<t>A SendError occurs when a Message could not be sent due to an error condition:
an attempt to send a Message which is too large for the system and
Protocol Stack to handle, some failure of the underlying Protocol Stack, or a
set of send parameters not consistent with the Connection’s transport
parameters. The SendError contains an implementation-specific reference to the
Message to which it applies.</t>

<section anchor="send-params" title="Send Parameters">

<t>The Send Action takes per-Message send parameters which control how the
contents will be sent down to the underlying Protocol Stack and transmitted.</t>

<t>If Send Parameters should be overridden for a specific Message, an
empty sent parameter Object can be acquired and all desired Send Parameters
can be added to that Object. A sendParameters Object can be reused for
sending multiple contents with the same properties.</t>

<figure><artwork><![CDATA[
SendParameters := NewSendParameters()
SendParameters.Add(parameter, value)
]]></artwork></figure>

<t>The Send Parameters share a single namespace with the Transport Parameters (see
<xref target="transport-params"/>). This allows the specification of Protocol Properties that can
be overridden on a per-Message basis.</t>

<t>Send Parameters may be inconsistent with the properties of the Protocol Stacks
underlying the Connection on which a given Message is sent. For example,
infinite Lifetime is not possible on a Message over a Connection not providing
reliability. Sending a Message with Send Properties inconsistent with the
Transport Preferences on the Connection yields an error.</t>

<t>The following send parameters are supported:</t>

<section anchor="send-lifetime" title="Lifetime">

<t>Lifetime specifies how long a particular Message can wait to be sent to the
remote endpoint before it is irrelevant and no longer needs to be
(re-)transmitted. When a Message’s Lifetime is infinite, it must be
transmitted reliably. The type and units of Lifetime are
implementation-specific.</t>

</section>
<section anchor="send-niceness" title="Niceness">

<t>Niceness represents an unbounded hierarchy of priorities of Messages, relative
to other Messages sent over the same Connection and/or Connection Group (see
<xref target="groups"/>). It is most naturally represented as a non-negative integer.
A Message with Niceness 0 will yield to a Message with Niceness 1, which will
yield to a Message with Niceness 2, and so on. Niceness may be used as a
sender-side scheduling construct only, or be used to specify priorities on the
wire for Protocol Stacks supporting prioritization.</t>

<t>Note that this inversion of normal schemes for expressing priority has a
convenient property: priority increases as both Niceness and Lifetime
decrease.</t>

</section>
<section anchor="send-ordered" title="Ordered">

<t>Ordered is a boolean property. If true, this Message should be delivered after
the last Message passed to the same Connection via the Send Action; if false,
this Message may be delivered out of order.</t>

</section>
<section anchor="send-idempotent" title="Idempotent">

<t>Idempotent is a boolean property. If true, the application-layer entity in the
Message is safe to send to the remote endpoint more than once for a single
Send Action. It is used to mark data safe for certain 0-RTT establishment
techniques, where retransmission of the 0-RTT data may cause the remote
application to receive the Message multiple times.</t>

</section>
<section anchor="send-checksum" title="Corruption Protection Length">

<t>This numeric property specifies the length of the section of the Message,
starting from byte 0, that the application assumes will be received without
corruption due to lower layer errors. It is used to specify options for simple
integrity protection via checksums. By default, the entire Message is protected
by checksum. A value of 0 means that no checksum is required, and a special
value (e.g. -1) can be used to indicate the default. Only full coverage is
guaranteed, any other requests are advisory.</t>

</section>
<section anchor="send-ackimmed" title="Immediate Acknowledgement">

<t>This boolean property specifies, if true, that an application wants this
Message to be acknowledged immediately by the receiver. In case of reliable
transmission, this informs the transport protocol on the sender side faster
that it can remove the Message from its buffer; therefore this property can be
useful for latency-critical applications that maintain tight control over the
send buffer (see <xref target="sending"/>).</t>

</section>
<section anchor="instantaneous-capacity-profile" title="Instantaneous Capacity Profile">

<t>This enumerated property specifies the application’s preferred tradeoffs for
sending this Message; it is a per-Message override of the Capacity Profile
protocol and path selection property (see <xref target="transport-params"/>).</t>

<t>The following values are valid for Instantaneous Capacity Profile:</t>

<t><list style="hanging">
  <t hangText='Default:'>
  No special optimizations of the tradeoff between delay, delay
  variation, and bandwidth efficiency should be made when sending this message.</t>
  <t hangText='Interactive/Low Latency:'>
  Response time (latency) should be optimized at the
  expense of bandwidth efficiency and delay variation when sending this message.
  This can be used by the system to disable the coalescing of multiple small
  Messages into larger packets (Nagle’s algorithm), to signal a preference for
  lower-latency, higher-loss treatment, and so on.</t>
  <t hangText='Constant Rate:'>
  Delay and delay variation should be optimized at the
  expense of bandwidth efficiency.</t>
  <t hangText='Scavenger/Bulk:'>
  This Message may be sent at the system’s leisure. This can
  be used to signal a preference for less-than-best-effort treatment, to delay
  sending until lower-cost paths are available, and so on.</t>
</list></t>

</section>
</section>
<section anchor="send-framing" title="Sender-side Framing">

<t>Sender-side framing allows a caller to provide the interface with a function
that takes a Message of an appropriate application-layer type and returns an
array of octets, the on-the-wire representation of the Message to be handed down
to the Protocol Stack. It consists of a Framer Object with a single Action,
Frame. Since the Framer depends on the protocol used at the application layer,
it is bound to the Preconnection during the pre-establishment phase:</t>

<figure><artwork><![CDATA[
Preconnection.FrameWith(Framer)

OctetArray := Framer.Frame(Message)
]]></artwork></figure>

<t>Sender-side framing is a convenience feature of the interface, for parity with
receiver-side framing (see <xref target="receive-framing"/>).</t>

</section>
</section>
<section anchor="receiving" title="Receiving Data">

<t>Once a Connection is established, Messages may be received on it. The application can indicate that it is ready to receive Messages by calling Receive() on the Connection.</t>

<figure><artwork><![CDATA[
Connection.Receive(ReceiveHandler, maxLength)
]]></artwork></figure>

<t>Receive takes a ReceiveHandler, which can handle the Received Event and the
ReceiveError error. Each call to Receive will result in at most one Received
event being sent to the handler, though implementations may provide
convenience functions to indicate readiness to receive a larger but finite
number of Messages with a single call. This allows an application to provide
backpressure to the transport stack when it is temporarily not ready to
receive messages.</t>

<t>Receive also takes an optional maxLength argument, the maximum size (in bytes
of data) Message the application is currently prepared to receive. The default
value for maxLength is infinite. If an incoming Message is larger than the
minimum of this size and the maximum Message size on receive for
the Connection’s Protocol Stack, it will be received as a partial Message.
Note that maxLength does not guarantee that the application will receive that
many bytes if they are available; the interface may return partial Messages
smaller than maxLength according to implementation constraints.</t>

<figure><artwork><![CDATA[
Connection -> Received<Message>
]]></artwork></figure>

<t>As with sending, the type of the Message to be passed is dependent on the
implementation, and on the constraints on the Protocol Stacks implied by the
Connection’s transport parameters. The Message may also contain metadata from
protocols in the Protocol Stack; which metadata is available is Protocol Stack
dependent. In particular, when this information is available, the value of the
Explicit Congestion Notification (ECN) field is contained in such metadata.
This information can be used for logging and debugging purposes, and for
building applications which need access to information about the transport
internals for their own operation.</t>

<t>The Message Object must provide some method to retrieve an octet array
containing application data, corresponding to a single message within the
underlying Protocol Stack’s framing.  See <xref target="receive-framing"/> for handling
framing in situations where the Protocol Stack provides octet-stream transport
only.</t>

<t>The Message Object passed to Received is complete and atomic, unless one of the following
conditions holds:</t>

<t><list style="symbols">
  <t>the underlying Protocol Stack supports message boundary preservation, and
the size of the Message is larger than the buffers available for a single
message;</t>
  <t>the underlying Protocol Stack does not support message boundary
preservation, and the deframer (see <xref target="receive-framing"/>) cannot determine
the end of the message using the buffer space it has available; or</t>
  <t>the underlying Protocol Stack does not support message boundary
preservation, and no deframer was supplied by the application</t>
</list></t>

<t>The Message Object passed to Received will indicate one of the following:</t>

<t><list style="numbers">
  <t>this is a complete message;</t>
  <t>this is a partial message containing a section of a message with a known message boundary (made partial for local buffering reasons, either by the underlying Protocol Stack or the deframer). In this case, the Message Object passed to Received may contain the byte offset of the data in the partial Message within the full Message, an indication whether this is the
last (highest-offset) partial Message in the full Message, and an optional
reference to the full Message it belongs to; or</t>
  <t>this is a partial message containing data with no definite message boundary, i.e. the only known message boundary is given by termination of the Connection</t>
</list></t>

<t>Note that in the absence of message boundary preservation and without
deframing, the entire Connection is represented as one large message of
indeterminate length.</t>

<figure><artwork><![CDATA[
Connection -> ReceiveError<>
]]></artwork></figure>

<t>A ReceiveError occurs when data is received by the underlying Protocol Stack
that cannot be fully retrieved or deframed, or when some other indication is
received that reception has failed. Such conditions that irrevocably lead the
the termination of the Connection are signaled using ConnectionError instead
(see <xref target="termination"/>).</t>

<section anchor="receive-framing" title="Receiver-side De-framing over Stream Protocols">

<t>The Receive Event is intended to be fired once per application-layer Message
sent by the remote endpoint; i.e., it is a desired property of this interface
that a Send at one end of a Connection maps to exactly one Receive on the
other end. This is possible with Protocol Stacks that provide
message boundary preservation, but is not the case over Protocol Stacks that
provide a simple octet stream transport.</t>

<t>For preserving message boundaries over stream transports, this interface
provides receiver-side de-framing. This facility is based on the observation
that, since many of our 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 protocol has
defined its own framing. A Deframer allows an application to push this
de-framing down into the interface, in order to transform an octet stream into
a sequence of Messages.</t>

<t>Concretely, receiver-side de-framing allows a caller to provide the interface
with a function that takes an octet stream, as provided by the underlying
Protocol Stack, reads and returns a single Message of an appropriate type for
the application and platform, and leaves the octet stream at the start of the
next Message to deframe. It consists of a Deframer Object with a single Action,
Deframe. Since the Deframer depends on the protocol used at the application
layer, it is bound to the Preconnection during the pre-establishment phase:</t>

<figure><artwork><![CDATA[
Preconnection.DeframeWith(Deframer)

Message := Deframer.Deframe(OctetStream, ...)
]]></artwork></figure>

</section>
</section>
<section anchor="introspection" title="Setting and Querying of Connection Properties">

<t>At any point, the application can set and query the properties of a
Connection. Depending on the phase the Connection is in, the Connection
properties will include different information.</t>

<figure><artwork><![CDATA[
ConnectionProperties := Connection.GetProperties()
]]></artwork></figure>

<figure><artwork><![CDATA[
Connection.SetProperties()
]]></artwork></figure>

<t>Connection properties include:</t>

<t><list style="symbols">
  <t>The status of the Connection, which can be one of the following:
Establishing, Established, Closing, or Closed.</t>
  <t>Transport Features of the protocols that conform to the Required and
Prohibited Transport Preferences, which might be selected by the transport
system during Establishment. These features correspond to the properties
given in <xref target="transport-params"/> and can only be queried.</t>
  <t>Transport Features of the Protocol Stacks that were selected and
instantiated, once the Connection has been established. These features
correspond to the properties given in <xref target="transport-params"/> and can only be
queried. Instead of preference levels, these features have boolean values
indicating whether or not they were selected. Note that these transport
features may not fully reflect the specified parameters given in the
pre-establishment phase.  For example, a certain Protocol Selection Property
that an application specified as Preferred may not actually be present in
the chosen Protocol Stack Instances because none of the currently available
transport protocols had this feature.</t>
  <t>Protocol Properties of the Protocol Stack in use (see <xref target="protocol-props"/>
below). These can be set or queried. Certain specific procotol queries may
be read-only, on a protocol- and property-specific basis.</t>
  <t>Path Properties of the path(s) in use, once the Connection has been
established. These properties can be derived from the local provisioning
domain, measurements by the Protocol Stack, or other sources. They can only
be queried.</t>
</list></t>

<section anchor="protocol-props" title="Protocol Properties">

<t>Protocol Properties represent the configuration of the selected Protocol Stacks
backing a Connection. Some properties apply generically across multiple
transport protocols, while other properties only apply to specific protocols.
The default settings of these properties will vary based on the specific
protocols being used and the system’s configuration.</t>

<t>Note that Protocol Properties are also set during pre-establishment, as
transport parameters, to preconfigure Protocol Stacks during establishment.</t>

<t>Generic Protocol Properties include:</t>

<t><list style="symbols">
  <t>Relative niceness: This numeric property is similar to the Niceness send
property (see <xref target="send-niceness"/>), a non-negative integer representing the
relative inverse priority of this Connection relative to other Connections in
the same Connection Group. It has no effect on Connections not part of a
Connection Group. As noted in <xref target="groups"/>, this property is not entangled when
Connections are cloned.</t>
  <t>Timeout for aborting Connection: This numeric property specifies how long to
wait before aborting a Connection during establishment, or before deciding
that a Connection has failed after establishment. It is given in seconds.</t>
  <t>Retransmission threshold before excessive retransmission notification:
This numeric property specifies after how many retransmissions to inform
the application about “Excessive Retransmissions”.</t>
  <t>Required minimum coverage of the checksum for receiving:
This numeric property specifies the part of the received data that needs
to be covered by a checksum. It is given in Bytes. A value of 0 means
that no checksum is required, and a special value (e.g., -1) indicates
full checksum coverage.</t>
  <t>Connection group transmission scheduler:
This enumerated property specifies which
scheduler should be used among Connections within a Connection Group. It
applies to Connection Groups; the set of schedulers can be taken from
<xref target="I-D.ietf-tsvwg-sctp-ndata"/>.</t>
  <t>Maximum message size concurrent with Connection establishment:
This numeric property represents the maximum Message size that can be sent
before or during Connection establishment, see also <xref target="send-idempotent"/>.
It is given in Bytes. This property is read-only.</t>
  <t>Maximum Message size before fragmentation or segmentation: This numeric
property, if applicable, represents the maximum Message size that can be
sent without incurring network-layer fragmentation and/or transport layer
segmentation at the sender. This property is read-only.</t>
  <t>Maximum Message size on send: This numeric property represents
the maximum Message size that can be sent. This
property is read-only.</t>
  <t>Maximum Message size on receive: This numeric property
represents the maximum Message size that can be received.
This property is read-only.</t>
</list></t>

<t>In order to specify Specific Protocol Properties, Transport System
implementations may offer applications to attach a set of options to the
Preconnection Object, associated with a specific protocol. For example, an
application could specify a set of TCP Options to use if and only if TCP is
selected by the system. Such properties must not be assumed to apply across
different protocols. Attempts to set specific protocol properties on a
Protocol Stack not containing that specific protocol are simply ignored, and
do not raise an error.</t>

</section>
</section>
<section anchor="termination" title="Connection Termination">

<t>Close terminates a Connection after satisfying all the requirements that were
specified regarding the delivery of Messages that the application has already
given to the transport system. For example, if reliable delivery was requested
for a Message handed over before calling Close, the transport system will ensure
that this Message is indeed delivered. If the Remote Endpoint still has data to
send, it cannot be received after this call.</t>

<figure><artwork><![CDATA[
Connection.Close()
]]></artwork></figure>

<t>The Closed Event can inform the application that the Remote Endpoint has closed the
Connection; however, there is no guarantee that a remote close will be
signaled.</t>

<figure><artwork><![CDATA[
Connection -> Closed<>
]]></artwork></figure>

<t>Abort terminates a Connection without delivering remaining data:</t>

<figure><artwork><![CDATA[
Connection.Abort()
]]></artwork></figure>

<t>A ConnectionError can inform the application that the other side has aborted
the Connection; however, there is no guarantee that an abort will be signaled:</t>

<figure><artwork><![CDATA[
Connection -> ConnectionError<>
]]></artwork></figure>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>RFC-EDITOR: Please remove this section before publication.</t>

<t>This document has no Actions for IANA.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>This document describes a generic API for interacting with a transport services (TAPS) system.
Part of this API includes configuration details for transport security protocols, as discussed
in Section <xref target="security-parameters"/>. It does not recommend use (or disuse) of specific
algorithms or protocols. Any API-compatible transport security protocol should work in a TAPS system.</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>This work has received funding from the European Union’s Horizon 2020 research and
innovation programme under grant agreements No. 644334 (NEAT) and No. 688421 (MAMI).</t>

<t>This work has been supported by Leibniz Prize project funds of DFG - German
Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ FE 570/4-1).</t>

<t>This work has been supported by the UK Engineering and Physical Sciences
Research Council under grant EP/R04144X/1.</t>

<t>Thanks to Stuart Cheshire, Josh Graessley, David Schinazi, and Eric Kinnear for
their implementation and design efforts, including Happy Eyeballs, that heavily
influenced this work. Thanks to Laurent Chuat and Jason Lee for initial work on
the Post Sockets interface, from which this work has evolved.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor="I-D.ietf-taps-minset">
<front>
<title>A Minimal Set of Transport Services for TAPS Systems</title>

<author initials='M' surname='Welzl' fullname='Michael Welzl'>
    <organization />
</author>

<author initials='S' surname='Gjessing' fullname='Stein Gjessing'>
    <organization />
</author>

<date month='February' day='28' year='2018' />

<abstract><t>This draft recommends a minimal set of IETF Transport Services offered by end systems supporting TAPS, 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='Internet-Draft' value='draft-ietf-taps-minset-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-taps-minset-02.txt' />
</reference>



<reference anchor="I-D.ietf-tsvwg-sctp-ndata">
<front>
<title>Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol</title>

<author initials='R' surname='Stewart' fullname='Randall Stewart'>
    <organization />
</author>

<author initials='M' surname='Tuexen' fullname='Michael Tuexen'>
    <organization />
</author>

<author initials='S' surname='Loreto' fullname='Salvatore Loreto'>
    <organization />
</author>

<author initials='R' surname='Seggelmann' fullname='Robin Seggelmann'>
    <organization />
</author>

<date month='September' day='1' year='2017' />

<abstract><t>The Stream Control Transmission Protocol (SCTP) is a message oriented transport protocol supporting arbitrarily large user messages.  This document adds a new chunk to SCTP for carrying payload data.  This allows a sender to interleave different user messages that would otherwise result in head of line blocking at the sender.  The interleaving of user messages is required for WebRTC Datachannels.  Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams.  Multiple ways for performing this selection, called stream schedulers, are defined in this document.  A stream scheduler can choose to either implement, or not implement, user message interleaving.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tsvwg-sctp-ndata-13' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-ndata-13.txt' />
</reference>



<reference anchor="I-D.ietf-tsvwg-rtcweb-qos">
<front>
<title>DSCP Packet Markings for WebRTC QoS</title>

<author initials='P' surname='Jones' fullname='Paul Jones'>
    <organization />
</author>

<author initials='S' surname='Dhesikan' fullname='Subha Dhesikan'>
    <organization />
</author>

<author initials='C' surname='Jennings' fullname='Cullen Jennings'>
    <organization />
</author>

<author initials='D' surname='Druta' fullname='Dan Druta'>
    <organization />
</author>

<date month='August' day='19' year='2016' />

<abstract><t>Many networks, such as service provider and enterprise networks, can provide different forwarding treatments for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis.  This document provides the recommended DSCP values for web browsers to use for various classes of WebRTC traffic.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tsvwg-rtcweb-qos-18' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rtcweb-qos-18.txt' />
</reference>


<reference anchor="TAPS-ARCH" >
  <front>
    <title>An Architecture for Transport Services</title>
    <author initials="T." surname="Pauly" role="editor">
      <organization></organization>
    </author>
    <author initials="B." surname="Trammell" role="editor">
      <organization></organization>
    </author>
    <author initials="A." surname="Brunstrom">
      <organization></organization>
    </author>
    <author initials="G." surname="Fairhurst">
      <organization></organization>
    </author>
    <author initials="C." surname="Perkins">
      <organization></organization>
    </author>
    <author initials="P." surname="Tiesel">
      <organization></organization>
    </author>
    <author initials="C." surname="Wood">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>


    </references>

    <references title='Informative References'>





<reference anchor="I-D.pauly-taps-transport-security">
<front>
<title>A Survey of Transport Security Protocols</title>

<author initials='T' surname='Pauly' fullname='Tommy Pauly'>
    <organization />
</author>

<author initials='K' surname='Rose' fullname='Kyle Rose'>
    <organization />
</author>

<author initials='C' surname='Wood' fullname='Christopher Wood'>
    <organization />
</author>

<date month='January' day='3' year='2018' />

<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 and catalog transport services [RFC8095] by describing the interfaces required to add security protocols.  It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and WireGuard.  This survey is not limited to protocols developed within the scope or context of the IETF.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-pauly-taps-transport-security-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-pauly-taps-transport-security-01.txt' />
</reference>



<reference  anchor="RFC0793" target='https://www.rfc-editor.org/info/rfc793'>
<front>
<title>Transmission Control Protocol</title>
<author initials='J.' surname='Postel' fullname='J. Postel'><organization /></author>
<date year='1981' month='September' />
</front>
<seriesInfo name='STD' value='7'/>
<seriesInfo name='RFC' value='793'/>
<seriesInfo name='DOI' value='10.17487/RFC0793'/>
</reference>



<reference  anchor="RFC8095" target='https://www.rfc-editor.org/info/rfc8095'>
<front>
<title>Services Provided by IETF Transport Protocols and Congestion Control Mechanisms</title>
<author initials='G.' surname='Fairhurst' fullname='G. Fairhurst' role='editor'><organization /></author>
<author initials='B.' surname='Trammell' fullname='B. Trammell' role='editor'><organization /></author>
<author initials='M.' surname='Kuehlewind' fullname='M. Kuehlewind' role='editor'><organization /></author>
<date year='2017' month='March' />
<abstract><t>This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services.  It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Real-Time Transport Protocol (RTP), File Delivery over Unidirectional Transport / Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, NACK- Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport.  This survey provides background for the definition of transport services within the TAPS working group.</t></abstract>
</front>
<seriesInfo name='RFC' value='8095'/>
<seriesInfo name='DOI' value='10.17487/RFC8095'/>
</reference>



<reference  anchor="RFC8084" target='https://www.rfc-editor.org/info/rfc8084'>
<front>
<title>Network Transport Circuit Breakers</title>
<author initials='G.' surname='Fairhurst' fullname='G. Fairhurst'><organization /></author>
<date year='2017' month='March' />
<abstract><t>This document explains what is meant by the term &quot;network transport                          Circuit Breaker&quot;.  It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion- controlled traffic and explains where CBs are, and are not, needed. It also defines requirements for building a CB and the expected outcomes of using a CB within the Internet.</t></abstract>
</front>
<seriesInfo name='BCP' value='208'/>
<seriesInfo name='RFC' value='8084'/>
<seriesInfo name='DOI' value='10.17487/RFC8084'/>
</reference>



<reference  anchor="RFC5245" target='https://www.rfc-editor.org/info/rfc5245'>
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<date year='2010' month='April' />
<abstract><t>This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model.  This protocol is called Interactive Connectivity Establishment (ICE).  ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).  ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP).  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5245'/>
<seriesInfo name='DOI' value='10.17487/RFC5245'/>
</reference>




    </references>


<section anchor="appendix-non-consensus" title="Additional Properties">

<t>The interface specified by this document represents the minimal common interface
to an endpoint in the transport services architecture <xref target="TAPS-ARCH"/>, based upon
that architecture and on the minimal set of transport service features
elaborated in <xref target="I-D.ietf-taps-minset"/>. However, the interface has been designed with
extension points to allow the implementation of features beyond those in the
minimal common interface: Protocol Selection Properties, Path Selection
Properties, and options on Message send are open sets. Implementations of the
interface are free to extend these sets to provide additional expressiveness to
applications written on top of them.</t>

<t>This appendix enumerates a few additional parameters and properties that could
be used to enhance transport protocol and/or path selection, or the transmission
of messages given a Protocol Stack that implements them. These are not part of
the interface, and may be removed from the final document, but are presented
here to support discussion within the TAPS working group as to whether they
should be added to a future revision of the base specification.</t>

<section anchor="protocol-and-path-selection-properties" title="Protocol and Path Selection Properties">

<t>The following protocol and path selection properties might be made available in
addition to those specified in <xref target="transport-params"/>:</t>

<t><list style="symbols">
  <t>Suggest a timeout to the Remote Endpoint: This boolean property specifies
whether an application considers it useful to propose a timeout until the
Connection is assumed to be lost. This property applies to Connections and
Connection Groups. This is not a strict requirement. The default is to have
this option. [EDITOR’S NOTE: For discussion of this option, see
https://github.com/taps-api/drafts/issues/109]</t>
  <t>Request not to delay acknowledgment of Message:
This boolean property specifies whether an application considers it
useful to request for Message that its acknowledgment be sent out as
early as possible instead of potentially being bundled with other
acknowledgments. This property applies to Connections and Connection
groups. This is not a strict requirement. The default is to not have this
option. [EDITOR’S NOTE: For discussion of this option, see
https://github.com/taps-api/drafts/issues/90]</t>
</list></t>

<section anchor="intents" title="Application Intents">

<t>Application Intents are a group of transport properties expressing what an
application wants to achieve, knows, assumes or prefers regarding its
communication. They are not strict requirements. In particular, they should not
be used to express any Quality of Service expectations that an application might
have. Instead, an application should express its intentions and its expected
traffic characteristics in order to help the transport system make decisions
that best match it, but on a best-effort basis. Even though Application Intents
do not represent Quality of Service requirements, a transport system may use
them to determine a DSCP value, e.g. similar to Table 1 in
<xref target="I-D.ietf-tsvwg-rtcweb-qos"/>.</t>

<t>Application Intents can influence protocol selection, protocol configuration,
path selection, and endpoint selection. For example, setting the “Timeliness”
Intent to “Interactive” may lead the transport system to disable the Nagle
algorithm for a Connection, while setting the “Timeliness” to “Background” may
lead it to setting the DSCP value to “scavenger”. If the “Size to be Sent”
Intent is set on an individual Message, it may influence path selection.</t>

<t>Specifying Application Intents is not mandatory. An application can specify any
combination of Application Intents. If specified, Application Intents are
defined as parameters passed to the Preconnection Object, and may influence the
Connection established from that Preconnection. If a Connection is cloned to
form a Connection Group, and associated Application Intents are cloned along
with the other transport parameters. Some Intents have also corresponding
Message Properties, similar to the properties in <xref target="send-params"/>.</t>

<t>Application Intents can be added to this interface as Transport Preferences with
the “Prefer” preference level.</t>

<section anchor="traffic-category" title="Traffic Category">

<t>This Intent specifies what the application expect the dominating traffic
pattern to be.</t>

<t>Possible Category values are:</t>

<t><list style="hanging">
  <t hangText='Query:'>
  Single request / response style workload, latency bound</t>
  <t hangText='Control:'>
  Long lasting low bandwidth control channel, not bandwidth bound</t>
  <t hangText='Stream:'>
  Stream of data with steady data rate</t>
  <t hangText='Bulk:'>
  Bulk transfer of large Messages, presumably bandwidth bound</t>
</list></t>

<t>The default is to not assume any particular traffic pattern. Most categories
suggest the use of other intents to further describe the traffic pattern
anticipated, e.g., the bulk category suggesting the use of the Message Size
intents or the stream category suggesting the Stream Bitrate and Duration
intents.</t>

</section>
<section anchor="size-to-be-sent-received" title="Size to be Sent / Received">

<t>This Intent specifies what the application expects the size of a transfer to be.
It is a numeric property and given in Bytes.</t>

</section>
<section anchor="duration" title="Duration">

<t>This Intent specifies what the application expects the lifetime of a transfer
to be. It is a numeric property and given in milliseconds.</t>

</section>
<section anchor="send-receive-bit-rate" title="Send / Receive Bit-rate">

<t>This Intent specifies what the application expects the bit-rate of a transfer to
be. It is a numeric property and given in Bytes per second.</t>

</section>
<section anchor="cost-preferences" title="Cost Preferences">

<t>This Intent describes what an application prefers regarding monetary costs,
e.g., whether it considers it acceptable to utilize limited data volume. It
provides hints to the transport system on how to handle trade-offs between cost
and performance or reliability. This Intent can also apply to an individual
Messages.</t>

<t><list style="hanging">
  <t hangText='No Expense:'>
  Avoid transports associated with monetary cost</t>
  <t hangText='Optimize Cost:'>
  Prefer inexpensive transports and accept service degradation</t>
  <t hangText='Balance Cost:'>
  Use system policy to balance cost and other criteria</t>
  <t hangText='Ignore Cost:'>
  Ignore cost, choose transport solely based on other criteria</t>
</list></t>

<t>The default is “Balance Cost”.</t>

</section>
</section>
</section>
<section anchor="protocol-properties" title="Protocol Properties">

<t>The following protocol properties might be made available in addition to those
in <xref target="protocol-props"/>:</t>

<t><list style="symbols">
  <t>Abort timeout to suggest to the Remote Endpoint: This numeric property
specifies the timeout to propose to the Remote Endpoint. It is given in
seconds. [EDITOR’S NOTE: For discussion of this property, see
https://github.com/taps-api/drafts/issues/109]</t>
</list></t>

</section>
<section anchor="send-parameters" title="Send Parameters">

<t>The following send parameters might be made available in addition to those
specified in <xref target="send-params"/>:</t>

<t><list style="symbols">
  <t>Immediate:
Immediate is a boolean property. If true, the caller prefers immediacy to
efficient capacity usage for this Message. For example, this means that
the Message should not be bundled with other
Message into the same transmission by the underlying Protocol Stack.</t>
  <t>Send Bitrate:
This numeric property in Bytes per second specifies at what
bitrate the application wishes the Message to be sent. A transport supporting
this feature will not exceed the requested Send Bitrate even if flow-control
and congestion control allow higher bitrates. This helps to avid bursty
traffic pattern on busy video streaming servers.</t>
</list></t>

</section>
</section>
<section anchor="appendix-api-sketch" title="Sample API definition in Go">

<t>This document defines an abstract interface. To illustrate how this would map
concretely into a programming language, an API interface definition in Go is
available online at https://github.com/mami-project/postsocket.  Documentation
for this API – an illustration of the documentation an application developer
would see for an instance of this interface - is available online at
https://godoc.org/github.com/mami-project/postsocket. This API definition will
be kept largely in sync with the development of this abstract interface
definition.</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAIoPmFoAA819/XbbVpLn/3gKHPuPSH1IWnac7kSemW1ZthNPO7baUjaz
szunGyQhEWMSYAOgZCXjeZV9mH2xrV993C+AspKe7FmfxJZI4N66devWd9Wd
TqdZX/Xr8jg/qfOTede3xaLPT7bbdbUo+qqp8zfFbdnmr+u+bC+LRZn3TX7R
FnW3bdo+Py/b62pRdlkxn7fl9XF+cXJ27h/Ols2iLjY0+rItLvspjb7ZlOv1
tC+23bSyx6ZHR9my6MvjjOYsr5r29jiv6ssmy6pte5z37a7rnxwdfXP0JCva
sjj2AGQ3Tfvhqm12W536R/q9qq/yb/FZ9qG8pQeWxwJRXfbTF4Ajy7q+qJd/
KdZNTbDdEvzb6jj/n32zmOQdDduWlx39dLvBD/+WZcWuXzXtcZbnU/o/J+C6
4/z5DHDwevhDWejztirq+Iu2AX7LZdU3LX/QtFfH+cuL7/J/3bXVYsWflZui
WtOyy/7yj4ammX5Hu1KW/XH+7bqh0bFHXVfmX37FXy6qntD19dE3T8LhFs2u
7oHH85uq/6ls17TeGPzvZ/mP5fqnEPbv6e2iXAefj4P+Q11dl21HE+fNZf6u
WzcRmGfv8ufNx/zx0ddH+fN1VS8J9QGoR18+/n3u33KQvm3am+I2RMYG8NyU
f6wuq9muamZ1Ey/hYpa/rK9WRbvsg1VcrMq27Ir4K4b74of8OaGiqiNwvy/a
xQpI/T//u8yffBlA+vjoq6//EL7iYP22bDdFHQHby7R/rIjMZv1uOufXZssy
hvnbWf6qqNrVru1CoL9tlm25TL4aQfYJDbssy3gFL8pt0fabsu7xCK2bYChb
OgbRU6+IbOgkv23m6zJ/vqvWS3tCVmtDT/KT50+e5l/+8DKhpEXTKxm5RdNZ
bW//WLZXs2K+rGfFYrb7wN8TJR7nq77fHj96dHNzM4sfeTQgxT/tytW6vKl0
eKPH9t+L9Ks7Ds8Gz88+uOf/2FcfZmU5K/vVT7/pWTqd5WclGE8XQH/a0P5H
n4/s57frortqbiLQzherplnj29Nms9314Gfni6qsF2UApb6Z598+fpJ//ec/
x6DSLD3R05/o3WWzCZG06LZ/pP8FrBmBFC/ljLhaVXZlyBfOVtW62m7z8+i7
3/5IbWXezx0pwv6PTRMSzumqrTr/IUMKmVaSIFjMIlAf00eXFbCVv2mabQDq
6Y6QRMhvJvlpsa4um7auivybr44ePx3F9XlPwqvjQ7qh07coIqwXNwTNHwsA
MVvQjmR1Q+vtiRYgVl5PX8zA+kUwbmhZBFv0eXd9czXtFv12WpOoLEa+bPvF
TTmf/q3p8CWk4fTk/el3xwxGIORpawjeRb9ry5wWNSbN8UYiurfFbn0r4GFz
IbLxlJeM+DPVfz1/PsNr7tOBOBm8kgrV+711MiO5u6tpT5XWB08M2O7gieQM
D76PD8bY60xvGRSXZGcD3PWG7GlXLojFEKFl2XQ6zQvVvbLsYkW0S9jfMUNf
lt2ireZEWKRW2EP5tm2ugCawhipUzUgK5W6ObA3dbUK7vF43N3gWXw/3O6KJ
Wf66z7vdFk90eCErutt6sWqbutmRVlT0DcllmWRTdR10RKL5Tdl1xRXon7ib
BwGQklrVrAH/MqODDI0t3xb9ihZ5SxRGB2W9vs0JsTQ/HaOiz2kr+2ojkBAu
sEBSIpZYX1tu17xUgosmIZqg+Yt1/vz8BWluiw8lwXxy9jovGPScll12PR3V
zYbAXJY1wV7TCtoB1jIPsmKNmDehvKyvK1o678UNRDx9stw29HqXr4rrMt/s
1n0F1uJGJG24XubbhqDuK4JtDBk0qaw4vySanQkNbKrlcl1m2UPoq22z3C2w
OlBEyQskRvMxP/er/KLLz9+d/ukv5xfvX55876iD3pnk89t8DhUAu65YzwxB
BKlQyg9vX/9LREubZlmuaY+NXoghk4pMC2/yD3V5k69I4NC7N0S4ZaYvAtMF
CLVYE4qqfkUr+9tO1j4tFoSPLr+s1iUvulh3+rqDqvDGBpHXDe1cQdt83ax3
bH/QNnTVBo/QYWGSuGl262VeN30+L7FFoLgOzBeblAGzxa3A1OMo8dslU0Ul
VEE2REcj40czDGhQ+cC2iABpu4wIGx8+/ubro24WIRtDVUKT7lDZcThtsH3r
/MzGOrg4PTucZCR1F6TL0lu0KBrzcf7zz//t/avToz988+WnT8RfTs+Ipghi
OhL0UEuyo/1QzOl03BA/1JMFGElvyfoVCTAcKkLXqlhf0gYsCuIWtPU7OjY4
u01P1LebV3/bQdvAyCuisJLpelfToSBO1dP4ZUZk27MKa7uC9QHDhCqczoJ3
cMLTQXIWm5DaaMdanKMmk53qemIQEC0Q6ExTLc0Z2JQDkuvoBLyWDdiUBZ/+
iYBTsJyifXA7JSQlsOCR66IlKXgbPpONHLkJlgSyuqZZZ7AScrIu1uuyBtdi
cgGFR/xK58pIvSZWc0WkviUdH6xAtz1iOTVTw3Bt+ZwU72UuBLYhAdFtq5ZZ
GLh7dQV8VPUCTITVh4IBIXy1TbFY0ZFYkSZKJJA3u570H3AaIhz/DpFOlp10
vEl0EGiDyq3wSlJbfhK2D5HCc03oVacbfPqUBfKFqONqNV2X12QCFqmW4DHa
qdQADgNJlc1hUmAY2/C7hRVx4a0AFs41IYDaCluU62lZsLBg7LqzKaxTKYm1
tFL2S+VWuQwo4LJkGuqY0zLWC5IYt12F3Wyuq6WcRzmKpPt/9ekTy6qffx7T
yhjZD/ML0lZJNVw3V7c88Vs6a8asq86YjSGXJ6CFb3h/383/naDvbGOL+Gws
ilqwBGUA7PRZfqKnjGFPHqXVQ99Q6iJTRkd/lr+8pl0JZsnkG36LaJiJNZk7
lPTr22e8sjOi/U1J8BCGO6L3qgB6mc/LhAYdHpY5ZyKyvNpRK3YcNICBmDex
oDkR9HLCDGTXKaJCsoJ6xGqr7PeCiLoXZUiWc5z953/+py3t+B/1uYND/jh6
FfstyJLDODrEbOR9HRw444l5kdG803+SD//hn4bT9sUHPlxEO9h8j85nbizC
Q90XVT36mEykYG3t40ke/DibzQ7zRwrC3kcUNrddbjNFaNeNLRR7YU+pVHRn
2Z3fjCRMub58hq9v+RUS+tU1CS7hjsEABfA+Densat3MSTRh2eXHnsjlO+gV
TE1uJvpyUW6Jt26KrWgs+KSl5eQs0EEchc5xKTTDp47my65I+a5Jj6uvdqST
CgzyGWmPPZ8XenxdtFclCbdluYV+Ce+JrNZxDBH/mRvIRI6NMnPLXLBOMg9g
gypLPIfkrAJJ4rAkY2mZQeHtJsxVac/7gtY5CU7P+FjXZHvixXmxgPpMigad
K7KHGvidooPLj+FbwhcGxOwi72R+nrgtr0hMs5PIDSt664r+WuO0A0PlZY9V
gCVFOCecEcGSpmh8gAa5Llnj4r+IPByjl+kWpXD1781O2Ow6qBdENCoLQwKh
3a7q6+aDKPqkT9XC72fveaDy4NCOF6gE9GUD49V5qRMS3g66siRW7gD49Olw
pkzaBIxOCc7S2R4AE2XbNi3rjxWRyvp2AlTIh5P83wE+o+ZW98D47Ya0z2ZB
xl3CTkGapl2FOu8sJ+onoQuTA/ZORrCSvaImD/C5j94DYQq1ms7GjuSuQJhV
NMQS55sBXyyadsmqgCgu/JDsNYvlZdVsjN6T+TKjdiFZxUrEx4O5QBlsyE1I
GEPuAEyixA7kVi9uMzB4r505NjdTs0cX9EIUozOvGP38MNB4suzHkiYm68ZT
YKBGEG8ZalbL8hKyRmR9oAI9y0wx6Ogc3kApIw1EDnu5LuZNSwvznDnU1WpF
Q6DKNZcZo9CtpFL9T46g/zwAJxJ4ppR0IvlyHPTQumSxHSq9e8zLObxkJlKj
F8KDZmgqemjOUJLrgB0K+8tDLUtJJNIalCs6c+e8BzcR2r2pyHKZq3Av4HtR
617pgx+CwWlGOp9KKK70fMKIO2+eZfDg8SwQPRsyfPLimjgSrBmj8VizobMH
Xb5ob0VG5B5x03DRNwWdFxqhrHms8KSy4UpULFugG0NCB2M1BMQHXua+PQlV
wEjKsATVXX+GTX/5UcxdU2f53Jm/KFJ5O1H5p3S4yzZckhtdJAsGWDf11RQQ
0KmlkwLxcUn61O22h3q+JUImNgB5Ydo0Nt4rfxjCdAZRIGi3rrw3hCE/CeWQ
Z9t52cHOrLoVKHxigKq9LCCCQ2/Fd+HcD5sGTDbYRlOMZTf05EfrZueNCgHm
yNMlTnPN/hy2nvi1JaycZrthZk/fiM2CFSuz68zicKaLaQHd/j1iX5DYx+I9
Wap7CBbMqE0qaAY5cBRTd6UlvgOh7zGoTpsApRzhBPHQv1fEiWl7JZ7DcQP3
3kS8LoTQmJRxRkCwlzs6esXymoxuVpUuYXxGGPUUrEtVR2LnSZgtBd7/cecg
PNYTOhuMFA/FFGpMh4Veth5jxBjlN4JCPG5Azw5hxPUtz+1AWzaluCn09AhY
JEpIlkAZPN9tNnTgxRwZ8Xu+Drk0ZiFOTeArJ3KqaABydqfn9TOu1YDnZ5EI
msFeiB0kFQFesdIgFO/IPZL7uvsZaRXerDyDAuEJBzgNCILmip+AT1W8Gt7+
yIKDj/chwAkX7PVUJdnb4PrAZXVFkrfXLRcPL8gikkqOEdBUATHz2uD22zS9
97ACVP9QFsHpiSAWO14og+hMQTGfjTEaqIYi9kcmDU+dGapsdi7FhZDglwV4
S1omSY7uGI5XhJPAJdXhHmP7oJqVM2hkiBDQBhMzx8GdiKZE8CzWFUF7OMns
aK9ZdWLWUO8fkG2C0REzeGzK9nCSsyZOB+mn60YO4/4BSacWPsr/RvwbCvQ7
qN3RFsK7Zk9B+xugH8/0gi02CjagMzMHUu0oDECI0629drSlsYZ83hBXgF5D
Khbp4LCRstL4ckIWOqDIGhhT4XEzHm4YLwIm5IwuoSo6wMtuDALeO+H9M2/l
QDtxBJfYA342N4eZZURq89tUiZnlL0X3xhLE5iDe5yyYTqyAFb1Rpq4c2+jA
knIOV++m6ZzMYC1YfFeq3MLc61LtMRDH4hFSHuSWNvQNAU8l6R/5dlWIrhRS
URCrYjWaH0r8aDHnBKsn8p2+DCk0P8N7wvaJeKYR+erMLBO7gVAUo/A20Xyy
GHmis33Rwl3R7HrT/viA0c9/25Wt7B77hfkRFw7KFskwau9jAPhxk8OoPpmI
9/nQUrCfiIxw8ACREFarA99usJoE46KAb6qrVZ+XH4n43AndSTSQvbyZjEqC
kSQTduRNQzSbv1Seyfv7Xvio+8zTAkeH6qYXa97Hz1QRHlsO2+201e5h2hYy
3SdJgDNYl77glXr+ruOXzELxOnT8Hklj+2rqv6JXyQaD0yzPk105/sf8bXkT
fXbAKLHVT1x0+M4/grNf+JLTMthJ2N3zrXNdoLyk/k0ckGQrv//h/IJ5tg9W
XY4ICWL3bNIRub9h+XRwmIlHa9GwchTpoByS6vJ3Zxev3709eYMh2dfhxngt
IrOkURahrgIAU8IagXBMjOnoWTT6LwTLlsY8YGxpszEUGrmNAw5JleK3yCBm
p30zZXH73glpVkwb9SeFcaR4scQ4XoFs/TmAt3qqMowIOdCsg4dUMgXPkZl0
mTlLmWz0lTkjWdSZohtjerljP+KA0xJUsa7EKkm0A6ZfIRNzyTYam7Kxqhjo
gFdi9cxL2pAyUj9U52rqZ7ksTh799IktMxVgEBcP83Ph8YD5pWNGPz+MeI2c
jWHUi1n6rhOz/T5ssL/dll3G4bhLWRj730ImGGqz4Z6e7+b8tnd/ODHA/hzQ
x7K6pGFLmwiP2thqzhONtcQkzBv3+ozMvSWN0sE58OLtOedMqZ/AK2D2YSex
Z/qXwat3mzkNx55iRYk8OhNOKas/V9pulVHGbI7OePLY7EdSHr4jYx9DHTwo
PxYbzZN6MP6smlcHD5Bi2D1QbvZ3AvD67Pr3J4KagydHR4+Pl/Ovj59+8+To
uHzyzfK4eEo//eHp7x8f/+HoD18eHxXjo5wRmg6ePv3yvwympwbT42+ezI5m
T2ZPHt97ZqbPdOJIUNG88UMyrdEBbUZ99GD0mf/C6c77XX3ORsqB0uYkF22d
DK+lKAcmsl4nznC421nxNSWeRrCsIHcS3LkpnD6amc/AefIIVg8m6+QazuAI
nj9o+0alI/C9JQONnUFnDTnOz/50KMMxH8k8H6GPxCjNX+FZORh0LFPO42JG
ZohrWI89A4NTDVfegFG5ITx8sJNYXoEMGSqcEc8/WDsMU6CCxUbsrqN5vYV9
J29lhzEN36yvFV6Bv0YiCuLHpWXumEyfZCameWVeeNIuasirkqgYLWncASFi
HNM7l1JdlsuxuFQE2kS9hOVG8lTwYcZP7FyEfllsYCpq7BnRPth262pTOQ9B
tyCbXTysa15qX7IDJVtW9NU1rAmVsft8qrKA9wJbuO4JcrYkuuSyHYJVDAgJ
MGQpaVRYCWSe+eMqVkw0erfUwJAQp6aANbThb08ukIeB9CyawvuBnPZhGyVB
uVgye19akIHw88OBfr/XZFo1SEcJNH2iSHZZKdKDff0CQTdey8ZF/7ZMwEi6
Ft93ZHiwYtrBYbFY75ZB1hi/iZ0LUlQcBJE4/baskSXMb5xbqotzWpx5Jz9U
z4F7zRvl0Ajp0egbl0yZhGRgX9Lso6iFp6Jpr4qaIy/YRPFoCG9kat+yZ2ZV
OOZyXsYJIqHu6cyvWY45x2J+zFlhw5X8+9Rl/FwX6x24y1mI1jM40c9HM38c
x1/fZuzVRtIi4eIScTy/kTnnNsElvmLvBI45uPzgCYnl0DK6UvwaeIoVKD/r
DDk/pQZo2WjYNl1XIWbEB9nihZ6bjpqtEqnwHC6MlvbMzzBaSIz2hn/MZePk
CBu0LgilLG3Mk3QSxQA5FgJoRN2nw7DcLaI5FrcYpqkJQPEccqpew9lmYEwS
uEzRCGadXRKR7jg/kLgS8vfCByWXc96WxYfhoXTZE8UaRvtBObuaZWJYrSuO
zr2Ak5HJGcLGj2t5RsguI8EGR03X7TZb50FE2D7JSBTmROSaahjDcLtaRRJ1
LyqiEo2Kg1FGRxUZA8gdEAVa6INDMqtyvSWJ2O1ajVpkIbYrdR0uih07ZngI
tXKD0BXAhqk2M1eXLOKgO3SMCD/73GrWQZbVknOoBiIli/1kBUcses50E4dk
EAT3x+C8qiUhG/CqDpGJ+58zVmUnWCCMpoUj86u2uK2wslJd1ZBCgb+Iz5qp
eUyLjmO4xApTTfIwZ5HMn+HUQQSj8tFhxFwssZfDdu4pzXckfTNDbgqkJwp1
+DTMafqSFBOnCa1ZqvqUcIGdt1TQzTNkXqnURGldB+9oYxJLE3PLpViLMHaX
FYnyXeQym6g3kZXMINeYmQNzQj/b4KgeZ/Ai/QckqX3xH/lLepxm/3v+/AcP
Ow3+RL/82j8yLPEBSR/iX0Q0CF048nokhCiqj/EtpV7SJsGbxJV+Q6dYoVUk
CPz2y31H5BNZLoNBDQn566u6EWDpl1MoghBsyJi5LIhuwk0RhUMyVHng/bjN
T66bapnfDa2Pkd4HYoeGZlXNq/6z2L1r9AGGs5NBMtmQwXJymBlokMMsVxVR
nYpEzQQxTjeaFSweRPeiJAE6s8thd04c9cYHGFlohGycT69LdvJZeczgLk7P
JIDrdHcNotrGei3MQRjodyICPz93Njb3Dy/OBtm2gWakILM7U9n9UKdyeCMm
8Ls9spVLyrBH86ZZl0XtUWeMhqU9B6VSo0k4V5qo4dgw59qoHESkANOycaEZ
fAg6rEvOLQPIYGfNDolEJNfbnYp0EY0SFOuIaJRZs4QGnSF4NS81F1n5IixJ
5AHFQczFumEva4vADVLJdSi3YF6a6GFhREgyOQYJGhpAEU0EutLCZT2y3RbS
pzh7aRTNPRrfihl26SwJiTLW2HVKa/xtNwua1N7NGuqatDea4SK7U9bOX89e
AfH3IlTdc/FPp1gZR3mE4jS3waH8sxinYSKcW4i5jBHJqD41jwrScmg/KlZG
XV6z5Z0idaT7JZhP8/6h/C058baXzL3L3VoSYZd4puSanhCEyGQdh2dm8NyD
eu9CJFtKnHM3ROeQgvlxLo5jtt5sNUTxu/wHEgFH0/cXF7TNkh0Uq5xibNVw
JG0kLGih9L8Ds8Jg1xWyiUFA0CC5pilIGY6se0/ugzgDDmeUy2bVORV7C8ta
ko/53N7KiHRkW18o5lkUDaXDIz5xt3tn4oOkNKzTMpFHyXt8XmoOsBrfHn9I
Lro/B6KhPrOD5uH8GJLPfTbHMsNHtkYUH7es5Iybbj3wI3beS5GSrkuAtTE/
cuAszNscTSgLvEji6nI2G40liewoHZQwyyUZHqjKv03OyT3YvGSM7kXy2yCt
g6f6COMAKnxbhrl1vwm/YeeClsmo408SeJg1gkU7IHroIRsm4UvOi10VOCGk
wRAMhSZGdXDEJRwdD/16RqQIRi7xnZL0fsh9ffr9mebDW1pP0bYoZfmtsSsa
SL0XAldj9/8D2qyodbEqFx+63SZnx7SW14DpSEGKL/X4e7SQvehTzegR2bKd
/uQiHqA7A45Ra1Bx+ikyYxEHXsCkcPM2rgQleLnhxCoZw1euYJTfXp5OVBVC
Wr7gCBmKWgqO8xhoACOqDKfzDrdIlWZVgc3ZsqDjegW9wvKQBQ5+JEGlQwPT
gs+bvbjdetFc1rsNu2+W43sNQfmhQvLaZeLv8KYf9gl+vkn+Y/WqmuQvsU/0
FHuE3ly8nKi2BoHBFhAL1M5bzKFDhHuMMAPrrUrNVQnMaBX5FZzwxXqSrKgL
8h52knOBImy4vEWV/avY2X/lff6rGcp/HfhVZs61L9Er5zulcf6q3ovhW7yY
GCIOc3LMKLV1tZjhxmreueyUyIrNaz4zJtSujWSS477rLMnP6QBu7iCcaEr7
bdeXGxKMdFhvhTMU2wLF+TAtUSZ+T3oYunvLj/Rl6BNg4paWDSqnL7UgGJb2
2J7L+lKIzK+dy0barjq3udvOdCeeqb42HiGg8epGwgTmkuBGBwKEN8glnMHk
Rz9WEvcdYo2GeyFbAAxyI6uIKW44Dl03SdxZEwxhHQgCyyVTvQ6vQCFcYbU1
zNY31U+hf5vV32XZXF6awsWMZY1qGP6HM04KOVeg+jn9dVMtCYNeEQqODZfk
KBe2qJswGSMpzji1sFQu9C5Z0Y/eNDf5m4LDDuOoMGeRPD9D4HPbYBugEecH
a3n3MIBHl2xFSJyDQ9iqJVQyuhhJmYqWrhw8dKvMb3U4PRh0oEw24dNFUxBF
LLSww2nu3QYhJZcmzMUdXI/actWNdBU4eFuQpvoF3BhXTUvEujkM2R+am7RT
Xask3E9YbtAOF1y1FfkTo8cnXOyP30nBldpHlT5I7GlyFvqsh6NAtc/fc3u+
sa0QmtOOJvXykboCRFss1J0lg0ghHWmKbewpiSPZdAiA8xHs79lOZRSf2U4T
vhuV12aOBHCAx8JfCQ5oIdYOAW6BnHZdm45sUAlRcFSkWLSMQSTF0Q6gZMHH
+XIekimVNkP7kaQnk0NDvFUmeat2sSNGz1ExxpX1Jvj66adPUnwmqFwWW9A/
MExUZJoT1LQ1+4nIMERdLn3ZPnq+W3/Ye5iwruhAve73bmwhhApddIMWWL7A
x7QMOLV39IjHenhgfOubYTGf5A4YzHEdka6MT4BReULjNBAdtm4KO2Q6J4xM
af85sX+cwEkDsNixtu6Io/ijLuUkBzmIZ2cuF0kL+sMg/yM6gnfG+TUR2YCY
YkaJn19Y6aNzGWtRJWo+vGvBhflcjC+L4/+IBYo+oAozvbUxJ4R76Y4ck+zh
w4fj2QOScyHpBaOhft/c4Y6UfA6PrWUVGRv2ca5zOJfTdmIkjKWCaG7i2FiS
ojbyzUGQIf3ah9u2ccIEe3yIhJJGQKMAz7IfVzjuY3tvKthfaay/cqrSJMRz
EP2nJzMT49xIwCWnqGISlTkPs+H342J2slyGDSZYaznMRh9V1fXAH7/D0ecE
8s8+JpGxzz7Gka57zCnaePQg7yVS6NDSC2UOsbdtkpTvBZunrAs1HYgagLdB
ycjmYSaE1/U4bXBQbeM6jdxFiIEW+23Z30GTPvGEMzDCTBi4YqDimgGtSYb7
jjSrZFihCjaxCJcipO+q73rm08rCqLNiacYOyZ9/rsCxQa0YQdoUhUNecTMy
+n8U8WXFqjcambHVapVdsjq1SjIu5YpPPZuKXIZH77sku40U78FPQ4JuwWml
0lVDKmc5bTxL0sbh2xpkplklRZQ9BXvf+mjkPz8cKyfJslMpLA2YiGVlX7w5
J7m/hSlLol938kPd3EgvjDgjZZafco1gl59/9+6HNy8ysA8rny8uk0CpZI6r
DQKNHNvmHJtB94kCSa7dYtd1VqL62eaFnz5NpMlXmMzp69Q1xcNcLJatkY3V
4aRlpq5bk9RDqp4nCj4K1+M0GyJjV1GpvvSC21t0K9RVqQiNX0p4udV4oqie
j3MnpzUqnAmlxvALO6COQvZPCC1E8iV37PCTKbnng2Rkai3+rSYjVtcQzR9K
lJj+oPLOej8F3/pcQFfAfs3pcF90mRtRRVWS5Tkje6NB6k11Gc3HyGGHlblO
Juqh6Szzh10rWdc36if47vx7JJ4a+n2HGVe7s+uMS3DoParRONyHd0io17qI
A1vN4Z4Hz2QJfypvD7bux0m+3REHW9CPrsPTufUM82ZWgGMytMVHdwN+m5CM
GoDjsYThQYAGUAqvdek5Ez2ffm491M5J0zfKCIRmRo63mp6zkCFpZupxFnKV
iW+QJv0GNIGZ1WlOYPZgzO7aBYczdmwePHlyiPSTR4+w6O2Tr37/4fGeF089
NAdHH09PT745lBeJAf7l5emL717i7/OTv/z4+uK7v5x+d0L/PTn6y9m7N//j
8ZdHX/3lnH796vf7oLJlnNgqDv5wiMHL5ZOvvnr8jdtxjT2iD0bpt7rf1aV8
5my0Sb6uLktpV0JKK+33hPNNyutKzQK4wdgokCPx5v0PkD6vXr96tx+B52Wv
IJxiNvMEHTw+evKUEQmY8UteCtvv7jHKGwX04MnT3/3+iP7jldMYZJK19xng
fUnLO3h8GGQY0QDv6nLKPBeKp+IP9baaBkwMght1IO+UVFKPTO5sJbm1e54N
1YmMzMZpczmF4T7LX0puzt4Xq2H3Mk4v9AyOjfvbrfaWdWUJHbqWSXpsK8Wy
eM1ZXC6bED0og2ZJKaO862QQbs4ZajCeD+A4nlHFsgGhiE6q4ErV6JFbJZEz
mx1XH0wcB0YVbrWANEMnXm595VWhSZhWzAlUbIrOpZh+XfkUoDXMeMedO5OO
mAVGs7YAgyTMRPhOXemA4+QzrwaN8XnHfohcLrCInFQMH3azB3EzA9p8WSws
RfUXnaBA1jNX/ylvu5qt8P14AJwFv5B4ExLbnMVDQ5iKphLcfj34OWNi/44X
bljXflqgAJIC8Ix/GhU251DW6Y3/HqzQjdyH0zqZY1LMtyDdj5JR6R6XXwjv
4WxrSTxFW27MsIgeLrnXCufxSm6toubUgLgfehzM+/Fh6xuMfLBIP1GcvOH0
jBHPwWS0ahu0qvq9p2vV5M2TYpo815bkrkFAUsGbZc+FkiJrJ3RYsW4Cb6al
c3CjNqPIgIvNsrgLATeMvMPh8YzrCvyi2RiLGjK5FSfN6mxyy42z05D0WZIu
2PAdecxFDbm8L867f86sc0taPZKZuhGGW+IVwwGGpsysigfhrrACW3pCPMu0
YUn4lCu31mfAprsKTvOiLlHtylGWoFJaX9aigKDu68RHg8IWpa3va+EDWru5
Nb4QZVQMvhNeQ/5uW9bHDnyy7LTQuPwkrTShXaPfhjYQsq6El34rxBYJOy40
I9V3iOjsNlKuThj0PV/2FNXbge5meQKGKaULtRHJklMuLn1goiZag7e9gsip
fGPdhpjnOoycWOooc5KoRUJcoh6U+POJf25+R+lWaV+LK4ar9Vqhc05H2Dbb
nTTFSqx968GqLYRSvJqiTaQiyQzazzqpuHSP5Qdk/gw1dIvu8OlB+HGzZc3c
1UegzQ5ptRz3icc+jMq+WCfyHmPflA777A9hUHVwwr6YIZrqJr/ctfCRRIJf
TmBUrZ+GR4PDuJDOezVor8uGDlS2yq3n7tChNWwmhURlC7LaUVmyqmJdgxzl
uKJM23LHgQZea6xqUbDiVrPyBsdM5t/wngnp/xb1WGnCDk7mK3flEUmViXYG
V/JD9CbobSkdJy2txEXvBu6+LCiEs/4Lg13kDXiW186ZBz9KkPjIIqfj8i72
GycexcoSmgMBZLvP6VpxliCQRoC5D30d0CB/XBv1hGNpWm8wvawnoCS3m0NW
MP0nOpbF8tbaI18wt6YPtP0xd7fokiFZPw/XVqS7HHQK4fTXPl+XRdcziewk
AruPpiR1JHwjiwUgh8u12awhJGqaodvK/EC7czA/U1HkFxe7X+MlieSzFc/G
EGdfcusnQ+BJHX9uGFSXqauR1mqtSMOIWz6GrMPHNy9368uKy6WbJLtSpJG1
2pCSvGCqzDfhdGoEAl9pa1AUAprQD51+cDITZ709RGtj5isLrnD1BY6i3sqo
See27plfuX7l2HrmF6elz0vWLm7EIXMHAzFVMLRWlYkk8ys25qVwqrEnLPVr
wb0u0V0sbIbSDBPhJNWM4xnWfk7bu8X7Igc0U/sAmRUsr7Ss+kxULVVmRMsi
VUaUDFJk7PtxTeamECd6SskMTboHk0wc0VwoKlqEqB1SHHmHIpIAkd1TE7Hl
RHpIrHm4BkVjeod8uUfrEFKXZrQD4Zip2XFXSFO1kqTIPlBKVDXIBqpBHqsG
aTu7QD9IdR4OQwfKTtjSYaIBYDlx4tSM8hZhCDF1wpy5GOrkTlkY4mOWs3x3
L4CBz5FIZFLeayz5ZzSWJJ4DtlU3GWvqfLVMEsViLUbH4cSjPT2SBqQBDuuX
r/x++Q/+o0BiDZ+Lxde4B2MoxrI7eA0vnyg9acgYn7xp01ZcAjZ2zYn0wHB8
UG4EsUIH2xFfr2NRlkHLh2ROpFVEk4DHCRfCZSWxdTMnaSrqlmhT4j1J7Bfo
C41l0Wgifz+K5qy8dpkb7MmAcNW8RfbhSZ11NZINELJSxPqwUh5tHzEI8cbC
Nvxwn6QdKMEDSYr0FGfVBX1MEtZwwB1Mor3giIw7wYc6ehaIsnjPPyM/vGlJ
fNWlcUJKqGGNf2O7/jjsSPbzw6BxR5adh/Z51MVsb9B5aGaC/gbW+ygvD5/z
Z3O0AYg5SZJSaG5oM2DJfNtPegqE5tiNGuf8SPuroVsK1XO61/sZ9sW4s0IM
nBG+CnVDNs34WgL7peQ1jHkJ9p1vrltCHmKwe1ywdKue5z2NejFeNgLCPk+5
ZH81bcsJmku5A4wvuor8OpD5UReZmVkJI2j6nACKXiKWlzHL+68QQhnSfX8T
IeRhfkHGyLgASp75p1Hxszdjw7dLH8R9X42Ll7B/gpaDBFP14Z15Q0mWpouM
iJOwPUPVp4MnoissMnWpAYOVEJqyXyRtxnFqsib7O2WNjPb5PRd5s+mu3peX
E6kE8pZe8tivlkDsvr2HBBoKoHxoPE2yX2U57eETk+wXyC8vfSIBxqF10Ums
+VQ+0nzKgiWvT19qWu1XT55+hTwWuXzFUuh9gnCCHvOfL+JGazKptt1C7b92
7gI8AGVesSvIzV/k5xc/vFXbiGtRNDm4Ew9olkwLxmJNu5iHbqqPdjWeM4p1
OOkb8pHOSha0ahMWkjQIG+NRSbauW4rGEmwlY+L5uX439P66mUN+ZsAw65Rw
G9yMIFK+BGtEqjMrKoLee5n6EORqqKC15X6sTHyT+CKSFi7CEc/MW64SeF+P
W010ZtC1WYNnD4V0UZdcNcldXmunBqZKf1fO+eszHMAfy/n7i1MYa671V+hQ
EH1tUF9GqpnGvLJMP0mxyH7A0OBLGtz7WMwpWrLeoYkNt5jfICQmUYDT4RNM
AqeKBJkodTTdVqXcJsgrYi/WTVRiJ9dVonkY0UDwottaGfem8F5m68vrJQT3
nU39410Z9eiGSfwAuXcoG14+kNPO7UO4NkirYXBnE4PTpx22pWftLB+ut771
nV2T1YGQ+ZqDVdUuY/OKCZ7HDJPZk7tCxmqiOZtCQo6rsmqzMKWdHYNI/kw6
uFTi3o6xZJEz2RrJGZXggSvzkl6G2vkFLuaR3Y7JyW14evbU84fS7ywMC7sO
X25v/MNCFvFQx7b0LKL/8GYHP1JyaIzp+wegBPDe3WarYilWtXUxljYl/AYu
3YmaYKa7Qqh5uTdSqDdUyLhjTAlSmc2GaE1AvjXb2LMgCYpEGhqTNPhQeJpG
otzETrENCIgQ1cnm2xKTPvMJx0g2Kt1qXq2x5QAGqPDFWlQxxnOs1RIaULQz
dsCSCUQ55w6B5jG1uJ7ecCc3+khxCYuZ1HHtr8DJwtYCKfat7Kgf7DfvcWtd
Cf1FD2E3OjF+WlZ62ZOK9aRlA77cE0TgUEt6DF8HIhoq7v6QzeLeIAEwZ+FJ
He0n1kXH/Dirq0VZo9lc/lZ/yrlVmV4zop0n7KlPn47VJFlDEEv9nwUH3D3g
rhZKLpP6LA+b6C2cTR2lcDA5SUGbB84ynq1Wpq2QE8iuXNZmxkaSGl+ulEsH
4hZPFW65DnM8hXqSflbS1QLu7Ks6uTlC3cy6auHIB99P3x7mH/PT/FH+/UQb
T7w1P7x/94sui2Ga5N/bU5viI9nTmwRo54IH5xvurEgmyV23geTSaB/GMViD
PHE8ZtuMuA/vLanOW1JSEFtfXlddg+bx4rbNr3ZEgWRQala79OCSolW//0ol
msvNvCjBKqrbceV1mA8Pd8FizzBSRk+zZpcV1y7l5xq45XZKyNGX6OzYbTbO
UxrdaVP1eZoYFPYYmPHIWdW5oKld1Ol7zdgdq/Ar+UbVQUZA0j7VOCu3WnV3
XnIZS8AFPeSD6OsMbx7o9HJ+fK5WoI2jfbyVAsd3aaoey4XlyU2p8RaJj8SI
fHhlVMpMpRZzOYwuE6WP3hGJskSOyfPds67KDjUdbVuwNtWQ8dbbBYhhmxJl
ZiNNfrbF7bopxIk61ye4VbO2SbDhMz+89sJE2vcUdTa5XKyw5/IFIr7zfe0v
uUN0iYxMUphaMnNb6UHZMaOyFAO5qqKRZA//rovjhCzANg8jRI1eZTJ3OU3m
EWCy4PtkiHMaApt3rtdF+2yXcEKeyESWK4GcB7I1TSULCIl7GvhLxXjCy8yf
l+ie0XA/C75qDgEucWCpVYj2PJOQiLNGTlzsrOEVFV4tMJALVuGRZOxOjDha
fHNA05BvVs3a+oX5Qy3NXcLCfLY4uNEGKpNve7kNgm/gZo2nkt4WtMLG7vqx
WmDOxVSIpTpcZ1XgJEIXXM6UAO+4E6dLRmd16rYAdbCXghDfJj01x2QbwBWh
bdyW/Qh3JKs3yQpzwtd0K0lw1vY3ie/ZKe8AZZZpIvmVNGpxX772CTKObMNT
F3a+OpyYU4XtcZ/xiNJy7JsGcGM/Lrh63KOMU/Os0WCWcrGoKy1LGs5lhcg9
CcVtGMCeDHg657T7K7tGc0Ho+V69hIFbGJ+OuoKJXq/5jpBwHmyhZY06ZdE5
dAUrfP9t4GYdhA/1LC1RlcJHz0fjfSlMGgHR8B0pBDCKtOmPxAW6yrrqjV1A
LHfqhugTZ5bI/mVFI3SVJSuE8DqP4hBFyC+wbH89YMmk5iz4vBzL7pBj43cd
58m+Ldz973WWHFMHpS90V3gDIa2mcG/diCBw3OidXf8Zd6hCs+W5iU/eNTRp
WGqjCvbDcnk/pN58h8bBrOb1lg6IRbD9weHJtP0VVyanNO4avElGmrULCPNL
igAtrG8xvaqNzp3GBBbUl+iFn9lAHUf5/2C5AJaNqarruBuLygBOOmPy0nyt
qi3Hj9/Lj1uk2w9PoH5x/0NY6gtWei/nsUJWNN+96AjXUbIyXtEr5S2ITSv6
iViglSwRA8x0Jt95ytmDfLoBFEcVJj6qUdSujwxNtSoIfG5Cn6lwWd9ag8NA
o1GajjHxG5D1KFNchvETF7V3XyQ7YhNIr3KNa0iDu53pe9KMjeAXDf04AzX5
rF+WIKmOws2UtItLUpnHenHCDrnPGuopJhI6sDb5eviCksL4RVEWMrtdoORW
FT4A3fRS+80XA3ixOc6TshGepDgL9i7VHPbuXXb33j0UCyy+zyM0dpw8cwdF
rt4J25qmC1b9UJvTrYjPARD8XkqHSFFAZH+1nPpO/Arj94pmoB4FgAedaK6h
rC2XGhsofE96p0ES+XNWo0DhazrUFlTltlhIOY/mHKxd85lk7sye920nij7I
x44tvGSStjTLNTPd0KcEe6QFPtewmbYVvkUTWDF0+OHBYfLUnuYSoRKT4Jd9
1cPrRxxsoz0DtPJn5BJI1xCab/3kxUUVNRwoGTbmCJtvBzvd7Om2O7gRRfMB
wts6Ai914GO/HNUswsLi2I8URLDEoRIEyqWFcnhhVEZmCXIZSy8x1HHoLi1p
Qt4o6dHhfFGP9yxqQmhulYAhVnxVi9h9tsRRHGTBNgZdTgYZ9S48oLx5kLSe
8gWQj0syOpbONW7tynacoITKrl/5/nTgJey+V5twsSPW7qUHQQLFRX0kdsF0
zwkIcdKvk9fctqwl3JW4bt3cY6oNa+Nt9lsctOX0MORB+Y+R7Pqii/bRNjes
S4t8H9aQWJg8e3ow+a6u5AJCNxjK+Pdwe+3+4xyMikPn7828czK8rBa6JWfV
EBirqmyLdrG6lStExB8rxO8dHQRrgYokGMkSxHB1FnKNtEaiB+EUTQofhL0G
1YDwIuEiD/RO4Xpx1WkUaAnuFLQ19bQurxgYNj2u0FPrJCZyt+YjETVMphLy
HX/ucdgxOvvs40+iGJ/7WNkK8/JC3PzeF9UtyBzfcShEjJedXtxgHi5nCNtd
x8FWiB14g3Ydw7TjMP7hHeoWs/BtadRaQ+6F8tYaTpE1g7bRC7VIyUSoPhjq
lrX9AtKbOFoV2vjH/pkKoX6+jazQe78dWoAqo+VsWcpzSrjvWmmHo3TbyK9w
/uoX3B877VVLxIL6iV2prgSnhjj5r847a5qTia8myFxKmnQlVGuZQoHW8wwG
1WWxRrOBaFLddT8jrCc4JbECXWbgH9GVBh4RUmX8159fb5SKo+k9WresAYRQ
6KAzhenGewokNlKxDVeXdSU0EZ8FCLATanS6KdoPWg6FSbhSThtMi6MmcuBk
fblY1RWqIy2YEnfNNmEr7/K4vr7Mg50l1rL1vwuNlLQTO2/Bqb+XAsdHN/pN
WV8RreqmWHdd1nkhitEpFQW/431S1/Kyu95tMeLumOCSbjmabNvB1ZgfTfLR
xut8HVYQHXO5dXa9RnC5hppFEhVTKuDrrtJ9Mn4itQdyyjsWJxnzT9cNJaB9
QwQN9txdhSPEB1Jry1Cx0XfLJbpv2ZvQeSXaRfg44t4NqrfVje9iHNXLs4Zt
3VAzeVmKd6aPD9Nmhe7+hX7lWq8g05RkhnRbtibLVZe5UBdPcqsCzEp1pbpC
w2N2Xq28kGgfbV7W5fJKQltKKcR2uQTRKGV/N212xNjZ5XrCuNd+IXdoEZhx
fKfwEy/jcsdbPQ5MG5Klxt2UCdHmAsjCkzUxzg8Pb7cv3mK+fhZZuYRPiGEy
75TL9LADOITJaVN3eac+oGf4srU2EGFTbu1Gpm3DOe9R2p5OF5BYnBcWxkWk
l5o29aSzjDvXzKQ0fYNFrHmfBvWdtpvS6VSzmtMWv7qDv7Qtsk8VsBa9XWTA
hTLimTlxIutELRfnXBgAdo/Ol87NPmZcpdr4aMfju5Ez7H/8izsWR/2KaYhf
37E4QOzGQi2f61H8y3oQM0l9tmntaBfcO2DMx/oTh46oX9CdmAYb60/82e7E
d/Rm/a/pQPwb9Qfe3y53qIJ1QUc6wSzhYV1WuBnJt7zlG168dBzHy+c71nLg
VSjadn1HonGt+FxwD0iptg0b3MeYVOeb2QivJDhtQsZi1eLACIPabNiL06Sw
+khplXut/vegLFPTuuzaziy4PjvwLVi0gPhKy5JvqGU6E9UlBddZEuIXHYHe
oH+mbK8kbdFHcxngctXIlVXxxiYO6zTqqJAkNsaV99bpGtUxJQrrJONngrsw
7SWJsjqHhuOzYrkN9TJePpdDsKjfV42Sf770dLR6iqHCjesHAt8hmT/A5gnj
9vgfFWx5zpJGXOOqIWVUcr+qmmsg6LLoAy92EPDk1i0Fq4CcZGVaRTxgVGNf
xjkUD7UgP0jh8bX4Y0k8cQ3KxLMzPcVO6cWz2vkhjmLVofbnLvp1VSFmEriB
oZZqFqJWLx4cDp1ZgzjGzB7Wf6XRUovemh/FbtA9sI4EdqbS5322xEpbWXGe
fVSuqoFNG0vc/eJUk85rnI3f+/YHdiM73xjBfRbYdYKkxLhEUxtSBL4wBaN1
Vy4nnUx5J5SXZBEdKQvpIg0ciK/Y0g+QX5hgQoqMOMIy0rDmuBvEO5aSc4s1
xi7hYXjU4EIWBrsq9BbjWK3lzuUik4U6ECVqNIsHXlOjFqN4k9YwFw3FUmIo
m1q72m2//cTZr3YqDZLMm/ygqjWtRBuxH3qeN6ymWexapEbzLZ4IBVqXS4Yj
vgtM7CJug+vgCLyN7CoIyw4DQ013hE190Bp9zwDbTZ8MuEXYxxKX8sYVKbPy
MIhhpUGxqh/asuzGS1JiZmH3ZLesZVOKO9wZcONmsx4FcwQUqLWvbwX9lg8e
S+FniYiUOh5uLJdA1mWsdhnagr1fkDG+1LrMJEshyE4YjY66knadxKKj1mpf
9Altaf8rMgCzkQxAY3i/OAMwG49SDjInQmUsardPDxXsz+EyVZ8oV43N/ky5
pXsJvMDlvVYpiWU+YQp2sA8JuPQZZ/m6wxboYpjfeSmw1pfazhpkbZc3RFeT
Hbw8fXtIDA0e4qh8ES2IdgHgWmUbzp1mqa6bqyu9gYW2cL6T37a7dtt0Vv6B
YzbfVWuJ5YTmseAJAQq7tomZ8liimw8t25X2rkttRfwY+ULWwlCNxiQxNr75
N6ipYy7Vt1UJdlmLEqh5mYqaBG69lMIXH+sJcjLA7lrz5aDZ3qgwLqMXXWSW
a3PzgY7CC2WBhxCZU5Fot6p+51BZaiVXEnXWJXeysGkH/X8ToBP++3GMef+y
E/SVz/ESXxfnSk7IbODCWy6PkHPuTPbMJTsg8rVednwZ8N2Rcg0GOPtTFFZ0
LNkG19Pa5WK9z++MWMxQXKiXJTyOkas4twmffRZEx9gtQS8FVe7JiYE1T1+U
0ztUSa0s1mXF2r1CcsMZizadzZfVqQNJgtma3xQICzqDv82S6saviK/ZtZ6w
wxt770tlLAydbjZGVERDj2fKGcVSUKJ0+/ck/NoEoi0oPNeh07uIji79Kv2x
B1R4wC4dG1X4IHx/Pp1Nr/OcBJcN3I18TesxVB6OVO7eA3McblCZxUQBVz38
etqva6V5xXZfSpLVG9Svswc6SDSx/VA/Ub+y5DYp78g4MnXAnpcOHZcx5eFg
gj2DL0PlNBtkboWPg7Sl+g3Cgun6y3tutVwzio0VmpW8hXRzJXVVfQCkze4h
gcrufMfO8imNnANBlWagF+ryi3nHy4Nn7C4GF11LLpThdCqNYcRGaRJqxsmR
rDGbprkk8WlsBYdL4j93aXhJy5rIuAvz3/bd2L2X5DNLgfH9BDhaLqJ4KZdq
8mkI2tCw4JbgR0CQ3FBBp9V0fe6DpmnJyIDjWwF2ktFl4kj2hKT4NZ1eXKu8
JouKqZk1jrt2VdJA2PHmipv9t4IddCqnAa1nYzCeuB3gOnsfOSteOCkg0YFz
EdZnTt80x0QZONYuvCWuhrhmNNeaxjXnlhfaLBPu+xG/mNU0hE0ZkyDrs7gA
0GWROTe+2WDOJpEdtnxYMexVhkXulE2xZc2P8661KtFWpNaAu+LdJ5y6BCM+
0qPJ82Zof0aNgH2vWUtsXnAkCvgfGzQzHbLQEKRqjKliNZNrgXQmzoeLoeCs
CK4XTN7sJikenQ4X+7aWjgwUK/SwpLvDx1fI/aLCyeZuubwpdsXGRkvFm11r
Bnyk6XpLh87I+toqHC9Oz9QllDmlwdDyeZUtmbu3S8hkpswudRlBV984/81E
yooHLk7vCUV1r7uzCpbiTe1V7RNEhERp2e+m2XUrCWt6REuqJ0ctEjdkVUu6
hHTX10ovb1DoJuPNDDoHGv2ICDArfcb9DbjbBDJq9m31vZ3mWeI0z0OneQzW
RK4K1Fb8A8adpT4ReJ662I1uts9+Zzx7AczlEqUMIDS4LnogTAiE+PC1Riwj
7FlgpNduCOAMdfmxD70KKjNG3O1ux+90uL+w973L3b34C53umTjd89/K6a5w
sdvdYDzMXBD++B8d5PboATvlz3XTZ7OZun8Rw+ntKtX8z6jk09DdsLIbBxHd
ysMbuEiYnUifYW0Clu4x/AZQQjG8KxRM8lSL0HFNoG81JmXYXul9y4nSU2lZ
XqBypTca6qUR+bK6ZNWyD50MA+UnWOfg8jT/nXUbGRTFjjwTALyN8lb1Kovf
sfcJl3DsuqGuMYlrFcftoTy6h2Dif4P2dLpuOv4UaYz0Myef/y7IdH4l0RU3
uef7oqQ1jC7fZMknlNPEZ76P0mjSrcG/4fSHeXCfpHKa8F5TDSfriYiaBVrT
/UsD1ntgXJsIh10aSvTzPdcVSmMSThiTTqZ2w9zdiBlVM27genGLEqRUEl3m
LuV6o0pCumOV4OkS+Vbj/Yv8ZUukwdw1eq9FN5V82eQKars5yuGZO9ZaepBk
YPAKRf+mbTKDUO+3Z2d1hBR0vfY5nNyWJthzNxHMVwxgpsAl3yDR+5z6MkrF
dquXOPwe1jnLo4x1CE7N8fOb6XJSrHsFe1yGqU4ejKJTEm/V7Jb2y/3OOuOq
JSZXxbNauaKDV6d2v+SuIDXd2jvXwQH3QRXf4iIfLfdeseUCHVCQyXQ8Vngw
SshAIuZWUyW9KpbzDYjTuCtjlRWxW6H1VHWqiHWVKrgph4Za6yO8w5K8ABVi
qrnDUs6mU9rtcrwNviTI6iB+x/2/RxaERAV09JeV3H3kkLQxPHTBudL1DQpW
xc3DmhLS0qAb8UXyBYTQpiwQyeN7tYy1jZRYiSnTkcq90O5pt+6UCm48K0Lz
1JE9/PlhskNZNvaYcwdY1CS4MtBlfCrXSgtEEJtM2waRTtREdTt8Nm7zK7mM
WC7AkGurfUXmkFatRaggIuoHhQF4SJf0KURk19wFUURrENJFNkQk9q9hfkR2
kLso0h8cCS2LBqceWpd4E6EsSkQfQ7c0weoaPhYqwAY8Car2aA8Ku4Ddt2VL
Zc1YUTkBZVdBj4EUqhjvtf7BtVjRDKRBhjCHUTcVilJU4rz1TVlYuI0WyPsG
PbiYZLTKIU97HdBYVpahaf2un473JwQH2D3sajji5jMWDRhtiAWLQBoNIDur
5NqF6H02Y63RWnyTvI5wwg+VegmyVX6ovR4iMGqdJBdo5dFcfDEot98SjaPa
lAh1cThiroUQQfOVPVs1UlRE9mUuBURaHuSGi3wuY8SkZRz8Fi6RWwp/Uy9O
wkfFqaZlzjFNava2E88diHop3Pt9nDHfr4geEBZyF019RBwQW5zk1tdBCPPY
8hHvQIgABrSwoyEeLQg0KslEBilHHR+8dKDEQHcPdCWqBVsOgsvXNuFtKeKX
fKWEJhTdB3bzzdtIzrkpt4VxCjqqugC7XELTSN0Gt4/x+evJPjy/5fL6YVa7
bfL98trzIK99wontFqvBQJK6bqMYThhjAQVJg6hog7W6qGwdhu7OZxb/U+7f
C7I0hZ0PWn9pfGPY/guooqG0pBhITZ/onqm8lOpom9OpCtL7jdMD8lwuOK7K
/nLad9c3V9Nu0W+nNXaPL6v+nWuIY04ujl/SKTEnHPsmAhiiA7afhIICub0J
MOZ2t3RT1jn47MHjLmxh38xo86RCbqQtCtKEx0nuIuWPTv2LsBHBqUBdEvkE
HTvQGMv/HvPFQDJJ7wg505wm8QsxIymxvWslUfHOADXaYU795jF0Winoxbtc
J5RHMDsvFqc9/jrcNJKnvU8s+MUqd7sXIQgooXi/NzDKoPbAw1L+lxGmcTyX
eb4PpteB29XKhM5NcxxRiSaBcX/Oel42ljrYcDA9ruVo0KmBnc7GBqweSetz
x9oKTwY3yhZDzXaWWKh1VCIm/SRscW5y9Lp/5wGA+cb9UpbajUSeQD+axN1i
lzpzOCzQmTlDRoNxUsYlFaSskIten3kPmtfK8xNpYNFJlV4/XF/S9LVIW1Zo
cwl3Py03PhoMIiG3DaCprurGBFO2bCQdsqi6MqzjjhoZXwTRvJ8fhrG4LGOX
mIv3pRfSiSLR0cPd5a064FUqs3jcKFWrIyjzPoKW1F/Nr1u56srbKHl0NBmQ
UzekL2kmnHSYHKp7GNFN5aun/GzIyXB3tGaS7uL7LnGMkGM68/j2IsbJZHRW
Ma7KGsZu5styg7QbxJjLpa8nleLP1aA9e971GArrFc2m4doj64foWsNb2qVv
qcNptgPnKwMddgIXZ6d1jeEsBnFkJhh32zB2yc5CBumjPMJnUC1d28pW2x6k
aZ52H66MYYmkmQWOR+PuArOLuM+5aGMPbZp4UkxL5skmyHcYdm3kAQ1HJ4Og
9X2QpB4MRJyYVOfcCyFJpb0ngmp53fdTUdSMXvaXAGs4epi/PnnLSwFMYq13
Wfb+1en05YvXF+/eH+dnuI+v9LV/3MxCxlXC3+7mUZtc5KQ2C86NNqvRuq5x
zRnNqL0/9baWdPp4CLsdljuPq8V+cvZau+Rq9RdcqSIigjOH6DH8gwcXJ2fn
h3byszNnH9A0GElt/cRr4Zr4XUaKib9jxntlcAqrbrFDVlFWoTmjIAianjw9
9e4K0vag67nwL0TfZoPoPvsRoUpWHf14yOqyuV1cRRe3iw9FCJlotIgpErkI
7qgF1BBY0/S51S8r9MCNQ032MK15te3gF1ZFeOXHToJMzsX3cgdZRXT5Qy3p
wt8RxD8RGp4cPTlCtUKJThMseCriUNcuUH5FqNlo2JTsG27EcdWWKh/eNrP8
90+ffvnl0/zg7cuTi0OW1Pzp118/ffI4P/j+5PvXh7MUUI4QRJcavSmreV39
RDoNlCaamIOZWAe7wl68+jaf5t8SwyA14r2B+4qD6KIyf9v0/SUcjPmP1XpV
rjc25JQUGJr7ydFjAufVn/41f/Uy/+oPR4+eko13D8CAvR/+RLzzqiLrtLVo
4tnqtuPK2HOuhyMj0UF1SlAtqnWEs5dnj94fPX389Om/PHrMkxb1B9Yszvsd
SP50VXYrEruT/J+bbkXGWUFyZ12Sxv+iuK6WNAuZeMVPlRitL3HO/kQbRRNa
8Llqx1ryIZ3lqs6lSg4lz3ycsIjviAne5i9vyzmaz2kN9Kqk2da36H+z5lC+
ut+BH+5gp1C/KXasLp2udoWEP/8ZmYGE8jK483IteG2kq/MZqmDOG6mGDCud
fB/zPtoLTc4gdE2nU27uyWfAtwGOfMe0HERWP07hokOIHKLcmmT5ggKvx9g1
iY6Zpdo8HCAFCtZxQWOY/yM9z9wllWmnXMfbQA0VKvDh9/z5Z5zm6cn70+/g
WxMH7m5rZX/Rs0FVgEExuJtUZ/FBtXINmVM4P5431ottN6VxaAjwt6gxtUeM
o34hGdXrs/IjWcHsyZALK1l35gaJ/HraedJHveblLUf3EB+yaNY+lB7fEbRi
64ajI+6rLPyKcaUGQ+P7OknPuVbvx6Slo/1CYhJproXHQcGWuTTN5oUv1Qff
aZNklyXlidD6slyXWmmVxcUALXoKyVVkzVan3BjfMaL1TiFI0svyZrzbdRhF
8u22IDTChq1lvSo4TDTsJaCmfFyy7m5SDR1XmU/jNMdHkYbXJNPQkNrJyjTs
BFQGnucsySvCQlxZIbSXIBx1WWHVdiwlkU3vAJAs0EyqAhqX0q0C3nRHPZEs
PcFNwO60d3snzfYs07e8zbx7zXWIQ3YRn0M0owxboODQxo3QkmgWS4aIVgMy
Tqv+79FFgA1YSzDg9Oyg5KbOjEjEkmq6kL3tCZ9z0OR8d4UaGmhk6qEfv2hK
PR/7e2jAKa/ITFuaqt7IbTK1s4QcINTQBDNLbbZETeIUmMBanyNI2fWpW2nU
s9lprsLA1+mTLDmqjfSrivtHO4M3KuiTDpWcJsD+pqpTPjPL/9f/FA38i/P8
7buLl8dssAZEaAqsPM/uRRpi1ffb7vjRoysi0d18RkzwEbPmYls9WrZkBnaP
pNnqo8dH3/ybOeNLdV9YWXvQf4Sllre7nQN1/37dZ7doFL9famOzUPdlklza
26WQWKE/drUAaZB2Ah9LkNRaBQka7F6tNLGA23fvUPyq/iRp3p4ncwycrvsp
IMycyuX4/0oKwLOcLNKLI/H/FRV8c/Rv0iYlaErPPTXAazlXDT+RhjP2vfSD
9LdBhbLAOEvQUuxGzNbIQ6cdcIgfkmpS4h4wbAWbVNINSRKBufTIO4WIMPhO
611tLFKSAUwgDHHeDSoEOdVGGbPe3eqEm8DMWXl/3hXWBvtctSFpxRv2qUko
nblphu106UKTQT6MzGxTVaqv1p628JF1/UXcG20xcLMT7F2yETpaSRflzpJB
sh13O22KDxKX5CCcKIPobEFf9NwSVi8zgPwNO15I6gg7gXKtFh+hA+dGdEkT
I0gL92ISm+kGI19PDiG+iS82KPIX56dndr8K94QKouwXLKgeQ1QNgkdtv7gp
59O/NR0Hj8ZoWL02YokEZrJXXNxnkXdgkqUKDvbMKezB3bKRo9HuZsE2PUDo
es3F8w8ygQcLehC0tHnAaLHiiiHSkt4x3P7Fuwq0RC/Jh1yXe6Hg6Z8TO8SZ
rpc8e8azV9pk2b/n94Tf6qxNywPnsnzAd1WIZEULcbdIdiH1emdKcNGRq2uq
9E4Rvy8RrtHUVXz6AGZsV5X7kiFPpjs6e+GmoEFWrcUFatSrbuZBycrImLys
4NL2PQzRJc5DJHmlOu44uCfcofqqX3bsOI2ul1FNtkhuVJMOAOk1q3JZGZkN
klk/cocTh6l9uGUft9eRCuRLZK5prng1x4vDOe/JhmAJp+XhQQmwy7sOba4k
kSbK/s2TG3nuONtxV+awNgQ7NN7qlo1SpmD59MEg01N6iz3E+8yWTwlrdOhu
1eRSOg9VopFghTB3iXA0ElTB2ZIhwV5QrS3nh+Y7M/3G5go6epHCzZnnx9kx
ku+RlG9K1SO7zwFZ0reo+SFjRe7W0a5Pkl7PqdboroYx3iD8j7pEAAQ73Hdn
sh5suGKwLtcTCXu5r3UsyZNncKT+QPtgaIuDnvtv8AewR7NMWjsd5/hXa0Ck
V4gU4flWtFu++INLzgaTjmtVokhIhr3vGWzyVLE8y79v+JZQRi2Mjk7NF+zO
TlpUWfGcEFfvL602D7Xx6HDkDKnMi2or2cyS+MFmHla6sK3U2Yy36oR9ULkK
XprZ3NbJXnC7bxRF/XNcYKRV5y9UetlIRscJpyaqcW1kfjlFay9vrSsv/H4q
Kb/WMrhB8B0QJvkPCp+D+9dCY32lY4gygSi/H0TEj4j5uowsQRz8Nw5bwPVU
KPpXwjnXAQaYy+4PJ2OOqxUFWIP1FCQe8LkYSB9muRlRaYc6+IYkQY80UTQ7
6yaZkLbZflUfW+doUrHt7fquHZnjIA++acqSs66b9U6qj3zV3srcgaPaDwK+
cBI2rrUSug9yCbXrPwjoMnZ+yCVH7LXirLKgXXqIBwgNFlEunTZSUrKg6Oxt
g9s10MEOvOvkuqnCC9oH6QsRxrLsnfbD433BALI1NJe0xeNkzWC0eqlYdG7Z
ZXnVFks9GM+LNa/NRvuhcx0G5UJuPn76EDeoY68m7xZacBJBFVn2mtMD3CD6
Kx6fIA2/6aJtaNbck9TyhNPBEob8IATxwd4c7b0urHv5q/KBvypjfSFNzGcf
lYaIvX/Kcf27XFUjSTpxAmIwoPmixgdM8ww530n4y70tf5+39es8QMMrQD7X
x/8XIT9xFkZqG++B67YL15JvvVvdoxW2lnEab9I+uUzp8Ay5C1/dXZQ76Vnb
tFHeRWKiaftOa1mseWBJl3FNsBh1J/mWDWGD8Shj83MV/pwyxtui0nt/4uII
ww9zeXtm58hUVDUglT43sCe6aI3+/gSkvAbn3d+0q85K6y3obj5GEnJpV3pr
6ky0kLxkUr/ML4m6pqpNwgeHiivfdsnUTAkD6T2yugRzscHfIb4jRC/nu7aT
6qNYAQNjmu86UpdJojSqMwlZ4wr6TlIReO85GUDbW7DpROZRE4b96AxNuw9l
v1h9GmYpwOyTYug5emwt+uhytCYnFO06wYHcicNxSBDTptii148WMAvdFC4w
zjp4UV/trJ+IpCyYFTOAt+oyfyabes0ulH6ML2wIEVMNgz/aQoxz5HSW5y90
WSJb3IHBzNMpC0RbTBC5WIYvpQrEEmYTSDaTNXcaxWXhKoVcwzYI+TTuAOZW
k7nVNDTrrGmv7rWuC1tEgDS+9IHI/QMkK5sbvAU5bv7z98Io+OYNZzCH+5z5
cYms/i+W46Vzyv8AAA==

-->

</rfc>

