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

2006/ws/policy ws-policy-guidelines.html,1.52,1.53

From: Prasad Yendluri via cvs-syncmail <cvsmail@w3.org>
Date: Tue, 08 May 2007 20:33:51 +0000
To: public-ws-policy-eds@w3.org
Message-Id: <E1HlWNb-0008Cr-SV@lionel-hutz.w3.org>

Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv31527

Modified Files:
	ws-policy-guidelines.html 
Log Message:
Latest .html that reflects Maryann's most recent changes

Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -d -r1.52 -r1.53
--- ws-policy-guidelines.html	8 May 2007 01:05:29 -0000	1.52
+++ ws-policy-guidelines.html	8 May 2007 20:33:48 -0000	1.53
@@ -119,7 +119,7 @@
 <h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1. <a href="#introduction">Introduction</a><br>
 2. <a href="#best-practices-list">List of Good Practice Statements</a><br>
 3. <a href="#Assertions">What is an Assertion? </a><br>
-4. <a href="#d3e240">Who is involved in authoring Assertions? </a><br>
+4. <a href="#d3e253">Who is involved in authoring Assertions? </a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;4.1 <a href="#roles"> Roles and Responsibilities </a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.1.1 <a href="#domain-owners"> Assertion Authors</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.1.2 <a href="#consumers">Consumers</a><br>
@@ -136,12 +136,15 @@
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.4.2 <a href="#nested-assertions">Nested Assertions</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;5.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.1 <a href="#d3e660">Optional behavior in Compact authoring</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2 <a href="#d3e700">Optional behavior at runtime</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2.1 <a href="#d3e745">Example</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;5.6 <a href="#levels-of-abstraction">Considerations for Policy Attachment in WSDL </a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;5.7 <a href="#interrelated-domains">Interrelated domains</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;5.5 <a href="#Ignorable">Designating Ignorable Behavior</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.1 <a href="#doc-ignorable-assertions">Assertions and Ignorable Behavior</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2 <a href="#XML-ignorable-assertions">XML Outline for Ignorable </a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;5.6 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.6.1 <a href="#d3e718">Optional behavior in Compact authoring</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.6.2 <a href="#d3e758">Optional behavior at runtime</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.6.2.1 <a href="#d3e803">Example</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;5.7 <a href="#levels-of-abstraction">Considerations for Policy Attachment in WSDL </a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;5.8 <a href="#interrelated-domains">Interrelated domains</a><br>
 6. <a href="#versioning-policy-assertions">Versioning Policy Assertions</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;6.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br>
 &nbsp;&nbsp;&nbsp;&nbsp;6.2 <a href="#extending-assertions"> Evolution of Assertions (Versioning and Compatibility)</a><br>
@@ -207,7 +210,7 @@
         the Socratic style of beginning with a question, and then answering 
         the question.
         </p></div><div class="div1">
