Media Types with Multiple Suffixes

Media Types with Multiple Suffixes This section is an addition to RFC 6838. Media types MAY be registered with more than one structured suffix appended to the base subtype name. Characters on the left-most side of the left-most "+" in a subtype name specify the base subtype name. The entire structured suffix is all of the characters to the right of the left-most "+" sign in the media type, including the left-most "+" sign itself. The entire structured suffix MAY be composed of one or more broader structured suffixes. As an example, given the "application/foo+bar+baz" media type: "application" is the top-level type, "foo" is the base subtype name, "+bar+baz" is the entire structured suffix, and "+baz" is the broader structured suffix contained in the entire structured suffix.

Processing Multiple Suffixes This section is an addition to RFC 6838. 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 left to right inclusive. In other words, an application can choose to ignore the base subtype name from a media type with multiple suffixes, and process according to the remaining media type suffix(es). This sort of generic processing of a portion of the media type MAY be utilized by a processor that is capable of applying decoding rules associated with the portion of the structured syntax suffix in the Structured Syntax Suffixes Registry. When the entire structured suffix is composed of multiple structured suffixes, those structured suffixes MUST be considered in left-to-right order. This is done by considering the entire structured suffix first, and then dropping the left-most suffix for each iteration of the structured suffix variations that are considered. Note that "considering" a structured suffix variation does not mean that an implementation has to process the data associated with each variation, but it does mean that the variations that are considered do have a valid order in which they are considered. For example, for the media type "application/vc+ld+json", applications can choose to process the underlying representation according to any one of the following processing models, in the following order:

application/vc+ld+json (as specified in the Media Type Registry)
+ld+json (as specified in the Structured Syntax Suffixes Registry)
+json (as specified in the Structured Syntax Suffixes Registry)

This means that a processor considers processing the entire media type first, and then considers variations of the structured suffixes in most specific to least specific (left-to-right) order; for example, "+ld+json" (more specific) and then "+json" (less specific). The processor is never expected to process "+ld" alone when presented with a "application/vc+ld+json" media type for two reasons 1) doing so would be considered interpreting multiple structured suffixes out of order, and 2) "+ld" is not a registered structured suffix type. If an application choses to utilize a portion of the media type that is a structured syntax suffix, the suffix MUST exist as an entry in the Structured Syntax Suffixes Registry and the specification referred to in the "Encoding Considerations" entry of the registry MUST be used for both encoding and decoding the byte stream associated with the media type. In order to gain the most benefit from the media that is presented, and to reduce the security attack surface for processed content, implementations that are able to process multiple suffixes SHOULD process the most specific media type or structured syntax suffix that they are able to process. For processors that choose to process data associated with multiple structured suffixes, if processing data according to any registered structured suffix type fails, further processing on less specific structured suffixes SHOULD NOT be performed.

Fragment Identifiers This section is an addition to RFC 6838. The syntax and semantics for fragment identifiers are specified in the "Fragment Identifier Considerations" column in the IANA Structured Syntax Suffixes registry. In general, when processing fragment identifiers associated with a structured syntax suffix, the following rules SHOULD be followed:

For cases defined for the structured syntax suffix, where the fragment identifier does resolve per the structured syntax suffix rules, then proceed as specified by the specification associated with the "Fragment Identifier Considerations" column in the IANA Structured Syntax Suffixes registry.
For cases defined for the structured syntax suffix, where the fragment identifier does not resolve per the structured syntax suffix rules, then proceed as specified by the specification associated with the full media type.
For cases not defined for the structured syntax suffix, then proceed as specified by the specification associated with the full media type.

Structured Syntax Name Suffixes The following paragraphs are additional guidance to Section 4.2.8 "Structured Syntax Name Suffixes", in RFC 6838. Media types that make use of a named structured syntax, or similar separator such as a dash "-", MUST ensure that the registration is semantically aligned, from a data model perspective, with existing base subtype names in the media type registry. For example, for the media types "application/foo+bar" and "application/foo+baz", the expectation is that the semantics suggested by the base subtype name "application/foo" are the same between both media types. The Designated Expert MUST reject a registration if they believe the semantics for a media type registration does not align with existing base subtype names in the media type registry. Registrants MUST prove to the Designated Expert, such as through an email to a public mailing list or issue tracker comment, that they have consent from the existing Change Controller for the associated base subtype name to register the new media type.

