[要約] RFC 4236は、Open Pluggable Edge Services（OPES）を使用したHTTP適応に関するものであり、その目的は、ネットワークエッジでのHTTPトラフィックの変更や改変を可能にするためのフレームワークを提供することです。
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)
Open Pluggable Edge Services（OPES）によるHTTP適応
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).
Copyright（c）The Internet Society（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.
Open Pluggable Edge Services（OPES）フレームワークは、OPESトレース、OPESバイパス、OPESコールアウトプロトコルなど、いくつかのアプリケーションに依存しないメカニズムを文書化します。このドキュメントは、HyperText Transfer Protocol（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.
Open Pluggable Edge Services（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.
o 「OPESユースケースと展開シナリオ」に関するドキュメント[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.
o 「OPESのセキュリティの脅威とリスク」[RFC3837]は、特定のソリューションを推奨せずに、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].
o OPESアーキテクチャのコアには、OPESプロセッサとCallout Serverがあります。これは、Opes Callout Protocol（OCP）を介して相互に通信する2つのネットワーク要素です。このようなプロトコルの要件は、「Opes Callout Protocolsの要件」[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 Callout Protocol Core」[RFC4037]は、OPESプロセッサとCallout Server間の通信に使用されるアプリケーション不可知論的プロトコルコアを指定します。
o "OPES entities and end points communications" [RFC3897] specifies generic tracing and bypass mechanisms for OPES.
o 「OPESエンティティとエンドポイント通信」[RFC3897]は、OPEの一般的なトレースとバイパスメカニズムを指定します。
o The OCP Core and Communications documents are independent from the application protocol being adapted by OPES entities. Their
o OCPコアおよび通信ドキュメントは、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のアプリケーションプロファイルです。HTTPメッセージの適応をサポートするために、アプリケーションに依存しないOPESメカニズムを使用および拡張する方法を指定します。
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：メッセージ処理言語」[Rules-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 Callout Protocol（OCP）Core [RFC4037]のHTTPプロファイルを文書化します。HTTPプロファイルを理解するには、OCPコアに精通しています。このセクションでは、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メッセージの適応をサポートするCallout Serverは、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メッセージの長さを通信するために、アプリケーションメッセージ開始（AMS）メッセージの新しいパラメーターを導入します（HTTPヘッダーは、長さの情報を確実にまたはまったく伝えないことがよくあります）。このパラメーターは、セクション3.3に文書化されています。セクション3.4は、データを使用してHTTPメッセージパーツを鉱山（DUM）メッセージを使用して報告するメカニズムを文書化します。
The remaining OCP sections document various OCP marshaling corner cases such as handling of HTTP transfer encodings and 100 Continue responses.
残りのOCPセクションは、HTTP転送エンコーディングの処理や100の継続応答など、さまざまなOCPマーシャリングコーナーケースを文書化します。
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 Opesプロセッサは、HTTPヘッダーを分離および解釈し、HTTPメッセージの境界を見つける必要があるため、HTTPメッセージパーツに関する情報を持っている可能性があります。Callout Serverは、特定の部品を気にしないか、興味深い部品の分離と分類に関するHTTP Opesプロセッサ作業を再利用することで利益を得ることがあります。
The following is the declaration of am-part (application message part) type using OCP Core Protocol Element Type Declaration Mnemonic (PETDM):
以下は、OCPコアプロトコル要素タイプ宣言Mnemonic（PETDM）を使用したAM-PART（アプリケーションメッセージパーツ）タイプの宣言です。
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-PART」原子は有効な値です。
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]).
Request-Header：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].
Request-Trailer：Chunked Transfer Encodingの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]).
Response-Header：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.
Response-Body：[RFC2616]のセクション4.3で定義されているHTTP応答メッセージのメッセージ本文は、トレーラーを含めません。
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].
Response-Trailer：Chunked Transfer Encodingの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）、request-body（aux）、request-trailer（aux）、response-header、response-body、response-trailer
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.
リクエストプロファイルには、適応されたパーツリストの2つのバリアントが含まれています。HTTPリクエストパーツとHTTP応答パーツ。「（aux）」の接尾辞でマークされたパーツは、プロファイルに対して明示的にネゴシエートされた場合にのみ使用できる補助パーツです。AM-PARTSの交渉と使用を管理する特定のルールについては、セクション3.2.1を参照してください。
The scope of a negotiated profile is the OCP connection (default) or the service group specified via the SG parameter.
ネゴシエートされたプロファイルの範囲は、SGパラメーターを介して指定されたOCP接続（デフォルト）またはサービスグループです。
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-Parts（セクション3.2.3）パラメーターを介して交渉された現在の補助部品を送信する必要があります。OCPエージェントは、Aux-Parts（セクション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
リクエストプロファイルでは、CallOutサーバーはどちらかの適応を送信する必要があります
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トランザクションを終了する必要があります。非公式には、Callout Serverは、適応されたHTTPリクエストを転送せずにOPESプロセッサにHTTP応答を返すように強制され、Adapted Response Partsを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 AUX-PARTS（セクション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 Preservation-Interest-body（セクション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-PARTSパラメーターを使用して、補助アプリケーションメッセージパーツを元のデータフローに含めることをネゴシエートすることができます。パラメーターは、AM-PARTトークンの空のリストです。OPESプロセッサは、Aux-Partsパラメーターを送信して、補助アプリケーションメッセージパーツの可用性を宣伝する場合があります。コールアウトサーバーは、必要な部品の空のサブセットで応答する場合があります。Callout Serverの応答は、正常にネゴシエートされた補助メッセージパーツのサブセットを定義します。
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 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.
ネゴシエーションオファー（NO）メッセージを受信する場合、CallOutサーバーはAux-Partsパラメーターにリストされている非酸化部品を無視する必要があります。ネゴシエーション応答（NR）メッセージを送信する場合、Calloutサーバーは、ネゴシエーションオファーに明示的にリストされていないアプリケーションメッセージパーツを選択してはなりません。最後のルールに違反した場合、OPESプロセッサはトランザクションを終了する必要があります。
An OPES processor MUST send each negotiated auxiliary part to the callout server, unless the part is absent.
OPESプロセッサは、部品が存在しない限り、各交渉済みの補助部品をCalloutサーバーに送信する必要があります。
Example: Aux-Parts: (request-header,request-body)
例：aux-parts ：（リクエストヘッダー、リクエストボディ）
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.
Callout Serverは、元のデータフローが開始される前に、元のアプリケーションメッセージボディ送信で一時停止を要求して、ボディの一時停止パラメーターを使用する場合があります。パラメーターの値は「オフセット」タイプです。パラメーターは、送信者が一時的に見ることに興味がないという非酸化アプリケーションメッセージボディサフィックスの開始を指定します。
[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.
たとえば、一時停止のボディ値がゼロの場合、OPESプロセッサは、HTTP応答プロファイルの応答ボディパーツを含む最初のデータ使用鉱山（DUM）メッセージを送信する直前に、MYデータ（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).
Callout Serverは、STOP-Receiving-Bodyパラメーターを使用して、元のデータフローが開始される前に、データの受信データ（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.
Callout Serviceは、停止データを受信するプロファイル（DWSR）メッセージが送信されるプロファイルのすべてのトランザクションに対して、メッセージ本文に固定オフセットがある場合、交渉応答を備えたストップレシーブボディパラメーターを送信する場合があります。OPESプロセッサは、対応するオフセットでDWSRメッセージを受信したかのように動作する必要があります。後者のオフセットは、ストップレシーブボディオフセットとは異なり、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プロセッサは、応答ヘッダーメッセージパーツを送信した直後に、Response-Bodyメッセージパーツを開始する直後に、アプリケーションメッセージエンド（AME）メッセージを結果コード206に送信する必要があります。
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).
Preservation-Interest-Bodyパラメーターを使用して、OPESプロセッサでのデータ保存を最適化できます。パラメーターの値は「サイズ」のタイプであり、元の非酸化メッセージ本文部品のプレフィックスサイズ（HTTPリクエストボディのリクエストボディと応答プロファイルの応答ボディ）を個別化します。
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.
Callout Serviceは、データ保存関心（DPI）メッセージが送信されるアプリケーションメッセージ本文の固定サイズのプレフィックスがある場合、交渉対応を備えた保存Interest-Bodyパラメーターを送信する場合があります。OPESプロセッサは、ORG-Offset Zeroを使用してDPIメッセージを受信し、Org-SizeがPreservation-Interest-Bodyパラメーターの値に等しいように動作する必要があります。
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応答プロファイルで保存利益体の値がゼロの場合、calloutサーバーは、応答体の部分に対してデータを使用してデータを送信してはなりません。OPESプロセッサは、データを保存することを決定する前であっても、この情報を使用してデータ保存動作を最適化する場合があります。
Example: Preservation-Interest-Body: 0
例：Preservation-Interest-Body：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.
Calloutサーバーは、コンテンツエンコードリストを送信して、コンテンツエンコーディングの好みを示す場合があります。最初にリストされているエンコーディングは、他のエンコーディングよりも推奨されます。OPESプロセッサは、Calloutサーバーにアプリケーションメッセージを送信するときにエンコードを使用する任意のコンテンツを使用できます。
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)
例：Content-Encodings ：（ 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プロセッサによる交渉の申し出を示しています。Calloutサーバーは、適切なネゴシエーション応答を送信します。
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.
Callout Serverは、補助リクエストヘッダーパーツをリクエストしますが、リクエストボディパーツを受信することには関心がありません。
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.
Calloutサーバーは、サイズゼロの保存Interest-Bodyパラメーターを介して、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の一時停止値を送信することにより、Callout Serverはデータの一時停止を要求します。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エージェント（[RFC2616]のセクション7.2.2 "エンティティの長さ」を参照）は、AMSメッセージを送信する時点で、AMSメッセージのAM-ELという名前のパラメーターを使用してこの長さを発表するはずです。正確なエンティティの長さが不明な場合、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).
AM-ELパラメーターを受信するOPESプロセッサは、HTTPによるコンテンツレングスのHTTPエンティティヘッダーがHTTPのアプリケーションメッセージに対して許可されている場合、HTTPメッセージを構築する際に、コンテンツ長HTTPエンティティヘッダーでパラメーターの値を使用する必要があります（セクション3.8.1を参照）。
A new named parameter for Data Use Mine (DUM) messages is introduced.
データ使用鉱山（DUM）メッセージの新しい名前のパラメーターが導入されています。
AM-Part: am-part
AM-PART：AM-PART
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トランザクションの一部であるすべてのダムメッセージを含むAM-PARTパラメーターを送信する必要があります。AM-PARTパラメーター値は、単一のAM-PARTトークンです。構文で暗示されているように、ダムメッセージには単一のアプリケーションメッセージパーツのデータのみを含めることができます。1つのメッセージ部分は、同じAM-PARTパラメーターを持つ任意の数のダムメッセージに断片化できます。
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つのダムメッセージを示しています。応答体部分は断片化され、2つのダムメッセージ内で送信されます。
Example: P: DUM 88 1 0 Kept: 0 AM-Part: response-header
例：P：Dum 88 1 0 Keep：0 am-part：Response-Header
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：ダム88 1 64キープ：64 AMパート：応答ボディ
19:<html><body>This is
;
P: DUM 88 1 83
Kept: 83
AM-Part: response-body
32: a simple message.</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メッセージ、および拡張ステータスコードと拡張メソッドのリクエストなどの応答が含まれます。特別に構成されていない限り、OPESプロセッサは、Calloutサーバーでの適応のためにすべてのHTTPメッセージを転送する必要があります。OPESバイパス命令、構成されたHTTPメッセージ処理ルール、およびCallOutサーバーを使用した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プロセッサがこれらのメッセージを処理するはずのコールアウトサービスに転送しない場合、悪意のある接続要求が記録されない場合があります。
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メッセージが適応する価値がないことを一方的に決定することはできません。決定を下すには、Callout Serverの意見、構成設定、または別の外部情報が必要です。
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メッセージを作成できます。ただし、転送エンコードヘッダーに固有の要件については、セクション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.
ロギングと盗聴は、許容可能な転送エンコーディングを交渉する価値がある可能性のある例です。CallOutサーバーはエンコードをストリップできない場合がありますが、「現状のまま」メッセージ全体をログインしたい場合があります。ただし、ほとんどの場合、Callout Serverは不明な転送エンコーディングを有意義に処理することはできません。
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ヘッダーの正しさを確保する必要があります。計算可能なヘッダーは、メッセージ本文のみに基づいて値を計算できるヘッダーとして定義されます。たとえば、HTTP/1.1（[RFC2616]）のコンプライアンスを主張するプロセッサによって、コンテンツレングスとコンテンツMD5ヘッダーの正確性を確保する必要があります。
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プロセッサは、Callout Serverによって返された適応アプリケーションメッセージから準拠した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ヘッダーの正確性を確認せずに、Calloutサーバーから次のCalloutサーバーに部分的に適合した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ヘッダーメッセージパーツ内で送信されるコンテンツ長ヘッダーを信頼してはなりません。メッセージの長さは、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.
o Callout ServerがAMSメッセージを含むAM-ELパラメーターを送信する場合、OPESプロセッサはこの値を使用してコンテンツ長ヘッダーを作成して、永続的なHTTP接続を維持できるようにする必要があります。HTTPルールは、コンテンツ長ヘッダーが転送エンコードメッセージで使用されることを禁止していることに注意してください。
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.
o AM-ELパラメーターまたは同等のエンティティの長さ情報が利用できない場合、HTTPルールがチャンクされた転送エンコードを許可する場合、OPESプロセッサはチャンク転送エンコードを使用する必要があります。この場合、コンテンツ長ヘッダーを削除する必要があることに注意してください。
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プロセッサがOCPトランザクションが終了するのを待ってから、永続的なHTTP接続で適応されたHTTPメッセージを転送することができます。
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プロセッサは、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チェックサムが無効になるように、Callout Serviceがコンテンツを変更すると想定する必要があります。
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プロセッサがエンティティが適応されているために権威あると見なされる場合にのみ、再計算が可能です。非著作的なOPESプロセッサは、HTTPメッセージが変更されていないことを検出しない限り、コンテンツMD5ヘッダーを削除する必要があります。この場合、コンテンツMD5ヘッダーをメッセージに残す場合があります。このような検出がメッセージの遅延を大幅に増加させる場合、コンテンツ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のホームページにアクセスしたいと考えていますが、プロキシで使用されているCallout Serverで実行されている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.
OPESプロセッサからのOCPメッセージには「P：」がマークされており、Calloutサーバーからの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
; S: DUM 55 0 AM-Part: response-body
;S：Dum 55 0 Am-Part：Response-body
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
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
; S: DUM 89 63 AM-Part: response-body
;S：DUM 89 63 AM-PART：Response-Body
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リソースの変更を示し、データの保存最適化を示しています。Callout ServerはDUYメッセージを使用して変更されていない応答ヘッダーパーツを送信しますが、AMSメッセージを送信する時点で変更されたHTMLリソースのサイズがわからないため、Callout ServerはAM-ELパラメーターを省略します。OPESプロセッサは、コンテンツ長ヘッダーの調整を担当します。
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 /pes/adsample.html http/1.1ホスト：www.martin-stecher.de
; P: DUM 88 65
;P：ダム88 65
Kept: 65 64 AM-Part: response-header
維持：65 64 AM-PART：Response-Header
64:HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 95
; P: DUM 88 129 Kept: 65 90 AM-Part: response-body
;P：Dum 88 129 Keep：65 90 AM-PART：Response-Body
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拡張ヘッダーは、トレースエントリを運ぶために定義されています。それらの定義は、[RFC2616]で定義されているBNF表記と要素を使用して与えられます。
OPES-System = "OPES-System" ":" #trace-entry
OPES-Via = "OPES-Via" ":" #trace-entry
trace-entry = opes-agent-id *( ";" parameter )
opes-agent-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-systemはヘッダーをトレースする唯一の必要なOPESであり、Opes-Viaはオプションのトレースの詳細を提供します。両方のヘッダーは、トレースエントリの追加の順序を反映しています。
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ヘッダーからの一部またはすべてのトレースエントリーパラメーターを省略することを除いて、同一のトレースエントリを追加する必要があります。非公式には、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.
これらのヘッダーはすべて#LISTコンストラクトを使用して定義されているため、有効なHTTPメッセージにはヘッダーごとに複数のトレースエントリが含まれる場合があることに注意してください。OPESエージェントは、複数の等しく名前のフィールドを使用して長いトレースを記録するのではなく、単一のヘッダーフィールドを使用する必要があります。複数の名前の拡張ヘッダーフィールドを使用することは、HTTPの観点から違法であり、Opes-Unaware 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
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システムトレースエントリに置き換えられました。10のサービスのうち3つだけがトレースされています。残りのサービスには、エントリやエントリがOPESシステムまたはプロセッサによって削除されませんでした。最後にトレースされたサービスには、「モード」パラメーターが含まれていました。Traceエントリのさまざまな識別子は、おそらくメッセージの受信者に意味がないでしょうが、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].
[RFC3897]で定義されているように、OPESシステムバイパスを可能にするために、HTTP拡張ヘッダーが導入されています。
OPES-Bypass = "OPES-Bypass" ":" ( "*" | 1#bypass-entry )
bypass-entry = opes-agent-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.
このヘッダーは、HTTPリクエストに追加して、リストされているOPESエージェントのOPESシステムバイパスを要求できます。アスタリスク「*」文字は、すべての可能な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接続要求のリクエスト-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 Core [RFC4037]の「IANA考慮事項」セクションで概説されている登録手順を使用して、リクエストと応答のプロファイル機能（セクション3.2）を登録します。2つの機能の対応する「URI」パラメーターは次のとおりです。
o http://www.iana.org/assignments/opes/ocp/http/request
o
o http://www.iana.org/assignments/opes/ocp/http/response
o
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プロファイルは、各プロファイルがアプリケーションと存在する仕様ITプロファイルに組み込まれているかのように、これらの仕様から対応するコンプライアンス定義を使用します。
[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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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。、「Open Pluggable Edge Services（OPES）エンティティとエンドポイント通信」、RFC 3897、2004年9月。
[RFC4037] Rousskov, A., "Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core", RFC 4037, March 2005.
[RFC4037] Rousskov、A。、「Open Pluggable Edge Services（OPES）Callout Protocol（OCP）Core」、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.、Chen、R.、Hofmann、M。、およびH. Orman、「Open Pluggable Edge Services（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] Beck、A.、Hofmann、M.、Orman、H.、Penno、R。、およびA. Terzis、「Open Pluggable Edge Services（OPES）Callout Protocolsの要件」、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.、Srinivas、B.、Hofmann、M。、およびH. Orman、「Open Pluggable Edge Services（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.、Burger、E.、Chen、R.、Mchenry、S.、Orman、H.、およびR. Penno、「Open Pluggable Edge Services（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.、Beck、A.、Chan、T。、およびH. Orman、「Open Pluggable Edge Services（OPES）のポリシー、承認、および執行要件」、RFC 3838、2004年8月。
[rules-p] Beck, A. and A. Rousskov, "P: Message Processing Language", work in progress, October 2003.
[Rules-P] Beck、A。and 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] Floyd、S。およびL. Daigle、「Open Pluggable Edge Servicesの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.
著者は、ロバート・コリンズ（同期）とラリー・マスインター（Adobe）の貢献に感謝しています。Larry Masinterは、このドキュメントの早期レビューを提供しました。
Authors' Addresses
著者のアドレス
Alex Rousskov The Measurement Factory
Alex Rousskov測定工場
EMail: rousskov@measurement-factory.com
URI: http://www.measurement-factory.com/
Martin Stecher CyberGuard Corporation Vattmannstr. 3 Paderborn 33100 DE
Martin Stecher Cyberguard Corporation Vattmannnst。3 Paderborn 33100 de
EMail: martin.stecher@webwasher.com
URI: http://www.webwasher.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。