-<h2><a name="best-practices-list" id="best-practices-list"></a>2. List of Good Practice Statements</h2><p>The following good practices appear in this document with discussion and examples, and are summarized here for quick reference:</p><ul><li><p><a href="#bp-assertion-specification-parts"><b>1. Parts of an Assertion Specification</b></a></p></li><li><p><a href="#bp-assertion-semantics"><b>2. Semantics of Policy Assertions</b></a></p></li><li><p><a href="#bp-semantics-and-form"><b>3. Semantics of an Assertion and its form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>4. Starting to Build an Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>5. Unique QNames</b></a></p></li><li><p><a href="#bp-assertions-and-message-semantics"><b>6. Assertions and Message Semantics</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>7. Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-definition"><b>8. Definition of Policy Assertions</b></a></p></li><li><p><a href="#bpnesting"><b>9. Nesting of Assertions</b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>10. Assertion XML should allow use of wsp:Optional attribute</b></a></p></li><li><p><a href="#bp-assertion-description-explicitly-allow-optional"><b>11. Assertion description should explicitly indicate that wsp:Optional is allowed.</b></a></p></li><li><p><a href="#bp-limit-optional-assertions"><b>12. Limit use of Optional Assertions</b></a></p></li><li><p><a href="#bp-entire-mep-for-optional"><b>13. Consider entire message exchange pattern when specifying Assertions that may be optional</b></a></p></li><li><p><a href="#bp-indicate-optional-assertion-use"><b>14. Indicate use of  an Optional Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>15. An assertion description should specify a policy subject</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>16. Granularity of policy subjects</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>17. Assertin attachment to multiple policy subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>18. Preferred attachment point for an Assertion</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>19. Independent Assertions</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>20. Change of the Policy Subject Over Time</b></a></p></li></ul></div><div class="div1">
+<h2><a name="best-practices-list" id="best-practices-list"></a>2. List of Good Practice Statements</h2><p>The following good practices appear in this document with discussion and examples, and are summarized here for quick reference:</p><ul><li><p><a href="#bp-assertion-specification-parts"><b>1. Parts of an Assertion Specification</b></a></p></li><li><p><a href="#bp-assertion-semantics"><b>2. Semantics of Policy Assertions</b></a></p></li><li><p><a href="#bp-semantics-and-form"><b>3. Semantics of an Assertion and its form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>4. Starting to Build an Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>5. Unique QNames</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>6. Clear Semantics</b></a></p></li><li><p><a href="#XMLOutline"><b>7. XML Outline</b></a></p></li><li><p><a href="#bp-assertions-and-message-semantics"><b>8. Assertions and Message Semantics</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>9. Duplication of Asertions</b></a></p></li><li><p><a href="#bp-assertion-definition"><b>10. Definition of Policy Assertions</b></a></p></li><li><p><a href="#bp-nesting"><b>11. Nesting of Assertions</b></a></p></li><li><p><a href="#DefineIgnorable"><b>12. Assertions Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>13. Ignorable Attribute in XML</b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>14. Assertion XML should allow use of wsp:Optional attribute</b></a></p></li><li><p><a href="#bp-assertion-description-explicitly-allow-optional"><b>15. Assertion description should explicitly indicate that wsp:Optional is allowed.</b></a></p></li><li><p><a href="#bp-limit-optional-assertions"><b>16. Limit use of Optional Assertions</b></a></p></li><li><p><a href="#bp-entire-mep-for-optional"><b>17. Consider entire message exchange pattern when specifying Assertions that may be optional</b></a></p></li><li><p><a href="#bp-indicate-optional-assertion-use"><b>18. Indicate use of  an Opional Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>19. An assertion description should specify a policy subject</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>20. Granularity of policy subjects</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>21. Assertion attachment to multiple policy subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>22. Preferred attachment point for an Assertion</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>23. Independent Assertions</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>24. Change of the Policy Subject Over Time</b></a></p></li></ul></div><div class="div1">
 <h2><a name="Assertions" id="Assertions"></a>3. What is an Assertion? </h2><p>An assertion is a piece of metadata that describes a
       	capability related to a specific WS-Policy domain. Sets of domain-specific assertions
       	are typically defined in a dedicated specification that describes
@@ -266,7 +269,7 @@
       	best practices will be an assertion specification that describes
       	a contract for the consumers and providers of the capabilities and constraints of the domain.
       	</p></div><div class="div1">
-<h2><a name="d3e240" id="d3e240"></a>4. Who is involved in authoring Assertions? </h2><p>In order for the policy framework to enable communities to
+<h2><a name="d3e253" id="d3e253"></a>4. Who is involved in authoring Assertions? </h2><p>In order for the policy framework to enable communities to
 		express their own domain knowledge, it is necessary to provide basic
 		functionality that all domains could exploit and then allow
 		points of extension where authors of the various WS-Policy
@@ -398,7 +401,7 @@
 				</p><p>
 				The WS-Policy Attachment specification defines a number of different 
 				policy subjects to which an assertion can be attached. For attaching to 
-					WSDL subjects see <a href="#levels-of-abstraction"><b>5.6 Considerations for Policy Attachment in WSDL </b></a> for more detail. 
+					WSDL subjects see <a href="#levels-of-abstraction"><b>5.7 Considerations for Policy Attachment in WSDL </b></a> for more detail. 
 				Additionally, the framework provides for the means to extend the set of 
 				policy subjects beyond the set of subjects defined in the WS-Policy 
 				Attachment specification.
@@ -547,6 +550,27 @@
             		document). If the assertion has a nested policy expression then the assertion XML
             		outline can enumerate the nested assertions that are allowed. An example is the following:
             		</p><div class="exampleOuter"><div class="exampleInner"><pre>
