NOTE-ws-policy-guidelines-20071112 157 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en-US" xmlns="http://www.w3.org/1999/xhtml" xml:lang=
"en-US">
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
<meta http-equiv="Content-Type" content=
"text/html; charset=utf-8" />
<title>Web Services Policy 1.5 - Guidelines for Policy Assertion
Authors</title>

<style type="text/css">
/*<![CDATA[*/
/**/
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

ol.enumar      { list-style-type: decimal; }
ol.enumla      { list-style-type: lower-alpha; }
ol.enumlr      { list-style-type: lower-roman; }
ol.enumua      { list-style-type: upper-alpha; }
ol.enumur      { list-style-type: upper-roman; }

dt.label       { display: run-in; }

li, p           { margin-top: 0.3em;
                 margin-bottom: 0.3em; }

.diff-chg       { background-color: yellow; }
.diff-del       { background-color: red; text-decoration: line-through;}
.diff-add       { background-color: lime; }

table          { empty-cells: show; }

table caption {
        font-weight: normal;
        font-style: italic;
        text-align: left;
        margin-bottom: .5em;
}

div.issue {
  color: red;
}
.rfc2119 {
  font-variant: small-caps;
}

div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}

div.boxedtext {
   border: solid #bebebe 1px;
   margin: 2em 1em 1em 2em;
 }

span.practicelab {
   margin: 1.5em 0.5em 1em 1em;
   font-weight: bold;
   font-style: italic;
 }

