<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.35 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-bormann-core-media-content-type-format-04" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title abbrev="Content-Types">On Media-Types, Content-Types, and related terminology</title>
    <seriesInfo name="Internet-Draft" value="draft-bormann-core-media-content-type-format-04"/>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization>Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
      <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
      <address>
        <postal>
          <street>Rheinstrasse 75</street>
          <city>Darmstadt</city>
          <code>64295</code>
          <country>Germany</country>
        </postal>
        <email>henk.birkholz@sit.fraunhofer.de</email>
      </address>
    </author>
    <date year="2021" month="February" day="22"/>
    <abstract>
      <t>There is a lot of confusion about media-types, content-types, and
related terminology.</t>
      <t>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.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <t><xref target="RFC1590" format="default"/> introduced media types and their registration.
That document took MIME types from <xref target="RFC1521" format="default"/> 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 <xref target="RFC6838" format="default"/>,
which does not even have an ABNF <xref target="RFC5234" format="default"/> production for media type.
<xref target="RFC6838" format="default"/>'s predecessor, <xref target="RFC4288" format="default"/>, supplied the ABNF shown in (<xref target="abnf-type-subtype1" format="default"/>).</t>
      <blockquote>
        <figure anchor="abnf-type-subtype1">
          <name>ABNF for type and subtype, cited from RFC 4288</name>
          <artwork type="abnf;old" align="center" name="" alt=""><![CDATA[
type-name = reg-name
subtype-name = reg-name

reg-name = 1*127reg-name-chars
reg-name-chars = ALPHA / DIGIT / "!" /
                 "#" / "$" / "&" / "." /
                 "+" / "-" / "^" / "_"
]]></artwork>
        </figure>
      </blockquote>
      <t><xref target="RFC6838" format="default"/>, obsoleting <xref target="RFC4288" format="default"/>, restricts the
first character of a reg-name to alphanumeric.
It contains the otherwise semantically equivalent ABNF shown in
<xref target="ABNF-type-subtype2" format="default"/>, however adding prose comments that further
limit the use of "."  and "+".</t>
      <figure anchor="ABNF-type-subtype2">
        <name>ABNF for type and subtype, as defined from RFC 6838</name>
        <sourcecode type="abnf">
type-name = restricted-name
subtype-name = restricted-name

restricted-name = restricted-name-first *126restricted-name-chars
restricted-name-first  = ALPHA / DIGIT
restricted-name-chars  = ALPHA / DIGIT / "!" / "#" /
                         "$" / "&amp;" / "-" / "^" / "_"
restricted-name-chars =/ "." ; Characters before first dot always
                             ; specify a facet name
restricted-name-chars =/ "+" ; Characters after last plus always
                             ; specify a structured syntax suffix
</sourcecode>
      </figure>
    </section>
    <section anchor="media-type" numbered="true" toc="default">
      <name>Media-Type</name>
      <t>Today, the term "media type" is now generally used for a registered
combination of a type-name and a subtype-name, as well as for the
specification that defines the semantics of this combination.
We further disambiguate by calling the former a <em>media type name</em>.
An ABNF definition of <tt>Media-Type-Name</tt>:</t>
      <figure anchor="ABNF-Media-Type-Name">
        <name>Definition of Media-Type-Name</name>
        <sourcecode type="abnf">
Media-Type-Name = type-name "/" subtype-name
</sourcecode>
      </figure>
      <t>For the purposes of this memo, we define:</t>
      <dl>
        <dt>
Media-Type-Name:  </dt>
        <dd>
          <t>A combination of a type-name and a subtype-name
registered in <xref target="IANA.media-types" format="default"/>, conventionally identified by the two
names separated by a slash.</t>
        </dd>
      </dl>
      <t>(This leaves the term "Media Type" for the actual specification that
is registered under the Media-Type-Name.)</t>
    </section>
    <section anchor="content-type" numbered="true" toc="default">
      <name>Content-Type</name>
      <t>Media types can have parameters <xref target="RFC6838" format="default"/>, some of which are
defined by the media type specification to be mandatory.
In HTTP and many other protocols, media-type-names and parameters are
then used together in a "Content-Type" header field.
HTTP <xref target="RFC7231" format="default"/> uses the ABNF in <xref target="http-ct" format="default"/>:</t>
      <blockquote>
        <figure anchor="http-ct">
          <name>Content-Type ABNF from RFC 7231</name>
          <artwork type="abnf;old" align="center" name="" alt=""><![CDATA[
Content-Type = media-type
media-type = type "/" subtype *( OWS ";" OWS parameter )
type       = token
subtype    = token
token          = 1*tchar
tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
               / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
               / DIGIT / ALPHA
OWS        = *( SP / HTAB )
]]></artwork>
        </figure>
      </blockquote>
      <t>In the ABNF as established by
