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: [ws-rx] 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)



Thanks, Ashok:-)

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295


"Ashok Malhotra" <ashok.malhotra@oracle.com> wrote on 03/01/2007 06:08:34 PM:

> Since this is going into the spec tonight I thought I would fix bugs
> in Chris’ Policy and express a preference for one of his alternatives.

> Essentially I removed the <All> around the single assertion and
> added <wsp:Policy> wrappers around the nesting.

>  
> <wsp:Policy>
>   <wsp:ExactlyOne>
>       <wsa:Addressing>

>        <wsp:Policy>
>               <wsa:AnonymousResponses/>

>          </wsp:Policy>
>       </wsa:Addressing>
>     <wsp:All>
>       <wsa:Addressing>

>           <wsp:Policy>
>                <wsa:NonAnonymousResponses/>

>        </wsp:Policy>
>       </wsa:Addressing>
>       <wsmc:MCSupported/>
>     </ws:All>
>   </wsp:ExactlyOne>
> </wsp:Policy>

>  
> We prefer this alternative because it states explicitly that all
> responses (replies and faults) are governed by NonAnon.

> All the best, Ashok
>
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
> request@w3.org] On Behalf Of Christopher B Ferris
> Sent: Thursday, March 01, 2007 12:00 PM
> To: Gilbert Pilz
> Cc: Doug Davis; public-ws-addressing@w3.org; ws policy; public-ws-
> policy-request@w3.org; tom@coastin.com; wsrx
> Subject: Re: [ws-rx] 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)

>  
>
> <wsp:Policy>
>   <wsp:ExactlyOne>
>     <wsp:All>
>       <wsa:Addressing>
>         <wsa:AnonymousResponses/>
>       </wsa:Addressing>
>     </ws:All>
>     <wsp:All>
>       <wsa:Addressing/>
>       <wsmc:MCSupported/>
>     </ws:All>
>   </wsp:ExactlyOne>
> </wsp:Policy>
>
> I believe that is the policy that you are seeking. One could argue
> that this policy is also
> valid (and consistent with what we are trying to express):
>
> <wsp:Policy>
>   <wsp:ExactlyOne>
>     <wsp:All>
>       <wsa:Addressing>
>         <wsa:AnonymousResponses/>
>       </wsa:Addressing>
>     </ws:All>
>     <wsp:All>
>       <wsa:Addressing>
>         <wsa:NonAnonymousResponses/>
>       </wsa:Addressing>
>       <wsmc:MCSupported/>
>     </ws:All>
>   </wsp:ExactlyOne>
> </wsp:Policy>
>
> Of course, the key is that the nested policy is optional. So, for
> those of you who think that the
> MCanon is inconsistent with wsa:NonAnonymousResponses, then the
> former example might be
> more suitable.
>
> Cheers,
>
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
> phone: +1 508 377 9295
>
> "Gilbert Pilz" <Gilbert.Pilz@bea.com> wrote on 03/01/2007 02:46:40 PM:
>
> > Except for the fact the WS-RM requires the use of WS-Addr . . .
> >  
> > - gp
> >
> > From: Doug Davis [mailto:dug@us.ibm.com]
> > Sent: Thursday, March 01, 2007 10:52 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 agree - it would not give you the semantics you want.  Now, switch
> > the outer "All" with "ExactlyOne" and you'd get it (I think).
> >
> > 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:43 PM
> >
> > To
> >
> > Doug Davis/Raleigh/IBM@IBMUS
> >
> > cc
> >
> > <public-ws-addressing@w3.org>, "ws policy" <public-ws-policy@w3.
> > org>, <public-ws-policy-request@w3.org>, <tom@coastin.com>, "wsrx"
> > <ws-rx@lists.oasis-open.org>
> >
> > Subject
> >
> > RE: Absence of wsam:NonAnon implies prohibition of non-anon response
> > (was RE: [ws-rx] I just posted a PR comment on MakeConnection
> Policyassertion)
> >
> >
> >
> >
> > I agree that, at a shallow level, the policy is 'valid'. However, if
> > I wanted to indicate to clients that they must use ReplyTo
> addressesthat 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
> Policyassertion)
> >
> >
>
> >
> >
> >
> >
> >
> > 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
> > >
> > >
> > >


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