OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Absence of wsam:NonAnon implies prohibition of non-anon response (was RE: [ws-rx] I just posted a PR comment on MakeConnection Policy assertion)


I agree that, at a shallow level, the policy is 'valid'. However, if I wanted to indicate to clients that they must use ReplyTo addresses that are either wsa:anon or wsmc:anon, this is an incorrect policy. Agreed?
 
- gp


From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, March 01, 2007 10:20 AM
To: Gilbert Pilz
Cc: public-ws-addressing@w3.org; ws policy; public-ws-policy-request@w3.org; tom@coastin.com; wsrx
Subject: Re: Absence of wsam:NonAnon implies prohibition of non-anon response (was RE: [ws-rx] I just posted a PR comment on MakeConnection Policy assertion)


I believe this is valid from a policy perspective.
wsa:ReplyTo must be wsa:Anon   but it allows for other EPRs (just not wsa:ReplyTo/FaultTo) to use MCanonURI.

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



"Gilbert Pilz" <Gilbert.Pilz@bea.com>
Sent by: public-ws-policy-request@w3.org

03/01/2007 01:14 PM

To
<tom@coastin.com>
cc
"wsrx" <ws-rx@lists.oasis-open.org>, <public-ws-addressing@w3.org>, "ws policy" <public-ws-policy@w3.org>
Subject
Absence of wsam:NonAnon implies prohibition of non-anon response (was RE: [ws-rx] I just posted a PR comment on MakeConnection Policy assertion)





Tom,

It seems the following policy would be invalid under your model because
there is no wsam:NonAnonymousResponses assertion yet a ReplyTo that
contained an instance of the wsmc:anon URI would be a non-anonymous
response. Do you agree?

<wsp:Policy wsu:Id="RMResponsePolicy">
 <wsp:All>
   <wsam:Addressing>
     <wsp:Policy>
       <wsp:ExactlyOne>
         <wsp:All>
           <wsam:AnonymousResponses/>
         </wsp:All>
       <wsp:ExactlyOne>
     </wsp:Policy>
   </wsam:Addressing>
   <wsmc:MCRequired/>
 </wsp:All>
</wsp:Policy>

- gp

> -----Original Message-----
> From: Tom Rutt [mailto:tom@coastin.com]
> Sent: Wednesday, February 28, 2007 4:18 PM
> To: Gilbert Pilz
> Cc: tom@coastin.com; wsrx; public-ws-addressing@w3.org; ws policy
> 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
>
>
>

smime.p7s



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]