Sat. afternoon minutes

Here are the massaged .txt file and resulting .html file.  I took Noah's
.txt file as a starting point.

08:09:55 <RRSAgent> RRSAgent has joined #xmlprotocol
08:09:55 <RRSAgent> logging to http://www.w3.org/2006/03/04-xmlprotocol-irc
12:04:32 <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
12:04:38 <cferris> I think we have already covered that
12:04:50 <cferris> HTTP is inherently request-response
12:05:08 <cferris> the question is whether there is a SOAP envelope in the request or response
12:05:27 <cferris> in either case, you are obligated to await the response
12:06:34 <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)
13:10:02 <mikem> hi chris we are about to get started
13:10:16 <cferris> k, dialing
13:10:37 <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.
13:10:49 <Zakim> +Chris_Ferris
13:10:51 <Zakim> -Chris_Ferris
13:10:52 <Zakim> +Chris_Ferris
13:11:27 <cferris> in that case, it really isn't different than the R-O-R, is it?
13:12:26 <dhull> scribenick: dhull
13:12:26 <dhull> scribe: David Hull
13:12:26 <dhull> Meeting: XML Protocols F2F 4 March 2006 - Afternoon (Mandelieu)
13:12:26 <dhull> chair: Mike Mahon
13:12:26 <dhull> TOPIC: "Strongly-typed" vs. "Weakly-typed" MEPs


