RE: Revised positions for closed/open world assumptions

Skip,

It has never been the case that a consumer understand all of the 
assertions in the producer's policy
in order to be able to interact with that producer. All that has ever been 
necessary is that the two policies
have at least one compatible alternative resultant from intersection. If 
there is a compatible alternative,
then it is presumed that both parties understand the set of assertion 
types present in that compatible
alternative since the assertion types were present in both policies (one 
would assume that if you 
use an assertion type in your policy, that you understand its semantic).

The intent here is to ensure consistent behavior with regards to policy 
framework
processing that adheres to the Rumsfeldian view of the world: there are 
knowns that you
know, unknowns that you know and unknowns that you don't know. All we are 
trying to
say here is that __as a result of policy framework processing__ that the 
initiator of
an interaction governed by policy will not intentionally apply behaviors 
implied by
assertion types it knows about in the case where the intersected policy 
does NOT contain
those assertion types.

The example I have been using is one in which the consumer's policy is

<Policy>
  <ExactlyOne>
    <All>
      <A/>
      <B/>
      <C/>
    </All>
    <All>
      <A/>
      <B/>
    </All>
  </ExactlyOne>
</Policy>

And the producer's policy is:

<Policy>
  <ExactlyOne>
    <All>
      <A/>
      <B/>
    </All>
    <All>
      <A/>
      <B/>
      <D/>
    </All>
  </ExactlyOne>
</Policy>

The result of intersection would be:

<Policy>
  <ExactlyOne>
    <All>
      <A/>
      <B/>
      <A/>
      <B/>
    </All>
  </ExactlyOne>
</Policy>

Note the absence of C in the intersected policy. What we are trying to 
make clear is that the behavior
implied by C would not be applied in the interaction. Behavior implied by 
D **might** be applied, but 
the consumer is not presumed to know anything about D since D is not 
present in the consumer's policy.
Certainly, we would not expect D to be applied __as a result of policy 
framework processing__ because
D is not present in the consumer's policy. However,  something else in the 
implementation of the consumer 
might apply that behavior ostensibly ignorant of the fact that that 
behavior is implied by D.

Behavior implied by Z, an assertion type wholly absent from both policy 
expressions is completely out of
scope of the ___policy processing framework___. 

In the above example, from the consumer's perspective, A, B and C are the 
knowns that it knows. D is the
unknown that it knows. Z is the unknown that it doesn't know.

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/15/2007 10:42:47 AM:

> 
> I would very much object to an abdication of the consumer's obligation
> to understand the producer's policy. Have I missed a resolved issue? Am
> I misunderstanding the content of Tony's message?
> 
> Thanks 
> 
> -----Original Message-----
> From: public-ws-policy-request@w3.org
> [mailto:public-ws-policy-request@w3.org] On Behalf Of Frederick Hirsch
> Sent: Tuesday, May 15, 2007 10:29 AM
> To: ext Rogers, Tony
> Cc: Frederick Hirsch; Dale Moberg; Christopher B Ferris;
> public-ws-policy@w3.org
> Subject: Re: Revised positions for closed/open world assumptions
> 
> 
> This seems a clear explanation that might be appropriate for the
> guidelines.
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> On May 14, 2007, at 10:52 PM, ext Rogers, Tony wrote:
> 
> > I hesitate to add to the confusion, but I had an idea.
> >
> > Thinking from the point of view of a client, I know what assertions 
> > and alternatives I included in my policy (let us be conventional, and 
> > posit that I had assertions A, B, and C in my policy, and let us 
> > assume that the intersection with the server policy includes only A 
> > and B).
> >
> > Then I think I can make three statements:
> >
> > 1. I can definitely use the behaviours associated with assertions A 
> > and B, because I "asked" about them, and they appeared in the 
> > intersection.
> >
> > 2. I can definitely NOT use the behaviour/s associated with assertion 
> > C, because I "asked" about it, and it did not appear in the 
> > intersection.
> >
> > 3. I do not know if the server supports the behaviour/s associated 
> > with assertion D, because I didn't "ask" about it. However, it would 
> > be unreasonable to expect to use these behaviours because I didn't 
> > "ask" about it. If I wish to use D's behaviour/s, I should have 
> > included it in my policy.
> >
> > Is that a reasonable way to look at the problem? It seems to me that 
> > the discussions of open and closed worlds can be reduced to the space 
> > of the assertions about which I (as client) "ask". If I don't ask 
> > about something, then I don't know if it is supported or not, but it 
> > seems unreasonable to expect it to be supported without "asking". I 
> > guess we could say that there is nothing to stop the client attempting
> 
> > to use such a behaviour, but it should be prepared to have it "fail" 
> > (for some meaning of "fail").
> >
> > Note that I do not posit the client inspecting the server's policy 
> > statement - that could be done, but it could also be that the client 
> > sends its policy to the server, and receives the intersection in 
> > return (the server might not publish its complete policy statement).
> >
> > Tony Rogers
> > tony.rogers@ca.com
> >
> >
> > From: public-ws-policy-request@w3.org [mailto:public-ws-policy- 
> > request@w3.org] On Behalf Of Dale Moberg
> > Sent: Tuesday, 15 May 2007 3:40
> > To: Christopher B Ferris
> > Cc: public-ws-policy@w3.org
> > Subject: RE: Revised positions for closed/open world assumptions
> >
> > Chris Ferris writes:
> >
> > 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.
> >
> >
> >
> > DaleMoberg>> OK, by switching to an explanation of a "policy
> > processing model," I think a lot of the "logical quibbles" can drop 
> > out, and that I think is an improvement. The language is not 
> > encroaching on the semantic options that domain policy assertion 
> > designers have available.
> >
> >
> >
> > It seems that the advice actually gets close to common sense now, for 
> > you appear to be saying that once you select a policy alternative, 
> > engage in the behavior that you intend to engage in!
> >
> >
> >
> > The other alternatives are "out of scope" once your policy 
> > alternative (for which you found a match) is selected. And if you 
> > included behavior that triggered other provider-supported policy 
> > assertions (present in other alternatives), then the other side can 
> > be expected to make a response, and you might not be prepared for 
> > it! Or something like that might occur that messes up the interaction.
> >
> >
> >
> > The phrase "implicit contract" though seems a stretch. Suppose the 
> > policy provider offers several policy alternatives. The policy 
> > provider presumably does not care what policy alternative is 
> > selected by the policy consumer, and unless the provider was being 
> > deceptive, permits the consumer to jump from one alternative to 
> > another. Is there any presumption that in the case where several 
> > policy alternatives are in common between consumer and provider, 
> > that the consumer cannot engage one set of behaviors one time and 
> > another set of behaviors the next time? I personally can't 
> > understand how to get that commitment over time out of ws-policy at 
> > present. If the commitment is just for one time, then the advice 
> > boils down to the truism, that a consumer should be consistent 
> > between his selected policy alternative intentions and his WS 
> > behaviors.
> >
> >
> >
> > I am guessing that if there is push-back now, it will be because 
> > the proposed policy processing model impinges on somebody's planned 
> > implementation.
> >
> >
> >
> >
> >
> >
> 
> 
> 
>