[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [dsml-comment] For Discussion
During looking again into DSMLv2.xsd, I found two more things that I'd like to submit for discussion. I. DsmlMessage attribute requestID The attribute 'requestID' of the DsmlMessage complex type is 'string'. Since it reflects the LDAPMessage.messageID, with all its restrictions, I have the following remarks: messageID is an Integer and is used to map a request onto its corresponding responses. requestID is a string. From the programmer's point of view, how shall I handle this mapping in the following cases: Example A: <searchRequest requestID="01">...</searchRequest> is answered by <searchResponse requestID="1">...</searchResponse> What rules apply to detemine the equivalence of requestID Strings? Example B: <searchRequest requestID="0">...</searchRequest> is a syntax error since a requestID of 0 is reserved for unsolicitedNotifications. But what about: <searchRequest requestID="0000">...</searchRequest> I'd suggest to change the base type of RequestID to Integer, as the MessageID in RFC 2251. Then equality is easy to determine. II. AbandonRequest DSMLv2.xsd defines an AbandonRequest but no AbandonResponse. This is aligned with RFC 2251 where it is defined that an AbandonResponse does not have a response. My first guess was - oops this is academic who will ever use DSMLv2 batchRequests first to start an operation and then kill it. My second guess was - oops this is not academic. I for example use batchRequests to test LDAP Server access, and maybe I want to test abandon operations one day. The DSMLv2.doc does not discuss AbandonRequest, but a clarification would be helpful. The following questions should be answered: - How should an AbandonRequest be treated for the different processing modes? My answer: processing="sequential" simple solution: ignore AbandonRequest - the operation will in any case already be finished before the AbandonRequest is met. Response order is maintained, only that no response is created for the AbandonRequest. A client requesting an Abandon operation in a batchRequest gets back a batchResponse that looks as if no AbandonRequest had been present in the batchRequest. or - more sophisticated If the server first parses the requests before starting execution, he may detect that a particluar operation has a subsequent Abandon and decide not to start the operation. In the batchResponse, an appropriate result code indicates this, see below. processing="parallel" Server may ignore the AbandonRequest and process the batchRequest as if there were no AbandonRequest. If the Server can handle Abandon, and the AbandonRequest pertains at an operation that can be abandoned (Search or Compare), and is still running: Stop the operation. For a Search, return a SearchResponse with only a SearchResultDone indicating a specific result code "abandoned" which has to be added to DSMLv2 Specification. SearchResultDone is required in SearchResponse. For Compare, return a CompareResponse with resultCode "abandoned". The same applies for operations not yet started. - If the abandon request specifies an abandonID that does not correspond to a previously requested message, or a mesage already abandoned, how is this to be treated? RFC 2251 states that servers must ignore AbandonRequests for unrecognized messageIDs or messages already abandoned. So just ignore such an AbandonRequest. - If an AbandonRequest contains a syntax error, an ErrorResponse must be generated. So how to treat response order if an erroneous AbandonRequest appears in a batchRequest? As any other Error detected during processing the batchRequest: Return a helpful ErrorResponse. -- Dr. Annette Sündermann Zenturion GmbH Postfach 1248, 85730 Ismaning Tel.: 089/638 76 706 Fax: 089/638 76 707 Internet: http://www.zenturion.de
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC