Either use .jsonld or the application/json type, but don't mix both

[darobin]

The TDM policy resource is currently described as being available at /.well-known/tdmrep.json but also served as application/ld+json.

Many servers will have their .well-known implemented as a simple on-disk bucket that the server serves from as static content. The default configuration for .json is application/json across the board. Requiring that people update their HTTP server configuration just for this is expecting too much and could be sufficient on its own to prevent adoption.

One option to fix this is to keep application/ld+json and make the extension .jsonld. This brings the two into alignment, but it has the downside that Web servers are rarely set up to map .jsonld at all, so most of these resources will likely end being served as text/plain or application/octet-stream.

Another option is to keep .json but switch to application/json (or just recommend ignoring the media type). This is, as the name indicates, a well known resource. It is fair to assume that the media type is know, and that the content is expected to be processed as JSON-LD.

I recommend the latter, it's easier and works just as well.

(Note: This is not a hypothetical issue — looking at how to implement this on nytimes.com, this is the difference between just adding a file to a git repo and redeploying configuration to our production CDNs. We had similar problems with the GPC and changed to make it easy on people.)

[llemeurfr]

Another option is to keep .json but switch to application/json (or just recommend ignoring the media type)

This is indeed a simplification without drawback. If nobody disagrees in the next 10 days, I'll update the draft spec accordingly (ignoring the media type is simpler).

[llemeurfr]

To clarify a point: there are two files involved:

• tdmrep.json is a json (not json-ld) file stored in .well-known, by which content providers can express TDM opt-out of different files. It is specified in section 6.1.
• a TDM Policy is an HTML or ODRL file, stored anywhere with no specific name, by which content providers can express conditions on which TDM can be applied on their content. It is introduced in section 5.2 and the machine readable policy is specified in section 7. The mention of a content-type, in section 5.2, is related to the definition of protocol errors when accessing a TDM Policy.

The file extension of an ODRL file can be .json of .jsonld; I therefore propose to accept either application/json or application/ld+json as proper content-type for a machine-readable TDM Policy. I re-phrased part of section 5.2 to reflect that.

Note: This opens a new set of questions: is it a protocol error if the client cannot access the TDM Policy (network issue) or if it cannot parse a machine-readable TDM Policy as an ODRL file (formatting issue)? We'll have to discuss this in another issue.

[llemeurfr]

Note: This opens a new set of questions: is it a protocol error if the client cannot access the TDM Policy (network issue) or if it cannot parse a machine-readable TDM Policy as an ODRL file (formatting issue)? We'll have to discuss this in another issue.

The suppression of value 2 for tdm-reservation solves this issue. Being unable to access or parse a TDM Policy is not a protocol error; simply, the TDM Agent cannot know at this time which conditions would allow it to process the resource.