[要約] RFC 4037は、Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Coreに関する仕様です。OCPは、OPESアーキテクチャで使用されるプロトコルであり、アプリケーションの処理を外部のサービスに委譲するために使用されます。このRFCの目的は、OCPのコアプロトコルの仕様を提供し、OPESアプリケーションの開発と相互運用性を促進することです。
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).
Copyright（c）The Internet Society（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.
このドキュメントは、Open Pluggable Edge Services（OPES）Callout Protocol（OCP）のコアを指定します。OCP MARSHALS他の通信プロトコルからのアプリケーションメッセージ：OPES仲介者は、元のアプリケーションメッセージをCallout Serverに送信します。Callout Serverは、適応されたアプリケーションメッセージをプロセッサに送り返します。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
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
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.
Open Pluggable Edge Services（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プロセッサは、Calloutサーバーと通信することにより、サービス実行の責任を委任できます。[RFC3836]で説明されているように、OPESプロセッサは、Opes Callout Protocol（OCP）を使用してCalloutサーバー上のサービスと呼び出して通信します。このドキュメントは、そのプロトコル（「OCP Core」）のコアを指定します。
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のアプリケーション固有の側面について説明しています。たとえば、「OPESによるHTTP適応」[Opes-HTTP]は、部分的に、HTTPメッセージとHTTPメタ情報をOCPを介して伝える方法を説明しています。
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を使用してCalloutサーバーでのプロキシメッセージの適応を容易にします。したがって、OPESプロセッサがアプリケーションメッセージをプロキシングし、OCPを介してコールアウトサーバーをマーシャルし、適応結果をワイヤーに戻すと仮定するのは自然です。ただし、この仮定は、OCPがOPESプロセッサがプロキシしているアプリケーションメッセージに直接適用されることを意味しますが、そうではないかもしれません。
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 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.
この仕様では、OPESプロセッサとOPESプロセッサとCallout Serverの間で交換されるOPESプロセッサとアプリケーションメッセージによって提案されているアプリケーションメッセージ間の特定の関係を定義または必要としません。OPESプロセッサは通常、これらのアプリケーションメッセージ間のマッピングを提供しますが、プロセッサの特定のアクションはOCPスコープを超えています。言い換えれば、この仕様は、アプリケーションプロキシとしてのOPESプロセッサの役割や、Callout Servicesの繰り返しとして関係していません。OCPコアの範囲は、単一のOpesプロセッサと単一のCalloutサーバー間の通信です。
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を介して送信するために、どのアプリケーションメッセージまたはそれらに関する情報をプロキシ化したかを選択する場合があります。すべてのproxied接続に関するすべてのプロキシメッセージ（特定のアプリケーションプロトコルに対して接続が定義されている場合）、一部の接続、選択されたプロキシメッセージ、またはCalloutサーバーにOCPを介して送信されることはありません。OPESプロセッサおよびプロキシプロトコルに関連するCallout Server状態は、アプリケーションメッセージメタデータとして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]は、OPEの範囲で考慮され、OPESアーキテクチャの設計における動機とガイダンスとして使用されている一連のサービスとアプリケーションを説明しています。
o The OPES architecture and common terminology are described in "An Architecture for Open Pluggable Edge Services (OPES)" [RFC3835].
o OPESアーキテクチャと共通の用語は、「オープンプラグ可能なエッジサービス（OPES）のアーキテクチャ」[RFC3835]で説明されています。
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 「OPESのセキュリティの脅威とリスク」[RFC3837]は、特定のソリューションを推奨せずに、OPESリスク分析を提供します。
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 「IABの考慮事項のOPES処理」[RFC3914]は、OPES WGがチャーターされたときに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プロセッサとCallout Serverがあります。これは、Opes Callout Protocol（OCP）を介して相互に通信する2つのネットワーク要素です。このプロトコルの要件は、「Opes Callout Protocolsの要件」[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 「OPESエンティティとエンドポイント通信」[RFC3897]は、OPEの一般的なトレースとバイパスメカニズムを指定します。
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エンティティによって適応されるアプリケーションプロトコルとは独立しています。それらの一般的なメカニズムは、アプリケーション固有のプロファイルによって補完する必要があります。「OPESによるHTTP適応」[Opes-HTTP]は、HTTPのアプリケーションプロファイルです。HTTPメッセージの適応をサポートするために、アプリケーションに依存しないOPESメカニズムを使用および拡張する方法を指定します。
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-Rule]は、OPES適応（翻訳など）をどのようなアプリケーションメッセージ（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.
このドキュメントでは、キーワードは「必要はありません」、「必須」、「必要」、「shall」、「shill "、" low "nove"、 "becommented"、 ""、 "may"、 "optional"このドキュメントは、[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プロセッサは、アプリケーションプロトコルからのメッセージで動作し、それらのアプリケーションメッセージに関する情報をCallout Serverに中継する場合があります。OCPはアプリケーションプロトコルでもあります。したがって、OCPおよびその他のアプリケーションプロトコルには、「メッセージ」、「接続」、「トランザクション」などのプロトコル要素が存在します。この仕様では、OCP以外のアプリケーションプロトコルからの要素へのすべての参照は、明示的な「アプリケーション」予選で使用されます。「アプリケーション」予選のない参照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プロセッサとCallout Serverの間の基本的な単位。このメッセージは、構文ルール（セクション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プロセッサとコールアウトサーバーのネゴシエーションによって定義されたエンティティ。通常、ネゴシエートされた定義は、アプリケーションプロトコル（たとえば、[RFC2616]のHTTPメッセージの定義）の定義と一致します。
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プロセッサからCallout Serverに流れるアプリケーションメッセージを参照してください。
adapted: Referring to an application message flowing from an OPES callout server to the OPES processor.
適応：OPES Calloutサーバーから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.
適応：変更、生成、コピーを含む、Calloutサーバーによるあらゆる種類のアクセス。たとえば、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プロセッサとコールアウトサーバーは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 Callout Protocol（OCP）を使用して、Calloutサーバーと通信する場合があります。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プロセッサは、OCPを使用してコールアウトサーバーとアプリケーションメッセージを交換するために、コールアウトサーバーとのトランスポート接続を確立します。輸送層接続（通常はTCP/IP）が確立された後、OCPエージェントExchange Connection Start（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 Coreは、エージェントが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）メッセージを送信して、続くアプリケーションデータのCalloutサーバーを準備します。アプリケーションメッセージの範囲が確立されると、データを使用して鉱山（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プロセッサに応答します。適応されたアプリケーションメッセージデータは、データを使用して次に送信できます。アプリケーションメッセージは、アプリケーションメッセージエンド（AME）メッセージを使用して「完了」または「閉じ」と発表されます。トランザクションエンド（TE）メッセージを使用してトランザクションを閉じることもできます。これらのすべてのメッセージは、適応されたデータフローに対応しています。
+---------------+ +-------+
| 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プロセッサは、Callout Serverから送信された適応されたアプリケーションメッセージを受信します。受信したアプリケーションメッセージに固有のその他の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 Coreは、単一の元のアプリケーションメッセージと単一の適応アプリケーションメッセージの交換に特化したトランザクションインターフェイスを指定します。一部のアプリケーションプロトコルでは、単一のオリジナルアプリケーションメッセージまたは単一のOCPトランザクションの一部として交換される複数の元のメッセージに対して、複数の適応バージョンが必要になる場合があります。たとえば、1つの元の電子メールメッセージを複数の電子メールメッセージに変換する必要があります。各受信者に1つのカスタムメッセージを使用してください。
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 Serverは、適応されたアプリケーションメッセージ配信とトランザクションを終了します。任意の時代の早期および異常な終端がサポートされています。終了メッセージには、結果の説明が含まれています。
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クライアント」と、Callout Serverを「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プロセッサには、Calloutサーバーへの複数の同時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 接続は、コントロールメッセージやトランザクション関連のメッセージなど、一度にせいぜい1つのメッセージを伝えることができます。メッセージは常に単一の接続に関連付けられています（つまり、メッセージは複数の並行接続にまたがることはできません）。
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プロセッサからコールアウトサーバーへの一連のトランザクションメッセージは、元のフローと呼ばれます。CalloutサーバーからOPESプロセッサへの一連のトランザクションメッセージは、適応フローと呼ばれます。2つのフローは時間内に重複する場合があります。
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 Coreでは、トランザクションは単一のオリジナルと単一の適応アプリケーションメッセージに関連付けられています。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 Coreは、そのような状況に対処するためのメッセージを定義しません。拡張メカニズムがない場合、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」することから恩恵を受ける場合があります。後者は、適応データを作成する前にCalloutサーバーで長い時間がかかる可能性のある適応に特に役立ちます。
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通信は通常、インターネット上のTCP/IP接続で行われると想定されています（ただし、この仕様ではデフォルトのTCPポートはOCPに割り当てられていません）。これは、OCPが他の輸送プロトコルや他のネットワークの上に実装されることを排除するものではありません。ビープ音などの高レベルの輸送プロトコル[RFC3080]を使用できます。OCP Coreには、信頼性の高いメッセージ順序紹介輸送が必要です。これらのプロパティを備えたプロトコルを使用できます。問題のプロトコルのトランスポートデータユニットへの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オクテットです。パイプライン、プレビュー、データ保存、および早期終了の最適化、およびアプリケーションデータのAS-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 Serverの間のトランスポート、トランザクション管理、およびアプリケーションデータ交換を扱います。一部のメッセージは、OPESプロセッサでのみ放出できます。コールアウトサーバーのみによって。OPESプロセッサとCallout Serverの両方によるものもあります。一部のメッセージには応答が必要です（そのようなメッセージを「リクエスト」と呼ぶことができます）;他のメッセージ（「応答」）に応答してのみ使用できるものもあります。勧誘なしに送信される場合があります。また、応答を必要としない場合があります。
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メッセージは、メッセージ名とその後のオプションのパラメーターとペイロードで構成されています。正確なメッセージの構文は、次の拡張されたバックスノーフォーム（ABNF）[RFC2234]で定義されます。
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
payload = data
named-value = name ":" SP value
named-value = name "：" sp値
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
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ベースの文法に共通していますが、ここでは使用されません。Whitespaceの構文は、上記の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 引用された値エンコードのサイズ属性は、列（ '：'）セパレーターに続くオクテットの正確な数を指定します。サイズのオクテットの後に引用（ '"'）文字が続かない場合、エンコーディングは構文的に無効です。
o Empty quoted values are encoded as a 4-octet sequence "0:".
o 空の引用値は、4-OCTETシーケンス「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は、4オクテット1234または8オクテットの「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サブセットであり、構文は「データ」要素以外の非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」文字列は、通常OCPメッセージペイロードの前にCRLFシーケンスの存在を強調するために使用されることがあります。通常、可視線の端は、ワイヤの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 Syntaxは、パラメーターの拡張を可能にしながら、短い制御メッセージと必要なパラメーターのコンパクトな表現を提供します。以下は、短いコントロールメッセージの例です。各ラインの最後に必要なCRLFシーケンスは明示的には表示されません（セクション3.2を参照）。
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)
});
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）メッセージには、2つの匿名パラメーター（最後の1つは拡張機能）と2つの名前のパラメーター（最後のパラメーターは拡張機能です）があります。
DWM 1 3 Size-Request: 16384 X-Need-Info: "26:twenty six octet extension";
dwm 1 3サイズリケスト：16384 x-need-info： "26：26オクテット拡張";
Finally, any message may have a payload part. For example, the Data Use Mine (DUM) message below carries 8865 octets of raw data.
最後に、どのメッセージにもペイロードパーツがある場合があります。たとえば、以下のデータを使用するデータ（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プロセッサからCalloutサーバーへのフロー（元のアプリケーションメッセージの送信）と、CalloutサーバーからOPESプロセッサへのフロー（適応済みアプリケーションメッセージの送信）という2つのメッセージフローで構成されています。Callout Serverによって作成されたアプリケーションメッセージの数と、Callout Serverが元のアプリケーションメッセージを実際に変更するかどうかは、要求されたCalloutサービスとその他の要因によって異なります。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）メッセージが送信または受信、明示的または黙示的に終了します。どちらの側でもメッセージを送信できます。トランザクションに関連付けられたゼロ以上のOCPメッセージは、その間に交換できます。以下の図は、可能なメッセージシーケンスを示しています（プレフィックス「P」はOPESプロセッサの略であり、プレフィックス「S」はCallout Serverの略です）。いくつかのメッセージの詳細は省略されています。
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メッセージとその部分の多くの基準が含まれています。この文脈では、「無効な入力」とは、規範的ルールの少なくとも1つに違反するメッセージまたはメッセージ部分を意味します。無効な部分を持つメッセージは、定義上、無効です。メッセージの解析または解釈中に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は通常、堅牢性を超える正確さを評価すべきであるオプションであるが侵襲的なアプリケーションメッセージ操作を扱います。たとえば、特定のオプションのWebページコンテンツを挿入または削除しないことは、通常、その挿入または削除を実行しながら、ホストページを破損（使用不可）よりもはるかに邪魔になりません。ほとんどのOPES適応は本質的に高レベルであるため、特に「堅牢性の推測」が関与している場合、適応の正確性を自動的に評価することが不可能になります。
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.
ほとんどの交渉では、少なくとも1回の往復時間遅延が必要です。まれに、反対側の対応がすぐに必要でない場合、交渉遅延を排除することができ、交渉の対応について過度に楽観的な仮定の固有のリスクがあります。
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接続終了につながります。この設計により、交渉シナリオの数が減り、エージェントの1人が準拠していないときに行き詰まりになります。
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.
2つのコアネゴシエーションプリミティブがサポートされています：交渉の申し出と交渉対応。ネゴシエーションオファー（NO）メッセージを使用すると、エージェントがレスポンダーが好みの最大1つの機能を選択する必要がある一連の機能を指定できます。選択は、ネゴシエーション応答（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拡張機能は、ネゴシエートされている機能に応じて、イニシエーターの役割をエージェントの1人に割り当てることができます。たとえば、両方のエージェントが他のエージェントがオファーをするのを待つ状況を避けるために、輸送セキュリティ機能の交渉を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.
いずれかのエージェントがオファーを行う可能性があるため、2つの通信エージェントによって2つの「同時」オファーが同時に行われる場合があります。管理されていない同時オファーは、交渉の行き詰まりにつながる可能性があります。Opesプロセッサに優先事項を与えることにより、オファー処理ルール（セクション11.18）は、OCP接続ごとに1つのオファーのみが一度に尊重され、他の同時オファーが両方のエージェントによって無視されることを保証します。
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 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.
交渉段階は、両方のエージェントがさらに進む前に必要なすべての機能を交渉する機会を持つことを保証するメカニズムです。交渉段階にはOCP接続範囲があり、重複しません。各OCPエージェントについて、ネゴシエーションフェーズは、メッセージが既存のフェーズの一部ではない場合、最初の交渉オファー（NO）メッセージまたは最初の交渉回答（NR）メッセージから始まります。各OCPエージェントについて、ネゴシエーションフェーズは、最初のネゴシエーション応答（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）、Progressクエリ（PQ）、Progress Answer（PA）、Progress Report（PR）、およびConnection End（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接続の寿命の間に複数の交渉段階が発生する可能性があります。エージェントは、古いフェーズが終了した直後に新しいネゴシエーションフェーズを開始しようとする場合がありますが、他のエージェントは、新しい交渉オファー（NO）を受信する前に「ネゴシエーションフェーズメッセージ」以外のメッセージを送信する可能性があります。フェーズを開始するエージェントは、そのオファーが受信者に届いている間にこれらのメッセージを処理するために準備する必要があります。
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）メッセージを送信する必要があります。これらの2つのルールは、最初の交渉段階をブートストラップします。エージェントは、少なくとも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に受け取った場合にのみ、さらなる交渉を期待する必要があります。非公式には、エージェントは、ネゴシエーションオファーまたは応答を含む真の「オファーペンディング」パラメーターを送信することにより、フェーズを開いたままにすることができます。さらに、エージェントが交渉段階を継続する必要がある可能性がある場合、エージェントは真の「オファーペンディング」パラメーターを送信する必要があります。
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メッセージは、この場合の交渉段階を終了することに注意してください。
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 responding to the processor Negotiation Offer (NO) message. The processor chooses to accept the feature:
次の例は、CalloutサーバーがOPESプロセッサが交渉していない機能の交渉を強制する方法を示しています。サーバーは、プロセッサネゴシエーションオファー（NO）メッセージに応答するときに、「オファーペンディング」パラメーターをtrueに設定することに注意してください。プロセッサは、機能を受け入れることを選択します。
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.
サーバーが真の「オファーペンディング」値を送信した後に上記の交渉を停止しようとする場合、その唯一のオプションは空のネゴシエーションオファーを送信することです（上記の最初の例を参照）。サーバーが代わりに何もしない場合、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).
次の例は、2つの想像上の特徴を有効にすることを主張するコールアウトサーバーを使用したダイアログを示しています：強力な輸送暗号化と応答用の揮発性ストレージ。サーバーは、両方の機能が有効になるまで敏感なメッセージを交換しないように設計されています。当然のことながら、揮発性ストレージ機能は安全に交渉する必要があります。OPESプロセッサは、強力な暗号化メカニズムの1つをサポートしていますが、おそらくパフォーマンス上の理由で、強力な暗号化を提供することはできません（ボランティアのサポートを提供する）ことを好みます。サーバーは、強力な暗号化を提供する機会を得るために、真の「オファーペンディング」パラメーターを送信する必要があります（この場合、これは正常に交渉されます）。（唯一の）成功した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 ...
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;
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フィルタリングまたは広告挿入）。しかし、多くの場合、Calloutサービスは完全なデータを表示する必要があります。デフォルトでは、変更されていないデータは、最初にOPESプロセッサからCallout Serverに移動し、次に戻ります。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.
変更されていないデータの送信を避けるために、Callout Serviceは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 chunk. That OCP message does not have payload and, therefore, the return trip is eliminated.
OPESプロセッサがデータチャンクを保持することを約束する場合、データは鉱山（DUM）メッセージの保持されているパラメーターを介して決定とチャンクパラメーターを発表します。Callout Serverは、保存されたチャンクを参照してデータを使用してデータを使用してチャンクを「使用」することができます。その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.
元のデータと適応されたデータの間のマッピングはプロセッサに知られていないため、プロセッサは、チャンクが不要であることをコールアウトサーバーに明示的に指示しない限り、対応するトランザクションの終了まで保存されたチャンクを維持する必要があります。上記の要件で暗示されているように、プロセッサは、Callout Serverがデータを使用してYours（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プロセッサは、Callout ServerがKeep Dataが不要になったことを示した場合、オフセットを増やす可能性があります。
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サーバーではそうではありません。一方、データ保存のコミットメントからプロセッサを解放するのは責任があるのはCallout Serverです。この利益相反をプロトコルレベルで解決する簡単な方法はありません。一部のOPESプロセッサは、データ保存の目的で比較的小さなバッファーを割り当て、バッファがいっぱいになったときにデータの保存を停止する場合があります。この手法は、維持されたデータを迅速に再利用または破棄できるコールアウトサービスに利益をもたらします。別のプロセッサ戦略は、歴史的データの再利用統計に基づいてバッファーをサイズすることです。有益な協力の可能性を改善するために、Calloutサーバーは、OPESプロセッサに不要なデータをすぐに通知することを強くお勧めします。データを送信しないという決定を下したCalloutサーバー（特定のデータ範囲またはまったく）を使用する（DUY）メッセージを使用する必要があります。その他のメカニズム。
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設計により、コールアウトサーバーによる一方的な早期データフロー終了は、エラーを伴うOCPトランザクションの終了につながります。したがって、2つのエージェントは、エラーのない早期終了を可能にするために協力する必要があります。
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.
このセクションには、元のデータフローまたは適応されたデータフローの早期終了に関する2つのメカニズムを文書化します。組み合わせて、メカニズムにより、コールアウトサーバーは処理ループから完全に抜け出すことができます。
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.
Calloutサーバーが残りの元のデータフローに関心がないシナリオがあります。たとえば、単純なアクセスブロッキングまたは「このサイトが一時的なダウン」であるCallout Serviceは、適応（生成された）アプリケーションメッセージを送信する必要がありますが、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 Stup受信データ（DWSR）メッセージを介して、早期の元のデータフロー終了をサポートします。（特定のサイズを超えて）追加の元のデータを受信しようとしないCalloutサーバーは、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.
次の図は、典型的な一連のイベントを示しています。2つのデータフローを接続する下向きの線は、エージェントが反対エージェントの反応を待っている間に、より多くの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
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 Coreは、データの送信を停止する（DWSS）を停止し、データの送信（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を送信後に送信または一時停止）を使用する責任があります。
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プロセッサーが適応されたデータフローが終了するのを待っているときの元のデータフローの可能性のある一時停止を含む、典型的な一連のイベントを示しています。2つのデータフローを接続する下向きの線は、エージェントが反対エージェントの反応を待っている間に、より多くの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>
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 Serverがジョブを辞めようとする場合、OPESプロセッサが完全なアプリケーションメッセージを構築できるようにするために特別な注意を払う必要があります。論理レベルでは、このメカニズムは、OCPトランザクションの途中で、あるCallout Serverから別の（非変更）Callout Serverに切り替えることに相当します。
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プロセッサは、プロセッサが適応されたアプリケーションメッセージの残りの部分を再構築できないため、適応されたデータフローを時期尚早に終了させません。プロセッサは、残りの元のデータのどの接尾辞が適応された部品に従う必要があるかを知りません。オリジナルのオクテットと適応されたオクテットのマッピングは、コールアウトサービスにのみ知られています。
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.
DWSSメッセージに続いてDWSRメッセージが続くOPESプロセッサは、DSSメッセージを送信する前に206（部分）ステータスコードを使用してAMEメッセージを送信してはなりません。非公式には、このルールは、ループから速く出たいと思うコールアウトサーバーがDWSSメッセージをすぐに送信する必要があることを意味します。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の形式は、実装間の相互運用性を向上させることを目的としています。2つのプロトコル要素が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.
アトム、リスト、構造、およびメッセージコンストラクトは、利用可能な4つのベースタイプです。それらの構文およびセマンティクスルールは、セクション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 新しいアトミックタイプの宣言：<new-type-name>：Atomを拡張します。
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>：<OldType-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>：{<OldType-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>;
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>] ...;<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 ペイロードセマンティクスを使用してメッセージベースタイプを拡張する：<New-Type-Name>：{...}で<Old-Type-Name>を拡張し、ペイロード。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のSMTPプロファイルは、次の宣言を使用して、AM-IDを使用してアプリケーションメッセージ開始（AMS）メッセージを拡張する場合があります。
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）メッセージは、タイプ機能のパラメーターを使用します。機能（セクション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コアネームスペースタグは「コア」です。タイプを宣言する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] ... [namen]
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拡張機能は、1つのベース形式でタイプを定義し、導入するすべての新しいプロトコル要素のタイプを指定する必要があります。
uri: extends atom;
uri：原子を拡張します。
Uri (universal resource identifier) is an atom formatted according to URI rules in [RFC2396].
URI（Universal Resource Identifier）は、[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：Atomを拡張します。
Uni (unique numeric identifier) is an atom formatted as dec-number and with a value in the [0, 2147483647] range, inclusive.
uni（一意の数値識別子）は、decnumberとしてフォーマットされた原子であり、[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 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.
UNIパラメーターは、一意の（特定のスコープ内）識別子として使用されます。UNIセマンティクスは、スコープ仕様なしでは不完全です。一部のOCPメッセージは識別子を作成します（つまり、それらを範囲に入れます）。一部のOCPメッセージはそれらを破壊します（つまり、スコープからそれらを削除します）。OCPエージェントは、同じ範囲内で同じUNI値を複数回作成してはなりません。同じタイプの新しい識別子を作成し、古い識別子と同じ範囲内で作成する場合、OCPエージェントは新しい識別子に対してより高い数値値を使用する必要があります。最初のルールにより、UNI識別子は、相互参照ログやその他のアーティファクトに適しています。2番目のルールは、最初のルールの効率的なチェックを可能にします。
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.
たとえば、以前のトランザクションエンド（TS）メッセージが同じトランザクションに対して送信された場合でも、以前に使用されていたトランザクション識別子「XID」を同じOCPトランザクション内の新しいトランザクション開始（TS）メッセージに使用してはなりません。
An OCP agent MUST terminate the state associated with uni uniqueness scope if all unique values have been used up.
OCPエージェントは、すべての一意の値が使い果たされている場合、Uni Uniquenessスコープに関連する状態を終了する必要があります。
size: extends atom;
サイズ：原子を拡張します。
Size is an atom formatted as dec-number and with a value in the [0, 2147483647] range, inclusive.
サイズは、decnumberとしてフォーマットされ、[0、2147483647]範囲に値がある原子です。
Size value is the number of octets in the associated data chunk.
サイズ値は、関連するデータチャンクのオクテットの数です。
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コアは、OCPマーシャリングプロセスの一部として大きなサイズを必要とする2147483647オクテットを超えるアプリケーションメッセージを処理できません。この制限は、セクション15.1で示唆されているように、OCPエクステンションで対処できます。
offset: extends atom;
オフセット：アトムを拡張します。
Offset is an atom formatted as dec-number and with a value in the [0, 2147483647] range, inclusive.
オフセットは、decnumberとしてフォーマットされた原子であり、[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.
オフセットは、関連するデータフローの最初のオクテットと比較して、オクテットの数で発現するオクテット位置です。最初のデータOctetのオフセットの値はゼロです。
percent: extends atom;
パーセント：アトムを拡張します。
Percent is an atom formatted as dec-number and with a value in the [0, 100] range, inclusive.
パーセントは、decnumberとしてフォーマットされた原子であり、[0、100]範囲の値が包括的です。
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：Atomを拡張します。
Boolean type is an atom with two valid values: true and false. A boolean parameter expresses the truthfulness of the associated statement.
ブールタイプは、2つの有効な値を持つ原子です：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;
SG-ID：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はパーセントタイプを拡張して、アプリケーションデータが変更されるという送信者の信頼を表します。パーセンテージ値に関連付けられたブールステートメントは「データが変更されます」です。変更は、少なくとも1つのデータOctetの数値を変更する適応として定義されます。
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 reason. The reason member contains informative textual information not intended for automated processing. For example:
OCP処理の結果は、2人の文書化されたメンバーを持つ構造として表されます。必要なUNIステータスコードとオプションの理由です。メンバーには、自動処理を目的としていない有益なテキスト情報が含まれています。例えば：
{ 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. |
+--------+--------------+-------------------------------------------+
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.
結果セマンティクスを拡張することは、新しい「結果」構造メンバーを追加するか、追加の結果コードを交渉することにより可能になります（たとえば、交渉済みプロファイルの一部として）。未知の（当時のコンテキストで）結果コードの受信者は、コード400（障害）が受信されたかのように動作する必要があります。
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.
テキスト情報（結果構造の2番目の匿名パラメーター）は、多くの場合、「理由」または「理由フレーズ」と呼ばれます。手動のトラブルシューティングの取り組みを支援するために、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;
};
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機能の使用に対するサポートを宣言し、交渉するために使用されます。
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 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:
サービス構造には、1つの匿名のメンバー、タイプURIのOPESサービス識別子があります。サービスには、サービス依存パラメーターがある場合があります。OCPで使用するサービスを定義するOCP拡張機能は、追加の「サービス」構造メンバーとして、ある場合、サービス識別子とサービス依存パラメーターを定義する必要があります。たとえば、サービス値は次のようになります。
{"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).
オフセットなどのいくつかのパラメータータイプは、元のデータフローと適応されたデータフローの両方に適用されます。特に、異なる所属のパラメーターが1つのメッセージ宣言で混合されている場合、タイプのデータフロー所属を誤解するのは比較的簡単です。以下のステートメントは、データフローと存在するバージョンを使用して、新しいデータフロー固有のタイプを宣言します（<type>プレースホルダーで示されます）。
The following new types refer to original data only:
次の新しいタイプは、元のデータのみを参照してください。
org-<type>: extends <type>;
The following new types refer to adapted data only:
次の新しいタイプは、適応データのみを指します。
adp-<type>: extends <type>;
The following new types refer to the sender's dataflow only:
次の新しいタイプは、送信者のデータフローのみを指します。
my-<type>: extends <type>;
The following new types refer to the recipient's dataflow only:
次の新しいタイプは、受信者のデータフローのみを指します。
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 Coreは、上記のタイプネーミングスキームを使用して、次のタイプのデータフロー専門化を実装します：オフセット、サイズ、および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 with a given name can appear in the message; messages with multiple equally named parameters are semantically invalid.
このセクションでは、特定のOCPメッセージについて説明します。各メッセージには一意の名前が付けられ、通常は匿名および/または名前付きパラメーターのセットがあります。匿名パラメーターの順序は、以下のメッセージ定義で指定されています。この仕様では、指定されたパラメーターの特定の順序は暗示されていません。OCP拡張機能は、注文依存の指定パラメーターを導入してはなりません。特定の名前を持つ1つの名前付きパラメーターは、メッセージに表示される可能性があります。複数の等しく指定されたパラメーターを持つメッセージは、意味的に無効です。
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トランザクションまたはすでに終了した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）ではない場合、エージェントは400（障害）結果ステータスコードを持つ接続端（CE）メッセージとの接続を終了する必要があります。OCPエージェントは、接続開始（CS）メッセージを正確に1回送信する必要があります。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.
いつでも、Calloutサーバーは、ステータスコード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を輸送として使用すると、RAW TCP接続（ポート番号を備えたローカルおよびリモートピアIPアドレス）がOCP接続を識別します。他のトランスポートは、同じトランスポートを共有する論理接続を区別するために、OCP接続識別子を提供する場合があります。たとえば、単一のビープ音[RFC3080]チャネルは、単一のOCP接続として指定される場合があります。
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.
接続終了（CE）メッセージは、すべてのトランザクション、交渉、および終了時に開かれた、またはアクティブなサービスグループの終了を意味します。
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）メッセージは、適応サービスのリストが特定のサービスグループ識別子（「My-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のリスト）が必要です。したがって、実装が維持できる有限数の関連性があります。Calloutサーバーは、受け入れるOCP接続ごとに少なくとも1つの関連付けを維持できる必要があります。サービスグループ作成（SGC）メッセージの受信者が要求された関連付けを作成しない場合、障害を示す接続端（CE）メッセージとの接続を直ちに終了する必要があります。
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;
};
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トランザクションの開始を示します。このメッセージを受信すると、Callout Serverは、対応するトランザクションエンド（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」識別子は、作成されたAサービスグループが作成された（SGC）メッセージで作成されたサービスグループを指します。Callout Serverは、指定された順序で「My-SG-ID」に関連付けられたサービスのリストを適用する必要があります。
This message introduces the transaction identifier (xid).
このメッセージは、トランザクション識別子（XID）を紹介します。
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 example, unnecessary delays, rejection of new transactions, and even timeouts for agents that rely on this end-of-file condition to proceed.
OCPエージェントは、対応するトランザクションに関連するメッセージを送信しないことを決定する直後にトランザクションエンド（TE）メッセージを送信する必要があります。この要件に違反すると、たとえば、不必要な遅延、新しいトランザクションの拒否、さらにはこのファイル終了状態に依存して進むエージェントのタイムアウトさえも引き起こす可能性があります。
This message terminates the life of the transaction identifier (xid).
このメッセージは、トランザクション識別子（XID）の寿命を終了します。
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サーバーは、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メッセージがCalloutサーバーによって送信されると、オプションの「サービス」パラメーターは、サーバーが元のアプリケーションメッセージに適用できるOPESサービスを説明します。通常、「サービス」値は、OPESプロセッサで尋ねられたものと一致します。Calloutサーバーは、OPESプロセッサが要求したサービスのリストとその値が異なる場合、「サービス」パラメーターを送信する必要があります。同じサービスが多くの名前で知られている可能性があるため、不一致は必ずしもエラーを意味するわけではありません。
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;
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コアメッセージです。送信者は、データを使用して鉱山（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プロセッサが「保持されている」パラメーターを送信すると、プロセッサは指定されたデータのコピーを保持する必要があります（保存コミットメントが開始または継続されます）。保持されているオフセットパラメーターは、保存されたデータの最初のオクテットのオフセットを指定します。維持されているサイズパラメーターは、保存されたデータのサイズです。データの保存ルールにより、OPESプロセッサがオフセットを減らし、まだ完全に配信されていないデータ範囲をCallout Serverに指定できるようにする（禁止しない）ことに注意してください。OCPコアは、ダムペイロードと「保持」パラメーターとの関係を必要としません。
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.
「保持」パラメーター値がデータ保存ルールに違反しているが、受信者が特定のOCPトランザクションにデータを使用しているデータ（DUY）メッセージを送信していない場合、受信者は特定のトランザクションに保存されたデータを使用してはなりません（つまり、任意のデータを送信してください（YOURS（DUY）メッセージを使用します）。「保持されている」パラメーター値がデータ保存ルールに違反し、受信者が既にデータを送信している場合（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」パラメーターをCallOutサーバーに送信する必要があります。「信頼できる」の定義は、完全にCallout Server次第です。データ修正予測には、ダムペイロードが含まれます。つまり、添付のペイロードが変更されている場合、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サーバーは「AS-IS」パラメーターを送信する必要があります。コールアウトサーバーに送信されていないデータフラグメントを指定する「AS-IS」パラメーターは無効です。受信者は、無効な「AS-IS」パラメーターを無視する必要があります。同一のことは、すべての適応されたオクテットが対応する元のオクテットと同じ数値を持っていることを意味します。このパラメーターは、保存コミットメントなしに部分的なデータ保存の最適化を可能にすることを目的としています。保存されたデータは、Calloutサーバーとの接続を2回越えていますが、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;
};
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.
Callout Serverは、OPESプロセッサに、指定されたオフセットから開始された保存された元のデータの「サイズ」バイトを使用するように指示します。
The OPES processor MUST NOT terminate its data preservation commitment (section 7) in reaction to receiving a Data Use Yours (DUY) message.
OPESプロセッサは、データを受信することに反応してデータ保存コミットメント（セクション7）を終了してはなりません（DUY）メッセージを使用してはなりません。
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) 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.
データ保存率（DPI）メッセージは、最初のオクテットオフセットとサイズをパラメーターとして使用することにより、元のデータチャンクを記述します。チャンクは、Callout Serverが将来のデータを参照することに関心がある可能性のある元のデータの唯一の領域です。このデータチャンクは、「再利用可能なデータ」と呼ばれます。元のデータの残りの部分は、「使い捨てデータ」と呼ばれます。したがって、使い捨てデータは、指定されたオフセットの下および（オフセットサイズ）オフセット以上のオクテットで構成されています。
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).
Callout Serverは、以前のデータ保存関心（DPI）メッセージに示された使い捨てデータ領域と重複する再利用可能なデータ領域を示してはなりません。言い換えれば、再利用可能なデータは成長してはならず、使い捨てデータは縮小してはなりません。Callout Serverがこのルールに違反した場合、データ保存率（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プロセッサにデータの保存を強制することはできません。これに関連して、この用語は、OPESプロセッサの協力を考慮して、将来データを再利用することにCallout Serverの関心を表すために略です。
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のサイズ値は、サーバーがすべての元のデータを再利用したいことを示しています。ゼロのサイズ値は、サーバーがそれ以上データを送信しないことを示します（YORS（DUY）メッセージを使用します）。
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.
希望の停止データ（DWSR）メッセージは、OPESプロセッサに、Callout Serverが少なくともORGサイズのアプリケーションメッセージプレフィックスを受信した後、いつでも元のデータの受信を停止したいことを通知します。つまり、サーバーは、少なくとも組織サイズのオクテットを送信した後、プロセッサに元のデータフローを時期尚早に終了するように求めています（セクション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.
[データの受信]メッセージ（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プロセッサは、データの保存コミットメント（セクション7）を終了してはなりません。他のメッセージと同様に、OPESプロセッサは、将来の保存コミットメントを決定するために、希望する停止データ（DWSR）によって提供される情報を使用する場合があります。
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.
希望の停止データ（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;
};
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）メッセージを送信することにより、コールアウトサーバーに適応データフローを時期尚早に終了するように指示します。Callout Serverは、停止データ送信データ（DWSS）メッセージを送信することにより、STOP SENSINGデータ（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 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）メッセージを受信するCallOutサーバーは、206（部分）ステータスコードでアプリケーションメッセージエンド（AME）メッセージを送信することにより、すぐにデータフローを終了する必要があります。Callout Serverが既に適応データフローを終了している場合、Callout Serverはデータ送信データ（DSS）メッセージを停止することを無視する必要があります。未承諾のDSSメッセージを受信しているCalloutサーバーは、まだ廃止された適応データフローのメッセージを受け取る必要があります。そのメッセージを無効または勧誘として扱う必要があります（つまり、サーバーは単に未承諾の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.
OPESプロセッサの送信データ送信データ（DSS）メッセージは、Callout Serverがデータフローを終了した後、適合アプリケーションメッセージを正しく再構築できる必要があります。この要件は、プロセッサが停止データ（DSS）メッセージがある場合、停止データ（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.
Callout ServerがDSSメッセージを受信し、上記のルールに違反して、アプリケーションメッセージエンド（AME）応答を送信する前に、より元のデータを待っている場合、デッドロックが発生する可能性があります。）より多くの元のデータを送信するメッセージ。
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.
希望データが一時停止した（DWP）メッセージは、指定されたオフセットから始まるデータの受信に対する送信者の一時的な関心の欠如を示します。この無関心は、データを送信する送信者の意図について何も意味しません。
The "your-offset" parameter refers to dataflow originating at the OCP agent receiving the parameter.
「オフセット」パラメーターとは、パラメーターを受信する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.
希望データが一時停止（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（DWP）メッセージの送信者は、指定されたオフセットまたはまったく正確に一時停止されるデータに依存してはなりません。
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];
};
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サイズです。Calloutサーバーから送信されると、サイズは組織サイズです。
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".
「サイズリクエスト」パラメーターは、パラメーターを受信する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）メッセージを送信できることに注意してください。「サイズリクエスト」パラメーターは、このメッセージを有用なスタンドアロン最適化にします。
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）メッセージを送信できます。このセクションのルールは、2つのオファーが同時に提出された場合、1つのオファーのみが尊重されることを保証します。エージェントは、同じ接続で以前のオファーへの応答がまだ期待されている場合、ネゴシエーションオファー（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.
Callout Serverが自社のオファーが保留中の場合、ネゴシエーションオファー（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 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.
オプションの「SG」パラメーターを使用して、指定されたサービスグループへの交渉の範囲を絞り込みます。SGが存在する場合、ネゴシエートされた機能はネゴシエートされ、指定されたサービスグループIDを使用するトランザクションに対してのみ有効になります。接続スコープ機能は、すべてのサービスグループに対してネゴシエートされ、有効になっています。範囲の存在は、言語のプログラミングに共通する自動競合解決を意味するものではありません。競合は許可されていません。接続スコープ機能を交渉する場合、エージェントは既存の各サービスグループ内の競合を確認する必要があります。グループスコープのある機能を交渉する場合、エージェントは、すでに交渉されている接続スコープ機能との競合を確認する必要があります。たとえば、1つのサービスグループが既に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];
};
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.
拒否された申し出（否定的な応答）は、匿名の「機能」パラメーターを省略することにより示されます。
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）メッセージの送信者は、拒否および不明のパラメーターを介して追加の詳細を提供する場合があります。拒否パラメーターは、メッセージが受信されなかったときに存在する交渉状態を考慮して、交渉の申し出（NO）の受信者に知られているがサポートできない機能をリストするために使用できます。未知のパラメーターを使用して、NO受信者には不明な機能をリストすることができます。
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;
};
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];
};
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.
Progress Query（PQ）メッセージは、即時の進行状況回答（PA）応答を求めます。トランザクション識別子が受信者の観点から無効である場合でも、受信者はすぐにPQ要求に応答する必要があります。
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メッセージには、送信者の状態が含まれます。「ORG-DATA」サイズは、識別されたアプリケーションメッセージに対してこれまでにエージェントが送信または送信した元のデータサイズの合計です（エージェントは元のデータを送信または受信することができるため、あいまいさはありません）。受信したデータを参照する場合、進捗情報は、データが何らかの方法で処理されたことを意味するものではありません。
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.
Progress Inquiry Interfaceは、アイドル状態の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.
エージェントがProgressクエリ（PQ）リクエストで特定されたトランザクションに取り組んでいる場合、Agentは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メッセージは、回答時にトランザクション識別子がまだ有効である場合、Progressクエリ（PQ）メッセージで識別されるトランザクションとオリジナルのデータフローで送信者の進捗状況を中継します。回答のない情報は、クエリ受信者の視点からの無効、不明、またはクローズドトランザクションおよび/または元のデータフローを示しています。
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）メッセージには、送信者の状態が含まれます。メッセージセマンティクスと関連する要件は、PRメッセージが未承諾で送信されることを除いて、Progress Answer（PA）メッセージのセマンティクスと同一です。送信者は、いつでも進捗を報告できます。送信者は、トランザクションまたは元のアプリケーションメッセージとは無関係の進捗状況を報告するか、有効な（現在の）トランザクションまたは元のデータフローに関連する場合があります。
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）の考慮事項[RFC3238]のOPES処理は、[RFC3914]に記載されています。
This section examines security considerations for OCP. OPES threats are documented in [RFC3837] 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のセキュリティ上の考慮事項を検証します。OPESの脅威は、[RFC3837]に機密情報を含む可能性のある[RFC3837] OCPリレーアプリケーションメッセージに文書化されています。情報の漏れや変更を防ぐために適切な輸送暗号化を交渉することができます（セクション6を参照）が、OCPエージェントはデフォルトで暗号化されていない輸送をサポートする場合があります。これらの構成は、Opes Proxies自体が安全であっても、アプリケーションメッセージをサードパーティの録音と変更に公開します。
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プロセッサによって引き起こされるコールアウトサーバーのバッファオーバーフローは、他のOPESプロセッサとの接続を含む、他の（100％安全な）OCP接続からの情報へのプロセッサアクセスを許可する場合があります。
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は、Callout Serverが接続開始（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は、Callout ServerがServiceグループ作成（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コアは、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コアエクステンションは、機能URIパラメーターにhttp://www.iana.org/assignments/opes/ocp/プレフィックスを使用する必要があります。IANAは、このような「URI」パラメーターによって識別されたリソースを、対応する機能登録を備えていることが示唆されています。また、IANAは、http：//www.iana.org/assignments/opes/ocp/で、またはそのURLからリンクされたページで、登録されたすべてのOCP機能のインデックスを維持することも示唆されています。
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 list of unsupported SHOULDs (if any), in an appropriate format, explaining why the preferred behavior was not chosen.
非公式には、OCPコンプライアンスとは、「既知の「必須」違反がなく、すべての「「違反」が意図的であることを意味します。言い換えれば、「すべき」とは、「「違反する理由」を満たさなければならない」という意味です。コンプライアンスのクレームには、適切な形式でサポートされていない肩（もしあれば）のリストが添付され、好みの動作が選択されなかった理由を説明することが期待されています。
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拡張はネゴシエーションメカニズム自体を動的に変更する可能性がありますが、この仕様で定義された交渉メカニズムを使用して、そのような代替を最初に交渉する必要があります。たとえば、機能を正常に交渉すると、デフォルトの「オファーペンディング」値が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：この仕様が、Callout Serverによって送信されたメッセージのセマンティクスを文書化するかどうか。
tie: Related messages such as associated request, response message, or associated state message.
タイ：関連するリクエスト、応答メッセージ、または関連する状態メッセージなどの関連メッセージ。
+-------+----------------------------+-------+-------+--------------+
| 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 | |
+-------------------------------+-------------+-------------+-------+
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.
著者は、アビー・バルビル（ノルテル・ネットワーク）、オスカー・バトゥナー（独立コンサルタント）、ラリー・マスインター（アドビ）、カレル・ミッティグ（フランステレコムR＆D）、マルクスホフマン（ベルラボ）、ヒラリーオルマン（紫色のストリーク）の貢献に感謝して認めています。Reinaldo Penno（Nortel Networks）、Martin Stecher（Webwasher）、および匿名のOpesワーキンググループの参加者。
Special thanks to Marshall Rose for his xml2rfc tool.
XML2RFCツールを提供してくれたMarshall Roseに感謝します。
[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、「Open Pluggable Edge Services（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、「Open Pluggable Edge Services（OPES）Callout Protocolsの要件」、RFC 3836、2004年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、「Open Pluggable Edge Services（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、「Open Pluggable Edge Services（OPES）ユースケースと展開シナリオ」、RFC 3752、2004年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、「Open Pluggable Edge Services（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。、「Open Pluggable Edge Services（OPES）エンティティとエンドポイント通信」、RFC 3897、2004年9月。
[OPES-RULES] Beck, A. and A. Rousskov, "P: Message Processing Language", Work in Progress, October 2003.
[Opes-rules] Beck、A。and 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、「IAB考慮事項のオープンプラグ可能なエッジサービス（OPES）治療」、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、「OpesによるHTTP適応」、2004年1月、Work in Progress。
[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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080] Rose、M。、「ブロック拡張可能な交換プロトコルコア」、RFC 3080、2001年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、「Open Pluggable Edge ServicesのIAB建築および政策上の考慮事項」、RFC 3238、2002年1月。
Author's Address
著者の連絡先
Alex Rousskov The Measurement Factory
Alex Rousskov測定工場
EMail: rousskov@measurement-factory.com
URI: http://www.measurement-factory.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。