idnits 2.17.1 draft-w3cdidwg-media-types-with-multiple-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 a Security Considerations section. ** 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.) -- The abstract seems to indicate that this document updates RFC6838, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 11, 2021) is 1202 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Guy 3 Internet-Draft Digital Bazaar 4 Intended status: Standards Track January 11, 2021 5 Expires: July 15, 2021 7 Media Types with Multiple Suffixes 8 draft-w3cdidwg-media-types-with-multiple-suffixes-01 10 Abstract 12 This document updates RFC 6838 "Media Type Specifications and 13 Registration Procedures" to describe how to interpret subtypes with 14 multiple suffixes. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on July 15, 2021. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 48 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 49 2. Media Types with Multiple Suffixes . . . . . . . . . . . . . 2 50 2.1. Processing Multiple Suffixes . . . . . . . . . . . . . . 3 51 3. Normative References . . . . . . . . . . . . . . . . . . . . 3 52 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 4 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1. Introduction 57 As written, RFC 6838 [RFC6838] permits the registration of media type 58 subtype names which contain any number of occurrences of the "+" 59 character. RFC 6838 defines the characters following the final "+" 60 to be a structured syntax suffix, but does not define anything 61 further about how to interpret subtype names containing more than one 62 "+" character. 64 This document updates RFC 6838 to clarify how to interpret subtype 65 names containing more than one "+" character as subtypes with 66 multiple suffixes. 68 As registration of media types which use a structured suffix has 69 become widely supported, this enables further specialization of media 70 types that build on already registered and well-defined media types 71 which themselves use a structured suffix. 73 1.1. Conventions Used in This Document 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119] when they 78 appear in ALL CAPS. They may also appear in lower or mixed case as 79 plain English words, without any normative meaning. 81 2. Media Types with Multiple Suffixes 83 The following paragraphs are additions to RFC 6838. 85 Media types MAY be registered with more than one suffix appended to 86 the base subtype name. The suffixes MUST be interpreted as ordered. 87 Valid media type names containing a structured suffix are built from 88 right to left (not left to right). Characters on the left-most side 89 of the left-most "+" in a subtype name specify the base subtype name. 90 Characters to the right of each "+" in a subtype name denote 91 additional structured syntax specifier suffixes. 93 Media types with more than one suffix MUST be registered according to 94 the procedure defined in [RFC6838]. A new base subtype name MUST 95 only be registered with suffix combinations that are already 96 registered in their own right. 98 For example, a media type that uses the two suffixes "+svg+xml" is 99 only permitted insofar as "svg+xml" is already registered. In this 100 case, the suffix "+svg" does not need to be registered individually, 101 but "+xml" and "svg+xml" MUST be registered. 103 2.1. Processing Multiple Suffixes 105 Registered subtypes have clear processing rules. In cases where 106 specific handling of the exact media type is not required, receivers 107 of the media type MAY do generic processing on the underlying 108 representation according to their ability to process any subset of 109 the suffix(es) from right to left inclusive. In other words, an 110 application can choose to ignore the base subtype name and left-most 111 "+" from a media type with multiple suffixes, and process according 112 to the remaining media type suffix(es). An application can ignore as 113 many of the left-most suffixes as necessary to achieve a media type 114 that can be processed. 116 For example, for the media type "application/did+ld+json", the 117 following are all valid subtypes with their own individually 118 specified processing rules: 120 did+ld+json 121 ld+json 122 json 124 Thus applications can choose to process the underlying representation 125 according any of the following valid media types: 127 application/did+ld+json 128 application/ld+json 129 application/json 131 3. Normative References 133 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 134 Requirement Levels", BCP 14, RFC 2119, 135 DOI 10.17487/RFC2119, March 1997, 136 . 138 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 139 Specifications and Registration Procedures", BCP 13, 140 RFC 6838, DOI 10.17487/RFC6838, January 2013, 141 . 143 Appendix A. Acknowledgements 145 The editors would like to thank the following individuals for 146 feedback on the specification (in alphabetical order): Martin J. 147 Duerst, Ivan Herman, Graham Klyne, Murray S. Kucherawy, Manu Sporny, 148 Ted Thibodeau Jr. 150 Author's Address 152 Amy Guy 153 Digital Bazaar 154 203 Roanoke Street W. 155 Blacksburg, VA 24060 156 US 158 Email: rhiaro@digitalbazaar.com 159 URI: https://rhiaro.co.uk/