[NEW ISSUE] v.next: Intersection mode is neither defaulted nor specified [Issue 4292]

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

 

Title: Intersection mode is neither defaulted nor specified [v.next]

Target: v.next of Framework specification (
http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.h
tml?content-type=text/html;%20charset=utf-8)
25 January 2007

 

Description: A potential problem exists with intersection mode
selection. Intersection mode is not defaulted in the Framework
specification, and mode indication is not specified. This leaves
Framework open to implementations where a provider requires one mode and
a client may or may not interpret it, and may or may not support that
same mode. From the implementation perspective, a consumer will not be
able to talk to a provider and not be able to report why. 

At present, a consumer can only detect that a service request has failed
when intersection cannot be performed. Intersection rules as specified
in Framework do not provide for a standard way of reflecting why
intersection could not be performed - intersection can fail for reasons
other than the policies incompatibility as driven by mode (e.g. a policy
not being complete when intersection is attempted). Intersection may
also fail due to poorly written policies which would not be compatible
regardless of mode.

 

Consider:

Scenario 1:

            Entity A: Service policy requires that any intersections
apply lax mode

            Entity B: Service policy requires that any intersections
apply strict mode

 

In the current Framework spec

            1. Entity B attempts to use Entity A's service. Entity A's
required lax mode conflicts with Entity B's required strict mode and
Entity B's request will fail.

            2. Entity B reports that the request failed, but cannot
report why.

 

For example, a provider of a service which handles LOB processing can
provide a number of QoS which are exposed as policies. A consumer can
effectively navigate which QoS (service interface) to use through its
requirements. However, a consumer 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 certifying/validating it's interaction with the service). 

 

Scenario 2:

            Entity A: Service policy requires that any intersections
apply strict mode

            Entity B: Service policy accepts strict intersection but,
but the entity doesn't implement strict

 

In the current Framework spec

            1. Entity B attempts to use Entity A's service, but has not
implemented handling of strict mode intersection and this fails in its
request.

            2. Entity B reports that the request failed, but cannot
report why. 

 

For example, a provider has a service which, while ignorable,
prioritises its policies (strict) - for example, an internet banking
service which always requires its security and reliability policies to
the exclusion of a consumer's requirements. However, certain consumers
of this service type may be required to use their own security policies
- they may not have implemented the capacity to use the provider's
service with the provider's required security policy (thus supporting
only lax). 

 

Either scenario highlights the fact that strict and lax mode, as
ignorable is currently specified, can be used exclusively by either
consumer or provider. As such, WS-Policy needs to address cases where
they are used as such.

            

Proposal: Specify the indication of intersection mode in the Framework
spec and specify that the default intersection mode is strict.

 

Spec text to add to Framework:

            The wsp:IntersectionMode element indicates the mode required
by a policy assertion for intersection. The default intersection mode is
strict. 

 

            <wsp:IntersectionMode>

   <anyElementQName>

      standard-elements

   </anyElementQName>

</wsp:IntersectionMode>

 

The schema outline for this element is as follows:

 

            <wsp:Policy ... > 

  ...

  <xsd:element ref="IntersectionMode" />

  ...

              <xsd:element name="IntersectionMode"
type="tIntersectionMode" />

  <xsd:complexType name="tIntersectionMode">

    <xsd:sequence>

      <xsd:any namespace="##other" processContents="lax" />

    </xsd:sequence>

  </xsd:complexType>

  ... 

</wsp:Policy>

 

            The following describes the Element Information Item defined
in the schema outline above:

 

            /wsp:Policy/wsp:IntersectionMode

 

            This attribute is of type wsp:tIntersectionMode. If the
actual value (See XML Schema Part 1 [XML Schema Structures]) is
"strict", the policy's supported intersection mode is strict. If the
actual value is "lax", the policy's supported intersection mode is
"lax". If the actual values are "strict" and "lax", the policy's
supported intersection modes are "strict" and "lax". Omitting this
attribute is semantically equivalent to including it with a value of
"strict".

 

Note that the proposed wsp:IntersectionMode provides for extensibility.
As additional intersection modes are defined and implemented, this
element can be used to specify their use.        

                                    

In the first scenario above, if Entity B could reliably consume the
intersection mode emitted by Entity A in its policy, it could interpret
that A requires lax; in the second, if Entity B could reliably consume
the intersection mode emitted by Entity A in its policy, it could
interpret that A requires strict. In either case, with the changes in
this proposal, Entity B can:

            1. Not fail and perform some other logic to manager the
situation

            2. Fail and report the actual cause of failure

 

Best,

 

-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