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: [Non-DoD Source] Re: [cti] type changing from "object" to "array" for cyber observable objects

If memory serves it came down to a data transformation and validation question vs client side performance.  With the logic being that if a system needed to store the ID off separately it could move they key into an internal field for its own use and then transform it back out when exporting it as Cybox data.

This in turn would allow any client traversing or validating cybox graph to use the already defined JSON keys rather than having to build a separate key array and then do a second pass to resolve all relationships.

Jeffrey Mates, Civ DC3/DCCI
Computer Scientist
Defense Cyber Crime Institute

-----Original Message-----
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Andras Iklody
Sent: Friday, September 29, 2017 4:06 AM
To: cti@lists.oasis-open.org
Subject: [Non-DoD Source] Re: [cti] type changing from "object" to "array" for cyber observable objects

Is the reasoning behind it explained anywhere? Whoever we've discussed STIX 2.x so far with had their faces buried deeply in their palms whenever they got to the part of the documentation that explained this very concept.

Also, revising bad decisions, even if they were reached via concensus / a previous debate can be healthy for a standard. Especially when the only explanation we get each time we ask about this is "as thus has been decideth" without any reasoning given.

Best regards,

On 29. sep. 2017 09:53, Trey Darley wrote:
> On 29.09.2017 09:43:26, Andras Iklody wrote:
>> 100% agreed! {"0":{}, "1":{}} is just ridiculous.
> All -
> Referring to STIX 2.0, Part 3, §2.5 "Observable Objects":
> "Each key in the dictionary SHOULD be a non-negative monotonically 
> increasing integer, incrementing by 1 from a starting value of 0, and 
> represented as a string within the JSON MTI serialization. However, 
> implementers MAY elect to use an alternate key format if necessary."
> As anyone participating in standards development work knows, 
> compromises are often necessary. The choice to standardize on a 
> monotonically increasing integer was a compromise following a lengthy 
> debate. Note, however, that this is a SHOULD. You're free to use 
> whatever you like as a key provided it's a valid JSON string.

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:

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

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