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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dsml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [dsml] Draft 10/31 of DSML v2


1. Schema problems

  The document body seems to have gotten out of synch with the schema in the appendix. Section 4 mentions DSMLResponse several times as one of the four possible top-level elements, but it is neither defined nor referenced in the schema. The same is true for DSMLRequest.

  There are groups defined in the schema for DSMLResponses and DSMLRequests, but neither type is referenced elsewhere in the schema.

  If it is the case, as the document body indicates, that you can have a DSMLRequest or a DSMLResponse as the root element of a DSMLv2 document, then they should be defined in the schema.

2. The Bind request

  The BindRequest element does not specify or imply a bind at all. Binding is assumed to have taken place outside the DSML document. I suggest renaming the element to something else, e.g. AuthorizationRequest. The same goes for BindResponse, of course. Note: with an implementation of proxied authorization as per http://search.ietf.org/internet-drafts/draft-weltman-ldapv3-proxy-07.txt, the server will typically not execute any operation on receiving the AuthorizationRequest (which should therefor always succeed) but rather will associate the requested identity with each following request (which could therefor fail based on whether or not the bound identity is granted rights to be authorized as the requested identity for the particular operation). The AuthorizationRequest would fail if the server doesn't support such a request, or if it is able to evaluate and deny the request without examining the operations that the authorization identity will be applied to.

3. Searches in batch requests in concurrent mode

  Dealing with search requests alongside of update requests in a batch request is difficult to do efficiently on a server in concurrent mode, particularly if the results are to be ordered. I don't there is much value in it either. The justification for concurrent mode batch requests has been to allow efficient processing of bulk updates where the order does not matter. I suggest removing searchRequest from BatchRequests and searchResult* from DSMLBatchResponses. That means that search requests can only appear in a DSMLRequest.

4. Typo in section 8 heading: "8. but would like to know others' opinions."

Rob


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC