Re: assertion classes

Sverdlov, Yakov wrote:
> Sorry for pushing the same subject again but I would not separate the
> proposed assertion classes into two categories: requester and provider.

The requester and provider are not categories, they are actors. There 
can be many more actors, but I wanted to keep this as simple as possible 
for now.

> One can argue that it is possible to change the second column's title
> from "Provider" to "Requester" i.e. the requester's assertions can also:
> - "Implement behavior mandated by assertion"
> - "Implement behavior mandated by assertion, may publish assertion"
> - "Publish assertion"
> - "Support behavior mandated by assertion"
> etc
> The same exercise can be performed with the third column. You can switch
> the title from "Requester" to "Provider", and the content below will be
> applicable without significant changes.
> As Anne Anderson correctly stated in her email
> "...Both clients and services (consumers and providers) may have
> Requirements and Capabilities..."

In the table in the document, the provider owns the policy. The 
requester retrieves the policy. This document does not consider whether 
the requester has a policy of its own or whether assertions need to be 
merged or intersected. If a requester would e.g. "publish an assertion", 
it would have either changed its role and become a provider or this 
would be a new class of assertions.

But your remarks make me wonder if there would be use cases where it 
would be necessary to convey which actor owns a policy inside the policy 
itself. In simple cases that information can be derived from the context 
(a client should know from what web service it read a policy), but it 
might now always be so straight-forward with multiple actors.


> -----Original Message-----
> From:
> [] On Behalf Of Fabian Ritzmann
> Sent: Tuesday, October 10, 2006 1:32 PM
> To:
> Subject: assertion classes
> Hi,
> I tried to assemble a few characteristics of different classes of 
> assertions in the attached paper. This represents a very simplistic 
> view, but I hope it can help to untangle some tarballs and gain more 
> clarity in the discussions on optionality, advisory, and local policies 
> and assertions.
> Fabian

Received on Wednesday, 11 October 2006 14:50:39 UTC