span.practicelab   { background: #dfffff; }

 span.practicelab {
   position: relative;
   padding: 0 0.5em;
   top: -1.5em;
 }
p.practice
{
   margin: 1.5em 0.5em 1em 1em;
 }

@media screen {
 p.practice {
   position: relative;
   top: -2em;
   padding: 0;
   margin: 1.5em 0.5em -1em 1em;
}
}
/**/
/*]]>*/
</style>
<link rel="stylesheet" type="text/css" href=
"http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css" />
</head>
<body>
<div class="head">
<p><a href="http://www.w3.org/"><img src=
"http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width=
"72" /></a></p>
<h1><a name="title" id="title"></a>Web Services Policy 1.5 -
Guidelines for Policy Assertion Authors</h1>
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Working Group
Note 12 November 2007</h2>
<dl>
<dt>This version:</dt>
<dd><a href=
"http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112">http://www.w3.org/TR/2007/NOTE-ws-policy-guidelines-20071112</a></dd>
<dt>Latest version:</dt>
<dd><a href=
"http://www.w3.org/TR/ws-policy-guidelines">http://www.w3.org/TR/ws-policy-guidelines</a></dd>
<dt>Previous version:</dt>
<dd><a href=
"http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070928">http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070928</a></dd>
<dt>Editors:</dt>
<dd>Asir S Vedamuthu, Microsoft Corporation</dd>
<dd>David Orchard, BEA Systems, Inc.</dd>
<dd>Frederick Hirsch, Nokia</dd>
<dd>Maryann Hondo, IBM Corporation</dd>
<dd>Prasad Yendluri, webMethods (A subsidiary of Software AG)</dd>
<dd>Toufic Boubez, Layer 7 Technologies</dd>
<dd>Ümit Yalçinalp, SAP AG.</dd>
</dl>
<p>This document is also available in these non-normative formats:
<a href="ws-policy-guidelines.pdf">PDF</a>, <a href=
"ws-policy-guidelines.ps">PostScript</a>, <a href=
"ws-policy-guidelines.xml">XML</a>, and&nbsp;<a href=
"ws-policy-guidelines.txt">plain text</a>.</p>
<p class="copyright"><a href=
"http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>&nbsp;©&nbsp;2007&nbsp;<a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup>
(<a href="http://www.csail.mit.edu/"><acronym title=
"Massachusetts Institute of Technology">MIT</acronym></a>, <a href=
"http://www.ercim.org/"><acronym title=
"European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved.
W3C <a href=
"http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a href=
"http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
and <a href=
"http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> rules apply.</p>
</div>
<hr />
<div>
<h2><a name="abstract" id="abstract"></a>Abstract</h2>
<p><em>Web Services Policy 1.5 - Guidelines for Policy Assertion
Authors</em> is intended to provide guidance for Assertion Authors
that will work with the Web Services Policy 1.5 - Framework
[<cite><a href="#WS-Policy">Web Services Policy
Framework</a></cite>] and Web Services Policy 1.5 - Attachment
[<cite><a href="#WS-PolicyAttachment">Web Services Policy
Attachment</a></cite>] specifications to create domain specific
assertions. The focus of this document is to provide best practices
and patterns to follow as well as illustrate the care needed in
using WS-Policy to achieve the best possible results for
interoperability. It is a complementary guide to using the
specifications.</p>
</div>
<div>
<h2><a name="status" id="status"></a>Status of this Document</h2>
<p><em>This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. A list of current W3C publications and the latest
revision of this technical report can be found in the <a href=
"http://www.w3.org/TR/">W3C technical reports index</a> at
http://www.w3.org/TR/.</em></p>
<p>This is a <a href=
"http://www.w3.org/2004/02/Process-20040205/tr#WGNote">W3C Working
Group Note</a> of the Web Services Policy 1.5 - Guidelines for
Policy Assertion Authors specification, developed by the members of
the <a href="http://www.w3.org/2002/ws/policy/">Web Services Policy
Working Group</a>, which is part of the <a href=
"http://www.w3.org/2002/ws/Activity">W3C Web Services
Activity</a>.</p>
<p>A list of <a href="#change-description">changes in this version
of the document</a> and a <a href=
"ws-policy-guidelines-diff20070928.html">diff-marked version
against the previous version of this document</a> are available.
Please send comments about this document to the <a href=
"mailto:public-ws-policy-comments@w3.org">public-ws-policy-comments@w3.org</a>
mailing list (<a href=
"http://lists.w3.org/Archives/Public/public-ws-policy-comments/">public
archive</a>) with a subject that is prefaced with
[ws-policy-guidelines].</p>
<p>Publication as a Working Group Note does not imply endorsement
by the W3C Membership. This is a draft document and may be updated,
replaced or obsoleted by other documents at any time. It is
inappropriate to cite this document as other than work in
progress.</p>
<p>This document was produced by a group operating under the
<a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5
February 2004 W3C Patent Policy</a>. W3C maintains a <a href=
"http://www.w3.org/2004/01/pp-impl/39293/status">public list of any
patent disclosures</a> made in connection with the deliverables of
the group; that page also includes instructions for disclosing a
patent. An individual who has actual knowledge of a patent which
the individual believes contains <a href=
"http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">
Essential Claim(s)</a> must disclose the information in accordance
with <a href=
"http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">
section 6 of the W3C Patent Policy</a>.</p>
</div>
<div class="toc">
<h2><a name="contents" id="contents"></a>Table of Contents</h2>
<p class="toc">1. <a href="#introduction">Introduction</a><br />
2. <a href="#best-practices-list">List of Best Practice
Statements</a><br />
3. <a href="#Assertions">What is an Assertion?</a><br />
4. <a href="#assertion-authors">Who is involved in authoring
Assertions?</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.1 <a href="#roles">Roles and
Responsibilities</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.1.1 <a href=
"#domain-owners">Assertion Authors</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.1.2 <a href=
"#consumers">Consumers</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4.1.3 <a href=
"#providers">Providers</a><br />
5. <a href="#general-guidelines">General Guidelines for Assertion
Authors</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;5.1 <a href="#assertion-target">Assertions
and Their Target Use</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;5.2 <a href="#compact-full">Authoring
Styles</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;5.3 <a href=
"#new-guidelines-domains">Considerations when Modeling New
Assertions</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.3.1 <a href=
"#minimal-approach">Minimal approach</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.3.2 <a href=
"#QName_and_XML_Information_Set_representation">QName and XML
Information Set representation</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.3.3 <a href=
"#self-describing">Self Describing Messages</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.3.4 <a href=
"#single-domains">Single Domains</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.3.5 <a href=
"#order-of-behaviors">Order of Behaviors</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;5.4 <a href="#comparison">Comparison of
Nested and Parameterized Assertions</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.4.1 <a href=
"#parameterized-assertions">Assertions with Parameters</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.4.2 <a href=
"#nested-assertions">Nested Assertions</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;5.5 <a href="#Ignorable">Designating
Ignorable Behavior</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.1 <a href=
"#d3e882">Ignorable behavior in authoring</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.5.2 <a href=
"#d3e895">Ignorable behavior at runtime</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;5.6 <a href=
"#optional-policy-assertion">Designating Optional
Behaviors</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.6.1 <a href=
"#d3e910">Optional behavior at runtime</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;5.7 <a href=
"#levels-of-abstraction">Considerations for Policy
Attachment</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.7.1 <a href=
"#general-attachment-guidelines">General Guidelines</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.7.2 <a href=
"#wsdl-attachment-guidelines">Considerations for Policy Attachment
in WSDL</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.7.3 <a href=
"#UDDI-attachment-guidelines">Considerations for Policy Attachment
in UDDI</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;5.8 <a href=
"#interrelated-domains">Interrelated domains</a><br />
6. <a href="#versioning-policy-assertions">Versioning Policy
Assertions</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;6.1 <a href=
"#Referencing_Policy_Expressions">Referencing Policy
Expressions</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;6.2 <a href=
"#extending-assertions">Evolution of Assertions (Versioning and
Compatibility)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;6.3 <a href=
"#supporting-new-policy-subjects">Supporting New Policy
Subjects</a><br /></p>
<h3><a name="appendices" id="appendices"></a>Appendices</h3>
<p class="toc">A. <a href="#security-considerations">Security
Considerations</a><br />
B. <a href="#xml-namespaces">XML Namespaces</a><br />
C. <a href="#references">References</a><br />
D. <a href="#acknowledgments">Acknowledgements</a>
(Non-Normative)<br />
E. <a href="#change-description">Changes in this Version of the
Document</a> (Non-Normative)<br />
F. <a href="#change-log">Web Services Policy 1.5 - Guidelines for
Policy Assertion Authors Change Log</a> (Non-Normative)<br /></p>
</div>
<hr />
<div class="body">
<div class="div1">
<h2><a name="introduction" id="introduction"></a>1.
Introduction</h2>
<p>The WS-Policy specification defines a policy to be a collection
of policy alternatives. Each policy alternative is a collection of
policy assertions. The Web Services Policy 1.5 - Framework provides
a flexible framework to represent consistent combinations of
behaviors from a variety of domains. A policy assertion is a
machine readable metadata expression that identifies behaviors
required for Web services interactions. <em>Web Services Policy 1.5
- Guidelines for Policy Assertion Authors</em> is a resource
primarily for Assertion Authors and provides guidelines on the use
of Web Services Policy 1.5 - Framework and Web Services Policy 1.5
- Attachment specifications to create and use domain specific
assertions to enable interoperability.</p>
<p>WS-Policy Assertions communicate the requirements and
capabilities of a web service by adhering to the specification,
WS-Policy Framework. To enable interoperability of web services
different sets of WS-Policy Assertions need to be defined by
different communities based upon domain-specific requirements of
the web service.</p>
<p>The focus of these guidelines is to capture best practices and
usage patterns for practitioners. It is a complementary guide to
the Framework and Attachments specifications and the Primer. It is
intended to provide non-normative guidelines for WS-Policy
Assertion Authors who need to know the features of the language and
understand the requirements for describing policy assertions. Some
of the guidance for WS-Policy Assertion Authors can also be helpful
for those who use the policy assertions created by Assertion
Authors.</p>
<p>This document assumes a basic understanding of XML, Namespaces
in XML, WSDL, SOAP and the Web Services Policy language.</p>
<p>This is a non-normative document and does not provide a
definitive specification of the Web Services Policy framework.
<a href="#xml-namespaces"><b>B. XML Namespaces</b></a> lists all
the namespace prefixes that are used in this document. (XML
elements without a namespace prefix are from the Web Services
Policy XML Namespace.)</p>
<p>As a companion document to the primer, this document also
follows the Socratic style of beginning with a question, and then
answering the question.</p>
</div>
<div class="div1">
<h2><a name="best-practices-list" id="best-practices-list"></a>2.
List of Best Practice Statements</h2>
<p>The following Best Practices appear in this document with
discussion and examples, and are summarized here for quick
reference:</p>
<ul>
<li>
<p><a href="#bp-compatibility-tests"><b>1. Define assertions
relevant to compatibility tests</b></a></p>
</li>
<li>
<p><a href=
"#bp-ignorable-for-not-related-to-compatibility-tests"><b>2. Mark
Ignorable Assertions not related to compatibility</b></a></p>
</li>
<li>
<p><a href="#bp-semantics-and-form"><b>3. Semantics Independent of
the Form</b></a></p>
</li>
<li>
<p><a href="#bp-assertion-start"><b>4. Start with a Simple
Assertion</b></a></p>
</li>
<li>
<p><a href="#bp-unique-qnames"><b>5. Use Unique QNames</b></a></p>
</li>
<li>
<p><a href="#XMLOutline"><b>6. Provide an XML
definition</b></a></p>
</li>
<li>
<p><a href="#AssertionDefinitions"><b>7. Specify Semantics
Clearly</b></a></p>
</li>
<li>
<p><a href="#DefineIgnorable"><b>8. Document Ignorable
Behavior</b></a></p>
</li>
<li>
<p><a href="#ignorableAssertions"><b>9. Document Use of the
Ignorable Attribute in XML</b></a></p>
</li>
<li>
<p><a href="#bp-assertion-xml-allow-optional"><b>10. Assertion
Authors should allow use of wsp:Optional</b></a></p>
</li>
<li>
<p><a href="#bp-not-necessary-to-understand-a-message"><b>11.
Assertions should not describe message semantics</b></a></p>
</li>
<li>
<p><a href="#bp-assertion-duplication"><b>12. Avoid Duplication of
Assertions</b></a></p>
</li>
<li>
<p><a href="#bp-assertion-parameters"><b>13. Use Parameters for
Useful Information</b></a></p>
</li>
<li>
<p><a href="#bp-dependent-behaviors"><b>14. Use Nested Assertions
for Dependent Behaviors</b></a></p>
</li>
<li>
<p><a href="#bp-declare-nested-assertions"><b>15. Enumerate Nested
Assertions</b></a></p>
</li>
<li>
<p><a href="#bp-discourage-domain-specific-intersection"><b>16.
Discourage Domain Specific Intersection</b></a></p>
</li>
<li>
<p><a href="#bp-entire-mep-for-optional"><b>17. Consider entire
message exchange pattern when specifying Assertions that represent
optional behavior related to a subset of that message exchange
pattern when considering appropriate policy subject attachment
points</b></a></p>
</li>
<li>
<p><a href="#bp-limitoptional-assertion-use"><b>18. Limit use of an
Optional Assertion</b></a></p>
</li>
<li>
<p><a href="#bp-indicate-optional-assertion-use"><b>19. Indicate
use of an Optional Assertion</b></a></p>
</li>
<li>
<p><a href="#bp-assertion-semantics"><b>20. Semantics Independent
of Attachment Mechanisms</b></a></p>
</li>
<li>
<p><a href="#bp-semantics-multiple-same-type"><b>21. Describe
Semantics of Multiple Assertions of Same Type</b></a></p>
</li>
<li>
<p><a href="#bp-leverage-defined-attachment-mechanisms"><b>22.
Leverage Defined Attachment Mechanisms</b></a></p>
</li>
<li>
<p><a href="#bp-use-defined-policy-subjects"><b>23. Use Defined
Policy Subjects</b></a></p>
</li>
<li>
<p><a href="#bp-identify-policy-subjects"><b>24. Identify Policy
Subjects</b></a></p>
</li>
<li>
<p><a href="#bp-WSDL-policy-subject"><b>25. Specify WSDL Policy
Subject(s)</b></a></p>
</li>
<li>
<p><a href="#bp-WSDL-consider-scope"><b>26. Consider Scope of
Attachment Points</b></a></p>
</li>
<li>
<p><a href="#bp-WSDL-policy-subject-Granularity"><b>27. Choose the
Most Granular WSDL Policy Subject</b></a></p>
</li>
<li>
<p><a href="#bp-WSDL-multiple-policy-subjects"><b>28. Define Rules
for Attachment of an Assertion type to Multiple WSDL policy
subjects</b></a></p>
</li>
<li>
<p><a href="#bp-WSDL-preferred-attachment-point"><b>29. Specify
Preferred WSDL Attachment Point</b></a></p>
</li>
<li>
<p><a href="#bp-UDDI-tmodels"><b>30. Use defined tModels when
appropriate</b></a></p>
</li>
<li>
<p><a href="#bp-specify-composition"><b>31. Specify Composition
with Related Assertions</b></a></p>
</li>
<li>
<p><a href="#bp-independent-assertions"><b>32. Independent
Assertions for Different Versions of a Behavior</b></a></p>
</li>
<li>
<p><a href="#bp-policy-subject-change"><b>33. Document changes to
policy subject</b></a></p>
</li>
</ul>
</div>
<div class="div1">
<h2><a name="Assertions" id="Assertions"></a>3. What is an
Assertion?</h2>
<p>An assertion is a piece of metadata that describes a capability
related to a specific domain that has chosen to express their
capabilities via the WS-Policy expressions. Sets of domain-specific
assertions are typically defined in a dedicated specification that
describes their semantics, applicability and scoping requirements
as well as their data type definition using XML Schema
[<cite><a href="#XMLSchemaPart1">XML Schema
Structures</a></cite>].</p>
<p>Policy assertions representing shared and visible behaviors are
useful pieces of metadata to enable interoperability and tooling
for automation. The key to understanding when to design policy
assertions is to have clarity on the characteristics of a behavior
represented by a policy assertion. Some useful ways to discover
relevant behaviors are to ask questions like the following:</p>
<ul>
<li>
<p>Is this behavior a requirement?</p>
</li>
<li>
<p>Is the behavior visible?</p>
<p>A visible behavior refers to a requirement that manifests itself
on the wire. Web services provide interoperable machine-to-machine
interaction among disparate systems. Web service interoperability
is the capability of disparate systems to exchange data using
common data formats and protocols supporting characteristics such
as messaging, security, reliability and transaction. Such data
formats and protocols manifest on the wire. Providers and
requesters rely on wire messages conforming to such formats and
protocols to achieve interoperability.</p>
<p>If an assertion describes a behavior that does not manifest on
the wire then the assertion will not impact the interoperability of
wire messages, but may still be relevant to enabling an
interoperable interaction. For example, a provider may not wish to
interact unless a client can accept an assertion describing
provider behavior. An example is an assertion that describes the
privacy notice information of a provider and the associated
regulatory safeguard in place on the provider's side. For cases
where the provider does not intend the assertion to impact
interoperability it may mark it as ignorable.</p>
<p>If an assertion has no wire or message-level visible behavior
then the interacting participants may require some sort of
additional mechanism to indicate compliance with the assertion and
to enable dispute resolution. Introducing an additional
non-repudiation mechanism adds unnecessary complexity to processing
a policy assertion.</p>
</li>
<li>
<p>Does the behavior apply to two or more Web service
participants?</p>
<p>A shared behavior refers to a requirement that is relevant to an
interoperable Web service interaction and involves two or more
participants. If an assertion only describes one participant's
behavior the assertion may still be relevant to enabling an
interoperable interaction. An example is the use of logging or
auditing by the provider. If an assertion only describes one
participant's behavior then the assertion may be marked as
ignorable (indicating it does not impact interoperability). An
ignorable policy assertion is ignored for lax policy intersection.
If an assertion is not an ignorable assertion then it is deemed
important for agreement between both parties.</p>
</li>
<li>
<p>Does the behavior have an implied scoping to a policy subject
such as service, endpoint, operation and message?</p>
</li>
<li>
<p>Is there a requirement that a choice must be made for successful
interaction?</p>
<p>Sometimes providers and requesters are required to engage in
certain behaviors. The use of optimization and reliable messaging
are two examples.</p>
</li>
</ul>
<p>There are already many examples in the industry that adhere to
the above practices, such as <cite><a href="#WS-RM-Policy">Web
Services Reliable Messaging Policy Assertion</a></cite> and
<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>.
Some common characteristics from these documents may be considered
as <em>best practices</em> for new Assertion Authors:</p>
<ul>
<li>
<p>Specify both the syntax and the semantics of the assertions</p>
</li>
<li>
<p>If nested or parameterized assertions are defined, be clear
about their usage</p>
</li>
<li>
<p>Describe the policy subjects the assertions can be attached
to.</p>
</li>
</ul>
<p>In this document we will explain why these practices should be
followed so that the assertion developers defining such a
specification will be well informed and able to adequately specify
assertions for their domain.</p>
<p>It is expected that consumers of the metadata specified by the
Assertion Authors will also benefit from understanding these
practices as it will help them utilize the assertions in the
context of the WS-Policy framework. A result of following the best
practices will be an assertion specification that describes a
contract for the consumers and providers of the capabilities and
constraints of the domain.</p>
</div>
<div class="div1">
<h2><a name="assertion-authors" id="assertion-authors"></a>4. Who
is involved in authoring Assertions?</h2>
<p>In order for the policy framework to enable communities to
express their own domain knowledge, it is necessary to provide
basic functionality that all domains could exploit and then allow
points of extension where authors of the various WS-Policy
assertions for a particular domain can provide additional
semantics.</p>
<p>Some policy assertions specify traditional requirements and
capabilities that will ultimately manifest on the wire (e.g.,
authentication scheme, transport protocol selection). Other policy
assertions have no wire manifestation yet are critical to proper
service selection and usage (e.g., privacy policy, QoS
characteristics). WS-Policy provides a single policy grammar to
allow both kinds of assertions to be reasoned about in a consistent
manner.</p>
<div class="div2">
<h3><a name="roles" id="roles"></a>4.1 Roles and
Responsibilities</h3>
<p>Below we capture some of the characteristics of the roles and
responsibilities for the authors, consumers and providers.</p>
<div class="div3">
<h4><a name="domain-owners" id="domain-owners"></a>4.1.1 Assertion
Authors</h4>
<p>Assertion Authors are part of a community that chooses to
exploit the WS-Policy Framework by creating their own
specifications to define a set of assertions that express the
capabilities and constraints of that target domain. The WS-Policy
Framework is based on a declarative model, meaning that it is
incumbent on the Assertion Authors to define both the semantics of
the assertions as well as the scope of their target domain in their
specification. The set of metadata for any particular domain will
vary in the granularity of assertion specification required. It is
the intent of this document to help communities utilize the
framework in such a way that multiple WS-Policy domains can
co-exist and consumers and providers can utilize the framework
consistently across domains.</p>
<p>Assertion authors should review the conformance sections of the
WS-Policy Framework and Attachment specifications and an assertion
must adhere to all the constraints contained in the Framework and
Attachment specifications.</p>
<p>Assertion Authors should also specify a policy subject. For
instance, if a policy assertion were to be used with WSDL, an
assertion description should specify a WSDL policy subject.</p>
<p>An example of a domain specification that follows these
practices is the WS-SecurityPolicy specification [<cite><a href=
"#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]. The
WS-SecurityPolicy authors have defined the scope of their target
domain (security) as follows:</p>
<p><em>"This document [WS-SecurityPolicy] defines a set of security
policy assertions for use with the WS-Policy framework with respect
to security features provided in WSS: SOAP Message Security,
WS-Trust and WS-SecureConversation. This document takes the
approach of defining a base set of assertions that describe how
messages are to be secured. Flexibility with respect to token
types, cryptographic algorithms and mechanisms used, including
using transport level security is part of the design and allows for
evolution over time. The intent is to provide enough information
for compatibility and interoperability to be determined by web
service participants along with all information necessary to
actually enable a participant to engage in a secure exchange of
messages."</em></p>
<p>An example of scoping individual assertions to policy subjects
is also provided by the WS-Security Policy specification in
Appendix A.</p>
</div>
<div class="div3">
<h4><a name="consumers" id="consumers"></a>4.1.2 Consumers</h4>
<p>A consumer of WS-Policy Assertions can be any entity that is
capable of parsing a WS-Policy XML expression and selecting one
alternative from the policy. This selected alternative is then used
to govern the creation of a message to send to the subject to which
the policy alternative was attached. The WS-Policy Attachment
specification defines a set of attachment mechanisms for use with
common web service subjects: WSDL definitions [<cite><a href=
"#WSDL11">WSDL 1.1</a></cite>, <cite><a href="#WSDL20">WSDL 2.0
Core Language</a></cite>], and UDDI directory entries
[<cite><a href="#UDDIAPI20">UDDI API 2.0</a></cite>, <cite><a href=
"#UDDIDataStructure20">UDDI Data Structure 2.0</a></cite>,
<cite><a href="#UDDI30">UDDI 3.0</a></cite>].</p>
<p>In the degenerate case, a human could read the XML and determine
if a message could be constructed conformant to the advertised
policy.</p>
<p>It is expected that consumers of WS-Policy will include a wide
range of client configurations, from stand alone client
applications to "active" web service requesters that are capable of
adapting to the constraints and capabilities expressed in a
WS-Policy document and modifying their own configurations
dynamically.</p>
</div>
<div class="div3">
<h4><a name="providers" id="providers"></a>4.1.3 Providers</h4>
<p>A provider who expresses capabilities and requirements of a Web
service as policies can be any web service implementation that can
specify its on-the-wire message behavior as a policy expression
that conforms to the Web Services Policy 1.5 - Framework
[<cite><a href="#WS-Policy">Web Services Policy
Framework</a></cite>] and Web Services Policy 1.5 - Attachment
[<cite><a href="#WS-PolicyAttachment">Web Services Policy
Attachment</a></cite>] specifications. The Web Services Policy 1.5
- Attachment specification has defined a set of subjects and an
extensible mechanism for attaching policies to web services
subjects.</p>
<p>When deploying services with policies it is useful for providers
to anticipate how to evolve their services capabilities over time.
If forward compatibility is a concern in order to accommodate
compatibility with different and potentially new clients, providers
should refer to <a href="#versioning-policy-assertions"><b>6.
Versioning Policy Assertions</b></a> and <cite><a href=
"#WS-Policy-Primer">Web Services Policy Primer</a></cite> that
describes service and policy assertion evolution.</p>
</div>
</div>
</div>
<div class="div1">
<h2><a name="general-guidelines" id="general-guidelines"></a>5.
General Guidelines for Assertion Authors</h2>
<p>As Assertion Authors begin the task of inventing XML dialects to
represent policy assertions they can take advantage of WS-Policy
building on XML principles and XML Schema validation in their
design. WS-Policy relies on the QName of a policy assertion being
an XML element but allows Assertion Authors to optionally provide
additional semantics through nesting assertions, or specifying
assertion parameters. This section covers several aspects of
assertion design and provides some answers to the following
questions:</p>
<ul>
<li>
<p>What is the intended use of the policy assertion?</p>
</li>
<li>
<p>Which authoring style will be used?</p>
</li>
<li>
<p>Is this a new policy domain? Does it need to compose with other
domains?</p>
</li>
<li>
<p>How complex are the assertions?</p>
</li>
<li>
<p>Is there a need to consider nesting?</p>
</li>
<li>
<p>Do optional behaviors need to be represented?</p>
</li>
</ul>
<div class="div2">
<h3><a name="assertion-target" id="assertion-target"></a>5.1
Assertions and Their Target Use</h3>
<p>Assertion Authors should understand the functionality that the
WS-Policy framework provides and apply the knowledge of the policy
framework processing when defining the set of assertions.</p>
<p>Assertions can be simple or they can be complex. Assertion
Authors may choose to specify multiple peer assertions, each
carrying the semantic of a particular behavior, or they may choose
to specify assertions that contain assertion parameters and/or
nested policy expressions (nested assertions), where each nested
assertion of which relates to an aspect of the behavior, yet
encapsulated within a single assertion. There are advantages to
simplifying the set of assertions. The ultimate goal of policy is
to enable interoperability. By keeping assertion design as simple
as possible, Assertion Authors will more likely be able to meet
that objective.</p>
<p>Assertion Authors need to have a specific goal in mind for the
assertions that they author. Assertion specifications should
include a detailed specification of the assertion’s semantics and a
set of valid policy subjects to which the assertion maybe attached.
The specification should also include the scope of the assertion in
the context of a particular policy subject. For example, an
assertion with Endpoint Policy Subject can be scoped to a given
message exchange with that endpoint, or it can be scoped to all
messages exchanged with that endpoint. The former case permits a
client to select a different alternative with each successive
message exchange. Finally, the ability to combine individual
assertions may also need to be considered. For example, if an
assertion applies to the SOAP protocol, it would be necessary to
consider how its presence must interact with other policy
assertions that are defined for security.</p>
<p>Assertion Authors should include the following items in an
assertion specification:</p>
<ul>
<li>
<p>The definition of the assertion's semantic (See best practice
<a href="#AssertionDefinitions"><b>7. Specify Semantics
Clearly</b></a>).</p>
</li>
<li>
<p>The specification of the set of valid policy subjects to which
an assertion may be attached (See best practice <a href=
"#bp-WSDL-policy-subject"><b>25. Specify WSDL Policy
Subject(s)</b></a>).</p>
</li>
<li>
<p>The scope of the assertion in the context of a particular policy
subject (See best practices in Section <a href=
"#levels-of-abstraction"><b>5.7 Considerations for Policy
Attachment</b></a>).</p>
</li>
<li>
<p>Any composition considerations if the assertion is used with
other assertions in a context (See best practice <a href=
"#bp-specify-composition"><b>31. Specify Composition with Related
Assertions</b></a>).</p>
</li>
</ul>
<p>The WS-Policy Attachment specification defines a number of
different policy subjects to which an assertion can be attached.
For attaching to WSDL subjects see <a href=
"#levels-of-abstraction"><b>5.7 Considerations for Policy
Attachment</b></a> for more detail. Additionally, the framework
provides for the means to extend the set of policy subjects beyond
the set of subjects defined in the WS-Policy Attachment
specification.</p>
<div class="boxedtext">
<p><a name="bp-compatibility-tests" id=
"bp-compatibility-tests"></a><span class="practicelab">Best
Practice 1: Define assertions relevant to compatibility
tests</span></p>
<p class="practice">Assertion authors should define assertions for
behaviors that are relevant to compatibility assessment, such as
web service protocols that manifest on the wire.</p>
</div>
<p>Assertion authors may define assertions that are not related to
compatibility assessment. These assertions may be used to
accurately describe behaviour, even if they do not affect
compatibility. WS-Policy has the wsp:Ignorable attribute that may
be used for indicating assertions that are not related to
compatibility assessment, described in <a href="#Ignorable"><b>5.5
Designating Ignorable Behavior</b></a></p>
<div class="boxedtext">
<p><a name="bp-ignorable-for-not-related-to-compatibility-tests"
id="bp-ignorable-for-not-related-to-compatibility-tests"></a><span class="practicelab">Best
Practice 2: Mark Ignorable Assertions not related to
compatibility</span></p>
<p class="practice">Assertion authors should recommend that
assertions that are not relevant to compatibility assessment be
marked with the wsp:Ignorable attribute.</p>
</div>
</div>
<div class="div2">
<h3><a name="compact-full" id="compact-full"></a>5.2 Authoring
Styles</h3>
<p>WS-Policy supports two different authoring styles, compact form
and normal form. A compact form is one in which an expression
consists of three constructs: an attribute to decorate an assertion
(to indicate whether it is required or optional), semantics for
recursively nested policy operators, and a policy
reference/inclusion mechanism. A policy expression in the compact
form can be translated into its normal form using the policy
normalization algorithm described in the Web Service Policy
Framework (see section 4.3 Compact Policy Expression).</p>
<p>The two forms of a policy expression are semantically
equivalent. When multiple alternatives are present in a policy, the
normal form may express the choices more explicitly. On the other
hand, the compact form may be more readable for humans when an
assertion is marked as optional using the <code>wsp:optional</code>
attribute. A policy processor may normalize a policy expression
originally authored in compact form at any time without changing
the semantics of the policy. In general, it is not possible to
guarantee in what form a policy expression would be when it is
processed. As a result, the description for a policy assertion
should not depend on the style used to author a policy expression
that contains the assertion.</p>
<div class="boxedtext">
<p><a name="bp-semantics-and-form" id=
"bp-semantics-and-form"></a><span class="practicelab">Best Practice
3: Semantics Independent of the Form</span></p>
<p class="practice">The semantics of an assertion should be
independent of the form (compact or normal form) of policy
expressions that contain the assertion.</p>
</div>
<p>In the example below, the policy expression is shown in its two
forms, compact and normal. In compact form, the
<code>wsrmp:RMAssertion</code> assertion is augmented by the
<code>wsp:Optional="true"</code> attribute. While the compact form
of the expression might be more human readable, the semantics of
the particular assertion are independent of the form and of the
presence (or absence) of the <code>wsp:optional</code>
attribute.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
5-1.</span> Policy Expression in Compact Form</i></p>
<div class="exampleInner">
<pre>
&lt;wsp:Policy xmlns:wsp='http://www.w3.org/ns/ws-policy'
        xmlns:sp='http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702'
        xmlns:wsrmp='http://docs.oasis-open.org/ws-rx/wsrmp/200608'&gt;
&lt;wsrmp:RMAssertion wsp:Optional="true"/&gt;
  &lt;wsp:ExactlyOne&gt;
    &lt;wsp:All&gt;
      &lt;sp:TransportBinding&gt;
        &lt;wsp:Policy&gt;
          &lt;sp:TransportToken&gt;
            &lt;wsp:Policy&gt;
                  &lt;sp:HttpsToken&gt;
                    &lt;wsp:Policy&gt;
                     &lt;sp:RequireClientCertificate/&gt;
                    &lt;/wsp:Policy&gt;
                  &lt;/sp:HttpsToken&gt;
            &lt;/wsp:Policy&gt;
          &lt;/sp:TransportToken&gt;
        &lt;/wsp:Policy&gt;
      &lt;/sp:TransportBinding&gt;
    &lt;/wsp:All&gt;
  &lt;/wsp:ExactlyOne&gt;
&lt;/wsp:Policy&gt;
</pre></div>
</div>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
5-2.</span> Policy Expression in Normal Form</i></p>
<div class="exampleInner">
<pre>
&lt;wsp:Policy xmlns:wsp='http://www.w3.org/ns/ws-policy'
        xmlns:sp='http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702'
        xmlns:wsrmp='http://docs.oasis-open.org/ws-rx/wsrmp/200608'&gt;
  &lt;wsp:ExactlyOne&gt;
    &lt;wsp:All&gt;
      &lt;wsrmp:RMAssertion/&gt;
      &lt;sp:TransportBinding&gt;
        &lt;wsp:Policy&gt;
          &lt;sp:TransportToken&gt;
            &lt;wsp:Policy&gt;
                  &lt;sp:HttpsToken&gt;
                    &lt;wsp:Policy&gt;
                      &lt;sp:RequireClientCertificate/&gt;
                    &lt;/wsp:Policy&gt;
                  &lt;/sp:HttpsToken&gt;
            &lt;/wsp:Policy&gt;
          &lt;/sp:TransportToken&gt;
        &lt;/wsp:Policy&gt;
      &lt;/sp:TransportBinding&gt;
    &lt;/wsp:All&gt;

    &lt;wsp:All&gt;
      &lt;sp:TransportBinding&gt;
        &lt;wsp:Policy&gt;
          &lt;sp:TransportToken&gt;
            &lt;wsp:Policy&gt;
                  &lt;sp:HttpsToken&gt;
                    &lt;wsp:Policy&gt;
                      &lt;sp:RequireClientCertificate/&gt;
                    &lt;/wsp:Policy&gt;
                  &lt;/sp:HttpsToken&gt;
            &lt;/wsp:Policy&gt;
          &lt;/sp:TransportToken&gt;
        &lt;/wsp:Policy&gt;
      &lt;/sp:TransportBinding&gt;
    &lt;/wsp:All&gt;
  &lt;/wsp:ExactlyOne&gt;
&lt;/wsp:Policy&gt;
</pre></div>
</div>
</div>
<div class="div2">
<h3><a name="new-guidelines-domains" id=
"new-guidelines-domains"></a>5.3 Considerations when Modeling New
Assertions</h3>
<p>When creating a new policy domain, it is important to understand
how policy expressions are used by a framework implementation that
has followed the specifications.</p>
<p>The examples given in this document are based on existing
assertions such as WS-SecurityPolicy and WS-RM Policy. These policy
expressions represent web services message exchange requirements,
but policy authoring can be done by individual groups that wish to
represent web services application requirements and deployments
that wish to reuse the WS-Policy framework in order to enable
dynamic negotiation of business requirements and capabilities at
runtime.</p>
<div class="div3">
<h4><a name="minimal-approach" id="minimal-approach"></a>5.3.1
Minimal approach</h4>
<p>New Assertion Authors are encouraged to try to not overload
assertions. A single assertion indicates a single behavior. Sets of
assertions can by grouped by an operator "All". This indicates that
there is a relationship between the assertions.</p>
<p>If grouping is utilized, choices between such groupings can be
indicated by an "ExactlyOne" operator. This basic set of operators
allows Assertion Authors a wide range of options for expressing the
possible combinations of assertions within their domain.</p>
<p>It requires a good deal of effort to evaluate the capabilities
of a domain and capture them in a way that reflects the options of
the domain if the domain has a lot of assertions to define.
Interoperability testing of new policy domains is recommended to
ensure that consumers and providers are able to use the new domain
assertions. To facilitate proper progression of an assertion,
Assertion Authors should start with a simple working assertion that
allows extensibility. As the design work progresses, one may add
more parameters or nested policy assertions to meet one's
interoperability needs.</p>
<div class="boxedtext">
<p><a name="bp-assertion-start" id=
"bp-assertion-start"></a><span class="practicelab">Best Practice 4:
Start with a Simple Assertion</span></p>
<p class="practice">Assertion Authors should start with a simple
working assertion that allows assertion parameter
extensibility.</p>
</div>
<p>New Assertion Authors are encouraged to look at <cite><a href=
"#WS-RM-Policy">Web Services Reliable Messaging Policy
Assertion</a></cite> to see an example of a relatively simple
domain that has defined three assertions. Assertion Authors are
encouraged to look at <cite><a href=
"#WS-SecurityPolicy">WS-SecurityPolicy</a></cite> to see an example
of a complex domain that has been decomposed into a set of policy
expressions.</p>
</div>
<div class="div3">
<h4><a name="QName_and_XML_Information_Set_representation" id=
"QName_and_XML_Information_Set_representation"></a>5.3.2 QName and
XML Information Set representation</h4>
<p>Web Services Policy language allows Assertion Authors to invent
their own XML dialects to represent policy assertions. The policy
language relies only on the policy assertion XML element QName.
This QName is unique and identifies the behavior represented by a
policy assertion. Assertion Authors have the option to represent an
assertion parameter as a child element (by leveraging natural XML
nesting) or an attribute of an assertion. The general guidelines on
when to use XML elements versus attributes apply. Use a unique
QName to identify a distinct behavior.</p>
<div class="boxedtext">
<p><a name="bp-unique-qnames" id=
"bp-unique-qnames"></a><span class="practicelab">Best Practice 5:
Use Unique QNames</span></p>
<p class="practice">Assertion Authors should use a unique QName to
identify a distinct behavior.</p>
</div>
<div class="boxedtext">
<p><a name="XMLOutline" id="XMLOutline"></a><span class=
"practicelab">Best Practice 6: Provide an XML definition</span></p>
<p class="practice">Assertion authors should provide an XML schema
definition to specify the syntax of an assertion. A reader-friendly
description such as an XML outline (see below) is also useful.</p>
</div>
<p>An example of a specification that provides an XML Outline is
the Web Services Reliable Messaging Policy document [<cite><a href=
"#WS-RM-Policy">Web Services Reliable Messaging Policy
Assertion</a></cite>]. The definition of the outline syntax used in
that specification is found in its Terminology section (1.1). As an
example of the outline syntax in use, the following outline has
been copied from the aforementioned specification.</p>
<div class="exampleOuter">
<div class="exampleInner">
<pre>
 &lt;wsrmp:RMAssertion [wsp:Optional="true"]? ...&gt;
   &lt;wsp:Policy &gt;
     [ &lt;wsrmp:SequenceSTR/&gt; |
       &lt;wsrmp:SequenceTransportSecurity/&gt; ] ?
     &lt;wsrmp:DeliveryAssurance/&gt;
       &lt;wsp:Policy &gt;
        [ &lt;wsrmp:ExactlyOnce/&gt; |
          &lt;wsrmp:AtLeastOnce/&gt; |
          &lt;wsrmp:AtMostOnce/&gt; ]
        &lt;wsrmp:InOrder/&gt; ?
       &lt;/wsp:Policy&gt;
     &lt;/wsrmp:DeliveryAssurance&gt; ] ?
    &lt;/wsp:Policy&gt;
 &lt;/wsrmp:RMAssertion/&gt;

</pre></div>
</div>
<p>The syntax of an assertion can be represented using an XML
outline (plus an XML schema document). If the assertion has a
nested policy expression then the assertion XML outline can
enumerate the nested assertions that are allowed. An example is the
following:</p>
<div class="exampleOuter">
<div class="exampleInner">
<pre>
 &lt;sp:IssuedToken sp:IncludeToken="xs:anyURI"? ... &gt;
  &lt;sp:Issuer&gt; wsa:EndpointReferenceType&lt;/sp:Issuer&gt;?
  &lt;sp:RequestSecurityTokenTemplate TrustVersion="xs:anyURI"? &gt;
    ...
  &lt;/sp:RequestSecurityTokenTemplate &gt;
  &lt;wsp:Policy &gt;
    &lt;sp:RequireDerivedKeys /&gt; ?
    &lt;sp:RequireExternalReference /&gt; ?
    &lt;sp:RequireInternalReference /&gt; ?
    ...
  &lt;/wsp:Policy&gt; ?
  ...
&lt;/sp:IssuedToken&gt;


</pre></div>
</div>
<div class="boxedtext">
<p><a name="AssertionDefinitions" id=
"AssertionDefinitions"></a><span class="practicelab">Best Practice
7: Specify Semantics Clearly</span></p>
<p class="practice">Assertion authors should clearly and completely
specify the semantics of a policy assertion.</p>
</div>
<div class="boxedtext">
<p><a name="DefineIgnorable" id="DefineIgnorable"></a><span class=
"practicelab">Best Practice 8: Document Ignorable
Behavior</span></p>
<p class="practice">An assertion description should include
guidance as to the use of (or constraint against the use of) the
wsp:Ignorable attribute to indicate whether or not the behavior
indicated by the QName may be ignored by policy intersection.</p>
</div>
<div class="boxedtext">
<p><a name="ignorableAssertions" id=
"ignorableAssertions"></a><span class="practicelab">Best Practice
9: Document Use of the Ignorable Attribute in XML</span></p>
<p class="practice">An Assertion Author should document, in the XML
outline and/or schema for the assertion, whether or not the
assertion allows for the use of the wsp:Ignorable attribute.</p>
</div>
<p>The Policy Framework provides two modes of authoring policy
expressions: compact and normal form. One of the mechanisms that
the Policy Framework provides to policy authors for purposes of
writing compact policy expressions is the <code>wsp:Optional</code>
attribute. Assertion Authors should allow for the use of the
<code>wsp:Optional</code> attribute in the XML outline and/or
schema definition of an assertion as this will allow policy
expression authors to compose compact policy expressions.</p>
<div class="boxedtext">
<p><a name="bp-assertion-xml-allow-optional" id=
"bp-assertion-xml-allow-optional"></a><span class=
"practicelab">Best Practice 10: Assertion Authors should allow use
of wsp:Optional</span></p>
<p class="practice">An assertion's XML outline and/or schema
definition should allow the use of the wsp:Optional attribute so as
to enable policy authors to compose compact policy expressions.</p>
</div>
<p>For example, consider the following two equivalent policy
expressions:</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
5-5.</span> Normal form expression:</i></p>
<div class="exampleInner">
<pre>
&lt;wsp:Policy&gt;
  &lt;wsp:ExactlyOne&gt;
    &lt;wsp:All&gt;
    &lt;wsam:Addressing&gt;
        &lt;wsp:Policy/&gt;
    &lt;/wsam:Addressing&gt;
    &lt;/wsp:All&gt;
    &lt;wsp:All&gt;
    &lt;/wsp:All&gt;
  &lt;/wsp:ExactlyOne&gt;
&lt;/wsp:Policy&gt;
</pre></div>
</div>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
5-6.</span> Compact form expression:</i></p>
<div class="exampleInner">
<pre>
&lt;wsp:Policy&gt;
    &lt;wsam:Addressing wsp:Optional="true"&gt;
        &lt;wsp:Policy/&gt;
    &lt;/wsam:Addressing&gt;
&lt;/wsp:Policy&gt;
</pre></div>
</div>
<p>If the assertion author had not provided for the
<code>wsp:Optional</code> attribute to be included on the
assertion, then policy expression authors would be forced to
express the optionality of a behavior as two explicit policy
alternatives, one with and one without that assertion when
including assertions of that type in their policies.</p>
</div>
<div class="div3">
<h4><a name="self-describing" id="self-describing"></a>5.3.3 Self
Describing Messages</h4>
<p>WS-Policy is intended to communicate the requirements,
capabilities and behaviors of nodes that provide the message's
path, not specifically to declare properties of the message
semantics. One of the advantages of Web services is that an XML
message can be stored and later examined (e.g. as a record of a
business transaction) or interpreted by an intermediary; however,
if information that is necessary to understand a message is not
available, these capabilities suffer.</p>
<p>Policy assertions should not be used to express the semantics of
a message. Rather, if a property is required to understand a
message, it should be communicated in the message, or be made
available by some other means (e.g., being referenced by a URI in
the message) instead of being communicated as a policy element.
Note that there are other specifications that target specification
of semantics of a message, such as <cite><a href=
"#SAWSDL">SAWSDL</a></cite>.</p>
<p>If the messages could not be made self describing by utilizing
additional properties present in the message as required by the
assertion, it would be necessary to determine the behaviors engaged
at runtime by additional means. A general protocol that aids in
determining such behaviors may be utilized, however a standard
protocol for this purpose is currently not available to ensure
interoperability. Thus, a private protocol should be used with
care.</p>
<p>Another approach is to use of the assertion to selectively apply
to subjects. For example, a dedicated endpoint may be allocated to
ensure the engagement of a behavior that is expressed by a policy
assertion. This approach can be considered when messages cannot be
self describing.</p>
<p>Policy assertions should not be used to express the semantics of
a message. Firstly, an assertion type indicates a <em>runtime</em>
behavior. Secondly, Assertion Authors need to indicate how the
runtime behavior represented in the assertion type can be inferred
or indicated from a message at runtime. If there is a need for the
behavior to be represented in a persistent way or if there is a
need for additional data or metadata that is present in a message
to be persisted, it should be incorporated into the assertion
design or in the message itself. In essence, the Assertion Authors
should consider how to make messages self describing when utilizing
their assertions by specifying additional properties, headers, etc.
that must be present in a message as part of their assertion
design.</p>
<div class="boxedtext">
<p><a name="bp-not-necessary-to-understand-a-message" id=
"bp-not-necessary-to-understand-a-message"></a><span class=
"practicelab">Best Practice 11: Assertions should not describe
message semantics</span></p>
<p class="practice">Assertion Authors should not define policy
assertions to represent information that is necessary to understand
a message.</p>
</div>
<p>For example, if the details of a message's encryption ( e.g.,
the cipher used, etc) are expressed in policy that isn't attached
to the message, it isn't possible to later decipher it. This is
very different from expressing, in policy, what ciphers (and so
forth) are supported by a particular endpoint, or those that are
required in a particular message; the latter are the intended uses
of the WS-Policy framework.</p>
</div>
<div class="div3">
<h4><a name="single-domains" id="single-domains"></a>5.3.4 Single
Domains</h4>
<p>When considering the creation of a new domain of policy
assertions, it is important to identify whether or not the domain
is self-contained or at least if a subset of the domain can be well
defined. A domain that expresses a broad set of capabilities will
also need to have a community supporting implementations of these
capabilities to provide value to the consumers. Ultimately it is
the consumers and providers that will determine whether a
particular set of assertions correctly characterize a domain. A new
community should avoid duplicating assertions that have already
been defined as this will create ambiguity not clarification. New
Assertion Authors should focus on creating assertions for those
specific constraints and capabilities that do not overlap with
other domains but that communicate new functionality.</p>
<p>The model advocated for new assertion development is a
cooperative marketplace [some might say it is an "opt-in" model].
The providers of services need to find value in the set of
assertions or they will not include the assertions in their service
descriptions.</p>
<p>It is the responsibility of the Assertion Authors to avoid
duplication of assertions. A review by a broad community is the
best way to ensure that the granularity of a set of domain
assertions is appropriate.</p>
<div class="boxedtext">
<p><a name="bp-assertion-duplication" id=
"bp-assertion-duplication"></a><span class="practicelab">Best
Practice 12: Avoid Duplication of Assertions</span></p>
<p class="practice">Assertion Authors should reuse an existing
assertion (rather than create a new one) whenever possible.</p>
</div>
</div>
<div class="div3">
<h4><a name="order-of-behaviors" id="order-of-behaviors"></a>5.3.5
Order of Behaviors</h4>
<p>A policy alternative is a collection of zero or more policy
assertions. Assertions within a policy alternative are not
ordered.</p>
<p>The order of assertions in a policy alternative and order in
which behaviors (indicated by assertions) are applied are two
distinct concepts. The order of assertions in a policy alternative
has no bearing on the order in which behaviors are applied.</p>
<p>Specifying the order in which behaviors are applied is outside
the scope of the Web Services Policy Framework. However, the
Framework says that assertion authors can write assertions that
indicate the order in which behaviors are applied.</p>
<p>According to the SOAP processing model, the order of headers and
body processing (for behaviors such as addressing, security,
reliability and transaction) is at the discretion of the SOAP node
and SOAP-based protocols may be used to control the order of
processing.</p>
<p>The Web Services Security specification provides producers with
a choice of signing a message before encrypting or signing a
message after encrypting. That is, WS-Security 1.1, section 8 says,
lines 1173-1183 - says "Finally, if a producer wishes to sign a
message before encryption, then following the ordering rules laid
out in section 5, "Security Header", they SHOULD first prepend the
signature element to the <code>wsse:Security</code> header, and
then prepend the encryption element, ... Likewise, if a producer
wishes to sign a message after encryption, they SHOULD first
prepend the encryption element to the <code>wsse:Security</code>
header, and then prepend the signature element."</p>
<p>The Web Services Security Policy specification provides
assertions which let users control whether to sign the message
before encrypting or sign it after encrypting.</p>
<p>In the example below, the SignBeforeEncrypting assertion
requires producers to sign a message before encrypting.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
5-7.</span> SignBeforeEncrypting assertion</i></p>
<div class="exampleInner">
<pre>
&lt;wsp:Policy&gt;
  &lt;sp:AsymmetricBinding&gt;
    &lt;wsp:Policy&gt;
      &lt;sp:IncludeTimestamp /&gt;
      &lt;sp:SignBeforeEncrypting /&gt;
      &lt;sp:EncryptSignature /&gt;
      &lt;sp:ProtectTokens /&gt;
    &lt;wsp:Policy/&gt;
  &lt;/sp:AsymmetricBinding&gt;
  &lt;wsam:Addressing&gt;...&lt;/wsam:Addressing&gt;
