08:09:55 RRSAgent has joined #xmlprotocol 08:09:55 logging to http://www.w3.org/2006/03/04-xmlprotocol-irc 08:10:33 mikem has joined #xmlprotocol 08:14:01 agenda http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Feb/0030.html 08:14:42 topic XML Protocol F2F 08:14:58 kraatika has joined #xmlprotocol 08:15:40 noah has joined #XMLProtocol 08:16:02 kraatika has joined #xmlprotocol 08:16:21 cferris has joined #xmlprotocol 08:16:32 dilaing in shortly 08:16:44 just making coffee, etc 08:16:53 have we started? 08:16:56 not yet 08:16:58 good morning Chris :) 08:17:02 hardly 08:17:05 heh 08:17:17 Perfect time for an MEP discussion, eh? 08:17:24 mwahhahaha 08:18:06 Make sure to invite the dog to the telcon too 08:23:44 Team_(foo)08:21Z has now started 08:23:51 +Chris_Ferris 08:23:56 in 08:24:31 and yes, the dogs are here 08:24:36 :-) 08:24:41 Hi Chris! 08:24:46 Hi Noah 08:26:31 Iles 'A' 08:28:53 +TP_Iles_A 08:28:59 marc has joined #xmlprotocol 08:30:47 Scribe: GlenD 08:31:20 Meeting: XML Protocol Face-to-face, Mandelieu, France, 3/4/2006 08:31:33 dorchard has joined #xmlprotocol 08:31:40 Chair: Mike Mahan 08:32:30 dhull has joined #xmlprotocol 08:33:01 Topic: 1. Action Items 08:36:01 Agenda: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Feb/0030.html 08:36:49 - Draft web page describing SOAP MEPS. DONE see http://lists.w3.org/Archives/Public/xml-dist-app/2006Feb/0028.html 08:37:35 does the page need a status? 08:37:39 Mike: should we publish this? 08:37:46 All: yep 08:38:42 q+ 08:41:08 anish has joined #xmlprotocol 08:41:21 (discussion of why to use frag-ids in the URL for MEPs) 08:44:28 ACTION: Yves to check the HTML and publish the MEP document. 08:44:31 http://lists.w3.org/Archives/Public/xml-dist-app/2006Feb/att-0028/ClassOfMEPs.html 08:45:37 - Clarifying fault generation 08:46:00 Noah: We discussed this inline, should be in the appropriate minutes. 08:46:16 Mike: We needed to open a new rec issue? 08:46:32 Yves: Should check... yes, this is REC issue 41 08:46:40 Mike: Put this in errata 08:47:14 ACTION: Noah to take proposed text for fault generation and insert into errata doc. 08:47:48 ACTION 2=Yves to take proposed text for fault generation and insert into errata doc. 08:48:29 Topic: 2. SOAP PER status 08:48:54 (nothing to see here) 08:49:10 Topic: 3. One-way SOAP messaging. 08:49:26 Mike: Goal for today is to come to a conclusion on how to resolve this one. 08:50:26 Mike: Fairly clear proposals... Let's discuss the new mail threads (if any need to do so) then really dig in? 08:51:06 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? 08:51:30 ...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. 08:51:34 q+ 08:51:41 q- 08:52:12 q+ 08:53:06 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... 08:54:19 Glen, actually, I would hope that the wsdl would have nothing to do with it AT ALL 08:54:30 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.... 08:54:51 +1 to chris, at the SOAP level we don't even know that WSDL exists 08:55:06 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 08:55:12 weird 08:55:19 q+ for DO 08:55:21 I think that is a Notes feature 08:55:23 but we can define things with the hope that wsld exist :) 08:56:19 i get a error 500 08:56:28 DaveH: I think we're not really doing a good job (i.e. much at all) to help out with other bindings 08:57:10 DaveH: 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 08:57:44 anish, see http://www-128.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=440&entry=107924 08:57:51 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. 08:58:23 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. 08:59:09 +1 08:59:43 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).... 09:01:15 Noah: I'd almost rather go and work through the examples first and then allow that to bring up the conversations like strongly/weakly... 09:01:18 q? 09:01:24 q- 09:02:10 Noah: Proposals differ in various ways, incl. how we change the spec, how many documents, etc. We need to track all these dimensions. 09:03:26 Mike: if we could pull the discussions into the overall framework of laying out the proposals/examples, then I'm good with that. 09:03:33 Marc: okee 09:03:40 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. 09:03:56 q? 09:03:58 q- 09:04:05 q- 09:04:23 zakim, who is here? 09:04:23 On the phone I see Chris_Ferris, TP_Iles_A 09:04:24 On IRC I see anish, dhull, marc, cferris, kraatika, noah, mikem, RRSAgent, Zakim, GlenD, herve, Yves, Loggy 09:04:26 TP_Iles_A has Noah, MikeM, Glen, Herve, DaveO, Marc, Anish, Yves, DavidH 09:05:15 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. 09:05:45 q+ to talk about non-WSDL scenarios 09:05:57 q+ 09:06:01 q+ 09:06:58 Glen: can we start be agreeing on what we're going to do? 09:07:12 DaveO: Need to update my examples a little, but I think maybe we should start with those. 09:08:44 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). 09:09:34 q+ to comment on SOAP/XMPP 09:09:47 ... 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. 09:09:59 ack noah 09:10:00 noah, you wanted to talk about non-WSDL scenarios 09:11:55 -1 to Glen's point about use of SOAP MEP URI in WSDL 09:13:24 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 09:13:47 Chris: WSDL shouldn't talk about MEPs 09:14:10 Chris: When you toss in WSA, that screws everything up 09:14:26 q+ 09:14:47 q- 09:16:21 (brief discussion about who was saying what) 09:16:47 Glen: I do think that WSDL should have a way of talking about what SOAP MEP(s) to use 09:17:34 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. 09:18:04 Noah: 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. 09:18:08 Glen: Not quite right 09:18:51 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) 09:19:00 Chris: (woof woof) 09:20:10 q? 09:21:01 ack Glen 09:21:03 q- 09:21:08 dhull, you wanted to comment on SOAP/XMPP 09:22:10 http://lists.w3.org/Archives/Public/xml-dist-app/2006Feb/0022.html 09:22:18 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 09:22:59 q? 09:23:09 q+ DOrchard 09:23:54 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. 09:25:10 DaveH: 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. 09:27:02 dorchard has joined #xmlprotocol 09:27:08 DaveH: 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. 09:27:28 q? 09:27:43 q+ To talk briefly about XMPP 09:28:32 q+ to say that we should make a decision today and not extend the f2f till tomorrow 09:28:33 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. 09:29:37 DaveH: I want to hear it if you've got a killer app for weakly. Curious as to how it answers my questions. 09:31:11 Noah: We all want to get this stuff out on the table, maybe not so much one-one... 09:32:30 Noah: 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... 09:32:41 +1 09:33:30 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. 09:34:14 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. 09:36:41 DaveO: 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. 09:36:54 q? 09:37:32 q? 09:37:35 q- 09:37:36 Yves: Should focus on a small set of MEPs and map to the most frequently used transports 09:37:45 q+ BREAK 09:38:13 Anish: Let's not extend this to Sunday (was Dave serious?)...! 09:38:26 I wasn't serious about Sunday.. 09:38:48 DaveH, I have read your message and I like it btw... 09:38:57 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. 09:39:58 Anish: I don't find req * / resp * (ultra flexible mep) to be very useful. 09:40:09 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.. 09:40:24 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) 09:40:55 Anish: Anything that gets my use-cases done is good with me. Seems like our proposals thus far mostly do this. 09:41:15 q? 09:41:18 ack do 09:41:20 ack anish 09:41:20 anish, you wanted to say that we should make a decision today and not extend the f2f till tomorrow 09:42:10 ack B 09:42:17 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. 09:42:24 BREAK - back at 11:10AM Cannes time 09:42:36 -Chris_Ferris 09:42:45 -TP_Iles_A 09:42:47 Team_(foo)08:21Z has ended 09:42:48 Attendees were Chris_Ferris, Noah, MikeM, Glen, Herve, DaveO, Marc, Anish, Yves, DavidH 09:53:06 pauld has joined #xmlprotocol 09:53:17 rrsagent, where am i? 09:53:17 See http://www.w3.org/2006/03/04-xmlprotocol-irc#T09-53-17 10:00:13 noah has joined #XMLProtocol 10:08:36 noah has joined #XMLProtocol 10:10:44 I can't dial back in 10:10:52 conference is restricted 10:14:46 I'll check now 10:16:24 yoo hoo 10:16:29 are we back yet? 10:16:32 I couldn't dial in 10:16:49 Scenarios are at http://www.pacificspirit.com/Authoring/async/async-scenarios.html 10:16:55 WS_XMLP(TP)4:00AM has now started 10:16:55 +Tp_iles_a 10:17:25 +Chris_Ferris 10:17:25 ah 10:17:26 -Chris_Ferris 10:17:27 +Chris_Ferris 10:17:32 why did the coe change? 10:17:40 why wasn't it just the usual code 10:17:43 And the ones that I think are v. worthwhile are at http://www.pacificspirit.com/Authoring/async/async-scenarios.html#twoway-inout 10:17:54 because the call was schedules at 10am instead of 9, so I created a teleconference for when we started :) 10:18:04 AH 10:18:15 herve has joined #xmlprotocol 10:18:18 RESUME 10:18:21 no wonder it was on my calendar for 4 am 10:18:27 as you woke up early, if would have been a shame to say "well wait for an hour to dial" :) 10:18:34 lol 10:20:07 Dimensions to consider: 10:20:15 * how much impact on the current specs 10:20:24 * obligations and opportunities for binding authors 10:20:34 marc has joined #xmlprotocol 10:20:35 shellshear has joined #xmlprotocol 10:20:40 * WSDL description ease 10:20:52 * Functional operation 10:21:10 schepers_ has joined #xmlprotocol 10:22:29 And how I talk about descriptions can use the "protocol mep" at http://lists.w3.org/Archives/Public/xml-dist-app/2005Nov/0011.html 10:24:20 could we have some scribing here? 10:24:38 I can't see the whiteboard and I can only barely hear the discussion 10:24:57 There isn't yet much to scribe in discussion, but I'll copy whiteboard 10:25:13 Scenarios: 10:25:16 - SOAP only 10:25:20 - WSDL + SOAP 10:25:23 - Jabber 10:25:38 (Dimensions are as above) 10:26:27 Counting MEP options... 10:26:54 Noah: req/optional-resp = 1, SOAPResponse = 2, OneWay (FAF) = 3 10:28:22 Yves: we could also have req/resp(not optional), soapresponse, and one-way with a flag 10:28:41 Noah: HTTP forces particular timing (transport resp always comes back) 10:30:00 Chris: another dimension is "what are we describing"? app level or the nature of a binding? 10:31:02 Chris: 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... 10:31:56 Chris: 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 10:32:30 Chris: let's not become architecture astronauts 10:32:39 q? 10:32:41 architectural astronauts: http://www.joelonsoftware.com/articles/fog0000000018.html 10:32:44 q+ 10:32:56 Chris: fix it and make it work, move on, rather than do some architecturally "perfect" thing which might require SOAP 1.3 10:34:02 q- 10:34:55 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. 10:36:00 DaveO: Where does strongly/weakly go under dimensions? Impact on WSDL extensions? 10:36:43 Noah: Maybe we should get concrete and start with examples, discussing these things in that context? 10:37:35 q+ 10:37:37 Mike: Just getting criteria down before we start diving down 10:37:43 ack dh 10:38:09 Dave reiterates his comment above in IRC 10:38:40 So, the scenario area is http://www.pacificspirit.com/Authoring/async/async-scenarios.html#twoway-inout 10:38:49 s/Dave rei/DaveH rei/ 10:39:53 Noah: an aside - can we get these things in W3C space if we're going to continue to use them? 10:39:58 Dave: sure 10:41:24 http://www.pacificspirit.com/Authoring/async/async-scenarios.html#twoway-inout 10:50:01 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. 10:50:08 why does it care? 10:51:01 Marc: Didn't you just tell us? It's got a reply-to of anonymous or not.... 10:51:17 Dave: right, message contents trigger particular behaviour 10:51:57 (argh, apologies - "Dave" in recent scribings has been "DaveO") 10:52:42 (DaveO runs through examples) 10:59:00 DaveO: Important part is how the receiving software knows to send a 202 or to send a response envelope 11:01:29 Glen: None of this (WSDL description, wire messages) really changes based on which MEP architecture we choose.... 11:01:47 That isn't actually true, because the WSDL *might* change a little (names of MEPs) 11:02:37 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. 11:03:06 Noah: Part of what we're doing is considering how our architectures help to encourage software to be built well. 11:04:30 (back to DaveO's examples) 11:04:43 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. 11:05:15 I would like to +1 Noah's last point... SOAP describes a protocl, not the implementation 11:05:36 DaveO: Key part of this is how we write the wsa:UsingAddressing WSDL extension 11:05:48 q+ 11:06:01 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. 11:06:20 ack cf 11:08:00 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... 11:08:18 ... unclear how you factor in MEPs, and it's weird to try to put that in at the WSDL layer 11:09:26 Chris: SOAP processor should NOT know about the WSDL... 11:10:17 ... how the SOAP proc. determines if there's a response comes from ABOVE the SP, not below it. 11:10:22 (nodding heads) 11:10:56 Chris: where the response goes either gets handled implicitly (binding) or explicitly (WSA header) 11:12:27 (clarification of who said what) 11:12:53 Chris: OK, my concern isn't currently a concern, continue... 11:12:58 (DaveO continues) 11:12:59 q_ 11:13:01 q_ 11:13:04 q+ 11:16:25 if [reply endpoint] is anon, and the binding is UDP, the SOAP processor would generate a fault because there is no response channel 11:16:37 ack cf 11:17:05 Glen: UNLESS there is a SOAP/UDP binding that supports a backchannel 11:18:39 DaveO: Core question is how you know that you should/shouldn't send anonymous replyTos 11:18:56 q? 11:19:52 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 11:20:27 +1 chris 11:20:32 +1 chris 11:20:37 Background question: Does SOAP binding framework really allow any kind of messaging protocol without any assumptions? 11:21:38 do u mean trasport protocol? 11:21:40 there are some assumptions, e.g. it must be able to serialize an infoset, send it somewhere and then reconstitute it 11:22:08 DaveO: One-way app message is OK in either case (one way or two way underlying) 11:22:34 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 11:23:34 q+ 11:23:39 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" 11:24:27 DaveO: Weakly typed has a single MEP and you know whether you can use anonymous by knowing the BINDING 11:26:18 DaveO: 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 11:27:41 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. 11:27:57 q+ 11:28:32 q+ to say that "looking at the binding" is too broad. We only need one bit. 11:29:23 Noah: Dave is looking at the binding and saying "do you have the supportsResponse property" as opposed to looking at an MEP 11:30:07 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. 11:30:55 DaveO: 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" 11:31:29 IMO, the wsa:UsingAddressing should only be a key that says that addressing is supported 11:32:56 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) 11:33:16 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) 11:33:38 good! 11:33:39 yes we did marc 11:34:00 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. 11:34:01 and what about all the asynch stuff? out? 11:34:02 I thought we agreed that some time ago 11:34:51 (Noah does a dramatic reading from the SOAP spec) 11:35:06 (Huzzah!) 11:35:09 Specs on tape! 11:35:19 Audio specs 11:35:32 that's what we have been missing all this time 11:35:38 the wsaw:Anonymous element lets you say whether you require anon Reply/FaultTo | require non-anon Reply/FaultTo | can support either 11:35:59 dorchard has joined #xmlprotocol 11:36:49 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? 11:37:23 the point is also to catch errors at the sending side 11:37:35 like in the one way with ws-addr reply-to anonymous 11:37:54 and that is a problem why? 11:38:23 (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)) 11:38:56 suppose the wsdl oneway had a qos that required that the receiving endpoint return a non-repudiation receipt ack 11:39:01 Noah points out that SOAP Part 1 has a very important definition of MEP at http://www.w3.org/TR/soap12-part1/#soapmep. 11:39:11 Noah wants to know whether DaveO is trying to change this. 11:39:14 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... 11:39:17 chris: to where? 11:39:25 that would not necessarily be described in the WSDL, but the response would be delivered on the HTTP response 11:40:04 q? 11:40:10 if it's A->B->C, (C and A being the same software) and A<->B is different 11:40:47 Yves, I do want to get to the sender point, but just not right when I was talking about the receiver... 11:41:07 dave: ok I'll wait for that :) 11:43:06 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? 11:44:14 q? 11:44:19 ack cf 11:44:48 Chris: 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. 11:45:24 Chris: We should do the minimum necessary (enable 202 with empty response for req/resp) and move on 11:45:48 ack mar 11:46:03 Right now we don't have an answer for, say SOAP/XMPP or pub-sub 11:46:09 Marc: DaveO, you said MEP isn't adding much value. 11:46:15 DaveO: In terms of dealing with responses, yes. 11:46:58 DaveH, why do you say that? 11:47:25 what is preventing the SOAP/XMPP crowd from defining their binding and/or MEP? 11:47:28 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 11:48:00 Marc: So it seems what you need to know at both sides is the binding capabilities and the MEP 11:48:03 Glen: What MEP? 11:48:36 Marc: application MEP, WSDL MEP, whatever 11:48:45 Marc: how can you say MEP isnt important? 11:48:56 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. 11:49:07 DaveO: The uber mep is just about protocol.. not about application/WSDL level 11:49:22 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. 11:50:04 q+ 11:50:09 q- 11:50:50 q+ to comment on there being more than one MEP per binding 11:51:40 Noah: timing issues are important 11:52:02 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. 11:52:18 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. 11:52:19 q+ to talk about timing 11:52:27 dhull, you wanted to say that "looking at the binding" is too broad. We only need one bit. 11:53:25 dorchard has joined #xmlprotocol 11:53:48 dhull: "strongly" vs "weakly" isn't right... it should be "static" vs "latent" typing. 11:54:15 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) 11:54:44 dhull: would you have a named "isAnonymousAllowed" bit somewhere? 11:54:52 DaveO: in the coupling of the binding 11:55:08 dhull: not part of your job in the binding is to check off the meaning of that bit 11:55:20 DaveO: no parameter at the MEP level which the binding would fill in 11:55:22 but as I pointed out anon is fine if you aren't expecting a response even is the transport can't support anon 11:55:32 dhull: would be happier with a named thing that you could check 11:56:37 Noah: it's important to consider timing. how long will I have to wait is an important part of all of this. 11:56:41 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) 11:57:01 anish: exactly 11:57:01 Noah: different APIs for response in 20ms and two weeks... 11:57:27 yes, mostly i was +1ing you with a pointer to the default impact 11:58:09 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. 11:58:27 herve has joined #xmlprotocol 11:58:37 Noah: if we have HTTP, *something* needs to come back from the other side 11:59:53 Noah: 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. 12:00:44 DaveH says that we need a "isAnonSupported" property on the MEP 12:00:58 (with the "weakly typed" option) 12:01:18 I think I could support that addition 12:01:18 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. 12:01:35 +1 12:01:37 on the MEP or the binding ? 12:01:45 on the binding mebbe 12:01:55 on the MEP sounds weird 12:02:16 +1 to Noah 12:02:20 q? 12:02:22 ack cf 12:02:22 cferris, you wanted to comment on there being more than one MEP per binding 12:02:24 ack n 12:02:24 Here's an example, on WS-A, of how to use the properties of the mep 12:02:26 noah, you wanted to talk about timing 12:02:27 When wsaw:Async attribute has this value, then the 12:02:27 response message MAY be the response part (aka 12:02:27 http://www.w3.org/2004/12/ws-addr/mep/ResponseMessage or 12:02:27 http://www.w3.org/2003/05/soap/mep/InboundMessage) of a 12:02:27 request-optional-response or request-response MEP or the response 12:02:28 message MAY be the request part (aka 12:02:30 http://www.w3.org/2004/12/ws-addr/mep/RequestMessage or 12:02:32 http://www.w3.org/2003/05/soap/mep/OutboundMessage) of a separate 12:02:33 timing issue may be a property of the MEP 12:02:36 request-optional response or request MEP. 12:02:45 Chris: shouldn't have multiple MEPs per binding 12:02:48 and the combination will describe the API in use 12:03:24 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 12:03:38 Noah, I agree 12:03:40 -Chris_Ferris 12:03:40 LUNCH 12:04:32 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 12:04:38 I think we have already covered that 12:04:50 HTTP is inherently request-response 12:05:08 the question is whether there is a SOAP envelope in the request or response 12:05:27 in either case, you are obligated to await the response 12:06:34 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) 13:10:02 hi chris we are about to get started 13:10:16 k, dialing 13:10:37 Chris, in the case of WSDL one-way using SOAP/HTTP, I think all the proposed bindings say that there might be a response. 13:10:49 +Chris_Ferris 13:10:51 -Chris_Ferris 13:10:52 +Chris_Ferris 13:11:27 in that case, it really isn't different than the R-O-R, is it? 13:12:26 scribe: dhull 13:13:07 brb 13:18:46 back 13:19:27 http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0000.html 13:19:59 could someone describe what glen is drawing? 13:20:15 I have a little difficulty seeing it at this distance 13:20:36 herve has joined #xmlprotocol 13:20:41 let's wait until they decide that they want to draw 13:22:31 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. 13:22:58 daveO: That's SOAP MEPs at the bottom? 13:23:00 Glen: yes 13:23:13 daveO: In your view you need a binding underneath 13:23:16 Glen: no 13:24:08 Noah: Underneath the boxes you have things like HTTP, XMPP iq, or UDP, XMPP msg 13:24:52 Noah: you write general software that knows how to handle this e.g., request-response or FAF -- FAF means no timing issues. 13:25:21 FAF does not necessarily mean that there are no timing issues 13:25:22 Noah: Strongly typed MEPs give factoring. 13:25:36 just scribing, Anish 13:26:14 Noah: Describing strongly typed. Question for DaveO is how does weakly typed do this. To be answered. 13:27:39 noah: 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. 13:27:55 noah: Defining an MEP encourages software that uses that factoring, but doesn't force it. 13:28:42 daveO: Doesn't the app (doing r-r over one-way) ... you don't show the connection between HTTP and out/in. (?) 13:29:40 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. 13:30:44 q+ 13:30:48 noah: 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) 13:31:29 noah: 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) 13:31:51 noah: E.g., spinning off a thread to wait for response happens just one place. 13:32:07 noah: Clearly this doesn't have to be presented in terms of MEPS 13:32:27 glenD: Extend this to robust in-only (cool case), too 13:32:36 daveO: Don't disagree with this style of writing APIs. 13:32:59 noah: APIs follow naturally from strongly-typed MEPs. Good Thing. 13:34:16 noah: 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. 13:35:09 noah: Wrapping up suites of function in bulk encourages operability. 95-5 case. Just like read/write/open/close. Most code shared, occasional special case. 13:35:26 noah has joined #XMLProtocol 13:35:32 http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0000.html 13:35:36 chris: Put link into IRC of email to dist-app. 13:36:13 chis: Wanted to respond to discussion before lunch break. Appreciate point Noah makes about APIs. Perhaps I was making too fine a distinction, but ... 13:37:12 marc has joined #xmlprotocol 13:37:28 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. 13:38:38 chris: 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. 13:38:46 Glen: this is already agreed. 13:38:54 Noah: He's responding to an IRC comment I made. 13:39:13 q+ 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.. 13:39:19 chris: unless you're changing behavior of underlying protocol, not safe to layer one-way over req-resp. 13:40:26 so, to cut to the chase Chris are you saying that we just make the response optional and we are done ? 13:40:36 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. 13:41:38 chris: In r-o-r, fault will come back, can't mask out. 13:41:56 SOAP mU fault etc. => transport failure. 13:42:42 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. 13:43:02 Noah: They're going directly over UDP and tracking distinctions themselves. Otherwise going over HTTP. 13:43:14 DaveO: Going over HTTP, SMTP, JMS 13:43:40 Glen: Don't deny benefit to software construction, but also helps other spec writers. 13:43:59 Glen: Mapping of in-out to FAF is valuable per se (?) 13:44:19 q+ 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 doing SOAP Response and I think that means that technically it must be a separate binding unless we say that you MUST support both MEPs 13:44:20 DaveO: Main point is helping people write specs. Don't buy help to constructing software. 13:44:44 DaveO: Data available to spec writers is important. 13:45:00 marc: yes 13:46:12 schepers_ has left #xmlprotocol 13:46:43 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. 13:46:48 DaveO: Not what I meant 13:47:25 Noah: This is how it's coming across to me. Structurally r-o-r (and maybe adding FAF) is a small change. 13:47:36 +1 13:47:41 GlenD: Would not go into HTTP binding. 13:47:59 q+ 13:48:14 GlenD: If you need to know what MEP is action, need to do it before SOAP 13:48:17 q+ 13:48:19 Yves: Who needs to know 13:48:27 Glen, Noah: Everybody 13:49:05 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. 13:49:27 GlenD: We think each others arguments are specious. Obviously a misunderstanding. Let's solve the disconnect. 13:49:52 glen draws some more 13:49:58 q? 13:50:33 ack cferris 13:50:33 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 13:50:36 ... doing SOAP Response and I think that means that technically it must be a separate binding unless we say that you MUST support both MEPs 13:51:20 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. 13:52:02 chris: 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. 13:52:08 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). 13:52:22 It doesn't require you to respond to a get or a post for any particular URI. 13:52:28 ack dorchard 13:52:28 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 13:52:32 q? 13:52:35 So, you can in fact legally write a binding that says "no" to a get on any particular URI. 13:52:57 checking 13:53:20 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. 13:53:26 I think RFC 2616 lets you send a status code for "don't do that op on this URI", no? 13:53:33 yes 13:53:45 415 METHOD NOT SUPPORTED 13:53:54 QED? 13:54:04 ok (wise guy!) 13:54:13 too tired 13:54:16 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. 13:54:19 415 is unsupported media type 13:54:20 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. 13:54:24 405 is method not allowed 13:54:24 We got lucky on HTTP, I think. 13:54:33 405? 13:54:50 Checking 13:54:59 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. 13:55:01 brain cramp 13:55:25 what's up (down actually) with w3.org site? 13:56:04 405 Method Not Allowed 13:56:04 The method specified in the Request-Line is not allowed for the 13:56:04 resource identified by the Request-URI. The response MUST include an 13:56:04 Allow header containing a list of valid methods for the requested 13:56:04 resource. 13:56:23 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) 13:56:57 Glen: Can you explain this in terms of weakly-typed, or show problem with this. It seems you have to look inside the boxes. 13:57:22 Chris: I think we're all pretty impressed with the fact that you got up at 3AM for this! 13:57:38 DaveO: There is no consensus whether, if strongly-typed approach is adopted, HTTP would supporte two or three MEPs. 13:57:44 GlenD: who believes what? 13:58:05 :-) 13:58:28 GlenD: Noah, Glen, DaveH think no. 13:59:06 DaveO: If FAF is there, and doing an in-only, can just use one-way MEP. 13:59:15 q? 13:59:25 GlenD: But not a good idea. You would need to say something more on the wire if HTTP does both. 13:59:33 q+ to talk about dynamically choosing MEPs 13:59:47 DaveO: Neither choices is good. Adding one-way adds confusion from need to differentiate on wire. 13:59:55 GlenD: Not hard to do, if you want to do it. 14:00:30 hmmm 14:00:45 guess it could be my broadband provider network that is the problem 14:00:54 hum, maybe try www.w3.org instead of w3.org 14:01:00 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). 14:01:02 might be the redirecter on w3.org 14:01:12 omnes: PAOS uses HTTP headers to identify itself 14:01:27 GlenD: unfortunately, we don't provide marker. So we're default. 14:01:29 I saw this last week too 14:01:57 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. 14:02:04 Anish: Can do this now. 14:04:23 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? 14:04:29 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. 14:05:13 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? 14:05:42 DaveO: Binding exposes uber-MEP. 14:05:50 GlenD: Just what does it expose? 14:06:00 DaveO: Exposes the properties. 14:06:10 DaveH: What props? 14:06:22 Noah, you are correct, the spec DOES say MUST support BOTH MEPs... interesting 14:06:28 DaveO: Reuqest msg, response mesg. destination etc., as described in proposal. 14:06:29 I stand corrected, thanks 14:06:47 mikem has joined #xmlprotocol 14:07:14 DaveO: Suppose you're using HTTP. Binding says how props go into MEP. E.g., request message goes into InboundMessage (?) 14:07:28 GlenD: How does app know what binding can do? 14:07:41 marc has left #xmlprotocol 14:07:48 DaveO: Binding says how to put request into props. 14:08:12 marc has joined #xmlprotocol 14:08:15 GlenD: MEP that strongly-typed exposes has semantics. 14:08:26 DaveO: That's a fallacy. E.g look at WSA. 14:08:31 GlenD: What do you mean? 14:09:03 GlenD: I know that *something* is going to come back. WSA doesn't affect that. Take "request-response" to mean "request-opt-response" 14:09:10 q? 14:09:37 DaveO: S.T. approach says you're going to look ahead and build your app based on bindings 14:10:06 DaveO: App picks binding, knows what's going to happen. App knows by what binding it picked what will happen. 14:11:48 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. 14:12:29 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. 14:13:30 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. 14:13:59 DaveO: No, no change. Uber MEP is request-response MEP. It has a request bucket and a response bucket. 14:14:05 q? 14:15:26 DaveH: How do you know you shouldn't use anon for UDP e.g. 14:16:00 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. 14:17:29 q+ 14:19:56 marc: A coherent answer would have been, no OutboundMessage property in binding. If it has OutboundMessage, how do you know it's never populated? 14:20:23 glen: and if you do know, how is that different from strong typing? 14:23:09 DaveO: The way the software will know whether anon response endpoints are allowed will depend upon the protocols supported. 14:23:43 Noah: So two XMPP bindings had better have the same behavior. 14:23:52 Anish: So you mean binding, not protocol. 14:24:01 mikem, I'd like to chime in 14:24:16 the people in the room have been dominating the discussion 14:24:21 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. 14:24:33 DaveO: Question is how parameterized are these. 14:25:16 Chris: Want to shift discussion to what it is about Noah's proposal that would preculde correct impl. 14:25:31 GlenD: I.e., who can't live with it and why 14:25:35 Chris: Yes. 14:31:52 GlenD has joined #xmlprotocol 14:35:47 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? 14:36:27 dhull has joined #xmlprotocol 14:57:06 anish has joined #xmlprotocol 15:01:50 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? 15:02:15 No. 15:02:22 i would add manifested in the protocol part 15:02:25 not the soap env 15:02:38 GlenD: What does that (chris's question) mean? 15:02:50 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? 15:02:56 chris: In current (HTTP) case, it's the web method 15:02:56 ... and given that MEPs are already identified by URIs, this is easy 15:02:59 something like an http header that says "response optional"? 15:03:54 actually, I was not thinking that you need anything like: response optional... I think that Noah's proposal handles things nicely 15:03:54 GlenD: Don't need to go there right now. There is a minimal soultion 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 15:04:05 s/soultion/solution/ 15:04:12 anish: Need to deal with it in any case (?) 15:04:29 Noah: Do we need an exact proposal now? 15:05:01 marc has joined #xmlprotocol 15:05:17 perhaps we need two things identified in the protocol: the binding URI and the MEP URI 15:05:18 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. 15:05:56 q+ 15:06:05 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. 15:06:48 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 15:06:52 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. 15:07:01 Chris: just offering to move toward consensus. 15:07:31 marc, given that we can't someone from creating another http binding, we should provide both 15:07:42 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. 15:08:38 Anish: May need to identify both -- binding in effect and MEP in effect. Otherwise message can look exactly the same in different circumstances. Can't stop someone from defining their own HTTP binding. Would be nice to define particular HTTP header to key off of. 15:08:54 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. 15:09:06 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 15:09:14 Anish: Typically impls ignore HTTP headers they don't understand. Would be nice if we defined it and asked binding authors to use it. 15:09:32 Yves: Not every impl will read this, so still can't rely on it. (no Mu) 15:09:38 s/Mu/mU/ 15:09:47 Noah: Do we need to go here? 15:09:50 Omnes: No 15:10:08 GlenD: Can do this later. 15:10:10 Anish: Yes. 15:10:15 Strong +1 15:10:24 Yves: Might be nice to signal version in use. 15:10:37 GlenD: Chris & Anish take action to work up proposal? 15:10:42 Anish: yes 15:11:13 Chris: Wouldn't oppose this. Personal opinion is don't need to distinguish, say, r-o-r and one-way, that's actually bad. 15:11:27 Chris: Will take action item, yes. 15:11:52 Yves: Not differentiating bindings, not MEPs. 15:12:18 Noah: Need at least on proposal phrased pertty formally. 15:12:26 Anish: Straw poll? 15:12:36 Noah: First set down a clear proposal to poll on. 15:12:43 Mike: How do we expose this. 15:13:03 Agenda: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Feb/0030.html 15:13:07 GlenD: Noah's email is well-formed, all bows tied up. 15:13:20 GlenD: DaveO, you have same? 15:13:34 DaveO: Yes, taking addendum into account. 15:13:45 Noah proposal: http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html 15:14:00 GlenD: If there's a strong leaning one direction, can address objections or work up further details. 15:14:17 Here's the "uber-mep" http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0007.html 15:14:51 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). 15:15:40 Noah: 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) 15:16:14 Noah: i.e. clarify that SOAP envelope is optional in r-r. 15:16:56 DaveO: Does 202 allow an envelope? 15:17:25 Noah: Not as I've drafted it. Never chooses to use it. Signal as to whether you got an envelope is 200 vs. 202. 15:17:57 Anish: HTTP allows entity body in 202. 15:18:22 q+ 15:18:38 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? 15:18:47 GlenD: WS-RX acks. 15:19:02 Noah: That's just tunneling. I think that's a misuse of HTTP. 15:19:32 DaveO: Uber-MEP proposal more elegantly deals with 202 issue, whether envelope is allowed other than for app response. 15:19:57 Noah: Think it's really screwy architecturally, but strongly-typed MEP could be edited to accommodate that. 15:20:00 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 15:20:18 DaveO: 15:20:35 to say that a SOAP envelope carried as a request only applies to the content of the SOAP body isn't correct IMO 15:21:00 q+ to ask if we need to decide on the entity body of 202 to get a consensus on the direction 15:21:05 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) 15:21:40 DaveO: There's a big dragon there in terms of strongly-typed MEPs. 15:22:07 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. 15:22:14 Noah: It's a design call whether to put it in MEP or in binding-specific. Kind of like IOCTL. Certainly is ugly. 15:22:20 cheers, Dave 15:22:48 Anish: Do we need to figure out all the details to get consensus on general direction? 15:24:01 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). 15:24:19 q+ 15:24:33 Noah: MEP tends to say fault should come back to sender. In WSA world there are issues of where and when to direct faults. 15:25:04 Some faults are very much like transport failures (e.g. host unreachable) 15:25:14 Anish: 202 is intentionally non-commital 15:25:27 Anish: Can get fault back on 202. 15:25:37 Noah: But that's a definitive problem (200). 15:26:11 GlenD: But what about robust in-only. Does 202 mean no fault happened, but one might happen later. 15:26:19 can I gat a word in edgesise? 15:26:25 edgewise 15:26:26 DaveH: Went over all this in async TF. It all fell out. 15:26:51 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. 15:26:59 GlenD: In the absence of any other extensions. 15:27:33 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. 15:27:36 what I hear Noah saying is that for the use case of ws-rx that [fault endpoint] MUST be non-anonymous 15:27:44 GlenD: Not a problem. WSA can override. 15:28:11 GlenD: There is a stack of stuff above at both ends. 15:28:20 Anish: True for req-rep, but we're defining a new MEP 15:28:25 q? 15:28:29 Noah: No, clarifying an existing MEP. 15:28:35 noah, you wanted to talk about dynamically choosing MEPs 15:28:42 Noah: In part because implementors have gone this way. 15:28:57 ahem 15:29:10 *cough* 15:29:22 Yves: We have a way to use 204 to say no response. Quite different from 202, which says nothing about processing. 15:30:46 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. 15:31:08 q+ to respond to chris' comment 15:31:44 Chris: 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. 15:32:23 mU (so fault) and 202/204 deals with the no processing/mU check | processing/mU check 15:32:29 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. 15:32:48 Anish: Just making sure everyone understands the proposal. There are some gray areas t odeal with later. 15:32:54 Chris: Cant' sort them out here. 15:33:01 Mike: In violent agreement here. 15:33:07 s/Can't/Don't/ 15:33:17 Anish: Dont' quite agree on 202 but will sort out later. 15:33:34 From: http://www.w3.org/TR/soap12-part2/#bindfaulthdn 15:33:45 "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." 15:33:49 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 15:33:53 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. 15:34:23 ... cause I have usecases where it is truely doing queue, without checking the soap message and I would like to enable those cases 15:34:41 DaveO: Is that two instances of req-rep? Do I shut down and switch MEPs. 15:35:17 chris -- daveo is drawing a diagram on the whiteboard 15:36:18 I hope someone is capturing the drawings and can possibly inline them into the minutes since I think that they will be valuable 15:37:32 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. 15:38:36 DaveO: ReplyTo will have http:, or smtp: or whatever, telling it what to use. Then has to pick MEP. 15:39:16 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. 15:39:26 DaveO: There's no info ahead of time. 15:40:20 dorchard has joined #xmlprotocol 15:40:31 -Chris_Ferris 15:41:05 Noah: You know in advance there are only two code paths, regardless of how many protocols you actually support. 15:41:08 +Chris_Ferris 15:41:10 -Chris_Ferris 15:41:11 +Chris_Ferris 15:41:16 -Chris_Ferris 15:41:41 Noah: Proposing note 50 + promise of future FAF MEP. 15:41:56 +Chris_Ferris 15:41:58 -Chris_Ferris 15:41:59 i would rather call it one-way mep than faf mep 15:41:59 +Chris_Ferris 15:42:27 My proposal is roughly: 15:42:38 DaveO, if you are saying that an EPR can't communicate the characteristics of the MEP, then I would agree 15:42:48 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). 15:42:59 disregard that 15:43:13 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 15:43:26 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... 15:43:28 ...that SOAP envelope is optional in r-r. 15:43:48 (previous is pasted from previous minutes) 15:43:52 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 15:46:20 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. 15:46:53 so, you are suggesting, for instance, that the HTTP method should be communicated in the EPR? 15:47:16 for the case of an HTTP-based response endpoint? 15:48:22 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 15:48:28 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 15:49:12 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 15:49:28 Mike: Poll -- Who agrees this is good direction? 15:50:05 Chris: Agree, but want to know form of (2). Addendum or separate rec-track doc? 15:50:53 Noah: Haven't thought it through. People (e.g., DHull) have repeatedly asked. Want least overhead in process, minimal pain for rest of SOAP. 15:50:59 btw 202 vs 204 may be seen as faf vs non faf one way (or ror) 15:51:15 Chris: Step 1 could be errata, but 2 is too big for this. 15:51:26 Mike: Notes vote was 9-1. 15:51:56 Noah: 2nd addition means nothing more than errata? Can we add MEP? 15:52:03 Yves: If it's just clarifying material. 15:52:08 Noah: That's a big stretch. 15:52:29 Noah proposal: if it can't be second edition, then SOAP 1.2 Part 3: additional MEPs and Features 15:52:36 Chris: +1. Considering rec track proposal (?). Think this affects my vote. 15:52:39 You'd have to do the new MEP in a Rec track as there's no CR results for it as an errata 15:53:01 Chris: Concerned this will take so long as to become irrelevant. 15:53:07 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 15:53:24 Chris: Not in favor of both at same time. 15:53:32 Noah: Would have to go through CR. 15:53:37 q+ 15:53:58 Noah: Don't want SOAP 1.3. What about SOAP 1.2 part 3. 15:54:02 +1 15:54:06 +1 15:54:10 +1 15:54:15 +1 15:55:50 q- 15:55:54 DaveH: Friendly amendment: Note with (1) that this is not the answer for datagram protocols, this is to come in work for (2). 15:56:01 ack an 15:56:01 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 15:56:09 Noah: Fine [in fact, Noah actually proposed it] 15:56:40 works for me 15:57:55 Mike: Formal vote? 15:58:12 Noah: Should we continue to work for consensus since there isn't one yet? 15:58:19 DaveO: It's time to decide. 15:58:28 GlenD: You want objection noted? 15:59:18 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. 16:00:23 Mike: Separate issue is Dave's new style (no state machine) for new work. 16:01:09 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. 16:01:10 Mike: Formal vote by company 16:03:03 RESOLUTION: Parts (1) and (2) as minuted above. Formal vote: Yes: IBM, Nokia, Sonic, Canon, Sun, Oracle, W3C, TIBCO. No: BEA 16:03:36 Noah: (abstentions: none) 16:03:45 s/Noah/Note/ 16:04:27 Mike: Straw poll: Amendement for part (2) above, use simplified MEP description style 16:06:12 Note: simplified MEP style for new work 16:06:28 Mike: 9 yes 1 abstain 16:06:29 For the record, I'd be glad to do editorial work on any one-way work. 16:06:55 abstain means you are going along with whatever the group decides 16:09:06 (just for the record) 204 may be better than 202, and 202 reserved for "true" one way 16:09:08 lol 16:09:26 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. 16:10:35 Noah: Hoping this is a small amount of work. 16:10:38 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? 16:10:41 DaveO has joined #xmlprotocol 16:10:53 chris, i think that is clear 16:11:04 ok, just checking 16:11:32 I think I misunderstood the bit about 202/204 as relates to "true" one-way 16:11:45 I meant without a backchannel for faults 16:11:56 I don't think that is what we are doing 16:12:04 we are doing R-O-R 16:12:10 there is a back-channel 16:12:20 so as rr impliues backchannel, 204 is more suited 16:12:24 in terms of the one-way MEP, then there is no backchannel 16:12:26 s/rr/ror/ 16:12:44 so 202 looks more like one-way as there is no backchannel 16:13:19 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 16:13:32 Mike: Need to capture how we're going to publish this. 16:13:33 because "processed" might mean, queued for processing 16:13:35 URI for instructions for running scribe.perl: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm 16:13:51 URI for scribe.perl itself: http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/ 16:13:59 we can talk about the semantic of 200/204, but 202 really means that no processing happened 16:14:14 so no mU were checked 16:14:15 yes 16:14:17 Note: We will not produce an HTTP binding for one-way MEP in (2). 16:14:22 URI for scribe.perl itself: http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribe.perl 16:16:13 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? 16:16:28 we call it Fred 16:16:44 Anish: Still need to discuss issues, now that we've decided overall direction 16:17:08 DHull: Will part 3 have its own issues list? 16:17:17 Mike: Yves? 16:17:26 Yves: Can reuse existing list. 16:18:06 Anish: Issue 3) (Yves) 202 vs 204 4) possible HTTP header signalling binding, MEP 16:18:33 Mike: Actions, ownership: 16:19:27 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. 16:19:35 Anish: regrets for next two weeks 16:19:52 ACTION: Anish to start email discussion of what does FAF really mean? 16:20:04 ACTION: Yves to start discussion of 202 vs. 204 16:20:30 ACTION: Marc to start discussion of possible HTTP header signalling binding/MEP 16:20:30 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? 16:21:02 Note: What does FAF mean and what timing issues are there are actually the same issue (actioned to Anish) 16:22:45 My key points are effectively in the resolution: 16:23:00 Chris: Could people please provide pointers to key emails in previous discussion of "what does FAF mean" issue. 16:23:09 Mike: This seems part of starting email discussion. 16:23:23 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. 16:23:35 2) Therefore, this MEP is mainly for datagram-like protocols. 16:23:42 Chris, those two points are my main input. 16:23:46 Mike: Meet a week from Wednesday? 16:23:51 Omnes: General approval. 16:23:52 noah, what MEP would you use for queueing/messaging/jms? 16:24:08 that is where it gets tricky 16:24:11 thanks, noah 16:24:14 Mike: Next meeting March 15 16:26:50 Mike: I believe my draft is a useful starting point. Group should read it keeping in mind that this should be headed quickly toward Rec. 16:27:18 ACTION: Noah to suggest how the group should proceed in reviewing draft (suggestion will probably be what I just said) 16:27:51 Mike: Anything else? 16:27:54 Omnes: No. 16:28:05 DaveH, did you mean Noah instead of Mike in reference to "my draft"? 16:29:49 s/Mike: I believe my/Noah: I believe my/ 16:30:01 -Chris_Ferris 16:30:07 ciao 16:30:11 cya 16:30:19 Mike: Adjourned 16:30:20 -Tp_iles_a 16:30:21 or should I say au revoir 16:30:21 WS_XMLP(TP)4:00AM has ended 16:30:23 Attendees were Tp_iles_a, Chris_Ferris 16:30:46 cferris has left #xmlprotocol 16:33:59 rrsagent, draft minutes 16:33:59 I have made the request to generate http://www.w3.org/2006/03/04-xmlprotocol-minutes.html mikem 16:38:28 rrsagent, make log public 16:39:02 rrsagent, where am I? 16:39:02 See http://www.w3.org/2006/03/04-xmlprotocol-irc#T16-39-02 16:40:10 rrsagent, please generate minutes 16:40:10 I have made the request to generate http://www.w3.org/2006/03/04-xmlprotocol-minutes.html noah