Subject: RE: Time-stamp server. TimePrecision info

From: Paul Halliden <[email-masked]>
Date: Thu, 1 Apr 1999 17:51:49 +0100

I quite agree that hours may not be close enough in some cases. The point is
that the spec specifically talks about a range of communication techniques
between requester and TSS including e-mail which has a notoriously variable
transit time.  The timestamp gives no indication about how long the
requester's message took to get to the timestamp authority.  Even if it did,
I don't believe that the authority would be in any position to know reliably
at what time the request was made.  Thus anyone who relies on a sequence of
timestamps to indicate order is deluding themselves if they want precision
anywhere near the transit time of the network(s) used. I would expect the
timestamp authority's policy to say its service was unsuited for such
precise sequencing and that some other technique for establishing the
sequence of transactions should be used.

Paul

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: 01 April 1999 17:05
To: [email-masked]
Cc: [email-masked]
Subject: RE: Time-stamp server. TimePrecision info

I suspect that "close enough" may change over time, and hours may not
be good enough.  For example, the required accuracy for timestamps on
stock trading messages is more likely to be minutes rather than hours
even today.

In any case, it helps to be consistent.  If hours or even minutes is
the outer limit of resolution needed, them milliseconds have no place
in the timestamp format.

As for establishing order by having a second document include the
older timestamp of the first document, that's fine if I generate both
documents.  If the dispute is on which of the two of us generated our
document first, then we'll be dealing with two independent timestamps
presumably from different servers.  If they aren't synchronized to UTC 
any better than hours, the service will not be useful in a number of
interesting cases. 

Finally: it's a bad idea to make the specs tighter than what is
achievable, but it also doesn't make a whole lot of sense to make them
4 orders of magnitude looser.  Synchronizing to UTC to within a
fraction of a second is easy, and network round trip times are in the
range of seconds (actually, often way smaller than that).  Yes, that
opens the question of how you handle leap seconds.  One solution is to
loosen things up some more, but going from seconds to hours is really
not necessary.

	paul

---

From: Paul Koning <[email-masked]>
Date: Thu, 1 Apr 1999 12:25:34 -0500

>> Paul Halliden wrote:

I don't see that the transport matters.

No matter what transport you use, the only thing the timestamp tells
you is the time at which the server generated the stamp.  The
requester obviously issued the request before that, but you cannot
know how much before that.

Similarly, a sequence of timestamps shows sequence of timestamping,
not sequence of request generation.

If I need a timestamp to show that I did X by time Y, I'd use a
transport with low enough latency to meet my needs.  What that latency 
is, is a decision I have to make, but it doesn't matter to the server.

	paul