Structured Syntax Suffix Registration Template This section replaces Section 6.2 "Structured Syntax Suffix Registration Template" in RFC 6838. Media types containing more than one structured suffix MUST be registered according to the procedure defined in [RFC6838] and this document. For structured suffixes containing more than one broader structured suffix, the structured suffix to the right of the one being registered MUST also be registered. For example, for the structured suffix "+foo+bar+baz", the registration order is "+baz", then "+bar+baz", and finally "+foo+bar+baz". Structured suffixes containing more than one broader structured suffix MAY register all of the suffixes at the same time. This template describes the fields that must be supplied in a structured syntax suffix registration request:

Name: Full name of the well-defined structured syntax.
+suffix: Suffix used to indicate conformance to the syntax.
References: Include full citations for all specifications necessary to understand the structured syntax.
Encoding considerations: A full citation to a section in a specification that provides general guidance regarding encoding considerations for any type employing this syntax. The same requirements for media type encoding considerations given in Section 4.8 apply here.
Interoperability considerations: A full citation to a section in a specification that documents any issues regarding the interoperable use of types employing this structured syntax should be given here. Examples would include the existence of incompatible versions of the syntax, issues combining certain charsets with the syntax, or incompatibilities with other types or protocols.
Fragment identifier considerations: A full citation to a section in a specification that documents the generic processing rules of fragment identifiers for any type employing this syntax should be described here.
Security considerations: A full citation to a section in a specification that provides security considerations shared by media types employing this structured syntax must be specified here. The same requirements for media type security considerations given in Section 4.6 apply here, with the exception that the option of not assessing the security considerations is not available for suffix registrations.
Contact: Person or organization (including contact information) to contact for further information.
Author/Change controller: Person or organization (including contact information) authorized to change this suffix registration.

Security Considerations This section is an addition to Section 7 "Security Considerations" in RFC 6838.

Document Validity for Suffixes If a toolchain chooses to process a provided media type by using the selected structured suffix processing rules, it cannot presume that a document that is valid per the decoding rules associated with the structured suffix will be valid for a recognized subset of the structured suffix. For example, presuming a media type of "application/foo+bar+baz", a toolchain cannot presume that a valid "+baz" document will also be a valid "+bar+baz" document nor a valid "application/foo+bar+baz" document. On the other hand, presuming a media type of "application/foo+bar+baz", a toolchain can presume that a valid "application/foo+bar+baz" document will also be a valid "+bar+baz" document and a valid "+baz" document.

Fragment Semantics for Suffixes If a toolchain chooses to process a provided media type by using the selected structured suffix processing rules, it cannot presume that fragment identifier semantics will be the same across a recognized subset of the structured suffix. For example, presuming a media type of "application/foo+bar+baz", a toolchain cannot presume that the fragment semantics for a "+baz" document will be the same as for a "+bar+baz" document or the same as for an "application/foo+bar+baz" document.

Security Characteristics for Suffixes Toolchains cannot assume that the security characteristics of processing based on structured suffixes will be the same for the entire media type nor for any combination of recognized structured suffixes. For example, presuming a media type of "application/foo+bar+baz", a toolchain cannot presume that the security considerations for a "+baz" document will be the same as for a "+bar+baz" document nor the same for an "application/foo+bar+baz" document.

Partial Processing of Suffixes It is possible for an 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 might then directly invoke Microsoft Excel, 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. Enterprising attackers might take advantage of toolchains that partially process media types in this manner. Toolchains that process media types based purely on a structured suffix need to ensure that further processing does not blindly trust the decoded data, and that proper magic header or file structure checking is performed, before allowing the decoded data to drive operations that might negatively impact the application environment or operating system.