Subject: RE: Time-stamp server. TimePrecision info

From: Robert Zuccherato <[email-masked]>
Date: Tue, 30 Mar 1999 08:27:06 -0500

Personally, I have no problem with adding an optional timePrecision field to
specify the accuracy of the given time stamp.  I think that in some
applications that can be useful information, particularly when the time
stamp token will be kept for evidence purposes.  However, I really don't
think it would be wise to make the serial number mandatory.  I agree that in
some situations it may be critical for clients to know "who was first" if
the resolution of the timestamp means that they both have the same value for
the time.  But, I don't think that it will be critical in all applications.
Therefore, I would rather not make it mandatory and force its use on those
applications (and TSA's supporting them) where it is not required.

	Robert Zuccherato.

> ----------
> From: 	Michael Zolotarev[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Monday, March 29, 1999 10:38 PM
> To: 	[email-masked]'; [email-masked]'
> Cc: 	'Simon Laing'; 'Andrew Shellshear'
> Subject: 	RE: Time-stamp server. TimePrecision info
> 
> Michael,
> Technically you are right, and I certainly agree that monotonicity is 
> absolutely essential, and assumed. It is accuracy and precision which I am
> 
> trying to address here.
> 
> I believe that when considering what might go into a time stamp, we should
> 
> think in terms of what a user would NEED to know. After all, what matters 
> for a client is
> 1) how trustworthy is the TSA in general, and
> 2) how accurate is the time in that particular time stamp.
> 
> Presenting a customer with extra details, like splitting the quality of
> the 
> time into its precision and accuracy, may unnecessarily overcomplicate the
> 
> issue, without giving much information anyway.
> 
> A reference to the source(s) of time data, available from the TSA's
> policy, 
> should be a starting point for anybody who wants to know more about 
> characteristics of the time.
> 
> Thinking of monotonicity:
> Should the TSTInfo::serialNumber field be OPTIONAL? In addition to serving
> 
> as just an extra proof of monotonicity, which is assumed anyway, the 
> serialNumber may be the only way to resolve a 'who was the first'
> argument. 
> If two requests arrived virtually 'simultaneously', the TSS will generate 
> two time stamps with the same time value. The probability of it depends on
> 
> the resolution of the time source used. It may be critical for the clients
> 
> to know who was actually the first (thinking of on-line betting, auctions,
> 
> etc). This turns the serialNumber into a mandatory field, doesn't it?
> 
> Michael Zolotarev
> Technical Architect, Baltimore Technologies Ltd (Australia)
> 
> -----Original Message-----
> From:	Michael Sierchio [SMTP:[email-masked]]
> Sent:	Monday, March 29, 1999 3:32 PM
> To:	[email-masked]
> Cc:	[email-masked]'; Simon Laing; Andrew Shellshear
> Subject:	Re: Time-stamp server. TimePrecision info
> 
> Michael Zolotarev wrote:
> > ...
> > for example, the policy might state: "The time returned will be accurate
> 
> to
> > within 100ms, and if the time-stamp server cannot
> > provide this level of accuracy, it will not issue a time-stamp."
> 
> It seems to me that there are three qualities of interest for
> timestamps, in increasing order of importance -- precision, accuracy,
> and monotonicity.  The last is essential,  and perhaps more important
> than the other two.
>

---

From: Paul Koning <[email-masked]>
Date: Tue, 30 Mar 1999 11:25:07 -0500

>>>>> "Robert" == Robert Zuccherato <[email-masked]> writes:

 Robert> Personally, I have no problem with adding an optional
 Robert> timePrecision field to specify the accuracy of the given time
 Robert> stamp. ...

 >> ---------- From: Michael Zolotarev
 >> ...we should
 >> think in terms of what a user would NEED to know. After all, what
 >> matters for a client is 1) how trustworthy is the TSA in general,
 >> and 2) how accurate is the time in that particular time stamp.
 >> 
 >> Presenting a customer with extra details, like splitting the
 >> quality of the time into its precision and accuracy, may
 >> unnecessarily overcomplicate the

These sound like good things.  If they are done, though, it would be
very helpful if ambiguous words like "precision" and "accuracy" are
avoided (and in particular, not used as terms intended to describe
*different* things).  What is needed are descriptions of what a
parameter tells you, e.g.,

a. the smallest representable increment in the timestamp (often called
"resolution")

b. the bound on the difference between the timestamp value and the
current UTC ("accuracy"?  "precision"?)

c. whether the timestamp is monotonic (or possibly, if non-monotonic,
the bound on its nonmonotonicity).

Obviously, a < b, and if c != 0, a < c < b.  b is the hardest to
supply, but also the one that's essential if you want to draw
conclusions from timestamps generated by two servers.

	paul