+ &lt;sp:IssuedToken sp:IncludeToken="xs:anyURI"? ... &gt;
+  &lt;sp:Issuer&gt; wsa:EndpointReferenceType&lt;/sp:Issuer&gt;?
+  &lt;sp:RequestSecurityTokenTemplate TrustVersion="xs:anyURI"? &gt;
+    ...
+  &lt;/sp:RequestSecurityTokenTemplate &gt;
+  &lt;wsp:Policy &gt;
+    &lt;sp:RequireDerivedKeys /&gt; ?
+    &lt;sp:RequireExternalReference /&gt; ?
+    &lt;sp:RequireInternalReference /&gt; ?
+    ...
+  &lt;/wsp:Policy&gt; ?
+  ...
+&lt;/sp:IssuedToken&gt;
+ 
+ </pre></div></div><div class="boxedtext"><p><a name="AssertionDefinitions" id="AssertionDefinitions"></a><span class="practicelab">Good
+practice 6: Clear Semantics</span></p><p class="practice"> An assertion description must clearly and completely specify the semantics of a policy 
+			  	    assertion.
+			  	    </p></div><div class="boxedtext"><p><a name="XMLOutline" id="XMLOutline"></a><span class="practicelab">Good
+practice 7: XML Outline</span></p><p class="practice"> An assertion description should provide an XML outline plus an XML schema to specify the
+			  	    syntax of the assertion.
+			  	    </p></div><div class="exampleOuter"><div class="exampleInner"><pre>
  &lt;wsrmp:RMAssertion [wsp:Optional="true"]? ...&gt; 
    ...
  &lt;/wsrmp:RMAssertion/&gt;
@@ -571,7 +595,7 @@
     				behavior that is expressed by a policy assertion. This approach
     				can be considered when messages cannot be self describing. 
      				</p><div class="boxedtext"><p><a name="bp-assertions-and-message-semantics" id="bp-assertions-and-message-semantics"></a><span class="practicelab">Good
-practice 6: Assertions and Message Semantics</span></p><p class="practice">Policy assertions should not be used to express the semantics of a message.
+practice 8: Assertions and Message Semantics</span></p><p class="practice">Policy assertions should not be used to express the semantics of a message.
      				Firstly, an assertion type indicates a runtime behavior.  Secondly, Assertion Authors need to indicate how the runtime behavior represented in the assertion type can be inferred or indicated
      				from a message at runtime.  If there is a need for the behavior
     		 		to be represented in a persistent way or if there is a need for
@@ -609,7 +633,7 @@
 					assertions or they will not include the assertions in
 					their service descriptions. 
 					</p><div class="boxedtext"><p><a name="bp-assertion-duplication" id="bp-assertion-duplication"></a><span class="practicelab">Good
-practice 7: Duplication of Assertions</span></p><p class="practice">Avoid duplication of assertions.
+practice 9: Duplication of Assertions</span></p><p class="practice">Avoid duplication of assertions.
         			A review by a broad community is the best way to ensure that the granularity of a set of domain
         			assertions is appropriate. </p></div></div></div><div class="div2">
 <h3><a name="comparison" id="comparison"></a>5.4 Comparison of Nested and Parameterized Assertions</h3><p>There are two different ways to provide additional information in an
@@ -633,13 +657,13 @@
                                         <code>sp:SignedParts</code> policy assertion 
                                         (this assertion requires the parts of a message to be protected). 
             		                </p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 5-4. </span>Policy Assertion with Assertion Parameters</i></p><div class="exampleInner"><pre>&lt;wsp:Policy&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 5-5. </span>Policy Assertion with Assertion Parameters</i></p><div class="exampleInner"><pre>&lt;wsp:Policy&gt;
   &lt;sp:SignedParts&gt;
     &lt;sp:Body/&gt;
     &lt;sp:Header/&gt;
   &lt;/sp:SignedParts&gt;
 &lt;/wsp:Policy&gt;</pre></div></div><div class="boxedtext"><p><a name="bp-assertion-definition" id="bp-assertion-definition"></a><span class="practicelab">Good
-practice 8: Definition of Policy Assertions</span></p><p class="practice">Define policy assertion parameters for 
+practice 10: Definition of Policy Assertions</span></p><p class="practice">Define policy assertion parameters for 
                                          specifying useful pieces of information necessary for engaging 
                                          the behavior described by an assertion but not relevant to policy 
                                          intersection.</p></div></div><div class="div3">
