<Marsh> Scribe: Marsh

<scribe> Scribe: MSEder

Marc: discussing problems with mailing list

<TonyR> Excuse me - what is the conference code on phone?

ASYNC

scribe: working process and lifetime of task force

marc: task force not a body with deliverables
... minutes for every meeting, no need for attendance , no standing, 4 one hour calls to get work done
... Mark is chairing but looking for volunteers

Mark: scope and deliverables
... what do people think were here for

<mnot> http://www.w3.org/2002/ws/addr/5/01/19-ws-addr-minutes.html#item03

Jonathan: has not looked at minutes. thinks the scope is problem in layering between WSDL MEPs and binding to underlying soap protocol
... come up with higher-leve MEPs for async

Hugo: can we do reply to with the tools we have now if not what are we missing

Mark: relevant part is to compare all the different scenarios and decide what is important
... create a decision tree and decide how to move forward
... look at requirements and decide what scenarios need to be addressed
... secondary consideration if we need to do new stuff where should it be done

Hugo: important thing is to understand the problem or what is missing, do not need to figure out who can fix it

marc: recommendation to WSDL group to have a closer association between their MEPs and soap MEPs

jonathan: are you suggesting that the MEPs are the same

marc: missing is any kind of one-way MEP

ugo: need to understand how matching can be done. one MEP will not materialize

mark: do we have time to discuss use cases or come up with them

umit: David's proposals are a good starting point

<TonyR> Did Ugo suggest that there might be multiple SOAP MEPs to one higher MEP?

umit: we should not hinder what can be done

GregT David concentrates on soap 1.2, but there's a lot of 1.1 out there

marc: different protocols for request response messages, not sure if that is in scope for WSDL

GregT on the wire what we want, we need a way to render that

<GregT_> yes

umit: WSDL does not provide the granularity to support these kinds of messages

marc: does not want to turn this into a boil the ocean discussion for WSDL

jonathan: do we have the building blocks we needed the right level
... what are the ways I can do that today. what is awkward and what can we improve

umit: a hole in WSDL about one-way MEP's and in SOAP
... no way in WSDL to map this to soap

jonathan: Look at HTTP bindings. Do not have an in only
... one underlying thing request response
... not clear there is a hole beyond describing the situation

greg: need to provide some guidance

jonathan: sounds like this is more an editorial problem

umit: we don't really say what we do with a response
... one concern in much worse situation than what is described in WS-I basic profile
... WSDL needs much more comprehensive design. Need one SOAP MEP
... Can we take what David has done and incorporat it

jonathan: collapse layer between SOAP MEP and WSDL MEP. Different SOAP MEP for in only. Have any lot of MEP's at the WSDL level
... WSDL says clearly which MEP's, but need to have clear statements about the SOAP bindings in WSDL

marc: problems in current SOAP HTTP binding
... out in does not map to the SOAP request response MEP

hugo: discussed in trying to have HTTP binding in WSDL support out in

Asir: David's one-way SOAP MEP adds new transport
... as it stands today in WSDL at the binding level you can specify only one transport

marc: Mark touched on this problem earlier. do not need to support this natively in a single interaction with WSDL

mark: at some point with MEP is you need something like BEPL. subjective decision

jonathan: where does that leave us with use cases?

umit: input only use case is something we need to support in a better way

jonathan: what is the list of MEPs we need to support

umit: in only is a very common use case that has been adopted in the 1.1 world

jonathan: need to trace through the options we have for in only today

greg: need to go down to the transport level also
... if people want to have separate connections need to to figure how to render that

mark: thinks of these as separate problems
... you compose the 2 one ways

<kliu> I see three important use cases we need to support:

<kliu> 1. binding for in-only meps

paco: we are seeing a lot of holes in different specs

<kliu> 2. asyncronous binding for in-outt meps

<kliu> 3. mechanism for indicating different protocols for in and out messages

paco: do we want to identify the holes and send to the appropriate working group or do we want to try and fill the holes
... the basic we will need to do is identified the holes

mark: we have 15 minutes left
... identify which use cases are important. a few ways to do this
... spend the next week trying to figure out the use cases and identify the holes

jonathan: take the three that Kevin outlined in IRC and see what the issues are

mark: agrees likes those three issues
... issues listed in IRC

<TonyR> Do we have to consider out-only MEP?

jonathan: thinks these issues are enough and the others will thin out pretty quickly

mark: not a great dependency on the addressing working group

jonathan: I agree, some holes in WSDL

mark: take action to talk to David

marc: Also agrees non- issue for addressing

mark: The are WSDL issues primarily
... still looking for a chair
... let's have a discussion on the list about those three use cases
... identify where the holes are

<scribe> ACTION: Poco and greg to look at those three action items

mark: there is a public mailing list for this task force

<hugo> public-ws-async-tf@w3.org

mark: 4 more meetings of an hour each. goal is to present something at the technical plenary
... need to find someone to make presentation. people should keep that in mind for the presentation can be made easily

greg: try to get something on the list by the end of the week

umit: what is the action item

mark: Paco and greg look at those three use cases

<mnot> ACTION 1 = Paco and Greg to develop three scenarios (1: in-only 2: async in-out 3: in-out w/ different transports), with concrete examples of messages, etc.

This is scribe.perl Revision: 1.109  of Date: 2005/01/21 04:36:25  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Marc/Mark/
Succeeded: s/ugo/umit/
Succeeded: s/jonathan:/GregT/
Succeeded: s/jonathan:/GregT/
Succeeded: s/who:/Asir:/
Succeeded: s/in out/in only/
Succeeded: s/are/as/
Succeeded: s/Great/Greg/
Found Scribe: Marsh
Inferring ScribeNick: Marsh
Found Scribe: MSEder
Inferring ScribeNick: MSEder
Scribes: Marsh, MSEder
ScribeNicks: Marsh, MSEder

WARNING: No "Topic:" lines found.

Default Present: MarkN, MSEder, Hugo, Marsh, Ugo_Corda, Marc, [Sun], [webMethods], Roberto, asir, Umit_Yalcinalp, TonyR, GregT, +1.914.674.aaaa, Paco
Present: MarkN MSEder Hugo Marsh Ugo_Corda Marc [Sun] [webMethods] Roberto asir Umit_Yalcinalp TonyR GregT +1.914.674.aaaa Paco
Got date from IRC log name: 26 Jan 2005
People with action items: greg poco

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