OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] timestamp proposal for STIX 2.0 RC3


I am not sure which I would prefer between 2 and 4.  But I strongly dislike not giving bounds to numbers.  If we do this, then all of our digital signatures in the future will probably break.  For example, if you send me a date that has pico-seconds and I can only understand micro-seconds and thus drop that precision on the floor, then the digital signatures will FAIL.  


It is such common practice in standards bodies to not only give guidance but to also give limits and bounds to content, that I can not see why we would not do this here.  


Further, ballots that have results at a near 50/50 or I would go as far as 60/40 result, are probably saying that we need to do more work to figure the issue out.  It is my belief in a standards body that a simple majority is just saying that the community is radically divided on the issue and we should go back and work to find a solution that works for the majority of people.


Bret


From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Mr. Stefan Hagen <stefan@hagen.link>
Sent: Wednesday, December 7, 2016 11:22:44 AM
To: cti@lists.oasis-open.org
Subject: Re: [cti] timestamp proposal for STIX 2.0 RC3
 
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<]


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]