[要約] RFC 8895は、ALTOプロトコルのIncremental Updatesを実現するためにServer-Sent Events（SSE）を使用する方法を定義しています。このRFCの目的は、ALTOサーバーからのネットワーク情報の効率的な更新を可能にし、通信の効率性を向上させることです。
Internet Engineering Task Force (IETF) W. Roome
Request for Comments: 8895 Nokia Bell Labs
Category: Standards Track Y. Yang
ISSN: 2070-1721 Yale University
November 2020
Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)
アプリケーションレイヤトラフィック最適化（ALTO）サーバ送信イベント（SSE）を使用した増分更新
Abstract
概要
The Application-Layer Traffic Optimization (ALTO) protocol (RFC 7285) provides network-related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available.
アプリケーションレイヤトラフィック最適化（ALTO）プロトコル（RFC 7285）は、ネットワーク情報リソースと呼ばれるネットワーク関連の情報をクライアントアプリケーションに提供し、クライアントはネットワークリソースを利用することに情報に基づいた決定を下すことができます。このドキュメントでは、ALTOサーバーがALTOクライアントにアップデートをプッシュして2つの利点を実現するためのメカニズムを示します。（1）情報リソースのごく一部のみが変更された場合、ALTOサーバーは変更点だけを送信できます。（2）Altoサーバが利用可能になるとすぐに更新を送信できるという点で、更新は即時になる可能性があります。
Status of This Memo
本文書の状態
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/rfc8895.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8895で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 IETFの信頼と文書著者として識別された人。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terms
2.1. Requirements Language
3. Background
3.1. Incremental Encoding: JSON Merge Patch
3.1.1. JSON Merge Patch Encoding
3.1.2. JSON Merge Patch ALTO Messages
3.2. Incremental Encoding: JSON Patch
3.2.1. JSON Patch Encoding
3.2.2. JSON Patch ALTO Messages
3.3. Multiplexing and Server Push: HTTP/2
3.4. Server Push: Server-Sent Event
4. Overview of Approach and High-Level Protocol Message Flow
4.1. Update Stream Service Message Flow
4.2. Stream Control Service Message Flow
4.3. Service Announcement and Management Message Flow
5. Update Messages: Data Update and Control Update Messages
5.1. Generic ALTO Update Message Structure
5.2. ALTO Data Update Message
5.3. ALTO Control Update Message
6. Update Stream Service
6.1. Media Type
6.2. HTTP Method
6.3. Capabilities
6.4. Uses
6.5. Request: Accept Input Parameters
6.6. Response
6.7. Additional Requirements on Update Stream Service
6.7.1. Event Sequence Requirements
6.7.2. Cross-Stream Consistency Requirements
6.7.3. Multipart Update Requirements
6.8. Keep-Alive Messages
7. Stream Control Service
7.1. URI
7.2. Media Type
7.3. HTTP Method
7.4. IRD Capabilities & Uses
7.5. Request: Accept Input Parameters
7.6. Response
8. Examples
8.1. Example: IRD Announcing Update Stream Services
8.2. Example: Simple Network and Cost Map Updates
8.3. Example: Advanced Network and Cost Map Updates
8.4. Example: Endpoint Property Updates
8.5. Example: Multipart Message Updates
9. Operation and Processing Considerations
9.1. Considerations for Choosing Data Update Messages
9.2. Considerations for Client Processing Data Update Messages
9.3. Considerations for Updates to Filtered Cost Maps
9.4. Considerations for Updates to Ordinal Mode Costs
9.5. Considerations for SSE Text Formatting and Processing
10. Security Considerations
10.1. Update Stream Server: Denial-of-Service Attacks
10.2. ALTO Client: Update Overloading or Instability
10.3. Stream Control: Spoofed Control Requests and Information
Breakdown
11. Requirements on Future ALTO Services to Use This Design
12. IANA Considerations
12.1. application/alto-updatestreamparams+json Media Type
12.2. application/alto-updatestreamcontrol+json Media Type
13. Appendix: Design Decision: Not Allowing Stream Restart
14. References
14.1. Normative References
14.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] provides network-related information, called network information resources, to client applications so that clients may make informed decisions in utilizing network resources. For example, an ALTO server provides network and cost maps, where a network map partitions the set of endpoints into a manageable number of sets each defined by a Provider-Defined Identifier (PID) and a cost map provides directed costs between PIDs. Given network and cost maps, an ALTO client can obtain costs between endpoints by first using the network map to get the PID for each endpoint and then using the cost map to get the costs between those PIDs. Such costs can be used by the client to choose communicating endpoints with low network costs.
アプリケーションレイヤトラフィック最適化（ALTO）プロトコル[RFC7285]は、ネットワーク情報リソースと呼ばれるネットワーク関連の情報をクライアントアプリケーションに提供し、クライアントはネットワークリソースを利用する際に情報に基づいた決定を下すことができます。たとえば、ALTOサーバはネットワークマップとコストマップを提供し、ネットワークマップはプロバイダ定義識別子（PID）によって定義された各エンドポイントのセットの管理可能な数にパーティションを分割し、コストマップはPID間の指示コストを提供します。ネットワークとコストのマップを考えると、ALTOクライアントは、最初にネットワークマップを使用してエンドポイント間のコストを入手して、各エンドポイントのPIDを取得し、次にコストマップを使用してそれらのPIDS間のコストを取得できます。そのようなコストは、クライアントがネットワークコストが低いと通信エンドポイントを選択するために使用できます。
The ALTO protocol defines only an ALTO client pull model without defining a mechanism to allow an ALTO client to obtain updates to network information resources, other than by periodically re-fetching them. In settings where an information resource may be large but only parts of it may change frequently (e.g., some entries of a cost map), complete re-fetching can be inefficient.
ALTOプロトコルは、ALTOクライアントが定期的にそれらを再フェッチすることによってネットワーク情報リソースの更新を取得できるようにするためのメカニズムを定義せずにALTOクライアントプルモデルのみを定義します。情報リソースが大きくなる可能性があるが、その一部の一部だけが頻繁に変化してもよい（例えば、コストマップの一部のエントリ）、完全な再フェッチが非効率的になる可能性がある。
This document presents a mechanism to allow an ALTO server to push incremental updates to ALTO clients. Integrating server push and incremental updates provides two benefits: (1) updates can be small, in that if only a small section of an information resource changes, the ALTO server can send just the changes and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available.
この文書は、ALTOサーバーがALTOクライアントに増分更新をプッシュできるようにするためのメカニズムを示しています。サーバープッシュおよびインクリメンタルアップデートの統合は2つの利点を提供します。（1）情報リソースのごく一部のみが変更された場合、ALTOサーバーが変更だけを送信でき、（2）の更新は即時に送信できます。Altoサーバーは、利用可能な限り早く更新を送信できます。
While primarily intended to provide updates to GET-mode network and cost maps, the mechanism defined in this document can also provide updates to POST-mode ALTO services, such as the ALTO endpoint property and endpoint cost services. The mechanism can also support new ALTO services to be defined by future extensions, but a future service needs to satisfy requirements specified in Section 11.
Get-Modeネットワークとコストマップへの更新を提供することを主に意図しているが、この文書で定義されているメカニズムは、Alto EndpointプロパティおよびエンドポイントコストサービスなどのポストモードALTOサービスの更新も提供できます。このメカニズムはまた、将来の拡張によって定義されるべき新しいALTOサービスをサポートすることができますが、将来のサービスはセクション11で指定された要件を満たす必要があります。
The rest of this document is organized as follows. Section 3 gives background on the basic techniques used in this design: (1) JSON merge patch and JSON patch to allow incremental updates and (2) Server-Sent Events (SSE) [SSE] to allow server push. With the background, Section 4 gives a non-normative overview of the design. Section 5 defines individual messages in an update stream. Section 6 defines the update stream service. Section 7 defines the stream control service. Section 8 gives several examples to illustrate the two types of services. Section 9 describes operation and processing considerations by both ALTO servers and clients. Section 13 discusses a design feature that is not supported. Section 10 discusses security issues. Sections 11 and 12 review the requirements for future ALTO services to use SSE and IANA considerations, respectively.
この文書の残りの部分は次のように編成されています。セクション3は、このデザインで使用されている基本的な手法を背景にします。（1）JSON Merge PatchおよびJSONパッチは、インクリメンタルアップデートと（2）サーバー送信イベント（SSE）[SSE] [SSE]を許可します。バックグラウンドで、セクション4はデザインの非規範的な概要を示しています。セクション5は更新ストリーム内の個々のメッセージを定義します。セクション6は更新ストリームサービスを定義します。セクション7はストリーム制御サービスを定義します。セクション8は、2つのタイプのサービスを説明するためのいくつかの例を示しています。第9章では、Altoサーバーとクライアントの両方による操作と処理の考慮事項について説明します。セクション13はサポートされていない設計機能について説明します。セクション10はセキュリティ上の問題について説明します。SSEとIANAの考慮事項を使用するための将来のALTOサービスの要件を確認します。
Besides the terminologies as defined in [RFC7285], this document also uses additional terminologies defined as follows:
[RFC7285]で定義されている用語のほかに、この文書では次のように定義されている追加の用語も使用しています。
Update Stream: A reliable, in-order connection compatible with HTTP/1.x between an ALTO client and an ALTO server so that the server can push a sequence of update messages using [SSE] to the client.
アップデートストリーム：ALTOクライアントとALTOサーバとの間のhttp / 1.xと互換性のある信頼性のある順番で、サーバが[SSE]を使用して[SSE]を使用して一連の更新メッセージをプッシュできるようにする。
Update Stream Server: This document refers to an ALTO server providing an update stream as an ALTO update stream server, or update stream server for short. Note that the ALTO server mentioned in this document refers to a general server that provides various kinds of services; it can be an update stream server or stream control server (see below). It can also be a server providing ALTO Information Resource Directory (IRD).
更新Stream Server：このドキュメントは、ALTO Update Stream Serverとしてアップデートストリームを提供するALTOサーバ、またはStream Serverを短縮するための更新プログラムを参照しています。この文書に記載されているALTOサーバは、さまざまな種類のサービスを提供する一般的なサーバーを参照しています。これはアップデートStream ServerまたはStream Control Server（下記参照）です。ALTO情報リソースディレクトリ（IRD）を提供するサーバーでもあります。
Update Message: A message that is either a data update message or a control update message.
更新メッセージ：データ更新メッセージまたは制御更新メッセージのいずれかであるメッセージ。
Data Update Message: An update message that is for a single ALTO information resource and sent from the update stream server to the ALTO client when the resource changes. A data update message can be either a full-replacement message or an incremental-change message. Full replacement is a shorthand for a full-replacement message, and incremental change is a shorthand for an incremental-change message.
データ更新メッセージ：リソースが変更されたときに、単一のALTO情報リソースの場合は更新メッセージを更新し、Update Stream ServerからALTOクライアントに送信されます。データ更新メッセージは、フル置換メッセージまたは増分変更メッセージのいずれかであり得る。フル置換は完全な交換メッセージのための省略形であり、インクリメンタル変更は増分変更メッセージのための短距離です。
Full Replacement: A data update message for a resource that encodes the content of the resource in its original ALTO encoding.
フル置換：元のALTOエンコーディング内のリソースの内容をエンコードするリソースのデータ更新メッセージ。
Incremental Change: A data update message that specifies only the difference between the new content and the previous version. An incremental change can be encoded using either JSON merge patch or JSON patch in this document.
増分変更：新しいコンテンツと前のバージョンの違いのみを指定するデータ更新メッセージ。このドキュメントのJSONマージパッチまたはJSONパッチを使用して、増分変更をエンコードできます。
Stream Control Service: A service that provides an HTTP URI so that the ALTO client of an update stream can use it to send stream control requests to the ALTO server on the addition or removal of resources receiving update messages from the update stream. The ALTO server creates a new stream control resource for each update stream instance, assigns a unique URI to it, and sends the URI to the client as the first event in the stream. (Note that the stream control service in ALTO has no association with the similarly named Stream Control Transmission Protocol [RFC4960].)
ストリーム制御サービス：アップデートストリームのALTOクライアントがそれを使用して、更新ストリームから更新されたメッセージを受信したリソースの追加または削除でALTOサーバにストリーム制御要求を送信できるようにHTTP URIを提供するサービス。ALTOサーバは、各アップデートストリームインスタンスに対して新しいストリーム制御リソースを作成し、それに一意のURIを割り当て、ストリーム内の最初のイベントとしてURIをクライアントに送信します。（AltoのStream Control Serviceは、同様にStream Control Transmission Protocol [RFC4960]と関連付けられていないことに注意してください。）
Stream Control: A shorthand for stream control service.
ストリーム制御：ストリーム制御サービスのための短距離。
Stream Control Server: An ALTO server providing the stream control service.
ストリーム制御サーバ：Stream Controlサービスを提供するALTOサーバ。
Substream-ID: An ALTO client can assign a unique substream-id when requesting the addition of a resource receiving update messages from an update stream. The server puts the substream-id in each update event for that resource. The substream-id allows a client to use one update stream to receive updates to multiple requests for the same resource (i.e., with the same resource-id in an ALTO IRD), for example, for a POST-mode resource with different input parameters.
サブサブシームID：ALTOクライアントは、更新ストリームから更新メッセージを受信したリソースの追加を要求するときに固有のサブストリームIDを割り当てることができます。サーバーはそのリソースの各更新イベントにサブストリームIDを置きます。サブストリームIDを使用すると、クライアントは1つの更新ストリームを使用して、異なる入力パラメータを持つポストモードリソースの場合など、同じリソースに対して（すなわち、ALTO IRD内の同じリソースIDで）複数の要求を受け取ることができます。。
Data-ID: A subfield of the "event" field of [SSE] to identify the ALTO data (object) to be updated. For an ALTO resource returning a multipart response, the data-id to identify the data (object) is the substream-id, in addition to the Content-ID of the object in the multipart response. The data-id of a single-part response is just the substream-id.
DATA-ID：更新するALTOデータ（オブジェクト）を識別するための[SSE]の「イベント」フィールドのサブフィールド。MultiPart応答を返すALTOリソースの場合、マルチパート応答内のオブジェクトのContent-IDに加えて、データ（Object）を識別するためのデータIDがサブストリームIDです。単一部分応答のデータIDはサブストリームIDだけです。
Control Update Message: An update message for the update stream server to notify the ALTO client of related control information of the update stream. A control update message may be triggered by an internal event at the server, such as server overloading and hence the update stream server will no longer send updates for an information resource, or as a result of a client sending a request through the stream control service. The first message of an update stream is a control update message that provides a control URI to the ALTO client. The ALTO client can use the URI to send stream control requests to the stream control server.
制御更新メッセージ：更新ストリームの関連制御情報のALTOクライアントに通知するための更新プログラムサーバの更新メッセージ。制御更新メッセージは、サーバのオーバーロードなどのサーバでの内部イベントによってトリガされてもよく、したがって更新ストリームサーバは情報リソースの更新を送信しなくなり、クライアントがストリーム制御サービスを通じて要求を送信する結果としてもよい。更新ストリームの最初のメッセージは、ALTOクライアントに制御URIを提供する制御更新メッセージである。ALTOクライアントはURIを使用してストリーム制御要求をストリーム制御サーバに送信できます。
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」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
The design requires two basic techniques: encoding of incremental changes and server push. For incremental changes, existing techniques include JSON merge patch and JSON patch; this design uses both. For server push, existing techniques include HTTP/2 and [SSE]; this design adopts some design features of HTTP/2 but uses [SSE] as the basic server-push design. The rest of this section gives a non-normative summary of JSON merge patch, JSON patch, HTTP/2, and [SSE].
設計には2つの基本的な技術が必要です。インクリメンタル変更とサーバープッシュのエンコード。増分変更のために、既存のテクニックにはJSON Merge PatchとJSONパッチが含まれます。この設計は両方を使用しています。サーバープッシュの場合、既存のテクニックにはHTTP / 2と[SSE]があります。この設計はHTTP / 2のデザイン機能を採用していますが、基本的なサーバープッシュデザインとして[SSE]を使用しています。このセクションの残りの部分では、JSONマージパッチ、JSONパッチ、HTTP / 2、[SSE]の非規範的な要約を示します。
To avoid always sending complete data, a server needs mechanisms to encode incremental changes, and JSON merge patch is one mechanism. [RFC7396] defines the encoding of incremental changes (called JSON merge patch objects) to be used by the HTTP PATCH method [RFC5789]. From [RFC7396], this document adopts only the JSON merge patch object encoding and does not use the HTTP PATCH method, as the updates are sent as events instead of HTTP methods; also, the updates are server to client, and PATCH semantics are more for client to server. Below is a non-normative summary of JSON merge patch objects; see [RFC7396] for the normative definition.
完全なデータを常に送信するのを避けるために、サーバーは増分変更をエンコードするメカニズムを必要とし、JSON Merge Patchは1つのメカニズムです。[RFC7396] HTTPパッチ方法[RFC5789]で使用する増分変更のエンコーディング（JSON Merge Patchオブジェクトと呼ばれます）を定義します。[RFC7396]から、この文書はJSON Merge Patchオブジェクトエンコーディングのみを採用し、更新プログラムはHTTPメソッドではなくイベントとして送信されるため、HTTPパッチメソッドを使用しません。また、更新プログラムはクライアントへのサーバーであり、パッチの意味はクライアントからサーバーへのものです。以下は、JSONマージパッチオブジェクトの非規範的な要約です。規範的定義の[RFC7396]を参照してください。
Informally, a JSON merge patch message consists of a JSON merge patch object (referred to as a patch in [RFC7396]), which defines how to transform one JSON value into another using a recursive merge patch algorithm. Specifically, the patch is computed by treating two JSON values (first one being the original and the second being the updated) as trees of nested JSON objects (dictionaries of name/value pairs), where the leaves are values (e.g., JSON arrays, strings, and numbers), other than JSON objects, and the path for each leaf is the sequence of keys leading to that leaf. When the second tree has a different value for a leaf at a path or adds a new leaf, the patch has a leaf, at that path, with the new value. When a leaf in the first tree does not exist in the second tree, the JSON merge patch tree has a leaf with a JSON "null" value. Hence, in the patch, null as the value of a name/value pair will delete the element with "name" in the original JSON value. The patch does not have an entry for any leaf that has the same value in both versions. See the MergePatch pseudocode at the beginning of Section 2 of [RFC7396] for the formal specification of how to apply a given patch. As a result, if all leaf values are simple scalars, JSON merge patch is a quite efficient representation of incremental changes. It is less efficient when leaf values are arrays, because JSON merge patch replaces arrays in their entirety, even if only one entry changes.
非公式には、JSONマージパッチメッセージはJSONマージパッチオブジェクト（[RFC7396]のパッチと呼ばれます）で構成されています。これにより、再帰的マージパッチアルゴリズムを使用して、1つのJSON値を別のJSON値に変換する方法を定義します。具体的には、パッチは、ネストされたJSONオブジェクトのツリー（Name / Value Paibの辞書）として、2つのJSON値（最初のものが更新され、2番目になる）を扱うことによって計算されます。葉が値（例：JSON配列など） JSONオブジェクト以外の文字列、および数字）、および各リーフのパスは、そのリーフにつながるキーのシーケンスです。 2番目のツリーがパスの葉の値が異なるか、新しいリーフを追加すると、そのパスに新しい値があるというパッチには、パッチがあります。最初のツリーのリーフが2番目のツリーに存在しない場合、JSONマージパッチツリーにはJSON "NULL"値があるリーフがあります。したがって、パッチでは、名前/値のペアの値としてNULLが元のJSON値の「名前」を持つ要素を削除します。パッチには、両方のバージョンで同じ値を持つ葉のエントリがありません。特定のパッチを適用する方法の正式な仕様については、[RFC7396]のセクション2の冒頭2のMergePatch Pseudocodeを参照してください。その結果、すべてのリーフ値が単純なスカラーの場合、JSON Merge Patchは、非常に効率的な段階的な変更を表しています。 JSONマージパッチは、1つのエントリが変更された場合でも、リーフの値が配列である場合は効率的です。
To provide both examples of JSON merge patch and a demonstration of the feasibility of applying JSON merge patch to ALTO, the sections below show the application of JSON merge patch to two key ALTO messages.
JSONマージパッチの例と、JSONマージパッチをALTOに適用する実現可能性の実証を提供するために、以下のセクションはJSON Mergeパッチの2つの主要なALTOメッセージへの適用を示しています。
Section 11.2.1.6 of [RFC7285] defines the format of an ALTO network map message. Assume a simple example ALTO message sending an initial network map:
[RFC7285]のセクション11.2.1.6 ALTOネットワークマップメッセージのフォーマットを定義します。初期ネットワークマップを送信する簡単な例ALTOメッセージを仮定します。
{
"meta" : {
"vtag": {
"resource-id" : "my-network-map",
"tag" : "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
}
},
"network-map" : {
"PID1" : {
"ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ]
},
"PID2" : {
"ipv4" : [ "198.51.100.128/25" ]
},
"PID3" : {
"ipv4" : [ "0.0.0.0/0" ],
"ipv6" : [ "::/0" ]
}
}
}
Consider the following JSON merge patch update message, which (1) adds an ipv4 prefix "203.0.113.0/25" and an ipv6 prefix "2001:db8:8000::/33" to "PID1", (2) deletes "PID2", and (3) assigns a new "tag" to the network map:
次のJSON Merge Patch Updateメッセージを検討します。この（1）は、IPv4プレフィックス "203.0.113.0/25"とIPv6プレフィックス "2001：DB8：8000 :: / 33"を「pid1」、（2）削除する "PID2を追加します。"、（3）ネットワークマップに新しい「タグ」を割り当てます。
{
"meta" : {
"vtag" : {
"tag" : "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
}
},
"network-map": {
"PID1" : {
"ipv4" : [ "192.0.2.0/24", "198.51.100.0/25",
"203.0.113.0/25" ],
"ipv6" : [ "2001:db8:8000::/33" ]
},
"PID2" : null
}
}
Applying the JSON merge patch update to the initial network map is equivalent to the following ALTO network map:
初期ネットワークマップへのJSONマージパッチ更新の適用は、次のALTOネットワークマップと同じです。
{
"meta" : {
"vtag": {
"resource-id" : "my-network-map",
"tag" : "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
}
},
"network-map" : {
"PID1" : {
"ipv4" : [ "192.0.2.0/24", "198.51.100.0/25",
"203.0.113.0/25" ],
"ipv6" : [ "2001:db8:8000::/33" ]
},
"PID3" : {
"ipv4" : [ "0.0.0.0/0" ],
"ipv6" : [ "::/0" ]
}
}
}
Section 11.2.3.6 of [RFC7285] defines the format of an ALTO cost map message. Assume a simple example ALTO message for an initial cost map:
[RFC7285]のセクション11.2.3.6 ALTO原価マップメッセージのフォーマットを定義します。初期コストマップのための簡単な例ALTOメッセージを想定します。
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-network-map",
"tag": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
}
],
"cost-type" : {
"cost-mode" : "numerical",
"cost-metric": "routingcost"
},
"vtag": {
"resource-id" : "my-cost-map",
"tag" : "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
}
},
"cost-map" : {
"PID1": { "PID1": 1, "PID2": 5, "PID3": 10 },
"PID2": { "PID1": 5, "PID2": 1, "PID3": 15 },
"PID3": { "PID1": 20, "PID2": 15 }
}
}
The following JSON merge patch message updates the example cost map so that (1) the "tag" field of the cost map is updated, (2) the cost of PID1->PID2 is 9 instead of 5, (3) the cost of PID3->PID1 is no longer available, and (4) the cost of PID3->PID3 is defined as 1.
次のJSONマージパッチメッセージは、（1）コストマップの「タグ」フィールドが更新されるように、（2）PID1-> PID2のコストが5ではなく9、（3）のコストPID3-> PID1はもう利用できなくなり、（4）PID3-> PID3のコストを1と定義します。
{
"meta" : {
"vtag": {
"tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"
}
}
"cost-map" : {
"PID1" : { "PID2" : 9 },
"PID3" : { "PID1" : null, "PID3" : 1 }
}
}
Hence, applying the JSON merge patch to the initial cost map is equivalent to the following ALTO cost map:
したがって、JSONマージパッチを初期コストマップに適用することは、次のALTOコストマップに相当します。
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-network-map",
"tag": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
}
],
"cost-type" : {
"cost-mode" : "numerical",
"cost-metric": "routingcost"
},
"vtag": {
"resource-id": "my-cost-map",
"tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"
}
},
"cost-map" : {
"PID1": { "PID1": 1, "PID2": 9, "PID3": 10 },
"PID2": { "PID1": 5, "PID2": 1, "PID3": 15 },
"PID3": { "PID2": 15, "PID3": 1 }
}
}
One issue of JSON merge patch is that it does not handle array changes well. In particular, JSON merge patch considers an array as a single object and hence can only replace an array in its entirety. When the change is to make a small change to an array, such as the deletion of an element from a large array, whole-array replacement is inefficient. Consider the example in Section 3.1.2.1. To add a new entry to the ipv4 array for PID1, the server needs to send a whole new array. Another issue is that JSON merge patch cannot change a value to be null, as the JSON merge patch processing algorithm (MergePatch in Section 3.1.1) interprets a null as a removal instruction. On the other hand, some ALTO resources can have null values, and it is possible that the update will want to change the new value to be null.
JSON Merge Patchの1つの問題は、配列の変更をうまく処理しないことです。特に、JSON Merge Patchは、配列を単一のオブジェクトとして考慮しており、したがってアレイを全体として置き換えることができます。大きなアレイからの要素の削除など、変更が小さい場合は、アレイ全体の置換が非効率的である場合は、配列に小さな変更を加えることができます。セクション3.1.2.1の例を検討してください。PID1のIPv4配列に新しいエントリを追加するには、サーバーは新しい配列全体を送信する必要があります。もう1つの問題は、JSON Merge Patch Processing Algorithm（セクション3.1.1のMergePatch）が削除指示としてNULLを解釈するため、JSON Merge PatchがNULLに変更できないということです。一方、いくつかのALTOリソースはNULL値を持つことができ、更新がNULLになるように新しい値を変更することが可能である可能性があります。
JSON patch [RFC6902] can address the preceding issues. It defines a set of operators to modify a JSON object. See [RFC6902] for the normative definition.
JSONパッチ[RFC6902]前述の問題に対処できます。JSONオブジェクトを変更するための一連の演算子を定義します。規範的定義の[RFC6902]を参照してください。
To provide both examples of JSON patch and a demonstration of the difference between JSON patch and JSON merge patch, the sections below show the application of JSON patch to the same updates shown in Section 3.1.2.
JSONパッチの例とJSONパッチとJSONのマージパッチの違いのデモンストレーションの両方を提供するために、以下のセクションでは、セクション3.1.2に示されている同じ更新プログラムへのJSONパッチのアプリケーションを示します。
First, consider the same update as in Section 3.1.2.1 for the network map. Below is the encoding using JSON patch:
まず、ネットワークマップの3.1.2.1項と同じ更新を検討してください。以下はJSONパッチを使用したエンコーディングです。
[
{
"op": "replace",
"path": "/meta/vtag/tag",
"value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
},
{
"op": "add",
"path": "/network-map/PID1/ipv4/2",
"value": "203.0.113.0/25"
}
{
"op": "add",
"path": "/network-map/PID1/ipv6",
"value": ["2001:db8:8000::/33"]
},
{
"op": "remove",
"path": "/network-map/PID2"
}
]
Compared with JSON merge patch, JSON patch does not encode cost map updates efficiently. Consider the cost map update shown in Section 3.1.2.2, the encoding using JSON patch is:
JSON Merge Patchと比較して、JSONパッチは効率的にコストマップの更新をエンコードしません。セクション3.1.2.2に示す原価マップの更新を考慮して、JSONパッチを使用したエンコーディングは次のとおりです。
[
{
"op": "replace",
"path": "/meta/vtag/tag",
"value": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"
},
{
"op": "replace",
"path": "/cost-map/PID1/PID2",
"value": 9
},
{
"op": "remove",
"path": "/cost-map/PID3/PID1"
},
{
"op": "replace",
"path": "/cost-map/PID3/PID3",
"value": 1
}
]
HTTP/2 [RFC7540] provides two related features: multiplexing and server push. In particular, HTTP/2 allows a client and a server to multiplex multiple HTTP requests and responses over a single TCP connection. The requests and responses can be interleaved on a block (frame) by block (frame) basis, by indicating the requests and responses in HTTP/2 messages, avoiding the head-of-line blocking problem encountered with HTTP/1.1. To achieve the same goal, this design introduces substream-id to allow a client to receive updates to multiple resources. HTTP/2 also provides a server-push facility to allow a server to send asynchronous updates.
HTTP / 2 [RFC7540]は、多重化とサーバープッシュの2つの関連機能を提供します。特に、HTTP / 2では、クライアントとサーバーが単一のTCP接続を介して複数のHTTP要求と応答を多重化できます。要求および応答は、HTTP / 2メッセージ内の要求および応答を示すことによって、ブロック（フレーム）でブロック（フレーム）でインターリーブすることができ、HTTP / 2.1で発生した回線ブロック解決の問題を回避する。同じ目標を達成するために、この設計では、クライアントが複数のリソースへの更新を受信できるようにSubstream-IDを導入します。HTTP / 2には、サーバーが非同期アップデートを送信できるようにサーバープッシュ機能も提供します。
Despite the two features of HTTP/2, this design chooses a design compatible with HTTP/1.x for the simplicity of HTTP/1.x. A design based on HTTP/2 may more likely need to be implemented using a more complex HTTP/2 client library. In such a case, one approach for using server push for updates is for the update stream server to send each data update message as a separate server-push item and let the client apply those updates as they arrive. An HTTP/2 client library may not necessarily inform a client application when the server pushes a resource. Instead, the library might cache the pushed resource and only deliver it to the client when the client explicitly requests that URI. Further, it is more likely that a design based on HTTP/2 may encounter issues with a proxy between the client and the server, in that server push is optional and can be disabled by any proxy between the client and the server. This is not a problem for the intended use of server push; eventually, the client will request those resources, so disabling server push just adds a delay. But this means that Server Push is not suitable for resources that the client does not know to request.
HTTP / 2の2つの機能にもかかわらず、この設計はHTTP / 1.xの単純さのためにHTTP / 1.xと互換性のある設計を選択します。 HTTP / 2に基づく設計は、より複雑なHTTP / 2クライアントライブラリを使用して実装する可能性が高いです。そのような場合、アップデートのためのサーバープッシュを使用するための1つのアプローチは、アップデートStream Serverが各データ更新メッセージを別々のサーバープッシュ項目として送信し、それらが到着したときにそれらの更新を適用させるためのものです。 HTTP / 2クライアントライブラリは、サーバーがリソースをプッシュしたときに必ずしもクライアントアプリケーションに通知されない場合があります。代わりに、ライブラリはプッシュされたリソースをキャッシュすることができ、クライアントが明示的にそのURIを要求するときにのみクライアントに配信することができます。さらに、HTTP / 2に基づく設計は、そのサーバプッシュがオプションであり、クライアントとサーバ間の任意のプロキシによって無効にすることができる。これは、サーバープッシュの使用目的の使用に問題ありません。最終的には、クライアントはそれらのリソースを要求しますので、サーバープッシュを無効にするだけで遅延を追加します。しかしこれは、サーバープッシュがクライアントが要求することを知らないリソースに適していないことを意味します。
Thus, this design leaves a design based on HTTP/2 as a future work and focuses on ALTO updates on HTTP/1.x and [SSE].
したがって、このデザインは将来の作業としてhttp / 2に基づく設計を残し、http / 1.xと[sse]のAltoの更新に焦点を当てます。
Server-Sent Events (SSE) are techniques that can work with HTTP/1.1. The following is a non-normative summary of SSE; see [SSE] for its normative definition.
サーバー送信イベント（SSE）は、HTTP / 1.1で動作できるテクニックです。以下は、SSEの非規範的な要約です。その規範的定義の[SSE]を参照してください。
SSE enable a server to send new data to a client by "server push". The client establishes an HTTP [RFC7230] [RFC7231] connection to the server and keeps the connection open. The server continually sends messages. Each message has one or more lines, where a line is terminated by a carriage return immediately followed by a new line, a carriage return not immediately followed by a new line, or a new line not immediately preceded by a carriage return. A message is terminated by a blank line (two line terminators in a row).
SSEは、サーバーを「サーバープッシュ」で新しいデータをクライアントに送信できるようにします。クライアントは、HTTP [RFC7230] [RFC7231] [RFC7231]接続をサーバーに接続し、接続を開いたままにします。サーバーは継続的にメッセージを送信します。各メッセージには1行ずつ1行があり、その後のキャリッジリターンで直ちに新しい行が終了した場合、キャリッジリターンはすぐに新しい回線、またはキャリッジリターンが直前にされない新しい行です。メッセージは空白行（行内の2行のターミネータ）によって終了されます。
Each line in a message is of the form "field-name: string value". Lines with a blank field name (that is, lines that start with a colon) are ignored, as are lines that do not have a colon. The protocol defines three field names: event, id, and data. If a message has more than one "data" line, the value of the data field is the concatenation of the values on those lines. There can be only one "event" and "id" line per message. The "data" field is required; the others are optional.
メッセージ内の各行は、 "field-name：string value"の形式です。結腸がない行のように、空白のフィールド名（つまり、コロンで始まる行）を持つ行は無視されます。プロトコルは、イベント、ID、およびデータの3つのフィールド名を定義します。メッセージが複数の「データ」回線が複数ある場合、データフィールドの値はそれらの行の値の連結です。メッセージごとに「イベント」と「ID」行だけがあります。「データ」フィールドが必要です。他のものはオプションです。
Figure 1 is a sample SSE stream, starting with the client request. The server sends three events and then closes the stream.
図1は、クライアント要求から始めて、SSEストリームのサンプルです。サーバーは3つのイベントを送信してからストリームを閉じます。
(Client request) GET /stream HTTP/1.1 Host: example.com Accept: text/event-stream
（クライアントリクエスト）Get / Stream HTTP / 1.1ホスト：example.com accept：text / event-stream
(Server response) HTTP/1.1 200 OK Connection: keep-alive Content-Type: text/event-stream
（サーバーの応答）HTTP / 1.1 200 OK接続：キープアライブコンテンツタイプ：テキスト/イベントストリーム
event: start id: 1 data: hello there
イベント：スタートID：1データ：こんにちは
event: middle id: 2 data: let's chat some more ... data: and more and more and ...
イベント：ミドルID：2データ：もう少しチャットしましょう...データ：など...
event: end id: 3 data: goodbye
イベント：エンドID：3データ：さようなら
Figure 1: A Sample SSE Stream
図1：サンプルSSEストリーム
With the preceding background, this section now gives a non-normative overview of the update mechanisms and message flow to be defined in later sections of this document. Figure 2 gives the main components and overall message flow.
前述の背景では、このセクションでは、このドキュメントの後述のセクションで定義される更新メカニズムとメッセージフローの非規範的な概要を示します。図2は、主要な構成要素と全体のメッセージフローを示しています。
-------------------------------------------------------------------
| |
| +-------+ +-------+ 1. init request +------+ |
| | | | | <-------------- | | |
| | | | | --------------> | | |
| 3.add/ | | | | 1'. control URI | | |
| remove | | | | | | |
| resource |Stream | |Update | | | |
-------->|Control| private |Stream | 2a. data update |Client| --
|Server |<------->|Server | messages | |
-------- | | | | ---------------> | | <-
| response | | | | ---------------> | | |
| | | | | 2b. control update| | |
| +-------+ +-------+ messages +------+ |
| |
-------------------------------------------------------------------
Figure 2: ALTO SSE Architecture and Message Flow
図2：ALTO SSEアーキテクチャとメッセージフロー
The building block of the update mechanism defined in this document is the update stream service (defined in Section 6), where each update stream service is a POST-mode service that provides update streams.
この文書で定義されている更新メカニズムのビルディングブロックは、更新ストリームサービスが更新ストリームを提供するポストモードサービスである更新ストリームサービスです。
Note that the lines of the format "** ... **" are used to describe message flows in this section and the following sections.
このセクションのメッセージフローと次のセクションのメッセージフローを記述するために、 "** ... **"の線が使用されていることに注意してください。
** Initial request: client -> update server **: When an ALTO client requests an update stream service, the ALTO client establishes a persistent connection to the update stream server and submits an initial update-stream request (defined in Section 6.5), creating an update stream. This initial request creating the update stream is labeled "1. init request" in Figure 2.
**クライアント - > update server **：ALTOクライアントがアップデートストリームサービスを要求すると、ALTOクライアントはUpdate Stream Serverへの永続的な接続を確立し、初期更新ストリーム要求を送信します（セクション6.5で定義）。更新ストリームを作成します。更新プログラムストリームの作成この初期要求には、図2の「1. init要求」とラベルが付いています。
An update stream can provide updates to both GET-mode resources, such as ALTO network and cost maps, and POST-mode resources, such as ALTO endpoint property service. Also, to avoid creating too many update streams, this design allows an ALTO client to use one update stream to receive updates to multiple requests. In particular, the client may request to receive updates for the same resource but with different parameters for a POST-mode resource, in addition to being able to consolidate updates for multiple resources into a single stream. The updates for each request is called a substream and hence the update server needs an identifier to indicate the substream when sending an update. To achieve this goal, the client assigns a unique substream-id when requesting updates to a resource in an update stream, and the server puts the substream-id in each update.
更新ストリームは、ALTOネットワークやコストマップなどのGETモードリソース、およびAlto Endpoint Property Serviceなどのポストモードのリソースの両方に更新を提供できます。また、更新ストリームが多すぎることを回避するために、この設計により、ALTOクライアントが1つの更新ストリームを使用して複数の要求に更新を受け取ることができます。特に、クライアントは、複数のリソースに対する更新を単一のストリームに統合できることに加えて、同じリソースに対する更新を受信することを要求することができる。各要求の更新はサブストリームと呼ばれ、更新サーバは更新を送信するときにサブストリームを示す識別子を必要とする。この目的を達成するために、アップデートストリーム内のリソースへの更新を要求するときにクライアントは一意のサブストリームIDを割り当て、サーバは各更新にサブストリームIDを入力します。
** Data updates: update server -> client **: The objective of an update stream is to continuously push (to an ALTO client) the data value changes for a set of resources, where the set of resources is specified by the ALTO client's requests. This document refers to messages sending such data-value changes as data update messages (defined in Section 5.2). Although an update stream may update one or more requests, each data update message updates only one request and is sent as a Server-Sent Event (SSE), as defined by [SSE]. A data update message is encoded either as a full replacement or as an incremental change. A full replacement uses the JSON message format defined by the ALTO protocol. There can be multiple encodings for incremental changes. The current design supports incremental changes using JSON merge patch [RFC7396] or JSON patch [RFC6902] to describe the changes of the resource. Future documents may define additional mechanisms for incremental changes. The update stream server decides when to send data update messages and whether to send full replacements or incremental changes. These decisions can vary from resource to resource and from update to update. Since the transport is a design compatible with HTTP/1.x, data update messages are delivered reliably and in order, and the lossless, sequential delivery of its messages allows the server to know the exact state of the client to compute the correct incremental updates. Figure 2 shows examples of data update messages (labeled "2a. data update messages") in the overall message flow.
**データ更新：Update Server - > Client **：アップデートストリームの目的は（ALTOクライアントに）（ALTOクライアントに）変更されます（ALTOクライアントに）データ値が変更され、リソースのセットがALTOクライアントによって指定されているリソースのセットが指定されます。リクエスト。このドキュメントは、そのようなデータ値の変更をデータ更新メッセージとして送信するメッセージを参照します（セクション5.2で定義）。更新ストリームは1つまたは複数の要求を更新することができるが、各データ更新メッセージは1つの要求のみを更新し、[SSE]によって定義されるようにサーバ送信イベント（SSE）として送信される。データ更新メッセージは、フル置換または増分変更としてエンコードされます。フル置換は、ALTOプロトコルによって定義されたJSONメッセージフォーマットを使用します。増分変更には複数のエンコーディングがあります。現在の設計は、リソースの変更を説明するためのJSON Merge Patch [RFC7396]またはJSONパッチ[RFC6902]を使用した増分変更をサポートしています。将来の文書は、増分変更のための追加のメカニズムを定義するかもしれません。 Update Stream Serverは、データの更新メッセージを送信するかどうか、および全置換または増分変更を送信するかを決定します。これらの決定はリソースからリソースまで、更新から更新までさまざまです。トランスポートはHTTP / 1.xと互換性のある設計であるため、データの更新メッセージは確実に、順番に配信され、そのメッセージの無限のシーケンシャル配信により、サーバーはクライアントの正確な状態を計算するためにサーバーが正しい増分アップデートを計算することができます。 。図2は、全体的なメッセージフローにおけるデータ更新メッセージ（「2A。データ更新メッセージ」と表示された）の例を示す。
** Control updates: update server -> client **: An update stream can run for a long time and hence there can be status changes at the update stream server side during the lifetime of an update stream; for example, the update stream server may encounter an error or need to shut down for maintenance. To support a robust, flexible protocol design, this document allows the update stream server to send control update messages (defined in Section 5.3) in addition to data update messages to the ALTO client. Figure 2 shows that both data updates and control updates can be sent by the server to the client (labeled "2b. control update messages").
**コントロールアップデート：Update Server - > Client **：更新ストリームは長時間実行でき、更新ストリームの有効期間中に更新ストリームサーバ側でステータス変更が発生する可能性があります。例えば、更新ストリームサーバはエラーが発生したり、メンテナンスのためにシャットダウンする必要があるかもしれません。堅牢で柔軟なプロトコル設計をサポートするために、このドキュメントでは、Altoクライアントへのデータ更新メッセージに加えて、更新ストリームサーバが制御更新メッセージ（セクション5.3で定義）を送信することができます。図2は、データの更新と制御の両方の更新をサーバーからクライアントに送信できることを示しています（ "2b"のラベル付き "）。
** Stream control: client -> stream control server **: In addition to control changes triggered from the update stream server side, in a flexible design, an ALTO client may initiate control changes as well, in particular, by adding or removing ALTO resources receiving updates. An ALTO client initiates such changes using the stream control service (defined in Section 7). Although one may use a design that the client uses as the same HTTP connection to send the control requests, it requires stronger server support, such as HTTP pipeline. For more flexibility, this document introduces stream control service. In particular, the update stream server of an update stream uses the first message to provide the URI of the stream control service (labeled "1': control URI" in Figure 2).
**ストリームコントロール：クライアント - > Stream Control Server **：更新ストリームサーバー側からトリガーされたコントロール変更に加えて、柔軟な設計で、ALTOクライアントは、特にALTOを追加または削除することによって制御の変化も開始することがあります。リソースを受信します。ALTOクライアントは、ストリーム制御サービスを使用してそのような変更を開始します（セクション7で定義）。クライアントが同じHTTP接続として使用するデザインを使用して、制御要求を送信することができますが、HTTPパイプラインなどのより強力なサーバーサポートが必要です。より柔軟性のために、この文書はStream Controlサービスを発表します。特に、アップデートストリームの更新ストリームサーバは、第1のメッセージを使用して、ストリーム制御サービスのURI（図2の「1 '：制御URI」というラベル）を提供する。
The ALTO client can then use the URI to ask the stream control server specified in the URI to request the update stream server to (1) send data update messages for additional resources, (2) stop sending data update messages for previously requested resources, or (3) gracefully stop and close the update stream altogether.
その後、ALTOクライアントはURIを使用してURIで指定されたストリーム制御サーバーに（1）追加のリソースのデータの送信メッセージを送信する（2）以前に要求されたリソースのデータ更新メッセージの送信を停止することができます。（3）更新ストリームを完全に停止して閉じる。
** Service announcements: IRD server -> client **: An update server may provide any number of update stream services, where each update stream may provide updates for a given subset of the ALTO server's resources. An ALTO server's Information Resource Directory (IRD) defines the update stream services and declares the set of resources for which each update stream service provides updates. The ALTO server selects the resource set for each update stream service. It is recommended that if a resource depends on one or more other resource(s) (indicated with the "uses" attribute defined in [RFC7285]), these other resource(s) should also be part of that update stream. Thus, the update stream for a cost map should also provide updates for the network map on which that cost map depends.
**サービスのお知らせ：IRD Server - > Client **：アップデートサーバーは、任意の数の更新ストリームサービスを提供し、各更新ストリームはALTOサーバーのリソースの特定のサブセットの更新を提供することができます。ALTOサーバの情報リソースディレクトリ（IRD）は、アップデートストリームサービスを定義し、各更新ストリームサービスが更新を提供するリソースのセットを宣言します。ALTOサーバは、更新ストリームサービスごとに設定されたリソースを選択します。リソースが1つ以上の他のリソースに依存する場合（RFC7285]で定義されている「使用」属性で示されている）、これらの他のリソースもその更新ストリームの一部になる必要があります。したがって、コストマップのための更新ストリームは、そのコストマップが依存するネットワークマップの更新も提供する必要があります。
** Service management (server) **: An ALTO client may request any number of update streams simultaneously. Because each update stream consumes resources on the update stream server, an update stream server may require client authorization and/or authentication, limit the number of open update streams, close inactive streams, or redirect an ALTO client to another update stream server.
**サービス管理（サーバー）**：ALTOクライアントは、任意の数の更新ストリームを同時に要求することができます。更新ストリームはアップデートStream Server上のリソースを消費するため、アップデートStream Serverはクライアント認証および/または認証を必要とし、オープンアップデートストリームの数を制限し、非アクティブなストリームを閉じるか、またはALTOクライアントを別のアップデートストリームサーバーにリダイレクトすることができます。
This section defines the format of update messages sent from the server to the client. It first defines the generic structure of update messages (Section 5.1). It then defines the details of the data update messages (Section 5.2) and the control update messages (Section 5.3). These messages will be used in the next two sections to define the update stream service (Section 6) and the stream control service (Section 7).
このセクションでは、サーバーからクライアントに送信された更新メッセージのフォーマットを定義します。まず、更新メッセージの総称構造を定義します（セクション5.1）。その後、データ更新メッセージ（セクション5.2）と制御更新メッセージの詳細を定義します（セクション5.3）。これらのメッセージは、更新ストリームサービス（セクション6）およびストリーム制御サービスを定義するために次の2つのセクションで使用されます。
Both data update and control update messages from the server to the client have the same basic structure. Each message includes a data field to provide data information, which is typically a JSON object, and an event field preceding the data field, to specify the media type indicating the encoding of the data field.
サーバーからクライアントへのデータの更新メッセージと制御の両方の更新メッセージは同じ基本構造を持ちます。各メッセージは、データフィールドの符号化を示すメディアタイプを指定するための、通常、JSONオブジェクト、およびデータフィールドの前のイベントフィールドを提供するためのデータフィールドを含む。
A data update message needs additional information to identify the ALTO data (object) to which the update message applies. To be generic, this document uses a data-id to identify the ALTO data (object) to be updated; see below.
データ更新メッセージは、更新メッセージが適用されるALTOデータ（オブジェクト）を識別するための追加情報を必要とする。一般的になるために、この文書はデータIDを使用して更新されるべきALTOデータ（オブジェクト）を識別します。下記参照。
Hence, the event field of ALTO update message can include two subfields (media-type and data-id), where the two subfields are separated by a comma (',', U+002C):
したがって、ALTO更新メッセージのイベントフィールドは、2つのサブフィールド（メディアタイプおよびデータID）を含むことができ、2つのサブフィールドはカンマ（ '、'、U 002C）によって区切られている。
media-type [ ',' data-id ]
メディアタイプ['、'データID]
According to Section 4.2 of [RFC6838], the comma character is not allowed in a media-type name so there is no ambiguity when decoding of the two subfields.
[RFC6838]のセクション4.2によると、カンマ文字はメディアタイプ名では許可されていませんので、2つのサブフィールドをデコードするときにあいまいさがない。
Note that an update message does not use the SSE "id" field.
更新メッセージはSSE "ID"フィールドを使用しません。
A data update message is sent when a monitored resource changes. As discussed in the preceding section, the event field of a data update message includes two subfields: 'media-type' and 'data-id'.
監視対象リソースが変更されたときにデータ更新メッセージが送信されます。前述のセクションで説明したように、データ更新メッセージのイベントフィールドには、「メディアタイプ」と「データID」の2つのサブフィールドが含まれています。
The 'media-type' subfield depends on whether the data update is a complete specification of the identified data or an incremental patch (e.g., a JSON merge patch or JSON patch), if possible, describing the changes from the last version of the data. This document refers to these as full replacement and incremental change, respectively. The encoding of a full replacement is defined by its defining document (e.g., network and cost map messages by [RFC7285]) and uses the media type defined in that document. The encoding of JSON merge patch is defined by [RFC7396], with the media type "application/merge-patch+json"; the encoding of JSON patch is defined by [RFC6902], with media type "application/json-patch+json".
'media-type'サブフィールドは、データの最後のバージョンからの変更を説明して、データの更新が識別されたデータの完全な指定または増分パッチ（例えば、JSON Merge PatchまたはJSONパッチ）のどちらであるかによって異なります。。この文書は、それぞれ完全な交換および増分変化としてのものを指します。完全な置き換えの符号化は、その定義文書（例えば、[RFC7285]によるネットワークおよび原価マップメッセージ）によって定義され、その文書で定義されたメディアタイプを使用する。JSON Mergeパッチのエンコーディングは[RFC7396]で定義されています。メディアタイプ "application / merge-patch json";JSONパッチのエンコーディングは[RFC6902]によって、メディアタイプの「application / json-patch JSON」と定義されています。
The 'data-id' subfield identifies the ALTO data to which the data update message applies.
'data-id'サブフィールドは、データ更新メッセージが適用されるALTOデータを識別します。
First, consider the case that the resource contains only a single JSON object. For example, since an ALTO client can request data updates for both a cost map resource (object) and its dependent network map resource (object) in the same update stream, to distinguish the updates, the client assigns a substream-id for each resource receiving data updates. Substream-ids MUST be unique within an update stream but need not be globally unique. A substream-id is encoded as a JSON string with the same format as that of the type ResourceID (Section 10.2 of [RFC7285]). The type SubstreamID is used in this document to indicate a string of this format. The substream-id of a single JSON object is the 'data-id'.
まず、リソースに単一のJSONオブジェクトのみが含まれている場合を検討してください。たとえば、ALTOクライアントは、同じアップデートストリーム内のコストマップリソース（オブジェクト）とその依存ネットワークマップリソース（オブジェクト）の両方に対してデータ更新を要求することができます。更新を区別するために、クライアントはリソースごとにサブサブシームIDを割り当てます。データの更新を受信します。Substream-IDはアップデートストリーム内で一意である必要がありますが、グローバルに一意である必要はありません。サブストリームIDは、Type ResourceIDと同じ形式のJSON文字列として符号化されている（[RFC7285]のセクション10.2）。このフォーマットの文字列を示すために、Substramid型がこのドキュメントで使用されています。単一のJSONオブジェクトのサブストリームIDは 'data-id'です。
As an example, assume that the ALTO client assigns substream-id "1" in its request to receive updates to the network map and substream-id "2" to the cost map. Then, the substream-ids are the data-ids indicating which objects will be updated. Figure 3 shows some examples of ALTO data update messages:
一例として、ALTOクライアントが、ネットワークマップおよびサブストリームID「2」への更新をコストマップに受信する要求にサブストリームID「1」を割り当てると仮定する。そして、サブストリームIDSはどのオブジェクトが更新されるかを示すデータIDである。図3は、ALTOデータ更新メッセージの例を示しています。
event: application/alto-networkmap+json,1
data: { ... full network map message ... }
event: application/alto-costmap+json,2
data: { ... full cost map message ... }
event: application/merge-patch+json,2
data: { ... JSON merge patch update for the cost map ... }
Figure 3: Examples of ALTO Data Update Messages
図3：ALTOデータ更新メッセージの例
Next, consider the case that a resource may include multiple JSON objects. This document considers the case that a resource may contain multiple components (parts), and they are encoded using the media type "multipart/related" [RFC2387]. Each part of this multipart response MUST be an HTTP message including a Content-ID header and a JSON object body. Each component requiring the update stream service (defined in Section 6) MUST be identified by a unique Content-ID to be defined in its defining document.
次に、リソースが複数のJSONオブジェクトを含めることができる場合を考える。この資料は、リソースに複数のコンポーネント（部品）を含めることができ、それらはメディアタイプ「MULTIPART / RESERTION」[RFC2387]を使用してエンコードされます。このマルチパート応答の各部分は、Content-IDヘッダーとJSONオブジェクト本体を含むHTTPメッセージでなければなりません。Update Streamサービスを必要とする各コンポーネント（セクション6で定義）は、その定義文書で定義される固有のコンテンツIDによって識別されなければなりません。
For a resource using the media type "multipart/related", the 'data-id' subfield MUST be the concatenation of the substream-id, the '.' separator (U+002E), and the unique Content-ID, in order.
メディアタイプ「マルチパート/関連」を使用したリソースの場合、 'data-id'サブフィールドはサブストリームID、 '。'の連結でなければなりません。区切り文字（U 002E）、および固有のコンテンツID、順に。
Control update messages have the media type "application/alto-updatestreamcontrol+json", and the data is of type UpdateStreamControlEvent:
コントロールアップデートメッセージには、メディアタイプ "application / alto-updateStreamControl JSON"があり、データはupdateStreamControlEvent型です。
object {
[String control-uri;]
[SubstreamID started<1..*>;]
[SubstreamID stopped<1..*>;]
[String description;]
} UpdateStreamControlEvent;
control-uri: the URI providing stream control for this update stream (see Section 7). The server sends a control update message notifying the client of the control-uri. This control update message notifying the control-uri will be sent once and MUST be the first event in an update stream. If the URI value is NULL, the update stream server does not support stream control for this update stream; otherwise, the update stream server provides stream control through the given URI.
CONTROL-URI：このアップデート・ストリームのためのURI提供のストリーム制御（セクション7を参照）。サーバは、制御URIのクライアントに通知する制御更新メッセージを送信する。制御URIを通知するこの制御更新プログラムメッセージは1回送信され、更新ストリームの最初のイベントでなければなりません。URI値がNULLの場合、Update Stream Serverはこの更新ストリームのストリーム制御をサポートしません。それ以外の場合、Update Stream Serverは与えられたURIを介してストリーム制御を提供します。
started: a list of substream-ids of resources. It notifies the ALTO client that the update stream server will start sending data update messages for each resource listed.
開始：リソースのサブストリームIDのリスト。AltoクライアントにアップデートStream Serverがリストされている各リソースに対してデータ更新メッセージの送信を開始することを通知します。
stopped: a list of substream-ids of resources. It notifies the ALTO client that the update stream server will no longer send data update messages for the listed resources. There can be multiple reasons for an update stream server to stop sending data update messages for a resource, including a request from the ALTO client using stream control (Section 6.7.1) or an internal server event.
停止しました：リソースのサブストリームIDのリスト。これは、Update Stream Serverがリストされているリソースに対してデータ更新メッセージを送信しなくなることをALTOクライアントに通知します。Stream Control（6.7.1項）または内部サーバーイベントを使用して、ALTOクライアントからの要求を含む、リソースのデータ更新メッセージの送信を停止するためのアップデートStream Serverが複数の理由がある可能性があります。
description: a non-normative, human-readable text providing an explanation for the control event. When an update stream server stops sending data update messages for a resource, it is RECOMMENDED that the update stream server use the description field to provide details. There can be multiple reasons that trigger a "stopped" event; see above. The intention of this field is to provide a human-readable text for the developer and/or the administrator to diagnose potential problems.
説明：制御イベントの説明を提供する非規範的な人間が読めるテキスト。アップデートStream Serverがリソースのデータ更新メッセージの送信を停止すると、更新ストリームサーバーが説明フィールドを使用して詳細を提供することをお勧めします。「停止」イベントを引き起こす複数の理由がある可能性があります。上記を参照。この分野の意図は、開発者および/または管理者に潜在的な問題を診断するための人間が読めるテキストを提供することである。
An update stream service returns a stream of update messages, as defined in Section 5. An ALTO server's IRD (Information Resource Directory) MAY define one or more update stream services, which ALTO clients use to request new update stream instances. An IRD entry defining an update stream service MUST define the media type, HTTP method, and capabilities and uses as follows.
Update Stream Serviceは、セクション5で定義されているように、更新メッセージのストリームを返します.Alto ServerのIRD（Information Resource Directory）は、1つ以上のアップデートストリームサービスを定義することができます。これは、クライアントが新しいアップデートストリームインスタンスを要求するために使用する。アップデートストリームサービスを定義するIRDエントリは、メディアタイプ、HTTPメソッド、および機能を定義し、次のように使用する必要があります。
The media type of an ALTO update stream service is "text/event-stream", as defined by [SSE].
Alto Update Streamサービスのメディアタイプは、[SSE]によって定義されているように、 "text / event-stream"です。
An ALTO update stream service is requested using the HTTP POST method.
HTTP POSTメソッドを使用して、ALTO更新ストリームサービスが要求されます。
The capabilities are defined as an object of type UpdateStreamCapabilities:
機能は、updateStreamCapabilities型のオブジェクトとして定義されています。
object {
IncrementalUpdateMediaTypes incremental-change-media-types;
Boolean support-stream-control;
} UpdateStreamCapabilities;
object-map {
ResourceID -> String;
} IncrementalUpdateMediaTypes;
If this update stream can provide data update messages with incremental changes for a resource, the "incremental-change-media-types" field has an entry for that resource-id, and the value is the supported media types of the incremental change separated by commas. Normally, this will be "application/merge-patch+json", "application/ json-patch+json", or "application/merge-patch+json,application/json-patch+json", because, as described in Section 5, they are the only incremental change types defined by this document. However, future extensions may define other types of incremental changes.
この更新プログラムストリームがリソースに対して増分変更を伴うデータ更新メッセージを提供できる場合、「incremental-change-media-types」フィールドにはそのリソースIDのエントリがあり、値は区切られた増分変更のサポートされているメディアタイプです。カンマ通常、これは "Application / Merge-Patch JSON"、 "Application / JSON-Patch JSON"、または "Application / Merge-Patch JSON、Application / JSON-Patch JSON"になります。この文書で定義されている唯一の増分変更タイプ。ただし、将来の拡張機能は、他の種類の増分変更を定義することがあります。
When choosing the media types to encode incremental changes for a resource, the update stream 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 and hence the field is no longer defined (i.e., undefined); see the MergePatch algorithm in Section 3.1.1 on how null value is processed. This, however, may not be the intended result for the resource, when null and undefined have different semantics for the resource. In such a case, the update stream server MUST choose JSON patch over JSON merge patch if JSON patch is indicated as a capability of the update stream server. If the server does not support JSON patch to handle such a case, the server then need to send a full replacement.
リソースの増分変更をエンコードするためにメディアタイプを選択すると、Update Stream Serverはエンコードの制限を考慮する必要があります。たとえば、JSON Mergeパッチがフィールドの値がnullであることを指定すると、その意味はそのフィールドがターゲットから削除され、したがってフィールドが定義されなくなります（すなわち、未定義）。NULL値の処理方法については、セクション3.1.1のMergePatchアルゴリズムを参照してください。ただし、NULLと未定義の場合は、リソースに対して異なるセマンティクスがある場合は、これはリソースに対する意図された結果ではない可能性があります。このような場合、Update Stream ServerがUpdate Stream Serverの機能として示されている場合、Update Stream ServerはJSON Merge Patchを介してJSONパッチを選択する必要があります。サーバーがそのようなケースを処理するためにJSONパッチをサポートしていない場合、サーバーは完全な置き換えを送信する必要があります。
The "support-stream-control" field specifies whether the given update stream supports stream control. If the "support-stream-control" field is "true", the update stream server will use the stream control specified in this document; otherwise, the update stream server may use other mechanisms to provide the same functionality as stream control.
「support-stream-control」フィールドは、指定された更新ストリームがストリーム制御をサポートするかどうかを指定します。「support-stream-control」フィールドが "true"の場合、Update Stream Serverはこのドキュメントで指定されたストリーム制御を使用します。そうでなければ、更新ストリームサーバは他のメカニズムを使用してストリーム制御と同じ機能を提供することができる。
The "uses" attribute MUST be an array with the resource-ids of every resource for which this update stream can provide updates. Each resource specified in the "uses" MUST support full replacement; the update stream server can always send full replacement, and the ALTO client MUST accept full replacement.
"using"属性は、この更新プログラムストリームが更新を提供できるすべてのリソースのリソースIDを持つ配列でなければなりません。「使用」で指定された各リソースは完全な置き換えをサポートしている必要があります。Update Stream Serverは常にフル置換を送信でき、Altoクライアントは完全な交換を受け入れる必要があります。
This set may be any subset of the ALTO server's 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 an update stream's "uses" set includes resource R1 and resource R1 depends on ("uses") resource R0, then the update stream's "uses" set SHOULD include R0 as well as R1. For example, an update stream for a cost map SHOULD also provide updates for the network map upon which that cost map depends.
このセットは、ALTOサーバのリソースのサブセットであり、リンクされたIRDSで定義されたリソースを含み得る。ただし、ALTOサーバーはリソース依存関係の下で閉じられているセットを選択することをお勧めします。すなわち、更新ストリームの「使用」セットがリソースR1を含み、リソースR1が依存する（「使用」）リソースR0に依存している場合、更新ストリームの「使用」セットはR0とR1を含むべきである。例えば、コストマップのための更新ストリームはまた、そのコストマップが依存するネットワークマップに対する更新を提供するべきである。
An ALTO client specifies the parameters for the new update stream by sending an HTTP POST body with the media type "application/alto-updatestreamparams+json". That body contains a JSON object of type UpdateStreamReq, where:
ALTOクライアントは、メディアタイプの「アプリケーション/ ALTO-UpdateStreamParams JSON」を使用してHTTP POSTボディを送信することによって、新しいアップデートストリームのパラメータを指定します。その本体にはUpdateStreamReqと型のJSONオブジェクトが含まれています。
object {
[AddUpdatesReq add;]
[SubstreamID remove<0..*>;]
} UpdateStreamReq;
object-map {
SubstreamID -> AddUpdateReq;
} AddUpdatesReq;
object {
ResourceID resource-id;
[JSONString tag;]
[Boolean incremental-changes;]
[Object input;]
} AddUpdateReq;
add: Specifies the resources (and the parameters for the resources) for which the ALTO client wants updates. In the scope of the same update stream, the ALTO client MUST assign a substream-id that is unique in the scope of the update stream (Section 5.2) for each entry and use those substream-ids as the keys in the "add" field.
追加：ALTOクライアントが更新を希別するリソース（およびリソースのパラメータ）を指定します。同じアップデートストリームの範囲では、ALTOクライアントは各エントリの更新ストリームの範囲内で固有のサブストリームID（セクション5.2）を割り当てる必要があり、それらのサブストリームIDを「追加」フィールドにキーとして使用します。。
resource-id: The resource-id of an ALTO resource and MUST be in the update stream's "uses" list (Section 6.4). If the resource-id is a GET-mode resource with a version tag (or "vtag"), as defined in Sections 6.3 and 10.3 of [RFC7285], and the ALTO client has previously retrieved a version of that resource from the update stream server, the ALTO client MAY set the "tag" field to the tag part of the client's version of that resource. If that version is not current, the update stream server MUST send a full replacement before sending any incremental changes, as described in Section 6.7.1. If that version is still current, the update stream server MAY omit the initial full replacement.
resource-id：ALTOリソースのリソースIDで、更新ストリームの「使用」リストに入っている必要があります（セクション6.4）。リソースIDが、[RFC7285]のセクション6.3と10.3で定義されているバージョンタグ（または「VTAG」）を持つGet-Modeリソースで、ALTOクライアントは以前に更新ストリームからそのリソースのバージョンを取得しています。サーバー、ALTOクライアントは、そのリソースのクライアントのバージョンのタグ部分に「タグ」フィールドを設定することができます。そのバージョンが最新ではない場合、6.7.1項で説明されているように、アップデートStream Serverは、増分変更を送信する前にフル置換を送信する必要があります。そのバージョンがまだ現在の場合、アップデートストリームサーバーは最初のフル置換を省略することがあります。
incremental-changes: The ALTO client specifies whether it is willing to receive incremental changes from the update stream server for this substream. If the "incremental-changes" field is "true", the update stream server MAY send incremental changes for this substream. In this case, the client MUST support all incremental methods from the set announced in the server's capabilities for this resource; see Section 6.3 for the server's announcement of potential incremental methods. If a client does not support all incremental methods from the set announced in the server's capabilities, the client can set "incremental-changes" to "false", and the update stream server then MUST NOT send incremental changes for that substream. The default value for "incremental-changes" is "true", so to suppress incremental changes, the ALTO client MUST explicitly set "incremental-changes" to "false". An alternative design of incremental-changes control is a more fine-grained control, by allowing a client to select a subset of incremental methods from the set announced in the server's capabilities. But this alternative design is not adopted in this document, because it adds complexity to the server, which is more likely to be the bottleneck. Note that the ALTO client cannot suppress full replacement. When the ALTO client sets "incremental-changes" to "false", the update stream server MUST send a full replacement instead of an incremental change to the ALTO client. The update stream server MAY wait until more changes are available and send a single full replacement with those changes. Thus, an ALTO client that declines to accept incremental changes may not get updates as quickly as an ALTO client that does.
増分変化：ALTOクライアントは、このサブストリームのアップデートストリームサーバーからの増分変更を受信しても構わないと思われるかどうかを指定します。 「インクリメンタル変更」フィールドが「TRUE」の場合、アップデートストリームサーバはこのサブストリームに対して増分変更を送信することができる。この場合、クライアントは、このリソースのサーバーの機能でアナウンスされたセットからすべての増分メソッドをサポートする必要があります。潜在的な増分方法のサーバーの発表については、6.3項を参照してください。クライアントがサーバーの機能でアナウンスされたセットからすべての増分メソッドをサポートしていない場合、クライアントは "incremental-changes"を "false"に設定でき、アップデートStream Serverはそのサブストリームのインクリメンタル変更を送信してはなりません。 "incremental-changes"のデフォルト値は "true"です。 incremental-changesコントロールの代替デザインは、クライアントがサーバーの機能で発表されたセットから増分メソッドのサブセットを選択できるようにすることで、よりきめ細かいコントロールです。しかし、この代替デザインはこの文書では採用されていません。これはサーバーに複雑さを追加するため、ボトルネックになる可能性が高いです。 Altoクライアントは完全な交換を抑制することはできません。 ALTOクライアントが「incremental-changes」を「false」に設定すると、ALTOクライアントへの増分変更の代わりにUpdate Stream Serverは完全な置換を送信する必要があります。アップデートStream Serverは、より多くの変更が利用可能になるまで待機し、それらの変更に1つの完全な置き換えを送信することがあります。したがって、増分的な変更を受け入れるように辞退する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オブジェクトに設定する必要があります。
remove: It is used in update stream control requests (Section 7) and is not allowed in the update stream request. The update stream server SHOULD ignore this field if it is included in the request.
削除：更新ストリーム制御要求（セクション7）で使用され、更新ストリーム要求では許可されていません。更新ストリームサーバーは、要求に含まれている場合はこのフィールドを無視してください。
If a request has any errors, the update stream server MUST NOT create an update stream. Also, the update stream server will send an error response to the ALTO client, as specified in Section 6.6.
リクエストにエラーがある場合は、Update Stream Serverはアップデートストリームを作成しないでください。また、Update Stream Serverは、6.6項で指定されているように、ALTOクライアントにエラー応答を送信します。
If the update stream request has any errors, the update stream server MUST return an HTTP "400 Bad Request" 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:
更新ストリーム要求にエラーがある場合、Update Stream ServerはALTOクライアントにHTTP "400不良要求"を返す必要があります。レスポンスの本文は、[RFC7285]のセクション8.5.2で指定されている一般的なALTOエラー応答フォーマットに従います。したがって、Altoエラー応答の例は次のとおりです。
HTTP/1.1 400 Bad Request
Content-Length: 131
Content-Type: application/alto-error+json
Connection: Closed
{
"meta":{
"code": "E_INVALID_FIELD_VALUE",
"field": "add/my-network-map/resource-id",
"value": "my-networkmap/#"
}
}
Note that "field" and "value" are optional fields. If the "value" field exists, the "field" field MUST exist.
"field"と "value"はオプションのフィールドです。「値」フィールドが存在する場合は、「フィールド」フィールドが存在している必要があります。
* If an update stream request does not have an "add" field specifying one or more resources, the error code of the error message MUST be E_MISSING_FIELD and the "field" field SHOULD be "add". The update stream server MUST close the stream without sending any events.
* 更新ストリーム要求に1つ以上のリソースを指定する「追加」フィールドがない場合、エラーメッセージのエラーコードはE_Missing_Fieldでなければならず、「フィールド」フィールドは「追加」する必要があります。Update Stream Serverはイベントを送信せずにストリームを閉じる必要があります。
* If the "resource-id" field is invalid or is not associated with the update stream, the error code of the error message MUST be E_INVALID_FIELD_VALUE. The "field" field SHOULD be the full path of the "resource-id" field, and the "value" field SHOULD be the invalid resource-id. If there are more than one invalid resource-ids, the update stream server SHOULD pick one and return it. The update stream server MUST close the stream (i.e., TCP connection) without sending any events.
* "resource-id"フィールドが無効であるか、更新プログラムストリームに関連付けられていない場合、エラーメッセージのエラーコードはe_invalid_field_valueでなければなりません。「フィールド」フィールドは、「Resource-ID」フィールドのフルパスで、「Value」フィールドは無効なリソースIDである必要があります。2つ以上の無効なリソースIDがある場合、アップデートStream Serverは1つを選択して返します。Update Stream Serverは、イベントを送信せずにストリーム（すなわち、TCP接続）を閉じる必要があります。
* 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 that resource expects. If the "input" field is missing or invalid, the update stream server MUST return the same error response that that resource would return for missing or invalid input (see [RFC7285]). In this case, the update stream server MUST close the update stream without sending any events. If the input for several POST-mode resources is missing or invalid, the update stream server MUST pick one and return it.
* リソースが入力を必要とするポストモードサービスである場合、クライアントはそのリソースが期待するパラメータを使用して「入力」フィールドをJSONオブジェクトに設定する必要があります。「入力」フィールドが見つからないか無効な場合、Update Stream Serverはそのリソースが欠落または無効な入力に戻るのと同じエラー応答を返す必要があります（[RFC7285]を参照）。この場合、Update Stream Serverはイベントを送信せずにアップデートストリームを閉じる必要があります。複数のポストモードリソースの入力が見つからないか無効な場合、アップデートストリームサーバは1つを選択して返す必要があります。
The response to a valid request is a stream of update messages. Section 5 defines the update messages, and [SSE] defines how they are encoded into a stream.
有効な要求に対する応答は更新メッセージのストリームです。セクション5は更新メッセージを定義し、[SSE]はそれらがストリームにどのようにエンコードされているかを定義します。
An update stream server SHOULD send updates only when the underlying values change. However, it may be difficult for an update stream server to guarantee that in all circumstances. Therefore, a client MUST NOT assume that an update message represents an actual change.
Update Stream Serverは、基礎となる値が変更されたときにのみ更新を送信する必要があります。ただし、アップデートStream Serverがあらゆる状況では保証するのは難しい場合があります。したがって、クライアントは更新メッセージが実際の変更を表すと仮定してはいけません。
* The first event MUST be a control update message with the URI of the update stream control service (see Section 7) for this update stream. Note that the value of the control-uri can be "null", indicating that there is no control stream service.
* 最初のイベントは、このアップデートストリームのURIを備えたコントロールアップデートメッセージでなければなりません（セクション7を参照）。コントロールURIの値は "null"にすることができ、Control Streamサービスがないことを示します。
* As soon as possible, after the ALTO client initiates the connection, the update stream server checks the "tag" field for each added update request. If the "tag" field is not specified in an added update request, the update stream server MUST first send a full replacement for the request. If the "tag" field is specified, the client can accept incremental changes, and the server can compute an incremental update based on the "tag" (the server needs to ensure that for a POST resource with input, the "tag" should indicate the correct result for different inputs); the update stream server MAY omit the initial full replacement.
* できるだけ早く、ALTOクライアントが接続を開始した後、アップデートStream Serverは追加された各更新要求の「タグ」フィールドをチェックします。「タグ」フィールドが追加された更新要求で指定されていない場合、Update Stream Serverは最初にそのリクエストの完全な置換を送信する必要があります。「タグ」フィールドが指定されている場合、クライアントはインクリメンタル変更を受け入れ、サーバーは「タグ」に基づいて増分更新を計算できます（サーバーは、入力を伴う投稿リソースの場合は、「タグ」を示す必要があることを確認する必要があります。異なる入力に対する正しい結果）。更新ストリームサーバは、最初のフル置換を省略することがあります。
* If this update stream provides updates for resource-ids R0 and R1 and if R1 depends on R0, then the update stream server MUST send the update for R0 before sending the related updates for R1. For example, suppose an update stream provides updates to a network map and its dependent cost maps. When the network map changes, the update stream server MUST send the network map update before sending the cost map updates.
* このアップデートストリームがリソースID R0およびR1の更新を提供し、R1がR0に依存する場合、更新ストリームサーバはR1の関連更新を送信する前にR0の更新を送信する必要があります。たとえば、アップデートストリームがネットワークマップとその従属コストマップへの更新を提供するとします。ネットワークマップが変更された場合、アップデートStream Serverはコストマップの更新を送信する前にネットワークマップの更新を送信する必要があります。
* When the ALTO client uses the stream control service to stop updates for one or more resources (Section 7), the ALTO client MUST send a stream control request. The update stream server MUST send a control update message whose "stopped" field has the substream-ids of all stopped resources.
* ALTOクライアントがストリーム制御サービスを使用して1つ以上のリソースの更新を停止する（セクション7）、ALTOクライアントはストリーム制御要求を送信する必要があります。Update Stream Serverは、 "Stoped"フィールドにあるすべての停止リソースのサブストリームIDを持つコントロールアップデートメッセージを送信する必要があります。
If multiple ALTO clients create multiple update streams from the same update stream resource and with the same update request parameters (i.e., same resource and same input), the update stream server MUST send the same updates to all of them. However, the update stream server MAY pack data items into different patch events, as long as the net result of applying those updates is the same.
複数のALTOクライアントが、同じ更新ストリームリソースから複数の更新ストリームを作成し、同じ更新要求パラメータ（すなわち、同じリソースおよび同じ入力）で、更新ストリームサーバはそれらのすべてに同じ更新を送信する必要がある。ただし、更新ストリームサーバーは、それらの更新プログラムを適用した結果が同じである限り、データ項目をさまざまなパッチイベントにパックすることができます。
For example, suppose two different ALTO clients create two different update streams for the same cost map, and suppose the update stream server processes three separate cost point updates with a brief pause between each update. The server MUST send all three new cost points to both clients. But the update stream server MAY send a single patch event (with all three cost points) to one ALTO client while sending three separate patch events (with one cost point per event) to the other ALTO client.
たとえば、2つの異なるALTOクライアントが同じコストマップに対して2つの異なる更新ストリームを作成し、Update Stream Serverが各更新間の一時停止で3つの別々のコストポイント更新を処理するとします。サーバーは、両方のクライアントに3つの新しいコストポイントをすべて送信する必要があります。しかし、アップデートStream Serverは、3つの別々のパッチイベントを（イベントごとに1つのコストポイント）を他のALTOクライアントに送信しながら、1つのALTOクライアントに単一のパッチイベントを送信することができます。
An update stream server MAY offer several different update stream resources that provide updates to the same underlying resource (that is, a resource-id may appear in the "uses" field of more than one update stream resource). In this case, those update stream resources MUST return the same update.
アップデートストリームサーバは、同じ基礎となるリソースに対する更新を提供するいくつかの異なる更新ストリームリソースを提供してもよい（つまり、リソースIDが複数の更新ストリームリソースの「使用」フィールドに表示され得る）。この場合、これらのアップデートストリームリソースは同じ更新を返す必要があります。
This design allows any valid media type for full replacement. Hence, it supports ALTO resources using multipart to contain multiple JSON objects. This realizes the push benefit but not the incremental encoding benefit of SSE.
この設計により、完全な交換のために任意の有効なメディアタイプが可能になります。したがって、マルチパートを使用して複数のJSONオブジェクトを含むALTOリソースをサポートします。これはプッシュ利益を実現しますが、SSEの増分符号化の利点はありません。
JSON patch and merge patch provide the incremental encoding benefit but can be applied to only a single JSON object. If an update stream service supports a resource providing a multipart media type, which we refer to as a multipart resource, then the update stream service needs to handle the issue that the message of a full multipart resource can include multiple JSON objects. To address the issue, when an update stream service specifies that it supports JSON patch or merge patch incremental updates for a multipart resource, the service MUST ensure that (1) each part of a multipart message is a single JSON object, (2) each part is specified by a static Content-ID in the initial full message, (3) each data update event applies to only one part, and (4) each data update specifies substream-id.content-id as the "event" field of the event, to identify the part to be updated.
JSONパッチおよびマージパッチは、インクリメンタルエンコードの利点を提供しますが、単一のJSONオブジェクトのみに適用できます。アップデートストリームサービスがマルチパートリソースとして参照するリソースをサポートしている場合、アップデートストリームサービスは、フルマルチパートリソースのメッセージが複数のJSONオブジェクトを含むことができるという問題を処理する必要がある。問題に対処するために、Update StreamサービスがMultiPartリソースのJSONパッチまたはマージパッチの増分更新をサポートすることを指定している場合、サービスは（1）マルチパートメッセージの各部分が単一のJSONオブジェクトであることを確認する必要があります。部分は、最初のフルメッセージの静的コンテンツIDで指定されます。（3）各データ更新イベントは1つの部分にのみ適用され、（4）各データ更新はSUBSLEAM-ID.CONTENT-IDを「イベント」フィールドとして指定します。更新される部分を識別するためのイベント。
In an SSE stream, any line that starts with a colon (U+003A) character is a comment, and an ALTO client MUST ignore that line [SSE]. As recommended in [SSE], an update stream server SHOULD send a comment line (or an event) every 15 seconds to prevent ALTO clients and proxy servers from dropping the HTTP connection. Note that although TCP also provides a Keep-Alive function, the interval between TCP Keep-Alive messages can depend on the OS configuration and varies. The preceding recommended SSE Keep-Alive allows the SSE client to detect the status of the update stream server with more certainty.
SSEストリームでは、コロン（U 003A）文字で始まる行がコメントであり、ALTOクライアントはその行[SSE]を無視する必要があります。[SSE]で推奨されるように、ALTOクライアントとプロキシサーバーがHTTP接続を削除するのを防ぐために、アップデートストリームサーバーは15秒ごとにコメント行（またはイベント）を送信する必要があります。TCPはキープアライブ機能も提供しますが、TCPキープアライブメッセージ間の間隔はOS構成によって異なります。前述の推奨SSEキープアライブにより、SSEクライアントは更新ストリームサーバのステータスをより確実に検出することができます。
A stream control service allows an ALTO client to remove resources from the set of resources that are monitored by an update stream or add additional resources to that set. The service also allows an ALTO client to gracefully shut down an update stream.
Stream Control Serviceでは、ALTOクライアントがアップデートストリームによって監視されるリソースのセットまたはそのセットに追加のリソースを追加するリソースのリソースを削除できます。このサービスにより、ALTOクライアントがアップデートストリームを適切にシャットダウンすることもできます。
When an update stream server creates a new update stream and if the update stream server supports stream control for the update stream, the update stream server creates a stream control service for that update stream. An ALTO client uses the stream control service to remove resources from the update stream instance or to request updates for additional resources. An ALTO client cannot obtain the stream control service through the IRD. Instead, the first event that the update stream server sends to the ALTO client has the URI for the associated stream control service (see Section 5.3).
アップデートストリームサーバが新しい更新ストリームを作成し、更新ストリームサーバが更新ストリームのストリーム制御をサポートしている場合、Update Stream Serverはその更新ストリームのストリーム制御サービスを作成する。ALTOクライアントは、ストリーム制御サービスを使用して、更新ストリームインスタンスからリソースを削除したり、追加のリソースの更新を要求します。AltoクライアントはIRDを介してストリーム制御サービスを取得できません。代わりに、Update Stream ServerがALTOクライアントに送信する最初のイベントは、関連するストリーム制御サービスのURIを持っています（セクション5.3を参照）。
Each stream control request is an individual HTTP request. The ALTO client MAY send multiple stream control requests to the stream control server using the same HTTP connection.
各ストリーム制御要求は個々のHTTPリクエストです。ALTOクライアントは、同じHTTP接続を使用してストリーム制御サーバーに複数のストリーム制御要求を送信することができます。
The URI for a stream control service, by itself, MUST uniquely specify the update stream instance that it controls. The stream control server MUST NOT use other properties of an HTTP request, such as cookies or the client's IP address, to determine the update stream. Furthermore, an update stream server MUST NOT reuse a control service URI once the associated update stream has been closed.
Stream Control ServiceのURIは、それ自体で、それが制御するアップデートストリームインスタンスを一意に指定する必要があります。Stream Controlサーバーは、クッキーやクライアントのIPアドレスなどのHTTPリクエストの他のプロパティを使用しないでください。さらに、関連付けられた更新ストリームが閉じられたら、更新ストリームサーバは制御サービスURIを再利用してはいけません。
The ALTO client MUST evaluate a relative control URI reference [RFC3986] (for example, a URI reference without a host or with a relative path) in the context of the URI used to create the update stream. The stream control service's host MAY be different from the update stream's host.
ALTOクライアントは、更新ストリームを作成するために使用されたURIのコンテキストで、相対制御URIリファレンス[RFC3986]（たとえば、ホストなしのURI参照または相対パスを持つ）を評価する必要があります。ストリーム制御サービスのホストは、更新ストリームのホストとは異なる場合があります。
It is expected that there is an internal mechanism to map a stream control URI to the unique update stream instance to be controlled. For example, the update stream service may assign a unique, internal stream id to each update stream instance. However, the exact mechanism is left to the update stream service provider.
制御される独自のアップデートストリームインスタンスにストリーム制御URIをマッピングするための内部メカニズムがあると予想されます。例えば、更新ストリームサービスは、各更新ストリームインスタンスに一意の内部ストリームIDを割り当てることができる。ただし、正確なメカニズムは更新ストリームサービスプロバイダに残っています。
To prevent an attacker from forging a stream control URI and sending bogus requests to disrupt other update streams, the service should consider two security issues. First, if http, not https, is used, the stream control URI can be exposed to an on-path attacker. To address this issue, in a setting where the path from the server to the client can traverse such an attacker, the server SHOULD use https. Second, even without direct exposure, an off-path attacker may guess valid stream control URIs. To address this issue, the server SHOULD choose stream control URIs with enough randomness to make guessing difficult; the server SHOULD introduce mechanisms that detect repeated guesses indicating an attack (e.g., keeping track of the number of failed stream control attempts). Please see the W3C's "Good Practices for Capability URLs" <https://www.w3.org/TR/ capability-urls/>.
攻撃者がストリーム制御URIを冗長させ、他のアップデートストリームを混乱させるためのボーガス要求を送信するのを防ぐために、サービスは2つのセキュリティ問題を考慮する必要があります。まず、HTTPSではなくHTTPが使用されている場合、ストリームコントロールURIをOn-Path攻撃者に公開することができます。この問題に対処するには、サーバーからクライアントへのパスがそのような攻撃者を通過できる設定で、サーバーはHTTPSを使用する必要があります。第二に、直接露光がなくても、オフパス攻撃者は有効なストリーム制御URIを推測する可能性があります。この問題に対処するには、サーバーは推測困難を推測するのに十分なランダム性を持つストリーム制御URIを選択する必要があります。サーバは、攻撃を示す繰り返し推測を検出するメカニズム（例えば、失敗したストリーム制御試行の数を追跡する）を導入する必要があります。W3Cの「機能URLのための良い慣行」<https://www.w3.org/tr/ capability-urls />を参照してください。
An ALTO stream control response does not have a specific media type.
アルトストリーム制御応答は特定のメディアタイプを持たない。
An ALTO update stream control resource is requested using the HTTP POST method.
HTTP POSTメソッドを使用して、ALTO更新ストリーム制御リソースが要求されます。
None (Stream control services do not appear in the IRD).
NONE（Stream Control ServicesはIRDには表示されません）。
A stream control service accepts the same input media type and input parameters as the update stream service (Section 6.5). The only difference is that a stream control service also accepts the "remove" field.
ストリーム制御サービスは、更新ストリームサービスとして同じ入力メディアタイプと入力パラメータを受け入れます（6.5項）。唯一の違いは、ストリーム制御サービスが「削除」フィールドも受け入れることです。
If specified, the "remove" field is an array of substream-ids the ALTO client previously added to this update stream. An empty "remove" array is equivalent to a list of all currently active resources; the update stream server responds by removing all resources and closing the stream.
指定されている場合、 "remove"フィールドは以前にこのアップデートストリームに追加されたALTOクライアントがサブストリームIDの配列です。空の「削除」アレイは、現在アクティブなすべてのリソースのリストと同じです。Update Stream Serverは、すべてのリソースを削除してストリームを閉じることによって応答します。
An ALTO client MAY use the "add" field to add additional resources. The ALTO client MUST assign a unique substream-id to each additional resource. Substream-ids MUST be unique over the lifetime of this update stream; an ALTO client MUST NOT reuse a previously removed substream-id. The processing of an "add" resource is the same as discussed in Sections 6.5 and 6.6.
ALTOクライアントは、「追加」フィールドを使用して追加のリソースを追加することができます。ALTOクライアントは、各追加リソースに固有のサブストリームIDを割り当てる必要があります。サブストリームIDは、このアップデートストリームの有効期間にわたって一意である必要があります。ALTOクライアントは、以前に削除されたサブストリームIDを再利用してはいけません。「追加」リソースの処理は、セクション6.5と6.6で説明したものと同じです。
If a request has any errors, the update stream server MUST NOT add or remove any resources from the associated update stream. Also, the stream control server will return an error response to the client, as specified in Section 7.6.
リクエストにエラーがある場合、Update Stream Serverは関連する更新ストリームからリソースを追加または削除してはいけません。また、Stream Control Serverはセクション7.6で指定されているように、エラー応答をクライアントに返します。
The stream control server MUST process the "add" field before the "remove" field. If the request removes all active resources without adding any additional resources, the update stream server MUST close the update stream. Thus, an update stream cannot have zero resources.
Stream Controlサーバーは、[削除]フィールドの前に[追加]フィールドを処理する必要があります。追加のリソースを追加せずに要求がすべてのアクティブリソースを削除した場合、アップデートストリームサーバーは更新ストリームを閉じる必要があります。したがって、アップデートストリームはゼロのリソースを持つことができません。
If the request has any errors, the stream control server MUST return an HTTP "400 Bad Request" to the ALTO client. The body part of the response follows the generic ALTO error response format specified in Section 8.5.2 of [RFC7285]. An error response has the same format as specified in Section 6.6. Detailed error code and error information are specified as below.
要求にエラーがある場合、Stream Control ServerはALTOクライアントにHTTP "400不良要求"を返す必要があります。応答の身体部分は、[RFC7285]の8.5.2項で指定されている一般的なALTOエラー応答フォーマットに従います。エラー応答は、6.6項で指定されているものと同じです。詳細なエラーコードとエラー情報は以下のように指定されています。
* If the "add" request does not satisfy the requirements in Section 6.5, the stream control server MUST return the ALTO error message defined in Section 6.6.
* 「追加」要求がセクション6.5の要件を満たさない場合、Stream Control Serverはセクション6.6で定義されているALTOエラーメッセージを返す必要があります。
* If any substream-id in the "remove" field was not added in a prior request, the error code of the error message MUST be E_INVALID_FIELD_VALUE, the "field" field SHOULD be "remove", and the "value" field SHOULD be an array of the invalid substream-ids. Thus, it is illegal to "add" and "remove" the same substream-id in the same request. However, it is legal to remove a substream-id twice. To support the preceding checking, the update stream server MUST keep track of previously used but now closed substream-ids.
* 「削除」フィールドのSubstram-IDが事前の要求に追加されていない場合は、エラーメッセージのエラーコードはE_INVALID_FIELD_VALUEでなければなりません。[フィールド]フィールドは[削除]で、[value]フィールドにする必要があります。無効なサブストリームIDの配列。したがって、同じ要求で同じSubstram-IDを「追加」および「削除」することは違法です。ただし、サブストリームIDを2回削除するのは合法です。上記の検査をサポートするために、アップデートStream Serverは以前に使用されているがクローズドなサブストリームIDを追跡する必要があります。
* If any substream-id in the "add" field has been used before in this stream, the error code of the error message MUST be E_INVALID_FIELD_VALUE, the "field" field SHOULD be "add", and the "value" field SHOULD be an array of invalid substream-ids.
* このストリームの前に「追加」フィールドのSubstram-IDが使用されている場合、エラーメッセージのエラーコードはE_INVALID_FIELD_VALUEでなければなりません。「フィールド」フィールドは "Add"で、 "value"フィールドをする必要があります。無効なサブストリームIDの配列。
* If the request has a non-empty "add" field and a "remove" field with an empty list of substream-ids (to replace all active resources with a new set, the client MUST explicitly enumerate the substream-ids to be removed), the error code of the error message MUST be E_INVALID_FIELD_VALUE, the "field" field SHOULD be "remove", and the "value" field SHOULD be an empty array.
* 要求に空でない「追加」フィールドとSUBSLEAM-IDの空のリストを持つ「削除」フィールドがある場合（すべてのアクティブなリソースを新しいセットに置き換えるために、クライアントは削除するサブストリームIDを明示的に列挙する必要があります）エラーメッセージのエラーコードはE_INVALID_FIELD_VALUEでなければなりません、「フィールド」フィールドは "remove"にする必要があり、 "value"フィールドは空の配列にする必要があります。
If the request is valid but the associated update stream has been closed, then the stream control server MUST return an HTTP "404 Not Found".
要求が有効であるが関連する更新プログラムストリームが閉じられている場合、Stream ControlサーバはHTTP "404が見つかりません"を返す必要があります。
If the request is valid and the stream control server successfully processes the request without error, the stream control server should return either an HTTP "202 Accepted" response or an HTTP "204 No Content" response. The difference is that for the latter case, the stream control server is sure that the update stream server has also processed the request. Regardless of a 202 or 204 HTTP response, the final updates of related resources will be notified by the update stream server using its control update message(s), due to the modular design.
要求が有効で、ストリーム制御サーバーがエラーなしで要求を正常に処理した場合、Stream ControlサーバーはHTTP "202承認された"応答またはhttp "204コンテンツ"の応答を返すべきです。違いは後者の場合の場合、ストリーム制御サーバはアップデートストリームサーバが要求を処理したことを確信していることです。202または204のHTTPレスポンスに関係なく、モジュール設計のため、コントロールアップデートメッセージを使用して、更新ストリームサーバによって関連リソースの最終更新が通知されます。
Below is an example IRD announcing three update stream services. The first, which is named "update-my-costs", provides updates for the network map, the "routingcost" and "hopcount" cost maps, and a Filtered Cost Map resource. The second, which is named "update-my-prop", provides updates to the endpoint properties service. The third, which is named "update-my-pv", provides updates to a nonstandard ALTO service returning a multipart response.
以下は、3つの更新ストリームサービスを発表する例の例です。1つ目は "Update-My-Cosp"という名前で、ネットワークマップ、 "routingcost"、および "Hopcount"コストマップ、およびフィルタ処理されたコストマップリソースの更新を提供します。2つ目は "update-my-prop"という名前で、エンドポイントプロパティサービスの更新を提供します。"Update-My-PV"という名前の3つ目は、マルチパート応答を返す非標準のALTOサービスの更新を提供します。
Note that in the "update-my-costs" update stream shown in the example IRD, the update stream server uses JSON patch for network map, and it uses JSON merge patch to update the other resources. Also, the update stream will only provide full replacements for "my-simple-filtered-cost-map".
例IRDの例に示す「アップデート - マイコスト」アップデートストリームでは、Update Stream ServerはネットワークマップにJSONパッチを使用し、その他のリソースを更新するためにJSON Merge Patchを使用します。また、アップデートストリームは、「My-Simple-Filtered-Cost-Map」の完全な置換を提供します。
Also, note that this IRD defines two Filtered Cost Map resources. They use the same cost types, but "my-filtered-cost-map" accepts cost constraint tests, while "my-simple-filtered-cost-map" does not. To avoid the issues discussed in Section 9.3, the update stream provides updates for the second but not the first.
また、このIRDは2つのフィルタリングされたコストマップリソースを定義しています。それらは同じコストタイプを使用しますが、「My Filtered-Cost-Map」はコスト制約テストを受け入れ、「My Simple-Filtered-Cost-Map」はそうではありません。セクション9.3で説明した問題を回避するために、アップデートストリームは2番目の更新を提供しますが、最初のものではありません。
This IRD also announces a nonstandard ALTO service, which is named "my-pv". This service accepts an extended endpoint cost request as an input and returns a multipart response, including an endpoint cost resource and a property map resource. This document does not rely on any other design details of this new service. In this document, the "my-pv" service is only used to illustrate how the update stream service provides updates to an ALTO resource returning a multipart response.
このIRDはまた、「My-PV」という名前の非標準のALTOサービスを発表します。このサービスは、拡張エンドポイントコスト要求を入力として受け付け、エンドポイントコストリソースとプロパティマップリソースを含むマルチパートレスポンスを返します。この文書はこの新しいサービスの他の設計の詳細に依存していません。このドキュメントでは、 "My-PV"サービスは、Update StreamサービスがMultipartレスポンスを返すALTOリソースへの更新を提供する方法を説明するためにのみ使用されます。
"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-networkmap"],
"capabilities": {
"cost-type-names": ["num-routingcost"]
}
},
"my-hopcount-map": {
"uri": "https://alto.example.com/costmap/hopcount",
"media-type": "application/alto-costmap+json",
"uses": ["my-networkmap"],
"capabilities": {
"cost-type-names": ["num-hopcount"]
}
},
"my-filtered-cost-map": {
"uri": "https://alto.example.com/costmap/filtered/constraints",
"media-type": "application/alto-costmap+json",
"accepts": "application/alto-costmapfilter+json",
"uses": ["my-networkmap"],
"capabilities": {
"cost-type-names": ["num-routingcost", "num-hopcount"],
"cost-constraints": true
}
},
"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-networkmap"],
"capabilities": {
"cost-type-names": ["num-routingcost", "num-hopcount"],
"cost-constraints": false
}
},
"my-props": {
"uri": "https://alto.example.com/properties",
"media-type": "application/alto-endpointprops+json",
"accepts": "application/alto-endpointpropparams+json",
"capabilities": {
"prop-types": ["priv:ietf-bandwidth"]
}
},
"my-pv": {
"uri": "https://alto.example.com/endpointcost/pv",
"media-type": "multipart/related;
type=application/alto-endpointcost+json",
"accepts": "application/alto-endpointcostparams+json",
"capabilities": {
"cost-type-names": [ "path-vector" ],
"ane-properties": [ "maxresbw", "persistent-entities" ]
}
},
"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-props": {
"uri": "https://alto.example.com/updates/properties",
"media-type": "text/event-stream",
"uses": [ "my-props" ],
"accepts": "application/alto-updatestreamparams+json",
"capabilities": {
"incremental-change-media-types": {
"my-props": "application/merge-patch+json"
},
"support-stream-control": true
}
},
"update-my-pv": {
"uri": "https://alto.example.com/updates/pv",
"media-type": "text/event-stream",
"uses": [ "my-pv" ],
"accepts": "application/alto-updatestreamparams+json",
"capabilities": {
"incremental-change-media-types": {
"my-pv": "application/merge-patch+json"
},
"support-stream-control": true
}
}
Given the update streams announced in the preceding example IRD, the section below shows an example of an ALTO client's request and the update stream server's immediate response, using the update stream resource "update-my-costs". In the example, the ALTO client requests updates for the network map and "routingcost" cost map but not for the "hopcount" cost map. The ALTO client uses the ALTO server's resource-ids as the substream-ids. Because the client does not provide a "tag" for the network map, the update stream server must send a full replacement for the network map as well as for the cost map. The ALTO client does not set "incremental-changes" to "false", so it defaults to "true". Thus, the update stream server will send patch updates for the cost map and the network map.
上記の例のIRDでアナウンスされたアップデートストリームを考えると、以下のセクションは、更新ストリームリソース「Update-My-Cosp」を使用して、ALTOクライアントの要求およびアップデートストリームサーバーの即時応答の例を示しています。この例では、ALTOクライアントはネットワークマップの更新と「ルーチンコスト」コストマップを要求しますが、「HopCount」コストマップではありません。ALTOクライアントは、ALTOサーバのリソースIDをサブストリームIDSとして使用します。クライアントはネットワークマップに「タグ」を提供していないため、アップデートStream Serverはネットワークマップとコストマップのフル置換を送信する必要があります。Altoクライアントは "incremental-changes"を "false"に設定していないため、デフォルトは "true"になります。したがって、アップデートStream Serverは、コストマップとネットワークマップのパッチ更新を送信します。
POST /updates/costs HTTP/1.1
Host: alto.example.com
Accept: text/event-stream,application/alto-error+json
Content-Type: application/alto-updatestreamparams+json
Content-Length: 155
{ "add": {
"my-network-map": {
"resource-id": "my-network-map"
},
"my-routingcost-map": {
"resource-id": "my-routingcost-map"
}
}
}
HTTP/1.1 200 OK Connection: keep-alive Content-Type: text/event-stream
HTTP / 1.1 200 OK接続：キープアライブコンテンツタイプ：テキスト/イベントストリーム
event: application/alto-updatestreamcontrol+json
data: {"control-uri":
data: "https://alto.example.com/updates/streams/3141592653589"}
event: application/alto-networkmap+json,my-network-map
data: {
data: "meta" : {
data: "vtag": {
data: "resource-id" : "my-network-map",
data: "tag" : "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
data: }
data: },
data: "network-map" : {
data: "PID1" : {
data: "ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ]
data: },
data: "PID2" : {
data: "ipv4" : [ "198.51.100.128/25" ]
data: },
data: "PID3" : {
data: "ipv4" : [ "0.0.0.0/0" ],
data: "ipv6" : [ "::/0" ]
data: }
data: }
data: }
data: }
event: application/alto-costmap+json,my-routingcost-map
data: {
data: "meta" : {
data: "dependent-vtags" : [{
data: "resource-id": "my-network-map",
data: "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
data: }],
data: "cost-type" : {
data: "cost-mode" : "numerical",
data: "cost-metric": "routingcost"
data: },
data: "vtag": {
data: "resource-id" : "my-routingcost-map",
data: "tag" : "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
data: }
data: },
data: "cost-map" : {
data: "PID1": { "PID1": 1, "PID2": 5, "PID3": 10 },
data: "PID2": { "PID1": 5, "PID2": 1, "PID3": 15 },
data: "PID3": { "PID1": 20, "PID2": 15 }
data: }
data: }
After sending those events immediately, the update stream server will send additional events as the maps change. For example, the following represents a small change to the cost map. PID1->PID2 is changed to 9 from 5, PID3->PID1 is no longer available, and PID3->PID3 is now defined as 1:
それらのイベントをすぐに送信した後、アップデートStream Serverはマップが変更されるにつれて追加のイベントを送信します。例えば、コストマップへの小さな変更を表す。PID1-> PID2は5から9に変更され、PID3-> PID1は使用できなくなり、PID3-> PID3は1として定義されています。
event: application/merge-patch+json,my-routingcost-map
data: {
data: "meta" : {
data: "vtag": {
data: "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"
data: }
data: },
data: "cost-map": {
data: "PID1" : { "PID2" : 9 },
data: "PID3" : { "PID1" : null, "PID3" : 1 }
data: }
data: }
As another example, the following represents a change to the network map: an ipv4 prefix "203.0.113.0/25" is added to PID1. It triggers changes to the cost map. The update stream server chooses to send an incremental change for the network map and send a full replacement instead of an incremental change for the cost map:
別の例として、ネットワークマップへの変更を表します.PID1にIPv4プレフィックス "203.0.113.0/25"が追加されました。コストマップへの変更を引き起こします。Update Stream Serverは、ネットワークマップのインクリメンタル変更を送信し、コストマップの増分変更の代わりにフル置換を送信します。
event: application/json-patch+json,my-network-map
data: {
data: {
data: "op": "replace",
data: "path": "/meta/vtag/tag",
data: "value" :"a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
data: },
data: {
data: "op": "add",
data: "path": "/network-map/PID1/ipv4/2",
data: "value": "203.0.113.0/25"
data: }
data: }
event: application/alto-costmap+json,my-routingcost-map
data: {
data: "meta" : {
data: "vtag": {
data: "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"
data: }
data: },
data: "cost-map" : {
data: "PID1": { "PID1": 1, "PID2": 3, "PID3": 7 },
data: "PID2": { "PID1": 12, "PID2": 1, "PID3": 9 },
data: "PID3": { "PID1": 14, "PID2": 8 }
data: }
data: }
This example is similar to the previous one, except that the ALTO client requests updates for the "hopcount" cost map as well as the "routingcost" cost map and provides the current version tag of the network map, so the update stream server is not required to send the full network map data update message at the beginning of the stream. In this example, the client uses the substream-ids "net", "routing", and "hops" for those resources. The update stream server sends the stream control URI and the full cost maps, followed by updates for the network map and cost maps as they become available:
この例は、ALTOクライアントが「HopCount」コストマップの更新を要求し、「RoutingCost」コストマップの更新を要求し、ネットワークマップの現在のバージョンタグを提供するので、アップデートStream Serverはそうではない。ストリームの先頭にフルネットワークマップデータ更新メッセージを送信するために必要です。この例では、クライアントはこれらのリソースに対してSubstram-ID "Net"、 "Routing"、および "Hops"を使用します。Update Stream Serverは、ストリーム制御URIとフルコストマップを送信し、続いてネットワークマップとコストマップを使用可能になるように更新します。
POST /updates/costs HTTP/1.1
Host: alto.example.com
Accept: text/event-stream,application/alto-error+json
Content-Type: application/alto-updatestreamparams+json
Content-Length: 244
{ "add": {
"net": {
"resource-id": "my-network-map",
"tag": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
},
"routing": {
"resource-id": "my-routingcost-map"
},
"hops": {
"resource-id": "my-hopcount-map"
}
}
}
HTTP/1.1 200 OK Connection: keep-alive Content-Type: text/event-stream
HTTP / 1.1 200 OK接続：キープアライブコンテンツタイプ：テキスト/イベントストリーム
event: application/alto-updatestreamcontrol+json
data: {"control-uri":
data: "https://alto.example.com/updates/streams/2718281828459"}
event: application/alto-costmap+json,routing
data: { ... full routingcost cost map message ... }
event: application/alto-costmap+json,hops
data: { ... full hopcount cost map message ... }
(pause)
（一時停止）
event: application/merge-patch+json,routing
data: {"cost-map": {"PID2" : {"PID3" : 31}}}
event: application/merge-patch+json,hops
data: {"cost-map": {"PID2" : {"PID3" : 4}}}
If the ALTO client wishes to stop receiving updates for the "hopcount" cost map, the ALTO client can send a "remove" request on the stream control URI:
ALTOクライアントが「HopCount」コストマップの更新を受信するのを停止したい場合、ALTOクライアントはStream Control URIに対して「削除」要求を送信できます。
POST /updates/streams/2718281828459 HTTP/1.1
Host: alto.example.com
Accept: text/plain,application/alto-error+json
Content-Type: application/alto-updatestreamparams+json
Content-Length: 24
{
"remove": [ "hops" ]
}
HTTP/1.1 204 No Content Content-Length: 0
HTTP / 1.1 204コンテンツの内容の長さ：0
(stream closed without sending data content)
（データコンテンツを送信せずにストリームが閉じる）
The update stream server sends a "stopped" control update message on the original request stream to inform the ALTO client that updates are stopped for that resource:
Update Stream Serverは、オリジナルの要求ストリームに「停止した」コントロールアップデートメッセージを送信して、更新がそのリソースに対して更新が停止されることをALTOクライアントに通知します。
event: application/alto-updatestreamcontrol+json
data: {
data: "stopped": ["hops"]
data: }
Below is an example of an invalid stream control request. The "remove" field of the request includes an undefined substream-id, and the stream control server will return an error response to the ALTO client.
以下は無効なストリーム制御要求の例です。要求の「削除」フィールドには未定義のサブストリームIDが含まれ、ストリーム制御サーバはALTOクライアントへのエラー応答を返します。
POST /updates/streams/2718281828459 HTTP/1.1
Host: alto.example.com
Accept: text/plain,application/alto-error+json
Content-Type: application/alto-updatestreamparams+json
Content-Length: 31
{
"remove": [ "properties" ]
}
HTTP/1.1 400 Bad Request
Content-Length: 89
Content-Type: application/alto-error+json
{
"meta":{
"code": "E_INVALID_FIELD_VALUE",
"field": "remove",
"value": "properties"
}
If the ALTO client no longer needs any updates and wishes to shut the update stream down gracefully, the client can send a "remove" request with an empty array:
ALTOクライアントが更新を必要としなくなった場合、アップデートストリームを正常に停止したい場合は、クライアントは空の配列を使用して「削除」要求を送信できます。
POST /updates/streams/2718281828459 HTTP/1.1
Host: alto.example.com
Accept: text/plain,application/alto-error+json
Content-Type: application/alto-updatestreamparams+json
Content-Length: 17
{
"remove": [ ]
}
HTTP/1.1 204 No Content Content-Length: 0
HTTP / 1.1 204コンテンツの内容の長さ：0
(stream closed without sending data content)
（データコンテンツを送信せずにストリームが閉じる）
The update stream server sends a final control update message on the original request stream to inform the ALTO client that all updates are stopped and then closes the stream:
Update Stream Serverは、すべての更新が停止してからストリームを閉じることをALTOクライアントに通知するために、元の要求ストリームに最終制御アップデートメッセージを送信します。
event: application/alto-updatestreamcontrol+json
data: {
data: "stopped": ["net", "routing"]
data: }
(server closes stream)
（サーバーがストリームを閉じる）
As another example, here is how an ALTO client can request updates for the property "priv:ietf-bandwidth" for one set of endpoints and "priv:ietf-load" for another. The update stream server immediately sends full replacements with the property values for all endpoints. After that, the update stream server sends data update messages for the individual endpoints as their property values change.
別の例として、ALTOクライアントが、1セットのエンドポイントと別のエンドポイントと「PRIV：IETF-LOAD」に対してプロパティ "Priv：IETF-Bandwidth"の更新を要求できる方法です。Update Stream Serverは、すべてのエンドポイントのプロパティ値を含む完全な置換を直ちに送信します。その後、Update Stream Serverは、プロパティ値が変更されたときに個々のエンドポイントのデータ更新メッセージを送信します。
POST /updates/properties HTTP/1.1
Host: alto.example.com
Accept: text/event-stream
Content-Type: application/alto-updatestreamparams+json
Content-Length: 511
{ "add": {
"props-1": {
"resource-id": "my-props",
"input": {
"properties" : [ "priv:ietf-bandwidth" ],
"endpoints" : [
"ipv4:198.51.100.1",
"ipv4:198.51.100.2",
"ipv4:198.51.100.3"
]
}
},
"props-2": {
"resource-id": "my-props",
"input": {
"properties" : [ "priv:ietf-load" ],
"endpoints" : [
"ipv6:2001:db8:100::1",
"ipv6:2001:db8:100::2",
"ipv6:2001:db8:100::3"
]
}
}
}
}
HTTP/1.1 200 OK Connection: keep-alive Content-Type: text/event-stream
HTTP / 1.1 200 OK接続：キープアライブコンテンツタイプ：テキスト/イベントストリーム
event: application/alto-updatestreamcontrol+json
data: {"control-uri":
data: "https://alto.example.com/updates/streams/1414213562373"}
event: application/alto-endpointprops+json,props-1
data: { "endpoint-properties": {
data: "ipv4:198.51.100.1" : { "priv:ietf-bandwidth": "13" },
data: "ipv4:198.51.100.2" : { "priv:ietf-bandwidth": "42" },
data: "ipv4:198.51.100.3" : { "priv:ietf-bandwidth": "27" }
data: } }
event: application/alto-endpointprops+json,props-2
data: { "endpoint-properties": {
data: "ipv6:2001:db8:100::1" : { "priv:ietf-load": "8" },
data: "ipv6:2001:db8:100::2" : { "priv:ietf-load": "2" },
data: "ipv6:2001:db8:100::3" : { "priv:ietf-load": "9" }
data: } }
(pause)
（一時停止）
event: application/merge-patch+json,props-1
data: { "endpoint-properties":
data: {"ipv4:198.51.100.1" : {"priv:ietf-bandwidth": "3"}}
data: }
(pause)
（一時停止）
event: application/merge-patch+json,props-2
data: { "endpoint-properties":
data: {"ipv6:2001:db8:100::3" : {"priv:ietf-load": "7"}}
data: }
If the ALTO client needs the "priv:ietf-bandwidth" property and the "priv:ietf-load" property for additional endpoints, the ALTO client can send an "add" request on the stream control URI:
ALTOクライアントに「Priv：IETF-Bandwidth」プロパティと追加のエンドポイントの「PRIV：IETF-LOAD」プロパティが必要な場合、ALTOクライアントはStream Control URIに対して「追加」要求を送信できます。
POST /updates/streams/1414213562373" HTTP/1.1
Host: alto.example.com
Accept: text/plain,application/alto-error+json
Content-Type: application/alto-updatestreamparams+json
Content-Length: 448
{ "add": {
"props-3": {
"resource-id": "my-props",
"input": {
"properties" : [ "priv:ietf-bandwidth" ],
"endpoints" : [
"ipv4:198.51.100.4",
"ipv4:198.51.100.5"
]
}
},
"props-4": {
"resource-id": "my-props",
"input": {
"properties" : [ "priv:ietf-load" ],
"endpoints" : [
"ipv6:2001:db8:100::4",
"ipv6:2001:db8:100::5"
]
}
}
}
}
HTTP/1.1 204 No Content Content-Length: 0
HTTP / 1.1 204コンテンツの内容の長さ：0
(stream closed without sending data content)
（データコンテンツを送信せずにストリームが閉じる）
The update stream server sends full replacements for the two new resources, followed by incremental changes for all four requests as they arrive:
Update Stream Serverは2つの新しいリソースに対して完全な置換を送信し、続いて4つのリクエストすべての到着時に増分変更を送信します。
event: application/alto-endpointprops+json,props-3
data: { "endpoint-properties": {
data: "ipv4:198.51.100.4" : { "priv:ietf-bandwidth": "25" },
data: "ipv4:198.51.100.5" : { "priv:ietf-bandwidth": "31" },
data: } }
event: application/alto-endpointprops+json,props-4
data: { "endpoint-properties": {
data: "ipv6:2001:db8:100::4" : { "priv:ietf-load": "6" },
data: "ipv6:2001:db8:100::5" : { "priv:ietf-load": "4" },
data: } }
(pause)
（一時停止）
event: application/merge-patch+json,props-3
data: { "endpoint-properties":
data: {"ipv4:198.51.100.5" : {"priv:ietf-bandwidth": "15"}}
data: }
(pause)
（一時停止）
event: application/merge-patch+json,props-2
data: { "endpoint-properties":
data: {"ipv6:2001:db8:100::2" : {"priv:ietf-load": "9"}}
data: }
(pause)
（一時停止）
event: application/merge-patch+json,props-4
data: { "endpoint-properties":
data: {"ipv6:2001:db8:100::4" : {"priv:ietf-load": "3"}}
data: }
This example shows how an ALTO client can request a nonstandard ALTO service returning a multipart response. The update stream server immediately sends full replacements of the multipart response. After that, the update stream server sends data update messages for the individual parts of the response as the ALTO data (object) in each part changes.
この例では、ALTOクライアントがマルチパート応答を返す非標準のALTOサービスを要求できる方法を示しています。Update Stream Serverは、マルチパート応答の完全な置換を直ちに送信します。その後、Update Stream Serverは、各部分のALTOデータ（オブジェクト）として、応答の個々の部分のデータ更新メッセージを送信します。
POST /updates/pv HTTP/1.1
Host: alto.example.com
Accept: text/event-stream
Content-Type: application/alto-updatestreamparams+json
Content-Length: 382
{
"add": {
"ecspvsub1": {
"resource-id": "my-pv",
"input": {
"cost-type": {
"cost-mode": "array",
"cost-metric": "ane-path"
},
"endpoints": {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [ "ipv4:192.0.2.89", "ipv4:203.0.113.45" ]
},
"ane-properties": [ "maxresbw", "persistent-entities" ]
}
}
}
}
HTTP/1.1 200 OK Connection: keep-alive Content-Type: text/event-stream
HTTP / 1.1 200 OK接続：キープアライブコンテンツタイプ：テキスト/イベントストリーム
event: application/alto-updatestreamcontrol+json
data: {"control-uri":
data: "https://alto.example.com/updates/streams/1414"}
event: multipart/related;boundary=example-pv;
type=application/alto-endpointcost+json,ecspvsub1
data: --example-pv
data: Content-ID: ecsmap
data: Content-Type: application/alto-endpointcost+json
data:
data: { ... data (object) of an endpoint cost map ... }
data: --example-pv
data: Content-ID: propmap
data: Content-Type: application/alto-propmap+json
data:
data: { ... data (object) of a property map ... }
data: --example-pv--
(pause)
（一時停止）
event: application/merge-patch+json,ecspvsub1.ecsmap
data: { ... merge patch for updates of ecspvsub1.ecsmap ... }
event: application/merge-patch+json,ecspvsub1.propmap
data: { ... merge patch for updates of ecspvsub1.propmap ... }
The update stream server should be cognizant of the effects of its update schedule, which includes both the choice of timing (i.e., when/what to trigger an update) and the choice of message format (i.e., given an update, send a full replacement or an incremental change). In particular, the update schedule can have effects on both the overhead and the freshness of information. To minimize overhead, the server may choose to batch a sequence of updates for resources that frequently change by sending cumulative updates or a full replacement after a while. The update stream server should be cognizant that batching reduces the freshness of information. The server should also consider the effect of such delays on client behaviors (see below on client timeout on waiting for updates of dependent resources).
アップデートストリームサーバは、更新スケジュールの効果を認識しており、これにはタイミングの選択（すなわち、更新をトリガーするとき）とメッセージフォーマットの選択（更新が完全な置き換えを送信する）の両方を含む必要があります。または増分変更）特に、更新スケジュールは、オーバーヘッドと情報の鮮度の両方に影響を与える可能性があります。オーバーヘッドを最小限に抑えるために、サーバーは、累積的な更新またはしばらくの後に完全な交換によって頻繁に変更されるリソースの一連の更新をバッチすることを選択できます。更新ストリームサーバーは、バッチ処理が情報の鮮度を低下させることを認識している必要があります。サーバーは、クライアントの動作に対するそのような遅延の影響も考慮する必要があります（従属リソースの更新を待っているクライアントのタイムアウトについては、以下を参照してください）。
For incremental updates, this design allows both JSON patch and JSON merge patch for incremental changes. JSON merge patch is clearly superior to JSON patch for describing incremental changes to cost maps, endpoint costs, and endpoint properties. For these data structures, JSON merge patch is more space efficient, as well as simpler to apply. There is no advantage allowing a server to use JSON patch for those resources.
増分更新の場合、この設計により、JSONパッチとJSONマージパッチの両方が増分変更を許可します。JSON Merge Patchは、コストマップ、エンドポイントコスト、およびエンドポイントプロパティへの増分変更を記述するためのJSONパッチよりも明らかに優れています。これらのデータ構造の場合、JSON Mergeパッチはより多くのスペース効率、適用が簡単です。サーバーがそれらのリソースにJSONパッチを使用できることを可能にするという利点はありません。
The case is not as clear for incremental changes to network maps.
ケースは、ネットワークマップへの増分変更が明確ではありません。
First, consider small changes, such as moving a prefix from one PID to another. JSON patch could encode that as a simple insertion and deletion, while JSON merge patch would have to replace the entire array of prefixes for both PIDs. On the other hand, to process a JSON patch update, the ALTO client would have to retain the indexes of the prefixes for each PID. Logically, the prefixes in a PID are an unordered set, not an array; aside from handling updates, a client has no need to retain the array indexes of the prefixes. Hence, to take advantage of JSON patch for network maps, ALTO clients would have to retain additional, otherwise unnecessary, data.
まず、プレフィックスをあるPIDから別のPIDに移動するなど、小さな変更を検討してください。JSON Patchは単純な挿入と削除としてそれをエンコードできますが、JSON Mergeパッチは両方のPIDのプレフィックスの配列全体を置き換える必要があります。一方、JSONパッチアップデートを処理するために、ALTOクライアントは各PIDのプレフィックスのインデックスを保持する必要があります。論理的には、PIDの接頭辞は配列ではなく順序付けられていないセットです。更新を処理するのを除けば、クライアントはプレフィックスの配列インデックスを保持する必要はありません。したがって、ネットワークマップのためにJSONパッチを利用するために、ALTOクライアントは追加の追加、そうでなければ不要なデータを保持する必要があります。
Second, consider more involved changes, such as removing half of the prefixes from a PID. JSON merge patch would send a new array for that PID, while JSON patch would have to send a list of remove operations and delete the prefix one by one.
次に、PIDからのプレフィックスの半分を取り外すなど、より多くの関与の変更を検討してください。JSON MergeパッチはそのPIDの新しい配列を送信し、JSONパッチは削除操作のリストを送信し、プレフィックスを1つずつ削除する必要があります。
Therefore, each update stream server may decide on its own whether to use JSON merge patch or JSON patch according to the changes in network maps.
したがって、各更新ストリームサーバは、ネットワークマップの変更に従ってJSONマージパッチまたはJSONパッチを使用するかどうかを独自に決定することができる。
In general, when an ALTO client receives a full replacement for a resource, the ALTO client should replace the current version with the new version. When an ALTO client receives an incremental change for a resource, the ALTO client should apply those patches to the current version of the resource.
一般に、ALTOクライアントがリソースの完全な置換を受信すると、ALTOクライアントは現在のバージョンを新しいバージョンと置き換える必要があります。ALTOクライアントがリソースに対して増分変更を受信すると、ALTOクライアントはそれらのパッチを現在のバージョンのリソースに適用する必要があります。
However, because resources can depend on other resources (e.g., cost maps depend on network maps), an ALTO client MUST NOT use a dependent resource if the resource on which it depends has changed. There are at least two ways an ALTO client can do that. The following paragraphs illustrate these techniques by referring to network and cost map messages, although these techniques apply to any dependent resources.
しかしながら、リソースは他のリソース（例えば、コストマップはネットワークマップに依存する）に依存することができるので、それが依存するリソースが変更された場合には、ALTOクライアントは従属リソースを使用してはいけません。Altoクライアントがそれをすることができる2つの方法が少なくとも2つあります。次の段落は、これらの技術を参照してネットワークとコストマップメッセージを参照して説明していますが、これらの手法は依存したリソースに適用されます。
Note that when a network map changes, the update stream server MUST send the network map update message before sending the updates for the dependent cost maps (see Section 6.7.1).
ネットワークマップが変更されると、依存コストマップのアップデートを送信する前に、アップデートStream Serverはネットワークマップの更新メッセージを送信する必要があります（セクション6.7.1を参照）。
One approach is for the ALTO client to save the network map update message in a buffer and continue to use the previous network map and the associated cost maps until the ALTO client receives the update messages for all dependent cost maps. The ALTO client then applies all network and cost map updates atomically.
1つのアプローチは、ALTOクライアントがバッファ内のネットワークマップ更新メッセージを保存し、ALTOクライアントがすべての従属コストマップの更新メッセージを受信するまで、以前のネットワークマップと関連するコストマップを使用し続けることです。その後、ALTOクライアントはすべてのネットワークを適用し、原子力マップの更新をアトミックに適用します。
Alternatively, the ALTO client MAY update the network map immediately. In this case, the cost maps using the network map become invalid because they are inconsistent with the current network map; hence, the ALTO client MUST mark each such dependent cost map as temporarily invalid and MUST NOT use each such cost map until the ALTO client receives a cost map update message indicating that it is based on the new network map version tag.
あるいは、ALTOクライアントはすぐにネットワークマップを更新することができる。この場合、ネットワークマップを使用したコストマップは、現在のネットワークマップと矛盾しているため無効になります。したがって、ALTOクライアントは、そのような各依存コストマップを一時的に無効にマークし、ALTOクライアントがそれが新しいネットワークマップのバージョンタグに基づくことを示すコストマップ更新メッセージを受信するまでそのような各コストマップを使用してはならない。
The update stream server SHOULD send updates for dependent resources (i.e., the cost maps in the preceding example) in a timely fashion. However, if the ALTO client does not receive the expected updates, a simple recovery method is that the ALTO client closes the update stream connection, discards the dependent resources, and reestablishes the update stream. The ALTO client MAY retain the version tag of the last version of any tagged resources and give those version tags when requesting the new update stream. In this case, if a version is still current, the update stream server will not resend that resource.
更新ストリームサーバは、従属リソース（すなわち、前の例のコストマップ）の更新をタイムリーに送信する必要があります。ただし、ALTOクライアントが予想される更新を受信しない場合、簡単な回復方法は、ALTOクライアントがアップデートストリーム接続を閉じ、従属リソースを破棄し、更新ストリームを再確立することです。ALTOクライアントは、タグ付きリソースの最後のバージョンのバージョンタグを保持し、新しいアップデートストリームを要求するときにそれらのバージョンタグを与えることができます。この場合、バージョンがまだ現在の場合、Update Stream Serverはそのリソースを再送信しません。
Although not as efficient as possible, this recovery method is simple and reliable.
できるだけ効率的ではありませんが、この回復方法は簡単で信頼性があります。
If an update stream provides updates to a Filtered Cost Map that allows constraint tests, then an ALTO client MAY request updates to a Filtered Cost Map request with a constraint test. In this case, when a cost changes, the update stream server MUST send an update if the new value satisfies the test. If the new value does not, whether the update stream server sends an update depends on whether the previous value satisfied the test. If it did not, the update stream server SHOULD NOT send an update to the ALTO client. But if the previous value did, then the update stream server MUST send an update with a "null" value to inform the ALTO client that this cost no longer satisfies the criteria.
更新ストリームが制約テストを可能にするフィルタコストマップへの更新を提供する場合、ALTOクライアントは制約テストでフィルタ処理されたコストマップ要求に更新を要求することができる。この場合、コストが変更されると、新しい値がテストを満たしている場合、アップデートStream Serverはアップデートを送信する必要があります。新しい値がそうでない場合、アップデートStream Serverがアップデートを送信するかどうかは、前の値がテストを満たしているかどうかによって異なります。そうでない場合、Update Stream ServerはAltoクライアントに更新を送信しないでください。しかし、以前の値がした場合、アップデートStream Serverは、このコストが基準を満たしていないことをALTOクライアントに通知するために、アップデートStream Serverが "NULL"値で更新を送信する必要があります。
An update stream server can avoid having to handle such a complicated behavior by offering update streams only for Filtered Cost Maps that do not allow constraint tests.
アップデートストリームサーバは、制約テストを許可しないフィルタ処理されたコストマップに対してのみ更新ストリームを提供することによって、そのような複雑な動作を処理する必要がない。
For an ordinal mode cost map, a change to a single cost point may require updating many other costs. As an extreme example, suppose the lowest cost changes to the highest cost. For a numerical mode cost map, only that one cost changes. But for an ordinal mode cost map, every cost might change. While this document allows an update stream server to offer incremental updates for ordinal mode cost maps, update stream server implementors should be aware that incremental updates for ordinal costs are more complicated than for numerical costs, and ALTO clients should be aware that small changes may result in large updates.
序数モードコストマップの場合、単一のコストポイントへの変更は他の多くのコストを更新する必要があるかもしれません。極端な例として、最も低いコストが最も高いコストに変わるとします。数値モードコストマップの場合、その1コストが変化するだけです。しかし、序数モードのコストマップでは、すべてのコストが変わる可能性があります。このドキュメントでは、Update Stream Serverは序数モードコストマップの増分更新を提供することを可能にします.Stream Serverのメイン業者は、数値コストよりも序数コストの増分の更新がより複雑であり、ALTOクライアントは小さな変更が発生する可能性があることに注意する必要があります。大きな更新で。
An update stream server can avoid this complication by only offering full replacements for ordinal cost maps.
アップデートStream Serverは、序数コストマップの完全な置換を提供することによって、この複雑さを回避できます。
SSE was designed for events that consist of relatively small amounts of line-oriented text data, and SSE clients frequently read input one line at a time. However, an update stream sends a full cost map as a single events, and a cost map may involve megabytes, if not tens of megabytes, of text. This has implications that the ALTO client and the update stream server may consider.
SSEは、比較的少量の線指向テキストデータで構成され、SSEクライアントが一度に1ラインを入力することがよくあります。ただし、アップデートストリームは単一のイベントとしてフルコストマップを送信し、テキストの数十メガバイトであれば、メガバイトを含めることができます。これは、ALTOクライアントとアップデートストリームサーバーが考慮されることがあります。
First, some SSE client libraries read all data for an event into memory and then present it to the client as a character array. However, a client may not have enough memory to hold the entire JSON text for a large cost map. Hence, an ALTO client SHOULD consider using an SSE library that presents the event data in manageable chunks, so the ALTO client can parse the cost map incrementally and store the underlying data in a more compact format.
まず、一部のSSEクライアントライブラリは、イベントのすべてのデータをメモリに読み込み、それを文字配列としてクライアントに提示します。ただし、クライアントには、JSONテキスト全体を大規模なコストマップに保持するのに十分なメモリがない可能性があります。したがって、ALTOクライアントは、管理可能なチャンク内のイベントデータを提示するSSEライブラリを使用することを検討する必要があるため、ALTOクライアントはコストマップを徐々に解析し、基礎となるデータをよりコンパクトな形式で保存できます。
Second, an SSE client library may use a low-level, generic socket read library that stores each line of an event data, just in case the higher-level parser may need the line delimiters as part of the protocol formatting. A server sending a complete cost map as a single line may then generate a multi-megabyte data "line", and such a long line may then require complex memory management at the client. It is RECOMMENDED that an update stream server limit the lengths of data lines.
第2に、SSEクライアントライブラリは、上位レベルのパーサがプロトコルフォーマットの一部としてライン区切り文字を必要とする可能性がある場合に、イベントデータの各行を格納する低レベルの一般的なソケットリードライブラリを使用することができます。その後、完全なコストマップを単一の行として送信するサーバは、マルチメガバイトデータ「行」を生成し、そのような長い行はクライアントで複雑なメモリ管理を必要とする可能性がある。Update Stream Serverがデータ行の長さを制限することをお勧めします。
Third, an SSE server may use a library, which may put line breaks in places that would have semantic consequences for the ALTO updates; see Section 11. The update stream server implementation MUST ensure that no line breaks are introduced to change the semantics.
第3に、SSEサーバはライブラリを使用することができ、これはALTOの更新に対する意味的な結果がある場所でラインブレークを置くことができます。See Stream Serverの実装は、セマンティクスを変更するために改行が導入されていないことを確認する必要があります。
The security considerations (Section 15 of [RFC7285]) of the base protocol 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.
基本プロトコルのセキュリティ上の考慮事項（RFC7285]のセクション15）は、この拡張に完全に適用されます。たとえば、同じ信憑性と整合性の考慮事項（[RFC7285のセクション15.1）がまだ完全に適用されます。ALTOユーザーのプライバシーに関する同じ考察（[RFC7285のセクション15.4）もまだ完全に適用されます。
The additional services (addition of update streams and stream control URIs) provided by this extension extend the attack surface described in Section 15.1.1 of [RFC7285]. Below, we discuss the additional risks and their remedies.
この拡張によって提供される追加のサービス（更新ストリームおよびストリーム制御URIの追加）は、[RFC7285]のセクション15.1.1に記載されている攻撃面を拡張する。以下に、追加のリスクとその救済策について説明します。
Allowing persistent update stream connections enables a new class of Denial-of-Service attacks.
永続的なアップデートストリーム接続を許可すると、新しいクラスのサービス拒否攻撃が可能になります。
For the update stream server, an ALTO client might create an unreasonable number of update stream connections or add an unreasonable number of substream-ids to one update stream.
Update Stream Serverの場合、ALTOクライアントは、不合理な数の更新ストリーム接続を作成したり、不合理な数のサブストリームIDを1つの更新ストリームに追加することがあります。
To avoid these attacks on the update stream server, the server SHOULD choose to limit the number of active streams and reject new requests when that threshold is reached. An update stream server SHOULD also choose to limit the number of active substream-ids on any given stream or limit the total number of substream-ids used over the lifetime of a stream and reject any stream control request that would exceed those limits. In these cases, the update stream server SHOULD return the HTTP status "503 Service Unavailable".
アップデートStream Serverへのこれらの攻撃を回避するために、サーバーはアクティブなストリームの数を制限し、そのしきい値に達したときに新しい要求を拒否することを選択します。Update Stream Serverは、特定のストリーム上のアクティブなサブストリームIDの数を制限するか、ストリームの有効期間で使用されるサブストリームIDの総数を制限し、それらの制限を超えるストリーム制御要求を拒否することも選択する必要があります。このような場合、Update Stream ServerはHTTPステータス "503サービスが利用できない"を返すべきです。
It is important to note that the preceding approaches are not the only possibilities. For example, it may be possible for the update stream server to use somewhat more clever logic involving IP reputation, rate-limiting, and compartmentalization of the overall threshold into smaller thresholds that apply to subsets of potential clients.
前のアプローチが唯一の可能性ではないことに注意することが重要です。例えば、アップデートStream Serverは、IPレピュテーション、レート制限、および全体的なしきい値の区分化を含むやや賢いロジックを使用して、潜在的なクライアントのサブセットに適用される小さなしきい値に使用することが可能であり得る。
While the preceding techniques prevent update stream DoS attacks from disrupting an update stream server's other services, it does make it easier for a DoS attack to disrupt the update stream service. Therefore, an update stream server MAY prefer to restrict update stream services to authorized clients, as discussed in Section 15 of [RFC7285].
上記の手法では、アップデートStream DOS攻撃が更新プログラムサーバーの他のサービスを中断するのを防ぎますが、DOS攻撃がアップデートストリームサービスを中断するのが簡単になります。したがって、[RFC7285]のセクション15で説明したように、アップデート・ストリーム・サーバーは、更新ストリーム・サービスを承認されたクライアントに制限することを好むことがあります。
Alternatively, an update stream server MAY return the HTTP status "307 Temporary Redirect" to redirect the client to another ALTO server that can better handle a large number of update streams.
あるいは、更新ストリームサーバは、多数の更新ストリームをよりよく処理することができる別のALTOサーバにクライアントをリダイレクトするために、更新ステータスサーバをHTTPステータス「307一時リダイレクト」を返すことができる。
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. Under overloading, the client MAY choose to remove the information resources with high update rates.
継続的な更新の可用性は、ALTOクライアント、特に、処理機能が限られているALTOクライアントの過負荷を引き起こす可能性があります。現在の設計には、クライアントがサーバーからの更新速度を短縮するためのフロー制御メカニズムは含まれていません。オーバーロード中、クライアントは、更新レートの高い情報リソースを削除することを選択できます。
Also, under overloading, the client may 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.
また、過負荷の下で、クライアントは、情報がまだ新鮮であるか古くなっているかどうかを検出できなくなる可能性があります。そのような場合、クライアントは安定性や効率の問題を回避するために情報を使用する方法に注意してください。
10.3. Stream Control: Spoofed Control Requests and Information Breakdown
10.3. ストリーム制御：偽装制御要求と情報の内訳
An outside party that can read the update stream response or that can observe stream control requests can obtain the control URI and use that to send a fraudulent "remove" requests, thus disabling updates for the valid ALTO client. This can be avoided by encrypting the update stream and stream control requests (see Section 15 of [RFC7285]). Also, the update stream server echoes the "remove" requests on the update stream, so the valid ALTO client can detect unauthorized requests.
更新ストリーム応答を読み取ることができる、またはストリーム制御要求を観察することができる外部のパーティは、制御URIを取得し、それを使用して不正な「削除」要求を送信することができ、したがって有効なALTOクライアントの更新を無効にすることができます。これは、更新ストリームとストリーム制御要求を暗号化することで回避できます（[RFC7285]のセクション15を参照）。また、Update Stream Serverはアップデートストリームで「削除」要求をエコーします。そのため、有効なALTOクライアントは不正な要求を検出できます。
In general, as the architecture allows the possibility for the update stream server and the stream control server to be different entities, the additional risks should be evaluated and remedied. For example, the private communication path between the servers may be attacked, resulting in a risk of communications breakdown between them, as well as invalid or spoofed messages claiming to be on that private communications path. Proper security mechanisms, including confidentiality, authenticity, and integrity mechanisms, should be considered.
一般に、アーキテクチャでは、アップデートStream ServerとStream Control Serverが異なるエンティティになる可能性があるため、追加のリスクを評価して修復する必要があります。例えば、サーバ間のプライベート通信経路は攻撃され、それらの間の通信の内訳、ならびにそのプライベート通信経路上にあると主張する無効または偽装されたメッセージがある。機密性、信憑性、および完全性メカニズムを含む適切なセキュリティメカニズムを考慮する必要があります。
Although this design is quite flexible, it has underlying requirements.
このデザインはかなり柔軟ですが、その下にある要件があります。
The key requirements are that (1) each data update message is for a single resource and (2) an incremental change can be applied only to a resource that is a single JSON object, as both JSON merge patch and JSON patch can apply only to a single JSON object. Hence, if a future ALTO resource can contain multiple objects, then either each individual object also has a resource-id or an extension to this design is made.
重要な要件は、（1）各データ更新メッセージが単一のリソース用であり、（2）、JSON Merge PatchとJSONパッチの両方がにのみ適用できるため、単一のJSONオブジェクトであるリソースにのみ増分変更を適用できます。単一のJSONオブジェクト。したがって、将来のALTOリソースに複数のオブジェクトを含めることができれば、各個々のオブジェクトにもリソースIDがあり、またはこのデザインへの拡張機能も行われます。
At the low-level encoding level, new line in SSE has its own semantics. Hence, this design requires that resource encoding does not include new lines that can be confused with SSE encoding. In particular, the data update message MUST NOT include "event: " or "data: " at a new line as part of data message.
低レベルのエンコーディングレベルでは、SSE内の新しい行には独自のセマンティクスがあります。したがって、この設計では、リソースエンコーディングにSSEエンコーディングと混同できる新しい行が含まれていないことが必要です。特に、データメッセージの一部として、データ更新メッセージに「イベント：」または「データ：」を含めてはいけません。
If an update stream provides updates to a Filtered Cost Map that allows constraint tests, the requirements for such services are stated in Section 9.3.
アップデートストリームが制約テストを可能にするフィルタリングコストマップへの更新を提供する場合、そのようなサービスの要件はセクション9.3に記載されています。
This document defines two new media types: "application/alto-updatestreamparams+json", as described in Section 6.5, and "application/alto-updatestreamcontrol+json", as described in Section 5.3. All other media types used in this document have already been registered, either for ALTO, JSON merge patch, or JSON patch.
このドキュメントでは、セクション6.5で説明されている「アプリケーション/ alto-updateStreamParams json」と「application / alto-updatestreamparams json」と「Application / Alto-UpdateStreamControl JSON」を定義しています。この文書で使用されている他のすべてのメディアタイプは、Alto、JSON Merge Patch、またはJSONパッチのどちらかに登録されています。
Type name: application
タイプ名：アプリケーション
Subtype name: alto-updatestreamparams+json
サブタイプ名：alto-updatestreamparams 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: Security considerations relating to the generation and consumption of ALTO Protocol messages are discussed in Section 10 of RFC 8895 and Section 15 of [RFC7285].
セキュリティ上の考慮事項：ALTOプロトコルメッセージの生成と消費に関するセキュリティ上の考慮事項は、RFC 8895の第10章および[RFC7285]の第15章で説明しています。
Interoperability considerations: RFC 8895 specifies format of conforming messages and the interpretation thereof.
相互運用性の考慮事項：RFC 8895は、適合メッセージのフォーマットとその解釈を指定します。
Published specification: Section 6.5 of RFC 8895.
公開仕様：RFC 8895のセクション6.5。
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
File extension(s): RFC 8895 uses the media type to refer to protocol messages and thus does not require a file extension.
ファイル拡張子：RFC 8895はメディアタイプを使用してプロトコルメッセージを参照しているため、ファイル拡張子を必要としません。
Macintosh file type code(s): N/A
Person & email address to contact for further information: See Authors' Addresses section.
その他の情報について連絡先のある人とEメールアドレス：作家の住所のセクションを参照してください。
Intended usage: COMMON
意図された使用法：一般的な
Restrictions on usage: N/A
使用制限：N / A.
Author: See Authors' Addresses section.
著者：作者の住所のセクションを参照してください。
Change controller: Internet Engineering Task Force (mailto:iesg@ietf.org).
変更コントローラー：インターネットエンジニアリングタスクフォース（Mailto：iesg@ietf.org）。
Type name: application
タイプ名：アプリケーション
Subtype name: alto-updatestreamcontrol+json
サブタイプ名：alto-updateSreamControl 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: Security considerations relating to the generation and consumption of ALTO Protocol messages are discussed in Section 10 of RFC 8895 and Section 15 of [RFC7285].
セキュリティ上の考慮事項：ALTOプロトコルメッセージの生成と消費に関するセキュリティ上の考慮事項は、RFC 8895の第10章および[RFC7285]の第15章で説明しています。
Interoperability considerations: RFC 8895 specifies format of conforming messages and the interpretation thereof.
相互運用性の考慮事項：RFC 8895は、適合メッセージのフォーマットとその解釈を指定します。
Published specification: Section 5.3 of RFC 8895.
公開仕様：RFC 8895のセクション5.3。
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
File extension(s): RFC 8895 uses the media type to refer to protocol messages and thus does not require a file extension.
ファイル拡張子：RFC 8895はメディアタイプを使用してプロトコルメッセージを参照しているため、ファイル拡張子を必要としません。
Macintosh file type code(s): N/A
Person & email address to contact for further information: See Authors' Addresses section.
その他の情報について連絡先のある人とEメールアドレス：作家の住所のセクションを参照してください。
Intended usage: COMMON
意図された使用法：一般的な
Restrictions on usage: N/A
使用制限：N / A.
Author: See Authors' Addresses section.
著者：作者の住所のセクションを参照してください。
Change controller: Internet Engineering Task Force (mailto:iesg@ietf.org).
変更コントローラー：インターネットエンジニアリングタスクフォース（Mailto：iesg@ietf.org）。
If an update stream is closed accidentally, when the ALTO client reconnects, the update stream server must resend the full maps. This is clearly inefficient. To avoid that inefficiency, the SSE specification allows an update stream server to assign an id to each event. When an ALTO client reconnects, the ALTO client can present the id of the last successfully received event, and the update stream server restarts with the next event.
アップデートストリームが誤って閉じられている場合、ALTOクライアントが再接続されると、アップデートStream Serverは全マップを再送信する必要があります。これは明らかに非効率的です。その非効率性を避けるために、SSE仕様はUpdate Stream Serverが各イベントにIDを割り当てることを可能にします。ALTOクライアントが再接続すると、ALTOクライアントは最後に正常に受信されたイベントのIDを提示でき、アップデートStream Serverは次のイベントで再起動します。
However, that mechanism adds additional complexity. The update stream server must save SSE messages in a buffer in case ALTO clients reconnect. But that mechanism will never be perfect: If the ALTO client waits too long to reconnect or if the ALTO client sends an invalid ID, then the update stream server will have to resend the complete maps anyway.
ただし、そのメカニズムは追加の複雑さを追加します。ALTOクライアントが再接続されている場合は、Update Stream ServerはSSEメッセージをバッファに保存する必要があります。しかし、そのメカニズムは決して完璧になることはありません.ALTOクライアントが再接続に時間がかかりすぎる場合、またはALTOクライアントが無効なIDを送信した場合、アップデートStream Serverはとにかく完全なマップを再送信する必要があります。
Furthermore, this is unlikely to be a problem in practice. ALTO clients who want continuous updates for large resources, such as full network and cost maps, are likely to be things like P2P trackers. These ALTO clients will be well connected to the network; they will rarely drop connections.
さらに、これは実際には問題になる可能性は低いです。フルネットワークやコストマップなど、大資源のための継続的なアップデートを希望するALTOクライアントは、P2Pトラッカーのようなものである可能性があります。これらのALTOクライアントはネットワークによく接続されます。彼らはめったに接続を落とすことはめったにありません。
Mobile devices certainly can and do drop connections and will have to reconnect. But mobile devices will not need continuous updates for multi-megabyte cost maps. If mobile devices need continuous updates at all, they will need them for small queries, such as the costs from a small set of media servers from which the device can stream the currently playing movie. If the mobile device drops the connection and reestablishes the update stream, the update stream server will have to retransmit only a small amount of redundant data.
モバイル機器は確かに接続を落として行うことができ、再接続する必要があります。しかし、モバイルデバイスは、マルチメガバイトコストマップのための継続的な更新を必要としません。モバイルデバイスがまったく継続的な更新を必要とする場合、それらは、デバイスが現在再生中のムービーをストリーミングできるメディアサーバーの小さなセットからのコストなど、それらを必要とします。モバイルデバイスが接続をドロップしてアップデートストリームを再確立すると、アップデートStream Serverは少量の冗長データしか再送信される必要があります。
In short, using event ids to avoid resending the full map adds a considerable amount of complexity to avoid a situation that is very rare. The complexity is not worth the benefit.
つまり、フルマップを再送信しないようにイベントIDを使用して、非常にまれな状況を回避するためにかなりの量の複雑さが追加されます。複雑さは利益の価値がない。
The update stream service does allow the ALTO client to specify the tag of the last received version of any tagged resource, and if that is still current, the update stream server need not retransmit the full resource. Hence, ALTO clients can use this to avoid retransmitting full network maps. Cost maps are not tagged, so this will not work for them. Of course, the ALTO protocol could be extended by adding version tags to cost maps, which would solve the retransmission-on-reconnect problem. However, adding tags to cost maps might add a new set of complications.
Update Stream Serviceは、ALTOクライアントがタグ付けされたリソースの最後の受信バージョンのタグを指定できるようにします。これがまだ現在の場合、アップデートStream Serverはフルリソースを再送信する必要はありません。したがって、ALTOクライアントはこれを使用してフルネットワークマップを再送信するのを避けることができます。コストマップはタグ付けされていないため、これはそれらのためには機能しません。もちろん、ALTOプロトコルは、再送信オンリカネートの問題を解決するためのコストマップにバージョンタグを追加することによって拡張することができます。ただし、コストマップにタグを追加すると、新しい合併症のセットが追加される可能性があります。
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, DOI 10.17487/RFC2387, August 1998, <https://www.rfc-editor.org/info/rfc2387>.
[RFC2387] Levinson、E.、「MIMEマルチパート/関連コンテンツタイプ」、RFC 2387、DOI 10.17487 / RFC2387、1998年8月、<https://www.rfc-editor.org/info/rfc2387>。
[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>.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、「Uniform Resource Identifier（URI）：汎用構文」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J.、およびT.Hansen、「メディアタイプの仕様および登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<https：///www.rfc-editor.org/info/rfc6838>。
[RFC6902] Bryan, P., Ed. and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Patch", RFC 6902, DOI 10.17487/RFC6902, April 2013, <https://www.rfc-editor.org/info/rfc6902>.
[RFC6902] Bryan、P.、ED。M. Nottingham、Ed。、「JavaScriptオブジェクト表記（JSON）パッチ」、RFC 6902、DOI 10.17487 / RFC6902、2013年4月、<https：//www.rfc-editor.org/info/rfc6902>。
[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>.
[RFC7285] Alimi、R.、Ed。、Penno、R.、Ed。、Yang、Y、Ed。、Kiesel、S.、Previdi、S.、Roome、W.、Shalunov、S.、およびR。不安、「アプリケーション層交通最適化（ALTO）プロトコル」、RFC 7285、DOI 10.17487 / RFC7285、2014年9月、<https：//www.rfc-editor.org/info/rfc7285>。
[RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396, DOI 10.17487/RFC7396, October 2014, <https://www.rfc-editor.org/info/rfc7396>.
[RFC7396] Hoffman、P.およびJ.Snell、 "Json Merge Patch"、RFC 7396、DOI 10.17487 / RFC7396、2014年10月、<https：//www.rfc-editor.org/info/rfc7396>。
[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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<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>.
[RFC8259] Bray、T.、ED。、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https：//www.rfc-editor.org/ info / rfc8259>。
[SSE] Hickson, I., "Server-Sent Events", W3C Recommendation, February 2015, <https://www.w3.org/TR/eventsource/>.
[SSE] Hickson、I。、「サーバー送信イベント」、W3C勧告、2015年2月、<https：//www.w3.org/tr/eventSource/>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「ストリーム制御伝送プロトコル」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https：//www.rfc-editor.org/info/rfc4960>。
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, DOI 10.17487/RFC5789, March 2010, <https://www.rfc-editor.org/info/rfc5789>.
[RFC5789] DusseAll、L.およびJ.Snell、RFC 5789、DOI 10.17487 / RFC5789、2010年3月、<https：//www.rfc-editor.org/info/rfc5789>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールド、R.、ED。J.Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：メッセージ構文とルーティング」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https：//www.rfc-editor.org/info/RFC7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding、R.、Ed。J. Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：セマンティクスとコンテンツ」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231>。
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540] Belshe、M.、Peon、R.およびM.Thomson、Ed。、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<https：//www.rfc-editor.org/info/rfc7540>。
Acknowledgments
謝辞
Thank you to Dawn Chen (Tongji University), Shawn Lin (Tongji University), and Xiao Shi (Yale University) for their contributions to an earlier version of this document.
この文書の以前のバージョンへの貢献のために、夜明け陳（振らせ）、Shawn Lin（Tongji大学）、Xiao Shi（Yale University）をありがとうございました。
Contributors
貢献者
Sections 2, 5.1, 5.2, and 8.5 of this document are based on contributions from Jingxuan Jensen Zhang, and he is considered an author.
この文書のセクション2,5.1,5.2、および8.5は、Jingxuan Jensen Zhangの貢献に基づいており、彼は作者と見なされています。
Authors' Addresses
著者の住所
Wendy Roome Nokia Bell Labs (Retired) 124 Burlington Rd Murray Hill, NJ 07974 United States of America
Wendy Rooome Nokia Bell Labs（引退）124 Burllington RD Murray Hill、NJ 07974アメリカ合衆国
Phone: +1-908-464-6975
Email: wendy@wdroome.com
Y. Richard Yang Yale University 51 Prospect St New Haven, CT United States of America
Y. Richard Yang Yale University 51 Prospect St New Haven、CT
Email: yry@cs.yale.edu