[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [EXT] Re: [cti-taxii] Proposal to relax language in section 3.4 version URL query parameter
Given that use case (Sept or Oct 2017) I would suggest not making this change and figuring out a way to express arbitrary ranges. I think this is what Drew was suggesting in Github too, I +1ed his comment. It just seems like always searching
for an exact year, month, or day vs. a range will be limiting. From: "Bret Jordan (CS)" <Bret_Jordan@symantec.com> Right now we have no way of doing this and this seems like a very simple way of providing that functionality. Let me rephrase, the only functionality we currently provide is to forward synchronize an entire data feed from a certain point in time (added_after).. But the added_after
is NOT tied to the modified time / version in STIX at all. Since a TAXII server may get 2017 content in 2019, a client would have to sync the entire dataset. There is no way of just asking for versions of content that were modified in say 2017 or 2017-10
for example. Bret From: cti-taxii@lists.oasis-open.org <cti-taxii@lists.oasis-open.org> on
behalf of Wunder, John A. <jwunder@mitre.org> Do you ever imagine wanting to do queries like “versions between June 4 to June 16”? If so I would say don’t make this change, because once you add that additional capability (to provide a start/stop
date for a range of versions) it would introduce two ways of doing things (“2018-06” vs. “2018-06-01” to “2018-06-30”). If on the other hand the common use case is “modified this day” or “modified this year” then the approach below makes sense. Along those lines, what’s the use case for this wildcarding? Like
I get the functionality, “I want to see any versions from June” but when would a client system want to make that request? John From:
<cti-taxii@lists.oasis-open.org> on behalf of "Bret Jordan (CS)" <Bret_Jordan@symantec.com> Right now in the URL Query Parameter section 3.4.1 (https://docs.google.com/document/d/1EsiWY7TGqt9yH6QUXv4c-opXSr3wR0TDMt8Q0yJjpoo/edit#)
for specifying a version, we have the following text for calling out a specific value.
For STIX objects, this requests objects whose modified time matches exactly the provided value. This value
MUST follow the rules for timestamp
as defined in [STIX™
Version 2.0. Part 1: STIX Core Concepts]. I propose that we change this text to be:
For STIX objects, this requests objects whose modified time matches
The reason for this change is to allow a client to ask for "?match[version]=2017-01" and get all of the STIX objects and their versions
from January 2017 but not from December 2016 or earlier or from February 2017 or later. This is documented here:
https://github.com/oasis-tcs/cti-taxii2/issues/61 Bret |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]