On Media-Types, Content-Types, and related terminology
draft-bormann-core-media-content-type-format-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Author | Carsten Bormann | ||
Last updated | 2019-03-11 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-bormann-core-media-content-type-format-00
Network Working Group C. Bormann Internet-Draft Universitaet Bremen TZI Intended status: Standards Track March 11, 2019 Expires: September 12, 2019 On Media-Types, Content-Types, and related terminology draft-bormann-core-media-content-type-format-00 Abstract There is a lot of confusion about media-types, content-types, and related terminology. This memo is an attempt at clearing it up. 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 September 12, 2019. Copyright Notice Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Bormann Expires September 12, 2019 [Page 1] Internet-Draft Content-Types March 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Media-Type . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Content-Type . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Content-Coding . . . . . . . . . . . . . . . . . . . . . . . 3 5. Content-Format . . . . . . . . . . . . . . . . . . . . . . . 4 6. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 10.2. Informative References . . . . . . . . . . . . . . . . . 5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction [RFC1590] introduced media types and their registration. That document took MIME types from [RFC1521] and gave them a new name. At that time, the term "media type" was often used just for the major type ("text", "audio"), and what we call a media-type now was the combination of a type and a subtype. This lives on in [RFC6838], which does not even have an ABNF production for media type: type-name = reg-name subtype-name = reg-name reg-name = 1*127reg-name-chars reg-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "." / "+" / "-" / "^" / "_" 2. Media-Type However, the term "media type" is now generally used for a registered combination of a type-name and a subtype-name, as in Media-Type = type-name "/" subtype For the purposes of this memo, we define: Media-Type: A combination of a type-name and a subtype-name registered in [IANA.media-types], conventionally identified by the two names separated by a slash. Bormann Expires September 12, 2019 [Page 2] Internet-Draft Content-Types March 2019 3. Content-Type Media types have parameters [RFC6838], some of which are mandatory. In HTTP and many other protocols, these are then used in a "Content- Type" header field. HTTP [RFC7231] uses: Content-Type = media-type media-type = type "/" subtype *( OWS ";" OWS parameter ) type = token subtype = token token = 1*tchar tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA OWS = *( SP / HTAB ) We don't follow the inclusive use established by [RFC2616], parts of which became [RFC7231], to use the term media-type for a Media-Type with parameters; note that [RFC2616] was quite confused about this by claiming (Section 3.7): Media-type values are registered with the Internet Assigned Number Authority (IANA [19]). This clearly reverts to the understanding of Media-Type we use. We instead define as a separate term: Content-Type: A Media-Type, optionally associated with parameters (separated from the media type name and from each other by a semicolon). Removing the legacy HTAB characters now shunned in polite conversion, we define the conventional textual representation of a Content-Type as: Content-Type = media-type *( *SP ";" *SP parameter ) 4. Content-Coding [RFC2616] also introduced the term Content-Coding, a registered name for an encoding transformation that has been or can be applied to a representation: content-coding = token Confusingly, in HTTP the Content-Coding is then given in a header field called "Content-Encoding"; we NEVER use this term (except when we are in error). Instead we define: Bormann Expires September 12, 2019 [Page 3] Internet-Draft Content-Types March 2019 Content-Coding: a registered name for an encoding transformation that has been or can be applied to a representation. Content-Codings are registered in the HTTP Content Coding Registry, a subregistry of [IANA.http-parameters]. We often use the "identity" Content-Coding, which is the identity transformation, and often fail to identify that Content-Coding by name, instead calling it "no Content-Coding". 5. Content-Format CoAP [RFC7252] defines a Content-Format as the combination of a Content-Type and a Content-Coding, identified by a numeric identifier defined by the "CoAP Content-Formats" registry (a subregistry of [IANA.core-parameters]), but in more confusing words (it did not have the benefit of the present memo). Content-Format: the combination of a Content-Type and a Content- Coding, identified by a numeric identifier defined by the "CoAP Content-Formats" registry. Note that there is no conventional string representation of just the combination of a Content-Type and a Content-Coding; Content-Formats are always identified by their registered Content-Format numbers. 6. Abbreviations Media-Types are sometime abbreviated as "mt", and Content-Types as "ct". We do not propose to use those abbreviations: Where the long form of the values can be used, the long form "Content-Type" can also be used to name them. For historical reasons, both [RFC6690] and [RFC7252] use the abbreviation "ct" for Content-Format (think first and last character). For Content-Coding, the abbreviation "cc" can be used. 7. Discussion The ABNF given here is provisional and needs ot be cleaned up: We need to unify the various forms of reg-name, token, etc. We need to define parameter. We also need to typographically differentiate foreign ABNF just shown for illustration from the normative ABNF of this memo. We need to discuss case-insensitivity, which is usually rather insensitive. Bormann Expires September 12, 2019 [Page 4] Internet-Draft Content-Types March 2019 8. IANA Considerations While this memo talks a lot about IANA registries, it does not require any action from IANA. 9. Security Considerations Confusion about terminology may, in the worst case, cause security problems. No other security considerations are knwon to be raised by the present memo. 10. References 10.1. Normative References [IANA.core-parameters] IANA, "Constrained RESTful Environments (CoRE) Parameters", <http://www.iana.org/assignments/core-parameters>. [IANA.http-parameters] IANA, "Hypertext Transfer Protocol (HTTP) Parameters", <http://www.iana.org/assignments/http-parameters>. [IANA.media-types] IANA, "Media Types", <http://www.iana.org/assignments/media-types>. 10.2. Informative References [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, DOI 10.17487/RFC1521, September 1993, <https://www.rfc-editor.org/info/rfc1521>. [RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590, DOI 10.17487/RFC1590, March 1994, <https://www.rfc-editor.org/info/rfc1590>. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, <https://www.rfc-editor.org/info/rfc2616>. Bormann Expires September 12, 2019 [Page 5] Internet-Draft Content-Types March 2019 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <https://www.rfc-editor.org/info/rfc6690>. [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>. [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>. Acknowledgements Matthias Kovatsch forced the author to make up his mind about this. Ari Keranen forced him to write it up, then. Author's Address Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Bormann Expires September 12, 2019 [Page 6]