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

Here is a *revision* (having minor changes) to the proposal to close
Issue 4393:

 

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, in the 3rd
paragraph, 4th sentence as follows:

 

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

 

Add to 3.4.1 Strict and Lax Policy Intersection, after the 4th paragraph
as follows:

 

"In certain cases the provider may intend for their policy or policies
to be intersected using one mode, while a requestor may not support that
same mode while they both have expectations on expected results. For
example, a provider of a service which handles line of business (LOB)
processing can provide a number of qualities of service (QoS) which are
exposed as policies. A requestor can effectively navigate which QoS
(service interface) to use through its requirements. 

However, the requestor of an LOB processing service may need to
consistently apply certain assertions in order to use a service, whether
these are the requestor's own, or accepted from the provider. In
particular, requestors which require strict mode intersection could
encounter unnecessary intersection results such as failures (no policy
alternatives available) without any information as to why the failure
occurred. In such cases it is useful for the requestors to apply
multiple intersection modes when consuming policies and comparing the
results, in order to detect conflicts and specify their source.

 

Regardless of chosen policy intersection mode, the wsp:Ignorable marker
on a policy assertion 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, and are not ignored, regardless whether those assertions are
marked with wsp:Ignorable."

 

-Charlton.

--

 

Charlton Barreto
Senior Computer Scientist
Adobe Systems Incorporated
345 Park Avenue, MS E15
San Jose, CA 95110-2704 USA
408.536.4496 p   
415.692.5396 m
charltonb@adobe.com