W3C home > Mailing lists > Public > public-ws-policy@w3.org > May 2007

RE: Bug 4584 : Clarify how lax mode and ignorable assertions affect the intersection algorithm

From: Sergey Beryozkin <sergey.beryozkin@iona.com>
Date: Sat, 26 May 2007 22:51:52 +0100
To: "'Charlton Barreto'" <charlton_b@mac.com>
Cc: "'Christopher B Ferris'" <chrisfer@us.ibm.com>, <public-ws-policy@w3.org>, <public-ws-policy-request@w3.org>
Message-ID: <EMEA-EMS151dyZSdA6k000004a3@emea-ems1.ionaglobal.com>

Hi Charlton

Lets have a look at the following section in the primer, 
http://www.w3.org/TR/2007/WD-ws-policy-primer-20070330/#ignorable-policy-ass
ertions

"The wsp:Ignorable attribute allows providers to clearly indicate which
policy assertions indicate behaviors that don't manifest on the wire and may
not be of concern to a requester when determining policy compatibility."

and

"Please note that the impact of the ignorable attribute is at the discretion
of policy consumers through selection of "lax" or "strict" mode (See 3.4.1
Strict and Lax Policy Intersection). Therefore ignorable assertions may have
an effect on determining compatibility of provider and consumer policies."

IMHO it just doesn't make sense for requesters (ultimate consumers or those
enhancing the policy) to use ignorable assertions in the light of the
primer's explanation. The primer explains
why providers may want to use them, furthermore it stresses that the
consumer decides whether to honor the ignorable attribute.
Which party the requesters initiating the intersection target its ignorable
assertions at? At themselves? And why are they using ignorable assertions in
the first place ?

As I said there's only one technical explanation I can think of : use the
generic intersection algorithm to bring in extra policy assertions... That's
in itself can be a good enough reason for requesters to use ignorable
assertions, but that's a low-level technical detail which has little to do
with the way ignorable assertions are presented in the primer, 
That's why it's an overload of the original semantics.

>>.
>>I was always thinking about the ignorable attribute as the means for the
>>provider to tell the requester that this assertion may be ignored.

>...for the sake of intersection. Let's be careful with the terminology. :-)

Sorry, don't understand the comment about the terminology :-) 
Consider a policy-aware client application which doesn't do the intersection
(have no specific preconditions) and it consumes a WSDL with an ignorable
assertion...Ignorable assertions can be useful without the intersection.
Say, a provider advertises something (as ignorable assertion), obviously a 
client (UI) tool doesn't need to do the intersection in order to show this
assertion to the user, right ?


>>I think in itself it's not a bad idea (perhaps the overall processing can
be
>>accelerated/simplified, etc) but I'd consider this to be an overload of
the
>>original semantics of "ignorable" - 

>Does it? All ignorable means is that lax mode intersection doesn't apply
>the intersection algorithm to an assertion.

