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

2006/ws/policy ws-policy-guidelines.html,1.82,1.83

From: David Orchard via cvs-syncmail <cvsmail@w3.org>
Date: Tue, 17 Jul 2007 15:49:43 +0000
To: public-ws-policy-eds@w3.org
Message-Id: <E1IApJ1-0000tJ-QY@lionel-hutz.w3.org>

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

Modified Files:
	ws-policy-guidelines.html 
Log Message:
Update to section 5.5 for partial resolution of 4661/4462

Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.82
retrieving revision 1.83
diff -u -d -r1.82 -r1.83
--- ws-policy-guidelines.html	17 Jul 2007 11:47:41 -0000	1.82
+++ ws-policy-guidelines.html	17 Jul 2007 15:49:41 -0000	1.83
@@ -136,11 +136,11 @@
 &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;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;&nbsp;&nbsp;&nbsp;&nbsp;5.5.1 <a href="#d3e764">Ignorable behavior in authoring</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2 <a href="#d3e777">Ignorable behavior at runtime</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="#d3e778">Optional behavior in Compact authoring</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.6.2 <a href="#d3e818">Optional behavior at runtime</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.6.1 <a href="#d3e792">Optional behavior in Compact authoring</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.6.2 <a href="#d3e832">Optional behavior at runtime</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>
@@ -208,8 +208,9 @@
         the question.
         </p></div><div class="div1">
 <h2><a name="best-practices-list" id="best-practices-list"></a>2. List of Best Practice Statements</h2><p>The following Best Practices appear in this document with discussion and examples, and are summarized here for quick reference:</p><ul><li><p><a href="#bp-assertion-semantics"><b>1. Semantics Independent of 
-				Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-compatibility-tests"><b>2. Behaviors Relevant to Compatibility Tests</b></a></p></li><li><p><a href="#bp-semantics-and-form"><b>3. Semantics Independent of the Form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>4. Start with a Simple Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>5. Use Unique QNames</b></a></p></li><li><p><a href="#XMLOutline"><b>6. Provide an XML Outline</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>7. Specify Semantics Clearly</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>8. Not Necessary to Understand a Message</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>9. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>10. Use Parameters for Useful 
-					Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>11. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>12. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>13. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#DefineIgnorable"><b>14. Assertions Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>15. Ignorable Attribute in XML</b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>16. Assertion XML should allow use of wsp:Optional attribute</b></a></p></li><li><p><a href="#bp-assertion-description-explicitly-allow-optional"><b>17. Use the wsp:Optional attribute to indicate optional</b></a></p></li><li><p><a href="#bp-limit-optional-assertions"><b>18. Limit use of Optional Assertions</b></a></p></li><li><p><a href="#bp-entire-mep-for-optional"><b>19. Consider entire message exchange pattern whn specifying Assertions that may be optional</b></a></p></li><li><p><a href="#bp-indicate-optional-assertion-use"><b>20. Indicate use of  an Optional Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>21. Specify Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>22. Choose the Most Granular Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>23. Define Semantics of Attachment to Multiple Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>24. Specify Preferred Attachment Point for an Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-multiple-instance-semantics"><b>25. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-specify-composition"><b>26. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>27. Use Independent Assertions for Different Versions of a Behavior</b></a></p></li><i><p><a href="#bp-policy-subject-change"><b>28. Change of the Policy Subject Over Time</b></a></p></li></ul></div><div class="div1">
+				Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-compatibility-tests"><b>2. Behaviors Relevant to Compatibility Tests</b></a></p></li><li><p><a href="#bp-semantics-and-form"><b>3. Semantics Independent of the Form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>4. Start with a Simple Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>5. Use Unique QNames</b></a></p></li><li><p><a href="#XMLOutline"><b>6. Provide an XML Outline</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>7. Specify Semantics Clearly</b></a></p></li><li><p><a href="#DefineIgnorable"><b>8. Assertion Authors Should Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>9. Assertion Authors Should Document Use of the Ignorable 
+Attribute in XML </b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>10. Not Necessary to Understand a Message</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>11. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>12. Use Parameters for Useful 
+					Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>13. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>14. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>15. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>16. Assertion XML should allow use of wsp:Optional attribute</b></a></p></li><li><p><a href="#bp-assertion-description-explicitly-allow-optional"><b>17. Use the wsp:Optional attribute to indicate optional</b></a></p></li><li><p><a href="#bp-limit-optional-assertions"><b>18. Limit use of Optional Assertions</b></a></p></li><li><p><a href="#bp-entire-mep-for-optional"><b>19. 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>20. Indicate use of  an Optional Assertion</b></a></p></li><li><p>a href="#bp-WSDL-policy-subject"><b>21. Specify Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>22. Choose the Most Granular Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>23. Define Semantics of Attachment to Multiple Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>24. Specify Preferred Attachment Point for an Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-multiple-instance-semantics"><b>25. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-specify-composition"><b>26. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>27. Use Independent Assertions for Different Versions of a Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>28. 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
@@ -602,6 +603,14 @@
  </pre></div></div><div class="boxedtext"><p><a name="AssertionDefinitions" id="AssertionDefinitions"></a><span class="practicelab">Best
 Practice 7: Specify Semantics Clearly</span></p><p class="practice"> Assertion authors should clearly and completely specify the
  			  	    	 semantics of a policy assertion.
