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_type> 
> 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_type> 
> 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_Assertions> 
> 
> 
> 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 Tuesday, 8 May 2007 23:58:05 UTC