Re: Policy expressions with no wire manifestation

Ah, my fault. I thought you were advocating adding  
<oasis:QOSGuarantee/> as well!

Mark.


On 22 Sep 2006, at 13:15, Sergey Beryozkin wrote:

> Hi
>
> Can you please elaborate a bit more on what you mean.
> I was actually advocating that assertions with no associated  
> behavioural requirements (to entites which may consume them) should  
> be marked with wsp:optional so that not to limit services' reach  
> which may be using such assertions and the only actual proposal was  
> for that guidelines for policy authors be amended acoordingly.
>
> Have you interpreted my message differently ? If no then what  
> problems do you see with using wsp:optional in cases like this ?
>
> Thanks, Sergey
>
> I can see some advantages and disadvantages to this. I like and  
> agree with the intention. However, as William pointed out, this can  
> be accomplished already, albeit in a slightly skewed way using  
> wsp:optional. But obviously that should prevent us trying to fix a  
> perceived deficiency in the specification. Unfortunately I think  
> this could be a major can-of-worms, worthy of its own specification!
>
> Mark.
>
>
>
> On 22 Sep 2006, at 11:03, Sergey Beryozkin wrote:
>
>> Minor omission :
>>
>> "Making such policy assertion as <oasis:QOSGuarantee>  would  
>> unnecessarily limit the audience of this service."
>>
>> I missed a phrase there, should be
>>
>> "Making such policy assertion as <oasis:QOSGuarantee> *non- 
>> optional* would unnecessarily limit the audience of this service."
>>
>> Cheers, Sergey Beryozkin
>> Iona Technologies
>> ----- Original Message -----
>> From: Sergey Beryozkin
>> To: William Henry
>> Cc: Maryann Hondo ; Anthony Nadalin ; public-ws-policy@w3.org ;  
>> public-ws-policy-request@w3.org
>> Sent: Friday, September 22, 2006 10:51 AM
>> Subject: Re: Policy expressions with no wire manifestation
>>
>> Hi all,
>>
>> After thinking a bit more about policies which express  
>> capabilities with no wire manifestations and no associated  
>> behaviours expected from a consumer of such policies, I came to  
>> some conclusion.
>>
>> Here's an example :
>>
>> wsp:Policy>
>>    <wsp:ExactlyOnce>
>>       <wsp:All>
>>          <!--- security assertion -->
>>          <sp:HttpsToken/>
>>       </wsp:All>
>>       <wsp:All>
>>          <!-- capability assertion -->
>>          <oasis:QOSGuarantee>
>>             <NeverEverFails/>
>>          </oasis:QOSGuarantee>
>>          <!--- security assertion -->
>>          <sp:HttpsToken/>
>>       </wsp:All>
>>    <wsp/ExactlyOnce>
>> <wsp:Policy>
>>
>> A policy designer wishes to tell to ws-policy aware entities out  
>> there that they must be able to use HTTPS should they attempt to  
>> start communicating with the service.
>> Futhermore, a policy designer wishes to tell that the service has  
>> a well-known capability to never fail, but is careful to ensure  
>> that the entities not aware of what this means but still meeting a  
>> key requirement of being able to use HTTPS can still enjoy  
>> communicating with this service. A policy author achives this by  
>> creating two policy alternatives.
>> The reason is simple : <oasis:QOSGuarantee> assertion is not a  
>> requirement but a capability which has no wire manifestations and  
>> behavioural requirements for the entities which can understand  
>> what it means.
>>
>> In fact, the above expression, being in a normal form, is  
>> equivalent to this compact expression :
>>
>> wsp:Policy>
>>    <wsp:ExactlyOnce>
>>        <sp:HttpsToken/>
>>         <oasis:QOSGuarantee wsp:optional="true">
>>             <NeverEverFails/>
>>          </oasis:QOSGuarantee>
>>    <wsp/ExactlyOnce>
>> <wsp:Policy>
>>
>> Making such policy assertion as <oasis:QOSGuarantee>  would  
>> unnecessarily limit the audience of this service. A requester  
>> entity should never fail if it does not understand what  
>> <oasis:QOSGuarantee>  given the fact the only thing it can ever do  
>> with it is to note that this service posesses the advertised  
>> quality and see whether it meets its selection criteria or not.
>>
>> For example, if a requester searches for services which are known  
>> to publish its message logging traces to a well known external  
>> site it shoud be sufficient for it to be able to recognize a well  
>> known <common:publishTraces href="..."/> rather than fail due to  
>> the fact <oasis:QOSGuarantee/>  is not recognized. Likewise those  
>> searching for never failing services should be able to consume  
>> those who assert it and not fail should they not recognize  
>> <common:publishTraces href="..."/>.
>>
>> This brings me to a simple conclusion : Policy authors SHOULD be  
>> encouraged to use wsp:optional when using policy asssertions which  
>> advertise capabilities with no associated behavioral requirements  
>> and wire representations in order to widen the service's audience  
>> and improve interoperability. wsp:optional means here that it's a  
>> capability which *may* be used for a service selection. I believe  
>> guidelined for policy authors should be updated.
>>
>> At the moment the WS-Policy Framework (primer) uses wsp:optional  
>> to mark assertions which identify behaviours which *may* be  
>> engaged. It refers to such assertions as 'capabilities'. IMHO it's  
>> not the best/too broad the definition and it will cause  
>> confusions. For ex : <mtom:OptimizedMimeSerialization  
>> wsp:optional="true"/>. I feel it's better be additionally  
>> categorised as an optional requirement.
>>
>> Any thoughts or objections ?
>>
>> Likewise an assertion like <sp:MustSupportRefKeyIdentifier />   
>> does not fall into this category because a policy author  
>> *requires* a consuming entity to understand it, ortherwise the  
>> secure processing on either side will fail.
>>
>> Thanks, Sergey Beryozkin
>> Iona Technologies
>>
>>
>> It is my understanding that people are using the wsp:optional to  
>> handle this. So if the requester (consumer) doesn't know about it  
>> they can ignore it.
>>
>> This works BUT it is really using wsp:optional in an unintended  
>> way. The truth is that such an assertion is not really optional  
>> it's only optional in the sense that the requester can ignore it  
>> however the provider must be providing this level of service and  
>> the requester must do nothing - so in that sense it really isn't  
>> optional it's just a handy use of the wsp:optional.
>>
>> This is one of the reasons I think there could be another  
>> attribute missing (like the wsp:local).
>>
>> Another reason for having such an attribute would be for the  
>> generic engine to be able to handle such a thing consistently in  
>> all implementations. e.g. if I had a wh:local then I'd be forcing  
>> the requester to either know about my namespace or assume that  
>> they can't use this service. I think it can just make things  
>> messier than they need to be.
>>
>> Having said all that I understand the effort that introducing a  
>> new attribute would mean and seeing as you can get a similar  
>> affect using things like wsp:optional (albeit in an unintended  
>> way) I expect push back on the idea.
>>
>> Regards,
>> William
>>
>> On Sep 20, 2006, at 11:46 AM, Beryozkin, Sergey wrote:
>>
>>> Hi Maryann, others
>>>
>>> this is most helpful...
>>>
>>> "I would note that if you're "using the assertion for selection",  
>>> it could
>>> imply that you know what it is."
>>>
>>> Ok, I think I start understanding it (fingers crossed :-)). A  
>>> requester runtime may be required to select services which are  
>>> highly available. It expects providers to advertize well-known  
>>> <oasis:HighlyAvailable/> assertions. If a provider advertizes a  
>>> policy which have no <oasis:HighlyAvailable/> assertions then the  
>>> intersection will fail. I think it's reasonable.
>>>
>>> Now consider a different case.
>>> A requester runtime has no priori policy requirements. However it  
>>> understands all well-known security assertions but no others  
>>> ones. It has found a service which requires that a requester  
>>> supports some security policies.
>>>
>>> Futhermore, a provider wishes to advertize some of its  
>>> capabilities, namely that it's the best service around. A  
>>> requester does not know yet about such assertions and is not even  
>>> planning to use assertions like this for services selection.
>>>
>>> How would we do it ?
>>>
>>> Like this  ? :
>>>
>>> <wsp:Policy>
>>>    <wsp:ExactlyOnce>
>>>       <wsp:All>
>>>          <!--- security assertion -->
>>>          <sp:HttpsToken/>
>>>       </wsp:All>
>>>       <wsp:All>
>>>          <!-- capability assertion -->
>>>          <oasis:QOSGuarantee>
>>>             <TheBestServiceInThisCategory verifiedBy="..."/>
>>>          </oasis:QOSGuarantee>
>>>          <!--- security assertion -->
>>>          <sp:HttpsToken/>
>>>       </wsp:All>
>>>    <wsp/ExactlyOnce>
>>> <wsp:Policy>
>>>
>>> Thanks,
>>> Sergey Beryozkin
>>> Iona Technologies
>>>
>>> ----- Original Message -----
>>> From: Maryann Hondo
>>> To: Sergey Beryozkin
>>> Cc: Anthony Nadalin ; public-ws-policy@w3.org ; public-ws-policy- 
>>> request@w3.org ; Sergey Beryozkin
>>> Sent: Wednesday, September 20, 2006 2:17 PM
>>> Subject: Re: Policy expressions with no wire manifestation
>>>
>>>
>>> Sergey,
>>> I responded to your other mail ...so this is a bit of a repetition.
>>>
>>> In the guidelines document, Umit and I have attempted to capture  
>>> "observations" about the use of optional, and this might
>>> be a case where it would be useful.  I would note that if you're  
>>> "using the assertion for selection", it could
>>> imply that you know what it is. Whether or not it is required on  
>>> the wire is a facet of the behavior associated with the assertion.
>>> Each set of authors is given a set of tools by the  
>>> specifications, but the authors need to craft the assertions.
>>>
>>> Maryann
>>>
>>>
>>>
>>> "Sergey Beryozkin" <sergey.beryozkin@iona.com>
>>> Sent by: public-ws-policy-request@w3.org
>>> 09/20/2006 05:35 AM
>>>
>>> To
>>> "Sergey Beryozkin" <sergey.beryozkin@iona.com>, Anthony Nadalin/ 
>>> Austin/IBM@IBMUS
>>> cc
>>> <public-ws-policy@w3.org>, <public-ws-policy-request@w3.org>
>>> Subject
>>> Re: Policy expressions with no wire manifestation
>>>
>>>
>>>
>>>
>>>
>>> Hi there
>>>
>>> That was a response in a hurry so I take it back. Before flooding  
>>> the group concalls with trivial issues I'd rather attempt to make  
>>> my question as clear as possible. Note that I may indeed be  
>>> confused, but if so then I'd appreciate an answer which would help.
>>>
>>> Consider this example :
>>>
>>> <wsp:Policy>
>>>    <wsp:ExactlyOnce>
>>>          <oasis:QOSGuarantee>
>>>               <NeverFails/>
>>>               <TheBestServiceInThisCategory verifiedBy="..."/>
>>>          <oasis:QOSGuarantee>
>>>    <wsp/ExactlyOnce>
>>> <wsp:Policy>
>>>
>>> This is an example of a policy with a single alternative. This  
>>> alternative contains non-optional assertions
>>> defined by a policy profile spec published a month ago. These  
>>> assertions have no wire manifestations.
>>> A ws-policy aware (requester) entity whose runtime has not been  
>>> updated yet to recognize <oasis:QOSGuarantee> is about to start  
>>> communicating with the service which advertizes this policy.
>>>
>>> Given the fact that it's likely ws-policy aware requesters will  
>>> refuse to start talking to a service should they fail to support  
>>> the above policy and that the fact whether this requester  
>>> supports this policy or not will have no effect on the actual  
>>> communication with the service this policy attached to, my  
>>> understanding is that such assertions with no wire manifestations  
>>> SHOULD be marked as wsp:optional :
>>>
>>> <wsp:Policy>
>>>    <wsp:ExactlyOnce>
>>>          <oasis:QOSGuarantee wsp:optional="true">
>>>               <!-- -->
>>>          <oasis:QOSGuarantee>
>>>    <wsp/ExactlyOnce>
>>> <wsp:Policy>
>>>
>>> This means a requester may use this policy for a service  
>>> selection but doesn't need to refuse talking to this service  
>>> should it fail to recognize the policy.
>>>
>>> Does it make sense ?
>>> What is the group's position on this issue ?
>>>
>>> Thanks
>>>
>>> Sergey Beryozkin
>>> Iona Technologies
>>>
>>>
>>
>>
>
>