- From: Asir Vedamuthu via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 14 Jun 2007 19:46:21 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv8240
Modified Files:
ws-policy-framework.xml ws-policy-framework.html
Log Message:
Implemented the resolution for issue 4583. Editors' action 318.
Index: ws-policy-framework.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-framework.xml,v
retrieving revision 1.147
retrieving revision 1.148
diff -u -d -r1.147 -r1.148
--- ws-policy-framework.xml 14 Jun 2007 17:44:30 -0000 1.147
+++ ws-policy-framework.xml 14 Jun 2007 19:46:19 -0000 1.148
@@ -465,7 +465,20 @@
same type. Mechanisms for determining the aggregate behavior indicated by the
assertions (and their Post-Schema-Validation Infoset (PSVI) (See XML Schema Part
1 [<bibref ref="XMLSchemaPart1"/>]) content, if any) are specific to the
- assertion type and are outside the scope of this document.</p>
+ assertion type and are outside the scope of this document. If policy assertion
+ authors did not specify the semantics of repetition of <termref def="policy_assertion">policy
+ assertions</termref> of a
+ <termref def="policy_assertion_type">type</termref> that allows neither
+ <termref def="policy_assertion_parameter">parameters</termref> nor
+ <termref def="nested_policy_expression">nested
+ policy expressions</termref> within a
+ <termref def="policy_alternative">policy alternative</termref>, then repetition is
+ simply redundancy, and multiple <termref def="policy_assertion">assertions</termref>
+ of the <termref def="policy_assertion_type">assertion type</termref>
+ within a <termref def="policy_alternative">policy alternative</termref> have the same meaning as a single
+ <termref def="policy_assertion">assertion</termref>
+ of the <termref def="policy_assertion_type">type</termref> within the
+ <termref def="policy_alternative">policy alternative</termref>.</p>
<p>Note: Depending on the semantics of the domain specific policy assertions
regardless if they are qualified by nested policy expressions, a
combination of the policy assertions can be required to specify a particular
@@ -1817,10 +1830,40 @@
alternative from each policy. If two policies are not compatible, their
intersection has no policy alternatives.</p>
</item>
- </ulist>
- <p>See Section <specref ref="rPolicy_Alternative"/> for mechanisms for determining
- the aggregate behavior indicated by multiple assertions of the same <termref
- def="policy_assertion_type">policy assertion type</termref>.</p>
+ <item>
+ <p>The result of policy intersection can be zero or more
+ <termref def="policy_alternative">alternatives</termref>.
+ Each <termref def="policy_alternative">alternative</termref> may contain more
+ than one <termref def="policy_assertion">assertion</termref> of the same <termref
+ def="policy_assertion_type">type</termref>
+ which may come from different input
+ <termref def="policy">policies</termref>. See Section
+ <specref ref="rPolicy_Alternative"/> for mechanisms for determining
+ the aggregate behavior indicated by multiple
+ <termref def="policy_assertion">assertions</termref> of the same <termref
+ def="policy_assertion_type">policy assertion type</termref>.
+ If policy assertion authors did not specify the semantics of multiple
+ <termref def="policy_assertion">assertions</termref> of the same <termref
+ def="policy_assertion_type">assertion type</termref> within a
+ <termref def="policy_alternative">policy
+ alternative</termref> and
+ the <termref
+ def="policy_assertion_type">type</termref> and its descendant <termref
+ def="policy_assertion_type">assertion types</termref> (within a
+ <termref def="nested_policy_expression">nested policy
+ expression</termref> outline, if any) do not allow any
+ <termref def="policy_assertion_parameter">parameters</termref>, then multiple
+ <termref def="policy_assertion">assertions</termref> of the <termref
+ def="policy_assertion_type">type</termref> within a
+ <termref def="policy_alternative">policy
+ alternative</termref> in
+ the intersection
+ result have the same meaning as a single
+ <termref def="policy_assertion">assertion</termref> of the <termref
+ def="policy_assertion_type">type</termref> within
+ the <termref def="policy_alternative">policy alternative</termref>.</p>
+ </item>
+ </ulist>
<p>An entity applies all the behaviors implied by a policy alternative when that policy alternative is chosen from the intersection result (see <specref ref="Web_services"/>). If an entity includes a policy assertion type A in its policy, and this policy assertion type A does not occur in an intersected result, then that entity SHOULD not apply the behavior implied by assertion type A. If a policy assertion type Z is not included in the input policies being intersected then the intersection result is silent about the behavior implied by the assertion type Z.
</p>
<p>As an example of intersection, consider two input policies in normal form:</p>
@@ -1904,13 +1947,41 @@
(16) </wsp:ExactlyOne>
(17) </wsp:Policy></eg>
- <p>Note that there are > 1 assertions of the type <el>sp:SignedParts</el>;
- when the behavior associated with <el>sp:SignedParts</el> is invoked, the
- contents of both assertions are used to indicate the correct behavior. Whether
- these two assertions are compatible depends on the domain-specific semantics of
- the <el>sp:SignedParts</el> assertion. To leverage intersection, assertion
- authors are encouraged to factor assertions such that two assertions of the same
- assertion type are always (or at least typically) compatible.</p>
+ <p>Note that there are two <termref def="policy_assertion">assertions</termref>
+ of the type <el>sp:SignedParts</el> and two
+ <termref def="policy_assertion">assertions</termref> of the
+ <termref def="policy_assertion_type">type</termref> <el>sp:EncryptedParts</el>, one
+ from each of the input <termref def="policy">Policies</termref>. In general,
+ whether two <termref def="policy_assertion">assertions</termref> of the
+ same <termref def="policy_assertion_type">type</termref> are
+ compatible or repetition is redundancy depends on the domain-specific
+ semantics of the <termref def="policy_assertion_type">assertion type</termref>.
+ As mentioned above, if the <termref def="policy_assertion">assertions</termref>
+ have no <termref def="policy_assertion_parameter">parameters</termref> and the
+ <termref def="policy_assertion">assertions</termref>
+ in <termref def="nested_policy_expression">nested policiy expressions</termref>
+ have no <termref def="policy_assertion_parameter">parameters</termref>, then multiple
+ <termref def="policy_assertion">assertions</termref> of
+ the <termref def="policy_assertion_type">type</termref>
+ within a <termref def="policy_alternative">policy alternative</termref>
+ in the intersection result have the same meaning
+ as a single <termref def="policy_assertion">assertion</termref>
+ of the <termref def="policy_assertion_type">type</termref> within
+ the <termref def="policy_alternative">policy alternative</termref>.</p>
+
+ <p>Based on the semantics of multiple
+ <termref def="policy_assertion">assertions</termref> of the
+ EncryptedParts <termref def="policy_assertion_type">assertion
+ type</termref>, as specified in the WS-SecurityPolicy
+ [<bibref ref="WS-SecurityPolicy"/>] specification, one of the
+ <el>sp:EncryptedParts</el> <termref def="policy_assertion">assertion</termref>
+ in the above example is redundant.</p>
+
+ <p>Whether the two <el>sp:SignedParts</el>
+ <termref def="policy_assertion">assertions</termref> are compatible
+ or one of them is redundant depends on the semantics defined for
+ this <termref def="policy_assertion_type">assertion type</termref>.</p>
+
<p>As another example of intersection of WS-Addressing assertions that utilize the framework intersection algorithm, consider two input policies:</p>
<eg xml:space="preserve" role="needs-numbering"><wsp:Policy
@@ -3376,6 +3447,15 @@
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/319">319</loc>.
</td>
</tr>
+ <tr>
+ <td>20070614</td>
+ <td>ASV</td>
+ <td>Implemented the resolution
+ for issue <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4583">4583</loc>.
+ Editors' action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/318">318</loc>.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Index: ws-policy-framework.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-framework.html,v
retrieving revision 1.121
retrieving revision 1.122
diff -u -d -r1.121 -r1.122
--- ws-policy-framework.html 14 Jun 2007 17:44:30 -0000 1.121
+++ ws-policy-framework.html 14 Jun 2007 19:46:19 -0000 1.122
@@ -285,7 +285,9 @@
<a href="#ignorable_policy_assertion">ignorable policy assertion</a>
</dt><dd><p>An
<b>ignorable policy assertion</b> is an assertion that may be
- ignored for policy intersection (as defined in <a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8#Policy_Intersection">4.5 Policy
+ ignored for purposes of determining the compatibility of alternatives
+ in policy intersection in a lax mode
+ (as defined in <a href="http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;charset=utf-8#Policy_Intersection">4.5 Policy
Intersection</a>).</p></dd><dt class="label">
<a href="#nested_policy_expression">nested policy expression</a>
</dt><dd><p>A <b>nested policy expression</b>
@@ -391,7 +393,20 @@
same type. Mechanisms for determining the aggregate behavior indicated by the
assertions (and their Post-Schema-Validation Infoset (PSVI) (See XML Schema Part
1 [<cite><a href="#XMLSchemaPart1">XML Schema Structures</a></cite>]) content, if any) are specific to the
- assertion type and are outside the scope of this document.</p><p>Note: Depending on the semantics of the domain specific policy assertions
+ assertion type and are outside the scope of this document. If policy assertion
+ authors did not specify the semantics of repetition of <a title="policy assertion" href="#policy_assertion">policy
+ assertions</a> of a
+ <a title="policy assertion type" href="#policy_assertion_type">type</a> that allows neither
+ <a title="policy assertion parameter" href="#policy_assertion_parameter">parameters</a> nor
+ <a title="nested policy expression" href="#nested_policy_expression">nested
+ policy expressions</a> within a
+ <a title="policy alternative" href="#policy_alternative">policy alternative</a>, then repetition is
+ simply redundancy, and multiple <a title="policy assertion" href="#policy_assertion">assertions</a>
+ of the <a title="policy assertion type" href="#policy_assertion_type">assertion type</a>
+ within a <a title="policy alternative" href="#policy_alternative">policy alternative</a> have the same meaning as a single
+ <a title="policy assertion" href="#policy_assertion">assertion</a>
+ of the <a title="policy assertion type" href="#policy_assertion_type">type</a> within the
+ <a title="policy alternative" href="#policy_alternative">policy alternative</a>.</p><p>Note: Depending on the semantics of the domain specific policy assertions
regardless if they are qualified by nested policy expressions, a
combination of the policy assertions can be required to specify a particular
behavior. For example, a combination of two or three assertions from the
@@ -1144,8 +1159,30 @@
two policies are compatible, their intersection is the set of the
intersections between all pairs of compatible alternatives, choosing one
alternative from each policy. If two policies are not compatible, their
- intersection has no policy alternatives.</p></li></ul><p>See Section <a href="#rPolicy_Alternative"><b>3.2 Policy Alternative</b></a> for mechanisms for determining
- the aggregate behavior indicated by multiple assertions of the same <a title="policy assertion type" href="#policy_assertion_type">policy assertion type</a>.</p><p>An entity applies all the behaviors implied by a policy alternative when that policy alternative is chosen from the intersection result (see <a href="#Web_services"><b>3.4 Policies of Entities in a Web Services Based System</b></a>). If an entity includes a policy assertion type A in its policy, and this policy assertion type A does not occur in an intersected result, then that entity SHOULD not apply the behavior implied by assertion type A. If a policy assertion type Z is not included in the input policies being intersected then the intersection result is silent about the behavior implied by the assertion type Z.
+ intersection has no policy alternatives.</p></li><li><p>The result of policy intersection can be zero or more
+ <a title="policy alternative" href="#policy_alternative">alternatives</a>.
+ Each <a title="policy alternative" href="#policy_alternative">alternative</a> may contain more
+ than one <a title="policy assertion" href="#policy_assertion">assertion</a> of the same <a title="policy assertion type" href="#policy_assertion_type">type</a>
+ which may come from different input
+ <a title="policy" href="#policy">policies</a>. See Section
+ <a href="#rPolicy_Alternative"><b>3.2 Policy Alternative</b></a> for mechanisms for determining
+ the aggregate behavior indicated by multiple
+ <a title="policy assertion" href="#policy_assertion">assertions</a> of the same <a title="policy assertion type" href="#policy_assertion_type">policy assertion type</a>.
+ If policy assertion authors did not specify the semantics of multiple
+ <a title="policy assertion" href="#policy_assertion">assertions</a> of the same <a title="policy assertion type" href="#policy_assertion_type">assertion type</a> within a
+ <a title="policy alternative" href="#policy_alternative">policy
+ alternative</a> and
+ the <a title="policy assertion type" href="#policy_assertion_type">type</a> and its descendant <a title="policy assertion type" href="#policy_assertion_type">assertion types</a> (within a
+ <a title="nested policy expression" href="#nested_policy_expression">nested policy
+ expression</a> outline, if any) do not allow any
+ <a title="policy assertion parameter" href="#policy_assertion_parameter">parameters</a>, then multiple
+ <a title="policy assertion" href="#policy_assertion">assertions</a> of the <a title="policy assertion type" href="#policy_assertion_type">type</a> within a
+ <a title="policy alternative" href="#policy_alternative">policy
+ alternative</a> in
+ the intersection
+ result have the same meaning as a single
+ <a title="policy assertion" href="#policy_assertion">assertion</a> of the <a title="policy assertion type" href="#policy_assertion_type">type</a> within
+ the <a title="policy alternative" href="#policy_alternative">policy alternative</a>.</p></li></ul><p>An entity applies all the behaviors implied by a policy alternative when that policy alternative is chosen from the intersection result (see <a href="#Web_services"><b>3.4 Policies of Entities in a Web Services Based System</b></a>). If an entity includes a policy assertion type A in its policy, and this policy assertion type A does not occur in an intersected result, then that entity SHOULD not apply the behavior implied by assertion type A. If a policy assertion type Z is not included in the input policies being intersected then the intersection result is silent about the behavior implied by the assertion type Z.
</p><p>As an example of intersection, consider two input policies in normal form:</p><div class="exampleInner"><pre>(01) <wsp:Policy
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
xmlns:wsp="http://www.w3.org/ns/ws-policy" >
@@ -1218,13 +1255,36 @@
(14) </sp:EncryptedParts>
(15) </wsp:All>
(16) </wsp:ExactlyOne>
-(17) </wsp:Policy></pre></div><p>Note that there are > 1 assertions of the type <code>sp:SignedParts</code>;
- when the behavior associated with <code>sp:SignedParts</code> is invoked, the
- contents of both assertions are used to indicate the correct behavior. Whether
- these two assertions are compatible depends on the domain-specific semantics of
- the <code>sp:SignedParts</code> assertion. To leverage intersection, assertion
- authors are encouraged to factor assertions such that two assertions of the same
- assertion type are always (or at least typically) compatible.</p><p>As another example of intersection of WS-Addressing assertions that utilize the framework intersection algorithm, consider two input policies:</p><div class="exampleInner"><pre>(01) <wsp:Policy
+(17) </wsp:Policy></pre></div><p>Note that there are two <a title="policy assertion" href="#policy_assertion">assertions</a>
+ of the type <code>sp:SignedParts</code> and two
+ <a title="policy assertion" href="#policy_assertion">assertions</a> of the
+ <a title="policy assertion type" href="#policy_assertion_type">type</a> <code>sp:EncryptedParts</code>, one
+ from each of the input <a title="policy" href="#policy">Policies</a>. In general,
+ whether two <a title="policy assertion" href="#policy_assertion">assertions</a> of the
+ same <a title="policy assertion type" href="#policy_assertion_type">type</a> are
+ compatible or repetition is redundancy depends on the domain-specific
+ semantics of the <a title="policy assertion type" href="#policy_assertion_type">assertion type</a>.
+ As mentioned above, if the <a title="policy assertion" href="#policy_assertion">assertions</a>
+ have no <a title="policy assertion parameter" href="#policy_assertion_parameter">parameters</a> and the
+ <a title="policy assertion" href="#policy_assertion">assertions</a>
+ in <a title="nested policy expression" href="#nested_policy_expression">nested policiy expressions</a>
+ have no <a title="policy assertion parameter" href="#policy_assertion_parameter">parameters</a>, then multiple
+ <a title="policy assertion" href="#policy_assertion">assertions</a> of
+ the <a title="policy assertion type" href="#policy_assertion_type">type</a>
+ within a <a title="policy alternative" href="#policy_alternative">policy alternative</a>
+ in the intersection result have the same meaning
+ as a single <a title="policy assertion" href="#policy_assertion">assertion</a>
+ of the <a title="policy assertion type" href="#policy_assertion_type">type</a> within
+ the <a title="policy alternative" href="#policy_alternative">policy alternative</a>.</p><p>Based on the semantics of multiple
+ <a title="policy assertion" href="#policy_assertion">assertions</a> of the
+ EncryptedParts <a title="policy assertion type" href="#policy_assertion_type">assertion
+ type</a>, as specified in the WS-SecurityPolicy
+ [<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>] specification, one of the
+ <code>sp:EncryptedParts</code> <a title="policy assertion" href="#policy_assertion">assertion</a>
+ in the above example is redundant.</p><p>Whether the two <code>sp:SignedParts</code>
+ <a title="policy assertion" href="#policy_assertion">assertions</a> are compatible
+ or one of them is redundant depends on the semantics defined for
+ this <a title="policy assertion type" href="#policy_assertion_type">assertion type</a>.</p><p>As another example of intersection of WS-Addressing assertions that utilize the framework intersection algorithm, consider two input policies:</p><div class="exampleInner"><pre>(01) <wsp:Policy
xmlns:wsp="http://www.w3.org/ns/ws-policy"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" >
(02) <wsp:ExactlyOne>
@@ -1629,4 +1689,8 @@
for issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4561">4561</a>.
Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/319">319</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070614</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Implemented the resolution
+ for issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4583">4583</a>.
+ Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/318">318</a>.
</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Received on Thursday, 14 June 2007 19:46:29 UTC