Administrivia

no changes to agenda

Minutes approved as distributed

Bob: will review CR33 handling in previous minutes

review action items

all action items completed

proposed and new issues

Bob: Metadata issue
... Who will provide policy input?

Paco: is this something we will provide in general framework, or will it be an open-ended job?

Bob: Hope it is not open-ended.

plh: This could fit in the WSDL binding document.

Anish: Hope not in WSDL binding, it is really separate.
... It is about defining attachment points for policy data.

Bob: plh: in policy WG, are they producing a policy assertion related to this?

plh: no

Paco: Not sure where is the right place to do it. Probably a separate document. It is an expansion of our charter.

Bob: Does the WG want to expand the charter?

plh: A "note" would have no normative status.

Tom Rutt: Do we say in the WSDL binding doc, do we say what qname to use?

<anish> tom, in wsdl binding doc we have this -- http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/#metadatinepr

<David_Illsley> Tom, from the spec: To do so, the creator of an EPR MAY include a WSDL 2.0 description element (or a WSDL 1.1 definitions element) in the metadata property of the EPR.

MrGoodner: Are we clear on what the policy WG is asking?

Bob: Would the WG like to work in conjunction with the Policy WG on this?

PaulD: Don't fully understand the use case, the requirements, the work needed.

Anish: Independent of how it is done, or what WG, it is a useful thing to have.

<pauld> guess I'm unconvinced on the utility of attaching WSDL to an EPR either

Anish: There was no policy WG when we started. It is useful to have the connection to policy. It will be needed for many future use cases.

Bob: Last time we discussed this, we decided it was the job of the Policy WG.
... If we are not willing to work with them, that is a decision we can make. Then it will be left to some future activity to resolve it.

Tom: We did it for WSDL, are there other aspects to be addessed other than EPR?

Paco: This may be more complex than we think. It opens a lot of related problems. It is not something to take on casually. Do we need to amend the charter?

plh: agree with Paco. It is different from thw WSDL case, where we were the ones to control it. This is initiated by the Policy WG, and I don't think it is the role of this WG to do it.

Marc Hadley: Would be surprised if we had to do more than say, "You can put a policy element here."

<Zakim> anish, you wanted to say 'why doesn't ws-policy do this and change their charter if need be? they specify wsdl attachment points too.'

<bob> +1, anish

<w3circ> +1 anish

Anish: Think the Policy WG should do this. WS-Addressing Core is done; Policy is not done. We would have to keep tracking their work.

MrG: The task is not well defined.
... Need to define the expected outcome.

<plh> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3620

plh: The Policy WG said "We will not do it now." Are we not stepping on their toes?

Bob: They asked for some participation from this WG.
... The chair described the scope as requiring a couple of people to participate in a couple of joint calls.

plh: no problem to having a joint call

Bob: any objection? None heard.

<TomRutt> yes to call

Bob: Who will participate? Paco, Gil, Tom Rutt
... Others? Three is probably enough. I will try to set up a time, via email.
... Can we run through the CR 31 work by Tony?

CR31

Tony: changed cells related to wsa: prohibited

Bob: So we need to also finish CR33?

Tony: yes.

CR33

<anish> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0106.html

Anish: Will go through email. Link is pasted in chat.
... Describing option 1 and option 2.

Marc: Define older client in this framework.

<marc> Old == CR

Anish: The namespace becomes interesting in option 2
... In option 2, we keep UsingAddressing, add two more extensions.
... Describing scenarios with older and newer clients.

Anish: The other issue with namespaces - we will need a new schema in option 2.

