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: Thu, 26 Oct 2006 08:05:48 -0400
Message-Id: <691B9AE7-089E-4EF2-9888-93779C8C6974@nokia.com>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "Paul Cotton" <Paul.Cotton@microsoft.com>, <public-ws-policy@w3.org>
To: ext Sergey Beryozkin <sergey.beryozkin@iona.com>

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 GMT

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