See also: IRC log
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.
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.
[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]