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

2006/ws/policy ws-policy-primer.html,1.66,1.67 ws-policy-primer.xml,1.72,1.73

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
Message-Id: <E1IVZBq-0000l4-Tr@lionel-hutz.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 @@
 &nbsp;&nbsp;&nbsp;&nbsp;3.7 <a href="#combine-policies">Combine Policies</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;3.8 <a href="#extensibility-and-versioning">Extensibility and Versioning</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.1 <a href="#ext-vers-policylanguage">Policy Language</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.2 <a href="#d3e1411">Policy Expressions</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.2 <a href="#d3e1425">Policy Expressions</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.3 <a href="#ignorable-and-versioning">Use of Ignorable attribute and an alternative Versioning Scenario</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.8.4 <a href="#ignorable-and-optional-and-versioning">Use of Ignorable and Optional attributes</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;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)&lt;wsp:Policy wsu:Id="..." &gt;
+(P002)  &lt;wsp:ExactlyOne&gt;
+(P003)    &lt;wsp:All&gt;
+(P004)      &lt;sp:EndorsingSupportingTokens 
+(P005)        xmlns:sp="..."&gt; &lt;!-- parent policy assertion a --&gt;      
+(P006)        &lt;wsp:Policy&gt; &lt;!-- nested policy a1  --&gt;
+(P007)          &lt;sp:X509Token  sp:IncludeToken=".../IncludeToken/AlwaysToRecipient"&gt; 
+(P008)            &lt;wsp:Policy&gt;       
+(P009)              &lt;sp:RequireThumbprintReference /&gt;
+(P010)              &lt;sp:WssX509V3Token10 /&gt;
+(P011)            &lt;/wsp:Policy&gt;
+(P012)          &lt;/sp:X509Token&gt;
+(P013)        &lt;/wsp:Policy&gt;
+(P014)      &lt;/sp:EndorsingSupportingTokens&gt;... 
+(P015)    &lt;/wsp:All&gt;
+(P016)  &lt;/wsp:ExactlyOne&gt;
+(P017)&lt;/wsp:Policy&gt;</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)&lt;wsp:Policy wsu:Id="..." &gt;
+(P002)   &lt;wsp:ExactlyOne&gt;
+(P003)	   &lt;wsp:All&gt;
+(P004)       &lt;sp:SignedSupportingTokens 
+(P005)	       xmlns:sp="..."&gt; &lt;!-- parent policy assertion b --&gt;      
+(P006)	       &lt;wsp:Policy&gt; &lt;!-- nested policy b1 --&gt;
+(P007)	         &lt;sp:X509Token  sp:IncludeToken=".../IncludeToken/AlwaysToRecipient"&gt; 
+(P008)	           &lt;wsp:Policy&gt;       
+(P009)               &lt;sp:RequireThumbprintReference /&gt;
+(P010)	             &lt;sp:WssX509V3Token10 /&gt;
+(P011)	           &lt;/wsp:Policy&gt;
+(P012)	        &lt;/sp:X509Token&gt;
+(P013)	      &lt;/wsp:Policy&gt;
+(P014)	    &lt;/sp:SignedSupportingTokens&gt;... 
+(P015)	  &lt;/wsp:All&gt;
+(P016)  &lt;/wsp:ExactlyOne&gt;
+(P017)&lt;/wsp:Policy&gt;
+          </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>&lt;wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" &gt;
+<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>&lt;wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" &gt;
   &lt;PolicyReference URI="#secure" /&gt;
   &lt;wsdl:operation name="GetRealQuote"&gt;…&lt;/wsdl:operation&gt;
   …
@@ -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>&lt;Policy wsu:Id=”common2”&gt;
+<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>&lt;Policy wsu:Id=”common2”&gt;
   &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
   &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
 &lt;/Policy&gt;
@@ -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>&lt;Policy&gt;
+<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>&lt;Policy&gt;
   &lt;All&gt;
     &lt;Policy&gt;
      &lt;mtom:OptimizedMimeSerialization wsp:Optional="true"/&gt;
@@ -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>&lt;Policy&gt;
+<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>&lt;Policy&gt;
   &lt;ExactlyOne&gt;
     &lt;All&gt;
       &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
@@ -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>&lt;Policy&gt;
+<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>&lt;Policy&gt;
   &lt;ExactlyOne&gt;
     &lt;All&gt;
       &lt;wsam:Addressing&gt;…&lt;/wsam:Addressing&gt;
@@ -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>&lt;Policy&gt;
   &lt;ExactlyOne&gt;
     &lt;All&gt;
@@ -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)&lt;wsp:Policy wsu:Id="..." &gt;
+(P002)  &lt;wsp:ExactlyOne&gt;
+(P003)    &lt;wsp:All&gt;
+(P004)      &lt;sp:EndorsingSupportingTokens 
+(P005)        xmlns:sp="..."&gt; &lt;!-- parent policy assertion a --&gt;      
+(P006)        &lt;wsp:Policy&gt; &lt;!-- nested policy a1  --&gt;
+(P007)          &lt;sp:X509Token  sp:IncludeToken=".../IncludeToken/AlwaysToRecipient"&gt; 
+(P008)            &lt;wsp:Policy&gt;       
+(P009)              &lt;sp:RequireThumbprintReference /&gt;
+(P010)              &lt;sp:WssX509V3Token10 /&gt;
+(P011)            &lt;/wsp:Policy&gt;
+(P012)          &lt;/sp:X509Token&gt;
+(P013)        &lt;/wsp:Policy&gt;
+(P014)      &lt;/sp:EndorsingSupportingTokens&gt;... 
+(P015)    &lt;/wsp:All&gt;
+(P016)  &lt;/wsp:ExactlyOne&gt;
+(P017)&lt;/wsp:Policy&gt;</eg>
+ </example>
+     
+        <example>
+          <head>Client Nested incompatible policy example</head>
+          <eg xml:space="preserve">Client
+(P001)&lt;wsp:Policy wsu:Id="..." &gt;
+(P002)   &lt;wsp:ExactlyOne&gt;
+(P003)	   &lt;wsp:All&gt;
+(P004)       &lt;sp:SignedSupportingTokens 
+(P005)	       xmlns:sp="..."&gt; &lt;!-- parent policy assertion b --&gt;      
+(P006)	       &lt;wsp:Policy&gt; &lt;!-- nested policy b1 --&gt;
+(P007)	         &lt;sp:X509Token  sp:IncludeToken=".../IncludeToken/AlwaysToRecipient"&gt; 
+(P008)	           &lt;wsp:Policy&gt;       
+(P009)               &lt;sp:RequireThumbprintReference /&gt;
+(P010)	             &lt;sp:WssX509V3Token10 /&gt;
+(P011)	           &lt;/wsp:Policy&gt;
+(P012)	        &lt;/sp:X509Token&gt;
+(P013)	      &lt;/wsp:Policy&gt;
+(P014)	    &lt;/sp:SignedSupportingTokens&gt;... 
+(P015)	  &lt;/wsp:All&gt;
+(P016)  &lt;/wsp:ExactlyOne&gt;
+(P017)&lt;/wsp:Policy&gt;
+          </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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:04 GMT