<cferris> I am on conflicting call as well

Misc

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.

3. Minutes

16 november: no pushback, minutes approved.

4. Action Items

Anish: pending

Mike: pending
... done

Noah: 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

<cferris> dialing

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

Chris: 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.

<cferris> please attribute "Chris: putting blank soap message is not good." to Marc

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.

<mikeem> I was just looking for that

This is scribe.perl Revision: 1.127  of Date: 2005/08/16 15:12:03  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/type/typo/
No ScribeNick specified.  Guessing ScribeNick: h_scribe
Inferring Scribes: h_scribe

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: Anish Chris Chris_Ferris Dave Dave_Hull Glen GlenD Marc Mike Montreal Noah Pete_Wenzel Solution Yves aaaa aabb anish2 cferris dhull mikeem
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 30 Nov 2005
Guessing minutes URL: http://www.w3.org/2005/11/30-xmlprotocol-minutes.html
People with action items: mike

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report