Re: [cti] timestamp proposal for STIX 2.0 RC3

["Wunder, John A." <jwunder@mitre.org>]

Eric,

Just to be clear, our current approach is the RFC3339 profile of ISO8601, which doesn’t allow arbitrary precision. We did an investigation of support for ISO8601 arbitrary precision across a bunch of different libraries and it was very poor, which is why we ended up with RFC3339 and a separate precision field.

There’s a separate ballot (two ballots are now open) for whether we add a separate precision field to support this use case. Consensus on the list has been that we do not need to support precision at this point.

John

On 12/13/16, 9:53 AM, ", Eric Burger on behalf of Eric Burger" <cti@lists.oasis-open.orgewb25@georgetown.edu on behalf of Eric.Burger@georgetown.edu> wrote:

    #1 is simple because people are familiar with it and has been in use for decades. It also allows for arbitrary precision. What am I missing?
    
    In fact, how will any of the epoch mechanisms handle “it happened in 2015”? That is pretty straightforward with ISO8601.
    
    > On Dec 13, 2016, at 12:48 AM, Terry MacDonald <terry.macdonald@cosive.com> wrote:
    > 
    > I would also say that one of the guiding principles that I thought we were using in this TC was one of simplification, and another of confusing on the 80%. Both were agreed at a past F2F from memory.
    > 
    > It certainly feels like this discussion/series of proposals is aligning with neither.
    > 
    > Will the original proposal cover 80%of the use cases?
    > 
    > Cheers
    > Terry MacDonald
    > Cosive
    > 
    > On 13 Dec. 2016 02:32, "Eric Burger" <Eric.Burger@georgetown.edu> wrote:
    > 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.
    >> 
    > 
    >