[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                         C. Bormann
Internet-Draft                                   Universitaet Bremen TZI
Intended status: Standards Track                           July 08, 2019
Expires: January 9, 2020


         On Media-Types, Content-Types, and related terminology
            draft-bormann-core-media-content-type-format-01

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 January 9, 2020.

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 January 9, 2020                [Page 1]


Internet-Draft                Content-Types                    July 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Media-Type  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Content-Type  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Content-Coding  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Content-Format  . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Abbreviations . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     10.2.  Informative References . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

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 [RFC5234] 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.  We further
   disambiguate by calling this a media type name, as, in ABNF:

   Media-Type-Name = type-name "/" subtype-name

   For the purposes of this memo, we define:

   Media-Type-Name:  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 January 9, 2020                [Page 2]


Internet-Draft                Content-Types                    July 2019


   (This leaves the term "Media Type" for the actual specification that
   is registered under the Media-Type-Name.)

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 )

                 Figure 1: Content-Type ABNF from RFC 7231

   We don't follow this inclusive use established by [RFC2616], parts of
   which became [RFC7231], namely to use the term media-type for a
   Media-Type-Name 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-Name we use.
   We instead define as a separate term:

   Content-Type:  A Media-Type-Name, 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,
   as well as some other cobwebs, we define the conventional textual
   representation of a Content-Type as:












Bormann                  Expires January 9, 2020                [Page 3]


Internet-Draft                Content-Types                    July 2019


   Content-Type   = Media-Type-Name *( *SP ";" *SP parameter )
   parameter      = token "=" ( token / quoted-string )

   token          = 1*tchar
   tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
                  / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
                  / DIGIT / ALPHA
   quoted-string  = %x22 *qdtext %x22
   qdtext         = SP / %x21 / %x23-5B / %x5D-7E


   Note that there is a slight inconsistency between the "token" used
   here and the "reg-name" used above; since media type parameters
   probably will be defined within the guard rails set by [RFC7231], we
   need to use HTTP's more comprehensive definition here.

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:

   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.



Bormann                  Expires January 9, 2020                [Page 4]


Internet-Draft                Content-Types                    July 2019


   Note that there has not been a conventional string representation of
   just the combination of a Content-Type and a Content-Coding; Content-
   Formats so far always are identified by their registered Content-
   Format numbers.  However, there are applications where that is useful
   [I-D.keranen-core-senml-data-ct], so we define:

   Content-Format = 1*DIGIT
   Content-Format-String   = Content-Type ["@" content-coding]

   This allows the use of Content-Format-Strings such as "application/
   json@deflate" in place of the less self-describing content-format
   "11050", or other combinations that do not have a content-format
   number defined yet.

   Content-Format-Strings MUST NOT explicitly use the content-coding
   value of "identity" (i.e., if an identity content-coding is desired,
   the entire optional part including the "@" sign is left out).

   Note that a quoted string inside a content-type parameter might
   contain an "@" sign, so the parsing of Content-Format-Strings cannot
   be done in a too simplistic way.

6.  Abbreviations

   Media type names 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 to be cleaned up: We
   need to unify the various forms of reg-name, token, etc.

   (ABNF just shown for illustration is centered, while the normative
   ABNF of this memo is left-aligned.)

   We need to discuss case-insensitivity, which is usually rather
   insensitive.






Bormann                  Expires January 9, 2020                [Page 5]


Internet-Draft                Content-Types                    July 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

   [I-D.keranen-core-senml-data-ct]
              Keranen, A. and C. Bormann, "SenML Data Value Content-
              Format Indication", draft-keranen-core-senml-data-ct-01
              (work in progress), March 2019.

   [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>.







Bormann                  Expires January 9, 2020                [Page 6]


Internet-Draft                Content-Types                    July 2019


   [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>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [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, and created a convincing
   use case of Content-Format-Strings.  John Mattsson alerted us to a
   mistake.

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 January 9, 2020                [Page 7]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/