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: [EXT] [cti] RE: TAXII Version Filter - Please review


For your first two paragraphs and proposed solutions, I would be in favor of having a broader discussion with the group members. The important part is to reach consensus upon the behavior for the filter. That should make for three options now.

 

In regards to what version of TAXII should address this problem. Ideally it would be good to have for TAXII 2.1, otherwise it would leave a gap in that area. It was present in 2.0 with the marking-definition object but it was not as apparent/significant to those making requests. I think the problem will be more pronounced with Cyber Observables since they are more valuable/more likely to be shared among others.

 

Option #1: Say nothing about those Cyber Observables, or say that this specific version parameter does not work for objects that do not have versions.  Meaning, if the version does not have a version, then this parameter is meaningless.

 

Option #2: Figure out what we are going to do with the "last", "first", and "all" parameters.  But the specific parameter I think we can just say it is not applicable.  

 

Option #3: Make use of the “date_added” where the server time assigned to that object when added to the collection is used to disambiguate any request regarding version.

 

-Emmanuelle

 

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Bret Jordan
Sent: Wednesday, January 23, 2019 8:27 AM
To: Vargas-Gonzalez, Emmanuelle <emmanuelle@mitre.org>; cti@lists.oasis-open.org
Subject: [cti] Re: [EXT] [cti] RE: TAXII Version Filter - Please review

 

That is a good point... I am also starting to think that we should just not saying anything about those, or say that this specific version parameter does not work for objects that do not have versions.  Meaning, if the version does not have a version, then this parameter is meaningless.  

 

We would still need to figure out what we are going to do with the "last", "first", and "all" parameters.  But the specific parameter I think we can just say it is not applicable.  

 

Or we just say that for TAXII 2.1, we are going to do nothing here, and we will worry about it for TAXII 2.2.  TAXII 2.2 could probably be released around the same time as STIX 2.1.

 

Bret

 


From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Vargas-Gonzalez, Emmanuelle <emmanuelle@mitre.org>
Sent: Wednesday, January 23, 2019 5:51:37 AM
To: cti@lists.oasis-open.org
Subject: [EXT] [cti] RE: TAXII Version Filter - Please review

 

Bret,

 

I feel like this line If the STIX object does not contain either a modified or created timestamp, then this filter should return the latest version according to the server.

does not convey (or goes against) the purpose of using the version filter. I am having a problem with the word latest on that line as not always we would want to resolve for the latest object in a server. Perhaps something like the following would allow for the resolution of objects without created or modified time.

 

### BEGIN

 

If the STIX object does not contain either a modified or created timestamp, then this filter should use the date and time when the object was added to the server as a method to disambiguate the object to be returned.

 

### END

 

Any thoughts?

 

Thanks,

Emmanuelle

 

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Bret Jordan
Sent: Wednesday, January 23, 2019 4:49 AM
To: cti@lists.oasis-open.org
Subject: [EXT] [cti] TAXII Version Filter - Please review

 

All,

 

Drew, Allan, and I took a stab at fixing the text on the version filter parameter so that can work with a STIX object that does not have a modified timestamp (marking-definition object).  The text from section 3.4.1 now reads:

 

### BEGIN

 

For STIX objects, this filter option requests objects whose modified time matches exactly the provided value and the value MUST follow the rules for timestamp as defined in [STIX™ Version 2.0. Part 1: STIX Core Concepts]. For STIX objects that do not contain a modified timestamp (ex. the marking-definition object), then this filter should match on the created timestamp. If the STIX object does not contain either a modified or created timestamp, then this filter should return the latest version according to the server.

 

For example: "2016-01-01T01:01:01.000Z" tells the server to return the exact STIX object(s) that matched the modified time or created time (in the case of a marking-definition object) of "2016-01-01T01:01:01.000Z".

 

### END

 

The extra caveat for not having either a modified or created timestamp deals with the potential cyber observable changes. Please review and comment on the list with any concerns or changes. 

 

 

Bret



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