See also: IRC log
<cferris> let me clarify my point... the essence of the binding doesn't necessarily change based on whether you are doing a request-response or a oneway
<cferris> I think we have already covered that
<cferris> HTTP is inherently request-response
<cferris> the question is whether there is a SOAP envelope in the request or response
<cferris> in either case, you are obligated to await the response
<cferris> the thing that concerns me is that some may incorrectly (IMO) assume that because the WSDL says oneway, that there is some assumption that there will not be a SOAP envelope in the HTTP response (in the case of the SOAP/HTTP binding)
<mikem> hi chris we are about to get started
<cferris> k, dialing
<dorchard> Chris, in the case of WSDL one-way using SOAP/HTTP, I think all the proposed bindings say that there might be a response.
<cferris> in that case, it really isn't different than the R-O-R, is it?
<scribe> scribenick: dhull
<scribe> scribe: David Hull
<cferris> brb
<cferris> back
<cferris> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0000.html
<cferris> could someone describe what glen is drawing?
<cferris> I have a little difficulty seeing it at this distance
<daveh> let's wait until they decide that they want to draw
glen: I have a WSDL operation I need to connect to what I actually have. I might have a "req-resp" thing to connect to, or a one way. Need a layer in between to do the connection.
daveO: That's SOAP MEPs at the bottom?
Glen: yes
daveO: In your view you need a binding underneath
Glen: no
Noah: Underneath the boxes you have things like HTTP, XMPP iq, or UDP, XMPP msg
... you write general software that knows how to handle this e.g., request-response or FAF -- FAF means no timing issues.
<anish> FAF does not necessarily mean that there are no timing issues
Noah: Strongly typed MEPs give factoring.
<daveh> just scribing, Anish
Noah: Describing strongly typed. Question for DaveO is how does weakly typed do this. To be answered.
... Application will look up endpoint and need to know "can I use this transport" "can I code to convenient API". This architecture is a factoring of what's common to transports. Under SOAP 1.2, we call this factored bit an MEP.
... Defining an MEP encourages software that uses that factoring, but doesn't force it.
daveO: Doesn't the app (doing r-r over one-way) ... you don't show the connection between HTTP and out/in. (?)
noah: So consider in-only WSDL MEP. You might come up with in-only Java API (e.g.). Where can I support that? Depending on what I want to do, in a lot of places. Could write directly to transport bindings -- easy for UDP-like protocols.
... So App doesn't have to know anything about transports. But what if it's in-only at WSDL level, but over HTTP. Could directly call HTTP, but because we have strongly-typed SOAP MEPS, can write shim between in-only (WSDL) and request-response (SOAP)
... Now have two ways of doing in-only. One over (all) request-response, one over (all) FAF, not 4 (i.e. one for each protocol)
... E.g., spinning off a thread to wait for response happens just one place.
... Clearly this doesn't have to be presented in terms of MEPS
glenD: Extend this to robust in-only (cool case), too
daveO: Don't disagree with this style of writing APIs.
noah: APIs follow naturally from strongly-typed MEPs. Good Thing.
... Also guide protocol people (e.g. XMPP) as to what things to support. If you can happily implement an existing MEP, good chance you can just plug in. If you have troubles, then you know you probably won't "just work". Can define new MEP that works for you and others can leverage that.
... Wrapping up suites of function in bulk encourages operability. 95-5 case. Just like read/write/open/close. Most code shared, occasional special case.
<cferris> http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/0000.html
chris: Put link into IRC of email to dist-app.
... Wanted to respond to discussion before lunch break. Appreciate point Noah makes about APIs. Perhaps I was making too fine a distinction, but ...
... have to consider with the SOAP MEPs we're considering don't have a binding that supports multiple MEPs, but multiple bindings. Even in case of WSA anonymous response endpoints, SOAP faults (mU, version) must be generated before WSA processing.
... WSA headers are just qnames at this point. There is always case for SOAP envelope back on response channel. So maybe we can do that and layer on other MEPs. Unless you have done something different in binding (e.g. HTTP header that says no response), can't really support one-way over HTTP.
Glen: this is already agreed.
Noah: He's responding to an IRC comment I made.
chris: unless you're changing behavior of underlying protocol, not safe to layer one-way over req-resp.
<marc> so, to cut to the chase Chris are you saying that we just make the response optional and we are done ?
chris: In case of response MEP, it's a separate binding. Rules are different, different HTTP verb (GET vs POST). Layering one-way over request-response is changing the underlying binding. Unless communicating through binding (in non-SOAP way) what MEP is in play, then can't support multiple MEPs.
... In r-o-r, fault will come back, can't mask out.
<daveh> SOAP mU fault etc. => transport failure.
DaveO: by Noah's argument, we would have no one-way software without one-way MEP. For eons. Our providing one-way MEP won't help.
Noah: They're going directly over UDP and tracking distinctions themselves. Otherwise going over HTTP.
DaveO: Going over HTTP, SMTP, JMS
Glen: Don't deny benefit to software construction, but also helps other spec writers.
... Mapping of in-out to FAF is valuable per se (?)
DaveO: Main point is helping people write specs. Don't buy help to constructing software.
... Data available to spec writers is important.
<cferris> marc: yes
Noah: Already made the choice of style (to use MEPs). This extension is a small bump on what's already there. Like tweaking a class or two, not changing object structure.
DaveO: Not what I meant
Noah: This is how it's coming across to me. Structurally r-o-r (and maybe adding FAF) is a small change.
<cferris> +1
GlenD: Would not go into HTTP binding.
... If you need to know what MEP is action, need to do it before SOAP
Yves: Who needs to know?
Glen_and_Noah: Everybody
DaveO: My point is, you're right. Who needs to know. Strongly-typed MEPs doesn't help, actually confuses issue. You need to look elsewhere.
GlenD: We think each others arguments are specious. Obviously a misunderstanding. Let's solve the disconnect.
... (draws some more)
<Zakim> cferris, you wanted to finish my thought that IMO, with the current state of affairs, leaving aside the fact that people aren't doing SRR as written in today's REC, that few are
chris: picking up train of thought ... leaving aside that people are not doing req-resp as written, few are doing SOAP response. Really are two different bindings. Can't use SOAP response with any given endpoint. Nothing in spec says must support both of them.
... Maybe can make some abstractions and describe differently in terms of MEP supported by same binding, but really there are special properties supported by bindings and not envelope, or you don't have support for multiple MEPs per binding.
<noah> I think that in the particular case of the HTTP binding, the spec says you DO have to support both MEPs, BUT (important caveat coming).
<noah> It doesn't require you to respond to a get or a post for any particular URI.
<Zakim> dorchard, you wanted to point out that if "one-way" meps helped build software, we wouldn't have any one-way software because we don't have a one-way mep yet.. and to
<noah> So, you can in fact legally write a binding that says "no" to a get on any particular URI.
<cferris> checking
glenD: (describes picture) You have an HTTP binding with Req/resp and SOAP resp, plus other properties (proxy? HTTPS). At this level doesn't matter that it's HTTP. HTTP-ness is encapsulated. MEP specs are exactly what the rest of the world deals with.
<noah> I think RFC 2616 lets you send a status code for "don't do that op on this URI", no?
<cferris> yes
<cferris> 415 METHOD NOT SUPPORTED
<noah> QED?
<cferris> ok (wise guy!)
<cferris> too tired
<noah> I do think the business of figuring out what you're doing in the case that there is more than one is indeed an important and dangerous aspect of the design.
<Yves> 415 is unsupported media type
GlenD: When you have this picture (leading in to strongly-typed case) Suppose some software has 50 bindings underneath, and somehow we select one. Each binding is black box. Features and properties are exposed. That's MEPs and other features and props.
<Yves> 405 is method not allowed
<noah> We got lucky on HTTP, I think.
<cferris> 405?
<noah> Checking
GlenD: So if I'm doing an in-out, and I see I have request-response available from my binding, my middleware knows how to bind it.
<cferris> brain cramp
<cferris> what's up (down actually) with w3.org site?
<noah> 405 Method Not Allowed
<noah> The method specified in the Request-Line is not allowed for the
<noah> resource identified by the Request-URI. The response MUST include an
<noah> Allow header containing a list of valid methods for the requested
<noah> resource.
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)
... Can you explain this in terms of weakly-typed, or show problem with this. It seems you have to look inside the boxes.
<noah> Chris: I think we're all pretty impressed with the fact that you got up at 3AM for this!
DaveO: There is no consensus whether, if strongly-typed approach is adopted, HTTP would supporte two or three MEPs.
GlenD: who believes what?
<cferris> :-)
GlenD: Noah, Glen, DaveH think no.
DaveO: If FAF is there, and doing an in-only, can just use one-way MEP.
GlenD: But not a good idea. You would need to say something more on the wire if HTTP does both.
DaveO: Neither of the choices is good. Adding one-way adds confusion from need to differentiate on wire.
GlenD: Not hard to do, if you want to do it.
<cferris> hmmm
<cferris> guess it could be my broadband provider network that is the problem
<Yves> hum, maybe try www.w3.org instead of w3.org
Anish: Chris has argued that because of mU processing, have to allow faults to come back. Otherwise have to prohibit on wire (e.g. HTTP header). Another reason to do that anyway is that our binding is not only possible HTTP binding. In fact, PAOS is also an HTTP binding (over SOAP 1.1).
<Yves> might be the redirecter on w3.org
omnes: PAOS uses HTTP headers to identify itself
GlenD: unfortunately, we don't provide marker. So we're default.
<cferris> I saw this last week too
Anish: We have a chance to fix this. This is not *the* HTTP binding. Would be nice to define header as marker, defining binding, MEP or both.
... Can do this now.
<cferris> so, Noah, if I understand what you are going to say (I can read minds), then you are arguing for the requirement that IFF a binding supports multiple MEPs, then each MEP MUST (SHOULD?) distinguish itself in a manner that is specific to the underlying transport/transfer rather than via SOAP?
DaveO: Challenge I put out is that there is not consensus. How many MEPs depends on how you look at it. If HTTP supports both r-r and faf, receiver has to distinguish.
GlenD: But that's not the picture I'm talking about. How do you resolve the same question (of what protocol can do) in weakly-typed version?
DaveO: Binding exposes uber-MEP.
GlenD: Just what does it expose?
DaveO: Exposes the properties.
DaveH: What props?
<cferris> Noah, you are correct, the spec DOES say MUST support BOTH MEPs... interesting
DaveO: Reuqest msg, response mesg. destination etc., as described in proposal.
<cferris> I stand corrected, thanks
DaveO: Suppose you're using HTTP. Binding says how props go into MEP. E.g., request message goes into InboundMessage (?)
GlenD: How does app know what binding can do?
DaveO: Binding says how to put request into props.
GlenD: MEP that strongly-typed exposes has semantics.
DaveO: That's a fallacy. E.g look at WSA.
GlenD: What do you mean?
... I know that *something* is going to come back. WSA doesn't affect that. Take "request-response" to mean "request-opt-response"
DaveO: S.T. approach says you're going to look ahead and build your app based on bindings
... App picks binding, knows what's going to happen. App knows by what binding it picked what will happen.
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.
DaveO: IMO the advantage of W.T. is that props are exposed. When we wrote WSA SOAP binding, it was the same properties, regardless of anon or non-anon reply.
GlenD: But what we say in WSA SOAP binding is that anon response will be part of same SOAP MEP instance. With W.T. that would have to care whether you're using HTTP or whatever.
DaveO: No, no change. Uber MEP is request-response MEP. It has a request bucket and a response bucket.
DaveH: How do you know you shouldn't use anon for UDP e.g.
DaveO: If you have an anon value, you'll get response from current instance of Uber MEP. Non-anon means two instances of Uber MEP.
Marc: A coherent answer would have been, no OutboundMessage property in binding. If it has OutboundMessage, how do you know it's never populated?
GlenD: and if you do know, how is that different from strong typing?
DaveO: The way the software will know whether anon response endpoints are allowed will depend upon the protocols supported.
Noah: So two XMPP bindings had better have the same behavior.
Anish: So you mean binding, not protocol.
<cferris> mikem, I'd like to chime in
<cferris> the people in the room have been dominating the discussion
Noah: So if I have a new "Dave's binding", how do I tell, given just the name, what to do. Seems like I have to ask a person.
DaveO: Question is how parameterized are these.
Chris: Want to shift discussion to what it is about Noah's proposal that would preculde correct impl.
GlenD: I.e., who can't live with it and why
Chris: Yes.
<cferris> would addition of a requirement in the spec (part 1 I think) that said: "an MEP MUST be explicitly manifested in the SOAP binding IFF there are more than one MEPs that are supported" address some people's concerns?
<cferris> 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?
<noah> No.
<anish> i would add manifested in the protocol part
<anish> not the soap env
GlenD: What does that (chris's question) mean?
<noah> The reason I don't like this, is that it doesn't provide the key function: if two bindings support the same single MEP, then neither is documenting that it does. What am I missing?
Chris: In current (HTTP) case, it's the web method
<anish> ... and given that MEPs are already identified by URIs, this is easy
<dorchard> something like an http header that says "response optional"?
<cferris> actually, I was not thinking that you need anything like: response optional... I think that Noah's proposal handles things nicely
GlenD: Don't need to go there right now. There is a minimal solution we can do -- ratify what impls do anyway, make WSA, WSDL 2.0 happy, handle robust in-only, without a lot of extra work. Would make me happy
anish: Need to deal with it in any case (?)
Noah: Do we need an exact proposal now?
<anish> perhaps we need two things identified in the protocol: the binding URI and the MEP URI
Noah: If it's helpful to go into this, we can. Like Glen would prefer to ask how close are we to big-picture consensus answer. I know Chris offered this to be helpful, but I don't need to do it to be heard.
Chris: In response to your point in IRC: my point was not to document that a particular MEP was in play MEP must be distinguishible when more than one supported.
<marc> we either need to have a single HTTP binding and identify the MEP in use or have multiple bindings (one per MEP) and identify the binding in use or some combination of the two
Noah: What you said was self-evident, we should say each binding names URI of MEP it supports. If you think something's broken, we can debate it. Otherwise don't need to discuss it.
Chris: just offering to move toward consensus.
<anish> marc, given that we can't someone from creating another http binding, we should provide both
Chris: bringing this is as guidance to authors of bindings. You make MEP explicit through the binding. Can go without this if it's not helpful.
Anish: May need to identify both -- binding in effect and MEP in effect. Otherwise message can look exactly the same in different circumstances. Don't stop someone from defining their own HTTP binding. Would be nice to define particular HTTP header to key off of.
<noah> Anish suggests that bindings must indicate on the wire what MEP is in use at a given time. I think that's probably a good thing to have in most cases, but I think we need a longer discusion to decide whether we always need that, and I don't see settling that as being on the critical path for today.
<marc> anish, true though you could say that would be their problem to co0me up with some way to identify their new binding and (possibly) make sure its compatible with our binding in some way
Anish: Typically impls ignore HTTP headers they don't understand. Would be nice if we defined it and asked binding authors to use it.
Yves: Not every impl will read this, so still can't rely on it. (no mU)
Noah: Do we need to go here?
Omnes: No
GlenD: Can do this later.
Anish: Yes.
<noah> Strong +1
Yves: Might be nice to signal version in use.
GlenD: Chris & Anish take action to work up proposal?
Anish: yes
Chris: Wouldn't oppose this. Personal opinion is don't need to distinguish, say, r-o-r and one-way, that's actually bad.
... Will take action item, yes.
Yves: Not differentiating bindings, not MEPs.
Noah: Need at least on proposal phrased pertty formally.
Anish: Straw poll?
Noah: First set down a clear proposal to poll on.
Mike: How do we expose this.
GlenD: Noah's email is well-formed, all bows tied up.
... DaveO, you have same?
DaveO: Yes, taking addendum into account.
<mikem> Noah proposal: http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html
GlenD: If there's a strong leaning one direction, can address objections or work up further details.
<dorchard> Here's the "uber-mep" http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0007.html
Noah: My proposal is roughly SOAP 1.2 with these deltas (no changes to defn of MEP, no getting rid of state manchines -- that's orthogonal).
... (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)
DaveO: Does 202 allow an envelope?
Noah: Not as I've drafted it. Never chooses to use it. Signal as to whether you got an envelope is 200 vs. 202.
Anish: HTTP allows entity body in 202.
Noah: Would be misuse from HTTP point of view. Not hung up on it either way. Note at higher level that MEP is request-optional envelope response. What do you want to put there?
GlenD: WS-RX acks.
Noah: That's just tunneling. I think that's a misuse of HTTP.
DaveO: Uber-MEP proposal more elegantly deals with 202 issue, whether envelope is allowed other than for app response.
Noah: Think it's really screwy architecturally, but strongly-typed MEP could be edited to accommodate that.
<cferris> I disagree that sending a WS-RX Ack as a 202 entity body is an abuse of HTTP... to say that the message is unrelated is IMO, not the case. It is related by virtue of the RM Sequence
DaveO: <didn't catch>
<cferris> to say that a SOAP envelope carried as a request only applies to the content of the SOAP body isn't correct IMO
Noah: If it's a common pattern across protocols, write it up in MEP. If it's just an HTTP thing, don't put it in MEP, it's a binding-specific feature (also allowed)
DaveO: There's a big dragon there in terms of strongly-typed MEPs.
<dorchard> I pointed out that a soap envelope in the http response might not be the "response" of a SOAP request-response MEP, and that's a problem with the strongly typed MEP approach.
Noah: It's a design call whether to put it in MEP or in binding-specific. Kind of like IOCTL. Certainly is ugly.
<daveh> cheers, Dave
Anish: Do we need to figure out all the details to get consensus on general direction?
Noah: One other complicating factor: SOAP MEPs are supposed to tell you what to do with faults. 202 may mean "didn't want to run SOAP processing model yet" (so no fault will come back), or it may mean that SOAP processing has happened, but we're not done (so faults could come back).
... MEP tends to say fault should come back to sender. In WSA world there are issues of where and when to direct faults.
<daveh> Some faults are very much like transport failures (e.g. host unreachable)
Anish: 202 is intentionally non-commital
... Can get fault back on 202.
Noah: But that's a definitive problem (200).
GlenD: But what about robust in-only. Does 202 mean no fault happened, but one might happen later.
<cferris> can I gat a word in edgesise?
<cferris> edgewise
DaveH: Went over all this in async TF. It all fell out.
Noah: I believe proposal we're voting on says that, at the MEP level, if there is an error in the request, the fault will come back to the requestor.
GlenD: In the absence of any other extensions.
Noah: SOAP req-rep MEP says if there is an error in request, SOAP fault will be generated, sent back in place of reply. That's the problem.
<cferris> what I hear Noah saying is that for the use case of ws-rx that [fault endpoint] MUST be non-anonymous
GlenD: Not a problem. WSA can override.
... There is a stack of stuff above at both ends.
Anish: True for req-rep, but we're defining a new MEP
Noah: No, clarifying an existing MEP.
<Zakim> noah, you wanted to talk about dynamically choosing MEPs
Noah: In part because implementors have gone this way.
<cferris> ahem
<cferris> *cough*
Yves: We have a way to use 204 to say no response. Quite different from 202, which says nothing about processing.
Chris: Think there will be issue in WS-RX to discuss this issue, whether it's a 202 and how much SOAP processing has to happen. My opinion: if doing reliable messaging, have to do SOAP processing, at least up to a particular point.
... have to figure out mU and which ones you can do if you're doing any reliable mesging at all. You could have an interchange with 202, but you would never get an mU fault. Flowing acks back on response is related to processing of message.
<Yves> mU (so fault) and 202/204 deals with the no processing/mU check | processing/mU check
Chris: Probably do need to clarify (in WS-RX?). Want to come back to discussion after break. Is Noah's proposal close enough to take that direction and declare victory. Who has heartburn. Seem to be off in weeds now.
Anish: Just making sure everyone understands the proposal. There are some gray areas to deal with later.
Chris: Cant' sort them out here.
Mike: In violent agreement here.
Anish: Dont' quite agree on 202 but will sort out later.
<noah> From: http://www.w3.org/TR/soap12-part2/#bindfaulthdn
<noah> "If a SOAP fault is generated by the responding SOAP node while it is in the "Receiving" state, the SOAP fault is made available in http://www.w3.org/2003/05/soap/mep/OutboundMessage and the state machine transitions to the "Receiving+Sending" state."
<anish> chris -- i think it is fine for wsrx to say that when sending back 202 make sure u do the mU processing, but I don't want to say that in the general case
DaveO: In terms of S.T. proposal, what goes on at receiver when WSA message is sent in in-out, replyTo implies separate connection, e.g. an SMTP connection?
<anish> ... cause I have usecases where it is truely doing queue, without checking the soap message and I would like to enable those cases
DaveO: Is that two instances of req-rep? Do I shut down and switch MEPs.
<anish> chris -- daveo is drawing a diagram on the whiteboard
<cferris> I hope someone is capturing the drawings and can possibly inline them into the minutes since I think that they will be valuable
DaveH: Will always have one instance of r-o-r/HTTP for this example. Separately, another MEP for reply; r-o-r or FAF depending on transport used for reply.
DaveO: ReplyTo will have http:, or smtp: or whatever, telling it what to use. Then has to pick MEP.
Noah: This is a feature. If smtp, send message and disappear. If http, has to send message and hang and wait. S.T. approach tells responder its responsibilities.
DaveO: There's no info ahead of time.
Noah: You know in advance there are only two code paths, regardless of how many protocols you actually support.
... Proposing note 50 + promise of future FAF MEP.
<anish> i would rather call it one-way mep than faf mep
<noah> My proposal is roughly:
<cferris> DaveO, if you are saying that an EPR can't communicate the characteristics of the MEP, then I would agree
<noah> 1) Take the existing req/resp MEP, make clear that envelope in response is optional, signal lack of envelope with 202, and update http binding to match. THat's in draft linked from http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html
Noah: My proposal is roughly SOAP 1.2 with these deltas (no changes to defn of MEP, no getting rid of state manchines -- that's orthogonal). Clarify optional response in r-r, with 202 in HTTP. Recognize request for development of one-way fire-and-forget for protocols in which no signalling through the network is needed at time of sending (i.e., buffering for sending is enough) i.e. clarify
that SOAP envelope is optional in r-r.
(previous is pasted from previous minutes)
<noah> 2) Prepare a one way fire & forget MEP, making clear that this is for use with protocols in which you do not have to wait for network acknowledgements before proceeding at the sender site
<dorchard> Chris, that's roughly right. I think that the strongly-typed meps don't help the recieverr because it does it's determination of connections based upon the EPR, and 2 meps vs 1 mep doesn't do anything for it.
<cferris> so, you are suggesting, for instance, that the HTTP method should be communicated in the EPR?
<cferris> for the case of an HTTP-based response endpoint?
<noah> 1) Take the existing req/resp MEP, make clear that envelope in response is optional, signal lack of envelope with 202 and/or 204 as appropriate (TBD if this proposal is accepted), and update http binding to match. THat's in draft linked from http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0050.html
<noah> 2) Prepare a one way fire & forget MEP, making clear that this is for use with protocols in which you do not have to wait for network acknowledgements before proceeding at the sender site
<Yves> chris, if EPR were about adding informations to the URI like the protocol context (HTTP verbs, some context headers), I would have bene happy with EPRs
Mike: Poll -- Who agrees this is good direction?
Chris: Agree, but want to know form of (2). Addendum or separate rec-track doc?
Noah: Haven't thought it through. People (e.g., DHull) have repeatedly asked. Want least overhead in process, minimal pain for rest of SOAP.
<Yves> btw 202 vs 204 may be seen as faf vs non faf one way (or ror)
Chris: Step 1 could be errata, but 2 is too big for this.
Mike: Notes vote was 9-1.
Noah: 2nd addition means nothing more than errata? Can we add MEP?
Yves: If it's just clarifying material.
Noah: That's a big stretch.
<noah> Noah proposal: if it can't be second edition, then SOAP 1.2 Part 3: additional MEPs and Features
Chris: +1. Considering rec track proposal (?). Think this affects my vote.
<dorchard> You'd have to do the new MEP in a Rec track as there's no CR results for it as an errata
Chris: Concerned this will take so long as to become irrelevant.
<noah> So, do part 1 in SOAP part 2 2nd edition, and put the new one-way MEP in a new Part 3, which would have to go through CR
Chris: Not in favor of both at same time.
Noah: Would have to go through CR.
... Don't want SOAP 1.3. What about SOAP 1.2 part 3.
<cferris> +1
<marc> +1
<Yves> +1
<herve> +1
DaveH: Friendly amendment: Note with (1) that this is not the answer for datagram protocols, this is to come in work for (2).
<Zakim> anish, you wanted to ask if we need to decide on the entity body of 202 to get a consensus on the direction and to respond to chris' comment
Noah: Fine [in fact, Noah actually proposed it]
<cferris> works for me
Mike: Formal vote?
Noah: Should we continue to work for consensus since there isn't one yet?
DaveO: It's time to decide.
GlenD: You want objection noted?
DaveO: Want complete victory, but that's not going to happen. WG has given my proposal considerable amount of discussion. Given that no one else has come on board, time to move on. Appreciate opportunity to champion decision, but time to move on.
Mike: Separate issue is Dave's new style (no state machine) for new work.
<dorchard> I should say, I would have liked to have convince the WG of the uber-mep approach, but that doesn't appear likely given more time. I thank the chair and the WG for the opportunity to champion it. We should have a vote on the issue and proceed.
Mike: Formal vote by company
RESOLUTION: Parts (1) and (2) as minuted above. Formal vote: Yes: IBM, Nokia, Sonic, Canon, Sun, Oracle, W3C, TIBCO. No: BEA
Note: (abstentions: none)
Mike: Straw poll: Amendement for part (2) above, use simplified MEP description style
Note: simplified MEP style for new work
Mike: 9 yes 1 abstain
<dorchard> For the record, I'd be glad to do editorial work on any one-way work.
<cferris> abstain means you are going along with whatever the group decides
<Yves> (just for the record) 204 may be better than 202, and 202 reserved for "true" one way
<cferris> lol
Noah: I will take responsibility for MEP and binding-related stuff. My intention is not to do much in the next few days as we debate things like 202/204. Assume that's the base text, I'll take a pass when debate dies down. Will make sure this gets into a copy with other errata.
... Hoping this is a small amount of work.
<cferris> can we be clear that the step 2 of Noah's proposal is JUST the MEP and that we are not doing an HTTP binding for that?
<anish> chris, i think that is clear
<cferris> ok, just checking
<cferris> I think I misunderstood the bit about 202/204 as relates to "true" one-way
<Yves> I meant without a backchannel for faults
<cferris> I don't think that is what we are doing
<cferris> we are doing R-O-R
<cferris> there is a back-channel
<Yves> so as rr impliues backchannel, 204 is more suited
<cferoris> in terms of the one-way MEP, then there is no backchannel
<Yves> so 202 looks more like one-way as there is no backchannel
<cferris> 204 means "no response", 202 means "accepted, not processed" 200 means processed, but IMO it does not mean that the response is THE application-level response
Mike: Need to capture how we're going to publish this.
<cferris> because "processed" might mean, queued for processing
<noah> URI for instructions for running scribe.perl: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
<noah> URI for scribe.perl itself: http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/
<Yves> we can talk about the semantic of 200/204, but 202 really means that no processing happened
<Yves> so no mU were checked
<cferris> yes
Note: We will not produce an HTTP binding for one-way MEP in (2).
<noah> URI for scribe.perl itself: http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribe.perl
Anish: Issues -- 1) Fire and Forget implies something not true in every case, so what do we call it? 2) What timing issues are there?
<cferris> we call it Fred
Anish: Still need to discuss issues, now that we've decided overall direction
DHull: Will part 3 have its own issues list?
Mike: Yves?
Yves: Can reuse existing list.
Anish: Issue 3) (Yves) 202 vs 204 4) possible HTTP header signalling binding, MEP
Mike: Actions, ownership:
<noah> Noah is a bit worried about (a) whether having HTTP headers for the MEP is actually a good idea (b) even if it is in principle, I want to be careful about anything that would take us back through CR and (c) I want to watch for interop issues with the existing binding.
<noah> Anish: regrets for next two weeks
<scribe> ACTION: Anish to start email discussion of what does FAF really mean? [recorded in http://www.w3.org/2006/03/04-xmlprotocol-minutes.html#action01]
<scribe> ACTION: Yves to start discussion of 202 vs. 204 [recorded in http://www.w3.org/2006/03/04-xmlprotocol-minutes.html#action02]
<scribe> ACTION: Marc to start discussion of possible HTTP header signalling binding/MEP [recorded in http://www.w3.org/2006/03/04-xmlprotocol-minutes.html#action03]
<cferris> could I request that people identify emails in the archives for which they think identifies any substantive points related to the part3 spec so that the editors don't have to wade through every one of them?
Note: What does FAF mean and what timing issues are there are actually the same issue (actioned to Anish)
<noah> My key points are effectively in the resolution:
Chris: Could people please provide pointers to key emails in previous discussion of "what does FAF mean" issue.
Mike: This seems part of starting email discussion.
<noah> 1) Timing is an issue. In particular, the MEP should NOT be used for transports on which you have to wait for actual network traffic before proceeding at the sender.
<noah> 2) Therefore, this MEP is mainly for datagram-like protocols.
<noah> Chris, those two points are my main input.
Mike: Meet a week from Wednesday?
Omnes: General approval.
<anish> noah, what MEP would you use for queueing/messaging/jms?
<anish> that is where it gets tricky
<cferris> thanks, noah
Mike: Next meeting March 15
Noah: I believe my draft is a useful starting point. Group should read it keeping in mind that this should be headed quickly toward Rec.
<scribe> ACTION: Noah to suggest how the group should proceed in reviewing draft (suggestion will probably be what I just said) [recorded in http://www.w3.org/2006/03/04-xmlprotocol-minutes.html#action04]
Mike: Anything else?
Omnes: No.
<cferris> DaveH, did you mean Noah instead of Mike in reference to "my draft"?
<cferris> ciao
<anish> cya
Mike: Adjourned
<cferris> or should I say au revoir