Please see above. Ignorable assertion means that a provider tells the
consumer : this is an assertion which does not require you to do anything on
the wire, look at it and if you recognize it (through the intersection or
through the user's decision) then you've got the message. If the provider
uses the ignorable assertions then it wants to say something. Lax mode is
there to make ignorable assertions a viable option for providers. Without a 
lax mode providers will have to know their consumers really well before
using ignorable assertions.  

>>I'm wandering what the primer can possibly say about the requesters using
>>ignorable assertions ?

>Other than writing some scenarios into the primer, which has proved to be
>difficult, I don't see what else the primer can state.

I think the most interesting bit is see how a dry specification text can be
applied to the real world scenarios. If we can't think of realistic examples
then it's all just the pure academic discussion. I like the idea of the
intermediate requester enhancing the policy along the way (or indeed just
utilizing the lax mode to bring in extra info for itself), may be that can
be presented as an example showing why requesters might want to use
ignorable assertions, alongside with the wording changes similar to those
suggested by Chris. Wording changes would make things clearer.

Thanks, Sergey

-----Original Message-----
From: Charlton Barreto [mailto:charlton_b@mac.com] 
Sent: 25 May 2007 23:47
To: Sergey Beryozkin
Cc: 'Christopher B Ferris'; public-ws-policy@w3.org;
public-ws-policy-request@w3.org
Subject: RE: Bug 4584 : Clarify how lax mode and ignorable assertions affect
the intersection algorithm

Hi Sergey,

Responses inline.

-Charlton.
 
On Friday, May 25, 2007, at 10:05PM, "Sergey Beryozkin"
<sergey.beryozkin@iona.com> wrote:
>Hi Chris
>
> 
>
>Many thanks for detailed comments.
>
> 
>
>I was actually always looking at the intersection as being directional. In
a
>sense that the provider's assertions are ultimately dictating
>
>what is it that the requesters has to deal with. Therefore, I thought
>requesters can only restrict by doing the intersection.
>

Requestors can also embellish by doing the intersection. Requestors and
providers, both being able to attach policies, can use them to define which
policies the consumer must or may apply to services it consumes. 

>
>I was always thinking about the ignorable attribute as the means for the
>provider to tell the requester that this assertion may be ignored.

...for the sake of intersection. Let's be careful with the terminology. :-)

The ignorable attribute allows the provider to communicate that in lax mode
intersection, the requestor, when processing the intersection, doesn't apply
the intersection algorithm to those assertions. 

>The primer says that ignoring the ignorable assertions is at the discretion
>of the requester (entity initiating the transaction), so it seems there's
>some sense of directionality here;

It is the requestor that performs intersection. Thus the requestor is the
party having the discretion to apply or not apply the intersection algoritm
to assertions. 

>it's not clear why the requester itself would use ignorable assertions. I
>can think about only one reason : 
>
>* the requester wishes to use a generic intersection algorithm to bring its
>own configuration/(private policies) irrespectively of whether the provider
>knows anything about them or not.

I would say instead: "The requestor wishes to bring its own policies
irrespective of whether the provider knows anything about them or not when
lax mode is employed." Ignorable assertions are not processed in that case.
When strict mode is employed, the intersection algorithm is not applied to
them.

>
>Essentially the requester expands the possible combination of assertions it
>has to deal with.
>
> 
>
>I think in itself it's not a bad idea (perhaps the overall processing can
be
>accelerated/simplified, etc) but I'd consider this to be an overload of the
>original semantics of "ignorable" - 

Does it? All ignorable means is that lax mode intersection doesn't apply the
intersection algorithm to an assertion. 

>(the provider wishes to tell the requester about the ignoreability of the
>specific assertion) but may be because I haven't understood those semantics
>in the first place.
>
> 
>
>I'm wandering what the primer can possibly say about the requesters using
>ignorable assertions ?

Other than writing some scenarios into the primer, which has proved to be
difficult, I don't see what else the primer can state.
 
