1.1 Glossary

This document uses the following terms:

Augmented Backus-Naur Form (ABNF): A modified version of Backus-Naur Form (BNF), commonly used by Internet specifications. ABNF notation balances compactness and simplicity with reasonable representational power. ABNF differs from standard BNF in its definitions and uses of naming rules, repetition, alternatives, order-independence, and value ranges. For more information, see [RFC5234].

computer name: The DNS or NetBIOS name.

core transaction manager facet: The facet that acts as the internal coordinator of each transaction that is inside the transaction manager. The core transaction manager facet communicates with other facets in its transaction manager to ensure that each transaction is processed correctly. To accomplish this, the core transaction manager facet maintains critical transaction state, in both volatile memory and in a durable store, such as in a log file.

facet: In OleTx, a subsystem in a transaction manager that maintains its own per-transaction state and responds to intra-transaction manager events from other facets. A facet can also be responsible for communicating with other participants of a transaction.

globally unique identifier (GUID): A term used interchangeably with universally unique identifier (UUID) in Microsoft protocol technical documents (TDs). Interchanging the usage of these terms does not imply or require a specific algorithm or mechanism to generate the value. Specifically, the use of this term does not imply or require that the algorithms described in [RFC4122] or [C706] must be used for generating the GUID. See also universally unique identifier (UUID).

higher-layer business logic: The application functionality that invokes the functionality that is specific to this protocol.

IPv4 address in string format: A string representation of an IPv4 address in dotted-decimal notation, as described in [RFC1123] section 2.1.

OleTx transaction manager (OleTx TM): A transaction manager that implements the OleTx Transaction Protocol [MS-DTCO].

partner transaction manager: A transaction manager that plays the opposite role in an enlistment. When the TIP subordinate transaction manager facet is communicating with the partner transaction manager, the partner transaction manager acts as a superior transaction manager. When the TIP superior transaction manager facet is communicating with the partner transaction manager, the partner transaction manager acts as a subordinate transaction manager. The TIP transaction manager communicating with an application facet does not communicate with a partner transaction manager.

signal: In OleTx, the act of communicating an event between facets inside a transaction manager.

single-phase commit: An optimization of the Two-Phase Commit Protocol in which a transaction manager delegates the right to decide the outcome of a transaction to its only subordinate participant. This optimization can result in an In Doubt outcome.

superior transaction manager: A role taken by a transaction manager that is responsible for gathering outcome votes and providing the final transaction outcome. A root transaction manager can act as a superior transaction manager to a number of subordinate transaction managers. A transaction manager can act as both a subordinate transaction manager and a superior transaction manager on the same transaction.

TIP: An acronym for the Transaction Internet Protocol, which is specified in [RFC2371] section 13.

tip command: A TIP request or reply, including action and parameters, as specified in [RFC2371] section 13.

TIP command line: That part of a TIP message that contains a single TIP command. This is specified in the TIP standard [RFC2371] section 11 as a "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)."

tip connection: A TIP connection that is initiated and used, as specified in [RFC2371] section 4.

TIP subordinate transaction manager: A subordinate transaction manager that implements the transaction management functionality that is specified in TIP.

TIP subordinate transaction manager facet: The facet that accepts requests to push a transaction from the partner transaction manager, sends requests to pull a transaction from the partner transaction manager, and participates as a subordinate in the Two-Phase Commit protocol.

TIP superior transaction manager: A superior transaction manager that implements the transaction management functionality that is specified in TIP.

TIP superior transaction manager facet: The facet that accepts requests to pull a transaction from the partner transaction manager, sends requests to push a transaction to the partner transaction manager, drives the Two-Phase Commit protocol with the partner transaction manager, and after a failure, performs recovery.

tip transaction manager: A transaction manager for the transaction management functionality specified in TIP.

TIP transaction manager communicating with an application facet: The facet that accepts requests to create and complete a transaction from an application.

TIP transaction manager facets: The facets that constitute the transaction manager role, namely the TIP superior transaction manager facet, the TIP subordinate transaction manager facet, and the TIP transaction manager communicating with an application facet.

transaction: In OleTx, an atomic transaction.

transaction manager: The party that is responsible for managing and distributing the outcome of atomic transactions. A transaction manager is either a root transaction manager or a subordinate transaction manager for a specified transaction.

Transport Layer Security (TLS): A security protocol that supports confidentiality and integrity of messages in client and server applications communicating over open networks. TLS supports server and, optionally, client authentication by using X.509 certificates (as specified in [X509]). TLS is standardized in the IETF TLS working group.

two-phase commit: An agreement protocol that is used to resolve the outcome of an atomic transaction in response to a commit request from the root application. Phase One and Phase Two are the distinct phases of the Two-Phase Commit Protocol.

MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as defined in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT.