RE: Response to the Last Call comments by WS-Policy to the WS-Addressing Metadata document 1.0

Hello,

We have reviewed the changes made to the WS-Addressing Metadata spec by the WS-Addressing working group and we think the changes address the intent of the comments made by the WS-Policy working group.  We suggest responding to the WS-Addressing working group that our comments have been appropriately addressed.

Thanks.

Daniel Roth

-----Original Message-----
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Bob Freund
Sent: Monday, April 23, 2007 3:15 PM
To: public-ws-policy@w3.org; [WS-A]
Cc: Paul Cotton; Christopher B Ferris
Subject: Response to the Last Call comments by WS-Policy to the WS-Addressing Metadata document 1.0

As approved during the WS-Addressing WG Teleconference on 2007-04-23:

This is in response to the WS-Policy group's last call review[1] of the WS-Addressing 1.0 Metadata Document[2].
The WS-Policy WG's review generated WS-Addressing issue lc133[4] which was resolved with a resolution which adopted "Proposal G"[3] as editorially by modified in section 3.1.1 and in examples by the resolution.

We have attached the resulting section 3 of the WS-Addressing 1.0 Metadata Document so created.  The WS-Addressing WG feels that this resolution substantially resolves your comments found in [1].
If you agree that this resolution satisfies the comments contained in [1], please so indicate by an affirmative response to this message. If not, please provide additional clarifying commentary.

In detail, we have made the following adjustments:
In response to points A and B contained in [2]
"(A) The presence of either of the two nested assertions does not indicate a required behavior."

The working group discussed this at length and was confused by the use of the phrase "required behavior" in [1] since in WS-Policy 1.5 Framework 1. "Introduction" it is stated:

"A policy assertion represents a requirement, capability, or other property of a behavior"

And in WS-Policy 1.5 Framework section 2.4 "Terminology" it is stated:

"Definition: A policy assertion represents a requirement, a capability, or other property of a behavior"

The working group assumed that "requirement, a capability, or other property of a behavior" was intended

Further to (A), we have provided substitute policy assertions as incorporated within the attached to wit:

"3.1.1 Addressing Assertion
The wsam:Addressing policy assertion is a nested policy container assertion. The meaning of this assertion, when present in a policy alternative, is that WS-Addressing is required to communicate with the subject. The wsam:Addressing assertion indicates that there are no restrictions on the use of WS-Addressing unless otherwise qualified by assertions in its nested policy expression.  In order to indicate that the subject supports WS-Addressing but does not require its use, an additional policy alternative should be provided which does not contain this assertion. This may be done in WS-Policy compact form by adding the attribute wsp:Optional="true" to the wsam:Addressing assertion."

And: two nested assertions which may appear within the Addressing Assertion

"3.1.2 AnonymousResponses Assertion
The wsam:AnonymousResponses element MAY be used as a policy assertion nested within the wsam:Addressing assertion in accordance with the rules laid down by WS-Policy Framework 1.5 section 4.3.2.
The appearance of this element within the wsam:Addressing policy assertion indicates that the endpoint requires request messages to use response endpoint EPRs that contain the anonymous URI
("http://www.w3.org/2005/08/addressing/anonymous") as the value of [address]. In other words, the endpoint requires the use of anonymous responses.
The None URI ("http://www.w3.org/2005/08/addressing/none") may appear as the value of [address] in place of the anonymous URI; this value MUST be accepted."

And:

"3.1.3 NonAnonymousResponses Assertion
The wsam:NonAnonymousResponses element MAY be used as a policy assertion nested within the Addressing assertion in accordance with the rules laid down by WS-Policy Framework 1.5 section 4.3.2. The wsam:NonAnonymousResponses policy assertion MUST NOT be used in the same policy alternative as the wsam:AnonymousResponses policy assertion.
The appearance of this element within the wsam:Addressing assertion indicates that the endpoint requires request messages to use response endpoint EPRs that contain something other than the anonymous URI as the value of [address]. In other words, the endpoint requires the use of non-anonymous responses. This assertion is deliberately vague; its presence indicates that some non-anonymous addresses will be accepted but doesn't constrain what such an address might look like. A receiver can still reject a request that contains an address that it doesn't understand or that requires a binding it doesn't support.
The None URI ("http://www.w3.org/2005/08/addressing/none") may appear as the value of [address] in place of a non-anonymous address; this value MUST be accepted."


Response to "(D) The WS-Addressing Metadata draft does not specify a policy subject"
The policy subject has been identified as endpoint to wit:

"The wsam:Addressing policy assertion applies to the endpoint policy subject"


Response to "(E) The WS-Addressing Metadata draft should rule out wsdl:portType and wsdl20:interface as possible attachment points."

Such a prohibition has been included to wit:

"A policy expression containing the wsam:Addressing policy assertion MUST NOT be attached to a wsdl:portType or wsdl20:interface. The wsam:Addressing policy assertion specifies a concrete behavior whereas the wsdl:portType or wsdl20:interface is an abstract construct"

Thanks
-bob
Chair, WS-Addressing

[1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Feb/0006.ht
ml
[2] http://www.w3.org/TR/2007/WD-ws-addr-metadata-20070202/
[3]
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Mar/att-004
3/WSA_Policy_-_alternative_G.pdf
[4] http://www.w3.org/2002/ws/addr/lc-issues/Overview.html#lc133

Received on Tuesday, 8 May 2007 16:29:57 UTC