RE: Client policy processing

Ashok,

I think that to say that there is no intersection is incorrect. Even if 
the entity chooses to use
an optimization such as you describe, the net effect of "deciding" that 
the two policies
are compatible is equivalent (IMO) to intersection. You just took a 
short-cut. From the
perspective of the rule we have offered, the end result should be the 
same, that only
those behaviors are engaged as a result of policy processing.

If one assumes that the virtual client policy were isomorphic with that of 
the 
provider, then there are no other behaviors that are to be applied as a 
result
of policy processing.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295

public-ws-policy-request@w3.org wrote on 05/20/2007 02:42:51 PM:

> I guess you are arguing against the IBM proposal that requires the 
> client to have knowledge of the server?s policy to know what not to do.
> 
> I have a different usecase for how low-powered clients would use 
> policy.  I think servers will publish a few well-known policies 
> identified by name.  Each policy will have a single alternative. 
> The client will identify the policy and decide if it can adhere to 
> it.  No intersection.
> 
> All the best, Ashok 
> 
> From: public-ws-policy-request@w3.org [mailto:public-ws-policy-
> request@w3.org] On Behalf Of Rogers, Tony
> Sent: Sunday, May 20, 2007 3:27 AM
> To: public-ws-policy@w3.org
> Subject: RE: Client policy processing
> 
> Earlier I suggested that it might be possible that a client could 
> submit its policy to a server, and have the server return the 
> intersection. At the time I suggested that the server might do this 
> to avoid revealing its full policy - I wasn't happy with that as a 
> use-case, though. I have since realised that there is a more 
> convincing use-case for such behaviour - a low-powered client 
> (telephone, PDA, etc) might do this so that it didn't not have to 
> compute the policy intersection, particularly if the server offered 
> a large and complex policy (one with a myriad of encryption options,
> for example). Having a low-powered client send its policy (probably 
> fairly small) to the server and having the server return the 
> intersection would be a practical solution. The low-powered client, 
> as I suggested, knows what it "asked" for, and would not use any 
> behaviours not included in the intersection the server supplied. 
> Yes, this is asymmetric, but it seems quite appropriate when there's
> an asymmetry in computational power.
> 
> Someone (I'm sorry, I don't recall who) objected to this idea, 
> saying that the client must be aware of the server's full policy, 
> because there might be something very important in it. At the time, 
> I was unconvinced, but I didn't have a good counter-argument. It has
> since occurred to me (I guess I think slowly!) that if something was
> very important to the server, it should appear in the policy 
> intersection, or the intersection should be empty. If a server, for 
> example, will refuse to serve anyone not complying with a particular
> behaviour, surely that behaviour must be present in any non-empty 
> intersection?
> 
> Additionally, I stand by my earlier suggestion, that the server 
> could also reject any request that does not comply. 
> 
> Tony Rogers
> CA, Inc
> Senior Architect, Development
> tony.rogers@ca.com
> co-chair UDDI TC at OASIS
> co-chair WS-Desc WG at W3C
> 
>