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

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 []

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".