- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Wed, 25 Oct 2006 16:10:51 -0400
- To: Frederick Hirsch <frederick.hirsch@nokia.com>
- Cc: ext Sergey Beryozkin <sergey.beryozkin@iona.com>, "Paul Cotton" <Paul.Cotton@microsoft.com>, <public-ws-policy@w3.org>
I assume I missed the email subject line, which indicated that this only applies to assertions that are provider only. regards, Frederick Frederick Hirsch Nokia On Oct 25, 2006, at 3:18 PM, Frederick Hirsch wrote: > Sergey > > Is this what is meant by policy alternatives? > > For example, if one alternative uses message security and the other > TLS, wouldn't a client expect the security mechanism outlined in > the alternative to be used, and not the other? > > For example, what if the client does not support WSS, but does > support TLS. Then wouldn't picking the alternative with TLS suggest > not the use of WSS as offered in the other alternative? > > This seems different than what you mention in your message. > > regards, Frederick > > Frederick Hirsch > Nokia > > > On Oct 25, 2006, at 11:53 AM, ext Sergey Beryozkin wrote: > >> Hi >> >> I'd also like a primer clarifying and explaining what does it >> mean, from a requester's point of view, to work with different >> policy alternatives. >> For ex, at the moment, if we have a policy like this : >> <wsp:Policy> >> <ExactlyOnce> >> <!-- alt1 --> >> <All> >> <foo/> >> </All> >> <!-- alt2 --> >> <All> >> <bar/> >> </All> >> </ExactlyOnce> >> </wsp:Policy> >> >> then one interpretation can be that by selecting a first >> alternative a requester is choosing to work with a provider which >> has no <bar/>. >> The primer should explain that two alternatives are two different >> policy micro-vocabulary instances and that, by choosing the >> alternative the requester just chooses the vocabulary it >> understands/prefers. >> From a provider's perspective, a policy vocabulary is the one >> which combines the vocabularies of all alternmatives. That is it >> supports all assertions, even if this assertion is not present in >> the alternative chosen by a given requester. >> For ex: >> <wsp:Policy> >> <ExactlyOnce> >> <!-- alt1 --> >> <All> >> <sp:MessageSecurity/> >> </All> >> <!-- alt2 --> >> <All> >> <sp:TransportSecurity/> >> </All> >> </ExactlyOnce> >> </wsp:Policy> >> >> Irrespectively of the alternative chosen the provider retains the >> 'being secure' capability. Likewise if we have two service >> endpoints, with one endpoint being annotated with a policy >> alternative (service metadata) and the other one being not, the >> second endpoint still posesses the same capabilities as the first >> endpoint, it's just thes capabilites will have to be discovered >> out-of-band for the the second endpoint. >> >> Another example : >> >> <wsp:Policy> >> <ExactlyOnce> >> <!-- alt1 --> >> <All> >> <sp:MessageSecurity/> >> </All> >> <!-- alt2 --> >> <All> >> <sp:TransportSecurity/> >> </All> >> <!-- alt3 --> >> <All> >> <oasis:free/> >> <ExactlyOnce> >> <All> >> <sp:MessageSecurity/> >> </All> >> <All> >> <sp:TransportSecurity/> >> </All> >> </ExactlyOnce> >> </All> >> </ExactlyOnce> >> </wsp:Policy> >> >> 3 vocabularies are presented. Irrespectively of the alternative/ >> vocabukary chosen, a service provider retains the capability of >> being free and secure. >> >> Thanks, Sergey >> >> Hi >> >> "Can you formulate your required example even in outline form?" >> >> >> Example. A service has a capability to keep the clients' info >> confidential. This capability has no behavioral requirements on >> the client and has no wire representations. It wishes to advertize >> this capability such that those requesters which understand what >> it means can use it during the intersection stage or as part of a >> search as a base for choosing this service among similar ones. >> >> Additionally, this service wishes to make itself available to >> those requesters which has no a priori knowledge of this assertion >> due to the safe-to-ignore properties of this capability. >> >> >> <wsp:Policy> >> >> <wsp:ExactlyOnce> >> >> <contoso:infoConfidential wsp:optional="true"/> >> >> <wsp:ExactlyOnce> >> >> </wsp:Policy> >> >> >> "I assume you want this text in the primer and/or guidelines doc. >> Is that correct? >> >> If so can you offer proposed text?" >> >> >> I'd like to see a clarification in the wsp:optional wording which >> clearly states that wsp:optional is not optional for a provider >> and that wsp:optional is a hint to a requester that an assertion >> identifies a requirement which is optional for a requester to do >> something about it. In case of <contoso:infoConfidential >> wsp:optional="true"/> it's a requirement to understand what >> contoso:infoConfidential means. >> >> >> I'd like to the terminology be updated such that a >> <contoso:infoConfidential wsp:optional="true"/> does not turn from >> a capability in a compact form into a requirement in the normal >> form. Any assertion when looked from a provider's side is a >> capability. Any provider's assertion when looked from a >> requester's side is a requirement on the requester (to understand >> it, to do something about it). >> >> If the group agrees with the above then I'd ask editors for help >> in presenting the text in a more readable way. >> >> >> "Can you please clarify what you mean by “so that a policy author >> can use wsp:optional as a recognized but not a workaround to mark >> such assertions”? " >> >> >> Thanks, Sergey >> >> >> >1. Add an example to a primer and/or policy guidelines >> >> >> >> Can you formulate your required example even in outline form? >> >> >> >> >2. Explain why policy authors should make such assertions >> optional for those requesters which are not aware of them. >> >> >> >> I assume you want this text in the primer and/or guidelines doc. >> Is that correct? >> >> >> >> If so can you offer proposed text? >> >> >> >> > 3. Make any necessary changes to the wsp:optional related >> wording so that a policy author can use wsp:optional as a >> recognized but not a workaround way to mark such assertions. >> >> >> >> Can you please clarify what you mean by “so that a policy author >> can use wsp:optional as a recognized but not a workaround to mark >> such assertions”? >> >> >> >> Are you saying the Framework should warn policy assertion authors >> from using wsp:optional to describe “assertions with no >> behavioural requirements on the requester”? >> >> >> >> /paulc >> >> Paul Cotton, Microsoft Canada >> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 >> Tel: (613) 225-5445 Fax: (425) 936-7329 >> mailto:Paul.Cotton@microsoft.com >> >> >> >> >> From: public-ws-policy-request@w3.org [mailto:public-ws-policy- >> request@w3.org] On Behalf Of Sergey Beryozkin >> Sent: October 6, 2006 6:27 AM >> To: Sergey Beryozkin; public-ws-policy@w3.org >> Subject: Re: NEW ISSUE :Clarify usage of assertions with no >> behavioral requirements on the requeste >> >> >> >> Hello, >> >> >> >> This is the resolution I think would adequately address this issue : >> >> >> >> 1. Add an example to a primer and/or policy guidelines >> 2. Explain why policy authors should make such assertions optional >> for those requesters which are not aware of them. >> 3. Make any necessary changes to the wsp:optional related wording >> so that a policy author can use wsp:optional as a recognized but >> not a workaround way to mark such assertions. >> >> >> >> Thanks, Sergey >> >> >> >> http://www.w3.org/Bugs/Public/show_bug.cgi?id=3789 >> >> Target : WS-Policy Framework and policy guidelines >> >> Justification : >> >> There's a class of policy assertions which have no behavioral >> requirements on the requester but can be still usefully processed by >> requesters which are aware >> of what assertions mean. >> For example : <oasis:Replicatable/> >> >> An assertion like this one can be a useful source of information >> for requesters. Providers having expected properties like >> <oasis:Replicatable/> can be chosen/searched. >> At the same time, given the fact assertions like >> <oasis:Replicatable/> >> have no behavioral requirements on the provider it's important to >> ensure >> policy-aware clients which have no knowledge of these assertions >> can proceed >> consuming the service advertsing this assertion. >> >> Currently the way to advertise such an assertion is to use a >> normal form with two policy alternatives(simple case), with only one >> alternative containing this assertion thus making it optional, or, >> in other words, giving a chance to requesters to ignore it. >> Such normal form expression is equivalent to a compact form with >> the optional assertion marked with wsp:optional attribute with a >> value 'true'. >> >> However, at the moment the primer recommends using wsp:optional >> when one needs to mark asssertions which identify optional >> capabilities/requirements with behavioral requirements on a >> requester should the requester wishes to use it. >> >> Thus marking assertions like <oasis:Replicatable/> with >> wsp:optional is considered to be a wrong approach. >> >> Proposal : >> >> Clarify the text describing the optionality in the policy >> guidelines and in the Framework spec on how a policy author should >> use >> assertions like >> <oasis:Replicatable/>. >> It's important that assertions like these can be usefully >> interpreted by knowledgeble requesters and safely ignored by >> requesters >> unaware of them. >> >> >
Received on Wednesday, 25 October 2006 20:11:14 UTC