WS-Addressing WG Teleconference

approval of minutes

<scribe> chair: minutes accepted, no objections.

<scribe> chair: insert new item into agenda - sent to working group WS-Policy working group response to our lc133

lc133

<scribe> chair: can we agree that chair's efforts to form a reasonable response to last call commentary?

anish: accepted proposal g by accepting 2 more issues. Is what we expect from WS-P affected by this?

<scribe> chair: 2 new issues (from Anish). One of them scope of policy subject (specification or something else). These are issues that arose subsequent to adopting g. It may or may not affect them. Unknown at this time.

trutt: agrees that those issues came up after. Wants to send this to the WS-P group now and see what their response is.

anish: happy to do so. Wants to see if this response addresses WS-P concerns.

trutt: thinks we can accommodate any changes due to other issues later.

<scribe> chair: having a call with policy chairs weekly. WS-P doesn't see anything from WS-A that they can act on at this time. Hope that this response is something that they can act on.

<scribe> chair: any objections to submitting this draft?

trutt: maybe monica can comment, but policy group is already using alternative g in discussions. We should be asserting that this is what we want. We make definitive statements about the semantics of empty. At this point, until/unless ws-p comes up with something better this is the way we should go. But am happy to take something else from ws-p group.

RESOLUTION: to send response to WS-P as defined.

lc134

<bob> http://www.w3.org/2002/ws/addr/lc-issues/#lc134

anish: AI not completed from last time. Apologies.

<scribe> chair: defer to next time?

<scribe> chair: explains reading of lc134. Proposal might be close with no action. Would that sound right?

anish: does not dispute that that would make sense. However, we would still need to clarify in the spec that the assertion means compliant with both specifications.

<scribe> chair: OK. But will we have concrete text for next week? Want to get into 2nd last call next Monday.

anish: agrees.

lc135

anish: when we accepted g we said that if you had ws-a top level address assertion with no nested assertions it means no restrictions on the endpoint. this could be interpreted as meaning it supports anon and non-anon. Another interpretation could be that it supports ws-a and no other additional claim is made. there are well defined soap faults that can sent if either anon or non-anon is supported and you can try them and see what happens. Anish likes that
... because such a definition can be quite useful.
... thinks Tom (Rutt) takes us to proposal f.

trutt: no, going back to original supports stuff, where empty says nothing (e).
... empty means no responses are supported at all.

anish: anon and non-anon nested assertions cannot occur within the same ws-a top-level assertion. that would have to change if we remove this restriction. you may want to say that anon and non-anon are definitely supported.

trutt: biggest problem is interpretation won't work with intersection.

anish: wants clarification.

trutt: current definition supports intersection. it's designed to work with the ws-p algorithm.

katy: how could you positively support that you support anon and non-anon?
... thinks it has been covered by anish. Agrees that we should stay as we are.

anish: in that case, how do you create a policy that supports ws-a and ws-a soap binding? without saying anything about whatever else is not mandated by the spec.

<scribe> chair: you'd simply say addressing?

anish: if we just say addressing, it means that you support anon and non-anon.
... nowhere does it say that you have to support non-anon and anon. they aren't always applicable. this is forcing me to create a new assertion. understand that anon and non-anon are important for interaction patterns. But thinks issue gives that as well.

trutt: thinks that anish is arguing something else entirely. Didn't think new nested assertions were ever going to be added. make non-anon and anon first level assertions?

<monica> doesn't ws-a metdata element in the core spec indicate that metadata could be more than ws-am?

anish: not envisioning that new nested assertions will be allowed. Or making them top-level assertions.
... wants to say that only specific URIs are supported for responses and non-anon is too broad for that. Does not want to advertise non-anon in that case.

trutt: but that's already defined. non-anon doesn't mean you support any non-anon URI.

<TRutt__> Anish is actually asking for what is in the LC draft

anish: wants assertions to be composable. Not defining new ones.

monica: in the metadata element is optional. Is what anish wants a metadata element that is not scoped to what the metadata spec?

anish: not sure why metadata element is being brought up. Metadata in EPR?

monica: yes.

anish: thinks discussion is independent of this.

monica: not sure what the baseline assertion is. Confused by discussion (on both sides).

anish: policy assertion that is independent of the attachment mechanism. That's why the metadata element is irrelevant.

trutt: you want an assertion that is not nested within ws-a, correct? thinks what anish wants is already in the lc spec. but it doesn't work with the intersection algorithm.

