<?xmlversion="1.0" encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 --> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ ]> <?rfc compact="yes"?> <?rfc text-list-symbols="o*+-"?> <?rfc subcompact="no"?> <?rfc sortrefs="yes"?> <?rfc symrefs="yes"?> <?rfc strict="yes"?> <?rfc toc="yes"?>version='1.0' encoding='utf-8'?> <rfcipr="trust200902"xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-cbor-sequence-02"category="std">indexInclude="true" ipr="trust200902" number="8742" prepTime="2020-02-19T08:03:51" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-cbor-sequence-02" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc8742" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <title abbrev="CBOR Sequences">Concise Binary Object Representation (CBOR) Sequences</title> <seriesInfo name="RFC" value="8742" stream="IETF"/> <author initials="C." surname="Bormann" fullname="Carsten Bormann"><organization>Universität<organization ascii="Universitaet Bremen TZI" showOnFrontPage="true">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> <dateyear="2019" month="September" day="25"/> <abstract> <t>Thismonth="02" year="2020"/> <keyword>binary format</keyword> <keyword>data interchange format</keyword> <keyword>JSON</keyword> <abstract pn="section-abstract"> <t pn="section-abstract-1">This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type“application/cbor-seq”."application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence.</t><t>Structured<t pn="section-abstract-2">Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers“+cbor-seq”"+cbor-seq" as a structured syntax suffix for CBOR Sequences.</t> </abstract> <boilerplate> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t pn="section-boilerplate.1-1"> This is an Internet Standards Track document. </t> <t pn="section-boilerplate.1-2"> This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. </t> <t pn="section-boilerplate.1-3"> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <eref target="https://www.rfc-editor.org/info/rfc8742" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2"> <name slugifiedName="name-copyright-notice">Copyright Notice</name> <t pn="section-boilerplate.2-1"> Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. </t> <t pn="section-boilerplate.2-2"> This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. </t> </section> </boilerplate> <toc> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2"> <li pn="section-toc.1-1.1.2.1"> <t keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-used-in-this-do">Conventions Used in This Document</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.2"> <t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-cbor-sequence-format">CBOR Sequence Format</xref></t> </li> <li pn="section-toc.1-1.3"> <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-the-cbor-seq-structured-syn">The "+cbor-seq" Structured Syntax Suffix</xref></t> </li> <li pn="section-toc.1-1.4"> <t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-practical-considerations">Practical Considerations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2"> <li pn="section-toc.1-1.4.2.1"> <t keepWithNext="true" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-specifying-cbor-sequences-i">Specifying CBOR Sequences in Concise Data Definition Language (CDDL)</xref></t> </li> <li pn="section-toc.1-1.4.2.2"> <t keepWithNext="true" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-diagnostic-notation">Diagnostic Notation</xref></t> </li> <li pn="section-toc.1-1.4.2.3"> <t keepWithNext="true" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-optimizing-cbor-sequences-f">Optimizing CBOR Sequences for Skipping Elements</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.5"> <t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t> </li> <li pn="section-toc.1-1.6"> <t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2"> <li pn="section-toc.1-1.6.2.1"> <t keepWithNext="true" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-media-type">Media Type</xref></t> </li> <li pn="section-toc.1-1.6.2.2"> <t keepWithNext="true" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-coap-content-format-registr">CoAP Content-Format Registration</xref></t> </li> <li pn="section-toc.1-1.6.2.3"> <t keepWithNext="true" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-structured-syntax-suffix">Structured Syntax Suffix</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.7"> <t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2"> <li pn="section-toc.1-1.7.2.1"> <t keepWithNext="true" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t> </li> <li pn="section-toc.1-1.7.2.2"> <t keepWithNext="true" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.8"> <t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t> </li> <li pn="section-toc.1-1.9"> <t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t> </li> </ul> </section> </toc> </front> <middle> <section anchor="introduction"title="Introduction"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t pn="section-1-1">The Concise Binary Object Representation (CBOR) <xreftarget="RFC7049"/>target="RFC7049" format="default" sectionFormat="of" derivedContent="RFC7049"/> can be used for serialization of data in the JSON <xreftarget="RFC8259"/>target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259"/> data model or in its own, somewhatexpandedexpanded, data model. When serializing a sequence of such values, it is sometimes convenient to have a format where these sequences can simply be concatenated to obtain a serialization of the concatenated sequence ofvalues,values or to encode a sequence of values that might grow at the end by just appending further CBOR data items.</t><t>This<t pn="section-1-2">This document describes the concept and format of“CBOR Sequences”,"CBOR Sequences", which are composed of zero or more encoded CBOR data items. CBOR Sequences can be consumed (and produced) incrementally without requiring a streaming CBOR parser that is able to deliver substructures of a data item incrementally (or a streaming encoder able to encode from substructures incrementally).</t><t>This<t pn="section-1-3">This document defines and registers the“application/cbor-seq”"application/cbor-seq" media type in themedia type registry,"Media Types" registry along with aCoAPConstrained Application Protocol (CoAP) Content-Format identifier. Media type structured syntax suffixes <xreftarget="RFC6838"/>target="RFC6838" format="default" sectionFormat="of" derivedContent="RFC6838"/> were introduced as a way for a media type to signal that it is based on another media type as its foundation. CBOR <xreftarget="RFC7049"/>target="RFC7049" format="default" sectionFormat="of" derivedContent="RFC7049"/> defines the“+cbor”"+cbor" structured syntax suffix. This document defines and registers the“+cbor-seq”"+cbor-seq" structured syntax suffix in the“Structured"Structured Syntax SuffixRegistry”.</t>Registry".</t> <section anchor="conventions-used-in-this-document"title="Conventionsnumbered="true" toc="include" removeInRFC="false" pn="section-1.1"> <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in ThisDocument"> <t>TheDocument</name> <t pn="section-1.1-1"> The key words“MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”,"<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and“OPTIONAL”"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xreftarget="RFC2119"/> <xref target="RFC8174"/>target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <t>Inhere. </t> <t pn="section-1.1-2">In this specification, the term“byte”"byte" is used in its now-customary sense as a synonym for“octet”.</t>"octet".</t> </section> </section> <section anchor="cbor-sequence-format"title="CBORnumbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-cbor-sequence-format">CBOR SequenceFormat"> <t>Formally,Format</name> <t pn="section-2-1">Formally, a CBOR Sequence is a sequence of bytes that is recursively defined aseither</t> <t><list style="symbols"> <t>aneither of the following:</t> <ul spacing="normal" bare="false" empty="false" pn="section-2-2"> <li pn="section-2-2.1">an empty (zero-length) sequence ofbytes</t> <t>thebytes</li> <li pn="section-2-2.2">the sequence of bytes making up an encoded CBOR data item <xreftarget="RFC7049"/>,target="RFC7049" format="default" sectionFormat="of" derivedContent="RFC7049"/> followed by a CBORSequence.</t> </list></t> <t>InSequence.</li> </ul> <t pn="section-2-3">In short, concatenating zero or more encoded CBOR data items generates a CBOR Sequence. (Consequently, concatenating zero or more CBOR Sequences also results in a CBOR Sequence.)</t><t>There<t pn="section-2-4">There is noend of sequenceend-of-sequence indicator. (If one is desired,CBOR-encodingCBOR encoding an array of the CBOR data model values beingencoded —encoded, employing either a definite or an indefinite lengthencoding —encoding, as a single CBOR data item may actually be the more appropriate representation.)</t><t>CBOR<t pn="section-2-5">CBOR Sequences, unlike JSON Text Sequences <xreftarget="RFC7464"/>,target="RFC7464" format="default" sectionFormat="of" derivedContent="RFC7464"/>, do not use a marker between items. This is possible becauseCBOR encodedCBOR-encoded data items areself-delimitingself delimiting and the end can always be calculated. (Note that, while the early object/array-only form of JSON wasself-delimitingself delimiting as well, this stopped being the case when simple values such as single numbers were made valid JSON documents.)</t><t>Decoding<t pn="section-2-6">Decoding a CBOR Sequence works as follows:</t><t><list style="symbols"> <t>If<ul spacing="normal" bare="false" empty="false" pn="section-2-7"> <li pn="section-2-7.1">If the CBOR Sequence is an empty sequence of bytes, the result is an empty sequence of CBOR data modelvalues.</t> <t>Otherwise,values.</li> <li pn="section-2-7.2">Otherwise, one must decode a single CBOR data item from the bytes of the CBORsequence,Sequence and insert the resulting CBOR data model value at the start of the result of repeating this decoding process recursively with the remaining bytes. (A streaming decoder would therefore simply deliver zero or more CBOR data model values, each as soon as the bytes making it up areavailable.)</t> </list></t> <t>Thisavailable.)</li> </ul> <t pn="section-2-8">This means that if any data item in the sequence is notwell-formed,well formed, it is not possible to reliably decode the rest of the sequence. (An implementation may be able to recover from some errors in a sequence of bytes that is almost, but notentirelyentirely, a well-formed encoded CBOR data item. Handling malformed data is outside the scope of this specification.)</t><t>This<t pn="section-2-9">This also means that the CBOR Sequence format can reliably detect truncation of the bytes making up the last CBOR data item in the sequence, butnotit cannot detect entirely missing CBOR data items at the end. A CBOR Sequence decoder that is used for consuming streaming CBOR Sequence data may simply pause for more data (e.g., by suspending and later resuming decoding) in case a truncated final item is being received.</t> </section> <section anchor="the-cbor-seq-structured-syntax-suffix"title="The “+cbor-seq”numbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-the-cbor-seq-structured-syn">The "+cbor-seq" Structured SyntaxSuffix"> <t>TheSuffix</name> <t pn="section-3-1">The use case for the“+cbor-seq”"+cbor-seq" structured syntax suffix is analogous to that for“+cbor”: It SHOULD"+cbor": it <bcp14>SHOULD</bcp14> be used by a media type when the result of parsing the bytes of the media type object as a CBOR Sequenceleads to ais meaningfulresult thatand is at least sometimes not just a single CBOR data item. (Without the qualification at the end, this sentence is trivially true for any +cbor media type, which of course should continue to use the“+cbor”"+cbor" structured syntax suffix.)</t><t>Applications<t pn="section-3-2">Applications encountering a“+cbor-seq”"+cbor-seq" media type can then either simply use generic processing if all they need is a generic view of the CBORSequence,Sequence orthey canuse generic CBOR Sequence tools for initial parsing and then implement their own specific processing on top of that generic parsing tool.</t> </section> <section anchor="practical-considerations"title="Practical Considerations">numbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-practical-considerations">Practical Considerations</name> <section anchor="specifying-cbor-sequences-in-cddl"title="Specifyingnumbered="true" toc="include" removeInRFC="false" pn="section-4.1"> <name slugifiedName="name-specifying-cbor-sequences-i">Specifying CBOR Sequences inCDDL"> <t>In CDDLConcise Data Definition Language (CDDL)</name> <t pn="section-4.1-1">In Concise Data Definition Language (CDDL) <xreftarget="RFC8610"/>,target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/>, CBORsequencesSequences are already supported as contents of byte strings using the<spanx style="verb">.cborseq</spanx><tt>.cborseq</tt> control operator(Section 3.8.4 of <xref target="RFC8610"/>),(<xref target="RFC8610" sectionFormat="of" section="3.8.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8610#section-3.8.4" derivedContent="RFC8610"/>) by employing an array as the controller type:</t><figure><artwork type="CDDL"><![CDATA[ my-embedded-cbor-seq<sourcecode type="cddl" markers="false" pn="section-4.1-2">my-embedded-cbor-seq = bytes .cborseq my-array my-array = [* my-element] my-element = my-foo / my-bar]]></artwork></figure> <t>CDDL currently</sourcecode> <t pn="section-4.1-3">Currently, CDDL does not provide for unadorned CBORsequencesSequences as a top-level subject of a specification. For now, the suggestion is to use anarray, asarray for the<spanx style="verb">.cborseq</spanx> control operator,top-level rule, as is used for thetop-level rule<tt>.cborseq</tt> control operator, and add English text that explains that the specification is really about a CBORsequenceSequence with the elements of the array:</t><figure><artwork type="CDDL"><![CDATA[ ;<sourcecode type="cddl" markers="false" pn="section-4.1-4">; This defines an array, the elements of which are to be used ; in a CBORsequence:Sequence: my-sequence = [* my-element] my-element = my-foo / my-bar]]></artwork></figure> <t>(Future</sourcecode> <t pn="section-4.1-5">(Future versions of CDDL may provide a notation for top-level CBORsequences, e.g.Sequences, e.g., by using a group as the top-level rule in a CDDL specification.)</t> </section> <section anchor="diagnostic-notation"title="Diagnostic Notation"> <t>CBORnumbered="true" toc="include" removeInRFC="false" pn="section-4.2"> <name slugifiedName="name-diagnostic-notation">Diagnostic Notation</name> <t pn="section-4.2-1">CBOR diagnostic notation (seeSection 6 of<xreftarget="RFC7049"/>)target="RFC7049" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7049#section-6" derivedContent="RFC7049"/>) or extended diagnostic notation(Appendix G of <xref target="RFC8610"/>)(<xref target="RFC8610" sectionFormat="of" section="G" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8610#appendix-G" derivedContent="RFC8610"/>) also does not provide for unadorned CBOR Sequences at this time (the latter does provide for CBOR Sequences embedded in a byte stringin Appendix G.3 ofas per <xreftarget="RFC8610"/>).</t> <t>Intarget="RFC8610" sectionFormat="of" section="G.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8610#appendix-G.3" derivedContent="RFC8610"/>).</t> <t pn="section-4.2-2">In a similar spirit to the recommendation for CDDL above, this specification recommends enclosing the CBOR data items in an array. In a more informal setting, where the boundaries within which the notation is used are obvious, it is also possible to leave off the outer brackets for this array, as shown in these two examples:</t><figure><artwork type="CBORdiag"><![CDATA[<artwork type="CBORdiag" name="" align="left" alt="" pn="section-4.2-3"> [1, 2, 3] 1, 2, 3]]></artwork></figure> <t>Note</artwork> <t pn="section-4.2-4">Note that it is somewhat difficult to discuss zero-length CBOR Sequences in the latter form.</t> </section> <section anchor="optimizing-cbor-sequences-for-skipping-elements"title="Optimizingnumbered="true" toc="include" removeInRFC="false" pn="section-4.3"> <name slugifiedName="name-optimizing-cbor-sequences-f">Optimizing CBOR Sequences for SkippingElements"> <t>InElements</name> <t pn="section-4.3-1">In certain applications, being able to efficiently skip an element without the need for decoding its substructure, or efficiently fanning out elements to multi-threaded decoding processes, is of the utmost importance. For these applications, byte strings (which carry length information in bytes) containing embedded CBOR can be used as the elements of a CBORsequence:</t> <figure><artwork type="CDDL"><![CDATA[ ;Sequence:</t> <sourcecode type="cddl" markers="false" pn="section-4.3-2">; This defines an array of CBOR byte strings, the elements of which ; are to be used in a CBORsequence:Sequence: my-sequence = [* my-element] my-element = bytes .cbor my-element-structure my-element-structure = my-foo / my-bar]]></artwork></figure> <t>Within</sourcecode> <t pn="section-4.3-3">Within limits, this may also enable recovering from elements that internally are notwell-formed —well formed; the limitation is that the sequence of byte strings does need to bewell-formedwell formed as such.</t> </section> </section> <section anchor="security-considerations"title="Security Considerations"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t pn="section-5-1">The security considerations of CBOR <xreftarget="RFC7049"/>target="RFC7049" format="default" sectionFormat="of" derivedContent="RFC7049"/> apply. This format provides no cryptographic integrity protection of anykind,kind but can be combined with security specifications such asCOSECBOR Object Signing and Encryption (COSE) <xreftarget="RFC8152"/>target="RFC8152" format="default" sectionFormat="of" derivedContent="RFC8152"/> to do so. (COSE protections can be applied to an entire CBORsequenceSequence or to each of the elements of the sequence independently; in the latter case, additional effort may be required if there is a need to protect the relationship of the elements in the sequence.)</t><t>As<t pn="section-5-2">As usual, decoders must operate on input that is assumed to be untrusted. This means that decodersMUST<bcp14>MUST</bcp14> fail gracefully in the face of malicious inputs.</t> </section> <section anchor="iana-considerations"title="IANA Considerations">numbered="true" toc="include" removeInRFC="false" pn="section-6"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <section anchor="media-type"title="Media Type"> <t>Medianumbered="true" toc="include" removeInRFC="false" pn="section-6.1"> <name slugifiedName="name-media-type">Media Type</name> <t pn="section-6.1-1">Media types are registered in themedia types"Media Types" registry <xreftarget="IANA.media-types"/>.target="IANA-MEDIA-TYPES" format="default" sectionFormat="of" derivedContent="IANA-MEDIA-TYPES"/>. IANAis requested to registerhas registered theMIMEmedia type for CBOR Sequence, application/cbor-seq, as follows:</t><t>Type<t pn="section-6.1-2">Type name: application</t><t>Subtype<t pn="section-6.1-3">Subtype name: cbor-seq</t><t>Required<t pn="section-6.1-4">Required parameters: N/A</t><t>Optional<t pn="section-6.1-5">Optional parameters: N/A</t><t>Encoding<t pn="section-6.1-6">Encoding considerations: binary</t><t>Security<t pn="section-6.1-7">Security considerations: SeeRFCthis,RFC 8742, <xreftarget="security-considerations"/>.</t> <t>Interoperabilitytarget="security-considerations" format="default" sectionFormat="of" derivedContent="Section 5"/>.</t> <t pn="section-6.1-8">Interoperability considerations: Described herein.</t><t>Published<t pn="section-6.1-9">Published specification:RFCthis.</t> <t>ApplicationsRFC 8742.</t> <t pn="section-6.1-10">Applications that use this media type: Data serialization and deserialization.</t><t>Fragment<t pn="section-6.1-11">Fragment identifier considerations: N/A</t><t>Additional<t pn="section-6.1-12">Additional information:</t><t><list style="symbols"> <t>Deprecated<ul spacing="normal" bare="false" empty="false" pn="section-6.1-13"> <li pn="section-6.1-13.1">Deprecated alias names for this type:N/A</t> <t>MagicN/A</li> <li pn="section-6.1-13.2">Magic number(s):N/A</t> <t>FileN/A</li> <li pn="section-6.1-13.3">File extension(s):N/A</t> <t>MacintoshN/A</li> <li pn="section-6.1-13.4">Macintosh file type code(s):N/A</t> </list></t> <t><list style="hanging"> <t hangText='PersonN/A</li> </ul> <dl newline="false" spacing="normal" pn="section-6.1-14"> <dt pn="section-6.1-14.1">Person & email address to contact for furtherinformation:'> cbor@ietf.org</t> </list></t> <t>Intendedinformation:</dt> <dd pn="section-6.1-14.2"> cbor@ietf.org</dd> </dl> <t pn="section-6.1-15">Intended usage: COMMON</t><t>Author:<t pn="section-6.1-16">Author: Carsten Bormann (cabo@tzi.org)</t><t>Change<t pn="section-6.1-17">Change controller: IETF</t> </section> <section anchor="coap-content-format-registration"title="CoAPnumbered="true" toc="include" removeInRFC="false" pn="section-6.2"> <name slugifiedName="name-coap-content-format-registr">CoAP Content-FormatRegistration"> <t>IANA is requested to assignRegistration</name> <t pn="section-6.2-1">IANA has assigned a CoAP Content-Format ID for the media type“application/cbor-seq”, in"application/cbor-seq", within theCoAP Content-Formats"CoAP Content-Formats" subregistry of thecore-parameter"Constrained RESTful Environments (CoRE) Parameters" registry <xreftarget="IANA.core-parameters"/>,target="IANA-CORE-PARAMETERS" format="default" sectionFormat="of" derivedContent="IANA-CORE-PARAMETERS"/>, from the“Expert Review”"Expert Review" (0-255)range.range (<xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>). The assigned ID is shown in <xreftarget="tbl-coap-content-formats"/>.</t> <texttable title="CoAPtarget="tbl-coap-content-formats" format="default" sectionFormat="of" derivedContent="Table 1"/>.</t> <table anchor="tbl-coap-content-formats" align="center" pn="table-1"> <name slugifiedName="name-coap-content-format-id">CoAP Content-FormatID" anchor="tbl-coap-content-formats"> <ttcol align='left'>Media type</ttcol> <ttcol align='left'>Encoding</ttcol> <ttcol align='left'>ID</ttcol> <ttcol align='left'>Reference</ttcol> <c>application/cbor-seq</c> <c>-</c> <c>TBD63</c> <c>RFCthis</c> </texttable> <t>RFC editor: Please replace TBD63 by the number actually assigned and delete this paragraph.</t>ID</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Media type</th> <th align="left" colspan="1" rowspan="1">Encoding</th> <th align="left" colspan="1" rowspan="1">ID</th> <th align="left" colspan="1" rowspan="1">Reference</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">application/cbor-seq</td> <td align="left" colspan="1" rowspan="1">-</td> <td align="left" colspan="1" rowspan="1">63</td> <td align="left" colspan="1" rowspan="1">RFC 8742</td> </tr> </tbody> </table> </section> <section anchor="structured-syntax-suffix"title="Structurednumbered="true" toc="include" removeInRFC="false" pn="section-6.3"> <name slugifiedName="name-structured-syntax-suffix">Structured SyntaxSuffix"> <t>StructuredSuffix</name> <t pn="section-6.3-1">Structured Syntax Suffixes are registered within the“Structured"Structured Syntax SuffixRegistry”Registry" maintained at <xreftarget="IANA.media-type-structured-suffix"/>.target="IANA-STRUCTURED-SYNTAX-SUFFIX" format="default" sectionFormat="of" derivedContent="IANA-STRUCTURED-SYNTAX-SUFFIX"/>. IANAis requested to registerhas registered the“+cbor-seq”"+cbor-seq" structured syntax suffix in accordance with <xreftarget="RFC6838"/>,target="RFC6838" format="default" sectionFormat="of" derivedContent="RFC6838"/> as follows:</t><t><list style='empty'> <t>Name: CBOR Sequence</t> </list></t> <t><list style='empty'> <t>+suffix: +cbor-seq</t> </list></t> <t><list style='empty'> <t>References: RFCthis</t> </list></t> <t><list style='empty'> <t>Encoding<ul empty="true" spacing="normal" bare="false" pn="section-6.3-2"> <li pn="section-6.3-2.1">Name: CBOR Sequence</li> </ul> <ul empty="true" spacing="normal" bare="false" pn="section-6.3-3"> <li pn="section-6.3-3.1">+suffix: +cbor-seq</li> </ul> <ul empty="true" spacing="normal" bare="false" pn="section-6.3-4"> <li pn="section-6.3-4.1">References: RFC 8742</li> </ul> <ul empty="true" spacing="normal" bare="false" pn="section-6.3-5"> <li pn="section-6.3-5.1">Encoding considerations:binary</t> </list></t> <t><list style='empty'> <t>Fragmentbinary</li> </ul> <ul empty="true" spacing="normal" bare="false" pn="section-6.3-6"> <li pn="section-6.3-6.1">Fragment identifier considerations: The syntax and semantics of fragment identifiers specified for +cbor-seqSHOULD<bcp14>SHOULD</bcp14> be the same as that specified for“application/cbor-seq”."application/cbor-seq". (At the time of publication of this document, there is no fragment identification syntax defined for“application/cbor-seq”.)</t> </list></t> <t><list style='empty'> <t><list style='empty'> <t>The"application/cbor-seq".)</li> </ul> <ul empty="true" spacing="normal" bare="false" pn="section-6.3-7"> <li pn="section-6.3-7.1"> <ul empty="true" spacing="normal" bare="false" pn="section-6.3-7.1.1"> <li pn="section-6.3-7.1.1.1">The syntax and semantics for fragment identifiers for a specific“xxx/yyy+cbor-seq” SHOULD"xxx/yyy+cbor-seq" <bcp14>SHOULD</bcp14> be processed asfollows:</t> </list></t> </list></t> <t><list style='empty'> <t><list style='empty'> <t><list style='empty'> <t>Forfollows:</li> <li pn="section-6.3-7.1.1.2"> <ul spacing="normal" bare="false" empty="false" pn="section-6.3-7.1.1.2.1"> <li pn="section-6.3-7.1.1.2.1.1">For cases defined in +cbor-seq,whereif the fragment identifier resolves per the +cbor-seq rules, then process as specified in+cbor-seq.</t> </list></t> </list></t> </list></t> <t><list style='empty'> <t><list style='empty'> <t><list style='empty'> <t>For+cbor-seq.</li> <li pn="section-6.3-7.1.1.2.1.2">For cases defined in +cbor-seq,whereif the fragment identifier does not resolve per the +cbor-seq rules, then process as specified in“xxx/yyy+cbor-seq”.</t> </list></t> </list></t> </list></t> <t><list style='empty'> <t><list style='empty'> <t><list style='empty'> <t>For"xxx/yyy+cbor-seq".</li> <li pn="section-6.3-7.1.1.2.1.3">For cases not defined in +cbor-seq,thenprocess as specified in“xxx/yyy+cbor-seq”.</t> </list></t> </list></t> </list></t> <t><list style='empty'> <t>Interoperability"xxx/yyy+cbor-seq".</li> </ul> </li> </ul> </li> </ul> <ul empty="true" spacing="normal" bare="false" pn="section-6.3-8"> <li pn="section-6.3-8.1">Interoperability considerations:n/a</t> </list></t> <t><list style='empty'> <t>Securityn/a</li> </ul> <ul empty="true" spacing="normal" bare="false" pn="section-6.3-9"> <li pn="section-6.3-9.1">Security considerations: SeeRFCthis,RFC 8742, <xreftarget="security-considerations"/></t> </list></t> <t><list style='empty'> <t>Contact:target="security-considerations" format="default" sectionFormat="of" derivedContent="Section 5"/></li> </ul> <ul empty="true" spacing="normal" bare="false" pn="section-6.3-10"> <li pn="section-6.3-10.1">Contact: CBOR WG mailing list (cbor@ietf.org), or any IESG-designatedsuccessor.</t> </list></t> <t><list style='empty'> <t>Author/Changesuccessor.</li> </ul> <ul empty="true" spacing="normal" bare="false" pn="section-6.3-11"> <li pn="section-6.3-11.1">Author/Change controller:IETF</t> </list></t>IETF</li> </ul> </section> </section> </middle> <back> <referencestitle='Normative References'> <reference anchor="RFC7049" target='https://www.rfc-editor.org/info/rfc7049'> <front> <title>Concise Binary Object Representation (CBOR)</title> <author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author> <author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author> <date year='2013' month='October' /> <abstract><t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t></abstract> </front> <seriesInfo name='RFC' value='7049'/> <seriesInfo name='DOI' value='10.17487/RFC7049'/> </reference> <reference anchor="IANA.media-type-structured-suffix" target='http://www.iana.org/assignments/media-type-structured-suffix'> <front> <title>Structured Syntax Suffix Registry</title> <author><organization>IANA</organization></author> <date/> </front> </reference>pn="section-7"> <name slugifiedName="name-references">References</name> <references pn="section-7.1"> <name slugifiedName="name-normative-references">Normative References</name> <referenceanchor="IANA.core-parameters" target='http://www.iana.org/assignments/core-parameters'>anchor="IANA-CORE-PARAMETERS" target="https://www.iana.org/assignments/core-parameters" quoteTitle="true" derivedAnchor="IANA-CORE-PARAMETERS"> <front> <title>Constrained RESTful Environments (CoRE) Parameters</title><author><organization>IANA</organization></author> <date/><author> <organization showOnFrontPage="true">IANA</organization> </author> </front> </reference> <referenceanchor="IANA.media-types" target='http://www.iana.org/assignments/media-types'>anchor="IANA-MEDIA-TYPES" target="https://www.iana.org/assignments/media-types" quoteTitle="true" derivedAnchor="IANA-MEDIA-TYPES"> <front> <title>Media Types</title><author><organization>IANA</organization></author> <date/><author> <organization showOnFrontPage="true">IANA</organization> </author> </front> </reference> <reference anchor="IANA-STRUCTURED-SYNTAX-SUFFIX" target="https://www.iana.org/assignments/media-type-structured-suffix" quoteTitle="true" derivedAnchor="IANA-STRUCTURED-SYNTAX-SUFFIX"> <front> <title>Structured Syntax Suffix Registry</title> <author> <organization showOnFrontPage="true">IANA</organization> </author> </front> </reference> <reference anchor="RFC2119"target='https://www.rfc-editor.org/info/rfc2119'>target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <authorinitials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <dateyear='1997' month='March' /> <abstract><t>Inyear="1997" month="March"/> <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 forimprovements.</t></abstract>improvements.</t> </abstract> </front> <seriesInfoname='BCP' value='14'/>name="BCP" value="14"/> <seriesInfoname='RFC' value='2119'/>name="RFC" value="2119"/> <seriesInfoname='DOI' value='10.17487/RFC2119'/>name="DOI" value="10.17487/RFC2119"/> </reference> <referenceanchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>anchor="RFC7049" target="https://www.rfc-editor.org/info/rfc7049" quoteTitle="true" derivedAnchor="RFC7049"> <front><title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title><title>Concise Binary Object Representation (CBOR)</title> <authorinitials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>initials="C." surname="Bormann" fullname="C. Bormann"> <organization showOnFrontPage="true"/> </author> <author initials="P." surname="Hoffman" fullname="P. Hoffman"> <organization showOnFrontPage="true"/> </author> <dateyear='2017' month='May' /> <abstract><t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduceyear="2013" month="October"/> <abstract> <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include theambiguity bypossibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t> </abstract> </front> <seriesInfo name="RFC" value="7049"/> <seriesInfo name="DOI" value="10.17487/RFC7049"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author initials="B." surname="Leiba" fullname="B. Leiba"> <organization showOnFrontPage="true"/> </author> <date year="2017" month="May"/> <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 specialmeanings.</t></abstract>meanings.</t> </abstract> </front> <seriesInfoname='BCP' value='14'/>name="BCP" value="14"/> <seriesInfoname='RFC' value='8174'/>name="RFC" value="8174"/> <seriesInfoname='DOI' value='10.17487/RFC8174'/>name="DOI" value="10.17487/RFC8174"/> </reference> </references> <referencestitle='Informative References'>pn="section-7.2"> <name slugifiedName="name-informative-references">Informative References</name> <reference anchor="RFC6838"target='https://www.rfc-editor.org/info/rfc6838'>target="https://www.rfc-editor.org/info/rfc6838" quoteTitle="true" derivedAnchor="RFC6838"> <front> <title>Media Type Specifications and Registration Procedures</title> <authorinitials='N.' surname='Freed' fullname='N. Freed'><organization /></author>initials="N." surname="Freed" fullname="N. Freed"> <organization showOnFrontPage="true"/> </author> <authorinitials='J.' surname='Klensin' fullname='J. Klensin'><organization /></author>initials="J." surname="Klensin" fullname="J. Klensin"> <organization showOnFrontPage="true"/> </author> <authorinitials='T.' surname='Hansen' fullname='T. Hansen'><organization /></author>initials="T." surname="Hansen" fullname="T. Hansen"> <organization showOnFrontPage="true"/> </author> <dateyear='2013' month='January' /> <abstract><t>Thisyear="2013" month="January"/> <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 CurrentPractice.</t></abstract>Practice.</t> </abstract> </front> <seriesInfoname='BCP' value='13'/>name="BCP" value="13"/> <seriesInfoname='RFC' value='6838'/>name="RFC" value="6838"/> <seriesInfoname='DOI' value='10.17487/RFC6838'/>name="DOI" value="10.17487/RFC6838"/> </reference> <reference anchor="RFC7464"target='https://www.rfc-editor.org/info/rfc7464'>target="https://www.rfc-editor.org/info/rfc7464" quoteTitle="true" derivedAnchor="RFC7464"> <front> <title>JavaScript Object Notation (JSON) Text Sequences</title> <authorinitials='N.' surname='Williams' fullname='N. Williams'><organization /></author>initials="N." surname="Williams" fullname="N. Williams"> <organization showOnFrontPage="true"/> </author> <dateyear='2015' month='February' /> <abstract><t>Thisyear="2015" month="February"/> <abstract> <t>This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type"application/json-seq"."application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character(0x0A).</t></abstract> </front> <seriesInfo name='RFC' value='7464'/> <seriesInfo name='DOI' value='10.17487/RFC7464'/> </reference> <reference anchor="RFC8259" target='https://www.rfc-editor.org/info/rfc8259'> <front> <title>The JavaScript Object Notation (JSON) Data Interchange Format</title> <author initials='T.' surname='Bray' fullname='T. Bray' role='editor'><organization /></author> <date year='2017' month='December' /> <abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t><t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract>(0x0A).</t> </abstract> </front> <seriesInfoname='STD' value='90'/> <seriesInfo name='RFC' value='8259'/>name="RFC" value="7464"/> <seriesInfoname='DOI' value='10.17487/RFC8259'/>name="DOI" value="10.17487/RFC7464"/> </reference> <reference anchor="RFC8091"target='https://www.rfc-editor.org/info/rfc8091'>target="https://www.rfc-editor.org/info/rfc8091" quoteTitle="true" derivedAnchor="RFC8091"> <front> <title>A Media Type Structured Syntax Suffix for JSON Text Sequences</title> <authorinitials='E.' surname='Wilde' fullname='E. Wilde'><organization /></author>initials="E." surname="Wilde" fullname="E. Wilde"> <organization showOnFrontPage="true"/> </author> <dateyear='2017' month='February' /> <abstract><t>Structuredyear="2017" month="February"/> <abstract> <t>Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers"+json-seq""+json-seq" as a structured syntax suffix for JSON textsequences.</t></abstract>sequences.</t> </abstract> </front> <seriesInfo name="RFC" value="8091"/> <seriesInfo name="DOI" value="10.17487/RFC8091"/> </reference> <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126"> <front> <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <author initials="M." surname="Cotton" fullname="M. Cotton"> <organization showOnFrontPage="true"/> </author> <author initials="B." surname="Leiba" fullname="B. Leiba"> <organization showOnFrontPage="true"/> </author> <author initials="T." surname="Narten" fullname="T. Narten"> <organization showOnFrontPage="true"/> </author> <date year="2017" month="June"/> <abstract> <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t> <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t> <t>This is the third edition of this document; it obsoletes RFC 5226.</t> </abstract> </front> <seriesInfoname='RFC' value='8091'/>name="BCP" value="26"/> <seriesInfoname='DOI' value='10.17487/RFC8091'/>name="RFC" value="8126"/> <seriesInfo name="DOI" value="10.17487/RFC8126"/> </reference> <reference anchor="RFC8152"target='https://www.rfc-editor.org/info/rfc8152'>target="https://www.rfc-editor.org/info/rfc8152" quoteTitle="true" derivedAnchor="RFC8152"> <front> <title>CBOR Object Signing and Encryption (COSE)</title> <authorinitials='J.' surname='Schaad' fullname='J. Schaad'><organization /></author>initials="J." surname="Schaad" fullname="J. Schaad"> <organization showOnFrontPage="true"/> </author> <dateyear='2017' month='July' /> <abstract><t>Conciseyear="2017" month="July"/> <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 usingCBOR.</t></abstract>CBOR.</t> </abstract> </front> <seriesInfo name="RFC" value="8152"/> <seriesInfo name="DOI" value="10.17487/RFC8152"/> </reference> <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" quoteTitle="true" derivedAnchor="RFC8259"> <front> <title>The JavaScript Object Notation (JSON) Data Interchange Format</title> <author initials="T." surname="Bray" fullname="T. Bray" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2017" month="December"/> <abstract> <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t> <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t> </abstract> </front> <seriesInfoname='RFC' value='8152'/>name="STD" value="90"/> <seriesInfo name="RFC" value="8259"/> <seriesInfoname='DOI' value='10.17487/RFC8152'/>name="DOI" value="10.17487/RFC8259"/> </reference> <reference anchor="RFC8610"target='https://www.rfc-editor.org/info/rfc8610'>target="https://www.rfc-editor.org/info/rfc8610" quoteTitle="true" derivedAnchor="RFC8610"> <front> <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title> <authorinitials='H.' surname='Birkholz' fullname='H. Birkholz'><organization /></author>initials="H." surname="Birkholz" fullname="H. Birkholz"> <organization showOnFrontPage="true"/> </author> <authorinitials='C.' surname='Vigano' fullname='C. Vigano'><organization /></author>initials="C." surname="Vigano" fullname="C. Vigano"> <organization showOnFrontPage="true"/> </author> <authorinitials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>initials="C." surname="Bormann" fullname="C. Bormann"> <organization showOnFrontPage="true"/> </author> <dateyear='2019' month='June' /> <abstract><t>Thisyear="2019" month="June"/> <abstract> <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR orJSON.</t></abstract>JSON.</t> </abstract> </front> <seriesInfoname='RFC' value='8610'/>name="RFC" value="8610"/> <seriesInfoname='DOI' value='10.17487/RFC8610'/>name="DOI" value="10.17487/RFC8610"/> </reference> </references> </references> <sectionnumbered="no"numbered="false" anchor="acknowledgements"title="Acknowledgements"> <t>This drafttoc="include" removeInRFC="false" pn="section-appendix.a"> <name slugifiedName="name-acknowledgements">Acknowledgements</name> <t pn="section-appendix.a-1">This document has mostly been generated from <xreftarget="RFC7464"/>target="RFC7464" format="default" sectionFormat="of" derivedContent="RFC7464"/> byNico Williams<contact fullname="Nico Williams"/> and <xreftarget="RFC8091"/>target="RFC8091" format="default" sectionFormat="of" derivedContent="RFC8091"/> byErik Wilde,<contact fullname="Erik Wilde"/>, which do asimilar,similar but slightly more complicated exercise for JSON <xreftarget="RFC8259"/>. Laurence Lundbladetarget="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259"/>. <contact fullname="Laurence Lundblade"/> raised an issue on the CBOR mailing list that pointed out the need for this document.Jim Schaad and John Mattsson<contact fullname="Jim Schaad"/> and <contact fullname="John Mattsson"/> provided helpful comments.</t> </section> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b"> <name slugifiedName="name-authors-address">Author's Address</name> <author initials="C." surname="Bormann" fullname="Carsten Bormann"> <organization ascii="Universitaet Bremen TZI" showOnFrontPage="true">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> </section> </back><!-- ##markdown-source: H4sIAOSMi10AA61bbXMcN3L+jl+BrKpypLVL8UXSSXTZdRRJ2XSJpCJKpUqu rnLYGewurNmZ1QBDai0rvyUf8kuSP5anuzGvu5RVubiuztwZDNDol6efbsCT yUSlRZKbpT3WaWlmYeJsmE2SaVFOvP1Y2Tyxk8wE64PyweTpv5usyDE4lJVV blXyXz4c7u8/3z9UiQnH2odUPUiK3NvcV/5Y/2lt/Z/UA19Nl857V+RhvcIM F+dvX6qVO1ZaJ8VyZZJQD9U62E9hkjkfJn69nBYZZim+ezjBG8zSjs4LGuyL MpR25tvP8dHgQShdb/4iqX8EFzJIc1rkifNWv3C5Kdf6evqrTYJ+Y1elxT6C CZBb75y+uH6zq2+iYrwy02lpb/E1nnceP0ihsWN9uH/wXJkqLIqSdkniay26 PjWlDzbXL4pyafKc3xTl/Fi/y92tLb0L//NfQb8o7RKD3v7bBQ/ALqzFLl4X PsxMstBHR/uPH+/zu8SF9XH8QB4UKdY5mxw+O3ryPD6p8lBi1E+WFl3zw9WC zfnw8fPJ48ODyeHBs8nTo+eHB/zSLo3LjnVipsVfwm9uDxIqlZPIAVLSnt68 PP3z/uPnGAOPwe+Lk6uTvaVNnZmQlScQuUpCVdp04qvZzH2Ce3hfD0yK0k5W poRKAjaNWfoPNifEmM4P5fJZK80DFmd//3D/WBufOBefHD09hIBVmD2LD54c Hj3GkGk+kx08fXb0LM7LQpd2Hrf2+CkG/uo/ys9nh0+e088ij7/3nx/w64P4 ++DJIe3B2/j76QFESdI0U2oymWBFqAOeq5R6u3BeI/IqmCvo1PqkdFPrdVjY b3JFNXBFLXrQiFDs3RcJtmJT2ZOmTamRWa0yl/DXj+r4Hu1pfdL3Xk2Ri8jz uphhurXOq+XUlvil8BpOlcp4uLjRLtilH2vvlqtsTV9ifpvz0i7XNYDsKXXT +AGCE3v4pMUdsGVI3pHTa5NlxZ0uoIn+81CoaeWyVCMQ8XLJe12aDxZSaPuJ Noc/wsLQ/9m1NqXV9EGgD0yOIdiVy+eqnRSqorGuhBBVnrJuoBE2jl/ZxM2i wmChmctJuDxVcA/MBPfUo4eNImkqo/092+RNktpUAxJ74hNLB/ewCp55geAs UnxO5oWDfJsj1Jj0+TOD9pcviNZcT62uvE0VLett6UzmfpPhMKpYjpWof7m5 vqJvyanxLb9awsgZ0IjGOPKDu3ysfLG0d6RbaBpKwAbbsVDZ+4XNm5WgZNJF 7VBY0lfJQt2arLLwFliJ9IsJg1tCp3CbW5s7CoRQ6IW5hV1qf76DF1iSFDFV T+h5i9HnprbvdpihmAYD0c3mzjGP6o3uyliLh41jEvH1wTZkiGIfW7r5Iuh5 CV8Vj8MnqZ6u9a9IhxrBhp+kiFlVsisPgmbv6xhAUtqVxHNUBdYf9fPMaKzu Fg55gFydsiKQJ6Vxv9myoH0sAaf6nqiF0foOWTsOxT9ESvUOLb5in7TpLrwh 4ewSEKBrfeeQ1qqAYPhYuTJaHPnJLOlvXgs4DgtIRGKnZppZ0iwchlKcQiZv wkXAppVusNgO9mJUO71sqWymjMaalcVS96ftzbO7RelNWOs2rMkA2+FSAEkx dsQI6qCJzFCux5pI0px1hF2dFievKZbhdGHyko2pXIofgBdbwg6X7RT3AQhk RJT2UtSXL+qOgsNF3LCpYNCdWTPcmK5oUJJ389xk0RxskakhjGB0HMItTUWx 38NFtmoLNLXyKKoECUf3yl+j6tc1r1jzHVC9F0+j8kedvHLDA9SNDHgTbTGC zR88IPXfksbh2/qdl/TEAp1FgQRxPyBv3BVlCmi/fHfzdjSWf+ura/77zfm/ vLt4c35Gf9/8fPLqVfOHiiNufr5+9+qs/av98vT68vL86kw+xlPde6RGlyf/ ijekjtH167cX11cnr0ayza7aKNJhyymb3ZbIBIHtrmr44J29OH393/958Bi2 +ifQkMODg+cwl/x4dvDnx/gBXM1ltSKnaOaflDYVIZdh7EfIABNWDrEDWIRD +AVSgSZEhlLVRZStlyh5EtD3cqlH03WwI/KzKiqcHCov7iYJELJYIqUpKhFs TJ3rvMjXS3bdUZEEG9h0A3ISw0fxvxHSY4qv3gjnB6BNYvgGhUqbVKDXtzZb K/FBDhvrKACU+o6ZwnIVADqEopPM5vOw2N2cEUNpq5srgZIQRlUrnmor+LZB NAZTnBXEeCwnj8Fu9ljN0HsZxp08R/N/C8bruc1tSdWbGk6sQRyoRKOfgfT4 ldkHeQLuUECPvsqCZz8ZTL3LsVSyKfKC0yJRgMZAyItYqSDk27mYwQF5JBzY IYzHiiab8IY4q2D+sgSkSfru7FBoiqRkBESbF1INYqVgxKxY81O2LaUXsjcU QxvDvBCkfiBW1s2qzNY95Rz8yuzQfEvIAx5fcXKaWskDpCkET1msSiLfyIxd nkZa6Wfvsa7yzH2IHOwtKt72nVCyj/APhD6UGCiGIA6C5gO2MrXhztq8SeSM ZPgfCIB3lBOnNjH0Ba9Ya4XkV+IXBCPeZrMJJeOlC6LptKExRAVMhkzimRGY LKmoCZCSya4KbI7CaQzYcJnsHpABVRTMUB+xwSYMLMRdyHS8xzvg1MaqXt/Z LBtHLAkF4CeN5mQihBzF8CSEz0YWyYySMUkMJEUKzYWdLQ3IAMa5VNat0dOT Ec5s7VkD4ADuf/A0pcSjPyY0uOh4XQ9iapTYiH9BQAkPGan0lrHb/XgPS16T t96B98P2tiahW92Q+Q6tJsDTiRBqecTFBOUdQr0MHdEaljaUIbJZbpqYMtSz xg3hF/zaCkhIaqr1Cc+H5/YRVgsHkgmWYOU0kKUlTzrpMEbZagkrVBn7YWnh OyyGEP1IGzeRaVOLY7hj9I6C2A31EVo1RXwGBSKIpqC9NS4jKinIhT0trcnr lCFFcJeZ9nGfQS6wE0/I2wnChF7R4yYiA0Fm5rDMujZrVGujYt/B5pNcsbsv mzqPMAexaJrJkoLUIZwXtZS2ZVmUEZDrqdRG/jPZsvAI3WkVWEAiRRCMMk9n C72EoprNQ7Kf4U0Z6Q/pN46V1/C/KngX9+WTYmVlYw5B36UIjZY5j3RUvRlo sfIhNOooLwBjFHhfnnQLu43sS88yA/UOokYMqNr4iKpQjSq4TdmLj4iaTZ23 pW0SHVjVimbSQ2RG6imab1AftZ+yA8O+4upqxdg9q52cX+/YvfnemCiCr3xd W1JkEy6XHJ5tHOGPXYV9MngaHXVF8jgqAUQNddKEJ1lEVkqc7oF+O2DgGwRb C8EWvkxy8iIk7LeTd0JFlEjzogLlL8T6zPukijjWF8iFwp9jJ0O4Uac+4ZRA FWZMFKqHgZ2BkpOEY/bVnlmTUluJ8iq8EBPNqqwGuiZeAo2DF7X9CgobKfK7 uNyLkp33Uh6zMB/BE9pOUutEdc6zVBkyksCr3a1jVkH9dSnjgD6sls6mOPMC 4bDbpADYWqKIwE1qbgCZK0YIsk1rkq+UZojHk7bY9Rz7FVUXkiW7Ju3olYIy kBEivYq+S6sy63RJnREYbWdcTnBjLrdUDpA96oG3zt710tdNE5ziV2terjt3 35ShKDLuJCric9Bg4xqR1YAr1XAaO35UytS41JW0yOGSK5EGtmr2UrsaVuK6 5DV1cqGzjGpLwr1S1Mfl5g1PvN4IdYbn07OzV8zr6Q8uBdI0I6rHQ9suF+em DJCRUtCvVigCpFhJpJdA3s5uz8cb+Zwwp6ZNf98jo2Guv/Possg0ALkk2q13 biw3GfXR3rO9xzRJI8MuI0xLnRv2bZq2FM2VUVuHDnGU+g/8IztaricWJCxF 2mjOj/QPEZZrcTRG8Yyq/gND/vodPbZinr+p9m+8w49ZUehH9MfUlLwemDRp DjSj5OIFBC+GJex4SymIAqfKTVqUeV0VdfRKxB42Rm0HkkINI0YI7kD1M5Wm epNKViF1vprPka9JdY770UzKo4rGQh3LP1L/uB7UEaGsMiut+zTV54AU5xd8 BiY+SM1tcKc2TfYTqpS1jBpmSqBj+jtuOVhUaw2TigXvGfH72KZpujP15oaf t41HaUdwu/n7TjlYr35M9mxE+b8Ye+dlRbCl+VyMAIroMzkApcza4obsL+pg /Ta6ZTzxbdFFeZScXGLFUAeXeKD498AkshvSywaDQZCfOTPPQaaADldx7Vjj pe2bRqodb62uI+8p7aFpAuwSysHalvrqauvHJ9JP/qR/qr+UeBUSNfR/tcX/ O/V7kMRD2UzvCE0KRCJ4mk4IDQpWXYe36KWDPPSglXDvqI8p0sSgZLkEz0am WLnSca9fGHBSLGH/tDUeGxeufGvHW/hj+wWnqqxoQG/I11zeOPCeiMB8Kh4a IvJtoDpm3J4y6Cn3O0uH3VLUYAZxdIqWxho1uyPvL6a3DjSmPtVgc3RJP8jD LRFhCThEJ5XvSB0fbKjhgj5rEER6bMJRKYHfFfAMQ7nLN4GKbZKTqL8ejPXh WB/9Tan4V4wYKtG7jd7m8CZ1yPgJ8xt4jfNJhYKt0+catnpisRP9g9Qm7dTr FZxHDnoGPkJbuvngVit6dx4Bgx0gQQHK5zIdrjGOHLRp5JN4TkDdYxaus2US ddehVEwhaKmm+qTeYrf1z8yhO93M5ETxyAQtkGHJJRXDk7CgPEvFzKCc5QOr hldWgaonKs2QjI3Uai8Fzr0d7qyTmdWOuFECQ6/rblNzeF2wwTlR7nK+iIVy E2+sYzAgVbPhCFddQN6A3T9G9aYP0RX1HqjHHH2w/wehvkMLOoPa+wJq28N7 U8R7iVXuKvnIq7lJR+Foc3avWDHzmRwVza0TLOhAhghvLkkUCw1Kem4IciTQ Cg0KNGXrsN5uGJkgs5WDSWiuO6eRLhazyRtqmriw3iCTb3n2+DLpvWzM1x7J kAeu64ageJeKgM692KRcr0IxL80KNuUjhDlPjDEhpqZ46o8qOpXSWI4FUVos p9wtZzbRiNSD5rYtd3p9c85yFd5CLkKbAjC0p3b4Tbtec+zIwSN64r451eID HhNPZg28McbjgND0msyW8hHH/vcDHKOKdazAtRxJgEQAnEA81y0WOdIkD59J I0qKldqKUXbG89JmsvGFW+mhTINOEddZlDlQDtatvRJuSpWkkEOrGQlWVaf8 9HIWy96j6P4OhnMfdtioaibkA6uZcRmojUksalr4dJRlZsRHkf0AjMhbspyX 2p/u2myrZuR88i3dIlGX3ZsapW3O7gQQ+rW3b05Em8NLubfz5QvyMS3GzBXq 8fHovp6NJ7q8uDzvVpz1HYom24zVtkPacb+HS2LHS1ed0UrdVNPQvqo/VupN bf3uvaSrRydKUdJjd9l4c16fG/QD9FhP+eYGFtsewcfYiqWbQgRYYyipDqtJ fxzpCykUK7KjTF22ba6z5giQnNbl+OZ1NaVagkr+bpwe12vuDUp/9iRpHLB3 1brH5ESr+hcqqGABrnSfYb6XpZkzxrdH3BuSstJO2vjrZELuup/R0Yl0rDA1 zElG6tAlEYln+U5fmjlRZT4A2PG7zfOXdDbBrJqqhu6bS5MA+grUWDM+v+B2 BoKnHfMatsUO/1luwFFZVlJrGx7K6TmRdlV9taMnvvjSX+gapdyXI7vxhZnK mzld/bu+vLy+wv7lYuDwKqDe6V63o1Ojhcnn3dI7Xp2UY+2NqwX1yXd0861h BlRx83z71QR9cdaUsZ3bDtvvQ4zroN8yEfOxGgBqwO5f8GvwgauF/t0/aog0 Bxyj808rOr94Y6lVNNI7+5PDJ092VUmqYTC0cVPYIDbgOkT68+cwzTC7WU1i 42Qi5pKw+r17/aL953fdBPXvNCM/emNniCzKL7/ju20awaBJO8XbF2dPj+g7 iTZ6pj4f6wf3CQT1ZP6HUaazkeZ7qT+Mtlto9AVA9fJUQ/JAPvSaepQExqsM CB/XRZHLXFnu7zXnlY2e6C5bimwVYriT7pkaCMe/v/N735vNlBBrqMFVDdX7 qr2qoemEiMgvCRcoZ3hPRpJboEMvVr1k8a23RkwCP0tN3RaB48ULoORvvcTx o76Sq7rdlEOPH9Y3WR+2WePH1jd8g670+A9Tw4/6WxCTaaDshWDXA5cwNOEW 4Gzz++ZWRiyTGkk7bXXT1NVx0L03RHdOgl5RJukeuGB79bnquKVJ4Jgb4sSv ovj1pQvqL9yzIkDvxx/v3zJD77Y9z+SaWN3UHX369OnRer3unmY0u6/Lu3Rg dCxMBR1RRN/ICr952NKLtltQS9G5zkXnB0V2S42U6Jmt7qmnJPVV3pyW9qzQ XWfv/0OYpjEUpfq6UKoVSveE2tTkhnS0yHYJv7rd7TPrP+Q6+SND4/5hXkWT nEpKj5H+/ieCIT7ipP8AAem4m853xzqeyVyc3/w0oUsr83iVtEpoh0XJG5Dk /uje3E315NQkH4h2nyQf8uIus+k8Fg6fH5jBoy+UNgTIbfrDKC8oAUhNT//R hl7AYtSZ4OsoUHd97yeVFFrfJqGUcOWSQr93GXjV0iuKLHl7IK/PS/eBXqfN IRMKt6Z3JxWhz+juKx2U0gk9XTzlIKZj40+25CvLFIr9u8XAkVemkuz5qsrT aUa3NErjOAZz5VDp2Hi3WyzRMwMz01VBJWuqN9pAPTjCSr+4pb5JFsZwltO/ FIscrC8ET6wuFsREk7MVHflJO5GqoP8FtqbccBAzAAA= --></rfc>