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

Sergey, the use case that you are asking for is exactly the use case
that I'm asking for.  I'm becoming convinced that there isn't such a use
case because nobody has been able to mention one in the past week or so.
 
Cheers,
Dave


________________________________

	From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin
	Sent: Wednesday, May 02, 2007 2:19 AM
	To: public-ws-policy@w3.org; Christopher B Ferris
	Subject: Re: policy vocabulary, will not be applied, oh my!
	
	
	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 <mailto:chrisfer@us.ibm.com>

		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