&lt;/wsp:Policy&gt;
</pre></div>
</div>
<p>In the example below, the EncryptBeforeSigning assertion
requires producers to sign a message after encrypting.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
5-8.</span> EncryptBeforeSigning assertion</i></p>
<div class="exampleInner">
<pre>
&lt;wsp:Policy&gt;
  &lt;sp:AsymmetricBinding&gt;
    &lt;wsp:Policy&gt;
      &lt;sp:IncludeTimestamp /&gt;
      &lt;sp:EncryptBeforeSigning /&gt;
      &lt;sp:EncryptSignature /&gt;
      &lt;sp:ProtectTokens /&gt;
    &lt;wsp:Policy/&gt;
  &lt;/sp:AsymmetricBinding&gt;
  &lt;wsam:Addressing&gt;...&lt;/wsam:Addressing&gt;
&lt;/wsp:Policy&gt;
</pre></div>
</div>
</div>
</div>
<div class="div2">
<h3><a name="comparison" id="comparison"></a>5.4 Comparison of
Nested and Parameterized Assertions</h3>
<p>There are two different ways to provide additional information
in an assertion beyond its type: assertion parameters and nested
policy expressions. We cover these two cases below followed by a
comparison of these approaches targeting when to use either of the
two approaches.</p>
<p>The main consideration for choosing between use of parameters or
nested policy expressions is that the framework intersection
algorithm processes nested policy expressions, but does not
consider parameters in the algorithm.</p>
<div class="div3">
<h4><a name="parameterized-assertions" id=
"parameterized-assertions"></a>5.4.1 Assertions with
Parameters</h4>
<p>Policy assertion parameters are the opaque payload of an
assertion. Parameters carry additional useful information for
engaging the behavior described by an assertion and are preserved
through policy processing such as normalization, merge and policy
intersection. Requesters may use policy intersection to select a
compatible policy alternative for an interaction. Assertion
parameters do not affect the outcome of policy intersection unless
the assertion specifies domain specific processing for policy
intersection.</p>
<p>In the XML representation of a policy assertion, the child
elements and attributes of the assertion excluding child elements
and attributes from the policy language namespace name are the
assertion parameters.</p>
<div class="boxedtext">
<p><a name="bp-assertion-parameters" id=
"bp-assertion-parameters"></a><span class="practicelab">Best
Practice 13: Use Parameters for Useful Information</span></p>
<p class="practice">Assertion Authors should represent useful
additive information necessary for engaging the behavior
represented by a policy assertion as assertion parameters.</p>
</div>
<p>In the example below, <code>sp:Body</code> and
<code>sp:Header</code> elements are the two assertion parameters of
the <code>sp:SignedParts</code> policy assertion (this assertion
requires the parts of a message to be protected). These two
parameters identify the parts of a wire message that should be
protected. These parameters carry additional useful information for
engaging the behavior.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
5-9.</span> Policy Assertion with Assertion Parameters</i></p>
<div class="exampleInner">
<pre>
&lt;wsp:Policy&gt;
  &lt;sp:SignedParts&gt;
    &lt;sp:Body/&gt;
    &lt;sp:Header/&gt;
  &lt;/sp:SignedParts&gt;
