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] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.


How many other, widely-used standards allow time ranges as envisioned here.  As I think about trying to write code to consume this it makes my head hurt.  I feel that this is antithetical to our stated goal of making STIX/CybOX simpler, easier to implement and most importantly easier to consume.  Think about what this proposal would do to UIs for example.  Yikes!

 

Let’s be explicit where we need a time range.  Everywhere else I’d urge we stick with a single time. Please. J

 

From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Mark Davidson
Sent: Tuesday, February 02, 2016 10:53 AM
To: Barnum, Sean D.; Wunder, John A.; OASIS CTI TC Discussion List
Subject: Re: [cti] RE: CTI TC Timestamps - Proposed: Adopt the ISO 8601 <start>/<end> construct.

 

Under the proposed structure, how would a consumer differentiate between a timestamp (e.g., “this report was produced at XYZ”) vs. a time range with an unbounded end (e.g., “this indicator is valid from now until eternity”)? If I understand the proposal correctly, there would be no way for a consumer to decide whether "2015-03-01T13:00:00Z” is a timestamp or a time range.

 

Personally, I think we should be explicit about which fields are timestamps and which fields are time ranges (at least in the spec). 

 

Which fields don’t fall cleanly into either category?

 

Thank you.

-Mark

 

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature



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