Re: [ws-rx] I just posted a PR comment on MakeConnection Policy assertion

[Christopher B Ferris <chrisfer@us.ibm.com>]

Actually, let's be clear. You do NOT
have to have a policy alternative with an 
MC assertion in order to engage. 

A policy has a vocabulary
A policy can have multiple alternatives
An alternative has a vocabulary that
is a subset of the policy vocabulary

If an assertion is absent from the policy
vocabulary, then the policy says NOTHING
about the requirement/capability expressed
by that assertion.

If the policy vocabulary includes an
assertion, an an alternative does not, then 
for that alternative, there is an implied
NOT for that assertion.

http://www.w3.org/TR/2006/WD-ws-policy-20061117/#rPolicy_Alternative
"[Definition:
A policy alternative is a potentially empty collection of policy
assertions.] An alternative with zero assertions
indicates no behaviors. An alternative with one or more assertions indicates
behaviors implied by those, and only those assertions. [Definition: A policy
vocabulary is the set of all policy
assertion types used in a policy.] [Definition:
A policy alternative vocabulary is the set of all policy
assertion types within the policy
alternative.] When an assertion whose type is
part of the policy's vocabulary is not included in a policy alternative,
the policy alternative without the assertion type indicates that the assertion
will not be applied in the context of the attached policy subject. See
the example in Section 4.3.1
Optional Policy Assertions "

Let me repeat the important part:

When an assertion whose type is part of the policy's vocabulary
is not included in a policy alternative, the policy alternative without
the assertion type indicates that the assertion will not be applied in
the context of the attached policy subject.

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

Tom Rutt <tom@coastin.com>

02/27/2007 02:36 PM

Please respond to
tom@coastin.com

To	Paul Fremantle <paul@wso2.com>
cc	wsrx <ws-rx@lists.oasis-open.org>
Subject	Re: [ws-rx] I just posted a PR comment on MakeConnection Policy assertion

