[要約] RFC 2371は、Transaction Internet Protocol Version 3.0（TIP）の仕様を定義しています。TIPは、トランザクション処理をサポートするためのプロトコルであり、信頼性とセキュリティを重視しています。このRFCの目的は、TIPの機能と動作を明確にし、ネットワーク上でのトランザクション処理の効率性を向上させることです。
Network Working Group J. Lyon
Request for Comments: 2371 Microsoft
Category: Standards Track K. Evans
J. Klein
Tandem Computers
July 1998
Transaction Internet Protocol Version 3.0
トランザクションインターネットプロトコルバージョン3.0
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed, even in the face of failures. This document proposes a simple, easily-implemented protocol for achieving this end.
いくつかの作業で異なるノードが連携する多くのアプリケーションでは、作業がアトミックに行われることを保証する必要があります。つまり、障害が発生しても、各ノードは作業を完了するかどうかについて同じ結論に達する必要があります。このドキュメントは、この目的を達成するためのシンプルで簡単に実装できるプロトコルを提案します。
Table of Contents
目次
1. Introduction 2 2. Example Usage 3 3. Transactions 4 4. Connections 4 5. Transaction Identifiers 5 6. Pushing vs. Pulling Transactions 5 7. TIP Transaction Manager Identification & Connection Establishment 6 8. TIP Uniform Resource Locators 8 9. States of a Connection 10 10. Protocol Versioning 12 11. Commands and Responses 12 12. Command Pipelining 13 13. TIP Commands 13 14. Error Handling 20 15. Connection Failure and Recovery 20 16. Security Considerations 22 17. References 25 18. Authors' Addresses 26 19. Comments 26 Appendix A. The TIP Multiplexing Protocol Version 2.0. 27 Fully Copyright Statement 31
1.はじめに2 2.使用例3 3.トランザクション4 4.接続4 5.トランザクション識別子5 6.トランザクションのプッシュとプル5 5. TIPトランザクションマネージャの識別と接続の確立6 8. TIP Uniform Resource Locator 8 9.状態接続の設定10 10.プロトコルのバージョン管理12 11.コマンドと応答12 12.コマンドのパイプライン処理13 13. TIPコマンド13 14.エラー処理20 15.接続の失敗と回復20 16.セキュリティに関する考慮事項22 17.参考資料25 18.著者アドレス26 19.コメント26付録A. TIP多重化プロトコルバージョン2.0。 27完全な著作権表示31
The standard method for achieving atomic commitment is the two-phase commit protocol; see [1] for an introduction to atomic commitment and two-phase commit protocols.
アトミックコミットメントを達成するための標準的な方法は、2フェーズコミットプロトコルです。アトミックコミットメントと2フェーズコミットプロトコルの概要については、[1]を参照してください。
Numerous two-phase commit protocols have been implemented over the years. However, none of them has become widely used in the Internet, due mainly to their complexity. Most of that complexity comes from the fact that the two-phase commit protocol is bundled together with a specific program-to-program communication protocol, and that protocol lives on top of a very large infrastructure.
長年にわたり、多くの2フェーズコミットプロトコルが実装されています。ただし、主にその複雑さのために、インターネットで広く使用されるようになったものはありません。その複雑さのほとんどは、2フェーズコミットプロトコルが特定のプログラム間通信プロトコルと一緒にバンドルされており、そのプロトコルが非常に大規模なインフラストラクチャの上に存在するという事実から生じます。
This memo proposes a very simple two-phase commit protocol. It achieves its simplicity by specifying only how different nodes agree on the outcome of a transaction; it allows (even requires) that the subject matter on which the nodes are agreeing be communicated via other protocols. By doing so, we avoid all of the issues related to application communication semantics and data representation (to name just a few). Independent of the application communication protocol a transaction manager may use the Transport Layer Security protocol [3] to authenticate other transaction managers and encrypt messages.
このメモは、非常に単純な2フェーズコミットプロトコルを提案しています。異なるノードがトランザクションの結果にどのように同意するかのみを指定することにより、その単純さを実現します。それは、ノードが同意している主題が他のプロトコルを介して通信されることを可能にします（要求さえします）。そうすることで、アプリケーション通信のセマンティクスとデータ表現に関連するすべての問題を回避できます（ほんの数例を挙げれば）。アプリケーション通信プロトコルとは関係なく、トランザクションマネージャはトランスポート層セキュリティプロトコル[3]を使用して、他のトランザクションマネージャを認証し、メッセージを暗号化できます。
It is envisioned that this protocol will be used mainly for a transaction manager on one Internet node to communicate with a transaction manager on another node. While it is possible to use this protocol for application programs and/or resource managers to speak to transaction managers, this communication is usually intra-node, and most transaction managers already have more-than-adequate interfaces for the task.
このプロトコルは、主に1つのインターネットノード上のトランザクションマネージャが別のノード上のトランザクションマネージャと通信するために使用されることが想定されています。アプリケーションプログラムやリソースマネージャーがトランザクションマネージャーと通信するためにこのプロトコルを使用することは可能ですが、この通信は通常ノード内で行われ、ほとんどのトランザクションマネージャーはタスクに対して十分以上のインターフェースをすでに持っています。
While we do not expect this protocol to replace existing ones, we do expect that it will be relatively easy for many existing heterogeneous transaction managers to implement this protocol for communication with each other.
このプロトコルが既存のプロトコルに取って代わるとは予想していませんが、多くの既存の異種トランザクションマネージャーが相互に通信するためにこのプロトコルを実装することは比較的容易です。
Further supplemental information regarding the TIP protocol can be found in [5].
TIPプロトコルに関する補足情報は、[5]にあります。
Today the electronic shopping basket is a common metaphor at many electronic store-fronts. Customers browse through an electronic catalog, select goods and place them into an electronic shopping basket. HTTP servers [2] provide various means ranging from URL encoding to context cookies to keep track of client context (e.g. the shopping basket of a customer) and resume it on subsequent customer requests.
今日、電子ショッピングバスケットは、多くの電子店舗でよく使われる比喩です。顧客は電子カタログを閲覧して商品を選択し、電子買い物かごに入れます。 HTTPサーバー[2]は、URLエンコーディングからコンテキストCookieまでさまざまな手段を提供して、クライアントコンテキスト（顧客の買い物かごなど）を追跡し、その後の顧客の要求で再開します。
Once a customer has finished shopping they may decide to commit their selection and place the associated orders. Most orders may have no relationship with each other except being executed as part of the same shopping transaction; others may be dependent on each other (for example, if made as part of a special offering). Irrespective of these details a customer will expect that all orders have been successfully placed upon receipt of a positive acknowledgment. Today's electronic store-fronts must implement their own special protocols to coordinate such placement of all orders. This programming is especially complex when orders are placed through multiple electronic store-fronts. This complexity limits the potential utility of internet applications, and constrains growth. The protocol described in this document intends to provide a standard for Internet servers to achieve agreement on a unit of shared work (e.g. placement of orders in an electronic shopping basket). The server (e.g. a CGI program) placing the orders may want to start a transaction calling its local transaction manager, and ask other servers participating in the work to join the transaction. The server placing the orders passes a reference to the transaction as user data on HTTP requests to the other servers. The other servers call their transaction managers to start a local transaction and ask them to join the remote transaction using the protocol defined in this document. Once all orders have been placed, execution of the two-phase-commit protocol is delegated to the involved transaction managers. If the transaction commits, all orders have been successfully placed and the customer gets a positive acknowledgment. If the transaction aborts no orders will be placed and the customer will be informed of the problem.
顧客が買い物を終えたら、彼らは選択をコミットして関連する注文を出すことに決めるかもしれません。ほとんどの注文は、同じショッピングトランザクションの一部として実行されることを除いて、互いに関係がない場合があります。他のメンバーは互いに依存している可能性があります（たとえば、特別オファーの一部として作成された場合）。これらの詳細に関係なく、お客様はすべての注文が肯定応答を受け取ったときに正常に行われたと期待します。今日の電子店舗では、そのようなすべての注文の配置を調整するために、独自の特別なプロトコルを実装する必要があります。このプログラミングは、注文が複数の電子店舗を通じて行われる場合は特に複雑です。この複雑さにより、インターネットアプリケーションの潜在的なユーティリティが制限され、成長が抑制されます。このドキュメントで説明されているプロトコルは、インターネットサーバーが共有作業の単位（電子ショッピングバスケットでの注文の配置など）に関する合意を達成するための標準を提供することを目的としています。注文を行うサーバー（CGIプログラムなど）は、ローカルトランザクションマネージャーを呼び出してトランザクションを開始し、作業に参加している他のサーバーにトランザクションへの参加を依頼する場合があります。注文を出すサーバーは、他のサーバーへのHTTP要求のユーザーデータとしてトランザクションへの参照を渡します。他のサーバーは、トランザクションマネージャーを呼び出してローカルトランザクションを開始し、このドキュメントで定義されているプロトコルを使用してリモートトランザクションに参加するように依頼します。すべての注文が行われると、2フェーズコミットプロトコルの実行は、関連するトランザクションマネージャーに委任されます。トランザクションがコミットすると、すべての注文が正常に行われ、顧客は肯定的な確認を受け取ります。トランザクションが中止された場合、注文は行われず、お客様に問題が通知されます。
Transaction support greatly simplifies programming of these applications as exception handling and failure recovery are delegated to a special component. End users are also not left having to deal with the consequences of only partial success. While this example shows how the protocol can be used by HTTP servers, applications may use the protocol when accessing a remote database (e.g. via ODBC), or invoking remote services using other already existing protocols (e.g.
トランザクション処理は、例外処理と障害回復が特別なコンポーネントに委任されるため、これらのアプリケーションのプログラミングを大幅に簡素化します。エンドユーザーも、部分的な成功のみの結果に対処する必要はありません。この例では、HTTPサーバーでプロトコルを使用する方法を示していますが、アプリケーションは、リモートデータベースにアクセスするとき（ODBCなどを介して）、または他の既存のプロトコルを使用してリモートサービスを呼び出すときに（例：
RPC). The protocol makes it easy for applications in a heterogeneous network to participate in the same transaction, even if using different communication protocols.
RPC）。このプロトコルにより、異なる通信プロトコルを使用している場合でも、異種ネットワークのアプリケーションが同じトランザクションに参加することが容易になります。
"Transaction" is the term given to the programming model whereby computational work performed has atomic semantics. That is, either all work completes successfully and changes are made permanent (the transaction commits), or if any work is unsuccessful, changes are undone (the transaction aborts). The work comprising a transaction (unit of work), is defined by the application.
「トランザクション」とは、実行される計算作業がアトミックセマンティクスを持つプログラミングモデルに与えられる用語です。つまり、すべての作業が正常に完了し、変更が永続化される（トランザクションがコミットされる）か、またはいずれかの作業が失敗した場合、変更が取り消されます（トランザクションが中止されます）。トランザクション（作業単位）を構成する作業は、アプリケーションによって定義されます。
The Transaction Internet Protocol (TIP) requires a reliable ordered stream transport with low connection setup costs. In an Internet (IP) environment, TIP operates over TCP, optionally using TLS to provide a secured and authenticated connection, and optionally using a protocol to multiplex light-weight connections over the same TCP or TLS connection.
Transaction Internet Protocol（TIP）には、接続設定コストが低く、信頼性の高い順序付けされたストリーム転送が必要です。インターネット（IP）環境では、TIPはTCPで動作し、オプションでTLSを使用して安全で認証された接続を提供し、オプションでプロトコルを使用して同じTCPまたはTLS接続で軽量接続を多重化します。
Transaction managers that share transactions establish a TCP (and optionally a TLS) connection. The protocol uses a different connection for each simultaneous transaction shared betwween two transaction managers. After a transaction has ended, the connection can be reused for a different transaction.
トランザクションを共有するトランザクションマネージャは、TCP（およびオプションでTLS）接続を確立します。プロトコルは、2つのトランザクションマネージャ間で共有される同時トランザクションごとに異なる接続を使用します。トランザクションが終了した後、接続は別のトランザクションに再利用できます。
Optionally, instead of associating a TCP or TLS connection with only a single transaction, two transaction managers may agree on a protocol to multiplex light-weight connections over the same TCP or TLS connection, and associate each simultaneous transaction with a separate light-weight connection. Using light-weight connections reduces latency and resource consumption associated with executing simultaneous transactions. Similar techniques as described here are widely used by existing transaction processing systems. See Appendix A for an example of one such protocol.
オプションで、TCPまたはTLS接続を単一のトランザクションのみに関連付ける代わりに、2つのトランザクションマネージャーがプロトコルに同意し、同じTCPまたはTLS接続を介して軽量接続を多重化し、各同時トランザクションを個別の軽量接続に関連付けることができます。 。軽量接続を使用すると、同時トランザクションの実行に関連する遅延とリソース消費が減少します。ここで説明するのと同様の手法は、既存のトランザクション処理システムで広く使用されています。そのようなプロトコルの例については、付録Aを参照してください。
Note that although the TIP protocol itself is described only in terms of TCP and TLS, there is nothing to preclude the use of TIP with other transport protocols. However, it is up to the implementor to ensure the chosen transport provides equivalent semantics to TCP, and to map the TIP protocol appropriately.
TIPプロトコル自体はTCPとTLSに関してのみ説明されていますが、他のトランスポートプロトコルでのTIPの使用を妨げるものは何もないことに注意してください。ただし、選択したトランスポートがTCPと同等のセマンティクスを提供することを保証し、TIPプロトコルを適切にマップするかどうかは、実装者次第です。
In this document the terms "connection" or "TCP connection" can refer to a TIP TCP connection, a TIP TLS connection, or a TIP multiplexing connection (over either TCP or TLS). It makes no difference which, the behavior is the same in each case. Where there are differences in behavior between the connection types, these are stated explicitly.
このドキュメントでは、「接続」または「TCP接続」という用語は、TIP TCP接続、TIP TLS接続、または（TCPまたはTLSを介した）TIP多重化接続を指します。どちらの場合も動作は同じで、違いはありません。接続タイプ間に動作の違いがある場合、これらは明示的に述べられています。
Unfortunately, there is no single globally-accepted standard for the format of a transaction identifier; there are various standard and proprietary formats. Allowed formats for a TIP transaction identifier are described below in the section "TIP Uniform Resource Locators". A transaction manager may map its internal transaction identifiers into this TIP format in any manner it sees fit. Furthermore, each party in a superior/subordinate relationship gets to assign its own identifier to the transaction; these identifiers are exchanged when the relationship is first established. Thus, a transaction manager gets to use its own format of transaction identifier internally, but it must remember a foreign transaction identifier for each superior/subordinate relationship in which it is involved.
残念ながら、トランザクション識別子の形式について、世界的に認められた単一の標準はありません。さまざまな標準および独自の形式があります。 TIPトランザクション識別子に使用できる形式については、「TIP Uniform Resource Locators」のセクションで説明します。トランザクションマネージャは、適切と思われる方法で、内部トランザクション識別子をこのTIP形式にマッピングできます。さらに、上位/下位関係の各当事者は、トランザクションに独自の識別子を割り当てることができます。これらの識別子は、関係が最初に確立されたときに交換されます。したがって、トランザクションマネージャは独自の形式のトランザクション識別子を内部的に使用するようになりますが、関係する上位/下位関係ごとに外部トランザクション識別子を覚えておく必要があります。
Suppose that some program on node "A" has created a transaction, and wants some program on node "B" to do some work as part of the transaction. There are two classical ways that he does this, referred to as the "push" model and the "pull" model.
ノード "A"の一部のプログラムがトランザクションを作成し、ノード "B"の一部のプログラムにトランザクションの一部として何らかの処理を実行させたいとします。彼がこれを行うには、「プッシュ」モデルと「プル」モデルと呼ばれる2つの古典的な方法があります。
In the "push" model, the program on A first asks his transaction manager to export the transaction to node B. A's transaction manager sends a message to B's TM asking it to instantiate the transaction as a subordinate of A, and return its name for the transaction. The program on A then sends a message to its counterpart on B on the order of "Do some work, and make it part of the transaction that your transaction manager already knows of by the name ...". Because A's TM knows that it sent the transaction to B's TM, A's TM knows to involve B's TM in the two-phase commit process.
「プッシュ」モデルでは、Aのプログラムは最初にトランザクションマネージャーにトランザクションをノードBにエクスポートするように要求します。AのトランザクションマネージャーはメッセージをBのTMに送信して、トランザクションをAの下位としてインスタンス化し、その名前を返します。トランザクション。次に、Aのプログラムは、「何らかの作業を行い、トランザクションマネージャーが名前で知っているトランザクションの一部にする...」の順序で、Bの対応するプログラムにメッセージを送信します。 AのTMはトランザクションをBのTMに送信したことを知っているため、AのTMはBのTMを2フェーズコミットプロセスに関与させることを知っています。
In the "pull" model, the program on A merely sends a message to B on the order of "Do some work, and make it part of the transaction that my TM knows by the name ...". The program on B asks its TM to enlist in the transaction. At that time, B's TM will "pull" the transaction over from A. As a result of this pull, A's TM knows to involve B's TM in the two-phase commit process.
「プル」モデルでは、A上のプログラムは、「何らかの作業を行い、TMが名前で知っているトランザクションの一部にする」というメッセージをBに送信するだけです。 Bのプログラムは、TMにトランザクションに参加するように要求します。その時点で、BのTMはトランザクションをAから「プル」します。このプルの結果、AのTMはBのTMを2フェーズコミットプロセスに関与させることを認識します。
The protocol described here supports both the "push" and "pull" models.
ここで説明するプロトコルは、「プッシュ」モデルと「プル」モデルの両方をサポートしています。
In order for TIP transaction managers to connect they must be able to identify and locate each other. The information necessary to do this is described by the TIP transaction manager address.
TIPトランザクションマネージャーが接続するには、お互いを識別して特定できる必要があります。これを行うために必要な情報は、TIPトランザクションマネージャのアドレスによって記述されます。
[This specification does not prescribe how TIP transaction managers initially obtain the transaction manager address (which will probably be via some implementation-specific configuration mechanism).]
[この仕様は、TIPトランザクションマネージャーがトランザクションマネージャーのアドレスを最初に取得する方法を規定していません（おそらく、実装固有の構成メカニズムを介して行われます）。]
TIP transaction manager addresses take the form:
TIPトランザクションマネージャのアドレスは、次の形式を取ります。
<hostport><path>
The <hostport> component comprises:
<hostport>コンポーネントは次の要素で構成されています。
<host>[:<port>]
where <host> is either a <dns name> or an <ip address>; and <port> is a decimal number specifying the port at which the transaction manager (or proxy) is listening for requests to establish TIP connections. If the port number is omitted, the standard TIP port number (3372) is used.
ここで、<host>は<dns name>または<ip address>です。 <port>は、トランザクションマネージャ（またはプロキシ）がTIP接続を確立するための要求をリッスンするポートを指定する10進数です。ポート番号を省略すると、標準のTIPポート番号（3372）が使用されます。
A <dns name> is a standard name, acceptable to the domain name service. It must be sufficiently qualified to be useful to the receiver of the command.
<dns name>は標準名であり、ドメインネームサービスで使用できます。コマンドの受信者に役立つように十分に修飾されている必要があります。
An <ip address> is an IP address, in the usual form: four decimal numbers separated by period characters.
<ipアドレス>は、通常の形式のIPアドレスで、ピリオド文字で区切られた4つの10進数です。
The <hostport> component defines the scope (locale) of the <path> component.
<hostport>コンポーネントは、<path>コンポーネントのスコープ（ロケール）を定義します。
The <path> component of the transaction manager address contains data identifying the specific TIP transaction manager, at the location defined by <hostport>.
トランザクションマネージャアドレスの<path>コンポーネントには、<hostport>で定義された場所にある、特定のTIPトランザクションマネージャを識別するデータが含まれています。
The <path> component takes the form:
<path>コンポーネントの形式は次のとおりです。
"/" [path_segments]
"/" [path_segments]
path_segments = segment *( "/" segment )
segment = *pchar *( ";" param )
param = *pchar
pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+"
unreserved = ASCII character octets with values in the range
(inclusive): 48-57, 65-90, 97-122 | "$" | "-" | "_" |
"." | "!" | "~" | "*" | "'" | "(" | ")" | ","
escaped = "%" hex hex
hex = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" |
"A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" |
"e" | "f"
The <path> component may consist of a sequence of path segments separated by a single slash "/" character. Within a path segment, the characters "/", ";", "=", and "?" are reserved. Each path segment may include a sequence of parameters, indicated by the semicolon ";" character. The parameters are not significant to the parsing of relative references.
<path>コンポーネントは、単一のスラッシュ「/」文字で区切られた一連のパスセグメントで構成されます。パスセグメント内の文字「/」、「;」、「=」、「？」予約されています。各パスセグメントには、セミコロン「;」で示される一連のパラメータを含めることができます。キャラクター。パラメータは、相対参照の解析には重要ではありません。
[It is intended that the form of the transaction manager address follow the proposed scheme for Uniform Resource Identifiers (URI) [8].]
[トランザクションマネージャアドレスの形式は、提案されているUniform Resource Identifier（URI）[8]のスキームに従うことを意図しています。]
The TIP transaction manager address therefore provides to the connection initiator (the primary) the endpoint identifier to be used for the TCP connection (<hostport>), and to the connection receiver (the secondary) the path to be used to locate the specific TIP transaction manager (<path>). This is all the information required for the connection between the primary and secondary TIP transaction managers to be established.
したがって、TIPトランザクションマネージャーアドレスは、TCP接続（<hostport>）に使用されるエンドポイント識別子を接続開始者（プライマリ）に提供し、特定のTIPを見つけるために使用されるパスを接続レシーバー（セカンダリ）に提供しますトランザクションマネージャ（<path>）。これは、プライマリとセカンダリのTIPトランザクションマネージャ間の接続を確立するために必要なすべての情報です。
After a connection has been established, the primary party issues an IDENTIFY command. This command includes as parameters two transaction manager addresses: the primary transaction manager address, and the secondary transaction manager address.
接続が確立された後、プライマリパーティはIDENTIFYコマンドを発行します。このコマンドには、パラメーターとして2つのトランザクションマネージャーアドレス（プライマリトランザクションマネージャーアドレスとセカンダリトランザクションマネージャーアドレス）が含まれています。
The primary transaction manager address identifies the TIP transaction manager that initiated the connection. This information is required in certain cases after connection failures, when one of the parties of the connection must re-establish a new connection to the other party in order to complete the two-phase-commit protocol. If the primary party needs to re-establish the connection, the job is easy: a connection is established in the same way as was the original connection. However, if the secondary party needs to re-establish the connection, it must be known how to contact the initiator of the original connection. This information is supplied to the secondary via the primary transaction manager address on the IDENTIFY command. If a primary transaction manager address is not supplied, the primary party must not perform any action which would require a connection to be re-established (e.g. to perform recovery actions).
プライマリトランザクションマネージャアドレスは、接続を開始したTIPトランザクションマネージャを識別します。この情報は、接続の障害が発生した後、2フェーズコミットプロトコルを完了するために、接続の一方が他方への新しい接続を再確立する必要がある場合に必要になります。プライマリパーティが接続を再確立する必要がある場合、作業は簡単です。接続は、元の接続と同じ方法で確立されます。ただし、セカンダリパーティが接続を再確立する必要がある場合は、元の接続のイニシエータに連絡する方法を知っている必要があります。この情報は、IDENTIFYコマンドのプライマリトランザクションマネージャアドレスを介してセカンダリに提供されます。プライマリトランザクションマネージャーのアドレスが指定されていない場合、プライマリパーティは、接続の再確立を必要とするアクション（リカバリアクションの実行など）を実行してはなりません。
The secondary transaction manager address identifies the receiving TIP transaction manager. In the case of TIP communication via intermediate proxy servers, this URL may be used by the proxy servers to correctly identify and connect to the required TIP transaction manager.
セカンダリトランザクションマネージャーアドレスは、受信TIPトランザクションマネージャーを識別します。中間プロキシサーバーを介したTIP通信の場合、プロキシサーバーはこのURLを使用して、必要なTIPトランザクションマネージャーを正しく識別し、接続することができます。
Transactions and transaction managers are resources associated with the TIP protocol. Transaction managers and transactions are located using the transaction manager address scheme. Once a connection has been established, TIP commands may be sent to operate on transactions associated with the respective transaction managers.
トランザクションとトランザクションマネージャは、TIPプロトコルに関連付けられたリソースです。トランザクションマネージャとトランザクションは、トランザクションマネージャのアドレススキームを使用して配置されます。接続が確立されると、TIPコマンドを送信して、それぞれのトランザクションマネージャに関連付けられているトランザクションを操作できます。
Applications which want to pull a transaction from a remote node must supply a reference to the remote transaction which allows the local transaction manager (i.e. the transaction manager pulling the transaction) to connect to the remote transaction manager and identify the particular transaction. Applications which want to push a transaction to a remote node must supply a reference to the remote transaction manager (i.e. the transaction manager to which the transaction is to be pushed), which allows the local transaction manager to locate the remote transaction manager. The TIP protocol defines a URL scheme [4] which allows applications and transaction managers to exchange references to transaction managers and transactions.
リモートノードからトランザクションをプルするアプリケーションは、リモートトランザクションへの参照を提供する必要があります。これにより、ローカルトランザクションマネージャー（つまり、トランザクションマネージャーがトランザクションをプルする）がリモートトランザクションマネージャーに接続し、特定のトランザクションを識別できるようになります。トランザクションをリモートノードにプッシュするアプリケーションは、リモートトランザクションマネージャー（つまり、トランザクションがプッシュされるトランザクションマネージャー）への参照を提供する必要があります。これにより、ローカルトランザクションマネージャーがリモートトランザクションマネージャーを見つけることができます。 TIPプロトコルは、アプリケーションとトランザクションマネージャーがトランザクションマネージャーとトランザクションへの参照を交換できるようにするURLスキーム[4]を定義します。
A TIP URL takes the form:
TIP URLの形式は次のとおりです。
tip://<transaction manager address>?<transaction string>
where <transaction manager address> identifies the TIP transaction manager (as defined in Section 7 above); and <transaction string> specifies a transaction identifier, which may take one of two forms (standard or non-standard):
ここで、<トランザクションマネージャアドレス>はTIPトランザクションマネージャを識別します（上記のセクション7で定義）。 <transaction string>は、次の2つの形式（標準または非標準）のいずれかを取るトランザクション識別子を指定します。
i. "urn:" <NID> ":" <NSS>
A standard transaction identifier, conforming to the proposed Internet Standard for Uniform Resource Names (URNs), as specified by RFC2141; where <NID> is the Namespace Identifier, and <NSS> is the Namespace Specific String. The Namespace ID determines the syntactic interpretation of the Namespace Specific String. The Namespace Specific String is a sequence of characters representing a transaction identifier (as defined by <NID>). The rules for the contents of these fields are specified by [6] (valid characters, encoding, etc.).
RFC2141で指定されているUniform Resource Names（URN）のインターネット標準案に準拠した標準トランザクション識別子。ここで、<NID>は名前空間識別子、<NSS>は名前空間固有の文字列です。名前空間IDは、名前空間固有の文字列の構文上の解釈を決定します。名前空間固有の文字列は、トランザクションID（<NID>で定義）を表す一連の文字です。これらのフィールドの内容の規則は、[6]で指定されています（有効な文字、エンコーディングなど）。
This format of <transaction string> may be used to express global transaction identifiers in terms of standard representations. Examples for <NID> might be <iso> or <xopen>. e.g.
この<transaction string>の形式は、標準の表現でグローバルトランザクション識別子を表すために使用できます。 <NID>の例は、<iso>または<xopen>です。例えば
tip://123.123.123.123/?urn:xopen:xid
Note that Namespace Ids require registration. See [7] for details on how to do this.
名前空間IDには登録が必要です。これを行う方法の詳細については、[7]を参照してください。
ii. <transaction identifier>
ii。 <トランザクション識別子>
A sequence of printable ASCII characters (octets with values in the range 32 through 126 inclusive (excluding ":") representing a transaction identifier. In this non-standard case, it is the combination of <transaction manager address> and <transaction identifier> which ensures global uniqueness. e.g.
トランザクション識別子を表す印刷可能なASCII文字のシーケンス（32〜126の範囲の値を持つオクテット（ "："を除く）。この非標準のケースでは、<トランザクションマネージャアドレス>と<トランザクション識別子>の組み合わせです。グローバルな一意性を保証します。
tip://123.123.123.123/?transid1
To create a non-standard TIP URL from a transaction identifier, first replace any reserved characters in the transaction identifier with their equivalent escape sequences, then insert the appropriate transaction manager address. If the transaction identifier is one that you created, insert your own transaction manager address. If the transaction identifier is one that you received on a TIP connection that you initiated, use the secondary transaction manager address that was sent in the IDENTIFY command. If the transaction identifier is one that you received on a TIP connection that you did not initiate, use the primary transaction manager address that was received in the IDENTIFY command.
トランザクション識別子から非標準のTIP URLを作成するには、まずトランザクション識別子の予約文字を同等のエスケープシーケンスで置き換えてから、適切なトランザクションマネージャアドレスを挿入します。トランザクション識別子が作成したものである場合は、独自のトランザクションマネージャアドレスを挿入します。トランザクション識別子が、開始したTIP接続で受信したものである場合は、IDENTIFYコマンドで送信されたセカンダリトランザクションマネージャアドレスを使用します。トランザクション識別子が、開始していないTIP接続で受信したものである場合は、IDENTIFYコマンドで受信したプライマリトランザクションマネージャアドレスを使用します。
TIP URLs must be guaranteed globally unique for all time. This uniqueness constraint ensures TIP URLs are never duplicated, thereby preventing possible non-deterministic behaviour. How uniqueness is achieved is implementation specific. For example, the Universally Unique Identifier (UUID, also known as a Globally Unique Identifier, or GUID (see [9])) could be used as part of the <transaction string>. Note also that some standard transaction identifiers may define their own rules for ensuring global uniqueness (e.g. OSI CCR atomic action identifiers).
TIP URLは、常にグローバルに一意であることが保証されている必要があります。この一意性の制約により、TIP URLが重複することがなくなり、非決定的な動作の可能性を防ぎます。どのように一意性が達成されるかは、実装によって異なります。たとえば、Universally Unique Identifier（UUID、別名Globally Unique Identifier、またはGUID（[9]を参照））は、<transaction string>の一部として使用できます。また、一部の標準トランザクション識別子は、グローバルな一意性を確保するための独自のルールを定義している場合があります（例：OSI CCRアトミックアクション識別子）。
Except as otherwise described above, the TIP URL scheme follows the rules for reserved characters as defined in [4], and uses escape sequences as defined in [4] Section 5.
上記以外の場合を除き、TIP URLスキームは、[4]で定義されている予約文字のルールに従い、[4]セクション5で定義されているエスケープシーケンスを使用します。
Note that the TIP protocol itself does not use the TIP URL scheme (it does use the transaction manager address scheme). The TIP URL scheme is proposed as a standard way to pass transaction identification information through other protocols. e.g. between cooperating application processes. The TIP URL may then be used to communicate to the local transaction manager the information necessary to associate the application with a particular TIP transaction. e.g. to PULL the transaction from a remote transaction manager. It is anticipated that each TIP implementation will provide some set of APIs for this purpose ([5] includes examples of such APIs).
TIPプロトコル自体はTIP URLスキームを使用しないことに注意してください（トランザクションマネージャアドレススキームを使用します）。 TIP URLスキームは、トランザクション識別情報を他のプロトコルで渡す標準的な方法として提案されています。例えば連携するアプリケーションプロセス間。次に、TIP URLを使用して、アプリケーションを特定のTIPトランザクションに関連付けるために必要な情報をローカルトランザクションマネージャに伝達できます。例えばリモートトランザクションマネージャからトランザクションをプルします。各TIP実装は、この目的のためにいくつかのAPIセットを提供することが予想されます（[5]には、そのようなAPIの例が含まれています）。
At any instant, only one party on a connection is allowed to send commands, while the other party is only allowed to respond to commands that he receives. Throughout this document, the party that is allowed to send commands is called "primary"; the other party is called "secondary". Initially, the party that initiated the connection is primary; however, a few commands cause the roles to switch. A connection returns to its original polarity whenever the Idle state is reached.
いつでも、接続の一方の当事者だけがコマンドを送信でき、もう一方の当事者は、受信したコマンドに応答することしかできません。このドキュメント全体で、コマンドの送信が許可されているパーティは「プライマリ」と呼ばれます。相手は「セカンダリ」と呼ばれます。最初は、接続を開始した側がプライマリです。ただし、いくつかのコマンドによって役割が切り替わります。アイドル状態になると、接続は元の極性に戻ります。
When multiplexing is being used, these rules apply independently to each "virtual" connection, regardless of the polarity of the underlying connection (which will be in the Multiplexing state).
多重化が使用されている場合、これらのルールは、基になる接続（多重化状態になる）の極性に関係なく、各「仮想」接続に個別に適用されます。
Note that commands may be sent "out of band" by the secondary via the use of pipelining. This does not affect the polarity of the connection (i.e. the roles of primary and secondary do not switch). See section 12 for details.
コマンドは、パイプラインを使用してセカンダリから「帯域外」で送信される場合があることに注意してください。これは接続の極性には影響しません（つまり、プライマリとセカンダリの役割は切り替わりません）。詳細については、セクション12を参照してください。
In the normal case, TIP connections should only be closed by the primary, when in Initial state. It is generally undesirable for a connection to be closed by the secondary, although this may be necessary in certain error cases.
通常の場合、TIP接続は、初期状態のときにプライマリによってのみ閉じられる必要があります。セカンダリによって接続が閉じられることは一般的に望ましくありませんが、これは特定のエラーの場合に必要になることがあります。
At any instant, a connection is in one of the following states. From the point of view of the secondary party, the state changes when he sends a reply; from the point of view of the primary party, the state changes when he receives a reply.
いつでも、接続は次のいずれかの状態です。二次パーティの観点から見ると、彼が応答を送信すると状態が変化します。プライマリパーティの観点からは、彼が応答を受け取ると状態が変化します。
Initial: The initial connection starts out in the Initial state. Upon entry into this state, the party that initiated the connection becomes primary, and the other party becomes secondary. There is no transaction associated with the connection in this state. From this state, the primary can send an IDENTIFY or a TLS command.
初期：初期接続は初期状態で始まります。この状態になると、接続を開始したパーティがプライマリになり、他のパーティがセカンダリになります。この状態の接続に関連付けられているトランザクションはありません。この状態から、プライマリはIDENTIFYまたはTLSコマンドを送信できます。
Idle: In this state, the primary and the secondary have agreed on a protocol version, and the primary supplied an identifier to the secondary party to reconnect after a failure. There is no transaction associated with the connection in this state. Upon entry to this state, the party that initiated the connection becomes primary, and the other party becomes secondary. From this state, the primary can send any of the following commands: BEGIN, MULTIPLEX, PUSH, PULL, QUERY and RECONNECT.
アイドル：この状態では、プライマリとセカンダリはプロトコルバージョンについて合意しており、プライマリは障害後に再接続するために識別子をセカンダリパーティに提供しました。この状態の接続に関連付けられているトランザクションはありません。この状態になると、接続を開始した側がプライマリになり、もう一方の側がセカンダリになります。この状態から、プライマリは次のコマンドのいずれかを送信できます：BEGIN、MULTIPLEX、PUSH、PULL、QUERY、およびRECONNECT。
Begun: In this state, a connection is associated with an active transaction, which can only be completed by a one-phase protocol. A BEGUN response to a BEGIN command places a connection into this state. Failure of a connection in Begun state implies that the transaction will be aborted. From this state, the primary can send an ABORT, or COMMIT command.
開始：この状態では、接続はアクティブなトランザクションに関連付けられており、1フェーズのプロトコルでのみ完了できます。 BEGINコマンドに対するBEGUN応答は、接続をこの状態にします。開始状態での接続の失敗は、トランザクションが中止されることを意味します。この状態から、プライマリはABORTまたはCOMMITコマンドを送信できます。
Enlisted: In this state, the connection is associated with an active transaction, which can be completed by a one-phase or, two-phase protocol. A PUSHED response to a PUSH command, or a PULLED response to a PULL command, places the connection into this state. Failure of the connection in Enlisted state implies that the transaction will be aborted. From this state, the primary can send an ABORT, COMMIT, or PREPARE command.
参加：この状態では、接続はアクティブなトランザクションに関連付けられており、1フェーズまたは2フェーズのプロトコルで完了できます。 PUSHコマンドへのPUSHED応答、またはPULLコマンドへのPULLED応答は、接続をこの状態にします。参加状態での接続の失敗は、トランザクションが中止されることを意味します。この状態から、プライマリはABORT、COMMIT、またはPREPAREコマンドを送信できます。
Prepared: In this state, a connection is associated with a transaction that has been prepared. A PREPARED response to a PREPARE command, or a RECONNECTED response to a RECONNECT command places a connection into this state. Unlike other states, failure of a connection in this state does not cause the transaction to automatically abort. From this state, the primary can send an ABORT, or COMMIT command.
準備済み：この状態では、接続は準備済みのトランザクションに関連付けられています。 PREPAREコマンドへのPREPARED応答、またはRECONNECTコマンドへのRECONNECTED応答は、接続をこの状態にします。他の状態とは異なり、この状態で接続が失敗しても、トランザクションは自動的に中止されません。この状態から、プライマリはABORTまたはCOMMITコマンドを送信できます。
Multiplexing: In this state, the connection is being used by a multiplexing protocol, which provides its own set of connections. In this state, no TIP commands are possible on the connection. (Of course, TIP commands are possible on the connections supplied by the multiplexing protocol.) The connection can never leave this state.
多重化：この状態では、接続は独自の接続セットを提供する多重化プロトコルによって使用されています。この状態では、接続でTIPコマンドは使用できません。 （もちろん、TIPコマンドは、多重化プロトコルによって提供される接続で可能です。）接続がこの状態を離れることはありません。
Tls: In this state, the connection is being used by the TLS protocol, which provides its own secured connection. In this state, no TIP commands are possible on the connection. (Of course, TIP commands are possible on the connection supplied by the TLS protocol.) The connection can never leave this state.
Tls：この状態では、接続はTLSプロトコルによって使用されており、独自の保護された接続を提供します。この状態では、接続でTIPコマンドは使用できません。 （もちろん、TIPコマンドはTLSプロトコルによって提供される接続で可能です。）接続はこの状態を離れることはできません。
Error: In this state, a protocol error has occurred, and the connection is no longer useful. The connection can never leave this state.
エラー：この状態では、プロトコルエラーが発生し、接続は使用できなくなりました。接続がこの状態を離れることはありません。
This document describes version 3 of the protocol. In order to accommodate future versions, the primary party sends a message indicating the lowest and the highest version number it understands. The secondary responds with the highest version number it understands.
このドキュメントでは、プロトコルのバージョン3について説明します。将来のバージョンに対応するために、プライマリパーティは、理解できる最小および最大のバージョン番号を示すメッセージを送信します。セカンダリは、理解できる最大のバージョン番号で応答します。
After such an exchange, communication can occur using the smaller of the highest version numbers (i.e., the highest version number that both understand). This exchange is mandatory and occurs using the IDENTIFY command (and IDENTIFIED response).
このような交換の後、最も高いバージョン番号の小さい方（つまり、両方が理解できる最も高いバージョン番号）を使用して通信が行われます。この交換は必須であり、IDENTIFYコマンド（およびIDENTIFIED応答）を使用して行われます。
If the highest version supported by one party is considered obsolete and no longer supported by the other party, no useful communication can occur. In this case, the newer party should merely drop the connection.
一方のパーティでサポートされている最も高いバージョンが廃止され、もう一方のパーティでサポートされなくなった場合、有用な通信は行われません。この場合、新しいパーティは単に接続をドロップする必要があります。
All commands and responses consist of one line of ASCII text, using only octets with values in the range 32 through 126 inclusive, followed by either a CR (an octet with value 13) or an LR (an octet with value 10). Each line can be split up into one or more "words", where successive words are separated by one or more space octets (value 32).
すべてのコマンドと応答は、1行のASCIIテキストで構成され、32〜126の範囲の値を持つオクテットのみを使用し、その後にCR（値が13のオクテット）またはLR（値が10のオクテット）が続きます。各行は1つ以上の「単語」に分割でき、連続する単語は1つ以上のスペースオクテット（値32）で区切られます。
Arbitrary numbers of spaces at the beginning and/or end of each line are allowed, and ignored.
各行の先頭および/または末尾の任意の数のスペースが許可され、無視されます。
Lines that are empty, or consist entirely of spaces are ignored. (One implication of this is that you can terminate lines with both a CR and an LF if desired; the LF will be treated as terminating an empty line, and ignored.)
空の行、またはスペースのみで構成される行は無視されます。 （これが意味することの1つは、必要に応じてCRとLFの両方で行を終了できることです。LFは空行の終了として扱われ、無視されます。）
In all cases, the first word of each line indicates the type of command or response; all defined commands and responses consist of upper-case letters only.
すべての場合において、各行の最初の単語はコマンドまたは応答のタイプを示します。定義されているすべてのコマンドと応答は、大文字のみで構成されています。
For some commands and responses, subsequent words convey parameters for the command or response; each command and response takes a fixed number of parameters.
一部のコマンドと応答では、後続の単語がコマンドまたは応答のパラメーターを伝えます。各コマンドと応答は、固定数のパラメーターを取ります。
All words on a command or response line after (and including) the first undefined word are totally ignored. These can be used to pass human-readable information for debugging or other purposes.
最初の未定義の単語（およびそれを含む）の後のコマンドまたは応答行のすべての単語は完全に無視されます。これらは、人間が読める情報をデバッグまたはその他の目的で渡すために使用できます。
In order to reduce communication latency and improve efficiency, it is possible for multiple TIP "lines" (commands or responses) to be pipelined (concatenated) together and sent as a single message. Lines may also be sent "ahead" (by the secondary, for later procesing by the primary). Examples are an ABORT command immediately followed by a BEGIN command, or a COMMITTED response immediately followed by a PULL command.
通信の待ち時間を減らして効率を向上させるために、複数のTIP "行"（コマンドまたは応答）をパイプライン（連結）して、単一のメッセージとして送信することが可能です。回線を「先に」送信することもできます（セカンダリによって、後でプライマリによって処理されるため）。たとえば、ABORTコマンドの直後にBEGINコマンドが続く場合や、COMMITTED応答の直後にPULLコマンドが続く場合があります。
The sending of pipelined lines is an implementation option. Likewise which lines are pipelined together. Generally, it must be certain that the pipelined line will be valid for the state of the connection at the time it is processed by the receiver. It is the responsibility of the sender to determine this.
パイプラインの送信は実装オプションです。同様に、どのラインも一緒にパイプライン処理されます。一般に、パイプライン化されたラインは、レシーバーによって処理された時点の接続の状態に対して有効であることを確認する必要があります。これを決定するのは送信者の責任です。
All implementations must support the receipt of pipelined lines - the rules for processing of which are described by the following paragraph:
すべての実装は、パイプライン化されたラインの受信をサポートする必要があります。その処理ルールは、次の段落で説明されています。
When the connection state is such that a line should be read (either command or response), then that line (when received) is processed. No more lines are read from the connection until processing again reaches such a state. If a line is received on a connection when it is not the turn of the other party to send, that line is _not_ rejected. Instead, the line is held and processed when the connection state again requires it. The receiving party must process lines and issue responses in the order of lines received. If a line causes an error the connection enters the Error state, and all subsequent lines on the connection are discarded.
接続状態が行を読み取る必要がある（コマンドまたは応答のいずれか）場合、その行（受信時）が処理されます。処理が再びそのような状態になるまで、接続から読み取られる行はありません。送信する相手の番でないときに回線が接続で受信された場合、その回線は拒否されません。代わりに、接続状態で再び必要になったときに、回線は保留されて処理されます。受信側は、回線を処理し、受信した回線の順序で応答を発行する必要があります。回線によってエラーが発生した場合、接続はエラー状態になり、接続の後続の回線はすべて破棄されます。
Commands pertain either to connections or transactions. Commands which pertain to connections are: IDENTIFY, MULTIPLEX and TLS. Commands which pertain to transactions are: ABORT, BEGIN, COMMIT, PREPARE, PULL, PUSH, QUERY, and RECONNECT.
コマンドは、接続またはトランザクションに関係します。接続に関連するコマンドは、IDENTIFY、MULTIPLEX、TLSです。トランザクションに関連するコマンドは、ABORT、BEGIN、COMMIT、PREPARE、PULL、PUSH、QUERY、およびRECONNECTです。
Following is a list of all valid commands, and all possible responses to each:
以下は、すべての有効なコマンドと、それぞれに対する可能なすべての応答のリストです。
ABORT
中絶
This command is valid in the Begun, Enlisted, and Prepared states. It informs the secondary that the current transaction of the connection will abort. Possible responses are: ABORTED The transaction has aborted; the connection enters Idle state.
このコマンドは、Begun、Enlisted、およびPrepared状態で有効です。接続の現在のトランザクションが中止されることをセカンダリに通知します。可能な応答は次のとおりです。ABORTEDトランザクションは中止されました。接続はアイドル状態になります。
ERROR The command was issued in the wrong state, or was malformed. The connection enters the Error state.
ERRORコマンドが誤った状態で発行されたか、形式が正しくありませんでした。接続はエラー状態になります。
BEGIN
ベギン
This command is valid only in the Idle state. It asks the secondary to create a new transaction and associate it with the connection. The newly created transaction will be completed with a one-phase protocol. Possible responses are:
このコマンドは、アイドル状態でのみ有効です。セカンダリに新しいトランザクションを作成して接続に関連付けるように要求します。新しく作成されたトランザクションは、1フェーズのプロトコルで完了します。可能な応答は次のとおりです。
BEGUN <transaction identifier> A new transaction has been successfully begun, and that transaction is now the current transaction of the connection. The connection enters Begun state.
BEGUN <トランザクション識別子>新しいトランザクションが正常に開始され、そのトランザクションは現在、接続の現在のトランザクションです。接続が開始状態になります。
NOTBEGUN A new transaction could not be begun; the connection remains in Idle state.
NOTBEGUN新しいトランザクションを開始できませんでした。接続はアイドル状態のままです。
ERROR The command was issued in the wrong state, or was malformed. The connection enters the Error state.
ERRORコマンドが誤った状態で発行されたか、形式が正しくありませんでした。接続はエラー状態になります。
COMMIT
コミット
This command is valid in the Begun, Enlisted or Prepared states. In the Begun or Enlisted state, it asks the secondary to attempt to commit the transaction; in the Prepared state, it informs the secondary that the transaction has committed. Note that in the Enlisted state this command represents a one-phase protocol, and should only be done when the sender has 1) no local recoverable resources involved in the transaction, and 2) only one subordinate (the sender will not be involved in any transaction recovery process). Possible responses are:
このコマンドは、Begun、Enlisted、またはPrepared状態で有効です。開始または参加状態では、セカンダリにトランザクションのコミットを試行するように要求します。準備済み状態では、トランザクションがコミットしたことをセカンダリに通知します。 Enlisted状態では、このコマンドは1フェーズプロトコルを表し、送信者が1）トランザクションに関与するローカルの回復可能なリソースを持たない場合、および2）1つのみの下位（送信者はいずれにも関与しない）の場合にのみ実行する必要があります。トランザクション回復プロセス）。可能な応答は次のとおりです。
ABORTED This response is possible only from the Begun and Enlisted states. It indicates that some party has vetoed the commitment of the transaction, so it has been aborted instead of committing. The connection enters the Idle state.
ABORTEDこの応答は、Begun状態とEnlisted状態からのみ可能です。これは、一部の当事者がトランザクションのコミットメントに拒否権を行使したため、コミットするのではなく中止されたことを示しています。接続はアイドル状態になります。
COMMITTED This response indicates that the transaction has been committed, and that the primary no longer has any responsibilities to the secondary with respect to the transaction. The connection enters the Idle state.
COMMITTEDこの応答は、トランザクションがコミットされたこと、およびプライマリがトランザクションに関してセカンダリに責任を持たなくなったことを示します。接続はアイドル状態になります。
ERROR The command was issued in the wrong state, or was malformed. The connection enters the Error state.
ERRORコマンドが誤った状態で発行されたか、形式が正しくありませんでした。接続はエラー状態になります。
ERROR
エラー
This command is valid in any state; it informs the secondary that a previous response was not recognized or was badly formed. A secondary should not respond to this command. The connection enters Error state.
このコマンドはどの状態でも有効です。以前の応答が認識されなかったか、形式が正しくなかったことをセカンダリに通知します。セカンダリはこのコマンドに応答すべきではありません。接続はエラー状態になります。
IDENTIFY <lowest protocol version>
<highest protocol version>
<primary transaction manager address> | "-"
<secondary transaction manager address>
This command is valid only in the Initial state. The primary party informs the secondary party of: 1) the lowest and highest protocol version supported (all versions between the lowest and highest must be supported; 2) optionally, an identifier for the primary party at which the secondary party can re-establish a connection if ever needed (the primary transaction manager address); and 3) an identifier which may be used by intermediate proxy servers to connect to the required TIP transaction manager (the secondary transaction manager address). If a primary transaction manager address is not supplied, the secondary party will respond with ABORTED or READONLY to any PREPARE commands. Possible responses are:
このコマンドは、初期状態でのみ有効です。プライマリパーティはセカンダリパーティに次のことを通知します。1）サポートされる最低および最高のプロトコルバージョン（最低と最高の間のすべてのバージョンをサポートする必要があります。2）オプションで、セカンダリパーティが再確立できるプライマリパーティの識別子必要に応じて接続（プライマリトランザクションマネージャーアドレス）。および3）必要なTIPトランザクションマネージャー（セカンダリトランザクションマネージャーアドレス）に接続するために中間プロキシサーバーで使用される識別子。プライマリトランザクションマネージャのアドレスが指定されていない場合、セカンダリパーティはPREPAREコマンドに対してABORTEDまたはREADONLYで応答します。可能な応答は次のとおりです。
IDENTIFIED <protocol version> The secondary party has been successfully contacted and has saved the primary transaction manager address. The response contains the highest protocol version supported by the secondary party. All future communication is assumed to take place using the smaller of the protocol versions in the IDENTIFY command and the IDENTIFIED response. The connection enters the Idle state.
IDENTIFIED <プロトコルバージョン>セカンダリパーティに正常に接続し、プライマリトランザクションマネージャーのアドレスを保存しました。応答には、セカンダリパーティでサポートされている最高のプロトコルバージョンが含まれています。将来のすべての通信は、IDENTIFYコマンドとIDENTIFIED応答のプロトコルバージョンの小さい方を使用して行われると想定されています。接続はアイドル状態になります。
NEEDTLS The secondary party is only willing to communicate over TLS secured connections. The connection enters the Tls state, and all subsequent communication is as defined by the TLS protocol. This protocol will begin with the first octet after the line terminator of the IDENTIFY command (for data sent by the primary party), and the first byte after the line terminator of the NEEDTLS response (for data sent by the secondary party). This implies that an implementation must not send both a CR and a LF octet after either the IDENTIFY command or the NEEDTLS response, lest the LF octet be mistaken for the first byte of the TLS protocol. The connection provided by the TLS protocol starts out in the Initial state. After TLS has been negotiated, the primary party must resend the IDENTIFY command. If the primary party cannot support (or refuses to use) the TLS protocol, it closes the connection.
NEEDTLSセカンダリパーティは、TLSで保護された接続を介してのみ通信する意思があります。接続はTls状態になり、その後のすべての通信はTLSプロトコルで定義されたとおりになります。このプロトコルは、IDENTIFYコマンドのラインターミネータの後の最初のオクテット（プライマリパーティから送信されたデータの場合）から始まり、NEEDTLS応答のラインターミネータの後の最初のバイト（セカンダリパーティから送信されたデータの場合）から始まります。これは、LFオクテットがTLSプロトコルの最初のバイトと間違えられないように、実装はIDENTIFYコマンドまたはNEEDTLS応答の後にCRとLFオクテットの両方を送信してはならないことを意味します。 TLSプロトコルによって提供される接続は、初期状態で始まります。 TLSがネゴシエートされた後、プライマリパーティはIDENTIFYコマンドを再送信する必要があります。プライマリパーティがTLSプロトコルをサポートできない（または使用を拒否する）場合は、接続を閉じます。
ERROR The command was issued in the wrong state, or was malformed. This response also occurs if the secondary party does not support any version of the protocol in the range supported by the primary party. The connection enters the Error state. The primary party should close the connection.
ERRORコマンドが誤った状態で発行されたか、形式が正しくありませんでした。この応答は、セカンダリパーティがプライマリパーティでサポートされている範囲のプロトコルのバージョンをサポートしていない場合にも発生します。接続はエラー状態になります。プライマリパーティは接続を閉じる必要があります。
MULTIPLEX <protocol-identifier>
MULTIPLEX <プロトコル識別子>
This command is only valid in the Idle state. The command seeks agreement to use the connection for a multiplexing protocol that will supply a large number of connections on the existing connection. The primary suggests a particular multiplexing protocol. The secondary party can either accept or reject use of this protocol.
このコマンドは、アイドル状態でのみ有効です。このコマンドは、既存の接続に多数の接続を提供する多重化プロトコルの接続を使用することについての合意を求めます。プライマリは、特定の多重化プロトコルを示唆しています。セカンダリパーティは、このプロトコルの使用を許可または拒否できます。
At the present, the only defined protocol identifier is "TMP2.0", which refers to the TIP Multiplexing Protocol, version 2.0. See Appendix A for details of this protocol. Other protocol identifiers may be defined in the future.
現在、定義されている唯一のプロトコル識別子は「TMP2.0」で、これはTIP多重化プロトコル、バージョン2.0を指します。このプロトコルの詳細については、付録Aを参照してください。他のプロトコル識別子は将来定義されるかもしれません。
If the MULTIPLEX command is accepted, the specified multiplexing protocol will totally control the underlying connection. This protocol will begin with the first octet after the line terminator of the MULTIPLEX command (for data sent by the initiator), and the first byte after the line terminator of the MULTIPLEXING response (for data received by the initiator). This implies that an implementation must not send both a CR and a LF octet after either the MULTIPLEX command or the MULTIPLEXING response, lest the LF octet be mistaken for the first byte of the multiplexing protocol.
MULTIPLEXコマンドが受け入れられると、指定された多重化プロトコルが基礎となる接続を完全に制御します。このプロトコルは、MULTIPLEXコマンドのラインターミネーターの後の最初のオクテット（イニシエーターによって送信されたデータの場合）と、MULTIPLEXING応答のラインターミネーターの後の最初のバイト（イニシエーターによって受信されたデータの場合）から始まります。これは、実装がMULTIPLEXコマンドまたはMULTIPLEXING応答の後にCRとLFオクテットの両方を送信してはならないことを意味します。LFオクテットが多重化プロトコルの最初のバイトと間違えられないようにするためです。
Note that when using TMP V2.0, a single TIP command (TMP application message) must be wholly contained within a single TMP packet (the TMP PUSH flag is not used by TIP). Possible responses to the MULTIPLEX command are: MULTIPLEXING The secondary party agrees to use the specified multiplexing protocol. The connection enters the Multiplexing state, and all subsequent communication is as defined by that protocol. All connections created by the multiplexing protocol start out in the Idle state.
TMP V2.0を使用する場合、単一のTIPコマンド（TMPアプリケーションメッセージ）は、単一のTMPパケット内に完全に含まれている必要があることに注意してください（TMP PUSHフラグはTIPでは使用されません）。 MULTIPLEXコマンドに対する可能な応答は次のとおりです。MULTIPLEXING二次パーティは、指定された多重化プロトコルを使用することに同意します。接続は多重化状態になり、その後のすべての通信はそのプロトコルで定義されたとおりになります。多重化プロトコルによって作成されたすべての接続は、アイドル状態から始まります。
CANTMULTIPLEX The secondary party cannot support (or refuses to use) the specified multiplexing protocol. The connection remains in the Idle state.
CANTMULTIPLEXセカンダリパーティは、指定された多重化プロトコルをサポートできません（または使用を拒否します）。接続はアイドル状態のままです。
ERROR The command was issued in the wrong state, or was malformed. The connection enters the Error state.
ERRORコマンドが誤った状態で発行されたか、形式が正しくありませんでした。接続はエラー状態になります。
PREPARE
準備する
This command is valid only in the Enlisted state; it requests the secondary to prepare the transaction for commitment (phase one of two-phase commit). Possible responses are:
このコマンドはEnlisted状態でのみ有効です。コミットメントのためにトランザクションを準備するようにセカンダリに要求します（2フェーズコミットのフェーズ1）。可能な応答は次のとおりです。
PREPARED The subordinate has prepared the transaction; the connection enters PREPARED state.
PREPARED部下がトランザクションを準備しました。接続はPREPARED状態になります。
ABORTED The subordinate has vetoed committing the transaction. The connection enters the Idle state. After this response, the superior has no responsibilities to the subordinate with respect to the transaction.
ABORTED部下はトランザクションのコミットを拒否しました。接続はアイドル状態になります。この応答の後、上司は取引に関して部下に対して責任を負いません。
READONLY The subordinate no longer cares whether the transaction commits or aborts. The connection enters the Idle state. After this response, the superior has no responsibilities to the subordinate with respect to the transaction.
READONLY従属はトランザクションがコミットするか中止するかを気にしなくなりました。接続はアイドル状態になります。この応答の後、上司は取引に関して部下に対して責任を負いません。
ERROR The command was issued in the wrong state, or was malformed. The connection enters the Error state.
ERRORコマンドが誤った状態で発行されたか、形式が正しくありませんでした。接続はエラー状態になります。
PULL <superior's transaction identifier>
<subordinate's transaction identifier>
This command is only valid in Idle state. This command seeks to establish a superior/subordinate relationship in a transaction, with the primary party of the connection as the subordinate (i.e., he is pulling a transaction from the secondary party). Note that the entire value of <transaction string> (as defined in the section "TIP Uniform Resource Locators") must be specified as the transaction identifier. Possible responses are:
このコマンドは、アイドル状態でのみ有効です。このコマンドは、トランザクションの上位/下位関係を確立することを目的としており、接続のプライマリパーティを下位とします（つまり、セカンダリパーティからトランザクションをプルしています）。 （「TIP Uniform Resource Locators」のセクションで定義されている）<transaction string>の値全体をトランザクション識別子として指定する必要があることに注意してください。可能な応答は次のとおりです。
PULLED The relationship has been established. Upon receipt of this response, the specified transaction becomes the current transaction of the connection, and the connection enters Enlisted state. Additionally, the roles of primary and secondary become reversed. (That is, the superior becomes the primary for the connection.)
PULLED関係が確立されました。この応答を受信すると、指定されたトランザクションが接続の現在のトランザクションになり、接続は参加状態になります。さらに、プライマリとセカンダリの役割が逆になります。 （つまり、上司が接続のプライマリになります。）
NOTPULLED The relationship has not been established (possibly, because the secondary party no longer has the requested transaction). The connection remains in Idle state.
NOTPULLED関係が確立されていません（おそらく、二次パーティが要求されたトランザクションをもう持っていないため）。接続はアイドル状態のままです。
ERROR The command was issued in the wrong state, or was malformed. The connection enters the Error state.
ERRORコマンドが誤った状態で発行されたか、形式が正しくありませんでした。接続はエラー状態になります。
PUSH <superior's transaction identifier>
PUSH <上位のトランザクション識別子>
This command is valid only in the Idle state. It seeks to establish a superior/subordinate relationship in a transaction with the primary as the superior. Note that the entire value of <transaction string> (as defined in the section "TIP Uniform Resource Locators") must be specified as the transaction identifier. Possible responses are:
このコマンドは、アイドル状態でのみ有効です。プライマリーを上位としてトランザクションで上位/下位関係を確立しようとします。 （「TIP Uniform Resource Locators」のセクションで定義されている）<transaction string>の値全体をトランザクション識別子として指定する必要があることに注意してください。可能な応答は次のとおりです。
PUSHED <subordinate's transaction identifier> The relationship has been established, and the identifier by which the subordinate knows the transaction is returned. The transaction becomes the current transaction for the connection, and the connection enters Enlisted state.
PUSHED <部下のトランザクション識別子>関係が確立され、部下がトランザクションを知るための識別子が返されます。トランザクションは接続の現在のトランザクションになり、接続は参加状態になります。
ALREADYPUSHED <subordinate's transaction identifier> The relationship has been established, and the identifier by which the subordinate knows the transaction is returned. However, the subordinate already knows about the transaction, and is expecting the two-phase commit protocol to arrive via a different connection. In this case, the connection remains in the Idle state.
ALREADYPUSHED <部下のトランザクション識別子>関係が確立され、部下がトランザクションを知るための識別子が返されます。ただし、部下はトランザクションをすでに認識しており、2フェーズコミットプロトコルが別の接続を介して到着することを期待しています。この場合、接続はアイドル状態のままです。
NOTPUSHED The relationship could not be established. The connection remains in the Idle state.
NOTPUSHED関係を確立できませんでした。接続はアイドル状態のままです。
ERROR The command was issued in the wrong state, or was malformed. The connection enters Error state.
ERRORコマンドが誤った状態で発行されたか、形式が正しくありませんでした。接続はエラー状態になります。
QUERY <superior's transaction identifier>
QUERY <上位のトランザクション識別子>
This command is valid only in the Idle state. A subordinate uses this command to determine whether a specific transaction still exists at the superior. Possible responses are:
このコマンドは、アイドル状態でのみ有効です。部下はこのコマンドを使用して、特定のトランザクションが上司にまだ存在するかどうかを判断します。可能な応答は次のとおりです。
QUERIEDEXISTS The transaction still exists. The connection remains in the Idle state.
QUERIEDEXISTSトランザクションはまだ存在しています。接続はアイドル状態のままです。
QUERIEDNOTFOUND The transaction no longer exists. The connection remains in the Idle state.
QUERIEDNOTFOUNDトランザクションは存在しません。接続はアイドル状態のままです。
ERROR The command was issued in the wrong state, or was malformed. The connection enters Error state.
ERRORコマンドが誤った状態で発行されたか、形式が正しくありませんでした。接続はエラー状態になります。
RECONNECT <subordinate's transaction identifier>
RECONNECT <部下のトランザクション識別子>
This command is valid only in the Idle state. A superior uses the command to re-establish a connection for a transaction, when the previous connection was lost during Prepared state. Possible responses are:
このコマンドは、アイドル状態でのみ有効です。上司はコマンドを使用して、準備済み状態中に前の接続が失われたときに、トランザクションの接続を再確立します。可能な応答は次のとおりです。
RECONNECTED The subordinate accepts the reconnection. The connection enters Prepared state.
RECONNECTED部下は再接続を受け入れます。接続は準備済み状態になります。
NOTRECONNECTED The subordinate no longer knows about the transaction. The connection remains in Idle state.
NOTRECONNECTED部下はトランザクションを認識しなくなりました。接続はアイドル状態のままです。
ERROR The command was issued in the wrong state, or was malformed. The connection enters Error state.
ERRORコマンドが誤った状態で発行されたか、形式が正しくありませんでした。接続はエラー状態になります。
TLS
TLS
This command is valid only in the Initial state. A primary uses this command to attempt to establish a secured connection using TLS.
このコマンドは、初期状態でのみ有効です。プライマリはこのコマンドを使用して、TLSを使用した安全な接続の確立を試みます。
If the TLS command is accepted, the TLS protocol will totally control the underlying connection. This protocol will begin with the first octet after the line terminator of the TLS command (for data sent by the primary), and the first byte after the line terminator of the TLSING response (for data received by the primary). This implies that an implementation must not send both a CR and a LF octet after either the TLS command or the TLSING response, lest the LF octet be mistaken for the first byte of the TLS protocol.
TLSコマンドが受け入れられると、TLSプロトコルが基礎となる接続を完全に制御します。このプロトコルは、TLSコマンドのラインターミネータの後の最初のオクテット（プライマリによって送信されるデータの場合）から始まり、TLSING応答のラインターミネータの後の最初のバイト（プライマリによって受信されるデータの場合）から始まります。これは、LFオクテットがTLSプロトコルの最初のバイトと間違えられないように、実装はTLSコマンドまたはTLSING応答の後にCRとLFオクテットの両方を送信してはならないことを意味します。
Possible responses to the TLS command are:
TLSコマンドに対する可能な応答は次のとおりです。
TLSING The secondary party agrees to use the TLS protocol [3]. The connection enters the Tls state, and all subsequent communication is as defined by the TLS protocol. The connection provided by the TLS protocol starts out in the Initial state.
TLSINGセカンダリパーティはTLSプロトコルの使用に同意します[3]。接続はTls状態になり、その後のすべての通信はTLSプロトコルで定義されたとおりになります。 TLSプロトコルによって提供される接続は、初期状態で始まります。
CANTTLS The secondary party cannot support (or refuses to use) the TLS protocol. The connection remains in the Initial state.
CANTTLSセカンダリパーティはTLSプロトコルをサポートできません（または使用を拒否します）。接続は初期状態のままです。
ERROR The command was issued in the wrong state, or was malformed. The connection enters the Error state.
ERRORコマンドが誤った状態で発行されたか、形式が正しくありませんでした。接続はエラー状態になります。
If either party receives a line that it cannot understand it closes the connection. If either party (either a command or a response), receives an ERROR indication or an ERROR response on a connection the connection enters the Error state and no further communication is possible on that connection. An implementation may decide to close the connection. Closing of the connection is treated by the other party as a communication failure.
どちらかの当事者が理解できないラインを受け取る場合それは接続を閉じます。いずれかの当事者（コマンドまたは応答のいずれか）が、接続でERROR指示またはERROR応答を受信した場合、接続はエラー状態になり、その接続ではそれ以上通信できません。実装は接続を閉じることを決定するかもしれません。接続のクローズは、通信障害として他のパーティによって処理されます。
Receipt of an ERROR indication or an ERROR response indicates that the other party believes that you have not properly implemented the protocol.
ERROR表示またはERROR応答の受信は、プロトコルを適切に実装していないと相手が信じていることを示します。
A connection failure may be caused by a communication failure, or by any party closing the connection. It is assumed TIP implementations will use some private mechanism to detect TIP connection failure (e.g. socket keepalive, or a timeout scheme).
接続障害の原因としては、通信障害、または接続を閉じるパーティが考えられます。 TIP実装は、プライベートメカニズムを使用してTIP接続障害（ソケットキープアライブ、タイムアウトスキームなど）を検出すると想定されています。
Depending on the state of a connection, transaction managers will need to take various actions when a connection fails.
接続の状態に応じて、トランザクションマネージャは接続が失敗したときにさまざまなアクションを実行する必要があります。
If the connection fails in Initial or Idle state, the connection does not refer to a transaction. No action is necessary.
接続が初期状態またはアイドル状態で失敗した場合、接続はトランザクションを参照しません。アクションは必要ありません。
If the connection fails in the Multiplexing state, all connections provided by the multiplexing protocol are assumed to have failed. Each of them will be treated independently.
多重化状態で接続が失敗した場合、多重化プロトコルによって提供されるすべての接続が失敗したと見なされます。それらのそれぞれは独立して扱われます。
If the connection fails in Begun or Enlisted state and COMMIT has been sent, then transaction completion has been delegated to the subordinate (the superior is not involved); the outcome of the transaction is unknown by the superior (it is known at the subordinate). The superior uses application-specific means to determine the outcome of the transaction (note that transaction integrity is not compromised in this case since the superior has no recoverable resources involved in the transaction). If the connection fails in Begun or Enlisted state and COMMIT has not been sent, the transaction will be aborted.
BegunまたはEnlisted状態で接続が失敗し、COMMITが送信された場合、トランザクションの完了は下位に委任されています（上司は関与していません）。トランザクションの結果は、上司には分からない（それは部下で知られている）。上長は、アプリケーション固有の手段を使用してトランザクションの結果を決定します（この場合、上長はトランザクションに関与する回復可能なリソースを持たないため、トランザクションの整合性は損なわれません）。 BegunまたはEnlisted状態で接続が失敗し、COMMITが送信されていない場合、トランザクションは中止されます。
If the connection fails in Prepared state, then the appropriate action is different for the superior and subordinate in the transaction.
Prepared状態で接続が失敗した場合、適切なアクションはトランザクションの上位と下位で異なります。
If the superior determines that the transaction commits, then it must eventually establish a new connection to the subordinate, and send a RECONNECT command for the transaction. If it receives a NOTRECONNECTED response, it need do nothing else. However, if it receives a RECONNECTED response, it must send a COMMIT request and receive a COMMITTED response.
上司がトランザクションのコミットを決定した場合、上司は最終的に部下への新しい接続を確立し、トランザクションにRECONNECTコマンドを送信する必要があります。 NOTRECONNECTED応答を受信した場合は、他に何もする必要はありません。ただし、RECONNECTED応答を受信した場合は、COMMIT要求を送信し、COMMITTED応答を受信する必要があります。
If the superior determines that the transaction aborts, it is allowed to (but not required to) establish a new connection and send a RECONNECT command for the transaction. If it receives a RECONNECTED response, it should send an ABORT command.
上司がトランザクションが異常終了したと判断した場合、新しい接続を確立し、トランザクションにRECONNECTコマンドを送信することが許可されます（必須ではありません）。 RECONNECTED応答を受信した場合は、ABORTコマンドを送信する必要があります。
The above definition allows the superior to reestablish the connection before it knows the outcome of the transaction, if it finds that convenient. Having succeeded in a RECONNECT command, the connection is back in Prepared state, and the superior can send a COMMIT or ABORT command as appropriate when it knows the transaction outcome.
上記の定義により、上司は、トランザクションの結果がわかる前に接続を再確立できます。 RECONNECTコマンドが成功すると、接続はPrepared状態に戻り、上司はトランザクションの結果を知っているときにCOMMITまたはABORTコマンドを適切に送信できます。
Note that it is possible for a RECONNECT command to be received by the subordinate before it is aware that the previous connection has failed. In this case the subordinate treats the RECONNECT command as a failure indication and cleans-up any resources associated with the connection, and associates the transaction state with the new connection.
以前の接続が失敗したことを認識する前に、RECONNECTコマンドが部下によって受信される可能性があることに注意してください。この場合、部下はRECONNECTコマンドを失敗の指示として扱い、接続に関連付けられているすべてのリソースをクリーンアップして、トランザクション状態を新しい接続に関連付けます。
If a subordinate notices a connection failure in Prepared state, then it should periodically attempt to create a new connection to the superior and send a QUERY command for the transaction. It should continue doing this until one of the following two events occurs:
部下が準備状態で接続の失敗に気付いた場合、定期的に上司への新しい接続を作成し、トランザクションのQUERYコマンドを送信する必要があります。次の2つのイベントのいずれかが発生するまで、これを継続する必要があります。
1. It receives a QUERIEDNOTFOUND response from the superior. In this case, the subordinate should abort the transaction.
1. 上司からQUERIEDNOTFOUND応答を受け取ります。この場合、部下はトランザクションを中止する必要があります。
2. The superior, on some connection that it initiated, sends a RECONNECT command for the transaction to the subordinate. In this case, the subordinate can expect to learn the outcome of the transaction on this new connection. If this new connection should fail before the subordinate learns the outcome of the transaction, it should again start sending QUERY commands.
2. 上司は、開始したいくつかの接続で、トランザクションのRECONNECTコマンドを従属に送信します。この場合、部下は、この新しい接続でのトランザクションの結果を学習することを期待できます。部下がトランザクションの結果を知る前にこの新しい接続が失敗した場合、再度QUERYコマンドの送信を開始する必要があります。
Note that if a TIP system receives either a QUERY or a RECONNECT command, and for some reason is unable to satisfy the request (e.g. the necessary recovery information is not currently available), then the connection should be dropped.
TIPシステムがQUERYまたはRECONNECTコマンドを受信し、何らかの理由で要求を満たすことができない場合（たとえば、必要な回復情報が現在利用できない場合）は、接続をドロップする必要があることに注意してください。
This section is meant to inform application developers, transaction manager developers, and users of the security implications of TIP as described by this document. The discussion does not include definitive solutions to the issues described, though it does make some suggestions for reducing security risks.
このセクションは、アプリケーション開発者、トランザクションマネージャ開発者、およびユーザーに、このドキュメントで説明されているTIPのセキュリティへの影響を通知することを目的としています。ここでは、セキュリティリスクを軽減するためのいくつかの提案を行いますが、説明には、説明されている問題の確実な解決策は含まれていません。
As with all two phase-commit protocols, any security mechanisms applied to the application communication protocol are liable to be subverted unless corresponding mechanisms are applied to the commitment protocol. For example, any authentication between the parties using the application protocol must be supported by security of the TIP exchanges to at least the same level of certainty.
2つのフェーズコミットプロトコルすべてと同様に、アプリケーション通信プロトコルに適用されるセキュリティメカニズムは、対応するメカニズムがコミットメントプロトコルに適用されない限り、破壊される可能性があります。たとえば、アプリケーションプロトコルを使用するパーティ間の認証は、TIP交換のセキュリティによって少なくとも同じレベルの確実性でサポートされる必要があります。
TLS provides optional client-side authentication, optional server-side authentication, and optional packet encryption.
TLSは、オプションのクライアント側認証、オプションのサーバー側認証、およびオプションのパケット暗号化を提供します。
A TIP implementation may refuse to provide service unless TLS is being used. It may refuse to provide service if packet encryption is not being used. It may refuse to provide service unless the remote party has been authenticated (via TLS).
TIP実装は、TLSが使用されていない限り、サービスの提供を拒否する場合があります。パケット暗号化が使用されていない場合、サービスの提供を拒否することがあります。リモートパーティが（TLSを介して）認証されていない場合、サービスの提供を拒否することがあります。
A TIP implementation should be willing to be authenticated itself (via TLS). This is true regardless of whether the implementation is acting as a client or a server.
TIP実装は、それ自体が（TLSを介して）認証されることをいとわないはずです。これは、実装がクライアントとして機能しているかサーバーとして機能しているかに関係なく当てはまります。
Once a remote party has been authenticated, a TIP transaction manager may use that remote party's identity to decide what operations to allow.
リモートパーティが認証されると、TIPトランザクションマネージャはそのリモートパーティのIDを使用して、許可する操作を決定できます。
Whether TLS is to be used on a connection, and if so, how TLS is to be used, and what operations are to subsequently be allowed, is determined by the security policies of the connecting TIP transaction managers towards each other. How these security policies are defined, and how a TIP transaction manager learns of them is totally private to the implementation and beyond the scope of this document.
接続でTLSを使用するかどうか、使用する場合、TLSの使用方法、およびその後のどの操作を許可するかは、相互に接続するTIPトランザクションマネージャーのセキュリティポリシーによって決定されます。これらのセキュリティポリシーがどのように定義され、TIPトランザクションマネージャがそれらをどのように学習するかは、実装に対して完全にプライベートであり、このドキュメントの範囲を超えています。
Assume that a malicious user knows the identity of a transaction that is currently active in some transaction manager. If the malefactor opens a TIP connection to the transaction manager, sends a PULL command, then closes the connection, he can cause that transaction to be aborted. This results in a denial of service to the legitimate owner of the transaction.
悪意のあるユーザーが、トランザクションマネージャーで現在アクティブなトランザクションのIDを知っていると想定します。不正行為者がトランザクションマネージャへのTIP接続を開き、PULLコマンドを送信してから接続を閉じると、そのトランザクションは中止される可能性があります。これにより、トランザクションの正当な所有者にサービス拒否が発生します。
An implementation may avoid this attack by refusing PULL commands unless TLS is being used, the remote party has been authenticated, and the remote party is trusted.
実装では、TLSが使用され、リモートパーティが認証され、リモートパーティが信頼されている場合を除き、PULLコマンドを拒否することでこの攻撃を回避できます。
When the connection between two transaction managers is closed while a transaction is in the Prepared state, each transaction manager needs to remember information about the transaction until a connection can be re-established.
トランザクションがPrepared状態のときに2つのトランザクションマネージャ間の接続が閉じられると、各トランザクションマネージャは、接続が再確立されるまでトランザクションに関する情報を記憶する必要があります。
If a malicious user exploits this fact to repeatedly create transactions, get them into Prepared state and drop the connection, he may cause a transaction manager to suffer resource exhaustion, thus denying service to all legitimate users of that transaction manager.
悪意のあるユーザーがこの事実を悪用してトランザクションを繰り返し作成し、それらを準備済み状態にして接続をドロップすると、トランザクションマネージャーがリソースを使い果たし、そのトランザクションマネージャーのすべての正当なユーザーへのサービスが拒否される可能性があります。
An implementation may avoid this attack by refusing PUSH commands unless TLS is being used, the remote party has been authenticated, and the remote party is trusted.
実装では、TLSが使用され、リモートパーティが認証され、リモートパーティが信頼されている場合を除き、PUSHコマンドを拒否することでこの攻撃を回避できます。
If a subordinate transaction manager has lost its connection for a particular prepared transaction, a malicious user can initiate a TIP connection to the transaction manager, and send it a RECONNECT command followed by either a COMMIT or an ABORT command for the transaction. The malicious user could thus cause part of a transaction to be committed when it should have been aborted, or vice versa.
下位のトランザクションマネージャーが特定の準備されたトランザクションの接続を失った場合、悪意のあるユーザーがトランザクションマネージャーへのTIP接続を開始し、RECONNECTコマンドに続いてトランザクションのCOMMITまたはABORTコマンドを送信できます。したがって、悪意のあるユーザーは、トランザクションの一部を中止する必要があるときにトランザクションの一部をコミットしたり、その逆を行ったりする可能性があります。
An implementation may avoid this attack by recording the authenticated identity of its superior in a transaction, and by refusing RECONNECT commands unless TLS is being used and the authenticated identity of the remote party is the same as the identity of the original superior.
実装では、トランザクションで上司の認証済みIDを記録し、TLSが使用されており、リモートパーティの認証済みIDが元の上司のIDと同じでない限り、RECONNECTコマンドを拒否することで、この攻撃を回避できます。
If a malicious user can intercept traffic on a TIP connection, he may be able to deduce information useful in planning other attacks. For example, if comment fields include the product name and version number of a transaction manager, a malicious user might be able to use this information to determine what security bugs exist in the implementation.
悪意のあるユーザーがTIP接続でトラフィックを傍受できる場合、他の攻撃の計画に役立つ情報を推測できる可能性があります。たとえば、コメントフィールドにトランザクションマネージャーの製品名とバージョン番号が含まれている場合、悪意のあるユーザーがこの情報を使用して、実装に存在するセキュリティバグを特定できる可能性があります。
An implementation may avoid this attack by always using TLS to provide session encryption, and by not putting any personalizing information on the TLS/TLSING command/response pair.
実装は、常にTLSを使用してセッション暗号化を提供し、パーソナライズ情報をTLS / TLSINGコマンド/応答ペアに置かないことにより、この攻撃を回避することができます。
If a malicious user can intercept and alter traffic on a TIP connection, he can wreak havoc in a number of ways. For example, he could replace a COMMIT command with an ABORT command.
悪意のあるユーザーがTIP接続のトラフィックを傍受して変更できる場合、彼はさまざまな方法で大混乱をもたらすことができます。たとえば、COMMITコマンドをABORTコマンドに置き換えることができます。
An implementation may avoid this attack by always using TLS to provide session encryption and authentication of the remote party.
実装では、常にTLSを使用してセッションの暗号化とリモートパーティの認証を提供することにより、この攻撃を回避できます。
[1] Gray, J. and A. Reuter (1993), Transaction Processing: Concepts and Techniques. San Francisco, CA: Morgan Kaufmann Publishers. (ISBN 1-55860-190-2).
[1] グレイ、J。およびA.ロイター（1993）、トランザクション処理：概念と手法。カリフォルニア州サンフランシスコ：Morgan Kaufmann Publishers。 （ISBN 1-55860-190-2）。
[2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[2] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」、RFC 2068、1997年1月。
[3] Dierks, T., et. al., "The TLS Protocol Version 1.0", Work in Progress.
[3] Dierks、T.、et。その他、「TLSプロトコルバージョン1.0」、作業中。
[4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[4] Berners-Lee、T.、Masinter、L。、およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[5] Evans, K., Klein, J., and J. Lyon, "Transaction Internet Protocol - Requirements and Supplemental Information", RFC 2372, July 1998.
[5] Evans、K.、Klein、J。、およびJ. Lyon、「Transaction Internet Protocol-Requirements and Supplemental Information」、RFC 2372、1998年7月。
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6] Moats、R。、「URN構文」、RFC 2141、1997年5月。
[7] Faltstrom, P., et. al., "Namespace Identifier Requirements for URN Services", Work in Progress.
[7] Faltstrom、P。、他al。、「URNサービスの名前空間識別子の要件」、作業中。
[8] Berners-Lee, T., et. at., "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", Work in Progress.
[8] バーナーズ-リー、T。、等。 at。、「Uniform Resource Identifiers（URI）：Generic Syntax and Semantics」、Work in Progress。
[9] Leach, P., and R. Salz, "UUIDs and GUIDs", Work in Progress.
[9] Leach、P。、およびR. Salz、「UUIDおよびGUID」、作業中。
Jim Lyon Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399, USA
じｍ ょん みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ー６３９９、 うさ
Phone: +1 (206) 936 0867
Fax: +1 (206) 936 7329
EMail: JimLyon@Microsoft.Com
Keith Evans Tandem Computers, Inc. 5425 Stevens Creek Blvd Santa Clara, CA 95051-7200, USA
Keith Evans Tandem Computers、Inc. 5425 Stevens Creek Blvd Santa Clara、CA 95051-7200、USA
Phone: +1 (408) 285 5314
Fax: +1 (408) 285 5245
EMail: Keith.Evans@Tandem.Com
Johannes Klein Tandem Computers Inc. 10555 Ridgeview Court Cupertino, CA 95014-0789, USA
Johannes Klein Tandem Computers Inc. 10555 Ridgeview Court Cupertino、CA 95014-0789、USA
Phone: +1 (408) 285 0453
Fax: +1 (408) 285 9818
EMail: Johannes.Klein@Tandem.Com
Please send comments on this document to the authors at <JimLyon@Microsoft.Com>, <Keith.Evans@Tandem.Com>, <Johannes.Klein@Tandem.Com>, or to the TIP mailing list at <Tip@Lists.Tandem.Com>. You can subscribe to the TIP mailing list by sending mail to <Listserv@Lists.Tandem.Com> with the line "subscribe tip <full name>" somewhere in the body of the message.
このドキュメントに関するコメントは、<JimLyon@Microsoft.Com>、<Keith.Evans@Tandem.Com>、<Johannes.Klein@Tandem.Com>の作成者、または<Tip @ ListsのTIPメーリングリストに送信してください。 Tandem.Com>。メッセージ本文のどこかに「subscribe tip <full name>」という行を入れて<Listserv@Lists.Tandem.Com>にメールを送信することにより、TIPメーリングリストを購読できます。
Appendix A. The TIP Multiplexing Protocol Version 2.0.
付録A. TIP多重化プロトコルバージョン2.0。
This appendix describes version 2.0 of the TIP Multiplexing Protocol (TMP). TMP is intended solely for use with the TIP protocol, and forms part of the TIP protocol specification (although its implementation is optional). TMP V2.0 is the only multiplexing protocol supported by TIP V3.0.
この付録では、TIP多重化プロトコル（TMP）のバージョン2.0について説明します。 TMPはTIPプロトコルでの使用のみを目的としており、TIPプロトコル仕様の一部を形成します（その実装はオプションです）。 TMP V2.0は、TIP V3.0でサポートされる唯一の多重化プロトコルです。
Abstract
概要
TMP provides a simple mechanism for creating multiple lightweight connections over a single TCP connection. Several such lightweight connections can be active simultaneously. TMP provides a byte oriented service, but allows message boundaries to be marked.
TMPは、単一のTCP接続で複数の軽量接続を作成するためのシンプルなメカニズムを提供します。このような軽量接続のいくつかは、同時にアクティブにすることができます。 TMPはバイト指向のサービスを提供しますが、メッセージ境界をマークすることができます。
There are several protocols in widespread use on the Internet which create a single TCP connection for each transaction. Unfortunately, because these transactions are short lived, the cost of setting up and tearing down these TCP connections becomes significant, both in terms of resources used and in the delays associated with TCP's congestion control mechanisms.
インターネット上で広く使用されているプロトコルがいくつかあり、トランザクションごとに単一のTCP接続が作成されます。残念ながら、これらのトランザクションは存続期間が短いため、これらのTCP接続のセットアップと破棄にかかるコストは、使用されるリソースの点でも、TCPの輻輳制御メカニズムに関連する遅延の点でも、かなり高くなります。
The TIP Multiplexing Protocol (TMP) is a simple protocol running on top of TCP that can be used to create multiple lightweight connections over a single transport connection. TMP therefore provides for more efficient use of TCP connections. Data from several different TMP connections can be interleaved, and both message boundaries and end of stream markers can be provided.
TIP多重化プロトコル（TMP）は、TCP上で実行される単純なプロトコルで、単一のトランスポート接続を介して複数の軽量接続を作成するために使用できます。したがって、TMPはTCP接続のより効率的な使用を提供します。いくつかの異なるTMP接続からのデータをインターリーブでき、メッセージ境界とストリーム終了マーカーの両方を提供できます。
Because TMP runs on top of a reliable byte ordered transport service it can avoid most of the extra work TCP must go through in order to ensure reliability. For example, TMP connections do not need to be confirmed, so there is no need to wait for handshaking to complete before data can be sent.
TMPは信頼性の高いバイト順のトランスポートサービスの上で実行されるため、信頼性を確保するためにTCPが実行しなければならない余分な作業のほとんどを回避できます。たとえば、TMP接続は確認する必要がないため、データを送信する前にハンドシェイクが完了するのを待つ必要はありません。
Note: TMP is not intended as a generalized multiplexing protocol. If you are designing a different protocol that needs multiplexing, TMP may or may not be appropriate. Protocols with large messages can exceed the buffering capabilities of the receiver, and under certain conditions this can cause deadlock. TMP when used with TIP does not suffer from this problem since TIP is a request-response protocol, and all messages are short.
注：TMPは、一般化された多重化プロトコルとしては意図されていません。多重化が必要な別のプロトコルを設計している場合、TMPが適切な場合とそうでない場合があります。大きなメッセージを含むプロトコルは、レシーバーのバッファリング能力を超える可能性があり、特定の条件下では、これによりデッドロックが発生する可能性があります。 TIPは要求応答プロトコルであり、すべてのメッセージが短いため、TMPをTIPと併用してもこの問題は発生しません。
The basic protocol model is that of multiple lightweight connections operating over a reliable stream of bytes. The party which initiated the connection is referred to as the primary, and the party which accepted the connection is referred to as the secondary.
基本的なプロトコルモデルは、信頼性の高いバイトストリーム上で動作する複数の軽量接続のモデルです。接続を開始した側をプライマリと呼び、接続を受け入れた側をセカンダリと呼びます。
Connections may be unidirectional or bi-directional; each end of a bi-directional connection may be closed separately. Connections may be closed normally, or reset to indicate an abortive release. Aborting a connection closes both data streams.
接続は単方向でも双方向でもかまいません。双方向接続の両端は別々に閉じることができます。接続が正常に閉じられるか、リセットが中止されたことを示します。接続を中止すると、両方のデータストリームが閉じます。
Once a connection has been opened, applications can send messages over it, and signal the end of application level messages. Application messages are encapsulated in TMP packets and transferred over the byte stream. A single TIP command (TMP application message) must be wholly contained within a single TMP packet.
接続が開かれると、アプリケーションはその接続を介してメッセージを送信し、アプリケーションレベルのメッセージの終わりを通知できます。アプリケーションメッセージはTMPパケットにカプセル化され、バイトストリームを介して転送されます。単一のTIPコマンド（TMPアプリケーションメッセージ）は、単一のTMPパケット内に完全に含まれている必要があります。
A TMP packet consists of a 64 bit header followed by zero or more octets of data. The header contains three fields; a flag byte, the connection identifier, and the packet length. Both integers, the connection identifier and the packet length must be sent in network byte order.
TMPパケットは、64ビットのヘッダーと、それに続く0個以上のデータのオクテットで構成されます。ヘッダーには3つのフィールドがあります。フラグバイト、接続識別子、およびパケット長。接続識別子とパケット長の両方の整数は、ネットワークバイトオーダーで送信する必要があります。
FLAGS
+--------+--------+--------+--------+
|SFPR0000| Connection ID |
+--------+--------+--------+--------+
| | Length |
+--------+--------+--------+--------+
+-------+-----------+-----------------------------------------+
| Name | Mask | Description |
+-------+-----------+ ----------------------------------------+
| SYN | 1xxx|0000 | Open a new connection |
| FIN | x1xx|0000 | Close an existing connection |
| PUSH | xx1x|0000 | Mark application level message boundary |
| RESET | xxx1|0000 | Abort the connection |
+-------+-----------+-----------------------------------------+
Each TMP connection is identified by a 24 bit integer. TMP connections created by the party which initiated the underlying TCP connection must have even identifiers; those created by the other party must have odd identifiers.
各TMP接続は24ビット整数で識別されます。基礎となるTCP接続を開始したパーティによって作成されたTMP接続には、偶数の識別子が必要です。相手が作成したものは、奇数の識別子を持つ必要があります。
TMP connections can exist in several different states; Closed, OpenWrite, OpenSynRead, OpenSynReset, OpenReadWrite, CloseWrite, and CloseRead. A connection can change its state in response to receiving a packet with the SYN, FIN, or RESET bits set, or in response to an API call by the application. The available API calls are open, close, and abort.
TMP接続は、いくつかの異なる状態で存在する可能性があります。 Closed、OpenWrite、OpenSynRead、OpenSynReset、OpenReadWrite、CloseWrite、CloseRead。接続は、SYN、FIN、またはRESETビットが設定されたパケットの受信に応じて、またはアプリケーションによるAPI呼び出しに応じて、その状態を変更できます。使用可能なAPI呼び出しは、open、close、およびabortです。
The meaning of most states is obvious (e.g. OpenWrite means that a connection has been opened for writing). The meaning of the states OpenSynRead and OpenResetRead need more explanation.
ほとんどの状態の意味は明白です（たとえば、OpenWriteは、接続が書き込み用に開かれていることを意味します）。 OpenSynReadとOpenResetReadの状態の意味については、さらに説明が必要です。
In the OpenSynRead state a primary opened and immediately closed the output data stream of a connection, and is now waiting for a SYN response from the secondary to open the input data stream for reading.
OpenSynRead状態では、プライマリが接続の出力データストリームを開いてすぐに閉じ、現在、セカンダリからのSYN応答を待って、入力データストリームを開いて読み取ります。
In the OpenResetRead state a primary opened and immediately aborted a connection, and is now waiting for a SYN response from the secondary to finally close the connection.
OpenResetRead状態では、プライマリが開いてすぐに接続を中止し、セカンダリからのSYN応答を待って、最終的に接続を閉じます。
The state table shown below describes the actions and state transitions that occur in response to a given event. The events accepted by each state are listed in priority order with highest priority first. If multiple events are present in a message, those events matching the list are processed. If multiple events match, the event with the highest priority is accepted and processed first. Any remaining events are processed in the resultant successor state.
以下に示す状態表は、特定のイベントに応答して発生するアクションと状態遷移を示しています。各状態で受け入れられるイベントは、優先順位の高い順にリストされます。メッセージに複数のイベントが存在する場合、リストに一致するイベントが処理されます。複数のイベントが一致する場合、優先度が最も高いイベントが受け入れられ、最初に処理されます。残りのイベントはすべて、後続の状態で処理されます。
For example, if a TMP connection at the secondary is in the Closed state, and the secondary receives a packet containing a SYN event, a FIN event and an input data event (i.e. DATA-IN), the secondary first accepts the SYN event (because it is the only match in Closed state). The secondary accepts the connection, sends a SYN event and enters the ReadWrite state. The SYN event is removed from the list of pending events. The remaining events are FIN and DATA-IN. In the ReadWrite state the secondary reads the input data (i.e. the DATA-IN event is processed first because it has higher priority than the FIN event). Once the data has been read and the DATA-IN event has been removed from the list of pending events, the FIN event is processed and the secondary enters the CloseWrite state.
たとえば、セカンダリのTMP接続がClosed状態で、セカンダリがSYNイベント、FINイベント、および入力データイベント（つまり、DATA-IN）を含むパケットを受信した場合、セカンダリは最初にSYNイベント（クローズ状態での唯一の一致なので）。セカンダリは接続を受け入れ、SYNイベントを送信し、ReadWrite状態に入ります。 SYNイベントが保留中のイベントのリストから削除されます。残りのイベントはFINとDATA-INです。 ReadWrite状態では、セカンダリは入力データを読み取ります（つまり、FINイベントよりも優先度が高いため、DATA-INイベントが最初に処理されます）。データが読み取られ、DATA-INイベントが保留中のイベントのリストから削除されると、FINイベントが処理され、セカンダリがCloseWrite状態になります。
If the secondary receives a packet containing a SYN event, and is for some reason unable to accept the connection (e.g. insufficient resources), it should reject the request by sending a SYN event followed by a RESET event. Note that both events can be sent as part of the same TMP packet.
セカンダリがSYNイベントを含むパケットを受信し、何らかの理由で接続を受け入れることができない場合（リソースが不十分など）、セカンダリはSYNイベントに続いてRESETイベントを送信することでリクエストを拒否する必要があります。両方のイベントを同じTMPパケットの一部として送信できることに注意してください。
If either party receives a TMP packet that it does not understand, or an event in an incorrect state, it closes the TCP connection.
どちらかのパーティが理解できないTMPパケット、または誤った状態のイベントを受信した場合、TCP接続を閉じます。
+==============+=========+==========+==============+
| Entry State | Event | Action | Exit State |
+==============+=========+==========+==============+
| Closed | SYN | SYN | ReadWrite |
| | OPEN | SYN | OpenWrite |
+--------------+---------+----------+--------------+
| OpenWrite | SYN | Accept | ReadWrite |
| | WRITE | DATA-OUT | OpenWrite |
| | CLOSE | FIN | OpenSynRead |
| | ABORT | RESET | OpenSynReset |
+--------------+---------+----------+--------------+
| OpenSynRead | SYN | Accept | CloseRead |
+--------------+---------+----------+--------------+
| OpenSynReset | SYN | Accept | Closed |
+--------------+---------+----------+--------------+
| ReadWrite | DATA-IN | Accept | ReadWrite |
| | FIN | Accept | CloseWrite |
| | RESET | Accept | Closed |
| | WRITE | DATA-OUT | ReadWrite |
| | CLOSE | FIN | CloseRead |
| | ABORT | RESET | Closed |
+--------------+---------+----------+--------------+
| CloseWrite | RESET | Accept | Closed |
| | WRITE | DATA-OUT | CloseWrite |
| | CLOSE | FIN | Closed |
| | ABORT | RESET | Closed |
+--------------+---------+----------+--------------+
| CloseRead | DATA-IN | Accept | CloseRead |
| | FIN | Accept | Closed |
| | RESET | Accept | Closed |
| | ABORT | RESET | Closed |
+--------------+---------+----------+--------------+
TMP Event Priorities and State Transitions
TMPイベントの優先順位と状態遷移
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。