editorial update for Respond / Notify RMP operations

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

Title: editorial update for Respond / Notify RMP operations

Proposed (revised) updates for introducing the Respond operation, and Notify extension:
(As opposed to the one I proposed before, this new update does not preempt
the handling of some of Doug's summary items, e.g. does not assume an "underlying
request-response" protocol) 

Reminder: The intent behind the recent proposal to add a "Respond" abstract operation
to the RMP, was to specify how the RMP must treat user-level MEPs that correlate responses and requests
such as (but not restricted to) WSDL request-response operation types.
"Notify" is also enhanced so that it may deliver a payload to a Producer
(not just failure notices).

Note: introducing Respond / Notify as a new RMP-to-RMP communication channel,
has more editorial implications on how the RMP uses the underlying protocol
and how the RMP maps to WSDL operation types.
This will be detailed separately.

Jacques

---------------------------------------------------------------

1. Add definition (Terminology section):
Respond:
"An abstract operation supported by the RMP. When invoked, the operation transfers payload data from the Consumer to a Receiving RMP, that is related to a previous payload received by the RMP and passed to the COnsumer via "Deliver". "

Notify: Add at the end:
"..., or passes to the Producer a payload sent back by the Consumer."

2. Add the following subsection in Messaging Model section (under 2.1):
Properties of Operations invocation:
"In order to act in both sending and receiving roles, an RMP MUST implement the four abstract operations Submit, Notify, Deliver and Respond. An  RMP MUST be able to correlate a Respond invocation with a previous Deliver invocation. When the Deliver operation is invoked for a payload, a receiving RMP MUST know whether a related Respond invocation is expected."

3. Ignore the previous update proposed for 2.2.1. A more complete definition of the options for mapping the "Respond" invocation to the underlying protocol MEPs (and how that affects the bundling of RM Reply with business response) need be introduced.

4. In Section 3.2:
Unless we have time to address the reliability of payloads submitted via "Respond",
I suggest we add a scoping statement at the end of the QoS subsection of each reliability feature
 (Sections 3.2.1, 3.2.2, 3.2.3) (because so far, we only describe relaibility of  payloads submitted via "Submit"):
"In the current specification, the [ XYZ, e.g. Guaranteed Delivery] agreement is defined  for payloads passed to the receiving RMP via  the Submit operation. Although the [XYZ] agreement may etend to payloads submitted via Respond, some binding cases with the underlying protocol require a special handling not describes in this specification."

5. Latest updates proposed for Table 5.2 should not be done, until 5.2. fixed separately.