RE: Revised positions for closed/open world assumptions

I think you may have misunderstood. What I said about D was that the client did NOT know if it could be used, and should NOT use it because of that. Put another way, if you don't "ask" about something, you can't then use it, or if you do, you must be prepared for it to "fail".
 
Tony Rogers
CA, Inc
Senior Architect, Development
tony.rogers@ca.com
co-chair UDDI TC at OASIS
co-chair WS-Desc WG at W3C

________________________________

From: Snow, Skip [mailto:skip.snow@citi.com]
Sent: Wed 16-May-07 0:42
To: Frederick Hirsch; Rogers, Tony
Cc: Dale Moberg; Christopher B Ferris; public-ws-policy@w3.org
Subject: RE: Revised positions for closed/open world assumptions



Fredrick:

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 Tuesday, 15 May 2007 17:27:28 UTC