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: Next batch of TAXII issues


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. 

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.

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.

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

For this one, I am not sure where we should put this information 

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.

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 of [RFC7231]) and an optional version parameter in the HTTP Accept header (section 5.3.2 of [RFC7231]) and Content-Type header (section 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.

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.


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