[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 rfc2371                               
Network Working Group                                            J. Lyon
Internet-Draft                                                 Microsoft
Obsoletes <draft-lyon-itp-nodes-00.txt>                         K. Evans
Expires in 6 month                                              J. Klein
                                                        Tandem Computers
                                                      February 7th, 1997

                     Transaction Internet Protocol

                     <draft-lyon-itp-nodes.01.txt>

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited. Please send comments to
   the authors at <JimLyon@Microsoft.Com>, <Evans_Keith@Tandem.Com>,
   <Klein_Johannes@Tandem.Com>, or to the TIP mailing list at
   <tip@Tandem.Com>. You can subscribe to the TIP mailing list by
   sending mail to <listserv@Tandem.Com> with the line "subscribe tip"
   somewhere in the body of the message.


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.


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,

Lyon                                                           [Page 1]


Internet-Draft      Transaction Internet Protocol     February 7th, 1997

   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 Secure Socket Layer
   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.


Example Usage

   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.

   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.


Lyon                                                           [Page 2]


Internet-Draft      Transaction Internet Protocol     February 7th, 1997

   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 acknowledgement. If the transaction aborts no orders will
   be placed and the customer will be informed of the problem.

   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. RPC). The protocol makes it easy for
   applications in a heterogeneous network to participate in the same
   transaction, even if using different communication protocols.


Transactions

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


Connections

   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 a protocol to
   multiplex light-weight connections over the same TCP connection.
   While the TIP protocol is described in the context of TCP/IP, other
   reliable ordered stream transports may be used to replace TCP/IP.

   Transaction managers which share transactions establish a TCP
   connection. The protocol uses a different connection for each
   simultaneous transaction shared between two transaction managers.
   After a transaction has ended, the connection can be reused for
   a different transaction.

Lyon                                                           [Page 3]


Internet-Draft      Transaction Internet Protocol     February 7th, 1997


   Optionally, instead of associating a TCP connection with only a
   single transaction, two transaction managers may agree on a protocol
   to multiplex light-weight connections over the same TCP 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 [3] for an example
   of one such protocol.


Transaction Identifiers

   Unfortunately, there is no globally-accepted standard for the format
   of a transaction identifier; various transaction managers have their
   own proprietary formats.  Therefore, for the purposes of this
   protocol, a transaction identifier is any sequence of printable
   ASCII characters (octets with values in the range 33 through 126,
   inclusive). A transaction manager may map its internal transaction
   identifiers into this printable sequence 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.


Pushing vs. Pulling Transactions

   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.

   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.

   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.


Lyon                                                           [Page 4]


Internet-Draft      Transaction Internet Protocol     February 7th, 1997

   The protocol described here supports both the "push" and "pull"
   models.


Endpoint Identification

   In certain cases after connection failures, one of the parties of
   a connection may have a responsibility to re-establish a new
   connection to the other party in order to complete the
   two-phase-commit protocol. If the party that initiated the original
   connection needs to re-establish it, the job is easy: he merely
   establishes a connection in the same way that he originally did it.
   However, if the other party needs to re-establish the connection,
   he needs to know how to contact the initiator of the original
   connection. He gets this information in the following way:

   After a TCP connection has been established the initiating party
   issues an IDENTIFY command and supplies an endpoint identifier which
   is used to re-establish the connection if needed. If the initiating
   party does not supply an endpoint identifier on the IDENTIFY command,
   he must not perform any action which would require a
   connection to be re-established (e.g. perform recovery actions).

   An <endpoint identifier> as used in the IDENTIFY (and a few other)
   commands has one of the following formats:
      <dns name>
      <ip address>
      <dns name>:<port number>
      <ip address>:<port number>

   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.

   An <ip address> is an IPv4 or IPv6 address, in the usual form: four
|  (or six??) decimal numbers separated by period characters.

   The <port number> is a decimal number specifying the port at which
   the transaction manager is listening for requests to establish TCP
   connections.  If the port number is omitted from the endpoint
   identifier, the standard transaction service port number is assumed.


