RFC4037 日本語訳
4037 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core.A. Rousskov. March 2005. (Format: TXT=131487 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Rousskov Request for Comments: 4037 The Measurement Factory Category: Standards Track March 2005
Rousskovがコメントのために要求するワーキンググループA.をネットワークでつないでください: 4037 測定工場のカテゴリ: 2005年の標準化過程行進
Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core
開いているPluggable縁のサービス(作品)Calloutプロトコル(OCP)コア
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document specifies the core of the Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: An OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). As defined in this document, the OCP Core consists of application-agnostic mechanisms essential for efficient support of typical adaptations.
このドキュメントはオープンPluggable Edge Services(作品)Calloutプロトコル(OCP)のコアを指定します。 OCPは他の通信プロトコルからのアプリケーションメッセージを整理します: 作品仲介者は原出願メッセージをcalloutサーバに送ります。 calloutサーバは適合しているアプリケーションメッセージをプロセッサに送り返します。 OCPは典型的な適合タスクで念頭(例えば、ウイルスとスパム管理か言語と形式翻訳か、メッセージanonymizationか、広告操作)に設計されています。 本書では定義されるように、OCP Coreは典型的な適合の効率的なサポートに、不可欠のアプリケーション不可知論者メカニズムから成ります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. OPES Document Map . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 6
2. Overall Operation . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Initialization . . . . . . . . . . . . . . . . . . . . . 7
2.2. Original Dataflow . . . . . . . . . . . . . . . . . . . 8
2.3. Adapted Dataflow . . . . . . . . . . . . . . . . . . . . 8
2.4. Multiple Application Messages . . . . . . . . . . . . . 9
2.5. Termination . . . . . . . . . . . . . . . . . . . . . . 9
2.6. Message Exchange Patterns . . . . . . . . . . . . . . . 9
2.7. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 10
2.8. Environment . . . . . . . . . . . . . . . . . . . . . . 11
3. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 範囲. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2。 作品は地図. . . . . . . . . . . . . . . . . . . 5 1.3を記録します。 用語. . . . . . . . . . . . . . . . . . . . . . 6 2。 総合的な操作. . . . . . . . . . . . . . . . . . . . . . 7 2.1。 初期設定. . . . . . . . . . . . . . . . . . . . . 7 2.2。 オリジナルのデータフロー. . . . . . . . . . . . . . . . . . . 8 2.3。 適合しているデータフロー. . . . . . . . . . . . . . . . . . . . 8 2.4。 複数のアプリケーションメッセージ. . . . . . . . . . . . . 9 2.5 終了. . . . . . . . . . . . . . . . . . . . . . 9 2.6。 交換処理パターン. . . . . . . . . . . . . . . 9 2.7。 タイムアウト. . . . . . . . . . . . . . . . . . . . . . . . 10 2.8。 環境. . . . . . . . . . . . . . . . . . . . . . 11 3。 メッセージ. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Rousskov Standards Track [Page 1] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[1ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 12
3.2. Message Rendering . . . . . . . . . . . . . . . . . . . 13
3.3. Message Examples . . . . . . . . . . . . . . . . . . . . 14
3.4. Message Names . . . . . . . . . . . . . . . . . . . . . 15
4. Transactions . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Invalid Input . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Negotiation Phase . . . . . . . . . . . . . . . . . . . 17
6.2. Negotiation Examples . . . . . . . . . . . . . . . . . . 18
7. 'Data Preservation' Optimization . . . . . . . . . . . . . . . 20
8. 'Premature Dataflow Termination' Optimizations . . . . . . . . 21
8.1. Original Dataflow . . . . . . . . . . . . . . . . . . . 22
8.2. Adapted Dataflow . . . . . . . . . . . . . . . . . . . . 23
8.3. Getting Out of the Loop . . . . . . . . . . . . . . . . 24
9. Protocol Element Type Declaration Mnemonic (PETDM) . . . . . . 25
9.1 Optional Parameters . . . . . . . . . . . . . . . . . 27
10. Message Parameter Types . . . . . . . . . . . . . . . . . . . 28
10.1. uri. . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.2. uni. . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.3. size . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.4. offset . . . . . . . . . . . . . . . . . . . . . . . . 29
10.5. percent . . . . . . . . . . . . . . . . . . . . . . . 29
10.6. boolean. . . . . . . . . . . . . . . . . . . . . . . . 30
10.7. xid . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.8. sg-id. . . . . . . . . . . . . . . . . . . . . . . . . 30
10.9. modp. . . . . . . . . . . . . . . . . . . . . . . . . 30
10.10. result. . . . . . . . . . . . . . . . . . . . . . . . 30
10.11. feature . . . . . . . . . . . . . . . . . . . . . . . 32
10.12. features. . . . . . . . . . . . . . . . . . . . . . . 32
10.13. service . . . . . . . . . . . . . . . . . . . . . . . 32
10.14. services. . . . . . . . . . . . . . . . . . . . . . . 33
10.15. Dataflow Specializations. . . . . . . . . . . . . . . 33
11. Message Definitions . . . . . . . . . . . . . . . . . . . . . 33
11.1. Connection Start (CS) . . . . . . . . . . . . . . . . 34
11.2. Connection End (CE) . . . . . . . . . . . . . . . . . 35
11.3. Service Group Created (SGC) . . . . . . . . . . . . . 35
11.4. Service Group Destroyed (SGD) . . . . . . . . . . . . 36
11.5. Transaction Start (TS). . . . . . . . . . . . . . . . 36
11.6. Transaction End (TE). . . . . . . . . . . . . . . . . 36
11.7. Application Message Start (AMS) . . . . . . . . . . . 37
11.8. Application Message End (AME) . . . . . . . . . . . . 37
11.9. Data Use Mine (DUM) . . . . . . . . . . . . . . . . . 38
11.10. Data Use Yours (DUY). . . . . . . . . . . . . . . . . 39
11.11. Data Preservation Interest (DPI). . . . . . . . . . . 39
11.12. Want Stop Receiving Data (DWSR) . . . . . . . . . . . 40
11.13. Want Stop Sending Data (DWSS) . . . . . . . . . . . . 41
11.14. Stop Sending Data (DSS) . . . . . . . . . . . . . . . 41
11.15. Want Data Paused (DWP). . . . . . . . . . . . . . . . 42
3.1. メッセージ・フォーマット. . . . . . . . . . . . . . . . . . . . . 12 3.2。 メッセージレンダリング. . . . . . . . . . . . . . . . . . . 13 3.3。 メッセージの例. . . . . . . . . . . . . . . . . . . . 14 3.4。 メッセージ名. . . . . . . . . . . . . . . . . . . . . 15 4。 トランザクション. . . . . . . . . . . . . . . . . . . . . . . . . 15 5。 無効の入力. . . . . . . . . . . . . . . . . . . . . . . . 16 6。 交渉. . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1。 交渉フェーズ. . . . . . . . . . . . . . . . . . . 17 6.2。 交渉の例. . . . . . . . . . . . . . . . . . 18 7。 'データ保存'最適化. . . . . . . . . . . . . . . 20 8。 '時期尚早なデータフロー終了'最適化. . . . . . . . 21 8.1。 オリジナルのデータフロー. . . . . . . . . . . . . . . . . . . 22 8.2。 適合しているデータフロー. . . . . . . . . . . . . . . . . . . . 23 8.3。 輪. . . . . . . . . . . . . . . . 24 9から、出ます。 .259.1の要素型宣言ニーモニック(PETDM)の任意のパラメタ. . . . . . . . . . . . . . . . . 27 10について議定書の中で述べてください。 メッセージParameter Types.28 10.1uri。 . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.2. uni。 . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.3. サイズ. . . . . . . . . . . . . . . . . . . . . . . . . 29 10.4は.29 10.5パーセントの.29 10.6論理演算子を相殺しました。 . . . . . . . . . . . . . . . . . . . . . . . 30 10.7. xid.30 10.8sg-イド。 . . . . . . . . . . . . . . . . . . . . . . . . 30 10.9. modp。 . . . . . . . . . . . . . . . . . . . . . . . . 30 10.10. なってください。 . . . . . . . . . . . . . . . . . . . . . . . 30 10.11. .32 10.12の特徴を特徴としてください。 . . . . . . . . . . . . . . . . . . . . . . 32 10.13. .32 10.14のサービスを修理してください。 . . . . . . . . . . . . . . . . . . . . . . 33 10.15. データフロー専門化。 . . . . . . . . . . . . . . 33 11. メッセージ定義. . . . . . . . . . . . . . . . . . . . . 33 11.1。 接続スタート(Cs。). . . . . . . . . . . . . . . . 34 11.2 接続終わりの(Ce。). . . . . . . . . . . . . . . . . 35 11.3 サービスグループは(SGC). . . . . . . . . . . . . 35 11.4を作成しました。 サービスグループは(SGD). . . . . . . . . . . . 36 11.5を破壊しました。 トランザクションスタート(ts)。 . . . . . . . . . . . . . . . 36 11.6. トランザクション終わり(Te)。 . . . . . . . . . . . . . . . . 36 11.7. アプリケーションメッセージスタート(AMS。). . . . . . . . . . . 37 11.8 アプリケーションメッセージ終わりの(AME。). . . . . . . . . . . . 37 11.9 データは.38 11.10に、私のもの(DUM)を使用します。 データはあなたのもの(DUY)を使用します。 . . . . . . . . . . . . . . . . 39 11.11. データ保存関心(dpi)。 . . . . . . . . . . 39 11.12. 停止にデータ(DWSR).40 11.13に受けて欲しいです。 停止にデータ(DWSS). . . . . . . . . . . . 41 11.14を送って欲しいです。 (DSS). . . . . . . . . . . . . . . 41 11.15をデータに送るのを止めてください。 欠乏、データは(DWP)をポーズしました。 . . . . . . . . . . . . . . . 42
Rousskov Standards Track [Page 2] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[2ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
11.16. Paused My Data (DPM). . . . . . . . . . . . . . . . . 43
11.17. Want More Data (DWM). . . . . . . . . . . . . . . . . 43
11.18. Negotiation Offer (NO). . . . . . . . . . . . . . . . 44
11.19. Negotiation Response (NR) . . . . . . . . . . . . . . 45
11.20. Ability Query (AQ). . . . . . . . . . . . . . . . . . 46
11.21. Ability Answer (AA) . . . . . . . . . . . . . . . . . 46
11.22. Progress Query (PQ) . . . . . . . . . . . . . . . . . 47
11.23. Progress Answer (PA). . . . . . . . . . . . . . . . . 47
11.24. Progress Report (PR). . . . . . . . . . . . . . . . . 48
12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 48
13. Security Considerations . . . . . . . . . . . . . . . . . . . 48
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
15. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 50
15.1. Extending OCP Core . . . . . . . . . . . . . . . . . . 51
A. Message Summary . . . . . . . . . . . . . . . . . . . . . . . 52
B. State Summary . . . . . . . . . . . . . . . . . . . . . . . 53
C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
16.1. Normative References . . . . . . . . . . . . . . . . . 54
16.2. Informative References . . . . . . . . . . . . . . . . 54
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 55
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 56
11.16. 私のデータ(DPM)をポーズしました。 . . . . . . . . . . . . . . . . 43 11.17. 欠乏、 より多くのデータ(DWM)。 . . . . . . . . . . . . . . . . 43 11.18. 交渉申し出(いいえ)。 . . . . . . . . . . . . . . . 44 11.19. 交渉応答(NR。). . . . . . . . . . . . . . 45 11.20 能力質問(AQ)。 . . . . . . . . . . . . . . . . . 46 11.21. 能力答え(AA。). . . . . . . . . . . . . . . . . 46 11.22 質問(PQ). . . . . . . . . . . . . . . . . 47 11.23を進行してください。 答え(PA)を進行してください。 . . . . . . . . . . . . . . . . 47 11.24. 経過報告書(PR)。 . . . . . . . . . . . . . . . . 48 12. IAB問題. . . . . . . . . . . . . . . . . . . . . 48 13。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 48 14。 IANA問題. . . . . . . . . . . . . . . . . . . . . 50 15。 承諾. . . . . . . . . . . . . . . . . . . . . . . . . 50 15.1。 OCPコア. . . . . . . . . . . . . . . . . . 51A.メッセージ概要. . . . . . . . . . . . . . . . . . . . . . . 52B.州の概要. . . . . . . . . . . . . . . . . . . . . . . 53C.承認. . . . . . . . . . . . . . . . . . . . . . 54 16を広げています。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 54 16.1。 引用規格. . . . . . . . . . . . . . . . . 54 16.2。 有益な参照. . . . . . . . . . . . . . . . 54作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . . . 55 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . 56
1. Introduction
1. 序論
The Open Pluggable Edge Services (OPES) architecture [RFC3835] 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(作品)アーキテクチャ[RFC3835]は情報提供業者と、データ消費者と、ゼロの間のアプリケーション・サービス(作品サービス)か、より多くの作品プロセッサを協力して可能にします。 考慮しているアプリケーション・サービスは、情報提供業者とデータ消費者の間で交換されたアプリケーションレベルメッセージを、分析して、ことによると変えます。
The OPES processor can delegate the responsibility of service
execution by communicating with callout servers. As described in
[RFC3836], an OPES processor invokes and communicates with services
on a callout server by using an OPES callout protocol (OCP). This
document specifies the core of that protocol ("OCP Core").
作品プロセッサは、calloutサーバとコミュニケートすることによって、サービス実行の責任を代表として派遣することができます。 [RFC3836]で説明されるように、作品プロセッサは、calloutサーバでサービスで作品calloutプロトコル(OCP)を使用することによって、呼び出して、交信します。 このドキュメントはそのプロトコル(「OCPコア」)のコアを指定します。
The OCP Core specification documents general application-independent protocol mechanisms. A separate series of documents describes application-specific aspects of OCP. For example, "HTTP Adaptation with OPES" [OPES-HTTP] describes, in part, how HTTP messages and HTTP meta-information can be communicated over OCP.
OCP Core仕様は一般的なアプリケーションから独立しているプロトコルメカニズムを記録します。ドキュメントの別々のシリーズはOCPのアプリケーション特有の局面について説明します。 例えば、「作品とのHTTP適合」[作品HTTP]はOCPの上でどうHTTPメッセージとHTTPメタ情報を伝えることができるかを一部説明します。
Section 1.2 provides a brief overview of the entire OPES document collection, including documents describing OPES use cases and security threats.
全体の作品ドキュメント収集の簡潔な概要はセクション1.2は提供されて、作品について説明するドキュメントを含んでいると、ケースと軍事的脅威は使用されます。
Rousskov Standards Track [Page 3] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[3ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
1.1. Scope
1.1. 範囲
The OCP Core specification documents the behavior of OCP agents and the requirements for OCP extensions. OCP Core does not contain requirements or mechanisms specific for application protocols being adapted.
OCP Core仕様はOCPエージェントの振舞いとOCP拡張子のための要件を記録します。 OCP Coreは適合させられるアプリケーション・プロトコルに、特定の要件かメカニズムを含んでいません。
As an application proxy, the OPES processor proxies a single application protocol or converts from one application protocol to another. At the same time, OPES processor may be an OCP client, using OCP to facilitate adaptation of proxied messages at callout servers. It is therefore natural to assume that an OPES processor takes application messages being proxied, marshals them over OCP to callout servers, and then puts the adaptation results back on the wire. However, this assumption implies that OCP is applied directly to application messages that OPES processor is proxying, which may not be the case.
アプリケーションプロキシ、1つのアプリケーションからのただ一つのアプリケーション・プロトコルか転向者が別のものに議定書の中で述べる作品プロセッサプロキシとして。 同時に、作品プロセッサはOCPクライアントであるかもしれません、calloutサーバでproxiedメッセージの適合を容易にするのにOCPを使用して。 したがって、作品プロセッサがproxiedされるアプリケーション伝言を受け取て、OCPの上でcalloutサーバにそれらを整理して、次に、適合結果をワイヤに戻すと仮定するのは当然です。 しかしながら、この仮定は、OCPが直接作品プロセッサ(ケースでないかもしれない)にproxyingされているというアプリケーションメッセージに適用されるのを含意します。
OPES processor scope callout server scope
+-----------------+ +-----------------+
| pre-processing | OCP scope | |
| +- - - - - - - - - - - - - - - - - - -+ |
| iteration | <== ( application data ) ==> | adaptation |
| +- - - - - - - - - - - - - - - - - - -+ |
| post-processing | | |
+-----------------+ +-----------------+
作品プロセッサ範囲のcalloutサーバ範囲+-----------------+ +-----------------+ | 前処理| OCP範囲| | | +- - - - - - - - - - - - - - - - - - -+ | | 繰り返し| <= (アプリケーションデータ) ==>| 適合| | +- - - - - - - - - - - - - - - - - - -+ | | 後工程| | | +-----------------+ +-----------------+
An OPES processor may preprocess (or postprocess) proxied application messages before (or after) they are adapted at callout servers. For example, a processor may take an HTTP response being proxied and pass it as-is, along with metadata about the corresponding HTTP connection. Another processor may take an HTTP response, extract its body, and pass that body along with the content-encoding metadata. Moreover, to perform adaptation, the OPES processor may execute several callout services, iterating over several callout servers. Such preprocessing, postprocessing, and iterations make it impossible to rely on any specific relationship between application messages being proxied and application messages being sent to a callout service. Similarly, specific adaptation actions at the callout server are outside OCP Core scope.
作品プロセッサが前処理するかもしれない、(後処理、)、それらが適合させられる(or after)の前のproxiedアプリケーションメッセージはサーバをcalloutします。 例えば、プロセッサは、proxiedされるHTTP応答を取って、そのままでそれを通過するかもしれません、対応するHTTP接続に関するメタデータと共に。 別のプロセッサは、内容をコード化するメタデータと共に、HTTP応答を取って、ボディーを抽出して、そのボディーを通過するかもしれません。 そのうえ、適合を実行するために、作品プロセッサはいくつかのcalloutサービス、いくつかのcalloutサーバの上の繰り返しを実行するかもしれません。 そのような前処理、後処理、および繰り返しで、proxiedされるアプリケーションメッセージとcalloutサービスに送られるアプリケーションメッセージとのどんな特定の関係も当てにするのは不可能になります。 同様に、OCP Core範囲の外にcalloutサーバにおける特定の適合動作があります。
This specification does not define or require any specific relationship among application messages being proxied by an OPES processor and application messages being exchanged between an OPES processor and a callout server via OCP. The OPES processor usually provides some mapping among these application messages, but the processor's specific actions are beyond OCP scope. In other words, this specification is not concerned with the OPES processor role as
この仕様は、OCPを通して作品プロセッサとcalloutサーバの間で交換しながら、作品プロセッサによってproxiedされるアプリケーションメッセージとアプリケーションメッセージの中で少しの特定の関係も定義もしませんし、必要ともしません。 作品プロセッサは通常これらのアプリケーションメッセージに何らかのマッピングを提供しますが、プロセッサの特定の動作はOCP範囲を超えています。 言い換えれば、この仕様は作品プロセッサの役割に関係がありません。
Rousskov Standards Track [Page 4] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[4ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
an application proxy or as an iterator of callout services. The scope of OCP Core is communication between a single OPES processor and a single callout server.
アプリケーションプロキシかcalloutサービスの繰返し子として。 OCP Coreの範囲は単一の作品プロセッサとただ一つのcalloutサーバとのコミュニケーションです。
Furthermore, an OPES processor may choose which proxied application messages or information about them to send over OCP. All proxied messages on all proxied connections (if connections are defined for a given application protocol), everything on some connections, selected proxied messages, or nothing might be sent over OCP to callout servers. OPES processor and callout server state related to proxied protocols can be relayed over OCP as application message metadata.
その上、作品プロセッサは、どれがOCPを移動するためにそれらのアプリケーションメッセージか情報をproxiedしたかを選ぶかもしれません。 proxied接続(接続が与えられたアプリケーション・プロトコルのために定義されるなら)(何人かの接続でのすべて)が選択したすべてに関するすべてのproxiedメッセージはメッセージをproxiedしなかったかもしれませんか、calloutサーバへのOCPの上に何も送らないかもしれません。 アプリケーションメッセージメタデータとしてOCPの上でproxiedプロトコルに関連する作品プロセッサとcalloutサーバ状態はリレーできます。
1.2. OPES Document Map
1.2. 作品ドキュメント地図
This document belongs to a large set of OPES specifications produced by the IETF OPES Working Group. Familiarity with the overall OPES approach and typical scenarios is often essential when one tries to comprehend isolated OPES documents. This section provides an index of OPES documents to assist the reader with finding "missing" information.
このドキュメントはIETF OPES作業部会によって作り出された大きい作品仕様に属します。 理解する1つのトライが作品ドキュメントを隔離したとき、総合的な作品アプローチと典型的なシナリオへの親しみはしばしば不可欠です。 このセクションは、「なくなった」情報を見つけるのに読者を補助するために作品ドキュメントのインデックスを提供します。
o "OPES Use Cases and Deployment Scenarios" [RFC3752] describes a
set of services and applications that are considered in scope for
OPES and that have been used as a motivation and guidance in
designing the OPES architecture.
o 「作品Use CasesとDeployment Scenarios」[RFC3752]は作品アーキテクチャを設計する際に作品のために範囲で考えられて、動機と指導として利用された1セットのサービスとアプリケーションについて説明します。
o The OPES architecture and common terminology are described in "An
Architecture for Open Pluggable Edge Services (OPES)" [RFC3835].
o 「開いているPluggable縁のサービス(作品)のためのアーキテクチャ」[RFC3835]で作品アーキテクチャと一般的な用語は説明されます。
o "Policy, Authorization, and Enforcement Requirements of OPES"
[RFC3838] outlines requirements and assumptions on the policy
framework, without specifying concrete authorization and
enforcement methods.
o 「作品の方針、Authorization、およびEnforcement Requirements」[RFC3838]は方針フレームワークに要件と仮定について概説します、具体的な承認と実施メソッドを指定しないで。
o "Security Threats and Risks for OPES" [RFC3837] provides OPES risk
analysis, without recommending specific solutions.
o 特定のソリューションを推薦しないで、「作品のためのセキュリティThreatsとRisks」[RFC3837]は作品危険分析を提供します。
o "OPES Treatment of IAB Considerations" [RFC3914] addresses all
architecture-level considerations expressed by the IETF Internet
Architecture Board (IAB) when the OPES WG was chartered.
o 「IAB Considerationsの作品Treatment」[RFC3914]はOPES WGがチャーターされたときIETFインターネット・アーキテクチャ委員会(IAB)によって言い表されたすべてのアーキテクチャレベル問題を扱います。
o At the core of the OPES architecture are the OPES processor and
the callout server, two network elements that communicate with
each other via an OPES Callout Protocol (OCP). The requirements
for this protocol are discussed in "Requirements for OPES Callout
Protocols" [RFC3836].
o 作品アーキテクチャのコアに、作品プロセッサとcalloutサーバがあります、作品Calloutプロトコル(OCP)で互いにコミュニケートする2つのネットワーク要素。 「作品Calloutプロトコルのための要件」[RFC3836]でこのプロトコルのための要件について議論します。
Rousskov Standards Track [Page 5] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[5ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
o This document specifies an application agnostic protocol core to
be used for the communication between an OPES processor and a
callout server.
o このドキュメントは、作品プロセッサとcalloutサーバとのコミュニケーションに使用されるためにアプリケーション不可知論者プロトコルコアを指定します。
o "OPES Entities and End Points Communications" [RFC3897] specifies
generic tracing and bypass mechanisms for OPES.
o 「作品EntitiesとEnd Points Communications」[RFC3897]はジェネリックのたどるのと迂回メカニズムを作品に指定します。
o The OCP Core and communications documents are independent from the
application protocol being adapted by OPES entities. Their
generic mechanisms have to be complemented by application-specific
profiles. "HTTP Adaptation with OPES" [OPES-HTTP] is such an
application profile for HTTP. It specifies how
application-agnostic OPES mechanisms are to be used and augmented
in order to support adaptation of HTTP messages.
o OCP Coreとコミュニケーションドキュメントは作品実体によって適合させられるアプリケーション・プロトコルから独立しています。 それらのジェネリックメカニズムはアプリケーション特有のプロフィールで補足とならなければなりません。 「作品があるHTTP Adaptation」[作品HTTP]はHTTPのためのそのようなアプリケーションプロフィールです。 それは、アプリケーション不可知論者作品メカニズムがHTTPメッセージの適合をサポートするためにどのように使用されて、増大するかことであると指定します。
o Finally, "P: Message Processing Language" [OPES-RULES] defines a
language for specifying what OPES adaptations (e.g., translation)
must be applied to what application messages (e.g., e-mail from
bob@example.com). P language is intended for configuring
application proxies (OPES processors).
o 最終的である、「P:」 「メッセージProcessing Language」[作品-RULES]は、どんな作品適合(例えば、翻訳)をどんなアプリケーションメッセージに適用しなければならないかを指定するために言語を定義します(例えば、 bob@example.com から、メールしてください)。 P言語は、アプリケーションプロキシ(作品プロセッサ)を構成するために意図します。
1.3. Terminology
1.3. 用語
In this document, the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase constitute normal prose usage, with no normative implications.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか? 標準の意味と共に使用されると、これらのキーワードはすべて大文字するようになるでしょう。 コネが小文字で印刷するこれらの単語の発生は標準の含意なしで正常な散文用法を構成します。
The OPES processor works with messages from application protocols and may relay information about those application messages to a callout server. OCP is also an application protocol. Thus, protocol elements such as "message", "connection", or "transaction" exist in OCP and other application protocols. In this specification, all references to elements from application protocols other than OCP are used with an explicit "application" qualifier. References without the "application" qualifier refer to OCP elements.
作品プロセッサは、アプリケーション・プロトコルからのメッセージで取り組んで、それらのアプリケーションメッセージの情報をcalloutサーバにリレーするかもしれません。また、OCPはアプリケーション・プロトコルです。 したがって、「メッセージ」、「接続」、または「トランザクション」などのプロトコル要素はOCPと他のアプリケーション・プロトコルで存在しています。 この仕様では、OCP以外のアプリケーション・プロトコルからの要素のすべての参照が明白な「アプリケーション」資格を与える人と共に使用されます。 「アプリケーション」資格を与える人のいない参照はOCP要素を示します。
OCP message: A basic unit of communication between an OPES processor
and a callout server. The message is a sequence of octets
formatted according to syntax rules (section 3.1). Message
semantics is defined in section 11.
OCPメッセージ: a calloutサーバ作品プロセッサとメッセージとのコミュニケーションの原単位はシンタックス・ルール(セクション3.1)によると、フォーマットされた八重奏の系列です。 メッセージ意味論はセクション11で定義されます。
application message: An entity defined by OPES processor and callout
server negotiation. Usually, the negotiated definition would
match the definition from an application protocol (e.g., [RFC2616]
definition of an HTTP message).
アプリケーションメッセージ: 作品プロセッサとcalloutサーバ交渉で定義された実体。 通常、交渉された定義はアプリケーション・プロトコル(例えば、HTTPメッセージの[RFC2616]定義)から定義に合っているでしょう。
Rousskov Standards Track [Page 6] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[6ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
application message data: An opaque sequence of octets representing a
complete or partial application message. OCP Core does not
distinguish application message structures (if there are any).
Application message data may be empty.
アプリケーションメッセージデータ: 完全であるか部分的なアプリケーションメッセージを表す八重奏の不明瞭な系列。 OCP Coreはアプリケーションメッセージ構造を区別しません(いずれかあれば)。 アプリケーションメッセージデータは空であるかもしれません。
data: Same as application message data.
データ: アプリケーションメッセージデータと同じです。
original: Referring to an application message flowing from the OPES
processor to a callout server.
オリジナル: 作品プロセッサからcalloutサーバまで流れるアプリケーションメッセージを示します。
adapted: Referring to an application message flowing from an OPES
callout server to the OPES processor.
適合する: 作品calloutサーバから作品プロセッサまで流れるアプリケーションメッセージを示します。
adaptation: Any kind of access by a callout server, including
modification, generation, and copying. For example, translating
or logging an SMTP message is adaptation of that application
message.
適合: 変更、世代、およびコピーを含むcalloutサーバによるどんな種類のアクセス。 例えば、SMTPメッセージを翻訳するか、または登録するのが、そのアプリケーションメッセージの適合です。
agent: The actor for a given communication protocol. The OPES
processor and callout server are OCP agents. An agent can be
referred to as a sender or receiver, depending on its actions in a
particular context.
エージェント: 与えられた通信プロトコルのための俳優。 作品プロセッサとcalloutサーバはOCPエージェントです。 特定の文脈における動作によって、送付者か受信機とエージェントを呼ぶことができます。
immediate: Performing the specified action before reacting to new
incoming messages or sending any new messages unrelated to the
specified action.
即座: 新しい入力メッセージに反応する前に、指定された動作を実行するか、または指定された動作に関係ないどんな新しいメッセージも送ります。
OCP extension: A specification extending or adjusting this document
for adaptation of an application protocol (a.k.a., application
profile; e.g., [OPES-HTTP]), new OCP functionality (e.g.,
transport encryption and authentication), and/or new OCP Core
version.
OCP拡張子: アプリケーション・プロトコル(通称アプリケーションプロフィール; 例えば、[作品HTTP])、新しいOCPの機能性(例えば、輸送暗号化と認証)、そして/または、新しいOCP Coreバージョンの適合のためのこのドキュメントを広げているか、または調整する仕様。
2. Overall Operation
2. 総合的な操作
The OPES processor may use the OPES callout protocol (OCP) to communicate with callout servers. Adaptation using callout services is sometimes called "bump in the wire" architecture.
作品プロセッサは、calloutサーバとコミュニケートするのに、作品calloutプロトコル(OCP)を使用するかもしれません。 calloutサービスを利用する適合は時々「ワイヤでの隆起」アーキテクチャと呼ばれます。
2.1. Initialization
2.1. 初期設定
The OPES processor establishes transport connections with callout servers to exchange application messages with the callout server(s) by using OCP. After a transport-layer connection (usually TCP/IP) is established, communicating OCP agents exchange Connection Start (CS) messages. Next, OCP features can be negotiated between the processor and the callout server (see section 6). For example, OCP agents may negotiate transport encryption and application message definition.
作品プロセッサは、OCPを使用することによってcalloutサーバとアプリケーションメッセージを交換するためにcalloutサーバとの輸送の接続を確立します。 トランスポート層接続(通常TCP/IP)が確立された後に、交信しているOCPエージェントはConnection Start(CS)メッセージを交換します。 次に、プロセッサとcalloutサーバの間でOCPの特徴を交渉できます(セクション6を見てください)。 例えば、OCPエージェントは輸送暗号化とアプリケーションメッセージ定義を交渉するかもしれません。
Rousskov Standards Track [Page 7] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[7ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
When enough settings are negotiated, OCP agents may start exchanging application messages.
十分な設定が交渉されるとき、OCPエージェントは、アプリケーションメッセージを交換し始めるかもしれません。
OCP Core provides negotiation and other mechanisms for agents to encrypt OCP connections and authenticate each other. OCP Core does not require OCP connection encryption or agent authentication. Application profiles and other OCP extensions may document and/or require these and other security mechanisms. OCP is expected to be used, in part, in closed environments where trust and privacy are established by means external to OCP. Implementations are expected to demand necessary security features via the OCP Core negotiation mechanism, depending on agent configuration and environment.
エージェントがOCP接続を暗号化して、互いを認証するように、OCP Coreは交渉と他のメカニズムを提供します。 OCP CoreはOCP接続暗号化かエージェント認証を必要としません。 アプリケーションプロフィールと他のOCP拡張子は、これらと他のセキュリティー対策を記録する、そして/または、必要とするかもしれません。信頼とプライバシーがOCPへの外部の手段で確立される閉じている環境でOCPが一部使用されると予想されます。 エージェント構成と環境によって、実装がOCP Core交渉メカニズムで必要なセキュリティ機能を要求すると予想されます。
2.2. Original Dataflow
2.2. オリジナルのデータフロー
When the OPES processor wants to adapt an application message, it sends a Transaction Start (TS) message to initiate an OCP transaction dedicated to that application message. The processor then sends an Application Message Start (AMS) message to prepare the callout server for application data that will follow. Once the application message scope is established, application data can be sent to the callout server by using Data Use Mine (DUM) and related OCP message(s). All of these messages correspond to the original dataflow.
作品プロセッサがアプリケーションメッセージを適合させたがっているとき、それはそのアプリケーションメッセージに捧げられたOCPトランザクションを開始するTransaction Start(TS)メッセージを送ります。 そしてプロセッサは従うアプリケーションデータのためにcalloutサーバを準備するApplication Message Start(AMS)メッセージを送ります。 いったんアプリケーションメッセージ範囲を確立すると、Data Use Mine(DUM)と関連するOCPメッセージを使用することによって、calloutサーバにアプリケーションデータを送ることができます。 これらのメッセージのすべてがオリジナルのデータフローに対応しています。
2.3. Adapted Dataflow
2.3. 適合しているデータフロー
The callout server receives data and metadata sent by the OPES processor (original dataflow). The callout server analyses metadata and adapts data as it comes in. The server usually builds its version of metadata and responds to the OPES processor with an Application Message Start (AMS) message. Adapted application message data can be sent next, using Data Use Mine (DUM) OCP message(s). The application message is then announced to be "completed" or "closed" by using an Application Message End (AME) message. The transaction may be closed by using a Transaction End (TE) message, as well. All these messages correspond to adapted data flow.
calloutサーバは作品プロセッサ(オリジナルのデータフロー)によって送られたデータとメタデータを受け取ります。 入るとき、calloutサーバは、メタデータを分析して、データを適合させます。 サーバは、通常、メタデータのバージョンを築き上げて、Application Message Start(AMS)メッセージで作品プロセッサに反応します。 Data Use Mine(DUM)OCPメッセージを使用して、次に、適合しているアプリケーションメッセージデータを送ることができます。 そして、アプリケーションメッセージは、Application Message End(AME)メッセージを使用することによって「完成される」か、または「閉じられる」ために発表されます。 トランザクションは、また、Transaction End(TE)メッセージを使用することによって、閉じられるかもしれません。 これらのすべてのメッセージが適合しているデータフローに対応しています。
+---------------+ +-------+
| OPES | == (original data flow) ==> |callout|
| processor | <== (adapted data flow) === |server |
+---------------+ +-------+
+---------------+ +-------+ | 作品| == (オリジナルのデータフロー) ==>| callout| | プロセッサ| <= (適合しているデータフロー) === |サーバ| +---------------+ +-------+
The OPES processor receives the adapted application message sent by the callout server. Other OPES processor actions specific to the application message received are outside scope of this specification.
作品プロセッサはcalloutサーバによって送られた適合しているアプリケーションメッセージを受け取ります。この仕様の範囲の外にアプリケーションメッセージに特定の動作が受けた他の作品プロセッサはあります。
Rousskov Standards Track [Page 8] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[8ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
2.4. Multiple Application Messages
2.4. 複数のアプリケーションメッセージ
OCP Core specifies a transactions interface dedicated to exchanging a single original application message and a single adapted application message. Some application protocols may require multiple adapted versions for a single original application message or even multiple original messages to be exchanged as a part of a single OCP transaction. For example, a single original e-mail message may need to be transformed into several e-mail messages, with one custom message for each recipient.
OCP Coreはただ一つの原出願メッセージとただ一つの適合しているアプリケーションメッセージを交換するのに捧げられたトランザクションインタフェースを指定します。 いくつかのアプリケーション・プロトコルがただ一つの原出願メッセージのための複数の適合しているバージョンか複数のただ一つのOCPトランザクションの一部として交換されるべきオリジナルのメッセージさえ必要とするかもしれません。 例えば、ただ一つのオリジナルのメールメッセージは、いくつかのメールメッセージに変えられる必要があるかもしれません、各受取人あたり1つのカスタムメッセージで。
OCP extensions MAY document mechanisms for exchanging multiple original and/or multiple adapted application messages within a single OCP transaction.
OCP拡張子は、ただ一つのOCPトランザクションの中で複数のオリジナルである、そして/または、複数の適合しているアプリケーションメッセージを交換するためにメカニズムを記録するかもしれません。
2.5. Termination
2.5. 終了
Either OCP agent can terminate application message delivery, transaction, or connection by sending an appropriate OCP message. Usually, the callout server terminates adapted application message delivery and the transaction. Premature and abnormal terminations at arbitrary times are supported. The termination message includes a result description.
どちらのOCPエージェントも、適切なOCPメッセージを送ることによって、アプリケーションメッセージ配送、トランザクション、または接続を終えることができます。 通常、calloutサーバは適合しているアプリケーションメッセージ配送とトランザクションを終えます。 任意の時の時期尚早、そして、異常終了はサポートされます。 終了メッセージは結果記述を含んでいます。
2.6. Message Exchange Patterns
2.6. 交換処理パターン
In addition to messages carrying application data, OCP agents may also exchange messages related to their configuration, state, transport connections, application connections, etc. A callout server may remove itself from the application message processing loop. A single OPES processor can communicate with many callout servers and vice versa. Though many OCP exchange patterns do not follow a classic client-server model, it is possible to think of an OPES processor as an "OCP client" and of a callout server as an "OCP server". The OPES architecture document [RFC3835] describes configuration possibilities.
また、アプリケーションデータを運ぶメッセージに加えて、OCPエージェントはそれらの構成、状態、輸送の接続、アプリケーション接続などに関連するメッセージを交換するかもしれません。 calloutサーバはアプリケーションメッセージ処理ループから立ち退くかもしれません。 単一の作品プロセッサは逆もまた同様に多くのcalloutサーバとコミュニケートできます。 多くのOCP交換パターンは古典的なクライアント・サーバモデルに続きませんが、「OCPサーバ」として「OCPクライアント」としての作品プロセッサとcalloutサーバを考えるのは可能です。 作品アーキテクチャドキュメント[RFC3835]は構成の可能性について説明します。
The following informal rules illustrate relationships between connections, transactions, OCP messages, and application messages:
以下の非公式の規則は接続と、トランザクションと、OCPメッセージと、アプリケーションメッセージとの関係を例証します:
o An OCP agent may communicate with multiple OCP agents. This is
outside the scope of this specification.
o OCPエージェントは複数のOCPエージェントとコミュニケートするかもしれません。 この仕様の範囲の外にこれはあります。
o An OPES processor may have multiple concurrent OCP connections to
a callout server. Communication over multiple OCP connections is
outside the scope of this specification.
o 作品プロセッサには、calloutサーバには複数の同時発生のOCP接続があるかもしれません。この仕様の範囲の外に複数のOCP接続の上のコミュニケーションがあります。
Rousskov Standards Track [Page 9] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[9ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
o A connection may carry multiple concurrent transactions. A
transaction is always associated with a single connection (i.e., a
transaction cannot span multiple concurrent connections).
o 接続は複数の同時発生のトランザクションを運ぶかもしれません。 トランザクションはいつも単独結合に関連しています(すなわち、トランザクションは複数の同時接続にかかることができません)。
o A connection may carry at most one message at a time, including
control messages and transaction-related messages. A message is
always associated with a single connection (i.e., a message cannot
span multiple concurrent connections).
o コントロールメッセージとトランザクション関連のメッセージを含んでいて、接続は一度に1つのメッセージを高々伝えるかもしれません。 メッセージはいつも単独結合に関連しています(すなわち、メッセージは複数の同時接続にかかることができません)。
o A transaction is a sequence of messages related to application of
a given set of callout services to a single application message.
o トランザクションはただ一つのアプリケーションメッセージに対する与えられたセットのcalloutサービスの応用に関連するメッセージの系列です。
A sequence of transaction messages from an OPES processor to a
callout server is called original flow. A sequence of transaction
messages from a callout server to an OPES processor is called
adapted flow. The two flows may overlap in time.
作品プロセッサからcalloutサーバまでのトランザクションメッセージの系列はオリジナルの流れと呼ばれます。 calloutサーバから作品プロセッサまでのトランザクションメッセージの系列は適合している流れと呼ばれます。 2回の流れが時間内に、重なるかもしれません。
o In OCP Core, a transaction is associated with a single original
and a single adapted application message. OCP Core extensions may
extend transaction scope to more application messages.
o OCP Coreでは、トランザクションはただ一つのオリジナルとただ一つの適合しているアプリケーションメッセージに関連しています。 OCP Core拡張子は、より多くのアプリケーションメッセージにトランザクション範囲を広げるかもしれません。
o An application message (adapted or original) is transferred by
using a sequence of OCP messages.
o OCPメッセージの系列を使用することによって、アプリケーションメッセージ(適合しているかオリジナルの)を移します。
2.7. Timeouts
2.7. タイムアウト
OCP violations, resource limits, external dependencies, and other factors may lead to states in which an OCP agent is not receiving required messages from the other OCP agent. OCP Core defines no messages to address such situations. In the absence of any extension mechanism, OCP agents must implement timeouts for OCP operations. An OCP agent MUST forcefully terminate any OCP connection, negotiation, transaction, etc. that is not making progress. This rule covers both dead- and livelock situations.
OCP違反、リソース限界、外部の依存、および他の要素はOCPエージェントがもう片方のOCPエージェントから必要なメッセージを受け取っていない州に通じるかもしれません。 OCP Coreはそのような状況を扱うメッセージを全く定義しません。 どんな拡張機能がないとき、OCPエージェントはOCP操作のためにタイムアウトを実装しなければなりません。 OCPエージェントは力強くどんなOCP接続、交渉、それが進歩をしていないトランザクションなども終えなければなりません。 この規則は死者とlivelock状況の両方をカバーしています。
In their implementation, OCP agents MAY rely on transport-level or other external timeouts if such external timeouts are guaranteed to happen for a given OCP operation. Depending on the OCP operation, an agent may benefit from "pinging" the other side with a Progress Query (PQ) message before terminating an OCP transaction or connection. The latter is especially useful for adaptations that may take a long time at the callout server before producing any adapted data.
それらの実装では、そのような外部のタイムアウトが与えられたOCP操作のために起こるように保証されるなら、OCPエージェントは輸送平らであるか他の外部のタイムアウトを当てにするかもしれません。 OCP操作によって、エージェントは反対側がOCPトランザクションか接続を終える前のProgress Query(PQ)メッセージで「確認」であることの利益を得るかもしれません。 後者は特にどんな適合しているデータも作り出す前にcalloutサーバで長くかかるかもしれない適合の役に立ちます。
Rousskov Standards Track [Page 10] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[10ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
2.8. Environment
2.8. 環境
OCP communication is assumed usually to take place over TCP/IP connections on the Internet (though no default TCP port is assigned to OCP in this specification). This does not preclude OCP from being implemented on top of other transport protocols, or on other networks. High-level transport protocols such as BEEP [RFC3080] may be used. OCP Core requires a reliable and message-order-preserving transport. Any protocol with these properties can be used; the mapping of OCP message structures onto the transport data units of the protocol in question is outside the scope of this specification.
通常、OCPコミュニケーションがインターネットでTCP/IP接続の上で行われると思われます(デフォルトTCPポートは全くこの仕様でOCPに割り当てられませんが)。 これは、他のトランスポート・プロトコルの上か、他のネットワークの上で実装されるので、OCPを排除しません。 BEEP[RFC3080]などのハイレベルのトランスポート・プロトコルは使用されるかもしれません。 OCP Coreは信頼できてメッセージが保存を注文している輸送を必要とします。 これらの特性があるどんなプロトコルも使用できます。 この仕様の範囲の外に問題のプロトコルの輸送データ単位へのOCPメッセージ構造に関するマッピングがあります。
OCP Core is application agnostic. OCP messages can carry application-specific information as a payload or as application-specific message parameters.
OCP Coreはアプリケーション不可知論者です。 OCPメッセージはペイロードとして、または、アプリケーション特有のメッセージパラメタとしてアプリケーション特有の情報を運ぶことができます。
OCP Core overhead in terms of extra traffic on the wire is about 100 - 200 octets per small application message. Pipelining, preview, data preservation, and early termination optimizations, as well as as-is encapsulation of application data, make fast exchange of application messages possible.
小さいアプリケーションメッセージあたりワイヤの上の付加的なトラフィックに関するOCP Coreオーバーヘッドはおよそ100--200の八重奏です。 パイプライン処理、プレビュー、データ保存、および期限前契約解除最適化(そのままと同様にアプリケーションデータのカプセル化)で、アプリケーションメッセージの速い交換は可能になります。
3. Messages
3. メッセージ
As defined in section 1.3, an OCP message is a basic unit of communication between an OPES processor and a callout server. A message is a sequence of octets formatted according to syntax rules (section 3.1). Message semantics is defined in section 11. Messages are transmitted on top of OCP transport.
セクション1.3で定義されるように、OCPメッセージは作品プロセッサとcalloutサーバとのコミュニケーションの原単位です。メッセージはシンタックス・ルール(セクション3.1)によると、フォーマットされた八重奏の系列です。 メッセージ意味論はセクション11で定義されます。 メッセージはOCP輸送の上で送られます。
OCP messages deal with transport, transaction management, and
application data exchange between a single OPES processor and a
single callout server. Some messages can be emitted only by an OPES
processor; some only by a callout server; and some by both OPES
processor and callout server. Some messages require responses (one
could call such messages "requests"); some can only be used in
response to other messages ("responses"); some may be sent without
solicitation; and some may not require a response.
OCPメッセージは輸送、トランザクション管理、および単一の作品プロセッサとただ一つのcalloutサーバの間のアプリケーションデータ交換に対処します。作品プロセッサだけはいくつかのメッセージを放つことができます。 calloutサーバだけによるいくつか。 そして、作品プロセッサとcalloutサーバ両方のいくつかのメッセージによる或るものは応答を必要とします(人は、そのようなメッセージを「要求」と呼ぶことができました)。 他のメッセージ(「応答」)に対応して或るものを使用できるだけです。 懇願なしで或るものを送るかもしれません。 そして、或るものは応答を必要としないかもしれません。
Rousskov Standards Track [Page 11] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[11ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
3.1. Message Format
3.1. メッセージ・フォーマット
An OCP message consists of a message name followed by optional parameters and a payload. The exact message syntax is defined by the following Augmented Backus-Naur Form (ABNF) [RFC2234]:
OCPメッセージは任意のパラメタとペイロードが支えたメッセージ名から成ります。 正確なメッセージ構文は以下のAugmented BN記法(ABNF)[RFC2234]によって定義されます:
message = name [SP anonym-parameters]
[CRLF named-parameters CRLF]
[CRLF payload CRLF]
";" CRLF
「メッセージ=名[SPアノニムパラメタ][CRLF命名されたパラメタCRLF][CRLFペイロードCRLF]」;、」 CRLF
anonym-parameters = value *(SP value) ; space-separated
named-parameters = named-value *(CRLF named-value) ; CRLF-separated
list-items = value *("," value) ; comma-separated
アノニムパラメタは値*(SP値)と等しいです。 スペースで切り離された命名されたパラメタは命名された値の*(CRLFの命名された値)と等しいです。 CRLFによって切り離されたリスト項目が値*と等しい、(「」、値)、。 コンマで、切り離されます。
payload = data
ペイロード=データ
named-value = name ":" SP value
「命名された値は名前と等しい」:、」 SP値
value = structure / list / atom
structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}"
list = "(" [ list-items ] ")"
atom = bare-value / quoted-value
構造/リスト/原子値=構造が「「[アノニムパラメタ][CRLF命名されたパラメタCRLF]」」リスト=と等しい、「(「[リスト項目]」) 」 原子は引用された裸値/値と等しいです。
name = ALPHA *safe-OCTET bare-value = 1*safe-OCTET quoted-value = DQUOTE data DQUOTE data = size ":" *OCTET ; exactly size octets
「=アルファー*金庫OCTET裸値=1*金庫-OCTETをDQUOTEデータDQUOTE引用された値=データ=サイズと命名してください」:、」 *八重奏。 まさにサイズ八重奏
safe-OCTET = ALPHA / DIGIT / "-" / "_" size = dec-number ; 0-2147483647 dec-number = 1*DIGIT ; no leading zeros or signs
アルファー/ DIGIT /「-」/"_"安全なOCTET=サイズはDEC社番号と等しいです。 0-2147483647 DEC社番号は1*DIGITと等しいです。 先行ゼロでないサインがありません。
Several normative rules accompany the above ABNF:
いくつかの標準の規則が上のABNFに同伴します:
o There is no "implied linear space" (LWS) rule. LWS rules are
common to MIME-based grammars but are not used here. The
whitespace syntax is restricted to what is explicitly allowed by
the above ABNF.
o 「暗示している直線的なスペース」(LWS)規則が全くありません。 LWS規則は、MIMEベースの文法に共通ですが、ここで使用されません。 空白構文は上のABNFによって明らかに許容されていることに制限されます。
o All protocol elements are case sensitive unless it is specified
otherwise. In particular, message names and parameter names are
case sensitive.
o それが別の方法で指定されない場合、すべてのプロトコル要素が大文字と小文字を区別しています。 メッセージ名とパラメタ名は特に、大文字と小文字を区別しています。
o Sizes are interpreted as decimal values and cannot have leading
zeros.
o サイズは、デシマル値として解釈されて、先行ゼロを持つことができません。
o Sizes do not exceed 2147483647.
o サイズは2147483647を超えていません。
Rousskov Standards Track [Page 12] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[12ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
o The size attribute in a quoted-value encoding specifies the exact
number of octets following the column (':') separator. If size
octets are not followed by a quote ('"') character, the encoding
is syntactically invalid.
o コラムに従って、引用された値のコード化におけるサイズ属性が八重奏のはっきりした数を指定する、(':'、)、分離符。 引用文がサイズ八重奏のあとに続いていない、('、「'、)、キャラクタ、コード化がシンタクス上無効である、'、」
o Empty quoted values are encoded as a 4-octet sequence "0:".
o 空の引用された値が4八重奏の系列としてコード化される、「0:」
o Any bare value can be encoded as a quoted value. A quoted value
is interpreted after the encoding is removed. For example, number
1234 can be encoded as four octets 1234 or as eight octets
"4:1234", yielding exactly the same meaning.
o 引用された値としてどんな裸値もコード化できます。 コード化を取り除いた後に引用された値を解釈します。 例えば、4つの八重奏1234として、または、8八重奏「4:1234」としてNo.1234をコード化できます、まさに同じ意味をもたらして。
o Unicode UTF-8 is the default encoding. Note that ASCII is a UTF-8
subset, and that the syntax prohibits non-ASCII characters outside
of the "data" element.
o ユニコードUTF-8はデフォルトコード化です。 ASCIIがUTF-8部分集合であり、構文が「データ」要素の外で非ASCII文字を禁止することに注意してください。
Messages violating formatting rules are, by definition, invalid. See section 5 for rules governing processing of invalid messages.
形式規則に違反するメッセージは定義上無効です。 無効のメッセージの処理を治める規則に関してセクション5を見てください。
3.2. Message Rendering
3.2. メッセージレンダリング
OCP message samples in this specification and its extensions may not be typeset to depict minor syntactical details of OCP message format. Specifically, SP and CRLF characters are not shown explicitly. No rendering of an OCP message can be used to infer message format. The message format definition above is the only normative source for all implementations.
この仕様とその拡大でのOCPメッセージのサンプルは、OCPメッセージ・フォーマットの小さい方の構文の詳細について表現するために植字されないかもしれません。 明確に、SPとCRLFキャラクタは明らかに示されません。 メッセージ・フォーマットを推論するのにOCPメッセージのレンダリングを使用できません。 上のメッセージ・フォーマット定義はすべての実装のための唯一の標準のソースです。
On occasion, an OCP message line exceeds text width allowed by this
specification format. A backslash ("\"), a "soft line break"
character, is used to emphasize a protocol-violating
presentation-only linebreak. Bare backslashes are prohibited by OCP
syntax. Similarly, an "\r\n" string is sometimes used to emphasize
the presence of a CRLF sequence, usually before OCP message payload.
Normally, the visible end of line corresponds to the CRLF sequence on
the wire.
時々、OCPメッセージ行はこの仕様形式によって許容されたテキスト幅を超えています。 バックスラッシュ(「\」)(「柔らかいラインブレイク」キャラクタ)は、プロトコルに違反するプレゼンテーションだけlinebreakを強調するのに使用されます。 むき出しのバックスラッシュはOCP構文で禁止されています。 「」 同様と、\r\n」ストリングは、通常OCPメッセージペイロードの前でCRLF系列の存在を強調するのに時々使用されます。 通常、目に見える行末はワイヤのCRLF系列に対応しています。
The next section (section 3.3) contains specific OCP message examples, some of which illustrate the above rendering techniques.
次のセクション(セクション3.3)は特定のOCPメッセージの例を含みます。その或るものは上のレンダリングのテクニックを例証します。
Rousskov Standards Track [Page 13] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[13ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
3.3. Message Examples
3.3. メッセージの例
OCP syntax provides for compact representation of short control messages and required parameters while allowing for parameter extensions. Below are examples of short control messages. The required CRLF sequence at the end of each line is not shown explicitly (see section 3.2).
OCP構文はパラメタ拡張子を考慮している間、短いコントロールメッセージと必要なパラメタのコンパクトな表現に備えます。 以下に、短いコントロールメッセージに関する例があります。 それぞれの行の終わりの必要なCRLF系列は明らかに示されません(セクション3.2を見てください)。
PQ; TS 1 2; DWM 22; DWP 22 16; x-doit "5:xyzzy";
PQ。 t1 2。 DWM22。 DWP22 16。 x-ドイト、「5、: xyzzy、」、。
The above examples contain atomic anonymous parameter values, such as number and string constants. OCP messages sometimes use more complicated parameters such as item lists or structures with named values. As both messages below illustrate, structures and lists can be nested:
上記の例は数やストリング定数などの原子匿名のパラメタ値を含んでいます。 OCPメッセージは時々命名された値がある項目リストか構造などの、より複雑なパラメタを使用します。 以下の両方のメッセージが例証するように、構造とリストを入れ子にすることができます:
NO ({"32:http://www.iana.org/assignments/opes/ocp/tls"});
NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response"
Optional-Parts: (request-header)
},{"54:http://www.iana.org/assignments/opes/ocp/http/response"
Optional-Parts: (request-header,request-body)
Transfer-Encodings: (chunked)
});
(「32、: http://www.iana.org/assignments/opes/ocp/tls 、」、)、。 (「54、: http://www.iana.org/assignments/opes/ocp/http/response 、」 オプショナル・パーツ: (要求ヘッダー)、「54、: http://www.iana.org/assignments/opes/ocp/http/response 、」 オプショナル・パーツ: (要求ヘッダー、要求本体)転送-Encodings:、(chunkedしました)、)、。
Optional parameters and extensions are possible with a named parameters approach, as illustrated by the following example. The DWM (section 11.17) message in the example has two anonymous parameters (the last one being an extension) and two named parameters (the last one being an extension).
任意のパラメタと拡大は以下の例によって例証されるように命名されたパラメタアプローチで可能です。 例のDWM(セクション11.17)メッセージには、2つの匿名のパラメタ(拡大である最後のもの)があります、そして、2は(拡大である最後のもの)とパラメタを命名しました。
DWM 1 3 Size-Request: 16384 X-Need-Info: "26:twenty six octet extension";
DWM1 3サイズ要求: 16384 X必要性インフォメーション: 「26:26八重奏拡大」。
Finally, any message may have a payload part. For example, the Data Use Mine (DUM) message below carries 8865 octets of raw data.
最終的に、どんなメッセージにも、ペイロード部分があるかもしれません。 例えば、以下のData Use Mine(DUM)メッセージは生データの8865の八重奏を運びます。
DUM 1 13 Modp: 75 \r\n 8865:... 8865 octets of raw data ...;
DUM1 13Modp: 75円r n8865円: … 生データの8865の八重奏…;
Rousskov Standards Track [Page 14] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[14ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
3.4. Message Names
3.4. メッセージ名
Most OCP messages defined in this specification have short names, formed by abbreviating or compressing a longer but human-friendlier message title. Short names without a central registration system (such as this specification or the IANA registry) are likely to cause conflicts. Informal protocol extensions should avoid short names. To emphasize what is already defined by message syntax, implementations cannot assume that all message names are very short.
この仕様に基づき定義されたほとんどのOCPメッセージが、より長い、しかし、より人間に優しいメッセージタイトルを簡略化するか、または圧縮することによって形成された省略名を持っています。 主要な登録制(この仕様かIANA登録などの)のない省略名は闘争を引き起こしそうです。 非公式のプロトコル拡大は省略名を避けるべきです。 メッセージ構文で既に定義されることを強調するために、実装は、すべてのメッセージ名が非常に短いと仮定できません。
4. Transactions
4. トランザクション
An OCP transaction is a logical sequence of OCP messages processing a single original application message. The result of the processing
OCPトランザクションはただ一つの原出願メッセージを処理するOCPメッセージの論理的順序です。 処理の結果
may be zero or more application messages, adapted from the original. A typical transaction consists of two message flows: a flow from the OPES processor to the callout server (sending the original application message), and a flow from the callout server to the OPES processor (sending adapted application messages). The number of application messages produced by the callout server and whether the callout server actually modifies the original application message may depend on the requested callout service and other factors. The OPES processor or the callout server can terminate the transaction by sending a corresponding message to the other side.
ゼロかオリジナルから適合させられたより多くのアプリケーションメッセージがそうです。 典型的なトランザクションは2回のメッセージ流れから成ります: 作品プロセッサからcalloutサーバまでの流れ(原出願メッセージを送る)、およびcalloutサーバから作品プロセッサまでの流れ(発信はアプリケーションメッセージを適合させました)。 アプリケーションメッセージの数はcalloutサーバによって生産されました、そして、calloutサーバが実際に原出願メッセージを変更するかどうかが要求されたcalloutサービスと他の要素に依存するかもしれません。 作品プロセッサかcalloutサーバが、対応するメッセージを反対側に送ることによって、トランザクションを終えることができます。
An OCP transaction starts with a Transaction Start (TS) message sent by the OPES processor. A transaction ends with the first Transaction End (TE) message sent or received, explicit or implied. A TE message can be sent by either side. Zero or more OCP messages associated with the transaction can be exchanged in between. The figure below illustrates a possible message sequence (prefix "P" stands for the OPES processor; prefix "S" stands for the callout server). Some message details are omitted.
OCPトランザクションは作品プロセッサによって送られたTransaction Start(TS)メッセージから始まります。 最初のTransaction End(TE)メッセージが送られる、受信される、明白であるかまたは暗示していた状態で、トランザクションは終わります。 どちらの側はTEメッセージを送ることができます。 ゼロかトランザクションに関連しているより多くのOCPメッセージを中間でと交換できます。 以下の図は可能なメッセージ系列を例証します(接頭語「P」は作品プロセッサを表します; 接頭語「S」はcalloutサーバを表します)。 いくつかのメッセージの詳細が省略されます。
P: TS 10;
P: AMS 10 1;
... processor sending application data to the callout server
S: AMS 10 2;
... callout server sending application data to the processor
... processor sending application data to the callout server
P: AME 10 1 result;
S: AME 10 2 result;
P: TE 10 result;
P: t10。 P: AMS10 1。 … calloutサーバSへのプロセッサ送付アプリケーションデータ: AMS10 2。 … calloutサーバPにアプリケーションデータを送るプロセッサ…プロセッサへのcalloutサーバ送付アプリケーションデータ: AME10 1結果。 S: AME10 2は結果として生じます。 P: TE10は結果になります。
Rousskov Standards Track [Page 15] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[15ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
5. Invalid Input
5. 無効の入力
This specification contains many criteria for valid OCP messages and their parts, including syntax rules, semantics requirements, and relationship to agents state. In this context, "Invalid input" means messages or message parts that violate at least one of the normative rules. A message with an invalid part is, by definition, invalid. If OCP agent resources are exhausted while parsing or interpreting a message, the agent MUST treat the corresponding OCP message as invalid.
この仕様は有効なOCPメッセージとそれらの部分の多くの評価基準を含んでいます、シンタックス・ルール、意味論要件、およびエージェント状態との関係を含んでいて。 このような関係においては、「無効の入力」は少なくとも標準の規則の1つに違反するメッセージかメッセージの部品を意味します。 無効の部分があるメッセージは定義上無効です。 OCPエージェントリソースがメッセージを分析するか、または解釈している間、疲れ果てるなら、エージェントは無効の対応するOCP同じくらいメッセージを扱わなければなりません。
Unless explicitly allowed to do otherwise, an OCP agent MUST terminate the transaction if it receives an invalid message with transaction scope and MUST terminate the connection if it receives an invalid message with a connection scope. A terminating agent MUST use the result status code of 400 and MAY specify termination cause information in the result status reason parameter (see section 10.10). If an OCP agent is unable to determine the scope of an invalid message it received, the agent MUST treat the message as having connection scope.
トランザクション範囲で無効のメッセージを受け取って、接続範囲で無効のメッセージを受け取るなら接続を終えなければならなくて、別の方法でするのは明らかに許容されていない場合、OCPエージェントがトランザクションを終えなければなりません。 終わっているエージェントは、400の結果ステータスコードを使用しなければならなくて、結果状態理由パラメタの終了原因情報を指定するかもしれません(セクション10.10を見てください)。 OCPエージェントがそれが受け取った無効のメッセージの範囲を決定できないなら、エージェントは接続範囲を持っているとしてメッセージを扱わなければなりません。
OCP usually deals with optional but invasive application message manipulations for which correctness ought to be valued above robustness. For example, a failure to insert or remove certain optional web page content is usually far less disturbing than corrupting (making unusable) the host page while performing that insertion or removal. Most OPES adaptations are high level in nature, which makes it impossible to assess correctness of the adaptations automatically, especially if "robustness guesses" are involved.
通常、OCPは正当性が丈夫さを超えて評価されるべきである任意の、しかし、侵略的なアプリケーションメッセージ操作に対処します。 例えば、通常、ある任意のウェブページ内容を挿入するか、または取り除かないことはその挿入か取り外しを実行している間、ホストページを崩壊させるより(使用不可能な作成)はるかに不穏ではありません。 ほとんどの作品適合が自然で高いレベルです、特に「丈夫さ推測」がかかわるなら。(自然は自動的に適合の正当性を評価するのを不可能にします)。
6. Negotiation
6. 交渉
The negotiation mechanism allows OCP agents to agree on the mutually acceptable set of features, including optional and application-specific behavior and OCP extensions. For example, transport encryption, data format, and support for a new message can be negotiated. Negotiation implies intent for a behavioral change. For a related mechanism allowing an agent to query capabilities of its counterpart without changing the counterpart's behavior, see the Ability Query (AQ) and Ability Answer (AA) message definitions.
OCPエージェントは交渉メカニズムで互いに許容できるセットの特徴に同意できます、任意、そして、アプリケーション特異的行動とOCP拡張子を含んでいて。 例えば、暗号化、データの形式を輸送してください。そうすれば、新しいメッセージのサポートは交渉できます。 交渉は行動変化に関する意図を含意します。 エージェントが対応者の振舞いを変えないで対応者の能力について質問できる関連するメカニズムに関しては、Ability Query(AQ)とAbility Answer(AA)メッセージ定義を見てください。
Most negotiations require at least one round trip time delay. In rare cases when the other side's response is not required immediately, negotiation delay can be eliminated, with an inherent risk of an overly optimistic assumption about the negotiation response.
ほとんどの交渉が少なくとも1つの周遊旅行時間遅れを必要とします。 たまには反対側の応答はすぐに必要でないときに、交渉遅れを排除できます、交渉応答に関するひどく楽観的な仮定の固有のリスクで。
Rousskov Standards Track [Page 16] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[16ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
A detected violation of negotiation rules leads to OCP connection termination. This design reduces the number of negotiation scenarios resulting in a deadlock when one of the agents is not compliant.
交渉規則の検出された違反はOCP接続終了につながります。 このデザインはエージェントのひとりが言いなりにならないとき行き詰まりをもたらす交渉シナリオの数を減少させます。
Two core negotiation primitives are supported: negotiation offer and negotiation response. A Negotiation Offer (NO) message allows an agent to specify a set of features from which the responder has to select at most one feature that it prefers. The selection is sent by using a Negotiation Response (NR) message. If the response is positive, both sides assume that the selected feature is in effect immediately (see section 11.19 for details). If the response is negative, no behavioral changes are assumed. In either case, further offers may follow.
2つのコア交渉基関数がサポートされます: 交渉申し出と交渉応答。 Negotiation Offer(いいえ)メッセージで、エージェントは応答者がそれが好む1つの特徴を高々選択しなければならない1セットの特徴を指定できます。 Negotiation Response(NR)メッセージを使用することによって、選択を送ります。 応答が積極的であるなら、両側は、選択された特徴がすぐに有効であると仮定します(詳細に関してセクション11.19を見てください)。 応答が否定的であるなら、行動変化は全く想定されません。 どちらの場合ではも、さらなる申し出は続くかもしれません。
Negotiating OCP agents have to take into account prior negotiated (i.e., already enabled) features. OCP agents MUST NOT make and MUST reject offers that would lead to a conflict with already negotiated features. For example, an agent cannot offer an HTTP application profile for a connection that already has an SMTP application profile enabled, as there would be no way to resolve the conflict for a given transaction. Similarly, once TLSv1 connection encryption is negotiated, an agent must not offer and must reject offers for SSLv2 connection encryption (unless a negotiated feature explicitly allows for changing an encryption scheme on the fly).
交渉しているOCPエージェントは先の交渉された(すなわち、既に可能にされた)特徴を考慮に入れなければなりません。 OCPエージェントは拒絶しなければなりません。既に交渉された特徴との闘争に通じる申し出を、作って、拒絶してはいけません。 例えば、エージェントはSMTPアプリケーションプロフィールを既に可能にさせる接続のためにHTTPアプリケーションプロフィールを提供できません、与えられたトランザクションのために対立を解決する方法が全くないでしょう、したがって。 同様に、TLSv1接続暗号化がいったん交渉されると、エージェント必須は、SSLv2接続暗号化のための申し出を提供して、拒絶してはいけません(交渉された特徴が、急いで暗号化体系を変えると明らかに考慮しない場合)。
Negotiation Offer (NO) messages may be sent by either agent. OCP extensions documenting negotiation MAY assign the initiator role to one of the agents, depending on the feature being negotiated. For example, negotiation of transport security feature should be initiated by OPES processors to avoid situations where both agents wait for the other to make an offer.
交渉Offer(いいえ)メッセージはどちらのエージェントによっても送られるかもしれません。 交渉される特徴によって、交渉を記録するOCP拡張子は創始者の役割をエージェントのひとりに割り当てるかもしれません。 例えば、セキュリティが特徴とする輸送の交渉は作品プロセッサによって開始されて、両方のエージェントがもう片方が申し出るのを待つ状況を避けるべきです。
As either agent may make an offer, two "concurrent" offers may be made at the same time, by the two communicating agents. Unmanaged concurrent offers may lead to a negotiation deadlock. By giving OPES processor a priority, offer-handling rules (section 11.18) ensure that only one offer per OCP connection is honored at a time, and that the other concurrent offers are ignored by both agents.
どちらのエージェントも申し出るとき、同時に2つの「同時発生」の申し出をするかもしれません、2人の交信しているエージェントで。 Unmanaged同時発生の申し出は交渉行き詰まりにつながるかもしれません。 作品プロセッサを優先させることによって、申し出取り扱い規則(セクション11.18)は、OCP接続あたり1つの申し出だけが一度に、光栄に思っていて、他の同時発生の申し出が両方のエージェントによって無視されるのを確実にします。
6.1. Negotiation Phase
6.1. 交渉フェーズ
A Negotiation Phase is a mechanism ensuring that both agents have a chance to negotiate all features they require before proceeding further. Negotiation Phases have OCP connection scope and do not overlap. For each OCP agent, the Negotiation Phase starts with the first Negotiation Offer (NO) message received or the first Negotiation Response (NR) message sent, provided the message is not a part of an existing Phase. For each OCP agent, Negotiation Phase
Negotiation Phaseは両方のエージェントには彼らがさらに続く前に必要とするすべての特徴を交渉する機会があるのを確実にするメカニズムです。 交渉PhasesはOCP接続範囲を持って、重なりません。 それぞれのOCPエージェントに関しては、Negotiation Phaseは送るどんなメッセージも受けなかった最初のNegotiation Offerか最初のNegotiation Response(NR)メッセージから始まります、メッセージが既存のPhaseの一部でないなら。 それぞれのOCPエージェント、Negotiation Phaseのために
Rousskov Standards Track [Page 17] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[17ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
ends with the first Negotiation Response (NR) message (sent or received), after which the agent expects no more negotiations. Agent expectation rules are defined later in this section.
最初のNegotiation Response(NR)メッセージ(送るか、または受け取る)がある終わり。(その時、エージェントはそれ以上の交渉を全く予想しませんでした後)。 エージェント期待規則は後でこのセクションで定義されます。
During a Negotiation Phase, an OCP agent MUST NOT send messages other than the following "Negotiation Phase messages": Negotiation Offer (NO), Negotiation Response (NR), Ability Query (AQ), Ability Answer (AA), Progress Query (PQ), Progress Answer (PA), Progress Report (PR), and Connection End (CE).
Negotiation Phaseの間、OCPエージェントは以下の「交渉Phaseメッセージ」を除いたメッセージを送ってはいけません: 交渉申し出(いいえ)、交渉応答(NR)、能力質問(AQ)(能力答え(AA))は質問(PQ)、進歩答え(PA)、経過報告書(PR)、および接続終わりの(Ce)を進行します。
Multiple Negotiation Phases may happen during the lifespan of a single OCP connection. An agent may attempt to start a new Negotiation Phase immediately after the old Phase is over, but it is possible that the other agent will send messages other than "Negotiation Phase messages" before receiving the new Negotiation Offer (NO). The agent that starts a Phase has to be prepared to handle those messages while its offer is reaching the recipient.
複数のNegotiation Phasesが単独のOCP接続の寿命の間、起こるかもしれません。 古いPhaseが終わっている直後エージェントは、新しいNegotiation Phaseを始動するのを試みるかもしれませんが、もう片方のエージェントが新しいNegotiation Offer(いいえ)を受ける前の「交渉Phaseメッセージ」を除いたメッセージを送るのは、可能です。 Phaseを始動するエージェントは申し出が受取人に届いている間、それらのメッセージを扱う用意ができていなければなりません。
An OPES processor MUST make a negotiation offer immediately after sending a Connection Start (CS) message. If the OPES processor has nothing to negotiate, the processor MUST send a Negotiation Offer (NO) message with an empty features list. These two rules bootstrap the first Negotiation Phase. Agents are expected to negotiate at least the application profile for OCP Core. Thus, these bootstrapping requirements are unlikely to result in any extra work.
作品プロセッサはConnection Start(CS)メッセージを送る直後交渉申し出をしなければなりません。 作品プロセッサに何も交渉するものがないなら、プロセッサは空の特徴リストがあるどんなメッセージもNegotiation Offerに送ってはいけません。 これらの2つの規則が最初のNegotiation Phaseを独力で進みます。 エージェントがOCP Coreのための少なくともアプリケーションプロフィールを交渉すると予想されます。 したがって、要件を独力で進むこれらはどんな時間外労働ももたらしそうにはありません。
Once a Negotiation Phase starts, an agent MUST expect further negotiations if and only if the last NO sent or the last NR received contained a true "Offer-Pending" parameter value. Informally, an agent can keep the phase open by sending true "Offer-Pending" parameters with negotiation offers or responses. Moreover, if there is a possibility that the agent may need to continue the Negotiation Phase, the agent must send a true "Offer-Pending" parameter.
そして、Negotiation Phaseがいったん始まると、エージェントがさらなる交渉を予想しなければならない、最後のノーが発信しただけであるか、そして、NRが受けた最終が本当の「未定の申し出」パラメタ価値を含みました。 非公式に、エージェントは、フェーズを開くように交渉申し出か応答と共に本当の「未定の申し出」パラメタを送ることによって、保つことができます。 そのうえ、エージェントが、Negotiation Phaseを続ける必要があるかもしれない可能性があれば、エージェントは本当の「未定の申し出」パラメタを送らなければなりません。
6.2. Negotiation Examples
6.2. 交渉の例
Below is an example of the simplest negotiation possible. The OPES processor is offering nothing and is predictably receiving a rejection. Note that the NR message terminates the Negotiation Phase in this case because neither of the messages contains a true "Offer-Pending" value:
以下に、可能な最も簡単な交渉に関する例があります。 作品プロセッサは、何も提供していなくて、予想どおりに拒絶を受けています。 メッセージのどちらも本当の「未定の申し出」値を含まないのでNRメッセージがこの場合Negotiation Phaseを終えることに注意してください:
P: NO (); S: NR;
P: ()がありません。 S: NR。
The next example illustrates how a callout server can force negotiation of a feature that an OPES processor has not negotiated. Note that the server sets the "Offer-Pending" parameter to true when
次の例はcalloutサーバがどう作品プロセッサが交渉していない特徴の交渉を強制できるかを例証します。 サーバが「未定の申し出」パラメタを本当に設定することに注意してください、いつ
Rousskov Standards Track [Page 18] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[18ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
responding to the processor Negotiation Offer (NO) message. The processor chooses to accept the feature:
プロセッサNegotiation Offerにどんなメッセージも反応させません。 プロセッサは、特徴を受け入れるのを選びます:
P: NO ();
S: NR
Offer-Pending: true
;
S: NO ({"22:ocp://feature/example/"})
Offer-Pending: false
;
P: NR {"22:ocp://feature/example/"};
P: ()がありません。 S: 申し出未定のNR: 本当。 S: (「22、: ocp://feature/example/、」、)、未定の申し出: 誤っている。 P: NR、「22、: ocp://feature/example/、」、。
If the server seeks to stop the above negotiations after sending a true "Offer-Pending" value, its only option would be send an empty negotiation offer (see the first example above). If the server does nothing instead, the OPES processor would wait for the server and would eventually time out the connection.
本当の「未定の申し出」値を送った後にサーバが上の交渉を止めようとするなら、唯一のオプションは空の交渉申し出を送ること(上記を最初の例見る)でしょう。 サーバが代わりに何もしないなら、作品プロセッサがサーバを待っていて、結局待つだろう、タイムアウト、接続。
The following example shows a dialog with a callout server that insists on enabling two imaginary features: strong transport encryption and volatile storage for responses. The server is designed not to exchange sensitive messages until both features are enabled. Naturally, the volatile storage feature has to be negotiated securely. The OPES processor supports one of the strong encryption mechanisms but prefers not to offer (to volunteer support for) strong encryption, perhaps for performance reasons. The server has to send a true "Offer-Pending" parameter to get a chance to offer strong encryption (which is successfully negotiated in this case). Any messages sent by either agent after the (only) successful NR response are encrypted with "strongB" encryption scheme. The OPES processor does not understand the volatile storage feature, and the last negotiation fails (over a strongly encrypted transport connection).
以下の例は2つの想像する特徴を可能にすると主張するcalloutサーバで対話を示しています: 強い輸送暗号化と応答のための揮発性記憶装置。 サーバは、両方の特徴が可能にされるまで機密のメッセージを交換しないように設計されています。 当然、揮発性記憶装置機能はしっかりと交渉されなければなりません。 作品プロセッサは、強い暗号化メカニズムの1つをサポートしますが、強い暗号化を提供しないのを(サポートを買って出る)好みます、恐らく性能理由で。 サーバは、強い暗号化(この場合首尾よく交渉される)を提供する機会を得るために本当の「未定の申し出」パラメタを送らなければなりません。 (唯一)のうまくいっているNR応答の後にどちらのエージェントによっても送られたどんなメッセージも"strongB"暗号化体系で暗号化されます。 作品プロセッサは揮発性記憶装置機能を理解していません、そして、最後の交渉は失敗します(強く暗号化された輸送接続の上で)。
P: NO ({"29:ocp://example/encryption/weak"})
;
S: NR
Offer-Pending: true
;
S: NO ({"32:ocp://example/encryption/strongA"},\
{"32:ocp://example/encryption/strongB"})
Offer-Pending: true
;
P: NR {"32:ocp://example/encryption/strongB"}
;
... all traffic below is encrypted using strongB ...
P: (「29、: ocp://例/暗号化/弱者、」、)、。 S: 申し出未定のNR: 本当。 S: (「32、: ocp://例/暗号化/strongA、」、\、「32、: ocp://例/暗号化/strongB、」、)、未定の申し出: 本当。 P: NR、「32、: ocp://例/暗号化/strongB、」、。 … 以下のすべてのトラフィックがstrongBを使用することで暗号化されています…
Rousskov Standards Track [Page 19] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[19ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
S: NO ({"31:ocp://example/storage/volatile"})
Offer-Pending: false
;
P: NR
Unknowns: ({"31:ocp://example/storage/volatile"})
;
S: CSE { 400 "33:lack of VolStore protocol support" }
;
S: (「31:、ocp://例/ストレージ/揮発性、」、)、未定の申し出: 誤っている。 P: NR未知: (「31:、ocp://例/ストレージ/揮発性、」、) ; S: CSE、400、「33: VolStoreの不足はサポートについて議定書の中で述べる」、。
The following example from [OPES-HTTP] illustrates successful HTTP application profile negotiation:
[作品HTTP]からの以下の例はうまくいっているHTTPアプリケーションプロフィール交渉を例証します:
P: NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header,request-body)
})
SG: 5;
S: NR {"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header)
Pause-At-Body: 30
Wont-Send-Body: 2147483647
Content-Encodings: (gzip)
}
SG: 5;
P: (「54、: http://www.iana.org/assignments/opes/ocp/http/response 、」 補助の部分: (要求ヘッダー、要求本体)、)、SG: 5; S: NR、「54: 」 補助の部分: (要求ヘッダー)がボディーでポーズする http://www.iana.org/assignments/opes/ocp/http/response : 30 習慣はボディーを送ります:、2147483647内容-Encodings: (gzip)、SG: 5;
7. 'Data Preservation' Optimization
7. 'データ保存'最適化
Many adaptations do not require any data modifications (e.g., message logging or blocking). Some adaptations modify only a small portion of application message content (e.g., HTTP cookies filtering or ad insertion). Yet, in many cases, the callout service has to see complete data. By default, unmodified data would first travel from the OPES processor to the callout server and then back. The "data preservation" optimization in OCP helps eliminate the return trip if both OCP agents cooperate. Such cooperation is optional: OCP agents MAY support data preservation optimization.
多くの適合は少しのデータ変更(例えば、メッセージ伐採かブロッキング)も必要としません。 いくつかの適合がアプリケーションメッセージ内容(例えば、HTTPクッキーフィルタリングか広告挿入)の少量だけを変更します。 しかし、多くの場合、calloutサービスは完全なデータを見なければなりません。 デフォルトで、変更されていないデータは、最初に、calloutサーバへの作品プロセッサから旅して、次に、後部から旅するでしょう。 OCPの「データ保存」最適化は、両方のOCPエージェントが協力するなら往復を排除するのを助けます。 そのような協力は任意です: OCPエージェントは、データ保存が最適化であるとサポートするかもしれません。
To avoid sending back unmodified data, a callout service has to know that the OPES processor has a copy of the data. As data sizes can be very large and the callout service may not know in advance whether it will be able to use the processor copy, it is not possible to require the processor to keep a copy of the entire original data. Instead, it is expected that a processor may keep some portion of the data, depending on processor settings and state.
To avoid sending back unmodified data, a callout service has to know that the OPES processor has a copy of the data. As data sizes can be very large and the callout service may not know in advance whether it will be able to use the processor copy, it is not possible to require the processor to keep a copy of the entire original data. Instead, it is expected that a processor may keep some portion of the data, depending on processor settings and state.
When an OPES processor commits to keeping a data chunk, it announces its decision and the chunk parameters via a Kept parameter of a Data Use Mine (DUM) message. The callout server MAY "use" the chunk by sending a Data Use Yours (DUY) message referring to the preserved
When an OPES processor commits to keeping a data chunk, it announces its decision and the chunk parameters via a Kept parameter of a Data Use Mine (DUM) message. The callout server MAY "use" the chunk by sending a Data Use Yours (DUY) message referring to the preserved
Rousskov Standards Track [Page 20] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov Standards Track [Page 20] RFC 4037 OPES Callout Protocol Core March 2005
chunk. That OCP message does not have payload and, therefore, the return trip is eliminated.
chunk. That OCP message does not have payload and, therefore, the return trip is eliminated.
As the mapping between original and adapted data is not known to the processor, the processor MUST keep the announced-as-preserved chunk until the end of the corresponding transaction, unless the callout server explicitly tells the processor that the chunk is not needed. As implied by the above requirement, the processor cannot assume that a data chunk is no longer needed just because the callout server sent a Data Use Yours (DUY) message or adapted data with, for instance, the same offset as the preserved chunk.
As the mapping between original and adapted data is not known to the processor, the processor MUST keep the announced-as-preserved chunk until the end of the corresponding transaction, unless the callout server explicitly tells the processor that the chunk is not needed. As implied by the above requirement, the processor cannot assume that a data chunk is no longer needed just because the callout server sent a Data Use Yours (DUY) message or adapted data with, for instance, the same offset as the preserved chunk.
For simplicity, preserved data is always a contiguous chunk of original data, described by an (offset, size) pair using a "Kept" parameter of a Data Use Mine (DUM) message. An OPES processor may volunteer to increase the size of the kept data. An OPES processor may increase the offset if the callout server indicated that the kept data is no longer needed.
For simplicity, preserved data is always a contiguous chunk of original data, described by an (offset, size) pair using a "Kept" parameter of a Data Use Mine (DUM) message. An OPES processor may volunteer to increase the size of the kept data. An OPES processor may increase the offset if the callout server indicated that the kept data is no longer needed.
Both agents may benefit from data reuse. An OPES processor has to allocate storage to support this optimization, but a callout server does not. On the other hand, it is the callout server that is responsible for relieving the processor from data preservation commitments. There is no simple way to resolve this conflict of interest on a protocol level. Some OPES processors may allocate a relatively small buffer for data preservation purposes and stop preserving data when the buffer becomes full. This technique would benefit callout services that can quickly reuse or discard kept data. Another processor strategy would be to size the buffer based on historical data reuse statistics. To improve chances of beneficial cooperation, callout servers are strongly encouraged to immediately notify OPES processors of unwanted data. The callout server that made a decision not to send Data Use Yours (DUY) messages (for a specific data ranges or at all) SHOULD immediately inform the OPES processor of that decision with the corresponding Data Preservation Interest (DPI) message(s) or other mechanisms.
Both agents may benefit from data reuse. An OPES processor has to allocate storage to support this optimization, but a callout server does not. On the other hand, it is the callout server that is responsible for relieving the processor from data preservation commitments. There is no simple way to resolve this conflict of interest on a protocol level. Some OPES processors may allocate a relatively small buffer for data preservation purposes and stop preserving data when the buffer becomes full. This technique would benefit callout services that can quickly reuse or discard kept data. Another processor strategy would be to size the buffer based on historical data reuse statistics. To improve chances of beneficial cooperation, callout servers are strongly encouraged to immediately notify OPES processors of unwanted data. The callout server that made a decision not to send Data Use Yours (DUY) messages (for a specific data ranges or at all) SHOULD immediately inform the OPES processor of that decision with the corresponding Data Preservation Interest (DPI) message(s) or other mechanisms.
8. 'Premature Dataflow Termination' Optimizations
8. 'Premature Dataflow Termination' Optimizations
Many callout services adapt small portions of large messages and would preferably not to be in the loop when that adaptation is over. Some callout services may not seek data modification and would preferably not send data back to the OPES processor, even if the OPES processor is not supporting the data preservation optimization (Section 7). By OCP design, unilateral premature dataflow termination by a callout server would lead to termination of an OCP transaction with an error. Thus, the two agents must cooperate to allow for error-free premature termination.
Many callout services adapt small portions of large messages and would preferably not to be in the loop when that adaptation is over. Some callout services may not seek data modification and would preferably not send data back to the OPES processor, even if the OPES processor is not supporting the data preservation optimization (Section 7). By OCP design, unilateral premature dataflow termination by a callout server would lead to termination of an OCP transaction with an error. Thus, the two agents must cooperate to allow for error-free premature termination.
Rousskov Standards Track [Page 21] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov Standards Track [Page 21] RFC 4037 OPES Callout Protocol Core March 2005
This section documents two mechanisms for premature termination of original or adapted dataflow. In combination, the mechanisms allow the callout server to get out of the processing loop altogether.
This section documents two mechanisms for premature termination of original or adapted dataflow. In combination, the mechanisms allow the callout server to get out of the processing loop altogether.
8.1. Original Dataflow
8.1. Original Dataflow
There are scenarios where a callout server is not interested in the remaining original dataflow. For example, a simple access blocking or "this site is temporary down" callout service has to send an adapted (generated) application message but would preferably not receive original data from the OPES processor.
There are scenarios where a callout server is not interested in the remaining original dataflow. For example, a simple access blocking or "this site is temporary down" callout service has to send an adapted (generated) application message but would preferably not receive original data from the OPES processor.
OCP Core supports premature original dataflow termination via the Want Stop Receiving Data (DWSR) message. A callout server that does not seek to receive additional original data (beyond a certain size) sends a DWSR message. The OPES processor receiving a DWSR message terminates original dataflow by sending an Application Message End (AME) message with a 206 (partial) status code.
OCP Core supports premature original dataflow termination via the Want Stop Receiving Data (DWSR) message. A callout server that does not seek to receive additional original data (beyond a certain size) sends a DWSR message. The OPES processor receiving a DWSR message terminates original dataflow by sending an Application Message End (AME) message with a 206 (partial) status code.
The following figure illustrates a typical sequence of events. The downward lines connecting the two dataflows illustrate the transmission delay that allows for more OCP messages to be sent while an agent waits for the opposing agent reaction.
The following figure illustrates a typical sequence of events. The downward lines connecting the two dataflows illustrate the transmission delay that allows for more OCP messages to be sent while an agent waits for the opposing agent reaction.
OPES Callout
Processor Server
DUM> <DUM
DUM> <DWSR <-- Server is ready to stop receiving
... _____/<DUM <-- Server continues as usual
DUM>______/ <DUM
AME> ... <-- Processor stops sending original data
\_____ <DUM
\______<DUM
<DUM <-- Server continues to send adapted data
...
<AME
OPES Callout Processor Server DUM> <DUM DUM> <DWSR <-- Server is ready to stop receiving ... _____/<DUM <-- Server continues as usual DUM>______/ <DUM AME> ... <-- Processor stops sending original data \_____ <DUM \______<DUM <DUM <-- Server continues to send adapted data ... <AME
The mechanism described in this section has no effect on the adapted dataflow. Receiving an Application Message End (AME) message with 206 (partial) result status code from the OPES processor does not introduce any special requirements for the adapted dataflow termination. However, it is not possible to terminate adapted dataflow prematurely after the original dataflow has been prematurely terminated (see section 8.3).
The mechanism described in this section has no effect on the adapted dataflow. Receiving an Application Message End (AME) message with 206 (partial) result status code from the OPES processor does not introduce any special requirements for the adapted dataflow termination. However, it is not possible to terminate adapted dataflow prematurely after the original dataflow has been prematurely terminated (see section 8.3).
Rousskov Standards Track [Page 22] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov Standards Track [Page 22] RFC 4037 OPES Callout Protocol Core March 2005
8.2. Adapted Dataflow
8.2. Adapted Dataflow
There are scenarios where a callout service may want to stop sending adapted data before a complete application message has been sent. For example, a logging-only callout service has to receive all application messages but would preferably not send copies back to the OPES processor.
There are scenarios where a callout service may want to stop sending adapted data before a complete application message has been sent. For example, a logging-only callout service has to receive all application messages but would preferably not send copies back to the OPES processor.
OCP Core supports premature adapted dataflow termination via a combination of Want Stop Sending Data (DWSS) and Stop Sending Data (DSS) messages. A callout service that seeks to stop sending data sends a DWSS message, soliciting an OPES processor permission to stop. While waiting for the permission, the server continues with its usual routine.
OCP Core supports premature adapted dataflow termination via a combination of Want Stop Sending Data (DWSS) and Stop Sending Data (DSS) messages. A callout service that seeks to stop sending data sends a DWSS message, soliciting an OPES processor permission to stop. While waiting for the permission, the server continues with its usual routine.
An OPES processor receiving a Want Stop Sending Data message responds with a Stop Sending Data (DSS) message. The processor may then pause to wait for the callout server to terminate the adapted dataflow or may continue sending original data while making a copy of it. Once the server terminates the adapted dataflow, the processor is responsible for using original data (sent or paused after sending DSS) instead of the adapted data.
An OPES processor receiving a Want Stop Sending Data message responds with a Stop Sending Data (DSS) message. The processor may then pause to wait for the callout server to terminate the adapted dataflow or may continue sending original data while making a copy of it. Once the server terminates the adapted dataflow, the processor is responsible for using original data (sent or paused after sending DSS) instead of the adapted data.
The callout server receiving a DSS message terminates the adapted dataflow (see the Stop Sending Data (DSS) message definition for the exact requirements and corner cases).
The callout server receiving a DSS message terminates the adapted dataflow (see the Stop Sending Data (DSS) message definition for the exact requirements and corner cases).
The following figure illustrates a typical sequence of events, including a possible pause in original dataflow when the OPES processor is waiting for the adapted dataflow to end. The downward lines connecting the two dataflows illustrate the transmission delay that allows for more OCP messages to be sent while an agent waits for the opposing agent reaction.
The following figure illustrates a typical sequence of events, including a possible pause in original dataflow when the OPES processor is waiting for the adapted dataflow to end. The downward lines connecting the two dataflows illustrate the transmission delay that allows for more OCP messages to be sent while an agent waits for the opposing agent reaction.
Rousskov Standards Track [Page 23] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov Standards Track [Page 23] RFC 4037 OPES Callout Protocol Core March 2005
OPES Callout
Processor Server
DUM> <DUM
DUM> <DWSS <-- Server is ready to stop sending
... _____/<DUM <-- Server continues as usual,
DUM>______/ <DUM waiting for DSS
DSS> ...
\_____ <DUM
possible \______<DUM
org-dataflow <AME 206 <-- Server terminates adapted dataflow
pause _____/ upon receiving the DSS message
______/
DUM> <-- Processor resumes original dataflow
DUM> to the server and starts using
... original data without adapting it
AME>
OPES Callout Processor Server DUM> <DUM DUM> <DWSS <-- Server is ready to stop sending ... _____/<DUM <-- Server continues as usual, DUM>______/ <DUM waiting for DSS DSS> ... \_____ <DUM possible \______<DUM org-dataflow <AME 206 <-- Server terminates adapted dataflow pause _____/ upon receiving the DSS message ______/ DUM> <-- Processor resumes original dataflow DUM> to the server and starts using ... original data without adapting it AME>
Premature adapted dataflow preservation is not trivial, as the OPES processor relies on the callout server to provide adapted data (modified or not) to construct the adapted application message. If the callout server seeks to quit its job, special care must be taken to ensure that the OPES processor can construct the complete application message. On a logical level, this mechanism is equivalent to switching from one callout server to another (non-modifying) callout server in the middle of an OCP transaction.
Premature adapted dataflow preservation is not trivial, as the OPES processor relies on the callout server to provide adapted data (modified or not) to construct the adapted application message. If the callout server seeks to quit its job, special care must be taken to ensure that the OPES processor can construct the complete application message. On a logical level, this mechanism is equivalent to switching from one callout server to another (non-modifying) callout server in the middle of an OCP transaction.
Other than a possible pause in the original dataflow, the mechanism described in this section has no effect on the original dataflow. Receiving an Application Message End (AME) message with 206 (partial) result status code from the callout server does not introduce any special requirements for the original dataflow termination.
Other than a possible pause in the original dataflow, the mechanism described in this section has no effect on the original dataflow. Receiving an Application Message End (AME) message with 206 (partial) result status code from the callout server does not introduce any special requirements for the original dataflow termination.
8.3. Getting Out of the Loop
8.3. Getting Out of the Loop
Some adaptation services work on application message prefixes and do not seek to be in the adaptation loop once their work is done. For example, an ad insertion service that did its job by modifying the first fragment of a web "page" would not seek to receive more original data or to perform further adaptations. The 'Getting Out of the Loop' optimization allows a callout server to get completely out of the application message processing loop.
Some adaptation services work on application message prefixes and do not seek to be in the adaptation loop once their work is done. For example, an ad insertion service that did its job by modifying the first fragment of a web "page" would not seek to receive more original data or to perform further adaptations. The 'Getting Out of the Loop' optimization allows a callout server to get completely out of the application message processing loop.
The "Getting Out of the Loop" optimization is made possible by terminating the adapted dataflow (section 8.2) and then by terminating the original dataflow (section 8.1). The order of termination is very important.
The "Getting Out of the Loop" optimization is made possible by terminating the adapted dataflow (section 8.2) and then by terminating the original dataflow (section 8.1). The order of termination is very important.
Rousskov Standards Track [Page 24] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov Standards Track [Page 24] RFC 4037 OPES Callout Protocol Core March 2005
If the original dataflow is terminated first, the OPES processor would not allow the adapted dataflow to be terminated prematurely, as the processor would not be able to reconstruct the remaining portion of the adapted application message. The processor would not know which suffix of the remaining original data has to follow the adapted parts. The mapping between original and adapted octets is known only to the callout service.
If the original dataflow is terminated first, the OPES processor would not allow the adapted dataflow to be terminated prematurely, as the processor would not be able to reconstruct the remaining portion of the adapted application message. The processor would not know which suffix of the remaining original data has to follow the adapted parts. The mapping between original and adapted octets is known only to the callout service.
An OPES processor that received a DWSS message followed by a DWSR message MUST NOT send an AME message with a 206 (partial) status code before sending a DSS message. Informally, this rule means that a callout server that wants to get out of the loop fast should send a DWSS message immediately followed by a DWSR message; the server does not have to wait for the OPES processor's permission to terminate adapted dataflow before requesting that the OPES processor terminates original dataflow.
An OPES processor that received a DWSS message followed by a DWSR message MUST NOT send an AME message with a 206 (partial) status code before sending a DSS message. Informally, this rule means that a callout server that wants to get out of the loop fast should send a DWSS message immediately followed by a DWSR message; the server does not have to wait for the OPES processor's permission to terminate adapted dataflow before requesting that the OPES processor terminates original dataflow.
9. Protocol Element Type Declaration Mnemonic (PETDM)
9. Protocol Element Type Declaration Mnemonic (PETDM)
A protocol element type is a named set of syntax and semantics rules. This section defines a simple, formal declaration mnemonic for protocol element types, labeled PETDM. PETDM simplicity is meant to ease type declarations in this specification. PETDM formality is meant to improve interoperability among implementations. Two protocol elements are supported by PETDM: message parameter values and messages.
A protocol element type is a named set of syntax and semantics rules. This section defines a simple, formal declaration mnemonic for protocol element types, labeled PETDM. PETDM simplicity is meant to ease type declarations in this specification. PETDM formality is meant to improve interoperability among implementations. Two protocol elements are supported by PETDM: message parameter values and messages.
All OCP Core parameter and message types are declared by using PETDM. OCP extensions SHOULD use PETDM when declaring new types.
All OCP Core parameter and message types are declared by using PETDM. OCP extensions SHOULD use PETDM when declaring new types.
Atom, list, structure, and message constructs are four available base types. Their syntax and semantics rules are defined in section 3.1. New types can be declared in PETDM to extend base types semantics by using the following declaration templates. The new semantics rules are meant to be attached to each declaration using prose text.
Atom, list, structure, and message constructs are four available base types. Their syntax and semantics rules are defined in section 3.1. New types can be declared in PETDM to extend base types semantics by using the following declaration templates. The new semantics rules are meant to be attached to each declaration using prose text.
Text in angle brackets "<>" are template placeholders, to be substituted with actual type names or parameter name tokens. Square brackets "[]" surround optional elements such as structure members or message payload.
Text in angle brackets "<>" are template placeholders, to be substituted with actual type names or parameter name tokens. Square brackets "[]" surround optional elements such as structure members or message payload.
o Declaring a new atomic type: <new-type-name>: extends atom;
o Declaring a new atomic type: <new-type-name>: extends atom;
o Declaring a new list with old-type-name items: <new-type-name>: extends list of <old-type-name>; Unless it is explicitly noted otherwise, empty lists are valid and have the semantics of an absent parameter value.
o Declaring a new list with old-type-name items: <new-type-name>: extends list of <old-type-name>; Unless it is explicitly noted otherwise, empty lists are valid and have the semantics of an absent parameter value.
Rousskov Standards Track [Page 25] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov Standards Track [Page 25] RFC 4037 OPES Callout Protocol Core March 2005
o Declaring a new structure with members:
<new-type-name>: extends structure with {
<old-type-nameA> <old-type-nameB> [<old-type-nameC>] ...;
<member-name1>: <old-type-name1>;
<member-name2>: <old-type-name2>;
[<member-name3>: <old-type-name3>];
...
};
o Declaring a new structure with members: <new-type-name>: extends structure with { <old-type-nameA> <old-type-nameB> [<old-type-nameC>] ...; <member-name1>: <old-type-name1>; <member-name2>: <old-type-name2>; [<member-name3>: <old-type-name3>]; ... };
The new structure may have anonymous members and named members. Neither group has to exist. Note that it is always possible for extensions to add more members to old structures without affecting type semantics because unrecognized members are ignored by compliant agents.
The new structure may have anonymous members and named members. Neither group has to exist. Note that it is always possible for extensions to add more members to old structures without affecting type semantics because unrecognized members are ignored by compliant agents.
o Declaring a new message with parameters:
<new-type-name>: extends message with {
<old-type-nameA> <old-type-nameB> [<old-type-nameC>] ...;
<parameter-name1>: <old-type-name1>;
<parameter-name2>: <old-type-name2>;
[<parameter-name3>: <old-type-name3>];
...
};
o Declaring a new message with parameters: <new-type-name>: extends message with { <old-type-nameA> <old-type-nameB> [<old-type-nameC>] ...; <parameter-name1>: <old-type-name1>; <parameter-name2>: <old-type-name2>; [<parameter-name3>: <old-type-name3>]; ... };
The new type name becomes the message name. Just as when a structure is extended, the new message may have anonymous parameters and named parameters. Neither group has to exist. Note that it is always possible for extensions to add more parameters to old messages without affecting type semantics because unrecognized parameters are ignored by compliant agents.
The new type name becomes the message name. Just as when a structure is extended, the new message may have anonymous parameters and named parameters. Neither group has to exist. Note that it is always possible for extensions to add more parameters to old messages without affecting type semantics because unrecognized parameters are ignored by compliant agents.
o Extending a type with more semantics details:
o Extending a type with more semantics details:
<new-type-name>: extends <old-type-name>;
<new-type-name>: extends <old-type-name>;
o Extending a structure- or message-base type:
<new-type-name>: extends <old-type-name> with {
<old-type-nameA> <old-type-nameB> [<old-type-nameC>] ...;
<member-name1>: <old-type-name1>;
<member-name2>: <old-type-name2>;
[<member-name3>: <old-type-name3>];
...
};
New anonymous members are appended to the anonymous members of the
old type, and new named members are merged with named members of the
old type.
o Extending a structure- or message-base type: <new-type-name>: extends <old-type-name> with { <old-type-nameA> <old-type-nameB> [<old-type-nameC>] ...; <member-name1>: <old-type-name1>; <member-name2>: <old-type-name2>; [<member-name3>: <old-type-name3>]; ... }; New anonymous members are appended to the anonymous members of the old type, and new named members are merged with named members of the old type.
Rousskov Standards Track [Page 26] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov Standards Track [Page 26] RFC 4037 OPES Callout Protocol Core March 2005
o Extending a message-base type with payload semantics:
<new-type-name>: extends <old-type-name> with {
...
} and payload;
Any any OCP message can have payload, but only some message types
have known payload semantics. Like any parameter, payload may be
required or optional.
o Extending a message-base type with payload semantics: <new-type-name>: extends <old-type-name> with { ... } and payload; Any any OCP message can have payload, but only some message types have known payload semantics. Like any parameter, payload may be required or optional.
o Extending type semantics without renaming the type: <old-type-name>: extends <namespace>::<old-type-name>; The above template can be used by OCP Core extensions that seek to change the semantics of OCP Core types without renaming them. This technique is essential for extending OCP messages because the message name is the same as the message type name. For example, an SMTP profile for OCP might use the following declaration to extend an Application Message Start (AMS) message with Am-Id, a parameter defined in that profile:
o Extending type semantics without renaming the type: <old-type-name>: extends <namespace>::<old-type-name>; The above template can be used by OCP Core extensions that seek to change the semantics of OCP Core types without renaming them. This technique is essential for extending OCP messages because the message name is the same as the message type name. For example, an SMTP profile for OCP might use the following declaration to extend an Application Message Start (AMS) message with Am-Id, a parameter defined in that profile:
AMS: extends Core::AMS with {
Am-Id: am-id;
};
AMS: extends Core::AMS with { Am-Id: am-id; };
All extended types may be used as replacements of the types they extend. For example, a Negotiation Offer (NO) message uses a parameter of type Features. Features (section 10.12) is a list of feature (section 10.11) items. A Feature is a structure-based type. An OCP extension (e.g., an HTTP application profile) may extend the feature type and use a value of that extended type in a negotiation offer. Recipients that are aware of the extension will recognize added members in feature items and negotiate accordingly. Other recipients will ignore them.
All extended types may be used as replacements of the types they extend. For example, a Negotiation Offer (NO) message uses a parameter of type Features. Features (section 10.12) is a list of feature (section 10.11) items. A Feature is a structure-based type. An OCP extension (e.g., an HTTP application profile) may extend the feature type and use a value of that extended type in a negotiation offer. Recipients that are aware of the extension will recognize added members in feature items and negotiate accordingly. Other recipients will ignore them.
The OCP Core namespace tag is "Core". OCP extensions that declare types MUST define their namespace tags (so that other extensions and documentation can use them in their PETDM declarations).
The OCP Core namespace tag is "Core". OCP extensions that declare types MUST define their namespace tags (so that other extensions and documentation can use them in their PETDM declarations).
9.1. Optional Parameters
9.1. Optional Parameters
Anonymous parameters are positional: The parameter's position (i.e., the number of anonymous parameters to the left) is its "name". Thus, when a structure or message has multiple optional anonymous parameters, parameters to the right can be used only if all parameters to the left are present. The following notation
Anonymous parameters are positional: The parameter's position (i.e., the number of anonymous parameters to the left) is its "name". Thus, when a structure or message has multiple optional anonymous parameters, parameters to the right can be used only if all parameters to the left are present. The following notation
[name1] [name2] [name3] ... [nameN]
[name1] [name2] [name3] ... [nameN]
is interpreted as
is interpreted as
Rousskov Standards Track [Page 27] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov Standards Track [Page 27] RFC 4037 OPES Callout Protocol Core March 2005
[name1 [ name2 [ name3 ... [nameN] ... ]]]
[name1 [ name2 [ name3 ... [nameN] ... ]]]
When an anonymous parameter is added to a structure or message that has optional anonymous parameters, the new parameter has to be optional and can only be used if all old optional parameters are in use. Named parameters do not have these limitations, as they are not positional, but associative; they are identified by their explicit and unique names.
When an anonymous parameter is added to a structure or message that has optional anonymous parameters, the new parameter has to be optional and can only be used if all old optional parameters are in use. Named parameters do not have these limitations, as they are not positional, but associative; they are identified by their explicit and unique names.
10. Message Parameter Types
10. Message Parameter Types
This section defines parameter value types that are used for message definitions (section 11). Before using a parameter value, an OCP agent MUST check whether the value has the expected type (i.e., whether it complies with all rules from the type definition). A single rule violation means that the parameter is invalid. See Section 5 for rules on processing invalid input.
This section defines parameter value types that are used for message definitions (section 11). Before using a parameter value, an OCP agent MUST check whether the value has the expected type (i.e., whether it complies with all rules from the type definition). A single rule violation means that the parameter is invalid. See Section 5 for rules on processing invalid input.
OCP extensions MAY define their own types. If they do, OCP extensions MUST define types with exactly one base format and MUST specify the type of every new protocol element they introduce.
OCP extensions MAY define their own types. If they do, OCP extensions MUST define types with exactly one base format and MUST specify the type of every new protocol element they introduce.
10.1. uri
10.1. uri
uri: extends atom;
uri: extends atom;
Uri (universal resource identifier) is an atom formatted according to URI rules in [RFC2396].
Uri (universal resource identifier) is an atom formatted according to URI rules in [RFC2396].
Often, a uri parameter is used as a unique (within a given scope) identifier. Uni semantics is incomplete without the scope specification. Many uri parameters are URLs. Unless it is noted otherwise, URL identifiers do not imply the existence of a serviceable resource at the location they specify. For example, an HTTP request for an HTTP-based URI identifier may result in a 404 (Not Found) response.
Often, a uri parameter is used as a unique (within a given scope) identifier. Uni semantics is incomplete without the scope specification. Many uri parameters are URLs. Unless it is noted otherwise, URL identifiers do not imply the existence of a serviceable resource at the location they specify. For example, an HTTP request for an HTTP-based URI identifier may result in a 404 (Not Found) response.
10.2. uni
10.2. uni
uni: extends atom;
uni: extends atom;
Uni (unique numeric identifier) is an atom formatted as dec-number and with a value in the [0, 2147483647] range, inclusive.
Uni (unique numeric identifier) is an atom formatted as dec-number and with a value in the [0, 2147483647] range, inclusive.
A uni parameter is used as a unique (within a given scope) identifier. Uni semantics is incomplete without the scope specification. Some OCP messages create identifiers (i.e., bring them into scope). Some OCP messages destroy them (i.e, remove them
A uni parameter is used as a unique (within a given scope) identifier. Uni semantics is incomplete without the scope specification. Some OCP messages create identifiers (i.e., bring them into scope). Some OCP messages destroy them (i.e, remove them
Rousskov Standards Track [Page 28] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov Standards Track [Page 28] RFC 4037 OPES Callout Protocol Core March 2005
from scope). An OCP agent MUST NOT create the same uni value more than once within the same scope. When creating a new identifier of the same type and within the same scope as some old identifier, an OCP agent MUST use a higher numerical value for the new identifier. The first rule makes uni identifiers suitable for cross-referencing logs and other artifacts. The second rule makes efficient checks of the first rule possible.
from scope). An OCP agent MUST NOT create the same uni value more than once within the same scope. When creating a new identifier of the same type and within the same scope as some old identifier, an OCP agent MUST use a higher numerical value for the new identifier. The first rule makes uni identifiers suitable for cross-referencing logs and other artifacts. The second rule makes efficient checks of the first rule possible.
For example, a previously used transaction identifier "xid" must not be used for a new Transaction Start (TS) message within the same OCP transaction, even if a prior Transaction End (TE) message was sent for the same transaction.
For example, a previously used transaction identifier "xid" must not be used for a new Transaction Start (TS) message within the same OCP transaction, even if a prior Transaction End (TE) message was sent for the same transaction.
An OCP agent MUST terminate the state associated with uni uniqueness scope if all unique values have been used up.
An OCP agent MUST terminate the state associated with uni uniqueness scope if all unique values have been used up.
10.3. size
10.3. size
size: extends atom;
size: extends atom;
Size is an atom formatted as dec-number and with a value in the [0, 2147483647] range, inclusive.
Size is an atom formatted as dec-number and with a value in the [0, 2147483647] range, inclusive.
Size value is the number of octets in the associated data chunk.
Size value is the number of octets in the associated data chunk.
OCP Core cannot handle application messages that exceed 2147483647 octets in size, that require larger sizes as a part of OCP marshaling process, or that use sizes with granularity other than 8 bits. This limitation can be addressed by OCP extensions, as hinted in section 15.1.
OCP Core cannot handle application messages that exceed 2147483647 octets in size, that require larger sizes as a part of OCP marshaling process, or that use sizes with granularity other than 8 bits. This limitation can be addressed by OCP extensions, as hinted in section 15.1.
10.4. offset
10.4. offset
offset: extends atom;
offset: extends atom;
Offset is an atom formatted as dec-number and with a value in the [0, 2147483647] range, inclusive.
Offset is an atom formatted as dec-number and with a value in the [0, 2147483647] range, inclusive.
Offset is an octet position expressed in the number of octets relative to the first octet of the associated dataflow. The offset of the first data octet has a value of zero.
Offset is an octet position expressed in the number of octets relative to the first octet of the associated dataflow. The offset of the first data octet has a value of zero.
10.5. percent
10.5. percent
percent: extends atom;
percent: extends atom;
Percent is an atom formatted as dec-number and with a value in the [0, 100] range, inclusive.
Percent is an atom formatted as dec-number and with a value in the [0, 100] range, inclusive.
Rousskov Standards Track [Page 29] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov Standards Track [Page 29] RFC 4037 OPES Callout Protocol Core March 2005
Percent semantics is incomplete unless its value is associated with a boolean statement or assertion. The value of 0 indicates absolute impossibility. The value of 100 indicates an absolute certainty. In either case, the associated statement can be relied upon as if it were expressed in boolean rather than probabilistic terms. Values in the [1,99] inclusive range indicate corresponding levels of certainty that the associated statement is true.
Percent semantics is incomplete unless its value is associated with a boolean statement or assertion. The value of 0 indicates absolute impossibility. The value of 100 indicates an absolute certainty. In either case, the associated statement can be relied upon as if it were expressed in boolean rather than probabilistic terms. Values in the [1,99] inclusive range indicate corresponding levels of certainty that the associated statement is true.
10.6. boolean
10.6. boolean
boolean: extends atom;
boolean: extends atom;
Boolean type is an atom with two valid values: true and false. A boolean parameter expresses the truthfulness of the associated statement.
Boolean type is an atom with two valid values: true and false. A boolean parameter expresses the truthfulness of the associated statement.
10.7. xid
10.7. xid
xid: extends uni;
xid: extends uni;
Xid, an OCP transaction identifier, uniquely identifies an OCP transaction within an OCP connection.
Xid, an OCP transaction identifier, uniquely identifies an OCP transaction within an OCP connection.
10.8. sg-id
10.8. sg-id
sg-id: extends uni;
sg-id: extends uni;
Sg-id, a service group identifier, uniquely identifies a group of services on an OCP connection.
Sg-id, a service group identifier, uniquely identifies a group of services on an OCP connection.
10.9. modp
10.9. modp
modp: extends percent;
modp: extends percent;
Modp extends the percent type to express the sender's confidence that application data will be modified. The boolean statement associated with the percentage value is "data will be modified". Modification is defined as adaptation that changes the numerical value of at least one data octet.
Modp extends the percent type to express the sender's confidence that application data will be modified. The boolean statement associated with the percentage value is "data will be modified". Modification is defined as adaptation that changes the numerical value of at least one data octet.
10.10. result
10.10. result
result: extends structure with {
atom [atom];
};
result: extends structure with { atom [atom]; };
The OCP processing result is expressed as a structure with two documented members: a required Uni status code and an optional
The OCP processing result is expressed as a structure with two documented members: a required Uni status code and an optional
Rousskov Standards Track [Page 30] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov Standards Track [Page 30] RFC 4037 OPES Callout Protocol Core March 2005
reason. The reason member contains informative textual information not intended for automated processing. For example:
reason. The reason member contains informative textual information not intended for automated processing. For example:
{ 200 OK }
{ 200 "6:got it" }
{ 200 "27:27 octets in UTF-8 encoding" }
{ 200 OK } { 200 "6:got it" } { 200 "27:27 octets in UTF-8 encoding" }
This specification defines the following status codes:
This specification defines the following status codes:
Result Status Codes
Result Status Codes
+--------+--------------+-------------------------------------------+ | code | text | semantics | +--------+--------------+-------------------------------------------+ | 200 | OK | Overall success. This specification does | | | | not contain any general actions for a 200 | | | | status code recipient. | | 206 | partial | Partial success. This status code is | | | | documented for Application Message End | | | | (AME) messages only. The code indicates | | | | that the agent terminated the | | | | corresponding dataflow prematurely (i.e., | | | | more data would be needed to reconstruct | | | | a complete application message). | | | | Premature termination of one dataflow | | | | does not introduce any special | | | | requirements for the other dataflow | | | | termination. See dataflow termination | | | | optimizations (section 8) for use cases. | | 400 | failure | An error, exception, or trouble. A | | | | recipient of a 400 (failure) result of an | | | | AME, TE, or CE message MUST destroy any | | | | state or data associated with the | | | | corresponding dataflow, transaction, or | | | | connection. For example, an adapted | | | | version of the application message data | | | | must be purged from the processor | | | | cache if the OPES processor receives an | | | | Application Message End (AME) message | | | | with result code of 400. | +--------+--------------+-------------------------------------------+
+--------+--------------+-------------------------------------------+ | コード| テキスト| 意味論| +--------+--------------+-------------------------------------------+ | 200 | OK| 総合的な成功。 この仕様はそうします。| | | | 200のための少しの一般的な動作も含んでいません。| | | | ステータスコード受取人。 | | 206 | 部分的| 部分的な成功。 このステータスコードはそうです。| | | | Application Message Endのために、記録されます。| | | | (AME) メッセージ専用。 コードは示します。| | | | エージェントは終えました。| | | | 対応するデータフロー、早まって、(| | | | すなわち、より多くのデータが|再建するのに必要でしょう| | | 完全なアプリケーションメッセージ。) | | | | 1つのデータフローの未完熟終了| | | | どんな特別番組も紹介しません。| | | | もう片方のデータフローのための要件| | | | 終了。 データフロー終了を見てください。| | | | 使用のための(セクション8)がケースに入れる最適化。 | | 400 | 失敗| 誤り、例外、または問題。 A| | | | 400(失敗)が結果になるaの受取人| | | | AME、TE、またはCEメッセージがいずれも破壊しなければなりません。| | | | 交際した状態かデータ| | | | または対応するデータフロー、トランザクション。| | | | 接続。 例えば、適合| | | | アプリケーションメッセージデータのバージョン| | | | プロセッサを追放しなければなりません。| | | | 作品プロセッサが受信されるなら、キャッシュします。| | | | アプリケーションMessage End(AME)メッセージ| | | | 400の結果コードで。 | +--------+--------------+-------------------------------------------+
Specific OCP messages may require code-specific actions.
特定のOCPメッセージはコード特有の動作を必要とするかもしれません。
Extending result semantics is made possible by adding new "result" structure members or by negotiating additional result codes (e.g., as a part of a negotiated profile). A recipient of an unknown (in
新しい「結果」構造メンバーを加えるか、または追加結果コード(例えば、交渉されたプロフィールの一部としての)を交渉することによって、結果意味論について敷衍するのを可能にします。 中未知の受取人、(。
Rousskov Standards Track [Page 31] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[31ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
then-current context) result code MUST act as if code 400 (failure) were received.
次に、現在の背景) 結果コードはまるでコード400(失敗)を受け取るかのように行動しなければなりません。
The recipient of a message without the actual result parameter, but with an optional formal result parameter, MUST act as if code 200 (OK) were received.
実際の結果パラメタ、任意の正式な結果パラメタがあるメッセージの受取人はまるでコード200(OK)を受け取るかのように行動しなければなりません。
Textual information (the second anonymous parameter of the result structure) is often referred to as "reason" or "reason phrase". To assist manual troubleshooting efforts, OCP agents are encouraged to include descriptive reasons with all results indicating a failure.
文字情報(結果構造の2番目の匿名のパラメタ)はしばしば「理由」か「理由句」と呼ばれます。 手動のトラブルシューティング取り組みを補助するために、OCPエージェントがすべての結果が失敗を示している描写的である理由を含んでいるよう奨励されます。
In this specification, an OCP message with result status code of 400 (failure) is called "a message indicating a failure".
この仕様では、400(失敗)の結果ステータスコードがあるOCPメッセージは「失敗を示すメッセージ」と呼ばれます。
10.11. feature
10.11. 特徴
feature: extends structure with {
uri;
};
以下を特集してください。 構造を広げている、uri;、。
The feature type extends structure to relay an OCP feature identifier and to reserve a "place" for optional feature-specific parameters (sometimes called feature attributes). Feature values are used to declare support for and to negotiate use of OCP features.
特徴タイプは、OCP特徴識別子をリレーして、任意の特徴特有のパラメタ(時々特徴属性と呼ばれる)のために「場所」を予約するために構造を広げています。 特徴値は、候補の支持にまわって、OCPの特徴の使用を交渉するのに使用されます。
This specification does not define any features.
この仕様はどんな特徴も定義しません。
10.12. features
10.12. 特徴
features: extends list of feature;
特徴: 特徴のリストを広げています。
Features is a list of feature values. Unless it is noted otherwise, the list can be empty, and features are listed in decreasing preference order.
特徴は特徴値のリストです。 それが別の方法で注意されない場合、リストは空である場合があります、そして、特徴は減少している好みの命令にリストアップされています。
10.13. service
10.13. サービス
service: extends structure with {
uri;
};
サービス: 構造を広げている、uri;、。
Service structure has one anonymous member, an OPES service identifier of type uri. Services may have service-dependent parameters. An OCP extension defining a service for use with OCP MUST define service identifier and service-dependent parameters, if there are any, as additional "service" structure members. For example, a service value may look like this:
サービス構造には、1人の匿名のメンバー、タイプuriに関する作品サービス識別子があります。 サービスには、サービス依存するパラメタがあるかもしれません。 OCP MUSTとの使用のためのサービスを定義するOCP拡張子はサービス識別子とサービス依存するパラメタを定義します、いずれかあれば、追加「サービス」構造メンバーとして。 例えば、サービス値はこれに似るかもしれません:
Rousskov Standards Track [Page 32] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[32ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
{"41:http://www.iana.org/assignments/opes/ocp/tls" "8:blowfish"}
「41、: http://www.iana.org/assignments/opes/ocp/tls 、」、「8、: フグ、」
10.14. services
10.14. サービス
services: extends list of service;
サービス: サービスのリストを広げています。
Services is a list of service values. Unless it is noted otherwise, the list can be empty, and the order of the values is the requested or actual service application order.
サービスはサービス値のリストです。 それが別の方法で注意されない場合、リストは空である場合があります、そして、値の注文は要求されたか実際のサービスアプリケーション命令です。
10.15. Dataflow Specializations
10.15. データフロー専門化
Several parameter types, such as offset apply to both original and adapted dataflow. It is relatively easy to misidentify a type's dataflow affiliation, especially when parameters with different affiliations are mixed together in one message declaration. The following statements declare new dataflow-specific types by using their dataflow-agnostic versions (denoted by a <type> placeholder).
相殺されるような数人のパラメータの型がオリジナルの、そして、適合の両方であっているデータフローに当てはまります。 タイプのデータフロー提携を誤認するのは比較的簡単です、特に異なった提携があるパラメタが1つのメッセージ宣言で一緒に複雑であるときに。 以下の声明は、彼らのデータフロー不可知論者バージョン(<タイプ>プレースホルダで、指示される)を使用することによって、新しいデータフロー特定のタイプを宣言します。
The following new types refer to original data only:
以下の新しいタイプはオリジナルのデータだけを示します:
org-<type>: extends <type>;
org-<は>をタイプします: <タイプ>を広げています。
The following new types refer to adapted data only:
新しいタイプが言及する以下はデータだけを適合させました:
adp-<type>: extends <type>;
adp-<は>をタイプします: <タイプ>を広げています。
The following new types refer to the sender's dataflow only:
以下の新しいタイプは送付者のデータフローだけを示します:
my-<type>: extends <type>;
私、-<は>をタイプします: <タイプ>を広げています。
The following new types refer to the recipient's dataflow only:
以下の新しいタイプは受取人のデータフローだけを示します:
your-<type>: extends <type>;
あなた、-<は>をタイプします: <タイプ>を広げています。
OCP Core uses the above type-naming scheme to implement dataflow specialization for the following types: offset, size, and sg-id. OCP extensions SHOULD use the same scheme.
OCP Coreは以下のタイプのためにデータフロー専門化を実装するのに上のタイプを命名する体系を使用します: オフセット、サイズ、およびsg-イド。 OCP拡大SHOULDは同じ体系を使用します。
11. Message Definitions
11. メッセージ定義
This section describes specific OCP messages. Each message is given a unique name and usually has a set of anonymous and/or named parameters. The order of anonymous parameters is specified in the message definitions below. No particular order for named parameters is implied by this specification. OCP extensions MUST NOT introduce order-dependent named parameters. No more than one named-parameter
このセクションは特定のOCPメッセージについて説明します。 各メッセージは、ユニークな名前を与えて、通常、1セットの匿名の、そして/または、命名されたパラメタを持っています。 以下でのメッセージ定義で匿名のパラメタの注文を指定します。 この仕様で命名されたパラメタのどんな特定の注文も含意しません。 OCP拡張子はオーダー依存する命名されたパラメタを紹介してはいけません。 1つ未満の命名されたパラメタ
Rousskov Standards Track [Page 33] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[33ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
with a given name can appear in the message; messages with multiple equally named parameters are semantically invalid.
名と共にメッセージに現れることができます。 複数の等しく命名されたパラメタがあるメッセージは意味的に無効です。
A recipient MUST be able to parse any message in valid format (see section 3.1), subject to the limitations of the recipient's resources.
受取人のリソースの制限を条件として受取人は有効な形式(セクション3.1を見る)でどんなメッセージも分析できなければなりません。
Unknown or unexpected message names, parameters, and payloads may be valid extensions. For example, an "extra" named parameter may be used for a given message, in addition to what is documented in the message definition below. A recipient MUST ignore any valid but unknown or unexpected name, parameter, member, or payload.
未知の、または、予期していなかったメッセージ名、パラメタ、およびペイロードは有効な拡大であるかもしれません。 例えば、命名された「付加的な」パラメタは与えられたメッセージに使用されるかもしれません、以下でのメッセージ定義に記録されることに加えて。 受取人はどんな有効な、しかし、未知の、または、予期していなかった名前、パラメタ、メンバー、またはペイロードも無視しなければなりません。
Some message parameter values use uni identifiers to refer to various OCP states (see section 10.2 and Appendix B). These identifiers are created, used, and destroyed by OCP agents via corresponding messages. Except when creating a new identifier, an OCP agent MUST NOT send a uni identifier that corresponds to an inactive state (i.e., that was either never created or already destroyed). Such identifiers invalidate the host OCP message (see section 5). For example, the recipient must terminate the transaction when the xid parameter in a Data Use Mine (DUM) message refers to an unknown or already terminated OCP transaction.
いくつかのメッセージパラメタ値が、様々なOCP州について言及するのにuni識別子を使用します(セクション10.2とAppendix Bを見てください)。 これらの識別子は、対応するメッセージでOCPエージェントによって作成されて、使用されて、無効にされます。 新しい識別子を作成する時以外に、OCPエージェントは不活発な状態に対応するuni識別子を送ってはいけません(すなわち、それは、決して作成されなかったか、または既に破壊されました)。 そのような識別子はホストOCPメッセージを無効にします(セクション5を見てください)。 Data Use Mine(DUM)メッセージのxidパラメタが未知の、または、既に終えられたOCPトランザクションについて言及するとき、例えば、受取人はトランザクションを終えなければなりません。
11.1. Connection Start (CS)
11.1. 接続始め(Cs)
CS: extends message;
Cs: メッセージを広げています。
A Connection Start (CS) message indicates the start of an OCP connection. An OCP agent MUST send this message before it sends any other message on the connection. If the first message an OCP agent receives is not Connection Start (CS), the agent MUST terminate the connection with a Connection End (CE) message having 400 (failure) result status code. An OCP agent MUST send Connection Start (CS) message exactly once. An OCP agent MUST ignore repeated Connection Start (CS) messages.
Connection Start(CS)メッセージはOCP接続の始まりを示します。 いかなる他のメッセージも接続に送る前にOCPエージェントはこのメッセージを送らなければなりません。 OCPエージェントが受け取る最初のメッセージがConnection Start(CS)でないなら、エージェントは400(失敗)結果ステータスコードを持っているConnection End(CE)メッセージとの関係を終えなければなりません。 OCPエージェントはまさに一度Connection Start(CS)メッセージを送らなければなりません。 OCPエージェントは繰り返されたConnection Start(CS)メッセージを無視しなければなりません。
At any time, a callout server MAY refuse further processing on an OCP connection by sending a Connection End (CE) message with the status code 400 (failure). Note that the above requirement to send a CS message first still applies.
いつでも、calloutサーバは、OCP接続のときにステータスコード400(失敗)があるConnection End(CE)メッセージを送ることによって、さらなる処理を拒否するかもしれません。 最初にCSメッセージを送るという上記の要件がまだ適用されていることに注意してください。
With TCP/IP as transport, raw TCP connections (local and remote peer IP addresses with port numbers) identify an OCP connection. Other transports may provide OCP connection identifiers to distinguish logical connections that share the same transport. For example, a single BEEP [RFC3080] channel may be designated as a single OCP connection.
輸送としてのTCP/IPで、未熟なTCP接続(ポートナンバーがある地方の、そして、リモートな同輩IPアドレス)はOCP接続を特定します。 他の輸送は、同じ輸送を共有する論理的な接続を区別するために接続識別子をOCPに供給するかもしれません。 例えば、独身のBEEP[RFC3080]チャンネルは単独のOCP接続として任命されるかもしれません。
Rousskov Standards Track [Page 34] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[34ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
11.2. Connection End (CE)
11.2. 接続終わり(Ce)
CE: extends message with {
[result];
};
Ce: メッセージを広げている、[結果];、。
A Connection End (CE) Indicates the end of an OCP connection. The agent initiating closing or termination of a connection MUST send this message immediately prior to closing or termination. The recipient MUST free associated state, including transport state.
Connection End(CE)はOCP接続の終わりを示します。 接続の閉鎖か終了を開始するエージェントは閉鎖か終了のすぐ前にこのメッセージを送らなければなりません。 受取人は輸送状態を含む準国家を解放しなければなりません。
Connection termination without a Connection End (CE) message indicates that the connection was prematurely closed, possibly without the closing-side agent's prior knowledge or intent. When an OCP agent detects a prematurely closed connection, the agent MUST act as if a Connection End (CE) message indicating a failure was received.
Connection End(CE)メッセージのない接続終了は、接続が早まって閉店したのを示します、ことによると終わりのサイドエージェントの先の知識も意図なしで。 OCPエージェントが早まって閉じている接続を検出するとき、エージェントはまるで失敗を示すConnection End(CE)メッセージを受け取るかのように行動しなければなりません。
A Connection End (CE) message implies the end of all transactions, negotiations, and service groups opened or active on the connection being ended.
Connection End(CE)メッセージは終わる接続のときに開かれるか、またはアクティブな状態ですべてのトランザクション、交渉、およびサービスグループの終わりを含意します。
11.3. Service Group Created (SGC)
11.3. 創設されたサービスグループ(SGC)
SGC: extends message with {
my-sg-id services;
};
SGC: メッセージを広げている、私のsgイドサービス;、。
A Service Group Created (SGC) message informs the recipient that a
list of adaptation services has been associated with the given
service group identifier ("my-sg-id"). Following this message, the
sender can refer to the group by using the identifier. The recipient
MUST maintain the association until a matching Service Group
Destroyed (SGD) message is received or the corresponding OCP
connection is closed.
Service Group Created(SGC)メッセージは適合サービスのリストがそうである受取人に与えられたサービスグループ識別子に関連していた状態で知らせます(「私のsgイド」)。 このメッセージに従って、送付者は、識別子を使用することによって、グループを参照できます。 合っているService Group Destroyed(SGD)メッセージが受信されているか、または対応するOCP接続が閉じられるまで、受取人は協会を維持しなければなりません。
Service groups have a connection scope. Transaction management messages do not affect existing service groups.
サービスグループには、接続範囲があります。 トランザクション管理メッセージは既存のサービスグループに影響しません。
Maintaining service group associations requires resources (e.g., storage to keep the group identifier and a list of service IDs). Thus, there is a finite number of associations an implementation can maintain. Callout servers MUST be able to maintain at least one association for each OCP connection they accept. If a recipient of a Service Group Created (SGC) message does not create the requested association, it MUST immediately terminate the connection with a Connection End (CE) message indicating a failure.
サービスグループ協会を維持するのはリソース(例えば、グループ識別子とサービスIDのリストを保つストレージ)を必要とします。 したがって、実装が維持できる協会の有限数があります。 Calloutサーバはそれらが受け入れるそれぞれのOCP接続あたり少なくとも1つの協会を維持できなければなりません。 Service Group Created(SGC)メッセージの受取人が要求された協会を創設しないなら、それはすぐに、失敗を示すConnection End(CE)メッセージとの関係を終えなければなりません。
Rousskov Standards Track [Page 35] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[35ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
11.4. Service Group Destroyed (SGD)
11.4. 破壊されたサービスグループ(SGD)
SGD: extends message with {
my-sg-id;
};
SGD: メッセージを広げている、私のsgイド;、。
A Service Group Destroyed (SGD) message instructs the recipient to forget about the service group associated with the specified identifier. The recipient MUST destroy the identified service group association.
Service Group Destroyed(SGD)メッセージは、指定された識別子に関連しているサービスグループを忘れるよう受取人に命令します。 受取人は特定されたサービスグループ協会を破壊しなければなりません。
11.5. Transaction Start (TS)
11.5. トランザクション始め(ts)
TS: extends message with {
xid my-sg-id;
};
t: メッセージを広げている、私のxid sgイド;、。
Sent by an OPES processor, a Transaction Start (TS) message indicates the start of an OCP transaction. Upon receiving this message, the callout server MAY refuse further transaction processing by responding with a corresponding Transaction End (TE) message. A callout server MUST maintain the state until it receives a message indicating the end of the transaction or until it terminates the transaction itself.
作品プロセッサで送って、Transaction Start(TS)メッセージはOCPトランザクションの始まりを示します。 このメッセージを受け取ると、calloutサーバは、対応するTransaction End(TE)メッセージで応じることによって、さらなるトランザクション処理を拒否するかもしれません。 トランザクションの終わりを示すメッセージを受け取るか、またはトランザクション自体を終えるまで、calloutサーバは状態を維持しなければなりません。
The required "my-sg-id" identifier refers to a service group created with an a Service Group Created (SGC) message. The callout server MUST apply the list of services associated with "my-sg-id", in the specified order.
「私のsgイド」識別子が参照する必要はService Group Created(SGC)と共にサービスグループにメッセージを作成しました。 calloutサーバは指定されたオーダーにおける「私のsgイド」に関連しているサービスのリストを当てはまらなければなりません。
This message introduces the transaction identifier (xid).
このメッセージはトランザクション識別子(xid)を紹介します。
11.6. Transaction End (TE)
11.6. トランザクション終わり(Te)
TE: extends message with {
xid [result];
};
Te: メッセージを広げている、xid[結果];、。
A Transaction End (TE) indicates the end of the identified OCP transaction.
Transaction End(TE)は特定されたOCPトランザクションの終わりを示します。
An OCP agent MUST send a Transaction End (TE) message immediately after it makes a decision to send no more messages related to the corresponding transaction. Violating this requirement may cause, for
関連しないそれ以上のメッセージを全く送るという決定を対応するトランザクションにする直後OCPエージェントはTransaction End(TE)メッセージを送らなければなりません。 この要件が引き起こすかもしれない違反
Rousskov Standards Track [Page 36] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[36ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
example, unnecessary delays, rejection of new transactions, and even timeouts for agents that rely on this end-of-file condition to proceed.
続くこのファイル終了条件を当てにする例、不要な遅れ、新しいトランザクションの拒絶、およびエージェントのためのタイムアウトさえ。
This message terminates the life of the transaction identifier (xid).
このメッセージはトランザクション識別子(xid)の寿命を終えます。
11.7. Application Message Start (AMS)
11.7. アプリケーションメッセージ始め(AMS)
AMS: extends message with {
xid;
[Services: services];
};
AMS: xid[サービス: サービス]でメッセージを広げています。
An Application Message Start (AMS) message indicates the start of the original or adapted application message processing and dataflow. The recipient MAY refuse further processing by sending an Application Message End (AME) message indicating a failure.
Application Message Start(AMS)メッセージはオリジナルの、または、適合しているアプリケーションメッセージ処理とデータフローの始まりを示します。 Application Message End(AME)メッセージに失敗を示させることによって、受取人はさらなる処理を拒否するかもしれません。
When an AMS message is sent by the OPES processor, the callout server usually sends an AMS message back, announcing the creation of an adapted version of the original application message. This announcement may be delayed. For example, the callout server may wait for more information from the OPES processor.
作品プロセッサでAMSメッセージを送るとき、通常、calloutサーバはAMSメッセージを返送します、原出願メッセージの適合しているバージョンの作成を発表して。 この発表は遅れるかもしれません。 例えば、calloutサーバは作品プロセッサからの詳しい情報を待つかもしれません。
When an AMS message is sent by the callout server, an optional "Services" parameter describes OPES services that the server MAY apply to the original application message. Usually, the "services" value matches what was asked by the OPES processor. The callout server SHOULD send a "Services" parameter if its value would differ from the list of services requested by the OPES processor. As the same service may be known under many names, the mismatch does not necessarily imply an error.
calloutサーバでAMSメッセージを送るとき、任意の「サービス」パラメタはサーバが原出願メッセージに適用するかもしれない作品サービスについて説明します。 通常、「サービス」値は作品プロセッサによって尋ねられたことに合っています。 値が作品プロセッサによって要求されたサービスのリストと異なっているなら、calloutサーバSHOULDは「サービス」パラメタを送ります。 同じサービスが多くの名前の下で知られているかもしれないように、ミスマッチは必ず誤りを含意するというわけではありません。
11.8. Application Message End (AME)
11.8. アプリケーションメッセージ終わり(AME)
AME: extends message with {
xid [result];
};
AME: メッセージを広げている、xid[結果];、。
An Application Message End (AME) message indicates the end of the original or adapted application message processing and dataflow. The recipient should expect no more data for the corresponding application message.
Application Message End(AME)メッセージはオリジナルの、または、適合しているアプリケーションメッセージ処理とデータフローの終わりを示します。 受取人は対応するアプリケーションメッセージのためのそれ以上のデータを全く予想するべきではありません。
An Application Message End (AME) message ends any data preservation commitments and any other state associated with the corresponding application message.
Application Message End(AME)メッセージはどんなデータ保存委任と対応するアプリケーションメッセージに関連しているいかなる他の状態も終わらせます。
Rousskov Standards Track [Page 37] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[37ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
An OCP agent MUST send an Application Message End (AME) message immediately after it makes a decision to stop processing of its application message. Violating this requirement may cause, for example, unnecessary delays, rejection of new transactions, and even timeouts for agents that rely on this end-of-file condition to proceed.
アプリケーションメッセージの停止処理に決定する直後OCPエージェントはApplication Message End(AME)メッセージを送らなければなりません。 この要件に違反すると、続くこのファイル終了条件を当てにする例えば、不要な遅れ、新しいトランザクションの拒絶、およびエージェントのためのタイムアウトさえ引き起こされるかもしれません。
11.9. Data Use Mine (DUM)
11.9. データは私のものを使用します。(DUM)
DUM: extends message with {
xid my-offset;
[As-is: org-offset];
[Kept: org-offset org-size ];
[Modp: modp];
} and payload;
DUM: そして、メッセージを広げている、xid、私、-相殺してください、;、[そのままである、: org-オフセット] ; [: org-オフセットorg-サイズであることが保たれます]; [Modp: modp];、ペイロード。
A Data Use Mine (DUM) message carries application data. It is the only OCP Core message with a documented payload. The sender MUST NOT make any gaps in data supplied by Data Use Mine (DUM) and Data Use Yours (DUY) messages (i.e., the my-offset of the next data message must be equal to the my-offset plus the payload size of the previous data message). Messages with gaps are invalid. The sender MUST send payload and MAY use empty payload (i.e., payload with zero size). A DUM message without payload is invalid. Empty payloads are useful for communicating meta-information about the data (e.g., modification predictions or preservation commitments) without sending data.
Data Use Mine(DUM)メッセージはアプリケーションデータを運びます。 それは記録されたペイロードがある唯一のOCP Coreメッセージです。 すなわち、送付者がData Use Mine(DUM)とData Use Yours(DUY)メッセージからデータのどんな不足も供給させてはいけない、(私、-相殺してください、次のデータメッセージが等しいに違いない、私、-相殺してください、前のデータのペイロードサイズが通信させるプラス) ギャップがあるメッセージは無効です。 送付者は、ペイロードを送らなければならなくて、空のペイロード(すなわち、サイズがないペイロード)を使用するかもしれません。 ペイロードのないDUMメッセージは無効です。 空のペイロードは送付データなしでデータ(例えば、変更予測か保存委任)のメタ情報を伝えることの役に立ちます。
An OPES processor MAY send a "Kept" parameter to indicate its current data preservation commitment (section 7) for original data. When an OPES processor sends a "Kept" parameter, the processor MUST keep a copy of the specified data (the preservation commitment starts or continues). The Kept offset parameter specifies the offset of the first octet of the preserved data. The Kept size parameter is the size of preserved data. Note that data preservation rules allow (i.e., do not prohibit) an OPES processor to decrease offset and to specify a data range not yet fully delivered to the callout server. OCP Core does not require any relationship between DUM payload and the "Kept" parameter.
作品プロセッサは、オリジナルのデータのために、現在のデータ保存委任(セクション7)を示すために「保たれた」パラメタを送るかもしれません。 作品プロセッサが「保たれた」パラメタを送るとき、プロセッサは指定されたデータの写しを取っておかなければなりません(保存委任は、始まるか、または続きます)。 Keptオフセットパラメタは保存されたデータの最初の八重奏のオフセットを指定します。 Keptサイズ・パラメータは保存されたデータのサイズです。 減少させる作品プロセッサは相殺されました、そして、データ範囲を指定するのはまだ完全にcalloutサーバに配送されたというわけではありません。すなわち、保存規則が許容するそのデータに注意してください、(禁止しない、)、OCP CoreはDUMペイロードと「保たれた」パラメタとの少しの関係も必要としません。
If the "Kept" parameter value violates data preservation rules but the recipient has not sent any Data Use Yours (DUY) messages for the given OCP transaction yet, then the recipient MUST NOT use any preserved data for the given transaction (i.e., must not sent any Data Use Yours (DUY) messages). If the "Kept" parameter value violates data preservation rules and the recipient has already sent Data Use Yours (DUY) messages, the DUM message is invalid, and the rules of section 5 apply. These requirements help preserve data integrity when "Kept" optimization is used by the OPES processor.
「保たれた」パラメタ値がデータ保存規則に違反しますが、受取人がまだどんなData Use Yours(DUY)にも与えられたOCPトランザクションへのメッセージを送らないなら、受取人は与えられたトランザクション(すなわち、どんなData Use Yours(DUY)メッセージも送られないで、そうしなければならない)に少しの保存されたデータも使用してはいけません。 「保たれた」パラメタ値がデータ保存規則に違反して、受取人が既にData Use Yours(DUY)にメッセージを送ったなら、DUMメッセージは無効です、そして、セクション5の規則は適用されます。 これらの要件は、「保たれた」最適化が作品プロセッサによって使用されるとき、データ保全を保存するのを助けます。
Rousskov Standards Track [Page 38] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[38ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
A callout server MUST send a "Modp" parameter if the server can provide a reliable value and has not already sent the same parameter value for the corresponding application message. The definition of "reliable" is entirely up to the callout server. The data modification prediction includes DUM payload. That is, if the attached payload has been modified, the modp value cannot be 0%.
サーバが信頼できる値を提供できて、対応するアプリケーションメッセージのために既に同じパラメタ値を送らないなら、calloutサーバは"Modp"パラメタを送らなければなりません。 「信頼できること」の定義は完全にcalloutサーバまで達しています。データ変更予測はDUMペイロードを含んでいます。 すなわち、付属ペイロードが変更されたなら、modp値は0%であるはずがありません。
A callout server SHOULD send an "As-is" parameter if the attached data is identical to a fragment at the specified offset in the original dataflow. An "As-is" parameter specifying a data fragment that has not been sent to the callout server is invalid. The recipient MUST ignore invalid "As-is" parameters. Identical means that all adapted octets have the same numeric value as the corresponding original octets. This parameter is meant to allow for partial data preservation optimizations without a preservation commitment. The preserved data still crosses the connection with the callout server twice, but the OPES processor may be able to optimize its handling of the data.
添付のデータが指定の断片と同じであるなら、SHOULDが「そのままで」というパラメタを送るcalloutサーバはオリジナルのデータフローで相殺されました。 「そのままで」というcalloutサーバに送られないデータ断片を指定するパラメタは無効です。 受取人は「そのままで」という無効のパラメタを無視しなければなりません。 八重奏を適合させた同じ手段がすべて、対応するオリジナルの八重奏と同じ数値を持っています。 このパラメタは保存委任なしで部分的なデータ保存最適化を考慮することになっています。 保存されたデータはまだcalloutサーバとの関係に二度交差していますが、作品プロセッサはデータの取り扱いを最適化できるかもしれません。
The OPES processor MUST NOT terminate its data preservation commitment (section 7) in reaction to receiving a Data Use Mine (DUM) message.
作品プロセッサはData Use Mine(DUM)メッセージを受け取ることへの反応でデータ保存委任(セクション7)を終えてはいけません。
11.10. Data Use Yours (DUY)
11.10. データはあなたのものを使用します。(DUY)
DUY: extends message with {
xid org-offset org-size;
};
DUY: メッセージを広げている、xid org-オフセットorg-サイズ;、。
The callout server tells the OPES processor to use the "size" bytes of preserved original data, starting at the specified offset, as if that data chunk came from the callout server in a Data Use Mine (DUM) message.
calloutサーバは、保存されたオリジナルのデータの「サイズ」バイトを使用するように作品プロセッサに言います、指定されたオフセットから、まるでそのデータ塊がData Use Mine(DUM)メッセージのcalloutサーバから来るかのように。
The OPES processor MUST NOT terminate its data preservation commitment (section 7) in reaction to receiving a Data Use Yours (DUY) message.
作品プロセッサはData Use Yours(DUY)メッセージを受け取ることへの反応でデータ保存委任(セクション7)を終えてはいけません。
11.11. Data Preservation Interest (DPI)
11.11. データ保存関心(dpi)
DPI: extends message with {
xid org-offset org-size;
};
dpi: メッセージを広げている、xid org-オフセットorg-サイズ;、。
The Data Preservation Interest (DPI) message describes an original data chunk by using the first octet offset and size as parameters. The chunk is the only area of original data that the callout server may be interested in referring to in future Data Use Yours (DUY)
Data Preservation Interest(DPI)メッセージは、パラメタとして最初の八重奏オフセットとサイズを使用することによって、オリジナルのデータ塊について説明します。 塊は言及するcalloutサーバが将来のData Use Yoursで関心があるかもしれないオリジナルのデータの唯一の領域です。(DUY)
Rousskov Standards Track [Page 39] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[39ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
messages. This data chunk is referred to as "reusable data". The rest of the original data is referred to as "disposable data". Thus, disposable data consists of octets below the specified offset and at or above the (offset + size) offset.
メッセージ。 このデータ塊は「再利用できるデータ」と呼ばれます。 オリジナルのデータの残りは「使い捨てのデータ」と呼ばれます。 したがって、使い捨てのデータはオフセットにおいて、または、指定されたオフセットと(オフセット+サイズ)オフセットを超えて八重奏から成ります。
After sending this message, the callout server MUST NOT send Data Use Yours (DUY) messages referring to disposable data chunk(s). If an OPES processor is not preserving some reusable data, it MAY start preserving that data. If an OPES processor preserves some disposable data, it MAY stop preserving that data. If an OPES processor does not preserve some disposable data, it MAY NOT start preserving that data.
このメッセージを送った後に、calloutサーバで、Data Use Yours(DUY)メッセージは使い捨てのデータ塊について言及してはいけません。 作品プロセッサがいくつかの再利用できるデータを保存していないなら、それは、そのデータを保存し始めるかもしれません。 作品プロセッサがいくつかの使い捨てのデータを保存するなら、それは、そのデータを保存するのを止めるかもしれません。 作品プロセッサがいくつかの使い捨てのデータを保存しないなら、それは、そのデータを保存し始めないかもしれません。
A callout server MUST NOT indicate reusable data areas that overlap with disposable data areas indicated in previous Data Preservation Interest (DPI) messages. In other words, reusable data must not grow, and disposable data must not shrink. If a callout server violates this rule, the Data Preservation Interest (DPI) message is invalid (see section 5).
calloutサーバは前のData Preservation Interest(DPI)メッセージで示される使い捨てのデータ領域に重なる再利用できるデータ領域を示してはいけません。 言い換えれば、再利用できるデータは成長してはいけません、そして、使い捨てのデータは縮小してはいけません。 calloutサーバがこの規則に違反するなら、Data Preservation Interest(DPI)メッセージは無効です(セクション5を見てください)。
The Data Preservation Interest (DPI) message cannot force the OPES processor to preserve data. In this context, the term reusable stands for callout server interest in reusing the data in the future, given the OPES processor cooperation.
Data Preservation Interest(DPI)メッセージによって、作品プロセッサはやむを得ずデータを保存できません。 このような関係においては、再利用できるという用語は将来データを再利用することへのcalloutサーバ関心を表します、作品プロセッサ協力を考えて。
For example, an offset value of zero and the size value of 2147483647 indicate that the server may want to reuse all the original data. The size value of zero indicates that the server is not going to send any more Data Use Yours (DUY) messages.
例えば、ゼロのオフセット値と2147483647のサイズ値は、サーバがすべてのオリジナルのデータを再利用したがっているかもしれないのを示します。 ゼロのサイズ値は、サーバがそれ以上のData Use Yours(DUY)にメッセージを送らないだろうというのを示します。
11.12. Want Stop Receiving Data (DWSR)
11.12. 停止受信データが欲しいです。(DWSR)
DWSR: extends message with {
xid org-size;
};
DWSR: メッセージを広げている、xid org-サイズ;、。
The Want Stop Receiving Data (DWSR) message informs OPES processor that the callout server wants to stop receiving original data any time after receiving at least an org-size amount of an application message prefix. That is, the server is asking the processor to terminate original dataflow prematurely (see section 8.1) after sending at least org-size octets.
メッセージが少なくともアプリケーションメッセージ接頭語のorg-サイズ量を受けた後にいつでもオリジナルのデータを受け取るのを止めることをcalloutサーバがそうしたがっている作品プロセッサに知らせるWant Stop Receiving Data(DWSR)。 すなわち、サーバは、少なくともorg-サイズ八重奏を送った後に早まって(セクション8.1を見る)オリジナルのデータフローを終えるようにプロセッサに頼んでいます。
An OPES processor receiving a Want Stop Receiving Data (DWSR) message SHOULD terminate original dataflow by sending an Application Message End (AME) message with a 206 (partial) status code.
Want Stop Receiving Data(DWSR)メッセージSHOULDを受ける作品プロセッサは、206の(部分的)のステータスコードでApplication Message End(AME)メッセージを送ることによって、オリジナルのデータフローを終えます。
Rousskov Standards Track [Page 40] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[40ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
An OPES processor MUST NOT terminate its data preservation commitment (section 7) in reaction to receiving a Want Stop Receiving Data (DWSR) message. Just like with any other message, an OPES processor may use information supplied by Want Stop Receiving Data (DWSR) to decide on future preservation commitments.
作品プロセッサはWant Stop Receiving Data(DWSR)メッセージを受け取ることへの反応でデータ保存委任(セクション7)を終えてはいけません。 まさしくいかなる他のメッセージなどのようにも、作品プロセッサは今後の保存委任を決めるためにWant Stop Receiving Data(DWSR)によって提供された情報を使用するかもしれません。
11.13. Want Stop Sending Data (DWSS)
11.13. 停止にデータを送って欲しいです。(DWSS)
DWSS: extends message with {
xid;
};
DWSS: メッセージを広げている、xid;、。
The Want Stop Sending Data (DWSS) message informs the OPES processor that the callout server wants to stop sending adapted data as soon as possible; the server is asking the processor for permission to terminate adapted dataflow prematurely (see section 8.2). The OPES processor can grant this permission by using a Stop Sending Data (DSS) message.
Want Stop Sending Data(DWSS)メッセージはcalloutサーバができるだけ早く適合しているデータを送るのを止めたがっている作品プロセッサを知らせます。 サーバは早まって適合しているデータフローを終える許可をプロセッサに求めています(セクション8.2を見てください)。 作品プロセッサは、Stop Sending Data(DSS)メッセージを使用することによって、この許可を与えることができます。
Once the DWSS message is sent, the callout server MUST NOT prematurely terminate adapted dataflow until the server receives a DSS message from the OPES processor. If the server violates this rule, the OPES processor MUST act as if no DWSS message were received. The latter implies that the OCP transaction is terminated by the processor, with an error.
いったんDWSSメッセージを送ると、サーバが作品プロセッサからDSSメッセージを受け取るまで、calloutサーバは早まって、適合しているデータフローを終えてはいけません。 サーバがこの規則に違反するなら、作品プロセッサはまるでDWSSメッセージを全く受け取らないかのように作動しなければなりません。 後者は、誤りでOCPトランザクションがプロセッサによって終えられるのを含意します。
An OPES processor receiving a DWSS message SHOULD respond with a Stop Sending Data (DSS) message, provided the processor would not violate DSS message requirements by doing so. The processor SHOULD respond immediately once DSS message requirements can be satisfied.
そうすることによってプロセッサがDSSメッセージ要件に違反しないならSHOULDがStop Sending Data(DSS)メッセージで反応させるDWSSメッセージを受け取る作品プロセッサ。 すぐいったんDSSメッセージ要件を満たすことができると、プロセッサSHOULDは応じます。
11.14. Stop Sending Data (DSS)
11.14. データを送るのを止めてください。(DSS)
DSS: extends message with {
xid;
};
DSS: メッセージを広げている、xid;、。
The Stop Sending Data (DSS) message instructs the callout server to terminate adapted dataflow prematurely by sending an Application Message End (AME) message with a 206 (partial) status code. A callout server is expected to solicit the Stop Sending Data (DSS) message by sending a Want Stop Sending Data (DWSS) message (see section 8.2).
Stop Sending Data(DSS)メッセージは、早まって206の(部分的)のステータスコードでApplication Message End(AME)メッセージを送ることによって適合しているデータフローを終えるようcalloutサーバに命令します。 Want Stop Sending Data(DWSS)メッセージを送ることによってcalloutサーバがStop Sending Data(DSS)メッセージに請求すると予想されます(セクション8.2を見てください)。
A callout server receiving a solicited Stop Sending Data (DSS) message for a yet-unterminated adapted dataflow MUST immediately terminate dataflow by sending an Application Message End (AME) message with a 206 (partial) status code. If the callout server
まだ「非-終え」られた適合しているデータフローへの請求されたStop Sending Data(DSS)メッセージを受け取るcalloutサーバは、すぐに、206の(部分的)のステータスコードでApplication Message End(AME)メッセージを送ることによって、データフローを終えなければなりません。 calloutサーバです。
Rousskov Standards Track [Page 41] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[41ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
already terminated adapted dataflow, the callout server MUST ignore the Stop Sending Data (DSS) message. A callout server receiving an unsolicited DSS message for a yet-unterminated adapted dataflow MUST either treat that message as invalid or as solicited (i.e., the server cannot simply ignore unsolicited DSS messages).
適合しているデータフローが既に終わって、calloutサーバはStop Sending Data(DSS)メッセージを無視しなければなりません。 まだ「非-終え」られた適合しているデータフローへの求められていないDSSメッセージを受け取るcalloutサーバは病人として、または、請求にされるとしてそのメッセージを扱わなければなりません(すなわち、サーバは求められていないDSSメッセージを絶対に無視できません)。
The OPES processor sending a Stop Sending Data (DSS) message MUST be able to reconstruct the adapted application message correctly after the callout server terminates dataflow. This requirement implies that the processor must have access to any original data sent to the callout after the Stop Sending Data (DSS) message, if there is any. Consequently, the OPES processor either has to send no data at all or has to keep a copy of it.
calloutサーバがデータフローを終えた後にStop Sending Data(DSS)メッセージを送る作品プロセッサは正しく適合しているアプリケーションメッセージを再建できなければなりません。 この要件は、プロセッサがStop Sending Data(DSS)メッセージの後のcalloutに送られたどんなオリジナルのデータにも近づく手段を持たなければならないのを含意します、いずれかあれば。 その結果、作品プロセッサは、データを全く送ってはいけませんし、またそれの写しを取っておかなければなりません。
If a callout server receives a DSS message and, in violation of the above rules, waits for more original data before sending an Application Message End (AME) response, a deadlock may occur: The OPES processor may wait for the Application Message End (AME) message to send more original data.
calloutサーバがDSSメッセージを受け取って、Application Message End(AME)に応答を送る前に上の規則を違反して、よりオリジナルのデータを待つなら、行き詰まりは起こるかもしれません: 作品プロセッサは、よりオリジナルのデータを送るApplication Message End(AME)メッセージを待つかもしれません。
11.15. Want Data Paused (DWP)
11.15. データをポーズして欲しいです。(DWP)
DWP: extends message with {
xid your-offset;
};
DWP: -相殺してください、;、。
The Want Data Paused (DWP) message indicates the sender's temporary lack of interest in receiving data starting with the specified offset. This disinterest implies nothing about sender's intent to send data.
Want Data Paused(DWP)メッセージは指定されたオフセットから始まって、データを受け取る際に送付者の興味がある一時的な不足を示します。 この公平無私はデータを送る送付者の意図に関して何も含意しません。
The "your-offset" parameter refers to dataflow originating at the OCP agent receiving the parameter.
-相殺してください、」 パラメタはパラメタを受け取るOCPエージェントで起因するデータフローを示します。
If, at the time the Want Data Paused (DWP) message is received, the recipient has already sent data at the specified offset, the message recipient MUST stop sending data immediately. Otherwise, the recipient MUST stop sending data immediately after it sends the specified offset. Once the recipient stops sending more data, it MUST immediately send a Paused My Data (DPM) message and MUST NOT send more data until it receives a Want More Data (DWM) message.
Want Data Paused(DWP)メッセージが受信されているとき受取人が指定されたオフセットのときに既にデータを送ったなら、メッセージ受取人は、すぐにデータを送るのを止めなければなりません。 さもなければ、受取人は、指定されたオフセットを送る直後データを送るのを止めなければなりません。 受取人が、より多くのデータを送るのをいったん止めると、それは、すぐに、Paused My Data(DPM)メッセージを送らなければならなくて、Want More Data(DWM)メッセージを受け取るまで、より多くのデータは送ってはいけません。
As are most OCP Core mechanisms, data pausing is asynchronous. The sender of the Want Data Paused (DWP) message MUST NOT rely on the data being paused exactly at the specified offset or at all.
ほとんどのOCP Coreメカニズムのように、データの止まりは非同期です。 Want Data Paused(DWP)メッセージの送付者はちょうど指定されたオフセットにおいて全くポーズされるデータを当てにしてはいけません。
Rousskov Standards Track [Page 42] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[42ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
11.16. Paused My Data (DPM)
11.16. 私のデータをポーズします。(DPM)
DPM: extends message with {
xid;
};
DPM: メッセージを広げている、xid;、。
The Paused My Data (DPM) message indicates the sender's commitment to send no more data until the sender receives a Want More Data (DWM) message.
Paused My Data(DPM)メッセージは送付者がWant More Data(DWM)メッセージを受け取るまでそれ以上のデータを全く送らない送付者の委任を示します。
The recipient of the Paused My Data (DPM) message MAY expect the data delivery being paused. If the recipient receives data despite this expectation, it MAY abort the corresponding transaction with a Transaction End (TE) message indicating a failure.
Paused My Data(DPM)メッセージの受取人はポーズされるデータ配送を予想するかもしれません。 この期待にもかかわらず、受取人がデータを受け取るなら、それはTransaction End(TE)メッセージが失敗を示している対応するトランザクションを中止するかもしれません。
11.17. Want More Data (DWM)
11.17. より多くのデータが欲しいです。(DWM)
DWM: extends message with {
xid;
[Size-request: your-size];
};
DWM: メッセージを広げている、xid; [サイズ要求:、あなた、-、サイズ、]、;、。
The Want More Data (DWM) message indicates the sender's need for more data.
Want More Data(DWM)メッセージは送付者の、より多くのデータの必要性を示します。
Message parameters always refer to dataflow originating at the other OCP agent. When sent by an OPES processor, your-size is adp-size; when sent by a callout server, your-size is org-size.
メッセージパラメタはいつももう片方のOCPエージェントで起因するデータフローを示します。 作品プロセッサで送るとあなた、-、サイズ、adp-サイズです。 calloutサーバで送るとあなた、-、サイズ、org-サイズはそうです。
The "Size-request" parameter refers to dataflow originating at the OCP agent receiving the parameter. If a "Size-request" parameter is present, its value is the suggested minimum data size. It is meant to allow the recipient to deliver data in fewer chunks. The recipient MAY ignore the "Size-request" parameter. An absent "Size-request" parameter implies "any size".
「サイズ要求」パラメタはパラメタを受け取るOCPエージェントで起因するデータフローを示します。 「サイズ要求」パラメタが存在しているなら、値は提案された最小のデータサイズです。 それで、受取人は、より少ない塊におけるデータを提供することになっていることができます。 受取人は「サイズ要求」パラメタを無視するかもしれません。 欠けている「サイズ要求」パラメタは「どんなサイズも」を含意します。
The message also cancels the Paused My Data (DPM) message effect. If the recipient was not sending any data because of its DPM message, the recipient MAY resume sending data. Note, however, that the Want More Data (DWM) message can be sent regardless of whether the dataflow in question has been paused. The "Size-request" parameter makes this message a useful stand-alone optimization.
また、メッセージはPaused My Data(DPM)メッセージ効果を取り消します。 受取人がDPMメッセージのために少しのデータも送らなかったなら、受取人は、データを送るのを再開するかもしれません。 しかしながら、問題のデータフローがポーズされたかどうかにかかわらずWant More Data(DWM)メッセージを送ることができることに注意してください。 「サイズ要求」パラメタはこのメッセージを役に立つスタンドアロンの最適化にします。
Rousskov Standards Track [Page 43] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[43ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
11.18. Negotiation Offer (NO)
11.18. 交渉申し出(いいえ)
NO: extends message with {
features;
[SG: my-sg-id];
[Offer-Pending: boolean];
};
いいえ: 特徴; [SG: 私のsgイド][未定の申し出: 論理演算子]でメッセージを広げています。
A Negotiation Offer (NO) message solicits a selection of a single "best" feature out of a supplied list, using a Negotiation Response (NR) message. The sender is expected to list preferred features first when it is possible. The recipient MAY ignore sender preferences. If the list of features is empty, the negotiation is bound to fail but remains valid.
Negotiation Offer(いいえ)メッセージは供給されたリストからただ一つの「最も良い」特徴の選択に請求します、Negotiation Response(NR)メッセージを使用して。 最初に、それが可能であるときに、送付者が都合のよい特徴をリストアップすると予想されます。 受取人は送付者好みを無視するかもしれません。 特徴のリストが空であるなら、交渉は、失敗するのにおいて制限されていますが、有効なままで残っています。
Both the OPES processor and the callout server are allowed to send Negotiation Offer (NO) messages. The rules in this section ensure that only one offer is honored if two offers are submitted concurrently. An agent MUST NOT send a Negotiation Offer (NO) message if it still expects a response to its previous offer on the same connection.
作品プロセッサとcalloutサーバの両方がどんなメッセージもNegotiation Offerに送ることができません。 このセクションの規則は、同時に2つの申し出を提出するなら1つの申し出だけが光栄に思っているのを確実にします。 それが同じ接続のときにまだ前の申し出への応答を予想しているなら、エージェントはどんなメッセージもNegotiation Offerに送ってはいけません。
If an OPES processor receives a Negotiation Offer (NO) message while its own offer is pending, the processor MUST disregard the server offer. Otherwise, it MUST respond immediately.
それ自身の申し出が未定ですが、作品プロセッサがNegotiation Offer(いいえ)メッセージを受け取るなら、プロセッサはサーバ申し出を無視しなければなりません。 さもなければ、それはすぐに、応じなければなりません。
If a callout server receives a Negotiation Offer (NO) message when its own offer is pending, the server MUST disregard its own offer. In either case, the server MUST respond immediately.
それ自身の申し出が未定であるときに、calloutサーバがNegotiation Offer(いいえ)メッセージを受け取るなら、サーバはそれ自身の申し出を無視しなければなりません。 どちらの場合ではも、サーバはすぐに、反応しなければなりません。
If an agent receives a message sequence that violates any of the above rules in this section, the agent MUST terminate the connection with a Connection End (CE) message indicating a failure.
エージェントがこのセクションの上の規則のいずれかにも違反するメッセージ系列を受け取るなら、エージェントは失敗を示すConnection End(CE)メッセージとの関係を終えなければなりません。
An optional "Offer-Pending" parameter is used for Negotiation Phase maintenance (section 6.1). The option's value defaults to "false".
任意の「未定の申し出」パラメタはNegotiation Phaseメインテナンス(セクション6.1)に使用されます。 オプションの値は「誤っていること」をデフォルトとします。
An optional "SG" parameter is used to narrow the scope of negotiations to the specified service group. If SG is present, the negotiated features are negotiated and enabled only for transactions that use the specified service group ID. Connection-scoped features are negotiated and enabled for all service groups. The presence of scope does not imply automatic conflict resolution common to programming languages; no conflicts are allowed. When negotiating connection-scoped features, an agent MUST check for conflicts within each existing service group. When negotiating group-scoped features, an agent MUST check for conflicts with connection-scoped features
任意の"SG"パラメタは、指定されたサービスグループに交渉の範囲を狭くするのに使用されます。 SGが存在しているなら、交渉された特徴は、指定されたサービスグループIDを使用するトランザクションのためだけに、交渉されて、可能にされます。 接続によって見られた特徴は、すべてのサービスグループのために交渉されて、可能にされます。 範囲の存在はプログラミング言語に共通の自動紛争解決を含意しません。 闘争は全く許されていません。 接続によって見られた特徴を交渉するとき、エージェントは闘争がないかどうかそれぞれの既存のサービスグループの中でチェックしなければなりません。 グループによって見られた特徴を交渉するとき、エージェントは接続によって見られた特徴との闘争がないかどうかチェックしなければなりません。
Rousskov Standards Track [Page 44] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[44ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
already negotiated. For example, it must not be possible to negotiate a connection-scoped HTTP application profile if one service group already has an SMTP application profile, and vice versa.
既に交渉されています。 例えば、1つのサービスグループにSMTPアプリケーションプロフィールが既にあるなら、接続によって見られたHTTPアプリケーションプロフィールを交渉するのは可能であるはずがありません、逆もまた同様に。
OCP agents SHOULD NOT send offers with service groups used by pending transactions. Unless it is explicitly noted otherwise in a feature documentation, OCP agents MUST NOT apply any negotiations to pending transactions. In other words, negotiated features take effect with the new OCP transaction.
サービスグループが未定のトランザクションによって使用されている状態で、OCPエージェントSHOULD NOTは申し出を送ります。 それが別の方法で特徴ドキュメンテーションに明らかに述べられない場合、OCPエージェントは少しの交渉も未定のトランザクションに適用してはいけません。 言い換えれば、交渉された特徴は新しいOCPトランザクションで実施します。
As with other protocol elements, OCP Core extensions may document additional negotiation restrictions. For example, specification of a transport security feature may prohibit the use of the SG parameter in negotiation offers, to avoid situations where encryption is enabled for only a portion of overlapping transactions on the same transport connection.
他のプロトコル要素なら、OCP Core拡張子は追加交渉制限を記録するかもしれません。 例えば、輸送セキュリティ機能の仕様は、暗号化が同じ輸送接続のときに重なっているトランザクションの部分だけに可能にされる状況を避けるために交渉申し出におけるSGパラメタの使用を禁止するかもしれません。
11.19. Negotiation Response (NR)
11.19. 交渉応答(NR)
NR: extends message with {
[feature];
[SG: my-sg-id];
[Rejects: features];
[Unknowns: features];
[Offer-Pending: boolean];
};
NR: [特徴]; [SG: 私のsgイド]; [廃棄物: 特徴] ; [未知: 特徴][未定の申し出: 論理演算子]でメッセージを広げています。
A Negotiation Response (NR) message conveys recipient's reaction to a Negotiation Offer (NO) request. An accepted offer (a.k.a., positive response) is indicated by the presence of an anonymous "feature" parameter, containing the selected feature. If the selected feature does not match any of the offered features, the offering agent MUST consider negotiation failed and MAY terminate the connection with a Connection End (CE) message indicating a failure.
Negotiation Response(NR)メッセージはNegotiation Offer(いいえ)要求に受取人の反応を伝えます。 選択された特徴を含んでいて、受け入れられた申し出(通称積極的な応答)は匿名の「特徴」パラメタの存在によって示されます。 選択された特徴が提供された特徴のいずれにも合っていないなら、提供エージェントは、交渉が失敗されていると考えなければならなくて、失敗を示すConnection End(CE)メッセージとの関係を終えるかもしれません。
A rejected offer (negative response) is indicated by omitting the anonymous "feature" parameter.
拒絶された申し出(否定応答)は、匿名の「特徴」パラメタを省略することによって、示されます。
The successfully negotiated feature becomes effective immediately. The sender of a positive response MUST consider the corresponding feature enabled immediately after the response is sent; the recipient of a positive response MUST consider the corresponding feature enabled immediately after the response is received. Note that the scope of the negotiated feature application may be limited to a specified service group. The negotiation phase state does not affect enabling of the feature.
首尾よく交渉された特徴はすぐに、有効になります。 積極的な応答の送付者は、応答直後可能にされた対応する特徴が送られると考えなければなりません。 積極的な応答の受取人は、応答直後可能にされた対応する特徴が受信されていると考えなければなりません。 交渉された特徴アプリケーションの範囲が指定されたサービスグループに制限されるかもしれないことに注意してください。 交渉フェーズ状態は特徴を可能にすることに影響しません。
Rousskov Standards Track [Page 45] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[45ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
If negotiation offer contains an SG parameter, the responder MUST include that parameter in the Negotiation Response (NR) message. The recipient of an NR message without the expected SG parameter MUST treat negotiation response as invalid.
交渉申し出がSGパラメタを含んでいるなら、応答者はNegotiation Response(NR)メッセージでそのパラメタを入れなければなりません。 予想されたSGパラメタのないNRメッセージの受取人は無効の交渉同じくらい応答を扱わなければなりません。
If the negotiation offer lacks an SG parameter, the responder MUST NOT include that parameter in the Negotiation Response (NR) message. The recipient of an NR message with an unexpected SG parameter MUST treat the negotiation response as invalid.
交渉申し出がSGパラメタを欠いているなら、応答者はNegotiation Response(NR)メッセージでそのパラメタを入れてはいけません。 予期していなかったSGパラメタがあるNRメッセージの受取人は無効の交渉同じくらい応答を扱わなければなりません。
An optional "Offer-Pending" parameter is used for Negotiation Phase maintenance (section 6.1). The option's value defaults to "false".
任意の「未定の申し出」パラメタはNegotiation Phaseメインテナンス(セクション6.1)に使用されます。 オプションの値は「誤っていること」をデフォルトとします。
When accepting or rejecting an offer, the sender of the Negotiation Response (NR) message MAY supply additional details via Rejects and Unknowns parameters. The Rejects parameter can be used to list features that were known to the Negotiation Offer (NO) recipient but could not be supported given negotiated state that existed when NO message was received. The Unknowns parameter can be used to list features that were unknown to the NO recipient.
申し出を受け入れるか、または拒絶するとき、Negotiation Response(NR)メッセージの送付者はRejectsとUnknownsパラメタで追加詳細を提供するかもしれません。 Rejectsパラメタは、Negotiation Offer(いいえ)受取人にとって知られていた特徴をリストアップするのに使用できますが、メッセージを全く受け取らなかったとき存在した交渉された状態を考えて、サポートされないかもしれません。 いいえ受取人にとって、未知である特徴をリストアップするのにUnknownsパラメタを使用できます。
11.20. Ability Query (AQ)
11.20. 能力質問(AQ)
AQ: extends message with {
feature;
};
AQ: メッセージを広げている、特徴;、。
An Ability Query (AQ) message solicits an immediate Ability Answer (AA) response. The recipient MUST respond immediately with an AA message. This is a read-only, non-modifying interface. The recipient MUST NOT enable or disable any features due to an AQ request.
Ability Query(AQ)メッセージは即座のAbility Answer(AA)応答に請求します。 受取人はすぐAAメッセージで応じなければなりません。 これは書き込み禁止、非変更インタフェースです。 受取人は、AQ要求によるどんな特徴も可能にしてはいけませんし、また無効にしてはいけません。
OCP extensions documenting a feature MAY extend AQ messages to supply additional information about the feature or the query itself.
特徴を記録するOCP拡張子は特徴か質問自体に関する追加情報を提供するAQメッセージを広げるかもしれません。
The primary intended purpose of the ability inquiry interface is debugging and troubleshooting and not automated fine-tuning of agent behavior and configuration. The latter may be better achieved by the OCP negotiation mechanism (section 6).
能力問い合せインタフェースのプライマリ本来の目的は、自動化された微調整ではなく、エージェントの振舞いと構成のデバッグとトラブルシューティングです。 OCP交渉メカニズム(セクション6)によって後者は達成されるほうがよいです。
11.21. Ability Answer (AA)
11.21. 能力答え(AA)
AA: extends message with {
boolean;
};
AA: メッセージを広げている、論理演算子;、。
Rousskov Standards Track [Page 46] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[46ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
An Ability Answer (AA) message expresses the sender's support for a feature requested via an Ability Query (AQ) message. The sender MUST set the value of the anonymous boolean parameter to the truthfulness of the following statement: "At the time of this answer generation, the sender supports the feature in question". The meaning of "support" and additional details are feature specific. OCP extensions documenting a feature MUST document the definition of "support" in the scope of the above statement and MAY extend AA messages to supply additional information about the feature or the answer itself.
Ability Answer(AA)メッセージは送付者のAbility Query(AQ)メッセージで要求された特徴のサポートを言い表します。 送付者は匿名の論理演算子パラメタの値を以下の声明の正直さに設定しなければなりません: 「この答え世代時点で、送付者は問題の特徴をサポートします。」 「サポート」と追加詳細の意味は特徴特有です。 特徴を記録するOCP拡張子は、上の声明の範囲に「サポート」の定義を記録しなければならなくて、特徴か答え自体に関して追加情報を提供するAAメッセージを広げるかもしれません。
11.22. Progress Query (PQ)
11.22. 進歩質問(PQ)
PQ: extends message with {
[xid];
};
PQ: メッセージを広げている、[xid];、。
A Progress Query (PQ) message solicits an immediate Progress Answer (PA) response. The recipient MUST immediately respond to a PQ request, even if the transaction identifier is invalid from the recipient's point of view.
Progress Query(PQ)メッセージは即座のProgress Answer(PA)応答に請求します。 受取人はすぐにPQ要求に応じなければなりません、トランザクション識別子が受取人の観点から無効であっても。
11.23. Progress Answer (PA)
11.23. 進歩答え(PA)
PA: extends message with {
[xid];
[Org-Data: org-size];
};
PA: [xid][Org-データ: orgサイズ]でメッセージを広げています。
A PA message carries the sender's state. The "Org-Data" size is the total original data size received or sent by the agent so far for the identified application message (an agent can be either sending or receiving original data, so there is no ambiguity). When referring to received data, progress information does not imply that the data has otherwise been processed in some way.
PAメッセージは送付者の状態を運びます。 「Org-データ」サイズはエージェントが今までのところ特定されたアプリケーションメッセージのために受け取るか、または送る総元のデータサイズ(エージェントがオリジナルのデータを送るか、または受け取ることができるので、あいまいさが全くない)です。 受信データを示すとき、進歩情報は、そうでなければ、何らかの方法でデータを処理してあるのを含意しません。
The progress inquiry interface is useful for several purposes, including keeping idle OCP connections "alive", gauging the agent processing speed, verifying the agent's progress, and debugging OCP communications. Verifying progress, for example, may be essential to implement timeouts for callout servers that do not send any adapted data until the entire original application message is received and processed.
進歩問い合せインタフェースはいくつかの目的の役に立ちます、「生きている」ように無駄なOCP接続を保つのを含んでいて、エージェント処理速度を測って、エージェントの進歩について確かめて、OCPコミュニケーションをデバッグして。 例えば、進歩について確かめるのは、全体の原出願メッセージが受け取られて、処理されるまで少しの適合しているデータも送らないcalloutサーバのためにタイムアウトを実装するのに不可欠であるかもしれません。
A recipient of a PA message MUST NOT assume that the sender is not working on any transaction or application message not identified in the PA message. A PA message does not carry information about multiple transactions or application messages.
PAメッセージの受取人は、送付者がPAメッセージで特定されなかったどんなトランザクションやアプリケーションメッセージにも取り組んでいないと仮定してはいけません。 PAメッセージは多数の取引かアプリケーションメッセージの情報を運びません。
Rousskov Standards Track [Page 47] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[47ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
If an agent is working on the transaction identified in the Progress Query (PQ) request, the agent MUST send the corresponding transaction ID (xid) when answering the PQ with a PA message. Otherwise, the agent MUST NOT send the transaction ID. If an agent is working on the original application message for the specified transaction, the agent MUST send the Org-Data parameter. If the agent has already sent or received the Application Message End (AME) message for the original dataflow, the agent MUST NOT send the Org-data parameter.
PAメッセージでPQに答えるとき、エージェントが(PQ)が要求するProgress Queryで特定されたトランザクションに取り組んでいるなら、エージェントはID(xid)を対応するトランザクションに送らなければなりません。 さもなければ、エージェントはIDをトランザクションに送ってはいけません。 エージェントが指定されたトランザクションへの原出願メッセージに取り組んでいるなら、エージェントはOrg-データパラメタを送らなければなりません。 エージェントが既にオリジナルのデータフローへのApplication Message End(AME)メッセージを送るか、または受け取ったなら、エージェントはOrg-データパラメタを送ってはいけません。
Informally, the PA message relays the sender's progress with the transaction and original dataflow identified by the Progress Query (PQ) message, provided the transaction identifier is still valid at the time of the answer. Absent information in the answer indicates invalid, unknown, or closed transaction and/or original dataflow from the query recipient's point of view.
トランザクションとオリジナルのデータフローがProgress Query(PQ)メッセージによって特定されている状態で、非公式に、PAメッセージは送付者の進歩をリレーします、トランザクション識別子が答え時点でまだ有効であるなら。 答えにおける欠けている情報は質問受取人の観点から無効の、または、未知の、または、閉じているトランザクション、そして/または、オリジナルのデータフローを示します。
11.24. Progress Report (PR)
11.24. 経過報告書(PR)
PR: extends message with {
[xid];
[Org-Data: org-size];
};
PR: [xid][Org-データ: orgサイズ]でメッセージを広げています。
A Progress Report (PR) message carries the sender's state. The message semantics and associated requirements are identical to those of a Progress Answer (PA) message except that the PR message, is sent unsolicited. The sender MAY report progress at any time. The sender MAY report progress unrelated to any transaction or original application message or related to any valid (current) transaction or original dataflow.
Progress Report(PR)メッセージは送付者の状態を運びます。 意味論と関連要件がProgress Answerのものと同じであるというメッセージをそれを除いて、PRメッセージを通信させて、送ります(PA)。求められていません。 送付者はいつでも、経過を報告するかもしれません。 送付者はどんなトランザクションや、原出願メッセージや、関連するいずれにも有効な(現在の)トランザクションやまたはオリジナルのデータフローにも関係ない状態で経過を報告するかもしれません。
Unsolicited progress reports are especially useful for OCP extensions dealing with "slow" callout services that introduce significant delays for the final application message recipient. The report may contain progress information that will make that final recipient more delay tolerant.
求められていない経過報告書は特に最終的なアプリケーションメッセージ受取人のために重要な遅れを導入する「遅い」calloutサービスに対処するOCP拡張子の役に立ちます。 レポートは許容性があった状態でその最終的な受取人により多くの遅れを作る進歩情報を含むかもしれません。
12. IAB Considerations
12. IAB問題
OPES treatment of IETF Internet Architecture Board (IAB) considerations [RFC3238] are documented in [RFC3914].
IETFインターネット・アーキテクチャ委員会(IAB)問題[RFC3238]の作品処理は[RFC3914]に記録されます。
13. Security Considerations
13. セキュリティ問題
This section examines security considerations for OCP. OPES threats are documented in [RFC3837]
このセクションはOCPがないかどうかセキュリティ問題を調べます。 脅威が記録される作品[RFC3837]
Rousskov Standards Track [Page 48] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[48ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
OCP relays application messages that may contain sensitive information. Appropriate transport encryption can be negotiated to prevent information leakage or modification (see section 6), but OCP agents may support unencrypted transport by default. These configurations will expose application messages to third-party recording and modification, even if OPES proxies themselves are secure.
OCPは機密情報を含むかもしれないアプリケーションメッセージをリレーします。 情報漏出か変更を防ぐために適切な輸送暗号化を交渉できますが(セクション6を見てください)、OCPエージェントはデフォルトで非暗号化された輸送をサポートするかもしれません。 作品プロキシ自体が安全であっても、これらの構成は、アプリケーションがメッセージであると第三者録音と変更に暴露するでしょう。
OCP implementation bugs may lead to security vulnerabilities in OCP agents, even if OCP traffic itself remains secure. For example, a buffer overflow in a callout server caused by a malicious OPES processor may grant that processor access to information from other (100% secure) OCP connections, including connections with other OPES processors.
OCPトラフィック自体が安全なままで残っても、OCP実装バグはOCPエージェントでセキュリティの脆弱性に通じるかもしれません。 例えば、悪意がある作品プロセッサによって引き起こされたcalloutサーバにおけるバッファオーバーフローは他の(100%安全)のOCP接続からそのプロセッサ情報入手を承諾するかもしれません、他の作品プロセッサとの接続を含んでいて。
Careless OCP implementations may rely on various OCP identifiers to be unique across all OCP agents. A malicious agent can inject an OCP message that matches identifiers used by other agents, in an attempt to gain access to sensitive data. OCP implementations must always check an identifier for being "local" to the corresponding connection before using that identifier.
不注意なOCP実装は、すべてのOCPエージェントの向こう側に特有になるように様々なOCP識別子を当てにするかもしれません。 悪意があるエージェントは他のエージェントによって使用された識別子に合っているOCPメッセージを注入できます、極秘データへのアクセスを得る試みで。 OCP実装はその識別子を使用する前に対応する接続において「地方」であるのがないかどうかいつも識別子をチェックしなければなりません。
OCP is a stateful protocol. Several OCP commands increase the amount of state that the recipient has to maintain. For example, a Service Group Created (SGC) message instructs the recipient to maintain an association between a service group identifier and a list of services.
OCPはstatefulプロトコルです。 いくつかのOCPコマンドが受取人が維持しなければならない状態の量を増強します。 例えば、Service Group Created(SGC)メッセージは、サービスグループ識別子とサービスのリストとの協会を維持するよう受取人に命令します。
Implementations that cannot correctly handle resource exhaustion increase security risks. The following are known OCP-related resources that may be exhausted during a compliant OCP message exchange:
正しくリソース疲労困憊を扱うことができない実装がセキュリティ危険を増強します。 ↓これは対応するOCP交換処理の間に枯渇するかもしれない知られているOCP関連のリソースです:
OCP message structures: OCP message syntax does not limit the nesting
depth of OCP message structures and does not place an upper limit
on the length (number of OCTETs) of most syntax elements.
OCPメッセージ構造: OCPメッセージ構文は、OCPメッセージ構造の巣篭もりの深さを制限しないで、またほとんどの構文要素の長さ(OCTETsの数)に関して上限を課しません。
concurrent connections: OCP does not place an upper limit on the
number of concurrent connections that a callout server may be
instructed to create via Connection Start (CS) messages.
同時接続: OCPはConnection Start(CS)メッセージで作成してくださいcalloutサーバが命令されるかもしれない同時接続の数に関して上限を課しません。
service groups: OCP does not place an upper limit on the number of
service group associations that a callout server may be instructed
to create via Service Group Created (SGC) messages.
サービスは分類されます: OCPはcalloutサーバがService Group Created(SGC)メッセージで作成するよう命令されるかもしれないサービスグループ協会の数に関して上限を課しません。
concurrent transactions: OCP does not place an upper limit on the
number of concurrent transactions that a callout server may be
instructed to maintain via Transaction Start (TS) messages.
同時発生のトランザクション: OCPはTransaction Start(TS)メッセージで維持してくださいcalloutサーバが命令されるかもしれない同時発生のトランザクションの数に関して上限を課しません。
Rousskov Standards Track [Page 49] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[49ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
concurrent flows: OCP Core does not place an upper limit on the
number of concurrent adapted flows that an OPES processor may be
instructed to maintain via Application Message Start (AMS)
messages.
同時発生の流れ: OCP CoreはApplication Message Start(AMS)メッセージで維持してください作品プロセッサが命令されるかもしれない同時発生の適合している流れの数に関して上限を課しません。
14. IANA Considerations
14. IANA問題
The IANA maintains a list of OCP features, including application profiles (section 10.11). For each feature, its uri parameter value is registered along with the extension parameters (if there are any). Registered feature syntax and semantics are documented with PETDM notation (section 9).
IANAはアプリケーションプロフィール(セクション10.11)を含むOCPの特徴のリストを維持します。 各特徴に関しては、uriパラメタ価値は拡大パラメタと共に示されます(いずれかあれば)。 PETDM記法(セクション9)で登録された特徴構文と意味論は記録されます。
The IESG is responsible for assigning a designated expert to review each standards-track registration prior to IANA assignment. The OPES working group mailing list may be used to solicit commentary for both standards-track and non-standards-track features.
IESGはIANA課題の前にそれぞれの標準化過程登録を見直すために指定された専門家を選任するのに責任があります。 作品ワーキンググループメーリングリストは、標準化過程と非標準化過程の特徴の両方のための論評に請求するのに使用されるかもしれません。
Standards-track OCP Core extensions SHOULD use http://www.iana.org/assignments/opes/ocp/ prefix for feature uri parameters. It is suggested that the IANA populate resources identified by such "uri" parameters with corresponding feature registrations. It is also suggested that the IANA maintain an index of all registered OCP features at the http://www.iana.org/assignments/opes/ocp/ URL or on a page linked from that URL.
標準化過程OCP Core拡大SHOULDは特徴uriパラメタに http://www.iana.org/assignments/opes/ocp/ 接頭語を使用します。 IANAが対応する特徴登録証明書でそのような"uri"パラメタによって特定されたリソースに居住することが提案されます。 また、IANAが http://www.iana.org/assignments/opes/ocp/ URLにおける、または、そのURLからリンクされた1ページの上のすべての登録されたOCPの特徴のインデックスを維持することが提案されます。
This specification defines no OCP features for IANA registration.
この仕様はIANA登録のためのOCPの特徴を全く定義しません。
15. Compliance
15. 承諾
This specification defines compliance for the following compliance subjects: OPES processors (OCP client implementations), callout servers (OCP server implementations), and OCP extensions. An OCP agent (a processor or callout server) may also be referred to as the "sender" or "recipient" of an OCP message.
この仕様は以下の承諾対象のためのコンプライアンスを定義します: 作品プロセッサ(OCPクライアント実装)、calloutサーバ(OCPサーバ実装)、およびOCP拡張子。 また、OCPエージェント(プロセッサかcalloutサーバ)はOCPメッセージの「送付者」か「受取人」と呼ばれるかもしれません。
A compliance subject is compliant if it satisfies all applicable "MUST" and "SHOULD" requirements. By definition, to satisfy a "MUST" requirement means to act as prescribed by the requirement; to satisfy a "SHOULD" requirement means either to act as prescribed by the requirement or to have a reason to act differently. A requirement is applicable to the subject if it instructs (addresses) the subject.
すべての適切な“MUST"と“SHOULD"要件を満たすなら、承諾対象は対応します。 定義上、“MUST"要件を満たすのは、要件によって処方されるように行動することを意味します。 “SHOULD"要件を満たすのは、要件によって処方されるように行動するか、または異なって行動する理由を持っていることを意味します。 命令するなら、要件は対象に適切です。(アドレス)対象。
Informally, OCP compliance means that there are no known "MUST" violations, and that all "SHOULD" violations are deliberate. In other words, "SHOULD" means "MUST satisfy or MUST have a reason to violate". It is expected that compliance claims be accompanied by a
非公式に、OCPコンプライアンスは“MUST"違反が知られていなくて、すべての“SHOULD"違反が慎重であることを意味します。 言い換えれば、“SHOULD"手段は「満足させなければならないか、または違反する理由を持たなければなりません」。 承諾クレームがaによって伴われると予想されます。
Rousskov Standards Track [Page 50] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[50ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
list of unsupported SHOULDs (if any), in an appropriate format, explaining why the preferred behavior was not chosen.
都合のよい振舞いがなぜ選ばれなかったかがわかる適切な形式のサポートされないSHOULDs(もしあれば)のリスト。
Only normative parts of this specification affect compliance. Normative parts are those parts explicitly marked with the word "normative", definitions, and phrases containing unquoted capitalized keywords from [RFC2119]. Consequently, examples and illustrations are not normative.
この仕様の標準の部分だけがコンプライアンスに影響します。 標準の部品は、[RFC2119]からの引用を終わっている大文字で書かれたキーワードを含む単語が「規範的な」状態で明らかに示されるそれらの部品と、定義と、句です。 その結果、例とイラストは規範的ではありません。
15.1. Extending OCP Core
15.1. OCPコアを広げています。
OCP extensions MUST NOT change the OCP Core message format, as defined by ABNF and accompanying normative rules in Section 3.1. This requirement is intended to allow OCP message viewers, validators, and "intermediary" software to at least isolate and decompose any OCP message, even a message with semantics unknown to them (i.e., extended).
OCP拡張子はOCP Coreメッセージ・フォーマットを変えてはいけません、セクション3.1のABNFと付随の標準の規則で定義されるように。 この要件が、OCPメッセージビューアー、validators、および「仲介者」ソフトウェアがどんなOCPメッセージ(彼ら(すなわち、広がっている)にとっての、未知の意味論があるメッセージさえ)も少なくとも隔離して、分解するのを許容することを意図します。
OCP extensions are allowed to change normative OCP Core requirements for OPES processors and callout servers. However, OCP extensions SHOULD NOT make these changes and MUST require on a "MUST"-level that these changes are negotiated prior to taking effect. Informally, this specification defines compliant OCP agent behavior until changes to this specification (if any) are successfully negotiated.
OCP拡張子は作品プロセッサとcalloutサーバのための標準のOCP Core要件を変えることができます。 しかしながら、OCP拡大SHOULDは、これらの変更を行って、“MUST"-レベルでこれらの変化が効く前に交渉されるのを必要としてはいけません。 非公式に、この仕様(もしあれば)への変化が首尾よく交渉されるまで、この仕様は対応するOCPエージェントの振舞いを定義します。
For example, if an RTSP profile for OCP requires support for offsets exceeding 2147483647 octets, the profile specification can document appropriate OCP changes while requiring that RTSP adaptation agents negotiate "large offsets" support before using large offsets. This negotiation can be bundled with negotiating another feature (e.g., negotiating an RTSP profile may imply support for "large offsets").
例えば、OCPのためのRTSPプロフィールが2147483647の八重奏を超えているオフセットに支持を要するなら、RTSP適合エージェントが使用の前に大きいサポートが相殺する「大きいオフセット」を交渉するのが必要である間、プロフィール仕様は適切なOCP変化を記録できます。 別の特徴を交渉するのはこの交渉を添付することができます(例えば、RTSPプロフィールを交渉すると、「大きいオフセット」のサポートは含意されるかもしれません)。
As implied by the above rules, OCP extensions may dynamically alter the negotiation mechanism itself, but such an alternation would have to be negotiated first, using the negotiation mechanism defined by this specification. For example, successfully negotiating a feature might change the default "Offer-Pending" value from false to true.
上の規則で含意されるように、OCP拡張子はダイナミックに交渉メカニズム自体を変更するかもしれませんが、そのような交互は最初に交渉されなければならないでしょう、この仕様で定義された交渉メカニズムを使用して。 例えば、首尾よく特徴を交渉すると、デフォルト「未定の申し出」価値は誤るのから本当に変化するかもしれません。
Rousskov Standards Track [Page 51] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[51ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
Appendix A. Message Summary
付録A.メッセージ概要
This appendix is not normative. The table below summarizes key OCP message properties. For each message, the table provides the following information:
この付録は規範的ではありません。 以下のテーブルは主要なOCPメッセージの特性をまとめます。 各メッセージのために、テーブルは以下の情報を提供します:
name: Message name as seen on the wire.
以下を命名してください。 ワイヤの上に見られるメッセージ名。
title: Human-friendly message title.
タイトル: 人間に優しいメッセージタイトル。
P: Whether this specification documents message semantics as sent by
an OPES processor.
P: この仕様は作品プロセッサで送るようにメッセージ意味論を記録であるかどうか
S: Whether this specification documents message semantics as sent by
a callout server.
S: この仕様はcalloutサーバで送るようにメッセージ意味論を記録であるかどうか
tie: Related messages such as associated request, response message,
or associated state message.
以下を結んでください。 関連要求、応答メッセージ、または準国家メッセージなどの関連メッセージ。
+-------+----------------------------+-------+-------+--------------+ | name | title | P | S | tie | +-------+----------------------------+-------+-------+--------------+ | CS | Connection Start | X | X | CE | | CE | Connection End | X | X | CS | | SGC | Service Group Created | X | X | SGD TS | | SGD | Service Group Destroyed | X | X | SGC | | TS | Transaction Start | X | | TE SGC | | TE | Transaction End | X | X | TS | | AMS | Application Message Start | X | X | AME | | AME | Application Message End | X | X | AMS DSS | | DUM | Data Use Mine | X | X | DUY DWP | | DUY | Data Use Yours | | X | DUM DPI | | DPI | Data Preservation Interest | | X | DUY | | DWSS | Want Stop Sending Data | | X | DWSR DSS | | DWSR | Want Stop Receiving Data | | X | DWSS | | DSS | Stop Sending Data | X | | DWSS | | DWP | Want Data Paused | X | X | DPM | | DPM | Paused My Data | X | X | DWP DWM | | DWM | Want More Data | X | X | DPM | | NO | Negotiation Offer | X | X | NR SGC | | NR | Negotiation Response | X | X | NO | | PQ | Progress Query | X | X | PA | | PA | Progress Answer | X | X | PQ PR | | PR | Progress Report | X | X | PA | | AQ | Ability Query | X | X | AA | | AA | Ability Answer | X | X | AQ | +-------+----------------------------+-------+-------+--------------+
+-------+----------------------------+-------+-------+--------------+ | 名前| タイトル| P| S| 繋がり| +-------+----------------------------+-------+-------+--------------+ | Cs| 接続始め| X| X| Ce| | Ce| 接続終わり| X| X| Cs| | SGC| 創設されたサービスグループ| X| X| SGD t| | SGD| 破壊されたサービスグループ| X| X| SGC| | t| 取引始め| X| | Te SGC| | Te| 取引終わり| X| X| t| | AMS| アプリケーションメッセージ始め| X| X| AME| | AME| アプリケーションメッセージ終わり| X| X| AMS DSS| | DUM| データは私のものを使用します。| X| X| DUY DWP| | DUY| データはあなたのものを使用します。| | X| DUM dpi| | dpi| データ保存関心| | X| DUY| | DWSS| 停止にデータを送って欲しいです。| | X| DWSR DSS| | DWSR| 停止受信データが欲しいです。| | X| DWSS| | DSS| データを送るのを止めてください。| X| | DWSS| | DWP| データをポーズして欲しいです。| X| X| DPM| | DPM| 私のデータをポーズします。| X| X| DWP DWM| | DWM| より多くのデータが欲しいです。| X| X| DPM| | いいえ| 交渉申し出| X| X| NR SGC| | NR| 交渉応答| X| X| いいえ| | PQ| 進歩質問| X| X| PA| | PA| 進歩答え| X| X| PQ PR| | PR| 経過報告書| X| X| PA| | AQ| 能力質問| X| X| AA| | AA| 能力答え| X| X| AQ| +-------+----------------------------+-------+-------+--------------+
Rousskov Standards Track [Page 52] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[52ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
Appendix B. State Summary
付録B.州の概要
This appendix is not normative. The table below summarizes OCP states. Some states are maintained across multiple transactions and application messages. Some correspond to a single request/response dialog; the asynchronous nature of most OCP message exchanges requires OCP agents to process other messages while waiting for a response to a request and, hence, while maintaining the state of the dialog.
この付録は規範的ではありません。 以下のテーブルはOCP州をまとめます。 多数の取引とアプリケーションメッセージの向こう側に維持される州もあります。 或るものはただ一つの要求/応答対話に対応しています。 ほとんどのOCP交換処理の非同期的性質は、OCPエージェントが要求への応答を待っている間、他のメッセージを処理して、したがって、維持をゆったり過ごすのを必要とします。対話の状態。
For each state, the table provides the following information:
各状態に、テーブルは以下の情報を提供します:
state: Short state label.
州: 脆い州のラベル。
birth: Messages creating this state.
出生: この状態を創設するメッセージ。
death: Messages destroying this state.
死: この状態を破壊するメッセージ。
ID: Associated identifier, if any.
ID: もしあれば関連識別子
+-------------------------------+-------------+-------------+-------+ | state | birth | death | ID | +-------------------------------+-------------+-------------+-------+ | connection | CS | CE | | | service group | SGC | SGD | sg-id | | transaction | TS | TE | xid | | application message and | AMS | AME | | | dataflow | | | | | premature org-dataflow | DWSR | AME | | | termination | | | | | premature adp-dataflow | DWSS | DSS AME | | | termination | | | | | paused dataflow | DPM | DWM | | | preservation commitment | DUM | DPI AME | | | negotiation | NO | NR | | | progress inquiry | PQ | PA | | | ability inquiry | PQ | PA | | +-------------------------------+-------------+-------------+-------+
+-------------------------------+-------------+-------------+-------+ | 状態| 出生| 死| ID| +-------------------------------+-------------+-------------+-------+ | 接続| Cs| Ce| | | サービスグループ| SGC| SGD| sg-イド| | 取引| t| Te| xid| | そしてアプリケーションメッセージ。| AMS| AME| | | データフロー| | | | | 時期尚早なorg-データフロー| DWSR| AME| | | 終了| | | | | 時期尚早なadp-データフロー| DWSS| DSS AME| | | 終了| | | | | ポーズされたデータフロー| DPM| DWM| | | 保存委任| DUM| dpi AME| | | 交渉| いいえ| NR| | | 進歩問い合せ| PQ| PA| | | 能力問い合せ| PQ| PA| | +-------------------------------+-------------+-------------+-------+
Rousskov Standards Track [Page 53] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[53ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
Appendix C. Acknowledgements
付録C.承認
The author gratefully acknowledges the contributions of Abbie Barbir (Nortel Networks), Oskar Batuner (Independent Consultant), Larry Masinter (Adobe), Karel Mittig (France Telecom R&D), Markus Hofmann (Bell Labs), Hilarie Orman (The Purple Streak), Reinaldo Penno (Nortel Networks), and Martin Stecher (Webwasher), as well as an anonymous OPES working group participant.
作者は感謝してアビーBarbir(ノーテルNetworks)、オスカーBatuner(独立しているConsultant)、ラリーMasinter(Adobe)、カレルMittig(フランステレコムの研究開発)、マーカスホフマン(ベル研究所)、Hilarie Orman(Purple Streak)、レイナルド・ペンノ(ノーテルNetworks)、およびマーチン・ステッチャー(Webwasher)の貢献を承諾します、匿名の作品ワーキンググループの関係者と同様に。
Special thanks to Marshall Rose for his xml2rfc tool.
彼のxml2rfcツールのためのマーシャル・ローズのおかげで、特別です。
16. References
16. 参照
16.1. Normative References
16.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2396] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
[RFC3835] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H.
Orman, "An Architecture for Open Pluggable Edge Services
(OPES)", RFC 3835, August 2004.
[RFC3835] Barbir、A.、ペンノ、R.、チェン、R.、ホフマン、M.、およびH.Orman、「開いているPluggable縁のサービスのための構造(作品)」、RFC3835(2004年8月)。
16.2. Informative References
16.2. 有益な参照
[RFC3836] Beck, A., Hofmann, M., Orman, H., Penno, R., and A.
Terzis, "Requirements for Open Pluggable Edge Services
(OPES) Callout Protocols", RFC 3836, August 2004.
[RFC3836] べック、A.、ホフマン、M.、Orman、H.、ペンノ、R.、およびA.Terzis、「開いているPluggableのための要件はサービス(作品)Calloutプロトコルを斜めに進みます」、RFC3836、2004年8月。
[RFC3837] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and
H. Orman, "Security Threats and Risks for Open Pluggable
Edge Services (OPES)", RFC 3837, August 2004.
[RFC3837] Barbir、A.、Batuner、O.、Srinivas、B.、ホフマン、M.、およびH.Orman、「開いているPluggableのための軍事的脅威とリスクはサービス(作品)を斜めに進みます」、RFC3837、2004年8月。
[RFC3752] Barbir, A., Burger, E., Chen, R., McHenry, S., Orman,
H., and R. Penno, "Open Pluggable Edge Services (OPES)
Use Cases and Deployment Scenarios", RFC 3752, April
2004.
[RFC3752]のBarbir、A.、バーガー、E.、チェン、R.、マクヘンリー、S.、Orman、H.、およびR.ペンノ、「開いているPluggable縁のサービス(作品)はケースと展開シナリオを使用します」、RFC3752、2004年4月。
[RFC3838] Barbir, A., Batuner, O., Beck, A., Chan, T., and H.
Orman, "Policy, Authorization, and Enforcement
Requirements of the Open Pluggable Edge Services
(OPES)", RFC 3838, August 2004.
[RFC3838] Barbir、A.、Batuner、O.、べック、A.、チェン、T.、H.Orman、および「開いているPluggable縁のサービス(作品)の方針、認可、および実施要件」、RFC3838(2004年8月)
Rousskov Standards Track [Page 54] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[54ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
[RFC3897] Barbir, A., "Open Pluggable Edge Services (OPES)
Entities and End Points Communication", RFC 3897,
September 2004.
[RFC3897]Barbir、A.、「Pluggable縁のサービス(作品)実体とエンドポイントコミュニケーションを開いてください」、RFC3897、2004年9月。
[OPES-RULES] Beck, A. and A. Rousskov, "P: Message Processing
Language", Work in Progress, October 2003.
[作品規則]のべック、A.、およびA.Rousskov、「P:」 「メッセージは言語を処理し」て、進歩、2003年10月に働いてください。
[RFC3914] Barbir, A. and A. Rousskov, "Open Pluggable Edge
Services (OPES) Treatment of IAB Considerations", RFC
3914, October 2004.
[RFC3914]BarbirとA.とA.Rousskov、「IAB問題の開いているPluggable縁のサービス(作品)処理」、RFC3914、2004年10月。
[OPES-HTTP] Rousskov, A. and M. Stecher, "HTTP adaptation with
OPES", Work in Progress, January 2004.
[作品HTTP] RousskovとA.とM.ステッチャー、「作品とのHTTP適合」、ProgressのWork、2004年1月。
[RFC2616] 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.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol
Core", RFC 3080, March 2001.
[RFC3080] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC
3238, January 2002.
[RFC3238] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、2002年1月。
Author's Address
作者のアドレス
Alex Rousskov The Measurement Factory
アレックスRousskov測定工場
EMail: rousskov@measurement-factory.com URI: http://www.measurement-factory.com/
メール: rousskov@measurement-factory.com ユリ: http://www.measurement-factory.com/
Rousskov Standards Track [Page 55] RFC 4037 OPES Callout Protocol Core March 2005
Rousskov標準化過程[55ページ]RFC4037作品Calloutは2005年のコア行進のときに議定書を作ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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.
このドキュメントは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機能のための基金は現在、インターネット協会によって提供されます。
Rousskov Standards Track [Page 56]
Rousskov標準化過程[56ページ]
一覧
スポンサーリンク
