[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg]
Then it seems that we are OK regarding processing TimeToLive. 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 03:38:53 PM To: Martin W Sachs/Watson/IBM@IBMUS cc: Dan Weinreb <dlw@exceloncorp.com>, arvola@tibco.com, ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] When the message is resent, it is not repackaged so the timestamp does not change. If we change the timestamp we would also have to rebuild the signature (we don't want to do that). Regards, David Fischer Drummond Group. -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Tuesday, November 06, 2001 12:44 PM To: David Fischer Cc: Dan Weinreb; arvola@tibco.com; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] Interesting question. If the time the message was created is in the header, then at first sight, TimeToLive should be left as is so that a recipient can directly compare TimeToLive to the time the message was created. However... when a message is re-sent due to a timeout, what is the time the message was created? If it is the time the original message was created, all well and good. If it is the time the retry was created, we have a problem because it will appear that TimeToLive starts over again with each retry. 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:38:32 PM To: Martin W Sachs/Watson/IBM@IBMUS, Dan Weinreb <dlw@exceloncorp.com> cc: arvola@tibco.com, ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] OK with me. MessageData already has a Timestamp element which is the time the message was created (section 3.1.6.2). Shall I change TimeToLive to an Interval? Regards, David Fischer Drummond Group. -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Tuesday, November 06, 2001 11:13 AM To: Dan Weinreb Cc: david@drummondgroup.com; arvola@tibco.com; ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] If we change TimeToLive to an interval, we also need to add the time the message was originally sent to the header if it isn't there already. 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 ******************************************************************************** ***** Dan Weinreb <dlw@exceloncorp.com> on 11/06/2001 11:32:23 AM Please respond to Dan Weinreb <dlw@exceloncorp.com> To: Martin W Sachs/Watson/IBM@IBMUS cc: david@drummondgroup.com, arvola@tibco.com, ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Date: Tue, 06 Nov 2001 11:07:52 -0500 From: Martin W Sachs <mwsachs@us.ibm.com> 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. It's really too bad that we have a field called "TimeToLive" whose value is a date/time rather than an interval. The phrase "time to live" strongly suggests an interval, as in: "You have only this much time left to live" or "Unfortuantely for you, Mr. Bond, your time to live is only three minutes, after which this bomb will go off! Ha, ha ha!" The Java JMS specification uses timeToLive as the name of a paramter that is interpreted as an interval (a number of milliseconds). The Netscape LDAP Universal Schema contains "ttl (time to live)", an interval (in seconds). The International Telecommunication Union published a note called "Expiration Dates for H.323 Endpoint Registrations", saying: n AVC-1159 it was proposed that an optional Expiration Date be added to the RRQ and RCF messages. Because using an absolute time requires synchronization of clocks between the endpoint and the gatekeeper, the name ExpirationDate is changed to TimeToLive and the definition is changed to be the number of seconds that the registration is to be considered valid. By using TimeToLive to mean an absolute time, we are going against the rest of the industry. Is there any chance that we could come up with an improved name for this field? ---------------------------------------------------------------- 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> ---------------------------------------------------------------- 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