RE: policy vocabulary, will not be applied, oh my!

Also, if you leave out optional behaviors out of your policy then
requesters than can only do the optional behaviour won't know to enable
those behaviors...

Cheers,
Dave 

> -----Original Message-----
> From: public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] On Behalf Of Daniel Roth
> Sent: Tuesday, May 08, 2007 5:14 PM
> To: Anish Karmarkar
> Cc: Ashok Malhotra; Asir Vedamuthu; Christopher B Ferris; 
> public-ws-policy@w3.org
> Subject: RE: policy vocabulary, will not be applied, oh my!
> 
> 
> Hi Anish,
> 
> > is policy always meant to be complete?
> 
> If you leave required behaviors out of your policy, then 
> requesters won't know to enable those behaviors and 
> intersection results won't be meaningful.
> 
> Daniel Roth
> 
> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> Sent: Tuesday, May 08, 2007 4:54 PM
> To: Daniel Roth
> Cc: Ashok Malhotra; Asir Vedamuthu; Christopher B Ferris; 
> public-ws-policy@w3.org
> Subject: Re: policy vocabulary, will not be applied, oh my!
> 
> Curious: is policy always meant to be complete?
> For example, in the case where there is only one alternative, 
> is there no unstated behavior?
> 
> -Anish
> --
> 
> Daniel Roth wrote:
> > Hi Ashok,
> >
> >
> >
> > The problem with "no claims" is that you no longer know if 
> a policy is 
> > complete or not (there may be unstated behaviors), which 
> means you can 
> > never be sure if you are going to interoperate.
> >
> >
> >
> > Daniel  Roth
> >
> >
> >
> >
> >
> > *From:* Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
> > *Sent:* Tuesday, May 08, 2007 2:18 PM
> > *To:* Daniel Roth; Asir Vedamuthu; Christopher B Ferris; 
> > public-ws-policy@w3.org
> > *Subject:* RE: policy vocabulary, will not be applied, oh my!
> >
> >
> >
> > Thanks, Dan, for clarifying.
> >
> >
> >
> > So, NOBI has implied negation.  We would rather not have 
> this.  Here 
> > is how I would phrase it.  Monica also suggested explicit phrasing.
> >
> >
> >
> > An alternative should express exactly those behaviors that are 
> > indicated by its assertions and make no claims about other 
> assertions.
> >
> >
> >
> > All the best, Ashok
> >
> > 
> ----------------------------------------------------------------------
> > --
> >
> > *From:* Daniel Roth [mailto:Daniel.Roth@microsoft.com]
> > *Sent:* Tuesday, May 08, 2007 1:35 PM
> > *To:* Ashok Malhotra; Asir Vedamuthu; Christopher B Ferris; 
> > public-ws-policy@w3.org
> > *Subject:* RE: policy vocabulary, will not be applied, oh my!
> >
> >
> >
> > Hi Ashok,
> >
> >
> >
> > Chris' proposal is actually exactly what I meant by NOBI.  An 
> > alternative should express exactly those behaviors that are 
> needed for 
> > interop and nothing else should be done.
> >
> >
> >
> > For example, if I have an alternative that says I require message 
> > security, then requesters should not also enable transport security 
> > and expect to interoperate.
> >
> >
> >
> > Chris' proposal looks good to me.
> >
> >
> >
> > Daniel Roth
> >
> >
> >
> > *From:* public-ws-policy-request@w3.org 
> > [mailto:public-ws-policy-request@w3.org] *On Behalf Of 
> *Ashok Malhotra
> > *Sent:* Tuesday, May 08, 2007 11:42 AM
> > *To:* Asir Vedamuthu; Christopher B Ferris; public-ws-policy@w3.org
> > *Subject:* RE: policy vocabulary, will not be applied, oh my!
> >
> >
> >
> > So, Asir, just to be clear, this position is different from 
> the NOIB 
> > (No Implied Behavior) that Dan espoused on last Wednesday's call.
> >
> >
> >
> > All the best, Ashok
> >
> > 
> ----------------------------------------------------------------------
> > --
> >
> > *From:* public-ws-policy-request@w3.org 
> > [mailto:public-ws-policy-request@w3.org] *On Behalf Of 
> *Asir Vedamuthu
> > *Sent:* Tuesday, May 08, 2007 9:22 AM
> > *To:* Christopher B Ferris; public-ws-policy@w3.org
> > *Subject:* RE: policy vocabulary, will not be applied, oh my!
> >
> >
> >
> > +1
> >
> >
> >
> > An alternative with one or more assertions indicates 
> behaviors implied 
> > by those, and only those assertions. If a policy 
> alternative does not 
> > specify a behavior then the alternative means the behavior 
> is not applied.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Asir S Vedamuthu
> >
> > Microsoft Corporation
> >
> >
> >
> >
> >
> > *From:* public-ws-policy-request@w3.org 
> > [mailto:public-ws-policy-request@w3.org] *On Behalf Of 
> *Christopher B 
> > Ferris
> > *Sent:* Tuesday, May 08, 2007 5:01 AM
> > *To:* public-ws-policy@w3.org
> > *Subject:* Re: policy vocabulary, will not be applied, oh my!
> >
> >
> >
> >
> > All,
> >
> > I've been thinking about this, and possible language that 
> would make 
> > things clear to the reader that an alternative's set of assertions 
> > implies that ONLY those behaviors implied by those assertions are 
> > applied in the context of an interchange governed by that policy 
> > alternative.
> >
> > Also, since there isn't an issue to go with this thread, and it may 
> > well end up with CR edits to the spec, I opened an issue (4544) in 
> > Bugzilla:
> >
> >         http://www.w3.org/Bugs/Public/show_bug.cgi?id=4544
> >
> > The first paragraph in section 3.2 of the Framework currently reads:
> >
> > [Definition: A *policy alternative* is a potentially empty 
> collection 
> > of policy assertions 
> > 
> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_assertion>.] 
> > An alternative with zero assertions indicates no behaviors. An 
> > alternative with one or more assertions indicates behaviors 
> implied by 
> > those, and only those assertions. [Definition: A *policy 
> vocabulary* 
> > is the set of all policy assertion types 
> > 
> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_assertion_typ
> > e> used in a policy.] [Definition: A *policy alternative 
> vocabulary* 
> > is the set of all policy assertion types 
> > 
> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_assertion_typ
> > e>
> > within the policy alternative
> > 
> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_alternative>.
> > ] 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. See the example 
> in Section
> > *4.3.1 Optional Policy Assertions*
> > 
> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#Optional_Policy_Asse
> > rtions>
> >
> >
> > I would propose the following change:
> >
> > [Definition: A *policy alternative* is a potentially empty 
> collection 
> > of policy assertions 
> > 
> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_assertion>.] 
> > An alternative with zero assertions indicates no behaviors. An 
> > alternative with one or more assertions indicates behaviors 
> implied by 
> > those, and only those assertions. No other behaviors are to 
> be applied 
> > for the alternative.
> >
> > The rest of the edits in the original proposal [1] remain unchanged.
> >
> > [1] 
> > 
> http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0003.html
> >
> > 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
> >
> > public-ws-policy-request@w3.org wrote on 05/07/2007 09:07:16 AM:
> >
> >>
> >>  +1,
> >>
> >>  (Thanks Chris, for providing an example. Makes it much 
> clearer for  
> >> understanding issue.)
> >>
> >>  regards, Frederick
> >>
> >>  Frederick Hirsch
> >>  Nokia
> >>
> >>
> >>  On May 2, 2007, at 5:19 AM, ext Sergey Beryozkin wrote:
> >>
> >>  > Hi Chris
> >>  >
> >>  > Would it be possible to post an example which would show a  > 
> >> realistic scenario where it's obvious the fact that the input  > 
> >> policy vocabulary is not included in the effective policy's  > 
> >> vocabulary may cause the problems for a client ? I just find it  > 
> >> difficult to understand the reasoning when policies A&B 
> are used in  
> >> > examples :-)  >  > Also, I don't understand why the 
> client can not 
> >> use the effective  > policy's vocabulary as the guidance on what 
> >> assertions can be  > applied. The fact that many more assertions 
> >> might've been involved  > in the intersection seems unimportant to 
> >> me, the client can not  > apply what the effective policy has now, 
> >> that is whatever  > assertions are in the selected alternative. I 
> >> think this is what  > Monica said in the other email (sorry if 
> >> misinterpreted that email  > reply).
> >>  >
> >>  > I hope the practical example will help to understand 
> the problem  
> >> > better  >  > Thanks, Sergey  > ----- Original Message -----  > 
> >> From: Christopher B Ferris  > To: public-ws-policy@w3.org  > Sent: 
> >> Tuesday, May 01, 2007 9:22 PM  > Subject: policy 
> vocabulary, will not 
> >> be applied, oh my!
> >>  >
> >>  >
> >>  > There are some related issues/questions/concerns that 
> have been  > 
> >> expressed by members  > of the WG with regards the framework 
> >> specification as it relates to  > the "will not be 
> applied" principle  
> >> > and the definions for "policy vocabulary", etc. Below, I have  > 
> >> enumerated these issues  > and suggest a path forward to address 
> >> those concerns.
> >>  >
> >>  > 1. The definition of "policy vocabulary" is 
> incompatible with  > 
> >> intersected policy as regards to  > the "will not be applied" 
> >> principle because post intersection, the  > resultant policy 
> >> expression  > does not carry the policy vocabulary of the input 
> >> policy  > expressions. Hence, if a provider  > had two 
> alternatives, 
> >> one with Foo and one without Foo, and the  > result of 
> intersection 
> >> determined  > that the alternative without Foo was 
> compatible with a 
> >> client's  > policy, then the resultant  > policy 
> expression would not 
> >> have in its vocabulary (as computed  > using the algorithim  > 
> >> currently specified) Foo and hence it would not be clear 
> whether  > 
> >> Foo carries with it  > the "will not be applied" semantic.
> >>  >
> >>  > Action-283 - 
> http://lists.w3.org/Archives/Public/public-ws-policy/
> >>  > 2007Apr/0103.html
> >>  > Action-284 - 
> http://lists.w3.org/Archives/Public/public-ws-policy/
> >>  > 2007Apr/0106.html
> >>  > Ashok email - 
> >> http://lists.w3.org/Archives/Public/public-ws-policy/
> >>  > 2007Apr/0065.html
> >>  >
> >>  > 2. There is a degree of confusion regarding the "will not be  > 
> >> applied" semantic as it applies to nested policy.
> >>  > This is related to the interpretation of "policy 
> vocabulary" that  
> >> > many held prior to the clarification provided by  > 
> Microsoft  >  > 
> >> Asir's email on nested policy vocabulary - http://lists.w3.org/  > 
> >> Archives/Public/public-ws-policy/2007Apr/0017.html
> >>  >
> >>  > 3. As a result, a number of email threads have sprung 
> up that  > 
> >> question the merits of the "will not be applied"
> >>  > semantic.
> >>  >
> >>  > Ashok - http://lists.w3.org/Archives/Public/public-ws-policy/
> >>  > 2007Apr/0065.html
> >>  > Dale - 
> >> http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/
> >>  > 0075.html
> >>  > Ashok - http://lists.w3.org/Archives/Public/public-ws-policy/
> >>  > 2007Apr/0101.html
> >>  > Dale - 
> >> http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/
> >>  > 0108.html
> >>  >
> >>  > It may be that the most prudent course forward would be to drop 
> >> the  > "will not be applied" semantic as relates  > policy 
> >> vocabulary. As a result, there is little need of a normative  > 
> >> definion for policy vocabulary or policy alternative  > 
> vocabulary, 
> >> as these definitions only served to allow one to  > 
> determine whether 
> >> the behavior implied by a  > given assertion carried the 
> "will not be 
> >> applied" semantic.
> >>  >
> >>  > Instead, we could simply state that the behavior 
> implied by an  > 
> >> assertion that is absent from a given alternative  > is not to be 
> >> applied in the context of the attached policy subject  > when that 
> >> alternative is engaged.
> >>  > This would provide clearer semantic (I believe) to 
> borth assertion  
> >> > and policy authors.
> >>  >
> >>  > The attached mark-up of the policy framework specification 
> >> contains  > the changes that I believe would  > be necessary to 
> >> affect this change.
> >>  >
> >>  > Impact analysis:
> >>  >
> >>  > - The proposed change does not affect the XML syntax  > 
> - Nor does 
> >> it impact the semantics of the namespace, therefore the  > 
> namesapce 
> >> URI can remain unchanged  > - It does not affect the 
> processing model 
> >> (normalization,  > intersection)  > - It does not impact testing 
> >> results to date  > - It does not affect any of the assertion 
> >> languages developed to date  >  > The related questsion 
> that needs to 
> >> be asked should we choose to  > adopt this proposal is:
> >>  >
> >>  >         Does this change affect any implementations?
> >>  >
> >>  > From analysis of the set of test cases, the answer is 
> not clear,  
> >> > because there were no tests that  > excercised either policy 
> >> vocabulary or the "will not be applied"
> >>  > semantic. Thus, it would be important that  > we check our 
> >> respective implementations to ascertain whether there  > 
> would be any 
> >> impact. From an IBM  > perspective, this change does not 
> impact our 
> >> implementation.
> >>  >
> >>  >
> >>  >
> >>  > 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
> >>
> >>
> >
> 
>

Received on Wednesday, 9 May 2007 16:26:09 UTC