Re: Comments on reliable messaging draft specification

[Christopher Ferris <chris.ferris@east.sun.com>]

All,

My comments below.

Chris

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:
> 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

David/All, 

I believe that what David describes above is what we discussed
in Burlington. An Ack is returned to the sender regardless of whether the message
is deemed to be a duplicate by the recipient.

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

The description in RM seems more prescriptive, but the header spec
specifically states that "the message id shall conform to RFC2111". This
seems to me to be more than enough detail! I don't think that we
need to be offering redundant information. We want the document
to be succinct.

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

Again, as we discussed, a message should never me modified. Section 2.4
needs to be revised to make this clear. At present, the sequence of 
steps to be taken would lead to a case where a message could be sent
multiple times and there could be no means of detecting it as a duplicate.

Before line 132 there should be a preliminary step:

1) create message, assign messageId and recoveryCounter
2) store...

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

My take is that it belongs in a TPAConversation instance. 

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

Then it would be a different TPA! I would like to see a specific use case(s)
which would have the *application* twiddling around in this area on a 
message by message basis. If these exist, I would agree to adding it to
the header. Otherwise, ttl applies and it need not be in the message.
There's no reason why an implementation couldn't store this value with
the message in persistent store so that it could optimize the GC function.
It doesn't seem to me that it is necessary to carry it in the header to
accomodate the sending party's implementation. The problem with a timestamp
is that for it to be effective, there needs to be an agreement as to
what time it is!

> 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 ;-)

We (you and I) have already addressed this. I believe that these belong
in the TPA. In our proposal (which I covered in the f2f in Burlington)
these were described as being in the TPA. If not mistaken, they are
already covered in tpaML 1.0.6 for the most part.

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

Agreed, but it would seem to me that in such a case that the window count
would be 1, and everything else works the same.

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

Agreed. This needs to be made explicit.

Lines 181-186
I think that it needs to be made more explicit as to the handling
of the messages to be resent. Is the window the same (yes)? Are the
recovery counters the same (yes). What is the behavior of the receiving
party's system when receiving messages resent in response to an error?

> 
> 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?

RecoveryNo is not unique unless it is qualified with the windowId for
which there is no provision. It would seem to me that there would need
to be some provision given for this, otherwise, implementations which
choose to use the suggested idempotency scheme *might* treat a stale
message (which hasn't expired) which was effectively lost, resent and then
subsequently "found" as a NEW message instead of a duplicate and the
actual "NEW" message would be treated as a duplicate and discarded!!!

> 
> Lines 198 & 199
> ---------------
> I'm not sure this is sufficient. See response to Section 2.1 above.
> 
> That's it !!
> David
> 
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
> Sent: Wednesday, July 26, 2000 12:52 PM
> To: ebxml transport
> Subject: reliable messaging draft specification
> 
> All,
> 
> I am posting Fujitsu's draft of the reliable messaging spec
> at the request of Jim Hughes because he's having problems
> posting to the alias.
> 
> Cheers,
> 
> Chris
> 
> >Attached is a PDF copy of a draft Reliable Messaging Specification, based
> >on the presentation made by Fujitsu in the Burlingame meeting. I believe
> >we will spend time on this in the August meeting, but it may be useful to
> >take comments via email or in the weekly teleconferences before then.
> >
> >Regards,
> >
> >Jim Hughes
> >Fujitsu
> 
> --
>     _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
>    _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
>   _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
>        _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
> _/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903

-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903