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

2006/ws/policy ws-policy-guidelines.html,1.89,1.90 ws-policy-guidelines.xml,1.104,1.105

From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 18 Jul 2007 23:02:30 +0000
To: public-ws-policy-eds@w3.org
Message-Id: <E1IBIXO-0007ZU-EX@lionel-hutz.w3.org>

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

Modified Files:
	ws-policy-guidelines.html ws-policy-guidelines.xml 
Log Message:
Implemented the resolution for issue 4654. Editors' action 340. Add new section general-attachment-guidelines.

Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.89
retrieving revision 1.90
diff -u -d -r1.89 -r1.90
--- ws-policy-guidelines.html	18 Jul 2007 22:44:03 -0000	1.89
+++ ws-policy-guidelines.html	18 Jul 2007 23:02:27 -0000	1.90
@@ -136,11 +136,13 @@
 &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="#d3e797">Ignorable behavior in authoring</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2 <a href="#d3e810">Ignorable behavior at runtime</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.1 <a href="#d3e806">Ignorable behavior in authoring</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2 <a href="#d3e819">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="#d3e825">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;&nbsp;&nbsp;&nbsp;&nbsp;5.6.1 <a href="#d3e834">Optional behavior at runtime</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;5.7 <a href="#levels-of-abstraction">Considerations for Policy Attachment</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.7.1 <a href="#general-attachment-guidelines">General Guidelines</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.7.2 <a href="#wsdl-attachment-guidelines">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>
@@ -204,7 +206,9 @@
 				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-ignorable-for-not-related-to-compatibility-tests"><b>3. Mark Ignorable Assertions not related to compatibility</b></a></p></li><li><p><a href="#bp-semantics-and-form"><b>4. Semantics Independent of the Form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>5. Start with a Simple Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>6. Use Unique QNames</b></a></p></li><li><p><a href="#XMLOutline"><b>7. Provide an XML definition</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>8. Specify Semantics Clearly</b></a></p></li><li><p><a href="#DefineIgnorable"><b>9. Assertion Authors Should Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>10. Assertion Authors Should Document Use of the Ignorable 
 Attribute in XML </b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>11. Assertion Authors should allow use of wsp:Optional 
 attribute</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>12. Not Necessary to Understand a Message</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>13. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>14. Use Parameters for Useful 
-					Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>15. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>16. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>17. Discourage Domain Specific Intersection</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 f 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">
+					Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>15. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>16. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>17. Discourage Domain Specific Intersection</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-leverage-defined-attachment-mechanisms"><b>21. Assertion
+						Authors Should Leverage Defined Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-use-defined-policy-subjects"><b>22. Assertion
+						Authors Should Use Defined Policy Subjects</b></a></p></li><li><p><a href="#bp-identify-policy-subjects"><b>23. Assertion Authors should Identify Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>24. Specify Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>25. Choose the Most Granular Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>26. Define Semantics of Attachment to Multiple Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>27. Specify Preferred Attachment Point for an Assertion</b></a></p></li><li><p><a href="#bp-WSDL-policy-multiple-instance-semantics"><b>28. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-specify-composition"><b>29. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>30. Use Independent Assertions for Different Versions of a Behavior</b></a><p></li><li><p><a href="#bp-policy-subject-change"><b>31. 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
@@ -390,14 +394,14 @@
 					<ul><li><p>The definition of the assertion's semantic 
 							(See best practice <a href="#AssertionDefinitions"><b>8. Specify Semantics Clearly</b></a>).</p></li><li><p>The specification of the set of valid policy subjects to which an 
 							assertion may be attached
-							(See best practice <a href="#bp-WSDL-policy-subject"><b>21. Specify Policy Subject(s)</b></a>).</p></li><li><p>The scope of the assertion in the context of a particular policy 
-							subject (See best practices in Section <a href="#levels-of-abstraction"><b>5.7 Considerations for Policy Attachment in WSDL </b></a>).</p></li><li><p>Any composition considerations if the assertion is used with
+							(See best practice <a href="#bp-WSDL-policy-subject"><b>24. Specify Policy Subject(s)</b></a>).</p></li><li><p>The scope of the assertion in the context of a particular policy 
+							subject (See best practices in Section <a href="#levels-of-abstraction"><b>5.7 Considerations for Policy Attachment</b></a>).</p></li><li><p>Any composition considerations if the assertion is used with
 						other assertions in a context