&lt;/wsp:Policy&gt;
</pre></div>
</div>
</div>
<div class="div3">
<h4><a name="nested-assertions" id="nested-assertions"></a>5.4.2
Nested Assertions</h4>
<p>The framework provides the ability to "nest" policy assertions.
For domains with a complex set of options, nesting provides one way
to indicate dependent elements within a behavior. In particular,
when assertion authors define an assertion type that allows nested
policy expression, it is important to also define the semantics of
that assertion when it contains an empty nested policy expression
(for example:
&lt;wsam:Addressing&gt;&lt;wsp:Policy/&gt;&lt;/wsam:Addressing&gt;).</p>
<p>The following design questions below can help to determine when
to use nested policy expressions:</p>
<ul>
<li>
<p>Are these assertions designed for the same policy subject?</p>
</li>
<li>
<p>Do these assertions represent dependent behaviors?</p>
</li>
</ul>
<p>If the answers are yes to both of these questions then
leveraging nested policy expressions is something to consider. Keep
in mind that a nested policy expression participates in the policy
intersection algorithm. If a requester uses policy intersection to
select a compatible policy alternative then the assertions in a
nested policy expression play a first class role in the outcome. If
there is a nested policy expression, an assertion description
should declare it and enumerate the nested policy assertions that
are allowed. There is one caveat to watch out for: policy
assertions with deeply nested policy can greatly increase the
complexity of a policy and should be avoided when they are not
needed.</p>
<div class="boxedtext">
<p><a name="bp-dependent-behaviors" id=
"bp-dependent-behaviors"></a><span class="practicelab">Best
Practice 14: Use Nested Assertions for Dependent
Behaviors</span></p>
<p class="practice">Assertion Authors should represent dependent
behaviors that are relevant to a compatibility test and apply to
the same policy subject using nested policy assertions.</p>
</div>
<div class="boxedtext">
<p><a name="bp-declare-nested-assertions" id=
"bp-declare-nested-assertions"></a><span class="practicelab">Best
Practice 15: Enumerate Nested Assertions</span></p>
<p class="practice">If there is a nested policy expression, then
the Assertion Authors should enumerate the nested policy assertions
that are allowed.</p>
</div>
<p>Assertion Authors should recognize that the framework can yield
multiple assertions of the same type. The <em>QName</em> of the
assertion is the only vehicle for the framework to match a specific
assertion, NOT the contents of the element. If the assertion is a
parameterized assertion the authors must understand that this type
of assertion will require additional processing by consumers in
order to disambiguate the assertions or to understand the semantics
of the name value pairs, complex content, attribute values
contribution to the processing. The tradeoff is the generality vs.
the flexibility and complexity of the comparison expected for a
domain.</p>
<p>If the assertion authors want to delegate the processing to the
framework, utilizing nesting should be considered. Otherwise,
domain specific comparison algorithms may need to be devised and be
delegated to the specific domain handlers that are not visible to
the WS-Policy framework. However, domain specific intersection
processing reduces interop and increases the burden to implement an
assertion.</p>
<div class="boxedtext">
<p><a name="bp-discourage-domain-specific-intersection" id=
"bp-discourage-domain-specific-intersection"></a><span class=
"practicelab">Best Practice 16: Discourage Domain Specific
Intersection</span></p>
<p class="practice">Assertion authors should only specify domain
specific intersection semantics when policy intersection is
insufficient.</p>
</div>
<p>We will use the WS-SecurityPolicy to illustrate the use of
nested assertions.</p>
<p>Securing messages is a complex usage scenario. The
WS-SecurityPolicy Assertion Authors have defined 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 a Web
service, the consumer must know not only that transport-level
security is required, but also the transport token to use, the
secure transport to use, the algorithm suite to use for performing
cryptographic operations, etc. The <code>sp:TransportBinding</code>
policy assertion can represent these dependent behaviors.</p>
<p>A policy assertion like the <code>sp:TransportBinding</code>
identifies a visible behavior that is a requirement. A nested
policy expression can be used to enumerate the dependent behaviors
on the Transport binding. A nested policy expression is a policy
expression that is a child element of another policy assertion
element. A nested policy expression further qualifies the behavior
of its parent policy assertion.</p>
<p>In the example below, the child Policy element is a nested
policy expression and further qualifies the behavior of the
<code>sp:TransportBinding</code> policy assertion. The
<code>sp:TransportToken</code> is a nested policy assertion of the
<code>sp:TransportBinding</code> policy assertion. The
<code>sp:TransportToken</code> assertion requires the use of a
specific transport token and further qualifies the behavior of the
<code>sp:TransportBinding</code> policy assertion (which already
requires the use of transport-level security for protecting
messages).</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
5-10.</span> Transport Security Policy Assertion</i></p>
<div class="exampleInner">
<pre>
&lt;sp:TransportBinding&gt;
  &lt;Policy&gt;
    &lt;sp:TransportToken&gt;
      &lt;Policy&gt;
        &lt;sp:HttpsToken&gt;
          &lt;wsp:Policy/&gt;
        &lt;/sp:HttpsToken&gt;
      &lt;/Policy&gt;
    &lt;/sp:TransportToken&gt;
    &lt;sp:AlgorithmSuite&gt;
      &lt;Policy&gt;
        &lt;sp:Basic256Rsa15/&gt;
      &lt;/Policy&gt;
    &lt;/sp:AlgorithmSuite&gt;
  &lt;/Policy&gt;
&lt;/sp:TransportBinding&gt;
</pre></div>
</div>
<p>The <code>sp:AlgorithmSuite</code> is a nested policy assertion
of the <code>sp:TransportBinding</code> policy assertion. The
<code>sp:AlgorithmSuite</code> assertion requires the use of the
algorithm suite identified by its nested policy assertion
(<code>sp:Basic256Rsa15</code> <em>in the example above</em>) and
further qualifies the behavior of the
<code>sp:TransportBinding</code> policy assertion.</p>
<p>Setting aside the details of using transport-level security, a
policy-aware client that recognizes this policy assertion can
engage transport-level security and its dependent behaviors
automatically. This means the complexity of security usage is
absorbed by a policy-aware client and hidden from Web service
application developers.</p>
<p>Assertion Authors should note the effect of nested policy
expressions on policy intersection in their nested policy design.
The result of intersecting an assertion that contains an empty
nested policy expression with an assertion of the same type without
a nested policy expression is that the assertions are not
compatible. Therefore, when providers require dependent behaviors
these behaviors should be explicitly specified as assertions in a
nested policy expression. When the definition of an assertion
allows for nested dependent behaviors, but the use of the assertion
only contains an empty nested policy expression, this specific use
indicates the specification of no nested dependent behaviors. This
use must not be interpreted as being compatible with "any" of the
nested dependent behaviors that are allowed by the assertion,
unless otherwise specified by the assertion definition.</p>
<p>As an example, WS-Security Policy defines
<code>sp:HttpToken</code> assertion to contain three possible
nested elements, <code>sp:HttpBasicAuthentication</code>,
<code>sp:HttpDigestAuthentication</code> and
<code>sp:RequireClientCertificate</code>. When the
<code>HttpToken</code> 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.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
5-11.</span> Empty Nested Policy Expression</i></p>
<div class="exampleInner">
<pre>
&lt;sp:TransportToken&gt;
  &lt;wsp:Policy&gt;
        &lt;sp:HttpsToken&gt;
          &lt;wsp:Policy/&gt;
        &lt;/sp:HttpsToken&gt;
  &lt;/wsp:Policy&gt;