@@ -679,7 +703,7 @@
         				already requires the use of transport-level security for
         				protecting messages).
         				</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 5-5. </span>Transport Security Policy Assertion</i></p><div class="exampleInner"><pre>&lt;sp:TransportBinding&gt;
+<p style="text-align: left" class="exampleHead"><i><span>Example 5-6. </span>Transport Security Policy Assertion</i></p><div class="exampleInner"><pre>&lt;sp:TransportBinding&gt;
   &lt;Policy&gt;
     &lt;sp:TransportToken&gt;
       &lt;Policy&gt;
@@ -725,7 +749,7 @@
 						<code>HttpToken</code> is used with an empty nested policy in a policy expression
 						by a provider, it will indicate that none of the dependent behaviors
 						namely authentication or client certificate is required.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 5-6. </span>Empty Nested Policy Expression</i></p><div class="exampleInner"><pre>&lt;sp:TransportToken&gt; 
+<p style="text-align: left" class="exampleHead"><i><span>Example 5-7. </span>Empty Nested Policy Expression</i></p><div class="exampleInner"><pre>&lt;sp:TransportToken&gt; 
   &lt;wsp:Policy&gt; 
 	&lt;sp:HttpsToken&gt; 
 	  &lt;wsp:Policy/&gt; 
@@ -757,14 +781,30 @@
             		first class role in the outcome. There is one caveat to watch out for: policy assertions
             		with deeply nested policy can greatly increase the complexity of a policy and should be
             		avoided when they are not needed.</p><div class="boxedtext"><p><a name="bp-nesting" id="bp-nesting"></a><span class="practicelab">Good
-practice 9: Nesting of Assertions</span></p><p class="practice">If the assertion
+practice 11: Nesting of Assertions</span></p><p class="practice">If the assertion
         			authors want to delegate the processing to the framework,
         			utilizing nesting should be considered. Otherwise, domain
         			specific comparison algorithms may need to be devised and be
         			delegated to the specific domain handlers that are not visible
         			to the WS-Policy framework.</p></div></div></div><div class="div2">
