Transaction Internet Protocol Version 3.0
RFC 2371

Document Type RFC - Proposed Standard (July 1998; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2371 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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

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.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.


   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

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

Lyon, et. al.               Standards Track                     [Page 1]
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
Show full document text