idnits 2.17.00 (12 Aug 2021) /tmp/idnits56748/draft-ietf-mediaman-suffixes-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (February 2022) is 88 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEDIAMAN M. Sporny 3 Internet-Draft A. Guy 4 Updates: 6838 (if approved) Digital Bazaar 5 Intended status: Standards Track February 2022 6 Expires: 25 August 2022 8 Media Types with Multiple Suffixes 9 draft-ietf-mediaman-suffixes-01 11 Abstract 13 This document updates RFC 6838 "Media Type Specifications and 14 Registration Procedures" to describe how to interpret subtypes with 15 multiple suffixes. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 5 August 2022. 34 Copyright Notice 36 Copyright (c) 2022 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 52 2. Media Types with Multiple Suffixes . . . . . . . . . . . . . 2 53 2.1. Processing Multiple Suffixes . . . . . . . . . . . . . . 3 54 2.2. Security Considerations . . . . . . . . . . . . . . . . . 4 55 2.2.1. Media Type Fibbing . . . . . . . . . . . . . . . . . 4 56 3. Normative References . . . . . . . . . . . . . . . . . . . . 4 57 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 60 1. Introduction 62 As written, RFC 6838 [RFC6838] permits the registration of media type 63 subtype names which contain any number of occurrences of the "+" 64 character. RFC 6838 defines the characters following the final "+" 65 to be a structured syntax suffix, but does not define anything 66 further about how to interpret subtype names containing more than one 67 "+" character. 69 This document updates RFC 6838 to clarify how to interpret subtype 70 names containing more than one "+" character as subtypes with 71 multiple suffixes. 73 As registration of media types which use a structured suffix has 74 become widely supported, this enables further specialization of media 75 types that build on already registered and well-defined media types 76 which themselves use a structured suffix. 78 1.1. Conventions Used in This Document 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119] when they 83 appear in ALL CAPS. They may also appear in lower or mixed case as 84 plain English words, without any normative meaning. 86 2. Media Types with Multiple Suffixes 88 The following paragraphs are additions to RFC 6838. 90 Media types MAY be registered with more than one suffix appended to 91 the base subtype name. The suffixes MUST be interpreted as ordered. 92 Valid media type names containing a structured suffix are built from 93 right to left (not left to right). Characters on the left-most side 94 of the left-most "+" in a subtype name specify the base subtype name. 95 Characters to the right of each "+" in a subtype name denote 96 additional structured syntax suffixes. 98 Media types with more than one suffix MUST be registered according to 99 the procedure defined in [RFC6838]. A new base subtype name MUST 100 only be registered with suffix combinations that are already 101 registered in their own right in the Structured Syntax Suffixes 102 registry (https://www.iana.org/assignments/media-type-structured- 103 suffix/media-type-structured-suffix.xhtml). 105 For example, a media type that uses two suffixes, such as 106 "application/foo+xml+gzip" is only permitted insofar as "+gzip" and 107 "+xml" are already registered structured syntax suffixes. 109 2.1. Processing Multiple Suffixes 111 Registered media types have clear processing rules. In cases where 112 specific handling of the exact media type is not required, receivers 113 of the media type MAY do generic processing on the underlying 114 representation according to their ability to process any subset of 115 the suffix(es) from right to left inclusive. In other words, an 116 application can choose to ignore the base subtype name and left-most 117 "+" from a media type with multiple suffixes, and process according 118 to the remaining media type suffix(es). 120 This sort of generic processing MAY be utilized in a processing 121 pipeline where each segment of the pipeline handles a particular 122 structured syntax suffix by applying decoding rules associated with 123 the structured syntax suffix in the Structured Syntax Suffixes 124 Registry (https://www.iana.org/assignments/media-type-structured- 125 suffix/media-type-structured-suffix.xhtml). The segment of the 126 pipleine could then remove the structured syntax suffix from the 127 media type and then pass the output of the decoding operation as well 128 as the modified media type further down the pipeline. 130 For example, for the media type "application/did+ld+json", 131 applications can choose to process the underlying representation 132 according any of the following processing models: 1) application/ 133 did+ld+json (as specified in the Media Type Registry 134 (https://www.iana.org/assignments/media-types/media-types.xhtml)), 2) 135 +ld+json (as specified in the Structured Syntax Suffixes Registry 136 (https://www.iana.org/assignments/media-type-structured-suffix/media- 137 type-structured-suffix.xhtml)), or 3) +json (as specified in the 138 Structured Syntax Suffixes Registry 139 (https://www.iana.org/assignments/media-type-structured-suffix/media- 140 type-structured-suffix.xhtml)). As a further example, for the media 141 type "image/svg+xml+gzip", applications can choose to process the 142 underlying representation according any of the following processing 143 models: 1) image/svg+xml+gzip (as specified in the Media Type 144 Registry (https://www.iana.org/assignments/media-types/media- 145 types.xhtml)), 2) +gzip (as specified in the Structured Syntax 146 Suffixes Registry (https://www.iana.org/assignments/media-type- 147 structured-suffix/media-type-structured-suffix.xhtml)), and then +xml 148 (as specified in the Structured Syntax Suffixes Registry 149 (https://www.iana.org/assignments/media-type-structured-suffix/media- 150 type-structured-suffix.xhtml)). 152 If an application choses to utilize a portion of the media type that 153 is a structured syntax suffix, the specification referred to in the 154 the "Encoding Considerations" entry of the Structured Syntax Suffixes 155 Registry (https://www.iana.org/assignments/media-type-structured- 156 suffix/media-type-structured-suffix.xhtml) MUST be used for both 157 encoding and decoding the byte stream associated with the media type. 159 2.2. Security Considerations 161 2.2.1. Media Type Fibbing 163 It is possible for attacker to utilize multiple structured suffixes 164 in a way that tricks unsuspecting toolchains into skipping important 165 security checks and allowing viruses to propagate. For example, an 166 attacker might utilize an "application/vnd.ms- 167 excel.addin.macroEnabled.12+zip" structured suffix to trigger an 168 unzip process that would then invoke Microsoft Excel directly, 169 bypassing anti-virus tooling that would otherwise block a macro- 170 enabled MS Excel file containing a virus of some kind from being 171 scanned or opened. 173 While the liklihood of these sorts of attacks are low, they are not 174 zero and enterprising attackers might take advantage of applications 175 that carelessly register themselves in a structured suffix processing 176 toolchain. These sorts of toolchains need to ensure that the 177 incoming media type is not blindly trusted and that proper magic 178 header or file structure checking is performed before allowing the 179 encoded data to drive operations that might negatively impact the 180 application environment or operating system. 182 3. Normative References 184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", BCP 14, RFC 2119, 186 DOI 10.17487/RFC2119, March 1997, 187 . 189 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 190 Specifications and Registration Procedures", BCP 13, 191 RFC 6838, DOI 10.17487/RFC6838, January 2013, 192 . 194 Appendix A. Acknowledgements 196 The editors would like to thank the following individuals for 197 feedback on the specification (in alphabetical order): Martin J. 198 Duerst, Ivan Herman, Graham Klyne, Murray S. Kucherawy, and Ted 199 Thibodeau Jr. 201 Authors' Addresses 203 Manu Sporny 204 Digital Bazaar 205 203 Roanoke Street W. 206 Blacksburg, VA 24060 207 United States of America 208 Email: msporny@digitalbazaar.com 209 URI: http://manu.sporny.org/ 211 Amy Guy 212 Digital Bazaar 213 203 Roanoke Street W. 214 Blacksburg, VA 24060 215 United States of America 216 Email: rhiaro@digitalbazaar.com 217 URI: https://rhiaro.co.uk/