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

2006/ws/policy ws-policy-guidelines.html,1.103,1.104

From: Maryann Hondo via cvs-syncmail <cvsmail@w3.org>
Date: Fri, 21 Sep 2007 22:05:28 +0000
To: public-ws-policy-eds@w3.org
Message-Id: <E1IYqcq-0001W7-5e@lionel-hutz.w3.org>

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

Modified Files:
	ws-policy-guidelines.html 
Log Message:
Implemented the changes proposed by Editors' action 358 issue 5044- attachment best practices

Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.103
retrieving revision 1.104
diff -u -d -r1.103 -r1.104
--- ws-policy-guidelines.html	13 Sep 2007 21:06:27 -0000	1.103
+++ ws-policy-guidelines.html	21 Sep 2007 22:05:26 -0000	1.104
@@ -125,13 +125,14 @@
 &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="#d3e812">Ignorable behavior in authoring</a><br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2 <a href="#d3e825">Ignorable behavior at runtime</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.1 <a href="#d3e822">Ignorable behavior in authoring</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2 <a href="#d3e835">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="#d3e840">Optional behavior at runtime</a><br>
+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.6.1 <a href="#d3e850">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;&nbsp;&nbsp;&nbsp;&nbsp;5.7.3 <a href="#UDDI-attachment-guidelines">Considerations for Policy Attachment in UDDI</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>
@@ -194,9 +195,9 @@
 <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. Define assertions 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. Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>10. 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</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>12. Define message format only</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-leverage-defined-attachment-mechanisms"><b>21. Leverage Defined Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-use-defined-policy-subjects"><b>22. Use Defined Policy Subjects</b></a></p></li><li><p><a href="#bp-identify-policy-subjects"><b>23. Identiy Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>24. Specify WSDL Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>25. Choose the Most Granular WSDL Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>26.  Define Rules for Attachment of an Assertion 
-							type to Multiple WSDL policy subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>27. Specify Preferred WSDL Attachment Point</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. Independent Assertions for Different Versions of a
-           					Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>31. Document changes to policy 
+					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-reusableAssertions"><b>21. Reusable Assertions</b></a></p></li><li><p><a href="#bp-semantics-multiple-same-type"><b>22. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-leverage-defined-attachment-mechanisms"><b>23. Levrage Defined Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-use-defined-policy-subjects"><b>24. Use Defined Policy Subjects</b></a></p></li><li><p><a href="#bp-identify-policy-subjects"><b>25. Identify Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>26. Specify WSDL Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-consider-scope"><b>27. Consider Scope of Attachment Points</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>28. Choose the Most Granular WSDL Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>29.  Define Rules for Attachment of an Assertion 
+							type to Multiple WSDL policy subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>30. Specify Preferred WSDL Attachment Point</b></a></p></li><li><p><a href="#bp-UDDI-tmodels"><b>31. Use defined tModels when appropriate</b></a></p></li><li><p><a href="#bp-specify-composition"><b>32. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>33. Independent Assertions for Different Versions of a
+           					Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>34. Document changes to policy 
 			subject</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
@@ -383,10 +384,10 @@
 					<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>24. Specify WSDL Policy Subject(s)</b></a>).</p></li><li><p>The scope of the assertion in the context of a particular policy 
+							(See best practice <a href="#bp-WSDL-policy-subject"><b>26. Specify WSDL 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>29. Specify Composition with Related Assertions</b></a>).</p></li></ul>
+							(See best practice <a href="#bp-specify-composition"><b>32. 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 
@@ -851,16 +852,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="d3e812" id="d3e812"></a>5.5.1 Ignorable behavior in authoring</h4><p>  
+<h4><a name="d3e822" id="d3e822"></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 compatibility 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. Document Ignorable Behavior</b></a> and <a href="#ignorableAssertions"><b>10. 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="d3e825" id="d3e825"></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="d3e835" id="d3e835"></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="d3e840" id="d3e840"></a>5.6.1 Optional behavior at runtime</h4><p>Since optional behaviors indicate optionality for
+<h4><a name="d3e850" id="d3e850"></a>5.6.1 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
@@ -946,34 +947,52 @@
 						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: Leverage Defined Attachment Mechanisms</span></p><p class="practice">
-							Assertion Authors should leverage defined attachment mechanisms 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: Use Defined Policy Subjects</span></p><p class="practice"> Assertion
-							Authors should leverage defined policy subjects when possible to
+						unknown) attachment mechanisms in mind. Since multiple attachment mechanisms
+						may be used, a policy alternative created during the process of calculating
+						an effective policy can contain multiple instances of the same policy 
+						assertion type ( i.e., the SignedParts assertion). It is therefore also
+						important for the policy authors to define what it means if multiple
+						assertions are present. 
+					</p><div class="boxedtext"><p><a name="bp-reusableAssertions" id="bp-reusableAssertions"></a><span class="practicelab">Best
+Practice 21: Reusable Assertions</span></p><p class="practice">
+							Assertion Authors are encouraged to create policy assertions that
+							can be used regardless of attachment mechanism.</p></div><p>For example, a security policy expression can be assigned a key reference and
+					be attached to a UDDI binding or can be embedded in a WSDL document. </p><div class="boxedtext"><p><a name="bp-semantics-multiple-same-type" id="bp-semantics-multiple-same-type"></a><span class="practicelab">Best
+Practice 22: Describe Semantics of Multiple Assertions of Same Type</span></p><p class="practice">
+							Assertion Authors should specify the semantics of multiple instances
+							of the 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 regardless of the mechanism used to attach them to
+							a policy subject. If there are multiple instances of a policy
+							assertion type in the same policy alternative without parameters
+							and nested policies, these have the same meaning as a single
+							assertion of the type within the policy alternative.</p></div><p> Assertion authors should review sections 3.2 and 4.5 of the Policy Framework
+					<cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> for more detail
+					on the processing for multiple assertions of the same type.</p><div class="boxedtext"><p><a name="bp-leverage-defined-attachment-mechanisms" id="bp-leverage-defined-attachment-mechanisms"></a><span class="practicelab">Best
+Practice 23: Leverage Defined Attachment Mechanisms</span></p><p class="practice">
+							Assertion Authors should leverage defined attachment models when
+							possible to document the use of the policy assertions they author and ensure
+							that there are no additional semantics implied by  the defined 
+							attachment models for their assertions.</p></div><div class="boxedtext"><p><a name="bp-use-defined-policy-subjects" id="bp-use-defined-policy-subjects"></a><span class="practicelab">Best
+Practice 24: Use Defined Policy Subjects</span></p><p class="practice"> Assertion
+							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>
+							easier to define and group. </p></div><div class="boxedtext"><p><a name="bp-identify-policy-subjects" id="bp-identify-policy-subjects"></a><span class="practicelab">Best
+Practice 25: Identify Policy Subjects</span></p><p class="practice">
 						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: Identify Policy Subjects</span></p><p class="practice">
