Re: NEW ISSUE: 4142 Contradictory recommendation for nesting and intersection

Hi,

I agree that the answer in the general case should be NO. WS-Policy can 
not anticipate the semantics of a nested policy and should default to 
match all nested assertions.

Fabian


Asir Vedamuthu wrote:
>
> Answer is NO – as per the policy intersection algorithm in Section 4.5 
> [1]. We agree that the quoted sentence [2] in Section 4.3.2 is 
> misleading. There is an easy fix – drop the sentence.
>
> Regarding ACTION-181 [3], when should we expect your amended proposal?
>
> [1] http://www.w3.org/TR/2006/WD-ws-policy-20061117/#Policy_Intersection
>
> [2] “The reason for requiring at least an empty <wsp:Policy/> Element 
> above is to ensure that two assertions of the same type will always be 
> compatible and an intersection would not fail (see Section 4.5 Policy 
> Intersection)”
>
> [3] http://www.w3.org/2005/06/tracker/wspolicy/actions/181
>
> Regards,
>
> Asir S Vedamuthu
>
> Microsoft Corporation
>
> *From:* public-ws-policy-request@w3.org 
> [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Yalcinalp, Umit
> *Sent:* Wednesday, January 10, 2007 12:11 PM
> *To:* Sergey Beryozkin; Anthony Nadalin
> *Cc:* public-ws-policy@w3.org; public-ws-policy-request@w3.org
> *Subject:* RE: NEW ISSUE: Contradictory recommendation for nesting and 
> intersection
>
> The question is about the semantics. In the example, ex:Foo is NOT a 
> policy parameter. It is a nested assertion. Let me paraphrase for more 
> clarity.
>
> Is
>
> <ex:MyAssertion>
>
> <wsp:Policy>
>
> <ex:NestedAssertion>
>
> </wsp:Policy>
>
> </ex:MyAssertion>
>
> compatible with
>
> <ex:MyAssertion>
>
> <wsp:Policy/>
>
> </ex:MyAssertion>
>
> ?
>
> (a) No
>
> (b) Yes
>
> Depending on your answer, the fix in the document is different. Fix is 
> secondary to what the wg members think the semantics is.
>
> Given that our WGs, such as WS-Addressing have been looking into using 
> nested assertions as well, this needs to be well aligned, agreed.
>
> --umit
>
>     *From:* Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
>     *Sent:* Wednesday, Jan 10, 2007 3:34 AM
>     *To:* Anthony Nadalin
>     *Cc:* public-ws-policy@w3.org; public-ws-policy-request@w3.org;
>     Yalcinalp, Umit
>     *Subject:* Re: NEW ISSUE: Contradictory recommendation for nesting
>     and intersection
>
>     Hi
>
>     Thanks for the explanation about the parameters. I think I just
>     got it wrong. In the Umit's example I thought ex:Foo was a
>     parameter, but it's actually a policy assertion in that
>     example...so I reckon option1 would still be the right approach to
>     follow....
>
>     Cheers, Sergey
>
>         ----- Original Message -----
>
>         *From:* Anthony Nadalin <mailto:drsecure@us.ibm.com>
>
>         *To:* Sergey Beryozkin <mailto:sergey.beryozkin@iona.com>
>
>         *Cc:* public-ws-policy@w3.org <mailto:public-ws-policy@w3.org>
>         ; public-ws-policy-request@w3.org
>         <mailto:public-ws-policy-request@w3.org> ; Yalcinalp, Umit
>         <mailto:umit.yalcinalp@sap.com>
>
>         *Sent:* Tuesday, January 09, 2007 5:07 PM
>
>         *Subject:* Re: NEW ISSUE: Contradictory recommendation for
>         nesting and intersection
>
>         The ex:Foo parameter is a domain specific processing item, not
>         evaluated at the framework level, thus I would consider the
>         assertions in your example the same. This is the understanding
>         we have with Security Policy assertions.
>
>         Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
>         Inactive hide details for "Sergey Beryozkin"
>         <sergey.beryozkin@iona.com>"Sergey Beryozkin"
>         <sergey.beryozkin@iona.com <mailto:sergey.beryozkin@iona.com>>
>
>         *"Sergey Beryozkin" <sergey.beryozkin@iona.com
>         <mailto:sergey.beryozkin@iona.com>>*
>         Sent by: public-ws-policy-request@w3.org
>         <mailto:public-ws-policy-request@w3.org>
>
>         01/03/2007 12:28 PM
>
>         	
>
>         cid:image002.png@01C736B5.D085AB30
>
>         To
>
>         	
>
>         cid:image003.png@01C736B5.D085AB30
>         "Yalcinalp, Umit" <umit.yalcinalp@sap.com
>         <mailto:umit.yalcinalp@sap.com>>, <public-ws-policy@w3.org
>         <mailto:public-ws-policy@w3.org>>
>
>         cid:image002.png@01C736B5.D085AB30
>
>         cc
>
>         	
>
>         cid:image003.png@01C736B5.D085AB30
>
>         cid:image002.png@01C736B5.D085AB30
>
>         Subject
>
>         	
>
>         cid:image003.png@01C736B5.D085AB30
>         Re: NEW ISSUE: Contradictory recommendation for nesting and
>         intersection
>
>         cid:image003.png@01C736B5.D085AB30
>
>         	
>
>         cid:image003.png@01C736B5.D085AB30
>
>
>         Hi
>
>         "
>
>         (a) The statement in 4.3.2 quoted is in error. Including a
>         nested empty policy expression allows the compatibility
>         testing to occur, but does NOT guarantee the same types to be
>         compatible for intersection (which is implied by the
>         intersection algorithm). Using this logic, expressions 1 and 2
>         are not compatible as the intersection algorithm suggests. "
>
>         seems like the right solution, as in
>
>         "The alternative in (1) is <wsp:Policy>
>         <ex:Foo/></wsp:Policy>. The alternative in (2) is <wsp:Policy/>."
>
>         (1) is more specialized than (2), has ex:Foo policy parameter,
>         hence they're different
>
>         Cheers, Sergey
>
>         ----- Original Message -----
>         *From:* Yalcinalp, Umit <mailto:umit.yalcinalp@sap.com>
>         *To:* public-ws-policy@w3.org <mailto:public-ws-policy@w3.org>
>         *Sent:* Wednesday, January 03, 2007 1:56 AM
>         *Subject:* NEW ISSUE: Contradictory recommendation for nesting
>         and intersection
>
>         Title: Contradictory recommendation for nesting and intersection
>
>         Description: The specification provides some guidance about
>         when to include an empty policy element. Section 4.3.2,
>         Assertion/Policy element states:
>
>         {Note: if the schema outline for an assertion type requires a
>         nested policy expression but the assertion does not further
>         qualify one or more aspects of the behavior indicated by the
>         assertion type (i.e., no assertions are needed in the nested
>         policy expression), the assertion MUST include an empty
>         <wsp:Policy/> Element Information Item in its* [children]*
>         property; as explained in Section *4.3.3 Policy Operators*,
>         this is equivalent to a nested policy expression with a single
>         alternative that has zero assertions. The reason for requiring
>         at least an empty <wsp:Policy/> Element above is to ensure
>         that two assertions of the same type will always be compatible
>         and an intersection would not fail (see Section *4.5 Policy
>         Intersection*).
>
>         }
>         The paragraph stated imply two different and somewhat
>         contradictory advice.
>         (a) A nested assertion by definition (via schema) should
>         always expressed using nesting, even if the nesting yields
>         zero assertions in a single alternative. (This is per the
>         first statement)
>
>         (b) Two assertions that have the same nesting will always be
>         compatible REGARDLESS of whether they have different nested
>         elements inside. (This is inferred from the last statement).
>
>         While the first statement is intuitive, the second
>         recommendation (b) is counter indicative per the intersection
>         algorithm and thus requires either changing or clarification.
>         This is due to the unclarity of the intersection algorithm.
>         Consider the following two policy expressions:
>
>         (1)
>         <wsp:Policy>
>         <wsp:ExactlyOne>
>         <wsp:All>
>         <ex:NestedAssertion>
>         <wsp:Policy>
>         <ex:Foo/>
>         </wsp:Policy>
>         </ex:NestedAssertion>
>         </wsp:All>
>         </wsp:ExactlyOne>
>         </wsp:Policy>
>         (2)
>         <wsp:Policy>
>         <wsp:ExactlyOne>
>         <wsp:All>
>         <ex:NestedAssertion>
>         <wsp:Policy/>
>         </ex:NestedAssertion>
>         </wsp:All>
>         </wsp:ExactlyOne>
>         </wsp:Policy>
>         According to the statement above, these assertions are
>         expected to be "compatible" but the intersection algorithm in
>         Section 4.5 does not confirm this expectation:
>
>         {If either assertion contains a nested policy expression, the
>         two assertions are compatible if they both have a nested
>         policy expression and the alternative in the nested policy
>         expression of one is compatible with the alternative in the
>         nested policy expression of the other. }
>
>         According to the previous statement, the nested expressions in
>         (1) and (2) are NOT compatible assertions, either in strict or
>         lax mode because of the definition of the compatibity of the
>         alternatives are governed by the following. (Lets consider
>         strict mode for simplicity)
>
>         {If the mode is strict, two policy alternatives A and B are
>         compatible:
>
>                               # if each assertion in A is compatible
>                                 with an assertion in B, and
>                               # if each assertion in B is compatible
>                                 with an assertion in A.}
>
>         The alternative in (1) is <wsp:Policy> <ex:Foo/></wsp:Policy>.
>         The alternative in (2) is <wsp:Policy/>. According to the
>         compatibility definition, these two alternatives are not
>         compatible as there is no nested ex:Foo element within the
>         second alternative for (2).
>
>         Therefore, including a nested policy expression WILL STILL
>         FAIL the intersection algorithm in contradiction to the
>         statement:
>
>         {The reason for requiring at least an empty <wsp:Policy/>
>         Element above is to ensure that two assertions of the same
>         type will always be compatible and an intersection would not
>         fail (see Section *4.5 Policy Intersection*). }
>
>         Thus the specification is in conflict with itself and this
>         should be resolved. See proposal section for two alternative
>         ways of fixing this.
>
>         Target: Framework, Primer
>
>         Justification: The specification is contradictory with itself.
>         It does not explain the utility of nesting and empty policy
>         expression well. The clarification should be included in the
>         framework as well as the primer since it was deemed necessary
>         for an explanation in the framework document itself for
>         further clarification in the first place. Readers who are not
>         familiar with the nesting will definitely get this wrong,
>         especially there is contradictory statements in the
>         specification.
>
>         Proposal:
>         There are two ways to interpret this conflict as there are two
>         possible ways forward depending on the intent of the
>         specification:
>
>         (a) The statement in 4.3.2 quoted is in error. Including a
>         nested empty policy expression allows the compatibility
>         testing to occur, but does NOT guarantee the same types to be
>         compatible for intersection (which is implied by the
>         intersection algorithm). Using this logic, expressions 1 and 2
>         are not compatible as the intersection algorithm suggests.
>
>         This requires fixing the last sentence in the quoted paragraph
>         in Section 4.3.2.
>         (b) The intersection algorithm makes a special provision for
>         an empty policy assertion to allow compatibity with nesting.
>         This means expressions 1 and 2 are always compatible with each
>         other. This means when we have nested empty policies, it is a
>         cop-out for cheating the intersection algorithm and thus
>         requires the intersection algorithm to account for this
>         specifically.
>
>         The resolution requires including an example, preferably to
>         the framework, alternatively to the primer to illustrate the
>         result of intersection with the examples provided in this
>         report. If (b) is chosen, adding some guidance to Guidelines
>         document will be appropriate as well as the framework fix.
>
>         This report is filed as [Bug 4142].
>
>         [1] http://www.w3.org/TR/ws-policy/
>         [2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4142
>         ----------------------
>
>         Dr. Umit Yalcinalp
>         Research Scientist
>         SAP Labs, LLC
>         Email: umit.yalcinalp@sap.com Tel: (650) 320-3095
>         SDN: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238
>         --------
>         "Nearly all men can stand adversity, but if you want to test a
>         man's character, give him power." Abraham Lincoln.
>


-- 
Fabian Ritzmann
Sun Microsystems, Inc.
Stella Business Park             Phone +358-9-525 562 96
Lars Sonckin kaari 12            Fax   +358-9-525 562 52
02600 Espoo                      Email Fabian.Ritzmann@Sun.COM
Finland

Received on Monday, 15 January 2007 09:16:56 UTC