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

Tom,
What does it mean if neither wsam:Anon nor wsam:nonAnon appear under a 
wsam:Addressing element?
In your proposal you say the absence of wsam:Anon means it Anon can't be 
used.
In your proposal you say the absence of wsam:nonAnon means Anon must be 
used.
So we have contradictory statements when neither appear, no?

thanks
-Doug
______________________________________________________
STSM  |  Web Services Architect  |  IBM Software Group
(919) 254-6905  |  IBM T/L 444-6905  |  dug@us.ibm.com



Tom Rutt <tom@coastin.com> 
Sent by: public-ws-policy-request@w3.org
02/28/2007 07:18 PM
Please respond to
tom@coastin.com


To
Gilbert Pilz <Gilbert.Pilz@bea.com>
cc
tom@coastin.com, wsrx <ws-rx@lists.oasis-open.org>, 
public-ws-addressing@w3.org, ws policy <public-ws-policy@w3.org>
Subject
Re: [ws-rx] I just posted a PR comment on MakeConnection Policy assertion







I put an example policy which has three alternatives

These cover the CR33 is in my opinion.

The following example shows an equivalent policy expression, assuming 
proposed
alternative A (wsa:NonAnonymous defined as any URI value other than 
wsa:Anonymous) is selected.  This requires use of MakeConnection to be 
treated as a special case of wsam:nonAnonymous reply.



<wsp:Policy>  <-- Policy expression for proposed alternative a) -->
..<wsp:ExactlyOne>

....<wsp:All>
......<wsam:Addressing>
........<wsp:Policy>
..........<wsp:ExactlyOne>
..........<!-- anon or non-anon responses required-->
............<wsp:All>
..............<wsam:AnonymousResponses/>
............</wsp:All>
............<wsp:All>
...............<wsam:NonanonymousResponses/>
............</wsp:All>
..........</wsp:ExactlyOne>
........</wsp:Policy>
......</wsam:Addressing>
......<!--  wsmc:MakeConnection is not asserted as part of this all, 
thus no statement on its use in this alternative --.>
....</wsp:All>


....<! Addressing required, only use makeConnection for reply -->
....<wsp:All>
......<wsam:Addressing>
........<wsp:Policy>
..........<wsp:ExactlyOne>
..........<!-- non-anon responses required-->
............<wsp:All>
...............<wsam:NonanonymousResponses/>
............<wsp:All>
..........</wsp:ExactlyOne>
........</wsp:Policy>
......</wsam:Addressing>
......<wsmc:MakeConnection/>
....</wsp:All>
..</wsp:ExactlyOne>
</wsp:Policy>



