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

Received on Thursday, 1 March 2007 00:18:59 UTC