Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
The Directory Services Markup Language (DSML) Protocol [DSML2] is a protocol that specifies the encoding of directory service (DS) operations in XML [XML10] documents using a SOAP [SOAP1.1] request/response binding. These XML documents can be used to request that a DS operation be performed, such as the creation or removal of a directory object.
In a [SOAP1.1] binding, there is no correlation between subsequent operations. That is, there is no way for a caller to indicate that a directory operation is a continuation of a previous directory operation. Even though this lack of continuity does not cause an issue for many directory operations, a directory server can implement operations that are intended to be used in a sequence where an operation is required to be correlated with a preceding operation.
For example, Lightweight Directory Access Protocol (LDAP) paged searches [RFC2696] allow a search that returns a large number of results to be split into multiple searches, each of which returns a subset of search results. The server can return a cookie with each search result that the client is expected to pass to the next search request. However, for the server to be able to interpret the cookie correctly, the server is required to detect that the next search request is a continuation of the search request that returned the cookie. DSML SOAP session extension (SSE) provides such a mechanism to correlate multiple search requests. This mechanism can be used in conjunction with existing LDAP controls, such as LDAP paged search control [RFC2696], to enable operations such as LDAP paged searches.
In DSML SSE, the correlation between operations is abstracted as a session. Zero or more directory operations can be performed in a session, and it is the responsibility of the DS to save any state necessary for correlating the operations in that session.
SSE provides the following features to clients:
A way to indicate that a DSML request is expected to cause the creation of a session.
A way to associate operations with a specific session, so that the DS can save any state required for correlation between those operations.
A way to request that a session be terminated, so that no future requests will apply to that session and so that the state of the session can be discarded by the server.
SSE does not specify the state that is required to be saved. An implementation of a DS is free to save any state that could be necessary for performing future operations within that session. For example, a DS that supports LDAP-paged searches could choose to save the portion of the search result that has not yet been returned to the client.
SSE does not specify how soon its state will be discarded after a session is terminated. Moreover, discarding the state of a session does not imply further changes to the state of the abstract data model of the directory [MS-ADTS]. That is, directory objects that were added to the directory as part of the session stay added, objects that were removed stay removed, and objects that were modified stay modified.