RE: Revised positions for closed/open world assumptions

> I would like 1+2+3 but we can discuss.

Chris' latest proposal [1] dated May 16th directly addresses your items 1 and 2. Will the second sentence below satisfy your item 3?

"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. If a policy assertion type Z is not included in the policies being intersected then the intersected policy says nothing about the behavior implied by the assertion type Z."

[1] http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0181.html

Regards,

Asir S Vedamuthu
Microsoft Corporation


From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Ashok Malhotra
Sent: Wednesday, May 16, 2007 8:47 AM
To: Christopher B Ferris
Cc: David Orchard; public-ws-policy@w3.org; public-ws-policy-request@w3.org
Subject: RE: Revised positions for closed/open world assumptions

Hi Chris:
I think we are getting close.

I see a spectrum of 3 possible positions:

1. Your words below which say - do what the selected alternative says you must do.

2. Add words that say -- and do not do what was in alternatives that you could have selected and did not [This is essentially what's in the spec now].

3. Add words that say -- for assertions/behaviors not in the policy we make no claims as long as the above agreements are not violated.

I would like 1+2+3 but we can discuss.

All the best, Ashok

________________________________
From: public-ws-policy-request@w3.org [mailto:public-ws-policy-request@w3.org] On Behalf Of Christopher B Ferris
Sent: Friday, May 11, 2007 1:59 PM
To: Ashok Malhotra
Cc: David Orchard; public-ws-policy@w3.org; public-ws-policy-request@w3.org
Subject: RE: Revised positions for closed/open world assumptions


Ashok,

Maryann and I have been thinking about your concerns. Possibly, the confusion relates to the scope to
which this proposal applies.

It is our understanding that it applies to those aspects of behavior that are controlled/influenced
by policy framework processing... e.g. those behaviors that are engaged, configured, constrained by policy.

Clearly, there is going to be behavior that is outside the domain of policy. That is not relevant
to policy (though it may be relevant to interoperation, which I believe may be Dale's point).

There may even be behavior that is subsequently documented by policy assertions that
are unknown to an implementation at the time of its deployment. These too are out of
scope of consideration of the policy framework processing as it relates to what is or is not applied in the
context of an alternative that does not include such unknown assertions.

Does that make things any clearer?

Consider the following example

client policy:

<Policy>
  <A/>
  <B/>
  <C wsp:Optional='true'/>
</Policy>

server policy:

<Policy>
  <A/>
  <B/>
</Policy>

intersection would yield:

<Policy>
  <A/>
  <B/>
  <A/>
  <B/>
</Policy>

Would you engage C anyway?

It is our understanding that if you have an entity that engages C (from your previous example) when C is IN the
alternative selected for interaction with the attached policy subject, that it would NOT engage
that behavior when C is absent the alternative selected for interaction with the attached
policy subject.

Under the "makes no claims" regime, an implementation would be free to do C even though it were not in
the intersected alternative, because the interpretation of that alternative (A, B, A, B) says nothing about whether
C may or may not be applied.

What is the point of performing intersection to determine the compatible alternative(s) if the implementation
isn't going to bother to abide by the resulting policy to engage in the interaction?

This may seem like it is drifting back towards the notion of policy vocabulary. But, the fact is that
I think as you point out, you need to at least know what you know and behave in a consistent manner with
regards to what the policy says and the behaviors you apply in the context of the interaction.

The point of policy is to enable interoperation between Web services components. In order for it to be
effective, there needs to be a shared understanding as to what the policy means and we need
to have the respective endpoints behaving in a consistent manner relative to the policies that are
used to determine the set of compatible alternatives from which to choose for purposes of interaction.

Maryann and I have been noodling on language that tries to capture our intent better. So, rather than
add the "No other behaviors are to be applied" language, we think that maybe if we added the following
prose to section 4.5 Intersection, just before the algorithm is described, that that might clear up the confusion
while at the same time preserving the semantic that we believe to be important.

New text for section 4.5:

If the intersection algorithm produces a policy alternative, common to both parties, it indicates that the behaviors
implied by the assertions in that policy alternative are an implicit contract and will be applied for any interaction
based on that alternative. Any behaviors not represented by policy assertions in that alternative are out of scope
and not applied as a result of policy framework processing.

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/11/2007 08:17:27 AM:

>
> Note that 2 requires additional information, namely, all the
> assertions/behaviors in the closed world.  How is this information
> conveyed to the policy engine?
>
> All the best, Ashok
>
> > -----Original Message-----
> > From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
> > request@w3.org] On Behalf Of David Orchard
> > Sent: Thursday, May 10, 2007 2:11 PM
> > To: public-ws-policy@w3.org
> > Subject: Revised positions for closed/open world assumptions
> >
> >
> > Here's my revised estimate of the positions:
> >
> > Overview
> > There are roughly 3 positions that may be taken on the issue of the
> > meaning of assertions in alternative(s).
> >
> > 1. AIN Vocabulary flavour:
> > Any behaviour not implied by an assertion that is in a vocabulary should
> > not be applied (Roughly original chris proposal)
> >
> > No proponents. No further elaboration planned.
> >
> > 2. AIN Closed world flavour (revised MSFT/IBM proposal):
> > Any behaviour not implied by an alternative must not be applied.  Any
> > behaviors implied by assertions in an alternative must be applied.
> >
> > Questions:
> > 1. Is it OK to omit Ignorable="true" Assertion?
> > 2. Is it OK to omit Optional="true" Assertion?
> >
> > Pros
> > This ensures that a provider will provide a "complete" description of
> > the behaviors and thus guarantee interop including optional/ignorable.
> >
> > Cons
> > Pending questions, may limit providers ability to apply behaviors.
> >
> > 3. AIN Removal (open world):
> > Any behaviour not implied by any assertions in an alternative may or may
> > not be applied.  Any behaviors implied by assertions in an alternative
> > must be applied.
> >
> > Pros
> > Perception of "simpler" specification.  Allows service fuller control
> > over application of behaviors.
> >
> > Cons
> > Provider might not provide "complete" description.  Interop is
> > guaranteed but optional and/or ignorable behaviors may be missed by
> > clients.
> >
> > Cheers,
> > Dave
> >
>
>