3.1.4.2 Session

Note Abstract data model objects that are referenced in this section are defined in section 3.1.1. SOAP fault processing is specified in section 3.1.4.4.

The server MUST perform a Session operation when it receives a DSML SOAP request message that contains a <Session> header (section 2.2.2.2).

If the server is not capable of performing a Session operation and if the header contains a soap:mustUnderstand attribute equal to 1, then the server MUST generate a SOAP fault and MUST NOT process any DSML operations that are contained in the SOAP body of the message. Otherwise, if the server is not capable of performing a Session operation and either the header does not contain a soap:mustUnderstand attribute equal to 1 or that attribute is not present, then the server processes the DSML operations as if the <Session> header were not specified.

To perform the Session operation, the server MUST retrieve the SessionTableEntry from the SessionTable, which contains a SessionID object with a value that matches the SessionID attribute specified in the <Session> header. If no such SessionTableEntry is found, then the server MUST generate a SOAP fault.

After the matching SessionTableEntry has been retrieved, the server MUST reset the timer represented by the <SessionIdleTimer> element of the SessionTableEntry, to 0. The server MUST perform any DSML operations that are contained in the SOAP body of the request message, using the state stored in the SessionTableEntry. DSML operations have the form of a <dsml:batchRequest> element with zero or more child elements. The server saves any state changes in the Session object of the SessionTableEntry to correlate these operations with future operations.

When all operations, if any, have been successfully completed, the server MUST generate a DSML response message [DSML2] with a <Session> header (see section 2.2.2.2). The SessionID attribute of that <Session> header MUST be assigned the value of the SessionID object of the retrieved SessionTableEntry.