>
>Cheers, Sergey
>
> 
>
> 
>
> 
>
> 
>
>  _____  
>
>From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
>Sent: 25 May 2007 12:29
>To: Sergey Beryozkin
>Cc: public-ws-policy@w3.org; public-ws-policy-request@w3.org
>Subject: Re: Bug 4584 : Clarify how lax mode and ignorable assertions
affect
>the intersection algorithm
>
> 
>
>
>Sergey, 
>
>As I indicated, the intersection result includes all assertions from the
>compatible alternatives 
>regardless of whether or not they are marked ignorable. It does not matter
>which 
>policy includes such alternatives. 
>
>More comments below. 
>
>Cheers, 
>
>Christopher Ferris
>STSM, Software Group Standards Strategy
>email: chrisfer@us.ibm.com
>blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
>phone: +1 508 377 9295 
>
>public-ws-policy-request@w3.org wrote on 05/25/2007 06:17:02 AM:
>
>> Consider the following two policies. 
>>   
>> Provider policy : 
>> <Policy> 
>>  <A/> 
>>  <B wsp:ignorable="true"/> 
>> </Policy> 
>>   
>> Requester policy : 
>> <Policy> 
>>  <A/> 
>>  <D wsp:ignorable="true"/> 
>> </Policy> 
>>   
>> Requester initiates the intersection, lax mode is on. 
>>   
>> I believe the following clarification should be made : 
>> 1. If the entity which initiates the intersection contains
>ignorableassertions 
>> then such assertions must be treated as normal non-ignorable assertions,
>that 
>> is, the requester's policy is equivalent in this case to 
>>   
>> <Policy> 
>>  <A/> 
>>  <D/> 
>> </Policy> 
>
>How they are treated with regards to engaging behavior in an interaction 
>is not relevant to intersection. Intersection is all about determining 
>whether two policies are compatible. 
>
>>   
>> Lax mode means that the requester may ignore the provider's ignorable 
>
>Correct. 
>
>> assertions. It does not say anything about including the
>requester'sassertions 
>> marked as being ignorable into the effective intersected policy. 
>
>Actually, it does. 
>http://www.w3.org/TR/2007/CR-ws-policy-20070330/#Policy_Intersection 
>
>"If two alternatives are compatible, their intersection is an alternative
>containing all of the assertions in both alternatives. " 
>
>Granted, the language could be a little confusing since it could have been
>read to 
>mean that only those assertions present in BOTH of the alternatives are
>included in the 
>result. However, that was not the intent. An inspection of the test cases
>for intersection 
>should make it clear that the intent was actually that the intersection
>result is the 
>bag union of the two alternatives. 
>
>We have actually cleared this up as a result of resolving one of David
>Hull's issue 4553 
>        http://www.w3.org/Bugs/Public/show_bug.cgi?id=4553 
>
>The new text agreed during this week's f2f is as follows: 
>
>"If two alternatives are compatible, their intersection is an
>alternative containing all of the occurrences of all of the assertions from
>each of the
>alternatives (i.e., the bag union of the two)." 
>
>> Ignorable assertion means : you can ignore it for the intersection
>purposes if 
>> you're in a lax mode, it's the message to the entity initiating the 
>> intersection. 
>
>Correct, you can ignore it for purposes of intersection in lax mode.
>However, 
>I think you should re-read the intersection algorithm as it applies to
>Ignorable. 
>
>Again, quoting from the framework (as amended by the resolution to 4553): 
>
>If the mode is strict, two policy alternatives A and B are compatible: 
>    * if each assertion in A is compatible with an assertion in B, and 
>    * if each assertion in B is compatible with an assertion in A. 
>
>If the mode is lax, two policy alternatives A and B are compatible: 
>    * if each assertion in A that is not an ignorable policy assertion is
>compatible with an assertion in B, and 
>    * if each assertion in B that is not an ignorable policy assertion is
>compatible with an assertion in A. 
>
>If two alternatives are compatible, their intersection is an an
>alternative containing all of the occurrences of all of the assertions from
>each of the
>alternatives (i.e., the bag union of the two). 
>
>Note that nowhere does it say to remove the assertions marked as ignorable.
>It simply says that 
>for each assertion that is not ignorable... 
>
>Regardless of whether strict or lax mode is used, the result is "an
>alternative containing all of the occurrences of all of the assertions from
>each of the
>alternatives (i.e., the bag union of the two)." 
>
>No statement is made about excluding those assertions that are marked
>ignorable. 
>
>>   
>> If this clarification is made then the above two policies will not
>intersect 
>> irrespectively of which side initiates the intersection. 
>
>Intersection is not directional. 
>
>>   
>> Now consider these two policies : 
>>   
>> Provider policy : 
>> <Policy> 
>>  <A/> 
>>  <B wsp:ignorable="true"/> 
>> </Policy> 
>>   
>> Requester policy : 
>> <Policy> 
>>  <A/> 
>> </Policy> 
>>   
>> Requester initiates the intersection, lax mode is on.   
>>   
>> Clarification needs to be done on whether the effective policy after the 
>> intersection includes <B wsp:ignorable="true"/> or not. If ignorablemeans
>this 
>> assertion is ignorable for the intersection purposes then why, after the 
>> intersection engine finishes its job, <B/> would still be there ? 
>
>Yes, see above. 
>
>I am wondering whether it would be clearer if we were to change the
>definition of 
>ignorable from: 
>
>An ignorable policy assertion is an assertion that may be ignored for
policy
>intersection (as defined ...) 
>
>to 
>
>An ignorable policy assertion is an assertion that may be ignored for
>purposes of 
>determining the compatibility of alternatives in policy intersection (as
>defined ...) 
>
>Additionally, we could add to section 4.4 text that makes it clear that the

>behavior implied by an ignorable assertion is expected to be a behavior
that
>need not 
>be engaged for successful interoperation with the entity that includes such
>ignorable 
>assertions in its policy. 
>
>>   
>> If the requester is working in a design mode then I can see the value, as
>the 
>> (UI) tool may offer a user a chance to decide on what to do with <B/> 
>>   
>> If the requester is an application doing an intersection 
>> dynamically, then what 
>> is the value of keeping </B> after the intersection ? 
>
>That is an exercise for the implementation to decide. Maybe, as in the
>example 
>we use in the Primer, a warning dialog might be displayed to the end used 
>indicating that the service provider is logging all message traffic. 
>
>>   
>>   
>> Thanks, Sergey Beryozkin
>
>
Received on Saturday, 26 May 2007 21:52:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:34 UTC