<bob> ack [IPc

<Zakim> [IPcaller], you wanted to ask whether compatibility concern is related to question of progression directly to PR or via second LC

Marc Hadley: Why are we focusing on this?

Anish: MrG raised the question.

Bob: Between these two options, it appears that people may have a preference?

Anish: Subtracting from the schema requires a namespace rev, but not necessarily adding to an extension point. We would be removing wsaw:Anonymous.

plh: We still own the namespace; we can still change the schema. However, we need to be careful.

MrG: If we are making substantive changes, a new namespace would be appropriate. If we take away a marker, we should have a new namespace.

<bob> ack [IPc

<Zakim> [IPcaller], you wanted to ask about expressivity vs existing Anonymous element

Some implementatoins are using these elements.

<MrGoodner> +1 Marc

marc: Not sure what we are trying to achieve.

Paco: Untying the semantics from the anonymous URI.

<David_Illsley> PaulKnight, my comment was that wsaw:Action and wsaw:UsingAddressing are widely implemented - only 1 known implementation of wsaw:Anonymous

<marc> my comment was that the proposed markup is no more expressive than the current markup - wondering what was wrong with the current marker

<marc> paco noted that policy recommends differentiation by qname so our use of attributes in the Anon element goes against that

Bob: Now we have an explanation and two options. Are we prepared to decide?

Dhull: Have we ruled out the purely syntactic approach?
... My email described this point.

Bob: I had not captured it as a proposal for this issue.

Paco: We discussed it briefly on the last call.

<pauld> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0096.html

Bob: A sysntactic approach which may or may not have a regexp defining what the backchannel may be.

Anish: Would this go inside a policy or WSDL extension, or is it independent of the notion of backchannel? Looking at the qname, would you understand it?

Dhull: You would have to look at what patterns were allowed or not. It tells the client what form of address could be used in the ReplyTo EPR.

anish: what if I don't want to change the WSDL, but for instance enable Reliability, because I want to tweak the policy and not the WSDL?

Dhull: It boils down to whether you want to find what is supported - directly or not.

MrG: The real problem is the way the RM anon URI might be used without RM. There would be no policy assertions in the WSDL. Not sure this is an improvement.
... the OASIS WS-RX TC is also looking at related issues.

Gpilz: Some expressivity would be lost.

Bob: We were focusing on Anish and Paco's proposal, then discussed David Hull's proposal. We need to focus on selecting the best approach.
... Does the group favor David's approach, or anish and Paco's?

Paco: I would be worried about implementing mechanisms without having a clear use case for it. So far, having a simple marker for backchannel or not is sufficient.

Anish: Third possibility: wsaw:Address constraint as suggested by David Hull could be a child element of the response. It can solve some problems.

Anish: It is interesting to consider a hybrid approach.

Dhull: Agree.
... I don't think it is a complex new feature. The term backchannel is an undefined term itself, and it may also be complex for composability.

<Dug> marc - that's not a WSA issue - that's an RM issue

MrG: Using a backchannel marker without a mention of the URIs may not be helpful. It may not be appropriate to cover it here rather than RM.

Paco: Can we separate the issues of CR33 based on our proposal from the possibility of using David's mechanism?

<pauld> or close with no action

<MrGoodner> +1 pauld

<dhull> But Paul --- we've talked about it this long ... surely we must take *some* action ...

<dhull> :-)

<MrGoodner> update wsaw:Anon as not being useful as a policy assertion?

Bob: Options : option 1 - composability with policy - define text element

Paco: That is not really a separable issue.

Bob: No matter which we use, we need to deal with composability with policy.

<dhull> Ironically, my biggest problem with the marker proposal is composability

Bob: can we choose between option 1 and option 2 in the proposal by Paco and Anish?
... any objection to limiting the choice of solutions for CR 33 to those two options?

MrG: It does not solve composability issue.
... Once you have the backchannel marker, you have no idea what will be on the wire.

Dhull: Not clear which will compose best.

Paco: What is non-composability argument against using the marker?

<anish> isn't this similar to what we have done with 'anon' uri?

<anish> 'anon' uri does not mean anything outside the context of a particular binding

Extended discussion of meaning and use of backchannel.

<dhull> nutshell: Where is it defined and how?

Bob: We are replowing some old ground here.

Dhull: A fresh answer to anonymous may be sprouting from the old ground.
... Backchannel is not defined well.

Tom Rutt: Semantics still not well defined. It is up to the endpoint to know how to handle the URI.

Paco: Dhull's proposal provides more information than is needed.

Dhull: It is needed, because backchannel is not clearly defined.

Paco: In case of http, backchannel is known.

Bob: Backchannel as a term appears to be undefined and unused.

MrG: There is no marker for this. You don't know that RM is in use in every case. There is an interoperability issue.

Bob: Want to keep discussion focused on CR33 options in front of us.
... Choose one of the options, or close with no action. We can't directly work on RM.

Dug: CR33 is just about whether other URIs can be defined. WSA does not have to define how they are used, just whether to allow the extensibility point.

MrG: If the extensibility point is defined without clear rules, it will not be composable.

Dug: It is not WSA's problem to address.

<Dug> only one URI can be in wsa:ReplyTo at a time - the spec that defines that URI defines what goes on the wire - its not a WSA issue.

Anish: How about the hybrid approach? David Hull proposed address constraints, which could be used with the proposals by Paco and myself. It would have a child element describing address constraints.

MrG: How the constraints are expressed is the issue.

Anish: The constraints are constraints, not another policy assertion.

Bob: One approach is to define anonymous as the base URI and the constraint as a facet to define how it is extended.

David Hull: fell off line

Bob: We need to make a decision.
... Can we reach a decision tonight?
... Can we take the approach Paco and Anish have suggested?
... To solve CR33, the approach defined in Anish and Pacos' proposal ,either option 1 or 2, is acceptable? Any objections?

Dhull: Object
... Don't see how it will work.

Bob: extend meeting for 5 minutes? No objection.

Tom: will support one or other of those.

<Dug> using anon URI doesn't solve cr33

Marc Hadley: could support either , if anonymous URI is used in place of backchannel.

<bob> s/cold/could

Bob: Will need to continue discussion next week.
... We have not used backchannel as a term anywhere in our specification.

<marc> e.g. wsaw:WASResponseUsingAnonymousOnly

Bob: discuss on mailing list

<Dug> MarcH - could you send a proposal to the list? so people can noodle it?