RFC3752 日本語訳
3752 Open Pluggable Edge Services (OPES) Use Cases and DeploymentScenarios. A. Barbir, E. Burger, R. Chen, S. McHenry, H. Orman, R.Penno. April 2004. (Format: TXT=29481 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Barbir
Request for Comments: 3752 Nortel Networks
Category: Informational E. Burger
Brooktrout Technology, Inc.
R. Chen
AT&T Labs
S. McHenry
Individual Contributor
H. Orman
Purple Streak Development
R. Penno
Nortel Networks
April 2004
Barbirがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3752 ノーテルはカテゴリをネットワークでつなぎます: 個々の貢献者の紫色の一続きの開発R.ペンノH.Ormanノーテルが2004年4月にネットワークでつなぐ情報のE.の技術Inc.R.チェンAT&TバーガーBrooktrout研究室のS.マクヘンリー
Open Pluggable Edge Services (OPES)
Use Cases and Deployment Scenarios
開いている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). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses.
このメモは、オープンPluggable Edge Services(作品)のために使用の議論にケースを提供して、シナリオを展開に提供します。 仕事は要求、そして/または、応答に実行できたサービスを調べます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Types of OPES services . . . . . . . . . . . . . . . . . . . . 3
2.1. Services performed on requests . . . . . . . . . . . . . 3
2.1.1. Services intending to modify requests . . . . . 3
2.1.2. Services *not* intending to modify requests . . 4
2.2. Services performed on responses. . . . . . . . . . . . . 4
2.2.1. Services intending to modify responses . . . . . 4
2.2.2. Services *not* intending to modify responses . . 5
2.3. Services creating responses. . . . . . . . . . . . . . . 5
3. OPES deployment scenarios . . . . . . . . . . . . . . . . . . 5
3.1. Surrogate Overlays . . . . . . . . . . . . . . . . . . . 6
3.2. Delegate Overlays . . . . . . . . . . . . . . . . . . . 7
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 作品のタイプは.32.1を修理します。 サービスは要求. . . . . . . . . . . . . 3 2.1.1に働きました。 要求. . . . . 3 2.1.2を変更するつもりでありながら、修理します。 変更する*意図ではなく、サービス*が.42.2を要求します。 サービスは応答に働きました。 . . . . . . . . . . . . 4 2.2.1. 応答. . . . . 4 2.2.2を変更するつもりでありながら、修理します。 応答. . 5 2.3を変更するつもりでありながら、*ではなく、*を修理します。 応答を作成するサービス。 . . . . . . . . . . . . . . 5 3. 作品展開シナリオ. . . . . . . . . . . . . . . . . . 5 3.1。 代理のオーバレイ. . . . . . . . . . . . . . . . . . . 6 3.2。 代表オーバレイ. . . . . . . . . . . . . . . . . . . 7
Barbir, et al. Informational [Page 1] RFC 3752 OPES Scenarios April 2004
Barbir、他 [1ページ]情報のRFC3752作品シナリオ2004年4月
3.3. Enterprise environment . . . . . . . . . . . . . . . . . 8
3.4. Callout Servers . . . . . . . . . . . . . . . . . . . . 9
3.5. Chaining of OPES data filters and callout servers . . . 9
3.5.1. Chaining along the content path. . . . . . . . . 9
3.5.2. Chaining along the callout path. . . . . . . . . 9
4. Failure cases and service notification . . . . . . . . . . . . 10
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 11
6. Informative References . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
3.3. エンタープライズ環境. . . . . . . . . . . . . . . . . 8 3.4。 Calloutサーバ. . . . . . . . . . . . . . . . . . . . 9 3.5。 作品データフィルタとcalloutサーバ. . . 9 3.5.1の推論。 満足している経路に沿って鎖を作ります。 . . . . . . . . 9 3.5.2. callout経路に沿って鎖を作ります。 . . . . . . . . 9 4. 失敗事件とサービス通知. . . . . . . . . . . . 10 5。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 11 6. 有益な参照. . . . . . . . . . . . . . . . . . . . 11 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 12 8。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 12 9。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 14
1. Introduction
1. 序論
The Open Pluggable Edge Services (OPES) [1] architecture 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. The execution of such services is governed by a set of filtering rules installed on the OPES processor.
オープンPluggable Edge Services(作品)[1]アーキテクチャは情報提供業者と、データ消費者と、ゼロの間のアプリケーション・サービス(作品サービス)か、より多くの作品プロセッサを協力して可能にします。 考慮しているアプリケーション・サービスは、情報提供業者とデータ消費者の間で交換されたアプリケーションレベルメッセージを、分析して、ことによると変えます。 そのようなサービスの実行は作品プロセッサにインストールされた規則をフィルターにかけるセットによって治められます。
The rules enforcement can trigger the execution of service applications local to the OPES processor. Alternatively, the OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout [6] servers.
実施が作品プロセッサへのローカルのサービスアプリケーションの実行の引き金となることができるという規則。 あるいはまた、作品プロセッサは、1つ以上のリモートcallout[6]サーバを伝えて、協力することによって、サービス実行の責任を分配できます。
The document presents examples of services in which Open Pluggable Edge Services (OPES) would be useful. There are different types of OPES services: services that modify requests, services that modify responses, and a special case of the latter, services that create responses.
ドキュメントはオープンPluggable Edge Services(作品)が役に立つサービスの例を提示します。 異なったタイプの作品サービスがあります: 要求を変更するサービス、応答を変更するサービス、および後者の特別なケース、応答を作成するサービス。
The work also examines various deployment scenarios of OPES services. The two main deployment scenarios, as described by the OPES architecture [1], are surrogate overlays and delegate overlays. Surrogate overlays act on behalf of data provider applications, while delegate overlays act on behalf of data consumer applications. The document also describes combined surrogate and delegate overlays, as one might find within an enterprise deployment.
また、仕事は作品サービスの様々な展開シナリオを調べます。 作品アーキテクチャ[1]によって説明される2つの主な展開シナリオが、代理のオーバレイであり、オーバレイを代表として派遣します。 代理のオーバレイは情報提供業者アプリケーションを代表して行動しますが、代表オーバレイはデータ消費者アプリケーションを代表して行動します。 また、人が企業展開の中で見つけるかもしれないようにドキュメントは結合した代理と代表オーバレイについて説明します。
The document is organized as follows: Section 2 discusses the various types of OPES services. Section 3 introduces OPES deployment scenarios. Section 4 discusses failure cases and service notification. Section 5 discusses security considerations.
ドキュメントは以下の通りまとめられます: セクション2は様々なタイプの作品サービスについて論じます。 セクション3は作品展開シナリオを紹介します。 セクション4は失敗事件とサービス通知について論じます。 セクション5はセキュリティ問題について論じます。
Barbir, et al. Informational [Page 2] RFC 3752 OPES Scenarios April 2004
Barbir、他 [2ページ]情報のRFC3752作品シナリオ2004年4月
The IAB has expressed architectural and policy concerns [2] about OPES. Other OPES documents that may be relevant are, "OPES Service Authorization and Enforcement Requirements" [5]. See references [3, 4] for recommended background reading.
IABは作品に関する建築するのと方針心配[2]を述べました。 他の関連するかもしれない作品ドキュメントは「作品は承認と実施要件を修理する」ということです。[5]。 お勧めのバックグラウンドの参照[3、4]が読んでいるのを見てください。
2. Types of OPES services
2. 作品サービスのタイプ
OPES scenarios involve services that can be performed on requests for data and/or responses. OPES services can be classified into three categories: services performed on requests, services performed on responses, and services creating responses. In Figure 1, the four service activation points for an OPES processor are depicted. The data dispatcher examines OPES rules, enforces policies, and invokes service applications (if applicable) at each service activation point.
作品シナリオはデータ、そして/または、応答を求める要求に実行できるサービスにかかわります。 作品サービスを3つのカテゴリに分類できます: 要求に実行されたサービス、応答に実行されたサービス、および応答を作成するサービス。 図1では、作品プロセッサのための4つのサービス駆動位置が表現されます。 データ発送者は、それぞれのサービス駆動位置に作品規則を調べて、方針を実施して、サービスアプリケーションを呼び出します(適切であるなら)。
+------------------------------------------------+
| +-------------+-------------+ |
| | Service Application | |
| +---------------------------+ |
Responses | Data Dispatcher | Responses
<============4== +---------------------------+ <=3===========
Requests | HTTP | Requests
=============1=> +---------------------------+ ==2==========>
| OPES Processor |
+------------------------------------------------+
+------------------------------------------------+ | +-------------+-------------+ | | | サービスアプリケーション| | | +---------------------------+ | 応答| データ発送者| 応答<。============4== +---------------------------+ <=3=========== 要求| HTTP| 要求=============1 =>+---------------------------+ ==2==========>| 作品プロセッサ| +------------------------------------------------+
Figure 1: Service Activation Points
図1: サービス駆動位置
2.1. Services performed on requests
2.1. 要求に実行されたサービス
An OPES service performed on HTTP requests may occur when a request arrives at an OPES processor (point 1) or when it is about to leave the OPES processor (point 2).
要求が作品プロセッサ(ポイント1)に到着するか、または作品プロセッサ(ポイント2)が残っていようとしているとき、HTTP要求に実行された作品サービスは起こるかもしれません。
The services performed on requests can further be divided into two cases: those that intend to modify requests and those that do not.
さらに要求に実行されたサービスは2つのケースに分割できます: 要求を変更するつもりであるものとそうしないそれら。
2.1.1. Services intending to modify requests
2.1.1. 要求を変更する意図を修理します。
An OPES processor may modify a service request on behalf of the data consumer for various reasons, such as:
作品プロセッサは以下などの様々な理由によるデータ消費者を代表してサービスのリクエストを変更するかもしれません。
o Owner of a Web access device might need control over what kind of
Web content can be accessed with the device, parental control for
example.
o ウェブアクセスデバイスの所有者はデバイス(例えば、ペアレンタル・コントロール)でどういうウェブ内容にアクセスできるかのコントロールを必要とするかもしれません。
o Organization may restrict or redirect access to certain web
o 組織は、あるウェブへのアクセスを制限するか、または向け直すかもしれません。
Barbir, et al. Informational [Page 3] RFC 3752 OPES Scenarios April 2004
Barbir、他 [3ページ]情報のRFC3752作品シナリオ2004年4月
services based on various criteria such as time of the day or the
employee access privileges.
1日か従業員の時間などの様々な評価基準に基づくサービスは特権にアクセスします。
o Hiding the data consumer's identity, user agent, or referrer.
o データ消費者のアイデンティティ、ユーザエージェント、またはリファラーを隠します。
o Adding user preferences or device profile to the service request
to get personalized or adapted services.
o ユーザー選択かデバイスプロフィールを得るサービスのリクエストに追加するのは、サービスを個人化したか、または適合させました。
o Blocking or redirecting a service request due to a corporate
policy.
o 会社の方針のためサービスのリクエストを妨げるか、または向け直します。
An OPES processor may also modify a service request on behalf of the data provider in several ways, such as:
また、作品プロセッサは以下などのいくつかの方法で情報提供業者を代表してサービスのリクエストを変更するかもしれません。
o Redirecting the request to a different server to reduce the server
work load.
o サーバ仕事量を減少させるために異なったサーバに要求を向け直します。
o Redirecting image requests to improve access time.
o アクセスタイムを改良するというイメージ要求を向け直します。
2.1.2. Services *not* intending to modify requests
2.1.2. 要求を変更するつもりでありながら、*ではなく、*を修理します。
An OPES processor may invoke useful service applications that do not modify the user requests. Examples include:
作品プロセッサはユーザ要求を変更しない役に立つサービスアプリケーションを呼び出すかもしれません。 例は:
o Administrative functions for the data provider, such as service
monitoring or usage tracking for billing purposes.
o 情報提供業者のための支払い目的のために追跡されるサービスモニターか用法などの行政機能。
o Useful services for the data consumer, such as user profiling
(with the user's consent) for service adaptation later on.
o 後で間のサービス適合のためのユーザプロフィールなどのデータ消費者(ユーザの同意がある)にとって、役に立つサービス。
2.2. Services performed on responses
2.2. 応答に実行されたサービス
An OPES service performed on HTTP responses may occur when a response arrives at an OPES processor (point 3) or when it is about to leave the OPES processor (point 4). In the case of a caching proxy, the former service may be an encoding operation before the content is stored in the cache, while the latter may be a decoding operation before the content is returned to the data consumer.
応答が作品プロセッサ(ポイント3)に到着するか、または作品プロセッサ(ポイント4)が残っていようとしているとき、HTTP応答に実行された作品サービスは起こるかもしれません。 キャッシュしているプロキシの場合では、内容がキャッシュで保存される前に前のサービスはコード化作業であるかもしれません、データ消費者に内容を返す前に後者が解読操作であるかもしれませんが。
The services performed on responses can further be divided into two cases: those that intend to modify responses and those that do not.
さらに応答に実行されたサービスは2つのケースに分割できます: 応答を変更するつもりであるものとそうしないそれら。
2.2.1. Services intending to modify responses
2.2.1. 応答を変更する意図を修理します。
There are several reasons why responses from the data providers might be modified before delivery to the data consumer:
情報提供業者からの応答が配送の前にデータ消費者に変更されるかもしれないいくつかの理由があります:
o Content adaptation: the data provider may not have all the device
o 満足している適合: 情報提供業者には、すべてのデバイスがあるかもしれないというわけではありません。
Barbir, et al. Informational [Page 4] RFC 3752 OPES Scenarios April 2004
Barbir、他 [4ページ]情報のRFC3752作品シナリオ2004年4月
profiles and templates necessary to transcode the original content
into a format appropriate for mobile devices of limited screen
size and display capabilities.
形式へのオリジナルコンテンツが限られた画面サイズとディスプレイ能力のモバイル機器のために当てる「移-コード」に必要なプロフィールとテンプレート。
o Language translation: the data provider may not have all the
translation capabilities needed to deliver the same content in
multiple languages to various areas around the world. An OPES
processor may perform the language translation or it may invoke
different callout servers to perform different language
translation tasks.
o 言語翻訳: 情報提供業者には、複数の言語の同じ内容を世界中の様々な領域に提供するのに必要であるすべての翻訳能力がないかもしれません。 作品プロセッサが言語翻訳を実行するかもしれませんか、またはそれは、異なった言語翻訳タスクを実行するために異なったcalloutサーバを呼び出すかもしれません。
2.2.2. Services *not* intending to modify responses
2.2.2. 応答を変更するつもりでありながら、*ではなく、*を修理します。
An OPES service may be performed on the responses without modifying them. Examples include:
それらを変更しないで、作品サービスは応答に実行されるかもしれません。 例は:
o Logging/Monitoring: Each response may be examined and recorded for
monitoring or debugging purposes.
o 伐採/モニター: 各応答は、目的をモニターするか、またはデバッグするために調べられて、記録されるかもしれません。
o Accounting: An OPES processor may record the usage data (time and
space) of each service request for billing purposes.
o 会計: 作品プロセッサは支払い目的のためのそれぞれのサービスのリクエストに関する用法データ(時間と空間)を記録するかもしれません。
2.3. Services creating responses
2.3. 応答を作成するサービス
Services creating responses may include OPES services that dynamically assemble web pages based on the context of the data consumer application.
応答を作成するサービスはダイナミックにデータ消費者アプリケーションの文脈に基づくウェブページを組み立てる作品サービスを含むかもしれません。
Consider a content provider offering web pages that include a local weather forecast based on the requestor's preferences. The OPES service could analyze received requests, identify associated user preferences, select appropriate templates, insert the corresponding local weather forecasts, and would then deliver the content to the requestor. Note that the OPES processor may perform the tasks with or without direct access to the weather data. For example, the service could use locally cached weather data or it could simply embed a URL pointing to another server that holds the latest local weather forecast information.
要請者の好みに基づく地方の天気予報を含んでいるウェブページを提供するコンテンツプロバイダーを考えてください。 作品サービスは受信された要求を分析するかもしれません、そして、関連ユーザー選択を特定してください、そして、適切なテンプレートを選択してください、そして、対応する地方の天気予報を挿入してください、そして、次に、内容を要請者に提供するでしょう。 作品プロセッサが気象データへの直接アクセスのあるなしにかかわらずタスクを実行するかもしれないことに注意してください。 例えば、サービスが局所的にキャッシュされた気象データを使用するかもしれませんか、またはそれは単に最新のローカルの天気予報情報を保持する別のサーバを示すURLを埋め込むかもしれません。
3. OPES deployment scenarios
3. 作品展開シナリオ
OPES entities can be deployed over an overlay network that supports the provisioning of data services in a distributed manner. Overlay networks are an abstraction that creates a virtual network of connected devices layered on an existing underlying IP networks in order to perform application level services.
分配された方法における、データサービスの食糧を供給することをサポートするオーバレイネットワークの上で作品実体を配布することができます。 オーバレイネットワークは存在のときにアプリケーションレベルサービスを実行するためにIPネットワークの基礎となりながら層にされた接続デバイスの仮想ネットワークを創設する抽象化です。
The use of overlay networks creates virtual networks that via OPES
ネットワークが仮想に作成するオーバレイの使用は作品でそれをネットワークでつなぎます。
Barbir, et al. Informational [Page 5] RFC 3752 OPES Scenarios April 2004
Barbir、他 [5ページ]情報のRFC3752作品シナリオ2004年4月
entities enables the necessary network infrastructure to provide better services for data consumer and provider applications. At the application level, the resulting overlay networks are termed OPES Services Networks.
実体は、必要なネットワークインフラがデータ消費者とプロバイダーアプリケーションのための、より良いサービスを提供するのを可能にします。 アプリケーションレベルでは、結果として起こるオーバレイネットワークは作品Services Networksと呼ばれます。
There are two parties that are interested in the services that are offered by OPES entities, the delegate and the surrogate. Delegates are authorized agents that act on behalf of data consumers. Surrogates are authorized agents that act on behalf of data providers.
作品実体によって提供されるサービスに興味を持っている2回のパーティー、代表、および代理がいます。 代表はデータ消費者を代表して行動する委任代理人です。 代理は情報提供業者を代表して行動する委任代理人です。
All parties that are involved in enforcing policies must communicate the policies to the parties that are involved. These parties are trusted to adhere to the communicated policies.
方針を実施するのにかかわるすべてのパーティーがかかわるパーティーに方針を伝えなければなりません。 これらのパーティーがコミュニケートしている方針を固く守ると信じられます。
In order to delegate fine-grained trust, the parties must convey policy information by implicit contract, by a setup protocol, by a dynamic negotiation protocol, or in-line with application data headers.
きめ細かに粒状の信頼を代表として派遣するために、パーティーは暗黙の契約で方針情報を伝えなければなりません、セットアッププロトコルで、アプリケーションデータヘッダーに伴うプロトコルの、または、インラインのダイナミックな交渉で。
3.1. Surrogate Overlays
3.1. 代理のオーバレイ
A surrogate overlay is a specific type of OPES service network, which is delegated the authority to provide data services on behalf of one or more origin servers. Such services include, but are not limited to, dynamic assembling of web pages, watermarking, and content adaptation.
代理のオーバレイは特定のタイプの作品サービスネットワークです。(そのネットワークは代表として派遣して、データを提供する権威が1つ以上の発生源を代表してサーバを修理するということです)。 動力がウェブページを集合させることでの透かし、および満足している適合に含んでいますが、そのようなサービスは限られていません。
The elements of surrogate overlays act on behalf of origin severs and logically belong to the authoritative domain of the respective origin servers. The scenario is depicted in Figure 2.
発生源を代表した代理のオーバレイ条例の原理は、それぞれの発生源サーバの正式のドメインに断ち切って、論理的に属します。 シナリオは図2に表現されます。
Barbir, et al. Informational [Page 6] RFC 3752 OPES Scenarios April 2004
Barbir、他 [6ページ]情報のRFC3752作品シナリオ2004年4月
*********************************************
* *
* +--------+ Authoritative *
* | Origin | Domain *
* | Server | *
* +--------+ +------------+ *
* | | OPES Admin | *
* | | Server | *
* | +------------+ *
* | / *
* | / *
* +--------------+ +-----------------+ *
* | OPES |----- | Remote Call-out | *
* | Processor | | Server | *
* +--------------+ +-----------------+ *
* | *
*********************************************
|
|
|
+---------------------------+
| Data consumer application |
+---------------------------+
********************************************* * * * +--------+ 正式の**| 発生源| ドメイン**| サーバ| * * +--------+ +------------+ * * | | 作品アドミン| * * | | サーバ| * * | +------------+ * * | / * * | / * * +--------------+ +-----------------+ * * | 作品|----- | 外では、呼びますリモート。| * * | プロセッサ| | サーバ| * * +--------------+ +-----------------+ * * | * ********************************************* | | | +---------------------------+ | データ消費者アプリケーション| +---------------------------+
Figure 2: Authoritative Domains for Surrogate Overlays
図2: 代理のオーバレイのための正式のドメイン
3.2. Delegate Overlays
3.2. 代表オーバレイ
A delegate overlay is a specific type of OPES service network, which is delegated the authority to provide data services on behalf of one or more data consumer applications.
代表オーバレイは特定のタイプの作品サービスネットワークです。(そのネットワークは代表として派遣して、データを提供する権威が1人以上のデータ消費者を代表してアプリケーションを供給するということです)。
Delegate overlays provide services that would otherwise be performed by the data consumer applications. Such services include, but are not limited to, virus scanning and content filtering.
代表オーバレイはそうでなければデータ消費者アプリケーションで実行されるサービスを提供します。 含んでいますが、サービスが制限されないそのようなもの、ウイルススキャン、およびコンテントのフィルタリング。
The elements of delegate overlays logically belong to the authoritative domain of the respective data consumer application. The situation is illustrated in Figure 3.
代表オーバレイの要素はそれぞれのデータ消費者アプリケーションの正式のドメインに論理的に属します。 状況は図3で例証されます。
Barbir, et al. Informational [Page 7] RFC 3752 OPES Scenarios April 2004
Barbir、他 [7ページ]情報のRFC3752作品シナリオ2004年4月
+--------+
| Origin |
| Server |
+--------+
|
|
|
*********************************************
* | *
* +--------------+ +-----------------+ *
* | OPES |----- | Remote Call-out | *
* | Processor | | Server | *
* +--------------+ +-----------------+ *
* | \ *
* | +------------+ *
* | | OPES Admin | *
* | | Server | *
* | +------------+ *
* +---------------------+ *
* | Data consumer Appl. | Authoritative *
* +---------------------+ Domain *
* *
*********************************************
+--------+ | 発生源| | サーバ| +--------+ | | | ********************************************* * | * * +--------------+ +-----------------+ * * | 作品|----- | 外では、呼びますリモート。| * * | プロセッサ| | サーバ| * * +--------------+ +-----------------+ * * | \ * * | +------------+ * * | | 作品アドミン| * * | | サーバ| * * | +------------+ * * +---------------------+ * * | データ消費者Appl。 | 正式の**+---------------------+ ドメイン************************************************
Figure 3: Authoritative Domains for Delegate Overlays
図3: 代表オーバレイのための正式のドメイン
3.3. Enterprise environment
3.3. エンタープライズ環境
Deployment of OPES services in an enterprise environment is unique in several ways:
企業環境における作品サービスの展開はいくつかの方法でユニークです:
o Both data providers and data consumers are in the same
administrative domain and trust domain. This implies that the
logical OPES administrator has the authority to enforce corporate
policies on all data providers, data consumers, and OPES entities.
o 情報提供業者とデータ消費者の両方が同じ管理ドメインと信頼ドメインにあります。 これは、論理的な作品管理者には会社の方針にすべての情報提供業者、データ消費者、および作品実体に押しつける権威があるのを含意します。
o In the case when a callout server outside the corporate firewall
is invoked for services (such as language translation) that cannot
be performed inside the corporation, care must be taken to
guarantee a secure communication channel between the callout
server and corporate OPES entities. The callout server must also
adhere to all corporate security policies for the services
authorized.
o 法人のファイアウォールの外のcalloutサーバが会社の中で実行できないサービス(言語翻訳などの)のために呼び出されるときの場合では、calloutサーバと法人の作品実体の間の安全な通信チャネルを保証するために注意しなければなりません。 また、calloutサーバはサービスのための方針が認可したすべての企業の機密保持を固く守らなければなりません。
Barbir, et al. Informational [Page 8] RFC 3752 OPES Scenarios April 2004
Barbir、他 [8ページ]情報のRFC3752作品シナリオ2004年4月
3.4. Callout Servers
3.4. Calloutサーバ
In some cases the deployment of OPES services can benefit from the use of callout servers that could distribute the workload of OPES processors or to contract specialized services from other OPES providers.
いくつかの場合、作品サービスの展開が作品プロセッサのワークロードを分配できたcalloutサーバの使用の利益を得ることができますか、または契約するのは他の作品プロバイダーからサービスを専門にしました。
In general, operations such as virus scanning that operate on large objects are better handled through the use of a dedicated callout server that is better designed to perform the memory intensive task than what an OPES processor could handle.
一般に、大きいオブジェクトを作動させるウイルススキャンなどの操作は作品プロセッサが扱うことができたことよりメモリの徹底的なタスクを実行するように設計されるほうがよいひたむきなcalloutサーバの使用で扱われるほうがよいです。
3.5. Chaining of OPES data filters and callout servers
3.5. 作品データフィルタとcalloutサーバの推論
OPES data processors can be "chained" in two dimensions: along the content path or along the callout path. In the latter case, the callout servers can themselves be organized in series for handling requests. Any content that is touched by more than one data processor or more than one callout server has been handled by a "chain".
二次元で作品データ処理装置を「チェーニングできます」: 満足している経路かcallout経路に沿って。 後者の場合でcalloutする、組織化されたコネが取り扱い要求のためのシリーズであったなら自分たちでサーバ缶をcalloutします。 1台以上のデータ処理装置か1つ以上のcalloutサーバによって触れられるどんな内容も「チェーン」によって扱われました。
NOTE: Chaining of callout servers is deferred from version 1 of the Protocol. The discussion of chaining is included here for completeness.
以下に注意してください。 calloutサーバの推論はプロトコルのバージョン1から延期されます。 推論の議論は完全性のためにここに含まれています。
3.5.1. Chaining along the content path
3.5.1. 満足している経路に沿って鎖を作ること。
An OPES provider may have assigned OPES services to a set of processors arranged in series. All content might move through the series, and if the content matches the rules for a processor, it is subjected to the service. In this way, the content can be enhanced by several services. This kind of chaining can be successful if the services are relatively independent. For example, the content might be assembled by a service early in the chain and then further decorated by a later service.
作品プロバイダーは連続的にアレンジされた1セットのプロセッサに対する作品サービスを割り当てたかもしれません。 すべての内容がシリーズを通して移行するかもしれません、そして、内容がプロセッサのための規則に合っているなら、それはサービスにかけられます。 このように、いくつかのサービスで内容を高めることができます。 サービスが比較的独立しているなら、この種類の推論はうまくいっている場合があります。 例えば、内容はチェーンで早くて次に、後のサービスでさらに飾り付けををされたサービスで組み立てられるかもしれません。
3.5.2. Chaining along the callout path
3.5.2. callout経路に沿って鎖を作ること。
Alternatively, an OPES data processor might act as a content-level switch in a cluster of other data processors and callout servers.
あるいはまた、作品データ処理装置はひとかたまりになって他のデータ処理装置とcalloutサーバの満足しているレベルスイッチとして作動するかもしれません。
The first stage might develop a processing schedule for the content and direct it to other OPES data processors and/or callout servers. For example, OPES processor A might handle all services assembling content, OPES processor B might handle all services involving URL translation, and OPES processor C might handle all content security services. The first processor would determine that processors A and
第一段階は、内容のために処理スケジュールを開発して、他の作品データ処理装置、そして/または、calloutサーバにそれを向けるかもしれません。 例えば、作品プロセッサAは内容を組み立てるすべてのサービスを扱うかもしれません、そして、作品プロセッサBはURL翻訳にかかわるすべてのサービスを扱うかもしれません、そして、作品プロセッサCはすべての満足しているセキュリティー・サービスを扱うかもしれません。 そして最初のプロセッサがそのプロセッサAを決定するだろう。
Barbir, et al. Informational [Page 9] RFC 3752 OPES Scenarios April 2004
Barbir、他 [9ページ]情報のRFC3752作品シナリオ2004年4月
C were needed for a particular content object, and it would direct the content to those processors. In turn, the processors might use several callout servers to accomplish the task.
Cが特定の満足しているオブジェクトに必要でした、そして、それはそれらのプロセッサに内容を向けるでしょう。 順番に、プロセッサは、タスクを達成するのにいくつかのcalloutサーバを使用するかもしれません。
4. Failure cases and service notification
4. 失敗事件とサービス通知
These are illustrative cases where information about OPES processing can help endpoint users determine where and why content modifications are being performed.
これらは作品処理の情報が、終点ユーザが、満足している変更がどこでなぜ実行されているかを決心しているのを助けることができる具体例です。
o Content provider uses an OPES data processor to enhance content
based only on context local to the provider. The local context
might be time of day, local URL, or available advertising, for
example. The content provider might find OPES logging to be
sufficient for debugging any problems in this case. However, the
content provider might also try direct probing by issuing a
request for the content and examining headers related to tracing.
If unexpected parameters show up in the trace headers, the content
provider's administrator can use these to correct the OPES rules
or detect the presence of an unexpected OPES processor in the
content path.
o コンテンツプロバイダーは、プロバイダーへのローカルの関係だけに基づく内容を高めるのに作品データ処理装置を使用します。 例えば、ローカルの関係は、時刻、ローカルのURL、または利用可能な広告であるかもしれません。 コンテンツプロバイダーは、作品伐採がこの場合どんな問題もデバッグするのに十分であることがわかるかもしれません。 しかしながら、また、コンテンツプロバイダーは、内容に関する要求を出して、たどるのに関連するヘッダーを調べることによって、ダイレクト調べを試みるかもしれません。 予期していなかったパラメタが跡のヘッダーに現れるなら、コンテンツプロバイダーの管理者は、満足している経路に作品規則を修正するか、または予期していなかった作品プロセッサの存在を検出するのにこれらを使用できます。
o Content provider uses an OPES data processor to enhance content
based on context related to the requestor. The requestor may
notice that his requests do not elicit the same response as
another requestor. He may, for example, get an error message. If
he believes there is a configuration error on the OPES data
processor, he will need to provide information to the
administrator of it. If the information includes "OPES service
access control, action: blocked", for example, he can inquire
about the circumstances that will allow him to be added to the
access control list. In another example, if he sees a picture
unrelated to the surrounding text, and if the tracing shows "OPES
service choose picture, action: insert 640x480 weather.gif", he
might complain that the OPES service does not properly recognize
his geographic location and inserts the wrong weather map. In any
case, if the information is forwarded to the content provider, the
problem may be fixed.
o コンテンツプロバイダーは、要請者に伝える文脈に基づく内容を高めるのに作品データ処理装置を使用します。 要請者は、彼の要求が別の要請者と同じ応答を引き出さないのに気付くかもしれません。 例えば、彼はエラーメッセージを得るかもしれません。 作品データ処理装置の上に構成誤りがあると信じていると、彼は、それの管理者に情報を提供する必要があるでしょう。 情報インクルードである、「作品サービスはコントロール、動作にアクセスします」。 「妨げられます」、例えば、彼は彼がアクセスコントロールリストに追加されるのを許容する事情について問い合わせをすることができます。 彼は周囲のテキストに関係ない画像を見ます、そして、別の例、追跡は「作品サービスが画像を選びます、動作」を示しています。 「差し込み640x480weather.gif」、彼は作品サービスが適切に彼の地理的な位置を認識しないで、間違った天気図を挿入すると不平を言うかもしれません。 どのような場合でも、情報をコンテンツプロバイダーに転送するなら、問題を修正するかもしれません。
o End user has OPES processor available as part of his network
access environment. The end user may have selected "translate
English to Spanish" as an OPES service. If he sees "OPES service
language translation, action: destination language not supported,
no action", then he may inquire of the OPES service provider about
what languages are supported by the package. If the end user
feels that the source language is not properly represented by the
o エンドユーザは彼のネットワークアクセス環境の一部として利用可能な作品プロセッサを持っています。 エンドユーザは作品サービスとして「英語をスペイン語に翻訳してください」を選定したかもしれません。 彼が、「作品は言語翻訳、動作を修理します」がわかるなら 当時の彼は、「言語がサポートしなかった目的地、動作がありません」とどんな言語がパッケージによってサポートされるかに関する作品サービスプロバイダーに問い合わせるかもしれません。 エンドユーザは、原言語が適切に表されないと感じます。
Barbir, et al. Informational [Page 10] RFC 3752 OPES Scenarios April 2004
Barbir、他 [10ページ]情報のRFC3752作品シナリオ2004年4月
provider, resulting in inability for the service to operate, he
(or the language service provider) can contact the content
provider.
プロバイダー、サービスが作動できないことをもたらして、彼(または、言語サービスプロバイダー)はコンテンツプロバイダーに連絡できます。
o If the content provider gets complaints from users about the
translation service and feels that the problem is not in the
content but in the service, he may recommend that the service not
be applied to his pages. He can do that through content headers,
for example, with the notation "No OPES service #8D3298EB" or "No
OPES class language translation".
o コンテンツプロバイダーが、翻訳サービスに関してユーザから苦情を得て、問題が内容にはあるのではなく、サービス中であると感じるなら、彼は、サービスが彼のページに適用されないことを勧めるかもしれません。 例えば、彼は満足しているヘッダーを通して記法「いいえ作品サービス#8D3298EB」にもかかわらず、「作品クラス言語翻訳がありません」でそれができます。
o End user's ISP or enterprise uses OPES to control user access
based on user profiles. The end user can see that the OPES
services are being applied by his ISP, but he cannot control them.
If he feels that the transformations bowdlerize the content he can
complain to the provider organization.
o エンドユーザのISPか企業が、ユーザ・プロファイルに基づくユーザアクセスを制御するのに作品を使用します。 エンドユーザは、作品サービスが彼のISPによって適用されているのを見ることができますが、彼はそれらを制御できません。 変換が内容を削除すると感じるなら、彼はプロバイダー組織に不平を言うことができます。
o The content provider or end user relies on a content distribution
network and OPES is used within that network. OPES may be
authorized by either the content provider, end user, or both. The
content provider may suspect that his access control rules are not
being applied properly, for example. He may ask for notification
on all accesses to his content through a log. This request and
the logfile are outside the OPES architecture; there are security
implications for the request, the response, and the resources used
by the logfile.
o コンテンツプロバイダーかエンドユーザが満足している流通機構を当てにします、そして、作品はそのネットワークの中で使用されます。 作品はコンテンツプロバイダー、エンドユーザ、または両方によって認可されるかもしれません。 コンテンツプロバイダーは、彼のアクセス制御規則が適切に、例えば適用されていないと疑うかもしれません。 彼はログを通して彼の内容へのすべてのアクセスに関する通知を求めるかもしれません。 作品アーキテクチャの外でこの要求とログファイルがあります。 ログファイルによる要求、応答、および運用資金のためのセキュリティ含意があります。
5. Security Considerations
5. セキュリティ問題
The document presents usage scenarios and deployment cases. Issues related to the overall security of OPES entities are given in [1].
ドキュメントは用法シナリオと展開ケースを提示します。 [1]で作品実体の総合的なセキュリティに関連する問題を与えます。
6. Informative References
6. 有益な参照
[1] A. Barbir et al., "An Architecture for Open Pluggable Edge
Services (OPES)", Work in Progress, July 2002.
[1] A.Barbir他、「開いているPluggable縁のサービス(作品)のための構造」、Progress、2002年7月のWork。
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[2] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、2002年1月。
[3] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
Waldbusser, "Terminology for Policy-Based Management", RFC 3198,
November 2001.
[3]WesterinenとA.とSchnizleinとJ.とStrassnerとJ.とScherlingとM.、クインとB.とハーツォグとS.とHuynhとA.とカールソンとM.とペリーとJ.とS.Waldbusser、「方針を拠点とする管理のための用語」RFC3198(2001年11月)。
Barbir, et al. Informational [Page 11] RFC 3752 OPES Scenarios April 2004
Barbir、他 [11ページ]情報のRFC3752作品シナリオ2004年4月
[4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[4] フィールディング、R.、Gettys、J.、ムガール人、J.、ニールセン、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[5] OPES Working Group, "OPES Service Authorization and Enforcement
Requirements", Work in Progress, May 2002.
[5] 「作品サービス認可と実施要件」という作品作業部会は進歩、2002年5月に働いています。
[6] Beck, A., et al., "Requirements for OPES Callout Protocols",
Work in Progress, July 2002.
[6] べック、A.、他、「作品Calloutプロトコルのための要件」、Progress、2002年7月のWork。
7. Acknowledgements
7. 承認
The authors would like to thank the participants of the OPES WG for their comments on this document.
作者はこのドキュメントの彼らのコメントについてOPES WGの関係者に感謝したがっています。
8. Authors' Addresses
8. 作者のアドレス
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada
アビーBarbirノーテルは3500縦梁アベニューネピアン、オンタリオのK2H8の9Eのカナダをネットワークでつなぎます。
Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com
以下に電話をしてください。 +1 5229年の613 763メール: abbieb@nortelnetworks.com
Eric W. Burger Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079
エリックW.バーガーBrooktrout技術Inc.18Keewaydin礼拝堂博士、ニューハンプシャー 03079
EMail: e.burger@ieee.org
メール: e.burger@ieee.org
Yih-Farn Robin Chen AT&T Labs - Research 180 Park Avenue Florham Park, NJ 07932 US
Yih-FarnロビンチェンAT&T研究室--研究180パーク・アベニューFlorham公園、ニュージャージー07932米国
Phone: +1 973 360 8653 EMail: chen@research.att.com
以下に電話をしてください。 +1 8653年の973 360メール: chen@research.att.com
Barbir, et al. Informational [Page 12] RFC 3752 OPES Scenarios April 2004
Barbir、他 [12ページ]情報のRFC3752作品シナリオ2004年4月
Stephen McHenry 305 Vineyard Town Center, #251 Morgan Hill, CA 95037 US
ビンヤード・タウンのセンター、スティーブン・マクヘンリー305モーガン・ヒル、#251カリフォルニア95037米国
Phone: +1 408 683 2700 EMail: stephen@mchenry.net
以下に電話をしてください。 +1 2700年の408 683メール: stephen@mchenry.net
Hilarie Orman Purple Streak Development
Hilarie Ormanの紫色の一続きの開発
EMail: ho@alum.mit.edu
メール: ho@alum.mit.edu
Reinaldo Penno Nortel Networks 600 Technology Park Drive Billerica, MA 01803 US
レイナルドペンノノーテルネットワーク600技術公園Drive MA01803ビルリカ(米国)
EMail: rpenno@nortelnetworks.com
メール: rpenno@nortelnetworks.com
Barbir, et al. Informational [Page 13] RFC 3752 OPES Scenarios April 2004
Barbir、他 [13ページ]情報のRFC3752作品シナリオ2004年4月
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Barbir, et al. Informational [Page 14]
Barbir、他 情報[14ページ]
一覧
スポンサーリンク
