OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-taxii message

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


Subject: Re: [cti-taxii] Open Questions on RC1


My suggestions inline.

 

From: <cti-taxii@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Thursday, February 2, 2017 at 2:02 PM
To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Subject: [cti-taxii] Open Questions on RC1

 

All,

 

We have been working through RC1 and processing as many of the comments and suggestions that we can. One of the comments that we received is that we really need to do Pagination in this first release.  Sergey has kindly submitted some suggestions to solve this.  We have a few questions though, that we need you all to decide on:

 

1) Should the client be allowed to do its own pagination, aka, should it be allowed to set its limit or should the Server determine that?  Another option is should the limit just be defined in the spec.?

 

a)      What happens when the client asks for 1000 records and the server is only willing to give 100, should the server return an error, should it fulfill the request up to a 100 and then give a hint in say the HTTP Header that the "limit" is "100", or should it be done a different way.

 

AT: Server should provide hint in the negotiation of what the max size that it supports is. Secondly if a client asks for a size larger than the server supports then the server should respond with its limit and status message that indicates the content requested was limited based on server limits.

 

 

 

Another thing we came across that is that the definition of a list in TAXII was not the same as STIX.  Meaning, TAXII allowed empty lists.  We are proposing that this be changed. Does anyone have any issue with that?  What this would mean is that you would get an HTTP 204 (No Content) back instead of an empty list.  

 

AT: No issue.

 

 

In section 4.5, the Manifest Resource, we are also proposing that we remove the "last_modified" property and just say that the "versions" property MUST be sorted in ascending order.  Does anyone have an issue with this? 

 

AT: Suggest we use the same terminology as defined in STIX schema (which uses modified) and therefore we should stick with modified term and not use version.

 

 

Bret



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