1.7.3 Capability Negotiation Mechanisms

This protocol uses the following capability negotiation mechanisms for each of the versioning mechanisms discussed previously.

  • Protocol Version numbers as versioning mechanism

    • Support for certain connection types is optional for a specific protocol version. A connection initiator can determine whether the acceptor supports these connection types by sending the first message for the connection and determining the acceptor's level of support from the response. If the acceptor rejects the connection with a MTAG_CONNECTION_REQ_DENIED as specified in [MS-CMP] section 2.2.5, the connection type is not supported.

    • Support for a message type is never optional for a specific connection type, with one exception: TXUSER_RESOLVE_MTAG_ACCESSDENIED (section 2.2.8.3.2.1). However, there is no negotiation process to determine support for this message, and the message is sent by a sender that supports it in all cases.

    • Some specific data fields inside certain message types were added in specific protocol versions as additional data fields that appear after the fields that are defined by previous protocol versions. The receivers examine the size of the incoming MESSAGE_PACKET (section 2.2.4.1) structure to determine which additional data fields, if any, were included in the message by the sender.

  • Structures with fields containing version numbers as a versioning mechanism

    The structures using version numbers as a versioning mechanism do not have any optional elements for a particular version. Therefore, there are no capability negotiation mechanisms associated with them.

  • Structures with a field containing a value that identifies the structure format as a versioning mechanism

    In this case, the format of the structure is completely determined by the respective format-specifying field. There are no capability negotiation mechanisms associated with these structures.