<xref target="RFC2616" format="default"/>, parts of which became <xref target="RFC7231" format="default"/>, the rule name
media-type is used for a Media-Type-Name with parameters attached.
We don't follow this inclusive use of media-type; note that
<xref target="RFC2616" format="default"/> was quite confused about this term by claiming (<xref section="3.7" sectionFormat="of" target="RFC2616" format="default"/>):</t>
      <ul empty="true" spacing="normal">
        <li>Media-type values are registered with the Internet Assigned Number
  Authority (IANA [19]).</li>
      </ul>
      <t>This clearly reverts to the understanding of Media-Type-Name we use.</t>
      <t>In order to resolve some of this confusion, we define as a separate term:</t>
      <dl>
        <dt>
Content-Type:  </dt>
        <dd>
          <t>A Media-Type-Name, optionally associated with parameters (separated from
the media type name and from each other by a semicolon).</t>
        </dd>
      </dl>
      <t>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 with the ABNF in <xref target="ABNF-Content-Type" format="default"/>:</t>
      <figure anchor="ABNF-Content-Type">
        <name>Definition of Content-Type</name>
        <sourcecode type="abnf">
Content-Type   = Media-Type-Name *( *SP ";" *SP parameter )
parameter      = token "=" ( token / quoted-string )

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

</sourcecode>
      </figure>
      <t>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
<xref target="RFC7231" format="default"/>, we need to use HTTP's more comprehensive definition here.</t>
    </section>
    <section anchor="content-coding" numbered="true" toc="default">
      <name>Content-Coding</name>
      <t><xref section="3.5" sectionFormat="of" target="RFC2616" format="default"/> also introduced the term Content-Coding, a
registered name for an encoding transformation that has been or can be
applied to a representation:</t>
      <figure anchor="ABNF-content-coding">
        <name>Definition of content-coding as in RFC 2616</name>
        <sourcecode type="abnf">
content-coding   = token
</sourcecode>
      </figure>
      <t>Confusingly, in HTTP the Content-Coding is then given in a header
field called "Content-Encoding"; we <strong>never</strong> use this term (except when
we are in error).  Instead we define:</t>
      <dl>
        <dt>
Content-Coding:  </dt>
        <dd>
          <t>a registered name for an encoding transformation that has been or
can be applied to a representation.</t>
        </dd>
      </dl>
      <t>Content-Codings are registered in the HTTP Content Coding Registry, a
subregistry of <xref target="IANA.http-parameters" format="default"/>.  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".</t>
    </section>
    <section anchor="content-format" numbered="true" toc="default">
      <name>Content-Format</name>
      <t>CoAP, in <xref section="1" sectionFormat="of" target="RFC7252" format="default"/>, defines a Content-Format as the
combination of a Content-Type and a Content-Coding, identified by a
numeric identifier defined in the "CoAP Content-Formats" registry (a
subregistry of <xref target="IANA.core-parameters" format="default"/>), but in more confusing words (it
did not have the benefit of the present specifications).</t>
      <dl>
        <dt>
Content-Format:  </dt>
        <dd>
          <t>the combination of a Content-Type and a Content-Coding, identified
by a numeric identifier defined by the "CoAP Content-Formats"
subregistry of <xref target="IANA.core-parameters" format="default"/>.</t>
        </dd>
      </dl>
      <t>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 <xref target="I-D.keranen-core-senml-data-ct" format="default"/>, so we define:</t>
      <figure anchor="ABNF-Content-Format-String">
        <name>Definition of Content-Format/-String</name>
        <sourcecode type="abnf">
Content-Format = "0" / (POS-DIGIT *DIGIT)
Content-Format-String   = Content-Type ["@" content-coding]
</sourcecode>
      </figure>
      <t>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.</t>
      <t>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).</t>
      <t>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.</t>
    </section>
    <section anchor="remaining-abnf" numbered="true" toc="default">
      <name>Remaining ABNF</name>
      <t>This specification uses the ABNF given in <xref target="abnf-boilerplate" format="default"/>, as
originally defined in <xref target="RFC5234" format="default"/> and <xref target="RFC8866" format="default"/>:</t>
      <figure anchor="abnf-boilerplate">
        <name>Commonly Used ABNF Definitions</name>
        <sourcecode type="abnf">
