2015-11-20 18:55 GMT+03:00 Jason Keirstead <Jason.Keirstead@ca.ibm.com>:
I myself don't really see much a use case for precision. What is the use case? Why do I care about the precision of the producer, if it is second resolution or millisecond resolution?
Furthermore - do people actually envision a producer that does not have the capability to produce millisecond resolution? What would that be...? Someone with a watch?
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - UnknownJerome Athias ---11/20/2015 11:27:48 AM---attached just a screenshot from my tool to illustrate the concern 2015-11-20 17:06 GMT+03:00 Wunder,
From: Jerome Athias <athiasjerome@gmail.com>
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 11/20/2015 11:27 AM
Subject: Re: [cti-stix] STIX timestamps and ISO 8601:2000
Sent by: <cti-stix@lists.oasis-open.org>
attached just a screenshot from my tool to illustrate the concern
2015-11-20 17:06 GMT+03:00 Wunder, John A. <jwunder@mitre.org>:
> One of the changes we made in STIX 1.1 was the addition of a “precision”
> attribute next to all timestamps (except for @timestamp, which was intended
> to always be precise to the second or millisecond). The intent was to allow
> producers to convey times that were precise to a millisecond/second
> (possible in ISO 8601), day, month, and year (not possible in ISO 8601). The
> use case was incident and report timestamps where implying millisecond or
> even second precision was not accurate…the incident was reported on a given
> day and so the full timestamp would need to fake the time portion of the
> day.
>
> To be honest I’m not sure that that use case is important enough to
> introduce the concept of precision, but we did explicitly add it in 1.1 so
> it’s something we should at least consider as an alternative to always
> requiring millisecond precision even in cases where’s it’s essentially
> faked.
>
> The other thing STIX added on top of that is that timezone is “strongly
> suggested” (it’s optional in 8601). I’d be in favor of making it required
> unless any implementors have objections.
>
> John
>
> On Nov 20, 2015, at 8:57 AM, Jason Keirstead <Jason.Keirstead@CA.IBM.COM>
> wrote:
>
> The problem is the "subset" potion. ISO 8601 actually does not specify how
> to represent milliseconds. So some people don't include it, some do,
> sometimes they also throw in nanoseconds...
>
> I think we should extend ISO 8601 in the spec to include milliseconds and
> make it mandatory, so that it is well known exactly what the time format
> will be. Millisecond resolution will be required for many pieces of software
> operating with STIX.
>
> -
> Jason Keirstead
> Product Architect, Security Intelligence, IBM Security Systems
> www.ibm.com/security | www.securityintelligence.com
>
> Without data, all you are is just another person with an opinion - Unknown
>
>
> <graycol.gif>Jerome Athias ---11/19/2015 11:48:25 PM---Back to the future
> ---------- Forwarded message ----------
>
>
>
> From: Jerome Athias <athiasjerome@gmail.com>
> To: cti-stix@lists.oasis-open.org
> Date: 11/19/2015 11:48 PM
> Subject: [cti-stix] Fwd: STIX timestamps and ISO 8601:2000
> Sent by: <cti-stix@lists.oasis-open.org>
>
> ________________________________
>
>
>
> Back to the future
>
>
> ---------- Forwarded message ----------
> From: Jerome Athias <athiasjerome@gmail.com>
> Date: 2014-02-10 10:10 GMT+03:00
> Subject: Re: STIX Content Revision and Revocation
> To: "Wunder, John A." <jwunder@mitre.org>
> Cc : Terry MacDonald <terry.macdonald@gmail.com>, Patrick Maroney
> <Pmaroney@specere.org>, "Grobauer, Bernd"
> <Bernd.Grobauer@siemens.com>, "Taylor, Marlon"
> <Marlon.Taylor@hq.dhs.gov>, DisplayName <patrick.maroney@mac.com>,
> "Barnum, Sean D." <sbarnum@mitre.org>, Kyle Maxwell
> <krmaxwell@gmail.com>, Dave Dittrich <dittrich@u.washington.edu>,
> stix-discussion-list Structured Threat Information _expression_/ST
> <stix-discussion-list@lists.mitre.org>
>
>
> I would see xs:datetime as "an implementation of strings formatted
> according to a subset of ISO 8601:2000, documented in RFC 3339."
> http://www.w3.org/TR/xmlschema-2/#isoformats
> http://tools.ietf.org/html/rfc3339
>
> so no "differences"
>
> 2014-02-10 Wunder, John A. <jwunder@mitre.org>:
>> Hey guys,
>>
>>
>>
>> I have a quick question about RFC3339 vs. XML Schema's dateTime. I looked
>> into them briefly and as far as I can tell they are very similar...some
>> small
>> differences in what each allows (capital T to denote time vs. either
>> capital
>> or lowercase, things like that). Are there important differences that make
>> RFC3339 better than xs:dateTime that I'm missing? The nice thing about
>> xs:dateTime is that, as long as STIX is in XML it natively validates, vs.
>> RFC3339 which we would have to validate (and wouldn't work as well in
>> programmatic bindings).
>>
>>
>>
>> Note: I'm basing this off of this mailing list post regarding Atom, so
>> it's
>> very possible I just don't understand the differences:
>> http://www.imc.org/atom-syntax/mail-archive/msg13103.html.
>>
>>
>>
>> Thanks,
>>
>> John
>>
>>
>>
>> From: Terry MacDonald [mailto:terry.macdonald@gmail.com]
>> Sent: Sunday, February 09, 2014 8:20 PM
>> To: Patrick Maroney
>> Cc: Grobauer, Bernd; Taylor, Marlon; DisplayName; Barnum, Sean D.; Wunder,
>> John A.; Kyle Maxwell; Dave Dittrich; stix-discussion-list Structured
>> Threat
>> Information _expression_/ST
>> Subject: Re: STIX Content Revision and Revocation
>>
>>
>>
>> [+1] again on the RFC3339 (In UTC with 6 digits of precision) for me too
>> please.
>>
>>
>>
>> Cheers
>>
>>
>>
>> Terry MacDonald
>>
>>
>> Terry MacDonald
>>
>>
>>
>> On 10 February 2014 14:02, Patrick Maroney <Pmaroney@specere.org> wrote:
>>
>> [+1] For a universal (optional) timestamp attribute( (RFC3339 in UTC
>> with
>> at last 6 digits of precision for 'time-secfrac'). Understand we will
>> need
>> to defer on other related attributes (like potential CRUD/change modality)
>> to give it the attention this needs However, this change would help lay
>> the foundations for a unified temporal reference (or at least the ability
>> to
>> assert same ;-).
>>
>>
>>
>> Patrick Maroney
>> Executive Director
>> Defense Security Information Exchange (DSIE)
>> Office: (856)983-0001
>> Cell: (609)841-5104
>> pmaroney@specere.org
>>
>> ________________________________
>>
>> From: owner-stix-discussion-list@lists.mitre.org
>> <owner-stix-discussion-list@lists.mitre.org> on behalf of Grobauer, Bernd
>> <Bernd.Grobauer@siemens.com>
>> Sent: Sunday, February 09, 2014 2:48:01 PM
>> To: Taylor, Marlon; DisplayName; Barnum, Sean D.
>>
>>
>> Cc: Wunder, John A.; Terry MacDonald; Kyle Maxwell; Dave Dittrich;
>> stix-discussion-list Structured Threat Information _expression_/ST
>>
>> Subject: RE: STIX Content Revision and Revocation
>>
>>
>>
>> Hi,
>>
>>
>>
>> I pretty much agree with Marlon's answers to the open questions put by
>> Sean.
>> Looking at
>>
>> draft 2 of version 1.1 of Stix, I would like to add my vote to Marlon's
>> answer to question
>>
>> 10 "Should an additional @timestamp attribute be added to each
>> contstruct.".
>> Marlon
>>
>> prefers the attribute, and so do I: timestamp information is such
>> essential
>> information,
>>
>> that it should be on top-level right next to the identifier rather than
>> somewhere below
>>
>> in the (optional!!) "Information_Source/Time/Produced_Time" element.
>>
>>
>>
>> Also: I think on must be able to add timestamp information to really every
>> object
>>
>> that has an identifier: I am not sure that every object I want to
>> timestamp
>> has the 'Information_Source'-substructure:
>>
>> making '@timestamp' an attribute next to any place where an '@id'
>> attribute
>> occurs makes sure
>>
>> that any object can be timestamped.
>>
>>
>>
>> So, in short: although this comes rather late in the timeline of STIX 1.1:
>> I
>> really think
>>
>> that draft 2 should be changed with regards to the location of where the
>> timestamp information
>>
>> is kept: make '@timestamp' a sibling of '@id', '@id_ref' and
>> '@timestamp_ref' rather
>>
>> than keeping the timestamp in "Information_Source/Time/Produced_Time".
>>
>>
>>
>> Kind regards,
>>
>>
>>
>> Bernd
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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
>
>
>
>
>
[attachment "STIXBuilder_Precision.png" deleted by Jason Keirstead/CanEast/IBM]
---------------------------------------------------------------------
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