This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4292 - Intersection mode is neither defaulted nor specified
Summary: Intersection mode is neither defaulted nor specified
Status: RESOLVED WONTFIX
Alias: None
Product: WS-Policy
Classification: Unclassified
Component: Framework (show other bugs)
Version: FPWD
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Felix Sasaki
QA Contact: Web Services Policy WG QA List
URL:
Whiteboard:
Keywords: futureConsideration
Depends on:
Blocks:
 
Reported: 2007-01-31 16:16 UTC by Charlton Barreto
Modified: 2007-03-14 17:15 UTC (History)
1 user (show)

See Also:


Attachments

Description Charlton Barreto 2007-01-31 16:16:32 UTC
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.
Comment 1 Charlton Barreto 2007-01-31 18:35:54 UTC
Note that this is an issue for v.next
Comment 2 Christopher Ferris 2007-03-14 17:15:16 UTC
[13:12] scribe: RESOLUTION: Issue 4292 Resolve as v.next.
[13:12] scribe: RESOLUTION: Issue 4292 Open new primer issue to address poor man's selection. 
[13:12] paulc: rssagent, where am i
[13:12] cferris: rrsagent, where am i?
[13:12] RRSAgent: See http://www.w3.org/2007/03/14-ws-policy-irc#T17-13-34
[13:13] cferris: ACTION: Charlton to open new primer issue to relate to the discussion of 4292
[13:13] * trackbot noticed an ACTION. Trying to create it.
[13:13] * RRSAgent records action 3
[13:13] trackbot: Created ACTION-255 - Open new primer issue to relate to the discussion of 4292 [on Charlton Barreto - due 2007-03-21].