Re: [cti] Advertising a CSD version of STIX and TAXII

[Allan Thomson <athomson@lookingglasscyber.com>]

I suggest Option 2) is preferred.

 

For orgs that don’t care about the sub-version information they can parse the version string for the <major>.<minor> information and ignore the rest.

 

For orgs that care they can use the full version information.

 

Allan

 

From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Thursday, March 1, 2018 at 9:06 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Advertising a CSD version of STIX and TAXII

 

All,

 

We have been having a discussion on Slack (#taxii) and in the TAXII Github issue tracker for issue 49 (https://github.com/oasis-tcs/cti-taxii2/issues/49) about how to handle, or if we should handle, the ability to advertise a CSD / draft version that is supported by a solution.  As we have not been able to come to consensus, I am asking the broader community for comments and feedback.  

 

Problem:

As we begin to release CSDs for STIX and TAXII 2.1 and the amount of time between releases grows, I believe it will be important for systems to know and understand which version, even a draft version, that the solution currently supports to make sure it can work seamlessly. 

 

Options:

1) Do nothing. Always advertise "2.1".  So for CSD01, CSD02, CSD03, etc, you would always just advertise "2.1". 

 

The risks to this that I see are, clients will have no way of knowing if their product is talking to another product that supports that same version of features. If everything was always additive, this "might" be okay. However, given our new process and how concepts can be dropped before the final CS, if they do not have support or code, then a client with support for CSD02 might not work with a client that supports CSD03. And there would be no way for the clients to know that, without two humans talking it through.  

 

Also we may have a situations where something is added to CSD01 and then radically changed in CSD02 due to issues that are found during development. If this happens, a server that is hosting content and is able to update more quickly, will have no way of telling a client (that has not yet updated) that it is using the newer version.

 

2) Add some sort of designation or suffix to the end of the version that represents an ever increasing value that can easily distinguish  the version you are using.  Say for CSD01 through CSD03 you could do 2.1-draft01, 2.1-draft02, 2.1-draft03, and then when the final version is ready for a CS level release, the suffix would be dropped and the version would be just 2.1.  

 

Thoughts?

 

Bret