Glen - need to plot out scenarios given state of world - what is the minimum, and what is blue sky... We will walk through each usecase, and summarize

Marc - in-only use case - most people know what it is... can we achive it, yes/no. soap 1.1 and ws-i bp 1.1 describe how one-way messages can be used.

wsdl 1.1 and 2.0 both have an in-only MEP

Marc - SOAP 1.2 doesn't define an in-only MEP (it defines an out-only). SOAP http bindings require soap envelope in response

marc - minimal changes to support usecase, may not need to define soap 1.2 usecase, but it may have to change the http binding to support the usecase

Marc - I think we can accomplish this via an errata by raising an issue w/XMLP

Marc - I'm using in-only and one-way interchangeabley.. When I say one-way, I mean in-only

Glen - how would you reconcile soap req/rsp MEP indicates SOAP response comes back?

Glen - does MEP say soap out, and soap back?

Marc - just because SOAP doesn't define it, and wsdl defines in-only MEP, it can be realized w/soap/http binding

Glen - if the soap group defines it, there is an open question of wheter it's ok to add to current binding. Other people may use it to support new MEP.

marc - that's what I was hinting at w/solving w/errata. It alreadyallows to get a 202/204 (empty entity body)

Glen - binding says it supports the MEPs, is it ok for that bidning to also enable the support of other MEPs in the future by adding them (and I can tell you by adding the MEP).

Marc - I think there is extensibility in using 204 code. I think the binding is written to be open. It's allowed extensibility in mediatype (something leveraged in MTOM)

Anish - if you look at section 3.2, it doesn't say you can't have other MEPs... I think there is wording that says these are the only MEPs supported

?? - Is this an interop question?

Anish - I would rather go to XMLP and get an errata

Hugo - we need to be careful assuming it's going to be an errata. e.g., someone reading binding in soap 1.2 first addition (it doesn't have a MEP), and someone who reads the second edition and errata, and now it behaves differently

Anish - Marc, you didn't think you needed to create a new SOAP MEP (or the XMLP to create one)?

Marc - someone needs to create one, it doesn't have to be XMLP group

Anish - w/o having SOAP MEP defined, we cna't do that (agreement w/that statement)

Kevin - do we need to do something w/the HTTP bidning too?

Marc - I scaned through WSDL 2.0 http binding, I don't think we need to do anything there...

Marc - it's not covered in the default bidning, you would have to specify you want the POST method w/empty entity body in the return

Kevin - should we provide guidence in the spec of binding wsdl one-way to http req/resp, we should be ok?

Marc - you could, but it's not required

Asir - what does wsdl workng group have to do to support this?

Umit - the one-way MEP must be defined by someone (question is, who defines it. It could be wsdl as one likely place). S

Marsh - I'm not familar w/soap resp mep (do http MEP, and get SOAPEnv) - sounds like out only.

Marsh - WSA fits in, not you can send an EPR to tell it how to deal w/an out-in.

Marsh - the out-only doesn't seem to correspond to the new thing

Glen - in the out-only, in some out of band means, you should come to me and get information.

Glen - if you want to use this for in-only case, you need to tell the service to tell the service to get the in-message for me

Marsh - if we define one-way mep, we can binding that to in-only or out-only MEP

Marsh - these all sound relevant to Michael's use case 7 (where you poll)

Glen - we still need some way in the wsdl to indicate this is going on

Anish - the SOAP MEP tells you how to utilize the information so out message utilizes the in-message

<anish> what i meant was that by structuring the MEPs, you won't need out-of-band information, the info will be available in the binding

David - aren't one-way messages supposed to be fire and forget?

Marsh - fundemental building blocks req/resp, abstract out-in, in-out, etc... and you can have mappings for this

David - if we have a one-way, wsdl or soap, and bound to HTTP, we have the atomic operations to solve any message exchange pattern.

Glen - it may not be possible to use that MEP backwards, ie., if I can't initiate HTTP request back to me, I can't use that

Umit - I thought we established 2 necessarily requirements 1) one-way input MEP, 2) http binding

Paco - I think we shold also be looking at whether wsdl 1.1 soap 1.1 we know how to deal w/these use cases... in particular, w/this one, the answer is yes

Glen - use case 2 (simple req/resp)...

Glen - 2 is a correlated sync req/resp over same connection. whatever binding is hsa capabilties to do req/resp. That's how the correlation get's implemented. The current specs allow this (WSDL 1.1 and 2.0), and the simple HTTP get stockquote in wsdl 2.0 (and 1.1) can be done. Seems like no changes necessary (as long you understand protocol binding is what provides protocol MEP upwards).

Roberto - use case 3 (async req/resp w/2 different connections)..

Roberto - took an example of kevin's writeup (submit expense request). resp message can be of 2 different types. if longer response, it comes on different connection

Roberto - overlap w/use cases. in particular, looked at 2 different ways to formulate:

1) what's doable, actually separate interactions into 2 halves, and describe w/2 separate one-way operations in 2 interfaces

