rfc2371.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   The <path> component of the transaction manager address contains data
   identifying the specific TIP transaction manager, at the location
   defined by <hostport>.

   The <path> component takes the form:

     "/" [path_segments]

     path_segments = segment *( "/" segment )
     segment = *pchar *( ";" param )
     param = *pchar

     pchar = unreserved | escaped | ":" | "@" | "&" | "=" | "+"
     unreserved = ASCII character octets with values in the range



Lyon, et. al.               Standards Track                     [Page 6]

RFC 2371                    TIP Version 3.0                    July 1998


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

   [It is intended that the form of the transaction manager address
   follow the proposed scheme for Uniform Resource Identifiers (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.

   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.

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






Lyon, et. al.               Standards Track                     [Page 7]

RFC 2371                    TIP Version 3.0                    July 1998


   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.

8. TIP Uniform Resource Locators

   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.

   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.

   A TIP URL takes the form:

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

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




Lyon, et. al.               Standards Track                     [Page 8]

RFC 2371                    TIP Version 3.0                    July 1998


     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.

       tip://123.123.123.123/?urn:xopen:xid

     Note that Namespace Ids require registration. See [7] for details
     on how to do this.

   ii. <transaction identifier>

     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.

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

   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.

   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



Lyon, et. al.               Standards Track                     [Page 9]

RFC 2371                    TIP Version 3.0                    July 1998


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

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

   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.

   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.

   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



Lyon, et. al.               Standards Track                    [Page 10]

RFC 2371                    TIP Version 3.0                    July 1998


     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. From this state, the primary can send an
     ABORT, or COMMIT command.

   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.

   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.

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







Lyon, et. al.               Standards Track                    [Page 11]

RFC 2371                    TIP Version 3.0                    July 1998


10. Protocol Versioning

   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.

   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