This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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 ?
If the requester initiates the intersection and it has ignorable assertions then if those assertions are truly ignorable, that is, the requester has not marked them as ignorable by mistake, then it might be harmless for suchs assertions be included in the post-intersection policy even though no match has been found during the intersection. The value of it is unclear though so it all needs to be clarified. It's not clear why the assertion which the requester has marked as ignorable (thus presumably telling about the nature of such an assertion to the consumers of this requester's policy) is still in the intersected policy even though no match is there.
[13:30] cferris: 1. Modify Section 3.1, Framework - S/An ignorable policy assertion is an assertion that may be ignored for policy intersection/An ignorable policy assertion is an assertion that may be ignored for purposes of determining the compatibility of alternatives in policy intersection in lax mode/ [13:30] monica: c/on/using [13:30] monica: ok in [13:30] cferris: 2. Add to Section 4.5, Framework 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. [13:30] cferris: 3. S/If two alternatives are compatible, their intersection is an alternative containing all of the assertions in both alternatives/If two alternatives are compatible, their intersection is an alternative containing all of the assertions in both alternatives, regardless of whether or not they are marked with the wsp:Ignorable='true' attribute. [13:31] asir: RESOLUTION: closed issue 4584 with the changes 1-3 above [13:31] cferris: rrsagent, where am i? [13:31] RRSAgent: See http://www.w3.org/2007/06/06-ws-policy-irc#T17-33-13