Web Services Addressing Face-to-Face -- 29 Sep 2005

<pauld> hugo: the targetNamespace urn seems more like a bug than a means of migration

<pauld> ACTION: Jonathan to formulate a proposal for a migration guide [recorded in http://www.w3.org/2005/09/29-ws-addr-minutes.html#action01]

<pauld> mnot: wrap up

<yinleng> \me Is the meeting over yet?

<pauld> meeting ajurned with photos

<scribe> Scribe: anish

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0033.html

Discussion about the f2f meeting after the Japan f2f

Mark: after that very likely in Vancouver, BC

issue i059

<GlenD> http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Jul/0010.html

Mark: what do we need in our docs to close our issue and go to LC. That is the important thing.

Glen: after months of sporadic discussion in ATF, we came up with guiding questions to frame the landscape.
... the basic idea is that for addressing to succeed, a lot of things that people want to do should be in our test suite
... for example async req-res over http
... What do we need to do in various WS WGs to specify in clear way as to how this works without any handwaving
... The 1st issue being: what about one-way. SOAP does not have one-way.
... We asked the one-way the XMLP WG is going to work on one-way MEP in SOAP
... But there is a question of is that what we want, how long that is going to take?
... There is also the WSDL question wrt one-way.

Mark: we can specify something in our WSDL binding without referring to the one-way MEP

Glen: we could

Mark: and we could specify thing in our test suite, which is not a REC

Glen: the case of req-res with wsa:ReplyTo over HTTP with multiple connection is not supported by any specs right now
... our charter says that we have to do all MEPs in an async way

Paco: we don't have a way to represent this in WSDL

Paul: we go to REC and move forward with SOAP spec instead of WSDL

Glen: we need to talk about whether some of the issues with async are our issues
... here is one option: when u use wsa:UsingAddressing that means async and we don't need to do anything else. But the problems is that we have been doing this for a while and this isn't written down anywhere

Paco: the issue is you have to do this in a way that does not contradict the binding

anish: reminder to the WG that they need requirements for us, so that they can craft their charter correctly
... if we don't they will go ahead and create a solution that they think is right

paco: q-
... we can agree on the runtime behavior first and then we can figure out how these things are speced out

Glen: we have a meeting in the bay area which turned out a number of pictures with how things look on the wire
... for one-way, req-res using addressing
... it was 4 way matrix, with one-way protocol, two-way protocol and one-way MEP and req-res MEP
... there is a general question about relationship between WSDL MEP/SOAP MEP/Transport MEPs

Umit: in the sunnyvale meeting, there was agreement on the wire level agreement, but it did not go beyond udp/http layer. The problem is to figure out whether we are going to try and solve the problem only for http or in a general way

Arun walks in the room

Glen: the relationship between soap and wsdl meps is the core question
... in some proposal there are SOAP meps, some proposal don't
... there are three choices:
... one-to-one mapping between SOAP and WSDL MEP, transport stuff happens below this
... the 2nd approach is soap mep are tightly coupled to transport MEPs. Eg, soap req-res binds to HTTP req-res. At the WSDL level it is not tightly coupled.

umit: the xmlp wg cannot solve this problem

glen: xmlp has requested requirements from us
... when someone picks up our specs and wsdl/soap spec they should be able to build something that will work

<pauld> whiteboard diagrams from Palo Alto: http://www.flickr.com/photos/psd/9876773, documented by daveo here: http://www.pacificspirit.com/Authoring/async/async-scenarios.html

Mark: we need to not focus on the solution here (for the things that will be done by XMLP). we need to focus on requirements

Glen: that depends on the solution that we pursue here in wsa

paco: i agree that we need to figure out our needs. it is not our job to figure out the direction. that is for wsdl and xmlp to figure out

Glen: i don't agree

paco: how wsdl meps map to soap meps is not our job

<uyalcina> +1 to Paco

daveo: i don't think anything that there is anything that glen said that contradicts that

paco: glen is mixing requirements with solution

glen: can we do that cleaning without going into solution space

daveo: we have to say what happens in the case where there is a non-anon replyTo address

glen: in that case u would say something like what comes back on the HTTP response as long as the "response" is sent back to replyTo

daveh: we need to provide feedback from ATF to XMLP
... the wsa spec does talk about what anon means and how much we say about HTTP and anon
... but that is influenced by the async model
... it would be nice if some other layer was providing a crisp definition that we could point to
... I would like to call attention to DH2 proposal in Glen's email
... DH2 is something that is not in Glen's email but rather something that i have been working on

jeff: this is not a unsolved problem
... this is not that hard problem to solve
... at the application level, how in wsdl we specify async
... i just think we could be done by that, maybe we need a one-way mep

umit: what i feel is that, we have the wire level stuff, we have to make a decision in the test suite anyway. In the case soap 1.1, we just need a marker, there is a proposal for that. We can claim victory with that and not solve the whole problem.

daveo: right, effectively we would be creating our own soap binding anyway

umit: we have to build a test suite which we have to implement anyway

<pauld> +1 to umit

mark: our charter says that we need to use WSDL meps in async way, nothing about SOAP
... can we define a WSDL extension and get this done
... there are also things which are out of scope in the charter

daveh: i agree that this is not new, the difficulty we had was how to map that to wsdl and soap. That is the hard part and we are feeding into xmlp to make the description easy.
... easy things should be easy and hard things should be possible

Glen: i'm very amenable to Paco's view that we look at this top-down in a direct way
... unfortunately, that isn't as easy
... I'm very sympathetic to what Umit just say -- get this done with a minimal thing
... I would in general IMO we should make minimal changes. If xmlp and WSDL do what they do to make this easier in the future.
... creating new soap binding right now, if that can be avoided, would be good
... If things change drastically, then we can deal with it later

Mark: i heard some folks say is: do we push things down to SOAP or do it in WSDL
... eg have extension that changes the meaning of bindings
... Paco reminded us that we need to do this not only for SOAP 1.2/wsdl2.0 but also WSDL 1.1/soap 1.1
... we can't change those spec
... in that case, pushing things into wsdl extension for wsdl 1.1 is the only solution
... the question is: do we want to take the same approach in wsdl 2.0 or do something different

daveo: the timing for what xmlp may come up with it, if we go to REC and then xmlp does things differently, then we can do a backward compatible ws-addressing new version

anish: there is a proposal to do exactly that

----------------------------------

BREAK

-----------------------------------

BACK FROM BREAK

mark: the asyntf went on for > 6 months, we are not terribly closer

glen: we have framed things, but there isn't consensus
... getting wsa to work dips into architecture

mark: we should give xmlp feedback about their binding

glen: what do we say about this in wsdl (about wsdl out message and the soap binding)
... a simple two step process would be to errata to soap 1.2, and then make sure that WSDL allows one to say where the in/out messages go, perhaps with extensions

anish: so we can define extensions that modify/change existing binding if we have to

glen: that is what marc's proposal is, we need to perhaps tweak this

<mnot> http://www.w3.org/mid/1EFFF9BA-6069-4EFC-AEE3-EB4AD09770B2@Sun.COM

glen: everybody agreed in the TF that there should be markup in wsdl (optional) which says which bindings are acceptable on the response message

daveo: the problems that i have with marc's proposal is that u can't take a binding that has constraints on it and say that they don't apply. This needs to be a different binding.

mark: we need to figure out that we need such a binding, irrespective of whether this is a new binding or not

umit: agree with daveo

mark: what marc is saying is that xmlp will do this, we won't do this.

glen: is it ok to add things to a binding. That is what extensions are for in WSDL

anish: issues around mixed transport protocols for wsdl 1.1

glen: not a problem we just specify the right extension

paco: lets solve the simple wsdl1.1/soap1.1 case, lets do that and figure out what the requirements are

mark: can we figure out the async bit and soap bit for one-way. From my perspective, i would like to see a proposal for this along with the enabling bits that are required

umit: we sent a proposal to the async tf (paco, anish and i)

mark: it would be helpful to have a person/people go off and figure out what the wsdl extensions would look like and what requirements it places on soap etc
... if people could go away for a week or two and come back

glen: this is going the route that Paco was suggesting -- lets do the soap11/wsdl11 now and figure out how that would look like

<scribe> ACTION: proposal to address the issue of how to solve issue i059 for wsdl11/soap11 and figure out how the WSDL extension would look like [recorded in http://www.w3.org/2005/09/29-ws-addr-minutes.html#action02]

mark: xmlp has asked us for requirements not design advice
... can we give them anything at this point

glen: no, not yet
... it depends on the middle layer
... depending on how we do this, all we may need is a one-way mep
... but another way is to say that we need less from you

mark: but xmlp is going to do one-way, so it would suffice for us

gil: we can't give them all the requirement, but that would be one of them

mark: well we can say that one-way is all we need

- DRAFT -

Web Services Addressing Face-to-Face

29 Sep 2005

Attendees

Contents

issue i059

Summary of Action Items

Scribe.perl diagnostic output