&lt;/sp:TransportToken&gt;
</pre></div>
</div>
<p>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.</p>
</div>
</div>
<div class="div2">
<h3><a name="Ignorable" id="Ignorable"></a>5.5 Designating
Ignorable Behavior</h3>
<div class="div3">
<h4><a name="d3e882" id="d3e882"></a>5.5.1 Ignorable behavior in
authoring</h4>
<p>The Policy Framework provides an intersection algorithm that has
two defined modes for processing (lax and strict). The Framework
also defines an attribute (wsp:Ignorable) that can be used to
influence whether assertions are part of the compatibility
assessment between two alternatives. [see <cite><a href=
"#WS-Policy">Web Services Policy Framework</a></cite> and
<cite><a href="#WS-Policy-Primer">Web Services Policy
Primer</a></cite>]. Assertion authors should consider whether the
behavior represented by the Assertion they are defining can be
safely ignored for the purposes of intersection, and should follow
<a href="#DefineIgnorable"><b>8. Document Ignorable
Behavior</b></a> and <a href="#ignorableAssertions"><b>9. Document
Use of the Ignorable Attribute in XML</b></a> to include this
guidance in the assertion's definition.</p>
</div>
<div class="div3">
<h4><a name="d3e895" id="d3e895"></a>5.5.2 Ignorable behavior at
runtime</h4>
<p>Regardless of whether the assertion allows the ignorable
attribute, assertion authors should indicate the semantic of the
runtime behavior in the description of the assertion.</p>
<p>As said in <a href=
"http://www.w3.org/TR/2007/NOTE-ws-policy-primer-20071112#strict-lax-policy-intersection">
section 3.4.1 Strict and Lax Policy Intersection</a> in
<cite><a href="#WS-Policy-Primer">Web Services Policy
Primer</a></cite>, "Regardless of the chosen intersection mode,
ignorable assertions do not express any wire-level requirements on
the behavior of consumers - in other words, a consumer could choose
to ignore any such assertions that end up in the resulting policy
after intersection, with no adverse effects on runtime
interactions." Therefore, any assertion that is marked with
ignorable should not impose any wire-level requirements on the part
of consumers. Assertion Authors are reminded that regardless of
whether an assertion is marked as ignorable, policy consumers using
strict intersection will not 'ignore' the assertion.</p>
</div>
</div>
<div class="div2">
<h3><a name="optional-policy-assertion" id=
"optional-policy-assertion"></a>5.6 Designating Optional
Behaviors</h3>
<div class="div3">
<h4><a name="d3e910" id="d3e910"></a>5.6.1 Optional behavior at
runtime</h4>
<p>The target scope of an assertion is an important factor for
Assertion Authors to consider as it determines the
<em>granularity</em> of the scope for which the behavior is to be
engaged. For example, if an assertion has a scope of endpoint
policy subject the behavior indicated by that assertion applies to
all , messages exchanged in both directions (e.g. both request and
response messages) with the specific endpoint to which the policy
alternative including that assertion is attached.</p>
<p>Certain behaviors might provide in their specification for the
optional use of that behavior in the context of a subset of a given
interaction. When such optional behaviors are indicated by
attaching assertions with only one side of an interaction, such as
an inbound message of a request-response, the engagement in the
context of the rest of the interaction such as the outbound
message, will be undefined. Therefore, the Assertion Authors are
encouraged to consider the implications of attachment of an
assertion that indicates such optional behavior at a message policy
subject on the interaction as a whole. For example, if reliable
messaging (RM) is applied to a request message because the policy
attached to the inbound message in a request-response operation had
an alternative that incldued RM in its assertions, is the
application of RM to the outbound message permitted, even if there
is no policy attached to that subject? Leaving the semantics either
unspecified or incompletely specified may result in implementations
making assumptions that might have undesireable consequences. This
is especially important if the assertion is applicable to more than
one specific policy subject. The approach taken by WS-RM Policy
[<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging
Policy Assertion</a></cite>] is to provide for an RM assertion to
be attached at either or both message and endpoint policy subjects.
In order to eliminate the ambiguity associated with only using a
message policy subject, the WS-RM Policy requires a policy to be
attached to an endpoint policy subject as well as a message policy
subject whenever a policy is attached to a message policy subject.
The combination directly addresses the unstated semantic that if RM
is used for inbound messages, that it MAY be used for outbound
messages, even if the assertion is not attached to the outbound
message (and vice-versa).</p>
<div class="boxedtext">
<p><a name="bp-entire-mep-for-optional" id=
"bp-entire-mep-for-optional"></a><span class="practicelab">Best
Practice 17: Consider entire message exchange pattern when
specifying Assertions that represent optional behavior related to a
subset of that message exchange pattern when considering
appropriate policy subject attachment points</span></p>
<p class="practice">Assertion Authors should associate assertions
that represent optional behavior with the appropriate policy
subject and use the smallest possible granularity (See Best
Practice 28) to limit the degree to which optional behavior
applies.</p>
</div>
<p>Behaviors that must be engaged in the context of an interaction
must not be marked with wsp:Optional="true". since this creates two
alternatives; one with and one without that assertion. This would
allow the policy consumer to select the policy alternative that
does not contain that assertion, and thus result in an interaction
that did not engage the required behavior that was indicated by
that assertion.</p>
<div class="boxedtext">
<p><a name="bp-limitoptional-assertion-use" id=
"bp-limitoptional-assertion-use"></a><span class="practicelab">Best
Practice 18: Limit use of an Optional Assertion</span></p>
<p class="practice">Assertion Authors should disallow the use of
the wsp:Optional attribute on assertions that represent behaviors
that must be engaged.</p>
</div>
<p>Behaviors must be engaged with respect to messages that are
targeted to the provider so that the provider can determine that
the optional behavior is engaged. In ohter words, the need for self
describing messages [<a href="#self-describing"><b>5.3.3 Self
Describing Messages</b></a> ]should not be forgotten. An explicit,
out of band mechanism might be necessary to enable a client to
indicate that the optional behavior is engaged. (Such an out of
band mechanism is outside the scope of the WS-Policy
Framework).</p>
<div class="boxedtext">
<p><a name="bp-indicate-optional-assertion-use" id=
"bp-indicate-optional-assertion-use"></a><span class=
"practicelab">Best Practice 19: Indicate use of an Optional
Assertion</span></p>
<p class="practice">When a given behavior may be optional, it must
be possible for both message participants to determine that the
assertion has been selected by both parties, either out of band or
as reflected by the message content.</p>
</div>
<p>The <cite><a href="#WS-Policy-Primer">Web Services Policy
Primer</a></cite> document contains an example that outlines the
use of <cite><a href="#MTOM">MTOM</a></cite> as an optional
behavior that can be engaged by a consumer. Related to this
behavior is an assertion that identifies the use of MIME
Multipart/Related serialization [<cite><a href=
"#MTOMPolicy">MTOMPolicy</a></cite>]. Policy-aware clients that
recognize and engage this policy assertion will use Optimized MIME
Serialization for messages.</p>
<p>The semantics of the MTOM assertion declare that the behavior
must be reflected in messages by requiring that they use an obvious
wire format (MIME Multipart/Related serialization). Thus, this
optional behavior is self describing. For example, an inbound
message to a web service that requires MTOM must adhere to
Optimized MIME Serialization. By examining the message, the
provider can determine whether the policy alternate that contains
the MTOM assertion is being obeyed ( <a href=
"#bp-indicate-optional-assertion-use">Best Practice: Indicate use
of an Optional Assertion</a>).</p>
<p>Note that if a MTOM assertion were only bound to the policy
subject representing the inbound message, then it would not be
clear to the service provider whether the outbound whether the
outbound messages generated by that provider should also utilize
that behavior. Thus this assertion should be associated at the
granularity of an entire message exchange. The semantics of the
assertion should specify this to avoid inappropriate assumptions by
implementations.</p>
</div>
</div>
<div class="div2">
<h3><a name="levels-of-abstraction" id=
"levels-of-abstraction"></a>5.7 Considerations for Policy
Attachment</h3>
<div class="div3">
<h4><a name="general-attachment-guidelines" id=
"general-attachment-guidelines"></a>5.7.1 General Guidelines</h4>
<p>Although a policy assertion may be constrained to a specific set
of policy subjects by Assertion Authors, its semantics should not
be dependent upon the mechanism by which the policy expression is
attached to a given policy subject. For instance, an assertion
"Foo" has the same semantics when attached to an operation policy
subject regardless of whether it was attached using XML element
policy attachment or the external URI attachment mechanism.
Independence from a specific attachment mechanism allows policy
tools to choose the most appropriate mechanism to attach a policy
without having to analyze the contents of the policy.</p>
<div class="boxedtext">
<p><a name="bp-assertion-semantics" id=
"bp-assertion-semantics"></a><span class="practicelab">Best
Practice 20: Semantics Independent of Attachment
Mechanisms</span></p>
<p class="practice">The semantics of a policy assertion should not
depend on the attachment mechanism used.</p>
</div>
<p>For example, a security policy expression can be assigned a key
reference and be attached to a UDDI binding or can be embedded in a
WSDL document.</p>
<p>Since multiple attachment mechanisms may be used, a policy
alternative created during the process of calculating an effective
policy can contain multiple instances of the same policy assertion
type ( i.e., the SignedParts assertion). It is therefore also
important for the policy authors to define what it means if
multiple assertions are present.</p>
<div class="boxedtext">
<p><a name="bp-semantics-multiple-same-type" id=
"bp-semantics-multiple-same-type"></a><span class=
"practicelab">Best Practice 21: Describe Semantics of Multiple
Assertions of Same Type</span></p>
<p class="practice">Assertion Authors should specify the semantics
of multiple instances of the same policy assertion type in the same
policy alternative and the semantics of parameters and nested
policy (if any) when there are multiple instances of a policy
assertion type in the same policy alternative regardless of the
mechanism used to attach them to a policy subject.</p>
</div>
<p>Assertion authors should review sections 3.2 and 4.5 of the
Policy Framework <cite><a href="#WS-Policy">Web Services Policy
Framework</a></cite> for more detail on the processing for multiple
assertions of the same type.</p>
<div class="boxedtext">
<p><a name="bp-leverage-defined-attachment-mechanisms" id=
"bp-leverage-defined-attachment-mechanisms"></a><span class=
"practicelab">Best Practice 22: Leverage Defined Attachment
Mechanisms</span></p>
<p class="practice">Assertion Authors should leverage defined
attachment models when possible to document the use of the policy
assertions they author and ensure that there are no additional
semantics implied by the defined attachment models for their
assertions.</p>
</div>
<div class="boxedtext">
<p><a name="bp-use-defined-policy-subjects" id=
"bp-use-defined-policy-subjects"></a><span class="practicelab">Best
Practice 23: Use Defined Policy Subjects</span></p>
<p class="practice">Assertion Assertion Authors should leverage
defined policy subjects when possible to facilitate the deployment
of their policy assertions. Common Policy subjects have been
defined and used by other policy assertion authors and new policy
assertions that leverage these existing subjects will be easier to
define and group.</p>
</div>
<div class="boxedtext">
<p><a name="bp-identify-policy-subjects" id=
"bp-identify-policy-subjects"></a><span class="practicelab">Best
Practice 24: Identify Policy Subjects</span></p>
<p class="practice">Policy assertion authors should unambiguously
identify the appropriate policy subjects for their assertions. If
the best practices are followed, and the assertions are scoped
according to their subject, then multiple policy domains may be
combined without conflict. Each domain should define any
limitations at the policy subject level that might impact
interoperability.</p>
</div>
<p>Assertion Authors should review the policy subjects defined in
WS-PolicyAttachments and identify which of the existing policy
subjects can be used with the assertions they define. That
identification will facilitate the deployment of their policy
assertions.</p>
<p>An example of this practice is the Reliable Messaging Policy
Assertion document [<cite><a href="#WS-RM-Policy">Web Services
Reliable Messaging Policy Assertion</a></cite>]. In the Sequence
STR Assertion (section 2.5.1) the Reliable Messaging Policy
Assertion authors state that "The STR assertion defines the
requirement that an RM Sequence MUST be bound to an explicit token
that is referenced from a <code>wsse:SecurityTokenReference</code>
in the CreateSequence message. This assertion MUST apply to
[Endpoint Policy Subject]. This assertion MUST NOT be used for an
endpoint that does not also use the RM assertion". This is
illustrative of how the domain assertion author can specify
additional constraints and assumptions for attachment and
engagement of behavior in addition to the capabilities specified in
Web Services Policy 1.5 - Attachment [<cite><a href=
"#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>].
Such additional constraints must be clearly specified by the
assertion authors.</p>
</div>
<div class="div3">
<h4><a name="wsdl-attachment-guidelines" id=
"wsdl-attachment-guidelines"></a>5.7.2 Considerations for Policy
Attachment in WSDL</h4>
<p>A behavior identified by a policy assertion applies to the
associated policy subject. If a policy assertion is to be used
within WSDL, Assertion Authors should specify a WSDL policy
subject.</p>
<p>The specific WSDL policy subject is determined with respect to a
behavior as follows:</p>
<ul>
<li>
<p>If the behavior applies to any message exchange using any of the
endpoints offered by a service then the subject is the service
policy subject.</p>
</li>
<li>
<p>If the behavior applies to any message exchange made using an
endpoint then the subject is the endpoint policy subject.</p>
</li>
<li>
<p>If the behavior applies to any message exchange defined by an
operation then the subject is the operation policy subject.</p>
</li>
<li>
<p>If the behavior applies to an input message then the subject is
the message policy subject - similarly for output and fault message
WSDL policy subjects.</p>
</li>
</ul>
<div class="boxedtext">
<p><a name="bp-WSDL-policy-subject" id=
"bp-WSDL-policy-subject"></a><span class="practicelab">Best
Practice 25: Specify WSDL Policy Subject(s)</span></p>
<p class="practice">Assertion Authors should specify the set of
relevant WSDL policy subjects with which the assertion may be
associated.</p>
</div>
<p>Assertion Authors that utilize WSDL policy subjects need to
understand how the assertions will be processed in intersection and
merging, and the specific implications of the processing for a
specific attachment point and policy subject. This topic is
considered in detail in <cite><a href="#WS-Policy-Primer">Web
Services Policy Primer</a></cite></p>
<p>For a given WSDL policy subject, there may be several attachment
points. For example, there are three attachment points for the
endpoint policy subject: the port, binding and portType element.
Assertion Authors should identify the relevant attachment point
when defining a new assertion.</p>
<div class="boxedtext">
<p><a name="bp-WSDL-consider-scope" id=
"bp-WSDL-consider-scope"></a><span class="practicelab">Best
Practice 26: Consider Scope of Attachment Points</span></p>
<p class="practice">To determine the relevant attachment points,
Assertion Authors should consider the scope of the attachment
point.</p>
</div>
<p>For example, an assertion should only be allowed in the portType
element if the assertion reasonably applies to any endpoint that
ever references that portType. Most of the known policy assertions
are designed for the endpoint, operation or message policy
subject.</p>
<p>In using WSDL attachment, it should be noted that the service
policy subject is a collection of endpoint policy subjects. The
endpoint policy subject is a collection of operation WSDL policy
subjects and so on. As a result, the WSDL policy subjects compose
naturally. It is quite tempting to associate the identified
behavior to a broader policy subject than to a fine granular policy
subject. For instance, it is convenient to attach a supporting
token assertion (defined by the Web Services Security Policy
specification) to an endpoint policy subject instead of a message
policy subject. The best practice is to choose the most granular
WSDL policy subject to which the behavior represented by a policy
assertion applies.</p>
<div class="boxedtext">
<p><a name="bp-WSDL-policy-subject-Granularity" id=
"bp-WSDL-policy-subject-Granularity"></a><span class=
"practicelab">Best Practice 27: Choose the Most Granular WSDL
Policy Subject</span></p>
<p class="practice">Assertion Authors should choose the most
granular WSDL policy subject to which the behavior represented by a
policy assertion applies.</p>
</div>
<p>For authoring convenience, Assertion Authors may allow the
association of an assertion to multiple WSDL policy subjects within
the same context of use (e.g in the same WSDL description). If an
assertion is allowed to be associated with multiple WSDL policy
subjects as is possible with WSDL, then the Assertion Authors have
the burden to describe the rules when multiple instances of the
same assertion are attached to different WSDL policy subjects in
order to avoid non-interoperable behavior.</p>
<div class="boxedtext">
<p><a name="bp-WSDL-multiple-policy-subjects" id=
"bp-WSDL-multiple-policy-subjects"></a><span class=
"practicelab">Best Practice 28: Define Rules for Attachment of an
Assertion type to Multiple WSDL policy subjects</span></p>
<p class="practice">If an assertion is allowed to be associated
with multiple WSDL policy subjects, the assertion author should
describe the rules for multiple instances of the same assertion
attached to multiple WSDL policy subjects in the same context.</p>
</div>
<p>To give one example, section 2.3 of the Web Services Reliable
Messaging Policy Assertion specification [<cite><a href=
"#WS-RM-Policy">Web Services Reliable Messaging Policy
Assertion</a></cite>] gives rules on which WSDL policy subjects may
be associated with the RM Policy assertion, and which WSDL 1.1
elements may have RM Policy assertions attached.</p>
<p>If the behavior indicated by an assertion varies when attached
to different policy subjects the Assertion Authors should consider
the following:</p>
<ul>
<li>
<p>Decompose the semantics with several assertions.</p>
</li>
<li>
<p>Rewrite a single assertion targeting a specific policy
subject.</p>
</li>
</ul>
<p>Since many attachment points are available in WSDL, it would be
necessary for Assertion Authors to recommend a preferred attachment
point. One approach would be to identify different attachment
points in a policy subject, choose the most granular policy subject
that the behavior applies to and specify that as a preferred
attachment point. However, this approach only works if the policy
subject is a true WSDL construct other than some other protocol
concept that is layered over WSDL message exchanges. For example,
as described previously the WS-RM Policy is a capability that
governs a target endpoint's capability to accept message sequences
that are beyond single message exchange. Therefore, its semantics
encompass the cases when message level WSDL policy subjects may be
used as attachment but also considers the case when sequences are
present. In addition, when the policy assertions do not target
wire-level behaviors but rather abstract requirements, this
technique does not apply.</p>
<div class="boxedtext">
<p><a name="bp-WSDL-preferred-attachment-point" id=
"bp-WSDL-preferred-attachment-point"></a><span class=
"practicelab">Best Practice 29: Specify Preferred WSDL Attachment
Point</span></p>
<p class="practice">If an assertion can be attached at multiple
attachment points within a policy subject, Assertion Authors should
specify a preferred attachment point for the chosen policy
subject.</p>
</div>
<p>Assertion Authors that utilize WSDL policy subjects need to
understand how the assertions will be processed in merging and the
specific implications of a result where multiple assertions of the
assertion type are in an alternative, in the merged policy. For
example, consider the SignedParts assertion defined in
WS-SecurityPolicy 1.2. The definition of SignedParts assertion
explicitly permits multiple SignedParts assertions to be present
within a policy alternative, and declares it to be equivalent to a
single SignedParts assertion containing the union of all specified
message parts. So, if a SignedParts assertion is specified in a
WSDL binding at the input message level and subsequently an
additional SignedParts assertion is specified at the WSDL endpoint
policy subject level, then the effective policy at the endpoint
could have more than one SignedParts assertion in the same
alternative. However, the clear semantics defined by the
SignedParts assertion enable processing of the multiple occurrences
properly.</p>
</div>
<div class="div3">
<h4><a name="UDDI-attachment-guidelines" id=
"UDDI-attachment-guidelines"></a>5.7.3 Considerations for Policy
Attachment in UDDI</h4>
<p>In general, UDDI protocol messages can be used to save TModel,
businessEntity, businessService and bindingTemplate definitions
with policies attached. These definitions can also be the target of
a "find" protocol message, thus allowing authors to store and
retrieve policy assertions. There are two ways to associate policy
expressions with UDDI definitions: direct referece, and registering
policy as a UDDI TModel. Assertion Authors defining new assertions
should consider each approach.</p>
<div class="boxedtext">
<p><a name="bp-UDDI-tmodels" id="bp-UDDI-tmodels"></a><span class=
"practicelab">Best Practice 30: Use defined tModels when
appropriate</span></p>
<p class="practice">UDDI defines the following policy subjects:
Service Provider Policy, Service Policy subject and Endpoint Policy
subject.</p>
</div>
<p>When defining assertions and recommending a service provider
policy subject [uddi:BusinessEntity], or a service policy subject
[uddi:buisnessService], assertion authors are scoping the behaviors
to the service provider as a whole. When defining assertions and
recommending an endpoint policy subject [uddi:bindingTemplate,
uddi:tModel], assertion authors are scoping behaviors to a deployed
endpoint.</p>
</div>
</div>
<div class="div2">
<h3><a name="interrelated-domains" id=
"interrelated-domains"></a>5.8 Interrelated domains</h3>
<p>Assertion Authors need to be clear about how assertions defined
in their domain may fit with assertions for interrelated domains.
Assertion Authors should not duplicate existing assertions and
should also make sure that when adding assertions those new
assertions are consistent with pre-existing assertions of any
interrelated domain.</p>
<div class="boxedtext">
<p><a name="bp-specify-composition" id=
"bp-specify-composition"></a><span class="practicelab">Best
Practice 31: Specify Composition with Related Assertions</span></p>
<p class="practice">Assertion authors should clearly specify how an
assertion may compose with other related assertions, if any.</p>
</div>
<p>A classic example of such an interrelated domain is security,
because security tends to cut across all aspects of a solution. Web
Services Reliable Messaging Policy Assertions [<cite><a href=
"#WS-RM-Policy">Web Services Reliable Messaging Policy
Assertion</a></cite>] defines additional assertions related to
[<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>],
an interrelated security domain. One such additional assertion
specifies the use of transport security to protect a message
sequence, for example.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
5-12.</span> Reliable Message Sequence Security</i></p>
<div class="exampleInner">
<pre>
&lt;wsrmp:SequenceTransportSecurity [wsp:Optional="true"]? ... /&gt;
</pre></div>
</div>
<p>The Reliable Message Policy specification states "This assertion
is effectively meaningless unless it occurs in conjunction with the
<code>RMAssertion</code> and a <code>sp:TransportBinding</code>
assertion that requires the use of some transport-level security
mechanism (e.g. <code>sp:HttpsToken</code>)".</p>
</div>
</div>
<div class="div1">
<h2><a name="versioning-policy-assertions" id=
"versioning-policy-assertions"></a>6. Versioning Policy
Assertions</h2>
<p>Assertion Authors need to consider not just the expression of
the current set of requirements but how they anticipate new
assertions being added to the set. There are three aspects to
versioning policy assertions:</p>
<ul>
<li>
<p>Assertion Extensibility. Assertion authors should allow for
extensibility (see best practice 5. Start with a Simple
Assertion)</p>
</li>
<li>
<p>Policy Language Extensibility</p>
<p>Over time, the Policy WG or third parties can version or extend
the Policy Language with new or modified constructs. These
constructs may be compatible or incompatible with previous
versions.</p>
<p>Assertion Authors should review the WS-Policy Primer
<cite><a href="#WS-Policy-Primer">Web Services Policy
Primer</a></cite> and the specifications <cite><a href=
"#WS-Policy">Web Services Policy Framework</a></cite>
<cite><a href="#WS-PolicyAttachment">Web Services Policy
Attachment</a></cite> for details on extensibility.</p>
<p>The current WS-Policy language <cite><a href="#WS-Policy">Web
Services Policy Framework</a></cite> provides extensibility points
on 6 elements with a combination of attribute and/or element
extensibility:</p>
<ol class="enumar">
<li>
<p>Policy: element from ##other namespace and any attribute</p>
</li>
<li>
<p>ExactlyOne, All: element from ##other namespace; no attribute
extensibility</p>
</li>
<li>
<p>PolicyReference: any element and any attribute</p>
</li>
<li>
<p>PolicyAttachment: element from ##other namespace and any
attribute</p>
</li>
<li>
<p>AppliesTo: any element and any attribute</p>
</li>
<li>
<p>URI: any attribute</p>
</li>
</ol>
</li>
<li>
<p>Supporting New Policy Subjects (see Section <a href=
"#supporting-new-policy-subjects"><b>6.3 Supporting New Policy
Subjects</b></a>).</p>
</li>
</ul>
<div class="div2">
<h3><a name="Referencing_Policy_Expressions" id=
"Referencing_Policy_Expressions"></a>6.1 Referencing Policy
Expressions</h3>
<p>The <cite><a href="#WS-Policy-Primer">Web Services Policy
Primer</a></cite> illustrates how providers can utilize the
identification mechanism defined in the Policy specification to
expose a complex policy expression as a reusable building block for
other policy expressions by reference. Reuse may also be useful for
domain Assertion Authors, especially those defining complex
assertions utilizing references to policy expressions by nesting.
Statically available parameterized content may also be reused by
different assertions. However, such referencing mechanism is
outside the scope of WS-Policy naming and referencing framework and
other mechanisms could be used. As an example, in <cite><a href=
"#WS-Policy-Primer">Web Services Policy Primer</a></cite> Section
4.2, the <code>sp:issuedToken</code> assertion utilizes the
<code>sp:RequestSecurityTokenTemplate</code> parameter that
contains necessary information to request a security token. The
contents of the parameter are static and may be reused in different
security scenarios using other referencing mechanisms (these are
outside the scope of the WS-Policy Framework).</p>
</div>
<div class="div2">
<h3><a name="extending-assertions" id=
"extending-assertions"></a>6.2 Evolution of Assertions (Versioning
and Compatibility)</h3>
<p>Over time, there may be multiple equivalent behaviors emerging
in the Web Service interaction space. Examples of such multiple
equivalent behaviors are WSS: SOAP Message Security 1.0 vs. 1.1 and
WS-Addressing August 2004 version vs. WS-Addressing W3C
Recommendation [<cite><a href="#WS-Addressing">WS-Addressing
Core</a></cite>]. These equivalent behaviors are mutually exclusive
for an interaction. Such equivalent behaviors can be modeled as
independent assertions.</p>
<div class="boxedtext">
<p><a name="bp-independent-assertions" id=
"bp-independent-assertions"></a><span class="practicelab">Best
Practice 32: Independent Assertions for Different Versions of a
Behavior</span></p>
<p class="practice">Assertion Authors should use independent
assertions for modeling different versions of a behavior.</p>
</div>
<p>The policy expression in the example below requires the use of
WSS: SOAP Message Security 1.0.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
6-1.</span> Message-level Security and WSS: SOAP Message Security
1.0</i></p>
<div class="exampleInner">
<pre>
&lt;Policy&gt;
  &lt;sp:Wss10&gt;…&lt;/sp:Wss10&gt;
&lt;/Policy&gt;
</pre></div>
</div>
<p>The policy expression in the example below requires the use of
WSS: SOAP Message Security 1.1. These are multiple equivalent
behaviors and are represented using distinct policy assertions.</p>
<div class="exampleOuter">
<p style="text-align: left" class="exampleHead"><i><span>Example
6-2.</span> Message-level Security and WSS: SOAP Message Security
1.1</i></p>
<div class="exampleInner">
<pre>
&lt;Policy&gt;
  &lt;sp:Wss11&gt;…&lt;/sp:Wss11&gt;
&lt;/Policy&gt;
</pre></div>
</div>
</div>
<div class="div2">
<h3><a name="supporting-new-policy-subjects" id=
"supporting-new-policy-subjects"></a>6.3 Supporting New Policy
Subjects</h3>
<p>The best practice <a href="#bp-WSDL-policy-subject"><b>25.
Specify WSDL Policy Subject(s)</b></a> specifies that policy
authors should define the set of policy subjects to which policy
assertions can be attached. Over time, new policy subjects may need
to be defined. When this occurs, policy Assertion Authors may
update the list of policy subjects supported by an assertion.</p>
<p>When the assertion's semantics do not change to invalidate any
of the original policy subjects but new policy subjects need to be
added, it may be possible to use the same assertion to designate
the additional policy subjects without a namespace change. For
example, a policy assertion for a protocol that is originally
designed for endpoint policy subject may add message policy subject
to indicate finer granularity in the attachment provided that
endpoint policy subject is also retained in its design. When new
policy subjects are added it is incumbent on the authors to retain
the semantic of the policy assertion.</p>
<div class="boxedtext">
<p><a name="bp-policy-subject-change" id=
"bp-policy-subject-change"></a><span class="practicelab">Best
Practice 33: Document changes to policy subject</span></p>
<p class="practice">If the policy subjects change over time, the
assertion description should also be versioned to reflect this
change.</p>
</div>
</div>
</div>
</div>
<div class="back">
<div class="div1">
<h2><a name="security-considerations" id=
"security-considerations"></a>A. Security Considerations</h2>
<p>Security considerations are discussed in the <cite><a href=
"#WS-Policy">Web Services Policy Framework</a></cite> document.</p>
</div>
<div class="div1">
<h2><a name="xml-namespaces" id="xml-namespaces"></a>B. XML
Namespaces</h2>
<p>The table below lists XML Namespaces that are used in this
document. The choice of any namespace prefix is arbitrary and not
semantically significant.</p>
<a name="nsprefix" id="nsprefix"></a>
<table summary=
"Prefixes and XML Namespaces used in this specification" border="1"
cellspacing="0" cellpadding="5">
<caption>Table B-1. Prefixes and XML Namespaces used in this
specification.</caption>
<thead>
<tr>
<th rowspan="1" colspan="1">Prefix</th>
<th rowspan="1" colspan="1">XML Namespace</th>
<th rowspan="1" colspan="1">Specifications</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="1" colspan="1"><code>soap</code></td>
<td rowspan="1" colspan="1">
<code>http://www.w3.org/2003/05/soap-envelope</code></td>
<td rowspan="1" colspan="1">[<cite><a href="#SOAP12">SOAP 1.2
Messaging Framework (Second Edition)</a></cite>]</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><code>sp</code></td>
<td rowspan="1" colspan="1">
<code>http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702</code></td>
<td rowspan="1" colspan="1">[<cite><a href=
"#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><code>wsa</code></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>wsam</code></td>
<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></td>
<td rowspan="1" colspan="1">[<cite><a href="#WSDL11">WSDL
1.1</a></cite>]</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><code>wsp</code></td>
<td rowspan="1" colspan="1">
<code>http://www.w3.org/ns/ws-policy</code></td>
<td rowspan="1" colspan="1">[<cite><a href="#WS-Policy">Web
Services Policy Framework</a></cite>, <cite><a href=
"#WS-PolicyAttachment">Web Services Policy
Attachment</a></cite>]</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><code>wsrmp</code></td>
<td rowspan="1" colspan="1">
<code>http://docs.oasis-open.org/ws-rx/wsrmp/200702</code></td>
<td rowspan="1" colspan="1">[<cite><a href="#WS-RM-Policy">Web
Services Reliable Messaging Policy Assertion</a></cite>]</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><code>wss</code></td>
<td rowspan="1" colspan="1">
<code>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd</code></td>
<td rowspan="1" colspan="1">[<cite><a href=
"#WS-Security2004">WS-Security 2004</a></cite>]</td>
</tr>
<tr>
<td rowspan="1" colspan="1"><code>wsu</code></td>
<td rowspan="1" colspan="1">
<code>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd</code></td>
<td rowspan="1" colspan="1">[<cite><a href=
"#WS-Security2004">WS-Security 2004</a></cite>]</td>
</tr>
</tbody>
</table>
<br /></div>
<div class="div1">
<h2><a name="references" id="references"></a>C. References</h2>
<dl>
<dt class="label"><a name="MTOM" id="MTOM"></a>[MTOM]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/">SOAP Message
Transmission Optimization Mechanism</a></cite>, M. Gudgin, N.
Mendelsohn, M. Nottingham and H. Ruellan, Editors. World Wide Web
Consortium, 25 January 2005. This version of the SOAP Message
Transmission Optimization Mechanism Recommendation is
http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/. The <a href=
"http://www.w3.org/TR/soap12-mtom/">latest version of SOAP Message
Transmission Optimization Mechanism</a> is available at
http://www.w3.org/TR/soap12-mtom/.</dd>
<dt class="label"><a name="MTOMPolicy" id=
"MTOMPolicy"></a>[MTOMPolicy]</dt>
<dd><cite><a href=
"http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization/optimizedmimeserialization-policy.pdf">
MTOM Serialization Policy Assertion (WS-MTOMPolicy)</a></cite>, C
Ferris, K Gavrylyuk, J Marsh , J Schlimmer, Authors. September
2006. Version 1.0 at
http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization/optimizedmimeserialization-policy.pdf.</dd>
<dt class="label"><a name="SOAP11" id="SOAP11"></a>[SOAP 1.1]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2000/NOTE-SOAP-20000508/">Simple Object
Access Protocol (SOAP) 1.1</a></cite>, D. Box, et al, Editors.
World Wide Web Consortium, 8 May 2000. Available at
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.</dd>
<dt class="label"><a name="SOAP12" id="SOAP12"></a>[SOAP 1.2
Messaging Framework (Second Edition)]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/REC-soap12-part1-20070427/">SOAP Version
1.2 Part 1: Messaging Framework (Second Edition)</a></cite>, M.
Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen,
A. Karmarkar, and Y. Lafon, Editors. World Wide Web Consortium, 27
April 2007. This version of the SOAP Version 1.2 Part 1: Messaging
Framework Recommendation is
http://www.w3.org/TR/2007/REC-soap12-part1-20070427/. The <a href=
"http://www.w3.org/TR/soap12-part1/">latest version of SOAP Version
1.2 Part 1: Messaging Framework</a> is available at
http://www.w3.org/TR/soap12-part1/.</dd>
<dt class="label"><a name="XOP" id="XOP"></a>[XOP]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2005/REC-xop10-20050125/">XML-binary
Optimized Packaging</a></cite>, M. Gudgin, N. Mendelsohn, M.
Nottingham and H. Ruellan, Editors. World Wide Web Consortium, 25
January 2005. This version of the XML-binary Optimized Packaging
Recommendation is http://www.w3.org/TR/2005/REC-xop10-20050125/.
The <a href="http://www.w3.org/TR/xop10/">latest version of
XML-binary Optimized Packaging</a> is available at
http://www.w3.org/TR/xop10/.</dd>
<dt class="label"><a name="WS-Addressing" id=
"WS-Addressing"></a>[WS-Addressing Core]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/">Web Services
Addressing 1.0 - Core</a></cite>, M. Gudgin, M. Hadley, and T.
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-AddressingMetadata" id=
"WS-AddressingMetadata"></a>[WS-Addressing Metadata]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/">Web
Services Addressing 1.0 - Metadata</a></cite>, M. Gudgin, M.
Hadley, T. Rogers and Ü. Yalçinalp, Editors. World Wide Web
Consortium, 4 September 2007. This version of Web Services
Addressing 1.0 - Metadata W3C Recommendation is
http://www.w3.org/TR/2007/REC-ws-addr-metadata-20070904/. 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="WSDL11" id="WSDL11"></a>[WSDL 1.1]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2001/NOTE-wsdl-20010315">Web Services
Description Language (WSDL) 1.1</a></cite>, E. Christensen, et al,
Authors. World Wide Web Consortium, March 2001. Available at
http://www.w3.org/TR/2001/NOTE-wsdl-20010315.</dd>
<dt class="label"><a name="WSDL20" id="WSDL20"></a>[WSDL 2.0 Core
Language]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/REC-wsdl20-20070626/">Web Services
Description Language (WSDL) Version 2.0 Part 1: Core
Language</a></cite>, R. Chinnici, J. J. Moreau, A. Ryman, S.
Weerawarana, Editors. World Wide Web Consortium, 26 June 2007. This
version of the WSDL 2.0 specification is
http://www.w3.org/TR/2007/REC-wsdl20-20070626/. The <a href=
"http://www.w3.org/TR/wsdl20/">latest version of WSDL 2.0</a> is
available at http://www.w3.org/TR/wsdl20.</dd>
<dt class="label"><a name="WS-Policy" id="WS-Policy"></a>[Web
Services Policy Framework]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/REC-ws-policy-20070904/">Web Services
Policy 1.5 - Framework</a></cite>, A. S. Vedamuthu, D. Orchard, F.
Hirsch, M. Hondo, P. Yendluri, T. Boubez and Ü. Yalçinalp, Editors.
World Wide Web Consortium, 4 September 2007. This version of the
Web Services Policy 1.5 - Framework specification is at
http://www.w3.org/TR/2007/REC-ws-policy-20070904/. The <a href=
"http://www.w3.org/TR/ws-policy/">latest version of Web Services
Policy 1.5 - Framework</a> is available at
http://www.w3.org/TR/ws-policy/.</dd>
<dt class="label"><a name="WS-PolicyAttachment" id=
"WS-PolicyAttachment"></a>[Web Services Policy Attachment]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/">Web
Services Policy 1.5 - Attachment</a></cite>, A. S. Vedamuthu, D.
Orchard, F. Hirsch, M. Hondo, P. Yendluri, T. Boubez and Ü.
Yalçinalp, Editors. World Wide Web Consortium, 4 September 2007.
This version of the Web Services Policy 1.5 - Attachment
specification is at
http://www.w3.org/TR/2007/REC-ws-policy-attach-20070904/. The
<a href="http://www.w3.org/TR/ws-policy-attach/">latest version of
Web Services Policy 1.5 - Attachment</a> is available at
http://www.w3.org/TR/ws-policy-attach/.</dd>
<dt class="label"><a name="WS-Policy-Primer" id=
"WS-Policy-Primer"></a>[Web Services Policy Primer]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2007/WD-ws-policy-primer-20070810/">Web
Services Policy 1.5 - Primer</a></cite>, A. S. Vedamuthu, D.
Orchard, F. Hirsch, M. Hondo, P. Yendluri, T. Boubez and Ü.
Yalçinalp, Editors. World Wide Web Consortium, 10 August 2007. This
version of Web Services Policy 1.5 - Primer specification is
http://www.w3.org/TR/2007/WD-ws-policy-primer-20070810/. The
<a href="http://www.w3.org/TR/ws-policy-primer/">latest version of
Web Services Policy 1.5 - Primer</a> is available at
http://www.w3.org/TR/ws-policy-primer/.</dd>
<dt class="label"><a name="WS-RM" id="WS-RM"></a>[Web Services
Reliable Messaging]</dt>
<dd><cite><a href=
"http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.html">
Web Services Reliable Messaging (WS-ReliableMessaging)</a></cite>,
D. Davis, A. Karmarkar G. Pilz, S. Winkler, Ü. Yalçinalp, Editors.
Organization for the Advancement of Structured Information
Standards, 14 June 2007, available at:
http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.html.
Namespace document is available at <a href=
"http://docs.oasis-open.org/ws-rx/wsrm/200702">http://docs.oasis-open.org/ws-rx/wsrm/200702</a>.</dd>
<dt class="label"><a name="WS-RM-Policy" id="WS-RM-Policy"></a>[Web
Services Reliable Messaging Policy Assertion]</dt>
<dd><cite><a href=
"http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf">
Web Services Reliable Messaging Policy Assertion (WS-RM Policy)
Version 1.1</a></cite>, D. Davis, A. Kamarkar, G. Pilz, and Ü.
Yalçinalp, Editors. Organization for the Advancement of Structured
Information Standards, OASIS Standard, 14 June 2007. This version
available at
http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf.
Namespace document is available at <a href=
"http://docs.oasis-open.org/ws-rx/wsrmp/200702">http://docs.oasis-open.org/ws-rx/wsrmp/200702</a>.</dd>
<dt class="label"><a name="WS-Security2004" id=
"WS-Security2004"></a>[WS-Security 2004]</dt>
<dd><cite><a href=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf">
Web Services Security: SOAP Message Security 1.0</a></cite>, A.
Nadalin, C. Kaler, P. Hallam-Baker and R. Monzillo, Editors.
Organization for the Advancement of Structured Information
Standards, March 2004. Available at
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf.</dd>
<dt class="label"><a name="WS-SecurityPolicy" id=
"WS-SecurityPolicy"></a>[WS-SecurityPolicy]</dt>
<dd><cite><a href=
"http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf">
WS-SecurityPolicy v1.2</a></cite>, A. Nadalin, M. Goodner, M.
Gudgin, A. Barbir, and H. Granqvist, Editors. Organization for the
Advancement of Structured Information Standards, 1 July 2007.
Available at
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf.
Namespace document available at
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702.</dd>
<dt class="label"><a name="WS-Trust" id=
"WS-Trust"></a>[WS-Trust]</dt>
<dd><cite><a href=
"http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf">
Web Services Atomic Transaction (WS-AtomicTransaction) Version
1.1</a></cite>, M. Little, A. Wilkinson, Editors. Organization for
the Advancement of Structured Information Standards, OASIS
Standard, 16 April 2007. This version available at
http://docs.oasis-open.org/ws-tx/wstx-wsat-1.1-spec-os/wstx-wsat-1.1-spec-os.html.
Namespace document is available at <a href=
"http://docs.oasis-open.org/ws-tx/wsat/2006/06">http://docs.oasis-open.org/ws-tx/wsat/2006/06</a>.</dd>
<dt class="label"><a name="UDDIAPI20" id="UDDIAPI20"></a>[UDDI API
2.0]</dt>
<dd><cite><a href=
"http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm">UDDI
Version 2.04 API</a></cite>, T. Bellwood, Editor. Organization for
the Advancement of Structured Information Standards, 19 July 2002.
This version of UDDI Version 2.0 API is
http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm.
The <a href="http://uddi.org/pubs/ProgrammersAPI_v2.htm">latest
version of the UDDI 2.0 API</a> is available at
http://uddi.org/pubs/ProgrammersAPI_v2.htm.</dd>
<dt class="label"><a name="UDDIDataStructure20" id=
"UDDIDataStructure20"></a>[UDDI Data Structure 2.0]</dt>
<dd><cite><a href=
"http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm">UDDI
Version 2.03 Data Structure Reference</a></cite>, C. von Riegen,
Editor. Organization for the Advancement of Structured Information
Standards, 19 July 2002. This version of UDDI Version 2.0 Data
Structures is
http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm.
The <a href="http://uddi.org/pubs/DataStructure_v2.htm">latest
version of the UDDI 2.0 Data Structures</a> is available at
http://uddi.org/pubs/DataStructure_v2.htm.</dd>
<dt class="label"><a name="UDDI30" id="UDDI30"></a>[UDDI 3.0]</dt>
<dd><cite><a href=
"http://uddi.org/pubs/uddi-v3.0.2-20041019.htm">UDDI Version
3.0.2</a></cite>, L. Clément, A. Hately, C. von Riegen, and T.
Rogers, Editors. Organization for the Advancement of Structured
Information Standards, 19 October 2004. This version of the UDDI
Version 3.0 is http://uddi.org/pubs/uddi-v3.0.2-20041019.htm. The
<a href="http://uddi.org/pubs/uddi_v3.htm">latest version of the
UDDI 3.0</a> specification is available at
http://uddi.org/pubs/uddi_v3.htm.</dd>
<dt class="label"><a name="SAWSDL" id="SAWSDL"></a>[SAWSDL]</dt>
<dd><cite><a href="http://www.w3.org/TR/sawsdl/">Semantic
Annotations for WSDL and XML Schema</a></cite> Joel Farrell, Holger
Lausen, Editors. World Wide Web Consortium, 28 Augusty 2007. This
is a W3C recommendation and the specification can be found at
http://www.w3.org/TR/2007/REC-sawsdl-20070828/. The <a href=
"http://www.w3.org/TR/sawsdl/">latest version of Semantic
Annotations for WSDL and XML Schema</a> is available at
http://www.w3.org/TR/sawsdl/.</dd>
<dt class="label"><a name="XMLSchemaPart2" id=
"XMLSchemaPart2"></a>[XML Schema Datatypes]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">XML Schema
Part 2: Datatypes Second Edition</a></cite>, P. Byron and A.
Malhotra, Editors. World Wide Web Consortium, 2 May 2001, revised
28 October 2004. This version of the XML Schema Part 2
Recommendation is
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028. The <a href=
"http://www.w3.org/TR/xmlschema-2/">latest version of XML Schema
Part 2</a> is available at http://www.w3.org/TR/xmlschema-2.</dd>
<dt class="label"><a name="XMLSchemaPart1" id=
"XMLSchemaPart1"></a>[XML Schema Structures]</dt>
<dd><cite><a href=
"http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML Schema
Part 1: Structures Second Edition</a></cite>, H. Thompson, D.
Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide Web
Consortium, 2 May 2001, revised 28 October 2004. This version of
the XML Schema Part 1 Recommendation is
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. The <a href=
"http://www.w3.org/TR/xmlschema-1/">latest version of XML Schema
Part 1</a> is available at http://www.w3.org/TR/xmlschema-1.</dd>
</dl>
</div>
<div class="div1">
<h2><a name="acknowledgments" id="acknowledgments"></a>D.
Acknowledgements (Non-Normative)</h2>
<p>This document is the work of the <a href=
"http://www.w3.org/2002/ws/policy/">W3C Web Services Policy Working
Group</a>.</p>
<p>Members of the Working Group are (at the time of writing, and by
alphabetical order): Dimitar Angelov (SAP AG), Abbie Barbir (Nortel
Networks), Charlton Barreto (Adobe Systems Inc.), Sergey Beryozkin
(IONA Technologies, Inc.), Vladislav Bezrukov (SAP AG), Toufic
Boubez (Layer 7 Technologies), Symon Chang (BEA Systems, Inc.),
Paul Cotton (Microsoft Corporation), Doug Davis (IBM Corporation),
Jacques Durand (Fujitsu Limited), Ruchith Fernando (WSO2),
Christopher Ferris (IBM Corporation), William Henry (IONA
Technologies, Inc.), Frederick Hirsch (Nokia), Maryann Hondo (IBM
Corporation), Ondrej Hrebicek (Microsoft Corporation), Steve Jones
(Layer 7 Technologies), Tom Jordahl (Adobe Systems Inc.), Paul
Knight (Nortel Networks), Philippe Le Hégaret (W3C/MIT), Mark
Little (JBoss Inc.), Mohammad Makarechian (Microsoft Corporation),
Ashok Malhotra (Oracle Corporation), Jonathan Marsh (WSO2), Arnaud
Meyniel (Axway Software), Jeff Mischkinsky (Oracle Corporation),
Dale Moberg (Axway Software), Anthony Nadalin (IBM Corporation),
David Orchard (BEA Systems, Inc.), Sanjay Patil (SAP AG), Manjula
Peiris (WSO2), Fabian Ritzmann (Sun Microsystems, Inc.), Daniel
Roth (Microsoft Corporation), Tom Rutt (Fujitsu Limited), Sanka
Samaranayake (WSO2), Felix Sasaki (W3C/Keio), Yakov Sverdlov (CA),
Asir Vedamuthu (Microsoft Corporation), Sanjiva Weerawarana (WSO2),
Ümit Yalçinalp (SAP AG), Prasad Yendluri (webMethods, Inc.).</p>
<p>Previous members of the Working Group were: Jeffrey Crump, Glen
Daniels, Jong Lee, Monica Martin, Bob Natale, Eugene Osovetsky,
Bijan Parsia, Skip Snow, Seumas Soltysik, Mark Temple-Raston.</p>
<p>The people who have contributed to <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/">discussions
on public-ws-policy@w3.org</a> are also gratefully
acknowledged.</p>
</div>
<div class="div1">
<h2><a name="change-description" id="change-description"></a>E.
Changes in this Version of the Document (Non-Normative)</h2>
<p>A list of major changes since the Working Draft dated 28
September, 2007 is below:</p>
<ul>
<li>
<p>Clarified the target audience for this document (see <a href=
"#introduction"><b>1. Introduction</b></a>).</p>
</li>
<li>
<p>Moved <a href="#bp-assertion-semantics"><b>20. Semantics
Independent of Attachment Mechanisms</b></a> from section <a href=
"#assertion-target"><b>5.1 Assertions and Their Target Use</b></a>
to section <a href="#general-attachment-guidelines"><b>5.7.1
General Guidelines</b></a>.</p>
</li>
<li>
<p>Added a new section: <a href="#order-of-behaviors"><b>5.3.5
Order of Behaviors</b></a>.</p>
</li>
<li>
<p>Dropped an incorrect ignorable example in section <a href=
"#QName_and_XML_Information_Set_representation"><b>5.3.2 QName and
XML Information Set representation</b></a>.</p>
</li>
<li>
<p>Rewrote section: <a href="#optional-policy-assertion"><b>5.6
Designating Optional Behaviors</b></a>.</p>
</li>
<li>
<p>Updated <a href="#references"><b>C. References</b></a>.</p>
</li>
</ul>
</div>
<div class="div1">
<h2><a name="change-log" id="change-log"></a>F. Web Services Policy
1.5 - Guidelines for Policy Assertion Authors Change Log
(Non-Normative)</h2>
<a name="ws-policy-primer-changelog-table" id=
"ws-policy-primer-changelog-table"></a>
<table border="1">
<tbody>
<tr>
<th rowspan="1" colspan="1">Date</th>
<th rowspan="1" colspan="1">Author</th>
<th rowspan="1" colspan="1">Description</th>
</tr>
<tr>
<td rowspan="1" colspan="1">20060829</td>
<td rowspan="1" colspan="1">UY</td>
<td rowspan="1" colspan="1">Created first draft based on agreed
outline and content</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061013</td>
<td rowspan="1" colspan="1">UY</td>
<td rowspan="1" colspan="1">Editorial fixes (suggested by
Frederick), fixed references, bibl items, fixed dangling pointers,
created eds to do</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061018</td>
<td rowspan="1" colspan="1">MH</td>
<td rowspan="1" colspan="1">Editorial fixes for readability, added
example for Encrypted parts</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061030</td>
<td rowspan="1" colspan="1">UY</td>
<td rowspan="1" colspan="1">Fixes for Paul Cotton's editorial
comments (20061020)</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061031</td>
<td rowspan="1" colspan="1">UY</td>
<td rowspan="1" colspan="1">Fixes for Frederick's editorial
comments (20061025)</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061031</td>
<td rowspan="1" colspan="1">UY</td>
<td rowspan="1" colspan="1">Optionality discussion feedback
integration</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061115</td>
<td rowspan="1" colspan="1">MH</td>
<td rowspan="1" colspan="1">First attempt at restructuring to
include primer content</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061120</td>
<td rowspan="1" colspan="1">MH</td>
<td rowspan="1" colspan="1">Restructure to address action items
64,77, which refer to bugzilla 3705 and F2F RESOLUTION 3792</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061127</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Updated the list of editors. Added
<a href=
"http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0033.html">
Frederick</a> and <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0054.html">
Umit</a> to the list of editors. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/86">86</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061128</td>
<td rowspan="1" colspan="1">MH</td>
<td rowspan="1" colspan="1">Replaced section in Lifecycle with
pointer to the text in the primer: related to action 77</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061129</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Editorial revision (editorial actions
<a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/84">84</a>
and <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/90">90</a>)
- includes suggestions from Asir: <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0129.html">
Part 1</a> and <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0134.html">
Part 2</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061129</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Formatted examples in <a href=
"#extending-assertions"><b>6.2 Evolution of Assertions (Versioning
and Compatibility)</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061218</td>
<td rowspan="1" colspan="1">FS</td>
<td rowspan="1" colspan="1">Formatted examples in <a href=
"#compact-full"><b>5.2 Authoring Styles</b></a> and scenario
section.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061219</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Editorial revision: most parts of
editorial action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/96">96</a>.
Remaining editorials to be reviewed.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061220</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Editorial revision: completed missing
parts of editorial action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/96">96</a>
after editorial reviews by co-editors.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20061226</td>
<td rowspan="1" colspan="1">MH</td>
<td rowspan="1" colspan="1">Editorial revision: reconciled terms
related to "Assertion Authors" <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/106">106</a>
and bug http://www.w3.org/Bugs/Public/show_bug.cgi?id=3983</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070104</td>
<td rowspan="1" colspan="1">UY</td>
<td rowspan="1" colspan="1">Resolution of Issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3982">3982</a> Based
on <a href=
"http://www.w3.org/2006/12/06-ws-policy-irc#T18-55-00">Minutes for
resolution</a>, Minor formatting for consistent use of the term
"Assertion Author"</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070104</td>
<td rowspan="1" colspan="1">UY</td>
<td rowspan="1" colspan="1">Resolution of Issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3980">3980</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070108</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Reset Section <a href=
"#change-description"><b>E. Changes in this Version of the
Document</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070122</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Completed action item: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/127">127</a>
Resolution for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4197">4197</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070130</td>
<td rowspan="1" colspan="1">UY</td>
<td rowspan="1" colspan="1">Completed action item: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/144">144</a>.
Resolution for issues <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3985">3985</a> and
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3986">3986</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070130</td>
<td rowspan="1" colspan="1">UY</td>
<td rowspan="1" colspan="1">Completed action item: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/137">137</a>.
Resolution for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4198">4198</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070130</td>
<td rowspan="1" colspan="1">UY</td>
<td rowspan="1" colspan="1">Completed action item: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/119">119</a>.
Resolution for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4141">4141</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070130</td>
<td rowspan="1" colspan="1">UY</td>
<td rowspan="1" colspan="1">Completed action item: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/126">126</a>.
Resolution for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4188">4188</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070130</td>
<td rowspan="1" colspan="1">UY</td>
<td rowspan="1" colspan="1">Fixed SAWSDL ref name</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070131</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Fixed numerous spelling and typo
errors. Implement resolution for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3953">3953</a> as
noted in message <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2006Dec/0090.html">
90</a> and amended as noted in message <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0217.html">
217</a>. Changes correspond to editor's action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/152">152</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070221</td>
<td rowspan="1" colspan="1">MH</td>
<td rowspan="1" colspan="1">Partial implementation for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4072">4072</a> in
response to editor's action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/154">154</a>
. NOTE ALSO- I needed to put back in the "prefix" entity defintion
[line7] to get the build to work.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070306</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented partial <a href=
"http://www.w3.org/2007/01/31-ws-policy-minutes.html#item10">resolution</a>
for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3987">3987</a>.
Related editorial action is <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/153">153</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070308</td>
<td rowspan="1" colspan="1">DBO</td>
<td rowspan="1" colspan="1">Changed "lifecycle" spec references to
versioning to fix build.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070314</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented <a href=
"http://www.w3.org/2007/03/14-ws-policy-irc#T18-14-48">resolution</a>
for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4072">4072</a> as
outlined in <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0103.html">
proposal</a>. Editorial action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/204">204</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070314</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented <a href=
"http://www.w3.org/2007/03/14-ws-policy-irc#T18-07-08">resolution</a>
for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3987">3987</a> as
outlined in <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0096.html">
proposal</a>. Editorial action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/203">203</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070315</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3979#c1">resolution</a>
for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3979">issue
3979</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/198">198</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070315</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0000.html">
resolution</a> for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3981">issue
3981</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/205">205</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070315</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented <a href=
"http://www.w3.org/2007/03/13-ws-policy-irc#T23-08-08">resolution</a>
for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4035">4035</a> as
outlined in <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Feb/0169.html">
proposal</a>. Editorial action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/197">197</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070319</td>
<td rowspan="1" colspan="1">MH</td>
<td rowspan="1" colspan="1">Implemented resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4073">4073</a> in
response to editor's action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/199">199</a>
as outlined in <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0093.html">
proposal</a> .</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070320</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4319#c1">resolution</a>
for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4319">issue
4319</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/206">206</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070320</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3990#c1">resolution</a>
for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3990">issue
3990</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/210">210</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070320</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212#c1">resolution</a>
for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4212">issue
4212</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/207">207</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070321</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Updated section <a href=
"#change-description"><b>E. Changes in this Version of the
Document</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070329</td>
<td rowspan="1" colspan="1">DBO</td>
<td rowspan="1" colspan="1">Changed all &lt;p&gt;Best Practice: to
&lt;p role="practice"&gt;</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070416</td>
<td rowspan="1" colspan="1">DBO</td>
<td rowspan="1" colspan="1">Updated 6.2 and 6.3 for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue
3989</a>. Note, removed one best practice that was a dup.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070423</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Updated 5.5 Designating Optional
Behaviors for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue
3989</a>. Added informative reference for MTOMPolicy. Added two
best practices, one is similar to G16 but focused on optional.
Revised practice that was there.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070425</td>
<td rowspan="1" colspan="1">MH</td>
<td rowspan="1" colspan="1">Updated 5.3 "Considerations when
Modeling New Assertions" related to <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue
3989</a>. [Editorial Action 229] Restructured text to follow
examples</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070425</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Updated 5.2 Authoring Styles for
<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue
3989</a> and editors' action item <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/227">227</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070426</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Editorial changes to align with the
OASIS WS-SecurityPolicy specification. For <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4318">issue
4318</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/245">245</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070427</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Updated 5.5.1 Optional behavior in
Compact authoring adding G7 and G8 for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue 3989</a>
and editors' action item <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/250">250</a>
as noted in <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/0069.html">
message 69</a>. Also replaced TBD in section 2 with descriptive
text."</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070501</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Reset Section <a href=
"#change-description"><b>E. Changes in this Version of the
Document</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070507</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Updated 5.6 WSDL guidelines section, to
follow the new format and added G15, G16, G17 and G18. Accounts for
parts of resolution for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue 3989</a>
corresponding to editors' action items <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232">232</a>,
<a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232">253</a>,
and <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232">256</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070507</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Updated 5.1 Assertions and their Target
Use for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue 3989</a>
and editors' action item <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/227">227</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070508</td>
<td rowspan="1" colspan="1">MH</td>
<td rowspan="1" colspan="1">Updated Section 5 for adding guidelines
G9, G10 on ignorable, and G5 , G6 (general) to address editors'
action items <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/251">251</a>.
<a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/256">256</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070511</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Updated 5.6 WSDL guidelines section to
add G19 identified in AI 256 (now G24). Accounts for parts of
resolution for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue 3989</a>
corresponding to editors' action item <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232">256</a>
- now complete.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070513</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Updated Section 5.4.1 to use the new
format re issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue
3989</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/230">230</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070514</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Updated Section 5.4.2 to use the new
format re issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue
3989</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/230">230</a>.
Collapsed Section 5.4.2 and 5.4.3.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070514</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Added G11 and G13 to Section 5.4.1 and
5.4.2 re issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue
3989</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/252">252</a>
and <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/255">255</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070516</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Editorial change to section 5.7 to
place best practices after the associated explanatory text and to
fix grammar.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070518</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Ensured Best Practices G1, G3 and G20
of <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf">
original IBM/MS Contribution</a> are reflected.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070518</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Updated Appendix E, Changes in this
Version of the Document (<a href="#change-description"><b>E.
Changes in this Version of the Document</b></a>).</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070520</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Added Best Practice <a href=
"#bp-specify-composition"><b>31. Specify Composition with Related
Assertions</b></a> (from the <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf">
IBM and MS Contribution</a> to <a href=
"#interrelated-domains"><b>5.8 Interrelated domains</b></a>. Added
an ed note that Section <a href="#interrelated-domains"><b>5.8
Interrelated domains</b></a> needs to be re-structured.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070520</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Added Best Practice <a href=
"#bp-not-necessary-to-understand-a-message"><b>11. Assertions
should not describe message semantics</b></a> (from the <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf">
IBM and MS Contribution</a> to <a href="#self-describing"><b>5.3.3
Self Describing Messages</b></a> .</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070520</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Added an ed note that Section <a href=
"#Ignorable"><b>5.5 Designating Ignorable Behavior</b></a> looks
incomplete.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070520</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Fixed typos.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070520</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Added an ed note in Section <a href=
"#assertion-target"><b>5.1 Assertions and Their Target Use</b></a>
that there is an open issue against Best Practice G2.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070524</td>
<td rowspan="1" colspan="1">DBO</td>
<td rowspan="1" colspan="1">Editorial changes to align with the W3C
WS-Addressing Metadata specification. For <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4375">issue
4375</a>. Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/284">284</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070529</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented Resolution for <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4573">issue
4573</a>. Apply "Best Practices" consistently.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070529</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/290">290</a>.
Consistent use of Assertion Authors.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070529</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/291">291</a>.
Consistent use of should in place of must in the best practice
statements.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070529</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/294">294</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070530</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/303">303</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070530</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/304">304</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070530</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/305">305</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070530</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/306">306</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070530</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/307">307</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070530</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/3087">308</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070601</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
actions <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/310">310</a>
and <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/311">311</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">200706013</td>
<td rowspan="1" colspan="1">MH</td>
<td rowspan="1" colspan="1">Implemented Resolution in Editors'
actions <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/292">292</a>
and <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/293">293</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">200706016</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/289">289</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070616</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4074">4074</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/286">286</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">200706018</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/295">295</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">200706018</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Implemented place holder for Editors'
action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/249">249</a>
for locking the document.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070713</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Restructured and updated <a href=
"#interrelated-domains"><b>5.8 Interrelated domains</b></a> to use
Architecture of WWW format and add example, according to Editors'
action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/309">309</a>.
Updated the WSDL 20 reference [<cite><a href="#WSDL20">WSDL 2.0
Core Language</a></cite>] and WS-SecurityPolicy reference
[<cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>]
for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4831">4831</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/326">326</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070717</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4853">4853</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/333">333</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070717</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4852">4852</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/332">332</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070717</td>
<td rowspan="1" colspan="1">DBO</td>
<td rowspan="1" colspan="1">Implemented partial resolution, section
5.5 updates, for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4662">4662</a>,
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/332">332</a>
#2.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070718</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3988">3988</a>.
Editors' action: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/338">338</a>,
drop <a href=
"http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070330/#scenario">
Section 7 Scenario and a worked example</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070718</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=3978">3978</a>.
Editors' action: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/339">339</a>,
drop <a href=
"http://www.w3.org/TR/2007/WD-ws-policy-guidelines-20070330/#best-practices-attachment">
Section 6 Applying Best Practices for Policy Attachment</a></td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070718</td>
<td rowspan="1" colspan="1">DBO</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4661">4661</a>,
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4662">4662</a>,
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4861">4861</a>.
Editors' action: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/342">342</a>,
<a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/346">346</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070718</td>
<td rowspan="1" colspan="1">DBO</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4664">4664</a>.
Editors' action: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/343">343</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070718</td>
<td rowspan="1" colspan="1">DBO</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4566">4566</a>.
Editors' action: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/249">249</a>,
<a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/328">328</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070718</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4862">4862</a>.
Editors' action: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/348">348</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070718</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4654">4654</a>.
Editors' action: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/340">340</a>.
Add new section <a href="#general-attachment-guidelines"><b>5.7.1
General Guidelines</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070718</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Updated Web Services Reliable Messaging
Policy reference [<cite><a href="#WS-RM-Policy">Web Services
Reliable Messaging Policy Assertion</a></cite>] and WS-Addressing
Metadata reference [<cite><a href=
"#WS-AddressingMetadata">WS-Addressing Metadata</a></cite>].
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/331">331</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070719</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4859">4859</a>.
Editors' action: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/335">335</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070727</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4660">4660</a>.
Editors' action: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/342">342</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070727</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4695">4695</a>.
Editors' action: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/347">347</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070727</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Updated Section <a href=
"#change-description"><b>E. Changes in this Version of the
Document</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070806</td>
<td rowspan="1" colspan="1">FS</td>
<td rowspan="1" colspan="1">Updated references for draft
publication.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070912</td>
<td rowspan="1" colspan="1">PY</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5041">5041</a>.
Editors' action: <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/347">356</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070912</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5043">5043</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/357">357</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070913</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=4861">4861</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/353">353</a>
with the caveats and clarifications expressed in message <a href=
"http://lists.w3.org/Archives/Public/public-ws-policy-eds/2007Sep/0002.html">
2007Sep-0002</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070921</td>
<td rowspan="1" colspan="1">MH</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5044">5044</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/358">358</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070921</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Updated references [<cite><a href=
"#WS-Policy">Web Services Policy Framework</a></cite>] and
[<cite><a href="#WS-PolicyAttachment">Web Services Policy
Attachment</a></cite>].</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20070921</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Reset Section <a href=
"#change-description"><b>E. Changes in this Version of the
Document</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071017</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5128">5128</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/371">371</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071017</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5185">5185</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/373">373</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071024</td>
<td rowspan="1" colspan="1">FJH</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5184">5184</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/372">372</a>.
Implemented as originally proposed b,c,e,f,h,j. Implemented as
amended a, k,l. Did not implement g which was not processed by
WG.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071024</td>
<td rowspan="1" colspan="1">TIB</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5186">5186</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/374">374</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071026</td>
<td rowspan="1" colspan="1">MH</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5206">5206</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/379">379</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071026</td>
<td rowspan="1" colspan="1">MH</td>
<td rowspan="1" colspan="1">Implemented the resolution for issue
<a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5189">5189</a>.
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/381">381</a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071026</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Fixed typos (re <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5206">5206</a> and
editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/379">379</a>).
s/Example 1/SignBeforeEncrypting assertion/ and s/Example
2/EncryptBeforeSigning assertion/ in <a href=
"#order-of-behaviors"><b>5.3.5 Order of Behaviors</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071026</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Fixed incorrect changes (re <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5184">5184</a> and
editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/372">372</a>).
a) s/Supporting New Policy Subjects/(see Section 6.3 Supporting New
Policy Subjects)/ and b) s/6.3 Supporting New Policy Subjects (see
Section 6.3 Supporting New Policy Subjects)/6.3 Supporting New
Policy Subjects/.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071026</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Applied missed changes (re <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5186">5186</a> and
editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/374">374</a>)
to <a href="#xml-namespaces"><b>B. XML Namespaces</b></a> and
<a href="#references"><b>C. References</b></a>. Fixed SOAP 1.2, Web
Services Reliable Messaging, Web Services Reliable Messaging Policy
Assertion, WS-SecurityPolicy and WS-Trust references.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071026</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Updated <a href=
"#change-description"><b>E. Changes in this Version of the
Document</b></a>.</td>
</tr>
<tr>
<td rowspan="1" colspan="1">20071029</td>
<td rowspan="1" colspan="1">ASV</td>
<td rowspan="1" colspan="1">Incorporated Chris' proposed resolution
for issue <a href=
"http://www.w3.org/Bugs/Public/show_bug.cgi?id=5218">5218</a>: drop
the second sentence in <a href=
"#bp-semantics-multiple-same-type"><b>21. Describe Semantics of
Multiple Assertions of Same Type</b></a>, "If there are multiple
instances of a policy assertion type in the same policy alternative
without parameters and nested policies, these have the same meaning
as a single assertion of the type within the policy alternative."
Editors' action <a href=
"http://www.w3.org/2005/06/tracker/wspolicyeds/actions/384">384</a>.</td>
</tr>
</tbody>
</table>
<br /></div>
</div>
</body>
</html>