[wsrm] Proposed clarificaiton resolutions to Ferris comments 1,2

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

Title: [wsrm] Proposed clarificaiton resolutions to Ferris comments 1,2

Tom:

inline <JD>,
suggested updates on your proposal responding to Chris F. (here, for comments #1 and #2 only).

It also appears that our definition of "Notify" in Section 1.5 is too general, as we never intended to use Notify
to report on successful deliveries - as Chris assumes - but only on failed deliveries, as described later in the spec.
So I narrow it accordingly in 1.5 below.

-Jacques

-------------------------
From: Tom Rutt [tom@coastin.com]
Sent: Wednesday, July 14, 2004 1:59 PM
To: wsrm
Subject: [wsrm] Proposed clarificaiton resolutions to Ferris comments
1,2,24,5,7,9,16,19

Proposed resolutions for some of Chris Ferris comments on WS-Reliability
ED 1.05:

Comments 1, 2, 24: Need to clarify that no implementation details are
prescribed for abstract RMP operations:

Proposed clarification:

Add at the end of line 85 the following sentence to the qos bullet:

"

These abstract operations are associated with processing of an RMP,
however implementation aspects regarding how, or when, they are invoked
are not prescribed by this specification.

"
<JD> I think we need an even more explicit statement, for addressing comments 1,2 from CF:
" These operations are abstractly defined here as transfer of information
(message payload, error notice) between the RMP and external components (Producer, Consumer).
This specification makes no requirement on how these operations should be implemented,
and by which component. Defining the reliability QoS contracts does not require
more concrete definitions, which are left to implementations. "
I would place the statement in the "Note" after Figure 1, replacing and expanding
on sentence in line 110 (" The interpretation of these operations is a matter
of implementation.")
Although these ops are first mentioned in line 85, this reference is very general
and does not call for such a detailed adjustment that early. In line 85, I would just
add "These operations are defined in Section 1.5".

Add the following new paragraph between lines 105 and 106, before the Note

"

The direction of the arrows for the qos contract abstract operations,
shown in Figure 1, represents the direction of information flow
associated with the operation. Implementation details of how these
operations are invoked, including which entity invokes the abstract
operation, are not prescribed by this specification.

<JD> OK, but I would remove second sentence if we use my
previous rewording, as it is redundant.
 
"

Lines 182-198: generalize the definitions of the four abstract operations

"

...

"

with the following:

"

Deliver:

An abstract operation associated with a Receiving RMP. When invoked, the
operation makes the payload of one Reliable Message available to the
Consumer from the Receiving RMP. For example, in one specific
implementation choice, the payload is placed into a queue by the
Receiving RMP to be consumed by an application component.

<JD> The "associated with a Receiving RMP" might still be misinterpreted.
I would replace 1st sentence with:
"An abstract operation that controls a transfer from Receiving RMP to Consumer."

Submit:

An abstract operation associated with a Sending RMP. When invoked, the
operation transfers payload data from the Producer to the Sending RMP
(e.g., a request to the Sending RMP to take responsibility for the
Reliable Message).

<JD> I would replace 1st sentence with:
"An abstract operation that controls a transfer from Producer to Sending RMP."

Respond:

An abstract operation associated with a Receiving RMP. When invoked, the
operation transfers payload data from the Consumer to a Receiving RMP.

<JD> I would replace 1st sentence with:
"An abstract operation that controls a transfer from Consumer to Receiving RMP."

Notify:

An abstract operation associated with a Sending RMP. When invoked, the
operation makes available a response payload received by the Sending
RMP, to the Producer, or makes available to the Producer the status of a
Reliable Message (e.g., a notification that the Sending RMP failed to
send a Reliable Message).

<JD> similarly,
"An abstract operation that controls a transfer from Sending RMP to Producer."
plus a narrowing: replace "the status" by "the failure status".