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

<!-- xml2rfc v2v3 conversion 3.17.1 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.24 (Ruby 3.0.6) -->
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc editing="no"?>
<?rfc tocompact="yes"?>
<?rfc iprnotified="no"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
ipr="trust200902"
docName="draft-ietf-alto-new-transport-22"
number="9569"
submissionType="IETF"
category="std"
consensus="true"
updates=""
obsoletes=""
tocDepth="3"
tocInclude="true"
sortRefs="true"
symRefs="true"
xml:lang="en"
version="3">
  <!-- xml2rfc v2v3 conversion 3.17.1 -->

  <front>

    <title abbrev="ALTO TIPS">The ALTO Application-Layer Traffic Optimization (ALTO) Transport Information Publication Service</title> Service (TIPS)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-alto-new-transport-22"/> name="RFC" value="9569"/>

    <author initials="K." surname="Gao" fullname="Kai Gao">
      <organization>Sichuan University</organization>
      <address>
        <postal>
          <street>No.24 South Section 1, Yihuan Road</street>
          <city>Chengdu</city>
          <code>610000</code>
          <country>China</country>
        </postal>
        <email>kaigao@scu.edu.cn</email>
      </address>
    </author>
    <author initials="R." surname="Schott" fullname="Roland Schott">
      <organization>Deutsche Telekom</organization>
      <address>
        <postal>
          <street>Ida-Rhodes-Straße 2</street>
          <street>Deutsche-Telekom-Allee 9</street>
          <city>Darmstadt</city>
          <code>64295</code>
          <country>Germany</country>
        </postal>
        <email>Roland.Schott@telekom.de</email>
      </address>
    </author>
    <author initials="Y. R." surname="Yang" fullname="Yang Richard Yang">
      <organization>Yale University</organization>
      <address>
        <postal>
          <street>51 Prospect Street</street>
          <city>New Haven</city>
          <code>CT</code>
          <country>USA</country>
	  <code>06511</code>
	  <region>CT</region>
          <country>United States of America</country>
        </postal>
        <email>yry@cs.yale.edu</email>
      </address>
    </author>
    <author initials="L." surname="Delwiche" fullname="Lauren Delwiche">
      <organization>Yale University</organization>
      <address>
        <postal>
          <street>51 Prospect Street</street>
          <city>New Haven</city>
          <code>3408</code>
          <country>USA</country>
	  <region>CT</region>
          <code>06511</code>
          <country>United States of America</country>
        </postal>
        <email>lauren.delwiche@yale.edu</email>
      </address>
    </author>
    <author initials="L." surname="Keller" fullname="Lachlan Keller">
      <organization>Yale University</organization>
      <address>
        <postal>
          <street>51 Prospect Street</street>
          <city>New Haven</city>
          <code>3408</code>
          <country>USA</country>
	  <region>CT</region>
          <code>06511</code>
          <country>United States of America</country>
        </postal>
        <email>lachlan.keller@yale.edu</email>
        <email>lachlan.keller@aya.yale.edu</email>
      </address>
    </author>
    <date/>

    <date year="2024" month="August"/>

    <area>Transport Area</area>
    <workgroup>ALTO</workgroup>

    <abstract>
      <t>The ALTO Protocol
      <t>"Application-Layer Traffic Optimization (ALTO) Protocol" (RFC 7285) leverages HTTP/1.1 and is designed for
      the simple, sequential request-reply use case, in which an ALTO client
      requests a sequence of information resources and the server responds
      with the complete content of each resource resource, one at a time.</t>
      <t>ALTO
      <t>RFC 8895, which describes ALTO incremental updates using Server-Sent Events (SSE) (RFC 8895) (SSE),
      defines a multiplexing protocol on top of HTTP/1.x, so that an ALTO
      server can incrementally push resource updates to clients whenever
      monitored network information resources change, allowing the clients to
      monitor multiple resources at the same time. However, HTTP/2 and later
      versions already support concurrent, non-blocking transport of multiple
      streams in the same HTTP connection.</t>

      <t>To take advantage of newer HTTP features, this document introduces
      the ALTO Transport Information Publication Service (TIPS). TIPS uses an
      incremental RESTful design to give an ALTO client the new capability to explicitly,
      explicitly and concurrently (non-blocking) (in a non-blocking manner) request (pull) (or pull)
      specific incremental updates using
native HTTP/2 or HTTP/3, while still
      functioning for HTTP/1.1.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    Application-Layer Traffic Optimization Working Group mailing list (alto@ietf.org),
    which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/alto/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="intro">
      <name>Introduction</name>
      <t>Application-Layer
      <t>The Application-Layer Traffic Optimization (ALTO) protocol provides means for network
applications to obtain network status information. So far, the ALTO information
can be transported in two ways:</t>
      <ol spacing="normal" type="1"><li>The type="1"><li>Using the ALTO base protocol <xref target="RFC7285"/>, which is designed for the simple use case
in which an ALTO client requests a network information resource, resource and the
server sends the complete content of the requested information (if any)
resource to the client.</li>
        <li>ALTO
        <li>Using ALTO incremental updates using Server-Sent Events (ALTO/SSE) <xref target="RFC8895"/>,
which target="RFC8895"/>;
this method is designed for an ALTO client to indicate to the server that it wants
to receive updates for a set of resources resources, and the server can then
concurrently and incrementally push updates to that client whenever
monitored resources change.</li>
      </ol>

      <t>Both protocols are designed for HTTP/1.1 <xref target="RFC9112"/>, but target="RFC9112"/>. While they still work with HTTP/2 <xref target="RFC9113"/> and
HTTP/3 <xref target="RFC9114"/> can support HTTP/1.1 workflows. However, HTTP/2 target="RFC9114"/>, ALTO and HTTP/3
provide features that can improve certain properties ALTO/SSE cannot take full advantage of ALTO new features offered by HTTP/2 and ALTO/SSE.</t> HTTP/3.</t>
      <ul spacing="normal">
        <li>First, consider the ALTO base protocol, which is designed to transfer only
complete information resources. A client can run the base protocol on top of
HTTP/2 or HTTP/3 to request multiple information resources in concurrent
streams, but each request must be for a complete information resource: there is
no capability for the server to transmit incremental updates. Hence, there can be a large
overhead when the client already has an information resource and then there are
small changes to the resource.</li>
        <li>Next, consider ALTO/SSE <xref target="RFC8895"/>. Although ALTO/SSE can transfer
incremental updates, it introduces a customized multiplexing protocol on top
of HTTP, assuming a total-order message channel from the server to the client.
The multiplexing design does not provide naming (i.e., a resource identifier)
to individual incremental updates. Such a design cannot use concurrent data
streams available in HTTP/2 and HTTP/3, HTTP/3 because both cases require a resource
identifier. Additionally, ALTO/SSE is a push-only protocol, which denies the
client flexibility in choosing how and when it receives updates.</li>
      </ul>
      <t>To mitigate these concerns, this document introduces a new ALTO service called
the Transport Information Publication Service (TIPS). TIPS uses an incremental
RESTful design to provide an ALTO client with a new capability to explicitly,
concurrently issue non-blocking requests for specific incremental updates using
native
HTTP/2 or HTTP/3, while still functioning for HTTP/1.1.</t>
      <t>While both ALTO/SSE <xref target="RFC8895"/> and TIPS both can transport incremental updates of
ALTO information resources to clients, they have different design goals. The
TIPS extension enables more scalable and robust distribution of incremental
updates,
updates but is missing the session management and built-in server push
capabilities of ALTO/SSE. From the performance perspective, TIPS is optimizing
throughput by leveraging concurrent and out-of-order transport of data, while
ALTO/SSE is optimizing latency as new events can be immediately transferred to
the clients without waiting for another round of communication when there are
multiple updates. Thus, we do not see TIPS as a replacement for ALTO/SSE, but as a complement
of ALTO/SSE.
to it. One example of combining these two extensions is as shown in
<xref target="tips-sse"/>.</t>
      <t>Note that future extensions may leverage server push, a feature of HTTP/2
<xref target="RFC9113"/> and HTTP/3 <xref target="RFC9114"/>, as an alternative of SSE. We discuss why
this alternative design is not ready at the time of writing in <xref target="push"/>.</t>
      <t>Specifically, this document specifies:</t>
      <ul spacing="normal">
        <li>Extensions to the ALTO Protocol for dynamic subscription and efficient
uniform update delivery of an incrementally changing network information
resource.</li>
        <li>A new resource type that indicates the TIPS updates graph model for a
resource.</li>
        <li>URI patterns to fetch the snapshots or incremental updates.</li>
      </ul>
      <t>Some operational complexities that must be taken into consideration when
implementing this extension are discussed in <xref target="ops-considerations"/>, including target="ops-considerations"/>: these include
load balancing in <xref target="load-balancing"/>, target="load-balancing"/> and fetching and processing incremental updates
of dependent resources in <xref target="cross-sched"/></t> target="cross-sched"/>.</t>
      <t><xref target="sec-bcp-http"/> discusses to what extent the TIPS design adheres to the Best
Current Practices best
current practices for building protocols with HTTP <xref target="RFC9205"/>.</t>

<section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
      <section anchor="notations">
        <name>Notations</name>
        <t>This document uses the same syntax and notations as introduced in
<xref section="8.2" sectionFormat="of" target="RFC7285"/> to specify the extensions to existing ALTO resources and services.</t>
      </section>
    </section>
    <section anchor="overview">
      <name>TIPS Overview</name>
      <section anchor="requirements">
        <name>Transport Requirements</name>
        <t>The ALTO Protocol and its extensions support two transport mechanisms:
First, a mechanisms:</t>
	<ol>
<li>A client can directly request an ALTO resource and obtain a complete
snapshot of that ALTO resource, as specified in the base protocol <xref target="RFC7285"/>;
Second, a target="RFC7285"/>;</li>
<li>A client can subscribe to incremental changes of one or multiple ALTO
resources using the incremental update extension <xref target="RFC8895"/>, and a server pushes
the updates to the client through Server Sent Events (SSE).</t> SSE.</li>
	</ol>
        <t>However, the current transport mechanisms are not optimized for storing,
transmitting, and processing (incremental) updates of ALTO information
resources. Specifically, the new transport mechanism must satisfy the following
requirements:</t>
        <dl>
          <dt>Incremental updates:</dt>
          <dd>
            <t>Incremental updates only maintain and transfer the "diff" upon changes. Thus,
it is more efficient than storing and transferring the full updates,
especially when the change of an ALTO resource is minor. The base protocol
does not support incremental updates and the current incremental update
mechanism in <xref target="RFC8895"/> has limitations (as discussed below).</t>
          </dd>
          <dt>Concurrent, non-blocking update transmission:</dt>
          <dd>
            <t>When a client needs to receive and apply multiple incremental updates, it is
desired to transmit the updates concurrently to fully utilize the bandwidth
and to reduce head-of-line blocking. The Unfortunately, the ALTO incremental update extension
<xref target="RFC8895"/>, unfortunately, target="RFC8895"/> does not satisfy this requirement -- even requirement. Even though
the updates can be multiplexed by the server to avoid head-of-line blocking
between multiple resources, the updates are delivered sequentially and can
suffer from head-of-line blocking inside the connection, for connection (for example, when
there is a packet loss.</t> loss).</t>
          </dd>
          <dt>Long-polling
          <dt>Long polling updates:</dt>
          <dd>
            <t>Long-polling
            <t>Long polling updates can reduce the time to send the request, making it
possible to achieve sub-RTT transmission of ALTO incremental updates. In
<xref target="RFC8895"/>, this requirement is fulfilled using server-sent event (SSE) SSE and
is still desired in the ALTO new ALTO transport.</t>
          </dd>
          <dt>Backward compatibility:</dt>
          <dd>
            <t>While some of the previous requirements are offered by HTTP/2 <xref target="RFC9113"/> and
HTTP/3 <xref target="RFC9114"/>, it is desired that the ALTO new ALTO transport mechanism can
work with HTTP/1.1 as many development tools and current ALTO implementations
are based on HTTP/1.1.</t>
          </dd>
        </dl>

        <t>The ALTO new ALTO transport specified in this document satisfies all of the following design
requirements:</t>
requirements above by:</t>
        <ul spacing="normal">
          <li>This document reuses
          <li>Reusing the data format introduced in <xref target="RFC8895"/> that enables
incremental updates using JSON patches or merge patches.</li>
          <li>This document introduce
          <li>Introducing a unified data model to describe the
     changes (snapshots and incremental updates) of an ALTO resource,
     referred to as a TIPS
view. "TIPS view".  In the data model, snapshots and
     incremental updates are indexed as individual HTTP resources
     following a unified naming convention, independent of the HTTP
     version.  Thus, these updates can be concurrently requested and be
     transferred in a non-blocking manner either by using multiple
     connections or leveraging multiplexed data transfer offered by
     HTTP/2 or HTTP/3.</li>
          <li>The
          <li>Basing the unified naming convention is based on a monotonically
     increasing sequence number, making it possible for a client to
     construct the URL of a future update and send a long-polling long polling
     request.</li>
          <li>The
          <li>Making the unified naming convention is independent of the HTTP versions
     and can able to operate atop HTTP/1.1, HTTP/2 HTTP/2, or HTTP/3.</li>
        </ul>
        <t>This document assumes the deployment model discussed in  <xref target="sec-dep-model"/>.</t>
      </section>
      <section anchor="terminology">
        <name>TIPS Terminology</name>
        <t>In addition to the terms defined in <xref target="RFC7285"/>, this document uses the following terms:</t>
        <dl>
          <dt>Transport Information Publication Service (TIPS):</dt>
          <dd>
            <t>Is a
            <t>A new type of ALTO service, as specified in this document, to enable a
uniform transport mechanism for updates of an incrementally changing ALTO
network information resource.</t>
          </dd>
          <dt>Network information resource:</dt>
          <dd>
            <t>Is a
            <t>A piece of retrievable information about network state, per <xref target="RFC7285"/>.</t>
          </dd>
          <dt>TIPS view (tv):</dt>
          <dd>
            <t>Is defined in this document to be the
            <t>The container of incremental transport
information about the network information resource. The TIPS view has one
basic component, the updates graph (ug), but may include other transport
information.</t>
          </dd>
          <dt>Updates graph (ug):</dt>
          <dd>
            <t>Is a
            <t>A directed, acyclic graph whose nodes represent the set of
            versions of an information resource, resource and whose edges represent the
            set of update items to compute these versions. An ALTO map service
            (e.g., Cost Map, Network Map) a cost map or a network map) may need only a single updates
            graph. A dynamic network information service (e.g., Filtered
Cost Map) a filtered
            cost map) may create an updates graph (within a new TIPS view) for
            each unique request. Encoding The encoding of a an updates graph is specified
            in <xref target="open-req"/>.</t>
          </dd>
          <dt>Version:</dt>
          <dd>
            <t>Represents
            <t>The representation of a historical content of an information resource. For an information
resource, each version is associated with and uniquely identified by a
monotonically and consecutively increased sequence number. This document uses
the term "version s" to refer to the version associated with sequence number
"s". Version The version is encoded as a JSONNumber, as specified in <xref target="open-req"/>.</t>
          </dd>
          <dt>Start sequence number (start-seq):</dt> (&lt;start-seq&gt;):</dt>
          <dd>
            <t>Is the
            <t>The smallest non-zero sequence number in an updates graph.</t>
          </dd>
          <dt>End sequence number (end-seq):</dt> (&lt;end-seq&gt;):</dt>
          <dd>
            <t>Is the
            <t>The largest sequence number in an updates graph.</t>
          </dd>
          <dt>Snapshot:</dt>
          <dd>
            <t>Is a
            <t>A full replacement of a resource and that is contained within an updates graph.</t>
          </dd>

          <dt>Incremental update:</dt>
          <dd>
            <t>Is a
            <t>A partial replacement of a resource contained within an
            updates graph, codified in this document as a JSON Merge Patch merge patch or
            a JSON Patch. patch. An incremental update is mandatory if the source
            version (i) and the target version (j) are
consecutive, i.e., consecutive (i.e., i + 1 = j, and
            j); otherwise, it is optional or (or a shortcut otherwise. shortcut). Mandatory incremental
            updates are always in an updates graph, while optional/shortcut
            incremental updates may or may not be included in an updates
            graph.</t>
          </dd>
          <dt>Update item:</dt>
          <dd>
            <t>Refers to the
            <t>The content on an edge of the updates graph, which can be either a
snapshot or an incremental update. An update item can be considered as to be a pair
(op, data) where op denotes whether the item is an incremental update or a
snapshot,
snapshot and data is the content of the item.</t>
          </dd>
          <dt>ID#i-#j:</dt>
          <dd>
            <t>Denotes
            <t>Denotation of the update item on a specific edge in the updates graph to transition
from version i to version j, where i and j are the sequence numbers of the
source node and the target node of the edge, respectively.</t>
          </dd>
        </dl>
        <figure anchor="fig-overview">
          <name>Overview of ALTO TIPS</name>
          <artwork type="drawing" align="center"><![CDATA[
                                   +-------------+
    +-----------+ +--------------+ |  Dynamic    | +-----------+
    |  Routing  | | Provisioning | |  Network    | | External  |
    | Protocols | |    Policy    | | Information | | Interface |
    +-----------+ +--------------+ +-------------+ +-----------+
          |              |                |              |
+-----------------------------------------------------------------+
| ALTO Server                                                     |
| +-------------------------------------------------------------+ |
| |                                         Network Information | |
| | +-------------+                         +-------------+     | |
| | | Information |                         | Information |     | |
| | | Resource #1 |                         | Resource #2 |     | |
| | +-------------+                         +-------------+     | |
| +-----|--------------------------------------/-------\--------+ |
|       |                                     /         \         |
| +-----|------------------------------------/-----------\------+ |
| |     |       Transport Information       /             \     | |
| | +--------+                     +--------+        +--------+ | |
| | |  tv1   |                     |  tv2   |        |  tv3   | | |
| | +--------+                     +--------+        +--------+ | |
| |     |                          /                     |      | |
| | +--------+            +--------+                 +--------+ | |
| | | tv1/ug |            | tv2/ug |                 | tv3/ug | | |
| | +--------+            +--------+                 +--------+ | |
| +----|----\----------------|-------------------------|--------+ |
|      |     \               |                         |          |
+------|------\--------------|-------------------------|----------+
       |       +------+      |                         |
       |               \     |                         |
   +----------+       +----------+                 +----------+
   | Client 1 |       | Client 2 |                 | Client 3 |
   +----------+       +----------+                 +----------+

tvi   = TIPS view i
tvi/ug = incremental updates graph associated with tvi
]]></artwork>
        </figure>
        <t><xref target="fig-overview"/> shows an example illustrating an overview of the ALTO TIPS
service.
extension. The server provides the TIPS service of for two information resources (#1
and #2) where #1 is an ALTO map service, service and #2 is a filterable
service. There are 3 three ALTO clients (Client 1, Client 2, and Client 3) that are
connected to the ALTO server.</t>
        <t>Each client uses the TIPS view to retrieve updates. Specifically, a TIPS view
(tv1) is created for the map service #1, #1 and is shared by multiple clients. For
the filtering service #2, two different TIPS views (tv2 and tv3) are created upon
different client requests with different filter sets.</t>
      </section>
    </section>
    <section anchor="tips-updates-graph">
      <name>TIPS Updates Graph</name>
      <t>In order to provide incremental updates for a resource, an ALTO server creates
an updates graph, which is a directed, directed acyclic graph that contains a sequence of
incremental updates and snapshots (collectively called update items) "update items") of a
network information resource.</t>
      <section anchor="data-model">
        <name>Basic Data Model of an Updates Graph</name>
        <t>For each resource (e.g., a cost map, map or a network map), the incremental updates and
snapshots can be represented using the following directed acyclic graph model,
where the server tracks the change of the resource maps with version IDs that are
assigned sequentially (i.e., incremented by 1 one each time):</t>
        <ul spacing="normal">
          <li>Each node in the graph is a version of the resource, which is identified by a
sequence number (defined as a JSONNumber). Version 0 is reserved as the
initial state (empty/null).</li>
          <li>A tag identifies the content of a node. A tag has the same format as the
"tag" field in <xref section="10.3" sectionFormat="of" target="RFC7285"/> and is valid only within the
scope of the resource.</li>

          <li>Each edge is an update item. In particular, the edge from i to j is the update
item to transit from version i to version j.</li>
          <li>Version
          <li>The version is path-independent (different path independent, i.e., different paths arrive arriving at the node associated with the same version/node
has version
have the same content)</li> content.</li>
        </ul>

        <t>A concrete example is shown in <xref target="fig-ug"/>. There are 7 seven nodes in the graph,
