RE: WS-Policy and interopearbility (Was: policy vocabulary, will not be applied, oh my!)

Agreed that ws-policy can indicate something about
requirements/capabilities available. My real question was about how
adhering to "behaviors other than those implied by policy assertions in
a policy alternative will not be engaged" produces interoperability, and
why that semantic should be baked into the framework, rather than be
made in remarks made when explaining a policy domain language's
assertions. It seems to me that if a specific behavior should be
prohibited in order that interoperability occurs, that a specific
negation of a policy should be present to indicate it must not be
combined with the positive assertions. Otherwise it becomes somewhat
vague as to what range of behaviors it is important not to engage for a
given policy alternative.

 

________________________________

From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com] 
Sent: Wednesday, May 09, 2007 3:53 AM
To: Dale Moberg; public-ws-policy@w3.org
Cc: 'David Orchard'; 'Daniel Roth'; 'Christopher B Ferris'
Subject: WS-Policy and interopearbility (Was: policy vocabulary, will
not be applied, oh my!)

 

Hi

 

> Second, I am also puzzled about the emergence of the concern with
interoperability.

 

IMHO it's a very legitimate concern. WS-Policy may enhance the chances
for the interoperability.

May be it's not the main goal of the specs, but the positive side-effect
can be achieved. 

For example, various custom WSDL extensors can be turned into WS-Policy
extensors and then even standardized.

Other example is that often the capabilities are sometimes bundled into
the (WSDL) endpoint extensors, say, security-related ones.

Extracting such capabilities into standalone WS-Policy extensors can
only increase the chance for the interoperability between third-party

clients of a given service

 

Thanks, Sergey 

 

 

 

________________________________

From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Dale Moberg
Sent: 08 May 2007 23:16
To: public-ws-policy@w3.org
Cc: David Orchard; Daniel Roth; Christopher B Ferris
Subject: RE: policy vocabulary, will not be applied, oh my!

 

First, I prefer Monica and Ashok's proposed revisions. I can understand
their proposal. I share Mr. Orchard's concerns about trying to finesse
the difficulties with the original AIN.

 

Second, I am also puzzled about the emergence of the concern with
interoperability.

 

Is it the intention that the ws-policy framework somehow ensure that
when there exist policy alternatives in common between proposer's policy
and consumer's policy, then the proposer and consumer will interoperate?
It seems that there might be a lot of "behavior" not covered by any
policy domain expression that could cause interoperability problems
(like extensions, etc), so it will be very difficult to defend the idea
that agreeing on the same policy alternative ensures interoperability. 

 

Anyway, isn't the WS-I organization one primary forum where conformance
profiles and promotion of WS interoperability is to occur? Our charter
only says that

The Working Group may also:

*	Author a primer that includes guidance on the use of policy
expressions to facilitate Web services interoperability and guidelines
for authoring policy assertions, and 

I don't see that either the framework or attachment documents are
devoted to interoperability. It would be nice if the ws-policy framework
provided a general solution to WS interoperability, but I think that is
taking on some big problems that are not explicitly in scope. Possibly I
misunderstand, however; so I would like to see an explicit statement of
the design intent that connects the policy framework ambitions with WS
interoperability. Maybe that way we can understand the NOBI option's
rationale.

 

 

 

________________________________

From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of David Orchard
Sent: Tuesday, May 08, 2007 2:46 PM
To: Daniel Roth; Ashok Malhotra; Asir Vedamuthu; Christopher B Ferris;
public-ws-policy@w3.org
Subject: RE: policy vocabulary, will not be applied, oh my!

 

I don't get it.  The very precise sentence that you state "If a behavior
isn't implied, then it shouldn't be applied if you want to interop" says
to me AIN.  

 

Now MAYbe you are saying 

AIN: "If a behavior isn't implied, then it MUST not be applied"

and NOBI: "If a behavior isn't implied, then it shouldn't be applied " 

and someother acronym: "If a behavior isn't implied, then it may or may
not be applied as there is no implied behaviour" 

 

is that where we are at?  Then you are disambiguating between AIN and
NOBI by MUST vs SHOULD?

 

Cheers,

Dave

	
________________________________


	From: Daniel Roth [mailto:Daniel.Roth@microsoft.com] 
	Sent: Tuesday, May 08, 2007 2:40 PM
	To: David Orchard; Ashok Malhotra; Asir Vedamuthu; Christopher B
Ferris; public-ws-policy@w3.org
	Subject: RE: policy vocabulary, will not be applied, oh my!

	Hi David,

	 

	NOBI simply means that an alternative implies the behaviors that
are asserted and No Other Behaviors are Implied.  If a behavior isn't
implied, then it shouldn't be applied if you want to interop.  

	 

	Chris' proposal gets us out of the mess of having to consider
policy vocabularies or absent assertions (AIN stuff) in order to
understand what an alternative implies you have to do in order to
interop.

	 

	Daniel Roth

	 

	 

	From: David Orchard [mailto:dorchard@bea.com] 
	Sent: Tuesday, May 08, 2007 1:43 PM
	To: Daniel Roth; Ashok Malhotra; Asir Vedamuthu; Christopher B
Ferris; public-ws-policy@w3.org
	Subject: RE: policy vocabulary, will not be applied, oh my!

	 

	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
		> 
		>