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

 

> -----Original Message-----
> From: public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] On Behalf Of Frederick Hirsch
> Sent: Thursday, Sep 28, 2006 10:33 AM
> To: ext Christopher B Ferris
> 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
> 
> 
> Chris
> 
> Thanks for the clear explanation, makes a lot of sense.
> 
> I think the distinction is whether we are talking what 
> contributes to  
> a "contract" versus what is advisory (i.e. not necessarily 
> part of an  
> agreement).

IMO, your characterization is not quite right from the perspective of
the client. 

If you look at the categories that I posted in [1], what is advisory is
the third category from the perspective of the client. (It is still a
contract of the provider to itself)

However, the first and the second category (wsp:optional="true") is
still within a contract. 

> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 

Cheers, 

--umit

[1]
http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0197.html

> On Sep 28, 2006, at 1:17 PM, ext Christopher B Ferris wrote:
> 
> >
> > 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
> > > >>>
> > > >>>
> > > >>
> > > >
> > >
> > >
> 
> 
>

Received on Thursday, 28 September 2006 17:41:26 UTC