3 ms·

It could just be following the analogy of application/json. Which in turn raises the same question about json... here FWIW is Crockford's theory :) > But overa

It could just be following the analogy of application/json. Which in turn raises the same question about json... here FWIW is Crockford's theory :) > But overall, it was a really painful process. And in the end, I didn’t even get the mime type I wanted. I wanted Text/JSON. They gave me Application/JSON, which was weird because JSON is not an application, it’s a text format. It’s a way of representing data in text. And I think maybe that… Well, I don’t know why they’ve forced that on me. I’d like to think it’s because there were some XML fans who were resentful about what I’d been doing and decided that I didn’t deserve to have text that was reserved for XML. So they got text XML, but I got Application/JSON, which didn’t affect me personally at all, but for the people who use it, it’s not a big deal. It’s a little ugliness in the header. https://corecursive.com/json-vs-xml-douglas-crockford/ https://corecursive.com/json-vs-xml-douglas-crockford/

deleted 3y ago
[deleted]
aezart 3y ago
We have an integration at work that sends copies of the same message to two different servers running the same software, and one requires text/xml and the other requires application/xml.
lifthrasiir 3y ago
RFC 6838 is clear about the `text` top-level type [1]: > The "text" top-level type is intended for sending material that is principally textual in form. [...] Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In comparison, if `text/*` should be used for any format that encodes something in a text format as Crockford wanted, then you can put every file format into `text/*` with base64 encoding in principle. Limiting `text/*` to the data that is textual in nature avoids this issue by setting a reasonable expectation [2]. It is even possible to register `text/vnd.foobar+json` if you want, because a structured syntax suffix `+json` doesn't affect the top-level type. But JSON in general doesn't guarantee any textual data even after processing. [1] https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1 https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1 [2] Therefore `text/rtf` is possible when it doesn't embed any additional object, otherwise `application/rtf` should be used. It is debatable whether a source code is a text or not however, especially when it can be executed in place. The transition from `application/javascript` to `text/javascript` [3] is one example. [3] https://datatracker.ietf.org/doc/html/rfc9239 https://datatracker.ietf.org/doc/html/rfc9239

deleted 3y ago

[deleted]

aezart 3y ago

We have an integration at work that sends copies of the same message to two different servers running the same software, and one requires text/xml and the other requires application/xml.

lifthrasiir 3y ago

RFC 6838 is clear about the `text` top-level type [1]: > The "text" top-level type is intended for sending material that is principally textual in form. [...] Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In comparison, if `text/*` should be used for any format that encodes something in a text format as Crockford wanted, then you can put every file format into `text/*` with base64 encoding in principle. Limiting `text/*` to the data that is textual in nature avoids this issue by setting a reasonable expectation [2]. It is even possible to register `text/vnd.foobar+json` if you want, because a structured syntax suffix `+json` doesn't affect the top-level type. But JSON in general doesn't guarantee any textual data even after processing. [1] https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1 https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.1 [2] Therefore `text/rtf` is possible when it doesn't embed any additional object, otherwise `application/rtf` should be used. It is debatable whether a source code is a text or not however, especially when it can be executed in place. The transition from `application/javascript` to `text/javascript` [3] is one example. [3] https://datatracker.ietf.org/doc/html/rfc9239 https://datatracker.ietf.org/doc/html/rfc9239