representing 7 seven different versions of the resource. Edges in the figure represent
the updates from the source version to the target version. Thick lines represent
mandatory incremental updates (e.g., ID103-104), dotted lines represent optional
incremental updates (e.g., ID103-105), and thin lines represent snapshots (e.g.,
ID0-103). Note that node content is path independent: the content of node v can
be obtained by applying the updates from any path that ends at v. For example,
assume the latest version is 105 and a client already has version 103. The base
version of the client is 103 as it serves as a base upon which incremental
updates can be applied. The applied.</t>

<t>The target version 105 can either be directly be:</t>

<ul>
  <li>directly fetched as a snapshot, computed snapshot;</li>

  <li>computed incrementally by applying the incremental updates between
  103 and 104, then 104 and 105, or if the optional update from 103 to 105 exists,
computed 105; or,</li>

  <li>computed incrementally by taking the "shortcut" path from 103 to 105.</t>
  105 if the optional update from 103 to 105 exists.</li></ul>

        <figure anchor="fig-ug">
          <name>TIPS Model Example</name>
          <artwork type="drawing" align="center"><![CDATA[
                                                    +======+
                                              ------|  0   |
                                             /      +======+
                                    ID0-101 /        |   |
                                          |/__       |   |
                                   +======+          |   |
                   tag: 3421097 -> | 101  |          |   |
                                   +======+          |   |
                           ID101-102  ||             |   |
                                      \/             |   |
                                   +======+          |   |
                   tag: 6431234 -> | 102  |          |   |
                                   +======+          |   |
                           ID102-103  ||             |   |
                                      \/             |   |
                                   +======+          /   |
+--------------+   tag: 0881080 -> | 103  |<--------/    |
| Base Version |   =======>        +======+ ID0-103      |
+--------------+             103-104  ||    ..           |
                                      \/     ..          |
                                   +======+  ..          |
                   tag: 6452654 -> | 104  |  .. ID103    |
                                   +======+  .. -105     |
                           ID104-105  ||     ..          | ID0-105
                                      \/   |._           /
                                   +======+             /
                   tag: 7838392 -> | 105  |<-----------/
                                   +======+
                           ID105-106  ||
                                      \/
                                   +======+
                   tag: 6470983 -> | 106  |
                                   +======+
]]></artwork>
        </figure>
      </section>
      <section anchor="updates-graph-modification-invariants">
        <name>Updates Graph Modification Invariants</name>
        <t>A server may might change its updates graph (to compact, compact it, to add nodes,
etc.), but it must will need to ensure that any resource state that it makes
available is reachable by clients, either directly via a snapshot
(that is, relative to 0) or indirectly by requesting an earlier
snapshot and a contiguous set of incremental updates.  Additionally,
to allow clients to proactively construct URIs for future update
items, the ID of each added node in the updates graph must will need to increment
contiguously by 1.  More specifically, the updates graph <bcp14>MUST</bcp14> satisfy
the following invariants:</t>
        <ul
        <dl spacing="normal">
          <li>Continuity: At
          <dt>Continuity:</dt><dd>At any time, let ns denote the smallest non-zero version (i.e.,
start-seq)
&lt;start-seq&gt;) in the update updates graph and let ne denote the latest version (i.e.,
end-seq). Then
&lt;end-seq&gt;). Then, any version in between ns and ne <bcp14>MUST</bcp14> also exist.  This implies
that the incremental update from ni to ni + 1 exists for any ns &lt;= ni &lt;= ne, and all versions the version numbers in the update updates graph (except 0) is an
   constitute exactly the integer interval
<tt>[ns, ne]</tt>.</li>
          <li>Feasibility: Let [ns, ne].</dd>
          <dt>Feasibility:</dt><dd>Let ns denote the start-seq &lt;start-seq&gt; in the update updates graph. The server <bcp14>MUST</bcp14>
provide a snapshot of ns and, ns;  in other words, there is always a direct link
to ns in the update graph.</li>
          <li>"Right updates graph.</dd>
          <dt>"Right shift" only: Assume only:</dt><dd>Assume a server provides versions in <tt>[n1, n2]</tt> [n1, n2] at time t
and versions in <tt>[n1', n2']</tt> [n1', n2'] at time t'. If t' &gt; t, then n1' &gt;= n1 and n2' &gt;=
n2.</li>
        </ul>
n2.</dd>
        </dl>
        <t>For example, consider the case that a server compacts a resource's updates graph
to conserve space, using the example model in <xref target="data-model"/>. Assume at time 0,
the server provides the versions <tt>{101, {101, 102, 103, 104, 105, 106}</tt>. 106}.  At time 1,
both <tt>{103, {103, 104, 105, 106}</tt> 106} and <tt>{105, 106}</tt> {105, 106} are valid sets. However, <tt>{102, {102,
103, 104, 105, 106}</tt> 106} and <tt>{104, {104, 105, 106}</tt> 106} are not valid sets as there is no
snapshot to version 102 or 104 in the update updates graph. Thus, there is a risk that
the right content of version 102 (in the first example) or 104 (in the second
example) cannot be obtained by a client that does not have the previous version
101 or 103, respectively.</t>
      </section>
    </section>
    <section anchor="workflow">
      <name>TIPS Workflow and Resource Location Schema</name>
      <section anchor="workflow-overview">
        <name>Workflow</name>
        <t>At a high level, an ALTO client first uses requests the TIPS service information resource (denoted as TIPS-F
and TIPS-F,
where F is for frontend) to indicate the information resource(s) resource or resources that the client
wants to monitor. For each requested resource, the server returns a JSON object
that contains a URI, which points to the root of a TIPS view (denoted as
TIPS-V), and a summary of the current view, which contains the information to
correctly interact with the current view. With the URI to the root of a TIPS
view, clients can construct URIs (see <xref target="schema"/>) to fetch incremental updates.</t>
        <t>An example workflow is shown in <xref target="fig-workflow-pull"/>. After the TIPS-F
service
 receives the request from the client to monitor the updates of an ALTO
resource, it creates a TIPS view service resource and returns the corresponding
information to the client. The URI points to that specific TIPS-V instance instance, and
the summary contains the start-seq &lt;start-seq&gt; and end-seq &lt;end-seq&gt; of the update graph, updates graph and a
server-recommended edge to consume first, e.g., first (e.g., from i to j.</t> j).</t>
        <t>An ALTO client can then continuously pull each additional update with the
information. For example, the client in <xref target="fig-workflow-pull"/> first fetches the
update from i to j, j and then from j to j+1. Note that the update item at
<tt>&lt;tips-view-uri&gt;/ug/&lt;j&gt;/&lt;j+1&gt;</tt> may
"&lt;tips-view-uri&gt;/ug/&lt;j&gt;/&lt;j+1&gt;" might not yet exist, so the server holds the
request until the update becomes available (long (i.e., long polling).</t>
        <t>A server <bcp14>MAY</bcp14> close a TIPS view at any time, e.g., time (e.g., under high system load or due
to client inactivity. inactivity). In the event that a TIPS view is closed, an edge request
will receive error code 404 (Not Found) in response, and the client will have to request a
new TIPS view URI.</t>
        <t>If resources allow, a server <bcp14>SHOULD</bcp14> avoid closing TIPS views that have active
polling edge requests or have recently served responses until clients have had a
reasonable interval to request the next update, unless guided by specific
control policies.</t>
        <figure anchor="fig-workflow-pull">
          <name>ALTO TIPS Workflow Supporting Client Pull</name>
          <artwork type="drawing" align="center"><![CDATA[
Client                                 TIPS-F           TIPS-V
  o                                       .                .
  | POST to create/receive a TIPS view    .  Create TIPS   .
  |           for resource 1              .      View      .
  |-------------------------------------> |.-.-.-.-.-.-.-> |
  | <tips-view-uri>, <tips-view-summary>  .                |
  | <-------------------------------------| <-.-.-.-.-.-.-.|
  |                                                        .
  | GET /<tips-view-path>/ug/<i>/<j>                       .
  |------------------------------------------------------> |
  | content on edge i to j                                 |
  | <------------------------------------------------------|
  |                                                        .
  | GET /<tips-view-path>/ug/<j>/<j+1>                     .
  |------------------------------------------------------> |
  .                                                        .
  .                                                        .
  | content on edge j to j+1                               |
  | <------------------------------------------------------|
  |                                                        .
  o                                                        .
                                                           .
                                         TIPS View Closed  o
]]></artwork>
        </figure>
      </section>
      <section anchor="schema">
        <name>Resource Location Schema</name>
        <t>The resource location schema defines how a client constructs URI URIs to fetch
incremental updates.</t>
        <t>To access each update in an updates graph, consider the model
represented as a "virtual" file system (adjacency list), contained within the
root of a TIPS view URI (see <xref target="open-resp"/> for the definition of tips-view-uri).
For example, assuming that the update updates graph of a TIPS view is as shown in
<xref target="fig-ug"/>, the location schema of this TIPS view will have the format as in
<xref target="fig-ug-schema"/>.</t>
        <figure anchor="fig-ug-schema">
          <name>Location Schema Example</name>
          <artwork type="drawing" align="center"><![CDATA[
  <tips-view-path>  // root path to a TIPS view
    |_ ug    // updates graph
    |  |_ 0
    |  |  |_ 101    // full 101 snapshot
    |  |  |_ 103
    |  |  \_ 105
    |  |_ 101
    |  |  \_ 102    // 101 -> 102 incremental update
    |  |_ 102
    |  |  \_ 103
    |  |_ 103
    |  |  |_ 104
    |  |  \_ 105    // optional shortcut 103 -> 105 incr. update
    |  |_ 104
    |  |  \_ 105
    |  \_ 105
    |     \_ 106
    \_ ...
]]></artwork>
        </figure>
        <t>TIPS uses this directory schema to generate template URIs which that allow
clients to construct the location of incremental updates after receiving the
tips-view-uri from the server. The generic template for the location of the
update item on the edge from node 'i' to node 'j' in the updates graph is:</t>
        <artwork><![CDATA[
        <sourcecode type=""><![CDATA[
    <tips-view-uri>/ug/<i>/<j>
]]></artwork>
]]></sourcecode>
        <t>Due to the sequential nature of the update item IDs, a client can long poll a
future update that does not yet exist (e.g., the incremental update from 106 to
107)
107). This can be done by constructing the URI for the next edge that will be added, starting from
the sequence number of the current last node (denoted as end-seq) &lt;end-seq&gt;) in the graph
to the next sequential node (with the sequence number of end-seq &lt;end-seq + 1):</t>
        <artwork><![CDATA[ 1&gt;):</t>
        <sourcecode type=""><![CDATA[
    <tips-view-uri>/ug/<end-seq>/<end-seq + 1>
]]></artwork>
]]></sourcecode>
        <t>Incremental updates of a TIPS view are read-only. Thus, they are fetched using
the HTTP GET method.</t>
      </section>
    </section>
    <section anchor="ird">
      <name>TIPS Information Resource Directory (IRD) Announcement</name>
      <t>To announce a TIPS information resource in the information resource directory
(IRD), IRD, an ALTO server <bcp14>MUST</bcp14> specify the "media-type", "capabilities" "capabilities", and "uses"
as follows.</t>
      <section anchor="media-type">
        <name>Media Type</name>
        <t>The media type of the Transport Information Publication Service (TIPS) resource is
"application/alto-tips+json".</t>
      </section>
      <section anchor="caps">
        <name>Capabilities</name>
        <t>The capabilities "capabilities" field of a TIPS information resource is modeled on that defined in
Section 6.3 of
<xref target="RFC8895"/>.</t> target="RFC8895" sectionFormat="of" section="6.3"/>.</t>
        <t>Specifically, the capabilities are defined as an object of type
TIPSCapabilities:</t> the TIPSCapabilities type:</t>
        <figure anchor="tips-cap">
          <name>TIPSCapabilities</name>
          <artwork align="left"><![CDATA[
          <sourcecode type=""><![CDATA[
     object {
       IncrementalUpdateMediaTypes incremental-change-media-types;
     } TIPSCapabilities;

     object-map {
        ResourceID -> String;
     } IncrementalUpdateMediaTypes;
]]></artwork>
]]></sourcecode>
        </figure>
        <t>with the field:</t>
        <dl>
          <dt>incremental-change-media-types:</dt>
          <dd>
            <t>If a TIPS information resource can provide updates with incremental changes for a
resource, the "incremental-change-media-types" field has an entry
for that resource-id,
whose key is the ID of the resource and the value is the supported media types
of incremental changes, separated by commas. For the implementation of this
specification, this <bcp14>MUST</bcp14> be "application/merge-patch+json",
"application/json-patch+json", or
"application/merge-patch+json,application/json-patch+json", unless defined by
a future extension.
</t>
            <t>When choosing the media types to encode incremental updates for a
resource, the server <bcp14>MUST</bcp14> consider the limitations of the
encoding.  For example, when a JSON merge patch specifies that the
value of a field is null, its semantics are that the field is
removed from the target and hence target; hence, the field is no longer defined
(i.e., undefined).  This, however,  However, this may not be the intended result
for the resource, when null and undefined have different semantics
for the resource.  In such a case, the server <bcp14>MUST</bcp14> choose JSON
patch encoding over JSON merge patch if JSON patch is indicated as a
capability of the TIPS.  If encoding for the server does not support JSON patch
to handle such a case, incremental update if both media types "application/json-patch+json" and "application/merge-patch" are supported by the server then needs to send a full
replacement.</t> TIPS information resource.</t>
          </dd>
        </dl>
      </section>
      <section anchor="uses">
        <name>Uses</name>
        <t>The "uses" attribute <bcp14>MUST</bcp14> be an array with the resource-ids resource IDs of every
network information resource for which this TIPS information resource can provide service.</t>
        <t>This set <bcp14>MAY</bcp14> be any subset of the ALTO server's network information resources
and <bcp14>MAY</bcp14> include resources defined in linked IRDs. However, it is <bcp14>RECOMMENDED</bcp14>
that the ALTO server selects a set that is closed under the resource dependency
relationship. That is, if a TIPS' TIPS information resource's "uses" set includes resource R1 R1, and resource
R1 depends on ("uses") resource R0, then the TIPS' "uses" set should include R0
as well as R1. For example, if a TIPS information resource provides a TIPS view for a cost map, it
should also provide a TIPS view for the network map upon which that cost map
depends.</t>
        <t>If the set is not closed, at least one resource R1 in the "uses" field of a TIPS information resource
depends on another resource R0 which that is not in the "uses" field of the same
TIPS.
TIPS information resource. Thus, a client cannot receive incremental updates for another resource R0 from that is not in the "uses" field of the same TIPS service. information resource.  If the client observes in an update of R1 that the version tag for
R0 has changed, it must request the full content of R0, which is likely to be
less efficient than receiving the incremental updates of R0.</t>
      </section>
      <section anchor="an-example">
        <name>An Example</name>
        <t>Extending the IRD example in Section 8.1 of <xref target="RFC8895"/>, target="RFC8895" sectionFormat="of" section="8.1"/>, <xref target="ex-ird"/> is the IRD of an
ALTO server supporting the ALTO base protocol, ALTO/SSE, and ALTO TIPS.</t>
        <figure anchor="ex-ird">
          <name>Example of an ALTO Server Supporting the ALTO Base Protocol, ALTO/SSE, ALTO/&wj;SSE, and ALTO TIPS</name>
          <artwork align="left"><![CDATA[

          <sourcecode type="json"><![CDATA[
  "my-network-map": {
    "uri": "https://alto.example.com/networkmap",
    "media-type": "application/alto-networkmap+json"
  },
  "my-routingcost-map": {
    "uri": "https://alto.example.com/costmap/routingcost",
    "media-type": "application/alto-costmap+json",
    "uses": ["my-network-map"],
    "capabilities": {
      "cost-type-names": ["num-routingcost"]
    }
  },
  "my-hopcount-map": {
    "uri": "https://alto.example.com/costmap/hopcount",
    "media-type": "application/alto-costmap+json",
    "uses": ["my-network-map"],
    "capabilities": {
      "cost-type-names": ["num-hopcount"]
    }
  },
  "my-simple-filtered-cost-map": {
    "uri": "https://alto.example.com/costmap/filtered/simple",
    "media-type": "application/alto-costmap+json",
    "accepts": "application/alto-costmapfilter+json",
    "uses": ["my-network-map"],
    "capabilities": {
      "cost-type-names": ["num-routingcost", "num-hopcount"],
      "cost-constraints": false
    }
  },
  "update-my-costs": {
    "uri": "https://alto.example.com/updates/costs",
    "media-type": "text/event-stream",
    "accepts": "application/alto-updatestreamparams+json",
    "uses": [
        "my-network-map",
        "my-routingcost-map",
        "my-hopcount-map",
        "my-simple-filtered-cost-map"
    ],
    "capabilities": {
      "incremental-change-media-types": {
        "my-network-map": "application/json-patch+json",
        "my-routingcost-map": "application/merge-patch+json",
        "my-hopcount-map": "application/merge-patch+json"
      },
      "support-stream-control": true
    }
  },
  "update-my-costs-tips": {
    "uri": "https://alto.example.com/updates-new/costs",
    "media-type": "application/alto-tips+json",
    "accepts": "application/alto-tipsparams+json",
    "uses": [
        "my-network-map",
        "my-routingcost-map",
        "my-hopcount-map",
        "my-simple-filtered-cost-map"
    ],
    "capabilities": {
      "incremental-change-media-types": {
        "my-network-map": "application/json-patch+json",
        "my-routingcost-map": "application/merge-patch+json",
        "my-hopcount-map": "application/merge-patch+json",
        "my-simple-filtered-cost-map": "application/merge-patch+json"
      }
    }
  },
  "tips-sse": {
    "uri": "https://alto.example.com/updates/tips",
    "media-type": "text/event-stream",
    "accepts": "application/alto-updatestreamparams+json",
    "uses": [ "update-my-costs-tips" ],
    "capabilities": {
      "incremental-change-media-types": {
        "update-my-costs-tips": "application/merge-patch+json"
      }
    }
  }
]]></artwork>
]]></sourcecode>
        </figure>
        <t>Note that it is straightforward for an ALTO server to run HTTP/2 and
support concurrent retrieval of multiple resources such as "my-
network-map" "my-network-map" and "my-routingcost-map" using multiple HTTP/2 streams.</t>
        <t>The resource "update-my-costs-tips" provides an ALTO TIPS service, information resource, and this is
indicated by the media-type media type "application/alto-tips+json".</t>
      </section>
    </section>
    <section anchor="tips-management">
      <name>TIPS Management</name>
      <t>Upon request, a server sends a TIPS view to a client. This TIPS view may might be
created at the time of the request or may might already exist (either because another
client has already created a TIPS view for the same requested network resource
or because the server perpetually maintains a TIPS view for an often-requested
resource).</t>
      <section anchor="open-req">
        <name>Open Request</name>
        <t>An ALTO client requests that the server provide a TIPS view for a given resource
by sending an HTTP POST body with the media type
"application/alto-tipsparams+json". That body contains a JSON object of type
TIPSReq, the TIPSReq type, where:</t>
        <figure anchor="fig-open-req">
          <name>TIPSReq</name>
          <artwork align="left"><![CDATA[
          <sourcecode type=""><![CDATA[
    object {
       ResourceID   resource-id;
       [JSONString  tag;]
       [Object      input;]
    } TIPSReq;
]]></artwork>
]]></sourcecode>
        </figure>
        <t>with the following fields:</t>
        <dl>
          <dt>resource-id:</dt>
          <dd>
            <t>The resource-id
            <t>This field contains the resource ID of an ALTO resource and to be monitored, which <bcp14>MUST</bcp14> be in the TIPS' TIPS information resource's "uses" list
(<xref target="ird"/>). If a client does not support all incremental methods from the set
announced in the server's capabilities, the client <bcp14>MUST NOT</bcp14> use the TIPS
service.</t>
information resource.</t>
          </dd>
          <dt>tag:</dt>
          <dd>
            <t>If the resource-id "resource-id" is associated with a GET-mode resource with a version tag (or
"vtag"), as defined in Section 10.3 of <xref target="RFC7285"/>, target="RFC7285" sectionFormat="of" section="10.3"/>, and the ALTO
client has previously retrieved a version of that resource from
ALTO, the ALTO client <bcp14>MAY</bcp14> set the "tag" field to the tag part of
the client's version of that resource.  The server <bcp14>MAY</bcp14> use the tag
when calculating a recommended starting edge for the client to
consume.  Note that the client <bcp14>MUST</bcp14> support all incremental
methods from the set announced in the server's capabilities for
this resource.</t>
          </dd>
          <dt>input:</dt>
          <dd>
            <t>If the resource is a POST-mode service that requires input, the
ALTO client <bcp14>MUST</bcp14> set the "input" field to a JSON object with the
parameters that the resource expects.</t>
          </dd>
        </dl>
      </section>
      <section anchor="open-resp">
        <name>Open Response</name>
        <t>The response to a valid request <bcp14>MUST</bcp14> be a JSON object of type
