[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [dsml] Draft 10/31 of DSML v2
Re 1, the specification probably should not reference possible top-level elements except in the bindings sections, as which elements allowed to be top-level is binding-specific. Both bindings defined in the specification support top-level elements of types BatchRequest and BatchResponse only. Re 2, that makes sense to me and would help eliminate confusion. However if it's a tradeoff between hitting 11/22 and changing the names, I vote to hit 11/22. Re 3, searchRequest and searchResponse must remain as possible child elements of BatchRequest and BatchResponse, resp., given that otherwise they could not be expressed in the bindings we have defined. If a server implementation finds it to be too demanding to support concurrent searches, it is free to ignore the processing="parallel" directive and process them serially (or with a limited amount of concurrency). -J -----Original Message----- From: Rob Weltman [mailto:robw@worldspot.com] Sent: Friday, November 02, 2001 3:05 PM To: DSML version 2 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 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC