- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 31 Jan 2007 20:15:16 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv1267
Modified Files:
ws-policy-guidelines.html ws-policy-guidelines.xml
Log Message:
Fixed numerous spelling and typo errors.
Implement resolution for issue 3953
(http://www.w3.org/Bugs/Public/show_bug.cgi?id=3953)
as noted in message 90 and amendment in message 217.
(http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0090.html and http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0217.html)
Changes correspond to editor's action 152.
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -d -r1.23 -r1.24
--- ws-policy-guidelines.html 30 Jan 2007 23:57:50 -0000 1.23
+++ ws-policy-guidelines.html 31 Jan 2007 20:15:13 -0000 1.24
@@ -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">What is an Assertion? </a><br>3. <a href="#d3e169">Who is involved in authoring Assertions? </a><br> 3.1 <a href="#roles"> Roles and Responsibilities </a><br> 3.1.1 <a href="#domain-owners"> Assertion Authors</a><br> 3.1.2 <a href="#consumers">Consumers</a><br> 3.1.3 <a href="#providers">Providers</a><br>4. <a href="#general-guidelines">General Guidelines for Assertion Authors</a><br> 4.1 <a href="#assertion-target">Assertions and Their Target Use</a><br> 4.2 <a href="#compact-full">Authoring Styles </a><br> 4.3 <a href="#new-guidelines-domains">Considerations when Modeling New Assertions</a><br> 43.1 <a href="#minimal-approach">Minimal approach</a><br> 4.3.2 <a href="#QName_and_XML_Information_Set_representation">QName and XML Information Set representation</a><br> 4.3.3 <a href="#self-describing"> Self Describing Messages </a><br> 4.3.4 <a href="#single-domains">Single Domains</a><br> 4.4 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br> 4.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br> 4.4.2 <a href="#nested-assertions">Nested Assertions</a><br> 4.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br> 4.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br> nbsp; 4.5.1 <a href="#d3e510">Optional behavior in Compact authoring</a><br> 4.5.2 <a href="#d3e518">Optional behavior at runtime</a><br> 4.6 <a href="#typing-assertions">Typing Assertions</a><br> 4.7 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>5. <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br> 5.2 <a href="#extending-assertions"> 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> 7.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br> 7.2 <a href="#apropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br> 7.2.1 <a href="#interaction">Interaction between Subjects</a><br> 7.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>8. <a href="#scenario">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">What is an Assertion? </a><br>3. <a href="#d3e169">Who is involved in authoring Assertions? </a><br> 3.1 <a href="#roles"> Roles and Responsibilities </a><br> 3.1.1 <a href="#domain-owners"> Assertion Authors</a><br> 3.1.2 <a href="#consumers">Consumers</a><br> 3.1.3 <a href="#providers">Providers</a><br>4. <a href="#general-guidelines">General Guidelines for Assertion Authors</a><br> 4.1 <a href="#assertion-target">Assertions and Their Target Use</a><br> 4.2 <a href="#compact-full">Authoring Styles </a><br> 4.3 <a href="#new-guidelines-domains">Considerations when Modeling New Assertions</a><br> 43.1 <a href="#minimal-approach">Minimal approach</a><br> 4.3.2 <a href="#QName_and_XML_Information_Set_representation">QName and XML Information Set representation</a><br> 4.3.3 <a href="#self-describing"> Self Describing Messages </a><br> 4.3.4 <a href="#single-domains">Single Domains</a><br> 4.4 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br> 4.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br> 4.4.2 <a href="#nested-assertions">Nested Assertions</a><br> 4.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br> 4.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br> nbsp; 4.5.1 <a href="#d3e510">Optional behavior in Compact authoring</a><br> 4.5.2 <a href="#d3e518">Optional behavior at runtime</a><br> 4.6 <a href="#typing-assertions">Typing Assertions</a><br> 4.7 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br> 4.8 <a href="#interrelated-domains">Interrelated domains</a><br>5. <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br> 5.2 <a href="#extending-assertions"> Evolution of Assertions (Versioning and Compatibility)</a><br>6. <a href="#best-practices-attachment">Applying Best Practices for Policy Attachment</a><br> 6.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br> 6.2 < href="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br> 6.2.1 <a href="#interaction">Interaction between Subjects</a><br> 6.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>7. <a href="#scenario">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>The WS-Policy specification defines a policy to be a collection
@@ -241,7 +241,7 @@
advertised policy.
</p><p>It is expected that consumers of WS-Policy will include a
wide range of client configurations, from stand alone client
- applications to "active" web service requestors that are
+ applications to "active" web service requesters that are
capable of adapting to the constraints and capabilities
expressed in a WS-Policy document and modifying their own
configurations dynamically.
@@ -267,7 +267,7 @@
</p></div></div></div><div class="div1">
<h2><a name="general-guidelines"></a>4. General Guidelines for Assertion Authors</h2><p> As Assertion Authors begin the task of inventing XML dialects to represent policy assertions they can take
advantage of WS-Policy building on XML principles and XML Schema validation in their design. WS-Policy
- relies on the QName of a policy assertion being an XML element but allows Assertuib Authors to optionally
+ relies on the QName of a policy assertion being an XML element but allows Assertion Authors to optionally
provide additional semantics through nesting assertions, or specifying assertion parameters.
This section covers several aspects of assertion design and provides some answers to the following questions:</p><ul><li><p>What is the intended use of the policy assertion?</p></li><li><p>Which authoring style will be used?</p></li><li><p>Is this a new policy domain? Does it need to compose with other domains?</p></li><li><p>How complex are the assertions?</p></li><li><p>Is there a need to consider nesting?</p></li><li><p>Do optional behaviors need to be represented?</p></li></ul><div class="div2">
<h3><a name="assertion-target"></a>4.1 Assertions and Their Target Use</h3><p>Assertion Authors need to have some definition of what the goal is for the assertions
@@ -289,7 +289,7 @@
assertion. Determining the appropriate policy subjects can sometimes
involve understanding the requirements of wide range of client configurations, from
stand alone client applications to "active" web service
- requestors that are capable of modifying their own configurations dynamically.
+ requesters that are capable of modifying their own configurations dynamically.
</p><p> Once the range of policy subjects is identified, there are choices for ways of
attaching multiple instances of a simple policy
assertion to multiple subjects. One way is to utilize
@@ -827,7 +827,19 @@
considers when sequences are present. In addition, when the
policy assertions do not target wire-level behaviors but
rather abstract requirements, this technique does not apply.
- </p></div></div><div class="div1">
+ </p></div><div class="div2">
+<h3><a name="interrelated-domains"></a>4.8 Interrelated domains</h3><p>Domain authors need to be clear about how assertions defined in
+ their domain may fit with assertions for interrelated domains. A
+ classic example of such an interrelated domain is security, because
+ security tends to
+ cut across all aspects of a solution.</p><p> One example is the definition
+ of additional assertions
+ related to the interrelated security domain [<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>] in
+ Web Services Reliable Messaging Policy
+ Assertions [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite>]. </p><p>Care should be taken to not duplicate existing
+ assertions and also to make sure that new assertions are consistent
+ with pre-existing assertions, when adding assertions related to an
+ interrelated domain. </p></div></div><div class="div1">
<h2><a name="lifecycle"></a>5. Lifecycle of Assertions</h2><p>Assertion Authors need to consider not just the expression of the current set of requirements but
how they anticipate new assertions being added to the set. There are three aspects that govern an assertions lifecycle:</p><ul><li><p> Assertion Extensibility </p></li><li><p> Policy Language Extensibility </p><p>Over time, the Policy WG or third parties can version or extend the Policy Language with new
or modified constructs. These constructs may be compatible or incompatible with previous versions.
@@ -865,49 +877,35 @@
<sp:Wss11>…</sp:Wss11>
</Policy></pre></div></div><p>Best practice: use independent assertions for modeling multiple equivalent
behaviors.</p></div></div><div class="div1">
-<h2><a name="inter-policy"></a>6. Inter-domain Policy and Composition Issues</h2><p>Assertion Authors must be aware of the interactions between their
- domain and other domains. For example, security assertions interact
- with other protocol assertions in a composition. Although
- modeling protocol assertions may appear to be an independent behavior,
- protocol assertions and security assertions affect transport
- bindings and their interactions must be considered. For
- example utilization of WS-Security Policy with other
- protocols affects transport bindings and would result in nested
- policy assertions when additional protocols are composed with
- <cite><a href="#WS-Security2004">WS-Security 2004</a></cite>. Thus, Assertion Authors should
- be aware of the compositional semantics with other related
- domains. The protocol assertions that require composition
- with WS-Security should be particularly aware of the nesting
- requirements on top of transport level security. </p></div><div class="div1">
-<h2><a name="best-practices-attachment"></a>7. Applying Best Practices for Policy Attachment</h2><div class="div2">
-<h3><a name="context-free-policies"></a>7.1 Appropriate Attachment: Preserving Context-Free Policies</h3><p>Policy attachment should not affect the interpretation of
+<h2><a name="best-practices-attachment"></a>6. Applying Best Practices for Policy Attachment</h2><div class="div2">
+<h3><a name="context-free-policies"></a>6.1 Appropriate Attachment: Preserving Context-Free Policies</h3><p>Policy attachment should not affect the interpretation of
Policy alternatives. If it did, each policy assertion would
need to be written with different (and possibly unknown)
attachment mechanisms in mind. In particular, the timing of a
policy attachment or the role that a party who attaches
policy should have no bearing on the evaluation of the policy
assertion </p></div><div class="div2">
-<h3><a name="appropriate-attachment-assertion-subjects"></a>7.2 Appropriate Attachment: Identifying Assertion Subjects</h3><p>Each policy attachment mechanism should unambiguously
+<h3><a name="appropriate-attachment-assertion-subjects"></a>6.2 Appropriate Attachment: Identifying Assertion Subjects</h3><p>Each policy attachment mechanism should unambiguously
identify the subject of the attached assertions. Generally,
this should be a specific SOAP node or a specific message
between two SOAP nodes. Some attachment mechanisms may
encompass multiple notes or messages, for example, "the
message along its entire path". </p><div class="div3">
-<h4><a name="interaction"></a>7.2.1 Interaction between Subjects</h4><p>If the best practices are followed, and the assertions
+<h4><a name="interaction"></a>6.2.1 Interaction between Subjects</h4><p>If the best practices are followed, and the assertions
are scoped according to their subject, then multiple policy
domains may be combined without conflict. Each domain
should define any limitations at the policy subject level
that might impact interoperability (i.e. WS-SecurityPolicy
- binding abstraction to group capabilities per message
exchange). </p></div></div><div class="div2">
-<h3><a name="identifying-assertion-sources"></a>7.3 Appropriate Attachment: Identifying Assertion Sources </h3><p>As with identifying Policy subjects, policy attachment
+<h3><a name="identifying-assertion-sources"></a>6.3 Appropriate Attachment: Identifying Assertion Sources </h3><p>As with identifying Policy subjects, policy attachment
mechanisms should make it possible to clearly identify the
- source of a poly assertion both for debugging and for
+ source of a policy assertion both for debugging and for
verification. This could take several forms: it could be
assumed (in WSDL, the source of the assertion is the same
as the WSDL provider) or it could be proven (using
<cite><a href="#WS-Trust">WS-Trust</a></cite>). </p></div></div><div class="div1">
-<h2><a name="scenario"></a>8. Scenario and a worked example</h2><p>To illustrate the topics explored in this document, we
+<h2><a name="scenario"></a>7. Scenario and a worked example</h2><p>To illustrate the topics explored in this document, we
include an example of a web service and how a fictitious company
might utilize the WS-Policy Framework to enable Web Service
interoperability. Company A has determined to utilize WS-Security,
@@ -930,10 +928,10 @@
the use of transport-level security for protecting messages as
well as including addressing headers. Employees of Company A have
already incorporated <code>wss:Security</code> headers into their
- messages. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-1. </span>Message with Security Headers</i></p><div class="exampleInner"><pre><soap:Envelope>
+ messages. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 7-1. </span>Message with Security Headers</i></p><div class="exampleInner"><pre><soap:Envelope>
<soap:Header>
<wss:Security soap:mustUnderstand ="1">
- <wsu:Timestamp u:Id=_0">
+ <wsu:Timestamp wsu:Id=_0">
<wsu:Created> 20006-01-19T02:49:53.914Z </u:Created>
<wsu:Expires> 20006-01-19T02:54:53.914Z </u:Expires>
</wsu:Timestamp>
@@ -949,7 +947,7 @@
messages. </p><p>The example below illustrates a policy expression that
CompanyA has created for its employees to use on their web
services to indicate the use of addressing and transport-level
- security for securing messages. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-2. </span> CompanyA-ProfileA </i></p><div class="exampleInner"><pre>
+ security for securing messages. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 7-2. </span> CompanyA-ProfileA </i></p><div class="exampleInner"><pre>
<Policy URI=http://www.CompanyA.com/WebServicesProfileA.xml>
<wsa:UsingAddressing />
<sp:TransportBinding></sp:TransportBinding>
@@ -973,11 +971,11 @@
<em>CompanyA-ProfileA</em> and it is the policy that is used
by many web services at Company A that rely on HTTPS to provide
transport level protection of messages. </p><p>The second policy is shown in Figure
- <em>CompanyA-ProfileB</em> and it offers requestors of a
+ <em>CompanyA-ProfileB</em> and it offers requesters of a
service the ability to provide additional integrity protection by
including WS-Security Headers to protect the message content
after it is processed by the transport. The additional security
- processing is not required by all Company A web services. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-3. </span>CompanyA-ProfileB (not expanded)</i></p><div class="exampleInner"><pre><Policy wsu:Id="CompanyA-ProfileB">
+ processing is not required by all Company A web services. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 7-3. </span>CompanyA-ProfileB (not expanded)</i></p><div class="exampleInner"><pre><Policy wsu:Id="CompanyA-ProfileB">
<wsa:UsingAddressing/>
<ExactlyOne>
<sp:TransportBinding></sp:TransportBinding>
@@ -1001,7 +999,7 @@
represent (ed) these dependent behaviors as "nested" policy
assertions. </p><p>In the example below the child Policy element is a nested
policy behavior and further qualifies the behavior of the
- <code>sp:TransportBinding</code> policy assertion. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-4. </span>CompanyA-ProfileB (fully expanded)</i></p><div class="exampleInner"><pre><Policy wsu:Id="CompanyA-ProfileB">
+ <code>sp:TransportBinding</code> policy assertion. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 7-4. </span>CompanyA-ProfileB (fully expanded)</i></p><div class="exampleInner"><pre><Policy wsu:Id="CompanyA-ProfileB">
<wsa:UsingAddressing/>
<ExactlyOne>
<sp:TransportBinding>
@@ -1048,13 +1046,13 @@
specification and attach the policies to the web service endpoint
policy subject as recommended by the WS-SecurityPolicy
specification. For the default web services, the URI is included
- in the wsdl binding for each web service. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-5. </span></i></p><div class="exampleInner"><pre><wsdl:binding name="CompanyADefaultBinding" type="tns:CompanyADefault">
+ in the wsdl binding for each web service. </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 7-5. </span></i></p><div class="exampleInner"><pre><wsdl:binding name="CompanyADefaultBinding" type="tns:CompanyADefault">
<wsp:PolicyReference URI="http://www.CompanyA.com/WebServicesProfileA.xml">
<wsdl:operation name="GetQuote"> </wsdl:operation>
</wsdl:binding></pre></div></div><p>The partner specified policy is included in the beginning of
the WSDL 1.1 document and referenced by the binding for the service
- as in the example below.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 8-6. </span></i></p><div class="exampleInner"><pre>
-<wsdl:definitions name="StokeQuote"
+ as in the example below.</p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 7-6. </span></i></p><div class="exampleInner"><pre>
+<wsdl:definitions name="StockQuote"
targetNamespace="http:..">
<wsp:Policy wsu:Id="CompanyA-ProfileB">
<wsa:UsingAddressing />
@@ -1257,7 +1255,7 @@
<a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0129.html">Part 1</a> and
<a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0134.html">Part 2</a>.
</td></tr><tr><td rowspan="1" colspan="1">20061129</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Formatted examples in <a href="#extending-assertions"><b>5.2 Evolution of Assertions (Versioning and Compatibility)</b></a>.
- </td></tr><tr><td rowspan="1" colspan="1">20061218</td><td rowspan="1" colspan="1">FS</td><td rowspan="1" colspan="1">Formatted examples in <a href="#compact-full"><b>4.2 Authoring Styles </b></a> and <a href="#scenario"><b>8. Scenario and a worked example</b></a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20061218</td><td rowspan="1" colspan="1">FS</td><td rowspan="1" colspan="1">Formatted examples in <a href="#compact-full"><b>4.2 Authoring Styles </b></a> and <a href="#scenario"><b>7. Scenario and a worked example</b></a>.
</td></tr><tr><td rowspan="1" colspan="1">20061219</td><td rowspan="1" colspan="1">TIB</td><td rowspan="1" colspan="1">Editorial revision: most parts of editorial action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/96">96</a>.
Remaining editorials to be reviewed.
@@ -1282,4 +1280,11 @@
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/119">119</a>.
Resolution for issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4141">4141</a></td></tr><tr><td rowspan="1" colspan="1">20070130</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Completed action item:
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/126">126</a>.
- Resolution for issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4188">4188</a></td></tr><tr><td rowspan="1" colspan="1">20070130</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Fixed SAWSDL ref name</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
+ Resolution for issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4188">4188</a></td></tr><tr><td rowspan="1" colspan="1">20070130</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Fixed SAWSDL ref name</td></tr><tr><td rowspan="1" colspan="1">20070131</td><td rowspan="1" colspan="1">FJH</td><td rowspan="1" colspan="1">Fixed numerous spelling and typo errors. Implement resolution for issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3953">3953</a>
+ as noted in message
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0090.html">90</a> and amended
+ as noted in message
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0217.html">217</a>.
+ Changes correspond to editor's action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/152">152</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.32
retrieving revision 1.33
diff -u -d -r1.32 -r1.33
--- ws-policy-guidelines.xml 30 Jan 2007 23:57:50 -0000 1.32
+++ ws-policy-guidelines.xml 31 Jan 2007 20:15:13 -0000 1.33
@@ -348,7 +348,7 @@
</p>
<p>It is expected that consumers of WS-Policy will include a
wide range of client configurations, from stand alone client
- applications to "active" web service requestors that are
+ applications to "active" web service requesters that are
capable of adapting to the constraints and capabilities
expressed in a WS-Policy document and modifying their own
configurations dynamically.
@@ -384,7 +384,7 @@
<head>General Guidelines for Assertion Authors</head>
<p> As Assertion Authors begin the task of inventing XML dialects to represent policy assertions they can take
advantage of WS-Policy building on XML principles and XML Schema validation in their design. WS-Policy
- relies on the QName of a policy assertion being an XML element but allows Assertuib Authors to optionally
+ relies on the QName of a policy assertion being an XML element but allows Assertion Authors to optionally
provide additional semantics through nesting assertions, or specifying assertion parameters.
This section covers several aspects of assertion design and provides some answers to the following questions:</p>
<ulist>
@@ -433,7 +433,7 @@
assertion. Determining the appropriate policy subjects can sometimes
involve understanding the requirements of wide range of client configurations, from
stand alone client applications to "active" web service
- requestors that are capable of modifying their own configurations dynamically.
+ requesters that are capable of modifying their own configurations dynamically.
</p>
<p> Once the range of policy subjects is identified, there are choices for ways of
attaching multiple instances of a simple policy
@@ -1173,6 +1173,23 @@
rather abstract requirements, this technique does not apply.
</p>
</div2>
+ <div2 id="interrelated-domains">
+ <head>Interrelated domains</head>
+ <p>Domain authors need to be clear about how assertions defined in
+ their domain may fit with assertions for interrelated domains. A
+ classic example of such an interrelated domain is security, because
+ security tends to
+ cut across all aspects of a solution.</p>
+ <p> One example is the definition
+ of additional assertions
+ related to the interrelated security domain [<bibref ref="WS-SecurityPolicy"/>] in
+ Web Services Reliable Messaging Policy
+ Assertions [<bibref ref="WS-RM-Policy"/>]. </p>
+ <p>Care should be taken to not duplicate existing
+ assertions and also to make sure that new assertions are consistent
+ with pre-existing assertions, when adding assertions related to an
+ interrelated domain. </p>
+ </div2>
</div1>
<div1 id="lifecycle">
<head>Lifecycle of Assertions</head>
@@ -1253,24 +1270,6 @@
</div2>
</div1>
- <div1 id="inter-policy">
- <head>Inter-domain Policy and Composition Issues</head>
- <p>Assertion Authors must be aware of the interactions between their
- domain and other domains. For example, security assertions interact
- with other protocol assertions in a composition. Although
- modeling protocol assertions may appear to be an independent behavior,
- protocol assertions and security assertions affect transport
- bindings and their interactions must be considered. For
- example utilization of WS-Security Policy with other
- protocols affects transport bindings and would result in nested
- policy assertions when additional protocols are composed with
- <bibref ref="WS-Security2004"/>. Thus, Assertion Authors should
- be aware of the compositional semantics with other related
- domains. The protocol assertions that require composition
- with WS-Security should be particularly aware of the nesting
- requirements on top of transport level security. </p>
- <!-- EDS TO DO: MORE/SIMPLIFY the previous paragraph -->
- </div1>
<div1 id="best-practices-attachment">
<head>Applying Best Practices for Policy Attachment</head>
<div2 id="context-free-policies">
@@ -1307,7 +1306,7 @@
<head>Appropriate Attachment: Identifying Assertion Sources </head>
<p>As with identifying Policy subjects, policy attachment
mechanisms should make it possible to clearly identify the
- source of a poly assertion both for debugging and for
+ source of a policy assertion both for debugging and for
verification. This could take several forms: it could be
assumed (in WSDL, the source of the assertion is the same
as the WSDL provider) or it could be proven (using
@@ -1360,7 +1359,7 @@
<eg xml:space="preserve"><soap:Envelope>
<soap:Header>
<wss:Security soap:mustUnderstand ="1">
- <wsu:Timestamp u:Id=_0">
+ <wsu:Timestamp wsu:Id=_0">
<wsu:Created> 20006-01-19T02:49:53.914Z </u:Created>
<wsu:Expires> 20006-01-19T02:54:53.914Z </u:Expires>
</wsu:Timestamp>
@@ -1412,7 +1411,7 @@
by many web services at Company A that rely on HTTPS to provide
transport level protection of messages. </p>
<p>The second policy is shown in Figure
- <emph>CompanyA-ProfileB</emph> and it offers requestors of a
+ <emph>CompanyA-ProfileB</emph> and it offers requesters of a
service the ability to provide additional integrity protection by
including WS-Security Headers to protect the message content
after it is processed by the transport. The additional security
@@ -1514,7 +1513,7 @@
<example>
<head/>
<eg xml:space="preserve">
-<wsdl:definitions name="StokeQuote"
+<wsdl:definitions name="StockQuote"
targetNamespace="http:..">
<wsp:Policy wsu:Id="CompanyA-ProfileB">
<wsa:UsingAddressing />
@@ -1971,6 +1970,18 @@
<td>UY</td>
<td>Fixed SAWSDL ref name</td>
</tr>
+ <tr>
+ <td>20070131</td>
+ <td>FJH</td>
+ <td>Fixed numerous spelling and typo errors. Implement resolution for issue
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3953">3953</loc>
+ as noted in message
+ <loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0090.html">90</loc> and amended
+ as noted in message
+ <loc href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0217.html">217</loc>.
+ Changes correspond to editor's action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/152">152</loc>.</td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Wednesday, 31 January 2007 20:15:30 UTC