rfc9569.original.xml   rfc9569.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<!-- xml2rfc v2v3 conversion 3.17.1 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!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. <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
6) --> ipr="trust200902"
<?rfc strict="yes"?> docName="draft-ietf-alto-new-transport-22"
<?rfc comments="yes"?> number="9569"
<?rfc inline="yes"?> submissionType="IETF"
<?rfc editing="no"?> category="std"
<?rfc tocompact="yes"?> consensus="true"
<?rfc iprnotified="no"?> updates=""
<?rfc compact="yes"?> obsoletes=""
<?rfc subcompact="no"?> tocDepth="3"
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft tocInclude="true"
-ietf-alto-new-transport-22" category="std" consensus="true" tocDepth="3" tocInc sortRefs="true"
lude="true" sortRefs="true" symRefs="true" version="3"> symRefs="true"
<!-- xml2rfc v2v3 conversion 3.17.1 --> xml:lang="en"
version="3">
<front> <front>
<title abbrev="ALTO TIPS">The ALTO Transport Information Publication Service
</title> <!--[rfced] Please note that the title of the document has been
<seriesInfo name="Internet-Draft" value="draft-ietf-alto-new-transport-22"/> updated as follows:
Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
Style Guide"). Please review.
Original:
The ALTO Transport Information Publication Service
Current:
The Application-Layer Traffic Optimization (ALTO) Transport
Information Publication Service (TIPS)
-->
<title abbrev="ALTO TIPS">The Application-Layer Traffic Optimization (ALTO)
Transport Information Publication Service (TIPS)</title>
<seriesInfo name="RFC" value="9569"/>
<!--[rfced] For each of the "Yale University" authors, we have updated
your addresses to match what was used in RFC 9275 for Yang
Richard Yang. Please review and let us know any objections.
Yale University
51 Prospect Street
New Haven, CT 06511
United States of America
Email: yry@cs.yale.edu
-->
<author initials="K." surname="Gao" fullname="Kai Gao"> <author initials="K." surname="Gao" fullname="Kai Gao">
<organization>Sichuan University</organization> <organization>Sichuan University</organization>
<address> <address>
<postal> <postal>
<street>No.24 South Section 1, Yihuan Road</street> <street>No.24 South Section 1, Yihuan Road</street>
<city>Chengdu</city> <city>Chengdu</city>
<code>610000</code> <code>610000</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>kaigao@scu.edu.cn</email> <email>kaigao@scu.edu.cn</email>
skipping to change at line 53 skipping to change at line 89
</postal> </postal>
<email>Roland.Schott@telekom.de</email> <email>Roland.Schott@telekom.de</email>
</address> </address>
</author> </author>
<author initials="Y. R." surname="Yang" fullname="Yang Richard Yang"> <author initials="Y. R." surname="Yang" fullname="Yang Richard Yang">
<organization>Yale University</organization> <organization>Yale University</organization>
<address> <address>
<postal> <postal>
<street>51 Prospect Street</street> <street>51 Prospect Street</street>
<city>New Haven</city> <city>New Haven</city>
<code>CT</code> <code>06511</code>
<country>USA</country> <region>CT</region>
<country>United States of America</country>
</postal> </postal>
<email>yry@cs.yale.edu</email> <email>yry@cs.yale.edu</email>
</address> </address>
</author> </author>
<author initials="L." surname="Delwiche" fullname="Lauren Delwiche"> <author initials="L." surname="Delwiche" fullname="Lauren Delwiche">
<organization>Yale University</organization> <organization>Yale University</organization>
<address> <address>
<postal> <postal>
<street>51 Prospect Street</street> <street>51 Prospect Street</street>
<city>New Haven</city> <city>New Haven</city>
<code>3408</code> <region>CT</region>
<country>USA</country> <code>06511</code>
<country>United States of America</country>
</postal> </postal>
<email>lauren.delwiche@yale.edu</email> <email>lauren.delwiche@yale.edu</email>
</address> </address>
</author> </author>
<author initials="L." surname="Keller" fullname="Lachlan Keller"> <author initials="L." surname="Keller" fullname="Lachlan Keller">
<organization>Yale University</organization> <organization>Yale University</organization>
<address> <address>
<postal> <postal>
<street>51 Prospect Street</street> <street>51 Prospect Street</street>
<city>New Haven</city> <city>New Haven</city>
<code>3408</code> <region>CT</region>
<country>USA</country> <code>06511</code>
<country>United States of America</country>
</postal> </postal>
<email>lachlan.keller@yale.edu</email> <email>lachlan.keller@yale.edu</email>
</address> </address>
</author> </author>
<date/>
<date year="2024" month="April"/>
<area>Transport Area</area> <area>Transport Area</area>
<workgroup>ALTO</workgroup> <workgroup>ALTO</workgroup>
<!--[rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract> <abstract>
<t>The ALTO Protocol (RFC 7285) leverages HTTP/1.1 and is designed for the <t>"Application-Layer Traffic Optimization (ALTO) Protocol" (RFC 7285) lev
simple, erages HTTP/1.1 and is designed for
sequential request-reply use case, in which an ALTO client requests a the simple, sequential request-reply use case, in which an ALTO client
sequence of information resources and the server responds with the complete requests a sequence of information resources and the server responds
content of each resource one at a time.</t> with the complete content of each resource, one at a time.</t>
<t>ALTO incremental updates using Server-Sent Events (SSE) (RFC 8895) defi <t>RFC 8895, which describes ALTO incremental updates using Server-Sent Ev
nes a ents (SSE),
multiplexing protocol on top of HTTP/1.x, so that an ALTO server can defines a multiplexing protocol on top of HTTP/1.x, so that an ALTO
incrementally push resource updates to clients whenever monitored network server can incrementally push resource updates to clients whenever
information resources change, allowing the clients to monitor multiple resources monitored network information resources change, allowing the clients to
at the same time. However, HTTP/2 and later versions already support concurrent, monitor multiple resources at the same time. However, HTTP/2 and later
non-blocking transport of multiple streams in the same HTTP connection.</t> versions already support concurrent, non-blocking transport of multiple
<t>To take advantage of newer HTTP features, this document introduces the streams in the same HTTP connection.</t>
ALTO
Transport Information Publication Service (TIPS). TIPS uses an incremental <!--[rfced] FYI - We have adjusted the sentence below to clarify what
RESTful design to give an ALTO client the new capability to explicitly, the items in parentheses refer to. Please review and let us know
concurrently (non-blocking) request (pull) specific incremental updates using if these changes alter your intended meaning.
native HTTP/2 or HTTP/3, while still functioning for HTTP/1.1.</t>
Original:
TIPS uses an incremental RESTful design to give an ALTO client the new
capability to explicitly, concurrently (non-blocking) request (pull)
specific incremental updates using native HTTP/2 or HTTP/3, while
still functioning for HTTP/1.1.
Current:
TIPS uses an incremental RESTful design to give an ALTO client the new
capability to explicitly and concurrently (in a non-blocking manner)
request (or pull) specific incremental updates using native HTTP/2 or
HTTP/3, while still functioning for HTTP/1.1.
-->
<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 and concurrently (in a non-blocking manner) request (or pull)
specific incremental updates using native HTTP/2 or HTTP/3, while still
functioning for HTTP/1.1.</t>
</abstract> </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> </front>
<middle> <middle>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t>Application-Layer Traffic Optimization (ALTO) provides means for networ k <t>The Application-Layer Traffic Optimization (ALTO) protocol provides mea ns for network
applications to obtain network status information. So far, the ALTO information applications to obtain network status information. So far, the ALTO information
can be transported in two ways:</t> can be transported in two ways:</t>
<ol spacing="normal" type="1"><li>The ALTO base protocol <xref target="RFC <ol spacing="normal" type="1"><li>Using the ALTO base protocol <xref targe
7285"/>, which is designed for the simple use case t="RFC7285"/>, which is designed for the simple use case
in which an ALTO client requests a network information resource, and the in which an ALTO client requests a network information resource and the
server sends the complete content of the requested information (if any) server sends the complete content of the requested information (if any)
resource to the client.</li> resource to the client.</li>
<li>ALTO incremental updates using Server-Sent Events (ALTO/SSE) <xref t <li>Using ALTO incremental updates using Server-Sent Events (ALTO/SSE) <
arget="RFC8895"/>, xref target="RFC8895"/>;
which is designed for an ALTO client to indicate to the server that it wants this method is designed for an ALTO client to indicate to the server that it wan
to receive updates for a set of resources and the server can then ts
to receive updates for a set of resources, and the server can then
concurrently and incrementally push updates to that client whenever concurrently and incrementally push updates to that client whenever
monitored resources change.</li> monitored resources change.</li>
</ol> </ol>
<!--[rfced] The transition between the text that introduces this list
and the list itself might benefit from being clarified. Are the
bullet points things to consider before using HTTP/2 or HTTP/3?
Original:
Both protocols are designed for HTTP/1.1 [RFC9112], but HTTP/2
[RFC9113] and HTTP/3 [RFC9114] can support HTTP/1.1 workflows.
However, HTTP/2 and HTTP/3 provide features that can improve certain
properties of ALTO and ALTO/SSE.
* First, consider the ALTO base protocol, which is designed to
transfer only complete information resources...
-->
<t>Both protocols are designed for HTTP/1.1 <xref target="RFC9112"/>, but HTTP/2 <xref target="RFC9113"/> and <t>Both protocols are designed for HTTP/1.1 <xref target="RFC9112"/>, but HTTP/2 <xref target="RFC9113"/> and
HTTP/3 <xref target="RFC9114"/> can support HTTP/1.1 workflows. However, HTTP/2 and HTTP/3 HTTP/3 <xref target="RFC9114"/> can support HTTP/1.1 workflows. However, HTTP/2 and HTTP/3
provide features that can improve certain properties of ALTO and ALTO/SSE.</t> provide features that can improve certain properties of ALTO and ALTO/SSE.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>First, consider the ALTO base protocol, which is designed to transfe r only <li>First, consider the ALTO base protocol, which is designed to transfe r only
complete information resources. A client can run the base protocol on top of 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 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 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 b e a large no capability for the server to transmit incremental updates. Hence, there can b e a large
overhead when the client already has an information resource and then there are overhead when the client already has an information resource and then there are
small changes to the resource.</li> small changes to the resource.</li>
<li>Next, consider ALTO/SSE <xref target="RFC8895"/>. Although ALTO/SSE can transfer <li>Next, consider ALTO/SSE <xref target="RFC8895"/>. Although ALTO/SSE can transfer
incremental updates, it introduces a customized multiplexing protocol on top incremental updates, it introduces a customized multiplexing protocol on top
of HTTP, assuming a total-order message channel from the server to the client. 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) The multiplexing design does not provide naming (i.e., a resource identifier)
to individual incremental updates. Such a design cannot use concurrent data to individual incremental updates. Such a design cannot use concurrent data
streams available in HTTP/2 and HTTP/3, because both cases require a resource streams available in HTTP/2 and HTTP/3 because both cases require a resource
identifier. Additionally, ALTO/SSE is a push-only protocol, which denies the identifier. Additionally, ALTO/SSE is a push-only protocol, which denies the
client flexibility in choosing how and when it receives updates.</li> client flexibility in choosing how and when it receives updates.</li>
</ul> </ul>
<t>To mitigate these concerns, this document introduces a new ALTO service called <t>To mitigate these concerns, this document introduces a new ALTO service called
the Transport Information Publication Service (TIPS). TIPS uses an incremental the Transport Information Publication Service (TIPS). TIPS uses an incremental
RESTful design to provide an ALTO client with a new capability to explicitly, RESTful design to provide an ALTO client with a new capability to explicitly,
concurrently issue non-blocking requests for specific incremental updates using concurrently issue non-blocking requests for specific incremental updates using
native HTTP/2 or HTTP/3, while still functioning for HTTP/1.1.</t> native HTTP/2 or HTTP/3, while still functioning for HTTP/1.1.</t>
<t>While ALTO/SSE <xref target="RFC8895"/> and TIPS both can transport inc remental updates of <t>While both ALTO/SSE <xref target="RFC8895"/> and TIPS can transport inc remental updates of
ALTO information resources to clients, they have different design goals. The ALTO information resources to clients, they have different design goals. The
TIPS extension enables more scalable and robust distribution of incremental TIPS extension enables more scalable and robust distribution of incremental
updates, but is missing the session management and built-in server push updates but is missing the session management and built-in server push
capabilities of ALTO/SSE. From the performance perspective, TIPS is optimizing capabilities of ALTO/SSE. From the performance perspective, TIPS is optimizing
throughput by leveraging concurrent and out-of-order transport of data, while 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 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 the clients without waiting for another round of communication when there are
multiple updates. Thus, we do not see TIPS as a replacement but as a complement multiple updates. Thus, we do not see TIPS as a replacement for ALTO/SSE, but as
of ALTO/SSE. One example of combining these two extensions is as shown in a complement
to it. One example of combining these two extensions is shown in
<xref target="tips-sse"/>.</t> <xref target="tips-sse"/>.</t>
<t>Note that future extensions may leverage server push, a feature of HTTP /2 <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 <xref target="RFC9113"/> and HTTP/3 <xref target="RFC9114"/>, as an alternative of SSE. We discuss why
this alternative design is not ready in <xref target="push"/>.</t> this alternative design is not ready at the time of writing in <xref target="pus h"/>.</t>
<t>Specifically, this document specifies:</t> <t>Specifically, this document specifies:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Extensions to the ALTO Protocol for dynamic subscription and efficie nt <li>Extensions to the ALTO Protocol for dynamic subscription and efficie nt
uniform update delivery of an incrementally changing network information uniform update delivery of an incrementally changing network information
resource.</li> resource.</li>
<li>A new resource type that indicates the TIPS updates graph model for a <li>A new resource type that indicates the TIPS updates graph model for a
resource.</li> resource.</li>
<li>URI patterns to fetch the snapshots or incremental updates.</li> <li>URI patterns to fetch the snapshots or incremental updates.</li>
</ul> </ul>
<t>Some operational complexities that must be taken into consideration whe n <t>Some operational complexities that must be taken into consideration whe n
implementing this extension are discussed in <xref target="ops-considerations"/> implementing this extension are discussed in <xref target="ops-considerations"/>
, including : these include
load balancing <xref target="load-balancing"/>, fetching and processing incremen load balancing in <xref target="load-balancing"/> and fetching and processing in
tal updates cremental updates
of dependent resources <xref target="cross-sched"/></t> of dependent resources in <xref target="cross-sched"/>.</t>
<t><xref target="sec-bcp-http"/> discusses to what extent the TIPS design <t><xref target="sec-bcp-http"/> discusses to what extent the TIPS design
adheres to the Best adheres to the best
Current Practices for building protocols with HTTP <xref target="RFC9205"/>.</t> current practices for building protocols with HTTP <xref target="RFC9205"/>.</t>
<section anchor="requirements-language">
<section anchor="requirements-language">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and be interpreted as
only when, they described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="notations"> <section anchor="notations">
<name>Notations</name> <name>Notations</name>
<t>This document uses the same syntax and notations as introduced in <t>This document uses the same syntax and notations as introduced in
<xref section="8.2" sectionFormat="of" target="RFC7285"/> to specify the extensi ons to existing ALTO resources and services.</t> <xref section="8.2" sectionFormat="of" target="RFC7285"/> to specify the extensi ons to existing ALTO resources and services.</t>
</section> </section>
</section> </section>
<section anchor="overview"> <section anchor="overview">
<name>TIPS Overview</name> <name>TIPS Overview</name>
<section anchor="requirements"> <section anchor="requirements">
<name>Transport Requirements</name> <name>Transport Requirements</name>
<t>The ALTO Protocol and its extensions support two transport mechanisms <t>The ALTO Protocol and its extensions support two transport mechanisms
: :</t>
First, a client can directly request an ALTO resource and obtain a complete <ol>
snapshot of that ALTO resource, as specified in the base protocol <xref target=" <li>A client can directly request an ALTO resource and obtain a complete
RFC7285"/>; snapshot of that ALTO resource, as specified in the base protocol <xref target="
Second, a client can subscribe to incremental changes of one or multiple ALTO 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 resources using the incremental update extension <xref target="RFC8895"/>, and a server pushes
the updates to the client through Server Sent Events (SSE).</t> the updates to the client through SSE.</li>
</ol>
<t>However, the current transport mechanisms are not optimized for stori ng, <t>However, the current transport mechanisms are not optimized for stori ng,
transmitting, and processing (incremental) updates of ALTO information transmitting, and processing (incremental) updates of ALTO information
resources. Specifically, the new transport mechanism must satisfy the following resources. Specifically, the new transport mechanism must satisfy the following
requirements:</t> requirements:</t>
<dl> <dl>
<dt>Incremental updates:</dt> <dt>Incremental updates:</dt>
<dd> <dd>
<t>Incremental updates only maintain and transfer the "diff" upon ch anges. Thus, <t>Incremental updates only maintain and transfer the "diff" upon ch anges. Thus,
it is more efficient than storing and transferring the full updates, it is more efficient than storing and transferring the full updates,
especially when the change of an ALTO resource is minor. The base protocol especially when the change of an ALTO resource is minor. The base protocol
does not support incremental updates and the current incremental update does not support incremental updates and the current incremental update
mechanism in <xref target="RFC8895"/> has limitations (as discussed below).</t> mechanism in <xref target="RFC8895"/> has limitations (as discussed below).</t>
</dd> </dd>
<dt>Concurrent, non-blocking update transmission:</dt> <dt>Concurrent, non-blocking update transmission:</dt>
<dd> <dd>
<t>When a client needs to receive and apply multiple incremental upd ates, it is <t>When a client needs to receive and apply multiple incremental upd ates, it is
desired to transmit the updates concurrently to fully utilize the bandwidth desired to transmit the updates concurrently to fully utilize the bandwidth
and to reduce head-of-line blocking. The ALTO incremental update extension and to reduce head-of-line blocking. Unfortunately, the ALTO incremental update
<xref target="RFC8895"/>, unfortunately, does not satisfy this requirement -- ev extension
en though <xref target="RFC8895"/> does not satisfy this requirement. Even though
the updates can be multiplexed by the server to avoid head-of-line blocking the updates can be multiplexed by the server to avoid head-of-line blocking
between multiple resources, the updates are delivered sequentially and can between multiple resources, the updates are delivered sequentially and can
suffer from head-of-line blocking inside the connection, for example, when suffer from head-of-line blocking inside the connection (for example, when
there is a packet loss.</t> there is a packet loss).</t>
</dd> </dd>
<dt>Long-polling updates:</dt> <dt>Long polling updates:</dt>
<dd> <dd>
<t>Long-polling updates can reduce the time to send the request, mak ing it <t>Long polling updates can reduce the time to send the request, mak ing it
possible to achieve sub-RTT transmission of ALTO incremental updates. In possible to achieve sub-RTT transmission of ALTO incremental updates. In
<xref target="RFC8895"/>, this requirement is fulfilled using server-sent event (SSE) and <xref target="RFC8895"/>, this requirement is fulfilled using SSE and
is still desired in the ALTO new transport.</t> is still desired in the ALTO new transport.</t>
</dd> </dd>
<dt>Backward compatibility:</dt> <dt>Backward compatibility:</dt>
<dd> <dd>
<t>While some of the previous requirements are offered by HTTP/2 <xr ef target="RFC9113"/> and <t>While some of the previous requirements are offered by HTTP/2 <xr ef target="RFC9113"/> and
HTTP/3 <xref target="RFC9114"/>, it is desired that the ALTO new transport mecha nism can HTTP/3 <xref target="RFC9114"/>, it is desired that the ALTO new transport mecha nism can
work with HTTP/1.1 as many development tools and current ALTO implementations work with HTTP/1.1 as many development tools and current ALTO implementations
are based on HTTP/1.1.</t> are based on HTTP/1.1.</t>
</dd> </dd>
</dl> </dl>
<t>The ALTO new transport specified in this document satisfies all the d
esign <!--[rfced] We had a few questions about the list that appears at the
end of Section 2.1:
Original:
The ALTO new transport specified in this document satisfies all the
design requirements:
* This document reuses the data format introduced in [RFC8895] that
enables incremental updates using JSON patches or merge patches.
* This document introduce a unified data model to describe the
changes (snapshots and incremental updates) of an ALTO resource,
referred to as a 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.
* 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
request.
* The unified naming convention is independent of the HTTP versions
and can operate atop HTTP/1.1, HTTP/2 or HTTP/3.
This document assumes the deployment model discussed in Appendix A.
a) Please review how the text before the list relates to the list
itself.
b) Please consider making the list more parallel in structure.
Perhaps:
The ALTO new transport specified in this document satisfies all the design requi
rements listed above by:
* Reusing the data format introduced in [RFC8895] that
enables incremental updates using JSON patches or merge patches.
* Introducing a unified data model to describe the
changes (snapshots and incremental updates) of an ALTO resource,
referred to as a "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.
* Basing the unified naming convention 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
request.
* Making the unified naming convention independent of the HTTP versions
and able to operate atop HTTP/1.1, HTTP/2, or HTTP/3.
-->
<t>The ALTO new transport specified in this document satisfies all of th
e following design
requirements:</t> requirements:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>This document reuses the data format introduced in <xref target="R FC8895"/> that enables <li>This document reuses the data format introduced in <xref target="R FC8895"/> that enables
incremental updates using JSON patches or merge patches.</li> incremental updates using JSON patches or merge patches.</li>
<li>This document introduce a unified data model to describe the chang <li>This document introduces a unified data model to describe the chan
es ges
(snapshots and incremental updates) of an ALTO resource, referred to as a TIPS (snapshots and incremental updates) of an ALTO resource, referred to as a "TIPS
view. In the data model, snapshots and incremental updates are indexed as view". In the data model, snapshots and incremental updates are indexed as
individual HTTP resources following a unified naming convention, independent individual HTTP resources following a unified naming convention, independent
of the HTTP version. Thus, these updates can be concurrently requested and be 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 transferred in a non-blocking manner either by using multiple connections or
leveraging multiplexed data transfer offered by HTTP/2 or HTTP/3.</li> by leveraging multiplexed data transfer offered by HTTP/2 or HTTP/3.</li>
<li>The unified naming convention is based on a monotonically increasi ng sequence <li>The unified naming convention is based on a monotonically increasi ng sequence
number, making it possible for a client to construct the URL of a future number, making it possible for a client to construct the URL of a future
update and send a long-polling request.</li> update and send a long polling request.</li>
<li>The unified naming convention is independent of the HTTP versions and can <li>The unified naming convention is independent of the HTTP versions and can
operate atop HTTP/1.1, HTTP/2 or HTTP/3.</li> operate atop HTTP/1.1, HTTP/2, or HTTP/3.</li>
</ul> </ul>
<t>This document assumes the deployment model discussed in <xref target ="sec-dep-model"/>.</t> <t>This document assumes the deployment model discussed in <xref target ="sec-dep-model"/>.</t>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>TIPS Terminology</name> <name>TIPS Terminology</name>
<t>In addition to the terms defined in <xref target="RFC7285"/>, this do cument uses the following terms:</t> <t>In addition to the terms defined in <xref target="RFC7285"/>, this do cument uses the following terms:</t>
<dl> <dl>
<dt>Transport Information Publication Service (TIPS):</dt> <dt>Transport Information Publication Service (TIPS):</dt>
<dd> <dd>
<t>Is a new type of ALTO service, as specified in this document, to enable a <t>A new type of ALTO service, as specified in this document, to ena ble a
uniform transport mechanism for updates of an incrementally changing ALTO uniform transport mechanism for updates of an incrementally changing ALTO
network information resource.</t> network information resource.</t>
</dd> </dd>
<dt>Network information resource:</dt> <dt>Network information resource:</dt>
<dd> <dd>
<t>Is a piece of retrievable information about network state, per <x ref target="RFC7285"/>.</t> <t>A piece of retrievable information about network state, per <xref target="RFC7285"/>.</t>
</dd> </dd>
<dt>TIPS view (tv):</dt> <dt>TIPS view (tv):</dt>
<dd> <dd>
<t>Is defined in this document to be the container of incremental tr ansport <t>The container of incremental transport
information about the network information resource. The TIPS view has one information about the network information resource. The TIPS view has one
basic component, updates graph (ug), but may include other transport basic component, the updates graph (ug), but may include other transport
information.</t> information.</t>
</dd> </dd>
<dt>Updates graph (ug):</dt> <dt>Updates graph (ug):</dt>
<dd> <dd>
<t>Is a directed, acyclic graph whose nodes represent the set of ver <t>A directed, acyclic graph whose nodes represent the set of
sions of an versions of an information resource and whose edges represent the
information resource, and edges the set of update items to compute these set of update items to compute these versions. An ALTO map service
versions. An ALTO map service (e.g., Cost Map, Network Map) may need only a (e.g., a cost map or a network map) may need only a single updates
single updates graph. A dynamic network information service (e.g., Filtered graph. A dynamic network information service (e.g., a filtered
Cost Map) may create an updates graph (within a new TIPS view) for each unique cost map) may create an updates graph (within a new TIPS view) for
request. Encoding of a updates graph is specified in <xref target="open-req"/>.< each unique request. The encoding of an updates graph is specified
/t> in <xref target="open-req"/>.</t>
</dd> </dd>
<dt>Version:</dt> <dt>Version:</dt>
<dd> <dd>
<t>Represents a historical content of an information resource. For a n information <t>The representation of a historical content of an information reso urce. For an information
resource, each version is associated with and uniquely identified by a resource, each version is associated with and uniquely identified by a
monotonically and consecutively increased sequence number. This document uses monotonically and consecutively increased sequence number. This document uses
the term "version s" to refer to the version associated with sequence number the term "version s" to refer to the version associated with sequence number
"s". Version is encoded as a JSONNumber, as specified in <xref target="open-req" />.</t> "s". The version is encoded as a JSONNumber, as specified in <xref target="open- req"/>.</t>
</dd> </dd>
<dt>Start sequence number (start-seq):</dt> <dt>Start sequence number (start-seq):</dt>
<dd> <dd>
<t>Is the smallest non-zero sequence number in an updates graph.</t> <t>The smallest non-zero sequence number in an updates graph.</t>
</dd> </dd>
<dt>End sequence number (end-seq):</dt> <dt>End sequence number (end-seq):</dt>
<dd> <dd>
<t>Is the largest sequence number in an updates graph.</t> <t>The largest sequence number in an updates graph.</t>
</dd> </dd>
<dt>Snapshot:</dt> <dt>Snapshot:</dt>
<dd> <dd>
<t>Is a full replacement of a resource and is contained within an up dates graph.</t> <t>A full replacement of a resource that is contained within an upda tes graph.</t>
</dd> </dd>
<!--[rfced] FYI - We have rephrased the sentence
below. Please review and let us know if these changes alter your
intended meaning.
Original:
An incremental update is mandatory if the source version (i) and
target version (j) are consecutive, i.e., i + 1 = j, and optional or a
shortcut otherwise.
Current:
An incremental update is mandatory if the source version (i) and the
target version (j) are consecutive (i.e., i + 1 = j); otherwise, it is
optional or a shortcut.
-->
<dt>Incremental update:</dt> <dt>Incremental update:</dt>
<dd> <dd>
<t>Is a partial replacement of a resource contained within an update <t>A partial replacement of a resource contained within an
s graph, updates graph, codified in this document as a JSON merge patch or
codified in this document as a JSON Merge Patch or JSON Patch. An incremental a JSON patch. An incremental update is mandatory if the source
update is mandatory if the source version (i) and target version (j) are version (i) and the target version (j) are consecutive (i.e., i + 1
consecutive, i.e., i + 1 = j, and optional or a shortcut otherwise. Mandatory =
incremental updates are always in an updates graph, while optional/shortcut j); otherwise, it is optional or a shortcut. Mandatory incremental
incremental updates may or may not be included in an updates graph.</t> updates are always in an updates graph, while optional/shortcut
incremental updates may or may not be included in an updates
graph.</t>
</dd> </dd>
<dt>Update item:</dt> <dt>Update item:</dt>
<dd> <dd>
<t>Refers to the content on an edge of the updates graph, which can <t>The content on an edge of the updates graph, which can be either
be either a a
snapshot or an incremental update. An update item can be considered as a pair snapshot or an incremental update. An update item can be considered to be a pair
(op, data) where op denotes whether the item is an incremental update or a (op, data) where op denotes whether the item is an incremental update or a
snapshot, and data is the content of the item.</t> snapshot and data is the content of the item.</t>
</dd> </dd>
<dt>ID#i-#j:</dt> <dt>ID#i-#j:</dt>
<dd> <dd>
<t>Denotes the update item on a specific edge in the updates graph t o transition <t>Denotation of the update item on a specific edge in the updates g raph to transition
from version i to version j, where i and j are the sequence numbers of the 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> source node and the target node of the edge, respectively.</t>
</dd> </dd>
</dl> </dl>
<figure anchor="fig-overview"> <figure anchor="fig-overview">
<name>Overview of ALTO TIPS</name> <name>Overview of ALTO TIPS</name>
<artwork type="drawing" align="center"><![CDATA[ <artwork type="drawing" align="center"><![CDATA[
+-------------+ +-------------+
+-----------+ +--------------+ | Dynamic | +-----------+ +-----------+ +--------------+ | Dynamic | +-----------+
| Routing | | Provisioning | | Network | | External | | Routing | | Provisioning | | Network | | External |
skipping to change at line 381 skipping to change at line 543
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| Client 1 | | Client 2 | | Client 3 | | Client 1 | | Client 2 | | Client 3 |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
tvi = TIPS view i tvi = TIPS view i
tvi/ug = incremental updates graph associated with tvi tvi/ug = incremental updates graph associated with tvi
]]></artwork> ]]></artwork>
</figure> </figure>
<t><xref target="fig-overview"/> shows an example illustrating an overvi ew of the ALTO TIPS <t><xref target="fig-overview"/> shows an example illustrating an overvi ew of the ALTO TIPS
service. The server provides the TIPS service of two information resources (#1 service. The server provides the TIPS service of two information resources (#1
and #2) where #1 is an ALTO map service, and #2 is a filterable and #2) where #1 is an ALTO map service and #2 is a filterable
service. There are 3 ALTO clients (Client 1, Client 2, and Client 3) that are service. There are three ALTO clients (Client 1, Client 2, and Client 3) that ar
e
connected to the ALTO server.</t> connected to the ALTO server.</t>
<t>Each client uses the TIPS view to retrieve updates. Specifically, a T IPS view <t>Each client uses the TIPS view to retrieve updates. Specifically, a T IPS view
(tv1) is created for the map service #1, and is shared by multiple clients. For (tv1) is created for the map service #1 and is shared by multiple clients. For
the filtering service #2, two different TIPS views (tv2 and tv3) are created upo n the filtering service #2, two different TIPS views (tv2 and tv3) are created upo n
different client requests with different filter sets.</t> different client requests with different filter sets.</t>
</section> </section>
</section> </section>
<section anchor="tips-updates-graph"> <section anchor="tips-updates-graph">
<name>TIPS Updates Graph</name> <name>TIPS Updates Graph</name>
<t>In order to provide incremental updates for a resource, an ALTO server creates <t>In order to provide incremental updates for a resource, an ALTO server creates
an updates graph, which is a directed, acyclic graph that contains a sequence of an updates graph, which is a directed acyclic graph that contains a sequence of
incremental updates and snapshots (collectively called update items) of a incremental updates and snapshots (collectively called "update items") of a
network information resource.</t> network information resource.</t>
<section anchor="data-model"> <section anchor="data-model">
<name>Basic Data Model of Updates Graph</name> <name>Basic Data Model of an Updates Graph</name>
<t>For each resource (e.g., a cost map, a network map), the incremental <t>For each resource (e.g., a cost map or a network map), the incrementa
updates and l updates and
snapshots can be represented using the following directed acyclic graph model, 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 ar e where the server tracks the change of the resource maps with version IDs that ar e
assigned sequentially (i.e., incremented by 1 each time):</t> assigned sequentially (i.e., incremented by one each time):</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Each node in the graph is a version of the resource, which is iden tified by a <li>Each node in the graph is a version of the resource, which is iden tified by a
sequence number (defined as a JSONNumber). Version 0 is reserved as the sequence number (defined as a JSONNumber). Version 0 is reserved as the
initial state (empty/null).</li> initial state (empty/null).</li>
<li>A tag identifies the content of a node. A tag has the same format as the <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 "tag" field in <xref section="10.3" sectionFormat="of" target="RFC7285"/> and is valid only within the
scope of resource.</li> scope of the resource.</li>
<!--[rfced] How may we rephrase the sentence below?
Specifically, how may we replace the "/" character with a more
descriptive conjunction?
In addition, please review usage of the "/" character throughout. We
recommend reviewing these instances and updating with "and", "or", or
"and/or" for ease of the reader, if necessary.
Original:
* Version is path-independent (different paths arrive at the same
version/node has the same content)
Perhaps:
* The version is path independent (i.e., different paths arriving
at the same version or node have the same content)
-->
<li>Each edge is an update item. In particular, the edge from i to j i s the update <li>Each edge is an update item. In particular, the edge from i to j i s the update
item to transit from version i to version j.</li> item to transit from version i to version j.</li>
<li>Version is path-independent (different paths arrive at the same ve <li>The version is path independent (different paths arrive at the sam
rsion/node e version/node
has the same content)</li> has the same content).</li>
</ul> </ul>
<t>A concrete example is shown in <xref target="fig-ug"/>. There are 7 n
odes in the graph, <!--[rfced] For ease of the reader, we would like to update the text
representing 7 different versions of the resource. Edges in the figure represent below to read as a bulleted list. Please review and let us know
if these changes would alter your intended meaning.
Original:
The target version 105 can either be directly fetched as a snapshot,
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 incrementally by taking the "shortcut" path from 103
to 105.
Perhaps:
The target version 105 can be:
* directly fetched as a snapshot;
* computed incrementally by applying the incremental updates between
103 and 104, then 104 and 105; or,
* computed incrementally by taking the "shortcut" path from 103 to
105 if the optional update from 103 to 105 exists.
-->
<t>A concrete example is shown in <xref target="fig-ug"/>. There are sev
en nodes in the graph,
representing seven different versions of the resource. Edges in the figure repre
sent
the updates from the source version to the target version. Thick lines 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 mandatory incremental updates (e.g., ID103-104), dotted lines represent optional
incremental updates (e.g., ID103-105), and thin lines represent snapshots (e.g., 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 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, 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 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 version of the client is 103 as it serves as a base upon which incremental
updates can be applied. The target version 105 can either be directly fetched as updates can be applied. The target version 105 can either be directly fetched as
a snapshot, computed incrementally by applying the incremental updates between a snapshot, 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, 103 and 104 (then 104 and 105), or, if the optional update from 103 to 105 exist s,
computed incrementally by taking the "shortcut" path from 103 to 105.</t> computed incrementally by taking the "shortcut" path from 103 to 105.</t>
<figure anchor="fig-ug"> <figure anchor="fig-ug">
<name>TIPS Model Example</name> <name>TIPS Model Example</name>
<artwork type="drawing" align="center"><![CDATA[ <artwork type="drawing" align="center"><![CDATA[
+======+ +======+
------| 0 | ------| 0 |
/ +======+ / +======+
ID0-101 / | | ID0-101 / | |
|/__ | | |/__ | |
+======+ | | +======+ | |
tag: 3421097 -> | 101 | | | tag: 3421097 -> | 101 | | |
+======+ | | +======+ | |
ID101-102 || | | ID101-102 || | |
\/ | | \/ | |
+======+ | | +======+ | |
tag: 6431234 -> | 102 | | | tag: 6431234 -> | 102 | | |
+======+ | | +======+ | |
ID102-103 || | | ID102-103 || | |
\/ | | \/ | |
+======+ / | +======+ / |
+--------------+ tag: 0881080 -> | 103 |<--------/ | +--------------+ tag: 0881080 -> | 103 |<--------/ |
| Base Version | =======> +======+ ID0-103 | | Base Version | =======> +======+ ID0-103 |
+--------------+ 103-104 || .. | +--------------+ 103-104 || .. |
\/ .. | \/ .. |
+======+ .. | +======+ .. |
tag: 6452654 -> | 104 | .. ID103 | tag: 6452654 -> | 104 | .. ID103 |
+======+ .. -105 | +======+ .. -105 |
ID104-105 || .. | ID0-105 ID104-105 || .. | ID0-105
\/ |._ / \/ |._ /
+======+ / +======+ /
tag: 7838392 -> | 105 |<-----------/ tag: 7838392 -> | 105 |<-----------/
+======+ +======+
ID105-106 || ID105-106 ||
\/ \/
+======+ +======+
tag: 6470983 -> | 106 | tag: 6470983 -> | 106 |
+======+ +======+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="updates-graph-modification-invariants"> <section anchor="updates-graph-modification-invariants">
<name>Updates Graph Modification Invariants</name> <name>Updates Graph Modification Invariants</name>
<t>A server may change its updates graph (to compact, to add nodes, <t>A server may change its updates graph (to compact it, to add nodes,
etc.), but it must ensure that any resource state that it makes etc.), but it must ensure that any resource state that it makes
available is reachable by clients, either directly via a snapshot available is reachable by clients, either directly via a snapshot
(that is, relative to 0) or indirectly by requesting an earlier (that is, relative to 0) or indirectly by requesting an earlier
snapshot and a contiguous set of incremental updates. Additionally, snapshot and a contiguous set of incremental updates. Additionally,
to allow clients to proactively construct URIs for future update to allow clients to proactively construct URIs for future update
items, the ID of each added node in the updates graph must increment items, the ID of each added node in the updates graph must increment
contiguously by 1. More specifically, the updates graph <bcp14>MUST</bcp14> sat isfy contiguously by 1. More specifically, the updates graph <bcp14>MUST</bcp14> sat isfy
the following invariants:</t> the following invariants:</t>
<ul spacing="normal"> <dl spacing="normal">
<li>Continuity: At any time, let ns denote the smallest non-zero versi <dt>Continuity:</dt><dd>At any time, let ns denote the smallest non-ze
on (i.e., ro version (i.e.,
start-seq) in the update graph and ne denote the latest version (i.e., start-seq) in the updates graph and let ne denote the latest version (i.e.,
end-seq). Then any version in between ns and ne <bcp14>MUST</bcp14> also exist. end-seq). Then, any version in between ns and ne <bcp14>MUST</bcp14> also exist.
This implies
<!--[rfced] Please review our update to the following text to remedy
a switch between singular and plural. If our change does not
correctly capture your intent, please let us know how we may
rephrase.
Original:
This implies that the incremental update from ni to ni + 1 exists for
any ns <= ni <= ne, and all versions in the update graph (except 0) is
an integer interval [ns, ne].
Current:
This implies that the incremental update from ni to ni + 1 exists for
any ns <= ni <= ne, and each version in the updates graph (except 0)
is an integer interval [ns, ne].
-->
This implies
that the incremental update from ni to ni + 1 exists for any ns &lt;= ni &lt;= n e, that the incremental update from ni to ni + 1 exists for any ns &lt;= ni &lt;= n e,
and all versions in the update graph (except 0) is an integer interval and each version in the updates graph (except 0) is an integer interval
<tt>[ns, ne]</tt>.</li> <tt>[ns, ne]</tt>.</dd>
<li>Feasibility: Let ns denote the start-seq in the update graph. The <dt>Feasibility:</dt><dd>Let ns denote the start-seq in the updates gr
server <bcp14>MUST</bcp14> aph. The server <bcp14>MUST</bcp14>
provide a snapshot of ns and, in other words, there is always a direct link provide a snapshot of ns; in other words, there is always a direct link
to ns in the update graph.</li> to ns in the updates graph.</dd>
<li>"Right shift" only: Assume a server provides versions in <tt>[n1, <dt>"Right shift" only:</dt><dd>Assume a server provides versions in <
n2]</tt> at time t tt>[n1, n2]</tt> at time t
and versions in <tt>[n1', n2']</tt> at time t'. If t' &gt; t, then n1' &gt;= n1 and n2' &gt;= and versions in <tt>[n1', n2']</tt> at time t'. If t' &gt; t, then n1' &gt;= n1 and n2' &gt;=
n2.</li> n2.</dd>
</ul> </dl>
<t>For example, consider the case that a server compacts a resource's up dates graph <t>For example, consider the case that a server compacts a resource's up dates graph
to conserve space, using the example model in <xref target="data-model"/>. Assum e at time 0, to conserve space, using the example model in <xref target="data-model"/>. Assum e at time 0,
the server provides the versions <tt>{101, 102, 103, 104, 105, 106}</tt>. At tim e 1, the server provides the versions <tt>{101, 102, 103, 104, 105, 106}</tt>. At ti me 1,
both <tt>{103, 104, 105, 106}</tt> and <tt>{105, 106}</tt> are valid sets. Howev er, <tt>{102, both <tt>{103, 104, 105, 106}</tt> and <tt>{105, 106}</tt> are valid sets. Howev er, <tt>{102,
103, 104, 105, 106}</tt> and <tt>{104, 105, 106}</tt> are not valid sets as ther e is no 103, 104, 105, 106}</tt> and <tt>{104, 105, 106}</tt> are not valid sets as ther e is no
snapshot to version 102 or 104 in the update graph. Thus, there is a risk that snapshot to version 102 or 104 in the updates graph. Thus, there is a risk that
the right content of version 102 (in the first example) or 104 (in the second 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 example) cannot be obtained by a client that does not have the previous version
101 or 103, respectively.</t> 101 or 103, respectively.</t>
</section> </section>
</section> </section>
<section anchor="workflow"> <section anchor="workflow">
<name>TIPS Workflow and Resource Location Schema</name> <name>TIPS Workflow and Resource Location Schema</name>
<section anchor="workflow-overview"> <section anchor="workflow-overview">
<name>Workflow</name> <name>Workflow</name>
<t>At a high level, an ALTO client first uses the TIPS service (denoted <t>At a high level, an ALTO client first uses the TIPS service (denoted
as TIPS-F as TIPS-F,
and F is for frontend) to indicate the information resource(s) that the client where F is for frontend) to indicate the information resource or resources that
the client
wants to monitor. For each requested resource, the server returns a JSON object 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 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 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 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 incremen tal updates.</t> view, clients can construct URIs (see <xref target="schema"/>) to fetch incremen tal updates.</t>
<t>An example workflow is shown in <xref target="fig-workflow-pull"/>. A fter the TIPS-F <t>An example workflow is shown in <xref target="fig-workflow-pull"/>. A fter the TIPS-F
service receives the request from the client to monitor the updates of an ALTO service receives the request from the client to monitor the updates of an ALTO
resource, it creates a TIPS view service and returns the corresponding resource, it creates a TIPS view service and returns the corresponding
information to the client. The URI points to that specific TIPS-V instance and information to the client. The URI points to that specific TIPS-V instance, and
the summary contains the start-seq and end-seq of the update graph, and a the summary contains the start-seq and end-seq of the updates graph and a
server-recommended edge to consume first, e.g., from i to j.</t> server-recommended edge to consume first (e.g., from i to j).</t>
<t>An ALTO client can then continuously pull each additional update with the <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 information. For example, the client in <xref target="fig-workflow-pull"/> first fetches the
update from i to j, and then from j to j+1. Note that the update item at update from i to 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 not yet exist, so th e server holds the <tt>&lt;tips-view-uri&gt;/ug/&lt;j&gt;/&lt;j+1&gt;</tt> may not yet exist, so th e server holds the
request until the update becomes available (long polling).</t> request until the update becomes available (i.e., long polling).</t>
<t>A server <bcp14>MAY</bcp14> close a TIPS view at any time, e.g., unde <t>A server <bcp14>MAY</bcp14> close a TIPS view at any time (e.g., unde
r high system load or due r high system load or due
to client inactivity. In the event that a TIPS view is closed, an edge request to client inactivity). In the event that a TIPS view is closed, an edge request
will receive error code 404 in response, and the client will have to request a will receive error code 404 (Not Found) in response, and the client will have to
request a
new TIPS view URI.</t> new TIPS view URI.</t>
<t>If resources allow, a server <bcp14>SHOULD</bcp14> avoid closing TIPS views that have active <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 polling edge requests or have recently served responses until clients have had a
reasonable interval to request the next update, unless guided by specific reasonable interval to request the next update, unless guided by specific
control policies.</t> control policies.</t>
<figure anchor="fig-workflow-pull"> <figure anchor="fig-workflow-pull">
<name>ALTO TIPS Workflow Supporting Client Pull</name> <name>ALTO TIPS Workflow Supporting Client Pull</name>
<artwork type="drawing" align="center"><![CDATA[ <artwork type="drawing" align="center"><![CDATA[
Client TIPS-F TIPS-V Client TIPS-F TIPS-V
o . . o . .
skipping to change at line 563 skipping to change at line 789
| <------------------------------------------------------| | <------------------------------------------------------|
| . | .
o . o .
. .
TIPS View Closed o TIPS View Closed o
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="schema"> <section anchor="schema">
<name>Resource Location Schema</name> <name>Resource Location Schema</name>
<t>The resource location schema defines how a client constructs URI to f etch <t>The resource location schema defines how a client constructs URIs to fetch
incremental updates.</t> incremental updates.</t>
<t>To access each update in an updates graph, consider the model <t>To access each update in an updates graph, consider the model
represented as a "virtual" file system (adjacency list), contained within the 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 ti ps-view-uri). root of a TIPS view URI (see <xref target="open-resp"/> for the definition of ti ps-view-uri).
For example, assuming that the update graph of a TIPS view is as shown in For example, assuming that the updates graph of a TIPS view is as shown in
<xref target="fig-ug"/>, the location schema of this TIPS view will have the for mat as in <xref target="fig-ug"/>, the location schema of this TIPS view will have the for mat as in
<xref target="fig-ug-schema"/>.</t> <xref target="fig-ug-schema"/>.</t>
<figure anchor="fig-ug-schema"> <figure anchor="fig-ug-schema">
<name>Location Schema Example</name> <name>Location Schema Example</name>
<artwork type="drawing" align="center"><![CDATA[ <artwork type="drawing" align="center"><![CDATA[
<tips-view-path> // root path to a TIPS view <tips-view-path> // root path to a TIPS view
|_ ug // updates graph |_ ug // updates graph
| |_ 0 | |_ 0
| | |_ 101 // full 101 snapshot | | |_ 101 // full 101 snapshot
| | |_ 103 | | |_ 103
skipping to change at line 594 skipping to change at line 820
| |_ 103 | |_ 103
| | |_ 104 | | |_ 104
| | \_ 105 // optional shortcut 103 -> 105 incr. update | | \_ 105 // optional shortcut 103 -> 105 incr. update
| |_ 104 | |_ 104
| | \_ 105 | | \_ 105
| \_ 105 | \_ 105
| \_ 106 | \_ 106
\_ ... \_ ...
]]></artwork> ]]></artwork>
</figure> </figure>
<t>TIPS uses this directory schema to generate template URIs which allow <t>TIPS uses this directory schema to generate template URIs that allow
clients to construct the location of incremental updates after receiving the 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 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> 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> <tips-view-uri>/ug/<i>/<j>
]]></artwork> ]]></sourcecode>
<t>Due to the sequential nature of the update item IDs, a client can lon g poll a <t>Due to the sequential nature of the update item IDs, a client can lon g poll a
future update that does not yet exist (e.g., the incremental update from 106 to future update that does not yet exist (e.g., the incremental update from 106 to
107) by constructing the URI for the next edge that will be added, starting from 107). This can be done by constructing the URI for the next edge that will be ad ded, starting from
the sequence number of the current last node (denoted as end-seq) in the graph the sequence number of the current last node (denoted as end-seq) in the graph
to the next sequential node (with the sequence number of end-seq + 1):</t> to the next sequential node (with the sequence number of end-seq + 1):</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
<tips-view-uri>/ug/<end-seq>/<end-seq + 1> <tips-view-uri>/ug/<end-seq>/<end-seq + 1>
]]></artwork> ]]></sourcecode>
<t>Incremental updates of a TIPS view are read-only. Thus, they are fetc hed using <t>Incremental updates of a TIPS view are read-only. Thus, they are fetc hed using
the HTTP GET method.</t> the HTTP GET method.</t>
</section> </section>
</section> </section>
<section anchor="ird"> <section anchor="ird">
<name>TIPS Information Resource Directory (IRD) Announcement</name> <name>TIPS Information Resource Directory (IRD) Announcement</name>
<t>To announce a TIPS information resource in the information resource dir <t>To announce a TIPS information resource in the IRD, an ALTO server <bcp
ectory 14>MUST</bcp14> specify "media-type", "capabilities", and "uses"
(IRD), an ALTO server <bcp14>MUST</bcp14> specify the "media-type", "capabilitie
s" and "uses"
as follows.</t> as follows.</t>
<section anchor="media-type"> <section anchor="media-type">
<name>Media Type</name> <name>Media Type</name>
<t>The media type of the Transport Information Publication Service resou rce is <t>The media type of the Transport Information Publication Service (TIPS ) resource is
"application/alto-tips+json".</t> "application/alto-tips+json".</t>
</section> </section>
<section anchor="caps"> <section anchor="caps">
<name>Capabilities</name> <name>Capabilities</name>
<t>The capabilities field of TIPS is modeled on that defined in <t>The "capabilities" field of TIPS is modeled on that defined in
Section 6.3 of <xref target="RFC8895"/>.</t> <xref target="RFC8895" sectionFormat="of" section="6.3"/>.</t>
<t>Specifically, the capabilities are defined as an object of type <t>Specifically, the capabilities are defined as an object of the TIPSCa
TIPSCapabilities:</t> pabilities type:</t>
<figure anchor="tips-cap"> <figure anchor="tips-cap">
<name>TIPSCapabilities</name> <name>TIPSCapabilities</name>
<artwork align="left"><![CDATA[ <sourcecode type="json"><![CDATA[
object { object {
IncrementalUpdateMediaTypes incremental-change-media-types; IncrementalUpdateMediaTypes incremental-change-media-types;
} TIPSCapabilities; } TIPSCapabilities;
object-map { object-map {
ResourceID -> String; ResourceID -> String;
} IncrementalUpdateMediaTypes; } IncrementalUpdateMediaTypes;
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>with field:</t> <t>With the field:</t>
<dl> <dl>
<dt>incremental-change-media-types:</dt> <dt>incremental-change-media-types:</dt>
<dd> <dd>
<t>If a TIPS can provide updates with incremental changes for a <t>If a TIPS can provide updates with incremental changes for a
resource, the "incremental-change-media-types" field has an entry resource, the "incremental-change-media-types" field has an entry
for that resource-id, and the value is the supported media types for that resource-id, and the value is the supported media types
of incremental changes, separated by commas. For the implementation of this of incremental changes, separated by commas. For the implementation of this
specification, this <bcp14>MUST</bcp14> be "application/merge-patch+json", specification, this <bcp14>MUST</bcp14> be "application/merge-patch+json",
"application/json-patch+json", or "application/json-patch+json", or
"application/merge-patch+json,application/json-patch+json", unless defined by "application/merge-patch+json,application/json-patch+json", unless defined by
a future extension. a future extension.
</t> </t>
<t>When choosing the media types to encode incremental updates for a <t>When choosing the media types to encode incremental updates for a
resource, the server <bcp14>MUST</bcp14> consider the limitations of the resource, the server <bcp14>MUST</bcp14> consider the limitations of the
encoding. For example, when a JSON merge patch specifies that 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 value of a field is null, its semantics are that the field is
removed from the target and hence the field is no longer defined removed from the target; hence, the field is no longer defined
(i.e., undefined). This, however, may not be the intended result (i.e., undefined). However, this may not be the intended result
for the resource, when null and undefined have different semantics for the resource, when null and undefined have different semantics
for the resource. In such a case, the server <bcp14>MUST</bcp14> choose JSON for the resource. In such a case, the server <bcp14>MUST</bcp14> choose a JSON
patch over JSON merge patch if JSON patch is indicated as a patch over a JSON merge patch if the JSON patch is indicated as a
capability of the TIPS. If the server does not support JSON patch capability of the TIPS. If the server does not support a JSON patch
to handle such a case, the server then needs to send a full to handle such a case, the server then needs to send a full
replacement.</t> replacement.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="uses"> <section anchor="uses">
<name>Uses</name> <name>Uses</name>
<t>The "uses" attribute <bcp14>MUST</bcp14> be an array with the resourc e-ids of every <t>The "uses" attribute <bcp14>MUST</bcp14> be an array with the resourc e-ids of every
network information resource for which this TIPS can provide service.</t> network information resource for which this TIPS can provide service.</t>
<t>This set <bcp14>MAY</bcp14> be any subset of the ALTO server's networ k information resources <t>This set <bcp14>MAY</bcp14> be any subset of the ALTO server's networ k information resources
and <bcp14>MAY</bcp14> include resources defined in linked IRDs. However, it is <bcp14>RECOMMENDED</bcp14> 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 that the ALTO server selects a set that is closed under the resource dependency
relationship. That is, if a TIPS' "uses" set includes resource R1 and resource relationship. That is, if a TIPS' "uses" set includes resource R1, and resource
R1 depends on ("uses") resource R0, then the TIPS' "uses" set should include R0 R1 depends on ("uses") resource R0, then the TIPS' "uses" set should include R0
as well as R1. For example, if a TIPS provides a TIPS view for a cost map, it as well as R1. For example, if a TIPS provides a TIPS view for a cost map, it
should also provide a TIPS view for the network map upon which that cost map should also provide a TIPS view for the network map upon which that cost map
depends.</t> depends.</t>
<t>If the set is not closed, at least one resource R1 in the "uses" fiel d of a TIPS <t>If the set is not closed, at least one resource R1 in the "uses" fiel d of a TIPS
depends on another resource R0 which is not in the "uses" field of the same depends on another resource R0 that is not in the "uses" field of the same
TIPS. Thus, a client cannot receive incremental updates for R0 from the same TIPS. Thus, a client cannot receive incremental updates for R0 from the same
TIPS service. If the client observes in an update of R1 that the version tag for TIPS service. 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 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> less efficient than receiving the incremental updates of R0.</t>
</section> </section>
<section anchor="an-example"> <section anchor="an-example">
<name>An Example</name> <name>An Example</name>
<t>Extending the IRD example in Section 8.1 of <xref target="RFC8895"/>, <t>Extending the IRD example in <xref target="RFC8895" sectionFormat="of
<xref target="ex-ird"/> is the IRD of an " section="8.1"/>, <xref target="ex-ird"/> is the IRD of an
ALTO server supporting ALTO base protocol, ALTO/SSE, and ALTO TIPS.</t> ALTO server supporting the ALTO base protocol, ALTO/SSE, and ALTO TIPS.</t>
<figure anchor="ex-ird"> <figure anchor="ex-ird">
<name>Example of an ALTO Server Supporting ALTO Base Protocol, ALTO/SS <name>Example of an ALTO Server Supporting the ALTO Base Protocol, ALT
E, and ALTO TIPS</name> O/SSE, and ALTO TIPS</name>
<artwork align="left"><![CDATA[
"my-network-map": { <!--[rfced] Please note that we have removed whitespace from the left
"uri": "https://alto.example.com/networkmap", of two pieces of sourcecode (Figures 6 and 11) in the document to
"media-type": "application/alto-networkmap+json" keep the text within our 72 character limit. Please let us know
}, any objections. -->
"my-routingcost-map": {
"uri": "https://alto.example.com/costmap/routingcost", <sourcecode type="json"><![CDATA[
"media-type": "application/alto-costmap+json", "my-network-map": {
"uses": ["my-network-map"], "uri": "https://alto.example.com/networkmap",
"capabilities": { "media-type": "application/alto-networkmap+json"
"cost-type-names": ["num-routingcost"] },
} "my-routingcost-map": {
}, "uri": "https://alto.example.com/costmap/routingcost",
"my-hopcount-map": { "media-type": "application/alto-costmap+json",
"uri": "https://alto.example.com/costmap/hopcount", "uses": ["my-network-map"],
"media-type": "application/alto-costmap+json", "capabilities": {
"uses": ["my-network-map"], "cost-type-names": ["num-routingcost"]
"capabilities": { }
"cost-type-names": ["num-hopcount"] },
} "my-hopcount-map": {
}, "uri": "https://alto.example.com/costmap/hopcount",
"my-simple-filtered-cost-map": { "media-type": "application/alto-costmap+json",
"uri": "https://alto.example.com/costmap/filtered/simple", "uses": ["my-network-map"],
"media-type": "application/alto-costmap+json", "capabilities": {
"accepts": "application/alto-costmapfilter+json", "cost-type-names": ["num-hopcount"]
"uses": ["my-network-map"], }
"capabilities": { },
"cost-type-names": ["num-routingcost", "num-hopcount"], "my-simple-filtered-cost-map": {
"cost-constraints": false "uri": "https://alto.example.com/costmap/filtered/simple",
} "media-type": "application/alto-costmap+json",
}, "accepts": "application/alto-costmapfilter+json",
"update-my-costs": { "uses": ["my-network-map"],
"uri": "https://alto.example.com/updates/costs", "capabilities": {
"media-type": "text/event-stream", "cost-type-names": ["num-routingcost", "num-hopcount"],
"accepts": "application/alto-updatestreamparams+json", "cost-constraints": false
"uses": [ }
"my-network-map", },
"my-routingcost-map", "update-my-costs": {
"my-hopcount-map", "uri": "https://alto.example.com/updates/costs",
"my-simple-filtered-cost-map" "media-type": "text/event-stream",
], "accepts": "application/alto-updatestreamparams+json",
"capabilities": { "uses": [
"incremental-change-media-types": { "my-network-map",
"my-network-map": "application/json-patch+json", "my-routingcost-map",
"my-routingcost-map": "application/merge-patch+json", "my-hopcount-map",
"my-hopcount-map": "application/merge-patch+json" "my-simple-filtered-cost-map"
}, ],
"support-stream-control": true "capabilities": {
} "incremental-change-media-types": {
}, "my-network-map": "application/json-patch+json",
"update-my-costs-tips": { "my-routingcost-map": "application/merge-patch+json",
"uri": "https://alto.example.com/updates-new/costs", "my-hopcount-map": "application/merge-patch+json"
"media-type": "application/alto-tips+json", },
"accepts": "application/alto-tipsparams+json", "support-stream-control": true
"uses": [ }
"my-network-map", },
"my-routingcost-map", "update-my-costs-tips": {
"my-hopcount-map", "uri": "https://alto.example.com/updates-new/costs",
"my-simple-filtered-cost-map" "media-type": "application/alto-tips+json",
], "accepts": "application/alto-tipsparams+json",
"capabilities": { "uses": [
"incremental-change-media-types": { "my-network-map",
"my-network-map": "application/json-patch+json", "my-routingcost-map",
"my-routingcost-map": "application/merge-patch+json", "my-hopcount-map",
"my-hopcount-map": "application/merge-patch+json", "my-simple-filtered-cost-map"
"my-simple-filtered-cost-map": "application/merge-patch+json" ],
} "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", "tips-sse": {
"media-type": "text/event-stream", "uri": "https://alto.example.com/updates/tips",
"accepts": "application/alto-updatestreamparams+json", "media-type": "text/event-stream",
"uses": [ "update-my-costs-tips" ], "accepts": "application/alto-updatestreamparams+json",
"capabilities": { "uses": [ "update-my-costs-tips" ],
"incremental-change-media-types": { "capabilities": {
"update-my-costs-tips": "application/merge-patch+json" "incremental-change-media-types": {
} "update-my-costs-tips": "application/merge-patch+json"
} }
} }
]]></artwork> }
]]></sourcecode>
</figure> </figure>
<t>Note that it is straightforward for an ALTO server to run HTTP/2 and <t>Note that it is straightforward for an ALTO server to run HTTP/2 and
support concurrent retrieval of multiple resources such as "my- support concurrent retrieval of multiple resources such as "my-network-map" and
network-map" and "my-routingcost-map" using multiple HTTP/2 streams.</t> "my-routingcost-map" using multiple HTTP/2 streams.</t>
<t>The resource "update-my-costs-tips" provides an ALTO TIPS service, an d this is <t>The resource "update-my-costs-tips" provides an ALTO TIPS service, an d this is
indicated by the media-type "application/alto-tips+json".</t> indicated by the media-type "application/alto-tips+json".</t>
</section> </section>
</section> </section>
<section anchor="tips-management"> <section anchor="tips-management">
<name>TIPS Management</name> <name>TIPS Management</name>
<t>Upon request, a server sends a TIPS view to a client. This TIPS view ma y be <t>Upon request, a server sends a TIPS view to a client. This TIPS view ma y be
created at the time of the request or may already exist (either because another created at the time of the request or may already exist (either because another
client has already created a TIPS view for the same requested network resource 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 or because the server perpetually maintains a TIPS view for an often-requested
resource).</t> resource).</t>
<section anchor="open-req"> <section anchor="open-req">
<name>Open Request</name> <name>Open Request</name>
<t>An ALTO client requests that the server provide a TIPS view for a giv en resource <t>An ALTO client requests that the server provide a TIPS view for a giv en resource
by sending an HTTP POST body with the media type by sending an HTTP POST body with the media type
"application/alto-tipsparams+json". That body contains a JSON object of type "application/alto-tipsparams+json". That body contains a JSON object of the TIPS
TIPSReq, where:</t> Req type, where:</t>
<figure anchor="fig-open-req"> <figure anchor="fig-open-req">
<name>TIPSReq</name> <name>TIPSReq</name>
<artwork align="left"><![CDATA[ <sourcecode type="json"><![CDATA[
object { object {
ResourceID resource-id; ResourceID resource-id;
[JSONString tag;] [JSONString tag;]
[Object input;] [Object input;]
} TIPSReq; } TIPSReq;
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>with the following fields:</t> <t>With the following fields:</t>
<dl> <dl>
<dt>resource-id:</dt> <dt>resource-id:</dt>
<dd> <dd>
<t>The resource-id of an ALTO resource and <bcp14>MUST</bcp14> be in the TIPS' "uses" list <t>The resource-id of an ALTO resource <bcp14>MUST</bcp14> be in the TIPS' "uses" list
(<xref target="ird"/>). If a client does not support all incremental methods fro m the set (<xref target="ird"/>). If a client does not support all incremental methods fro m the set
announced in the server's capabilities, the client <bcp14>MUST NOT</bcp14> use t he TIPS announced in the server's capabilities, the client <bcp14>MUST NOT</bcp14> use t he TIPS
service.</t> service.</t>
</dd> </dd>
<dt>tag:</dt> <dt>tag:</dt>
<dd> <dd>
<t>If the resource-id is a GET-mode resource with a version tag (or <t>If the resource-id is a GET-mode resource with a version tag (or
"vtag"), as defined in Section 10.3 of <xref target="RFC7285"/>, and the ALTO "vtag"), as defined in <xref target="RFC7285" sectionFormat="of" section="10.3"/ >, and the ALTO
client has previously retrieved a version of that resource from 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 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 ta g the client's version of that resource. The server <bcp14>MAY</bcp14> use the ta g
when calculating a recommended starting edge for the client to when calculating a recommended starting edge for the client to
consume. Note that the client <bcp14>MUST</bcp14> support all incremental consume. Note that the client <bcp14>MUST</bcp14> support all incremental
methods from the set announced in the server's capabilities for methods from the set announced in the server's capabilities for
this resource.</t> this resource.</t>
</dd> </dd>
<dt>input:</dt> <dt>input:</dt>
<dd> <dd>
<t>If the resource is a POST-mode service that requires input, the <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 ALTO client <bcp14>MUST</bcp14> set the "input" field to a JSON object with the
parameters that the resource expects.</t> parameters that the resource expects.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="open-resp"> <section anchor="open-resp">
<name>Open Response</name> <name>Open Response</name>
<t>The response to a valid request <bcp14>MUST</bcp14> be a JSON object <t>The response to a valid request <bcp14>MUST</bcp14> be a JSON object
of type of the AddTIPSResponse type, denoted as media type "application/alto-tips+json":
AddTIPSResponse, denoted as media type "application/alto-tips+json":</t> </t>
<figure anchor="fig-open-resp"> <figure anchor="fig-open-resp">
<name>AddTIPSResponse</name> <name>AddTIPSResponse</name>
<artwork align="left"><![CDATA[ <sourcecode type="json"><![CDATA[
object { object {
URI tips-view-uri; URI tips-view-uri;
TIPSViewSummary tips-view-summary; TIPSViewSummary tips-view-summary;
} AddTIPSResponse; } AddTIPSResponse;
object { object {
UpdatesGraphSummary updates-graph-summary; UpdatesGraphSummary updates-graph-summary;
} TIPSViewSummary; } TIPSViewSummary;
object { object {
JSONNumber start-seq; JSONNumber start-seq;
JSONNumber end-seq; JSONNumber end-seq;
StartEdgeRec start-edge-rec; StartEdgeRec start-edge-rec;
} UpdatesGraphSummary; } UpdatesGraphSummary;
object { object {
JSONNumber seq-i; JSONNumber seq-i;
JSONNumber seq-j; JSONNumber seq-j;
} StartEdgeRec; } StartEdgeRec;
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>with the following fields:</t> <t>With the following fields:</t>
<dl> <dl>
<dt>tips-view-uri:</dt> <dt>tips-view-uri:</dt>
<dd> <dd>
<t>URI to the requested TIPS view. The value of this field <bcp14>MU ST</bcp14> have the <t>This is the URI to the requested TIPS view. The value of this fie ld <bcp14>MUST</bcp14> have the
following format: following format:
</t> </t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
scheme "://" tips-view-host "/" tips-view-path scheme "://" tips-view-host "/" tips-view-path
tips-view-host = host [ ":" port] tips-view-host = host [ ":" port]
tips-view-path = path tips-view-path = path
]]></artwork> ]]></sourcecode>
<t>where scheme <bcp14>MUST</bcp14> be "http" or "https" unless spec <t>Where scheme <bcp14>MUST</bcp14> be "http" or "https" unless spec
ified by a future ified by a future
extension, and host, port and path are as specified in Sections 3.2.2, 3.2.3, extension, and host, port, and path are as specified in Sections <xref target="R
and 3.3 in <xref target="RFC3986"/>. An ALTO server <bcp14>SHOULD</bcp14> use th FC3986" sectionFormat="bare" section="3.2.2"/>, <xref target="RFC3986" sectionFo
e "https" scheme unless rmat="bare"
the contents of the TIPS view are intended to be publicly accessible and does section="3.2.3"/>, and <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 do
not raise security concerns. The field <bcp14>MUST</bcp14> contain only ASCII ch aracters. In not raise security concerns. The field <bcp14>MUST</bcp14> contain only ASCII ch aracters. In
case the original URL contains international characters (e.g., in the domain case the original URL contains international characters (e.g., in the domain
name), the ALTO server implementation <bcp14>MUST</bcp14> properly encode the UR L into the name), the ALTO server implementation <bcp14>MUST</bcp14> properly encode the UR L into the
ASCII format (e.g., using the "urlencode" function).</t> ASCII format (e.g., using the "urlencode" function).</t>
<t>A server <bcp14>MUST NOT</bcp14> use the same URI for different T IPS views, either for <t>A server <bcp14>MUST NOT</bcp14> use the same URI for different T IPS views, either for
different resources or different request bodies to the same resource. URI different resources or for different request bodies to the same resource. URI
generation is implementation specific, for example, one may compute a generation is implementation specific; for example, one may compute a
Universally Unique Identifier (UUID, <xref target="RFC4122"/>) or a hash value b Universally Unique Identifier (UUID) <xref target="RFC4122"/> or a hash value ba
ased on sed on
the request, and append it to a base URL. For performance considerations, it the 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 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 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 address, which may result in duplicated TIPS views in cases such as mobile
clients. However, this is not mandatory as a server may intentionally use clients. However, this is not mandatory as a server may intentionally use
client information to compute the TIPS view URI to provide service isolation client information to compute the TIPS view URI to provide service isolation
between clients.</t> between clients.</t>
</dd> </dd>
<dt>tips-view-summary:</dt> <dt>tips-view-summary:</dt>
<dd> <dd>
<t>Contains an updates-graph-summary. <t>Contains an updates-graph-summary.
</t> </t>
<t>The updates-graph-summary field contains the starting sequence nu <t>The "updates-graph-summary" field contains the
mber start-seq of the updates graph and the end-seq that
(start-seq) of the updates graph and the last sequence number (end-seq) that
is currently available, along with a recommended edge to consume is currently available, along with a recommended edge to consume
(start-edge-rec). If the client does NOT provide a version tag, the server (start-edge-rec). If the client does NOT provide a version tag, the server
<bcp14>MUST</bcp14> recommend the edge of the latest snapshot available. <bcp14>MUST</bcp14> recommend the edge of the latest snapshot available.
If the client does provide a version tag, the server <bcp14>MUST</bcp14> either recommend If the client does provide a version tag, the server <bcp14>MUST</bcp14> either recommend
the first incremental update edge starting from the client's tagged version the first incremental update edge starting from the client's tagged version
or the edge of the latest snapshot. Which edge is selected depends on the or recommend the edge of the latest snapshot: which edge is selected depends on the
implementation. For example, a server <bcp14>MAY</bcp14> calculate the cumulativ e size of implementation. For example, a server <bcp14>MAY</bcp14> calculate the cumulativ e size of
the incremental updates available from that version onward and compare it to 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 the size of the complete resource snapshot. If the snapshot is bigger, the
server recommends the first incremental update edge starting from the server recommends the first incremental update edge starting from the
client's tagged version. Otherwise, the server recommends the latest snapshot client's tagged version. Otherwise, the server recommends the latest snapshot
edge.</t> edge.</t>
</dd> </dd>
</dl> </dl>
<t>If the request has any errors, the TIPS service <bcp14>MUST</bcp14> r eturn an HTTP <t>If the request has any errors, the TIPS service <bcp14>MUST</bcp14> r eturn an HTTP
"400 Bad Request" to the ALTO client; the body of the response 400 (Bad Request) error code to the ALTO client; the body of the response
follows the generic ALTO error response format specified in follows the generic ALTO error response format specified in
Section 8.5.2 of <xref target="RFC7285"/>. Hence, an example ALTO error respons e <xref 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> has the format shown in <xref target="ex-bad-request"/>.</t>
<figure anchor="ex-bad-request"> <figure anchor="ex-bad-request">
<name>ALTO Error Example</name> <name>ALTO Error Example</name>
<artwork align="left"><![CDATA[ <sourcecode type=""><![CDATA[
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Content-Length: 131 Content-Length: 131
Content-Type: application/alto-error+json Content-Type: application/alto-error+json
{ {
"meta":{ "meta":{
"code": "E_INVALID_FIELD_VALUE", "code": "E_INVALID_FIELD_VALUE",
"field": "resource-id", "field": "resource-id",
"value": "my-network-map/#" "value": "my-network-map/#"
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>Note that "field" and "value" are optional fields. If the "value" <t>Note that "field" and "value" are optional fields. If the "value"
field exists, the "field" field <bcp14>MUST</bcp14> exist.</t> field exists, the "field" field <bcp14>MUST</bcp14> exist.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the TIPS request does not have a "resource-id" field, the error code of <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> and the "field " field, if the error message <bcp14>MUST</bcp14> be <tt>E_MISSING_FIELD</tt> and the "field " field, if
present, <bcp14>MUST</bcp14> be "resource-id". The TIPS service <bcp14>MUST NOT< /bcp14> create any TIPS present, <bcp14>MUST</bcp14> be "resource-id". The TIPS service <bcp14>MUST NOT< /bcp14> create any TIPS
view.</li> view.</li>
<li>If the "resource-id" field is invalid or is not associated with th e TIPS, the <li>If the "resource-id" field is invalid or is not associated with th e TIPS, the
error code of the error message <bcp14>MUST</bcp14> be <tt>E_INVALID_FIELD_VALUE </tt>. If present, error code of the error message <bcp14>MUST</bcp14> be <tt>E_INVALID_FIELD_VALUE </tt>. If present,
the "field" field <bcp14>MUST</bcp14> be the full path of the "resource-id" fiel d, and the the "field" field <bcp14>MUST</bcp14> be the full path of the "resource-id" fiel d, and the
"value" field <bcp14>MUST</bcp14> be the invalid resource-id.</li> "value" field <bcp14>MUST</bcp14> be the invalid resource-id.</li>
<li>If the resource is a POST-mode service that requires input, the cl ient <bcp14>MUST</bcp14> <li>If the resource is a POST-mode service that requires input, the cl ient <bcp14>MUST</bcp14>
set the "input" field to a JSON object with the parameters that that resource set the "input" field to a JSON object with the parameters that resource
expects. If the "input" field is missing or invalid, TIPS <bcp14>MUST</bcp14> re turn the expects. If the "input" field is missing or invalid, TIPS <bcp14>MUST</bcp14> re turn the
same error response that resource would return for missing or invalid input same error response that resource would return for missing or invalid inputs
(see <xref target="RFC7285"/>).</li> (see <xref target="RFC7285"/>).</li>
</ul> </ul>
<t>Furthermore, it is <bcp14>RECOMMENDED</bcp14> that the server uses th e following HTTP codes to <t>Furthermore, it is <bcp14>RECOMMENDED</bcp14> that the server use the following HTTP code to
indicate other errors, with the media type "application/alto-error+json".</t> indicate other errors, with the media type "application/alto-error+json".</t>
<ul spacing="normal"> <dl spacing="normal">
<li>429 (Too Many Requests): when the number of TIPS views open reques <dt>429 (Too Many Requests):</dt><dd>Indicates when the number of TIPS
ts exceeds views open requests exceeds
the server threshold. The server <bcp14>MAY</bcp14> indicate when to re-try the the server threshold. The server <bcp14>MAY</bcp14> indicate when to retry the r
request in equest in
the "Re-Try After" headers.</li> the "Re-Try After" headers.</dd>
</ul> </dl>
<t>It is <bcp14>RECOMMENDED</bcp14> that the server provide the ALTO/SSE support for the TIPS <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 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 TIPS views that it monitors and make better cross-resource transport decisions
(see <xref target="cross-sched"/> for related considerations).</t> (see <xref target="cross-sched"/> for related considerations).</t>
</section> </section>
<section anchor="open-example"> <section anchor="open-example">
<name>Open Example</name> <name>Open Example</name>
<section anchor="basic-example"> <section anchor="basic-example">
<name>Basic Example</name> <name>Basic Example</name>
<t>For simplicity, assume that the ALTO server is using the Basic
<!--[rfced] What does "Basic" refer to in the following text (i.e.,
why is it capped here?
Original:
For simplicity, assume that the ALTO server is using the Basic
authentication.
-->
<t>For simplicity, assume that the ALTO server is using Basic
authentication. If a client with username "client1" and password authentication. If a client with username "client1" and password
"helloalto" wants to create a TIPS view of an ALTO Cost Map resource "helloalto" wants to create a TIPS view of an ALTO cost map resource
with resource ID "my-routingcost-map", it can send the with the resource ID "my-routingcost-map", it can send the
request depicted in <xref target="ex-op"/>.</t> request depicted in <xref target="ex-op"/>.</t>
<figure anchor="ex-op"> <figure anchor="ex-op">
<name>Request Example of Opening a TIPS View</name> <name>Request Example of Opening a TIPS View</name>
<artwork align="left"><![CDATA[ <sourcecode type=""><![CDATA[
POST /tips HTTP/1.1 POST /tips HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-tips+json, application/alto-error+json Accept: application/alto-tips+json, application/alto-error+json
Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K
Content-Type: application/alto-tipsparams+json Content-Type: application/alto-tipsparams+json
Content-Length: 41 Content-Length: 41
{ {
"resource-id": "my-routingcost-map" "resource-id": "my-routingcost-map"
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>If the operation is successful, the ALTO server returns the <t>If the operation is successful, the ALTO server returns the
message shown in <xref target="ex-op-rep"/>.</t> message shown in <xref target="ex-op-rep"/>.</t>
<figure anchor="ex-op-rep"> <figure anchor="ex-op-rep">
<name>Response Example of Opening a TIPS View</name> <name>Response Example of Opening a TIPS View</name>
<artwork align="left"><![CDATA[ <sourcecode type=""><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/alto-tips+json Content-Type: application/alto-tips+json
Content-Length: 255 Content-Length: 255
{ {
"tips-view-uri": "https://alto.example.com/tips/2718281828", "tips-view-uri": "https://alto.example.com/tips/2718281828",
"tips-view-summary": { "tips-view-summary": {
"updates-graph-summary": { "updates-graph-summary": {
"start-seq": 101, "start-seq": 101,
"end-seq": 106, "end-seq": 106,
"start-edge-rec" : { "start-edge-rec" : {
"seq-i": 0, "seq-i": 0,
"seq-j": 105 "seq-j": 105
} }
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="example-using-digest-authentication"> <section anchor="example-using-digest-authentication">
<name>Example using Digest Authentication</name> <name>Example Using Digest Authentication</name>
<t>Below is another example of the same query using Digest authenticat ion, a <t>Below is another example of the same query using Digest authenticat ion, 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 sa me as in <xref target="ex-op-rep"/> and thus 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 sa me as in <xref target="ex-op-rep"/>; thus, it has been
omitted for simplicity.</t> omitted for simplicity.</t>
<figure anchor="ex-op-digest"> <figure anchor="ex-op-digest">
<name>Open Example with Digest Authentication</name> <name>Open Example with Digest Authentication</name>
<artwork align="left"><![CDATA[ <sourcecode type=""><![CDATA[
POST /tips HTTP/1.1 POST /tips HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-tips+json, application/alto-error+json Accept: application/alto-tips+json, application/alto-error+json
Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K
Content-Type: application/alto-tipsparams+json Content-Type: application/alto-tipsparams+json
Content-Length: 41 Content-Length: 41
{ {
"resource-id": "my-routingcost-map" "resource-id": "my-routingcost-map"
} }
skipping to change at line 1068 skipping to change at line 1306
{ {
"resource-id": "my-routingcost-map" "resource-id": "my-routingcost-map"
} }
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/alto-tips+json Content-Type: application/alto-tips+json
Content-Length: 258 Content-Length: 258
{....} {....}
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="tips-sse"> <section anchor="tips-sse">
<name>Example using ALTO/SSE</name> <name>Example Using ALTO/SSE</name>
<t>This section gives an example of receiving incremental updates of t he TIPS view <t>This section gives an example of receiving incremental updates of t he TIPS view
summary using ALTO/SSE <xref target="RFC8895"/>. Consider the <tt>tips-sse</tt> resource, as summary using ALTO/SSE <xref target="RFC8895"/>. Consider the <tt>tips-sse</tt> resource, as
announced by the IRD in <xref target="ex-ird"/>, which provides ALTO/SSE for the announced by the IRD in <xref target="ex-ird"/>, which provides ALTO/SSE for the
<tt>update-my-cost-tips</tt> resource, a client may send the following request t o <tt>update-my-cost-tips</tt> resource; a client may send the following request t o
receive updates of the TIPS view (authentication is omitted for simplicity).</t> receive updates of the TIPS view (authentication is omitted for simplicity).</t>
<figure anchor="ex-tips-sse"> <figure anchor="ex-tips-sse">
<name>Example of Monitoring TIPS view with ALTO/SSE</name> <name>Example of Monitoring TIPS View with ALTO/SSE</name>
<artwork align="left"><![CDATA[ <sourcecode type=""><![CDATA[
POST /updates/tips HTTP/1.1 POST /updates/tips HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: text/event-stream,application/alto-error+json Accept: text/event-stream,application/alto-error+json
Content-Type: application/alto-updatestreamparams+json Content-Type: application/alto-updatestreamparams+json
Content-Length: 76 Content-Length: 76
{ {
"add": { "add": {
"tips-123": { "resource-id": "update-my-cost-tips" } "tips-123": { "resource-id": "update-my-cost-tips" }
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>Then, the client will be able to receive the TIPS view summary as f ollows.</t> <t>Then, the client will be able to receive the TIPS view summary as f ollows.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Connection: keep-alive Connection: keep-alive
Content-Type: text/event-stream Content-Type: text/event-stream
event: application/alto-tips+json,tips-123 event: application/alto-tips+json,tips-123
data: { data: {
data: "tips-view-uri": "https://alto.example.com/tips/2718281828", data: "tips-view-uri": "https://alto.example.com/tips/2718281828",
data: "tips-view-summary": { data: "tips-view-summary": {
data: "updates-graph-summary": { data: "updates-graph-summary": {
data: "start-seq": 101, data: "start-seq": 101,
data: "end-seq": 106, data: "end-seq": 106,
data: "start-edge-rec" : { data: "start-edge-rec" : {
data: "seq-i": 0, data: "seq-i": 0,
data: "seq-j": 105 data: "seq-j": 105
data: } data: }
data: } data: }
data: } data: }
data: } data: }
]]></artwork> ]]></sourcecode>
<t>When there is an update to the TIPS view, for example, the <tt>end- <t>When there is an update to the TIPS view (for example, when the <tt
seq</tt> is >end-seq</tt> is
increased by 1, the client will be able to receive the incremental update of the increased by 1), the client will be able to receive the incremental update of th
e
TIPS view summary as follows.</t> TIPS view summary as follows.</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
event: application/merge-patch+json,tips-123 event: application/merge-patch+json,tips-123
data: { data: {
data: "tips-view-summary": { data: "tips-view-summary": {
data: "updates-graph-summary": { data: "updates-graph-summary": {
data: "end-seq": 107 data: "end-seq": 107
data: } data: }
data: } data: }
data: } data: }
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="pull"> <section anchor="pull">
<name>TIPS Data Transfers - Client Pull</name> <name>TIPS Data Transfers - Client Pull</name>
<t>TIPS allows an ALTO client to retrieve the content of an update item <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 from the updates graph, with an update item defined as the content
(incremental update or snapshot) on an edge in the updates graph.</t> (incremental update or snapshot) on an edge in the updates graph.</t>
<section anchor="request"> <section anchor="request">
<name>Request</name> <name>Request</name>
<t>The client sends an HTTP GET request, where the media type of an <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 o f update item resource <bcp14>MUST</bcp14> be the same as the "media-type" field o f
the update item on the specified edge in the updates graph.</t> the update item on the specified edge in the updates graph.</t>
<t>The GET request <bcp14>MUST</bcp14> have the following format:</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> GET /<tips-view-path>/ug/<i>/<j>
HOST: <tips-view-host> HOST: <tips-view-host>
]]></artwork> ]]></sourcecode>
<t>For example, consider the updates graph in <xref target="fig-ug-schem a"/>. If the client <t>For example, consider the updates graph in <xref target="fig-ug-schem a"/>. If the client
wants to query the content of the first update item (0 -&gt; 101) whose media ty pe wants to query the content of the first update item (0 -&gt; 101) whose media ty pe
is "application/alto-costmap+json", it sends a request to is "application/alto-costmap+json", it sends a request to
"/tips/2718281828/ug/0/101" and sets the "Accept" header to "/tips/2718281828/ug/0/101" and sets the "Accept" header to
"application/alto-costmap+json,application/alto-error+json". See <xref target="i u-example"/> "application/alto-costmap+json,application/alto-error+json". See <xref target="i u-example"/>
for a concrete example.</t> for a concrete example.</t>
</section> </section>
<section anchor="response"> <section anchor="response">
<name>Response</name> <name>Response</name>
<t>If the request is valid (<tt>ug/&lt;i&gt;/&lt;j&gt;</tt> exists), the response is encoded <t>If the request is valid (i.e., <tt>ug/&lt;i&gt;/&lt;j&gt;</tt> exists ), the response is encoded
as a JSON object whose data format is indicated by the media type.</t> 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 upda tes, by long polling <t>A client <bcp14>MAY</bcp14> conduct proactive fetching of future upda tes, by long polling
updates that have not been provided in the directory yet. For such updates, the updates that have not been provided in the directory yet. For such updates, the
client <bcp14>MUST</bcp14> indicate all media types that may appear. It is <bcp1 4>RECOMMENDED</bcp14> that the client <bcp14>MUST</bcp14> indicate all media types that may appear. It is <bcp1 4>RECOMMENDED</bcp14> that the
server allows for at least the long polling of <tt>&lt;end-seq&gt; -&gt; &lt;end -seq + 1&gt;</tt>.</t> server allow for at least the long polling of <tt>&lt;end-seq&gt; -&gt; &lt;end- seq + 1&gt;</tt>.</t>
<t>Hence, the server processing logic <bcp14>MUST</bcp14> be:</t> <t>Hence, the server processing logic <bcp14>MUST</bcp14> be:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If <tt>ug/&lt;i&gt;/&lt;j&gt;</tt> exists: return content using en <li>If <tt>ug/&lt;i&gt;/&lt;j&gt;</tt> exists, return content using en
coding.</li> coding.</li>
<li>Else if long polling <tt>ug/&lt;i&gt;/&lt;j&gt;</tt> is acceptable <li>Else, if long polling <tt>ug/&lt;i&gt;/&lt;j&gt;</tt> is acceptabl
: put request in a e, put request in a
backlog queue, then either a response is triggered when the content is ready backlog queue, then either a response is triggered when the content is ready
or the request is interrupted, e.g., by a network error.</li> or the request is interrupted (e.g., by a network error).</li>
<li>Else: return error.</li> <li>Else, return error.</li>
</ul> </ul>
<t>It is <bcp14>RECOMMENDED</bcp14> that the server uses the following H TTP codes to <t>It is <bcp14>RECOMMENDED</bcp14> that the server use the following HT TP codes to
indicate errors, with the media type "application/alto-error+json", indicate errors, with the media type "application/alto-error+json",
regarding update item requests.</t> regarding update item requests.</t>
<ul spacing="normal"> <dl spacing="normal">
<li>404 (Not Found): if the requested update does not exist, or the re <dt>404 (Not Found):</dt><dd>Indicates that the requested update does
quested not exist or the requested
TIPS view does not exist or is closed by the server.</li> TIPS view does not exist or is closed by the server.</dd>
<li>410 (Gone): if an update has a seq that is smaller than the start- <dt>410 (Gone):</dt><dd>Indicates an update has a seq that is smaller
seq.</li> than the start-seq.</dd>
<li>415 (Unsupported Media Type): if the media type(s) accepted by the <dt>415 (Unsupported Media Type):</dt><dd>Indicates the media type (or
types) accepted by the
client does not include the media type of the update chosen by the client does not include the media type of the update chosen by the
server.</li> server.</dd>
<li>425 (Too Early): if the seq exceeds the server long-polling window <dt>425 (Too Early):</dt><dd>Indicates the seq exceeds the server long
</li> polling window.</dd>
<li>429 (Too Many Requests): when the number of pending (long-poll) <dt>429 (Too Many Requests):</dt><dd>Indicates the number of pending (
requests exceeds the server threshold. The server <bcp14>MAY</bcp14> indicate wh long poll)
en to re-try requests exceeds the server threshold. The server <bcp14>MAY</bcp14> indicate wh
the request in the "Re-Try After" headers.</li> en to retry
</ul> the request in the "Re-Try After" headers.</dd>
</dl>
</section> </section>
<section anchor="iu-example"> <section anchor="iu-example">
<name>Example</name> <name>Example</name>
<t>Assume the client wants to get the contents of the update item on <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> edge 0 to 101. The format of the request is shown in <xref target="ex-get"/>.</ t>
<figure anchor="ex-get"> <figure anchor="ex-get">
<name>GET Example</name> <name>GET Example</name>
<artwork align="left"><![CDATA[ <sourcecode type=""><![CDATA[
GET /tips/2718281828/ug/0/101 HTTP/1.1 GET /tips/2718281828/ug/0/101 HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-costmap+json, \ Accept: application/alto-costmap+json, \
application/alto-error+json application/alto-error+json
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>The response is shown in <xref target="ex-get-res"/>.</t> <t>The response is shown in <xref target="ex-get-res"/>.</t>
<figure anchor="ex-get-res"> <figure anchor="ex-get-res">
<name>Response to a GET Request</name> <name>Response to a GET Request</name>
<artwork align="left"><![CDATA[ <sourcecode type=""><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/alto-costmap+json Content-Type: application/alto-costmap+json
Content-Length: 50 Content-Length: 50
{ ... full replacement of my-routingcost-map ... } { ... full replacement of my-routingcost-map ... }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="new-next-edge-recommendation"> <section anchor="new-next-edge-recommendation">
<name>New Next Edge Recommendation</name> <name>New Next Edge Recommendation</name>
<t>While intended TIPS usage is for the client to receive a recommended <t>While intended TIPS usage is for the client to receive a recommended
starting edge in the TIPS summary, consume that edge, then construct starting edge in the TIPS summary, consume that edge, and then construct
all future URIs by incrementing the sequence count by 1, there may be all future URIs by incrementing the sequence count by one, there may be
cases in which the client needs to request a new next edge to 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 has not consume. For example, if a client has an open TIPS view, yet has not
polled in a while, the client may request the next logical polled in a while, the client may request the next logical
incremental URI but the server has compacted the updates graph so it incremental URI; however, the server has compacted the updates graph, so it
no longer exists. Thus, the client <bcp14>MAY</bcp14> request a new next edge t o no longer exists. Thus, the client <bcp14>MAY</bcp14> request a new next edge t o
consume based on its current version of the resource.</t> consume based on its current version of the resource.</t>
<section anchor="request-1"> <section anchor="request-1">
<name>Request</name> <name>Request</name>
<t>An ALTO client requests that the server provide a next edge recomme ndation for a <t>An ALTO client requests that the server provide a next edge recomme ndation for a
given TIPS view by sending an HTTP POST request with the media type 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> h "application/alto-tipsparams+json". The URL of the request <bcp14>MUST</bcp14> h
ave the format of</t> ave the following format:</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
<tips-view-path>/ug <tips-view-path>/ug
]]></artwork> ]]></sourcecode>
<t>and the <tt>HOST</tt> field <bcp14>MUST</bcp14> be the <tt>&lt;tips -view-host&gt;</tt>.</t> <t>and the <tt>HOST</tt> field <bcp14>MUST</bcp14> be the <tt>&lt;tips -view-host&gt;</tt>.</t>
<t>The POST body has the same format as the TIPSReq <xref target="fig- open-req"/>. The <t>The POST body has the same format as the TIPSReq in <xref target="f ig-open-req"/>. The
<tt>resource-id</tt> <bcp14>MUST</bcp14> be the same as the resource ID used to create the TIPS view, <tt>resource-id</tt> <bcp14>MUST</bcp14> be the same as the resource ID used to create the TIPS view,
and the optional <tt>input</tt> field <bcp14>MUST NOT</bcp14> be present.</t> and the optional <tt>input</tt> field <bcp14>MUST NOT</bcp14> be present.</t>
</section> </section>
<section anchor="response-1"> <section anchor="response-1">
<name>Response</name> <name>Response</name>
<t>The response to a valid request <bcp14>MUST</bcp14> be a JSON merge <t>The response to a valid request <bcp14>MUST</bcp14> be a JSON merge
patch to the object of type patch to the object of the AddTIPSResponse type (defined in <xref target="open-
AddTIPSResponse (defined in <xref target="open-resp"/>), denoted as media type resp"/>), denoted as media type
"application/merge-patch+json". The "update-graph-summary" field <bcp14>MUST</bc "application/merge-patch+json". The "updates-graph-summary" field <bcp14>MUST</b
p14> be present cp14> be present
in the response and hence its parent field "tips-view-summary" <bcp14>MUST</bcp1 in the response; hence, its parent field "tips-view-summary" <bcp14>MUST</bcp14>
4> be present be present
as well.</t> as well.</t>
<t>If the <tt>tag</tt> field is present in the request, the server <bc p14>MUST</bcp14> check if any <t>If the <tt>tag</tt> field is present in the request, the server <bc p14>MUST</bcp14> check if any
version within the range [start-seq, end-seq] has the same tag value. If the version within the range [start-seq, end-seq] has the same tag value. If the
version exists, e.g., denoted as tag-seq, the server <bcp14>MUST</bcp14> compute version exists (e.g., denoted as tag-seq), the server <bcp14>MUST</bcp14> comput
the paths from e the paths from
both tag-seq and 0 to the end-seq, and choose the one with the minimal cost. The both tag-seq and 0 to the end-seq and choose the one with the minimal cost. The
cost <bcp14>MAY</bcp14> be implementation specific, e.g., number of messages, ac cost <bcp14>MAY</bcp14> be implementation specific (e.g., number of messages, ac
cumulated data cumulated data
size, etc. The first edge of the selected path <bcp14>MUST</bcp14> be returned a size, etc.). The first edge of the selected path <bcp14>MUST</bcp14> be returned
s the as the
recommended next edge.</t> recommended next edge.</t>
<t>If the <tt>tag</tt> field is NOT present, it <bcp14>MUST</bcp14> be
interpreted as the tag-seq is 0.</t> <!--[rfced] *AD, We had two questions regarding the following text:
<t>It is <bcp14>RECOMMENDED</bcp14> that the server uses the following
HTTP codes to Original:
If the tag field is NOT present, it MUST be interpreted as the
tag-seq is 0.
a) Please review our update to the following text that contains BCP 14
keywords and let us know any objections.
Current:
If the tag field is NOT present, the interpretation MUST be that the
tag-seq is 0.
b) Is the use of "NOT" (in all caps) necessary here? Might this cause
BCP 14 confusion? Note that this is not the only occurrence in the
document.
-->
<t>If the <tt>tag</tt> field is NOT present, the interpretation <bcp
14>MUST</bcp14> be that the tag-seq is 0.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that the server use the following
HTTP code to
indicate errors, with the media type "application/alto-error+json", indicate errors, with the media type "application/alto-error+json",
regarding new next edge requests.</t> regarding new next edge requests.</t>
<ul spacing="normal"> <dl spacing="normal">
<li>404 (Not Found): if the requested TIPS view does not exist or is <dt>404 (Not Found):</dt><dd>Indicates that the requested TIPS view
closed by the server.</li> does not exist or has been
</ul> closed by the server.</dd>
</dl>
</section> </section>
<section anchor="example"> <section anchor="example">
<name>Example</name> <name>Example</name>
<t>We give an example of the new next edge recommendation service. Ass <t>In this section, we give an example of the new next edge recommenda
ume that a tion service. Assume that a
client already creates a TIPS view as in <xref target="open-example"/>, whose up client already creates a TIPS view (as in <xref target="open-example"/>) whose u
dates graph pdates graph
is as shown in <xref target="fig-ug"/>. Now assume that the client already has t is as shown in <xref target="fig-ug"/>. Now assume that the client already has t
ag 0881080 ag 0881080,
whose corresponding sequence number is 103, and sends the following new next whose corresponding sequence number is 103, and sends the following new next
edge recommendation request (authentication is omitted for simplicity):</t> edge recommendation request (authentication is omitted for simplicity):</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
POST /tips/2718281828/ug HTTP/1.1 POST /tips/2718281828/ug HTTP/1.1
HOST alto.example.com HOST alto.example.com
Accept: application/merge-patch+json, application/alto-error+json Accept: application/merge-patch+json, application/alto-error+json
Content-Type: application/alto-tipsparams+json Content-Type: application/alto-tipsparams+json
Content-Length: 62 Content-Length: 62
{ {
"resource-id": "my-routingcost-map", "resource-id": "my-routingcost-map",
"tag": "0881080" "tag": "0881080"
} }
]]></artwork> ]]></sourcecode>
<t>According to <xref target="fig-ug"/>, there are 3 potential paths: <t>According to <xref target="fig-ug"/>, there are three potential pat
103 -&gt; 104 -&gt; 105 -&gt; 106, hs: 103 -&gt; 104 -&gt; 105 -&gt; 106,
103 -&gt; 105 -&gt; 106, and 0 -&gt; 105 -&gt; 106. Assume that the server choos 103 -&gt; 105 -&gt; 106, and 0 -&gt; 105 -&gt; 106. Assume that the server choos
es shortest es the shortest
update path by the accumulated data size and the best path is 103 -&gt; 105 -&gt ; 106. 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> Thus, the server responds with the following message:</t>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/merge-patch+json Content-Type: application/merge-patch+json
Content-Length: 193 Content-Length: 193
{ {
"tips-view-summary": { "tips-view-summary": {
"updates-graph-summary": { "updates-graph-summary": {
"start-seq": 101, "start-seq": 101,
"end-seq": 106, "end-seq": 106,
"start-edge-rec": { "start-edge-rec": {
"seq-i": 103, "seq-i": 103,
"seq-j": 105 "seq-j": 105
} }
} }
} }
} }
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="ops-considerations"> <section anchor="ops-considerations">
<name>Operation and Processing Considerations</name> <name>Operation and Processing Considerations</name>
<t>TIPS has some common operational considerations as ALTO/SSE <xref targe t="RFC8895"/>, <t>TIPS has some common operational considerations as ALTO/SSE <xref targe t="RFC8895"/>,
including:</t> including:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>server choosing update messages (<xref section="9.1" sectionFormat=" <li>the server choosing update messages (<xref section="9.1" sectionForm
of" target="RFC8895"/>);</li> at="of" target="RFC8895"/>);</li>
<li>client processing update messages (<xref section="9.2" sectionFormat <li>the client processing update messages (<xref section="9.2" sectionFo
="of" target="RFC8895"/>);</li> rmat="of" target="RFC8895"/>);</li>
<li>updates of filtered map services (<xref section="9.3" sectionFormat= <li>the updates of filtered map services (<xref section="9.3" sectionFor
"of" target="RFC8895"/>);</li> mat="of" target="RFC8895"/>); and</li>
<li>updates of ordinal mode costs (<xref section="9.4" sectionFormat="of <li>the updates of ordinal mode costs (<xref section="9.4" sectionFormat
" target="RFC8895"/>).</li> ="of" target="RFC8895"/>).</li>
</ul> </ul>
<t>There are also some operation considerations specific to TIPS, which we
discuss <t>There are also some operational considerations specific to TIPS, which
we discuss
below.</t> below.</t>
<section anchor="load-balancing"> <section anchor="load-balancing">
<name>Considerations for Load Balancing</name> <name>Considerations for Load Balancing</name>
<t>There are two levels of load balancing in TIPS. The first level is to <t>There are two levels of load balancing in TIPS: the first level is to
balance balance
the load of TIPS views for different clients, and the second is to balance the the load of TIPS views for different clients and the second is to balance the
load of incremental updates.</t> load of incremental updates.</t>
<t>Load balancing of TIPS views can be achieved either at the applicatio n layer or <t>Load balancing of TIPS views can be achieved either at the applicatio n layer or
at the infrastructure layer. For example, an ALTO server <bcp14>MAY</bcp14> set at the infrastructure layer. For example, an ALTO server <bcp14>MAY</bcp14> set
<tt>&lt;tips-view-host&gt;</tt> to different subdomains to distribute TIPS views , or simply <tt>&lt;tips-view-host&gt;</tt> to different subdomains to distribute TIPS views or simply
use the same host of the TIPS service and rely on load balancers to distribute use the same host of the TIPS service and rely on load balancers to distribute
the load.</t> the load.</t>
<!--[rfced] In the following text, is the switch from singular to
plural intentional?
Original:
For example, a request may be directed to a wrong backend server ...
* the backend servers are stateful, i.e., the TIPS view is created and
stored only on a single server;
Perhaps:
For example, a request may be directed to the wrong backend server ...
* the backend server is...
-->
<t>TIPS allows a client to make concurrent pulls of incremental updates for the <t>TIPS allows a client to make concurrent pulls of incremental updates for the
same TIPS view potentially through different HTTP connections. As a consequence, same TIPS view, potentially through different HTTP connections. As a consequence
it introduces additional complexities when the ALTO server is being load ,
balanced. For example, a request may be directed to a wrong backend server and TIPS introduces additional complexities when the ALTO server is being load
get incorrectly processed if the following two conditions both hold:</t> balanced. For example, a request may be directed to the wrong backend server and
get processed incorrectly if the following two conditions both hold:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the backend servers are stateful, i.e., the TIPS view is created <li>the backend servers are stateful (i.e., the TIPS view is created
and stored only on a single server;</li> and stored only on a single server); and</li>
<li>the ALTO server is using layer-4 load balancing, i.e., the <li>the ALTO server is using Layer 4 load balancing (i.e., the
requests are distributed based on the TCP 5-tuple.</li> requests are distributed based on the TCP 5-tuple).</li>
</ul> </ul>
<t>Thus, additional considerations are required to enable correct load <t>Thus, additional considerations are required to enable correct load
balancing for TIPS, including:</t> balancing for TIPS, including:</t>
<ul spacing="normal"> <dl spacing="normal">
<li>Use a stateless architecture: One solution is to follow the <dt>Using a stateless architecture:</dt><dd>One solution is to follow
the
stateless computing pattern: states about the TIPS view are not stateless computing pattern: states about the TIPS view are not
maintained by the backend servers but are stored in a distributed maintained by the backend servers but are stored in a distributed
database. Thus, concurrent requests to the same TIPS view can be database. Thus, concurrent requests to the same TIPS view can be
processed on arbitrary stateless backend servers, which all processed on arbitrary stateless backend servers, which all
fetches data from the same database.</li> fetch data from the same database.</dd>
<li>Configure the load balancers properly: In case when the backend <dt>Configuring the load balancers properly:</dt><dd>In the case that
the backend
servers are stateful, the load balancers must be properly servers are stateful, the load balancers must be properly
configured to guarantee that requests of the same TIPS view always configured to guarantee that requests of the same TIPS view always
arrive at the same server. For example, an operator or a provider arrive at the same server. For example, an operator or a provider
of an ALTO server <bcp14>MAY</bcp14> configure layer-7 load balancers that of an ALTO server <bcp14>MAY</bcp14> configure Layer 7 load balancers that
distribute requests based on the tips-view-path component in the URI.</li> distribute requests based on the tips-view-path component in the URI.</dd>
</ul> </dl>
</section> </section>
<section anchor="cross-sched"> <section anchor="cross-sched">
<name>Considerations for Cross-Resource Dependency Scheduling</name> <name>Considerations for Cross-Resource Dependency Scheduling</name>
<t>Dependent ALTO resources result in cross-resource dependencies in <t>Dependent ALTO resources result in cross-resource dependencies in
TIPS. Consider the following pair of resources, where my-cost-map TIPS. Consider the following pair of resources, where my-cost-map
(C) is dependent on my-network-map (N). The updates graph for each (C) is dependent on my-network-map (N). The updates graph for each
resource is shown, along with links in between the respective updates resource is shown, along with links between the respective updates
graphs to show dependency:</t> graphs to show dependency:</t>
<figure anchor="fig-cross"> <figure anchor="fig-cross">
<name>Example Dependency Model</name> <name>Example Dependency Model</name>
<artwork type="drawing" align="center"><![CDATA[ <artwork type="drawing" align="center"><![CDATA[
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
my-network-map (N) | 0 |-->|89 |-->|90 |-->|91 |-->|92 | my-network-map (N) | 0 |-->|89 |-->|90 |-->|91 |-->|92 |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| \ \ \ | \ \ \
| \ \ \ | \ \ \
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
skipping to change at line 1378 skipping to change at line 1651
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|_______________________| |_______________________|
]]></artwork> ]]></artwork>
</figure> </figure>
<t>In <xref target="fig-cross"/>, the cost-map versions 101 and 102 (den oted as C101 and C102) <t>In <xref target="fig-cross"/>, the cost-map versions 101 and 102 (den oted as C101 and C102)
are dependent on the network-map version 89 (denoted as N89). The cost-map 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> 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 <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 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> and how long the client needs to buffer the update.</t>
<ul spacing="normal"> <dl spacing="normal">
<li>Example 1: The client requests N89, N90, N91, C101, C102 in that <dt>Example 1:</dt><dd>The client requests N89, N90, N91, C101, C102 i
n that
order. The client either gets no consistent view of the resources order. The client either gets no consistent view of the resources
or has to buffer N90 and N91.</li> or has to buffer N90 and N91.</dd>
<li>Example 2: The client requests C101, C102, C103, N89. The client <dt>Example 2:</dt><dd>The client requests C101, C102, C103, N89. The
either gets no consistent view or has to buffer C103.</li> client
</ul> either gets no consistent view or has to buffer C103.</dd>
</dl>
<!--[rfced] It appears there is text missing in the last sentence
below. Please let us know how to update.
Original:
This allows a client to build consistent views quickly as the updates
are already stored in the buffer. Otherwise, it is RECOMMENDED to
request
-->
<t>To get consistent ALTO information, a client must process the updates following <t>To get consistent ALTO information, a client must process the updates following
the guidelines specified in <xref section="9.2" sectionFormat="of" target="RFC88 95"/>. If resource permits the guidelines specified in <xref section="9.2" sectionFormat="of" target="RFC88 95"/>. If resources permit
(i.e., sufficient updates can be buffered), an ALTO client can safely use long (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 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 quickly as the updates are already stored in the buffer. Otherwise, it is
<bcp14>RECOMMENDED</bcp14> to request</t> <bcp14>RECOMMENDED</bcp14> to request</t>
</section> </section>
<section anchor="shared-tips-view"> <section anchor="shared-tips-view">
<name>Considerations for Managing Shared TIPS Views</name> <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 <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 for any resource. However, on the server side, there are different
implementation options, especially for common resources (e.g., implementation options, especially for common resources (e.g.,
network map or cost map) that may be frequently queried by many network maps or cost maps) that may be frequently queried by many
clients. Some potential options are listed below:</t> clients. Some potential options are listed below:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>An ALTO server creates one TIPS view of the common resource for <li>An ALTO server creates one TIPS view of the common resource for
each client.</li> each client.</li>
<li> <li>
<t>An ALTO server maintains one copy of the TIPS view for each commo n <t>An ALTO server maintains one copy of the TIPS view for each commo n
resource and all clients requesting the same resources use the resource and all clients requesting the same resources use the
same copy. There are two ways to manage the storage for the same copy. There are two ways to manage the storage for the
shared copy: </t> shared copy:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the ALTO server maintains the set of clients that have sent a polling <li>the ALTO server maintains the set of clients that have sent a polling
request to the TIPS view, and only removes the view from the storage when request to the TIPS view and only removes the view from the storage when
the set becomes empty and no client immediately issues a new edge request;</li> the set becomes empty and no client immediately issues a new edge request; or</l
i>
<li>the TIPS view is never removed from the storage.</li> <li>the TIPS view is never removed from the storage.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>Developers may choose different implementation options depending on <t>Developers may choose different implementation options depending on
criteria such as request frequency, available resources of the ALTO criteria such as request frequency, available resources of the ALTO
server, the ability to scale, and programming complexity.</t> server, the ability to scale, and programming complexity.</t>
</section> </section>
<section anchor="considerations-for-offering-shortcut-incremental-updates" > <section anchor="considerations-for-offering-shortcut-incremental-updates" >
<name>Considerations for Offering Shortcut Incremental Updates</name> <name>Considerations for Offering Shortcut Incremental Updates</name>
<t>Besides the mandatory stepwise incremental updates (from i to i+1), <t>Besides the mandatory stepwise incremental updates (from i to i+1),
an ALTO server <bcp14>MAY</bcp14> optionally offer shortcut incremental updates, or 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; simple shortcuts, between two non-consecutive versions i and i+k (k &gt;
1). Such shortcuts offer alternative paths in the update graph and 1). Such shortcuts offer alternative paths in the updates graph and
can potentially speed up the transmission and processing of can potentially speed up the transmission and processing of
incremental updates, leading to faster synchronization of ALTO incremental updates, leading to faster synchronization of ALTO
information, especially when the client has limited bandwidth and information, especially when the client has limited bandwidth and
computation. However, implementors of an ALTO server must be aware computation. However, implementors of an ALTO server must be aware
that:</t> that:</t>
<ol spacing="normal" type="1"><li>Optional shortcuts may increase the si
ze of the update graph, in <ol spacing="normal" type="1"><li>optional shortcuts may increase the si
the worst case being the square of the number of updates (i.e., ze of the updates graph, worst case scenario being the square of the number of u
pdates (i.e.,
when a shortcut is offered for each version to all future when a shortcut is offered for each version to all future
versions).</li> versions).</li>
<li>Optional shortcuts require additional storage on the ALTO server.< <li>optional shortcuts require additional storage on the ALTO server.<
/li> /li>
<li>Optional shortcuts may reduce concurrency when the updates do not <li>optional shortcuts may reduce concurrency when the updates do not
overlap, e.g., when the updates apply to different parts of an overlap (e.g., when the updates apply to different parts of an
ALTO resource. In such a case, the total size of the original ALTO resource). In such a case, the total size of the original
updates is close to the size of the shortcut, but the original updates is close to the size of the shortcut, but the original
updates can be transmitted concurrently while the shortcut is updates can be transmitted concurrently while the shortcut is
transmitted in a single connection.</li> transmitted in a single connection.</li>
</ol> </ol>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The security considerations (Section 15 of <xref target="RFC7285"/>) of <t>The security considerations of the base protocol (<xref
the base target="RFC7285" sectionFormat="of" section="15"/>) fully apply to this
protocol fully apply to this extension. For example, the same extension. For example, the same authenticity and integrity
authenticity and integrity considerations (Section 15.1 of <xref target="RFC7285 considerations (<xref target="RFC7285" sectionFormat="of"
"/>) section="15.1"/>) still fully apply; the same considerations for the
still fully apply; the same considerations for the privacy of ALTO privacy of ALTO users (<xref target="RFC7285" sectionFormat="of"
users (Section 15.4 of <xref target="RFC7285"/>) also still fully apply. Additio section="15.4"/>) also still fully apply. Additionally, operators of the
nally, ALTO servers <bcp14>MUST</bcp14> follow the guidelines in <xref
operators of the ALTO servers <bcp14>MUST</bcp14> follow the guidelines in <xref target="RFC9325"/> to avoid new TLS vulnerabilities discovered after
target="RFC9325"/> to avoid <xref target="RFC7285"/> was published.</t>
new TLS vulnerabilities discovered after <xref target="RFC7285"/> was published. <t>The additional services (the addition of update read service and update
</t>
<t>The additional services (addition of update read service and update
push service) provided by this extension extend the attack surface push service) provided by this extension extend the attack surface
described in Section 15.1.1 of <xref target="RFC7285"/>. The following sub-sect ions discuss the described in <xref target="RFC7285" sectionFormat="of" section="15.1.1"/>. The following subsections discuss the
additional risks and their remedies.</t> additional risks and their remedies.</t>
<section anchor="tips-denial-of-service-attacks"> <section anchor="tips-denial-of-service-attacks">
<name>TIPS: Denial-of-Service Attacks</name> <name>TIPS: Denial-of-Service Attacks</name>
<t>Allowing TIPS views enables new classes of Denial-of-Service attacks. In <t>Allowing TIPS views enables new classes of DoS attacks. In
particular, for the TIPS server, one or multiple malicious ALTO clients might 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 create an excessive number of TIPS views, to exhaust the server resource and/or
to block normal users from the accessing the service.</t> to block normal users from accessing the service.</t>
<t>To avoid such attacks, the server <bcp14>MAY</bcp14> choose to limit the number of active <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 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 n umber of predictive fetching and the server <bcp14>MAY</bcp14> also choose to limit the n umber of
pending requests. If a new request exceeds the threshold, the server <bcp14>MAY< /bcp14> log 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> the event and return the HTTP status 429 (Too Many Requests).</t>
<t>It is important to note that the preceding approaches are not the onl y <t>It is important to note that the preceding approaches are not the onl y
possibilities. For example, it may be possible for TIPS to use somewhat more possibilities. For example, it may be possible for TIPS to use somewhat more
clever logic involving TIPS view eviction policies, IP reputation, clever logic involving TIPS view eviction policies, IP reputation,
rate-limiting, and compartmentalization of the overall threshold into smaller rate-limiting, and compartmentalization of the overall threshold into smaller
thresholds that apply to subsets of potential clients. If service availability 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 is a concern, ALTO clients <bcp14>MAY</bcp14> establish service level agreements with the ALTO
server.</t> server.</t>
</section> </section>
<section anchor="alto-client-update-overloading-or-instability"> <section anchor="alto-client-update-overloading-or-instability">
<name>ALTO Client: Update Overloading or Instability</name> <name>ALTO Client: Update Overloading or Instability</name>
<t>The availability of continuous updates can also cause overload for an ALTO <t>The availability of continuous updates can also cause overload for an ALTO
client, in particular, an ALTO client with limited processing capabilities. The client, in particular, an ALTO client with limited processing capabilities. The
current design does not include any flow control mechanisms for the client to 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 and QUIC reduce the update rates from the server. For example, TCP, HTTP/2, and QUIC
provide stream and connection flow control data limits, which might help prevent provide stream and connection flow control data limits, which might help prevent
the client from being overloaded. Under overloading, the client <bcp14>MAY</bcp1 4> choose to the client from being overloaded. Under overloading, the client <bcp14>MAY</bcp1 4> choose to
remove the information resources with high update rates.</t> remove the information resources with high update rates.</t>
<t>Also, under overloading, the client may no longer be able to detect <t>Also, under overloading, the client may no longer be able to detect
whether information is still fresh or has become stale. In such a 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 case, the client should be careful in how it uses the information to
avoid stability or efficiency issues.</t> avoid stability or efficiency issues.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to register the following media types from the regist <t>IANA has registered the following media types from the registry availab
ry available at <xref target="IANA-Media-Type"/>:</t> le at <xref target="IANA-Media-Type"/>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>application/alto-tips+json: as described in <xref target="open-resp" />;</li> <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> <li>application/alto-tipsparams+json: as described in <xref target="open -req"/>;</li>
</ul> </ul>
<ul empty="true">
<li> <!--[rfced] Please note that any changes to the IANA Considerations
<t>Note to the RFC Editor: Please replace This-Document with the RFC n section will be communicated to IANA upon the completion of
umber to be assigned to this document.</t> AUTH48.-->
</li>
</ul>
<section anchor="applicationalto-tipsjson-media-type"> <section anchor="applicationalto-tipsjson-media-type">
<name>application/alto-tips+json Media Type</name> <name>application/alto-tips+json Media Type</name>
<dl> <dl>
<dt>Type name:</dt> <dt>Type name:</dt>
<dd> <dd>application</dd>
<t>application</t>
</dd>
<dt>Subtype name:</dt> <dt>Subtype name:</dt>
<dd> <dd>alto-tips+json</dd>
<t>alto-tips+json</t>
</dd>
<dt>Required parameters:</dt> <dt>Required parameters:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
<dt>Optional parameters:</dt> <dt>Optional parameters:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
<dt>Encoding considerations:</dt> <dt>Encoding considerations:</dt>
<dd> <dd>Encoding considerations are identical to those specified for the
<t>Encoding considerations are identical to those specified for the "application/json" media type. See <xref target="RFC8259"/>.</dd>
"application/json" media type. See <xref target="RFC8259"/>.</t>
</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd> <dd>See the Security Considerations section of RFC 9569.</dd>
<t>See the Security Considerations section of This-Document.</t>
</dd>
<dt>Interoperability considerations:</dt> <dt>Interoperability considerations:</dt>
<dd> <dd>N/A</dd>
<t>N/A.</t>
</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd> <dd><xref target="open-resp"/> of RFC 9569.</dd>
<t><xref target="open-resp"/> of This-Document.</t>
</dd>
<dt>Applications that use this media type:</dt> <dt>Applications that use this media type:</dt>
<dd> <dd>ALTO servers and ALTO clients either stand alone or are embedded w
<t>ALTO servers and ALTO clients either stand alone or are embedded ithin other
within other applications.</dd>
applications.</t>
</dd>
<dt>Fragment identifier considerations:</dt> <dt>Fragment identifier considerations:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd> <dt>Additional information:</dt><dd>
<dt>Additional information:</dt> <t><br/></t>
<dd> <dl spacing="compact">
<t><br/>
</t>
<dl>
<dt>Deprecated alias names for this type:</dt> <dt>Deprecated alias names for this type:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
<dt>Magic number(s):</dt> <dt>Magic number(s):</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
<dt>File extension(s):</dt> <dt>File extension(s):</dt>
<dd> <dd>RFC 9569 uses the media type to refer to protocol messages; th
<t>This document uses the media type to refer to protocol messag us, it
es and thus does not require a file extension.</dd>
does not require a file extension.</t>
</dd>
<dt>Macintosh file type code(s):</dt> <dt>Macintosh file type code(s):</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
</dl> </dl>
</dd> </dd>
<dt>Person and email address to contact for further information:</dt> <dt>Person &amp; email address to contact for further information:</dt
<dd> >
<t>See Authors' Addresses section.</t> <dd><br/>See the Authors' Addresses section of RFC 9569.</dd>
</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd> <dd>COMMON</dd>
<t>COMMON</t>
</dd>
<dt>Restrictions on usage:</dt> <dt>Restrictions on usage:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
<dt>Author:</dt> <dt>Author:</dt>
<dd> <dd>See the Authors' Addresses section of RFC 9569.</dd>
<t>See Authors' Addresses section.</t>
</dd>
<dt>Change controller:</dt> <dt>Change controller:</dt>
<dd> <dd>Internet Engineering Task Force (iesg@ietf.org).</dd>
<t>Internet Engineering Task Force (mailto:iesg@ietf.org).</t>
</dd>
<dt>Provisional registration?:</dt>
<dd>
<t>No</t>
</dd>
</dl> </dl>
</section> </section>
<section anchor="applicationalto-tipsparamsjson-media-type"> <section anchor="applicationalto-tipsparamsjson-media-type">
<name>application/alto-tipsparams+json Media Type</name> <name>application/alto-tipsparams+json Media Type</name>
<dl> <dl>
<dt>Type name:</dt> <dt>Type name:</dt>
<dd> <dd>application</dd>
<t>application</t>
</dd>
<dt>Subtype name:</dt> <dt>Subtype name:</dt>
<dd> <dd>alto-tipsparams+json</dd>
<t>alto-tipsparams+json</t>
</dd>
<dt>Required parameters:</dt> <dt>Required parameters:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
<dt>Optional parameters:</dt> <dt>Optional parameters:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
<dt>Encoding considerations:</dt> <dt>Encoding considerations:</dt>
<dd> <dd>Encoding considerations are identical to those specified for the
<t>Encoding considerations are identical to those specified for the "application/json" media type. See <xref target="RFC8259"/>.</dd>
"application/json" media type. See <xref target="RFC8259"/>.</t>
</dd>
<dt>Security considerations:</dt> <dt>Security considerations:</dt>
<dd> <dd>See the Security Considerations section of RFC 9569.</dd>
<t>See the Security Considerations section of This-Document.</t>
</dd>
<dt>Interoperability considerations:</dt> <dt>Interoperability considerations:</dt>
<dd> <dd>N/A</dd>
<t>N/A.</t>
</dd>
<dt>Published specification:</dt> <dt>Published specification:</dt>
<dd> <dd><xref target="open-req"/> of RFC 9569.</dd>
<t><xref target="open-req"/> of This-Document.</t>
</dd>
<dt>Applications that use this media type:</dt> <dt>Applications that use this media type:</dt>
<dd> <dd>ALTO servers and ALTO clients either stand alone or are embedded w
<t>ALTO servers and ALTO clients either stand alone or are embedded ithin other
within other applications.</dd>
applications.</t>
</dd>
<dt>Fragment identifier considerations:</dt> <dt>Fragment identifier considerations:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd> <dt>Additional information:</dt><dd>
<dt>Additional information:</dt> <t><br/></t>
<dd> <dl spacing="compact">
<t><br/>
</t>
<dl>
<dt>Deprecated alias names for this type:</dt> <dt>Deprecated alias names for this type:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
<dt>Magic number(s):</dt> <dt>Magic number(s):</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
<dt>File extension(s):</dt> <dt>File extension(s):</dt>
<dd> <dd>This document uses the media type to refer to protocol message
<t>This document uses the media type to refer to protocol messag s; thus, it
es and thus does not require a file extension.</dd>
does not require a file extension.</t>
</dd>
<dt>Macintosh file type code(s):</dt> <dt>Macintosh file type code(s):</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
</dl> </dl>
</dd> </dd>
<dt>Person and email address to contact for further information:</dt>
<dd> <dt>Person &amp; email address to contact for further information:<br/
<t>See Authors' Addresses section.</t> ></dt>
</dd> <dd><br/>See the Authors' Addresses section of RFC 9569.</dd>
<dt>Intended usage:</dt> <dt>Intended usage:</dt>
<dd> <dd>COMMON</dd>
<t>COMMON</t>
</dd>
<dt>Restrictions on usage:</dt> <dt>Restrictions on usage:</dt>
<dd> <dd>N/A</dd>
<t>N/A</t>
</dd>
<dt>Author:</dt> <dt>Author:</dt>
<dd> <dd>See the Authors' Addresses section of RFC 9569.</dd>
<t>See Authors' Addresses section.</t>
</dd>
<dt>Change controller:</dt> <dt>Change controller:</dt>
<dd> <dd>Internet Engineering Task Force (iesg@ietf.org).</dd>
<t>Internet Engineering Task Force (mailto:iesg@ietf.org).</t>
</dd>
<dt>Provisional registration?:</dt>
<dd>
<t>No</t>
</dd>
</dl> </dl>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<title>Key words for use in RFCs to Indicate Requirement Levels</tit 19.xml"/>
le> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.72
<author fullname="S. Bradner" initials="S." surname="Bradner"/> 85.xml"/>
<date month="March" year="1997"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
<abstract> 59.xml"/>
<t>In many standards track documents several words are used to sig <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
nify the requirements in the specification. These words are often capitalized. T 74.xml"/>
his document defines these words as they should be interpreted in IETF documents <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.88
. This document specifies an Internet Best Current Practices for the Internet Co 95.xml"/>
mmunity, and requests discussion and suggestions for improvements.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
</abstract> 12.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
<seriesInfo name="BCP" value="14"/> 13.xml"/>
<seriesInfo name="RFC" value="2119"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
<seriesInfo name="DOI" value="10.17487/RFC2119"/> 14.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.39
<reference anchor="RFC7285"> 86.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
<title>Application-Layer Traffic Optimization (ALTO) Protocol</title 25.xml"/>
>
<author fullname="R. Alimi" initials="R." role="editor" surname="Ali
mi"/>
<author fullname="R. Penno" initials="R." role="editor" surname="Pen
no"/>
<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 top
ology information of Internet Service Provider (ISP) networks. For example, view
s to Internet routing tables at Looking Glass servers are available and can be p
ractically downloaded to many network application clients. What is missing is kn
owledge 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 t
o distribute it.</t>
<t>The Application-Layer Traffic Optimization (ALTO) services defi
ned in this document provide network information (e.g., basic network location s
tructure and preferences of network paths) with the goal of modifying network re
source consumption patterns while maintaining or improving application performan
ce. 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 appli
cations to effectively utilize them. Additional services are built on top of the
maps.</t>
<t>This document describes a protocol implementing the ALTO servic
es. Although the ALTO services would primarily be provided by ISPs, other entiti
es, such as content service providers, could also provide ALTO services. Applica
tions 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 con
tent 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 ECMAScrip
t Programming Language Standard. JSON defines a small set of formatting rules fo
r the portable representation of structured data.</t>
<t>This document removes inconsistencies with other specifications
of JSON, repairs specification errors, and offers experience-based interoperabi
lity 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</ti
tle>
<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 protoco
l 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 Upd
ates 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 resource
s, to client applications so that clients can make informed decisions in utilizi
ng 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 inc
remental, in that if only a small section of an information resource changes, th
e ALTO server can send just the changes and (2) updates can be immediate, in tha
t 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="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document specifies the HTTP/1.1 message syntax, message parsing, connectio
n 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="T
homson"/>
<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 sem
antics 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 excha
nges 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="Bi
shop"/>
<date month="June" year="2022"/>
<abstract>
<t>The QUIC transport protocol has several features that are desir
able in a transport for HTTP, such as stream multiplexing, per-stream flow contr
ol, 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 ch
aracters that identifies an abstract or physical resource. This specification de
fines the generic URI syntax and a process for resolving URI references that mig
ht be in relative form, along with guidelines and security considerations for th
e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
et of all valid URIs, allowing an implementation to parse the common components
of a URI reference without knowing the scheme-specific requirements of every pos
sible identifier. This specification does not define a generative grammar for UR
Is; 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 (T
LS) 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 Sec
urity (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, inclu
ding attacks on the most commonly used cipher suites and their modes of operatio
n. This document provides the latest recommendations for ensuring the security o
f 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 pu
blished when the industry was transitioning to TLS 1.2. Years later, this transi
tion 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, thi
s 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>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC4122">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.41
<title>A Universally Unique IDentifier (UUID) URN Namespace</title> 22.xml"/>
<author fullname="P. Leach" initials="P." surname="Leach"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
<author fullname="M. Mealling" initials="M." surname="Mealling"/> 05.xml"/>
<author fullname="R. Salz" initials="R." surname="Salz"/>
<date month="July" year="2005"/> <reference anchor="IANA-Media-Type" target="https://www.iana.org/assignm
<abstract> ents/media-types">
<t>This specification defines a Uniform Resource Name namespace fo
r UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique ID
entifier). A UUID is 128 bits long, and can guarantee uniqueness across space an
d time. UUIDs were originally used in the Apollo Network Computing System and la
ter 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 t
he kind permission of the OSF (now known as The Open Group). Information from ea
rlier versions of the DCE specification have been incorporated into this documen
t. [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 us
e HTTP to define new application protocols. It is written primarily to guide IET
F efforts to define application protocols using HTTP for deployment on the Inter
net 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>
<reference anchor="IANA-Media-Type" target="https://www.iana.org/assignm
ents/media-types/media-types.xhtml">
<front> <front>
<title>Media Types</title> <title>Media Types</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date year="2023" month="June"/>
</front> </front>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="sec-dep-model"> <section anchor="sec-dep-model">
<name>A High-Level Deployment Model</name> <name>A High-Level Deployment Model</name>
<t>Conceptually, the TIPS system consists of three types of resources:</t> <t>Conceptually, the TIPS system consists of three types of resources:</t>
<ul spacing="normal"> <dl spacing="normal">
<li>(R1) TIPS frontend to create TIPS views.</li> <dt>(R1):</dt><dd>The TIPS frontend to create TIPS views.</dd>
<li>(R2) TIPS view directory, which provides metadata (e.g., references) <dt>(R2):</dt><dd>The TIPS view directory, which provides metadata (e.g.
about the , references) about the
network resource data.</li> network resource data.</dd>
<li>(R3) The actual network resource data, encoded as complete ALTO netw <dt>(R3):</dt><dd>The actual network resource data, encoded as complete
ork ALTO network
resources (e.g., cost map, network map) or incremental updates.</li> resources (e.g., a cost map or a network map) or incremental updates.</dd>
</ul> </dl>
<figure anchor="fig-service-model"> <figure anchor="fig-service-model">
<name>Sample TIPS Deployment Model</name> <name>Sample TIPS Deployment Model</name>
<artwork type="drawing" align="center"><![CDATA[ <artwork type="drawing" align="center"><![CDATA[
+------------------------------------------------+ +------------------------------------------------+
| | | |
+------+ |R1: Frontend/Open R2: Directory/Meta R3: Data | +------+ |R1: Frontend/Open R2: Directory/Meta R3: Data |
| | "iget" base | +-----+ +-----+ +-----+ | | | "iget" base | +-----+ +-----+ +-----+ |
| | resource 1 | | | | | | | | | | resource 1 | | | | | | | |
| |-------------|---->| | | | | | | | |-------------|---->| | | | | | |
| | incremental | | | | |-------->| | | | | incremental | | | | |-------->| | |
skipping to change at line 1927 skipping to change at line 2007
| | incremental | | | | | | | | | | incremental | | | | | | | |
| | transfer | +-----+ | | ------->| | | | | transfer | +-----+ | | ------->| | |
| | resource | | | | | | | | resource | | | | | |
| |<------------|-----------------------| | | | | | |<------------|-----------------------| | | | |
+------+ | +-----+ +-----+ | +------+ | +-----+ +-----+ |
| | | |
+------------------------------------------------+ +------------------------------------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Design Point: Component Resource Location</t> <t>Design Point: Component Resource Location</t>
<ul spacing="normal"> <dl spacing="normal">
<li>Design 1 (Single): all the three resource types at the same, single <dt>Design 1 (Single):</dt><dd>all the three resource types at the same
server (accessed via single server (accessed via
relative reference)</li> relative reference).</dd>
<li>Design 2 (Flexible): all three resource types can be at their own se <dt>Design 2 (Flexible):</dt><dd>all three resource types can be at thei
rver (accessed via r own server (accessed via
absolute reference)</li> absolute reference).</dd>
<li>Design 3 (Dir + Data): R2 and R3 must remain together, though R1 mig <dt>Design 3 (Dir + Data):</dt><dd>R2 and R3 must remain together, thoug
ht not be h R1 might not be
on the same server</li> on the same server.</dd>
</ul> </dl>
<t>This document supports Design 1 and Design 3. For Design 1, the TIPS se <t>This document supports Designs 1 and 3. For Design 1, the TIPS service
rvice
simply needs to always use the same host for the TIPS views. For Design 3, the simply needs to always use the same host for the TIPS views. For Design 3, the
TIPS service can set tips-view-host to a different server. Note that the TIPS service can set tips-view-host to a different server. Note that the
deployment flexibility is at the logical level, as these services deployment flexibility is at the logical level, as these services
can be distinguished by different paths and potentially be routed to different can be distinguished by different paths and potentially be routed to different
physical servers by layer-7 load balancing. See <xref target="load-balancing"/> for a physical servers by Layer 7 load balancing. See <xref target="load-balancing"/> for a
discussion on load balancing considerations. Future documents may extend the discussion on load balancing considerations. Future documents may extend the
protocol to support Design 2.</t> protocol to support Design 2.</t>
</section> </section>
<section anchor="sec-bcp-http"> <section anchor="sec-bcp-http">
<name>Conformance to "Building Protocols with HTTP" Best Current Practices </name> <name>Conformance to "Building Protocols with HTTP" Best Current Practices </name>
<t>This specification adheres fully to <xref target="RFC9205"/> as further elaborated below:</t> <t>This specification adheres fully to <xref target="RFC9205"/> as further elaborated below:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>TIPS does not "redefine, refine, or overlay the semantics of
<li><t>TIPS does not (as described in <xref section="3.1" sectionFormat=
"of" target="RFC9205"/>):</t><blockquote>...redefine, refine, or overlay the sem
antics of
generic protocol elements such as methods, status codes, or generic protocol elements such as methods, status codes, or
existing header fields" and instead focuses on "protocol elements existing header fields"
that are specific to <tt>[the TIPS]</tt> application -- namely, <tt>[its]</tt> H
TTP </blockquote>
resources" (<xref section="3.1" sectionFormat="of" target="RFC9205"/>).</li> <t>and instead focuses on</t>
<blockquote>"...protocol elements
that are specific to [the TIPS] application -- namely, [its] HTTP
resources.</blockquote></li>
<li>There are no statically defined URI components (<xref section="3.2" sectionFormat="of" target="RFC9205"/>).</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 which is <li>No minimum version of HTTP is specified by TIPS, which is
recommended (<xref section="4.1" sectionFormat="of" target="RFC9205"/>).</li> recommended (in <xref section="4.1" sectionFormat="of" target="RFC9205"/>).</li>
<li>The TIPS design follows the advice that "When specifying examples of <li>The TIPS design follows the advice (in <xref
protocol interactions, applications should document both the section="4.1" sectionFormat="of" target="RFC9205"/>) that:</li></ul>
request and response messages with complete header sections, <blockquote>When specifying examples of protocol interactions,
preferably in HTTP/1.1 format" (<xref section="4.1" sectionFormat="of" target="R applications should document both the request and response messages
FC9205"/>).</li> with complete header sections, preferably in HTTP/1.1 format...</blockquo
<li>TIPS uses URI templates which is recommended (<xref section="4.2" se te>
ctionFormat="of" target="RFC9205"/>).</li> <ul spacing="normal">
<li>TIPS follows the pattern that "a client will begin interacting <li>TIPS uses URI templates, which is recommended (in <xref section="4.2
with a given application server by requesting an initial document " sectionFormat="of" target="RFC9205"/>).</li>
that contains information about that particular deployment, <li>TIPS follows the pattern (in <xref section="4.4.1" sectionFormat="of
potentially including links to other relevant resources. Doing so " target="RFC9205"/>) that:</li></ul>
ensures that the deployment is as flexible as possible <blockquote>Generally, a client will begin interacting with a given
(potentially spanning multiple servers), allows evolution, and application server by requesting an initial document that contains
also allows the application to tailor the "discovery document" to the client" information about that particular deployment, potentially including
(<xref section="4.4.1" sectionFormat="of" target="RFC9205"/>).</li> links to other relevant resources. Doing so ensures that the
deployment is as flexible as possible (potentially spanning multiple
servers), allows evolution, and also gives the application the
opportunity to tailor the "discovery document" to the
client.</blockquote>
<ul spacing="normal">
<li>TIPS uses existing HTTP schemes (<xref section="4.4.2" sectionFormat ="of" target="RFC9205"/>).</li> <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" <li>TIPS defines its errors "to use the most applicable status code"
(<xref section="4.6" sectionFormat="of" target="RFC9205"/>).</li> (<xref section="4.6" sectionFormat="of" target="RFC9205"/>).</li>
<li>TIPS does not "make assumptions about the relationship between <li>TIPS does not (as in <xref section="4.11" sectionFormat="of"
separate requests on a single transport connection; doing so target="RFC9205"/>):</li></ul>
breaks many of the assumptions of HTTP as a stateless protocol and <blockquote>...make assumptions about the relationship between separate
will cause problems in interoperability, security, operability, requests on a single transport connection; doing so breaks many of the
and evolution" (<xref section="4.11" sectionFormat="of" target="RFC9205"/>). Th assumptions of HTTP as a stateless protocol and will cause problems in
e only relationship interoperability, security, operability, and
between requests is that a client must first discover where a TIPS view of evolution.</blockquote>
a resource will be served, which is consistent with the URI discovery in <t indent="3">The only relationship between requests is that a
<xref section="4.4.1" sectionFormat="of" target="RFC9205"/>.</li> client must first discover where a TIPS view of a resource will be
</ul> served, which is consistent with the URI discovery in <xref
section="4.4.1" sectionFormat="of" target="RFC9205"/>.</t>
</section> </section>
<section anchor="push"> <section anchor="push">
<name>Push-mode TIPS using HTTP Server Push</name> <name>Push-Mode TIPS Using HTTP Server Push</name>
<t>TIPS allows ALTO clients to subscribe to incremental updates of an ALTO <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 resource, and the specification in this document is based on the current best
practice of building such a service using native HTTP. Earlier versions of this practice of building such a service using native HTTP. Earlier versions of this
document had investigated the possibility of enabling push-mode TIPS, i.e., by document had investigated the possibility of enabling push-mode TIPS (i.e., by
taking advantage of the server push feature in HTTP/2 and HTTP/3.</t> taking advantage of the server push feature in HTTP/2 and HTTP/3).</t>
<t>In the ideal case, push-mode TIPS can potentially improve performance ( e.g., <t>In the ideal case, push-mode TIPS can potentially improve performance ( e.g.,
latency) in more dynamic environments and use cases, with wait-free message latency) in more dynamic environments and use cases with wait-free message
delivery. Using native server push also results in minimal changes to the delivery. Using a native server push also results in minimal changes to the
current protocol. While not adopted due to the lack of server push support and 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 increased protocol complexity, push-mode TIPS remains a potential direction of
protocol improvement.</t> protocol improvement.</t>
</section> </section>
<section anchor="persistent-http-connections"> <section anchor="persistent-http-connections">
<name>Persistent HTTP Connections</name> <name>Persistent HTTP Connections</name>
<t>Previous versions of this document use persistent HTTP connections to d <t>Previous draft versions of this document use persistent HTTP connection
etect the s to detect the
liveness of clients. This design, however, does not conform well with the best liveness of clients. However, this design does not conform well with the best
current practice of HTTP. For example, if an ALTO client is accessing a TIPS current 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 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 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 between the proxy and the ALTO server. Thus, using persistent connections may
not correctly detect the right liveness state.</t> not correctly detect the right liveness state.</t>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The authors of this document would like to thank Mark Nottingham and Sp <t>The authors of this document would like to thank <contact
encer fullname="Mark Nottingham"/> and <contact fullname="Spencer Dawkins"/>
Dawkins for providing invaluable reviews of earlier versions of this document, for providing invaluable reviews of earlier draft versions of this documen
Adrian Farrel, Qin Wu, and Jordi Ros Giralt for their continuous feedback, Russ t;
White, Donald Eastlake, Martin Thomson, Bernard Adoba, Spencer Dawkins, Linda <contact fullname="Adrian Farrel"/>, <contact fullname="Qin Wu"/>, and
Dunbar and Sheng Jiang for the directorate reviews, Martin Duke for the Area <contact fullname="Jordi Ros Giralt"/> for their continuous feedback;
Director review, Francesca Palombini, Wesley Eddy, Roman Danyliw, Murray <contact fullname="Russ White"/>, <contact fullname="Donald Eastlake 3rd"/>,
Kucherawy and Zaheduzzaman Sarker for the telechat and IESG reviews, and Mohamed <contact fullname="Martin Thomson"/>, <contact fullname="Bernard
Boucadair for shepherding the document.</t> Adoba"/>, <contact fullname="Spencer Dawkins"/>, <contact
fullname="Linda Dunbar"/>, and <contact fullname="Sheng Jiang"/> for the
directorate 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; and <contact
fullname="Mohamed Boucadair"/> for shepherding the document.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+1963rbyLHgfzwFlv4x0jFJSZSvmtgbjWVPdOLbkeTMN8nM <!--[rfced] Please review the following questions and updates
NwZJiMSYBBgAlMzI3lfZfZbdF9u6dleDoCR7kpN8u0f5MpYA9K26urru1ev1 regarding the terminology used in this document.
onExypN5ehCPy+S87mVpfd5LZnXRy9PLXl0mebUoyro3S+q0qqM6q2fwbeds
msaHL8/exGf6RXycnxflPKmzIo/fLoezbMS/n6blRTZKO1EyHJbpBTTmhsdv a. We have a few questions regarding the use of the abbreviation
TzsRfJNOinJ1EFf1OBrDXwfx1dHh2fPPUZQtyoO4LpdVPdjdfbw7iJIyTQ7M "TIPS":
iIfwd3RZlB8mZbFcHNCEoqiqk3z8SzIrcuhrlVbRIjuIYui/zEY1P4njUTGf
p3ld6d9ZPsv0+zhOx1md5ZODOC/gr7oY6Qv4tZgvEt8PPBini3p6EO9jL4sy i. We note the use of "TIPS" both with and without articles. Because
L+rsPEvH0raCeZbpuRunWs3tn43equXQPYHmUbKsp0WJs+/B/3GW0PKP/fj7 TIPS is expanded as "Transport Information Publication Service",
pKC/eeP+mGTuCawyTaF153XRH9yLTwvoAXZgRDux141/zKbLJI9PimTcoQaj should articles be added in front of the abbreviation where necessary?
rAbgP5um+WS85CfFGDp9sLcLP/JgmdclfZXlCT0qSgDOaTaizt7l2UVaVtAR
vUvnSTY7iD8k2SQpfl+Nlv10vOyP8ihcxkk/Ph1Ni7o2KzkpZrB39rmu53ic With an article:
9E6mMLOqdwpI+X/+ZxoPzPyPknIO+z6u7QruDR7fDxfwfQoImq/8Eo7SZV2N If a TIPS can provide updates with incremental changes for a
AJfP0ln6oZjbBfBk+jyZ39f8QX+cNtbxYx+X8mOST8xC8M/4BOCTlGP/Thdz resource...
fy9+WxbVArYlPqVnZimv08v4D8lFmpulPDsL1/Hu9NCv4cdklm7Yg1W5+v2o
6q/gC9yExsxf9mH9s0uYZWqm/jJZlmkevvnqie8+uD/Y/bq5z2geAG+ex+83 Without an article:
L+KP6WyWlsESRlPYO/vin7MCmkb/A03DLCBnOnmR4sk+efFssLf3WH59OHh0 TIPS uses an incremental RESTful design...
X359NLivTx/tPbynvz56rB883tsb+F/3/a/67f7jRw/06f4AmkWZ0mg39r29
getksEtdHx++Puy9AhqY9M5WC/oQCB0Tfnoc4+OKHyflBOE6retFdbCzc3l5 Perhaps:
2c+SPOkDcHaSqsomOdHZnTn1V2ND+3v/47Sez6grJv6D3cF+b/dBFPV6vTgZ The TIPS uses an incremental RESTful design...
wr4BNYwid9/A7iERnsVbMOMYwbUdz1KAfjJJq/gPZ2dvd/b6ezGSkayKgV7A
DNJxDMuOa+ijyuaLWdqNqvSvS5hXlsziEn+t6l6ZLmareFml8Sip0i6gV3w5 ii. Additionally, there are some instances of the phrase "TIPS
BdSDvnjo0SyDJvp9FSfSyyiNi/M4M9dfmVbFshzBhHAeNC5cgmmJLxZFPq7i service" throughout. As the "S" in TIPS already stands for "Service",
ywzoMr5Aej9L6zQaFXmN3UNXKSCO6yOGeyxO6jiBLZin/SiiuWT5qEwRsrCA how may we update these instances to avoid repetition?
5QJBV8HU4c6i6zYte6fY1/MLhH28dXr6fJsBhuizDWA5h9sOVzBfzuoMJvAR
my4UtrCEuljgVASgH7twk8F8cR4CDVnRKMkjMxmA4GJZmdnr5OpC4Adrh8sG b. May we change instances of "the ALTO new transport" to
dyyeF3lWFyVsT57WeI9H7UAEMppPYEeg++ISJ0qAk96gY+kn1sX4phFMmMAP "the new ALTO transport"?
dIHhF/+huMTBu7y0Ae0QMjdlTEe4yAEsM2Asxiu4jhfEZ8DWjJYlUKO6C2c3
7w1nxegDzcOxIgAqNzrSmmReIQK5sXEw7Cfnqxi28QzgmXyArR1fJAC5CSER c. FYI - We have updated the terms below as follows for
8FwwEfr4PE1qoIBVFzpBTC5GSwQx9FqXxXiJcKnlUES3ZsLiLWS7tvvEfSGu consistency. Please review and let us know any objections.
I4ZaZIpOnp+enS9ncnIQuhMgFs0zgCPDXGH3F8kwmwHhwy/TjwsYEAjFqht5
mAFKbFmobesJircWy9lsO0ZqDDzTaDNSRzmRLN2ygkG0s9/FE0oQz2az+HyZ i. Instances of update graph and update-graph-summary changed to
E3BxZ871GyAGfSYm82w8nsHtfQeAxCAkyFzdIYgCv3m4WCi8ei+TFWwEwPUc updates graph and updates-graph-summary (as there were more instances
J/ZmAbiT/Y1BuYWA2MbDcpEBlOJ5CsCnARWLE98R4WcxrBNABnkNs4WdrSzB of the latter and for consistency with this document's terminology
AFaoiM+Tsuu21L4FJjmPh6nHNjgwiFuXRXyZrCog63uwodpwCMTLn+SrK7lU list).
Pn/uCjnbTBYd8Yvodr2J/LkFtZ3arpI+7EtoRZUi6bNULzZUD59L57RA3+dW
dg69rbaxK0dY6sKQAdjiQT/+CsqITXaIPBKkkDwCpHCgdmA1z0EB441xr92E ii. We have expanded SSE as Server-Sent Events (plural) to match its
ZK1EK7MadgjGwf7gdZmOUkRjnRZ1CA1o+RvvDNx9+JOYkuBU0R23TnoNxaVJ use in RFC 8895. Please note that we have udpated to use the
yFSV6mI3nvA2iSwA8rsCriZFIJhNmYYgcHcsQQyZEMSt4bLW46nP9z9/xjlG abbreviated form after its expansion in the Introduction. Please let
fFbd43vwGNek1NX1h7h0DhS+aifS3E0k587RR1kkkrE5vgOUSEs6b/DXAn7N us know any objections.
4BuAL20b9qNbjmQhfpGVVd1FuFbQaenPX3CM2o4OghcP5Dm0KvLZSqQ5wurW
awzwU/cCZ1su+XoIz6u7eaG7JrVjFGLS6S6b9hsTVu9RhYVfvJJ4m4S90I7g -->
P0BcGBevXcEBzhewIUN8zgtL/B0dEeQX2Myzuu08wv4i19SV/oS8JXANAzMJ
fcMmllO4gQlnzSl3F/M0kXtrfZJ6enLpHNAX1z+H8yEoXulJ1SaECK/TjxYP <!--[rfced] Please review the following questions regarding this
FEksWYANnIE8vpxM/Ws6nIIGpEZYW2w3zoJLG4AMIC/gOgEkuo79QkAwAwa0 document's use of the <tt> element and other XML formatting queries.
tKqWc/wGuMACOu8VJc5ynlYVcg64sDyFG7As5s19MDQyplsiGFOu+XEBM8uL
Wm81FKTw9VbWT/swvAcvvMxJw1Fuk/qD6B80WcKKW7f6dIl3iA4E8MJh6KJx When reviewing the questions below, please keep in mind that in the
CIqsf+KxNE4uQH5KhoTd6xQAkDgdJdjDECkV3lcVoXOG2+1mirvh5gpbN0ad html and pdf outputs, the text enclosed in <tt> is output in
TpEjnez6/ctwQ5Bs9vAMrx146CBjRguPNyPhOYJO8B7P2bQo6HqZFpc0S0La fixed-width font. In the txt output, there are no changes to the font,
rFZqXzlQEM8HRyKb0HUxTQUIaZlfx+UlxGk5nhu5uBGsIh1HuLf/UNZPsaFx and these terms do not appear in quotation marks. Please review the
65HwknwJA5gB/gJSWd7Z8RFIO/4TWMAf6LO2c027RlARhMoNY982IaDOTR7N output files and let us know if quotation marks should be added
0F4v6RCBQ2oF8x5n50AiCNkZvJMimVXEt0U0NtCfNEf5I05zxH1gLOGGjivY anywhere for the ease of the reader or if the document should remain
azoKOMmyGCK5HmeozARSjl+T6Ok30VEdpPSAUXMAvYpMsOc0wBwE9Ak1oF6H as is.
y2xW9wCVhWrgcYjcxprrk27N+IUSGbhcaf0oAMPvpFSBLeoyLGHsgtlm3L16
WiLhXMCkhisV2HFehgrgXIpl3SvOhbwF4hXSCNnsyB5fPwiJcfkIGKOKcDNl a. Field names sometimes appear with quotes or <tt> styling
Hk+ul2xOaoc6BXRUil3SPR5ZcRJxGyYBfBupgIXpK/AyAfAvcYrnpD1e5nrA throughout. How may we update this formatting for consistency?
LsPbxl3NjgSeTZewIZeABAUR2SpNGUZ4jcWod0hGvB24afSQL2J8FgXAf5On
gCkJces8kWGWy/4COUGZwCFSRdStiiugTHjSo6srmFjVq6oULrMoel0QGQLu Originals (not a comprehensive list):
6XyJrJRtOU/cLqUWL/AuEM7LqQcGUYPji9c5vm7MV3YyA0lbjjK0pzX9gKej
glsRVQOriAih/U4OTMY3FHMAgK1XVzghWsmpkA8m7iElFdKSopzUi+Pnfo1y ...the <tt>tag</tt> field
O4ZqJdzv8QqvvxGq46tRmS1ol3FdKUqDGbNUMSAAor9sM8xyhkrAFS4rJKyA ...MAY set the "tag" field
cMR54Da1iExWqiFWBPhERF8v6awWsk8qa7AQxYRcaNKkTBZTIBnjlNeQrHf7
7uQ4XiQ1ApYWf57WI1ZCVXmyACwB9IeWbbc4gLiYw47BMU/4FhUM/cgEgman ...the optional <tt>input</tt> field
rCSqNRAASAiFn/IHJcoUsRlrYas85SNZg1GBZdyrqwIQNuilQmSCOc6WYyQs If the "input" field is missing or invalid...
swL4xCHQyHyEHV5d4YOee4Af0zqJeYIthCttlDJJbFkoHrZxugA5lUVdpelX
V6OyqODojKbp+PPnCDC+Ske94WjRQ80noL1OmyB7ieCgZdV+pwSNkzFSCod9 ..the <tt>HOST</tt> field
36FV7ZlQwLeo7MxGIhoiXR5bxlDUhqQe4rM12L1PB+DOnfiEOSDStsYvAd2W
cHRZcfoBLiHAOpC9O6/enZ51uvxv/PoN/X7y/D/eHZ88P8LfT/9w+PKl+yWS b. The terms below appear in different formatting patterns (some with
L07/8ObdyyP/m2/57M2rV89fH3FjeBoHj6LOq8MfO6wK6Lx5e3b85vXhyw4r different hyphenation, capitalization, quotation, <tt> styling,
xuwZxX0HeCCVzgE9F2WKKoCkigBmcACHjAzfPXv7v//X3j1Y+n8TpTnAnf9A etc.). Keeping in mind the question above, what format or pattern
BTn8gQjGoxE3x3/iHYwqmTRB3I5JEEgWGex61fXkETcFAPlvf0HI/HwQ/w72 would you like us to follow so that we may update these for
du/eU3mACw4eKsyChwSz9SdrjRmILY9ahnHQDJ43IB3O9/DH4G+Fu3lICAPk consistency?
nw8UIondDeINneayWsEB+UhAzbUFgs1xqGO+WtTI+Kg/QBLo1E64sUyDV9Rp
GhBgICAVUQKiwqEORLhdpD53+Ai9ucBHQBuv7hTy62dai+eCg2Nwdac0f35u i. resource-id(s) v. resource ID v. <tt>resource-id</tt> v. "resoure-id"
MyOQEqWu7LRUMYGXqWdB5ikS8ayaw0UiWoPEyvNjGGaEvK5K1so0B5KpqAK9
pB0p7WUVGNCNoBFjqFxhY1Upb9TxfRvBNhT5uDE3uciGKQtsnuypRAxjo5nB Originals:
6tBJsew3ZOm4yHWyaSi41aLRghPLPQCBxR4CDVXqdcrEIoqaLl4zYAAaOLUQ
NROi2bZFRFGQWxDuUFRXIHeXsIxupNoJRL1u817YMivcNkz/umLW6HaaLAjr ...with the resource ID "my-routingcost-map"...
x1vmxtdkBR1UciLOC7FrRBZbgV05Xr+gDqKDuOUx07s5oBajF+pAVDmFQ3RQ
/OjA10Wuey5sKYrJLCigtOEYHETFXOEV9FcqHoCo6JUc6DRBaErsjtfb0FjC If a TIPS can provide updates with incremental changes for a resource,
EoWngWSTvChZdR1gNHTmFBJ6GNvkMFWUKiasfwM9ecBnAXqSEmkGyKE0bQv+ the "incremental-change-media-types" field has an entry for that
9szHMIU9QZx75o0/oQAruC+oRJIV7s4PuHZ3+vI0HVdW90tnYoGWRqPC26A0 resource-id...
Qj0bcg2lUTeiSs2eoUDMRqZuiRsAouEMsF6IRT6+zMb1FHojiOFkkHDHqGND
aQtdX2JdlzElXHfSobPgrC/xWNTLnASsrtk/h+iZ09LQLdPrkYAWs0YNdUl2 The <tt>resource-id<tt> MUST be the same as the resource ID used to
VSyzOVUVbsiqodlKLops3L4G6G0IjHYK3a/bBLvBSKzeJtY9xStHzcKiX0fz create the TIPS view, and the optional input field MUST NOT be
JvrloPDO6rXWAdEXARUlbNtQK1+XiI6Ia11mf2OnREXFUzL6kNbxDFhLwLSX present.
RT7pLYAYeOyi8972nFXIvI04KNo26aZN5UzILdQFosATRJllAQNlqExA8AFP
DBuAd0Pv5OwswGND7Fo0esdrm7+2ufAnIOJ5hmoquTp443oVvibJXMzSaCGI ...the "field" field MUST be the full path of the "resource-id" field,
sQFrcBTf5aajWQSUFC0UALZL9KwhZ6lalHF8+EgXRLIKW5SAl7zIimUwPd71 and the "value" field MUST be the invalid resource-id.
ghQyhFgbDBdxqyDL5NKdy6mYmNdnakgPoxFJfo6FZz8FFLXzFXR3AQRnMWej
EtldEPuEsPFeqOAkXFtMq0DCieyuVXWdtU+nwUYEQjKdUpTkkD3G5bC00ryR ii. media type v. media-type v. "media-type"
enHIKpapYxZRPxPz1RjyhgHRJXCJgqtdXy7o8u+nb16jtAoCF0ml87SEi0Qe
9Ndn4oaEY4WSOS6TpsQiMSC8yhLmYsIpbHnht2FQ0xltt91fXfjNaZBYZ4Ms Originals:
KnSIXCkeEg8VmkI3vnEg2lCQ8YneJQwfp1wnqc/zY45pMOsVpT0QIDxfRICw
NxFn2Z6Ak6KuxNtBtVOsP2rQ3+By8bZZUhri3Wr1aMTVBhfkHI0SQP8yUp4N The client sends an HTTP GET request, where the media type of an
V7KzjiJ7Qok7DN0ZtaCl/ARDb2tbO7ZOFyxokW4GCJ5cd2JwY+CKKnLm2nhH update item resource MUST be the same as the "media-type" field of the
EiFW7NiDhq7lfIgsp6OjnoqKzcyZglFPUZfLEROEdycvCXFEuwZdyR3Ksg3x update item on the specified edge in the updates graph.
xjNL2gXAt1uF2di2ba3M7cVaG3QiKhaOTHTboBceKTI66elOF7NiRY/5QAVq
mpjVIfBRj96qToKEtrO0REZvVkxWIJDV/q/PyOHGiRhmVBrADyrxUPLkQ10Y It is RECOMMENDED that the server uses the following HTTP codes to
6nZJ1Z8Gag6U6kvtIsRYq7GFNG56B4oY2iaJmbl0SZrNWVUfee1g222AeGPE indicate errors, with the media type "application/alto-error+json"...
is3aQpLB4mv9LFCPe81rt6xFlrKfWpnWJVz8Yl7zLZIhqr2tjwosGTDHwh9R
BLeUZPCt+kKhZnYr3CBW6ghXhKIJHeCA9jkAEblrzocFqWuWTyfFTwqZepBk The resource "update-my-costs-tips" provides an ALTO TIPS service, and
kQGEkzwiDgH+xv0JNaVby8k2G0lQ1c36RIAPkaoNU4LVv1vrwwGY5f8URe/R this is indicated by the media-type "application/alto-tips+json".
CmjCSD66nBYVyqJjslICO1KpVlAcP9yJJVRoQCF0p0nHE1XNcFuhKFmdztnw
BMtdqnER7yLpux8fyv01TxbOjLiV9if9bvysAIH0VbLoxopJ8Mc2wQXFF5Yt d. There is one instance of end-seq that appears with <tt> styling
yT4LOOntGrw+9GpQfXnbRjXGepGhYj9F3kqH5ZGQ9BJtbO4T8kt8t8D2uo3e (every other instance appears without the <tt> tag). Would you like us
ZtYaPRngpAHdjGJHP+Pn+aggxSmR37C/rHGIUcOc5j1oS+j9JwYY7uqJbhbu to remove the <tt> tags from this one instance?
LmA1ysIjUnw7l6UNPgj9+AW7CoVafr+XNG/ZGzbSVMUIbVNjsa3CXvOy8FpS
KzbdebgP4bVFhB72OB0t0VziLzInzwD4+Rbrx+uaPpG8kG7GHZ1T1WEx8dw7 With <tt> styling:
Eeir5lwbQ0B3narTj//kV5fidhBHA4BEvu61XKlNgtrYi9M6Qa417B/4NXwM
csRf9ezReUAHD9S6IQfyt7Qs1tqRWqSBu1H0PF8DEqBqPm72T64p1fps2ns9 When there is an update to the TIPS view, for example, the
FU7PEQfSlVhDH2FmoBnMKkcjGbLtXa8rfzyJB7iwQ/OmcW4coEteTOMNUoLb <tt>end-seq</tt> is...
wPgVceNvkRtHBoKe0V9EaKw92nE9GUk68GtRAoYyxyLTUtTayrZZQ0FO5f7x
r9vixmPQHFhbck3J4rvxXvwk/lX0/gsxT7Fr3RSIOHzPdP0yq+BovtJJbBA/ But without:
kAdPZuhY2ba56m6g4+zoEBt6Q9KG0gvS0qJmCwddNeMNqPPOU3QmQnAEvaZU
SQ81xdtAeb/1SY6mysULA04U3CmbywbbIT3Q/plbxUgCZILTY7xIMjzqWwXc The URI points to that specific TIPS-V instance and the summary
Gsifb6N2A4XqBfrMFDgVeMC36VS6ypoeJzpQEU6Od5K4/qwK133uesOjcHQn contains the start-seq and end-seq of the updates graph...
6935FcF0JGN6UPCQxOU75xICmCgWwltBtWuZkGrS9DgCja/1j1+7stKMZvkr
267oRg4oQyWTxXUxliML4FSWguL0TFaFs+tShAD7UcxWsMb/AT8YmXeZSQzR -->
DT93e/bnbtR8drfxBTz4FMdHcoHDz6fw84ifxSfAjOGNCr9/QuPJRVaJmw0+
cIxDzB+gkb3EUxh/kg7eOhMmfR/HbwtgkVbawPLo/Dd0cA5ETDq4YQl3r/n7 <!--[rfced] We have updated a number of <artwork> elements to
rgHbpxBYjT/X30eNkb7i5270iRkvMWt8zc+n6FNzzV86C+pjbb0bf3Q/G/tC <sourcecode> throughout. Please confirm that these updates are
fTSBvemn7Tvto7njG1fe8p3v40TvtTt71/bhvxs0+vjta+E3n263DTvy70/h correct.
vug8b/Oz4377ya/wy+axY37/yc5DYcM/7RJ0cxZ+JmswbQfn+mvzxO9tXF/s
bQQKvR7Y1/Rkn2fxd5yHhUfLz07r00/6z3XzuGZ2rfAAcOwsJ+Fk8Olg7al7 In addition, please consider whether the "type" attribute of any
tc+v/n7zuOtQzCGw/mxGPPfG4Dr/81NjvOuOsP9VabL0+9OG0TbPw1wJ2u/d sourcecode element should be set and/or has been set correctly.
AATXzKPZUH9+an3aaGiIiAK75ZH/uduY8af4GasaPbVzjwatOCAv9/8O40f1
RQbPnhhdS4bPEMeetLK+zFk1xUVoQkxNdHUQ3znPJj115ABGiu6cXjLLJvmT The current list of preferred values for "type" is available at
zihFHqDDgadPOs71Q9VylD+APLFsL58/kz8PcZrqJ5nNZkuMI63ZlB0Xpitn https://www.rfc-editor.org/materials/sourcecode-types.txt. If the
uSHlvSgrWKmkfgsa5+UcuVSlgc0viw1ewFt39iJk9u4MlDWGS4o54KYehvld current list does not contain an applicable type, feel free to suggest
uJvIJnhOGhJUzwXTYedS2ErjiA2jKEZ0HSJwb7rz2xK0WVKAaU4aqsDxkVeJ additions for consideration. Note that it is also acceptable to leave
kjDqJESX7fSqfrNJHUCaQ+PYGjo9JP7zaAvo1TbJtKTX8ZFmVv90Z6+rom81 the "type" attribute not set.
TUSp780DvEZSppDbCENGbYnUAawWt8A7V7sZVKif5LABoIQkQLq5oBtE5Ns0 -->
A9sIT/1rHhY1bsYTSRWB3yOSkx5bXJa903zbmWCLgVXqhcG0NMEqapU6Of5o
s6KR46BYwq/I78YFJ0ebvCe8SWoLmPOZCh4SYBCoF9kKFt2gi75zJ/6OFK9H <!-- [rfced] Please review the "Inclusive Language" portion of the
KL69IlMBtAvAFV/dQeFOTAVR9EI1eU5PIcpC9JLCECVUTfpoQ/hzu7vBE4lW online Style Guide
FflVifTq9K7OGh0aDRSkDYiy3S7i42udD8pk9KFqOLjYiCKco+CRyo3HR5U/ <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
ihwY3/Q3kGAbtyo+D3sMGzTwb4sLM/5NkqPIsk6zmbjhGhMyCLSuTlxXgKk+ and let us know if any changes are needed.
v6Gx2/Zqvd2YLP4EEPpOIj2zPCMdFNkPYB/ni3q1k2OYr7o218nEz2FNvE9o
YX35bpoYR0SxLfuxOvBJB45nOhPtoctzstvfD30QhcpcwN2ivqGsANMA1VGx For example, please consider whether the use of "native" should be updated:
SG0UZt9DmrUGlVfWsP4BLbykcRstZxq5S5+S7oB0Br+q/sI5I7FWwmsbrlM0
8BSMHnWR1NOetftteSKF71B3VZKPkQl6l+52EKw4gQCkAvjtKDokWy/63fpr ...request (or pull) specific incremental updates using native
00cOxHzJLicYBOcvo4di1rBo2I3cYcOT9dAQUmvoCOLv4udk15BuYCSMLnDd HTTP/2...
BC6DPsItVB2q8TDQHJK6e/QhnlGyA9+h0UO2UBAhPsdHe7v7vb3de9vozVTj
aWz045SAreS10c39bY2IhmU2OzJkmFpFx0e70GYfDpwP0qATr0dF0MGagQ+a ...requests for specific incremental updates using native HTTP/2...
Z4kaXJARGGgge57KqUcHNCWDAWjRF4U6FkeNcYXYdMEWDfVkitgyLIpxzAtl
jRmwVvH8bIna1O9gcd7xL2pQLWlHfe2Tr3HNpLdiikTOguTLKFRtPf7JBZVi ...current best practice of building such a service using native HTTP.
KH465rEaemWcKH6mDgqp9+GlkAF2wkiMXlLMa82w6yZE29BB/NEiWhFABxCL Using a native server push also results in...
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> </rfc>
 End of changes. 248 change blocks. 
1555 lines changed or deleted 1237 lines changed or added

This html diff was produced by rfcdiff 1.48.