- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Tue, 15 May 2007 10:28:38 -0400
- To: "ext Rogers, Tony" <Tony.Rogers@ca.com>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, "Dale Moberg" <dmoberg@us.axway.com>, "Christopher B Ferris" <chrisfer@us.ibm.com>, <public-ws-policy@w3.org>
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