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

[Doug Davis <dug@us.ibm.com>]

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