- From: Sergey Beryozkin <sergey.beryozkin@iona.com>
- Date: Thu, 26 Oct 2006 09:58:29 +0100
- To: "Frederick Hirsch" <frederick.hirsch@nokia.com>
- Cc: "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." Absolutely not. Can you please point me to at least a single line in this thread where I was saying "assertions with no behavioral requirements on the requesters" are provider only ? If there's something a requester can do with the assertion then it's a good policy assertion which applies to both parties involved. Ex : <highlyAvailable/> applies to both parties because a requester can do something meaningful about, that is : use a search engine to select ha services, use intersection engine to select ha services, etc... Ex : <myLocalLoggingDetails/> applies to provider-only, SHOULD be stripped and if not then completely ignored by a requester by not even warning a user (in a design time scenario) that this assertion is not recognized. This example is not considerd in this thread, it was considered as a use case for introducing wsp:local. <highlyAvailable/> is not providerOnly, <myLocalLoggingDetails/> is. Thanks, Sergey 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 Thursday, 26 October 2006 08:57:35 UTC