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: Re: [EXT] Re: [cti] Next batch of TAXII issues


Thanks for the quick response John... 


I agree with your statements..  If everyone else can respond here or in github, that would be great. 


Bret



From: Wunder, John A. <jwunder@mitre.org>
Sent: Friday, February 23, 2018 2:38:19 PM
To: Bret Jordan; cti@lists.oasis-open.org
Subject: [EXT] Re: [cti] Next batch of TAXII issues
 

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: <cti@lists.oasis-open.org> on behalf of "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
Date: Friday, February 23, 2018 at 4:12 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] 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 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.

 

 

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



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