Network Working Group A. Beck
Request for Comments: 3836 M. Hofmann
Category: Informational Lucent Technologies
H. Orman
Purple Streak Development
R. Penno
Nortel Networks
A. Terzis
Johns Hopkins University
August 2004
Requirements for Open Pluggable Edge Services (OPES)
Callout Protocols
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document specifies the requirements that the OPES (Open Pluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services. The requirements are intended to help evaluate possible protocol candidates, as well as to guide the development of such protocols.
この文書は、OPES（オープンプラグイン可能なエッジサービス）コールアウトプロトコルはOPESサービスのリモート実行をサポートするために満たさなければならない要件を指定します。要件は、可能なプロトコルの候補を評価するために、ならびにそのようなプロトコルの開発を導くことを意図しています。
Table of Contents
目次
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Functional Requirements . . . . . . . . . . . . . . . . . . . 3
3.1. Reliability . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Congestion Avoidance . . . . . . . . . . . . . . . . . 3
3.3. Callout Transactions . . . . . . . . . . . . . . . . . 3
3.4. Callout Connections . . . . . . . . . . . . . . . . . . 4
3.5. Asynchronous Message Exchange . . . . . . . . . . . . . 5
3.6. Message Segmentation . . . . . . . . . . . . . . . . . 5
3.7. Support for Keep-Alive Mechanism . . . . . . . . . . . 6
3.8. Operation in NAT Environments . . . . . . . . . . . . . 6
3.9. Multiple Callout Servers . . . . . . . . . . . . . . . 6
3.10. Multiple OPES Processors . . . . . . . . . . . . . . . 6
3.11. Support for Different Application Protocols . . . . . . 7
3.12. Capability and Parameter Negotiations . . . . . . . . . 7
3.13. Meta Data and Instructions . . . . . . . . . . . . . . 8
4. Performance Requirements . . . . . . . . . . . . . . . . . . 9
4.1. Protocol Efficiency . . . . . . . . . . . . . . . . . . 9
5. Security Requirements . . . . . . . . . . . . . . . . . . . . 9
5.1. Authentication, Confidentiality, and Integrity . . . . 9
5.2. Hop-by-Hop Confidentiality. . . . . . . . . . . . . . . 10
5.3. Operation Across Untrusted Domains. . . . . . . . . . . 10
5.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References. . . . . . . . . . . . . . . . . . 10
7.2. Informative References. . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 12
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 13
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[2]。
The Open Pluggable Edge Services (OPES) architecture [1] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze, and possibly transform, application-level messages exchanged between the data provider and the data consumer.
[1]開きプラガブルエッジサービス（OPES）アーキテクチャは、データプロバイダ、データコンシューマ、およびゼロ以上OPESプロセッサ間の連携アプリケーションサービス（OPESサービス）を可能にします。検討中のアプリケーションサービスは、アプリケーションレベルのメッセージは、データプロバイダとデータコンシューマ間で交換、分析、そしておそらく変換します。
The execution of such services is governed by a set of rules installed on the OPES processor. The enforcement of rules can trigger the execution of service applications local to the OPES processor. Alternatively, the OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers. As described in [1], an OPES processor communicates with and invokes services on a callout server by using a callout protocol. This document presents the requirements for such a protocol.
このようなサービスの実行はOPESプロセッサにインストールされている一連の規則によって支配されています。規則の施行は、OPESプロセッサにローカル・サービス・アプリケーションの実行をトリガすることができます。あるいは、OPESプロセッサが通信し、1つまたは複数のリモートコールアウトサーバと連携することにより、サービス実行の責任を分散することができます。 [1]に記載されているように、OPESプロセッサはと通信し、コールアウトプロトコルを使用してコールアウトサーバ上のサービスを呼び出します。この文書では、そのようなプロトコルのための要件を提示します。
The requirements in this document are divided into three categories - functional requirements, performance requirements, and security requirements. Each requirement is presented as one or more statements, followed by brief explanatory material as appropriate.
機能要件、性能要件、およびセキュリティ要件 - この文書の要件は、3つのカテゴリに分類されています。各要件は、必要に応じて簡単に説明する材料、続いて1つ以上の文として提示されています。
The OPES callout protocol MUST be able to provide ordered reliability for the communication between an OPES processor and callout server. Additionally, the callout protocol SHOULD be able to provide unordered reliability.
OPESコールアウトプロトコルはOPESプロセッサとコールアウトサーバ間の通信のために順序付けられた信頼性を提供できなければなりません。また、コールアウトプロトコルは順不同信頼性を提供することができるべきです。
In order to satisfy the reliability requirements, the callout protocol SHOULD specify that it must be used with a transport protocol that provides ordered/unordered reliability at the transport-layer, for example TCP [6] or SCTP [7].
信頼性要件を満たすために、コールアウトプロトコルは、それはトランスポート層で注文/順不同の信頼性を提供するトランスポートプロトコルで使用されなければならないことを指定する必要があり、例えば、TCP [6]又はSCTP [7]。
The OPES callout protocol MUST ensure that congestion avoidance matching the standard of RFC 2914 [4] is applied on all communication between the OPES processor and callout server. For this purpose, the callout protocol SHOULD use a congestion-controlled transport-layer protocol, presumably either TCP [6] or SCTP [7].
OPESコールアウトプロトコルは、RFC 2914の標準に合致すること輻輳回避を確保しなければならない[4] OPESプロセッサとコールアウトサーバ間のすべての通信に適用されます。この目的のために、コールアウトプロトコル[7] [6]又はSCTP輻輳制御トランスポート層プロトコル、おそらくTCPのいずれかを使用すべきです。
The OPES callout protocol MUST enable an OPES processor and a callout server to perform callout transactions with the purpose of exchanging partial or complete application-level protocol messages (or modifications thereof). More specifically, the callout protocol MUST enable an OPES processor to forward a partial or complete application message to a callout server so that one or more OPES services can process the forwarded application message (or parts thereof). The result of the service operation may be a modified application message. The callout protocol MUST therefore enable the callout server to return a modified application message or the modified parts of an application message to the OPES processor. Additionally, the callout protocol MUST enable a callout server to report the result of a callout transaction (e.g., in the form of a status code) back to the OPES processor.
OPESコールアウトプロトコルは、部分的または完全なアプリケーションレベルのプロトコルメッセージ（又はその変形）を交換する目的でコールアウト取引を実行するOPESプロセッサとコールアウトサーバを有効にする必要があります。具体的には、コールアウトプロトコルは、一つ以上のOPESサービスが転送されたアプリケーションメッセージ（またはその一部）を処理できるように、コールアウトサーバーに部分的または完全なアプリケーション・メッセージを転送するOPESプロセッサを有効にする必要があります。サービスオペレーションの結果が変更されたアプリケーションメッセージであってもよいです。コールアウトプロトコルは、従って、OPESプロセッサに変更されたアプリケーション・メッセージまたはアプリケーション・メッセージの変更された部分を返すために、コールアウトサーバを有効にする必要があります。また、コールアウトプロトコルは、バックOPESプロセッサに（ステータス・コードの形で、例えば、）コールアウトトランザクションの結果を報告するためにコールアウトサーバを有効にする必要があります。
A callout transaction is defined as a message exchange between an OPES processor and a callout server consisting of a callout request and a callout response. Both, the callout request and the callout response MAY each consist of one or more callout protocol messages, i.e. a series of protocol messages. A callout request MUST always contain a partial or complete application message. A callout response MUST always indicate the result of the callout transaction. A callout response MAY contain a modified application message.
コールアウトトランザクションがOPESプロセッサとコールアウト要求及びコールアウト応答から成るコールアウト・サーバ間のメッセージの交換として定義されます。両方は、コールアウト要求及びコールアウト応答は、それぞれ一つ以上のコールアウト・プロトコル・メッセージ、プロトコルメッセージの、すなわち一連からなることができます。コールアウト要求は常に部分的または完全なアプリケーションメッセージを含まなければなりません。コールアウト応答は常にコールアウトトランザクションの結果を示さなければなりません。コールアウト応答が変更されたアプリケーションメッセージを含むかもしれません。
Callout transactions are always initiated by a callout request from an OPES processor and are typically terminated by a callout response from a callout server. The OPES callout protocol MUST, however, also provide a mechanism that allows either endpoint of a callout transaction to terminate a callout transaction before a callout request or response has been completely received by the corresponding callout endpoint. Such a mechanism MUST ensure that a premature termination of a callout transaction does not result in the loss of application message data.
吹き出しトランザクションは常にOPESプロセッサからのコールアウト要求によって開始され、通常はコールアウトサーバからのコールアウト応答で終了します。 OPESコールアウトプロトコルは、しかし、また、コールアウト要求または応答が完全に対応するコールアウトエンドポイントによって受信される前にコールアウト・トランザクションのエンドポイントのいずれかがコールアウトトランザクションを終了することを可能にするメカニズムを提供しなければなりません。このようなメカニズムは、コールアウト取引の早期終了がアプリケーションメッセージデータの損失が生じないことを保証しなければなりません。
A premature termination of a callout transaction is required to support OPES services, which may terminate even before they have processed the entire application message. Content analysis services, for example, may be able to classify a Web object after having processed just the first few bytes of a Web object.
コールアウト取引の早期終了は、彼らは、アプリケーション全体のメッセージを処理していても前に終了することができOPESサービスをサポートするために必要です。コンテンツ分析サービスは、例えば、Webオブジェクトの最初の数バイトを処理した後、Webオブジェクトを分類することができるかもしれません。
The OPES callout protocol MUST enable an OPES processor and a callout server to perform multiple callout transactions over a callout connection. Additionally, the callout protocol MUST provide a method of associating callout transactions with callout connections. A callout connection is defined as a logical connection at the application-layer between an OPES processor and a callout server. A callout connection MAY have certain parameters associated with it, for example parameters that control the fail-over behavior of connection endpoints. Callout connection-specific parameters MAY be negotiated between OPES processors and callout servers (see Section 3.12).
OPESコールアウトプロトコルは、コールアウト接続を介して複数の吹き出しトランザクションを実行するためにOPESプロセッサとコールアウトサーバを有効にする必要があります。また、コールアウトプロトコルは、コールアウト接続でコールアウト取引を関連付ける方法を提供しなければなりません。コールアウト接続はOPESプロセッサとコールアウトサーバ間のアプリケーション層での論理的接続として定義されます。コールアウトの接続は、接続エンドポイントのフェイルオーバー動作を制御する、例えばパラメータのそれに関連付けられた特定のパラメータを有してもよいです。吹き出し接続固有のパラメータは、OPESプロセッサとコールアウトサーバ（3.12節を参照）との間で交渉されるかもしれません。
The OPES callout protocol MAY choose to multiplex multiple callout connections over a single transport-layer connection if a flow control mechanism that guarantees fairness among multiplexed callout connections is applied.
OPESコールアウトプロトコルは、多重コールアウト接続間の公平性を保証するフロー制御メカニズムが適用される場合、単一のトランスポート層接続を介して複数の吹き出し接続を多重化することを選ぶかもしれ。
Callout connections MUST always be initiated by an OPES processor. A callout connection MAY be closed by either endpoint of the connection, provided that doing so does not affect the normal operation of on-going callout transactions associated with the callout connection.
吹き出しの接続は常にOPESプロセッサによって開始されなければなりません。コールアウトの接続は、接続のいずれかのエンドポイントで閉じることができる、そうすることがコールアウト接続に関連付けられ、進行コールアウト取引の正常な動作には影響しないことを条件とします。
The OPES callout protocol MUST support an asynchronous message exchange over callout connections.
OPESコールアウトプロトコルは、コールアウト接続を介して非同期メッセージの交換をサポートしなければなりません。
In order to allow asynchronous processing on the OPES processor and callout server, it MUST be possible to separate request issuance from response processing. The protocol MUST therefore allow multiple outstanding callout requests and provide a method of correlating callout responses with callout requests.
OPESプロセッサとコールアウトサーバ上の非同期処理を可能にするためには、応答処理からの要求の発行を分離することが可能でなければなりません。プロトコルは、従って、複数の未処理のコールアウト要求を許可し、コールアウト要求にコールアウト応答を相関させる方法を提供しなければなりません。
Additionally, the callout protocol MUST enable a callout server to respond to a callout request before it has received the entire request.
また、コールアウトプロトコルは、それが全体の要求を受信した前にコールアウト要求に応答するコールアウトサーバを有効にする必要があります。
The OPES callout protocol MUST allow an OPES processor to forward an application message to a callout server in a series of smaller message fragments. The callout protocol MUST further enable the receiving callout server to re-assemble the fragmented application message.
OPESコールアウトプロトコルはOPESプロセッサが小さいメッセージフラグメントの直列にコールアウトサーバにアプリケーションメッセージを転送することを可能にしなければなりません。コールアウトプロトコルはさらに断片化されたアプリケーションメッセージを再アセンブルする受信コールアウトサーバを有効にする必要があります。
Likewise, the callout protocol MUST enable a callout server to return an application message to an OPES processor in a series of smaller message fragments. The callout protocol MUST enable the receiving OPES processor to re-assemble the fragmented application message.
同様に、コールアウトプロトコルは、より小さなメッセージフラグメントの直列OPESプロセッサにアプリケーション・メッセージを返すためにコールアウトサーバを有効にする必要があります。コールアウトプロトコルは、断片化されたアプリケーションメッセージを再アセンブルする受信OPESプロセッサを有効にする必要があります。
Depending on the application-layer protocol used on the data path, application messages may be very large in size (for example in the case of audio/video streams) or of unknown size. In both cases, the OPES processor has to initiate a callout transaction before it has received the entire application message to avoid long delays for the data consumer. The OPES processor MUST therefore be able to forward fragments or chunks of an application message to a callout server as it receives them from the data provider or consumer. Likewise, the callout server MUST be able to process and return application message fragments as it receives them from the OPES processor.
データパスで使用されるアプリケーション層のプロトコルに応じて、アプリケーション・メッセージは、（オーディオ/ビデオストリームの場合など）または未知のサイズの大きさに非常に大きくてもよいです。両方の場合において、OPESプロセッサは、データ消費者のための長時間の遅延を回避するために、アプリケーション全体のメッセージを受信する前にコールアウトトランザクションを開始しなければなりません。 OPESプロセッサは、したがって、それはデータプロバイダまたは消費者からそれらを受信するコールアウトサーバにアプリケーション・メッセージの断片またはチャンクを転送できなければなりません。同様に、コールアウトサーバは、OPESプロセッサからそれらを受け取るように、アプリケーションのメッセージフラグメントを処理し、返すことができなければなりません。
Application message segmentation is also required if the OPES callout protocol provides a flow control mechanism in order to multiplex multiple callout connections over a single transport-layer connection (see Section 3.4).
OPESコールアウトプロトコルは、単一のトランスポート層接続を介して複数の吹き出し接続を多重化するために、フロー制御機構を提供する場合、アプリケーション・メッセージ分割も必要とされる（セクション3.4参照）。
The OPES callout protocol MUST provide a keep-alive mechanism which, if used, would allow both endpoints of a callout connection to detect a failure of the other endpoint, even in the absence of callout transactions. The callout protocol MAY specify that keep-alive messages be exchanged over existing callout connections or a separate connection between OPES processor and callout server. The callout protocol MAY also specify that the use of the keep-alive mechanism is optional.
OPESコールアウトプロトコルが、使用される場合、コールアウト接続の両方のエンドポイントでもコールアウトトランザクションが存在しない場合に、他のエンドポイントの障害を検出することを可能にするキープアライブ機構を提供しなければなりません。コールアウトプロトコルは、既存のコールアウトの接続やOPESプロセッサとコールアウトサーバ間の個別の接続を介して交換されているキープアライブメッセージを指定するかもしれません。コールアウトプロトコルはまた、キープアライブメカニズムの使用は任意であることを指定してもよいです。
The detection of a callout server failure may enable an OPES processor to establish a callout connection with a stand-by callout server so that future callout transactions do not result in the loss of application message data. The detection of the failure of an OPES processor may enable a callout server to release resources which would otherwise not be available for callout transactions with other OPES processors.
コールアウトサーバ障害の検出は、将来のコールアウトトランザクションがアプリケーション・メッセージ・データが失われないようにスタンドバイコールアウトサーバとコールアウトの接続を確立するために、OPESプロセッサを可能にすることができます。 OPESプロセッサの故障の検出は、そうでなければ他のOPESプロセッサとコールアウト取引のために利用可能ではないリソースを解放するためにコールアウトサーバーを可能にすることができます。
The OPES protocol SHOULD be NAT-friendly, i.e., its operation should not be compromised by the presence of one or more NAT devices in the path between an OPES processor and a callout server.
OPESプロトコルは、NATに優しい、すなわちされるべきであり、その動作はOPESプロセッサとコールアウトサーバとの間の経路内の1つまたは複数のNATデバイスの存在によって損なわれるべきではありません。
The OPES callout protocol MUST allow an OPES processor to simultaneously communicate with more than one callout server.
OPESコールアウトプロトコルはOPESプロセッサは、同時に複数のコールアウトサーバと通信することを可能にしなければなりません。
In larger networks, OPES services are likely to be hosted by different callout servers. Therefore, an OPES processor will likely have to communicate with multiple callout servers. The protocol design MUST enable an OPES processor to do so.
大規模なネットワークでは、OPESサービスが異なるコールアウトサーバによってホストされる可能性が高いです。したがって、OPESプロセッサはおそらく、複数のコールアウトサーバと通信する必要があります。プロトコルの設計は、そうするOPESプロセッサを有効にする必要があります。
The OPES callout protocol MUST allow a callout server to simultaneously communicate with more than one OPES processor.
OPESコールアウトプロトコルは、コールアウトサーバが同時に複数のOPESプロセッサと通信することを可能にしなければなりません。
The protocol design MUST support a scenario in which multiple OPES processors use the services of a single callout server.
プロトコルの設計は、複数のOPESプロセッサは、単一のコールアウトサーバーのサービスを使用するシナリオをサポートしなければなりません。
The OPES callout protocol SHOULD be application protocol-agnostic, i.e., it SHOULD not make any assumptions about the characteristics of the application-layer protocol used on the data path between the data provider and data consumer. At a minimum, the callout protocol MUST be compatible with HTTP [5].
OPESコールアウトプロトコルは、アプリケーションプロトコルに依存しない、すなわち、それはデータ・プロバイダとデータコンシューマの間のデータ経路上で使用されるアプリケーション層プロトコルの特性についての仮定を行うべきではないであるべきです。最低でも、コールアウトプロトコルはHTTP [5]と互換性がなければなりません。
The OPES entities on the data path may use different application-layer protocols, including, but not limited to, HTTP [5] and RTP [8]. It would be desirable to be able to use the same OPES callout protocol for any such application-layer protocol.
データパス上OPESエンティティを含む異なるアプリケーション層プロトコルを使用するが、HTTP、これらに限定されないかもしれない[5]及びRTP [8]。任意のそのようなアプリケーション層プロトコルの同じOPESコールアウトプロトコルを使用することができることが望ましいであろう。
The OPES callout protocol MUST support the negotiation of capabilities and callout connection parameters between an OPES processor and a callout server. This implies that the OPES processor and the callout server MUST be able to exchange their capabilities and preferences. Then they MUST be able to engage in a deterministic negotiation process that terminates either with the two endpoints agreeing on the capabilities and parameters to be used for future callout connections/transactions or with a determination that their capabilities are incompatible.
OPESコールアウトプロトコルはOPESプロセッサとコールアウトサーバとの間の機能およびコールアウト接続パラメータのネゴシエーションをサポートしなければなりません。これは、OPESプロセッサとコールアウトサーバは自分の能力や好みを交換することができなければならないことを意味します。その後、彼らは2つのエンドポイントは、将来のコールアウト接続/トランザクションのためまたはそれらの機能に互換性がないという決意で使用する機能やパラメータに同意のいずれかで終了し、確定交渉プロセスに携わることができなければなりません。
Capabilities and parameters that could be negotiated between an OPES processor and a callout server include (but are not limited to): callout protocol version, fail-over behavior, heartbeat rate for keep-alive messages, security-related parameters, etc.
機能とOPESプロセッサとコールアウトサーバーが含ま間で交渉することができます（ただし、これらに限定されない）パラメータ：コールアウトプロトコルバージョン、フェイルオーバ行動、キープアライブメッセージのための心拍数、セキュリティ関連のパラメータなど
The callout protocol MUST NOT use negotiation to determine the transport protocol to be used for callout connections. The callout protocol MAY, however, specify that a certain application message protocol (e.g., HTTP [5], RTP [8]) requires the use of a certain transport protocol (e.g., TCP [6], SCTP [7]).
コールアウトプロトコルは、コールアウトの接続に使用するトランスポートプロトコルを決定するためにネゴシエーションを使用してはなりません。コールアウトプロトコルMAYは、しかし、特定のアプリケーション・メッセージ・プロトコル（例えば、HTTP [5]、RTP [8]）特定のトランスポートプロトコルの使用を必要とすることを指定する（例えば、TCP [6]、SCTP [7]）。
Callout connection parameters may also pertain to the characteristics of OPES callout services if, for example, callout connections are associated with one or more specific OPES services. An OPES service-specific parameter may, for example, specify which parts of an application message an OPES service requires for its operation.
例えば、コールアウト接続は、1つ以上の特定OPESサービスに関連付けられている、場合吹き出し接続パラメータもOPESコールアウトサービスの特性に関係してもよいです。 OPESサービス固有のパラメータは、例えば、OPESサービスが動作するために必要とするアプリケーション・メッセージの部分を指定することができます。
Callout connection parameters MUST be negotiated on a per-callout connection basis and before any callout transactions are performed over the corresponding callout connection. Other parameters and capabilities, such as the fail-over behavior, MAY be negotiated between the two endpoints independently of callout connections.
吹き出し接続パラメータごとのコールアウト接続ごとにネゴシエートされなければならないし、任意の吹き出しトランザクションは、対応するコールアウト接続を介して実行される前に。このようフェイルオーバー動作と他のパラメータと機能は、独立して、コールアウト接続の2つのエンドポイント間で交渉されるかもしれません。
The parties to a callout protocol MAY use callout connections to negotiate all or some of their capabilities and parameters. Alternatively, a separate control connection MAY be used for this purpose.
コールアウトプロトコルの当事者は、その機能やパラメータの全部または一部を交渉するためにコールアウト接続を使用するかもしれません。代替的に、別個の制御接続は、この目的に使用することができます。
The OPES callout protocol MUST provide a mechanism for the endpoints of a particular callout transaction to include metadata and instructions for the OPES processor or callout server in callout requests and responses.
OPESコールアウトプロトコルは、コールアウト要求と応答にOPESプロセッサまたはコールアウトサーバのメタデータおよび命令を含むように特定のコールアウトトランザクションのエンドポイントのためのメカニズムを提供しなければなりません。
Specifically, the callout protocol MUST enable an OPES processor to include information about the forwarded application message in a callout request, e.g. in order to specify the type of forwarded application message or to specify what part(s) of the application message are forwarded to the callout server. Likewise, the callout server MUST be able to include information about the returned application message.
具体的には、コールアウトプロトコルは、例えば、コールアウト要求で転送アプリケーションメッセージについての情報を含むようにOPESプロセッサを有効にする必要があります転送されたアプリケーションメッセージのタイプを指定したり、アプリケーション・メッセージのどの部分（複数可）を指定するために、コールアウトサーバに転送されます。同様に、コールアウトサーバは、返されたアプリケーションメッセージについての情報を含めることができなければなりません。
The OPES processor MUST further be able to include an ordered list of one or more uniquely specified OPES services which are to be performed on the forwarded application message in the specified order. However, as the callout protocol MAY also choose to associate callout connections with specific OPES services, there may not be a need to identify OPES services on a per-callout transaction basis.
OPESプロセッサは、さらに、指定された順序で転送されたアプリケーションメッセージに対して実行される1つの以上の一意に特定OPESサービスの順序付けられたリストを含むことができなければなりません。コールアウトプロトコルは、特定のOPESサービスとのコールアウトの接続を関連付けるために選ぶかもしれしかし、ごとのコールアウトトランザクションごとにOPESサービスを特定する必要がないかもしれません。
Additionally, the OPES callout protocol MUST allow the callout server to indicate to the OPES processor the cacheability of callout responses. This implies that callout responses may have to carry cache-control instructions for the OPES processor.
また、OPESコールアウトプロトコルは、コールアウトサーバは、OPESプロセッサにコールアウト応答のキャッシュ可能性を示すために許容しなければなりません。これは、コールアウト応答がOPESプロセッサのキャッシュ制御命令を運ぶために持っている可能性を示唆しています。
The OPES callout protocol MUST further enable the OPES processor to indicate to the callout server if it has kept a local copy of the forwarded application message (or parts thereof). This information enables the callout server to determine whether the forwarded application message must be returned to the OPES processor, even if it has not been modified by an OPES service.
OPESコールアウトプロトコルはさらに、それが転送されたアプリケーションメッセージ（またはその一部）のローカルコピーを保持している場合、コールアウトサーバに示すために、OPESプロセッサを有効にする必要があります。この情報は、転送されたアプリケーション・メッセージは、それがOPESサービスによって変更されていない場合でも、OPESプロセッサに戻さなければならないかどうかを決定するためにコールアウトサーバーを可能にします。
The OPES callout protocol MUST also allow OPES processors to comply with the tracing requirements of the OPES architecture as laid out in [1] and [3]. This implies that the callout protocol MUST enable a callout server to convey to the OPES processor information about the OPES service operations performed on the forwarded application message.
OPESコールアウトプロトコルはまた、レイアウトとしてOPESプロセッサはOPESアーキテクチャのトレース要件に準拠することを可能にしなければならない[1]と[3]。これは、コールアウトプロトコルが転送されたアプリケーションメッセージに対して実行OPESサービス操作に関するOPESプロセッサ情報を伝達するためにコールアウトサーバを有効にしなければならないことを意味します。
The OPES callout protocol SHOULD have minimal latency. For example, the size and complexity of its headers could be minimized.
OPESコールアウトプロトコルは、最小限の待ち時間を有するべきです。例えば、そのヘッダーのサイズと複雑さを最小限に抑えることができました。
Because OPES callout transactions add latency to application protocol transactions on the data path, callout protocol efficiency is crucial to overall performance.
OPESコールアウトトランザクションがデータパスにアプリケーションプロトコルトランザクションに待ち時間を追加するため、コールアウトプロトコルの効率が全体的な性能に重要です。
In the absence of any security mechanisms, sensitive information might be communicated between the OPES processor and the callout server in violation of either endpoint's security and privacy policy, through misconfiguration or deliberate insider attack. By using strong authentication, message encryption, and integrity checks, this threat can be minimized to a smaller set of insiders and/or operator configuration errors.
任意のセキュリティメカニズムが存在しない場合には、機密情報が設定ミスや意図的なインサイダー攻撃を通じて、エンドポイントのセキュリティとプライバシーポリシーのいずれかに違反してOPESプロセッサとコールアウトサーバ間で通信されることがあります。強力な認証、メッセージの暗号化、および整合性チェックを使用することにより、この脅威は小さいインサイダーのセットおよび/またはオペレータの設定エラーを最小限に抑えることができます。
The OPES processor and the callout servers SHOULD have enforceable policies that limit the parties they communicate with and that determine the protections to use based on identities of the endpoints and other data (such as enduser policies). In order to enforce the policies, they MUST be able to authenticate the callout protocol endpoints using cryptographic methods.
OPESプロセッサとコールアウトサーバは、それらが通信し、そのエンドポイントのアイデンティティと（例えば、エンドユーザポリシーなど）他のデータに基づいて、使用する保護を決定する当事者を制限する強制力のポリシーを持っているべきです。ポリシーを適用するためには、彼らは暗号方式を使用して、コールアウトプロトコルのエンドポイントを認証できなければなりません。
The parties to the callout protocol MUST have a sound basis for binding authenticated identities to the protocol endpoints, and they MUST verify that these identities are consistent with their security policies.
コールアウトプロトコルの当事者は、プロトコルのエンドポイントに認証されたアイデンティティを結合するための健全な基盤を持っていなければならない、と彼らはこれらのIDは、そのセキュリティポリシーと一致していることを確かめなければなりません。
The OPES callout protocol MUST provide for message authentication, confidentiality, and integrity between the OPES processor and the callout server. It MUST provide mutual authentication. For this purpose, the callout protocol SHOULD use existing security mechanisms. The callout protocol specification is not required to specify the security mechanisms, but it MAY instead refer to a lower-level security protocol and discuss how its mechanisms are to be used with the callout protocol.
OPESコールアウトプロトコルはOPESプロセッサとコールアウト・サーバ間のメッセージ認証、機密性、および完全性を提供しなければなりません。これは、相互認証を提供しなければなりません。この目的のために、コールアウトプロトコルは、既存のセキュリティ・メカニズムを使用すべきです。コールアウトのプロトコル仕様は、セキュリティ・メカニズムを指定するために必要とされず、その代わりに低レベルのセキュリティプロトコルを参照し、そのメカニズムはコールアウトプロトコルで使用される方法について説明MAY。
If hop-by-hop encryption is a requirement for the content path, then this confidentiality MUST be extended to the communication between the OPES processor and the callout server. While it is recommended that the communication between the OPES processor and callout server always be encrypted, encryption MAY be optional if both the OPES processor and the callout server are co-located together in a single administrative domain with strong confidentiality guarantees.
ホップ・バイ・ホップの暗号化は、コンテンツ・パスのための要件である場合、この機密はOPESプロセッサとコールアウトサーバ間の通信に拡張されなければなりません。 OPESプロセッサとコールアウトサーバ間の通信は常に暗号化されることをお勧めしますがOPESプロセッサおよびコールアウト・サーバーの両方が強い機密性の保証を備えた単一の管理ドメインで一緒に同じ場所に配置されている場合、暗号化は任意です。
In order to minimize data exposure, the callout protocol MUST use a different encryption key for each encrypted content stream.
データの露出を最小限にするためには、コールアウト・プロトコルは、各暗号化されたコンテンツのストリームごとに異なる暗号鍵を使用しなければなりません。
The OPES callout protocol MUST operate securely across untrusted domains between the OPES processor and the callout server.
OPESコールアウトプロトコルはOPESプロセッサとコールアウトサーバとの間の信頼できないドメイン間で確実に動作しなければなりません。
If the communication channels between the OPES processor and callout server cross outside of the organization which is responsible for the OPES services, then endpoint authentication and message protection (confidentiality and integrity) MUST be used.
OPESサービスの原因である組織の外部OPESプロセッサとコールアウトサーバ相互間の通信チャネルは、その後、エンドポイント認証とメッセージ保護（機密性と完全性）を使用する必要がある場合。
Any communication carrying information relevant to privacy policies MUST protect the data using encryption.
プライバシーポリシーに関連する情報を運ぶ任意の通信は暗号化を使用してデータを保護する必要があります。
The security requirements for the OPES callout protocol are discussed in Section 5.
OPESコールアウトプロトコルのセキュリティ要件は、第5節で議論されています。
[1] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.
[1] Barbir、A.、Penno、R.、陳、R.、ホフマン、M.、およびH.オーマン、 "オープン・プラグイン可能なエッジサービスのためのアーキテクチャ（OPES）"、RFC 3835、2004年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[3]フロイド、S.とL. Daigle氏、 "オープン・プラグイン可能なエッジサービスのためのIAB建築・ポリシーに関する注意事項"、RFC 3238、2002年1月。
[4] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[4]フロイド、S.とL. Daigle氏、 "オープン・プラグイン可能なエッジサービスのためのIAB建築・ポリシーに関する注意事項"、RFC 3238、2002年1月。
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[5]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[6]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[7]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[8] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 3550、2003年7月。
Parts of this document are based on previous work by Anca Dracinschi Sailer, Volker Hilt, and Rama R. Menon.
このドキュメントの一部はANCA Dracinschiザイラー、フォルカー柄、そしてラマR.メノンによって前の仕事に基づいています。
The authors would like to thank the participants of the OPES WG for their comments on this document.
作者はこのドキュメントの彼らのコメントのためOPES WGの参加者に感謝したいと思います。
Andre Beck Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 US
アンドレ・ベックルーセント・テクノロジーズ101 Crawfordsコーナー道路ホルムデル、NJ 07733米国
EMail: abeck@bell-labs.com
メールアドレス：abeck@bell-labs.com
Markus Hofmann Lucent Technologies Room 4F-513 101 Crawfords Corner Road Holmdel, NJ 07733 US
マーカス・ホフマンルーセント・テクノロジーズルーム4F-513 101 Crawfordsコーナー道路ホルムデル、NJ 07733米国
Phone: +1 732 332 5983 EMail: hofmann@bell-labs.com
電話：+1 732 332 5983 Eメール：hofmann@bell-labs.com
Hilarie Orman Purple Streak Development
ヒラリーオーマンパープルストリーク開発
EMail: ho@alum.mit.edu URI: http://www.purplestreak.com
電子メール：ho@alum.mit.edu URI：http://www.purplestreak.com
Reinaldo Penno Nortel Networks 600 Technology Park Drive Billerica, MA 01821 US
レイナルドPenno Nortel Networksの600テクノロジーパークドライブビレリカ、MA 01821米国
EMail: rpenno@nortelnetworks.com
メールアドレス：rpenno@nortelnetworks.com
Andreas Terzis Computer Science Department Johns Hopkins University 3400 North Charles Street, 224 NEB Baltimore, MD 21218
アンドレアスTerzisコンピュータサイエンス学部ジョンズ・ホプキンス大学3400のノースチャールズストリート、224 NEBボルチモア、MD 21218
Phone: +1 410 516 5847 EMail: terzis@cs.jhu.edu
電話：+1 410 516 5847 Eメール：terzis@cs.jhu.edu
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。