Network Working Group A. Rousskov
Request for Comments: 4236 The Measurement Factory
Category: Standards Track M. Stecher
CyberGuard Corporation
November 2005
HTTP Adaptation with Open Pluggable Edge Services (OPES)
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol. This document extends those generic mechanisms for Hypertext Transfer Protocol (HTTP) adaptation. Together, application-agnostic OPES documents and this HTTP profile constitute a complete specification for HTTP adaptation with OPES.
オープンプラグイン可能なエッジサービス（OPES）フレームワーク文書ようOPESトレース、OPESバイパス、及びOPESコールアウトプロトコルなど、いくつかのアプリケーションに依存しないメカニズム。この文書では、ハイパーテキスト転送プロトコル（HTTP）の適応のために、これらの一般的なメカニズムを拡張します。一緒に、アプリケーションに依存しないOPESドキュメントとこのHTTPプロファイルはOPESとHTTP適応のための完全な仕様を構成しています。
Table of Contents
目次
1. Scope ...........................................................3
2. OPES Document Map ...............................................3
3. Callout Protocol ................................................4
3.1. Application Message Parts ..................................5
3.2. Application Profile Features ...............................6
3.2.1. Profile Parts .......................................6
3.2.2. Profile Structure ...................................8
3.2.3. Aux-Parts ...........................................8
3.2.4. Pause-At-Body .......................................9
3.2.5. Stop-Receiving-Body ................................10
3.2.6. Preservation-Interest-Body .........................10
3.2.7. Content-Encodings ..................................11
3.2.8. Profile Negotiation Example ........................12
3.3. Application Message Start Message .........................13
3.4. DUM Message ...............................................13
3.5. Selective Adaptation ......................................14
3.6. Hop-by-hop Headers ........................................15
3.7. Transfer Encodings ........................................15
3.8. HTTP Header Correctness ...................................16
3.8.1. Message Size Recalculation .........................16
3.8.2. Content-MD5 Header .................................17
3.9. Examples ..................................................18
4. Tracing ........................................................22
5. Bypass .........................................................24
6. IAB Considerations .............................................24
7. Security Considerations ........................................24
8. IANA Considerations ............................................24
9. Compliance .....................................................25
10. References ....................................................25
10.1. Normative References .....................................25
10.2. Informative References ...................................25
The Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES processor and endpoints communications [RFC3897] or OPES callout protocol [RFC4037]. This document extends those generic mechanisms for adaptation of a specific application protocol, HTTP [RFC2616]. Together, application-agnostic OPES documents and this HTTP profile constitute a complete specification for HTTP adaptation with OPES.
オープンプラグイン可能なエッジサービス（OPES）フレームワーク文書ようOPESプロセッサおよびエンドポイント通信[RFC3897]またはOPESコールアウトプロトコル[RFC4037]などのいくつかのアプリケーションに依存しないメカニズム。この文書は、特定のアプリケーションプロトコル、HTTP [RFC2616]の適応のためにそれらの一般的なメカニズムを拡張します。一緒に、アプリケーションに依存しないOPESドキュメントとこのHTTPプロファイルはOPESとHTTP適応のための完全な仕様を構成しています。
The primary sections of this document specify HTTP-specific extensions for the corresponding application-agnostic mechanisms documented elsewhere.
この文書の主要セクションは、他の場所で文書化され、対応するアプリケーションに依存しないメカニズムのHTTP固有の拡張子を指定します。
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 trying to comprehend isolated OPES documents. This section provides an index of OPES documents to assist the reader with finding "missing" information.
この文書は、IETF OPESワーキンググループによって作成OPES仕様の大規模なセットに属します。孤立OPES文書を理解しようとすると、全体的なOPESアプローチと一般的なシナリオに精通していることが多いが不可欠です。このセクションでは、「行方不明」の情報を見つけることで、読者を支援するためOPES文書のインデックスを提供します。
o The document on "OPES Use Cases and Deployment Scenarios" [RFC3752] describes a set of services and applications that are considered in scope for OPES and have been used as a motivation and guidance in designing the OPES architecture.
「OPES使用事例と展開シナリオ」のドキュメントO [RFC3752]はOPESのスコープ内にあるとみなされ、OPESアーキテクチャを設計する上でのモチベーションやガイダンスとして使用されているサービスやアプリケーションのセットを記述する。
o The OPES architecture and common terminology are described in "An Architecture for Open Pluggable Edge Services (OPES)" [RFC3835].
O OPESアーキテクチャと共通の用語は、「オープン・プラガブルエッジサービスのためのアーキテクチャ（OPES）」[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「政策、認可およびOPESの施行の要件」[RFC3838]は、具体的な承認と執行方法を指定せずに、政策の枠組みに関する要件および仮定の概要を説明します。
o "Security Threats and Risks for OPES" [RFC3837] provides OPES risk analysis, without recommending specific solutions.
[RFC3837] o「はOPESのためのセキュリティの脅威とリスク」とは、特定のソリューションを推薦せずに、OPESリスク分析を提供します。
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の考慮事項のOPES治療」[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 such protocol are discussed in "Requirements for OPES Callout Protocols" [RFC3836].
OPESアーキテクチャの中核oはOPESプロセッサとコールアウトサーバは、OPES吹き出しプロトコル（OCP）を介して互いに通信する2つのネットワーク要素です。そのようなプロトコルのための要件は、「OPES吹き出しプロトコルのための要件」[RFC3836]に記載されています。
o "OPES Callout Protocol Core" [RFC4037] specifies an application agnostic protocol core to be used for the communication between OPES processor and callout server.
O「OPES吹き出しプロトコルコア」[RFC4037]はOPESプロセッサとコールアウトサーバ間の通信に使用されるアプリケーションにとらわれないプロトコルコアを指定します。
o "OPES entities and end points communications" [RFC3897] specifies generic tracing and bypass mechanisms for OPES.
○「OPESエンティティと終点通信」[RFC3897]はOPESための一般的なトレースとバイパス機構を指定します。
o The OCP Core and Communications documents are independent from the application protocol being adapted by OPES entities. Their
OCPコアと通信文書O OPESエンティティによって適合されているアプリケーションプロトコルから独立しています。彼らの
generic mechanisms have to be complemented by application-specific profiles. This document, HTTP adaptation with OPES, 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.
一般的なメカニズムは、アプリケーション固有のプロファイルによって補完する必要があります。この文書で、OPESとHTTPの適応は、HTTPのためのそのようなアプリケーションプロファイルです。これは、アプリケーションに依存しないOPESメカニズムを使用してHTTPメッセージの適応を支援するために増強される方法を指定します。
o Finally, "P: Message Processing Language" [rules-p] 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 meant for configuring application proxies (OPES processors).
O最後に、「P：メッセージ処理言語」[ルール-p]はOPES適応（例えば、翻訳）がどのアプリケーション・メッセージ（例えば、電子メールbob@example.comから）に適用されなければならないものを指定するための言語を定義します。 P言語は、アプリケーションプロキシ（OPESプロセッサ）を構成するためのものです。
This section documents the HTTP profile for the OPES Callout Protocol (OCP) Core [RFC4037]. Familiarity with OCP Core is required to understand the HTTP profile. This section uses OCP Core conventions, terminology, and mechanisms.
このセクションでは、OPESコールアウトプロトコル（OCP）コア[RFC4037]のためのHTTPプロファイルを説明します。 OCPコア精通は、HTTPプロファイルを理解することが必要です。このセクションでは、OCPコアの規約、用語、およびメカニズムを使用しています。
OPES processor communicates its desire to adapt HTTP messages via a Negotiation Offer (NO) message with HTTP-specific feature identifiers documented in Section 3.2. HTTP-specific OCP optimization mechanisms can be negotiated at the same time. A callout server that supports adaptation of HTTP messages has a chance to negotiate what HTTP message parts will participate in adaptation, including negotiation of HTTP request parts as metadata for HTTP response adaptation. Negotiable HTTP message parts are documented in Section 3.1.
OPESプロセッサは、3.2節に記載HTTP固有の機能識別子との交渉のオファー（NO）メッセージを介してHTTPメッセージを適合させるためにその願望を伝えます。 HTTP固有のOCPの最適化メカニズムが同時に交渉することができます。 HTTPメッセージの適応をサポートコールアウトサーバは、HTTPメッセージの部品は、HTTPレスポンスの適応のためのメタデータとしてのHTTPリクエストパートの交渉を含め、適応に参加するかを交渉する機会を持っています。応相談HTTPメッセージの部品は、3.1節に記載されています。
HTTP profile introduces a new parameter for the Application Message Start (AMS) message to communicate known HTTP message length (HTTP headers often do not convey length information reliably or at all). This parameter is documented in Section 3.3. Section 3.4 documents a mechanism to report HTTP message parts with Data Use Mine (DUM) messages.
HTTPプロファイルは、（HTTPヘッダは、多くの場合、確実に長さの情報を伝えるか、まったくありません）、既知のHTTPメッセージの長さを通信するアプリケーションメッセージ開始（AMS）メッセージのための新しいパラメータを導入しています。このパラメータは、3.3節に記載されています。 3.4節の文書データ利用マイン（DUM）メッセージとHTTPメッセージの部品を報告する仕組み。
The remaining OCP sections document various OCP marshaling corner cases such as handling of HTTP transfer encodings and 100 Continue responses.
残りのOCPのセクションでは、このようなHTTP転送エンコーディングの取り扱いなど、さまざまなOCPマーシャリングコーナーケースを文書化し、100は、応答を続けます。
An HTTP message may have several well-known parts: headers, body, and trailers. HTTP OPES processors are likely to have information about HTTP message parts because they have to isolate and interpret HTTP headers and find HTTP message boundaries. Callout servers may either not care about certain parts or may benefit from reusing HTTP OPES processor work on isolating and categorizing interesting parts.
ヘッダ、本体、およびトレーラー：HTTPメッセージは、いくつかの周知の部品を有していてもよいです。彼らは隔離し、HTTPヘッダを解釈し、HTTPメッセージの境界を見つけなければならないので、HTTP OPESプロセッサは、HTTPメッセージの部品についての情報を持っている可能性があります。コールアウトサーバは、いずれかの特定の部分を気にしないかもしれませんか、興味深い部分を分離し、分類上のHTTP OPESプロセッサの仕事を再利用から利益を得ることができます。
The following is the declaration of am-part (application message part) type using OCP Core Protocol Element Type Declaration Mnemonic (PETDM):
以下、AM-部（アプリケーションメッセージ部分）OCPコアプロトコル要素型宣言ニーモニック（PETDM）を使用して型の宣言です。
am-part: extends atom;
am-parts: extends list of am-part;
Figure 1
図1
The following six "am-part" atoms are valid values:
以下の6つの「AM-部」の原子は、有効な値は次のとおりです。
request-header: The start-line of an HTTP request message, all request message headers, and the CRLF separator at the end of HTTP headers (compare with section 4.1 of [RFC2616]).
リクエスト・ヘッダー：HTTPヘッダの終わりにHTTPリクエストメッセージ、すべての要求メッセージヘッダー、およびCRLF分離の開始ライン（[RFC2616]のセクション4.1と比較）。
request-body: The message body of an HTTP request message as defined in section 4.3 of [RFC2616] but not including the trailer.
リクエストボディ：[RFC2616]のセクション4.3で定義されているが、トレーラを含まないようにHTTPリクエストメッセージのメッセージボディ。
request-trailer: The entity headers of the trailer of an HTTP request message in chunked transfer encoding. This part follows the same syntax as the trailer defined in section 3.6.1 of [RFC2616].
要求トレーラー：チャンク転送符号化におけるHTTPリクエストメッセージのトレーラの実体ヘッダー。この部分は、[RFC2616]のセクション3.6.1で定義されたトレーラと同じ構文に従います。
response-header: The start-line of an HTTP response message, all response message headers, and the CRLF separator at the end of HTTP headers (compare with section 4.1 of [RFC2616]).
レスポンス・ヘッダー：HTTP応答メッセージ、すべての応答メッセージヘッダー、およびHTTPヘッダの末尾にCRLFセパレータ（[RFC2616]のセクション4.1と比較）のスタートライン。
response-body: The message body of an HTTP response message as defined in section 4.3 of [RFC2616] but not including the trailer.
応答体：HTTPレスポンスメッセージのメッセージボディ[RFC2616]のセクション4.3で定義されているが、トレーラを含まないように。
response-trailer: The entity headers of the trailer of an HTTP response message in chunked transfer encoding. This part follows the same syntax as the trailer defined in section 3.6.1 of [RFC2616].
応答トレーラー：チャンク転送符号化におけるHTTPレスポンスメッセージのトレーラの実体ヘッダー。この部分は、[RFC2616]のセクション3.6.1で定義されたトレーラと同じ構文に従います。
This document defines two HTTP profiles for OCP: request and response profiles. These two profiles are described below. Each profile has a unique feature identifier, a list of original application message parts, and a list of adapted application message parts:
リクエストとレスポンスのプロファイル：この文書は、OCPのための2つのHTTPプロファイルを定義します。これらの2つのプロファイルは、以下に記載されています。各プロファイルには、ユニークな特徴識別子、元のアプリケーション・メッセージ・パーツのリスト、および適応アプリケーションメッセージ部分のリストを有します。
profile ID: http://www.iana.org/assignments/opes/ocp/http/request
プロフィールID：http://www.iana.org/assignments/opes/ocp/http/request
original request parts: request-header, request-body, request-trailer
元の要求の部品：要求ヘッダ、リクエストボディ、要求トレーラー
adapted request parts: request-header, request-body, request-trailer
適応要求部：要求ヘッダ、リクエストボディ、要求トレーラー
adapted response parts: response-header, response-body, response-trailer
適応応答の部品：レスポンスヘッダ、レスポンスボディ、応答トレーラー
profile ID: http://www.iana.org/assignments/opes/ocp/http/response
プロフィールID：http://www.iana.org/assignments/opes/ocp/http/response
original transaction parts: request-header (aux), request-body (aux), request-trailer (aux), response-header, response-body, response-trailer
元のトランザクションの部分：要求ヘッダ（AUX）、リクエストボディ（AUX）、要求トレーラー（AUX）、レスポンスヘッダ、レスポンスボディ、応答トレーラー
adapted response parts: response-header, response-body, response-trailer
適応応答の部品：レスポンスヘッダ、レスポンスボディ、応答トレーラー
The request profile contains two variants of adapted part lists: HTTP request parts and HTTP response parts. Parts marked with an "(aux)" suffix are auxiliary parts that can only be used if explicitly negotiated for a profile. See Section 3.2.1 for specific rules governing negotiation and use of am-parts.
HTTPリクエストの部品やHTTPレスポンスパーツ：要求プロファイルが適応パーツリストの二つの変種が含まれています。 「（AUX）」接尾辞の付いた部品は、明示的にプロファイルのために交渉した場合にのみ使用することができ、補助部品です。交渉とAM-部品の使用を管理する特定の規則については、セクション3.2.1を参照してください。
The scope of a negotiated profile is the OCP connection (default) or the service group specified via the SG parameter.
ネゴシエートされたプロファイルの範囲は、OCP接続（デフォルト）またはSGパラメータで指定されたサービスグループです。
An OCP agent MUST send application message parts in the order implied by the profile parts lists above. An OCP agent receiving an out-of-order part MAY terminate the transaction with an error.
OCPエージェントは、上記のプロファイルパーツリストによって暗黙ために、アプリケーションのメッセージ部分を送らなければなりません。アウトオブオーダー一部を受け取るOCPエージェントがエラーで取引を終了することができます。
An OPES processor MUST NOT send parts that are not listed as "original" in the negotiated profile. A callout server MUST NOT send parts that are not listed as "adapted" in the negotiated profile. An OCP agent receiving an not-listed part MUST terminate the transaction with an error. The informal rationale for the last requirement is to reduce the number of subtle interoperability problems where an agent thinks that the parts it is sending are understood/used by the other agent when, in fact, they are being ignored or skipped because they are not expected.
OPESプロセッサは交渉さプロファイルで「オリジナル」として記載されていない部品を送ってはいけません。コールアウトサーバは、ネゴシエートプロファイルに「適応」として記載されていない部品を送ってはいけません。 - 表示されていない部分を受信OCPエージェントはエラーでトランザクションを終了しなければなりません。実際に、彼らは無視されるか、またはそれらが期待されていないため、スキップされているとき、最後の要件のための非公式の根拠は、エージェントが送信している部分が理解/他のエージェントによって使用されていることを考えて微妙な相互運用性の問題の数を減らすことです。
Some HTTP messages lack certain parts. For example, many HTTP requests do not have bodies, and most HTTP messages do not have trailers. An OCP agent MUST NOT send (i.e., must skip) absent application message parts.
いくつかのHTTPメッセージは、特定の部分を欠いています。例えば、多くのHTTPリクエストは、ボディを持っていない、とほとんどのHTTPメッセージは、トレーラーを持っていません。 OCP剤が存在しないアプリケーションメッセージ部分（すなわち、スキップしなければならない）を送ってはいけません。
An OCP agent MUST send present non-auxiliary parts and it MUST send those present auxiliary parts that were negotiated via the Aux-Parts (Section 3.2.3) parameter. OCP agents MUST NOT send auxiliary parts that were not negotiated via the Aux-Parts (Section 3.2.3) parameter.
OCP剤が存在する非補助部品を送る必要があり、AUX-部品（セクション3.2.3）パラメータを介して交渉されたもの、本補助部品を送らなければなりません。 OCPエージェントはAUX-部品（3.2.3）パラメータ経由で交渉されていなかった補助部品を送ってはいけません。
An OCP agent receiving a message part in violation of the above requirements MAY terminate the corresponding transaction with an error.
上記の要件に違反してメッセージ部分を受信OCPエージェントがエラーに対応するトランザクションを終了することができます。
By design, original parts not included in the adapted parts list cannot be adapted. In other words, a callout service can only adapt parts in the adapted parts list even though it may have access to other parts.
設計により、適応パーツリストに含まれていないオリジナルパーツを適応することはできません。つまり、コールアウトサービスは、それが他の部分へのアクセス権を持っている場合であっても適応パーツリストで部品を適応させることができます。
In the request profile, the callout server MUST send either adapted
要求プロファイルでは、コールアウトサーバは、いずれかの適応送らなければなりません
request parts or adapted response parts. An OPES processor receiving adapted flow with application message parts from both lists (in violation of the previous rule) MUST terminate the OCP transaction with an error. Informally, the callout server sends adapted response parts to "short-circuit" the HTTP transaction, forcing the OPES processor to return an HTTP response without forwarding an adapted HTTP request. This short-circuiting is useful for responding, for example, to an HTTP request that the callout service defines as forbidden.
部品や適応応答の部品を要求します。 （以前のルールに違反して）両方のリストからアプリケーション・メッセージ・パーツとの適合フローを受信OPESプロセッサはエラーでOCPトランザクションを終了しなければなりません。非公式に、コールアウトサーバは、適応HTTP要求を転送することなく、HTTPレスポンスを返すようにOPESプロセッサを強制的に「短絡」HTTPトランザクションに適応応答部分を送信します。この短絡は、例えば、禁止としてコールアウトサービスを定義するHTTPリクエストに、応答するために有用です。
Unless explicitly configured to do otherwise, an OPES processor MUST offer all non-auxiliary original parts in Negotiation Offer (NO) messages. See Section 3.5 for this rule rationale and examples of harmful side-effects from selective adaptation.
明示的に行うように構成されていない限り、OPESプロセッサは交渉オファー（NO）メッセージ内のすべての非補助オリジナルパーツを提供しなければなりません。このルールの根拠と選択的適応からの有害な副作用の例については、3.5節を参照してください。
An HTTP application profile feature extends semantics of the feature type of OCP Core while adding the following named parameters to that type:
その型に次の名前付きパラメータを追加しながら、HTTPアプリケーションプロファイル機能は、OCPコアの機能タイプの意味を拡張します。
o Aux-Parts (Section 3.2.3)
単位でO（3.2.3）
o Pause-At-Body (Section 3.2.4)
O一時停止・アット・ボディ（3.2.4項）
o Stop-Receiving-Body (Section 3.2.5)
Oストップ受信ボディ（セクション3.2.5）
o Preservation-Interest-Body (Section 3.2.6)
O保全・インタレスト・ボディ（3.2.6項）
o Content-Encodings (Section 3.2.7)
Oコンテンツのエンコーディング（セクション3.2.7）
The definition of the HTTP profile feature structure using PETDM follows:
PETDMを使用してHTTPプロファイルの機能構造体の定義は次のとおりです。
HTTP-Profile: extends Feature with {
[Aux-Parts: am-parts];
[Pause-At-Body: size];
[Stop-Receiving-Body: size];
[Preservation-Interest-Body: size];
[Content-Encodings: codings];
};
Figure 2
図2
An HTTP profile structure can be used in feature lists of Negotiation Offer (NO) messages and as an anonymous parameter of a Negotiation Response (NR) message. All profile parameters apply to any OCP transaction within profile scope.
HTTPプロファイルの構造は、交渉のオファー（NO）メッセージの機能リストにと交渉応答（NR）メッセージの匿名のパラメータとして使用することができます。すべてのプロファイルパラメータは、プロファイル範囲内の任意のOCPトランザクションに適用されます。
The Aux-Parts parameter of an HTTP response profile can be used to negotiate the inclusion of auxiliary application message parts into the original data flow. The parameter is a possibly empty list of am-part tokens. An OPES processor MAY send an Aux-Parts parameter to advertise availability of auxiliary application message parts. A callout server MAY respond with a possibly empty subset of the parts it needs. The callout server response defines the subset of successfully negotiated auxiliary message parts.
HTTP応答プロファイルのAUX-部品パラメータは、元のデータフローに補助アプリケーションメッセージ部分の包含を交渉するために使用することができます。パラメータは午前パートトークンの可能性が空のリストです。 OPESプロセッサは補助アプリケーションメッセージ部分の可用性を宣伝するためにAUX-部品のパラメータを送信することができます。コールアウトサーバは、それが必要とする部品の空の可能性サブセットで応答することができます。コールアウトサーバの応答が正常にネゴシエートされた補助メッセージ部分のサブセットを定義します。
When receiving a Negotiation Offer (NO) message, the callout server MUST ignore any non-auxiliary part listed in the Aux-Parts parameter. When sending a Negotiation Response (NR) message, the callout server
交渉のオファー（NO）メッセージを受信すると、コールアウトサーバは、AUX-部品パラメータにリストされた任意の非補助部分を無視しなければなりません。交渉応答を送信する（NR）メッセージ、コールアウトサーバ
MUST NOT select any application message part that was not explicitly listed in the negotiation offer. In case of a violation of the last rule, the OPES processor MUST terminate the transaction.
明示的に交渉の申し出に記載されていませんでした任意のアプリケーションメッセージ部分を選択してはなりません。最後の規則に違反した場合に、OPESプロセッサはトランザクションを終了しなければなりません。
An OPES processor MUST send each negotiated auxiliary part to the callout server, unless the part is absent.
一部が存在しない場合を除きOPESプロセッサは、コールアウト・サーバに各ネゴシエート補助部を送らなければなりません。
Example: Aux-Parts: (request-header,request-body)
例：AUX-部品：（リクエストヘッダ、要求体）
Figure 3
図3
A callout server MAY use the Pause-At-Body parameter to request a pause in original application message body transmission before original dataflow starts. The parameter's value is of type "offset". The parameter specifies the start of the non-auxiliary application message body suffix that the sender is temporarily not interested in seeing.
コールアウトサーバは、元のデータフローを開始する前に、元のアプリケーションのメッセージ本体の伝送で一時停止を要求する一時停止アットボディパラメータを使用するかもしれません。パラメータの値は、「オフセット」型です。パラメータは、送信者が一時的に見ることに興味がない非補助アプリケーションメッセージボディのサフィックスの開始を指定します。
[headers][ body prefix | body suffix ][trailer]
<-- ? --><-- offset --><-- ? ---------------->
<-- equiv. DWP offset ->
Figure 4
図4
When an OPES processor receives a Pause-At-Body parameter, it MUST behave as if it has received a Want Data Paused (DWP) message with the corresponding org-offset. Note that the latter offset is different from the Pause-At-Body offset and is unknown until the size of the HTTP message headers is known.
OPESプロセッサはポーズアットボディパラメータを受信すると、それは、対応する組織オフセットとするデータ一時停止（DWP）メッセージを受信したかのように、それに動作しなければなりません。オフセット後者オフセットポーズアット体とは異なり、HTTPメッセージヘッダのサイズが知られるまで未知であることに留意されたいです。
For example, if the Pause-At-Body value is zero, the OPES processor should send a Paused My Data (DPM) message just before it sends the first Data Use Mine (DUM) message with the response-body part in the HTTP response profile. If the Pause-At-Body value is 300, the OPES processor should send a DPM message after transmitting 300 OCTETs for that application message part.
ポーズアットボディー値がゼロであれば、それはHTTPレスポンスのレスポンス・ボディ部を有する第1のデータを使用する鉱山（DUM）メッセージを送信する直前に、例えば、OPESプロセッサは一時停止マイデータ（DPM）メッセージを送信する必要がありますプロフィール。ポーズアットボディ値が300である場合、OPESプロセッサは、そのアプリケーションメッセージ部分300個のオクテットを送信した後DPMメッセージを送信しなければなりません。
Example: Pause-At-Body: 0
例：一時停止・アット・ボディ：0
Figure 5
図5
A callout server MAY use the Stop-Receiving-Body parameter to imply a Want Stop Receiving Data (DWSR) message behavior before the original dataflow starts. The parameter's value is of type "offset". The parameter specifies an offset into the original, non-auxiliary message body part (request-body in request profile and response-body in response profile).
コールアウトサーバーが欲しいが、元のデータフローを開始する前に、データ（DWSR）メッセージの振る舞いを受信を停止することを意味するものでストップ受信ボディパラメータを使用するかもしれません。パラメータの値は、「オフセット」型です。パラメータは、元の、非補助メッセージボディ部（応答プロファイルの要求プロファイル及びレスポンスボディに要求体）へのオフセットを指定します。
A callout service MAY send a Stop-Receiving-Body parameter with its negotiation response if there is a fixed offset into the message body for all transactions of a profile for which a Want Stop Receiving Data (DWSR) message would be sent. An OPES processor MUST behave as if it has received a DWSR message with the corresponding offset. Note that the latter offset is different from the Stop-Receiving-Body offset and is unknown until the size of the HTTP message headers is known.
固定したいが、データの受信を停止（DWSR）メッセージが送信されるであろうために、プロファイルのすべてのトランザクションのメッセージ本体へのオフセットがある場合、コールアウト・サービスは、その交渉応答を停止-受信ボディパラメータを送信することができます。それは対応するオフセットとDWSRメッセージを受信したかのようにOPESプロセッサは振る舞うしなければなりません。オフセット後者オフセットストップ受信体とは異なり、HTTPメッセージヘッダのサイズが知られるまで未知であることに留意されたいです。
For example, if the Stop-Receiving-Body value is zero in an HTTP response profile, the OPES processor should send an Application Message End (AME) message with result code 206 immediately after sending the response-header message part and before starting with the response-body message part.
例えば、ストップ受信ボディー値がHTTP応答プロファイルにゼロであれば、OPESプロセッサは、応答ヘッダメッセージ部を送信した後で始まる直前結果コード206とアプリケーション・メッセージエンド（AME）メッセージを送信しますレスポンスボディメッセージ部分。
Example: Stop-Receiving-Body: 0
例：ストップ受信ボディ：0
Figure 6
図6
The Preservation-Interest-Body parameter can be used to optimize data preservation at the OPES processor. The parameter's value is of type "size" and denominates a prefix size of the original, non-auxiliary message body part (request-body in HTTP request profile and response-body in response profile).
保存・インタレスト身体パラメータは、OPESプロセッサにデータ保存を最適化するために使用することができます。パラメータの値は、タイプ「サイズ」であり、元の、非補助メッセージボディ部（応答プロファイルのHTTPリクエストプロファイルとレスポンスボディに要求体）のプレフィックスサイズをdenominates。
A callout service MAY send a Preservation-Interest-Body parameter with its negotiation response if there is a fixed-size prefix of the application message body for which a Data Preservation Interest (DPI) message would be sent. An OPES processor MUST behave as if it receives a DPI message with org-offset zero and org-size equal to the value of the Preservation-Interest-Body parameter.
データの保存利息（DPI）メッセージが送られることになるため、アプリケーションのメッセージ本体の固定サイズの接頭辞がある場合は、コールアウト・サービスは、その交渉応答で保存・インタレスト・ボディパラメータを送信することができます。それは保存関心体パラメータの値に等しいDPIのORG-ゼロオフセットを持つメッセージとORG-サイズを受信した場合のようにOPESプロセッサは振る舞うしなければなりません。
For example, if the Preservation-Interest-Body value is zero in an HTTP response profile, the callout server must not send any Data Use Yours (DUY) message for the response-body part; the OPES processor may use this information to optimize its data preservation behavior even before it makes the decision to preserve data.
例えば、保存関心ボディー値がHTTP応答プロファイルにゼロである場合、コールアウトサーバは、応答のボディ部分のための任意のデータを使用しユアーズ（DUY）メッセージを送信してはなりません。 OPESプロセッサは、データを保存するために決定をする前であっても、そのデータ保存の動作を最適化するために、この情報を使用することができます。
Example: Preservation-Interest-Body: 0
例：保存 - インタレスト・ボディ：0
Figure 7
図7
A callout server MAY send a Content-Encodings list to indicate its preferences in content encodings. Encodings listed first are preferred to other encodings. An OPES processor MAY use any content encoding when sending application messages to a callout server.
コールアウトサーバは、コンテンツのエンコーディングにその好みを示すために、コンテンツのエンコーディングのリストを送信することができます。最初にリストエンコーディングは、他の符号化に好適です。コールアウトサーバにアプリケーションメッセージを送信するときにOPESプロセッサは、任意のコンテンツのエンコーディングを使用するかもしれません。
The list of preferred content encodings does not imply lack of support for other encodings. The OPES processor MUST NOT bypass a service just because the actual content encoding does not match the service's preferences.
好みのコンテンツエンコーディングのリストは、他のエンコーディングのサポートの欠如を意味するものではありません。実際のコンテンツのエンコーディングは、サービスの好みと一致していないという理由だけでOPESプロセッサは、サービスをバイパスしてはなりません。
If an OCP agent receives an application message that it cannot handle due to specific content encoding, the usual transaction termination rules apply.
OCPエージェントは、それが原因特定のコンテンツのエンコードには処理できないアプリケーションメッセージを受信した場合、通常の取引終了規則が適用されます。
content-coding: extends atom;
content-codings: extends list of content-coding;
Example: Content-Encodings: (gzip)
例：コンテンツエンコーディング：（GZIP）
Figure 8
図8
The semantics of content-coding is defined in section 3.5 of [RFC2616].
コンテンツコーディングのセマンティクスは[RFC2616]のセクション3.5で定義されています。
Example:
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
Preservation-Interest-Body: 0
Content-Encodings: (gzip)
}
SG: 5
;
Figure 9
図9
This example shows a negotiation offer made by an OPES processor for a service group (id 5) that has already been created; the callout server sends an adequate negotiation response.
この例では、既に作成されているサービスグループ（ID 5）のためOPESプロセッサ製交渉のオファーを示す図です。コールアウトサーバは、十分な交渉応答を送信します。
The OPES processor offers one profile feature for HTTP response messages. Besides the standard message parts, the OPES processor is able to add the header and body of the original HTTP request as auxiliary message parts.
OPESプロセッサは、HTTP応答メッセージのための1つのプロファイル機能を提供しています。標準的なメッセージ部分の他に、OPESプロセッサは、補助メッセージ部分として元のHTTPリクエストのヘッダとボディを追加することが可能です。
The callout server requests the auxiliary request-header part, but is not interested in receiving the request-body part.
コールアウトサーバは、補助リクエストヘッダ部分を要求するが、要求ボディ部を受信することに興味がありません。
The OPES processor sends at most the following message parts, in the specified order, for all transactions in service group 5: request-header, response-header, response-body, response-trailer. Note that the request-body part is not included (because it is an auxiliary part that was not explicitly requested). Some of the response parts may not be sent if the original message lacks them.
要求ヘッダ、応答ヘッダ、応答ボディ、応答トレーラー：OPESプロセッサは、サービスグループ5内のすべての取引について、指定された順序で、ほとんどの次のメッセージ部に送信します。 （それは明示的に要求されなかった補助部品であるので）要求ボディ部が含まれていないことに留意されたいです。元のメッセージは、それらがない場合、応答部品の一部が送信されない場合があります。
The callout server indicates through the Preservation-Interest-Body parameter with size zero that it will not send any DUY messages. The OPES processor may therefore preserve no preservation for any transaction of this profile.
コールアウトサーバは、それがどんなDUYメッセージを送信しませんサイズゼロの保存・インタレスト・ボディのパラメータを使用して示します。 OPESプロセッサは、したがって、このプロファイルの任意の取引のために全く保存を保存しないことができます。
By sending a Pause-At-Body value of 30, the callout server requests a data pause. The OPES processor sends a Paused My Data (DPM) message immediately after sending at least 30 OCTETs of the response-body part. Thereafter, the OPES processor waits for a Want More Data (DWM) message from the callout service.
30のポーズアットボディー値を送信することにより、コールアウトサーバは、データの一時停止を要求します。 OPESプロセッサはレスポンスボディ部分の少なくとも30個のオクテットを送信した直後に一時停止マイデータ（DPM）メッセージを送信します。その後、OPESプロセッサは、コールアウトサービスからより多くのデータ（DWM）メッセージを欲しい待ちます。
A new named parameter for Application Message Start (AMS) messages is introduced.
アプリケーションメッセージ開始（AMS）メッセージのための新しい名前付きパラメータが導入されます。
AM-EL: size
AM-EL：サイズ
Figure 10
図10
AM-EL value is the size of the request-body part in the HTTP request profile, and is the size of the response-body part in the HTTP response profile, before any transfer codings have been applied (or after all transfer codings have been removed). This definition is consistent with the HTTP entity length definition.
任意の転送コーディングが適用される前にAM-EL値は、HTTPリクエストプロファイルのリクエストボディ部のサイズであり、HTTP応答プロファイルのレスポンスボディ部のサイズ（またはすべての転送コーディングがされた後削除）。この定義は、HTTPエンティティの長さの定義と一致しています。
An OCP agent that knows the exact length of the HTTP message entity (see Section 7.2.2 "Entity Length" in [RFC2616]) at the time it sends the AMS message, SHOULD announce this length using the AM-EL named parameter of an AMS message. If the exact entity length is not known, an OCP agent MUST NOT send an AM-EL parameter. Relaying correct entity length can have significant performance advantages for the recipient, and implementations are strongly encouraged to relay known entity lengths. Similarly, relaying incorrect entity length can have drastic correctness consequences for the recipient, and implementations are urged to exercise great care when relaying entity length.
HTTPメッセージのエンティティの正確な長さを知っているOCPエージェントがAMSメッセージを送信時に（7.2.2項[RFC2616]で「エンティティの長さ」を参照）、のAM-ELという名前のパラメータを使用して、この長さを発表するべきですAMSメッセージ。正確な実体の長さが知られていない場合は、OCPエージェントはAM-ELパラメータを送ってはいけません。正しいエンティティ長さを中継する受信者の大幅なパフォーマンスの利点を有することができ、実装が強く知らエンティティ長を中継することが奨励されます。同様に、間違ったエンティティの長さを中継することは、受信者のための抜本的正しさの影響を持つことができ、および実装は、エンティティの長さを中継する際に細心の注意を払うよう要請しています。
An OPES processor receiving an AM-EL parameter SHOULD use the parameter's value in a Content-Length HTTP entity header when constructing an HTTP message, provided a Content-Length HTTP entity header is allowed for the given application message by HTTP (see Section 3.8.1).
HTTPメッセージを構築する際のContent-Length HTTPエンティティヘッダのパラメータの値を使用する必要がありAM-ELパラメータを受信OPESプロセッサは、コンテンツ長HTTPエンティティヘッダがHTTPによって与えられたアプリケーション・メッセージ（セクション3.8を参照するために許可されました。 1）。
A new named parameter for Data Use Mine (DUM) messages is introduced.
データ使用マイン（DUM）メッセージのための新しい名前付きパラメータが導入されます。
AM-Part: am-part
AM-パート：午前パート
Figure 11
図11
An OCP agent MUST send an AM-Part parameter with every DUM message that is a part of an OCP transaction with an HTTP profile. The AM-Part parameter value is a single am-part token. As implied by the syntax, a DUM message can only contain data of a single application message part. One message part can be fragmented into any number of DUM messages with the same AM-Part parameter.
OCPエージェントは、HTTPプロファイルを持つOCPトランザクションの一部であるすべてのDUMメッセージとAM-パートパラメータを送らなければなりません。 AM-パートのパラメータ値は、単一の午前パートのトークンです。構文によって暗示されるように、DUMメッセージは、単一のアプリケーションメッセージ部のデータを含むことができます。 1つのメッセージ部分は同じAM-パートパラメータとDUMメッセージの任意の数に分割することができます。
The following example shows three DUM messages containing an abridged HTTP response message. The response-body part is fragmented and sent within two DUM messages.
次の例では、要約HTTPレスポンスメッセージを含む3つのDUMメッセージを示しています。レスポンスボディ部分が断片化し、2つのDUMメッセージ内で送信されます。
Example: P: DUM 88 1 0 Kept: 0 AM-Part: response-header
例：P：DUM 88 1 0を保持：0 AM-パート：レスポンスヘッダ
64:HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 51
; P: DUM 88 1 64 Kept: 64 AM-Part: response-body
; P：DUM 88 1 64を保持：64 AM-パート：レスポンスボディ
19:<html><body>This is ; P: DUM 88 1 83 Kept: 83 AM-Part: response-body
19：<HTML> <BODY>これは、 P：DUM 88 1 83を保持：83 AM-パート：応答体
32: a simple message.</body></html> ;
。32：シンプルメッセージ</ BODY> </ HTML>。
Figure 12
図12
The HTTP profile for OCP applies to all HTTP messages. That scope includes HTTP messages such as 1xx (Informational) responses, POST, CONNECT, and OPTIONS requests, as well as responses with extension status codes and requests with extension methods. Unless specifically configured to do otherwise, an OPES processor MUST forward all HTTP messages for adaptation at callout servers. OPES bypass instructions, configured HTTP message handling rules, and OCP-negotiation with a callout server are all examples of an acceptable "specific configuration" that provides an exception to this rule.
OCPのためのHTTPプロファイルには、すべてのHTTPメッセージに適用されます。その範囲は、1XXとしてHTTPメッセージ（情報）応答、POST、CONNECT、およびOPTIONS要求、ならびに拡張ステータスコードと拡張メソッドと要求と応答を含みます。特に他に行うように構成されていない限り、OPESプロセッサは、コールアウトサーバに適応するために、すべてのHTTPメッセージを転送しなければなりません。 OPESバイパス命令、コールアウトサーバと設定されたルールを処理するHTTPメッセージ、およびOCPネゴシエーションは、この規則の例外を提供して許容される「は、特定の構成」のすべての例です。
While it may seem useless to attempt to adapt "control" messages such as a 100 (Continue) response, skipping such messages by default may lead to serious security flaws and interoperability problems. For example, sensitive company information might be relayed via a carefully crafted 100 Continue response; or a malicious CONNECT request may not get logged if OPES processor does not forward these messages to a callout service that is supposed to handle them.
それは、このような100（続行）応答として「制御」のメッセージを適応しようとしても無駄に見えるかもしれませんが、デフォルトではこのようなメッセージをスキップすることは、重大なセキュリティ上の欠陥との相互運用性の問題につながる可能性があります。たとえば、企業の機密情報を慎重に100が応答を続行細工を経由して中継されることがあります。 OPESプロセッサがそれらを処理することになっているコールアウトサービスにこれらのメッセージを転送しない場合や、悪質なCONNECT要求が記録されないことがあります。
By design, OPES processor implementation cannot unilaterally decide that an HTTP message is not worth adapting. It needs a callout server opinion, a configuration setting, or another external information to make the decision.
設計により、OPESプロセッサの実装では、一方的にHTTPメッセージは、適応価値がないと判断することはできません。これは、意思決定をするためにコールアウトサーバの意見、構成設定、または他の外部情報を必要とします。
HTTP defines several hop-by-hop headers (e.g., Connection) and allows for extension headers to be specified as hop-by-hop ones (via the Connection header mechanism). Depending on the environment and configuration, an OPES processor MAY forward hop-by-hop headers to callout servers and MAY use hop-by-hop headers returned by callout servers to build an HTTP message for the next application hop. However, see Section 3.7 for requirements specific to the Transfer-Encoding header.
HTTPは、いくつかのホップバイホップヘッダ（例えば、接続）を定義し、拡張ヘッダは、ホップバイホップもの（接続ヘッダ機構を介して）として指定することを可能にします。環境や設定によっては、OPESプロセッサは、コールアウト・サーバーへのホップバイホップヘッダを転送することができるし、次のアプリケーションのホップのためのHTTPメッセージを構築するためにコールアウトサーバから返されたホップバイホップのヘッダーを使用するかもしれません。しかし、転送-Encodingヘッダーに固有の要件については、3.7節を参照してください。
For example, a logging or statistics collection service may want to see hop-by-hop headers sent by the previous application hop to the OPES processor and/or hop-by-hop headers sent by the OPES processor to the next application hop. Another service may actually handle HTTP logic of removing and adding hop-by-hop headers. Many services will ignore hop-by-hop headers. This specification does not define a mechanism for distinguishing these use cases.
たとえば、ログや統計収集サービスは、次のアプリケーションのホップにOPESプロセッサによって送られたOPESプロセッサおよび/またはホップバイホップヘッダに以前のアプリケーションのホップで送信されたホップバイホップヘッダを見てみたいことがあります。別のサービスは、実際にホップバイホップヘッダを除去し、追加のHTTPロジックを処理することができます。多くのサービスは、ホップバイホップヘッダを無視します。この仕様では、これらのユースケースを区別するためのメカニズムを定義しません。
HTTP messages may use transfer encodings, a hop-by-hop encoding feature of HTTP. Adaptations that use HTTP transfer encodings have to be explicitly negotiated. This specification does not document such negotiations. In the absence of explicit transfer-encoding negotiations, an OCP agent MUST NOT send transfer-encoded application message bodies.
HTTPメッセージは、HTTPのホップバイホップ符号化機能を転送エンコーディングを使用することができます。 HTTP転送エンコーディングを使用する適応は、明示的に交渉する必要があります。この仕様は、そのような交渉を文書化しません。明示的な転送符号化交渉の非存在下で、OCPエージェントが転送コード化されたアプリケーションメッセージ本文を送ってはいけません。
Informally, the above rule means that the agent or its environment have to make sure that all transfer encodings are stripped from an HTTP message body before it enters OCP scope. An agent MUST terminate the OCP transaction if it has to send an application message body but cannot remove all transfer encodings. Violations of these rules lead to interoperability problems.
非公式に、上記のルールは、エージェントまたはその環境が、それはOCPスコープに入る前に、すべての転送エンコーディングは、HTTPメッセージ本体から取り除かれていることを確認しなければならないことを意味します。それはアプリケーションメッセージ本文を送信するために持っていますが、すべての転送エンコーディングを削除することができない場合、エージェントは、OCPトランザクションを終えなければなりません。これらの規則の違反は、相互運用性の問題につながります。
If an OCP agent receives transfer-encoded application data in violation of the above requirement, the agent MAY terminate the corresponding OCP transaction.
OCP剤が上記の要件に違反して転送エンコードされたアプリケーションデータを受信した場合、エージェントは、対応するOCPトランザクションを終了することができます。
An OPES processor removing transfer encodings MUST remove the Transfer-Encoding header before sending the header part to the callout service. A callout server receiving a Transfer-Encoding header MAY assume that original application data is still transfer-encoded (and terminate the transaction). The OPES processor MUST send a correct Transfer-Encoding header to the next HTTP recipient, independent of what header (if any) the callout server returned.
転送エンコーディングを除去OPESプロセッサは、コールアウトサービスにヘッダ部分を送信する前に、転送符号化ヘッダを削除する必要があります。転送符号化ヘッダを受信したコールアウトサーバは、元のアプリケーションデータが符号化された転送（およびトランザクションを終了）ままであると仮定することができます。 OPESプロセッサは、コールアウトサーバが返さどのヘッダ（もしあれば）とは無関係に、次のHTTP受信者に正しい転送符号化ヘッダを送らなければなりません。
Logging and wiretapping are the examples where negotiating acceptable transfer encodings may be worthwhile. While a callout server may not be able to strip an encoding, it may still want to log the entire message "as is". In most cases, however, the callout server would not be able to meaningfully handle unknown transfer encodings.
ロギングおよび盗聴は価値があるかもしれ許容される転送符号化を交渉例です。コールアウトサーバがエンコーディングを取り除くことができないかもしれないが、それはまだ「そのまま」全体のメッセージをログに記録することができます。しかし、ほとんどの場合、コールアウトサーバは、意味のある未知の転送エンコーディングを処理することができません。
When communicating with HTTP applications, OPES processors MUST ensure correctness of all computable HTTP headers documented in specifications that the processors intend to be compliant with. A computable header is defined as a header whose value can be computed based on the message body alone. For example, the correctness of Content-Length and Content-MD5 headers has to be ensured by processors claiming compliance with HTTP/1.1 ([RFC2616]).
HTTPアプリケーションと通信するときに、OPESプロセッサは、プロセッサが準拠するつもり仕様書に記載のすべての計算HTTPヘッダの正確さを確実にしなければなりません。計算ヘッダは、その値のみメッセージ本文に基づいて計算することができるヘッダとして定義されます。例えば、コンテンツ長とContent-MD5ヘッダの正当性は、HTTP / 1.1（[RFC2616]）の遵守を主張プロセッサによって確保されなければなりません。
Informally and by default, the OPES processor has to validate and eventually recalculate, add, or remove computable HTTP headers in order to build a compliant HTTP message from an adapted application message returned by the callout server. If a particular OPES processor trusts certain HTTP headers that a callout service sends, it can use those headers "as is".
非公式と、デフォルトで、OPESプロセッサは、検証し、最終的に再計算し、追加、またはコールアウトサーバから返された適応アプリケーションメッセージから準拠したHTTPメッセージを構築するために計算HTTPヘッダを削除する必要があります。特定のOPESプロセッサは、コールアウト・サービスが送信する特定のHTTPヘッダを信頼している場合、それは「そのまま」これらのヘッダを使用することができます。
An OPES processor MAY forward a partially adapted HTTP message from a callout server to the next callout server, without verifying HTTP header correctness. Consequently, a callout service cannot assume that the HTTP headers it receives are correct or final from an HTTP point of view.
OPESプロセッサはHTTPヘッダ正当性を検証することなく、次のコールアウトサーバにコールアウトサーバーから部分的に適合HTTPメッセージを転送することができます。結果として、コールアウトサービスは、それが受信するHTTPヘッダーがビューのHTTPポイントから正しいまたは最終であると仮定することができません。
The following subsections present guidelines for the recalculation of some HTTP headers.
以下のサブセクションで、いくつかのHTTPヘッダの再計算のための、本ガイドライン。
By default, an OCP agent MUST NOT trust the Content-Length header that is sent within an HTTP header message part. The message length could be modified by a callout service without adaptation of the HTTP message headers.
デフォルトでは、OCPエージェントは、HTTPヘッダーメッセージ部分内で送信されるContent-Lengthヘッダを信用してはいけません。メッセージ長は、HTTPメッセージヘッダの適応なしでコールアウトサービスによって変更することができます。
Before sending the HTTP message to the HTTP peer, the OPES processor has to ensure correctness of the message length indication according to section 4.4 of [RFC2616].
HTTPピアにHTTPメッセージを送信する前に、OPESプロセッサは[RFC2616]のセクション4.4に従ってメッセージ長指示の正当性を保証しなければなりません。
Besides ensuring HTTP message correctness, good OPES processors set up the message to optimize performance, including minimizing delivery latency. Specifically, indicating the end of a message by closing the HTTP connection ought to be the last resort:
HTTPメッセージの正しさを保証する以外に、良好なOPESプロセッサは、配信遅延を最小化するなど、性能を最適化するようにメッセージを設定します。具体的には、HTTP接続を閉じて、メッセージの終了を示すには、最後の手段であるべきです。
o If the callout server sends an AM-EL parameter with its AMS message, the OPES processor SHOULD use this value to create a Content-Length header to be able to keep a persistent HTTP connection. Note that HTTP rules prohibit a Content-Length header to be used in transfer-encoded messages.
コールアウトサーバがAMSメッセージでAM-ELパラメータを送信する場合、O、OPESプロセッサは、永続HTTP接続を維持することができるようにContent-Lengthヘッダを作成するには、この値を使用すべきです。そのHTTPルールが転送エンコードされたメッセージに使用されるContent-Lengthヘッダを禁止注意。
o If AM-EL parameter or equivalent entity length information is not available, and HTTP rules allow for chunked transfer encoding, the OPES processor SHOULD use chunked transfer encoding. Note that any Content-Length header has to be removed in this case.
AM-ELパラメータまたは等価なエンティティ長情報が利用できない、およびHTTPルールはチャンク転送符号化を可能にする場合は、O、OPESプロセッサは、チャンク転送符号化を使用すべきです。任意のContent-Lengthヘッダは、この場合には除去しなければならないことに留意されたいです。
o If the message size is not known a priori and chunked transfer coding cannot be used, but the OPES processor can wait for the OCP transaction to finish before forwarding the adapted HTTP message on a persistent HTTP connection, then the processor SHOULD compute and add a Content-Length header.
Oメッセージサイズは事前に知られ、転送コーディングを使用することができないチャンクが、OPESプロセッサは、プロセッサが計算し、追加すべきである、持続的なHTTP接続に適したHTTPメッセージを転送する前に終了するOCPトランザクションを待つことができますされていない場合Content-Lengthヘッダ。
o Finally, if all optimizations are not applicable, the OPES processor SHOULD delete any Content-Length header and forward adapted data immediately, while indicating the message end by closing the HTTP connection.
Oすべての最適化が適用されない場合は最後に、OPESプロセッサは、任意のContent-Lengthヘッダを削除する必要があり、HTTP接続を閉じて、メッセージ終了を示しているが、すぐに適合データを転送します。
By default, the OPES processor MUST assume that the callout service modifies the content in a way that the MD5 checksum of the message body becomes invalid.
デフォルトでは、OPESプロセッサは、コールアウト・サービスは、メッセージ本文のMD5チェックサムが無効になる方法でコンテンツを変更すると仮定しなければなりません。
According to section 14.15 of [RFC2616], HTTP intermediaries must not generate Content-MD5 headers. A recalculation is therefore possible only if the OPES processor is considered authoritative for the entity being adapted. An un-authoritative OPES processor MUST remove the Content-MD5 header unless it detects that the HTTP message was not modified; in this case, it MAY leave the Content-MD5 header in the message. When such detection significantly increases message latency, deleting the Content-MD5 header may be a better option.
[RFC2616]のセクション14.15によれば、HTTPの仲介は、Content-MD5ヘッダを生成してはなりません。再計算は、OPESプロセッサが適合さエンティティの権限を持つと考えられる場合のみが可能です。それはHTTPメッセージが変更されていないことを検出しない限り、非権威OPESプロセッサは、Content-MD5ヘッダを削除する必要があります。この場合は、メッセージのContent-MD5ヘッダを残すことができます。そのような検出が有意のContent-MD5ヘッダを削除し、メッセージの待ち時間を増加させるときに、より良いオプションであってもよいです。
This is a possible OCP message flow using an HTTP request profile. An end-user wants to access the home page of www.restricted.example.com, through the proxy, but access is denied by a URL blocking service running on the callout server used by the proxy.
これは、HTTPリクエスト・プロファイルを使用可能OCPメッセージフローです。エンドユーザはプロキシを介して、www.restricted.example.comのホーム・ページにアクセスすることを望んでいるが、アクセスは、プロキシが使用するコールアウト・サーバー上で実行されているURLブロッキングサービスによって拒否されます。
OCP messages from the OPES processor are marked with "P:" and OCP messages from the callout server are marked with "S:". The OCP connection is not closed at the end but kept open for the next OCP transaction.
「P：」OPESプロセッサからのOCPのメッセージがでマークされ、コールアウトサーバからOCPメッセージは、「S：」が付いています。 OCP接続は最後に閉じたが、次のOCPトランザクションのために開いたままにされていません。
Example:
P: CS;
S: CS;
P: SGC 11 ({"31:ocp-test.example.com/url-filter"});
P: NO ({"53:http://www.iana.org/assignments/opes/ocp/http/request"})
SG: 11
;
S: NR {"53:http://www.iana.org/assignments/opes/ocp/http/request"}
SG: 11
;
P: TS 55 11;
P: AMS 55
AM-EL: 0
;
P: DUM 55 0
Kept: 0
AM-Part: request-header
235:GET http://www.restricted.example.com/ HTTP/1.1
Accept: */*
Accept-Language: de
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; Windows NT 5.0)
Host: www.restricted.example.com
Proxy-Connection: Keep-Alive
;
P: AME 55;
S: AMS 55;
S: DUM 55 0
AM-Part: response-header
76:HTTP/1.1 403 Forbidden Content-Type: text/html Proxy-Connection: close
76：HTTP / 1.1 403禁止のContent-Type：text / htmlのプロキシ接続：閉じます
; S: DUM 55 0 AM-Part: response-body
; S：DUM 55 0 AM-パート：レスポンスボディ
67:<html><body>You are not allowed to
access this page.</body></html>
;
S: AME 55;
P: TE 55;
S: TE 55;
Figure 13
図13
The next example is a language translation of a small plain text file that gets transferred in an HTTP response. In this example, OCP agents negotiate a profile for the whole OCP connection. The OCP connection remains open in the end of the OCP transaction. (Note that NO and NR messages were rendered with an extra new line to satisfy RFC formatting requirements.)
次の例では、HTTPレスポンスに転送されます小さなテキストファイルの言語の翻訳です。この例では、OCP剤が全体OCP接続のためのプロファイルを交渉します。 OCP接続は、OCPトランザクションの終わりで開いたままになります。 （NOおよびNRメッセージがRFCのフォーマット要件を満たすために余分な改行でレンダリングされたことに注意してください。）
Example:
P: CS;
S: CS;
P: NO
({"54:http://www.iana.org/assignments/opes/ocp/http/response"});
S: NR
{"54:http://www.iana.org/assignments/opes/ocp/http/response"};
P: SGC 12 ({"44:ocp-test.example.com/translate?from=EN&to=DE"});
P: TS 89 12;
P: AMS 89
AM-EL: 86
;
P: DUM 89 0
AM-Part: response-header
65:HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 86
; P: DUM 89 65 AM-Part: response-body
; P：DUM 89 65 AM-パート：レスポンスボディ
86:Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune
;
P: AME 89;
S: AMS 89
AM-EL: 78
;
P: TE 89;
S: DUM 89 0
AM-Part: response-header
65:HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 78
65：HTTP / 1.1 200 OKのContent-Type：text / plainのコンテンツの長さ：78
; S: DUM 89 63 AM-Part: response-body
; S：DUM 89 63 AM-パート：レスポンスボディ
80:Ob's edler im Gemuet, die Pfeil und Schleudern
des wuetenden Geschicks erdulden
;
S: AME 89;
S: TE 89;
Figure 14
図14
The following example shows modification of an HTML resource and demonstrates data preservation optimization. The callout server uses a DUY message to send back an unchanged response header part, but because it does not know the size of the altered HTML resource at the time it sends the AMS message, the callout server omits the AM-EL parameter; the OPES processor is responsible for adjusting the Content-Length header.
次の例では、HTMLリソースの変更を示しており、データ保存の最適化を示しています。コールアウトサーバは変わらないレスポンスヘッダ部を返送するDUYメッセージを使用していますが、それはそれはAMSメッセージを送る時に変更されたHTMLリソースのサイズを知らないので、コールアウトサーバは、AM-ELパラメータを省略します。 OPESプロセッサは、Content-Lengthヘッダを調整するための責任があります。
Example:
P: CS;
S: CS;
P: SGC 10 ({"30:ocp-test.example.com/ad-filter"});
P: NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header,request-body)
},{"45:http://www.iana.org/assignments/opes/ocp/MIME"})
SG: 10
;
S: NR {"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header)
Content-Encodings: (gzip)
}
SG: 10
;
P: TS 88 10;
P: AMS 88
AM-EL: 95
;
P: DUM 88 0
AM-Part: request-header
65:GET /opes/adsample.html HTTP/1.1 Host: www.martin-stecher.de
65：GET /opes/adsample.html HTTP / 1.1ホスト：www.martin-stecher.de
; P: DUM 88 65
; P：DUM 88 65
Kept: 65 64 AM-Part: response-header
維持：65 64 AM-パート：レスポンスヘッダ
64:HTTP/1.1 200 OK Content-Type: text/html Content-Length: 95
64：HTTP / 1.1 200 OKのContent-Type：text / htmlでのコンテンツの長さ：95
; P: DUM 88 129 Kept: 65 90 AM-Part: response-body
; P：DUM 88 129を保持：65 90 AM-パート：レスポンスボディ
26:<html>
<body>
This is my
;
S: AMS 88;
P: DUM 88 155
Kept: 65 158
AM-Part: response-body
68: new ad: <img src="my_ad.gif"
width=88 height=31>
</body>
</html>
;
S: DUY 88 65 64
S: DPI 88 129 2147483647;
P: AME 88;
S: DUM 88 0
AM-Part: response-body
52:<html>
<body>
This is my new ad:
</body>
</html>
;
S: DPI 88 129 0;
P: TE 88;
S: AME 88;
S: TE 88;
Figure 15
図15
[RFC3897] defines application-agnostic tracing facilities in OPES. Compliance with this specification requires compliance with [RFC3897]. When adapting HTTP, trace entries are supplied using HTTP message headers. The following HTTP extension headers are defined to carry trace entries. Their definitions are given using BNF notation and elements defined in [RFC2616].
[RFC3897]はOPESアプリケーションに依存しないトレース機能を定義します。この仕様に準拠するには、[RFC3897]の遵守が必要です。 HTTPを適応すると、トレース・エントリーは、HTTPメッセージのヘッダを使用して供給されています。次のHTTP拡張ヘッダは、トレース・エントリーを運ぶために定義されています。その定義は、BNF記法と[RFC2616]で定義された要素を使用して与えられています。
OPES-System = "OPES-System" ":" #trace-entry
OPES-Via = "OPES-Via" ":" #trace-entry
trace-entry = opes-agent-id *( ";" parameter ) opes-agent-id = absoluteURI
トレースエントリ= OPES剤-ID *を（ ";" パラメータ）OPES剤-ID = absoluteURIで
Figure 16
図16
An OPES System MUST add its trace entry to the OPES-System header. Other OPES agents MUST use the OPES-Via header if they add their tracing entries. All OPES agents MUST append their entries. Informally, OPES-System is the only required OPES tracing header while OPES-Via provides optional tracing details; both headers reflect the order of trace entry additions.
OPESシステムは、OPES-システムヘッダにそのトレースエントリを追加する必要があります。彼らは彼らのトレースのエントリを追加した場合、他のOPESエージェントは、OPES-Viaヘッダーを使用しなければなりません。すべてのOPESエージェントは、自分のエントリを追加しなければなりません。非公式に、OPES-システムOPES-VIAは任意のトレースの詳細を提供しながら、ヘッダをトレースのみ必要OPESあります。両方のヘッダには、トレース・エントリーの追加の順序を反映しています。
If an OPES-Via header is used in the original application message, an OPES System MUST append its entry to the OPES-Via header. Otherwise, an OPES System MAY append its entry to the OPES-Via header. If an OPES System is using both headers, it MUST add identical trace entries except it MAY omit some or all trace-entry parameters from the OPES-Via header. Informally, the OPES System entries in the OPES-Via header are used to delimit and group OPES-Via entries from different OPES Systems without having a priory knowledge about OPES System identifiers.
OPES-VIAヘッダが元のアプリケーションメッセージで使用される場合、OPESシステムはOPES-Viaヘッダーにそのエントリを追加する必要があります。それ以外の場合は、OPESシステムはOPES-Viaヘッダーにそのエントリを追加するかもしれません。 OPESシステムは、両方のヘッダを使用している場合、それはOPES-Viaヘッダから一部またはすべてのトレース・エントリーのパラメータを省略してもよい（MAY）を除いて、同一のトレースエントリを追加する必要があります。非公式に、OPES-VIAヘッダ内OPESシステムエントリはOPESシステム識別子に関するプライオリ知識を有することなく、異なるOPESシステムからOPES-VIAエントリを区切るとグループ化するために使用されます。
Note that all of these headers are defined using #list constructs and, hence, a valid HTTP message may contain multiple trace entries per header. OPES agents SHOULD use a single header-field rather than using multiple equally-named fields to record a long trace. Using multiple equally-named extension header-fields is illegal from HTTP's point of view and may not work with some of the OPES-unaware HTTP proxies.
したがって、有効なHTTPメッセージはヘッダごとに複数のトレース項目を含んでいてもよい、これらのヘッダの全てが#list構築物を用いて定義されていることに注意してくださいと。 OPESエージェントは、かなり長いトレースを記録するために、複数の均等という名前のフィールドを使用するよりも単一のヘッダフィールドを使用すべきです。複数の均等な名前の拡張ヘッダフィールドを使用すると、ビューのHTTPの観点から違法であり、OPES非対応のHTTPプロキシの一部では動作しない場合があります。
For example, here is an HTTP response message header after OPES adaptations have been applied by a single OPES processor executing 10 OPES services:
例えば、ここでOPES適応が10のOPESサービスを実行する単一OPESプロセッサによって適用された後、HTTPレスポンスメッセージのヘッダです。
Example: HTTP/1.1 200 OK Date: Thu, 18 Sep 2003 06:25:24 GMT Last-Modified: Wed, 17 Sep 2003 18:24:25 GMT Content-type: application/octet-stream OPES-System: http://www.cdn.example.com/opes?session=ac79a749f56 OPES-Via: http://www.cdn.example.com/opes?session=ac79a749f56, http://www.srvcs-4u.example.com/cat/?sid=123, http://www.srvcs-4u.example.com/cat/?sid=124, http://www.srvcs-4u.example.com/cat/?sid=125 ; mode=A
例：HTTP / 1.1 200 OK日：木、2003年9月18日6時25分24秒GMTのLast-Modified：水曜日、2003年9月17日18時24分25秒GMTのコンテンツタイプ：アプリケーション/ octet-streamとOPES-システム：のhttp： //www.cdn.example.com/opes?session=ac79a749f56 OPES-経由：http://www.cdn.example.com/opes?session=ac79a749f56、http://www.srvcs-4u.example.com ？/猫/ SID = 123、http://www.srvcs-4u.example.com/cat/?sid=124、http://www.srvcs-4u.example.com/cat/?sid=125。モード= A
Figure 17
図17
In the above example, the OPES processor has not included its trace entry or its trace entry was replaced by an OPES system trace entry. Only 3 out of 10 services are traced. The remaining services did not include their entries or their entries were removed by OPES system or processor. The last traced service included a "mode" parameter. Various identifiers in trace entries will probably have no meaning to the recipient of the message, but may be decoded by OPES System software.
上記の例では、OPESプロセッサは、そのトレース項目が含まれていないか、トレースエントリがOPESシステム・トレース・エントリに置き換えました。わずか3 10のうちのサービスがトレースされます。残りのサービスは、そのエントリが含まれていなかったか、そのエントリはOPESシステムまたはプロセッサによって除去しました。最後にトレースされたサービスは、「モード」のパラメータが含まれています。トレースエントリ内の様々な識別子は、おそらく、メッセージの受信者には何の意味もありませんが、OPESシステムソフトウェアによって復号化することができます。
OPES entities MAY place optional tracing entries in a message trailer (i.e., entity-headers at the end of a Chunked-Body of a chunked-encoded message), provided trailer presence does not violate HTTP protocol. See [RFC3897] for a definition of what tracing entries are optional. OPES entities MUST NOT place required tracing entries in a message trailer.
OPESエンティティ（すなわち、チャンクエンコードされたメッセージのチャンクボディーの端部におけるエンティティヘッダ）、提供トレーラの存在は、HTTPプロトコルに違反していないメッセージ・トレーラーに任意のトレースのエントリを置くことができます。トレースエントリはオプションであるかの定義については、[RFC3897]を参照してください。 OPESエンティティは、メッセージのトレーラーに必要なトレースのエントリを配置してはならず。
An HTTP extension header is introduced to allow for OPES system bypass as defined in [RFC3897].
HTTP拡張ヘッダは、[RFC3897]で定義されるようにOPESシステムバイパスを可能にするために導入されます。
OPES-Bypass = "OPES-Bypass" ":" ( "*" | 1#bypass-entry ) bypass-entry = opes-agent-id
OPESバイパス= "OPESバイパス" "："（ "*" | 1＃バイパスエントリー）バイパスエントリー= OPESエージェント-ID
Figure 18
図18
This header can be added to HTTP requests to request OPES system bypass for the listed OPES agents. The asterisk "*" character is used to represent all possible OPES agents.
このヘッダは、列挙されたOPESエージェントのOPESシステムバイパスを要求するHTTPリクエストに追加することができます。アスタリスク「*」の文字は、すべての可能なOPESエージェントを表すために使用されます。
See [RFC3897] for what can be bypassed and for bypass requirements.
バイパスすることができます何のために、バイパスの要件については、[RFC3897]を参照してください。
OPES treatment of IETF Internet Architecture Board (IAB) considerations [RFC3238] are documented in "OPES Treatment of IAB Considerations" [RFC3914].
IETFインターネットアーキテクチャ委員会（IAB）の考察[RFC3238]のOPES処理は "IABの考慮事項のOPES治療" [RFC3914]に記載されています。
Application-independent security considerations are documented in application-agnostic OPES specifications. HTTP profiles do not introduce any HTTP-specific security considerations. However, that does not imply that HTTP adaptations are immune from security threats.
アプリケーションに依存しないセキュリティ上の考慮事項は、アプリケーションに依存しないOPES仕様に記載されています。 HTTPプロファイルは、任意のHTTP固有のセキュリティの考慮事項を導入しません。しかし、それは、HTTPの適応は、セキュリティ上の脅威から免疫があることを意味するものではありません。
Specific threat examples include such adaptations as rewriting the Request-URI of an HTTP CONNECT request or removing an HTTP hop-by-hop Upgrade header before the HTTP proxy can act on it. As with any adaptation, the OPES agents MUST NOT perform such actions without HTTP client or server consent.
具体的な脅威の例としては、HTTP CONNECT要求のリクエストURIを書き換えるか、HTTPプロキシがそれに作用することができる前に、HTTPホップバイホップアップグレードヘッダを除去するなどの適応を含みます。任意の適応と同様に、OPESエージェントは、HTTPクライアントまたはサーバの同意なしに、このようなアクションを実行してはなりません。
The IANA registers request and response profile features (Section 3.2) using the registration procedure outlined in the "IANA Considerations" Section of OCP Core [RFC4037]. The corresponding "uri" parameters for the two features are:
IANAは、OCPコアの「IANAの考慮事項」セクション[RFC4037]に概説登録手順を使用して要求と応答プロファイル機能（セクション3.2）を登録します。二つの特徴に対応する「URI」パラメータは次のとおりです。
o http://www.iana.org/assignments/opes/ocp/http/request
お ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／おぺｓ／おｃｐ／ｈっｔｐ／れくえｓｔ
o http://www.iana.org/assignments/opes/ocp/http/response
お ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／おぺｓ／おｃｐ／ｈっｔｐ／れｓぽんせ
Compliance with OPES mechanisms is defined in corresponding application-agnostic specifications. HTTP profiles for these mechanisms use corresponding compliance definitions from these specifications, as if each profile were incorporated into the application-agnostic specification it profiles.
OPESメカニズムの遵守は、アプリケーションに依存しない仕様対応で定義されています。各プロファイルは、それがプロファイルのアプリケーションに依存しない仕様に組み込まれたかのようにこれらのメカニズムのためのHTTPプロファイルは、これらの仕様から対応コンプライアンスの定義を使用します。
[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.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC3897] Barbir, A., "Open Pluggable Edge Services (OPES) Entities and End Points Communication", RFC 3897, September 2004.
[RFC3897] Barbir、A.、 "オープンプラグイン可能なエッジサービス（OPES）エンティティとエンドポイントのコミュニケーション"、RFC 3897、2004年9月。
[RFC4037] Rousskov, A., "Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core", RFC 4037, March 2005.
[RFC4037] Rousskov、A.、 "オープンプラグイン可能なエッジサービス（OPES）コールアウトプロトコル（OCP）コア"、RFC 4037、2005年3月。
[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.、Penno、R.、陳、R.、ホフマン、M.、およびH.オーマン、 "オープン・プラグイン可能なエッジサービスのためのアーキテクチャ（OPES）"、RFC 3835、2004年8月。
[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.、オーマン、H.、Penno、R.、およびA. Terzis、 "オープンプラグイン可能なエッジサービスの要件（OPES）コールアウトプロトコル"、RFC 3836、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.、スリニバス、B.、ホフマン、M.、およびH.オーマン、 "オープンプラグイン可能なエッジサービスのセキュリティの脅威とリスク（OPES）"、RFC 3837、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.、オーマン、H.、およびR. Penno、 "オープン・プラグイン可能なエッジサービス（OPES）ケースと展開シナリオを使用する"、RFC 3752 、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.オーマン、 "ポリシー、認可、及びオープンプラグイン可能なエッジサービス（OPES）の施行要件"、RFC 3838、 2004年8月。
[rules-p] Beck, A. and A. Rousskov, "P: Message Processing Language", work in progress, October 2003.
[ルール-P]ベック、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の考慮事項のオープンプラグイン可能なエッジ・サービス（OPES）治療"、RFC 3914、2004年10月。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[RFC3238]フロイド、S.とL. Daigle氏、 "オープン・プラグイン可能なエッジサービスのためのIAB建築・ポリシーに関する注意事項"、RFC 3238、2002年1月。
Acknowledgements
謝辞
The authors gratefully acknowledge the contributions of Robert Collins (Syncretize) and Larry Masinter (Adobe). Larry Masinter provided an early review of this document.
作者は感謝ロバート・コリンズ（Syncretize）とラリーMasinter（アドビシステムズ社）の貢献を認めます。ラリーMasinterは、この文書の早期見直しを提供しました。
Authors' Addresses
著者のアドレス
Alex Rousskov The Measurement Factory
アレックスRousskovザ・計測ファクトリー
EMail: rousskov@measurement-factory.com URI: http://www.measurement-factory.com/
電子メール：rousskov@measurement-factory.com URI：http://www.measurement-factory.com/
Martin Stecher CyberGuard Corporation Vattmannstr. 3 Paderborn 33100 DE
マーティンStecherサイバーガードコーポレーションVattmannstr。 3 33100パーダーボルンDE
EMail: martin.stecher@webwasher.com URI: http://www.webwasher.com/
電子メール：martin.stecher@webwasher.com URI：http://www.webwasher.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。