W3C home > Mailing lists > Public > public-ws-policy@w3.org > November 2006

RE: ISSUE (3639) Which policy alternative was selected?

From: Dale Moberg <dmoberg@us.axway.com>
Date: Fri, 3 Nov 2006 10:23:38 -0700
Message-ID: <97085FEE4C8BDB4AB6FA3E770EBC79BB697BA6@mail1.cyclonecommerce.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:20:43 GMT