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

2006/ws/policy ws-policy-guidelines.xml,1.8,1.9

From: Umit Yalsinap via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 01 Nov 2006 02:31:59 +0000
To: public-ws-policy-eds@w3.org
Message-Id: <E1Gf5tX-0004sj-CG@lionel-hutz.w3.org>

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

Modified Files:
	ws-policy-guidelines.xml 
Log Message:
Assertions for optional behaviors take 2


Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- ws-policy-guidelines.xml	1 Nov 2006 01:18:13 -0000	1.8
+++ ws-policy-guidelines.xml	1 Nov 2006 02:31:56 -0000	1.9
@@ -726,18 +726,19 @@
      </p>
 			</div2>
 			<div2 id="optional-policy-assertion">
-				<head>Optional Policy Assertion</head>
-				<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,
+				<head>Policy Assertions Designating Optional Behaviors</head>
+				<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>
+        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 <bibref ref="WS-Policy-Primer"/> document contains an
         example that proposes the use of <bibref ref="MTOM"/> as an
         optional behavior that can be engaged by a consumer. The
@@ -760,7 +761,7 @@
         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>
+          Serialization require some care considering the scoping of the assertion that is applicable. </p>
 				<ulist>
 					<item>
 						<p>Since optional behaviors indicate optionality for
@@ -774,51 +775,74 @@
           </p>
 					</item>
 					<item>
-						<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>
-					</item>
-					<item>
-						<p>When optional behaviors are attached with only
+						<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 [<specref
+          ref="self-describing"/>] 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> </item> <item>
+	                                        <p> The target scope
+          of an optional assertion is an important factor for
+          assertion authors to consider as it determines the
+          <emph>granularity</emph> 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 <emph> engaged </emph>. 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>
+
+	                          <ulist>
+                                        <item> <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> </item>
+          
+	                                 <item>
+						<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 <emph>undefined</emph>. 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. <bibref ref="WS-RM"/> Policy currently allows
-            the incoming messages to utilize WS-RM protocol (see
-            <bibref ref="WS-RM"/>) to be engaged although the
-            assertion may only appear on an outbound message in a
-            request response. </p>
-					</item>
-					<item>
+            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 <bibref
+            ref="WS-RM"/> 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> </item> 
+                                 </ulist> </item>
+
+                                        <item>
 						<p>Optional assertion authors should explicitly state
-          how the capability that is enabled by the assertion would be
+          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>
+          specific headers or some other means. See also <specref ref="self-describing"/>.</p>
 					</item>
 				</ulist>
 			</div2>
@@ -1613,6 +1637,11 @@
 						<td>UY</td>
 						<td>Fixes for Frederick's editorial comments (20061025)</td>
 					</tr>
+<tr>
+						<td>20061031</td>
+						<td>UY</td>
+						<td>Optionality discussion feedback integration</td>
+					</tr>
 				</tbody>
 			</table>
 		</inform-div1>
Received on Wednesday, 1 November 2006 02:46:24 GMT

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