Re: [cti] timestamp proposal for STIX 2.0 RC3

["Mr. Stefan Hagen" <stefan@hagen.link>]

I favour 1, 2, 3, and least 4 of below alternatives.

Top-postingly,
Stefan.

On 07/12/16 19:04, Wunder, John A. wrote:
> So I’ve been thinking a lot about this and it’s very similar to the
> debate where we talked about whether we should limit the max lengths
> that strings could be. We ended up deciding not to add that based on a
> ballot, and while it wasn’t an overwhelming result I think for
> consistency we should continue that pattern here. That would also be
> consistent with the ISO8601 text, which didn’t have any limits.
> 
>  
> 
> I do think that Andy’s point is good and we should provide
> recommendations for what you should support for string limits, max
> number sizes, time precisions, etc. IMO all of that should go in an
> implementer’s guide.
> 
>  
> 
> If this ends up biting us later we can add the limits as normative
> requirements in a later version. Going down this path would lead to:
> 
>  
> 
>  
> 
> *2.10.  Timestamp*
> 
> Type Name: timestamp
> 
> Timestamps in STIX are represented as a number of seconds since the Unix
> epoch (January 1, 1970) in the UTC (Coordinated Universal Time) timezone.
> 
> The JSON MTI serialization uses the JSON number type <TODO: add
> reference> when representing timestamp.
> 
>  
> 
>  
> 
> That text would let you represent the same dates you can represent in
> the current ISO8601 format, which everyone has been OK with. It would
> mean that different implementations may support different precision, but
> as the ballot showed people tend to be fine with that and, again, that’s
> how the old text worked so it’s not even a change.
> 
>  
> 
> Let’s have a quick informal ballot, and depending on how that goes we
> probably should move to a formal ballot. In order of preference, what do
> you think:
> 
>  
> 
> 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.
> 
>  
> 
> I have no preference on this topic. They all seem workable, I just want
> us to agree on something and move on.
> 
>  
> 
> John
> 
>  ... [8<]