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

[Christine Tomlinson <chris.tomlinson@sun.com>]

I will commit to a draft SOAP binding by next telecon.

ciao,
Christine

Jeff Bohren wrote:

> I think it is pretty clear that the DSML 2 should include the grammar,
> but should not include the SOAP transport. That still leaves a lot in
> between we have to sort out. I think the sun proposal lays out a good
> demarcation of where the core should end, but we need to do a straw-man
> of the SOAP bindings and see how well it works with it.
>
> Jeff Bohren
> Access360
>
> -----Original Message-----
> From: Jeff Parham [mailto:jeffparh@windows.microsoft.com]
> Sent: Thursday, August 09, 2001 1:13 PM
> To: Keith_Attenborough@lotus.com; John McGarvey
> Cc: dsml@lists.oasis-open.org
> Subject: RE: proposed approach for (a) rapid progress, and (b)
> interoperability
>
> This sounds right to me -- thanks, John.
>
> The lingering question I have is what exactly does the core "DSML 2"
> encompass?  I.e., if someone claims their product to be "DSML
> 2-compliant," does that mean that it implements just the grammar, the
> grammar and the SOAP transport, or... ?
>
> -J
>
> -----Original Message-----
> From: Keith_Attenborough@lotus.com [mailto:Keith_Attenborough@lotus.com]
>
> Sent: Thursday, August 09, 2001 5:17 AM
> To: John McGarvey
> Cc: dsml@lists.oasis-open.org
> Subject: Re: proposed approach for (a) rapid progress, and (b)
> interoperability
>
> 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
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: dsml-request@lists.oasis-open.org
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: dsml-request@lists.oasis-open.org