Content-Type specs should be clear about application/ld+json *without* a profile

[azaroth42]

Source: https://github.com/IIIF/api/pull/1993#discussion_r622415587

The Presentation and Image APIs are clear that the content-type for the HTTP response should be application/ld+json;profile="(context)" with a fallback to the default json content type if there isn't fine grained control over the header value. However it is not clear if application/ld+json without the profile parameter is preferred over the vanilla JSON value.

Suggested change, as per Change Discovery API is to clarify that it's either ld+json with the profile, or application/json if not.

If the above Content-Type header value cannot be generated, then the value SHOULD instead be application/json (regular JSON), without a profile parameter.

[jpstroop]

Based on the Slack convo, what about:

If the appropriate JSON-LD Content-Type header, including a profile parameter, cannot be supplied, then the Content-Type value SHOULD ...

[mcwhitaker]

The Image and Presentation APIs, right before where this sentence would go, mentions the need for the profile parameter and shows the example with the profile parameter, so the above Content-Type header value refers to a value that includes the profile parameter. That is clear enough to me, but I do not oppose making it even more clear if others would prefer.