- From: Asir Vedamuthu via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 29 Oct 2007 17:55:33 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv28099
Modified Files:
ws-policy-guidelines-diff20070928.xml
ws-policy-guidelines-diff20070928.html
Log Message:
Regenerating the diff
Index: ws-policy-guidelines-diff20070928.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines-diff20070928.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- ws-policy-guidelines-diff20070928.html 27 Oct 2007 01:42:46 -0000 1.3
+++ ws-policy-guidelines-diff20070928.html 29 Oct 2007 17:55:31 -0000 1.4
@@ -146,10 +146,10 @@
5.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br>
5.4.2 <a href="#nested-assertions">Nested Assertions</a><br>
5.5 <a href="#Ignorable">Designating Ignorable Behavior</a><br>
- 5.5.1 <a href="#d4e946">Ignorable behavior in authoring</a><br>
- 5.5.2 <a href="#d4e959">Ignorable behavior at runtime</a><br>
+ 5.5.1 <a href="#d4e944">Ignorable behavior in authoring</a><br>
+ 5.5.2 <a href="#d4e957">Ignorable behavior at runtime</a><br>
5.6 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
- 5.6.1 <a href="#d4e974">Optional behavior at runtime</a><br>
+ 5.6.1 <a href="#d4e972">Optional behavior at runtime</a><br>
5.7 <a href="#levels-of-abstraction">Considerations for Policy Attachment</a><br>
5.7.1 <a href="#general-attachment-guidelines">Generalimportant Guidelines</a><br>
5.7.2 <a href="#wsdl-attachment-guidelines">Considerations for Policy Attachment in WSDL</a><br>
@@ -553,7 +553,7 @@
understand how policy expressions are used by a
framework implementation that has followed the specifications.
</p><p>The examples given in this document <span class="diff-add"><span>are
- based</span></span><span class="diff-del"><span>reference </span></span><span class="diff-chg"><span>on </span></span><span class="diff-add"><span>existing assertions such</span></span><span class="diff-del"><span>like </span></span><span class="diff-add"><span>as </span></span>WS-SecurityPolicy and WS-RM Policy.
+ based</span></span><span class="diff-del"><span>reference </span></span><span class="diff-chg"><span>on </span></span><span class="diff-add"><span>existing assertions such as</span></span><span class="diff-del"><span>like </span></span>WS-SecurityPolicy and WS-RM Policy.
These policy expressions represent web services message exchange requirements, but policy authoring can
be done by individual groups that wish to represent web services application requirements and
deployments that wish to reuse the WS-Policy framework in
@@ -936,16 +936,16 @@
certificate will not be able to use this provider solely on the basis
of intersection algorithm alone.</p></div></div><div class="div2">
<h3><a name="Ignorable" id="Ignorable"></a>5.5 Designating Ignorable Behavior</h3><div class="div3">
-<h4><a name="d4e946" id="d4e946"></a>5.5.1 Ignorable behavior in authoring</h4><p>
+<h4><a name="d4e944" id="d4e944"></a>5.5.1 Ignorable behavior in authoring</h4><p>
The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict). The Framework also defines an attribute (wsp:Ignorable) that can be used to influence whether assertions are part of the compatibility assessment between two alternatives. [see <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> and <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>]. Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and should follow <a href="#DefineIgnorable"><b>8. Document Ignorable Behavior</b></a> and <a href="#ignorableAssertions"><b>9. Document Use of the Ignorable
Attribute in XML </b></a> to include this guidance in the assertion's definition.</p></div><div class="div3">
-<h4><a name="d4e959" id="d4e959"></a>5.5.2 Ignorable behavior at runtime</h4><p>Regardless of whether the assertion allows the ignorable attribute, assertion authors should
+<h4><a name="d4e957" id="d4e957"></a>5.5.2 Ignorable behavior at runtime</h4><p>Regardless of whether the assertion allows the ignorable attribute, assertion authors should
indicate the semantic of the runtime behavior in the description of the assertion.
</p><p>
As said in <a href="ws-policy-primer.html#strict-lax-policy-intersection">section 3.4.1 Strict and Lax Policy Intersection</a> in <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>, "Regardless of the chosen intersection mode, ignorable assertions do not express any wire-level requirements on the behavior of consumers - in other words, a consumer could choose to ignore any such assertions that end up in the resulting policy after intersection, with no adverse effects on runtime interactions." Therefore, any assertion that is marked with ignorable should not impose any wire-level requirements on the part of consumers. Assertion Authors are reminded that regardless of whether an assertion is marked as ignorable, policy consumers using strict intersection will not 'ignore' the assertion.
</p></div></div><div class="div2">
<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>5.6 Designating Optional Behaviors</h3><div class="div3">
-<h4><a name="d4e974" id="d4e974"></a>5.6.1 Optional behavior at runtime</h4><p><span class="diff-del"><span>Since optional behaviors indicate optionality for
+<h4><a name="d4e972" id="d4e972"></a>5.6.1 Optional behavior at runtime</h4><p><span class="diff-del"><span>Since optional behaviors indicate optionality for
both the provider and the consumer, behaviors that must
always be engaged by a consumer must not be marked as
"optional" with a value "true" since this would allow the
@@ -966,7 +966,7 @@
applies to all , messages exchanged in both </span></span><span class="diff-add"><span>directions</span></span><span class="diff-del"><span>when
optional </span></span><span class="diff-chg"><span>(e.g. </span></span><span class="diff-add"><span>both
request</span></span><span class="diff-del"><span>is </span></span><span class="diff-add"><span>and </span></span><span class="diff-chg"><span>response </span></span><span class="diff-add"><span>messages)</span></span><span class="diff-del"><span>. </span></span><span class="diff-chg"><span>with </span></span>the
- <span class="diff-del"><span>behavior </span></span><span class="diff-add"><span>specific</span></span><span class="diff-del"><span>would be applicable </span></span><span class="diff-add"><span>endpoint </span></span>to <span class="diff-add"><span>which
+ <span class="diff-del"><span>behavior would be </span></span><span class="diff-chg"><span>specific </span></span><span class="diff-add"><span>endpoint </span></span>to <span class="diff-add"><span>which
the </span></span>policy <span class="diff-add"><span>alternative including</span></span><span class="diff-del"><span>subject </span></span>that <span class="diff-add"><span>assertion </span></span>is <span class="diff-add"><span>attached.
</span></span></p><div class="diff-add"><p class="diff-add"><span class="diff-del"><span>designated, </span></span><span class="diff-chg"><span>Certain behaviors might provide in their </span></span><span class="diff-add"><span>specification</span></span><span class="diff-del"><span>Authors
to </span></span><span class="diff-chg"><span>for </span></span>the
@@ -980,14 +980,14 @@
request-response, the engagement <span class="diff-add"><span>in the context </span></span>of the rest of the interaction
<span class="diff-add"><span>such as the outbound message, </span></span>will
be undefined. Therefore, the Assertion Authors are encouraged to
- consider <span class="diff-del"><span>how </span></span>the <span class="diff-add"><span>implications of </span></span>attachment <span class="diff-add"><span>of an assertion that indicates
- such optional behavior</span></span><span class="diff-del"><span>on </span></span><span class="diff-add"><span>at </span></span>a message policy subject on <span class="diff-chg"><span>the interaction
+ consider <span class="diff-del"><span>how </span></span>the <span class="diff-add"><span>implications of </span></span>attachment <span class="diff-add"><span>of an assertion that</span></span><span class="diff-add"><span>indicates
+ such optional behavior at </span></span>a message policy subject on <span class="diff-chg"><span>the interaction
as a whole. For example, if reliable messaging (RM) </span></span><span class="diff-add"><span>is</span></span><span class="diff-del"><span>for
message </span></span><span class="diff-chg"><span>applied to </span></span>a request
<span class="diff-add"><span>message </span></span><span class="diff-del"><span>response for response </span></span><span class="diff-add"><span>because</span></span><span class="diff-del"><span>messages,
using </span></span><span class="diff-chg"><span>the </span></span>policy <span class="diff-chg"><span>attached to </span></span>the <span class="diff-chg"><span>inbound message in </span></span><span class="diff-add"><span>a request-response</span></span><span class="diff-del"><span>or
</span></span><span class="diff-chg"><span>operation had an alternative that incldued RM </span></span>in<span class="diff-del"><span>assumptions.
- Similarly, </span></span><span class="diff-chg"><span>its </span></span><span class="diff-add"><span>assertions, is</span></span><span class="diff-del"><span>engagement </span></span><span class="diff-add"><span>the application
+ Similarly, </span></span><span class="diff-chg"><span>its </span></span><span class="diff-add"><span>assertions, is the</span></span><span class="diff-del"><span>engagement </span></span><span class="diff-add"><span>application
</span></span>of <span class="diff-chg"><span>RM to the outbound message permitted, </span></span><span class="diff-add"><span>even</span></span><span class="diff-del"><span>an
outbound </span></span><span class="diff-chg"><span>if there is no </span></span><span class="diff-add"><span>policy
attached</span></span><span class="diff-del"><span>should </span></span><span class="diff-chg"><span>to </span></span><span class="diff-add"><span>that subject? Leaving </span></span><span class="diff-del"><span>describing
@@ -997,25 +997,25 @@
</span></span>This is especially important if the assertion is applicable to more
than one specific policy subject. <span class="diff-chg"><span>The </span></span>approach <span class="diff-del"><span>that is currently </span></span>taken
by
- WS-RM Policy [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy Assertion</a></cite>] is to <span class="diff-add"><span>provide for an RM
- assertion to be attached at either or
- </span></span><span class="diff-del"><span>introduce </span></span>both message and endpoint policy <span class="diff-add"><span>subjects.
+ WS-RM Policy [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy Assertion</a></cite>] is to <span class="diff-add"><span>provide for
+ </span></span><span class="diff-del"><span>introduce </span></span><span class="diff-add"><span>an RM
+ assertion to be attached at either or </span></span>both message and endpoint policy <span class="diff-add"><span>subjects.
In</span></span><span class="diff-del"><span>subjects </span></span><span class="diff-chg"><span>order to eliminate </span></span><span class="diff-add"><span>the</span></span><span class="diff-del"><span>its
- assertions </span></span><span class="diff-chg"><span>ambiguity </span></span><span class="diff-add"><span>associated with only using a message
- policy</span></span><span class="diff-del"><span>require </span></span><span class="diff-add"><span>subject, </span></span>the <span class="diff-chg"><span>WS-RM Policy </span></span><span class="diff-add"><span>requires a policy to be attached to an
- </span></span>endpoint policy subject <span class="diff-add"><span>as well as
- </span></span><span class="diff-del"><span>when </span></span><span class="diff-add"><span>a </span></span>message policy subject <span class="diff-add"><span>whenever a policy
+ assertions </span></span><span class="diff-chg"><span>ambiguity </span></span><span class="diff-add"><span>associated with only using a</span></span><span class="diff-del"><span>require </span></span><span class="diff-add"><span>message
+ policy subject, </span></span>the <span class="diff-chg"><span>WS-RM </span></span><span class="diff-add"><span>Policy requires a</span></span><span class="diff-del"><span>of </span></span><span class="diff-add"><span>policy to be attached to an
+ </span></span>endpoint policy subject
+ <span class="diff-del"><span>when </span></span><span class="diff-add"><span>as well as a </span></span>message policy subject <span class="diff-add"><span>whenever a policy
is attached to a message policy subject.
The combination directly addresses
the unstated semantic that if RM </span></span>is used <span class="diff-add"><span>for inbound messages, that it MAY
- be used for outbound</span></span><span class="diff-del"><span>via </span></span><span class="diff-add"><span>messages, even if the assertion is not attached to the
- outbound message (and vice-versa).</span></span><span class="diff-del"><span>attachment.
+ be used for outbound messages, even if the assertion is not attached to the
+ outbound</span></span><span class="diff-del"><span>via </span></span><span class="diff-add"><span>message (and vice-versa).</span></span><span class="diff-del"><span>attachment.
</span></span></p></div><div class="boxedtext"><p><a name="bp-entire-mep-for-optional" id="bp-entire-mep-for-optional"></a><span class="practicelab">Best
Practice 17: Consider entire message exchange pattern when specifying Assertions that representmay be optional behavior related
to a subset of that message exchange pattern when considering appropriate policy
subject attachment points </span></p><p class="practice">Assertion Authors should associate assertions that represent optional behavior
with the appropriate policy subjectendpoint and use the smallest
- possible granularity (See Best Practice 28) to limit the degree to which optional behavior applies.</p></div><p>
+ possible granularity (See Best Practice 28) to limit the degree to which optional behavioroptionality applies.</p></div><p>
Behaviors <span class="diff-add"><span>that </span></span>must be engaged <span class="diff-add"><span>in the context of an interaction must not be marked
with wsp:Optional="true". since this creates two alternatives; one with and one without
that assertion. This would allow the policy consumer to select the policy alternative
@@ -1054,7 +1054,7 @@
Note that if a MTOM assertion were only bound to <span class="diff-add"><span>the policy subject representing</span></span><span class="diff-del"><span>an </span></span><span class="diff-add"><span>the
</span></span>inbound <span class="diff-chg"><span>message, </span></span><span class="diff-del"><span>endpoint,
</span></span>then it would not be clear <span class="diff-add"><span>to the service provider </span></span>whether the outbound
- <span class="diff-add"><span>whether </span></span><span class="diff-chg"><span>the outbound </span></span><span class="diff-add"><span>messages generated by that</span></span><span class="diff-del"><span>the </span></span>provider <span class="diff-chg"><span>should
+ <span class="diff-add"><span>whether </span></span><span class="diff-chg"><span>the outbound </span></span><span class="diff-add"><span>messages generated by</span></span><span class="diff-del"><span>the </span></span><span class="diff-add"><span>that </span></span>provider <span class="diff-chg"><span>should
</span></span>also utilize <span class="diff-chg"><span>that </span></span>behavior. Thus this assertion should be associated at the granularity
of an entire message exchange. The semantics of the assertion should specify this
to avoid inappropriate assumptions by implementations.
@@ -1062,9 +1062,9 @@
<h3><a name="levels-of-abstraction" id="levels-of-abstraction"></a>5.7 <span class="diff-add"><span>Considerations </span></span><span class="diff-chg"><span>for Policy </span></span><span class="diff-add"><span>Attachment</span></span></h3><div class="div3">
<h4><a name="general-attachment-guidelines" id="general-attachment-guidelines"></a>5.7.1 <span class="diff-add"><span>General</span></span><span class="diff-del"><span>important </span></span><span class="diff-add"><span>Guidelines</span></span></h4><p><span class="diff-add"><span>Although</span></span><span class="diff-del"><span>for </span></span><span class="diff-add"><span>a</span></span><span class="diff-del"><span>an
optional </span></span><span class="diff-chg"><span>policy </span></span><span class="diff-add"><span>assertion</span></span><span class="diff-del"><span>where it </span></span>may <span class="diff-add"><span>be constrained to a specific set of policy subjects by Assertion Authors,
- its semantics should </span></span>not be <span class="diff-chg"><span>dependent upon </span></span><span class="diff-add"><span>the mechanism by which the policy</span></span><span class="diff-del"><span>it </span></span><span class="diff-add"><span>expression </span></span>is <span class="diff-add"><span>attached </span></span>to <span class="diff-add"><span>a
- given</span></span><span class="diff-del"><span>apply </span></span><span class="diff-chg"><span>policy subject. </span></span><span class="diff-add"><span>For instance, an</span></span><span class="diff-del"><span>message
- exchange </span></span><span class="diff-add"><span>assertion "Foo" has the same semantics </span></span>when <span class="diff-chg"><span>attached to an </span></span><span class="diff-add"><span>operation
+ its semantics should </span></span>not be <span class="diff-chg"><span>dependent upon </span></span><span class="diff-add"><span>the mechanism by which the policy expression</span></span><span class="diff-del"><span>it </span></span>is <span class="diff-add"><span>attached </span></span>to <span class="diff-add"><span>a
+ given</span></span><span class="diff-del"><span>apply </span></span><span class="diff-chg"><span>policy subject. </span></span><span class="diff-add"><span>For instance, an assertion "Foo" has the same semantics</span></span><span class="diff-del"><span>message
+ exchange </span></span>when <span class="diff-chg"><span>attached to an </span></span><span class="diff-add"><span>operation
policy</span></span><span class="diff-del"><span>part </span></span><span class="diff-chg"><span>subject regardless </span></span><span class="diff-add"><span>of</span></span><span class="diff-del"><span>exchange
(Best </span></span><span class="diff-chg"><span>whether it was attached using XML element policy attachment or the external </span></span><span class="diff-add"><span>URI
attachment</span></span><span class="diff-del"><span>optional).
@@ -1078,10 +1078,11 @@
General </span></span>a<span class="diff-del"><span>Guidelines
- The </span></span><span class="diff-chg"><span>specific </span></span>attachment mechanism <span class="diff-add"><span>allows policy tools</span></span><span class="diff-del"><span>used </span></span>to <span class="diff-chg"><span>choose </span></span>the <span class="diff-add"><span>most
- appropriate</span></span><span class="diff-chg"><span>mechanism to attach a policy without </span></span><span class="diff-add"><span>having</span></span><span class="diff-del"><span>additional
- semantics </span></span><span class="diff-add"><span>to analyze</span></span><span class="diff-del"><span>in </span></span>the <span class="diff-chg"><span>contents </span></span>of <span class="diff-chg"><span>the </span></span><span class="diff-add"><span>policy.</span></span></p><div class="boxedtext"><p><a name="bp-assertion-semantics" id="bp-assertion-semantics"></a><span class="practicelab">Best
-Practice 20: Semanticsalternatives. Independent of Attachment Mechanisms</span></p><p class="practice">The semantics of a policy assertion should not depend on theto attachment mechanism used.</p></div><p><span class="diff-add"><span>For example, a security policy expression can </span></span>be <span class="diff-chg"><span>assigned a key reference and
+ The </span></span><span class="diff-chg"><span>specific </span></span>attachment mechanism <span class="diff-add"><span>allows policy</span></span><span class="diff-del"><span>used </span></span><span class="diff-add"><span>tools </span></span>to
+ <span class="diff-del"><span>communicate </span></span><span class="diff-add"><span>choose </span></span>the <span class="diff-add"><span>most
+ appropriate</span></span><span class="diff-del"><span>policy </span></span><span class="diff-chg"><span>mechanism to attach a </span></span><span class="diff-add"><span>policy without</span></span><span class="diff-del"><span>or </span></span><span class="diff-chg"><span>having </span></span><span class="diff-add"><span>to</span></span><span class="diff-del"><span>additional
+ semantics </span></span><span class="diff-chg"><span>analyze </span></span>the <span class="diff-chg"><span>contents </span></span>of <span class="diff-chg"><span>the </span></span><span class="diff-add"><span>policy.</span></span></p><div class="boxedtext"><p><a name="bp-assertion-semantics" id="bp-assertion-semantics"></a><span class="practicelab">Best
+Practice 20: Semanticsalternatives. Independent of Attachment Mechanisms</span></p><p class="practice">The semantics of a policy assertion should not depend on the attachment mechanism used.</p></div><p><span class="diff-add"><span>For</span></span><span class="diff-del"><span>to </span></span><span class="diff-add"><span>example, a security policy expression can </span></span>be <span class="diff-chg"><span>assigned a key reference and
be attached </span></span><span class="diff-add"><span>to a</span></span><span class="diff-del"><span>mechanisms </span></span><span class="diff-add"><span>UDDI binding or can be embedded </span></span>in <span class="diff-add"><span>a WSDL document.</span></span><span class="diff-del"><span>mind. </span></span></p><p>Since multiple attachment mechanisms may be used, a policy alternative created during the process of calculating
an effective policy can contain multiple instances of the same policy assertion type
( i.e., the SignedParts assertion). It is therefore also important for the policy authors to define what it
@@ -1129,7 +1130,7 @@
and identify which of the existing policy subjects can be used with the assertions
they define. That
identification will facilitate the deployment of their policy
- <span class="diff-del"><span>assertions and include such information in the assertion </span></span><span class="diff-chg"><span>assertions.
+ <span class="diff-del"><span>assertions and include such information in the </span></span><span class="diff-add"><span>assertions.</span></span><span class="diff-del"><span>assertion definition.
</span></span></p><p> An example of this practice is
the Reliable Messaging Policy Assertion document [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy Assertion</a></cite>]. In the Sequence STR Assertion (section
2.5.1) the Reliable Messaging Policy Assertion authors state that "The
@@ -1190,7 +1191,7 @@
policy </span></span><span class="diff-add"><span>practice
is</span></span><span class="diff-del"><span>attachments </span></span>to <span class="diff-chg"><span>choose the most granular WSDL policy subject </span></span><span class="diff-add"><span>to</span></span><span class="diff-del"><span>granularity
should </span></span><span class="diff-chg"><span>which the </span></span><span class="diff-add"><span>behavior
- represented</span></span><span class="diff-del"><span>only </span></span><span class="diff-add"><span>by a</span></span><span class="diff-del"><span>after </span></span><span class="diff-add"><span>policy assertion</span></span><span class="diff-del"><span>careful </span></span><span class="diff-chg"><span>applies.
+ represented</span></span><span class="diff-del"><span>only </span></span><span class="diff-add"><span>by a policy</span></span><span class="diff-del"><span>after </span></span><span class="diff-chg"><span>assertion applies.
</span></span></p><div class="boxedtext"><p><a name="bp-WSDL-policy-subject-Granularity" id="bp-WSDL-policy-subject-Granularity"></a><span class="practicelab">Best
Practice 27: Choose the Most Granular WSDL Policy Subject</span></p><p class="practice">Assertion Authors should choose the most granular WSDL policy subject
to which the behavior represented by a policy assertion applies.
@@ -1214,7 +1215,7 @@
[<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy Assertion</a></cite>] gives rules on which WSDL policy subjects may be associated with the RM
Policy assertion, and which WSDL 1.1 elements may have RM Policy assertions attached.
</p><p>If the <span class="diff-chg"><span>behavior indicated </span></span><span class="diff-add"><span>by</span></span><span class="diff-del"><span>imply
- different </span></span><span class="diff-chg"><span>an assertion varies </span></span><span class="diff-add"><span>when attached </span></span>to <span class="diff-chg"><span>different </span></span><span class="diff-add"><span>policy subjects</span></span><span class="diff-del"><span>points, </span></span>the Assertion Authors
+ different </span></span><span class="diff-chg"><span>an assertion </span></span><span class="diff-add"><span>varies when attached</span></span><span class="diff-del"><span>respect </span></span>to <span class="diff-chg"><span>different </span></span><span class="diff-add"><span>policy subjects</span></span><span class="diff-del"><span>points, </span></span>the Assertion Authors
should consider the following:</p><ul><li><p> Decompose the semantics with several assertions.</p></li><li><p> Rewrite a single assertion targeting a specific <span class="diff-add"><span>policy </span></span>subject. </p></li></ul><p>Since many attachment points are available in WSDL, it would be
necessary for Assertion Authors to recommend a preferred attachment
point. One approach would be to identify different attachment points in
@@ -1289,8 +1290,8 @@
security mechanism (e.g. <code>sp:HttpsToken</code>)".
</p></div></div><div class="div1">
<h2><a name="versioning-policy-assertions" id="versioning-policy-assertions"></a>6. Versioning Policy Assertions</h2><p>Assertion Authors need to consider not just the expression of the current set of requirements but
- how they anticipate new assertions being added to the set. There are three aspects to versioning policy assertions:</p><ul><li><p> Assertion <span class="diff-add"><span>Extensibility. Assertion</span></span><span class="diff-del"><span>Extensibility </span></span><span class="diff-add"><span>authors should allow for extensibility
- (see best practice 5. Start with a Simple Assertion)
+ how they anticipate new assertions being added to the set. There are three aspects to versioning policy assertions:</p><ul><li><p> Assertion <span class="diff-add"><span>Extensibility. Assertion authors should allow for extensibility
+ (see best</span></span><span class="diff-del"><span>Extensibility </span></span><span class="diff-add"><span>practice 5. Start with a Simple Assertion)
</span></span></p></li><li><p> Policy Language Extensibility </p><p>Over time, the Policy WG or third parties can version or extend the Policy Language with new
or modified constructs. These constructs may be compatible or incompatible with previous versions.
</p><p> Assertion Authors should review the WS-Policy Primer <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>
@@ -1408,7 +1409,7 @@
World Wide Web Consortium, 8 May 2000. Available at
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/. </dd><dt class="label"><span class="diff-chg"><a name="SOAP12"></a>SOAP 1.2 Messaging Framework (Second Edition)</span></dt><dd><div class="diff-chg">
<cite><a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/">SOAP Version 1.2 Part 1: Messaging Framework <span class="diff-add"><span>(Second Edition)</span></span></a></cite>, M. Gudgin, M. Hadley,
- N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen, <span class="diff-add"><span>A. Karmarkar, and Y.</span></span><span class="diff-add"><span>Lafon, Editors.
+ N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen, <span class="diff-chg"><span>A. </span></span><span class="diff-add"><span>Karmarkar, and Y. Lafon, Editors.
</span></span>World Wide Web Consortium, <span class="diff-add"><span>27</span></span><span class="diff-del"><span>24
June </span></span><span class="diff-chg"><span>April </span></span><span class="diff-add"><span>2007.
</span></span>This version of the SOAP Version 1.2 Part 1: Messaging Framework Recommendation
@@ -1476,7 +1477,7 @@
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf.
Namespace document available at
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702. </dd><dt class="label"><span class="diff-chg"><a name="WS-Trust"></a>WS-Trust</span></dt><dd><div class="diff-chg">
- <cite><a href="http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf">Web Services <span class="diff-chg"><span>Atomic </span></span><span class="diff-add"><span>Transaction (WS-AtomicTransaction)</span></span><span class="diff-del"><span>Language </span></span><span class="diff-add"><span>Version 1.1</span></span><span class="diff-del"><span>(WS-Trust)</span></span></a></cite>,
+ <cite><a href="http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf">Web Services <span class="diff-chg"><span>Atomic </span></span><span class="diff-add"><span>Transaction (WS-AtomicTransaction) Version</span></span><span class="diff-del"><span>Language </span></span><span class="diff-chg"><span>1.1</span></span></a></cite>,
<span class="diff-del"><span>S. </span></span><span class="diff-chg"><span>M. Little, A. </span></span><span class="diff-add"><span>Wilkinson,
Editors.</span></span><span class="diff-del"><span>Authors. </span></span><span class="diff-add"><span>Organization</span></span><span class="diff-del"><span>Actional Corporation, BEA
Systems, Inc., Computer Associates International, Inc.,
@@ -1509,7 +1510,7 @@
http://uddi.org/pubs/DataStructure_v2.htm.
</dd><dt class="label"><span class="diff-chg"><a name="UDDI30"></a>UDDI 3.0</span></dt><dd><div class="diff-chg">
<cite><a href="http://uddi.org/pubs/uddi-v3.0.2-20041019.htm">UDDI Version <span class="diff-chg"><span>3.0.2</span></span></a></cite>, L. Clément, <span class="diff-add"><span>A.</span></span><span class="diff-del"><span>et
- al, </span></span><span class="diff-add"><span>Hately, C.</span></span><span class="diff-add"><span>von Riegen, and T. Rogers, Editors.
+ al, </span></span><span class="diff-chg"><span>Hately, </span></span><span class="diff-add"><span>C. von Riegen, and T. Rogers, Editors.
</span></span>Organization for the Advancement of Structured Information Standards, <span class="diff-chg"><span>19 </span></span>October <span class="diff-chg"><span>2004. </span></span>This version of the
UDDI Version 3.0 is
<span class="diff-del"><span>http://uddi.org/pubs/uddi-v3.0.1-20031014.htm. </span></span><span class="diff-add"><span>http://uddi.org/pubs/uddi-v3.0.2-20041019.htm.
@@ -1873,4 +1874,12 @@
Web Services Reliable Messaging, Web Services Reliable Messaging Policy Assertion,
WS-SecurityPolicy and WS-Trust references.
</td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20071026</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">ASV</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Updated <a href="#change-description"><b>E. Changes in this Version of the Document</b></a>.
+ </td></div></tr></div><div class="diff-add"><tr class="diff-add"><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">20071029</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">ASV</td></div><div class="diff-add"><td colspan="1" class="diff-add" rowspan="1">Incorporated Chris' proposed resolution for
+ issue <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5218"><span class="diff-add"><span>5218</span></span></a>: drop the
+ second sentence in <a href="#bp-semantics-multiple-same-type"><b>21. Describe Semantics of Multiple Assertions of Same Type</b></a>, "If there are multiple
+ instances
+ of a policy assertion type in the same policy alternative without
+ parameters and nested policies, these have the same meaning as a
+ single assertion of the type within the policy alternative." Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/384"><span class="diff-add"><span>384</span></span></a>.
</td></div></tr></div></tbody></table><br></div></div></body></html>
\ No newline at end of file
Index: ws-policy-guidelines-diff20070928.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines-diff20070928.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- ws-policy-guidelines-diff20070928.xml 27 Oct 2007 01:42:46 -0000 1.3
+++ ws-policy-guidelines-diff20070928.xml 29 Oct 2007 17:55:31 -0000 1.4
@@ -383,7 +383,7 @@
understand how policy expressions are used by a
framework implementation that has followed the specifications.
</p><p>The examples given in this document <phrase diff="add">are
- based</phrase><phrase diff="del">reference </phrase><phrase diff="chg">on </phrase><phrase diff="add">existing assertions such</phrase><phrase diff="del">like </phrase><phrase diff="add">as </phrase>WS-SecurityPolicy and WS-RM Policy.
+ based</phrase><phrase diff="del">reference </phrase><phrase diff="chg">on </phrase><phrase diff="add">existing assertions such as</phrase><phrase diff="del">like </phrase>WS-SecurityPolicy and WS-RM Policy.
These policy expressions represent web services message exchange requirements, but policy authoring can
be done by individual groups that wish to represent web services application requirements and
deployments that wish to reuse the WS-Policy framework in
@@ -790,7 +790,7 @@
applies to all , messages exchanged in both </phrase><phrase diff="add">directions</phrase><phrase diff="del">when
optional </phrase><phrase diff="chg">(e.g. </phrase><phrase diff="add">both
request</phrase><phrase diff="del">is </phrase><phrase diff="add">and </phrase><phrase diff="chg">response </phrase><phrase diff="add">messages)</phrase><phrase diff="del">. </phrase><phrase diff="chg">with </phrase>the
- <phrase diff="del">behavior </phrase><phrase diff="add">specific</phrase><phrase diff="del">would be applicable </phrase><phrase diff="add">endpoint </phrase>to <phrase diff="add">which
+ <phrase diff="del">behavior would be </phrase><phrase diff="chg">specific </phrase><phrase diff="add">endpoint </phrase>to <phrase diff="add">which
the </phrase>policy <phrase diff="add">alternative including</phrase><phrase diff="del">subject </phrase>that <phrase diff="add">assertion </phrase>is <phrase diff="add">attached.
</phrase></p><p diff="add"><phrase diff="del">designated, </phrase><phrase diff="chg">Certain behaviors might provide in their </phrase><phrase diff="add">specification</phrase><phrase diff="del">Authors
to </phrase><phrase diff="chg">for </phrase>the
@@ -804,14 +804,14 @@
request-response, the engagement <phrase diff="add">in the context </phrase>of the rest of the interaction
<phrase diff="add">such as the outbound message, </phrase>will
be undefined. Therefore, the Assertion Authors are encouraged to
- consider <phrase diff="del">how </phrase>the <phrase diff="add">implications of </phrase>attachment <phrase diff="add">of an assertion that indicates
- such optional behavior</phrase><phrase diff="del">on </phrase><phrase diff="add">at </phrase>a message policy subject on <phrase diff="chg">the interaction
+ consider <phrase diff="del">how </phrase>the <phrase diff="add">implications of </phrase>attachment <phrase diff="add">of an assertion that</phrase><phrase diff="add">indicates
+ such optional behavior at </phrase>a message policy subject on <phrase diff="chg">the interaction
as a whole. For example, if reliable messaging (RM) </phrase><phrase diff="add">is</phrase><phrase diff="del">for
message </phrase><phrase diff="chg">applied to </phrase>a request
<phrase diff="add">message </phrase><phrase diff="del">response for response </phrase><phrase diff="add">because</phrase><phrase diff="del">messages,
using </phrase><phrase diff="chg">the </phrase>policy <phrase diff="chg">attached to </phrase>the <phrase diff="chg">inbound message in </phrase><phrase diff="add">a request-response</phrase><phrase diff="del">or
</phrase><phrase diff="chg">operation had an alternative that incldued RM </phrase>in<phrase diff="del">assumptions.
- Similarly, </phrase><phrase diff="chg">its </phrase><phrase diff="add">assertions, is</phrase><phrase diff="del">engagement </phrase><phrase diff="add">the application
+ Similarly, </phrase><phrase diff="chg">its </phrase><phrase diff="add">assertions, is the</phrase><phrase diff="del">engagement </phrase><phrase diff="add">application
</phrase>of <phrase diff="chg">RM to the outbound message permitted, </phrase><phrase diff="add">even</phrase><phrase diff="del">an
outbound </phrase><phrase diff="chg">if there is no </phrase><phrase diff="add">policy
attached</phrase><phrase diff="del">should </phrase><phrase diff="chg">to </phrase><phrase diff="add">that subject? Leaving </phrase><phrase diff="del">describing
@@ -821,26 +821,26 @@
</phrase>This is especially important if the assertion is applicable to more
than one specific policy subject. <phrase diff="chg">The </phrase>approach <phrase diff="del">that is currently </phrase>taken
by
- WS-RM Policy [<bibref ref="WS-RM-Policy"/>] is to <phrase diff="add">provide for an RM
- assertion to be attached at either or
- </phrase><phrase diff="del">introduce </phrase>both message and endpoint policy <phrase diff="add">subjects.
+ WS-RM Policy [<bibref ref="WS-RM-Policy"/>] is to <phrase diff="add">provide for
+ </phrase><phrase diff="del">introduce </phrase><phrase diff="add">an RM
+ assertion to be attached at either or </phrase>both message and endpoint policy <phrase diff="add">subjects.
In</phrase><phrase diff="del">subjects </phrase><phrase diff="chg">order to eliminate </phrase><phrase diff="add">the</phrase><phrase diff="del">its
- assertions </phrase><phrase diff="chg">ambiguity </phrase><phrase diff="add">associated with only using a message
- policy</phrase><phrase diff="del">require </phrase><phrase diff="add">subject, </phrase>the <phrase diff="chg">WS-RM Policy </phrase><phrase diff="add">requires a policy to be attached to an
- </phrase>endpoint policy subject <phrase diff="add">as well as
- </phrase><phrase diff="del">when </phrase><phrase diff="add">a </phrase>message policy subject <phrase diff="add">whenever a policy
+ assertions </phrase><phrase diff="chg">ambiguity </phrase><phrase diff="add">associated with only using a</phrase><phrase diff="del">require </phrase><phrase diff="add">message
+ policy subject, </phrase>the <phrase diff="chg">WS-RM </phrase><phrase diff="add">Policy requires a</phrase><phrase diff="del">of </phrase><phrase diff="add">policy to be attached to an
+ </phrase>endpoint policy subject
+ <phrase diff="del">when </phrase><phrase diff="add">as well as a </phrase>message policy subject <phrase diff="add">whenever a policy
is attached to a message policy subject.
The combination directly addresses
the unstated semantic that if RM </phrase>is used <phrase diff="add">for inbound messages, that it MAY
- be used for outbound</phrase><phrase diff="del">via </phrase><phrase diff="add">messages, even if the assertion is not attached to the
- outbound message (and vice-versa).</phrase><phrase diff="del">attachment.
+ be used for outbound messages, even if the assertion is not attached to the
+ outbound</phrase><phrase diff="del">via </phrase><phrase diff="add">message (and vice-versa).</phrase><phrase diff="del">attachment.
</phrase></p><p id="bp-entire-mep-for-optional" role="practice">
<quote>Consider entire message exchange pattern when specifying Assertions that <phrase diff="add">represent</phrase><phrase diff="del">may be </phrase>optional <phrase diff="add">behavior related
to a subset of that message exchange pattern when considering appropriate policy
subject attachment points </phrase></quote>
<quote>Assertion Authors should associate assertions <phrase diff="add">that represent optional behavior
</phrase>with the appropriate <phrase diff="add">policy subject</phrase><phrase diff="del">endpoint </phrase>and use the smallest
- possible granularity <phrase diff="add">(See Best Practice 28) </phrase>to limit the degree to which <phrase diff="chg">optional </phrase><phrase diff="add">behavior </phrase>applies.</quote>
+ possible granularity <phrase diff="add">(See Best Practice 28) </phrase>to limit the degree to which <phrase diff="add">optional behavior</phrase><phrase diff="del">optionality </phrase>applies.</quote>
</p><p>
Behaviors <phrase diff="add">that </phrase>must be engaged <phrase diff="add">in the context of an interaction must not be marked
with wsp:Optional="true". since this creates two alternatives; one with and one without
@@ -884,15 +884,15 @@
Note that if a MTOM assertion were only bound to <phrase diff="add">the policy subject representing</phrase><phrase diff="del">an </phrase><phrase diff="add">the
</phrase>inbound <phrase diff="chg">message, </phrase><phrase diff="del">endpoint,
</phrase>then it would not be clear <phrase diff="add">to the service provider </phrase>whether the outbound
- <phrase diff="add">whether </phrase><phrase diff="chg">the outbound </phrase><phrase diff="add">messages generated by that</phrase><phrase diff="del">the </phrase>provider <phrase diff="chg">should
+ <phrase diff="add">whether </phrase><phrase diff="chg">the outbound </phrase><phrase diff="add">messages generated by</phrase><phrase diff="del">the </phrase><phrase diff="add">that </phrase>provider <phrase diff="chg">should
</phrase>also utilize <phrase diff="chg">that </phrase>behavior. Thus this assertion should be associated at the granularity
of an entire message exchange. The semantics of the assertion should specify this
to avoid inappropriate assumptions by implementations.
</p></div3></div2><div2 diff="add" id="levels-of-abstraction"><head><phrase diff="add">Considerations </phrase><phrase diff="chg">for Policy </phrase><phrase diff="add">Attachment</phrase></head><div3 id="general-attachment-guidelines"><head><phrase diff="add">General</phrase><phrase diff="del">important </phrase><phrase diff="add">Guidelines</phrase></head><p><phrase diff="add">Although</phrase><phrase diff="del">for </phrase><phrase diff="add">a</phrase><phrase diff="del">an
optional </phrase><phrase diff="chg">policy </phrase><phrase diff="add">assertion</phrase><phrase diff="del">where it </phrase>may <phrase diff="add">be constrained to a specific set of policy subjects by Assertion Authors,
- its semantics should </phrase>not be <phrase diff="chg">dependent upon </phrase><phrase diff="add">the mechanism by which the policy</phrase><phrase diff="del">it </phrase><phrase diff="add">expression </phrase>is <phrase diff="add">attached </phrase>to <phrase diff="add">a
- given</phrase><phrase diff="del">apply </phrase><phrase diff="chg">policy subject. </phrase><phrase diff="add">For instance, an</phrase><phrase diff="del">message
- exchange </phrase><phrase diff="add">assertion "Foo" has the same semantics </phrase>when <phrase diff="chg">attached to an </phrase><phrase diff="add">operation
+ its semantics should </phrase>not be <phrase diff="chg">dependent upon </phrase><phrase diff="add">the mechanism by which the policy expression</phrase><phrase diff="del">it </phrase>is <phrase diff="add">attached </phrase>to <phrase diff="add">a
+ given</phrase><phrase diff="del">apply </phrase><phrase diff="chg">policy subject. </phrase><phrase diff="add">For instance, an assertion "Foo" has the same semantics</phrase><phrase diff="del">message
+ exchange </phrase>when <phrase diff="chg">attached to an </phrase><phrase diff="add">operation
policy</phrase><phrase diff="del">part </phrase><phrase diff="chg">subject regardless </phrase><phrase diff="add">of</phrase><phrase diff="del">exchange
(Best </phrase><phrase diff="chg">whether it was attached using XML element policy attachment or the external </phrase><phrase diff="add">URI
attachment</phrase><phrase diff="del">optional).
@@ -906,12 +906,13 @@
General </phrase>a<phrase diff="del">Guidelines
- The </phrase><phrase diff="chg">specific </phrase>attachment mechanism <phrase diff="add">allows policy tools</phrase><phrase diff="del">used </phrase>to <phrase diff="chg">choose </phrase>the <phrase diff="add">most
- appropriate</phrase><phrase diff="chg">mechanism to attach a policy without </phrase><phrase diff="add">having</phrase><phrase diff="del">additional
- semantics </phrase><phrase diff="add">to analyze</phrase><phrase diff="del">in </phrase>the <phrase diff="chg">contents </phrase>of <phrase diff="chg">the </phrase><phrase diff="add">policy.</phrase></p><p id="bp-assertion-semantics" role="practice">
+ The </phrase><phrase diff="chg">specific </phrase>attachment mechanism <phrase diff="add">allows policy</phrase><phrase diff="del">used </phrase><phrase diff="add">tools </phrase>to
+ <phrase diff="del">communicate </phrase><phrase diff="add">choose </phrase>the <phrase diff="add">most
+ appropriate</phrase><phrase diff="del">policy </phrase><phrase diff="chg">mechanism to attach a </phrase><phrase diff="add">policy without</phrase><phrase diff="del">or </phrase><phrase diff="chg">having </phrase><phrase diff="add">to</phrase><phrase diff="del">additional
+ semantics </phrase><phrase diff="chg">analyze </phrase>the <phrase diff="chg">contents </phrase>of <phrase diff="chg">the </phrase><phrase diff="add">policy.</phrase></p><p id="bp-assertion-semantics" role="practice">
<quote><phrase diff="add">Semantics</phrase><phrase diff="del">alternatives. </phrase><phrase diff="chg">Independent of Attachment </phrase><phrase diff="add">Mechanisms</phrase></quote><phrase diff="del">each
- </phrase><quote><phrase diff="add">The semantics of a </phrase>policy assertion <phrase diff="chg">should not </phrase><phrase diff="add">depend on the</phrase><phrase diff="del">to </phrase><phrase diff="add">attachment mechanism used.</phrase></quote>
- </p><p><phrase diff="add">For example, a security policy expression can </phrase>be <phrase diff="chg">assigned a key reference and
+ </phrase><quote><phrase diff="add">The semantics of a </phrase>policy assertion <phrase diff="chg">should not </phrase><phrase diff="add">depend on the attachment mechanism used.</phrase></quote>
+ </p><p><phrase diff="add">For</phrase><phrase diff="del">to </phrase><phrase diff="add">example, a security policy expression can </phrase>be <phrase diff="chg">assigned a key reference and
be attached </phrase><phrase diff="add">to a</phrase><phrase diff="del">mechanisms </phrase><phrase diff="add">UDDI binding or can be embedded </phrase>in <phrase diff="add">a WSDL document.</phrase><phrase diff="del">mind. </phrase></p><p>Since multiple attachment mechanisms may be used, a policy alternative created during the process of calculating
an effective policy can contain multiple instances of the same policy assertion type
( i.e., the SignedParts assertion). It is therefore also important for the policy authors to define what it
@@ -931,10 +932,10 @@
semantics of parameters and nested policy (if any) when there are
multiple instances of a policy assertion type in the same policy
alternative regardless of the mechanism used to attach them to
- a policy subject. If there are multiple instances of a policy
+ a policy subject. <phrase diff="del">If there are multiple instances of a policy
assertion type in the same policy alternative without parameters
and nested policies, these have the same meaning as a single
- assertion of the type within the policy alternative.</quote> </p><p> Assertion authors should review sections 3.2 and 4.5 of the Policy Framework
+ assertion of the type within the policy alternative.</phrase></quote> </p><p> Assertion authors should review sections 3.2 and 4.5 of the Policy Framework
<bibref ref="WS-Policy"/> for more detail
on the processing for multiple assertions of the same type.</p><p id="bp-leverage-defined-attachment-mechanisms" role="practice">
<quote>Leverage Defined Attachment Mechanisms</quote><quote>
@@ -959,7 +960,7 @@
and identify which of the existing policy subjects can be used with the assertions
they define. That
identification will facilitate the deployment of their policy
- <phrase diff="del">assertions and include such information in the assertion </phrase><phrase diff="chg">assertions.
+ <phrase diff="del">assertions and include such information in the </phrase><phrase diff="add">assertions.</phrase><phrase diff="del">assertion definition.
</phrase></p><p> An example of this practice is
the Reliable Messaging Policy Assertion document [<bibref ref="WS-RM-Policy"/>]. In the Sequence STR Assertion (section
2.5.1) the Reliable Messaging Policy Assertion authors state that "The
@@ -1023,7 +1024,7 @@
policy </phrase><phrase diff="add">practice
is</phrase><phrase diff="del">attachments </phrase>to <phrase diff="chg">choose the most granular WSDL policy subject </phrase><phrase diff="add">to</phrase><phrase diff="del">granularity
should </phrase><phrase diff="chg">which the </phrase><phrase diff="add">behavior
- represented</phrase><phrase diff="del">only </phrase><phrase diff="add">by a</phrase><phrase diff="del">after </phrase><phrase diff="add">policy assertion</phrase><phrase diff="del">careful </phrase><phrase diff="chg">applies.
+ represented</phrase><phrase diff="del">only </phrase><phrase diff="add">by a policy</phrase><phrase diff="del">after </phrase><phrase diff="chg">assertion applies.
</phrase></p><p id="bp-WSDL-policy-subject-Granularity" role="practice">
<quote>Choose the Most Granular WSDL Policy Subject</quote>
<quote>Assertion Authors should choose the most granular WSDL policy subject
@@ -1051,7 +1052,7 @@
[<bibref ref="WS-RM-Policy"/>] gives rules on which WSDL policy subjects may be associated with the RM
Policy assertion, and which WSDL 1.1 elements may have RM Policy assertions attached.
</p><p>If the <phrase diff="chg">behavior indicated </phrase><phrase diff="add">by</phrase><phrase diff="del">imply
- different </phrase><phrase diff="chg">an assertion varies </phrase><phrase diff="add">when attached </phrase>to <phrase diff="chg">different </phrase><phrase diff="add">policy subjects</phrase><phrase diff="del">points, </phrase>the Assertion Authors
+ different </phrase><phrase diff="chg">an assertion </phrase><phrase diff="add">varies when attached</phrase><phrase diff="del">respect </phrase>to <phrase diff="chg">different </phrase><phrase diff="add">policy subjects</phrase><phrase diff="del">points, </phrase>the Assertion Authors
should consider the following:</p><ulist><item><p> Decompose the semantics with several assertions.</p></item><item><p> Rewrite a single assertion targeting a specific <phrase diff="add">policy </phrase>subject. </p></item></ulist><p>Since many attachment points are available in WSDL, it would be
necessary for Assertion Authors to recommend a preferred attachment
point. One approach would be to identify different attachment points in
@@ -1128,8 +1129,8 @@
<code>RMAssertion</code> and a <code>sp:TransportBinding</code> assertion that requires the use of some transport-level
security mechanism (e.g. <code>sp:HttpsToken</code>)</quote>.
</p></div2></div1><div1 id="versioning-policy-assertions"><head>Versioning Policy Assertions</head><p>Assertion Authors need to consider not just the expression of the current set of requirements but
- how they anticipate new assertions being added to the set. There are three aspects to versioning policy assertions:</p><ulist><item><p> Assertion <phrase diff="add">Extensibility. Assertion</phrase><phrase diff="del">Extensibility </phrase><phrase diff="add">authors should allow for extensibility
- (see best practice 5. Start with a Simple Assertion)
+ how they anticipate new assertions being added to the set. There are three aspects to versioning policy assertions:</p><ulist><item><p> Assertion <phrase diff="add">Extensibility. Assertion authors should allow for extensibility
+ (see best</phrase><phrase diff="del">Extensibility </phrase><phrase diff="add">practice 5. Start with a Simple Assertion)
</phrase></p></item><item><p> Policy Language Extensibility </p><p>Over time, the Policy WG or third parties can version or extend the Policy Language with new
or modified constructs. These constructs may be compatible or incompatible with previous versions.
</p><p> Assertion Authors should review the WS-Policy Primer <bibref ref="WS-Policy-Primer"/>
@@ -1240,7 +1241,7 @@
World Wide Web Consortium, 8 May 2000. Available at
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" diff="chg" href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/" id="SOAP12" key="SOAP 1.2 Messaging Framework (Second Edition)" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">SOAP Version 1.2 Part 1: Messaging Framework <phrase diff="add">(Second Edition)</phrase></titleref>, M. Gudgin, M. Hadley,
- N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen, <phrase diff="add">A. Karmarkar, and Y.</phrase><phrase diff="add">Lafon, Editors.
+ N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen, <phrase diff="chg">A. </phrase><phrase diff="add">Karmarkar, and Y. Lafon, Editors.
</phrase>World Wide Web Consortium, <phrase diff="add">27</phrase><phrase diff="del">24
June </phrase><phrase diff="chg">April </phrase><phrase diff="add">2007.
</phrase>This version of the SOAP Version 1.2 Part 1: Messaging Framework Recommendation
@@ -1308,7 +1309,7 @@
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf.
Namespace document available at
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702. </bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" diff="chg" href="http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf" id="WS-Trust" key="WS-Trust" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
- <titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">Web Services <phrase diff="chg">Atomic </phrase><phrase diff="add">Transaction (WS-AtomicTransaction)</phrase><phrase diff="del">Language </phrase><phrase diff="add">Version 1.1</phrase><phrase diff="del">(WS-Trust)</phrase></titleref>,
+ <titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">Web Services <phrase diff="chg">Atomic </phrase><phrase diff="add">Transaction (WS-AtomicTransaction) Version</phrase><phrase diff="del">Language </phrase><phrase diff="chg">1.1</phrase></titleref>,
<phrase diff="del">S. </phrase><phrase diff="chg">M. Little, A. </phrase><phrase diff="add">Wilkinson,
Editors.</phrase><phrase diff="del">Authors. </phrase><phrase diff="add">Organization</phrase><phrase diff="del">Actional Corporation, BEA
Systems, Inc., Computer Associates International, Inc.,
@@ -1341,7 +1342,7 @@
http://uddi.org/pubs/DataStructure_v2.htm.
</bibl><bibl xmlns:xlink="http://www.w3.org/1999/xlink" diff="chg" href="http://uddi.org/pubs/uddi-v3.0.2-20041019.htm" id="UDDI30" key="UDDI 3.0" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple">
<titleref xlink:actuate="onRequest" xlink:show="new" xlink:type="simple">UDDI Version <phrase diff="chg">3.0.2</phrase></titleref>, L. Clément, <phrase diff="add">A.</phrase><phrase diff="del">et
- al, </phrase><phrase diff="add">Hately, C.</phrase><phrase diff="add">von Riegen, and T. Rogers, Editors.
+ al, </phrase><phrase diff="chg">Hately, </phrase><phrase diff="add">C. von Riegen, and T. Rogers, Editors.
</phrase>Organization for the Advancement of Structured Information Standards, <phrase diff="chg">19 </phrase>October <phrase diff="chg">2004. </phrase>This version of the
UDDI Version 3.0 is
<phrase diff="del">http://uddi.org/pubs/uddi-v3.0.1-20031014.htm. </phrase><phrase diff="add">http://uddi.org/pubs/uddi-v3.0.2-20041019.htm.
@@ -1707,4 +1708,12 @@
Web Services Reliable Messaging, Web Services Reliable Messaging Policy Assertion,
WS-SecurityPolicy and WS-Trust references.
</td></tr><tr diff="add"><td colspan="1" diff="add" rowspan="1">20071026</td><td colspan="1" diff="add" rowspan="1">ASV</td><td colspan="1" diff="add" rowspan="1">Updated <specref ref="change-description"/>.
+ </td></tr><tr diff="add"><td colspan="1" diff="add" rowspan="1">20071029</td><td colspan="1" diff="add" rowspan="1">ASV</td><td colspan="1" diff="add" rowspan="1">Incorporated Chris' proposed resolution for
+ issue <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5218" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">5218</phrase></loc>: drop the
+ second sentence in <specref ref="bp-semantics-multiple-same-type"/>, "If there are multiple
+ instances
+ of a policy assertion type in the same policy alternative without
+ parameters and nested policies, these have the same meaning as a
+ single assertion of the type within the policy alternative." Editors' action
+ <loc xmlns:xlink="http://www.w3.org/1999/xlink" href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/384" xlink:actuate="onRequest" xlink:show="replace" xlink:type="simple"><phrase diff="add">384</phrase></loc>.
</td></tr></tbody></table></inform-div1></back></spec>
\ No newline at end of file
Received on Monday, 29 October 2007 17:55:42 UTC