-<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>5.5 Designating Optional Behaviors</h3><div class="div3">
-<h4><a name="d3e660" id="d3e660"></a>5.5.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors that may be engaged by a consumer. When using the
+<h3><a name="Ignorable" id="Ignorable"></a>5.5 Designating Ignorable Behavior</h3><p>Policy assertions can be marked with an attribute to indicate that the assertion
+			  	can be ignored by the interstection algorithm. Assertion authors should consider
+			  	whether the behavior represented by the Assertion they are defining can be ignored for the purposes of 
+			  	intersection, and indicate this in the definition of the assertion.  The use of the 
+			  	ignorable attribute influences whether or not certain assertions are part of the
+			  	compatability assessment between two alternatives. See [tbd] for details on the use 
+			  	of the ignorable attribute.
+				</p><div class="div3">
+<h4><a name="doc-ignorable-assertions" id="doc-ignorable-assertions"></a>5.5.1 Assertions and Ignorable Behavior</h4><div class="boxedtext"><p><a name="DefineIgnorable" id="DefineIgnorable"></a><span class="practicelab">Good
+practice 12: Assertions Document Ignorable Behavior</span></p><p class="practice"> An assertion description should use the wsp:Ignorable attribute
+			  	    to indicate that the behavior indicated by the QName may be ignored by policy intersection. 
+			  	    </p></div></div><div class="div3">
+<h4><a name="XML-ignorable-assertions" id="XML-ignorable-assertions"></a>5.5.2 XML Outline for Ignorable </h4><div class="boxedtext"><p><a name="ignorableAssertions" id="ignorableAssertions"></a><span class="practicelab">Good
+practice 13: Ignorable Attribute in XML</span></p><p class="practice"> An assertion XML outline should allow for the use of the wsp:Ignorable attribute
+			  	    to indicate ignorable behavior.
+			  	    </p></div></div></div><div class="div2">
+<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>5.6 Designating Optional Behaviors</h3><div class="div3">
+<h4><a name="d3e718" id="d3e718"></a>5.6.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors that may be engaged by a consumer. When using the
 					compact authoring form for assertions, such behaviors are marked by
 					using <code>wsp:Optional</code> attribute with a value of
 					"true". (In order to simplify reference to such assertions, 
@@ -779,30 +819,30 @@
 					the wsp:Optional attribute. An assertion author should clearly indicate in the assertion 
 					definition that it is possible to be optional 
 					and to allow the use of the wsp:Optional attribute in the XML definition. </p><div class="boxedtext"><p><a name="bp-assertion-xml-allow-optional" id="bp-assertion-xml-allow-optional"></a><span class="practicelab">Good
-practice 10: Assertion XML should allow use of wsp:Optional attribute</span></p><p class="practice">An assertion XML outline should allow the use of the wsp:Optional attribute to 
+practice 14: Assertion XML should allow use of wsp:Optional attribute</span></p><p class="practice">An assertion XML outline should allow the use of the wsp:Optional attribute to 
 						indicate optional behaviors.</p></div><p>To give a general example, the definition of assertion syntax for a hypothetical assertion such as SampleAssertion, 
 					should allow attribute extensibility as part of the XML definition, allowing the wsp:Optional attribute to be used:
 					</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 5-7. </span>Use of @any for attribute extensibility</i></p><div class="exampleInner"><pre>/samplePrefix:SampleAssertion/@any
+<p style="text-align: left" class="exampleHead"><i><span>Example 5-8. </span>Use of @any for attribute extensibility</i></p><div class="exampleInner"><pre>/samplePrefix:SampleAssertion/@any
 This is an extensibility mechanism to allow additional attributes to be added to the element, including wsp:Optional.
 				</pre></div></div><p>The portion of the assertion definition that describes policy subjects and assertion attachment should indicate
 				that wsp:Optional can be used to indicate that the behavior is optional for the policy subject.</p><div class="boxedtext"><p><a name="bp-assertion-description-explicitly-allow-optional" id="bp-assertion-description-explicitly-allow-optional"></a><span class="practicelab">Good
-practice 11: Assertion description should explicitly indicate that wsp:Optional is allowed.</span></p><p class="practice">An assertion description should use the wsp:Optional attribute to indicate that the 
+practice 15: Assertion description should explicitly indicate that wsp:Optional is allowed.</span></p><p class="practice">An assertion description should use the wsp:Optional attribute to indicate that the 
 						behavior indicated by the QName is optional for the associated policy subject.</p></div><p>Continuing the example with the hypothetical SampleAssertion, the section on Assertion Attachment should 
 					include discussion of optionality.
 				</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 5-8. </span>Assertion Attachment text mentions optionality for policy assertion subjects</i></p><div class="exampleInner"><pre>The SampleAssertion policy assertion indicates behavior over all messages in a binding, so
+<p style="text-align: left" class="exampleHead"><i><span>Example 5-9. </span>Assertion Attachment text mentions optionality for policy assertion subjects</i></p><div class="exampleInner"><pre>The SampleAssertion policy assertion indicates behavior over all messages in a binding, so
 it has an Endpoint Policy Subject and must be attached to a wsdl:binding or wsdl:port. 
 The assertion may be optional when attached to these subjects, allowing use of wsp:Optional.
 					</pre></div></div></div><div class="div3">
-<h4><a name="d3e700" id="d3e700"></a>5.5.2 Optional behavior at runtime</h4><p>Since optional behaviors indicate optionality for
+<h4><a name="d3e758" id="d3e758"></a>5.6.2 Optional behavior at runtime</h4><p>Since optional behaviors indicate optionality for
 					both the provider and the consumer, behaviors that must
 					always be engaged by a consumer must not be marked as
 					"optional" with a value "true" since this would allow the
 					consumer to select the policy alternative that does not contain the assertion,
 					and thus not engaging the behavior.
 				</p><div class="boxedtext"><p><a name="bp-limit-optional-assertions" id="bp-limit-optional-assertions"></a><span class="practicelab">Good
-practice 12: Limit use of Optional Assertions</span></p><p class="practice">Assertion Authors should not use optional assertions for behaviors that must be present 
+practice 16: Limit use of Optional Assertions</span></p><p class="practice">Assertion Authors should not use optional assertions for behaviors that must be present 
 						in compatible policy expressions.</p></div><p> The target scope of an optional assertion is an important factor for
 					Assertion Authors to consider as it determines the
 					<em>granularity</em> where the behavior is optionally
@@ -834,7 +874,7 @@
 					assertions and require the use of endpoint policy subject 
 					when message policy subject is used via attachment.
 				</p><div class="boxedtext"><p><a name="bp-entire-mep-for-optional" id="bp-entire-mep-for-optional"></a><span class="practicelab">Good
-practice 13: Consider entire message exchange pattern when specifying Assertions that may be optional</span></p><p class="practice">Assertion Authors should associate optional assertions with the appropriate endpoint and use the smallest 
+practice 17: Consider entire message exchange pattern when specifying Assertions that may be optional</span></p><p class="practice">Assertion Authors should associate optional assertions with the appropriate endpoint and use the smallest 
 						possible granularity to limit the degree to which optionality applies.</p></div><p>
 					Behaviors must be engaged
 					with respect to messages that are targeted to the provider
@@ -848,9 +888,9 @@
 					(Such an out of band mechanism is outside the scope of WS-Policy 
 					Framework).  
 				</p><div class="boxedtext"><p><a name="bp-indicate-optional-assertion-use" id="bp-indicate-optional-assertion-use"></a><span class="practicelab">Good
-practice 14: Indicate use of  an Optional Assertion</span></p><p class="practice">When a given behavior may be optional, it must be possible for both message participants to determine that the assertion is selected by both parties, 
+practice 18: Indicate use of  an Optional Assertion</span></p><p class="practice">When a given behavior may be optional, it must be possible for both message participants to determine that the assertion is selected by both parties, 
 					either out of band or as reflected by the message content.</p></div><div class="div4">
-<h5><a name="d3e745" id="d3e745"></a>5.5.2.1 Example</h5><p>
+<h5><a name="d3e803" id="d3e803"></a>5.6.2.1 Example</h5><p>
 					The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an example that outlines the 
 					use of 
 					<cite><a href="#MTOM">MTOM</a></cite> as an optional behavior that can be engaged by a consumer. 
@@ -876,12 +916,12 @@
 					exchange when optionally used in part of that exchange  
 					(<a href="#bp-entire-mep-for-optional">Good Practice: Consider entire message exchange pattern when specifying Assertions that may be optional</a>).
 				</p></div></div></div><div class="div2">
-<h3><a name="levels-of-abstraction" id="levels-of-abstraction"></a>5.6 Considerations for Policy Attachment in WSDL </h3><p>A behavior identified by a policy assertion applies to the
+<h3><a name="levels-of-abstraction" id="levels-of-abstraction"></a>5.7 Considerations for Policy Attachment in WSDL </h3><p>A behavior identified by a policy assertion applies to the
         		associated policy subject. If a policy assertion is to be used
         		within WSDL, assertion authors must specify a WSDL
         		policy subject. 
         		</p><div class="boxedtext"><p><a name="bp-WSDL-policy-subject" id="bp-WSDL-policy-subject"></a><span class="practicelab">Good
-practice 15: An assertion description should specify a policy subject</span></p><p class="practice">Assertion authors should associate assertions with the appropriate policy subject.  
+practice 19: An assertion description should specify a policy subject</span></p><p class="practice">Assertion authors should associate assertions with the appropriate policy subject.  
 					For instance, if a policy assertion is to be used with WSDL, the assertion description 
 					should specify a WSDL policy subject – such as service, endpoint, operation and message.
 				    </p></div><p>The specific WSDL policy subject is determined with respect to 
@@ -896,7 +936,7 @@
 				the processing for considering a specific attachment point and
 				policy subject. This topic is considered in detail in <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>
 				</p><div class="boxedtext"><p><a name="bp-WSDL-policy-subject-Granularity" id="bp-WSDL-policy-subject-Granularity"></a><span class="practicelab">Good
-practice 16: Granularity of policy subjects</span></p><p class="practice">Assertion authors should choose the most granular policy subject 
+practice 20: Granularity of policy subjects</span></p><p class="practice">Assertion authors should choose the most granular policy subject 
 					that the behavior represented by a policy assertion applies to.
 					</p></div><p> For a given WSDL policy subject, there may be several
         		attachment points. For example, there are three attachment
@@ -920,7 +960,7 @@
         		the Web Services Security Policy specification) to an endpoint
         		policy subject instead of a message policy subject. 
         		</p><div class="boxedtext"><p><a name="bp-WSDL-multiple-policy-subjects" id="bp-WSDL-multiple-policy-subjects"></a><span class="practicelab">Good
