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
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.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document specifies the core of the Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: An OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). As defined in this document, the OCP Core consists of application-agnostic mechanisms essential for efficient support of typical adaptations.
このドキュメントでは、Open Pluggable Edge Services（OPES）Callout Protocol（OCP）のコアを指定します。 OCPは、他の通信プロトコルからのアプリケーションメッセージをマーシャリングします。OPES仲介者は、元のアプリケーションメッセージをコールアウトサーバーに送信します。 コールアウトサーバーは、適応したアプリケーションメッセージをプロセッサに送り返します。 OCPは、一般的な適応タスク（たとえば、ウイルスとスパムの管理、言語と形式の変換、メッセージの匿名化、または広告操作）を念頭に置いて設計されています。 このドキュメントで定義されているように、OCPコアは、典型的な適応の効率的なサポートに不可欠なアプリケーションに依存しないメカニズムで構成されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. OPES Document Map . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . 6
2. Overall Operation . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Initialization . . . . . . . . . . . . . . . . . . . . . 7
2.2. Original Dataflow . . . . . . . . . . . . . . . . . . . 8
2.3. Adapted Dataflow . . . . . . . . . . . . . . . . . . . . 8
2.4. Multiple Application Messages . . . . . . . . . . . . . 9
2.5. Termination . . . . . . . . . . . . . . . . . . . . . . 9
2.6. Message Exchange Patterns . . . . . . . . . . . . . . . 9
2.7. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 10
2.8. Environment . . . . . . . . . . . . . . . . . . . . . . 11
3. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
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.
オープンプラガブルエッジサービス（OPES）アーキテクチャ[RFC3835]は、データプロバイダー、データコンシューマー、およびゼロ個以上のOPESプロセッサー間の協調アプリケーションサービス（OPESサービス）を可能にします。 検討中のアプリケーションサービスは、データプロバイダーとデータコンシューマーの間で交換されるアプリケーションレベルのメッセージを分析し、場合によっては変換します。
The OPES processor can delegate the responsibility of service execution by communicating with callout servers. As described in [RFC3836], an OPES processor invokes and communicates with services on a callout server by using an OPES callout protocol (OCP). This document specifies the core of that protocol ("OCP Core").
OPESプロセッサは、コールアウトサーバーと通信することにより、サービス実行の責任を委任できます。 [RFC3836]で説明されているように、OPSプロセッサは、OPSコールアウトプロトコル（OCP）を使用して、コールアウトサーバー上のサービスを呼び出して通信します。 このドキュメントでは、そのプロトコルのコア（「OCPコア」）を指定しています。
The OCP Core specification documents general application-independent protocol mechanisms. A separate series of documents describes application-specific aspects of OCP. For example, "HTTP Adaptation with OPES" [OPES-HTTP] describes, in part, how HTTP messages and HTTP meta-information can be communicated over OCP.
OCP Core仕様には、一般的なアプリケーションに依存しないプロトコルメカニズムが記載されています。 別の一連のドキュメントでは、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は、OPSのユースケースとセキュリティの脅威を説明する文書を含む、OPS文書コレクション全体の簡単な概要を提供します。
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.
アプリケーションプロキシとして、OPSプロセッサは単一のアプリケーションプロトコルをプロキシするか、あるアプリケーションプロトコルから別のアプリケーションプロトコルに変換します。 同時に、OPESプロセッサはOCPクライアントであり、OCPを使用して、コールアウトサーバーでのプロキシメッセージの適応を促進します。 したがって、OPESプロセッサがプロキシされているアプリケーションメッセージを取得し、OCPを介してコールアウトサーバーにマーシャリングし、その後、適応結果をワイヤに戻すと仮定するのは自然です。 ただし、この前提は、OPESプロセッサがプロキシしているアプリケーションメッセージにOCPが直接適用されることを意味しますが、そうでない場合があります。
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応答を受け取り、そのボディを抽出し、そのボディをコンテンツエンコードメタデータとともに渡す場合があります。 さらに、適応を実行するために、OPSプロセッサはいくつかのコールアウトサービスを実行し、複数のコールアウトサーバーを反復処理する場合があります。 このような前処理、後処理、および反復により、プロキシされるアプリケーションメッセージとコールアウトサービスに送信されるアプリケーションメッセージ間の特定の関係に依存することができなくなります。 同様に、コールアウトサーバーでの特定の適応アクションは、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プロセッサとOCPを介してコールアウトサーバーとの間で交換されるアプリケーションメッセージとの間の特定の関係を定義または要求しません。 OPESプロセッサは通常、これらのアプリケーションメッセージ間のマッピングを提供しますが、プロセッサの特定のアクションはOCPスコープを超えています。 つまり、この仕様は、アプリケーションプロキシとして、またはコールアウトサービスの反復子としてのOPESプロセッサの役割には関係していません。 OCPコアの範囲は、単一のOPESプロセッサと単一のコールアウトサーバー間の通信です。
Furthermore, an OPES processor may choose which proxied application messages or information about them to send over OCP. All proxied messages on all proxied connections (if connections are defined for a given application protocol), everything on some connections, selected proxied messages, or nothing might be sent over OCP to callout servers. OPES processor and callout server state related to proxied protocols can be relayed over OCP as application message metadata.
さらに、OPESプロセッサは、OCPを介して送信するプロキシアプリケーションメッセージまたはそれらに関する情報を選択できます。 すべてのプロキシ接続のすべてのプロキシメッセージ（接続が特定のアプリケーションプロトコルに対して定義されている場合）、一部の接続のすべて、選択したプロキシメッセージ、または何もOCP経由でコールアウトサーバーに送信されない場合があります。 プロキシされたプロトコルに関連するOPESプロセッサとコールアウトサーバーの状態は、OCPを介してアプリケーションメッセージメタデータとして中継できます。
This document belongs to a large set of OPES specifications produced by the IETF OPES Working Group. Familiarity with the overall OPES approach and typical scenarios is often essential when one tries to comprehend isolated OPES documents. This section provides an index of OPES documents to assist the reader with finding "missing" information.
このドキュメントは、IETF OPESワーキンググループによって作成された多数のOPES仕様に属します。 孤立したOPES文書を理解しようとする場合、全体的なOPESアプローチと典型的なシナリオに精通していることがしばしば不可欠です。 このセクションでは、読者が「欠落している」情報を見つけるのを支援するために、OPESドキュメントのインデックスを提供します。
o "OPES Use Cases and Deployment Scenarios" [RFC3752] describes a set of services and applications that are considered in scope for OPES and that have been used as a motivation and guidance in designing the OPES architecture.
o「OPESユースケースと展開シナリオ」[RFC3752]は、OPESの範囲内で考慮され、OPESアーキテクチャの設計の動機とガイダンスとして使用されているサービスとアプリケーションのセットについて説明しています。
o The OPES architecture and common terminology are described in "An Architecture for Open Pluggable Edge Services (OPES)" [RFC3835].
o OPESアーキテクチャと一般的な用語は、「オープンプラグ可能エッジサービス（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]は、特定のソリューションを推奨することなく、OPSリスク分析を提供します。
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アーキテクチャの中核となるのは、OPSプロセッサとコールアウトサーバーであり、OPESコールアウトプロトコル（OCP）を介して互いに通信する2つのネットワーク要素です。 このプロトコルの要件は、「OPESコールアウトプロトコルの要件」[RFC3836]で説明されています。
o This document specifies an application agnostic protocol core to be used for the communication between an OPES processor and a callout server.
oこのドキュメントは、OPESプロセッサとコールアウトサーバー間の通信に使用されるアプリケーションに依存しないプロトコルコアを指定します。
o "OPES Entities and End Points Communications" [RFC3897] specifies generic tracing and bypass mechanisms for OPES.
o「OPESエンティティとエンドポイント通信」[RFC3897]は、OPESの一般的なトレースおよびバイパスメカニズムを指定します。
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コアおよび通信ドキュメントは、OPSエンティティによって適合されているアプリケーションプロトコルから独立しています。 それらの一般的なメカニズムは、アプリケーション固有のプロファイルによって補完される必要があります。 「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：Message Processing Language」[OPES-RULES]は、どのアプリケーションメッセージ（bob@example.comからの電子メールなど）に適用する必要があるOPESの適応（翻訳など）を指定するための言語を定義します。 P言語は、アプリケーションプロキシ（OPESプロセッサ）の構成を目的としています。
In this document, the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase constitute normal prose usage, with no normative implications.
このドキュメントでは、 このドキュメントは、[RFC2119]で説明されているように解釈されます。 規範的な意味で使用すると、これらのキーワードはすべて大文字になります。 これらの単語の小文字の出現は、通常の散文の使用を構成し、規範的な意味はありません。
The OPES processor works with messages from application protocols and may relay information about those application messages to a callout server. OCP is also an application protocol. Thus, protocol elements such as "message", "connection", or "transaction" exist in OCP and other application protocols. In this specification, all references to elements from application protocols other than OCP are used with an explicit "application" qualifier. References without the "application" qualifier refer to OCP elements.
OPESプロセッサは、アプリケーションプロトコルからのメッセージを処理し、それらのアプリケーションメッセージに関する情報をコールアウトサーバーに中継します。 OCPはアプリケーションプロトコルでもあります。 したがって、OCPおよび他のアプリケーションプロトコルには、「メッセージ」、「接続」、「トランザクション」などのプロトコル要素が存在します。 この仕様では、OCP以外のアプリケーションプロトコルからの要素へのすべての参照は、明示的な「アプリケーション」修飾子とともに使用されます。 「application」修飾子のない参照は、OCP要素を参照します。
OCP message: A basic unit of communication between an OPES processor and a callout server. The message is a sequence of octets formatted according to syntax rules (section 3.1). Message semantics is defined in section 11.
OCPメッセージ：OPESプロセッサとコールアウトサーバー間の通信の基本単位。 メッセージは、構文規則に従ってフォーマットされたオクテットのシーケンスです（セクション3.1）。 メッセージのセマンティクスはセクション11で定義されています。
application message: An entity defined by OPES processor and callout server negotiation. Usually, the negotiated definition would match the definition from an application protocol (e.g., [RFC2616] definition of an HTTP message).
アプリケーションメッセージ：OPESプロセッサとコールアウトサーバーネゴシエーションによって定義されたエンティティ。 通常、ネゴシエートされた定義は、アプリケーションプロトコルの定義（たとえば、[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.
data：アプリケーションメッセージデータと同じです。
original: Referring to an application message flowing from the OPES processor to a callout server.
オリジナル：OPESプロセッサからコールアウトサーバーに流れるアプリケーションメッセージを参照します。
adapted: Referring to an application message flowing from an OPES callout server to the OPES processor.
適応：OPESコールアウトサーバーからOPESプロセッサに流れるアプリケーションメッセージを参照します。
adaptation: Any kind of access by a callout server, including modification, generation, and copying. For example, translating or logging an SMTP message is adaptation of that application message.
適応：変更、生成、コピーなど、コールアウトサーバーによるあらゆる種類のアクセス。 たとえば、SMTPメッセージの翻訳またはログ記録は、そのアプリケーションメッセージの適応です。
agent: The actor for a given communication protocol. The OPES processor and callout server are OCP agents. An agent can be referred to as a sender or receiver, depending on its actions in a particular context.
エージェント：特定の通信プロトコルのアクター。 OPESプロセッサとコールアウトサーバーはOCPエージェントです。 エージェントは、特定のコンテキストでのアクションに応じて、送信者または受信者と呼ばれます。
immediate: Performing the specified action before reacting to new incoming messages or sending any new messages unrelated to the specified action.
即時：新しい着信メッセージに反応する前に指定されたアクションを実行するか、指定されたアクションに関係のない新しいメッセージを送信します。
OCP extension: A specification extending or adjusting this document for adaptation of an application protocol (a.k.a., application profile; e.g., [OPES-HTTP]), new OCP functionality (e.g., transport encryption and authentication), and/or new OCP Core version.
OCP拡張：アプリケーションプロトコル（別名、アプリケーションプロファイル、たとえば[OPES-HTTP]）、新しいOCP機能（たとえば、トランスポート暗号化および認証）、および/または新しいOCPコアバージョンの適応のためにこのドキュメントを拡張または調整する仕様 。
The OPES processor may use the OPES callout protocol (OCP) to communicate with callout servers. Adaptation using callout services is sometimes called "bump in the wire" architecture.
OPESプロセッサは、OPESコールアウトプロトコル（OCP）を使用して、コールアウトサーバーと通信できます。 コールアウトサービスを使用する適応は、「バンプインザワイヤ」アーキテクチャと呼ばれることもあります。
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エージェントは接続開始（CS）メッセージを交換します。 次に、プロセッサとコールアウトサーバー間でOCP機能をネゴシエートできます（セクション6を参照）。 たとえば、OCPエージェントは、トランスポート暗号化とアプリケーションメッセージ定義をネゴシエートする場合があります。
When enough settings are negotiated, OCP agents may start exchanging application messages.
十分な設定がネゴシエートされると、OCPエージェントがアプリケーションメッセージの交換を開始する場合があります。
OCP Core provides negotiation and other mechanisms for agents to encrypt OCP connections and authenticate each other. OCP Core does not require OCP connection encryption or agent authentication. Application profiles and other OCP extensions may document and/or require these and other security mechanisms. OCP is expected to be used, in part, in closed environments where trust and privacy are established by means external to OCP. Implementations are expected to demand necessary security features via the OCP Core negotiation mechanism, depending on agent configuration and environment.
OCPコアは、エージェントがOCP接続を暗号化し、相互に認証するためのネゴシエーションおよびその他のメカニズムを提供します。 OCPコアは、OCP接続の暗号化またはエージェント認証を必要としません。 アプリケーションプロファイルおよびその他のOCP拡張機能は、これらおよびその他のセキュリティメカニズムを文書化および/または要求する場合があります。 OCPは、部分的には、OCPの外部の手段によって信頼とプライバシーが確立される閉鎖環境で使用されることが期待されています。 実装では、エージェントの構成と環境に応じて、OCPコアネゴシエーションメカニズムを介して必要なセキュリティ機能が要求されることが予想されます。
When the OPES processor wants to adapt an application message, it sends a Transaction Start (TS) message to initiate an OCP transaction dedicated to that application message. The processor then sends an Application Message Start (AMS) message to prepare the callout server for application data that will follow. Once the application message scope is established, application data can be sent to the callout server by using Data Use Mine (DUM) and related OCP message(s). All of these messages correspond to the original dataflow.
OPESプロセッサがアプリケーションメッセージを調整する場合、トランザクション開始（TS）メッセージを送信して、そのアプリケーションメッセージ専用のOCPトランザクションを開始します。 次に、プロセッサはアプリケーションメッセージスタート（AMS）メッセージを送信して、後に続くアプリケーションデータ用にコールアウトサーバーを準備します。 アプリケーションメッセージスコープが確立されると、Data Use Mine（DUM）および関連するOCPメッセージを使用して、アプリケーションデータをコールアウトサーバーに送信できます。 これらのメッセージはすべて、元のデータフローに対応しています。
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.
コールアウトサーバーは、OPESプロセッサによって送信されたデータとメタデータを受信します（元のデータフロー）。 コールアウトサーバーは、メタデータを分析し、受信時にデータを調整します。サーバーは通常、メタデータのバージョンを構築し、Application Message Start（AMS）メッセージでOPESプロセッサに応答します。 次に、Data Use Mine（DUM）OCPメッセージを使用して、適応されたアプリケーションメッセージデータを送信できます。 その後、アプリケーションメッセージは、アプリケーションメッセージエンド（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プロセッサは、コールアウトサーバーから送信された適応アプリケーションメッセージを受信します。 受信したアプリケーションメッセージに固有の他のOPESプロセッサアクションは、この仕様の範囲外です。
OCP Core specifies a transactions interface dedicated to exchanging a single original application message and a single adapted application message. Some application protocols may require multiple adapted versions for a single original application message or even multiple original messages to be exchanged as a part of a single OCP transaction. For example, a single original e-mail message may need to be transformed into several e-mail messages, with one custom message for each recipient.
OCPコアは、単一のオリジナルアプリケーションメッセージと単一の適合アプリケーションメッセージの交換専用のトランザクションインターフェイスを指定します。 一部のアプリケーションプロトコルでは、単一のOCPトランザクションの一部として、単一のオリジナルアプリケーションメッセージまたは複数のオリジナルメッセージを交換するために、複数の適応バージョンが必要になる場合があります。 たとえば、元の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メッセージを送信することにより、アプリケーションメッセージの配信、トランザクション、または接続を終了できます。 通常、コールアウトサーバーは、適応されたアプリケーションメッセージ配信とトランザクションを終了します。 任意の時点での早期終了および異常終了がサポートされています。 終了メッセージには結果の説明が含まれます。
In addition to messages carrying application data, OCP agents may also exchange messages related to their configuration, state, transport connections, application connections, etc. A callout server may remove itself from the application message processing loop. A single OPES processor can communicate with many callout servers and vice versa. Though many OCP exchange patterns do not follow a classic client-server model, it is possible to think of an OPES processor as an "OCP client" and of a callout server as an "OCP server". The OPES architecture document [RFC3835] describes configuration possibilities.
OCPエージェントは、アプリケーションデータを運ぶメッセージに加えて、構成、状態、トランスポート接続、アプリケーション接続などに関連するメッセージを交換する場合があります。コールアウトサーバーは、アプリケーションメッセージ処理ループから自身を削除する場合があります。 単一のOPESプロセッサは多くのコールアウトサーバーと通信でき、その逆も可能です。 多くのOCP交換パターンは従来のクライアント/サーバーモデルに従っていませんが、OPESプロセッサーを「OCPクライアント」と見なし、コールアウトサーバーを「OCPサーバー」と見なすことができます。 OPESアーキテクチャドキュメント[RFC3835]は、構成の可能性について説明しています。
The following informal rules illustrate relationships between connections, transactions, OCP messages, and application messages:
次の非公式ルールは、接続、トランザクション、OCPメッセージ、およびアプリケーションメッセージ間の関係を示しています。
o An OCP agent may communicate with multiple OCP agents. This is outside the scope of this specification.
o OCPエージェントは、複数のOCPエージェントと通信できます。 これは、この仕様の範囲外です。
o An OPES processor may have multiple concurrent OCP connections to a callout server. Communication over multiple OCP connections is outside the scope of this specification.
o OPESプロセッサには、コールアウトサーバーへの複数の同時OCP接続がある場合があります。 複数のOCP接続を介した通信は、この仕様の範囲外です。
o A connection may carry multiple concurrent transactions. A transaction is always associated with a single connection (i.e., a transaction cannot span multiple concurrent connections).
o接続は、複数の同時トランザクションを伝送できます。 トランザクションは常に単一の接続に関連付けられます（つまり、トランザクションは複数の同時接続にまたがることはできません）。
o A connection may carry at most one message at a time, including control messages and transaction-related messages. A message is always associated with a single connection (i.e., a message cannot span multiple concurrent connections).
o接続は、制御メッセージやトランザクション関連のメッセージを含め、一度に最大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プロセッサからコールアウトサーバーへのトランザクションメッセージのシーケンスは、元のフローと呼ばれます。 コールアウトサーバーから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コアでは、トランザクションは単一のオリジナルおよび単一の適応アプリケーションメッセージに関連付けられます。 OCPコア拡張機能は、トランザクションスコープをより多くのアプリケーションメッセージに拡張できます。
o An application message (adapted or original) is transferred by using a sequence of OCP messages.
oアプリケーションメッセージ（適応またはオリジナル）は、一連のOCPメッセージを使用して転送されます。
OCP violations, resource limits, external dependencies, and other factors may lead to states in which an OCP agent is not receiving required messages from the other OCP agent. OCP Core defines no messages to address such situations. In the absence of any extension mechanism, OCP agents must implement timeouts for OCP operations. An OCP agent MUST forcefully terminate any OCP connection, negotiation, transaction, etc. that is not making progress. This rule covers both dead- and livelock situations.
OCP違反、リソース制限、外部依存関係、およびその他の要因により、OCPエージェントが他のOCPエージェントから必要なメッセージを受信していない状態になる可能性があります。 OCPコアでは、このような状況に対処するためのメッセージは定義されていません。 拡張メカニズムが存在しない場合、OCPエージェントはOCP操作のタイムアウトを実装する必要があります。 OCPエージェントは、進行していないOCP接続、ネゴシエーション、トランザクションなどを強制的に終了しなければなりません。 このルールは、デッドロックとライブロックの両方の状況を対象としています。
In their implementation, OCP agents MAY rely on transport-level or other external timeouts if such external timeouts are guaranteed to happen for a given OCP operation. Depending on the OCP operation, an agent may benefit from "pinging" the other side with a Progress Query (PQ) message before terminating an OCP transaction or connection. The latter is especially useful for adaptations that may take a long time at the callout server before producing any adapted data.
それらの実装では、特定のOCP操作でそのような外部タイムアウトが発生することが保証されている場合、OCPエージェントはトランスポートレベルまたはその他の外部タイムアウトに依存する場合があります。 OCP操作に応じて、エージェントは、OCPトランザクションまたは接続を終了する前に、Progress Query（PQ）メッセージで相手側に「ping」することで利益を得る場合があります。 後者は、適応データを生成する前にコールアウトサーバーで長時間かかる適応に特に役立ちます。
OCP communication is assumed usually to take place over TCP/IP connections on the Internet (though no default TCP port is assigned to OCP in this specification). This does not preclude OCP from being implemented on top of other transport protocols, or on other networks. High-level transport protocols such as BEEP [RFC3080] may be used. OCP Core requires a reliable and message-order-preserving transport. Any protocol with these properties can be used; the mapping of OCP message structures onto the transport data units of the protocol in question is outside the scope of this specification.
OCP通信は通常、インターネット上のTCP / IP接続を介して行われると想定されます（ただし、この仕様ではデフォルトのTCPポートはOCPに割り当てられていません）。 これは、OCPが他のトランスポートプロトコルの上または他のネットワークに実装されることを妨げるものではありません。 BEEP [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 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プロセッサと単一のコールアウトサーバー間のアプリケーションデータ交換を処理します。 一部のメッセージは、OPESプロセッサによってのみ発行できます。 一部はコールアウトサーバーのみ。 また、一部はOPESプロセッサとコールアウトサーバーの両方によるものです。 一部のメッセージには応答が必要です（このようなメッセージを「要求」と呼ぶことができます）。 一部は、他のメッセージへの応答でのみ使用できます（「応答」）。 一部は勧誘なしで送信される場合があります。 また、応答を必要としないものもあります。
An OCP message consists of a message name followed by optional parameters and a payload. The exact message syntax is defined by the following Augmented Backus-Naur Form (ABNF) [RFC2234]:
OCPメッセージは、メッセージ名の後にオプションのパラメーターとペイロードが続きます。 正確なメッセージ構文は、次の拡張バッカスナウア形式（ABNF）[RFC2234]で定義されています。
message = name [SP anonym-parameters] [CRLF named-parameters CRLF] [CRLF payload CRLF] ";" CRLF
メッセージ=名前[SP匿名パラメーター] [CRLF名前付きパラメーターCRLF] [CRLFペイロードCRLF] ";" CRLF
anonym-parameters = value *(SP value) ; space-separated named-parameters = named-value *(CRLF named-value) ; CRLF-separated list-items = value *("," value) ; comma-separated
匿名パラメータ=値*（SP値）; スペースで区切られた名前付きパラメーター=名前付き値*（CRLF名前付き値）; CRLFで区切られたリスト項目=値*（ "、"値）; カンマ区切り
payload = data
ペイロード=データ
named-value = name ":" SP value
名前付き値=名前 "：" SP値
value = structure / list / atom structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}" list = "(" [ list-items ] ")" atom = bare-value / quoted-value
値=構造/リスト/アトム構造= "{" [匿名パラメータ] [CRLF名前付きパラメータCRLF] "}"リスト= "（" [リスト項目] "）"原子=ベアバリュー/クォートバリュー
name = ALPHA *safe-OCTET bare-value = 1*safe-OCTET quoted-value = DQUOTE data DQUOTE data = size ":" *OCTET ; exactly size octets
name = ALPHA * safe-OCTET bare-value = 1 * safe-OCTET quoted-value = DQUOTE data DQUOTE data = size "：" * OCTET; 正確なサイズのオクテット
safe-OCTET = ALPHA / DIGIT / "-" / "_" size = dec-number ; 0-2147483647 dec-number = 1*DIGIT ; no leading zeros or signs
safe-OCTET = ALPHA / DIGIT / "-" / "_" size = dec-number; 0-2147483647 dec-number = 1 * DIGIT; 先行ゼロまたは記号なし
Several normative rules accompany the above ABNF:
上記のABNFにはいくつかの規範的な規則が付随しています。
o There is no "implied linear space" (LWS) rule. LWS rules are common to MIME-based grammars but are not used here. The whitespace syntax is restricted to what is explicitly allowed by the above ABNF.
o「暗黙の線形空間」（LWS）ルールはありません。 LWSルールはMIMEベースの文法に共通ですが、ここでは使用しません。 空白の構文は、上記のABNFで明示的に許可されているものに制限されています。
o All protocol elements are case sensitive unless it is specified otherwise. In particular, message names and parameter names are case sensitive.
oすべてのプロトコル要素は、特に指定しない限り大文字と小文字を区別します。 特に、メッセージ名とパラメーター名では大文字と小文字が区別されます。
o Sizes are interpreted as decimal values and cannot have leading zeros.
oサイズは10進数値として解釈され、先頭にゼロを付けることはできません。
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 quoted-valueエンコードのサイズ属性は、列（ '：'）セパレーターに続くオクテットの正確な数を指定します。 サイズオクテットの後に引用符（ '"'）文字が続かない場合、エンコードは構文的に無効です。
o Empty quoted values are encoded as a 4-octet sequence "0:".
o空の引用符で囲まれた値は、4オクテットシーケンス「0：」としてエンコードされます。
o Any bare value can be encoded as a quoted value. A quoted value is interpreted after the encoding is removed. For example, number 1234 can be encoded as four octets 1234 or as eight octets "4:1234", yielding exactly the same meaning.
o裸の値は、引用符付きの値としてエンコードできます。 引用符で囲まれた値は、エンコーディングが削除された後に解釈されます。 たとえば、番号1234は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サブセットであり、構文は「data」要素以外の非ASCII文字を禁止していることに注意してください。
Messages violating formatting rules are, by definition, invalid. See section 5 for rules governing processing of invalid messages.
フォーマット規則に違反するメッセージは、定義により無効です。 無効なメッセージの処理を管理する規則については、セクション5を参照してください。
OCP message samples in this specification and its extensions may not be typeset to depict minor syntactical details of OCP message format. Specifically, SP and CRLF characters are not shown explicitly. No rendering of an OCP message can be used to infer message format. The message format definition above is the only normative source for all implementations.
この仕様とその拡張のOCPメッセージサンプルは、OCPメッセージフォーマットのマイナーな構文の詳細を表すためにタイプセットされていない場合があります。 具体的には、SPおよびCRLF文字は明示的に表示されません。 OCPメッセージのレンダリングを使用して、メッセージ形式を推測することはできません。 上記のメッセージ形式の定義は、すべての実装の唯一の規範的なソースです。
On occasion, an OCP message line exceeds text width allowed by this specification format. A backslash ("\"), a "soft line break" character, is used to emphasize a protocol-violating presentation-only linebreak. Bare backslashes are prohibited by OCP syntax. Similarly, an "\r\n" string is sometimes used to emphasize the presence of a CRLF sequence, usually before OCP message payload. Normally, the visible end of line corresponds to the CRLF sequence on the wire.
場合によっては、OCPメッセージ行がこの仕様形式で許可されているテキスト幅を超えています。 バックスラッシュ（「\」）、「ソフト改行」文字は、プロトコル違反のプレゼンテーションのみの改行を強調するために使用されます。 裸のバックスラッシュはOCP構文で禁止されています。 同様に、CRCシーケンスの存在を強調するために、通常はOCPメッセージペイロードの前に「\ r \ n」文字列が使用されることがあります。 通常、目に見える行末は、ワイヤ上のCRLFシーケンスに対応しています。
The next section (section 3.3) contains specific OCP message examples, some of which illustrate the above rendering techniques.
次のセクション（セクション3.3）には、特定のOCPメッセージの例が含まれており、その一部は上記のレンダリング手法を示しています。
OCP syntax provides for compact representation of short control messages and required parameters while allowing for parameter extensions. Below are examples of short control messages. The required CRLF sequence at the end of each line is not shown explicitly (see section 3.2).
OCP構文は、パラメーターの拡張を可能にしながら、短い制御メッセージと必要なパラメーターのコンパクトな表現を提供します。 以下は、ショートコントロールメッセージの例です。 各行の終わりに必要なCRLFシーケンスは明示的に示されていません（セクション3.2を参照）。
PQ;
TS 1 2;
DWM 22;
DWP 22 16;
x-doit "5:xyzzy";
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つの匿名パラメーター（最後が拡張子）と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.
オリジナルから適応されたゼロまたはそれ以上のアプリケーションメッセージがあります。 典型的なトランザクションは、2つのメッセージフローで構成されます。OPESプロセッサからコールアウトサーバーへのフロー（元のアプリケーションメッセージの送信）と、コールアウトサーバーからOPESプロセッサへのフロー（適応アプリケーションメッセージの送信）です。 コールアウトサーバーによって生成されるアプリケーションメッセージの数、およびコールアウトサーバーが元のアプリケーションメッセージを実際に変更するかどうかは、要求されたコールアウトサービスおよびその他の要因によって異なります。 OPESプロセッサまたはコールアウトサーバーは、対応するメッセージを相手側に送信することにより、トランザクションを終了できます。
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トランザクションは、OPSプロセッサによって送信されたTransaction Start（TS）メッセージで開始されます。 トランザクションは、明示的または暗黙的に送信または受信された最初のトランザクション終了（TE）メッセージで終了します。 TEメッセージはどちらの側からも送信できます。 トランザクションに関連付けられた0個以上のOCPメッセージは、その間で交換できます。 次の図は、可能なメッセージシーケンスを示しています（プレフィックス "P"はOPESプロセッサを表し、プレフィックス "S"はコールアウトサーバーを表します）。 一部のメッセージの詳細は省略されています。
P: TS 10;
P: AMS 10 1;
... processor sending application data to the callout server
S: AMS 10 2;
... callout server sending application data to the processor
... processor sending application data to the callout server
P: AME 10 1 result;
S: AME 10 2 result;
P: TE 10 result;
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エージェントが受信した無効なメッセージのスコープを決定できない場合、エージェントはメッセージを接続スコープを持つものとして扱わなければなりません（MUST）。
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拡張など、相互に受け入れられる一連の機能について合意できます。 たとえば、トランスポート暗号化、データ形式、および新しいメッセージのサポートについてネゴシエートできます。 交渉は、行動の変化を意図することを意味します。 エージェントが相手の動作を変更せずに相手の機能を照会できるようにする関連メカニズムについては、Ability Query（AQ）およびAbility Answer（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つにイニシエーターの役割を割り当てることができます。 たとえば、トランスポートセキュリティ機能のネゴシエーションは、両方のエージェントが相手のオファーを待つ状況を回避するために、OPSプロセッサによって開始される必要があります。
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エージェントは次の「ネゴシエーションフェーズメッセージ」以外のメッセージを送信してはなりません。 ）、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プロセッサは、Connection Start（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の受信が真の「Offer-Pending」パラメータ値を含んでいた場合にのみ、さらなるネゴシエーションを期待する必要があります。 非公式には、エージェントはネゴシエーションのオファーまたはレスポンスとともに真の「Offer-Pending」パラメーターを送信することにより、フェーズを開いたままにできます。 さらに、エージェントが交渉フェーズを継続する必要がある可能性がある場合、エージェントは真の「Offer-Pending」パラメータを送信する必要があります。
Below is an example of the simplest negotiation possible. The OPES processor is offering nothing and is predictably receiving a rejection. Note that the NR message terminates the Negotiation Phase in this case because neither of the messages contains a true "Offer-Pending" value:
以下は、可能な限り単純なネゴシエーションの例です。 OPESプロセッサは何も提供しておらず、予想どおりに拒否されています。 どちらのメッセージにも真の「Offer-Pending」値が含まれていないため、この場合、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:
次の例は、コールアウトサーバーが、OPESプロセッサがネゴシエートしていない機能のネゴシエーションを強制する方法を示しています。 サーバーは、プロセッサネゴシエーションオファー（NO）メッセージに応答するときに、「Offer-Pending」パラメーターを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.
サーバーが真の "Offer-Pending"値を送信した後に上記のネゴシエーションを停止しようとする場合、唯一のオプションは空のネゴシエーションオファーを送信することです（上記の最初の例を参照）。 サーバーが代わりに何もしない場合、OPSプロセッサはサーバーを待機し、最終的に接続をタイムアウトします。
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つをサポートしますが、おそらくパフォーマンス上の理由から、強力な暗号化を（ボランティアによるサポートのために）提供しないことを好みます。 サーバーは、強力な暗号化（この場合は正常にネゴシエートされます）を提供する機会を得るために、真の "Offer-Pending"パラメーターを送信する必要があります。 （のみ）正常なNR応答の後にいずれかのエージェントによって送信されたメッセージは、「strongB」暗号化スキームで暗号化されます。 OPESプロセッサは揮発性ストレージ機能を理解せず、最後のネゴシエーションは（強力に暗号化されたトランスポート接続を介して）失敗します。
P: NO ({"29:ocp://example/encryption/weak"})
;
S: NR
Offer-Pending: true
;
S: NO ({"32:ocp://example/encryption/strongA"},\
{"32:ocp://example/encryption/strongB"})
Offer-Pending: true
;
P: NR {"32:ocp://example/encryption/strongB"}
;
... all traffic below is encrypted using strongB ...
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フィルタリングや広告挿入など）。 しかし、多くの場合、コールアウトサービスは完全なデータを確認する必要があります。 デフォルトでは、変更されていないデータは、最初にOPESプロセッサからコールアウトサーバーに移動してから戻ってきます。 OCPの「データ保存」の最適化は、両方のOCPエージェントが協力する場合の往復旅行を排除するのに役立ちます。 このような連携はオプションです。OCPエージェントはデータ保存の最適化をサポートする場合があります。
To avoid sending back unmodified data, a callout service has to know that the OPES processor has a copy of the data. As data sizes can be very large and the callout service may not know in advance whether it will be able to use the processor copy, it is not possible to require the processor to keep a copy of the entire original data. Instead, it is expected that a processor may keep some portion of the data, depending on processor settings and state.
変更されていないデータを送り返すことを避けるために、コールアウトサービスはOPESプロセッサがデータのコピーを持っていることを知る必要があります。 データサイズは非常に大きくなる可能性があり、コールアウトサービスはプロセッサコピーを使用できるかどうかを事前に知らない可能性があるため、プロセッサに元のデータ全体のコピーを保持するよう要求することはできません。 代わりに、プロセッサの設定と状態に応じて、プロセッサがデータの一部を保持することが予想されます。
When an OPES processor commits to keeping a data chunk, it announces its decision and the chunk parameters via a Kept parameter of a Data Use Mine (DUM) message. The callout server MAY "use" the chunk by sending a Data Use Yours (DUY) message referring to the preserved chunk. That OCP message does not have payload and, therefore, the return trip is eliminated.
OPESプロセッサがデータチャンクの保持をコミットすると、データ使用鉱山（DUM）メッセージのKeptパラメーターを介して、その決定とチャンクパラメーターをアナウンスします。 コールアウトサーバーは、保存されたチャンクを参照するData Use Yours（DUY）メッセージを送信することにより、チャンクを「使用」する場合があります。 その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.
元のデータと適合データの間のマッピングはプロセッサに知られていないため、コールアウトサーバーがプロセッサにチャンクが不要であることを明示的に通知しない限り、プロセッサは対応するトランザクションの終了までアナウンスされたままのチャンクを保持する必要があります。 上記の要件で暗示されているように、プロセッサは、コールアウトサーバーがData Use 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.
簡単にするために、保存されたデータは常に元のデータの連続したチャンクであり、Data Use Mine（DUM）メッセージの「Kept」パラメーターを使用した（オフセット、サイズ）ペアで記述されます。 OPESプロセッサは、保持するデータのサイズを増やすことを自発的に行う場合があります。 保持されたデータが不要になったことをコールアウトサーバーが示した場合、OPSプロセッサはオフセットを増やすことができます。
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プロセッサはこの最適化をサポートするためにストレージを割り当てる必要がありますが、コールアウトサーバーはそうではありません。一方、プロセッサをデータ保存のコミットメントから解放するのは、コールアウトサーバーです。プロトコルレベルでこの利益相反を解決する簡単な方法はありません。一部のOPESプロセッサは、データ保存のために比較的小さなバッファを割り当て、バッファがいっぱいになるとデータの保存を停止する場合があります。この手法は、保持されたデータをすばやく再利用または破棄できるコールアウトサービスに役立ちます。別のプロセッサ戦略は、履歴データの再利用統計に基づいてバッファのサイズを調整することです。有益な協力の機会を改善するために、コールアウトサーバーは、不要なデータを直ちにOPESプロセッサに通知することを強くお勧めします。 Data Use Yours（DUY）メッセージ（特定のデータ範囲またはまったく）を送信しない決定をしたコールアウトサーバーは、対応するData Preservation Interest（DPI）メッセージでその決定をOPESプロセッサに直ちに通知する必要があります。他のメカニズム。
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.
コールアウトサーバーが残りの元のデータフローに関心がないシナリオがあります。 たとえば、単純なアクセスブロッキングまたは「このサイトは一時的にダウン」コールアウトサービスは、適応（生成）アプリケーションメッセージを送信する必要がありますが、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コアは、Want Stop Receiving Data（DWSR）メッセージを介した早期の元のデータフロー終了をサポートします。 （特定のサイズを超えて）追加の元のデータを受信しようとしないコールアウトサーバーは、DWSRメッセージを送信します。 DWSRメッセージを受信したOPESプロセッサは、206（部分）ステータスコードを含むApplication Message End（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（部分）結果ステータスコードを含むApplication Message End（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コアは、データ送信停止（DWSS）メッセージとデータ送信停止（DSS）メッセージの組み合わせにより、早期に適応したデータフロー終了をサポートします。 データの送信を停止しようとするコールアウトサービスは、停止するOPESプロセッサの許可を求めるDWSSメッセージを送信します。 許可を待っている間、サーバーは通常のルーチンを続行します。
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.
Want Stop Sending Dataメッセージを受信したOPESプロセッサは、Stop Sending Data（DSS）メッセージで応答します。 プロセッサは、一時停止して、コールアウトサーバーが適応データフローを終了するのを待つか、コピーを作成しながら元のデータの送信を継続します。 サーバーが適応データフローを終了すると、プロセッサは適応データの代わりに元のデータ（DSSの送信後に送信または一時停止）を使用します。
The callout server receiving a DSS message terminates the adapted dataflow (see the Stop Sending Data (DSS) message definition for the exact requirements and corner cases).
DSSメッセージを受信したコールアウトサーバーは、適応されたデータフローを終了します（正確な要件と特殊なケースについては、データ送信の停止（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プロセッサはコールアウトサーバーに依存して適応データ（変更されているかどうかに関係なく）を提供し、適応アプリケーションメッセージを構築するため、早期適応データフローの保存は簡単ではありません。 コールアウトサーバーがジョブを終了しようとする場合、OPESプロセッサが完全なアプリケーションメッセージを作成できるように特別な注意を払う必要があります。 論理レベルでは、このメカニズムは、OCPトランザクションの途中で1つのコールアウトサーバーから別の（変更しない）コールアウトサーバーに切り替えることに相当します。
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.
元のデータフローが停止する可能性があることを除き、このセクションで説明するメカニズムは元のデータフローには影響しません。 コールアウトサーバーから206（部分）結果ステータスコードを含むApplication Message End（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.
DWSSRメッセージとそれに続くDWSRメッセージを受信したOPESプロセッサは、DSSメッセージを送信する前に206（部分）ステータスコードを含むAMEメッセージを送信してはなりません。 非公式には、このルールは、ループからすばやく抜け出したいコールアウトサーバーがDWSSメッセージを送信した直後にDWSRメッセージを送信することを意味します。 サーバーは、OPESプロセッサが元のデータフローを終了することを要求する前に、適応されたデータフローを終了するOPESプロセッサの許可を待つ必要はありません。
A protocol element type is a named set of syntax and semantics rules. This section defines a simple, formal declaration mnemonic for protocol element types, labeled PETDM. PETDM simplicity is meant to ease type declarations in this specification. PETDM formality is meant to improve interoperability among implementations. Two protocol elements are supported by PETDM: message parameter values and messages.
プロトコル要素タイプは、構文およびセマンティクスルールの名前付きセットです。 このセクションでは、PETDMというラベルが付けられた、プロトコル要素タイプの単純で正式な宣言ニーモニックを定義します。 PETDMの単純さは、この仕様での型宣言を容易にすることを目的としています。 PETDM形式は、実装間の相互運用性を向上させることを目的としています。 PETDMでは、メッセージパラメータ値とメッセージという2つのプロトコル要素がサポートされています。
All OCP Core parameter and message types are declared by using PETDM. OCP extensions SHOULD use PETDM when declaring new types.
すべてのOCP Coreパラメーターとメッセージタイプは、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>：extends 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 old-type-name項目を含む新しいリストの宣言：<new-type-name>：<old-type-name>のリストを拡張します。 特に明記されていない限り、空のリストは有効であり、パラメータ値がないという意味を持ちます。
o Declaring a new structure with members:
<new-type-name>: extends structure with {
<old-type-nameA> <old-type-nameB> [<old-type-nameC>] ...;
<member-name1>: <old-type-name1>;
<member-name2>: <old-type-name2>;
[<member-name3>: <old-type-name3>];
...
};
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>];
...
};
The new type name becomes the message name. Just as when a structure is extended, the new message may have anonymous parameters and named parameters. Neither group has to exist. Note that it is always possible for extensions to add more parameters to old messages without affecting type semantics because unrecognized parameters are ignored by compliant agents.
新しいタイプ名がメッセージ名になります。 構造が拡張されるときと同様に、新しいメッセージには匿名パラメーターと名前付きパラメーターが含まれる場合があります。 どちらのグループも存在する必要はありません。 認識されていないパラメーターは準拠エージェントによって無視されるため、拡張機能が型のセマンティクスに影響を与えずに古いメッセージにパラメーターを追加することは常に可能であることに注意してください。
o Extending a type with more semantics details:
oより多くのセマンティクスの詳細で型を拡張する：
<new-type-name>: extends <old-type-name>;
<new-type-name>：<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 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>：extends <namespace> :: <old-type-name>; 上記のテンプレートは、OCP Coreタイプの名前を変更せずにセマンティクスを変更しようとするOCP Core拡張機能で使用できます。 メッセージ名はメッセージタイプ名と同じであるため、この手法はOCPメッセージを拡張するために不可欠です。 たとえば、OCPのSMTPプロファイルは、次の宣言を使用して、そのプロファイルで定義されているパラメーターであるAm-IdでApplication Message Start（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）メッセージは、Featuresタイプのパラメーターを使用します。 機能（セクション10.12）は、機能（セクション10.11）項目のリストです。 フィーチャーは構造ベースのタイプです。 OCP拡張機能（HTTPアプリケーションプロファイルなど）は、機能タイプを拡張し、ネゴシエーションオファーでその拡張タイプの値を使用できます。 拡張機能を認識している受信者は、機能アイテムに追加されたメンバーを認識し、それに応じて交渉します。 他の受信者はそれらを無視します。
The OCP Core namespace tag is "Core". OCP extensions that declare types MUST define their namespace tags (so that other extensions and documentation can use them in their PETDM declarations).
OCP Core名前空間タグは「Core」です。 タイプを宣言するOCP拡張機能は、名前空間タグを定義する必要があります（他の拡張機能やドキュメントがPETDM宣言で使用できるようにするため）。
Anonymous parameters are positional: The parameter's position (i.e., the number of anonymous parameters to the left) is its "name". Thus, when a structure or message has multiple optional anonymous parameters, parameters to the right can be used only if all parameters to the left are present. The following notation
匿名パラメーターは定位置です：パラメーターの位置（つまり、左側の匿名パラメーターの数）はその「名前」です。 したがって、構造体またはメッセージに複数のオプションの匿名パラメーターがある場合、右側のパラメーターは、左側のすべてのパラメーターが存在する場合にのみ使用できます。 次の表記
[name1] [name2] [name3] ... [nameN]
[name1] [name2] [name3] ... [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（ユニバーサルリソース識別子）は、[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（Not Found）応答になる場合があります。
uni: extends atom;
uni：アトムを拡張します。
Uni (unique numeric identifier) is an atom formatted as dec-number and with a value in the [0, 2147483647] range, inclusive.
Uni（一意の数値識別子）は、dec-numberとしてフォーマットされ、[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.
たとえば、同じトランザクションに対して以前のトランザクション終了（TE）メッセージが送信された場合でも、以前に使用されたトランザクション識別子「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一意性スコープに関連付けられた状態を終了しなければなりません。
size: extends atom;
サイズ：アトムを拡張します。
Size is an atom formatted as dec-number and with a value in the [0, 2147483647] range, inclusive.
サイズは、dec-numberとしてフォーマットされ、[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コアは、サイズが2147483647オクテットを超えるアプリケーションメッセージ、OCPマーシャリングプロセスの一部としてより大きなサイズを必要とするアプリケーションメッセージ、または8ビット以外の粒度のサイズを使用するアプリケーションメッセージを処理できません。 セクション15.1で示唆されているように、この制限はOCP拡張機能によって対処できます。
offset: extends atom;
オフセット：アトムを拡張します;
Offset is an atom formatted as dec-number and with a value in the [0, 2147483647] range, inclusive.
オフセットは、dec-numberとしてフォーマットされ、[0、2147483647]の範囲の値を持つアトムです。
Offset is an octet position expressed in the number of octets relative to the first octet of the associated dataflow. The offset of the first data octet has a value of zero.
オフセットは、関連するデータフローの最初のオクテットに対するオクテット数で表されるオクテット位置です。 最初のデータオクテットのオフセットの値はゼロです。
percent: extends atom;
パーセント：アトムを拡張します。
Percent is an atom formatted as dec-number and with a value in the [0, 100] range, inclusive.
パーセントは、dec-numberとしてフォーマットされ、[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;
ブール値：atomを拡張します;
Boolean type is an atom with two valid values: true and false. A boolean parameter expresses the truthfulness of the associated statement.
ブール型は、trueとfalseの2つの有効な値を持つアトムです。 ブールパラメータは、関連付けられたステートメントの真実性を表します。
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つのデータオクテットの数値を変更する適応として定義されます。
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処理結果は、必須のUniステータスコードとオプションの理由の2つの文書化されたメンバーを持つ構造として表されます。 理由メンバーには、自動処理を目的としない有益なテキスト情報が含まれています。 例えば：
{ 200 OK } { 200 "6:got it" } { 200 "27:27 octets in UTF-8 encoding" }
{200 OK} {200 "6：got it"} {200 "UTF-8エンコーディングの27:27オクテット"}
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機能IDを中継し、オプションの機能固有のパラメーター（機能属性とも呼ばれる）の「場所」を予約するために構造を拡張します。 機能値は、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"}
{"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>;
org- <type>：<type>を拡張します;
The following new types refer to adapted data only:
次の新しいタイプは、適合データのみを参照します。
adp-<type>: extends <type>;
adp- <type>：<type>を拡張します;
The following new types refer to the sender's dataflow only:
次の新しいタイプは、送信者のデータフローのみを参照します。
my-<type>: extends <type>;
my- <type>：<type>を拡張します;
The following new types refer to the recipient's dataflow only:
次の新しいタイプは、受信者のデータフローのみを参照します。
your-<type>: extends <type>;
your- <type>：<type>を拡張します;
OCP Core uses the above type-naming scheme to implement dataflow specialization for the following types: offset, size, and sg-id. OCP extensions SHOULD use the same scheme.
OCPコアは、上記のタイプ命名スキームを使用して、オフセット、サイズ、およびsg-idタイプのデータフローの特殊化を実装します。 OCP拡張は、同じスキームを使用する必要があります。
This section describes specific OCP messages. Each message is given a unique name and usually has a set of anonymous and/or named parameters. The order of anonymous parameters is specified in the message definitions below. No particular order for named parameters is implied by this specification. OCP extensions MUST NOT introduce order-dependent named parameters. No more than one named-parameter with a given name can appear in the message; messages with multiple equally named parameters are semantically invalid.
このセクションでは、特定のOCPメッセージについて説明します。 各メッセージには一意の名前が付けられ、通常は匿名および/または名前付きパラメーターのセットがあります。 匿名パラメーターの順序は、以下のメッセージ定義で指定されています。 この仕様では、名前付きパラメーターの特定の順序は暗示されていません。 OCP拡張は、順序に依存する名前付きパラメーターを導入してはなりません。 指定された名前を持つ名前付きパラメーターは、メッセージに複数表示できません。 複数の同じ名前のパラメータを持つメッセージは意味的に無効です。
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を参照）。 たとえば、Data Use Mine（DUM）メッセージのxidパラメーターが不明または既に終了したOCPトランザクションを参照している場合、受信者はトランザクションを終了する必要があります。
CS: extends message;
CS：メッセージを拡張します。
A Connection Start (CS) message indicates the start of an OCP connection. An OCP agent MUST send this message before it sends any other message on the connection. If the first message an OCP agent receives is not Connection Start (CS), the agent MUST terminate the connection with a Connection End (CE) message having 400 (failure) result status code. An OCP agent MUST send Connection Start (CS) message exactly once. An OCP agent MUST ignore repeated Connection Start (CS) messages.
接続開始（CS）メッセージは、OCP接続の開始を示します。 OCPエージェントは、接続上で他のメッセージを送信する前にこのメッセージを送信する必要があります。 OCPエージェントが受け取る最初のメッセージが接続開始（CS）でない場合、エージェントは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.
いつでも、コールアウトサーバーは、接続終了（CE）メッセージをステータスコード400（失敗）で送信することにより、OCP接続でのさらなる処理を拒否する場合があります。 最初にCSメッセージを送信するという上記の要件が引き続き適用されることに注意してください。
With TCP/IP as transport, raw TCP connections (local and remote peer IP addresses with port numbers) identify an OCP connection. Other transports may provide OCP connection identifiers to distinguish logical connections that share the same transport. For example, a single BEEP [RFC3080] channel may be designated as a single OCP connection.
トランスポートとしてTCP / IPを使用する場合、生のTCP接続（ポート番号を持つローカルおよびリモートピアIPアドレス）はOCP接続を識別します。 他のトランスポートは、同じトランスポートを共有する論理接続を区別するためにOCP接続識別子を提供する場合があります。 たとえば、単一のBEEP [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」）に関連付けられたことを受信者に通知します。 このメッセージに続いて、送信者は識別子を使用してグループを参照できます。 受信者は、一致するService Group Destroyed（SGD）メッセージが受信されるか、対応するOCP接続が閉じられるまで、関連付けを維持する必要があります。
Service groups have a connection scope. Transaction management messages do not affect existing service groups.
サービスグループには接続スコープがあります。 トランザクション管理メッセージは、既存のサービスグループには影響しません。
Maintaining service group associations requires resources (e.g., storage to keep the group identifier and a list of service IDs). Thus, there is a finite number of associations an implementation can maintain. Callout servers MUST be able to maintain at least one association for each OCP connection they accept. If a recipient of a Service Group Created (SGC) message does not create the requested association, it MUST immediately terminate the connection with a Connection End (CE) message indicating a failure.
サービスグループの関連付けを維持するには、リソースが必要です（たとえば、グループ識別子とサービスIDのリストを保持するストレージ）。 したがって、実装が維持できる関連付けの数には限りがあります。 コールアウトサーバーは、受け入れるOCP接続ごとに少なくとも1つの関連付けを維持できる必要があります。 Service Group Created（SGC）メッセージの受信者が要求されたアソシエーションを作成しない場合、失敗を示すConnection End（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.
Service Group Destroyed（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プロセッサによって送信されるTransaction Start（TS）メッセージは、OCPトランザクションの開始を示します。 このメッセージを受信すると、コールアウトサーバーは、対応するTransaction End（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」識別子は、Service Group Created（SGC）メッセージで作成されたサービスグループを指します。 コールアウトサーバーは、「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.
Application Message Start（AMS）メッセージは、元のアプリケーションメッセージ処理またはデータフローの適応を示します。 受信者は、失敗を示すApplication Message End（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メッセージを送り返し、元のアプリケーションメッセージの適合バージョンの作成を通知します。 この発表は遅れる場合があります。 たとえば、コールアウトサーバーは、OPSプロセッサからの追加情報を待つ場合があります。
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メッセージがコールアウトサーバーによって送信される場合、オプションの「Services」パラメーターは、サーバーが元のアプリケーションメッセージに適用することができるOPESサービスを記述します。 通常、「サービス」の値は、OPSプロセッサからの要求に一致します。 コールアウトサーバーは、その値がOPESプロセッサによって要求されたサービスのリストと異なる場合、「Services」パラメータを送信する必要があります。 同じサービスが多くの名前で知られているため、不一致は必ずしもエラーを意味するわけではありません。
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.
Data Use Mine（DUM）メッセージは、アプリケーションデータを運びます。 これは、文書化されたペイロードを持つ唯一のOCP Coreメッセージです。 送信者は、Data Use Mine（DUM）およびData Use Yours（DUY）メッセージによって提供されるデータにギャップを作ってはいけません（つまり、次のデータメッセージのmy-offsetは、my-offsetとペイロードサイズ 前のデータメッセージ）。 ギャップのあるメッセージは無効です。 送信者はペイロードを送信する必要があり、空のペイロード（つまり、サイズがゼロのペイロード）を使用することができます（MAY）。 ペイロードのない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プロセッサは、「Kept」パラメータを送信して、元のデータに対する現在のデータ保存のコミットメント（セクション7）を示すことができます（MAY）。 OPESプロセッサが「Kept」パラメータを送信する場合、プロセッサは指定されたデータのコピーを保持する必要があります（保存コミットメントが開始または続行します）。 Kept offsetパラメーターは、保存されるデータの最初のオクテットのオフセットを指定します。 Kept sizeパラメーターは、保存されるデータのサイズです。 データ保存ルールにより、OPESプロセッサはオフセットを減らし、コールアウトサーバーにまだ完全に配信されていないデータ範囲を指定できます（禁止しない）。 OCPコアでは、DUMペイロードと「Kept」パラメーターの関係は必要ありません。
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.
「Kept」パラメータ値がデータ保存ルールに違反しているが、受信者が特定のOCPトランザクションのデータ使用（DUY）メッセージをまだ送信していない場合、受信者は特定のトランザクションに保存データを使用してはなりません（つまり、 Data Use Yours（DUY）メッセージを送信）。 「Kept」パラメーター値がデータ保存ルールに違反しており、受信者が既にデータ使用（DUY）メッセージを送信している場合、DUMメッセージは無効であり、セクション5のルールが適用されます。 これらの要件は、「保持」最適化がOPESプロセッサで使用されるときにデータの整合性を維持するのに役立ちます。
A callout server MUST send a "Modp" parameter if the server can provide a reliable value and has not already sent the same parameter value for the corresponding application message. The definition of "reliable" is entirely up to the callout server. The data modification prediction includes DUM payload. That is, if the attached payload has been modified, the modp value cannot be 0%.
サーバーが信頼できる値を提供でき、対応するアプリケーションメッセージに対して同じパラメーター値をまだ送信していない場合、コールアウトサーバーは「Modp」パラメーターを送信する必要があります。 「信頼できる」の定義は、コールアウトサーバー次第です。 データ変更予測には、DUMペイロードが含まれます。 つまり、添付されたペイロードが変更されている場合、modp値は0％にできません。
A callout server SHOULD send an "As-is" parameter if the attached data is identical to a fragment at the specified offset in the original dataflow. An "As-is" parameter specifying a data fragment that has not been sent to the callout server is invalid. The recipient MUST ignore invalid "As-is" parameters. Identical means that all adapted octets have the same numeric value as the corresponding original octets. This parameter is meant to allow for partial data preservation optimizations without a preservation commitment. The preserved data still crosses the connection with the callout server twice, but the OPES processor may be able to optimize its handling of the data.
添付されたデータが元のデータフローの指定されたオフセットにあるフラグメントと同一である場合、コールアウトサーバーは「そのまま」パラメータを送信する必要があります。 コールアウトサーバーに送信されていないデータフラグメントを指定する「現状のまま」のパラメーターは無効です。 受信者は無効な「現状のまま」のパラメータを無視しなければなりません。 同一とは、すべての適応オクテットが対応する元のオクテットと同じ数値を持つことを意味します。 このパラメーターは、保存コミットメントなしで部分的なデータ保存の最適化を可能にすることを目的としています。 保存されたデータは、コールアウトサーバーとの接続を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プロセッサは、Data Use Mine（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.
コールアウトサーバーは、データ使用マイン（DUM）メッセージでそのデータチャンクがコールアウトサーバーから来たかのように、指定されたオフセットから始まる、保存された元のデータの「サイズ」バイトを使用するようにOPESプロセッサに指示します。
The OPES processor MUST NOT terminate its data preservation commitment (section 7) in reaction to receiving a Data Use Yours (DUY) message.
OPESプロセッサは、Data Use Yours（DUY）メッセージの受信に反応して、データ保存のコミットメント（セクション7）を終了してはなりません。
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.
Data Preservation Interest（DPI）メッセージは、最初のオクテットオフセットとサイズをパラメーターとして使用して、元のデータチャンクを記述します。 チャンクは、コールアウトサーバーが将来のData Use Yours（DUY）メッセージで参照することに関心を持つ可能性がある元のデータの唯一の領域です。 このデータチャンクは、「再利用可能なデータ」と呼ばれます。 元のデータの残りは「使い捨てデータ」と呼ばれます。 したがって、使い捨てデータは、指定されたオフセットより下で、（オフセット+サイズ）オフセット以上のオクテットで構成されます。
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.
このメッセージを送信した後、コールアウトサーバーは、使い捨てのデータチャンクを参照するData Use Yours（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).
コールアウトサーバーは、以前のData Preservation Interest（DPI）メッセージで示された使い捨てデータ領域と重複する再利用可能なデータ領域を示してはなりません。 言い換えれば、再利用可能なデータが増大してはならず、使い捨てのデータが収縮してはなりません。 コールアウトサーバーがこのルールに違反している場合、Data Preservation Interest（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.
Data Preservation Interest（DPI）メッセージは、OPESプロセッサーにデータを保存させることはできません。 この文脈において、再利用可能という用語は、OPESプロセッサの協力を前提として、コールアウトサーバーが将来データを再利用することに関心があることを表しています。
For example, an offset value of zero and the size value of 2147483647 indicate that the server may want to reuse all the original data. The size value of zero indicates that the server is not going to send any more Data Use Yours (DUY) messages.
たとえば、ゼロのオフセット値と2147483647のサイズ値は、サーバーがすべての元のデータを再利用したいことを示します。 ゼロのサイズ値は、サーバーがこれ以上Data Use Yours（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プロセッサに通知します。 つまり、サーバーは、少なくともorg-sizeオクテットを送信した後、元のデータフローを早期に終了するようにプロセッサに要求しています（セクション8.1を参照）。
An OPES processor receiving a Want Stop Receiving Data (DWSR) message SHOULD terminate original dataflow by sending an Application Message End (AME) message with a 206 (partial) status code.
Want Stop Receiving Data（DWSR）メッセージを受信したOPESプロセッサは、206（部分）ステータスコードを含むApplication Message End（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プロセッサは、Want Stop Receiving Data（DWSR）メッセージの受信に反応して、データ保存のコミットメント（セクション7）を終了してはなりません（MUST NOT）。 他のメッセージと同様に、OPESプロセッサは、Want Stop Receiving Data（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プロセッサに通知します。 サーバーは、適合したデータフローを早期に終了する許可をプロセッサに求めています（セクション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メッセージが送信されると、コールアウトサーバーは、サーバーが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）メッセージを送信することにより、適応型データフローを早期に終了するようにコールアウトサーバーに指示します。 コールアウトサーバーは、データ送信の停止（DWSS）メッセージを送信することにより、データ送信の停止（DSS）メッセージを要求することが期待されます（セクション8.2を参照）。
A callout server receiving a solicited Stop Sending Data (DSS) message for a yet-unterminated adapted dataflow MUST immediately terminate dataflow by sending an Application Message End (AME) message with a 206 (partial) status code. If the callout server 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）メッセージを受信するコールアウトサーバーは、206（部分）ステータスコードでアプリケーションメッセージエンド（AME）メッセージを送信することにより、データフローを直ちに終了しなければなりません。 コールアウトサーバーが既に適応データフローを終了している場合、コールアウトサーバーはデータ送信停止（DSS）メッセージを無視する必要があります。 まだ未終端の適応データフローの非請求DSSメッセージを受信するコールアウトサーバーは、そのメッセージを無効または要請として処理する必要があります（つまり、サーバーは単に非請求DSSメッセージを無視することはできません）。
The OPES processor sending a Stop Sending Data (DSS) message MUST be able to reconstruct the adapted application message correctly after the callout server terminates dataflow. This requirement implies that the processor must have access to any original data sent to the callout after the Stop Sending Data (DSS) message, if there is any. Consequently, the OPES processor either has to send no data at all or has to keep a copy of it.
データ送信停止（DSS）メッセージを送信するOPESプロセッサは、コールアウトサーバーがデータフローを終了した後、適応されたアプリケーションメッセージを正しく再構築できなければなりません。 この要件は、データ送信停止（DSS）メッセージがある場合、プロセッサがコールアウトに送信された元のデータにアクセスできる必要があることを意味します。 したがって、OPSプロセッサはデータをまったく送信しないか、データのコピーを保持する必要があります。
If a callout server receives a DSS message and, in violation of the above rules, waits for more original data before sending an Application Message End (AME) response, a deadlock may occur: The OPES processor may wait for the Application Message End (AME) message to send more original data.
コールアウトサーバーがDSSメッセージを受信し、上記のルールに違反して、アプリケーションメッセージエンド（AME）応答を送信する前に元のデータを待機すると、デッドロックが発生する場合があります：OPESプロセッサはアプリケーションメッセージエンド（AME ）より多くのオリジナルデータを送信するメッセージ。
DWP: extends message with {
xid your-offset;
};
The Want Data Paused (DWP) message indicates the sender's temporary lack of interest in receiving data starting with the specified offset. This disinterest implies nothing about sender's intent to send data.
Want Data Paused（DWP）メッセージは、指定されたオフセットで始まるデータの受信に対する送信者の一時的な関心の欠如を示します。 この無関心は、データを送信する送信者の意図について何も意味しません。
The "your-offset" parameter refers to dataflow originating at the OCP agent receiving the parameter.
「your-offset」パラメーターは、パラメーターを受信するOCPエージェントで発生するデータフローを指します。
If, at the time the Want Data Paused (DWP) message is received, the recipient has already sent data at the specified offset, the message recipient MUST stop sending data immediately. Otherwise, the recipient MUST stop sending data immediately after it sends the specified offset. Once the recipient stops sending more data, it MUST immediately send a Paused My Data (DPM) message and MUST NOT send more data until it receives a Want More Data (DWM) message.
Want Data Paused（DWP）メッセージを受信した時点で、受信者が指定されたオフセットで既にデータを送信している場合、メッセージ受信者はデータの送信を直ちに停止しなければなりません。 そうでなければ、受信者は指定されたオフセットを送信した直後にデータの送信を停止しなければなりません。 受信者が追加データの送信を停止すると、すぐに一時停止マイデータ（DPM）メッセージを送信する必要があり、追加データ（DWM）メッセージを受信するまで追加データを送信してはなりません。
As are most OCP Core mechanisms, data pausing is asynchronous. The sender of the Want Data Paused (DWP) message MUST NOT rely on the data being paused exactly at the specified offset or at all.
ほとんどのOCPコアメカニズムと同様に、データの一時停止は非同期です。 Want Data Paused（DWP）メッセージの送信者は、指定されたオフセットで、またはまったく一時停止されているデータに依存してはなりません。
DPM: extends message with {
xid;
};
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.
Paused My Data（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.
Paused My Data（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.
Want 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プロセッサから送信される場合、your-sizeはadp-sizeです。 コールアウトサーバーによって送信された場合、your-sizeはorg-sizeです。
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エージェントで発生するデータフローを指します。 「サイズ要求」パラメータが存在する場合、その値は推奨される最小データサイズです。 受信者がより少ないチャンクでデータを配信できるようにすることを目的としています。 受信者は「サイズ要求」パラメータを無視してもよい[MAY]。 「サイズ要求」パラメーターがない場合は、「任意のサイズ」を意味します。
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メッセージのためにデータを送信していなかった場合、受信者はデータの送信を再開できます。 ただし、問題のデータフローが一時停止されているかどうかに関係なく、Want More Data（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プロセッサとコールアウトサーバーの両方は、ネゴシエーションオファー（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）メッセージを受信した場合、プロセッサはサーバーオファーを無視しなければなりません（MUST）。 それ以外の場合は、すぐに応答する必要があります。
If a callout server receives a Negotiation Offer (NO) message when its own offer is pending, the server MUST disregard its own offer. In either case, the server MUST respond immediately.
コールアウトサーバーが、自身のオファーが保留中にネゴシエーションオファー（NO）メッセージを受信した場合、サーバーは自身のオファーを無視する必要があります。 いずれの場合も、サーバーはすぐに応答する必要があります。
If an agent receives a message sequence that violates any of the above rules in this section, the agent MUST terminate the connection with a Connection End (CE) message indicating a failure.
エージェントがこのセクションの上記のルールのいずれかに違反するメッセージシーケンスを受信した場合、エージェントは失敗を示す接続終了（CE）メッセージで接続を終了する必要があります。
An optional "Offer-Pending" parameter is used for Negotiation Phase maintenance (section 6.1). The option's value defaults to "false".
オプションの「Offer-Pending」パラメータは、交渉フェーズのメンテナンスに使用されます（セクション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エージェントは保留中のトランザクションにネゴシエーションを適用してはなりません（MUST NOT）。 つまり、ネゴシエートされた機能は、新しい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）メッセージにそのパラメータを含めてはなりません（MUST NOT）。 予期しないSGパラメータを持つNRメッセージの受信者は、ネゴシエーション応答を無効として扱わなければなりません。
An optional "Offer-Pending" parameter is used for Negotiation Phase maintenance (section 6.1). The option's value defaults to "false".
オプションの「Offer-Pending」パラメータは、交渉フェーズのメンテナンスに使用されます（セクション6.1）。 オプションの値のデフォルトは「false」です。
When accepting or rejecting an offer, the sender of the Negotiation Response (NR) message MAY supply additional details via Rejects and Unknowns parameters. The Rejects parameter can be used to list features that were known to the Negotiation Offer (NO) recipient but could not be supported given negotiated state that existed when NO message was received. The Unknowns parameter can be used to list features that were unknown to the NO recipient.
オファーを受け入れるか拒否する場合、ネゴシエーション応答（NR）メッセージの送信者は、拒否および不明パラメータを介して追加の詳細を提供することができます。 Rejectsパラメーターを使用して、ネゴシエーションオファー（NO）受信者に知られているが、メッセージが受信されなかったときに存在するネゴシエートされた状態ではサポートできなかった機能を一覧表示できます。 Unknownsパラメーターを使用して、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.
Ability Query（AQ）メッセージは、即時のAbility Answer（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.
Ability Answer（AA）メッセージは、Ability Query（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）メッセージは、即時Progress Answer（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.
進行状況照会インターフェースは、アイドル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 Query（PQ）要求で識別されたトランザクションで作業している場合、エージェントはPAメッセージでPQに応答するときに対応するトランザクションID（xid）を送信する必要があります。 それ以外の場合、エージェントはトランザクションIDを送信してはなりません。 エージェントが指定されたトランザクションの元のアプリケーションメッセージで作業している場合、エージェントはOrg-Dataパラメータを送信する必要があります。 エージェントが元のデータフローのApplication Message End（AME）メッセージを既に送信または受信している場合、エージェントはOrg-dataパラメータを送信してはなりません（MUST NOT）。
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 Query（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のセキュリティに関する考慮事項について説明します。 OPESの脅威は[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は、機密情報を含む可能性のあるアプリケーションメッセージを中継します。 適切なトランスポート暗号化をネゴシエートして情報の漏洩や変更を防ぐことができます（セクション6を参照）が、OCPエージェントはデフォルトで暗号化されていないトランスポートをサポートする場合があります。 これらの構成は、たとえOPESプロキシ自体が安全であっても、アプリケーションメッセージをサードパーティの記録および変更に公開します。
OCP implementation bugs may lead to security vulnerabilities in OCP agents, even if OCP traffic itself remains secure. For example, a buffer overflow in a callout server caused by a malicious OPES processor may grant that processor access to information from other (100% secure) OCP connections, including connections with other OPES processors.
OCPトラフィック自体が安全である場合でも、OCP実装のバグにより、OCPエージェントにセキュリティの脆弱性が生じる可能性があります。 たとえば、悪意のあるOPESプロセッサによるコールアウトサーバーのバッファオーバーフローは、他の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メッセージ構造のネストの深さを制限せず、ほとんどの構文要素の長さ（OCTETの数）に上限を設けません。
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は、コールアウトサーバーがConnection Start（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は、コールアウトサーバーがService Group Created（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コアは、アプリケーションメッセージスタート（AMS）メッセージを介して維持するようにOPESプロセッサに指示される可能性がある同時適合フローの数に上限を設けません。
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.
Standards-track OCP Core拡張機能は、機能uriパラメータにhttp://www.iana.org/assignments/opes/ocp/プレフィックスを使用する必要があります。 IANAは、そのような「uri」パラメータによって識別されるリソースに、対応する機能登録を追加することをお勧めします。 IANAは、http：//www.iana.org/assignments/opes/ocp/ URLまたはその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.
コンプライアンスサブジェクトは、該当するすべての「MUST」および「SHOULD」要件を満たしている場合に準拠します。 定義上、「MUST」要件を満たすとは、要件で規定されているとおりに動作することを意味します。 「SHOULD」要件を満たすとは、要件で規定されているとおりに行動するか、異なる行動をとる理由があることを意味します。 要件がサブジェクトに指示（アドレス指定）する場合、要件はサブジェクトに適用されます。
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準拠とは、既知の「MUST」違反がなく、すべての「SHOULD」違反が意図的なものであることを意味します。 言い換えれば、「SHOULD」とは「違反する理由を満たさなければならない、または持たなければならない」という意味です。 準拠の主張には、サポートされていないSHOULDのリスト（ある場合）が適切な形式で添付され、優先される動作が選択されなかった理由を説明することが期待されます。
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拡張機能はこれらの変更を行うべきではなく（SHOULD NOT）、 "MUST"レベルでこれらの変更が有効になる前にネゴシエートされることを要求する必要があります。 非公式に、この仕様は、この仕様への変更（ある場合）が正常にネゴシエートされるまで、準拠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プロファイルのネゴシエーションは、「大きなオフセット」のサポートを意味する場合があります）。
As implied by the above rules, OCP extensions may dynamically alter the negotiation mechanism itself, but such an alternation would have to be negotiated first, using the negotiation mechanism defined by this specification. For example, successfully negotiating a feature might change the default "Offer-Pending" value from false to true.
上記の規則で暗示されているように、OCP拡張機能はネゴシエーションメカニズム自体を動的に変更する場合がありますが、この仕様で定義されたネゴシエーションメカニズムを使用して、最初にネゴシエートする必要があります。 たとえば、機能を正常にネゴシエートすると、デフォルトの「Offer-Pending」値がfalseからtrueに変更される場合があります。
Appendix A. Message Summary
付録A.メッセージの要約
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.
name：ワイヤに表示されるメッセージ名。
title: Human-friendly message title.
title：人間に優しいメッセージのタイトル。
P: Whether this specification documents message semantics as sent by an OPES processor.
P：この仕様がOPESプロセッサによって送信されたメッセージセマンティクスを文書化するかどうか。
S: Whether this specification documents message semantics as sent by a callout server.
S：この仕様が、コールアウトサーバーによって送信されたメッセージセマンティクスを文書化するかどうか。
tie: Related messages such as associated request, response message, or associated state message.
tie：関連する要求、応答メッセージ、関連する状態メッセージなどの関連メッセージ。
+-------+----------------------------+-------+-------+--------------+
| name | title | P | S | tie |
+-------+----------------------------+-------+-------+--------------+
| CS | Connection Start | X | X | CE |
| CE | Connection End | X | X | CS |
| SGC | Service Group Created | X | X | SGD TS |
| SGD | Service Group Destroyed | X | X | SGC |
| TS | Transaction Start | X | | TE SGC |
| TE | Transaction End | X | X | TS |
| AMS | Application Message Start | X | X | AME |
| AME | Application Message End | X | X | AMS DSS |
| DUM | Data Use Mine | X | X | DUY DWP |
| DUY | Data Use Yours | | X | DUM DPI |
| DPI | Data Preservation Interest | | X | DUY |
| DWSS | Want Stop Sending Data | | X | DWSR DSS |
| DWSR | Want Stop Receiving Data | | X | DWSS |
| DSS | Stop Sending Data | X | | DWSS |
| DWP | Want Data Paused | X | X | DPM |
| DPM | Paused My Data | X | X | DWP DWM |
| DWM | Want More Data | X | X | DPM |
| NO | Negotiation Offer | X | X | NR SGC |
| NR | Negotiation Response | X | X | NO |
| PQ | Progress Query | X | X | PA |
| PA | Progress Answer | X | X | PQ PR |
| PR | Progress Report | X | X | PA |
| AQ | Ability Query | X | X | AA |
| AA | Ability Answer | X | X | AQ |
+-------+----------------------------+-------+-------+--------------+
Appendix B. State Summary
付録B.状態の概要
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.
state：短い状態ラベル。
birth: Messages creating this state.
birth：この状態を作成するメッセージ。
death: Messages destroying this state.
death：この状態を破壊するメッセージ。
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 | |
+-------------------------------+-------------+-------------+-------+
Appendix C. Acknowledgements
付録C.謝辞
The author gratefully acknowledges the contributions of Abbie Barbir (Nortel Networks), Oskar Batuner (Independent Consultant), Larry Masinter (Adobe), Karel Mittig (France Telecom R&D), Markus Hofmann (Bell Labs), Hilarie Orman (The Purple Streak), Reinaldo Penno (Nortel Networks), and Martin Stecher (Webwasher), as well as an anonymous OPES working group participant.
著者は、Abbie Barbir（Nortel Networks）、Oskar Batuner（独立コンサルタント）、Larry Masinter（Adobe）、Karel Mittig（France Telecom R＆D）、Markus Hofmann（Bell Labs）、Hilarie Orman（The Purple Streak）の貢献に感謝します。 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]バーナーズ・リー、T。、フィールディング、R。、およびL.マスインター、「Uniform Resource Identifiers（URI）：Generic Syntax」、RFC 2396、1998年8月。
[RFC3835] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.
[RFC3835] Barbir、A.、Penno、R.、Chen、R.、Hofmann、M。、およびH. Orman、「オープンプラガブルエッジサービス（OPES）のアーキテクチャ」、RFC 3835、2004年8月。
[RFC3836] Beck, A., Hofmann, M., Orman, H., Penno, R., and A. Terzis, "Requirements for Open Pluggable Edge Services (OPES) Callout Protocols", RFC 3836, August 2004.
[RFC3836] Beck、A.、Hofmann、M.、Orman、H.、Penno、R。、およびA. Terzis、「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、「セキュリティの脅威とオープンプラガブルエッジサービス（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）Use Cases and Deployment Scenarios」、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。、「オープンプラガブルエッジサービス（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.、A。Rousskov、「P：メッセージ処理言語」、Work in Progress、2003年10月。
[RFC3914] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services (OPES) Treatment of IAB Considerations", RFC 3914, October 2004.
[RFC3914] Barbir、A。、およびA. Rousskov、「オープンプラガブルエッジサービス（OPES）IAB考慮事項の処理」、RFC 3914、2004年10月。
[OPES-HTTP] Rousskov, A. and M. Stecher, "HTTP adaptation with OPES", Work in Progress, January 2004.
[OPES-HTTP] Rousskov、A.、M。Stecher、「HTTP適応とOPES」、Work in Progress、2004年1月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080]ローズ、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]フロイド、S。およびL.デイグル、「オープンプラガブルエッジサービスのIABアーキテクチャおよびポリシーに関する考慮事項」、RFC 3238、2002年1月。
Author's Address
著者の住所
Alex Rousskov The Measurement Factory
アレックス・ルスコフ測定工場
EMail: rousskov@measurement-factory.com URI: http://www.measurement-factory.com/
メール：rousskov@measurement-factory.com URI：http://www.measurement-factory.com/
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、制限の対象となります。また、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本書および本書に含まれる情報は「現状のまま」提供され、寄稿者、代表者または代表者（もしあれば）、インターネット協会、インターネットエンジニアリングタスクフォースはすべての保証を放棄します 黙示的であるが、ここに記載されている情報の使用が商品性または特定の目的への適合性の黙示的保証を侵害しないという保証に限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書に記載されている技術の実装または使用に関連すると主張される可能性のある知的財産権またはその他の権利の有効性または範囲、またはそのような権利の下でのライセンスの有無に関して、立場をとりません。 利用可能 また、そのような権利を特定するための独立した努力を行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/ipr）から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この標準を実装するために必要な技術を対象とする著作権、特許、特許出願、またはその他の所有権に関心を寄せるよう、あらゆる利害関係者を招待します。 IETFのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。