Action-272: Re: [ISSUE 4393 PRIMER] Add text to strict and lax policy intersection discussion ...

Here is an **updated** proposal based on the feedback we received last week,

See: http://www.w3.org/Bugs/Public/show_bug.cgi?id=4393

Title: Add text to strict and lax policy intersection discussion describing
how a policy consumer can determine issues due to intersection mode
conflicts

Target: WS-Policy Primer, Section 3.4.1

Description: While the Primer covers scenarios on applying intersection
modes, we do not have any content which illustrates how conflicts can be
detected. As such we need to indicate in the Primer how a consumer may
address such conflict detection and reporting.

Justification: As consumers have the option to choose one or more modes for
policy intersection (strict | lax | strict, delegate-to-user | lax,
delegate-to-user | strict, lax, delegate-to-user | ...), conflicts may occur
when providers intend for their policies to be applied only in a lax mode -
this is distinct from treating everything as ignorable. While the end result
may be the same (failure, being that no policy alternatives are available),
the consumer needs to be able to report why this occurs.

Proposal: Perform the following changes to the Primer text

Change in 3.4.1 Strict and Lax Policy Intersection, as follows (highlighted
in colour below):

 "The previous sections outlined how the normal-form of a policy expression
relate to the policy data model and how the compatibility of requester and
provider policies may be determined. This section outlines how ignorable
assertions may impact the process of determining compatibility.

In order to determine compatibility of its policy expression with a provider
policy expression, a requester may use either a "lax" or "strict" mode of
the intersection algorithm.

In the strict intersection mode two policy alternatives are compatible when
each assertion in one is compatible with an assertion in the other, and vice
versa. For this to be possible they must share the same policy alternative
vocabulary. The strict intersection mode is the mode of intersection
discussed in the previous sections of this document.

When using the strict intersection mode, all assertions are part of the
policy alternative vocabulary, including those marked with wsp:Ignorable. Thus,
the wsp:Ignorable attribute does not impact the intersection result even
when its attribute value is "true".

If a requester wishes to ignore ignorable assertions in a provider's policy,
then the requester should use the lax intersection mode. In the lax
intersection mode all ignorable assertions (i.e. with the value "true" for
the wsp:Ignorable attribute) are to be ignored by the intersection
algorithm. Thus in the lax intersection mode two policy alternatives are
compatible when each non-ignorable assertion in one is compatible with an
assertion in the other, and vice versa. For this to be possible the two
policy alternatives must share a policy alternative vocabulary for all
"non-ignorable" assertions.

Regardless of chosen policy intersection mode, a policy assertion marked
with the wsp:Ignorable attribute does not express any requirement on the
behavior of the client, rather, it is used for intersection as indicated in
Section 2.7. After intersection, any assertions contained in the resulting
policy that are understood by the client are handled as expected. As part of
the policy expression, these assertions are not ignored, regardless of
whether they are marked with wsp:Ignorable.

Domain-specific processing could take advantage of any information from the
policy data model, such as the ignorable property of a policy assertion.

Domain specific processing can be used by a requestor to effectively
navigate which QoS (service interface) to use through its requirements. The
requestor may need to consistently apply certain assertions in order to use
that service, whether these are the requestor's own, or accepted from the
provider.

Domain specific processing by a requestor can also provide a way to trigger
alternate processing options when no alternatives are available from the
intersection alone. The requestor could be presented with the result to
determine an acceptable alternative. For example, in strict mode
intersection, no alternatives may be available as a product of the
intersection to the requestor. The requestor can then make additional
attempts at intersection in order to isolate the cause and/or determine an
acceptable alternative."

Thanks,

-Charlton.