Re: [cti] timestamp proposal for STIX 2.0 RC3

This works for me. So the new text would be something like this.

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.

2.10.1. Requirements

· The timestamp field MUST be a non-negative decimal number between 0 (January 1, 1970) and 4102462800 (January 1, 2100) representing seconds since the Unix

epoch.

· The precision of the timestamp field MUST NOT be better than picoseconds (10^-12 seconds).

Two other questions:

1. Should we add a statement like Bret says saying you can (SHOULD?) use a float64 to represent this number (I believe float64 would lose precision if you try to do picoseconds, but should be good up until microseconds).

2. Should we add a statement saying that STIX systems SHOULD use NTP to sync their clocks?

Personally, I think implementation guidance like both of those items should be in an implementer’s guide, separate from the specification, to keep the specification focused on STIX itself.

John

On 12/6/16, 1:37 PM, "cti@lists.oasis-open.org on behalf of Michael Chisholm" <cti@lists.oasis-open.org on behalf of chisholm@mitre.org> wrote:

On 12/6/2016 12:24 PM, Wunder, John A. wrote:

> 2.10.1. Requirements

> · The timestamp field MUST be positive decimal number between 0 and 4102462800 (January 1, 2100) containing no more than picosecond precision.

> · The timestamp field MUST represent a number of seconds since January 1, 1970, in UTC (Coordinated Universal Time) as defined by ITU-R TF.460-6.

I'd put the interpretation and range into the same bullet (maybe

separate bullets, but not before the precision restriction). Yeah the

meaning (the number means seconds) is given in the description above,

but then again, you did deem it necessary to repeat that in the second

bullet. If you glossed over the description above, the first bullet

wouldn't make any sense (can't know what the implications of "picosecond

precision" are if you don't know what the number means). If there are

semantic dependencies among the bullets, I would put the dependencies

before the dependents. I think it makes more sense to layer up meaning

in an order such that each bullet can be understood in terms of the

previous bullets (if necessary), so people can just scan down the bullet

list in order. So you don't have to jump ahead and then go back again.

So I'd arrange the information in bullets this way:

* The timestamp field MUST be a non-negative decimal number between 0

and 4102462800 (January 1, 2100) representing seconds since the Unix

epoch (maybe repeat what the epoch is?).

* The precision of the timestamp field MUST be no better than

picoseconds (10^-12 seconds).

Andy

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail. Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

cti message