W3C home > Mailing lists > Public > public-ws-policy@w3.org > May 2007

Re: policy vocabulary, will not be applied, oh my!

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Tue, 08 May 2007 17:54:37 -0700
Message-ID: <46411BCD.8040409@oracle.com>
To: Daniel Roth <Daniel.Roth@microsoft.com>
CC: Ashok Malhotra <ashok.malhotra@oracle.com>, Asir Vedamuthu <asirveda@microsoft.com>, Christopher B Ferris <chrisfer@us.ibm.com>, "public-ws-policy@w3.org" <public-ws-policy@w3.org>

Daniel Roth wrote:
> Hi Anish,
> 
>> is policy always meant to be complete?
> 
> If you leave required behaviors out of your policy, then requesters won't know to enable those behaviors and intersection results won't be meaningful.
> 

Yes, but what about non-required behaviors?

I'm trying to figure out why "no claims" and interop is a problem only 
in the context of alternatives/implied negation. This seems to be a 
general issue. Perhaps that is what you meant too.

-Anish
--

> Daniel Roth
> 
> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> Sent: Tuesday, May 08, 2007 4:54 PM
> To: Daniel Roth
> Cc: Ashok Malhotra; Asir Vedamuthu; Christopher B Ferris; public-ws-policy@w3.org
> Subject: Re: policy vocabulary, will not be applied, oh my!
> 
> Curious: is policy always meant to be complete?
> For example, in the case where there is only one alternative, is there
> no unstated behavior?
> 
> -Anish
> --
> 
> Daniel Roth wrote:
>> Hi Ashok,
>>
>>
>>
>> The problem with "no claims" is that you no longer know if a policy is
>> complete or not (there may be unstated behaviors), which means you can
>> never be sure if you are going to interoperate.
>>
>>
>>
>> Daniel  Roth
>>
>>
>>
>>
>>
>> *From:* Ashok Malhotra [mailto:ashok.malhotra@oracle.com]
>> *Sent:* Tuesday, May 08, 2007 2:18 PM
>> *To:* Daniel Roth; Asir Vedamuthu; Christopher B Ferris;
>> public-ws-policy@w3.org
>> *Subject:* RE: policy vocabulary, will not be applied, oh my!
>>
>>
>>
>> Thanks, Dan, for clarifying.
>>
>>
>>
>> So, NOBI has implied negation.  We would rather not have this.  Here is
>> how I would phrase it.  Monica also suggested explicit phrasing.
>>
>>
>>
>> An alternative should express exactly those behaviors that are indicated
>> by its assertions and make no claims about other assertions.
>>
>>
>>
>> All the best, Ashok
>>
>> ------------------------------------------------------------------------
>>
>> *From:* Daniel Roth [mailto:Daniel.Roth@microsoft.com]
>> *Sent:* Tuesday, May 08, 2007 1:35 PM
>> *To:* Ashok Malhotra; Asir Vedamuthu; Christopher B Ferris;
>> public-ws-policy@w3.org
>> *Subject:* RE: policy vocabulary, will not be applied, oh my!
>>
>>
>>
>> Hi Ashok,
>>
>>
>>
>> Chris' proposal is actually exactly what I meant by NOBI.  An
>> alternative should express exactly those behaviors that are needed for
>> interop and nothing else should be done.
>>
>>
>>
>> For example, if I have an alternative that says I require message
>> security, then requesters should not also enable transport security and
>> expect to interoperate.
>>
>>
>>
>> Chris' proposal looks good to me.
>>
>>
>>
>> Daniel Roth
>>
>>
>>
>> *From:* public-ws-policy-request@w3.org
>> [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Ashok Malhotra
>> *Sent:* Tuesday, May 08, 2007 11:42 AM
>> *To:* Asir Vedamuthu; Christopher B Ferris; public-ws-policy@w3.org
>> *Subject:* RE: policy vocabulary, will not be applied, oh my!
>>
>>
>>
>> So, Asir, just to be clear, this position is different from the NOIB (No
>> Implied Behavior) that Dan espoused on last Wednesday's call.
>>
>>
>>
>> All the best, Ashok
>>
>> ------------------------------------------------------------------------
>>
>> *From:* public-ws-policy-request@w3.org
>> [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Asir Vedamuthu
>> *Sent:* Tuesday, May 08, 2007 9:22 AM
>> *To:* Christopher B Ferris; public-ws-policy@w3.org
>> *Subject:* RE: policy vocabulary, will not be applied, oh my!
>>
>>
>>
>> +1
>>
>>
>>
>> An alternative with one or more assertions indicates behaviors implied
>> by those, and only those assertions. If a policy alternative does not
>> specify a behavior then the alternative means the behavior is not applied.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Asir S Vedamuthu
>>
>> Microsoft Corporation
>>
>>
>>
>>
>>
>> *From:* public-ws-policy-request@w3.org
>> [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Christopher B Ferris
>> *Sent:* Tuesday, May 08, 2007 5:01 AM
>> *To:* public-ws-policy@w3.org
>> *Subject:* Re: policy vocabulary, will not be applied, oh my!
>>
>>
>>
>>
>> All,
>>
>> I've been thinking about this, and possible language that would make
>> things clear to the reader that an alternative's set of
>> assertions implies that ONLY those behaviors implied by those assertions
>> are applied in the context of an interchange
>> governed by that policy alternative.
>>
>> Also, since there isn't an issue to go with this thread, and it may well
>> end up with CR edits to the
>> spec, I opened an issue (4544) in Bugzilla:
>>
>>         http://www.w3.org/Bugs/Public/show_bug.cgi?id=4544
>>
>> The first paragraph in section 3.2 of the Framework currently reads:
>>
>> [Definition: A *policy alternative* is a potentially empty collection of
>> policy assertions
>> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_assertion>.] An
>> alternative with zero assertions indicates no behaviors. An alternative
>> with one or more assertions indicates behaviors implied by those, and
>> only those assertions. [Definition: A *policy vocabulary* is the set of
>> all policy assertion types
>> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_assertion_type>
>> used in a policy.] [Definition: A *policy alternative vocabulary* is the
>> set of all policy assertion types
>> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_assertion_type>
>> within the policy alternative
>> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_alternative>.]
>> When an assertion whose type is part of the policy's vocabulary is not
>> included in a policy alternative, the policy alternative without the
>> assertion type indicates that the assertion will not be applied in the
>> context of the attached policy subject. See the example in Section
>> *4.3.1 Optional Policy Assertions*
>> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#Optional_Policy_Assertions>
>>
>>
>> I would propose the following change:
>>
>> [Definition: A *policy alternative* is a potentially empty collection of
>> policy assertions
>> <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_assertion>.] An
>> alternative with zero assertions indicates no behaviors. An alternative
>> with one or more assertions indicates behaviors implied by those, and
>> only those assertions. No other behaviors are to be applied for the
>> alternative.
>>
>> The rest of the edits in the original proposal [1] remain unchanged.
>>
>> [1] http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0003.html
>>
>> Cheers,
>>
>> Christopher Ferris
>> STSM, Software Group Standards Strategy
>> email: chrisfer@us.ibm.com
>> blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
>> phone: +1 508 377 9295
>>
>> public-ws-policy-request@w3.org wrote on 05/07/2007 09:07:16 AM:
>>
>>>  +1,
>>>
>>>  (Thanks Chris, for providing an example. Makes it much clearer for
>>>  understanding issue.)
>>>
>>>  regards, Frederick
>>>
>>>  Frederick Hirsch
>>>  Nokia
>>>
>>>
>>>  On May 2, 2007, at 5:19 AM, ext Sergey Beryozkin wrote:
>>>
>>>  > Hi Chris
>>>  >
>>>  > Would it be possible to post an example which would show a
>>>  > realistic scenario where it's obvious the fact that the input
>>>  > policy vocabulary is not included in the effective policy's
>>>  > vocabulary may cause the problems for a client ? I just find it
>>>  > difficult to understand the reasoning when policies A&B are used in
>>>  > examples :-)
>>>  >
>>>  > Also, I don't understand why the client can not use the effective
>>>  > policy's vocabulary as the guidance on what assertions can be
>>>  > applied. The fact that many more assertions might've been involved
>>>  > in the intersection seems unimportant to me, the client can not
>>>  > apply what the effective policy has now, that is whatever
>>>  > assertions are in the selected alternative. I think this is what
>>>  > Monica said in the other email (sorry if misinterpreted that email
>>>  > reply).
>>>  >
>>>  > I hope the practical example will help to understand the problem
>>>  > better
>>>  >
>>>  > Thanks, Sergey
>>>  > ----- Original Message -----
>>>  > From: Christopher B Ferris
>>>  > To: public-ws-policy@w3.org
>>>  > Sent: Tuesday, May 01, 2007 9:22 PM
>>>  > Subject: policy vocabulary, will not be applied, oh my!
>>>  >
>>>  >
>>>  > There are some related issues/questions/concerns that have been
>>>  > expressed by members
>>>  > of the WG with regards the framework specification as it relates to
>>>  > the "will not be applied" principle
>>>  > and the definions for "policy vocabulary", etc. Below, I have
>>>  > enumerated these issues
>>>  > and suggest a path forward to address those concerns.
>>>  >
>>>  > 1. The definition of "policy vocabulary" is incompatible with
>>>  > intersected policy as regards to
>>>  > the "will not be applied" principle because post intersection, the
>>>  > resultant policy expression
>>>  > does not carry the policy vocabulary of the input policy
>>>  > expressions. Hence, if a provider
>>>  > had two alternatives, one with Foo and one without Foo, and the
>>>  > result of intersection determined
>>>  > that the alternative without Foo was compatible with a client's
>>>  > policy, then the resultant
>>>  > policy expression would not have in its vocabulary (as computed
>>>  > using the algorithim
>>>  > currently specified) Foo and hence it would not be clear whether
>>>  > Foo carries with it
>>>  > the "will not be applied" semantic.
>>>  >
>>>  > Action-283 - http://lists.w3.org/Archives/Public/public-ws-policy/
>>>  > 2007Apr/0103.html
>>>  > Action-284 - http://lists.w3.org/Archives/Public/public-ws-policy/
>>>  > 2007Apr/0106.html
>>>  > Ashok email - http://lists.w3.org/Archives/Public/public-ws-policy/
>>>  > 2007Apr/0065.html
>>>  >
>>>  > 2. There is a degree of confusion regarding the "will not be
>>>  > applied" semantic as it applies to nested policy.
>>>  > This is related to the interpretation of "policy vocabulary" that
>>>  > many held prior to the clarification provided by
>>>  > Microsoft
>>>  >
>>>  > Asir's email on nested policy vocabulary - http://lists.w3.org/
>>>  > Archives/Public/public-ws-policy/2007Apr/0017.html
>>>  >
>>>  > 3. As a result, a number of email threads have sprung up that
>>>  > question the merits of the "will not be applied"
>>>  > semantic.
>>>  >
>>>  > Ashok - http://lists.w3.org/Archives/Public/public-ws-policy/
>>>  > 2007Apr/0065.html
>>>  > Dale - http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/
>>>  > 0075.html
>>>  > Ashok - http://lists.w3.org/Archives/Public/public-ws-policy/
>>>  > 2007Apr/0101.html
>>>  > Dale - http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/
>>>  > 0108.html
>>>  >
>>>  > It may be that the most prudent course forward would be to drop the
>>>  > "will not be applied" semantic as relates
>>>  > policy vocabulary. As a result, there is little need of a normative
>>>  > definion for policy vocabulary or policy alternative
>>>  > vocabulary, as these definitions only served to allow one to
>>>  > determine whether the behavior implied by a
>>>  > given assertion carried the "will not be applied" semantic.
>>>  >
>>>  > Instead, we could simply state that the behavior implied by an
>>>  > assertion that is absent from a given alternative
>>>  > is not to be applied in the context of the attached policy subject
>>>  > when that alternative is engaged.
>>>  > This would provide clearer semantic (I believe) to borth assertion
>>>  > and policy authors.
>>>  >
>>>  > The attached mark-up of the policy framework specification contains
>>>  > the changes that I believe would
>>>  > be necessary to affect this change.
>>>  >
>>>  > Impact analysis:
>>>  >
>>>  > - The proposed change does not affect the XML syntax
>>>  > - Nor does it impact the semantics of the namespace, therefore the
>>>  > namesapce URI can remain unchanged
>>>  > - It does not affect the processing model (normalization,
>>>  > intersection)
>>>  > - It does not impact testing results to date
>>>  > - It does not affect any of the assertion languages developed to date
>>>  >
>>>  > The related questsion that needs to be asked should we choose to
>>>  > adopt this proposal is:
>>>  >
>>>  >         Does this change affect any implementations?
>>>  >
>>>  > From analysis of the set of test cases, the answer is not clear,
>>>  > because there were no tests that
>>>  > excercised either policy vocabulary or the "will not be applied"
>>>  > semantic. Thus, it would be important that
>>>  > we check our respective implementations to ascertain whether there
>>>  > would be any impact. From an IBM
>>>  > perspective, this change does not impact our implementation.
>>>  >
>>>  >
>>>  >
>>>  > Cheers,
>>>  >
>>>  > Christopher Ferris
>>>  > STSM, Software Group Standards Strategy
>>>  > email: chrisfer@us.ibm.com
>>>  > blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
>>>  > phone: +1 508 377 9295
>>>
>>>
Received on Wednesday, 9 May 2007 00:56:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:34 UTC