- From: Toufic Boubez via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 20 Dec 2006 06:24:26 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv31662
Modified Files:
ws-policy-guidelines.html ws-policy-guidelines.xml
Log Message:
Editorial revision: most parts of editorial action 96 from MS review.
Remaining editorials to be reviewed.
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- ws-policy-guidelines.html 30 Nov 2006 06:03:53 -0000 1.11
+++ ws-policy-guidelines.html 20 Dec 2006 06:24:20 -0000 1.12
@@ -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="#d3e176">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"> WS-Policy 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 WS-Policy 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> &nbp; 4.3.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> 4.5.1 <a href="#d3e514">Optional behavior in Compact authoring</a><br> 4.5.2 <a href="#d3e522">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 <ahref="#appropriate-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="#d3e176">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"> WS-Policy 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 WS-Policy 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> &nbp; 4.3.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> 4.5.1 <a href="#d3e518">Optional behavior in Compact authoring</a><br> 4.5.2 <a href="#d3e526">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 <ahref="#appropriate-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>
<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
@@ -157,7 +157,7 @@
</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 this practice, such as <cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite>
+ </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>
and <cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>. Some common characteristics from these documents may be considered as <em>best practices</em> for new assertion authors:
</p><ul><li><p>Specify both the syntax and the semantics of the assertions
</p></li><li><p>If nested or parameterized assertions are defined, be clear about their usage
@@ -176,7 +176,7 @@
express their own domain knowledge, it is necessary to provide basic
functionality that all domains could exploit and then allow
points of extension where authors of the various WS-Policy
- expressions for a particular domain can provide additional semantics.
+ assertions for a particular domain can provide additional semantics.
</p><p>Some policy assertions specify traditional
requirements and capabilities that will ultimately manifest on
the wire (e.g., authentication scheme, transport protocol selection). Other policy assertions have no wire manifestation
@@ -247,15 +247,15 @@
configurations dynamically.
</p></div><div class="div3">
<h4><a name="providers"></a>3.1.3 Providers</h4><p>A provider of WS-Policy Assertions can be any web service implementation that can
- specify its on-the-wire message behavior as an XML
- expression that conforms to the WS-PolicyFramework and
- WS-Policy Attachment specifications. The
- WS-PolicyAttachment specification has defined a set of
+ specify its on-the-wire message behavior as a policy
+ expression that conforms to the Web Services Policy 1.5 - Framework [<cite><a href="#WS-Policy">Web Services Policy Framework</a></cite>]
+ and Web Services Policy 1.5 - Attachment [<cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>] specifications.
+ The Web Services Policy 1.5 - Attachment specification has defined a set of
subjects and an extensible mechanism for attaching policies
to web services subjects. When a web service provider
chooses to make its capabilities and constraints available,
- it may also need to conform to requirements of other policy
- specifications it utilizes ( i.e., WS-SecurityPolicy).
+ the provider may also need to conform to requirements of other policy
+ assertion specifications it utilizes ( i.e., WS-SecurityPolicy).
</p><p>When deploying services with policies it is useful for providers to anticipate how
to evolve their services capabilities over time. If
forward compatibility is a concern in order to accommodate
@@ -328,8 +328,9 @@
<h3><a name="compact-full"></a>4.2 Authoring Styles </h3><p> WS-Policy supports two different authoring styles. A compact form is one in which an expression consists of three
constructs: an attribute to decorate an assertion (to indicate whether it is required or optional), semantics for
recursively nested policy operators, and a policy reference/inclusion mechanism.
- </p><div class="exampleOuter"><div class="exampleInner"><pre><wsp:Policy xmlns:wsp='http://www.w3.org/@@@@/@@/ws-policy' xmlns:sp='http://schemas.xmlsoap.org/ws/2005/07/securitypolicy'
- xmlns:wsrmp='http://docs.oasis-open.org/ws-rx/wsrmp/200608'>
+ </p><div class="exampleOuter"><div class="exampleInner"><pre><wsp:Policy xmlns:wsp='http://www.w3.org/@@@@/@@/ws-policy'
+ xmlns:sp='http://schemas.xmlsoap.org/ws/2005/07/securitypolicy'
+ xmlns:wsrmp='http://docs.oasis-open.org/ws-rx/wsrmp/200608'>
<wsrmp:RMAssertion wsp:Optional="true"/>
<wsp:ExactlyOne>
<wsp:All>
@@ -345,11 +346,12 @@
</wsp:ExactlyOne>
</wsp:Policy></pre></div></div><p>An alternative style is a "normal form" in which the optional attribute is replaced by the expression of the
alternatives allowed by the set of policy assertions.
- </p><div class="exampleOuter"><div class="exampleInner"><pre><wsp:Policy xmlns:wsp='http://www.w3.org/@@@@/@@/ws-policy' xmlns:sp='http://schemas.xmlsoap.org/ws/2005/07/securitypolicy'
+ </p><div class="exampleOuter"><div class="exampleInner"><pre><wsp:Policy xmlns:wsp='http://www.w3.org/@@@@/@@/ws-policy'
+ xmlns:sp='http://schemas.xmlsoap.org/ws/2005/07/securitypolicy'
xmlns:wsrmp='http://docs.oasis-open.org/ws-rx/wsrmp/200608'>
<wsp:ExactlyOne>
- <wsp:All>
+ <wsp:All>
<wsrmp:RMAssertion>
<sp:TransportBinding>
<wsp:Policy>
@@ -358,8 +360,7 @@
<sp:HttpsToken RequireClientCertificate='true' />
</wsp:Policy>
</sp:TransportToken>
-
- </wsp:Policy>
+ </wsp:Policy>
</sp:TransportBinding>
</wsp:All>
@@ -374,6 +375,7 @@
</wsp:Policy>
</sp:TransportBinding>
</wsp:All>
+
</wsp:ExactlyOne>
</wsp:Policy></pre></div></div><p> Note that both authoring styles are equivalent, however
there may be reasons to choose one form over another
@@ -599,7 +601,7 @@
to the WS-Policy framework.
</p></div></div><div class="div2">
<h3><a name="optional-policy-assertion"></a>4.5 Designating Optional Behaviors</h3><div class="div3">
-<h4><a name="d3e514"></a>4.5.1 Optional behavior in Compact authoring</h4><p>Optional behaviors represent behaviors which may be engaged by a consumer. When using the
+<h4><a name="d3e518"></a>4.5.1 Optional behavior in Compact authoring</h4><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
@@ -610,7 +612,7 @@
runtime behavior. In order to simplify reference to such
assertions, we just use the term optional assertions in this section.
</p></div><div class="div3">
-<h4><a name="d3e522"></a>4.5.2 Optional behavior at runtime</h4><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an
+<h4><a name="d3e526"></a>4.5.2 Optional behavior at runtime</h4><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an
example that proposes the use of <cite><a href="#MTOM">MTOM</a></cite> as an
optional behavior that can be engaged by a consumer. The
primer proposes that an assertion that identifies the use of
@@ -900,16 +902,16 @@
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>
<soap:Header>
- <wss:Security soap:mustUnderstand ="1">
- <wsu:Timestamp u:Id=_0">
- <wsu:Created> 20006-01-19T02:49:53.914Z </u:Created>
- <wsu:Expires> 20006-01-19T02:54:53.914Z </u:Expires>
- </wsu:Timestamp>
+ <wss:Security soap:mustUnderstand ="1">
+ <wsu:Timestamp u:Id=_0">
+ <wsu:Created> 20006-01-19T02:49:53.914Z </u:Created>
+ <wsu:Expires> 20006-01-19T02:54:53.914Z </u:Expires>
+ </wsu:Timestamp>
</wss:Security>
- <wsa:To> http://CompanyA/quote <wsa:To>
- <wsa:Action> http://CompanyA/GetRealQuote</wsa:Action>
-</soap:Header>
-<soap:Body>
+ <wsa:To> http://CompanyA/quote <wsa:To>
+ <wsa:Action> http://CompanyA/GetRealQuote</wsa:Action>
+ </soap:Header>
+ <soap:Body> ...
</soap:Envelope></pre></div></div><p>The SOAP message in the example above includes security
timestamps that express creation and expiration times of this
message. Company A requires the use of these security timestamps
@@ -945,11 +947,13 @@
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">
- <wsa:UsingAddressing /> <ExactlyOne>
- <sp:TransportBinding></sp:TransportBinding>
- <sp:AsymmetricBinding></sp:AssymetricBinding>
- </ExactlyOne> </Policy> </pre></div></div><p>We have shown above that Company A offered a
+ 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">
+ <wsa:UsingAddressing/>
+ <ExactlyOne>
+ <sp:TransportBinding></sp:TransportBinding>
+ <sp:AsymmetricBinding></sp:AssymetricBinding>
+ </ExactlyOne>
+</Policy></pre></div></div><p>We have shown above that Company A offered a
second profile that included two security options. The details of
the Bindings, requires a more detailed exploration of some of the
other features of the WS-Policy Framework. </p><p>When WS-Policy authors create sets of Policy assertions, like
@@ -967,27 +971,26 @@
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">
- <wsa:UsingAddressing />
- <ExactlyOne>
- <sp:TransportBinding>
- <Policy>
- <sp:TransportToken>
- <Policy>
- <sp:HttpsToken RequireClienCertificate="false" />
- </Policy>
- </sp:TransportToken>
- <sp:AlgorithmSuite>
- <Policy>
- <sp:Basic256Rsa15 />
- </Policy>
- </sp:AlgorithmSuite>
- </Policy>
- </sp:TransportBinding>
- <sp:AsymmetricBinding>
+ <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">
+ <wsa:UsingAddressing/>
+ <ExactlyOne>
+ <sp:TransportBinding>
+ <Policy>
+ <sp:TransportToken>
+ <Policy>
+ <sp:HttpsToken RequireClienCertificate="false" />
+ </Policy>
+ </sp:TransportToken>
+ <sp:AlgorithmSuite>
+ <Policy>
+ <sp:Basic256Rsa15 />
+ </Policy>
+ </sp:AlgorithmSuite>
+ </Policy>
+ </sp:TransportBinding>
+ <sp:AsymmetricBinding>
</sp:AssymetricBinding>
- </ExactlyOne>
+ </ExactlyOne>
</Policy></pre></div></div><p>
<code>The sp:AlgorithmSuite</code> is a nested policy
assertion of the <code>sp:TransportBinding</code> assertion and
@@ -1015,12 +1018,10 @@
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">
- <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
+ 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">
+ <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"
@@ -1048,10 +1049,9 @@
</wsp:Policy>
<wsdl:binding name="CompanyADefaultBinding" type="tns:CompanyADefault">
- <wsp:PolicyReference id=#CompanyA-ProfileB>
- <wsdl:operation name="GetQuote"> </wsdl:operation>
-
-</wsdl:binding> </pre></div></div><p>In some cases, companies may chose to implement their own
+ <wsp:PolicyReference id=#CompanyA-ProfileB>
+ <wsdl:operation name="GetQuote"> </wsdl:operation>
+</wsdl:binding></pre></div></div><p>In some cases, companies may chose to implement their own
assertions. When companies chose to become policy authors they need
to consider not only the definition of the behavior that the
assertion represents but they need to consider how new assertions
@@ -1223,4 +1223,8 @@
<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">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.
</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.20
retrieving revision 1.21
diff -u -d -r1.20 -r1.21
--- ws-policy-guidelines.xml 18 Dec 2006 03:48:58 -0000 1.20
+++ ws-policy-guidelines.xml 20 Dec 2006 06:24:20 -0000 1.21
@@ -230,7 +230,7 @@
</item>
</ulist>
- <p>There are already many examples in the industry that adhere to this practice, such as <bibref ref="WS-RM-Policy"/>
+ <p>There are already many examples in the industry that adhere to the above practices, such as <bibref ref="WS-RM-Policy"/>
and <bibref ref="WS-SecurityPolicy"/>. Some common characteristics from these documents may be considered as <emph>best practices</emph> for new assertion authors:
</p>
<ulist>
@@ -267,7 +267,7 @@
express their own domain knowledge, it is necessary to provide basic
functionality that all domains could exploit and then allow
points of extension where authors of the various WS-Policy
- expressions for a particular domain can provide additional semantics.
+ assertions for a particular domain can provide additional semantics.
</p>
<p>Some policy assertions specify traditional
requirements and capabilities that will ultimately manifest on
@@ -361,15 +361,15 @@
<div3 id="providers">
<head>Providers</head>
<p>A provider of WS-Policy Assertions can be any web service implementation that can
- specify its on-the-wire message behavior as an XML
- expression that conforms to the WS-PolicyFramework and
- WS-Policy Attachment specifications. The
- WS-PolicyAttachment specification has defined a set of
+ specify its on-the-wire message behavior as a policy
+ expression that conforms to the Web Services Policy 1.5 - Framework [<bibref ref="WS-Policy"/>]
+ and Web Services Policy 1.5 - Attachment [<bibref ref="WS-PolicyAttachment"/>] specifications.
+ The Web Services Policy 1.5 - Attachment specification has defined a set of
subjects and an extensible mechanism for attaching policies
to web services subjects. When a web service provider
chooses to make its capabilities and constraints available,
- it may also need to conform to requirements of other policy
- specifications it utilizes ( i.e., WS-SecurityPolicy).
+ the provider may also need to conform to requirements of other policy
+ assertion specifications it utilizes ( i.e., WS-SecurityPolicy).
</p>
<p>When deploying services with policies it is useful for providers to anticipate how
to evolve their services capabilities over time. If
@@ -1857,6 +1857,14 @@
<td>Formatted examples in <specref ref="compact-full"/> and <specref ref="scenario"/>.
</td>
</tr>
+ <tr>
+ <td>20061219</td>
+ <td>TIB</td>
+ <td>Editorial revision: most parts of editorial action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/96">96</loc>.
+ Remaining editorials to be reviewed.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Wednesday, 20 December 2006 06:24:39 UTC