Re: [cti] timestamp proposal for STIX 2.0 RC3

[Eric Burger <Eric.Burger@georgetown.edu>]

Notwithstanding we decided this last January, for all the reasons we discussed then, #1 still works.

I will easily concede #3 is workable and has some benefits as enumerated by Jason (the fact that for most date arithmetic, you will be using epoch dates anyway). However, note my emphasis on most. I would also offer that there are libraries out the wazoo for most every language and platform that converts between epoch dates and ISO8601 dates, so the argument that everyone has epoch falls flat. Everyone also has ISO8601.

As for #2 & #4, remember you will be receiving strings, not numbers, over the wire. As such you have to be able to digest a malformed STIX document. As such you will be doing character-by-character analysis no matter what. Moreover, what will you do when you receive a STIX document with a timestamp that has ‘unacceptable’ precision or date ranges? Send back a TAXII error? Drop the entire document on the floor? Try to ‘fix’ it?

On Dec 7, 2016, at 1:04 PM, Wunder, John A. <jwunder@mitre.org> wrote:

1.       Keep the old ISO8601 format, no limits on acceptable dates.

2.       Keep the old ISO8601 format, but add limits on acceptable precision and date ranges.

3.       Use this new epoch format, no limits on acceptable dates.

4.       Use this new epoch format, but add limits on acceptable precision and date ranges.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail