Network Working Group A. Barbir
Request for Comments: 3914 Nortel Networks
Category: Informational A. Rousskov
The Measurement Factory
October 2004
Open Pluggable Edge Services (OPES) Treatment of
IAB Considerations
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations.
IETFインターネットアーキテクチャ委員会（IAB）は、オープンプラグイン可能なエッジ・サービス（OPES）フレームワークの9アーキテクチャ・レベルの考慮事項を表明しました。この文書は、OPESは、これらの考慮事項を扱う方法を説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Consideration (2.1) 'One-party consent' . . . . . . . . . . . 3
4. Consideration (2.2) 'IP-layer communications' . . . . . . . . 4
5. Notification Considerations . . . . . . . . . . . . . . . . . 5
5.1. Notification versus trace. . . . . . . . . . . . . . . . 6
5.2. An example of an OPES trace for HTTP . . . . . . . . . . 8
5.3. Consideration (3.1) 'Notification' . . . . . . . . . . . 9
5.4. Consideration (3.2) 'Notification' . . . . . . . . . . . 10
6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 10
7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 11
8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 11
9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 12
10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 12
11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 12
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16
The Open Pluggable Edge Services (OPES) architecture [RFC3835], enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer.
オープン・プラガブルエッジサービス（OPES）アーキテクチャ[RFC3835]は、データプロバイダ、データコンシューマ、およびゼロ以上OPESプロセッサ間の連携アプリケーションサービス（OPESサービス）を可能にします。検討中のアプリケーションサービスは、分析し、おそらくデータプロバイダとデータコンシューマの間でやり取りするアプリケーションレベルのメッセージを変換します。
In the process of chartering OPES, the IAB made recommendations on issues that OPES solutions should be required to address. These recommendations were formulated in the form of a specific IAB considerations document [RFC3238]. In that document, IAB emphasized that its considerations did not recommend specific solutions and did not mandate specific functional requirements. Addressing an IAB consideration may involve showing appropriate protocol mechanisms or demonstrating that the issue does not apply. Addressing a consideration does not necessarily mean supporting technology implied by the consideration wording.
OPESをチャーターする過程では、IABは、OPESソリューションが対処する必要がなければならない問題についての提言を行いました。これらの推奨は、特定のIABの考慮事項ドキュメント[RFC3238]の形態で製剤化しました。その文書では、IABは、その考察は、特定のソリューションを推奨していませんでしたし、特定の機能要件を強制しなかったことを強調しました。 IAB考慮に対処する適切なプロトコルメカニズムを示すか、問題は適用されないことを実証していることを含むことができます。配慮に対処しても、必ずしも考慮文言によって暗黙技術を支えるという意味ではありません。
The primary goal of this document is to show that all formal IAB recommendations are addressed by OPES, to the extent that those considerations can be addressed by an IETF working group. The limitations of OPES working group to address certain aspects of IAB considerations are also explicitly documented.
このドキュメントの主な目標は、すべての正式なIAB勧告は、これらの考慮事項は、IETFワーキンググループによって対処することができる程度に、OPESによって対処されることを示すことです。 IABの考慮の特定の側面に対処するためにワーキンググループOPESの制限も明示的に文書化されています。
IAB considerations document [RFC3238] contains many informal recommendations. For example, while the IAB informally requires OPES architecture to "protect end-to-end data integrity by supporting end-host detection and response to inappropriate behavior by OPES intermediaries", the IAB has chosen to formalize these requirements via a set of more specific recommendations, such as Notification considerations addressed in Section 5.3 and Section 5.4 below. OPES framework addresses informal IAB recommendations by addressing corresponding formal considerations.
IABの考慮ドキュメント[RFC3238]は、多くの非公式の勧告が含まれています。例えば、IABは非公式に、IABは、より特定のセットを介してこれらの要件を形式化することを選択した「エンドホスト検出およびOPES仲介による不適切な振る舞いに対する応答を支持することにより、エンドツーエンドのデータ完全性を保護」するOPESアーキテクチャを必要としますこのような通知の考慮事項として勧告は、5.3節および以下のセクション5.4で対処しました。 OPESフレームワークは、対応する正式な考慮事項に取り組むことにより、非公式IAB勧告に対応しています。
There are nine formal IAB considerations [RFC3238] that OPES has to address. In the core of this document are the corresponding nine "Consideration" sections. For each IAB consideration, its section contains general discussion as well as references to specific OPES mechanisms relevant to the consideration.
OPESが対処しなければならない9つの正式なIABの考慮[RFC3238]はあります。このドキュメントのコアに対応する9「配慮」セクションがあります。各IABを考慮するために、その部分は、一般的な議論、ならびに考慮に関連する特定のOPESメカニズムへの参照を含みます。
This document does not introduce any new terminology but uses terminology from other OPES documents.
このドキュメントは、新しい用語を紹介するが、他のOPES文書から用語を使用していません。
"An OPES framework standardized in the IETF must require that the use of any OPES service be explicitly authorized by one of the application-layer end-hosts (that is, either the content provider or the client)." [RFC3238]
「IETFで標準化OPESフレームワーク（すなわち、コンテンツプロバイダまたはクライアントのいずれかである）任意OPESサービスの使用を明示的にアプリケーション層のエンドホストのいずれかによって承認されることを要求しなければなりません。」 [RFC3238]
OPES architecture requires that "OPES processors MUST be consented to by either the data consumer or data provider application" [RFC3835]. While this requirement directly satisfies IAB concern, no requirement alone can prevent consent-less introduction of OPES processors. In other words, OPES framework requires one-party consent but cannot guarantee it in the presence of incompliant OPES entities.
OPESアーキテクチャは、「OPESプロセッサはいずれかのデータコンシューマまたはデータプロバイダ・アプリケーションによってに同意しなければならない」と[RFC3835]を必要とします。この要件は、直接IAB懸念を満たす一方で、単独では要件がOPESプロセッサの同意レス導入を防ぐことはできません。言い換えれば、OPESフレームワークは、一党の同意が必要ですが、未対応OPESエンティティの存在下で、それを保証することはできません。
In [RFC3897], the OPES architecture enables concerned parties to detect unwanted OPES processors by examining OPES traces. While the use of traces in OPES is mandatory, a tracing mechanism on its own cannot detect processors that are in violation of OPES specifications. Examples include OPES processors operating in stealth mode. However, the OPES architecture allows the use of content signature to verify the authenticity of performed adaptations. Content signatures is a strong but expensive mechanism that can detect any modifications of signed content provided that the content provider is willing to sign the data and that the client is willing to either check the signature or relay received content to the content provider for signature verification.
[RFC3897]で、OPESアーキテクチャはOPESトレースを調べることによって、不要なOPESプロセッサを検出するために関係者を可能にします。 OPESにおけるトレースの使用は必須であるが、それ自体の上にトレース機構がOPES仕様に違反しているプロセッサーを検出することができません。例としては、ステルスモードで動作OPESプロセッサを含みます。しかし、OPESアーキテクチャは、コンテンツ署名の使用を行う適応の真正性を検証することを可能にします。コンテンツ署名は、署名されたコンテンツの変更を検出することができる強いが高価な機構は、コンテンツプロバイダがデータに署名する意思があることを提供し、クライアントは、署名またはリレーが署名検証のためのコンテンツプロバイダにコンテンツを受信確認するか意思があるということです。
OPES entities may copy or otherwise access content without modifying it. Such access cannot be detected using content signatures. Thus, "passive" OPES entities can operate on signed content without the data consumer or provider consent. If content privacy is a concern, then content encryption can be used. A passive processor is no different from any intermediary operating outside of OPES framework. No OPES mechanism (existing or foreseeable) can prevent non-modifying access to content.
OPESエンティティは、コピーまたはそれ以外の場合は、それを修正することなく、コンテンツにアクセスすることができます。そのようなアクセスは、コンテンツの署名を使用して検出することができません。このように、「受動的」OPESエンティティは、データコンシューマまたはプロバイダの同意なしに署名したコンテンツを操作することができます。コンテンツプライバシーが懸念される場合には、コンテンツの暗号化を使用することができます。受動プロセッサはOPESフレームワークの外側で動作する任意の中間と変わりません。 （既存または予測可能）がOPES機構は、コンテンツへの非修飾のアクセスを防ぐことはできません。
In summary, the one-party consent is satisfied by including the corresponding requirement in the IAB architecture document. That requirement alone cannot stop incompliant OPES entities to perform consent-less adaptations, but OPES framework allows for various means of detecting and/or preventing such adaptations. These means typically introduce overheads and require some level of producer-consumer cooperation.
要約すると、一党の同意は、IAB建築資料で対応する要件を含めることによって満たされます。単独でその要件は、未対応OPESエンティティが同意レス適応を実行するために止めることはできないが、OPESフレームワークは、検出および/またはそのような適応を防止する様々な手段を可能にします。これらの手段は、一般的にオーバーヘッドを導入し、生産者 - 消費者の協力のいくつかのレベルが必要です。
"For an OPES framework standardized in the IETF, the OPES intermediary must be explicitly addressed at the IP layer by the end user" [RFC3238].
[RFC3238]「IETFで標準化OPESフレームワークの、OPES仲介は、明示的にエンドユーザによってIPレイヤで対処しなければなりません」。
The OPES architecture requires that "OPES processors MUST be addressable at the IP layer by the end user (data consumer application)" [RFC3835]. The IAB and the architecture documents mention an important exception: addressing the first OPES processor in a chain of processors is sufficient. That is, a chain of OPES processors is viewed as a single OPES "system" at the address of the first chain element.
OPESアーキテクチャは、[RFC3835]「OPESプロセッサは、エンドユーザ（データ・コンシューマ・アプリケーション）によってIPレイヤでアドレス可能でなければなりません」ことを必要とします。 IABとアーキテクチャ文書は重要な例外を言及：プロセッサのチェーンに最初OPESプロセッサに対処するだけで十分です。つまり、OPESプロセッサの鎖は、第1のチェーン要素のアドレスに単一OPES「システム」とみなされます。
The notion of a chain is not strictly defined by IAB. For the purpose of addressing this consideration, a group of OPES processors working on a given application transaction is considered. Such a group would necessarily form a single processing chain, with a single "exit" OPES processor (i.e., the processor that adapted the given message last). The OPES architecture essentially requires that last OPES processor to be explicitly addressable at the IP layer by the data consumer application. The chain formation, including its exit point may depend on an application message and other dynamic factors such as time of the day or system load.
チェーンの概念は厳密にIABによって定義されていません。この考察に対処するためには、特定のアプリケーションのトランザクションに取り組んOPESプロセッサのグループが考慮されます。そのようなグループは、必ずしも単一の「出口」OPESプロセッサと、単一の処理チェーンを形成するであろう（すなわち、最後に与えられたメッセージを適応プロセッサ）。 OPESアーキテクチャは、本質的に、最後のOPESプロセッサが明示的にデータコンシューマーアプリケーションによってIPレイヤでアドレス指定されることが必要です。その出口点を含む鎖の形成は、アプリケーション・メッセージとその日の時間またはシステム負荷などの他の動的要因に依存し得ます。
Furthermore, if OPES processing is an internal processing step at a data consumer or a data provider application side, then the last OPES processor may reside in a private address space and may not be explicitly addressable from the outside. In such situations, the processing side must designate an addressable point on the same processing chain. That designated point may not be, strictly speaking, an OPES processor, but it will suffice as such as far as IAB considerations are concerned -- the data consumer application will be able to address it explicitly at the IP layer and it will represent the OPES processing chain to the outside world.
OPES処理は、データ消費者またはデータ・プロバイダ・アプリケーション側の内部処理工程であればさらに、最後OPESプロセッサは、プライベートアドレス空間内に常駐することができると明示的に外部からアドレス指定されなくてもよいです。そのような状況では、処理側は、同じ処理チェーン上のアドレス可能なポイントを指定しなければなりません。その指定されたポイントは、厳密には、OPESプロセッサを話すことはできませんが、それははるかにIABの考慮が懸念しているとしてとしてのような十分でしょう - データコンシューマ・アプリケーションは、IPレイヤで明示的に取り組むことができるようになりますと、それはOPESを表します外の世界への処理チェーン。
Designating an addressable processing point avoids the conflict between narrow interpretation of the IAB consideration and real system designs. It is irrational to expect a content provider to provide access to internal hosts participating in content generation, whether OPES processors are involved or not. Moreover, providing such access would serve little practical purpose because internal OPES processors are not likely to be able to answer any data consumer queries, being completely out of content generation context. For example, an OPES processor adding customer-specific information to XML pages may not understand or be aware of any final HTML content that the data consumer application receives and may not be able to map end user request to any internal user identification. Since OPES requires the end of the message processing chain to be addressable, the conflict does not exist. OPES places no requirements on the internal architecture of data producer systems while requiring the entire OPES-related content production "system" to be addressable at the IP layer.
アドレス指定可能な処理点を指定することIAB対価の狭い解釈と実際のシステム設計との競合を避けることができます。 OPESプロセッサが関与しているか否か、コンテンツプロバイダは、コンテンツの生成に関与する内部ホストへのアクセスを提供することを期待することが不合理です。内部OPESプロセッサはコンテンツ生成文脈から完全である、任意のデータ・コンシューマ・クエリに応答できないことがあるため、また、そのようなアクセスを提供することはほとんど実用的な目的を果たすであろう。例えば、XMLページを顧客固有の情報を追加OPESプロセッサは理解したり、データ・コンシューマ・アプリケーションが受け取ると、内部ユーザ識別にエンドユーザの要求をマッピングすることができない場合があり、任意の最終的なHTMLコンテンツを認識しないかもしれません。 OPESは、アドレス指定可能であることをメッセージ処理チェーンの終了を必要とするので、競合は存在しません。 OPES場所全体OPES関連コンテンツ制作「システム」を必要としながら、データ生産システムの内部アーキテクチャには要件は、IPレイヤでアドレス可能にします。
Private Domain | Public Domain | Private Domain
| |
+--------------+ | +-------------+ +--------+
| Data | | | OPES System | |Data |
| Consumer |<--- network -->| with public |<---->|Provider|
| Application | | | IP address | |App |
+--------------+ | +-------------+ +--------+
| |
| |
Figure 1
図1
This section discusses how OPES framework addresses IAB Notification considerations 3.1 and 3.2.
このセクションでは、OPESフレームワークは、IAB通知の考慮事項3.1および3.2の対処方法について説明します。
Before specific considerations are discussed, the relationship between IAB notifications and OPES tracing has to be explained. OPES framework concentrates on tracing rather than notification. The OPES Communications specification [RFC3897] defines "OPES trace" as application message information about OPES entities that adapted the message. Thus, OPES trace follows the application message it traces. The trace is for the recipient of the application message. Traces are implemented as extensions of application protocols being adapted and traced.
固有の考慮事項が議論される前に、IAB通知とOPESトレースとの関係を説明する必要があります。 OPESフレームワークは、通知ではなく、トレースに集中します。 OPES通信仕様[RFC3897]は、メッセージを適合さOPESエンティティ約アプリケーションメッセージ情報として「OPESトレース」を定義します。このように、OPESトレースは、トレースアプリケーションメッセージに従います。トレースは、アプリケーションメッセージの受信者のためです。トレースは、アプリケーションプロトコルの拡張機能が適応されるように実装され、トレースされます。
As opposed to an OPES trace, provider notification (as implied by IAB) notifies the sender of the application message rather than the recipient. Thus, notifications propagate in the opposite direction of traces. Supporting notifications directly would require a new protocol. Figure 2 illustrates the differences between a trace and notification from a single application message point of view.
OPESトレースとは対照的に、プロバイダ通知は（IABによって暗示されるように）アプリケーションメッセージの送信者ではなく、受信者に通知します。したがって、通知はトレースの反対方向に伝播します。直接通知をサポートする新しいプロトコルが必要となります。図2は、ビューの単一のアプリケーション・メッセージ・ポイントからトレースと通知の違いを示しています。
sender --[message A]--> OPES --[message A']--> recipient
^ V [with trace]
| |
+-<-- [notification] ---+
Figure 2
図2
Since notifications cannot be piggy-backed to application messages, they create new messages and may double the number of messages the sender has to process. The number of messages that need to be proceed is larger if several intermediaries on the message path generate notifications. Associating notifications with application messages may require duplicating application message information in notifications and may require maintaining a sender state until notification is received. These actions increase the performance overhead of notifications.
通知はピギーバックアプリケーションメッセージにすることはできませんので、彼らは新しいメッセージを作成し、送信者が処理しなければならないメッセージの数を2倍にすることができます。メッセージパス上の複数の仲介者が通知を生成する場合は続行する必要のあるメッセージの数が大きくなっています。アプリケーション・メッセージで通知を関連付けることは通知にアプリケーションメッセージ情報を複製する必要があり、通知が受信されるまで送信元の状態を維持する必要とするかもしれません。これらのアクションは、通知のパフォーマンス・オーバーヘッドを増加させます。
The level of available details in notifications versus provider interest in supporting notification is another concern. Experience shows that content providers often require very detailed information about user actions to be interested in notifications at all. For example, Hit Metering protocol [RFC2227] has been designed to supply content providers with proxy cache hit counts, in an effort to reduce cache busting behavior which was caused by content providers desire to get accurate site "access counts". However, the Hit Metering protocol is currently not widely deployed because the protocol does not supply content providers with information such as client IP addresses, browser versions, or cookies.
通知をサポートするプロバイダの関心対通知で利用可能な詳細のレベルは別の問題です。経験は、コンテンツプロバイダは、多くの場合、すべての通知に興味があることをユーザー動作に関する非常に詳細な情報を必要とすることを示しています。例えば、計量プロトコルをヒット[RFC2227]は、コンテンツプロバイダによって引き起こされたキャッシュの無効化行動を減らすための努力で、プロキシキャッシュのヒット数とコンテンツプロバイダを供給するように設計された正確なサイト「アクセス回数」を取得することを望みます。プロトコルは、クライアントのIPアドレス、ブラウザのバージョン、またはクッキーなどの情報をコンテンツプロバイダに提供していないためしかし、ヒット計量プロトコルは、現在、広く展開されていません。
Hit Metering experience is relevant because Hit Metering protocol was designed to do for HTTP caching intermediaries what OPES notifications are meant to do for OPES intermediaries. Performance requirements call for state reduction via aggregation of notifications while provider preferences call for state preservation or duplication. Achieving the right balance when two sides belong to different organizations and have different optimization priorities may be impossible.
ヒット計量プロトコルはOPES通知がOPESの仲介のために行うことを意図しているものHTTPキャッシングの仲介のために行うように設計されたため、ヒット計量経験が関連しています。プロバイダの好みが状態の保存や複製の呼び出しながら、性能要件は、通知の凝集を経由して状態の低減のために呼び出します。双方が異なる組織に属し、異なる最適化の優先順位は不可能かもしれ持っていたときに適切なバランスを達成。
Thus, instead of explicitly supporting notifications at the protocol level, OPES concentrates on tracing facilities. In essence, OPES supports notifications indirectly, using tracing facilities. In other words, the IAB choice of "Notification" label is interpreted as "Notification assistance" (i.e., making notifications meaningful) and is not interpreted as a "Notification protocol".
したがって、代わりに明示的にプロトコルレベルでの通知をサポートする、OPESは、施設をトレースに集中します。本質的には、OPESは、トレース機能を使用して、間接的に通知をサポートしています。換言すれば、「通知」ラベルのIAB選択（すなわち、意味の通知を行う）「通知支援」として解釈され、「通知プロトコル」と解釈されません。
The above concerns call for making notification optional. The OPES architecture allows for an efficient and meaningful notification protocol to be implemented in certain OPES environments. For example, an OPES callout server attached to a gateway or firewall may scan outgoing traffic for signs of worm or virus activity and notify a local Intrusion Detection System (IDS) of potentially compromised hosts (e.g., servers or client PCs) inside the network. Such notifications may use OPES tracing information to pinpoint the infected host (which could be another OPES entity). In this example, notifications are essentially sent back to the content producer (the local network) and use OPES tracing to supply details.
上記の懸念は、通知がオプション作るために呼び出します。 OPESアーキテクチャは、特定のOPES環境で実施することが効率的で意味のある通知プロトコルを可能にします。例えば、ゲートウェイ又はファイアウォールに取り付けOPESコールアウトサーバは、ワームやウイルス活性の兆候発信トラフィックをスキャンし、ネットワーク内の潜在的に損なわれたホスト（例えば、サーバやクライアントPC）の局所侵入検知システム（IDS）を通知してもよいです。このような通知は（別のOPESエンティティすることができる）感染したホストを特定するためにOPESトレース情報を使用することができます。この例では、通知は、本質的に、コンテンツ製作者（ローカルネットワーク）に送り返さと詳細を供給するためにトレースOPESを使用しています。
Another environment where efficient and meaningful notification using OPES tracing is possible are Content Delivery Networks (CDNs). A CDN node may use multiple content adaptation services to customize generic content supplied by the content producer (a web site). For example, a callout service may insert advertisements for client-local events. The CDN node itself may not understand specifics of the ad insertion algorithm implemented at callout servers. However, the node may use information in the OPES trace (e.g., coming from the callout service) to notify the content producer. Such notifications may be about the number of certain advertisements inserted (i.e., the number of "impressions" delivered to the customer) or even the number of ad "clicks" the customer made (e.g., if the node hosts content linked from the ads). Callout services doing ad insertion may lack details (e.g., a customer ID/address or a web server authentication token) to contact the content producer directly in this case. Thus, OPES trace produced by an OPES service becomes essential in enabling meaningful notifications that the CDN node sends to the content producer.
OPESトレースを使用して効率的かつ有意義な通知が可能である別の環境では、コンテンツ配信ネットワーク（CDN）です。 CDNノードは、コンテンツ制作（ウェブサイト）から供給される一般的なコンテンツをカスタマイズするために、複数のコンテンツ処理サービスを使用することができます。例えば、コールアウトサービスは、クライアント・地域のイベントのために広告を挿入することができます。 CDNノード自体はコールアウトサーバで実装広告挿入アルゴリズムの詳細を理解していないことがあります。しかし、ノードは、コンテンツ製作者に通知するために（例えば、コールアウトサービスから来る）OPESトレースに情報を使用することができます。このような通知が挿入された特定の広告の数程度でよい（すなわち、顧客に納入「感想」の数）または広告の偶数が行われ、顧客（例えば、ノードのホストコンテンツが広告からリンクされている場合）「をクリック」 。広告挿入を行う吹き出しサービスは、この場合には直接、コンテンツ製作者に連絡する詳細（例えば、顧客のID /アドレスまたはWebサーバの認証トークン）を欠いている可能性があります。したがって、OPESサービスによって生成OPESトレースは、CDNノードは、コンテンツ製作者に送信する意味の通知を可能に不可欠となります。
The example below illustrates adaptations done to HTTP request at an OPES processor operated by the client ISP. Both original (as sent by an end user) and adapted (as received by the origin web server) requests are shown. The primary adaptation is the modification of HTTP "Accept" header. The secondary adaptation is the addition of an OPES-System HTTP extension header [I-D.ietf-opes-http].
以下の例では、クライアントのISPによって操作OPESプロセッサにHTTPリクエストに行わ適応を示します。元（エンドユーザによって送信された）と適合（オリジンWebサーバによって受信されるように）両方の要求が示されています。一次適応ヘッダーを「受諾」HTTPの変形例です。二次適応はOPES-システムHTTP拡張ヘッダ[I-D.ietf-OPES-HTTP]の付加です。
GET /pub/WWW/ HTTP/1.1 Host: www.w3.org Accept: text/plain Figure 3
GET /パブ/ WWW / HTTP / 1.1ホスト：www.w3.org受け入れ：text / plainの図3
... may be adapted by an ISP OPES system to become:
...になるためにISP OPESシステムによって適合させることができます。
GET /pub/WWW/ HTTP/1.1 Host: www.w3.org Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8 OPES-System: http://www.isp-example.com/opes/?client-hash=1234567
GET /パブ/ WWW / HTTP / 1.1ホスト：www.w3.org受け入れ：テキスト/平野。 Q = 0.5、テキスト/ HTML、テキスト/ X-DVI。 Q = 0.8 OPES-システム：http://www.isp-example.com/opes/?client-hash=1234567
Figure 4
図4
The example below illustrates adaptations done to HTTP response at an OPES intermediary operated by a Content Distribution Network (CDN). Both original (as sent by the origin web server) and adapted (as received by the end user) responses are shown. The primary adaptation is the conversion from HTML markup to plain text. The secondary adaptation is the addition of an OPES-System HTTP extension header.
以下の例では、コンテンツ配信ネットワーク（CDN）によって操作OPES仲介におけるHTTP応答に行う適応を示します。両方の元（オリジンWebサーバから送信されたように）適合（エンドユーザによって受信されるように）応答が示されています。主な適応は、プレーンテキストにHTMLマークアップからの変換です。二次適応はOPES-システムHTTP拡張ヘッダの付加です。
HTTP/1.1 200 OK Content-Length: 12345 Content-Encoding: text/html
HTTP / 1.1 200 OKのContent-Length：12345コンテンツエンコード：text / htmlの
<html><head><h1>Available Documenta...
ます。<html> <head> <H1>利用可能なドクメンタ...
Figure 5
図5
... may be adapted by a CDN OPES system to become:
...になるためにCDN OPESシステムによって適合させることができます。
HTTP/1.1 200 OK Content-Length: 2345 Content-Encoding: text/plain OPES-System: http://www.cdn-example.com/opes/?site=7654&svc=h2t
HTTP / 1.1 200 OKのContent-Length：2345コンテンツエンコード：text / plainのOPES-システム：http://www.cdn-example.com/opes/?site=7654&svc=h2t
AVAILABLE DOCUMENTA... Figure 6
AVAILABLEドクメンタ...図6
In the above examples, OPES-System header values contain URIs that may point to OPES-specific documents such as description of the OPES operator and its privacy policy. Those documents may be parameterized to allow for customizations specific to the transaction being traced (e.g., client or even transaction identifier may be used to provide more information about performed adaptations). An OPES-Via header may be used to provide a more detailed trace of specific OPES entities within an OPES System that adapted the message. Traced OPES URIs may be later used to request OPES bypass [RFC3897].
上記の例では、OPES-システムヘッダ値は、OPESオペレータとそのプライバシーポリシーの記述としてOPES固有のドキュメントを指すことができるURIを含みます。これらの文書は、（例えば、クライアント、あるいはトランザクション識別子を行う適応に関する詳細な情報を提供するために使用されてもよい）トレースされるトランザクションに固有のカスタマイズを可能にするために、パラメータ化されてもよいです。 OPES-Viaヘッダ、メッセージを適合OPESシステム内の特定のOPESエンティティのより詳細なトレースを提供するために使用されてもよいです。トレースOPES URIは後OPESバイパス[RFC3897]を要求するために使用されてもよいです。
"The overall OPES framework needs to assist content providers in detecting and responding to client-centric actions by OPES intermediaries that are deemed inappropriate by the content provider" [RFC3238].
[RFC3238]「全体OPESフレームワークは、検出およびコンテンツプロバイダによって不適切と見なされるOPES仲介によるクライアント中心のアクションに応答して、コンテンツプロバイダを支援する必要があります」。
OPES tracing mechanisms assist content providers in detecting client-centric actions by OPES intermediaries. Specifically, a compliant OPES intermediary or system notifies a content provider of its presence by including its tracing information in the application protocol requests. An OPES system MUST leave its trace [RFC3897]. Detection assistance has its limitations. Some OPES intermediaries may work exclusively on responses and may not have a chance to trace the request. Moreover, some application protocols may not have explicit requests (e.g., a content push service).
OPESトレースメカニズムは、OPESの仲介によりクライアント中心の操作を検出する際に、コンテンツプロバイダを支援します。具体的には、コンプライアントOPES仲介またはシステムは、アプリケーションプロトコル要求にそのトレース情報を含めることにより、その存在のコンテンツプロバイダに通知します。 OPESシステムは、そのトレース[RFC3897]を残しておく必要があります。検出支援には限界があります。いくつかのOPES仲介は応答だけに働くことがあり、要求をトレースする機会を持っていないかもしれません。また、いくつかのアプリケーションプロトコルは、明示的な要求（例えば、コンテンツプッシュサービス）を有していなくてもよいです。
OPES tracing mechanisms assist content providers in responding to client-centric actions by OPES intermediaries. Specifically, OPES traces MUST include identification of OPES systems and SHOULD include a list of adaptation actions performed on provider's content. This tracing information may be included in the application request. Usually, however, this information will be included in the application response, an adapted version of which does not reach the content provider. If OPES end points cooperate, then notification can be assisted with traces. Content providers that suspect or experience difficulties can do any of the following:
OPESトレースメカニズムは、OPESの仲介により、クライアント中心のアクションに応答して、コンテンツプロバイダを支援します。具体的には、OPESトレースはOPESシステムの識別を含まなければなりませんし、プロバイダのコンテンツに対して実行適応行動のリストが含まれるべきです。このトレース情報は、アプリケーションの要求に含まれていてもよいです。しかしながら、通常、この情報は、アプリケーションの応答、コンテンツプロバイダに到達しないうちに適応バージョンに含まれます。 OPESエンドポイントが協力場合、通知は、トレースを支援することができます。疑いや経験の難しさは、次のいずれかの操作を行うことができ、コンテンツプロバイダー：
o Check whether requests they receive pass through OPES intermediaries. Presence of OPES tracing info will determine that. This check is only possible for request/response protocols. For other protocols (e.g., broadcast or push), the provider would have to assume that OPES intermediaries are involved until proven otherwise.
O、彼らが受け取るリクエストはOPESの仲介を通過するかどうかを確認してください。 OPESトレース情報の存在がそれを決定します。このチェックは、要求/応答プロトコルに対してのみ可能です。他のプロトコル（例えば、放送またはプッシュ）するために、プロバイダは、そうでなければ証明されるまでOPES仲介者が関与していると仮定しなければなりません。
o If OPES intermediaries are suspected, request OPES traces from potentially affected user(s). The trace will be a part of the application message received by the user software. If involved parties cooperate, the provider(s) may have access to all the needed information. Certainly, lack of cooperation may hinder access to tracing information. To encourage cooperation, data providers might be able to deny service to uncooperative users.
OPES仲介が疑われる場合はO、要求OPESは、潜在的に影響を受けたユーザ（複数可）からトレース。トレースは、ユーザソフトウェアによって受信されたアプリケーションメッセージの一部となります。関係者が協力した場合、プロバイダ（複数可）は、すべての必要な情報にアクセスすることができます。確かに、協力の欠如は、トレース情報へのアクセスを妨げる可能性があります。協力を促進するために、データプロバイダは、非協力的なユーザーへのサービスを拒否することができるかもしれません。
o Some traces may indicate that more information is available by accessing certain resources on the specified OPES intermediary or elsewhere. Content providers may query for more information in this case.
Oいくつかのトレースは、より多くの情報が指定されたOPES仲介や他の場所で特定のリソースにアクセスすることで利用可能であることを示してもよいです。コンテンツプロバイダは、この場合の詳細については、問い合わせることができます。
o If everything else fails, providers can enforce no-adaptation policy using appropriate OPES bypass mechanisms and/or end-to-end encryption mechanisms.
他のすべてが失敗した場合は、O、プロバイダは、適切なOPESバイパスメカニズムおよび/またはエンドツーエンドの暗号化メカニズムを使用していない適応ポリシーを強制することができます。
OPES detection and response assistance is limited to application protocols with support for tracing extensions. For example, HTTP [RFC2616] has such support while DNS over UDP does not.
OPES検出とレスポンスの支援は拡張子をトレースするためのサポートをアプリケーションプロトコルに限定されています。 UDP上DNSはないながら、例えば、HTTP [RFC2616]はこのような支持体を有しています。
"The overall OPES framework should assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries" [RFC3238].
[RFC3238]を「全体OPESフレームワークは、潜在的にそれらが不完全または損なわ仲介者を識別できるように、OPES仲介の挙動を検出することで、エンドユーザーを支援すべきです」。
OPES tracing mechanisms assist end users in detecting OPES intermediaries. Specifically, a compliant OPES intermediary or system notifies an end user of its presence by including its tracing information in the application protocol messages sent to the client. An OPES system MUST leave its trace [RFC3897]. However, detection assistance has its limitations. Some OPES systems may work exclusively on requests and may not have a chance to trace the response. Moreover, some application protocols may not have explicit responses (e.g., event logging service).
OPESトレースメカニズムは、OPESの仲介を検出する際にエンドユーザーを支援します。具体的には、コンプライアントOPES仲介またはシステムがクライアントに送信されるアプリケーション・プロトコル・メッセージでそのトレース情報を含めることによって、その存在をエンドユーザに通知します。 OPESシステムは、そのトレース[RFC3897]を残しておく必要があります。しかし、検出支援には限界があります。いくつかのOPESシステムは、要求だけに働くことと応答をトレースする機会を持っていないかもしれません。また、いくつかのアプリケーションプロトコルは、明示的な応答（例えば、イベントログサービス）を有していなくてもよいです。
OPES detection assistance is limited to application protocols with support for tracing extensions. For example, HTTP [RFC2616] has such support while DNS over UDP does not.
OPES検出支援は拡張子をトレースをサポートするアプリケーションプロトコルに制限されています。 UDP上DNSはないながら、例えば、HTTP [RFC2616]はこのような支持体を有しています。
"If there exists a "non-OPES" version of content available from the content provider, the OPES architecture must not prevent users from retrieving this "non-OPES" version from the content provider" [RFC3238].
非OPES「が存在する場合は、 『[RFC3238]『コンテンツプロバイダからバージョン』非OPES』コンテンツプロバイダから利用可能なコンテンツのバージョンは、OPESアーキテクチャは、これを取得するからユーザーを妨げてはなりません」。
"OPES entities MUST support a bypass feature" [RFC3897]. If an application message includes bypass instructions and an OPES intermediary is not configured to ignore them, the matching OPES intermediary will not process the message. An OPES intermediary may be configured to ignore bypass instructions only if no non-OPES version of content is available. Bypass may generate content errors since some OPES services may be essential but may not be configured as such.
[RFC3897]「OPESエンティティは、バイパス機能をサポートしなければなりません」。アプリケーション・メッセージは、バイパス命令を含み、OPES仲介は、それらを無視するように構成されていない場合、一致OPES仲介は、メッセージを処理しません。 OPES仲介は、コンテンツのいかなる非OPESバージョンが利用可能でない場合にのみ、バイパス命令を無視するように構成されてもよいです。バイパスは、いくつかのOPESサービスが不可欠かもしれないので、コンテンツのエラーが発生するかもしれませんが、このように構成することはできません。
Bypass support has limitations similar to the two notification-related considerations above.
バイパスのサポートは、上記の二つの通知関連の考慮事項と同様の制限があります。
"OPES documentation must be clear in describing these services as being applied to the result of URI resolution, not as URI resolution itself" [RFC3238].
[RFC3238]「OPESのドキュメントではなく、URI解決自体としてURI解決の結果に適用されるように、これらのサービスを説明する際に明確でなければなりません」。
"OPES Scenarios and Use Cases" specification [RFC3752] documents content adaptations that are in scope of the OPES framework. Scenarios include content adaptation of requests and responses. These documented adaptations do not include URI resolution. In some environments, it is technically possible to use documented OPES mechanisms to resolve URIs (and other kinds of identifiers or addresses). The OPES framework cannot effectively prevent any specific kind of adaptation.
「OPESシナリオとユースケース」仕様[RFC3752]ドキュメントOPESの枠組みの範囲内にあるコンテンツの適応。シナリオは、要求と応答の内容適応が含まれています。これらの文書の適応は、URIの解像度が含まれていません。いくつかの環境では、URIを（及び識別子またはアドレスの他の種類）を解決するために、文書OPESメカニズムを使用することは技術的に可能です。 OPESフレームワークは、効果的な適応のいずれかの特定の種類のを防ぐことはできません。
For example, a CDN node may substitute domain names in URLs with CDN-chosen IP addresses, essentially performing a URI resolution on behalf of the content producer (i.e., the web site owner). An OPES callout service running on a user PC may rewrite all HTML-embedded advertisement URLs to point to a user-specified local image, essentially performing a URI redirection on behalf of the content consumer (i.e., the end user). Such URI manipulations are outside of the OPES framework scope, but cannot be effectively eliminated from the real world.
例えば、CDNノードは、本質的に、コンテンツ製作者（すなわち、ウェブサイトの所有者）の代わりにURI解決を行う、CDN-選択されたIPアドレスとURLのドメイン名に置き換えてもよいです。ユーザのPC上で実行されているOPESコールアウト・サービスは、基本的にコンテンツ消費者（すなわち、エンドユーザ）に代わってURIリダイレクトを行うことにより、ユーザが指定したローカル画像を指すように、すべてのHTMLに埋め込まれた広告のURLを書き換えることができます。このようなURI操作はOPESフレームワークの範囲外ですが、効果的に現実の世界から排除することはできません。
"All proposed services must define their impact on inter- and intra-document reference validity" [RFC3238].
[RFC3238]を「すべての提案サービスは、間および文書内の参照有効性に及ぼす影響を定義する必要があります」。
The OPES framework does not propose adaptation services. However, OPES tracing requirements include identification of OPES intermediaries and services (for details, see "Notification" consideration sections in this document). It is required that provided identification can be used to locate information about the OPES intermediaries, including the description of impact on reference validity [RFC3897].
OPESフレームワークは、適応サービスを提案していません。しかし、OPESトレースの要件は（詳細については、このドキュメントの「通知」対価のセクションを参照してください）OPES仲介及びサービスの識別が含まれます。付与された識別が基準有効[RFC3897]への影響の記述を含む、OPES仲介についての情報を検索するために使用できることが要求されます。
"Any services that cannot be achieved while respecting the above two considerations may be reviewed as potential requirements for Internet application addressing architecture extensions, but must not be undertaken as ad hoc fixes" [RFC3238].
「上記の2点を尊重しながら達成することはできません任意のサービスには、アーキテクチャの拡張を扱うインターネットアプリケーションのための潜在的な要件として検討することができるが、アドホックの修正として行われてはならない」[RFC3238]。
OPES framework does not contain ad hoc fixes. This document in combination with and other OPES documents should be sufficient to inform service creators of IAB considerations. If a service does URI resolution or silently affects document reference validity, the authors are requested to review service impact on Internet application addressing architecture and work within IETF on potential extension requirements. Such actions would be outside of the current OPES framework.
OPESフレームワークは、アドホックの修正が含まれていません。これと組み合わせて、文書やその他のOPESドキュメントはIABの考慮のサービスクリエーターを知らせるのに十分であるべきです。サービスは、URIの解決を行うか、黙っ文書参照妥当性に影響を与える場合、著者は潜在的な拡張要件にIETF内のアーキテクチャと仕事に取り組むインターネットアプリケーション上のサービスへの影響を確認するように要求されています。このようなアクションは、現在のOPESの枠組みの外になります。
"The overall OPES framework must provide for mechanisms for end users to determine the privacy policies of OPES intermediaries" [RFC3238].
[RFC3238]「エンドユーザーがOPES仲介のプライバシーポリシーを決定するために、全体的なOPESフレームワークは、メカニズムを提供しなければなりません」。
OPES tracing mechanisms allow end users to identify OPES intermediaries (for details, see "Notification" consideration sections in this document). It is required that provided identification can be used to locate information about the OPES intermediaries, including their privacy policies.
OPESトレースメカニズムは、エンドユーザーが（、詳細については、このドキュメントの「通知」対価のセクションを参照してください）OPES仲介を識別することができます。提供識別が彼らのプライバシーポリシーを含むOPESの仲介についての情報を、見つけるために使用することができることが必要です。
The term "privacy policy" is not defined in this context (by IAB or OPES working group). OPES tracing mechanisms allow end users and content providers to identify an OPES system and/or intermediaries. It is believed that once an OPES system is identified, it would be possible to locate relevant information about that system, including information relevant to requesters perception of privacy policy or reference validity.
用語「プライバシーポリシー」は（IABやOPESワーキンググループによる）このコンテキストで定義されていません。 OPESトレースメカニズムは、エンドユーザおよびコンテンツプロバイダがOPESシステム及び/又は仲介者を識別することを可能にします。 OPESシステムが識別されると、プライバシーポリシーまたは参照妥当性のリクエスタ知覚に関連する情報を含め、そのシステムについての関連情報を、検索することが可能であろうと考えられています。
"If OPES is chartered, the OPES working group will also have to explicitly decide and document whether the OPES architecture must be compatible with the use of end-to-end encryption by one or more ends of an OPES-involved session. If OPES was compatible with end-to-end encryption, this would effectively ensure that OPES boxes would be restricted to ones that are known, trusted, explicitly addressed at the IP layer, and authorized (by the provision of decryption keys) by at least one of the ends" [RFC3238].
OPESがチャーターされている場合は、」、OPESワーキンググループは、明示的にOPESアーキテクチャはOPES-関与セッションの1つの以上の端部によって、エンドツーエンドの暗号化を使用すると互換性がなければならないかどうかを決定し、文書する必要があります。OPESであった場合エンドツーエンドの暗号化に対応して、これが効果的にOPESボックスは、知られ信頼されているものに限定されることを保証するであろう、明示的にIP層で対処し、のうちの少なくとも1つによって（復号鍵を提供することによって）認可終了」[RFC3238]。
The above quoted requirement was not explicitly listed as on of the IAB considerations, but still needs to be addressed. The context of the quote implies that the phrase "end-to-end encryption" refers to encryption along all links of the end-to-end path, with the OPES intermediaries as encrypting/decrypting participants or hops (e.g., encryption between the provider and the OPES intermediaries, and between the OPES intermediaries and the client).
上に引用の要件は、明示的にIABの考慮の上として記載されているが、それでも対処する必要はなかったです。引用の文脈は、句「エンド・ツー・エンドの暗号化」は、参加者やホップを暗号化/復号化などOPES仲介（例えば、プロバイダとの間で暗号化して、エンド・ツー・エンドのパスのすべてのリンクに沿って暗号化を参照していることを意味しますそして、OPESの仲介、およびOPESの仲介とクライアントの間で）。
Since OPES processors are regular hops on the application protocol path, OPES architecture allows for such encryption, provided the application protocol being adapted supports it. Hop-by-hop encryption would do little good for the overall application message path protection if callout services have to receive unencrypted content. To allow for complete link encryption coverage, OPES callout protocol (OCP) supports encryption of OCP connections between an OPES processor and a callout server via optional (negotiated) transport encryption mechanisms [I-D.ietf-opes-ocp-core].
OPESプロセッサはアプリケーション・プロトコル・パス上の正規のホップであるので、OPESアーキテクチャは、適合されているアプリケーションプロトコルがサポートして設けられ、そのような暗号化を可能にします。コールアウト・サービスは暗号化されていないコンテンツを受信する必要がある場合はホップ・バイ・ホップの暗号化は、アプリケーション全体のメッセージパスの保護のために少し良いを行うだろう。完全なリンク暗号化カバレッジを可能にするために、OPESコールアウトプロトコル（OCP）は、オプション（ネゴシエート）輸送暗号化機構[I-D.ietf-OPES-OCPコア]介しOPESプロセッサとコールアウトサーバとの間のOCP接続の暗号化をサポートします。
For example, TLS encryption [RFC2817] can be used among HTTP hops (some of which could be OPES processors) and between each OPES processor and a callout server.
例えば、TLS暗号化[RFC2817]は（OPESプロセッサとすることができるいくつかの）HTTPホップ間及び各OPESプロセッサとコールアウトサーバとの間で使用することができます。
This document does not define any mechanisms that may be subject to security considerations. This document scope is to address specific IAB considerations. Security of OPES mechanisms are discussed in Security Considerations sections of the corresponding OPES framework documents.
この文書では、セキュリティ上の考慮の対象となる可能性のあるメカニズムを定義していません。このドキュメントの範囲は、特定のIABの配慮に対処することです。 OPESメカニズムのセキュリティは、対応するOPESフレームワーク文書のセキュリティの考慮事項のセクションで説明されています。
For example, OPES tracing mechanisms assist content providers and consumers in protecting content integrity and confidentiality by requiring OPES intermediaries to disclose their presence. Security of the tracing mechanism is discussed in the Security Considerations section of [RFC3897].
例えば、OPESトレースメカニズムは、その存在を開示することOPESの仲介を必要とすることによって、コンテンツの完全性と機密性を保護するには、コンテンツプロバイダと消費者を支援します。追跡メカニズムのセキュリティは、[RFC3897]のセキュリティの考慮事項のセクションで説明されています。
This document may be perceived as a proof of OPES compliance with IAB implied recommendations. However, this document does not introduce any compliance subjects. Compliance of OPES implementations is defined in other OPES documents discussed above.
このドキュメントは、IAB暗黙の勧告にOPESのコンプライアンスの証明として認識することができます。しかし、この文書は、いかなるコンプライアンス科目を導入しません。 OPES実装のコンプライアンスは、上述の他のOPES文書で定義されています。
[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月。
[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月。
[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月。
[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月。
[RFC2227] Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting for HTTP", RFC 2227, October 1997.
[RFC2227]ムガール人、J.とP.リーチ、 "HTTP用のシンプルなヒット・メーターと使用制限"、RFC 2227、1997年10月。
[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月。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC2817] Khare、R.およびS.ローレンス、 "HTTP / 1.1内でTLSへのアップグレード"、RFC 2817、2000年5月。
[I-D.ietf-opes-http] Rousskov, A. and M. Stecher, "HTTP adaptation with OPES", Work in Progress, October 2003.
[I-D.ietf-OPES-HTTP] Rousskov、A.とM. Stecher、 "OPESとHTTP適応"、進歩、2003年10月に作業。
[I-D.ietf-opes-ocp-core] Rousskov, A., "OPES Callout Protocol Core", Work in Progress, November 2003.
[I-D.ietf-OPES-OCP-コア] Rousskov、A.、 "OPESコールアウトプロトコルコア"、進歩、2003年11月の作業。
Authors' Addresses
著者のアドレス
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario CA
アビーBarbir Nortel Networksの3500カーリングアベニューオタワ、オンタリオCA
Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com
電話：+1 613 763 5229 Eメール：abbieb@nortelnetworks.com
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/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 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.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、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機能のための基金は現在、インターネット協会によって提供されます。