20:00:41 <RRSAgent> RRSAgent has joined #ws-async
20:00:41 <RRSAgent> logging to http://www.w3.org/2005/07/06-ws-async-irc
20:01:29 <Zakim> WS_TF(async)4:00PM has now started
20:01:35 <Zakim> +Glen
20:01:37 <steve_winkler> steve_winkler has joined #ws-ASYNC
20:02:16 <Zakim> +swinkler
20:02:20 <Zakim> -Glen
20:02:21 <Zakim> +Glen
20:02:29 <steve_winkler> Zakim, swinkler is me
20:02:29 <Zakim> +steve_winkler; got it
20:03:15 <TonyR> TonyR has joined #ws-async
20:04:23 <anish> anish has joined #ws-async
20:04:35 <Zakim> +Anish
20:05:49 <Zakim> +??P7
20:06:01 <TonyR> zakim, ??p7 is me
20:06:01 <Zakim> +TonyR; got it
20:07:58 <Zakim> +Dave_Hull
20:08:15 <dhull> dhull has joined #ws-async
20:08:27 <anish> Scribe: anish
20:08:36 <anish> Chair: GlenD
20:08:48 <dhull> zakim, who is here
20:08:48 <Zakim> dhull, you need to end that query with '?'
20:08:51 <dhull> zakim, who is here?
20:08:51 <Zakim> On the phone I see Glen, steve_winkler, Anish, TonyR, Dave_Hull
20:08:52 <Zakim> On IRC I see dhull, anish, TonyR, steve_winkler, RRSAgent, Zakim, GlenD
20:08:52 <GlenD> Meeting: WS-Async Task Force Telcon
20:08:55 <dhull> zakim, who is not here?
20:08:55 <Zakim> I don't understand your question, dhull.
20:09:00 <Zakim> +Dave_Orchard
20:09:20 <anish> Glen sent out the decision matrix/summary
20:09:46 <dhull> q+ to ask yet another annoying question
20:09:57 <anish> Glen: there is a little bit of commentary and a bunch of proposals in it. Not sure which are stale and which are current. This is a draft. See if it is accurate. DaveO just sent another proposal
20:10:02 <GlenD> ack dhull
20:10:02 <Zakim> dhull, you wanted to ask yet another annoying question
20:10:34 <anish> dhull: we had those interesting usecases such as resource constrained usecase, 303 response, reverse-http binding
20:11:00 <anish> ... since we are looking at the broader scope we still need to ensure that we don't drop it on the floor
20:11:26 <anish> ... when we get to a leaf on the decision tree we can link it to the usecases that it satisfies
20:12:03 <anish> GlenD: that would entail expanding the middle section -- will do that
20:12:37 <anish> ... maybe i should just move that out to the 3rd section in the question area and say what it does wrt each question
20:13:38 <anish> daveo: do i need to update the scenarios doc?
20:14:04 <anish> GlenD: it does have the polling
20:14:17 <anish> daveo: but not the redirect
20:14:46 <anish> ... I think the 303 is a required part of the http binding
20:15:05 <anish> q+
20:15:23 <anish> ... current http semantics + bindings state machine covers it
20:16:04 <anish> Glend: but that does not cover what Marc was talking about it
20:16:38 <anish> daveo: if i get 303 i don't know what that means -- do i throw away the 'post'
20:18:33 <steve_winkler> in the spec, 303 states:  The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. 
20:19:38 <anish> anish: there is an ambiguity as to what to do with 3xx cause the binding says -- go to INIT stage
20:20:33 <anish> ACTION: DaveO to figure out how to do post followed by a different location
20:20:56 <GlenD> DaveO to add Marc's 303-based async scenario to the list
20:23:56 <anish> <more discussion on HTTP 3xx case>
20:25:15 <anish> anish: for those on XMLP WG this will be discussed during next week's agenda
20:25:19 <GlenD> ack anish
20:25:33 <anish> s/agenda/meeting/
20:26:04 <anish> glend: dave talk about your new MEP binding
20:26:48 <anish> daveO explains the new proposal at http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/att-0010/ws-addr-soapadjuncts-simplemeps_httpbinding.html
20:27:41 <anish> daveO: expunged any mention of soap req-res
20:27:59 <anish> ... but does allow SOAP
20:28:50 <anish> GlenD: the response status does it have a value when it is in the midst. Can i query that to figure out if it is done?
20:29:01 <anish> daveO: don't know. It is a little rough/rushed
20:29:27 <anish> Glend: u need some way of indicating upfront what is going to happen
20:29:59 <anish> daveO: on the wire behavior, if u get a 200 -- u may/may not get a body. If 202 -- no body. Moved state machine in the http binding
20:30:53 <anish> ... if u get a 202, the entity body will be empty and the next state is a success
20:31:24 <anish> GlenD: but the abstract MEP is independent from HTTP, needs someway of indicating that the MEP is complete
20:31:33 <anish> daveO: that is in there -- response status
20:31:46 <anish> GlenD: that does not have a value until the MEP is done
20:32:00 <anish> ... u might want to clarify that
20:32:19 <anish> ... or add a third value called 'ongoing'
20:33:40 <anish> daveO: if u take a look at the http binding that is there now, it looks lame -- it looks like a lot of ways of saying use HTTP
20:33:57 <dhull> q+
20:34:06 <anish> ... it is an attempt to not have state-machine in the MEP
20:34:28 <GlenD> ack dhull
20:35:51 <anish> dhull: i like the idea of trying to get away from SOAP MEPs and doing MEPs in one place. Since WSDL MEPs are well entrenched and tie into BPEL. The pieces we need to put SOAP message on the wire -- to use 'POST' and the media type. HTTP does the correlation for you for free.
20:36:07 <anish> ... WSDL req-res talks about HTTP's correlation regardless of SOAP
20:36:26 <anish> ... correlation may be the same regardless of whether u use SOAP or not
20:36:45 <anish> GlenD: it is not just the HTTP behavior
20:37:06 <anish> dhull: I would be happier if we just talk about the messages on the wire
20:37:30 <anish> daveO: the question is, if u use this binding can u still use the soap media-type
20:38:17 <anish> anish: why couldn't u use the same mediatype?
20:39:01 <anish> daveO: there is a relationship between soap faults and http status code
20:39:15 <anish> daveO: wrt to mediatype i have a question about one-way
20:40:06 <anish> ... if u get a 200 the soap response is in the entity body, but ws-i already says that u can use 202 and still use the same media-type
20:40:19 <anish> GlenD: i think it is mostly about the binding and not about the media-type
20:42:29 <anish> dhull: keep the higher level description uniform -- res-res is a req followed by response (everything is one-way)
20:43:02 <anish> ... a cellphone is going to do a http-request and get the 'request' as part of the http-response
20:43:25 <anish> ... request means move the soap message from the client to the server
20:43:37 <anish> daveO: the new binding that i have does not say that
20:44:01 <anish> dhull: from the functional MEP the cell-phone case is a request
20:44:16 <anish> .. same from the WSDL POV
20:44:46 <anish> daveO: it that case, what i have does not cover that
20:45:24 <Zakim> -Dave_Orchard
20:45:28 <anish> dhull: i'm musing about a soap-over-http request mini-binding and soap-over-http response mini-binding -- i.e. do what we ordinarily do
20:45:34 <Zakim> +Dave_Orchard
20:46:33 <anish> GlenD: it seems that there is a transport level difference in the usual case and the polling case
20:47:04 <anish> ... u do a request and the request tells u about how to do the response
20:47:45 <anish> <comparison to air-travel and reverse-http binding made>
20:48:01 <anish> glenD: at some level u have to say that the request goes on the http-request
20:48:29 <anish> dhull: my intuition is that 'can/should' be factored out of whether the message is SOAP or not
20:48:52 <anish> daveO: i could add yet another scenario
20:49:14 <anish> anish: it was nokia who was interested in this scenario
20:49:29 <GlenD> ACTION: DaveO to add polling (cellphone) use case to scenario list
20:50:14 <anish> daveO: can't imagine how to do that without an extension
20:50:39 <anish> GlenD: it is certainly doable
20:52:05 <anish> GlenD: lets see if we can tease out more of a consensus amongst the group, not sure if we want to focus on that usecase.
20:53:31 <anish> daveO: i heard some consensus last week to get rid of SOAP MEP
20:53:50 <anish> anish: i wanted to see how the binding would look like if we took an approach similar to SOAP 1.1
20:54:17 <anish> GlenD: do u think an implementor could figure out what to do and get interop
20:54:27 <anish> daveO: yes
20:54:55 <anish> GlenD: where/how does this get described. Somewhere we have to say that u have to use 'POST'
20:55:15 <anish> daveO: it isn't specified, I guess if the web-method is not specified then u must use POST
20:55:31 <anish> Glend: then u are going towards the existing binding
20:55:50 <dhull> q+
20:56:02 <anish> GlenD: one thing I like about dhull's latest proposal is that we won't have to change the current binding much
20:56:24 <anish> ... may require minimal effort
20:57:02 <anish> ... am sympathetic to the idea of getting rid of SOAP MEPs, but am worried about the amount of work/coordination etc
20:57:27 <anish> DaveO: would like to look at the matrix and see which usecases it meets
20:57:33 <GlenD> ack dhull
20:57:37 <anish> dhull: meant to cover all of that
20:58:10 <anish> dhull: the engineer side of me like the minimal approach, the architect in me likes getting rid of SOAP MEP
20:58:18 <steve_winkler> Zakim, mute dhull
20:58:18 <Zakim> sorry, steve_winkler, I do not see a party named 'dhull'
20:58:30 <steve_winkler> hopefully that didn't really work.
20:58:35 <anish> zakim, who is on the phone?
20:58:35 <Zakim> On the phone I see Glen, steve_winkler, Anish, TonyR, Dave_Hull, Dave_Orchard
20:59:03 <anish> zakim, Dave_Hull is dhull
20:59:03 <Zakim> +dhull; got it
20:59:38 <anish> glenD: we talked about knobs last week
21:00:57 <anish> ... concerned that as we description everything that is needed, we might end up very close to the current way MEPs are described
21:01:41 <anish> DaveO: u do not describe the time-varing properties in MEP
21:03:13 <anish> GlenD: where in the soap/wsdl stack does it get described
21:04:34 <anish> ... if get rid of SOAP MEPs then we need to change the wsdl's soap binding as well
21:04:57 <anish> ... and have to say exactly which binding is being used
21:05:16 <anish> daveO: u say which MEP (eg req-res) and the binding
21:05:49 <anish> ... the core is to not say that there is a response available and this is pushed in the http part
21:06:06 <anish> glenD: but this is not generic across bindings
21:06:22 <anish> ... what do i do with this properties as an implementor
21:06:35 <anish> ... write code that closely mirrors what is going on wrt the MEP
21:06:54 <anish> ... send the request and wait for the status to change and monitor for a response
21:07:05 <anish> ... may be have a tri-state field in Java
21:07:20 <anish> DaveO: if u want to write a different MEP/binding then go for it
21:07:46 <anish> ... I don't see the problem
21:08:09 <anish> glenD: when u define things in the abstract, it is useful to have the contract
21:08:38 <anish> DaveO: looks like u want a state-machine based MEP
21:08:46 <anish> ... and that is tied to SOAP
21:09:03 <anish> glenD: or a soap req-res MEP with the ability to get a response
21:09:13 <anish> ... that is what dull's proposal does
21:09:54 <anish> DaveO: that is not allowed in the SOAP HTTP binding
21:10:14 <anish> glenD: yes it isn't, we are talking about changes to the existing binding or a new binding
21:12:24 <anish> <discussion of ws-i's one-way and assertions in wsdl>
21:14:54 <anish> glenD: daveO we need to figure out whether we need a 'new' binding or whether we can do with errata etc
21:15:35 <anish> ... we should have everyone send in what their response is to this question
21:15:45 <Zakim> -Dave_Orchard
21:16:39 <GlenD> ACTION: Glen to mail out a request for answers to the matrix from each TF member
21:18:39 <anish> <discussion on how to move forward>
21:19:00 <anish> dhull: i'm torn about getting rid of SOAP MEPs, it is too late in the game
21:19:43 <anish> GlenD: i do code as well as architecting and I haven't figured out the no SOAP MEPs approach
21:21:35 <anish> anish: not sure if moving the state-transition to the transport level is a good idea. Wondering if there is some benefit to defining this at a higher level
21:22:37 <anish> tony: i'm not sure which is the right way to fix this. but obviously there is something broken
21:23:53 <anish> <more discussion on why we are having trouble achieving consensus>
21:29:57 <anish> anish: wondering aloud if we should define a new SOAP module which indicates the MEP that the message is part of
21:32:50 <Zakim> -steve_winkler
21:33:41 <anish> <discussion on how dhull's proposal will work for various cases>
21:37:10 <Zakim> -dhull
21:37:12 <anish> glend: go read the proposal and matrix
21:37:12 <Zakim> -Glen
21:37:15 <Zakim> -Anish
21:37:18 <anish> adjourned
21:37:19 <Zakim> -TonyR
21:37:20 <Zakim> WS_TF(async)4:00PM has ended
21:37:21 <Zakim> Attendees were Glen, steve_winkler, Anish, TonyR, Dave_Orchard, dhull
21:37:32 <anish> rrsagent, generate minutes
21:37:32 <RRSAgent> I have made the request to generate http://www.w3.org/2005/07/06-ws-async-minutes.html anish
21:37:44 <TonyR> TonyR has left #ws-async
21:38:06 <anish> rrsagent, please make log public
21:38:27 <anish> zakim, bye
21:38:27 <Zakim> Zakim has left #ws-async
21:38:54 <anish> rrsagent, bye
21:38:54 <RRSAgent> I see 3 open action items:
21:38:54 <RRSAgent> ACTION: DaveO to figure out how to do post followed by a different location [1]
21:38:54 <RRSAgent>   recorded in http://www.w3.org/2005/07/06-ws-async-irc#T20-20-33
21:38:54 <RRSAgent> ACTION: DaveO to add polling (cellphone) use case to scenario list [2]
21:38:54 <RRSAgent>   recorded in http://www.w3.org/2005/07/06-ws-async-irc#T20-49-29
21:38:54 <RRSAgent> ACTION: Glen to mail out a request for answers to the matrix from each TF member [3]
21:38:54 <RRSAgent>   recorded in http://www.w3.org/2005/07/06-ws-async-irc#T21-16-39