index.xml

<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xsl" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="yes" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
  submissionType="IETF" docName="draft-ietf-mediaman-suffixes-08"
  updates="6838" tocInclude="true" sortRefs="true" symRefs="true"
  version="2">

<front>

  <title>Media Type Suffixes</title>
  <seriesInfo name="Internet-Draft" value="draft-ietf-mediaman-suffixes-08"/>
  <author initials="M." surname="Sporny" fullname="Manu Sporny">
    <organization>Digital Bazaar</organization>
    <address>
      <postal>
        <street>203 Roanoke Street W.</street>
        <city>Blacksburg</city>
        <region>VA</region>
        <code>24060</code>
        <country>US</country>
      </postal>
      <email>msporny@digitalbazaar.com</email>
      <uri>https://www.linkedin.com/in/manusporny/</uri>
    </address>
  </author>

  <author initials="A." surname="Guy" fullname="Amy Guy">
    <organization>Digital Bazaar</organization>
    <address>
      <postal>
        <street>203 Roanoke Street W.</street>
        <city>Blacksburg</city>
        <region>VA</region>
        <code>24060</code>
        <country>US</country>
      </postal>
      <email>amy@rhiaro.co.uk</email>
      <uri>https://rhiaro.co.uk/</uri>
    </address>
  </author>

  <date month="June" day="19" year="2024" />
  <area>Internet</area>
  <workgroup>MEDIAMAN</workgroup>

  <abstract>
    <t>
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.
    </t>
  </abstract>

</front>
<middle>
  <section anchor="intro">
    <name>Introduction</name>
    <t>
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.
    </t>
    <t>
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.
    </t>

    <section anchor="conventions">
      <name>Conventions Used in This Document</name>
      <t>
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.
      </t>
    </section>
  </section>

  <section anchor="media-type-suffixes">
    <name>Media Type Suffixes</name>
    <t>
This section is an addition to RFC 6838.
    </t>
    <t>
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.
    </t>

    <section anchor="patterns">
      <name>Common Suffix Patterns</name>
      <t>
This section is an addition to RFC 6838.
      </t>

      <t>
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:
      </t>

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

      <t>
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.
      </t>

    </section>

    <section anchor="fragments">
      <name>Fragment Identifiers</name>
      <t>
This section is an addition to RFC 6838.
      </t>
      <t>
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:
      </t>
      <ol>
        <li>
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.
        </li>
        <li>
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.
        </li>
        <li>
For cases not defined for the structured syntax suffix, then proceed as
specified by the specification associated with the full media type.
        </li>
      </ol>
    </section>

    <section anchor="structured-syntax-name-suffixes">
      <name>Structured Syntax Name Suffixes</name>
      <t>
The following paragraphs are additional guidance to Section 4.2.8
"Structured Syntax Name Suffixes", in RFC 6838.
      </t>

      <t>
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.
      </t>

      <t>
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.
      </t>

    </section>

    <section anchor="structured-syntax-suffix-registration-template">
      <name>Structured Syntax Suffix Registration Template</name>
      <t>
This section replaces Section 6.2 "Structured Syntax Suffix Registration
Template" in RFC 6838.
      </t>
      <t>
This template describes the fields that must be supplied in a structured syntax
suffix registration request:
      </t>

      <dl newline="true">
        <dt>Name</dt>
        <dd>
Full name of the well-defined structured syntax.
        </dd>

        <dt>+suffix</dt>
        <dd>
Suffix used to indicate conformance to the syntax.
        </dd>

        <dt>References</dt>
        <dd>
Include full citations for all specifications necessary to understand the
structured syntax.
        </dd>

        <dt>Encoding considerations</dt>
        <dd>
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.
        </dd>

        <dt>Interoperability considerations</dt>
        <dd>
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.
        </dd>

        <dt>Fragment identifier considerations</dt>
        <dd>
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.
        </dd>

        <dt>Security considerations</dt>
        <dd>
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.
        </dd>

        <dt>Contact</dt>
        <dd>
Person or organization (including contact information) to contact for further
information.
        </dd>

        <dt>Author/Change controller</dt>
        <dd>
Person or organization (including contact information) authorized to change this
suffix registration.
        </dd>
      </dl>
    </section>
  </section>

  <section anchor="security-considerations">
    <name>Security Considerations</name>

    <t>
This section is an addition to Section 7 "Security Considerations" in RFC 6838.
    </t>

    <section anchor="ss-validity">
      <name>Document Validity for Suffixes</name>
      <t>
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 <em>can</em> presume that a valid "application/foo+bar" document
will also be a valid "+bar" document.
      </t>
    </section>

    <section anchor="ss-fragments">
      <name>Fragment Semantics for Suffixes</name>
      <t>
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.
      </t>
    </section>

    <section anchor="ss-security">
      <name>Security Characteristics for Suffixes</name>
      <t>
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.
      </t>
    </section>

    <section anchor="ss-partial-processing">
      <name>Partial Processing of Suffixes</name>
      <t>
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.
      </t>
      <t>
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.
      </t>
    </section>
  </section>

</middle>

<back>

  <references>
    <name>Normative References</name>
    <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
      <front>
        <title>Key words for use in RFCs to Indicate Requirement Levels</title>
        <author initials="S." surname="Bradner" fullname="S. Bradner">
          <organization />
        </author>
        <date year="1997" month="March" />
      </front>
      <seriesInfo name="BCP" value="14" />
      <seriesInfo name="RFC" value="2119" />
      <seriesInfo name="DOI" value="10.17487/RFC2119" />
    </reference>
    <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
      <front>
        <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
        <author initials="B." surname="Leiba" fullname="B. Leiba">
          <organization />
        </author>
        <date year="2017" month="May" />
      </front>
      <seriesInfo name="BCP" value="14" />
      <seriesInfo name="RFC" value="8174" />
      <seriesInfo name="DOI" value="10.17487/RFC8174" />
    </reference>
    <reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6838">
      <front>
        <title>Media Type Specifications and Registration Procedures</title>
        <author initials="N." surname="Freed" fullname="N. Freed">
          <organization />
        </author>
        <author initials="J." surname="Klensin" fullname="J. Klensin">
          <organization />
        </author>
        <author initials="T." surname="Hansen" fullname="T. Hansen">
          <organization />
        </author>
        <date year="2013" month="January" />
      </front>
      <seriesInfo name="BCP" value="13" />
      <seriesInfo name="RFC" value="6838" />
      <seriesInfo name="DOI" value="10.17487/RFC6838" />
    </reference>
  </references>

  <section anchor="iana-considerations">
    <name>IANA Considerations</name>

    <t>
[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.
    </t>

    <t>
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.
    </t>
  </section>

  <section anchor="acknowledgements">
    <name>Acknowledgements</name>
    <t>
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.
    </t>
  </section>

</back>
</rfc>