Network Working Group A. Barbir
Request for Comments: 3835 R. Penno
Category: Informational Nortel Networks
R. Chen
AT&T Labs
M. Hofmann
Bell Labs/Lucent Technologies
H. Orman
Purple Streak Development
August 2004
Network Working Group A. Barbir
Request for Comments: 3835 R. Penno
Category: Informational Nortel Networks
R. Chen
AT&T Labs
M. Hofmann
Bell Labs/Lucent Technologies
H. Orman
Purple Streak Development
August 2004
An Architecture for Open Pluggable Edge Services (OPES)
开放式可插拔边缘服务（OPES）的体系结构
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This memo defines an architecture that enables the creation of an application service in which a data provider, a data consumer, and zero or more application entities cooperatively implement a data stream service.
此备忘录定义了一种体系结构，该体系结构支持创建应用程序服务，其中数据提供者、数据使用者和零个或多个应用程序实体协作实现数据流服务。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 . The Architecture . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. OPES Entities. . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Data Dispatcher. . . . . . . . . . . . . . . . . 5
2.2. OPES Flows . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. OPES Rules . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Callout Servers. . . . . . . . . . . . . . . . . . . . . 7
2.5. Tracing Facility . . . . . . . . . . . . . . . . . . . . 8
3. Security and Privacy Considerations . . . . . . . . . . . . . 9
3.1. Trust Domains. . . . . . . . . . . . . . . . . . . . . . 9
3.2. Establishing Trust and Service Authorization . . . . . . 11
3.3. Callout Protocol . . . . . . . . . . . . . . . . . . . . 11
3.4. Privacy. . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. End-to-end Integrity . . . . . . . . . . . . . . . . . . 12
4. IAB Architectural and Policy Considerations for OPES . . . . . 12
4.1. IAB consideration (2.1) One-party Consent. . . . . . . . 12
4.2. IAB consideration (2.2) IP-Layer Communications. . . . . 13
4.3. IAB consideration (3.1 and 3.2) Notification . . . . . . 13
4.4. IAB consideration (3.3) Non-Blocking . . . . . . . . . . 13
4.5. IAB consideration (4.1) URI Resolution . . . . . . . . . 13
4.6. IAB consideration (4.2) Reference Validity . . . . . . . 13
4.7. IAB consideration (4.3) Application Addressing
Extensions . . . . . . . . . . . . . . . . . . . . . . . 14
4.8. IAB consideration (5.1) Privacy. . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 . The Architecture . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. OPES Entities. . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Data Dispatcher. . . . . . . . . . . . . . . . . 5
2.2. OPES Flows . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. OPES Rules . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Callout Servers. . . . . . . . . . . . . . . . . . . . . 7
2.5. Tracing Facility . . . . . . . . . . . . . . . . . . . . 8
3. Security and Privacy Considerations . . . . . . . . . . . . . 9
3.1. Trust Domains. . . . . . . . . . . . . . . . . . . . . . 9
3.2. Establishing Trust and Service Authorization . . . . . . 11
3.3. Callout Protocol . . . . . . . . . . . . . . . . . . . . 11
3.4. Privacy. . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. End-to-end Integrity . . . . . . . . . . . . . . . . . . 12
4. IAB Architectural and Policy Considerations for OPES . . . . . 12
4.1. IAB consideration (2.1) One-party Consent. . . . . . . . 12
4.2. IAB consideration (2.2) IP-Layer Communications. . . . . 13
4.3. IAB consideration (3.1 and 3.2) Notification . . . . . . 13
4.4. IAB consideration (3.3) Non-Blocking . . . . . . . . . . 13
4.5. IAB consideration (4.1) URI Resolution . . . . . . . . . 13
4.6. IAB consideration (4.2) Reference Validity . . . . . . . 13
4.7. IAB consideration (4.3) Application Addressing
Extensions . . . . . . . . . . . . . . . . . . . . . . . 14
4.8. IAB consideration (5.1) Privacy. . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
When supplying a data stream service between a provider and a consumer, the need to provision the use of other application entities, in addition to the provider and consumer, may arise. For example, some party may wish to customize a data stream as a service to a consumer. The customization step might be based on the customer's resource availability (e.g., display capabilities).
当在提供者和使用者之间提供数据流服务时，可能需要提供除提供者和使用者之外的其他应用实体的使用。例如，某一方可能希望将数据流定制为消费者的服务。定制步骤可能基于客户的资源可用性（例如，显示能力）。
In some cases it may be beneficial to provide a customization service at a network location between the provider and consumer host rather than at one of these endpoints. For certain services performed on
在某些情况下，在提供者和使用者主机之间的网络位置而不是在这些端点之一提供定制服务可能是有益的。对于在上执行的某些服务
behalf of the end-user, this may be the only option of service deployment. In this case, zero or more additional application entities may participate in the data stream service. There are many possible provisioning scenarios which make a data stream service attractive. The OPES Use Cases and Deployment Scenarios [1] document provides examples of OPES services. The document discusses services that modify requests, services that modify responses, and services that create responses. It is recommended that the document on OPES Use Cases and Deployment Scenarios [1] be read before reading this document.
代表最终用户，这可能是服务部署的唯一选项。在这种情况下，零个或多个附加应用实体可以参与数据流服务。有许多可能的供应场景使数据流服务具有吸引力。OPES用例和部署场景[1]文档提供了OPES服务的示例。本文档讨论修改请求的服务、修改响应的服务以及创建响应的服务。在阅读本文档之前，建议先阅读有关OPES用例和部署场景的文档[1]。
This document presents the architectural components of Open Pluggable Edge Services (OPES) that are needed in order to perform a data stream service. The architecture addresses the IAB considerations described in [2]. These considerations are covered in various parts of the document. Section 2.5 addresses tracing; section 3 addresses security considerations. Section 4 provides a summary of IAB considerations and how the architecture addresses them.
本文档介绍了执行数据流服务所需的开放可插拔边缘服务（OPE）的体系结构组件。该体系结构解决了[2]中描述的IAB注意事项。本文件各部分涵盖了这些考虑因素。第2.5节涉及追踪；第3节涉及安全考虑。第4节总结了IAB注意事项以及架构如何解决这些问题。
The document is organized as follows: Section 2 introduces the OPES architecture. Section 3 discusses OPES security and privacy considerations. Section 4 addresses IAB considerations for OPES. Section 5 discusses security considerations. Section 6 addresses IANA considerations. Section 7 provides a summary of the architecture and the requirements for interoperability.
本文件组织如下：第2节介绍了OPES体系结构。第3节讨论了OPES安全和隐私注意事项。第4节讨论了运营商的IAB考虑事项。第5节讨论了安全注意事项。第6节讨论了IANA的考虑因素。第7节概述了体系结构和互操作性要求。
The architecture of Open Pluggable Edge Services (OPES) can be described in terms of three interrelated concepts, mainly:
开放式可插拔边缘服务（OPE）的体系结构可以用三个相互关联的概念来描述，主要是：
o OPES entities: processes operating in the network;
o OPES实体：在网络中运行的过程；
o OPES flows: data flows that are cooperatively realized by the OPES entities; and,
o OPES流：OPES实体合作实现的数据流；和
o OPES rules: these specify when and how to execute OPES services.
o OPES规则：这些规则指定何时以及如何执行OPES服务。
An OPES entity is an application that operates on a data flow between a data provider application and a data consumer application. OPES entities can be:
OPES实体是在数据提供者应用程序和数据使用者应用程序之间的数据流上运行的应用程序。运营实体可以是：
o an OPES service application, which analyzes and possibly transforms messages exchanged between the data provider application and the data consumer application;
o OPES服务应用程序，其分析并可能转换数据提供者应用程序和数据使用者应用程序之间交换的消息；
o a data dispatcher, which invokes an OPES service application based on an OPES ruleset and application-specific knowledge.
o 数据调度器，它根据OPES规则集和特定于应用程序的知识调用OPES服务应用程序。
The cooperative behavior of OPES entities introduces additional functionality for each data flow provided that it matches the OPES rules. In the network, OPES entities reside inside OPES processors. In the current work, an OPES processor MUST include a data dispatcher. Furthermore, the data provider and data consumer applications are not considered as OPES entities.
OPES实体的协作行为为每个数据流引入了附加功能，前提是它符合OPES规则。在网络中，OPES实体驻留在OPES处理器内。在当前的工作中，OPES处理器必须包括一个数据调度器。此外，数据提供者和数据使用者应用程序不被视为OPES实体。
To provide verifiable system integrity (see section 3.1 on trust domains below) and to facilitate deployment of end-to-end encryption and data integrity control, OPES processors MUST be:
为了提供可验证的系统完整性（请参见下面关于信任域的第3.1节），并促进端到端加密和数据完整性控制的部署，OPES处理器必须：
o explicitly addressable at the IP layer by the end user (data consumer application). This requirement does not preclude a chain of OPES processors with the first one in the chain explicitly addressed at the IP layer by the end user (data consumer application).
o 最终用户（数据使用者应用程序）可在IP层显式寻址。此要求不排除OPES处理器链，其中链中的第一个处理器由最终用户在IP层明确寻址（数据消费者应用程序）。
o consented to by either the data consumer or data provider application. The details of this process are beyond the scope of the current work.
o 由数据使用者或数据提供者应用程序同意。这个过程的细节超出了当前工作的范围。
The OPES architecture is largely independent of the protocol that is used by the data provider application and the data consumer application to exchange data. However, this document selects HTTP [3] as the example for the underlying protocol in OPES flows.
OPES体系结构在很大程度上独立于数据提供者应用程序和数据使用者应用程序用于交换数据的协议。但是，本文选择HTTP[3]作为OPES流中底层协议的示例。
Data dispatchers include a ruleset that can be compiled from several sources and MUST resolve into an unambiguous result. The combined ruleset enables an OPES processor to determine which service applications to invoke for which data flow. Accordingly, the data dispatcher constitutes an enhanced policy enforcement point, where policy rules are evaluated and service-specific data handlers and state information are maintained, as depicted in Figure 1.
数据分派器包括一个规则集，该规则集可以从多个源编译，并且必须解析为明确的结果。组合规则集使OPES处理器能够确定为哪个数据流调用哪个服务应用程序。因此，数据调度器构成了一个增强的策略实施点，在这里评估策略规则并维护特定于服务的数据处理程序和状态信息，如图1所示。
+----------+
| callout |
| server |
+----------+
||
||
||
||
+--------------------------+
| +-----------+ || |
| | OPES | || |
| | service | || |
| |application| || |
| +-----------+ || |
| +----------------------+ |
OPES flow <---->| | data dispatcher and | |<----> OPES flow
| | policy enforcement | |
| +----------------------+ |
| OPES |
| processor |
+--------------------------+
+----------+
| callout |
| server |
+----------+
||
||
||
||
+--------------------------+
| +-----------+ || |
| | OPES | || |
| | service | || |
| |application| || |
| +-----------+ || |
| +----------------------+ |
OPES flow <---->| | data dispatcher and | |<----> OPES flow
| | policy enforcement | |
| +----------------------+ |
| OPES |
| processor |
+--------------------------+
Figure 1: Data Dispatchers
图1：数据调度器
The architecture allows for more than one policy enforcement point to be present on an OPES flow.
该体系结构允许在OPES流上存在多个策略实施点。
An OPES flow is a cooperative undertaking between a data provider application, a data consumer application, zero or more OPES service applications, and one or more data dispatchers.
OPES流是数据提供者应用程序、数据使用者应用程序、零个或多个OPES服务应用程序以及一个或多个数据调度器之间的协作。
Since policies are enforced by data dispatchers, the presence of at least one data dispatcher is required in the OPES flow.
由于策略由数据调度器强制执行，因此OPES流中至少需要一个数据调度器。
data OPES OPES data consumer processor A processor N provider
数据运营商运营商运营商数据消费者处理器处理器处理器供应商
+-----------+ +-----------+ . +-----------+ +-----------+
| data | | OPES | . | OPES | | data |
| consumer | | service | . | service | | provider |
|application| |application| . |application| |application|
+-----------+ +-----------+ . +-----------+ +-----------+
| | | | . | | | |
| HTTP | | HTTP | . | HTTP | | HTTP |
| | | | . | | | |
+-----------+ +-----------+ . +-----------+ +-----------+
| TCP/IP | | TCP/IP | . | TCP/IP | | TCP/IP |
+-----------+ +-----------+ . +-----------+ +-----------+
|| || || . || || ||
================ =====.======== ===========
+-----------+ +-----------+ . +-----------+ +-----------+
| data | | OPES | . | OPES | | data |
| consumer | | service | . | service | | provider |
|application| |application| . |application| |application|
+-----------+ +-----------+ . +-----------+ +-----------+
| | | | . | | | |
| HTTP | | HTTP | . | HTTP | | HTTP |
| | | | . | | | |
+-----------+ +-----------+ . +-----------+ +-----------+
| TCP/IP | | TCP/IP | . | TCP/IP | | TCP/IP |
+-----------+ +-----------+ . +-----------+ +-----------+
|| || || . || || ||
================ =====.======== ===========
| <----------------- OPES flow -------------------> |
| <----------------- OPES flow -------------------> |
Figure 2: An OPES flow
图2:OPES流程
Figure 2 depicts two data dispatchers that are present in the OPES flow. The architecture allows for one or more data dispatchers to be present in any flow.
图2描述了OPES流中存在的两个数据调度器。该体系结构允许在任何流中存在一个或多个数据调度器。
OPES' policy regarding services and the data provided to them is determined by a ruleset consisting of OPES rules. The rules consist of a set of conditions and related actions. The ruleset is the superset of all OPES rules on the processor. The OPES ruleset determines which service applications will operate on a data stream. In this model, all data dispatchers are invoked for all flows.
OPES关于服务和向其提供的数据的政策由OPES规则组成的规则集确定。规则由一组条件和相关操作组成。规则集是处理器上所有OPES规则的超集。OPES规则集确定哪些服务应用程序将在数据流上运行。在该模型中，所有流都调用所有数据调度器。
In order to ensure predictable behavior, the OPES architecture requires the use of a standardized schema for the purpose of defining and interpreting the ruleset. The OPES architecture does not require a mechanism for configuring a ruleset into a data dispatcher. This
为了确保可预测的行为，OPES体系结构需要使用标准化模式来定义和解释规则集。OPES体系结构不需要将规则集配置到数据调度器中的机制。这
is treated as a local matter for each implementation (e.g., through the use of a text editor or a secure upload protocol), as long as such a mechanism complies with the requirements set forth in section 3.
对于每个实现（例如，通过使用文本编辑器或安全上传协议），只要该机制符合第3节中规定的要求，则视为本地事务。
The evaluation of the OPES ruleset determines which service applications will operate on a data stream. How the ruleset is evaluated is not the subject of the architecture, except to note that it MUST result in the same unambiguous result in all implementations.
OPES规则集的评估确定哪些服务应用程序将在数据流上运行。如何评估规则集不是体系结构的主题，但需要注意的是，它必须在所有实现中产生相同的明确结果。
In some cases it may be useful for the OPES processor to distribute the responsibility of service execution by communicating with one or more callout servers. A data dispatcher invokes the services of a callout server by using the OPES callout protocol (OCP). The requirements for the OCP are given in [5]. The OCP is application-agnostic, being unaware of the semantics of the encapsulated application protocol (e.g., HTTP). However, the data dispatcher MUST incorporate a service aware vectoring capability that parses the data flow according to the ruleset and delivers the data to either the local or remote OPES service application.
在某些情况下，OPES处理器可以通过与一个或多个调用服务器通信来分配服务执行的责任。数据调度器通过使用OPES调用协议（OCP）调用调用服务器的服务。[5]中给出了OCP的要求。OCP与应用程序无关，不知道封装的应用程序协议（例如HTTP）的语义。但是，数据调度器必须包含服务感知矢量化功能，该功能根据规则集解析数据流，并将数据交付给本地或远程OPES服务应用程序。
The general interaction situation is depicted in Figure 3, which illustrates the positions and interaction of different components of OPES architecture.
图3描述了一般的交互情况，说明了OPES体系结构不同组件的位置和交互。
+--------------------------+
| +-----------+ |
| | OPES | |
| | service | | +---------------+ +-----------+
| |application| | | Callout | | Callout |
| +-----------+ | | Server A | | Server X |
| || | | +--------+ | | |
| +----------------------+ | | | OPES | | | |
| | data dispatcher | | | | Service| | | +--------+|
| +----------------------+ | | | Appl A | | | | OPES ||
| || || | | +--------+ | | |Service ||
| +---------+ +-------+ | | || | | | Appl X ||
| | HTTP | | | | | +--------+ | ... | +--------||
| | | | OCP |=========| | OCP | | | || |
| +---------+ +-------+ | | +--------+ | | +------+ |
| | | || | +---------------+ | | OCP | |
| | TCP/IP | =======================================| | |
| | | | | +------+ |
| +---------+ | +-----------+
+--------||-||-------------+
|| ||
+--------+ || || +--------+
|data |== =========================================|data |
|producer| |consumer|
+--------+ +--------+
+--------------------------+
| +-----------+ |
| | OPES | |
| | service | | +---------------+ +-----------+
| |application| | | Callout | | Callout |
| +-----------+ | | Server A | | Server X |
| || | | +--------+ | | |
| +----------------------+ | | | OPES | | | |
| | data dispatcher | | | | Service| | | +--------+|
| +----------------------+ | | | Appl A | | | | OPES ||
| || || | | +--------+ | | |Service ||
| +---------+ +-------+ | | || | | | Appl X ||
| | HTTP | | | | | +--------+ | ... | +--------||
| | | | OCP |=========| | OCP | | | || |
| +---------+ +-------+ | | +--------+ | | +------+ |
| | | || | +---------------+ | | OCP | |
| | TCP/IP | =======================================| | |
| | | | | +------+ |
| +---------+ | +-----------+
+--------||-||-------------+
|| ||
+--------+ || || +--------+
|data |== =========================================|data |
|producer| |consumer|
+--------+ +--------+
Figure 3: Interaction of OPES Entities
图3：运营实体之间的相互作用
The OPES architecture requires that each data dispatcher provides tracing facilities that allow the appropriate verification of its operation. The OPES architecture requires that tracing be feasible on the OPES flow, per OPES processor, using in-band annotation. One of those annotations could be a URI with more detailed information on the OPES services being executed in the OPES flow.
OPES体系结构要求每个数据调度器提供跟踪设施，以便对其操作进行适当的验证。OPES体系结构要求每个OPES处理器在OPES流上使用带内注释进行跟踪是可行的。其中一个注释可以是URI，其中包含有关OPES流中执行的OPES服务的更详细信息。
Providing the ability for in-band annotation MAY require header extensions on the application protocol that is used (e.g., HTTP). However, the presence of an OPES processor in the data request/ response flow SHALL NOT interfere with the operations of non-OPES aware clients and servers. Non-OPES clients and servers need not support these extensions to the base protocol.
提供带内注释功能可能需要对所使用的应用程序协议（例如HTTP）进行头扩展。但是，数据请求/响应流中的OPES处理器不得干扰非OPES感知的客户端和服务器的操作。非OPES客户端和服务器不需要支持基本协议的这些扩展。
OPES processors MUST obey tracing, reporting, and notification requirements set by the center of authority in the trust domain to which an OPES processor belongs. As part of these requirements, the OPES processor may be instructed to reject or ignore such requirements that originate from other trust domains.
OPES处理者必须遵守OPES处理者所属信任域中的授权中心设定的跟踪、报告和通知要求。作为这些要求的一部分，可能会指示OPES处理方拒绝或忽略源自其他信任域的此类要求。
Each data flow MUST be secured in accordance with several policies. The primary stakeholders are the data consumer and the data provider. The secondary stakeholders are the entities to which they may have delegated their trust. The other stakeholders are the owners of the callout servers. Any of these parties may be participants in the OPES flow.
每个数据流必须根据多个策略进行保护。主要利益相关者是数据消费者和数据提供者。次要利益相关者是指他们可能已委托其信任的实体。其他利益相关者是调用服务器的所有者。其中任何一方都可能是OPE流程的参与者。
These parties MUST have a model, explicit or implicit, describing their trust policy, which of the other parties are trusted to operate on data, and what security enhancements are required for communication. The trust might be delegated for all data, or it might be restricted to granularity as small as an application data unit.
这些参与方必须有一个模型，无论是显式的还是隐式的，描述他们的信任策略，信任哪些其他参与方对数据进行操作，以及通信需要哪些安全增强。信任可以委托给所有数据，也可以限制为与应用程序数据单元一样小的粒度。
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.
为了委托细粒度信任，各方必须通过隐式契约、设置协议、动态协商协议或与应用程序数据头一致的方式传递策略信息。
The delegation of authority starts at either a data consumer or data provider and moves to more distant entities in a "stepwise" fashion. Stepwise means A delegates to B, and B delegates to C, and so forth. The entities thus "colored" by the delegation are said to form a trust domain with respect to the original delegating party. Here, "Colored" means that if the first step in the chain is the data provider, then the stepwise delegation "colors" the chain with that data "provider" color. The only colors defined are the data "provider" and the data "consumer". Delegation of authority (coloring) propagates from the content producer start of authority or from the content consumer start of authority, which may be different from the end points in the data flow.
授权从数据使用者或数据提供者开始，并以“逐步”的方式转移到更遥远的实体。逐步的意思是A委托给B，B委托给C，依此类推。这样被委托“着色”的实体被称为相对于原始委托方形成信任域。在这里，“有色”意味着如果链中的第一步是数据提供者，则逐步委托会使用该数据“提供者”颜色“着色”链。定义的唯一颜色是数据“提供者”和数据“消费者”。授权委托（着色）从内容生产者开始的授权或从内容消费者开始的授权进行传播，这可能与数据流中的端点不同。
Figure 4 illustrates administrative domains, out-of-band rules, and policy distribution.
图4说明了管理域、带外规则和策略分布。
provider administrative domain consumer administrative domain
+------------------------------+ +-------------------------------+
| +--------------+ | | +--------------+ |
| |Provider | <- out-of-band rules, -> |Consumer | |
| |Administrative|~~>~~~: policies and ~<~|Administrative| |
| |Authority | : service authorization : |Authority | |
| +--------------+ : | | : +--------------+ |
| : : | | : : |
| : : | | : : |
| +----------+ : | | : +----------+ |
| | callout | +---------+ | | +---------+ | callout | |
| | server |====| | | | | |====| server | |
| +----------+ | | | | | | +----------+ |
| | OPES | | | | OPES | |
| +----------+ |processor| | | |processor| +----------+ |
| | | | | | | | | | | |
| | data | | | | | | | | data | |
| | provider | | | | | | | | consumer | |
| | | +---------+ | | +---------+ +----------+ |
| +----------+ || || | | || || +----------+ |
| || || || | | || || || |
| ============= ================= =========== |
| | | |
+-------------------------------+ +-------------------------------+
| <----------------- OPES flow -----------------> |
provider administrative domain consumer administrative domain
+------------------------------+ +-------------------------------+
| +--------------+ | | +--------------+ |
| |Provider | <- out-of-band rules, -> |Consumer | |
| |Administrative|~~>~~~: policies and ~<~|Administrative| |
| |Authority | : service authorization : |Authority | |
| +--------------+ : | | : +--------------+ |
| : : | | : : |
| : : | | : : |
| +----------+ : | | : +----------+ |
| | callout | +---------+ | | +---------+ | callout | |
| | server |====| | | | | |====| server | |
| +----------+ | | | | | | +----------+ |
| | OPES | | | | OPES | |
| +----------+ |processor| | | |processor| +----------+ |
| | | | | | | | | | | |
| | data | | | | | | | | data | |
| | provider | | | | | | | | consumer | |
| | | +---------+ | | +---------+ +----------+ |
| +----------+ || || | | || || +----------+ |
| || || || | | || || || |
| ============= ================= =========== |
| | | |
+-------------------------------+ +-------------------------------+
| <----------------- OPES flow -----------------> |
Figure 4: OPES administrative domains and policy distribution
图4:OPES管理域和策略分布
In order to understand the trust relationships between OPES entities, each is labeled as residing in an administrative domain. Entities associated with a given OPES flow may reside in one or more administrative domains.
为了理解OPES实体之间的信任关系，每个实体都被标记为驻留在管理域中。与给定OPES流关联的实体可能位于一个或多个管理域中。
An OPES processor may be in several trust domains at any time. There is no restriction on whether the OPES processors are authorized by data consumers and/or data providers. The original party has the option of forbidding or limiting redelegation.
一个OPES处理器可能随时位于多个信任域中。对于OPES处理器是否由数据消费者和/或数据提供商授权，没有任何限制。原协议方可选择禁止或限制再授权。
An OPES processor MUST have a representation of its trust domain memberships that it can report in whole or in part for tracing purposes. It MUST include the name of the party that delegated each privilege to it.
OPES处理程序必须具有其信任域成员身份的表示，该表示可以全部或部分报告以进行跟踪。它必须包括向其授予每项特权的一方的名称。
The OPES processor will have a configuration policy specifying what privileges the callout servers have and how they are to be identified. OPES uses standard protocols for authentication and other security communication with callout servers.
OPES处理器将具有一个配置策略，指定调出服务器具有哪些权限以及如何识别它们。OPES使用标准协议与callout服务器进行身份验证和其他安全通信。
An OPES processor will have a trusted method for receiving configuration information, such as rules for the data dispatcher, trusted callout servers, primary parties that opt-in or opt-out of individual services, etc.
OPES处理器将具有用于接收配置信息的可信方法，例如数据调度器规则、可信调出服务器、选择加入或退出单个服务的主要方等。
Protocol(s) for policy/rule distribution are out of scope for this document, but the OPES architecture assumes the existence of such a mechanism.
用于策略/规则分发的协议不在本文档的范围内，但OPES体系结构假定存在此类机制。
Requirements for the authorization mechanism are set in a separate document [4].
授权机制的要求在单独的文件[4]中设定。
Service requests may be done in-band. For example, a request to bypass OPES services could be signalled by a user agent using an HTTP header string "Bypass-OPES". Such requests MUST be authenticated. The way OPES entities will honor such requests is subordinate to the authorization policies effective at that moment.
服务请求可以在频带内完成。例如，用户代理可以使用HTTP头字符串“bypass OPES”发出绕过OPES服务的请求。此类请求必须经过身份验证。OPES实体接受此类请求的方式取决于当时有效的授权政策。
The determination of whether or not OPES processors will use the measures that are described in the previous section during their communication with callout servers depends on the details of how the primary parties delegated trust to the OPES processors and the trust relationship between the OPES processors and the callout server. Strong authentication, message authentication codes, and encryption SHOULD be used. If the OPES processors are in a single administrative domain with strong confidentiality and integrity guarantees, then cryptographic protection is recommended but optional.
OPES处理者在与调出服务器通信期间是否会使用上一节所述的措施取决于主要各方如何向OPES处理者授予信任以及OPES处理者与调出服务器之间的信任关系的详细信息。应使用强身份验证、消息身份验证代码和加密。如果OPES处理器位于一个具有强大机密性和完整性保证的管理域中，则建议使用加密保护，但这是可选的。
If the delegation mechanism names the trusted parties and their privileges in some way that permits authentication, then the OPES processors will be responsible for enforcing the policy and for using authentication as part of that enforcement.
如果委托机制以某种允许身份验证的方式命名受信任方及其权限，则OPES处理器将负责强制执行策略，并将身份验证作为强制执行的一部分。
The callout servers MUST be aware of the policy governing the communication path. They MUST not, for example, communicate confidential information to auxiliary servers outside the trust domain.
调出服务器必须知道控制通信路径的策略。例如，他们不得向信任域之外的辅助服务器传递机密信息。
A separate security association MUST be used for each channel established between an OPES processor and a callout server. The channels MUST be separate for different primary parties.
OPES处理器和调出服务器之间建立的每个通道必须使用单独的安全关联。对于不同的主要方，渠道必须是分开的。
Some data from OPES flow endpoints is considered "private" or "sensitive", and OPES processors MUST advise the primary parties of their privacy policy and respect the policies of the primary parties. The privacy information MUST be conveyed on a per-flow basis. This can be accomplished by using current available privacy techniques such as P3P [7] and HTTP privacy capabilities.
来自OPES流量端点的某些数据被视为“私有”或“敏感”，OPES处理者必须将其隐私政策告知主要当事方，并尊重主要当事方的政策。隐私信息必须按流量传递。这可以通过使用当前可用的隐私技术（如P3P[7]和HTTP隐私功能）来实现。
The callout servers MUST also participate in the handling of private data, they MUST be prepared to announce their own capabilities, and enforce the policy required by the primary parties.
调出服务器还必须参与私有数据的处理，它们必须准备好宣布自己的能力，并执行主要各方要求的策略。
Digital signature techniques can be used to mark data changes in such a way that a third-party can verify that the changes are or are not consistent with the originating party's policy. This requires an inline method to specify policy and its binding to data, a trace of changes and the identity of the party making the changes, and strong identification and authentication methods.
数字签名技术可用于标记数据更改，以便第三方能够验证更改是否与发起方的策略一致。这需要一个内联方法来指定策略及其与数据的绑定、更改跟踪和更改方的身份，以及强大的标识和身份验证方法。
Strong end-to-end integrity can fulfill some of the functions required by "tracing".
强大的端到端完整性可以实现“跟踪”所需的某些功能。
This section addresses the IAB considerations for OPES [2] and summarizes how the architecture addresses them.
本节介绍了运营商的IAB注意事项[2]，并总结了架构如何解决这些问题。
The IAB recommends that all OPES services be explicitly authorized by one of the application-layer end-hosts (that is, either the data consumer application or the data provider application).
IAB建议所有OPES服务由应用层终端主机之一（即数据使用者应用程序或数据提供者应用程序）明确授权。
The current work requires that either the data consumer application or the data provider application consent to OPES services. These requirements have been addressed in sections 2 (section 2.1) and 3.
当前工作要求数据使用者应用程序或数据提供者应用程序同意OPES服务。这些要求已在第2节（第2.1节）和第3节中说明。
The IAB recommends that OPES processors must be explicitly addressed at the IP layer by the end user (data consumer application).
IAB建议最终用户（数据消费者应用程序）必须在IP层明确寻址OPES处理器。
This requirement has been addressed in section 2.1, by the requirement that OPES processors be addressable at the IP layer by the data consumer application.
该要求已在第2.1节中通过要求OPES处理器可由数据使用者应用程序在IP层寻址来解决。
The IAB recommends that the OPES architecture incorporate tracing facilities. Tracing enables data consumer and data provider applications to detect and respond to actions performed by OPES processors that are deemed inappropriate to the data consumer or data provider applications.
IAB建议OPES体系结构包含追踪设施。跟踪使数据使用者和数据提供者应用程序能够检测并响应OPES处理器执行的对数据使用者或数据提供者应用程序不合适的操作。
Section 3.2 of this document discusses the tracing and notification facilities that must be supported by OPES services.
本文件第3.2节讨论了OPES服务必须支持的追踪和通知设施。
The OPES architecture requires the specification of extensions to HTTP. These extensions will allow the data consumer application to request a non-OPES version of the content from the data provider application. These requirements are covered in Section 3.2.
OPES体系结构需要HTTP扩展规范。这些扩展将允许数据使用者应用程序从数据提供者应用程序请求非OPES版本的内容。这些要求见第3.2节。
This consideration recommends that OPES documentation must be clear in describing OPES services as being applied to the result of URI resolution, not as URI resolution itself.
考虑到这一点，建议OPES文档在描述OPES服务应用于URI解析结果时必须清晰，而不是URI解析本身。
This requirement has been addressed in sections 2.5 and 3.2, by requiring OPES entities to document all the transformations that have been performed.
该要求已在第2.5节和第3.2节中得到解决，要求运营商实体记录所有已执行的转换。
This consideration recommends that all proposed services must define their impact on inter- and intra-document reference validity.
考虑到这一点，建议所有提议的服务必须定义其对文档间和文档内引用有效性的影响。
This requirement has been addressed in section 2.5 and throughout the document whereby OPES entities are required to document the performed transformations.
该要求已在第2.5节和整个文件中得到解决，因此OPES实体需要记录执行的转换。
This consideration recommends that any OPES 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.
该考虑事项建议，在遵守上述两个考虑事项的情况下无法实现的任何OPES服务都可以作为Internet应用程序寻址体系结构扩展的潜在需求进行审查，但不得作为临时修复。
The current work does not require extensions of the Internet application addressing architecture.
当前的工作不需要扩展Internet应用程序寻址体系结构。
This consideration recommends that the overall OPES framework must provide for mechanisms for end users to determine the privacy policies of OPES intermediaries.
这一考虑建议，整个OPES框架必须为最终用户提供机制，以确定OPES中介机构的隐私政策。
This consideration has been addressed in section 3.
这一考虑已在第3节中阐述。
The proposed work has to deal with security from various perspectives. There are security and privacy issues that relate to data consumer application, callout protocol, and the OPES flow. In [6], there is an analysis of the threats against OPES entities.
拟议的工作必须从不同角度处理安全问题。存在与数据使用者应用程序、调出协议和OPES流相关的安全和隐私问题。在[6]中，分析了针对运营实体的威胁。
The proposed work will evaluate current protocols for OCP. If the work determines that a new protocol needs to be developed, then there may be a need to request new numbers from IANA.
建议的工作将评估OCP的当前协议。如果工作确定需要制定新协议，则可能需要向IANA申请新号码。
Although the architecture supports a wide range of cooperative transformation services, it has few requirements for interoperability.
尽管该体系结构支持广泛的协作转换服务，但对互操作性的要求很少。
The necessary and sufficient elements are specified in the following documents:
以下文件规定了必要和充分的要素：
o the OPES ruleset schema, which defines the syntax and semantics of the rules interpreted by a data dispatcher; and,
o OPES规则集模式，它定义了数据调度器解释的规则的语法和语义；和
o the OPES callout protocol (OCP) [5], which defines the requirements for the protocol between a data dispatcher and a callout server.
o OPES调出协议（OCP）[5]，定义了数据调度器和调出服务器之间的协议要求。
[1] Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., and R. Penno, "Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios", RFC 3752, April 2004.
[1] Barbir，A.，Burger，E.，Chen，R.，McHenry，S.，Orman，H.，和R.Penno，“开放可插拔边缘服务（OPES）用例和部署场景”，RFC 3752，2004年4月。
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[2] Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB架构和政策考虑”，RFC 3238，2002年1月。
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[3] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[4] Barbir, A., Batuner, O., Beck, A., Chan, T., and H. Orman, "Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES)", RFC 3838, August 2004.
[4] Barbir，A.，Batuner，O.，Beck，A.，Chan，T.，和H.Orman，“开放式可插拔边缘服务（OPES）的政策、授权和实施要求”，RFC 3838，2004年8月。
[5] Beck, A., Hofmann, M., Orman, H., Penno, R., and A. Terzis, "Requirements for Open Pluggable Edge Services (OPES) Callout Protocols", RFC 3836, August 2004.
[5] Beck，A.，Hofmann，M.，Orman，H.，Penno，R.，和A.Terzis，“开放可插拔边缘服务（OPES）调用协议的要求”，RFC 38362004年8月。
[6] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H. Orman, "Security Threats and Risks for Open Pluggable Edge Services (OPES)", RFC 3837, August 2004.
[6] Barbir，A.，Batuner，O.，Srinivas，B.，Hofmann，M.，和H.Orman，“开放可插拔边缘服务（OPES）的安全威胁和风险”，RFC 3837，2004年8月。
[7] Cranor, L. et. al, "The Platform for Privacy Preferences 1.0 (P3P1.0) Specification", W3C Recommendation 16 http://www.w3.org/TR/2002/REC-P3P-20020416/, April 2002.
[7] Cranor，L.等人，“隐私偏好平台1.0（P3P1.0）规范”，W3C建议16http://www.w3.org/TR/2002/REC-P3P-20020416/，2002年4月。
This document is the product of OPES WG. Oskar Batuner (Independent consultant) and Andre Beck (Lucent) are additional authors that have contributed to this document.
本文件是OPES工作组的产品。Oskar Batuner（独立顾问）和Andre Beck（朗讯）是本文件的其他作者。
Earlier versions of this work were done by Gary Tomlinson (The Tomlinson Group) and Michael Condry (Intel).
这项工作的早期版本由Gary Tomlinson（汤姆林森集团）和Michael Condry（英特尔）完成。
The authors gratefully acknowledge the contributions of: John Morris, Mark Baker, Ian Cooper and Marshall T. Rose.
作者衷心感谢约翰·莫里斯、马克·贝克、伊恩·库珀和马歇尔·T·罗斯的贡献。
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada
加拿大安大略省内皮恩卡林大道3500号北电网络有限公司K2H 8E9
Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com
Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com
Yih-Farn Robin Chen AT&T Labs - Research 180 Park Avenue Florham Park, NJ 07932 US
Yih Farn Robin Chen AT&T实验室-美国新泽西州弗洛勒姆公园公园大道180号研究中心，邮编：07932
Phone: +1 973 360 8653
EMail: chen@research.att.com
Phone: +1 973 360 8653
EMail: chen@research.att.com
Markus Hofmann Bell Labs/Lucent Technologies Room 4F-513 101 Crawfords Corner Road Holmdel, NJ 07733 US
Markus Hofmann Bell实验室/朗讯科技公司4F-513室美国新泽西州霍姆德尔克劳福德角路101号07733
Phone: +1 732 332 5983
EMail: hofmann@bell-labs.com
Phone: +1 732 332 5983
EMail: hofmann@bell-labs.com
Hilarie Orman Purple Streak Development
Hilarie Orman紫色条纹发育
EMail: ho@alum.mit.edu
EMail: ho@alum.mit.edu
Reinaldo Penno Nortel Networks 600 Technology Park Drive Billerica, MA 01821 USA
雷纳尔多·佩诺北电网络公司美国马萨诸塞州比尔里卡科技园大道600号，邮编01821
EMail: rpenno@nortelnetworks.com
EMail: rpenno@nortelnetworks.com
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.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。