[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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. -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Tuesday, November 06, 2001 11:12 AM To: David Fischer Subject: RE: [ebxml-msg] Since we are talking about TimeToLive, the comparing has to be done by the MSH receiving the message. If the time of sending is in the message header, your words are logically OK though not necessarily the most understandable. If the time of sending is NOT in the message header, than the time origin that I pointed out still exists. However there is still the problem that I pointed out in the second paragaph. Retry interval is not fully defined and there is nothing that defines the time from when the message was sent until the first retry. If one assumes that the message sender keeps track of the time of sending each retry, then the only remaining question is whether the product is RetriesXRetryInterval or (Retries-1)XRetryInterval. Actually, the receiving MSH only has to compare the time of receiving a message to its TimeToLive, thus avoiding the whole question of time origins. 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 11:20:05 AM To: Martin W Sachs/Watson/IBM@IBMUS cc: Arvola Chan <arvola@tibco.com>, ebXML Msg <ebxml-msg@lists.oasis-open.org> Subject: RE: [ebxml-msg] OK, please give me some words. IMO, when it says SINCE that means Add. If you don't agree, please tell me what to change this to. Regards, David. -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Tuesday, November 06, 2001 10:08 AM To: David Fischer Cc: Arvola Chan; ebXML Msg Subject: Re: [ebxml-msg] You are still comparing a date and time to an interval. You need to either convert TimeToLive to an interval since some date-time origin or add a date-time origin to Retriesx RetryInterval. In addition, the comparison has another problem: The time from the initial message to the first retry is undefined. The specs (MSG and CPA) do not define the timeout used following sending the message and they do not say whether RetryInterval applies to the time before the first retry or only to the time between retries. 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 10:26:33 AM To: Arvola Chan <arvola@tibco.com> cc: ebXML Msg <ebxml-msg@lists.oasis-open.org> Subject: [ebxml-msg] Spec section 7.4.5: TimeToLive MUST be greater than the product of Retries and RetryInterval since the message was originally sent. Your comments: You cannot directly compare a dateTime quantity against a duration quantity. This does not directly compare. TimeToLive is compared to (Retries * RetryInterval) SINCE the message was originally sent. I believe this is correct. How would you prefer to say this? Regards, David Fischer Drummond Group. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC