idnits 2.17.1 draft-bormann-core-media-content-type-format-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1873 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) -- Looks like a reference, but probably isn't: '19' on line 118 -- Obsolete informational reference (is this intentional?): RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) -- Obsolete informational reference (is this intentional?): RFC 1590 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track March 11, 2019 5 Expires: September 12, 2019 7 On Media-Types, Content-Types, and related terminology 8 draft-bormann-core-media-content-type-format-00 10 Abstract 12 There is a lot of confusion about media-types, content-types, and 13 related terminology. 15 This memo is an attempt at clearing it up. 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 September 12, 2019. 34 Copyright Notice 36 Copyright (c) 2019 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 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Media-Type . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Content-Type . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Content-Coding . . . . . . . . . . . . . . . . . . . . . . . 3 55 5. Content-Format . . . . . . . . . . . . . . . . . . . . . . . 4 56 6. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 4 57 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 10.2. Informative References . . . . . . . . . . . . . . . . . 5 63 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 [RFC1590] introduced media types and their registration. That 69 document took MIME types from [RFC1521] and gave them a new name. At 70 that time, the term "media type" was often used just for the major 71 type ("text", "audio"), and what we call a media-type now was the 72 combination of a type and a subtype. This lives on in [RFC6838], 73 which does not even have an ABNF production for media type: 75 type-name = reg-name 76 subtype-name = reg-name 78 reg-name = 1*127reg-name-chars 79 reg-name-chars = ALPHA / DIGIT / "!" / 80 "#" / "$" / "&" / "." / 81 "+" / "-" / "^" / "_" 83 2. Media-Type 85 However, the term "media type" is now generally used for a registered 86 combination of a type-name and a subtype-name, as in 88 Media-Type = type-name "/" subtype 90 For the purposes of this memo, we define: 92 Media-Type: A combination of a type-name and a subtype-name 93 registered in [IANA.media-types], conventionally identified by the 94 two names separated by a slash. 96 3. Content-Type 98 Media types have parameters [RFC6838], some of which are mandatory. 99 In HTTP and many other protocols, these are then used in a "Content- 100 Type" header field. HTTP [RFC7231] uses: 102 Content-Type = media-type 103 media-type = type "/" subtype *( OWS ";" OWS parameter ) 104 type = token 105 subtype = token 106 token = 1*tchar 107 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" 108 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 109 / DIGIT / ALPHA 110 OWS = *( SP / HTAB ) 112 We don't follow the inclusive use established by [RFC2616], parts of 113 which became [RFC7231], to use the term media-type for a Media-Type 114 with parameters; note that [RFC2616] was quite confused about this by 115 claiming (Section 3.7): 117 Media-type values are registered with the Internet Assigned Number 118 Authority (IANA [19]). 120 This clearly reverts to the understanding of Media-Type we use. We 121 instead define as a separate term: 123 Content-Type: A Media-Type, optionally associated with parameters 124 (separated from the media type name and from each other by a 125 semicolon). 127 Removing the legacy HTAB characters now shunned in polite conversion, 128 we define the conventional textual representation of a Content-Type 129 as: 131 Content-Type = media-type *( *SP ";" *SP parameter ) 133 4. Content-Coding 135 [RFC2616] also introduced the term Content-Coding, a registered name 136 for an encoding transformation that has been or can be applied to a 137 representation: 139 content-coding = token 141 Confusingly, in HTTP the Content-Coding is then given in a header 142 field called "Content-Encoding"; we NEVER use this term (except when 143 we are in error). Instead we define: 145 Content-Coding: a registered name for an encoding transformation 146 that has been or can be applied to a representation. 148 Content-Codings are registered in the HTTP Content Coding Registry, a 149 subregistry of [IANA.http-parameters]. We often use the "identity" 150 Content-Coding, which is the identity transformation, and often fail 151 to identify that Content-Coding by name, instead calling it "no 152 Content-Coding". 154 5. Content-Format 156 CoAP [RFC7252] defines a Content-Format as the combination of a 157 Content-Type and a Content-Coding, identified by a numeric identifier 158 defined by the "CoAP Content-Formats" registry (a subregistry of 159 [IANA.core-parameters]), but in more confusing words (it did not have 160 the benefit of the present memo). 162 Content-Format: the combination of a Content-Type and a Content- 163 Coding, identified by a numeric identifier defined by the "CoAP 164 Content-Formats" registry. 166 Note that there is no conventional string representation of just the 167 combination of a Content-Type and a Content-Coding; Content-Formats 168 are always identified by their registered Content-Format numbers. 170 6. Abbreviations 172 Media-Types are sometime abbreviated as "mt", and Content-Types as 173 "ct". We do not propose to use those abbreviations: Where the long 174 form of the values can be used, the long form "Content-Type" can also 175 be used to name them. 177 For historical reasons, both [RFC6690] and [RFC7252] use the 178 abbreviation "ct" for Content-Format (think first and last 179 character). 181 For Content-Coding, the abbreviation "cc" can be used. 183 7. Discussion 185 The ABNF given here is provisional and needs ot be cleaned up: We 186 need to unify the various forms of reg-name, token, etc. We need to 187 define parameter. We also need to typographically differentiate 188 foreign ABNF just shown for illustration from the normative ABNF of 189 this memo. 191 We need to discuss case-insensitivity, which is usually rather 192 insensitive. 194 8. IANA Considerations 196 While this memo talks a lot about IANA registries, it does not 197 require any action from IANA. 199 9. Security Considerations 201 Confusion about terminology may, in the worst case, cause security 202 problems. No other security considerations are knwon to be raised by 203 the present memo. 205 10. References 207 10.1. Normative References 209 [IANA.core-parameters] 210 IANA, "Constrained RESTful Environments (CoRE) 211 Parameters", 212 . 214 [IANA.http-parameters] 215 IANA, "Hypertext Transfer Protocol (HTTP) Parameters", 216 . 218 [IANA.media-types] 219 IANA, "Media Types", 220 . 222 10.2. Informative References 224 [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 225 Mail Extensions) Part One: Mechanisms for Specifying and 226 Describing the Format of Internet Message Bodies", 227 RFC 1521, DOI 10.17487/RFC1521, September 1993, 228 . 230 [RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590, 231 DOI 10.17487/RFC1590, March 1994, 232 . 234 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 235 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 236 Transfer Protocol -- HTTP/1.1", RFC 2616, 237 DOI 10.17487/RFC2616, June 1999, 238 . 240 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 241 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 242 . 244 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 245 Specifications and Registration Procedures", BCP 13, 246 RFC 6838, DOI 10.17487/RFC6838, January 2013, 247 . 249 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 250 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 251 DOI 10.17487/RFC7231, June 2014, 252 . 254 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 255 Application Protocol (CoAP)", RFC 7252, 256 DOI 10.17487/RFC7252, June 2014, 257 . 259 Acknowledgements 261 Matthias Kovatsch forced the author to make up his mind about this. 262 Ari Keranen forced him to write it up, then. 264 Author's Address 266 Carsten Bormann 267 Universitaet Bremen TZI 268 Postfach 330440 269 Bremen D-28359 270 Germany 272 Phone: +49-421-218-63921 273 Email: cabo@tzi.org