W3C home > Mailing lists > Public > public-ws-policy-eds@w3.org > November 2006

2006/ws/policy ws-policy-guidelines.html,1.6,1.7

From: Umit Yalsinap via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 01 Nov 2006 02:32:19 +0000
To: public-ws-policy-eds@w3.org
Message-Id: <E1Gf5tr-0004zV-24@lionel-hutz.w3.org>

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

Modified Files:
	ws-policy-guidelines.html 
Log Message:
Optional behaviors take 2

Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- ws-policy-guidelines.html	1 Nov 2006 01:18:39 -0000	1.6
+++ ws-policy-guidelines.html	1 Nov 2006 02:32:16 -0000	1.7
@@ -63,7 +63,7 @@
         guide to using the specifications. </p></div><div>
 <h2><a name="status">Status of this Document</a></h2><p><strong>This document is an editors' copy that has
         no official standing.</strong></p><p></p></div><hr><div class="toc">
-<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#introduction">Introduction</a><br>2. <a href="#Assertions">Basic Concepts: What is an Assertion</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#assertion-roles">Roles and Responsibilities in Utilizing Policy Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.1 <a href="#domain-owners"> WS-Policy Authors</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.2 <a href="#consumers">Consumers</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.3 <a href="#providers">Providers</a><br>3. <a href="#general-guidelines">General Guidelines for WS-Policy Assertion Authors</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#assertion-target">Assertions and Their Target Use</a><br>4. <a href="#compact-full">Authoring Styles </a><br>5. <a href="#modeling-guidelines">Guidelines for Modeling New Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.1 <a href="#new-domains">New Policy Domains</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.2 <a href="single-domains">Single Domains</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.3 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.3.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.3.2 <a href="#nested-assertions">Nested Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.3.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.4 <a href="#self-describing"> Self Describing Messages </a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.5 <a href="#optional-policy-assertion">Optional Policy Assertion</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.6 <a href="#considerations-for-intersection"> Considerations for Intersection and Merging </a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.7 <a href="#typing-assertions">Typing Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.8 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>&nbsp;&nbsp;&nsp;&nbsp;5.9 <a href="#lifecycle">Lifecycle of Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.9.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.9.2 <a href="#extending-assertions"> Factors in Extending Assertions within a Domain </a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.9.3 <a href="#assertion-evolution">Evolution of Assertions (Versioning and Compatibility)</a><br>6. <a href="#inter-policy">Inter-domain Policy and Composition Issues</a><br>7. <a href="#best-practices-attachment">Applying Best Practices for  Policy Attachment</a><br>&nbsp;&nbsp;&nbsp;&nbsp;7.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br>&nbsp;&nbsp;&nbsp;&nbsp;7.2 <a href="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.2.1 <a href="#interaction">Interaction betwen Subjects</a><br>&nbsp;&nbsp;&nbsp;&nbsp;7.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>8. <a href="#scenerio">Scenario and a worked example</a><br></p>
+<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#introduction">Introduction</a><br>2. <a href="#Assertions">Basic Concepts: What is an Assertion</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#assertion-roles">Roles and Responsibilities in Utilizing Policy Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.1 <a href="#domain-owners"> WS-Policy Authors</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.2 <a href="#consumers">Consumers</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.3 <a href="#providers">Providers</a><br>3. <a href="#general-guidelines">General Guidelines for WS-Policy Assertion Authors</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#assertion-target">Assertions and Their Target Use</a><br>4. <a href="#compact-full">Authoring Styles </a><br>5. <a href="#modeling-guidelines">Guidelines for Modeling New Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.1 <a href="#new-domains">New Policy Domains</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.2 <a href="single-domains">Single Domains</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.3 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.3.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.3.2 <a href="#nested-assertions">Nested Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.3.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.4 <a href="#self-describing"> Self Describing Messages </a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.5 <a href="#optional-policy-assertion">Policy Assertions Designating Optional Behaviors</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.6 <a href="#considerations-for-intersection"> Considerations for Intersection and Merging </a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.7 <a href="#typing-assertions">Typing Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.8 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.9 <a href="#lifecycle">Lifecycle of Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.9.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.9.2 <a href="#extending-assertions"> Factors in Extending Assertions within a Domain </a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.9.3 <a href="#assertion-evolution">Evolution of Assertions (Versioning and Compatibility)</a><br>6. <a href="#inter-policy">Inter-domain Policy and Composition Issues</a><br>7. <a href="#best-practices-attachment">Applying Best Practices for  Policy Attachment</a><br>&nbsp;&nbsp;&nbsp;&nbsp;7.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br>&nbsp;&nbsp;&nbsp;&nbsp;7.2 <a href="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.2.1 <a href="#interacion">Interaction between Subjects</a><br>&nbsp;&nbsp;&nbsp;&nbsp;7.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>8. <a href="#scenerio">Scenario and a worked example</a><br></p>
 <h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#security-considerations">Security Considerations</a><br>B. <a href="#xml-namespaces">XML Namespaces</a><br>C. <a href="#references">References</a><br>D. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>E. <a href="#change-description">Changes in this Version of
           the Document</a> (Non-Normative)<br>F. <a href="#change-log">Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log</a> (Non-Normative)<br></p></div><hr><div class="body"><div class="div1">
 <h2><a name="introduction"></a>1. Introduction</h2><p>WS-Policy specification defines a policy to be a collection
@@ -572,17 +572,17 @@
     behavior that is expressed by a policy assertion. This approach
     can be considered when messages can not be self describing. 
      </p></div><div class="div2">
-<h3><a name="optional-policy-assertion"></a>5.5 Optional Policy Assertion</h3><p>Optional assertions represent behaviors which may be
-        engaged by a consumer. When using the compact authoring form
-        for assertions, behaviors are marked by using
-        <code>wsp:optional</code> attribute that has a value,
+<h3><a name="optional-policy-assertion"></a>5.5 Policy Assertions Designating Optional Behaviors</h3><p>Optional behaviors represent
+        behaviors which may be engaged by a consumer. When using the
+        compact authoring form for assertions, behaviors are marked by
+        using <code>wsp:optional</code> attribute that has a value,
         "true". During the process of normalization, the runtime
-        behavior is indicated by two policy alternatives, one with
-        and one without containing the assertion. In a
-        consumer/provider scenario, the choice of engaging the runtime
-        behavior is upon the consumer although the provider is
-        capable of engaging the runtime behavior.
-	</p><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an
+        behavior is indicated by two policy alternatives, one with and
+        one without containing the assertion. In a consumer/provider
+        scenario, the choice of engaging the runtime behavior is upon
+        the consumer although the provider is capable of engaging the
+        runtime behavior. In order to simplify reference to such
+        assertions, we just use the term optional assertions in this section. </p><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an
         example that proposes the use of <cite><a href="#MTOM">MTOM</a></cite> as an
         optional behavior that can be engaged by a consumer. The
         primer proposes that an assertion that identifies the use of
@@ -602,7 +602,7 @@
         the provider can determine whether the policy alternate that
         contains the MTOM assertion is being selected.</p><p>Assertion authors should be aware that optional behaviors,
           like utilizing optional support for Optimized MIME
-          Serialization require some care. </p><ul><li><p>Since optional behaviors indicate optionality for
+          Serialization require some care considering the scoping of the assertion that is applicable. </p><ul><li><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 presence of two
@@ -610,45 +610,61 @@
           choose the alternative that does not contain the assertion,
           and thus making the behavior not being engaged in an
           interaction.
-          </p></li><li><p>As demonstrated in the MIME optimization behavior,
-          behaviors must be engaged with respect to messages that are
-          targeted to the provider so that the provider can determine
-          that the optional behavior is engaged. In other words, the
-          requirement of self describing nature of messages in order
-          to engage behaviors must not be forgotten with regard to
-          the client's ability to detect and select the alternative if
-          it is to participate in the exchange. It is recommended that
-          authors not utilize optional assertions for outbound
-          messages unless there is explicit, out of band mechanism
-          (currently such a mechanism is outside the scope of
-          WS-Policy Framework) that a client can use to indicate that
-          the optional capability must be engaged. </p></li><li><p>When optional behaviors are attached with only
+          </p></li><li><p>As demonstrated in
+          the MIME optimization behavior, behaviors must be engaged
+          with respect to messages that are targeted to the provider
+          so that the provider can determine that the optional
+          behavior is engaged. In other words, the requirement of self
+          describing nature of messages [<a href="#self-describing"><b>5.4  Self Describing Messages </b></a>] in order to engage behaviors must
+          not be forgotten with regard to the client's ability to
+          detect and select the alternative if it is to participate in
+          the exchange. </p></li><li><p> The target scope
+          of an optional assertion is an important factor for
+          assertion authors to consider as it determines the
+          <em>granularity</em> where the behavior is optionally
+          engaged. For example, if the assertion is targeted for an
+          endpoint policy subject, it is expected to govern all the
+          messages that are indicated by the specific endpoint when
+          optional behavior is <em> engaged </em>. Since the
+          behavior would be applicable to policy subject that is
+          designated, it is important for the policy assertion authors
+          to choose the appropriate level of granularity for optional
+          behaviors, to consider whether a specific message or all
+          messages, etc.  are targeted. </p><ul><li><p> Attaching optional
+          assertions to outbound-messages using message policy subject
+          require some care. An explicit, out of band mechanism may be
+          necessary  to enable a client to indicate that
+          the optional behavior is engaged. Currently such a mechanism
+          is outside the scope of WS-Policy Framework.  </p></li><li><p>When optional
+            behaviors are indicated by attaching assertions with only
             one side of an interaction, such as an inbound message of
             a request-response, the engagement of the rest of the
-            interaction will be undefined. For example, if a
-            request-response interaction only specified MTOM
+            interaction will be <em>undefined</em>. For example,
+            if a request-response interaction only specified MTOM
             optimization for an inbound message, it would not be clear
             whether the outbound message from the provider could also
-            utilize the behavior. Therefore, the assertion authors
-            are encouraged to consider how the attachment on a message
+            utilize the behavior. Therefore, the assertion authors are
+            encouraged to consider how the attachment on a message
             policy subject on a response message should be treated
             when optional behaviors are specified for message
-            exchanges within a request response for response
-            messages. Leaving the semantics undescribed may result in
-            providers making assumptions (i.e. if the incoming message
-            utilized the optimization, the response will be returned
-            utilizing the MTOM serialization). Similarly, if
-            engagement of a behavior is only specified for an
-            outbound message, it may be necessary to describe the
+            exchanges within a request response for response messages,
+            using message policy subject. Leaving the semantics
+            undescribed may result in providers making assumptions
+            (i.e. if the incoming message utilized the optimization,
+            the response will be returned utilizing the MTOM
+            serialization). Similarly, if engagement of a behavior is
+            only specified for an outbound message, the policy
+            assertion authors should consider to describe the
             semantics if the incoming messages also utilized the
-            behavior. <cite><a href="#WS-RM">Web Services Reliable Messaging</a></cite> Policy currently allows
-            the incoming messages to utilize WS-RM protocol (see
-            <cite><a href="#WS-RM">Web Services Reliable Messaging</a></cite>) to be engaged although the
-            assertion may only appear on an outbound message in a
-            request response. </p></li><li><p>Optional assertion authors should explicitly state
-          how the capability that is enabled by the assertion would be
+            behavior. This is especially important if the assertion is
+            applicable to more than one specific policy subject. One
+            approach that is currently taken by WS-RM Policy <cite><a href="#WS-RM">Web Services Reliable Messaging</a></cite> is to introduce both message and endpoint
+            policy subjects for one of its assertions and require the
+            use of endpoint policy subject when message level subject
+            is used via attachment. </p></li></ul></li><li><p>Optional assertion authors should explicitly state
+          how the behavior that is enabled by the assertion would be
           engaged when they are designing their assertion, whether by
-          specific headers or some other means. </p></li></ul></div><div class="div2">
+          specific headers or some other means. See also <a href="#self-describing"><b>5.4  Self Describing Messages </b></a>.</p></li></ul></div><div class="div2">
 <h3><a name="considerations-for-intersection"></a>5.6  Considerations for Intersection and Merging </h3></div><div class="div2">
 <h3><a name="typing-assertions"></a>5.7 Typing Assertions</h3><p>Since a <em>QName</em> is the central mechanism for
 	  identifying a policy assertion, assertion authors should be
@@ -1167,4 +1183,4 @@
   </p></div><div class="div1">
 <h2><a name="change-description"></a>E. Changes in this Version of
           the Document (Non-Normative)</h2><p>A list of substantive changes since the previous publication is below:</p><ul><li><p>TBD</p></li></ul></div><div class="div1">
-<h2><a name="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 rowspan="1" colspa="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></tbody></table><br></div></div></body></html>
\ No newline at end of file
+<h2><a name="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 rowspan="1" colspa="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></tbody></table><br></div></div></body></html>
\ No newline at end of file
Received on Wednesday, 1 November 2006 02:46:27 GMT

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