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