[i021]: a proposal

[Jacques Durand <JDurand@us.fujitsu.com>]

Proposal for i021:

 

Instead of the finer-granularity attachment of policies (e.g. at message level) option, would propose the other option that is more in line with the intuitive scoping of policies, which are generally understood as applying to messages sent to the endpoint (and not sent by).

 

After Line 187 in Oct 6^th WS-RM Policy doc:

 

"As seen above, elements of an RM Policy assertion may concern the behavior of either an RM Source (e.g. wsrm:BaseRetransmissionInterval), or of an RM Destination (e.g. wsrm:AcknowledgementInterval). When attached to a service endpoint, although the endpoint may alternatively act as a Source and a Destination for operations that use both input and output messages, an RM Policy assertion will by default only apply to this endpoint in its Destination role. By default, any client to this endpoint must comply with the RM Policy assertion elements that concern the Source role."

 

That would be the minimal update needed to remove ambiguity.

 

Other side of the issue 021: how do we attach a policy to a service endpoint that governs output messages - say, a service endpoint is requiring its clients to use RM protocol and send back Acks with some AcknowledgementInterval T (possibly different from the policy assertions that govern the input messages)?

 

Proposal is to add an attribute to wsrmp:RMAssertion element: @scope.

- If @scope="in" (default) then the assertion applies to input messages only (service endpoint acting as RM Destination)

- If @scope="out" then the assertion applies to output messages only (service endpoint acting in RM Source role).

- if @scope="inout" then the assertion applies to both input and output messages.

 

 

I'll draft the formal proposal for that schema update after getting some feedback on the idea.

 

-Jacques