Web Services Addressing WG Teleconference

<bob> scribe: David Illsley

Bob: Adding item to agenda
... discussion of schedule of coming calls

Agenda accepted

Resolution Minutes of Nov 6th Accepted

Schedule of Upcoming Calls - Recognised holidays coming up

Proposal: No calls on Dec25th and Jan 1st

Bob: How do folks feel about meeting on Nov 20th?
... 3 reservations, no objections to cancellations
... 11/20, 12/25, 1,1 Cancelled

One objection to Nov 27th so having call

Bob: Marc and Gill have completed their action item

<bob> proposed new iisue http://lists.w3.org/Archives/Public/public-ws-addressing/2006Nov/0027.html

Bob: 1 proposed new issue - http://lists.w3.org/Archives/Public/public-ws-addressing/2006Nov/0027.html

Discussion of whether this is an issue

<scribe> ACTION: Paul Knight to review document and issue to advise on response [recorded in http://www.w3.org/2006/11/13-ws-addr-minutes.html#action01]

Proposal 7 for cr33 http://lists.w3.org/Archives/Public/public-ws-addressing/2006Nov/0026.html

Gil: Straightforward - represent everything as a positive asserton in a ws-policy friendly manner

3 assertions - AddressingRequired to indicated addressing required - use wsp:Optional to make it optional

Gil: AnonymousReplies indicates repies can be sent to anonymous, NonAnonymousReplies to non-anonymous uris
... Lets not get hung up on exact names yet

Katy: 3 policy assertions - are they mututally exclusive or would you expect AnonymousReplies and NonAnonymousReplies to only be there is AddressingRequired is there

Gil: expect AnonymousReplies doesn't make much sense without AddressingRequired

Tony: Think you can support AnonymousReplies without AddressingRequired but not NonAnonymousReplies

Katy; So AddressingRequired mandates addressing and the AnonymousReplies extends that so I think it should be nested to avoid illegal combinations

Gil: Would tend to agree but can't speak for Marc

Katy: WS-Foo assertion would have to be nested as well otherwise the WS-Foo assertion wouldn't mean anything without AddressingRequired

Gil: Seems combining policy assertion is going to have these problems

MarcG: Generally not a problem to leave an assertion which allows nesting open to nesting by other specifications
... I have lost how this proposal is related to the WSDL Binding Doc and the further we get into discussions about nested policy how we can reflect that back into the WSDL Binding doc

Bob: Was the groups intention that we have wsdl markers and policy assertions that map 1-1 - If things have changed we need to reflect that

Katy: a question which came up a while ago is whether people actually need the anonymous marker available in wsdl

MarcG: Happy if that's the decision of the group but where is it then documented

Gil: I'm not clear how MarcH assumed this would be reflected in the WSDL doc - assumed that as a flat set of elemented they could replace the existing ones in the wsdl doc
... If we have to go down the route of experimenting with nesting then maybe we have to look at doing this in policy alone
... Notes that people who speak up on havin the anonymous fnction in wsdl aren't on the call, specificall anish

<dhull> You need to be able to say "I support only anon" and "I don't support anon at all".

<dhull> somehow

Katy: We all agree that we need the anonymout semantics - but will anyone need to do this with wsdl - if everyone is moving to use ws-policy it doesn't make sense to move forward and jump through hoops to define wsdl specific elements

Bob: Another WG made many changes to a CR namespace and moved to PR because of agreement between implementors

MarcG: Using usingAddressing marker as an assertion
... don't think we can move forward without changing anonymous marker because anonymous element cannot be used in ws-polict

Bob: If we can round up all implementors and get them to agree then we can short circuit a lot of w3c process

MarcG: We need to get people together to discuss what's been implemented

Katy: We are using UsingAddressing in WSDL and not Anonymous and would look to use anonymous function in policy

MarcG Using UsingAddressing and have no current plans on using anonymous function

Bob: 2 people using UsingAddressing but not anonymous. So if we have a wsdl and policy assertion for UsingAddressing that would fit with implementations

Gil: The question is how do I feel with only having this inws-policy and no wsdl
... I'm fine with it and I think I misspoke when talking about anish
... I don't see the need to be able to do it 2 ways

TomR: Qnames which can be used as policy with the same semantics is how it worked. We're talking about separate rather than nested.
... we wanted to make them policy friendly and anishs proposal with separable asertions and I don't want to lose that

Bob: Gil, assuming the proposal put forward was accepted by the group would it be possible in wsdl

Gil: From my point of view these aren't really separable - the examples bear this out

TomR: For clarification you're proposing nesting

Gil: The proposal doesn't include nesting but the discussion suggests we're moving down that route

MarcG: I'm sceptical you can represent the nesting in wsdl
... See problems with matching between the UsingAddressing assertion and new assertions
... Proposal put forward today could be represented in wsdl
... getting aways from what I thought we were discussing

Katy: Usingaddressing and Addressingrequired not semantically equivalent - quite different markers, not interchangable qnames
... 2 questions: 1. whether we have to represent in both policy and wsdl. 2. is they have to be represented in the same way

Bob: Couldn't we re-write UsingAddressing to represent thr same as AddressingRequired

Katy: Don't think so because it would break existing implementation

TomR: Who is going to be responsible for coming up with ws-addresing assertions for policy

Bob: We're trying to come up with them now
... In a prior call we discussed an people believe that it was right that we generate the assertions
... The issue of working with policy was a different questions
... Looking at the policy assertions in the proposals do folks think that's workable?

Katy: I don't think it's workable unless the assertions are nested. I see MarcG said you could nest other assertions of a different namespace and I'm not sure about that?

MarcG: That would be up to the matching engine whether or not it matched and when processing an whether the assertions are recognised.

Bob: seems to me there is more expressability in terms of policy
... Is it possible to define the wsdl markers in a similar but less expressable way?

MarcG: Don't know, going back to what Paco said about UsingAddressing being a simple QName. I think expressing nested policy would require a schema exemplar

Gil: Questioning whether we really need to express this in WSDL - don't see anyone jumping up and down wanting it

Bob: looking at the charter we need

<bob> Do folks feel that we can get by with only the wsdl usingaddressing marker?

<dhull> is that "wsdl marker as syntactic sugar" model valid?

MarcG: Going forward you need the anonymous function in policy not wsdl?

Katy: yes

MarcG: so we need to canvas opinion of other implementors

Gil: I think there is a mapping between the current UsingAddressing element and the Addressingrequired is not 1-1
... The UsingAddressing flag maps into 2 separate alternatives
... think we were too full of zeal thinking we could define a single set of markers that would work in wsdl and policy

Tony: Gils point that you can express Usingaddressing supported, not required gets rid of my concerns

Bob: Looks like we are going down the track of having different QNames between policy and wsdl
... looks like a resolution that we aren't constrained by the bonds of keeping the qnames in wsdl
... Can we keep UsingAddressing and drop the anonymous stuff and leave the rest to policy

Tony: If the client gets it wrong we can always send an error

Bob: Take a look at the UsingAddressing marker we have - are the semantic what we want to keep
... if so do we want to drop the remaining bits about anonymous/non-anoymous

MarcG: Suggesting dropping wsaw:Anonymous
... Happy with that or dropping the surrounding test suggesting anonymous can be used as an assertion
... Think we need to chek with anish abot how they are using it

Bob: Why don't we propose this to the list and threaten to take a vote on nov 27th

<dhull> 27 November == CR 33 day 118

Gil: To be clear: the actualy policy assertions we're toying with here would be in the wsdl binding doc or another?

Bob: I think the wsdl doc

Gil: I think the suggestion is a good one. The more overlap between what you can do in both policy and wsdl, the more confusion
... Have UsingAddressing as the large grain flag and if you want the more granular approach, be directed to ws-policy

dhull: If there is a need to keep wsaw:anonymous can we define it in terms of the policy assertions

some disussion about if we actually want it in wsdl

Bob: semantics of current UsingAddressing is different than the ws-policy proposal
... Whether wsaw:Anon survives?

TomR: Are we going to do the ws-policy in this wsdl binding doc before it goed to CR?

Bob: We'll talk about that

TomR: if they're concurrent then we'll know what the differences will be before publish

Katy: Looking at minutes 25th Sept - removal of wsaw:Anonymous was discussed and voted. People voted against then seemed to be more concerned about the semantics, not necessarilty the wsdl marker
... Discussed many times

Bob: came to similar conclusion about the minutes

<Katy> minutes here discussing removal of wsaw:anonymous from wsdl: http://www.w3.org/2002/ws/addr/6/09/25-ws-addr-minutes.html

MarcG: If we're talking about only ws-policy does it really live in this doc not a note?

Bob: can we focus on the functionality first

MarcG: Sure, would like to have consideration of what happens if you use new assertions and UsingAddressing as an assertion. think it would be ok but need to check

bob catches march up

Bob: Only question I hear people digging into is nesting

Marc: Our policy guru thought nesting made sense. Not sure about nesting assertions from other technologies into ours. e.g. if rx defined an assertions for the rm anon would it have to nest or could it be top-level? Don't like the idea of interspersing

MargC: SecurityPolicy already leaves some gaps through schema extensibility, then up to matching engine

Bob: Is prposal 7 acceptable to the group?

Katy: Difficult to say if we don't know if we have to match this up the the WSDL doc

Bob: I thought we decided matching QNames between WSDL and Policy is folly
... We then don't have to have them matched up
... We then discussed taking the UsingAddressing and new assertions together, leaving the fine grain control in policy
... Tony made point that if you don't accept anon and you get one you can fault
... Proposal could be: Keep usingAddressing marker and that's it within the wsdl marker and then we also define the policy solution in a way similar to Proposal 7
... I think we would need 2 agreements
... Hope we can get to a directional agreement: Do we think that this is the most promising direction we could take?

dhull: I think we can agree on the second part regardless of the first

Katy: would like to see proposal with nesting

Bob: seem to have conflicting requirements to move forward.

dhull: If we know what we can safely define one in terms of the other then we can know we're safe

Bob: and another way to solve it is to only have the functionality on one, not the other
... I think I heard a number of people who want to see the anonymous function in policy and don't care about wsdl
... if that's the case then we could move forward by removing the anonymous marker in wsdl

MarcG: Generally happy but want to check with anish

Bob: Gil, Marc, appears to have traction. The thing that seems to bother Katy is that nesting is missing

Katy: Yes

Bob: How can we deal with the issue of nesting

Both MarcH and Gil: It's doable

Bob: Could we recast the proposal to take into account Katys concerns
... Anyone have objections to dealing with the nesting issue

TomR: Might be some concerns about intersection algorithm - only works at top level - may find out there's reasons not to do it - worth a try

Bob: Could people on both groups keep an eye out for these issues

<scribe> ACTION: TomRutt to check with Ws-Policy groups on potential problems with nesting [recorded in http://www.w3.org/2006/11/13-ws-addr-minutes.html#action02]

MarcH: Should I make a change to the proposal with changes from Reply to Response and adding nesting

Bob: The conbination we're talking about is just UsingAddressing
... Moving on to making a Primer for addressing
... Arun had posted some stuff he had

Gil: Haven't had a chance to look at it yet

Bob: Aob?
... No further business