RE: Revised positions for closed/open world assumptions

I think that there's no difference between using the client's vocabulary
vs the "total" vocabulary including the server's.  The only difference
would be if a client could do a behaviour but didn't use an assertion
for that behaviour in intersection AND the service had that assertion in
it's vocabulary, then the client might "illegally" try that assertion.
But note that this is when the client didn't use that assertion for
intersection, so what the heck is it doing?  The cases are the same when
a service offers an assertion and the client doesn't know about it, then
the service's assertion will be in the vocabulary but the client can't
do the behaviour anyway.  
 
Nevertheless, this is a 4th option to put on the table: AIN: client
vocabulary flavour.  
 
Cheers,
Dave


________________________________

	From: Rogers, Tony [mailto:Tony.Rogers@ca.com] 
	Sent: Tuesday, May 15, 2007 10:38 AM
	To: David Orchard; tom@coastin.com
	Cc: Dale Moberg; Christopher B Ferris; public-ws-policy@w3.org
	Subject: RE: Revised positions for closed/open world assumptions
	
	
	I believe not, in that I'm only considering the client's
"vocabulary", not the server's. 
	 
	I think that's an important point for two reasons:
	 
	1. the client's vocabulary may well be significantly smaller
than the server's, especially with recent developments suggesting that
the server may have to publish huge policies that explicitly list all
the alternatives. The client can readily accommodate its own vocabulary
(which is a known size) - having to accommodate a server's vocabulary
might over-tax a client on a portable device.
	 
	2. there may be some value in a facility wherein the client
provides its policy and the server returns the intersection of the
client's policy with the server's - in such a scenario the client
doesn't see the server's policy, and doesn't need to. If the server
policy is large, this could be useful
	 
	Anyway, I'll be quiet now :-)
	 
	
	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: David Orchard [mailto:dorchard@bea.com]
	Sent: Wed 16-May-07 3:17
	To: tom@coastin.com; Rogers, Tony
	Cc: Dale Moberg; Christopher B Ferris; public-ws-policy@w3.org
	Subject: 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
	>
	>
	>
	>
	>