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

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 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, a requestor of an
LOB processing service may be required to always apply either its own
assertions or always accept the provider's base (e.g. always accepting
the provider's base assertions as a way of supporting its interaction
with the service). 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 mode, the wsp:Ignorable marker does not affect the
behavior of the client. If the resulting policy contains assertions
marked with wsp:Ignorable, those assertions the client understands are
not ignored."

 

--

 

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