Closed darobin closed 2 years ago
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).
To clarify a point: there are two files involved:
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.
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.
The TDM policy resource is currently described as being available at
/.well-known/tdmrep.json
but also served asapplication/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
isapplication/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 astext/plain
orapplication/octet-stream
.Another option is to keep
.json
but switch toapplication/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.)