3 Protocol Details


In the following sections, the schema definition might differ from the processing rules imposed by the protocol. The WSDL in this specification matches the WSDL that shipped with the product and provides a base description of the schema. The text that introduces the WSDL might specify differences that reflect actual Microsoft product behavior. For example, the schema definition might allow for an element to be empty, null, or not present but the behavior of the protocol as specified restricts the same elements to being non-empty, not null, and present.

The client side of this protocol is simply a pass-through.  That is, no additional timers or other state is required on the client side of this protocol.  Calls made by the higher-layer protocol or application are passed directly to the transport, and the results returned by the transport are passed directly back to the higher-layer protocol or application.

Except where specified, protocol clients SHOULD interpret HTTP Status Codes returned by the protocol server as specified in [RFC2616], |Status Code Definitions (section 10).

This protocol allows protocol servers to notify protocol clients of application-level faults using SOAP faults. This protocol allows protocol servers to provide additional details for SOAP faults by including a detail element as specified either in [SOAP1.1], SOAP Fault (section 4.4) or [SOAP1.2/1], SOAP Fault (section 5.4) that conforms to the XML schema of the SOAPFaultDetails complex type specified in SOAPFaultDetails. Except where specified, these SOAP faults are not significant for interoperability, and protocol clients can interpret them in an implementation-specific manner.

This protocol allows protocol servers to perform implementation-specific authorization checks and notify protocol clients of authorization faults either using HTTP status codes or using SOAP faults as specified previously in this section.