-practice 17: Assertion attachment to multiple policy subjects</span></p><p class="practice">If an assertion is allowed to be associated with multiple policy 
+practice 21: Assertion attachment to multiple policy subjects</span></p><p class="practice">If an assertion is allowed to be associated with multiple policy 
 					subjects, the assertion description should describe the semantics of multiple 
 					instances of the same assertion attached to multiple policy subjects 
 					at the same time.
@@ -948,7 +988,7 @@
 					assertion author can specify additional constraints and
 					assumptions for attachment and engagement of behavior.
 				</p><div class="boxedtext"><p><a name="bp-WSDL-preferred-attachment-point" id="bp-WSDL-preferred-attachment-point"></a><span class="practicelab">Good
-practice 18: Preferred attachment point for an Assertion</span></p><p class="practice">If an assertion can be attached at multiple points within a policy 
+practice 22: Preferred attachment point for an Assertion</span></p><p class="practice">If an assertion can be attached at multiple points within a policy 
 						subject, an assertion author should specify a preferred attachment 
 						point for the chosen policy subject.
 					</p></div><p>One approach in WSDL is to identify different attachment points in
@@ -966,7 +1006,7 @@
 				policy assertions do not target wire-level behaviors but
 				rather abstract requirements, this technique does not apply. 
 				</p></div><div class="div2">
