Media Types with Multiple Suffixes
Digital Bazaar
203 Roanoke Street W.
Blacksburg
VA
24060
US
msporny@digitalbazaar.com
http://manu.sporny.org/
Digital Bazaar
203 Roanoke Street W.
Blacksburg
VA
24060
US
rhiaro@digitalbazaar.com
https://rhiaro.co.uk/
Internet
MEDIAMAN
This document updates RFC 6838 "Media Type Specifications and Registration
Procedures" to describe how to interpret subtypes with multiple suffixes.
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.
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.
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 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 in the
Structured Syntax Suffixes registry.
For example, a media type that uses two suffixes, such as
"application/foo+xml+gzip" is only permitted insofar as "+gzip" and "+xml"
are already registered structured syntax suffixes.
Processing Multiple Suffixes
Registered media types 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).
This sort of generic processing MAY be utilized in a processing pipeline where
each segment of the pipeline handles a particular structured syntax suffix by
applying decoding rules associated with the structured syntax suffix in the
Structured Syntax Suffixes Registry.
The segment of the pipleine could then remove the structured syntax suffix
from the media type and then pass the output of the decoding operation as well
as the modified media type further down the pipeline.
For example, for the media type "application/did+ld+json", applications can
choose to process the underlying representation according any of the following
processing models: 1) application/did+ld+json
(as specified in the Media Type Registry),
2) +ld+json (as specified in the Structured Syntax Suffixes Registry),
or 3) +json (as specified in the Structured Syntax Suffixes Registry).
As a further example, for the media type "image/svg+xml+gzip", applications can
choose to process the underlying representation according any of the following
processing models: 1) image/svg+xml+gzip
(as specified in the Media Type Registry),
2) +gzip (as specified in the Structured Syntax Suffixes Registry),
and then +xml (as specified in the Structured Syntax Suffixes Registry).
If an application choses to utilize a portion of the media type that is a
structured syntax suffix, the specification referred to in the the "Encoding
Considerations" entry of the
Structured Syntax Suffixes Registry MUST be used for both encoding and
decoding the byte stream associated with the media type.
Security Considerations
Media Type Fibbing
It is possible for attacker to utilize multiple structured suffixes in a way
that tricks unsuspecting toolchains into skipping important security checks
and allowing viruses to propagate. For example, an attacker might utilize an
"application/vnd.ms-excel.addin.macroEnabled.12+zip" structured suffix to
trigger an unzip process that would then invoke Microsoft Excel directly,
bypassing anti-virus tooling that would otherwise block a macro-enabled MS
Excel file containing a virus of some kind from being scanned or opened.
While the liklihood of these sorts of attacks are low, they are not zero and
enterprising attackers might take advantage of applications that carelessly
register themselves in a structured suffix processing toolchain. These sorts
of toolchains need to ensure that the incoming media type is not blindly
trusted and that proper magic header or file structure checking is performed
before allowing the encoded data to drive operations that might negatively
impact the application environment or operating system.
Normative References
Acknowledgements
The editors would like to thank the following individuals for feedback on the
specification (in alphabetical order): Martin J. Dürst, Ivan Herman, Graham
Klyne, Murray S. Kucherawy, Mark Nottingham, and Ted Thibodeau Jr.