- From: David Orchard via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 24 May 2007 16:38:59 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv23627
Modified Files:
ws-policy-primer.html ws-policy-primer.xml
Log Message:
Bugs 4559 and 4374?, Editors AI 281, 282
Index: ws-policy-primer.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.html,v
retrieving revision 1.54
retrieving revision 1.55
diff -u -d -r1.54 -r1.55
--- ws-policy-primer.html 3 May 2007 18:39:45 -0000 1.54
+++ ws-policy-primer.html 24 May 2007 16:38:56 -0000 1.55
@@ -215,7 +215,7 @@
<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:Body>…</soap:Body>
</soap:Envelope></pre></div></div><p>This message uses message addressing headers. The <code>wsa:To</code>
and <code>wsa:Action</code> header blocks identify the destination and the semantics
implied by this message respectively. (The prefix <code>wsa</code> is used here to denote
@@ -242,23 +242,23 @@
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 />
+ <wsam:Addressing>…</wsam:Addressing>
</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
+ element and a child element wsam:Addressing. Child elements of
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" >
<Policy>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
</Policy>
- ...
+ …
</wsdl:binding>
</pre></div></div><p>
Policies can also be attached to WSDL using references (See <a href="#Referencing_Policy_Expressions"><b>2.10 Referencing Policy Expressions</b></a>.)
- </p><p>The <code>wsap:UsingAddressing</code> element is a policy assertion. (The prefix
- <code>wsap</code> is used here to denote the Web Services Addressing – WSDL Binding XML
+ </p><p>The <code>wsam:Addressing</code> element is a policy assertion. (The prefix
+ <code>wsam</code> is used here to denote the Web Services Addressing – Metadata XML
Namespace.) This assertion identifies the use of Web Services Addressing information
headers. A policy-aware client can recognize this policy assertion, engage addressing
automatically, and use headers such as <code>wsa:To</code> and <code>wsa:Action</code> in
@@ -281,7 +281,7 @@
<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: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. Company-X requires the use of security timestamps and
transport-level security - such as <code>HTTPS</code> – for protecting messages. (The
@@ -290,8 +290,8 @@
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>
- <wsap:UsingAddressing />
- <sp:TransportBinding>...</sp:TransportBinding>
+ <wsam:Addressing>…</wsam:Addressing>
+ <sp:TransportBinding>…</sp:TransportBinding>
</Policy></pre></div></div><p>The <code>sp:TransportBinding</code> element is a policy assertion. (The prefix
<code>sp</code> is used here to denote the Web Services Security Policy XML Namespace.)
This assertion identifies the use of transport-level security – such as <code>HTTPS</code>
@@ -333,7 +333,7 @@
policy assertions using the <code>Policy</code> or <code>All</code> operator means that
all the behaviors represented by these assertions are required.</p><div class="exampleOuter">
<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 />
+ <wsam:Addressing>…</wsam:Addressing>
<sp:TransportBinding>…</sp:TransportBinding>
</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
@@ -360,7 +360,7 @@
policy expression in the example below requires the use of addressing and one of
transport- or message-level security for protecting messages.</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 2-9. </span>Addressing and Transport- OR Message-Level Security Policy Expression</i></p><div class="exampleInner"><pre><All>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
<ExactlyOne>
<sp:TransportBinding>…</sp:TransportBinding>
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
@@ -397,7 +397,7 @@
<p style="text-align: left" class="exampleHead"><i><span>Example 2-11. </span>Optional MIME Serialization, Addressing and Transport- OR Message-Level Security
Policy Expression</i></p><div class="exampleInner"><pre><All>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
<ExactlyOne>
<sp:TransportBinding>…</sp:TransportBinding>
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
@@ -537,7 +537,7 @@
identified using either of these mechanisms.</p><div class="exampleOuter">
<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 />
+ <wsam:Addressing>…</wsam:Addressing>
</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>.
@@ -549,7 +549,7 @@
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-16. </span>Common Policy Expression [xml:id]</i></p><div class="exampleInner"><pre><Policy xml:id=”common”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
</Policy></pre></div></div><p> Conditions and constraints on the use of the |xml:id| attribute in conjunction with Canonical
XML 1.0 are specified in Appendix C of <cite><a href="#XMLID">XML ID</a></cite> and are further detailed in <cite><a href="#C14NNOTE">C14N 1.0 Note</a></cite>.
Significant care is suggested in the use of xml:id.
@@ -585,7 +585,7 @@
<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 />
+ <wsam:Addressing>…</wsam:Addressing>
</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-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,
@@ -676,7 +676,7 @@
<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 />
+ <wsam:Addressing>…</wsam:Addressing>
<ExactlyOne>
<sp:TransportBinding>…</sp:TransportBinding>
<sp:AsymmetricBinding>…</sp:AsymmetricBinding >
@@ -741,7 +741,7 @@
<Policy wsu:Id=”common”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
</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
@@ -751,21 +751,21 @@
<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/>
+ <wsam:Addressing>…</wsam:Addressing>
<sp:TransportBinding>…</sp:TransportBinding>
</All>
<All> <!-- - - - - - - - - - - - - - Policy Alternative (b) -->
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
<sp:AsymmetricBinding>…</sp:AsymmetricBinding >
</All>
<All> <!-- - - - - - - - - - - - - - Policy Alternative (c) -->
<mtom:OptimizedMimeSerialization />
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
<sp:TransportBinding>…</sp:TransportBinding>
</All>
<All> <!-- - - - - - - - - - - - - - Policy Alternative (d) -->
<mtom:OptimizedMimeSerialization />
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
</All>
</ExactlyOne>
@@ -831,7 +831,7 @@
<ExactlyOne>
<All> <!-- - - - - - - - - - Company-X’s Policy Alternative (a) -->
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (c1) -->
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (c2) -->
<sp:TransportBinding>…</sp:TransportBinding>
</All>
@@ -848,7 +848,7 @@
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (t1) -->
<sp:TransportBinding>…</sp:TransportBinding>
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (t2) -->
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
</All>
</ExactlyOne>
</Policy></pre></div></div><p>The developer lets her policy-aware client select a compatible policy alternative in Company-X’s
@@ -983,7 +983,7 @@
WSDL port descriptions.</p><div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example 3-9. </span>Multiple Policy Expressions Attached to Endpoint Policy Subject </i></p><div class="exampleInner"><pre><Policy wsu:Id=”common2”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
</Policy>
<Policy wsu:Id=”secure2”>
<ExactlyOne>
@@ -1023,7 +1023,7 @@
<All>
<Policy>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
</Policy>
<Policy>
<ExactlyOne>
@@ -1058,7 +1058,7 @@
<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/>
+ <wsam:Addressing>…</wsam:Addressing>
<sp:TransportBinding>…</sp:TransportBinding>
</All>
</ExactlyOne>
@@ -1074,11 +1074,11 @@
<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/>
+ <wsam:Addressing>…</wsam:Addressing>
<sp:TransportBinding>…</sp:TransportBinding>
</All>
<All> <!-- - - - - - - - - - - - - - - - NEW Policy Alternative -->
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
<sp:AsymmetricBinding>…</sp: AsymmetricBinding >
</All>
</ExactlyOne>
@@ -1115,15 +1115,15 @@
<ExactlyOne>
<All>
<company-x:EndOfLife wsp:Ignorable="true"/>Mar-31-2008</company-x:EndOfLife>
- <wsap:UsingAddressing/>
- <sp:TransportBinding>...</sp:TransportBinding>
+ <wsam:Addressing>…</wsam:Addressing>
+ <sp:TransportBinding>…</sp:TransportBinding>
</All>
<!-- NEW Policy Alternative -->
<All>
<company-x:EndOfLife wsp:Ignorable="true">Mar-31-2999</company-x:EndOfLife>
- <wsap:UsingAddressing/>
- <sp:AsymmetricBinding>...</sp:AsymmetricBinding>
+ <wsam:Addressing>…</wsam:Addressing>
+ <sp:AsymmetricBinding>…</sp:AsymmetricBinding>
</All>
</ExactlyOne>
</Policy></pre></div></div><p>
@@ -1133,8 +1133,19 @@
In a scenario such as this, CompanyX is acting as both a policy assertion author and a policy expression author. As a policy expression author, when an assertion type is tagged as ignorable information, the use of strict or lax mode and presence or absence of the assertion type in the first version are important decisions.
</p></div><div class="div3">
<h4><a name="ignorable-and-optional-and-versioning" id="ignorable-and-optional-and-versioning"></a>3.8.4 Use of Ignorable and Optional attributes</h4><p>If Company-X knows about the hypothetical EndOfLife Policy assertion, it may or may not mark that assertion with wsp:Optional="true" in the first version. If it does include the assertion, marks the assertion with wsp:Ignorable="true" and wsp:Optional="false", then a client that:</p><ul><li><p>does not know about the assertion and using lax intersection will produce an intersection.</p></li><li><p>does not know about the assertion and using strict intersection will not produce an intersection. </p></li><li><p>does know about the assertion and using strict or lax intersection will produce an intersection. </p></li></ul><p>
-If it does include the assertion, marks the assertion with wsp:Ignorable="true" and wsp:Optional="true", then a client that:</p><ul><li><p>does or does not know about the assertion and using lax or strict intersection will produce an intersection. </p></li></ul><p>The following table summarizes the requester assertion knowledge and intersection mode on the left vs provider ignorable and optional on the top</p><table summary="Requester assertion knowledge and intersection mode vs provider ignorable and optional" border="true"><tbody><tr><td rowspan="1" colspan="1">Requester \ Provider</td><td rowspan="1" colspan="1">wsp:Ignorable="false", wsp:Optional="false"</td><td rowspan="1" colspan="1">wsp:Ignorable="true", wsp:Optional="false"</td><td rowspan="1" colspan="1">wsp:Ignorable="false", wsp:Optional="true"</td><td rowspan="1" colspan="1">wsp:Ignorable="true", wsp:Optional="true"</td></tr><tr><td rowspan="1" colspan="1">does not know, lax</td><td rowspan="1" colspan="1">No</td><td rowspan="1" colspan="1">Ye</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td></tr><tr><td rowspan="1" colspan="1">does not know, strict</td><td rowspan="1" colspan="1">No</td><td rowspan="1" colspan="1">No</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td></tr><tr><td rowspan="1" colspan="1">does know, lax</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td></tr><tr><td rowspan="1" colspan="1">does know, strict</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td></tr></tbody></table><br><p>If Company-X adds the hypothetical EndOfLife policy assertion type to a subsequent Alternative and does not mark the assertion with wsp:Optional="true", then after the policy expression has been deployed/used the same algorithm holds true, notably that a client using strict mode that does not understand the ssertion will not intersect
-with the alternative. If CompanyX adds the hypothetical EndOfLife policy assertion with an ignorable attribute and does mark the assertion with wsp:Optional="true", then clients using strict mode who do not understand the hypothetical EndOfLife assertion with the ignorable information will still be compatible with the alternative that does not contain the hypothetical EndOfLife policy assertion as per the intersection rules and the server can return an error if the request is received after the expiry date.</p><p>If Company-X knows about the hypothetical EndOfLife Policy assertion, it can guarantee that clients that know or don't know about the hypothetical EndOfLife Policy Assertion can intersect under any mode by marking the assertion with wsp:Optional="true". Clients that know about the hypothetical EndOfLife Policy assertion and performing strict intersection can guarantee interaction with services that know or don't know about the hypothetical EndOfLife Policy assertion by marking the assertion wih wsp:Optional="true". Clients that know about the hypothetical EndOfLife Policy assertion and performing lax intersection can guarantee interaction with services that know or don't know about the hypothetical EndOfLife Policy assertion by marking the assertion with wsp:Optional="true" or marking it with wsp:Ignorable="true".
+If it does include the assertion, marks the assertion with wsp:Ignorable="true" and wsp:Optional="true", then a client that:</p><ul><li><p>does or does not know about the assertion and using lax or strict intersection will produce an intersection. </p></li></ul><p>The following table summarizes the requester assertion knowledge and intersection mode on the left vs provider ignorable and optional on the top</p><table summary="Requester assertion knowledge and intersection mode vs provider ignorable and optional" border="true"><tbody><tr><td rowspan="1" colspan="1">Requester \ Provider</td><td rowspan="1" colspan="1">Required</td><td rowspan="1" colspan="1">Required and Ignorable (for intersection)</td><td rowspan="1" colspan="1">Optional </td><td rowspan="1" colspan="1">Optional and Ignorable (for intersection)</td></tr><tr><td rowspan="1" colspan="1">does not know, lax</td><td rowspan="1" colspan="1">No</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1"Yes</td></tr><tr><td rowspan="1" colspan="1">does not know, strict</td><td rowspan="1" colspan="1">No</td><td rowspan="1" colspan="1">No</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td></tr><tr><td rowspan="1" colspan="1">does know, lax</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td></tr><tr><td rowspan="1" colspan="1">does know, strict</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td><td rowspan="1" colspan="1">Yes</td></tr></tbody></table><br><p>If Company-X adds the hypothetical EndOfLife policy assertion type to a subsequent Alternative and does not mark the assertion with wsp:Optional="true", then after the policy expression has been deployed/used the same algorithm holds true, notably that a client using strict mode that does not understand the assertion will not intersect
+with the alternative. If CompanyX adds the hypothetical EndOfLife policy
+ assertion with an ignorable attribute and does mark the assertion
+ with wsp:Optional="true", then clients using strict mode who do not
+ understand the hypothetical EndOfLife assertion with the ignorable
+ information will still be compatible with the alternative that does
+ not contain the hypothetical EndOfLife policy assertion as per the
+ intersection rules. When wsp:Ignorable="true" is used, clients that are unaware of the
+ hypothetical EndOfLife assertion may make more requests for expired
+ services. This could result in servers generating Faults if the
+ request is received after the expiry date.
+
+.</p><p>If Company-X knows about the hypothetical EndOfLife Policy assertion, it can guarantee that clients that know or don't know about the hypothetical EndOfLife Policy Assertion can intersect under any mode by marking the assertion with wsp:Optional="true". Clients that know about the hypothetical EndOfLife Policy assertion and performing strict intersection can guarantee interaction with services that know or don't know about the hypothetical EndOfLife Policy assertion by marking the assertion with wsp:Optional="true". Clients that know about the hypothetical EndOfLife Policy assertion and performing lax intersection can guarantee interaction with services that know or don't know about the hypothetical EndOfLife Policy assertion by marking the assertion with wsp:Optional="true" or marking it with wsp:Ignorable="true".
</p><p>Because the actual value of the date/time may not be known when the policy expression is first created, a value that is roughly infinitely in the future is used. A subsequent policy alternative could refine the value and domain specific processing of the assertion can differentiate the value.
The advantage of adding the end of life information through a domain specific assertion is that some clients will have a machine processable way of knowing when the alternative will no longer be supported by evaluating the policy assertions in a policy expression. Without this information in a policy expression, the information must be conveyed in some other way or it will not be conveyed at all. This can usefully smooth the transition between versions of a service. </p><p>The disadvantage of adding the end of life information through a domain specific assertion is that clients need to understand the semantics of the hypothetical EndOfLife assertion in order to know whether a particular alternative is still valid. For example, a client that doesn’t know what the parameter “Mar-31-2008” means, will not know that the service is no longer available on April 1, and may send messages to this service in April, and if the service enforces “end of life”, these messages may fail.
</p></div></div><div class="div2">
@@ -1328,10 +1339,10 @@
</td><td rowspan="1" colspan="1">
<code>http://www.w3.org/2005/08/addressing</code>
</td><td rowspan="1" colspan="1">[<cite><a href="#WS-Addressing">WS-Addressing Core</a></cite>]</td></tr><tr><td rowspan="1" colspan="1">
- <code>wsap</code>
+ <code>wsam</code>
</td><td rowspan="1" colspan="1">
- <code>http://www.w3.org/2006/05/addressing/wsdl</code>
- </td><td rowspan="1" colspan="1">[<cite><a href="#WS-AddressingWSDL">WS-Addressing WSDL Binding</a></cite>]</td></tr><tr><td rowspan="1" colspan="1">
+ <code>http://www.w3.org/2007/05/addressing/metadata</code>
+ </td><td rowspan="1" colspan="1">[<cite><a href="#WS-AddressingMetadata">WS-Addressing Metadata</a></cite>]</td></tr><tr><td rowspan="1" colspan="1">
<code>wsdl</code>
</td><td rowspan="1" colspan="1">
<code>http://schemas.xmlsoap.org/wsdl/</code>
@@ -1381,12 +1392,12 @@
Rogers, Editors. World Wide Web Consortium, 9 May 2006. This version of the Web Services
Addressing 1.0 - Core Recommendation is
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. The <a href="http://www.w3.org/TR/ws-addr-core/">latest version of Web Services Addressing 1.0
- - Core</a> is available at http://www.w3.org/TR/ws-addr-core. </dd><dt class="label"><a name="WS-AddressingWSDL"></a>[WS-Addressing WSDL Binding] </dt><dd>
- <cite><a href="http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/">Web Services Addressing 1.0 - WSDL Binding</a></cite>, M. Gudgin, M. Hadley, T.
- Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, 29 May 2006. This version of
- the Web Services Addressing 1.0 - WSDL Binding is
- http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/. The <a href="http://www.w3.org/TR/ws-addr-wsdl">latest version of Web Services Addressing 1.0 -
- WSDL Binding</a> is available at http://www.w3.org/TR/ws-addr-wsdl. </dd><dt class="label"><a name="WS-Atomic"></a>[Web Services Atomic Transaction] </dt><dd>
+ - Core</a> is available at http://www.w3.org/TR/ws-addr-core. </dd><dt class="label"><a name="WS-AddressingMetadata"></a>[WS-Addressing Metadata] </dt><dd>
+ <cite><a href="http://www.w3.org/TR/2007/WD-ws-addr-metadata-20070516/">Web Services Addressing 1.0 - Metadata</a></cite>, M. Gudgin, M. Hadley, T.
+ Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, 16 May 2007. This version of
+ the Web Services Addressing 1.0 - Metadata is
+ http://www.w3.org/TR/2007/WD-ws-addr-metadata-20070516/. The <a href="http://www.w3.org/TR/ws-addr-metadata">latest version of Web Services Addressing 1.0 -
+ Metadata</a> is available at http://www.w3.org/TR/ws-addr-metadata. </dd><dt class="label"><a name="WS-Atomic"></a>[Web Services Atomic Transaction] </dt><dd>
<cite><a href="http://schemas.xmlsoap.org/ws/2004/10/wsat/">Web Services Atomic Transaction</a></cite>, L. P. Cabrera, et al, Authors.
Arjuna Technologies, Inc., BEA Systems, Inc., Hitachi Software, Inc., IONA Technologies, Inc.,
International Business Machines Corporation, and Microsoft Corporation,
@@ -1608,4 +1619,10 @@
</td></tr><tr><td rowspan="1" colspan="1">20070502</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Finished changes for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4414">issue 4414</a>.
Editors' action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239">239</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070524</td><td rowspan="1" colspan="1">DBO</td><td rowspan="1" colspan="1">Finished changes for <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4559">issue 4559</a>.
+ Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/281">281</a>, and
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4376">issue 4375</a>.
+ Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/282">282</a>
</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Index: ws-policy-primer.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer.xml,v
retrieving revision 1.58
retrieving revision 1.59
diff -u -d -r1.58 -r1.59
--- ws-policy-primer.xml 3 May 2007 18:39:45 -0000 1.58
+++ ws-policy-primer.xml 24 May 2007 16:38:57 -0000 1.59
@@ -170,7 +170,7 @@
<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:Body>…</soap:Body>
</soap:Envelope></eg>
</example>
<p>This message uses message addressing headers. The <code>wsa:To</code>
@@ -206,12 +206,12 @@
<example>
<head>Policy Expression</head>
<eg xml:space="preserve"><Policy>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
</Policy></eg>
</example>
<p>
The policy expression in the above example consists of a Policy main
- element and a child element wsap:UsingAddressing. Child elements of
+ element and a child element wsam:Addressing. Child elements of
the Policy element are policy assertions. Company-X attaches the above
policy expression to a WSDL binding description.
</p>
@@ -219,17 +219,17 @@
<head>Policy Expression Attached to Binding</head>
<eg xml:space="preserve"><wsdl:binding name="AddressingBinding" type="tns:RealTimeDataInterface" >
<Policy>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
</Policy>
- ...
+ …
</wsdl:binding>
</eg>
</example>
<p>
Policies can also be attached to WSDL using references (See <specref ref="Referencing_Policy_Expressions" />.)
</p>
- <p>The <code>wsap:UsingAddressing</code> element is a policy assertion. (The prefix
- <code>wsap</code> is used here to denote the Web Services Addressing – WSDL Binding XML
+ <p>The <code>wsam:Addressing</code> element is a policy assertion. (The prefix
+ <code>wsam</code> is used here to denote the Web Services Addressing – Metadata XML
Namespace.) This assertion identifies the use of Web Services Addressing information
headers. A policy-aware client can recognize this policy assertion, engage addressing
automatically, and use headers such as <code>wsa:To</code> and <code>wsa:Action</code> in
@@ -258,7 +258,7 @@
<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:Body>…</soap:Body>
</soap:Envelope></eg>
</example>
<p>The SOAP message in the example above includes security timestamps that express creation
@@ -272,8 +272,8 @@
<example>
<head>Addressing and Security Policy Expression</head>
<eg xml:space="preserve"><Policy>
- <wsap:UsingAddressing />
- <sp:TransportBinding>...</sp:TransportBinding>
+ <wsam:Addressing>…</wsam:Addressing>
+ <sp:TransportBinding>…</sp:TransportBinding>
</Policy></eg>
</example>
<p>The <code>sp:TransportBinding</code> element is a policy assertion. (The prefix
@@ -350,7 +350,7 @@
<example>
<head>Addressing and Security Policy Expression</head>
<eg xml:space="preserve"><All>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
<sp:TransportBinding>…</sp:TransportBinding>
</All></eg>
</example>
@@ -390,7 +390,7 @@
<example>
<head>Addressing and Transport- OR Message-Level Security Policy Expression</head>
<eg xml:space="preserve"><All>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
<ExactlyOne>
<sp:TransportBinding>…</sp:TransportBinding>
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
@@ -441,7 +441,7 @@
Policy Expression</head>
<eg xml:space="preserve"><All>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
<ExactlyOne>
<sp:TransportBinding>…</sp:TransportBinding>
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
@@ -556,7 +556,7 @@
<sp:Basic256Rsa15/>
</Policy>
</sp:AlgorithmSuite>
- …
+ …
</Policy>
</sp:TransportBinding></eg>
</example>
@@ -622,7 +622,7 @@
<head>Common Policy Expression</head>
<eg xml:space="preserve"><Policy wsu:Id=”common”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
</Policy></eg>
</example>
<p>In the example above, the <code>wsu:Id</code> attribute is used to identify a policy
@@ -639,7 +639,7 @@
<head>Common Policy Expression [xml:id]</head>
<eg xml:space="preserve"><Policy xml:id=”common”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
</Policy></eg>
</example>
<p> Conditions and constraints on the use of the |xml:id| attribute in conjunction with Canonical
@@ -692,7 +692,7 @@
<head>Common Policy Expression</head>
<eg xml:space="preserve"><Policy Name=”http://x.example.com/policy/common”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
</Policy></eg>
</example>
<p>The example below is a policy expression that re-uses the common policy expression above.</p>
@@ -732,8 +732,8 @@
<head>Secure Policy Expression Attached to WSDL Binding</head>
<eg xml:space="preserve"><wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
<PolicyReference URI="#secure" />
- <wsdl:operation name="GetRealQuote">…</wsdl:operation>
- …
+ <wsdl:operation name="GetRealQuote">…</wsdl:operation>
+ …
</wsdl:binding></eg>
</example>
<p>In addition to providing real-time quotes and book information on securities, Company-X
@@ -747,8 +747,8 @@
<head>Open Policy Expression Attached to WSDL Binding</head>
<eg xml:space="preserve"><wsdl:binding name="OpenBinding" type="tns:DelayedDataInterface" >
<PolicyReference URI="#common" />
- <wsdl:operation name="GetDelayedQuote">…</wsdl:operation>
- …
+ <wsdl:operation name="GetDelayedQuote">…</wsdl:operation>
+ …
</wsdl:binding></eg>
</example>
<p>In the example above, the <code>OpenBinding</code> WSDL binding description defines a
@@ -842,7 +842,7 @@
<eg xml:space="preserve"><Policy>
<All>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
<ExactlyOne>
<sp:TransportBinding>…</sp:TransportBinding>
<sp:AsymmetricBinding>…</sp:AsymmetricBinding >
@@ -869,16 +869,16 @@
<eg xml:space="preserve"><Policy>
<ExactlyOne>
<All>
- <x:AssertionA>…</x:AssertionA>
- <y:AssertionB>…</y:AssertionB>
- …
+ <x:AssertionA>…</x:AssertionA>
+ <y:AssertionB>…</y:AssertionB>
+ …
</All>
<All>
- <x:AssertionA>…</x:AssertionA>
- <z:AssertionC>…</z:AssertionC>
- …
+ <x:AssertionA>…</x:AssertionA>
+ <z:AssertionC>…</z:AssertionC>
+ …
</All>
- …
+ …
</ExactlyOne>
<Policy/></eg>
</example>
@@ -940,7 +940,7 @@
<Policy wsu:Id=”common”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
</Policy></eg>
</example>
<p>Let us look at the normal form for this policy expression. The example below is Company-X’s
@@ -954,21 +954,21 @@
<eg xml:space="preserve"><Policy>
<ExactlyOne>
<All> <!-- - - - - - - - - - - - - - Policy Alternative (a) -->
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
<sp:TransportBinding>…</sp:TransportBinding>
</All>
<All> <!-- - - - - - - - - - - - - - Policy Alternative (b) -->
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
<sp:AsymmetricBinding>…</sp:AsymmetricBinding >
</All>
<All> <!-- - - - - - - - - - - - - - Policy Alternative (c) -->
<mtom:OptimizedMimeSerialization />
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
<sp:TransportBinding>…</sp:TransportBinding>
</All>
<All> <!-- - - - - - - - - - - - - - Policy Alternative (d) -->
<mtom:OptimizedMimeSerialization />
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
<sp:AsymmetricBinding>…</sp:AsymmetricBinding>
</All>
</ExactlyOne>
@@ -1075,11 +1075,11 @@
<ExactlyOne>
<All> <!-- - - - - - - - - - Company-X’s Policy Alternative (a) -->
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (c1) -->
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (c2) -->
<sp:TransportBinding>…</sp:TransportBinding>
</All>
- …
+ …
</ExactlyOne>
</Policy></eg>
</example>
@@ -1096,7 +1096,7 @@
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (t1) -->
<sp:TransportBinding>…</sp:TransportBinding>
<!-- - - - - - - - - - - - - - - - - - Policy Assertion (t2) -->
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
</All>
</ExactlyOne>
</Policy></eg>
@@ -1222,8 +1222,8 @@
<head>Company-X’s Policy Expression Attached to WSDL binding Element</head>
<eg xml:space="preserve"><wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
<PolicyReference URI="#secure" />
- <wsdl:operation name="GetRealQuote">…</wsdl:operation>
- …
+ <wsdl:operation name="GetRealQuote">…</wsdl:operation>
+ …
</wsdl:binding></eg>
</example>
<p>If multiple policy expressions are attached to WSDL elements that collectively represent
@@ -1309,7 +1309,7 @@
<head>Multiple Policy Expressions Attached to Endpoint Policy Subject </head>
<eg xml:space="preserve"><Policy wsu:Id=”common2”>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
- <wsap:UsingAddressing />
+ <wsam:Addressing>…</wsam:Addressing>
</Policy>
<Policy wsu:Id=”secure2”>
<ExactlyOne>
@@ -1319,13 +1319,13 @@
</Policy>
<wsdl:binding name="SecureBinding" type="tns:RealTimeDataInterface" >
<PolicyReference URI="#secure2" />
- <wsdl:operation name="GetRealQuote">…</wsdl:operation>
- …
+ <wsdl:operation name="GetRealQuote">…</wsdl:operation>
+ …
</wsdl:binding>
<wsdl:service name=”RealTimeDataService”>
<wsdl:port name=”RealTimeDataPort” binding=”tns:SecureBinding”>
<PolicyReference URI="#common2"/>
- …
+ …
</wsdl:port>
</wsdl:service></eg>
</example>
@@ -1357,7 +1357,7 @@
<All>
<Policy>
<mtom:OptimizedMimeSerialization wsp:Optional="true"/>
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
</Policy>
<Policy>
<ExactlyOne>
@@ -1407,7 +1407,7 @@
<eg xml:space="preserve"><Policy>
<ExactlyOne>
<All>
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
<sp:TransportBinding>…</sp:TransportBinding>
</All>
</ExactlyOne>
@@ -1427,11 +1427,11 @@
<eg xml:space="preserve"><Policy>
<ExactlyOne>
<All>
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
<sp:TransportBinding>…</sp:TransportBinding>
</All>
<All> <!-- - - - - - - - - - - - - - - - NEW Policy Alternative -->
- <wsap:UsingAddressing/>
+ <wsam:Addressing>…</wsam:Addressing>
<sp:AsymmetricBinding>…</sp: AsymmetricBinding >
</All>
</ExactlyOne>
@@ -1478,15 +1478,15 @@
<ExactlyOne>
<All>
<company-x:EndOfLife wsp:Ignorable="true"/>Mar-31-2008</company-x:EndOfLife>
- <wsap:UsingAddressing/>
- <sp:TransportBinding>...</sp:TransportBinding>
+ <wsam:Addressing>…</wsam:Addressing>
+ <sp:TransportBinding>…</sp:TransportBinding>
</All>
<!-- NEW Policy Alternative -->
<All>
<company-x:EndOfLife wsp:Ignorable="true">Mar-31-2999</company-x:EndOfLife>
- <wsap:UsingAddressing/>
- <sp:AsymmetricBinding>...</sp:AsymmetricBinding>
+ <wsam:Addressing>…</wsam:Addressing>
+ <sp:AsymmetricBinding>…</sp:AsymmetricBinding>
</All>
</ExactlyOne>
</Policy></eg>
@@ -1525,10 +1525,10 @@
<tbody>
<tr>
<td>Requester \ Provider</td>
-<td>wsp:Ignorable="false", wsp:Optional="false"</td>
-<td>wsp:Ignorable="true", wsp:Optional="false"</td>
-<td>wsp:Ignorable="false", wsp:Optional="true"</td>
-<td>wsp:Ignorable="true", wsp:Optional="true"</td>
+<td>Required</td>
+<td>Required and Ignorable (for intersection)</td>
+<td>Optional </td>
+<td>Optional and Ignorable (for intersection)</td>
</tr>
<tr>
<td>does not know, lax</td>
@@ -1561,7 +1561,18 @@
</tbody>
</table>
<p>If Company-X adds the hypothetical EndOfLife policy assertion type to a subsequent Alternative and does not mark the assertion with wsp:Optional="true", then after the policy expression has been deployed/used the same algorithm holds true, notably that a client using strict mode that does not understand the assertion will not intersect
-with the alternative. If CompanyX adds the hypothetical EndOfLife policy assertion with an ignorable attribute and does mark the assertion with wsp:Optional="true", then clients using strict mode who do not understand the hypothetical EndOfLife assertion with the ignorable information will still be compatible with the alternative that does not contain the hypothetical EndOfLife policy assertion as per the intersection rules and the server can return an error if the request is received after the expiry date.</p>
+with the alternative. If CompanyX adds the hypothetical EndOfLife policy
+ assertion with an ignorable attribute and does mark the assertion
+ with wsp:Optional="true", then clients using strict mode who do not
+ understand the hypothetical EndOfLife assertion with the ignorable
+ information will still be compatible with the alternative that does
+ not contain the hypothetical EndOfLife policy assertion as per the
+ intersection rules. When wsp:Ignorable="true" is used, clients that are unaware of the
+ hypothetical EndOfLife assertion may make more requests for expired
+ services. This could result in servers generating Faults if the
+ request is received after the expiry date.
+
+.</p>
<p>If Company-X knows about the hypothetical EndOfLife Policy assertion, it can guarantee that clients that know or don't know about the hypothetical EndOfLife Policy Assertion can intersect under any mode by marking the assertion with wsp:Optional="true". Clients that know about the hypothetical EndOfLife Policy assertion and performing strict intersection can guarantee interaction with services that know or don't know about the hypothetical EndOfLife Policy assertion by marking the assertion with wsp:Optional="true". Clients that know about the hypothetical EndOfLife Policy assertion and performing lax intersection can guarantee interaction with services that know or don't know about the hypothetical EndOfLife Policy assertion by marking the assertion with wsp:Optional="true" or marking it with wsp:Ignorable="true".
</p>
<p>Because the actual value of the date/time may not be known when the policy expression is first created, a value that is roughly infinitely in the future is used. A subsequent policy alternative could refine the value and domain specific processing of the assertion can differentiate the value.
@@ -1887,12 +1898,12 @@
</tr>
<tr>
<td>
- <code>wsap</code>
+ <code>wsam</code>
</td>
<td>
- <code>http://www.w3.org/2006/05/addressing/wsdl</code>
+ <code>http://www.w3.org/2007/05/addressing/metadata</code>
</td>
- <td>[<bibref ref="WS-AddressingWSDL"/>]</td>
+ <td>[<bibref ref="WS-AddressingMetadata"/>]</td>
</tr>
<tr>
<td>
@@ -1991,14 +2002,14 @@
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/. The <loc
href="http://www.w3.org/TR/ws-addr-core/">latest version of Web Services Addressing 1.0
- Core</loc> is available at http://www.w3.org/TR/ws-addr-core. </bibl>
- <bibl key="WS-Addressing WSDL Binding" id="WS-AddressingWSDL"
- href="http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/">
- <titleref>Web Services Addressing 1.0 - WSDL Binding</titleref>, M. Gudgin, M. Hadley, T.
- Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, 29 May 2006. This version of
- the Web Services Addressing 1.0 - WSDL Binding is
- http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/. The <loc
- href="http://www.w3.org/TR/ws-addr-wsdl">latest version of Web Services Addressing 1.0 -
- WSDL Binding</loc> is available at http://www.w3.org/TR/ws-addr-wsdl. </bibl>
+ <bibl key="WS-Addressing Metadata" id="WS-AddressingMetadata"
+ href="http://www.w3.org/TR/2007/WD-ws-addr-metadata-20070516/">
+ <titleref>Web Services Addressing 1.0 - Metadata</titleref>, M. Gudgin, M. Hadley, T.
+ Rogers and Ü. Yalçinalp, Editors. World Wide Web Consortium, 16 May 2007. This version of
+ the Web Services Addressing 1.0 - Metadata is
+ http://www.w3.org/TR/2007/WD-ws-addr-metadata-20070516/. The <loc
+ href="http://www.w3.org/TR/ws-addr-metadata">latest version of Web Services Addressing 1.0 -
+ Metadata</loc> is available at http://www.w3.org/TR/ws-addr-metadata. </bibl>
<bibl id="WS-Atomic" key="Web Services Atomic Transaction" href="http://schemas.xmlsoap.org/ws/2004/10/wsat/">
<titleref>Web Services Atomic Transaction</titleref>, L. P. Cabrera, et al, Authors.
Arjuna Technologies, Inc., BEA Systems, Inc., Hitachi Software, Inc., IONA Technologies, Inc.,
@@ -2487,6 +2498,17 @@
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/239">239</loc>.
</td>
</tr>
+ <tr>
+ <td>20070524</td>
+ <td>DBO</td>
+ <td>Finished changes for <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4559">issue 4559</loc>.
+ Editors' action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/281">281</loc>, and
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=4376">issue 4375</loc>.
+ Editors' action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/282">282</loc>
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Thursday, 24 May 2007 16:39:02 UTC