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

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 Wednesday, 28 February 2007 23:19:45 UTC