W3C home > Mailing lists > Public > public-ws-policy@w3.org > May 2007

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

From: David Orchard <dorchard@bea.com>
Date: Tue, 8 May 2007 13:42:51 -0700
Message-ID: <4260A18CD3F05B469E67BC6C20464EAC062BC0@rcpbex01.amer.bea.com>
To: "Daniel Roth" <Daniel.Roth@microsoft.com>, "Ashok Malhotra" <ashok.malhotra@oracle.com>, "Asir Vedamuthu" <asirveda@microsoft.com>, "Christopher B Ferris" <chrisfer@us.ibm.com>, <public-ws-policy@w3.org>
Dan,
 
I'm confused about your terms and language.  there are the acronyms NOBI
and NOIB, which I think are the same.  Assuming that, it seems that
there's been a terminology swizzle so that NOBI has become AIN.  AFAICT,
your "For example" is an example of AIN.  
 
Can you tell me how NOBI is different than AIN now?  
 
Cheers,
Dave


________________________________

	From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Daniel Roth
	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_Assert
ions>  
	
	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 20:43:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:34 UTC