Publish YAML RFC blog post

src/posts/yaml-media-type-rfc.md

@@ -0,0 +1,22 @@
+---
+title: '22 years later, YAML now has a media type'
+date: '2024-02-20T15:00'
+cover_image: './header-images/signing.jpg'
+tags: http, openapi, standards
+---
+
+As of February 14th 2024, [RFC 9512](https://www.rfc-editor.org/rfc/rfc9512.html) formally registers `application/yaml` as the media type for all YAML content, and adds `+yaml` as a standard structured suffix for all YAML-based more specific media types. With this registration, it's now included in the official [media types list](https://www.iana.org/assignments/media-types/media-types.xhtml) maintained by the IANA.
+
+Media types like this (also known as the MIME types, from their original invention for email attachment metadata) are heavily used particularly in HTTP `Content-Type` headers for both requests & responses, and in all sorts of file metadata and processing logic elsewhere. These names give applications a common vocabulary to describe data when passing it around.
+
+The additional `+yaml` suffix also defined here is particularly useful. Media type structured suffixes like this (`+xml` and `+json` are other common examples) are used to define specific types for content that's based on an existing generic content type (such as YAML). In this case, this notably opens the door to standardization of other YAML-based MIME types, such as `application/openapi+yaml` (for OpenAPI specifications that are written in YAML) which is currently being formalized in [another standard](https://datatracker.ietf.org/doc/draft-ietf-httpapi-rest-api-mediatypes/), following closely behind this one.
+
+While a few applications have been using `application/yaml` and `+yaml` like this already, many haven't (e.g. Rails [still uses](https://github.com/rails/rails/blob/cd4a5b07332c8b1f1101d43b4db736e7d75dbdc3/actionpack/lib/action_dispatch/http/mime_types.rb#L42) `application/x-yaml`, and others like `text/yaml` and even `text/x-yaml` are frequently seen in the wild) and there's never been clear agreement on exactly how this should work. Hopefully with this RFC we'll be able to start picking a single media type consistently from now on, though updating older applications here will obviously take some time.
+
+[The full RFC](https://www.rfc-editor.org/rfc/rfc9512.html) is well worth a read if you're interested in the finer details, and discusses all sorts of more detailed questions around interoperability for an evolving language like YAML, its relationship with JSON, and the (many) security considerations to be aware of when defining a formal API around YAML data.
+
+This RFC is just one small change of course, but the hard slog of standardization like this is an important process that helps literally keep everybody on the same page. Everybody being able to agree on what YAML is actually called when sharing metadata should make it much easier to build software that more easily & reliably integrates together around YAML data in future.
+
+Congratulations to everybody involved in the RFC and the HTTPAPI working group at the IETF who pushed this through!
+
+_Want to debug your OpenAPI APIs and even inspect YAML HTTP traffic up close? **[Try out HTTP Toolkit](https://httptoolkit.com/)** now._