I thought of that Jason but the TAXII Server knows when something is added to a read-only collection and knows the version of the objects so I think its reasonable to include it to those collections too.
This will be important for filtering on new data added in the last 24 hours (for example) to read-only collections.
So encouraging the server to apply those properties to data added to even read-only collections is best practice (imo).
Allan Thomson
CTO (+1-408-331-6646)
LookingGlass
Cyber Solutions
From:
Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Friday, October 5, 2018 at 7:48 AM
To: Allan Thomson <athomson@lookingglasscyber.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Subject: Re: [cti-taxii] Manifest Resource
The reason they are optional is because for read-only collections where the data is being returned programmatically (IE the TAXII server is not a data repository), these fields
have no meaning.
So if they're made mandatory, the data will just be meaningless generated bloat
Its not a showstopper, but just for awareness.
-
Jason Keirstead
Lead Architect - IBM.Security
www.ibm.com/security
"Things may come to those who wait, but only the things left by those who hustle." - Unknown
From: Allan Thomson <athomson@lookingglasscyber.com>
To: Bret Jordan <Bret_Jordan@symantec.com>, "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Date: 10/05/2018 10:38 AM
Subject: Re: [cti-taxii] Manifest Resource
Sent by: <cti-taxii@lists.oasis-open.org>
Bret – I tried to think any case where they might not be available or generated.
I couldn’t think of any reasonable use case where the taxii server could not provide these, so I’m supportive of the change.
Allan
From: <cti-taxii@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Friday, October 5, 2018 at 7:00 AM
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Subject: [cti-taxii] Manifest Resource
All,
In looking at the Manifest Resource and its purpose, I am thinking we need to make the date added and version properties required. I believe this was an oversight in 2.0.
Currently we have the following properties
|
Property Name
|
Type
|
Description
|
|
id(required)
|
string
|
The identifier of the object that this manifest entry describes. For STIX objects the
idMUST be the STIX Object
id. For object types that do not have their own identifier, the server
MAY use any value as the id.
|
|
date_added(optional)
|
timestamp
|
The date and time this object was added.
|
|
version(optional)
|
string
|
The version of this object.
For objects in STIX format, the STIX
modifiedproperty is the version.
|
|
media_type(optional)
|
string
|
The media type that this specific version of the object can be requested in. This value
MUST be one of the media types listed on the collectionresource.
|
I propose that we change this to:
|
Property Name
|
Type
|
Description
|
|
id(required)
|
string
|
The identifier of the object that this manifest entry describes. For STIX objects the
idMUST be the STIX Object
id. For object types that do not have their own identifier, the server
MAY use any value as the id.
|
|
date_added(required)
|
timestamp
|
The date and time this object was added.
|
|
version(required)
|
string
|
The version of this object.
For objects in STIX format, the STIX
modifiedproperty is the version.
|
|
media_type(optional)
|
string
|
The media type that this specific version of the object can be requested in. This value
MUST be one of the media types listed on the collectionresource.
|
Is there anyone that would be against this change? If no, I will create a Github issue and make the change in Working Draft 04.
Bret