- From: Prasad Yendluri via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 19 Mar 2007 17:44:48 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv21945
Modified Files:
ws-policy-primer.html
Log Message:
Implemented the resolution for issue 4103. Editors' action 193.
Index: ws-policy-primer.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.html,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -d -r1.44 -r1.45
--- ws-policy-primer.html 16 Mar 2007 04:58:46 -0000 1.44
+++ ws-policy-primer.html 19 Mar 2007 17:44:46 -0000 1.45
@@ -161,8 +161,8 @@
<h3><a name="simple-message" id="simple-message"></a>2.2 Simple Message</h3><p>Let us start by considering a SOAP Message in the example below.</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 2-1. </span>SOAP Message</i></p><div class="exampleInner"><pre><soap:Envelope>
<soap:Header>
- <wsa:To>http://stock.contoso.com/realquote</wsa:To>
- <wsa:Action>http://stock.contoso.com/GetRealQuote</wsa:Action>
+ <wsa:To>http://x.example.com/realquote</wsa:To>
+ <wsa:Action>http://x.example.com/GetRealQuote</wsa:Action>
</soap:Header>
<soap:Body>...</soap:Body>
</soap:Envelope></pre></div></div><p>This message uses message addressing headers. The <code>wsa:To</code>
@@ -171,9 +171,9 @@
the Web Services Addressing XML Namespace. <a href="#xml-namespaces"><b>B. XML Namespaces</b></a> lists all the
namespaces and prefixes that are used in this document.)</p><p>Let us look at a fictitious scenario used in this document to illustrate the features of
the policy language. A Web service developer is building a client application
- that retrieves real time stock quote information from Contoso, Ltd. Contoso supplies real
- time data using Web services. The developer has Contoso’s advertised WSDL description of these Web
- services. Contoso requires the use of addressing headers for messaging. Just the WSDL
+ that retrieves real time stock quote information from Company-X, Ltd. Company-X supplies real
+ time data using Web services. The developer has Company-X’s advertised WSDL description of these Web
+ services. Company-X requires the use of addressing headers for messaging. Just the WSDL
description is not sufficient for the developer to enable the interaction between her client and
these Web services. WSDL constructs do not indicate requirements such as the use of
addressing.</p><p>(<em>The example companies, organizations, products, domain names, e-mail addresses,
@@ -181,21 +181,21 @@
any real company, organization, product, domain name, email address, logo, person,
places, or events is intended or should be inferred.</em>)</p><p>Providers have the option to convey requirements, such as the use of addressing, through
word-of-mouth and documentation – as they always have. To interact successfully with this
- service, the developer may have to read any related documentation, call someone at Contoso to
+ service, the developer may have to read any related documentation, call someone at Company-X to
understand the service metadata, or look at sample SOAP messages and infer such
requirements or behaviors.</p><p>Web Services Policy is a machine-readable language for representing these Web service
capabilities and requirements as policies. Policy makes it possible for providers to
represent such capabilities and requirements in a machine-readable form. For example,
- Contoso may augment the service WSDL description with a policy that requires the use of
+ Company-X may augment the service WSDL description with a policy that requires the use of
addressing. The client application developer can use a policy-aware client that understands this policy and engages
- addressing automatically.</p><p>How does Contoso use policy to represent the use of addressing? The example below
+ addressing automatically.</p><p>How does Company-X use policy to represent the use of addressing? The example below
illustrates a policy expression that requires the use of addressing.</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 2-2. </span>Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<wsap:UsingAddressing />
</Policy></pre></div></div><p>
The policy expression in the above example consists of a Policy main
element and a child element wsap:UsingAddressing. Child elements of
- the Policy element are policy assertions. Contoso attaches the above
+ the Policy element are policy assertions. Company-X attaches the above
policy expression to a WSDL binding description.
</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 2-3. </span>Policy Expression Attached to Binding</i></p><div class="exampleInner"><pre><wsdl:binding name="AddressingBinding" type="tns:RealTimeDataInterface" >
@@ -217,7 +217,7 @@
reference WSDL constructs (such as port, binding and portType), Web Services Policy does
not require a message to reference a policy expression though the policy expression
describes the message.</p></div><div class="div2">
-<h3><a name="secure-message" id="secure-message"></a>2.3 Secure Message</h3><p>In addition to requiring the use of addressing, Contoso requires the use of
+<h3><a name="secure-message" id="secure-message"></a>2.3 Secure Message</h3><p>In addition to requiring the use of addressing, Company-X requires the use of
transport-level security for protecting messages.</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 2-4. </span>Secure Message</i></p><div class="exampleInner"><pre><soap:Envelope>
<soap:Header>
@@ -227,15 +227,15 @@
<wsu:Expires>2006-01-19T02:54:53.914Z</u:Expires>
</wsu:Timestamp>
</wss:Security>
- <wsa:To>http://real.contoso.com/quote</wsa:To>
- <wsa:Action>http://real.contoso.com/GetRealQuote</wsa:Action>
+ <wsa:To>http://x.example.com/quote</wsa:To>
+ <wsa:Action>http://x.example.com/GetRealQuote</wsa:Action>
</soap:Header>
<soap:Body>...</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. Contoso requires the use of security timestamps and
+ and expiration times of this message. Company-X requires the use of security timestamps and
transport-level security - such as <code>HTTPS</code> – for protecting messages. (The
prefixes <code>wss</code> and <code>wsu</code> are used here to denote the Web Services
- Security and Utility namespaces.)</p><p>Similar to the use of addressing, Contoso indicates the use of transport-level security
+ Security and Utility namespaces.)</p><p>Similar to the use of addressing, Company-X indicates the use of transport-level security
using a policy expression. The example below illustrates a policy expression that requires
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 2-5. </span>Addressing and Security Policy Expression</i></p><div class="exampleInner"><pre><Policy>
@@ -249,13 +249,13 @@
SOAP Envelopes.</p><p>The client application developer can use a policy-aware client that recognizes this policy expression and engages
both addressing and transport-level security automatically.</p><p>For the moment, let us set aside the contents of the <code>sp:TransportBinding</code>
policy assertion and consider its details in a later section.</p></div><div class="div2">
-<h3><a name="other-assertions" id="other-assertions"></a>2.4 Other Assertions</h3><p>Thus far, we explored how Contoso uses policy expressions and assertions for representing
+<h3><a name="other-assertions" id="other-assertions"></a>2.4 Other Assertions</h3><p>Thus far, we explored how Company-X uses policy expressions and assertions for representing
behaviors that must be engaged for a Web service interaction. What is a policy assertion?
What role does it play? In brief, a policy assertion is a piece of service metadata, and
it identifies a domain (such as messaging, security, reliability and transaction) specific
- behavior that is a requirement. Contoso uses a policy assertion to convey a condition
+ behavior that is a requirement. Company-X uses a policy assertion to convey a condition
under which they offer a Web service. A policy-aware client can recognize policy
- assertions and engage these behaviors automatically.</p><p>Providers, like Contoso, have the option to combine behaviors for an interaction from
+ assertions and engage these behaviors automatically.</p><p>Providers, like Company-X, have the option to combine behaviors for an interaction from
domains such as messaging, security, reliability and transactions. Using policy
assertions, providers can represent these behaviors in a machine-readable form. Web
service developers can use policy-aware clients that recognize these
@@ -284,17 +284,17 @@
<p style="text-align: left" class="exampleHead"><i><span>Example 2-6. </span>Addressing and Security Policy Expression</i></p><div class="exampleInner"><pre><All>
<wsap:UsingAddressing />
<sp:TransportBinding>…</sp:TransportBinding>
-</All></pre></div></div><p>In addition to requiring the use of addressing, Contoso allows either the use of
+</All></pre></div></div><p>In addition to requiring the use of addressing, Company-X allows either the use of
transport- or message-level security for protecting messages. Web Services Policy language
can indicate this choice of behaviors in a machine-readable form. To indicate the use of
- message-level security for protecting messages, Contoso uses the
+ message-level security for protecting messages, Company-X uses the
<code>sp:AsymmetricBinding</code> policy assertion (see the example below).</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 2-7. </span>Asymmetric Binding Security Policy Assertion</i></p><div class="exampleInner"><pre><sp:AsymmetricBinding>…</sp:AsymmetricBinding></pre></div></div><p>The <code>sp:AsymmetricBinding</code> element is a policy assertion. (The prefix
<code>sp</code> is used here to denote the Web Services Security Policy namespace.) This
assertion identifies the use of message-level security – such as <em>WS-Security
1.0</em> - for protecting messages. Policy-aware clients can recognize this policy
assertion, engage message-level security for protecting messages and use headers such
- as <code>wss:Security</code> in SOAP Envelopes.</p><p>To allow the use of either transport- or message-level security, Contoso uses the
+ as <code>wss:Security</code> in SOAP Envelopes.</p><p>To allow the use of either transport- or message-level security, Company-X uses the
<code>ExactlyOne</code> policy operator. Policy assertions combined using the
<code>ExactlyOne</code> operator requires exactly one of the behaviors represented by
the assertions. The policy expression in the example below requires the use of either
@@ -302,7 +302,7 @@
<p style="text-align: left" class="exampleHead"><i><span>Example 2-8. </span>Transport- or Message-Level Security Policy Expression</i></p><div class="exampleInner"><pre><ExactlyOne>
<sp:TransportBinding>…</sp:TransportBinding>
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
-</ExactlyOne></pre></div></div><p>Contoso requires the use of addressing and requires the use of either transport- or
+</ExactlyOne></pre></div></div><p>Company-X requires the use of addressing and requires the use of either transport- or
message-level security for protecting messages. They represent this combination using
the <code>All</code> and <code>ExactlyOne</code> operators. Policy operators can be mixed
to represent different combinations of behaviors (capabilities and requirements). The
@@ -314,13 +314,13 @@
<sp:TransportBinding>…</sp:TransportBinding>
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
</ExactlyOne>
-</All></pre></div></div><p>Using this policy expression, Contoso gives the choice of mechanisms for protecting
+</All></pre></div></div><p>Using this policy expression, Company-X gives the choice of mechanisms for protecting
messages to clients (or requesters).</p></div><div class="div2">
-<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>2.6 Optional Policy Assertion</h3><p>Through a customer survey program, Contoso learns that a significant number of their
+<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>2.6 Optional Policy Assertion</h3><p>Through a customer survey program, Company-X learns that a significant number of their
customers prefer to use the Optimized MIME Serialization (as defined in the MTOM
- specification) for sending and receiving messages. Contoso adds optional support for the
+ specification) for sending and receiving messages. Company-X adds optional support for the
Optimized MIME Serialization and expresses this optional behavior in a machine-readable
- form.</p><p>To indicate the use of optimization using the Optimized MIME Serialization, Contoso uses
+ form.</p><p>To indicate the use of optimization using the Optimized MIME Serialization, Company-X uses
the <code>mtom:OptimizedMimeSerialization</code> policy assertion (see the example below).</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 2-10. </span>Optimized MIME Serialization Policy Assertion</i></p><div class="exampleInner"><pre><mtom:OptimizedMimeSerialization /></pre></div></div><p>The <code>mtom:OptimizedMimeSerialization</code> element is a policy assertion. (The
prefix <code>mtom</code> is used here to denote the Optimized MIME Serialization Policy
@@ -328,7 +328,7 @@
as required for request and response
messages. Policy-aware clients can recognize this policy assertion and engage Optimized
MIME Serialization for messages. The semantics of this assertion are reflected in
- messages: they use an optimized wire format (MIME Multipart/Related serialization).</p><p>Like Contoso’s optional support for Optimized MIME Serialization, there are behaviors
+ messages: they use an optimized wire format (MIME Multipart/Related serialization).</p><p>Like Company-X’s optional support for Optimized MIME Serialization, there are behaviors
that may be engaged (in contrast to must be engaged) for a Web service interaction. A
service provider will not fault if these behaviors are not engaged. Policy assertions can
be marked optional to represent behaviors that may be engaged for an interaction. A policy
@@ -351,7 +351,7 @@
<sp:TransportBinding>…</sp:TransportBinding>
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
</ExactlyOne>
-</All></pre></div></div><p>Contoso is able to meet their customer needs by adding optional support for the Optimized MIME
+</All></pre></div></div><p>Company-X is able to meet their customer needs by adding optional support for the Optimized MIME
Serialization. Optional support is outlined in section 3.4 Web Services Policy 1.5 - Framework and
detailed in section 4.5.2, Web Services Policy 1.5 - Guidelines for Policy Assertion Authors, specifically for Optimized MIME Serialization.
An optional policy assertion represents a behavior that may be engaged. When a
@@ -360,12 +360,12 @@
about the absence of that policy assertion. See section
<a href="#attaching-policy-expressions-to-wsdl"><b>2.11 Attaching Policy Expressions to WSDL</b></a> on the absence of policy expressions.</p></div><div class="div2">
<h3><a name="ignorable-policy-assertions" id="ignorable-policy-assertions"></a>2.7 Ignorable Policy Expressions</h3><p>
- Suppose Contoso decides that it will log SOAP messages sent and received in an exchange.
+ Suppose Company-X decides that it will log SOAP messages sent and received in an exchange.
This behavior has no direct impact on the messages sent on the wire, and does not affect interoperability.
- Some parties might have a concern about such logging and might decide not to interact with Contoso knowing
- that such logging is performed. To address this concern, Contoso includes a Logging assertion in its policy to enable
+ Some parties might have a concern about such logging and might decide not to interact with Company-X knowing
+ that such logging is performed. To address this concern, Company-X includes a Logging assertion in its policy to enable
such parties to be aware of logging. By marking the Logging assertion with the <code>wsp:Ignorable</code> attribute with a
- value of "true" Contoso indicates that a requester may choose to either ignore such assertions or to consider
+ value of "true" Company-X indicates that a requester may choose to either ignore such assertions or to consider
them as part of policy intersection. An assertion that may be ignored for policy intersection is called an
ignorable assertion.
</p><p>
@@ -397,10 +397,10 @@
two alternatives; one where the assertion A exists with @wsp:Ignorable=true and the
second where the assertion A does not exist.</p></div><div class="div2">
<h3><a name="nested-policy-expressions" id="nested-policy-expressions"></a>2.9 Nested Policy Expressions</h3><p>In the previous sections, we considered two security policy assertions. In this section,
- let us look at one of the security policy assertions in little more detail.</p><p>As you would expect, securing messages is a complex usage scenario. Contoso uses the
+ let us look at one of the security policy assertions in little more detail.</p><p>As you would expect, securing messages is a complex usage scenario. Company-X uses the
<code>sp:TransportBinding</code> policy assertion to indicate the use of transport-level
security for protecting messages. Just indicating the use of transport-level security for
- protecting messages is not sufficient. To successfully interact with Contoso’s Web
+ protecting messages is not sufficient. To successfully interact with Company-X’s Web
services, the developer must know what transport token to use, what secure transport to use, what
algorithm suite to use for performing cryptographic operations, etc. The
<code>sp:TransportBinding</code> policy assertion can represent these dependent
@@ -408,7 +408,7 @@
machine-readable form.</p><p>A policy assertion – like the <code>sp:TransportBinding</code> - identifies a visible
domain specific behavior that is a requirement. Given an assertion, there may be other
dependent behaviors that need to be enumerated for a Web Service interaction. In the case
- of the <code>sp:TransportBinding</code> policy assertion, Contoso needs to identify the
+ of the <code>sp:TransportBinding</code> policy assertion, Company-X needs to identify the
use of a transport token, a secure transport, an algorithm suite for performing
cryptographic operations, etc. A nested policy expression can be used to enumerate such
dependent behaviors.</p><p>What is a nested policy expression? A nested policy expression is a policy expression
@@ -443,12 +443,27 @@
can use a policy-aware client that recognizes this policy assertion and engages
transport-level security and its 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="Referencing_Policy_Expressions" id="Referencing_Policy_Expressions"></a>2.10 Referencing Policy Expressions</h3><p>Contoso has numerous Web service offerings that provide different kinds of real-time
+ Web service developers.</p><p> In another example, WS-Security Policy defines a sp:HttpToken assertion to
+ contain three possible nested elements, sp:HttpBasicAuthentication, sp:HttpDigestAuthentication
+ and sp:RequireClientCertificate. When the HttpToken is used with an empty nested policy in a
+ policy expression by a provider, it will indicate that none of the dependent behaviors namely
+ authentication or client certificate is required. A non-anonymous client who requires authentication
+ or client certificate will not be able to use this provider solely on the basis of intersection algorithm alone.
+<div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-14. </span> Empty Nested Assertion </i></p><div class="exampleInner"><pre><sp:TransportToken>
+ <wsp:Policy>
+ <sp:HttpsToken>
+ <wsp:Policy/>
+ </sp:HttpsToken>
+ </wsp:Policy>
+</sp:TransportToken>
+</pre></div></div>
+ </p></div><div class="div2">
+<h3><a name="Referencing_Policy_Expressions" id="Referencing_Policy_Expressions"></a>2.10 Referencing Policy Expressions</h3><p>Company-X has numerous Web service offerings that provide different kinds of real-time
quotes and book information on securities such as
<code>GetRealQuote</code>, <code>GetRealQuotes</code> and
- <code>GetExtendedRealQuote</code>. To accommodate the diversity of Contoso’s customers,
- Contoso supports multiple WSDL bindings for these Web services. Contoso provides
+ <code>GetExtendedRealQuote</code>. To accommodate the diversity of Company-X’s customers,
+ Company-X supports multiple WSDL bindings for these Web services. Company-X provides
consistent ways to interact with their services and wants to represent these capabilities
and requirements consistently across all of their offerings without duplicating policy
expressions multiple times. How? It is simple - a policy expression can be named and
@@ -467,19 +482,19 @@
expression: the <code>wsu:Id</code> <code>xml:id</code> and <code>Name</code> attributes. A
<code>PolicyReference</code> element can be used to reference a policy expression
identified using either of these mechanisms.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-14. </span>Common Policy Expression</i></p><div class="exampleInner"><pre><Policy wsu:Id=”common”>
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-15. </span>Common Policy Expression</i></p><div class="exampleInner"><pre><Policy wsu:Id=”common”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
<wsap:UsingAddressing />
</Policy></pre></div></div><p>In the example above, the <code>wsu:Id</code> attribute is used to identify a policy
expression. The value of the <code>wsu:Id</code> attribute is an XML ID. The relative IRI
for referencing this policy expression (within the same document) is <code>#common</code>.
- If the policy document IRI is <code>http://real.contoso.com/policy.xml</code> then the
+ If the policy document IRI is <code>http://x.example.com/policy.xml</code> then the
absolute IRI for referencing this policy expression is
- <code>http://real.contoso.com/policy.xml#common. (</code>The absolute IRI is formed by
+ <code>http://x.example.com/policy.xml#common. (</code>The absolute IRI is formed by
combining the document IRI, <code>#</code> and the value of the <code>wsu:Id</code>
- attribute.)</p><p> In addition to the Example 2-12, Contoso could have used either the xml:id or wsu:Id.
+ attribute.)</p><p> In addition to the Example 2-12, Company-X could have used either the xml:id or wsu:Id.
An example of the use of xml:id similar to that of wsu:Id is shown in Example 2-13. </p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-15. </span>Common Policy Expression [xml:id]</i></p><div class="exampleInner"><pre><Policy xml:id=”common”>
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-16. </span>Common Policy Expression [xml:id]</i></p><div class="exampleInner"><pre><Policy xml:id=”common”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
<wsap:UsingAddressing />
</Policy></pre></div></div><p> Conditions and constraints on the use of the |xml:id| attribute in conjunction with Canonical
@@ -494,13 +509,13 @@
</p></div><p>For re-use, a <code>PolicyReference</code> element can be used to reference a policy
expression as a standalone policy or within another policy expression. The example below
is a policy expression that re-uses the common policy expression above.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-16. </span>PolicyReference to Common Policy Expression</i></p><div class="exampleInner"><pre><PolicyReference URI="#common"/></pre></div></div><p>For referencing a policy expression within the same XML document, Contoso uses the
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-17. </span>PolicyReference to Common Policy Expression</i></p><div class="exampleInner"><pre><PolicyReference URI="#common"/></pre></div></div><p>For referencing a policy expression within the same XML document, Company-X uses the
<code>wsu:Id</code> attribute for identifying a policy expression and an IRI to this ID
value for referencing this policy expression using a <code>PolicyReference</code> element.</p><p>The example below is a policy expression that re-uses the common policy expression within
another policy expression. This policy expression requires the use of addressing, one of
transport- or message-level security for protecting messages and allows the use of
optimization.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-17. </span>Secure Policy Expression</i></p><div class="exampleInner"><pre><Policy wsu:Id=”secure”>
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-18. </span>Secure Policy Expression</i></p><div class="exampleInner"><pre><Policy wsu:Id=”secure”>
<All>
<PolicyReference URI="#common"/>
<ExactlyOne>
@@ -514,12 +529,12 @@
resides in. As such, referencing a policy expression using the <code>Name</code> attribute
relies on additional out of band information. In the example below, the <code>Name</code>
attribute identifies the policy expression. The IRI of this policy expression is
- <code>http://real.contoso.com/policy/common</code>.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-18. </span>Common Policy Expression</i></p><div class="exampleInner"><pre><Policy Name=”http://real.contoso.com/policy/common”>
+ <code>http://x.example.com/policy/common</code>.</p><div class="exampleOuter">
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-19. </span>Common Policy Expression</i></p><div class="exampleInner"><pre><Policy Name=”http://x.example.com/policy/common”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
<wsap:UsingAddressing />
</Policy></pre></div></div><p>The example below is a policy expression that re-uses the common policy expression above.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-19. </span>PolicyReference to Common Policy Expression</i></p><div class="exampleInner"><pre><PolicyReference URI="http://real.contoso.com/policy/common"/></pre></div></div><p>As policy expressions are composed from other policy expressions and
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-20. </span>PolicyReference to Common Policy Expression</i></p><div class="exampleInner"><pre><PolicyReference URI="http://x.example.com/policy/common"/></pre></div></div><p>As policy expressions are composed from other policy expressions and
assertions from different domains are used in a policy expression,
complex expressions will emerge. Naming parts of complex expressions for
reuse and building more complex policies through referencing enables
@@ -530,38 +545,38 @@
developed. Note that when a named expression has assertions that
contains parametrized expressions, care must be given to ensure that the
parameterized content is statically available to enable reuse.</p></div><div class="div2">
-<h3><a name="attaching-policy-expressions-to-wsdl" id="attaching-policy-expressions-to-wsdl"></a>2.11 Attaching Policy Expressions to WSDL</h3><p>A majority of Contoso’s customers use WSDL for building their client applications.
- Contoso leverages this usage by attaching policy expressions to the WSDL binding
+<h3><a name="attaching-policy-expressions-to-wsdl" id="attaching-policy-expressions-to-wsdl"></a>2.11 Attaching Policy Expressions to WSDL</h3><p>A majority of Company-X’s customers use WSDL for building their client applications.
+ Company-X leverages this usage by attaching policy expressions to the WSDL binding
descriptions.</p><p>In the example below, the <code>SecureBinding</code> WSDL binding description defines a
binding for an interface that provides real-time quotes and book information on
securities. (The prefixes <code>wsdl</code> and <code>tns</code> are used here to denote
the Web Services Description language XML namespace and target namespace of this WSDL
- document.) To require the use of security for these offerings, Contoso attaches the secure
+ document.) To require the use of security for these offerings, Company-X attaches the secure
policy expression in the previous section to this binding description. The WSDL
<code>binding</code> element is a common policy attachment point. The secure policy
expression attached to the <code>SecureBinding</code> WSDL binding description applies to
any message exchange associated with any <code>port</code> that supports this binding
description. This includes all the message exchanges described by operations in the
<code>RealTimeDataInterface</code>.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-20. </span>Secure Policy Expression Attached to WSDL Binding</i></p><div class="exampleInner"><pre><wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-21. </span>Secure Policy Expression Attached to WSDL Binding</i></p><div class="exampleInner"><pre><wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
<PolicyReference URI="#secure" />
<wsdl:operation name="GetRealQuote">…</wsdl:operation>
…
-</wsdl:binding></pre></div></div><p>In addition to providing real-time quotes and book information on securities, Contoso
+</wsdl:binding></pre></div></div><p>In addition to providing real-time quotes and book information on securities, Company-X
provides other kinds of data through Web services such as quotes delayed by 20 minutes and
security symbols through Web services (for example <code>GetDelayedQuote</code>,
<code>GetDelayedQuotes,</code>
- <code>GetSymbol</code> and <code>GetSymbols</code>). Contoso does not require the use of
+ <code>GetSymbol</code> and <code>GetSymbols</code>). Company-X does not require the use of
security for these services, but requires the use of addressing and allows the use of
optimization.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 2-21. </span>Open Policy Expression Attached to WSDL Binding</i></p><div class="exampleInner"><pre><wsdl:binding name="OpenBinding" type="tns:DelayedDataInterface" >
+<p style="text-align: left" class="exampleHead"><i><span>Example 2-22. </span>Open Policy Expression Attached to WSDL Binding</i></p><div class="exampleInner"><pre><wsdl:binding name="OpenBinding" type="tns:DelayedDataInterface" >
<PolicyReference URI="#common" />
<wsdl:operation name="GetDelayedQuote">…</wsdl:operation>
…
</wsdl:binding></pre></div></div><p>In the example above, the <code>OpenBinding</code> WSDL binding description defines a
binding for an interface that provides other kinds of data such as quotes delayed by 20
minutes and security symbols. To require the use of addressing and allow the use of
- optimization, Contoso attaches the common policy expression in the previous section to
+ optimization, Company-X attaches the common policy expression in the previous section to
this binding description. As we have seen in the <code>SecureBinding</code> case, the
common policy expression attached to the <code>OpenBinding</code> WSDL binding description
applies to any message exchange associated with any <code>port</code> that supports this
@@ -573,7 +588,7 @@
requirements that can be expressed as policy expressions, such as the use of addressing,
security and optimization. Or, the service may not have such capabilities and
requirements. A policy aware client should not conclude anything
- about the absence of policy expressions.</p><p>Service providers, like Contoso, can preserve and leverage their investments in WSDL and
+ about the absence of policy expressions.</p><p>Service providers, like Company-X, can preserve and leverage their investments in WSDL and
represent the capabilities and requirements of a Web service as policies. A WSDL document
may specify varying behaviors across Web service endpoints. Web service developers
can use a policy-aware client that recognizes these policy expressions in WSDL
@@ -582,7 +597,7 @@
tool and hidden from these Web service developers.</p></div><div class="div2">
<h3><a name="policy-automates-web-services-interaction" id="policy-automates-web-services-interaction"></a>2.12 Policy Automates Web Services Interaction</h3><p>As you have seen, Web Services Policy is a simple language that has four elements -
<code>Policy, All</code>, <code>ExactlyOne</code> and <code>PolicyReference</code> - and
- one attribute - <code>wsp:Optional</code>. In practice, service providers, like Contoso,
+ one attribute - <code>wsp:Optional</code>. In practice, service providers, like Company-X,
use policy expressions to represent combinations of capabilities and requirements. Web
service developers use policy-aware clients that understand policy expressions
and engage the behaviors represented by providers automatically. A sizable amount of
@@ -603,9 +618,9 @@
element plays two roles: wrapper element and operator.) Policy assertions can contain a
nested policy expression. Policy assertions can also be marked optional to represent
behaviors that may be engaged (capabilities) for an interaction. The optional marker is
- the <code>wsp:Optional</code> attribute which is placed on a policy assertion element.</p><p>Let us take a closer look at Contoso’s policy expression (see below) from the previous
+ the <code>wsp:Optional</code> attribute which is placed on a policy assertion element.</p><p>Let us take a closer look at Company-X’s policy expression (see below) from the previous
section.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-1. </span>Contoso’s Secure Policy Expression</i></p><div class="exampleInner"><pre><Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-1. </span>Company-X’s Secure Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<All>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
<wsap:UsingAddressing />
@@ -657,11 +672,11 @@
</All>
</ExactlyOne>
</Policy></pre></div></div><p>A policy expression in the compact form can be converted to the normal form. Web Services
- Policy language describes the algorithm for this conversion.</p><p>Let us re-consider Contoso’s policy expression (see the example below). Contoso requires
+ Policy language describes the algorithm for this conversion.</p><p>Let us re-consider Company-X’s policy expression (see the example below). Company-X requires
the use of addressing and either transport- or message-level security and allows the use
of optimization. This policy expression is in the compact form and has four policy
alternatives for requesters:</p><ol class="enumar"><li><p>Requires the use of addressing and transport-level security</p></li><li><p>Requires the use of addressing and message-level security</p></li><li><p>Requires the use of optimization, addressing and transport-level security and</p></li><li><p>Requires the use of optimization, addressing and message-level security.</p></li></ol><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-4. </span>Contoso’s Secure Policy Expression in Compact Form</i></p><div class="exampleInner"><pre><Policy wsu:Id=”secure”>
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-4. </span>Company-X’s Secure Policy Expression in Compact Form</i></p><div class="exampleInner"><pre><Policy wsu:Id=”secure”>
<All>
<PolicyReference URI=”#common”/>
<ExactlyOne>
@@ -674,13 +689,13 @@
<Policy wsu:Id=”common”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
<wsap:UsingAddressing />
-</Policy></pre></div></div><p>Let us look at the normal form for this policy expression. The example below is Contoso’s
+</Policy></pre></div></div><p>Let us look at the normal form for this policy expression. The example below is Company-X’s
policy expression in the normal form. As you can see, the compact form is less verbose
than the normal form. The normal form represents a policy as a collection of policy
alternatives. Each of the <code>All</code> operators is a policy alternative. There are
four policy alternatives in the normal form. These alternatives map to bullets (a) through
(d) above.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-5. </span>Contoso’s Policy Expression in Normal Form</i></p><div class="exampleInner"><pre><Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-5. </span>Company-X’s Policy Expression in Normal Form</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All> <!-- - - - - - - - - - - - - - Policy Alternative (a) -->
<wsap:UsingAddressing/>
@@ -712,7 +727,7 @@
retrieve referenced policy expressions.</p></div><div class="div2">
<h3><a name="policy-data-model" id="policy-data-model"></a>3.3 Policy Data Model</h3><p>In the previous section, we considered the normal form for policy expressions. As we
discussed, the normal form represents a policy as a collection of policy alternatives. In
- this section, let us look at the policy data model.</p><p>Contoso uses a policy to convey the conditions for an interaction. Policy-aware clients,
+ this section, let us look at the policy data model.</p><p>Company-X uses a policy to convey the conditions for an interaction. Policy-aware clients,
like the one used by the developer in our example (as explained earlier in <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>), view policy as an unordered collection of
zero or more policy alternatives. A policy alternative is an unordered collection of zero
or more policy assertions. A policy alternative represents a collection of behaviors or
@@ -752,16 +767,16 @@
alternatives.</p></li><li><p>The <code>Policy</code> wrapper element and policy alternatives which correspond to
the <code>Policy/ExactlyOne</code> element map to a policy.</p></li></ul><p>The diagram below describes this mapping from the normal form of a policy expression to
the policy data model.</p><div class="figure" style="text-align: center"><br><img src="normal-form-2-data-model.jpg" alt="Mapping from Normal Form to Policy Data Model"><p style="text-align:left"><i><span>Figure 3-2. </span>Mapping from Normal Form to Policy Data Model</i></p><br></div></div><div class="div2">
-<h3><a name="compatible-policies" id="compatible-policies"></a>3.4 Compatible Policies</h3><p>A provider, like Contoso, and a requester, like the policy-aware client used in our example, may represent
+<h3><a name="compatible-policies" id="compatible-policies"></a>3.4 Compatible Policies</h3><p>A provider, like Company-X, and a requester, like the policy-aware client used in our example, may represent
their capabilities and requirements for an interaction as policies and want to limit their
message exchanges to mutually compatible policies. Web Services Policy defines an
intersection mechanism for selecting compatible policy alternatives when there are two or
- more policies.</p><p>The example below is a copy of Contoso’s policy expression (from <a href="#normal-form-for-policy-expressions"><b>3.2 Normal Form for Policy Expressions</b></a>). As we saw before, Contoso offers four
+ more policies.</p><p>The example below is a copy of Company-X’s policy expression (from <a href="#normal-form-for-policy-expressions"><b>3.2 Normal Form for Policy Expressions</b></a>). As we saw before, Company-X offers four
policy alternatives. Of them, one of the policy alternatives requires the use of
addressing and transport-level security.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-6. </span>Contoso’s Policy Expression</i></p><div class="exampleInner"><pre><Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-6. </span>Company-X’s Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
- <All> <!-- - - - - - - - - - Contoso’s Policy Alternative (a) -->
+ <All> <!-- - - - - - - - - - Company-X’s Policy Alternative (a) -->
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (c1) -->
<wsap:UsingAddressing/>
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (c2) -->
@@ -770,7 +785,7 @@
…
</ExactlyOne>
</Policy></pre></div></div><p>The client application developer's organization requires the use of addressing and transport-level security for any
- interaction with Contoso’s Web services. The developer represents these behaviors using a policy
+ interaction with Company-X’s Web services. The developer represents these behaviors using a policy
expression illustrated in the example below in normal form. This policy expression
contains one policy alternative that requires the use of addressing and transport-level
security.</p><div class="exampleOuter">
@@ -783,10 +798,10 @@
<wsap:UsingAddressing/>
</All>
</ExactlyOne>
-</Policy></pre></div></div><p>The developer lets her policy-aware client select a compatible policy alternative in Contoso’s
+</Policy></pre></div></div><p>The developer lets her policy-aware client select a compatible policy alternative in Company-X’s
policy. How does this client select a compatible policy alternative? It is simple – it
uses the policy intersection. That is, the policy-aware client uses these two policy
- expressions (the client’s and Contoso’s) and the policy intersection to select a compatible
+ expressions (the client’s and Company-X’s) and the policy intersection to select a compatible
policy alternative for this interaction. Let us look at the details of policy
intersection.</p><p>For two policy assertions to be compatible they must have the same QName. And, if either
assertion has a nested policy, both assertions must have a nested policy and the nested
@@ -795,14 +810,14 @@
assertions have compatible nested policies. These two assertions are compatible because
they have the same QName and their nested policies are compatible.</p><p>Two policy alternatives are compatible if each policy assertion in one alternative is
compatible with a policy assertion in the other and vice-versa. For example, policy
- assertions (c1) and (c2) in Contoso’s policy alternative are compatible with policy
- assertions (t2) and (t1) in tje client’s policy alternative. Contoso’s policy alternative (a)
+ assertions (c1) and (c2) in Company-X’s policy alternative are compatible with policy
+ assertions (t2) and (t1) in tje client’s policy alternative. Company-X’s policy alternative (a)
and the client’s policy alternative are compatible because assertions in these two alternatives
are compatible.</p><p>Two policies are compatible if a policy alternative in one is compatible with a policy
- alternative in the other. For example, Contoso’s policy alternative (a) is compatible with
- the client’s policy alternative. Contoso’s policy and the client’s policy are compatible because one
- of Contoso’s policy alternative is compatible with the client’s policy alternative.</p><p>For this interaction, the developer’s policy-aware client can use policy alternative (a) to
- satisfy Contoso’s conditions or requirements.</p><p>Similarly, policy intersection can be used to check if providers expose endpoints that
+ alternative in the other. For example, Company-X’s policy alternative (a) is compatible with
+ the client’s policy alternative. Company-X’s policy and the client’s policy are compatible because one
+ of Company-X’s policy alternative is compatible with the client’s policy alternative.</p><p>For this interaction, the developer’s policy-aware client can use policy alternative (a) to
+ satisfy Company-X’s conditions or requirements.</p><p>Similarly, policy intersection can be used to check if providers expose endpoints that
conform to a standard policy. For example, a major retailer might require all their
supplier endpoints to be compatible with an agreed upon policy.</p><div class="div3">
<h4><a name="strict-lax-policy-intersection" id="strict-lax-policy-intersection"></a>3.4.1 Strict and Lax Policy Intersection</h4><p>
@@ -831,7 +846,7 @@
information from the policy data model, such as the ignorable property of a
policy assertion.
</p></div></div><div class="div2">
-<h3><a name="attaching-policy-expressions-to-wsdl2" id="attaching-policy-expressions-to-wsdl2"></a>3.5 Attaching Policy Expressions to WSDL</h3><p>In <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>, we looked into how Contoso attached
+<h3><a name="attaching-policy-expressions-to-wsdl2" id="attaching-policy-expressions-to-wsdl2"></a>3.5 Attaching Policy Expressions to WSDL</h3><p>In <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a>, we looked into how Company-X attached
their policy expressions to the WSDL <code>binding</code> element. In addition to the WSDL
<code>binding</code> element, a policy expression can be attached to other WSDL elements
such as <code>service</code>, <code>port</code>, <code>operation</code>
@@ -854,7 +869,7 @@
<code>message</code> element collectively represent the message policy subject for the
fault message. Policy expressions associated with a message policy subject apply only to
that message.</p><p>In the example below, the policy expression is attached to an endpoint policy subject.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-8. </span>Contoso’s Policy Expression Attached to WSDL binding Element</i></p><div class="exampleInner"><pre><wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-8. </span>Company-X’s Policy Expression Attached to WSDL binding Element</i></p><div class="exampleInner"><pre><wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
<PolicyReference URI="#secure" />
<wsdl:operation name="GetRealQuote">…</wsdl:operation>
…
@@ -890,7 +905,7 @@
in <a href="#Referencing_Policy_Expressions"><b>2.10 Referencing Policy Expressions</b></a>.
</p></div><div class="div2">
<h3><a name="combine-policies" id="combine-policies"></a>3.7 Combine Policies</h3><p>Multiple policy expressions may be attached to WSDL constructs. Let us consider how
- Contoso could have used multiple policy expressions in a WSDL document. In the example
+ Company-X could have used multiple policy expressions in a WSDL document. In the example
below, there are two policy expressions <code>#common2</code> and <code>#secure2</code>
attached to the <code>SecureBinding</code> WSDL binding and <code>RealTimeDataPort</code>
WSDL port descriptions.</p><div class="exampleOuter">
@@ -929,7 +944,7 @@
the <code>SecureBinding</code> WSDL binding and <code>RealTimeDataPort</code> WSDL port
descriptions. The <code>#common2</code> policy expression has two policy alternatives. The
<code>#secure2</code> policy expression has two policy alternatives. The
- combination of these two policies is equivalent to Contoso’s secure policy in <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a> and has four policy alternatives. In other
+ combination of these two policies is equivalent to Company-X’s secure policy in <a href="#basic-concepts-policy-expression"><b>2. Basic Concepts: Policy Expression</b></a> and has four policy alternatives. In other
words, the combination of two policies is the cross product of alternatives in these two
policies.</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 3-10. </span>Effective Policy of the Endpoint Policy Subject in the Previous Example</i></p><div class="exampleInner"><pre><Policy>
@@ -962,27 +977,27 @@
elements as policy assertions. The child elements of <code>wsp:PolicyReference</code> are ignored.
</p><p>The <code>PolicyReference</code> element allows element and attribute extensibility.</p><p>Web Services Policy language enables simple versioning practices that allow requesters to
continue the use of any older policy alternatives in a backward compatible manner. This
- allows service providers, like Contoso, to deploy new behaviors using additional policy
+ allows service providers, like Company-X, to deploy new behaviors using additional policy
assertions without breaking compatibility with clients that rely on any older policy
- alternatives.</p><p>The example below represents a Contoso version 1 policy expression. This expression
+ alternatives.</p><p>The example below represents a Company-X version 1 policy expression. This expression
requires the use of addressing and transport-level security for protecting messages. </p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-11. </span>Contoso’s Version 1 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-11. </span>Company-X’s Version 1 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All>
<wsap:UsingAddressing/>
<sp:TransportBinding>…</sp:TransportBinding>
</All>
</ExactlyOne>
-</Policy></pre></div></div><p>Over time, Contoso adds support for advanced behaviors: requiring the use of addressing
+</Policy></pre></div></div><p>Over time, Company-X adds support for advanced behaviors: requiring the use of addressing
and message-level security for protecting messages. They added this advanced support
without breaking compatibility with requesters that rely on addressing and transport-level
- security. The example below is Contoso’s version 2 policy expression. In this version,
- Contoso’s adds a new policy alternative that requires the use of addressing and
+ security. The example below is Company-X’s version 2 policy expression. In this version,
+ Company-X’s adds a new policy alternative that requires the use of addressing and
message-level security. The clients that rely on addressing and transport-level security
- may continue to interact with Contoso’s using the old policy alternative. Of course, these
+ may continue to interact with Company-X’s using the old policy alternative. Of course, these
clients have the option to migrate from using old policy alternatives to new policy
alternatives.</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-12. </span>Contoso’s Version 2 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-12. </span>Company-X’s Version 2 Policy Expression</i></p><div class="exampleInner"><pre><Policy>
<ExactlyOne>
<All>
<wsap:UsingAddressing/>
@@ -993,7 +1008,7 @@
<sp:AsymmetricBinding>…</sp: AsymmetricBinding >
</All>
</ExactlyOne>
-</Policy></pre></div></div><p>When Contoso added support for advanced behaviors, they spent time to plan for the
+</Policy></pre></div></div><p>When Company-X added support for advanced behaviors, they spent time to plan for the
continued support for existing clients, the smooth migration from using current to
advanced behaviors, and the switch to use only the advanced behaviors in the near future
(i.e. sun-setting current behaviors). In this versioning scenario, policy can be used to
@@ -1001,7 +1016,7 @@
to existing clients are required and these clients can smoothly migrate to new
functionality when they choose to. This level of versioning support in policy enables the
same class of versioning best practices built into WSDL constructs such as service, port
- and binding.</p><p>Let us look at tooling for unknown policy assertions. As service providers, like Contoso,
+ and binding.</p><p>Let us look at tooling for unknown policy assertions. As service providers, like Company-X,
incrementally deploy advanced behaviors, some requesters may not recognize these new
policy assertions. As discussed before, these requesters may continue to interact using
old policy alternatives. New policy assertions will emerge to represent new behaviors and
@@ -1022,24 +1037,24 @@
ignorable. When an alternative does have an expiry, it is usually
useful to convey this information to help smooth the versioning process.
</p><p>
- Contoso could specify that the older policy alternative will expire at a
- certain point in time using a Contoso specific expiry assertion. The example
- below shows Contoso version 2 policy expression with a hypothetical ignorable EndOfLife
+ Company-X could specify that the older policy alternative will expire at a
+ certain point in time using a Company-X specific expiry assertion. The example
+ below shows Company-X version 2 policy expression with a hypothetical ignorable EndOfLife
Assertion.
</p><div class="exampleOuter">
-<p style="text-align: left" class="exampleHead"><i><span>Example 3-13. </span>Contoso's Version 2 Policy Expression with hypothetical ignorable EndOfLife
+<p style="text-align: left" class="exampleHead"><i><span>Example 3-13. </span>Company-X's Version 2 Policy Expression with hypothetical ignorable EndOfLife
Assertion</i></p><div class="exampleInner"><pre>
<Policy>
<ExactlyOne>
<All>
- <contoso:EndOfLife wsp:Ignorable="true"/>Mar-31-2008</contoso:EndOfLife>
+ <company-x:EndOfLife wsp:Ignorable="true"/>Mar-31-2008</company-x:EndOfLife>
<wsap:UsingAddressing/>
<sp:TransportBinding>...</sp:TransportBinding>
</All>
<!-- NEW Policy Alternative -->
<All>
- <contoso:EndOfLife wsp:Ignorable="true">Mar-31-2999</contoso:EndOfLife>
+ <company-x:EndOfLife wsp:Ignorable="true">Mar-31-2999</company-x:EndOfLife>
<wsap:UsingAddressing/>
<sp:AsymmetricBinding>...</sp:AsymmetricBinding>
</All>
@@ -1051,10 +1066,10 @@
</p><p>
In a scenario such as this, where an assertion type is used for ignorable
information, the use of strict or lax mode and presence or absence of the
- assertion type in the first version are important decisions. If Contoso wishes
+ assertion type in the first version are important decisions. If Company-X wishes
clients to always be able to ignore the assertion, particularly those using
strict intersection, the first policy alternative offered should contain the
- policy assertion type. If Contoso adds the policy assertion type to a
+ policy assertion type. If Company-X adds the policy assertion type to a
subsequent alternative, then requesters using strict mode will not understand
the assertion type and the alternative with the ignorable information will not
be compatible with the older version of the alternative as per the intersection
@@ -1105,10 +1120,10 @@
Nested policy assertions affect the outcome of policy intersection.</p><p>The <code>sp:IssuedToken</code> security policy assertion identifies a visible domain
specific behavior: the use of a security token – such as SAML token - issued by a third
party for protecting messages. This behavior is relevant to a Web service interaction. For
- the sake of discussion, let us assume that Contoso requires the use of a SAML token issued
- by a third party. Service providers, like Contoso, must convey this usage and all the
+ the sake of discussion, let us assume that Company-X requires the use of a SAML token issued
+ by a third party. Service providers, like Company-X, must convey this usage and all the
necessary information to obtain this security token for Web service developers. This is a
- key piece of metadata for a successful interaction with Contoso’s Web services.</p></div><div class="div2">
+ key piece of metadata for a successful interaction with Company-X’s Web services.</p></div><div class="div2">
<h3><a name="versioning-policy-language" id="versioning-policy-language"></a>3.10 Versioning Policy Language</h3><p>
<table border="1" summary="Editorial note"><tr><td align="left" valign="top" width="50%"><b>Editorial note</b></td><td align="right" valign="top" width="50%"> </td></tr><tr><td colspan="2" align="left" valign="top">
The WG is contemplating moving some or all of this material into a non-normative appendix of the framework or attachment document. User feedback is solicited
@@ -1515,4 +1530,12 @@
to <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4253">issue 4253</a>
(editors action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/191">191</a>).
+ </td></tr><tr><td rowspan="1" colspan="1">20070319</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Implemented the resolution for
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4213">issue 4213</a>
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0076.html">as outlined.</a>
+ Editors' action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/189">189</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070319</td><td rowspan="1" colspan="1">PY</td><td rowspan="1" colspan="1">Implemented the resolution for
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4103">issue 4103</a>
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0033.html">as outlined.</a>
+ Editors' action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/193">193</a>.
</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Received on Monday, 19 March 2007 17:44:55 UTC