W3C home > Mailing lists > Public > public-ws-policy@w3.org > May 2007

Re: Revised positions for closed/open world assumptions

From: Tom Rutt <tom@coastin.com>
Date: Fri, 18 May 2007 10:38:11 -0400
To: Ashok Malhotra <ashok.malhotra@oracle.com>
Cc: Christopher B Ferris <chrisfer@us.ibm.com>, "public-ws-policy@w3.org" <public-ws-policy@w3.org>
Message-id: <464DBA53.1010002@coastin.com>

Chris's way seems easier to implement, since all one needs to know is 
their own input to the intersection, and the output of intersection.

Ashok's directionality seems to imply I need to know what the other side 
put in to the intersection algorithm

Tom



Ashok Malhotra wrote:
>
> Chris, I donít see the need for directionality. How about this:
>
> P and R exchange policies and decide on an alternative.
>
> P must do whatís mandated by the selected alternative.
>
> P cannot do what was in Rís policy but was not selected.
>
> R must do whatís mandated by the selected alternative.
>
> R cannot do what was in Pís policy but was not selected.
>
> No other claims.
>
> All the best, Ashok
>
> ------------------------------------------------------------------------
>
> *From:* Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> *Sent:* Friday, May 18, 2007 6:23 AM
> *To:* Ashok Malhotra
> *Cc:* public-ws-policy@w3.org
> *Subject:* RE: Revised positions for closed/open world assumptions
>
>
> Ashok,
>
> Maybe "initiating entity" is unclear. Basically, I intend it to be the 
> entity that engages an interaction
> by retrieving the other side's policy and intersecting it.
>
> If we expand this with a request/response MEP
>
> Requestor = R
> Provider = P
>
> If A is in R's policy, but not in P's policy R does not engage that 
> behavior.
> If A is in P's policy, but not in R's policy, P does not engage that 
> behavior
> If P does not use A's policy to engage the interaction, then 
> everything is out of scope.
> One would presume that P would deal with the behaviors represented in the
> messages received from R in a manner consistent with their specification.
>
> I recognize that the intersection algorithm is direction independent. 
> The proposed
> language does not affect intersection, it just places constraints on 
> the entity that
> uses the intersected policy to engage an interaction, limiting the set 
> of behaviors
> applied to those that are implied by assertions IN the intersected 
> policy and (possibly, but we
> don't say anything about them since they are out of scope) those which 
> are NOT IN
> the initiating entity's policy.
>
> Those behaviors that are IN the initiating entity's policy but NOT IN 
> the intersected policy
> are RIGHT OUT:-)
>
> Make sense?
>
> Cheers,
>
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
> phone: +1 508 377 9295
>
> "Ashok Malhotra" <ashok.malhotra@oracle.com> wrote on 05/17/2007 
> 07:06:31 PM:
>
> > Chris:
> > In your latest note in this thread you proposed
> >
> > Proposed text added to section 4.5:
> >
> > If an initiating entity includes a policy assertion type A in
> > its policy, and this policy assertion type A
> > does not occur in an intersected policy, then the initiating
> > entity does not apply the behavior implied by
> > assertion type A.
> >
> > I have two concerns about this proposal:
> >
> > 1. It does not say anything about the policy of the responder. Is
> > the behavior different in the other direction? I think not.
> > 2. The policy intersection algorithm is direction independent. This
> > proposal introduces direction dependency and Iím wary of that. If
> > we go that way then I would like to bring up the complex of ideas
> > that say that the initiator expresses constraints Ė what you must
> > do, and the responder expresses capabilities Ė what I can do and
> > intersection works differently if viewed from the two directions.
> > If we go that route then this leads naturally into the wildcard
> > matching that DaveO and I have been proposing.
> >
> > All the best, Ashok
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133
Received on Friday, 18 May 2007 14:38:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:34 UTC