Network Working Group A. Rousskov
Request for Comments: 4037 The Measurement Factory
Category: Standards Track March 2005
Network Working Group A. Rousskov
Request for Comments: 4037 The Measurement Factory
Category: Standards Track March 2005
Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core
开放可插拔边缘服务（OPES）呼叫协议（OCP）核心
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document specifies the core of the Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: An OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). As defined in this document, the OCP Core consists of application-agnostic mechanisms essential for efficient support of typical adaptations.
本文档指定了开放可插拔边缘服务（OPES）调用协议（OCP）的核心。OCP封送来自其他通信协议的应用程序消息：OPES中介将原始应用程序消息发送到调用服务器；调出服务器将调整后的应用程序消息发送回处理器。OCP的设计考虑了典型的适应任务（例如，病毒和垃圾邮件管理、语言和格式翻译、消息匿名化或广告操纵）。正如本文中所定义的，OCP核心由应用程序无关机制组成，这些机制对于有效支持典型的适应是必不可少的。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. OPES Document Map . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 6
2. Overall Operation . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Initialization . . . . . . . . . . . . . . . . . . . . . 7
2.2. Original Dataflow . . . . . . . . . . . . . . . . . . . 8
2.3. Adapted Dataflow . . . . . . . . . . . . . . . . . . . . 8
2.4. Multiple Application Messages . . . . . . . . . . . . . 9
2.5. Termination . . . . . . . . . . . . . . . . . . . . . . 9
2.6. Message Exchange Patterns . . . . . . . . . . . . . . . 9
2.7. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 10
2.8. Environment . . . . . . . . . . . . . . . . . . . . . . 11
3. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. OPES Document Map . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 6
2. Overall Operation . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Initialization . . . . . . . . . . . . . . . . . . . . . 7
2.2. Original Dataflow . . . . . . . . . . . . . . . . . . . 8
2.3. Adapted Dataflow . . . . . . . . . . . . . . . . . . . . 8
2.4. Multiple Application Messages . . . . . . . . . . . . . 9
2.5. Termination . . . . . . . . . . . . . . . . . . . . . . 9
2.6. Message Exchange Patterns . . . . . . . . . . . . . . . 9
2.7. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 10
2.8. Environment . . . . . . . . . . . . . . . . . . . . . . 11
3. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 12
3.2. Message Rendering . . . . . . . . . . . . . . . . . . . 13
3.3. Message Examples . . . . . . . . . . . . . . . . . . . . 14
3.4. Message Names . . . . . . . . . . . . . . . . . . . . . 15
4. Transactions . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Invalid Input . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Negotiation Phase . . . . . . . . . . . . . . . . . . . 17
6.2. Negotiation Examples . . . . . . . . . . . . . . . . . . 18
7. 'Data Preservation' Optimization . . . . . . . . . . . . . . . 20
8. 'Premature Dataflow Termination' Optimizations . . . . . . . . 21
8.1. Original Dataflow . . . . . . . . . . . . . . . . . . . 22
8.2. Adapted Dataflow . . . . . . . . . . . . . . . . . . . . 23
8.3. Getting Out of the Loop . . . . . . . . . . . . . . . . 24
9. Protocol Element Type Declaration Mnemonic (PETDM) . . . . . . 25
9.1 Optional Parameters . . . . . . . . . . . . . . . . . 27
10. Message Parameter Types . . . . . . . . . . . . . . . . . . . 28
10.1. uri. . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.2. uni. . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.3. size . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.4. offset . . . . . . . . . . . . . . . . . . . . . . . . 29
10.5. percent . . . . . . . . . . . . . . . . . . . . . . . 29
10.6. boolean. . . . . . . . . . . . . . . . . . . . . . . . 30
10.7. xid . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.8. sg-id. . . . . . . . . . . . . . . . . . . . . . . . . 30
10.9. modp. . . . . . . . . . . . . . . . . . . . . . . . . 30
10.10. result. . . . . . . . . . . . . . . . . . . . . . . . 30
10.11. feature . . . . . . . . . . . . . . . . . . . . . . . 32
10.12. features. . . . . . . . . . . . . . . . . . . . . . . 32
10.13. service . . . . . . . . . . . . . . . . . . . . . . . 32
10.14. services. . . . . . . . . . . . . . . . . . . . . . . 33
10.15. Dataflow Specializations. . . . . . . . . . . . . . . 33
11. Message Definitions . . . . . . . . . . . . . . . . . . . . . 33
11.1. Connection Start (CS) . . . . . . . . . . . . . . . . 34
11.2. Connection End (CE) . . . . . . . . . . . . . . . . . 35
11.3. Service Group Created (SGC) . . . . . . . . . . . . . 35
11.4. Service Group Destroyed (SGD) . . . . . . . . . . . . 36
11.5. Transaction Start (TS). . . . . . . . . . . . . . . . 36
11.6. Transaction End (TE). . . . . . . . . . . . . . . . . 36
11.7. Application Message Start (AMS) . . . . . . . . . . . 37
11.8. Application Message End (AME) . . . . . . . . . . . . 37
11.9. Data Use Mine (DUM) . . . . . . . . . . . . . . . . . 38
11.10. Data Use Yours (DUY). . . . . . . . . . . . . . . . . 39
11.11. Data Preservation Interest (DPI). . . . . . . . . . . 39
11.12. Want Stop Receiving Data (DWSR) . . . . . . . . . . . 40
11.13. Want Stop Sending Data (DWSS) . . . . . . . . . . . . 41
11.14. Stop Sending Data (DSS) . . . . . . . . . . . . . . . 41
11.15. Want Data Paused (DWP). . . . . . . . . . . . . . . . 42
3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 12
3.2. Message Rendering . . . . . . . . . . . . . . . . . . . 13
3.3. Message Examples . . . . . . . . . . . . . . . . . . . . 14
3.4. Message Names . . . . . . . . . . . . . . . . . . . . . 15
4. Transactions . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Invalid Input . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Negotiation Phase . . . . . . . . . . . . . . . . . . . 17
6.2. Negotiation Examples . . . . . . . . . . . . . . . . . . 18
7. 'Data Preservation' Optimization . . . . . . . . . . . . . . . 20
8. 'Premature Dataflow Termination' Optimizations . . . . . . . . 21
8.1. Original Dataflow . . . . . . . . . . . . . . . . . . . 22
8.2. Adapted Dataflow . . . . . . . . . . . . . . . . . . . . 23
8.3. Getting Out of the Loop . . . . . . . . . . . . . . . . 24
9. Protocol Element Type Declaration Mnemonic (PETDM) . . . . . . 25
9.1 Optional Parameters . . . . . . . . . . . . . . . . . 27
10. Message Parameter Types . . . . . . . . . . . . . . . . . . . 28
10.1. uri. . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.2. uni. . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.3. size . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.4. offset . . . . . . . . . . . . . . . . . . . . . . . . 29
10.5. percent . . . . . . . . . . . . . . . . . . . . . . . 29
10.6. boolean. . . . . . . . . . . . . . . . . . . . . . . . 30
10.7. xid . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.8. sg-id. . . . . . . . . . . . . . . . . . . . . . . . . 30
10.9. modp. . . . . . . . . . . . . . . . . . . . . . . . . 30
10.10. result. . . . . . . . . . . . . . . . . . . . . . . . 30
10.11. feature . . . . . . . . . . . . . . . . . . . . . . . 32
10.12. features. . . . . . . . . . . . . . . . . . . . . . . 32
10.13. service . . . . . . . . . . . . . . . . . . . . . . . 32
10.14. services. . . . . . . . . . . . . . . . . . . . . . . 33
10.15. Dataflow Specializations. . . . . . . . . . . . . . . 33
11. Message Definitions . . . . . . . . . . . . . . . . . . . . . 33
11.1. Connection Start (CS) . . . . . . . . . . . . . . . . 34
11.2. Connection End (CE) . . . . . . . . . . . . . . . . . 35
11.3. Service Group Created (SGC) . . . . . . . . . . . . . 35
11.4. Service Group Destroyed (SGD) . . . . . . . . . . . . 36
11.5. Transaction Start (TS). . . . . . . . . . . . . . . . 36
11.6. Transaction End (TE). . . . . . . . . . . . . . . . . 36
11.7. Application Message Start (AMS) . . . . . . . . . . . 37
11.8. Application Message End (AME) . . . . . . . . . . . . 37
11.9. Data Use Mine (DUM) . . . . . . . . . . . . . . . . . 38
11.10. Data Use Yours (DUY). . . . . . . . . . . . . . . . . 39
11.11. Data Preservation Interest (DPI). . . . . . . . . . . 39
11.12. Want Stop Receiving Data (DWSR) . . . . . . . . . . . 40
11.13. Want Stop Sending Data (DWSS) . . . . . . . . . . . . 41
11.14. Stop Sending Data (DSS) . . . . . . . . . . . . . . . 41
11.15. Want Data Paused (DWP). . . . . . . . . . . . . . . . 42
11.16. Paused My Data (DPM). . . . . . . . . . . . . . . . . 43
11.17. Want More Data (DWM). . . . . . . . . . . . . . . . . 43
11.18. Negotiation Offer (NO). . . . . . . . . . . . . . . . 44
11.19. Negotiation Response (NR) . . . . . . . . . . . . . . 45
11.20. Ability Query (AQ). . . . . . . . . . . . . . . . . . 46
11.21. Ability Answer (AA) . . . . . . . . . . . . . . . . . 46
11.22. Progress Query (PQ) . . . . . . . . . . . . . . . . . 47
11.23. Progress Answer (PA). . . . . . . . . . . . . . . . . 47
11.24. Progress Report (PR). . . . . . . . . . . . . . . . . 48
12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 48
13. Security Considerations . . . . . . . . . . . . . . . . . . . 48
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
15. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 50
15.1. Extending OCP Core . . . . . . . . . . . . . . . . . . 51
A. Message Summary . . . . . . . . . . . . . . . . . . . . . . . 52
B. State Summary . . . . . . . . . . . . . . . . . . . . . . . 53
C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
16.1. Normative References . . . . . . . . . . . . . . . . . 54
16.2. Informative References . . . . . . . . . . . . . . . . 54
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 55
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 56
11.16. Paused My Data (DPM). . . . . . . . . . . . . . . . . 43
11.17. Want More Data (DWM). . . . . . . . . . . . . . . . . 43
11.18. Negotiation Offer (NO). . . . . . . . . . . . . . . . 44
11.19. Negotiation Response (NR) . . . . . . . . . . . . . . 45
11.20. Ability Query (AQ). . . . . . . . . . . . . . . . . . 46
11.21. Ability Answer (AA) . . . . . . . . . . . . . . . . . 46
11.22. Progress Query (PQ) . . . . . . . . . . . . . . . . . 47
11.23. Progress Answer (PA). . . . . . . . . . . . . . . . . 47
11.24. Progress Report (PR). . . . . . . . . . . . . . . . . 48
12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 48
13. Security Considerations . . . . . . . . . . . . . . . . . . . 48
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
15. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 50
15.1. Extending OCP Core . . . . . . . . . . . . . . . . . . 51
A. Message Summary . . . . . . . . . . . . . . . . . . . . . . . 52
B. State Summary . . . . . . . . . . . . . . . . . . . . . . . 53
C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
16.1. Normative References . . . . . . . . . . . . . . . . . 54
16.2. Informative References . . . . . . . . . . . . . . . . 54
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 55
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 56
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服务）。考虑中的应用程序服务分析并可能转换数据提供者和数据使用者之间交换的应用程序级消息。
The OPES processor can delegate the responsibility of service execution by communicating with callout servers. As described in [RFC3836], an OPES processor invokes and communicates with services on a callout server by using an OPES callout protocol (OCP). This document specifies the core of that protocol ("OCP Core").
OPES处理器可以通过与调出服务器通信来委派服务执行的责任。如[RFC3836]所述，OPES处理器通过使用OPES调用协议（OCP）调用调用服务器上的服务并与之通信。本文件规定了该协议的核心（“OCP核心”）。
The OCP Core specification documents general application-independent protocol mechanisms. A separate series of documents describes application-specific aspects of OCP. For example, "HTTP Adaptation with OPES" [OPES-HTTP] describes, in part, how HTTP messages and HTTP meta-information can be communicated over OCP.
OCP核心规范记录了通用的独立于应用程序的协议机制。一系列单独的文档描述了OCP的应用程序特定方面。例如，“HTTP与OPES的适配”[OPES-HTTP]部分描述了如何通过OCP传递HTTP消息和HTTP元信息。
Section 1.2 provides a brief overview of the entire OPES document collection, including documents describing OPES use cases and security threats.
第1.2节简要概述了整个OPES文档集合，包括描述OPES用例和安全威胁的文档。
The OCP Core specification documents the behavior of OCP agents and the requirements for OCP extensions. OCP Core does not contain requirements or mechanisms specific for application protocols being adapted.
OCP核心规范记录了OCP代理的行为和OCP扩展的需求。OCP核心不包含特定于正在调整的应用程序协议的要求或机制。
As an application proxy, the OPES processor proxies a single application protocol or converts from one application protocol to another. At the same time, OPES processor may be an OCP client, using OCP to facilitate adaptation of proxied messages at callout servers. It is therefore natural to assume that an OPES processor takes application messages being proxied, marshals them over OCP to callout servers, and then puts the adaptation results back on the wire. However, this assumption implies that OCP is applied directly to application messages that OPES processor is proxying, which may not be the case.
作为应用程序代理，OPES处理器代理单个应用程序协议或从一个应用程序协议转换为另一个应用程序协议。同时，OPES处理器可以是OCP客户端，使用OCP促进调出服务器上代理消息的自适应。因此，很自然地假设OPES处理器接收被代理的应用程序消息，通过OCP将它们封送到callout服务器，然后将适配结果放回线路上。然而，这种假设意味着OCP直接应用于OPES处理器代理的应用程序消息，情况可能并非如此。
OPES processor scope callout server scope
+-----------------+ +-----------------+
| pre-processing | OCP scope | |
| +- - - - - - - - - - - - - - - - - - -+ |
| iteration | <== ( application data ) ==> | adaptation |
| +- - - - - - - - - - - - - - - - - - -+ |
| post-processing | | |
+-----------------+ +-----------------+
OPES processor scope callout server scope
+-----------------+ +-----------------+
| pre-processing | OCP scope | |
| +- - - - - - - - - - - - - - - - - - -+ |
| iteration | <== ( application data ) ==> | adaptation |
| +- - - - - - - - - - - - - - - - - - -+ |
| post-processing | | |
+-----------------+ +-----------------+
An OPES processor may preprocess (or postprocess) proxied application messages before (or after) they are adapted at callout servers. For example, a processor may take an HTTP response being proxied and pass it as-is, along with metadata about the corresponding HTTP connection. Another processor may take an HTTP response, extract its body, and pass that body along with the content-encoding metadata. Moreover, to perform adaptation, the OPES processor may execute several callout services, iterating over several callout servers. Such preprocessing, postprocessing, and iterations make it impossible to rely on any specific relationship between application messages being proxied and application messages being sent to a callout service. Similarly, specific adaptation actions at the callout server are outside OCP Core scope.
OPES处理器可以在调出服务器调整代理应用程序消息之前（或之后）对其进行预处理（或后处理）。例如，处理器可以接受被代理的HTTP响应并按原样传递它，以及关于相应HTTP连接的元数据。另一个处理器可以接收HTTP响应，提取其正文，并将该正文和内容编码元数据一起传递。此外，为了执行自适应，OPES处理器可以执行多个调用服务，在多个调用服务器上迭代。这样的预处理、后处理和迭代使得不可能依赖被代理的应用程序消息和被发送到调用服务的应用程序消息之间的任何特定关系。同样，callout服务器上的特定自适应操作也不在OCP核心范围内。
This specification does not define or require any specific relationship among application messages being proxied by an OPES processor and application messages being exchanged between an OPES processor and a callout server via OCP. The OPES processor usually provides some mapping among these application messages, but the processor's specific actions are beyond OCP scope. In other words, this specification is not concerned with the OPES processor role as
本规范不定义或要求由OPES处理器代理的应用程序消息与通过OCP在OPES处理器和调出服务器之间交换的应用程序消息之间存在任何特定关系。OPES处理器通常在这些应用程序消息之间提供一些映射，但处理器的特定操作超出了OCP范围。换句话说，本规范与OPES处理器角色无关
an application proxy or as an iterator of callout services. The scope of OCP Core is communication between a single OPES processor and a single callout server.
应用程序代理或调用服务的迭代器。OCP核心的范围是单个OPES处理器和单个调用服务器之间的通信。
Furthermore, an OPES processor may choose which proxied application messages or information about them to send over OCP. All proxied messages on all proxied connections (if connections are defined for a given application protocol), everything on some connections, selected proxied messages, or nothing might be sent over OCP to callout servers. OPES processor and callout server state related to proxied protocols can be relayed over OCP as application message metadata.
此外，OPES处理器可以选择通过OCP发送哪些代理应用程序消息或关于它们的信息。所有代理连接上的所有代理消息（如果为给定的应用程序协议定义了连接）、某些连接上的所有消息、选定的代理消息或任何消息都不能通过OCP发送到callout服务器。与代理协议相关的OPES处理器和callout服务器状态可以作为应用程序消息元数据通过OCP中继。
This document belongs to a large set of OPES specifications produced by the IETF OPES Working Group. Familiarity with the overall OPES approach and typical scenarios is often essential when one tries to comprehend isolated OPES documents. This section provides an index of OPES documents to assist the reader with finding "missing" information.
本文件属于IETF OPES工作组编制的大量OPES规范。当试图理解单独的OPES文档时，熟悉总体OPES方法和典型场景通常是必不可少的。本节提供OPES文档索引，以帮助读者查找“缺失”信息。
o "OPES Use Cases and Deployment Scenarios" [RFC3752] describes a set of services and applications that are considered in scope for OPES and that have been used as a motivation and guidance in designing the OPES architecture.
o “OPES用例和部署场景”[RFC3752]描述了OPES范围内考虑的一组服务和应用程序，这些服务和应用程序已被用作设计OPES体系结构的动机和指导。
o The OPES architecture and common terminology are described in "An Architecture for Open Pluggable Edge Services (OPES)" [RFC3835].
o “开放式可插拔边缘服务（OPES）的体系结构”[RFC3835]中描述了OPES体系结构和通用术语。
o "Policy, Authorization, and Enforcement Requirements of OPES" [RFC3838] outlines requirements and assumptions on the policy framework, without specifying concrete authorization and enforcement methods.
o “OPES的政策、授权和执行要求”[RFC3838]概述了政策框架的要求和假设，但未指定具体的授权和执行方法。
o "Security Threats and Risks for OPES" [RFC3837] provides OPES risk analysis, without recommending specific solutions.
o “运营商的安全威胁和风险”[RFC3837]提供运营商风险分析，但不推荐具体解决方案。
o "OPES Treatment of IAB Considerations" [RFC3914] addresses all architecture-level considerations expressed by the IETF Internet Architecture Board (IAB) when the OPES WG was chartered.
o “OPES对IAB考虑事项的处理”[RFC3914]解决了当OPES工作组获得特许时，IETF互联网体系结构委员会（IAB）表示的所有体系结构级考虑事项。
o At the core of the OPES architecture are the OPES processor and the callout server, two network elements that communicate with each other via an OPES Callout Protocol (OCP). The requirements for this protocol are discussed in "Requirements for OPES Callout Protocols" [RFC3836].
o OPES体系结构的核心是OPES处理器和调出服务器，这两个网络元素通过OPES调出协议（OCP）相互通信。本协议的要求在“OPES标注协议要求”[RFC3836]中讨论。
o This document specifies an application agnostic protocol core to be used for the communication between an OPES processor and a callout server.
o 本文档指定了用于OPES处理器和调用服务器之间通信的应用程序无关协议核心。
o "OPES Entities and End Points Communications" [RFC3897] specifies generic tracing and bypass mechanisms for OPES.
o “运营商实体和端点通信”[RFC3897]规定了运营商的通用跟踪和旁路机制。
o The OCP Core and communications documents are independent from the application protocol being adapted by OPES entities. Their generic mechanisms have to be complemented by application-specific profiles. "HTTP Adaptation with OPES" [OPES-HTTP] is such an application profile for HTTP. It specifies how application-agnostic OPES mechanisms are to be used and augmented in order to support adaptation of HTTP messages.
o OCP核心文件和通信文件独立于OPES实体采用的应用协议。它们的通用机制必须由特定于应用程序的概要文件来补充。“HTTP与OPES的适配”[OPES-HTTP]就是HTTP的应用程序配置文件。它指定如何使用和扩展应用程序无关的OPES机制，以支持HTTP消息的自适应。
o Finally, "P: Message Processing Language" [OPES-RULES] defines a language for specifying what OPES adaptations (e.g., translation) must be applied to what application messages (e.g., e-mail from bob@example.com). P language is intended for configuring application proxies (OPES processors).
o 最后，“P：消息处理语言”[OPES-RULES]定义了一种语言，用于指定必须对哪些应用程序消息（例如，来自bob@example.com). P语言用于配置应用程序代理（OPES处理器）。
In this document, 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 [RFC2119]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase constitute normal prose usage, with no normative implications.
在本文件中，本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。当和规范含义一起使用时，这些关键字将全部大写。这些单词以小写形式出现构成了正常的散文用法，没有任何规范含义。
The OPES processor works with messages from application protocols and may relay information about those application messages to a callout server. OCP is also an application protocol. Thus, protocol elements such as "message", "connection", or "transaction" exist in OCP and other application protocols. In this specification, all references to elements from application protocols other than OCP are used with an explicit "application" qualifier. References without the "application" qualifier refer to OCP elements.
OPES处理器处理来自应用程序协议的消息，并可能将有关这些应用程序消息的信息中继到调出服务器。OCP也是一种应用协议。因此，诸如“消息”、“连接”或“事务”之类的协议元素存在于OCP和其他应用程序协议中。在本规范中，除了OCP之外，对来自应用程序协议的元素的所有引用都与显式的“应用程序”限定符一起使用。没有“application”限定符的引用引用OCP元素。
OCP message: A basic unit of communication between an OPES processor and a callout server. The message is a sequence of octets formatted according to syntax rules (section 3.1). Message semantics is defined in section 11.
OCP消息：OPES处理器和调用服务器之间的基本通信单元。消息是根据语法规则格式化的八位字节序列（第3.1节）。第11节定义了消息语义。
application message: An entity defined by OPES processor and callout server negotiation. Usually, the negotiated definition would match the definition from an application protocol (e.g., [RFC2616] definition of an HTTP message).
应用程序消息：由OPES处理器和调用服务器协商定义的实体。通常，协商定义将与应用程序协议的定义相匹配（例如，HTTP消息的[RFC2616]定义）。
application message data: An opaque sequence of octets representing a complete or partial application message. OCP Core does not distinguish application message structures (if there are any). Application message data may be empty.
应用程序消息数据：表示完整或部分应用程序消息的不透明八位字节序列。OCP核心不区分应用程序消息结构（如果有）。应用程序消息数据可能为空。
data: Same as application message data.
数据：与应用程序消息数据相同。
original: Referring to an application message flowing from the OPES processor to a callout server.
原始：指从OPES处理器流向调用服务器的应用程序消息。
adapted: Referring to an application message flowing from an OPES callout server to the OPES processor.
自适应：指从OPES调出服务器流向OPES处理器的应用程序消息。
adaptation: Any kind of access by a callout server, including modification, generation, and copying. For example, translating or logging an SMTP message is adaptation of that application message.
自适应：调用服务器的任何访问，包括修改、生成和复制。例如，翻译或记录SMTP消息就是对该应用程序消息的改编。
agent: The actor for a given communication protocol. The OPES processor and callout server are OCP agents. An agent can be referred to as a sender or receiver, depending on its actions in a particular context.
代理：给定通信协议的参与者。OPES处理器和callout服务器是OCP代理。代理可以称为发送方或接收方，具体取决于其在特定上下文中的操作。
immediate: Performing the specified action before reacting to new incoming messages or sending any new messages unrelated to the specified action.
立即：在对新传入消息作出反应或发送与指定操作无关的任何新消息之前，执行指定操作。
OCP extension: A specification extending or adjusting this document for adaptation of an application protocol (a.k.a., application profile; e.g., [OPES-HTTP]), new OCP functionality (e.g., transport encryption and authentication), and/or new OCP Core version.
OCP扩展：扩展或调整本文件的规范，以适应应用程序协议（又称应用程序配置文件；如[OPES-HTTP]）、新的OCP功能（如传输加密和认证）和/或新的OCP核心版本。
The OPES processor may use the OPES callout protocol (OCP) to communicate with callout servers. Adaptation using callout services is sometimes called "bump in the wire" architecture.
OPES处理器可使用OPES调出协议（OCP）与调出服务器通信。使用callout services进行的自适应有时被称为“线路中的凹凸”体系结构。
The OPES processor establishes transport connections with callout servers to exchange application messages with the callout server(s) by using OCP. After a transport-layer connection (usually TCP/IP) is established, communicating OCP agents exchange Connection Start (CS) messages. Next, OCP features can be negotiated between the processor and the callout server (see section 6). For example, OCP agents may negotiate transport encryption and application message definition.
OPES处理器与callout服务器建立传输连接，以使用OCP与callout服务器交换应用程序消息。建立传输层连接（通常为TCP/IP）后，通信OCP代理将交换连接启动（CS）消息。接下来，可以在处理器和调出服务器之间协商OCP功能（参见第6节）。例如，OCP代理可以协商传输加密和应用程序消息定义。
When enough settings are negotiated, OCP agents may start exchanging application messages.
协商足够的设置后，OCP代理可以开始交换应用程序消息。
OCP Core provides negotiation and other mechanisms for agents to encrypt OCP connections and authenticate each other. OCP Core does not require OCP connection encryption or agent authentication. Application profiles and other OCP extensions may document and/or require these and other security mechanisms. OCP is expected to be used, in part, in closed environments where trust and privacy are established by means external to OCP. Implementations are expected to demand necessary security features via the OCP Core negotiation mechanism, depending on agent configuration and environment.
OCP核心为代理提供协商和其他机制，以加密OCP连接并相互验证。OCP核心不需要OCP连接加密或代理身份验证。应用程序配置文件和其他OCP扩展可能记录和/或需要这些和其他安全机制。OCP预计将部分用于通过OCP外部手段建立信任和隐私的封闭环境中。根据代理配置和环境，实现需要通过OCP核心协商机制提供必要的安全功能。
When the OPES processor wants to adapt an application message, it sends a Transaction Start (TS) message to initiate an OCP transaction dedicated to that application message. The processor then sends an Application Message Start (AMS) message to prepare the callout server for application data that will follow. Once the application message scope is established, application data can be sent to the callout server by using Data Use Mine (DUM) and related OCP message(s). All of these messages correspond to the original dataflow.
当OPES处理器想要调整应用程序消息时，它发送事务开始（TS）消息以启动专用于该应用程序消息的OCP事务。然后，处理器发送应用程序消息开始（AMS）消息，为调用服务器准备随后的应用程序数据。建立应用程序消息范围后，可以使用data Use Mine（DUM）和相关OCP消息将应用程序数据发送到callout服务器。所有这些消息都对应于原始数据流。
The callout server receives data and metadata sent by the OPES processor (original dataflow). The callout server analyses metadata and adapts data as it comes in. The server usually builds its version of metadata and responds to the OPES processor with an Application Message Start (AMS) message. Adapted application message data can be sent next, using Data Use Mine (DUM) OCP message(s). The application message is then announced to be "completed" or "closed" by using an Application Message End (AME) message. The transaction may be closed by using a Transaction End (TE) message, as well. All these messages correspond to adapted data flow.
callout server接收OPES处理器发送的数据和元数据（原始数据流）。callout server分析元数据并在数据进入时调整数据。服务器通常构建其元数据版本，并使用应用程序消息开始（AMS）消息响应OPES处理器。接下来可以使用data Use Mine（DUM）OCP消息发送经过调整的应用程序消息数据。然后使用应用程序消息结束（AME）消息宣布应用程序消息“完成”或“关闭”。也可以使用事务结束（TE）消息关闭事务。所有这些消息都对应于适应的数据流。
+---------------+ +-------+
| OPES | == (original data flow) ==> |callout|
| processor | <== (adapted data flow) === |server |
+---------------+ +-------+
+---------------+ +-------+
| OPES | == (original data flow) ==> |callout|
| processor | <== (adapted data flow) === |server |
+---------------+ +-------+
The OPES processor receives the adapted application message sent by the callout server. Other OPES processor actions specific to the application message received are outside scope of this specification.
OPES处理器接收调出服务器发送的自适应应用程序消息。特定于接收到的应用程序消息的其他OPES处理器操作不在本规范的范围内。
OCP Core specifies a transactions interface dedicated to exchanging a single original application message and a single adapted application message. Some application protocols may require multiple adapted versions for a single original application message or even multiple original messages to be exchanged as a part of a single OCP transaction. For example, a single original e-mail message may need to be transformed into several e-mail messages, with one custom message for each recipient.
OCP核心指定了一个事务接口，专用于交换单个原始应用程序消息和单个调整的应用程序消息。一些应用程序协议可能需要针对单个原始应用程序消息或甚至多个原始消息的多个适配版本作为单个OCP事务的一部分进行交换。例如，一封原始电子邮件可能需要转换为多封电子邮件，每个收件人有一封自定义邮件。
OCP extensions MAY document mechanisms for exchanging multiple original and/or multiple adapted application messages within a single OCP transaction.
OCP扩展可以记录用于在单个OCP事务中交换多个原始和/或多个自适应应用程序消息的机制。
Either OCP agent can terminate application message delivery, transaction, or connection by sending an appropriate OCP message. Usually, the callout server terminates adapted application message delivery and the transaction. Premature and abnormal terminations at arbitrary times are supported. The termination message includes a result description.
任何一个OCP代理都可以通过发送适当的OCP消息来终止应用程序消息传递、事务或连接。通常，callout服务器终止应用程序消息传递和事务。支持在任意时间过早和异常终止。终止消息包括结果描述。
In addition to messages carrying application data, OCP agents may also exchange messages related to their configuration, state, transport connections, application connections, etc. A callout server may remove itself from the application message processing loop. A single OPES processor can communicate with many callout servers and vice versa. Though many OCP exchange patterns do not follow a classic client-server model, it is possible to think of an OPES processor as an "OCP client" and of a callout server as an "OCP server". The OPES architecture document [RFC3835] describes configuration possibilities.
除了承载应用程序数据的消息外，OCP代理还可以交换与其配置、状态、传输连接、应用程序连接等相关的消息。调出服务器可以将自身从应用程序消息处理循环中移除。单个OPES处理器可以与多个调用服务器通信，反之亦然。尽管许多OCP交换模式不遵循经典的客户机-服务器模型，但可以将OPES处理器视为“OCP客户机”，将调用服务器视为“OCP服务器”。OPES体系结构文件[RFC3835]描述了配置的可能性。
The following informal rules illustrate relationships between connections, transactions, OCP messages, and application messages:
以下非正式规则说明了连接、事务、OCP消息和应用程序消息之间的关系：
o An OCP agent may communicate with multiple OCP agents. This is outside the scope of this specification.
o 一个OCP代理可以与多个OCP代理通信。这超出了本规范的范围。
o An OPES processor may have multiple concurrent OCP connections to a callout server. Communication over multiple OCP connections is outside the scope of this specification.
o OPES处理器可能有多个到调用服务器的并发OCP连接。通过多个OCP连接进行的通信不在本规范的范围内。
o A connection may carry multiple concurrent transactions. A transaction is always associated with a single connection (i.e., a transaction cannot span multiple concurrent connections).
o 一个连接可以承载多个并发事务。事务始终与单个连接关联（即，一个事务不能跨越多个并发连接）。
o A connection may carry at most one message at a time, including control messages and transaction-related messages. A message is always associated with a single connection (i.e., a message cannot span multiple concurrent connections).
o 一个连接一次最多可以携带一条消息，包括控制消息和与事务相关的消息。消息始终与单个连接关联（即，消息不能跨越多个并发连接）。
o A transaction is a sequence of messages related to application of a given set of callout services to a single application message.
o 事务是与将给定的调用服务集应用于单个应用程序消息相关的一系列消息。
A sequence of transaction messages from an OPES processor to a callout server is called original flow. A sequence of transaction messages from a callout server to an OPES processor is called adapted flow. The two flows may overlap in time.
从OPES处理器到调出服务器的一系列事务消息称为原始流。从调出服务器到OPES处理器的一系列事务消息称为适配流。这两个流可能在时间上重叠。
o In OCP Core, a transaction is associated with a single original and a single adapted application message. OCP Core extensions may extend transaction scope to more application messages.
o 在OCP核心中，事务与单个原始和单个改编的应用程序消息相关联。OCP核心扩展可以将事务范围扩展到更多的应用程序消息。
o An application message (adapted or original) is transferred by using a sequence of OCP messages.
o 通过使用OCP消息序列传输应用程序消息（改编或原始）。
OCP violations, resource limits, external dependencies, and other factors may lead to states in which an OCP agent is not receiving required messages from the other OCP agent. OCP Core defines no messages to address such situations. In the absence of any extension mechanism, OCP agents must implement timeouts for OCP operations. An OCP agent MUST forcefully terminate any OCP connection, negotiation, transaction, etc. that is not making progress. This rule covers both dead- and livelock situations.
OCP冲突、资源限制、外部依赖性和其他因素可能导致OCP代理未从其他OCP代理接收所需消息的状态。OCP核心没有定义任何消息来解决这种情况。在没有任何扩展机制的情况下，OCP代理必须为OCP操作实现超时。OCP代理必须强制终止任何未取得进展的OCP连接、协商、交易等。这条规则包括死锁和活锁两种情况。
In their implementation, OCP agents MAY rely on transport-level or other external timeouts if such external timeouts are guaranteed to happen for a given OCP operation. Depending on the OCP operation, an agent may benefit from "pinging" the other side with a Progress Query (PQ) message before terminating an OCP transaction or connection. The latter is especially useful for adaptations that may take a long time at the callout server before producing any adapted data.
在它们的实现中，OCP代理可能依赖于传输级别或其他外部超时，如果这些外部超时保证在给定OCP操作中发生。根据OCP操作的不同，在终止OCP事务或连接之前，使用进度查询（PQ）消息“ping”另一端可能会使代理受益。后者特别适用于可能需要很长时间才能在调出服务器上生成任何调整数据的调整。
OCP communication is assumed usually to take place over TCP/IP connections on the Internet (though no default TCP port is assigned to OCP in this specification). This does not preclude OCP from being implemented on top of other transport protocols, or on other networks. High-level transport protocols such as BEEP [RFC3080] may be used. OCP Core requires a reliable and message-order-preserving transport. Any protocol with these properties can be used; the mapping of OCP message structures onto the transport data units of the protocol in question is outside the scope of this specification.
OCP通信通常假定通过Internet上的TCP/IP连接进行（尽管在本规范中没有为OCP分配默认TCP端口）。这并不妨碍OCP在其他传输协议之上或在其他网络上实现。可以使用高级传输协议，如BEEP[RFC3080]。OCP核心需要可靠且保持消息顺序的传输。可以使用具有这些属性的任何协议；OCP消息结构到相关协议的传输数据单元的映射不在本规范的范围内。
OCP Core is application agnostic. OCP messages can carry application-specific information as a payload or as application-specific message parameters.
OCP核心与应用程序无关。OCP消息可以作为有效负载或特定于应用程序的消息参数携带特定于应用程序的信息。
OCP Core overhead in terms of extra traffic on the wire is about 100 - 200 octets per small application message. Pipelining, preview, data preservation, and early termination optimizations, as well as as-is encapsulation of application data, make fast exchange of application messages possible.
OCP核心开销在线路上的额外流量方面约为每个小应用程序消息100-200个八位组。流水线、预览、数据保存和提前终止优化，以及应用程序数据的is封装，使应用程序消息的快速交换成为可能。
As defined in section 1.3, an OCP message is a basic unit of communication between an OPES processor and a callout server. A message is a sequence of octets formatted according to syntax rules (section 3.1). Message semantics is defined in section 11. Messages are transmitted on top of OCP transport.
如第1.3节所述，OCP消息是OPES处理器和调出服务器之间的基本通信单元。消息是根据语法规则格式化的八位字节序列（第3.1节）。第11节定义了消息语义。消息在OCP传输之上传输。
OCP messages deal with transport, transaction management, and application data exchange between a single OPES processor and a single callout server. Some messages can be emitted only by an OPES processor; some only by a callout server; and some by both OPES processor and callout server. Some messages require responses (one could call such messages "requests"); some can only be used in response to other messages ("responses"); some may be sent without solicitation; and some may not require a response.
OCP消息处理单个OPES处理器和单个callout服务器之间的传输、事务管理和应用程序数据交换。某些信息只能由OPES处理器发出；有些仅由调用服务器提供；一些由OPES处理器和调出服务器提供。有些消息需要响应（可以将此类消息称为“请求”）；有些只能用于响应其他消息（“响应”）；有些可以不经征求而发送；有些可能不需要回复。
An OCP message consists of a message name followed by optional parameters and a payload. The exact message syntax is defined by the following Augmented Backus-Naur Form (ABNF) [RFC2234]:
OCP消息由消息名称、可选参数和有效负载组成。确切的消息语法由以下扩展的Backus Naur表单（ABNF）[RFC2234]定义：
message = name [SP anonym-parameters]
[CRLF named-parameters CRLF]
[CRLF payload CRLF]
";" CRLF
message = name [SP anonym-parameters]
[CRLF named-parameters CRLF]
[CRLF payload CRLF]
";" CRLF
anonym-parameters = value *(SP value) ; space-separated
named-parameters = named-value *(CRLF named-value) ; CRLF-separated
list-items = value *("," value) ; comma-separated
anonym-parameters = value *(SP value) ; space-separated
named-parameters = named-value *(CRLF named-value) ; CRLF-separated
list-items = value *("," value) ; comma-separated
payload = data
payload = data
named-value = name ":" SP value
命名值=名称“：”SP值
value = structure / list / atom
structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}"
list = "(" [ list-items ] ")"
atom = bare-value / quoted-value
value = structure / list / atom
structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}"
list = "(" [ list-items ] ")"
atom = bare-value / quoted-value
name = ALPHA *safe-OCTET
bare-value = 1*safe-OCTET
quoted-value = DQUOTE data DQUOTE
data = size ":" *OCTET ; exactly size octets
name = ALPHA *safe-OCTET
bare-value = 1*safe-OCTET
quoted-value = DQUOTE data DQUOTE
data = size ":" *OCTET ; exactly size octets
safe-OCTET = ALPHA / DIGIT / "-" / "_"
size = dec-number ; 0-2147483647
dec-number = 1*DIGIT ; no leading zeros or signs
safe-OCTET = ALPHA / DIGIT / "-" / "_"
size = dec-number ; 0-2147483647
dec-number = 1*DIGIT ; no leading zeros or signs
Several normative rules accompany the above ABNF:
上述ABNF随附若干规范性规则：
o There is no "implied linear space" (LWS) rule. LWS rules are common to MIME-based grammars but are not used here. The whitespace syntax is restricted to what is explicitly allowed by the above ABNF.
o 没有“隐含线性空间”（LWS）规则。LWS规则在基于MIME的语法中很常见，但此处不使用。空格语法仅限于上述ABNF明确允许的内容。
o All protocol elements are case sensitive unless it is specified otherwise. In particular, message names and parameter names are case sensitive.
o 除非另有规定，否则所有协议元素都区分大小写。特别是，消息名和参数名区分大小写。
o Sizes are interpreted as decimal values and cannot have leading zeros.
o 大小被解释为十进制值，不能有前导零。
o Sizes do not exceed 2147483647.
o 尺寸不超过2147483647。
o The size attribute in a quoted-value encoding specifies the exact number of octets following the column (':') separator. If size octets are not followed by a quote ('"') character, the encoding is syntactically invalid.
o 引号编码中的size属性指定列（“：”）分隔符后面的八位字节的确切数目。如果大小八位字节后面没有引号（“”）字符，则编码在语法上无效。
o Empty quoted values are encoded as a 4-octet sequence "0:".
o 空引用值被编码为4个八位组的序列“0:”。
o Any bare value can be encoded as a quoted value. A quoted value is interpreted after the encoding is removed. For example, number 1234 can be encoded as four octets 1234 or as eight octets "4:1234", yielding exactly the same meaning.
o 任何裸值都可以编码为带引号的值。删除编码后，将解释带引号的值。例如，数字1234可以编码为四个八位字节1234或八个八位字节“4:1234”，产生完全相同的含义。
o Unicode UTF-8 is the default encoding. Note that ASCII is a UTF-8 subset, and that the syntax prohibits non-ASCII characters outside of the "data" element.
o Unicode UTF-8是默认编码。请注意，ASCII是UTF-8子集，语法禁止“data”元素之外的非ASCII字符。
Messages violating formatting rules are, by definition, invalid. See section 5 for rules governing processing of invalid messages.
根据定义，违反格式规则的邮件无效。有关无效消息处理的规则，请参见第5节。
OCP message samples in this specification and its extensions may not be typeset to depict minor syntactical details of OCP message format. Specifically, SP and CRLF characters are not shown explicitly. No rendering of an OCP message can be used to infer message format. The message format definition above is the only normative source for all implementations.
本规范及其扩展中的OCP消息示例可能不会排版以描述OCP消息格式的次要语法细节。具体而言，SP和CRLF字符不会显式显示。OCP消息的任何呈现都不能用于推断消息格式。上面的消息格式定义是所有实现的唯一标准源。
On occasion, an OCP message line exceeds text width allowed by this specification format. A backslash ("\"), a "soft line break" character, is used to emphasize a protocol-violating presentation-only linebreak. Bare backslashes are prohibited by OCP syntax. Similarly, an "\r\n" string is sometimes used to emphasize the presence of a CRLF sequence, usually before OCP message payload. Normally, the visible end of line corresponds to the CRLF sequence on the wire.
有时，OCP消息行超出此规范格式允许的文本宽度。反斜杠（\）是一个“软换行符”字符，用于强调违反协议的仅表示换行符。OCP语法禁止使用裸反斜杠。类似地，“\r\n”字符串有时用于强调CRLF序列的存在，通常在OCP消息负载之前。通常，线路的可见端对应于导线上的CRLF序列。
The next section (section 3.3) contains specific OCP message examples, some of which illustrate the above rendering techniques.
下一节（第3.3节）包含特定的OCP消息示例，其中一些示例说明了上述渲染技术。
OCP syntax provides for compact representation of short control messages and required parameters while allowing for parameter extensions. Below are examples of short control messages. The required CRLF sequence at the end of each line is not shown explicitly (see section 3.2).
OCP语法提供了短控制消息和所需参数的紧凑表示，同时允许参数扩展。下面是短控制消息的示例。未明确显示每条线路末端所需的CRLF序列（见第3.2节）。
PQ;
TS 1 2;
DWM 22;
DWP 22 16;
x-doit "5:xyzzy";
PQ;
TS 1 2;
DWM 22;
DWP 22 16;
x-doit "5:xyzzy";
The above examples contain atomic anonymous parameter values, such as number and string constants. OCP messages sometimes use more complicated parameters such as item lists or structures with named values. As both messages below illustrate, structures and lists can be nested:
上述示例包含原子匿名参数值，如数字和字符串常量。OCP消息有时使用更复杂的参数，如项目列表或具有命名值的结构。正如下面两条消息所示，结构和列表可以嵌套：
NO ({"32:http://www.iana.org/assignments/opes/ocp/tls"});
NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response"
Optional-Parts: (request-header)
},{"54:http://www.iana.org/assignments/opes/ocp/http/response"
Optional-Parts: (request-header,request-body)
Transfer-Encodings: (chunked)
});
NO ({"32:http://www.iana.org/assignments/opes/ocp/tls"});
NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response"
Optional-Parts: (request-header)
},{"54:http://www.iana.org/assignments/opes/ocp/http/response"
Optional-Parts: (request-header,request-body)
Transfer-Encodings: (chunked)
});
Optional parameters and extensions are possible with a named parameters approach, as illustrated by the following example. The DWM (section 11.17) message in the example has two anonymous parameters (the last one being an extension) and two named parameters (the last one being an extension).
可选参数和扩展可以通过命名参数方法实现，如下例所示。示例中的DWM（第11.17节）消息有两个匿名参数（最后一个是扩展名）和两个命名参数（最后一个是扩展名）。
DWM 1 3 Size-Request: 16384 X-Need-Info: "26:twenty six octet extension";
DWM 1 3尺寸请求：16384 X-Need-Info:“26:二十六个八位组扩展名”；
Finally, any message may have a payload part. For example, the Data Use Mine (DUM) message below carries 8865 octets of raw data.
最后，任何消息都可能具有有效负载部分。例如，下面的Data Use Mine（DUM）消息包含8865个八位字节的原始数据。
DUM 1 13 Modp: 75 \r\n 8865:... 8865 octets of raw data ...;
DUM 1 13 Modp:75\r\n 8865:。。。8865个八位字节的原始数据。。。；
Most OCP messages defined in this specification have short names, formed by abbreviating or compressing a longer but human-friendlier message title. Short names without a central registration system (such as this specification or the IANA registry) are likely to cause conflicts. Informal protocol extensions should avoid short names. To emphasize what is already defined by message syntax, implementations cannot assume that all message names are very short.
本规范中定义的大多数OCP消息都有短名称，通过缩写或压缩较长但更人性化的消息标题形成。没有中央注册系统（如本规范或IANA注册表）的短名称可能会导致冲突。非正式协议扩展应避免使用短名称。为了强调消息语法已经定义的内容，实现不能假设所有消息名称都很短。
An OCP transaction is a logical sequence of OCP messages processing a single original application message. The result of the processing
OCP事务是处理单个原始应用程序消息的OCP消息的逻辑序列。处理结果
may be zero or more application messages, adapted from the original. A typical transaction consists of two message flows: a flow from the OPES processor to the callout server (sending the original application message), and a flow from the callout server to the OPES processor (sending adapted application messages). The number of application messages produced by the callout server and whether the callout server actually modifies the original application message may depend on the requested callout service and other factors. The OPES processor or the callout server can terminate the transaction by sending a corresponding message to the other side.
可以是零条或多条应用程序消息，根据原始消息改编。典型的事务由两个消息流组成：一个是从OPES处理器到调用服务器的消息流（发送原始应用程序消息），另一个是从调用服务器到OPES处理器的消息流（发送调整后的应用程序消息）。调用服务器生成的应用程序消息的数量以及调用服务器是否实际修改了原始应用程序消息可能取决于请求的调用服务和其他因素。OPES处理器或callout server可以通过向另一方发送相应的消息来终止事务。
An OCP transaction starts with a Transaction Start (TS) message sent by the OPES processor. A transaction ends with the first Transaction End (TE) message sent or received, explicit or implied. A TE message can be sent by either side. Zero or more OCP messages associated with the transaction can be exchanged in between. The figure below illustrates a possible message sequence (prefix "P" stands for the OPES processor; prefix "S" stands for the callout server). Some message details are omitted.
OCP事务从OPES处理器发送的事务开始（TS）消息开始。事务以发送或接收的第一个事务结束（TE）消息结束，无论是显式的还是默示的。TE消息可以由任意一方发送。与事务关联的零个或多个OCP消息可以在这两个消息之间交换。下图显示了可能的消息序列（前缀“P”表示OPES处理器；前缀“S”表示调用服务器）。省略了一些消息细节。
P: TS 10;
P: AMS 10 1;
... processor sending application data to the callout server
S: AMS 10 2;
... callout server sending application data to the processor
... processor sending application data to the callout server
P: AME 10 1 result;
S: AME 10 2 result;
P: TE 10 result;
P: TS 10;
P: AMS 10 1;
... processor sending application data to the callout server
S: AMS 10 2;
... callout server sending application data to the processor
... processor sending application data to the callout server
P: AME 10 1 result;
S: AME 10 2 result;
P: TE 10 result;
This specification contains many criteria for valid OCP messages and their parts, including syntax rules, semantics requirements, and relationship to agents state. In this context, "Invalid input" means messages or message parts that violate at least one of the normative rules. A message with an invalid part is, by definition, invalid. If OCP agent resources are exhausted while parsing or interpreting a message, the agent MUST treat the corresponding OCP message as invalid.
该规范包含有效OCP消息及其部分的许多标准，包括语法规则、语义要求以及与代理状态的关系。在此上下文中，“无效输入”指至少违反一条规范性规则的消息或消息部分。根据定义，包含无效部分的消息是无效的。如果在解析或解释消息时OCP代理资源耗尽，则代理必须将相应的OCP消息视为无效。
Unless explicitly allowed to do otherwise, an OCP agent MUST terminate the transaction if it receives an invalid message with transaction scope and MUST terminate the connection if it receives an invalid message with a connection scope. A terminating agent MUST use the result status code of 400 and MAY specify termination cause information in the result status reason parameter (see section 10.10). If an OCP agent is unable to determine the scope of an invalid message it received, the agent MUST treat the message as having connection scope.
除非明确允许执行其他操作，否则OCP代理必须在接收到具有事务作用域的无效消息时终止事务，并且在接收到具有连接作用域的无效消息时必须终止连接。终止代理必须使用结果状态代码400，并可在结果状态原因参数中指定终止原因信息（见第10.10节）。如果OCP代理无法确定其收到的无效消息的范围，则该代理必须将该消息视为具有连接范围。
OCP usually deals with optional but invasive application message manipulations for which correctness ought to be valued above robustness. For example, a failure to insert or remove certain optional web page content is usually far less disturbing than corrupting (making unusable) the host page while performing that insertion or removal. Most OPES adaptations are high level in nature, which makes it impossible to assess correctness of the adaptations automatically, especially if "robustness guesses" are involved.
OCP通常处理可选但具有侵入性的应用程序消息操作，其正确性应高于健壮性。例如，插入或删除某些可选网页内容的失败通常比在执行插入或删除操作时损坏（使其无法使用）主机页更令人不安。大多数OPE自适应本质上是高水平的，这使得不可能自动评估自适应的正确性，特别是在涉及“鲁棒性猜测”的情况下。
The negotiation mechanism allows OCP agents to agree on the mutually acceptable set of features, including optional and application-specific behavior and OCP extensions. For example, transport encryption, data format, and support for a new message can be negotiated. Negotiation implies intent for a behavioral change. For a related mechanism allowing an agent to query capabilities of its counterpart without changing the counterpart's behavior, see the Ability Query (AQ) and Ability Answer (AA) message definitions.
协商机制允许OCP代理就双方可以接受的特性集达成一致，包括可选的和特定于应用程序的行为以及OCP扩展。例如，可以协商传输加密、数据格式和对新消息的支持。谈判意味着行为改变的意图。有关允许代理在不更改对方行为的情况下查询其对方能力的相关机制，请参阅能力查询（AQ）和能力应答（AA）消息定义。
Most negotiations require at least one round trip time delay. In rare cases when the other side's response is not required immediately, negotiation delay can be eliminated, with an inherent risk of an overly optimistic assumption about the negotiation response.
大多数谈判至少需要一次往返时间延迟。在极少数情况下，当不需要对方立即作出回应时，可以消除谈判延迟，这会带来对谈判回应过于乐观的固有风险。
A detected violation of negotiation rules leads to OCP connection termination. This design reduces the number of negotiation scenarios resulting in a deadlock when one of the agents is not compliant.
检测到违反协商规则会导致OCP连接终止。这种设计减少了当其中一个代理不兼容时导致死锁的协商场景的数量。
Two core negotiation primitives are supported: negotiation offer and negotiation response. A Negotiation Offer (NO) message allows an agent to specify a set of features from which the responder has to select at most one feature that it prefers. The selection is sent by using a Negotiation Response (NR) message. If the response is positive, both sides assume that the selected feature is in effect immediately (see section 11.19 for details). If the response is negative, no behavioral changes are assumed. In either case, further offers may follow.
支持两个核心协商原语：协商提议和协商响应。协商报价（NO）消息允许代理指定一组功能，响应者必须从中最多选择一个自己喜欢的功能。通过使用协商响应（NR）消息发送选择。如果回答是肯定的，双方都认为所选特征立即生效（详情见第11.19节）。如果回答是否定的，则假设没有行为变化。在这两种情况下，可能会有进一步的报价。
Negotiating OCP agents have to take into account prior negotiated (i.e., already enabled) features. OCP agents MUST NOT make and MUST reject offers that would lead to a conflict with already negotiated features. For example, an agent cannot offer an HTTP application profile for a connection that already has an SMTP application profile enabled, as there would be no way to resolve the conflict for a given transaction. Similarly, once TLSv1 connection encryption is negotiated, an agent must not offer and must reject offers for SSLv2 connection encryption (unless a negotiated feature explicitly allows for changing an encryption scheme on the fly).
协商OCP代理必须考虑事先协商（即已启用）的功能。OCP代理不得做出或拒绝可能导致与已协商功能冲突的报价。例如，代理无法为已启用SMTP应用程序配置文件的连接提供HTTP应用程序配置文件，因为无法解决给定事务的冲突。类似地，一旦协商TLSv1连接加密，代理就不能提供也必须拒绝SSLv2连接加密（除非协商功能明确允许动态更改加密方案）。
Negotiation Offer (NO) messages may be sent by either agent. OCP extensions documenting negotiation MAY assign the initiator role to one of the agents, depending on the feature being negotiated. For example, negotiation of transport security feature should be initiated by OPES processors to avoid situations where both agents wait for the other to make an offer.
谈判报价（NO）消息可由任一代理发送。记录协商的OCP扩展可能会将发起人角色分配给其中一个代理，具体取决于正在协商的功能。例如，运输安全功能的协商应由OPES处理方发起，以避免两个代理都等待另一方报价的情况。
As either agent may make an offer, two "concurrent" offers may be made at the same time, by the two communicating agents. Unmanaged concurrent offers may lead to a negotiation deadlock. By giving OPES processor a priority, offer-handling rules (section 11.18) ensure that only one offer per OCP connection is honored at a time, and that the other concurrent offers are ignored by both agents.
由于任一代理都可以发出要约，两个通信代理可以同时发出两个“并发”要约。非托管并发报价可能导致协商死锁。通过给予OPES处理器优先权，要约处理规则（第11.18节）确保每个OCP连接一次只接受一个要约，并且其他并发要约被两个代理忽略。
A Negotiation Phase is a mechanism ensuring that both agents have a chance to negotiate all features they require before proceeding further. Negotiation Phases have OCP connection scope and do not overlap. For each OCP agent, the Negotiation Phase starts with the first Negotiation Offer (NO) message received or the first Negotiation Response (NR) message sent, provided the message is not a part of an existing Phase. For each OCP agent, Negotiation Phase
协商阶段是一种机制，确保两个代理在继续之前都有机会协商他们所需的所有功能。协商阶段具有OCP连接范围，且不重叠。对于每个OCP代理，如果消息不是现有阶段的一部分，则协商阶段从接收到的第一条协商要约（NO）消息或发送的第一条协商响应（NR）消息开始。对于每个OCP代理，协商阶段
ends with the first Negotiation Response (NR) message (sent or received), after which the agent expects no more negotiations. Agent expectation rules are defined later in this section.
以第一条协商响应（NR）消息（已发送或已接收）结束，之后代理不希望再进行协商。本节后面将定义代理期望规则。
During a Negotiation Phase, an OCP agent MUST NOT send messages other than the following "Negotiation Phase messages": Negotiation Offer (NO), Negotiation Response (NR), Ability Query (AQ), Ability Answer (AA), Progress Query (PQ), Progress Answer (PA), Progress Report (PR), and Connection End (CE).
在协商阶段，OCP代理不得发送以下“协商阶段消息”以外的消息：协商报价（NO）、协商响应（NR）、能力查询（AQ）、能力应答（AA）、进度查询（PQ）、进度应答（PA）、进度报告（PR）和连接结束（CE）。
Multiple Negotiation Phases may happen during the lifespan of a single OCP connection. An agent may attempt to start a new Negotiation Phase immediately after the old Phase is over, but it is possible that the other agent will send messages other than "Negotiation Phase messages" before receiving the new Negotiation Offer (NO). The agent that starts a Phase has to be prepared to handle those messages while its offer is reaching the recipient.
在单个OCP连接的生命周期内，可能会发生多个协商阶段。代理可以在旧阶段结束后立即尝试启动新的协商阶段，但另一个代理可能会在收到新的协商要约（否）之前发送“协商阶段消息”以外的消息。开始阶段的代理必须准备在其报价到达收件人时处理这些邮件。
An OPES processor MUST make a negotiation offer immediately after sending a Connection Start (CS) message. If the OPES processor has nothing to negotiate, the processor MUST send a Negotiation Offer (NO) message with an empty features list. These two rules bootstrap the first Negotiation Phase. Agents are expected to negotiate at least the application profile for OCP Core. Thus, these bootstrapping requirements are unlikely to result in any extra work.
OPES处理器必须在发送连接启动（CS）消息后立即发出协商要约。如果OPES处理方无需协商，则处理方必须发送带有空功能列表的协商报价（NO）消息。这两条规则引导了第一个协商阶段。代理应至少协商OCP核心的应用程序配置文件。因此，这些引导需求不太可能导致任何额外的工作。
Once a Negotiation Phase starts, an agent MUST expect further negotiations if and only if the last NO sent or the last NR received contained a true "Offer-Pending" parameter value. Informally, an agent can keep the phase open by sending true "Offer-Pending" parameters with negotiation offers or responses. Moreover, if there is a possibility that the agent may need to continue the Negotiation Phase, the agent must send a true "Offer-Pending" parameter.
一旦协商阶段开始，当且仅当最后一次发送的NO或最后一次接收的NR包含真实的“Offer Pending”参数值时，代理必须期望进一步协商。非正式地说，代理可以通过发送真实的“Offer Pending”参数和谈判报价或响应来保持阶段的开放性。此外，如果代理可能需要继续协商阶段，则代理必须发送一个真正的“Offer Pending”参数。
Below is an example of the simplest negotiation possible. The OPES processor is offering nothing and is predictably receiving a rejection. Note that the NR message terminates the Negotiation Phase in this case because neither of the messages contains a true "Offer-Pending" value:
下面是一个最简单的谈判示例。OPES处理器什么也不提供，可以预见会遭到拒绝。注意，在这种情况下，NR消息终止协商阶段，因为两条消息都不包含真正的“Offer Pending”值：
P: NO ();
S: NR;
P: NO ();
S: NR;
The next example illustrates how a callout server can force negotiation of a feature that an OPES processor has not negotiated. Note that the server sets the "Offer-Pending" parameter to true when
下一个示例说明调用服务器如何强制协商OPES处理器尚未协商的功能。请注意，服务器在以下情况下将“Offer Pending”参数设置为true：
responding to the processor Negotiation Offer (NO) message. The processor chooses to accept the feature:
响应处理器协商报价（否）消息。处理器选择接受该功能：
P: NO ();
S: NR
Offer-Pending: true
;
S: NO ({"22:ocp://feature/example/"})
Offer-Pending: false
;
P: NR {"22:ocp://feature/example/"};
P: NO ();
S: NR
Offer-Pending: true
;
S: NO ({"22:ocp://feature/example/"})
Offer-Pending: false
;
P: NR {"22:ocp://feature/example/"};
If the server seeks to stop the above negotiations after sending a true "Offer-Pending" value, its only option would be send an empty negotiation offer (see the first example above). If the server does nothing instead, the OPES processor would wait for the server and would eventually time out the connection.
如果服务器在发送真实的“Offer Pending”值后试图停止上述协商，则其唯一选项将是发送一个空的协商要约（请参见上面的第一个示例）。如果服务器什么也不做，OPES处理器将等待服务器，并最终使连接超时。
The following example shows a dialog with a callout server that insists on enabling two imaginary features: strong transport encryption and volatile storage for responses. The server is designed not to exchange sensitive messages until both features are enabled. Naturally, the volatile storage feature has to be negotiated securely. The OPES processor supports one of the strong encryption mechanisms but prefers not to offer (to volunteer support for) strong encryption, perhaps for performance reasons. The server has to send a true "Offer-Pending" parameter to get a chance to offer strong encryption (which is successfully negotiated in this case). Any messages sent by either agent after the (only) successful NR response are encrypted with "strongB" encryption scheme. The OPES processor does not understand the volatile storage feature, and the last negotiation fails (over a strongly encrypted transport connection).
下面的示例显示了一个带有callout服务器的对话框，该服务器坚持启用两个虚构的功能：强传输加密和响应的易失性存储。服务器设计为在启用这两个功能之前不交换敏感消息。当然，必须安全地协商易失性存储功能。OPES处理器支持一种强加密机制，但不愿意提供（自愿支持）强加密，可能是出于性能原因。服务器必须发送一个真正的“Offer Pending”参数，以获得提供强加密的机会（在本例中已成功协商）。在（唯一）成功的NR响应之后，任一代理发送的任何消息都使用“strongB”加密方案进行加密。OPES处理器不了解易失性存储功能，最后一次协商失败（通过强加密的传输连接）。
P: NO ({"29:ocp://example/encryption/weak"})
;
S: NR
Offer-Pending: true
;
S: NO ({"32:ocp://example/encryption/strongA"},\
{"32:ocp://example/encryption/strongB"})
Offer-Pending: true
;
P: NR {"32:ocp://example/encryption/strongB"}
;
... all traffic below is encrypted using strongB ...
P: NO ({"29:ocp://example/encryption/weak"})
;
S: NR
Offer-Pending: true
;
S: NO ({"32:ocp://example/encryption/strongA"},\
{"32:ocp://example/encryption/strongB"})
Offer-Pending: true
;
P: NR {"32:ocp://example/encryption/strongB"}
;
... all traffic below is encrypted using strongB ...
S: NO ({"31:ocp://example/storage/volatile"})
Offer-Pending: false
;
P: NR
Unknowns: ({"31:ocp://example/storage/volatile"})
;
S: CSE { 400 "33:lack of VolStore protocol support" }
;
S: NO ({"31:ocp://example/storage/volatile"})
Offer-Pending: false
;
P: NR
Unknowns: ({"31:ocp://example/storage/volatile"})
;
S: CSE { 400 "33:lack of VolStore protocol support" }
;
The following example from [OPES-HTTP] illustrates successful HTTP application profile negotiation:
[OPES-HTTP]中的以下示例说明了成功的HTTP应用程序配置文件协商：
P: NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header,request-body)
})
SG: 5;
S: NR {"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header)
Pause-At-Body: 30
Wont-Send-Body: 2147483647
Content-Encodings: (gzip)
}
SG: 5;
P: NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header,request-body)
})
SG: 5;
S: NR {"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header)
Pause-At-Body: 30
Wont-Send-Body: 2147483647
Content-Encodings: (gzip)
}
SG: 5;
Many adaptations do not require any data modifications (e.g., message logging or blocking). Some adaptations modify only a small portion of application message content (e.g., HTTP cookies filtering or ad insertion). Yet, in many cases, the callout service has to see complete data. By default, unmodified data would first travel from the OPES processor to the callout server and then back. The "data preservation" optimization in OCP helps eliminate the return trip if both OCP agents cooperate. Such cooperation is optional: OCP agents MAY support data preservation optimization.
许多自适应不需要任何数据修改（例如，消息记录或阻塞）。一些修改仅修改应用程序消息内容的一小部分（例如，HTTP Cookie过滤或广告插入）。然而，在许多情况下，调用服务必须查看完整的数据。默认情况下，未修改的数据将首先从OPES处理器传输到callout服务器，然后再返回。OCP中的“数据保存”优化有助于消除两个OCP代理协作时的回程。这种合作是可选的：OCP代理可以支持数据保存优化。
To avoid sending back unmodified data, a callout service has to know that the OPES processor has a copy of the data. As data sizes can be very large and the callout service may not know in advance whether it will be able to use the processor copy, it is not possible to require the processor to keep a copy of the entire original data. Instead, it is expected that a processor may keep some portion of the data, depending on processor settings and state.
为了避免发回未修改的数据，调出服务必须知道OPES处理器有数据的副本。由于数据大小可能非常大，而且调出服务可能事先不知道是否能够使用处理器副本，因此不可能要求处理器保留整个原始数据的副本。相反，根据处理器设置和状态，处理器可能保留部分数据。
When an OPES processor commits to keeping a data chunk, it announces its decision and the chunk parameters via a Kept parameter of a Data Use Mine (DUM) message. The callout server MAY "use" the chunk by sending a Data Use Yours (DUY) message referring to the preserved
当OPES处理器承诺保留数据块时，它通过数据使用挖掘（DUM）消息的保留参数宣布其决策和块参数。调出服务器可以通过发送一条数据使用您的（DUY）消息来“使用”区块，该消息引用保留的区块
chunk. That OCP message does not have payload and, therefore, the return trip is eliminated.
大块该OCP消息没有有效载荷，因此回程被消除。
As the mapping between original and adapted data is not known to the processor, the processor MUST keep the announced-as-preserved chunk until the end of the corresponding transaction, unless the callout server explicitly tells the processor that the chunk is not needed. As implied by the above requirement, the processor cannot assume that a data chunk is no longer needed just because the callout server sent a Data Use Yours (DUY) message or adapted data with, for instance, the same offset as the preserved chunk.
由于处理器不知道原始数据和调整数据之间的映射，因此处理器必须将宣布为保留的区块保留到相应事务结束，除非调出服务器明确告诉处理器不需要该区块。正如上述要求所暗示的，处理器不能仅仅因为调出服务器发送了数据使用您的（DUY）消息或调整的数据（例如，偏移量与保留的数据块相同），就认为不再需要数据块。
For simplicity, preserved data is always a contiguous chunk of original data, described by an (offset, size) pair using a "Kept" parameter of a Data Use Mine (DUM) message. An OPES processor may volunteer to increase the size of the kept data. An OPES processor may increase the offset if the callout server indicated that the kept data is no longer needed.
为简单起见，保留的数据始终是原始数据的连续块，由（偏移量、大小）对使用数据使用挖掘（DUM）消息的“保留”参数来描述。OPES处理器可能自愿增加保存数据的大小。如果调出服务器指示不再需要保留的数据，则OPES处理器可能会增加偏移量。
Both agents may benefit from data reuse. An OPES processor has to allocate storage to support this optimization, but a callout server does not. On the other hand, it is the callout server that is responsible for relieving the processor from data preservation commitments. There is no simple way to resolve this conflict of interest on a protocol level. Some OPES processors may allocate a relatively small buffer for data preservation purposes and stop preserving data when the buffer becomes full. This technique would benefit callout services that can quickly reuse or discard kept data. Another processor strategy would be to size the buffer based on historical data reuse statistics. To improve chances of beneficial cooperation, callout servers are strongly encouraged to immediately notify OPES processors of unwanted data. The callout server that made a decision not to send Data Use Yours (DUY) messages (for a specific data ranges or at all) SHOULD immediately inform the OPES processor of that decision with the corresponding Data Preservation Interest (DPI) message(s) or other mechanisms.
这两个代理都可以从数据重用中获益。OPES处理器必须分配存储以支持此优化，但callout服务器不能。另一方面，调出服务器负责解除处理器的数据保存义务。没有简单的方法可以在协议级别解决这种利益冲突。一些OPES处理器可能会为数据保存目的分配一个相对较小的缓冲区，并在缓冲区满时停止保存数据。这种技术将有利于能够快速重用或丢弃保留数据的调出服务。另一种处理器策略是根据历史数据重用统计数据调整缓冲区的大小。为了提高有益合作的机会，强烈建议调出服务器立即将不需要的数据通知OPES处理者。做出不发送数据使用您的（DUY）消息（针对特定数据范围或根本不发送）决定的调出服务器应立即将该决定通知OPES处理者，并提供相应的数据保存兴趣（DPI）消息或其他机制。
Many callout services adapt small portions of large messages and would preferably not to be in the loop when that adaptation is over. Some callout services may not seek data modification and would preferably not send data back to the OPES processor, even if the OPES processor is not supporting the data preservation optimization (Section 7). By OCP design, unilateral premature dataflow termination by a callout server would lead to termination of an OCP transaction with an error. Thus, the two agents must cooperate to allow for error-free premature termination.
许多调出服务适应大消息的一小部分，最好在调出结束时不在循环中。某些调出服务可能不寻求数据修改，最好不将数据发送回OPES处理器，即使OPES处理器不支持数据保存优化（第7节）。根据OCP设计，callout服务器单方面提前终止数据流将导致OCP事务的终止并出现错误。因此，两个代理必须合作以允许无错误的提前终止。
This section documents two mechanisms for premature termination of original or adapted dataflow. In combination, the mechanisms allow the callout server to get out of the processing loop altogether.
本节记录了两种过早终止原始或改编数据流的机制。通过组合，这些机制允许callout服务器完全退出处理循环。
There are scenarios where a callout server is not interested in the remaining original dataflow. For example, a simple access blocking or "this site is temporary down" callout service has to send an adapted (generated) application message but would preferably not receive original data from the OPES processor.
在某些情况下，调出服务器对剩余的原始数据流不感兴趣。例如，一个简单的访问阻塞或“此站点暂时关闭”呼叫服务必须发送一个调整（生成）的应用程序消息，但最好不要从OPES处理器接收原始数据。
OCP Core supports premature original dataflow termination via the Want Stop Receiving Data (DWSR) message. A callout server that does not seek to receive additional original data (beyond a certain size) sends a DWSR message. The OPES processor receiving a DWSR message terminates original dataflow by sending an Application Message End (AME) message with a 206 (partial) status code.
OCP Core支持通过Want Stop Receiving Data（DWSR）消息提前终止原始数据流。不寻求接收额外原始数据（超过特定大小）的调出服务器将发送DWSR消息。接收DWSR消息的OPES处理器通过发送带有206（部分）状态代码的应用程序消息结束（AME）消息来终止原始数据流。
The following figure illustrates a typical sequence of events. The downward lines connecting the two dataflows illustrate the transmission delay that allows for more OCP messages to be sent while an agent waits for the opposing agent reaction.
下图说明了一个典型的事件序列。连接两个数据流的下行线说明了传输延迟，允许在代理等待对方代理反应时发送更多OCP消息。
OPES Callout
Processor Server
DUM> <DUM
DUM> <DWSR <-- Server is ready to stop receiving
... _____/<DUM <-- Server continues as usual
DUM>______/ <DUM
AME> ... <-- Processor stops sending original data
\_____ <DUM
\______<DUM
<DUM <-- Server continues to send adapted data
...
<AME
OPES Callout
Processor Server
DUM> <DUM
DUM> <DWSR <-- Server is ready to stop receiving
... _____/<DUM <-- Server continues as usual
DUM>______/ <DUM
AME> ... <-- Processor stops sending original data
\_____ <DUM
\______<DUM
<DUM <-- Server continues to send adapted data
...
<AME
The mechanism described in this section has no effect on the adapted dataflow. Receiving an Application Message End (AME) message with 206 (partial) result status code from the OPES processor does not introduce any special requirements for the adapted dataflow termination. However, it is not possible to terminate adapted dataflow prematurely after the original dataflow has been prematurely terminated (see section 8.3).
本节中描述的机制对适应的数据流没有影响。从OPES处理器接收带有206（部分）结果状态代码的应用程序消息结束（AME）消息不会对适配数据流终止引入任何特殊要求。然而，在原始数据流被提前终止后，不可能提前终止适配数据流（见第8.3节）。
There are scenarios where a callout service may want to stop sending adapted data before a complete application message has been sent. For example, a logging-only callout service has to receive all application messages but would preferably not send copies back to the OPES processor.
在某些情况下，调出服务可能希望在发送完整的应用程序消息之前停止发送调整后的数据。例如，仅记录调用服务必须接收所有应用程序消息，但最好不要将副本发送回OPES处理器。
OCP Core supports premature adapted dataflow termination via a combination of Want Stop Sending Data (DWSS) and Stop Sending Data (DSS) messages. A callout service that seeks to stop sending data sends a DWSS message, soliciting an OPES processor permission to stop. While waiting for the permission, the server continues with its usual routine.
OCP核心通过停止发送数据（DWS）和停止发送数据（DSS）消息的组合，支持提前适应的数据流终止。试图停止发送数据的调用服务发送DWSS消息，请求OPES处理器允许停止。在等待权限时，服务器继续执行其常规例程。
An OPES processor receiving a Want Stop Sending Data message responds with a Stop Sending Data (DSS) message. The processor may then pause to wait for the callout server to terminate the adapted dataflow or may continue sending original data while making a copy of it. Once the server terminates the adapted dataflow, the processor is responsible for using original data (sent or paused after sending DSS) instead of the adapted data.
接收到想要停止发送数据消息的OPES处理器响应停止发送数据（DSS）消息。然后，处理器可暂停以等待调出服务器终止调整后的数据流，或在复制原始数据的同时继续发送原始数据。一旦服务器终止适配数据流，处理器负责使用原始数据（发送或在发送DSS后暂停）代替适配数据。
The callout server receiving a DSS message terminates the adapted dataflow (see the Stop Sending Data (DSS) message definition for the exact requirements and corner cases).
接收DSS消息的callout server会终止调整后的数据流（请参阅停止发送数据（DSS）消息定义以了解确切的要求和情况）。
The following figure illustrates a typical sequence of events, including a possible pause in original dataflow when the OPES processor is waiting for the adapted dataflow to end. The downward lines connecting the two dataflows illustrate the transmission delay that allows for more OCP messages to be sent while an agent waits for the opposing agent reaction.
下图说明了一个典型的事件序列，包括当OPES处理器等待调整后的数据流结束时原始数据流中可能出现的暂停。连接两个数据流的下行线说明了传输延迟，允许在代理等待对方代理反应时发送更多OCP消息。
OPES Callout
Processor Server
DUM> <DUM
DUM> <DWSS <-- Server is ready to stop sending
... _____/<DUM <-- Server continues as usual,
DUM>______/ <DUM waiting for DSS
DSS> ...
\_____ <DUM
possible \______<DUM
org-dataflow <AME 206 <-- Server terminates adapted dataflow
pause _____/ upon receiving the DSS message
______/
DUM> <-- Processor resumes original dataflow
DUM> to the server and starts using
... original data without adapting it
AME>
OPES Callout
Processor Server
DUM> <DUM
DUM> <DWSS <-- Server is ready to stop sending
... _____/<DUM <-- Server continues as usual,
DUM>______/ <DUM waiting for DSS
DSS> ...
\_____ <DUM
possible \______<DUM
org-dataflow <AME 206 <-- Server terminates adapted dataflow
pause _____/ upon receiving the DSS message
______/
DUM> <-- Processor resumes original dataflow
DUM> to the server and starts using
... original data without adapting it
AME>
Premature adapted dataflow preservation is not trivial, as the OPES processor relies on the callout server to provide adapted data (modified or not) to construct the adapted application message. If the callout server seeks to quit its job, special care must be taken to ensure that the OPES processor can construct the complete application message. On a logical level, this mechanism is equivalent to switching from one callout server to another (non-modifying) callout server in the middle of an OCP transaction.
过早适应的数据流保存并非小事，因为OPES处理器依赖callout服务器提供适应的数据（修改或不修改），以构建适应的应用程序消息。如果调出服务器试图退出其工作，则必须特别注意确保OPES处理器能够构建完整的应用程序消息。在逻辑层面上，这种机制相当于在OCP事务的中间从一个标注服务器切换到另一个（非修改）标注服务器。
Other than a possible pause in the original dataflow, the mechanism described in this section has no effect on the original dataflow. Receiving an Application Message End (AME) message with 206 (partial) result status code from the callout server does not introduce any special requirements for the original dataflow termination.
除了原始数据流中可能的暂停外，本节中描述的机制对原始数据流没有影响。从callout服务器接收带有206（部分）结果状态代码的应用程序消息结束（AME）消息不会对原始数据流终止提出任何特殊要求。
Some adaptation services work on application message prefixes and do not seek to be in the adaptation loop once their work is done. For example, an ad insertion service that did its job by modifying the first fragment of a web "page" would not seek to receive more original data or to perform further adaptations. The 'Getting Out of the Loop' optimization allows a callout server to get completely out of the application message processing loop.
一些自适应服务在应用程序消息前缀上工作，并且在工作完成后不寻求处于自适应循环中。例如，通过修改web“页面”的第一个片段来完成其工作的广告插入服务不会寻求接收更多原始数据或执行进一步的调整。“跳出循环”优化允许调出服务器完全跳出应用程序消息处理循环。
The "Getting Out of the Loop" optimization is made possible by terminating the adapted dataflow (section 8.2) and then by terminating the original dataflow (section 8.1). The order of termination is very important.
通过终止调整后的数据流（第8.2节），然后终止原始数据流（第8.1节），可以实现“脱离循环”优化。终止的顺序非常重要。
If the original dataflow is terminated first, the OPES processor would not allow the adapted dataflow to be terminated prematurely, as the processor would not be able to reconstruct the remaining portion of the adapted application message. The processor would not know which suffix of the remaining original data has to follow the adapted parts. The mapping between original and adapted octets is known only to the callout service.
如果首先终止原始数据流，则OPES处理器将不允许过早终止适配数据流，因为处理器将无法重建适配应用程序消息的剩余部分。处理器不知道剩余原始数据的哪个后缀必须跟在适配部分后面。原始八位字节和改编八位字节之间的映射只有callout服务知道。
An OPES processor that received a DWSS message followed by a DWSR message MUST NOT send an AME message with a 206 (partial) status code before sending a DSS message. Informally, this rule means that a callout server that wants to get out of the loop fast should send a DWSS message immediately followed by a DWSR message; the server does not have to wait for the OPES processor's permission to terminate adapted dataflow before requesting that the OPES processor terminates original dataflow.
在发送DSS消息之前，接收DWSS消息后接DWSR消息的OPES处理器不得发送带有206（部分）状态代码的AME消息。非正式地说，这条规则意味着想要快速脱离循环的callout服务器应该立即发送DWSS消息，后跟DWSR消息；在请求OPES处理器终止原始数据流之前，服务器不必等待OPES处理器的许可来终止适配数据流。
A protocol element type is a named set of syntax and semantics rules. This section defines a simple, formal declaration mnemonic for protocol element types, labeled PETDM. PETDM simplicity is meant to ease type declarations in this specification. PETDM formality is meant to improve interoperability among implementations. Two protocol elements are supported by PETDM: message parameter values and messages.
协议元素类型是一组命名的语法和语义规则。本节为协议元素类型定义了一个简单、正式的声明助记符，标记为PETDM。PETDM简单性旨在简化本规范中的类型声明。PETDM形式旨在改进实现之间的互操作性。PETDM支持两个协议元素：消息参数值和消息。
All OCP Core parameter and message types are declared by using PETDM. OCP extensions SHOULD use PETDM when declaring new types.
所有OCP核心参数和消息类型都是使用PETDM声明的。OCP扩展在声明新类型时应该使用PETDM。
Atom, list, structure, and message constructs are four available base types. Their syntax and semantics rules are defined in section 3.1. New types can be declared in PETDM to extend base types semantics by using the following declaration templates. The new semantics rules are meant to be attached to each declaration using prose text.
原子、列表、结构和消息构造是四种可用的基本类型。第3.1节定义了它们的语法和语义规则。通过使用以下声明模板，可以在PETDM中声明新类型以扩展基本类型语义。新的语义规则将使用散文文本附加到每个声明。
Text in angle brackets "<>" are template placeholders, to be substituted with actual type names or parameter name tokens. Square brackets "[]" surround optional elements such as structure members or message payload.
尖括号“<>”中的文本是模板占位符，将用实际的类型名或参数名标记替换。方括号“[]”围绕可选元素，如结构成员或消息负载。
o Declaring a new atomic type: <new-type-name>: extends atom;
o 声明新的原子类型：<newtypename>：扩展原子；
o Declaring a new list with old-type-name items: <new-type-name>: extends list of <old-type-name>; Unless it is explicitly noted otherwise, empty lists are valid and have the semantics of an absent parameter value.
o 使用旧类型名称项声明新列表：<new type name>：扩展<old type name>的列表；除非另有明确说明，否则空列表是有效的，并且具有缺少参数值的语义。
o Declaring a new structure with members: <new-type-name>: extends structure with { <old-type-nameA> <old-type-nameB> [<old-type-nameC>] ...; <member-name1>: <old-type-name1>; <member-name2>: <old-type-name2>; [<member-name3>: <old-type-name3>]; ... };
o 声明具有成员的新结构：<new-type-name>：使用{<old-type-nameA><old-type-nameB>[<old-type-nameC>]扩展结构；<member-name1>：<old-type-name1>；<member-name2>：<old-type-name2>；[<member-name3>：<old-type-name3>]；}；
The new structure may have anonymous members and named members. Neither group has to exist. Note that it is always possible for extensions to add more members to old structures without affecting type semantics because unrecognized members are ignored by compliant agents.
新结构可能有匿名成员和命名成员。这两个团体都不必存在。请注意，扩展总是可以在不影响类型语义的情况下向旧结构添加更多成员，因为兼容代理会忽略无法识别的成员。
o Declaring a new message with parameters: <new-type-name>: extends message with { <old-type-nameA> <old-type-nameB> [<old-type-nameC>] ...; <parameter-name1>: <old-type-name1>; <parameter-name2>: <old-type-name2>; [<parameter-name3>: <old-type-name3>]; ... };
o 使用参数声明新消息：<new-type-name>：使用{<old-type-nameA><old-type-nameB>[<old-type-nameC>]扩展消息；<parameter-name1>：<old-type-name1>；<parameter-name2>：<old-type-name2>；[<parameter-name3>：<old-type-name3>]；}；
The new type name becomes the message name. Just as when a structure is extended, the new message may have anonymous parameters and named parameters. Neither group has to exist. Note that it is always possible for extensions to add more parameters to old messages without affecting type semantics because unrecognized parameters are ignored by compliant agents.
新类型名称将成为消息名称。与扩展结构时一样，新消息可能具有匿名参数和命名参数。这两个团体都不必存在。请注意，扩展总是可以在不影响类型语义的情况下向旧消息添加更多参数，因为兼容代理会忽略无法识别的参数。
o Extending a type with more semantics details:
o 使用更多语义细节扩展类型：
<new-type-name>: extends <old-type-name>;
<new-type-name>: extends <old-type-name>;
o Extending a structure- or message-base type: <new-type-name>: extends <old-type-name> with { <old-type-nameA> <old-type-nameB> [<old-type-nameC>] ...; <member-name1>: <old-type-name1>; <member-name2>: <old-type-name2>; [<member-name3>: <old-type-name3>]; ... }; New anonymous members are appended to the anonymous members of the old type, and new named members are merged with named members of the old type.
o 扩展结构或消息基类型：<new-type-name>：使用{<old-type-nameA><old-type-nameB>[<old-type-nameC>]扩展<old-type-name>；<member-name1>：<old-type-name1>；<member-name2>：<old-type-name2>；[<member-name3>：<old-type-name3>]；新的匿名成员追加到旧类型的匿名成员，新的命名成员与旧类型的命名成员合并。
o Extending a message-base type with payload semantics: <new-type-name>: extends <old-type-name> with { ... } and payload; Any any OCP message can have payload, but only some message types have known payload semantics. Like any parameter, payload may be required or optional.
o 使用负载语义扩展消息基类型：<新类型名称>：使用{…}和负载扩展<旧类型名称>；任何OCP消息都可以有有效负载，但只有某些消息类型具有已知的有效负载语义。与任何参数一样，有效载荷可能是必需的，也可能是可选的。
o Extending type semantics without renaming the type: <old-type-name>: extends <namespace>::<old-type-name>; The above template can be used by OCP Core extensions that seek to change the semantics of OCP Core types without renaming them. This technique is essential for extending OCP messages because the message name is the same as the message type name. For example, an SMTP profile for OCP might use the following declaration to extend an Application Message Start (AMS) message with Am-Id, a parameter defined in that profile:
o 在不重命名类型的情况下扩展类型语义：<old-type-name>：扩展<namespace>：：<old-type-name>；OCP核心扩展可以使用上面的模板，这些扩展试图在不重命名OCP核心类型的情况下更改OCP核心类型的语义。此技术对于扩展OCP消息至关重要，因为消息名称与消息类型名称相同。例如，OCP的SMTP配置文件可能使用以下声明来扩展具有Am Id（该配置文件中定义的参数）的应用程序消息启动（AMS）消息：
AMS: extends Core::AMS with {
Am-Id: am-id;
};
AMS: extends Core::AMS with {
Am-Id: am-id;
};
All extended types may be used as replacements of the types they extend. For example, a Negotiation Offer (NO) message uses a parameter of type Features. Features (section 10.12) is a list of feature (section 10.11) items. A Feature is a structure-based type. An OCP extension (e.g., an HTTP application profile) may extend the feature type and use a value of that extended type in a negotiation offer. Recipients that are aware of the extension will recognize added members in feature items and negotiate accordingly. Other recipients will ignore them.
所有扩展类型都可以用作其扩展类型的替换。例如，协商报价（NO）消息使用Features类型的参数。功能（第10.12节）是功能（第10.11节）项目的列表。特征是基于结构的类型。OCP扩展（例如HTTP应用程序配置文件）可以扩展功能类型，并在协商报价中使用该扩展类型的值。知道扩展的收件人将识别功能项中添加的成员，并进行相应的协商。其他收件人将忽略它们。
The OCP Core namespace tag is "Core". OCP extensions that declare types MUST define their namespace tags (so that other extensions and documentation can use them in their PETDM declarations).
OCP核心命名空间标记为“Core”。声明类型的OCP扩展必须定义它们的名称空间标记（以便其他扩展和文档可以在它们的PETDM声明中使用它们）。
Anonymous parameters are positional: The parameter's position (i.e., the number of anonymous parameters to the left) is its "name". Thus, when a structure or message has multiple optional anonymous parameters, parameters to the right can be used only if all parameters to the left are present. The following notation
匿名参数是位置参数：参数的位置（即左侧匿名参数的数量）是其“名称”。因此，当结构或消息具有多个可选匿名参数时，只有左侧的所有参数都存在时，才能使用右侧的参数。以下符号
[name1] [name2] [name3] ... [nameN]
[name1][name2][name3]。。。[姓名]
is interpreted as
被解释为
[name1 [ name2 [ name3 ... [nameN] ... ]]]
[name1[name2[name3…[nameN]…]]
When an anonymous parameter is added to a structure or message that has optional anonymous parameters, the new parameter has to be optional and can only be used if all old optional parameters are in use. Named parameters do not have these limitations, as they are not positional, but associative; they are identified by their explicit and unique names.
将匿名参数添加到具有可选匿名参数的结构或消息时，新参数必须是可选的，并且只有在使用所有旧的可选参数时才能使用。命名参数没有这些限制，因为它们不是位置参数，而是关联参数；它们通过其明确和唯一的名称进行标识。
This section defines parameter value types that are used for message definitions (section 11). Before using a parameter value, an OCP agent MUST check whether the value has the expected type (i.e., whether it complies with all rules from the type definition). A single rule violation means that the parameter is invalid. See Section 5 for rules on processing invalid input.
本节定义用于消息定义的参数值类型（第11节）。在使用参数值之前，OCP代理必须检查该值是否具有预期的类型（即，它是否符合类型定义中的所有规则）。单个规则冲突表示参数无效。有关处理无效输入的规则，请参见第5节。
OCP extensions MAY define their own types. If they do, OCP extensions MUST define types with exactly one base format and MUST specify the type of every new protocol element they introduce.
OCP扩展可以定义自己的类型。如果这样做，OCP扩展必须使用一种基本格式定义类型，并且必须指定它们引入的每个新协议元素的类型。
uri: extends atom;
uri：扩展atom；
Uri (universal resource identifier) is an atom formatted according to URI rules in [RFC2396].
Uri（通用资源标识符）是根据[RFC2396]中的Uri规则格式化的原子。
Often, a uri parameter is used as a unique (within a given scope) identifier. Uni semantics is incomplete without the scope specification. Many uri parameters are URLs. Unless it is noted otherwise, URL identifiers do not imply the existence of a serviceable resource at the location they specify. For example, an HTTP request for an HTTP-based URI identifier may result in a 404 (Not Found) response.
通常，uri参数用作唯一（在给定范围内）标识符。如果没有范围规范，Uni语义是不完整的。许多uri参数都是URL。除非另有说明，否则URL标识符并不意味着在其指定的位置存在可用资源。例如，对基于HTTP的URI标识符的HTTP请求可能导致404（未找到）响应。
uni: extends atom;
uni：扩展原子；
Uni (unique numeric identifier) is an atom formatted as dec-number and with a value in the [0, 2147483647] range, inclusive.
Uni（唯一数字标识符）是一个原子，格式为dec编号，其值在[0，2147483647]范围内，包括在内。
A uni parameter is used as a unique (within a given scope) identifier. Uni semantics is incomplete without the scope specification. Some OCP messages create identifiers (i.e., bring them into scope). Some OCP messages destroy them (i.e, remove them
uni参数用作唯一（在给定范围内）标识符。如果没有范围规范，Uni语义是不完整的。一些OCP消息创建标识符（即，将它们引入范围）。一些OCP消息会破坏它们（即删除它们）
from scope). An OCP agent MUST NOT create the same uni value more than once within the same scope. When creating a new identifier of the same type and within the same scope as some old identifier, an OCP agent MUST use a higher numerical value for the new identifier. The first rule makes uni identifiers suitable for cross-referencing logs and other artifacts. The second rule makes efficient checks of the first rule possible.
从范围）。OCP代理不能在同一范围内多次创建同一uni值。当创建与某个旧标识符类型相同、范围相同的新标识符时，OCP代理必须为新标识符使用更高的数值。第一条规则使uni标识符适用于交叉引用日志和其他工件。第二条规则使第一条规则的有效检查成为可能。
For example, a previously used transaction identifier "xid" must not be used for a new Transaction Start (TS) message within the same OCP transaction, even if a prior Transaction End (TE) message was sent for the same transaction.
例如，以前使用的事务标识符“xid”不得用于同一OCP事务中的新事务开始（TS）消息，即使先前的事务结束（TE）消息是为同一事务发送的。
An OCP agent MUST terminate the state associated with uni uniqueness scope if all unique values have been used up.
如果所有唯一值都已用完，OCP代理必须终止与uni唯一性作用域关联的状态。
size: extends atom;
尺寸：扩展原子；
Size is an atom formatted as dec-number and with a value in the [0, 2147483647] range, inclusive.
Size是一个原子，格式为dec数字，其值在[0，2147483647]范围内，包括在内。
Size value is the number of octets in the associated data chunk.
Size value是关联数据块中的八位字节数。
OCP Core cannot handle application messages that exceed 2147483647 octets in size, that require larger sizes as a part of OCP marshaling process, or that use sizes with granularity other than 8 bits. This limitation can be addressed by OCP extensions, as hinted in section 15.1.
OCP核心无法处理大小超过2147483647个八位字节、在OCP封送处理过程中需要更大大小的应用程序消息，或者使用粒度不是8位的应用程序消息。如第15.1节所示，OCP扩展可以解决此限制。
offset: extends atom;
偏置：扩展原子；
Offset is an atom formatted as dec-number and with a value in the [0, 2147483647] range, inclusive.
偏移量是一个原子，格式为dec编号，其值在[0，2147483647]范围内，包括在内。
Offset is an octet position expressed in the number of octets relative to the first octet of the associated dataflow. The offset of the first data octet has a value of zero.
偏移量是八位字节位置，表示为相对于关联数据流的第一个八位字节的八位字节数。第一个数据八位组的偏移量的值为零。
percent: extends atom;
百分比：扩展原子；
Percent is an atom formatted as dec-number and with a value in the [0, 100] range, inclusive.
百分比是一个原子，格式为dec数字，其值在[01100]范围内，包括[01100]。
Percent semantics is incomplete unless its value is associated with a boolean statement or assertion. The value of 0 indicates absolute impossibility. The value of 100 indicates an absolute certainty. In either case, the associated statement can be relied upon as if it were expressed in boolean rather than probabilistic terms. Values in the [1,99] inclusive range indicate corresponding levels of certainty that the associated statement is true.
除非其值与布尔语句或断言关联，否则百分比语义是不完整的。值0表示绝对不可能。值100表示绝对确定。在任何一种情况下，都可以依赖关联语句，就好像它是用布尔术语而不是概率术语表示的一样。[1,99]范围内的值表示相关语句为真的相应确定程度。
boolean: extends atom;
布尔：扩展原子；
Boolean type is an atom with two valid values: true and false. A boolean parameter expresses the truthfulness of the associated statement.
布尔类型是一个具有两个有效值的原子：true和false。布尔参数表示关联语句的真实性。
xid: extends uni;
xid：扩展uni；
Xid, an OCP transaction identifier, uniquely identifies an OCP transaction within an OCP connection.
OCP事务标识符Xid唯一标识OCP连接中的OCP事务。
sg-id: extends uni;
sgid：扩展uni；
Sg-id, a service group identifier, uniquely identifies a group of services on an OCP connection.
Sg id是服务组标识符，唯一标识OCP连接上的一组服务。
modp: extends percent;
modp：扩展百分比；
Modp extends the percent type to express the sender's confidence that application data will be modified. The boolean statement associated with the percentage value is "data will be modified". Modification is defined as adaptation that changes the numerical value of at least one data octet.
Modp扩展了百分比类型，以表示发送方对应用程序数据将被修改的信心。与百分比值关联的布尔语句是“数据将被修改”。修改定义为改变至少一个数据八位字节数值的自适应。
result: extends structure with {
atom [atom];
};
result: extends structure with {
atom [atom];
};
The OCP processing result is expressed as a structure with two documented members: a required Uni status code and an optional
OCP处理结果表示为具有两个文档化成员的结构：一个必需的Uni状态代码和一个可选的
reason. The reason member contains informative textual information not intended for automated processing. For example:
原因原因成员包含不用于自动处理的信息性文本信息。例如：
{ 200 OK }
{ 200 "6:got it" }
{ 200 "27:27 octets in UTF-8 encoding" }
{ 200 OK }
{ 200 "6:got it" }
{ 200 "27:27 octets in UTF-8 encoding" }
This specification defines the following status codes:
本规范定义了以下状态代码：
Result Status Codes
结果状态代码
+--------+--------------+-------------------------------------------+
| code | text | semantics |
+--------+--------------+-------------------------------------------+
| 200 | OK | Overall success. This specification does |
| | | not contain any general actions for a 200 |
| | | status code recipient. |
| 206 | partial | Partial success. This status code is |
| | | documented for Application Message End |
| | | (AME) messages only. The code indicates |
| | | that the agent terminated the |
| | | corresponding dataflow prematurely (i.e., |
| | | more data would be needed to reconstruct |
| | | a complete application message). |
| | | Premature termination of one dataflow |
| | | does not introduce any special |
| | | requirements for the other dataflow |
| | | termination. See dataflow termination |
| | | optimizations (section 8) for use cases. |
| 400 | failure | An error, exception, or trouble. A |
| | | recipient of a 400 (failure) result of an |
| | | AME, TE, or CE message MUST destroy any |
| | | state or data associated with the |
| | | corresponding dataflow, transaction, or |
| | | connection. For example, an adapted |
| | | version of the application message data |
| | | must be purged from the processor |
| | | cache if the OPES processor receives an |
| | | Application Message End (AME) message |
| | | with result code of 400. |
+--------+--------------+-------------------------------------------+
+--------+--------------+-------------------------------------------+
| code | text | semantics |
+--------+--------------+-------------------------------------------+
| 200 | OK | Overall success. This specification does |
| | | not contain any general actions for a 200 |
| | | status code recipient. |
| 206 | partial | Partial success. This status code is |
| | | documented for Application Message End |
| | | (AME) messages only. The code indicates |
| | | that the agent terminated the |
| | | corresponding dataflow prematurely (i.e., |
| | | more data would be needed to reconstruct |
| | | a complete application message). |
| | | Premature termination of one dataflow |
| | | does not introduce any special |
| | | requirements for the other dataflow |
| | | termination. See dataflow termination |
| | | optimizations (section 8) for use cases. |
| 400 | failure | An error, exception, or trouble. A |
| | | recipient of a 400 (failure) result of an |
| | | AME, TE, or CE message MUST destroy any |
| | | state or data associated with the |
| | | corresponding dataflow, transaction, or |
| | | connection. For example, an adapted |
| | | version of the application message data |
| | | must be purged from the processor |
| | | cache if the OPES processor receives an |
| | | Application Message End (AME) message |
| | | with result code of 400. |
+--------+--------------+-------------------------------------------+
Specific OCP messages may require code-specific actions.
特定OCP消息可能需要特定于代码的操作。
Extending result semantics is made possible by adding new "result" structure members or by negotiating additional result codes (e.g., as a part of a negotiated profile). A recipient of an unknown (in
通过添加新的“结果”结构成员或协商其他结果代码（例如，作为协商概要文件的一部分），可以扩展结果语义。一个不为人知的消息的接收者
then-current context) result code MUST act as if code 400 (failure) were received.
然后，当前上下文（current context）结果代码必须像接收到代码400（failure）一样工作。
The recipient of a message without the actual result parameter, but with an optional formal result parameter, MUST act as if code 200 (OK) were received.
没有实际结果参数但带有可选正式结果参数的消息的收件人必须像收到代码200（OK）一样行事。
Textual information (the second anonymous parameter of the result structure) is often referred to as "reason" or "reason phrase". To assist manual troubleshooting efforts, OCP agents are encouraged to include descriptive reasons with all results indicating a failure.
文本信息（结果结构的第二个匿名参数）通常被称为“原因”或“原因短语”。为协助手动故障排除工作，鼓励OCP代理在所有结果中说明故障原因。
In this specification, an OCP message with result status code of 400 (failure) is called "a message indicating a failure".
在本规范中，结果状态代码为400（故障）的OCP消息称为“指示故障的消息”。
feature: extends structure with {
uri;
};
feature: extends structure with {
uri;
};
The feature type extends structure to relay an OCP feature identifier and to reserve a "place" for optional feature-specific parameters (sometimes called feature attributes). Feature values are used to declare support for and to negotiate use of OCP features.
特征类型扩展结构，以中继OCP特征标识符，并为可选的特征特定参数（有时称为特征属性）保留“位置”。功能值用于声明对OCP功能的支持，并协商OCP功能的使用。
This specification does not define any features.
本规范未定义任何功能。
features: extends list of feature;
功能：扩展功能列表；
Features is a list of feature values. Unless it is noted otherwise, the list can be empty, and features are listed in decreasing preference order.
要素是要素值的列表。除非另有说明，否则列表可以为空，并且特征按递减的首选项顺序列出。
service: extends structure with {
uri;
};
service: extends structure with {
uri;
};
Service structure has one anonymous member, an OPES service identifier of type uri. Services may have service-dependent parameters. An OCP extension defining a service for use with OCP MUST define service identifier and service-dependent parameters, if there are any, as additional "service" structure members. For example, a service value may look like this:
服务结构有一个匿名成员，即uri类型的OPES服务标识符。服务可能具有依赖于服务的参数。定义与OCP一起使用的服务的OCP扩展必须将服务标识符和服务相关参数（如果有）定义为附加的“服务”结构成员。例如，服务值可能如下所示：
{"41:http://www.iana.org/assignments/opes/ocp/tls" "8:blowfish"}
{"41:http://www.iana.org/assignments/opes/ocp/tls" "8:blowfish"}
services: extends list of service;
服务：扩展服务列表；
Services is a list of service values. Unless it is noted otherwise, the list can be empty, and the order of the values is the requested or actual service application order.
服务是服务值的列表。除非另有说明，否则列表可以为空，值的顺序为请求的或实际的服务应用程序顺序。
Several parameter types, such as offset apply to both original and adapted dataflow. It is relatively easy to misidentify a type's dataflow affiliation, especially when parameters with different affiliations are mixed together in one message declaration. The following statements declare new dataflow-specific types by using their dataflow-agnostic versions (denoted by a <type> placeholder).
有几种参数类型（如偏移量）同时适用于原始数据流和调整后的数据流。相对容易错误识别类型的数据流从属关系，特别是当具有不同从属关系的参数在一个消息声明中混合在一起时。以下语句通过使用其数据流不可知版本（由<type>占位符表示）声明新的数据流特定类型。
The following new types refer to original data only:
以下新类型仅指原始数据：
org-<type>: extends <type>;
org-<type>: extends <type>;
The following new types refer to adapted data only:
以下新类型仅适用于调整后的数据：
adp-<type>: extends <type>;
adp-<type>: extends <type>;
The following new types refer to the sender's dataflow only:
以下新类型仅指发送方的数据流：
my-<type>: extends <type>;
my-<type>: extends <type>;
The following new types refer to the recipient's dataflow only:
以下新类型仅指收件人的数据流：
your-<type>: extends <type>;
your-<type>: extends <type>;
OCP Core uses the above type-naming scheme to implement dataflow specialization for the following types: offset, size, and sg-id. OCP extensions SHOULD use the same scheme.
OCP核心使用上述类型命名方案为以下类型实现数据流专门化：偏移量、大小和sg-id。OCP扩展应使用相同的方案。
This section describes specific OCP messages. Each message is given a unique name and usually has a set of anonymous and/or named parameters. The order of anonymous parameters is specified in the message definitions below. No particular order for named parameters is implied by this specification. OCP extensions MUST NOT introduce order-dependent named parameters. No more than one named-parameter
本节介绍特定的OCP消息。每个消息都有一个唯一的名称，通常有一组匿名和/或命名参数。匿名参数的顺序在下面的消息定义中指定。本规范未暗示命名参数的特定顺序。OCP扩展不能引入依赖顺序的命名参数。不超过一个命名参数
with a given name can appear in the message; messages with multiple equally named parameters are semantically invalid.
具有给定名称的用户可以出现在消息中；具有多个同名参数的消息在语义上无效。
A recipient MUST be able to parse any message in valid format (see section 3.1), subject to the limitations of the recipient's resources.
收件人必须能够以有效格式解析任何邮件（见第3.1节），但受收件人资源的限制。
Unknown or unexpected message names, parameters, and payloads may be valid extensions. For example, an "extra" named parameter may be used for a given message, in addition to what is documented in the message definition below. A recipient MUST ignore any valid but unknown or unexpected name, parameter, member, or payload.
未知或意外的消息名称、参数和有效负载可能是有效的扩展名。例如，除了下面的消息定义中记录的内容外，还可以为给定消息使用一个“额外”命名参数。收件人必须忽略任何有效但未知或意外的名称、参数、成员或负载。
Some message parameter values use uni identifiers to refer to various OCP states (see section 10.2 and Appendix B). These identifiers are created, used, and destroyed by OCP agents via corresponding messages. Except when creating a new identifier, an OCP agent MUST NOT send a uni identifier that corresponds to an inactive state (i.e., that was either never created or already destroyed). Such identifiers invalidate the host OCP message (see section 5). For example, the recipient must terminate the transaction when the xid parameter in a Data Use Mine (DUM) message refers to an unknown or already terminated OCP transaction.
一些消息参数值使用uni标识符来表示各种OCP状态（见第10.2节和附录B）。OCP代理通过相应的消息创建、使用和销毁这些标识符。除创建新标识符外，OCP代理不得发送对应于非活动状态（即从未创建或已销毁）的uni标识符。此类标识符使主机OCP消息无效（见第5节）。例如，当数据使用挖掘（DUM）消息中的xid参数引用未知或已终止的OCP事务时，收件人必须终止该事务。
CS: extends message;
CS：扩展消息；
A Connection Start (CS) message indicates the start of an OCP connection. An OCP agent MUST send this message before it sends any other message on the connection. If the first message an OCP agent receives is not Connection Start (CS), the agent MUST terminate the connection with a Connection End (CE) message having 400 (failure) result status code. An OCP agent MUST send Connection Start (CS) message exactly once. An OCP agent MUST ignore repeated Connection Start (CS) messages.
连接启动（CS）消息表示OCP连接的启动。OCP代理必须在发送连接上的任何其他消息之前发送此消息。如果OCP代理收到的第一条消息不是连接启动（CS），则该代理必须使用连接结束（CE）消息终止连接，该消息具有400（故障）结果状态代码。OCP代理必须只发送一次连接启动（CS）消息。OCP代理必须忽略重复连接启动（CS）消息。
At any time, a callout server MAY refuse further processing on an OCP connection by sending a Connection End (CE) message with the status code 400 (failure). Note that the above requirement to send a CS message first still applies.
在任何时候，呼叫服务器都可以通过发送状态代码为400（故障）的连接结束（CE）消息来拒绝OCP连接上的进一步处理。请注意，上述先发送CS消息的要求仍然适用。
With TCP/IP as transport, raw TCP connections (local and remote peer IP addresses with port numbers) identify an OCP connection. Other transports may provide OCP connection identifiers to distinguish logical connections that share the same transport. For example, a single BEEP [RFC3080] channel may be designated as a single OCP connection.
使用TCP/IP作为传输，原始TCP连接（带有端口号的本地和远程对等IP地址）标识OCP连接。其他传输可以提供OCP连接标识符来区分共享相同传输的逻辑连接。例如，单个蜂鸣声[RFC3080]通道可以指定为单个OCP连接。
CE: extends message with {
[result];
};
CE: extends message with {
[result];
};
A Connection End (CE) Indicates the end of an OCP connection. The agent initiating closing or termination of a connection MUST send this message immediately prior to closing or termination. The recipient MUST free associated state, including transport state.
连接端（CE）表示OCP连接的结束。启动关闭或终止连接的代理必须在关闭或终止之前立即发送此消息。收件人必须释放关联状态，包括传输状态。
Connection termination without a Connection End (CE) message indicates that the connection was prematurely closed, possibly without the closing-side agent's prior knowledge or intent. When an OCP agent detects a prematurely closed connection, the agent MUST act as if a Connection End (CE) message indicating a failure was received.
没有连接结束（CE）消息的连接终止表示连接过早关闭，可能是在关闭方代理事先不知道或无意的情况下关闭的。当OCP代理检测到过早关闭的连接时，该代理必须像接收到指示故障的连接结束（CE）消息一样工作。
A Connection End (CE) message implies the end of all transactions, negotiations, and service groups opened or active on the connection being ended.
Connection End（CE）消息表示在要结束的连接上打开或活动的所有事务、协商和服务组的结束。
SGC: extends message with {
my-sg-id services;
};
SGC: extends message with {
my-sg-id services;
};
A Service Group Created (SGC) message informs the recipient that a list of adaptation services has been associated with the given service group identifier ("my-sg-id"). Following this message, the sender can refer to the group by using the identifier. The recipient MUST maintain the association until a matching Service Group Destroyed (SGD) message is received or the corresponding OCP connection is closed.
服务组创建（SGC）消息通知接收者一个适配服务列表已与给定的服务组标识符（“我的sg id”）关联。在该消息之后，发送方可以使用标识符引用该组。收件人必须保持关联，直到收到匹配的服务组销毁（SGD）消息或相应的OCP连接关闭。
Service groups have a connection scope. Transaction management messages do not affect existing service groups.
服务组具有连接作用域。事务管理消息不会影响现有服务组。
Maintaining service group associations requires resources (e.g., storage to keep the group identifier and a list of service IDs). Thus, there is a finite number of associations an implementation can maintain. Callout servers MUST be able to maintain at least one association for each OCP connection they accept. If a recipient of a Service Group Created (SGC) message does not create the requested association, it MUST immediately terminate the connection with a Connection End (CE) message indicating a failure.
维护服务组关联需要资源（例如，保存组标识符和服务ID列表的存储）。因此，一个实现可以维护的关联数量是有限的。调出服务器必须能够为其接受的每个OCP连接维护至少一个关联。如果已创建服务组（SGC）消息的收件人未创建所请求的关联，则必须立即终止连接，并显示连接结束（CE）消息，表明连接失败。
SGD: extends message with {
my-sg-id;
};
SGD: extends message with {
my-sg-id;
};
A Service Group Destroyed (SGD) message instructs the recipient to forget about the service group associated with the specified identifier. The recipient MUST destroy the identified service group association.
服务组已销毁（SGD）消息指示收件人忘记与指定标识符关联的服务组。收件人必须销毁已标识的服务组关联。
TS: extends message with {
xid my-sg-id;
};
TS: extends message with {
xid my-sg-id;
};
Sent by an OPES processor, a Transaction Start (TS) message indicates the start of an OCP transaction. Upon receiving this message, the callout server MAY refuse further transaction processing by responding with a corresponding Transaction End (TE) message. A callout server MUST maintain the state until it receives a message indicating the end of the transaction or until it terminates the transaction itself.
由OPES处理器发送的事务开始（TS）消息表示OCP事务的开始。收到此消息后，调出服务器可以通过响应相应的事务结束（TE）消息来拒绝进一步的事务处理。调出服务器必须保持该状态，直到它收到指示事务结束的消息或直到它终止事务本身。
The required "my-sg-id" identifier refers to a service group created with an a Service Group Created (SGC) message. The callout server MUST apply the list of services associated with "my-sg-id", in the specified order.
所需的“my sg id”标识符是指使用服务组创建（SGC）消息创建的服务组。调出服务器必须按指定顺序应用与“我的sg id”关联的服务列表。
This message introduces the transaction identifier (xid).
此消息引入事务标识符（xid）。
TE: extends message with {
xid [result];
};
TE: extends message with {
xid [result];
};
A Transaction End (TE) indicates the end of the identified OCP transaction.
事务结束（TE）表示已识别OCP事务的结束。
An OCP agent MUST send a Transaction End (TE) message immediately after it makes a decision to send no more messages related to the corresponding transaction. Violating this requirement may cause, for
OCP代理必须在决定不再发送与相应事务相关的消息后立即发送事务结束（TE）消息。违反此要求可能导致
example, unnecessary delays, rejection of new transactions, and even timeouts for agents that rely on this end-of-file condition to proceed.
例如，不必要的延迟、拒绝新事务，甚至依赖此文件结束条件继续的代理超时。
This message terminates the life of the transaction identifier (xid).
此消息终止事务标识符（xid）的生命周期。
AMS: extends message with {
xid;
[Services: services];
};
AMS: extends message with {
xid;
[Services: services];
};
An Application Message Start (AMS) message indicates the start of the original or adapted application message processing and dataflow. The recipient MAY refuse further processing by sending an Application Message End (AME) message indicating a failure.
应用程序消息开始（AMS）消息表示原始或修改的应用程序消息处理和数据流的开始。接收方可以通过发送指示失败的应用程序消息结束（AME）消息来拒绝进一步处理。
When an AMS message is sent by the OPES processor, the callout server usually sends an AMS message back, announcing the creation of an adapted version of the original application message. This announcement may be delayed. For example, the callout server may wait for more information from the OPES processor.
当OPES处理器发送AMS消息时，调出服务器通常会发回AMS消息，宣布创建原始应用程序消息的改编版本。这项宣布可能会推迟。例如，callout server可能会等待来自OPES处理器的更多信息。
When an AMS message is sent by the callout server, an optional "Services" parameter describes OPES services that the server MAY apply to the original application message. Usually, the "services" value matches what was asked by the OPES processor. The callout server SHOULD send a "Services" parameter if its value would differ from the list of services requested by the OPES processor. As the same service may be known under many names, the mismatch does not necessarily imply an error.
当调出服务器发送AMS消息时，可选的“服务”参数描述服务器可应用于原始应用程序消息的OPES服务。通常，“服务”值与OPES处理器要求的值相匹配。如果调出服务器的值与OPES处理器请求的服务列表不同，则调出服务器应发送“服务”参数。由于同一服务可能有许多名称，因此不匹配不一定意味着错误。
AME: extends message with {
xid [result];
};
AME: extends message with {
xid [result];
};
An Application Message End (AME) message indicates the end of the original or adapted application message processing and dataflow. The recipient should expect no more data for the corresponding application message.
应用程序消息结束（AME）消息表示原始或修改的应用程序消息处理和数据流的结束。收件人不应期望相应的应用程序消息有更多数据。
An Application Message End (AME) message ends any data preservation commitments and any other state associated with the corresponding application message.
应用程序消息结束（AME）消息结束任何数据保留承诺以及与相应应用程序消息关联的任何其他状态。
An OCP agent MUST send an Application Message End (AME) message immediately after it makes a decision to stop processing of its application message. Violating this requirement may cause, for example, unnecessary delays, rejection of new transactions, and even timeouts for agents that rely on this end-of-file condition to proceed.
OCP代理必须在决定停止处理其应用程序消息后立即发送应用程序消息结束（AME）消息。例如，违反此要求可能会导致不必要的延迟、拒绝新事务，甚至导致依赖此文件结束条件继续进行的代理超时。
DUM: extends message with {
xid my-offset;
[As-is: org-offset];
[Kept: org-offset org-size ];
[Modp: modp];
} and payload;
DUM: extends message with {
xid my-offset;
[As-is: org-offset];
[Kept: org-offset org-size ];
[Modp: modp];
} and payload;
A Data Use Mine (DUM) message carries application data. It is the only OCP Core message with a documented payload. The sender MUST NOT make any gaps in data supplied by Data Use Mine (DUM) and Data Use Yours (DUY) messages (i.e., the my-offset of the next data message must be equal to the my-offset plus the payload size of the previous data message). Messages with gaps are invalid. The sender MUST send payload and MAY use empty payload (i.e., payload with zero size). A DUM message without payload is invalid. Empty payloads are useful for communicating meta-information about the data (e.g., modification predictions or preservation commitments) without sending data.
数据使用挖掘（DUM）消息携带应用程序数据。这是唯一一条OCP核心消息，具有记录的有效负载。发送方不得在data Use Mine（DUM）和data Use Yours（DUY）消息提供的数据中存在任何间隙（即，下一条数据消息的my偏移量必须等于my偏移量加上上上上一条数据消息的有效负载大小）。带有间隙的消息无效。发送方必须发送有效负载，并且可以使用空有效负载（即大小为零的有效负载）。没有有效负载的DUM消息无效。空有效载荷对于在不发送数据的情况下传递有关数据的元信息（例如，修改预测或保存承诺）非常有用。
An OPES processor MAY send a "Kept" parameter to indicate its current data preservation commitment (section 7) for original data. When an OPES processor sends a "Kept" parameter, the processor MUST keep a copy of the specified data (the preservation commitment starts or continues). The Kept offset parameter specifies the offset of the first octet of the preserved data. The Kept size parameter is the size of preserved data. Note that data preservation rules allow (i.e., do not prohibit) an OPES processor to decrease offset and to specify a data range not yet fully delivered to the callout server. OCP Core does not require any relationship between DUM payload and the "Kept" parameter.
OPES处理器可发送“保留”参数，以表明其对原始数据的当前数据保存承诺（第7节）。当OPES处理器发送“保留”参数时，处理器必须保留指定数据的副本（保存承诺开始或继续）。keep offset参数指定保留数据的第一个八位字节的偏移量。保留大小参数是保留数据的大小。请注意，数据保留规则允许（即，不禁止）OPES处理器减少偏移量，并指定尚未完全传递到callout服务器的数据范围。OCP核心不需要DUM有效载荷和“保持”参数之间的任何关系。
If the "Kept" parameter value violates data preservation rules but the recipient has not sent any Data Use Yours (DUY) messages for the given OCP transaction yet, then the recipient MUST NOT use any preserved data for the given transaction (i.e., must not sent any Data Use Yours (DUY) messages). If the "Kept" parameter value violates data preservation rules and the recipient has already sent Data Use Yours (DUY) messages, the DUM message is invalid, and the rules of section 5 apply. These requirements help preserve data integrity when "Kept" optimization is used by the OPES processor.
如果“keeped”参数值违反了数据保存规则，但收件人尚未为给定OCP事务发送任何数据使用您的（DUY）消息，则收件人不得为给定事务使用任何保留的数据（即，不得发送任何数据使用您的（DUY）消息）。如果“keeped”参数值违反了数据保存规则，并且收件人已经发送了数据使用您的（DUY）消息，则DUM消息无效，第5节的规则适用。当OPES处理器使用“保持”优化时，这些要求有助于保持数据完整性。
A callout server MUST send a "Modp" parameter if the server can provide a reliable value and has not already sent the same parameter value for the corresponding application message. The definition of "reliable" is entirely up to the callout server. The data modification prediction includes DUM payload. That is, if the attached payload has been modified, the modp value cannot be 0%.
如果调出服务器可以提供可靠的值，并且尚未为相应的应用程序消息发送相同的参数值，则调出服务器必须发送“Modp”参数。“可靠”的定义完全取决于调用服务器。数据修改预测包括DUM有效载荷。也就是说，如果已修改所连接的有效负载，则modp值不能为0%。
A callout server SHOULD send an "As-is" parameter if the attached data is identical to a fragment at the specified offset in the original dataflow. An "As-is" parameter specifying a data fragment that has not been sent to the callout server is invalid. The recipient MUST ignore invalid "As-is" parameters. Identical means that all adapted octets have the same numeric value as the corresponding original octets. This parameter is meant to allow for partial data preservation optimizations without a preservation commitment. The preserved data still crosses the connection with the callout server twice, but the OPES processor may be able to optimize its handling of the data.
如果附加数据与原始数据流中指定偏移量处的片段相同，则调出服务器应发送“原样”参数。指定尚未发送到callout server的数据片段的“原样”参数无效。收件人必须忽略无效的“原样”参数。相同意味着所有调整的八位字节与对应的原始八位字节具有相同的数值。此参数旨在允许在没有保留承诺的情况下进行部分数据保留优化。保留的数据仍然会两次穿过与callout服务器的连接，但OPES处理器可能能够优化其对数据的处理。
The OPES processor MUST NOT terminate its data preservation commitment (section 7) in reaction to receiving a Data Use Mine (DUM) message.
OPES处理方不得因收到数据使用地雷（DUM）信息而终止其数据保存承诺（第7节）。
DUY: extends message with {
xid org-offset org-size;
};
DUY: extends message with {
xid org-offset org-size;
};
The callout server tells the OPES processor to use the "size" bytes of preserved original data, starting at the specified offset, as if that data chunk came from the callout server in a Data Use Mine (DUM) message.
调出服务器通知OPES处理器使用保留原始数据的“大小”字节，从指定的偏移量开始，就像数据块来自调出服务器的数据使用挖掘（DUM）消息一样。
The OPES processor MUST NOT terminate its data preservation commitment (section 7) in reaction to receiving a Data Use Yours (DUY) message.
OPES处理方不得因收到数据使用（DUY）消息而终止其数据保存承诺（第7节）。
DPI: extends message with {
xid org-offset org-size;
};
DPI: extends message with {
xid org-offset org-size;
};
The Data Preservation Interest (DPI) message describes an original data chunk by using the first octet offset and size as parameters. The chunk is the only area of original data that the callout server may be interested in referring to in future Data Use Yours (DUY)
数据保存兴趣（DPI）消息通过使用第一个八位组偏移量和大小作为参数来描述原始数据块。区块是callout服务器在将来使用您的数据（DUY）时可能感兴趣引用的唯一原始数据区域
messages. This data chunk is referred to as "reusable data". The rest of the original data is referred to as "disposable data". Thus, disposable data consists of octets below the specified offset and at or above the (offset + size) offset.
信息。此数据块称为“可重用数据”。其余原始数据称为“一次性数据”。因此，一次性数据由低于指定偏移量且等于或高于（偏移量+大小）偏移量的八位字节组成。
After sending this message, the callout server MUST NOT send Data Use Yours (DUY) messages referring to disposable data chunk(s). If an OPES processor is not preserving some reusable data, it MAY start preserving that data. If an OPES processor preserves some disposable data, it MAY stop preserving that data. If an OPES processor does not preserve some disposable data, it MAY NOT start preserving that data.
发送此消息后，callout server不得发送引用一次性数据块的数据使用（DUY）消息。如果OPES处理器没有保存一些可重用的数据，它可能会开始保存这些数据。如果OPES处理器保留了一些一次性数据，它可能会停止保留这些数据。如果OPES处理器不保留某些一次性数据，它可能不会开始保留这些数据。
A callout server MUST NOT indicate reusable data areas that overlap with disposable data areas indicated in previous Data Preservation Interest (DPI) messages. In other words, reusable data must not grow, and disposable data must not shrink. If a callout server violates this rule, the Data Preservation Interest (DPI) message is invalid (see section 5).
调出服务器不得指示与以前的数据保留兴趣（DPI）消息中指示的一次性数据区域重叠的可重用数据区域。换言之，可重用数据不能增长，一次性数据不能收缩。如果调出服务器违反此规则，则数据保留兴趣（DPI）消息无效（请参阅第5节）。
The Data Preservation Interest (DPI) message cannot force the OPES processor to preserve data. In this context, the term reusable stands for callout server interest in reusing the data in the future, given the OPES processor cooperation.
数据保留兴趣（DPI）消息不能强制OPES处理器保留数据。在这种情况下，术语Reusables表示callout服务器对在未来重用数据感兴趣，因为OPES处理器合作。
For example, an offset value of zero and the size value of 2147483647 indicate that the server may want to reuse all the original data. The size value of zero indicates that the server is not going to send any more Data Use Yours (DUY) messages.
例如，偏移值为零和大小值为2147483647表示服务器可能希望重用所有原始数据。size值为零表示服务器将不再发送任何数据使用您的（DUY）消息。
DWSR: extends message with {
xid org-size;
};
DWSR: extends message with {
xid org-size;
};
The Want Stop Receiving Data (DWSR) message informs OPES processor that the callout server wants to stop receiving original data any time after receiving at least an org-size amount of an application message prefix. That is, the server is asking the processor to terminate original dataflow prematurely (see section 8.1) after sending at least org-size octets.
Want Stop Receiving Data（DWSR）消息通知OPES processor callout server在收到至少一个组织大小的应用程序消息前缀后，希望随时停止接收原始数据。也就是说，在发送至少组织大小的八位字节后，服务器要求处理器提前终止原始数据流（参见第8.1节）。
An OPES processor receiving a Want Stop Receiving Data (DWSR) message SHOULD terminate original dataflow by sending an Application Message End (AME) message with a 206 (partial) status code.
接收到Want Stop receiving Data（DWSR）消息的OPES处理器应通过发送带有206（部分）状态代码的应用程序消息结束（AME）消息来终止原始数据流。
An OPES processor MUST NOT terminate its data preservation commitment (section 7) in reaction to receiving a Want Stop Receiving Data (DWSR) message. Just like with any other message, an OPES processor may use information supplied by Want Stop Receiving Data (DWSR) to decide on future preservation commitments.
OPES处理方不得在收到想要停止接收数据（DWSR）消息时终止其数据保存承诺（第7节）。与任何其他消息一样，OPES处理器可以使用Want Stop Receiving Data（DWSR）提供的信息来决定未来的保存承诺。
DWSS: extends message with {
xid;
};
DWSS: extends message with {
xid;
};
The Want Stop Sending Data (DWSS) message informs the OPES processor that the callout server wants to stop sending adapted data as soon as possible; the server is asking the processor for permission to terminate adapted dataflow prematurely (see section 8.2). The OPES processor can grant this permission by using a Stop Sending Data (DSS) message.
Want Stop Sending Data（DWSS）消息通知OPES处理器callout server希望尽快停止发送适配数据；服务器请求处理器允许提前终止适配数据流（参见第8.2节）。OPES处理器可通过使用停止发送数据（DSS）消息授予此权限。
Once the DWSS message is sent, the callout server MUST NOT prematurely terminate adapted dataflow until the server receives a DSS message from the OPES processor. If the server violates this rule, the OPES processor MUST act as if no DWSS message were received. The latter implies that the OCP transaction is terminated by the processor, with an error.
DWSS消息发送后，callout服务器不得过早终止适配数据流，直到服务器从OPES处理器接收到DSS消息。如果服务器违反此规则，则OPES处理器必须像未收到DWSS消息一样工作。后者意味着OCP事务由处理器终止，并出现错误。
An OPES processor receiving a DWSS message SHOULD respond with a Stop Sending Data (DSS) message, provided the processor would not violate DSS message requirements by doing so. The processor SHOULD respond immediately once DSS message requirements can be satisfied.
接收DWSS消息的OPES处理器应响应停止发送数据（DSS）消息，前提是处理器这样做不会违反DSS消息要求。一旦DSS消息要求得到满足，处理器应立即响应。
DSS: extends message with {
xid;
};
DSS: extends message with {
xid;
};
The Stop Sending Data (DSS) message instructs the callout server to terminate adapted dataflow prematurely by sending an Application Message End (AME) message with a 206 (partial) status code. A callout server is expected to solicit the Stop Sending Data (DSS) message by sending a Want Stop Sending Data (DWSS) message (see section 8.2).
停止发送数据（DSS）消息通过发送带有206（部分）状态代码的应用程序消息结束（AME）消息，指示调出服务器提前终止适配数据流。呼叫服务器应通过发送想要停止发送数据（DWSS）消息来请求停止发送数据（DSS）消息（参见第8.2节）。
A callout server receiving a solicited Stop Sending Data (DSS) message for a yet-unterminated adapted dataflow MUST immediately terminate dataflow by sending an Application Message End (AME) message with a 206 (partial) status code. If the callout server
接收到尚未终止的适配数据流的请求停止发送数据（DSS）消息的调出服务器必须通过发送带有206（部分）状态代码的应用程序消息结束（AME）消息立即终止数据流。如果调用服务器
already terminated adapted dataflow, the callout server MUST ignore the Stop Sending Data (DSS) message. A callout server receiving an unsolicited DSS message for a yet-unterminated adapted dataflow MUST either treat that message as invalid or as solicited (i.e., the server cannot simply ignore unsolicited DSS messages).
调出服务器已终止数据流，必须忽略停止发送数据（DSS）消息。对于尚未终止的适配数据流，接收未经请求的DSS消息的调出服务器必须将该消息视为无效消息或请求消息（即，服务器不能简单地忽略未经请求的DSS消息）。
The OPES processor sending a Stop Sending Data (DSS) message MUST be able to reconstruct the adapted application message correctly after the callout server terminates dataflow. This requirement implies that the processor must have access to any original data sent to the callout after the Stop Sending Data (DSS) message, if there is any. Consequently, the OPES processor either has to send no data at all or has to keep a copy of it.
在调出服务器终止数据流后，发送停止发送数据（DSS）消息的OPES处理器必须能够正确地重构适配的应用程序消息。此要求意味着，如果存在任何原始数据，则处理器必须能够访问在停止发送数据（DSS）消息后发送到调用的任何原始数据。因此，OPES处理器要么根本不发送数据，要么保留数据副本。
If a callout server receives a DSS message and, in violation of the above rules, waits for more original data before sending an Application Message End (AME) response, a deadlock may occur: The OPES processor may wait for the Application Message End (AME) message to send more original data.
如果调出服务器收到DSS消息，并且违反上述规则，在发送应用程序消息结束（AME）响应之前等待更多原始数据，则可能发生死锁：OPES处理器可能等待应用程序消息结束（AME）消息发送更多原始数据。
DWP: extends message with {
xid your-offset;
};
DWP: extends message with {
xid your-offset;
};
The Want Data Paused (DWP) message indicates the sender's temporary lack of interest in receiving data starting with the specified offset. This disinterest implies nothing about sender's intent to send data.
Want Data Paused（DWP）消息表示发送方暂时对接收从指定偏移量开始的数据不感兴趣。这种不感兴趣并不意味着发送者发送数据的意图。
The "your-offset" parameter refers to dataflow originating at the OCP agent receiving the parameter.
“your offset”参数指的是在接收该参数的OCP代理处发起的数据流。
If, at the time the Want Data Paused (DWP) message is received, the recipient has already sent data at the specified offset, the message recipient MUST stop sending data immediately. Otherwise, the recipient MUST stop sending data immediately after it sends the specified offset. Once the recipient stops sending more data, it MUST immediately send a Paused My Data (DPM) message and MUST NOT send more data until it receives a Want More Data (DWM) message.
如果在收到Want Data Paused（DWP）消息时，收件人已按指定的偏移量发送数据，则消息收件人必须立即停止发送数据。否则，收件人必须在发送指定偏移量后立即停止发送数据。一旦收件人停止发送更多数据，必须立即发送暂停的“我的数据”（DPM）消息，并且在收到“需要更多数据”（DWM）消息之前不得发送更多数据。
As are most OCP Core mechanisms, data pausing is asynchronous. The sender of the Want Data Paused (DWP) message MUST NOT rely on the data being paused exactly at the specified offset or at all.
与大多数OCP核心机制一样，数据暂停也是异步的。Want Data Paused（DWP）消息的发送方不能完全依赖于在指定偏移量处暂停的数据，或者根本不依赖于暂停的数据。
DPM: extends message with {
xid;
};
DPM: extends message with {
xid;
};
The Paused My Data (DPM) message indicates the sender's commitment to send no more data until the sender receives a Want More Data (DWM) message.
暂停我的数据（DPM）消息表示发件人承诺在收到“需要更多数据”（DWM）消息之前不再发送数据。
The recipient of the Paused My Data (DPM) message MAY expect the data delivery being paused. If the recipient receives data despite this expectation, it MAY abort the corresponding transaction with a Transaction End (TE) message indicating a failure.
已暂停的我的数据（DPM）邮件的收件人可能希望暂停数据传递。如果接收方接收到数据，尽管有此预期，它可能会中止相应的事务，并显示一条表示失败的事务结束（TE）消息。
DWM: extends message with {
xid;
[Size-request: your-size];
};
DWM: extends message with {
xid;
[Size-request: your-size];
};
The Want More Data (DWM) message indicates the sender's need for more data.
“需要更多数据”（DWM）消息表示发件人需要更多数据。
Message parameters always refer to dataflow originating at the other OCP agent. When sent by an OPES processor, your-size is adp-size; when sent by a callout server, your-size is org-size.
消息参数总是指源自其他OCP代理的数据流。当由OPES处理器发送时，您的大小为adp大小；由调用服务器发送时，您的大小为组织大小。
The "Size-request" parameter refers to dataflow originating at the OCP agent receiving the parameter. If a "Size-request" parameter is present, its value is the suggested minimum data size. It is meant to allow the recipient to deliver data in fewer chunks. The recipient MAY ignore the "Size-request" parameter. An absent "Size-request" parameter implies "any size".
“Size request”参数指的是在接收该参数的OCP代理处发起的数据流。如果存在“大小请求”参数，则其值为建议的最小数据大小。这意味着允许收件人以更少的数据块交付数据。收件人可以忽略“大小请求”参数。缺少“大小请求”参数意味着“任意大小”。
The message also cancels the Paused My Data (DPM) message effect. If the recipient was not sending any data because of its DPM message, the recipient MAY resume sending data. Note, however, that the Want More Data (DWM) message can be sent regardless of whether the dataflow in question has been paused. The "Size-request" parameter makes this message a useful stand-alone optimization.
该消息还取消暂停我的数据（DPM）消息的效果。如果收件人由于其DPM消息而未发送任何数据，则收件人可以继续发送数据。但是，请注意，无论相关数据流是否已暂停，都可以发送“需要更多数据”（DWM）消息。“Size request”参数使此消息成为有用的独立优化。
NO: extends message with {
features;
[SG: my-sg-id];
[Offer-Pending: boolean];
};
NO: extends message with {
features;
[SG: my-sg-id];
[Offer-Pending: boolean];
};
A Negotiation Offer (NO) message solicits a selection of a single "best" feature out of a supplied list, using a Negotiation Response (NR) message. The sender is expected to list preferred features first when it is possible. The recipient MAY ignore sender preferences. If the list of features is empty, the negotiation is bound to fail but remains valid.
协商报价（NO）消息使用协商响应（NR）消息从提供的列表中选择单个“最佳”功能。如果可能，发送方应首先列出首选功能。收件人可以忽略发件人首选项。如果功能列表为空，则协商肯定会失败，但仍然有效。
Both the OPES processor and the callout server are allowed to send Negotiation Offer (NO) messages. The rules in this section ensure that only one offer is honored if two offers are submitted concurrently. An agent MUST NOT send a Negotiation Offer (NO) message if it still expects a response to its previous offer on the same connection.
OPES处理器和callout服务器都可以发送协商报价（NO）消息。本节中的规则确保，如果同时提交两份报价，则只接受一份报价。如果代理仍希望在同一连接上收到对其先前报价的响应，则不得发送协商报价（NO）消息。
If an OPES processor receives a Negotiation Offer (NO) message while its own offer is pending, the processor MUST disregard the server offer. Otherwise, it MUST respond immediately.
如果OPES处理器在其自己的报价待定时收到协商报价（NO）消息，则处理器必须忽略服务器报价。否则，它必须立即作出反应。
If a callout server receives a Negotiation Offer (NO) message when its own offer is pending, the server MUST disregard its own offer. In either case, the server MUST respond immediately.
如果调出服务器在其自己的报价挂起时收到协商报价（NO）消息，则服务器必须忽略其自己的报价。无论哪种情况，服务器都必须立即响应。
If an agent receives a message sequence that violates any of the above rules in this section, the agent MUST terminate the connection with a Connection End (CE) message indicating a failure.
如果代理接收到的消息序列违反了本节中的上述任何规则，则代理必须使用指示故障的连接结束（CE）消息终止连接。
An optional "Offer-Pending" parameter is used for Negotiation Phase maintenance (section 6.1). The option's value defaults to "false".
可选的“报价待定”参数用于谈判阶段维护（第6.1节）。该选项的值默认为“false”。
An optional "SG" parameter is used to narrow the scope of negotiations to the specified service group. If SG is present, the negotiated features are negotiated and enabled only for transactions that use the specified service group ID. Connection-scoped features are negotiated and enabled for all service groups. The presence of scope does not imply automatic conflict resolution common to programming languages; no conflicts are allowed. When negotiating connection-scoped features, an agent MUST check for conflicts within each existing service group. When negotiating group-scoped features, an agent MUST check for conflicts with connection-scoped features
可选的“SG”参数用于将协商范围缩小到指定的服务组。如果存在SG，则仅针对使用指定服务组ID的事务协商和启用协商功能。针对所有服务组协商和启用连接作用域功能。作用域的存在并不意味着编程语言通用的自动冲突解决；不允许有冲突。协商连接范围的功能时，代理必须检查每个现有服务组中是否存在冲突。协商组范围的功能时，代理必须检查是否与连接范围的功能冲突
already negotiated. For example, it must not be possible to negotiate a connection-scoped HTTP application profile if one service group already has an SMTP application profile, and vice versa.
已经谈判过了。例如，如果一个服务组已经有SMTP应用程序配置文件，则不能协商连接范围的HTTP应用程序配置文件，反之亦然。
OCP agents SHOULD NOT send offers with service groups used by pending transactions. Unless it is explicitly noted otherwise in a feature documentation, OCP agents MUST NOT apply any negotiations to pending transactions. In other words, negotiated features take effect with the new OCP transaction.
OCP代理不应发送包含挂起事务使用的服务组的报价。除非在功能文档中另有明确说明，否则OCP代理不得对未决交易进行任何协商。换句话说，协商的特性在新的OCP事务中生效。
As with other protocol elements, OCP Core extensions may document additional negotiation restrictions. For example, specification of a transport security feature may prohibit the use of the SG parameter in negotiation offers, to avoid situations where encryption is enabled for only a portion of overlapping transactions on the same transport connection.
与其他协议元素一样，OCP核心扩展可能会记录额外的协商限制。例如，传输安全特性的规范可能禁止在协商报价中使用SG参数，以避免仅对同一传输连接上的重叠事务的一部分启用加密的情况。
NR: extends message with {
[feature];
[SG: my-sg-id];
[Rejects: features];
[Unknowns: features];
[Offer-Pending: boolean];
};
NR: extends message with {
[feature];
[SG: my-sg-id];
[Rejects: features];
[Unknowns: features];
[Offer-Pending: boolean];
};
A Negotiation Response (NR) message conveys recipient's reaction to a Negotiation Offer (NO) request. An accepted offer (a.k.a., positive response) is indicated by the presence of an anonymous "feature" parameter, containing the selected feature. If the selected feature does not match any of the offered features, the offering agent MUST consider negotiation failed and MAY terminate the connection with a Connection End (CE) message indicating a failure.
协商响应（NR）消息传达收件人对协商报价（NO）请求的反应。接受的报价（也称为肯定响应）通过存在匿名“特征”参数表示，该参数包含所选特征。如果所选择的特征与所提供的任何特征不匹配，则提供代理必须考虑协商失败，并且可以终止与指示失败的连接端（CE）消息的连接。
A rejected offer (negative response) is indicated by omitting the anonymous "feature" parameter.
拒绝的报价（否定响应）通过省略匿名“feature”参数表示。
The successfully negotiated feature becomes effective immediately. The sender of a positive response MUST consider the corresponding feature enabled immediately after the response is sent; the recipient of a positive response MUST consider the corresponding feature enabled immediately after the response is received. Note that the scope of the negotiated feature application may be limited to a specified service group. The negotiation phase state does not affect enabling of the feature.
协商成功的功能立即生效。正响应的发送者必须考虑响应发送后立即启用的相应特征；正响应的接收者必须考虑在接收到响应之后立即启用的相应特征。请注意，协商功能应用程序的范围可能仅限于指定的服务组。协商阶段状态不影响功能的启用。
If negotiation offer contains an SG parameter, the responder MUST include that parameter in the Negotiation Response (NR) message. The recipient of an NR message without the expected SG parameter MUST treat negotiation response as invalid.
如果协商报价包含SG参数，响应者必须在协商响应（NR）消息中包含该参数。没有预期SG参数的NR消息的收件人必须将协商响应视为无效。
If the negotiation offer lacks an SG parameter, the responder MUST NOT include that parameter in the Negotiation Response (NR) message. The recipient of an NR message with an unexpected SG parameter MUST treat the negotiation response as invalid.
如果协商要约缺少SG参数，则响应者不得在协商响应（NR）消息中包含该参数。具有意外SG参数的NR消息的收件人必须将协商响应视为无效。
An optional "Offer-Pending" parameter is used for Negotiation Phase maintenance (section 6.1). The option's value defaults to "false".
可选的“报价待定”参数用于谈判阶段维护（第6.1节）。该选项的值默认为“false”。
When accepting or rejecting an offer, the sender of the Negotiation Response (NR) message MAY supply additional details via Rejects and Unknowns parameters. The Rejects parameter can be used to list features that were known to the Negotiation Offer (NO) recipient but could not be supported given negotiated state that existed when NO message was received. The Unknowns parameter can be used to list features that were unknown to the NO recipient.
在接受或拒绝报价时，协商响应（NR）消息的发送方可以通过拒绝和未知参数提供额外的详细信息。Rejects参数可用于列出谈判报价（NO）接收者已知但由于在未收到邮件时存在的谈判状态而无法支持的功能。Unknowns参数可用于列出无收件人未知的功能。
AQ: extends message with {
feature;
};
AQ: extends message with {
feature;
};
An Ability Query (AQ) message solicits an immediate Ability Answer (AA) response. The recipient MUST respond immediately with an AA message. This is a read-only, non-modifying interface. The recipient MUST NOT enable or disable any features due to an AQ request.
能力查询（AQ）消息请求立即能力应答（AA）响应。收件人必须立即回复AA信息。这是一个只读、不可修改的接口。收件人不得因AQ请求而启用或禁用任何功能。
OCP extensions documenting a feature MAY extend AQ messages to supply additional information about the feature or the query itself.
记录特性的OCP扩展可以扩展AQ消息，以提供有关特性或查询本身的附加信息。
The primary intended purpose of the ability inquiry interface is debugging and troubleshooting and not automated fine-tuning of agent behavior and configuration. The latter may be better achieved by the OCP negotiation mechanism (section 6).
能力查询接口的主要目的是调试和故障排除，而不是自动微调代理行为和配置。后者可以通过OCP谈判机制更好地实现（第6节）。
AA: extends message with {
boolean;
};
AA: extends message with {
boolean;
};
An Ability Answer (AA) message expresses the sender's support for a feature requested via an Ability Query (AQ) message. The sender MUST set the value of the anonymous boolean parameter to the truthfulness of the following statement: "At the time of this answer generation, the sender supports the feature in question". The meaning of "support" and additional details are feature specific. OCP extensions documenting a feature MUST document the definition of "support" in the scope of the above statement and MAY extend AA messages to supply additional information about the feature or the answer itself.
能力应答（AA）消息表示发送方支持通过能力查询（AQ）消息请求的功能。发送方必须将匿名布尔参数的值设置为以下语句的真实性：“在生成此答案时，发送方支持有问题的功能”。“支持”和其他细节的含义是特定于功能的。记录功能的OCP扩展必须记录上述声明范围内的“支持”定义，并且可以扩展AA消息以提供有关功能或答案本身的附加信息。
PQ: extends message with {
[xid];
};
PQ: extends message with {
[xid];
};
A Progress Query (PQ) message solicits an immediate Progress Answer (PA) response. The recipient MUST immediately respond to a PQ request, even if the transaction identifier is invalid from the recipient's point of view.
进度查询（PQ）消息请求立即进度应答（PA）响应。接收方必须立即响应PQ请求，即使从接收方的角度来看交易标识符无效。
PA: extends message with {
[xid];
[Org-Data: org-size];
};
PA: extends message with {
[xid];
[Org-Data: org-size];
};
A PA message carries the sender's state. The "Org-Data" size is the total original data size received or sent by the agent so far for the identified application message (an agent can be either sending or receiving original data, so there is no ambiguity). When referring to received data, progress information does not imply that the data has otherwise been processed in some way.
PA消息携带发送者的状态。“组织数据”大小是代理迄今为止为已识别的应用程序消息接收或发送的原始数据总大小（代理可以发送或接收原始数据，因此不存在歧义）。当参考收到的数据时，进度信息并不意味着数据已经以某种方式进行了处理。
The progress inquiry interface is useful for several purposes, including keeping idle OCP connections "alive", gauging the agent processing speed, verifying the agent's progress, and debugging OCP communications. Verifying progress, for example, may be essential to implement timeouts for callout servers that do not send any adapted data until the entire original application message is received and processed.
进度查询接口有多种用途，包括保持空闲OCP连接“活动”、测量代理处理速度、验证代理的进度以及调试OCP通信。例如，验证进度对于在接收和处理整个原始应用程序消息之前不发送任何调整数据的调出服务器实施超时可能至关重要。
A recipient of a PA message MUST NOT assume that the sender is not working on any transaction or application message not identified in the PA message. A PA message does not carry information about multiple transactions or application messages.
PA消息的接收者不得假设发送者未处理PA消息中未标识的任何事务或应用程序消息。PA消息不包含有关多个事务或应用程序消息的信息。
If an agent is working on the transaction identified in the Progress Query (PQ) request, the agent MUST send the corresponding transaction ID (xid) when answering the PQ with a PA message. Otherwise, the agent MUST NOT send the transaction ID. If an agent is working on the original application message for the specified transaction, the agent MUST send the Org-Data parameter. If the agent has already sent or received the Application Message End (AME) message for the original dataflow, the agent MUST NOT send the Org-data parameter.
如果代理正在处理进度查询（PQ）请求中标识的事务，则代理在用PA消息回答PQ时必须发送相应的事务ID（xid）。否则，代理不得发送事务ID。如果代理正在处理指定事务的原始应用程序消息，则代理必须发送Org Data参数。如果代理已发送或接收原始数据流的应用程序消息结束（AME）消息，则代理不得发送Org data参数。
Informally, the PA message relays the sender's progress with the transaction and original dataflow identified by the Progress Query (PQ) message, provided the transaction identifier is still valid at the time of the answer. Absent information in the answer indicates invalid, unknown, or closed transaction and/or original dataflow from the query recipient's point of view.
非正式地说，PA消息通过进程查询（PQ）消息标识的事务和原始数据流传递发送方的进程，前提是事务标识符在应答时仍然有效。答案中缺少信息表示从查询接收方的角度来看，无效、未知或已关闭的事务和/或原始数据流。
PR: extends message with {
[xid];
[Org-Data: org-size];
};
PR: extends message with {
[xid];
[Org-Data: org-size];
};
A Progress Report (PR) message carries the sender's state. The message semantics and associated requirements are identical to those of a Progress Answer (PA) message except that the PR message, is sent unsolicited. The sender MAY report progress at any time. The sender MAY report progress unrelated to any transaction or original application message or related to any valid (current) transaction or original dataflow.
进度报告（PR）消息包含发件人的状态。消息语义和相关要求与进度应答（PA）消息的语义和相关要求相同，只是PR消息是主动发送的。发件人可随时报告进度。发送方可报告与任何交易或原始应用程序消息无关的进度，或与任何有效（当前）交易或原始数据流相关的进度。
Unsolicited progress reports are especially useful for OCP extensions dealing with "slow" callout services that introduce significant delays for the final application message recipient. The report may contain progress information that will make that final recipient more delay tolerant.
未经请求的进度报告对于处理“缓慢”调出服务的OCP扩展特别有用，这会给最终应用程序消息接收者带来严重延迟。报告可能包含进度信息，使最终接收者更能容忍延迟。
OPES treatment of IETF Internet Architecture Board (IAB) considerations [RFC3238] are documented in [RFC3914].
IETF互联网体系结构委员会（IAB）注意事项的OPE处理[RFC3238]记录在[RFC3914]中。
This section examines security considerations for OCP. OPES threats are documented in [RFC3837]
本节探讨OCP的安全注意事项。[RFC3837]中记录了OPES威胁
OCP relays application messages that may contain sensitive information. Appropriate transport encryption can be negotiated to prevent information leakage or modification (see section 6), but OCP agents may support unencrypted transport by default. These configurations will expose application messages to third-party recording and modification, even if OPES proxies themselves are secure.
OCP中继可能包含敏感信息的应用程序消息。可以协商适当的传输加密以防止信息泄漏或修改（参见第6节），但OCP代理默认情况下可能支持未加密的传输。这些配置将向第三方记录和修改应用程序消息，即使OPES代理本身是安全的。
OCP implementation bugs may lead to security vulnerabilities in OCP agents, even if OCP traffic itself remains secure. For example, a buffer overflow in a callout server caused by a malicious OPES processor may grant that processor access to information from other (100% secure) OCP connections, including connections with other OPES processors.
OCP实现缺陷可能导致OCP代理中存在安全漏洞，即使OCP流量本身保持安全。例如，恶意OPES处理器导致callout服务器中的缓冲区溢出可能会授予该处理器从其他（100%安全）OCP连接（包括与其他OPES处理器的连接）访问信息的权限。
Careless OCP implementations may rely on various OCP identifiers to be unique across all OCP agents. A malicious agent can inject an OCP message that matches identifiers used by other agents, in an attempt to gain access to sensitive data. OCP implementations must always check an identifier for being "local" to the corresponding connection before using that identifier.
粗心的OCP实现可能依赖于各种OCP标识符，使其在所有OCP代理中都是唯一的。恶意代理可以插入与其他代理使用的标识符匹配的OCP消息，以尝试访问敏感数据。OCP实现在使用该标识符之前，必须始终检查该标识符是否为对应连接的“本地”。
OCP is a stateful protocol. Several OCP commands increase the amount of state that the recipient has to maintain. For example, a Service Group Created (SGC) message instructs the recipient to maintain an association between a service group identifier and a list of services.
OCP是一种有状态协议。几个OCP命令增加了收件人必须维护的状态量。例如，服务组创建（SGC）消息指示收件人维护服务组标识符和服务列表之间的关联。
Implementations that cannot correctly handle resource exhaustion increase security risks. The following are known OCP-related resources that may be exhausted during a compliant OCP message exchange:
无法正确处理资源耗尽的实现会增加安全风险。以下是在兼容OCP消息交换期间可能耗尽的已知OCP相关资源：
OCP message structures: OCP message syntax does not limit the nesting depth of OCP message structures and does not place an upper limit on the length (number of OCTETs) of most syntax elements.
OCP消息结构：OCP消息语法不限制OCP消息结构的嵌套深度，也不限制大多数语法元素的长度（八位字节数）。
concurrent connections: OCP does not place an upper limit on the number of concurrent connections that a callout server may be instructed to create via Connection Start (CS) messages.
并发连接：OCP没有对呼叫服务器可能通过连接启动（CS）消息被指示创建的并发连接数设置上限。
service groups: OCP does not place an upper limit on the number of service group associations that a callout server may be instructed to create via Service Group Created (SGC) messages.
服务组：OCP没有对呼叫服务器可能通过服务组创建（SGC）消息被指示创建的服务组关联的数量设置上限。
concurrent transactions: OCP does not place an upper limit on the number of concurrent transactions that a callout server may be instructed to maintain via Transaction Start (TS) messages.
并发事务：OCP没有对调用服务器可能通过事务开始（TS）消息被指示维护的并发事务数设置上限。
concurrent flows: OCP Core does not place an upper limit on the number of concurrent adapted flows that an OPES processor may be instructed to maintain via Application Message Start (AMS) messages.
并发流：OCP Core没有对OPES处理器可能通过应用程序消息启动（AMS）消息被指示维护的并发适配流的数量设置上限。
The IANA maintains a list of OCP features, including application profiles (section 10.11). For each feature, its uri parameter value is registered along with the extension parameters (if there are any). Registered feature syntax and semantics are documented with PETDM notation (section 9).
IANA维护OCP功能列表，包括应用程序配置文件（第10.11节）。对于每个特性，其uri参数值与扩展参数（如果有）一起注册。注册的特征语法和语义用PETDM符号记录（第9节）。
The IESG is responsible for assigning a designated expert to review each standards-track registration prior to IANA assignment. The OPES working group mailing list may be used to solicit commentary for both standards-track and non-standards-track features.
IESG负责在IANA分配之前指派一名指定专家审查每个标准跟踪登记。OPES工作组邮件列表可用于征求标准轨道和非标准轨道特征的评论。
Standards-track OCP Core extensions SHOULD use http://www.iana.org/assignments/opes/ocp/ prefix for feature uri parameters. It is suggested that the IANA populate resources identified by such "uri" parameters with corresponding feature registrations. It is also suggested that the IANA maintain an index of all registered OCP features at the http://www.iana.org/assignments/opes/ocp/ URL or on a page linked from that URL.
标准轨道OCP核心扩展应使用http://www.iana.org/assignments/opes/ocp/ 功能uri参数的前缀。建议IANA使用相应的特征注册填充由此类“uri”参数标识的资源。此外，还建议IANA在站点上维护所有已注册OCP功能的索引http://www.iana.org/assignments/opes/ocp/ URL或从该URL链接的页面上。
This specification defines no OCP features for IANA registration.
本规范未定义IANA注册的OCP功能。
This specification defines compliance for the following compliance subjects: OPES processors (OCP client implementations), callout servers (OCP server implementations), and OCP extensions. An OCP agent (a processor or callout server) may also be referred to as the "sender" or "recipient" of an OCP message.
本规范定义了以下合规主题的合规性：OPES处理器（OCP客户端实现）、调出服务器（OCP服务器实现）和OCP扩展。OCP代理（处理者或调出服务器）也可以称为OCP消息的“发送者”或“接收者”。
A compliance subject is compliant if it satisfies all applicable "MUST" and "SHOULD" requirements. By definition, to satisfy a "MUST" requirement means to act as prescribed by the requirement; to satisfy a "SHOULD" requirement means either to act as prescribed by the requirement or to have a reason to act differently. A requirement is applicable to the subject if it instructs (addresses) the subject.
合规主体如果满足所有适用的“必须”和“应该”要求，则为合规主体。根据定义，满足“必须”要求意味着按照要求的规定行事；满足“应该”要求意味着要么按照要求的规定行事，要么有理由采取不同的行动。如果要求指示（说明）主题，则要求适用于主题。
Informally, OCP compliance means that there are no known "MUST" violations, and that all "SHOULD" violations are deliberate. In other words, "SHOULD" means "MUST satisfy or MUST have a reason to violate". It is expected that compliance claims be accompanied by a
非正式地说，OCP合规性意味着没有已知的“必须”违反行为，所有“应该”违反行为都是故意的。换句话说，“应该”意味着“必须满足或必须有理由违反”。预计合规性声明应附有
list of unsupported SHOULDs (if any), in an appropriate format, explaining why the preferred behavior was not chosen.
以适当格式列出不受支持的应选项（如果有），解释为何未选择首选行为。
Only normative parts of this specification affect compliance. Normative parts are those parts explicitly marked with the word "normative", definitions, and phrases containing unquoted capitalized keywords from [RFC2119]. Consequently, examples and illustrations are not normative.
只有本规范的规范性部分影响合规性。规范性部分是那些明确标有“规范性”一词、定义和短语的部分，其中包含[RFC2119]中未引用的大写关键词。因此，示例和说明不具有规范性。
OCP extensions MUST NOT change the OCP Core message format, as defined by ABNF and accompanying normative rules in Section 3.1. This requirement is intended to allow OCP message viewers, validators, and "intermediary" software to at least isolate and decompose any OCP message, even a message with semantics unknown to them (i.e., extended).
OCP扩展不得更改ABNF和第3.1节随附规范性规则定义的OCP核心消息格式。该要求旨在允许OCP消息查看器、验证器和“中介”软件至少隔离和分解任何OCP消息，即使是语义未知（即扩展）的消息。
OCP extensions are allowed to change normative OCP Core requirements for OPES processors and callout servers. However, OCP extensions SHOULD NOT make these changes and MUST require on a "MUST"-level that these changes are negotiated prior to taking effect. Informally, this specification defines compliant OCP agent behavior until changes to this specification (if any) are successfully negotiated.
OCP扩展允许更改OPES处理器和调用服务器的标准OCP核心要求。但是，OCP扩展不应进行这些更改，必须在“必须”级别上要求这些更改在生效之前经过协商。非正式地说，本规范定义了兼容的OCP代理行为，直到成功协商对本规范的更改（如果有）。
For example, if an RTSP profile for OCP requires support for offsets exceeding 2147483647 octets, the profile specification can document appropriate OCP changes while requiring that RTSP adaptation agents negotiate "large offsets" support before using large offsets. This negotiation can be bundled with negotiating another feature (e.g., negotiating an RTSP profile may imply support for "large offsets").
例如，如果OCP的RTSP配置文件要求支持超过2147483647个八位字节的偏移量，则配置文件规范可以记录适当的OCP更改，同时要求RTSP适配代理在使用大偏移量之前协商“大偏移量”支持。这种协商可以与协商另一个功能捆绑在一起（例如，协商RTSP配置文件可能意味着支持“大偏移”）。
As implied by the above rules, OCP extensions may dynamically alter the negotiation mechanism itself, but such an alternation would have to be negotiated first, using the negotiation mechanism defined by this specification. For example, successfully negotiating a feature might change the default "Offer-Pending" value from false to true.
正如上述规则所暗示的那样，OCP扩展可以动态地改变协商机制本身，但是这种改变必须首先使用本规范定义的协商机制进行协商。例如，成功协商功能可能会将默认的“Offer Pending”值从false更改为true。
This appendix is not normative. The table below summarizes key OCP message properties. For each message, the table provides the following information:
本附录不规范。下表总结了关键OCP消息属性。对于每条消息，该表提供以下信息：
name: Message name as seen on the wire.
名称：电线上显示的消息名称。
title: Human-friendly message title.
标题：人性化信息标题。
P: Whether this specification documents message semantics as sent by an OPES processor.
P：该规范是否记录了OPES处理器发送的消息语义。
S: Whether this specification documents message semantics as sent by a callout server.
S：此规范是否记录调用服务器发送的消息语义。
tie: Related messages such as associated request, response message, or associated state message.
tie：相关消息，如关联的请求、响应消息或关联的状态消息。
+-------+----------------------------+-------+-------+--------------+
| name | title | P | S | tie |
+-------+----------------------------+-------+-------+--------------+
| CS | Connection Start | X | X | CE |
| CE | Connection End | X | X | CS |
| SGC | Service Group Created | X | X | SGD TS |
| SGD | Service Group Destroyed | X | X | SGC |
| TS | Transaction Start | X | | TE SGC |
| TE | Transaction End | X | X | TS |
| AMS | Application Message Start | X | X | AME |
| AME | Application Message End | X | X | AMS DSS |
| DUM | Data Use Mine | X | X | DUY DWP |
| DUY | Data Use Yours | | X | DUM DPI |
| DPI | Data Preservation Interest | | X | DUY |
| DWSS | Want Stop Sending Data | | X | DWSR DSS |
| DWSR | Want Stop Receiving Data | | X | DWSS |
| DSS | Stop Sending Data | X | | DWSS |
| DWP | Want Data Paused | X | X | DPM |
| DPM | Paused My Data | X | X | DWP DWM |
| DWM | Want More Data | X | X | DPM |
| NO | Negotiation Offer | X | X | NR SGC |
| NR | Negotiation Response | X | X | NO |
| PQ | Progress Query | X | X | PA |
| PA | Progress Answer | X | X | PQ PR |
| PR | Progress Report | X | X | PA |
| AQ | Ability Query | X | X | AA |
| AA | Ability Answer | X | X | AQ |
+-------+----------------------------+-------+-------+--------------+
+-------+----------------------------+-------+-------+--------------+
| name | title | P | S | tie |
+-------+----------------------------+-------+-------+--------------+
| CS | Connection Start | X | X | CE |
| CE | Connection End | X | X | CS |
| SGC | Service Group Created | X | X | SGD TS |
| SGD | Service Group Destroyed | X | X | SGC |
| TS | Transaction Start | X | | TE SGC |
| TE | Transaction End | X | X | TS |
| AMS | Application Message Start | X | X | AME |
| AME | Application Message End | X | X | AMS DSS |
| DUM | Data Use Mine | X | X | DUY DWP |
| DUY | Data Use Yours | | X | DUM DPI |
| DPI | Data Preservation Interest | | X | DUY |
| DWSS | Want Stop Sending Data | | X | DWSR DSS |
| DWSR | Want Stop Receiving Data | | X | DWSS |
| DSS | Stop Sending Data | X | | DWSS |
| DWP | Want Data Paused | X | X | DPM |
| DPM | Paused My Data | X | X | DWP DWM |
| DWM | Want More Data | X | X | DPM |
| NO | Negotiation Offer | X | X | NR SGC |
| NR | Negotiation Response | X | X | NO |
| PQ | Progress Query | X | X | PA |
| PA | Progress Answer | X | X | PQ PR |
| PR | Progress Report | X | X | PA |
| AQ | Ability Query | X | X | AA |
| AA | Ability Answer | X | X | AQ |
+-------+----------------------------+-------+-------+--------------+
This appendix is not normative. The table below summarizes OCP states. Some states are maintained across multiple transactions and application messages. Some correspond to a single request/response dialog; the asynchronous nature of most OCP message exchanges requires OCP agents to process other messages while waiting for a response to a request and, hence, while maintaining the state of the dialog.
本附录不规范。下表总结了OCP状态。一些状态是跨多个事务和应用程序消息维护的。一些对应于单个请求/响应对话框；大多数OCP消息交换的异步性质要求OCP代理在等待请求响应的同时处理其他消息，从而在维护对话框状态的同时处理其他消息。
For each state, the table provides the following information:
对于每个状态，该表提供了以下信息：
state: Short state label.
状态：短状态标签。
birth: Messages creating this state.
出生：创建此状态的消息。
death: Messages destroying this state.
死亡：破坏此状态的消息。
ID: Associated identifier, if any.
ID：关联的标识符（如果有）。
+-------------------------------+-------------+-------------+-------+
| state | birth | death | ID |
+-------------------------------+-------------+-------------+-------+
| connection | CS | CE | |
| service group | SGC | SGD | sg-id |
| transaction | TS | TE | xid |
| application message and | AMS | AME | |
| dataflow | | | |
| premature org-dataflow | DWSR | AME | |
| termination | | | |
| premature adp-dataflow | DWSS | DSS AME | |
| termination | | | |
| paused dataflow | DPM | DWM | |
| preservation commitment | DUM | DPI AME | |
| negotiation | NO | NR | |
| progress inquiry | PQ | PA | |
| ability inquiry | PQ | PA | |
+-------------------------------+-------------+-------------+-------+
+-------------------------------+-------------+-------------+-------+
| state | birth | death | ID |
+-------------------------------+-------------+-------------+-------+
| connection | CS | CE | |
| service group | SGC | SGD | sg-id |
| transaction | TS | TE | xid |
| application message and | AMS | AME | |
| dataflow | | | |
| premature org-dataflow | DWSR | AME | |
| termination | | | |
| premature adp-dataflow | DWSS | DSS AME | |
| termination | | | |
| paused dataflow | DPM | DWM | |
| preservation commitment | DUM | DPI AME | |
| negotiation | NO | NR | |
| progress inquiry | PQ | PA | |
| ability inquiry | PQ | PA | |
+-------------------------------+-------------+-------------+-------+
The author gratefully acknowledges the contributions of Abbie Barbir (Nortel Networks), Oskar Batuner (Independent Consultant), Larry Masinter (Adobe), Karel Mittig (France Telecom R&D), Markus Hofmann (Bell Labs), Hilarie Orman (The Purple Streak), Reinaldo Penno (Nortel Networks), and Martin Stecher (Webwasher), as well as an anonymous OPES working group participant.
作者感谢Abbie Barbir（北电网络）、Oskar Batuner（独立顾问）、Larry Masinter（Adobe）、Karel Mittig（法国电信研发）、Markus Hofmann（贝尔实验室）、Hilarie Orman（紫色条纹）、Reinaldo Penno（北电网络）和Martin Stecher（网络洗衣机）的贡献，以及OPES工作组的匿名参与者。
Special thanks to Marshall Rose for his xml2rfc tool.
特别感谢Marshall Rose提供的xml2rfc工具。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[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月。
[RFC3836] Beck, A., Hofmann, M., Orman, H., Penno, R., and A. Terzis, "Requirements for Open Pluggable Edge Services (OPES) Callout Protocols", RFC 3836, August 2004.
[RFC3836]Beck，A.，Hofmann，M.，Orman，H.，Penno，R.，和A.Terzis，“开放式可插拔边缘服务（OPES）调用协议的要求”，RFC 38362004年8月。
[RFC3837] 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.
[RFC3837]Barbir，A.，Batuner，O.，Srinivas，B.，Hofmann，M.，和H.Orman，“开放可插拔边缘服务（OPES）的安全威胁和风险”，RFC 3837，2004年8月。
[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月。
[RFC3838] 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.
[RFC3838]Barbir，A.，Batuner，O.，Beck，A.，Chan，T.，和H.Orman，“开放式可插拔边缘服务（OPES）的政策、授权和实施要求”，RFC 3838，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月。
[OPES-RULES] Beck, A. and A. Rousskov, "P: Message Processing Language", Work in Progress, October 2003.
[OPES-RULES]Beck，A.和A.Rousskov，“P:消息处理语言”，正在进行的工作，2003年10月。
[RFC3914] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services (OPES) Treatment of IAB Considerations", RFC 3914, October 2004.
[RFC3914]Barbir，A.和A.Rousskov，“开放可插拔边缘服务（OPES）对IAB考虑因素的处理”，RFC 3914，2004年10月。
[OPES-HTTP] Rousskov, A. and M. Stecher, "HTTP adaptation with OPES", Work in Progress, January 2004.
[OPES-HTTP]Rousskov，A.和M.Stecher，“HTTP与OPES的适应”，正在进行的工作，2004年1月。
[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月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080]Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[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月。
Author's Address
作者地址
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 (2005).
版权所有（C）互联网协会（2005年）。
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/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编辑功能的资金目前由互联网协会提供。