- From: Maryann Hondo <mhondo@us.ibm.com>
- Date: Wed, 11 Oct 2006 07:14:58 -0600
- To: Fabian Ritzmann <Fabian.Ritzmann@Sun.COM>
- Cc: public-ws-policy@w3.org, public-ws-policy-request@w3.org
- Message-ID: <OFF1166F7B.B17235E7-ON87257204.00472192-85257204.0048C817@us.ibm.com>
Fabian, I can't help but notice the similarity to the "usage" assertion attribute in the first version of the spec[ http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-polfram/ws-policy2003.pdf] :-) The problem we ran into was how is this "class" or "attribute" processed in the intersection and merge operations? And what processing can the framework do? and what is left to the individual domains ( i.e, how do I know if I'm a proprietary requestor? or a proprietary provider? ( I must confess, this one baffles me a bit....but maybe its like the "ignored"). Could you please elaborate on how this proposal for "classes" affects the following: attachment models ( WSDL, UDDI, etc) intersection policy authoring what is normative? what is a "guideline"? Maryann Value Meaning wsp:Required The assertion must be applied to the subject. If the subject does not meet the criteria expressed in the assertion a fault or error will occur. wsp:Rejected The assertion is explicitly not supported and if present will cause failure. wsp:Optional The assertion may be made of the subject but it is not required to be applied. wsp:Observed The assertion will be applied to all subjects and requesters of the service are informed that the policy will be applied. wsp:Ignored The assertion is processed, but ignored. That is, it can be specified, but no action will be taken as a result of it being specified. Subjects and requesters are informed that the policy will be ignored. Fabian Ritzmann <Fabian.Ritzmann@Sun.COM> Sent by: public-ws-policy-request@w3.org 10/10/2006 01:32 PM To public-ws-policy@w3.org cc 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 -- Fabian Ritzmann Sun Microsystems, Inc. Stella Business Park Phone +358-9-525 562 96 Lars Sonckin kaari 12 Fax +358-9-525 562 52 02600 Espoo Email Fabian.Ritzmann@Sun.COM Finland
Attachments
- application/octet-stream attachment: AssertionClasses-3.pdf
Received on Wednesday, 11 October 2006 13:15:20 UTC