RE: T2 Clarify TimeToLive

[David Fischer <david@drummondgroup.com>]

>>  I think adding this to the spec as a non-normative note is a good idea.

Very Good.  I mostly realized the potential for problems when I realized this
could cause a recalculation of the signature.  I guess the answer is:

	TimeToLive  >  SendTime + (Retries * RetryInterval)

David Fischer
Drummond Group.

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Tuesday, September 11, 2001 11:50 PM
To: 'Arvola Chan'; David Fischer; ebXML Msg
Subject: RE: T2 Clarify TimeToLive


Currently TimeToLive is defined in section 8.4.6.4 as ...

The TimeToLive element indicates the time by which a message should be
delivered to and processed by the To Party.

... and in section 10.2.3 as ...

The TimeToLive value indicates the time by which a message should be
delivered to and processed by the To Party.

What I think you are suggesting is that we provide guidance on how it should
be set. There are two factors which can affect this:
1. Setting it to a value long enough so that it is longer that the time
required to do all the retries on all the hops between the From and To
Parties. By definition this is not precisely computable.
2. Setting it to a value that makes sense in a business context, e.g. if
this PO gets there in a day then it is fine.

I think adding this to the spec as a non-normative note is a good idea.

David

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Tuesday, September 11, 2001 5:12 PM
To: David Fischer; ebXML Msg
Subject: Re: T2 Clarify TimeToLive


David:

I agree with you that we need to clarify in the spec how TimeToLive
should be set for a given message. For reliably delivered messages,
I don't think we want to reset the the TimeToLive on every retry. It just
incurs unnecessary signature recomputation overhead. I would suggest setting
TimeToLive to current time (for the initial attempt) + (retry + 1) *
retryInterval. This must also be less than the receiver MSH's persist
duration.

For messages delivered by BestEffort, the TimeToLive can either be
omitted, or perhaps set to the current time plus the
RequestingBusinessActivity's or RespondingBusinessActivity's
timeToReceiveAcknowledgment.

Cheers,
-Arvola

-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Date: Tuesday, September 11, 2001 4:52 PM
Subject: T2 Clarify TimeToLive


I don't know if this is a problem or not.  TimeToLive is a time, not an
interval, and should probably be set to current time plus 1/2 RetryInterval
(half of the round trip from sender to receiver back to sender).  Won't this
have to be recalculated each retry?  Won't this invalidate the signature?

Maybe I'm getting the correct value of TimeToLive wrong?  What in the world
should this be?  Maybe this is more along the lines of "This PO is valid for
30
days" so this value should be set to current time plus 30 days?  In any
case, we
probably need to clarify the spec.

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>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>