If the client asks for STIX 2.0, the server needs to send valid 2.0 or nothing at all (either an empty response or a 415 status message). It is up to the negotiated agreement between the server and the source of the data whether the source's STIX 2.1 data can be "modified/down-converted" to STIX 2.0 or not.

We can suggest what the default behavior should be (absent any agreements to the contrary), but I feel like mandating any behavior in the spec is an overreach.

I agree with @gtback - conversion across STIX versions is an application behavior. The best we could do, in terms of assisting conversion across STIX versions, is to publish an official guide and a library implementing the official guide.

Recommendation: Discuss at F2F

After talking with @johnwunder I realized that the STIX specification actually prohibits down converting content. @MarkDavidson @gtback so it is not really a product issue, as it can not be done, without changing the ID and taking ownership of the content (which depending on the legal contracts, the product may not be able to do) and then trying to link it back to the original somehow.

So if a client asks for ID indicator-1234 in STIX 2.0 and the server has it in STIX 2.1 format, it can not deliver it without creating a new ID. But then it would not be a valid response to the client's request.

The relevant text from the STIX specification is here:

Every representation (each time the object version is serialized and shared) of a version of an object (identified by the object's id and modified properties) MUST always have the same set of properties and the same values for each property. In order to change the value of any property, or to add or remove properties, the modified property MUST be updated with the time of the change to indicate a new version.