+			  	    </p></div><div class="boxedtext"><p><a name="DefineIgnorable" id="DefineIgnorable"></a><span class="practicelab">Best
+Practice 8: Assertion Authors Should Document Ignorable Behavior</span></p><p class="practice">An assertion description should include guidance as to the use of (or 
+constraint against the use of) the wsp:Ignorable attribute to indicate 
+whether or not the behavior indicated by the QName may be ignored by policy 
+intersection. </p></div><div class="boxedtext"><p><a name="ignorableAssertions" id="ignorableAssertions"></a><span class="practicelab">Best
+Practice 9: Assertion Authors Should Document Use of the Ignorable 
+Attribute in XML </span></p><p class="practice"> An Assertion Author should document, in the XML outline and/or schema for 
+the assertion, whether or not the assertion allows for the use of the wsp:Ignorable attribute. 
 			  	    </p></div></div><div class="div3">
 <h4><a name="self-describing" id="self-describing"></a>5.3.3  Self Describing Messages </h4><p> WS-Policy is intended to communicate the requirements, capabilities and
     	 			behaviors of nodes that provide the message's path, not specifically to declare properties of the message semantics. One
@@ -633,7 +642,7 @@
      				their assertions by specifying additional properties, headers,
      				etc. that must be present in a message as part of their assertion design.
      				</p><div class="boxedtext"><p><a name="bp-not-necessary-to-understand-a-message" id="bp-not-necessary-to-understand-a-message"></a><span class="practicelab">Best
-Practice 8: Not Necessary to Understand a Message</span></p><p class="practice">Assertion Authors should not define policy assertions to represent information that is necessary to understand a message.</p></div><p>For example, if the details of a message's encryption ( e.g., the cipher used, etc) are expressed
+Practice 10: Not Necessary to Understand a Message</span></p><p class="practice">Assertion Authors should not define policy assertions to represent information that is necessary to understand a message.</p></div><p>For example, if the details of a message's encryption ( e.g., the cipher used, etc) are expressed
      				in policy that isn't attached to the message, it isn't possible
      				to later decipher it. This is very different from expressing, in
      				policy, what ciphers (and so forth) are supported by a particular
@@ -663,7 +672,7 @@
 					</p><p>It is the responsibility of the Assertion Authors to 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 class="boxedtext"><p><a name="bp-assertion-duplication" id="bp-assertion-duplication"></a><span class="practicelab">Best
-Practice 9: Avoid Duplication of Assertions</span></p><p class="practice">Assertion Authors should reuse an existing assertion (rather than create a new one) whenever possible.</p></div></div></div><div class="div2">
+Practice 11: Avoid Duplication of Assertions</span></p><p class="practice">Assertion Authors should reuse an existing assertion (rather than create a new one) whenever possible.</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
 				assertion beyond its type. We cover these two cases below followed by a
 				comparison of these approaches targeting when to use either of the approach.  
@@ -678,7 +687,7 @@
 					domain specific processing for policy intersection.</p><p>In the XML representation of a policy assertion, the child elements 
 					and attributes of the assertion excluding child elements and attributes 
 					from the policy language namespace name are the assertion parameters.</p><div class="boxedtext"><p><a name="bp-assertion-parameters" id="bp-assertion-parameters"></a><span class="practicelab">Best