AddTIPSResponse, the AddTIPSResponse type, denoted as media type "application/alto-tips+json":</t>
        <figure anchor="fig-open-resp">
          <name>AddTIPSResponse</name>
          <artwork align="left"><![CDATA[
          <sourcecode type=""><![CDATA[
    object {
      URI               tips-view-uri;
      TIPSViewSummary   tips-view-summary;
    } AddTIPSResponse;

    object {
      UpdatesGraphSummary   updates-graph-summary;
    } TIPSViewSummary;

    object {
      JSONNumber       start-seq;
      JSONNumber       end-seq;
      StartEdgeRec     start-edge-rec;
    } UpdatesGraphSummary;

    object {
      JSONNumber       seq-i;
      JSONNumber       seq-j;
    } StartEdgeRec;
]]></artwork>
]]></sourcecode>
        </figure>
        <t>with the following fields:</t>
        <dl>
          <dt>tips-view-uri:</dt>
          <dd>
            <t>URI
            <t>This is the URI to the requested TIPS view. The value of this field <bcp14>MUST</bcp14> have the
following format:
</t>
            <artwork><![CDATA[
            <sourcecode type=""><![CDATA[
    scheme "://" tips-view-host "/" tips-view-path

    tips-view-host = host [ ":" port]
    tips-view-path = path
]]></artwork>
]]></sourcecode>
            <t>where scheme <bcp14>MUST</bcp14> be "http" or "https" unless specified by a future
extension, and host, port port, and path are as specified in Sections 3.2.2, 3.2.3, <xref target="RFC3986" sectionFormat="bare" section="3.2.2"/>, <xref target="RFC3986" sectionFormat="bare"
section="3.2.3"/>, and 3.3 <xref target="RFC3986" sectionFormat="bare"
section="3.3"/> in <xref target="RFC3986"/>. An ALTO server <bcp14>SHOULD</bcp14> use the "https" scheme unless
the contents of the TIPS view are intended to be publicly accessible and does do
not raise security concerns. The field <bcp14>MUST</bcp14> contain only ASCII characters. In
case the original URL contains international characters (e.g., in the domain
name), the ALTO server implementation <bcp14>MUST</bcp14> properly encode the URL into the
ASCII format (e.g., using the "urlencode" function).</t>
            <t>A server <bcp14>MUST NOT</bcp14> use the same URI for different TIPS views, either for
different resources or for different request bodies to the same resource. URI
generation is implementation specific, specific; for example, one may compute a
Universally Unique Identifier (UUID, (UUID) <xref target="RFC4122"/>) target="RFC9562"/> or a hash value based on
the request, request and append it to a base URL. For performance considerations, it
is <bcp14>NOT RECOMMENDED</bcp14> to use properties that are not included in the request
body to determine the URI of a TIPS view, such as cookies or the client's IP
address, which may result in duplicated TIPS views in cases such as mobile
clients. However, this is not mandatory as a server may might intentionally use
client information to compute the TIPS view URI to provide service isolation
between clients.</t>
          </dd>
          <dt>tips-view-summary:</dt>
          <dd>
            <t>Contains an updates-graph-summary.
</t>
            <t>The updates-graph-summary "updates-graph-summary" field contains the starting sequence number
(start-seq)
&lt;start-seq&gt; of the updates graph (in the "start-seq" field) and the last sequence number (end-seq) &lt;end-seq&gt; that
is currently available, available (in the "end-seq" field), along with a recommended edge to consume
(start-edge-rec).
(in the "start-edge-rec" field). If the client does NOT not provide a version tag, the server
<bcp14>MUST</bcp14> recommend the edge of the latest snapshot available. available snapshot.
If the client does provide provides a version tag, the server <bcp14>MUST</bcp14> either recommend
the first incremental update edge starting from the client's tagged version
or recommend the edge of the latest snapshot. Which snapshot: which edge is selected depends on the
implementation. For example, a server <bcp14>MAY</bcp14> calculate the cumulative size of
the incremental updates available from that version onward and compare it to
the size of the complete resource snapshot. If the snapshot is bigger, the
server recommends the first incremental update edge starting from the
client's tagged version. Otherwise, the server recommends the latest snapshot
edge.</t>
          </dd>
        </dl>
        <t>If the request has any errors, the TIPS service ALTO server <bcp14>MUST</bcp14> return an HTTP
"400 Bad Request"
400 (Bad Request) error code to the ALTO client; the body of the response
follows the generic ALTO error response format specified in
Section 8.5.2 of
<xref target="RFC7285"/>. target="RFC7285" sectionFormat="of" section="8.5.2"/>.  Hence, an example ALTO error response
has the format shown in <xref target="ex-bad-request"/>.</t>
        <figure anchor="ex-bad-request">
          <name>ALTO Error Example</name>
          <artwork align="left"><![CDATA[
          <sourcecode type=""><![CDATA[
    HTTP/1.1 400 Bad Request
    Content-Length: 131
    Content-Type: application/alto-error+json

    {
        "meta":{
            "code":  "E_INVALID_FIELD_VALUE",
            "field": "resource-id",
            "value": "my-network-map/#"
        }
    }
]]></artwork>
]]></sourcecode>
        </figure>
        <t>Note that "field" and "value" are optional fields.  If the "value"
field exists, the "field" field <bcp14>MUST</bcp14> exist.</t>
        <ul spacing="normal">
          <li>If the TIPS request does not have a "resource-id" field, the error code of
the error message <bcp14>MUST</bcp14> be <tt>E_MISSING_FIELD</tt> "E_MISSING_FIELD" and the "field" field, if
present, <bcp14>MUST</bcp14> be "resource-id". The TIPS service ALTO server <bcp14>MUST NOT</bcp14> create any TIPS
view.</li>
          <li>If the "resource-id" field is invalid or is not associated with the TIPS, TIPS information resource, the
error code of the error message <bcp14>MUST</bcp14> be <tt>E_INVALID_FIELD_VALUE</tt>. "E_INVALID_FIELD_VALUE". If present,
the "field" field <bcp14>MUST</bcp14> be the full path of the "resource-id" field, and the
"value" field <bcp14>MUST</bcp14> be the invalid resource-id.</li> value of the "resource-id" field in the request.</li>
          <li>If the resource is a POST-mode service that requires input, the client <bcp14>MUST</bcp14>
set the "input" field to a JSON object with the parameters that that resource
expects. If the "input" field is missing or invalid, TIPS the ALTO server <bcp14>MUST</bcp14> return the
same error response that resource would return for missing or invalid input inputs
(see <xref target="RFC7285"/>).</li>
        </ul>
        <t>Furthermore, it is <bcp14>RECOMMENDED</bcp14> that the server uses use the following HTTP codes code to
indicate other errors, with the media type "application/alto-error+json".</t>
        <ul
        <dl spacing="normal">
          <li>429
          <dt>429 (Too Many Requests): Requests):</dt><dd>Indicates when the number of TIPS views open requests exceeds
the server threshold. The server <bcp14>MAY</bcp14> indicate when to re-try retry the request in
the "Re-Try After" headers.</li>
        </ul> headers.</dd>
        </dl>
        <t>It is <bcp14>RECOMMENDED</bcp14> that the server provide the ALTO/SSE support for the TIPS
resource. Thus, the client can be notified of the version updates of all the
TIPS views that it monitors and make better cross-resource transport decisions
(see <xref target="cross-sched"/> for related considerations).</t>
      </section>
      <section anchor="open-example">
        <name>Open Example</name>
        <section anchor="basic-example">
          <name>Basic Example</name>

          <t>For simplicity, assume that the ALTO server is using the Basic
authentication.
authentication <xref target="RFC7617"/>.  If a client with username "client1" and password
"helloalto" wants to create a TIPS view of an ALTO Cost Map cost map resource
with the resource ID "my-routingcost-map", it can send the
request depicted in <xref target="ex-op"/>.</t>
          <figure anchor="ex-op">
            <name>Request Example of Opening a TIPS View</name>
            <artwork align="left"><![CDATA[
            <sourcecode type=""><![CDATA[
    POST /tips HTTP/1.1
    Host: alto.example.com
    Accept: application/alto-tips+json, application/alto-error+json
    Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K
    Content-Type: application/alto-tipsparams+json
    Content-Length: 41

    {
      "resource-id": "my-routingcost-map"
    }
]]></artwork>
]]></sourcecode>
          </figure>
          <t>If the operation is successful, the ALTO server returns the
message shown in <xref target="ex-op-rep"/>.</t>
          <figure anchor="ex-op-rep">
            <name>Response Example of Opening a TIPS View</name>
            <artwork align="left"><![CDATA[
            <sourcecode type=""><![CDATA[
    HTTP/1.1 200 OK
    Content-Type: application/alto-tips+json
    Content-Length: 255

    {
      "tips-view-uri": "https://alto.example.com/tips/2718281828",
      "tips-view-summary": {
        "updates-graph-summary": {
          "start-seq": 101,
          "end-seq": 106,
          "start-edge-rec" : {
            "seq-i": 0,
            "seq-j": 105
          }
        }
      }
    }
]]></artwork>
]]></sourcecode>
          </figure>
        </section>
        <section anchor="example-using-digest-authentication">
          <name>Example using Using Digest Authentication</name>
          <t>Below is another example of the same query using Digest authentication, a
mandatory authentication method of ALTO servers as defined in <xref section="8.3.5" sectionFormat="of" target="RFC7285"/>. The content of the response is the same as in <xref target="ex-op-rep"/> and thus target="ex-op-rep"/>; thus, it has been
omitted for simplicity.</t>
          <figure anchor="ex-op-digest">
            <name>Open Example with Digest Authentication</name>
            <artwork align="left"><![CDATA[
            <sourcecode type=""><![CDATA[
    POST /tips HTTP/1.1
    Host: alto.example.com
    Accept: application/alto-tips+json, application/alto-error+json
    Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K
    Content-Type: application/alto-tipsparams+json
    Content-Length: 41

    {
      "resource-id": "my-routingcost-map"
    }

    HTTP/1.1 401 UNAUTHORIZED
    WWW-Authenticate: Digest
        realm="alto.example.com",
        qop="auth",
        algorithm="MD5",
        nonce="173b5aba4242409ee2ac3a4fd797f9d7",
        opaque="a237ff9ab865379a69d9993162ef55e4"

    POST /tips HTTP/1.1
    Host: alto.example.com
    Accept: application/alto-tips+json, application/alto-error+json
    Authorization: Digest
        username="client1",
        realm="alto.example.com",
        uri="/tips",
        qop=auth,
        algorithm=MD5,
        nonce="173b5aba4242409ee2ac3a4fd797f9d7",
        nc=00000001,
        cnonce="ZTg3MTI3NDFmMDQ0NzI1MDQ3MWE3ZTFjZmM5MTNiM2I=",
        response="8e937ae696c1512e4f990fa21c7f9347",
        opaque="a237ff9ab865379a69d9993162ef55e4"
    Content-Type: application/alto-tipsparams+json
    Content-Length: 41

    {
      "resource-id": "my-routingcost-map"
    }

    HTTP/1.1 200 OK
    Content-Type: application/alto-tips+json
    Content-Length: 258

    {....}
]]></artwork>
]]></sourcecode>
          </figure>
        </section>
        <section anchor="tips-sse">
          <name>Example using Using ALTO/SSE</name>
          <t>This section gives an example of receiving incremental updates of the TIPS view
summary using ALTO/SSE <xref target="RFC8895"/>. Consider the <tt>tips-sse</tt> "tips-sse" resource, as
announced by the IRD in <xref target="ex-ird"/>, which provides ALTO/SSE for the
<tt>update-my-cost-tips</tt> resource,
"update-my-cost-tips" resource; a client may might send the following request to
receive updates of the TIPS view (authentication is omitted for simplicity).</t>
          <figure anchor="ex-tips-sse">
            <name>Example of Monitoring TIPS view View with ALTO/SSE</name>
            <artwork align="left"><![CDATA[
            <sourcecode type=""><![CDATA[
    POST /updates/tips HTTP/1.1
    Host: alto.example.com
    Accept: text/event-stream,application/alto-error+json
    Content-Type: application/alto-updatestreamparams+json
    Content-Length: 76

    {
      "add": {
        "tips-123": { "resource-id": "update-my-cost-tips" }
      }
    }
]]></artwork>
]]></sourcecode>
          </figure>
          <t>Then, the client will be able to receive the TIPS view summary as follows.</t>
          <artwork><![CDATA[
          <sourcecode type=""><![CDATA[
 HTTP/1.1 200 OK
 Connection: keep-alive
 Content-Type: text/event-stream

 event: application/alto-tips+json,tips-123
 data: {
 data:   "tips-view-uri": "https://alto.example.com/tips/2718281828",
 data:   "tips-view-summary": {
 data:     "updates-graph-summary": {
 data:       "start-seq": 101,
 data:       "end-seq": 106,
 data:       "start-edge-rec" : {
 data:         "seq-i": 0,
 data:         "seq-j": 105
 data:       }
 data:     }
 data:   }
 data: }
]]></artwork>
]]></sourcecode>
          <t>When there is an update to the TIPS view, for view (for example, when the <tt>end-seq</tt> "end-seq" field is
increased by 1, 1), the client will be able to receive the incremental update of the
TIPS view summary as follows.</t>
          <artwork><![CDATA[
          <sourcecode type=""><![CDATA[
    event: application/merge-patch+json,tips-123
    data: {
    data:   "tips-view-summary": {
    data:     "updates-graph-summary": {
    data:       "end-seq": 107
    data:     }
    data:   }
    data: }
]]></artwork>
]]></sourcecode>
        </section>
      </section>
    </section>
    <section anchor="pull">
      <name>TIPS Data Transfers - Client Pull</name>
      <t>TIPS allows an ALTO client to retrieve the content of an update item
from the updates graph, with an update item defined as the content
(incremental update or snapshot) on an edge in the updates graph.</t>
      <section anchor="request">
        <name>Request</name>
        <t>The client sends an HTTP GET request, where the media type of an
update item resource <bcp14>MUST</bcp14> be the same as the "media-type" field of
the update item on the specified edge in the updates graph.</t>
        <t>The GET request <bcp14>MUST</bcp14> have the following format:</t>
        <artwork><![CDATA[
        <sourcecode type=""><![CDATA[
    GET /<tips-view-path>/ug/<i>/<j>
    HOST: <tips-view-host>
]]></artwork>
]]></sourcecode>
        <t>For example, consider the updates graph in <xref target="fig-ug-schema"/>. If the client
wants to query the content of the first update item (0 -&gt; 101) whose media type
is "application/alto-costmap+json", it sends a request to
"/tips/2718281828/ug/0/101" and sets the "Accept" header to
"application/alto-costmap+json,application/alto-error+json". See <xref target="iu-example"/>
for a concrete example.</t>
      </section>
      <section anchor="response">
        <name>Response</name>
        <t>If the request is valid (<tt>ug/&lt;i&gt;/&lt;j&gt;</tt> (i.e., "ug/&lt;i&gt;/&lt;j&gt;" exists), the response is encoded
as a JSON object whose data format is indicated by the media type.</t>
        <t>A client <bcp14>MAY</bcp14> conduct proactive fetching of future updates, by long polling
updates that have not been provided in the directory yet. For such updates, the
client <bcp14>MUST</bcp14> indicate all media types that may might appear. It is <bcp14>RECOMMENDED</bcp14> that the
server allows allow for at least the long polling of <tt>&lt;end-seq&gt; &lt;end-seq&gt; -&gt; &lt;end-seq + 1&gt;</tt>.</t> 1&gt;.</t>
        <t>Hence, the server processing logic <bcp14>MUST</bcp14> be:</t>
        <ul spacing="normal">
          <li>If <tt>ug/&lt;i&gt;/&lt;j&gt;</tt> exists: a resource with path "ug/&lt;i&gt;/&lt;j&gt;" exists, return content using encoding.</li>
          <li>Else
          <li>Else, if long polling <tt>ug/&lt;i&gt;/&lt;j&gt;</tt> "ug/&lt;i&gt;/&lt;j&gt;" is acceptable: acceptable, put request in a
backlog queue, then either a response is triggered when the content is ready
or the request is interrupted, e.g., interrupted (e.g., by a network error.</li>
          <li>Else: error).</li>
          <li>Else, return error.</li>
        </ul>
        <t>It is <bcp14>RECOMMENDED</bcp14> that the server uses use the following HTTP codes to
indicate errors, with the media type "application/alto-error+json",
regarding update item requests.</t>
        <ul
        <dl spacing="normal">
          <li>404
          <dt>404 (Not Found): if Found):</dt><dd>Indicates that the requested update does not exist, exist or the requested
TIPS view does not exist or is closed by the server.</li>
          <li>410 (Gone): if server.</dd>
          <dt>410 (Gone):</dt><dd>Indicates an update has a seq that is smaller than the start-seq.</li>
          <li>415 &lt;start-seq&gt;.</dd>
          <dt>415 (Unsupported Media Type): if Type):</dt><dd>Indicates the media type(s) type (or types) accepted by the
client does not include the media type of the update chosen by the
server.</li>
          <li>425
server.</dd>
          <dt>425 (Too Early): if Early):</dt><dd>Indicates the seq exceeds the server long-polling window</li>
          <li>429 long polling window.</dd>
          <dt>429 (Too Many Requests): when Requests):</dt><dd>Indicates the number of pending (long-poll) (long poll)
requests exceeds the server threshold. The server <bcp14>MAY</bcp14> indicate when to re-try retry
the request in the "Re-Try After" headers.</li>
        </ul> headers.</dd>
        </dl>
      </section>
      <section anchor="iu-example">
        <name>Example</name>
        <t>Assume the client wants to get the contents of the update item on
edge 0 to 101.  The format of the request is shown in <xref target="ex-get"/>.</t>
        <figure anchor="ex-get">
          <name>GET Example</name>
          <artwork align="left"><![CDATA[
          <sourcecode type=""><![CDATA[
    GET /tips/2718281828/ug/0/101 HTTP/1.1
    Host: alto.example.com
    Accept: application/alto-costmap+json, \
              application/alto-error+json
]]></artwork>
]]></sourcecode>
        </figure>
        <t>The response is shown in <xref target="ex-get-res"/>.</t>
        <figure anchor="ex-get-res">
          <name>Response to a GET Request</name>
          <artwork align="left"><![CDATA[
          <sourcecode type=""><![CDATA[
    HTTP/1.1 200 OK
    Content-Type: application/alto-costmap+json
    Content-Length: 50

    { ... full replacement of my-routingcost-map ... }
]]></artwork>
]]></sourcecode>
        </figure>
      </section>
      <section anchor="new-next-edge-recommendation">
        <name>New Next Edge Recommendation</name>
        <t>While intended TIPS usage is for the client to receive a recommended
starting edge in the TIPS summary, consume that edge, and then construct
all future URIs by incrementing the sequence count by 1, one, there may be
cases in which the client needs to request a new next edge to
consume.  For example, if a client has an open TIPS view yet but has not
polled in a while, the client may might request the next logical
incremental URI but URI; however, the server has compacted the updates graph graph, so it
no longer exists.  Thus, the client <bcp14>MAY</bcp14> request a new next edge to
consume based on its current version of the resource.</t>
        <section anchor="request-1">
          <name>Request</name>
          <t>An ALTO client requests that the server provide a next edge recommendation for a
given TIPS view by sending an HTTP POST request with the media type
"application/alto-tipsparams+json". The URL of the request <bcp14>MUST</bcp14> have the format of</t>
          <artwork><![CDATA[ following format:</t>
          <sourcecode type=""><![CDATA[
    <tips-view-path>/ug
]]></artwork>
]]></sourcecode>
          <t>and the <tt>HOST</tt> "HOST" field <bcp14>MUST</bcp14> be the <tt>&lt;tips-view-host&gt;</tt>.</t> "&lt;tips-view-host&gt;".</t>
          <t>The POST body has the same format as the TIPSReq in <xref target="fig-open-req"/>. The
<tt>resource-id</tt>
"resource-id" field <bcp14>MUST</bcp14> be the same as the resource ID used to create the TIPS view,
and the optional <tt>input</tt> "input" field <bcp14>MUST NOT</bcp14> be present.</t>
        </section>
        <section anchor="response-1">
          <name>Response</name>
          <t>The response to a valid request <bcp14>MUST</bcp14> be a JSON merge patch to the object of type the AddTIPSResponse type (defined in <xref target="open-resp"/>), denoted as media type
"application/merge-patch+json". The "update-graph-summary" "updates-graph-summary" field <bcp14>MUST</bcp14> be present
in the response and hence response; hence, its parent field "tips-view-summary" <bcp14>MUST</bcp14> be present
as well.</t>
          <t>If the <tt>tag</tt> "tag" field is present in the request, the server <bcp14>MUST</bcp14> check if any
