Re: Are nested assertions part of the policy vocabulary?

+1, what you see is what you know based on definition of assertions.

regards, Frederick

Frederick Hirsch
Nokia


On May 9, 2007, at 9:15 AM, ext Bob Freund wrote:

> The WS-Policy Spec simply defines a way to express and compare  
> (intersect, gosh I dislike that term) sets of metadata. It may  
> imply a bunch of other stuff, but I think that to the extent that  
> it does it oversteps.
>
> It is mandatory that the adjunct specs which define assertions for  
> a particular protocol  define which behaviors are intended in  
> conjunction with the underlying protocol spec.
>
> I might have preferred that WS-Policy define a wildcard policy  
> expression for readability, but it doesn’t matter that much IMO  
> since an empty policy is a policy none the less and optional=”true”  
> reduces the verbosity somewhat.
>
> How does one express “default” behavior?  Well, one way is to  
> define an assertion that connotes default, another is to express  
> nothing which might also connote default behavior.
>
> I really feel that it needs be up to the protocol writers to define  
> what that default behavior is and it cannot be subject to absence =  
> negation rules.  I think that if nothing is expressed, nothing is  
> expressed and nothing more.
>
> To the absence equals negation faction, the absence of the default  
> assertion, should it be defined, means what?
>
> Must there be an empty compatible policy for default behavior to be  
> exhibited?
>
> I think not, since just because policy exists, it will be tough to  
> require policy at least foe awhile.  Protocol authors and  
> implementers will find it necessary to work with clients or servers  
> that might be policy naive.   We still are forced to define a fault  
> mechanism and not only for this.
>
> The less that WS-Policy says about behavior, the better. Let it do  
> the simple and needed job of defining what a policy looks like and  
> how they might be compared in an optional application independent  
> manner.
>
>
>
> -bob
>
>
>
> From: public-ws-addressing-request@w3.org [mailto:public-ws- 
> addressing-request@w3.org] On Behalf Of Sergey Beryozkin
> Sent: Wednesday, May 09, 2007 4:40 AM
> To: 'Daniel Roth'; Bob Freund; 'Ashok Malhotra'; 'Maryann Hondo';  
> 'Anthony Nadalin'
> Cc: public-ws-addressing@w3.org; public-ws-policy@w3.org
> Subject: RE: Are nested assertions part of the policy vocabulary?
>
>
>
> Hi Dan
>
>
>
> “In some cases a single message may specify both an anonymous  
> ReplyTo EPR and a non-anonymous FaultsTo EPR.  To satisfy this  
> scenario you need to have some way of saying that addressing is  
> fully supported without qualifications”.
>
>
>
> This is the point I’ve missed. It’s the fact that a *single*  
> message may specify both types which makes an empty <Policy>  
> expression a useful alternative.
>
> IMHO, highlighting it in the wsa-addressing policy profile would  
> help. Otherwise it’s very tempting to use an empty <Policy>  
> expression alone to meet different client’s
>
> requirements for a more qualified support…
>
>
>
> Thanks for the explanation
>
> Sergey
>
>
>
>
>
>
>
> From: Daniel Roth [mailto:Daniel.Roth@microsoft.com]
> Sent: 08 May 2007 21:26
> To: Sergey Beryozkin; Bob Freund; Ashok Malhotra; Maryann Hondo;  
> Anthony Nadalin
> Cc: public-ws-addressing@w3.org; public-ws-policy@w3.org
> Subject: RE: Are nested assertions part of the policy vocabulary?
>
>
>
> Hi Sergey,
>
>
>
> > According to [1] If the provider uses <Policy/> then it means  
> this provider will work with consumers using either anonymous or  
> non-anonymous WSA qualifications.
>
> > And yet, the requester saying, by using <ws- 
> addressing><Policy><AnonymousResponses/></Policy></ws-addressing>,  
> that it wishes a provider to support
>
> > <AnonymousResponses/> will fail to intersect with the provider  
> using <Policy/> which says that all types of responses are supported
>
>
>
> A client that requires a service that supports anonymous responses  
> will work with a service that supports all of addressing or just  
> anonymous responses.  This means, the client should reflect that by  
> including both alternatives in its policy.  The client policy with  
> both alternatives intersects with the service policy and is  
> specifically recommended in section 3.6.1 of the WS-Addressing  
> Metadata spec.
>
>
>
> > I'd even say that the empty nested ws-adressing <Policy> should  
> be prohibited
>
>
>
> In some cases a single message may specify both an anonymous  
> ReplyTo EPR and a non-anonymous FaultsTo EPR.  To satisfy this  
> scenario you need to have some way of saying that addressing is  
> fully supported without qualifications.
>
>
>
> I hope this helps.
>
>
>
> Daniel Roth
>
>
>
>
>
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> Sent: Tuesday, May 08, 2007 2:25 AM
> To: Bob Freund; Daniel Roth; Ashok Malhotra; Maryann Hondo; Anthony  
> Nadalin
> Cc: public-ws-addressing@w3.org; public-ws-addressing- 
> request@w3.org; public-ws-policy@w3.org; public-ws-policy- 
> request@w3.org
> Subject: Re: Are nested assertions part of the policy vocabulary?
>
>
>
> Hi
>
>
>
> What confuses me is that it appears to be some inconsistency in the  
> definition of what the empty nested Policy means in the scope of ws- 
> addressing (see [1]), <ws-addressing><Policy/></ws-addressing> and  
> the fact that this nested <Policy> does not intersect with a more  
> qualified nested Policy such as <ws- 
> addressing><Policy><AnonymousResponses/></Policy></ws-addressing>.
>
>
>
> According to [1] If the provider uses <Policy/> then it means this  
> provider will work with consumers using either anonymous or non- 
> anonymous WSA qualifications. And yet, the requester saying, by  
> using <ws-addressing><Policy><AnonymousResponses/></Policy></ws- 
> addressing>, that it wishes a provider to support   
> <AnonymousResponses/> will fail to intersect with the provider  
> using <Policy/> which says that all types of responses are  
> supported...
>
>
>
> I think what this means is using an all inclusive <Policy>  
> alternative alone on the server is just not safe as it will cause  
> compliant clients (say those wishing a provider to support  
> <AnonymousResponses/>) to break...I'd even say that the empty  
> nested ws-adressing <Policy> should be prohibited...Just have two  
> nested policies, one allowing anonymous responses, another one  
> allowing non-anonymous ones...That way a provider supporting all  
> types of responses can list two alternatives and it will match all  
> clients....
>
>
>
>
>
> Thanks, Sergey
>
>
>
> [1] http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/ 
> att-0094/WSAddrPolicyAlgerntiveGprime.htm
>
> ----- Original Message -----
>
> From: Bob Freund
>
> To: Daniel Roth ; Ashok Malhotra ; Maryann Hondo ; Anthony Nadalin
>
> Cc: public-ws-addressing@w3.org ; public-ws-addressing- 
> request@w3.org ; public-ws-policy@w3.org ; public-ws-policy- 
> request@w3.org
>
> Sent: Tuesday, May 08, 2007 12:22 AM
>
> Subject: RE: Are nested assertions part of the policy vocabulary?
>
>
>
> +1
>
> From a plain reading of the WS-Policy intersection algorithm, these  
> policies indeed are not compatible per the WS-Policy 1.5 framework  
> CR spec.
>
> -bob
>
>
>
> From: public-ws-addressing-request@w3.org [mailto:public-ws- 
> addressing-request@w3.org] On Behalf Of Daniel Roth
> Sent: Tuesday, May 01, 2007 4:52 PM
> To: Ashok Malhotra; Maryann Hondo; Anthony Nadalin
> Cc: public-ws-addressing@w3.org; public-ws-addressing- 
> request@w3.org; public-ws-policy@w3.org; public-ws-policy- 
> request@w3.org
> Subject: RE: Are nested assertions part of the policy vocabulary?
>
>
>
> Hi Ashok,
>
>
>
> These two policies do not intersect and we believe this is verified  
> in the test cases.  If Policy 2 is the policy for a requester then  
> this intersection result may at first seem incorrect, so let me  
> explain:
>
>
>
> It is incumbent on the Addressing authors to specify the semantics  
> of the assertions.  The Addressing assertion expresses a  
> requirement that WS-Addressing be used to exchange messages without  
> qualifications.  The nested addressing assertions (which indicate  
> additional characteristics of  the base WS-Addressing assertion)   
> qualify this semantic to say that either only non-anonymous  
> responses are supported or that only anonymous responses are  
> supported.  In the WS-Addressing protocol it’s the requester’s  
> message that requests a specific kind of response – anonymous, non- 
> anonymous, or maybe even a mixture of the two.
>
>
>
> The thing to recognize is that if Policy 2 is a requester policy  
> then it is incomplete in that it is not acknowledging that the base  
> assertion also reflects support for anonymous responses.  The  
> requester determines what response type should be used.  So, a  
> client that needs non-anonymous responses will also work with a  
> service that supports all of addressing.   The client’s policy  
> should reflect that  it is compatible with an endpoint that  
> supports all of addressing by adding a second alternative.  This  
> can be easily done using the Optional attribute as is shown in  
> section 3.1.6 in the WS-Addressing Metadata spec:
>
>               <Policy><Addressing ><Policy><AnonymousResponses  
> wsp:Optional=”true” > </Policy></Addressing ></Policy>
>
>
>
> Note that if Policy 2 is a provider policy and Policy 1 is the  
> requester policy – where the requester wants unqualified support  
> for addressing, but the provider only supports a specific response  
> type – then there is no issue.  These policies should not intersect  
> and they don’t.
>
>
>
> We hope this helps.
>
>
>
> Daniel Roth
>
>
>
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy- 
> request@w3.org] On Behalf Of Ashok Malhotra
> Sent: Thursday, April 19, 2007 12:33 PM
> To: Maryann Hondo; Anthony Nadalin
> Cc: public-ws-addressing@w3.org; public-ws-addressing- 
> request@w3.org; public-ws-policy@w3.org; public-ws-policy- 
> request@w3.org
> Subject: RE: Are nested assertions part of the policy vocabulary?
>
>
>
> Hi Maryann:
>
> Perhaps I misunderstood.  Let me rephrase my comments as questions.
>
>
>
> Since Policy 1
>
> <Policy>
> <ws-addressing>
> <Policy/>
> </ws-addressing>
> </Policy>
> was intended to mean that ALL options ( anonymous, non-anonymous)  
> are supported.
>
>
>
> And Policy 2
>
> <Policy>
> <ws-addressing>
> <Policy>
> <ws-addressing: Anonymous>
> </Policy>
> </ws-addressing>
> </Policy>
> was intended to mean that  ONLY anonymous was supported.
>
> Should Policy 1 match Policy 2 in the intersection algorithm?
>
> All the best, Ashok
>
> From: public-ws-addressing-request@w3.org [mailto:public-ws- 
> addressing-request@w3.org] On Behalf Of Maryann Hondo
> Sent: Thursday, April 19, 2007 5:55 AM
> To: Ashok Malhotra; Anthony Nadalin
> Cc: Ashok Malhotra; public-ws-addressing@w3.org; public-ws- 
> addressing-request@w3.org; public-ws-policy@w3.org; public-ws- 
> policy-request@w3.org
> Subject: RE: Are nested assertions part of the policy vocabulary?
>
>
>
>
> Ashok,
> I would like to clarify my comments.
>
> I was trying to say, that the WS-Addressing group seemed to be  
> trying to use nested assertions to indicate a "constraint".
> My understanding of the semantics are the following:
> <Policy>
> <ws-addressing>
> <Policy/>
> </ws-addressing>
> </Policy>
> was intended to mean that ALL options ( anonymous, non-anonymous)  
> are supported.
>
> and
> <Policy>
> <ws-addressing>
> <Policy>
> <ws-addressing: Anonymous>
> </Policy>
> </ws-addressing>
> </Policy>
> was intended to mean that  ONLY anonymous was supported.
>
> This to me, ths meant that the "intent" of the base assertion was  
> being "constrained" by the presence off a nested assertion
> and that was ok if the working group understood the semantics they  
> were expressing ( i.e. the "absence" of a nested assertion
> means "no constraints" or "all options are supported")
>
>  and I thought the language of the ws-policy spec allowed this  
> interpretation since  a nested assertion could be seen to be
> qualifying the base assertion with a constraint rather than a  
> capability.
>
> Authors MAY define that an assertion contains a policy expression  
> (as defined in 4. Policy Expression) as one of its[children].  
> Nested policy expression(s) are used by authors to further qualify  
> one or more specific aspects of the original assertion.
>
>
> The spec already says the following so I don't think alternative 1  
> really adds anything, unless I'm missing something, like Tony, I  
> need more of an explanation of what you are suggesting you want the  
> intersection to do:
>
> Because the set of behaviors indicated by a policy alternative  
> depends on the domain-specific semantics of the collected  
> assertions, determining whether two policy alternatives are  
> compatible generally involves domain-specific processing.
>
> Maryann
>
> Anthony Nadalin/Austin/IBM@IBMUS
> Sent by: public-ws-addressing-request@w3.org
>
> 04/19/2007 03:41 AM
>
> To
>
> "Ashok Malhotra" <ashok.malhotra@oracle.com>
>
> cc
>
> "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>,  
> "public-ws-policy@w3.org" <public-ws-policy@w3.org>, public-ws- 
> policy-request@w3.org
>
> Subject
>
> RE: Are nested assertions part of the policy vocabulary?
>
>
>
>
>
>
>
>
>
>
> #1 " dependent on the semantics of the parent assertion." not sure  
> what this would mean can you give some guidance here ?
> #2 is real dangerous as you have no idea what you are matching on,  
> one day it could be XYZ and another day it could be ABC.
>
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> <image001.gif>
> ">"Ashok Malhotra" <ashok.malhotra@oracle.com>
>
> "Ashok Malhotra" <ashok.malhotra@oracle.com>
> Sent by: public-ws-policy-request@w3.org
>
> 04/16/2007 04:23 PM
>
>
>
> <image002.gif>
>
>
> To
>
> <image002.gif>
>
> "public-ws-policy@w3.org" <public-ws-policy@w3.org>, "public-ws- 
> addressing@w3.org" <public-ws-addressing@w3.org>
>
> <image002.gif>
>
>
> cc
>
> <image002.gif>
>
> <image002.gif>
>
>
> Subject
>
> <image002.gif>
>
> RE: Are nested assertions part of the policy vocabulary?
>
>
>
> <image002.gif>
>
> <image002.gif>
>
>
>
> I’m at the OASIS Symposium and have had extensive discussions with  
> the WS-Addressing folks re. the problems they are having in using  
> WS-Policy to express their requirements.
>
> As I see it, the sticky usecase is where the provider wants to say  
> this it supports WS-Addressing in all its manifestations and the  
> requester specifies that it supports a particular variation of WS- 
> Addressing. These two policies must match. Thus, the provider says:
>
> <Policy>
> <ws-addressing>
> <Policy/>
> </ws-addressing>
> </Policy>
>
> And the requester says:
>
> <Policy>
> <ws-addressing>
> <Policy>
> <ws-addressing-specific-assertions>
> </Policy>
> </ws-addressing>
> </Policy>
>
> These two policies must match in the intersection algorithm. The  
> text that prevents them from matching says:
>
> “If either assertion contains a nested policy expression, the two  
> assertions are compatible if they both have a nested policy  
> expression and the alternative in the nested policy expression of  
> one is compatible with the alternative in the nested policy  
> expression of the other.”
>
> In the note below (which Glen +1ed), Maryann suggests that a Policy  
> with just the <ws-addressing> assertion is expressing a constraint  
> which can be met in several ways – at least that’s how I read her  
> note. She does not, however, suggest concrete wording. Here are a  
> couple of suggestions:
> 1. Change the quoted text above to say that matching of nested  
> policy assertions is dependent on the semantics of the parent  
> assertion. This way, WS-Addressing could define its own semantics  
> for matching and solving their usecase.
> 2. Bob Freund suggested a wildcard assertion that could be included  
> within a nested Policy that would match any other nested policy.
>
> All the best, Ashok
>
>
>
>
> From: Maryann Hondo [mailto:mhondo@us.ibm.com]
> Sent: Wednesday, April 04, 2007 7:37 AM
> To: Glen Daniels
> Cc: Ashok Malhotra; Monica J. Martin; public-ws-policy@w3.org;  
> public-ws-policy-request@w3.org
> Subject: RE: Are nested assertions part of the policy vocabulary?
>
>
> Glen,
> I think the problem is that the assertions are really trying to  
> express a constraint .....and should be something
> like "nonAnonymousONLY". so the absence, is not the absence of  
> support but rather the absence of the constraint.
>
> And in this case I think the " no constraints" is sufficient for  
> your use case
> The client has no constraints on what the provider will do.
> That should intersect with all the provider options.
>
> I hope we can talk this through on the call.
> Maryann
>
> "Glen Daniels" <gdaniels@progress.com>
> Sent by: public-ws-policy-request@w3.org
>
> 04/04/2007 09:59 AM
>
>
>
> To
>
> "Monica J. Martin" <Monica.Martin@Sun.COM>, "Ashok Malhotra"  
> <ashok.malhotra@oracle.com>
>
> cc
>
> <public-ws-policy@w3.org>
>
> Subject
>
> RE: Are nested assertions part of the policy vocabulary?
>
>
>
>
>
>
>
>
>
>
>
> Hi Monica:
>
> I'm a little confused here. Are you and MaryAnn indeed saying that
> selecting the first alternative in Ashok's (and indeed WS- 
> Addressing's)
> example means that neither anonymous nor non-anonymous responses are
> allowed? That certainly isn't the goal of the policy, and indeed this
> interpretation would seem to disallow ANY kind of response.
>
> How would you write a consumer policy which was meant to successfully
> intersect with endpoint policies which either a) express nothing about
> anonymous responses, b) express a requirement for anonymous responses,
> or c) express a requirement for non-anonymous responses?
>
> --Glen
>
> > -----Original Message-----
> > From: public-ws-policy-request@w3.org
> > [mailto:public-ws-policy-request@w3.org] On Behalf Of Monica J.  
> Martin
> > Sent: Tuesday, April 03, 2007 5:30 PM
> > To: Ashok Malhotra
> > Cc: public-ws-policy@w3.org
> > Subject: Re: Are nested assertions part of the policy vocabulary?
> >
> >
> >
> > hondo: Ashok,
> > My response is yes.
> > Maryann
> >
> > >>mm1: Ashok, agree with MaryAnn on question one answer - this point
> > has been made that the nested assertions are part of the policy
> > vocabulary. Yet, an important point associated with this surrounds
> > whether or not the guiding conformance [1] requires support for  
> those
> > response types - that provides substance on your second
> > question and its
> > disposition.. [2]
> >
> > We also state in Section 3.2 Framework before the statement you  
> cite:
> >
> > An alternative with zero assertions indicates no behaviors. An
> > alternative with one or more assertions indicates
> > behaviors implied
> > by those, and only those assertions.
> >
> > Remember: (no position just stating the action-result), we augmented
> > this text in
> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=3602 Issue 3602.
> >
> > [1] WS-A specification(s) referenced
> > [2] Related to empty and the base assumptions of WS-Addressing.
> >
> > >Ashok Malhotra wrote: Section 3.2 of Framework says "When an
> > assertion whose type is part of the policy's vocabulary is
> > not included in a policy alternative, the policy alternative
> > without the assertion type indicates that the assertion will
> > not be applied in the context of the attached policy
> > subject." Are nested assertions included in the policy's
> > vocabulary?
> > >
> > >Consider the following example:
> > >
> > > <wsp:ExactlyOne>
> > > <wsp:All>
> > > <wsam:Addressing> <-- supports all response
> > types --> Alternative 1
> > > <wsp:Policy>
> > > </wsp:Policy>
> > > </wsam:Addressing>
> > > </wsp:All>
> > > <wsp:All>
> > > <wsam:Addressing> <-- requires Anonymous
> > responses --> Alternative 2
> > > <wsp:Policy>
> > > <AnonymousResponses />
> > > </wsp:Policy>
> > > </wsam:Addressing>
> > > </wsp:All>
> > > <wsp:All>
> > > <wsam:Addressing> <- requires nonAnonymous
> > responses --> Alternative 3
> > > <wsp:Policy>
> > > <NonAnonymousResponses />
> > > </wsp:Policy>
> > > </wsam:Addressing>
> > > </wsp:All>
> > > </wsp:ExactlyOne>
> > ></wsp:Policy>
> > >
> > >If Alternative 1 is selected, does this mean that neither
> > Anonymous responses nor NonAnonymous responses are allowed as
> > both are part of the policy vocabulary but not included in
> > the alternative.
> > >
> > >All the best, Ashok
> > >
> > >
> > >
> >
> >
> >
> >
> <image003.gif>
>
>

Received on Wednesday, 9 May 2007 14:33:29 UTC