RE: Revised positions for closed/open world assumptions

Isn't this the first option that I listed a while ago, which is AIN wrt
policy vocabulary?

Cheers,
Dave 

> -----Original Message-----
> From: public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] On Behalf Of Tom Rutt
> Sent: Tuesday, May 15, 2007 9:38 AM
> To: Rogers, Tony
> Cc: Dale Moberg; Christopher B Ferris; public-ws-policy@w3.org
> Subject: Re: Revised positions for closed/open world assumptions
> 
> 
> 
> I very much like this interpretation.
> 
> Tom Rutt
> 
> 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 <blocked::mailto: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.
> >
> 
> --
> ----------------------------------------------------
> Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133
> 
> 
> 
> 
>

Received on Tuesday, 15 May 2007 17:18:31 UTC