TAXII Discovery URL Collides With Existing Product URLs

[jordan2175]

We should look at adding NAPTR record support to TAXII to further enable discovery of TAXII services.

[jordan2175]

If we do this, we should probably drop the concept of DNS SRV records for discovery since that would be two ways of doing the same thing.

[jmgnc]

As there was some objection to /taxii/ I'll point out that there is /.well-know/ defined by https://tools.ietf.org/html/rfc5785 that helps address this.

Not sure that NAPTR is the correct solution as it is targeted to SIP internet telephony. Unless more definition is provided around usage of NAPTR, I can't see it being a viable option.

[jordan2175]

We talked about this briefly on the working call on 2018-01-23 and we agreed that we need to look in to this and that we will discuss again on a future working call.

[rjsmitre]

F2F consensus was to rename to taxii2

[jordan2175]

During interoperability testing, the CTI TC learned that the /taxii/ URL conflicts with existing product URLs. The conflict prevents effective implementation of TAXII2 for existing products, which is undesirable.

The proposed solution is to change the DiscoveryURL from /taxii/ to /taxii2/. While this change breaks backward compatibility, the estimated impact is small. Servers supporting both TAXII 2.0 and TAXII 2.1 can easily support both URLs through aliasing. Servers that can not use the /taxii/ URL can now use the /taxii2/ URL. Clients that support both TAXII 2.0 and TAXII 2.1 may have to try multiple URLs for discovery to succeed.

This change will also help distinguish TAXII 2.

[jordan2175]

Suggested changes have been added to the document.

[jordan2175]

These changes were made in the following sections: 3.1 4 4.1 4.1.1 8.2.1