Internet DRAFT - draft-ietf-mediaman-suffixes
draft-ietf-mediaman-suffixes
MEDIAMAN M. Sporny
Internet-Draft A. Guy
Intended status: Standards Track Digital Bazaar
Expires: 5 July 2023 1 January 2023
Media Types with Multiple Suffixes
draft-ietf-mediaman-suffixes-03
Abstract
This document updates RFC 6838 "Media Type Specifications and
Registration Procedures" to describe how to interpret subtypes with
multiple 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 5 July 2023.
Copyright Notice
Copyright (c) 2023 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 5 July 2023 [Page 1]
Internet-Draft Media Types with Multiple Suffixes January 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 2
2. Media Types with Multiple Suffixes . . . . . . . . . . . . . 2
2.1. Processing Multiple Suffixes . . . . . . . . . . . . . . 3
2.2. Fragment Identifiers . . . . . . . . . . . . . . . . . . 4
2.3. Security Considerations . . . . . . . . . . . . . . . . . 5
2.3.1. Media Type Fibbing . . . . . . . . . . . . . . . . . 5
3. Normative References . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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 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.
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 Types with Multiple Suffixes
The following paragraphs are additions to RFC 6838.
Sporny & Guy Expires 5 July 2023 [Page 2]
Internet-Draft Media Types with Multiple Suffixes January 2023
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 (https://www.iana.org/assignments/media-type-structured-
suffix/media-type-structured-suffix.xhtml).
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.
2.1. 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 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 (https://www.iana.org/assignments/media-type-structured-
suffix/media-type-structured-suffix.xhtml). 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 to any of the following processing models: 1) application/
did+ld+json (as specified in the Media Type Registry
(https://www.iana.org/assignments/media-types/media-types.xhtml)), 2)
+ld+json (as specified in the Structured Syntax Suffixes Registry
(https://www.iana.org/assignments/media-type-structured-suffix/media-
type-structured-suffix.xhtml)), or 3) +json (as specified in the
Sporny & Guy Expires 5 July 2023 [Page 3]
Internet-Draft Media Types with Multiple Suffixes January 2023
Structured Syntax Suffixes Registry
(https://www.iana.org/assignments/media-type-structured-suffix/media-
type-structured-suffix.xhtml)). As a further example, for the media
type "image/svg+xml+gzip", applications can choose to process the
underlying representation according to any of the following
processing models: 1) image/svg+xml+gzip (as specified in the Media
Type Registry (https://www.iana.org/assignments/media-types/media-
types.xhtml)), 2) +gzip (as specified in the Structured Syntax
Suffixes Registry (https://www.iana.org/assignments/media-type-
structured-suffix/media-type-structured-suffix.xhtml)), and then +xml
(as specified in the Structured Syntax Suffixes Registry
(https://www.iana.org/assignments/media-type-structured-suffix/media-
type-structured-suffix.xhtml)).
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
(https://www.iana.org/assignments/media-type-structured-suffix/media-
type-structured-suffix.xhtml) and the 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.
Given this generic structured syntax processing approach, it is
possible to perform structured syntax suffix processing on structured
syntax suffixes that result in an invalid media type that cannot be
processed further. For example, when processing image/svg+xml+gzip,
a processor could choose to process using the +gzip, and then the
+xml structured syntax suffixes rules which would result in a
meaningless application/svg media type. Application developers are
advised to ensure that the last structured syntax suffix, or valid
media type, processed is the last one that is expected to be
meaningfully processed by their application. Thus, an application
that processes the +gzip and then the +xml structured syntax suffixes
from an image/svg+xml+gzip media type expects that the +xml data is
the last meaningful piece of information that it hopes to extract
from the processing pipeline. That is, the application processor is
expected to make a choice between processing as +xml or as image/
svg+xml, and by making a choice, other choices might be removed from
further processing pipeline stages.
2.2. Fragment Identifiers
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:
Sporny & Guy Expires 5 July 2023 [Page 4]
Internet-Draft Media Types with Multiple Suffixes January 2023
1. For cases defined for the structured syntax suffix, where the
fragment identifier does resolve per the structured syntax suffix
rules, then 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 as specified by the specification associated
with the full media type.
3. For cases not defined for the structured syntax suffix, then as
specified by the specification associated with the full media
type.
Other advisory information, such as fragment processing not being
defined in any existing specification, MAY be provided in the
"Fragment Identifier Considerations" column in the IANA Structured
Syntax Suffixes registry as long as the text is terse in nature.
2.3. Security Considerations
2.3.1. Media Type Fibbing
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 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.
3. Normative References
Sporny & Guy Expires 5 July 2023 [Page 5]
Internet-Draft Media Types with Multiple Suffixes January 2023
[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>.
[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. Acknowledgements
The editors would like to thank the following individuals for
feedback on the specification (in alphabetical order): Martin J.
Duerst, Ivan Herman, Graham Klyne, Murray S. Kucherawy, Mark
Nottingham, 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: http://manu.sporny.org/
Amy Guy
Digital Bazaar
203 Roanoke Street W.
Blacksburg, VA 24060
United States of America
Email: rhiaro@digitalbazaar.com
URI: https://rhiaro.co.uk/
Sporny & Guy Expires 5 July 2023 [Page 6]
