On Media-Types, Content-Types, and related terminologyUniversität Bremen TZIPostfach 330440BremenD-28359Germany+49-421-218-63921cabo@tzi.orgThere is a lot of confusion about media-types, content-types, and
related terminology.This memo is an attempt at clearing it up, so we can use consistent
terminology in CoRE and related specifications.
It also defines some ABNF that can be used in these specifications.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 .
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 19 February 2021.
Copyright Notice
Copyright (c) 2020 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
() 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.
Table of Contents
. Introduction
. Media-Type
. Content-Type
. Content-Coding
. Content-Format
. Abbreviations
. Discussion
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Author's Address
Introduction introduced media types and their registration.
That document took MIME types from 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 ,
which does not even have an ABNF production for media type.
's predecessor, , supplied the ABNF shown in (). contains the semantically equivalent ABNF in
, which also provides comments that limit the
use of "." and "+".Media-TypeHowever, 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:For the purposes of this memo, we define:
Media-Type-Name:
A combination of a type-name and a subtype-name
registered in , conventionally identified by the two
names separated by a slash.
(This leaves the term "Media Type" for the actual specification that
is registered under the Media-Type-Name.)Content-TypeMedia types can have parameters , some of which are mandatory.
In HTTP and many other protocols, these are then used in a
"Content-Type" header field.
HTTP uses:We don't follow this inclusive use established by , parts
of which became , namely to use the term media-type for a
Media-Type-Name with parameters; note that 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 conversation,
as well as some other cobwebs, we define the conventional textual
representation of a Content-Type as:Note that there is a slight inconsistency between the "token" used
here and the "reg-name"/"restricted-name" used above; since media type
parameters probably will be defined within the guard rails set by
, we need to use HTTP's more comprehensive definition here.Content-Coding also introduced the term Content-Coding, a registered name
for an encoding transformation that has been or can be applied to a
representation: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 . 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".Content-FormatCoAP 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
), 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 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 , so we define: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.AbbreviationsMedia type names are sometimes abbreviated as "mt", and Content-Types
as "ct". We propose not 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 and use the
abbreviation "ct" for Content-Format (think first and last character).For Content-Coding, the abbreviation "cc" can be used.DiscussionThe 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 and tagged with
"abnf;old" in the XML, while the normative ABNF of this memo is
left-aligned and tagged with "abnf".)We need to discuss case-insensitivity, which is usually rather
insensitive.IANA ConsiderationsWhile this memo talks a lot about IANA registries, it does not
require any action from IANA.Security ConsiderationsConfusion about terminology may, in the worst case, cause security
problems. No other security considerations are known to be raised by
the present memo.ReferencesNormative ReferencesConstrained RESTful Environments (CoRE) ParametersIANAHypertext Transfer Protocol (HTTP) ParametersIANAMedia TypesIANAInformative ReferencesSenML Data Value Content-Format IndicationThe Sensor Measurement Lists (SenML) media type supports multiple types of values, from numbers to text strings and arbitrary binary data values. In order to simplify processing of the data values this document proposes to specify a new SenML field for indicating the Content-Format of the data.Work in ProgressMIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message BodiesThis document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and STD 11, RFC 1049, but extends and revises that work. [STANDARDS-TRACK]Media Type Registration ProcedureSeveral questions have been raised about the requirements and administrative procedure for registering MIME content-type and subtypes, and the use of these Media Types for other applications. This document addresses these issues and specifies a procedure for the registration of new Media Types (content-type/subtypes). It also generalizes the scope of use of these Media Types to make it appropriate to use the same registrations and specifications with other applications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.Hypertext Transfer Protocol -- HTTP/1.1HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068. [STANDARDS-TRACK]Media Type Specifications and Registration ProceduresThis document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Augmented BNF for Syntax Specifications: ABNFInternet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]Constrained RESTful Environments (CoRE) Link FormatThis specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]Media Type Specifications and Registration ProceduresThis document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentThe Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.The Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.AcknowledgementsMatthias 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.
Alexey Melnikov suggested to revive this draft after a year of dormancy.Author's AddressUniversität Bremen TZIPostfach 330440BremenD-28359Germany+49-421-218-63921cabo@tzi.org