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

RE: Revised positions for closed/open world assumptions

From: Snow, Skip <skip.snow@citi.com>
Date: Tue, 15 May 2007 10:42:47 -0400
Message-ID: <526F87F9F4FB3E4D8710C7F5DC00C5A1065ED42D@EXNJMB28.nam.nsroot.net>
To: "Frederick Hirsch" <frederick.hirsch@nokia.com>, "ext Rogers, Tony" <Tony.Rogers@ca.com>
Cc: "Dale Moberg" <dmoberg@us.axway.com>, "Christopher B Ferris" <chrisfer@us.ibm.com>, <public-ws-policy@w3.org>

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.
>
>
>
>
>
>
Received on Wednesday, 16 May 2007 03:12:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:51 GMT