Relax version URL query parameter to accept partial timestamp values

[jordan2175]

All,

Right now in the URL Query Parameter section 3.4.1 for specifying a version, we have the following text for calling out a specific value.

- requests a specific version of an object. 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:

- requests a specific version of an object. For STIX objects, this requests objects whose modified time matches the provided value.

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.

[varnerac]

I’m against adding this. We can already express this using the current format.

[jordan2175]

@varnerac actually no, we can not. 2018-01-01T00:00:00.001Z for example is in fact a real time that someone might want to query on.

[varnerac]

Sorry. Hit wrong button and closed.

[varnerac]

I read this too quickly. I think this warrants a new predicate to express version ranges, rather than deviating from the current timestampdata type.

[jordan2175]

But for this field value, we do not define it as needing to be a timestamp type since some object types other than STIX might have a different version field.

[varnerac]

Well, non-STIX content has the option of using any string for the query string. However, version "requests a specific version of an object". That's not suitable for a range request, which returns multiple versions. Your "starts with" syntax is just a range request. It makes an assumption that people want to search on ranges that correspond with the timestamp string's prefix. Why not provide an explicit range operator?

I'd prefer explicit range operators rather than override version to handle a specific version or range of versions via a string prefix comparison.

[JasonKeirstead]

For what it's worth, the "TAXII Information Request and Response" proposal addresses this use case.

[jmgnc]

you can use ISO 8601 Time Intervals: https://en.wikipedia.org/wiki/ISO_8601#Time_intervals These are computers, calculating time intervals are easy, and they can fully fill out the time. People should not be generating query strings/parameters by hand by themselves, their client should be.