David,
First of all, the sending MSH does care about the interval. RetryInterval
was invented on the assumption that people would set it long enough so that
a transient condition that might have caused the message to be lost might
have a chance to correct itself before the retry.
We don't say anything about the time to the first retry - that's the
problem. The timeout that the MSH uses is an implementation matter and
isn't specified. RetryInterval might be longer or shorter than that
timeout. If RetryInterval is shorter than the timeout, the timeout
controls; if RetryInterval is longer, RetryInterval controls. However in
any case, we don't say what determines the time to the first retry.
Now that we understand that TimeToLive can be processed without using
RetryInterval, the initial time to retry is a non-issue for TimeToLive.
However, I had submitted an issue about the initial time to retry with
regard to calculating the time to decide that a delivery failure has
occurred. I believe that that issue is still open.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
David Fischer <david@drummondgroup.com> on 11/06/2001 12:54:51 PM
To: Martin W Sachs/Watson/IBM@IBMUS
cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Subject: RE: [ebxml-msg]
I'll do whatever you guys tell me. The create time is in the MessageData.
I
have already struggled to find some understandable words and obviously I
have
failed. OTOH, much of this goes away if we change TimeToLive to an
Interval?
Your other concern. . . isn't the time to the first Retry still
RetryInterval?
I assume that the Sending MSH doesn't really care when the last Retry was
sent.
What it really cares about is a multiple of RetryInterval since the message
was
originally sent/created. The system would keep a RetryCount parameter and
then
send the next Retry when RetryCount * RetryInterval (SINCE create time) had
passed. OTOH, if a Retry were late due to some problem (system crash. . .)
then
this could mean multiple Retries at the same time. . .hmmm. I think this
is an
implementation detail and we don't have to solve it.
Your point about comparing TimeToLive to Receive time is correct. The
Receiving
MSH would have to add TimeToLive to the MessageData+Timestamp if we change
TimeToLive to an interval. We have to keep in mind that TimeToLive is
since
message creation, not since the last send.
Regards,
David Fischer
Drummond Group.