version within the range [start-seq, end-seq] [&lt;start-seq&gt;, &lt;end-seq&gt;] has the same tag value. If the
version exists, e.g., exists (e.g., denoted as tag-seq, &lt;tag-seq&gt;), the server <bcp14>MUST</bcp14> compute the paths from
both tag-seq &lt;tag-seq&gt; and 0 to the end-seq, &lt;end-seq&gt; and choose the one with the minimal cost. The
cost <bcp14>MAY</bcp14> be implementation specific, e.g., specific (e.g., number of messages, accumulated data
size, etc. etc.). The first edge of the selected path <bcp14>MUST</bcp14> be returned as the
	  recommended next edge.</t>

          <t>If the <tt>tag</tt> "tag" field is NOT not present, it the interpretation   <bcp14>MUST</bcp14> be interpreted as that the tag-seq &lt;tag-seq&gt; is 0.</t>
          <t>It is <bcp14>RECOMMENDED</bcp14> that the server uses use the following HTTP codes code to
indicate errors, with the media type "application/alto-error+json",
regarding new next edge requests.</t>
          <ul
          <dl spacing="normal">
            <li>404
            <dt>404 (Not Found): if Found):</dt><dd>Indicates that the requested TIPS view does not exist or is has been
closed by the server.</li>
          </ul> server.</dd>
          </dl>
        </section>
        <section anchor="example">
          <name>Example</name>
          <t>We
          <t>In this section, we give an example of the new next edge recommendation service. Assume that a
client already creates a TIPS view as (as in <xref target="open-example"/>, target="open-example"/>) whose updates graph
is as shown in <xref target="fig-ug"/>. Now assume that the client already has tag 0881080 0881080,
whose corresponding sequence number is 103, and sends the following new next
edge recommendation request (authentication is omitted for simplicity):</t>
          <artwork><![CDATA[
          <sourcecode type=""><![CDATA[
    POST /tips/2718281828/ug HTTP/1.1
    HOST alto.example.com
    Accept: application/merge-patch+json, application/alto-error+json
    Content-Type: application/alto-tipsparams+json
    Content-Length: 62

    {
      "resource-id": "my-routingcost-map",
      "tag": "0881080"
    }
]]></artwork>
]]></sourcecode>
          <t>According to <xref target="fig-ug"/>, there are 3 three potential paths: 103 -&gt; 104 -&gt; 105 -&gt; 106,
103 -&gt; 105 -&gt; 106, and 0 -&gt; 105 -&gt; 106. Assume that the server chooses the shortest
update path by the accumulated data size and the best path is 103 -&gt; 105 -&gt; 106.
Thus, the server responds with the following message:</t>
          <artwork><![CDATA[
          <sourcecode type=""><![CDATA[
    HTTP/1.1 200 OK
    Content-Type: application/merge-patch+json
    Content-Length: 193

    {
      "tips-view-summary": {
        "updates-graph-summary": {
          "start-seq": 101,
          "end-seq": 106,
          "start-edge-rec": {
            "seq-i": 103,
            "seq-j": 105
          }
        }
      }
    }
]]></artwork>
]]></sourcecode>
        </section>
      </section>
    </section>
    <section anchor="ops-considerations">
      <name>Operation and Processing Considerations</name>
      <t>TIPS has some common operational considerations as ALTO/SSE <xref target="RFC8895"/>,
including:</t>
      <ul spacing="normal">
        <li>server
        <li>the server choosing update messages (<xref section="9.1" sectionFormat="of" target="RFC8895"/>);</li>
        <li>client
        <li>the client processing update messages (<xref section="9.2" sectionFormat="of" target="RFC8895"/>);</li>
        <li>updates
        <li>the updates of filtered map services (<xref section="9.3" sectionFormat="of" target="RFC8895"/>);</li>
        <li>updates target="RFC8895"/>); and</li>
        <li>the updates of ordinal mode costs (<xref section="9.4" sectionFormat="of" target="RFC8895"/>).</li>
      </ul>

      <t>There are also some operation operational considerations specific to TIPS, which we discuss
below.</t>
      <section anchor="load-balancing">
        <name>Considerations for Load Balancing</name>
        <t>There are two levels of load balancing in TIPS. The TIPS: the first level is to balance
the load of TIPS views for different clients, clients and the second is to balance the
load of incremental updates.</t>
        <t>Load balancing of TIPS views can be achieved either at the application layer or
at the infrastructure layer. For example, an ALTO server <bcp14>MAY</bcp14> set
<tt>&lt;tips-view-host&gt;</tt>
&lt;tips-view-host&gt; to different subdomains to distribute TIPS views, views or simply
use the same host of the TIPS service information resource and rely on load balancers to distribute
	the load.</t>

        <t>TIPS allows a client to make concurrent pulls of incremental updates for the
same TIPS view view, potentially through different HTTP connections. As a consequence,
it
TIPS introduces additional complexities when the ALTO server is being balances the load
balanced. by distributing the requests to a set of backend servers. For example, a request may might be directed to a the wrong backend server and
get incorrectly processed incorrectly if the following two conditions both hold:</t>
        <ul spacing="normal">
          <li>the
          <li>these backend servers are stateful, i.e., stateful (i.e., the TIPS view is created
and stored only on a single server;</li> server); and</li>
          <li>the ALTO server is using layer-4 Layer 4 load balancing, i.e., balancing (i.e., the
requests are distributed based on the TCP 5-tuple.</li> 5-tuple).</li>
        </ul>
        <t>Thus, additional considerations are required to enable correct load
balancing for TIPS, including:</t>
        <ul
        <dl spacing="normal">
          <li>Use
          <dt>Using a stateless architecture: One architecture:</dt><dd>One solution is to follow the
stateless computing pattern: states about the TIPS view are not
maintained by the backend servers but are stored in a distributed
database.  Thus, concurrent requests to the same TIPS view can be
processed on arbitrary stateless backend servers, which all
fetches
fetch data from the same database.</li>
          <li>Configure database.</dd>
          <dt>Configuring the load balancers properly: In properly:</dt><dd>In the case when that the backend
servers are stateful, the load balancers must be properly
configured to guarantee that requests of the same TIPS view always
arrive at the same server.  For example, an operator or a provider
of an ALTO server <bcp14>MAY</bcp14> configure layer-7 Layer 7 load balancers that
distribute requests based on the tips-view-path component in the URI.</li>
        </ul> URI.</dd>
        </dl>
      </section>
      <section anchor="cross-sched">
        <name>Considerations for Cross-Resource Dependency Scheduling</name>
        <t>Dependent ALTO resources result in cross-resource dependencies in
TIPS.  Consider the following pair of resources, where my-cost-map
(C) is dependent on my-network-map (N).  The updates graph for each
resource is shown, along with links in between the respective updates
graphs to show dependency:</t>
        <figure anchor="fig-cross">
          <name>Example Dependency Model</name>
          <artwork type="drawing" align="center"><![CDATA[
                       +---+   +---+   +---+   +---+   +---+
  my-network-map (N)   | 0 |-->|89 |-->|90 |-->|91 |-->|92 |
                       +---+   +---+   +---+   +---+   +---+
                                 |   \       \       \
                                 |    \       \       \
                       +---+   +---+   +---+   +---+   +---+
  my-cost-map (C)      | 0 |-->|101|-->|102|-->|103|-->|104|
                       +---+   +---+   +---+   +---+   +---+
                        |_______________________|
]]></artwork>
        </figure>
        <t>In <xref target="fig-cross"/>, the cost-map versions 101 and 102 (denoted as C101 and C102)
are dependent on the network-map version 89 (denoted as N89). The cost-map
version 103 (C103) is dependent on the network-map version 90 (N90), and so on.</t>
        <t>Thus, the client must decide the order in which to receive and apply the
updates. The order may affect how fast the client can build a consistent view
and how long the client needs to buffer the update.</t>
        <ul
        <dl spacing="normal">
          <li>Example 1: The
          <dt>Example 1:</dt><dd>The client requests N89, N90, N91, C101, C102 in that
order.  The client either gets no consistent view of the resources
or has to buffer N90 and N91.</li>
          <li>Example 2: The N91.</dd>
          <dt>Example 2:</dt><dd>The client requests C101, C102, C103, N89.  The client
either gets no consistent view or has to buffer C103.</li>
        </ul> C103.</dd>
        </dl>

        <t>To get consistent ALTO information, a client must process the updates following
the guidelines specified in <xref section="9.2" sectionFormat="of" target="RFC8895"/>. If resource permits resources permit
(i.e., sufficient updates can be buffered), an ALTO client can safely use long
polling to fetch all the updates. This allows a client to build consistent views
quickly as the updates are already stored in the buffer. Otherwise, it is
            <bcp14>RECOMMENDED</bcp14> to request</t> request a full snapshot if the client does not have enough local resources to
            buffer and process the incremental updates.</t>
      </section>
      <section anchor="shared-tips-view">
        <name>Considerations for Managing Shared TIPS Views</name>
        <t>From a client's point of view, it sees only one copy of the TIPS view
for any resource.  However, on the server side, there are different
implementation options, especially for common resources (e.g.,
network map maps or cost map) maps) that may be frequently queried by many
clients.  Some potential options are listed below:</t>
        <ul spacing="normal">
          <li>An ALTO server creates one TIPS view of the common resource for
each client.</li>
<li>

            <t>An ALTO server maintains one copy of the TIPS view for each common
resource and all clients requesting the same resources use the
same copy.  There are two ways to manage the storage for the
shared copy:  </t> copy:</t>
            <ul spacing="normal">
              <li>the ALTO server maintains the set of clients that have sent a polling
request to the TIPS view, view and only removes the view from the storage when
the set becomes empty and no client immediately issues a new edge request;</li> request; or</li>
              <li>the TIPS view is never removed from the storage.</li>
            </ul>
          </li>
        </ul>
        <t>Developers may choose different implementation options depending on
criteria such as request frequency, available resources of the ALTO
server, the ability to scale, and programming complexity.</t>
      </section>
      <section anchor="considerations-for-offering-shortcut-incremental-updates">
        <name>Considerations for Offering Shortcut Incremental Updates</name>
        <t>Besides the mandatory stepwise incremental updates (from i to i+1),
an ALTO server <bcp14>MAY</bcp14> optionally offer shortcut incremental updates, or
simple shortcuts, between two non-consecutive versions i and i+k (k &gt;
1).  Such shortcuts offer alternative paths in the update updates graph and
can potentially speed up the transmission and processing of
incremental updates, leading to faster synchronization of ALTO
information, especially when the client has limited bandwidth and
computation.  However, implementors of an ALTO server must be aware
that:</t>

        <ol spacing="normal" type="1"><li>Optional type="1"><li>optional shortcuts may increase the size of the update updates graph, in
the worst case scenario being the square of the number of updates (i.e.,
when a shortcut is offered for each version to all future
versions).</li>
          <li>Optional
          <li>optional shortcuts require additional storage on the ALTO server.</li>
          <li>Optional
          <li>optional shortcuts may reduce concurrency when the updates do not
overlap, e.g.,
overlap (e.g., when the updates apply to different parts of an
ALTO resource. resource).  In such a case, the total size of the original
updates is close to the size of the shortcut, but the original
updates can be transmitted concurrently while the shortcut is
transmitted in a single connection.</li>
        </ol>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security considerations (Section 15 of <xref target="RFC7285"/>) of the base protocol (<xref
      target="RFC7285" sectionFormat="of" section="15"/>) fully apply to this
      extension.  For example, the same authenticity and integrity
      considerations (Section 15.1 of <xref target="RFC7285"/>) (<xref target="RFC7285" sectionFormat="of"
      section="15.1"/>) still fully apply; the same considerations for the
      privacy of ALTO users (Section 15.4 of <xref target="RFC7285"/>) (<xref target="RFC7285" sectionFormat="of"
      section="15.4"/>) also still fully apply. Additionally, operators of the
      ALTO servers <bcp14>MUST</bcp14> follow the guidelines in <xref
      target="RFC9325"/> to avoid new TLS vulnerabilities discovered after
      <xref target="RFC7285"/> was published.</t>
      <t>The additional services (addition (the addition of update read service and update
push service) provided by this extension extend the attack surface
described in Section 15.1.1 of <xref target="RFC7285"/>. target="RFC7285" sectionFormat="of" section="15.1.1"/>.  The following sub-sections subsections discuss the
additional risks and their remedies.</t>
      <section anchor="tips-denial-of-service-attacks">
        <name>TIPS: Denial-of-Service Attacks</name>
        <t>Allowing TIPS views enables new classes of Denial-of-Service DoS attacks. In
particular, for the TIPS server, one or multiple malicious ALTO clients might
create an excessive number of TIPS views, to exhaust the server resource and/or
to block normal users from the accessing the service.</t>
        <t>To avoid such attacks, the server <bcp14>MAY</bcp14> choose to limit the number of active
views and reject new requests when that threshold is reached. TIPS allows
predictive fetching and the server <bcp14>MAY</bcp14> also choose to limit the number of
pending requests. If a new request exceeds the threshold, the server <bcp14>MAY</bcp14> log
the event and return the HTTP status "429 Too many requests".</t> 429 (Too Many Requests).</t>
        <t>It is important to note that the preceding approaches are not the only
possibilities. For example, it may might be possible for a TIPS server to use somewhat more
clever logic involving TIPS view eviction policies, IP reputation,
rate-limiting, and compartmentalization of the overall threshold into smaller
thresholds that apply to subsets of potential clients. If service availability
is a concern, ALTO clients <bcp14>MAY</bcp14> establish service level agreements with the ALTO
server.</t>
      </section>
      <section anchor="alto-client-update-overloading-or-instability">
        <name>ALTO Client: Update Overloading or Instability</name>
        <t>The availability of continuous updates can also cause overload for an ALTO
client, in particular, an ALTO client with limited processing capabilities. The
current design does not include any flow control mechanisms for the client to
reduce the update rates from the server. For example, TCP, HTTP/2 HTTP/2, and QUIC
provide stream and connection flow control data limits, which might help prevent
the client from being overloaded. Under overloading, the client <bcp14>MAY</bcp14> choose to
remove the information resources with high update rates.</t>
        <t>Also, under overloading, the client may might no longer be able to detect
whether information is still fresh or has become stale.  In such a
case, the client should be careful in how it uses the information to
avoid stability or efficiency issues.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is requested to register has registered the following media types from the registry available at <xref target="IANA-Media-Type"/>:</t>

      <ul spacing="normal">
        <li>application/alto-tips+json: as described in <xref target="open-resp"/>;</li>
        <li>application/alto-tipsparams+json: as described in <xref target="open-req"/>;</li>
      </ul>
      <ul empty="true">
        <li>
          <t>Note to the RFC Editor: Please replace This-Document with the RFC number to be assigned to this document.</t>
        </li>
      </ul>

      <section anchor="applicationalto-tipsjson-media-type">
        <name>application/alto-tips+json Media Type</name>
        <dl>
          <dt>Type name:</dt>
          <dd>
            <t>application</t>
          </dd>
          <dd>application</dd>

          <dt>Subtype name:</dt>
          <dd>
            <t>alto-tips+json</t>
          </dd>
          <dd>alto-tips+json</dd>

          <dt>Required parameters:</dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dd>N/A</dd>

          <dt>Optional parameters:</dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dd>N/A</dd>

          <dt>Encoding considerations:</dt>
          <dd>
            <t>Encoding
          <dd>Encoding considerations are identical to those specified for the
"application/json" media type. See <xref target="RFC8259"/>.</t>
          </dd> target="RFC8259"/>.</dd>

          <dt>Security considerations:</dt>
          <dd>
            <t>See
          <dd>See the Security Considerations section of This-Document.</t>
          </dd> RFC 9569.</dd>

          <dt>Interoperability considerations:</dt>
          <dd>
            <t>N/A.</t>
          </dd>
          <dd>N/A</dd>

          <dt>Published specification:</dt>
          <dd>
            <t><xref
          <dd><xref target="open-resp"/> of This-Document.</t>
          </dd> RFC 9569.</dd>

          <dt>Applications that use this media type:</dt>
          <dd>
            <t>ALTO
          <dd>ALTO servers and ALTO clients either stand alone or are embedded within other
applications.</t>
          </dd>
applications.</dd>

          <dt>Fragment identifier considerations:</dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dd>N/A</dd>

          <dt>Additional information:</dt>
          <dd>
            <t><br/>
            </t>
            <dl> information:</dt><dd>
	  <t><br/></t>
            <dl spacing="compact">
              <dt>Deprecated alias names for this type:</dt>
              <dd>
                <t>N/A</t>
              </dd>
              <dd>N/A</dd>

              <dt>Magic number(s):</dt>
              <dd>
                <t>N/A</t>
              </dd>
              <dd>N/A</dd>

              <dt>File extension(s):</dt>
              <dd>
                <t>This document
              <dd>RFC 9569 uses the media type to refer to protocol messages and thus messages; thus, it
 does not require a file extension.</t>
              </dd> extension.</dd>

              <dt>Macintosh file type code(s):</dt>
              <dd>
                <t>N/A</t>
              </dd>
              <dd>N/A</dd>
            </dl>
          </dd>
          <dt>Person and &amp; email address to contact for further information:</dt>
          <dd>
            <t>See
          <dd><br/>See the Authors' Addresses section.</t>
          </dd> section of RFC 9569.</dd>

          <dt>Intended usage:</dt>
          <dd>
            <t>COMMON</t>
          </dd>
          <dd>COMMON</dd>

          <dt>Restrictions on usage:</dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dd>N/A</dd>

          <dt>Author:</dt>
          <dd>
            <t>See
          <dd>See the Authors' Addresses section.</t>
          </dd> section of RFC 9569.</dd>

          <dt>Change controller:</dt>
          <dd>
            <t>Internet
          <dd>Internet Engineering Task Force (mailto:iesg@ietf.org).</t>
          </dd>
          <dt>Provisional registration?:</dt>
          <dd>
            <t>No</t>
          </dd> (iesg@ietf.org).</dd>

        </dl>
      </section>
      <section anchor="applicationalto-tipsparamsjson-media-type">
        <name>application/alto-tipsparams+json Media Type</name>
        <dl>
          <dt>Type name:</dt>
          <dd>
            <t>application</t>
          </dd>
          <dd>application</dd>

          <dt>Subtype name:</dt>
          <dd>
            <t>alto-tipsparams+json</t>
          </dd>
          <dd>alto-tipsparams+json</dd>

          <dt>Required parameters:</dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dd>N/A</dd>

          <dt>Optional parameters:</dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dd>N/A</dd>

          <dt>Encoding considerations:</dt>
          <dd>
            <t>Encoding
          <dd>Encoding considerations are identical to those specified for the
 "application/json" media type. See <xref target="RFC8259"/>.</t>
          </dd> target="RFC8259"/>.</dd>

          <dt>Security considerations:</dt>
          <dd>
            <t>See
          <dd>See the Security Considerations section of This-Document.</t>
          </dd> RFC 9569.</dd>

          <dt>Interoperability considerations:</dt>
          <dd>
            <t>N/A.</t>
          </dd>
          <dd>N/A</dd>

          <dt>Published specification:</dt>
          <dd>
            <t><xref
          <dd><xref target="open-req"/> of This-Document.</t>
          </dd> RFC 9569.</dd>

          <dt>Applications that use this media type:</dt>
          <dd>
            <t>ALTO
          <dd>ALTO servers and ALTO clients either stand alone or are embedded within other
applications.</t>
          </dd>
applications.</dd>

          <dt>Fragment identifier considerations:</dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dd>N/A</dd>

	  <dt>Additional information:</dt>
          <dd>
            <t><br/>
            </t>
            <dl> information:</dt><dd>
	  <t><br/></t>
	  <dl spacing="compact">
              <dt>Deprecated alias names for this type:</dt>
              <dd>
                <t>N/A</t>
              </dd>
              <dd>N/A</dd>

              <dt>Magic number(s):</dt>
              <dd>
                <t>N/A</t>
              </dd>
              <dd>N/A</dd>

              <dt>File extension(s):</dt>
              <dd>
                <t>This document
              <dd>RFC 9569 uses the media type to refer to protocol messages and thus messages; thus, it
 does not require a file extension.</t>
              </dd> extension.</dd>

              <dt>Macintosh file type code(s):</dt>
              <dd>
                <t>N/A</t>
              </dd>
              <dd>N/A</dd>
            </dl>
          </dd>

          <dt>Person and &amp; email address to contact for further information:</dt>
          <dd>
            <t>See information:<br/></dt>
          <dd><br/>See the Authors' Addresses section.</t>
          </dd> section of RFC 9569.</dd>

          <dt>Intended usage:</dt>
          <dd>
            <t>COMMON</t>
          </dd>
          <dd>COMMON</dd>

          <dt>Restrictions on usage:</dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dd>N/A</dd>

          <dt>Author:</dt>
          <dd>
            <t>See
          <dd>See the Authors' Addresses section.</t>
          </dd> section of RFC 9569.</dd>

          <dt>Change controller:</dt>
          <dd>
            <t>Internet
          <dd>Internet Engineering Task Force (mailto:iesg@ietf.org).</t>
          </dd>
          <dt>Provisional registration?:</dt>
          <dd>
            <t>No</t>
          </dd> (iesg@ietf.org).</dd>

        </dl>
      </section>
    </section>
  </middle>

  <back>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC7285">
          <front>
            <title>Application-Layer Traffic Optimization (ALTO) Protocol</title>
            <author fullname="R. Alimi" initials="R." role="editor" surname="Alimi"/>
            <author fullname="R. Penno" initials="R." role="editor" surname="Penno"/>
            <author fullname="Y. Yang" initials="Y." role="editor" surname="Yang"/>
            <author fullname="S. Kiesel" initials="S." surname="Kiesel"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="W. Roome" initials="W." surname="Roome"/>
            <author fullname="S. Shalunov" initials="S." surname="Shalunov"/>
            <author fullname="R. Woundy" initials="R." surname="Woundy"/>
            <date month="September" year="2014"/>
            <abstract>
              <t>Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.</t>
              <t>The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.</t>
              <t>This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7285"/>
          <seriesInfo name="DOI" value="10.17487/RFC7285"/>
        </reference>
        <reference anchor="RFC8259">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
            <date month="December" year="2017"/>
            <abstract>
              <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t>
              <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="90"/>
          <seriesInfo name="RFC" value="8259"/>
          <seriesInfo name="DOI" value="10.17487/RFC8259"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8895">
          <front>
            <title>Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)</title>
            <author fullname="W. Roome" initials="W." surname="Roome"/>
            <author fullname="Y. Yang" initials="Y." surname="Yang"/>
            <date month="November" year="2020"/>
            <abstract>
              <t>The Application-Layer Traffic Optimization (ALTO) protocol (RFC 7285) provides network-related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8895"/>
          <seriesInfo name="DOI" value="10.17487/RFC8895"/>
        </reference>
        <reference anchor="RFC9112">
          <front>
            <title>HTTP/1.1</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns.</t>
              <t>This document obsoletes portions of RFC 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="99"/>
          <seriesInfo name="RFC" value="9112"/>
          <seriesInfo name="DOI" value="10.17487/RFC9112"/>
        </reference>
        <reference anchor="RFC9113">
          <front>
            <title>HTTP/2</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <author fullname="C. Benfield" initials="C." role="editor" surname="Benfield"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.</t>
              <t>This document obsoletes RFCs 7540 and 8740.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9113"/>
          <seriesInfo name="DOI" value="10.17487/RFC9113"/>
        </reference>
        <reference anchor="RFC9114">
          <front>
            <title>HTTP/3</title>
            <author fullname="M. Bishop" initials="M." role="editor" surname="Bishop"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9114"/>
          <seriesInfo name="DOI" value="10.17487/RFC9114"/>
        </reference>
        <reference anchor="RFC3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <date month="January" year="2005"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>
        <reference anchor="RFC9325">
          <front>
            <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
            <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <author fullname="T. Fossati" initials="T." surname="Fossati"/>
            <date month="November" year="2022"/>
            <abstract>
              <t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.</t>
              <t>RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="195"/>
          <seriesInfo name="RFC" value="9325"/>
          <seriesInfo name="DOI" value="10.17487/RFC9325"/>
        </reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7285.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8895.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9112.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9113.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9114.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/>

      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC4122">
          <front>
            <title>A Universally Unique IDentifier (UUID) URN Namespace</title>
            <author fullname="P. Leach" initials="P." surname="Leach"/>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <author fullname="R. Salz" initials="R." surname="Salz"/>
            <date month="July" year="2005"/>
            <abstract>
              <t>This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.</t>
              <t>This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4122"/>
          <seriesInfo name="DOI" value="10.17487/RFC4122"/>
        </reference>
        <reference anchor="RFC9205">
          <front>
            <title>Building Protocols with HTTP</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations.</t>
              <t>This document obsoletes RFC 3205.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="56"/>
          <seriesInfo name="RFC" value="9205"/>
          <seriesInfo name="DOI" value="10.17487/RFC9205"/>
        </reference>

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

        <reference anchor="IANA-Media-Type" target="https://www.iana.org/assignments/media-types/media-types.xhtml"> target="https://www.iana.org/assignments/media-types">
          <front>
            <title>Media Types</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date year="2023" month="June"/>
          </front>
        </reference>

      </references>
    </references>
    <section anchor="sec-dep-model">
      <name>A High-Level Deployment Model</name>
      <t>Conceptually, the TIPS system consists of three types of resources:</t>
      <ul
      <dl spacing="normal">
        <li>(R1)
        <dt>(R1):</dt><dd>The TIPS frontend to create TIPS views.</li>
        <li>(R2) views.</dd>
        <dt>(R2):</dt><dd>The TIPS view directory, which provides metadata (e.g., references) about the
network resource data.</li>
        <li>(R3) The data.</dd>
        <dt>(R3):</dt><dd>The actual network resource data, encoded as complete ALTO network
resources (e.g., a cost map, map or a network map) or incremental updates.</li>
      </ul> updates.</dd>
      </dl>
      <figure anchor="fig-service-model">
        <name>Sample TIPS Deployment Model</name>
        <artwork type="drawing" align="center"><![CDATA[
                      +------------------------------------------------+
                      |                                                |
 +------+             |R1: Frontend/Open  R2: Directory/Meta  R3: Data |
 |      | "iget" base |     +-----+           +-----+         +-----+  |
 |      | resource 1  |     |     |           |     |         |     |  |
 |      |-------------|---->|     |           |     |         |     |  |
 |      | incremental |     |     |           |     |-------->|     |  |
 |      | transfer    |     |     |           |     |         |     |  |
 |      | resource    |     |     |           |     |         |     |  |
 |      |<------------|-----------------------|     |         |     |  |
 |Client|             |     |     |           +-----+         +-----+  |
 |      | "iget" base |     |     |                                    |
 |      | resource 2  |     |     |           +-----+         +-----+  |
 |      |-------------|---->|     |           |     |         |     |  |
 |      | incremental |     |     |           |     |         |     |  |
 |      | transfer    |     +-----+           |     | ------->|     |  |
 |      | resource    |                       |     |         |     |  |
 |      |<------------|-----------------------|     |         |     |  |
 +------+             |                       +-----+         +-----+  |
                      |                                                |
                      +------------------------------------------------+
]]></artwork>
      </figure>
      <t>Design Point: Component Resource Location</t>
      <ul
      <dl spacing="normal">
        <li>Design
        <dt>Design 1 (Single): all (Single):</dt><dd>all the three resource types at the same, same single server (accessed via
relative reference)</li>
        <li>Design reference).</dd>
        <dt>Design 2 (Flexible): all (Flexible):</dt><dd>all three resource types can be at their own server (accessed via
absolute reference)</li>
        <li>Design reference).</dd>
        <dt>Design 3 (Dir + Data): R2 Data):</dt><dd>R2 and R3 must remain together, though R1 might not be
on the same server</li>
      </ul> server.</dd>
      </dl>
      <t>This document supports Design Designs 1 and Design 3. For Design 1, the TIPS service ALTO server
simply needs to always use the same host for the TIPS views. For Design 3, the
TIPS service
ALTO server can set tips-view-host to a different server. Note that the
deployment flexibility is at the logical level, as these services
can be distinguished by different paths and potentially be routed to different
physical servers by layer-7 Layer 7 load balancing. See <xref target="load-balancing"/> for a
discussion on load balancing considerations. Future documents may could extend the
protocol to support Design 2.</t>
    </section>
    <section anchor="sec-bcp-http">

      <name>Conformance to with "Building Protocols with HTTP" (RFC 9205) Best Current Practices</name>
      <t>This specification adheres fully to <xref target="RFC9205"/> as further elaborated below:</t>
      <ul spacing="normal">
        <li>TIPS

        <li><t>TIPS does not "redefine, (as described in <xref section="3.1" sectionFormat="of" target="RFC9205"/>):</t><blockquote>...redefine, refine, or overlay the semantics of
generic protocol elements such as methods, status codes, or
existing header fields" and fields.

</blockquote>
<t>and instead focuses on "protocol on</t>
<blockquote>...protocol elements
that are specific to <tt>[the TIPS]</tt> [the TIPS] application -- namely, <tt>[its]</tt> [its] HTTP
resources" (<xref section="3.1" sectionFormat="of" target="RFC9205"/>).</li>
resources.</blockquote></li>
        <li>There are no statically defined URI components (<xref section="3.2" sectionFormat="of" target="RFC9205"/>).</li>
        <li>No minimum version of HTTP is specified by TIPS TIPS, which is
recommended (<xref (in <xref section="4.1" sectionFormat="of" target="RFC9205"/>).</li>
        <li>The TIPS design follows the advice that "When (in <xref
	section="4.1" sectionFormat="of" target="RFC9205"/>) that:</li></ul>
	<blockquote>When specifying examples of protocol interactions,
	applications should document both the request and response messages
	with complete header sections, preferably in HTTP/1.1 format" (<xref section="4.1" sectionFormat="of" target="RFC9205"/>).</li> format...</blockquote>
	<ul spacing="normal">
        <li>TIPS uses URI templates templates, which is recommended (<xref (in <xref section="4.2" sectionFormat="of" target="RFC9205"/>).</li>
        <li>TIPS follows the pattern that "a (in <xref section="4.4.1" sectionFormat="of" target="RFC9205"/>) that:</li></ul>
	  <blockquote>Generally, a client will begin interacting with a given
	  application server by requesting an initial document that contains
	  information about that particular deployment, potentially including
	  links to other relevant resources.  Doing so ensures that the
	  deployment is as flexible as possible (potentially spanning multiple
	  servers), allows evolution, and also allows gives the application the
	  opportunity to tailor the "discovery document" to the client"
(<xref section="4.4.1" sectionFormat="of" target="RFC9205"/>).</li>
	  client.</blockquote>
	  <ul spacing="normal">
        <li>TIPS uses existing HTTP schemes (<xref section="4.4.2" sectionFormat="of" target="RFC9205"/>).</li>
        <li>TIPS defines its errors "to use the most applicable status code"
(<xref section="4.6" sectionFormat="of" target="RFC9205"/>).</li>
        <li>TIPS does not "make (as in <xref section="4.11" sectionFormat="of"
	target="RFC9205"/>):</li></ul>
	<blockquote>...make assumptions about the relationship between separate
	requests on a single transport connection; doing so breaks many of the
	assumptions of HTTP as a stateless protocol and will cause problems in
	interoperability, security, operability, and evolution" (<xref section="4.11" sectionFormat="of" target="RFC9205"/>).  The
	evolution.</blockquote>
	<t indent="3">The only relationship between requests is that a
	client must has to first discover where a TIPS view of a resource will be
	served, which is consistent with the URI discovery in <xref
	section="4.4.1" sectionFormat="of" target="RFC9205"/>.</li>
      </ul> target="RFC9205"/>.</t>

    </section>
    <section anchor="push">
      <name>Push-mode
      <name>Push-Mode TIPS using Using HTTP Server Push</name>
      <t>TIPS allows ALTO clients to subscribe to incremental updates of an ALTO
resource, and the specification in this document is based on the current best
practice of building such a service using native basic HTTP. Earlier versions of this
document had investigated the possibility of enabling push-mode TIPS, i.e., TIPS (i.e., by
taking advantage of the server push feature in HTTP/2 and HTTP/3.</t> HTTP/3).</t>
      <t>In the ideal case, push-mode TIPS can potentially improve performance (e.g.,
latency) in more dynamic environments and use cases, cases with wait-free message
delivery. Using native the built-in HTTP server push also results in minimal changes to the
current protocol. While not adopted due to the lack of server push support and
increased protocol complexity, push-mode TIPS remains a potential direction of
protocol improvement.</t>
    </section>
    <section anchor="persistent-http-connections">
      <name>Persistent HTTP Connections</name>
      <t>Previous draft versions of this document use persistent HTTP connections to detect the
liveness of clients. This design, however, However, this design does not conform well with the best
current practice practices of HTTP. For example, if an ALTO client is accessing a TIPS
view over an HTTP proxy, the connection is not established directly between the
ALTO client and the ALTO server, but between the ALTO client and the proxy and
between the proxy and the ALTO server. Thus, using persistent connections may might
not correctly detect the right liveness state.</t>
    </section>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The authors of this document would like to thank Mark Nottingham and Spencer
Dawkins <contact
      fullname="Mark Nottingham"/> and <contact fullname="Spencer Dawkins"/>
      for providing invaluable reviews of earlier draft versions of this document,
Adrian Farrel, Qin Wu, document;
      <contact fullname="Adrian Farrel"/>, <contact fullname="Qin Wu"/>, and Jordi
      <contact fullname="Jordi Ros Giralt Giralt"/> for their continuous feedback, Russ
White, Donald Eastlake, Martin Thomson, Bernard Adoba, Spencer Dawkins, Linda
Dunbar and Sheng Jiang feedback;      <contact fullname="Russ White"/>, <contact fullname="Donald Eastlake 3rd"/>,
      <contact fullname="Martin Thomson"/>, <contact fullname="Bernard
      Adoba"/>, <contact fullname="Spencer Dawkins"/>, <contact
      fullname="Linda Dunbar"/>, and <contact fullname="Sheng Jiang"/> for the
      directorate reviews, Martin Duke for the Area
Director review, Francesca Palombini, Wesley Eddy, Roman Danyliw, Murray
Kucherawy and Zaheduzzaman Sarker reviews; <contact fullname="Martin Duke"/> for the area
      director review; <contact fullname="Francesca Palombini"/>, <contact
      fullname="Wesley Eddy"/>, <contact fullname="Roman Danyliw"/>, <contact
      fullname="Murray Kucherawy"/>, and <contact fullname="Zaheduzzaman
      Sarker"/> for the telechat and IESG reviews, reviews; and Mohamed
Boucadair <contact
      fullname="Mohamed Boucadair"/> for shepherding the document.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1963rbyLHgfzwFlv4x0jFJSZSvmtgbjWVPdOLbkeTMN8nM
