RE: ISSUE 3564: Optional Assertions may not be usable in all cir cumstances

+1


________________________________

	From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Christopher B
Ferris
	Sent: Thursday, Sep 28, 2006 10:17 AM
	To: Frederick Hirsch
	Cc: Frederick Hirsch; ext Glen Daniels; public-ws-policy@w3.org;
public-ws-policy-request@w3.org; ext Sergey Beryozkin
	Subject: Re: ISSUE 3564: Optional Assertions may not be usable
in all cir cumstances
	
	

	Frederick wrote: 
	
	> I think we are getting lost with the words "capability" and  
	> "requirement" when I suspect the original meaning was very
simple:  
	> clients have capabilities expressed by policy, providers have

	> requirements expressed by policy, and an intersection
indicates a  
	> match of capabilities and requirements. 
	
	Taking my chair hat off to engage in some technical discourse...

	
	<hat mode="off"> 
	Actually, providers have capabilities and clients have
requirements at times. An example of this 
	is reliable messaging. Typically, it is the consumer/client that
wants to ensure that a message is 
	delivered. Thus, the WS-RX RM Policy assertion is typically
expressed as wsp:Optional='true' 
	by the provider, to indicate that it supports the capability
expressed by that assertion. The client would 
	then express a single alternative, either with, or without the
wsrm:RMAssertion for intersection purposes. 
	If present, then it requires RM. If absent, then it doesn't. If
both express with wsp:Optional='true' then 
	something else needs to factor into the intersection to select
the preferred alternative (although we haven't 
	got anything in the framework for that, but it can be handled
outside the framework one would expect). 
	
	The tricky case comes into play when policy is used to express a
provider-only assertion such as 
	auditing, which is not manifested on the wire, and which the
client really doesn't need to understand/comply with 
	in order to interact with the service provider. 
	
	I think that the question becomes, do we want/need WS-Policy to
be able to handle such cases where a 
	policy subject is decorated wth a policy alternative that
includes an assertion that is relevant only to 
	one of the participants in the interaction/exchange? 
	
	Given that there are other mechanisms by which a particpant role
(consumer or provider) can be configured 
	to effect a capability as a requirement of processing
(deployment descriptors and the like), I would think that 
	maybe we should consider any expression of unilateral
"requirements" as a v.next item. What is most important 
	is that we enable the framework such that a provider can
communicate to the client those capabilities that 
	it supports and the set of those capabilities that are required
for successful interaction from the perspective 
	of both the provider and the consumer of a service. 
	</hat> 
	
	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 09/28/2006 09:10:20 AM:
	
	> 
	> I think we are getting lost with the words "capability" and  
	> "requirement" when I suspect the original meaning was very
simple:  
	> clients have capabilities expressed by policy, providers have

	> requirements expressed by policy, and an intersection
indicates a  
	> match of capabilities and requirements.
	> 
	> This is different from the concept of a client not needing to
process  
	> or be aware of provider assertions that do not impact what is
on the  
	> wire, and removing/ignoring these advisory assertions from the

	> provider policy before/when performing intersection.
	> 
	> However a point made later in the thread indicates that a
client  
	> still must understand these, which I think is also your point
Sergey.
	> 
	> Is it worthwhile to mark assertions that do not impact
messaging  
	> (e.g. as advisory or local), thus removing issue of "optional"
for  
	> these, allowing them to be ignored in intersection yet still  
	> understood legally?
	> 
	> regards, Frederick
	> 
	> Frederick Hirsch
	> Nokia
	> 
	> 
	> On Sep 27, 2006, at 1:31 PM, ext Sergey Beryozkin wrote:
	> 
	> > Hi Frederick
	> >
	> >>
	> >> No, because it is meaningless to "ignore" an assertion that
is  
	> >> always  applied by the provider, even if it is advisory to
the  
	> >> client. In  other words, it is not ignored in associated
impact,  
	> >> even if client  chooses to treat as advisory and "ignore"
it.
	> >
	> > Would you agree that it would be useful to think of any
assertion  
	> > listed in a given policy as something which is always
supported by  
	> > their provider  ? In other words they're guaranteed to be
supported.
	> > Irrespectively of how assertions are marked they're
supported by  
	> > their provider and not ignored...
	> >
	> > Thanks, Sergey
	> >
	> >>
	> >> No, because it is meaningless to "ignore" an assertion that
is  
	> >> always  applied by the provider, even if it is advisory to
the  
	> >> client. In  other words, it is not ignored in associated
impact,  
	> >> even if client  chooses to treat as advisory and "ignore"
it.
	> >>
	> >> -- non-wire assertion states something will be done (e.g.
logging)  
	> >> -  this happens, so is not optional.
	> >> -- client views this as advisory, so ignores in making
request,  
	> >> but  this is not the same as assertion being ignored in
entire  
	> >> process.
	> >>
	> >> The issue here is that optional has a much different
meaning than   
	> >> advisory.
	> >>
	> >> regards, Frederick
	> >>
	> >> Frederick Hirsch
	> >> Nokia
	> >>
	> >>
	> >> On Sep 27, 2006, at 12:45 PM, ext Glen Daniels wrote:
	> >>
	> >>>
	> >>> Hi Frederick:
	> >>>
	> >>>> It is difficult to combine the concept of optional with
its
	> >>>> normalization implications with flagging items that can
be ignored
	> >>>> without implication of actual impact.
	> >>>
	> >>> Why is that?  Optional means that there is both an
acceptable
	> >>> alternative without this assertion, and one with this  
	> >>> assertion.   Isn't
	> >>> that the same thing as saying that the item can be ignored
at the  
	> >>> whim
	> >>> of the consumer?
	> >>>
	> >>> This seems true regardless of whether the given assertion
has an
	> >>> "impact" vis. the wire messages.
	> >>>
	> >>> --Glen
	> >>>
	> >>>
	> >>
	> >
	> 
	>