Skip to main content

Media Type Suffixes
draft-ietf-mediaman-suffixes-08

Document Type Active Internet-Draft (mediaman WG)
Authors Manu Sporny , Amy Guy
Last updated 2024-09-24 (Latest revision 2024-06-19)
Replaces draft-w3cdidwg-media-types-with-multiple-suffixes
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Associated WG milestone
Oct 2024
Draft about handling multiple suffixes to the IESG for approval (BCP)
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Murray Kucherawy
Send notices to (None)
draft-ietf-mediaman-suffixes-08
MEDIAMAN                                                       M. Sporny
Internet-Draft                                                    A. Guy
Updates: 6838 (if approved)                               Digital Bazaar
Intended status: Standards Track                            19 June 2024
Expires: 21 December 2024

                          Media Type Suffixes
                    draft-ietf-mediaman-suffixes-08

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.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Sporny & Guy            Expires 21 December 2024                [Page 1]
Internet-Draft             Media Type Suffixes                 June 2024

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   2
   2.  Media Type Suffixes . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Common Suffix Patterns  . . . . . . . . . . . . . . . . .   3
     2.2.  Fragment Identifiers  . . . . . . . . . . . . . . . . . .   3
     2.3.  Structured Syntax Name Suffixes . . . . . . . . . . . . .   4
     2.4.  Structured Syntax Suffix Registration Template  . . . . .   4
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     3.1.  Document Validity for Suffixes  . . . . . . . . . . . . .   5
     3.2.  Fragment Semantics for Suffixes . . . . . . . . . . . . .   6
     3.3.  Security Characteristics for Suffixes . . . . . . . . . .   6
     3.4.  Partial Processing of Suffixes  . . . . . . . . . . . . .   6
   4.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Appendix A.  IANA Considerations  . . . . . . . . . . . . . . . .   7
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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

Sporny & Guy            Expires 21 December 2024                [Page 2]
Internet-Draft             Media Type Suffixes                 June 2024

   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.

Sporny & Guy            Expires 21 December 2024                [Page 3]
Internet-Draft             Media Type Suffixes                 June 2024

   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.

Sporny & Guy            Expires 21 December 2024                [Page 4]
Internet-Draft             Media Type Suffixes                 June 2024

   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.

Sporny & Guy            Expires 21 December 2024                [Page 5]
Internet-Draft             Media Type Suffixes                 June 2024

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, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Sporny & Guy            Expires 21 December 2024                [Page 6]
Internet-Draft             Media Type Suffixes                 June 2024

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <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,
              May 2017, <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
   Email: msporny@digitalbazaar.com
   URI:   https://www.linkedin.com/in/manusporny/

Sporny & Guy            Expires 21 December 2024                [Page 7]
Internet-Draft             Media Type Suffixes                 June 2024

   Amy Guy
   Digital Bazaar
   203 Roanoke Street W.
   Blacksburg, VA 24060
   United States of America
   Email: amy@rhiaro.co.uk
   URI:   https://rhiaro.co.uk/

Sporny & Guy            Expires 21 December 2024                [Page 8]