Internet-Draft Media Type Suffixes June 2024
Sporny & Guy Expires 21 December 2024 [Page]
Workgroup:
MEDIAMAN
Internet-Draft:
draft-ietf-mediaman-suffixes-08
Updates:
6838 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
M. Sporny
Digital Bazaar
A. Guy
Digital Bazaar

Media Type Suffixes

Abstract

This document updates RFC 6838 "Media Type Specifications and Registration Procedures" to provide additional clarifications on how to interpret and register media types with 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 https://datatracker.ietf.org/drafts/current/.

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 21 December 2024.

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 first "+" character 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 that using more than one "+" character is not allowed. It also provides additional guidance that might be useful to specification authors that are registering media types with structured suffixes.

1.1. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Media Type Suffixes

This section is an addition to RFC 6838.

A structured suffix is defined as all of the characters to the right of the left-most "+" sign in a media type, including the left-most "+" sign itself. The structured suffix MUST NOT contain more than one "+" sign. As an example, given the "application/foo+bar" media type: "application" is the top-level type, "foo" is the base subtype name, and "+bar" is the structured suffix. A media type such as "application/foo+bar+baz" is not allowed.

2.1. Common Suffix Patterns

This section is an addition to RFC 6838.

There are a few common patterns that are utilized for media types that use structured suffixes. These patterns include expressing that the data associated with a media type:

  • Utilizes a structured data format such as "+xml", "+json", "+yaml", or "+cbor".
  • Is compressed using a binary compression format such as "+zip" or "+gzip".
  • Is encoded in a digitally signature format such as "+jwt" or "+cose".

While it is conceivable that suffixes such as "+xml+zip" are possible, such usage is NOT RECOMMENDED due to the large number of combinatorial possibilities that could occur and the negative impact that might have on security considerations for toolchains that attempt to safely process all of the possibilities.

2.2. 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:

  1. 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.
  2. 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.
  3. For cases not defined for the structured syntax suffix, then proceed as specified by the specification associated with the full media type.

2.3. 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.

2.4. Structured Syntax Suffix Registration Template

This section replaces Section 6.2 "Structured Syntax Suffix Registration Template" in RFC 6838.

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.

3. Security Considerations

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

3.1. 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", a toolchain cannot presume that a valid "+bar" document will also be a valid "application/foo" document. On the other hand, presuming a media type of "application/foo+bar", a toolchain can presume that a valid "application/foo+bar" document will also be a valid "+bar" document.

3.2. 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", a toolchain cannot presume that the fragment semantics for a "+bar" document will be the same as for an "application/foo+bar" document.

3.3. 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. For example, presuming a media type of "application/foo+bar", a toolchain cannot presume that the security characteristics for a "+bar" document will be the same as for a "application/foo+bar" document.

3.4. Partial Processing of Suffixes

It is conceivable that an attacker could utilize 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.

4. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC6838]
Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, , <https://www.rfc-editor.org/info/rfc6838>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

Appendix A. IANA Considerations

[RFC6838] established the Registration Procedure for the Structured Syntax Suffixes Registry as "Expert Review". However, since the inception of the registry, the Designated Experts have been operating as if the Registration Procedure is "Specification Required" given that a specification is required in the registration template for the "References" entry, which defines how the structured suffix is to be used. Every entry in the Structured Syntax Suffixes Registry contains at least one reference to a specification. Furthermore, this document updates the Structured Syntax Suffixes Registry Registration Template to include links to specifications for most fields. Therefore, there is a clear requirement for at least one specification when performing a Structured Syntax Suffix registration.

This section updates the Registration Procedure for the Structured Syntax Suffixes Registry to "Specification Required" and instructs IANA to update the existing registry to reflect this change.

Appendix B. Acknowledgements

The editors would like to thank the following individuals for feedback on the specification (in alphabetical order): Harald Alvestrand, Amanda Baber, Martin J. Dürst, Ivan Herman, Graham Klyne, Murray S. Kucherawy, Darrel Miller, Mark Nottingham, Roberto Polli, Orie Steele, and 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