- From: Umit Yalsinap via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 01 Nov 2006 01:18:41 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv23621
Modified Files:
ws-policy-guidelines.html
Log Message:
Fixes for Frederick's comments
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- ws-policy-guidelines.html 31 Oct 2006 04:04:56 -0000 1.5
+++ ws-policy-guidelines.html 1 Nov 2006 01:18:39 -0000 1.6
@@ -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">Basic Concepts: What is an Assertion</a><br> 2.1 <a href="#assertion-roles">Roles and Responsibilities in Utilizing Policy Assertions</a><br> 2.1.1 <a href="#domain-owners"> WS-Policy Authors</a><br> 2.1.2 <a href="#consumers">Consumers</a><br> 2.1.3 <a href="#providers">Providers</a><br>3. <a href="#general-guidelines">General Guidelines for WS-Policy Assertion Authors</a><br> 3.1 <a href="#assertion-target">Assertions and Their Target Use</a><br>4. <a href="#compact-full">Authoring Styles </a><br>5. <a href="#modeling-guidelines">Guidelines for Modeling New Assertions</a><br> 5.1 <a href="#new-domains">New Policy Domains</a><br> 5.2 <a href="single-domains">Single Domains</a><br> 5.3 <a href="#nested-assertions">Nested Assertions</a><br> 5.4 <a href="#parameterized-assertions">Assertions with Parameters</a><br> 5.5 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br> 5.6 <a href="#self-describing"> Self Describing Messages </a><br> 5.7 <a href="#optional-policy-assertion">Optional Policy Assertion</a><br> 5.8 <a href="#considerations-for-intersection"> Considerations for Intersection and Merging </a><br> 5.9 <a href="#typing-assertions">Typing Assertions</a><br> 5.10 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br> 5.11 <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.11.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressons</a><br> 5.11.2 <a href="#extending-assertions"> Factors in Extending Assertions within a Domain </a><br> 5.11.3 <a href="#assertion-evolution">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="#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="#scenerio">Scenario and 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">Basic Concepts: What is an Assertion</a><br> 2.1 <a href="#assertion-roles">Roles and Responsibilities in Utilizing Policy Assertions</a><br> 2.1.1 <a href="#domain-owners"> WS-Policy Authors</a><br> 2.1.2 <a href="#consumers">Consumers</a><br> 2.1.3 <a href="#providers">Providers</a><br>3. <a href="#general-guidelines">General Guidelines for WS-Policy Assertion Authors</a><br> 3.1 <a href="#assertion-target">Assertions and Their Target Use</a><br>4. <a href="#compact-full">Authoring Styles </a><br>5. <a href="#modeling-guidelines">Guidelines for Modeling New Assertions</a><br> 5.1 <a href="#new-domains">New Policy Domains</a><br> 5.2 <a href="single-domains">Single Domains</a><br> 5.3 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br> 5.3.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br> 5.3.2 <a href="#nested-assertions">Nested Assertions</a><br> 5.3.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br> 5.4 <a href="#self-describing"> Self Describing Messages </a><br> 5.5 <a href="#optional-policy-assertion">Optional Policy Assertion</a><br> 5.6 <a href="#considerations-for-intersection"> Considerations for Intersection and Merging </a><br> 5.7 <a href="#typing-assertions">Typing Assertions</a><br> 5.8 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br> &nsp; 5.9 <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.9.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br> 5.9.2 <a href="#extending-assertions"> Factors in Extending Assertions within a Domain </a><br> 5.9.3 <a href="#assertion-evolution">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="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br> 7.2.1 <a href="#interaction">Interaction betwen Subjects</a><br> 7.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>8. <a href="#scenerio">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>WS-Policy specification defines a policy to be a collection
@@ -209,7 +209,7 @@
</p></div><div class="div3">
<h4><a name="providers"></a>2.1.3 Providers</h4><p>A provider of WS-Policy
Assertions can be any web service implementation that can
- reflect it's on the wire message behavior as an XML
+ 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
@@ -223,7 +223,7 @@
to evolve their services capabilities over time. If
forward compatibility is a concern in order to accommodate
compatibility with different and potentially new clients,
- providers should refer to <a href="#lifecycle"><b>5.11 Lifecycle of Assertions</b></a> and
+ providers should refer to <a href="#lifecycle"><b>5.9 Lifecycle of Assertions</b></a> and
<cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> that describes service and
policy assertion evolution.
</p></div></div></div><div class="div1">
@@ -414,7 +414,31 @@
their service descriptions. </p><p>A review by a broad community is
the best way to ensure that the granularity of a set of domain
assertions is appropriate. </p></div><div class="div2">
-<h3><a name="nested-assertions"></a>5.3 Nested Assertions</h3><p>The framework provides the ability
+<h3><a name="comparison"></a>5.3 Comparison of Nested and Parameterized Assertions</h3><p>There are two different ways to
+ provide additional information in an
+ assertion beyond its type. We cover
+ these two cases below followed by a
+ comparison of these approaches
+ targeting when to use either of the
+ approach. </p><div class="div3">
+<h4><a name="parameterized-assertions"></a>5.3.1 Assertions with Parameters</h4><p>The framework allows WS-Policy
+ domain authors to define name value pairs, for example, to
+ qualify an assertion. For some domains it will be appropriate
+ to specify these parameters instead of nesting assertion elements. </p><p> Note that parameters of assertions include the following:</p><ul><li><p> Complex elements
+ with element children
+ that cannot be policy
+ assertions. </p></li><li><p> Elements that have attributes </p></li></ul><p>In the example below,
+ <code>sp:Body</code> and <code>sp:Header</code> elements
+ are the two assertion parameters of the
+ <code>sp:SignedParts</code> policy assertion (this
+ assertion requires the parts of a message to be
+ protected). </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 5-1. </span>Policy Assertion with Assertion Parameters</i></p><div class="exampleInner"><pre><Policy>
+ <sp:SignedParts>
+ <sp:Body />
+ <sp:Header />
+ </sp:SignedParts>
+</Policy></pre></div></div></div><div class="div3">
+<h4><a name="nested-assertions"></a>5.3.2 Nested Assertions</h4><p>The framework provides the ability
to "nest" policy assertions. For domains with a complex set of
options, nesting provides one way to indicate dependent
elements within a behavior. The granularity of assertions is
@@ -453,7 +477,7 @@
the <code>sp:TransportBinding</code> policy assertion (which
already requires the use of transport-level security for
protecting messages).
- </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 5-1. </span>Transport Security Policy Assertion</i></p><div class="exampleInner"><pre><sp:TransportBinding>
+ </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 5-2. </span>Transport Security Policy Assertion</i></p><div class="exampleInner"><pre><sp:TransportBinding>
<Policy>
<sp:TransportToken>
<Policy>
@@ -477,14 +501,8 @@
dependent behaviors automatically. That is, the complexity of
security usage is absorbed by a policy-aware client and hidden
from these Web service developers.
- </p></div><div class="div2">
-<h3><a name="parameterized-assertions"></a>5.4 Assertions with Parameters</h3><p>The framework provides an alternative approach for
- providing additional information for an assertion beyond its
- type. The framework allows WS-Policy domain authors to define
- name value pairs, for example, to qualify an assertion. For some domains it
- will be appropriate to specify these parameters instead of
- nesting elements. </p><p> Note that parameters of assertions include the following:</p><ul><li><p> Complex elements that have element children which can not be policy assertions. </p></li><li><p> Elements that have attributes </p></li></ul></div><div class="div2">
-<h3><a name="comparison"></a>5.5 Comparison of Nested and Parameterized Assertions</h3><p>The main consideration for selecting parameters or nesting
+ </p></div><div class="div3">
+<h4><a name="which-one-to-use"></a>5.3.3 Considerations for choosing parameters vs nesting</h4><p>The main consideration for selecting parameters or nesting
of assertions, is that <em>the framework intersection
algorithm processes nested alternatives, but does not consider
parameters in its algorithm</em>. </p><p>Domain authors should recognize that the framework can
@@ -503,57 +521,58 @@
delegated to the specific domain handlers that are not visible
to the WS-Policy framework. The tradeoff is the generality
vs. the flexibility and complexity of the comparison expected
- for a domain. </p><p>In the example below, <code>sp:Body</code> and <code>sp:Header</code> elements are the
- two assertion parameters of the <code>sp:SignedParts</code> policy assertion (this
- assertion requires the parts of a message to be protected). </p><div class="exampleOuter"><p style="text-align: left" class="exampleHead"><i><span>Example 5-2. </span>Policy Assertion with Assertion Parameters</i></p><div class="exampleInner"><pre><Policy>
- <sp:SignedParts>
- <sp:Body />
- <sp:Header />
- </sp:SignedParts>
-</Policy></pre></div></div></div><div class="div2">
-<h3><a name="self-describing"></a>5.6 Self Describing Messages </h3><p>WS-Policy is intended to communicate the requirements,
- capabilities, preferences and behaviors of nodes that provide the message's
- path, not specifically to declare properties of the message semantics.
- One of the advantages of Web services is that an XML
- message can be stored and later examined (e.g. as a record of a
- business transaction) or interpreted by an intermediary; however,
- if information that is necessary to understand a message is not
+ for a domain. </p></div></div><div class="div2">
+<h3><a name="self-describing"></a>5.4 Self Describing Messages </h3><p> WS-Policy is intended to
+ communicate the requirements, capabilities, preferences and
+ behaviors of nodes that provide the message's path, not
+ specifically to declare properties of the message semantics. One
+ of the advantages of Web services is that an XML message can be
+ stored and later examined (e.g. as a record of a business
+ transaction) or interpreted by an intermediary; however, if
+ information that is necessary to understand a message is not
available, these capabilities suffer.
- </p><p>For example, if the details of a message's encryption ( e.g.,
- the cipher used, etc) are expressed in policy that isn't attached
- to the message, it isn't possible to later decipher it. This is
- very different from expressing, in policy, what ciphers (and so
- forth) are supported by a particular endpoint, or those that are
- required in a particular message; the latter are the intended
- uses of the Ws-Policy framework.
- </p><p>The assertion authors should take into account that there are
- two important concepts when designing assertions and documenting the semantics of the
- assertion types. Firstly, an
- assertion type indicates a <em>runtime</em> behavior. Secondly,
- an assertion should also indicate how the assertion type can be
- inferred or indicated from a message. If there is a need for the
- behavior to be represented in a persistent way or if there s a need for additional data
- or metadata that is present in a message to be persisted, it should be incorporated
- into the assertion design or in the message itself.
- </p><p>As a result, Policy assertions should not be used to express
- the semantics of a message. If a property is
+ </p><p>Policy assertions should not be
+ used to express the semantics of a message. Rather, if a property is
required to understand a message, it should be communicated in
- the message, or be made available by some other means(e.g., being
- referenced by a URI in the message) rather than communicated as a
- policy element.
- </p><p>If the messages could not be made self describing by utilizing
- additional properties present in the message as required by the assertion, it would be
- necessary to determine the behaviors engaged at runtime by
- additional means. A general protocol that aids in determining
- such behaviors may be utilized, however a standard protocol for
- this purpose is currently not available to ensure
- interoperability. Thus, a private protocol should be used with
- care. Another alternative is to use
- of the assertion to selectively apply to subjects. For example, creating a separate endpoint to ensure
- engagement of the behavior is an option that can be
- considered as an alternate approach when messages can not be self describing.
+ the message, or be made available by some other means (e.g., being
+ referenced by a URI in the message) instead of being communicated as a
+ policy element.
+ </p><p>For example, if the details of a
+ message's encryption ( e.g., the cipher used, etc) are expressed
+ in policy that isn't attached to the message, it isn't possible
+ to later decipher it. This is very different from expressing, in
+ policy, what ciphers (and so forth) are supported by a particular
+ endpoint, or those that are required in a particular message; the
+ latter are the intended uses of the WS-Policy framework.
+ </p><p>As a result, the assertion authors
+ should take into account that the following important concepts
+ when designing assertions and documenting the semantics of the
+ assertion types. Firstly, an assertion type indicates a
+ <em>runtime</em> behavior. Secondly, an assertion should
+ also indicate how the assertion type can be inferred or indicated
+ from a message at runtime. If there is a need for the behavior
+ to be represented in a persistent way or if there is a need for
+ additional data or metadata that is present in a message to be
+ persisted, it should be incorporated into the assertion design or
+ in the message itself. In essence, the assertion authors should
+ consider how to make messages self describing when utilizing
+ their assertions by specifying additional properties, headers,
+ etc. that must be present in a message as part of their assertion
+ design.
+ </p><p>If the messages could not be made
+ self describing by utilizing additional properties present in the
+ message as required by the assertion, it would be necessary to
+ determine the behaviors engaged at runtime by additional means. A
+ general protocol that aids in determining such behaviors may be
+ utilized, however a standard protocol for this purpose is
+ currently not available to ensure interoperability. Thus, a
+ private protocol should be used with care. </p><p>Another approach is to use of the
+ assertion to selectively apply to subjects. For example, a
+ dedicated endpoint may be allocated to ensure the engagement of a
+ behavior that is expressed by a policy assertion. This approach
+ can be considered when messages can not be self describing.
</p></div><div class="div2">
-<h3><a name="optional-policy-assertion"></a>5.7 Optional Policy Assertion</h3><p>Optional assertions represent behaviors which may be
+<h3><a name="optional-policy-assertion"></a>5.5 Optional Policy Assertion</h3><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,
@@ -630,8 +649,8 @@
how the capability that is enabled by the assertion would be
engaged when they are designing their assertion, whether by
specific headers or some other means. </p></li></ul></div><div class="div2">
-<h3><a name="considerations-for-intersection"></a>5.8 Considerations for Intersection and Merging </h3></div><div class="div2">
-<h3><a name="typing-assertions"></a>5.9 Typing Assertions</h3><p>Since a <em>QName</em> is the central mechanism for
+<h3><a name="considerations-for-intersection"></a>5.6 Considerations for Intersection and Merging </h3></div><div class="div2">
+<h3><a name="typing-assertions"></a>5.7 Typing Assertions</h3><p>Since a <em>QName</em> is the central mechanism for
identifying a policy assertion, assertion authors should be
aware of the possible evolution of their assertions and how
this would impact the semantics overtime. A namespace
@@ -662,7 +681,7 @@
the definition of other domain expressions to be policy
subjects. More of this topic is covered in the <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>
</p><div class="exampleOuter"><p>EXAMPLE</p></div></div><div class="div2">
-<h3><a name="levels-of-abstraction"></a>5.10 Levels of Abstraction in WSDL </h3><p>A behavior identified by a policy assertion applies to the
+<h3><a name="levels-of-abstraction"></a>5.8 Levels of Abstraction in WSDL </h3><p>A behavior identified by a policy assertion applies to the
associated policy subject. If a policy assertion is to be used
within WSDL, policy assertion authors must specify a WSDL
policy subject. The policy subject is determined with respect
@@ -736,9 +755,9 @@
policy assertions do not target wire-level behaviors but
rather abstract requirements, this technique does not
apply. </p></div><div class="div2">
-<h3><a name="lifecycle"></a>5.11 Lifecycle of Assertions</h3><p>WS-Policy authors need to consider not just the expression of the current set of requirements but
+<h3><a name="lifecycle"></a>5.9 Lifecycle of Assertions</h3><p>WS-Policy 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></li><li><p> Subject attachment Extensibility </p></li></ul><div class="div3">
-<h4><a name="Referencing_Policy_Expressions"></a>5.11.1 Referencing Policy Expressions</h4><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> illustrates how
+<h4><a name="Referencing_Policy_Expressions"></a>5.9.1 Referencing Policy Expressions</h4><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> illustrates how
providers can
utilize the identification mechanism defined in the Policy specification
to expose a complex policy expression as a reusable building block for
@@ -753,8 +772,8 @@
manageability of the expressions as they are uniquely
identified.
</p></div><div class="div3">
-<h4><a name="extending-assertions"></a>5.11.2 Factors in Extending Assertions within a Domain </h4><p> Extensibility affects the policy subjects and attachment semantics. </p></div><div class="div3">
-<h4><a name="assertion-evolution"></a>5.11.3 Evolution of Assertions (Versioning and Compatibility)</h4><p>4.4.7. Over time, there may
+<h4><a name="extending-assertions"></a>5.9.2 Factors in Extending Assertions within a Domain </h4><p> Extensibility affects the policy subjects and attachment semantics. </p></div><div class="div3">
+<h4><a name="assertion-evolution"></a>5.9.3 Evolution of Assertions (Versioning and Compatibility)</h4><p>4.4.7. Over time, there may
be multiple equivalent behaviors emerging in the Web
Service interaction space. Examples of such multiple
equivalent behaviors are WSS: SOAP Message Security 1.0
@@ -857,7 +876,7 @@
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>
<Policy URI=http://www.CompanyA.com/WebServicesProfileA.xml>
<wsa:UsingAddressing />
- <sp:TransportBinding></spTransportBinding>
+ <sp:TransportBinding></sp:TransportBinding>
</Policy></pre></div></div><p>The <code>sp:TransportBinding</code> element is a policy assertion. The
assertion identifies the use of transport-level-security - such
as HTTPS for protecting messages at the transport
@@ -909,17 +928,19 @@
<wsa:UsingAddressing />
<ExactlyOne>
<sp:TransportBinding>
- <sp:TransportToken>
- <Policy>
- <sp:HttpsToken RequireClienCertificate="false" />
- </Policy>
- </sp:TransportToken>
- <sp:AlgorithmSuite>
<Policy>
- <sp:Basic256Rsa15 />
+ <sp:TransportToken>
+ <Policy>
+ <sp:HttpsToken RequireClienCertificate="false" />
+ </Policy>
+ </sp:TransportToken>
+ <sp:AlgorithmSuite>
+ <Policy>
+ <sp:Basic256Rsa15 />
+ </Policy>
+ </sp:AlgorithmSuite>
</Policy>
- </spAlgorithmSuite>
- </sp:TransportBinding>
+ </sp:TransportBinding>
<sp:AsymmetricBinding>
</sp:AssymetricBinding>
</ExactlyOne>
@@ -964,22 +985,22 @@
<wsa:UsingAddressing />
<ExactlyOne>
<sp:TransportBinding>
- <sp:TransportToken>
+ <Policy>
+ <sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken RequireClienCertificate="false" />
- </wsp:Policy>
- </sp:TransportToken>
- <sp:AlgorithmSuite>
- <wsp:Policy>
- <sp:Basic256Rsa15 />
- </wsp:Policy>
- </spAlgorithmSuite>
- </sp:TransportBinding>
+ </wsp:Policy>
+ </sp:TransportToken>
+ <sp:AlgorithmSuite>
+ <wsp:Policy>
+ <sp:Basic256Rsa15 />
+ </wsp:Policy>
+ </spAlgorithmSuite>
+ </Policy>
+ </sp:TransportBinding>
<sp:AsymmetricBinding>
-
-</sp:AssymetricBinding>
+ </sp:AssymetricBinding>
</ExactlyOne>
-
</wsp:Policy>
<wsdl:binding name="CompanyADefaultBinding" type="tns:CompanyADefault">
@@ -1146,4 +1167,4 @@
</p></div><div class="div1">
<h2><a name="change-description"></a>E. Changes in this Version of
the Document (Non-Normative)</h2><p>A list of substantive changes since the previous publication is below:</p><ul><li><p>TBD</p></li></ul></div><div class="div1">
-<h2><a name="change-log"></a>F. Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log (Non-Normative)</h2><a name="ws-policy-primer-changelog-table"></a><table border="1"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Author</th><th rowspan="1" colspan="1">Description</th></tr><tr><td rowspan="1" colspan="1">20060829</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Created first draft based on agreed outline and content</td></tr><tr><td rowspan="1" colspan="1">20061013</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Editorial fixes (suggested by Frederick), fixed references, bibl items, fixed dangling pointers, created eds to do</td></tr><tr><td rowspan="1" colspan="1">20061018</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Editorial fixes for readability, added example for Encrypted parts</td></tr><tr><td rowspan="1" colspan="1">20061030</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspa="1">Fixes for Paul Cotton's editorial comments (20061020)</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
+<h2><a name="change-log"></a>F. Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log (Non-Normative)</h2><a name="ws-policy-primer-changelog-table"></a><table border="1"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Author</th><th rowspan="1" colspan="1">Description</th></tr><tr><td rowspan="1" colspan="1">20060829</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Created first draft based on agreed outline and content</td></tr><tr><td rowspan="1" colspan="1">20061013</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Editorial fixes (suggested by Frederick), fixed references, bibl items, fixed dangling pointers, created eds to do</td></tr><tr><td rowspan="1" colspan="1">20061018</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Editorial fixes for readability, added example for Encrypted parts</td></tr><tr><td rowspan="1" colspan="1">20061030</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspa="1">Fixes for Paul Cotton's editorial comments (20061020)</td></tr><tr><td rowspan="1" colspan="1">20061031</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Fixes for Frederick's editorial comments (20061025)</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Received on Wednesday, 1 November 2006 01:18:52 UTC