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

For WG approval

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