-							(See best practice <a href="#bp-specify-composition"><b>26. Specify Composition with Related Assertions</b></a>).</p></li></ul>
+							(See best practice <a href="#bp-specify-composition"><b>29. Specify Composition with Related Assertions</b></a>).</p></li></ul>
 				</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.7 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</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.
@@ -856,16 +860,16 @@
 						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><div class="div3">
-<h4><a name="d3e797" id="d3e797"></a>5.5.1 Ignorable behavior in authoring</h4><p>  
+<h4><a name="d3e806" id="d3e806"></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>9. Assertion Authors Should Document Ignorable Behavior</b></a> and <a href="#ignorableAssertions"><b>10. 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="d3e810" id="d3e810"></a>5.5.2 Ignorable behavior at runtime</h4><p>Regardless of whether the assertion allows the ignorable attribute, assertion authors should
+<h4><a name="d3e819" id="d3e819"></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="d3e825" id="d3e825"></a>5.6.1 Optional behavior at runtime</h4><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">This section does not have Working Group consensus and there is an outstanding action item to revise it</td></tr></table><p>Since optional behaviors indicate optionality for
+<h4><a name="d3e834" id="d3e834"></a>5.6.1 Optional behavior at runtime</h4><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">This section does not have Working Group consensus and there is an outstanding action item to revise it</td></tr></table><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
@@ -945,7 +949,57 @@
 					exchange when optionally used in part of that exchange  
 					(<a href="#bp-entire-mep-for-optional">Best Practice: Consider entire message exchange pattern when specifying Assertions that may be optional</a>).
 				</p></div></div><div class="div2">
-<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
+<h3><a name="levels-of-abstraction" id="levels-of-abstraction"></a>5.7 Considerations for Policy Attachment</h3><div class="div3">
+<h4><a name="general-attachment-guidelines" id="general-attachment-guidelines"></a>5.7.1 General Guidelines</h4><p>
+						The Policy attachment mechanism used to
+						communicate the policy assertions should not affect or imply additional
+						semantics in the interpretation of Policy alternatives. If it did, each
+						policy assertion would need to be written with different (and possibly
+						unknown) attachment mechanisms in mind.
+					</p><div class="boxedtext"><p><a name="bp-leverage-defined-attachment-mechanisms" id="bp-leverage-defined-attachment-mechanisms"></a><span class="practicelab">Best
+Practice 21: Assertion
+						Authors Should Leverage Defined Attachment Mechanisms</span></p><p class="practice">
+							Assertion Authors should leverage defined attachment models when
+							possible to extend the deployment of their policy assertions and ensure
+							that there are no additional semantics implied by their
+							assertions.</p></div><p>Assertion authors are also encouraged to use the policy subjects defined by the policy attachments 
+						specification when possible. </p><div class="boxedtext"><p><a name="bp-use-defined-policy-subjects" id="bp-use-defined-policy-subjects"></a><span class="practicelab">Best
+Practice 22: Assertion
+						Authors Should Use Defined Policy Subjects</span></p><p class="practice"> Assertion
+							Authors should leverage defined policy subjects when possible to
+							facilitate the deployment of their policy assertions. Common Policy
+							subjects have been defined and used by other policy assertion authors
+							and new policy assertions that leverage these existing subjects will be
+							easier to define and group. </p></div><p>
+						Policy assertion authors
+						should unambiguously identify the appropriate policy subjects for their
+						assertions. If the best practices are followed, and the assertions are
+						scoped according to their subject, then multiple policy domains may be
+						combined without conflict. Each domain should define any limitations at
+						the policy subject level that might impact interoperability. 
+					</p><div class="boxedtext"><p><a name="bp-identify-policy-subjects" id="bp-identify-policy-subjects"></a><span class="practicelab">Best
+Practice 23: Assertion Authors should Identify Policy Subjects</span></p><p class="practice">
+							Assertion
+							Authors should review the policy subjects defined in
+							WS-PolicyAttachments and identify existing policy subjects when possible
+							to facilitate the deployment of their policy assertions and include this
+							information in the definition of the assertions.</p></div><p>
+						An example of this is
+						the Reliable Messaging Policy Assertion document [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite>]. In the Sequence STR Assertion (section
+						2.5.1) the Reliable Messaging Policy Assertion authors state that "The
+						STR assertion defines the requirement that an RM Sequence MUST be bound
+						to an explicit token that is referenced from a
+						<code>wsse:SecurityTokenReference</code> in the CreateSequence message.
+						This assertion MUST apply to [Endpoint Policy Subject]. This assertion
+						MUST NOT be used for an endpoint that does not also use the RM
+						assertion". This is illustrative of how the domain assertion author can
+						specify additional constraints and assumptions for attachment and
+						engagement of behavior in addition to the capabilities specified in
+						WS-PolicyAttachment [<cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>]. Such
+						additional constraints must be clearly specified by the assertion
+						authors. 
+					</p></div><div class="div3">
+<h4><a name="wsdl-attachment-guidelines" id="wsdl-attachment-guidelines"></a>5.7.2 Considerations for Policy Attachment in WSDL</h4><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 should specify a WSDL
         		policy subject. 
