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

RE: Revised positions for closed/open world assumptions

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Fri, 18 May 2007 15:29:11 -0400
To: "David Orchard" <dorchard@bea.com>
Cc: "Ashok Malhotra" <ashok.malhotra@oracle.com>, public-ws-policy@w3.org, public-ws-policy-request@w3.org
Message-ID: <OF84266A30.3B02D14E-ON852572DF.006AD2DB-852572DF.006AE903@us.ibm.com>
Not necessarily. In an asynchronous exchange, P might well engage an 
interaction with the ReplyTo endpoint.

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

public-ws-policy-request@w3.org wrote on 05/18/2007 02:31:23 PM:

> How does P know what is in R's policy?  It isn't doing the 
> intersection.  It just get the bits on the wire based upon what R 
> decides to do.
> 
> Cheers,
> Dave
> 
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
> request@w3.org] On Behalf Of Christopher B Ferris
> 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 
Received on Friday, 18 May 2007 19:29:40 UTC

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