Network Working Group A. Barbir
Request for Comments: 3914 Nortel Networks
Category: Informational A. Rousskov
The Measurement Factory
October 2004
Network Working Group A. Barbir
Request for Comments: 3914 Nortel Networks
Category: Informational A. Rousskov
The Measurement Factory
October 2004
Open Pluggable Edge Services (OPES) Treatment of IAB Considerations
开放可插拔边缘服务（OPES）处理IAB注意事项
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
摘要
IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations.
IETF互联网体系结构委员会（IAB）表达了开放可插拔边缘服务（OPES）框架的九个体系结构层面的考虑。本文件描述了OPES如何解决这些问题。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Consideration (2.1) 'One-party consent' . . . . . . . . . . . 3
4. Consideration (2.2) 'IP-layer communications' . . . . . . . . 4
5. Notification Considerations . . . . . . . . . . . . . . . . . 5
5.1. Notification versus trace. . . . . . . . . . . . . . . . 6
5.2. An example of an OPES trace for HTTP . . . . . . . . . . 8
5.3. Consideration (3.1) 'Notification' . . . . . . . . . . . 9
5.4. Consideration (3.2) 'Notification' . . . . . . . . . . . 10
6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 10
7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 11
8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 11
9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 12
10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 12
11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 12
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Consideration (2.1) 'One-party consent' . . . . . . . . . . . 3
4. Consideration (2.2) 'IP-layer communications' . . . . . . . . 4
5. Notification Considerations . . . . . . . . . . . . . . . . . 5
5.1. Notification versus trace. . . . . . . . . . . . . . . . 6
5.2. An example of an OPES trace for HTTP . . . . . . . . . . 8
5.3. Consideration (3.1) 'Notification' . . . . . . . . . . . 9
5.4. Consideration (3.2) 'Notification' . . . . . . . . . . . 10
6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 10
7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 11
8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 11
9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 12
10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 12
11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 12
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16
The Open Pluggable Edge Services (OPES) architecture [RFC3835], enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer.
开放可插拔边缘服务（OPES）体系结构[RFC3835]支持数据提供者、数据使用者和零个或多个OPES处理器之间的协作应用程序服务（OPES服务）。考虑中的应用程序服务分析并可能转换数据提供者和数据使用者之间交换的应用程序级消息。
In the process of chartering OPES, the IAB made recommendations on issues that OPES solutions should be required to address. These recommendations were formulated in the form of a specific IAB considerations document [RFC3238]. In that document, IAB emphasized that its considerations did not recommend specific solutions and did not mandate specific functional requirements. Addressing an IAB consideration may involve showing appropriate protocol mechanisms or demonstrating that the issue does not apply. Addressing a consideration does not necessarily mean supporting technology implied by the consideration wording.
在租船OPE的过程中，IAB就OPE解决方案需要解决的问题提出了建议。这些建议以特定IAB注意事项文件[RFC3238]的形式制定。在该文件中，IAB强调，其考虑并未建议具体的解决方案，也未规定具体的功能要求。解决IAB考虑事项可能涉及显示适当的协议机制或证明该问题不适用。解决对价不一定意味着支持对价措辞所隐含的技术。
The primary goal of this document is to show that all formal IAB recommendations are addressed by OPES, to the extent that those considerations can be addressed by an IETF working group. The limitations of OPES working group to address certain aspects of IAB considerations are also explicitly documented.
本文件的主要目标是表明所有正式的IAB建议都由运营商提出，只要IETF工作组能够解决这些问题。OPES工作组在解决IAB考虑的某些方面的局限性也有明确的记录。
IAB considerations document [RFC3238] contains many informal recommendations. For example, while the IAB informally requires OPES architecture to "protect end-to-end data integrity by supporting end-host detection and response to inappropriate behavior by OPES intermediaries", the IAB has chosen to formalize these requirements via a set of more specific recommendations, such as Notification considerations addressed in Section 5.3 and Section 5.4 below. OPES framework addresses informal IAB recommendations by addressing corresponding formal considerations.
IAB注意事项文件[RFC3238]包含许多非正式建议。例如，虽然IAB非正式地要求OPES架构“通过支持终端主机检测和响应OPES中介机构的不当行为来保护端到端数据完整性”，但IAB选择通过一组更具体的建议将这些要求正式化，如下文第5.3节和第5.4节所述的通知注意事项。OPES框架通过解决相应的正式考虑事项来解决非正式IAB建议。
There are nine formal IAB considerations [RFC3238] that OPES has to address. In the core of this document are the corresponding nine "Consideration" sections. For each IAB consideration, its section contains general discussion as well as references to specific OPES mechanisms relevant to the consideration.
运营运营商必须解决九个正式的IAB考虑事项[RFC3238]。本文件的核心是相应的九个“考虑”部分。对于每个IAB考虑事项，其章节包含一般性讨论以及与考虑事项相关的特定OPES机制的参考。
This document does not introduce any new terminology but uses terminology from other OPES documents.
本文件未引入任何新术语，但使用了其他OPES文件中的术语。
"An OPES framework standardized in the IETF must require that the use of any OPES service be explicitly authorized by one of the application-layer end-hosts (that is, either the content provider or the client)." [RFC3238]
“IETF中标准化的OPES框架必须要求任何OPES服务的使用由应用层终端主机之一（即，内容提供商或客户端）明确授权。”[RFC3238]
OPES architecture requires that "OPES processors MUST be consented to by either the data consumer or data provider application" [RFC3835]. While this requirement directly satisfies IAB concern, no requirement alone can prevent consent-less introduction of OPES processors. In other words, OPES framework requires one-party consent but cannot guarantee it in the presence of incompliant OPES entities.
OPES体系结构要求“OPES处理器必须得到数据使用者或数据提供者应用程序的同意”[RFC3835]。虽然这一要求直接满足了IAB的要求，但单凭任何要求都不能阻止采用无需征得同意的OPES处理器。换言之，OPES框架需要一方同意，但不能在不符合OPES规定的实体在场的情况下保证。
In [RFC3897], the OPES architecture enables concerned parties to detect unwanted OPES processors by examining OPES traces. While the use of traces in OPES is mandatory, a tracing mechanism on its own cannot detect processors that are in violation of OPES specifications. Examples include OPES processors operating in stealth mode. However, the OPES architecture allows the use of content signature to verify the authenticity of performed
在[RFC3897]中，OPES体系结构使相关方能够通过检查OPES跟踪来检测不需要的OPES处理器。虽然在OPES中必须使用跟踪，但跟踪机制本身无法检测到违反OPES规范的处理器。例如，以隐形模式运行的OPES处理器。但是，OPES体系结构允许使用内容签名来验证所执行内容的真实性
adaptations. Content signatures is a strong but expensive mechanism that can detect any modifications of signed content provided that the content provider is willing to sign the data and that the client is willing to either check the signature or relay received content to the content provider for signature verification.
适应。内容签名是一种强大但昂贵的机制，如果内容提供商愿意对数据进行签名，并且客户端愿意检查签名或将接收到的内容转发给内容提供商进行签名验证，则可以检测签名内容的任何修改。
OPES entities may copy or otherwise access content without modifying it. Such access cannot be detected using content signatures. Thus, "passive" OPES entities can operate on signed content without the data consumer or provider consent. If content privacy is a concern, then content encryption can be used. A passive processor is no different from any intermediary operating outside of OPES framework. No OPES mechanism (existing or foreseeable) can prevent non-modifying access to content.
OPES实体可以复制或以其他方式访问内容，而无需修改内容。使用内容签名无法检测到这种访问。因此，“被动”运营商实体可以在未经数据消费者或提供商同意的情况下对签名内容进行操作。如果关注内容隐私，则可以使用内容加密。被动处理器与任何在OPES框架之外运行的中间处理器没有什么不同。任何OPES机制（现有或可预见）都无法阻止对内容的非修改访问。
In summary, the one-party consent is satisfied by including the corresponding requirement in the IAB architecture document. That requirement alone cannot stop incompliant OPES entities to perform consent-less adaptations, but OPES framework allows for various means of detecting and/or preventing such adaptations. These means typically introduce overheads and require some level of producer-consumer cooperation.
总之，通过在IAB架构（architecture）文件中包含相应的要求来满足一方同意。单凭这一要求并不能阻止不符合要求的OPES实体进行无需同意的适应，但OPES框架允许采用各种方法检测和/或防止此类适应。这些手段通常会带来间接费用，并需要一定程度的生产者-消费者合作。
"For an OPES framework standardized in the IETF, the OPES intermediary must be explicitly addressed at the IP layer by the end user" [RFC3238].
“对于IETF中标准化的OPES框架，终端用户必须在IP层明确寻址OPES中介”[RFC3238]。
The OPES architecture requires that "OPES processors MUST be addressable at the IP layer by the end user (data consumer application)" [RFC3835]. The IAB and the architecture documents mention an important exception: addressing the first OPES processor in a chain of processors is sufficient. That is, a chain of OPES processors is viewed as a single OPES "system" at the address of the first chain element.
OPES体系结构要求“终端用户（数据消费者应用程序）必须能够在IP层寻址OPES处理器”[RFC3835]。IAB和体系结构文档提到了一个重要的例外：解决处理器链中的第一个OPES处理器就足够了。也就是说，OPES处理器链被视为第一个链元素地址处的单个OPES“系统”。
The notion of a chain is not strictly defined by IAB. For the purpose of addressing this consideration, a group of OPES processors working on a given application transaction is considered. Such a group would necessarily form a single processing chain, with a single "exit" OPES processor (i.e., the processor that adapted the given message last). The OPES architecture essentially requires that last OPES processor to be explicitly addressable at the IP layer by the data consumer application. The chain formation, including its exit point may depend on an application message and other dynamic factors such as time of the day or system load.
IAB没有严格定义链的概念。为了解决这个问题，需要考虑一组处理给定应用程序事务的OPES处理器。这样一个组必然会形成一个单一的处理链，带有一个“退出”OPES处理器（即，最后修改给定消息的处理器）。OPES体系结构本质上要求最后一个OPES处理器在IP层由数据使用者应用程序显式寻址。链的形成，包括其退出点，可能取决于应用程序消息和其他动态因素，如一天中的时间或系统负载。
Furthermore, if OPES processing is an internal processing step at a data consumer or a data provider application side, then the last OPES processor may reside in a private address space and may not be explicitly addressable from the outside. In such situations, the processing side must designate an addressable point on the same processing chain. That designated point may not be, strictly speaking, an OPES processor, but it will suffice as such as far as IAB considerations are concerned -- the data consumer application will be able to address it explicitly at the IP layer and it will represent the OPES processing chain to the outside world.
此外，如果OPES处理是数据消费者或数据提供者应用侧的内部处理步骤，则最后一个OPES处理器可以驻留在私有地址空间中，并且不能从外部显式寻址。在这种情况下，处理端必须在同一处理链上指定一个可寻址点。严格来说，该指定点可能不是OPES处理器，但就IAB考虑而言，它就足够了——数据使用者应用程序将能够在IP层显式地对其进行寻址，并且它将代表OPES处理链到外部世界。
Designating an addressable processing point avoids the conflict between narrow interpretation of the IAB consideration and real system designs. It is irrational to expect a content provider to provide access to internal hosts participating in content generation, whether OPES processors are involved or not. Moreover, providing such access would serve little practical purpose because internal OPES processors are not likely to be able to answer any data consumer queries, being completely out of content generation context. For example, an OPES processor adding customer-specific information to XML pages may not understand or be aware of any final HTML content that the data consumer application receives and may not be able to map end user request to any internal user identification. Since OPES requires the end of the message processing chain to be addressable, the conflict does not exist. OPES places no requirements on the internal architecture of data producer systems while requiring the entire OPES-related content production "system" to be addressable at the IP layer.
指定一个可寻址的处理点避免了IAB考虑的狭义解释和实际系统设计之间的冲突。期望内容提供商提供对参与内容生成的内部主机的访问是不合理的，无论是否涉及OPES处理器。此外，提供这种访问几乎没有实际用途，因为内部OPES处理器不太可能回答任何数据消费者查询，完全脱离了内容生成上下文。例如，向XML页面添加客户特定信息的OPES处理器可能不理解或不知道数据使用者应用程序接收到的任何最终HTML内容，并且可能无法将最终用户请求映射到任何内部用户标识。由于OPES要求消息处理链的末端可寻址，因此不存在冲突。OPES不要求数据生成系统的内部架构，同时要求整个OPES相关内容生成“系统”可在IP层寻址。
Private Domain | Public Domain | Private Domain
| |
+--------------+ | +-------------+ +--------+
| Data | | | OPES System | |Data |
| Consumer |<--- network -->| with public |<---->|Provider|
| Application | | | IP address | |App |
+--------------+ | +-------------+ +--------+
| |
| |
Private Domain | Public Domain | Private Domain
| |
+--------------+ | +-------------+ +--------+
| Data | | | OPES System | |Data |
| Consumer |<--- network -->| with public |<---->|Provider|
| Application | | | IP address | |App |
+--------------+ | +-------------+ +--------+
| |
| |
Figure 1
图1
This section discusses how OPES framework addresses IAB Notification considerations 3.1 and 3.2.
本节讨论OPES框架如何解决IAB通知注意事项3.1和3.2。
Before specific considerations are discussed, the relationship between IAB notifications and OPES tracing has to be explained. OPES framework concentrates on tracing rather than notification. The OPES Communications specification [RFC3897] defines "OPES trace" as application message information about OPES entities that adapted the message. Thus, OPES trace follows the application message it traces. The trace is for the recipient of the application message. Traces are implemented as extensions of application protocols being adapted and traced.
在讨论具体注意事项之前，必须解释IAB通知和OPE跟踪之间的关系。OPES框架专注于跟踪而不是通知。OPES通信规范[RFC3897]将“OPES跟踪”定义为适用于消息的OPES实体的应用消息信息。因此，OPES跟踪跟踪它跟踪的应用程序消息。跟踪针对应用程序消息的收件人。跟踪被实现为正在调整和跟踪的应用程序协议的扩展。
As opposed to an OPES trace, provider notification (as implied by IAB) notifies the sender of the application message rather than the recipient. Thus, notifications propagate in the opposite direction of traces. Supporting notifications directly would require a new protocol. Figure 2 illustrates the differences between a trace and notification from a single application message point of view.
与OPES跟踪不同，提供者通知（由IAB暗示）将应用程序消息通知发送者而不是接收者。因此，通知的传播方向与跟踪方向相反。直接支持通知需要一个新的协议。图2从单个应用程序消息的角度说明了跟踪和通知之间的区别。
sender --[message A]--> OPES --[message A']--> recipient
^ V [with trace]
| |
+-<-- [notification] ---+
sender --[message A]--> OPES --[message A']--> recipient
^ V [with trace]
| |
+-<-- [notification] ---+
Figure 2
图2
Since notifications cannot be piggy-backed to application messages, they create new messages and may double the number of messages the sender has to process. The number of messages that need to be proceed is larger if several intermediaries on the message path generate notifications. Associating notifications with application messages may require duplicating application message information in notifications and may require maintaining a sender state until notification is received. These actions increase the performance overhead of notifications.
由于通知不能被应用程序消息占用，它们会创建新的消息，并且可能使发送者必须处理的消息数量增加一倍。如果消息路径上的多个中介体生成通知，则需要继续处理的消息数量将更大。将通知与应用程序消息关联可能需要在通知中复制应用程序消息信息，并且可能需要在收到通知之前保持发件人状态。这些操作增加了通知的性能开销。
The level of available details in notifications versus provider interest in supporting notification is another concern. Experience shows that content providers often require very detailed information about user actions to be interested in notifications at all. For example, Hit Metering protocol [RFC2227] has been designed to supply content providers with proxy cache hit counts, in an effort to reduce cache busting behavior which was caused by content providers desire to get accurate site "access counts". However, the Hit Metering protocol is currently not widely deployed because the protocol does not supply content providers with information such as client IP addresses, browser versions, or cookies.
通知中可用详细信息的级别与提供商对支持通知的兴趣是另一个问题。经验表明，内容提供商通常需要非常详细的用户操作信息才能对通知感兴趣。例如，命中计量协议[RFC2227]旨在为内容提供商提供代理缓存命中计数，以减少因内容提供商希望获得准确的站点“访问计数”而导致的缓存破坏行为。但是，由于该协议不向内容提供商提供诸如客户端IP地址、浏览器版本或cookie之类的信息，因此当前未广泛部署命中计数协议。
Hit Metering experience is relevant because Hit Metering protocol was designed to do for HTTP caching intermediaries what OPES notifications are meant to do for OPES intermediaries. Performance requirements call for state reduction via aggregation of notifications while provider preferences call for state preservation or duplication. Achieving the right balance when two sides belong to different organizations and have different optimization priorities may be impossible.
命中计量体验是相关的，因为命中计量协议设计用于HTTP缓存中介，就像OPES通知用于OPES中介一样。性能要求要求通过聚合通知来减少状态，而提供程序首选项要求保留或复制状态。当双方属于不同的组织且具有不同的优化优先级时，实现正确的平衡可能是不可能的。
Thus, instead of explicitly supporting notifications at the protocol level, OPES concentrates on tracing facilities. In essence, OPES supports notifications indirectly, using tracing facilities. In other words, the IAB choice of "Notification" label is interpreted as "Notification assistance" (i.e., making notifications meaningful) and is not interpreted as a "Notification protocol".
因此，OPES没有在协议级别明确支持通知，而是将重点放在跟踪设施上。本质上，OPES使用跟踪功能间接支持通知。换句话说，IAB对“通知”标签的选择被解释为“通知协助”（即使通知有意义），而不是解释为“通知协议”。
The above concerns call for making notification optional. The OPES architecture allows for an efficient and meaningful notification protocol to be implemented in certain OPES environments. For example, an OPES callout server attached to a gateway or firewall may scan outgoing traffic for signs of worm or virus activity and notify a local Intrusion Detection System (IDS) of potentially compromised hosts (e.g., servers or client PCs) inside the network. Such notifications may use OPES tracing information to pinpoint the infected host (which could be another OPES entity). In this example, notifications are essentially sent back to the content producer (the local network) and use OPES tracing to supply details.
上述问题要求将通知设置为可选。OPES体系结构允许在某些OPES环境中实施有效且有意义的通知协议。例如，连接到网关或防火墙的OPES callout服务器可能会扫描传出流量以寻找蠕虫或病毒活动的迹象，并通知本地入侵检测系统（IDS）网络内可能受损的主机（例如服务器或客户端PC）。此类通知可能使用OPES跟踪信息来确定受感染主机（可能是另一个OPES实体）。在本例中，通知基本上被发送回内容生产者（本地网络），并使用OPES跟踪来提供详细信息。
Another environment where efficient and meaningful notification using OPES tracing is possible are Content Delivery Networks (CDNs). A CDN node may use multiple content adaptation services to customize generic content supplied by the content producer (a web site). For example, a callout service may insert advertisements for client-local events. The CDN node itself may not understand specifics of the ad insertion algorithm implemented at callout servers. However, the node may use information in the OPES trace (e.g., coming from the callout service) to notify the content producer. Such notifications may be about the number of certain advertisements inserted (i.e., the number of "impressions" delivered to the customer) or even the number of ad "clicks" the customer made (e.g., if the node hosts content linked from the ads). Callout services doing ad insertion may lack details (e.g., a customer ID/address or a web server authentication token) to contact the content producer directly in this case. Thus, OPES trace produced by an OPES service becomes essential in enabling meaningful notifications that the CDN node sends to the content producer.
内容交付网络（CDN）是另一个可以使用OPES跟踪进行高效且有意义的通知的环境。CDN节点可以使用多个内容适配服务来定制由内容生产者（网站）提供的通用内容。例如，调出服务可以为客户端本地事件插入广告。CDN节点本身可能不了解在callout服务器上实现的ad插入算法的细节。然而，节点可以使用OPES跟踪中的信息（例如，来自调出服务）来通知内容生产者。此类通知可以是关于插入的特定广告的数量（即，交付给客户的“印象”的数量）或者甚至是客户所做的广告“点击”的数量（例如，如果节点承载从广告链接的内容）。在这种情况下，进行广告插入的Callout services可能缺少直接联系内容制作者的详细信息（例如，客户ID/地址或web服务器身份验证令牌）。因此，OPES服务生成的OPES跟踪对于启用CDN节点发送给内容生产者的有意义的通知至关重要。
The example below illustrates adaptations done to HTTP request at an OPES processor operated by the client ISP. Both original (as sent by an end user) and adapted (as received by the origin web server) requests are shown. The primary adaptation is the modification of HTTP "Accept" header. The secondary adaptation is the addition of an OPES-System HTTP extension header [I-D.ietf-opes-http].
下面的示例说明了在客户端ISP操作的OPES处理器上对HTTP请求所做的调整。显示原始（由最终用户发送）和改编（由原始web服务器接收）请求。主要的适应是修改HTTP“Accept”头。第二个自适应是添加OPES系统HTTP扩展头[I-D.ietf-OPES-HTTP]。
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
Accept: text/plain
Figure 3
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
Accept: text/plain
Figure 3
... may be adapted by an ISP OPES system to become:
... 可由ISP OPES系统调整为：
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8
OPES-System: http://www.isp-example.com/opes/?client-hash=1234567
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8
OPES-System: http://www.isp-example.com/opes/?client-hash=1234567
Figure 4
图4
The example below illustrates adaptations done to HTTP response at an OPES intermediary operated by a Content Distribution Network (CDN). Both original (as sent by the origin web server) and adapted (as received by the end user) responses are shown. The primary adaptation is the conversion from HTML markup to plain text. The secondary adaptation is the addition of an OPES-System HTTP extension header.
下面的示例说明了在由内容分发网络（CDN）操作的OPES中介对HTTP响应所做的调整。显示原始（由原始web服务器发送）和改编（由最终用户接收）响应。主要的调整是从HTML标记到纯文本的转换。第二个自适应是添加OPES系统HTTP扩展头。
HTTP/1.1 200 OK Content-Length: 12345 Content-Encoding: text/html
HTTP/1.1 200 OK内容长度：12345内容编码：text/html
<html><head><h1>Available Documenta...
<html><head><h1>可用文档。。。
Figure 5
图5
... may be adapted by a CDN OPES system to become:
... 可通过CDN OPES系统调整为：
HTTP/1.1 200 OK
Content-Length: 2345
Content-Encoding: text/plain
OPES-System: http://www.cdn-example.com/opes/?site=7654&svc=h2t
HTTP/1.1 200 OK
Content-Length: 2345
Content-Encoding: text/plain
OPES-System: http://www.cdn-example.com/opes/?site=7654&svc=h2t
AVAILABLE DOCUMENTA... Figure 6
可用文档。。。图6
In the above examples, OPES-System header values contain URIs that may point to OPES-specific documents such as description of the OPES operator and its privacy policy. Those documents may be parameterized to allow for customizations specific to the transaction being traced (e.g., client or even transaction identifier may be used to provide more information about performed adaptations). An OPES-Via header may be used to provide a more detailed trace of specific OPES entities within an OPES System that adapted the message. Traced OPES URIs may be later used to request OPES bypass [RFC3897].
在上述示例中，OPES系统标题值包含URI，这些URI可能指向OPES特定的文档，例如OPES运营商及其隐私策略的描述。这些文档可以参数化，以允许特定于被跟踪事务的定制（例如，可以使用客户端或甚至事务标识符来提供有关执行的调整的更多信息）。通过报头的OPES可用于提供适用于消息的OPES系统内特定OPES实体的更详细跟踪。跟踪的OPES URI可在以后用于请求OPES旁路[RFC3897]。
"The overall OPES framework needs to assist content providers in detecting and responding to client-centric actions by OPES intermediaries that are deemed inappropriate by the content provider" [RFC3238].
“整个OPES框架需要帮助内容提供商检测并响应内容提供商认为不适当的OPES中介机构以客户为中心的行为”[RFC3238]。
OPES tracing mechanisms assist content providers in detecting client-centric actions by OPES intermediaries. Specifically, a compliant OPES intermediary or system notifies a content provider of its presence by including its tracing information in the application protocol requests. An OPES system MUST leave its trace [RFC3897]. Detection assistance has its limitations. Some OPES intermediaries may work exclusively on responses and may not have a chance to trace the request. Moreover, some application protocols may not have explicit requests (e.g., a content push service).
OPES跟踪机制帮助内容提供商检测OPES中介机构以客户端为中心的操作。具体地说，兼容的OPES中介或系统通过在应用协议请求中包含其跟踪信息来通知内容提供商其存在。OPES系统必须保留其跟踪[RFC3897]。检测协助有其局限性。一些OPES中介机构可能只处理响应，可能没有机会跟踪请求。此外，一些应用协议可能没有明确的请求（例如，内容推送服务）。
OPES tracing mechanisms assist content providers in responding to client-centric actions by OPES intermediaries. Specifically, OPES traces MUST include identification of OPES systems and SHOULD include a list of adaptation actions performed on provider's content. This tracing information may be included in the application request. Usually, however, this information will be included in the application response, an adapted version of which does not reach the content provider. If OPES end points cooperate, then notification can be assisted with traces. Content providers that suspect or experience difficulties can do any of the following:
OPES跟踪机制帮助内容提供商响应OPES中介机构以客户为中心的操作。具体而言，OPES跟踪必须包括OPES系统的标识，并应包括对提供商内容执行的适应行动列表。此跟踪信息可能包含在应用程序请求中。但是，通常情况下，这些信息将包含在应用程序响应中，内容提供商不会收到应用程序响应的修改版本。如果OPES端点配合，则可通过跟踪协助通知。怀疑或遇到困难的内容提供商可以执行以下任一操作：
o Check whether requests they receive pass through OPES intermediaries. Presence of OPES tracing info will determine that. This check is only possible for request/response protocols. For other protocols (e.g., broadcast or push), the provider would have to assume that OPES intermediaries are involved until proven otherwise.
o 检查他们收到的请求是否通过OPES中介机构传递。OPES跟踪信息的存在将决定这一点。此检查仅适用于请求/响应协议。对于其他协议（例如，广播或推送），提供商必须假设涉及OPES中介机构，除非另有证明。
o If OPES intermediaries are suspected, request OPES traces from potentially affected user(s). The trace will be a part of the application message received by the user software. If involved parties cooperate, the provider(s) may have access to all the needed information. Certainly, lack of cooperation may hinder access to tracing information. To encourage cooperation, data providers might be able to deny service to uncooperative users.
o 如果怀疑OPES中介，请向可能受影响的用户请求OPES跟踪。跟踪将是用户软件接收到的应用程序消息的一部分。如果相关方进行合作，提供商可以访问所有需要的信息。当然，缺乏合作可能会妨碍获得追踪信息。为了鼓励合作，数据提供商可能会拒绝向不合作的用户提供服务。
o Some traces may indicate that more information is available by accessing certain resources on the specified OPES intermediary or elsewhere. Content providers may query for more information in this case.
o 一些跟踪可能表明，通过访问指定OPES中介或其他地方的某些资源，可以获得更多信息。在这种情况下，内容提供商可以查询更多信息。
o If everything else fails, providers can enforce no-adaptation policy using appropriate OPES bypass mechanisms and/or end-to-end encryption mechanisms.
o 如果其他一切都失败了，提供商可以使用适当的OPES旁路机制和/或端到端加密机制强制执行无适配策略。
OPES detection and response assistance is limited to application protocols with support for tracing extensions. For example, HTTP [RFC2616] has such support while DNS over UDP does not.
OPES检测和响应协助仅限于支持跟踪扩展的应用程序协议。例如，HTTP[RFC2616]有这样的支持，而UDP上的DNS则没有。
"The overall OPES framework should assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries" [RFC3238].
“整个OPES框架应帮助最终用户检测OPES中介机构的行为，潜在地允许他们识别不完善或受损的中介机构”[RFC3238]。
OPES tracing mechanisms assist end users in detecting OPES intermediaries. Specifically, a compliant OPES intermediary or system notifies an end user of its presence by including its tracing information in the application protocol messages sent to the client. An OPES system MUST leave its trace [RFC3897]. However, detection assistance has its limitations. Some OPES systems may work exclusively on requests and may not have a chance to trace the response. Moreover, some application protocols may not have explicit responses (e.g., event logging service).
运营商追踪机制帮助最终用户检测运营商中介机构。具体地说，兼容的OPES中介或系统通过在发送给客户端的应用协议消息中包括其跟踪信息来通知最终用户其存在。OPES系统必须保留其跟踪[RFC3897]。然而，检测辅助有其局限性。一些OPES系统可能只对请求工作，可能没有机会跟踪响应。此外，一些应用程序协议可能没有明确的响应（例如，事件记录服务）。
OPES detection assistance is limited to application protocols with support for tracing extensions. For example, HTTP [RFC2616] has such support while DNS over UDP does not.
OPES检测协助仅限于支持跟踪扩展的应用程序协议。例如，HTTP[RFC2616]有这样的支持，而UDP上的DNS则没有。
"If there exists a "non-OPES" version of content available from the content provider, the OPES architecture must not prevent users from retrieving this "non-OPES" version from the content provider" [RFC3238].
“如果内容提供商提供的内容存在“非OPES”版本，则OPES体系结构不得阻止用户从内容提供商检索此“非OPES”版本”[RFC3238]。
"OPES entities MUST support a bypass feature" [RFC3897]. If an application message includes bypass instructions and an OPES intermediary is not configured to ignore them, the matching OPES intermediary will not process the message. An OPES intermediary may be configured to ignore bypass instructions only if no non-OPES version of content is available. Bypass may generate content errors since some OPES services may be essential but may not be configured as such.
“OPES实体必须支持旁路功能”[RFC3897]。如果应用程序消息包含旁路指令，并且OPES中介未配置为忽略这些指令，则匹配的OPES中介将不会处理该消息。只有在没有非OPES版本的内容可用时，OPES中介才可以配置为忽略旁路指令。旁路可能会产生内容错误，因为某些OPES服务可能是必需的，但可能未按此配置。
Bypass support has limitations similar to the two notification-related considerations above.
旁路支持的限制与上述两个与通知相关的注意事项类似。
"OPES documentation must be clear in describing these services as being applied to the result of URI resolution, not as URI resolution itself" [RFC3238].
“OPES文档必须清楚地描述这些服务应用于URI解析的结果，而不是URI解析本身”[RFC3238]。
"OPES Scenarios and Use Cases" specification [RFC3752] documents content adaptations that are in scope of the OPES framework. Scenarios include content adaptation of requests and responses. These documented adaptations do not include URI resolution. In some environments, it is technically possible to use documented OPES mechanisms to resolve URIs (and other kinds of identifiers or addresses). The OPES framework cannot effectively prevent any specific kind of adaptation.
“OPES场景和用例”规范[RFC3752]记录了OPES框架范围内的内容调整。场景包括请求和响应的内容调整。这些文档化的修改不包括URI解析。在某些环境中，技术上可以使用有文档记录的OPES机制来解析URI（以及其他类型的标识符或地址）。OPES框架无法有效阻止任何特定类型的适应。
For example, a CDN node may substitute domain names in URLs with CDN-chosen IP addresses, essentially performing a URI resolution on behalf of the content producer (i.e., the web site owner). An OPES callout service running on a user PC may rewrite all HTML-embedded advertisement URLs to point to a user-specified local image, essentially performing a URI redirection on behalf of the content consumer (i.e., the end user). Such URI manipulations are outside of the OPES framework scope, but cannot be effectively eliminated from the real world.
例如，CDN节点可以用CDN选择的IP地址替换url中的域名，基本上代表内容生产者（即网站所有者）执行URI解析。在用户PC上运行的OPES callout服务可以重写所有嵌入HTML的广告url以指向用户指定的本地图像，基本上代表内容消费者（即最终用户）执行URI重定向。这种URI操作超出了OPES框架的范围，但无法从现实世界中有效地消除。
"All proposed services must define their impact on inter- and intra-document reference validity" [RFC3238].
“所有建议的服务必须定义其对文档间和文档内引用有效性的影响”[RFC3238]。
The OPES framework does not propose adaptation services. However, OPES tracing requirements include identification of OPES intermediaries and services (for details, see "Notification" consideration sections in this document). It is required that
OPES框架并未提出适应服务。然而，运营商追踪要求包括运营商中介机构和服务的识别（有关详细信息，请参阅本文件中的“通知”考虑部分）。要求
provided identification can be used to locate information about the OPES intermediaries, including the description of impact on reference validity [RFC3897].
提供的标识可用于定位有关OPES中介机构的信息，包括对参考有效性影响的描述[RFC3897]。
"Any services that cannot be achieved while respecting the above two considerations may be reviewed as potential requirements for Internet application addressing architecture extensions, but must not be undertaken as ad hoc fixes" [RFC3238].
“在遵守上述两个考虑因素的情况下无法实现的任何服务都可以作为Internet应用程序寻址体系结构扩展的潜在要求进行审查，但不得作为临时修复进行”[RFC3238]。
OPES framework does not contain ad hoc fixes. This document in combination with and other OPES documents should be sufficient to inform service creators of IAB considerations. If a service does URI resolution or silently affects document reference validity, the authors are requested to review service impact on Internet application addressing architecture and work within IETF on potential extension requirements. Such actions would be outside of the current OPES framework.
OPES框架不包含临时修复。本文件与其他OPES文件一起应足以告知服务创建者IAB注意事项。如果服务没有URI解析或悄悄地影响文档引用的有效性，则要求作者审查服务对Internet应用程序寻址体系结构的影响，并在IETF内处理潜在的扩展需求。这些行动将不在当前的石油输出国组织框架内。
"The overall OPES framework must provide for mechanisms for end users to determine the privacy policies of OPES intermediaries" [RFC3238].
“整个OPES框架必须为最终用户提供机制，以确定OPES中介机构的隐私政策”[RFC3238]。
OPES tracing mechanisms allow end users to identify OPES intermediaries (for details, see "Notification" consideration sections in this document). It is required that provided identification can be used to locate information about the OPES intermediaries, including their privacy policies.
OPES跟踪机制允许最终用户识别OPES中介机构（有关详细信息，请参阅本文档中的“通知”考虑部分）。要求提供的标识可用于定位有关OPES中介机构的信息，包括其隐私政策。
The term "privacy policy" is not defined in this context (by IAB or OPES working group). OPES tracing mechanisms allow end users and content providers to identify an OPES system and/or intermediaries. It is believed that once an OPES system is identified, it would be possible to locate relevant information about that system, including information relevant to requesters perception of privacy policy or reference validity.
“隐私政策”一词在此上下文中没有定义（由IAB或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
“如果OPES获得特许，OPES工作组还必须明确决定并记录OPES架构是否必须与涉及OPES的会话的一个或多个终端使用的端到端加密兼容。如果OPES与端到端加密兼容，这将有效地确保OPES盒的安全性
restricted to ones that are known, trusted, explicitly addressed at the IP layer, and authorized (by the provision of decryption keys) by at least one of the ends" [RFC3238].
仅限于已知的、受信任的、在IP层显式寻址的、并且（通过提供解密密钥）由至少一端授权的“[RFC3238]。
The above quoted requirement was not explicitly listed as on of the IAB considerations, but still needs to be addressed. The context of the quote implies that the phrase "end-to-end encryption" refers to encryption along all links of the end-to-end path, with the OPES intermediaries as encrypting/decrypting participants or hops (e.g., encryption between the provider and the OPES intermediaries, and between the OPES intermediaries and the client).
上述要求未明确列为IAB考虑因素之一，但仍需解决。引用的上下文意味着短语“端到端加密”是指沿端到端路径的所有链路进行加密，OPES中介作为加密/解密参与者或跃点（例如，提供商和OPES中介之间以及OPES中介和客户端之间的加密）。
Since OPES processors are regular hops on the application protocol path, OPES architecture allows for such encryption, provided the application protocol being adapted supports it. Hop-by-hop encryption would do little good for the overall application message path protection if callout services have to receive unencrypted content. To allow for complete link encryption coverage, OPES callout protocol (OCP) supports encryption of OCP connections between an OPES processor and a callout server via optional (negotiated) transport encryption mechanisms [I-D.ietf-opes-ocp-core].
由于OPES处理器是应用协议路径上的常规跃点，因此OPES体系结构允许进行此类加密，前提是所适应的应用协议支持这种加密。如果调出服务必须接收未加密的内容，逐跳加密对整个应用程序消息路径保护几乎没有好处。为了实现完整的链路加密覆盖，OPES呼叫协议（OCP）支持通过可选（协商）传输加密机制对OPES处理器和呼叫服务器之间的OCP连接进行加密[I-D.ietf-OPES-OCP-core]。
For example, TLS encryption [RFC2817] can be used among HTTP hops (some of which could be OPES processors) and between each OPES processor and a callout server.
例如，TLS加密[RFC2817]可以在HTTP跃点之间（其中一些可能是OPES处理器）以及每个OPES处理器和调用服务器之间使用。
This document does not define any mechanisms that may be subject to security considerations. This document scope is to address specific IAB considerations. Security of OPES mechanisms are discussed in Security Considerations sections of the corresponding OPES framework documents.
本文件未定义任何可能受到安全考虑的机制。本文件的范围旨在说明IAB的具体注意事项。OPES机制的安全在相应OPES框架文件的安全注意事项部分进行了讨论。
For example, OPES tracing mechanisms assist content providers and consumers in protecting content integrity and confidentiality by requiring OPES intermediaries to disclose their presence. Security of the tracing mechanism is discussed in the Security Considerations section of [RFC3897].
例如，OPES跟踪机制通过要求OPES中介机构披露其存在，帮助内容提供商和消费者保护内容完整性和机密性。[RFC3897]的安全注意事项部分讨论了跟踪机制的安全性。
This document may be perceived as a proof of OPES compliance with IAB implied recommendations. However, this document does not introduce any compliance subjects. Compliance of OPES implementations is defined in other OPES documents discussed above.
本文件可被视为OPES符合IAB隐含建议的证明。然而，本文件并未介绍任何合规性主题。上述其他OPES文件中定义了OPES实施的合规性。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[RFC3238]Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB体系结构和政策考虑”，RFC 3238，2002年1月。
[RFC3752] Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H. and R. Penno, "Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios", RFC 3752, April 2004.
[RFC3752]Barbir，A.，Burger，E.，Chen，R.，McHenry，S.，Orman，H.和R.Penno，“开放可插拔边缘服务（OPES）用例和部署场景”，RFC 37522004年4月。
[RFC3835] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.
[RFC3835]Barbir，A.，Penno，R.，Chen，R.，Hofmann，M.，和H.Orman，“开放可插拔边缘服务（OPES）的体系结构”，RFC 3835，2004年8月。
[RFC3897] Barbir, A., "Open Pluggable Edge Services (OPES) Entities and End Points Communication", RFC 3897, September 2004.
[RFC3897]Barbir，A.，“开放可插拔边缘服务（OPES）实体和端点通信”，RFC 3877，2004年9月。
[RFC2227] Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting for HTTP", RFC 2227, October 1997.
[RFC2227]Mogul，J.和P.Leach，“HTTP的简单命中计量和使用限制”，RFC 2227，1997年10月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC2817]Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 28172000年5月。
[I-D.ietf-opes-http] Rousskov, A. and M. Stecher, "HTTP adaptation with OPES", Work in Progress, October 2003.
[I-D.ietf-opes-http]Rousskov，A.和M.Stecher，“http与opes的适应”，正在进行的工作，2003年10月。
[I-D.ietf-opes-ocp-core] Rousskov, A., "OPES Callout Protocol Core", Work in Progress, November 2003.
[I-D.ietf-opes-ocp-core]Rousskov，A.，“opes调用协议核心”，正在进行的工作，2003年11月。
Authors' Addresses
作者地址
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario CA
阿比芭比北电网络公司，加利福尼亚州安大略省内皮恩卡林大道3500号
Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com
Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com
Alex Rousskov The Measurement Factory
亚历克斯·罗斯科夫测量工厂
EMail: rousskov@measurement-factory.com
URI: http://www.measurement-factory.com/
EMail: rousskov@measurement-factory.com
URI: http://www.measurement-factory.com/
Full Copyright Statement
完整版权声明
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编辑功能的资金目前由互联网协会提供。