- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Tue, 08 May 2007 17:54:37 -0700
- 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