@@ -956,7 +1010,7 @@
           				made using an endpoint then the subject is the endpoint policy subject. </p></li><li><p>If the behavior applies to any message exchange
 	  					defined by an operation then the subject is the operation policy subject. </p></li><li><p>If the behavior applies to an input message then
 	  					the subject is the message policy subject - similarly for output and fault message policy subjects.</p></li></ul><div class="boxedtext"><p><a name="bp-WSDL-policy-subject" id="bp-WSDL-policy-subject"></a><span class="practicelab">Best
-Practice 21: Specify Policy Subject(s)</span></p><p class="practice">Assertion Authors should specify the set of relevant policy subjects with which 
+Practice 24: Specify Policy Subject(s)</span></p><p class="practice">Assertion Authors should specify the set of relevant policy subjects with which 
 					    the assertion may be associated. 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.
@@ -989,7 +1043,7 @@
         		policy attachments to policy subjects of broader scope and granularity 
         		should be done only after careful evaluation. 
         		</p><div class="boxedtext"><p><a name="bp-WSDL-policy-subject-Granularity" id="bp-WSDL-policy-subject-Granularity"></a><span class="practicelab">Best
-Practice 22: Choose the Most Granular Policy Subject</span></p><p class="practice">Assertion Authors should choose the most granular policy subject
+Practice 25: Choose the Most Granular Policy Subject</span></p><p class="practice">Assertion Authors should choose the most granular policy subject
 						to which the behavior represented by a policy assertion applies.
 					</p></div><p>
         		For authoring convenience, Assertion Authors may allow the
@@ -1000,7 +1054,7 @@
         		same assertion attached to different policy subjects at the same
         		time in order to avoid conflicting behavior.
 				</p><div class="boxedtext"><p><a name="bp-WSDL-multiple-policy-subjects" id="bp-WSDL-multiple-policy-subjects"></a><span class="practicelab">Best
-Practice 23: Define Semantics of Attachment to Multiple Policy Subjects</span></p><p class="practice">If an assertion is allowed to be associated with multiple policy subjects, 
+Practice 26: Define Semantics of Attachment to Multiple Policy Subjects</span></p><p class="practice">If an assertion is allowed to be associated with multiple policy subjects, 
 					the assertion author should describe the semantics of multiple instances of 
 					the same assertion attached to multiple policy subjects at the same time. 
 					</p></div><p>If the capability is not really suitable and may imply
@@ -1021,7 +1075,7 @@
 				when the policy assertions do not target wire-level behaviors but
 				rather abstract requirements, this technique does not apply. 
 				</p><div class="boxedtext"><p><a name="bp-WSDL-preferred-attachment-point" id="bp-WSDL-preferred-attachment-point"></a><span class="practicelab">Best
-Practice 24: Specify Preferred Attachment Point for an Assertion</span></p><p class="practice">If an assertion can be attached at multiple attachment points 
+Practice 27: Specify Preferred Attachment Point for an Assertion</span></p><p class="practice">If an assertion can be attached at multiple attachment points 
 					    within a policy subject, Assertion Authors should specify a 
 					    preferred attachment point for the chosen policy subject.
 					</p></div><p>Assertion Authors that utilize WSDL policy subjects need to 
@@ -1040,19 +1094,19 @@
 				same alternative. However, the clear semantics defined by the SignedParts 
 				assertion enable processing of the multiple occurrences properly.	
 			   </p><div class="boxedtext"><p><a name="bp-WSDL-policy-multiple-instance-semantics" id="bp-WSDL-policy-multiple-instance-semantics"></a><span class="practicelab">Best
