Re: Comments on reliable messaging draft specification

[Jim Hughes <jfh@fs.fujitsu.com>]

David -

My comments on your comments sent before the F2F... We covered some items 
during the F2F  discussions...

Jim

At 04:57 PM 8/4/00 -0700, David Burdett wrote:
>Folks
>
>Here are some initial comments/questions on the reliable messaging spec.
>
>David
>=========
>Section 2.1 Base Concept
>------------------------
>This doesn't say what you do when an ack is sent by the recipient of a
>normal message(s) but the ack get's lost. From my reading of the spec I
>think what happens is:

In Reliable Messaging, the only ACK we discuss is the ACK from the 
Receiver' Messaging Service Handler to the Sender's Messaging Service 
Handler. If this ACK gets lost, the Sender will retry [TBD] number of times 
before reporting the error to its higher level. The interface for reporting 
errors upwards is not yet defined...

>a) sender resends original normal message(s)
>b) recipient recognizes the normal message as a duplicate and discards it
>Perhaps the recipient, if they receive a duplicate normal message should
>resend the ack that was previously sent as otherwise they will never know if
>their resent message got through. We also need to think about the need for
>single threading of the recording of message ids etc so that duplicate
>messagess are properly recognized

Synchronization happens between Reliable Messaging Groups ("RM-Groups", 
formerly "Windows"). RM-level ACKs are only sent in response to the final 
message of an RM-Group. The Receiver will never send an ACK unless it has 
received all messages in the group (otherwise, it will send an error 
message). At this point the Receiver will assume that the group is closed 
and will be ready to start a new group of messages. As you suggest, maybe 
the Sender never gets this closing ACK from the Receiver, so it will 
timeout and try again to send the last message (final message of the 
previous group). The Receiver should be able to recognize that this message 
is a repeat of the previous attempt to close, and repeat the ACK to the 
Sender... so we may need to have a clear path to describe what happens.

Let me think about it a bit more. I'll put a placeholder in the spec to 
mark this issue.


>Table 2-1 Message Data Element - Message Identifier
>---------------------------------------------------
>The outline description of Message Identifier is much more prescriptive
>about what it should contain than the current (v0-63)version of the header
>spec. We need to make them consistent.

Going in that direction!

>Table 2-1 Message Data Element - Recovery Number
>------------------------------------------------
>a) The spec isn't clear whether recovery number is increased if you re-send
>a message. My guess is that it isn't.

Correct. SequenceNumber is the same.

>b) Is Recovery Number always increased - and what do you do if you receive a
>message that has a lower number than any of the ones you are currently
>processing in the Window. This could occur, for example if a message get's
>trapped in an email server somewhere. You possibly might want to ignore it
>or maybe you are trying to get a response to an earlier message that was
>lost.

At one time, we asked for monotonically increasing SequenceNumbers. Now, 
they just need to be unique within the Sender-Receiver-Transport space. We 
don't imply serialization of messages within an RM-Group of messages.


>Table 2-2 Reliable Messaging Info Element
>------------------------------------------------------------------------
>I think this is a topic we need to discus in the F2F next week. But some of
>the things we might want to think about are:
>a) Should Message Expiration Timestamp be in the TPA or in the header. If it
>can be expressed as a TTL and doesn't change then you could put it in the
>TPA. OTOH, Message Expiration Timestamp might be something that the
>application that is using ebXML TRP might want to specify, in which case it
>should be in the header.
>b) Do we want to add other information in here or in the TPA, specifically:
>   i) Retention Period - how long you keep the message before deleting it for
>reliable messaging purposes
>   ii) Retry Interval - how long you wait before resending a message
>    Both of the above might also need to be specified by the application.
>IMO I think we should tbe able to put he information in either the header or
>in the TPA as then it would also allow TRP to be used without a pre-existing
>TPA (OK I admit that this is one of my hobby horses ;-)
>
>Section 2-4 Message Transfer Sequence
>-------------------------------------
>I think it would also be a good idea to include an example where a single
>message is acknowledged. My guess is that this would be frequent occurrence
>when sending messages by email.

This would be a group size of 1.


>Lines 161 and 164 - Recovery Sequence
>-------------------------------------
>It's not clear that the Recovery Sequence is the one specified in section
>2.6 or some other recovery sequence.
>
>Section 2-7 Detection of Repeated Messages by the Receiver
>----------------------------------------------------------
>It seems to me that the "Message Id" and "FromPartyId" + "ToPartyId" +
>"Recovery No" are both globally unique identifiers for the Message. Do we
>need both?

In the latest spec, SequenceNumber is unique to the 
Sender-Receiver-Transport triple.

>Lines 198 & 199
>---------------
>I'm not sure this is sufficient. See response to Section 2.1 above.
>
>That's it !!
>David