- 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
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 UTC