We currently use the same .json extension for both chapters.json and transcript.json which means that we can't define a deterministic mapping from file type extensions to MIME type. One use case is that it allows you to configure a web server to automatically set the Content-Type response header based on the file name extension, but also allows desktop applications to associate the correct application to open a file based on its file name (e.g. double clicking on a chapters file could some day open a desktop app for editing chapters).
I think we can come up with a specific extension for each different file type, and I also think there should probably not be an issue with continuing to support the original .json extension for backwards compatibility, because current podcast apps will open whatever filename is in the link.
We currently use the same
.jsonextension for bothchapters.jsonandtranscript.jsonwhich means that we can't define a deterministic mapping from file type extensions to MIME type. One use case is that it allows you to configure a web server to automatically set theContent-Typeresponse header based on the file name extension, but also allows desktop applications to associate the correct application to open a file based on its file name (e.g. double clicking on a chapters file could some day open a desktop app for editing chapters).I think we can come up with a specific extension for each different file type, and I also think there should probably not be an issue with continuing to support the original
.jsonextension for backwards compatibility, because current podcast apps will open whatever filename is in the link.