W3C

XMLProtocol

30 Nov 2005

Agenda

See also: IRC log

Attendees

Present
Canon, Herve Ruellan
IBM, Chris Ferris
IBM, Noah Mendelsohn
Nokia, Mike Mahan
Oracle, Anish Karmarkar
Sonic, Glen Daniels
Sun Microsystems,Marc Hadley
Sun Microsystems; Pete Wenzel
Tibco, David Hull
W3C, Yves Lafon
Regrets
BEA Systems, David Orchard
Absent
Iona Technologies, Suresh Kodichath
Microsoft Corporation, Mike Vernal
SAP AG, Volker Wiechers
Excused
BEA Systems, Mark Nottingham
Canon, Jean-Jacques Moreau
Microsoft Corporation, Doug Purdy
Oracle, Jeff Mischkinsky
Chair
Mike Mahan
Scribe
Herve Ruellan


1. Roll call. Scribe for minutes

Herve is scribe

2. Agenda review, scheduling and AOB

Welcome to our two new members: Glen Daniels & David Hull

F2F

Mike: trying to have F2F at W3C Tech meeting.

However scheduling problems due to other group meetings

Solution: saturday after TP is the result. New members need to be aware of this.

3. Minutes

16 november: no pushback, minutes approved. Please publish Yves.

  1. Action Items

2005/10/05 Anish

Respond to his xmlp-comments posting, copying WSA, with early word of likely disposition of optional response in the HTTP binding

PENDING


2005/11/02: Mike

Verify the status of issues wrt PER specs

PENDING


2005/11/16: Mike

Ping Mark Baker wrt 33rec

Done


2005/11/16: Noah (due 30 nov)

Do a followup on the no-MEP/uber-MEp thread.

DONE



5. Administrative

Yves: PP and charter, vote still going on.

1 week for PP. Then 1 more week for new charter.

Probably finished by EoY

(may need to respond to charter comments)

7. MEP issue

Glen: 1 of main questions: shall MEP exists? And if yes, at what layer?

What to do with a WSDL MEP? HTTP has a build-in req-resp paradigm, other protocols may have other paradigm.

No consensus about where MEP lives.

1 way to see it, is that as SOAP MEP is close to a WSDL MEP.

Other way: SOAP MEP is an abstraction of a protocol MEP. HTTP has req-resp, SOAP req-resp MEP that binds to HTTP req-resp.

In first case 1 WSDL MEP binds to 1 SOAP MEP that binds to multiple protocol paradigm.

In second, 1 WSDL MEP binds to multiple SOAP MEP linked to protocol paradigm.

With a SOAP MEP close to HTTP transport, no need of 1-way MEP. Only need req-resp MEP with optionnaly empty response.

Think that MEP should stay.

Yves: HTTP natively does have ability 1-way stuff with empty response.

Dave: good summary of where things are.
... agree that SOAP MEP are usefull abstraction and should be close to transport level.
... SOAP MEPs describe what a protocol can propose.

Tend to think that every transport should provide a 1-way MEP.

To map WSDL MEP to SOAP MEP, it makes sense to have 1-way for everything, even HTTP.

Glen: fundamental difference is about where you bound your decision?

Dave: no, question is how do we model the way it is signaled.

1 approach: in case of HTTP, allways send a response (even if empty). Other way, use 1-way.

Glen: choice may be done late.

Dave: if define both (req-resp and 1-way), have to build them well, because have to distinguish them at response time.

Noah: new pb that can not decide at binding level from the outbound message which MEP is used.

Need to do it compatibly with existing REC.

Dave: possible to do it.
... when define 1-way for HTTP need to have it compatible with req-resp.

Noah: can have spec level compatible, but need to have it with software implementations.

May have a problem with current implementations.

Only way do it, is to add some marker.

Means that this new stuff will not be compatible with current implementations.

Think it is an incompatibility.

But thinks probably a murkier, because many implementations have ignored the REC on this point.

Noah: this is not an errata, but a change, because nothing is broken.
... case with 2 responses (ack to original sender + true response) common?

Marc: Does not append like this.

Noah: 1 way: add something in message to say that 1-way MEP is used.

Marc: could assume that if not there, then req-resp.

