Comments on reliable messaging draft specification

[David Burdett <david.burdett@commerceone.com>]

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

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.

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

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?

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