- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Thu, 26 Oct 2006 08:05:48 -0400
- To: ext Sergey Beryozkin <sergey.beryozkin@iona.com>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "Paul Cotton" <Paul.Cotton@microsoft.com>, <public-ws-policy@w3.org>
I mis-typed, meant "no behavioral requirements on requestor". Sorry about that. regards, Frederick Frederick Hirsch Nokia On Oct 26, 2006, at 4:58 AM, ext Sergey Beryozkin wrote: > "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 12:28:38 UTC