-Practice 25: Describe Semantics of Multiple Assertions of Same Type</span></p><p class="practice">A policy alternative can contain multiple instances of the same 
+Practice 28: Describe Semantics of Multiple Assertions of Same Type</span></p><p class="practice">A policy alternative can contain multiple instances of the same 
 					policy assertion type. Assertion authors should specify the semantics of 
 					multiple instances of same policy assertion type in the same policy 
 					alternative and the semantics of parameters and nested policy (if any) 
 					when there are multiple instances of a policy assertion type in the same 
 					policy alternative.
-					</p></div></div><div class="div2">
+					</p></div></div></div><div class="div2">
 <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. Assertion Authors should not duplicate existing  
 				assertions and should also make sure that when adding assertions those new assertions are consistent  
 				with pre-existing assertions of any  
 				interrelated domain. </p><div class="boxedtext"><p><a name="bp-specify-composition" id="bp-specify-composition"></a><span class="practicelab">Best
-Practice 26: Specify Composition with Related Assertions</span></p><p class="practice">Assertion authors should clearly specify how an assertion 
+Practice 29: Specify Composition with Related Assertions</span></p><p class="practice">Assertion authors should clearly specify how an assertion 
 				may compose with other related assertions, if any.</p></div><p> A  
 				classic example of such an interrelated domain is security, because  
 				security tends to
@@ -1095,7 +1149,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">Best
-Practice 27: Use Independent Assertions for Different Versions of a Behavior</span></p><p class="practice">Assertion Authors should use independent assertions for modeling different 
+Practice 30: Use Independent Assertions for Different Versions of a Behavior</span></p><p class="practice">Assertion Authors should use independent assertions for modeling different 
            			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">
@@ -1108,7 +1162,7 @@
   &lt;sp:Wss11&gt;…&lt;/sp:Wss11&gt;
 &lt;/Policy&gt;</pre></div></div></div><div class="div2">
 <h3><a name="supporting-new-policy-subjects" id="supporting-new-policy-subjects"></a>6.3 Supporting New Policy Subjects</h3><p>
-				The best practice <a href="#bp-WSDL-policy-subject"><b>21. Specify Policy Subject(s)</b></a> specifies that policy authors should 
+				The best practice <a href="#bp-WSDL-policy-subject"><b>24. Specify Policy Subject(s)</b></a> specifies that policy authors should 
 				define the set of policy subjects to which policy assertions can be 
 				attached.  Over time, new policy subjects may need to be defined.  When 
 				this occurs, policy Assertion Authors may update the list of policy 
@@ -1124,7 +1178,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">Best
-Practice 28: Change of the Policy Subject Over Time</span></p><p class="practice">If the policy subjects change over time, 
+Practice 31: 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><div class="back"><div class="div1">
 <h2><a name="security-considerations" id="security-considerations"></a>A. Security Considerations</h2><p> Security considerations are discussed in the <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> document.</p></div><div class="div1">
@@ -1469,7 +1523,7 @@
 						    are reflected. 
 						</td></tr><tr><td rowspan="1" colspan="1">20070518</td><td rowspan="1" colspan="1">PY</td><td rowspan="1" colspan="1">Updated Appendix E, Changes in this Version of the Document
 							(<a href="#change-description"><b>E. Changes in this Version of the Document</b></a>). 
-						</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-specify-composition"><b>26. Specify Composition with Related Assertions</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-specify-composition"><b>29. Specify Composition with Related Assertions</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="#interrelated-domains"><b>5.8 Interrelated domains</b></a>. Added an ed note that 
@@ -1564,4 +1618,9 @@
 							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/249">249</a>, 	<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/328">328</a>. </td></tr><tr><td rowspan="1" colspan="1">20070718</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=4862">4862</a>. 
 							Editors' action: 
-							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/348">348</a>. </td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
+							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/348">348</a>. </td></tr><tr><td rowspan="1" colspan="1">20070718</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=4654">4654</a>. 
+							Editors' action: 
+							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/340">340</a>.
+							Add new section <a href="#general-attachment-guidelines"><b>5.7.1 General Guidelines</b></a>.
+						</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file

Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.104
retrieving revision 1.105
diff -u -d -r1.104 -r1.105
--- ws-policy-guidelines.xml	18 Jul 2007 22:44:03 -0000	1.104
+++ ws-policy-guidelines.xml	18 Jul 2007 23:02:27 -0000	1.105
@@ -1225,7 +1225,68 @@
 		
 			
 			<div2 id="levels-of-abstraction">
