Re: [cti] timestamp proposal for STIX 2.0 RC3

[Michael Chisholm <chisholm@mitre.org>]

On 12/7/2016 11:36 AM, Bret Jordan (CS) wrote:
> So we are trying to define support up to picoseconds?  Do we really need that at this point?  Or are microseconds sufficient for now?
>
>
> If we do picoseconds and someone stores this data in a float64 and that truncates the data, does that invalidate it or cause something to blow up?
>
>
> I really do not want to design something that is either not going to work in code or is going to be very counter intuitive to a developer.
>
>
> Picking the number  "4102462800 " seems very arbitrary to me.

I don't think we should tell people how to write their code, including 
whether to use an IEEE-754 double-precision float representation or 
something else.

Perhaps what you're really getting at is all the integral values in that 
range should be exactly representable, and perhaps a few digits to the 
right of the decimal point.  Some normative text regarding 
approximation/truncation might be in order.

The same consideration could be given to all numeric types.  Every float 
could be subject to some truncation, and every number subject to 
bounds-checking by a particular implementation.  I've often thought that 
although you shouldn't mandate implementation, it's probably wise to 
mandate some minimum range/precision, to ensure a minimum level of 
interoperability.  Choosing greater range/precision could be an 
opportunity for products to distinguish themselves...?

On the other hand, the "no better than picosecond precision" restriction 
is an upper bound (on neither range nor precision [in the IEEE-754 
sense], but is a bound of a sort).  Why is that upper bound needed?  Why 
not let tools express additional fractional digits if they want, and 
allow implementations to ignore excess fractional digits (up to a point) 
if they want to?

Hmm... just noticed the STIX spec defines the float type as IEE 754 
double-precision numbers too.  Not sure if that is saying that 
implementations must represent floats that way, or if it thinks that's 
somehow the same thing as a real number (it says "a number with a 
fractional part").  I don't agree with either of these.  I think the 
value space should be real numbers, and the spec should probably give 
some minimum range/precision restrictions as described above.  That 
might rule out some implementations, but not force anyone into any 
particular implementations.  And the IEEE-754 representation is *not* 
the same as a "number with a fractional part".  The representation comes 
with certain consequences for range/precision, and can't represent any 
old number with a fractional part.  (The restriction on Inf and NaN is 
probably wise though.)

Andy