- From: Dale Moberg <dmoberg@us.axway.com>
- Date: Fri, 3 Nov 2006 10:23:38 -0700
- To: "Sergey Beryozkin" <sergey.beryozkin@iona.com>, <public-ws-policy@w3.org>
My goal was to produce a "use case" where there was not any wire manifestation of the service consumer's intent with respect to the service provider's capabilities. You are providing a different use case with different features (especially the wire manifested feature), and as such the example would "work" but as a different kind of use case and as long as someone writes a spec for "ws-retention" explaining the headers! In general, there are various tradeoffs between adding stuff to message metadata and just having an agreement in effect. So far I have never participated in two groups that shared the same equilibrium point on where that tradeoff should be. -----Original Message----- From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com] Sent: Friday, November 03, 2006 9:48 AM To: Dale Moberg; public-ws-policy@w3.org Subject: Re: ISSUE (3639) Which policy alternative was selected? Hello, Can an assertion like <retention:ExactlyTwelveMonths/> be redifined like this : <retention:retentionPeriod> <period>12months</period> </retention:retentionPeriod> The semantics of retention:retentionPeriod is that a requester should send a header confirming with a parameterized value. Furthemore, the documentation for the retention:retentionPeriod states that if no confirmation is sent then a default period of 6 months will be in effect. Does it work or not ? Thanks, Sergey [ MTOM stuff deleted and mailing list pruned...] ISSUE (3639) Which policy alternative was selected Though the MTOM example has provided some interesting conversation, at least one original issue that I thought was in this thread on ISSUE 3639 was why it would be useful to have a service consumer inform a service provider which policy alternative the service consumer had selected. First, if there are wire manifestations of the consumer's policy choice (so that the provider can tell what policy is operative by looking at the consumer's message), the main kind of use cases for informing the provider of the consumer's choice would be if the consumer was (by convention) not allowed to change from conforming to one policy alternative to conforming to another policy alternative "dynamically" (that is, to make use of a different policy alternative at the service consumer's whim). I think that there are IT departments that like things to be tidy in this way, but I would like to consider another type of use case, not involving anything in the consumer's message indicating the "choice" of policy alternative. So instead... Consider that there are provider policy alternatives for business document archiving that have to meet variable (US) state retention requirements. For example, suppose (US) states varied in how long they required out of state businesses to retain electronic business documents. Also, suppose that different states required 12 months, 3 years, or seven years. A business might then announce its capabilities with respect to business document retention functionality as: <Policy> <ExactlyOne> <All> <retention:ExactlyTwelveMonths/> <!-- other stuff --> </All> <All> <retention:ExactlyThreeYears/> <!-- other stuff --> </All> <All> <retention:AtLeastSevenYears/> <!-- other stuff --> </All> </ExactlyOnce> </Policy> It would at least be difficult for a provider to know how long to retain the records without getting some feedback about which of the provider's retention capabilities is to be used for a given service consumer. To be on the safe side, possibly retain all documents for 7 years? But if the other side expected that the documents would be erased after legal requirements expired, as the element names are intended to suggest, that wouldn't suffice. The SOX world is full of such interactions being needed, and though these are not "technical" policies, examples like these show why consumer/provider alignment on operative policy alternatives could be useful. It might, however, be better to treat these issues in v.next, when possibly preference over policy alternatives and negotiation would come into scope.
Received on Friday, 3 November 2006 17:23:57 UTC