13:13:07 <cferris> brb
13:18:46 <cferris> back
13:19:27 <cferris> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0000.html
13:19:59 <cferris> could someone describe what glen is drawing?
13:20:15 <cferris> I have a little difficulty seeing it at this distance
13:20:36 <herve> herve has joined #xmlprotocol
13:20:41 <daveh> let's wait until they decide that they want to draw
13:22:31 <dhull> 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 <dhull> daveO: That's SOAP MEPs at the bottom?
13:23:00 <dhull> Glen: yes
13:23:13 <dhull> daveO: In your view you need a binding underneath
13:23:16 <dhull> Glen: no
13:24:08 <dhull> Noah: Underneath the boxes you have things like HTTP, XMPP iq, or UDP, XMPP msg
13:24:52 <dhull> 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 <anish> FAF does not necessarily mean that there are no timing issues
13:25:22 <dhull> Noah: Strongly typed MEPs give factoring.
13:25:36 <daveh> just scribing, Anish
13:26:14 <dhull> Noah: Describing strongly typed.  Question for DaveO is how does weakly typed do this.  To be answered.
13:27:39 <dhull> 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 <dhull> noah: Defining an MEP encourages software that uses that factoring, but doesn't force it.
13:28:42 <dhull> 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 <dhull> 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 <cferris> q+
13:30:48 <dhull> 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 <dhull> 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 <dhull> noah: E.g., spinning off a thread to wait for response happens just one place.
13:32:07 <dhull> noah: Clearly this doesn't have to be presented in terms of MEPS
13:32:27 <dhull> glenD: Extend this to robust in-only (cool case), too
13:32:36 <dhull> daveO: Don't disagree with this style of writing APIs.
13:32:59 <dhull> noah: APIs follow naturally from strongly-typed MEPs.  Good Thing.
13:34:16 <dhull> 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 <dhull> 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> noah has joined #XMLProtocol
13:35:32 <cferris> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0000.html
13:35:36 <dhull> chris: Put link into IRC of email to dist-app.
13:36:13 <dhull> chris: 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> marc has joined #xmlprotocol
13:37:28 <dhull> 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 <dhull> 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 <dhull> Glen: this is already agreed.
13:38:54 <dhull> Noah: He's responding to an IRC comment I made.
13:39:13 <dorchard> 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 <dhull> chris: unless you're changing behavior of underlying protocol, not safe to layer one-way over req-resp.
13:40:26 <marc> so, to cut to the chase Chris are you saying that we just make the response optional and we are done ?
13:40:36 <dhull> 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 <dhull> chris: In r-o-r, fault will come back, can't mask out.  
13:41:56 <daveh> SOAP mU fault etc. => transport failure.
13:42:42 <dhull> 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 <dhull> Noah: They're going directly over UDP and tracking distinctions themselves.  Otherwise going over HTTP.
13:43:14 <dhull> DaveO: Going over HTTP, SMTP, JMS
13:43:40 <dhull> Glen: Don't deny benefit to software construction, but also helps other spec writers.
13:43:59 <dhull> Glen: Mapping of in-out to FAF is valuable per se (?)
13:44:19 <cferris> 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 <dhull> DaveO: Main point is helping people write specs.  Don't buy help to constructing software.
13:44:44 <dhull> DaveO: Data available to spec writers is important.
13:45:00 <cferris> marc: yes
13:46:12 <schepers_> schepers_ has left #xmlprotocol
13:46:43 <dhull> 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 <dhull> DaveO: Not what I meant
13:47:25 <dhull> 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 <cferris> +1
13:47:41 <dhull> GlenD: Would not go into HTTP binding.
13:47:59 <dorchard> q+
13:48:14 <dhull> GlenD: If you need to know what MEP is action, need to do it before SOAP
13:48:17 <anish> q+
13:48:19 <dhull> Yves: Who needs to know?
13:48:27 <dhull> Glen_and_Noah: Everybody
13:49:05 <dhull> 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 <dhull> GlenD: We think each others arguments are specious.  Obviously a misunderstanding.  Let's solve the disconnect.
13:49:52 <dhull> GlenD: (draws some more)
13:49:58 <dorchard> q?
13:50:33 <marc> ack cferris
13:50:33 <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
13:50:36 <Zakim> ... 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 <dhull> 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 <dhull> 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 <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).
13:52:22 <noah> It doesn't require you to respond to a get or a post for any particular URI.
13:52:28 <marc> ack dorchard
13:52:28 <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 
13:52:32 <marc> q?
13:52:35 <noah> So, you can in fact legally write a binding that says "no" to a get on any particular URI.
13:52:57 <cferris> checking
13:53:20 <dhull> 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 <noah> I think RFC 2616 lets you send a status code for "don't do that op on this URI", no?
13:53:33 <cferris> yes
13:53:45 <cferris> 415 METHOD NOT SUPPORTED
13:53:54 <noah> QED?
13:54:04 <cferris> ok (wise guy!)
13:54:13 <cferris> too tired
13:54:16 <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.
13:54:19 <Yves> 415 is unsupported media type
13:54:20 <dhull> 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 <Yves> 405 is method not allowed
13:54:24 <noah> We got lucky on HTTP, I think.
13:54:33 <cferris> 405?
13:54:50 <noah> Checking
13:54:59 <dhull> 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 <cferris> brain cramp
13:55:25 <cferris> what's up (down actually) with w3.org site?
13:56:04 <noah> 405 Method Not Allowed
13:56:04 <noah>    The method specified in the Request-Line is not allowed for the
13:56:04 <noah>    resource identified by the Request-URI. The response MUST include an
13:56:04 <noah>    Allow header containing a list of valid methods for the requested
13:56:04 <noah>    resource.
13:56:23 <dhull> GlenD: 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 <dhull> GlenD: 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 <noah> Chris: I think we're all pretty impressed with the fact that you got up at 3AM for this!
13:57:38 <dhull> DaveO: There is no consensus whether, if strongly-typed approach is adopted, HTTP would supporte two or three MEPs.
13:57:44 <dhull> GlenD: who believes what?
13:58:05 <cferris> :-)
13:58:28 <dhull> GlenD: Noah, Glen, DaveH think no.
13:59:06 <dhull> DaveO: If FAF is there, and doing an in-only, can just use one-way MEP.
13:59:15 <anish> q?
13:59:25 <dhull> GlenD: But not a good idea.  You would need to say something more on the wire if HTTP does both.
13:59:33 <noah> q+ to talk about dynamically choosing MEPs
13:59:47 <dhull> DaveO: Neither of the choices is good.  Adding one-way adds confusion from need to differentiate on wire.
13:59:55 <dhull> GlenD: Not hard to do, if you want to do it.
14:00:30 <cferris> hmmm
14:00:45 <cferris> guess it could be my broadband provider network that is the problem
14:00:54 <Yves> hum, maybe try www.w3.org instead of w3.org
14:01:00 <dhull> 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 <Yves> might be the redirecter on w3.org
14:01:12 <dhull> omnes: PAOS uses HTTP headers to identify itself
14:01:27 <dhull> GlenD: unfortunately, we don't provide marker.  So we're default.
14:01:29 <cferris> I saw this last week too
14:01:57 <dhull> 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 <dhull> Anish: Can do this now.
14:04:23 <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?
14:04:29 <dhull> 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 <dhull> GlenD: But that's not the picture I'm talking about.  How do you resolve the same question (of what protocol can do) in weakly-typed version?
14:05:42 <dhull> DaveO: Binding exposes uber-MEP.
14:05:50 <dhull> GlenD: Just what does it expose?
14:06:00 <dhull> DaveO: Exposes the properties.
14:06:10 <dhull> DaveH: What props?
14:06:22 <cferris> Noah, you are correct, the spec DOES say MUST support BOTH MEPs... interesting
14:06:28 <dhull> DaveO: Reuqest msg, response mesg. destination etc., as described in proposal.
14:06:29 <cferris> I stand corrected, thanks
14:06:47 <mikem> mikem has joined #xmlprotocol
14:07:14 <dhull> DaveO: Suppose you're using HTTP.  Binding says how props go into MEP.  E.g., request message goes into InboundMessage (?)
14:07:28 <dhull> GlenD: How does app know what binding can do?
14:07:41 <marc> marc has left #xmlprotocol
14:07:48 <dhull> DaveO: Binding says how to put request into props.
14:08:12 <marc> marc has joined #xmlprotocol
14:08:15 <dhull> GlenD: MEP that strongly-typed exposes has semantics.
14:08:26 <dhull> DaveO: That's a fallacy.  E.g look at WSA.
14:08:31 <dhull> GlenD: What do you mean?
14:09:03 <dhull> 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 <mikem> q?
14:09:37 <dhull> DaveO: S.T. approach says you're going to look ahead and build your app based on bindings
14:10:06 <dhull> DaveO: App picks binding, knows what's going to happen.  App knows by what binding it picked what will happen.
14:11:48 <dhull> Noah: 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 <dhull> 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 <dhull> 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 <dhull> DaveO: No, no change.  Uber MEP is request-response MEP.  It has a request bucket and a response bucket.
14:14:05 <dhull> q?
14:15:26 <dhull> DaveH: How do you know you shouldn't use anon for UDP e.g.
14:16:00 <dhull> 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 <cferris> q+
14:19:56 <dhull> 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 <dhull> GlenD: and if you do know, how is that different from strong typing?
14:23:09 <dhull> DaveO: The way the software will know whether anon response endpoints are allowed will depend upon the protocols supported.
14:23:43 <dhull> Noah: So two XMPP bindings had better have the same behavior.
14:23:52 <dhull> Anish: So you mean binding, not protocol.
14:24:01 <cferris> mikem, I'd like to chime in
14:24:16 <cferris> the people in the room have been dominating the discussion
14:24:21 <dhull> 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 <dhull> DaveO: Question is how parameterized are these.
14:25:16 <dhull> Chris: Want to shift discussion to what it is about Noah's proposal that would preculde correct impl.
14:25:31 <dhull> GlenD: I.e., who can't live with it and why
14:25:35 <dhull> Chris: Yes.
14:31:52 <GlenD> GlenD has joined #xmlprotocol
14:35:47 <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?
14:36:27 <dhull> dhull has joined #xmlprotocol
14:57:06 <anish> anish has joined #xmlprotocol
15:01:50 <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?
15:02:15 <noah> No. 
15:02:22 <anish> i would add manifested in the protocol part
15:02:25 <anish> not the soap env
15:02:38 <dhull> GlenD: What does that (chris's question) mean?
15:02:50 <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?
15:02:56 <dhull> Chris: In current (HTTP) case, it's the web method
15:02:56 <anish> ... and given that MEPs are already identified by URIs, this is easy
15:02:59 <dorchard> something like an http header that says "response optional"?
15:03:54 <cferris> actually, I was not thinking that you need anything like: response optional... I think that Noah's proposal handles things nicely
15:03:54 <dhull> 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 <Yves> s/soultion/solution/
15:04:12 <dhull> anish: Need to deal with it in any case (?)
15:04:29 <dhull> Noah: Do we need an exact proposal now?
15:05:01 <marc> marc has joined #xmlprotocol
15:05:17 <anish> perhaps we need two things identified in the protocol: the binding URI and the MEP URI
15:05:18 <dhull> 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 <anish> q+
15:06:05 <dhull> 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 <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
15:06:52 <dhull> 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 <dhull> Chris: just offering to move toward consensus.
15:07:31 <anish> marc, given that we can't someone from creating another http binding, we should provide both
15:07:42 <dhull> 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 <dhull> 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 <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.
15:09:06 <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
15:09:14 <dhull> 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 <dhull> Yves: Not every impl will read this, so still can't rely on it.  (no Mu)
15:09:38 <dhull> s/Mu/mU/
15:09:47 <dhull> Noah: Do we need to go here?
15:09:50 <dhull> Omnes: No
15:10:08 <dhull> GlenD: Can do this later.
15:10:10 <dhull> Anish: Yes.
15:10:15 <noah> Strong +1
15:10:24 <dhull> Yves: Might be nice to signal version in use.
15:10:37 <dhull> GlenD: Chris & Anish take action to work up proposal?
15:10:42 <dhull> Anish: yes
15:11:13 <dhull> 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 <dhull> Chris: Will take action item, yes.
15:11:52 <dhull> Yves: Not differentiating bindings, not MEPs.
15:12:18 <dhull> Noah: Need at least on proposal phrased pertty formally.
15:12:26 <dhull> Anish: Straw poll?
15:12:36 <dhull> Noah: First set down a clear proposal to poll on.
15:12:43 <dhull> Mike: How do we expose this.
15:13:03 <Yves> Agenda: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2006Feb/0030.html
15:13:07 <dhull> GlenD: Noah's email is well-formed, all bows tied up.
15:13:20 <dhull> GlenD: DaveO, you have same?
15:13:34 <dhull> DaveO: Yes, taking addendum into account.
15:13:45 <mikem> Noah proposal: http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html
15:14:00 <dhull> GlenD: If there's a strong leaning one direction, can address objections or work up further details.
15:14:17 <dorchard> Here's the "uber-mep" http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0007.html
15:14:51 <dhull> 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 <dhull> Noah: (1) Clarify optional response in r-r, i.e, SOAP envelope is optional, with 202 in HTTP.  (2) 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:56 <dhull> DaveO: Does 202 allow an envelope?
15:17:25 <dhull> 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 <dhull> Anish: HTTP allows entity body in 202.
15:18:22 <anish> q+
15:18:38 <dhull> 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 <dhull> GlenD: WS-RX acks.
15:19:02 <dhull> Noah: That's just tunneling.  I think that's a misuse of HTTP.
15:19:32 <dhull> DaveO: Uber-MEP proposal more elegantly deals with 202 issue, whether envelope is allowed other than for app response.
15:19:57 <dhull> Noah: Think it's really screwy architecturally, but strongly-typed MEP could be edited to accommodate that.
15:20:00 <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
15:20:18 <dhull> DaveO: <didn't catch>
15:20:35 <cferris> 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 <anish> q+ to ask if we need to decide on the entity body of 202 to get a consensus on the direction
15:21:05 <dhull> 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 <dhull> DaveO: There's a big dragon there in terms of strongly-typed MEPs.
15:22:07 <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.
15:22:14 <dhull> 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 <daveh> cheers, Dave
15:22:48 <dhull> Anish: Do we need to figure out all the details to get consensus on general direction?
15:24:01 <dhull> 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 <cferris> q+
15:24:33 <dhull> 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 <daveh> Some faults are very much like transport failures (e.g. host unreachable)
15:25:14 <dhull> Anish: 202 is intentionally non-commital
15:25:27 <dhull> Anish: Can get fault back on 202.
15:25:37 <dhull> Noah: But that's a definitive problem (200).
15:26:11 <dhull> GlenD: But what about robust in-only.  Does 202 mean no fault happened, but one might happen later.
15:26:19 <cferris> can I gat a word in edgesise?
15:26:25 <cferris> edgewise
15:26:26 <dhull> DaveH: Went over all this in async TF.  It all fell out.
15:26:51 <dhull> 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 <dhull> GlenD: In the absence of any other extensions.
15:27:33 <dhull> 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 <cferris> what I hear Noah saying is that for the use case of ws-rx that [fault endpoint] MUST be non-anonymous
15:27:44 <dhull> GlenD: Not a problem.  WSA can override.
15:28:11 <dhull> GlenD: There is a stack of stuff above at both ends.
15:28:20 <dhull> Anish: True for req-rep, but we're defining a new MEP
15:28:25 <cferris> q?
15:28:29 <dhull> Noah: No, clarifying an existing MEP.
15:28:35 <Zakim> noah, you wanted to talk about dynamically choosing MEPs
15:28:42 <dhull> Noah: In part because implementors have gone this way.
15:28:57 <cferris> ahem
15:29:10 <cferris> *cough*
15:29:22 <dhull> Yves: We have a way to use 204 to say no response.  Quite different from 202, which says nothing about processing.
15:30:46 <dhull> 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 up to a particular point.
15:31:08 <anish> q+ to respond to chris' comment
15:31:44 <dhull> 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 <Yves> mU (so fault) and 202/204 deals with the no processing/mU check | processing/mU check
15:32:29 <dhull> 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 <dhull> Anish: Just making sure everyone understands the proposal.  There are some gray areas to deal with later.
15:32:54 <dhull> Chris: Cant' sort them out here.
15:33:01 <dhull> Mike: In violent agreement here.
15:33:07 <cferris> s/Can't/Don't/
15:33:17 <dhull> Anish: Dont' quite agree on 202 but will sort out later.
15:33:34 <noah> From: http://www.w3.org/TR/soap12-part2/#bindfaulthdn
15:33:45 <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."
15:33:49 <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
15:33:53 <dhull> 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 <anish> ... 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 <dhull> DaveO: Is that two instances of req-rep?  Do I shut down and switch MEPs.
15:35:17 <anish> chris -- daveo is drawing a diagram on the whiteboard
15:36:18 <cferris> 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 <dhull> 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 <dhull> DaveO: ReplyTo will have http:, or smtp: or whatever, telling it what to use.  Then has to pick MEP.
15:39:16 <dhull> 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 <dhull> DaveO: There's no info ahead of time.
15:40:20 <dorchard> dorchard has joined #xmlprotocol
15:40:31 <Zakim> -Chris_Ferris
15:41:05 <dhull> Noah: You know in advance there are only two code paths, regardless of how many protocols you actually support.
15:41:08 <Zakim> +Chris_Ferris
15:41:10 <Zakim> -Chris_Ferris
15:41:11 <Zakim> +Chris_Ferris
15:41:16 <Zakim> -Chris_Ferris
15:41:41 <dhull> Noah: Proposing note 50 + promise of future FAF MEP.
15:41:56 <Zakim> +Chris_Ferris
15:41:58 <Zakim> -Chris_Ferris
15:41:59 <anish> i would rather call it one-way mep than faf mep
15:41:59 <Zakim> +Chris_Ferris
15:42:27 <noah> My proposal is roughly:
15:42:38 <cferris> DaveO, if you are saying that an EPR can't communicate the characteristics of the MEP, then I would agree
15:43:13 <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
15:43:26 <dhull> 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 <dhull> that SOAP envelope is optional in r-r.
15:43:48 <dhull> (previous is pasted from previous minutes)
15:43:52 <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
15:46:20 <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.
15:46:53 <cferris> so, you are suggesting, for instance, that the HTTP method should be communicated in the EPR?
15:47:16 <cferris> for the case of an HTTP-based response endpoint?
15:48:22 <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
15:48:28 <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
15:49:12 <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
15:49:28 <dhull> Mike: Poll -- Who agrees this is good direction?
15:50:05 <dhull> Chris: Agree, but want to know form of (2).  Addendum or separate rec-track doc?
15:50:53 <dhull> 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 <Yves> btw 202 vs 204 may be seen as faf vs non faf one way (or ror)
15:51:15 <dhull> Chris: Step 1 could be errata, but 2 is too big for this.
15:51:26 <dhull> Mike: Notes vote was 9-1.
15:51:56 <dhull> Noah: 2nd addition means nothing more than errata?  Can we add MEP?
15:52:03 <dhull> Yves: If it's just clarifying material.
15:52:08 <dhull> Noah: That's a big stretch.
15:52:29 <noah> Noah proposal: if it can't be second edition, then SOAP 1.2 Part 3:  additional MEPs and Features
15:52:36 <dhull> Chris: +1.  Considering rec track proposal (?).  Think this affects my vote.
15:52:39 <dorchard> 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 <dhull> Chris: Concerned this will take so long as to become irrelevant.
15:53:07 <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
15:53:24 <dhull> Chris: Not in favor of both at same time.
15:53:32 <dhull> Noah: Would have to go through CR.
15:53:37 <dhull> q+
15:53:58 <dhull> Noah: Don't want SOAP 1.3.  What about SOAP 1.2 part 3.
15:54:02 <cferris> +1
15:54:06 <marc> +1
15:54:10 <Yves> +1
15:54:15 <herve> +1
15:55:50 <cferris> q-
15:55:54 <dhull> 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 <anish> ack an
15:56:01 <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
15:56:09 <dhull> Noah: Fine [in fact, Noah actually proposed it]
15:56:40 <cferris> works for me
15:57:55 <dhull> Mike: Formal vote?
15:58:12 <dhull> Noah: Should we continue to work for consensus since there isn't one yet?
15:58:19 <dhull> DaveO: It's time to decide.
15:58:28 <dhull> GlenD: You want objection noted?
15:59:18 <dhull> 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 <dhull> Mike: Separate issue is Dave's new style (no state machine) for new work.
16:01:09 <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.
16:01:10 <dhull> Mike: Formal vote by company
16:03:03 <dhull> RESOLUTION: Parts (1) and (2) as minuted above.  Formal vote: Yes: IBM, Nokia, Sonic, Canon, Sun, Oracle, W3C, TIBCO.  No: BEA
16:03:36 <dhull> Noah: (abstentions: none)
16:03:45 <noah> s/Noah/Note/
16:04:27 <dhull> Mike: Straw poll: Amendement for part (2) above, use simplified MEP description style
16:06:12 <dhull> Note: simplified MEP style for new work
16:06:28 <dhull> Mike: 9 yes 1 abstain
16:06:29 <dorchard> For the record, I'd be glad to do editorial work on any one-way work.
16:06:55 <cferris> abstain means you are going along with whatever the group decides
16:09:06 <Yves> (just for the record) 204 may be better than 202, and 202 reserved for "true" one way
16:09:08 <cferris> lol
16:09:26 <dhull> 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 <dhull> Noah: Hoping this is a small amount of work.
16:10:38 <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?
16:10:41 <DaveO> DaveO has joined #xmlprotocol
16:10:53 <anish> chris, i think that is clear
16:11:04 <cferris> ok, just checking
16:11:32 <cferris> I think I misunderstood the bit about 202/204 as relates to "true" one-way
16:11:45 <Yves> I meant without a backchannel for faults
16:11:56 <cferris> I don't think that is what we are doing
16:12:04 <cferris> we are doing R-O-R
16:12:10 <cferris> there is a back-channel
16:12:20 <Yves> so as rr impliues backchannel, 204 is more suited
16:12:24 <cferris> in terms of the one-way MEP, then there is no backchannel
16:12:26 <Yves> s/rr/ror/
16:12:44 <Yves> so 202 looks more like one-way as there is no backchannel
16:13:19 <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
16:13:32 <dhull> Mike: Need to capture how we're going to publish this.
16:13:33 <cferris> because "processed" might mean, queued for processing
16:13:35 <noah> URI for instructions for running scribe.perl: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
16:13:51 <noah> URI for scribe.perl itself: http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/
16:13:59 <Yves> we can talk about the semantic of 200/204, but 202 really means that no processing happened
16:14:14 <Yves> so no mU were checked
16:14:15 <cferris> yes
16:14:17 <dhull> Note: We will not produce an HTTP binding for one-way MEP in (2).
16:14:22 <noah> URI for scribe.perl itself: http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribe.perl
16:16:13 <dhull> 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 <cferris> we call it Fred
16:16:44 <dhull> Anish: Still need to discuss issues, now that we've decided overall direction
16:17:08 <dhull> DHull: Will part 3 have its own issues list?
16:17:17 <dhull> Mike: Yves?
16:17:26 <dhull> Yves: Can reuse existing list.
16:18:06 <dhull> Anish: Issue 3) (Yves) 202 vs 204  4) possible HTTP header signalling binding, MEP
16:18:33 <dhull> Mike: Actions, ownership:
16:19:27 <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.
16:19:35 <noah> Anish: regrets for next two weeks
16:19:52 <dhull> ACTION: Anish to start email discussion of what does FAF really mean? 
16:20:04 <dhull> ACTION: Yves to start discussion of 202 vs. 204
16:20:30 <dhull> ACTION: Marc to start discussion of possible HTTP header signalling binding/MEP
16:20:30 <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?
16:21:02 <dhull> Note: What does FAF mean and what timing issues are there are actually the same issue (actioned to Anish)
16:22:45 <noah> My key points are effectively in the resolution:
16:23:00 <dhull> Chris: Could people please provide pointers to key emails in previous discussion of "what does FAF mean" issue.
16:23:09 <dhull> Mike: This seems part of starting email discussion.
16:23:23 <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.
16:23:35 <noah> 2) Therefore, this MEP is mainly for datagram-like protocols.
16:23:42 <noah> Chris, those two points are my main input.
16:23:46 <dhull> Mike: Meet a week from Wednesday?
16:23:51 <dhull> Omnes: General approval.
16:23:52 <anish> noah, what MEP would you use for queueing/messaging/jms?
16:24:08 <anish> that is where it gets tricky
16:24:11 <cferris> thanks, noah
16:24:14 <dhull> Mike: Next meeting March 15
16:26:50 <dhull> 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 <dhull> ACTION: Noah to suggest how the group should proceed in reviewing draft (suggestion will probably be what I just said)
16:27:51 <dhull> Mike: Anything else?
16:27:54 <dhull> Omnes: No.
16:28:05 <cferris> DaveH, did you mean Noah instead of Mike in reference to "my draft"?
16:29:49 <dhull> s/Mike: I believe my/Noah: I believe my/
16:30:01 <Zakim> -Chris_Ferris
16:30:07 <cferris> ciao
16:30:11 <anish> cya
16:30:19 <dhull> Mike: Adjourned
16:30:20 <Zakim> -Tp_iles_a
16:30:21 <cferris> or should I say au revoir
16:30:21 <Zakim> WS_XMLP(TP)4:00AM has ended
16:30:23 <Zakim> Attendees were David_Orchard, David_Hull, Glen_Daniels, Yves_Lafon, Marc_Hadley, Anish_Karmarkar, Noah_Mendelsohn, Chris_Ferris, Herve Ruellan, Michael_Mahan
16:30:46 <cferris> cferris has left #xmlprotocol
16:33:59 <mikem> rrsagent, draft minutes
16:33:59 <RRSAgent> I have made the request to generate http://www.w3.org/2006/03/04-xmlprotocol-minutes.html mikem
16:38:28 <noah> rrsagent, make log public
16:39:02 <noah> rrsagent, where am I?
16:39:02 <RRSAgent> See http://www.w3.org/2006/03/04-xmlprotocol-irc#T16-39-02
16:40:10 <noah> rrsagent, please generate minutes
16:40:10 <RRSAgent> I have made the request to generate http://www.w3.org/2006/03/04-xmlprotocol-minutes.html noah