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

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 ignorable
assertions
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>
 
Lax mode means that the requester may ignore the provider's ignorable
assertions. It does not say anything about including the requester's
assertions
marked as being ignorable into the effective intersected policy.
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.
 
If this clarification is made then the above two policies will not intersect
irrespectively of which side initiates the intersection.
 
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 ignorable means
this
assertion is ignorable for the intersection purposes then why, after the
intersection engine finishes its job, <B/> would still be there ?
 
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 ?

 

 

Thanks, Sergey Beryozkin