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

+1
Tom Rutt

Bob Freund wrote:
> 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 
>
>
>   
>
> ------------------------------------------------------------------------
>
>
>     3. Indicating Use of WS-Addressing
>
> This specification supports a mechanism for indicating, in a WSDL 
> description, that the endpoint conforms to the WS-Addressing 
> specification. That mechanism uses WS-Policy Framework [WS Policy 1.5 
> - Framework <#WSPolicy>].
>
>
>       3.1 WS-Policy Assertions
>
> The mechanism for indicating that a binding or endpoint conforms to 
> the WS-Addressing specification is through the use of the Web Services 
> Policy - Framework [WS Policy 1.5 - Framework <#WSPolicy>] and Web 
> Services Policy - Attachment [WS Policy 1.5 - Attachment 
> <#WSPolicyAttachment>] specifications. This specification defines 
> three policy assertions.
>
> The wsam:Addressing policy assertion applies to the endpoint policy 
> subject.
>
> For WSDL 1.1, these assertions may be attached to |wsdl11:port| or 
> |wsdl11:binding|. For WSDL 2.0, they may be attached to 
> |wsdl20:endpoint| or |wsdl20:binding|.
>
> 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.
>
>
>         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.
>
>
>         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 a policy alternativethe 
> wsam:Addressing policy assertion indicates that the endpoint expresses 
> explicitrequires support for request messages with 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 guarantees support forrequires 
> the use of anonymous responses.
>
> The absence of the wsam:AnonymousResponses policy assertion within a 
> policy alternative does *not* indicate that the endpoint will not 
> accept request messages with response endpoint EPRs that contain the 
> anonymous URI as an address; it simply indicates the lack of any 
> affirmation of support for anonymous URIs.
>
> 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.
>
>
>         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 a policy alternativethe 
> wsam:Addressing assertion indicates that the endpoint expresses 
> explicit support forrequires request messages with to use response 
> endpoint EPRs that contain something other than the anonymous URI as 
> the value of [address]. In other words, the endpoint guarantees 
> support forrequires 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.
>
> As with the other assertions, the absence of the 
> wsam:NonAnonymousResponses policy assertion within a policy 
> alternative does *not* indicate that the endpoint will not accept 
> request messages with response endpoint EPRs that contain something 
> other than the anonymous URI address; it simply indicates the lack of 
> any affirmation of support for them.
>
> 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.
>
>
>         3.1.4 Examples (Compact Form)
>
> /Example 3-1.// Subject supports WS-Addressing, no statement on 
> supported response EPRs/
>
> <wsp:Policy>
>
> <wsam:Addressing wsp:Optional="true">
>
> <wsp:Policy/>
>
> </wsam:Addressing>
>
> </wsp:Policy>
>
> /Example 3-2.// Subject requires WS-Addressing, no statement on 
> supported response EPRs/
>
> <wsp:Policy>
>
> <wsam:Addressing>
>
> <wsp:Policy/>
>
> </wsam:Addressing>
>
> </wsp:Policy>
>
> /Example 3-3. Subject supports WS-Addressing, explicitly (and 
> optionally) supports anonymous and non-anonymous response EPRs/
>
> <wsp:Policy>
>
> <wsam:Addressing wsp:Optional="true">
>
> <wsp:Policy>
>
> <wsam:AnonymousResponses wsp:Optional="true"/>
>
> <wsam:NonAnonymousResponses wsp:Optional="true"/>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:Policy>
>
> /Example 3-4. Subject requires WS-Addressing, requires explicit 
> support of anonymous or non-anonymous response EPRs/
>
> <wsp:Policy>
>
> <wsam:Addressing>
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsam:AnonymousResponses/>
>
> <wsam:NonAnonymousResponses/>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:Policy>
>
> /Example 3-53.// Subject requires WS-Addressing and explicit 
> supportrequires the use of non-anonymous response EPRs/
>
> <wsp:Policy>
>
> <wsam:Addressing>
>
> <wsp:Policy>
>
> <wsam:NonAnonymousResponses/>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:Policy>
>
>
>         3.1.5 Examples (Normal Form)
>
> /Example 3-46. Subject supports WS-Addressing, no statement on 
> supported response EPRs/
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All/>
>
> <wsp:All>
>
> <wsam:Addressing>
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All/>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> /Example 3-57. Subject requires WS-Addressing, no statement on 
> supported response EPRs/
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <wsam:Addressing>
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All/>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> /Example 3-8. Subject supports WS-Addressing, explicitly (and 
> optionally) supports anonymous and non-anonymous response EPRs/
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All/>
>
> <wsp:All>
>
> <wsam:Addressing>
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All/>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:All>
>
> <wsp:All>
>
> <wsam:Addressing>
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <wsam:AnonymousResponses/>
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:All>
>
> <wsp:All>
>
> <wsam:Addressing>
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <wsam:NonAnonymousResponses/>
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:All>
>
> <wsp:All>
>
> <wsam:Addressing>
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <wsam:AnonymousResponses/>
>
> <wsam:NonAnonymousResponses/>
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> /Example 3-9. Subject requires WS-Addressing, requires explicit 
> support of anonymous or non-anonymous response EPRs/
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <wsam:Addressing>
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <wsam:AnonymousResponses/>
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:All>
>
> <wsp:All>
>
> <wsam:Addressing>
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <wsam:NonAnonymousResponses/>
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> /Example 3-610. Subject requires WS-Addressing and explicit support 
> ofrequires the use of non-anonymous response EPRs/
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <wsam:Addressing>
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <wsam:NonAnonymousResponses/>
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
>
>         3.1.6 Finding Compatible Policies
>
>
>         When a client is looking for an endpoint with compatible
>         policy, one common method used is to take the policy
>         intersection between the policy which the client is looking
>         for, and the policy asserted in the WSDL document; a non-empty
>         intersection is sought. The policy used by the client must be
>         written carefully to avoid unexpected results. This is most
>         obvious when the client is not looking for explicit support of
>         a particular kind of response; failing to take care could mean
>         missing a compatible policy.
>
> /Example 3-7. Client looking for an endpoint which supports 
> Addressing, and which supports anonymous responses/
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <wsam:Addressing>
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <AnonymousResponses Optional=”true” />
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> /Example 3-8. Client looking for an endpoint which supports 
> Addressing, and does not require support for responses (will intersect 
> with anything)/
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <wsam:Addressing> <-- supports all response types -->
>
> <wsp:Policy>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:All>
>
> <wsp:All>
>
> <wsam:Addressing> <-- requires Anonymous responses -->
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <AnonymousResponses />
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:All>
>
> <wsp:All>
>
> <wsam:Addressing> <- requires nonAnonymous responses -->
>
> <wsp:Policy>
>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <NonAnonymousResponses />
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
> </wsam:Addressing>
>
> </wsp:All>
>
> </wsp:ExactlyOne>
>
> </wsp:Policy>
>
>
>         For more detailed descriptions of the use of wsp:Optional,
>         wsp:Ignorable, and strict and lax intersection, please refer
>         to the WS-Policy Primer [WS Policy 1.5 - Primer
>         <#WSPolicyPrimer>].
>
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Monday, 23 April 2007 19:05:29 UTC