rfc9193.original.xml   rfc9193.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.12 --> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.12 -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc tocdepth="3"?> -ietf-core-senml-data-ct-07" number="9193" obsoletes="" updates="" submissionTyp
<?rfc tocindent="yes"?> e="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDept
<?rfc symrefs="yes"?> h="3" symRefs="true" sortRefs="true" version="3">
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc strict="no"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-core-senml-data-ct-07" category="std" consensus="true" obsoletes="" update
s="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs=
"true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.9.1 --> <!-- xml2rfc v2v3 conversion 3.9.1 -->
<front> <front>
<title abbrev="SenML Data Content-Format Indication">SenML Data Value Conten <title abbrev="SenML Data Content-Format Indication">Sensor Measurement List
t-Format Indication</title> s (SenML) Fields for Indicating Data Value Content-Format</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-core-senml-data-ct-07"/> <seriesInfo name="RFC" value="9193"/>
<author initials="A." surname="Keränen" fullname="Ari Keränen"> <author initials="A." surname="Keränen" fullname="Ari Keränen">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Jorvas</city> <city>Jorvas</city>
<code>02420</code> <code>02420</code>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<email>ari.keranen@ericsson.com</email> <email>ari.keranen@ericsson.com</email>
</address> </address>
</author> </author>
<author initials="C." surname="Bormann" fullname="Carsten Bormann"> <author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization> <organization>Universität Bremen TZI</organization>
<address> <address>
<postal> <postal>
<street>Postfach 330440</street> <street>Postfach 330440</street>
<city>Bremen</city> <city>Bremen</city>
<code>D-28359</code> <code>D-28359</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone>+49-421-218-63921</phone> <phone>+49-421-218-63921</phone>
<email>cabo@tzi.org</email> <email>cabo@tzi.org</email>
</address> </address>
</author> </author>
<date year="2021"/> <date year="2022" month="June"/>
<keyword>Internet-Draft</keyword> <keyword>Internet of Things (IoT)</keyword>
<keyword>Internet of Things</keyword>
<keyword>IOT</keyword>
<keyword>data model</keyword>
<keyword>media type</keyword>
<abstract> <abstract>
<t>The Sensor Measurement Lists (SenML) media type supports multiple types <t>The Sensor Measurement Lists (SenML) media types support multiple types
of values, from numbers to text strings and arbitrary binary data values. of values, from numbers to text strings and arbitrary binary Data Values.
In order to facilitate processing of binary data values, this document In order to facilitate processing of binary Data Values, this document
specifies a pair of new SenML fields for indicating the specifies a pair of new SenML fields for indicating the
content format of those binary data values, i.e., their Internet media content format of those binary Data Values, i.e., their Internet media
type including parameters as well as any content codings applied.</t> type, including parameters as well as any content codings applied.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>The Sensor Measurement Lists (SenML) media types <xref target="RFC8428" format="default"/> can be used <t>The Sensor Measurement Lists (SenML) media types <xref target="RFC8428" format="default"/> can be used
to send various kinds of data. In the example given in to send various kinds of data. In the example given in
<xref target="ex-1" format="default"/>, a temperature value, an indication wheth er a lock is open, and <xref target="ex-1" format="default"/>, a temperature value, an indication wheth er a lock is open, and
a data value (with SenML field "vd") read from an NFC reader is sent in a a Data Value (with SenML field "vd") read from a Near Field Communication (NFC)
single SenML pack. reader is sent in a
The example is given in SenML JSON representation, so the "vd" (data single SenML Pack.
value) field is encoded as a base64url string (without The example is given in SenML JSON representation, so the "vd" (Data
Value) field is encoded as a base64url string (without
padding), as per <xref section="5" sectionFormat="of" target="RFC8428" format="d efault"/>.</t> padding), as per <xref section="5" sectionFormat="of" target="RFC8428" format="d efault"/>.</t>
<figure anchor="ex-1"> <figure anchor="ex-1">
<name>SenML pack with unidentified binary data</name> <name>SenML Pack with Unidentified Binary Data</name>
<sourcecode type="senml-json"><![CDATA[ <sourcecode type="senml-json"><![CDATA[
[ [
{"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":7.1}, {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":7.1},
{"n":"open","vb":false}, {"n":"open","vb":false},
{"n":"nfc-reader","vd":"aGkgCg"} {"n":"nfc-reader","vd":"aGkgCg"}
] ]
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>The receiver is expected to know how to interpret the data in the "vd" <t>The receiver is expected to know how to interpret the data in the "vd"
field based on the context, e.g., name of the data source and out-of-band field based on the context, e.g., the name of the data source and out-of-band
knowledge of the application. However, this context may not always be knowledge of the application. However, this context may not always be
easily available to entities processing the SenML pack, especially if easily available to entities processing the SenML Pack, especially if
the pack is propagated over time and via multiple entities. To facilitate the Pack is propagated over time and via multiple entities. To facilitate
automatic interpretation it is useful to be able to indicate an Internet automatic interpretation, it is useful to be able to indicate an Internet
media type and, optionally, content codings right in the SenML Record.</t> media type and, optionally, content codings right in the SenML Record.</t>
<t>The CoAP <t>The Constrained Application Protocol (CoAP)
Content-Format (<xref section="12.3" sectionFormat="of" target="RFC7252" format= "default"/>) provides this Content-Format (<xref section="12.3" sectionFormat="of" target="RFC7252" format= "default"/>) provides this
information in the form of a single unsigned integer; enclosing a Content-Format information in the form of a single unsigned integer. For instance, <xref target
number (in this case number 60 as ="RFC8949" format="default"/> defines the Content-Format number 60 for
defined for content-type application/cbor in <xref target="RFC8949" format="defa Content-Type application/cbor. Enclosing this Content-Format number in the Recor
ult"/>) in the Record is d is illustrated in <xref target="ex-2" format="default"/>. All registered CoAP
illustrated in <xref target="ex-2" format="default"/>. All registered CoAP Conte Content-Format numbers are listed
nt-Format numbers are listed in the "CoAP Content-Formats" registry <xref target="IANA.core-parameters" forma
in the <xref section="COAP Content-Formats registry" relative="#content-formats" t="default"/>, as specified by
sectionFormat="bare" target="IANA.core-parameters" format="default"/> <xref tar
get="IANA.core-parameters" format="default"/> as specified by
<xref section="12.3" sectionFormat="of" target="RFC7252" format="default"/>. <xref section="12.3" sectionFormat="of" target="RFC7252" format="default"/>.
Note that, at the time of writing, the structure of this registry only Note that, at the time of writing, the structure of this registry only
provides for zero or one content codings; nothing in the present provides for zero or one content coding; nothing in the present
document needs to change if the registry is extended to allow document needs to change if the registry is extended to allow
sequences of content codings.</t> sequences of content codings.</t>
<figure anchor="ex-2"> <figure anchor="ex-2">
<name>SenML Record with binary data identified as CBOR</name> <name>SenML Record with Binary Data Identified as CBOR</name>
<sourcecode type="json"><![CDATA[ <sourcecode type="json"><![CDATA[
{"n":"nfc-reader", "vd":"gmNmb28YKg", "ct":"60"} {"n":"nfc-reader", "vd":"gmNmb28YKg", "ct":"60"}
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>In this example SenML Record, the data value contains a string "foo" an <t>In this example SenML Record, the Data Value contains a string "foo" an
d a d a
number 42 encoded in a CBOR <xref target="RFC8949" format="default"/> array. Sin number 42 encoded in a Concise Binary Object Representation (CBOR) <xref target=
ce the example above "RFC8949" format="default"/> array. Since the example above
uses the JSON format of SenML, the data value containing the binary CBOR uses the JSON format of SenML, the Data Value containing the binary CBOR
value is base64-encoded (<xref section="5" sectionFormat="of" target="RFC4648" f value is base64 encoded (<xref section="5" sectionFormat="of" target="RFC4648" f
ormat="default"/>). ormat="default"/>).
The data value after base64 decoding is shown The Data Value after base64 decoding is shown
with CBOR diagnostic notation in <xref target="ex-2-cbor" format="default"/>.</t > with CBOR diagnostic notation in <xref target="ex-2-cbor" format="default"/>.</t >
<figure anchor="ex-2-cbor"> <figure anchor="ex-2-cbor">
<name>Example Data Value in CBOR diagnostic notation</name> <name>Example Data Value in CBOR Diagnostic Notation</name>
<sourcecode type="cbor-pretty"><![CDATA[ <sourcecode type="cbor-pretty"><![CDATA[
82 # array(2) 82 # array(2)
63 # text(3) 63 # text(3)
666F6F # "foo" 666F6F # "foo"
18 2A # unsigned(42) 18 2A # unsigned(42)
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<section anchor="evolution" numbered="true" toc="default"> <section anchor="evolution" numbered="true" toc="default">
<name>Evolution</name> <name>Evolution</name>
<t>As with SenML in general, there is no expectation that the creator of <t>As with SenML in general, there is no expectation that the creator of
a SenML pack knows (or has negotiated with) each consumer of that pack, a SenML Pack knows (or has negotiated with) each consumer of that Pack,
which may be very remote in space and particularly in time. which may be very remote in space and particularly in time.
This means that the SenML creator in general has no way to know This means that the SenML creator in general has no way to know
whether the consumer knows:</t> whether the consumer knows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>each specific media-type-name used</li> <li>each specific Media-Type-Name used,</li>
<li>each parameter and each parameter value used</li> <li>each parameter and each parameter value used,</li>
<li>each content coding in use</li> <li>each content coding in use, and</li>
<li>each Content-Format number in use for a combination of these</li> <li>each Content-Format number in use for a combination of these.</li>
</ul> </ul>
<t>What SenML, as well as the new fields defined here, guarantees is tha t <t>What SenML, as well as the new fields defined here, guarantees is tha t
a recipient implementation <em>knows</em> when it needs to be updated to a recipient implementation <em>knows</em> when it needs to be updated to
understand these field values and the values controlled by them; understand these field values and the values controlled by them;
registries are used to evolve these name spaces in a controlled way. registries are used to evolve these name spaces in a controlled way.
SenML packs can be processed by a consumer while not understanding all SenML Packs can be processed by a consumer while not understanding all
the information in them, and information can generally be preserved in the information in them, and information can generally be preserved in
this processing such that it is useful for further consumers.</t> this processing such that it is useful for further consumers.</t>
</section> </section>
</section> </section>
<section anchor="terminology" numbered="true" toc="default"> <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 >REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL</bcp14> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 >REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL</bcp14>
NOT", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED< /bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED< /bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as
described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref target= "RFC8174" format="default"/> when, and only when, they 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> appear in all capitals, as shown here.</t>
<dl> <dl newline="false" spacing="normal">
<dt> <dt>Media type: </dt>
Media Type: </dt> <dd>A registered label for representations (byte strings) prepared for
<dd> interchange <xref target="RFC1590" format="default"/>
<t>A registered label for representations (byte strings) prepared for <xref target="RFC6838" format="default"/>, identified by a Media-Type-Name.</dd>
interchange, identified by a Media-Type-Name <xref target="RFC1590" format="defa <dt>Media-Type-Name: </dt>
ult"/>, <dd>A combination of a type-name and a subtype-name registered in
<xref target="RFC6838" format="default"/>.</t> <xref target="IANA.media-types" format="default"/>, as per <xref target="RFC6838
</dd> " format="default"/>, conventionally
<dt> identified by the two names separated by a slash.</dd>
Media-Type-Name: </dt> <dt>Content-Type: </dt>
<dd> <dd>A Media-Type-Name, optionally associated with parameters
<t>A combination of a type-name and a subtype-name registered in
<xref target="IANA.media-types" format="default"/> as per <xref target="RFC6838"
format="default"/>, conventionally
identified by the two names separated by a slash.</t>
</dd>
<dt>
Content-Type: </dt>
<dd>
<t>A Media-Type-Name, optionally associated with parameters
(<xref section="5" sectionFormat="of" target="RFC2045" format="default"/>, separ ated from (<xref section="5" sectionFormat="of" target="RFC2045" format="default"/>, separ ated from
the Media-Type-Name and from each other by a semicolon). the Media-Type-Name and from each other by a semicolon).
In HTTP and many other protocols, used in a <tt>Content-Type</tt> header field.< In HTTP and many other protocols, it is used in a <tt>Content-Type</tt> header f
/t> ield.</dd>
</dd> <dt>Content coding: </dt>
<dt> <dd>A name registered in the "HTTP Content Coding Registry"
content coding: </dt> <xref target="IANA.http-parameters" format="default"/>, as specified by
<dd> Sections <xref target="RFC9110" section="16.6.1" sectionFormat="bare" format="de
<t>A name registered in the <xref section="HTTP Content Coding registr fault"/> and <xref target="RFC9110" section="18.6" sectionFormat="bare" format="
y" relative="#content-coding" sectionFormat="bare" target="IANA.http-parameters" default"/> of <xref target="RFC9110" format="default"/>, indicating an encoding
format="default"/> <xref target="IANA.http-parameters" format="default"/> as sp transformation with semantics further specified in <xref section="8.4.1" section
ecified by Format="of" target="RFC9110" format="default"/>.
Sections <xref target="I-D.ietf-httpbis-semantics" section="16.6.1" sectionForma
t="bare" format="default"/> and <xref target="I-D.ietf-httpbis-semantics" sectio
n="18.6" sectionFormat="bare" format="default"/> of <xref target="I-D.ietf-httpb
is-semantics" format="default"/>, indicating an encoding
transformation with semantics further specified in <xref section="8.4.1" section
Format="of" target="I-D.ietf-httpbis-semantics" format="default"/>.
Confusingly, in HTTP, content coding values are found in a header field Confusingly, in HTTP, content coding values are found in a header field
called "Content-Encoding", however "content coding" is the correct called "Content-Encoding"; however, "content coding" is the correct
term for the process and the registered values.</t> term for the process and the registered values.</dd>
</dd> <dt>Content format: </dt>
<dt> <dd>The combination of a Content-Type and zero or more content codings,
content format: </dt> identified
<dd> by (1) a numeric identifier defined in the "CoAP Content-Formats" registry <xref
<t>the combination of a Content-Type and zero or more content codings, target="IANA.core-parameters" format="default"/>,
identified
by (1) a numeric identifier defined in the <xref section="COAP Content-Formats r
egistry" relative="#content-formats" sectionFormat="bare" target="IANA.core-para
meters" format="default"/> <xref target="IANA.core-parameters" format="default"/
>
as per <xref section="12.3" sectionFormat="of" target="RFC7252" format="default" /> (referred to as Content-Format as per <xref section="12.3" sectionFormat="of" target="RFC7252" format="default" /> (referred to as Content-Format
number), or (2) a Content-Format-String.</t> number), or (2) a Content-Format-String.</dd>
</dd> <dt>Content-Format-String:</dt>
<dt> <dd>The string representation of the combination of a Content-Type and
Content-Format-String: </dt> zero or more content codings.</dd>
<dd> <dt>Content-Format-Spec:</dt>
<t>the string representation of the combination of a Content-Type and <dd>The string representation of a content format; either a
zero or more content codings.</t> Content-Format-String or the (decimal) string representation of a
</dd> Content-Format number.</dd>
<dt>
Content-Format-Spec: </dt>
<dd>
<t>the string representation of a content format; either a
Content-Format-String or the (decimal) string representation of a
Content-Format number.</t>
</dd>
</dl> </dl>
<t>Readers should also be familiar with the terms and concepts discussed i n <t>Readers should also be familiar with the terms and concepts discussed i n
<xref target="RFC8428" format="default"/>.</t> <xref target="RFC8428" format="default"/>.</t>
</section> </section>
<section anchor="senml-content-format-ct-field" numbered="true" toc="default "> <section anchor="senml-content-format-ct-field" numbered="true" toc="default ">
<name>SenML Content-Format ("ct") Field</name> <name>SenML Content-Format ("ct") Field</name>
<t>When a SenML Record contains a Data Value field ("vd"), the Record <bcp 14>MAY</bcp14> <t>When a SenML Record contains a Data Value field ("vd"), the Record <bcp 14>MAY</bcp14>
also include a Content-Format indication field, using label "ct". The also include a Content-Format indication field, using label "ct". The
value of this field is a Content-Format-Spec, i.e., one of:</t> value of this field is a Content-Format-Spec, i.e., one of the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>a CoAP Content-Format number in decimal form with no leading <li>a CoAP Content-Format number in decimal form with no leading
zeros (except for the value "0" itself). This value represents an zeros (except for the value "0" itself). This value represents an
unsigned integer in the range of 0-65535, similar to the "ct" unsigned integer in the range of 0-65535, similar to the "ct"
attribute defined in <xref section="7.2.1" sectionFormat="of" target="RFC7252" f ormat="default"/> for CoRE Link attribute defined in <xref section="7.2.1" sectionFormat="of" target="RFC7252" f ormat="default"/> for CoRE Link
Format <xref target="RFC6690" format="default"/>).</li> Format <xref target="RFC6690" format="default"/>.</li>
<li>or a Content-Format-String containing a Content-Type and <li>a Content-Format-String containing a Content-Type and
zero or more content codings (see below).</li> zero or more content codings (see below).</li>
</ul> </ul>
<t>The syntax of this field is formally defined in <xref target="abnf" for mat="default"/>.</t> <t>The syntax of this field is formally defined in <xref target="abnf" for mat="default"/>.</t>
<t>The CoAP Content-Format number provides a simple and efficient way <t>The CoAP Content-Format number provides a simple and efficient way
to indicate the type of the data. Since some Internet media types and to indicate the type of the data. Since some Internet media types and
their content coding and parameter alternatives do not have assigned their content coding and parameter alternatives do not have assigned
CoAP Content-Format numbers, using Content-Type and zero or more CoAP Content-Format numbers, using Content-Type and zero or more
content codings content codings
is also allowed. Both methods use a string value in the "ct" field to is also allowed. Both methods use a string value in the "ct" field to
keep its data type consistent across uses. When the "ct" field keep its data type consistent across uses. When the "ct" field
contains only digits, it is interpreted as a CoAP Content-Format contains only digits, it is interpreted as a CoAP Content-Format
number.</t> number.</t>
<t>To indicate that one or more content codings are used with a Content-Ty pe, <t>To indicate that one or more content codings are used with a Content-Ty pe,
each of the content coding values is appended to the Content-Type value (media each of the content coding values is appended to the Content-Type value (media
type and parameters, if any), separated by a "@" sign, in the order of type and parameters, if any), separated by an "@" sign, in the order of when
the content codings were applied (the same order as in <xref section="8.4" secti the content codings were applied (the same order as in <xref section="8.4" secti
onFormat="of" target="I-D.ietf-httpbis-semantics" format="default"/>). onFormat="of" target="RFC9110" format="default"/>).
For example (using a content coding value of "deflate" as defined in For example (using a content coding value of "deflate", as defined in
<xref section="8.4.1.2" sectionFormat="of" target="I-D.ietf-httpbis-semantics" f <xref section="8.4.1.2" sectionFormat="of" target="RFC9110" format="default"/>):
ormat="default"/>):</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
text/plain; charset=utf-8@deflate text/plain; charset=utf-8@deflate
]]></artwork> ]]></artwork>
<t>If no "@" sign is present after the media type and parameters, <t>If no "@" sign is present after the media type and parameters,
then no content coding has been specified, and the "identity" then no content coding has been specified, and the "identity"
content coding is used -- no encoding transformation is employed.</t> content coding is used -- no encoding transformation is employed.</t>
</section> </section>
<section anchor="senml-base-content-format-bct-field" numbered="true" toc="d efault"> <section anchor="senml-base-content-format-bct-field" numbered="true" toc="d efault">
<name>SenML Base Content-Format ("bct") Field</name> <name>SenML Base Content-Format ("bct") Field</name>
<t>The Base Content-Format Field, label "bct", provides a default value fo <t>The Base Content-Format field, label "bct", provides a default value fo
r r
the Content-Format Field (label "ct") within its range. The range of the the Content-Format field (label "ct") within its range. The range of the
base field includes the Record containing it, up to (but not including) base field includes the Record containing it, up to (but not including)
the next Record containing a "bct" field, if any, or up to the end of the the next Record containing a "bct" field, if any, or up to the end of the
pack otherwise. The process of resolving (<xref section="4.6" sectionFormat="of " target="RFC8428" format="default"/>) this base Pack otherwise. The process of resolving (<xref section="4.6" sectionFormat="of " target="RFC8428" format="default"/>) this base
field is performed by adding its value with the label "ct" to all Records field is performed by adding its value with the label "ct" to all Records
in this range that carry a "vd" field but do not already contain a in this range that carry a "vd" field but do not already contain a
Content-Format ("ct") field.</t> Content-Format ("ct") field.</t>
<t><xref target="ex-bct" format="default"/> shows a variation of <xref tar get="ex-2" format="default"/> with multiple records, with the <t><xref target="ex-bct" format="default"/> shows a variation of <xref tar get="ex-2" format="default"/> with multiple records, with the
"nfc-reader" records resolving to the base field value "60" and the "nfc-reader" records resolving to the base field value "60" and the
"iris-photo" record overriding this with the "image/png" media type "iris-photo" record overriding this with the "image/png" media type
(actual data left out for brevity).</t> (actual data left out for brevity).</t>
<figure anchor="ex-bct"> <figure anchor="ex-bct">
<name>SenML pack with bct field</name> <name>SenML Pack with the bct Field</name>
<sourcecode type="senml-json"><![CDATA[ <sourcecode type="senml-json"><![CDATA[
[ [
{"n":"nfc-reader", "vd":"gmNmb28YKg", {"n":"nfc-reader", "vd":"gmNmb28YKg",
"bct":"60", "bt":1627430700}, "bct":"60", "bt":1627430700},
{"n":"nfc-reader", "vd":"gmNiYXIYKw", "t":10}, {"n":"nfc-reader", "vd":"gmNiYXIYKw", "t":10},
{"n":"iris-photo", "vd":".....", "ct":"image/png", "t":10}, {"n":"iris-photo", "vd":".....", "ct":"image/png", "t":10},
{"n":"nfc-reader", "vd":"gmNiYXoYLA", "t":20} {"n":"nfc-reader", "vd":"gmNiYXoYLA", "t":20}
] ]
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
skipping to change at line 297 skipping to change at line 272
<li>"text/csv" (Comma-Separated Values (CSV) <xref target="RFC4180" form at="default"/> Content-Type)</li> <li>"text/csv" (Comma-Separated Values (CSV) <xref target="RFC4180" form at="default"/> Content-Type)</li>
<li>"text/csv;header=present@gzip" (CSV with header row, using "gzip" as <li>"text/csv;header=present@gzip" (CSV with header row, using "gzip" as
content coding)</li> content coding)</li>
</ul> </ul>
</section> </section>
<section anchor="abnf" numbered="true" toc="default"> <section anchor="abnf" numbered="true" toc="default">
<name>ABNF</name> <name>ABNF</name>
<t>This specification provides a formal definition of the syntax of <t>This specification provides a formal definition of the syntax of
Content-Format-Spec strings using ABNF notation <xref target="RFC5234" format="d efault"/>, which Content-Format-Spec strings using ABNF notation <xref target="RFC5234" format="d efault"/>, which
contains three new rules and a number of rules collected and adapted contains three new rules and a number of rules collected and adapted
from various RFCs <xref target="I-D.ietf-httpbis-semantics" format="default"/> < xref target="RFC6838" format="default"/> <xref target="RFC5234" format="default" /> <xref target="RFC8866" format="default"/>.</t> from various RFCs <xref target="RFC9110" format="default"/> <xref target="RFC683 8" format="default"/> <xref target="RFC5234" format="default"/> <xref target="RF C8866" format="default"/>.</t>
<figure anchor="content-format-spec"> <figure anchor="content-format-spec">
<name>ABNF syntax of Content-Format-Spec</name> <name>ABNF Syntax of Content-Format-Spec</name>
<sourcecode type="abnf"><![CDATA[ <sourcecode type="abnf"><![CDATA[
; New in this document ; New in this document
Content-Format-Spec = Content-Format-Number / Content-Format-String Content-Format-Spec = Content-Format-Number / Content-Format-String
Content-Format-Number = "0" / (POS-DIGIT *DIGIT) Content-Format-Number = "0" / (POS-DIGIT *DIGIT)
Content-Format-String = Content-Type *("@" Content-Coding) Content-Format-String = Content-Type *("@" Content-Coding)
; Cleaned up from [RFC-httpbis-semantics], ; Cleaned up from RFC 9110,
; leaving only SP as blank space, ; leaving only SP as blank space,
; removing legacy 8-bit characters, and ; removing legacy 8-bit characters, and
; leaving the parameter as mandatory with each semicolon: ; leaving the parameter as mandatory with each semicolon:
Content-Type = Media-Type-Name *( *SP ";" *SP parameter ) Content-Type = Media-Type-Name *( *SP ";" *SP parameter )
parameter = token "=" ( token / quoted-string ) parameter = token "=" ( token / quoted-string )
token = 1*tchar token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA / DIGIT / ALPHA
quoted-string = %x22 *( qdtext / quoted-pair ) %x22 quoted-string = %x22 *( qdtext / quoted-pair ) %x22
qdtext = SP / %x21 / %x23-5B / %x5D-7E qdtext = SP / %x21 / %x23-5B / %x5D-7E
quoted-pair = "\" ( SP / VCHAR ) quoted-pair = "\" ( SP / VCHAR )
; Adapted from section 8.4.1 of [RFC-httpbis-semantics] ; Adapted from Section 8.4.1 of RFC 9110
Content-Coding = token Content-Coding = token
; Adapted from various specs ; Adapted from various specs
Media-Type-Name = type-name "/" subtype-name Media-Type-Name = type-name "/" subtype-name
; RFC 6838 ; From RFC 6838
type-name = restricted-name type-name = restricted-name
subtype-name = restricted-name subtype-name = restricted-name
restricted-name = restricted-name-first *126restricted-name-chars restricted-name = restricted-name-first *126restricted-name-chars
restricted-name-first = ALPHA / DIGIT restricted-name-first = ALPHA / DIGIT
restricted-name-chars = ALPHA / DIGIT / "!" / "#" / restricted-name-chars = ALPHA / DIGIT / "!" / "#" /
"$" / "&" / "-" / "^" / "_" "$" / "&" / "-" / "^" / "_"
restricted-name-chars =/ "." ; Characters before first dot always restricted-name-chars =/ "." ; Characters before first dot always
; specify a facet name ; specify a facet name
restricted-name-chars =/ "+" ; Characters after last plus always restricted-name-chars =/ "+" ; Characters after last plus always
; specify a structured syntax suffix ; specify a structured syntax suffix
; Boilerplate from RFC 5234 and RFC 8866 ; Boilerplate from RFC 5234 and RFC 8866
DIGIT = %x30-39 ; 0 – 9 DIGIT = %x30-39 ; 0 - 9
POS-DIGIT = %x31-39 ; 1 – 9 POS-DIGIT = %x31-39 ; 1 - 9
ALPHA = %x41-5A / %x61-7A ; A – Z / a – z ALPHA = %x41-5A / %x61-7A ; A - Z / a - z
SP = %x20 SP = %x20
VCHAR = %x21-7E ; printable ASCII (no SP) VCHAR = %x21-7E ; printable ASCII (no SP)
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t><cref anchor="replace">RFC editor: Please replace [RFC-httpbis-semantic
s] by what gets
published from <xref target="I-D.ietf-httpbis-semantics" format="default
"/>.</cref></t>
</section> </section>
<section anchor="seccons" numbered="true" toc="default"> <section anchor="seccons" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The indication of a media type in the data does not exempt a consuming <t>The indication of a media type in the data does not exempt a consuming
application from properly checking its inputs. application from properly checking its inputs.
Also, the ability for an attacker to supply crafted SenML data that Also, the ability for an attacker to supply crafted SenML data that
specify media types chosen by the attacker may expose vulnerabilities specifies media types chosen by the attacker may expose vulnerabilities
of handlers for these media types to the attacker. of handlers for these media types to the attacker.
This includes "decompression bombs", compressed data that is crafted This includes "decompression bombs", compressed data that is crafted
to decompress to extremely large data items.</t> to decompress to extremely large data items.</t>
</section> </section>
<section anchor="iana" numbered="true" toc="default"> <section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>(Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with <t>IANA has assigned the following new labels in the "SenML Labels" subreg
the RFC number of this specification and remove this note.)</t> istry
<t>IANA is requested to assign new labels in the "SenML Labels" of the "Sensor Measurement Lists (SenML)" registry <xref target="IANA.senml" for
<xref section="subregistry" sectionFormat="bare" target="IANA.senml" relative="# mat="default"/> (as defined in <xref section="12.2" sectionFormat="of" target="R
senml-labels" format="default"/> FC8428" format="default"/>) for the
of the SenML registry <xref target="IANA.senml" format="default"/> (as defined i Content-Format indication, as per <xref target="tbl-senml-reg" format="default"/
n <xref section="12.2" sectionFormat="of" target="RFC8428" format="default"/>) f >:</t>
or the
Content-Format indication as per <xref target="tbl-senml-reg" format="default"/>
:</t>
<table anchor="tbl-senml-reg" align="center"> <table anchor="tbl-senml-reg" align="center">
<name>IANA Registration for new SenML Labels</name> <name>IANA Registration for New SenML Labels</name>
<thead> <thead>
<tr> <tr>
<th align="right">Name</th> <th align="right">Name</th>
<th align="left">Label</th> <th align="left">Label</th>
<th align="left">JSON Type</th> <th align="left">JSON Type</th>
<th align="left">XML Type</th> <th align="left">XML Type</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="right">Base Content-Format</td> <td align="right">Base Content-Format</td>
<td align="left">bct</td> <td align="left">bct</td>
<td align="left">String</td> <td align="left">String</td>
<td align="left">string</td> <td align="left">string</td>
<td align="left">RFC-AAAA</td> <td align="left">RFC 9193</td>
</tr> </tr>
<tr> <tr>
<td align="right">Content-Format</td> <td align="right">Content-Format</td>
<td align="left">ct</td> <td align="left">ct</td>
<td align="left">String</td> <td align="left">String</td>
<td align="left">string</td> <td align="left">string</td>
<td align="left">RFC-AAAA</td> <td align="left">RFC 9193</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Note that as per <xref section="12.2" sectionFormat="of" target="RFC842 8" format="default"/>, no CBOR labels or EXI <t>Note that, per <xref section="12.2" sectionFormat="of" target="RFC8428" format="default"/>, no CBOR labels nor Efficient XML Interchange (EXI)
schemaId values (EXI ID column) are supplied.</t> schemaId values (EXI ID column) are supplied.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2045" target="https://www.rfc-editor.org/info/rfc2
045"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2045.
<front> xml"/>
<title>Multipurpose Internet Mail Extensions (MIME) Part One: Format <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8428.
of Internet Message Bodies</title> xml"/>
<author fullname="N. Freed" initials="N." surname="Freed">
<organization/> <reference anchor="IANA.senml" target="https://www.iana.org/assignments/senml">
</author>
<author fullname="N. Borenstein" initials="N." surname="Borenstein">
<organization/>
</author>
<date month="November" year="1996"/>
<abstract>
<t>This initial document specifies the various headers used to des
cribe the structure of MIME messages. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2045"/>
<seriesInfo name="DOI" value="10.17487/RFC2045"/>
</reference>
<reference anchor="RFC8428" target="https://www.rfc-editor.org/info/rfc8
428">
<front>
<title>Sensor Measurement Lists (SenML)</title>
<author fullname="C. Jennings" initials="C." surname="Jennings">
<organization/>
</author>
<author fullname="Z. Shelby" initials="Z." surname="Shelby">
<organization/>
</author>
<author fullname="J. Arkko" initials="J." surname="Arkko">
<organization/>
</author>
<author fullname="A. Keranen" initials="A." surname="Keranen">
<organization/>
</author>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<date month="August" year="2018"/>
<abstract>
<t>This specification defines a format for representing simple sen
sor measurements and device parameters in Sensor Measurement Lists (SenML). Rep
resentations are defined in JavaScript Object Notation (JSON), Concise Binary Ob
ject Representation (CBOR), Extensible Markup Language (XML), and Efficient XML
Interchange (EXI), which share the common SenML data model. A simple sensor, su
ch as a temperature sensor, could use one of these media types in protocols such
as HTTP or the Constrained Application Protocol (CoAP) to transport the measure
ments of the sensor or to be configured.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8428"/>
<seriesInfo name="DOI" value="10.17487/RFC8428"/>
</reference>
<reference anchor="IANA.senml" target="https://www.iana.org/assignments/
senml">
<front> <front>
<title>Sensor Measurement Lists (SenML)</title> <title>Sensor Measurement Lists (SenML)</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/>
</front>
</reference>
<reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7
252">
<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 we
b transfer protocol for use with constrained nodes and constrained (e.g., low-po
wer, lossy) networks. The nodes often have 8-bit microcontrollers with small am
ounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wir
eless 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 appl
ication endpoints, supports built-in discovery of services and resources, and in
cludes key concepts of the Web such as URIs and Internet media types. CoAP is d
esigned to easily interface with HTTP for integration with the Web while meeting
specialized requirements such as multicast support, very low overhead, and simp
licity for constrained environments.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="7252"/>
<seriesInfo name="DOI" value="10.17487/RFC7252"/>
</reference> </reference>
<reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5
234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="C
rocker">
<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 A
ugmented BNF (ABNF), has been popular among many Internet specifications. The c
urrent specification documents ABNF. It balances compactness and simplicity with
reasonable representational power. The differences between standard BNF and AB
NF involve naming rules, repetition, alternatives, order-independence, and value
ranges. This specification also supplies additional rule definitions and encod
ing for a core lexical analyzer of the type common to several Internet specifica
tions. [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="I-D.ietf-httpbis-semantics" target="https://www.ietf.
org/archive/id/draft-ietf-httpbis-semantics-19.txt">
<front>
<title>HTTP Semantics</title>
<author fullname="Roy T. Fielding">
<organization>Adobe</organization>
</author>
<author fullname="Mark Nottingham">
<organization>Fastly</organization>
</author>
<author fullname="Julian Reschke">
<organization>greenbytes GmbH</organization>
</author>
<date day="12" month="September" year="2021"/>
<abstract>
<t> The Hypertext Transfer Protocol (HTTP) is a stateless applic
ation-
level protocol for distributed, collaborative, hypertext information
systems. This document describes the overall architecture of HTTP,
establishes common terminology, and defines aspects of the protocol
that are shared by all versions. In this definition are core
protocol elements, extensibility mechanisms, and the "http" and
"https" Uniform Resource Identifier (URI) schemes.
This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.
7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions xml"/>
of RFC 7230. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.
xml"/>
<reference anchor='RFC9110'>
<front>
<title>HTTP Semantics</title>
<author initials='R' surname='Fielding' fullname='Roy Fielding' role="editor">
<organization />
</author>
<author initials='M' surname='Nottingham' fullname='Mark Nottingham' role="edito
r">
<organization />
</author>
<author initials='J' surname='Reschke' fullname='Julian Reschke' role="editor">
<organization />
</author>
<date year='2022' month='June' />
</front>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="STD" value="97"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics-
19"/>
</reference>
<reference anchor="IANA.media-types" target="https://www.iana.org/assign ments/media-types"> <reference anchor="IANA.media-types" target="https://www.iana.org/assign ments/media-types">
<front> <front>
<title>Media Types</title> <title>Media Types</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/>
</front> </front>
</reference> </reference>
<reference anchor="IANA.core-parameters" target="https://www.iana.org/as signments/core-parameters"> <reference anchor="IANA.core-parameters" target="https://www.iana.org/as signments/core-parameters">
<front> <front>
<title>Constrained RESTful Environments (CoRE) Parameters</title> <title>Constrained RESTful Environments (CoRE) Parameters</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/>
</front> </front>
</reference> </reference>
<reference anchor="IANA.http-parameters" target="https://www.iana.org/as signments/http-parameters"> <reference anchor="IANA.http-parameters" target="https://www.iana.org/as signments/http-parameters">
<front> <front>
<title>Hypertext Transfer Protocol (HTTP) Parameters</title> <title>Hypertext Transfer Protocol (HTTP) Parameters</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/>
</front> </front>
</reference> </reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<front> xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
le> xml"/>
<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 sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. 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/rfc8
174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t 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>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4
648"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.
<front> xml"/>
<title>The Base16, Base32, and Base64 Data Encodings</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.
<author fullname="S. Josefsson" initials="S." surname="Josefsson"> xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.
</author> xml"/>
<date month="October" year="2006"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1590.
<abstract> xml"/>
<t>This document describes the commonly used base 64, base 32, and <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6690.
base 16 encoding schemes. It also discusses the use of line-feeds in encoded d xml"/>
ata, use of padding in encoded data, use of non-alphabet characters in encoded d <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4180.
ata, use of different encoding alphabets, and canonical encodings. [STANDARDS-T xml"/>
RACK]</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8866.
</abstract> xml"/>
</front>
<seriesInfo name="RFC" value="4648"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/>
</reference>
<reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8
949">
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author fullname="C. Bormann" initials="C." surname="Bormann">
<organization/>
</author>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization/>
</author>
<date month="December" year="2020"/>
<abstract>
<t>The Concise Binary Object Representation (CBOR) is a data forma
t whose design goals include the possibility of extremely small code size, fairl
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a
s ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improveme
nts, new details, and errata fixes while keeping full compatibility with the int
erchange format of RFC 7049. It does not create a new version of the format.</t
>
</abstract>
</front>
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference>
<reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6
838">
<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 regi
stration of media types for use in HTTP, MIME, and other Internet protocols. Th
is 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="RFC1590" target="https://www.rfc-editor.org/info/rfc1
590">
<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 a
dministrative 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 (conten
t-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="RFC6690" target="https://www.rfc-editor.org/info/rfc6
690">
<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, a
nd other relationships between links. Based on the HTTP Link Header field defin
ed in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carri
ed as a payload and is assigned an Internet media type. "RESTful" refers to the
Representational State Transfer (REST) architecture. A well-known URI is defin
ed as a default entry point for requesting the links hosted by a server. [STAND
ARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6690"/>
<seriesInfo name="DOI" value="10.17487/RFC6690"/>
</reference>
<reference anchor="RFC4180" target="https://www.rfc-editor.org/info/rfc4
180">
<front>
<title>Common Format and MIME Type for Comma-Separated Values (CSV)
Files</title>
<author fullname="Y. Shafranovich" initials="Y." surname="Shafranovi
ch">
<organization/>
</author>
<date month="October" year="2005"/>
<abstract>
<t>This RFC documents the format used for Comma-Separated Values (
CSV) files and registers the associated MIME type "text/csv". This memo provide
s information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4180"/>
<seriesInfo name="DOI" value="10.17487/RFC4180"/>
</reference>
<reference anchor="RFC8866" target="https://www.rfc-editor.org/info/rfc8
866">
<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 i
s intended for describing multimedia sessions for the purposes of session announ
cement, session invitation, and other forms of multimedia session initiation. Th
is document obsoletes RFC 4566.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8866"/>
<seriesInfo name="DOI" value="10.17487/RFC8866"/>
</reference>
</references> </references>
</references> </references>
<section numbered="false" anchor="acks" toc="default"> <section numbered="false" anchor="acks" toc="default">
<name>Acknowledgements</name> <name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Sérgio Abreu"/> for the discussions leading <t>The authors would like to thank <contact fullname="Sérgio Abreu"/> for the discussions leading
to the design of this extension and <contact fullname="Isaac Rivera"/> for revie ws and to the design of this extension and <contact fullname="Isaac Rivera"/> for revie ws and
feedback. feedback.
<contact fullname="Klaus Hartke"/> suggested not burdening this draft with a sep arate <contact fullname="Klaus Hartke"/> suggested not burdening this document with a separate
mandatory-to-implement version of the fields. mandatory-to-implement version of the fields.
<contact fullname="Alexey Melnikov"/>, <contact fullname="Jim Schaad"/>, and <co ntact fullname="Thomas Fossati"/> provided helpful <contact fullname="Alexey Melnikov"/>, <contact fullname="Jim Schaad"/>, and <co ntact fullname="Thomas Fossati"/> provided helpful
comments at Working-Group last call. comments at Working Group Last Call.
<contact fullname="Marco Tiloca"/> asked for clarifying and using the term Conte nt-Format-Spec.</t> <contact fullname="Marco Tiloca"/> asked for clarifying and using the term Conte nt-Format-Spec.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAJ+acWEAA51b63rbRnr+P1cxC3c3pEPQJHWwTEetaVmOlfhUS8nGm81u
QGJIogIBBgNIZmTl6T20F9Af+6e30dxJr6Tv980MTqS82ep5TJODmW++82kG
vu8LnQdJ+NcgThM1lnlWKBGtM/6m89Fg8GgwEmE6S4IVHodZMM/9SOVzf5Zm
ytcqWcV+GOSBP8v9OMiVzsWl2lynWTiWZ0muskTl/jNaJmZBPpY6D8UsTbBQ
F9rut47GQso8nY3lZxulPzM/0tU6mOWNoVCt8yVG9uzvKAlVUpuiN6tMzXVt
IM3y5gjArrCmNhIlcUSkl2vyLOJ9k9QusHiY37qYNofyKI+x/Fwlr17KZ2CF
/DaICyVPUpCf5P7zNFsFOZgRRuBAlCYimE4zddVYcvdkMBfQR4PRUARFvkyz
sfCBMwiY9OXXKvv1b4lKgJcR0CSL6oNpthjLU9CjdZoY2pQixJmyKN+M5Vdp
dhVoJjQkLgxG+6OBIbxI8gwznoNDUBEMqVUQxWMZZFH/UmUB9niiLPA+mCJ8
ZidQO+nLp0RJUmF2EmQaJNbGGblvkuhKZTrKf/1bLp9mCsKRF386q+H6NtX5
PJgt5d7eYH9/UCJuJpeIP/NHR3sHj+qIf6loqw2G1kvW7s/3H/n7o6E/Gh75
h3uPwNKSplkwTZ/kP0d9YCVEwmIAZqSY756fjAb7B2O5ilZqaAaO9kdHUGZS
fwycTV5P+vzDzn84OhgBZhqsze+D0d4++DZN5uKenbA3GMtlnq8H1cjQjBBA
/1mfrYx+TyMNQwMlOVhtpviJunb7rlQYBX6+WSs8rP1wz9lQ10EGKcAcNaHV
GHDzGG59XmtARMm8xZb9w31wYRpoZbnyaP8R4E/TzPw+PNo7sjgRSn6mwFvf
98EJSBcmJMTFUpEdwFDlKxXogoWay5eRzrXssIV0DQRJIGB+6zWMWstVEefR
OlbSEJvO5RWZne7JeZauZFKspkAaXkLm6kPOVp0stIQiQ3+nEbbPNnIaJfQf
OTC7vC/OEmhmqDJaCr2L4iiHCcp1ls6U1gAisdf2wp7Ml5GWcJUFUSD0Ws2i
eaSwpVwHUUarIDVr9HgQh1qCoTAYY+sAnC8VOUfyBNLwmlbB6LXauWPUV33a
VwG8c7aGWYKZFSWzuAgJciVGGWh5reKY/odxSLcfrMgwaL2OIxX2jaBWURjG
SggoKTbI0rCYkVeSN/ci+nn7DwtQy5sbEzZub2F0iZwqWWgVCnAbwyFoy6K0
0PISfNFEPlHch44mRKhUH4IVSX0BLUxAoLi5UR/84e1tD3zO1WoNv5QDCcMj
DCYlg4H29VIBSIapcTq7lJBXulYJzQpFUOOt7FxH+bIuK+ldhV5XZioIjYIB
8OvnJzwAgICkiewokYEgJYmVXY1IcdlnLjnUMddhb+d8df7mNSCtM0VAGNUe
YhcTTPvKDqEmGLWuxQdQVEKuL2RJshUe7hdZbFXdkJAWuVgHIYm226OJ4A8k
cK6MGA+IwU4cEPkvv/xinJr/bxQwvocZ33jTxBt7RZaMQwSt9Ho8HKjR4OFe
MBgOjgaDw72x1/NoCnEfXwt8PVExvl1544f94W2PodAMYjaNT73xPIi1qj1K
5jPf8JImhBgJvrxcnCy8W/EDoSVuxvIeSVpyvD32Ku5KllWRRJQMkMmFdWPx
rI5maqYo1DDjPsA4c8yD0l0m6bVc4h++R2RDkELOnGd1iJJSCsIwnhgdytSM
s/V8yHtS9RcwRQp1xmTtcp0W2Uyx14Eo/HTuT0nXaNNYhYtyMludUdK+fJFe
K2BqPYrdQq6CjUzSXAbxdbDRsBsBc4vijQyuEMGCKbnCVBILcvI6NX+VL+vK
CFzZNwUx1kZzQU+ZjREvWgeLgFiTEq9yRDxG/grmW3pct0dfXtRdJOUnKcWH
WcVIY3ZRTsBh5vMiJiRh8w5fa5y0S+nCRM3fY/MejJTAEMK9LX+VRYtl7sRk
qHynEOLIg5HcT9LJW9FKrzqVBQxH/T02AgrWt7ddYsEVNEkz86uYlyZuDxqg
FRCusfMi0dEiAcuI6oXKHpNhximzfiuzM3FJdhgYSRfa5AYPB7BQEap5RNAo
NlhifcOKSkceUIwlhOBM6SshbtEzxEvCPY4LCrM5oybZUY5g5nIC749QDA+t
MjwjDu1GE34FnjSmiaGw8G9uHFKGM3DyJ2+2AGhhNsg23S92ZSFw/oT61iA8
lAucsLSNuFNQffE6hdbkywDGFxiDZW3FlOssonDKkZG8IWIWRQQ2NbDcYQYb
jjeilDfx+2eVpYj+eKLaivaYjG9JMrWMsN5auIiP6K5CTjhmyyCBaUfGtMvt
2PEAZGgcD9Q5vRZa/VRAXRSHutaW1iGzK972ktK4ycXq9Wo6Onr/9YKGZjmG
DgdwejWfOWr6TKsh7DXrWUXNf0IMJ0/fvCPfeWYV1UWvOoxe5ehM2CQCAlQA
ZBwmCnnzNPVM1iWsmu+PyshF4ZJ3qhQZKpcFm748R/KiGiEfGfqVEvAimoc5
aFZZEuN1F0LOC1pyaUcTTUkoJnL6DqdOOzzScxiYCeI12KhpQY1ZLUNlhMaZ
AMJJIpi/TBuc2SJBFQPHCB0qnYkxSEu2lTX98Mlx5htxNJLV3z3Dl86oi5Ap
D/eqcQoOnT0epieHh88Pn2OYGU+DwyM5mti5zlV19gGnriGMhVOTU8vwWjEL
dO8ihZTk3j15epXGBVesYqJlLX3C0oVKkJbFLJ2MeZ6kNggbbpAZm3gK7c7J
AOfIx2ohngImPA2eLKGbiVqkecSOjTbqSkX1IbUVYImZMXQA5GgnrpcRHlL0
RNhBUNvAIlfkO4CYxhQT4OCFQFQRBxlFxYR9CUkcuK5UkOgKRYOVQ7SizmCW
SkRnl1cIl2/aVMGgx7SMkV8btK2/m9VqN5/zCE6L7aTSSTKyrSGjjvXpTUdC
SOKpe7g7Ipk57AUDanqQqbBsTIaC5eKPxAJrZ7UqgoijysbWNC5+kah7clEA
TewHo40MEyFY5GLROuJ8mRRt5ZJeeZ95c5/ydM4aSpdKVcI6DEzOJgr40Iz7
VgY1mxKbskjaYfeTeJGlccwBhR6sHrvgxNVZZljHyRN0+EpZmCwDVhBt/FQN
EGTcF5V6alfJ2KTLbBVUIocOwp4oe6tQ5/Qgjjn/2k4zVlyUNB7QHlbX4o3Z
DXhmV+xHBTvpWtKnC4ialbaRfZF850XGWunQo0BzT16obBUlaZwuNiZzulQb
SY08Lb1X35xfUHih/+XrN/z93em/fnP27vQZfT9/MXn5svwi7IzzF2++efms
+latPHnz6tXp62dmMUZlY0h4rybvPcMA783bi7M3rycvPelSpjLgkuiMbpT5
JscupFB6lkVTE2Cenrz9n/8a7sPd/o46OcPhI04+6MfR8OE+fpC2md0oI7A/
waGNQMqlArYN8BwCWCPRjTVrPzt5VnJw7/73xJkfxvKL6Ww93P9nO0AENwYd
zxqDzLPtka3Fhok7hnZsU3KzMd7idBPfyfvGb8f32qAQrzgxv4CLGouxnNSz
SFQgyqhXs5CF155ucuUaMJRgK7guk+ByvxDrTcbUq6cgbEC8n0/7+a/JHG9u
/gViGx48Gtya2vHGb3SXOI62FhlMWx7NVBfGz3JyQn3daqhGV5TU9jGdNZOn
mkq6vT8XKFdEhSlYiMIGUZyoXqfsXqhpQG48d/TqONBLkOBcdMXpFlH1mgjI
6HRWhUPZ6O1tpTPcxSREq72poUEddaDW5jgxh/sdHDpS9hsGVbWKZvAWCRIj
7s68uLh4y9Op52pnwh9RJ59Mhn0s+9Ef69T9CBPiDgq7cJDeDF2G+G2ZtEoR
G+c6jIMFj/9pEMi1SpFWX9OUItuD7VJEVn0TLYeH/cP+kMkdHvUPmbGuMUu8
rTX14LU5tTS4oB5LdOXTWV5lc7f0zNXGnCc6AR7197EpciNZ3434D5rnBdej
G9qchdGulcv4mFGYLxIrjjr/qXsecITznJBOLe7wx0vTl0CV0YDrmchOGU6G
yJ4TlYgl7AtMocRBqYzLNUG6nmur60lSNwBbRlvXHIbnCrYVKsl2+VR3J8AJ
WtsZdgEkoZhHTQr3NCtzlk/XuIbP9Sq3rVq/rcoFnK1OXKu8lZ1MzVWW2VJR
tzamUxVO27o9oh5VwVanwT9nh1tzJo1xx2JbpjV9tutK/V3+A49PSWDH5lDs
v7t1IJvq8FiqyLRttyRgqZFW1Toow6JVEHc/AXwLhmUlkH3HpsCxvUA+iVDP
2cU8WEVxhDyArZUdOPTbKDQwnak1NCGM9KzQxsmJqsfd5965SRXbXSiq1rvy
ORsekmtF1tgo0WvldK0WM8luhxvSvXrPByFcMM6m76+2u0+1VjhDIbdMbDLB
m/DpS4nczxbHrmNSdpy3lQzydOcQ1DRJ5yhs7vO8u5pKZGRWTKaXxlxF4RSD
+8ZJkk7B5tQHYm3pRwxO3gD+JtcqnncZV2BlHpSiJsEASLst54w74+YMSBv4
hwcHewcIhBHkG/CBD01gPpCN5tChaYHcpeYeKot92B+xMy5NlvA8Sd+dypdR
con1lmqTsxweUs7SpVxRcom1W49r/Yp/2NpkRysFfY3T665tfuoNwH3YliPb
FaUODcrofJI11vVN7xBg2TKjFqhpzVBROkcRy0UdqiNRb+2yxRANtc44ZGc6
PDpFbG8eXtmDIqLYnG214pit111BHNNaPpak2oCrrGWAMg5pESuA+ESD0xnA
JwNLKyfRgiyB7IxbeCqkw26oMNBZpiFXWlX/68q1T/gUAYplhYAq9lKpNamy
6Skxg6gio9hIxc0MNsDANHjF3qEJQpTegauWMFoAVs9We82CaLc9itLvXTSE
Rf00MuU7tKwsmNlum1raEyZNdOFjV/oR8Rlj2QbNl6rJfXsAVzvGbMibSJzT
yWW3186evSeeJJH3HL/NOW5qzjjadFxTK8qedsoOByQ+veE1gd7KvEQzx4OJ
gY1lc7JT2H7/LqKJIR5MjS7IeAS7MjvRyu76o1Yu2YVDpeYdtfkerGMI/DE1
mDOt8uMin/tHTyxgIc7m5EYdF8x5DntE26okGptHK3W2EpMSAtCigNpaU6WS
KintlamcZ3KofOO1bMR2HEL5v//+n9zss1lkO/+lxjL4l274xNkFyqd0KLIV
Laf1cEkuate05yas2YBGS3p1fwVeBUWcW7FQBVrXvzoM2amCYpd1PUrYWjl+
mDBZxRI6uadOsHOxJgDrenSuufYoh99Zk/Z3EF/YY5VH9V1h+mkf8h0LA0OS
C97GEDgFNOC4XU59DIMRt065EruOtMPZpeOYA+1I4yuunCo13LfljE1guiZ0
8CWPMn4gdyUZWsMLjcRzF4nLNKnioD3wsCRp4Xo5hoHsc2ZBlrEV04G3PWoF
c6xHD2I699g4ZiCN251NuTKSm+vgFeIydWpI9nSzoEwD3WmYQbY82swMfr2S
BlE/c3GPa4yzTK/J3qYphwPPmYnwoizS/nqJYtjB4PPVLDI2QZwomeYhM1qo
B2sqrCprFZ1glhdImThYxGqe04Ey5xx0mQwm2L3r/P43HByRh2HN4sMjzJji
6/Bw9HB/b/BwMLjjnL4CFL3/7uz919c0RAvrC2qkuwV9+itPqypyd6y+c7v0
/cuJXTAatO4IgJC7bgnQIxYTnVpwam4PO7RxKfOUQjoJxTp2E+8g06jsL7t8
lPWae5SVTWqBrBVeOrHHtPa2IQUTanol3FrWXU6SWUU6n8izaCOvferrdWnp
b1lZRQyv1RcSlOPWY4gBWt+K9Ad78CFbIzz7vlQ/FRF4Qd4e6u8dABk+Zb+j
sNoJ+0kZDnfswdjWAybf6mvEl200hsOBw+T/gceTQOnh6GgxW92JEXGtxMko
inGAXm1toNuJBm/LspjpKxbbahX452Xq8q3Rqs7J+bddWyzsD49QLDQwaEB5
bHo2xza8P1n8HK09hmBYZ1s6WXrt8lvPTNnByS5bweTp6+fCHHe58yjjKmux
0xQNJneJ6m2CssrYVe2XN+8MIrRRdQqKOtkUHT3Jx3RVTpsvM2WOlbIitoc6
gVNvCl08OqPjGL7Jw8/DYE03Fbhf6e6RgZ26bPBxRrWja1shYiVwdHR46A5l
fzEXNx/L18CmfQixs8Mhj9vl3WuD+IPdZd8WEDv9mA39gey8fXPuPzv78uxC
3uf/urubOvDix029vd+hdNANnTiJP5YnqLYpA0XewOz6HkRv3zb9oYepmMmh
jsuM87ek4lN4uEtzOEYz6ECVp8RqEcw28sifogwhD4OgxSk71XIVJHPlqCzg
NLWMQzpO3Rj9NeeirsE8bvbDmch2m/p+R94Hat5jj/+vgHdF9Z3/juEsLpHN
esewGPv9gfypSKE5vi3awCHzoPw7lsP7OREk+LP+wPsdici7x5//xJ+/588/
8Odn/HnfE7L5h8HP+ZHPn33+/At//pU/f+TPj/z5y47lRh8eyMnLty8mokkA
0Pr9h9GI2PJTyLfHShL5LmqXHwv7rKIFrHtAj4bmvz3/4Cl/O3jmPzwVdQiG
9D8TD3nRtycvJu8kq9bEmKHRK91qXd+laJWMjZJWktoC6SybHJXeOu6hZeU5
jvfAaxzsECzsL+lishDVvGPK6PjeP+jjiY3joO3HojWwPcWfR5nO5f3h6LD9
hENvG4KdD0AsUCfgrWm8eGsaKUmlh21lqf6sgv6hpnlO5+7Y6dgoJzxGac4o
B+fUGTAYh+WdxLu3pb/HNrJQjj+H48j5WOcTu37e2tUUsXGAPddxof/hTcub
YKGLWLqYz6MPgrTiaRrFKltTcDdaRmpC1/Y5stAPCglCGG4b9Ydh7A38vUeN
/QYoef9DPhKVyzYTh+2JQzvRyLGEuD/0DyZsdIdD/+EEEyc88U8YC/jbzwIW
V5os2elAGPOrRrD0tLHbGn4h50uXk/OTszPZQVF+/rZrAhwnzs0jD5/45rJo
DtpVL3FHxKN0+vu/ZAoMnKkf6t/HzDzYKNz7WL5FCNDcq6WH8s93eAPKqq6p
KFyovCnhdTGNI710vqAR2G0HYVZkKIcIS43MJbOn0Df34Iqov2bvA9da4Xzk
UGuM2O4RV1phqjQXoOqDWq3z8lIHRe1aLmmwoeuzii4QzZZqdumK4ihZF7nu
i0msU9OvD6Z0ZXZjLtsk1GhGgWLeOKD3GwgAvTEFIk39YhqEdHfGaXO9Tzqj
9wMSd7ZcAqMbT6hF6N2BqyKmayO8a2RellhCrWOyKlvNaNWAactaB8zehCrb
Gh5dd1tR+qmJ+Gm6mmqvJ90YEC9RpnaBpYaawtVCvnDzIaf3BUBwHGQLd+U6
VytzJYXO1LblGKG6ghA75gJoyvp1ulu/qOWQzqAQWXnH0iONm+DPFEXcbSEI
VWqZb2fB5AM4yVHmKRRC9WE8jCBfKf0JOXzuTuu4/Ua5KzdAdNn+NdJ8yYOe
uLlBkHEHiF9U7xDd3sIcMxVzS/vYu2cKegMKdmaTbgOrvFx6c1MHIDuNJmPz
nHHUbO9YBWj3U2r2UR5W5tPYvvLHWTMSs4+SY27r76OhEf9zJcVZ20f5HfC1
X9/R4SaJRH4EiF19vI9cqhOoMrXFd5feEAgrRskgWqstFgzht4EgD9ggj2oL
ffwZAo6MP3OOkOX9zvDc2j24V73W89IJqbqdvPOotyGCHjVI+XalVReAPP3u
TGh4kVVwVvYdOhiUZ88IsWKVdLkxwe6iel1nCmvlcm5WvmFg+g839+ia2i2R
aRRdhcdekrqXI8ybhVpe87lnHF0q4wEoy78B5r/+d7aIUjmBuha39qiLXaQ5
9GTDdMd31nXATZAVOHvim8/a2RJgnukgmMl39EpG4EBSI0tdm5OfuVLhlN+d
weSv4wAB/0WQ5ZeKJutisTD2Rq55WmShSspOGr+k6k4n3BGBKEsMP0/98tqh
5JcPq1LWNHF4z0kMl79BpREn0WV6dUuCwvBX0UqeI0kJQh6x1Fws0xUE/TzV
GnpBKNrCme5Bxut5EYuyFwSd+GOaUXjwv8xSFGCc0tC9C973VZDNUnkRxemM
GRPoS/c2AJwknL87AivKlzv4usWOqNwX/wcH7dvh4TsAAA==
</rfc> </rfc>
 End of changes. 62 change blocks. 
664 lines changed or deleted 189 lines changed or added

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