DIGIT     =  %x30-39           ; 0 – 9
POS-DIGIT =  %x31-39           ; 1 – 9
ALPHA     =  %x41-5A / %x61-7A ; A – Z / a – z
SP        =  %x20
</sourcecode>
      </figure>
    </section>
    <section anchor="abbreviations" numbered="true" toc="default">
      <name>Abbreviations</name>
      <t>Media 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.</t>
      <t>For historical reasons, both <xref target="RFC6690" format="default"/> and <xref target="RFC7252" format="default"/> use the
abbreviation "ct" for Content-Format (think first and last character).</t>
      <t>For Content-Coding, the abbreviation "cc" can be used.</t>
    </section>
    <section anchor="discussion" numbered="true" toc="default">
      <name>Discussion</name>
      <t>The ABNF given here is provisional and may need some more cleanup,
such as unifying the various forms of reg-name, token, etc.</t>
      <t>(ABNF just shown for illustration is centered, in a blockquote, and tagged with
<tt>&lt;artwork type="abnf;old"...&gt;</tt> in the XML, while the normative ABNF of this memo is
left-aligned and tagged with <tt>&lt;sourcecode type="abnf"...&gt;</tt>.)</t>
      <t>The XPath expression <tt>//sourcecode[@type='abnf']/text()</tt> can be used
on the XML form of this specification to extract the ABNF defined here.</t>
      <t>We need to discuss case-insensitivity at some point, which is usually
rather insensitive.</t>
    </section>
    <section anchor="suggested-usage" numbered="true" toc="default">
      <name>Suggested usage</name>
      <section anchor="cose" numbered="true" toc="default">
        <name>COSE</name>
        <t><xref section="3.1" sectionFormat="of" target="RFC8152" format="default"/> defines a common COSE header parameter
(number 3) called "content type" in the description, to indicate the
type of the data in the payload or ciphertext fields.</t>
        <t>This header parameter can either be an unsigned integer, indicating a CoRE
Content-Format number, or a text string.
The latter alternative is only defined in general terms.
It points to <xref section="4.2" sectionFormat="of" target="RFC6838" format="default"/> for 'text values following the
syntax of "&lt;type-name&gt;/&lt;subtype-name&gt;"...', but also discusses the
use of parameters and subparameters; no ABNF or similar detail
specification is provided.
The text does not discuss the use of Content-Coding in the text string
form, probably because nothing like the present document existed at
the time, creating a weird gap compared with numeric
Content-Format values.
(The text only has trivial changes in its updated version in <xref section="3.1" sectionFormat="of" target="I-D.ietf-cose-rfc8152bis-struct-15" format="default"/>.)</t>
        <t>The present specification suggests using the production
<tt>Content-Format-String</tt> as a more formal definition of the text string
that can go into the "content type" (number 3) common header parameter
in COSE.</t>
      </section>
      <section anchor="senml" numbered="true" toc="default">
        <name>SenML</name>
        <t>As discussed above, <xref section="3" sectionFormat="of" target="I-D.keranen-core-senml-data-ct" format="default"/>
makes use of the present specification.</t>
      </section>
      <section anchor="section" numbered="true" toc="default">
        <name>...</name>
        <t>(to be filled in along further use cases)</t>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>While this memo talks a lot about IANA registries, it does not