TIP Uniform Resource Locators

   Transactions and transaction managers are resources associated
   with the TIP protocol. Transaction managers and transactions are
   located using TCP/IP endpoint identifiers. Once a TCP connection has
   been established, TIP commands may be sent to operate on transactions
   associated with the respective transaction managers.

   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

Lyon                                                           [Page 5]


Internet-Draft      Transaction Internet Protocol     February 7th, 1997

   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 (i.e. TIP URLs) to
   transaction managers and transactions.

   An TIP URL takes the form:

      TIP://<host>[:<port>]/<transaction identifier>

   where <host> is an IP address or a DNS name as defined above,
   <port> is a valid TCP port number, and <transaction identifier>
   is a sequence of printable characters representing a transaction
   identifier as defined above. The TIP scheme follows the rules for
   reserved characters as defined in [4], and uses escape sequences
   as defined in [4] Section 5.

   Note that the TIP protocol itself does not use the TIP URL scheme.
   This URL scheme is proposed as a standard way to pass transaction
   identification information through other protocols. e.g. between
   cooperating application processes. The 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.

   To create a URL from a transaction identifier, first replace any
   reserved characters in the transaction identifier with their
   equivalent escape sequences, then insert the appropriate host
   endpoint identification. If the transaction identifier is one that
   you created, insert your own endpoint identification. If the
   transaction identifier is one that you received on a TIP connection
   that you initiated, insert the identification of the party to which
   you connected. If the transaction identifier is one that you
   received on a TIP connection that you did not initiate, use the
   identification that was received in the IDENTIFY command.


States of a connection

   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.

Lyon                                                           [Page 6]


Internet-Draft      Transaction Internet Protocol     February 7th, 1997


   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 the IDENTIFY command.

   Idle: In this state, the primary and the secondary have
      agreed on a protocol version, and the primary supplied an
      endpoint 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.


   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.

   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.

   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.

   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.

   Error: In this state, a protocol error has occurred, and the
      connection is no longer useful.

Lyon                                                           [Page 7]


Internet-Draft      Transaction Internet Protocol     February 7th, 1997



Protocol Versioning

   This document describes version 2 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.

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

   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.


Commands and Responses

   All commands and responses consist of one line of ASCII text, using
   only octets with values in the range 32 through 127 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 each word is successive words are separated by one or more
   space octets (value 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.)

   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 the last defined word
   are totally ignored.  These can be used to pass human-readable
   information for debugging or other purposes.


Command Pipelining

   The primary party of a connection is allowed to issue multiple

Lyon                                                           [Page 9]


Internet-Draft      Transaction Internet Protocol     February 7th, 1997

   commands without having to wait for responses. This reduces
   latency and allows the primary to react immediately to local state
   changes. Examples are a PREPARE command immediately followed by
   an ABORT command after the primary detected that a transaction must
   be aborted, or an IDENTIFY command immediately followed by a BEGIN,
   PUSH, or PULL command. The secondary must issue replies in the
   order of the commands received. If a command causes an error the
   connection enters the Error state and all subsequent commands on
   the connection are discarded.


Commands

   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, and the initiator of the connection becomes primary.

      ERROR
         The command was issued in the wrong state, or was malformed.
         The connection enters the Error state.

   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:

      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.

      NOTBEGUN
         A new transaction could not be begun; the connection
         remains in Idle state.

      ERROR
         The command was issued in the wrong state, or was malformed.
         The connection enters the Error state.

   COMMIT

      This command is valid in the Begun, Enlisted or Prepared states.
      In the Begun or Enlisted state, it asks the secondary to attempt

Lyon                                                           [Page 10]


