I'd like to propose that the title be changed to: "Trailing-slash requirement for resource identifiers is missing".

With that, 👍 to solving this problem.

We discussed this on the working call on 2018-02-20 with the following 15 TC members (Bret Jordan, Trey Darley, Chris Ricard, Christian Hunt, Dan Dye, Dave Lemire, Drew Varner, Efrain Ortiz, Gary Katz, Jane Ginn, John-Mark Gurney, John Wunder, Nicholas Hayden, Paul Patrick, Rich Piazza).

There was no objection to adding a normative statement that says all resource endpoints MUST have a trailing slash.

I added the following text to section 3.1

All TAXII endpoints MUST have a trailing slash "/" at the end of the resource. For example:

A request for a resource //collections//objects//
A request for a resource with some filter parameters //collections//objects//?match[type]=indicator

I don't have any issues with this change, I wasn't at the plugfest where it came up.

I do think it will end up being a gotcha for some clients so we should make sure to have it in an FAQ. Many services just transparently deal with requests as if the trailing / doesn't matter, so clients get used to being imprecise. This will probably be exacerbated by some servers continuing to allow requests if the trailing slash is missing.

All TAXII endpoint URL paths MUST end in a trailing slash "/"

that may be more specific than "at the end of a resource" since path is explained in RFC-7230 separate than other URL components like query

Discussed on working call on 2018-03-20. John-Mark might make some additional comments on this, but for now this change has been made.

So, reading RFC7230, I don't see a point about paths needing to end in a trailing slash. I didn't closely read the whole thing, but didn't see any obvious requirements.

I don't think it's an RFC 7230 issue. It's just specified "3.1 Endpoints" table and elsewhere in TAXII 2.0 CS01 that way. I think the point is to clarify that the trailing / is a normative requirement.

My comment above

All TAXII endpoint URL paths MUST end in a trailing slash "/"

isn't meant to imply that RFC-7230 requires the /. I'm just trying to describe where the / belongs using terms describing a URL from RFC-7230, instead of "at the end of a resource". Specifically using "path" from 2.7. Uniform Resource Identifiers.

I'm fine w/ this, but at the same time, I'm a bit torn by requiring single item instances like fetching an object by it's UUID to us a trailing slash. Trailing slash indicates a directory, and that there is more than one "entity" under there.

But forcing all paths to end w/ a slash is easier and more consistent.

The thing about fetching an object is that it actually returns object versions. I see your point though.

It is critical to remember that this is not a change from 2.0. This is the behavior that we all agreed to way back in 2.0 (it was originally requested by EclecticIQ from their API experience) and we tried to put it in the document, but found later, that we did not do a good enough job clarifying it. So this is all about adding the clarifying text.