-Practice 10: Use Parameters for Useful 
+Practice 12: Use Parameters for Useful 
 					Information</span></p><p class="practice">Assertion Authors should represent useful (or additional) 
                         information necessary for engaging the behavior represented by a policy 
                         assertion as assertion parameters.	
@@ -708,10 +717,10 @@
 						that are allowed. 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-dependent-behaviors" id="bp-dependent-behaviors"></a><span class="practicelab">Best
-Practice 11: Use Nested Assertions for Dependent Behaviors</span></p><p class="practice">Assertion Authors should represent dependent behaviors that are relevant 
+Practice 13: Use Nested Assertions for Dependent Behaviors</span></p><p class="practice">Assertion Authors should represent dependent behaviors that are relevant 
 						to a compatibility test and apply to the same policy subject using 
 						nested policy assertions.</p></div><div class="boxedtext"><p><a name="bp-declare-nested-assertions" id="bp-declare-nested-assertions"></a><span class="practicelab">Best
-Practice 12: Enumerate Nested Assertions</span></p><p class="practice">If there is a nested policy expression, then the Assertion Authors 
+Practice 14: Enumerate Nested Assertions</span></p><p class="practice">If there is a nested policy expression, then the Assertion Authors 
 						should enumerate the nested policy assertions that are allowed.</p></div><p>The main consideration for selecting parameters or nesting
 						of assertions is that <em>the framework intersection
 							algorithm processes nested alternatives, but does not consider
@@ -733,7 +742,7 @@
 						delegated to the specific domain handlers that are not visible
 						to the WS-Policy framework. However, domain specific intersection processing reduces 
 						interop and increases the burden to implement an assertion.</p><div class="boxedtext"><p><a name="bp-discourage-domain-specific-intersection" id="bp-discourage-domain-specific-intersection"></a><span class="practicelab">Best
-Practice 13: Discourage Domain Specific Intersection</span></p><p class="practice">Assertion authors should only specify domain specific 
+Practice 15: Discourage Domain Specific Intersection</span></p><p class="practice">Assertion authors should only specify domain specific 
 						intersection semantics when policy intersection is insufficient.</p></div><p>We will use the WS-SecurityPolicy to illustrate the use of nested assertions.
         				</p><p>Securing messages is a complex usage scenario. The WS-SecurityPolicy Assertion Authors have defined the
         				<code>sp:TransportBinding</code> policy assertion to indicate
@@ -819,24 +828,17 @@
 &lt;/sp:TransportToken&gt;</pre></div></div><p>A non-anonymous client who requires authentication or client
 						certificate will not be able to use this provider solely on the basis
 						of intersection algorithm alone.</p></div></div><div class="div2">
-<h3><a name="Ignorable" id="Ignorable"></a>5.5 Designating Ignorable Behavior</h3><table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%">&nbsp;</td></tr><tr><td colspan="2" align="left" valign="top">Looks incomplete – carries Best Practices but there isn’t any explanatory text.</td></tr></table><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">Best
-Practice 14: 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">Best
-Practice 15: 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="Ignorable" id="Ignorable"></a>5.5 Designating Ignorable Behavior</h3><div class="div3">
+<h4><a name="d3e764" id="d3e764"></a>5.5.1 Ignorable behavior in authoring</h4><p>  
+     			The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict).  The Framework also defines an attribute (wsp:Ignorable) that can be used to influence whether assertions are part of the compatability assessment between two alternatives.  [see <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> and <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>]. Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and should follow <a href="#DefineIgnorable"><b>8. Assertion Authors Should Document Ignorable Behavior</b></a> and <a href="#ignorableAssertions"><b>9. Assertion Authors Should Document Use of the Ignorable 
+Attribute in XML </b></a> to include this guidance in the assertion's definition.</p></div><div class="div3">
+<h4><a name="d3e777" id="d3e777"></a>5.5.2 Ignorable behavior at runtime</h4><p>Regardless of whether the assertion allows the ignorable attribute, assertion authors should
+			  	indicate the semantic of the runtime behavior in the description of the assertion.
+			  	</p><p>
+As said in <a href="ws-policy-primer.html#strict-lax-policy-intersection">section 3.4.1 Strict and Lax Policy Intersection</a> in <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>, "Regardless of the chosen intersection mode, ignorable assertions do not express any wire-level requirements on the behavior of consumers - in other words, a consumer could choose to ignore any such assertions that end up in the resulting policy after intersection, with no adverse effects on runtime interactions." Therefore, any assertion that is marked with ignorable should not impose any wire-level requirements on the part of consumers. Assertion Authors are reminded that regardless of whether an assertion is marked as ignorable, policy consumers using strict intersection will not 'ignore' the assertion. 
+			  	</p></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="d3e778" id="d3e778"></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
+<h4><a name="d3e792" id="d3e792"></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, 
@@ -867,7 +869,7 @@
 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="d3e818" id="d3e818"></a>5.6.2 Optional behavior at runtime</h4><p>Since optional behaviors indicate optionality for