Internet-Draft      Transaction Internet Protocol     February 7th, 1997

      to commit the transaction; in the Prepared state, it informs the
      secondary that the transaction has committed.
      Possible responses are:

      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.

      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.

      ERROR
         The command was issued in the wrong state, or was malformed.
         The connection enters the Error state.

   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>
            <initiating party's endpoint identifier> | "-"

      This command is valid only in the Initial state. The primary party
      informs the secondary party of the lowest and highest protocol
      version supported, and optionally of an IP address and a port
      number at which the other party can re-establish a connection
      if ever needed. If the primary party does not supply an endpoint
      identifier the secondary party will respond with ABORTED or
      READONLY to any PREPARE commands. Possible responses are:

      IDENTIFIED <protocol version>
         The accepting party has saved the identification. 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.

      ERROR
         The command was issued in the wrong state, or was malformed.
         This response also occurs if the accepting party does not
         support any version of the protocol in the range supported
         by the initiator.
         The connection enters the Error state. The initiator should
         close the connection.

Lyon                                                           [Page 11]


Internet-Draft      Transaction Internet Protocol     February 7th, 1997


    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:

      PREPARED
         The subordinate has prepared the transaction; the connection
         enters PREPARED state.

      ABORTED
         The subordinate has vetoed committing the transaction. The
         connection enters the Idle state, and the connection
         initiator becomes primary.  After this response, the
         superior has no responsibilities to the subordinate with
         respect to the
         transaction.

      READONLY
         The subordinate no longer cares whether the transaction
         commits or aborts. The connection enters the Idle state, and
         the connection initiator becomes primary.  After this
         response, the superior has no responsibilities to the
         subordinate with respect to the transaction.

      ERROR
         The command was issued in the wrong state, or was malformed.
         The connection enters the Error state.

   MULTIPLEX  <protocol>

      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 "SCP1.1",
      which refers to the Session Control Protocol, version 1.1, without
      header compression. See [5] for details on this protocol.
      Other protocol identifiers may be defined in the future.

      If the MULTIPLEX command is accepted, the specified multiplexing
      protocol will totally control the underlying connection. This
      protocol will begin with the first byte 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.

Lyon                                                           [Page 12]


Internet-Draft      Transaction Internet Protocol     February 7th, 1997


      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.

      CANTMULTIPLEX
         The secondary party cannot support (or refuses to use) the
         specified multiplexing protocol. The connection remains in the
         Idle state.

      ERROR
         The command was issued in the wrong state, or was malformed.
         The connection enters the Error state.

   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). Possible responses are:

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

      NOTPULLED
         The relationship has not been established (possibly, because
         the secondary party no longer has the requested transaction).
         The connection remains in Idle state.

      ERROR
         The command was issued in the wrong state, or was malformed.
         The connection enters the Error state.

   PUSH <superior's transaction identifier>

      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.
      Possible responses are:

      PUSHED <subordinate's transaction identifier>
         The relationship has been established, and identifier by which

Lyon                                                           [Page 13]


Internet-Draft      Transaction Internet Protocol     February 7th, 1997

         the subordinate knows the transaction is returned.  The
         transaction becomes current for the connection, and the
         connection enters Enlisted state.

      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.

      NOTPUSHED
         The relationship could not be established. The connection
         remains in the Idle state.

      ERROR
         The command was issued in the wrong state, or was malformed.
         The connection enters Error state.

   QUERY <superior's transaction identifier>

      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 the Idle state.

      QUERIEDNOTFOUND
         The transaction no longer exists.  The connection
         remains the Idle state.

      ERROR
         The command was issued in the wrong state, or was malformed.
         The connection enters Error state.

   RECONNECT <subordinate's transaction identifier>

      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.

      NOTRECONNECTED
         The subordinate no longer knows about the transaction. The
         connection remains in Idle state.

      ERROR

Lyon                                                           [Page 14]


Internet-Draft      Transaction Internet Protocol     February 7th, 1997

         The command was issued in the wrong state, or was malformed.
         The connection enters Error state.


Error Handling

   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.

   Receipt of an ERROR indication or an ERROR response indicates that
   the other party believes that you have not properly implemented the
   protocol.


