RFC3836 日本語訳
3836 Requirements for Open Pluggable Edge Services (OPES) CalloutProtocols. A. Beck, M. Hofmann, H. Orman, R. Penno, A. Terzis. August 2004. (Format: TXT=28438 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループA.べックの要求をネットワークでつないでください: 3836年のM.ホフマンカテゴリ: 情報のルーセントテクノロジーズH.OrmanはA.Terzisジョーンズ・ホプキンス大学2004年8月に一続きの開発R.ペンノノーテルネットワークを紫色にします。
Requirements for Open Pluggable Edge Services (OPES)
Callout Protocols
開いているPluggable縁のサービス(作品)Calloutプロトコルのための要件
Status of this Memo
この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).
Copyright(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.
このドキュメントは作品(開いているPluggable Edge Services)calloutプロトコルにリモート作品サービスの実行をサポートするために満足させられなければならないという要件を指定します。 要件は、可能なプロトコル候補を評価するのを助けて、そのようなプロトコルの開発を誘導することを意図します。
Beck, et al. Informational [Page 1] RFC 3836 Requirements for OPES Callout Protocols August 2004
べック、他 作品Calloutプロトコル2004年8月のための情報[1ページ]のRFC3836要件
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
1. 用語. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 3. 機能条件書. . . . . . . . . . . . . . . . . . . 3 3.1。 信頼性. . . . . . . . . . . . . . . . . . . . . . 3 3.2。 輻輳回避. . . . . . . . . . . . . . . . . 3 3.3。 Calloutトランザクション. . . . . . . . . . . . . . . . . 3 3.4。 Calloutコネクションズ. . . . . . . . . . . . . . . . . . 4 3.5。 非同期な交換処理. . . . . . . . . . . . . 5 3.6。 メッセージ分割. . . . . . . . . . . . . . . . . 5 3.7。 生きている生活費には、メカニズム. . . . . . . . . . . 6 3.8をサポートしてください。 NAT環境. . . . . . . . . . . . . 6 3.9における操作。 複数のCalloutサーバ. . . . . . . . . . . . . . . 6 3.10 複数の作品プロセッサ. . . . . . . . . . . . . . . 6 3.11 異なったアプリケーションには、プロトコル. . . . . . 7 3.12をサポートしてください。 能力とパラメタ交渉. . . . . . . . . 7 3.13。 メタデータと指示. . . . . . . . . . . . . . 8 4。 パフォーマンス要件. . . . . . . . . . . . . . . . . . 9 4.1。 効率. . . . . . . . . . . . . . . . . . 9 5について議定書の中で述べてください。 セキュリティ要件. . . . . . . . . . . . . . . . . . . . 9 5.1。 認証、秘密性、および保全. . . . 9 5.2。 ホップごとの秘密性。 . . . . . . . . . . . . . . 10 5.3. 信頼されていないドメイン中の操作。 . . . . . . . . . . 10 5.4. プライバシー. . . . . . . . . . . . . . . . . . . . . . . . 10 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 10 7。 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. 引用規格。 . . . . . . . . . . . . . . . . . 10 7.2. 有益な参照。 . . . . . . . . . . . . . . . . 11 8. 承認. . . . . . . . . . . . . . . . . . . . . . . 11 9。 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . 12 10. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 13
1. Terminology
1. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。
2. Introduction
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.
オープンPluggable Edge Services(作品)アーキテクチャ[1]は情報提供業者と、データ消費者と、ゼロの間のアプリケーション・サービス(作品サービス)か、より多くの作品プロセッサを協力して可能にします。 考慮しているアプリケーション・サービスは、情報提供業者とデータ消費者の間で交換されたアプリケーションレベルメッセージを、分析して、ことによると変えます。
Beck, et al. Informational [Page 2] RFC 3836 Requirements for OPES Callout Protocols August 2004
べック、他 作品Calloutプロトコル2004年8月のための情報[2ページ]のRFC3836要件
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.
そのようなサービスの実行は作品プロセッサにインストールされた1セットの規則で治められます。 規則の実施は作品プロセッサへのローカルのサービスアプリケーションの実行の引き金となることができます。 あるいはまた、作品プロセッサは、1つ以上のリモートcalloutサーバを伝えて、協力することによって、サービス実行の責任を分配できます。 [1]で説明されるように、作品プロセッサは、calloutサーバにcalloutプロトコルを使用することによって、サービスを交信して、呼び出します。 このドキュメントはそのようなプロトコルのための要件を提示します。
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つ以上の声明として提示されます。
3. Functional Requirements
3. 機能条件書
3.1. Reliability
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.
作品calloutプロトコルは作品プロセッサとcalloutサーバとのコミュニケーションに命令された信頼性を提供できなければなりません。さらに、calloutはSHOULDについて議定書の中で述べます。順不同の信頼性を提供できてください。
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].
信頼度要求事項を満たすために、calloutプロトコルSHOULDは、トランスポート層、例えば、TCP[6]かSCTP[7]で命令されたか順不同の信頼性を提供するトランスポート・プロトコルと共にそれを使用しなければならないと指定します。
3.2. Congestion Avoidance
3.2. 輻輳回避
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].
作品calloutプロトコルは、RFC2914[4]の規格に合っている輻輳回避が作品プロセッサとcalloutサーバとのすべてのコミュニケーションで適用されるのを確実にしなければなりません。このために、calloutプロトコルSHOULDは混雑で制御されたトランスポート層プロトコル(おそらくTCP[6]かSCTP[7]のどちらか)を使用します。
3.3. Callout Transactions
3.3. Calloutトランザクション
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
作品calloutプロトコルは、作品プロセッサとcalloutサーバが部分的であるか完全なアプリケーションレベルプロトコルメッセージ(または、それの変更)を交換する目的でcalloutトランザクションを実行するのを可能にしなければなりません。 より明確に、calloutプロトコルは、1つ以上の作品サービスが転送されたアプリケーションメッセージ(または、それの部品)を処理できるように、作品プロセッサが部分的であるか完全なアプリケーションメッセージをcalloutサーバに転送するのを可能にしなければなりません。 サービス操作の結果は変更されたアプリケーションメッセージであるかもしれません。 したがって、calloutプロトコルはcalloutを有効にしなければなりません。
Beck, et al. Informational [Page 3] RFC 3836 Requirements for OPES Callout Protocols August 2004
べック、他 作品Calloutプロトコル2004年8月のための情報[3ページ]のRFC3836要件
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.
変更されたアプリケーションメッセージかアプリケーションメッセージの変更された部分を作品プロセッサに返すサーバ。 さらに、calloutプロトコルは、calloutサーバがcalloutトランザクション(例えば、ステータスコードの形の)の結果を作品プロセッサに報告して戻すのを可能にしなければなりません。
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.
calloutトランザクションは、callout要求とcallout応答から成りながら、作品プロセッサとcalloutサーバの間で交換処理と定義されます。 両方、callout要求、およびcallout応答は1つ以上のcalloutプロトコルメッセージ(すなわち一連のプロトコルメッセージ)からそれぞれ成るかもしれません。 callout要求はいつも部分的であるか完全なアプリケーションメッセージを含まなければなりません。 callout応答はいつもcalloutトランザクションの結果を示さなければなりません。 callout応答は変更されたアプリケーションメッセージを含むかもしれません。
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.
Calloutトランザクションは、作品プロセッサからのcallout要求でいつも開始されて、calloutサーバからのcallout応答で通常終えられます。しかしながら、また、作品calloutプロトコルは対応するcallout終点でcallout要求か応答を完全に受け取る前にcalloutトランザクションのどちらの終点がもcalloutトランザクションを終えることができるメカニズムを提供しなければなりません。 そのようなメカニズムは、calloutトランザクションの未完熟終了がアプリケーションメッセージデータの損失をもたらさないのを確実にしなければなりません。
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.
calloutトランザクションの未完熟終了が、作品がサービスであるとサポートするのに必要です。(全体のアプリケーションメッセージを処理する前にさえサービスは終わるかもしれません)。 ウェブオブジェクトの最初の数バイトを処理した後に、例えば、満足している分析サービスはウェブオブジェクトを分類できるかもしれません。
3.4. Callout Connections
3.4. Calloutコネクションズ
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).
作品calloutプロトコルは、作品プロセッサとcalloutサーバがcallout接続の上で複数のcalloutトランザクションを実行するのを可能にしなければなりません。 さらに、calloutプロトコルはcalloutトランザクションを関連づけるメソッドにcallout接続を提供しなければなりません。 callout接続は作品プロセッサとcalloutサーバの間の応用層で論理的な接続と定義されます。callout接続には、それに関連しているあるパラメタがあるかもしれません、例えば、接続終点のフェイルオーバーの振舞いを制御するパラメタ。 Calloutの接続特有のパラメタは作品プロセッサとcalloutサーバの間で交渉されるかもしれません(セクション3.12を見てください)。
Beck, et al. Informational [Page 4] RFC 3836 Requirements for OPES Callout Protocols August 2004
べック、他 作品Calloutプロトコル2004年8月のための情報[4ページ]のRFC3836要件
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.
多重送信されたcallout接続の中で公正を保証するフロー制御メカニズムが適用されているなら、作品calloutプロトコルは、単独のトランスポート層接続の上に複数のcallout接続を多重送信するのを選ぶかもしれません。
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.
作品プロセッサでCallout接続をいつも開始しなければなりません。 callout接続は接続のどちらの終点によっても閉店させられるかもしれません、そうするのがcallout接続に関連している継続しているcalloutトランザクションの通常操作に影響しなければ。
3.5. Asynchronous Message Exchange
3.5. 非同期な交換処理
The OPES callout protocol MUST support an asynchronous message exchange over callout connections.
作品calloutプロトコルはcallout接続の上で非同期な交換処理をサポートしなければなりません。
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.
作品プロセッサとcalloutサーバに非同期処理を許容するために、応答処理と要求発行を切り離すのは可能でなければなりません。 プロトコルは、したがって、複数の傑出しているcallout要求を許して、callout応答を関連させるメソッドにcallout要求を提供しなければなりません。
Additionally, the callout protocol MUST enable a callout server to respond to a callout request before it has received the entire request.
さらに、全体の要求を受け取る前にcalloutプロトコルは、calloutサーバがcallout要求に応じるのを可能にしなければなりません。
3.6. Message Segmentation
3.6. メッセージ分割
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.
作品calloutプロトコルで、作品プロセッサは一連のより小さいメッセージ断片のcalloutサーバにアプリケーションメッセージを転送できなければなりません。 calloutプロトコルは、受信calloutサーバが断片化しているアプリケーションメッセージを組み立て直すのをさらに可能にしなければなりません。
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.
同様に、calloutプロトコルは、calloutサーバが一連のより小さいメッセージ断片の作品プロセッサにアプリケーションメッセージを返すのを可能にしなければなりません。 calloutプロトコルは、受信作品プロセッサが断片化しているアプリケーションメッセージを組み立て直すのを可能にしなければなりません。
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
データ経路で使用される応用層プロトコルによって、アプリケーションメッセージはサイズ(例えば、オーディオ/ビデオストリームのケースにおける)か未知のサイズで非常に大きいかもしれません。 どちらの場合も、データ消費者のために長時間の遅延を避ける全体のアプリケーションメッセージを受け取る前に作品プロセッサはcalloutトランザクションを開始しなければなりません。 したがってプロセッサがアプリケーションメッセージの断片か塊をcalloutサーバに送ることができなければならない作品
Beck, et al. Informational [Page 5] RFC 3836 Requirements for OPES Callout Protocols August 2004
べック、他 作品Calloutプロトコル2004年8月のための情報[5ページ]のRFC3836要件
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.
それは情報提供業者か消費者からそれらを受けます。 同様に、作品プロセッサからそれらを受けるとき、calloutサーバは、アプリケーションメッセージ断片を処理して、返すことができなければなりません。
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).
また、作品calloutプロトコルが単独のトランスポート層接続の上に複数のcallout接続を多重送信するためにフロー制御メカニズムを提供するなら(セクション3.4を見てください)、アプリケーションメッセージ分割が必要です。
3.7. Support for Keep-Alive Mechanism
3.7. 生きている生活費メカニズムのサポート
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.
作品calloutプロトコルは使用されるならもう片方の終点の失敗を検出するためにcallout接続の両方の終点を許容する生きている生活費メカニズムを提供しなければなりません、calloutトランザクションがないときでさえ。 calloutプロトコルは、生きている生活費メッセージが作品プロセッサとcalloutサーバとの既存のcallout関係か別々の関係の上と交換されると指定するかもしれません。また、calloutプロトコルは、生きている生活費メカニズムの使用が任意であると指定するかもしれません。
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.
calloutサーバの故障の検出が、作品プロセッサが予備calloutサーバとのcallout関係を確立するのを可能にするかもしれないので、将来のcalloutトランザクションはアプリケーションメッセージデータの損失をもたらしません。 作品プロセッサの失敗の検出は、calloutサーバがそうでなければ他の作品プロセッサでcalloutトランザクションに利用可能でないリソースを発表するのを可能にするかもしれません。
3.8. Operation in NAT Environments
3.8. NAT環境における操作
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.
作品はSHOULDについて議定書の中で述べます。NATに優しいです、作品プロセッサとcalloutサーバの間の経路での1台以上のNATデバイスの存在がすなわち、操作に感染するべきでないということになってください。
3.9. Multiple Callout Servers
3.9. 複数のCalloutサーバ
The OPES callout protocol MUST allow an OPES processor to simultaneously communicate with more than one callout server.
作品calloutプロトコルで、作品プロセッサは同時に、1つ以上のcalloutサーバとコミュニケートできなければなりません。
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.
より大きいネットワークでは、作品サービスは異なったcalloutサーバによって接待されそうです。 したがって、作品プロセッサはおそらく複数のcalloutサーバとコミュニケートしなければならないでしょう。 プロトコルデザインは、作品プロセッサがそうするのを可能にしなければなりません。
3.10. Multiple OPES Processors
3.10. 複数の作品プロセッサ
The OPES callout protocol MUST allow a callout server to simultaneously communicate with more than one OPES processor.
作品calloutプロトコルで、calloutサーバは同時に、1台以上の作品プロセッサとコミュニケートできなければなりません。
Beck, et al. Informational [Page 6] RFC 3836 Requirements for OPES Callout Protocols August 2004
べック、他 作品Calloutプロトコル2004年8月のための情報[6ページ]のRFC3836要件
The protocol design MUST support a scenario in which multiple OPES processors use the services of a single callout server.
プロトコルデザインは複数の作品プロセッサがただ一つのcalloutサーバのサービスを利用するシナリオをサポートしなければなりません。
3.11. Support for Different Application Protocols
3.11. 異なったアプリケーション・プロトコルのサポート
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].
アプリケーションがプロトコル不可知論者であったなら、作品calloutはSHOULDについて議定書の中で述べて、すなわち、それは応用層プロトコルの特性に関するどんな仮定も情報提供業者とデータ消費者の間のデータ経路で使用した造ではなく、SHOULDです。 最小限では、calloutプロトコルは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.
データ経路の作品実体は異なったアプリケーション層のプロトコル、包含、他、HTTP[5]、およびRTP[8]を使用するかもしれません。 どんなそのような応用層プロトコルにも同じ作品calloutプロトコルを使用できるのは望ましいでしょう。
3.12. Capability and Parameter Negotiations
3.12. 能力とパラメタ交渉
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.
作品calloutプロトコルは作品プロセッサとcalloutサーバの間の能力とcallout接続パラメタの交渉をサポートしなければなりません。これは、作品プロセッサとcalloutサーバが彼らの能力と好みを交換できなければならないのを含意します。 その時、彼らは2つの終点が、将来のcallout接続/トランザクションか決断と共に使用されるべき能力とパラメタで彼らの能力が両立しないのに同意している状態で終わる決定論的な交渉プロセスに従事できなければなりません。
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.
しかし、それを交渉できた作品プロセッサとcalloutサーバが含む能力とパラメタ、(制限されない、)、: calloutプロトコルバージョン、フェイルオーバーの振舞い、生きている生活費メッセージの鼓動率、セキュリティ関連のパラメタなど
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]).
calloutプロトコルは、トランスポート・プロトコルがcallout接続に使用されることを決定するのに交渉を使用してはいけません。 例えば、HTTP[5]、RTP[8])はあるトランスポート・プロトコルを使用に要求します。しかしながら、calloutプロトコルが、あるアプリケーションメッセージが議定書を作ると指定するかもしれない、((例えば、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.
また、例えば、callout接続が1つ以上の特定の作品サービスに関連しているなら、Callout接続パラメタは作品calloutサービスの特性に関係するかもしれません。 例えば、作品のサービス特有のパラメタは、作品サービスが操作のためにアプリケーションメッセージのどの部分を必要とするかを指定するかもしれません。
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
Callout接続パラメタは、1calloutあたり1個の接続ベースに関して交渉しなければならなくて、どんなcalloutトランザクションの前にも対応するcallout接続の上で実行されます。 そして他のパラメタ。
Beck, et al. Informational [Page 7] RFC 3836 Requirements for OPES Callout Protocols August 2004
べック、他 作品Calloutプロトコル2004年8月のための情報[7ページ]のRFC3836要件
capabilities, such as the fail-over behavior, MAY be negotiated between the two endpoints independently of callout connections.
フェイルオーバーの振舞いなどの能力はcallout接続の如何にかかわらず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.
calloutプロトコルへのパーティーは、彼らの能力とパラメタのすべてかいくつかを交渉するのにcallout接続を使用するかもしれません。 あるいはまた、別々のコントロール接続はこのために使用されるかもしれません。
3.13. Meta Data and Instructions
3.13. メタデータと指示
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.
特定のcalloutトランザクションの終点が作品プロセッサかcalloutサーバのためにcallout要求と応答にメタデータと指示を含むように、作品calloutプロトコルはメカニズムを提供しなければなりません。
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.
明確に、calloutプロトコルは、作品プロセッサが、例えばcallout要求に転送されたアプリケーションメッセージの情報を含んでいるか、転送されたアプリケーションメッセージのタイプを指定するか、またはアプリケーションメッセージのどんな部分がcalloutサーバに送られるかを指定するのを可能にしなければなりません。同様に、calloutサーバは返されたアプリケーションメッセージの情報を含むことができなければなりません。
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.
作品プロセッサはさらに指定された順序で転送されたアプリケーションメッセージに実行されることである1つ以上の唯一指定された作品サービスの規則正しいリストを含むことができなければなりません。 しかしながら、また、calloutプロトコルが、特定の作品サービスとのcallout関係を関連づけるのを選ぶかもしれないので、1calloutあたり1個のトランザクションベースで作品サービスを特定する必要がないかもしれません。
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.
さらに、作品calloutプロトコルで、calloutサーバはcallout応答のcacheabilityを作品プロセッサに示すことができなければなりません。 callout応答はこれが作品プロセッサのためのキャッシュ制御指示を運ぶつもりでなければならないかもしれません。
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.
作品calloutプロトコルは、作品プロセッサが、それが転送されたアプリケーションメッセージ(または、それの部品)の地方の写しを取っておいたかどうかをcalloutサーバに示すのをさらに可能にしなければなりません。 この情報は、calloutサーバが、転送されたアプリケーションメッセージを作品プロセッサに返さなければならないかどうか決定するのを可能にします、それが作品サービスで変更されていなくても。
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.
また、作品calloutプロトコルで、作品プロセッサは[1]と[3]で広げられるように作品アーキテクチャの追跡要件に従うことができなければなりません。 これは、calloutプロトコルが、calloutサーバが作品戦務活動のプロセッサ情報を作品に伝えるのを転送されたアプリケーションメッセージに実行されていた状態で可能にしなければならないのを含意します。
Beck, et al. Informational [Page 8] RFC 3836 Requirements for OPES Callout Protocols August 2004
べック、他 作品Calloutプロトコル2004年8月のための情報[8ページ]のRFC3836要件
4. Performance Requirements
4. パフォーマンス要件
4.1. Protocol Efficiency
4.1. プロトコル効率
The OPES callout protocol SHOULD have minimal latency. For example, the size and complexity of its headers could be minimized.
作品calloutプロトコルSHOULDには、最小量の潜在があります。 例えば、ヘッダーのサイズと複雑さは最小にされるかもしれません。
Because OPES callout transactions add latency to application protocol transactions on the data path, callout protocol efficiency is crucial to overall performance.
作品calloutトランザクションがデータ経路でアプリケーション・プロトコルトランザクションへの潜在を加えるので、calloutプロトコル効率は総合的な性能に重要です。
5. Security Requirements
5. セキュリティ要件
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.
どんなセキュリティー対策がないとき、機密情報は作品プロセッサとcalloutサーバの間でどちらかの終点のセキュリティとプライバシーに関する方針を違反して伝えられるかもしれません、misconfigurationか慎重なインサイダー攻撃で。 強い認証、メッセージ暗号化、および保全チェックを使用することによって、インサイダー、そして/または、オペレータの、より小さい構成誤りにこの脅威を最小にすることができます。
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.
作品プロセッサとcalloutサーバSHOULDには、彼らがコミュニケートするパーティーを制限して、保護が終点のアイデンティティに基づいて他のデータ(enduser方針などの)を使用すると決心している実施できる方針があります。 方針を実施するために、彼らは暗号のメソッドを使用することでcalloutプロトコル終点を認証できなければなりません。
5.1. Authentication, Confidentiality, and Integrity
5.1. 認証、秘密性、および保全
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.
calloutプロトコルへのパーティーには、プロトコル終点への拘束力がある認証されたアイデンティティのための健全な基礎がなければなりません、そして、それらがこれらのアイデンティティがそれらの安全保障政策と一致していることを確かめなければなりません。
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.
作品calloutプロトコルは作品プロセッサとcalloutサーバの間の通報認証、秘密性、および保全に備えなければなりません。それは互いの認証を提供しなければなりません。 このために、calloutプロトコルSHOULDは既存のセキュリティー対策を使用します。calloutプロトコル仕様はセキュリティー対策を指定するのに必要ではありませんが、それは、代わりに低レベルセキュリティプロトコルを呼んで、calloutプロトコルと共に使用されるメカニズムがことである方法について議論するかもしれません。
Beck, et al. Informational [Page 9] RFC 3836 Requirements for OPES Callout Protocols August 2004
べック、他 作品Calloutプロトコル2004年8月のための情報[9ページ]のRFC3836要件
5.2. Hop-by-Hop Confidentiality
5.2. ホップごとの秘密性
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.
ホップごとの暗号化が満足している経路のための要件であるなら、作品プロセッサとcalloutサーバとのコミュニケーションにこの秘密性を拡張しなければなりません。作品プロセッサとcalloutサーバの両方がただ一つの管理ドメインに強い秘密性保証で一緒に共同位置しているなら、作品プロセッサとcalloutサーバとのコミュニケーションがいつも暗号化されるのが、お勧めである間、暗号化は任意であるかもしれません。
In order to minimize data exposure, the callout protocol MUST use a different encryption key for each encrypted content stream.
データ暴露を最小にするために、calloutプロトコルはそれぞれの暗号化された満足しているストリームに、主要な異なった暗号化を使用しなければなりません。
5.3. Operation Across Untrusted Domains
5.3. 信頼されていないドメイン中の操作
The OPES callout protocol MUST operate securely across untrusted domains between the OPES processor and the callout server.
作品calloutプロトコルは作品プロセッサとcalloutサーバの間の信頼されていないドメインの向こう側にしっかりと作動しなければなりません。
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.
作品プロセッサとcalloutサーバの間の通信チャネルが作品サービスに責任がある組織の外と交差しているなら、終点認証とメッセージ保護(秘密性と保全)を使用しなければなりません。
5.4. Privacy
5.4. プライバシー
Any communication carrying information relevant to privacy policies MUST protect the data using encryption.
暗号化を使用して、プライバシーに関する方針に関連している情報を運ぶどんなコミュニケーションもデータを保護しなければなりません。
6. Security Considerations
6. セキュリティ問題
The security requirements for the OPES callout protocol are discussed in Section 5.
セクション5で作品calloutプロトコルのためのセキュリティ要件について議論します。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[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.、ペンノ、R.、チェン、R.、ホフマン、M.、およびH.Orman、「開いているPluggable縁のサービスのためのアーキテクチャ(作品)」、RFC3835(2004年8月)。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[3] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、2002年1月。
Beck, et al. Informational [Page 10] RFC 3836 Requirements for OPES Callout Protocols August 2004
べック、他 作品Calloutプロトコル2004年8月のための情報[10ページ]のRFC3836要件
[4] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[4] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
7.2. Informative References
7.2. 有益な参照
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[6] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、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.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「ストリーム制御伝動プロトコル」、RFC2960(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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC3550、2003年7月。
8. Acknowledgments
8. 承認
Parts of this document are based on previous work by Anca Dracinschi Sailer, Volker Hilt, and Rama R. Menon.
アンカDracinschi Sailer、ボルカーHilt、およびラマ・R.メノンのこのドキュメントの部分は前の仕事に基づいています。
The authors would like to thank the participants of the OPES WG for their comments on this document.
作者はこのドキュメントの彼らのコメントについてOPES WGの関係者に感謝したがっています。
Beck, et al. Informational [Page 11] RFC 3836 Requirements for OPES Callout Protocols August 2004
べック、他 作品Calloutプロトコル2004年8月のための情報[11ページ]のRFC3836要件
9. Authors' Addresses
9. 作者のアドレス
Andre Beck Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 US
Crawfordsコーナー道路Holmdel、アンドレべックルーセントテクノロジーズ101ニュージャージー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
マーカスホフマンルーセントテクノロジーズ4余地のF-513 101Crawfordsコーナー道路Holmdel、ニュージャージー07733米国
Phone: +1 732 332 5983 EMail: hofmann@bell-labs.com
以下に電話をしてください。 +1 5983年の732 332メール: hofmann@bell-labs.com
Hilarie Orman Purple Streak Development
Hilarie Ormanの紫色の一続きの開発
EMail: ho@alum.mit.edu URI: http://www.purplestreak.com
メール: ho@alum.mit.edu ユリ: http://www.purplestreak.com
Reinaldo Penno Nortel Networks 600 Technology Park Drive Billerica, MA 01821 US
レイナルドペンノノーテルネットワーク600技術公園Drive MA01821ビルリカ(米国)
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 224NEBボルチモア、MD 21218
Phone: +1 410 516 5847 EMail: terzis@cs.jhu.edu
以下に電話をしてください。 +1 5847年の410 516メール: terzis@cs.jhu.edu
Beck, et al. Informational [Page 12] RFC 3836 Requirements for OPES Callout Protocols August 2004
べック、他 作品Calloutプロトコル2004年8月のための情報[12ページ]のRFC3836要件
10. Full Copyright Statement
10. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Beck, et al. Informational [Page 13]
べック、他 情報[13ページ]
一覧
スポンサーリンク
