< draft-bormann-core-media-content-type-format-00.txt   draft-bormann-core-media-content-type-format-01.txt >
Network Working Group C. Bormann Network Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track March 11, 2019 Intended status: Standards Track July 08, 2019
Expires: September 12, 2019 Expires: January 9, 2020
On Media-Types, Content-Types, and related terminology On Media-Types, Content-Types, and related terminology
draft-bormann-core-media-content-type-format-00 draft-bormann-core-media-content-type-format-01
Abstract Abstract
There is a lot of confusion about media-types, content-types, and There is a lot of confusion about media-types, content-types, and
related terminology. related terminology.
This memo is an attempt at clearing it up. This memo is an attempt at clearing it up.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 10 skipping to change at page 2, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Media-Type . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Media-Type . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Content-Type . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Content-Type . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Content-Coding . . . . . . . . . . . . . . . . . . . . . . . 3 4. Content-Coding . . . . . . . . . . . . . . . . . . . . . . . 4
5. Content-Format . . . . . . . . . . . . . . . . . . . . . . . 4 5. Content-Format . . . . . . . . . . . . . . . . . . . . . . . 4
6. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . 5 10.1. Normative References . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . 5 10.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
[RFC1590] introduced media types and their registration. That [RFC1590] introduced media types and their registration. That
document took MIME types from [RFC1521] and gave them a new name. At 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 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 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], combination of a type and a subtype. This lives on in [RFC6838],
which does not even have an ABNF production for media type: which does not even have an ABNF [RFC5234] production for media type:
type-name = reg-name type-name = reg-name
subtype-name = reg-name subtype-name = reg-name
reg-name = 1*127reg-name-chars reg-name = 1*127reg-name-chars
reg-name-chars = ALPHA / DIGIT / "!" / reg-name-chars = ALPHA / DIGIT / "!" /
"#" / "$" / "&" / "." / "#" / "$" / "&" / "." /
"+" / "-" / "^" / "_" "+" / "-" / "^" / "_"
2. Media-Type 2. Media-Type
However, the term "media type" is now generally used for a registered However, the term "media type" is now generally used for a registered
combination of a type-name and a subtype-name, as in combination of a type-name and a subtype-name. We further
disambiguate by calling this a media type name, as, in ABNF:
Media-Type = type-name "/" subtype Media-Type-Name = type-name "/" subtype-name
For the purposes of this memo, we define: For the purposes of this memo, we define:
Media-Type: A combination of a type-name and a subtype-name Media-Type-Name: A combination of a type-name and a subtype-name
registered in [IANA.media-types], conventionally identified by the registered in [IANA.media-types], conventionally identified by the
two names separated by a slash. two names separated by a slash.
(This leaves the term "Media Type" for the actual specification that
is registered under the Media-Type-Name.)
3. Content-Type 3. Content-Type
Media types have parameters [RFC6838], some of which are mandatory. Media types have parameters [RFC6838], some of which are mandatory.
In HTTP and many other protocols, these are then used in a "Content- In HTTP and many other protocols, these are then used in a "Content-
Type" header field. HTTP [RFC7231] uses: Type" header field. HTTP [RFC7231] uses:
Content-Type = media-type Content-Type = media-type
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token type = token
subtype = token subtype = token
token = 1*tchar token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA / DIGIT / ALPHA
OWS = *( SP / HTAB ) OWS = *( SP / HTAB )
We don't follow the inclusive use established by [RFC2616], parts of Figure 1: Content-Type ABNF from RFC 7231
which became [RFC7231], to use the term media-type for a Media-Type
with parameters; note that [RFC2616] was quite confused about this by We don't follow this inclusive use established by [RFC2616], parts of
claiming (Section 3.7): 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 Media-type values are registered with the Internet Assigned Number
Authority (IANA [19]). Authority (IANA [19]).
This clearly reverts to the understanding of Media-Type we use. We This clearly reverts to the understanding of Media-Type-Name we use.
instead define as a separate term: We instead define as a separate term:
Content-Type: A Media-Type, optionally associated with parameters Content-Type: A Media-Type-Name, optionally associated with
(separated from the media type name and from each other by a parameters (separated from the media type name and from each other
semicolon). by a semicolon).
Removing the legacy HTAB characters now shunned in polite conversion, Removing the legacy HTAB characters now shunned in polite conversion,
we define the conventional textual representation of a Content-Type as well as some other cobwebs, we define the conventional textual
as: representation of a Content-Type as:
Content-Type = media-type *( *SP ";" *SP parameter ) 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 4. Content-Coding
[RFC2616] also introduced the term Content-Coding, a registered name [RFC2616] also introduced the term Content-Coding, a registered name
for an encoding transformation that has been or can be applied to a for an encoding transformation that has been or can be applied to a
representation: representation:
content-coding = token content-coding = token
Confusingly, in HTTP the Content-Coding is then given in a header Confusingly, in HTTP the Content-Coding is then given in a header
skipping to change at page 4, line 26 skipping to change at page 5, line 5
CoAP [RFC7252] defines a Content-Format as the combination of a CoAP [RFC7252] defines a Content-Format as the combination of a
Content-Type and a Content-Coding, identified by a numeric identifier Content-Type and a Content-Coding, identified by a numeric identifier
defined by the "CoAP Content-Formats" registry (a subregistry of defined by the "CoAP Content-Formats" registry (a subregistry of
[IANA.core-parameters]), but in more confusing words (it did not have [IANA.core-parameters]), but in more confusing words (it did not have
the benefit of the present memo). the benefit of the present memo).
Content-Format: the combination of a Content-Type and a Content- Content-Format: the combination of a Content-Type and a Content-
Coding, identified by a numeric identifier defined by the "CoAP Coding, identified by a numeric identifier defined by the "CoAP
Content-Formats" registry. Content-Formats" registry.
Note that there is no conventional string representation of just the Note that there has not been a conventional string representation of
combination of a Content-Type and a Content-Coding; Content-Formats just the combination of a Content-Type and a Content-Coding; Content-
are always identified by their registered Content-Format numbers. 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 6. Abbreviations
Media-Types are sometime abbreviated as "mt", and Content-Types as Media type names are sometime abbreviated as "mt", and Content-Types
"ct". We do not propose to use those abbreviations: Where the long as "ct". We do not propose to use those abbreviations: Where the
form of the values can be used, the long form "Content-Type" can also long form of the values can be used, the long form "Content-Type" can
be used to name them. also be used to name them.
For historical reasons, both [RFC6690] and [RFC7252] use the For historical reasons, both [RFC6690] and [RFC7252] use the
abbreviation "ct" for Content-Format (think first and last abbreviation "ct" for Content-Format (think first and last
character). character).
For Content-Coding, the abbreviation "cc" can be used. For Content-Coding, the abbreviation "cc" can be used.
7. Discussion 7. Discussion
The ABNF given here is provisional and needs ot be cleaned up: We The ABNF given here is provisional and needs to be cleaned up: We
need to unify the various forms of reg-name, token, etc. We need to need to unify the various forms of reg-name, token, etc.
define parameter. We also need to typographically differentiate
foreign ABNF just shown for illustration from the normative ABNF of (ABNF just shown for illustration is centered, while the normative
this memo. ABNF of this memo is left-aligned.)
We need to discuss case-insensitivity, which is usually rather We need to discuss case-insensitivity, which is usually rather
insensitive. insensitive.
8. IANA Considerations 8. IANA Considerations
While this memo talks a lot about IANA registries, it does not While this memo talks a lot about IANA registries, it does not
require any action from IANA. require any action from IANA.
9. Security Considerations 9. Security Considerations
skipping to change at page 5, line 35 skipping to change at page 6, line 35
[IANA.http-parameters] [IANA.http-parameters]
IANA, "Hypertext Transfer Protocol (HTTP) Parameters", IANA, "Hypertext Transfer Protocol (HTTP) Parameters",
<http://www.iana.org/assignments/http-parameters>. <http://www.iana.org/assignments/http-parameters>.
[IANA.media-types] [IANA.media-types]
IANA, "Media Types", IANA, "Media Types",
<http://www.iana.org/assignments/media-types>. <http://www.iana.org/assignments/media-types>.
10.2. Informative References 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 [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
Mail Extensions) Part One: Mechanisms for Specifying and Mail Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", Describing the Format of Internet Message Bodies",
RFC 1521, DOI 10.17487/RFC1521, September 1993, RFC 1521, DOI 10.17487/RFC1521, September 1993,
<https://www.rfc-editor.org/info/rfc1521>. <https://www.rfc-editor.org/info/rfc1521>.
[RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590, [RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590,
DOI 10.17487/RFC1590, March 1994, DOI 10.17487/RFC1590, March 1994,
<https://www.rfc-editor.org/info/rfc1590>. <https://www.rfc-editor.org/info/rfc1590>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>. <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 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
skipping to change at page 6, line 27 skipping to change at page 7, line 38
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
Acknowledgements Acknowledgements
Matthias Kovatsch forced the author to make up his mind about this. Matthias Kovatsch forced the author to make up his mind about this.
Ari Keranen forced him to write it up, then. 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 Author's Address
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
 End of changes. 22 change blocks. 
52 lines changed or deleted 101 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/