Re: [cti] timestamp proposal for STIX 2.0 RC3

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

#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.
>> 
> 
>

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