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: Fri, 25 May 2007 22:03:11 +0100
To: "'Christopher B Ferris'" <chrisfer@us.ibm.com>
Cc: <public-ws-policy@w3.org>, <public-ws-policy-request@w3.org>
Message-ID: <EMEA-EMS1eVPOEcyhJz00000497@emea-ems1.ionaglobal.com>
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.

 

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

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'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.

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" - 

(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 ?

 

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 21:04:14 GMT

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