-							Assertion
-							Authors should review the policy subjects defined in
-							Web Services Policy 1.5 - Attachment 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 policy subject level that might impact interoperability.</p></div><p>
+					Assertion Authors should review the policy subjects defined in WS-PolicyAttachments
+					and identify which of the existing policy subjects can be used with the assertions
+					they define. That identification will facilitate the deployment of their policy
+					assertions and include such information in the assertion definition.
+					</p><p> An example of this practice is
 						the Reliable Messaging Policy Assertion document [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy Assertion</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
@@ -999,23 +1018,24 @@
           				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 WSDL 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 24: Specify WSDL Policy Subject(s)</span></p><p class="practice">Assertion Authors should specify the set of relevant WSDL policy subjects with which 
+Practice 26: Specify WSDL Policy Subject(s)</span></p><p class="practice">Assertion Authors should specify the set of relevant WSDL 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.
-					</p></div><p>Assertion Authors that wish to utilize WSDL policy subjects need to 
+					    a WSDL policy subject - such as service, endpoint, operation and message it should be stated.
+					</p></div><p>Assertion Authors that utilize WSDL policy subjects need to 
 				understand how the assertions will be
-				processed in an intersection and merging, and the implications of
-				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>
+				processed in intersection and merging, and the specific implications of
+				the processing for 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><p> For a given WSDL policy subject, there may be several
         		attachment points. For example, there are three attachment
         		points for the endpoint policy subject: the port, binding and
         		portType element. Assertion Authors should identify the
-        		relevant attachment point when defining a new assertion. To
-        		determine the relevant attachment points, Assertion Authors should
-        		consider the scope of the attachment point. For example, an
-        		assertion should only be allowed in the portType element if
+        		relevant attachment point when defining a new assertion. 
+        		</p><div class="boxedtext"><p><a name="bp-WSDL-consider-scope" id="bp-WSDL-consider-scope"></a><span class="practicelab">Best
+Practice 27: Consider Scope of Attachment Points</span></p><p class="practice">To determine the relevant attachment points, Assertion Authors should
+        		consider the scope of the attachment point.
+					</p></div><p>
+        		For example, an assertion should only be allowed in the portType element if
         		the assertion reasonably applies to any endpoint that ever
         		references that portType. Most of the known policy assertions
         		are designed for the endpoint, operation or message policy subject. 
@@ -1032,7 +1052,7 @@
         		policy attachments to WSDL 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 25: Choose the Most Granular WSDL Policy Subject</span></p><p class="practice">Assertion Authors should choose the most granular WSDL policy subject
+Practice 28: Choose the Most Granular WSDL Policy Subject</span></p><p class="practice">Assertion Authors should choose the most granular WSDL policy subject
 						to which the behavior represented by a policy assertion applies.
 					</p></div><p>
         		For authoring convenience, Assertion Authors may allow the
@@ -1043,7 +1063,7 @@
         		when multiple instances of the same assertion are attached to different 
         		WSDL policy subjects in order to avoid non-interoperable 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 26:  Define Rules for Attachment of an Assertion 
+Practice 29:  Define Rules for Attachment of an Assertion 
 							type to Multiple WSDL policy subjects</span></p><p class="practice">If an assertion is allowed to be associated with multiple WSDL policy subjects, 
 							the assertion author should describe the rules for multiple 
 							instances of the same assertion attached to multiple WSDL policy subjects in 
@@ -1071,13 +1091,13 @@
 				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 27: Specify Preferred WSDL Attachment Point</span></p><p class="practice">If an assertion can be attached at multiple attachment points 
+Practice 30: Specify Preferred WSDL Attachment Point</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 
 				understand how the assertions will be processed in merging and 
-				the specify implications of ending up with multiple assertions of 
-				the same kind in an alternative, in the merged policy. For example, 
+				the specific implications of a result where multiple assertions of 
+				the assertion type are in an alternative, in the merged policy. For example, 
 				consider the SignedParts assertion defined in WS-SecurityPolicy 1.2.
 				The definition of SignedParts assertion explicitly permits multiple 
 				SignedParts assertions to be present within a policy alternative, 
@@ -1089,20 +1109,31 @@
 				at the endpoint could have more than one SignedParts assertion in the
 				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 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><div class="div2">
+			   </p></div><div class="div3">
+<h4><a name="UDDI-attachment-guidelines" id="UDDI-attachment-guidelines"></a>5.7.3 Considerations for Policy Attachment in UDDI</h4><p>In general, UDDI protocol messages can be used to save TModel, businessEntity, 
+				businessService and bindingTemplate definitions with policies attached. These
+				definitions can also be the target of a "find" protocol message, thus allowing
+				authors to store and retrieve policy assertions. There are two ways to associate
+				policy expressions with UDDI definitions: direct referece, and registering policy 
+				as a UDDI TModel. Assertion Authors defining new assertions should consider each 
+				approach.
+        		</p><div class="boxedtext"><p><a name="bp-UDDI-tmodels" id="bp-UDDI-tmodels"></a><span class="practicelab">Best
+Practice 31: Use defined tModels when appropriate</span></p><p class="practice">UDDI defines the following policy subjects: Service Provider Policy,
+					Service Policy subject and Endpoint Policy subject.
+					</p></div><p>
+					When defining assertions and recommending a service provider policy
+					subject [uddi:BusinessEntity], or a service policy subject [uddi:buisnessService],
+					assertion authors are scoping the behaviors to the service 
+					provider as a whole. When defining assertions and recommending an endpoint
+					policy subject [uddi:bindingTemplate, uddi:tModel], assertion authors
+					are scoping behaviors to a deployed endpoint.
+				</p></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 29: Specify Composition with Related Assertions</span></p><p class="practice">Assertion authors should clearly specify how an assertion 
+Practice 32: 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
@@ -1145,7 +1176,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 30: Independent Assertions for Different Versions of a
+Practice 33: 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
@@ -1159,7 +1190,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>24. Specify WSDL Policy Subject(s)</b></a> specifies that policy authors should 
+				The best practice <a href="#bp-WSDL-policy-subject"><b>26. Specify WSDL 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 
@@ -1175,7 +1206,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 31: Document changes to policy 
+Practice 34: Document changes to policy 
 			subject</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">
@@ -1524,7 +1555,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>29. 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>32. 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 
@@ -1652,4 +1683,7 @@
 							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/353">353</a>
 							with the caveats and clarifications expressed in message
 							<a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2007Sep/0002.html">2007Sep-0002</a>.
+						</td></tr><tr><td rowspan="1" colspan="1">20070921</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Implemented the resolution for issue 
+							<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5044">5044</a>. Editors' action 
+							<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/358">358</a>.
 						</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Received on Friday, 21 September 2007 22:05:58 GMT

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