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


Regarding pagination, the server should be in ultimate control, but the client should potentially be allowed to make some decisions as well. The way the GitHub API does pagination [1] has always made sense to me.

 

I’ll be honest that I never understood the prohibition on empty lists in STIX, but aiming consistency is a good thing where reasonable. My only concern about a 204 response is whether there would ever potentially be information you would want to return in a response with a required list that might be empty.  For something like Collections Response or Collection Manifest Response, where the entire response is a list, that’s seems OK. For the API Root, there are three required lists (versions, which should never be empty, and channels/collections, for which there is an ongoing conversation). Discovery Resource has a required list of api-roots. Does it ever make sense to return a Discovery Resource or API Root Resource without any items in these currently-required lists? All the other lists I see in the spec are optional.  

 

Just my $0.02.

 

Greg

 

[1] https://developer.github.com/v3/#pagination

 

From: <cti-taxii@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Thursday, February 2, 2017 at 4: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.

 

 

 

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.  

 

 

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? 

 

 

Bret



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