anish: asks for clarification.

<dhull> so if I intersect "I support addressing" with "I support addressing; I support anon", I get "I support addressing", right?

trutt: believes that option f is the right one.

katy: agrees with Tom that this is going backwards. Need way of saying "I support everything". More important that "I'm not going to tell you what I support."

<scribe> chair: agrees

anish: wouldn't katy be supported by allowing inclusion of both nested assertions.

katy: yes, but why would we go back several weeks?

anish: doesn't understand rational for change several weeks ago. For the intersection algorithm?

trutt: we decided use case of no responses wasn't important. If you say that was wrong, we go back to f.
... f lets you do that (more verbose than g). Would be happy to go back to f.

ram: maybe what anish wants is a clear definition of what it means to say "I support WS-Addressing". Correct?

<scribe> chair: what specification would you support that is independent of anon and non-anon?

anish: wants to distinguish between definitions/what they mean and necessarily supporting them.

trutt: just re-asserts that f is what anish wants. g is not.

dhull: would rather see none put with non-anon. prohibited, required, don't care give 9 possible options. would like to see a table for f and g (h?) and see how they deal with them.

+1

<TRutt__> I do not understand a "don

<TRutt__> t care use case

ram: why are we trying to be selective on what it means to support ws-a?

<anish> +1

trutt: crucial that don't care can be supported by f and g (for client). but why should a server ever want to assert don't care?
... does not see a use case for a server saying I'm not going to tell you I do anon or non-anon.

<anish> +q

ram: let's agree on what "I support WS-A" means. then apply that to single tl assertion. then qualify that on anon/non-anon.

trutt: use case of server that doesn't support responses was deemed not needed. hence dropping f and going with g.

dhull: can see case for no responses/non-anon only at server.

anish: trutt asserted that common case would be both supported? does not agree. thinks anon would be more common.

<TRutt__> addressing with non anon and requiring make connection does what anish wants

anish: agrees with tom.

katy: go back to before cr33 and have definition that "I support ws-a" means everything in the spec until this restriction came along (anon versus non-anon).
... thinks we should stay as we are.

<scribe> chair: no reason to re-open lc133?

katy: agrees.

<Katy> I agree with Ram - new requirements should be clarified in new issues

<anish> what usingAdressing said:

<anish> If WS-A is engaged, use of the message addressing properties MUST be fully compliant with this specification; in particular, senders MUST use all message addressing properties mandated by the Web Services Addressing 1.0 - Core[WS-Addressing Core], applicable WS-Addressing protocol bindings (e.g. Web Services Addressing 1.0 - SOAP Binding[WS-Addressing SOAP Binding]), and this specification, and MUST follow all applicable WS-Addressing normative requiremen

anish: described his understanding of definition of usingAddressing.

<TRutt__> AnonOnly, NonAnonOnly, NoResponsesAllowed could be three separate top level assertions, with neither present being "nothing stated"

<scribe> chair: what is different from g and usingAddressing text for tl assertion?

anish: difference is that usingAddressing is conformance to ws-a. But g is conformance plus that anon and non-anon are allowed.

trutt: thinks this is a valid assertion, but we should pull out anon/non-anon as tl assertions for composability.

<scribe> chair: could anish and tom take point offline?

<scribe> chair: spent enough time going over this. g was agreed by group. No compelling information to go back on g.

<dhull> doesn't G disallow anon and non-anon together?

<anish> dhull, it does not allow them together

<anish> i really think that using the usingddressing text makes thing composable

ram: believes text can be merged and come to agreement.

trutt: does not know how text can be reconciled.

katy: is there a requirement for "I don't support anything"? There are requirements for non-anon/anon.

+1

<scribe> chair: katy, let's have a vote and can you come up with the wording?

katy: full support, anon, non-anon only. Is there a requirement for "I support addressing but I don't say anything about whether I support anon or non-anon".

<Katy> Do we have a requirement to say "I support addressing but I don't say anything about my support for nonanon or anon responses"?

-1

<TRutt__> no

<dhull> yes

<Katy> no

<anish> yes

<Ram> NO

<gpilz> +1

<TonyR> abstain

3 yes

4 nos

<scribe> chair: close vote, but can we close this?

2 yes

5 nos

1 abstain

<scribe> chair: believes that margin is now enough to close this.

<scribe> chair: closed?

group: agrees.

<monica> may i make one comment

<scribe> chair: so how does this vote affect open issues? lc135?

