Share via

1.7 Versioning and Capability Negotiation

  • Article

  • Supported Transports: These RPC extensions can be implemented on top of various RPC transports, as specified in section 2.1. Higher-level protocols on the client either discover the RPC transport supported by the server or know it in advance. Higher-level protocols on the client can also determine whether a server supports a given RPC transport by sending a message on the RPC transport. If the server supports the RPC transport, the communication succeeds. If the server does not support the RPC transport, the RPC transport either returns a transport-dependent error or returns no reply, depending on the transport. For details on client behavior in the case of no reply, see sections 3.2.2 and 3.3.2. If the transport returns an error, an implementation-specific error is returned to the application or the higher-level protocols.

  • Protocol Versions: These RPC extensions do not introduce new protocol variants. The preexisting protocol variants are specified throughout this document. RPC extensions constrain the DCE 1.1: RPC specification, as specified in [C706], to only support protocol version 5.0 for connection-oriented RPC, protocol version 4.0 for connectionless RPC, and protocol version 2.0 for the NDR transfer syntax universally unique identifier (UUID). The DCE 1.1: RPC specification uses and extends the transfer syntax negotiation mechanism, as specified in section 3.3.1.5.6 and in [C706] chapter 12. Version negotiation is performed separately for each RPC interface, as specified in [C706] chapter 12.

  • Security and Authentication Methods: RPC extensions use a model with a pluggable security provider module for the actual security and authentication work. Higher-level protocols on the client should discover the security provider supported by the server or know them in advance. Higher-level protocols on the client can negotiate the use of RPC security providers by sending a message by using a given RPC security provider. If the server supports the RPC security provider, as specified in sections 3.3.3.1, 3.2.3.5.4, and 3.3.3.5.3, the communication succeeds. If the server does not support the RPC security provider, the server returns an error, as specified in section 3.3.3.5.3 for connection-oriented RPC protocols, or as specified in section 3.2.3.5.4 for connectionless RPC protocols.

  • Capability Negotiation: For the capability negotiation specified in sections 2.2.2.3 and 2.2.3.3, this protocol uses unused bits in the RPC protocol data unit (PDU) header, as specified in sections 2.2.2.3 and 2.2.3.3. This protocol also uses the bind time feature negotiation mechanism, as specified in section 3.3.1.5.3.