Paul Fremantle wrote:
> Tom
>
> Two questions:
>
> 1) Does this imply that to support MakeConnection REQUIRES the 
> endpoint to support and publish WS-Policy?
NO, however if you do support and publish ws-policy on an endpoint, then
you have to assert MakeConnection in that policy statement to use 
MakeConnection to send messaged from that endpoint.
>
> 2) Do you consider this a substantive change to the spec requiring
> another PR?
NO
>
> Paul
>
> Tom Rutt wrote:
>> I just posted a PR comment on MakeConnection Policy Assertion
not 
>> stating a requirement.
>>
>> I copy it here to this list as well: the following is the text
I 
>> posted to ws-rx-comment@lists.oasis-open.org
>> ------
>> Public Review Issue:
>> Title: MakeConnection Policy assertion is not a Requirement.
>>
>> Target: Web Services Make Connection v1.0
>> http://www.oasis-open.org/apps/org/workgroup/ws-
>> rx/download.php/22238/wsmc-1.0-spec-cd-05.pdf
>>
>> Rationale:
>>
>> The W3C WS-Policy working group has reviewed the WS-Addressing
Metadata
>> CR Specification ( http://www.w3.org/TR/2007/WD-ws-addr-metadata-
>> 20070202/ ., and has sent a comment suggesting changes to the
>> definitions of the AnonymousReplies, and NonAnonymousReplies nested
>> policy assertions. The recommendations and rationale for this
comment
>> are in the email: http://lists.w3.org/Archives/Public/public-ws-
>> policy/2007Feb/0140.html .
>>
>> It is pointed by the WS-Policy WG that these assertions are not
>> expressed as requirements, which causes problems in their application
>> within the policy intersection algorithm.
>>
>> It is recommended that these assertion definitions be changed
as
>> requirements within the scope of a single response message originating
>> from the endpoint to which the policy is attached. Policy statements
>> can be formed which state that one of a set of response types
must be
>> used to deliver reply messages.
>>
>> For example, assuming the two nested assertion types are changed
to be
>> requirements applying to instances of replies from an endpoint,
the
>> following policy expression states that either wsa:AnonymousReplies
or
>> wsa:NonAnonymousReplies are required to be used for sending replies
from
>> the endpoint to which this expression is attached:.
>>
>> <wsam:Addressing>
>> <wsp:Policy>
>> <wsp:ExactlyOne>
>> <wsp:All> <!-- either anon and non-anon responses required-->
>> <wsam:AnonymousResponses/>
>> </wsp:All>
>> <wsp:All>
>> <wsam:NonanonymousResponses/>
>> <wsp:All>
>> </wsp:ExactlyOne>
>> </wsp:Policy>
>> </wsam:Addressing>
>>
>> It is necessary to clarify that the scope of the assertion applies
to a
>> single instance of an MEP, not to all instances of MEPs associated
with
>> the endpoint,. to allow the client to choose for each message
exchange
>> the appropriate type of response.
>>
>> For the same reasons, the MakeConnection policy assertion definition
>> needs to be changed to be a requirement pertaining to instances
of
>> response messaged send from an endpoint.
>>
>> This does not cause problems of composition with ws addressing,
as the
>> following example demonstrates.
>>
>> Assuming the nested ws addressing assertions and the makeConnection
>> assertion are changed to be defined as requirements on instances
of
>> response messages sent from an endpoint, the following policy
expression
>> states that either the wsa:AnonymousReplies or the
>> wsa:NonAnonymousReplies or the wsmc:MakeConnection mechanism is
required
>> to be used for sending replies from the endpoint to which this
>> expression is attached:
>>
>> <wsp:Policy>
>> <wsp:ExactlyOne>
>> <wsp:All>
>> <wsam:Addressing>
>> <wsp:Policy>
>> <wsp:ExactlyOne>
>> <wsp:All> <!-- anon or non-anon responses required-->
>> <wsam:AnonymousResponses/>
>> </wsp:All>
>> <wsp:All>
>> <wsam:NonanonymousResponses/>
>> <wsp:All>
>> </wsp:ExactlyOne>
>> </wsp:Policy>
>> </wsam:Addressing>
>> <wsp:All>
>> <wsp:All> <! Addressing required, usemakeConnection for
reply -->
>> <wsam:Addressing>
>> <wsmc:MakeConnection>
>> <wsp:All>
>> </wsp:ExactlyOne>
>> <wsp:Policy>
>>
>> Stated in words, this endpoint requires that responses must be
sent
>> either as NonAnonymousReplies, or as wsa:Anonymous replies, or
as a
>> wsmc:MakeConnection reply.
>>
>> Proposed Resolution:
>>
>> In Clause 3.4 MakeConnection:
>>
>> Change lines 327 – 329 from:
>> “
>> The MakeConnection policy assertion indicates that the MakeConnection
>> protocol (operation and the use of the MakeConnection URI template
in
>> EndpointReferences) is supported. This assertion has Endpoint
Policy
>> Subject [WS-PolicyAttachment].
>> “
>> To
>> “
>> The MakeConnection policy assertion indicates that the MakeConnection
>> protocol (operation and the use of the MakeConnection URI template
in
>> EndpointReferences) is required for instances of replies. This
>> assertion has Endpoint Policy Subject [WS-PolicyAttachment].
>> “
>>
>> Change line 334 from:
>> “
>> A policy assertion that specifies that the MakeConnection protocol
is
>> supported.
>> “
>> To
>> “
>> A policy assertion that specifies that the MakeConnection protocol
is
>> required for instances of replies from an endpoint.
>> “
>>
>> Delete the following lines 341 – 343:
>> “
>> Because this policy assertion expresses a capability of a receiver
>> (rather than a requirement sender), care should be taken to ensure
that
>> it is decorated with the appropriate WS-Policy indicate that use,
>> support and understanding, of this assertion is optional to the
sender.
>> “
>>
>


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