Network Working Group A. Barbir
Request for Comments: 3897 Nortel Networks
Category: Informational September 2004
Network Working Group A. Barbir
Request for Comments: 3897 Nortel Networks
Category: Informational September 2004
Open Pluggable Edge Services (OPES) Entities and End Points Communication
开放可插拔边缘服务（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 documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES).
本备忘录记录了开放式可插拔边缘服务（OPE）的跟踪和非阻塞（旁路）要求。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 2
2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Tracing Requirements . . . . . . . . . . . . . . . . . . . . . 3
3.1. Traceable entities . . . . . . . . . . . . . . . . . . . 3
3.2. System requirements . . . . . . . . . . . . . . . . . . 5
3.3. Processor requirements . . . . . . . . . . . . . . . . . 5
3.4. Callout server requirements . . . . . . . . . . . . . . 5
4. Bypass (Non-blocking feature) Requirements . . . . . . . . . . 6
4.1. Bypassable entities . . . . . . . . . . . . . . . . . . 7
4.2. System requirements . . . . . . . . . . . . . . . . . . 8
4.3. Processor requirements . . . . . . . . . . . . . . . . . 8
4.4. Callout server requirements . . . . . . . . . . . . . . 9
5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 9
6. Compliance Considerations . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1. Tracing security considerations . . . . . . . . . . . . 10
8.2. Bypass security considerations . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 2
2. OPES System . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Tracing Requirements . . . . . . . . . . . . . . . . . . . . . 3
3.1. Traceable entities . . . . . . . . . . . . . . . . . . . 3
3.2. System requirements . . . . . . . . . . . . . . . . . . 5
3.3. Processor requirements . . . . . . . . . . . . . . . . . 5
3.4. Callout server requirements . . . . . . . . . . . . . . 5
4. Bypass (Non-blocking feature) Requirements . . . . . . . . . . 6
4.1. Bypassable entities . . . . . . . . . . . . . . . . . . 7
4.2. System requirements . . . . . . . . . . . . . . . . . . 8
4.3. Processor requirements . . . . . . . . . . . . . . . . . 8
4.4. Callout server requirements . . . . . . . . . . . . . . 9
5. Protocol Binding . . . . . . . . . . . . . . . . . . . . . . . 9
6. Compliance Considerations . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1. Tracing security considerations . . . . . . . . . . . . 10
8.2. Bypass security considerations . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
The Open Pluggable Edge Services (OPES) architecture [1] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer.
开放可插拔边缘服务（OPES）体系结构[1]支持数据提供者、数据使用者和零个或多个OPES处理器之间的协作应用程序服务（OPES服务）。考虑中的应用程序服务分析并可能转换数据提供者和数据使用者之间交换的应用程序级消息。
This work specifies OPES tracing and bypass functionality. The architecture document [1] requires that tracing is supported in-band. This design goal limits the type of application protocols that OPES can support. The details of what a trace record can convey are also dependent on the choice of the application level protocol. For these reasons, this work only documents requirements for OPES entities that are needed to support traces and bypass functionality. The task of encoding tracing and bypass features is application protocol specific. Separate documents will address HTTP and other protocols.
这项工作指定了OPES跟踪和旁路功能。体系结构文档[1]要求在频带内支持跟踪。此设计目标限制了OPE可以支持的应用程序协议的类型。跟踪记录可以传达的细节也取决于应用程序级协议的选择。出于这些原因，本工作仅记录支持跟踪和旁路功能所需的OPES实体的需求。编码跟踪和绕过特性的任务是特定于应用程序协议的。单独的文档将处理HTTP和其他协议。
The architecture does not prevent implementers from developing out-of-band protocols and techniques to address tracing and bypass. Such protocols are out of scope of the current work.
该体系结构并不阻止实现者开发带外协议和技术来解决跟踪和绕过问题。此类协议超出了当前工作的范围。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase comprise normal prose usage, with no normative implications.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中所述进行解释。当和规范含义一起使用时，这些关键字将全部大写。这些单词以小写形式出现，包括正常的散文用法，没有任何规范含义。
This section provides a definition of OPES System. This is needed in order to define what is traceable (or bypassable) in an OPES Flow.
本节提供了OPES系统的定义。这是定义OPES流程中可追踪（或可绕过）内容所必需的。
Definition: An OPES System is a set of all OPES entities authorized by either the data provider or the data consumer application to process a given application message.
定义：OPES系统是由数据提供者或数据使用者应用程序授权处理给定应用程序消息的所有OPES实体组成的集合。
The nature of the authorization agreement determines if authority delegation is transitive (meaning an authorized entity is authorized to include other entities).
授权协议的性质决定了授权委托是否可传递（意味着授权实体被授权包括其他实体）。
If specific authority agreements allow for re-delegation, an OPES system can be formed by induction. In this case, an OPES system starts with entities directly authorized by a data provider (or a data consumer) application. The OPES system then includes any OPES entity authorized by an entity that is already in the OPES system. The authority delegation is always viewed in the context of a given application message.
如果特定的授权协议允许重新授权，则可通过诱导形成OPES系统。在这种情况下，OPES系统从数据提供者（或数据使用者）应用程序直接授权的实体开始。然后，OPES系统包括已经在OPES系统中的实体授权的任何OPES实体。授权委托始终在给定应用程序消息的上下文中查看。
An OPES System is defined on an application message basis. Having an authority to process a message does not imply being involved in message processing. Thus, some OPES system members may not participate in processing of a message. Similarly, some members may process the same message several times.
OPES系统是根据应用程序消息定义的。拥有处理消息的权限并不意味着参与消息处理。因此，一些OPES系统成员可能不参与消息处理。同样，一些成员可能会多次处理同一消息。
The above definition implies that there can be no more than two OPES systems [Client-side and server-side OPES systems can process the same message at the same time] processing the same message at a given time. This is based on the assumption that there is a single data provider and a single data consumer as far as a given application message is concerned.
上述定义意味着在给定时间处理同一消息的OPES系统不得超过两个[客户端和服务器端OPES系统可以同时处理同一消息]。这是基于这样的假设，即就给定的应用程序消息而言，存在单个数据提供者和单个数据使用者。
For example, consider a Content Delivery Network (CDN) delivering an image on behalf of a busy web site. OPES processors and services, which the CDN uses to adapt and deliver the image, comprise an OPES System. In a more complex example, an OPES System would contain third party OPES entities that the CDN engages to perform adaptations (e.g., to adjust image quality).
例如，考虑一个内容传递网络（CDN），它代表一个繁忙的网站提供图像。CDN用于调整和传送图像的OPES处理器和服务构成OPES系统。在更复杂的示例中，OPES系统将包含CDN参与执行自适应（例如，调整图像质量）的第三方OPES实体。
The definition of OPES trace and tracing are given next.
接下来给出了OPES跟踪和跟踪的定义。
OPES trace: application message information about OPES entities that adapted the message.
OPES trace：应用程序消息有关调整消息的OPES实体的信息。
OPES tracing: the process of creating, manipulating, or interpreting an OPES trace.
OPES跟踪：创建、操作或解释OPES跟踪的过程。
Note that the above trace definition assumes in-band tracing. This dependency can be removed if desired. Tracing is performed on per message basis. Trace format is dependent on the application protocol that is being adapted. A traceable entity can appear multiple times in a trace (for example, every time it acts on a message).
请注意，上述跟踪定义假定带内跟踪。如果需要，可以删除此依赖项。跟踪是基于每条消息执行的。跟踪格式取决于正在调整的应用程序协议。可跟踪实体可以在跟踪中多次出现（例如，每次对消息进行操作时）。
This section focuses on identifying traceable entities in an OPES Flow.
本节着重于识别OPES流程中的可追踪实体。
Tracing information provides an "end" with information about OPES entities that adapted the data. There are two distinct uses of OPES traces. First, a trace enables an "end" to detect the presence of OPES System. Such "end" should be able to see a trace entry, but does not need to be able to interpret it beyond identification of the OPES System and location of certain required OPES-related disclosures (see Section 3.2).
跟踪信息提供了一个“结束”，其中包含有关调整数据的OPES实体的信息。OPES痕迹有两种不同的用途。首先，跟踪使“终端”能够检测OPES系统的存在。这种“结束”应该能够看到跟踪条目，但不需要能够在识别OPES系统和某些要求的OPES相关披露的位置之外对其进行解释（见第3.2节）。
Second, the OPES System administrator is expected to be able to interpret the contents of an OPES trace. The trace can be relayed to the administrator by an "end" without interpretation, as opaque data (e.g., a TCP packet or an HTTP message snapshot). The administrator can use the trace information to identify the participating OPES entities. The administrator can use the trace to identify the applied adaptation services along with other message-specific information.
其次，预计OPES系统管理员能够解释OPES跟踪的内容。跟踪可以作为不透明数据（例如TCP数据包或HTTP消息快照）通过“端”转发给管理员，而无需解释。管理员可以使用跟踪信息来识别参与的OPES实体。管理员可以使用跟踪来识别应用的自适应服务以及其他特定于消息的信息。
Since the administrators of various OPES Systems can have various ways of looking into tracing, they require the freedom in what to put in trace records and how to format them.
由于各种OPES系统的管理员可以通过各种方式查看跟踪，因此他们需要在跟踪记录中输入什么以及如何格式化记录方面的自由。
At the implementation level, for a given trace, an OPES entity involved in handling the corresponding application message is traceable or traced if information about it appears in that trace. This work does not specify any order to that information. The order of information in a trace can be OPES System specific or can be defined by application bindings documents.
在实现级别，对于给定的跟踪，处理相应的应用程序消息所涉及的OPES实体是可跟踪的，或者，如果该跟踪中出现了关于它的信息，则对其进行跟踪。这项工作没有指定任何顺序的信息。跟踪中的信息顺序可以是特定于OPES系统的，也可以由应用程序绑定文档定义。
OPES entities have different levels of traceability requirements. Specifically,
OPES实体具有不同级别的可追溯性要求。明确地
o An OPES System MUST add its entry to the trace. o An OPES processor SHOULD add its entry to the trace. o An OPES service MAY add its entry to the trace. o An OPES entity MAY delegate addition of its trace entry to another OPES entity. For example, an OPES System can have a dedicated OPES processor for adding System entries; an OPES processor can use a callout service to manage all OPES trace manipulations (since such manipulations are OPES adaptations).
o OPES系统必须将其条目添加到跟踪中。o OPES处理器应将其条目添加到跟踪中。o OPES服务可将其条目添加到跟踪中。o一个OPES实体可将其跟踪条目的添加委托给另一个OPES实体。例如，OPES系统可以有一个专用的OPES处理器，用于添加系统条目；OPES处理器可以使用调用服务来管理所有OPES跟踪操作（因为此类操作是OPES自适应）。
In an OPES context, a good tracing approach is similar to a trouble ticket ready for submission to a known address. The address is printed on the ticket. The trace in itself is not necessarily a detailed description of what has happened. It is the responsibility of the operator to decode trace details and to resolve the problems.
在OPES上下文中，良好的跟踪方法类似于准备提交到已知地址的故障单。地址印在车票上。追踪本身并不一定是对所发生事情的详细描述。操作员有责任解码跟踪细节并解决问题。
The following requirements document actions when forming an OPES System trace entry:
形成OPES系统跟踪条目时，以下要求记录了行动：
o OPES system MUST include its unique identification in its trace entry. Here, uniqueness scope is all OPES Systems that may adapt the message being traced. o An OPES System MUST define its impact on inter- and intra-document reference validity. o An OPES System MUST include information about its privacy policy, including identity of the party responsible for setting and enforcing the policy. o An OPES System SHOULD include information that identifies, to the technical contact, the OPES processors involved in processing the message. o When providing required information, an OPES System MAY use a single URI to identify a resource containing several required items. For example, an OPES System can point to a single web page with a reference to System privacy policy and technical contact information.
o OPES系统必须在其跟踪条目中包含其唯一标识。在这里，唯一性范围是所有可能适应被跟踪消息的OPES系统。o OPES系统必须定义其对文档间和文档内引用有效性的影响。o OPES系统必须包含有关其隐私政策的信息，包括负责制定和执行该政策的一方的身份。o OPES系统应包括向技术联系人识别处理信息所涉及的OPES处理者的信息。o当提供所需信息时，OPES系统可以使用单个URI来标识包含多个所需项目的资源。例如，OPES系统可以指向一个网页，该网页引用了系统隐私政策和技术联系信息。
This specification does not define the meaning of the terms privacy policy, policy enforcement, or reference validity or technical contact and contains no requirements regarding encoding, language, format, or any other aspects of that information. For example, a URI used for an OPES System trace entry may look like "http:// www.examplecompany.com/opes/?client=example.com" where the identified web page is dynamically generated and contains the all OPES System information required above.
本规范未定义术语隐私政策、政策执行或参考有效性或技术联系的含义，也未包含有关编码、语言、格式或该信息任何其他方面的要求。例如，用于OPES系统跟踪条目的URI可能类似于“http://www.examplecompany.com/OPES/？client=example.com”，其中动态生成标识的网页，并包含上述所有OPES系统信息。
The following requirements document actions when forming an OPES System trace entry:
形成OPES系统跟踪条目时，以下要求记录了行动：
o OPES processor SHOULD add its unique identification to the trace. Here, uniqueness scope is the OPES System containing the processor.
o OPES处理器应将其唯一标识添加到跟踪中。这里，唯一性范围是包含处理器的OPES系统。
In an OPES system, it is the task of an OPES processor to add trace records to application messages. The OPES System administrator decides if and under what conditions callout servers may add trace information to application messages.
在OPES系统中，OPES处理器的任务是向应用程序消息添加跟踪记录。OPES系统管理员决定callout服务器是否以及在何种条件下可以向应用程序消息添加跟踪信息。
IAB recommendation (3.3) [6] requires that the OPES architecture does not prevent a data consumer application from retrieving non-OPES version of content from a data provider application, provided that the non-OPES content exists. IAB recommendation (3.3) suggests that the Non-blocking feature (bypass) be used to bypass faulty OPES intermediaries (once they have been identified, by some method).
IAB建议（3.3）[6]要求OPES体系结构不阻止数据使用者应用程序从数据提供者应用程序检索非OPES版本的内容，前提是存在非OPES内容。IAB建议（3.3）建议使用非阻塞功能（旁路）绕过有故障的OPES中介机构（一旦通过某种方法确定）。
In addressing IAB consideration (3.3), one need to specify what constitutes non-OPES content. In this work the definition of "non-OPES" content is provider dependent. In some cases, the availability of "non-OPES" content can be a function of the internal policy of a given organization that has contracted the services of an OPES provider. For example, Company A has as contract with an OPES provider to perform virus checking on all e-mail attachments. An employee X of Company A can issue a non-blocking request for the virus scanning service. The request could be ignored by the OPES provider since it contradicts its agreement with Company A.
在处理IAB考虑事项（3.3）时，需要指定什么构成非OPES内容。在这项工作中，“非运营商”内容的定义取决于供应商。在某些情况下，“非运营商”内容的可用性可能是与运营商提供商签订服务合同的特定组织的内部政策的一个功能。例如，A公司与OPES提供商签订合同，对所有电子邮件附件执行病毒检查。公司A的员工X可以为病毒扫描服务发出非阻止请求。OPES供应商可以忽略该请求，因为它与A公司的协议相矛盾。
The availability of non-OPES content can be a function of content providers (or consumers or both) policy and deployment scenarios [5]. For this reason, this work does not attempt to define what is an OPES content as opposed to non-OPES content. The meaning of OPES versus non-OPES content is assumed to be determined through various agreements between the OPES provider, data provider and/or data consumer. The agreement determines what OPES services can be bypassed and in what order (if applicable).
非OPES内容的可用性可能是内容提供商（或消费者或两者）策略和部署场景的函数[5]。因此，本工作不试图定义什么是OPES内容，而不是非OPES内容。OPES与非OPES内容的含义假定通过OPES提供商、数据提供商和/或数据消费者之间的各种协议确定。该协议确定了哪些OPES服务可以绕过，以及以何种顺序（如果适用）绕过。
This specification documents bypassing of an OPES service or a group of services identified by a URI. In this context, to "bypass the service" for a given application message in an OPES Flow means to "not invoke the service" for that application message. A bypass URI that identifies an OPES system (processor) matches all services attached to that OPES system (processor). However, bypassing of OPES processors and OPES Systems themselves requires non-OPES mechanisms and is out of this specification scope. A bypass request an instruction to bypass, usually embedded in an application message.
本规范记录了对OPES服务或URI标识的一组服务的绕过。在此上下文中，在OPES流中对给定应用程序消息“绕过服务”意味着对该应用程序消息“不调用服务”。标识OPES系统（处理器）的旁路URI与连接到该OPES系统（处理器）的所有服务匹配。然而，绕过OPES处理器和OPES系统本身需要非OPES机制，不在本规范范围内。旁路请求一条要旁路的指令，通常嵌入在应用程序消息中。
The current specification does not provide for a good mechanism that allow and "end" to specify to "bypass this service but only if it is a part of that OPES system" or "bypass all services of that OPES system but not of this OPES system". Furthermore, if an OPES processor does not know for sure that a bypass URI does not match its service, it must bypass that service.
目前的规范没有提供一个良好的机制，允许和“结束”指定“绕过此服务，但仅当它是该OPES系统的一部分”或“绕过该OPES系统但不是该OPES系统的所有服务”。此外，如果OPES处理器不确定旁路URI是否与其服务不匹配，则必须绕过该服务。
If no non-OPES content is available without the specified service, the bypass request for that service must be ignored. This design implies that it may not be possible to detect non-OPES content existence or to detect violations of bypass rules in the environments where the tester does not know whether non-OPES content exists. This design assumes that most bypass requests are intended for situations where serving undesirable OPES content is better than serving an error message that no preferred non-OPES content exists.
如果没有指定的服务就没有非OPES内容可用，则必须忽略该服务的旁路请求。这种设计意味着，在测试人员不知道是否存在非OPES内容的环境中，可能无法检测到非OPES内容的存在或检测到违反绕过规则的情况。此设计假定大多数绕过请求都适用于提供不需要的OPES内容比提供不存在首选非OPES内容的错误消息要好的情况。
Bypass feature is to malfunctioning OPES services as HTTP "reload" request is to malfunctioning HTTP caches. The primary purpose of the bypass is to get usable content in the presence of service failures and not to provide the content consumer with more information on what is going on. OPES trace should be used for the latter instead.
旁路功能用于故障的OPES服务，就像HTTP“重新加载”请求用于故障的HTTP缓存一样。旁路的主要目的是在出现服务故障时获取可用内容，而不是向内容消费者提供更多有关正在发生的情况的信息。后者应使用OPES跟踪。
While this work defines a "bypass service if possible" feature, there are other related bypass features that can be implemented in OPES and/or in application protocols being adapted. For example, a "bypass service or generate an error" or "bypass OPES entity or generate an error". Such services would be useful for debugging broken OPES systems and may be defined in other OPES specifications. This work concentrates on documenting a user-level bypass feature addressing direct IAB concerns.
虽然这项工作定义了一个“如果可能的话旁路服务”特性，但是还有其他相关的旁路特性可以在OPE和/或正在调整的应用协议中实现。例如，“绕过服务或生成错误”或“绕过OPES实体或生成错误”。此类服务将有助于调试损坏的OPES系统，并可在其他OPES规范中定义。这项工作集中于记录用户级旁路功能，以解决IAB的直接问题。
In this work, the focus is on developing a bypass feature that allows a user to instruct the OPES System to bypass some or all of its services. The collection of OPES services that can be bypassed is a function of the agreement of the OPES provider with either (or both) the content provider or the content consumer applications. In the general case, a bypass request is viewed as a bypass instruction that contains a URI that identifies an OPES entity or a group of OPES entities that perform a service (or services) to be bypassed. An instruction may contain more than one such URI. A special wildcard identifier can be used to represent all possible URIs.
在这项工作中，重点是开发一个旁路功能，允许用户指示OPES系统绕过其部分或全部服务。可绕过的OPES服务集合是OPES提供商与内容提供商或内容消费者应用程序（或两者）达成协议的一项功能。在一般情况下，旁路请求被视为一条旁路指令，该指令包含一个URI，该URI标识执行要旁路的服务的OPES实体或一组OPES实体。一条指令可以包含多个这样的URI。特殊的通配符标识符可用于表示所有可能的URI。
In an OPES Flow, a bypass request is processed by each involved OPES processor. This means that an OPES processor examines the bypass instruction and if non-OPES content is available, the processor then bypasses the indicated services. The request is then forwarded to the next OPES processor in the OPES Flow. The next OPES processor would then handle all bypass requests, regardless of the previous processor actions. The processing chain continues throughout the whole processors that are involved in the OPES Flow.
在OPES流中，旁路请求由每个涉及的OPES处理器处理。这意味着OPES处理器检查旁路指令，如果非OPES内容可用，则处理器将绕过指示的服务。然后将请求转发到OPES流中的下一个OPES处理器。然后，下一个OPES处理器将处理所有旁路请求，而不考虑之前的处理器操作。处理链贯穿于OPES流程中涉及的整个处理器。
In an OPES System, bypass requests are generally client centric (originated by the data consumer application) and go in the opposite direction of tracing requests. This work requires that the bypass feature be performed in-band as an extension to an application specific protocol. Non-OPES entities should be able to safely ignore these extensions. The work does not prevent OPES Systems from developing their own out of band protocols.
在OPES系统中，旁路请求通常以客户端为中心（由数据使用者应用程序发起），与跟踪请求的方向相反。这项工作要求旁路功能作为应用程序特定协议的扩展在频带内执行。非运营实体应该能够安全地忽略这些扩展。这项工作并不妨碍OPES系统开发自己的带外协议。
The following requirements apply for bypass feature as related to an OPES System (the availability of a non-OPES content is a precondition):
以下要求适用于与OPES系统相关的旁路功能（非OPES内容的可用性是先决条件）：
o An OPES System MUST support a bypass feature. This means that the OPES System bypasses services whose URIs are identified by an OPES "end". o An OPES System MUST provide OPES version of the content if non-OPES version is not available.
o OPES系统必须支持旁路功能。这意味着OPES系统绕过URI由OPES“端”标识的服务。o如果非OPES版本不可用，OPES系统必须提供OPES版本的内容。
In order to facilitate the debugging (or data consumer user experience) of the bypass feature in an OPES System, it would be beneficial if non-bypassed entities included information related to why they ignored the bypass instruction. It is important to note that in some cases the tracing facility itself may be broken and the whole OPES System (or part) may need to be bypassed through the issue of a bypass instruction.
为了促进OPES系统中旁路功能的调试（或数据使用者用户体验），如果非旁路实体包含与忽略旁路指令的原因相关的信息，这将是有益的。需要注意的是，在某些情况下，跟踪设施本身可能会损坏，可能需要通过发出旁路指令绕过整个OPES系统（或部分）。
Bypass requirements for OPES processors are (the availability of a non-OPES content is a precondition):
OPES处理器的旁路要求如下（非OPES内容的可用性是一个先决条件）：
o OPES processor SHOULD be able to interpret and process a bypass instruction. This requirement applies to all bypass instructions, including those that identify unknown-to-recipient services. o OPES processors MUST forward bypass request to the next application hop provided that the next hop speaks application protocol with OPES bypass support. o OPES processor SHOULD be able to bypass it's service(s) execution.
o OPES处理器应该能够解释和处理旁路指令。此要求适用于所有旁路指令，包括识别接收方服务未知的旁路指令。o OPES处理器必须将旁路请求转发到下一个应用程序跃点，前提是下一个跃点使用OPES旁路支持的应用程序协议。o OPES处理器应能够绕过其服务执行。
OPES processors that know how to process and interpret a bypass instruction have the following requirements:
知道如何处理和解释旁路指令的OPES处理器具有以下要求：
o The recipient of a bypass instruction with a URI that does not identify any known-to-recipient OPES entity MUST treat that URI as a wildcard identifier (meaning bypass all applicable services).
o 具有未标识接收方OPES实体已知URI的旁路指令的接收方必须将该URI视为通配符标识符（意味着绕过所有适用的服务）。
In an OPES system, it is the task of an OPES processor to process bypass requests. The OPES System administrator decides if and under what conditions callout servers process bypass requests.
在OPES系统中，OPES处理器的任务是处理旁路请求。OPES系统管理员决定callout服务器是否以及在何种条件下处理旁路请求。
The task of encoding tracing and bypass features is application protocol specific. Separate documents will address HTTP and other protocols. These documents must address the ordering of trace information as needed.
编码跟踪和绕过特性的任务是特定于应用程序协议的。单独的文档将处理HTTP和其他协议。这些文件必须根据需要说明跟踪信息的顺序。
This specification defines compliance for the following compliance subjects: OPES System, processors, entities and callout servers.
本规范定义了以下合规主题的合规性：OPES系统、处理器、实体和标注服务器。
A compliance subject is compliant if it satisfies all applicable "MUST" and "SHOULD" level requirements. By definition, to satisfy a "MUST" level requirement means to act as prescribed by the requirement; to satisfy a "SHOULD" level requirement means to either act as prescribed by the requirement or have a reason to act differently. A requirement is applicable to the subject if it instructs (addresses) the subject.
如果合规主体满足所有适用的“必须”和“应该”级别要求，则合规主体为合规主体。根据定义，满足“必须”级别的要求意味着按照要求的规定行事；满足“应该”级别的要求意味着要么按照要求的规定行事，要么有理由采取不同的行动。如果要求指示（说明）主题，则要求适用于主题。
Informally, compliance with this document means that there are no known "MUST" violations, and all "SHOULD" violations are conscious. In other words, a "SHOULD" means "MUST satisfy or MUST have a reason to violate". It is expected that compliance claims are accompanied by a list of unsupported SHOULDs (if any), in an appropriate format, explaining why preferred behavior was not chosen.
非正式地说，遵守本文件意味着没有已知的“必须”违反行为，所有“应该”违反行为都是有意识的。换句话说，“应该”意味着“必须满足或必须有理由违反”。预计合规性声明将以适当的格式随附一份不受支持的应该（如果有）列表，解释为什么没有选择首选行为。
Only normative parts of this specification affect compliance. Normative parts are: parts explicitly marked using the word "normative", definitions, and phrases containing unquoted capitalized keywords from RFC 2119 [2]. Consequently, examples and illustrations are not normative.
只有本规范的规范性部分影响合规性。规范性部分是：使用RFC 2119[2]中的“规范性”一词、定义和包含未加引号大写关键字的短语明确标记的部分。因此，示例和说明不具有规范性。
This specification contains no IANA considerations. Application bindings MAY contain application-specific IANA considerations.
本规范不包含IANA注意事项。应用程序绑定可能包含特定于应用程序的IANA注意事项。
Security considerations for OPES are documented in [4]. Policy and authorization issues are documented in [3]. It is recommended that designers consult these documents before reading this section.
OPE的安全注意事项记录在[4]中。政策和授权问题记录在[3]中。建议设计师在阅读本节之前查阅这些文件。
This document is a requirement document for tracing and bypass feature. The requirements that are stated in this document can be used to extend an application level protocol to support these features. As such, the work has security precautions.
本文档是跟踪和绕过特性的需求文档。本文档中所述的要求可用于扩展应用程序级协议以支持这些功能。因此，工程具有安全预防措施。
The tracing facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the tracing facility may defeat safeguards built into the OPES architecture. The tracing facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System.
OPES体系结构的跟踪功能作为协议扩展实现。追踪设施的不充分实施可能会破坏OPES体系结构中内置的保障措施。跟踪设施本身可能成为恶意攻击的目标，或被用于对OPES系统进行午餐攻击。
Threats caused by or against the tracing facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application.
由跟踪设施引起或针对跟踪设施的威胁可被视为OPES流中应用程序级别的威胁。在这种情况下，威胁可能会影响数据使用者和数据提供者应用程序。
Since tracing information is a protocol extension, these traces can be injected in the data flow by non-OPES entities. In this case, there are risks that non-OPES entities can be compromised in a fashion that threat the overall integrity and effectiveness of an OPES System. For example, a non-OPES proxy can add fake tracing information into a trace. This can be done in the form of wrong, or unwanted, or non existent services. A non-OPES entity can inject large size traces that may cause buffer overflow in a data consumer application. The same threats can arise from compromised OPES entities. An attacker can control an OPES entity and inject wrong, or very large trace information that can overwhelm an end or the next OPES entity in an OPES flow. Similar threats can result from bad implementations of the tracing facility in trusted OPES entities.
由于跟踪信息是一种协议扩展，因此非OPES实体可以将这些跟踪注入数据流。在这种情况下，非OPES实体可能会以威胁OPES系统整体完整性和有效性的方式受到损害。例如，非OPES代理可以将虚假跟踪信息添加到跟踪中。这可以通过错误的、不需要的或不存在的服务来实现。非OPES实体可以注入可能导致数据使用者应用程序中缓冲区溢出的大尺寸跟踪。同样的威胁也可能来自受损的OPES实体。攻击者可以控制一个OPES实体并注入错误的或非常大的跟踪信息，这些信息可能会淹没OPES流中的一个末端或下一个OPES实体。类似的威胁可能源于可信OPES实体中跟踪设施的错误实现。
Compromised tracing information can be used to launch attacks on an OPES System that give the impression that unwanted content transformation was performed on the data. This can be achieved by inserting wrong entity (such OPES processor) identifiers. A compromised trace can affect the overall message integrity structure. This can affect entities that use message header information to perform services such as accounting, load balancing, or reference-based services.
泄露的跟踪信息可用于对OPES系统发起攻击，给人留下对数据执行了不必要的内容转换的印象。这可以通过插入错误的实体（如OPES处理器）标识符来实现。受损的跟踪可能会影响整个消息完整性结构。这可能会影响使用消息头信息执行服务（如记帐、负载平衡或基于引用的服务）的实体。
Compromised trace information can be used to launch DoS attacks that can overwhelm a data consumer application or an OPES entity in an OPES Flow. Inserting wrong tracing information can complicate the debugging tasks performed by system administrator during trouble shooting of OPES System behavior.
泄露的跟踪信息可用于发起DoS攻击，从而使数据使用者应用程序或OPES流中的OPES实体崩溃。在对OPES系统行为进行故障排除期间，插入错误的跟踪信息可能会使系统管理员执行的调试任务复杂化。
As a precaution, OPES entities ought to be capable of verifying that the inserted traces are performed by legal OPES entities. This can be done as part of the authorization and authentication face. Policy can be used to indicate what trace information can be expected from a peer entity. Other application level related security concerns can be found in [4].
作为预防措施，OPES实体应能够验证插入的记录道是否由合法的OPES实体执行。这可以作为授权和身份验证面的一部分来完成。策略可用于指示可从对等实体获得的跟踪信息。其他与应用程序级别相关的安全问题可在[4]中找到。
The bypass facility for OPES architecture is implemented as a protocol extension. Inadequate implementations of the bypass facility may defeat safeguards built into the OPES architecture. The bypass facility by itself can become a target of malicious attacks or used to lunch attacks on an OPES System.
OPES架构的旁路设施作为协议扩展实现。旁路设施的不充分实施可能会破坏OPES体系结构中的保障措施。旁路设施本身可能成为恶意攻击的目标，或用于对OPES系统进行午餐攻击。
Threats caused by or against the bypass facility can be viewed as threats at the application level in an OPES Flow. In this case, the threats can affect the data consumer and the data provider application.
旁路设施造成的或针对旁路设施的威胁可被视为OPES流程中应用级别的威胁。在这种情况下，威胁可能会影响数据使用者和数据提供者应用程序。
There are risks for the OPES System by non-OPES entities, whereby, these entities can insert bypass instructions into the OPES Flow. The threat can come from compromised non-OPES entities. The threat might affect the overall integrity and effectiveness of an OPES System. For example, a non-OPES proxy can add bypass instruction to bypass legitimate OPES entities. The attack might result in overwhelming the original content provider servers, since the attack essentially bypass any load balancing techniques. In addition, such an attack is also equivalent to a DoS attack, whereby, a legitimate data consumer application may not be able to access some content from a content provider or its OPES version.
非OPES实体对OPES系统存在风险，因此，这些实体可以在OPES流中插入旁路指令。威胁可能来自受损的非运营实体。这种威胁可能会影响OPES系统的整体完整性和有效性。例如，非OPES代理可以添加旁路指令以绕过合法的OPES实体。该攻击可能会导致原始内容提供商服务器崩溃，因为该攻击基本上绕过了任何负载平衡技术。此外，此类攻击还相当于DoS攻击，因此，合法的数据使用者应用程序可能无法从内容提供商或其OPES版本访问某些内容。
Since an OPES Flow may include non-OPES entities, it is susceptible to man-in-the-middle attacks, whereby an intruder may inject bypass instructions into the data path. These attacks may affect content availability or disturb load balancing techniques in the network.
由于OPES流可能包括非OPES实体，因此容易受到中间人攻击，入侵者可能会将绕过指令注入数据路径。这些攻击可能会影响内容可用性或干扰网络中的负载平衡技术。
The above threats can also arise by compromised OPES entities. An intruder can compromise an OPES entities and then use man-in-the-middle techniques to disturb content availability to a data consumer application or overload a content provider server (essentially, some form of a DoS attack).
上述威胁也可能由受损的OPES实体引起。入侵者可以破坏OPES实体，然后使用中间人技术干扰数据使用者应用程序的内容可用性或使内容提供商服务器过载（本质上是某种形式的DoS攻击）。
Attackers can use the bypass instruction to affect the overall integrity of the OPES System. The ability to introduce bypass instructions into a data flow may effect the accounting of the OPES System. It may also affect the quality of content that is delivered to the data consumer applications. Similar threats can arise from bad implementations of the bypass facility.
攻击者可以使用旁路指令影响OPES系统的整体完整性。将旁路指令引入数据流的能力可能会影响OPES系统的记帐。它还可能影响交付给数据使用者应用程序的内容质量。类似的威胁可能来自旁路设施的错误实现。
Inconsistent or selective bypass is also a threat. Here, one end can try to bypass a subset of OPES entities so that the resulting content is malformed and crashes or compromises entities that process that content (and expect that content to be complete and valid). Such exceptions are often not tested because implementers do not expect a vital service to disappear from the processing loop.
不一致或选择性旁路也是一种威胁。在这里，一端可以尝试绕过OPES实体的子集，从而导致生成的内容格式不正确，并使处理该内容的实体崩溃或受损（并期望该内容完整有效）。这样的异常通常不会被测试，因为实现者不希望重要的服务从处理循环中消失。
Other threats can arise from configuring access control policies for OPES entities. It is possible that systems implementing access controls via OPES entities may be incorrectly configured to honor bypass and, hence, give unauthorized access to intruders.
为OPES实体配置访问控制策略可能会产生其他威胁。通过OPES实体实施访问控制的系统可能被错误地配置为允许绕过，从而允许入侵者进行未经授权的访问。
Tap bypass can also be a threat. This is because systems implementing wiretaps via OPES entities may be incorrectly configured to honor bypass and, hence, ignore (leave undetected) traffic with bypass instructions that should have been tapped or logged. It is also possible for one end to bypass services such as virus scanning at the receiving end. This threat can be used by hackers to inject viruses throughout the network. Following an IETF policy on Wiretapping [7], OPES communication model does not consider wiretapping requirements. Nevertheless, the documented threat is real, not obvious, and OPES technology users operating in wiretapping or similar logging environments should be aware of it.
水龙头旁路也可能是一种威胁。这是因为通过OPES实体实施窃听的系统可能被错误地配置为支持旁路，从而忽略（未被检测到）本应被窃听或记录的旁路指令流量。也有可能一方绕过接收端的病毒扫描等服务。黑客可以利用这种威胁在整个网络中注入病毒。在IETF关于窃听的策略（7）之后，OPE通信模型不考虑窃听要求。尽管如此，记录在案的威胁是真实的，并不明显，在窃听或类似测井环境中运行的OPES技术用户应该意识到这一点。
Other application level related security concerns can be found in [4].
其他与应用程序级别相关的安全问题可在[4]中找到。
[1] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.
[1] Barbir，A.，Penno，R.，Chen，R.，Hofmann，M.，和H.Orman，“开放可插拔边缘服务（OPES）的体系结构”，RFC 38352004年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Barbir, A., Batuner, O., Beck, A., Chan, T., and H. Orman, "Policy, Authorization, and Enforcement Requirements of Open Pluggable Edge Services (OPES)", RFC 3838, August 2004.
[3] Barbir，A.，Batuner，O.，Beck，A.，Chan，T.，和H.Orman，“开放可插拔边缘服务（OPES）的政策、授权和实施要求”，RFC 3838，2004年8月。
[4] 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.
[4] Barbir，A.，Batuner，O.，Srinivas，B.，Hofmann，M.，和H.Orman，“开放可插拔边缘服务（OPES）的安全威胁和风险”，RFC 3837，2004年8月。
[5] 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.
[5] Barbir A.，Burger，E.，Chen，R.，McHenry，S.，Orman，H.，和R.Penno，“开放可插拔边缘服务（OPES）用例和部署场景”，RFC 3752，2004年4月。
[6] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[6] Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB架构和政策考虑”，RFC 3238，2002年1月。
[7] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[7] IAB和IESG，“IETF关于窃听的政策”，RFC 2804，2000年5月。
Several people has contributed to this work. Many thanks to: Alex Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin Stecher, Marshall Rose and Reinaldo Penno.
有几个人对这项工作做出了贡献。非常感谢：亚历克斯·罗斯科夫、希拉里·奥曼、奥斯卡·巴图纳、马库斯·哈夫曼、马丁·斯蒂彻、马歇尔·罗斯和雷纳尔多·佩诺。
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
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、其代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向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编辑功能的资金目前由互联网协会提供。