On Media-Types, Content-Types, and related terminology
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]