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

Hi Sergey,

 

The consumer can dictate the intersection mode but a provider may
require that a particular mode be applied in order to consumer its
messages. Since lax mode addresses compatibility for non-ignorable
policy assertions, is it correct to say that to have a provider declare
its assertions as ignorable is equivalent to declaring them as lax?

 

Possibly the question to address is this: Is it appropriate for a
provider to declare assertions ignorable when it really intends for lax
mode to be applied? Since lax mode addresses compatibility testing for
non-ignorable assertions, one can fathom the scenario where a provider
intends for consumers to use the policy in this mode (test the
non-ignorable assertions). 

 

Although the end result in terms of processing may be the same, it would
be useful to understand why the failure occurs. Your statement that
strict consumers will unnecessarily fail if they see unrecognized
assertions which are safe to be ignored definitely applies. I would add
that strict consumers would also fail without necessarily being able to
report the precise reason they failed. 

 

I see the main issue being the enablement of the consumer to report why
failures occur, which is a refinement of what we currently have in the
framework. 

 

-Charlton.

 

________________________________

From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com] 
Sent: 14 March 2007 09:30
To: Charlton Barreto; public-ws-policy@w3.org
Subject: Re: [NEW ISSUE] v.next: Intersection mode is neither defaulted
nor specified [Issue 4292] 

 

Hi

 

This is tagged as a v.next issue but I'd like to ask a clarification.

 

> provider requires one mode

 

Isn't it a consumer which dictates in what mode the intersection mode ?
Provider are not working in the lax/strict mode, unless they may be
(direct/indirect) consumers themselves, right ?

 

For example, we've just have the issue closed where the primer advises
the ignorable assertion author to be aware that the impact of the
ignorable attribute at the discretion of the consumer. By introducing a
wsp:ignorable assertion the author actually wishes/requires the lax mode
be used for the intersection purposes but the consumer is free to ignore
this wish/request and just use a strict mode.

 

I just don't understand what a strict consumer would do it if saw this
proposed mode statement ? It seems to me it would just duplicate what
the provider is already trying to say by using "ignorable assertions".

 

I propose to tackle the problem from the different angle. I believe the
actual problem is that the fact that consumers can choose to be strict
limits the exposure of policies which contain the ignorable assertions. 

Or the problem can be presented like this : strict consumers will
unnecessarily fail if they see unrecognized assertions which can
actually are safe to be ignored.

 

Strict mode is about failing when seeing unrecognized assertions,
irrespectively of how they're marked.

I propose for the framework to let assertion authors to assert somehow,
through the security signatures, etc, that the given ignorable assertion
is safe to ignore and update the rules for the strict mode to let such
unrecognoized ignorable assertions be actually ignored in the automatic
mode. 

 

Cheers, Sergey

	----- Original Message ----- 

	From: Charlton Barreto <mailto:barreto@adobe.com>  

	To: public-ws-policy@w3.org 

	Sent: Wednesday, March 14, 2007 2:07 PM

	Subject: [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