Tom Rutt wrote:
> Comments below
>
> Tom Rutt
>
> Gilbert Pilz wrote:
>> This discussion really belongs in WS-Addr so I've cross-posted . . .
>>
>> I'm very uncomfortable with the idea that the non-presence of the
>> wsam:NonAnonymousResponses implies that non-anonymous reply addresses 
>> are
>> not supported. Doesn't this just re-open the festering wound of CR33?
>>
>> Both the wsam:AnonymousResponses and wsmc:MCResponses assertions 
>> refer to
>> the use of fairly specific URIs, but wsam:NonAnonymousResponses 
>> refers to
>> the use of *any* URI other than
>> "http://www.w3.org/2005/08/addressing/anonymous". To say that the 
>> absence of
>> wsam:NonAnonymousResponses implies its negation is to say that *only*
>> wsa:Anon is supported (thus ruling out things like the wsmc:Anon URI).
>> Didn't we spend months figuring out that this wouldn't work?
>> 
> Since these two policy assetions are nested in Addressing asssertion, 
> any policy maker
> who includes the addressing assertion is aware of the semantics of its 
> two nested policy assertion types.
>
> That policy maker can construct a policy expression which contains 
> enough alternatives to
> cover all the response mechanisms it wants to use with that endpoint.
> Anyway, lets assume we take out the text about "non presence means 
> prohibition".  if someone puts int "AnonymousResponses" nested 
> assertion in an addressing assertion and it is a requirement, that is 
> saying that other type of responses cannot be used (since anonymous is 
> required for instances of responses).  Thus to allow use of non 
> anonymous responses and anonymous responses would require two 
> alternative in the policy expression.
>
> If we have to deal with alternatives anyway to espress the necessary 
> semantics of replies in a policy expression, I do not see the problem 
> of having "non Presence" of the NonAnonymousResponses
> nested assertion in any alternative involving addressing assetion 
> implying non-anonymous is prohibited.  Just add another alternative 
> which includes the nested assertion you want.
>
>
> Tom Rutt
>> - gp
>>
>> 
>>> -----Original Message-----
>>> From: Tom Rutt [mailto:tom@coastin.com] Sent: Tuesday, February 27, 
>>> 2007 12:56 PM
>>> To: tom@coastin.com
>>> Cc: Doug Davis; wsrx
>>> Subject: Re: [ws-rx] I just posted a PR comment on MakeConnection 
>>> Policy assertion
>>>
>>> Tom Rutt wrote:
>>> 
>>>> Tom Rutt wrote:
>>>> 
>>>>> Doug Davis wrote:
>>>>> 
>>>> I now understand that your changes are required since make 
>>> connection 
>>>> can also be used for delivering requests.
>>>>
>>>> Thus I agree with our changes to my proposal.
>>>>
>>>> However we still need to discuss the need for a statement on Non 
>>>> Presence implying prohibition.
>>>> 
>>> After talking to some ws-policy experts, it seems that because 
>>> MakeConnection is a first level policy assertion type, lack of 
>>> presence of this assertion anywhere in a policy alternative says 
>>> nothing about its use.
>>>
>>> The difference with ws addressing nested paramters is that they are 
>>> defined within the context of the first level assertion "addressing" 
>>> .  This for these nested parameters, non presence within an 
>>> asseretion of "addressing" policy  implies prohibition of that 
>>> alternative.
>>>
>>> The tricky part is if a policy has two alternatives, and one of 
>>> those alternative includes the MakeConnection assertion, that policy 
>>> statement has introduced MakeConnection into the policy vocabulary. 
>>> In such a case, does absence in one of the assertions imply not 
>>> using make connection?
>>>
>>> eg
>>>
>>> <wsp:Policy>
>>> <wsp:ExactlyOne>
>>> <wsp:All>
>>> <wsmc:MakeConnection/>
>>> </wsp:All>
>>> <wsp:All>
>>> <-- does this alternative prohibit use of MakeConnection?? -->
>>> </wsp:All>
>>> </wsp:ExactlyOne>
>>> </wsp:Policy>
>>>
>>> 
>>>> This discsussion needs to distinguish an endpoint which has 
>>> no policy 
>>>> statement attached, from one which has policy attached, but 
>>> does not 
>>>> include the makeConnection assertion in any alternative.
>>>> 
>>>>>> Tom,
>>>>>> you proposed:
>>>>>> 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].
>>>>>> "
>>>>>> Since MC doesn't talk about any EPR in particular I think 
>>> it would 
>>>>>> make more sense to reword as:
>>>>>> "
>>>>>> The MakeConnection policy assertion indicates that the 
>>> MakeConnection
>>> 
>>>>>> protocol (operation and the use of the MakeConnection URI 
>>> template in
>>> 
>>>>>> EndpointReferences) is required for messages from this 
>>> endpoint. This
>>> 
>>>>>> assertion has Endpoint Policy Subject [WS-PolicyAttachment].
>>>>>> 
>>>>> your wording removed "required for instances of replies". Is this 
>>>>> because you wish it to be used for requests as well.?
>>>>> 
>>>>>> "
>>>>>> And then you suggested:
>>>>>> 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.
>>>>>> "
>>>>>> And I would suggest this instead:
>>>>>> "
>>>>>> A policy assertion that specifies that the MakeConnection 
>>> protocol is
>>> 
>>>>>> required for instances of messages from this endpoint.
>>>>>> "
>>>>>>
>>>>>> 
>>>>> same question, I assumed makeConnection is for responses, are you
>>>>> are pointing out it can also be used for requests?
>>>>> Tom
>>>>> 
>>>>>> As to Paul's question of severity of this change, it 
>>> would seem that
>>> 
>>>>>> your text is still consistent with the intent of the 
>>> original text,
>>> 
>>>>>> as such it seems like a non-substantive change. Would you agree?
>>>>>>
>>>>>> thanks
>>>>>> -Doug
>>>>>> ______________________________________________________
>>>>>> STSM | Web Services Architect | IBM Software Group
>>>>>> (919) 254-6905 | IBM T/L 444-6905 | dug@us.ibm.com
>>>>>>
>>>>>> 
>>>>> ----------------------------------------------------
>>>>> Tom Rutt    email: tom@coastin.com; trutt@us.fujitsu.com
>>>>> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>>>>>
>>>>>
>>>>> 
>>>> 
>>> -- 
>>> ----------------------------------------------------
>>> Tom Rutt    email: tom@coastin.com; trutt@us.fujitsu.com
>>> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>>>
>>>
>>>
>>> 
>

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