Re: Revised positions for closed/open world assumptions

Chris,
More clarification is needed to understand two important aspects of the 
latest IBM proposal:

1. Use of only one policy alternative (not a mixture of several, just one)
2. The meaning of 'initiating entity'

I would like us to investigate these two questions briefly in hopes of 
bringing together
ideas that will lead to consensus. Note, that the word ENTITY is used 
until an
appropriate term is identified by the WG.

1. Use of only one policy alternative (not a mixture of several, just 
one) in explicit text.
Could we add something like th following to your existing text?:
* [add] AN ENTITY can engage the behaviors of a compatible policy 
alternative
when the policy alternative is part of the intersection result. Although 
more than
one policy alternative may exist in an intersection result, only one policy
alternative of all the expected behaviors is engaged.
* [add] If an ENTITY includes a policy assertion type A in its policy, 
and this
policy assertion type A does not occur in an intersected policy, then 
that ENTITY
does not apply the behavior implied by assertion type A.
2. The meaning of 'initiating entity':
* This term is ambiguous - what is the scope of this entity -
the policy intersection or the web service initiator? What
about intermediaries? The term needs to be unambiguous to
identify the ENTITY that engages the service. This is
somewhat challenging because the ENTITY that engages the
service may or may not know what that policy assertion type
A was in the policy of the policy requester/consumer/etc.

For example, there probably will be scenarios where two entities put 
forth policy
expressions for intersection, and each is then only made aware of the 
policy
intersection result. Each ENTITY may or may not have knowledge of the 
policy
expression the other ENTITY put forth for the intersection.

Tom Rutt

Christopher B Ferris wrote:
>
> 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 Monday, 21 May 2007 18:01:25 UTC