- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Fri, 11 May 2007 12:13:56 -0500
- To: "Bob Freund" <bob@freunds.com>
- Cc: "Paul Cotton" <Paul.Cotton@microsoft.com>, "[WS-A]" <public-ws-addressing@w3.org>, public-ws-policy@w3.org
- Message-ID: <OF3D4A54F1.0B153164-ON852572D8.005D8774-852572D8.005E8C32@us.ibm.com>
Bob,
Thanks for this point-by-point analysis of the WS-Addressing WG's
disposition of the WS-Policy WG's comments [1]
regarding the WS-Addressing Metadata spec [2].
The WS-Policy WG has reviewed the issues disposition provided and the
latest draft of the spec and we agree that the resolutions
to these issues correctly address the intent of the comments made by the
WS-Policy working group.
[1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2007Feb/0006.html
[2] http://www.w3.org/TR/2007/WD-ws-addr-metadata-20070202/
Cheers,
Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295
"Bob Freund" <bob@freunds.com> wrote on 04/23/2007 06:14:48 PM:
> 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
>
> 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].
>
> 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] and Web
> Services Policy - Attachment [WS Policy 1.5 - Attachment]
> specifications. This specification defines three policy assertions.
>
> The wsam:Addressingpolicy assertion applies to the endpoint policy
subject.
>
> For WSDL 1.1, these assertions may be attached to wsdl11:portor
> wsdl11:binding. For WSDL 2.0, they may be attached to wsdl20:
> endpointor wsdl20:binding.
>
> A policy expression containing the wsam:Addressingpolicy assertion
> MUST NOT be attached to a wsdl:portTypeor wsdl20:interface. The
> wsam:Addressingpolicy assertion specifies a concrete behavior
> whereas the wsdl:portTypeor wsdl20:interface is an abstract construct.
>
> 3.1.1 Addressing Assertion
>
> The wsam:Addressingpolicy 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:Addressingassertion indicates that there are
> norestrictions 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:Addressingassertion.
>
>
>
> 3.1.2 AnonymousResponsesAssertion
>
> The wsam:AnonymousResponseselement MAY be used as a policy assertion
> nested within the wsam:Addressingassertion 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:
> Addressingpolicy assertionindicates that the endpoint expresses explicit
> requiressupport for request messages with to use response endpoint
> EPRsthat 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
> ofanonymous 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 NonAnonymousResponsesAssertion
>
> The wsam:NonAnonymousResponseselement 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:NonAnonymousResponsespolicy assertion MUST NOT be used in the
> same policy alternative as the wsam:AnonymousResponsespolicy assertion.
>
> The appearance of this element within a policy alternativethe wsam:
> Addressingassertionindicates that the endpoint expresses explicit
support for
> requiresrequest messages with to use response endpoint EPRsthat
> contain something other than the anonymous URI as the value of
> [address]. In other words, the endpoint guarantees support for
> requires the use ofnon-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:Addressingwsp: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 support
> requires the useof 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 of
> requires the use ofnon-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>
>
> <AnonymousResponsesOptional=?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 nonAnonymousresponses -->
>
> <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].
>
>
>
> #### WSAddrPolicyAlgerntiveGprime.doc removed & duplicate added to
> MyAttachments Repository () on 01 May 2007 by Christopher B Ferris.
> Original attachment record is here ().
Received on Friday, 11 May 2007 17:14:51 UTC