RE: [dsml] Draft 10/31 of DSML v2

[Jeff Parham <jeffparh@windows.microsoft.com>]

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>