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

2006/ws/policy ws-policy-guidelines.xml,1.68,1.69

From: Prasad Yendluri via cvs-syncmail <cvsmail@w3.org>
Date: Fri, 11 May 2007 22:51:37 +0000
To: public-ws-policy-eds@w3.org
Message-Id: <E1HmdxZ-0005iv-8C@lionel-hutz.w3.org>

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

Modified Files:
	ws-policy-guidelines.xml 
Log Message:
Updated 5.6 WSDL guidelines section to add G19 identified in AI 256 (now G24). Accounts for parts of resolution for issue 3989 corresponding to editors' action item 256 - now complete. 

Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.68
retrieving revision 1.69
diff -u -d -r1.68 -r1.69
--- ws-policy-guidelines.xml	8 May 2007 19:50:02 -0000	1.68
+++ ws-policy-guidelines.xml	11 May 2007 22:51:35 -0000	1.69
@@ -1213,13 +1213,15 @@
 				<p> In using WSDL attachment, it should be noted that the
         		service policy subject is a collection of endpoint policy
         		subjects. The endpoint policy subject is a collection of
-        		operation policy subjects and etc. As a result, the WSDL
+        		operation policy subjects and so on. As a result, the WSDL
         		policy subjects compose naturally. It is quite tempting to
         		associate the identified behavior to a broader policy subject
         		than to a fine granular policy subject. For instance, it is
         		convenient to attach a supporting token assertion (defined by
         		the Web Services Security Policy specification) to an endpoint
-        		policy subject instead of a message policy subject. 
+        		policy subject instead of a message policy subject. However such 
+        		policy attachments to policy subjects of broader scope and granularity 
+        		should be done only after careful evaluation. 
         		</p>
         		
 				<p role="practice" id="bp-WSDL-multiple-policy-subjects">
@@ -1243,7 +1245,7 @@
 				
 				<p>If the capability is not really suitable and may imply
 					different semantics with respect to attachment points, the
-					assertion authors should consider the following</p>
+					assertion authors should consider the following:</p>
 				<ulist>
 					<item>
 						<p> Decompose the semantics with several assertions.</p>
@@ -1252,20 +1254,29 @@
 						<p> Rewrite a single assertion targeting a specific subject. </p>
 					</item>
 				</ulist>
+				
+				<p role="practice" id="bp-WSDL-policy-scope-semantics">
+					<quote>Fully specify constraints on policy scope</quote>
+					<quote>Assertion authors must clearly describe any constraints on the 
+					policy scope if not limited to policy subjects identified by the policy 
+					attachment point.
+					</quote>
+				</p>
 					
 				<p>The current set of subjects as mapped to the WSDL 1.1
 					elements, can also constrain the assertion constructs. 
-					For Example, in WS-RM,
-					the assertion authors chose to support certain capabilities at
-					the endpoint level. This resulted in the finer granularity of
-					the assertion to apply at the message policy subject, but the
-					assertion semantics also indicates that the if 
-					a sender chose to engage RM
-					semantics (although not specified via attachment in WSDL at incoming
-					messages), the providers will honor the engagement of RM.
-					This is illustrative of how the
-					assertion author can specify additional constraints and
-					assumptions for attachment and engagement of behavior.
+					For Example, in WS-RM, the assertion authors chose to support 
+					certain capabilities at the endpoint level. This resulted in 
+					the finer granularity of the assertion to apply at the message 
+					policy subject, but the assertion semantics also indicates that 
+					the if a sender chose to engage RM semantics (although not specified 
+					via attachment in WSDL at incoming messages), the providers will honor 
+					the engagement of RM. So, the WS-RM Policy is a capability that 
+					governs a target endpoints capability to accept sequences that 
+					is beyond single message exchanges. This is illustrative of how the 
+					assertion author can specify additional constraints and assumptions 
+					for attachment and engagement of behavior. Such additional constraints 
+					must be clearly specified by the assertion authors.
 				</p>
 				
 				<p role="practice" id="bp-WSDL-preferred-attachment-point">
@@ -1282,8 +1293,8 @@
 				specify that as a preferred attachment point. However, this
 				approach only works if the policy subject is a true WSDL
 				construct other than some other protocol concept that is
-				layered over WSDL message exchanges. For example, the WS-RM
-				Policy is a capability that governs a target endpoints
+				layered over WSDL message exchanges. For example, as described previously
+				the WS-RM Policy is a capability that governs a target endpoints
 				capability to accept sequences that is beyond single message
 				exchanges. Therefore, its semantics encompasses the cases when
 				message level policy subjects may be used as attachment but
@@ -1291,6 +1302,34 @@
 				policy assertions do not target wire-level behaviors but
 				rather abstract requirements, this technique does not apply. 
 				</p>
+				
+				<p role="practice" id="bp-WSDL-policy-multiple-instance-semantics">
+					<quote>Semantics of multiple assertions of the same kind</quote>
+					<quote>A policy alternative can contain multiple instances of the 
+					same policy assertion. An assertion description should specify the 
+					semantics of multiple instances of a policy assertion in the same 
+					policy alternative and the semantics of parameters and nested policy
+					(if any) when there are multiple instances of a policy assertion in 
+					the same policy alternative.
+					</quote>
+				</p>
+				<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, 
+				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, 
+				and declares it to be equivalent to a single SignedParts assertion 
+				containing the union of all specified message parts. So, if a SignedParts 
+				assertion is specified in a WSDL binding at the input message level
+				and subsequently an additional SignedParts assertion is specified 
+				at the WSDL endpoint policy subject level, then the effective policy 
+				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>
+				
 			</div2>
 		<div2 id="interrelated-domains">
 			<head>Interrelated domains</head>
@@ -2341,7 +2380,17 @@
 							<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/256">256</loc>.
 						</td>
 					</tr>
-					
+					<tr>
+						<td>20070511</td>
+						<td>PY</td>
+						<td>Updated 5.6 WSDL guidelines section to add G19 identified in AI 256 (now G24).
+							Accounts for parts of resolution for  
+							<loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue 3989</loc>
+							corresponding to editors' action item
+							<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232">256</loc>
+							- now complete.
+						</td>
+					</tr> 
 				</tbody>
 			</table>
 		</inform-div1>
Received on Friday, 11 May 2007 22:51:39 GMT

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