consolidated i021 proposal

[Christopher B Ferris <chrisfer@us.ibm.com>]

Replace the entire content of section 2.3
(Assertion Attachment) in the WS-RM Policy specification with the following:

The RM policy assertion is allowed to have the following Policy Subjects [WS-PolicyAttachment]:

• Endpoint Policy Subject
• Message Policy Subject

WS-PolicyAttachment defines a set of WSDL/1.1 [WSDL 1.1] policy attachment points for each of the above Policy Subjects. Since an RM policy assertion specifies a concrete behavior, it MUST NOT be attached to the abstract WSDL policy attachment points.

The following is the list of WSDL/1.1 elements whose scope contains the Policy Subjects allowed for an RM policy assertion but which MUST NOT have RM policy assertions attached: 

• wsdl:message
• wsdl:portType/wsdl:operation/wsdl:input
• wsdl:portType/wsdl:operation/wsdl:output
• wsdl:portType/wsdl:operation/wsdl:fault
• wsdl:portType

The following is the list of WSDL/1.1 elements whose scope contains the Policy Subjects allowed for an RM policy assertion and which MAY have RM policy assertions attached:

• wsdl:port
• wsdl:binding
• wsdl:binding/wsdl:operation/wsdl:input
• wsdl:binding/wsdl:operation/wsdl:output
• wsdl:binding/wsdl:operation/wsdl:fault

If the RM policy assertion appears in a policy expression attached to a wsdl:binding as well as to the individual wsdl:binding level message definitions(wsdl:binding/wsdl:operation/wsdl:input, wsdl:binding/wsdl:operation/wsdl:output, wsdl:binding/wsdl:operation/wsdl:fault), the parameters in the former MUST be used and the latter ignored.

If the RM policy assertion appears in a policy expression attached to a wsdl:port as well as to the other allowed WSDL/1.1 elements, the parameters in the former MUST be used and the latter ignored.

If an RM policy assertion is attached to any of:

• wsdl:binding/wsdl:operation/wsdl:input
• wsdl:binding/wsdl:operation/wsdl:output
• wsdl:binding/wsdl:operation/wsdl:fault

then
an RM policy assertion, specifying wsp:Optional=true MUST be attached to
the corresponding wsdl:binding or wsdl:port, indicating that the endpoint
supports WS-RM. Any messages, regardless of whether they have an attached
Message Policy Subject RM policy assertion, MAY be sent to that endpoint
using WS-RM. Additionally, the receiving endpoint MUST NOT reject any message
belonging to a Sequence, simply because there was no Message Policy Subject
RM policy assertion attached to that message. 

There might be certain RM implementations that are incapable of applying
RM QoS semantics on a per-message basis. In order 
to ensure the broadest interoperability, when an endpoint decorates its
WSDL with RM policy assertions using Message Policy Subject,
it must also be prepared to accept that all messages sent to that endpoint
might be sent within the context of an RM Sequence, regardless
of whether the corresponding wsdl:input, wsdl:output or wsdl:fault had
an attached RM policy assertion. 

Rather than turn away messages that were unnecessarily sent with RM semantics,
the receiving endpoint described by the WSDL 
must accept these messages. 

By attaching an RM policy assertion that specifies wsp:Optional="true"
to the corresponding endpoint that has attached RM policy
assertions at the Message Policy Subject level, the endpoint is describing
the above constraint in policy.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295