Next batch of TAXII issues

[Bret Jordan <Bret_Jordan@symantec.com>]

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