- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 12 Sep 2007 20:52:02 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv2863
Modified Files:
ws-policy-primer.html ws-policy-primer.xml
Log Message:
Implemented the resolution for issue 4943. Editors' action 354.
Index: ws-policy-primer.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.html,v
retrieving revision 1.66
retrieving revision 1.67
diff -u -d -r1.66 -r1.67
--- ws-policy-primer.html 12 Sep 2007 19:43:39 -0000 1.66
+++ ws-policy-primer.html 12 Sep 2007 20:51:59 -0000 1.67
@@ -95,7 +95,7 @@
3.7 <a href="#combine-policies">Combine Policies</a><br>
3.8 <a href="#extensibility-and-versioning">Extensibility and Versioning</a><br>
3.8.1 <a href="#ext-vers-policylanguage">Policy Language</a><br>
- 3.8.2 <a href="#d3e1411">Policy Expressions</a><br>
+ 3.8.2 <a href="#d3e1425">Policy Expressions</a><br>
3.8.3 <a href="#ignorable-and-versioning">Use of Ignorable attribute and an alternative Versioning Scenario</a><br>
3.8.4 <a href="#ignorable-and-optional-and-versioning">Use of Ignorable and Optional attributes</a><br>
3.9 <a href="#parts-of-a-policy-assertion">Parts of a Policy Assertion</a><br>
@@ -823,7 +823,7 @@
QName, <code>sp:TransportBinding</code>. For this discussion, let us assume that these two
assertions have compatible nested policies. These two assertions are compatible because
they have the same QName and their nested policies are compatible.</p><p>Two policy alternatives are compatible if each policy assertion in one alternative is
- compatible with a policy assertion in the other and vice-versa. For example, policy
+ compatible with a policy assertion in the other and vice-versa. For instance in Examples 3.6 and 3.7, policy
assertions (c1) and (c2) in Company-X’s policy alternative are compatible with policy
assertions (t2) and (t1) in the client’s policy alternative. Company-X’s policy alternative (a)
and the client’s policy alternative are compatible because assertions in these two alternatives
@@ -833,7 +833,54 @@
of Company-X’s policy alternative is compatible with the client’s policy alternative.</p><p>For this interaction, the developer’s policy-aware client can use policy alternative (a) to
satisfy Company-X’s conditions or requirements.</p><p>Similarly, policy intersection can be used to check if providers expose endpoints that
conform to a standard policy. For example, a major retailer might require all their
- supplier endpoints to be compatible with an agreed upon policy.</p><div class="div3">
+ supplier endpoints to be compatible with an agreed upon policy.</p><p>Consider a similar scenario between Company X and the client where nested policy expressions exist in the policy alternatives.
+ The nested policy expressions are compared for compatibility in the context of
+ their parent policy assertions during policy intersection. For example, take these two incompatible policies in Examples 3.8 and 3.9:
+ </p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-8. </span>Company X Nested incompatible policy example</i></p><div class="exampleInner"><pre>Company X
+(P001)<wsp:Policy wsu:Id="..." >
+(P002) <wsp:ExactlyOne>
+(P003) <wsp:All>
+(P004) <sp:EndorsingSupportingTokens
+(P005) xmlns:sp="..."> <!-- parent policy assertion a -->
+(P006) <wsp:Policy> <!-- nested policy a1 -->
+(P007) <sp:X509Token sp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
+(P008) <wsp:Policy>
+(P009) <sp:RequireThumbprintReference />
+(P010) <sp:WssX509V3Token10 />
+(P011) </wsp:Policy>
+(P012) </sp:X509Token>
+(P013) </wsp:Policy>
+(P014) </sp:EndorsingSupportingTokens>...
+(P015) </wsp:All>
+(P016) </wsp:ExactlyOne>
+(P017)</wsp:Policy></pre></div></div><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-9. </span>Client Nested incompatible policy example</i></p><div class="exampleInner"><pre>Client
+(P001)<wsp:Policy wsu:Id="..." >
+(P002) <wsp:ExactlyOne>
+(P003) <wsp:All>
+(P004) <sp:SignedSupportingTokens
+(P005) xmlns:sp="..."> <!-- parent policy assertion b -->
+(P006) <wsp:Policy> <!-- nested policy b1 -->
+(P007) <sp:X509Token sp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
+(P008) <wsp:Policy>
+(P009) <sp:RequireThumbprintReference />
+(P010) <sp:WssX509V3Token10 />
+(P011) </wsp:Policy>
+(P012) </sp:X509Token>
+(P013) </wsp:Policy>
+(P014) </sp:SignedSupportingTokens>...
+(P015) </wsp:All>
+(P016) </wsp:ExactlyOne>
+(P017)</wsp:Policy>
+ </pre></div></div><p>In this scenario as illustrated in Examples 3.8 and 3.9, the EndorsingSupportingTokens and
+ SignedSupportingTokens
+ assertions
+ are incompatible even though their nested policy expressions are compatible.
+ This is because the parent policy
+ assertions EndorsingSupportingTokens and SignedSupportingTokens have different
+ QNames.
+ </p><div class="div3">
<h4><a name="strict-lax-policy-intersection" id="strict-lax-policy-intersection"></a>3.4.1 Strict and Lax Policy Intersection</h4><p>
The previous sections outlined how the normal-form of a policy expression relates to the policy data model and how the
compatibility of requester and provider policies may be determined.
@@ -902,7 +949,7 @@
<code>message</code> element collectively represent the message policy subject for the
fault message. Policy expressions associated with a message policy subject apply only to
that message.</p><p>In the example below, the policy expression is attached to an endpoint policy subject.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-8. </span>Company-X’s Policy Expression Attached to WSDL binding Element</i></p><div class="exampleInner"><pre><wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-10. </span>Company-X’s Policy Expression Attached to WSDL binding Element</i></p><div class="exampleInner"><pre><wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
<PolicyReference URI="#secure" />
<wsdl:operation name="GetRealQuote">…</wsdl:operation>
…
@@ -942,7 +989,7 @@
below, there are two policy expressions <code>#common2</code> and <code>#secure2</code>
attached to the <code>SecureBinding</code> WSDL binding and <code>RealTimeDataPort</code>
WSDL port descriptions.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-9. </span>Multiple Policy Expressions Attached to Endpoint Policy Subject </i></p><div class="exampleInner"><pre><Policy wsu:Id=”common2”>
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-11. </span>Multiple Policy Expressions Attached to Endpoint Policy Subject </i></p><div class="exampleInner"><pre><Policy wsu:Id=”common2”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
<wsam:Addressing>…</wsam:Addressing>
</Policy>
@@ -980,7 +1027,7 @@
combination of these two policies is equivalent to Company-X’s secure policy in <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a> and has four policy alternatives. In other
words, the combination of two policies is the cross product of alternatives in these two
policies.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-10. </span>Effective Policy of the Endpoint Policy Subject in the Previous Example</i></p><div class="exampleInner"><pre><Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-12. </span>Effective Policy of the Endpoint Policy Subject in the Previous Example</i></p><div class="exampleInner"><pre><Policy>
<All>
<Policy>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
@@ -1010,13 +1057,13 @@
and treats unknown children of the <code>Policy</code>, <code>ExactlyOne</code>, <code>All</code>
elements as policy assertions. The child elements of <code>wsp:PolicyReference</code> are ignored.
</p><p>The <code>PolicyReference</code> element allows element and attribute extensibility.</p></div><div class="div3">
-<h4><a name="d3e1411" id="d3e1411"></a>3.8.2 Policy Expressions</h4><p>Services that use the Web Services Policy language for policy expression enable simple versioning practices that allow requesters to
+<h4><a name="d3e1425" id="d3e1425"></a>3.8.2 Policy Expressions</h4><p>Services that use the Web Services Policy language for policy expression enable simple versioning practices that allow requesters to
continue the use of older policy alternatives in a backward compatible manner. This
versioning practice allows service providers, like Company-X, to deploy new behaviors using additional (or new) policy
assertions without breaking compatibility with clients that rely on any older policy
alternatives. We use examples below to illustrate how versioning might be done.</p><p>The example below represents a Company-X version 1 policy expression. This expression
requires the use of addressing and transport-level security for protecting messages. </p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-11. </span>Company-X’s Version 1 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-13. </span>Company-X’s Version 1 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All>
<wsam:Addressing>…</wsam:Addressing>
@@ -1032,7 +1079,7 @@
may continue to interact with Company-X’s using the old policy alternative. Of course, these
clients have the option to migrate from using old policy alternatives to new policy
alternatives.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-12. </span>Company-X’s Version 2 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-14. </span>Company-X’s Version 2 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All>
<wsam:Addressing>…</wsam:Addressing>
@@ -1071,7 +1118,7 @@
</p><p>
Company-X could specify that one policy alternative will expire at a certain point in time using the hypothetical ignorable Company-X expiry assertion. The example below shows how Company-X can create a new version 2 policy expression with a second hypothetical ignorable EndOfLife Assertion with a different date and time.
</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-13. </span>Company-X's Version 2 Policy Expression with hypothetical ignorable EndOfLife
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-15. </span>Company-X's Version 2 Policy Expression with hypothetical ignorable EndOfLife
Assertion</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All>
@@ -1605,4 +1652,7 @@
</td></tr><tr><td rowspan="1" colspan="1">20070806</td><td rowspan="1" colspan="1">FS</td><td rowspan="1" colspan="1">Updated references for draft publication.</td></tr><tr><td rowspan="1" colspan="1">20070912</td><td rowspan="1" colspan="1">PY</td><td rowspan="1" colspan="1">Implemented the resolution for issue
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5036">5036</a>. Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/355">355</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070912</td><td rowspan="1" colspan="1">FJH</td><td rowspan="1" colspan="1">Implemented the resolution for issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4943">4943</a>. Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/354">354</a>.
</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Index: ws-policy-primer.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.xml,v
retrieving revision 1.72
retrieving revision 1.73
diff -u -d -r1.72 -r1.73
--- ws-policy-primer.xml 12 Sep 2007 19:43:39 -0000 1.72
+++ ws-policy-primer.xml 12 Sep 2007 20:51:59 -0000 1.73
@@ -1118,7 +1118,7 @@
assertions have compatible nested policies. These two assertions are compatible because
they have the same QName and their nested policies are compatible.</p>
<p>Two policy alternatives are compatible if each policy assertion in one alternative is
- compatible with a policy assertion in the other and vice-versa. For example, policy
+ compatible with a policy assertion in the other and vice-versa. For instance in Examples 3.6 and 3.7, policy
assertions (c1) and (c2) in Company-X’s policy alternative are compatible with policy
assertions (t2) and (t1) in the client’s policy alternative. Company-X’s policy alternative (a)
and the client’s policy alternative are compatible because assertions in these two alternatives
@@ -1127,12 +1127,71 @@
alternative in the other. For example, Company-X’s policy alternative (a) is compatible with
the client’s policy alternative. Company-X’s policy and the client’s policy are compatible because one
of Company-X’s policy alternative is compatible with the client’s policy alternative.</p>
+
<p>For this interaction, the developer’s policy-aware client can use policy alternative (a) to
satisfy Company-X’s conditions or requirements.</p>
<p>Similarly, policy intersection can be used to check if providers expose endpoints that
conform to a standard policy. For example, a major retailer might require all their
supplier endpoints to be compatible with an agreed upon policy.</p>
+ <p>Consider a similar scenario between Company X and the client where nested policy expressions exist in the policy alternatives.
+ The nested policy expressions are compared for compatibility in the context of
+ their parent policy assertions during policy intersection. For example, take these two incompatible policies in Examples 3.8 and 3.9:
+ </p>
+ <example>
+ <head>Company X Nested incompatible policy example</head>
+ <eg xml:space="preserve">Company X
+(P001)<wsp:Policy wsu:Id="..." >
+(P002) <wsp:ExactlyOne>
+(P003) <wsp:All>
+(P004) <sp:EndorsingSupportingTokens
+(P005) xmlns:sp="..."> <!-- parent policy assertion a -->
+(P006) <wsp:Policy> <!-- nested policy a1 -->
+(P007) <sp:X509Token sp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
+(P008) <wsp:Policy>
+(P009) <sp:RequireThumbprintReference />
+(P010) <sp:WssX509V3Token10 />
+(P011) </wsp:Policy>
+(P012) </sp:X509Token>
+(P013) </wsp:Policy>
+(P014) </sp:EndorsingSupportingTokens>...
+(P015) </wsp:All>
+(P016) </wsp:ExactlyOne>
+(P017)</wsp:Policy></eg>
+ </example>
+
+ <example>
+ <head>Client Nested incompatible policy example</head>
+ <eg xml:space="preserve">Client
+(P001)<wsp:Policy wsu:Id="..." >
+(P002) <wsp:ExactlyOne>
+(P003) <wsp:All>
+(P004) <sp:SignedSupportingTokens
+(P005) xmlns:sp="..."> <!-- parent policy assertion b -->
+(P006) <wsp:Policy> <!-- nested policy b1 -->
+(P007) <sp:X509Token sp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
+(P008) <wsp:Policy>
+(P009) <sp:RequireThumbprintReference />
+(P010) <sp:WssX509V3Token10 />
+(P011) </wsp:Policy>
+(P012) </sp:X509Token>
+(P013) </wsp:Policy>
+(P014) </sp:SignedSupportingTokens>...
+(P015) </wsp:All>
+(P016) </wsp:ExactlyOne>
+(P017)</wsp:Policy>
+ </eg>
+ </example>
+
+ <p>In this scenario as illustrated in Examples 3.8 and 3.9, the EndorsingSupportingTokens and
+ SignedSupportingTokens
+ assertions
+ are incompatible even though their nested policy expressions are compatible.
+ This is because the parent policy
+ assertions EndorsingSupportingTokens and SignedSupportingTokens have different
+ QNames.
+ </p>
+
<div3 id="strict-lax-policy-intersection">
<head>Strict and Lax Policy Intersection</head>
<p>
@@ -2565,6 +2624,14 @@
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/355">355</loc>.
</td>
</tr>
+ <tr>
+ <td>20070912</td>
+ <td>FJH</td>
+ <td>Implemented the resolution for issue
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4943">4943</loc>. Editors' action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/354">354</loc>.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Wednesday, 12 September 2007 20:52:08 UTC