NwZJiMSYBBgAlMzI3lfZfZbdF9u6dleDoCR7kpN8u0f5MpYA9K26urru1ev1
onExypN5ehCPy+S87mVpfd5LZnXRy9PLXl0mebUoyro3S+q0qqM6q2fwbeds
msaHL8/exGf6RXycnxflPKmzIo/fLoezbMS/n6blRTZKO1EyHJbpBTTmhsdv
TzsRfJNOinJ1EFf1OBrDXwfx1dHh2fPPUZQtyoO4LpdVPdjdfbw7iJIyTQ7M
iIfwd3RZlB8mZbFcHNCEoqiqk3z8SzIrcuhrlVbRIjuIYui/zEY1P4njUTGf
p3ld6d9ZPsv0+zhOx1md5ZODOC/gr7oY6Qv4tZgvEt8PPBini3p6EO9jL4sy
L+rsPEvH0raCeZbpuRunWs3tn43equXQPYHmUbKsp0WJs+/B/3GW0PKP/fj7
pKC/eeP+mGTuCawyTaF153XRH9yLTwvoAXZgRDux141/zKbLJI9PimTcoQaj
rAbgP5um+WS85CfFGDp9sLcLP/JgmdclfZXlCT0qSgDOaTaizt7l2UVaVtAR
vUvnSTY7iD8k2SQpfl+Nlv10vOyP8ihcxkk/Ph1Ni7o2KzkpZrB39rmu53ic
9E6mMLOqdwpI+X/+ZxoPzPyPknIO+z6u7QruDR7fDxfwfQoImq/8Eo7SZV2N
AJfP0ln6oZjbBfBk+jyZ39f8QX+cNtbxYx+X8mOST8xC8M/4BOCTlGP/Thdz
fy9+WxbVArYlPqVnZimv08v4D8lFmpulPDsL1/Hu9NCv4cdklm7Yg1W5+v2o
6q/gC9yExsxf9mH9s0uYZWqm/jJZlmkevvnqie8+uD/Y/bq5z2geAG+ex+83
L+KP6WyWlsESRlPYO/vin7MCmkb/A03DLCBnOnmR4sk+efFssLf3WH59OHh0
X359NLivTx/tPbynvz56rB883tsb+F/3/a/67f7jRw/06f4AmkWZ0mg39r29
getksEtdHx++Puy9AhqY9M5WC/oQCB0Tfnoc4+OKHyflBOE6retFdbCzc3l5
2c+SPOkDcHaSqsomOdHZnTn1V2ND+3v/47Sez6grJv6D3cF+b/dBFPV6vTgZ
wr4BNYwid9/A7iERnsVbMOMYwbUdz1KAfjJJq/gPZ2dvd/b6ezGSkayKgV7A
DNJxDMuOa+ijyuaLWdqNqvSvS5hXlsziEn+t6l6ZLmareFml8Sip0i6gV3w5
BdSDvnjo0SyDJvp9FSfSyyiNi/M4M9dfmVbFshzBhHAeNC5cgmmJLxZFPq7i
ywzoMr5Aej9L6zQaFXmN3UNXKSCO6yOGeyxO6jiBLZin/SiiuWT5qEwRsrCA
5QJBV8HU4c6i6zYte6fY1/MLhH28dXr6fJsBhuizDWA5h9sOVzBfzuoMJvAR
my4UtrCEuljgVASgH7twk8F8cR4CDVnRKMkjMxmA4GJZmdnr5OpC4Adrh8sG
dyyeF3lWFyVsT57WeI9H7UAEMppPYEeg++ISJ0qAk96gY+kn1sX4phFMmMAP
dIHhF/+huMTBu7y0Ae0QMjdlTEe4yAEsM2Asxiu4jhfEZ8DWjJYlUKO6C2c3
7w1nxegDzcOxIgAqNzrSmmReIQK5sXEw7Cfnqxi28QzgmXyArR1fJAC5CSER
8FwwEfr4PE1qoIBVFzpBTC5GSwQx9FqXxXiJcKnlUES3ZsLiLWS7tvvEfSGu
I4ZaZIpOnp+enS9ncnIQuhMgFs0zgCPDXGH3F8kwmwHhwy/TjwsYEAjFqht5
mAFKbFmobesJircWy9lsO0ZqDDzTaDNSRzmRLN2ygkG0s9/FE0oQz2az+HyZ
E3BxZ871GyAGfSYm82w8nsHtfQeAxCAkyFzdIYgCv3m4WCi8ei+TFWwEwPUc
J/ZmAbiT/Y1BuYWA2MbDcpEBlOJ5CsCnARWLE98R4WcxrBNABnkNs4WdrSzB
AFaoiM+Tsuu21L4FJjmPh6nHNjgwiFuXRXyZrCog63uwodpwCMTLn+SrK7lU
Pn/uCjnbTBYd8Yvodr2J/LkFtZ3arpI+7EtoRZUi6bNULzZUD59L57RA3+dW
dg69rbaxK0dY6sKQAdjiQT/+CsqITXaIPBKkkDwCpHCgdmA1z0EB441xr92E
ZK1EK7MadgjGwf7gdZmOUkRjnRZ1CA1o+RvvDNx9+JOYkuBU0R23TnoNxaVJ
yFSV6mI3nvA2iSwA8rsCriZFIJhNmYYgcHcsQQyZEMSt4bLW46nP9z9/xjlG
fFbd43vwGNek1NX1h7h0DhS+aifS3E0k587RR1kkkrE5vgOUSEs6b/DXAn7N
4BuAL20b9qNbjmQhfpGVVd1FuFbQaenPX3CM2o4OghcP5Dm0KvLZSqQ5wurW
awzwU/cCZ1su+XoIz6u7eaG7JrVjFGLS6S6b9hsTVu9RhYVfvJJ4m4S90I7g
P0BcGBevXcEBzhewIUN8zgtL/B0dEeQX2Myzuu08wv4i19SV/oS8JXANAzMJ
fcMmllO4gQlnzSl3F/M0kXtrfZJ6enLpHNAX1z+H8yEoXulJ1SaECK/TjxYP
FEksWYANnIE8vpxM/Ws6nIIGpEZYW2w3zoJLG4AMIC/gOgEkuo79QkAwAwa0
tKqWc/wGuMACOu8VJc5ynlYVcg64sDyFG7As5s19MDQyplsiGFOu+XEBM8uL
Wm81FKTw9VbWT/swvAcvvMxJw1Fuk/qD6B80WcKKW7f6dIl3iA4E8MJh6KJx
CIqsf+KxNE4uQH5KhoTd6xQAkDgdJdjDECkV3lcVoXOG2+1mirvh5gpbN0ad
TpEjnez6/ctwQ5Bs9vAMrx146CBjRguPNyPhOYJO8B7P2bQo6HqZFpc0S0La
rFZqXzlQEM8HRyKb0HUxTQUIaZlfx+UlxGk5nhu5uBGsIh1HuLf/UNZPsaFx
65HwknwJA5gB/gJSWd7Z8RFIO/4TWMAf6LO2c027RlARhMoNY982IaDOTR7N
0F4v6RCBQ2oF8x5n50AiCNkZvJMimVXEt0U0NtCfNEf5I05zxH1gLOGGjivY
azoKOMmyGCK5HmeozARSjl+T6Ok30VEdpPSAUXMAvYpMsOc0wBwE9Ak1oF6H
y2xW9wCVhWrgcYjcxprrk27N+IUSGbhcaf0oAMPvpFSBLeoyLGHsgtlm3L16
WiLhXMCkhisV2HFehgrgXIpl3SvOhbwF4hXSCNnsyB5fPwiJcfkIGKOKcDNl
Hk+ul2xOaoc6BXRUil3SPR5ZcRJxGyYBfBupgIXpK/AyAfAvcYrnpD1e5nrA
LsPbxl3NjgSeTZewIZeABAUR2SpNGUZ4jcWod0hGvB24afSQL2J8FgXAf5On
gCkJces8kWGWy/4COUGZwCFSRdStiiugTHjSo6srmFjVq6oULrMoel0QGQLu
6XyJrJRtOU/cLqUWL/AuEM7LqQcGUYPji9c5vm7MV3YyA0lbjjK0pzX9gKej
glsRVQOriAih/U4OTMY3FHMAgK1XVzghWsmpkA8m7iElFdKSopzUi+Pnfo1y
O4ZqJdzv8QqvvxGq46tRmS1ol3FdKUqDGbNUMSAAor9sM8xyhkrAFS4rJKyA
cMR54Da1iExWqiFWBPhERF8v6awWsk8qa7AQxYRcaNKkTBZTIBnjlNeQrHf7
7uQ4XiQ1ApYWf57WI1ZCVXmyACwB9IeWbbc4gLiYw47BMU/4FhUM/cgEgman
rCSqNRAASAiFn/IHJcoUsRlrYas85SNZg1GBZdyrqwIQNuilQmSCOc6WYyQs
swL4xCHQyHyEHV5d4YOee4Af0zqJeYIthCttlDJJbFkoHrZxugA5lUVdpelX
V6OyqODojKbp+PPnCDC+Ske94WjRQ80noL1OmyB7ieCgZdV+pwSNkzFSCod9
36FV7ZlQwLeo7MxGIhoiXR5bxlDUhqQe4rM12L1PB+DOnfiEOSDStsYvAd2W
cHRZcfoBLiHAOpC9O6/enZ51uvxv/PoN/X7y/D/eHZ88P8LfT/9w+PKl+yWS
L07/8ObdyyP/m2/57M2rV89fH3FjeBoHj6LOq8MfO6wK6Lx5e3b85vXhyw4r
xuwZxX0HeCCVzgE9F2WKKoCkigBmcACHjAzfPXv7v//X3j1Y+n8TpTnAnf9A
BTn8gQjGoxE3x3/iHYwqmTRB3I5JEEgWGex61fXkETcFAPlvf0HI/HwQ/w72
du/eU3mACw4eKsyChwSz9SdrjRmILY9ahnHQDJ43IB3O9/DH4G+Fu3lICAPk
nw8UIondDeINneayWsEB+UhAzbUFgs1xqGO+WtTI+Kg/QBLo1E64sUyDV9Rp
GhBgICAVUQKiwqEORLhdpD53+Ai9ucBHQBuv7hTy62dai+eCg2Nwdac0f35u
MyOQEqWu7LRUMYGXqWdB5ikS8ayaw0UiWoPEyvNjGGaEvK5K1so0B5KpqAK9
pB0p7WUVGNCNoBFjqFxhY1Upb9TxfRvBNhT5uDE3uciGKQtsnuypRAxjo5nB
6tBJsew3ZOm4yHWyaSi41aLRghPLPQCBxR4CDVXqdcrEIoqaLl4zYAAaOLUQ
NROi2bZFRFGQWxDuUFRXIHeXsIxupNoJRL1u817YMivcNkz/umLW6HaaLAjr
x1vmxtdkBR1UciLOC7FrRBZbgV05Xr+gDqKDuOUx07s5oBajF+pAVDmFQ3RQ
/OjA10Wuey5sKYrJLCigtOEYHETFXOEV9FcqHoCo6JUc6DRBaErsjtfb0FjC
EoWngWSTvChZdR1gNHTmFBJ6GNvkMFWUKiasfwM9ecBnAXqSEmkGyKE0bQv+
9szHMIU9QZx75o0/oQAruC+oRJIV7s4PuHZ3+vI0HVdW90tnYoGWRqPC26A0
Qj0bcg2lUTeiSs2eoUDMRqZuiRsAouEMsF6IRT6+zMb1FHojiOFkkHDHqGND
aQtdX2JdlzElXHfSobPgrC/xWNTLnASsrtk/h+iZ09LQLdPrkYAWs0YNdUl2
VSyzOVUVbsiqodlKLops3L4G6G0IjHYK3a/bBLvBSKzeJtY9xStHzcKiX0fz
JvrloPDO6rXWAdEXARUlbNtQK1+XiI6Ia11mf2OnREXFUzL6kNbxDFhLwLSX
RT7pLYAYeOyi8972nFXIvI04KNo26aZN5UzILdQFosATRJllAQNlqExA8AFP
DBuAd0Pv5OwswGND7Fo0esdrm7+2ufAnIOJ5hmoquTp443oVvibJXMzSaCGI
sQFrcBTf5aajWQSUFC0UALZL9KwhZ6lalHF8+EgXRLIKW5SAl7zIimUwPd71
ghQyhFgbDBdxqyDL5NKdy6mYmNdnakgPoxFJfo6FZz8FFLXzFXR3AQRnMWej
EtldEPuEsPFeqOAkXFtMq0DCieyuVXWdtU+nwUYEQjKdUpTkkD3G5bC00ryR
enHIKpapYxZRPxPz1RjyhgHRJXCJgqtdXy7o8u+nb16jtAoCF0ml87SEi0Qe
9Ndn4oaEY4WSOS6TpsQiMSC8yhLmYsIpbHnht2FQ0xltt91fXfjNaZBYZ4Ms
KnSIXCkeEg8VmkI3vnEg2lCQ8YneJQwfp1wnqc/zY45pMOsVpT0QIDxfRICw
NxFn2Z6Ak6KuxNtBtVOsP2rQ3+By8bZZUhri3Wr1aMTVBhfkHI0SQP8yUp4N
V7KzjiJ7Qok7DN0ZtaCl/ARDb2tbO7ZOFyxokW4GCJ5cd2JwY+CKKnLm2nhH
EiFW7NiDhq7lfIgsp6OjnoqKzcyZglFPUZfLEROEdycvCXFEuwZdyR3Ksg3x
xjNL2gXAt1uF2di2ba3M7cVaG3QiKhaOTHTboBceKTI66elOF7NiRY/5QAVq
mpjVIfBRj96qToKEtrO0REZvVkxWIJDV/q/PyOHGiRhmVBrADyrxUPLkQ10Y
6nZJ1Z8Gag6U6kvtIsRYq7GFNG56B4oY2iaJmbl0SZrNWVUfee1g222AeGPE
is3aQpLB4mv9LFCPe81rt6xFlrKfWpnWJVz8Yl7zLZIhqr2tjwosGTDHwh9R
BLeUZPCt+kKhZnYr3CBW6ghXhKIJHeCA9jkAEblrzocFqWuWTyfFTwqZepBk
kQGEkzwiDgH+xv0JNaVby8k2G0lQ1c36RIAPkaoNU4LVv1vrwwGY5f8URe/R
CmjCSD66nBYVyqJjslICO1KpVlAcP9yJJVRoQCF0p0nHE1XNcFuhKFmdztnw
BMtdqnER7yLpux8fyv01TxbOjLiV9if9bvysAIH0VbLoxopJ8Mc2wQXFF5Yt
yT4LOOntGrw+9GpQfXnbRjXGepGhYj9F3kqH5ZGQ9BJtbO4T8kt8t8D2uo3e
ZtYaPRngpAHdjGJHP+Pn+aggxSmR37C/rHGIUcOc5j1oS+j9JwYY7uqJbhbu
LmA1ysIjUnw7l6UNPgj9+AW7CoVafr+XNG/ZGzbSVMUIbVNjsa3CXvOy8FpS
KzbdebgP4bVFhB72OB0t0VziLzInzwD4+Rbrx+uaPpG8kG7GHZ1T1WEx8dw7
Eeir5lwbQ0B3narTj//kV5fidhBHA4BEvu61XKlNgtrYi9M6Qa417B/4NXwM
csRf9ezReUAHD9S6IQfyt7Qs1tqRWqSBu1H0PF8DEqBqPm72T64p1fps2ns9
FU7PEQfSlVhDH2FmoBnMKkcjGbLtXa8rfzyJB7iwQ/OmcW4coEteTOMNUoLb
wPgVceNvkRtHBoKe0V9EaKw92nE9GUk68GtRAoYyxyLTUtTayrZZQ0FO5f7x
r9vixmPQHFhbck3J4rvxXvwk/lX0/gsxT7Fr3RSIOHzPdP0yq+BovtJJbBA/
kAdPZuhY2ba56m6g4+zoEBt6Q9KG0gvS0qJmCwddNeMNqPPOU3QmQnAEvaZU
SQ81xdtAeb/1SY6mysULA04U3CmbywbbIT3Q/plbxUgCZILTY7xIMjzqWwXc
Gsifb6N2A4XqBfrMFDgVeMC36VS6ypoeJzpQEU6Od5K4/qwK133uesOjcHQn
6935FcF0JGN6UPCQxOU75xICmCgWwltBtWuZkGrS9DgCja/1j1+7stKMZvkr
267oRg4oQyWTxXUxliML4FSWguL0TFaFs+tShAD7UcxWsMb/AT8YmXeZSQzR
DT93e/bnbtR8drfxBTz4FMdHcoHDz6fw84ifxSfAjOGNCr9/QuPJRVaJmw0+
cIxDzB+gkb3EUxh/kg7eOhMmfR/HbwtgkVbawPLo/Dd0cA5ETDq4YQl3r/n7
rgHbpxBYjT/X30eNkb7i5270iRkvMWt8zc+n6FNzzV86C+pjbb0bf3Q/G/tC
fTSBvemn7Tvto7njG1fe8p3v40TvtTt71/bhvxs0+vjta+E3n263DTvy70/h
vug8b/Oz4377ya/wy+axY37/yc5DYcM/7RJ0cxZ+JmswbQfn+mvzxO9tXF/s
bQQKvR7Y1/Rkn2fxd5yHhUfLz07r00/6z3XzuGZ2rfAAcOwsJ+Fk8Olg7al7
tc+v/n7zuOtQzCGw/mxGPPfG4Dr/81NjvOuOsP9VabL0+9OG0TbPw1wJ2u/d
AATXzKPZUH9+an3aaGiIiAK75ZH/uduY8af4GasaPbVzjwatOCAv9/8O40f1
RQbPnhhdS4bPEMeetLK+zFk1xUVoQkxNdHUQ3znPJj115ABGiu6cXjLLJvmT
zihFHqDDgadPOs71Q9VylD+APLFsL58/kz8PcZrqJ5nNZkuMI63ZlB0Xpitn
uSHlvSgrWKmkfgsa5+UcuVSlgc0viw1ewFt39iJk9u4MlDWGS4o54KYehvld
uJvIJnhOGhJUzwXTYedS2ErjiA2jKEZ0HSJwb7rz2xK0WVKAaU4aqsDxkVeJ
kjDqJESX7fSqfrNJHUCaQ+PYGjo9JP7zaAvo1TbJtKTX8ZFmVv90Z6+rom81
TUSp780DvEZSppDbCENGbYnUAawWt8A7V7sZVKif5LABoIQkQLq5oBtE5Ns0
A9sIT/1rHhY1bsYTSRWB3yOSkx5bXJa903zbmWCLgVXqhcG0NMEqapU6Of5o
s6KR46BYwq/I78YFJ0ebvCe8SWoLmPOZCh4SYBCoF9kKFt2gi75zJ/6OFK9H
KL69IlMBtAvAFV/dQeFOTAVR9EI1eU5PIcpC9JLCECVUTfpoQ/hzu7vBE4lW
FflVifTq9K7OGh0aDRSkDYiy3S7i42udD8pk9KFqOLjYiCKco+CRyo3HR5U/
ihwY3/Q3kGAbtyo+D3sMGzTwb4sLM/5NkqPIsk6zmbjhGhMyCLSuTlxXgKk+
v6Gx2/Zqvd2YLP4EEPpOIj2zPCMdFNkPYB/ni3q1k2OYr7o218nEz2FNvE9o
YX35bpoYR0SxLfuxOvBJB45nOhPtoctzstvfD30QhcpcwN2ivqGsANMA1VGx
SG0UZt9DmrUGlVfWsP4BLbykcRstZxq5S5+S7oB0Br+q/sI5I7FWwmsbrlM0
8BSMHnWR1NOetftteSKF71B3VZKPkQl6l+52EKw4gQCkAvjtKDokWy/63fpr
00cOxHzJLicYBOcvo4di1rBo2I3cYcOT9dAQUmvoCOLv4udk15BuYCSMLnDd
BC6DPsItVB2q8TDQHJK6e/QhnlGyA9+h0UO2UBAhPsdHe7v7vb3de9vozVTj
aWz045SAreS10c39bY2IhmU2OzJkmFpFx0e70GYfDpwP0qATr0dF0MGagQ+a
Z4kaXJARGGgge57KqUcHNCWDAWjRF4U6FkeNcYXYdMEWDfVkitgyLIpxzAtl
jRmwVvH8bIna1O9gcd7xL2pQLWlHfe2Tr3HNpLdiikTOguTLKFRtPf7JBZVi
KH465rEaemWcKH6mDgqp9+GlkAF2wkiMXlLMa82w6yZE29BB/NEiWhFABxCL
aAZO4548ud+l+AsGgtNkC9Gh7cHWgOo4c/KcrjDObtOcavZYIP9PVVN3eHcb
nX2ForH15+4T+rn7FR2IkBbDzWLkrNv/7HzlDPik7XlR/tNXjP9p55dfvqa5
ztb0dF1zuO8O4v17g73dxw/j3lP4GGceSMf/wNH1BynaHsBsAN+GQueXgu6n
UH/yDwfdg3v7e4P9ewq6wT8FdAMk7P9ioNtxzddU6wK63UeP9nYf7SrocAG/
049oKqro/w5pszItOC0e7MnTtdHljpMFbBrd/8h1rKDr9+36vxx0tv1XgO5W
zQXr7g8e3HdYd492C5oTZ/D1oyNPcbvJ40D3+HPBumDyshH3vxSEn/q/mEc7
X49917UmCD58tP9o//FAIXjfIh/i35cOfRuA3QeQPECAfRFY/l4zEcR5uPv4
0b4u+8FXYEqoaltOblCykWqDhfbnzOt1OL4qlN9fkYeAuNEd5xdJmVGWG5Ai
REImjx4WjTG4quHSI45KyYi95pLxmAWJbgRsV1/csjIJKE3zalkKC4zcqZOx
WcTUPDvz5AMqTnzmCOSvQXyjP4AZciH5wu05Vu8iS2LP40Vb3GGFltgZxx/D
FHe3OTLWtRo6f1hRKqZJCSOUPpxLWGBgx0GeQQd0cdlqdakP01NECBTUTdgk
Z4uySJx6xjmavjs5Zq2ShHCLpEkaG5ZJj49cSjkAdDoONAeN6GGEt5tf5OfO
C96Deb6inARrsU5hPxQxKYEfUahpyRy2sC7jGY6RLyn94iFvMGo6uvEMreOV
OBNscPHxfiOoOCE53vkGhStUZTQGMaa204b44ntSHyCSHHKamJNxchddIn62
0CetOZlVEtIonlbos59xqkQXKNDiAEHseE7if84OLczdS/aBFY7zuyf4Dv+b
0gQJv2YzL1W3LXgr/ThKFzXir3pf1OmE/Jbg3F+Qf078/i+YfyRPf37PKocX
6AQtMRXxy/V9UBi3jRiozhEmOIBLIxLbYEeGHeVZZLdLClHWpECUA4C8cFTj
iVLzB8mk1b5cnn7nJJtMQWCcZucg7qCyB1CLBdZkTalvoQdw2AM4DH5+TxoU
iqhRSDe/+wY//MZ++Q3c6CC5fRM/jWuR7OCz+ClsGKejhO/hL+wwH/RF66mh
QUH+KcxoI/TOKYaZXFZGefxNg6xG4oCODeCEJqj087pOVeqw8zZpdIwOFlMb
CYRkObvdyCg8AxuIA8X7KxAEushI43/2uyzTkhgLt9Xn93080dTbXjei1CrY
Yv07gg6+8g8AAVhXR1p3nw4Mvxp0o2t7aTyVQFDfnWgQGcfywlNso3xD4QD2
B7m1DUi+DDA1LrPqA+0Zga0kDDSqGNvvltNzlXi98cZs63D6tqI43si9lsRJ
TUWOD56FnXNBd5RxJoh+kglEKDDSSPtrrkZi2fhBsrARPJ3nxMtCveZH03Se
xFd3NFsbMwiulX/RMyHaSNrjKUCFYjxm3vChOZUIFqHZyXkOM+0hLTO+6L0g
w9oLCjIrKCoP4TzeDrPxTduTmG1V254U8+gR5egziURF22XSpJlMeV1rCShT
uHVz5xZZDH8FgEZNSwxc0qqAXxSZjEV4UhSi9TZu9X655Gzf+9O2i6RezucJ
ZxipTdgrNnMufzpqc/11Afd5KdwLUX+gJyYNremrH/+gjzFlSOtcIx5U+RNU
ozWYki3McnN1VRG+fP687TOOtCcYOfQGW8WgFhW0Qy5MHUp067wWsim4oWjj
0m+ZaEivPvZBO5o81rIxPt4r8tsOTKbY54L90vEoP5OgAytiS8n2ixq1cCvM
FPjCpNQsBjWS2nstMhJghGlNqZbQwkUoKNgQbLm/nClegJmY0ElUTYqEU5GE
ZQK0KCM+MohkxZDbBO+Ec852wPpsY93gTbPHWFNVMtubC+uIW+UY0CzUaioC
WgCFyuZAI7wBDYR+sNaW7UOWs+LpuoykOT/9lZ7e3bM69qb/KNDz97+jpEm4
171lmT3dWU52fvfrU/j/3b2n751n7yqtmWmTTMmOREyLGSc9jRQJlwCbmR1q
iMBPbd67LQwMiyUwDE1nTrJ6dfgjQANDSiwSJpZ15o1a5shPEM2tVhUuhlLl
YHqjZRq5JGUAUxIrgNlzQYscnisciPH3qHjkcdd5H8uSosuM/Ns5xD0ty6Kk
9OnxPb5A+SBUPimszyQH7fi28rkt0chsQj3wcKC3b5AiFeWJruePJH0Kh4Tj
JJHvMb4AtBYah2WoSGPu7CoozpQ+wpVQzKPYN3X+leydkj36eJrgOcKAiyKX
qCrmre2aOI7pYy1bjtsDsgywbstszFe5nncSu8pihruPuRiqpnJeXDtu+mFy
2HzwJ4wHvKUSob/2ICJX3jcg6SD+EDHccYkNzI5x42cc0kOPtbH/wavbyfJ7
rSP/SfqSxhtdu+zP0/hTv2f/95S0Jp/ixjHu2gdCSp+2rFka32ps/C4Y/FNj
zV/0wwD7/vlZvGOmiuYbpkEZ0qCn1zW+1aTbIEgjm2ADNoGzSfumny8B2DoE
/5EAU6L9jwHYGuZ8ybR/U+P1rdKr7YbG/9ytui0Zam381T9f0JgIF9GgZ3Tt
wZRDfWrAhdygWnVOhl5UOuXUNngNCU1/C/2IxvUayUtYas7z4EjoTL/j167G
A6WldQya8uiVsvbEM7U5MHC62mSEWZEk0FIYo7aoqECBQUqFyDpdkdm+c5GV
9TKZoc8OZulgrmQrGf+ajChv5wzYp+3uepQaMU8tohIuQcQMCRysMBWfuhoS
BDJNkhqQf2CpAh7T5VducoGsRmuMu5ZWU51jmFlt7gRx31llOjBsz9Q6NpnO
eio4rdvmm8Qtjnd2WDxjz40i8MRETP70S7yc4C/wYag0orf0wa77nf4kyzI1
oNhF/NPpyBsf7psHP+GD+6ZbaNh8PZCOsU8gnvigNXOT72LQ7GI/eL3fnNG9
tRnJkM6pwkUGog2OJnGfJtFvG369O30Q/hXLgweR/Nrv95sWGNnXG6hF89Ab
a4xP38zBmaQbRV8m6RgrdqQ5Z3yA87VADTdL5FLOAVnnyBgWwqwVDnnbTRVx
QvI2M32iXIyCo9VMQs4CLk0JhFk3Iz2kdjwjt2n0XuhVR6aLb7JvSAVMv//6
TbspI0P7AkIed6JNgmPuiT6JjpameoOrC5S7LLdNqfD4qGok2HPiGkgCgSWm
oZhzUqK6h11nEECTX11Ee7sPt8mCpfukOl0kfwpGki1YcMcBicCg+xNafLqs
FaBsxtBv1BKt2FQpzZJKHM6s9k1tIoHDXySQoxlY8FFrp2BqGVC1E3fjve0b
dks+fep+w0aye63p8EKCnZA/Iebtymcro71d0Rt19uI84zhZyqSCjOQ8rafF
2CtHbSSUu6GP3BHcOj452o4P87xY5hKAfXUnK8ef+S6V5zq11vIFAtrWd+6s
RzTQmvs4291Mrs2Or7SF+VltTu8OJ2VFQtKJEs0nVLELt6/yxUwGdeOyopCy
7dbpVUzCv6hjKuPsUJFJ3Ou7v4Lk3OGRn9m041d3YMaatjNISM5OvzAXTTVO
LAen9eET5zKSROoV/ICdgm1Bh/XM0Y1xODucd4bORcVLYEDw4Ph2zgaP9dMr
5TgNorI9ncBMtdQsDeix4bxnqqR9y118jpvDfRvZoXoYXOGGcwh6fIQ33GmN
oROup2sm822kVxadRABI87aapWhaM04Ddk54SdGxp02ionPXrQ3Dt9FyJocC
qanaC/U0U29taUvXEl3zFnauH1F9xqWKSIpV/bATpqWJz/vcy8ZeY3WRzJap
OnRLVkqs4OGOBll5G7emTBQocLpIykRc+lHVmnBgCx/2ILOb8otkz1b05Gxe
dOPTKQfaHhwmSo/Wo/RofJzIRhx8go+DLzjp1vX9dK/vQbRYekSGBMdkLZ98
n9CUMmO6chl1QFc4GTAlCtkcOLO+05bwBSKITezpAvF5AMpxGaqYLzlnJ9lw
TKI5nzveyQXYC2MCp/bi4AO43IFJ7pKvSwVMGNyAo0oyA4g8oV/yGuYFqhUd
pySOyYhqU7okbQsstYP8BTqtMJyxDwkWQS0vPdvux+Ry0EWBj42lJukEXyk1
6/cBhMtZ7TE+DBNBuzWJs5SDRne2UcPCLbKtlz6SOjgiVPeFaymu7RViQUoA
JwcBTiSCr9f2IDs3uQAl8xmZ+JgiY3NThESvJyAlfSIrZuS1nLK+X3ErgNM6
Rsl0w9TZqK8ZXSWFG4pHvKku6wpfZe8wuQ5dXXzLxknNVTtSd4SxIEJZJitv
hzOkhxAXd3J1bdAVgZ9Zey9lWiqqUYSS3g3dkNCIQMOvKDV06jJrGG7im+ra
xFsVGWGxI82d5bXzJh0Y+mzAb8CuWDM+p9A0CcyjMI2mqxeHEWmV1EgTxyyx
QYh9w8LMZe4frSJ23oLTP80WyPCJT1em98w3uinYs6yg8j2d7Ik9T2oJwd/c
OWYXi7e47bb5fldcPhT5gv5B2FxSjBID6mQXGa7LFA8ZQGGvYe9yc/RuF5aX
1UJdGhiX1ZH0T95H3tcmbMIsuougs+ETYq7mDiNZJ1tcGPlrrb3hzD8gIaQo
ImDScAs04V5l7Y5LE5uxAaErqeIh6EPUcKgNPdUSuhTxCWdO3opiXCKETRKb
LhIYywup2pk7J0o1pM9iKKEnVu9F0WV7nrq7MKSEKsZEMAJyF3z9j7vOmdGa
g0ivYnxEEIccCGbZh5QTOg/TiO7YRmruQAJvXSl1yaToMFcNQhRRAZSxNoSD
6QO+8tgn8d9r8Mpd+CP92ENh5rNyQdiYk9YFp9arNdsq6Wktm64rxsfU2jPO
nfmqJ6iKHG3nwPG0HRAI4c+OVhtGEaIv0+8DV7UjzbBVV9sYGeggXpdAfBNm
aqgZl4CkmZSc+QbPx5fOBttAkx3Txa2nJW0NM0cj4mk4iP/SBNHP7otAxjsw
0kCHVoDj9bBKNncDwrhdYOdn+fxzEwrTYkH1r78WBNr+X3D9bmobF8/VUXvn
kruw91twQTvZ4U5/IzxQPb+oq+ta8ID/yXjUjRug7TbaszIL6xVgB+dwdaWt
0Gdi1oNpYrPqSyAudHCHG26Acw0yyg75O/S4+uDtYCt9UwsU7ObVBgAba1MT
1t3Guyahab4PjmDz5UYUle9us7E3SM322zYifb2wecNiD24jzm4Cxk2NXdvP
Bg3lmpJt74nXBfRVl8tb4SLprr4CIQFsl9cj5TVaslthJ37+X1j5r46VtwbW
7dG7FW215t/X0E5C8X8S6dxw4P4BSLPhYH8d1J3ylLnla1Wnz30lR1Xla/Wj
BhNNYZVvb2KiUfXqnRlZyqZrdjKtQSyhmhm2irkvpoLVqH2l3Ug1JKY6p+YN
p3wu61VVRGlSESpH9gyyoaHldDXrAcj4UgW43/Bv2IANXkbOPRzCzEqkFsmq
yCuOpJaMR4lraa43/7xyhVMxUStpQ6TKSuJ1FpQzIcyclBhn38ARAFV0IOBp
YiKRJilmwiXJYIlRkshqLgU1ImrqAi6ILFK1WHdZwS0N3BAtegHKBeI93VVN
4LQfhR/BBoWk5SJFfw5TeapFVYH67JqzOnP/zqV6m4XTN4s0p7JtuMyrOy4F
9Jp3sXPTdGJ3GJ7SoiaZZFhiyC0E3SxF+E0Y39mbcViMjQ7Oa6U3GKws2RLl
EvVgXP5NOEBgK4J1SgJZYylqGoqM4Sa2GsFv9YO/YPds0KFY0W9/dm/ecF/0
k+WLZS3v2HYEw3vrDuVNE2jfaOGBlkhdIgclH9NHyhm0fJmpklXnLFRotpYB
Iy2iqEOzFv0Z+gSRvvvqinQP2302FglOrOl0MSTOakPYgmsTx6QS1MXGWFdp
yGk97a0SeJ9rIchYD4IUfDEaVozbFXtWQ5vLYULfPz+jkCu/fqmlbRVIW2KX
ucD8RtuUJt1oVJtJjoLyGGqsksIRsSEEGgpElVw4kdu4mTDK2L7YVQC6wK66
XjWrsDj8UZSyaZCHyeXhmVByJMw9FscGiN9UG0fsx0HsIAygcIbesBeyTYyS
GSZc4rDb2IYtOCcH9hcR2uYCPQgcHNEAI4Uu/3aDNyASNm/DpVsiEmkFCRKZ
VzP30TYKR7QNZRhfkDoxwmiYiYCMqjJVfMK7apgKNojWojtE35k9CgmUC8KI
0RQDtC2tKem4gsfNKf2IAWNVQLfZM94T7mrhPRP5FY3H8Xd6mzkDSCuhPByP
meRo1IDxQTGuCNfd2ZupK3rNhD+Bv4nSWJwA+n6eSpSN/Uzcxb8VwtqYrtjk
m8My20sB9L5PFQnJk6bZb2MK7f367GyyGhcB9O2mL8SFRt9TmQXMwHWSjkwP
eIowLEhn07KA284o/Wsv2zgbfPurDmLn0npRVdf7IjS2wrkibLiwgp2nU2gD
3hxD5LgK9mVz9l86zHymCKHVo5ONom40sp0dEKycb0jM7nqAxCB+dQxuTdEO
0wkeoVdnpM0aXz6J6R8Qlg6AFwa69fP6h+QV+oScQ3UOQk4xlp+n4ZwKUCTs
ILfJwmFHTfy+UAeFnbqaVt7Iz7cPTqcbMwXFsqo4NpVUaNT6ONXKX/v9QX/Q
pX/2XWD7PtxtWvpp//GjBxTpFwotEvKjd4ROV9bDs3Z3D1tZKmse9p5hzjDO
1YoW5MSEhVXI95kqfVFBgoJdPMjClGQVxegC3tTE+I2wqjrjh8EI4Qg55eDh
6bPjY7QJYeglEFippKjx3lgHIZtk6J2KpcMcM0nhRLkru+6aqwuhXDvjAplw
miAQ8G1zZQvAGl4mND/gnIGNh7mJ6wW7Fb6MqXi73io0bXFSljF9YHlnWc64
MVwvcA9i39vs7+Fj1pqMEwkc6r7YlrzVpemQa9N/4wXOoKleLMCHZ76ysAg2
yl/AiNiZuMdKuroGWNTjplG7Ew2dlNRECiyR38G7HMuGViQBvaNyPfGxZrYs
4613746PuozD9/YGA4yBJaEEuLGpEBGtRaeI6uVJLhObUnVqvkHJjgabw+Zi
2Dbaknzki3OwxbvLtT5xbY0y4djPko1x0Lx2fi0aI29Lk5jZYGck31ARRS7g
pqhy3HC17Do9wKgoPmS8TQH7d/yWDvl4DPtSqcUTQctuKTj2eMn3uiW9ZH/F
k+I1DfMCuKvUs7nWw0BkflqWT/eYVF5Q57JfSBYk7QqCxvDMjYhdU1mrEYFg
Uv4qk5ZVxUyrPrlcITpJe+3IjU9XzzMnPebtfAGfqjPv6xy+FrqzHg5sCxr6
Kk22kFJrFRknTJAz8MYiSYRCgm++WKQLZQVUJudokXOuiTM2c1LeY7tpjCdx
D7Hai/xGcrLOOtgb0R03Yux8yWW1kvvFZ+zROVOMUMvANw7KIwrpcgPr4eYg
5baiyjipwEc7PDIwyiR1OUiwOzlU16ymj7VwTfZa9qXBapreCUMIfEgBG94o
iRXIVPiSkn7L+VJSJFVYbNrLeq2BAy64WRaY+LQ7RU6qSa5khlrhlKme9ifd
y12OE6uNVOKXrB4ruqNY7TMD2JVORHJ5G2Rvqq/ZGU8l1janH7+ppdRUI1FE
MGBjs4iPgqG8043eZ+yjuuKYalFHBNkxBMcx74DqtKLOvd3d+LtkrFq1TpDx
nWf+LT0gsu7T8RLTHIkrOD3UuA1qyYHdTq4TlsCydZF3ILnfHzTUEyB2/wFJ
SNcm52/pONIcxTqATwGRfuwNk7HqEl1wFPG8rqZyY/X08hlzgL2XaT6ppwfx
3v5e8Bwdnw/iNYGSJkYSJTPgxsQAQnLSObB2BLJtj9E2Enee/3L8+k+HL4+P
fnlx/Pzl0S/w+7vngckHPiKCjYYGoydqfkN8An4TWrZ27jQNEJ99pFEIpesF
JgT/cwK/iTHy2hGZI+vweS5cPFsDqViW8r6W8lHEl5EkqeU30pVhjzlVFmVt
OjacuU48zGeThHDifiTvts844IkQP5wDl5FMvIDz/vkvr45PT49ff887895d
c8H80A2P1CEcwtj1ApKdg6k+GpxHvKFcQcuV0xOSCGlX27Ig9nCVROWlsjBr
VTRkWEfXAghcv/wWxHxPpFPXqgBs2TBxJSbXNRLtio0LccrIyKNxS1e6VtNB
AKKv1YdZPRgT/i9ShbXowYyqkuVe1oW5vQw6xpCUrCIpiRIH0iK7YkUyJFuv
JRRUGuQ1VMdekountELRZL17Xj2zURQU6ygvCmQvliXeTPOiTFsccNdsKi2l
lcleMqKM73A1u0xL7MipF1SLFaVFUefpaod2+97gcbx1VhRoYVsp4a62D1jn
i935sDEjEqBSyJuFMNddOtaCps5nG0CIOVj6Te2yWwCPgbk6enW5Cq5fEqhp
d0/S3hm8pHRDnXiaJmOU4OG+vhGSyjXqBYx2W6dlVjU1kQhb1HgZ2h4knTnQ
Ar5q5dwpA2Xj3maUWyYyYHI5MjnVEecsxISZKJvUVHekqKqewzVfs3oMVzsl
e4sEpfhLVLKMJdKaPK3TcUMIFdseK4md7+kdVx7EPUJmkzwfslFWryQS26jm
Aw1GZRQP1E+ULOF3jEQQ3jUwDhEuAiKXqBGBy5me7nVEMVVVmHAw6kxTQHDE
yk7sEoEp8TainjFeaeViTw9oJAe/46N21xlKIZXkHDlQm4xAwJNno1qL4ML1
XSxC3oaslOSN4dgc5nmgb2BbGu4b9OqQfDBaeBqnJO9ey+9QHwDdosz+Rl8c
yNb9OPi4+PMP93dfnS2KP//wsRoOXlTj7x/98Tb8VMN62sqa3dsLea3gbjlo
hWwLA1RcryhWe7PxwEBUZauSS/yAvNCxpuM3OqNqSapBuAbX1WwmB1ikt2/I
wRYLOGqLDczrAJjXN7eG5WYoDu7fb4AxUHZf6/2DX+4MHu49GjzC/3vXnDXF
Reh106qWaDrbOK0DvMD8kfad6BTozYPueivVC3TisFP8AI0M0HC3u/78V+rQ
Jrj+HDV/a2OieaNuwCO5rW9GJCR++hWTsaOMakofBjQsir5LJfedBkmkvm+n
1QT0LVdhPyEthNNtCp2E78SS6WqpMepWDUuzL6jzqL/fv4+stZHlzqZBsREr
QbooSZwopbUIEV84w2UVFfOs1upg/hYwsQD/RfhuQ/ia8u9e/O714buzP7w5
Of7z8yN6+8MPP/QMosEcGWvcQYAbbzZ/0mmC1Mijfy0W8B76MM+S2QTgVE+h
5auj++ZFjiaRJ529h/vD+8kwuTeA/+0+TtNBMtpP7p2PHz5+eP54/NC0KBYJ
IDWMMNh/eH7+OBk+enB//+Hj5MHj8ePHj/f3HgzS8/v303ud6F8IMxpAVGbj
iWM2ul8AYKDLTzqhzyVDHYHeBnMA+W+BeD56sss/hgyPpJ8/n032X50d778+
ejF/dfQfu6//drwH/+6/+uH5/p/PXvz65/mr+6/OXmevBsdPglUyDXjSeZQ+
3n+YpA8ePxjt3d8bpPfOHz/ePU8GeyOYx/69r9v6f/5R+0dd149kRn34CZxI
gWqOhcBfcxFZRpsZ39bbpf0icmLJ1R31Fv7swkX5CphQLlWjuKNiaRqDtiH+
LDCWRGqnaI5pEjIgXHwQ93udzHtbMhEjT9XlRhw5MRBNLxnyEnPpdtU71I0m
Alf0PnQnpe0JhlEhAu1EyrAbYdhF8hWRhhtuWni81bh9AaztF9/22s1nHbG/
mM6teWh3b6JuN+DwBt/tVox++KBxxJLxOGQXaXf3Bvv4dO0EtmxP5zpXa0WV
2/pbv2JZOMgTyudGUaXDfkx5IIe7xDpoyCCdAe99uOGK6UFelRtY/ZwP2kH8
IU0XOPuLtGVL1raUgUxPrr3YFNj0OaZ+163g3/8O8kFLR00RQD+5UVbwH26S
GIIvWuSGlh7WpQf70boM0fLWShL29efGk/Bv+xcjbfSD6LXKRmlJMdQYe3rg
hkBUUVb7nn3aUVVRSanQW6Nqi6lLsmTcEolbEG4tdciXoNzfB1MsHjz80i0R
H38qXEvpjc5RJOrZ3IxwP1LCacnClrCdrJHL3lZKrkMhKSwhGjlLb7PYL9nK
g29tFiLTabTVtpOlMyxuc6y9WIFbEqWJmk5NZZxpidchkQy5z4blvFN8Rdww
M1SSB/nbnELMKvxVKCStqokocjH+pt5nkAbO2xmvWw0uwMw1dMxr88pzKpib
Mu0y8YZb+cCmKEN/t6fcyTUlPRrJ6XxBVZ/mMXQ48DUJWNCv16VtqZlgALW1
y6kM97DkOOZXMZEMQGVuCirmMpscvmLYm06T3iNMdndgGNakUk0N2k3mO1Q7
Tm2vHfI6dqTTj09J45wtewLTz58jTX4Rlqrta8ZUNh83beiu8O/We7+b78U2
KY5yVnXB7mzjKGkGcjBQkWioaTpIR2OjigjolLfdOMxjRQ/Ms+hKOXHqObLi
nIcVnKoudmezwLvKpj6XOSf3SV2qF+e45ZNCrtKaHTrIacr1jZTeOoo7Wwha
D4KsTDgYBR4tFmlSApZutHdIKQGlirRVmieEfB7MYnC9711WP8TaILEfFiIS
V4HQkEIOmdB8VkyykZKVA7UXtmzvgZrM9PCw8OESQXGZ5xlu/Hk4w6AzvKMJ
ufEyPYgXy9qYiNgZcJiMPsC08LwuU8kGI55ASagZK8klBU25atwyVX0pWgv7
c0mVHBKTI2i5XFDtd/bDJF9cjdeiw+NX5Jauz282Vd3e6PfV5j6sDz1JSorB
Cu8KtuLx/LFuwNZrQO8XIOiNtw+0KK73yZa2zkVAai+EUONUWZ6lCb8W+7rk
E5LTK0lLeRZ7u/HW90We8gT8jTwVR8K/xpqUiIuTUf44ua2UadWu7sdb73Kf
N86nWPSr8zDEKjWMcG5m3unIL0MzCq3fxOYOHSHVyk0vwRIH99nw+jwpZys/
FVyb2FMtguAJ6ekJAfwYF5fSze3ttwuJwNtynW3jrJpm3N9kxFUXBnNIr7Xi
Ig+kwuHVHXPlAAX3ta6VsdareSI+BU338pB5iYhd2eVSy3sS5ST3R7F2U4Wm
IhghtBMRk7LpPv7titDgdo5/Ckwp8bW6UWs3oVx214jhuAib0bhx/66BAC3T
v9lcZpfWqrC4vysKC0zbzC4uJqcbRT2vaQXp08/NxeN8b2c1Iv8TBId66nHy
99dAq15jPl0MhYF34jso9qEfptnMRC1IQuiE/TzX4t5iX6DDON9GYbScibxU
ua/r6v9wKXj4TG41l4g4Qm5B2BbKMD1ceclS7fTOcZgyI3gxtUxd9DN5dWc+
HZmbvcu151zZYiwNY5IdY1Urjelbz6Jm46Bz9hbxlwHmYsY3QEipHAyzTwnO
olF2iL3TG4VciAVJZkHqfHQHx9qlhnRRGjCu3peOW2SBqkB3fZ/ikdkWohIN
FxAkdzfDwYUUUDJKV9bLxlyakAhWBnvx78sjrv0cygBNJWMnB2B7oG+KwNaF
fX0QNgeuNAhqU/oTotuabFrlPdYGqFfge5T43rc4rr1vCoHvRfr0EeXqx0oi
r8/yrycNoC5yoIt5Z7tq9N4oQ99vlJ6tv8my4vglcVwJdUhuMc5r8z25igXL
Qp/FYapOgB4zVKgKqPTNIZ02hacota6P8sRM48b0bAo6bG8IAI2uT9DBSKGK
5FB71NhPWXTk4l5kSj4hKx4m9EunWoXYtEV3tdadZHn0Xt3v62Ty3nsIyneN
cJu2bKnp6ANzoKtIj7KvjRGXVGj5L47l7GqI588hCmJUNjliqrLBdaZ+uixV
GGhDE+5xbU4mHgZPDkdFc5lPaUTg29XdlymxW6jkfyWsyFNz6rM8m2OUW8El
dOFyIF8rzle6MVSLp+1ZTPG7wdSQI4lSwMgHENwjDCWABvVIY/WoCKeJo3CB
EuTfqlvKopTTv0U2jsWRwI0bzREr4kmc+bNCEt0CVRlOsaewg1a7/4oyW3jv
fKnUdr0oxiJOqzRmbJbAAKVkjmxYI/lmvtx8I7kEn4fGxzBRPUiYKCVMZKI+
LESUnDaqKwqhsKJKWBwm9sVhsM7g5Zp/Y2P0KZ+5ePfRo73dR7sRjxDUklwL
xYIRqZ4rK+NcTItDBwVK1AYUJd+3t1EetHnnhOJIQxB5Q6WxbymHrJkRbnTJ
+Dv4AzwYfLE/gHeKSyb4ieyY8UUEdmoEO8e5Vou4USYIY6Lh//vxoqAgxIQ9
6qsDX5LmnlamoX8eUN3jxiOhscHDEMENqWCqW3HxG+T3RFAlSicnrkkwOfZK
GYghogp9zkjXGDjyTKvzhiS0reKWMHyh0gc3mkY37G4TU1p3du/x/kY/yH+y
E+NGH0Y8zb/ZixENWm+c0ypu4FuvP30WOGtT8o6qF3pwq5ELKVJVzCnwbl7k
3hGWrumgm6Rq9eroRqyngoFJVWux0agB9dLGVD/qePiY8xC7rra/hfZCMo06
+NoeBus9GE8NTbdHSbHlhmh0sH9tB3TAMdEQRqVQZrKw9b2wNQsJcvgpYzcB
17sXN2DqygADBeGIH5aSL1HLX42WVRUN0V9UyqeEjZFyv8Sqr98lsyQfIaiu
7mAZ2N5QH3y286kvCy7QTSujerHuQ7zMNOm28k30Lem0C/kwjVjVn/jqLByD
EEb6Syy0T1jE5c7DrojR0q7aK9S9DKcYDikxE8loysmOVBvPNNFQkniWrJBx
LCN5l+XnZcI6DtRt0OtmXGyj9A7nQ4rWpUKKmveFE5ZDTtRQ8fNKSwLY3Ad6
366iIGECZfqwzkVh6enZCqV+s2kUu2QHcXvTbxiwbTlsDAsxaf/Q3l1tKgam
zlQ0Pc8uuRsNM5hP4eKcTA0IhDtVh5cKrys26iljAwQDhaK6LMZLqvbry0Zz
9O9HzqnklMuNIJFhyjaiZBwJJMZrUc3K97AOSixmqUSEXZZoCUKLTko8Fdu1
8nE04WoBrpC60CAUWs8btxueJcTpjI8iCUaowmZrFV2mQf9cLwSuiDqluAKu
7xEI8mSt4Dx+SOeJ36uLktQ9vPt4XeeTmV6/37qxWsNoCK979xoH3Qwd6OWp
FpLDpbFXNNEcn72N7/fqJVtjJS2/3bbwoihTjdkbc+EXclIRuNqdE1O9kL7w
HsEKG7hiBBnlqElKOOp1Sof2IH4DgmVVzJbKzmKxS9odZwdxDVmYxbGAm8Bs
Kwf8ErocFqLPC3PG5By0rXkPvcTS3FRUB/LG0kaRhtFAETtBNguB6ZR+QdZN
1cCZjCZ+KkzisBOPiYgG5TCrS3Te8WtsTKzrywFicy2dzsZtWxzBT49gDjcM
sLFLcf9oUBtNJ3OABWAorY07ojK8tz818b2lOyqZMExdtyQf6viEOJMlMPbA
8Jk4UC7kfd4GrWR2maxIykzKkgTI2n+m1QrXyDxfzUXJyVtE80n5JUxImE2S
4CDE5+vhGk2WhBmG+ruJB4eqkcIJsbTIjcKIC6O3X/vPKFDP16hzpVGopOR4
OWNmwMbzRZF+VYdJGiuTm6URKuhKrmSkwpeyHKEbr6eJiyQr2XFYOlZXInXz
xAIkW8+28biO3VwwXiUIfo+3Xm/3g0wookwnXzm4710kpTMnBWlIsCgNSfSa
mkWVfil7ZUinEXXKtX6wiq4vL3OwVpO19edur9e7e9O/0Hh9dTHWE93FgtRP
Pz16zP8+lr8f78m/Ayrg/JtGvuEHa5r+JL+7f2/X7PbtvgBKzuyGOCJDCVRA
CpN/B/Lvvvx77x8EpU+/tP98Cku+0oG5odyrmp7NKX2FBQ0p/lB1SNSR1hh2
kBANbkXVdJEjwHK6tmjnM30Bvwy2I65oaI4Wq8089qlKGNDOdvP60eNtDfqS
g6pfoh5gC3rfXz+3mzoHXN56/Xh3W5RWRUw14tZMXnQBYAzyWBOkIU3xlkJj
3OR8WTN2clABgebLjciHCVhQYC/wLJ+rV5KNr15mWEWJmZWKHHIoboHT2l2y
e1CbdXK4RN7WGPfECUd2de+A4dawqQFEuzEAAf+z16V9ov8OmLzzHUGTF1on
HYgYM0G3u7xozrZp4qvEl4gUi26qMCyBDEYO5zpon6ufHP13v4uzD6aFw9w0
s+YssCcuM458tfmcbh+TgMuGYyBKCLMTmFPdLUNSzmQJODOjAuhB2sHNigGy
ibh7Y4FZzuoqkjJ71dJVX9LxRLrkpaRjU43VoFSVnKecWYywJ1LXGS28rtH6
scFYVCCvy2WMnA2QVhHw0KMPs5VaD1yyJVIusErZc57Eh9F8gzRFlAwiauSJ
09xvG9gLyoSOKzmdJqUq9v9EYvfVnYqe9Rz7AlTsBbKUup5vgFMsMvapYCd3
8jxFfQrLMUhkFkExPz6JnFB8ZVMGu4xv6iUsadhhvlbN6sTPqFlscyFJ8+j6
Z5n1nFKpkLbLs0Cc+TCyNdToMy6bxmnQVJo8L7kOMvSF7ruSNXOO5juXqi4+
Rb2PV/7KRGi2mPQa26Bih0WdRvJLNVIgqIIUBXw3BFPXHIrIGGke+rY+fQ73
jRvgGCwZg+VDk8kb0VlLiwsGOT8Qm4ux0lSQJA8kcx6PCYrRRSG7zkoJzLvP
3QA2Jz6/M7VnFMQeOMtqb03k9WtjHCHUczXQnUMtWWMT53FL17z3hG5Y1WnB
hLBcz5P7ZjA5AUpmi2IQd6fjD9EMA23S+aJeUVdIMSX14JwsczWSjqyqlmSN
QiuOtbl9a5YaaAjylBXvjRqjMpU+cvkXgFgLkrAwpSXbYr2Cpv2EyMVOarY8
GpUgaJdZ4pIxKpgE9UeYysNlfDNJO32dSfEX5gtf63cirz1KZlK5Aeg88ODz
OQ7qND8r8ddroUpvcAlMlYqyHi1rW+ZYMxhjgH1FQYFkA3Uh8nDkFkgQWzVd
WwTHDOeX3d3bRpeKNcFPvSuQhNH9VuksWnqk6rtc8sV9h07fKpFcYoX7nHTy
KbxCHsexehkBJ7v7Id76ED+N9lAYOsV9cB3JBJKZpI69UCN9EDXh8zxGVDDU
qO2AGJKTLcuhGA1D+YbEkmBU78V51Lq6Gdw9etMBr4XQWOWjaVnkEjutyQei
4J43VNh7R3svLirrS7qnfHyZjWuZPKlvNAOMrzKqeIwpb9ZlddUuJJdAPqgA
KVAP9M98o14yHpycLJRDrfg0mYyEFphdThnE5xwuiqpmPQirJKnlX5eUQE0M
1s5nwWEacRzUh5Ql9mgk+yo2WSLELhNlEXtvPGqt6IImh0H7skQHZzV1SrGK
Nc0qdLO/GTowqeXIaI5HZgN1aeNC9WZU63eG5UvZdWPtU+Hlreoc6wnIPrLx
2KooNtQcrgtESrtZmmOZutDR1AvcadlMA11m13n2tXYh7KAclVoyIvmEqORV
GHQoDg9Bk8yocL2KnArQnGqy6ZDusWOWzURtieKWqxZxv5GM0eV8RY1TpOU5
ye115aFPaXR9Ge+GckyvdZ+FKZO7DB1bJjdMyJQYlSlFwC3Mgjl861mH0Tq5
J9+jMrtIRitHTTADQzjMvbWVs9mtOVYfE/lnSsK7ker9gkvLKS/Jhcfrk63A
oYnLH+8PYDg6mRdFNo7wBj97CRf1coYJqF1pCLTj4XlAQRsd0+1kgQWqOCN5
NU3H4mFoj6uzWOpDT0soliQwEvHzaLGspvp82wcPkQbb7jf/xga6pK6T0Qc4
YeV5MkojuD6BBRg2SpLAnq7tqnN4VyVgtRz2Ks3+LjZMYuXMssqs+lCpcTAj
bibFxN589SO7cxAfpTlcFL3ivHcqSzykOcKRONSxjDWQbQwV8VGjWVJVzI2s
98Ir5ezsSHMyTHlbdoNUbbHyLsgqYzI+rWE1T9BLplhWVhTEXICTaR25lJAU
4wD350V7Xrsu2UQ+TpNlFfhvWFZ7B9gHFAtnBexKjhfoLGbcdxyf5K93ftiu
DLggpJBLXm7o4YdqbHHRK/jSbdxWHL8WMWjZ/kjOnQhdpzUQqk5adgngkBAn
1Df3Y2ODBAoEG9wIivPGYTcrOrrXTi1SLtX5pnFOODOzIMTETW0NArOCdQkU
6yyL1KSNbMVE6wVsdQfDXzD6Zc7CKY/bce57wIgAyU9YkM+DyjMLVGCxO/SC
wgKnIr2jaxxdNiBgRIsC6xAIvWiWC3dSJ381S53BTPO9o4fBJYmnRYlxfymH
8mAIXZZfFLOLMAtCepHxeQY5CJUegBvHbzEWQnisblSiRy3BnuyFPm9zzWyg
YfFoDTAeKzocFmB9AYmZitxjTUevtw/Xpqdj6uVkJ0DDrjraxpIGiRDkgKcV
GbrhMcRdha1JiJy61uzFkEzKlLhF46tkxBQppE3p/6i3A5En4jfIyhTM7QLg
j3McgKfC1NpMjsTOAoMjlkgjLPPAmE1F1grp0dbqE8UBlXuwVKmhdBL7BnPJ
hk23tYjEsVYsjEDJs0m+HlOGqHyOt5tURo3nKVZSzKp5S5BJJOyfYYdL1sr5
UklsXgtw9+zZ264pOxj/x7vjZ5FLpk/5LQS5lBUKp0TWSlqtrySAlDaeprMF
VbxCjY+ZKU2HeXEFMhKidzmqiAu/kWuBF47kRCxYq5uIKxHgRVzagilMI4AE
xgLDDnfj5bVj4VH2wSAmewMWXhjVEZBU0rHaoanIIzEzeI5UzcoKBiRRs4A7
jjx3rIH+U8otC4ONgPIAR4Q4hgrvrPbexWE5hEgukNrhdekK1I9UaUFs6/Hh
68M1lpUeZk5pwLbcMp1kJCiGNkMbjeywib8tTZ0BtOVeXWHHPQqtJH/Bz59B
pPu3lsA1lxflgHPeGWYmCD34dnNz41J6TSd/pT6eSr0xli6ANYqfjzH7zEH8
dkYipQSakfa3d1SMlnN3mLWFXHBcowbYFzi06djx6GNpI7qRzQs2gadAntD1
G/OVYQEK0yaKTpfDOngZprCKTtR7w+dJxs9e7xxGkZMQW949l8DrBjuP7ze8
4hI9Y3ZNnvGC8Sh6tb5XBa4V++3YaHxJKIAa/8H9xxRQeNouN+F0TlM+5Bvk
LpcYCzk3u2t466Nxj8QHOR3rvQMw4MO3ytg7Nz9OKwcfBGjYNsihX6rcm6xS
zWyIDPYUZnjUcrF6JYrNBk4yqW+Fn0WYp4Bv47FkHMcaRvhhFOAWHvEXZTIh
bM186ZvW9UaRl68sOaHiJ78blk9JoXmUIkvEpUpnGYbnYZF52WP04qFVwYfS
J/z2KkFOhs/HVrXdePsC5W4n0vj3Z/bYeDpnYiKIJp3zmXMCsvMxdTks2Rrs
7k+nU0HXUjNyX+Y6Qt4HyDS9pXEwUqMx77ewV6JrS+dA4bRejpRLAY6dU0ef
c1LvJjgRdzlRYfUNSrXYNHUoKxhKsStL9sA+iNH48+Y1Hmx0ShHpDDNL6we8
g9TprYZ4RmWX9aoGPg9b0cnI0xoO+wRkZVbWniXVB+QLgP5t4WLr4gC4lMnv
s7Q+7xflBBVYb5EpqEQ4ZOJPq/3vNLWCqN5NZPq3kj4bRPAvSgD/n6SAf/3/
gAAq/bst+fsv6vdf1M9Qv16vRx6WyHEfxn8A4aP3kqRawKdZsaJNJo8itM6n
o944XVAZDUxl9gxF5QUX8rYFhlYV5q8QjwNRgpZpKqy49eIjE/XWyd42twQu
PWe9oYtH9rqtPn872LaxgJquaC1tJxbZISFP6g4SRqKLOOZHUddcwJxmyXKS
DGWo/W1SQALSwBLbv+xqzqdYovWpwBSRCfk+iuOmK4Cz/Xdj4xSwzQU52oIV
buEyiB5nX/SzyT3t0yavtU0/nyId/G74/GTvIH4hO7pDWWbjkwEmPpY923kF
ewTP9g84dR509Enn0Mkmad3hyoWfzALtEM0n7m/bkdutPV2a/W/c+sT9bToK
YEd/Pf26joItvmFGOt7T1o5qSTXY7OKLZ+Rg9Bs7+t0ajFp+ru2IFWQhCm6a
0a22fx2P1jva+NMKo8Fvm9E/BY+u72gdj9bPmja8FiHX8Wj95z8Fj9rp0YYZ
Xbdr1yzhC342dfQVNDtwEBY1NN/HNzgKn7KXJicqbVztHXLgJ2XuW/SuA67G
BQy4OICXhYo5vVg+3ou3TsnivH3g3BH5pvcFgejKN9ES3TDOKN5iWxPWQcwS
uiulMKS7sLfNiIN46wW68gzNmC3jafxeLUZAjKjfMF4ypEifDePtx1twXcV3
6YKCEU9Y23yyzz4gJTKZqNWckG4VeSAKWTvZE20y51mEYdTH0MeLSJZ0x0lL
grfKAxdH0nmw+ltfrVdzZIeglfcs5oiVeD0MMDBGMmNl+97n8K0gSpArD9XN
CuIU8GYCFEVP/9qaqaKxx7Vz2jmW6jKHFJINiW0pXXFHrZzVsYpkMzHmBTBn
yTLfcBX4d6CDErkXGUckzL1RLEVF7L04F9NVRQO6OKtVW7gNpngUobcR9vpZ
EhSJAZrk2LwZ8hqKcQBhznWlu82eL95I7t0oyHjFFb4U50kbjtFTWrUZvul8
h169ONJbaSnmA7SJdOLv0Fb5TOw0b7HsN5n6mYUfjhY9zNCNJQk4U78VoEFk
Qk/KShwcKP0AuiQMdtGpAFM6i+wEB3VYlEnD3ZQQxwl1nTLl3DzEgNO/hZgw
Es3TAWuC2VVSf1HLhjqApDOxrbnizVSBpuqqDZXSlZBTXBxzThAEi2SS5SKT
HXEtAbmEbGMjElthrZ21YTj/n5S2tiHU7/+ip+bn90EIMAhQKGqjCPT+L1ld
wWuqpRobxr9jI7v3XWg6A3WbnWq9A2te0NoQS2EHNLkRpghzgVxV2OGgrcPX
BWfFWc5tFi8yP2fWuX3IdSZFgmLfIpulxox0b+PUZeMZZW0d2GTsqy12KHk5
j7yiFHJsz9PNd7tB6W2SkThYW7WJ2pwc3eS8QUHEqVjcJRWT0zzQ+XAymiCI
+pN0eXy8BJIhes/mPqcE6wg6twEEZ9SDwai+dwpjkTFTQbsZrq07yEKxAaYE
mQo0Tbk6Stg+yXIPOZYUpXg2J1OzWCvX4dB5HUhiNUAYMpYrfN15cNXBrT1P
JemkNqbl2NN8hqohyi4OV0Lp4GBxpSq499OLJPd1K9HR/aggtx+q5pzm1bLU
vMIIC3OzcOacc+EM8Hf1aMCWW6F7apJTjS3neCP3AIZhMKDTC4n9Jf8ECvpE
C3ticNoAErWqSTaTW7WjLlkrB0FXQ5k3i9K8BFt/Iy45osauI5j3O8w0gX1s
RiAmIBVlIuNMTnFH/DtIc4d3uawIoWfI6vpcH2wexdF8SgRA2Yo0MMGFQjN3
B8+m2UI9ljmwFxXeNpzVhqT7qpLenP8tDOiRY1imyYeKvWjEdcROQMkeJ991
gc2O3Mg20zFiRwp4BbCYk0te1lBJd53TZDe2jzWy3uFPk2I0t5kJpwQCeMDQ
gsSb28EjUxeXIJyJk2kozklIbFh7kmblGWSt7UBYP+56ymQChJz1GImYR2j2
T74Oc4lTebusplxpVzDYYe4p0xz8gOohVNNGPYRAvS5uPGQaJ+/59kpB6uVi
CvCo81fA1pD/umW4s0bMtLq1YKYi4MeYZ8IRhspqiZOwssW8MnGSxwX2KRcy
avGdwz0hI1ypbtRpgozIBRLcSaKJPb2XFqEvORxS1HMASk2vMFxFdfKB6PUY
SWZiU9Bxkk2E8HmaEM+pNxmLLvTrPqmy2TtjnKJrFHl2hMPFTc9+kDBKdGAB
lHesqMQ24S2Xj1bbOBi6isXjFfBEwDil+UVWFjlzcORIiknJMG2rZJO7TLK6
d44ynNzTETrDIr7143cWwHZpRI85spxOqEv+R7pzTXngHJX0nPdjToBLdbHH
BaXIHi+dd8UM3VSL82Ak5cWRQviKKY5w+NCSNeixbFhRUJB6oLG6mhkxz/IL
XNUJI0YjhpxEOja+xE+FCv30grxEmygW2GRwj4I+TNYU7xNEQEJg50gNfVyT
xBIyM9dFhx4Oi3AkfsTCCOWo9NSCDo6HuT9AfDbWkuyG/meSKJ+dzpiERUzC
OIUKrwMg9XGlgczOtUtqnTsHPdzXTBKtmEj9yI6nVMLY+NhR34b2tzWgKRBC
2C/d07XgB0nNwdTC7IvdEpAGIwas5ofxOxSXpEpw+0T3FyHK4ehDXlzO0vGE
RZerAzbmpeMnnXM4Iy5HdsIGp3VU4drgs+yDHIIk/xC/SsoPKMQjxzEVN7rT
BWpGyugoufyQiQ89m1o4vxPmBpV4LamvDVRsAy10o3ejw3GZwc6+SGDVIPv/
BxzlH5ZMwP8ds2PFJ0UVf5+VyczpLbLSukGep+kYrVfd+ATzWf2ASVy6wDbm
CSzreVLVM+BFurikGpNQTYs55QX8DmObynF8OC6GSVdXF8vquvHLLB8n0dEy
HyYlrx/klkn87zDZiVOgqO2J2RZxv5aRjpYfXKBhfAhUI1Krh3zajV+USECr
URK/TWbFfAgkrBv/kFazdBU/H48ByU8KoLEwqXw1y6DBKzhZgCZ/hEsIeI5L
RrY/J5iS429/S/DTU9g5lHllXORyRsQzwIfHz0+/99PEJ68K2N10HH1XLEfJ
GPNrULrGabqA/sfq/O3dw/4v99pmRPMjAQA=

-->
</rfc>