Re: Proposed DSML 2 schema changes

[Keith_Attenborough@lotus.com]

One sort of devil's advocate question, and I apologize if this was covered in a prior call I missed.  Ref the proposal that "A DSML implementation must support model=sync or model=async" (underline added), and associated comments on flexibility.

The question is, can a DSML implementation which has chosen model=sync effectively (from a customer viewpoint, that is out of the box without consultant support) work with (interchange information) a DSML implementation that has selected model=async?  If the answer is an uncaveated "yes", then ignore the rest of this message. 

If the answer is other than an uncaveated "yes" then it seems like this extended flexibility will lead to exactly the situation standards are supposed to prevent and that customers hate -- they go to two vendors, are told "yep, we support DSML", make the trusting but naive assumption that this means the products will actually work together, then find out the two implementations support different models.  It would be better to pick one of the models as a "MUST" (A DSML implementation MUST support model=async) and the other as a MAY (A DSML implementation MAY support model=sync).  Picking which model is the must could be a real dog fight among the vendors, but frankly customers don't care how hard it is for us, they want products that work.

Similar comments apply to the rest of the proposed MUST v. MAY in the body of the message below.  To the extent that implementations need to have made the same choices on these elements in order to interoperate, then the choices should be "MUST".  And a suggestion is that since a single operation/response per envelope is a simple instance of supporting multiple operations/response per envelope, then perhaps supporting multiple operations/responses per envelope is the preferred choice.


Keith
------------------------------------------------------
Keith Attenborough, Product Manager - Lotus Directories
IBM Software Group
email:  Keith_Attenborough@lotus.com
phone/fax:  617.693.9650 / 617.374.0111
cell:  617-834-6962

Jeff Parham <jeffparh@windows.microsoft.com> 08/07/01 08:00 PM

To:        dsml@lists.oasis-open.org         cc:        (bcc: Keith Attenborough/CAM/Lotus)         Subject:        Proposed DSML 2 schema changes

The attached is a strawman including the following proposed changes:

• Adds the model attribute to the DSMLEnvelopeRequest element (see below).
• Fixes a typo in the LDAPErrorCode enumeration.
• Adds controls to the LDAPResult element.  The LDAPResult element is used as the response type for all operations other than searches and extended requests, and per RFC 2251 all responses can contain controls.
• Incorporates the requestID proposed by John McGarvey (IBM) and Christine Tomlinson (Sun).  The only change from Christine's representation is that the requestID is an attribute rather than a child element.  Incorporated John's suggestion that the requestID can occur on envelopes as well as individual requests/operations.
• Changes oc-class from minOccurs=1 to minOccurs=0.  This allows for DSML transformations of LDAP search responses corresponding to search requests in which typesOnly=true.
• Removes the dn attribute from ExtendedResponse.  (There is no such field in RFC 2251's ExtendedResponse.)
  The proposed model attribute of the DSMLEnvelopeRequest has two possible values -- sync and async.  The sync value indicates that the responses corresponding to all requests in the envelope must be bundled into a single DSMLEnvelopeResponse -- i.e., the behavior described in the original MS proposal.  The async value indicates that the responses corresponding to each request in the envelope may be sent asynchronously (using multiple DSMLEnvelopeResponse elements if needed).
   
  In addition I propose that the specification document state the following:
  • A DSML implementation MUST support model=sync or model=async.
  • A DSML implementation MAY support both model=sync and model=async.
  • A DSML implementation MAY support mutliple operations per DSMLEnvelopeRequest.
  • A DSML implementation MAY support multiple responses per DSMLEnvelopeResponse.
    For example, this would grant Microsoft the flexibility of not supporting the async model and iPlanet the flexibility of not supporting batched operations.