Rich, et al,
I'm aware of these, and many other, ISO 8601 constructs. My view is that rich _expression_ of temporal concepts is an integral component to the success of any lexicon seeking to serve as "the" standard for expressing all things in the Cyber Domain.
It's important to understand that RFC 3339 is just a profile/subset of ISO 8601. My original draft proposal included support for:
<start>/<end>
<start>/<duration>
<duration>/<end>
<duration>
However, once you add duration you start down a slippery slope of "mission creep". Many see RFC 3339 as an attempt to address the wide spread interoperability issues caused by the broad "flexibility"/"variability" of ISO 8601.
The basis for my persistent arguments are not theoretical. They come from 14+ years of practical frontline experience in large scale CSIRT Investigations, Incident Response, and internal/external agency reporting. There are many scenarios where what
is indeed a discrete event needs to be expressed as a range of time. This assertion applies equally to constructs that contain specific "Start Time", "End Time" fields. One or both of these often need to be expressed as a range.
Given the opportunity, I will continue to argue for much broader temporal
expressiveness in our CTI lexicon (again referencing the seminal work by Allen: http://web.cacs.louisiana.edu/~logan/521_f08/Doc/p832-allen.pdf and
adding Allen, Ferguson et al http://web.mit.edu/larsb/Public/16.412/pset%204/allen94actions.pdf).
The addition of the "/" to our timestamp is an attempt to compromise by proposing a simple, syntacticly
precise, and narrowly scoped extension to our current baseline Timestamp proposal (which is "in and of itself" already a profile/subset of ISO 8601).
Whether or not you concur with these perspectives, I sincerely appreciate your time in considering the merits same.
Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk:
(856)983-0001
Cell:
(609)841-5104
Email:
_____________________________
From: Piazza, Rich <>
Sent: Tuesday, February 2, 2016 4:22 PM
Subject: RE: [cti] CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.
To: Patrick Maroney <>, Jordan, Bret <>,
Barnum, Sean D. <>
Cc: OASIS CTI TC Discussion List <>
Just to confuse things – I took a look at the ISO-8601 (or more precisely the wiki page – you have to “buy” the actual ISO document).
Taking a look at it:
https://en.wikipedia.org/wiki/ISO_8601, time intervals can actually have 4 different formats:
<start>/<end>
<start>/<duration>
<duration>/<end>
<duration>
where <duration> is just a unit of date/time (which was also mentioned in the Slack conversation)
–
example from wiki page:
"P3Y6M4DT12H30M5S" represents a duration of "three years, six months, four days, twelve hours, thirty minutes, and five seconds".
Additionally, I not sure leaving out <start> or <end>, means “unbounded” – the wiki page doesn’t mention such a time interval. Of course that doesn’t mean it
isn’t defined in the full ISO document.
From:
[mailto:]
On Behalf Of Patrick Maroney
Sent: Tuesday, February 02, 2016 3:14 PM
To: Jordan, Bret <>; Barnum, Sean D. <>
Cc: OASIS CTI TC Discussion List <>
Subject: Re: [cti] CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.
I'm pretty busy so haven't had time to substantively respond to the questions, requests. Etc. received on the list and via direct emails.
I do want to highlight here that we are only talking about the TimeStamp serialization structure in the spirit of "one way to do things". This proposal simply defines the syntax, not
the context.
Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email:
On Tue, Feb 2, 2016 at 7:51 AM -0800, "Barnum, Sean D." <> wrote:
I agree with you that this could potentially remove the need for the separate precision field.
sean
From:
<> on behalf of "Jordan, Bret" <>
Date: Tuesday, February 2, 2016 at 12:20 AM
To: Patrick Maroney <>
Cc: OASIS CTI TC Discussion List <>
Subject: Re: [cti] CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.
I have thought a lot about this, since Pat first brought it up and I believe he has a solid case for this. I do think that this might be
a bit weird in the UI treatments if every timestamp allows a range. But that is an implementation issue. I have questions of how this differs from precision. And if we do this, can we not just drop the extra precision field? That could make processing so
much easier.
Before we accept this, I would love to see some normative text written and added to the pre-draft specs. I would like to see some examples
of how precision would effect this and the normative text that would surround it (or can we just drop the precision field).
Can we also get a line or two of text that talks about what to do if your tool can only support one timestamp? I am guessing you would
take the first one?
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE
7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On Feb 1, 2016, at 21:35, Patrick Maroney <> wrote:
We are reaching final consensus on our CTI TimeStamp deliberations. This is a proposal to add a simple ISO 8601 Standard extension to the
CTI TC TimeStamp specification that enables _expression_ of both "Absolute Time" and "Time Range" .
Proposal:
(1) Adopt the ISO 8601 <start>/<end> construct.
(2) All of the constraints we are placing on the CTI Timestamp format remain intact:*
"Absolute Time": "2015-03-01T13:00:00Z"
"Time Range": "2015-03-01T13:00:00Z/2016-05-11T15:30:00Z"
(3) Parsing of the ISO 8601 <start>/<end> construct should be straightforward (i.e., using standard date-time libraries that support
ISO 8601, regex).
*Note : This proposal only argues for the narrow adoption of the "/" Separator and would not allow any of the other ISO 8601 "Time Range
"shortcuts" (e.g., "2014-2015", "2015-11-13/15", "2015-02-15/03-14").
There is significant benefit for use cases where there is a very real need to express events, actions, observables, COAs, etc. in time
ranges. For example- statutory incident/intrusion reporting deadline requirements (measured increasingly for many in hours/days) guarantee a need express and revise events in time ranges while investigations gather evidence and more accurately establish the
sequence of events and timelines. There are also many relationships that are more effectively expressed in time ranges, vs. fixed points in time.
Hopefully you see the value in adding this ISO 8601 capability to "our thing".
Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email:
