<scribe> Scribe: anish

Glen sent out the decision matrix/summary

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

<Zakim> dhull, you wanted to ask yet another annoying question

dhull: we had those interesting usecases such as resource constrained usecase, 303 response, reverse-http binding
... since we are looking at the broader scope we still need to ensure that we don't drop it on the floor
... when we get to a leaf on the decision tree we can link it to the usecases that it satisfies

GlenD: that would entail expanding the middle section -- will do that
... maybe i should just move that out to the 3rd section in the question area and say what it does wrt each question

daveo: do i need to update the scenarios doc?

GlenD: it does have the polling

daveo: but not the redirect
... I think the 303 is a required part of the http binding
... current http semantics + bindings state machine covers it

Glend: but that does not cover what Marc was talking about it

daveo: if i get 303 i don't know what that means -- do i throw away the 'post'

<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.

anish: there is an ambiguity as to what to do with 3xx cause the binding says -- go to INIT stage

<scribe> ACTION: DaveO to figure out how to do post followed by a different location [recorded in http://www.w3.org/2005/07/06-ws-async-minutes.html#action01]

<GlenD> DaveO to add Marc's 303-based async scenario to the list

<more discussion on HTTP 3xx case>

anish: for those on XMLP WG this will be discussed during next week's meeting

glend: dave talk about your new MEP binding

daveO explains the new proposal at http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/att-0010/ws-addr-soapadjuncts-simplemeps_httpbinding.html

daveO: expunged any mention of soap req-res
... but does allow SOAP

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?

daveO: don't know. It is a little rough/rushed

Glend: u need some way of indicating upfront what is going to happen

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
... if u get a 202, the entity body will be empty and the next state is a success

GlenD: but the abstract MEP is independent from HTTP, needs someway of indicating that the MEP is complete

daveO: that is in there -- response status

GlenD: that does not have a value until the MEP is done
... u might want to clarify that
... or add a third value called 'ongoing'

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
... it is an attempt to not have state-machine in the MEP

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.
... WSDL req-res talks about HTTP's correlation regardless of SOAP
... correlation may be the same regardless of whether u use SOAP or not

GlenD: it is not just the HTTP behavior

dhull: I would be happier if we just talk about the messages on the wire

daveO: the question is, if u use this binding can u still use the soap media-type

anish: why couldn't u use the same mediatype?

daveO: there is a relationship between soap faults and http status code
... wrt to mediatype i have a question about one-way
... 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

GlenD: i think it is mostly about the binding and not about the media-type

dhull: keep the higher level description uniform -- res-res is a req followed by response (everything is one-way)
... a cellphone is going to do a http-request and get the 'request' as part of the http-response
... request means move the soap message from the client to the server

daveO: the new binding that i have does not say that

dhull: from the functional MEP the cell-phone case is a request
... same from the WSDL POV

daveO: it that case, what i have does not cover that

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

GlenD: it seems that there is a transport level difference in the usual case and the polling case
... u do a request and the request tells u about how to do the response

<comparison to air-travel and reverse-http binding made>

glenD: at some level u have to say that the request goes on the http-request

dhull: my intuition is that 'can/should' be factored out of whether the message is SOAP or not

daveO: i could add yet another scenario

anish: it was nokia who was interested in this scenario

<GlenD> ACTION: DaveO to add polling (cellphone) use case to scenario list [recorded in http://www.w3.org/2005/07/06-ws-async-minutes.html#action02]

daveO: can't imagine how to do that without an extension

GlenD: it is certainly doable
... lets see if we can tease out more of a consensus amongst the group, not sure if we want to focus on that usecase.

daveO: i heard some consensus last week to get rid of SOAP MEP

anish: i wanted to see how the binding would look like if we took an approach similar to SOAP 1.1

GlenD: do u think an implementor could figure out what to do and get interop

daveO: yes

GlenD: where/how does this get described. Somewhere we have to say that u have to use 'POST'

daveO: it isn't specified, I guess if the web-method is not specified then u must use POST

Glend: then u are going towards the existing binding
... one thing I like about dhull's latest proposal is that we won't have to change the current binding much
... may require minimal effort
... am sympathetic to the idea of getting rid of SOAP MEPs, but am worried about the amount of work/coordination etc

DaveO: would like to look at the matrix and see which usecases it meets

dhull: meant to cover all of that
... the engineer side of me like the minimal approach, the architect in me likes getting rid of SOAP MEP

<steve_winkler> hopefully that didn't really work.

glenD: we talked about knobs last week
... concerned that as we description everything that is needed, we might end up very close to the current way MEPs are described

DaveO: u do not describe the time-varing properties in MEP

GlenD: where in the soap/wsdl stack does it get described
... if get rid of SOAP MEPs then we need to change the wsdl's soap binding as well
... and have to say exactly which binding is being used

daveO: u say which MEP (eg req-res) and the binding
... the core is to not say that there is a response available and this is pushed in the http part

glenD: but this is not generic across bindings
... what do i do with this properties as an implementor
... write code that closely mirrors what is going on wrt the MEP
... send the request and wait for the status to change and monitor for a response
... may be have a tri-state field in Java

DaveO: if u want to write a different MEP/binding then go for it
... I don't see the problem

glenD: when u define things in the abstract, it is useful to have the contract

DaveO: looks like u want a state-machine based MEP
... and that is tied to SOAP

glenD: or a soap req-res MEP with the ability to get a response
... that is what dull's proposal does

DaveO: that is not allowed in the SOAP HTTP binding

glenD: yes it isn't, we are talking about changes to the existing binding or a new binding

<discussion of ws-i's one-way and assertions in wsdl>

glenD: daveO we need to figure out whether we need a 'new' binding or whether we can do with errata etc
... we should have everyone send in what their response is to this question

<GlenD> ACTION: Glen to mail out a request for answers to the matrix from each TF member [recorded in http://www.w3.org/2005/07/06-ws-async-minutes.html#action03]

<discussion on how to move forward>

dhull: i'm torn about getting rid of SOAP MEPs, it is too late in the game

GlenD: i do code as well as architecting and I haven't figured out the no SOAP MEPs approach

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

tony: i'm not sure which is the right way to fix this. but obviously there is something broken

<more discussion on why we are having trouble achieving consensus>

anish: wondering aloud if we should define a new SOAP module which indicates the MEP that the message is part of

<discussion on how dhull's proposal will work for various cases>

glend: go read the proposal and matrix

adjourned

This is scribe.perl Revision: 1.126  of Date: 2005/05/16 16:49:48  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/agenda/meeting/
Found Scribe: anish
Inferring ScribeNick: anish

WARNING: No "Topic:" lines found.

Default Present: Glen, steve_winkler, Anish, TonyR, Dave_Orchard, dhull
Present: Glen steve_winkler Anish TonyR Dave_Orchard dhull
Got date from IRC log name: 6 Jul 2005
Guessing minutes URL: http://www.w3.org/2005/07/06-ws-async-minutes.html
People with action items: daveo glen

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report