ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: i021: a proposal
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Fri, 13 Jan 2006 19:51:06 -0500
Proposal for i021:
- reduce the RM policy assertion to mean that RM is
supported
<wsrmp:RMAssertion [wsp:Optional="true|false"]?/>
No Optional attribute implies RM is supported
but optional.
- this assertion applies _just_ to incoming messages
- when optional its up to the RMS to decide whether
or not RM is used
- when not optional then RM is required for all messages
to this endpoint
- define a new RMRequired Fault to return when an
endpoint gets a message
that wasn't RM-enabled but requires it to be.
- Define this new fault in the RM spec.
- Add text to the wsrm spec saying that when a message
is sent to
an EPR that contains the <wsrmp:RMAssertion>
element in the
<wsa:Metadata> section then the sender
of the message should use
this information to know whether or not RM
is supported/required.
When sending replies it may not be possible for the
wsa:ReplyTo endpoint
to always expose WSDL to let the RMD know whether
or not it is RM-enabled.
To satisfy this the RMS can include the <wsrmp:RMAssertion>
element in
the wsa:ReplyTo EPR's <wsa:Metadata> element.
As to the current parameters (e.g. MaxMessage#), those
are removed and
will either be placed in the CreateSeqResponse (based
on Paul's issues)
or dropped entirely from the spec. This assertion
is not extensible.
thanks,
-Doug
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]