4 ms·

Does anyone know what's the rationale for settling on application/yaml instead of text/yaml? Couldn't find on within the text.

by mhitza 3y ago

vbernat 3y ago
Same as for application/json I suppose: this is a structured format to be processed by an application, not by humans directly.
wiktor-k 3y ago
There's one issue with text, it defaults to ASCII: > For example, for any MIME type whose main type is text, you can add the optional charset parameter to specify the character set used for the characters in the data. If no charset is specified, the default is ASCII (US-ASCII) unless overridden by the user agent's settings. To specify a UTF-8 text file, the MIME type text/plain;charset=UTF-8 is used. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_...
- paulddraper 3y ago
  Many text types default to other encodings. E.g. text/vcard https://www.iana.org/assignments/media-types/text/vcard https://www.iana.org/assignments/media-types/text/vcard
- arp242 3y ago
  That's fine, no? Not like application/anything can default to the correct character set. This is why everyone typically uses application/json; charset=UTF-8.
- creatonez 3y ago
  If you don't have a content type, you're screwed no matter what you do. Web browsers use a goofy detection system that sometimes works and sometimes fails, because it only reads the beginning of the file.
michael1999 3y ago
Agree this should be addressed. They explicitly deprecate text/yaml, but don't justify the choice. I could speculate that the YAML spec assumes full Unicode repertoire, and the only choices are UTF-8/16/32 BE/LE. But text/* allows (encourages) middle-boxes to guess and translate encodings to local standards (e.g. sniff Latin-1 and "helpfully" rewrite to 8859-9) to allow legacy clients to read text. A yaml file is more data than text, so text/* isn't appropriate. Similar to application/json. Not sure I agree, but my smallest complaint about yaml.
p1mrx 3y ago
https://github.com/ietf-wg-httpapi/mediatypes/issues/11 https://github.com/ietf-wg-httpapi/mediatypes/issues/11 > While I strongly support defining the application/yaml media type, I do not think that the text/yaml should be defined at this time. [...] Defining more than one media type is superfluous, and creates unnecessary uncertainty. The bare-text presentation of YAML content to a human is already now achievable by presenting YAML as text/plain
slim 3y ago
https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5 https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5
treffer 3y ago
So I got curious, nice questions. RFC6838: Expected uses for the "application" type name include but are not limited to file transfer, spreadsheets, presentations, scheduling data, and languages for "active" (computational) material. "File transfer" sounds to me like the distinction is: if you would expect to show it in a browser directly use audio/text/image/.... - otherwise it's application. This sounds OK for yaml. You _can_ still serve it as text/plain if you want to show it as text, but as yaml it's probably for download purposes. Btw, the RFC discussions are open. You can join an IETF mailinglist and start discussing such topics :-)
- 01HNNWZ0MV43FF 3y ago
  eh I'm holding out for an email service that doesn't need a blood oath to sign up
aloisklink 3y ago
One reason might be that `text/*` files follow the POSIX standard for text files [1], where no lines can exceed `{LINE_MAX}` bytes in length (and `LINE_MAX` depends on your OS). I don't believe the YAML spec has any rules on how long lines can be, so this means that some files won't technically be text files. (and some UNIX tools line-based tools might not work correctly on them). [1]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
aragonite 3y ago
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

Does anyone know what's the rationale for settling on application/yaml instead of text/yaml? Couldn't find on within the text.

by mhitza 3y ago

Does anyone know what's the rationale for settling on application/yaml instead of text/yaml? Couldn't find on within the text.

vbernat 3y ago

Same as for application/json I suppose: this is a structured format to be processed by an application, not by humans directly.

wiktor-k 3y ago

There's one issue with text, it defaults to ASCII: > For example, for any MIME type whose main type is text, you can add the optional charset parameter to specify the character set used for the characters in the data. If no charset is specified, the default is ASCII (US-ASCII) unless overridden by the user agent's settings. To specify a UTF-8 text file, the MIME type text/plain;charset=UTF-8 is used. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_...

paulddraper 3y ago
Many text types default to other encodings. E.g. text/vcard https://www.iana.org/assignments/media-types/text/vcard https://www.iana.org/assignments/media-types/text/vcard
arp242 3y ago
That's fine, no? Not like application/anything can default to the correct character set. This is why everyone typically uses application/json; charset=UTF-8.
creatonez 3y ago
If you don't have a content type, you're screwed no matter what you do. Web browsers use a goofy detection system that sometimes works and sometimes fails, because it only reads the beginning of the file.

michael1999 3y ago

Agree this should be addressed. They explicitly deprecate text/yaml, but don't justify the choice. I could speculate that the YAML spec assumes full Unicode repertoire, and the only choices are UTF-8/16/32 BE/LE. But text/* allows (encourages) middle-boxes to guess and translate encodings to local standards (e.g. sniff Latin-1 and "helpfully" rewrite to 8859-9) to allow legacy clients to read text. A yaml file is more data than text, so text/* isn't appropriate. Similar to application/json. Not sure I agree, but my smallest complaint about yaml.

p1mrx 3y ago

https://github.com/ietf-wg-httpapi/mediatypes/issues/11 https://github.com/ietf-wg-httpapi/mediatypes/issues/11 > While I strongly support defining the application/yaml media type, I do not think that the text/yaml should be defined at this time. [...] Defining more than one media type is superfluous, and creates unnecessary uncertainty. The bare-text presentation of YAML content to a human is already now achievable by presenting YAML as text/plain

slim 3y ago

https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5 https://datatracker.ietf.org/doc/html/rfc6838#section-4.2.5

treffer 3y ago

So I got curious, nice questions. RFC6838: Expected uses for the "application" type name include but are not limited to file transfer, spreadsheets, presentations, scheduling data, and languages for "active" (computational) material. "File transfer" sounds to me like the distinction is: if you would expect to show it in a browser directly use audio/text/image/.... - otherwise it's application. This sounds OK for yaml. You _can_ still serve it as text/plain if you want to show it as text, but as yaml it's probably for download purposes. Btw, the RFC discussions are open. You can join an IETF mailinglist and start discussing such topics :-)

01HNNWZ0MV43FF 3y ago
eh I'm holding out for an email service that doesn't need a blood oath to sign up

aloisklink 3y ago

One reason might be that `text/*` files follow the POSIX standard for text files [1], where no lines can exceed `{LINE_MAX}` bytes in length (and `LINE_MAX` depends on your OS). I don't believe the YAML spec has any rules on how long lines can be, so this means that some files won't technically be text files. (and some UNIX tools line-based tools might not work correctly on them). [1]: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

aragonite 3y ago

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