require any action from IANA.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Confusion about terminology may, in the worst case, cause security
problems, as can loosely defined syntax elements of a specification.
No other security considerations are known to be raised by the present
specification.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="IANA.core-parameters" target="http://www.iana.org/assignments/core-parameters">
          <front>
            <title>Constrained RESTful Environments (CoRE) Parameters</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="IANA.media-types" target="http://www.iana.org/assignments/media-types">
          <front>
            <title>Media Types</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="IANA.http-parameters" target="http://www.iana.org/assignments/http-parameters">
          <front>
            <title>Hypertext Transfer Protocol (HTTP) Parameters</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC4288" target="https://www.rfc-editor.org/info/rfc4288">
          <front>
            <title>Media Type Specifications and Registration Procedures</title>
            <author fullname="N. Freed" initials="N." surname="Freed">
              <organization/>
            </author>
            <author fullname="J. Klensin" initials="J." surname="Klensin">
              <organization/>
            </author>
            <date month="December" year="2005"/>
            <abstract>
              <t>This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4288"/>
          <seriesInfo name="DOI" value="10.17487/RFC4288"/>
        </reference>
        <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker">
              <organization/>
            </author>
            <author fullname="P. Overell" initials="P." surname="Overell">
              <organization/>
            </author>
            <date month="January" year="2008"/>
            <abstract>
              <t>Internet 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]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="68"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
        </reference>
        <reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6838">
          <front>
            <title>Media Type Specifications and Registration Procedures</title>
            <author fullname="N. Freed" initials="N." surname="Freed">
              <organization/>
            </author>
            <author fullname="J. Klensin" initials="J." surname="Klensin">
              <organization/>
            </author>
            <author fullname="T. Hansen" initials="T." surname="Hansen">
              <organization/>
            </author>
            <date month="January" year="2013"/>
            <abstract>
              <t>This 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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="13"/>
          <seriesInfo name="RFC" value="6838"/>
          <seriesInfo name="DOI" value="10.17487/RFC6838"/>
        </reference>
        <reference anchor="RFC7231" target="https://www.rfc-editor.org/info/rfc7231">
          <front>
            <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding">
              <organization/>
            </author>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>The 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7231"/>
          <seriesInfo name="DOI" value="10.17487/RFC7231"/>
        </reference>
        <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby">
              <organization/>
            </author>
            <author fullname="K. Hartke" initials="K." surname="Hartke">
              <organization/>
            </author>
            <author fullname="C. Bormann" initials="C." surname="Bormann">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>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.</t>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7252"/>
          <seriesInfo name="DOI" value="10.17487/RFC7252"/>
        </reference>
        <reference anchor="I-D.keranen-core-senml-data-ct" target="https://www.ietf.org/archive/id/draft-keranen-core-senml-data-ct-02.txt">
          <front>
            <title>SenML Data Value Content-Format Indication</title>
            <author fullname="Ari Keranen">
              <organization>Ericsson</organization>
            </author>
            <author fullname="Carsten Bormann">
              <organization>Universitaet Bremen TZI</organization>
            </author>
            <date day="8" month="July" year="2019"/>
            <abstract>
              <t>   The 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.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-keranen-core-senml-data-ct-02"/>
        </reference>
        <reference anchor="RFC8152" target="https://www.rfc-editor.org/info/rfc8152">
          <front>
            <title>CBOR Object Signing and Encryption (COSE)</title>
            <author fullname="J. Schaad" initials="J." surname="Schaad">
              <organization/>
            </author>
            <date month="July" year="2017"/>
            <abstract>
              <t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size.  There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol.  This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization.  This specification additionally describes how to represent cryptographic keys using CBOR.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8152"/>
          <seriesInfo name="DOI" value="10.17487/RFC8152"/>
        </reference>
        <reference anchor="I-D.ietf-cose-rfc8152bis-struct-15" target="https://www.ietf.org/archive/id/draft-ietf-cose-rfc8152bis-struct-15.txt">
          <front>
            <title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>
            <author fullname="Jim Schaad" initials="J." surname="Schaad">
              <organization>August Cellars</organization>
            </author>
            <date day="1" month="February" year="2021"/>
            <abstract>
              <t>   Concise Binary Object Representation (CBOR) is a data format designed
   for small code size and small message size.  There is a need for the
   ability to have basic security services defined for this data format.
   This document defines the CBOR Object Signing and Encryption (COSE)
   protocol.  This specification describes how to create and process
   signatures, message authentication codes, and encryption using CBOR
   for serialization.  This specification additionally describes how to
   represent cryptographic keys using CBOR.

   This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes
   RFC8152.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-cose-rfc8152bis-struct-15"/>
        </reference>
        <reference anchor="RFC1590" target="https://www.rfc-editor.org/info/rfc1590">
          <front>
            <title>Media Type Registration Procedure</title>
            <author fullname="J. Postel" initials="J." surname="Postel">
              <organization/>
            </author>
            <date month="March" year="1994"/>
            <abstract>
              <t>Several 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1590"/>
          <seriesInfo name="DOI" value="10.17487/RFC1590"/>
        </reference>
        <reference anchor="RFC1521" target="https://www.rfc-editor.org/info/rfc1521">
          <front>
            <title>MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies</title>
            <author fullname="N. Borenstein" initials="N." surname="Borenstein">
              <organization/>
            </author>
            <author fullname="N. Freed" initials="N." surname="Freed">
              <organization/>
            </author>
            <date month="September" year="1993"/>
            <abstract>
              <t>This 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1521"/>
          <seriesInfo name="DOI" value="10.17487/RFC1521"/>
        </reference>
        <reference anchor="RFC2616" target="https://www.rfc-editor.org/info/rfc2616">
          <front>
            <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
            <author fullname="R. Fielding" initials="R." surname="Fielding">
              <organization/>
            </author>
            <author fullname="J. Gettys" initials="J." surname="Gettys">
              <organization/>
            </author>
            <author fullname="J. Mogul" initials="J." surname="Mogul">
              <organization/>
            </author>
            <author fullname="H. Frystyk" initials="H." surname="Frystyk">
              <organization/>
            </author>
            <author fullname="L. Masinter" initials="L." surname="Masinter">
              <organization/>
            </author>
            <author fullname="P. Leach" initials="P." surname="Leach">
              <organization/>
            </author>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee">
              <organization/>
            </author>
            <date month="June" year="1999"/>
            <abstract>
              <t>HTTP 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2616"/>
          <seriesInfo name="DOI" value="10.17487/RFC2616"/>
        </reference>
        <reference anchor="RFC8866" target="https://www.rfc-editor.org/info/rfc8866">
          <front>
            <title>SDP: Session Description Protocol</title>
            <author fullname="A. Begen" initials="A." surname="Begen">
              <organization/>
            </author>
            <author fullname="P. Kyzivat" initials="P." surname="Kyzivat">
              <organization/>
            </author>
            <author fullname="C. Perkins" initials="C." surname="Perkins">
              <organization/>
            </author>
            <author fullname="M. Handley" initials="M." surname="Handley">
              <organization/>
            </author>
            <date month="January" year="2021"/>
            <abstract>
              <t>This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8866"/>
          <seriesInfo name="DOI" value="10.17487/RFC8866"/>
        </reference>
        <reference anchor="RFC6690" target="https://www.rfc-editor.org/info/rfc6690">
          <front>
            <title>Constrained RESTful Environments (CoRE) Link Format</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby">
              <organization/>
            </author>
            <date month="August" year="2012"/>
            <abstract>
              <t>This 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6690"/>
          <seriesInfo name="DOI" value="10.17487/RFC6690"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgements" toc="default">
      <name>Acknowledgements</name>
      <t><contact fullname="Matthias Kovatsch"/> forced the authors to make up their minds about this.
