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.
>
>
>
>
>
>

Received on Tuesday, 15 May 2007 14:29:16 UTC