messages exchanged on the wire are exactly the same. I interpreted this being req/resp in the wide way (didn't interpret in wsdl in-out MEP)

Glen - the idea was work w/the wire and work upwards (which is what you did)

Roberto - right... 2 spearate operations, essential piece missing is annotate that logical response is linked to the request. I prefer using teh WS-MD as a way to do this correlation

Roberto - someone pointed out this overlaps w/5 (not sure it's true).

Anish - the reason I pointed out was the use cases listed, were very much from a WSDL pt of view

Anish - I thought you would use something liek ws-addressing to figure out where the response needs to be sent

The first way get's the job done

2) w/single operation in one interface, you run into the bidning problems in kevin's email

Glen - some people like the grouping of the WDSL mep, to act same ways as coding artifiacts (as opposed to do everything underneath)

Anish - I thought the idea was to push back on modifying WSDL a whole lot (and see how much change there is, to do it in a single operation)

Roberto - I thought option 4 in kevin's writeup was covering the changes in wsdl.

<umit> Kevin's use case is more complex however

Kevin - you've demonstrated the complexity to achieve the asychrony at the binding level

Roberto - in the 1st formulation there is some way to express the relationship (one acting as req/ one as response). This would be a alteration of scenario 5

if you didn't want to change the way bindings work, you can select the number of combinations fo binding that are important (e.g., SOAP/HTTP and SOAP/SMTP - and define a brand new bindign). This can be a huge number of bindings...

Glen - I want to push on the why is it so hard to define the default bidning is SOAP/HTTP and if you see pieces, it may be bound differently

Kevin - if you do that, how does it impact at the service level?

Anish - you are saying you aren't constraning what a client can put in the reply to

Roberto - it's not very toolable

<asir> thanks Kevin for raising that question

Glen - you could put in a list of supported protocols, it would be a hint.

Umit - would this require endpoint to support multiple protocols?

Glen - only if guy writing WSDL would decide they would want to

<alewis> why can't the client simply use one of the "hinted" protocols?

Roberto - the problem w/this approach, is it's completely open ended, and doesn't know what the service supports, nor what the clients would want to use. There is alot of out-of -band info that has to be agreed upon

Glen - it seems that there is a closed set of things which can be used.

Anish - a more practical use case, you can say in WSDL that you can define a binding req is over HTTP and response is over these 5 protocols, and the replyTo will tell you what is chosen (as opposed to be completely open ended)

David - what happens if I put a bad address in the replyTo?

David - this is starting to get into some of the issues that's in use case 6

David - you may want to send something up the pipe, in case some one is listening...

<umit> +1 to Paco

Paco - I think that there is SOAP/http in and soap/http out w/2 different cnnections. To figure out that binding that does that w/the http binding, is something that we have to do, before we get into the whole aray of protocol answer. I want to separate the complexity of the 2 problems

Paco - as I understand the WSDL 2.0, you can still rpovide details for output message for request/response (and change at binding level). However, for wsdl 1.1, it didn't seem that difficult. It's more immediate than the array of response protocols... We will advance in interop if we do this one

Glen - assuming you want the req/resp in different connections.

<Zakim> mnot, you wanted to add information about where SOAP bindings, MEPs work might be done

Mark - don't know if widely known, but david fallside resigned from chair, and Michael from Nokia is the chair. I mentioned that it looks like might need to be new soap bindings, and michael said although XMLP isn't meeting, he will float that around and see if XMLP wants to take it up.

Mark - also... wanted to ask Glen to put together agenda for WSA and does task force want slot carved out

Glen - yes

Mark - need to decide whether you want 2 slots (WSDL and WSA) since they aren't joint.

Glen - the WSA could be summary, the WSDL one may be more significant

Umit - I had a question to Paco, can you clarify why WSDL 1.1 the req/resp isn't an issue?

Paco - I think it's doable (clearly within reach w/o new machinery). I haven't loooked deeply at 2.0, but from WSDL perspecitive, we probably ahve enough machinery to identify details of HTTP binding, and wouldn't be that hard to deal with it (if we limit support of different protocols)

Paco - WSDL 1.1 is not as formal as WSDL 2.0 (no soap MEPs)

Mark - looking at this discussion, it must be decided what is the minimal requirement to ship WSA, and what isn't required...

Glen - The core quesiton, do we want to req/resp to bind to same (or 2 different protocols). I would like to present to the groups something to vote on

<gdaniels> I have made the request to generate http://www.w3.org/2005/02/16-ws-async-minutes gdaniels

This is scribe.perl Revision: 1.111  of Date: 2005/02/12 19:57:54  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Arthur/Asir/
Succeeded: s/tactical/practical/
No ScribeNick specified.  Guessing ScribeNick: GregT
Inferring Scribes: GregT

WARNING: No "Topic:" lines found.

Default Present: MSEder, anish, ALewis, TonyR, GregT, Marc, GlenD, Jonathan_Marsh, [IBM], [Sun], Roberto, dhull, Hugo, +1.650.320.aaaa, [webMethods], asir, MarkN
Present: MSEder anish ALewis TonyR GregT Marc GlenD Jonathan_Marsh [IBM] [Sun] Roberto dhull Hugo +1.650.320.aaaa [webMethods] asir MarkN

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)