<contact fullname="Ari Keränen"/> forced them to write it up, then, and created a convincing
use case of Content-Format-Strings.
<contact fullname="John Mattsson"/> alerted us to a mistake.
<contact fullname="Alexey Melnikov"/> suggested reviving this draft after a year of dormancy.</t>
      <!--  LocalWords:  subtype HTAB subregistry ciphertext subparameters
 -->

</section>
  </back>
  <!-- ##markdown-source:
H4sIABSpM2AAA9Vb2XrcyHW+r6eogeJwGaLJbi4iqcWiSMliLEqKSH1yPDMx
q4Fqdg3RQA9QINVDU5/fIS+QCz9J/CZ5kvznVGElORM7V9FFsxuo9Sz/+c+p
UhiGIs6iVM30voxzNbHhOMtnKk3DKMt1ONOxUfiaWp3a0C7mOpzQexsmyurC
isKqNP6TSrIUA9i81MLMc/5W2NHGxt7GSETK7svCxuIRxil0WpTFvlxa6GJJ
PCrK8cwUhcEEGHtfHr86ey3mZl9IGWWzuYps1VRKq79gWlPYsFjMxlmCUbLV
b0O8wShN6zSjxkWW21xPiqY7OvUe2Nx0xs+i6oc1NsFq3qfyhAVwhsUVa/LQ
y8H/xM5lrkkQMRaXz0yaJdnFQqjxONdX+93mIka7fTnaGA3DjVE4GglV2mmW
01ZpD1I6JRyqvEAv+dKpgd9k+cW+/JSaK50Xxv7tr1a+zPUMjc7+eMwNsBWt
sZUPWWEnKprKzc2Nra0NfhcZu9j3HdyDLMY8R+Fod3N7zz8pU5uj1e80Tbrg
h/Mp6/Tbrb1wC2seDXfDnc290ZBf6pkyyb6M1Dh7YX82A6ywt483Or2UL01+
Oc2Sn5tdvM5VmU6zic7l6fEZP6/Edc8rP80UYw3GfqwXEMFgUrcdxLojgo9T
bVL8UEWh5ePt1o6XdrZGe9tLLaEcqXwGA47t/VIQKZs6xE5KOj54dzBgp5ir
HFuExmFMvQdVO+c3ZNNo0/pRvZ9aO++M03sgTDppJn8k5cfXhxsbo419qYrI
GP9kc2e0ty9LO9kV/HtrtLvrp2NXzfVFmCWxe7k92txC93E6cb93djf7jd2L
x6PNoVtQ9Xt7RBtV9Ps4PBpc6lyl2iMEHHqWhDBuwAT5Of+MrOu6O3RdC+27
Gm0nIf0O80lEb8emCKGtMrLhcNs1xSMhwjDEWkmPGEucTXWupSmkkklmZTZB
w3RSEm6gVVbatozXZBuvnJ+Ke/x0QONizJmeZTw2xrJWz+YWf2WUaJWb9EIa
K8v5GgBFXmsYfCpLGBYhmSE/taI1ojQpnP7jqw4yFHMdmYkBCmK1xUAcY/gE
o8V6YlJdYOCZlgcv372WdkrzYoaxpkliGs5ONabrj8HimZk4TrSALRzDbrMY
MsRbFpa81At5neVxIYOTT6dnwZr7K9+95+8fX/3rp+OPr47o++mbg7dv6y/C
tzh98/7T26PmW9Pz8P3Jyat3R64znsrOIxGcHPxb4LAxeP/h7Pj9u4O3gdsJ
ZIxYUwKHIALo02a0UwNd5fNck6wUYFIXUW7GbvcvDz/8138Ot+TNzTewptFw
uHd763/sDh9v4cc1sMHNlqXJwv+E0IDC8zk0SKOoJIFY58ZC7mgLkU+z61SS
TUGU4ubmtxhvuL23gfGMFyXmZ5OSbEM8AUY1OdR6YcgsSdYDyBoqqzdls+xS
nhyfvPK9Jnk2k9XwoyGGp3Eu1JWmwWaw5lRfM14OxIF1+rdmpnkHbKoyaFYR
yGusPZtQdGDz+BExVgImuPVM/ZjlgtrJ5YBCJalHlbHJghUnoGsanm0Y8lAt
j5Fpds1jYxyBQDo2KW+P/MxNzf0VxVn6NZCSHScBOGFBKcn45ibsQMnt7Zq4
nhqEojhDoxReq6+w8CltHibOBo9OhEeQy7y2X95Qs+mBuDvyUoH2OtaRLhDm
1+7MTZiH+bHc+TwxmjXnJnSKx3KXb25oZsdo/LagnxXYw9NxkkWXP5WZJaHm
lzG6PAuGwXPx9etXxs8nhKnck1Qnn5FN8FfhR7rzXFTf8HC4Ohw9rn6H0RTx
XnR/otHB2w9vDuS6PDr+3fEZ/gbfBHKdo1TnX/AooJf/xJ//zJ+D+xt+yy9D
/vx3/vxTQBsSN/vy0V1RwD8t8OMyVIm5wPYjTV4aSCZGzwIWJlueN45q52sU
WSFxtnyYvaSQFNyKp+uNVJ+Le3S6JrNxkSXaEuQ+pNBcO87mLHViwJQkSQwx
AqSBrbUWNMBFJfOpSuGa6MO4S3FBgR2wQWT4yK8NoStoRmoN+cVC6p9Kc6US
cueOyWDN9LsjphEtCu9h2blUcUxrhyVzfJgRIhTOpydlTpOJxMyM5ckphmC9
pC0Hld8GML2vlYX1rMvtWscPGFn3teg9uNskdJKDHe7031TmeF/7vlneaeaM
9yHrdcZ61zRrE21bcc9Q75/pmTP3J/KwsoECAQVmqaVbcZxRrL1Wi+Lhaenf
Ex9gFzAg0GdtGZN/YdZve7Mib4IFJApzzpOy+LsndQyozIkuLGCjX4Bdk4n5
whbBLnrX9h70RVn7IiDdsYyWQxLtg0MSbWhyG5CGLFaLh+KOKThEXOgUzI+c
hMMPzal8PEQoje8PHc4GO/GDH/HqrjWFoqIKYqLDc5zvVDSJVlY5KkVBxyda
Uw7EZ115moxNofDmogQFk+MFxzzyThqFiDX5q1xt9sgKX0UU9pGJZzXVTs4b
SYXv0PB8X9TBQPTewfybbQfrQWfToqPOfk+v0KPO3L1GpLrXPuTPy3wOsGmk
QUx2jUK8ExpW2eu9L/blgfy79AQjblTcjvSOXRMCAlYR2mk4Ng4T048JBV5I
ni3qOhMuLwT30pTlWPcSU8FppoC+ZccotLryunZWyOuXZ2yFFdOBz5UqkXdt
RWCE1lrLNNauR08KgxWy/nZ27gXlaRtRcOYpTT52H79xzB0CdDwHjFZU3ub3
3bKv3mqZ+cKYkTdlOTKR41S+OTv7wPKn3NNFJwomNosyoq2NzEMnSGraWiBN
jz6eGtrsQvMIRH9l0N5rAOKrSDLQUBIPBM+L7VHCByZWFl4B7Aesb85NI3t7
u/+/ZkftCeERzeJFi3Y6T2k7iVxdlu8/n8rgScB/6/3JFUdt3T90zC51WkXC
9iP+bECW6JYl3Bb82X7RCkpV7PlNKwIt8edq0Afx9S6XGnQCFX2e8+ef+fPr
Pd2roMhBUtAu6yVh96cf8OrN2cFL7LgCCy//X+FkHZG7oFBhPmX0d0nYcdro
GRiMYKfGiSmmbL8+KxrtDHfI1KEIWzS2PtYRoUVtNS5w5GXigLStZPhkK1r0
Ie/a2GnHiq1VEVbAYB5n6RIlOEmC4MMAZ9II4RVpR0WgmomeUI6hHQ7c3NRL
57wGlM5qXzKgLJMrBjwgowzFh0SBmyFAIDE41S6R3hw8pinqoVZg/s+hp5Nm
cyCKpWbfawMPb4oEckwKSkEnDooCKsOrd+VsDCJIwxxw+c/YhVymkpD8/rvh
3g8rVVGCyw8A05y4JfHIzPFGwjSuudJi74YHAn/sccDaRf5PAJgR/8sSCK0C
LB86fQWlFTHIDlQN0SwdbLptWS6C9GYFeZ/X8K+QlEWGEb6v3eUG/Mk2qeba
Rck6BrHpaqpkOiB0sULPDMAwS0lKHxHrrqqQnugLFS2c30QNLSPSUkzLNHWR
a54l3g6okMpIvCZaLMSJh+eLsvG1Hhdt0dA87UjH9WgEItBEZKMFHrciascZ
a3toIJXjf7sRg2vNKTrdCRn6agZSrAIqCCfpbxsnm+9trJTBs0Au++/rkjEg
psobiRDx8P8bbnY3gGX95stoJFd/ikkr/EP4783KGVvxauj+bIbbL/nb9lH4
+JXocrOOBu4lZp2YClb2roIfUnVVrSwA1VNLuFUVDGGmY22vtXboG7DgA8ZI
wf18qUkGVSqL+NjLRFxzwrEr4F6B0dteJFoeBwIxBqovYIOw8bGu8wGySVde
lCDJeSxzZRJiZ9aBfw3scIBUM6NgzCW2sASmSUkWnbnkGpyDEblFmX1lreFY
hxnhFeX9Hlzl5mC7A66uJtqqvtUcsDsG0gbRgloGDA4tqYRsuYm0uUoLXz6v
0oipotxQEyj6EisVCF11KOM0pu3EbV+sisl+8IZqdOyl1+pei+m1URTPOD6T
CMiEDh0kpxcJUjHjKSEJoisDMi2meheGSmpM8RynE8zpONvBxmpK8MpLJnhC
6lxdTSmorK6yQpswuKy/RHpuuYYq0I6iGsbWeZ7lKwOJaAahq7iTX3QXRsGh
nRH+Q+qhoz9XA/8FBQ36U98Jwt64WYS+qfTi++hKuAuyJVBIX9FdkIq84bdO
Ym5vsfXPuqm7Oud0SY5dBKJvn44hORXJqllv075izUNO4HiA3yptWjiB9DSO
+OeSZuOVUCW0xsogzXqLCDrO95pnJYEdfFhz4afywqH3QTriIWevkm3V6ywf
Kg53YNIlj315dNNBJXxBrnme16DkdRbQSnsrKAJZ62n5PrX1DuJA19bkuCTo
rcDK+5Y/F1k2VsQm5sr01FfkYXQplmIdR9LSW1zv+GWlZXxucWT3jh78X8QD
w2ea8wsC8nnl/QJyB+G/JpbB3UhFzkdiYAdUXZLjA+wdjiP48OEf2/STnviI
ecENcl82c8DTLyLURy9cauqZZ8q0uoCnvnHV2DW/NRqKYcTrjsAt95s3hYA7
T8qE5FSdW7q8voNxd1iZnxRUaIPYyvKH96ehYyer/Gel1zI89SwFXTrC+S54
EfSiwg/305DuQL/IR1zTdd+WwgonFIqyqKJdfL53bOiipGJGIYKW3NZ/LLL0
BSRCR5p8mjdPVKQrP0l0QdQhmYT+9I6CfbUvB3oyGA43tjeCNQrAFceuDcfX
yeOscUfVH8DpuHaFhbZ3/LDeQ3XWKfUX2gPEtaihuxeFOYUjg24gHdgw0AO4
5oTiVg3hvY50mqkLA2t02S+1yrWoMiFOmV3CGldpCqmbEkHJpa4JcKa0Kx2H
VJ6ZV34HuMf8zinrI+0W3Z8RvRT+XINWW03BVswYpvLC54oPCAvRFlIXY064
taMTNsswzGxO120ARXBLDikf6UJGSsORdXrL6pa2uvWjmqH487ZxZhKdz8mM
yNNgZkiBL4zLHFthoDkZJABxtYjd3Z2dbprknM6Re/D4zY1wc69TYd+Q//2X
/5B7ovFQ13DYbzj0Dd3JRT3i1jDcPuAcYWcYPj5AwwNu+Ec8U/ztZ4Gsos4w
KK3Y6B6rtXbcVGpmMz6t/kQsnuXUuHJBHvtIHvClGOO8o12e9GVUAjbKV+m4
uPBXaFzSDTAPZtYfwXevINGryAaO0CA1oOoxe5wn93ZKD1R76n352SMm3DyD
W5M3Vn7vyx+tKwtrdUMus/crj9SSiL6objhgYndaN9Wzgatsw6QsjAIEB4Cv
gDvIwsdADG8FOzt8Tu/MIqRbKa5oyfykvXTeKpPPHm4vU+Zz6Y+IaBw+t6nL
Bit+Hf1AzaXn7vhR0N47e8iRKaKSL7S5ixgtL6iyQgj+yhQOJFy9d+FSLK4/
OLKSaJWW8zXhwViWKZhhBSNXKjdZyacmMy7KVZnimstM1qS2EdXUeXIO1O4U
k4SBPLCs7i/QalwVkTTHjt9UCJ0BWXVx4dNFcf7UVyDZEJ8FVbU3GAwGz88r
9vaHk7dMghNnNPUdKieK9lEFRWCCQVfQJNPtTijPnxZZmUea7m+15nTzURWf
JPyHDwpNAfQgKHwh6Hx9ven23Qvut0T9ln5Yp4rA8sp5W20iq9ctG+O+g2uw
VPQlE2nQrQIsn+9+blLl2JkB5il0aPjWI7z7isIILJAVPc+Q7bbShbIoCQUF
VOMK91UnvqTySJ6WEExBHl4W6oLu/YDivz991c2qK0ZPd6vgGA2hjxh0uEd1
AFCHEbHsg+vmSp07+oBTnQA6GbnwPncpDOUsaUzycc7H6OSRge6DVZ3mapFk
SFko8zZz7I3LMpypFlW5s78iVpA2rvbHF0bK1JdQ6b7QBTE8Pzmn0nzt6n5W
yIxDcbXOR9UB201Cl72Ic1KN1lmoKdwtolYg8meenCG7y1usNy7INnLfGoy8
3Ol4FXInT1viKT1Guiq292DhD3npBsD3T+sznefr3z9tH709J0NfcmmMuzLm
rMoFWOFpXLt67g5/mydUFPd+l1M8N4kiBmUp5eyad4VLMeHYGddevtjm7k5l
z/fQx6omkfqSTS1mDhVrTQmKDg1KF3Cm1CMxl7qTZtX3qPQXw4aOrJXH5CtR
EaKBV/Y1sgG6RzV3l4TrmrvPnPp24FQwoDNGv0DWMqU9WCjgPCH0T+FdtAsD
5ZbzmGMpX7itLjg15wLsZL9+nRHJlseoexNJqIo9mly/gvbmHpQ4v5eunbsS
PUcJJsZJ76y6r4T6UuEFl9ccKex5d9v9HUzcQQjjoGPAsHOq05O3QhwUtUX6
YuRayyc2KyE9fF309lbM1KUuKpN6MOd208IbENTc2enEMEzx7T5mG/7gny9n
AnQLPuPlg5XDjEl0XnGpzz42VVHIquSyulnqjoa4m0+kDd0gNY0riJxuCHGd
dkFH0XxljU4r+F4vA7WOSj7X6U982Luz2r45OlOu5EciQIglQoJdwOrZZQo/
pCBnSvTMXWMkrSYZrK8FWR5ZdKLd/SPOyHuyfJf5DKwa1l1nrVfK5PIyJcbg
hJ0rUzTVB68h0dcQ3Ukdq+iS6WtE/aGhC7+Om0eq9+iWOLIzPB0/C9KMiO/N
zc0JcHlqsL3fZ1fKFtH01uFpVRR21+YZgMl44Ku+PABZxkXrcI+uDt4c5Eb+
Xud/+ysssDvQjEa4zulEyF/xtfVdUsYaMmouhiCJI0+qTOvhVIpn/Jdsmkra
RAHuesuVbQp5FLZdJXMGs8LC3fIS/UUv5IlOUnOZXVHzoo7zRDX9ERclm/S/
M/xNI4X0V/GNt5j/m0BE6Zl4+g00IN9mCOGfqca1L+tzdT4Za1eHWpG4EzGE
DMPn4n8Awu8AphcyAAA=

-->

</rfc>