-				<head>Considerations for Policy Attachment in WSDL </head>
+				<head>Considerations for Policy Attachment</head>
+				<div3 id="general-attachment-guidelines">
+					<head>General Guidelines</head>
+					<p>
+						The Policy attachment mechanism used to
+						communicate the policy assertions should not affect or imply additional
+						semantics in the interpretation of Policy alternatives. If it did, each
+						policy assertion would need to be written with different (and possibly
+						unknown) attachment mechanisms in mind.
+					</p>
+					
+					<p role="practice" id="bp-leverage-defined-attachment-mechanisms"><quote>Assertion
+						Authors Should Leverage Defined Attachment Mechanisms</quote><quote>
+							Assertion Authors should leverage defined attachment models when
+							possible to extend the deployment of their policy assertions and ensure
+							that there are no additional semantics implied by their
+							assertions.</quote> </p> 
+					<p>Assertion authors are also encouraged to use the policy subjects defined by the policy attachments 
+						specification when possible. </p>
+					
+					<p role="practice" id="bp-use-defined-policy-subjects"><quote>Assertion
+						Authors Should Use Defined Policy Subjects</quote><quote> Assertion
+							Authors should leverage defined policy subjects when possible to
+							facilitate the deployment of their policy assertions. Common Policy
+							subjects have been defined and used by other policy assertion authors
+							and new policy assertions that leverage these existing subjects will be
+							easier to define and group. </quote> </p> 
+					<p>
+						Policy assertion authors
+						should unambiguously identify the appropriate policy subjects for their
+						assertions. If the best practices are followed, and the assertions are
+						scoped according to their subject, then multiple policy domains may be
+						combined without conflict. Each domain should define any limitations at
+						the policy subject level that might impact interoperability. 
+					</p>
+					<p role="practice" id="bp-identify-policy-subjects">
+						<quote>Assertion Authors should Identify Policy Subjects</quote><quote>
+							Assertion
+							Authors should review the policy subjects defined in
+							WS-PolicyAttachments and identify existing policy subjects when possible
+							to facilitate the deployment of their policy assertions and include this
+							information in the definition of the assertions.</quote> </p> 
+					<p>
+						An example of this is
+						the Reliable Messaging Policy Assertion document [<bibref
+							ref="WS-RM-Policy "/>]. In the Sequence STR Assertion (section
+						2.5.1) the Reliable Messaging Policy Assertion authors state that "The
+						STR assertion defines the requirement that an RM Sequence MUST be bound
+						to an explicit token that is referenced from a
+						<code>wsse:SecurityTokenReference</code> in the CreateSequence message.
+						This assertion MUST apply to [Endpoint Policy Subject]. This assertion
+						MUST NOT be used for an endpoint that does not also use the RM
+						assertion". This is illustrative of how the domain assertion author can
+						specify additional constraints and assumptions for attachment and
+						engagement of behavior in addition to the capabilities specified in
+						WS-PolicyAttachment [<bibref ref="WS-PolicyAttachment "/>]. Such
+						additional constraints must be clearly specified by the assertion
+						authors. 
+					</p>
+				</div3>
+				<div3 id="wsdl-attachment-guidelines">
+					<head>Considerations for Policy Attachment in WSDL</head>
 				<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 should specify a WSDL
@@ -1385,7 +1446,7 @@
 					policy alternative.
 					</quote>
 				</p>
-				
+			</div3>	
 			</div2>
 		<div2 id="interrelated-domains">
 			<head>Interrelated domains</head>	
@@ -2546,7 +2607,18 @@
 							for issue <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4862">4862</loc>. 
 							Editors' action: 
 							<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/348">348</loc>. </td>
-					</tr>                 		              	                  		              			 
+					</tr>    
+					<tr>
+						<td>20070718</td>
+						<td>FJH</td>
+						<td>Implemented the resolution for issue 
+							<loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4654">4654</loc>. 
+							Editors' action: 
+							<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/340">340</loc>.
+							Add new section <specref ref="general-attachment-guidelines" />.
+						</td>
+					</tr> 
+					
 				</tbody>
 			</table>
 		</inform-div1>
Received on Wednesday, 18 July 2007 23:02:33 GMT

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