Network Working Group Internet Architecture Board (IAB)
Request for Comments: 3238 S. Floyd
Category: Informational L. Daigle
January 2002
IAB Architectural and Policy Considerations for
Open Pluggable Edge Services
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of Open Pluggable Edge Services (OPES) in the IETF. OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user.
このドキュメントは、IETFで開くプラグイン可能なエッジサービス（OPES）のチャーターに関連するいくつかの建築や政策問題に関するIABのコメントや提言が含まれています。 OPESは、オリジンサーバとクライアントの間のウェブプロキシキャッシュで、例えば、ネットワーク内のアプリケーション・レベルの仲介で展開されるだろうサービスです。これらの仲介者は、コンテンツプロバイダまたはエンドユーザーのいずれかの明示的な同意を得て、変換またはコンテンツをフィルタリングします。
Open Pluggable Edge Services (OPES) are services that would be deployed in the network, for example, at a web proxy cache between the origin server and the client, that would transform or filter content. Examples of proposed OPES services include assembling personalized web pages, adding user-specific regional information to web pages, virus scanning, content adaptation for clients with limited bandwidth, language translation, and the like [OPES].
開き、プラグイン可能なエッジサービス（OPES）は、変換やフィルタの内容でしょうオリジンサーバとクライアントの間のウェブプロキシキャッシュ、で、例えば、ネットワークに展開されるだろうサービスです。提案OPESサービスの例としては、パーソナライズされたWebページを組み立てるWebページにユーザー固有の地域情報を追加して、ウイルススキャン、限られた帯域幅、言語翻訳、および[OPES]などとのクライアントのためのコンテンツ適応含まれています。
The question of chartering OPES in the IETF ([OPESBOF1], [OPESBOF2], [OPESBOF3]) and the related controversy in the IETF community ([Carr01], [CDT01], [Morris01], [Orman01], [Routson01]) have raised to the fore several architectural and policy issues about robustness and the end-to-end integrity of data (in terms of the disparities between what the "origin server" makes available and what the client receives). In particular, questions have been raised about the possible requirements, for a protocol to be developed and standardized in the IETF, for that protocol to protect the end-to-end privacy and integrity of data. This document attempts to address some of the architectural and policy issues that have been unresolved in the chartering of OPES, and to come to some common recommendations from the IAB regarding these issues.
IETFでOPESをチャーターの質問（[OPESBOF1]、[OPESBOF2]、[OPESBOF3]）とIETFコミュニティの関連論争（[Carr01]、[CDT01]、[Morris01]、[Orman01]、[Routson01]） （「オリジンサーバが」利用可能になり、クライアントが受け取るものを何間格差の面で）前面に堅牢性とデータのエンドツーエンドの整合性について、いくつかの建築や政策課題を提起しています。プロトコルは、エンドツーエンドのプライバシーとデータの整合性を保護するために、そのプロトコルのために、IETFで開発され、標準化されるために特に質問は、可能な要件について提起されています。この文書は、OPESのチャーターで未解決となっている建築や政策課題のいくつかに対処しようとし、これらの問題について、IABからのいくつかの一般的な勧告に来て。
The purpose of this document is not to recommend specific solutions for OPES, or even to mandate specific functional requirements. This is also not a recommendation to the IESG about whether or not OPES should be chartered. Instead, these are recommendations on issues that any OPES solutions standardized in the IETF should be required to address, similar to the "Security Considerations" currently required in IETF documents [RFC2316]. As an example, one way to address security issues is to show that appropriate security mechanisms have been provided in the protocol, and another way to address security issues is to demonstrate that no security issues apply to this particular protocol. (Note however that a blanket sentence that "no security issues are involved" is never considered sufficient to address security concerns in a protocol with known security issues.)
このドキュメントの目的は、OPESのための具体的なソリューションをお勧めする、あるいは特定の機能要件を強制することはありません。また、これはOPESをチャーターする必要があるかどうかについてIESGへの勧告ではありません。その代わり、これらは現在、IETFドキュメント[RFC2316]で必要な「セキュリティの考慮事項」に似たIETFで標準化あらゆるOPESソリューションが対処する必要がなければならない問題についての勧告は、あります。一例として、セキュリティの問題に対処する一つの方法は、適切なセキュリティメカニズムがプロトコルで提供されていることを示すためであり、セキュリティの問題に対処する別の方法には、セキュリティの問題は、この特定のプロトコルには適用されないことを実証することです。 （「なしセキュリティ上の問題が関与されていない」ことを毛布文は、既知のセキュリティ問題とプロトコルのセキュリティ上の懸念に対処するために十分であると考えれないことに注意してください。）
This document will try to make our concerns underlying integrity, privacy, and security as clear as possible. We recommend that the IESG require that OPES documents address integrity, privacy, and security concerns in one way or another, either directly by demonstrating appropriate mechanisms, or by making a convincing case that there are no integrity or privacy concerns relevant to a particular document.
この文書では、完全性、プライバシー、そして可能な限り明確なセキュリティの基礎となる私たちの懸念を作るしようとします。私たちは、IESGがOPES文書が直接、適切なメカニズムを実証することにより、または特定の文書に関連する一切の完全性やプライバシーの問題がないことを説得力のあるケースを作るのいずれかによって、一つの方法または別の完全性、プライバシー、セキュリティ上の懸念に対処することを必要とすることをお勧めします。
In particular, it seems unavoidable that at some point in the future some OPES service will perform inappropriately (e.g., a virus scanner rejecting content that does not include a virus), and some OPES intermediary will be compromised either inadvertently or with malicious intent. Given this, it seems necessary for the overall architecture to help protect end-to-end data integrity by addressing, from the beginning of the design process, the requirement of helping end hosts to detect and respond to inappropriate behavior by OPES intermediaries.
特に、それは将来のある時点で、いくつかのOPESサービスが不適切に実行することは避けられないと思われる（例えば、ウイルスが含まれていないコンテンツを拒絶ウイルススキャナ）、およびいくつかのOPES仲介のいずれか不注意または悪意で妥協されるであろう。この考えれば、OPESの仲介により検出し、不適切な行動に対応するために、エンドホストを支援する要件、設計プロセスの最初から、取り組むことにより、エンドツーエンドのデータの整合性を保護するための全体的なアーキテクチャのために必要であると考えられます。
One of the goals of the OPES architecture must be to maintain the robustness long cited as one of the overriding goals of the Internet architecture [Clark88]. Given this, we recommend that the IESG require that the OPES architecture protect end-to-end data integrity by supporting end-host detection and response to inappropriate behavior by OPES intermediaries. We note that in this case by "supporting end-host detection", we are referring to supporting detection by the humans responsible for the end hosts at the content provider and client. We would note that many of these concerns about the ability of end hosts to detect and respond to the inappropriate behavior of intermediaries could be applied to the architectures for web caches and content distribution infrastructures even without the additional complication of OPES.
OPESアーキテクチャの目標の一つは、長いインターネットアーキテクチャ[Clark88]の最優先目標の一つとして挙げられる堅牢性を維持するためでなければなりません。このことを考えると、私たちは、IESGがOPESアーキテクチャはOPESの仲介により、不適切な行動にエンドホストの検出と応答をサポートすることで、エンドツーエンドのデータの整合性を保護することを要求することをお勧めします。私たちは、「サポートするエンドホストの検出」により、このケースでは、我々はコンテンツプロバイダとクライアントのエンドホストを担当する人間による検出をサポートすることに言及していることに注意してください。私たちは、仲介の不適切な行動を検出し、対応するエンドホストの能力について、これらの懸念の多くもOPESの追加複雑化することなく、Webキャッシュとコンテンツ配信インフラのためのアーキテクチャに適用できることに注意します。
Each section of the document contains a set of IAB Considerations that we would recommend be addressed by the OPES architecture. Section 6 summarizes by listing all of these considerations in one place.
文書の各セクションでは、我々がOPESアーキテクチャによって対処することをお勧めIABの考慮事項のセットが含まれています。第6節は、一つの場所にこれらの考慮事項のすべてを一覧表示することでまとめています。
In this document we try to use terminology consistent with RFC 3040 [RFC 3040] and with OPES works in progress.
この文書では、RFC 3040 [RFC 3040]とし、OPESが進行中の作品と一致した用語を使用するようにしてください。
One view on OPES has been that "OPES is deeply evil and the IETF should stay far, far away from this hideous abomination" [ODell01]. Others have suggested that "OPES would reduce both the integrity, and the perception of integrity, of communications over the Internet, and would significantly increase uncertainly about what might have been done to content as it moved through the network", and that therefore the risks of OPES outweigh the benefits [CDT01]. This view of the risks of OPES was revised in later email, based on the proposals from [Carr01], "assuming that certain privacy and integrity protections can be incorporated into the goals of the working group" [Morris01].
OPES上の一つのビューには、「OPESが深く悪であるとIETFは遠く、この恐ろしい醜態から、はるかにとどまるべき」[ODell01]ということでした。その他は、「OPESは、インターネット上での通信のため、整合性、および完全性の認識の両方を低減するであろう、そしてそれは、ネットワークを介して移動して有意にコンテンツに行われている可能性があるかについての不確実性を増加させる」、したがって、リスクということを示唆していますOPESのメリット[CDT01]を上回ります。 OPESのリスクのこのビューは、[Morris01]「特定のプライバシーと整合性の保護は、ワーキンググループの目標に組み込むことができると仮定して、」、[Carr01]からの提案に基づいて、後から電子メールで改訂されました。
One issue concerns the one-party consent model. In the one-party consent model, one of the end-nodes (that is, either the content provider or the end user) is required to explicitly authorize the OPES service, but authorization is not required from both parties. [CDT01] comments that relying only on a one-party consent model in the OPES charter "could facilitate third-party or state-sponsored censorship of Internet content without the knowledge or consent of end users", among other undesirable scenarios.
1つの問題は、一党の同意モデルに関するものです。一党の同意モデル、エンドノードの一つで（つまり、コンテンツプロバイダまたはエンドユーザーのいずれかである）を明示的OPESサービスを認可するために必要とされますが、承認は、両当事者から必要とされていません。 [CDT01] OPESチャーターにおける一党の同意モデルにのみ依存する他の望ましくないシナリオの中で、「知識やエンドユーザーの同意なしにサードパーティまたはインターネットコンテンツの状態主催の検閲を容易にすることができる」とコメントしています。
A natural first question is whether there is any architectural benefit to putting specific services inside the network (e.g., at the application-level web cache) instead of positioning all services either at the content provider or the end user. (Note that we are asking here whether there is architectural benefit, which is not the same as asking if there is a business model.) Client-centric services suggested for OPES include virus scanning, language translation, limited client bandwidth adaptation, request filtering, and adaptation of streaming media, and suggested server-centric services include location-based services and personalized web pages.
天然の最初の質問は、いずれかのコンテンツプロバイダまたはエンド・ユーザーにすべてのサービスを（アプリケーションレベルのWebキャッシュに、例えば）ネットワーク内の特定のサービスを置く代わりの位置決めに任意のアーキテクチャの利益があるかどうかです。 （私たちはビジネスモデルが存在するかどうかを尋ねるのと同じではない建築利益があるかどうか、ここで求めていることに注意してください。）クライアント中心のサービスがOPESのために提案ウイルススキャン、言語翻訳、制限されたクライアントの帯域幅の適応、要求のフィルタリングを含み、ストリーミングメディアの適応、およびサーバー中心のサービスを提案し、ロケーションベースのサービスおよびパーソナライズWebページが含まれます。
It seems clear that there can indeed be significant architectural benefit in providing some OPES services inside the network at the application-level OPES intermediary. For example, if some content is already available from a local or regional web cache, and the end user requires some transformation (such as adaptation to a limited-bandwidth path) applied to that data, providing that service at the web cache itself can prevent the wasted bandwidth of having to retrieve more data from the content provider, and at the same time avoid unnecessary delays in providing the service to the end user.
確かに、アプリケーションレベルOPESの仲介で、ネットワーク内のいくつかのOPESサービスを提供する上で重要な建築利益があることが明らかと思われます。例えば、いくつかのコンテンツはローカル又は地域のウェブキャッシュから既に入手可能であり、エンドユーザが（例えば、限定された帯域幅パスへの適応など）いくつかの変換を必要とする場合は、それ自体が防止できるWebキャッシュにそのサービスを提供し、そのデータに適用されますコンテンツプロバイダからより多くのデータを取得すると同時に、エンドユーザーにサービスを提供する上で、不必要な遅延を回避することの帯域幅の浪費。
A second question is whether the architectural benefits of providing services in the middle of the network outweigh the architectural costs, such as the potential costs concerning data integrity. This is similar to the issues considered in RFC 3135 [RFC 3135] of the relative costs and benefits of placing performance-enhancing proxies (PEPs) in the middle of a network to address link-related degradations. In the case of PEPs, the potential costs include disabling the end-to-end use of IP layer security mechanisms; introducing a new possible point of failure that is not under the control of the end systems; adding increased difficulty in diagnosing and dealing with failures; and introducing possible complications with asymmetric routing or mobile hosts. RFC 3135 carefully considers these possible costs, the mitigations that can be introduced, and the cases when the benefits of performance-enhancing proxies to the user are likely to outweigh the costs. A similar approach could be applied to OPES services (though we do not attempt that here).
2番目の質問は、ネットワークの途中でサービスを提供するアーキテクチャの利点は、このようなデータの整合性に関する潜在的なコストとしての建築費を、上回るかどうかです。これは、リンク関連の劣化に対処するために、ネットワークの途中でパフォーマンス強化プロキシ（のPEP）を置くの相対的な費用と便益の[RFC 3135] RFC 3135で考慮問題と類似しています。 PEPの場合には、潜在的なコスト含むIP層セキュリティメカニズムのエンドツーエンドの使用を無効にします。エンドシステムの制御下にない故障の新たな可能点を導入します。診断および障害に対処で増加した困難を加えます。非対称ルーティングまたはモバイルホストとの可能な合併症を導入します。 RFC 3135には、慎重にこれらの可能性、コスト、導入することができる緩和策、およびユーザーへのパフォーマンス強化プロキシの利益がコストを上回る可能性がある場合を考慮しています。 （我々はここにしようとしないが）同様のアプローチは、OPESサービスにも適用することができます。
A third question is whether an OPES service, designed primarily for a single retrieval action, has an impact on the application layer addressing architecture. This is related to the integrity issue above, but is independent of whether these services are applied in the middle of the network or at either end.
第三の問題は、主に単一の検索動作のために設計されたOPESサービスは、アーキテクチャに対処するアプリケーション層に影響を与えるかどうかです。これは、上記の整合性の問題に関連しているが、これらのサービスは、ネットワークの途中または最後のいずれかで適用されているかどうかとは無関係です。
Most of this document deals with the specific issue of data integrity with OPES services, including the goal of enabling end hosts to detect and respond to inappropriate behavior from broken or compromised OPES intermediaries.
検出し、壊れたり妥協OPESの仲介から、不適切な行動に対応するために、エンドホストを可能にするという目標を含むOPESサービスとデータの整合性の特定の問題、このドキュメントのお得な情報のほとんどは。
We agree that one-party consent, with one of the end-hosts explicitly authorizing the OPES service, must be a requirement for OPES to be standardized in the IETF.
私たちは、一党の同意は、明示的OPESサービスを許可するエンドホストの一つで、OPESのための要件は、IETFで標準化することでなければならないことに同意するものとします。
However, as we discuss in the next section of this document, we agree with [CDT01] that the one-party consent model by itself (e.g., with one of the end-hosts authorizing the OPES service, and the other end-host perhaps being unaware of the OPES service) is insufficient for protecting data integrity in the network. We also agree with
私たちは、この文書の次のセクションで議論するようしかし、我々は、おそらくOPESサービスを許可するエンドホストの一つであり、他のエンドホストとそれ自体で[CDT01]その一党の同意モデル（例えば、に同意します）OPESサービスを知らないということは、ネットワーク内のデータの整合性を保護するには不十分です。また、に同意します
[CDT01] that, regardless of the security and authorization mechanisms standardized for OPES in the IETF, OPES implementations could probably be modified to circumvent these mechanisms, resulting in the unauthorized modification of content. Many of the protocols in the IETF could be modified for anti-social purposes - transport protocols could be modified to evade end-to-end congestion control, routing protocols could be modified to inject invalid routes, web proxy caches could be used for the unauthorized modification of content even without OPES, and so on. None of these seem like compelling reasons not to standardize transport protocols, routing protocols, web caching protocols, or OPES itself. In our view, it means instead that the infrastructure needs, as much as possible, to be designed to detect and defend itself against compromised implementations, and misuses of protocols need to be addressed directly, each in the appropriate venue.
[CDT01]かかわらず、IETFにOPESのために標準化セキュリティおよび許可メカニズム、OPES実装は、おそらくコンテンツの不正な変更をもたらす、これらの機構を回避するように修正することができる、ということ。 IETFにおけるプロトコルの多くは、反社会的目的のために変更することができる - トランスポートプロトコルは、エンドツーエンドの輻輳制御を回避するように変更することができ、ルーティングプロトコルは無効なルートを注入するように変更することができ、Webプロキシキャッシュが不正に使用することができますでもOPESのない内容の変更、など。これらはいずれも、トランスポートプロトコル、ルーティングプロトコル、Webキャッシングプロトコル、またはOPES自体を標準化していない説得力のある理由のように思えるん。我々の見解では、それは可能な限りインフラのニーズは、検出し、妥協の実装に対して自分自身を守るために設計されたことを代わりにすることを意味し、プロトコルの誤用は、適切な会場でそれぞれ、直接対処する必要があります。
Mechanisms such as digital signatures, which help users to verify for themselves that content has not been altered, are a first step towards the detection of the unauthorized modification of content in the network. However, in the case of OPES, additional protection to ensure the end-to-end integrity of data is desirable as well, for example, to help end-users to detect cases where OPES intermediaries were authorized to modify content, but perform inappropriate modifications. We would note that mechanisms can *help* end-users to detect compromised OPES intermediaries in some cases even if they do not *guarantee* that end-users will be able to detect compromised OPES intermediaries in all cases.
ユーザーは、コンテンツが変更されていないことを自分自身のために確認するのに役立ち、デジタル署名などのメカニズムは、ネットワークにおけるコンテンツの不正変更の検出に向けた最初のステップです。しかしながら、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. Compatibility with end-to-end encryption would also help to prevent the widespread deployment of yet another set of services that, to benefit from, require one to keep one's packet contents in the clear for all to snoop.
OPESがチャーターされている場合は、OPESワーキンググループは、明示的にOPESアーキテクチャはOPES-関与セッションの1つの以上の端部によって、エンドツーエンドの暗号化を使用すると互換性がなければならないかどうかを決定し、文書する必要があります。 OPESは、エンドツーエンドの暗号化に対応していた場合、これは効果的OPESボックスは、知られ信頼されているものに限定されることを保証するであろう、明示的にIP層で対処し、かつ、少なくともによって（復号鍵を提供することによって）認可端部の一つ。エンドツーエンドの暗号化との互換性も、恩恵を受けるために、サービスのさらに別のセットの広範な展開を防止するのに役立つスヌープへのすべてのための明確で1のパケットの内容を維持するために1を必要とします。
IAB Considerations:
IABの考慮事項：
(2.1) One-party consent: 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).
（2.1）一党の同意：IETFで標準化さOPESフレームワークは、任意のOPESサービスの利用が明示的に（つまり、コンテンツプロバイダまたはクライアントのいずれかである）アプリケーション層のエンドホストのいずれかによって承認されることを要求しなければなりません。
(2.2) IP-layer communications: For an OPES framework standardized in the IETF, the OPES intermediary must be explicitly addressed at the IP layer by the end user.
（2.2）IPレイヤ通信は：IETFで標準化OPESフレームワークの、OPES仲介は、明示的にエンドユーザによってIPレイヤで対処しなければなりません。
We note that (2.2) is not intended to preclude a chain of intermediaries, with the first intermediary in the chain explicitly addressed at the IP layer by the end user.
我々は、（2.2）は、明示的にエンドユーザによってIPレイヤでアドレスさチェーン内の最初の中間で、仲介者のチェーンを排除することを意図していないことに注意してください。
The proposed OPES services have several possible forms, including server-centric services, such as the dynamic assembling of web pages, explicitly authorized by the content provider; client-centric services such as virus scanning or language translation explicitly authorized by the end user to act on the response from the content provider; and client-centric services such as privacy-based services or content-filtering explicitly authorized by the end user to act on the request from the end user to the content provider. We consider the issue of the end-to-end integrity of data separately for these different classes of services.
提案OPESサービスは、明示的にコンテンツプロバイダによって認可Webページの動的な組み立てなどのサーバー中心のサービス、など、いくつかの可能な形態を持っています。そのようなウイルススキャンまたは明示的にコンテンツプロバイダからの応答に基づいて行動するために、エンドユーザーが許可した言語の翻訳など、クライアント中心のサービス。このよう明示的にコンテンツプロバイダへのエンドユーザからの要求に基づいて行動するために、エンドユーザによって許可プライバシベースのサービスやコンテンツフィルタリングなど、クライアント中心のサービス。当社は、サービスのこれらの異なるクラスごとに個別のデータのエンドツーエンドの整合性の問題を検討します。
For each specific service, the question arises of whether it is necessary for both the content provider and the end user to be able to detect and respond to inappropriate behavior by OPES intermediaries, or if it is sufficient for just one of the two end-hosts to have this ability. We don't attempt a general answer, but we do discuss the issues further in the sections below.
各特定のサービスのために、質問は、コンテンツプロバイダとエンドユーザの両方が、それは単に1つの2つのエンドホストのために十分である場合は、検出しOPES仲介によって、不適切な振る舞いに応答できるようにすることが必要であるかどうかに生じこの能力を持っています。私たちは、一般的な答えをしようとしないが、我々は以下のセクションでさらに問題を議論します。
Why is there any concern about the end-to-end integrity of data in a client-centric OPES service acting on a response from a content provider? If the client requests a service such as virus scanning or language translation, why is that of any concern to the content provider one way or another? One answer is that one of the proper concerns of the IETF is to design architectures that enable end-hosts to detect and respond to inappropriate actions in the network. This seems of particular importance for powerful devices in the network such as OPES intermediaries, which are authorized by one of the end-nodes to act on or transform data in the network, but other than that are not under the direct control of that end-node.
なぜ、コンテンツプロバイダからの応答に作用するクライアント中心OPESサービスにおけるデータのエンドツーエンドの整合性についての懸念がありますか？クライアントは、このようなウイルススキャンや言語翻訳などのサービスを要求する場合、なぜコンテンツプロバイダへの懸念一つの方法または別のものはありますか？一つの答えは、IETFの適切な関心事の一つは検出して、ネットワーク内の不適切な行為に対応するためのエンドホストを有効にするアーキテクチャを設計することであるということです。これは、そのように作用するか、ネットワーク内でデータを変換するために、エンド・ノードのいずれかによって許可されているOPES仲介などのネットワークで強力なデバイスにとって特に重要と思われるが、それ以外は、そのエンドの直接の管理下にはありませんノード。
Consider as an example the services of virus scanning or language translation. The end user has reasonable power in detecting and dealing with imperfect or corrupted virus scanners or language translators that are under her direct control (e.g., on her own machine). The end user knows exactly what program is installed, and has direct access to the content before and after the service is applied. The end user would have less control over similar services offered by OPES in the network itself, where the end user's only control might be the binary one of authorizing or not authorizing the service. (We also note that services deployed on the end host in a self-contained fashion, such as a local virus scanning program, are not a service in the network, and therefore are not in the province of the IETF one way or another.)
一例として、ウイルススキャンや言語翻訳のサービスを考えてみましょう。エンドユーザーは、検出し（例えば、自分のマシン上で）彼女の直接の管理下にある不完全または破損したウイルススキャナや言語の翻訳者に対処する上で、合理的な力を持っています。エンドユーザーは、プログラムがインストールされている正確に何を知っており、サービスが適用される前と後のコンテンツに直接アクセスできます。エンドユーザーは、エンドユーザーの制御のみが許可またはサービスを許可しないバイナリ1であるかもしれないネットワーク自体にOPESが提供する同様のサービスを制御しにくいだろう。 （我々はまた、このようなローカルウイルススキャンプログラムとして自己完結型ファッション、内のエンドホスト上に展開されたサービスは、ネットワーク内のサービスではありませんので、IETF一つの方法または別の州ではないことに注意してください。）
For a OPES service such as virus scanning or language translation, the end user could detect a corrupted intermediary, but only through a "black-box" approach of comparing the input with the output. This is also imprecise and requires some effort, compared to the effort required to detect a corrupted virus scanner installed on one's own machine. For example, the user could retrieve the "non-OPES" version of the content directly from the content provider, if there is a "non-OPES" version, and compare this with the "OPES" version of the content available from the OPES intermediary. However, in the case of dynamic content, the "non-OPES" version of the content retrieved by the user directly from the content provider might not necessarily be the same as the "non-OPES" version of the content considered by the OPES intermediary. This limited control by the end user of the OPES service, and the limited ability of the end user to detect imperfect or corrupted intermediaries, argues for an architecture that helps the content provider to detect and respond to imperfect or corrupted OPES intermediaries as well.
そのようなウイルススキャンまたは言語翻訳などOPESサービスのために、エンドユーザはだけ出力と入力とを比較する「ブラックボックス」アプローチを介して、破損した中間体を検出することができます。また、これは不正確であると、自分のマシンにインストールされ、破損したウイルススキャナを検出するのに必要な労力に比べて、いくつかの努力が必要です。 「非OPES」バージョンがある場合例えば、ユーザは、コンテンツプロバイダから直接コンテンツの「非OPES」バージョンを取得でき、OPESから利用可能なコンテンツの「OPES」バージョンとこれを比較します仲介。しかしながら、動的コンテンツの場合、コンテンツプロバイダから直接ユーザによって検索されたコンテンツの「非OPES」バージョンは、必ずしもOPES仲介によって考慮コンテンツの「非OPES」バージョンと同じではないかもしれません。 OPESサービスのエンドユーザー、および不完全または破損した仲介者を検出するために、エンドユーザーの限られた能力によって、この制限された制御は、検出し、同様に不完全または破損OPESの仲介に対応するコンテンツプロバイダを支援アーキテクチャのために主張しています。
We consider the specific example of virus scanning, authorized by the end user as an OPES service. One could imagine virus scanning as a widely deployed OPES service, augmenting the virus scanning done on the end host itself. If I ask for, say, a paper by Steve Bellovin on security and viruses in the network, and am informed by my authorized OPES virus-scanning service that this content does not pass the virus-scan, there are a number of possibilities:
私たちは、OPESサービスとしてエンドユーザによって許可ウイルススキャンの具体的な例を考えてみましょう。一つは、エンドホスト自体で行わウイルススキャンを増強、広く展開OPESサービスとしてウイルススキャンを想像できます。私は、言う、のために、ネットワーク内のセキュリティやウイルスのスティーブBellovin氏の論文を依頼し、このコンテンツは、ウイルススキャンに合格していないというのが私の許可OPESウイルススキャンサービスによって知らされていた場合は、多くの可能性があります。
(1) Unknown to Steve, the content (that is, Steve's paper) contains a harmful virus.
（1）スティーブに未知の、コンテンツ（つまり、スティーブの紙である）、有害なウイルスが含まれています。
(2) Steve inserted a harmful virus in the content on purpose, with playful or malicious intent.
（2）スティーブは遊び心または悪意で、目的のコンテンツに有害なウイルスを挿入します。
(3) The OPES virus scanner can't distinguish between a true harmful virus, and Steve's paper about harmful viruses.
（3）OPESウイルススキャナは、真の有害なウイルス、および有害なウイルスについてスティーブの論文を区別することはできません。
(4) My local OPES virus scanner has been hacked, with malicious intent, to reject all content from Steve Bellovin.
（4）私の地元OPESウイルススキャナは、スティーブBellovin氏からのすべてのコンテンツを拒絶するように、悪意で、ハッキングされています。
At some point, for some content, some widely-deployed implementation of some OPES virus scanner is likely to result in problem (3), and some OPES implementation is likely to be corrupted to result in problem (4). Because the end user has limited control over the OPES virus scanner, the end user also is limited in its ability to detect problems (3) or (4) in the OPES virus scanner. In addition, the content provider is probably the one with the strongest incentive to detect problems (3) or (4) in the OPES virus scanner. (The content provider generally has a strong incentive to detect problem (1) as well.) In this case, it seems prudent that the overall OPES architecture should be carefully designed to prevent the OPES service of virus scanning, as authorized by the client, from unnecessarily preventing the distribution of content that in fact does not have viruses.
ある時点で、いくつかのコンテンツのために、いくつかのOPESウイルススキャナの一部広く展開実装（3）問題をもたらす可能性がある、といくつかのOPESの実装では、（4）問題をもたらすことが破壊される可能性があります。エンドユーザがOPESウイルススキャナ上限られた制御を有するので、エンドユーザはまた、OPESウイルススキャナの問題点（3）または（4）を検出する能力が制限されます。また、コンテンツプロバイダは、おそらく問題を検出するための最も強いインセンティブを有するもの（3）または（4）OPESウイルススキャナです。 （コンテンツプロバイダは、一般的に（1）と同様の問題を検出するための強力なインセンティブを持っています。）この場合、クライアントによって認可として全体的なOPESアーキテクチャは慎重に、ウイルススキャンのOPESサービスを防ぐように設計されるべきであると慎重なようで、不必要に実際にウイルスを持っていないコンテンツの配信を防止することから。
Obviously, it is not viable to propose that content providers simply indicate that some content should be passed to the end user without virus scanning - the point of virus scanning is for the end user to exercise control in this regard. However, if some form of end-system notification allows the content provider to find out that the content is being rejected by a virus scanning service instead of being delivered to the end user, then the content provider (Steve, in this case) might want to inform end users that this content is known by the content provider not to pass some OPES virus scanning services. End users could then make their own decisions about whether or not to retrieve that content bypassing the OPES virus scanning service, relying on their own virus scanner or an alternate virus scanning service for this particular content. Such end-system notification to the content provider, if requested, cannot be enforced, and cannot be relied upon from corrupted intermediaries, but it seems important nevertheless.
もちろん、それはコンテンツプロバイダは、単に一部のコンテンツは、ウイルススキャンせずにエンドユーザーに渡される必要があることを示すことを提案して実行可能ではありません - ウイルススキャンのポイントは、この点で制御を行使するために、エンドユーザーのためです。エンドシステム通知のいくつかのフォームは、コンテンツプロバイダがコンテンツではなく、エンドユーザーに配信されるのでウイルススキャンサービスによって拒否されていることを見つけることを可能にする場合は、その後、コンテンツプロバイダ（この場合はスティーブは、）をお勧めしますこのコンテンツは、コンテンツプロバイダによって知られていることをエンドユーザーに通知するために、いくつかのOPESのウイルススキャンサービスを渡すません。エンドユーザーは、その後、独自のウイルススキャナまたはこの特定のコンテンツの代替ウイルススキャンサービスに頼って、OPESのウイルススキャンサービスをバイパスしているコンテンツを取得するかどうかについては、自分の意思決定を行うことができます。コンテンツプロバイダにそのようなエンドシステム通知は、要求された場合、強制することができず、破損した仲介者から頼りにすることはできませんが、それにもかかわらず、重要と思われます。
Of course, malicious users can also use their awareness of the virus scanning service to perfect their ability to construct malicious viruses that can evade the virus scanning service. This will be done anyway, with any virus scanning service, and seems like an acceptable cost to allow content providers some protection against the vagaries of imperfect or corrupted OPES services in the network.
もちろん、悪意のあるユーザーはまた、ウイルススキャンサービスを回避することができ、悪質なウイルスを構築する能力を完璧にウイルススキャンサービスの意識を使用することができます。これは、任意のウイルススキャンサービスと、とにかく行われ、コンテンツプロバイダに、ネットワーク内の不完全または破損しOPESサービスの気まぐれに対してある程度の保護を可能にするために許容できるコストのように思われます。
Thus, for client-requested services such as virus scanning and language translation, it is clearly desirable for the origin server to have notification, if it requests it, that these services are being performed on its content before the content is sent to the client. Any such end-system notification might be accompanied by reduced performance (in terms of overhead, delays, etc.) for the OPES service applied to that content. But some form of end-system notification is clearly necessary if content providers are to be able to detect and respond to actions by OPES intermediaries that are deemed inappropriate by the content provider.
オリジンサーバが通知を持つことが要求した場合このように、ウィルススキャンや言語翻訳など、クライアントが要求したサービスのために、それはコンテンツがクライアントに送信される前に、これらのサービスは、そのコンテンツに対して実行されていることを、明らかに望ましいです。任意のこのようなエンドシステム通知は、そのコンテンツに適用OPESサービスの（オーバーヘッド、遅延、等の点で）パフォーマンスの低下を伴うかもしれません。コンテンツプロバイダは検出して、コンテンツプロバイダによって不適切と判断されOPESの仲介によってアクションに応答することができるようになっている場合でも、エンドシステム通知のいくつかのフォームは明らかに必要です。
Similarly for a client-based OPES service of language translation, it is clearly desirable for content providers to be able to inform end users when some content is deemed by the content provider to be incompatible with language translation. In this case, the important issue is not to prevent the OPES language translation from being performed on the content, but instead to give the content provider some mechanism to discover the language translation, and to inform the end user (or more precisely, to inform the end user's host computer) if the content provider believes that this language translation is incompatible with this particular content.
同様に言語翻訳のクライアントベースのOPESサービスのため、いくつかのコンテンツが言語翻訳と互換性がないために、コンテンツプロバイダによってみなされたとき、コンテンツプロバイダは、エンドユーザーに通知できるようにするために明らかに望ましいです。この場合、重要な問題は、コンテンツ上で実行されてからOPES言語の翻訳を阻止するために、代わりにコンテンツプロバイダに言語翻訳を発見するためのいくつかのメカニズムを与える、と知らせるために、より正確には、エンドユーザーに通知する（またはしませんエンドユーザーのホストコンピュータ）コンテンツプロバイダは、この言語の翻訳は、この特定のコンテンツとの互換性がないと考えています。
IAB Considerations:
IABの考慮事項：
(3.1) Notification: 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.
（3.1）通知：全体OPESフレームワークは、検出およびコンテンツプロバイダによって不適切と見なされるOPES仲介によるクライアント中心のアクションに応答して、コンテンツプロバイダを支援する必要があります。
What are the concerns, if any, with the end-to-end integrity of data in a server-centric OPES service such as location-based services? For example, CNN could authorize a location-based OPES service, where the OPES intermediary inserts the weather report or news headline of regional interest into the requested web page. The same issue of the detection and response to broken or modified OPES intermediaries occurs with server-centric OPES as with client-centric OPES services. We only consider server-centric services on responses, as we are not aware of any proposals for server-centric OPES services on requests from the client to the content provider.
こうしたロケーションベースのサービスとして、サーバー中心OPESサービスにおけるデータのエンド・ツー・エンドの完全性と、もしあれば、心配は何ですか？例えば、CNNは、OPES仲介が要求されたWebページに天気予報や地域の関心のニュースの見出しを挿入するロケーションベースOPESサービスを、許可することができます。検出と応答壊れたため、または修正OPES仲介の同じ問題は、クライアント中心OPESサービスと同様にサーバー中心OPESで発生します。私たちは、コンテンツプロバイダへのクライアントからの要求にサーバ中心OPESサービスのための任意の提案を認識していないとして、私たちは、回答にサーバー中心のサービスを検討してください。
How are the end-nodes to detect inappropriate actions from OPES services authorized by the content provider? The OPES service is being performed at an OPES intermediary in the network itself, and not under the direct control of the content provider; in particular, the content provider might not have the ability to monitor directly the output of the OPES intermediary. One could argue that the content provider and server-centric OPES intermediary are part of a single distributed application, and can be responsible on their own for detecting and dealing with broken or modified OPES intermediaries, without involving the end user. But this is unconvincing, basically arguing that standardizing protocols for performing OPES services is a network issue properly in the domain of the IETF, but the ensuring the overall integrity of the service is a distributed application matter, and not in the province of the IETF at all. It would seem to us that you can't have it both ways. Simply labeling the content provider and the OPES intermediary as part of the same distributed application does not give the content provider the ability to monitor the actions of the OPES intermediary.
どのようにコンテンツプロバイダによって認可OPESサービスから不適切な行為を検出するためのエンドノードがありますか？ OPESサービスは、ネットワーク自体ではなく、コンテンツ提供者の直接の制御下にOPES仲介で行われています。具体的には、コンテンツプロバイダは、直接OPES仲介の出力を監視する能力を持っていない可能性があります。一つは、コンテンツプロバイダとサーバ中心OPES仲介が単一の分散アプリケーションの一部であると主張することができ、およびエンドユーザーを介さず、検出し、破損または変更さOPES仲介に対処するため、独自に責任を負うことができます。しかし、これは、IETFの州では、基本的OPESサービスを実行するためのプロトコルを標準化することはIETFのドメインに適切にネットワークの問題であると主張し、説得力に欠けるが、サービスの全体的な整合性を確保することは、分散アプリケーションの問題であり、そしてありませんすべて。あなたがそれを両方の方法を持っていないことを私たちに思われます。単純にコンテンツプロバイダとコンテンツプロバイダにOPES仲介の行動を監視する能力を与えるものではありません同じ分散アプリケーションの一部としてOPES仲介を標識します。
However, if the end user receives some form of notification that these OPES services have been provided, and has some mechanism for receiving the "non-OPES" content from the content provider without the OPES intermediary's modifications (if there is such a thing as a non-OPES version of the content), then the end user is in a better position to detect and react to inappropriate actions from compromised or poorly-designed OPES intermediaries. Thus, it is clear that some form of end-system notification is required to allow the end user to detect and respond to broken or modified OPES intermediaries. If the end user has notification of action by OPES intermediaries, it could "veto" an OPES service simply by throwing the OPES-modified content away. And if the client wants to talk directly to the origin server to receive the "non-OPES" version, and the origin server is configured to allow this, then the OPES intermediary must be designed to permit this end-to-end communication.
ただし、エンドユーザーは、これらのOPESサービスが提供されている通知のいくつかのフォームを受信して、のようなものがあれば（OPES仲介の変更なしで、コンテンツプロバイダから「非OPES」コンテンツを受信するためのいくつかのメカニズムを持っている場合非OPESコンテンツのバージョン）は、次いで、エンドユーザは、検出および妥協又は難設計OPES仲介から不適切なアクションに反応するよりよい位置にあります。したがって、エンドシステム通知のいくつかのフォームは、エンドユーザが検出および破壊または改変OPES仲介に応答できるようにするために必要であることは明らかです。エンドユーザーがOPESの仲介によるアクションの通知を持っている場合、それは単にOPES-変更されたコンテンツを捨てることにより、「拒否権」OPESサービスでした。クライアントは、「非OPES」バージョンを受け取るためにオリジンサーバに直接話をしたい、とオリジンサーバはこれを許可するように設定されている場合と、その後、OPES仲介は、このエンドツーエンドの通信を可能にするように設計されなければなりません。
In addition to concerns about detecting and responding to faulty or compromised OPES intermediaries, there are purely policy-based concerns about the integrity of data. If the content provider looks at the source IP address from the HTTP request, or tosses a coin, in order to decide what content to provide, then that is the content provider's business. But if there exists a "non-OPES" version of some content available from the content provider, and also modified versions available from OPES intermediaries, then it is important that end users would be able to discover that they are receiving a modified version from the network, and not the "non-OPES" version that is also available from the content provider directly.
検出し、故障したり妥協OPES仲介への対応についての懸念に加えて、データの整合性について、純粋にポリシーベースの懸念があります。コンテンツプロバイダは、HTTPリクエストから元のIPアドレスを見て、または提供するために、どのようなコンテンツを決定するために、コインを投げる場合、そのコンテンツプロバイダのビジネスです。 「非OPES」コンテンツプロバイダから入手できるいくつかのコンテンツのバージョン、およびOPESの仲介から利用も改変されたバージョンが存在する場合でも、エンドユーザーがどこから変更されたバージョンを受けていることを発見することができるだろうということが重要ですまた、直接コンテンツプロバイダから提供されたネットワーク、およびない「非OPES」バージョン。
IAB Considerations:
IABの考慮事項：
(3.2) Notification: The overall OPES framework should assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries.
（3.2）通知：全体OPESフレームワークは、潜在的にそれらが不完全または損なわ仲介者を識別できるように、OPES仲介の挙動を検出することで、エンドユーザーを支援すべきです。
(3.3) Non-blocking: 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.
（3.3）非ブロッキング：コンテンツプロバイダから利用可能なコンテンツの「非OPES」バージョンが存在する場合は、OPESアーキテクチャは、コンテンツプロバイダから、この「非OPES」バージョンを取得からユーザーを妨げてはなりません。
There have also been proposals for OPES services authorized by the client on requests from the client to the content provider. Examples include services that remove fields from the HTTP header for added privacy, and content-filtering services that filter requests based on the requested URL. For such services, there is still a need for end hosts to be assisted in detecting and responding to imperfect or corrupted intermediaries, but it seems less clear to what extent this applies to the content provider, and to what extent it applies to the end user that authorized the service. The requirements will probably have to be determined by the OPES and wider IETF communities on a case-by-case basis for each specific service.
また、コンテンツプロバイダへのクライアントからの要求でクライアントによって認可OPESサービスのための提案がなされています。例としては、フィルタ要求は、要求されたURLに基づいて、追加のプライバシーのためのHTTPヘッダーからフィールドを削除するサービス、およびコンテンツフィルタリングサービスを含みます。このようなサービスのために、検出および不完全または破損仲介への対応を支援するためのエンドホストが依然として必要とされているが、それは、これは、コンテンツプロバイダに適用され、どの程度の少ないクリアなようで、どの程度それがエンドユーザーに適用しますそれは、サービスを承認しました。要件は、おそらく、各特定のサービスのためにケースバイケースでOPES、より広いIETF共同で決定する必要があります。
Most application layer addressing revolves around URIs, which, for the most part, give a structured method to refer to a single data entity on a remote server. URIs are universal in that, in principle, the same result is obtained irrespective of the location of the client performing the resolution.
ほとんどの部分は、リモートサーバー上の単一のデータ・エンティティを参照するために構造化された方法を与える、URIを中心に展開を扱うほとんどのアプリケーション層、。 URIは、原理的には、同じ結果が解像度を行うクライアントの場所にかかわらず得られる、という点で普遍的です。
Practice often differs from this theory -- ad-strippers remove data from pages at the client end; web server farms redirect clients to one of several potential target machines for load-balancing or to give the user "localized" content.
練習は、多くの場合、この理論とは異なり - 広告ストリッパーは、クライアント側でのページからデータを削除します。 Webサーバファームは、負荷分散のためのいくつかの潜在的なターゲットマシンのいずれか、またはユーザー「ローカライズされた」コンテンツを与えるためにクライアントをリダイレクトします。
However, from an architectural standpoint, it is important to be clear about what is being done here. In all cases, URI resolution standards (as defined for individual URI schemes, such as HTTP) apply unchanged between the client and the OPES intermediary. What the intermediary does to fulfill the request is not material to the discussion, and must produce a result that is compliant with the applicable URI scheme definition. In this sense, the OPES intermediary is the "endpoint" of URI resolution.
しかし、建築の観点から、ここで行われているかについて明確にすることが重要です。すべての場合において、（HTTPなど、個々のURIスキーム用に定義された）URI解決基準は、クライアントとOPES仲介の間変わらず適用されます。何仲介が要求を満たすために行うことは議論の材料ではなく、該当するURIスキームの定義に準拠した結果を生成しなければなりません。この意味で、OPES仲介は、URI解決の「エンドポイント」です。
In client-centric OPES, the intermediary is resolving the URI on behalf of the client, and then applying client-requested services to provide a data response to the client. The client gets the data it wanted, but it did not carry out the URI resolution.
クライアント中心OPESでは、仲介者は、クライアントの代わりにURIを解決し、クライアントへのデータ応答を提供するために、クライアントが要求したサービスを適用しています。クライアントは、それが望んでいたデータを取得しますが、それはURI解決を行っていませんでした。
In server-centric OPES, the "origin server" cedes its authority to the intermediary to determine what is the "appropriate" content to supply for a given URI. The client may well perform standard URI resolution, but that reaches no further than the intermediary.
サーバー中心OPESでは、「オリジンサーバは、」与えられたURIのために供給するために「適切な」内容が何であるかを決定するために、仲介にその権限をcedes。クライアントはよく標準のURIの解決を行うことができるが、それは仲介よりもさらに到達しません。
With those distinctions firmly in mind, there are two particular areas of concern for OPES-like services.
しっかりと念頭に置いたものの区別では、OPESのようなサービスのための関心の2つの特定の領域があります。
The first is the consideration of the effect of a series of interactions, over time and location (i.e., not just one document retrieval). Potential problems include inconsistencies in intra-and inter-document references -- depending on what content is changed, references from one version of a document might not exist in a modified target, etc.
最初は、時間と場所（すなわち、だけではなく1件の文書検索）上の相互作用の一連の効果を考慮しています。潜在的な問題がイントラと文書間の参照で矛盾を含んで - コンテンツが変更されたものに応じて、文書の1版からの参照が変更され、目標などに存在しない可能性があります
The other concern is whether this leads to the creation of content that is exclusively accessible through the use of an intermediary. That is, there is no "non-OPES" version. Either this should not be allowed, or this would argue for an extension to the Internet application layer addressing architecture.
他の懸念は、これが仲介を使用して排他的にアクセス可能なコンテンツの創出につながるかどうかです。つまり、何も「非OPES」バージョンはありません。どちらのこれは許されるべきではない、またはこれは、アーキテクチャに取り組むインターネットアプリケーション層への拡張のために主張するだろう。
IAB Considerations:
IABの考慮事項：
(4.1) URI resolution: OPES documentation must be clear in describing these services as being applied to the result of URI resolution, not as URI resolution itself.
（4.1）URI解像度：OPESのドキュメントではなく、URI解決自体としてURI解決の結果に適用されるように、これらのサービスを説明する際に明確でなければなりません。
(4.2) Reference validity: All proposed services must define their impact on inter- and intra-document reference validity.
（4.2）参照妥当性：すべての提案サービスは間および文書内の参照有効性に及ぼす影響を定義する必要があります。
(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.
上記の2点を尊重しながら達成することはできません（4.3）任意のサービスは、アーキテクチャの拡張を扱うインターネットアプリケーションのための潜在的な要件として検討することができるが、アドホックの修正として行われてはなりません。
Intermediaries in the middle of the network increase the number of locations where the privacy of an end-to-end transaction could be compromised. Some of these privacy concerns apply to web caches and CDNs in general as well as specifically to OPES intermediaries. It seems a reasonable requirement, for OPES to be chartered in the IETF, that the issue of providing mechanisms for end users to determine the privacy policies of OPES intermediaries should be addressed. These mechanisms could be quite different for client-centric and server-centric OPES services.
ネットワークの途中で仲介は、エンド・ツー・エンドのトランザクションのプライバシーが損なわれる可能性が場所の数を増やします。これらのプライバシーの問題のいくつかは、一般的にWebキャッシュとのCDNにだけでなく、具体的OPES仲介に適用されます。 OPESは、IETFにチャーターされることがOPES仲介のプライバシーポリシーを決定するために、エンドユーザーのためのメカニズムを提供するという問題に対処する必要があることを、合理的な要件と思われます。これらのメカニズムは、クライアント中心とサーバ中心OPESサービスのための全く異なる可能性があります。
For a complex issue such as an OPES architecture, which interacts with protocols from other standards bodies as well as from other IETF working groups, it seems necessary to keep in mind the overall picture while, at the same time, breaking out specific parts of the problem to be standardized in particular working groups. Thus, a requirement that the overall OPES architecture address privacy concerns does not necessarily mean that the mechanisms for this need to be developed in the IETF, or in the OPES working group (if it is chartered).
同時に、特定の部品を壊し、中に他の標準化団体からだけでなく、他のIETFワーキンググループからのプロトコルと相互作用し、そのようなOPESアーキテクチャのような複雑な問題については、念頭に置いて全体像を維持するために必要と思われます問題は、特定の作業グループで標準化されます。このように、（それがチャーターされている場合）、全体的なOPESアーキテクチャアドレスプライバシーの問題は、必ずしもこのようなニーズのためのメカニズムはIETFで開発された、またはOPESワーキンググループでなければという意味ではありません要件。
IAB Considerations:
IABの考慮事項：
(5.1) Privacy: The overall OPES framework must provide for mechanisms for end users to determine the privacy policies of OPES intermediaries.
（5.1）プライバシー：全体的なOPESフレームワークは、OPES仲介のプライバシーポリシーを決定するために、エンドユーザーのためのメカニズムを提供しなければなりません。
(2.1) One-party consent: 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).
（2.1）一党の同意：IETFで標準化さOPESフレームワークは、任意のOPESサービスの利用が明示的に（つまり、コンテンツプロバイダまたはクライアントのいずれかである）アプリケーション層のエンドホストのいずれかによって承認されることを要求しなければなりません。
(2.2) IP-layer communications: For an OPES framework standardized in the IETF, the OPES intermediary must be explicitly addressed at the IP layer by the end user.
（2.2）IPレイヤ通信は：IETFで標準化OPESフレームワークの、OPES仲介は、明示的にエンドユーザによってIPレイヤで対処しなければなりません。
(3.1) Notification: 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.
（3.1）通知：全体OPESフレームワークは、検出およびコンテンツプロバイダによって不適切と見なされるOPES仲介によるクライアント中心のアクションに応答して、コンテンツプロバイダを支援する必要があります。
(3.2) Notification: The overall OPES framework should assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries.
（3.2）通知：全体OPESフレームワークは、潜在的にそれらが不完全または損なわ仲介者を識別できるように、OPES仲介の挙動を検出することで、エンドユーザーを支援すべきです。
(3.3) Non-blocking: 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.
（3.3）非ブロッキング：コンテンツプロバイダから利用可能なコンテンツの「非OPES」バージョンが存在する場合は、OPESアーキテクチャは、コンテンツプロバイダから、この「非OPES」バージョンを取得からユーザーを妨げてはなりません。
(4.1) URI resolution: OPES documentation must be clear in describing these services as being applied to the result of URI resolution, not as URI resolution itself.
（4.1）URI解像度：OPESのドキュメントではなく、URI解決自体としてURI解決の結果に適用されるように、これらのサービスを説明する際に明確でなければなりません。
(4.2) Reference validity: All proposed services must define their impact on inter- and intra-document reference validity.
（4.2）参照妥当性：すべての提案サービスは間および文書内の参照有効性に及ぼす影響を定義する必要があります。
(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.
上記の2点を尊重しながら達成することはできません（4.3）任意のサービスは、アーキテクチャの拡張を扱うインターネットアプリケーションのための潜在的な要件として検討することができるが、アドホックの修正として行われてはなりません。
(5.1) Privacy: The overall OPES framework must provide for mechanisms for end users to determine the privacy policies of OPES intermediaries.
（5.1）プライバシー：全体的なOPESフレームワークは、OPES仲介のプライバシーポリシーを決定するために、エンドユーザーのためのメカニズムを提供しなければなりません。
This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of OPES in the IETF.
このドキュメントは、IETFにおけるOPESのチャーターに関連するいくつかの建築や政策問題に関するIABのコメントや提言が含まれています。
This document has benefited from discussions with members of the IAB and the IESG, contributors to OPES, John Wroclawski, and others. However, this is a document of the IAB, and we do not claim that the other people listed above agree with the contents.
このドキュメントは、IABとIESGのメンバーと話し合い、OPES、ジョンWroclawski、そして他の人への貢献の恩恵を受けています。しかし、これはIABのドキュメントであり、我々は、上記の他の人々が内容に同意することを主張しません。
[Carr01] Wayne Carr, "Suggested OPES Requirements for Integrity, Privacy and Security", email to ietf-openproxy@imc.org, August 16, 2001. URL "http://www.imc.org/ietf-openproxy/mail-archive/msg00869.html".
[Carr01]ウェイン・カー、「整合性、プライバシーとセキュリティのためOPES要件を推奨」、ietf-openproxy@imc.orgする電子メール、8月16日、2001年URL「http://www.imc.org/ietf-openproxy/mail -archive / msg00869.html」。
[CDT01] Policy Concerns Raised by Proposed OPES Working Group Efforts, email to the IESG, from the Center for Democracy & Technology, August 3, 2001. URL "http://www.imc.org/ietf-openproxy/mail-archive/msg00828.html".
[CDT01]民主主義と技術のためのセンターからの政策提案OPESワーキンググループの取り組みにより懸念、IESGへの電子メール、8月3日、2001年URL「http://www.imc.org/ietf-openproxy/mail-archive /msg00828.html」。
[Clark88] David D. Clark, The Design Philosophy of the DARPA Internet Protocols, SIGCOMM 1988.
[Clark88]デビッド・D.クラーク、DARPAインターネットプロトコルの設計理念、SIGCOMM 1988。
[Morris01] John Morris, "Re: corrected - Suggested OPES Requirements for Integrity, Privacy and Security", September 28, 2001. Email to ietf-openproxy@imc.org, URL "http://www.imc.org/ietf-openproxy/mail-archive/msg00935.html".
[Morris01]ジョン・モリス、「再：修正 - 完全性、プライバシーとセキュリティのためOPES要件を推奨」、9月28日、2001年ietf-openproxy@imc.orgをメールで送信、URL「http://www.imc.org/ietf -openproxy /メールアーカイブ/ msg00935.html」。
[ODell01] Mike O'Dell, "OPES continuing froth...", Message-Id: <200107101341.JAA30276@ccr.org>, July 10, 2001, email to ietf@ietf.org. URL "http://www1.ietf.org/mail-archive/ietf/Current/msg12650.html".
[ODell01]マイク・オデル、 "OPES継続泡..."、メッセージ-ID：<200107101341.JAA30276@ccr.org>、2001年7月10日、電子メールがietf@ietf.orgします。 URL "http://www1.ietf.org/mail-archive/ietf/Current/msg12650.html"。
[OPES] Open Pluggable Edge Services (OPES) Web Page, "http://www.ietf-opes.org/".
[OPES] "http://www.ietf-opes.org/"、プラグイン可能なエッジサービス（OPES）Webページを開きます。
[OPESBOF1] OPES BOF, 49th IETF, December 12, 2000. Agenda: "http://www.ietf.org/ietf/00dec/opes-agenda.txt". Minutes: "http://www.ietf.cnri.reston.va.us/ proceedings/00dec/toc.htm#P25_256".
[OPESBOF1] OPES BOF、第49回IETF、12月12日、2000年アジェンダ： "http://www.ietf.org/ietf/00dec/opes-agenda.txt"。分： "http://www.ietf.cnri.reston.va.us/手続/ 00dec / toc.htm＃P25_256"。
[OPESBOF2] OPES BOF, 50th IETF, March 9, 2001. Minutes: "http://www.ietf.org/proceedings/01mar/ietf50-40.htm".
[OPESBOF2] OPES BOF、第50回IETF、3月9日、2001年分： "http://www.ietf.org/proceedings/01mar/ietf50-40.htm"。
[OPESBOF3] OPES BOF, 51st IETF, August 2001. Agenda: "http://www.ietf.org/ietf/01aug/opes.txt". Minutes: "http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM".
[OPESBOF3] OPES BOF、第51回IETF、2001年8月アジェンダ： "http://www.ietf.org/ietf/01aug/opes.txt"。分： "http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM"。
[Orman01] Hilarie Orman, "Data Integrity for Open Pluggable Services", email to ietf-openproxy@imc.org, August 15, 2001. URL "http://www.imc.org/ietf-openproxy/mail-archive/msg00865.html".
[Orman01]ヒラリーオーマン、「オープン・プラグ可能なサービスのためのデータ整合性」、ietf-openproxy@imc.orgする電子メール、8月15日、2001年URL「http://www.imc.org/ietf-openproxy/mail-archive/ msg00865.html」。
[RFC 2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998.
[RFC 2316] Bellovin氏、S.、 "IABセキュリティアーキテクチャワークショップの報告書"、RFC 2316、1998年4月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC 3040] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.
[RFC 3040]クーパー、I.、Melve、I.およびG.トムリンソン、 "インターネットのWebレプリケーションおよびキャッシング分類学"、RFC 3040、2001年1月。
[RFC 3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
[RFC 3135]ボーダー、J.、古城、M.、Griner、J.、モンテネグロ、G.およびZ.シェルビー、 "プロキシのパフォーマンスの向上は、リンク関連の劣化を軽減することを目的"、RFC 3135、2001年6月。
[Routson01] Joyce Routson, IETF's Edge Standards Controversy, July 11, 2001, Stardust CDN Week. URL "http://www.stardust.com/cdnweek/articles/2001/07/09/ opes.htm".
[Routson01]ジョイスRoutson、IETFのエッジ基準論争、2001年7月11日、スターダストCDNウィーク。 URL "http://www.stardust.com/cdnweek/articles/2001/07/09/ opes.htm"。
This document does not propose any new protocols, and therefore does not involve any security considerations in that sense. However, throughout this document there are discussions of the privacy and integrity issues of OPES services and the architectural requirements created by those issues.
このドキュメントは、新しいプロトコルを提案していないので、その意味ではどのようなセキュリティ上の考慮を必要としません。しかし、この文書全体OPESサービスのプライバシーと整合性の問題と、それらの問題によって作成されたアーキテクチャ要件の議論があります。
There are no IANA considerations regarding this document.
この文書に関する一切IANAの考慮事項はありません。
Authors' Addresses
著者のアドレス
Internet Architecture Board EMail: iab@iab.org
インターネットアーキテクチャ委員会メールアドレス：iab@iab.org
Membership at time this document was completed:
このドキュメントが完成した時点で会員：
Harald Alvestrand Ran Atkinson Rob Austein Fred Baker Steve Bellovin Brian Carpenter Jon Crowcroft Leslie Daigle Steve Deering Sally Floyd Geoff Huston John Klensin Henning Schulzrinne
ハラルドAlvestrandはアトキンソンロブAusteinとフレッド・ベイカー、スティーブBellovin氏ブライアン・カーペンタージョンクロウクロフトレスリーDaigle氏スティーブデアリングサリーフロイドジェフ・ヒューストンジョン・クレンシンヘニングSchulzrinneと蘭
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。