RE: Policy expressions with no wire manifestation

I hope that all of you will review and comment on the guidelines document, 
as this is the kind of thing Umit and I were trying to
address with our proposal.  In my opinion, the normative text in the 
specifications gives the syntax for optional, and its role in 
normalization.
The assertion authors will need to define the semantic of the behavior.

Maryann



Prasad Yendluri <prasad.yendluri@webmethods.com> 
09/22/2006 11:46 AM

To
Sergey Beryozkin <sergey.beryozkin@iona.com>
cc
William Henry <william.henry@iona.com>, Maryann Hondo/Austin/IBM@IBMUS, 
Anthony Nadalin/Austin/IBM@IBMUS, public-ws-policy@w3.org, 
public-ws-policy-request@w3.org, Mark Little <mark.little@jboss.com>
Subject
RE: Policy expressions with no wire manifestation






Fundamentally we need to distinguish between (i) capabilities that a 
provider advertises and (ii) the requirements on the clients the provider 
specifies. The optional nature really applies to the latter (viz. 
requirements). Just because a requirement does not have wire 
manifestation, it cannot be marked ?optional?. What if a provider has a 
requirement to store the records of the interaction (audit log) for a 
specified amount of time, by the client (and the provider). This is not 
?optional? and is ?required? by the provider, as a clause for resolution 
of a dispute, should one arise later.  This does not result in any wire 
manifestation but it is not an optional behavior.
 
The fact that a requirement (assertion) does not result in wire 
manifestation should be (is expected to be) available from the 
specification of the assertion (type). Similarly if an assertion is a 
capability or a requirement should also be part of the specification of 
the assertion (type).
 
In any case marking assertions with no wire manifestation ?optional?, is 
not correct as optional is reserved for behaviors that are optional to 
engage, from the perspective of the provider.
 
Regards,
Prasad
 

From: public-ws-policy-request@w3.org 
[mailto:public-ws-policy-request@w3.org] On Behalf Of Mark Little
Sent: Friday, September 22, 2006 5:30 AM
To: Sergey Beryozkin
Cc: William Henry; Maryann Hondo; Anthony Nadalin; 
public-ws-policy@w3.org; public-ws-policy-request@w3.org
Subject: 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