trutt: lc135 should be close no change.

<Ram> +1

<anish> so with this decision, if i want to match policy that says support for anon, then it would match a policy that only says <wsam:Addressing>

<scribe> chair: group close lc135 no action?

RESOLUTION: lc135 closed no action

<scribe> chair: lc134 is last open issue. would like to get to lc again. incorporate resolution to lc133 into new editors draft of 1.0 metadata document so at next call we can have new resolution to get to lc.

<Ram> Related text: The inclusion of the wsaw:UsingAddressing element indicates that the applicable WS-Addressing specifications are supported and allows use of anonymous or non-anonymous URIs as addresses in an EPR. Specifically, when included in a SOAP binding, the wsaw:UsingAddressing marker identifies the use of Web Services Addressing 1.0 bound to SOAP as defined by Web Services Addressing 1.0 - SOAP Binding[WS-Addressing SOAP Binding].The presence of this eleme

+1

<Ram> Anish: Are you fine with this text?

<anish> does that mean i can use this assertion on the portType?

<TRutt__> I would clarify that I would be happy with a binding agnostic ws:addressing assertion type

<Ram> I propose that we allow both.

<gpilz> The presence of the wsam:Addressing assertion indicates that the applicable WS-Addressing specifications are supported. Specifically, when included in a SOAP binding, the wsam:Addressing assertion identifies the use of Web Services Addressing 1.0 bound to SOAP as defined by Web Services Addressing 1.0

group: seems wrong to have to modify the specification to add support for new protocols.

<gpilz> - SOAP Binding[WS-Addressing SOAP Binding].

<scribe> chair: happier to have something that does not constrain the future.

<anish> :-)

ram: proposes text as resolution.

<Ram> New Text: The use of the WS-Addressing policy assertion indicates that the applicable WS-Addressing specifications are supported and allows use of anonymous or non-anonymous URIs as addresses in an Response EPR. Specifically, when included in a SOAP binding, the WS-Addressing policy assertion identifies the use of Web Services Addressing 1.0 bound to SOAP as defined by Web Services Addressing 1.0 - SOAP Binding[WS-Addressing SOAP Binding].

<anish> for usingaddressing:

<anish> The wsaw:UsingAddressing element SHOULD appear as a child of the wsdl:binding element. Alternatively, the wsaw:UsingAddressing element MAY instead be included as a child of the wsdl20:endpoint (or wsdl11:port) when an endpoint intends to indicate compliance with WS-Addressing for a specific endpoint only.

<TRutt__> Response to "(D) The WS-Addressing Metadata draft does not specify a

<TRutt__> policy subject"

<TRutt__> The policy subject has been identified as endpoint to wit:

<TRutt__> "The wsam:Addressing policy assertion applies to the endpoint policy

<TRutt__> subject"

<TRutt__> Response to "(E) The WS-Addressing Metadata draft should rule out

<TRutt__> wsdl:portType and wsdl20:interface as possible attachment points."

<TRutt__> Such a prohibition has been included to wit:

<TRutt__> "A policy expression containing the wsam:Addressing policy assertion

<TRutt__> MUST NOT be attached to a wsdl:portType or wsdl20:interface. The

<TRutt__> wsam:Addressing policy assertion specifies a concrete behavior whereas

<TRutt__> the wsdl:portType or wsdl20:interface is an abstract construct"

<anish> what this proposal means:

<anish> 1) assertion means core+soapbinding

<anish> 2) cannot be used on abstract wsdl

<anish> 3) (1) & (2) means cannot be used on a non-soap binding

This feels rushed. Why can't we go with the original action item and let Anish and Gill take this offline and come back next week? I'd prefer to get something to vote on that is well thought out and not just thrown together in 30 seconds ;-)

<monica> +1

Can someone take over scribe duty? I've got to go, unfortunately.

Proposal: Add to Section 3 the language " This assertion implies support for ws-addr core and soap binding.

<Ram> +1

<Katy> +1

<anish> yes, that makes sense, unless we satisfy gil's requirement

<dhull> +1

<monica> should you use the work 'indicates'?

<dhull> How about "asserts"? That's what assertions do, after all.

<monica> this is an issue to the baseline that applies

<Ram> Should we go LC today?

<anish> woo-hoo, now if ws-policy will just answer our questions

<Ram> Did we resolve and accept proposal G??

RESOLUTION: lc134 with "Add to Section 3 the language " This assertion implies support for ws-addr core and soap binding."