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

Re: Policy expressions with no wire manifestation

From: Mark Little <mark.little@jboss.com>
Date: Fri, 22 Sep 2006 11:13:25 +0100
Message-Id: <96525392-ADAE-4133-8466-FF80A92DD932@jboss.com>
Cc: "William Henry" <william.henry@iona.com>, "Maryann Hondo" <mhondo@us.ibm.com>, "Anthony Nadalin" <drsecure@us.ibm.com>, <public-ws-policy@w3.org>, <public-ws-policy-request@w3.org>
To: Sergey Beryozkin <sergey.beryozkin@iona.com>
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
>>
>>
>
>
Received on Friday, 22 September 2006 10:12:34 GMT

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