RFC3914 日本語訳
3914 Open Pluggable Edge Services (OPES) Treatment of IABConsiderations. A. Barbir, A. Rousskov. October 2004. (Format: TXT=37411 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Barbir
Request for Comments: 3914 Nortel Networks
Category: Informational A. Rousskov
The Measurement Factory
October 2004
Barbirがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3914 ノーテルはカテゴリをネットワークでつなぎます: 情報のA.Rousskov測定工場の2004年10月
Open Pluggable Edge Services (OPES) Treatment of
IAB Considerations
IAB問題の開いているPluggable縁のサービス(作品)処理
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
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)はオープンPluggable Edge Services(作品)フレームワークのために9つのアーキテクチャレベル問題を言い表しました。 このドキュメントは作品がどうそれらの問題を扱うかを説明します。
Babir & Rousskov Informational [Page 1] RFC 3914 OPES Treatment of IAB Considerations October 2004
IAB問題2004年10月のBabir&Rousskovの情報[1ページ]のRFC3914作品処理
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 考慮の(2.1)の1'パーティーが'.3 4に同意します。 考慮(2.2)'IP-層のコミュニケーション'.4 5。 通知問題. . . . . . . . . . . . . . . . . 5 5.1。 通知対跡 . . . . . . . . . . . . . . . 6 5.2. HTTP. . . . . . . . . . 8 5.3のための作品跡に関する例。 考慮(3.1)'通知'. . . . . . . . . . . 9 5.4。 考慮(3.2)'通知'. . . . . . . . . . . 10 6。 考慮(3.3)'非ブロッキング'.107。 考慮(4.1)'URI解決'.118。 考慮(4.2)'参照の正当性'.119。 考慮(4.3)'アドレシング拡大'.12 10。 考慮(5.1)'プライバシー'. . . . . . . . . . . . . . . . 12 11。 考慮'暗号化'. . . . . . . . . . . . . . . . . . 12 12。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 13 13。 承諾. . . . . . . . . . . . . . . . . . . . . . . . . . 13 14。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 14 14.1。 引用規格. . . . . . . . . . . . . . . . . . 14 14.2。 有益な参照. . . . . . . . . . . . . . . . . 14作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 15の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
1. 序論
The Open Pluggable Edge Services (OPES) architecture [RFC3835], enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer.
オープンPluggable Edge Services(作品)アーキテクチャ[RFC3835]、a情報提供業者と、データ消費者と、ゼロの間のアプリケーション・サービス(作品サービス)か、より多くの作品プロセッサを協力して可能にします。 考慮しているアプリケーション・サービスは、情報提供業者とデータ消費者の間で交換されたアプリケーションレベルメッセージを、分析して、ことによると変えます。
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.
作品をチャーターすることの途中に、IABは問題における推薦状を扱うソリューションが必要であるべきであるその作品にしました。 これらの推薦は特定のIAB問題ドキュメント[RFC3238]の形で定式化されました。 そのドキュメントでは、IABは、問題が特定のソリューションを推薦しないで、また特定の機能条件書を強制しなかったと強調しました。 IABが考慮であると扱うのが、適切なプロトコルメカニズムを示しているか、または問題が適用されないのをデモをすることを伴うかもしれません。 考慮を扱うのは、必ず考慮言葉遣いによって含意された技術をサポートすることを意味するというわけではありません。
Babir & Rousskov Informational [Page 2] RFC 3914 OPES Treatment of IAB Considerations October 2004
IAB問題2004年10月のBabir&Rousskovの情報[2ページ]のRFC3914作品処理
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ワーキンググループがそれらの問題を扱うことができるという範囲に。 また、IAB問題のある一定の局面を扱う作品ワーキンググループの制限は明らかに記録されます。
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は、1セットの、より特定の推薦でこれらの要件を正式にするのを選びました、以下でセクション5.3とセクション5.4で扱われたNotification問題などのように。 作品フレームワークは、対応する正式な問題を扱うことによって、非公式の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.
作品が扱わなければならない9つの正式なIAB問題[RFC3238]があります。 このドキュメントのコアに、9つの対応する「考慮」セクションがあります。 それぞれのIABの考慮のために、セクションは考慮に関連している特定の作品メカニズムの参照と同様に一般的な議論を含みます。
2. Terminology
2. 用語
This document does not introduce any new terminology but uses terminology from other OPES documents.
このドキュメントは、少しの新しい用語も紹介しませんが、他の作品ドキュメントから用語を使用します。
3. Consideration (2.1) 'One-party consent'
3. 考慮(2.1)'1パーティーの同意'
"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で標準化された作品フレームワークは、どんな作品サービスの使用も応用層終わりホスト(すなわち、コンテンツプロバイダーかクライアントのどちらか)のひとりによって明らかに認可されるのを必要としなければなりません。」 [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.
作品アーキテクチャが、「データ消費者か情報提供業者アプリケーションで作品プロセッサを承諾しなければなりません。」が必要です[RFC3835]。 この要件が直接IAB関心を満たしている間、要件だけが作品プロセッサの同意なしの導入を防ぐことができません。 言い換えれば、作品フレームワークは、1パーティーの同意を必要としますが、incompliant作品実体があるときそれを保証できません。
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
[RFC3897]では、作品アーキテクチャは、関係者が作品跡を調べることによって求められていない作品プロセッサを検出するのを可能にします。 作品における跡の使用が義務的である間、それ自身のところの追跡メカニズムは作品仕様を違反しているプロセッサを検出できません。 例はこっそりモードで動作する作品プロセッサを含んでいます。 しかしながら、満足している署名の使用がアーキテクチャで信憑性について確かめることができる作品は働きました。
Babir & Rousskov Informational [Page 3] RFC 3914 OPES Treatment of IAB Considerations October 2004
IAB問題2004年10月のBabir&Rousskovの情報[3ページ]のRFC3914作品処理
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.
適合。 コンテンツプロバイダーが検出すれば署名している内容のどんな変更も検出できる強い、しかし、高価なメカニズムが、データに署名しても構わないと思っていて、クライアントが望んでいる満足している署名は、署名照合のために署名をチェックするか、または受信された内容をコンテンツプロバイダーにリレーします。
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.
それを変更しないで、作品実体は、内容にコピーするか、またはそうでなければ、アクセスするかもしれません。 満足している署名を使用するのをそのようなアクセスを検出できません。 したがって、「受動」の作品実体はデータ消費者もプロバイダー同意なしで署名している内容を作動させることができます。 満足しているプライバシーが関心であるなら、満足している暗号化を使用できます。 受け身のプロセッサは作品フレームワークの外で働いているどんな仲介者とも異なっていません。 どんな作品メカニズム(既存の、または、予見できる)も内容への非変更アクセスを防ぐことができません。
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.
概要では、1パーティーの同意は、IABアーキテクチャドキュメントに対応する要件を含んでいることによって、満たされています。 その要件だけが同意なしの適合を実行するためにincompliant作品実体を止めることができませんが、作品フレームワークはそのような適合を検出する、そして/または、防ぐ様々な手段を考慮します。 これらの手段は、オーバーヘッドを通常導入して、何らかのレベルのプロデューサー消費者協力を必要とします。
4. Consideration (2.2) 'IP-layer communications'
4. 考慮(2.2)'IP-層のコミュニケーション'
"For an OPES framework standardized in the IETF, the OPES intermediary must be explicitly addressed at the IP layer by the end user" [RFC3238].
「IETFで標準化された作品フレームワークにおいて、エンドユーザはIP層で作品仲介者を明らかに宛てなければならない」[RFC3238]。
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.
作品アーキテクチャが、「作品プロセッサはエンドユーザ(データ消費者アプリケーション)はIP層でアドレス可能であるに違いありません。」が必要です[RFC3835]。 IABとアーキテクチャドキュメントは重要な例外について言及します: プロセッサのチェーンにおける最初の作品プロセッサを扱うのは十分です。 すなわち、作品プロセッサのチェーンは単一の作品「システム」として最初のチェーン要素のアドレスで見なされます。
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によって厳密に定義されません。 この考慮を扱う目的のために、与えられたアプリケーショントランザクションに動く作品プロセッサのグループは考えられます。 そのようなグループは必ず単一の処理チェーンを形成するでしょう、単一の「出口」作品プロセッサ(すなわち、最後に与えられたメッセージを適合させたプロセッサ)で。 作品アーキテクチャは、その最後の作品プロセッサがIP層でデータ消費者アプリケーションで明らかにアドレス可能であることを本質的には必要とします。 チェーン構成、エキジットポイントを含んでいるのは日かシステム・ロードの時間などのアプリケーションメッセージと他の荷重倍数に依存するかもしれません。
Babir & Rousskov Informational [Page 4] RFC 3914 OPES Treatment of IAB Considerations October 2004
IAB問題2004年10月のBabir&Rousskovの情報[4ページ]のRFC3914作品処理
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.
その上、作品処理がデータ消費者の内部の処理ステップか情報提供業者アプリケーション側であるなら、最後の作品プロセッサは、プライベート・アドレススペースに住んでいるかもしれなくて、外部から明らかにアドレス可能でないかもしれません。 そのような状況で、処理側は同じ処理チェーンのアドレス可能点を指定しなければなりません。 そういうものとして、IAB問題に関する限り、十分でしょう--データ消費者アプリケーションはIP層で明らかにそれを扱うことができるでしょう、そして、ポイントに指定されたそれは厳密に言うと作品プロセッサでないかもしれませんが、それは作品処理チェーンを外の世界に代表するでしょう。
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の考慮と実システムデザインの狭い解釈にポイントが闘争を避けるアドレス可能な処理を指定します。 コンテンツプロバイダーが満足している世代で参加する内部のホストへのアクセスを提供すると予想するのは不合理です、作品プロセッサがかかわるか否かに関係なく。 そのうえ、そのようなアクセスを提供する場合、内部の作品プロセッサがどんなデータ消費者質問にも答えることができそうにないので、実用的な目的はほとんど役立たないでしょう、完全な満足している世代関係が使い果たされて。 例えば、XMLページに顧客特定情報を追加する作品プロセッサは、分からないで、またデータ消費者アプリケーションが受信して、どんな内部のユーザ登録名にもエンドユーザ要求を写像できないかもしれないのをどんな最終的なHTML内容も意識していないかもしれません。 作品が、メッセージ処理チェーンの端がアドレス可能であることを必要とするので、闘争は存在していません。 全体の作品関連の満足している生産「システム」がIP層でアドレス可能であることが必要である間、作品はデータプロデューサー・システムの内部のアーキテクチャに要件を全く置きません。
Private Domain | Public Domain | Private Domain
| |
+--------------+ | +-------------+ +--------+
| Data | | | OPES System | |Data |
| Consumer |<--- network -->| with public |<---->|Provider|
| Application | | | IP address | |App |
+--------------+ | +-------------+ +--------+
| |
| |
個人的なドメイン| 公共の場| 個人的なドメイン| | +--------------+ | +-------------+ +--------+ | データ| | | 作品システム| |データ| | 消費者| <、-、-- ネットワーク-->| 公衆と共に| <、-、-、--、>|プロバイダー| | アプリケーション| | | IPアドレス| |装置| +--------------+ | +-------------+ +--------+ | | | |
Figure 1
図1
5. Notification Considerations
5. 通知問題
This section discusses how OPES framework addresses IAB Notification considerations 3.1 and 3.2.
作品フレームワークが、IAB Notification問題が3.1と3.2であるとどう扱うかをこのセクションは論じます。
Babir & Rousskov Informational [Page 5] RFC 3914 OPES Treatment of IAB Considerations October 2004
IAB問題2004年10月のBabir&Rousskovの情報[5ページ]のRFC3914作品処理
5.1. Notification versus trace
5.1. 通知対跡
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通知と作品のたどるとの関係は説明されなければなりません。 作品フレームワークは通知よりむしろたどることに集中します。 作品Communications仕様[RFC3897]はメッセージを適合させた作品実体に関するアプリケーションメッセージ情報と「作品跡」を定義します。 したがって、作品跡はそれがたどるアプリケーションメッセージに従います。 跡はアプリケーションメッセージの受取人のためのものです。 跡は適合させられて、たどられるアプリケーション・プロトコルの拡大として実装されます。
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.
作品跡と対照的に、プロバイダー通知(IABによって含意されるように)は受取人よりむしろアプリケーションメッセージについて送付者に通知します。 したがって、通知は跡の逆方向に伝播されます。 通知をサポートするのは直接新しいプロトコルを必要とするでしょう。 図2はただ一つのアプリケーションメッセージ観点からの跡と通知の違いを例証します。
sender --[message A]--> OPES --[message A']--> recipient
^ V [with trace]
| |
+-<-- [notification] ---+
'送付者--[メッセージA]-->作品--[メッセージA']-->受取人^V[跡がある]| | +-<--[通知]---+
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.
アプリケーションメッセージに通知を背負うことができないので、それらは、新しいメッセージを作成して、送付者が処理しなければならないメッセージの数を倍にするかもしれません。 メッセージ経路の数人の仲介者が通知を生成するなら、続くことである必要があるメッセージの数は、より大きいです。 アプリケーションメッセージに通知を関連づけるのは、通知におけるアプリケーションメッセージ情報をコピーするのが必要であり、通知が受信されるまで送付者状態を維持するのを必要とするかもしれません。 これらの動作は通知の性能オーバーヘッドを増強します。
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.
通知における利用可能な詳細の対通知をサポートすることへのプロバイダー関心レベルは別の関心です。 経験は、コンテンツプロバイダーが、しばしばユーザ動作の非常に詳細な情報が全く通知に興味を持っているのを必要とするのを示します。 例えば、Hit Meteringプロトコル[RFC2227]は、正確なサイト「アクセスカウント」を得るコンテンツプロバイダー願望によって引き起こされた振舞いを破産させるキャッシュを減少させるために取り組みにおけるプロキシキャッシュヒット数をコンテンツプロバイダーに供給するように設計されています。 しかしながら、プロトコルが情報をもっているクライアントIPアドレス、ブラウザバージョン、またはクッキーなどのコンテンツプロバイダーを供給しないので、Hit Meteringプロトコルは現在、広く配布されません。
Babir & Rousskov Informational [Page 6] RFC 3914 OPES Treatment of IAB Considerations October 2004
IAB問題2004年10月のBabir&Rousskovの情報[6ページ]のRFC3914作品処理
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.
Hit MeteringプロトコルがHTTPのためにするようにどんな作品通知が作品仲介者のためにすることになっている仲介者をキャッシュしながら設計されたので、ヒットMetering経験は関連しています。 プロバイダー好みが州の保存か複製を求めている間、パフォーマンス要件は通知の集合で州の減少を求めます。 2つの側が異なった組織のものて、異なった最適化プライオリティを持っているとき正しいバランスを獲得するのは不可能であるかもしれません。
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".
したがって、プロトコルレベルで明らかに通知をサポートすることの代わりに、作品は追跡施設に集中します。 本質では、追跡施設を使用して、作品は間接的に通知をサポートします。 言い換えれば、「通知」ラベルの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.
上の関心は、通知を任意にするように求めます。 作品アーキテクチャは、効率的で重要な通知プロトコルが、ある作品環境で実装されるのを許容します。 例えば、ゲートウェイかファイアウォールに取り付けられた作品calloutサーバは、ネットワークの中でワームかウイルス活動のサインのために外向的なトラフィックをスキャンして、潜在的に感染されたホスト(例えば、サーバかクライアントPC)について地方のIntrusion Detection System(IDS)に通知するかもしれません。 そのような通知は、感染宿主(別の作品実体であるかもしれない)を正確に指摘するために情報をたどりながら、作品を使用するかもしれません。 この例では、通知は、本質的には満足しているプロデューサーに送り返されて(企業内情報通信網)、詳細部分を提供するのに作品のたどることを使用します。
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.
作品のたどることを使用するのが効率的で重要な通知が可能であるContent Delivery Networks(CDNs)である別の環境。 CDNノードは、満足しているプロデューサー(ウェブサイト)によって提供されたジェネリック内容をカスタム設計するのに複数の満足している適合サービスを利用するかもしれません。 例えば、calloutサービスはクライアントローカルイベントのために広告を載せるかもしれません。 CDNノード自体はcalloutサーバで実装された広告挿入アルゴリズムの詳細を理解しないかもしれません。 しかしながら、ノードは、満足しているプロデューサーに通知するのに作品跡(例えば、calloutサービスから、来る)で情報を使用するかもしれません。 そのような通知は、載せられたある広告(すなわち、顧客に提供された「印象」の数)のおよそ数か顧客が作った広告「クリック」の数でさえあるかもしれません(例えば、ノードが広告からリンクされた内容をホスティングするなら)。 広告挿入をするCalloutサービスは直接この場合満足しているプロデューサーに連絡する詳細(例えば、顧客ID/アドレスかウェブサーバー認証トークン)を欠くかもしれません。 したがって、作品サービスで生産された作品跡はCDNノードが満足しているプロデューサーに発信するという重要な通知を可能にするのにおいて不可欠になります。
Babir & Rousskov Informational [Page 7] RFC 3914 OPES Treatment of IAB Considerations October 2004
IAB問題2004年10月のBabir&Rousskovの情報[7ページ]のRFC3914作品処理
5.2. An example of an OPES trace for HTTP
5.2. HTTPのための作品跡に関する例
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によって操作された作品プロセッサでHTTP要求に行われた適合を例証します。 オリジナル(エンドユーザによって送られるように)の、そして、適合の両方であっている(発生源ウェブサーバーで受け取るように)要求は示されます。 プライマリ適合は「受諾HTTP」ヘッダーの変更です。 セカンダリ適合は作品システムHTTP拡張ヘッダー[I-D.ietf-opes-http]の追加です。
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
Accept: text/plain
Figure 3
/pub/WWW/ HTTP/1.1ホストを手に入れてください: www.w3.org Accept: テキスト/明瞭な図3
... may be adapted by an ISP OPES system to become:
…はISP作品システムによって適合させられて、なるかもしれません:
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
/pub/WWW/ HTTP/1.1ホストを手に入れてください: www.w3.org Accept: テキスト/平野。 q=0.5、テキスト/html、テキスト/x-dvi。 q=0.8作品システム: 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.
以下の例はContent Distribution Network(CDN)によって手術された作品仲介者でHTTP応答に行われた適合を例証します。 オリジナル(発生源ウェブサーバーで送るように)の、そして、適合の両方であっている(エンドユーザによって受け取られるように)応答は示されます。 HTMLマーク付けからプレーンテキストまでプライマリ適合は変換です。 セカンダリ適合は作品システムHTTP拡張ヘッダーの追加です。
HTTP/1.1 200 OK Content-Length: 12345 Content-Encoding: text/html
HTTP/1.1 200はコンテンツの長さを承認します: 12345 内容をコード化しています: テキスト/html
<html><head><h1>Available Documenta...
<html><ヘッド><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はコンテンツの長さを承認します: 2345 内容をコード化しています: 明瞭な作品テキスト/システム: http://www.cdn-example.com/opes/?site=7654&svc=h2t
AVAILABLE DOCUMENTA...
Figure 6
利用可能なドクメンタ… 図6
Babir & Rousskov Informational [Page 8] RFC 3914 OPES Treatment of IAB Considerations October 2004
IAB問題2004年10月のBabir&Rousskovの情報[8ページ]のRFC3914作品処理
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].
上記の例では、作品システムヘッダー値は作品オペレータとそのプライバシーに関する方針の記述などの作品特有のドキュメントを示すかもしれないURIを含んでいます。 それらのドキュメントは、たどられるトランザクションに特定の改造を考慮するためにparameterizedされるかもしれません(例えば、クライアントかトランザクション識別子さえ実行された適合に関する詳しい情報を提供するのに使用されるかもしれません)。 ヘッダーを通した作品は、メッセージを適合させた作品Systemの中で特定の作品実体の、より詳細な跡を提供するのに使用されるかもしれません。 たどられた作品URIは、後で作品迂回[RFC3897]を要求するのに使用されるかもしれません。
5.3. Consideration (3.1) 'Notification'
5.3. 考慮(3.1)'通知'
"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 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).
作品追跡メカニズムは作品仲介者によるクライアント中心の動作を検出するのにコンテンツプロバイダーを助けます。 明確に、アプリケーション・プロトコル要求に情報をたどるのを含んでいることによって、言いなりになっている作品仲介者かシステムが存在についてコンテンツプロバイダーに通知します。 作品システムは[RFC3897]に跡を残さなければなりません。 検出支援には、制限があります。 作品仲介者の中には排他的な応答に取り組んで、要求をたどる機会を持っていない人もいるかもしれません。 そのうえ、いくつかのアプリケーション・プロトコルには、明白な要求(例えば、満足しているプッシュサービス)がないかもしれません。
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:
作品追跡メカニズムは作品仲介者によるクライアント中心の動作に応じるのにコンテンツプロバイダーを助けます。 明確に、作品跡は作品システムの識別を含まなければなりません、そして、SHOULDはプロバイダーの内容に実行された適合動作のリストを含んでいます。 この追跡情報はアプリケーション要求に含まれるかもしれません。 しかしながら、通常、この情報はアプリケーション応答に含まれるでしょう。その適合しているバージョンはコンテンツプロバイダーに達しません。 作品終わりが指すなら、協力してください、そして、次に、跡で通知は促進できます。 苦境に疑うか、または陥るコンテンツプロバイダーが以下のどれかができます:
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 彼らが受け取る要求が作品仲介者を通り抜けるかどうかチェックしてください。 作品追跡インフォメーションの存在はそれを決定するでしょう。 要求/応答プロトコルだけに、このチェックは可能です。 他のプロトコル(例えば、放送するか、または押す)のために、プロバイダーは、そうでないと立証されるまで作品仲介者がかかわると仮定しなければならないでしょう。
Babir & Rousskov Informational [Page 9] RFC 3914 OPES Treatment of IAB Considerations October 2004
IAB問題2004年10月のBabir&Rousskovの情報[9ページ]のRFC3914作品処理
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.
o 作品仲介者が疑われるなら、潜在的に影響を受けるユーザから作品跡を要求してください。 跡はユーザソフトウェアによって受け取られたアプリケーションメッセージの一部になるでしょう。 関係者が協力するなら、プロバイダーはすべての必要な情報に近づく手段を持っているかもしれません。 確かに、協力不足は追跡情報へのアクセスを妨げるかもしれません。 協力を奨励するために、情報提供業者は非協力的なユーザに対するサービスを否定するかもしれない場合があります。
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 いくつかの跡が、詳しい情報が指定された作品仲介者の上かほかの場所で、あるリソースにアクセスすることによって利用可能であることを示すかもしれません。 詳しい情報については、コンテンツプロバイダーがこの場合情報について質問するかもしれません。
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 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.
作品検出と応答支援は追跡拡大のサポートでアプリケーション・プロトコルに制限されます。 例えば、UDPの上のDNSは持っていませんが、HTTP[RFC2616]にはそのようなサポートがあります。
5.4. Consideration (3.2) 'Notification'
5.4. 考慮(3.2)'通知'
"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 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).
作品追跡メカニズムは作品仲介者を検出するのにエンドユーザを助けます。 明確に、クライアントに送られたアプリケーション・プロトコルメッセージに情報をたどるのを含んでいることによって、言いなりになっている作品仲介者かシステムが存在についてエンドユーザに通知します。 作品システムは[RFC3897]に跡を残さなければなりません。 しかしながら、検出支援には、制限があります。 いくつかの作品システムは、排他的な要求に取り組んで、応答をたどる機会を持っていないかもしれません。 そのうえ、いくつかのアプリケーション・プロトコルには、明白な応答(例えば、イベント伐採サービス)がないかもしれません。
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.
作品検出支援は追跡拡大のサポートでアプリケーション・プロトコルに制限されます。 例えば、UDPの上のDNSは持っていませんが、HTTP[RFC2616]にはそのようなサポートがあります。
6. Consideration (3.3) 'Non-blocking'
6. 考慮(3.3)'非ブロッキング'
"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].
「コンテンツプロバイダーから利用可能な内容の「非作品」バージョンが存在しているなら、作品アーキテクチャによって、ユーザはコンテンツプロバイダーからこの「非作品」バージョンを検索してはいけないことができない」[RFC3238]。
Babir & Rousskov Informational [Page 10] RFC 3914 OPES Treatment of IAB Considerations October 2004
IAB問題2004年10月のBabir&Rousskovの情報[10ページ]のRFC3914作品処理
"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]。 アプリケーションメッセージが迂回指示を含んで、作品仲介者がそれらを無視するために構成されないと、合っている作品仲介者はメッセージを処理しないでしょう。 内容のどんな非作品バージョンも利用可能でない場合にだけ、作品仲介者は、迂回指示を無視するために構成されるかもしれません。 迂回は、いくつかの作品サービスが不可欠であるかもしれないので満足している誤りを生成しますが、そういうものとして構成されないかもしれません。
Bypass support has limitations similar to the two notification- related considerations above.
迂回サポートには、通知が問題を関係づけた2と同様の制限があります。
7. Consideration (4.1) 'URI resolution'
7. 考慮(4.1)'URI解決'
"OPES documentation must be clear in describing these services as being applied to the result of URI resolution, not as URI resolution itself" [RFC3238].
「これらのサービスがURI解決自体ではなく、URI解決の結果に適用されると記述するのにおいて作品ドキュメンテーションは明確であるに違いない」[RFC3238]。
"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.
「作品ScenariosとUse Cases」仕様[RFC3752]は作品フレームワークの範囲にある満足している適合を記録します。 シナリオは要求と応答の満足している適合を含んでいます。 これらの記録された適合はURI解決を含んでいません。 いくつかの環境で、URI(そして、他の種類の識別子かアドレス)を決議するのに記録された作品メカニズムを使用するのは技術的に可能です。 事実上、作品フレームワークはどんな特定の種類の適合も防ぐことができません。
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ノードはCDNによって選ばれたIPアドレスでURLのドメイン名を代入するかもしれません、本質的には満足しているプロデューサー(すなわち、ウェブサイト所有者)を代表してURI解決を実行して。 ユーザPCの上で作業する作品calloutサービスはユーザによって指定されたローカルのイメージを示すためにすべてのHTMLで埋め込まれた広告URLを書き直すかもしれません、本質的には満足している消費者(すなわち、エンドユーザ)を代表してURIリダイレクションを実行して。 そのようなURI操作を作品フレームワーク範囲の外にありますが、事実上、本当の世界から排除できません。
8. Consideration (4.2) 'Reference validity'
8. 考慮(4.2)'参照の正当性'
"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
作品フレームワークは適合サービスを提案しません。 しかしながら、作品追跡要件は作品仲介者の、そして、サービスの識別を含んでいます(詳細に関して、本書では「通知」考慮部を見てください)。 それが必要である、それ
Babir & Rousskov Informational [Page 11] RFC 3914 OPES Treatment of IAB Considerations October 2004
IAB問題2004年10月のBabir&Rousskovの情報[11ページ]のRFC3914作品処理
provided identification can be used to locate information about the OPES intermediaries, including the description of impact on reference validity [RFC3897].
作品仲介者の情報の場所を見つけるのに提供された識別を使用できます、参照の正当性[RFC3897]における影響の記述を含んでいて。
9. Consideration (4.3) 'Addressing extensions'
9. 考慮(4.3)'アドレシング拡大'
"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.
作品フレームワークは臨時のフィックスを含んでいません。 そして、と組み合わせてこのドキュメント、他の作品ドキュメントは、IAB問題についてサービスクリエイターに知らせるために十分であるべきです。 サービスがURI解決をするか、または静かにドキュメント参照の正当性に影響するなら、インターネットアプリケーションアドレッシング体系でサービス影響を見直して、作者がIETFの中で潜在的拡大要件に働くよう要求されます。 そのような動作が現在の作品フレームワークの外にあるでしょう。
10. Consideration (5.1) 'Privacy'
10. 考慮(5.1)'プライバシー'
"The overall OPES framework must provide for mechanisms for end users to determine the privacy policies of OPES intermediaries" [RFC3238].
「エンドユーザが作品仲介者のプライバシーに関する方針を決定するように、総合的な作品フレームワークはメカニズムに備えなければならない」[RFC3238]。
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.
作品追跡メカニズムで、エンドユーザは作品仲介者を特定できます(詳細に関して、本書では「通知」考慮部を見てください)。 彼らのプライバシーに関する方針を含んで、作品仲介者の情報の場所を見つけるのに提供された識別を使用できるのが必要です。
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か作品ワーキンググループで)定義されません。 作品追跡メカニズムで、エンドユーザとコンテンツプロバイダーは作品システム、そして/または、仲介者を特定できます。 作品システムがいったん特定されると、そのシステムの関連情報の場所を見つけるのが可能であると信じられています、プライバシーに関する方針か参照の正当性のリクエスタ認知に関連している情報を含んでいて。
11. Consideration 'Encryption'
11. 考慮'暗号化'
"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
「作品が貸し切りであるなら、また、作品ワーキンググループは、明らかに決めて、作品アーキテクチャはかかわった作品セッションの1つ以上の終わりのそばでの終端間暗号化の使用と互換性があるに違いないかどうか記録しなければならないでしょう。」 作品は終端間暗号化と互換性があるなら、事実上、これが、作品箱がそうであることを確実にするでしょうに。
Babir & Rousskov Informational [Page 12] RFC 3914 OPES Treatment of IAB Considerations October 2004
IAB問題2004年10月のBabir&Rousskovの情報[12ページ]のRFC3914作品処理
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].
「少なくとも終わりの1つまでに知られて、信じられて、IP層で明らかに扱われて、認可される(復号化キーの設備で)ものに制限されている」[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問題について明らかに記載されませんでしたが、上記の引用された要件は、まだ扱われる必要があります。 引用文の文脈は、「終端間暗号化」という句が終わりから端への経路のすべてのリンクに沿った暗号化について言及するのを含意します、関係者かホップ(例えば、プロバイダーと作品仲介者と、作品仲介者とクライアントの間の暗号化)を暗号化するか、または解読するとしての作品仲介者と共に。
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].
作品プロセッサがアプリケーション・プロトコル経路の通常のホップであるので、作品アーキテクチャはそのような暗号化を考慮します、適合させられるアプリケーション・プロトコルがそれをサポートするなら。 サービスが受け取らなければならないcalloutが内容を非暗号化するなら、ホップごとの暗号化に全面散布メッセージ経路保護のために役に立たないでしょうに。 完全なリンク暗号化適用範囲を考慮するために、作品calloutプロトコル(OCP)が任意(交渉される)の輸送暗号化メカニズムで作品プロセッサとcalloutサーバとのOCP関係の暗号化をサポートする、[I-D.がietf-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.
例えば、HTTPホップ(それのいくつかが作品プロセッサであるかもしれない)の中と、そして、それぞれの作品プロセッサとcalloutサーバの間でTLS暗号化[RFC2817]を使用できます。
12. Security Considerations
12. セキュリティ問題
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問題を扱うことになっています。 対応する作品フレームワークドキュメントのSecurity Considerations部で作品メカニズムのセキュリティについて議論します。
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].
例えば、作品追跡メカニズムは作品仲介者が彼らの存在を明らかにするのを必要とすることによって満足している保全と秘密性を保護するのにコンテンツプロバイダーと消費者を助けます。 [RFC3897]のSecurity Considerations部で追跡メカニズムのセキュリティについて議論します。
13. Compliance
13. 承諾
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への作品コンプライアンスの証拠が推薦を含意したとき、このドキュメントは知覚されるかもしれません。 しかしながら、このドキュメントはどんな承諾対象も紹介しません。 作品実装のコンプライアンスは上で議論した他の作品ドキュメントで定義されます。
Babir & Rousskov Informational [Page 13] RFC 3914 OPES Treatment of IAB Considerations October 2004
IAB問題2004年10月のBabir&Rousskovの情報[13ページ]のRFC3914作品処理
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[RFC3238] Floyd, S. and L. Daigle, "IAB
Architectural and Policy Considerations
for Open Pluggable Edge Services", RFC
3238, January 2002.
[RFC3238] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、2002年1月。
[RFC3752] Barbir, A., Burger, E., Chen, R.,
McHenry, S., Orman, H. and R. Penno,
"Open Pluggable Edge Services (OPES)
Use Cases and Deployment Scenarios",
RFC 3752, April 2004.
[RFC3752]のBarbir、A.、バーガー、E.、チェン、R.、マクヘンリー、S.、Orman、H.、およびR.ペンノ、「開いているPluggable縁のサービス(作品)はケースと展開シナリオを使用します」、RFC3752、2004年4月。
[RFC3835] Barbir, A., Penno, R., Chen, R.,
Hofmann, M., and H. Orman, "An
Architecture for Open Pluggable Edge
Services (OPES)", RFC 3835, August
2004.
[RFC3835] Barbir、A.、ペンノ、R.、チェン、R.、ホフマン、M.、およびH.Orman、「開いているPluggable縁のサービスのためのアーキテクチャ(作品)」、RFC3835(2004年8月)。
[RFC3897] Barbir, A., "Open Pluggable Edge
Services (OPES) Entities and End Points
Communication", RFC 3897, September
2004.
[RFC3897]Barbir、A.、「Pluggable縁のサービス(作品)実体とエンドポイントコミュニケーションを開いてください」、RFC3897、2004年9月。
14.2. Informative References
14.2. 有益な参照
[RFC2227] Mogul, J. and P. Leach, "Simple
Hit-Metering and Usage-Limiting for
HTTP", RFC 2227, October 1997.
[RFC2227] ムガール人、J.、P.リーチ、「簡単なヒット計量、HTTPのために用法で制限する」、RFC2227、10月1997日
[RFC2616] Fielding, R., Gettys, J., Mogul, J.,
Frystyk, H., Masinter, L., Leach, P.
and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2616, June
1999.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading
to TLS Within HTTP/1.1", RFC 2817, May
2000.
「HTTP/1.1インチ、RFC2817、2000年5月中にTLSにアップグレードする」[RFC2817]Khare、R.、およびS.ローレンス。
[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.ステッチャー、「作品とのHTTP適合」、Progress、2003年10月のWork。
Babir & Rousskov Informational [Page 14] RFC 3914 OPES Treatment of IAB Considerations October 2004
IAB問題2004年10月のBabir&Rousskovの情報[14ページ]のRFC3914作品処理
[I-D.ietf-opes-ocp-core] Rousskov, A., "OPES Callout Protocol
Core", Work in Progress, November 2003.
[ietf-opes-ocp-コア] A.、「作品Calloutプロトコルコア」というI-D.Rousskovは進歩、2003年11月に働いています。
Authors' Addresses
作者のアドレス
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario CA
アビーBarbirノーテルは3500縦梁アベニューネピアン、オンタリオカリフォルニアをネットワークでつなぎます。
Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com
以下に電話をしてください。 +1 5229年の613 763メール: abbieb@nortelnetworks.com
Alex Rousskov The Measurement Factory
アレックスRousskov測定工場
EMail: rousskov@measurement-factory.com URI: http://www.measurement-factory.com/
メール: rousskov@measurement-factory.com ユリ: http://www.measurement-factory.com/
Babir & Rousskov Informational [Page 15] RFC 3914 OPES Treatment of IAB Considerations October 2004
IAB問題2004年10月のBabir&Rousskovの情報[15ページ]のRFC3914作品処理
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Babir & Rousskov Informational [Page 16]
Babir&Rousskov情報です。[16ページ]
一覧
スポンサーリンク
