W3C home > Mailing lists > Public > public-ws-policy@w3.org > October 2006

Re: NEW ISSUE :Clarify usage of assertions with no behavioral requirements on the requester

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Wed, 25 Oct 2006 16:10:51 -0400
Message-Id: <F8878BB0-F7F5-481B-BA32-887F121CF678@nokia.com>
Cc: ext Sergey Beryozkin <sergey.beryozkin@iona.com>, "Paul Cotton" <Paul.Cotton@microsoft.com>, <public-ws-policy@w3.org>
To: Frederick Hirsch <frederick.hirsch@nokia.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:42 GMT