OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dsml-comment message

[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