16:33:26 <RRSAgent> RRSAgent has joined #xmlprotocol
16:33:26 <RRSAgent> logging to http://www.w3.org/2005/11/30-xmlprotocol-irc
16:33:37 <cferris> I am on conflicting call as well
16:34:07 <dhull> dhull has joined #xmlprotocol
16:34:21 <mikeem> mikeem has joined #xmlprotocol
16:34:48 <Zakim> -Dave_Hull
16:35:14 <Zakim> +Dave_Hull
16:35:19 <Zakim> + +1.858.831.aaaa
16:39:58 <h_scribe> Misc
16:40:09 <h_scribe> Two new members: Glen Daniels
16:40:15 <h_scribe> David Hull
16:40:17 <Zakim> + +1.514.878.aabb
16:40:24 <h_scribe> - F2F
16:40:39 <h_scribe> Mike: trying to have F2F at W3C Tech meeting.
16:40:52 <h_scribe> However scheduling problems due to other group meetings
16:41:18 <h_scribe> Solution: saturday after TP.
16:42:23 <anish> anish has joined #xmlprotocol
16:42:33 <h_scribe> 3. Minutes
16:42:49 <Zakim> +Anish
16:42:54 <h_scribe> 16 november: no pushback, minutes approved.
16:43:51 <h_scribe> 4. Action Items
16:44:01 <h_scribe> Anish: pending
16:44:12 <h_scribe> Mike: pending
16:44:23 <h_scribe> Mike: done
16:44:45 <h_scribe> Noah: done
16:44:59 <h_scribe> 5. Administrative
16:45:26 <h_scribe> Yves: PP and charter, vote still going on. 
16:45:37 <h_scribe> 1 week for PP. Then 1 more week for new charter.
16:45:49 <h_scribe> Probably finished by EoY
16:46:14 <h_scribe> (may need to respond to charter comments)
16:46:40 <h_scribe> 7. MEP issue
16:48:35 <h_scribe> Glen: 1 of main questions: shall MEP exists? And if yes, at what layer?
16:49:11 <h_scribe> What to do with a WSDL MEP? HTTP has a build-in req-resp paradigm, other protocols may have other paradigm.
16:49:34 <h_scribe> No consensus about where MEP lives.
16:50:23 <h_scribe> 1 way to see it, is that as SOAP MEP is close to a WSDL MEP.
16:51:06 <h_scribe> Other way: SOAP MEP is an abstraction of a protocol MEP. HTTP has req-resp, SOAP req-resp MEP that binds to HTTP req-resp.
16:51:30 <h_scribe> In first case 1 WSDL MEP binds to 1 SOAP MEP that binds to multiple protocol paradigm.
16:51:50 <h_scribe> In second, 1 WSDL MEP binds to multiple SOAP MEP linked to protocol paradigm.
16:53:21 <h_scribe> With a SOAP MEP close to HTTP transport, no need of 1-way MEP. Only need req-resp MEP with optionnaly empty response.
16:53:27 <h_scribe> Think that MEP should stay.
16:53:59 <Zakim> +Pete_Wenzel
16:54:02 <h_scribe> Yves: HTTP natively does have ability 1-way stuff with empty response.
16:55:21 <h_scribe> Dave: good summary of where things are.
16:55:45 <h_scribe> Dave: agree that SOAP MEP are usefull abstraction and should be close to transport level.
16:56:09 <h_scribe> Dave: SOAP MEPs describe what a protocol can propose.
16:56:42 <h_scribe> Tend to think that every transport should provide a 1-way MEP.
16:58:24 <h_scribe> To map WSDL MEP to SOAP MEP, it makes sense to have 1-way for everything, even HTTP.
16:59:20 <h_scribe> Glen: fundamental difference is about where you bound your decision?
16:59:47 <h_scribe> Dave: no, question is how do we model the way it is signaled.
17:00:26 <h_scribe> 1 approach: in case of HTTP, allways send a response (even if empty). Other way, use 1-way.
17:00:49 <h_scribe> Glen: choice may be done late.
17:01:29 <h_scribe> Dave: if define both (req-resp and 1-way), have to build them well, because have to distinguish them at response time.
17:02:18 <h_scribe> Noah: new pb that can not decide at binding level from the outbound message which MEP is used.
17:02:49 <h_scribe> Need to do it compatibly with existing REC.
17:02:57 <h_scribe> Dave: possible to do it.
17:03:29 <h_scribe> Dave: when define 1-way for HTTP need to have it compatible with req-resp.
17:04:01 <h_scribe> Noah: can have spec level compatible, but need to have it with software implementations.
17:04:16 <h_scribe> May have a problem with current implementations.
17:04:57 <h_scribe> Only way do it, is to add some marker.
17:05:18 <h_scribe> Means that this new stuff will not be compatible with current implementations.
17:05:34 <h_scribe> Think it is an incompatibility.
17:06:10 <h_scribe> But thinks probably a murkier, because many implementations have ignored the REC on this point.
17:06:28 <h_scribe> Noah: this is not an errata, but a change, because nothing is broken.
17:08:26 <h_scribe> Noah: case with 2 responses (ack to original sender + true response) common?
17:08:42 <h_scribe> Marc: Does not append like this.
17:09:54 <h_scribe> Noah: 1 way: add something in message to say that 1-way MEP is used.
17:10:14 <h_scribe> Marc: could assume that if not there, then req-resp.
17:11:41 <h_scribe> Noah: 2 way: create a new MEP, somewhat incompatible with current MEP: send a SOAP message with perhaps a response.
17:11:57 <h_scribe> Noah: 1st way is compatible, 2nd not.
17:12:27 <anish> q+ to ask why adding a http header makes it compatible, as opposed to something in the SOAP message
17:12:47 <h_scribe> Noah: say in spec for new binding, that it is largelly compatible with existing binding, but not completely compatible.
17:13:06 <cferris> I'm wondering if maybe what is needed is just a oneway SOAP MEP that is NOT supported by HTTP but possibly by other underlying transports such as TCP or BEEP
17:13:16 <h_scribe> Noah: 3rd option is just to ignore compatibility and rewrite current binding.
17:13:29 <h_scribe> Noah: 4th option is to use the uberMEP option.
17:13:42 <cferris> I am actually thinking that maybe we got it right... that for HTTP, there should always be a response SOAP envelope even if it is empty
17:14:22 <cferris> I am increasingly concerned about the conflation of SOAP MEP and WSDL or higher-level MEP
17:14:31 <cferris> I think it is a mistake to conflate them
17:14:36 <cferris> they are completely orthogonal
17:14:47 <dhull> We mean *not* to conflate them (at least Glen and I)
17:14:59 <h_scribe> Anish: if we add HTTP header, would not break compatibility. What about using a SOAP header? WSA make it clear whether there will be response or not.
17:15:06 <dhull> E.g in-out -> either req-rep or two one-ways, depending
17:15:08 <h_scribe> Noah: think that it is a good point.
17:15:12 <h_scribe> Can turn question over.
17:15:27 <marc> i *really* dislike the idea of sending round empty SOAP messages, what is the point ?
17:15:38 <h_scribe> HTTP header: very early signalling that compatibility is broken.
17:15:38 <dhull> they might not always be empty
17:15:41 <cferris> dialing
17:16:06 <h_scribe> Making SOAP depending on WSA is not good.
17:16:10 <dhull> +1
17:16:11 <marc> getting two separate response SOAP messages is just adding complexity with no benefit IMO
17:16:17 <cferris> well, what I dislike is disalowing a SOAP envelope in cases where the WSDL says oneway
17:16:25 <h_scribe> Feels more natural that the binding knows about transport.
17:16:27 <Zakim> +Chris_Ferris
17:16:49 <h_scribe> More a matter of taste, whether or not making the HTTP binding dependant on WSA header.
17:17:05 <dhull> E.g, BEEP request, BEEP "OK" response includes [message id] to say exactly which message it's ack-ing
17:17:23 <h_scribe> Glen: in spec, 2xx has a blank significance.
17:17:27 <dhull> (that was aimed at Marc's objection to empty SOAP messages)
17:17:32 <marc> right so there's no need to repeat that in a SOAP payload
17:17:39 <h_scribe> Therefore is it OK to fix this.
17:17:52 <dhull> (? [message id] *is* a SOAP thing)
17:18:18 <marc> i missunderstood, i meant the BEEP level correlation
17:18:32 <GlenD> GlenD has joined #xmlprotocol
17:18:36 <h_scribe> Chris: pb: what WSDL says is at application level. Nothing to do with real message exchange.
17:18:53 <dhull> That's another way to do it.  Maybe better.  IMHO there is still an open question as to how WSA MAPs relate to analogous transport-level things
17:19:18 <h_scribe> SOAP req-resp MEP maps nicely with HTTP messages.
17:19:58 <h_scribe> People are binding WSDL MEP with SOAP MEP. Is it necessary?
17:20:09 <h_scribe> Need to make clear what a MEP means.
17:20:27 <h_scribe> Noah: part of thing to do is to help people to be organized.
17:20:49 <h_scribe> Intersting thing about SOAP MEP is that allows to make statement about multiple transport.
17:21:27 <h_scribe> Allowed to remove the transport details from the application.
17:21:53 <h_scribe> In many cases, it means that SOAP MEP maps pretty close to transport level.
17:23:05 <h_scribe> Chris: if you have multiple MEP supported by a transport, what signals what MEP to use.
17:23:46 <h_scribe> Noah: a year ago, seems natural to know from outbound message what MEP is used. Not more the case, with WSA use-cases.
17:24:00 <h_scribe> Dave: you know what case you have by the response you get.
17:24:06 <anish2> anish2 has joined #xmlprotocol
17:24:44 <anish2> +1 to not including blank soap messages
17:24:58 <h_scribe> Chris: putting blank soap message is not good.
17:25:48 <h_scribe> Dave: there were cases where it was usefull to send back a SOAP OK message, with something more in it.
17:26:15 <h_scribe> Not only say: OK I got this 1-way message, but also for e.g. something about reliability.
17:26:48 <cferris> please attribute "Chris: putting blank soap message is not good." to Marc
17:26:56 <h_scribe> Anish: if sending back some information, would'nt that be SOAP req-resp?
17:27:14 <h_scribe> Dave: it could still be a 1-way message at application level.
17:27:47 <Montreal> Montreal people are going to head out....
17:28:15 <h_scribe> AOB
17:28:25 <h_scribe> Mike: Christmas schedule.
17:28:44 <Zakim> - +1.514.878.aabb
17:30:32 <h_scribe> Mike: 28 dec is off.
17:31:08 <h_scribe> Mike: probably do 21 dec.
17:31:28 <h_scribe> Mike: will do 4 jan.
17:32:13 <h_scribe> - Test collection errata.
17:32:23 <h_scribe> Anish: one issue is a type.
17:32:30 <h_scribe> s/type/typo/
17:32:36 <h_scribe> Mike: already discuss?
17:32:41 <h_scribe> Anish: yes.
17:32:50 <h_scribe> Mike: what is needed to do?
17:32:58 <h_scribe> Anish: need to agree how to fix it.
17:33:23 <h_scribe> Mike: take this next week.
17:33:42 <h_scribe> Mike: If any pushback for the resolution, make it this week. Will make decision next week.
17:34:27 <h_scribe> action: mike to put e-mail to list for sending response to proposed changes to test collection issues.
17:34:39 <Zakim> -Marc_Hadley
17:34:40 <Zakim> -Chris_Ferris
17:34:40 <Zakim> -Anish
17:34:40 <h_scribe> Mike: call adjourned.
17:34:44 <Zakim> - +1.858.831.aaaa
17:34:50 <Zakim> -Pete_Wenzel
17:35:19 <mikeem> I was just looking for that
17:36:01 <Zakim> -Canon
17:36:02 <cferris> rrsagent, draft minutes
17:36:02 <RRSAgent> I have made the request to generate http://www.w3.org/2005/11/30-xmlprotocol-minutes.html cferris
17:36:18 <cferris> rssagent, list actions
17:36:31 <cferris> zakim, please list actions
17:36:31 <Zakim> I don't understand 'please list actions', cferris
17:36:33 <anish> rrsagent, make log public
17:37:32 <mikeem> Yes - it is in the html 
17:37:38 <mikeem> Thanks guys
17:37:39 <cferris> yep
17:38:01 <cferris> looks like there were errors generating the minutes... not sure how that gets cleaned up
17:38:09 <cferris> been away too long:-)
17:38:33 <mikeem> I'll manual elide when I insert minutes
17:38:41 <mikeem> s/manually/manual
17:39:27 <anish> rrsagent, show actions
17:39:27 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2005/11/30-xmlprotocol-actions.rdf :
17:39:27 <RRSAgent> ACTION: mike to put e-mail to list for sending response to proposed changes to test collection issues. [1]
17:39:27 <RRSAgent>   recorded in http://www.w3.org/2005/11/30-xmlprotocol-irc#T17-34-27
17:40:58 <cferris> ciao
17:41:00 <cferris> cferris has left #xmlprotocol
17:45:46 <dorchard> dorchard has joined #xmlprotocol
17:48:31 <dorchard> anybody here?
18:13:15 <mike> mike has joined #xmlprotocol
18:35:00 <Zakim> disconnecting the lone participant, Dave_Hull, in WS_XMLP()11:30AM
18:35:02 <Zakim> WS_XMLP()11:30AM has ended
18:35:04 <Zakim> Attendees were Marc_Hadley, Dave_Hull, Canon, +1.858.831.aaaa, +1.514.878.aabb, Anish, Pete_Wenzel, Chris_Ferris
18:45:17 <noah_montreal> noah_montreal has joined #XMLProtocol
18:46:29 <noah> noah has joined #XMLProtocol
18:48:13 <noah_montreal> noah_montreal has joined #XMLProtocol
18:48:17 <noah_montreal> noah_montreal has joined #XMLProtocol
20:01:57 <Zakim> Zakim has left #xmlprotocol
20:23:39 <noah> noah has joined #XMLProtocol
20:28:21 <noah_montreal> noah_montreal has joined #XMLProtocol
21:43:14 <noah_montreal> noah_montreal has joined #XMLProtocol