- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 16 Mar 2007 04:09:04 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv18809
Modified Files:
ws-policy-guidelines.html ws-policy-guidelines.xml
Log Message:
Implement resolution for issue 4035, editors action 197.
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -d -r1.33 -r1.34
--- ws-policy-guidelines.html 16 Mar 2007 03:29:42 -0000 1.33
+++ ws-policy-guidelines.html 16 Mar 2007 04:09:02 -0000 1.34
@@ -179,29 +179,27 @@
transaction. Such data formats and protocols manifest on the wire. Providers and
requesters rely on wire messages conforming to such formats and protocols
to achieve interoperability.
- </p><p>If an assertion describes a behavior that does not manifest on the
- wire then the assertion is not relevant to an interoperable interaction.
- An example is an assertion that describes the privacy notice information of a provider
- and the associated regulatory safeguard in place on the provider’s side. Such
- assertions may represent business or regulatory level metadata but do not add any value
- to interoperability.
- </p><p>If an assertion has no wire or message-level visible behavior then the interacting
+ </p><p>
+ If an assertion describes a behavior that does not manifest on the wire then the assertion will not impact the
+ interoperability of wire messages, but may still be relevant to enabling an interoperable interaction.
+ For example, a provider may not wish to interact unless a client can accept an assertion describing provider behavior.
+ An example is an assertion that describes the privacy notice information of a provider and the associated regulatory
+ safeguard in place on the provider's side. For cases where the provider does not intend the assertion to impact
+ interoperability it may mark it as ignorable.
+ </p><p>If an assertion has no wire or message-level visible behavior then the interacting
participants may require some sort of additional mechanism to indicate
compliance with the assertion and to enable dispute resolution.
Introducing an additional non-repudiation mechanism adds
unnecessary complexity to processing a policy assertion.
</p></li><li><p>Does the behavior apply to two or more Web service participants?
- </p><p>A shared behavior refers to a requirement that is relevant to an interoperable Web
- service interaction and involves two or more participants. If an assertion only
- describes one participant’s behavior (non-shared behavior) then the assertion is not
- relevant to an interoperable interaction. Non-shared behaviors do not add any value for
- tooling or interoperability. An example of a non-shared behavior is the use of logging
- or auditing by the provider.
- Requesters may use the policy intersection to select a compatible policy alternative
- for a Web service interaction. If an assertion only describes one participant’s behavior
- then this assertion will not be present in the other participants’ policy and the policy
- intersection will unnecessarily produce false negatives.
- </p></li><li><p>Does the behavior have an implied scoping to a policy subject such as service, endpoint, operation and message?
+ </p><p>A shared behavior refers to a requirement that is relevant to an interoperable Web service interaction and involves
+ two or more participants. If an assertion only describes one participant's behavior the assertion may still be relevant to
+ enabling an interoperable interaction.
+ An example is the use of logging or auditing by the provider. If an assertion only describes one participant's behavior then
+ the assertion may be marked as ignorable (indicating it does not impact interoperability). An ignorable policy assertion is
+ ignored for lax policy intersection. If an assertion is not an ignorable assertion then it is deemed important for agreement
+ between both parties.
+ </p></li><li><p>Does the behavior have an implied scoping to a policy subject such as service, endpoint, operation and message?
</p></li><li><p>Is there a requirement that a choice must be made for successful interaction?</p><p>Sometimes providers and requesters are required to engage in certain behaviors.
The use of optimization and reliable messaging are two examples.
</p></li></ul><p>There are already many examples in the industry that adhere to the above practices, such as <cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite>
@@ -1312,7 +1310,7 @@
<a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0054.html">Umit</a> to the list of editors.
Editors' action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/86">86</a>.
</td></tr><tr><td rowspan="1" colspan="1">20061128</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Replaced section in Lifecycle with pointer to the text in the primer: related to action 77
- </td></tr><tr><td rowspan="1" colspan="1">20061129</td><td rowspan="1" colspan="1">FH</td><td rowspan="1" colspan="1">Editorial revision (editorial actions
+ </td></tr><tr><td rowspan="1" colspan="1">20061129</td><td rowspan="1" colspan="1">FJH</td><td rowspan="1" colspan="1">Editorial revision (editorial actions
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/84">84</a> and
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/90">90</a>) -
includes suggestions from Asir:
@@ -1372,4 +1370,8 @@
for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3979">issue 3979</a>.
Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/198">198</a>.
- </td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
+ </td></tr><tr><td rowspan="1" colspan="1">20070315</td><td rowspan="1" colspan="1">FJH</td><td rowspan="1" colspan="1">Implemented <a href="http://www.w3.org/2007/03/13-ws-policy-irc#T23-08-08">resolution</a> for issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4035">4035</a>
+ as outlined in
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0169.html">proposal</a>.
+ Editorial action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/197">197</a>. </td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -d -r1.42 -r1.43
--- ws-policy-guidelines.xml 16 Mar 2007 03:29:42 -0000 1.42
+++ ws-policy-guidelines.xml 16 Mar 2007 04:09:02 -0000 1.43
@@ -175,6 +175,7 @@
<item>
<p>Is the behavior visible?
</p>
+
<p>A visible behavior refers to a requirement that manifests itself on the wire. Web services
provide interoperable machine-to-machine interaction among disparate systems. Web
service interoperability is the capability of disparate systems to exchange data using
@@ -184,13 +185,14 @@
requesters rely on wire messages conforming to such formats and protocols
to achieve interoperability.
</p>
- <p>If an assertion describes a behavior that does not manifest on the
- wire then the assertion is not relevant to an interoperable interaction.
- An example is an assertion that describes the privacy notice information of a provider
- and the associated regulatory safeguard in place on the provider’s side. Such
- assertions may represent business or regulatory level metadata but do not add any value
- to interoperability.
- </p>
+ <p>
+ If an assertion describes a behavior that does not manifest on the wire then the assertion will not impact the
+ interoperability of wire messages, but may still be relevant to enabling an interoperable interaction.
+ For example, a provider may not wish to interact unless a client can accept an assertion describing provider behavior.
+ An example is an assertion that describes the privacy notice information of a provider and the associated regulatory
+ safeguard in place on the provider's side. For cases where the provider does not intend the assertion to impact
+ interoperability it may mark it as ignorable.
+ </p>
<p>If an assertion has no wire or message-level visible behavior then the interacting
participants may require some sort of additional mechanism to indicate
compliance with the assertion and to enable dispute resolution.
@@ -201,19 +203,16 @@
<item>
<p>Does the behavior apply to two or more Web service participants?
</p>
- <p>A shared behavior refers to a requirement that is relevant to an interoperable Web
- service interaction and involves two or more participants. If an assertion only
- describes one participant’s behavior (non-shared behavior) then the assertion is not
- relevant to an interoperable interaction. Non-shared behaviors do not add any value for
- tooling or interoperability. An example of a non-shared behavior is the use of logging
- or auditing by the provider.
- Requesters may use the policy intersection to select a compatible policy alternative
- for a Web service interaction. If an assertion only describes one participant’s behavior
- then this assertion will not be present in the other participants’ policy and the policy
- intersection will unnecessarily produce false negatives.
- </p>
-
- </item>
+ <p>A shared behavior refers to a requirement that is relevant to an interoperable Web service interaction and involves
+ two or more participants. If an assertion only describes one participant's behavior the assertion may still be relevant to
+ enabling an interoperable interaction.
+ An example is the use of logging or auditing by the provider. If an assertion only describes one participant's behavior then
+ the assertion may be marked as ignorable (indicating it does not impact interoperability). An ignorable policy assertion is
+ ignored for lax policy intersection. If an assertion is not an ignorable assertion then it is deemed important for agreement
+ between both parties.
+ </p>
+ </item>
+
<item>
<p>Does the behavior have an implied scoping to a policy subject such as service, endpoint, operation and message?
</p>
@@ -1867,7 +1866,7 @@
</tr>
<tr>
<td>20061129</td>
- <td>FH</td>
+ <td>FJH</td>
<td>Editorial revision (editorial actions
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/84">84</loc> and
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/90">90</loc>) -
@@ -2035,7 +2034,16 @@
<loc
href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/198">198</loc>.
</td>
- </tr>
+ </tr>
+ <tr>
+ <td>20070315</td>
+ <td>FJH</td>
+ <td>Implemented <loc href="http://www.w3.org/2007/03/13-ws-policy-irc#T23-08-08">resolution</loc> for issue
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4035">4035</loc>
+ as outlined in
+ <loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0169.html">proposal</loc>.
+ Editorial action <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/197">197</loc>. </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Friday, 16 March 2007 04:09:12 UTC