Re: proposed approach for (a) rapid progress, and (b) interoperability

[Keith_Attenborough@lotus.com]

This suggestion makes sense to me.  It breaks the work down into achievable units, helps clarify what each component covers (so customers can more easily understand what is needed for a working implementation) and the modular nature means additional transports or other potential expansions can be handled without distrubing the basic work.


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

John McGarvey <mcgarvey@us.ibm.com> 08/09/01 01:09 AM

To:        dsml@lists.oasis-open.org         cc:        (bcc: Keith Attenborough/CAM/Lotus)         Subject:        proposed approach for (a) rapid progress, and (b) interoperability

I suggest the following approach.

We plan 3 documents for the DSML 2.0 spec.  The first of these is the
proposal on the table, which is for the XML grammar of DSML 2.0.  The
second describes the transport bindings for SOAP.  The third describes best
practices in the implementation/use of optional features. Additional
documents may follow for additional transport bindings.  The grammar
document should be completed quickly.  The SOAP and best practices
documents should follow within three months of completion of the grammar
document.  I don't think we will need a separate security document, as we
will inherit the security characteristics of the likely DSML 2.0
transports.

The grammar document should be comprehensive and inclusive, including a
number of optional features which may not be included in some
implementations.  The documents for the transport bindings, however, must
be sufficiently prescriptive so as to ensure interoperability of
implementations.  For example, the grammar document may specify that an
implementation must support either the sync or the async model, or both.
But the SOAP transport document may require that an implementation support
the sync model.  The grammar document may support the bind operation as an
optional feature.  But the SOAP transport document may require that
authentication of the user be out of band, and that the bind operation may
not be used.

If we adopt the approach of making the grammar document inclusive, we
should include the following optional features: bind, asynchronous
notification, the parallel processing advisory, batch processing, and
external entities for DN navigation.  This list is perhaps not exhaustive,
but hopefully it does not need to be much longer.

Regards,
John McGarvey


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: dsml-request@lists.oasis-open.org