See also: IRC log
<GlenD> oops
<scribe> Scribe: Hugo
Glen goes over the agenda:
- SOAP work
- Scope our work into an issue in Addressing
Glen: I took an AI to frame our
work into an issue
... Dave has also sent a blog entry about protocol
independence; we'll see if we have time to get to it
Glen: there's been some discussion on the list within the last week
DaveH: [giving his summary of the
discussion]
... the in-optional-out SOAP MEP is trying to address some
async case
... with the reply/address going somewhere else
... the HTTP response is what tells you if you're going to get
an answer or not
... DaveO's blog entry is about this
<TonyR> http://www.pacificspirit.com/blog/2005/04/05/underlying_protocol_is_a_completely_leaky_abstraction
DaveH: my personal opinion is
that we will always have something going back: you need either
an application message or an ack
... otherwise you don't know
Glen: how does that relate to a true one-way MEP? do we need a separate one-way MEP?
Marc: do you always need anything back with this MEP?
Umit: yes; if you think about HTTP, there's always something coming back
Marc: this can be abstracted, right?
DaveH: sure, but this has to be
taken into account
... I think in-optional-out is a misnommer; I prefer to call it
in-(out-or-ack)
Greg: the ack to me is QoS
DaveO: the problem is not about QoS, it's about the HTTP error codes for the response
<marc> for the minutes, my point is that SOAP MEPs are about exchange of SOAP messages not underlying protocol artifacts
DaveH: if your WSDL MEP is one-way, then you're happy with fire-and-forget one-way; if it's request-response, then we have to consider this MEP
Glen: the question is: a thread is sending a message; when can the thread can go off and do something else?
Dave: in terms of coming up with one issue, I think that it is: what is needed in terms of WSDL to fully describe the combinations of SOAP/WSDL MEPs, and whether we need new SOAP MEPs for that
Greg: does the application care about whether things happen sync or asynchronously?
DaveO: given what SOAP+HTTP is, does WSA give you the ability to do what you'd like to do with it?
DaveH: I think we could address this by reducing the semantics of ReplyTo and FaultTo
Glen: but that reduces
interop
... every app using our spec should expect the same
behavior
<uyalcina> +1 To Glen
DaveH: we do define semantics in the core; I want to be careful that we don't say too much there, when things should be said in the WSDL binding
<dorchard> Issue text proposal: What are the constructs in WS-Addressing and the specifications it uses, like WSDL and SOAP, necessary for the full range of interoperable WS-A scenarios, such as asynch request/response and Fault handling.
Umit: can we say that it's not possible to use FaultTo and ReplyTo other than for anonymous with the current combination of WSDL and SOAP bindings
<dorchard> Break #1: one-way
Umit: if you put something else than anonymous, we don't know how it's going to behave
<GlenD> Issue text : We cannot reliably and interoperably use MAPs like ReplyTo/FaultTo with the current WSDL/SOAP constructs - the MEPs/behavior at the various layers are not clearly defined.
<dorchard> Break #2: FaultTo
DaveO: I'd like to spell it like: if FaultTo is specified, we don't know what to do with it
Mark: I think we're going in the right direction
<marc> "What SOAP MEP should be used to send a fault in the presence of a non-anonymous FaultTo"
<dorchard> Break #2: FaultTo + HTTP
<dorchard> Issue around is use of HTTP connection.
Glen: it is possible in any binding to have a transport error that may or may not be relayed to the app
DaveO: but I'm talking about a
SOAP error
... if you generate a fault, what do you do with it? what HTTP
error code do you use?
Umit: what if you have a redirect and a fault
DaveO: so you use a 400; can you
send the fault back?
... right now we don't have a MEP like in-optional-fault
Greg: over JMS, I can send a
message that is going to be sent successfully or not, but I
won't know and I won't care
... I could disregard the HTTP error code, the same way
DaveO: yes; either we are going to ignore the HTTP error codes and everything which makes HTTP special, or we can use them, and we need to carefully take them into account
Umit: if you were to say that we need in and robust-in, can we have 2 different SOAP MEPs and bindings, and go from there
Glen: can you close a connecting
right after an HTTP request?
... the SOAP MEP will take care of ignoring any response
Marc: what's the difference between the two cases in case of a 404?
DaveO: they would both have an empty 404
Umit: the robust-in is close to what the BP does
Glen: but something's going to
happen in the in-only case too
... it may be an implementation difference about the kind of
feedback you get
DaveH: there's another possible
approach
... we could have an in-only MEP, with a reply expected
property
... and the binding could take care of that
... you know from the ReplyTo and FaultTo whether you're
expecting something
DaveO: which MEP are you talking about?
DaveH: WSDL MEP req-resp
<dorchard> hugo, he's talking about WSDL mep
DaveO: I think that you have to
say at some point at the SOAP level if you're sending just a
request, or if you're expecting anything back
... there's only 4 MEPs at the SOAP level that we could
have
<dhull> DaveH: So why not say so explicitly?
<dhull> +1 multiple issues
Glen: do we want multiple issues, or a generic issue covering them all?
DaveO: I'd prefer 1 issue from a managerial perspective
Glen: I'm proposing to take a crack at writing this issue
Umit: I prefer my approach to the issue
DaveH: it's good to have 1 over-arching issue, but it clearly has multiple facets
<scribe> ACTION: Glen and Umit to write text for issue [recorded in http://www.w3.org/2005/04/06-ws-async-minutes.html#action01]
Glen: can we get together in CA just before the F2F?
<dorchard> I can be available monday afternoon?
Some agreement around meeting at 1pm on the 18th
<TonyR> Sounds like a good idea
Umit proposes to hold the meeting at SAP
<scribe> ACTION: Glen to send mail about meeting in CA [recorded in http://www.w3.org/2005/04/06-ws-async-minutes.html#action02]
<dorchard> SFO does have BART from airport to city...
This is scribe.perl Revision: 1.122 of Date: 2005/03/31 04:43:41 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/codes/codes for the response/ Succeeded: s/Are there any/What are the/g Succeeded: s/MEPs/bindings/ Succeeded: s/may not/may or may not/ Succeeded: s/SOAP/WSDL/ Found Scribe: Hugo Inferring ScribeNick: hugo Default Present: Dave_Hull, Glen, MarkN, Hugo, Jonathan_Marsh, TonyR, DOrchard, MSEder, Umit_Yalcinalp, Marc, Greg_Truty Present: Dave_Hull MarkN Hugo TonyR Jonathan_Marsh MSEder Umit DOrchard Marc Agenda: http://lists.w3.org/Archives/Member/member-ws-addressing/2005Apr/0005.html Got date from IRC log name: 6 Apr 2005 Guessing minutes URL: http://www.w3.org/2005/04/06-ws-async-minutes.html People with action items: glen umit[End of scribe.perl diagnostic output]