Connection Failure

   A connection fails when being closed. This may be caused by a
   communication failure, or by any party closing the connection.
   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, each party will
   abort the transaction.

   If the connection fails in Prepared state, then the appropriate
   action is different for the superior and subordinate in the
   transaction.

   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.

   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.

   The above definition allows the superior to reestablish the

Lyon                                                           [Page 15]


Internet-Draft      Transaction Internet Protocol     February 7th, 1997

   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.

   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:

   1. It receives a QUERIEDNOTFOUND response from the superior. In this
      case, the subordinate should abort the transaction.

   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.


References

   [1]  Gray, J. and A. Reuter (1993), Transaction Processing: Concepts
        and Techniques.  San Francisco, CA: Morgan Kaufmann Publishers.
        ISBN 1-55860-190-2.

   [2]  RFC1945 Informational "Hypertext Transfer Protocol -- HTTP/1.0"
        T. Berners-Lee, R. Fielding, and H. Frystyk, May 1997.

   [3]  Internet Draft "The SSL Protocol Version 3.0"
        A. Freier, P. Karlton, P. Kocher.

   [4]  RFC1738 Standards Track "Uniform Resource Locaters (URL)"
        T. Berners-Lee, L. Masinter, M. McCahill

   [5]  "SCP - Session Control Protocol V 1.1"
        http://sunsite.unc.edu/ses/scp.html
        S. Spiro


Security Considerations

   If a system implements this protocol, it is in essence allowing any
   other system to attempt to reach an atomic agreement about some piece
   of work.  However, since this protocol itself does not cause the work
   to occur, the security implications are minimal. If a system does not
   protect itself through usage of another protocol such as the Secure
   Socket Layer protocol security implications fall into the following
   two categories:

   1. Someone PUSHED a new transaction to us that we don't want.
      Depending on his correctness or intentions, he may or may not ever

Lyon                                                           [Page 16]


Internet-Draft      Transaction Internet Protocol     February 7th, 1997

      complete it. Thus, an arbitrary computer may cause us to save a
      little bit of state. An implementation concerned about this will
      probably drop the TCP connection if the other system does not
      complete transactions in a timely manner.

      The Secure Socket Layer protocol [3] may be used by a transaction
      manager to restrict access to trusted clients only.

   2. Someone PULLED a transaction from us when we didn't want him to.
      In this case, he will become involved in the atomic commitment
      protocol. At worst, he may cause a transaction to abort that
      otherwise would have committed.  Since transaction managers
      traditionally reserve the right to abort any transaction for any
      reason they see fit, this does not represent a disaster to the
      applications. However, if done frequently, it may represent a
      denial-of-service attack.

      Implementations concerned about this kind of attack can use the
      Secure Socket Layer protocol [3] to restrict access to trusted
      clients and encrypt messages thus preventing unauthorized
     disclosure of transaction identifiers.


Changes from version 0 of this Internet-Draft:

   The IDENTIFY command is now mandatory, and its format has
   slightly changed.
   The PUSHTO and PULLFROM commands have been deleted.
   The MULTIPLEX command has been added.
   The TIP URL scheme has been added.
   Pipelining of commands is now permitted.
   The version of the protocol is now 2.


Authors' Addresses

   Jim Lyon                           Keith Evans
   Microsoft Corporation              Tandem Computers, Inc.
   One Microsoft Way                  5425 Stevens Creek Blvd
   Redmond, WA  98052-6399, USA       Santa Clara, CA 95051-7200, USA

   Phone: +1 (206) 936 0867           Phone: +1 (408) 285 5314
   Fax:   +1 (206) 936 7329           Fax:   +1 (408) 285 5245
   Email: JimLyon@Microsoft.Com       Email: Evans_Keith@Tandem.Com


   Johannes Klein
   Tandem Computers Inc.
   10555 Ridgeview Court
   Cupertino, CA 95014-0789, USA

   Phone: +1 (408) 285 0453
   Fax:   +1 (408) 285 9818
   Email: Klein_Johannes@Tandem.Com

Lyon                                                           [Page 17]