W3C home > Mailing lists > Public > public-ws-policy@w3.org > May 2007

Re: Client policy processing

From: Anthony Nadalin <drsecure@us.ibm.com>
Date: Wed, 9 May 2007 08:29:03 -0500
To: Frederick Hirsch <frederick.hirsch@nokia.com>
Cc: Hirsch Frederick <frederick.hirsch@nokia.com>, ws policy <public-ws-policy@w3.org>, public-ws-policy-request@w3.org
Message-ID: <OFD29DE2D1.2F1C0FDF-ON862572D6.0049B88C-862572D6.004A123B@us.ibm.com>

I would say this is all optional, as the client may not have assess to its
own policy or the ability to actually process the policy (limited device).
i get worried that if we don't have absence means negation that we will
wind up in spots where it will be hard or impossible to know the actual
policy that was in effect.

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

             Frederick Hirsch                                              
             @nokia.com>                                                To 
             Sent by:                  ws policy <public-ws-policy@w3.org> 
             public-ws-policy-                                          cc 
             request@w3.org            Hirsch Frederick                    
             05/08/2007 05:03          Client policy processing            

Is it correct to say:

1. Client has access to its own policy, the provider policy and the
result of intersection which it performed
2. Result of intersection is a policy in its own right, and has no
implicit meaning other than what is stated in that policy (with its
own vocabulary)
3. Client can interpret that result-of-intersection policy together
with provider policy to infer acceptable interactions with provider,
based on vocabulary present in provider policy.

Thus the policy that results from intersection itself does not say
negation, but it can be inferred from that policy taken in
conjunction with provider policy.

Is this an approach toward making this less confusing?


regards, Frederick

Frederick Hirsch

(image/gif attachment: graycol.gif)

(image/gif attachment: pic31507.gif)

(image/gif attachment: ecblank.gif)

Received on Wednesday, 9 May 2007 16:41:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:34 UTC