-<h3><a name="interrelated-domains" id="interrelated-domains"></a>5.7 Interrelated domains</h3><p>Assertion authors need to be clear about how assertions defined in  
+<h3><a name="interrelated-domains" id="interrelated-domains"></a>5.8 Interrelated domains</h3><p>Assertion authors need to be clear about how assertions defined in  
 				their domain may fit with assertions for interrelated domains. A  
 				classic example of such an interrelated domain is security, because  
 				security tends to
@@ -1006,7 +1046,7 @@
            			[<cite><a href="#WS-Addressing">WS-Addressing Core</a></cite>]. These equivalent behaviors
            			are mutually exclusive for an interaction. Such equivalent
            			behaviors can be modeled as independent assertions. </p><div class="boxedtext"><p><a name="bp-independent-assertions" id="bp-independent-assertions"></a><span class="practicelab">Good
-practice 19: Independent Assertions</span></p><p class="practice">An assertion author should use independent assertions for modeling multiple versions of a behavior.</p></div><p>The
+practice 23: Independent Assertions</span></p><p class="practice">An assertion author should use independent assertions for modeling multiple versions of a behavior.</p></div><p>The
            			policy expression in the example below requires the use of
            			WSS: SOAP Message Security 1.0. </p><div class="exampleOuter">
 <p style="text-align: left" class="exampleHead"><i><span>Example 6-1. </span>Message-level Security and WSS: SOAP Message Security 1.0</i></p><div class="exampleInner"><pre>&lt;Policy&gt;
@@ -1034,7 +1074,7 @@
 				new policy subjects are added it is incumbent on the authors to retain the 
 				semantic of the policy assertion. 
 			</p><div class="boxedtext"><p><a name="bp-policy-subject-change" id="bp-policy-subject-change"></a><span class="practicelab">Good
-practice 20: Change of the Policy Subject Over Time</span></p><p class="practice">If the policy subjects change over time, 
+practice 24: Change of the Policy Subject Over Time</span></p><p class="practice">If the policy subjects change over time, 
 				the assertion description should also be versioned to reflect this 
 				change.</p></div></div></div><div class="div1">
 <h2><a name="best-practices-attachment" id="best-practices-attachment"></a>7. Applying Best Practices for  Policy Attachment</h2><div class="div2">
@@ -1538,4 +1578,8 @@
 							<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue 3989</a>
 							and editors' action item
 							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/227">227</a>.
+						</td></tr><tr><td rowspan="1" colspan="1">20070508</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Updated Section 5 for adding guidelines G9, G10 on ignorable, and G5 , G6 (general)
+							to address editors' action items
+							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/251">251</a>.
+							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/256">256</a>.
 						</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Received on Tuesday, 8 May 2007 20:34:05 GMT

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