- From: Asir Vedamuthu via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 30 Nov 2006 06:16:31 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv20885
Modified Files:
ws-policy-primer-diff20061109.xml build.xml
ws-policy-guidelines-diff20061109.xml
ws-policy-primer-diff20061109.html
ws-policy-guidelines-diff20061109.html
Added Files:
ws-policy-guidelines-diffaction-77.xml
ws-policy-guidelines-diffaction-77.html
ws-policy-guidelines-action-77.xml
Log Message:
There are three items:
A) Regenerated Primer document diff since Nov 9th 2006
B) Regenerated Guidelines document diff since Nov 9th 2006
C) [ACTION-89] Created a new Guidelines document diff since action 77
Index: ws-policy-guidelines-diff20061109.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines-diff20061109.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ws-policy-guidelines-diff20061109.xml 28 Nov 2006 23:47:21 -0000 1.2
+++ ws-policy-guidelines-diff20061109.xml 30 Nov 2006 06:16:29 -0000 1.3
@@ -83,24 +83,25 @@
<div1 id="introduction">
<head>Introduction</head>
- <p>WS-Policy specification defines a policy to be a collection
- of policy alternatives, where each policy alternative is a
- collection of policy assertions. <phrase diff="add">Policy is a flexible framework to represent
- consistent compinations of behaviors from a variety of domains.
- A policy assertion is a machine readable metadata exxpression that
+ <p><phrase diff="add">The </phrase>WS-Policy specification defines a policy to be a collection
+ of policy <phrase diff="chg">alternatives with </phrase>each policy alternative <phrase diff="del">is </phrase>a
+ collection of policy assertions. <phrase diff="add">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.
</phrase><emph>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</emph>
- is a resource primarily for assertion authors that provides
+ is a resource primarily for assertion authors <phrase diff="chg">and </phrase>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 are XML expressions
that communicate the requirements and capabilities of a web
- service by adhering to the specification, WS-Policy Framework. It
- was recognized that in order to enable interoperability of web
- services, different sets of WS-Policy Assertions needed to be
- defined by different communities based upon the requirements of
+ service by adhering to the specification, WS-Policy Framework. <phrase diff="add">To</phrase><phrase diff="del">It
+ was recognized that in order to </phrase>enable interoperability of web
+ <phrase diff="chg">services </phrase>different sets of WS-Policy Assertions <phrase diff="chg">need </phrase>to be
+ defined by different communities based upon <phrase diff="chg">domain-specific </phrase>requirements of
the web service.
@@ -114,7 +115,7 @@
reasoned about in a consistent manner.
</phrase></p>
<p>The focus of these guidelines is to capture best practices
- and usage patterns for practitioners to follow. It is a
+ and usage patterns for <phrase diff="add">practitioners.</phrase><phrase diff="del">practitioners to follow. </phrase>It is a
complementary guide to the Framework and Attachments
specifications and primer. It is intended to provide
non-normative guidelines for:
@@ -158,7 +159,7 @@
Policy XML Namespace.)
</p>
<p diff="add"> <phrase diff="add">As a companion document to the primer, this document also follows
- the Socratic style of beginning with a question, and then</phrase><phrase diff="del">Basic </phrase><phrase diff="add">answering
+ the Socratic style of beginning with a question,</phrase><phrase diff="del">Basic </phrase><phrase diff="add">and then answering
the</phrase><phrase diff="del">Concepts: </phrase><phrase diff="add">question.
</phrase></p>
</div1>
@@ -167,15 +168,14 @@
<head>What is an <phrase diff="add">Assertion? </phrase><phrase diff="del">Assertion</phrase></head>
<p>An assertion is a piece of metadata that describes a
- capability of a specific WS-Policy domain. Sets of assertions
- are typically defined in a dedicated specification that describe
- their semantics, applicability and scoping requirements as well
+ capability <phrase diff="chg">related </phrase><phrase diff="add">to </phrase>a specific WS-Policy domain. Sets of <phrase diff="add">domain-specific </phrase>assertions
+ are typically defined in a dedicated specification that <phrase diff="chg">describes
+ </phrase>their semantics, applicability and scoping requirements as well
as their data type definition using XML Schema.
</p>
- <p><phrase diff="add">Given that interoperability and automation are the motivations, policy assertions that
- represent, shared and visible behaviors are useful pieces of metadata. Such
- assertions enable tooling and improve interoperability. The key to understanding when to
+ <p><phrase diff="add">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:
@@ -188,23 +188,26 @@
<item>
<p><phrase diff="add">Is the behavior visible?
</phrase></p>
- <p><phrase diff="add">A visible behavior refers to a requirement that manifests on the wire. Web services
+ <p><phrase diff="add">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 such as messaging, security, reliability and
+ 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 only rely on these wire messages that conform to such formats and protocols
- for interoperability. If an assertion describes a behavior that does not manifest on the
- wire then the assertion is not relevant to an interoperable interaction.
+ requesters rely on wire messages conforming to such formats and protocols
+ to achieve interoperability.
</phrase></p>
- <p><phrase diff="add">For example, say an assertion describes the privacy notice information of a provider
- and there is an associated regulatory safeguard in place on the provider’s side. Such
+ <p><phrase diff="add">If an assertion describes a behavior that does not manifest on the
+ wire then the assertion is not relevant to an interoperable interaction.
+ 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. Such
assertions may represent business or regulatory level metadata but do not add any value
to interoperability.
</phrase></p>
- <p><phrase diff="add">If an assertion has no wire- or message-level visible behavior, then the interacting
- participants may require some sort of additional non-repudiation mechanism to indicate
- compliance with the assertion. Introducing an additional non-repudiation mechanism adds
+ <p><phrase diff="add">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.
</phrase></p>
</item>
@@ -217,9 +220,7 @@
relevant to an interoperable interaction. Non-shared behaviors do not add any value for
tooling or interoperability. An example of a non-shared behavior is the use of logging
or auditing by the provider.
- </phrase></p>
-
- <p><phrase diff="add">requesters may use the policy intersection to select a compatible policy alternative
+ Requesters may use the policy intersection to select a compatible policy alternative
for a Web service interaction. If an assertion only describes one participant’s behavior
then this assertion will not be present in the other participants’ policy and the policy
intersection will unnecessarily produce false negatives.
@@ -233,8 +234,8 @@
<item>
<p><phrase diff="add">Is there a requirement that a choice must be made for successful interaction?</phrase></p>
- <p><phrase diff="add">Some behaviors refer to a requirement that providers and requesters must deliberately choose
- to engage in. Examples, of such behaviors are the use of optimization, and reliable messaging.
+ <p><phrase diff="add">Sometimes providers and requesters are required to engage in certain behaviors.
+ The use of optimization and reliable messaging are two examples.
</phrase></p>
</item>
</ulist>
@@ -313,19 +314,19 @@
a way that multiple WS-Policy domains can co-exist and
consumers and providers can utilize the framework consistently across domains.
</p>
- <p>In order to take advantage of the WS-Policy Framework, any
- domain author attempting to define new WS-Policy assertions
- must adhere to the MUST's and SHOULD's in the specifications
- and should review the conformance section of the
+ <p><phrase diff="add">When</phrase><phrase diff="del">In order to take advantage </phrase><phrase diff="chg">using </phrase>the WS-Policy Framework, any
+ domain author <phrase diff="add">defining</phrase><phrase diff="del">attempting to define </phrase>new WS-Policy assertions
+ must adhere to the MUST's and SHOULD's in the <phrase diff="chg">specification
+ </phrase>and should review the conformance section of the
<phrase diff="del">specification. </phrase><phrase diff="add">specification.
</phrase></p>
<p>WS-Policy Domain authors must also specify how to associate
the assertions they have defined with the policy subjects
- identified by the WS-PolicyAttachment specification
- </p>
+ identified by the WS-PolicyAttachment <phrase diff="add">specification.
+ </phrase><phrase diff="del">specification</phrase></p>
<p>An example of a domain specification that
- includes these properties can be seen in the WS-SecurityPolicy
- <phrase diff="chg">pecification </phrase>[<bibref ref="WS-SecurityPolicy"></bibref>]. The
+ <phrase diff="del">includes these properties </phrase><phrase diff="chg">follows these practices is </phrase>the WS-SecurityPolicy
+ specification [<bibref ref="WS-SecurityPolicy"></bibref>]. The
WS-SecurityPolicy authors have defined their scope as follows:
</p>
<p>
@@ -352,8 +353,8 @@
<head>Consumers</head>
<p>A consumer of WS-Policy
Assertions can be any entity that is capable of parsing a
- WS-Policy xml element, and selecting one alternative from the
- policy, that it then uses to govern the creation of a message
+ WS-Policy <phrase diff="chg">XML element </phrase>and selecting one alternative from the
+ <phrase diff="chg">policy. This </phrase><phrase diff="add">selected alternative</phrase><phrase diff="del">it </phrase><phrase diff="add">is </phrase>then <phrase diff="chg">used </phrase>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 models for use with common web service
@@ -362,7 +363,7 @@
References (EPR) [<bibref ref="WS-Addressing"></bibref>].
</p>
<p>
- In the degenerate case, a human could read the xml and
+ In the degenerate case, a human could read the <phrase diff="chg">XML </phrase>and
determine if a message could be constructed conformant to the
advertised policy.
</p>
@@ -377,7 +378,7 @@
<div3 id="providers">
<head>Providers</head>
<p>A provider of WS-Policy Assertions can be any web service implementation that can
- specify its' on-the-wire message behavior as an XML
+ specify <phrase diff="chg">its </phrase>on-the-wire message behavior as an XML
expression that conforms to the WS-PolicyFramework and
WS-Policy Attachment specifications. The
WS-PolicyAttachment specification has defined a set of
@@ -387,7 +388,7 @@
it may also need to conform to requirements of other policy
specifications it utilizes ( i.e., WS-SecurityPolicy).
</p>
- <p>When deploying services with policies it is uesful for providers to anticipate how
+ <p>When deploying services with policies it is <phrase diff="chg">useful </phrase>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,
@@ -402,10 +403,10 @@
<div1 id="general-guidelines">
<head>General Guidelines for WS-Policy Assertion Authors</head>
<p diff="add"> <phrase diff="add">As 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 desgin. WS-Policy
- relies on the Qname of a policy assertion being an XML element but allows authors to optionally
+ 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 authors to optionally
provide additional semantics through nesting assertions, or specifying assertion parameters.
- This section covers several aspects of assertion design and provides somes answers to the following questions:</phrase></p>
+ This section covers several aspects of assertion design and provides some answers to the following questions:</phrase></p>
<ulist diff="add">
<item>
<p><phrase diff="add">What is the intended use of the policy assertion?</phrase></p>
@@ -414,7 +415,7 @@
<p><phrase diff="add">Which authoring style will be used?</phrase></p>
</item>
<item>
- <p><phrase diff="add">Is this a new policy domain? does it need to compose with other domains?</phrase></p>
+ <p><phrase diff="add">Is this a new policy domain? Does it need to compose with other domains?</phrase></p>
</item>
<item>
<p><phrase diff="add">How complex are the assertions?</phrase></p>
@@ -455,7 +456,8 @@
stand alone client applications to "active" web service
requestors that are capable of modifying their own configurations dynamically.
</p>
- <p> Once the range of policy subjects are identified, there are choices for ways of
+ <p> Once the range of policy subjects
+ <phrase diff="del">are </phrase><phrase diff="add">is </phrase>identified, there are choices for ways of
attaching multiple instances of a simple policy
assertion to multiple subjects. One way is to utilize
the referencing mechanism that is present in the
@@ -463,7 +465,7 @@
in different policies (e.g. with different
alternatives) via reference, a policy assertion may be
associated with different alternatives and subjects. A
- <phrase diff="chg">eferencing </phrase>mechanism is very useful in a tooling
+ referencing mechanism is very useful in a tooling
environment; when creating a domain specific
attachment in multiple WSDL files or Endpoint
References in which the same set of policies are expected to be applied.
@@ -471,9 +473,9 @@
<p><phrase diff="chg">Best practice: </phrase>WS-Policy <phrase diff="del">domain </phrase>authors should <phrase diff="chg">include </phrase>the following
<phrase diff="add">items
</phrase><phrase diff="del">factors when </phrase><phrase diff="chg">in </phrase>the <phrase diff="add">dialect</phrase><phrase diff="del">set of domain assertions as it
- may make sense to factor out some assertions that can be
- used by </phrase><phrase diff="add">specification:
- </phrase><phrase diff="del">multiple subjects:
+ may make sense to factor out some assertions that can </phrase><phrase diff="add">specification:
+ </phrase><phrase diff="del">be
+ used by multiple subjects:
</phrase></p>
<ulist>
<item>
@@ -520,7 +522,7 @@
<head>Authoring Styles </head>
- <p> WS-Policy supports 2 different authoring styles. A compact form is one in which an expression consists of three
+ <p> WS-Policy supports <phrase diff="chg">two </phrase>different authoring styles. 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.
</p>
@@ -588,13 +590,13 @@
in a policy, the normal form may express the choices more explicitly.
On the other hand, the compact form is more
readable for humans when an assertion is marked as optional
- using the <code>@optional</code> attribute as our example illustrates above.
+ using the <code><phrase diff="chg">wsp:optional</phrase></code> attribute as our example illustrates above.
</p>
- <p><phrase diff="add">Best practice: use the authoring style
+ <p><phrase diff="add">Best practice: use the authoring style most appropriate
- </phrase><phrase diff="del">Guidelines </phrase><phrase diff="add">most appropriate </phrase>for <phrase diff="chg">the target </phrase><phrase diff="add">audience </phrase></p>
+ </phrase><phrase diff="del">Guidelines </phrase>for <phrase diff="chg">the target </phrase><phrase diff="add">audience </phrase></p>
</div2><p diff="del">Assertions
</p><div2 id="new-guidelines-domains" diff="chg">
@@ -604,11 +606,11 @@
framework implementation that has followed </phrase>the
<phrase diff="del">framework. </phrase><phrase diff="add">specifications.
</phrase></p>
- <p diff="add"><phrase diff="add">The</phrase><phrase diff="del">Some </phrase><phrase diff="chg">examples given in </phrase><phrase diff="add">this document reference WS-Policy</phrase><phrase diff="del">infrastructure
- efforts </phrase>like WS-SecurityPolicy and WS-RM Policy.
+ <p diff="add"><phrase diff="add">The</phrase><phrase diff="del">Some </phrase><phrase diff="chg">examples given in </phrase><phrase diff="add">this document reference</phrase><phrase diff="del">infrastructure
+ efforts </phrase><phrase diff="add">WS-Policy </phrase>like WS-SecurityPolicy and WS-RM Policy.
<phrase diff="add">These </phrase><phrase diff="chg">policy </phrase><phrase diff="add">expressions</phrase><phrase diff="del">also
- anticipate </phrase><phrase diff="add">represent web services message exchange requirements, but policy</phrase><phrase diff="del">that </phrase><phrase diff="add">authoring can
- be done by </phrase>individual <phrase diff="add">groups that wish to represent </phrase>web services <phrase diff="add">application requirements</phrase><phrase diff="del">applications </phrase>and
+ anticipate </phrase><phrase diff="add">represent web services message exchange requirements, but policy authoring can
+ be done</phrase><phrase diff="del">that </phrase><phrase diff="add">by </phrase>individual <phrase diff="add">groups that wish to represent </phrase>web services <phrase diff="add">application requirements</phrase><phrase diff="del">applications </phrase>and
deployments <phrase diff="chg">that </phrase>wish to reuse the WS-Policy framework in
order to enable dynamic negotiation of business requirements
and capabilities at runtime.
@@ -620,19 +622,19 @@
behavior. Sets of assertions can by grouped by an operator "all". This indicates that there is a relationship between
the assertions and they now constitute a policy alternative.
</p>
- <p><phrase diff="add">If grouping is utilized,</phrase><phrase diff="del">Choices </phrase><phrase diff="add">choices </phrase>between alternatives can be indicated by
+ <p><phrase diff="add">If grouping is utilized, choices</phrase><phrase diff="del">Choices </phrase>between alternatives can be indicated by
an "exactly one" operator. This basic set of operators allows
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
- <phrase diff="chg">eflects </phrase>the options of the domain if the domain has a lot of
+ 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.
</p>
<p>New authors are encouraged to look at <bibref ref="WS-RM-Policy"></bibref> to see an example of a
- relatively simple domain that has defined 3 assertions. Domain authors are encouraged to look at <bibref ref="WS-SecurityPolicy"></bibref> to see an example of a complex domain that has been decomposed into a set of policy expressions.
+ relatively simple domain that has defined <phrase diff="chg">three </phrase>assertions. Domain authors are encouraged to look at <bibref ref="WS-SecurityPolicy"></bibref> to see an example of a complex domain that has been decomposed into a set of policy expressions.
</p>
<p><phrase diff="add">How big should an assertion be? How many assertion parameters should the assertion
enumerate? How many dependent behaviors should the assertion enumerate? It is always
@@ -640,7 +642,7 @@
design work progresses, you may add more parameters or nested policy assertions to meet
your interoperability needs.
</phrase></p>
- <p><phrase diff="add">Best practice: start with a simple working assertion that allows extensibility.
+ <p><phrase diff="add">Best practice: Start with a simple working assertion that allows extensibility.
</phrase></p>
</div3>
<div3 id="QName_and_XML_Information_Set_representation" diff="add">
@@ -656,7 +658,7 @@
document). If the assertion has a nested policy expression then the assertion XML
outline can enumerate the nested assertions that are allowed.
</phrase></p>
- <p><phrase diff="add">Best practice: use a unique QName to identify the behavior and provide an XML outline
+ <p><phrase diff="add">Best practice: Use a unique QName to identify the behavior and provide an XML outline
(plus an XML schema document) to specify the syntax of an assertion.
</phrase></p>
</div3>
@@ -705,9 +707,9 @@
<p><phrase diff="add">Another approach is to use of the assertion to selectively apply to subjects. For example, a
dedicated endpoint may be allocated to ensure the engagement of a
behavior that is expressed by a policy assertion. This approach
- can be considered when messages can not be self describing.
+ can be considered when messages cannot be self describing.
</phrase></p>
- <p><phrase diff="add">Best practice:Policy assertions should not be used to express the semantics of a message.
+ <p><phrase diff="add">Best practice: Policy assertions should not be used to express the semantics of a message.
</phrase></p>
</div3>
<div3 id="single-domains" diff="add">
@@ -731,7 +733,7 @@
</p>
<p>The model advocated for new
assertion development is a cooperative marketplace
- [some might say its an "opt-in" model]. The providers
+ [some might say <phrase diff="chg">it </phrase><phrase diff="add">is </phrase>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.
@@ -849,25 +851,25 @@
</example>
<p>The <code>sp:AlgorithmSuite</code> is a nested policy assertion of
- the <code>sp:TransportBinding</code> policy assertion. The<code>sp:AlgorithmSuite</code>
+ 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>
<emph>in the example above</emph>) 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
+ <phrase diff="chg">security, </phrase>a policy-aware client that recognizes this policy
assertion can engage transport-level security and its
- dependent behaviors automatically. That is, the complexity of
+ dependent behaviors automatically. <phrase diff="chg">This means </phrase>the complexity of
security usage is absorbed by a policy-aware client and hidden
- from these Web service developers.
+ from <phrase diff="del">these </phrase>Web service <phrase diff="add">application </phrase>developers.
</p>
</div3>
<div3 id="which-one-to-use">
<head>Considerations for choosing parameters vs nesting</head>
<p>The main consideration for selecting parameters or nesting
- of assertions, is that <emph>the framework intersection
+ of <phrase diff="chg">assertions </phrase>is that <emph>the framework intersection
algorithm processes nested alternatives, but does not consider
parameters in its algorithm</emph>.
</p>
@@ -900,39 +902,47 @@
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 </phrase><phrase diff="chg">following design questions below </phrase>can <phrase diff="add">help
- you</phrase><phrase diff="del">be
+ </phrase><phrase diff="del">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 </phrase>to <phrase diff="add">determine</phrase><phrase diff="del">understand a </phrase><phrase diff="chg">when to </phrase><phrase diff="add">use</phrase><phrase diff="del">not
available, </phrase><phrase diff="chg">nested policy </phrase><phrase diff="add">expressions:</phrase><phrase diff="del">suffer.
</phrase></p>
- <p><phrase diff="chg">Are </phrase><phrase diff="add">these</phrase><phrase diff="del">assertions should not be
+ <ulist diff="add">
+ <item>
+
+ <p><phrase diff="add">Are</phrase><phrase diff="del">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
+ the message, or be made available by some other means (e.g., </phrase><phrase diff="add">these</phrase><phrase diff="del">being
referenced by </phrase><phrase diff="chg">assertions designed for </phrase>the <phrase diff="add">same</phrase><phrase diff="del">message) instead of being communicated as a
</phrase>policy <phrase diff="chg">subject? </phrase></p>
- <p><phrase diff="add">Do</phrase><phrase diff="del">For example, if </phrase><phrase diff="add">these</phrase><phrase diff="del">the details of </phrase><phrase diff="add">assertions</phrase><phrase diff="del">a
+ </item>
+ <item>
+
+ <p><phrase diff="add">Do</phrase><phrase diff="del">For example, </phrase><phrase diff="add">these</phrase><phrase diff="del">if the details of </phrase><phrase diff="add">assertions</phrase><phrase diff="del">a
message's </phrase><phrase diff="chg">represent dependent </phrase><phrase diff="add">behaviors?</phrase></p>
+ </item>
+ </ulist>
<p diff="add"><phrase diff="add">If</phrase><phrase diff="del">e.g., </phrase>the <phrase diff="add">answers</phrase><phrase diff="del">cipher used, etc) </phrase>are <phrase diff="add">yes</phrase><phrase diff="del">expressed
in policy that isn't attached </phrase>to <phrase diff="add">both</phrase><phrase diff="del">the message, </phrase><phrase diff="chg">of these </phrase><phrase diff="add">questions</phrase><phrase diff="del">possible
to </phrase><phrase diff="chg">then leveraging nested </phrase><phrase diff="add">policy
expressions</phrase><phrase diff="del">This </phrase>is <phrase diff="chg">something to consider. Keep </phrase>in
- <phrase diff="del">policy, what ciphers </phrase><phrase diff="add">mind</phrase><phrase diff="del">(and so forth) are supported </phrase><phrase diff="chg">that </phrase>a <phrase diff="add">nested</phrase><phrase diff="del">particular
+ <phrase diff="del">policy, what ciphers (and so </phrase><phrase diff="add">mind</phrase><phrase diff="del">forth) are </phrase><phrase diff="add">that</phrase><phrase diff="del">supported by </phrase>a <phrase diff="add">nested</phrase><phrase diff="del">particular
endpoint, or those </phrase><phrase diff="chg">policy expression participates </phrase>in
<phrase diff="chg">the policy intersection </phrase><phrase diff="add">algorithm.</phrase><phrase diff="del">the
latter </phrase><phrase diff="chg">If a requester </phrase>uses <phrase diff="chg">policy intersection to </phrase><phrase diff="add">select</phrase><phrase diff="del">framework.
As </phrase>a
- <phrase diff="add">compatible </phrase><phrase diff="del">result, the assertion </phrase><phrase diff="add">policy</phrase><phrase diff="del">authors
- should take into </phrase><phrase diff="chg">alternative then </phrase>the <phrase diff="del">following important concepts
+ <phrase diff="add">compatible </phrase><phrase diff="del">result, the assertion authors
+ should </phrase><phrase diff="add">policy</phrase><phrase diff="del">take into </phrase><phrase diff="chg">alternative then </phrase>the <phrase diff="del">following important concepts
when designing </phrase>assertions <phrase diff="add">in</phrase><phrase diff="del">and documenting the semantics of the
assertion types. </phrase><phrase diff="chg">a nested policy expression play </phrase>a
<phrase diff="add">first
</phrase><phrase diff="del">runtime behavior. Secondly, an assertion </phrase><phrase diff="add">class</phrase><phrase diff="del">should
also </phrase><phrase diff="chg">role in </phrase>the <phrase diff="add">outcome.</phrase><phrase diff="del">assertion type can be inferred or indicated
from a message at runtime. If </phrase><phrase diff="chg">There </phrase>is <phrase diff="add">one</phrase><phrase diff="del">a need for </phrase><phrase diff="chg">caveat </phrase><phrase diff="del">behavior
- </phrase>to <phrase diff="add">watch</phrase><phrase diff="del">be represented in a persistent way or </phrase><phrase diff="chg">out for: policy </phrase><phrase diff="add">assertions
+ </phrase>to <phrase diff="add">watch</phrase><phrase diff="del">be represented in a persistent way </phrase><phrase diff="add">out</phrase><phrase diff="del">or if </phrase><phrase diff="chg">for: policy </phrase><phrase diff="add">assertions
with</phrase><phrase diff="del">a </phrase><phrase diff="chg">deeply </phrase><phrase diff="add">nested</phrase><phrase diff="del">for
additional </phrase><phrase diff="chg">policy can greatly increase the complexity of </phrase>a <phrase diff="add">policy</phrase><phrase diff="del">message to be
persisted, </phrase><phrase diff="chg">and </phrase>should be
@@ -972,7 +982,7 @@
<head><phrase diff="add">Optional behavior in Compact authoring</phrase></head>
<p>Optional behaviors represent behaviors which may be engaged by a consumer. When using the
compact authoring form for assertions, behaviors are marked by
- using <code>wsp:optional</code> attribute that has a value,
+ using <code><phrase diff="chg">wsp:Optional</phrase></code> attribute that has a value,
"true". During the process of normalization, the runtime
behavior is indicated by two policy alternatives, one with and
one without <phrase diff="del">containing </phrase>the assertion. In a consumer/provider
@@ -999,7 +1009,7 @@
<p>The semantics of this assertion declare that the behavior
is reflected in messages: they use an optimized wire format
(MIME Multipart/Related serialization). Note that in order for
- an optional behaviors to be engaged, the wire message that
+ an optional <phrase diff="chg">behavior </phrase>to be engaged, the wire message that
would utilize the specific assertion must be self
describing. For example, an inbound message to a web service
that asserts MTOM, must evaluate, the protocol format of the
@@ -1071,12 +1081,13 @@
when optional behaviors are specified for message
exchanges within a request response for response messages,
using message policy subject. Leaving the semantics
- undescribed may result in providers making assumptions
+ <phrase diff="add">not specified
+ </phrase><phrase diff="del">undescribed </phrase><phrase diff="add">or incompletely specified </phrase>may result in providers making assumptions
(i.e. if the incoming message utilized the optimization,
the response will be returned utilizing the MTOM
serialization). Similarly, if engagement of a behavior is
only specified for an outbound message, the policy
- assertion authors should consider to describe the
+ assertion authors should consider <phrase diff="add">describing </phrase><phrase diff="del">to describe </phrase>the
semantics if the incoming messages also utilized the
behavior. This is especially important if the assertion is
applicable to more than one specific policy subject. One
@@ -1127,7 +1138,7 @@
if an assertion is specific to a policy attachment
mechanism. An example could be identifying whether the
assertion expressed is associated with behaviors
- (endpoints) or artifacts ( messages) and then constraining
+ (endpoints) or artifacts <phrase diff="add">(messages)</phrase><phrase diff="del">( messages) </phrase>and then constraining
the use of an assertion to one of these subjects.
</p>
<p>Thus our example encryption assertion would have a
@@ -1139,16 +1150,16 @@
the definition of other domain expressions to be policy
subjects. More of this topic is covered in the <bibref ref="WS-Policy-Primer"></bibref>
</p>
-
- <p><phrase diff="add">Best Practice- To avoid confusion, assertion definitions should be
+ <p diff="add"><phrase diff="add">Best Practice- To avoid confusion, assertion definitions should be
precise about their semantics and include information that
restricts their set of permissible policy subjects
- appropriately and indicates which Qnames are associated with
- which subjects.</phrase><phrase diff="del">EXAMPLE</phrase></p>
+ appropriately and indicates which QNames are associated with
+ which subjects.</phrase></p>
<olist diff="add">
<item>
- <p><phrase diff="add">Description must clearly and completely specify the syntax (plus an XML Schema
- document) and semantics of a policy assertion.</phrase></p>
+
+ <p><phrase diff="add">Description must clearly and completely specify the syntax (plus an XML Schema
+ document) and semantics of a policy assertion.</phrase><phrase diff="del">EXAMPLE</phrase></p>
</item>
<item>
<p><phrase diff="add">If there is a nested policy expression, description must declare it and enumerate the
@@ -1204,10 +1215,12 @@
the domain authors chose to support certain capabilities at
the endpoint level. This resulted in the finer granularity of
the assertion to apply at the message policy subject, but the
- assertion semantics also indicates that the if the senders
- choose to engage RM semantics (although not specified via
- attachment in WSDL at incoming messages), the providers will
- honor the engagement of RM. This is illustrative of how the
+ assertion semantics also indicates that the if
+ <phrase diff="add">a </phrase><phrase diff="chg">sender </phrase><phrase diff="add">chose</phrase><phrase diff="del">senders
+ choose </phrase>to engage RM
+ semantics (although not specified via attachment in WSDL at incoming
+ messages), the providers will honor the engagement of RM.
+ This is illustrative of how the
assertion author can specify additional constraints and
assumptions for attachment and engagement of behavior.
</p>
@@ -1327,14 +1340,12 @@
<div2 id="extending-assertions">
- <head> Factors in Extending Assertions within a Domain </head>
- <p> Extensibility affects the policy subjects and attachment semantics. </p>
- </div2>
- <div2 id="assertion-evolution">
+ <head> <phrase diff="del">Factors in Extending Assertions within a Domain
+ Extensibility affects the policy subjects and attachment semantics.
- <head>Evolution of Assertions (Versioning and Compatibility)</head>
- <p>4.4.7. Over time, there may be multiple equivalent behaviors emerging in the Web
+ </phrase>Evolution of Assertions (Versioning and Compatibility)</head>
+ <p><phrase diff="del">4.4.7. </phrase>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
[<bibref ref="WS-Addressing"></bibref>]. These equivalent behaviors
@@ -1343,17 +1354,25 @@
policy expression in the example below requires the use of
WSS: SOAP Message Security 1.0. </p>
<example>
- <head>Example 4-2. Message-level Security and WSS: SOAP Message Security 1.0 </head>
- <p>ADD THE EXAMPLE HERE </p>
- </example>
- <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>
- <example>
- <head>Example 4-3. Message-level Security and WSS: SOAP Message Security 1.1</head>
- <p>ADD THE EXAMPLE HERE </p>
- </example>
- <p>Best practice: use independent assertions for modeling multiple equivalent behaviors. </p>
- <!-- EDS TO DO REconcile from Primer. GET THE REST FROM DAVE and Umit -->
+ <head><phrase diff="del">Example 4-2. </phrase>Message-level Security and WSS: SOAP Message Security 1.0 </head>
+<eg xml:space="preserve"><Policy>
+ <sp:Wss10>…</sp:Wss10>
+</Policy></eg>
+ <phrase diff="del">ADD THE EXAMPLE HERE
+ </phrase></example>
+ <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>
+ <example>
+ <head><phrase diff="del">Example 4-3. </phrase>Message-level Security and WSS: SOAP Message Security 1.1</head>
+<eg xml:space="preserve"><Policy>
+ <sp:Wss11>…</sp:Wss11>
+</Policy></eg>
+ <phrase diff="del">ADD THE EXAMPLE HERE
+ </phrase></example>
+ <p>Best practice: use independent assertions for modeling multiple equivalent
+ behaviors. </p>
+
</div2>
</div1>
@@ -1366,8 +1385,8 @@
modeling protocol assertions may appear to be an independent behavior,
protocol assertions and security assertions affect transport
bindings and their interactions must be considered. For
- example, utilization of WS-Security Policy with other
- protocols affect transport binding and would result in nested
+ <phrase diff="chg">example </phrase>utilization of WS-Security Policy with other
+ protocols <phrase diff="chg">affects </phrase>transport <phrase diff="chg">bindings </phrase>and would result in nested
policy assertions when additional protocols are composed with
<bibref ref="WS-Security2004"></bibref>. Thus, domain authors should
be aware of the compositional semantics with other related
@@ -1414,17 +1433,17 @@
mechanisms should make it possible to clearly identify the
source of a poly assertion both for debugging and for
verification. This could take several forms: it could be
- assumed ( in WSDL, the source of the assertion is the same
- as the WSDL provider) or it could be proven ( using
- <bibref ref="WS-Trust"></bibref>). </p>
+ assumed <phrase diff="add">(in</phrase><phrase diff="del">( in </phrase>WSDL, the source of the assertion is the same
+ as the WSDL provider) or it could be proven <phrase diff="add">(using</phrase><phrase diff="del">( using
+ </phrase><bibref ref="WS-Trust"></bibref>). </p>
</div2>
</div1>
- <div1 id="scenerio">
+ <div1 id="scenario" diff="chg">
<head>Scenario and a worked example</head>
<p>To illustrate the topics explored in this document, we
include an example of a web service and how a fictitious company
might utilize the WS-Policy Framework to enable Web Service
- interoperability. CompanyA has determined to utilize WS-Security,
+ interoperability. <phrase diff="add">Company A</phrase><phrase diff="del">CompanyA </phrase>has determined to utilize WS-Security,
WS-Addressing and WS-Reliable Messaging in all its new web
service offerings and has instructed its developers to use the
policy assertions defined by the following documents: </p>
@@ -1439,11 +1458,11 @@
<p>Web Services Addressing WSDL Binding</p>
</item>
</ulist>
- <p>The application developers at CompanyA are instructed to
- review the current web services at CompanyA and propose a plan
+ <p>The application developers at <phrase diff="add">Company A</phrase><phrase diff="del">CompanyA </phrase>are instructed to
+ review the current web services at <phrase diff="chg">Company </phrase><phrase diff="add">A </phrase>and propose a plan
for adding policy assertions. </p>
<p>The application developers collect information about web
- services within CompanyA and determine that all of the web
+ services within <phrase diff="add">Company A</phrase><phrase diff="del">CompanyA </phrase>and determine that all of the web
services already have a WSDL 1.1 description. The developers
have determined that Company A's web services fall into two
types of web services. There are those that fall into the
@@ -1457,7 +1476,7 @@
or message exchange. </p>
<p>Service A is a WSDL 1.1 conformant web service and requires
the use of transport-level security for protecting messages as
- well as including addressing headers. Employees of CompanyA have
+ well as including addressing headers. Employees of <phrase diff="add">Company A</phrase><phrase diff="del">CompanyA </phrase>have
already incorporated <code>wss:Security</code> headers into their
messages. </p>
<example>
@@ -1478,7 +1497,7 @@
</example>
<p>The SOAP message in the example above includes security
timestamps that express creation and expiration times of this
- message. CompanyA requires the use of these security timestamps
+ message. <phrase diff="chg">Company </phrase><phrase diff="add">A </phrase>requires the use of these security timestamps
and transport-level security, such as HTTPS for protecting
messages. </p>
<p>The example below illustrates a policy expression that
@@ -1496,7 +1515,7 @@
<p>The <code>sp:TransportBinding</code> element is a policy assertion. The
assertion identifies the use of transport-level-security - such
as HTTPS for protecting messages at the transport
- level. CompanyA's policy aware clients can now recognize this
+ level. <phrase diff="add">Company A's</phrase><phrase diff="del">CompanyA's </phrase>policy aware clients can now recognize this
policy assertion and if they support it, engage in transport
level security for protecting messages and providing security
timestamps in SOAP envelopes for any WSDL with this policy
@@ -1509,25 +1528,25 @@
alternatives rather than forcing a single client
configuration. </p>
<p>The developers read the WS-Policy specification and noted that
- there were 3 ways to express combinations of behaviors. The three
- policy operators, ( Policy, All and ExactlyOne) were considered
+ there were <phrase diff="chg">three </phrase>ways to express combinations of behaviors. The three
+ policy operators, <phrase diff="add">(Policy,</phrase><phrase diff="del">( Policy, </phrase>All and ExactlyOne) were considered
and the result was the creation of two policy elements. </p>
<p>The first policy is shown in Figure
<emph>CompanyA-ProfileA</emph> and it is the policy that is used
- by many web services at Company A that rely on https to provide
+ by many web services at Company A that rely on <phrase diff="chg">HTTPS </phrase>to provide
transport level protection of messages. </p>
<p>The second policy is shown in Figure
<emph>CompanyA-ProfileB</emph> and it offers requestors of a
service the ability to provide additional integrity protection by
including WS-Security Headers to protect the message content
after it is processed by the transport. The additional security
- processing is not required by all CompanyA web services. </p>
- <example> <head>CompanyA-ProfileB ( not expanded)</head> <eg xml:space="preserve"> <Policy wsu:Id="CompanyA-ProfileB">
+ processing is not required by all <phrase diff="add">Company A</phrase><phrase diff="del">CompanyA </phrase>web services. </p>
+ <example> <head>CompanyA-ProfileB <phrase diff="add">(not</phrase><phrase diff="del">( not </phrase>expanded)</head> <eg xml:space="preserve"> <Policy wsu:Id="CompanyA-ProfileB">
<wsa:UsingAddressing /> <ExactlyOne>
<sp:TransportBinding></sp:TransportBinding>
<sp:AsymmetricBinding></sp:AssymetricBinding>
</ExactlyOne> </Policy> </eg> </example>
- <p>We have shown above that CompanyA offered a
+ <p>We have shown above that <phrase diff="chg">Company </phrase><phrase diff="add">A </phrase>offered a
second profile that included two security options. The details of
the Bindings, requires a more detailed exploration of some of the
other features of the WS-Policy Framework. </p>
@@ -1540,7 +1559,7 @@
an <code>sp:TransportBinding</code> assertion, just indicating the use of
transport-level security for protecting messages is not
sufficient. For a consumer of a web service provided by a company,
- like CompanyA, to successfully interact, the consumer must also
+ like <phrase diff="add">Company A,</phrase><phrase diff="del">CompanyA, </phrase>to successfully interact, the consumer must also
know what transport token, what algorithm suite, etc. is
required. The <code>sp:TransportBinding</code> assertion, can (and has)
represent (ed) these dependent behaviors as "nested" policy
@@ -1581,24 +1600,24 @@
indicates the use of a specific type of token, in this case an
HttpsToken. </p>
<p>It should be noted that each policy has an Identifier. In the
- case of the default policy expression, CompanyA has decided that
+ case of the default policy expression, <phrase diff="add">Company A</phrase><phrase diff="del">CompanyA </phrase>has decided that
this policy expression should be broadly available via a URI.
There are advantages and disadvantages to using each type of
identifier. For URI's there is the issue of maintaining the
- policy expression when it may no longer be used ( CompanyA gets
- bought by CompanyB and starts using the policies of Company B,
+ policy expression when it may no longer be used <phrase diff="chg">(Company A </phrase>gets
+ bought by <phrase diff="add">Company B</phrase><phrase diff="del">CompanyB </phrase>and starts using the policies of Company B,
but some "old" consumers may still try to reference the
URI). </p>
<p> For the second type of web services, which may be used only
- by certain of CompanyA's business partners, the id is an XML ID.
+ by certain of <phrase diff="add">Company A's</phrase><phrase diff="del">CompanyA's </phrase>business partners, the id is an XML ID.
The relative URI for referencing this within the same WSDL
document is #CompanyA-ProfileB. This can be useful for company's
when the policy expressions are agreed to between partners but
may be changed as the business agreements change. But the
disadvantage is that the policy expression must be included in
each WSDL document. </p>
- <p>Since CompanyA has decided to use well known policy
- expressions that are themselves part of a specification, they
+ <p>Since <phrase diff="chg">Company </phrase><phrase diff="add">A </phrase>has decided to use well known policy
+ expressions that are <phrase diff="del">themselves </phrase>part of a specification, they
adhere to the guidance given in the WS-SecurityPolicy
specification and attach the policies to the web service endpoint
policy subject as recommended by the WS-SecurityPolicy
@@ -1614,7 +1633,7 @@
</wsdl:binding> </eg>
</example>
<p>The partner specified policy is included in the beginning of
- the wsdl 1.1document and referenced by the binding for the service
+ the <phrase diff="add">WSDL 1.1</phrase><phrase diff="del">wsdl </phrase><phrase diff="chg">document </phrase>and referenced by the binding for the service
as in the example below.</p>
<example>
<head></head>
@@ -1984,7 +2003,24 @@
<td rowspan="1" colspan="1" diff="add">MH</td>
<td rowspan="1" colspan="1" diff="add">Replaced section in Lifecycle with pointer to the text in the primer: related to action 77
</td>
- </tr>
+ </tr>
+ <tr diff="add">
+ <td rowspan="1" colspan="1" diff="add">20061129</td>
+ <td rowspan="1" colspan="1" diff="add">FH</td>
+ <td rowspan="1" colspan="1" diff="add">Editorial revision (editorial actions
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/84" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">84</phrase></loc> and
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/90" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">90</phrase></loc>) -
+ includes suggestions from Asir:
+ <loc href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0129.html" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Part 1</phrase></loc> and
+ <loc href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0134.html" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Part 2</phrase></loc>.
+ </td>
+ </tr>
+ <tr diff="add">
+ <td rowspan="1" colspan="1" diff="add">20061129</td>
+ <td rowspan="1" colspan="1" diff="add">ASV</td>
+ <td rowspan="1" colspan="1" diff="add">Formatted examples in <specref ref="extending-assertions"></specref>.
+ </td>
+ </tr>
</tbody>
</table>
Index: build.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/build.xml,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -d -r1.20 -r1.21
--- build.xml 26 Nov 2006 00:08:41 -0000 1.20
+++ build.xml 30 Nov 2006 06:16:29 -0000 1.21
@@ -11,6 +11,7 @@
<property name="diffformat" value="diffspec.xsl"/>
<property name="last-public-draft" value="20061102"/>
<property name="snap-shot" value="20061109"/>
+ <property name="action-77" value="action-77"/>
<target name="clean">
<delete quiet="true" file="ws-policy-framework.html"/>
@@ -134,6 +135,18 @@
<arg value="--diff"/>
<arg value="both"/>
<arg value="--words"/>
+ <arg value="ws-policy-guidelines-${action-77}.xml"/>
+ <arg value="ws-policy-guidelines.xml"/>
+ <arg value="ws-policy-guidelines-diff${action-77}.xml"/>
+ <classpath path="diffmk.jar:DiffMk.properties">
+ </classpath>
+ </java>
+ <java classname="com.sun.xtc.diffmk.DiffMk" fork="true">
+ <arg value="--doctype"/>
+ <arg value="xmlspec"/>
+ <arg value="--diff"/>
+ <arg value="both"/>
+ <arg value="--words"/>
<arg value="ws-policy-primer-${snap-shot}.xml"/>
<arg value="ws-policy-primer.xml"/>
<arg value="ws-policy-primer-diff${snap-shot}.xml"/>
@@ -144,6 +157,7 @@
<xslt style="${diffformat}" in="ws-policy-attachment-diff${last-public-draft}.xml" out="ws-policy-attachment-diff${last-public-draft}.html"/>
<xslt style="${diffformat}" in="ws-policy-primer-diff${snap-shot}.xml" out="ws-policy-primer-diff${snap-shot}.html"/>
<xslt style="${diffformat}" in="ws-policy-guidelines-diff${snap-shot}.xml" out="ws-policy-guidelines-diff${snap-shot}.html"/>
+ <xslt style="${diffformat}" in="ws-policy-guidelines-diff${action-77}.xml" out="ws-policy-guidelines-diff${action-77}.html"/>
</target>
<target name="changelog" description="Generate XML out of the CVS change log">
--- NEW FILE: ws-policy-guidelines-diffaction-77.html ---
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en-US"><head><META http-equiv="Content-Type" content="text/html; charset=utf-8"><meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"><title>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors -- Review Version</title><style type="text/css">
code { font-family: monospace; }
div.constraint,
div.issue,
div.note,
div.notice { margin-left: 2em; }
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; }
[...1916 lines suppressed...]
<a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0129.html"><span class="diff-add">Part 1</span></a> and
<a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0134.html"><span class="diff-add">Part 2</span></a>.
</td></div>
</tr></div>
<div class="diff-add"><tr class="diff-add">
<div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">20061129</td></div>
<div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">ASV</td></div>
<div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Formatted examples in <a href="#extending-assertions"><b>5.2 Factors in Extending Assertions within a Domain
Extensibility affects the policy subjects and attachment semantics.
Evolution of Assertions (Versioning and Compatibility)</b></a>.
</td></div>
</tr></div>
</tbody>
</table><br>
</div>
</div>
</body></html>
Index: ws-policy-primer-diff20061109.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer-diff20061109.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- ws-policy-primer-diff20061109.html 26 Nov 2006 00:08:41 -0000 1.1
+++ ws-policy-primer-diff20061109.html 30 Nov 2006 06:16:29 -0000 1.2
@@ -76,9 +76,11 @@
</dd><dt>Editors:</dt>
<dd>Asir S Vedamuthu, Microsoft Corporation</dd>
<dd>David Orchard, BEA Systems, Inc.</dd>
- <dd>Maryann Hondo, IBM Corporation</dd>
- <dd>Toufic Boubez, Layer 7 Technologies</dd>
- <dd>Prasad Yendluri, webMethods, Inc.</dd>
+ <dd><span class="diff-add">Frederick Hirsch</span><span class="diff-add">, <span class="diff-add">Nokia</span></span></dd>
+ <dd><span class="diff-add">Maryann Hondo, IBM Corporation</span></dd>
+ <dd><span class="diff-add">Prasad Yendluri</span><span class="diff-add">, <span class="diff-add">webMethods, Inc.</span></span></dd>
+ <dd><span class="diff-add">Toufic Boubez, Layer 7 Technologies</span></dd>
+ <dd><span class="diff-chg">Ümit Yalçinalp</span>, <span class="diff-chg">SAP AG.</span></dd>
</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © @@@@ <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">Abstract</a></h2>
<p>
@@ -1837,6 +1839,7 @@
</p></div></div>
</div></div>
+
</div></div>
<div class="div1">
@@ -2038,14 +2041,14 @@
Wide Web Consortium, 27 March 2006. This version of the WSDL 2.0 specification is
http://www.w3.org/TR/2006/CR-wsdl20-20060327. 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. (See <a href="http://www.w3.org/TR/2006/CR-wsdl20-20060327/">http://www.w3.org/TR/2006/CR-wsdl20-20060327/</a>.)</dd>
<dt class="label"><a name="WS-Policy"></a>[Web Services Policy Framework] </dt><dd>
- <cite>Web Services Policy 1.5 - Framework</cite>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
- Boubez and P. Yendluri, Editors. World Wide Web Consortium, @@,
+ <cite>Web Services Policy 1.5 - Framework</cite>, A. S. Vedamuthu, D. Orchard, <span class="diff-add">F. Hirsch, </span>M. Hondo,
+ <span class="diff-add">P. Yendluri, </span>T. Boubez and <span class="diff-chg">Ü. Yalçinalp, </span>Editors. World Wide Web Consortium, @@,
@@@@ @@@@. This version of the
Web Services Policy 1.5 - Framework specification is at http://www.w3.org/TR/ws-policy/. 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/. (See <a href="http://www.w3.org/TR/ws-policy/">http://www.w3.org/TR/ws-policy/</a>.)</dd>
<dt class="label"><a name="WS-PolicyAttachment"></a>[Web Services Policy Attachment] </dt><dd>
- <cite>Web Services Policy 1.5 - Attachment</cite>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
- Boubez and P. Yendluri, Editors. World Wide Web Consortium, @@,
+ <cite>Web Services Policy 1.5 - Attachment</cite>, A. S. Vedamuthu, D. Orchard, <span class="diff-add">F. Hirsch, </span>M. Hondo,
+ <span class="diff-add">P. Yendluri, </span>T. Boubez and <span class="diff-chg">Ü. Yalçinalp, </span>Editors. World Wide Web Consortium, @@,
@@@@ @@@@. This version of the
Web Services Policy 1.5 - Attachment specification is at http://www.w3.org/TR/ws-policy-attach. The <a href="http://www.w3.org/TR/ws-policy-attach/">latest version of
Web Services Policy 1.5 - Attachment</a> is available at
@@ -2102,7 +2105,7 @@
<div class="div1">
<h2><a name="change-description"></a>E. Changes in this Version of the Document (Non-Normative)</h2>
- <p>A list of substantive changes since the <span class="diff-add">Working Draft</span><span class="diff-del">previous </span><span class="diff-chg">dated </span><span class="diff-add">18 October, 2006 </span>is below:</p>
+ <p>A list of substantive changes since the <span class="diff-add">Working Draft dated 18</span><span class="diff-del">previous </span><span class="diff-chg">October, </span><span class="diff-add">2006 </span>is below:</p>
<ul>
<li><p><span class="diff-add">Moved
Sections</span><span class="diff-del">Replaced </span><span class="diff-add"><a href="http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/#parts-of-a-policy-assertion">
@@ -2253,6 +2256,16 @@
<span class="diff-add">4 Advanced Concepts II: Policy Assertion Design</span></a> into the Guidelines document.
</td></div>
</tr></div>
+ <div class="diff-add"><tr class="diff-add">
+ <div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">20061127</td></div>
+ <div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">ASV</td></div>
+ <div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Added
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0033.html"><span class="diff-add">Frederick</span></a> and
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0054.html"><span class="diff-add">Umit</span></a> to the list of editors.
+ Editors' action <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/86"><span class="diff-add">86</span></a>.
+ </td></div>
+ </tr></div>
+
</tbody>
</table><br>
</div>
--- NEW FILE: ws-policy-guidelines-diffaction-77.xml ---
<?xml version="1.0" encoding="utf-8"?>
<!-- $Id: ws-policy-guidelines-diffaction-77.xml,v 1.1 2006/11/30 06:16:29 avedamut Exp $ -->
<!DOCTYPE spec PUBLIC "-//W3C//DTD Specification V2.10//EN" "xmlspec.dtd" [
<!ENTITY % entities SYSTEM "entities.dtd" >
%entities;
<!ENTITY status SYSTEM "status-guidelines.xml">
<!ENTITY document.status "Editors' copy $Date: 2006/11/30 06:16:29 $">
<!ENTITY prevloc "">
<!ENTITY hellip "…">
]><spec w3c-doctype="wd" role="editors-copy">
<header>
<title>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</title>
<w3c-designation>ws-policy-guidelines.html</w3c-designation>
<w3c-doctype>Editors' copy $Date: 2006/11/30 06:16:29 $</w3c-doctype>
<pubdate>
<day>@@</day>
<month>@@@@</month>
<year>@@@@</year>
</pubdate>
[...1853 lines suppressed...]
<td rowspan="1" colspan="1" diff="add">Editorial revision (editorial actions
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/84" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">84</phrase></loc> and
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/90" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">90</phrase></loc>) -
includes suggestions from Asir:
<loc href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0129.html" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Part 1</phrase></loc> and
<loc href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0134.html" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Part 2</phrase></loc>.
</td>
</tr>
<tr diff="add">
<td rowspan="1" colspan="1" diff="add">20061129</td>
<td rowspan="1" colspan="1" diff="add">ASV</td>
<td rowspan="1" colspan="1" diff="add">Formatted examples in <specref ref="extending-assertions"></specref>.
</td>
</tr>
</tbody>
</table>
</inform-div1>
</back>
</spec>
--- NEW FILE: ws-policy-guidelines-action-77.xml ---
<?xml version="1.0" encoding="utf-8"?>
<!-- $Id: ws-policy-guidelines-action-77.xml,v 1.1 2006/11/30 06:16:29 avedamut Exp $ -->
<!DOCTYPE spec PUBLIC "-//W3C//DTD Specification V2.10//EN" "xmlspec.dtd" [
<!ENTITY % entities SYSTEM "entities.dtd" >
%entities;
<!ENTITY status SYSTEM "status-guidelines.xml">
<!ENTITY document.status "Editors' copy $Date: 2006/11/30 06:16:29 $">
<!ENTITY prevloc "">
<!ENTITY hellip "…">
]>
<?xml-stylesheet type='text/xsl' href='xmlspec-policy.xsl'?>
<spec w3c-doctype="wd" role="&document.role;">
<header>
<title>&guideline.title;</title>
<w3c-designation>&w3c-designation-guidelines;</w3c-designation>
<w3c-doctype>&document.status;</w3c-doctype>
<pubdate>
<day>&draft.day;</day>
<month>&draft.month;</month>
[...1797 lines suppressed...]
<tr>
<td>20061127</td>
<td>ASV</td>
<td>Updated the list of editors. Added
<loc href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0033.html">Frederick</loc> and
<loc href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0054.html">Umit</loc> to the list of editors.
Editors' action <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/86">86</loc>.
</td>
</tr>
<tr>
<td>20061128</td>
<td>MH</td>
<td>Replaced section in Lifecycle with pointer to the text in the primer: related to action 77
</td>
</tr>
</tbody>
</table>
</inform-div1>
</back>
</spec>
Index: ws-policy-primer-diff20061109.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-primer-diff20061109.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- ws-policy-primer-diff20061109.xml 26 Nov 2006 00:08:41 -0000 1.1
+++ ws-policy-primer-diff20061109.xml 30 Nov 2006 06:16:29 -0000 1.2
@@ -40,16 +40,24 @@
<affiliation>BEA Systems, Inc.</affiliation>
</author>
<author role="editor">
+ <name><phrase diff="add">Frederick Hirsch</phrase></name>
+ <affiliation diff="add"><phrase diff="add">Nokia</phrase></affiliation>
+ </author>
+ <author role="editor" diff="add">
<name>Maryann Hondo</name>
<affiliation>IBM Corporation</affiliation>
</author>
<author role="editor">
+ <name><phrase diff="add">Prasad Yendluri</phrase></name>
+ <affiliation diff="add"><phrase diff="add">webMethods, Inc.</phrase></affiliation>
+ </author>
+ <author role="editor" diff="add">
<name>Toufic Boubez</name>
<affiliation>Layer 7 Technologies</affiliation>
</author>
<author role="editor">
- <name>Prasad Yendluri</name>
- <affiliation>webMethods, Inc.</affiliation>
+ <name><phrase diff="chg">Ümit Yalçinalp</phrase></name>
+ <affiliation><phrase diff="chg">SAP AG.</phrase></affiliation>
</author>
</authlist>
<abstract>
@@ -1789,6 +1797,7 @@
</p></div3>
</div2>
+
</div1>
<div1 id="conclusion">
@@ -1986,14 +1995,14 @@
Wide Web Consortium, 27 March 2006. This version of the WSDL 2.0 specification is
http://www.w3.org/TR/2006/CR-wsdl20-20060327. The <loc href="http://www.w3.org/TR/wsdl20/" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="replace">latest version of WSDL 2.0</loc> is available at http://www.w3.org/TR/wsdl20. </bibl>
<bibl id="WS-Policy" key="Web Services Policy Framework" href="http://www.w3.org/TR/ws-policy/" xlink:actuate="onRequest" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:show="replace" xlink:type="simple">
- <titleref xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="new">Web Services Policy 1.5 - Framework</titleref>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
- Boubez and P. Yendluri, Editors. World Wide Web Consortium, @@,
+ <titleref xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="new">Web Services Policy 1.5 - Framework</titleref>, A. S. Vedamuthu, D. Orchard, <phrase diff="add">F. Hirsch, </phrase>M. Hondo,
+ <phrase diff="add">P. Yendluri, </phrase>T. Boubez and <phrase diff="chg">Ü. Yalçinalp, </phrase>Editors. World Wide Web Consortium, @@,
@@@@ @@@@. This version of the
Web Services Policy 1.5 - Framework specification is at http://www.w3.org/TR/ws-policy/. The <loc href="http://www.w3.org/TR/ws-policy/" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="replace">latest version of
Web Services Policy 1.5 - Framework</loc> is available at http://www.w3.org/TR/ws-policy/. </bibl>
<bibl id="WS-PolicyAttachment" key="Web Services Policy Attachment" href="http://www.w3.org/TR/ws-policy-attach/" xlink:actuate="onRequest" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:show="replace" xlink:type="simple">
- <titleref xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="new">Web Services Policy 1.5 - Attachment</titleref>, A. S. Vedamuthu, D. Orchard, M. Hondo, T.
- Boubez and P. Yendluri, Editors. World Wide Web Consortium, @@,
+ <titleref xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="new">Web Services Policy 1.5 - Attachment</titleref>, A. S. Vedamuthu, D. Orchard, <phrase diff="add">F. Hirsch, </phrase>M. Hondo,
+ <phrase diff="add">P. Yendluri, </phrase>T. Boubez and <phrase diff="chg">Ü. Yalçinalp, </phrase>Editors. World Wide Web Consortium, @@,
@@@@ @@@@. This version of the
Web Services Policy 1.5 - Attachment specification is at http://www.w3.org/TR/ws-policy-attach. The <loc href="http://www.w3.org/TR/ws-policy-attach/" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="replace">latest version of
Web Services Policy 1.5 - Attachment</loc> is available at
@@ -2048,7 +2057,7 @@
</inform-div1>
<inform-div1 id="change-description">
<head>Changes in this Version of the Document</head>
- <p>A list of substantive changes since the <phrase diff="add">Working Draft</phrase><phrase diff="del">previous </phrase><phrase diff="chg">dated </phrase><phrase diff="add">18 October, 2006 </phrase>is below:</p>
+ <p>A list of substantive changes since the <phrase diff="add">Working Draft dated 18</phrase><phrase diff="del">previous </phrase><phrase diff="chg">October, </phrase><phrase diff="add">2006 </phrase>is below:</p>
<ulist>
<item><p><phrase diff="add">Moved
Sections</phrase><phrase diff="del">Replaced </phrase><loc href="http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/#parts-of-a-policy-assertion" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="replace" diff="add">
@@ -2204,6 +2213,16 @@
<phrase diff="add">4 Advanced Concepts II: Policy Assertion Design</phrase></loc> into the Guidelines document.
</td>
</tr>
+ <tr diff="add">
+ <td rowspan="1" colspan="1" diff="add">20061127</td>
+ <td rowspan="1" colspan="1" diff="add">ASV</td>
+ <td rowspan="1" colspan="1" diff="add">Added
+ <loc href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0033.html" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Frederick</phrase></loc> and
+ <loc href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0054.html" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">Umit</phrase></loc> to the list of editors.
+ Editors' action <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/86" xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:actuate="onRequest" xlink:show="replace"><phrase diff="add">86</phrase></loc>.
+ </td>
+ </tr>
+
</tbody>
</table>
</inform-div1>
Index: ws-policy-guidelines-diff20061109.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines-diff20061109.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- ws-policy-guidelines-diff20061109.html 28 Nov 2006 23:47:22 -0000 1.2
+++ ws-policy-guidelines-diff20061109.html 30 Nov 2006 06:16:29 -0000 1.3
@@ -96,31 +96,36 @@
<h2><a name="status">Status of this Document</a></h2><p><strong>This document is an editors' copy that has
no official standing.</strong></p><p></p></div>
<hr><div class="toc">
-<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#introduction">Introduction</a><br>2. <a href="#Assertions">What is an Assertion? Assertion</a><br>3. <a href="#N1019C">Who is involved in authoring Assertions? Assertions</a><br> 3.1 <a href="#roles"> Roles and Responsibilities </a><br> 3.1.1 <a href="#domain-owners"> WS-Policy Authors</a><br> 3.1.2 <a href="#consumers">Consumers</a><br> 3.1.3 <a href="#providers">Providers</a><br>4. <a href="#general-guidelines">General Guidelines for WS-Policy Assertion Authors</a><br> 4.1 <a href="#assertion-target">Assertions and Their Target Use</a><br> 4.2 <a href="#compact-full">Authoring Styles </a><br> 4.3 <a href="#new-guidelines-domains">Considerations when Modeling New AssertionsDomains</a><br> &bsp; 4.3.1 <a href="#minimal-approach">Minimal approach</a><br> 4.3.2 <a href="#QName_and_XML_Information_Set_representation">QName and XML Information Set representation</a><br> 4.3.3 <a href="#self-describing"> Self Describing Messages </a><br> 4.3.4 <a href="#single-domains">Single Domains</a><br> 4.4 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br> 4.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br> 4.4.2 <a href="#nested-assertions">Nested Assertions</a><br> 4.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br> 4.5 <a href="#optional-policy-assertion">Policy Asertions Designating Optional Behaviors</a><br> 4.5.1 <a href="#N10673">Optional behavior in Compact authoring</a><br> 4.5.2 <a href="#N10686">Optional behavior at runtime</a><br> 4.6 <a href="#typing-assertions">Typing Assertions</a><br> 4.7 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>5. <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br> 5.2 <a href="#extending-assertions"> Factors in Extending Assertions within a Domain </a><br> 5.3 <a href="#assertion-evolution">Evolution of Assertions (Versioning and Compatibility)</a><br>6. <a href="#inter-policy">Inter-domain Policy and Composition Issues</a><br>7. <a href="#best-practices-attachment">Applying Best Practices for Policy Attachment</a>br> 7.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br> 7.2 <a href="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br> 7.2.1 <a href="#interaction">Interaction between Subjects</a><br> 7.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>8. <a href="#scenerio">Scenario and a worked example</a><br></p>
+<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#introduction">Introduction</a><br>2. <a href="#Assertions">What is an Assertion? Assertion</a><br>3. <a href="#N101CF">Who is involved in authoring Assertions? Assertions</a><br> 3.1 <a href="#roles"> Roles and Responsibilities </a><br> 3.1.1 <a href="#domain-owners"> WS-Policy Authors</a><br> 3.1.2 <a href="#consumers">Consumers</a><br> 3.1.3 <a href="#providers">Providers</a><br>4. <a href="#general-guidelines">General Guidelines for WS-Policy Assertion Authors</a><br> 4.1 <a href="#assertion-target">Assertions and Their Target Use</a><br> 4.2 <a href="#compact-full">Authoring Styles </a><br> 4.3 <a href="#new-guidelines-domains">Considerations when Modeling New AssertionsDomains</a><br> &bsp; 4.3.1 <a href="#minimal-approach">Minimal approach</a><br> 4.3.2 <a href="#QName_and_XML_Information_Set_representation">QName and XML Information Set representation</a><br> 4.3.3 <a href="#self-describing"> Self Describing Messages </a><br> 4.3.4 <a href="#single-domains">Single Domains</a><br> 4.4 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br> 4.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br> 4.4.2 <a href="#nested-assertions">Nested Assertions</a><br> 4.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br> 4.5 <a href="#optional-policy-assertion">Policy Asertions Designating Optional Behaviors</a><br> 4.5.1 <a href="#N1071B">Optional behavior in Compact authoring</a><br> 4.5.2 <a href="#N10730">Optional behavior at runtime</a><br> 4.6 <a href="#typing-assertions">Typing Assertions</a><br> 4.7 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>5. <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br> 5.2 <a href="#extending-assertions"> Factors in Extending Assertions within a Domain
+ Extensibility affects the policy subjects and attachment semantics.
+
+
+ Evolution of Assertions (Versioning and Compatibility)</a><br>6. <a href="#inter-policy">Inter-domain Policy and Composition Issues</a><br>7. <a href="#best-practices-attachment">Applying Best Practices for Policy Attachment</a><br> 7.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br> 7.2 <a href="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br> 7.2.1 <a href="#interaction">Interaction between Subjects</a><br> 7.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>8. <a href="#scenario">Scenario and a worked example</a><br></p>
<h3><a id="appendix" name="appendix">Appendices</a></h3><p class="toc">A. <a href="#security-considerations">Security Considerations</a><br>B. <a href="#xml-namespaces">XML Namespaces</a><br>C. <a href="#references">References</a><br>D. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>E. <a href="#change-description">Changes in this Version of
the Document</a> (Non-Normative)<br>F. <a href="#change-log">Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log</a> (Non-Normative)<br></p></div><hr><div class="body">
<div class="div1">
<h2><a name="introduction"></a>1. Introduction</h2>
- <p>WS-Policy specification defines a policy to be a collection
- of policy alternatives, where each policy alternative is a
- collection of policy assertions. <span class="diff-add">Policy is a flexible framework to represent
- consistent compinations of behaviors from a variety of domains.
- A policy assertion is a machine readable metadata exxpression that
+ <p><span class="diff-add">The </span>WS-Policy specification defines a policy to be a collection
+ of policy <span class="diff-chg">alternatives with </span>each policy alternative <span class="diff-del">is </span>a
+ collection of policy assertions. <span class="diff-add">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.
</span><em>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</em>
- is a resource primarily for assertion authors that provides
+ is a resource primarily for assertion authors <span class="diff-chg">and </span>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 are XML expressions
that communicate the requirements and capabilities of a web
- service by adhering to the specification, WS-Policy Framework. It
- was recognized that in order to enable interoperability of web
- services, different sets of WS-Policy Assertions needed to be
- defined by different communities based upon the requirements of
+ service by adhering to the specification, WS-Policy Framework. <span class="diff-add">To</span><span class="diff-del">It
+ was recognized that in order to </span>enable interoperability of web
+ <span class="diff-chg">services </span>different sets of WS-Policy Assertions <span class="diff-chg">need </span>to be
+ defined by different communities based upon <span class="diff-chg">domain-specific </span>requirements of
the web service.
@@ -134,7 +139,7 @@
reasoned about in a consistent manner.
</span></p>
<p>The focus of these guidelines is to capture best practices
- and usage patterns for practitioners to follow. It is a
+ and usage patterns for <span class="diff-add">practitioners.</span><span class="diff-del">practitioners to follow. </span>It is a
complementary guide to the Framework and Attachments
specifications and primer. It is intended to provide
non-normative guidelines for:
@@ -178,7 +183,7 @@
Policy XML Namespace.)
</p>
<div class="diff-add"><p class="diff-add"> <span class="diff-add">As a companion document to the primer, this document also follows
- the Socratic style of beginning with a question, and then</span><span class="diff-del">Basic </span><span class="diff-add">answering
+ the Socratic style of beginning with a question,</span><span class="diff-del">Basic </span><span class="diff-add">and then answering
the</span><span class="diff-del">Concepts: </span><span class="diff-add">question.
</span></p></div>
</div>
@@ -188,15 +193,14 @@
<h2><a name="Assertions"></a>2. What is an <span class="diff-add">Assertion? </span><span class="diff-del">Assertion</span></h2>
<p>An assertion is a piece of metadata that describes a
- capability of a specific WS-Policy domain. Sets of assertions
- are typically defined in a dedicated specification that describe
- their semantics, applicability and scoping requirements as well
+ capability <span class="diff-chg">related </span><span class="diff-add">to </span>a specific WS-Policy domain. Sets of <span class="diff-add">domain-specific </span>assertions
+ are typically defined in a dedicated specification that <span class="diff-chg">describes
+ </span>their semantics, applicability and scoping requirements as well
as their data type definition using XML Schema.
</p>
- <p><span class="diff-add">Given that interoperability and automation are the motivations, policy assertions that
- represent, shared and visible behaviors are useful pieces of metadata. Such
- assertions enable tooling and improve interoperability. The key to understanding when to
+ <p><span class="diff-add">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:
@@ -209,23 +213,26 @@
<li>
<p><span class="diff-add">Is the behavior visible?
</span></p>
- <p><span class="diff-add">A visible behavior refers to a requirement that manifests on the wire. Web services
+ <p><span class="diff-add">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 such as messaging, security, reliability and
+ 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 only rely on these wire messages that conform to such formats and protocols
- for interoperability. If an assertion describes a behavior that does not manifest on the
- wire then the assertion is not relevant to an interoperable interaction.
+ requesters rely on wire messages conforming to such formats and protocols
+ to achieve interoperability.
</span></p>
- <p><span class="diff-add">For example, say an assertion describes the privacy notice information of a provider
- and there is an associated regulatory safeguard in place on the provider’s side. Such
+ <p><span class="diff-add">If an assertion describes a behavior that does not manifest on the
+ wire then the assertion is not relevant to an interoperable interaction.
+ 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. Such
assertions may represent business or regulatory level metadata but do not add any value
to interoperability.
</span></p>
- <p><span class="diff-add">If an assertion has no wire- or message-level visible behavior, then the interacting
- participants may require some sort of additional non-repudiation mechanism to indicate
- compliance with the assertion. Introducing an additional non-repudiation mechanism adds
+ <p><span class="diff-add">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.
</span></p>
</li>
@@ -238,9 +245,7 @@
relevant to an interoperable interaction. Non-shared behaviors do not add any value for
tooling or interoperability. An example of a non-shared behavior is the use of logging
or auditing by the provider.
- </span></p>
-
- <p><span class="diff-add">requesters may use the policy intersection to select a compatible policy alternative
+ Requesters may use the policy intersection to select a compatible policy alternative
for a Web service interaction. If an assertion only describes one participant’s behavior
then this assertion will not be present in the other participants’ policy and the policy
intersection will unnecessarily produce false negatives.
@@ -254,8 +259,8 @@
<li>
<p><span class="diff-add">Is there a requirement that a choice must be made for successful interaction?</span></p>
- <p><span class="diff-add">Some behaviors refer to a requirement that providers and requesters must deliberately choose
- to engage in. Examples, of such behaviors are the use of optimization, and reliable messaging.
+ <p><span class="diff-add">Sometimes providers and requesters are required to engage in certain behaviors.
+ The use of optimization and reliable messaging are two examples.
</span></p>
</li>
</ul>
@@ -297,7 +302,7 @@
-<h2><a name="N1019C"></a>3. <span class="diff-chg">Who is involved </span>in <span class="diff-chg">authoring Assertions? </span><span class="diff-del">Assertions</span></h2>
+<h2><a name="N101CF"></a>3. <span class="diff-chg">Who is involved </span>in <span class="diff-chg">authoring Assertions? </span><span class="diff-del">Assertions</span></h2>
<p>In order for the policy framework to enable communities to
express their own domain knowledge, it is necessary to provide basic
@@ -337,19 +342,19 @@
a way that multiple WS-Policy domains can co-exist and
consumers and providers can utilize the framework consistently across domains.
</p>
- <p>In order to take advantage of the WS-Policy Framework, any
- domain author attempting to define new WS-Policy assertions
- must adhere to the MUST's and SHOULD's in the specifications
- and should review the conformance section of the
+ <p><span class="diff-add">When</span><span class="diff-del">In order to take advantage </span><span class="diff-chg">using </span>the WS-Policy Framework, any
+ domain author <span class="diff-add">defining</span><span class="diff-del">attempting to define </span>new WS-Policy assertions
+ must adhere to the MUST's and SHOULD's in the <span class="diff-chg">specification
+ </span>and should review the conformance section of the
<span class="diff-del">specification. </span><span class="diff-add">specification.
</span></p>
<p>WS-Policy Domain authors must also specify how to associate
the assertions they have defined with the policy subjects
- identified by the WS-PolicyAttachment specification
- </p>
+ identified by the WS-PolicyAttachment <span class="diff-add">specification.
+ </span><span class="diff-del">specification</span></p>
<p>An example of a domain specification that
- includes these properties can be seen in the WS-SecurityPolicy
- <span class="diff-chg">pecification </span>[<a href="#WS-SecurityPolicy">[WS-SecurityPolicy]</a>]. The
+ <span class="diff-del">includes these properties </span><span class="diff-chg">follows these practices is </span>the WS-SecurityPolicy
+ specification [<a href="#WS-SecurityPolicy">[WS-SecurityPolicy]</a>]. The
WS-SecurityPolicy authors have defined their scope as follows:
</p>
<p>
@@ -377,8 +382,8 @@
<h4><a name="consumers"></a>3.1.2 Consumers</h4>
<p>A consumer of WS-Policy
Assertions can be any entity that is capable of parsing a
- WS-Policy xml element, and selecting one alternative from the
- policy, that it then uses to govern the creation of a message
+ WS-Policy <span class="diff-chg">XML element </span>and selecting one alternative from the
+ <span class="diff-chg">policy. This </span><span class="diff-add">selected alternative</span><span class="diff-del">it </span><span class="diff-add">is </span>then <span class="diff-chg">used </span>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 models for use with common web service
@@ -387,7 +392,7 @@
References (EPR) [<a href="#WS-Addressing">[WS-Addressing Core]</a>].
</p>
<p>
- In the degenerate case, a human could read the xml and
+ In the degenerate case, a human could read the <span class="diff-chg">XML </span>and
determine if a message could be constructed conformant to the
advertised policy.
</p>
@@ -403,7 +408,7 @@
<h4><a name="providers"></a>3.1.3 Providers</h4>
<p>A provider of WS-Policy Assertions can be any web service implementation that can
- specify its' on-the-wire message behavior as an XML
+ specify <span class="diff-chg">its </span>on-the-wire message behavior as an XML
expression that conforms to the WS-PolicyFramework and
WS-Policy Attachment specifications. The
WS-PolicyAttachment specification has defined a set of
@@ -413,7 +418,7 @@
it may also need to conform to requirements of other policy
specifications it utilizes ( i.e., WS-SecurityPolicy).
</p>
- <p>When deploying services with policies it is uesful for providers to anticipate how
+ <p>When deploying services with policies it is <span class="diff-chg">useful </span>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,
@@ -429,10 +434,10 @@
<h2><a name="general-guidelines"></a>4. General Guidelines for WS-Policy Assertion Authors</h2>
<div class="diff-add"><p class="diff-add"> <span class="diff-add">As 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 desgin. WS-Policy
- relies on the Qname of a policy assertion being an XML element but allows authors to optionally
+ 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 authors to optionally
provide additional semantics through nesting assertions, or specifying assertion parameters.
- This section covers several aspects of assertion design and provides somes answers to the following questions:</span></p></div>
+ This section covers several aspects of assertion design and provides some answers to the following questions:</span></p></div>
<div class="diff-add"><ul>
<li>
<p><span class="diff-add">What is the intended use of the policy assertion?</span></p>
@@ -441,7 +446,7 @@
<p><span class="diff-add">Which authoring style will be used?</span></p>
</li>
<li>
- <p><span class="diff-add">Is this a new policy domain? does it need to compose with other domains?</span></p>
+ <p><span class="diff-add">Is this a new policy domain? Does it need to compose with other domains?</span></p>
</li>
<li>
<p><span class="diff-add">How complex are the assertions?</span></p>
@@ -483,7 +488,8 @@
stand alone client applications to "active" web service
requestors that are capable of modifying their own configurations dynamically.
</p>
- <p> Once the range of policy subjects are identified, there are choices for ways of
+ <p> Once the range of policy subjects
+ <span class="diff-del">are </span><span class="diff-add">is </span>identified, there are choices for ways of
attaching multiple instances of a simple policy
assertion to multiple subjects. One way is to utilize
the referencing mechanism that is present in the
@@ -491,7 +497,7 @@
in different policies (e.g. with different
alternatives) via reference, a policy assertion may be
associated with different alternatives and subjects. A
- <span class="diff-chg">eferencing </span>mechanism is very useful in a tooling
+ referencing mechanism is very useful in a tooling
environment; when creating a domain specific
attachment in multiple WSDL files or Endpoint
References in which the same set of policies are expected to be applied.
@@ -499,9 +505,9 @@
<p><span class="diff-chg">Best practice: </span>WS-Policy <span class="diff-del">domain </span>authors should <span class="diff-chg">include </span>the following
<span class="diff-add">items
</span><span class="diff-del">factors when </span><span class="diff-chg">in </span>the <span class="diff-add">dialect</span><span class="diff-del">set of domain assertions as it
- may make sense to factor out some assertions that can be
- used by </span><span class="diff-add">specification:
- </span><span class="diff-del">multiple subjects:
+ may make sense to factor out some assertions that can </span><span class="diff-add">specification:
+ </span><span class="diff-del">be
+ used by multiple subjects:
</span></p>
<ul>
<li>
@@ -549,7 +555,7 @@
<h3><a name="compact-full"></a>4.2 Authoring Styles </h3>
- <p> WS-Policy supports 2 different authoring styles. A compact form is one in which an expression consists of three
+ <p> WS-Policy supports <span class="diff-chg">two </span>different authoring styles. 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.
</p>
@@ -617,13 +623,13 @@
in a policy, the normal form may express the choices more explicitly.
On the other hand, the compact form is more
readable for humans when an assertion is marked as optional
- using the <code>@optional</code> attribute as our example illustrates above.
+ using the <code><span class="diff-chg">wsp:optional</span></code> attribute as our example illustrates above.
</p>
- <p><span class="diff-add">Best practice: use the authoring style
+ <p><span class="diff-add">Best practice: use the authoring style most appropriate
- </span><span class="diff-del">Guidelines </span><span class="diff-add">most appropriate </span>for <span class="diff-chg">the target </span><span class="diff-add">audience </span></p>
+ </span><span class="diff-del">Guidelines </span>for <span class="diff-chg">the target </span><span class="diff-add">audience </span></p>
</div></div><div class="diff-del"><p class="diff-del">Assertions
</p></div><div class="diff-chg"><div class="div2">
@@ -634,11 +640,11 @@
framework implementation that has followed </span>the
<span class="diff-del">framework. </span><span class="diff-add">specifications.
</span></p>
- <div class="diff-add"><p class="diff-add"><span class="diff-add">The</span><span class="diff-del">Some </span><span class="diff-chg">examples given in </span><span class="diff-add">this document reference WS-Policy</span><span class="diff-del">infrastructure
- efforts </span>like WS-SecurityPolicy and WS-RM Policy.
+ <div class="diff-add"><p class="diff-add"><span class="diff-add">The</span><span class="diff-del">Some </span><span class="diff-chg">examples given in </span><span class="diff-add">this document reference</span><span class="diff-del">infrastructure
+ efforts </span><span class="diff-add">WS-Policy </span>like WS-SecurityPolicy and WS-RM Policy.
<span class="diff-add">These </span><span class="diff-chg">policy </span><span class="diff-add">expressions</span><span class="diff-del">also
- anticipate </span><span class="diff-add">represent web services message exchange requirements, but policy</span><span class="diff-del">that </span><span class="diff-add">authoring can
- be done by </span>individual <span class="diff-add">groups that wish to represent </span>web services <span class="diff-add">application requirements</span><span class="diff-del">applications </span>and
+ anticipate </span><span class="diff-add">represent web services message exchange requirements, but policy authoring can
+ be done</span><span class="diff-del">that </span><span class="diff-add">by </span>individual <span class="diff-add">groups that wish to represent </span>web services <span class="diff-add">application requirements</span><span class="diff-del">applications </span>and
deployments <span class="diff-chg">that </span>wish to reuse the WS-Policy framework in
order to enable dynamic negotiation of business requirements
and capabilities at runtime.
@@ -651,19 +657,19 @@
behavior. Sets of assertions can by grouped by an operator "all". This indicates that there is a relationship between
the assertions and they now constitute a policy alternative.
</p>
- <p><span class="diff-add">If grouping is utilized,</span><span class="diff-del">Choices </span><span class="diff-add">choices </span>between alternatives can be indicated by
+ <p><span class="diff-add">If grouping is utilized, choices</span><span class="diff-del">Choices </span>between alternatives can be indicated by
an "exactly one" operator. This basic set of operators allows
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
- <span class="diff-chg">eflects </span>the options of the domain if the domain has a lot of
+ 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.
</p>
<p>New authors are encouraged to look at <a href="#WS-RM-Policy">[Web Services Reliable Messaging Policy]</a> to see an example of a
- relatively simple domain that has defined 3 assertions. Domain authors are encouraged to look at <a href="#WS-SecurityPolicy">[WS-SecurityPolicy]</a> to see an example of a complex domain that has been decomposed into a set of policy expressions.
+ relatively simple domain that has defined <span class="diff-chg">three </span>assertions. Domain authors are encouraged to look at <a href="#WS-SecurityPolicy">[WS-SecurityPolicy]</a> to see an example of a complex domain that has been decomposed into a set of policy expressions.
</p>
<p><span class="diff-add">How big should an assertion be? How many assertion parameters should the assertion
enumerate? How many dependent behaviors should the assertion enumerate? It is always
@@ -671,7 +677,7 @@
design work progresses, you may add more parameters or nested policy assertions to meet
your interoperability needs.
</span></p>
- <p><span class="diff-add">Best practice: start with a simple working assertion that allows extensibility.
+ <p><span class="diff-add">Best practice: Start with a simple working assertion that allows extensibility.
</span></p>
</div></div>
<div class="diff-add"><div class="div3">
@@ -688,7 +694,7 @@
document). If the assertion has a nested policy expression then the assertion XML
outline can enumerate the nested assertions that are allowed.
</span></p>
- <p><span class="diff-add">Best practice: use a unique QName to identify the behavior and provide an XML outline
+ <p><span class="diff-add">Best practice: Use a unique QName to identify the behavior and provide an XML outline
(plus an XML schema document) to specify the syntax of an assertion.
</span></p>
</div></div>
@@ -738,9 +744,9 @@
<p><span class="diff-add">Another approach is to use of the assertion to selectively apply to subjects. For example, a
dedicated endpoint may be allocated to ensure the engagement of a
behavior that is expressed by a policy assertion. This approach
- can be considered when messages can not be self describing.
+ can be considered when messages cannot be self describing.
</span></p>
- <p><span class="diff-add">Best practice:Policy assertions should not be used to express the semantics of a message.
+ <p><span class="diff-add">Best practice: Policy assertions should not be used to express the semantics of a message.
</span></p>
</div></div>
<div class="diff-add"><div class="div3">
@@ -765,7 +771,7 @@
</p>
<p>The model advocated for new
assertion development is a cooperative marketplace
- [some might say its an "opt-in" model]. The providers
+ [some might say <span class="diff-chg">it </span><span class="diff-add">is </span>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.
@@ -886,18 +892,18 @@
</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>
+ 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
+ <span class="diff-chg">security, </span>a policy-aware client that recognizes this policy
assertion can engage transport-level security and its
- dependent behaviors automatically. That is, the complexity of
+ dependent behaviors automatically. <span class="diff-chg">This means </span>the complexity of
security usage is absorbed by a policy-aware client and hidden
- from these Web service developers.
+ from <span class="diff-del">these </span>Web service <span class="diff-add">application </span>developers.
</p>
</div>
@@ -905,7 +911,7 @@
<h4><a name="which-one-to-use"></a>4.4.3 Considerations for choosing parameters vs nesting</h4>
<p>The main consideration for selecting parameters or nesting
- of assertions, is that <em>the framework intersection
+ of <span class="diff-chg">assertions </span>is that <em>the framework intersection
algorithm processes nested alternatives, but does not consider
parameters in its algorithm</em>.
</p>
@@ -938,39 +944,47 @@
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 </span><span class="diff-chg">following design questions below </span>can <span class="diff-add">help
- you</span><span class="diff-del">be
+ </span><span class="diff-del">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 </span>to <span class="diff-add">determine</span><span class="diff-del">understand a </span><span class="diff-chg">when to </span><span class="diff-add">use</span><span class="diff-del">not
available, </span><span class="diff-chg">nested policy </span><span class="diff-add">expressions:</span><span class="diff-del">suffer.
</span></p>
- <p><span class="diff-chg">Are </span><span class="diff-add">these</span><span class="diff-del">assertions should not be
+ <div class="diff-add"><ul>
+ <li>
+
+ <p><span class="diff-add">Are</span><span class="diff-del">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
+ the message, or be made available by some other means (e.g., </span><span class="diff-add">these</span><span class="diff-del">being
referenced by </span><span class="diff-chg">assertions designed for </span>the <span class="diff-add">same</span><span class="diff-del">message) instead of being communicated as a
</span>policy <span class="diff-chg">subject? </span></p>
- <p><span class="diff-add">Do</span><span class="diff-del">For example, if </span><span class="diff-add">these</span><span class="diff-del">the details of </span><span class="diff-add">assertions</span><span class="diff-del">a
+ </li>
+ <li>
+
+ <p><span class="diff-add">Do</span><span class="diff-del">For example, </span><span class="diff-add">these</span><span class="diff-del">if the details of </span><span class="diff-add">assertions</span><span class="diff-del">a
message's </span><span class="diff-chg">represent dependent </span><span class="diff-add">behaviors?</span></p>
+ </li>
+ </ul></div>
<div class="diff-add"><p class="diff-add"><span class="diff-add">If</span><span class="diff-del">e.g., </span>the <span class="diff-add">answers</span><span class="diff-del">cipher used, etc) </span>are <span class="diff-add">yes</span><span class="diff-del">expressed
in policy that isn't attached </span>to <span class="diff-add">both</span><span class="diff-del">the message, </span><span class="diff-chg">of these </span><span class="diff-add">questions</span><span class="diff-del">possible
to </span><span class="diff-chg">then leveraging nested </span><span class="diff-add">policy
expressions</span><span class="diff-del">This </span>is <span class="diff-chg">something to consider. Keep </span>in
- <span class="diff-del">policy, what ciphers </span><span class="diff-add">mind</span><span class="diff-del">(and so forth) are supported </span><span class="diff-chg">that </span>a <span class="diff-add">nested</span><span class="diff-del">particular
+ <span class="diff-del">policy, what ciphers (and so </span><span class="diff-add">mind</span><span class="diff-del">forth) are </span><span class="diff-add">that</span><span class="diff-del">supported by </span>a <span class="diff-add">nested</span><span class="diff-del">particular
endpoint, or those </span><span class="diff-chg">policy expression participates </span>in
<span class="diff-chg">the policy intersection </span><span class="diff-add">algorithm.</span><span class="diff-del">the
latter </span><span class="diff-chg">If a requester </span>uses <span class="diff-chg">policy intersection to </span><span class="diff-add">select</span><span class="diff-del">framework.
As </span>a
- <span class="diff-add">compatible </span><span class="diff-del">result, the assertion </span><span class="diff-add">policy</span><span class="diff-del">authors
- should take into </span><span class="diff-chg">alternative then </span>the <span class="diff-del">following important concepts
+ <span class="diff-add">compatible </span><span class="diff-del">result, the assertion authors
+ should </span><span class="diff-add">policy</span><span class="diff-del">take into </span><span class="diff-chg">alternative then </span>the <span class="diff-del">following important concepts
when designing </span>assertions <span class="diff-add">in</span><span class="diff-del">and documenting the semantics of the
assertion types. </span><span class="diff-chg">a nested policy expression play </span>a
<span class="diff-add">first
</span><span class="diff-del">runtime behavior. Secondly, an assertion </span><span class="diff-add">class</span><span class="diff-del">should
also </span><span class="diff-chg">role in </span>the <span class="diff-add">outcome.</span><span class="diff-del">assertion type can be inferred or indicated
from a message at runtime. If </span><span class="diff-chg">There </span>is <span class="diff-add">one</span><span class="diff-del">a need for </span><span class="diff-chg">caveat </span><span class="diff-del">behavior
- </span>to <span class="diff-add">watch</span><span class="diff-del">be represented in a persistent way or </span><span class="diff-chg">out for: policy </span><span class="diff-add">assertions
+ </span>to <span class="diff-add">watch</span><span class="diff-del">be represented in a persistent way </span><span class="diff-add">out</span><span class="diff-del">or if </span><span class="diff-chg">for: policy </span><span class="diff-add">assertions
with</span><span class="diff-del">a </span><span class="diff-chg">deeply </span><span class="diff-add">nested</span><span class="diff-del">for
additional </span><span class="diff-chg">policy can greatly increase the complexity of </span>a <span class="diff-add">policy</span><span class="diff-del">message to be
persisted, </span><span class="diff-chg">and </span>should be
@@ -1009,10 +1023,10 @@
<h3><a name="optional-policy-assertion"></a>4.5 <span class="diff-del">Policy Assertions </span>Designating Optional Behaviors</h3>
<div class="diff-add"><div class="div3">
-<h4><a name="N10673"></a>4.5.1 <span class="diff-add">Optional behavior in Compact authoring</span></h4>
+<h4><a name="N1071B"></a>4.5.1 <span class="diff-add">Optional behavior in Compact authoring</span></h4>
<p>Optional behaviors represent behaviors which may be engaged by a consumer. When using the
compact authoring form for assertions, behaviors are marked by
- using <code>wsp:optional</code> attribute that has a value,
+ using <code><span class="diff-chg">wsp:Optional</span></code> attribute that has a value,
"true". During the process of normalization, the runtime
behavior is indicated by two policy alternatives, one with and
one without <span class="diff-del">containing </span>the assertion. In a consumer/provider
@@ -1024,7 +1038,7 @@
</div></div>
<div class="diff-add"><div class="div3">
-<h4><a name="N10686"></a>4.5.2 <span class="diff-add">Optional behavior at runtime</span></h4>
+<h4><a name="N10730"></a>4.5.2 <span class="diff-add">Optional behavior at runtime</span></h4>
<p>The <a href="#WS-Policy-Primer">[Web Services Policy Primer]</a> document contains an
@@ -1040,7 +1054,7 @@
<p>The semantics of this assertion declare that the behavior
is reflected in messages: they use an optimized wire format
(MIME Multipart/Related serialization). Note that in order for
- an optional behaviors to be engaged, the wire message that
+ an optional <span class="diff-chg">behavior </span>to be engaged, the wire message that
would utilize the specific assertion must be self
describing. For example, an inbound message to a web service
that asserts MTOM, must evaluate, the protocol format of the
@@ -1112,12 +1126,13 @@
when optional behaviors are specified for message
exchanges within a request response for response messages,
using message policy subject. Leaving the semantics
- undescribed may result in providers making assumptions
+ <span class="diff-add">not specified
+ </span><span class="diff-del">undescribed </span><span class="diff-add">or incompletely specified </span>may result in providers making assumptions
(i.e. if the incoming message utilized the optimization,
the response will be returned utilizing the MTOM
serialization). Similarly, if engagement of a behavior is
only specified for an outbound message, the policy
- assertion authors should consider to describe the
+ assertion authors should consider <span class="diff-add">describing </span><span class="diff-del">to describe </span>the
semantics if the incoming messages also utilized the
behavior. This is especially important if the assertion is
applicable to more than one specific policy subject. One
@@ -1169,7 +1184,7 @@
if an assertion is specific to a policy attachment
mechanism. An example could be identifying whether the
assertion expressed is associated with behaviors
- (endpoints) or artifacts ( messages) and then constraining
+ (endpoints) or artifacts <span class="diff-add">(messages)</span><span class="diff-del">( messages) </span>and then constraining
the use of an assertion to one of these subjects.
</p>
<p>Thus our example encryption assertion would have a
@@ -1181,16 +1196,16 @@
the definition of other domain expressions to be policy
subjects. More of this topic is covered in the <a href="#WS-Policy-Primer">[Web Services Policy Primer]</a>
</p>
-
- <p><span class="diff-add">Best Practice- To avoid confusion, assertion definitions should be
+ <div class="diff-add"><p class="diff-add"><span class="diff-add">Best Practice- To avoid confusion, assertion definitions should be
precise about their semantics and include information that
restricts their set of permissible policy subjects
- appropriately and indicates which Qnames are associated with
- which subjects.</span><span class="diff-del">EXAMPLE</span></p>
+ appropriately and indicates which QNames are associated with
+ which subjects.</span></p></div>
<div class="diff-add"><ol>
<li>
- <p><span class="diff-add">Description must clearly and completely specify the syntax (plus an XML Schema
- document) and semantics of a policy assertion.</span></p>
+
+ <p><span class="diff-add">Description must clearly and completely specify the syntax (plus an XML Schema
+ document) and semantics of a policy assertion.</span><span class="diff-del">EXAMPLE</span></p>
</li>
<li>
<p><span class="diff-add">If there is a nested policy expression, description must declare it and enumerate the
@@ -1247,10 +1262,12 @@
the domain authors chose to support certain capabilities at
the endpoint level. This resulted in the finer granularity of
the assertion to apply at the message policy subject, but the
- assertion semantics also indicates that the if the senders
- choose to engage RM semantics (although not specified via
- attachment in WSDL at incoming messages), the providers will
- honor the engagement of RM. This is illustrative of how the
+ assertion semantics also indicates that the if
+ <span class="diff-add">a </span><span class="diff-chg">sender </span><span class="diff-add">chose</span><span class="diff-del">senders
+ choose </span>to engage RM
+ semantics (although not specified via attachment in WSDL at incoming
+ messages), the providers will honor the engagement of RM.
+ This is illustrative of how the
assertion author can specify additional constraints and
assumptions for attachment and engagement of behavior.
</p>
@@ -1373,15 +1390,12 @@
-<h3><a name="extending-assertions"></a>5.2 Factors in Extending Assertions within a Domain </h3>
- <p> Extensibility affects the policy subjects and attachment semantics. </p>
- </div>
- <div class="div2">
+<h3><a name="extending-assertions"></a>5.2 <span class="diff-del">Factors in Extending Assertions within a Domain
+ Extensibility affects the policy subjects and attachment semantics.
-
-<h3><a name="assertion-evolution"></a>5.3 Evolution of Assertions (Versioning and Compatibility)</h3>
- <p>4.4.7. Over time, there may be multiple equivalent behaviors emerging in the Web
+ </span>Evolution of Assertions (Versioning and Compatibility)</h3>
+ <p><span class="diff-del">4.4.7. </span>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
[<a href="#WS-Addressing">[WS-Addressing Core]</a>]. These equivalent behaviors
@@ -1390,16 +1404,24 @@
policy expression in the example below requires the use of
WSS: SOAP Message Security 1.0. </p>
<div class="exampleOuter">
- <p class="exampleHead" style="text-align: left"><i><span>Example 5-1. </span>Example 4-2. Message-level Security and WSS: SOAP Message Security 1.0 </i></p>
- <p>ADD THE EXAMPLE HERE </p>
- </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 class="exampleHead" style="text-align: left"><i><span>Example 5-2. </span>Example 4-3. Message-level Security and WSS: SOAP Message Security 1.1</i></p>
- <p>ADD THE EXAMPLE HERE </p>
- </div>
- <p>Best practice: use independent assertions for modeling multiple equivalent behaviors. </p>
+ <p class="exampleHead" style="text-align: left"><i><span>Example 5-1. </span><span class="diff-del">Example 4-2. </span>Message-level Security and WSS: SOAP Message Security 1.0 </i></p>
+<div class="exampleInner"><pre><Policy>
+ <sp:Wss10>…</sp:Wss10>
+</Policy></pre></div>
+ <span class="diff-del">ADD THE EXAMPLE HERE
+ </span></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 class="exampleHead" style="text-align: left"><i><span>Example 5-2. </span><span class="diff-del">Example 4-3. </span>Message-level Security and WSS: SOAP Message Security 1.1</i></p>
+<div class="exampleInner"><pre><Policy>
+ <sp:Wss11>…</sp:Wss11>
+</Policy></pre></div>
+ <span class="diff-del">ADD THE EXAMPLE HERE
+ </span></div>
+ <p>Best practice: use independent assertions for modeling multiple equivalent
+ behaviors. </p>
</div>
@@ -1414,8 +1436,8 @@
modeling protocol assertions may appear to be an independent behavior,
protocol assertions and security assertions affect transport
bindings and their interactions must be considered. For
- example, utilization of WS-Security Policy with other
- protocols affect transport binding and would result in nested
+ <span class="diff-chg">example </span>utilization of WS-Security Policy with other
+ protocols <span class="diff-chg">affects </span>transport <span class="diff-chg">bindings </span>and would result in nested
policy assertions when additional protocols are composed with
<a href="#WS-Security2004">[WS-Security 2004]</a>. Thus, domain authors should
be aware of the compositional semantics with other related
@@ -1467,18 +1489,18 @@
mechanisms should make it possible to clearly identify the
source of a poly assertion both for debugging and for
verification. This could take several forms: it could be
- assumed ( in WSDL, the source of the assertion is the same
- as the WSDL provider) or it could be proven ( using
- <a href="#WS-Trust">[WS-Trust]</a>). </p>
+ assumed <span class="diff-add">(in</span><span class="diff-del">( in </span>WSDL, the source of the assertion is the same
+ as the WSDL provider) or it could be proven <span class="diff-add">(using</span><span class="diff-del">( using
+ </span><a href="#WS-Trust">[WS-Trust]</a>). </p>
</div>
</div>
- <div class="div1">
+ <div class="diff-chg"><div class="div1">
-<h2><a name="scenerio"></a>8. Scenario and a worked example</h2>
+<h2><a name="scenario"></a>8. Scenario and a worked example</h2>
<p>To illustrate the topics explored in this document, we
include an example of a web service and how a fictitious company
might utilize the WS-Policy Framework to enable Web Service
- interoperability. CompanyA has determined to utilize WS-Security,
+ interoperability. <span class="diff-add">Company A</span><span class="diff-del">CompanyA </span>has determined to utilize WS-Security,
WS-Addressing and WS-Reliable Messaging in all its new web
service offerings and has instructed its developers to use the
policy assertions defined by the following documents: </p>
@@ -1493,11 +1515,11 @@
<p>Web Services Addressing WSDL Binding</p>
</li>
</ul>
- <p>The application developers at CompanyA are instructed to
- review the current web services at CompanyA and propose a plan
+ <p>The application developers at <span class="diff-add">Company A</span><span class="diff-del">CompanyA </span>are instructed to
+ review the current web services at <span class="diff-chg">Company </span><span class="diff-add">A </span>and propose a plan
for adding policy assertions. </p>
<p>The application developers collect information about web
- services within CompanyA and determine that all of the web
+ services within <span class="diff-add">Company A</span><span class="diff-del">CompanyA </span>and determine that all of the web
services already have a WSDL 1.1 description. The developers
have determined that Company A's web services fall into two
types of web services. There are those that fall into the
@@ -1511,7 +1533,7 @@
or message exchange. </p>
<p>Service A is a WSDL 1.1 conformant web service and requires
the use of transport-level security for protecting messages as
- well as including addressing headers. Employees of CompanyA have
+ well as including addressing headers. Employees of <span class="diff-add">Company A</span><span class="diff-del">CompanyA </span>have
already incorporated <code>wss:Security</code> headers into their
messages. </p>
<div class="exampleOuter">
@@ -1532,7 +1554,7 @@
</div>
<p>The SOAP message in the example above includes security
timestamps that express creation and expiration times of this
- message. CompanyA requires the use of these security timestamps
+ message. <span class="diff-chg">Company </span><span class="diff-add">A </span>requires the use of these security timestamps
and transport-level security, such as HTTPS for protecting
messages. </p>
<p>The example below illustrates a policy expression that
@@ -1550,7 +1572,7 @@
<p>The <code>sp:TransportBinding</code> element is a policy assertion. The
assertion identifies the use of transport-level-security - such
as HTTPS for protecting messages at the transport
- level. CompanyA's policy aware clients can now recognize this
+ level. <span class="diff-add">Company A's</span><span class="diff-del">CompanyA's </span>policy aware clients can now recognize this
policy assertion and if they support it, engage in transport
level security for protecting messages and providing security
timestamps in SOAP envelopes for any WSDL with this policy
@@ -1563,25 +1585,25 @@
alternatives rather than forcing a single client
configuration. </p>
<p>The developers read the WS-Policy specification and noted that
- there were 3 ways to express combinations of behaviors. The three
- policy operators, ( Policy, All and ExactlyOne) were considered
+ there were <span class="diff-chg">three </span>ways to express combinations of behaviors. The three
+ policy operators, <span class="diff-add">(Policy,</span><span class="diff-del">( Policy, </span>All and ExactlyOne) were considered
and the result was the creation of two policy elements. </p>
<p>The first policy is shown in Figure
<em>CompanyA-ProfileA</em> and it is the policy that is used
- by many web services at Company A that rely on https to provide
+ by many web services at Company A that rely on <span class="diff-chg">HTTPS </span>to provide
transport level protection of messages. </p>
<p>The second policy is shown in Figure
<em>CompanyA-ProfileB</em> and it offers requestors of a
service the ability to provide additional integrity protection by
including WS-Security Headers to protect the message content
after it is processed by the transport. The additional security
- processing is not required by all CompanyA web services. </p>
- <div class="exampleOuter"> <p class="exampleHead" style="text-align: left"><i><span>Example 8-3. </span>CompanyA-ProfileB ( not expanded)</i></p> <div class="exampleInner"><pre> <Policy wsu:Id="CompanyA-ProfileB">
+ processing is not required by all <span class="diff-add">Company A</span><span class="diff-del">CompanyA </span>web services. </p>
+ <div class="exampleOuter"> <p class="exampleHead" style="text-align: left"><i><span>Example 8-3. </span>CompanyA-ProfileB <span class="diff-add">(not</span><span class="diff-del">( not </span>expanded)</i></p> <div class="exampleInner"><pre> <Policy wsu:Id="CompanyA-ProfileB">
<wsa:UsingAddressing /> <ExactlyOne>
<sp:TransportBinding></sp:TransportBinding>
<sp:AsymmetricBinding></sp:AssymetricBinding>
</ExactlyOne> </Policy> </pre></div> </div>
- <p>We have shown above that CompanyA offered a
+ <p>We have shown above that <span class="diff-chg">Company </span><span class="diff-add">A </span>offered a
second profile that included two security options. The details of
the Bindings, requires a more detailed exploration of some of the
other features of the WS-Policy Framework. </p>
@@ -1594,7 +1616,7 @@
an <code>sp:TransportBinding</code> assertion, just indicating the use of
transport-level security for protecting messages is not
sufficient. For a consumer of a web service provided by a company,
- like CompanyA, to successfully interact, the consumer must also
+ like <span class="diff-add">Company A,</span><span class="diff-del">CompanyA, </span>to successfully interact, the consumer must also
know what transport token, what algorithm suite, etc. is
required. The <code>sp:TransportBinding</code> assertion, can (and has)
represent (ed) these dependent behaviors as "nested" policy
@@ -1635,24 +1657,24 @@
indicates the use of a specific type of token, in this case an
HttpsToken. </p>
<p>It should be noted that each policy has an Identifier. In the
- case of the default policy expression, CompanyA has decided that
+ case of the default policy expression, <span class="diff-add">Company A</span><span class="diff-del">CompanyA </span>has decided that
this policy expression should be broadly available via a URI.
There are advantages and disadvantages to using each type of
identifier. For URI's there is the issue of maintaining the
- policy expression when it may no longer be used ( CompanyA gets
- bought by CompanyB and starts using the policies of Company B,
+ policy expression when it may no longer be used <span class="diff-chg">(Company A </span>gets
+ bought by <span class="diff-add">Company B</span><span class="diff-del">CompanyB </span>and starts using the policies of Company B,
but some "old" consumers may still try to reference the
URI). </p>
<p> For the second type of web services, which may be used only
- by certain of CompanyA's business partners, the id is an XML ID.
+ by certain of <span class="diff-add">Company A's</span><span class="diff-del">CompanyA's </span>business partners, the id is an XML ID.
The relative URI for referencing this within the same WSDL
document is #CompanyA-ProfileB. This can be useful for company's
when the policy expressions are agreed to between partners but
may be changed as the business agreements change. But the
disadvantage is that the policy expression must be included in
each WSDL document. </p>
- <p>Since CompanyA has decided to use well known policy
- expressions that are themselves part of a specification, they
+ <p>Since <span class="diff-chg">Company </span><span class="diff-add">A </span>has decided to use well known policy
+ expressions that are <span class="diff-del">themselves </span>part of a specification, they
adhere to the guidance given in the WS-SecurityPolicy
specification and attach the policies to the web service endpoint
policy subject as recommended by the WS-SecurityPolicy
@@ -1668,7 +1690,7 @@
</wsdl:binding> </pre></div>
</div>
<p>The partner specified policy is included in the beginning of
- the wsdl 1.1document and referenced by the binding for the service
+ the <span class="diff-add">WSDL 1.1</span><span class="diff-del">wsdl </span><span class="diff-chg">document </span>and referenced by the binding for the service
as in the example below.</p>
<div class="exampleOuter">
<p class="exampleHead" style="text-align: left"><i><span>Example 8-6. </span></i></p>
@@ -1712,7 +1734,7 @@
to consider policy subjects.</p>
<p>The policy framework only defines an algorithm for calculating
effective policies for WSDL 1.1 based subjects. </p>
- </div>
+ </div></div>
</div>
<div class="back">
<div class="div1">
@@ -2038,7 +2060,28 @@
<div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">MH</td></div>
<div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Replaced section in Lifecycle with pointer to the text in the primer: related to action 77
</td></div>
- </tr></div>
+ </tr></div>
+ <div class="diff-add"><tr class="diff-add">
+ <div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">20061129</td></div>
+ <div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">FH</td></div>
+ <div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Editorial revision (editorial actions
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/84"><span class="diff-add">84</span></a> and
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/90"><span class="diff-add">90</span></a>) -
+ includes suggestions from Asir:
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0129.html"><span class="diff-add">Part 1</span></a> and
+ <a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2006Nov/0134.html"><span class="diff-add">Part 2</span></a>.
+ </td></div>
+ </tr></div>
+ <div class="diff-add"><tr class="diff-add">
+ <div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">20061129</td></div>
+ <div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">ASV</td></div>
+ <div class="diff-add"><td rowspan="1" colspan="1" class="diff-add">Formatted examples in <a href="#extending-assertions"><b>5.2 Factors in Extending Assertions within a Domain
+ Extensibility affects the policy subjects and attachment semantics.
+
+
+ Evolution of Assertions (Versioning and Compatibility)</b></a>.
+ </td></div>
+ </tr></div>
</tbody>
</table><br>
Received on Thursday, 30 November 2006 06:16:51 UTC