Re: Policy expressions with no wire manifestation

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 Wednesday, 20 September 2006 18:43:30 UTC