Re: [wsrm] Rel 33 and Rel 50, follow-up

[Tom Rutt <tom@coastin.com>]

Jacques Durand wrote:

> Following-up to last call, for our spec editor:
>  
> 1. I propose that we format the resolution of Rel 33 as a set of two 
> definitions in the Terminology section
> (which I suggest should be renamed Definitions section, as it is not 
> just about setting the vocabulary,
> but also introducing precise and new semantics):
>  

I have a few comments, inline.

>  
> *Message Delivery*:
> Action of transfering the responsibility of processing further a message,
> from the RMP and onto the next processor entity. This action marks
> the end of the RMP processing for this message. The time at which this 
> action
> occurs must be clearly indentifiable so that the next message processor
> can always establish in which order two deliveries are made.
> Examples of delivery are: pushing the message in a queue accessible by 
> an application,
> calling back an application component, storing the message in a 
> database where
> it is accessible by the next processor.
>  
> *Acknowledgement*:
> An acknowledgement is a message containing an RM:Response element 
> referring
> to at least one previous message (and containing no RM:Fault element).
> An acknowledgement means that the acknowledged message has been 
> completely and
> successfully delivered (see Message Delivery).

This sounds too strong
Something like the following (with wordsmithing required)
" An ack means that the acknowledged message has satisfied all the 
ws-reliabiliy requirements placed on it for delivery, and the receiving 
user has accepted the responsibility for completion of delivery, using  
the mechanism specified in its contract with the Receiving Reliable 
message processor.."

>  
>  
> 2. Here is the rewording of Rel 50 that was requested before it was 
> approved, again formatted as a Definition item.
>  
> *ExpiryTime*:
> As a mandatory element for each message, ExpiryTime indicates the 
> ultimate time
> after which the receiver RMP MUST NOT deliver a received message to 
> the application.
> After a message has been sent for the first time, ExpiryTime in a message
> MUST NOT be modified in any case by the Sender, when resending the 
> message:
> two messages with same ID (i.e. duplicates) MUST have same ExpiryTime.
> When a message expires on the Sender side before being either 
> successfully sent or acknowledged,
> a Sender RMP MUST NOT send it or resend it, and must communicate a 
> delivery failure
> to the Sender application.
> NOTE:
> - Given the above definition of ExpiryTime, in case duplicate 
> elimination is required,
> when a received message is processed, it is sufficient to only check 
> for its duplicates
> among IDs of past messages that have not expired yet at the time of 
> the duplicate check.
>  
>  
>  
> Jacques
>  
>  



-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133