Discovery Resource Does not Clearly Articulate API Root Allowable Values

[JasonKeirstead]

Currently the specification is silent on if the URLs inside api_roots can be relative or not.

I would prefer that relative be allowed as it would make creating a modular TAXII service library simpler.... but regardless of the decision, we need to be clear here.

[JasonKeirstead]

We also need the same clarity on the "default" property

[allant0]

Suggest we should also test this in future interop tests. The spec being silent to me means that it allows both and thats legitimate. Therefore we should include verification that for certain use cases in interop that we test it.

[jmgnc]

I agree that we should support host relative URLs, but not path relative.. that is: /foobar

is valid, and: ../foobar

is not valid...

The reason path relative should not be supported, is that it shouldn't be needed, as the api-root is at a well know location, and so the ../ will likely be a fixed prefix.

[jordan2175]

This was discussed on the working call on 2018-01-23 and the consensus was that this needs to be fixed / addressed, however, there is not yet a solid proposal for text on how to fix it, just that it needs to be fixed. The following people were on the working call: Bret Jordan, Trey Darley, John-Mark Gurney, Sarah Kelley, Chris Ricard, Dave Lemire, Jason Keirstead, Nicholas Hayden, Richard Struse, Sunil Ravipati.

[jordan2175]

At the F2F we discussed and have consensus that we need to allow both a Fully Qualified URL and an Host Based Absolute Path.

[jordan2175]

During interoperability testing, implementers discovered that the specification does not clearly specify the syntax for URL values. Implementations were evenly split between fully qualified URLs (e.g., https://example.com/api/1/) and URL paths (e.g., /api/1/).

At the Jan F2F is Salt Lake City, the consensus of the group was that both "Fully Qualified" URLs and "Absolute Path" URLs should be permitted, and clarifying text should be added to the specification. In large part, determining fully qualified URLs of hosted services is seen as prohibitively complex to implement. This is a backward compatible change.

The dissenting opinion is that the HTTP URL syntax is clearly defined, and that it requires the "fully qualified" form. The complexity of implementing fully qualified URLs is seen by some as overstated.

[jordan2175]

We talked about this again on the working call on 2018-02-27 and the decision was to use full URLs and absolute paths that are absolute from the host, not relative to the discovery endpoint. @JasonKeirstead @jmgnc are going to contribute some text for the document.

[jordan2175]

I added text to section 4.1.1 API_Roots property description. The description now reads:

A list of URLs that identify known API Roots. This list MAY be filtered on a per-client basis.

API Root URLs MUST be HTTPS absolute URLs or relative URLs. API Root relative URLs MUST begin with a single / character and MUST NOT begin with // or '../". API Root URLs MUST NOT contain a URL query component.

Examples - Valid https://taxii.example.com:443/ https://someserver.example.net/apiroot1/ /someapiroot/

Examples -Invalid //someserver.example.com/apiroot1 ../someapiroot/ https://foo.edu/bar?baz

[varnerac]

LGTM