XML Protocol Face-to-face, Mandelieu, France, 3/4/2006 -- 4 Mar 2006

<mikem> agenda http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Feb/0030.html

<mikem> topic XML Protocol F2F

<cferris> dilaing in shortly

<cferris> just making coffee, etc

<cferris> have we started?

<Yves> not yet

<GlenD> good morning Chris :)

<cferris> hardly

<GlenD> heh

<GlenD> Perfect time for an MEP discussion, eh?

<cferris> mwahhahaha

<GlenD> Make sure to invite the dog to the telcon too

<cferris> in

<cferris> and yes, the dogs are here

<cferris> :-)

<noah> Hi Chris!

<cferris> Hi Noah

<mikem> Iles 'A'

<GlenD> Scribe: GlenD

1. Action Items

- Draft web page describing SOAP MEPS. DONE see http://lists.w3.org/Archives/Public/xml-dist-app/2006Feb/0028.html

<cferris> does the page need a status?

Mike: should we publish this?

All: yep

(discussion of why to use frag-ids in the URL for MEPs)

<scribe> ACTION: Yves to check the HTML and publish the MEP document. [recorded in http://www.w3.org/2006/03/04-xmlprotocol-minutes.html#action01]

<Yves> http://lists.w3.org/Archives/Public/xml-dist-app/2006Feb/att-0028/ClassOfMEPs.html

- Clarifying fault generation

Noah: We discussed this inline, should be in the appropriate minutes.

Mike: We needed to open a new rec issue?

Yves: Should check... yes, this is REC issue 41

Mike: Put this in errata

<scribe> ACTION: Noah to take proposed text for fault generation and insert into errata doc. [recorded in http://www.w3.org/2006/03/04-xmlprotocol-minutes.html#action02]

ACTION 2=Yves to take proposed text for fault generation and insert into errata doc.

2. SOAP PER status

(nothing to see here)

3. One-way SOAP messaging.

Mike: Goal for today is to come to a conclusion on how to resolve this one.
... Fairly clear proposals... Let's discuss the new mail threads (if any need to do so) then really dig in?

Marc: I'd really like to hear what's functionally unique to each of the various proposals... struggling to understand the differences between some of them. Does this change how the protocol actually functions?
... if this is really about documentation and nothing else, I'm happy with whatever. But if there are actual functional diffs, I want to understand that.

Glen: I'd been envisioning doing a flipchart of a couple of scenarios - here's the WSDL, the messages, etc. for each proposal, and how they'd change. I think the changes aren't nec. on the wire but in the WSDL...

<cferris> Glen, actually, I would hope that the wsdl would have nothing to do with it AT ALL

DaveH: We've only got one binding. There's a disproportionate amount of attention to HTTP right now. Wishy-washy in WSA about what it means to send/receive a message....

<Yves> +1 to chris, at the SOAP level we don't even know that WSDL exists

<cferris> http://www-128.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=440&entry=10792http://www-128.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=440&entry=10792http://www-128.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=440&entry=10792http://www.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=440&entry=107924

<cferris> weird

<cferris> I think that is a Notes feature

<Yves> but we can define things with the hope that wsld exist :)

<anish> i get a error 500

DaveH: I think we're not really doing a good job (i.e. much at all) to help out with other bindings
... I sent out a list of questions we need to deal with... I'm down with whatever as long as the proposal(s) we consider can answer those questions

<Yves> anish, see http://www-128.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=440&entry=107924

DaveH: Even if two proposals put the same things on the wire, if one makes it harder to write a new binding/describe what's going on, then that's a value differentiator.

Mike: OK, let's try to dispatch the strongly/weakly typed and the discovery MEP threads first, and then come up with a plan for closure.

<cferris> +1

Noah: Marc's onto something here. Let's make sure we actually know exactly what the proposals are here (point at particular documents/emails/etc)....
... I'd almost rather go and work through the examples first and then allow that to bring up the conversations like strongly/weakly...
... Proposals differ in various ways, incl. how we change the spec, how many documents, etc. We need to track all these dimensions.

Mike: if we could pull the discussions into the overall framework of laying out the proposals/examples, then I'm good with that.

Marc: okee

<noah> Right: I think going through worked examples is important, as Marc says, but I want to be sure we discuss the other dimensions such as whether we want to minimize changes to the text vs. taking the opportunity to "improve" it.

DaveO: Let's do the flipchart thing. Two straightforward cases we can talk about - one-way and req-resp... with req-resp working over HTTP and not. That last seems to be a key difference between strongly and weakly typed.

<noah> Glen: can we start be agreeing on what we're going to do?

DaveO: Need to update my examples a little, but I think maybe we should start with those.

Noah: Scenarios that don't involve WSDL are very important. SOAP messages need to be exchangeable in environments where WSDL isn't the right model for thinking about them. SOAP needs to be usable in low-end scenarios (scripting, tossing simple dynamic messages around).
... want to make sure that the SOAP story stands on it's own in terms of what an MEP is, how to tell authors of bindings what they should/need to do, etc.

<Zakim> noah, you wanted to talk about non-WSDL scenarios

<cferris> -1 to Glen's point about use of SOAP MEP URI in WSDL

Glen: I think that WSDL is useful in more ways than just having the document around - when writing other "things" that talk about SOAP services (whether WSDL or binding specs or extensions), that's when we often see these concepts (MEPS etc) appear and alter things a bit

Chris: WSDL shouldn't talk about MEPs
... When you toss in WSA, that screws everything up

(brief discussion about who was saying what)

Glen: I do think that WSDL should have a way of talking about what SOAP MEP(s) to use

Noah: I hear Chris saying that the WSDL talks about the bindings - the binding spec tells you which MEPs are involved, but nobody says that in the WSDL.
... I hear Glen saying that if the WSDL names the SOAP MEP, it can help you choose which binding to use, or make sure you have an appropriate one.

Glen: Not quite right

Chris: When you establish a binding, that certainly brings along the MEPs that binding supports. But if I want to do async req/resp over HTTP, then the SOAP MEP has nothing to do with the WSDL MEP. (woof woof)
... (woof woof)

<Zakim> dhull, you wanted to comment on SOAP/XMPP

<dhull> http://lists.w3.org/Archives/Public/xml-dist-app/2006Feb/0022.html

Glen: I actually think that WSDL MEPs should bind down to "one or more" SOAP MEPs - you don't necessarily look for exactly a compatible SOAP MEP, you either find a binding that matches natively or adapt the WSDL MEP down to a particular binding using something like WS-Addr

DaveH: Laid out the questions (what info do you need, what do you need to do) to answer in order to send messages in that email.
... protocol capabilities, whether you're using anonymous in WSA, etc... lots of cases to consider. We tend to focus on one piece without looking back out at the whole decision tree. Hopefully this can help focus us better.
... Noah mentioned SOAP/XMPP, and that's a telling example. They said "hey we have a protocol, what do we do?". So they bound Req/Resp because that's the only thing they could find in the Rec. They bound it correctly, but they ALSO have this one-way thing and they bound req-resp to that, which *isn't* right.

DaveO: Weakly typed is superior to strongly typed - I have a scenario for exactly this, and I need a 20 minute grudge match with Noah to convince him.

DaveH: I want to hear it if you've got a killer app for weakly. Curious as to how it answers my questions.

Noah: We all want to get this stuff out on the table, maybe not so much one-one...
... I can see where in some sense the XMPP binding is a good use-case... we can look at their binding as if starting from each type of proposal, and see what's good and bad...

<dhull> +1

<dhull> It's not SOAP MEP exposed to upper level. It's SOAP and WSDL both are used in figuring out what to put on the wire. Neither is above or below the other.

DaveO: A couple people have questioned why have a SOAP MEP exposed to the upper level. I want to make sure the mapping between the description formats and the MEP is on the table. Take this upper level message and put it into a lower level message, etc.... So essentially, speaking against Chris' point earlier.
... Just read Chris' blog entry, and there's a slight mischaracterization. I don't actually want a "SOAP one-way abstract binding" and a "SOAP one-way and req-resp abstract binding" which sit on TOP of actual protocol bindings.. I want FEWER SOAP MEPs/bindings, not more.

Yves: Should focus on a small set of MEPs and map to the most frequently used transports

Anish: Let's not extend this to Sunday (was Dave serious?)...!

<dorchard> I wasn't serious about Sunday..

<dorchard> DaveH, I have read your message and I like it btw...

Anish: Let's make a decision and move on. We've been doing this stuff for a looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong time now, so let's just get some direction and go there.
... I don't find req * / resp * (ultra flexible mep) to be very useful.

<dorchard> DaveH, in fact I want to dive into the issue of how does the receiver "know" which MEP, either in-only or in-out is in play..

Anish: On the other hand, also not useful to talk about EVERY single message talked about by an underlying protocol (i.e. tcp windowing, etc)
... Anything that gets my use-cases done is good with me. Seems like our proposals thus far mostly do this.

<Zakim> anish, you wanted to say that we should make a decision today and not extend the f2f till tomorrow

<dorchard> my point wrt chris' blog is that I agree that we need a binding per protocol, I don't want to have where there's a meta-mep that is an abstraction of various meps.

BREAK - back at 11:10AM Cannes time

<cferris> I can't dial back in

<cferris> conference is restricted

<mikem> I'll check now

<cferris> yoo hoo

<cferris> are we back yet?

<cferris> I couldn't dial in

<dorchard> Scenarios are at http://www.pacificspirit.com/Authoring/async/async-scenarios.html

<cferris> ah

<cferris> why did the coe change?

<cferris> why wasn't it just the usual code

<dorchard> And the ones that I think are v. worthwhile are at http://www.pacificspirit.com/Authoring/async/async-scenarios.html#twoway-inout

<Yves> because the call was schedules at 10am instead of 9, so I created a teleconference for when we started :)

<cferris> AH

RESUME

<cferris> no wonder it was on my calendar for 4 am

<Yves> as you woke up early, if would have been a shame to say "well wait for an hour to dial" :)

<cferris> lol

Dimensions to consider:

* how much impact on the current specs

* obligations and opportunities for binding authors

* WSDL description ease

* Functional operation

<dorchard> And how I talk about descriptions can use the "protocol mep" at http://lists.w3.org/Archives/Public/xml-dist-app/2005Nov/0011.html

<cferris> could we have some scribing here?

<cferris> I can't see the whiteboard and I can only barely hear the discussion

There isn't yet much to scribe in discussion, but I'll copy whiteboard

Scenarios:

- SOAP only

- WSDL + SOAP

- Jabber

(Dimensions are as above)

Counting MEP options...

Noah: req/optional-resp = 1, SOAPResponse = 2, OneWay (FAF) = 3

Yves: we could also have req/resp(not optional), soapresponse, and one-way with a flag

Noah: HTTP forces particular timing (transport resp always comes back)

Chris: another dimension is "what are we describing"? app level or the nature of a binding?
... One-way isn't appropriate for HTTP... Jabber or BEEP is inherently ad-hoc bidirectional, so that's the nature of the MEP. You can do req/resp, but lots more too. Wouldn't necessarily want to ascribe req/resp to it...
... in terms of underlying binding HTTP is req(opt body)/resp(opt body). Maybe we put too fine a spin on it when we did SOAPResponse
... let's not become architecture astronauts

<anish> architectural astronauts: http://www.joelonsoftware.com/articles/fog0000000018.html

Chris: fix it and make it work, move on, rather than do some architecturally "perfect" thing which might require SOAP 1.3

<dhull> The aim here is to make two things easy: 1) Writing bindings for protocols not yet covered, 2) implementing those bindings and apps on top of them.

DaveO: Where does strongly/weakly go under dimensions? Impact on WSDL extensions?

Noah: Maybe we should get concrete and start with examples, discussing these things in that context?

Mike: Just getting criteria down before we start diving down

DaveH reiterates his comment above in IRC

<dorchard> So, the scenario area is http://www.pacificspirit.com/Authoring/async/async-scenarios.html#twoway-inout

Noah: an aside - can we get these things in W3C space if we're going to continue to use them?

Dave: sure

<dorchard> http://www.pacificspirit.com/Authoring/async/async-scenarios.html#twoway-inout

Dave: how does the receiver know which scenario (3.3.1/3.3.2) it's in? This seems a good thing to look at.

<cferris> why does it care?

Marc: Didn't you just tell us? It's got a reply-to of anonymous or not....

Dave: right, message contents trigger particular behaviour

(argh, apologies - "Dave" in recent scribings has been "DaveO")

(DaveO runs through examples)

DaveO: Important part is how the receiving software knows to send a 202 or to send a response envelope

Glen: None of this (WSDL description, wire messages) really changes based on which MEP architecture we choose....

That isn't actually true, because the WSDL *might* change a little (names of MEPs)

Noah: Another layer that is important here is that even though SOAP doesn't describe a particular way of writing your software, it has as a goal enabling you to do it well.
... Part of what we're doing is considering how our architectures help to encourage software to be built well.

(back to DaveO's examples)

<noah> Right, so a key part of what we're going to have to discuss in a minute is: what are our assumptions about how software might be built at the two endpoints and (a) can you make the right decisions with either design, or is there a problem with one of them and (b) does one or the other facilitate a nicer layering.

<cferris> I would like to +1 Noah's last point... SOAP describes a protocl, not the implementation

DaveO: Key part of this is how we write the wsa:UsingAddressing WSDL extension

<noah> Well, to be clear, I said that, but I also said that one of the design points of MEPs is to facilitate clean and well layered implementations. In particular, I would claim that MEPs were invented to make it easier to write software layers that could make similar protocols look similar to SOAP applications.

Chris: I'm having trouble with wsa:UsingAddressing and how it trickles down into the layers... WSDL is only from one endpoint's POV and message flow is about two endpoints. Fundamentally broken, makes assumptions about what the client is/isn't going to do...
... unclear how you factor in MEPs, and it's weird to try to put that in at the WSDL layer
... SOAP processor should NOT know about the WSDL...
... how the SOAP proc. determines if there's a response comes from ABOVE the SP, not below it.

(nodding heads)

Chris: where the response goes either gets handled implicitly (binding) or explicitly (WSA header)

(clarification of who said what)

Chris: OK, my concern isn't currently a concern, continue...

(DaveO continues)

<cferris> q_

<cferris> if [reply endpoint] is anon, and the binding is UDP, the SOAP processor would generate a fault because there is no response channel

Glen: UNLESS there is a SOAP/UDP binding that supports a backchannel

DaveO: Core question is how you know that you should/shouldn't send anonymous replyTos

<cferris> if the sending SOAP node had any sense at all, IT would generate a fault if the [reply endpoint] = anon and the binding does not support a response backchannel

+1 chris

<marc> +1 chris

<kraatika> Background question: Does SOAP binding framework really allow any kind of messaging protocol without any assumptions?

<anish> do u mean trasport protocol?

<marc> there are some assumptions, e.g. it must be able to serialize an infoset, send it somewhere and then reconstitute it

DaveO: One-way app message is OK in either case (one way or two way underlying)

glen: Yes, except that in two-way underlying case, the software needs to generate a response anyway and needs to know how to do so

DaveO: Case for strongly typed - you know from which MEP you are using whether anonymous works or not. "using one-way, hey I can't do anonymous"
... Weakly typed has a single MEP and you know whether you can use anonymous by knowing the BINDING
... So in either the strongly typed or the weakly typed way, you need to know what binding you're using and the info comes from there, so the MEP "abstraction" doesn't do you any good insulating you from binding differences

Noah: Important to remember what some of us think an MEP is - certain bindings have a "common interface". When looking at the MEP you ARE looking at the binding. This allows you to do useful work based on the particular capabilities of the MEP regardless of the binding.
... Dave is looking at the binding and saying "do you have the supportsResponse property" as opposed to looking at an MEP

DaveO: Key thing is that in the WSDL for all of this there's a description (wsa:UsingAddressing) of the fact that addressing is in use.
... Value of having one MEP is that there's a common set of properties so that when you do the SOAP binding you can say things like "put the response in the soap:ResponseMessage property"

<cferris> IMO, the wsa:UsingAddressing should only be a key that says that addressing is supported

Noah: So these things are just a taxonomy of properties (a vocabulary) - requestMessage, responseMessage, etc... this is very different from what SOAP says an MEP is (i.e. MEPs in SOAP have behavior, where to deliver faults, etc)

<marc> i think we agreed in the WS-A WG yesterday that UsingAddr tells you one of three things: WS-Addr required | WS-Addr supported | unknown (if not specified)

<cferris> good!

<anish> yes we did marc

Noah: You may have good reasons for wanting to fundamentally change what an MEP is, but that is in fact what you're doing here.

<cferris> and what about all the asynch stuff? out?

<dhull> I thought we agreed that some time ago

(Noah does a dramatic reading from the SOAP spec)

<dhull> (Huzzah!)

<cferris> Specs on tape!

<cferris> Audio specs

<cferris> that's what we have been missing all this time

<marc> the wsaw:Anonymous element lets you say whether you require anon Reply/FaultTo | require non-anon Reply/FaultTo | can support either

<cferris> that seems odd to me, but I suppose the point is to allow an endpoint to signal whether it can produce a response in a reasonable amount of time or not?

<Yves> the point is also to catch errors at the sending side

<Yves> like in the one way with ws-addr reply-to anonymous

<cferris> and that is a problem why?

(Noah compares the uber-MEP to a giant Java interface which has every method ever - that loses a lot of the power of interfaces (constraining things to useful sets))

<cferris> suppose the wsdl oneway had a qos that required that the receiving endpoint return a non-repudiation receipt ack

<noah> Noah points out that SOAP Part 1 has a very important definition of MEP at http://www.w3.org/TR/soap12-part1/#soapmep.

<noah> Noah wants to know whether DaveO is trying to change this.

DaveO: You end up at the same place whether you have a parameterized MEP that you select between "modes", or a set of MEPs where you need to pick MEPs...

<Yves> chris: to where?

<cferris> that would not necessarily be described in the WSDL, but the response would be delivered on the HTTP response

<Yves> if it's A->B->C, (C and A being the same software) and A<->B is different

<dorchard> Yves, I do want to get to the sender point, but just not right when I was talking about the receiver...

<Yves> dave: ok I'll wait for that :)

Chris: DaveO keeps asking how it knows... and yet we have all this interop experience with WS-Addr/SOAP.... What are we trying to do here? Architectural purity?
... SOAP spec should not directly contradict what people are actually doing in practice... req/resp with required SOAP envelope in response is not what people are doing today.
... We should do the minimum necessary (enable 202 with empty response for req/resp) and move on

<dhull> Right now we don't have an answer for, say SOAP/XMPP <message> or pub-sub

Marc: DaveO, you said MEP isn't adding much value.

DaveO: In terms of dealing with responses, yes.

<cferris> DaveH, why do you say that?

<cferris> what is preventing the SOAP/XMPP crowd from defining their binding and/or MEP?

Marc: Given underlying one-way transport, if I send anonymous replyto with one-way (in-only WSDL), that's fine because there's no application level response
... So it seems what you need to know at both sides is the binding capabilities and the MEP

Glen: What MEP?

Marc: application MEP, WSDL MEP, whatever
... how can you say MEP isnt important?

<dhull> So, if I just want to send you a hunk of SOAP over XMPP, by the current bindings, what do I do? As I read it, I send you a request, you send me back a reply, and I ignore it. As opposed to, I just send you a message. It's broken.

DaveO: The uber mep is just about protocol.. not about application/WSDL level

<noah> Noah's current thinking is that the key thing about DaveO's position is that he views the uber-MEP as mainly providing standard terminology that other specs can use.

Noah: timing issues are important

<noah> FWIW: Noah views that as a coherent position in principle, but not at all in the spirit of what SOAP 1.2 says a SOAP 1.2 MEP is. So, it's really important to read the spec at http://www.w3.org/TR/soap12-part1/#soapmep and to see whether we're serious about what SOAP says an MEP is. I perceive that Dave is trying to change that.

dhull: there's a lot in a binding, even a simple one. one of these things is whether there's a response or not. we only need to look at one bit.

<Zakim> dhull, you wanted to say that "looking at the binding" is too broad. We only need one bit.

dhull: "strongly" vs "weakly" isn't right... it should be "static" vs "latent" typing.

<dorchard> I haven't heard yet whether we are saying that HTTP supports "one-way" AND "request-response", OR HTTP supports request-response (where mandatory response is the protocol response)

dhull: would you have a named "isAnonymousAllowed" bit somewhere?

DaveO: in the coupling of the binding

dhull: not part of your job in the binding is to check off the meaning of that bit

DaveO: no parameter at the MEP level which the binding would fill in

<marc> but as I pointed out anon is fine if you aren't expecting a response even is the transport can't support anon

dhull: would be happier with a named thing that you could check

Noah: it's important to consider timing. how long will I have to wait is an important part of all of this.

<anish> marc -- it has to be ok. if it isn't we have a problem. since we should not say that you can't compose with ws-addr for a particular mep/binding. Given the defaults in ws-addr, anon reply-to is always a very good possibility (esp. for one-way transports)

<marc> anish: exactly

Noah: different APIs for response in 20ms and two weeks...

<anish> yes, mostly i was +1ing you with a pointer to the default impact

Noah: we have to say in what terms the protocols can support one-way. Most protos can do one way SOMEHOW, but how long do you have to wait around? FAF is "really" don't wait around.
... if we have HTTP, *something* needs to come back from the other side
... sender needs to know which APIs are available for use. Whether its an MEP or a property or whatever, we need a way to look down and figure that out.

<cferris> DaveH says that we need a "isAnonSupported" property on the MEP

<dhull> (with the "weakly typed" option)

<cferris> I think I could support that addition

Noah: Minimize changes to the Rec. We already have a binding which says you send an HTTP msg and wait for a reply. It's vague about whether there has to be an envelope there or not. So let's cover that by saying you still have to get the response (transport) from the HTTP stack, but it may or may not contain a SOAP envelope.

<marc> on the MEP or the binding ?

<marc> on the binding mebbe

<marc> on the MEP sounds weird

<herve> +1 to Noah

<Zakim> cferris, you wanted to comment on there being more than one MEP per binding

<dorchard> Here's an example, on WS-A, of how to use the properties of the mep

<Zakim> noah, you wanted to talk about timing

<dorchard> When wsaw:Async attribute has this value, then the

<dorchard> response message MAY be the response part (aka

<dorchard> http://www.w3.org/2004/12/ws-addr/mep/ResponseMessage or

<dorchard> http://www.w3.org/2003/05/soap/mep/InboundMessage) of a

<dorchard> request-optional-response or request-response MEP or the response

<dorchard> message MAY be the request part (aka

<dorchard> http://www.w3.org/2004/12/ws-addr/mep/RequestMessage or

<dorchard> http://www.w3.org/2003/05/soap/mep/OutboundMessage) of a separate

<Yves> timing issue may be a property of the MEP

<dorchard> request-optional response or request MEP.

Chris: shouldn't have multiple MEPs per binding

<Yves> and the combination will describe the API in use

<noah> I'm afraid I disagree with Chris on the multiple MEPs/binding. I think they're in the spirit of Java interfaces. Saying that one binding can do multiple MEPs and keep them straight, lets you capture the mix n match between capabilities shared and not shared by different transports

Noah, I agree

LUNCH

<cferris> let me clarify my point... the essence of the binding doesn't necessarily change based on whether you are doing a request-response or a oneway

<cferris> I think we have already covered that

<cferris> HTTP is inherently request-response

<cferris> the question is whether there is a SOAP envelope in the request or response

<cferris> in either case, you are obligated to await the response

<cferris> the thing that concerns me is that some may incorrectly (IMO) assume that because the WSDL says oneway, that there is some assumption that there will not be a SOAP envelope in the HTTP response (in the case of the SOAP/HTTP binding)

<mikem> hi chris we are about to get started

<cferris> k, dialing

<dorchard> Chris, in the case of WSDL one-way using SOAP/HTTP, I think all the proposed bindings say that there might be a response.

<cferris> in that case, it really isn't different than the R-O-R, is it?

<dhull> scribe: dhull

<cferris> brb

<cferris> back

<cferris> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0000.html

<cferris> could someone describe what glen is drawing?

<cferris> I have a little difficulty seeing it at this distance

let's wait until they decide that they want to draw

glen: I have a WSDL operation I need to connect to what I actually have. I might have a "req-resp" thing to connect to, or a one way. Need a layer in between to do the connection.

daveO: That's SOAP MEPs at the bottom?

Glen: yes

daveO: In your view you need a binding underneath

Glen: no

Noah: Underneath the boxes you have things like HTTP, XMPP iq, or UDP, XMPP msg
... you write general software that knows how to handle this e.g., request-response or FAF -- FAF means no timing issues.

<anish> FAF does not necessarily mean that there are no timing issues

Noah: Strongly typed MEPs give factoring.

just scribing, Anish

Noah: Describing strongly typed. Question for DaveO is how does weakly typed do this. To be answered.
... Application will look up endpoint and need to know "can I use this transport" "can I code to convenient API". This architecture is a factoring of what's common to transports. Under SOAP 1.2, we call this factored bit an MEP.
... Defining an MEP encourages software that uses that factoring, but doesn't force it.

daveO: Doesn't the app (doing r-r over one-way) ... you don't show the connection between HTTP and out/in. (?)

noah: So consider in-only WSDL MEP. You might come up with in-only Java API (e.g.). Where can I support that? Depending on what I want to do, in a lot of places. Could write directly to transport bindings -- easy for UDP-like protocols.
... So App doesn't have to know anything about transports. But what if it's in-only at WSDL level, but over HTTP. Could directly call HTTP, but because we have strongly-typed SOAP MEPS, can write shim between in-only (WSDL) and request-response (SOAP)
... Now have two ways of doing in-only. One over (all) request-response, one over (all) FAF, not 4 (i.e. one for each protocol)
... E.g., spinning off a thread to wait for response happens just one place.
... Clearly this doesn't have to be presented in terms of MEPS

glenD: Extend this to robust in-only (cool case), too

daveO: Don't disagree with this style of writing APIs.

noah: APIs follow naturally from strongly-typed MEPs. Good Thing.
... Also guide protocol people (e.g. XMPP) as to what things to support. If you can happily implement an existing MEP, good chance you can just plug in. If you have troubles, then you know you probably won't "just work". Can define new MEP that works for you and others can leverage that.
... Wrapping up suites of function in bulk encourages operability. 95-5 case. Just like read/write/open/close. Most code shared, occasional special case.

<cferris> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0000.html

chris: Put link into IRC of email to dist-app.

chis: Wanted to respond to discussion before lunch break. Appreciate point Noah makes about APIs. Perhaps I was making too fine a distinction, but ...

chris: have to consider with the SOAP MEPs we're considering don't have a binding that supports multiple MEPs, but multiple bindings. Even in case of WSA anonymous response endpoints, SOAP faults (mU, version) must be generated before WSA processing.
... WSA headers are just qnames at this point. There is always case for SOAP envelope back on response channel. So maybe we can do that and layer on other MEPs. Unless you have done something different in binding (e.g. HTTP header that says no response), can't really support one-way over HTTP.

Glen: this is already agreed.

Noah: He's responding to an IRC comment I made.

chris: unless you're changing behavior of underlying protocol, not safe to layer one-way over req-resp.

<marc> so, to cut to the chase Chris are you saying that we just make the response optional and we are done ?

chris: In case of response MEP, it's a separate binding. Rules are different, different HTTP verb (GET vs POST). Layering one-way over request-response is changing the underlying binding. Unless communicating through binding (in non-SOAP way) what MEP is in play, then can't support multiple MEPs.
... In r-o-r, fault will come back, can't mask out.

SOAP mU fault etc. => transport failure.

DaveO: by Noah's argument, we would have no one-way software without one-way MEP. For eons. Our providing one-way MEP won't help.

Noah: They're going directly over UDP and tracking distinctions themselves. Otherwise going over HTTP.

DaveO: Going over HTTP, SMTP, JMS

Glen: Don't deny benefit to software construction, but also helps other spec writers.
... Mapping of in-out to FAF is valuable per se (?)

DaveO: Main point is helping people write specs. Don't buy help to constructing software.
... Data available to spec writers is important.

<cferris> marc: yes

Noah: Already made the choice of style (to use MEPs). This extension is a small bump on what's already there. Like tweaking a class or two, not changing object structure.

DaveO: Not what I meant

Noah: This is how it's coming across to me. Structurally r-o-r (and maybe adding FAF) is a small change.

<cferris> +1

GlenD: Would not go into HTTP binding.
... If you need to know what MEP is action, need to do it before SOAP

Yves: Who needs to know

Glen, Noah: Everybody

DaveO: My point is, you're right. Who needs to know. Strongly-typed MEPs doesn't help, actually confuses issue. You need to look elsewhere.

GlenD: We think each others arguments are specious. Obviously a misunderstanding. Let's solve the disconnect.

glen draws some more

<Zakim> cferris, you wanted to finish my thought that IMO, with the current state of affairs, leaving aside the fact that people aren't doing SRR as written in today's REC, that few are

chris: picking up train of thought ... leaving aside that people are not doing req-resp as written, few are doing SOAP response. Really are two different bindings. Can't use SOAP response with any given endpoint. Nothing in spec says must support both of them.
... Maybe can make some abstractions and describe differently in terms of MEP supported by same binding, but really there are special properties supported by bindings and not envelope, or you don't have support for multiple MEPs per binding.

<noah> I think that in the particular case of the HTTP binding, the spec says you DO have to support both MEPs, BUT (important caveat coming).

<noah> It doesn't require you to respond to a get or a post for any particular URI.

<Zakim> dorchard, you wanted to point out that if "one-way" meps helped build software, we wouldn't have any one-way software because we don't have a one-way mep yet.. and to

<noah> So, you can in fact legally write a binding that says "no" to a get on any particular URI.

<cferris> checking

glenD: (describes picture) You have an HTTP binding with Req/resp and SOAP resp, plus other properties (proxy? HTTPS). At this level doesn't matter that it's HTTP. HTTP-ness is encapsulated. MEP specs are exactly what the rest of the world deals with.

<noah> I think RFC 2616 lets you send a status code for "don't do that op on this URI", no?

<cferris> yes

<cferris> 415 METHOD NOT SUPPORTED

<noah> QED?

<cferris> ok (wise guy!)

<cferris> too tired

<noah> I do think the business of figuring out what you're doing in the case that there is more than one is indeed an important and dangerous aspect of the design.

<Yves> 415 is unsupported media type

GlenD: When you have this picture (leading in to strongly-typed case) Suppose some software has 50 bindings underneath, and somehow we select one. Each binding is black box. Features and properties are exposed. That's MEPs and other features and props.

<Yves> 405 is method not allowed

<noah> We got lucky on HTTP, I think.

<cferris> 405?

<noah> Checking

GlenD: So if I'm doing an in-out, and I see I have request-response available from my binding, my middleware knows how to bind it.

<cferris> brain cramp

<cferris> what's up (down actually) with w3.org site?

<noah> 405 Method Not Allowed

<noah> The method specified in the Request-Line is not allowed for the

<noah> resource identified by the Request-URI. The response MUST include an

<noah> Allow header containing a list of valid methods for the requested

<noah> resource.

Glen: Suppose I have another binding, that just exposes one-way MEP. If I have to do an in-out on top of that, I know I use WSA and build in-out from it. Value of strongly typed is that I can have layers like WSA that know how to map to SOAP message exchanges without knowing anything about binding (box) except that someone selected it (e.g., via WSDL)
... Can you explain this in terms of weakly-typed, or show problem with this. It seems you have to look inside the boxes.

<noah> Chris: I think we're all pretty impressed with the fact that you got up at 3AM for this!

DaveO: There is no consensus whether, if strongly-typed approach is adopted, HTTP would supporte two or three MEPs.

GlenD: who believes what?

<cferris> :-)

GlenD: Noah, Glen, DaveH think no.

DaveO: If FAF is there, and doing an in-only, can just use one-way MEP.

GlenD: But not a good idea. You would need to say something more on the wire if HTTP does both.

DaveO: Neither choices is good. Adding one-way adds confusion from need to differentiate on wire.

GlenD: Not hard to do, if you want to do it.

<cferris> hmmm

<cferris> guess it could be my broadband provider network that is the problem

<Yves> hum, maybe try www.w3.org instead of w3.org

Anish: Chris has argued that because of mU processing, have to allow faults to come back. Otherwise have to prohibit on wire (e.g. HTTP header). Another reason to do that anyway is that our binding is not only possible HTTP binding. In fact, PAOS is also an HTTP binding (over SOAP 1.1).

<Yves> might be the redirecter on w3.org

omnes: PAOS uses HTTP headers to identify itself

GlenD: unfortunately, we don't provide marker. So we're default.

<cferris> I saw this last week too

Anish: We have a chance to fix this. This is not *the* HTTP binding. Would be nice to define header as marker, defining binding, MEP or both.
... Can do this now.

<cferris> so, Noah, if I understand what you are going to say (I can read minds), then you are arguing for the requirement that IFF a binding supports multiple MEPs, then each MEP MUST (SHOULD?) distinguish itself in a manner that is specific to the underlying transport/transfer rather than via SOAP?

DaveO: Challenge I put out is that there is not consensus. How many MEPs depends on how you look at it. If HTTP supports both r-r and faf, receiver has to distinguish.

GlenD: But that's not the pictureI'm talking about. How do you resolve the same question (of what protocol can do) in weakly-typed version?

DaveO: Binding exposes uber-MEP.

GlenD: Just what does it expose?

DaveO: Exposes the properties.

DaveH: What props?

<cferris> Noah, you are correct, the spec DOES say MUST support BOTH MEPs... interesting

DaveO: Reuqest msg, response mesg. destination etc., as described in proposal.

<cferris> I stand corrected, thanks

DaveO: Suppose you're using HTTP. Binding says how props go into MEP. E.g., request message goes into InboundMessage (?)

GlenD: How does app know what binding can do?

DaveO: Binding says how to put request into props.

GlenD: MEP that strongly-typed exposes has semantics.

DaveO: That's a fallacy. E.g look at WSA.

GlenD: What do you mean?
... I know that *something* is going to come back. WSA doesn't affect that. Take "request-response" to mean "request-opt-response"

DaveO: S.T. approach says you're going to look ahead and build your app based on bindings
... App picks binding, knows what's going to happen. App knows by what binding it picked what will happen.

Naoh: Whatever you call them, the ST picture tries to capture suites of functionality. I believe what you're doing is just standardizing names, not behavior. Commonality between bindings is an emergent property.

DaveO: IMO the advantage of W.T. is that props are exposed. When we wrote WSA SOAP binding, it was the same properties, regardless of anon or non-anon reply.

GlenD: But what we say in WSA SOAP binding is that anon response will be part of same SOAP MEP instance. With W.T. that would have to care whether you're using HTTP or whatever.

DaveO: No, no change. Uber MEP is request-response MEP. It has a request bucket and a response bucket.

DaveH: How do you know you shouldn't use anon for UDP e.g.

DaveO: If you have an anon value, you'll get response from current instance of Uber MEP. Non-anon means two instances of Uber MEP.

marc: A coherent answer would have been, no OutboundMessage property in binding. If it has OutboundMessage, how do you know it's never populated?

glen: and if you do know, how is that different from strong typing?

DaveO: The way the software will know whether anon response endpoints are allowed will depend upon the protocols supported.

Noah: So two XMPP bindings had better have the same behavior.

Anish: So you mean binding, not protocol.

<cferris> mikem, I'd like to chime in

<cferris> the people in the room have been dominating the discussion

Noah: So if I have a new "Dave's binding", how do I tell, given just the name, what to do. Seems like I have to ask a person.

DaveO: Question is how parameterized are these.

Chris: Want to shift discussion to what it is about Noah's proposal that would preculde correct impl.

GlenD: I.e., who can't live with it and why

Chris: Yes.

<cferris> would addition of a requirement in the spec (part 1 I think) that said: "an MEP MUST be explicitly manifested in the SOAP binding IFF there are more than one MEPs that are supported" address some people's concerns?

<cferris> 04 01would addition of a requirement in the spec (part 1 I think) that said: "an MEP MUST be explicitly manifested in the SOAP binding IFF there are more than one MEPs that are supported" address some people's concerns?

<noah> No.

<anish> i would add manifested in the protocol part

<anish> not the soap env

GlenD: What does that (chris's question) mean?

<noah> The reason I don't like this, is that it doesn't provide the key function: if two bindings support the same single MEP, then neither is documenting that it does. What am I missing?

chris: In current (HTTP) case, it's the web method

<anish> ... and given that MEPs are already identified by URIs, this is easy

<dorchard> something like an http header that says "response optional"?

<cferris> actually, I was not thinking that you need anything like: response optional... I think that Noah's proposal handles things nicely

GlenD: Don't need to go there right now. There is a minimal solution we can do -- ratify what impls do anyway, make WSA, WSDL 2.0 happy, handle robust in-only, without a lot of extra work. Would make me happy

anish: Need to deal with it in any case (?)

Noah: Do we need an exact proposal now?

<anish> perhaps we need two things identified in the protocol: the binding URI and the MEP URI

Noah: If it's helpful to go into this, we can. Like Glen would prefer to ask how close are we to big-picture consensus answer. I know Chris offered this to be helpful, but I don't need to do it to be heard.

Chris: In response to your point in IRC: my point was not to document that a particular MEP was in play MEP must be distinguishible when more than one supported.

<marc> we either need to have a single HTTP binding and identify the MEP in use or have multiple bindings (one per MEP) and identify the binding in use or some combination of the two

Noah: What you said was self-evident, we should say each binding names URI of MEP it supports. If you think something's broken, we can debate it. Otherwise don't need to discuss it.

Chris: just offering to move toward consensus.

<anish> marc, given that we can't someone from creating another http binding, we should provide both

Chris: bringing this is as guidance to authors of bindings. You make MEP explicit through the binding. Can go without this if it's not helpful.

Anish: May need to identify both -- binding in effect and MEP in effect. Otherwise message can look exactly the same in different circumstances. Don't stop someone from defining their own HTTP binding. Would be nice to define particular HTTP header to key off of.

<noah> Anish suggests that bindings must indicate on the wire what MEP is in use at a given time. I think that's probably a good thing to have in most cases, but I think we need a longer discusion to decide whether we always need that, and I don't see settling that as being on the critical path for today.

<marc> anish, true though you could say that would be their problem to co0me up with some way to identify their new binding and (possibly) make sure its compatible with our binding in some way

Anish: Typically impls ignore HTTP headers they don't understand. Would be nice if we defined it and asked binding authors to use it.

Yves: Not every impl will read this, so still can't rely on it. (no mU)

Noah: Do we need to go here?

Omnes: No

GlenD: Can do this later.

Anish: Yes.

<noah> Strong +1

Yves: Might be nice to signal version in use.

GlenD: Chris & Anish take action to work up proposal?

Anish: yes

Chris: Wouldn't oppose this. Personal opinion is don't need to distinguish, say, r-o-r and one-way, that's actually bad.
... Will take action item, yes.

Yves: Not differentiating bindings, not MEPs.

Noah: Need at least on proposal phrased pertty formally.

Anish: Straw poll?

Noah: First set down a clear proposal to poll on.

Mike: How do we expose this.

<Yves> Agenda: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Feb/0030.html

GlenD: Noah's email is well-formed, all bows tied up.
... DaveO, you have same?

DaveO: Yes, taking addendum into account.

<mikem> Noah proposal: http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html

GlenD: If there's a strong leaning one direction, can address objections or work up further details.

<dorchard> Here's the "uber-mep" http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0007.html

Noah: My proposal is roughly SOAP 1.2 with these deltas (no changes to defn of MEP, no getting rid of state manchines -- that's orthogonal).
... Clarify optional response in r-r, with 202 in HTTP. Recognize request for development of one-way fire-and-forget for protocols in which no signalling through the network is needed at time of sending (i.e., buffering for sending is enough)
... i.e. clarify that SOAP envelope is optional in r-r.

DaveO: Does 202 allow an envelope?

Noah: Not as I've drafted it. Never chooses to use it. Signal as to whether you got an envelope is 200 vs. 202.

Anish: HTTP allows entity body in 202.

Noah: Would be misuse from HTTP point of view. Not hung up on it either way. Note at higher level that MEP is request-optional envelope response. What do you want to put there?

GlenD: WS-RX acks.

Noah: That's just tunneling. I think that's a misuse of HTTP.

DaveO: Uber-MEP proposal more elegantly deals with 202 issue, whether envelope is allowed other than for app response.

Noah: Think it's really screwy architecturally, but strongly-typed MEP could be edited to accommodate that.

<cferris> I disagree that sending a WS-RX Ack as a 202 entity body is an abuse of HTTP... to say that the message is unrelated is IMO, not the case. It is related by virtue of the RM Sequence

DaveO: <didn't catch>

<cferris> to say that a SOAP envelope carried as a request only applies to the content of the SOAP body isn't correct IMO

Noah: If it's a common pattern across protocols, write it up in MEP. If it's just an HTTP thing, don't put it in MEP, it's a binding-specific feature (also allowed)

DaveO: There's a big dragon there in terms of strongly-typed MEPs.

<dorchard> I pointed out that a soap envelope in the http response might not be the "response" of a SOAP request-response MEP, and that's a problem with the strongly typed MEP approach.

Noah: It's a design call whether to put it in MEP or in binding-specific. Kind of like IOCTL. Certainly is ugly.

cheers, Dave

Anish: Do we need to figure out all the details to get consensus on general direction?

Noah: One other complicating factor: SOAP MEPs are supposed to tell you what to do with faults. 202 may mean "didn't want to run SOAP processing model yet" (so no fault will come back), or it may mean that SOAP processing has happened, but we're not done (so faults could come back).
... MEP tends to say fault should come back to sender. In WSA world there are issues of where and when to direct faults.

Some faults are very much like transport failures (e.g. host unreachable)

Anish: 202 is intentionally non-commital
... Can get fault back on 202.

Noah: But that's a definitive problem (200).

GlenD: But what about robust in-only. Does 202 mean no fault happened, but one might happen later.

<cferris> can I gat a word in edgesise?

<cferris> edgewise

DaveH: Went over all this in async TF. It all fell out.

Noah: I believe proposal we're voting on says that, at the MEP level, if there is an error in the request, the fault will come back to the requestor.

GlenD: In the absence of any other extensions.

Noah: SOAP req-rep MEP says if there is an error in request, SOAP fault will be generated, sent back in place of reply. That's the problem.

<cferris> what I hear Noah saying is that for the use case of ws-rx that [fault endpoint] MUST be non-anonymous

GlenD: Not a problem. WSA can override.
... There is a stack of stuff above at both ends.

Anish: True for req-rep, but we're defining a new MEP

Noah: No, clarifying an existing MEP.

<Zakim> noah, you wanted to talk about dynamically choosing MEPs

Noah: In part because implementors have gone this way.

<cferris> ahem

<cferris> *cough*

Yves: We have a way to use 204 to say no response. Quite different from 202, which says nothing about processing.

Chris: Think there will be issue in WS-RX to discuss this issue, whether it's a 202 and how much SOAP processing has to happen. My opinion: if doing reliable messaging, have to do SOAP processing, at least upto a particular point.
... have to figure out mU and which ones you can do if you're doing any reliable mesging at all. You could have an interchange with 202, but you would never get an mU fault. Flowing acks back on response is related to processing of message.

<Yves> mU (so fault) and 202/204 deals with the no processing/mU check | processing/mU check

Chris: Probably do need to clarify (in WS-RX?). Want to come back to discussion after break. Is Noah's proposal close enough to take that direction and declare victory. Who has heartburn. Seem to be off in weeds now.

Anish: Just making sure everyone understands the proposal. There are some gray areas t odeal with later.

Chris: Cant' sort them out here.

Mike: In violent agreement here.

Anish: Dont' quite agree on 202 but will sort out later.

<noah> From: http://www.w3.org/TR/soap12-part2/#bindfaulthdn

<noah> "If a SOAP fault is generated by the responding SOAP node while it is in the "Receiving" state, the SOAP fault is made available in http://www.w3.org/2003/05/soap/mep/OutboundMessage and the state machine transitions to the "Receiving+Sending" state."

<anish> chris -- i think it is fine for wsrx to say that when sending back 202 make sure u do the mU processing, but I don't want to say that in the general case

DaveO: In terms of S.T. proposal, what goes on at receiver when WSA message is sent in in-out, replyTo implies separate connection, e.g. an SMTP connection.

<anish> ... cause I have usecases where it is truely doing queue, without checking the soap message and I would like to enable those cases

DaveO: Is that two instances of req-rep? Do I shut down and switch MEPs.

<anish> chris -- daveo is drawing a diagram on the whiteboard

<cferris> I hope someone is capturing the drawings and can possibly inline them into the minutes since I think that they will be valuable

DaveH: Will always have one instance of r-o-r/HTTP for this example. Separately, another MEP for reply; r-o-r or FAF depending on transport used for reply.

DaveO: ReplyTo will have http:, or smtp: or whatever, telling it what to use. Then has to pick MEP.

Noah: This is a feature. If smtp, send message and disappear. If http, has to send message and hang and wait. S.T. approach tells responder its responsibilities.

DaveO: There's no info ahead of time.

Noah: You know in advance there are only two code paths, regardless of how many protocols you actually support.
... Proposing note 50 + promise of future FAF MEP.

<anish> i would rather call it one-way mep than faf mep

<noah> My proposal is roughly:

<cferris> DaveO, if you are saying that an EPR can't communicate the characteristics of the MEP, then I would agree

Noah: My proposal is roughly SOAP 1.2 with these deltas (no changes to defn of MEP, no getting rid of state manchines -- that's orthogonal).

disregard that

<noah> 1) Take the existing req/resp MEP, make clear that envelope in response is optional, signal lack of envelope with 202, and update http binding to match. THat's in draft linked from http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html

Noah: My proposal is roughly SOAP 1.2 with these deltas (no changes to defn of MEP, no getting rid of state manchines -- that's orthogonal). Clarify optional response in r-r, with 202 in HTTP. Recognize request for development of one-way fire-and-forget for protocols in which no signalling through the network is needed at time of sending (i.e., buffering for sending is enough) i.e. clarify...
... that SOAP envelope is optional in r-r.

(previous is pasted from previous minutes)

<noah> 2) Prepare a one way fire & forget MEP, making clear that this is for use with protocols in which you do not have to wait for network acknowledgements before proceeding at the sender site

<dorchard> Chris, that's roughly right. I think that the strongly-typed meps don't help the recieverr because it does it's determination of connections based upon the EPR, and 2 meps vs 1 mep doesn't do anything for it.

<cferris> so, you are suggesting, for instance, that the HTTP method should be communicated in the EPR?

<cferris> for the case of an HTTP-based response endpoint?

<noah> 1) Take the existing req/resp MEP, make clear that envelope in response is optional, signal lack of envelope with 202 and/or 204 as appropriate (TBD if this proposal is accepted), and update http binding to match. THat's in draft linked from http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html

<noah> 2) Prepare a one way fire & forget MEP, making clear that this is for use with protocols in which you do not have to wait for network acknowledgements before proceeding at the sender site

<Yves> chris, if EPR were about adding informations to the URI like the protocol context (HTTP verbs, some context headers), I would have bene happy with EPRs

Mike: Poll -- Who agrees this is good direction?

Chris: Agree, but want to know form of (2). Addendum or separate rec-track doc?

Noah: Haven't thought it through. People (e.g., DHull) have repeatedly asked. Want least overhead in process, minimal pain for rest of SOAP.

<Yves> btw 202 vs 204 may be seen as faf vs non faf one way (or ror)

Chris: Step 1 could be errata, but 2 is too big for this.

Mike: Notes vote was 9-1.

Noah: 2nd addition means nothing more than errata? Can we add MEP?

Yves: If it's just clarifying material.

Noah: That's a big stretch.

<noah> Noah proposal: if it can't be second edition, then SOAP 1.2 Part 3: additional MEPs and Features

Chris: +1. Considering rec track proposal (?). Think this affects my vote.

<dorchard> You'd have to do the new MEP in a Rec track as there's no CR results for it as an errata

Chris: Concerned this will take so long as to become irrelevant.

<noah> So, do part 1 in SOAP part 2 2nd edition, and put the new one-way MEP in a new Part 3, which would have to go through CR

Chris: Not in favor of both at same time.

Noah: Would have to go through CR.
... Don't want SOAP 1.3. What about SOAP 1.2 part 3.

<cferris> +1

<marc> +1

<Yves> +1

<herve> +1

DaveH: Friendly amendment: Note with (1) that this is not the answer for datagram protocols, this is to come in work for (2).

<Zakim> anish, you wanted to ask if we need to decide on the entity body of 202 to get a consensus on the direction and to respond to chris' comment

Noah: Fine [in fact, Noah actually proposed it]

<cferris> works for me

Mike: Formal vote?

Noah: Should we continue to work for consensus since there isn't one yet?

DaveO: It's time to decide.

GlenD: You want objection noted?

DaveO: Want complete victory, but that's not going to happen. WG has given my proposal considerable amount of discussion. Given that no one else has come on board, time to move on. Appreciate opportunity to champion decision, but time to move on.

Mike: Separate issue is Dave's new style (no state machine) for new work.

<dorchard> I should say, I would have liked to have convince the WG of the uber-mep approach, but that doesn't appear likely given more time. I thank the chair and the WG for the opportunity to champion it. We should have a vote on the issue and proceed.

Mike: Formal vote by company

RESOLUTION: Parts (1) and (2) as minuted above. Formal vote: Yes: IBM, Nokia, Sonic, Canon, Sun, Oracle, W3C, TIBCO. No: BEA

Note: (abstentions: none)

Mike: Straw poll: Amendement for part (2) above, use simplified MEP description style

Note: simplified MEP style for new work

Mike: 9 yes 1 abstain

<dorchard> For the record, I'd be glad to do editorial work on any one-way work.

<cferris> abstain means you are going along with whatever the group decides

<Yves> (just for the record) 204 may be better than 202, and 202 reserved for "true" one way

<cferris> lol

Noah: I will take responsibility for MEP and binding-related stuff. My intention is not to do much in the next few days as we debate things like 202/204. Assume that's the base text, I'll take a pass when debate dies down. Will make sure this gets into a copy with other errata.
... Hoping this is a small amount of work.

<cferris> can we be clear that the step 2 of Noah's proposal is JUST the MEP and that we are not doing an HTTP binding for that?

<anish> chris, i think that is clear

<cferris> ok, just checking

<cferris> I think I misunderstood the bit about 202/204 as relates to "true" one-way

<Yves> I meant without a backchannel for faults

<cferris> I don't think that is what we are doing

<cferris> we are doing R-O-R

<cferris> there is a back-channel

<Yves> so as rr impliues backchannel, 204 is more suited

<cferoris> in terms of the one-way MEP, then there is no backchannel

<Yves> so 202 looks more like one-way as there is no backchannel

<cferris> 204 means "no response", 202 means "accepted, not processed" 200 means processed, but IMO it does not mean that the response is THE application-level response

Mike: Need to capture how we're going to publish this.

<cferris> because "processed" might mean, queued for processing

<noah> URI for instructions for running scribe.perl: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

<noah> URI for scribe.perl itself: http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/

<Yves> we can talk about the semantic of 200/204, but 202 really means that no processing happened

<Yves> so no mU were checked

<cferris> yes

Note: We will not produce an HTTP binding for one-way MEP in (2).

<noah> URI for scribe.perl itself: http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribe.perl

Anish: Issues -- 1) Fire and Forget implies something not true in every case, so what do we call it? 2) What timing issues are there?

<cferris> we call it Fred

Anish: Still need to discuss issues, now that we've decided overall direction

DHull: Will part 3 have its own issues list?

Mike: Yves?

Yves: Can reuse existing list.

Anish: Issue 3) (Yves) 202 vs 204 4) possible HTTP header signalling binding, MEP

Mike: Actions, ownership:

<noah> Noah is a bit worried about (a) whether having HTTP headers for the MEP is actually a good idea (b) even if it is in principle, I want to be careful about anything that would take us back through CR and (c) I want to watch for interop issues with the existing binding.

<noah> Anish: regrets for next two weeks

<scribe> ACTION: Anish to start email discussion of what does FAF really mean? [recorded in http://www.w3.org/2006/03/04-xmlprotocol-minutes.html#action03]

<scribe> ACTION: Yves to start discussion of 202 vs. 204 [recorded in http://www.w3.org/2006/03/04-xmlprotocol-minutes.html#action04]

<scribe> ACTION: Marc to start discussion of possible HTTP header signalling binding/MEP [recorded in http://www.w3.org/2006/03/04-xmlprotocol-minutes.html#action05]

<cferris> could I request that people identify emails in the archives for which they think identifies any substantive points related to the part3 spec so that the editors don't have to wade through every one of them?

Note: What does FAF mean and what timing issues are there are actually the same issue (actioned to Anish)

<noah> My key points are effectively in the resolution:

Chris: Could people please provide pointers to key emails in previous discussion of "what does FAF mean" issue.

Mike: This seems part of starting email discussion.

<noah> 1) Timing is an issue. In particular, the MEP should NOT be used for transports on which you have to wait for actual network traffic before proceeding at the sender.

<noah> 2) Therefore, this MEP is mainly for datagram-like protocols.

<noah> Chris, those two points are my main input.

Mike: Meet a week from Wednesday?

Omnes: General approval.

<anish> noah, what MEP would you use for queueing/messaging/jms?

<anish> that is where it gets tricky

<cferris> thanks, noah

Mike: Next meeting March 15

Noah: I believe my draft is a useful starting point. Group should read it keeping in mind that this should be headed quickly toward Rec.

<scribe> ACTION: Noah to suggest how the group should proceed in reviewing draft (suggestion will probably be what I just said) [recorded in http://www.w3.org/2006/03/04-xmlprotocol-minutes.html#action06]

Mike: Anything else?

Omnes: No.

<cferris> DaveH, did you mean Noah instead of Mike in reference to "my draft"?

<cferris> ciao

<anish> cya

Mike: Adjourned

<cferris> or should I say au revoir

- DRAFT -

XML Protocol Face-to-face, Mandelieu, France, 3/4/2006

4 Mar 2006

Attendees

Contents

1. Action Items

2. SOAP PER status

3. One-way SOAP messaging.

Summary of Action Items

Scribe.perl diagnostic output