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

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

From: Glen Daniels <gdaniels@progress.com>
Date: Fri, 3 Nov 2006 12:23:18 -0500
Message-ID: <80A43FC052CE3949A327527DCD5D6B2701F8D23F@MAIL01.bedford.progress.com>
To: <public-ws-policy@w3.org>


Hi Sergey, Dale:

In these cases in general, it's a good idea to define SOME kind of wire
level indication that your desired policy is going to be followed.  For
the example below, you could define a SOAP header which you would send
along with your request (as Sergey suggests) like this:

<soap:Header>
 <retention:retainFor soap:mustUnderstand="1">
   12months
 </retention:retainFor>
 ...

There are two reasons to do something like this - first, so the provider
simply knows the correct thing to do.  Second, so that the messages can
act as some kind of legal record of the negotiated agreement between the
interacting parties.  For the first reason, this kind of simple SOAP
header works quite well.  For the second, I think we may need a somewhat
richer negotiation mechanism which allows for notarizing both parties'
agreement to the selected policy alternative... but then again sending
the request in an integrity-preserving way and simply having a log might
be good enough.

In any case, I do definitely think that some kind of standard mechanism
to do this (example - canonicalize and serialize the XML of the selected
policy alternative, take the MD5 checksum of the result, and send that
in a well-known header) is something we'll want to tackle eventually,
but for now leaving this for v.next is fine.

--Glen


> -----Original Message-----
> From: public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] On Behalf Of Sergey Beryozkin
> Sent: Friday, November 03, 2006 11: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:24:03 GMT

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