00:00:53 <Gil> Gil has joined #ws-addr
00:01:39 <pauld> hugo: the targetNamespace urn seems more like a bug than a means of migration
00:02:06 <pauld> ACTION: Jonathan to formulate a proposal for a migration guide
00:03:28 <pauld> mnot: wrap up 
00:05:12 <yinleng> \me Is the meeting over yet?
00:06:25 <pauld> meeting ajurned with photos
00:06:27 <TRutt> TRutt has left #ws-addr
00:06:55 <yinleng> yinleng has left #ws-addr
00:30:46 <Zakim> -[TIBCO]
00:30:54 <Zakim> -prasad
00:30:55 <Zakim> WS_(F2F)12:00PM has ended
00:30:57 <Zakim> Attendees were Roland_Merrick, Mark_Peel, [TIBCO], Prasad_Yendluri, prasad, yinleng, Mark_Peel/Katy_Warr
03:34:15 <Zakim> Zakim has left #ws-addr
04:55:40 <pauld> pauld has joined #ws-addr
05:24:09 <bob> bob has joined #ws-addr
05:29:03 <bob> bob has joined #ws-addr
16:15:02 <RRSAgent> RRSAgent has joined #ws-addr
16:15:02 <RRSAgent> logging to http://www.w3.org/2005/09/29-ws-addr-irc
16:15:07 <mnot> zakim, this is ws
16:15:07 <Zakim> ok, mnot; that matches WS_(F2F)12:00PM
16:15:18 <mnot> Meeting: Web Services Addressing Face-to-Face
16:15:21 <mnot> Chair: Mark Nottingham
16:15:54 <mnot> Agenda: http://www.w3.org/mid/D98ACD86-AAC1-405F-BD05-3CE8D3B63980@bea.com
16:16:01 <Zakim> +Mark_Peel
16:16:23 <hugo> hugo has joined #ws-addr
16:19:17 <hugo> RRSAgent, make log public
16:19:55 <Marsh> Marsh has joined #ws-addr
16:23:37 <MSEder> zakim, mute me
16:23:37 <Zakim> MSEder should now be muted
16:23:43 <dorchard> dorchard has joined #ws-addr
16:27:16 <anish> anish has joined #ws-addr
16:27:25 <anish> Scribe: anish
16:28:53 <anish> Agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0033.html
16:29:18 <anish> Discussion about the f2f meeting after the Japan f2f
16:29:29 <Paco> Paco has joined #ws-addr
16:29:32 <anish> Mark: after that very likely in Vancouver, BC
16:32:35 <Zakim> -Mark_Little
16:32:51 <anish> Topic: issue i059
16:33:05 <jeffm> jeffm has joined #ws-addr
16:33:33 <GlenD> GlenD has joined #ws-addr
16:33:34 <GlenD> http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Jul/0010.html
16:35:00 <anish> Mark: what do we need in our docs to close our issue and go to LC. That is the important thing.
16:35:34 <anish> Glen: after months of sporadic discussion in ATF, we came up with guiding questions to frame the landscape.
16:36:06 <anish> ... the basic idea is that for addressing to succeed, a lot of things that people want to do should be in our test suite
16:36:16 <anish> ... for example async req-res over http
16:36:49 <anish> ... What do we need to do in various WS WGs to specify in clear way as to how this works without any handwaving
16:37:10 <anish> ... The 1st issue being: what about one-way. SOAP does not have one-way.
16:37:31 <anish> ... We asked the one-way the XMLP WG is going to work on one-way MEP in SOAP
16:37:53 <anish> ... But there is a question of is that what we want, how long that is going to take?
16:38:03 <uyalcina> uyalcina has joined #ws-addr
16:38:13 <anish> ... There is also the WSDL question wrt one-way.
16:38:57 <anish> Mark: we can specify something in our WSDL binding without referring to the one-way MEP
16:39:03 <anish> Glen: we could
16:39:24 <anish> Mark: and we could specify thing in our test suite, which is not a REC
16:40:07 <anish> Glen: the case of req-res with wsa:ReplyTo over HTTP with multiple connection is not supported by any specs right now
16:40:28 <anish> ... our charter says that we have to do all MEPs in an async way
16:40:38 <bob> bob has joined #ws-addr
16:40:42 <anish> Paco: we don't have a way to represent this in WSDL
16:41:16 <anish> Paul: we go to REC and move forward with SOAP spec instead of WSDL
16:41:38 <gil> gil has joined #ws-addr
16:41:40 <anish> Glen: we need to talk about whether some of the issues with async are our issues
16:41:42 <anish> q+
16:42:43 <anish> ... 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
16:43:00 <anish> Paco: the issue is you have to do this in a way that does not contradict the binding
16:45:41 <anish> anish: reminder to the WG that they need requirements for us, so that they can craft their charter correctly
16:45:57 <anish> ... if we don't they will go ahead and create a solution that they think is right
16:47:06 <mnot> mnot has joined #ws-addr
16:47:12 <anish> paco: q-
16:47:13 <mnot> zakim, who is on the phone?
16:47:13 <Zakim> On the phone I see Prasad_Yendluri, MSEder (muted), [TIBCO], Mark_Peel
16:47:16 <anish> q-
16:48:13 <anish> paco: we can agree on the runtime behavior first and then we can figure out how these things are speced out
16:48:40 <anish> Glen: we have a meeting in the bay area which turned out a number of pictures with how things look on the wire
16:48:52 <anish> ... for one-way, req-res using addressing
16:49:10 <prasad> prasad has joined #ws-Addr
16:49:27 <uyalcina> q+
16:49:34 <anish> ... it was 4 way matrix, with one-way protocol, two-way protocol and one-way MEP and req-res MEP
16:50:22 <anish> ... there is a general question about relationship between WSDL MEP/SOAP MEP/Transport MEPs
16:51:38 <anish> 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
16:51:59 <anish> Arun walks in the room
16:54:13 <anish> Glen: the relationship between soap and wsdl meps is the core question
16:54:22 <swinkler> swinkler has joined #ws-addr
16:54:59 <anish> ... in some proposal there are SOAP meps, some proposal don't
16:55:04 <Arun> Arun has joined #ws-addr
16:55:20 <anish> ... there are three choices:
16:55:43 <anish> ... one-to-one mapping between SOAP and WSDL MEP, transport stuff happens below this
16:56:46 <anish> ... 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.
16:57:24 <anish> umit: the xmlp wg cannot solve this problem
16:58:08 <anish> glen: xmlp has requested requirements from us
16:58:41 <anish> ... when someone picks up our specs and wsdl/soap spec they should be able to build something that will work
16:58:47 <dorchard> dorchard has joined #ws-addr
16:58:55 <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
16:59:56 <anish> 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
17:00:28 <anish> Glen: that depends on the solution that we pursue here in wsa
17:00:38 <Paco> q+
17:01:23 <mnot> ack uyal
17:01:32 <andreas> andreas has joined #ws-addr
17:01:45 <dhull> dhull has joined #ws-addr
17:01:54 <anish> 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
17:01:56 <dhull> q+
17:02:00 <mnot> ack Paco
17:02:25 <anish> Glen: i don't agree
17:02:34 <anish> paco: how wsdl meps map to soap meps is not our job
17:02:49 <anish> q+
17:03:22 <uyalcina> +1 to Paco
17:03:44 <jeffm> q+
17:04:10 <anish> daveo: i don't think anything that there is anything that glen said that contradicts that
17:04:19 <anish> paco: glen is mixing requirements with solution
17:04:32 <anish> glen: can we do that cleaning without going into solution space
17:05:05 <anish> daveo: we have to say what happens in the case where there is a non-anon replyTo address
17:05:38 <mnot> ack dhull
17:05:45 <anish> 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
17:06:10 <anish> daveo: we need to provide feedback from ATF to XMLP
17:06:33 <anish> ... the wsa spec does talk about what anon means and how much we say about HTTP and anon
17:06:44 <anish> ... but that is influenced by the async model
17:07:09 <anish> ... it would be nice if some other layer was providing a crisp definition that we could point to
17:07:30 <anish> s/daveo/daveh/
17:08:09 <anish> ... I would like to call attention to DH2 proposal in Glen's email
17:08:41 <anish> ... DH2 is something that is not in Glen's email but rather something that i have been working on
17:08:46 <mnot> ack anish
17:08:57 <GlenD> q+
17:11:48 <uyalcina> q+
17:12:00 <mnot> ack jeffm
17:12:14 <anish> jeff: this is not a unsolved problem
17:12:26 <anish> ... this is not that hard problem to solve
17:12:41 <anish> ... at the application level, how in wsdl we specify async
17:13:20 <dhull> q+
17:13:56 <pauld> q+
17:14:01 <anish> ... i just think we could be done by that, maybe we need a one-way mep
17:14:05 <mnot> ack uyal
17:14:07 <mnot> ack glen
17:14:29 <GlenD> q+
17:15:16 <anish> 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.
17:15:55 <anish> daveo: right, effectively we would be creating our own soap binding anyway
17:16:03 <pauld> q-
17:16:16 <anish> umit: we have to build a test suite which we have to implement anyway
17:16:19 <pauld> +1 to umit
17:16:57 <mnot> q?
17:17:41 <anish> mark: our charter says that we need to use WSDL meps in async way, nothing about SOAP
17:18:06 <dorchard> dorchard has joined #ws-addr
17:18:08 <anish> ... can we define a WSDL extension and get this done
17:18:20 <anish> ... there are also things which are out of scope in the charter
17:18:25 <mnot> ack dhull
17:19:13 <anish> 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.
17:19:20 <mnot> ack glen
17:19:23 <anish> ... easy things should be easy and hard things should be possible
17:19:42 <anish> Glen: i'm very amenable to Paco's view that we look at this top-down in a direct way
17:19:58 <anish> ... unfortunately, that isn't as easy
17:20:18 <anish> ... I'm very sympathetic to what Umit just say -- get this done with a minimal thing
17:20:56 <anish> ... 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.
17:21:12 <anish> ... creating new soap binding right now, if that can be avoided, would be good
17:21:32 <anish> ... If things change drastically, then we can deal with it later
17:21:50 <anish> Mark: i heard some folks say is: do we push things down to SOAP or do it in WSDL
17:22:09 <anish> ... eg have extension that changes the meaning of bindings
17:22:48 <anish> ... 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
17:22:57 <anish> ... we can't change those spec
17:23:27 <anish> ... in that case, pushing things into wsdl extension for wsdl 1.1 is the only solution
17:23:44 <anish> ... the question is: do we want to take the same approach in wsdl 2.0 or do something different
17:24:33 <anish> 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
17:25:27 <anish> anish: there is a proposal to do exactly that
17:25:44 <anish> ----------------------------------
17:25:47 <anish> BREAK
17:25:50 <anish> -----------------------------------
17:29:26 <Zakim> -Prasad_Yendluri
17:32:47 <vikas> vikas has joined #ws-addr
17:43:50 <Zakim> +Prasad_Yendluri
17:49:38 <anish> BACK FROM BREAK
17:51:23 <anish> mark: the asyntf went on for > 6 months, we are not terribly closer
17:51:34 <anish> glen: we have framed things, but there isn't consensus
17:52:13 <anish> ... getting wsa to work dips into architecture
17:54:44 <anish> mark: we should give xmlp feedback about their binding
17:55:09 <anish> glen: what do we say about this in wsdl (about wsdl out message and the soap binding)
17:56:12 <anish> ... 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
17:58:57 <anish> anish: so we can define extensions that modify/change existing binding if we have to
17:59:08 <mnot> mnot has joined #ws-addr
17:59:20 <anish> glen: that is what marc's proposal is, we need to perhaps tweak this
17:59:54 <uyalcina> uyalcina has joined #ws-addr
18:00:09 <mnot> http://www.w3.org/mid/1EFFF9BA-6069-4EFC-AEE3-EB4AD09770B2@Sun.COM
18:01:10 <anish> ... everybody agreed in the TF that there should be markup in wsdl (optional) which says which bindings are acceptable on the response message
18:01:27 <dorchard> q+
18:01:57 <anish> q+
18:02:51 <mnot> ack dorch
18:03:39 <anish> 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.
18:04:13 <GlenD> q+
18:04:16 <anish> mark: we need to figure out that we need such a binding, irrespective of whether this is a new binding or not
18:04:43 <anish> umit: agree with daveo
18:04:56 <anish> mark: what marc is saying is that xmlp will do this, we won't do this.
18:05:42 <anish> glen: is it ok to add things to a binding. That is what extensions are for in WSDL
18:06:35 <Paco> q+
18:09:25 <mnot> ack anish
18:09:39 <mnot> ack glend
18:09:46 <anish> anish: issues around mixed transport protocols for wsdl 1.1
18:09:53 <mnot> ack paco
18:09:54 <anish> glen: not a problem we just specify the right extension
18:10:18 <anish> paco: lets solve the simple wsdl1.1/soap1.1 case, lets do that and figure out what the requirements are
18:10:41 <GlenD> q+ to quickly point out something re extensibility and naming
18:11:21 <bob> bob has joined #ws-addr
18:12:05 <anish> 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
18:12:47 <anish> umit: we sent a proposal to the async tf (paco, anish and i)
18:16:24 <anish> 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
18:17:01 <anish> ... if people could go away for a week or two and come back
18:18:03 <anish> glen: this is going the route that Paco was suggesting -- lets do the soap11/wsdl11 now and figure out how that would look like
18:19:46 <anish> 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
18:21:01 <anish> mark: xmlp has asked us for requirements not design advice
18:21:10 <anish> ... can we give them anything at this point
18:21:23 <anish> glen: no, not yet
18:21:30 <anish> ... it depends on the middle layer
18:21:43 <anish> ... depending on how we do this, all we may need is a one-way mep
18:22:03 <anish> .. but another way is to say that we need less from you
18:22:23 <anish> mark: but xmlp is going to do one-way, so it would suffice for us
18:22:44 <anish> gil: we can't give them all the requirement, but that would be one of them
18:23:08 <anish> mark: well we can say that one-way is all we need
18:23:29 <hugo> RRSAgent, draft minutes
18:23:29 <RRSAgent> I have made the request to generate http://www.w3.org/2005/09/29-ws-addr-minutes.html hugo
18:23:41 <hugo> RRSAgent, make log public
18:23:50 <anish> glen: we may want them to fix their existing binding
18:24:35 <anish> mark: so do we agree that all we need is (a) a one way mep and (b) errata to existing soap binding
18:24:43 <dhull> q+
18:25:12 <mnot> ack dh
18:25:15 <mnot> ack glen
18:25:15 <Zakim> GlenD, you wanted to quickly point out something re extensibility and naming
18:25:45 <anish> daveh: suppose we get a one-way binding from xmlp, what does that mean? Now any async req/res can be built on top of that one-way?
18:26:10 <anish> Glen: my view is that what we need is the ability in wsdl to describe as to what/how to replyTo
18:26:33 <anish> ... HTTP is natively a transport level req-res
18:26:38 <anish> ... if we allow 202
18:26:47 <anish> ... then we can use that to do async
18:29:01 <anish> glen: wsdl 2.0 does not say explicitly to take the input message in wsdl and stick it in the soap request message and so on
18:29:13 <anish> ... so that is where the glue comes in
18:29:22 <anish> daveh: there is more than that
18:29:32 <anish> glen: yes, but that is the 1st step
18:29:46 <anish> ... then comes the extension
18:30:00 <anish> daveh: i don't see that as a wsa extension
18:30:03 <anish> glen: who else?
18:30:33 <anish> ... we need the hook in wsdl to hang our hat on
18:31:02 <anish> daveh: where is the state machine
18:31:13 <anish> glen: in the extension spec
18:31:46 <anish> daveh: sounds suboptimal. Hence the proposal that I sent out (DH2)
18:32:00 <anish> daveh describes his proposal
18:34:03 <anish> daveh: to completely handle what is going on in async req/res, the wsa extension to wsdl will be non-trivial and it is as much work as my proposal
18:35:11 <anish> mark: i asked folks to send their proposal to the list and only one person sent his proposal and he is not here
18:35:29 <anish> daveh: i did sent one too, but i did it today. The other proposals are not secret either
18:38:34 <anish> mark: i'm looking at this from the POV of what does it take to declare victory
18:38:42 <anish> ... how does your proposal get us there?
18:39:37 <anish> daveh: afaics marc's proposal says we need a 202 response. we agreed on to allow a binding to say that it will accept only certain transports.
18:40:11 <anish> ... the thing about 202 ack doesn't related to WSA
18:40:25 <anish> ... WSA could probably declare victory right now
18:40:33 <anish> mark: we could do this in testing?
18:40:45 <anish> daveh: not clear
18:41:03 <anish> mark: but u are saying that we don't need to add any text to our spec
18:41:10 <PaulKnight> PaulKnight has joined #ws-addr
18:41:36 <anish> ... at a very high level the proposal we have is come up with a addressing extension to wsdl 1.1 and see how that looks
18:42:26 <anish> daveh: there are lot of things in here that people assume. there is no distributed state machine that is defined
18:43:12 <anish> ... there is not analogous dist. state machine that talks about the requester, responder, fault endpoint and reply endpoint
18:43:18 <anish> s/not/no/
18:43:42 <anish> daveh: OTOH, this is not a WSA issue
18:44:21 <anish> ... I'm torn here. I'm not proposing anything that is core WSA, but it needs to be solved.
18:45:54 <anish> mark: we haven't had anyone dispute the action item that was assigned.
18:46:12 <anish> ... are any of the proposal radically different from the previous discussion
18:46:34 <anish> ... that can't be brought up as issues against the outcome of the AI
18:46:59 <anish> daveh: we have a case of blind men and the elephant
18:47:10 <anish> ... the proposals are not necessarily mutually exclusive
18:47:43 <anish> daveh: here is my quick summary of my DH2 proposal --
18:48:09 <anish> ... this builds on my previous email to the async tf
18:48:32 <anish> ... the idea is to try to factor out the state machine from what kind of message gets transported and how it gets transport
18:48:34 <Arun> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0045.html
18:48:46 <anish> ... req-res is req-res regarless of how things get sent
18:49:15 <anish> ... a message goes from sender to receiver. Both have 3 states: request, success, fail
18:50:12 <anish> ... it defines a application level state machine
18:50:35 <anish> ... wsdl in-out is modelled as an incoming request mapped to a outgoing reply or a fault
18:50:49 <anish> ... you have 6 little state machines going around
18:51:24 <anish> ... if you take this formation and what it means, it maps to existing req-res but makes it more general
18:52:19 <anish> ... at the soap level this is equivalent to what we have
18:52:28 <anish> .. but brings the generalization to the soap level
18:52:47 <anish> ... at the soap level there is a bunch of one-way exchanges
18:53:07 <anish> ... since HTTP has two different ways we need to talk about bindings
18:53:25 <anish> ... u have soap over post, soap over get and soap over HTTP response
18:54:57 <anish> ... It allows u to do async req-res over http, it allows u to have the cell-phone case
18:55:29 <anish> Glen: there are lot of pieces of state machine to get things working. But how do u connect the wsdl mep to all the things that you are talking about
18:55:53 <anish> daveh: all the soap bindings are one-way pieces
18:56:30 <anish> ... if u have wsa engaged to fomulate things in terms of one-way
18:57:29 <anish> mark: as a chair i'm concerned as this is ambitious
18:57:40 <anish> ... we tried to do this in XMLP and it took a very long time
18:58:10 <anish> ... i'm not sure we need that level of detail to declare success
18:58:46 <anish> daveh: this is something that made things conceptually easier for me
18:59:02 <anish> mark: i don't want to stumble over too many layers of abstraction
18:59:17 <anish> daveh: only two layers of abstraction
19:00:00 <anish> glen: my proposal is in line with marc's
19:00:22 <anish> ... the important part is to define the glue between wsdl mep to soap mep
19:01:35 <dorchard> dorchard has joined #ws-addr
19:01:41 <dorchard> http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/att-0159/WS-Addressing-SOAP-Adjuncts.html
19:02:08 <anish> daveo: the 1st proposal at the URL is talking soap req-res MEP in soap and making it one-way
19:02:18 <anish> ... calls it the soap-request MEP
19:02:32 <anish> ... it is a one-way MEP, it follows the soap binding framework
19:02:40 <anish> ... it then has a http binding for that
19:03:17 <anish> ... it does a little bit of change to the existing binding
19:03:24 <anish> ... it is mostly cut-paste-prune
19:03:59 <anish> ... one of the problems is: what if we decide that for description purposes, how is the mapping from WSDL MEP to SOAP MEP
19:04:15 <anish> ... this allows you to map a WSDL MEP to multiple SOAP MEP
19:04:55 <dorchard> http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Jun/att-0008/WS-Addressing-SOAP-Adjuncts.html
19:06:07 <anish> Dave's email with 3 proposals is at: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0046.html
19:07:35 <anish> mark: so the wsdl would point to soap req-res, but a new extension will say that it is now two soap one-way
19:07:43 <anish> daveo: yes
19:09:59 <anish> daveo: the next proposal has one-to-one mapping of wsdl and soap MEPs
19:10:04 <anish> ... we still have a one-way MEP
19:10:48 <anish> ... but we have a complicated soap binding that takes a SOAP req-res and has a property that says whether or not you have a separate HTTP connection
19:11:07 <anish> ... it take a variety of SOAP MEP it does a variety of things.
19:11:21 <anish> ... There is an algorithm in the spec that defines this
19:12:14 <anish> ... it does 2 things: allows one-way and allows nesting of http binding
19:12:37 <anish> ... there is a comment about why i don't like the state machine
19:13:29 <anish> ... it is fairly complicated, but one binding supports one-way and req-res with multiple http connections
19:13:45 <anish> Mark: which one do you prefer between the 3 proposals
19:13:50 <anish> david: #3
19:13:54 <dorchard> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/att-0010/ws-addr-soapadjuncts-simplemeps_httpbinding.html
19:15:03 <anish> davido: the 3rd proposal removes the notion of soap-ness
19:15:11 <anish> ... there is a request and there is a response
19:15:22 <anish> ... response happens after the request
19:15:32 <anish> ... there are uris for request and the response
19:15:48 <anish> ... the binding says how the request and response gets sent/received
19:16:46 <anish> ... the ws-addressing http binding specifies how messages are composed
19:17:43 <dhull> q+
19:17:47 <anish> ... I favor this approach. I don't believe that having SOAP MEPs have helped us, in fact they have hurt us
19:18:32 <anish> ... saying one-way or req-res doesn't help as wsa:ReplyTo changes everything
19:19:28 <anish> mark: you 1st proposal aligns with the previous discussion/action
19:19:40 <anish> ... in terms of wsdl desc what is the change in the three proposals?
19:20:03 <anish> daveo: in the UsingAddressing we can say that we are using the request-optional-response
19:20:46 <anish> ... it is easier for us to write the UsingAddressing, as there are fewer things to look at (specs)
19:21:55 <anish> mark: at a high level we are not diverting from our previous approach that we decided. the question is what kind of soap meps there are and we need to figure those things out.
19:22:46 <anish> daveo: xmlp is looking for direction from us and would do what we recommend. They are amenable.
19:27:19 <anish> umit: this isn't one person or two person's thought, there has been lot of discussion on this
19:27:59 <anish> ... don't personalize the ideas
19:29:29 <anish> mark: can we come to an agreement on the proposal that we have seen and recommend something to XMLP
19:29:54 <anish> ... I'm going to tell them that we need something very quickly that won't blow away our schedule
19:31:13 <anish> ... if people want to go to XMLP and advocate a particular proposal they should join XMLP
19:31:16 <anish> ---------------------------
19:31:17 <anish> LUNCH
19:31:19 <anish> ---------------------------------
19:31:20 <Zakim> -Mark_Peel
19:32:25 <Zakim> -Prasad_Yendluri
19:33:05 <Zakim> -MSEder
19:34:08 <pauld> pauld has joined #ws-addr
20:04:05 <yinleng> yinleng has joined #ws-addr
20:10:33 <Zakim> +YinLeng
20:20:40 <Zakim> -YinLeng
20:33:42 <Zakim> +MSEder
20:33:45 <Zakim> -[TIBCO]
20:33:46 <Zakim> +[TIBCO]
20:35:06 <Zakim> +YinLeng
20:40:29 <MSEder> MSEder has joined #ws-addr
20:40:42 <MSEder> zakim, mute me
20:40:42 <Zakim> MSEder should now be muted
20:43:10 <Zakim> +Prasad_Yendluri
20:44:46 <vikas> start of afternoon session
20:45:15 <dorchard> dorchard has joined #ws-addr
20:45:15 <Arun> Arun has joined #ws-addr
20:45:28 <vikas> mnot: What if anything we can recommend to XMLP; if we cannot, we communicate no requirements from us to XMLP
20:45:44 <bob> bob has joined #ws-addr
20:45:53 <vikas> mnot: However, then we have to live with what they do ; so lets us arrive at requirements
20:46:11 <vikas> mnot: There are four proposals. Dave's proposal is #1
20:46:46 <vikas> paco: All we say right now is give us a 1-way MEP
20:47:00 <vikas> mnot: MarcH's proposal is #2
20:47:17 <vikas> mnot: #3 and #4, Dorcard's 2nd and 3rd proposal
20:47:17 <uyalcina> uyalcina has joined #ws-addr
20:48:24 <vikas> glen: refers to a another proposal, anish points out that it is only for soap and wsdl 11
20:48:41 <vikas> mnot: Do we need a 5th option? 
20:48:53 <vikas> mnot: less is more
20:49:54 <vikas> glen and anish are in discussion about 202 "fix"
20:50:15 <vikas> mnot: 1) 1-way SOAP MEP w/HTTP Binding
20:50:28 <vikas> mnot: 2) Rix Req/Res SOAP HTTP Binding 202 Problem
20:51:21 <vikas> mnot: 3) Dynamic MEP Switching or 1+2 in one binding
20:51:54 <vikas> mnot: 4) Req/Res MEP and HTTP Binding 
20:52:06 <vikas> glen: objects to option 3) being classified as 1 + 2
20:52:51 <vikas> dorchard: clarifies
20:53:46 <vikas> glen: maintains position, they are different i.e. proposal 3 is not 1+2
20:54:12 <vikas> mnot: is this a discussion that can be taken offline
20:54:52 <mnot> mnot has joined #ws-addr
20:55:35 <vikas> umit: What is difference between 2 and 4
20:55:49 <vikas> glen: no state machine in 4
20:57:30 <vikas> glen: we can specify wire level messages and say we don't care how to do it
20:57:46 <vikas> mnot: Can you live with characterization of four options
20:58:23 <vikas> dorchard: Clarfications spends time which can be used in arriving at recommendations
20:58:31 <Zakim> -YinLeng
20:59:40 <vikas> mnot: adds a fifth proposal 1 + 2 (separate bindings)
21:00:06 <vikas> it is 2:00PM
21:00:52 <vikas> mnot: Polls for consensus on 5 options
21:01:11 <vikas> dhull: where is mine ? Everything is 1-way
21:01:35 <vikas> mnot: 1-way MEP that has no directionality
21:01:43 <vikas> dhull: yes
21:02:12 <vikas> mnot: Isn't that #1?
21:03:09 <vikas> mnot: Adding a sixth option: (6) 1-WAY (Directionless) SOAP MEP + SOAP over POST and SOAP over RESPONSE
21:03:52 <Paco> q+
21:04:16 <vikas> anish: What do you mean by Dynamic ? 
21:04:26 <vikas> dorchard: Dynamic MEP Switching
21:04:59 <vikas> paco: Recommend the solution (behavior) not design the solution
21:05:13 <vikas> glen: We need to know the semantics of WSDL extension
21:05:29 <vikas> paco: AI from XMLP was to define the behavior. 
21:06:52 <vikas> mnot: Polling for consensus again 
21:09:35 <pauld> pauld has joined #ws-addr
21:10:09 <vikas> markg: What is status quo? 
21:10:12 <chad> chad has joined #ws-addr
21:10:14 <vikas> mnot: Option 1
21:10:33 <anish> chad: new vote
21:10:33 <chad> new poll
21:10:55 <anish> chad: question: Recommendations to XMLP
21:11:18 <anish> chad: option 1: 1-way SOAP MEP w/HTTP Binding(s) [status quo]
21:11:37 <anish> chad: option 2: Fix Req/Res SOAP HTTP binding 202 problem
21:11:53 <anish> chad: option 3: 1 + 2 in one binding (dynamic MEP switching)
21:12:14 <anish> chad: option 4: Req/Res MEP + HTTP Binding (Simplified - no state machine)
21:12:27 <anish> chad option 5: 1 +2 (separate bindings)
21:12:43 <anish> chad: option 5: 1 +2 (separate bindings)
21:13:53 <jeffm> jeffm has joined #ws-addr
21:15:29 <vikas> dhull: wants to reword option number 6
21:17:38 <anish> q+
21:19:52 <vikas> mnot: Recommend XMLP that whatever the solution, the ack problem should be fixed
21:24:57 <anish> chad: option 6: 1-way (directionless) SOAP MEP + SOAP-over-POST/Response Bindings
21:25:12 <anish> chad: options
21:25:42 <dorchard> Of the options: 1) is daveO #1; #2) is MarcH; 3) is daveO #2; 4) is DaveO #3; #5) is synthetic; #6; is DaveH's 
21:25:58 <GlenD> vote: 2
21:26:32 <dorchard> vote: 4
21:26:39 <vikas> vote: 1
21:26:42 <hugo> vote: 5, 1, 2
21:26:45 <uyalcina> vote: 5, 2, 1
21:26:45 <Arun> 2
21:26:51 <Arun> vote: 2
21:26:54 <TonyR> vote:3, 4, 1
21:26:55 <Paco> vote: 1
21:26:56 <Marsh> vote: 1
21:27:06 <dhull> vote: tibco: 6,5,4
21:27:14 <MSEder> vote: 1
21:27:16 <Marsh> vote: Rebecca: 5, 1, 4
21:27:17 <pauld> vote: 1
21:27:25 <gil> vote: 4
21:27:36 <prasad> vote: 1, 3
21:27:56 <Marsh> vote: Prasad: 1, 3
21:27:58 <anish> vote: prasad: 1 3
21:28:21 <anish> vote: prasad:
21:28:29 <anish> vote: prasad: abstain
21:28:49 <bob> vote 1
21:29:04 <bob> chad: vote: 1
21:29:12 <pauld> vote: 4
21:29:22 <mnot> chad, votes?
21:29:26 <dhull> vote: abstain
21:29:32 <anish> vote: 5, 3, 1, 2 4
21:29:39 <anish> vote: 5 3 1 2 4
21:29:42 <gil> gil: abstain
21:29:49 <gil> chad: abstain
21:29:49 <uyalcina> vote: 2, 5, 1
21:29:52 <anish> vote: 5, 3, 1, 2, 4
21:30:01 <anish> chad: votes
21:30:05 <dhull> chad: vote: abstain
21:30:07 <TRutt> TRutt has joined #ws-addr
21:30:11 <bob> chad: 1
21:30:12 <TRutt> vote: 1
21:30:15 <pauld> vote: vote: abstain
21:30:45 <TRutt> vote: abstain
21:31:13 <anish> chad: count
21:31:22 <anish> chad, count
21:31:22 <chad> Question: Recommendations to XMLP
21:31:22 <chad>     Option 1: 1-way SOAP MEP w/HTTP Binding(s) [status quo] (6)
21:31:22 <chad>     Option 2: Fix Req/Res SOAP HTTP binding 202 problem (3)
21:31:22 <chad>     Option 3: 1 + 2 in one binding (dynamic MEP switching) (1)
21:31:22 <chad>     Option 4: Req/Res MEP + HTTP Binding (Simplified - no state machine) (2)
21:31:23 <chad>     Option 5: 1 +2 (separate bindings) (3)
21:31:25 <chad>     Option 6: 1-way (directionless) SOAP MEP + SOAP-over-POST/Response Bindings (1)
21:31:27 <chad> 21 voters: anish (5, 3, 1, 2, 4) , Arun (2) , bob (1) , dhull () , dorchard (4) , gil () , GlenD (2) , hugo (5, 1, 2) , Marsh (1) , MSEder (1) , Paco (1) , pauld (4) , Prasad (1, 3) , prasad () , Rebecca (5, 1, 4) , tibco (6, 5, 4) , TonyR (3, 4, 1) , TRutt () , uyalcina (2, 5, 1) , vikas (1) , vote () 
21:31:31 <chad> Round  1: Count of first place rankings.
21:31:33 <chad> Round  2: Tie when choosing candidate to eliminate.
21:31:35 <chad>           Tie at round 1 between 3, 6.
21:31:37 <chad>           Tie broken randomly.
21:31:39 <chad>           Eliminating candidate 3.
21:31:41 <chad> Round  3: Eliminating candidate 6.
21:31:43 <chad> Round  4: Tie when choosing candidate to eliminate.
21:31:45 <chad>           Tie at round 3 between 2, 4.
21:31:47 <chad>           Tie at round 2 between 2, 4.
21:31:49 <chad>           Candidate 4 has the fewest votes at round 1.
21:31:51 <chad>           Eliminating candidate 4.
21:31:53 <chad> Round  5: Eliminating candidate 2.
21:31:55 <chad> Round  6: Eliminating candidate 5.
21:31:57 <chad>           Candidate 1 is elected.
21:31:59 <chad> Winner is option 1 - 1-way SOAP MEP w/HTTP Binding(s) [status quo]
21:32:17 <anish> chad, details
21:34:49 <TonyR> vote: 3, 4, 5, 1
21:34:52 <bob> chad: 5,1
21:34:56 <uyalcina> vote: 5
21:35:04 <anish> chad, count
21:35:04 <chad> Question: Recommendations to XMLP
21:35:04 <chad>     Option 1: 1-way SOAP MEP w/HTTP Binding(s) [status quo] (5)
21:35:04 <chad>     Option 2: Fix Req/Res SOAP HTTP binding 202 problem (2)
21:35:04 <chad>     Option 3: 1 + 2 in one binding (dynamic MEP switching) (1)
21:35:04 <chad>     Option 4: Req/Res MEP + HTTP Binding (Simplified - no state machine) (2)
21:35:05 <chad>     Option 5: 1 +2 (separate bindings) (5)
21:35:07 <chad>     Option 6: 1-way (directionless) SOAP MEP + SOAP-over-POST/Response Bindings (1)
21:35:09 <chad> 21 voters: anish (5, 3, 1, 2, 4) , Arun (2) , bob (5, 1) , dhull () , dorchard (4) , gil () , GlenD (2) , hugo (5, 1, 2) , Marsh (1) , MSEder (1) , Paco (1) , pauld (4) , Prasad (1, 3) , prasad () , Rebecca (5, 1, 4) , tibco (6, 5, 4) , TonyR (3, 4, 5, 1) , TRutt () , uyalcina (5) , vikas (1) , vote () 
21:35:13 <chad> Round  1: Count of first place rankings.
21:35:15 <chad> Round  2: Tie when choosing candidate to eliminate.
21:35:17 <chad>           Tie at round 1 between 3, 6.
21:35:19 <chad>           Tie broken randomly.
21:35:21 <chad>           Eliminating candidate 6.
21:35:23 <chad> Round  3: Eliminating candidate 3.
21:35:25 <chad> Round  4: Eliminating candidate 2.
21:35:27 <chad> Round  5: Eliminating candidate 4.
21:35:29 <chad> Round  6: Eliminating candidate 1.
21:35:31 <chad>           Election over.  Candidate 5 is elected.
21:35:33 <chad> Winner is option 5 - 1 +2 (separate bindings)
21:35:39 <anish> chad, details
21:36:30 <anish> chad: votes
21:39:58 <vikas> mnot: Requirement for a 1 way MEP with anish's identified problem; no strong inclination to any particular style of solution
21:42:11 <MSEder> zakim, who is on the call
21:42:11 <Zakim> I don't understand 'who is on the call', MSEder
21:42:39 <MSEder> zakim, who is there
21:42:39 <Zakim> I don't understand 'who is there', MSEder
21:43:02 <vikas> mnot: The WSA Group requests the XML protocol working group to fulfil the following requirements: 
21:43:14 <pauld> I make the point that the issue for our schedule is that the 202 errata allows to to CR test the SOAP binding, the rest can wait until we have to consider describing exchanges in WSDL
21:43:22 <vikas> mnot: Delivery of a one way SOAP MEP and corresponding HTTP binding, such as that proposed by dorchard and 
21:43:29 <vikas> required by the WSD WG
21:43:53 <vikas> Correction of the ack problem pointed out by Anish
21:44:00 <vikas> and Timely delivery
21:44:36 <MSEder> zakim, who is on the call?
21:44:36 <Zakim> On the phone I see [TIBCO], MSEder (muted), Prasad_Yendluri
21:45:02 <vikas> mnot: Does anyone object to this statement
21:45:20 <vikas> no objections raised
21:46:49 <vikas> On i59, a separate group to work offline and make a proposal to wider WG
21:48:33 <mnot> http://www.w3.org/mid/37D0366A39A9044286B2783EB4C3C4E8208172@RED-MSG-10.redmond.corp.microsoft.com
21:48:33 <vikas> Moving on CR Issue with no number
21:50:31 <vikas> jmarsh: Not completely editorial but changes in wording will capture intent better
21:51:04 <vikas> jmarsh: Discuss proposal 
21:51:18 <vikas> mnot: close it by accepting proposal
21:51:24 <vikas> mnot: CR2 Next
21:52:45 <vikas> hugo: We had decided to decide on this issue much later
21:53:00 <vikas> mnot: Moving on to CR3
21:53:31 <vikas> http://www.w3.org/2002/ws/addr/cr-issues/#cr3
21:53:44 <bob> bob has joined #ws-addr
21:55:56 <bob> ping
21:56:25 <vikas> jmarsh: The existing resolution got a push back from Nokia. They want a xml:id added to wsa:epr/metadata and/or wsa:/epr/refp
21:58:11 <vikas> jmarsh: why not wsu:id?
21:59:29 <vikas> jmarsh: because the id is required for signing, xml:id might confuse people
22:00:07 <vikas> It is 3:00PM
22:00:28 <vikas> jmarsh: if we don't have to put something in, don't
22:00:51 <vikas> anish: Profile might dictate which xx:id to use
22:01:03 <gil> q+
22:01:38 <vikas> hugo: Can we find a compromise? We don't add it to our schema but point to other specification. 
22:02:00 <vikas> jmarsh: Nokia claims that it is a interoperability problem, but it is difficult to see why
22:02:16 <vikas> mnot: He might be using us as a forcing function to get something else
22:02:56 <vikas> anish: Why is this a specific problem for us ? There are lots of recomendations that define SOAP headers. But they don't say anything about ID. So why should we? 
22:03:42 <vikas> mnot: show of hands for maintaining status quo
22:04:01 <vikas> bobf: Rule it out of scope
22:04:43 <vikas> tony: Put both xml:id and wsu:id as alternate soultions. 
22:05:43 <vikas> ******************  BREAK *********************** WILL RETURN AT 3:30pm
22:08:04 <bob> bob has joined #ws-addr
22:08:20 <MSEder> zakim, unmute me
22:08:20 <Zakim> MSEder should no longer be muted
22:08:49 <Zakim> -MSEder
22:23:49 <vikas> RESUMING
22:25:13 <vikas> jmarsh: Reading an email to public email in http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0000.html
22:26:11 <vikas> gil: Can one get a SOAPAction back on response
22:26:20 <vikas> hugo: In SOAP12 you can expect it 
22:28:04 <vikas> anish: wsa:Action and soap:Action could be sibling attributes and both can be specified and our spec will restrict what those values are i.e. they are the same
22:29:55 <vikas> becky: We are putting action attribute at the message level and the WSDL group wants confirmation? 
22:30:39 <vikas> anish: They have a new attribute at the message level and we have a restriction on that attribute and we would need to respecify it. 
22:30:49 <bob> bob has joined #ws-addr
22:30:52 <vikas> becky: They are not asking anything that we don't want to do 
22:31:03 <vikas> anish: We need to add further clarification
22:31:11 <vikas> umit: We may not need to change anything
22:33:51 <vikas> anish: may be an issue needs to be raised on the consequences of this on wsdl 11
22:33:59 <vikas> mnot: Go ahead and file it
22:35:06 <vikas> mnot: WG agrees with that issue and jmarsh to coordinate it back with wsdl wg
22:36:25 <vikas> mnot: Next is Umit's anon URI issue
22:40:48 <vikas> umit: Loosening definition to include EPRs from other specifications. The issue is in http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0035.html
22:42:32 <vikas> anish: Change the semantics to say "The anonymous URI references back channel for any binding"
22:45:02 <Marsh> zakim, who's on the phone?
22:45:02 <Zakim> On the phone I see [TIBCO], Prasad_Yendluri
22:46:48 <vikas> glenm: Two changes: "Replace ReplyTo  or Faulto with "an"
22:48:22 <vikas> glenm: Add "for response messages" at the end of sentence beginning with "Any underlying protoco..."
22:51:59 <uyalcina> uyalcina has joined #ws-addr
22:52:59 <vikas> Next is http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0051.html
22:53:35 <pauld> s/glenm/glen/g
22:55:28 <vikas> glen: It is mostly editorial; 
22:56:14 <vikas> andreas: From discussions yesterday we don't have an EPR in WSDL. 
22:56:21 <vikas> glen: Yes that is a different issue
22:57:01 <vikas> mnot: Proposal accepted. 
22:58:50 <vikas> mnot: Next is Hugos' http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Sep/0004.html
23:00:07 <vikas> It is 4:00PM
23:04:25 <vikas> mnot: We will push this one to next time. Everybody to read spec and evaluate hugo's proposal
23:06:03 <Zakim> +Gian_Sampson-Wild
23:07:09 <vikas> Next is dhull's http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0038.html
23:12:51 <vikas> dhull: How to tell is WSA is engaged when wsdl:required is false
23:13:03 <vikas> dhull: Two options as listed
23:13:16 <dorchard> dorchard has joined #ws-addr
23:14:32 <gil> q+
23:18:47 <mnot> ack dhull, paco, anish
23:18:50 <vikas> tony: Binding decides whether wsa is in use. 
23:18:56 <mnot> ack dhull
23:19:00 <mnot> ack paco
23:19:02 <mnot> ack anish
23:19:04 <mnot> ack gil
23:19:11 <anish> q+
23:20:56 <uyalcina> q+
23:21:02 <anish> q-
23:22:05 <dhull> q+
23:22:41 <TonyR> q+
23:22:52 <gil> +1 to jeff
23:22:59 <Paco> q+
23:23:17 <mnot> ack uyal
23:23:24 <anish> jeff, there is a explicit indicator in case of soap binding -- wsa:Action
23:23:40 <Paco> +1
23:25:04 <mnot> ack dh
23:25:25 <anish> q+
23:26:17 <uyalcina> I agree with Jeff that defaulting is getting in the way for deterministicly deciding just by looking at the wire whether WS-A is engaged or not.
23:27:25 <vikas> dhull: discusses the two resolutions in the email referenced above. 
23:27:52 <mnot> ack tony
23:27:54 <Marsh> q+
23:28:01 <vikas> dhull: larger issues is need to define it explicitly ; currently it is all implicit
23:28:50 <vikas> tony: once you go through the binding, all defaults are set. You have to make decision if wsa is engaged before settings defaults
23:29:17 <dhull> q+
23:30:44 <vikas> tony: after the default setting stage, one has list of MAPS , binding should make that decision, that decision does may not be based on content of the message. 
23:31:05 <mnot> q?
23:31:08 <TRutt> q+
23:31:08 <mnot> ack Paco
23:31:28 <vikas> paco: until one knows if wsa is engaged, no point in talking about maps
23:31:49 <vikas> paco: Action is giving us everything we need. There is no need for wsa:engaged
23:33:29 <jeffm> q+
23:33:41 <vikas> this discussion is in context of wsdl:required is false
23:33:44 <uyalcina> q+
23:33:45 <mnot> ack anish
23:33:51 <vikas> anish: this is binding specific problem 
23:34:53 <vikas> anish: what is the intention of the sender of the message. If there is any header then the sender intended use of wsa
23:35:57 <vikas> paco: we want to make explicit what the intention of the sender is, not try to guess. Action is the way
23:36:01 <mnot> ack marsh
23:37:15 <vikas> jmarsh: if action is missing, send back the header and ask for action
23:38:46 <vikas> tony: if action is the flag, where is it determined and how it is carried forth
23:42:21 <vikas> anish: if the receiving server understands the headers and finds no action, then?
23:42:40 <mnot> ack dhull
23:42:52 <uyalcina> q-
23:42:55 <vikas> dhull: convinced by tony's proposal
23:43:10 <uyalcina> I don't need to speak, I agree with Jonathan and Paco. It is simple, deterministic
23:43:17 <vikas> dhull: Would like to propose adoption of proposal 2 in the email referenced
23:44:52 <vikas> tony: Binding determines if wsa is engaged and everything comes after that
23:45:02 <mnot> q+ Becky
23:45:41 <vikas> This flag would be in the core and binding would implement it 
23:45:44 <mnot> ack Trutt
23:46:33 <mnot> ack jeff
23:48:15 <vikas> mnot: couple of sentences in the core which says  there is a concept of boolean flag which says wsa is engaged and that is implemented in the binding
23:48:44 <vikas> tony: We cannot base the core on presence of headers in the binding
23:49:04 <mnot> ack Becky
23:50:26 <anish> I've an algorithm that tells you when it is engaged:
23:50:26 <anish> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/0100.html
23:50:45 <anish> if (mU='1' on any WSA header) //receiver must engage WSA or fault
23:50:45 <anish> {
23:50:45 <anish>    if (receiver does not understand WSA)
23:50:45 <anish>    {
23:50:45 <anish>       fault and stop processing the message
23:50:46 <anish>    }
23:50:48 <anish>    if (any WSA rule is violated) //including missing wsa:Action
23:50:48 <Marsh> q+ 
23:50:50 <anish>    {
23:50:52 <anish>       fault and stop processing the message
23:50:54 <anish>    }
23:50:56 <anish>    process the message as a WSA message
23:50:58 <anish> }
23:51:01 <anish> else //sender does not mandate WSA, receiver gets to choose
23:51:02 <anish> {
23:51:04 <anish>    if (receiver wants to process the message with WSA engaged)
23:51:06 <anish>    {
23:51:06 <Zakim> -[TIBCO]
23:51:08 <anish>      if (any WSA rule is violated) //including missing wsa:Action
23:51:10 <anish>      {
23:51:12 <anish>        fault and stop processing the message
23:51:14 <anish>      }
23:51:16 <anish>      process the message as a WSA message
23:51:18 <anish>    }
23:51:18 <Marsh> zakim, who's on the phone
23:51:18 <Zakim> I don't understand 'who's on the phone', Marsh
23:51:20 <anish>    else
23:51:21 <Marsh> zakim, who's on the phone?
23:51:21 <Zakim> On the phone I see Prasad_Yendluri, Gian_Sampson-Wild
23:51:22 <anish>    {
23:51:24 <anish>      ignore all WSA headers, if any
23:51:26 <anish>      process the message as a non-WSA message
23:51:28 <anish>    }
23:51:30 <anish> }
23:51:32 <anish> q+
23:52:08 <Zakim> +[TIBCO]
23:53:41 <anish> +1 to paul
23:54:21 <vikas> paul: Binding dependent, ws-addressing engaged is 
23:54:25 <mnot> q?
23:54:27 <mnot> ack marsh
23:54:28 <anish> q?
23:54:32 <anish> q-
23:54:45 <Arun> Arun has joined #ws-addr
23:56:58 <vikas> mnot: The whole issue boils down to if we need a concept of "being engaged" in core 
23:58:19 <vikas> mnot: straw poll says people prefer it stay in binding only and not in the core
23:58:34 <anish> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/0100.html