[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] STIX timestamps and ISO 8601:2000
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
Description: PNG image
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]