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 Friday, 25 May 2007 22:46:56 UTC