RFC 2371 (rfc2371) - Page 2 of 31

Transaction Internet Protocol Version 3

RFC 2371                    TIP Version 3.0                    July 1998


 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. Introduction

   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.

   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.

   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.

   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.

   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].





Lyon, et. al.               Standards Track