See also: IRC log
<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[End of scribe.perl diagnostic output]