Internet Engineering Task Force (IETF) K. Gao
Request for Comments: 9569 Sichuan University
Category: Standards Track R. Schott
ISSN: 2070-1721 Deutsche Telekom
Y. R. Yang
L. Delwiche
L. Keller
Yale University
September 2024
"Application-Layer Traffic Optimization (ALTO) Protocol" (RFC 7285) leverages HTTP/1.1 and is designed for the simple, sequential request-reply use case, in which an ALTO client requests a sequence of information resources and the server responds with the complete content of each resource, one at a time.
「アプリケーションレイヤートラフィック最適化（ALTO）プロトコル」（RFC 7285）はHTTP/1.1を活用し、ALTOクライアントが一連の情報リソースを要求し、サーバーが対応するシンプルでシーケンシャルリクエスト対応のユースケース向けに設計されています。各リソースの完全なコンテンツは、一度に1つずつ。
RFC 8895, which describes ALTO incremental updates using Server-Sent Events (SSE), defines a multiplexing protocol on top of HTTP/1.x, so that an ALTO server can incrementally push resource updates to clients whenever monitored network information resources change, allowing the clients to monitor multiple resources at the same time. However, HTTP/2 and later versions already support concurrent, non-blocking transport of multiple streams in the same HTTP connection.
サーバーセントイベント（SSE）を使用したALTOの増分更新を説明するRFC 8895は、HTTP/1.xの上に多重化プロトコルを定義しているため、ALTOサーバーは監視されているネットワーク情報リソースの変更を課すたびにリソースの更新を徐々にプッシュできるようにします。複数のリソースを同時に監視するクライアント。ただし、HTTP/2以降のバージョンは、同じHTTP接続内の複数のストリームの同時の非ブロック輸送を既にサポートしています。
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 HTTP/2 or HTTP/3, while still functioning for HTTP/1.1.
新しいHTTP機能を活用するために、このドキュメントでは、ALTO Transport Information Publication Service（TIPS）を紹介します。TIPSは、インクリメンタルなRESTFULデザインを使用して、HTTP/2またはHTTP/3を使用して、ALTOクライアントに明示的かつ同時に（非ブロッキング方法で）特定のインクリメンタルアップデートを（またはプル）する新しい機能を提供しますが、HTTP/1.1で機能しています。。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9569.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9569で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
1.2. Notations
2. TIPS Overview
2.1. Transport Requirements
2.2. TIPS Terminology
3. TIPS Updates Graph
3.1. Basic Data Model of an Updates Graph
3.2. Updates Graph Modification Invariants
4. TIPS Workflow and Resource Location Schema
4.1. Workflow
4.2. Resource Location Schema
5. TIPS Information Resource Directory (IRD) Announcement
5.1. Media Type
5.2. Capabilities
5.3. Uses
5.4. An Example
6. TIPS Management
6.1. Open Request
6.2. Open Response
6.3. Open Example
6.3.1. Basic Example
6.3.2. Example Using Digest Authentication
6.3.3. Example Using ALTO/SSE
7. TIPS Data Transfers - Client Pull
7.1. Request
7.2. Response
7.3. Example
7.4. New Next Edge Recommendation
7.4.1. Request
7.4.2. Response
7.4.3. Example
8. Operation and Processing Considerations
8.1. Considerations for Load Balancing
8.2. Considerations for Cross-Resource Dependency Scheduling
8.3. Considerations for Managing Shared TIPS Views
8.4. Considerations for Offering Shortcut Incremental Updates
9. Security Considerations
9.1. TIPS: Denial-of-Service Attacks
9.2. ALTO Client: Update Overloading or Instability
10. IANA Considerations
10.1. application/alto-tips+json Media Type
10.2. application/alto-tipsparams+json Media Type
11. References
11.1. Normative References
11.2. Informative References
Appendix A. A High-Level Deployment Model
Appendix B. Conformance with "Building Protocols with HTTP" (RFC
9205) Best Current Practices
Appendix C. Push-Mode TIPS Using HTTP Server Push
Appendix D. Persistent HTTP Connections
Acknowledgments
Authors' Addresses
The Application-Layer Traffic Optimization (ALTO) protocol provides means for network applications to obtain network status information. So far, the ALTO information can be transported in two ways:
アプリケーション層トラフィック最適化（ALTO）プロトコルは、ネットワークアプリケーションがネットワークステータス情報を取得する手段を提供します。これまでのところ、ALTO情報は2つの方法で輸送できます。
1. Using the ALTO base protocol [RFC7285], which is designed for the simple use case in which an ALTO client requests a network information resource and the server sends the complete content of the requested information (if any) resource to the client.
1. ALTOベースプロトコル[RFC7285]を使用します。これは、ALTOクライアントがネットワーク情報リソースを要求し、サーバーが要求された情報（もしあれば）リソースの完全なコンテンツをクライアントに送信する単純なユースケース向けに設計されています。
2. Using ALTO incremental updates using Server-Sent Events (ALTO/ SSE) [RFC8895]; this method is designed for an ALTO client to indicate to the server that it wants to receive updates for a set of resources, and the server can then concurrently and incrementally push updates to that client whenever monitored resources change.
2. サーバーセントイベント（ALTO/ SSE）[RFC8895]を使用したALTOの増分更新を使用。このメソッドは、ALTOクライアントが一連のリソースの更新を受信したいことをサーバーに示すように設計されており、サーバーは監視されたリソースが変更されるたびに同時にそのクライアントに更新をプッシュすることができます。
Both protocols are designed for HTTP/1.1 [RFC9112]. While they still work with HTTP/2 [RFC9113] and HTTP/3 [RFC9114], ALTO and ALTO/SSE cannot take full advantage of new features offered by HTTP/2 and HTTP/3.
両方のプロトコルは、HTTP/1.1 [RFC9112]用に設計されています。彼らはまだHTTP/2 [RFC9113]およびHTTP/3 [RFC9114]で作業していますが、ALTOとALTO/SSEは、HTTP/2およびHTTP/3が提供する新機能を最大限に活用できません。
* First, consider the ALTO base protocol, which is designed to transfer only complete information resources. A client can run the base protocol on top of HTTP/2 or HTTP/3 to request multiple information resources in concurrent streams, but each request must be for a complete information resource: there is no capability for the server to transmit incremental updates. Hence, there can be a large overhead when the client already has an information resource and then there are small changes to the resource.
* まず、完全な情報リソースのみを転送するように設計されたALTOベースプロトコルを検討します。クライアントは、HTTP/2またはHTTP/3の上にベースプロトコルを実行して、同時ストリームで複数の情報リソースを要求することができますが、各要求は完全な情報リソースに対して必要です。サーバーが増分更新を送信する機能はありません。したがって、クライアントがすでに情報リソースを持っている場合、リソースに小さな変更がある場合、大きなオーバーヘッドがある可能性があります。
* Next, consider ALTO/SSE [RFC8895]. Although ALTO/SSE can transfer incremental updates, it introduces a customized multiplexing protocol on top of HTTP, assuming a total-order message channel from the server to the client. The multiplexing design does not provide naming (i.e., a resource identifier) to individual incremental updates. Such a design cannot use concurrent data streams available in HTTP/2 and HTTP/3 because both cases require a resource identifier. Additionally, ALTO/SSE is a push-only protocol, which denies the client flexibility in choosing how and when it receives updates.
* 次に、ALTO/SSE [RFC8895]を検討します。ALTO/SSEはインクリメンタルアップデートを転送できますが、サーバーからクライアントへの合計注文メッセージチャネルを想定して、HTTPの上にカスタマイズされた多重化プロトコルを導入します。多重化設計は、個々の増分更新に命名（つまり、リソース識別子）を提供しません。このような設計では、両方のケースがリソース識別子を必要とするため、HTTP/2およびHTTP/3で利用可能な同時データストリームを使用することはできません。さらに、ALTO/SSEはプッシュ専用プロトコルであり、アップデートを受信する方法と時期を選択する際のクライアントの柔軟性を否定します。
To mitigate these concerns, this document introduces a new ALTO service called the Transport Information Publication Service (TIPS). TIPS uses an incremental RESTful design to provide an ALTO client with a new capability to explicitly, concurrently issue non-blocking requests for specific incremental updates using HTTP/2 or HTTP/3, while still functioning for HTTP/1.1.
これらの懸念を軽減するために、このドキュメントでは、Transport Information Publations Service（TIPS）と呼ばれる新しいALTOサービスを紹介します。Tipsは、Incremental Restful Designを使用して、HTTP/1.1で機能している間、HTTP/2またはHTTP/3を使用して、特定の増分更新の非ブロッキング要求を明示的に、同時に発行する新しい機能をALTOクライアントに提供します。
While both ALTO/SSE [RFC8895] and TIPS can transport incremental updates of ALTO information resources to clients, they have different design goals. The TIPS extension enables more scalable and robust distribution of incremental updates but is missing the session management and built-in server push capabilities of ALTO/SSE. From the performance perspective, TIPS is optimizing throughput by leveraging concurrent and out-of-order transport of data, while ALTO/ SSE is optimizing latency as new events can be immediately transferred to the clients without waiting for another round of communication when there are multiple updates. Thus, we do not see TIPS as a replacement for ALTO/SSE, but as a complement to it. One example of combining these two extensions is shown in Section 6.3.3.
ALTO/SSE [RFC8895]とヒントの両方で、ALTO情報リソースのインクリメンタル更新をクライアントに輸送できますが、設計目標は異なります。TIPS拡張機能により、よりスケーラブルで堅牢な分布が増分更新を可能にしますが、ALTO/SSEのセッション管理と組み込みのサーバープッシュ機能が欠落しています。パフォーマンスの観点から見ると、ヒントはデータの同時輸送と秩序外の輸送を活用することによりスループットを最適化しますが、ALTO/ SSEは、複数の通信ラウンドを待つことなく、新しいイベントをすぐにクライアントに転送できるため、レイテンシを最適化しています。更新。したがって、ヒントはAlto/SSEの代替品としてではなく、それを補完するものとして見ています。これら2つの拡張機能を組み合わせる1つの例をセクション6.3.3に示します。
Note that future extensions may leverage server push, a feature of HTTP/2 [RFC9113] and HTTP/3 [RFC9114], as an alternative of SSE. We discuss why this alternative design is not ready at the time of writing in Appendix C.
将来の拡張機能は、SSEの代替として、HTTP/2 [RFC9113]およびHTTP/3 [RFC9114]の機能であるサーバープッシュを活用する可能性があることに注意してください。付録Cの執筆時点で、この代替設計が準備ができていない理由について説明します。
Specifically, this document specifies:
具体的には、このドキュメントは以下を指定します。
* Extensions to the ALTO Protocol for dynamic subscription and efficient uniform update delivery of an incrementally changing network information resource.
* 動的なサブスクリプションのためのALTOプロトコルへの拡張と、段階的に変更されるネットワーク情報リソースの効率的な均一な更新配信。
* A new resource type that indicates the TIPS updates graph model for a resource.
* TIPSを示す新しいリソースタイプは、リソースのグラフモデルを更新します。
* URI patterns to fetch the snapshots or incremental updates.
* スナップショットまたはインクリメンタル更新を取得するためのURIパターン。
Some operational complexities that must be taken into consideration when implementing this extension are discussed in Section 8: these include load balancing in Section 8.1 and fetching and processing incremental updates of dependent resources in Section 8.2.
この拡張機能を実装する際に考慮しなければならないいくつかの運用上の複雑さについては、セクション8で説明します。これらには、セクション8.1での負荷分散、およびセクション8.2の従属リソースのインクリメンタル更新の取得と処理が含まれます。
Appendix B discusses to what extent the TIPS design adheres to the best current practices for building protocols with HTTP [RFC9205].
付録Bでは、TIPSデザインがHTTP [RFC9205]を使用してプロトコルを構築するための最良の現在のプラクティスにどの程度順守するかについて説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document uses the same syntax and notations as introduced in Section 8.2 of [RFC7285] to specify the extensions to existing ALTO resources and services.
このドキュメントでは、[RFC7285]のセクション8.2で導入された同じ構文と表記を使用して、既存のALTOリソースとサービスの拡張を指定します。
The ALTO Protocol and its extensions support two transport mechanisms:
ALTOプロトコルとその拡張は、2つの輸送メカニズムをサポートしています。
1. A client can directly request an ALTO resource and obtain a complete snapshot of that ALTO resource, as specified in the base protocol [RFC7285];
1. クライアントは、Base Protocol [RFC7285]で指定されているように、ALTOリソースを直接リクエストし、そのALTOリソースの完全なスナップショットを取得できます。
2. A client can subscribe to incremental changes of one or multiple ALTO resources using the incremental update extension [RFC8895], and a server pushes the updates to the client through SSE.
2. クライアントは、インクリメンタルアップデートエクステンション[RFC8895]を使用して、1つまたは複数のALTOリソースの増分変更をサブスクライブでき、サーバーはSSEを介してアップデートをクライアントにプッシュします。
However, the current transport mechanisms are not optimized for storing, transmitting, and processing (incremental) updates of ALTO information resources. Specifically, the new transport mechanism must satisfy the following requirements:
ただし、現在の輸送メカニズムは、ALTO情報リソースの保存、送信、および処理（増分）の更新に最適化されていません。具体的には、新しい輸送メカニズムは次の要件を満たす必要があります。
Incremental updates:
増分更新：
Incremental updates only maintain and transfer the "diff" upon changes. Thus, it is more efficient than storing and transferring the full updates, especially when the change of an ALTO resource is minor. The base protocol does not support incremental updates and the current incremental update mechanism in [RFC8895] has limitations (as discussed below).
増分更新は、変更時に「DIFF」を維持および転送するだけです。したがって、特にALTOリソースの変更がマイナーである場合、完全な更新を保存および転送するよりも効率的です。基本プロトコルは増分更新をサポートせず、[RFC8895]の現在の増分更新メカニズムには制限があります（以下で説明します）。
Concurrent, non-blocking update transmission:
同時、非ブロッキング更新伝送：
When a client needs to receive and apply multiple incremental updates, it is desired to transmit the updates concurrently to fully utilize the bandwidth and to reduce head-of-line blocking. Unfortunately, the ALTO incremental update extension [RFC8895] does not satisfy this requirement. Even though the updates can be multiplexed by the server to avoid head-of-line blocking between multiple resources, the updates are delivered sequentially and can suffer from head-of-line blocking inside the connection (for example, when there is a packet loss).
クライアントが複数の増分アップデートを受信して適用する必要がある場合、帯域幅を完全に利用して頭のブロックを減らすために、更新を同時に送信することが望まれます。残念ながら、ALTOの増分更新拡張機能[RFC8895]はこの要件を満たしていません。複数のリソース間の頭のブロッキングを回避するために、更新をサーバーによって多重化できますが、更新は順次配信され、接続内の頭のブロックに苦しむ可能性があります（たとえば、パケット損失がある場合の場合）。
Long polling updates:
長い投票の更新：
Long polling updates can reduce the time to send the request, making it possible to achieve sub-RTT transmission of ALTO incremental updates. In [RFC8895], this requirement is fulfilled using SSE and is still desired in the new ALTO transport.
長い投票の更新により、リクエストを送信する時間を短縮し、ALTOの増分更新のサブRTT伝送を実現することが可能になります。[RFC8895]では、この要件はSSEを使用して満たされており、新しいALTOトランスポートで依然として望まれています。
Backward compatibility:
後方互換性：
While some of the previous requirements are offered by HTTP/2 [RFC9113] and HTTP/3 [RFC9114], it is desired that the new ALTO transport mechanism can work with HTTP/1.1 as many development tools and current ALTO implementations are based on HTTP/1.1.
以前の要件の一部はHTTP/2 [RFC9113]およびHTTP/3 [RFC9114]によって提供されますが、新しいALTOトランスポートメカニズムはHTTP/1.1で機能し、多くの開発ツールと現在のALTOの実装がHTTPに基づいているため、HTTP/1.1で動作することが望まれます。/1.1。
The new ALTO transport specified in this document satisfies all of the following design requirements above by:
このドキュメントで指定されている新しいアルトトランスポートは、上記のすべての設計要件を次のように満たします。
* Reusing the data format introduced in [RFC8895] that enables incremental updates using JSON patches or merge patches.
* [RFC8895]で導入されたデータ形式を再利用すると、JSONパッチまたはマージパッチを使用した増分更新が可能になります。
* 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.
* 「ヒントビュー」と呼ばれるALTOリソースの変更（スナップショットと増分更新）を記述するための統一データモデルを導入します。データモデルでは、スナップショットと増分更新は、HTTPバージョンとは無関係に、統一された命名規則に続いて個々のHTTPリソースとしてインデックス化されています。したがって、これらの更新は、複数の接続を使用するか、HTTP/2または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.
* 単調に増加するシーケンス数に基づいて統一された命名規則に基づいて、クライアントが将来の更新のURLを構築し、長いポーリングリクエストを送信することを可能にします。
* Making the unified naming convention independent of the HTTP versions and able to operate atop HTTP/1.1, HTTP/2, or HTTP/3.
* HTTPバージョンから独立して統一された命名条約を作成し、HTTP/1.1、HTTP/2、またはHTTP/3の上で動作させることができます。
This document assumes the deployment model discussed in Appendix A.
このドキュメントでは、付録Aで説明した展開モデルを想定しています。
In addition to the terms defined in [RFC7285], this document uses the following terms:
[RFC7285]で定義されている用語に加えて、このドキュメントでは次の用語を使用しています。
Transport Information Publication Service (TIPS):
輸送情報出版サービス（ヒント）：
A new type of ALTO service, as specified in this document, to enable a uniform transport mechanism for updates of an incrementally changing ALTO network information resource.
このドキュメントで指定されているように、新しいタイプのALTOサービスは、ALTOネットワーク情報リソースを段階的に更新するための均一な輸送メカニズムを可能にします。
Network information resource:
ネットワーク情報リソース：
A piece of retrievable information about network state, per [RFC7285].
[RFC7285]ごとに、ネットワーク状態に関する取得可能な情報。
TIPS view (tv):
ヒントビュー（テレビ）：
The container of incremental transport information about the network information resource. The TIPS view has one basic component, the updates graph (ug), but may include other transport information.
ネットワーク情報リソースに関する増分輸送情報のコンテナ。ヒントビューには、1つの基本的なコンポーネント、更新グラフ（ug）がありますが、他の輸送情報が含まれる場合があります。
Updates graph (ug):
グラフを更新（UG）：
A directed, acyclic graph whose nodes represent the set of versions of an information resource and whose edges represent the set of update items to compute these versions. An ALTO map service (e.g., a cost map or a network map) may need only a single updates 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 request. The encoding of an updates graph is specified in Section 6.1.
ノードが情報リソースのバージョンのセットを表し、エッジがこれらのバージョンを計算するための更新項目のセットを表す指向的な非環式グラフ。ALTOマップサービス（コストマップやネットワークマップなど）には、単一の更新グラフのみが必要になる場合があります。ダイナミックネットワーク情報サービス（たとえば、フィルタリングされたコストマップなど）は、一意の要求ごとに更新グラフ（新しいヒントビュー内）を作成する場合があります。更新グラフのエンコードは、セクション6.1で指定されています。
Version:
バージョン：
The representation of a historical content of an information resource. For an information resource, each version is associated with and uniquely identified by a monotonically and consecutively increased sequence number. This document uses the term "version s" to refer to the version associated with sequence number "s". The version is encoded as a JSONNumber, as specified in Section 6.1.
情報リソースの歴史的な内容の表現。情報リソースの場合、各バージョンは、シーケンス数を単調におよび連続的に増加させたものに関連付けられ、一意に識別されます。このドキュメントでは、「バージョンs」という用語を使用して、シーケンス番号「s」に関連付けられたバージョンを参照しています。このバージョンは、セクション6.1で指定されているように、jsonnumberとしてエンコードされています。
Start sequence number (<start-seq>):
シーケンス番号を開始（<start-seq>）：
The smallest non-zero sequence number in an updates graph.
更新グラフの最小の非ゼロシーケンス番号。
End sequence number (<end-seq>):
終了シーケンス番号（<End-seq>）：
The largest sequence number in an updates graph.
更新グラフの最大のシーケンス番号。
Snapshot:
スナップショット：
A full replacement of a resource that is contained within an updates graph.
更新グラフに含まれるリソースの完全な交換。
Incremental update:
増分更新：
A partial replacement of a resource contained within an updates graph, codified in this document as a JSON merge patch or a JSON patch. 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). Mandatory incremental updates are always in an updates graph, while optional/shortcut incremental updates may or may not be included in an updates graph.
このドキュメントでJSONマージパッチまたはJSONパッチとして成文化された更新グラフに含まれるリソースの部分的な置換。ソースバージョン（i）とターゲットバージョン（j）が連続している場合（つまり、i + 1 = j）、増分更新が必須です。それ以外の場合は、オプション（またはショートカット）です。必須のインクリメンタル更新は常に更新グラフにありますが、オプション/ショートカットの増分更新は更新グラフに含まれている場合と含まれない場合があります。
Update item:
更新項目：
The content on an edge of the updates graph, which can be either a snapshot or an incremental update. An update item can be considered to be a pair (op, data) where op denotes whether the item is an incremental update or a snapshot and data is the content of the item.
更新グラフの端にあるコンテンツは、スナップショットまたは増分更新のいずれかです。更新項目は、アイテムがインクリメンタルアップデートであるかスナップショットであり、データがアイテムのコンテンツであるかを示すペア（OP、データ）と見なすことができます。
ID#i-#j:
ID＃i-＃j：
Denotation of the update item on a specific edge in the updates graph to transition from version i to version j, where i and j are the sequence numbers of the source node and the target node of the edge, respectively.
更新グラフの特定のエッジでの更新項目の表示は、バージョンIからバージョンJに移行するために、IとJはソースノードのシーケンス番号とエッジのターゲットノードです。
+-------------+
+-----------+ +--------------+ | Dynamic | +-----------+
| Routing | | Provisioning | | Network | | External |
| Protocols | | Policy | | Information | | Interface |
+-----------+ +--------------+ +-------------+ +-----------+
| | | |
+-----------------------------------------------------------------+
| ALTO Server |
| +-------------------------------------------------------------+ |
| | Network Information | |
| | +-------------+ +-------------+ | |
| | | Information | | Information | | |
| | | Resource #1 | | Resource #2 | | |
| | +-------------+ +-------------+ | |
| +-----|--------------------------------------/-------\--------+ |
| | / \ |
| +-----|------------------------------------/-----------\------+ |
| | | Transport Information / \ | |
| | +--------+ +--------+ +--------+ | |
| | | tv1 | | tv2 | | tv3 | | |
| | +--------+ +--------+ +--------+ | |
| | | / | | |
| | +--------+ +--------+ +--------+ | |
| | | tv1/ug | | tv2/ug | | tv3/ug | | |
| | +--------+ +--------+ +--------+ | |
| +----|----\----------------|-------------------------|--------+ |
| | \ | | |
+------|------\--------------|-------------------------|----------+
| +------+ | |
| \ | |
+----------+ +----------+ +----------+
| Client 1 | | Client 2 | | Client 3 |
+----------+ +----------+ +----------+
tvi = TIPS view i
tvi/ug = incremental updates graph associated with tvi
Figure 1: Overview of ALTO TIPS
図1：アルトのヒントの概要
Figure 1 shows an example illustrating an overview of the ALTO TIPS extension. The server provides TIPS for two information resources (#1 and #2) where #1 is an ALTO map service and #2 is a filterable service. There are three ALTO clients (Client 1, Client 2, and Client 3) that are connected to the ALTO server.
図1は、ALTO TIPS拡張の概要を示す例を示しています。サーバーは、2つの情報リソース（＃1と＃2）のヒントを提供します。ここで、＃1はALTOマップサービスであり、＃2はフィルター可能なサービスです。ALTOサーバーに接続されている3つのALTOクライアント（クライアント1、クライアント2、およびクライアント3）があります。
Each client uses the TIPS view to retrieve updates. Specifically, a TIPS view (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 upon different client requests with different filter sets.
各クライアントは、ヒントビューを使用して更新を取得します。具体的には、マップサービス＃1用のヒントビュー（TV1）が作成され、複数のクライアントが共有しています。フィルタリングサービス＃2の場合、異なるフィルターセットを使用して、異なるクライアントリクエストで2つの異なるヒントビュー（TV2とTV3）が作成されます。
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 incremental updates and snapshots (collectively called "update items") of a network information resource.
リソースのインクリメンタル更新を提供するために、ALTOサーバーは更新グラフを作成します。これは、ネットワーク情報リソースの一連の増分更新とスナップショット（総称する「更新項目」と呼ばれる）を含む指向的な非環式グラフです。
For each resource (e.g., a cost map or a network map), the incremental updates and snapshots can be represented using the following directed acyclic graph model, where the server tracks the change of the resource maps with version IDs that are assigned sequentially (i.e., incremented by one each time):
各リソース（コストマップまたはネットワークマップなど）について、増分更新とスナップショットは、次の指向の透析グラフモデルを使用して表現できます。ここで、サーバーはリソースマップの変更をシーケンシャルに割り当てられたバージョンIDで追跡します（つまり、、毎回1つずつ増加します）：
* Each node in the graph is a version of the resource, which is identified by a sequence number (defined as a JSONNumber). Version 0 is reserved as the initial state (empty/null).
* グラフ内の各ノードはリソースのバージョンで、シーケンス番号（jsonnumberとして定義）で識別されます。バージョン0は、初期状態（空/null）として予約されています。
* A tag identifies the content of a node. A tag has the same format as the "tag" field in Section 10.3 of [RFC7285] and is valid only within the scope of the resource.
* タグは、ノードのコンテンツを識別します。タグは、[RFC7285]のセクション10.3の「タグ」フィールドと同じ形式を持ち、リソースの範囲内でのみ有効です。
* Each edge is an update item. In particular, the edge from i to j is the update item to transit from version i to version j.
* 各エッジは更新アイテムです。特に、IからJへのエッジは、バージョンIからバージョンJへのトランジットの更新項目です。
* The version is path independent, i.e., different paths arriving at the node associated with the same version have the same content.
* バージョンはPath Independentです。つまり、同じバージョンに関連付けられているノードに到着するさまざまなパスが同じコンテンツを持っています。
A concrete example is shown in Figure 2. There are seven nodes in the graph, representing seven different versions of the resource. Edges in the figure represent the updates from the source version to the target version. Thick lines represent mandatory incremental updates (e.g., ID103-104), dotted lines represent optional incremental updates (e.g., ID103-105), and thin lines represent snapshots (e.g., ID0-103). Note that node content is path independent: the content of node v can be obtained by applying the updates from any path that ends at v. For example, assume the latest version is 105 and a client already has version 103. The base version of the client is 103 as it serves as a base upon which incremental updates can be applied.
具体的な例を図2に示します。グラフには7つのノードがあり、リソースの7つの異なるバージョンを表しています。図のエッジは、ソースバージョンからターゲットバージョンへの更新を表しています。厚い線は、必須の増分更新（例：ID103-104）を表し、点線はオプションの増分更新（例：ID103-105）を表し、薄い線はスナップショット（例：ID0-103）を表します。ノードコンテンツはパスに依存しないことに注意してください：ノードVのコンテンツは、vで終了する任意のパスから更新を適用することで取得できます。たとえば、最新バージョンは105であり、クライアントはすでにバージョン103を持っていると仮定します。クライアントは、増分更新を適用できるベースとして機能するため、103です。
The target version 105 can be:
ターゲットバージョン105は次のとおりです。
* directly fetched as a snapshot;
* スナップショットとして直接フェッチします。
* computed incrementally by applying the incremental updates between 103 and 104, then 104 and 105; or,
* 103から104の間の増分更新を適用し、104と105の間に刻み目に計算しました。または、
* computed incrementally by taking the "shortcut" path from 103 to 105 if the optional update from 103 to 105 exists.
* 103から105までのオプションの更新が存在する場合、103から105に「ショートカット」パスを取得して段階的に計算します。
+======+
------| 0 |
/ +======+
ID0-101 / | |
|/__ | |
+======+ | |
tag: 3421097 -> | 101 | | |
+======+ | |
ID101-102 || | |
\/ | |
+======+ | |
tag: 6431234 -> | 102 | | |
+======+ | |
ID102-103 || | |
\/ | |
+======+ / |
+--------------+ tag: 0881080 -> | 103 |<--------/ |
| Base Version | =======> +======+ ID0-103 |
+--------------+ 103-104 || .. |
\/ .. |
+======+ .. |
tag: 6452654 -> | 104 | .. ID103 |
+======+ .. -105 |
ID104-105 || .. | ID0-105
\/ |._ /
+======+ /
tag: 7838392 -> | 105 |<-----------/
+======+
ID105-106 ||
\/
+======+
tag: 6470983 -> | 106 |
+======+
Figure 2: TIPS Model Example
図2：ヒントモデルの例
A server might change its updates graph (to compact it, to add nodes, etc.), but it will need to ensure that any resource state that it makes available is reachable by clients, either directly via a snapshot (that is, relative to 0) or indirectly by requesting an earlier snapshot and a contiguous set of incremental updates. Additionally, to allow clients to proactively construct URIs for future update items, the ID of each added node in the updates graph will need to increment contiguously by 1. More specifically, the updates graph MUST satisfy the following invariants:
サーバーは更新グラフを変更する可能性があります（コンパクトするには、ノードなどを追加するなど）が、それが利用可能になるリソースの状態が、スナップショットを介して直接クライアントが到達できるようにする必要があります（つまり、つまり、0）または、以前のスナップショットと隣接する増分更新セットを要求することにより間接的に。さらに、クライアントが将来の更新項目のためにURIを積極的に構築できるようにするために、更新グラフに追加された各ノードのIDは、1によって連続的にインクリメントする必要があります。
Continuity:
連続：
At any time, let ns denote the smallest non-zero 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 MUST also exist. This implies that the incremental update from ni to ni + 1 exists for any ns <= ni <= ne, and all the version numbers in the updates graph (except 0) constitute exactly the integer interval [ns, ne].
いつでも、NSが更新グラフの最小の非ゼロバージョン（つまり、<Start-Seq>）を示し、最新バージョン（つまり、<End-seq>）を示します。次に、NSとNEの間にあるバージョンも存在する必要があります。これは、NS <= ni <= neに対してNiからNi + 1からNi + 1の増分更新が存在し、更新グラフ（0を除く）のすべてのバージョン番号が正確に整数間隔[NS、NE]を構成することを意味します。
Feasibility:
実現可能性：
Let ns denote <start-seq> in the updates graph. The server MUST provide a snapshot of ns; in other words, there is always a direct link to ns in the updates graph.
nsは、更新グラフで<start-seq>を示します。サーバーは、NSのスナップショットを提供する必要があります。言い換えれば、更新グラフには常にNSへの直接リンクがあります。
"Right shift" only:
「正しいシフト」のみ：
Assume a server provides versions in [n1, n2] at time t and versions in [n1', n2'] at time t'. If t' > t, then n1' >= n1 and n2' >= n2.
サーバーが[n1、n2]のバージョンを時刻tに提供し、[n1 '、n2']のバージョンを時刻t 'で提供していると仮定します。t '> tの場合、n1'> = n1およびn2 '> = n2。
For example, consider the case that a server compacts a resource's updates graph to conserve space, using the example model in Section 3.1. Assume at time 0, the server provides the versions {101, 102, 103, 104, 105, 106}. At time 1, both {103, 104, 105, 106} and {105, 106} are valid sets. However, {102, 103, 104, 105, 106} and {104, 105, 106} are not valid sets as there is no 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 example) cannot be obtained by a client that does not have the previous version 101 or 103, respectively.
たとえば、セクション3.1のサンプルモデルを使用して、サーバーがリソースの更新グラフをコンパクトしてスペースを保護する場合を検討してください。時間0で、サーバーはバージョン{101、102、103、104、105、106}を提供すると仮定します。時間1では、{103、104、105、106}と{105、106}の両方が有効なセットです。ただし、{102、103、105、106}および{104、105、106}は、更新グラフにバージョン102または104にスナップショットがないため、有効なセットではありません。したがって、以前のバージョン101または103をそれぞれ持っていないクライアントが、バージョン102（最初の例）または104（2番目の例で）の適切なコンテンツを取得できないというリスクがあります。
At a high level, an ALTO client first requests the TIPS information resource (denoted as TIPS-F, 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 that contains a URI, which points to the root of a TIPS view (denoted as TIPS-V), and a summary of the current view, which contains the information to correctly interact with the current view. With the URI to the root of a TIPS view, clients can construct URIs (see Section 4.2) to fetch incremental updates.
高レベルでは、ALTOクライアントは、最初に、クライアントが監視したい情報リソースまたはリソースを示すために、ヒント情報リソース（FORTEND用のヒントFとして表される）を要求します。要求されたリソースごとに、サーバーは、チップビューのルート（TIPS-Vと表される）のルートを指すURIを含むJSONオブジェクトと、現在のビューの要約を返します。現在のビュー。URIがヒントビューのルートにあるため、クライアントはURIを構築し（セクション4.2を参照）、増分更新を取得できます。
An example workflow is shown in Figure 3. After the TIPS-F receives the request from the client to monitor the updates of an ALTO resource, it creates a TIPS view resource and returns the corresponding 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 updates graph and a server-recommended edge to consume first (e.g., from i to j).
ワークフローの例を図3に示します。TIPS-Fがクライアントからリクエストを受信してALTOリソースの更新を監視した後、ヒントビューリソースを作成し、対応する情報をクライアントに返します。URIは、その特定のTIPS-Vインスタンスを指しており、要約には、更新グラフの<Start-Seq>と<End-seq>と、最初に消費するサーバーが推奨するエッジが含まれています（例：IからJまで）。
An ALTO client can then continuously pull each additional update with the information. For example, the client in Figure 3 first fetches the update from i to j and then from j to j+1. Note that the update item at "<tips-view-uri>/ug/<j>/<j+1>" might not yet exist, so the server holds the request until the update becomes available (i.e., long polling).
ALTOクライアントは、情報を使用して追加の更新を継続的に引き出すことができます。たとえば、図3のクライアントは、最初にIからJからJ、次にJからJ+1に更新を取得します。「<tips-view-uri>/ug/<j>/<j+1>」の更新項目はまだ存在しない可能性があるため、更新が利用可能になるまでサーバーが要求を保持していることに注意してください（つまり、長い投票）。
A server MAY close a TIPS view at any time (e.g., under high system load or due to client inactivity). In the event that a TIPS view is closed, an edge request will receive error code 404 (Not Found) in response, and the client will have to request a new TIPS view URI.
サーバーは、いつでもヒントビューを閉じることができます（たとえば、システム負荷が高い、またはクライアントの非活動により）。ヒントビューが閉じられている場合、エッジリクエストはそれに応じてエラーコード404（見つかりません）を受信し、クライアントはURIの新しいヒントビューを要求する必要があります。
If resources allow, a server SHOULD avoid closing TIPS views that have active polling edge requests or have recently served responses until clients have had a reasonable interval to request the next update, unless guided by specific control policies.
リソースが許可されている場合、サーバーは、アクティブなポーリングエッジ要求を備えたヒントビューを閉じるか、最近、特定の制御ポリシーに導かれない限り、クライアントが次のアップデートをリクエストする合理的なインターバルがあるまで応答を提供したことを避ける必要があります。
Client TIPS-F TIPS-V
o . .
| POST to create/receive a TIPS view . Create TIPS .
| for resource 1 . View .
|-------------------------------------> |.-.-.-.-.-.-.-> |
| <tips-view-uri>, <tips-view-summary> . |
| <-------------------------------------| <-.-.-.-.-.-.-.|
| .
| GET /<tips-view-path>/ug/<i>/<j> .
|------------------------------------------------------> |
| content on edge i to j |
| <------------------------------------------------------|
| .
| GET /<tips-view-path>/ug/<j>/<j+1> .
|------------------------------------------------------> |
. .
. .
| content on edge j to j+1 |
| <------------------------------------------------------|
| .
o .
.
TIPS View Closed o
Figure 3: ALTO TIPS Workflow Supporting Client Pull
図3：クライアントプルをサポートするアルトのヒントワークフロー
The resource location schema defines how a client constructs URIs to fetch incremental updates.
リソースロケーションスキーマは、クライアントがURIを構築して増分更新を取得する方法を定義します。
To access each update in an updates graph, consider the model represented as a "virtual" file system (adjacency list), contained within the root of a TIPS view URI (see Section 6.2 for the definition of tips-view-uri). For example, assuming that the updates graph of a TIPS view is as shown in Figure 2, the location schema of this TIPS view will have the format as in Figure 4.
更新グラフで各更新にアクセスするには、ヒントビューURIのルート内に含まれる「仮想」ファイルシステム（隣接リスト）として表されるモデルを検討してください（ヒント-View-URIの定義についてはセクション6.2を参照）。たとえば、ヒントビューの更新グラフが図2に示すとおりであると仮定すると、このヒントビューの位置スキーマには、図4のように形式があります。
<tips-view-path> // root path to a TIPS view
|_ ug // updates graph
| |_ 0
| | |_ 101 // full 101 snapshot
| | |_ 103
| | \_ 105
| |_ 101
| | \_ 102 // 101 -> 102 incremental update
| |_ 102
| | \_ 103
| |_ 103
| | |_ 104
| | \_ 105 // optional shortcut 103 -> 105 incr. update
| |_ 104
| | \_ 105
| \_ 105
| \_ 106
\_ ...
Figure 4: Location Schema Example
図4：ロケーションスキーマの例
TIPS uses this directory schema to generate template URIs that allow clients to construct the location of incremental updates after receiving the tips-view-uri from the server. The generic template for the location of the update item on the edge from node 'i' to node 'j' in the updates graph is:
TIPSは、このディレクトリスキーマを使用して、サーバーからTIPS-View-URIを受信した後、クライアントが増分更新の場所を構築できるようにするテンプレートURIを生成します。更新グラフのノード「I」からノード「J」への端にある更新項目の位置の一般的なテンプレートは次のとおりです。
<tips-view-uri>/ug/<i>/<j>
Due to the sequential nature of the update item IDs, a client can long poll a future update that does not yet exist (e.g., the incremental update from 106 to 107). This can be done by constructing the URI for the next edge that will be added, starting from the sequence number of the current last node (denoted as <end-seq>) in the graph to the next sequential node (with the sequence number of <end-seq + 1>):
更新アイテムIDの順番な性質により、クライアントはまだ存在しない将来の更新（たとえば、106から107までの増分更新など）を長期にわたって投票できます。これは、グラフ内の現在の最後のノード（<End-seq>として表）のシーケンス番号から次のシーケンシャルノード（シーケンス番号を使用して）のシーケンス番号から、追加される次のエッジのURIを構築することで実行できます。<end-seq + 1>）：
<tips-view-uri>/ug/<end-seq>/<end-seq + 1>
Incremental updates of a TIPS view are read-only. Thus, they are fetched using the HTTP GET method.
ヒントビューの増分更新は読み取り専用です。したがって、HTTP GETメソッドを使用してフェッチされます。
To announce a TIPS information resource in the IRD, an ALTO server MUST specify "media-type", "capabilities", and "uses" as follows.
IRDでヒント情報リソースを発表するには、ALTOサーバーは「メディアタイプ」、「機能」、および「使用」を次のように指定する必要があります。
The media type of the Transport Information Publication Service (TIPS) resource is "application/alto-tips+json".
Transport Information Publication Service（TIPS）リソースのメディアタイプは「Application/Alto-Tips+JSON」です。
The "capabilities" field of a TIPS information resource is modeled on that defined in Section 6.3 of [RFC8895].
TIPS情報リソースの「機能」フィールドは、[RFC8895]のセクション6.3で定義されているものでモデル化されています。
Specifically, the capabilities are defined as an object of the TIPSCapabilities type:
具体的には、機能はTIPSCAPABILISTYタイプのオブジェクトとして定義されます。
object {
IncrementalUpdateMediaTypes incremental-change-media-types;
} TIPSCapabilities;
object-map {
ResourceID -> String;
} IncrementalUpdateMediaTypes;
Figure 5: TIPSCapabilities
図5：Tipscapability
with the field:
フィールドで：
incremental-change-media-types:
Incremental-Change-Media-Types：
If a TIPS information resource can provide updates with incremental changes for a resource, the "incremental-change-media-types" field has an entry whose key is the ID of the resource and the value is the supported media types of incremental changes, separated by commas. For the implementation of this specification, this MUST be "application/ merge-patch+json", "application/json-patch+json", or "application/ merge-patch+json,application/json-patch+json", unless defined by a future extension.
ヒント情報リソースがリソースの増分変更でアップデートを提供できる場合、「インクリメンタルチェンジメディアタイプ」フィールドには、リソースのIDであり、値はサポートされているメディアタイプの増分変更のエントリがあり、分離されています。コンマによって。この仕様を実装するには、これは「アプリケーション/マージパッチ+json」、「アプリケーション/ jsonパッチ+json」、または「アプリケーション/マージパッチ+json、アプリケーション/ json-パッチ+json」でなければなりません。将来の拡張機能によって定義されます。
When choosing the media types to encode incremental updates for a resource, the server MUST consider the limitations of the encoding. For example, when a JSON merge patch specifies that the value of a field is null, its semantics are that the field is removed from the target; hence, the field is no longer defined (i.e., undefined). However, this may not be the intended result for the resource, when null and undefined have different semantics for the resource. In such a case, the server MUST choose JSON patch encoding over JSON merge patch encoding for the incremental update if both media types "application/json-patch+json" and "application/merge-patch" are supported by the TIPS information resource.
メディアタイプを選択してリソースの増分更新をエンコードする場合、サーバーはエンコードの制限を考慮する必要があります。たとえば、JSONマージパッチがフィールドの値がnullであることを指定すると、そのセマンティクスはフィールドがターゲットから削除されるということです。したがって、フィールドはもはや定義されていません（つまり、未定義です）。ただし、これは、Nullと未定義のリソースのセマンティクスが異なる場合、リソースの意図された結果ではない場合があります。このような場合、サーバーは、両方のメディアタイプ「Application/JSON-Patch+JSON」と「Application/Merge-Patch」がTIPS情報リソースによってサポートされている場合、インクリメンタルアップデートのJSONマージパッチをエンコードするJSONパッチを選択する必要があります。
The "uses" attribute MUST be an array with the resource IDs of every network information resource for which this TIPS information resource can provide service.
「使用」属性は、このヒント情報リソースがサービスを提供できるすべてのネットワーク情報リソースのリソースIDを備えた配列でなければなりません。
This set MAY be any subset of the ALTO server's network information resources and MAY include resources defined in linked IRDs. However, it is RECOMMENDED that the ALTO server selects a set that is closed under the resource dependency relationship. That is, if a TIPS information resource's "uses" set includes resource R1, and resource R1 depends on ("uses") resource R0, then the "uses" set should include R0 as well as R1. For example, if a TIPS information resource provides a TIPS view for a cost map, it should also provide a TIPS view for the network map upon which that cost map depends.
このセットは、ALTOサーバーのネットワーク情報リソースの任意のサブセットである可能性があり、リンクされたIRDで定義されたリソースが含まれる場合があります。ただし、ALTOサーバーは、リソース依存関係の関係で閉じられているセットを選択することをお勧めします。つまり、TIPS情報リソースの「使用」セットにリソースR1が含まれ、リソースR1が（「使用」）リソースR0に依存する場合、「使用」セットにはR0とR1を含む必要があります。たとえば、ヒント情報リソースがコストマップのヒントビューを提供する場合、コストマップが依存するネットワークマップのヒントビューも提供する必要があります。
If the set is not closed, at least one resource R1 in the "uses" field of a TIPS information resource depends on another resource R0 that is not in the "uses" field of the same TIPS information resource. Thus, a client cannot receive incremental updates for another resource R0 that is not in the "uses" field of the same TIPS information resource. If the client observes in an update of R1 that the version tag for R0 has changed, it must request the full content of R0, which is likely to be less efficient than receiving the incremental updates of R0.
セットが閉じていない場合、ヒント情報リソースの「使用」フィールドの少なくとも1つのリソースR1は、同じヒント情報リソースの「使用」フィールドにない別のリソースR0に依存します。したがって、クライアントは、同じヒント情報リソースの「使用」フィールドにない別のリソースR0の増分更新を受信できません。クライアントがR1の更新でR0のバージョンタグが変更されたことを観察した場合、R0の完全な内容を要求する必要があります。
Extending the IRD example in Section 8.1 of [RFC8895], Figure 6 is the IRD of an ALTO server supporting the ALTO base protocol, ALTO/ SSE, and ALTO TIPS.
[RFC8895]のセクション8.1でIRDの例を拡張すると、図6は、ALTOベースプロトコル、ALTO/ SSE、およびALTOのヒントをサポートするALTOサーバーのIRDです。
"my-network-map": {
"uri": "https://alto.example.com/networkmap",
"media-type": "application/alto-networkmap+json"
},
"my-routingcost-map": {
"uri": "https://alto.example.com/costmap/routingcost",
"media-type": "application/alto-costmap+json",
"uses": ["my-network-map"],
"capabilities": {
"cost-type-names": ["num-routingcost"]
}
},
"my-hopcount-map": {
"uri": "https://alto.example.com/costmap/hopcount",
"media-type": "application/alto-costmap+json",
"uses": ["my-network-map"],
"capabilities": {
"cost-type-names": ["num-hopcount"]
}
},
"my-simple-filtered-cost-map": {
"uri": "https://alto.example.com/costmap/filtered/simple",
"media-type": "application/alto-costmap+json",
"accepts": "application/alto-costmapfilter+json",
"uses": ["my-network-map"],
"capabilities": {
"cost-type-names": ["num-routingcost", "num-hopcount"],
"cost-constraints": false
}
},
"update-my-costs": {
"uri": "https://alto.example.com/updates/costs",
"media-type": "text/event-stream",
"accepts": "application/alto-updatestreamparams+json",
"uses": [
"my-network-map",
"my-routingcost-map",
"my-hopcount-map",
"my-simple-filtered-cost-map"
],
"capabilities": {
"incremental-change-media-types": {
"my-network-map": "application/json-patch+json",
"my-routingcost-map": "application/merge-patch+json",
"my-hopcount-map": "application/merge-patch+json"
},
"support-stream-control": true
}
},
"update-my-costs-tips": {
"uri": "https://alto.example.com/updates-new/costs",
"media-type": "application/alto-tips+json",
"accepts": "application/alto-tipsparams+json",
"uses": [
"my-network-map",
"my-routingcost-map",
"my-hopcount-map",
"my-simple-filtered-cost-map"
],
"capabilities": {
"incremental-change-media-types": {
"my-network-map": "application/json-patch+json",
"my-routingcost-map": "application/merge-patch+json",
"my-hopcount-map": "application/merge-patch+json",
"my-simple-filtered-cost-map": "application/merge-patch+json"
}
}
},
"tips-sse": {
"uri": "https://alto.example.com/updates/tips",
"media-type": "text/event-stream",
"accepts": "application/alto-updatestreamparams+json",
"uses": [ "update-my-costs-tips" ],
"capabilities": {
"incremental-change-media-types": {
"update-my-costs-tips": "application/merge-patch+json"
}
}
}
Figure 6: Example of an ALTO Server Supporting the ALTO Base Protocol, ALTO/SSE, and ALTO TIPS
図6：ALTOベースプロトコル、ALTO/SSE、およびALTOのヒントをサポートするALTOサーバーの例
Note that it is straightforward for an ALTO server to run HTTP/2 and support concurrent retrieval of multiple resources such as "my-network-map" and "my-routingcost-map" using multiple HTTP/2 streams.
ALTOサーバーがHTTP/2を実行し、複数のHTTP/2ストリームを使用して「My-Network-Map」や「My-RoutingCost-Map」などの複数のリソースの同時検索をサポートすることは簡単であることに注意してください。
The resource "update-my-costs-tips" provides an ALTO TIPS information resource, and this is indicated by the media type "application/alto-tips+json".
リソース「Update-My-Costs-Tips」は、ALTOのヒント情報リソースを提供します。これは、メディアタイプ「Application/Alto-Tips+JSON」で示されています。
Upon request, a server sends a TIPS view to a client. This TIPS view might be created at the time of the request or might already exist (either because another client has already created a TIPS view for the same requested network resource or because the server perpetually maintains a TIPS view for an often-requested resource).
リクエストに応じて、サーバーはクライアントにヒントビューを送信します。このヒントビューは、リクエストの時点で作成される可能性があるか、既に存在する可能性があります（別のクライアントが既に要求されたネットワークリソースのヒントビューを作成しているため、またはサーバーがしばしば要求されるリソースのヒントビューを永久に維持しているためです）。
An ALTO client requests that the server provide a TIPS view for a given resource by sending an HTTP POST body with the media type "application/alto-tipsparams+json". That body contains a JSON object of the TIPSReq type, where:
ALTOクライアントは、メディアタイプの「Application/Alto-Tipsparams+JSON」を使用してHTTPポスト本体を送信することにより、サーバーが特定のリソースのヒントビューを提供することを要求します。そのボディには、TipsReqタイプのJSONオブジェクトが含まれています。
object {
ResourceID resource-id;
[JSONString tag;]
[Object input;]
} TIPSReq;
Figure 7: TIPSReq
図7：Tipsreq
with the following fields:
次のフィールドで：
resource-id:
Resource-ID：
This field contains the resource ID of an ALTO resource to be monitored, which MUST be in the TIPS information resource's "uses" list (Section 5). If a client does not support all incremental methods from the set announced in the server's capabilities, the client MUST NOT use the TIPS information resource.
このフィールドには、監視対象のALTOリソースのリソースIDが含まれています。これは、情報リソースの「使用」リスト（セクション5）にある必要があります。クライアントがサーバーの機能で発表されたセットからすべての増分メソッドをサポートしていない場合、クライアントはTIPS情報リソースを使用してはなりません。
tag:
tag:
If the "resource-id" is associated with a GET-mode resource with a version tag (or "vtag"), as defined in Section 10.3 of [RFC7285], and the ALTO client has previously retrieved a version of that resource from ALTO, the ALTO client MAY set the "tag" field to the tag part of the client's version of that resource. The server MAY use the tag when calculating a recommended starting edge for the client to consume. Note that the client MUST support all incremental methods from the set announced in the server's capabilities for this resource.
[RESSONCE-ID]が[RFC7285]のセクション10.3で定義されているように、バージョンタグ（または「VTAG」）を持つゲットモードリソースに関連付けられており、ALTOクライアントが以前にALTOからそのリソースのバージョンを取得した場合、ALTOクライアントは、そのリソースのクライアントのバージョンのタグ部分に「タグ」フィールドを設定する場合があります。サーバーは、クライアントが消費するように推奨される開始エッジを計算するときにタグを使用する場合があります。クライアントは、このリソースのためにサーバーの機能で発表されたセットからすべての増分メソッドをサポートする必要があることに注意してください。
input:
入力：
If the resource is a POST-mode service that requires input, the ALTO client MUST set the "input" field to a JSON object with the parameters that the resource expects.
リソースが入力を必要とするポストモードサービスである場合、ALTOクライアントは、リソースが期待するパラメーターを使用してJSONオブジェクトに「入力」フィールドを設定する必要があります。
The response to a valid request MUST be a JSON object of the AddTIPSResponse type, denoted as media type "application/alto-tips+json":
有効なリクエストへの応答は、メディアタイプ「Application/Alto-Tips+JSON」として示されるAddTipsResponseタイプのJSONオブジェクトでなければなりません。
object {
URI tips-view-uri;
TIPSViewSummary tips-view-summary;
} AddTIPSResponse;
object {
UpdatesGraphSummary updates-graph-summary;
} TIPSViewSummary;
object {
JSONNumber start-seq;
JSONNumber end-seq;
StartEdgeRec start-edge-rec;
} UpdatesGraphSummary;
object {
JSONNumber seq-i;
JSONNumber seq-j;
} StartEdgeRec;
Figure 8: AddTIPSResponse
図8：AddTipsResponse
with the following fields:
次のフィールドで：
tips-view-uri:
TIPS-view-uri：
This is the URI to the requested TIPS view. The value of this field MUST have the following format:
これは、リクエストされたヒントビューのURIです。このフィールドの値には、次の形式が必要です。
scheme "://" tips-view-host "/" tips-view-path
tips-view-host = host [ ":" port]
tips-view-path = path
where scheme MUST be "http" or "https" unless specified by a future extension, and host, port, and path are as specified in Sections 3.2.2, 3.2.3, and 3.3 in [RFC3986]. An ALTO server SHOULD 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 MUST contain only ASCII characters. In case the original URL contains international characters (e.g., in the domain name), the ALTO server implementation MUST properly encode the URL into the ASCII format (e.g., using the "urlencode" function).
[RFC3986]のセクション3.2.2、3.2.3、および3.3で指定されているように、将来の拡張機能で指定されていない限り、スキームは「HTTP」または「HTTPS」でなければなりません。ALTOサーバーは、ヒントビューの内容が公開され、セキュリティ上の懸念を提起しないことを意図していない限り、「HTTPS」スキームを使用する必要があります。フィールドにはASCII文字のみを含める必要があります。元のURLに国際文字（ドメイン名など）が含まれている場合、ALTOサーバーの実装は、URLをASCII形式に適切にエンコードする必要があります（たとえば、「Urlencode」関数を使用）。
A server MUST NOT use the same URI for different TIPS views, either for different resources or for different request bodies to the same resource. URI generation is implementation specific; for example, one may compute a Universally Unique Identifier (UUID) [RFC9562] or a hash value based on the request and append it to a base URL. For performance considerations, it is NOT RECOMMENDED to use properties that are not included in the request body to determine the URI of a TIPS view, such as cookies or the client's IP address, which may result in duplicated TIPS views in cases such as mobile clients. However, this is not mandatory as a server might intentionally use client information to compute the TIPS view URI to provide service isolation between clients.
サーバーは、異なるリソースまたは同じリソースの異なる要求本体に対して、異なるヒントビューに同じURIを使用してはなりません。URI世代は実装固有です。たとえば、普遍的に一意の識別子（UUID）[RFC9562]またはリクエストに基づいてハッシュ値を計算して、ベースURLに追加できます。パフォーマンスの考慮事項については、CookieやクライアントのIPアドレスなどのヒントビューのURIを決定するためにリクエスト本体に含まれていないプロパティを使用することはお勧めしません。。ただし、サーバーは意図的にクライアント情報を使用してURIを表示するヒントを計算してクライアント間のサービス分離を提供する可能性があるため、これは必須ではありません。
tips-view-summary:
TIPS-View-Summary：
Contains an updates-graph-summary.
アップデートグラフサマリーが含まれています。
The "updates-graph-summary" field contains the <start-seq> of the updates graph (in the "start-seq" field) and the <end-seq> that is currently available (in the "end-seq" field), along with a recommended edge to consume (in the "start-edge-rec" field). If the client does not provide a version tag, the server MUST recommend the edge of the latest available snapshot. If the client provides a version tag, the server MUST either recommend the first incremental update edge starting from the client's tagged version or recommend the edge of the latest snapshot: which edge is selected depends on the implementation. For example, a server MAY calculate the cumulative size of the incremental updates available from that version onward and compare it to the size of the complete resource snapshot. If the snapshot is bigger, the server recommends the first incremental update edge starting from the client's tagged version. Otherwise, the server recommends the latest snapshot edge.
「Updates-Graph-Summary」フィールドには、更新グラフの<Start-Seq>（「Start-Seq」フィールド）と現在利用可能な<End-seq>（「End-seq」フィールドで）が含まれています。）、消費する推奨エッジ（「スタートエッジ」フィールド）とともに。クライアントがバージョンタグを提供していない場合、サーバーは最新の利用可能なスナップショットのエッジを推奨する必要があります。クライアントがバージョンタグを提供する場合、サーバーは、クライアントのタグ付きバージョンから始まる最初の増分更新エッジを推奨するか、最新のスナップショットのエッジを推奨する必要があります。選択したエッジは、実装によって異なります。たとえば、サーバーは、そのバージョン以降に利用可能な増分更新の累積サイズを計算し、完全なリソーススナップショットのサイズと比較できます。スナップショットが大きい場合、サーバーは、クライアントのタグ付きバージョンから始まる最初の増分更新エッジを推奨します。それ以外の場合、サーバーは最新のスナップショットエッジを推奨します。
If the request has any errors, the ALTO server MUST return an HTTP 400 (Bad Request) error code to the ALTO client; the body of the response follows the generic ALTO error response format specified in Section 8.5.2 of [RFC7285]. Hence, an example ALTO error response has the format shown in Figure 9.
リクエストにエラーがある場合、ALTOサーバーはHTTP 400（悪い要求）エラーコードをALTOクライアントに返す必要があります。応答の本文は、[RFC7285]のセクション8.5.2で指定された一般的なALTOエラー応答形式に従います。したがって、ALTOエラー応答の例には、図9に示す形式があります。
HTTP/1.1 400 Bad Request
Content-Length: 131
Content-Type: application/alto-error+json
{
"meta":{
"code": "E_INVALID_FIELD_VALUE",
"field": "resource-id",
"value": "my-network-map/#"
}
}
Figure 9: ALTO Error Example
図9：ALTOエラーの例
Note that "field" and "value" are optional fields. If the "value" field exists, the "field" field MUST exist.
「フィールド」と「値」はオプションのフィールドであることに注意してください。「値」フィールドが存在する場合、「フィールド」フィールドが存在する必要があります。
* If the TIPS request does not have a "resource-id" field, the error code of the error message MUST be "E_MISSING_FIELD" and the "field" field, if present, MUST be "resource-id". The ALTO server MUST NOT create any TIPS view.
* ヒント要求に「リソースID」フィールドがない場合、エラーメッセージのエラーコードは「e_missing_field」でなければならず、「フィールド」フィールドは存在する場合は「リソースID」でなければなりません。ALTOサーバーは、ヒントビューを作成してはなりません。
* If the "resource-id" field is invalid or is not associated with the TIPS information resource, the error code of the error message MUST be "E_INVALID_FIELD_VALUE". If present, the "field" field MUST be the full path of the "resource-id" field, and the "value" field MUST be the value of the "resource-id" field in the request.
* 「Resource-ID」フィールドが無効であるか、TIPS情報リソースに関連付けられていない場合、エラーメッセージのエラーコードは「e_invalid_field_value」でなければなりません。存在する場合、「フィールド」フィールドは「リソースID」フィールドのフルパスでなければならず、「値」フィールドはリクエストの「リソースID」フィールドの値でなければなりません。
* If the resource is a POST-mode service that requires input, the client MUST set the "input" field to a JSON object with the parameters that resource expects. If the "input" field is missing or invalid, the ALTO server MUST return the same error response that resource would return for missing or invalid inputs (see [RFC7285]).
* リソースが入力を必要とするポストモードサービスである場合、クライアントはリソースが期待するパラメーターを使用して「入力」フィールドをJSONオブジェクトに設定する必要があります。「入力」フィールドが欠落または無効な場合、ALTOサーバーは、リソースが欠落または無効な入力に対して戻るのと同じエラー応答を返す必要があります（[RFC7285]を参照）。
Furthermore, it is RECOMMENDED that the server use the following HTTP code to indicate other errors, with the media type "application/alto-error+json".
さらに、メディアタイプ「Application/Alto-Error+JSON」を使用して、サーバーが次のHTTPコードを使用して他のエラーを示すことをお勧めします。
429 (Too Many Requests):
429（リクエストが多すぎます）：
Indicates when the number of TIPS views open requests exceeds the server threshold. The server MAY indicate when to retry the request in the "Re-Try After" headers.
ヒントの数が表示されていることを表示すると、オープンリクエストがサーバーのしきい値を超えることを示します。サーバーは、ヘッダーの「再試行」でリクエストをいつ再試行するかを示す場合があります。
It is RECOMMENDED that the server provide the ALTO/SSE support for the TIPS resource. Thus, the client can be notified of the version updates of all the TIPS views that it monitors and make better cross-resource transport decisions (see Section 8.2 for related considerations).
サーバーは、TIPSリソースにALTO/SSEサポートを提供することをお勧めします。したがって、クライアントには、すべてのヒントのバージョンの更新が監視され、より良いリソース輸送の決定を下すことを通知できます（関連する考慮事項についてはセクション8.2を参照）。
For simplicity, assume that the ALTO server is using Basic authentication [RFC7617]. If a client with username "client1" and password "helloalto" wants to create a TIPS view of an ALTO cost map resource with the resource ID "my-routingcost-map", it can send the request depicted in Figure 10.
簡単にするために、ALTOサーバーが基本認証を使用していると仮定します[RFC7617]。ユーザー名「client1」とパスワード「helloAlto」を持つクライアントが、リソースID「My-routingCost-Map」を使用してALTOコストマップリソースのヒントビューを作成したい場合、図10に示すリクエストを送信できます。
POST /tips HTTP/1.1
Host: alto.example.com
Accept: application/alto-tips+json, application/alto-error+json
Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K
Content-Type: application/alto-tipsparams+json
Content-Length: 41
{
"resource-id": "my-routingcost-map"
}
Figure 10: Request Example of Opening a TIPS View
図10：ヒントビューを開く例をリクエストする
If the operation is successful, the ALTO server returns the message shown in Figure 11.
操作が成功した場合、ALTOサーバーは図11に示すメッセージを返します。
HTTP/1.1 200 OK
Content-Type: application/alto-tips+json
Content-Length: 255
{
"tips-view-uri": "https://alto.example.com/tips/2718281828",
"tips-view-summary": {
"updates-graph-summary": {
"start-seq": 101,
"end-seq": 106,
"start-edge-rec" : {
"seq-i": 0,
"seq-j": 105
}
}
}
}
Figure 11: Response Example of Opening a TIPS View
図11：ヒントビューを開く回答例
Below is another example of the same query using Digest authentication, a mandatory authentication method of ALTO servers as defined in Section 8.3.5 of [RFC7285]. The content of the response is the same as in Figure 11; thus, it has been omitted for simplicity.
以下は、[RFC7285]のセクション8.3.5で定義されているALTOサーバーの必須認証方法であるダイジェスト認証を使用した同じクエリの別の例です。応答の内容は、図11と同じです。したがって、簡単にするために省略されています。
POST /tips HTTP/1.1
Host: alto.example.com
Accept: application/alto-tips+json, application/alto-error+json
Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K
Content-Type: application/alto-tipsparams+json
Content-Length: 41
{
"resource-id": "my-routingcost-map"
}
HTTP/1.1 401 UNAUTHORIZED
WWW-Authenticate: Digest
realm="alto.example.com",
qop="auth",
algorithm="MD5",
nonce="173b5aba4242409ee2ac3a4fd797f9d7",
opaque="a237ff9ab865379a69d9993162ef55e4"
POST /tips HTTP/1.1
Host: alto.example.com
Accept: application/alto-tips+json, application/alto-error+json
Authorization: Digest
username="client1",
realm="alto.example.com",
uri="/tips",
qop=auth,
algorithm=MD5,
nonce="173b5aba4242409ee2ac3a4fd797f9d7",
nc=00000001,
cnonce="ZTg3MTI3NDFmMDQ0NzI1MDQ3MWE3ZTFjZmM5MTNiM2I=",
response="8e937ae696c1512e4f990fa21c7f9347",
opaque="a237ff9ab865379a69d9993162ef55e4"
Content-Type: application/alto-tipsparams+json
Content-Length: 41
{
"resource-id": "my-routingcost-map"
}
HTTP/1.1 200 OK
Content-Type: application/alto-tips+json
Content-Length: 258
{....}
Figure 12: Open Example with Digest Authentication
図12：ダイジェスト認証を使用したオープン例
This section gives an example of receiving incremental updates of the TIPS view summary using ALTO/SSE [RFC8895]. Consider the "tips-sse" resource, as announced by the IRD in Figure 6, which provides ALTO/ SSE for the "update-my-cost-tips" resource; a client might send the following request to receive updates of the TIPS view (authentication is omitted for simplicity).
このセクションでは、ALTO/SSE [RFC8895]を使用して、ヒントビューの要約の増分更新を受信した例を示します。図6でIRDによって発表された「Tips-SSE」リソースを考えてみましょう。これは、「更新my-cost-tips」リソースにALTO/ SSEを提供します。クライアントは、次のリクエストを送信して、ヒントビューの更新を受信する場合があります（簡単にするために認証は省略されています）。
POST /updates/tips HTTP/1.1
Host: alto.example.com
Accept: text/event-stream,application/alto-error+json
Content-Type: application/alto-updatestreamparams+json
Content-Length: 76
{
"add": {
"tips-123": { "resource-id": "update-my-cost-tips" }
}
}
Figure 13: Example of Monitoring TIPS View with ALTO/SSE
図13：Alto/SSEを使用した監視のヒントビュービュー
Then, the client will be able to receive the TIPS view summary as follows.
次に、クライアントは次のようにヒントビューの要約を受信できます。
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/event-stream
event: application/alto-tips+json,tips-123
data: {
data: "tips-view-uri": "https://alto.example.com/tips/2718281828",
data: "tips-view-summary": {
data: "updates-graph-summary": {
data: "start-seq": 101,
data: "end-seq": 106,
data: "start-edge-rec" : {
data: "seq-i": 0,
data: "seq-j": 105
data: }
data: }
data: }
data: }
When there is an update to the TIPS view (for example, when the "end-seq" field is increased by 1), the client will be able to receive the incremental update of the TIPS view summary as follows.
ヒントビューの更新がある場合（たとえば、「エンドシュー」フィールドが1増加すると）、クライアントは次のようにヒントビューの要約の増分更新を受信できます。
event: application/merge-patch+json,tips-123
data: {
data: "tips-view-summary": {
data: "updates-graph-summary": {
data: "end-seq": 107
data: }
data: }
data: }
TIPS allows an ALTO client to retrieve the content of an update item from the updates graph, with an update item defined as the content (incremental update or snapshot) on an edge in the updates graph.
ヒントを使用すると、ALTOクライアントは更新グラフから更新項目のコンテンツを取得できます。更新アイテムは、更新グラフのエッジにコンテンツ（増分更新またはスナップショット）として定義されています。
The client sends an HTTP GET request, where the media type of an update item resource MUST be the same as the "media-type" field of the update item on the specified edge in the updates graph.
クライアントはHTTP GETリクエストを送信します。ここで、更新アイテムリソースのメディアタイプは、更新グラフの指定されたエッジにある更新アイテムの「メディアタイプ」フィールドと同じでなければなりません。
The GET request MUST have the following format:
GETリクエストには、次の形式が必要です。
GET /<tips-view-path>/ug/<i>/<j>
HOST: <tips-view-host>
For example, consider the updates graph in Figure 4. If the client wants to query the content of the first update item (0 -> 101) whose media type is "application/alto-costmap+json", it sends a request to "/tips/2718281828/ug/0/101" and sets the "Accept" header to "application/alto-costmap+json,application/alto-error+json". See Section 7.3 for a concrete example.
たとえば、図4の更新グラフを検討してください。クライアントがメディアタイプが「アプリケーション/ALTO -COSTMAP+JSON」である最初の更新項目（0-> 101）のコンテンツをクエリしたい場合、リクエストを送信します。/TIPS/2718281828/ug/0/101 "と「Acputed」ヘッダーを「Application/Alto-Costmap+JSON、Application/Alto-Error+JSON」に設定します。具体的な例については、セクション7.3を参照してください。
If the request is valid (i.e., "ug/<i>/<j>" exists), the response is encoded as a JSON object whose data format is indicated by the media type.
要求が有効な場合（つまり、「ug/<i>/<j>」存在する）、応答はメディアタイプでデータ形式が示されるJSONオブジェクトとしてエンコードされます。
A client MAY conduct proactive fetching of future updates, by long polling updates that have not been provided in the directory yet. For such updates, the client MUST indicate all media types that might appear. It is RECOMMENDED that the server allow for at least the long polling of <end-seq> -> <end-seq + 1>.
クライアントは、ディレクトリにまだ提供されていない長いポーリングの更新により、将来の更新の予防的なフェッチを実施することができます。このような更新のために、クライアントは表示される可能性のあるすべてのメディアタイプを示す必要があります。サーバーは、少なくとも<end-seq> - > <end-seq + 1>の長いポーリングを許可することをお勧めします。
Hence, the server processing logic MUST be:
したがって、サーバーの処理ロジックは次のようにする必要があります。
* If a resource with path "ug/<i>/<j>" exists, return content using encoding.
* パス「ug/<i>/<j>」を持つリソースが存在する場合、エンコードを使用してコンテンツを返します。
* Else, if long polling "ug/<i>/<j>" is acceptable, put request in a backlog queue, then either a response is triggered when the content is ready or the request is interrupted (e.g., by a network error).
* それ以外の場合、長いポーリング「ug/<i>/<j>」が許容できる場合、バックログキューにリクエストを入れ、コンテンツの準備ができたときに応答がトリガーされるか、リクエストが中断されます（たとえば、ネットワークエラーによって）。
* Else, return error.
* それ以外の場合、エラーを返します。
It is RECOMMENDED that the server use the following HTTP codes to indicate errors, with the media type "application/alto-error+json", regarding update item requests.
サーバーは、メディアタイプの「アプリケーション/Alto-Error+JSON」を使用して、アイテムの更新リクエストに関して、次のHTTPコードを使用してエラーを示すことをお勧めします。
404 (Not Found):
404（見つかりません）：
Indicates that the requested update does not exist or the requested TIPS view does not exist or is closed by the server.
要求された更新が存在しないか、要求されたヒントビューが存在しないか、サーバーによって閉じられていることを示します。
410 (Gone):
410（なくなった）：
Indicates an update has a seq that is smaller than the <start-seq>.
更新には<Start-Seq>よりも小さいSEQがあることを示します。
415 (Unsupported Media Type):
415（サポートされていないメディアタイプ）：
Indicates the media type (or types) accepted by the client does not include the media type of the update chosen by the server.
クライアントが受け入れるメディアタイプ（またはタイプ）には、サーバーが選択した更新のメディアタイプが含まれていないことを示します。
425 (Too Early):
425（早すぎる）：
Indicates the seq exceeds the server long polling window.
SEQがサーバーの長いポーリングウィンドウを超えることを示します。
429 (Too Many Requests):
429（リクエストが多すぎます）：
Indicates the number of pending (long poll) requests exceeds the server threshold. The server MAY indicate when to retry the request in the "Re-Try After" headers.
保留中の（長い世論調査）要求の数がサーバーのしきい値を超えることを示します。サーバーは、ヘッダーの「再試行」でリクエストをいつ再試行するかを示す場合があります。
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 Figure 14.
クライアントがEdge 0〜101に更新項目の内容を取得したいと仮定します。リクエストの形式を図14に示します。
GET /tips/2718281828/ug/0/101 HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json, \
application/alto-error+json
Figure 14: GET Example
図14：例を取得します
The response is shown in Figure 15.
応答を図15に示します。
HTTP/1.1 200 OK
Content-Type: application/alto-costmap+json
Content-Length: 50
{ ... full replacement of my-routingcost-map ... }
Figure 15: Response to a GET Request
図15：GETリクエストへの応答
While intended TIPS usage is for the client to receive a recommended starting edge in the TIPS summary, consume that edge, and then construct all future URIs by incrementing the sequence count by one, there may be cases in which the client needs to request a new next edge to consume. For example, if a client has an open TIPS view but has not polled in a while, the client might request the next logical incremental URI; however, the server has compacted the updates graph, so it no longer exists. Thus, the client MAY request a new next edge to consume based on its current version of the resource.
意図されたヒントの使用法は、クライアントがヒントの概要で推奨されるスタートエッジを受け取り、そのエッジを消費し、シーケンスカウントを1つずつ増やすことですべての将来のURIを構築することですが、クライアントが新しいものをリクエストする必要がある場合がある場合があります消費する次のエッジ。たとえば、クライアントがオープンなヒントビューを持っているが、しばらく投票していない場合、クライアントは次の論理増分URIを要求する場合があります。ただし、サーバーは更新グラフを圧縮しているため、存在しなくなりました。したがって、クライアントは、現在のバージョンのリソースに基づいて消費する新しい次のエッジを要求する場合があります。
An ALTO client requests that the server provide a next edge recommendation for a given TIPS view by sending an HTTP POST request with the media type "application/alto-tipsparams+json". The URL of the request MUST have the following format:
ALTOクライアントは、メディアタイプ「Application/Alto-Tipsparams+JSON」とともにHTTP POSTリクエストを送信することにより、サーバーが特定のヒントビューの次のエッジ推奨を提供することを要求します。リクエストのURLには、次の形式が必要です。
<tips-view-path>/ug
and the "HOST" field MUST be "<tips-view-host>".
そして、「ホスト」フィールドは「<Tips-View-Host>」でなければなりません。
The POST body has the same format as the TIPSReq in Figure 7. The "resource-id" field MUST be the same as the resource ID used to create the TIPS view, and the optional "input" field MUST NOT be present.
ポストボディは、図7のTIPSREQと同じ形式を持っています。「リソースID」フィールドは、TIPSビューの作成に使用されるリソースIDと同じでなければならず、オプションの「入力」フィールドが存在してはなりません。
The response to a valid request MUST be a JSON merge patch to the object of the AddTIPSResponse type (defined in Section 6.2), denoted as media type "application/merge-patch+json". The "updates-graph-summary" field MUST be present in the response; hence, its parent field "tips-view-summary" MUST be present as well.
有効なリクエストに対する応答は、メディアタイプ「アプリケーション/マージパッチ+json」として示されているaddTipsResponseタイプのオブジェクト（セクション6.2で定義）のJSONマージパッチでなければなりません。「アップデートグラフサマリー」フィールドは、応答に存在する必要があります。したがって、その親フィールド「ヒントビュースマリー」も同様に存在する必要があります。
If the "tag" field is present in the request, the server MUST check if any 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 MUST compute the paths from both <tag-seq> and 0 to the <end-seq> and choose the one with the minimal cost. The cost MAY be implementation specific (e.g., number of messages, accumulated data size, etc.). The first edge of the selected path MUST be returned as the recommended next edge.
「タグ」フィールドがリクエストに存在する場合、サーバーは範囲内のバージョン[<Start-Seq>、<End-seq>]が同じタグ値を持っているかどうかを確認する必要があります。バージョンが存在する場合（例：<tag-seq>として示されるなど）、サーバーは<tag-seq>と0の両方のパスを<end-seq>へのパスを計算し、最小コストのあるパスを選択する必要があります。コストは実装固有の場合があります（たとえば、メッセージの数、累積データサイズなど）。選択されたパスの最初のエッジは、推奨される次のエッジとして返す必要があります。
If the "tag" field is not present, the interpretation MUST be that the <tag-seq> is 0.
「タグ」フィールドが存在しない場合、解釈は<Tag-seq>が0である必要があります。
It is RECOMMENDED that the server use the following HTTP code to indicate errors, with the media type "application/alto-error+json", regarding new next edge requests.
サーバーは、次のHTTPコードを使用してエラーを示すことをお勧めします。メディアタイプの「アプリケーション/Alto-Error+JSON」を使用して、新しい次のエッジ要求に関して。
404 (Not Found):
404（見つかりません）：
Indicates that the requested TIPS view does not exist or has been closed by the server.
要求されたヒントビューが存在しないか、サーバーによって閉じられていることを示します。
In this section, we give an example of the new next edge recommendation service. Assume that a client already creates a TIPS view (as in Section 6.3) whose updates graph is as shown in Figure 2. Now assume that the client already has tag 0881080, whose corresponding sequence number is 103, and sends the following new next edge recommendation request (authentication is omitted for simplicity):
このセクションでは、新しいNext Edge推奨サービスの例を示します。クライアントがすでに図2に示すように、更新グラフを参照しているヒントビュー（セクション6.3のように）を作成していると仮定します。ここで、クライアントは対応するシーケンス番号が103であるタグ0881080を既に持っていると仮定し、次の新しい次のエッジ推奨を送信しますリクエスト（簡単にするために認証は省略されています）：
POST /tips/2718281828/ug HTTP/1.1
HOST alto.example.com
Accept: application/merge-patch+json, application/alto-error+json
Content-Type: application/alto-tipsparams+json
Content-Length: 62
{
"resource-id": "my-routingcost-map",
"tag": "0881080"
}
According to Figure 2, there are three potential paths: 103 -> 104 -> 105 -> 106, 103 -> 105 -> 106, and 0 -> 105 -> 106. Assume that the server chooses the shortest update path by the accumulated data size and the best path is 103 -> 105 -> 106. Thus, the server responds with the following message:
図2によると、3つの潜在的なパスがあります：103-> 104-> 105-> 106、103-> 105-> 106、および0-> 105-> 106.蓄積されたデータサイズと最良のパスは103-> 105-> 106です。したがって、サーバーは次のメッセージで応答します。
HTTP/1.1 200 OK
Content-Type: application/merge-patch+json
Content-Length: 193
{
"tips-view-summary": {
"updates-graph-summary": {
"start-seq": 101,
"end-seq": 106,
"start-edge-rec": {
"seq-i": 103,
"seq-j": 105
}
}
}
}
TIPS has some common operational considerations as ALTO/SSE [RFC8895], including:
ヒントには、ALTO/SSE [RFC8895]など、いくつかの一般的な運用上の考慮事項があります。
* the server choosing update messages (Section 9.1 of [RFC8895]);
* 更新メッセージを選択するサーバー（[RFC8895]のセクション9.1）;
* the client processing update messages (Section 9.2 of [RFC8895]);
* クライアント処理の更新メッセージ（[RFC8895]のセクション9.2）;
* the updates of filtered map services (Section 9.3 of [RFC8895]); and
* フィルタリングされたマップサービスの更新（[RFC8895]のセクション9.3）;そして
* the updates of ordinal mode costs (Section 9.4 of [RFC8895]).
* 序数モードの更新コスト（[RFC8895]のセクション9.4）。
There are also some operational considerations specific to TIPS, which we discuss below.
また、以下で説明するヒントに固有のいくつかの運用上の考慮事項もあります。
There are two levels of load balancing in TIPS: the first level is to balance the load of TIPS views for different clients and the second is to balance the load of incremental updates.
ヒントには2つのレベルの負荷分散があります。最初のレベルは、異なるクライアントのチップビューの負荷のバランスをとることであり、2つ目は増分更新の負荷のバランスをとることです。
Load balancing of TIPS views can be achieved either at the application layer or at the infrastructure layer. For example, an ALTO server MAY set <tips-view-host> to different subdomains to distribute TIPS views or simply use the same host of the TIPS information resource and rely on load balancers to distribute the load.
チップビューのロードバランスは、アプリケーションレイヤーまたはインフラストラクチャレイヤーのいずれかで達成できます。たとえば、ALTOサーバーは、<tips-view-host>を異なるサブドメインに設定して、ヒントビューを配布するか、単にヒント情報リソースの同じホストを使用し、負荷を分散するためにロードバランサーに依存するだけです。
TIPS allows a client to make concurrent pulls of incremental updates for the same TIPS view, potentially through different HTTP connections. As a consequence, TIPS introduces additional complexities when the ALTO server balances the load by distributing the requests to a set of backend servers. For example, a request might be directed to the wrong backend server and get processed incorrectly if the following two conditions both hold:
ヒントを使用すると、クライアントは、異なるHTTP接続を介して、潜在的に同じヒントビューの増分更新を同時に行うことができます。結果として、ヒントは、ALTOサーバーがバックエンドサーバーのセットにリクエストを配布することにより、負荷のバランスをとるときに追加の複雑さをもたらします。たとえば、次の2つの条件が保持されている場合、リクエストは間違ったバックエンドサーバーに向けられ、誤って処理される場合があります。
* these backend servers are stateful (i.e., the TIPS view is created and stored only on a single server); and
* これらのバックエンドサーバーはステートフルです（つまり、ヒントビューは作成され、単一のサーバーにのみ保存されます）。そして
* the ALTO server is using Layer 4 load balancing (i.e., the requests are distributed based on the TCP 5-tuple).
* ALTOサーバーは、レイヤー4ロードバランシングを使用しています（つまり、リクエストはTCP 5タプルに基づいて配布されます）。
Thus, additional considerations are required to enable correct load balancing for TIPS, including:
したがって、以下を含む、ヒントの正しい負荷分散を有効にするために追加の考慮事項が必要です。
Using a stateless architecture:
ステートレスアーキテクチャの使用：
One solution is to follow the stateless computing pattern: states about the TIPS view are not maintained by the backend servers but are stored in a distributed database. Thus, concurrent requests to the same TIPS view can be processed on arbitrary stateless backend servers, which all fetch data from the same database.
解決策の1つは、ステートレスコンピューティングパターンに従うことです。ヒントビューに関する状態は、バックエンドサーバーによって維持されず、分散データベースに保存されます。したがって、同じヒントビューへの同時リクエストは、すべてが同じデータベースからデータを取得する任意のステートレスバックエンドサーバーで処理できます。
Configuring the load balancers properly:
ロードバランサーの適切な構成：
In the case that the backend servers are stateful, the load balancers must be properly configured to guarantee that requests of the same TIPS view always arrive at the same server. For example, an operator or a provider of an ALTO server MAY configure Layer 7 load balancers that distribute requests based on the tips-view-path component in the URI.
バックエンドサーバーがステートフルである場合、ロードバランサーは、同じヒントのリクエストが常に同じサーバーに到着することを保証するように適切に構成する必要があります。たとえば、ALTOサーバーのオペレーターまたはプロバイダーは、URIのヒントビューパスコンポーネントに基づいてリクエストを配布するレイヤー7ロードバランサーを構成できます。
Dependent ALTO resources result in cross-resource dependencies in TIPS. Consider the following pair of resources, where my-cost-map (C) is dependent on my-network-map (N). The updates graph for each resource is shown, along with links between the respective updates graphs to show dependency:
依存するアルトリソースは、ヒントのリソース相互依存関係をもたらします。マイコストマップ（c）がmy-network-map（n）に依存しているリソースの次のペアを考えてみましょう。各リソースの更新グラフが表示され、それぞれの更新グラフ間のリンクが依存関係を示します。
+---+ +---+ +---+ +---+ +---+
my-network-map (N) | 0 |-->|89 |-->|90 |-->|91 |-->|92 |
+---+ +---+ +---+ +---+ +---+
| \ \ \
| \ \ \
+---+ +---+ +---+ +---+ +---+
my-cost-map (C) | 0 |-->|101|-->|102|-->|103|-->|104|
+---+ +---+ +---+ +---+ +---+
|_______________________|
Figure 16: Example Dependency Model
図16：依存関係モデルの例
In Figure 16, the cost-map versions 101 and 102 (denoted as C101 and C102) are dependent on the network-map version 89 (denoted as N89). The cost-map version 103 (C103) is dependent on the network-map version 90 (N90), and so on.
図16では、コストマップバージョン101および102（C101およびC102として表される）は、ネットワークマップバージョン89（N89として表される）に依存しています。コストマップバージョン103（C103）は、ネットワークマップバージョン90（N90）などに依存します。
Thus, the client must decide the order in which to receive and apply the updates. The order may affect how fast the client can build a consistent view and how long the client needs to buffer the update.
したがって、クライアントは、更新を受信して適用する順序を決定する必要があります。この順序は、クライアントが一貫したビューを構築できる速度と、クライアントがアップデートをバッファリングするために必要な期間に影響を与える可能性があります。
Example 1:
例1：
The client requests N89, N90, N91, C101, C102 in that order. The client either gets no consistent view of the resources or has to buffer N90 and N91.
クライアントは、その順序でN89、N90、N91、C101、C102を要求します。クライアントは、リソースの一貫したビューを取得していないか、N90とN91をバッファする必要があります。
Example 2:
例2：
The client requests C101, C102, C103, N89. The client either gets no consistent view or has to buffer C103.
クライアントは、C101、C102、C103、N89を要求します。クライアントは、一貫したビューを取得しないか、C103をバッファする必要があります。
To get consistent ALTO information, a client must process the updates following the guidelines specified in Section 9.2 of [RFC8895]. If resources permit (i.e., sufficient updates can be buffered), an ALTO client can safely use long polling to fetch all the updates. This allows a client to build consistent views quickly as the updates are already stored in the buffer. Otherwise, it is RECOMMENDED to request a full snapshot if the client does not have enough local resources to buffer and process the incremental updates.
一貫したALTO情報を取得するには、クライアントは[RFC8895]のセクション9.2で指定されたガイドラインに従って更新を処理する必要があります。リソースが許可されている場合（つまり、十分な更新をバッファリングできます）、ALTOクライアントはすべての更新を取得するために長いポーリングを安全に使用できます。これにより、更新がバッファに既に保存されているため、クライアントは一貫したビューをすばやく構築できます。それ以外の場合は、クライアントが増分更新をバッファリングおよび処理するのに十分なローカルリソースを持っていない場合は、完全なスナップショットを要求することをお勧めします。
From a client's point of view, it sees only one copy of the TIPS view for any resource. However, on the server side, there are different implementation options, especially for common resources (e.g., network maps or cost maps) that may be frequently queried by many clients. Some potential options are listed below:
クライアントの観点から、リソースのヒントビューのコピーは1つだけ表示されます。ただし、サーバー側には、特に多くのクライアントが頻繁に照会する可能性のある一般的なリソース（ネットワークマップやコストマップなど）については、さまざまな実装オプションがあります。いくつかの潜在的なオプションを以下に示します。
* An ALTO server creates one TIPS view of the common resource for each client.
* ALTOサーバーは、各クライアントの共通リソースの1つのヒントビューを作成します。
* An ALTO server maintains one copy of the TIPS view for each common resource and all clients requesting the same resources use the same copy. There are two ways to manage the storage for the shared copy:
* ALTOサーバーは、一般的なリソースごとにヒントビューのコピーを1つ維持し、同じリソースを要求するすべてのクライアントが同じコピーを使用します。共有コピーのストレージを管理する方法は2つあります。
- 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 the set becomes empty and no client immediately issues a new edge request; or
- ALTOサーバーは、ヒントビューにポーリングリクエストを送信したクライアントのセットを維持し、セットが空になり、すぐに新しいEDGEリクエストを発行しない場合にのみ、ストレージからビューを削除します。または
- the TIPS view is never removed from the storage.
- ヒントビューがストレージから削除されることはありません。
Developers may choose different implementation options depending on criteria such as request frequency, available resources of the ALTO server, the ability to scale, and programming complexity.
開発者は、要求頻度、ALTOサーバーの利用可能なリソース、拡張機能、プログラミングの複雑さなどの基準に応じて、異なる実装オプションを選択できます。
Besides the mandatory stepwise incremental updates (from i to i+1), an ALTO server MAY optionally offer shortcut incremental updates, or simple shortcuts, between two non-consecutive versions i and i+k (k > 1). Such shortcuts offer alternative paths in the updates graph and can potentially speed up the transmission and processing of incremental updates, leading to faster synchronization of ALTO information, especially when the client has limited bandwidth and computation. However, implementors of an ALTO server must be aware that:
必須の段階的な増分更新（IからI+1）に加えて、ALTOサーバーは、2つの非受信バージョンIとI+K（K> 1）の間で、ショートカットの増分アップデート、または簡単なショートカットをオプションで提供する場合があります。このようなショートカットは、更新グラフの代替パスを提供し、特にクライアントの帯域幅と計算が制限されている場合、ALTO情報のより速い同期につながる潜在的に、インクリメンタルアップデートの送信と処理を高速化できます。ただし、ALTOサーバーの実装者は次のことを認識する必要があります。
1. optional shortcuts may increase the size of the updates graph, worst case scenario being the square of the number of updates (i.e., when a shortcut is offered for each version to all future versions).
1. オプションのショートカットは、更新グラフのサイズを増加させる可能性があります。最悪のシナリオは、更新の数の平方です（つまり、各バージョンに将来のすべてのバージョンにショートカットが提供される場合）。
2. optional shortcuts require additional storage on the ALTO server.
2. オプションのショートカットには、ALTOサーバーに追加のストレージが必要です。
3. optional shortcuts may reduce concurrency when the updates do not overlap (e.g., when the updates apply to different parts of an 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 can be transmitted concurrently while the shortcut is transmitted in a single connection.
3. オプションのショートカットは、更新が重複しない場合（たとえば、アップデートがALTOリソースのさまざまな部分に適用される場合）に並行性を低下させる場合があります。このような場合、元の更新の合計サイズはショートカットのサイズに近いですが、ショートカットが単一の接続で送信されている間、元の更新を同時に送信できます。
The security considerations of the base protocol (Section 15 of [RFC7285]) fully apply to this extension. For example, the same authenticity and integrity considerations (Section 15.1 of [RFC7285]) still fully apply; the same considerations for the privacy of ALTO users (Section 15.4 of [RFC7285]) also still fully apply. Additionally, operators of the ALTO servers MUST follow the guidelines in [RFC9325] to avoid new TLS vulnerabilities discovered after [RFC7285] was published.
ベースプロトコル（[RFC7285]のセクション15）のセキュリティ上の考慮事項は、この拡張機能に完全に適用されます。たとえば、同じ信頼性と整合性の考慮事項（[RFC7285]のセクション15.1）はまだ完全に適用されます。ALTOユーザーのプライバシーに関する同じ考慮事項（[RFC7285]のセクション15.4）もまだ完全に適用されます。さらに、ALTOサーバーのオペレーターは、[RFC9325]のガイドラインに従って、[RFC7285]が公開された後に発見された新しいTLSの脆弱性を回避する必要があります。
The additional services (the addition of update read service and update push service) provided by this extension extend the attack surface described in Section 15.1.1 of [RFC7285]. The following subsections discuss the additional risks and their remedies.
[RFC7285]のセクション15.1.1で説明されている攻撃面を拡張するこの拡張機能によって提供される追加サービス（更新読み取りサービスと更新プッシュサービスの追加）。次のサブセクションでは、追加のリスクとその救済策について説明します。
Allowing TIPS views enables new classes of DoS attacks. In particular, for the TIPS server, one or multiple malicious ALTO clients might create an excessive number of TIPS views, to exhaust the server resource and/or to block normal users from accessing the service.
チップビューを許可すると、新しいクラスのDOS攻撃が可能になります。特に、TIPSサーバーの場合、1つまたは複数の悪意のあるALTOクライアントは、サーバーリソースを排出したり、通常のユーザーがサービスにアクセスするのをブロックするために、過度の数のヒントビューを作成する場合があります。
To avoid such attacks, the server MAY choose to limit the number of active views and reject new requests when that threshold is reached. TIPS allows predictive fetching and the server MAY also choose to limit the number of pending requests. If a new request exceeds the threshold, the server MAY log the event and return the HTTP status 429 (Too Many Requests).
このような攻撃を回避するために、サーバーはアクティブなビューの数を制限し、そのしきい値に達したときに新しい要求を拒否することを選択できます。ヒントを使用すると、予測フェッチが可能になり、サーバーは保留中のリクエストの数を制限することも選択できます。新しい要求がしきい値を超えると、サーバーはイベントをログにしてHTTPステータス429を返すことができます（リクエストが多すぎます）。
It is important to note that the preceding approaches are not the only possibilities. For example, it might be possible for a TIPS server to use somewhat more clever logic involving TIPS view eviction policies, IP reputation, rate-limiting, and compartmentalization of the overall threshold into smaller thresholds that apply to subsets of potential clients. If service availability is a concern, ALTO clients MAY establish service level agreements with the ALTO server.
前のアプローチだけが唯一の可能性ではないことに注意することが重要です。たとえば、TIPSサーバーは、潜在的なクライアントのサブセットに適用されるより小さなしきい値への全体的なしきい値を視聴する、潜在的なクライアントのサブセットに適用されるより小さなしきい値へのヒントを表示するヒントを含む、やや巧妙なロジックを使用することが可能かもしれません。サービスの可用性が懸念される場合、ALTOクライアントはALTOサーバーとのサービスレベル契約を確立する場合があります。
The availability of continuous updates can also cause overload for an ALTO client, in particular, an ALTO client with limited processing capabilities. The current design does not include any flow control mechanisms for the client to reduce the update rates from the server. For example, TCP, HTTP/2, and QUIC provide stream and connection flow control data limits, which might help prevent the client from being overloaded. Under overloading, the client MAY choose to remove the information resources with high update rates.
継続的な更新の可用性は、ALTOクライアント、特に処理機能が限られているALTOクライアントの過負荷を引き起こす可能性があります。現在の設計には、クライアントがサーバーからの更新レートを削減するためのフロー制御メカニズムは含まれていません。たとえば、TCP、HTTP/2、およびQUICは、クライアントが過負荷にならないようにするのに役立つ可能性のあるストリームおよび接続フロー制御データの制限を提供します。過負荷の下で、クライアントは、高い更新レートで情報リソースを削除することを選択できます。
Also, under overloading, the client might no longer be able to detect whether information is still fresh or has become stale. In such a case, the client should be careful in how it uses the information to avoid stability or efficiency issues.
また、過負荷の下で、クライアントは、情報がまだ新鮮であるか、古くなっているかを検出できなくなる可能性があります。このような場合、クライアントは、安定性や効率の問題を回避するために情報を使用する方法に注意する必要があります。
IANA has registered the following media types from the registry available at [IANA-Media-Type]:
IANAは、[iana-media-type]で利用可能なレジストリから次のメディアタイプを登録しています。
* application/alto-tips+json: as described in Section 6.2;
* Application/ALTO-TIPS+JSON：セクション6.2で説明されています。
* application/alto-tipsparams+json: as described in Section 6.1;
* Application/Alto-Tipsparams+JSON：セクション6.1で説明したとおり。
Type name:
タイプ名：
application
応用アプリケーション出願塗布申請アプリ使用利用申込申し込み応募運用願い願い出要請控訴勉励丹念請求応用力適用業務
Subtype name:
サブタイプ名：
alto-tips+json
アルトタイップス+json
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
Encoding considerations are identical to those specified for the "application/json" media type. See [RFC8259].
エンコーディングの考慮事項は、「アプリケーション/JSON」メディアタイプに指定されたものと同じです。[RFC8259]を参照してください。
Security considerations:
セキュリティ上の考慮事項：
See the Security Considerations section of RFC 9569.
RFC 9569のセキュリティに関する考慮事項セクションを参照してください。
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
Section 6.2 of RFC 9569.
RFC 9569のセクション6.2。
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
ALTO servers and ALTO clients either stand alone or are embedded within other applications.
ALTOサーバーとALTOクライアントは、単独であるか、他のアプリケーションに組み込まれています。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨エイリアス名：
N/A
n/a
Magic number(s):
マジックナンバー：
N/A
n/a
File extension(s):
ファイル拡張子：
RFC 9569 uses the media type to refer to protocol messages; thus, it does not require a file extension.
RFC 9569は、メディアタイプを使用してプロトコルメッセージを参照しています。したがって、ファイル拡張子は必要ありません。
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
See the Authors' Addresses section of RFC 9569.
RFC 9569の著者のアドレスセクションを参照してください。
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
N/A
n/a
Author:
著者：
See the Authors' Addresses section of RFC 9569.
RFC 9569の著者のアドレスセクションを参照してください。
Change controller:
Change Controller：
Internet Engineering Task Force (iesg@ietf.org).
インターネットエンジニアリングタスクフォース（iesg@ietf.org）。
Type name:
タイプ名：
application
応用アプリケーション出願塗布申請アプリ使用利用申込申し込み応募運用願い願い出要請控訴勉励丹念請求応用力適用業務
Subtype name:
サブタイプ名：
alto-tipsparams+json
Alto-Tipsparams+Json
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
Encoding considerations are identical to those specified for the "application/json" media type. See [RFC8259].
エンコーディングの考慮事項は、「アプリケーション/JSON」メディアタイプに指定されたものと同じです。[RFC8259]を参照してください。
Security considerations:
セキュリティ上の考慮事項：
See the Security Considerations section of RFC 9569.
RFC 9569のセキュリティに関する考慮事項セクションを参照してください。
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
Section 6.1 of RFC 9569.
RFC 9569のセクション6.1。
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
ALTO servers and ALTO clients either stand alone or are embedded within other applications.
ALTOサーバーとALTOクライアントは、単独であるか、他のアプリケーションに組み込まれています。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨エイリアス名：
N/A
n/a
Magic number(s):
マジックナンバー：
N/A
n/a
File extension(s):
ファイル拡張子：
RFC 9569 uses the media type to refer to protocol messages; thus, it does not require a file extension.
RFC 9569は、メディアタイプを使用してプロトコルメッセージを参照しています。したがって、ファイル拡張子は必要ありません。
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
See the Authors' Addresses section of RFC 9569.
RFC 9569の著者のアドレスセクションを参照してください。
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
N/A
n/a
Author:
著者：
See the Authors' Addresses section of RFC 9569.
RFC 9569の著者のアドレスセクションを参照してください。
Change controller:
Change Controller：
Internet Engineering Task Force (iesg@ietf.org).
インターネットエンジニアリングタスクフォース（iesg@ietf.org）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic
Optimization (ALTO) Incremental Updates Using Server-Sent
Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November
2020, <https://www.rfc-editor.org/info/rfc8895>.
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>.
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[IANA-Media-Type]
IANA, "Media Types",
<https://www.iana.org/assignments/media-types>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>.
[RFC9205] Nottingham, M., "Building Protocols with HTTP", BCP 56,
RFC 9205, DOI 10.17487/RFC9205, June 2022,
<https://www.rfc-editor.org/info/rfc9205>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/info/rfc9562>.
Conceptually, the TIPS system consists of three types of resources:
概念的には、ヒントシステムは3種類のリソースで構成されています。
(R1):
（R1）：
The TIPS frontend to create TIPS views.
ヒントフロントエンドでは、ヒントビューを作成します。
(R2):
（R2）：
The TIPS view directory, which provides metadata (e.g., references) about the network resource data.
TIPSは、ネットワークリソースデータに関するメタデータ（例：参照）を提供するディレクトリを表示します。
(R3):
（R3）：
The actual network resource data, encoded as complete ALTO network resources (e.g., a cost map or a network map) or incremental updates.
実際のネットワークリソースデータは、完全なALTOネットワークリソース（コストマップまたはネットワークマップなど）または増分更新としてエンコードされています。
+------------------------------------------------+
| |
+------+ |R1: Frontend/Open R2: Directory/Meta R3: Data |
| | "iget" base | +-----+ +-----+ +-----+ |
| | resource 1 | | | | | | | |
| |-------------|---->| | | | | | |
| | incremental | | | | |-------->| | |
| | transfer | | | | | | | |
| | resource | | | | | | | |
| |<------------|-----------------------| | | | |
|Client| | | | +-----+ +-----+ |
| | "iget" base | | | |
| | resource 2 | | | +-----+ +-----+ |
| |-------------|---->| | | | | | |
| | incremental | | | | | | | |
| | transfer | +-----+ | | ------->| | |
| | resource | | | | | |
| |<------------|-----------------------| | | | |
+------+ | +-----+ +-----+ |
| |
+------------------------------------------------+
Figure 17: Sample TIPS Deployment Model
図17：サンプルのヒント展開モデル
Design Point: Component Resource Location
設計ポイント：コンポーネントリソースの場所
Design 1 (Single):
デザイン1（シングル）：
all the three resource types at the same single server (accessed via relative reference).
同じ単一サーバーの3つのリソースタイプはすべて（相対参照でアクセスされます）。
Design 2 (Flexible):
デザイン2（柔軟）：
all three resource types can be at their own server (accessed via absolute reference).
3つのリソースタイプはすべて、独自のサーバーにあります（Absolute Referenceからアクセス）。
Design 3 (Dir + Data):
設計3（dir +データ）：
R2 and R3 must remain together, though R1 might not be on the same server.
R1は同じサーバー上にない可能性がありますが、R2とR3は一緒にいる必要があります。
This document supports Designs 1 and 3. For Design 1, the ALTO server simply needs to always use the same host for the TIPS views. For Design 3, the ALTO server can set tips-view-host to a different server. Note that the deployment flexibility is at the logical level, as these services can be distinguished by different paths and potentially be routed to different physical servers by Layer 7 load balancing. See Section 8.1 for a discussion on load balancing considerations. Future documents could extend the protocol to support Design 2.
このドキュメントでは、デザイン1と3をサポートしています。デザイン1の場合、ALTOサーバーは、単に同じホストを常にヒントビューに使用する必要があります。設計3の場合、ALTOサーバーは別のサーバーにヒント視聴ホストを設定できます。これらのサービスは異なるパスによって区別され、レイヤー7の負荷バランシングによって異なる物理サーバーにルーティングされる可能性があるため、展開の柔軟性は論理レベルにあることに注意してください。ロードバランスの考慮事項に関する議論については、セクション8.1を参照してください。将来のドキュメントは、デザイン2をサポートするためにプロトコルを拡張できます。
This specification adheres fully to [RFC9205] as further elaborated below:
この仕様は、以下にさらに詳しく説明するように、[RFC9205]に完全に付着します。
* TIPS does not (as described in Section 3.1 of [RFC9205]):
* ヒントはありません（[RFC9205]のセクション3.1で説明されています）：
...redefine, refine, or overlay the semantics of generic protocol elements such as methods, status codes, or existing header fields.
...メソッド、ステータスコード、既存のヘッダーフィールドなどの一般的なプロトコル要素のセマンティクスを再定義、改良、またはオーバーレイします。
and instead focuses on
代わりに焦点を当てます
...protocol elements that are specific to [the TIPS] application -- namely, [its] HTTP resources.
... [TIPS]アプリケーションに固有のプロトコル要素 - つまり、[その] HTTPリソース。
* There are no statically defined URI components (Section 3.2 of [RFC9205]).
* 静的に定義されたURIコンポーネントはありません（[RFC9205]のセクション3.2）。
* No minimum version of HTTP is specified by TIPS, which is recommended (in Section 4.1 of [RFC9205]).
* HTTPの最小バージョンは、推奨されるヒントで指定されていません（[RFC9205]のセクション4.1）。
* The TIPS design follows the advice (in Section 4.1 of [RFC9205]) that:
* ヒントのデザインは、[RFC9205]のセクション4.1のアドバイスに従います。
When specifying examples of protocol interactions, applications should document both the request and response messages with complete header sections, preferably in HTTP/1.1 format...
プロトコルの相互作用の例を指定する場合、アプリケーションは要求メッセージと応答メッセージの両方を完全なヘッダーセクション、できればhttp/1.1形式で文書化する必要があります...
* TIPS uses URI templates, which is recommended (in Section 4.2 of [RFC9205]).
* ヒントでは、URIテンプレートを使用します（[RFC9205]のセクション4.2）。
* TIPS follows the pattern (in Section 4.4.1 of [RFC9205]) that:
* ヒントは、パターン（[RFC9205]のセクション4.4.1）に従います。
Generally, a client will begin interacting with a given application server by requesting an initial document that contains information about that particular deployment, potentially including links to other relevant resources. Doing so ensures that the deployment is as flexible as possible (potentially spanning multiple servers), allows evolution, and also gives the application the opportunity to tailor the "discovery document" to the client.
一般に、クライアントは、他の関連するリソースへのリンクを含む可能性のある特定の展開に関する情報を含む初期ドキュメントを要求することにより、特定のアプリケーションサーバーとの対話を開始します。そうすることで、展開が可能な限り柔軟であることが保証され（複数のサーバーに及ぶ可能性があります）、進化を可能にし、アプリケーションにクライアントに「ディスカバリードキュメント」を調整する機会を与えます。
* TIPS uses existing HTTP schemes (Section 4.4.2 of [RFC9205]).
* ヒントでは、既存のHTTPスキームを使用します（[RFC9205]のセクション4.4.2）。
* TIPS defines its errors "to use the most applicable status code" (Section 4.6 of [RFC9205]).
* ヒントでは、「最も適用可能なステータスコードを使用する」エラーを定義します（[RFC9205]のセクション4.6）。
* TIPS does not (as in Section 4.11 of [RFC9205]):
* ヒントはありません（[RFC9205]のセクション4.11のように）：
...make assumptions about the relationship between separate requests on a single transport connection; doing so breaks many of the assumptions of HTTP as a stateless protocol and will cause problems in interoperability, security, operability, and evolution.
...単一の輸送接続での個別の要求間の関係について仮定を立てます。そうすることで、HTTPがステートレスプロトコルとしての多くの仮定を破り、相互運用性、セキュリティ、操作性、および進化に問題を引き起こします。
The only relationship between requests is that a client has to first discover where a TIPS view of a resource will be served, which is consistent with the URI discovery in Section 4.4.1 of [RFC9205].
リクエスト間の唯一の関係は、クライアントが最初にリソースのヒントビューが提供される場所を発見しなければならないことです。これは、[RFC9205]のセクション4.4.1のURI発見と一致しています。
TIPS allows ALTO clients to subscribe to incremental updates of an ALTO resource, and the specification in this document is based on the current best practice of building such a service using basic HTTP. Earlier versions of this 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).
ヒントを使用すると、ALTOクライアントはALTOリソースの増分更新を購読することができ、このドキュメントの仕様は、基本的なHTTPを使用してそのようなサービスを構築する現在のベストプラクティスに基づいています。このドキュメントの以前のバージョンは、プッシュモードのヒントを有効にする可能性を調査していました（つまり、HTTP/2およびHTTP/3のサーバープッシュ機能を利用することにより）。
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 delivery. Using the built-in HTTP server push also results in minimal changes to the current protocol. While not adopted due to the lack of server push support and increased protocol complexity, push-mode TIPS remains a potential direction of protocol improvement.
理想的なケースでは、プッシュモードのヒントは、より動的な環境とユースケースでパフォーマンス（たとえば、遅延）を改善する可能性があります。組み込みのHTTPサーバープッシュを使用すると、現在のプロトコルの変更が最小限に抑えられます。サーバーのプッシュサポートの欠如とプロトコルの複雑さの増加のために採用されていませんが、プッシュモードのヒントは、プロトコルの改善の潜在的な方向の依存のままです。
Previous draft versions of this document use persistent HTTP connections to detect the liveness of clients. However, this design does not conform well with the best 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 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 might not correctly detect the right liveness state.
このドキュメントの以前のドラフトバージョンは、クライアントの活性を検出するために永続的なHTTP接続を使用します。ただし、この設計は、HTTPの最良の現在のプラクティスに適していません。たとえば、ALTOクライアントがHTTPプロキシを介してヒントビューにアクセスしている場合、接続はALTOクライアントとALTOサーバーの間ではなく、ALTOクライアントとプロキシ間、プロキシとALTOサーバーの間で直接確立されません。したがって、永続的な接続を使用すると、適切なlivension状態を正しく検出できない場合があります。
The authors of this document would like to thank Mark Nottingham and Spencer Dawkins for providing invaluable reviews of earlier draft versions of this document; Adrian Farrel, Qin Wu, and Jordi Ros Giralt for their continuous feedback; Russ White, Donald Eastlake 3rd, Martin Thomson, Bernard Aboba, Spencer Dawkins, Linda Dunbar, and Sheng Jiang for the directorate reviews; Martin Duke for the area director review; Francesca Palombini, Wesley Eddy, Roman Danyliw, Murray Kucherawy, and Zaheduzzaman Sarker for the telechat and IESG reviews; and Mohamed Boucadair for shepherding the document.
この文書の著者は、この文書の以前のドラフトバージョンの貴重なレビューを提供してくれたMark NottinghamとSpencer Dawkinsに感謝します。エイドリアン・ファレル、Qin Wu、およびJordi Ros Giraltの継続的なフィードバック。Russ White、Donald Eastlake 3rd、Martin Thomson、Bernard Aboba、Spencer Dawkins、Linda Dunbar、Sheng Jiangの監督レビュー。エリアディレクターレビューのマーティンデューク。Francesca Palombini、Wesley Eddy、Roman Danyliw、Murray Kucherawy、およびZaheduzzaman SarkerのTelechatおよびIESGレビュー。ドキュメントを羊飼いのためのMohamed Boucadair。
Kai Gao
Sichuan University
No.24 South Section 1, Yihuan Road
Chengdu
610000
China
Email: kaigao@scu.edu.cn
Roland Schott
Deutsche Telekom
Deutsche-Telekom-Allee 9
64295 Darmstadt
Germany
Email: Roland.Schott@telekom.de
Yang Richard Yang
Yale University
51 Prospect Street
New Haven, CT 06511
United States of America
Email: yry@cs.yale.edu
Lauren Delwiche
Yale University
51 Prospect Street
New Haven, CT 06511
United States of America
Email: lauren.delwiche@yale.edu
Lachlan Keller
Yale University
51 Prospect Street
New Haven, CT 06511
United States of America
Email: lachlan.keller@aya.yale.edu