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

+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 Monday, 7 May 2007 13:12:40 UTC