DSML Teleconference Minutes September 5, 2001

 

 

List of attendees:

Winston Bumpus, Chair

Alexis Bor

John McGarvey

Keith Attenborough

Shon Vella

Jeff Parham

Christine Tomlinson

Nigel Jacobs

Trey Prake

Darran Rolls

Gavenraj Sodhi

Tony Gullotta

James Tauber

Rob Weltman

Andy Hariotto

 

 

Minutes:

 

      Microsoft Scenarios and Proposals:

 

            1st scenario:  SOAP Client sends invalid message in envelope

                  (Agreed that it is out of scope, mostly SOAP spec)

            What happens if error happens between SOAP server and DSML server?

                  - SOAP Fault should be returned.

                        - Is their an alternative?

                        - There is no alternative and there is no disagreement.

 

            What we disagree on… (2nd Scenario)

-        DSML client, who piggybacks SOAP envelope, creates wrong DSML request.  In this case, two options return SOAP fault or return SOAP response body with error response from DSML.

-        Proposal:  Use SOAP body

o        Consistent with how DSML works

o        Should use error response

 

Last scenario

-        Query with no success:  Resolve code of no success is returned.

o        Proposal:  Return as a DSML response and not SOAP fault.

 

 

Action Item:  Winston:  Liaison with XML Protocol Group

      - Whether SOAP Fault message is designed for Application error messages.

 

      SOAP fault was intended to describe SOAP-related errors.  If SOAP cannot with DSML server, this makes sense.

 

      SOAP as used with UDDI, does it raise a lot of complexity? How so?

           

      SOAP Fault provides message as an advisory.  Like an application layer within the transport layer.

 

      Proposed extension or alternation to original response message with respect to error response.

 

-        A lot of things needed to be discuss.

 

1) Identifying what are compliant entities (DSML envelope request, response, DSML Request and DSML response)

-        May have been mis-interpretation to SUN's proposal

o        Search response would not be top-level as defined by SUN

o        Would be put in batch name-space

2) Embed multiple v2 elements in own document if you would like

3) Both transport that working group is proposing (LDIF-replacement and SOAP) would require envelope

4) Specification will continue to focus on envelope, as it will be for baseline transport

5) Formalize scope of working group and also else would be on top of baseline framework and/or DSML v3.

 

DSML group defines a choice amongst a collection of responses, none of them were a search response.

           

            Any other comments to Jeff’s Proposal?  Nothing.

 

            Have not come to consensus to namespace issue.  Good for next conference call.

 

-       OASIS has URI reference

 

Action item:  Forward URN reference to list.