Noah: 2 way: create a new MEP, somewhat incompatible with current MEP: send a SOAP message with perhaps a response.
... 1st way is compatible, 2nd not.
... say in spec for new binding, that it is largelly compatible with existing binding, but not completely compatible.

<cferris> I'm wondering if maybe what is needed is just a oneway SOAP MEP that is NOT supported by HTTP but possibly by other underlying transports such as TCP or BEEP

Noah: 3rd option is just to ignore compatibility and rewrite current binding.
... 4th option is to use the uberMEP option.

<cferris> I am actually thinking that maybe we got it right... that for HTTP, there should always be a response SOAP envelope even if it is empty

<cferris> I am increasingly concerned about the conflation of SOAP MEP and WSDL or higher-level MEP

<cferris> I think it is a mistake to conflate them

<cferris> they are completely orthogonal

<dhull> We mean *not* to conflate them (at least Glen and I)

Anish: if we add HTTP header, would not break compatibility. What about using a SOAP header? WSA make it clear whether there will be response or not.

<dhull> E.g in-out -> either req-rep or two one-ways, depending

Noah: think that it is a good point.

Can turn question over.

<marc> i *really* dislike the idea of sending round empty SOAP messages, what is the point ?

HTTP header: very early signalling that compatibility is broken.

<dhull> they might not always be empty

Making SOAP depending on WSA is not good.

<dhull> +1

<marc> getting two separate response SOAP messages is just adding complexity with no benefit IMO

<cferris> well, what I dislike is disalowing a SOAP envelope in cases where the WSDL says oneway

Feels more natural that the binding knows about transport.

More a matter of taste, whether or not making the HTTP binding dependant on WSA header.

<dhull> E.g, BEEP request, BEEP "OK" response includes [message id] to say exactly which message it's ack-ing

Glen: in spec, 2xx has a blank significance.

<dhull> (that was aimed at Marc's objection to empty SOAP messages)

<marc> right so there's no need to repeat that in a SOAP payload

Therefore is it OK to fix this.

<dhull> (? [message id] *is* a SOAP thing)

<marc> i missunderstood, i meant the BEEP level correlation

Chris: pb: what WSDL says is at application level. Nothing to do with real message exchange.

<dhull> That's another way to do it. Maybe better. IMHO there is still an open question as to how WSA MAPs relate to analogous transport-level things

SOAP req-resp MEP maps nicely with HTTP messages.

People are binding WSDL MEP with SOAP MEP. Is it necessary?

Need to make clear what a MEP means.

Noah: part of thing to do is to help people to be organized.

Intersting thing about SOAP MEP is that allows to make statement about multiple transport.

Allowed to remove the transport details from the application.

In many cases, it means that SOAP MEP maps pretty close to transport level.

Chris: if you have multiple MEP supported by a transport, what signals what MEP to use.

Noah: a year ago, seems natural to know from outbound message what MEP is used. Not more the case, with WSA use-cases.

Dave: you know what case you have by the response you get.

<anish2> +1 to not including blank soap messages

Marc: putting blank soap message is not good.

Dave: there were cases where it was usefull to send back a SOAP OK message, with something more in it.

Not only say: OK I got this 1-way message, but also for e.g. something about reliability.

Anish: if sending back some information, would'nt that be SOAP req-resp?

Dave: it could still be a 1-way message at application level.

<Montreal> Montreal people are going to head out....

AOB

Mike: Christmas schedule.
... 28 dec is off.
... probably do 21 dec.
... will do 4 jan.

- Test collection errata.

Anish: one issue is a typo.

Mike: already discuss?

Anish: yes.

Mike: what is needed to do?

Anish: need to agree how to fix it.

Mike: take this next week.
... If any pushback for the resolution, make it this week. Will make decision next week.

<scribe> ACTION: mike to put e-mail to list for sending response to proposed changes to test collection issues. [recorded in http://www.w3.org/2005/11/30-xmlprotocol-minutes.html#action01]

Mike: call adjourned.

Summary of Action Items

[NEW] ACTION: mike to put e-mail to list for sending response to proposed changes to test collection issues. [recorded in http://www.w3.org/2005/11/30-xmlprotocol-minutes.html#action01]
 
[End of minutes]