W3C home > Mailing lists > Public > public-ws-policy-eds@w3.org > November 2006

2006/ws/policy ws-policy-guidelines.html,1.5,1.6

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
Message-Id: <E1Gf4kb-0006BB-E8@lionel-hutz.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>&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#assertion-roles">Roles and Responsibilities in Utilizing Policy Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.1 <a href="#domain-owners"> WS-Policy Authors</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.2 <a href="#consumers">Consumers</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.3 <a href="#providers">Providers</a><br>3. <a href="#general-guidelines">General Guidelines for WS-Policy Assertion Authors</a><br>&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;&nbsp;5.1 <a href="#new-domains">New Policy Domains</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.2 <a href="single-domains">Single Domains</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.3 <a href="#nested-assertions">Nested Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.4 <a href="#parameterized-assertions">Assertions with Parameters</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.5 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.6 <a href="#self-describing"> Self Describing Messages </a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.7 <a href="#optional-policy-assertion">Optional Policy Assertion</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.8 <a href="#considerations-for-intersection"> Considerations for Intersection and Merging </a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.9 <a href="#typing-assertions">Typing Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.10 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.11 <a href="#lifecycle">Lifecycle of Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.11.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressons</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.11.2 <a href="#extending-assertions"> Factors in Extending Assertions within a Domain </a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;&nbsp;7.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br>&nbsp;&nbsp;&nbsp;&nbsp;7.2 <a href="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.2.1 <a href="#interaction">Interaction between Subjects</a><br>&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#assertion-roles">Roles and Responsibilities in Utilizing Policy Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.1 <a href="#domain-owners"> WS-Policy Authors</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.2 <a href="#consumers">Consumers</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.3 <a href="#providers">Providers</a><br>3. <a href="#general-guidelines">General Guidelines for WS-Policy Assertion Authors</a><br>&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;&nbsp;5.1 <a href="#new-domains">New Policy Domains</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.2 <a href="single-domains">Single Domains</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.3 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.3.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.3.2 <a href="#nested-assertions">Nested Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.3.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.4 <a href="#self-describing"> Self Describing Messages </a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.5 <a href="#optional-policy-assertion">Optional Policy Assertion</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.6 <a href="#considerations-for-intersection"> Considerations for Intersection and Merging </a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.7 <a href="#typing-assertions">Typing Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;5.8 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>&nbsp;&nbsp;&nsp;&nbsp;5.9 <a href="#lifecycle">Lifecycle of Assertions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.9.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.9.2 <a href="#extending-assertions"> Factors in Extending Assertions within a Domain </a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;&nbsp;7.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br>&nbsp;&nbsp;&nbsp;&nbsp;7.2 <a href="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.2.1 <a href="#interaction">Interaction betwen Subjects</a><br>&nbsp;&nbsp;&nbsp;&nbsp;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>&lt;Policy&gt;
+  &lt;sp:SignedParts&gt;
+    &lt;sp:Body /&gt;
+    &lt;sp:Header /&gt;
+  &lt;/sp:SignedParts&gt;
+&lt;/Policy&gt;</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>&lt;sp:TransportBinding&gt;
+        </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>&lt;sp:TransportBinding&gt;
   &lt;Policy&gt;
     &lt;sp:TransportToken&gt;
       &lt;Policy&gt;
@@ -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>&lt;Policy&gt;
-  &lt;sp:SignedParts&gt;
-    &lt;sp:Body /&gt;
-    &lt;sp:Header /&gt;
-  &lt;/sp:SignedParts&gt;
-&lt;/Policy&gt;</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>
 &lt;Policy URI=http://www.CompanyA.com/WebServicesProfileA.xml&gt; 
 	&lt;wsa:UsingAddressing /&gt;
-	&lt;sp:TransportBinding&gt;&lt;/spTransportBinding&gt;
+	&lt;sp:TransportBinding&gt;&lt;/sp:TransportBinding&gt;
 &lt;/Policy&gt;</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 @@
 	&lt;wsa:UsingAddressing /&gt;
 	&lt;ExactlyOne&gt;
 	   &lt;sp:TransportBinding&gt;
-   	 &lt;sp:TransportToken&gt;
-		   &lt;Policy&gt;
-		      &lt;sp:HttpsToken RequireClienCertificate="false" /&gt;
-              &lt;/Policy&gt;
-            &lt;/sp:TransportToken&gt;
-            &lt;sp:AlgorithmSuite&gt;
               &lt;Policy&gt;
-		      &lt;sp:Basic256Rsa15 /&gt;
+   	         &lt;sp:TransportToken&gt;
+		    &lt;Policy&gt;
+		      &lt;sp:HttpsToken RequireClienCertificate="false" /&gt;
+                    &lt;/Policy&gt;
+                 &lt;/sp:TransportToken&gt;
+                 &lt;sp:AlgorithmSuite&gt;
+                    &lt;Policy&gt;
+		       &lt;sp:Basic256Rsa15 /&gt;
+                    &lt;/Policy&gt;
+                 &lt;/sp:AlgorithmSuite&gt;
               &lt;/Policy&gt;
-            &lt;/spAlgorithmSuite&gt;
-       &lt;/sp:TransportBinding&gt;
+        &lt;/sp:TransportBinding&gt;
 	   &lt;sp:AsymmetricBinding&gt;
   &lt;/sp:AssymetricBinding&gt;
 	&lt;/ExactlyOne&gt;
@@ -964,22 +985,22 @@
 	&lt;wsa:UsingAddressing /&gt;
 	&lt;ExactlyOne&gt;
 	   &lt;sp:TransportBinding&gt;
-     	 &lt;sp:TransportToken&gt;
+              &lt;Policy&gt;
+     	         &lt;sp:TransportToken&gt;
 		   &lt;wsp:Policy&gt;
 		      &lt;sp:HttpsToken RequireClienCertificate="false" /&gt;
-              &lt;/wsp:Policy&gt;
-            &lt;/sp:TransportToken&gt;
-            &lt;sp:AlgorithmSuite&gt;
-              &lt;wsp:Policy&gt;
-		      &lt;sp:Basic256Rsa15 /&gt;
-              &lt;/wsp:Policy&gt;
-            &lt;/spAlgorithmSuite&gt;
-       &lt;/sp:TransportBinding&gt;
+                   &lt;/wsp:Policy&gt;
+                 &lt;/sp:TransportToken&gt;
+                 &lt;sp:AlgorithmSuite&gt;
+                    &lt;wsp:Policy&gt;
+		       &lt;sp:Basic256Rsa15 /&gt;
+                    &lt;/wsp:Policy&gt;
+                 &lt;/spAlgorithmSuite&gt;
+              &lt;/Policy&gt;
+           &lt;/sp:TransportBinding&gt;
 	   &lt;sp:AsymmetricBinding&gt;
-
-&lt;/sp:AssymetricBinding&gt;
+           &lt;/sp:AssymetricBinding&gt;
 	&lt;/ExactlyOne&gt;
-
 &lt;/wsp:Policy&gt;
 
 &lt;wsdl:binding name="CompanyADefaultBinding" type="tns:CompanyADefault"&gt; 
@@ -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 GMT

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