Thanks for writing this up, it makes it very easy to go through and respond. In order to avoid duplicating things I responded individually to every issue in Github.
Most seemed fine as-is, a couple I think needed some editorial work to make sure the text was clear, and I think one needs more discussion (https://github.com/oasis-tcs/cti-taxii2/issues/49).
John
From: <> on behalf of "Bret Jordan (CS)" <>
Date: Friday, February 23, 2018 at 4:12 PM
To: "" <>
Subject: [cti] Next batch of TAXII issues
All,
Here are seven low hanging issues I would like to see if we can resolve over email. If we do not hear any objections by the end of next week, we will
proceed with the currently proposed solutions. Please respond with your approval, disapproval, or additional feedback/suggestions/improvements either over email or in the Github issue tracker. BTW, here is the link to the current
TAXII 2.1 Document for
your reference.
Version filter is unclear if result MUST only be
the latest version #25
In section 3.4.1, change the version description text to:
The version of the object(s) that are being requested from either an object or manifest endpoint. If no version parameter is provided, the server
MUST return only the latest version of the object.
Object Sort Order is Confusing and Surprising to
Some #31
In section 3.4, add the following text to the added after description:
If no added_after parameter is provided, the server MUST return the oldest records in the dataset first.
Trailing-slash normative requirement for resource
identifiers is missing #41
In section 3.1, the following normative statement and examples were added:
All requests to a TAXII endpoint
MUST include the trailing slash "/" at the end of the resource. For example:
A request for a resource without any filter parameters /<api-root>/collections/<id>/objects/<object-id>/
A request for a resource with some filter parameters. /<api-root>/collections/<id>/objects/<object-id>/?match[type]=indicator
Update JSON Reference #43
For this one, I am not sure where we should put this information
Section 3.3 still talks about an object search endpoint
#51
In section 3.3, a paragraph remains about the old object search endpoint. This endpoint was removed before TAXII 2.0 was finished, however, this paragraph
did not also get removed. Proposal, remove this paragraph.
For the Object Search Endpoint, objects MUST be sorted in ascending order by the date the object first appeared in object search (i.e., the added date). If an object would appear multiple
times, all appearances after the first appearance MUST be omitted from the result. That is, if an object would have appeared first in the list and again halfway down, only the first entry should be present in the result.
Missing reference in content negotiation #54
Advertising a version of TAXII at a CSD level is
not currently possible #49
In section 1.4.7 I have tried to address the above two issues, by making sure the references are correct and that we provide a way to advertise a version
that is still at a CSD level. So an example version, in the Content-type header would be: "version=2.1.csd01"
This specification uses media types (section 3.1.1.1 of [RFC7231]) and an optional version parameter in the HTTP Accept header (section 5.3.2 of [RFC7231]) and Content-Type header (section
3.1.1.5 of [RFC7231]) to perform HTTP content negotiation as defined in [RFC7231].
In addition to the following media types, this specification defines an optional version parameter per the guidelines as defined in section 4.3 of [RFC6838]. The version parameter for
the STIX and TAXII media types follow the following rules:
The first digit represents the major specification release number
The second digit represents the minor specification release number
The third value, if present, represents a committee specification draft number (e.g., csd01).
The STIX 2.0 and TAXII 2.1 media types and versions are defined in the following table.
API Root TAXII Version does not match Media Type
Version #48
In section 4.3.1 we define the versions to be "taxii-2.1" instead of the value that matches the media type version. I propose that for 2.1, we change
this to be the same at the media type version. This will also allow us to advertise at the API root level the CSD version as well.
Thanks
Bret
