Re: [cti] timestamp proposal for STIX 2.0 RC3

["Back, Greg" <gback@mitre.org>]

Of the two proposals, I prefer Proposal #1 to option #2.

 

But despite the performance numbers, I still prefer for the RFC 3339 string date representation; in my mind, it’s less ambiguous than a numeric timestamp, regardless of how well we specify whichever numeric format we choose. I expect the true performance impact to be minimal in the context of a real application that reads or writes data from/to a database or performs any sort of network activity. Sadly, it’s much harder to benchmark that scenario. If you have an application that is transferring massive volumes of STIX data (which I still don’t fully understand the use case for; I feel like STIX is the wrong hammer for that particular nail), I feel it’s unlikely you’re decoding JSON into memory and then re-encoding it again anyway. At that level both RFC 3339 and numeric timestamps are both just sequences of characters in JSON.

 

I’m not too concerned about the leap-second issue, but then again I’m not too concerned about supporting resolution finer than milliseconds. I just don’t see the practical value in being able to distinguish things that happened within the same millisecond. That said, if we support any form of fractional seconds, supporting higher precision (from a spec perspective) has minimal impact.

 

In the end, though, I’ll happily accept whatever the consensus opinion is. I think the marginal benefit of any approach over any of the others is minimal.

 

Greg

 

From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, December 1, 2016 at 4:19 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] timestamp proposal for STIX 2.0 RC3

 

Hi All – As discussed on the working call on Tuesday I took the action to come back with an updated proposal on how to represent timestamps numerically instead of requiring the string representation as is currently defined in STIX 2.0 RC3.

 

Please find attached the proposal(s).

 

Proposal #1 is the preferred approach but including 2 options for consideration to see if others have a different preference.

 

Thanks to the Greg Back from the Mitre team for doing some quick performance testing on string vs numerical based timestamp processing. I’ve included the results in the slide deck for support.

 

Regards

 

Allan