+<h4><a name="d3e832" id="d3e832"></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
@@ -1521,7 +1523,7 @@
 					(<a href="#best-practices-list"><b>2. List of Best Practice Statements</b></a>).
 					</p></li><li><p>Incorporated the Best Practices from 
 						<a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf">IBM/Microsoft Contibution.</a>
-					</p></li><li><p>Made editorial changes to align with the OASIS WS-SecurityPolicy specification.</p></li><li><p>Made editorial changes to align with the W3C WS-Addressing 1.0 Metadata specification.</p></li></ul></div><div class="div1">
+					</p></li><li><p>Made editorial changes to align with the OASIS WS-SecurityPolicy specification.</p></li><li><p>Made editorial changes to align with the W3C WS-Addressing 1.0 Metadata specification.</p></li><li><p>Updated Section 5.5 for 4661/4662.</p></li></ul></div><div class="div1">
 <h2><a name="change-log" id="change-log"></a>F. Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log (Non-Normative)</h2><a name="ws-policy-primer-changelog-table"></a><table border="1"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Author</th><th rowspan="1" colspan="1">Description</th></tr><tr><td rowspan="1" colspan="1">20060829</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Created first draft based on agreed outline and content</td></tr><tr><td rowspan="1" colspan="1">20061013</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Editorial fixes (suggested by Frederick), fixed references, bibl items, fixed dangling pointers, created eds to do</td></tr><tr><td rowspan="1" colspan="1">20061018</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Editorial fixes for readability, added example for Encrypted parts</td></tr><tr><td rowspan="1" colspan="1">20061030</td><td rowspan="1" colspan="1">UY</td><td rospan="1" colspan="1">Fixes for Paul Cotton's editorial comments (20061020)</td></tr><tr><td rowspan="1" colspan="1">20061031</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Fixes for Frederick's editorial comments (20061025)</td></tr><tr><td rowspan="1" colspan="1">20061031</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Optionality discussion feedback integration</td></tr><tr><td rowspan="1" colspan="1">20061115</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">First attempt at restructuring to include primer content</td></tr><tr><td rowspan="1" colspan="1">20061120</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Restructure to address action items 64,77, which refer to bugzilla 3705 and F2F RESOLUTION 3792 </td></tr><tr><td rowspan="1" colspan="1">20061127</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Updated the list of editors. Added 
 							<a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0033.html">Frederick</a> and 
 							<a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0054.html">Umit</a> to the list of editors.
@@ -1677,7 +1679,7 @@
 							and MS Contribution</a> to 
 							<a href="#interrelated-domains"><b>5.8 Interrelated domains</b></a>. Added an ed note that 
 							Section <a href="#interrelated-domains"><b>5.8 Interrelated domains</b></a> needs to be re-structured.
-						</td></tr><tr><td rowspan="1" colspan="1">20070520</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Added Best Practice <a href="#bp-not-necessary-to-understand-a-message"><b>8. Not Necessary to Understand a Message</b></a> (from
+						</td></tr><tr><td rowspan="1" colspan="1">20070520</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Added Best Practice <a href="#bp-not-necessary-to-understand-a-message"><b>10. Not Necessary to Understand a Message</b></a> (from
 							the <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf">IBM 
 								and MS Contribution</a> to 
 							<a href="#self-describing"><b>5.3.3  Self Describing Messages </b></a>.
@@ -1743,4 +1745,6 @@
 							for issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4852">4852</a>. 
 							Editors' action 
 							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/332">332</a>.
-						</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
+						</td></tr><tr><td rowspan="1" colspan="1">20070717</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Implemented partial resolution, section 5.5 updates, 
+							for issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4662">4662</a>, 							Editors' action 
+							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/332">332</a> #2.</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Received on Tuesday, 17 July 2007 15:49:55 GMT

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