See also: IRC log
Added new issues for discussion.
Umit: I would like to resolve cr 13 on faults
No objection to approval of Minutes <http://www.w3.org/2002/ws/addr/5/12/19-ws-addr- minutes.html>
2005-11-28: i059 - keep open
2005-12-05: i066 - action completed
2005-12-12: i067 - action completed
BEA will not provide lunches and bkfast in room.
Self arrange for bkfast, go out as group for lunch
Dinner: BEA could host on Wed evening, vs Thursday.
<PaulKnight> run a ballot for dinner?
Dave O prefers Wed Evening.
<Nilo> same here
Tue and Thur Evening could be informal groups
Mark N will conduct a poll on options.
Suggested 8:30 PM Wed Evening in the poll
Mark N: plan short lunch on thursday, friday can be a better lunch.
Possible order in "thai" type food
Weather: rainy, not snowy
<anish> one reason to use the marker in endpoint is that in WSDL 2.0, the binding is reusable
Katy Proposes to remove tags wsaw:anonymous, and wsaw:Using addressing at endpoint level
Glen D: so the problem is conflicts between endpoint and binding
Katy: this provides a way to clean up the spec,
Umit: I agree to have them on the binding
<gdaniels> It buys us reusable bindings
<gdaniels> so you don't have to build one for "addressing on" and another for "addressing off" in order to support different capabilities on different endpoints
<Zakim> dorchard, you wanted to ask whether use case examination will actually take less time than fixing the minor problems in the spec.
Resolution: agreed to add new issue based on Katy's email
Katy: there are times when the address needs to be overridden, which violates 4.1 text
<uyalcina> +1 to the issue
Anish: If you are not using
address are you still using that port?
... if you need run time info you would use epr not port in wsdl
... if wsdl port has static address, that is its definition
Katy: Jax rpc has call interfaced to override address, I thought of this as same port, If not so we should clarify the spec.
Anish: I do not object to adding issue, however resolution might be clarification text.
Jonathan: we should also continue to look at Katy's original proposal.
Resolution: add Katy second New issue from her email, Katy owner
Umit: there will be new CR issues for next week.
Mark N: my hope is to resolve all CR issues next week.
Suggest wg meeting to 6 or 6:30 on thursday
Discussion of Dave O action item
Mark N: how do these issue resolutions get reflected in our wsdl binding document?
<uyalcina> I fail to see what the difference is between what is part of our original proposal and in this proposal with respect to SOAP 1.1/HTTP. Just wording differences>?
Dave O: if it done in a separate "soap binding " doc the wsdl could use reference to that binding
<uyalcina> It seems to me that this is not the content problem, but which document the defn is included.
Mark N: if the impact is low, and we can agree to push the binding work elsewhere, with an editors' not in the last call to allow updated of reference, we might be done.
Dave O: the reference could specify a minimum requirement on the binding, a bar which hits what we are doing in our test cases.
Mark N: that is why the reference can be left open for change after last call.
Paco: do we know who will take this over for both soap 1.1 and 1.2?
Mark N: we have to make that happen before we clan close the issue.
mnot: for soap 1.2 xmlp could do it, for soap 1.1 a separate w3c Note could be cited.
Dave O: our WG could do if for Soap 1.1, xmlp could do it for soap 1.2
Umit: why not put the soap 1.1
stuff in this wsdl binding now, rather than refer to another
... I thought we already agreed on the soap 1.1 solution.
... I do not see the big advantage to this separate document for soap 1.1
Mark N: some people see a separate document as more easy to reference elsewhare
<Zakim> dorchard, you wanted to answer umit
Dave O: xmlp is working on this for soap 1.2, this has been on the table for quite some time that they will have a separate doc for soap 1.2 oneway.
Dave O: haveing a separate document for a binding is a separate thing than a wsdl extension. Some believe a separate document for a binding for Soap binding is best.
Umit: my concern is a w3c does not have the same importance as a rec doc.
Dave O: I would like to see this as a w3c Rec.
Mark N: our charter deliverables do not include a soap binding document.
Mark N: we could publish a note, but we are not chartered to do a soap oneway binding for soap 1.1
Dave O: I think our charter could allow two documents rather than one.
<Zakim> dhull, you wanted to advocate dodging the whole issue
<dorchard> So, for the record, I agree with Umit's concern about the binding being in a Note rather than a Rec track document. If separate doc is Note, then I'd rather have 1) keep in SOAP binding and go back to CR or 2) keep in WSDL doc.
D Hull: define anonymous using behaviour rather than a specific address. We can leave out details
Gil: the last place I would look to see how to do asynch in soap 1.1 is in a wsdl binding document for ws addressing. It has broader usage than within our group
Paco: wrt soap 1.2, we agree to
let another group do it. since we are group to likely solve
soap 1.1 problem, I hesitate to wait for another
... perhaps do not go to LC until we have soap 1.1 solution
<Zakim> dorchard, you wanted to mention that if w3c is against Rec tracking anything soap 1.1, then they ought to be objecting to it being in ws-a wsdl extension and they haven't done so.
Tony R: If Soap 1.1 is expected to go away, having the binding in a separate doc would have advantages.
Dave O: I believe soap 1.1 will be used as the primary vehicle for a while.
Philipe: Soap 1.1 is w3c note, not recommendation. A w3c rec should not rely on a w3c note.
Phiipe: if the recommendation would have to rely on a w3c note we would be against thate
Philippe: if the text lives by itself it is not optional. Optional text in a rec is a different case
Dave O: I do not get the importance of something being optional, vs. whether the optional part is by value or by reference?
<Gil> your point would be?
Mark N: it is more acceptable to have the soap 1.1 binding stuff as an optional part of our spec.
<plh> A W3C Recommendation for the Web Services Addressing SOAP 1.1 and SOAP 1.2 Binding specification, mapping Web Services Addressing message properties to SOAP 1. 1 and SOAP 1.2 headers.
Philippe: Need to be concerned about requiring charter change for new deliverable.
<dorchard> BEA would like to see the document that specifies the soap 1.1 one-way http binding go through CR and Rec.
<dorchard> +1 to umit
<plh> "The use of these abstract message properties in the context of all WSDL 1.1 or WSDL 2.0 Message Exchange Patterns, including the asynchronous use of these MEPs."
Umit: I do not see how this would require a new charter if we do it within the soap binding document?
Dave O: we have been talking about this in the wsdl document for a long time, so why would it be outside our charter.
Mark N "including the asynchonous use of the meps" is in the charter wording
<uyalcina> +1 to DO
Anish: I do not see problem with
soap 1.1 binding as note, with reference in our rec doc.
... it removes concern about putting in wsdl doc, and als the concern to not put soap doc back to LC.
<dorchard> Hmm.. So what's the difference between 1) Rec track document contains one-way binding (wsdl doc) 2) Rec track dcoument references Note?
Jonathan: I do not want to take soap binding to lc. Schedule is important. I do not see problem with a note, referenced in wsdl doc.
<Zakim> dhull, you wanted to comment on handling async
<dorchard> So it seems that there is a trade-off between Rec track but arguably inappropriate document factoring vs appropriate document factoring and Note status.
D Hull: in some respects the ReplyTo satisfies the requirement in the charter. Having soap 1.1 binding is not charter item, but is a good thing.
Phillipe: WG can publish notes. However the WG should get their spec out sooner rather than later
Umit: one or two paragraphs would be the contents of the note (from either My proposal of Dave O proposal). Notes take time to progress on their own.
<Zakim> dorchard, you wanted to point out that we are talking about 2 sentences..
Anish: the Wsdl binding and Note can go to LC at the same time.
Dave O: one or two sentences might suffice. I do not see it as being a reason to delay progression of the spec.
Dave O: we have to agree on what the sentences are, independent of which document they go in.
<dorchard> maybe straw poll time?
<dorchard> 1) wsdl doc by value; 2) wsdl doc then refer to Note; 3) soap binding doc; 4) wsdl doc then refer to Rec
Mark N: two choices: 1) separate doc with ref in wsdl doc, or 2) agree soon and put in wsdl doc
Tony R: I prefer separated
Paco: I would rather leave in the
... restricting it to wsdl doc places it stronger within our charter.
Dave O: there is another option to put it in the soap binding document.
Jonathan: I am against such a delay on soap binding rec.
Mark N: if someone could draft proposed referencing text we could look at it.
<mnot> ACTION: DaveO to propose referencing text for i067 and i068, and give summary of SOAP 1.1 HTTP binding [recorded in http://www.w3.org/2006/01/09-ws-addr-minutes.html#action01]
Dave O: I volunteered to do those action items, some of the referencing text has already be proposed.
Mark N: discuss on email list, looking at Dave O proposals on referenceing. Dave O will summarize how the soap 1.1 one way binding would look like. At f2f We will have three options before group
1) soap 1.1 in wsdl doc
2)soap 1.1 in soap biding doc (back to lc)
3) make soap 1.1 asynch in separate note
Jonathan: proposes to make
discussion of global element more generic, to allow its use
elsewhere. He provided example
... i give two proposals, the second is more specific to policy framework, that is why I prefer it.
Umit: this proposal is based on the older version of wsdl binding document. Some paragraphs have been changed
Anish: Saying that anyone using this element has the same meaning as how we use it in this spec seems wrong. The using spec can tighten semantics.
Jonathan: section 3.2 already uses term "semantic equivalence"
Anish: we are not just talking about ws-policy, we are restricting any framework using ws-addressing.
<bob> hi, i need to be completely retrained
Anish: I think the other specs should have freedom on how they use an element in a policy framework in a wsdl document.
Anish: I am saying we should not do this.
Jonathan: I want to be able compose the spec on on using addressing element and a spec on policy framework.
Anish: this is going beyond the bounds of the wsdl binding document.
Dave O: while outside charter, it is such a small tweek that I am in favor.
Paco: I am in favor of this. Using this element in another framework is not supported by the ws-addressing spec.
Phillipe: I like the idea of opening the text to allow the element to be used elsewhere .
Umit: I speak in Favor of It, especially the second one.
Tom R: I could live with neither proposal, but prefer the more general proposal 1.
Jonathan: the fist one seems less direct, and sneakear.
Tom R: I could live more with change 1.
Mark N: we can have a Chad on this at next week f2f, with a short discussion. Please send any email before meeting.
Jonathan: cr 10 has a proposal 6 which seems to be agreeable.
CR 13, familiarize yourself with proposal from Umit.
<uyalcina> CR13 does NOT require us to go back to LC as there is already a note in the spec indicating that we can add more faults if needed
CR14 - the proposal from D Hull has three options.
s/I prefer nochange, but /I/
mnot: People should look at these CR issues as well as Katy's new issues.