new X-TAXII-Content-Types header for automatic version negotiation

[traut]

I would like to hear your opinion about TAXII version auto negotiation (in the scope of HTTP based implementations). I think this is an important issue that needs to be in HTTP Protocol Bindings specification.

At the moment, Discovery Service is the only source of information about any configured service instance. It is the only way to get the Message Bindings that a service instance supports. If the host decided not to run Discovery Service, the clients have no way to get this information, they can only try to guess.

I propose to add X-TAXII-Content-Types header to TAXII HTTP Protocol Binding Specification.

The negotiation scenario then would be:

• client knows service instance URL (for example http://taxii.example.com/service/inbox) but knows nothing about TAXII version that this service supports.
• client sends OPTIONS HTTP request to that service-specific URL (http://taxii.example.com/service/inbox)
• TAXII service replies with appropriate response and X-TAXII-Content-Types header configured. X-TAXII-Content-Types contains all Message Binding IDs that this particular service supports, comma separated. Example:

X-TAXII-Content-Types: urn:taxii.mitre.org:message:xml:1.0,urn:taxii.mitre.org:message:xml:1.1

• client sends a request to the service, as a correct TAXII message that corresponds to one of the Message Binding IDs from X-TAXII-Content-Types header value.

I see this addition as a one step towards version agnostic client/server implementations.

[MarkDavidson]

Related to (but not the same as) https://github.com/TAXIIProject/TAXII-Specifications/issues/58

[traut]

just as a note: this logic is supported in OpenTAXII already

[jordan2175]

I like this idea in general. And yes, this moves away from vanilla HTTP, however, adding header values to HTTP seems like a better solution then having these things embedded in the TAXII message.

[traut]

I must say the naming is unfortunate. Maybe X-TAXII-Supported-Versions or similar would be better

[MarkDavidson]

I'd like to make one comment at a high level before I dive down into the weeds. The comment is that I think TAXII Version Negotiation is a good requirement for TAXII going forward.

Now, for a deeper dive:

From the http/1.1 spec regarding options:

A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options. The format for such a body is not defined by this specification, but might be defined by future extensions to HTTP.

I then thought that some variant of the Accept would be reasonable, but I couldn't quickly find any documentation for the Accept header being used in this way. In my searched I looked at the HTTP 406 - Unacceptable status code, which doesn't specify a standard mechanism for conveying which Content-Type values are acceptable.

There's probably a bit more to explore here, but hopefully there's a way to do version negotiation within vanilla HTTP. If not, we'll have to invent something akin to what has been discussed here.

-Mark