- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Thu, 28 Sep 2006 13:33:17 -0400
- To: "ext Christopher B Ferris" <chrisfer@us.ibm.com>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "ext Glen Daniels" <gdaniels@progress.com>, public-ws-policy@w3.org, public-ws-policy-request@w3.org, ext Sergey Beryozkin <sergey.beryozkin@iona.com>
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). regards, Frederick Frederick Hirsch Nokia 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:33:48 UTC