Internet-Draft Media Types with Multiple Suffixes November 2021
Sporny & Guy Expires 25 May 2022 [Page]
Intended Status:
Standards Track
M.S. Sporny
Digital Bazaar
A.G. Guy
Digital Bazaar

Media Types with Multiple Suffixes


This document updates RFC 6838 "Media Type Specifications and Registration Procedures" to describe how to interpret subtypes with multiple suffixes.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 5 May 2022.

Table of Contents

1. Introduction

As written, RFC 6838 [RFC6838] permits the registration of media type subtype names which contain any number of occurrences of the "+" character. RFC 6838 defines the characters following the final "+" to be a structured syntax suffix, but does not define anything further about how to interpret subtype names containing more than one "+" character.

This document updates RFC 6838 to clarify how to interpret subtype names containing more than one "+" character as subtypes with multiple suffixes.

As registration of media types which use a structured suffix has become widely supported, this enables further specialization of media types that build on already registered and well-defined media types which themselves use a structured suffix.

1.1. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. They may also appear in lower or mixed case as plain English words, without any normative meaning.

2. Media Types with Multiple Suffixes

The following paragraphs are additions to RFC 6838.

Media types MAY be registered with more than one suffix appended to the base subtype name. The suffixes MUST be interpreted as ordered. Valid media type names containing a structured suffix are built from right to left (not left to right). Characters on the left-most side of the left-most "+" in a subtype name specify the base subtype name. Characters to the right of each "+" in a subtype name denote additional structured syntax specifier suffixes.

Media types with more than one suffix MUST be registered according to the procedure defined in [RFC6838]. A new base subtype name MUST only be registered with suffix combinations that are already registered in their own right.

For example, a media type that uses the two suffixes "+svg+xml" is only permitted insofar as "svg+xml" is already registered. In this case, the suffix "+svg" does not need to be registered individually, but "+xml" and "svg+xml" MUST be registered.

2.1. Processing Multiple Suffixes

Registered subtypes have clear processing rules. In cases where specific handling of the exact media type is not required, receivers of the media type MAY do generic processing on the underlying representation according to their ability to process any subset of the suffix(es) from right to left inclusive. In other words, an application can choose to ignore the base subtype name and left-most "+" from a media type with multiple suffixes, and process according to the remaining media type suffix(es). An application can ignore as many of the left-most suffixes as necessary to achieve a media type that can be processed.

For example, for the media type "application/did+ld+json", the following are all valid subtypes with their own individually specified processing rules:


Thus applications can choose to process the underlying representation according any of the following valid media types:


3. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, , <>.

Appendix A. Acknowledgements

The editors would like to thank the following individuals for feedback on the specification (in alphabetical order): Martin J. Duerst, Ivan Herman, Graham Klyne, Murray S. Kucherawy, Manu Sporny, Ted Thibodeau Jr.

Authors' Addresses

Manu Sporny
Digital Bazaar
203 Roanoke Street W.
Blacksburg, VA 24060
United States of America
Amy Guy
Digital Bazaar
203 Roanoke Street W.
Blacksburg, VA 24060
United States of America