rfc8742xml2.original.xml		rfc8742.xml
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version='1.0' encoding='utf-8'?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
	<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 -->		nsus="true" docName="draft-ietf-cbor-sequence-02" indexInclude="true" ipr="trust
			200902" number="8742" prepTime="2020-02-19T08:03:51" scripts="Common,Latin" sort
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [		Refs="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=
	<?rfc compact="yes"?>		"prev"/>
	<?rfc text-list-symbols="o*+-"?>		<link href="https://dx.doi.org/10.17487/rfc8742" rel="alternate"/>
	<?rfc subcompact="no"?>		<link href="urn:issn:2070-1721" rel="alternate"/>
	<?rfc sortrefs="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc strict="yes"?>
	<?rfc toc="yes"?>
	<rfc ipr="trust200902" docName="draft-ietf-cbor-sequence-02" category="std">
	<front>		<front>
	<title abbrev="CBOR Sequences">Concise Binary Object Representation (CBOR) S equences</title>		<title abbrev="CBOR Sequences">Concise Binary Object Representation (CBOR) S equences</title>
			<seriesInfo name="RFC" value="8742" stream="IETF"/>
	<author initials="C." surname="Bormann" fullname="Carsten Bormann">		<author initials="C." surname="Bormann" fullname="Carsten Bormann">
	<organization>Universität Bremen TZI</organization>		<organization ascii="Universitaet Bremen TZI" showOnFrontPage="true">Unive rsitä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 month="02" year="2020"/>
	<date year="2019" month="September" day="25"/>		<keyword>binary format</keyword>
			<keyword>data interchange format</keyword>
	<abstract>		<keyword>JSON</keyword>
			<abstract pn="section-abstract">
	<t>This document describes the Concise Binary Object Representation		<t pn="section-abstract-1">This document describes the Concise Binary Obje
			ct Representation
	(CBOR) Sequence format and associated media type		(CBOR) Sequence format and associated media type
	“application/cbor-seq”. A CBOR Sequence consists of any number of		"application/cbor-seq". A CBOR Sequence consists of any number of
	encoded CBOR data items, simply concatenated in sequence.</t>		encoded CBOR data items, simply concatenated in sequence.</t>
			<t pn="section-abstract-2">Structured syntax suffixes for media types allo
	<t>Structured syntax suffixes for media types allow other media types to		w other media types to
	build on them and make it explicit that they are built on an existing		build on them and make it explicit that they are built on an existing
	media type as their foundation. This specification defines and		media type as their foundation. This specification defines and
	registers “+cbor-seq” as a structured syntax suffix for CBOR		registers "+cbor-seq" as a structured syntax suffix for CBOR
	Sequences.</t>		Sequences.</t>
	</abstract>		</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="non
			e"/>.
			</t>
			</section>
			<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
			ude" 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" p
			n="section-toc.1">
			<name slugifiedName="name-table-of-contents">Table of Contents</name>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
			c.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 derivedCon
			tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
			n</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-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 derive
			dContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-conventions-u
			sed-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 derivedCon
			tent="" format="title" sectionFormat="of" target="name-cbor-sequence-format">CBO
			R 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 derivedCon
			tent="" format="title" sectionFormat="of" target="name-the-cbor-seq-structured-s
			yn">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 derivedCon
			tent="" format="title" sectionFormat="of" target="name-practical-considerations"
			>Practical Considerations</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-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 derive
			dContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-specifying-cb
			or-sequences-i">Specifying CBOR Sequences in Concise Data Definition Language (C
			DDL)</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 derive
			dContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-diagnostic-no
			tation">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 derive
			dContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-optimizing-cb
			or-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 derivedCon
			tent="" 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 derivedCon
			tent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA
			Considerations</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-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 derive
			dContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-media-type">M
			edia 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 derive
			dContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xre
			f 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 derive
			dContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-structured-sy
			ntax-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 derivedCon
			tent="" format="title" sectionFormat="of" target="name-references">References</x
			ref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-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 derive
			dContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-normative-ref
			erences">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 derive
			dContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xre
			f derivedContent="" format="title" sectionFormat="of" target="name-informative-r
			eferences">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 derivedC
			ontent="" format="title" sectionFormat="of" target="name-acknowledgements">Ackno
			wledgements</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 derivedC
			ontent="" format="title" sectionFormat="of" target="name-authors-address">Author
			's Address</xref></t>
			</li>
			</ul>
			</section>
			</toc>
	</front>		</front>
	<middle>		<middle>
			<section anchor="introduction" numbered="true" toc="include" removeInRFC="fa
	<section anchor="introduction" title="Introduction">		lse" pn="section-1">
			<name slugifiedName="name-introduction">Introduction</name>
	<t>The Concise Binary Object Representation (CBOR) <xref target="RFC7049"/> can		<t pn="section-1-1">The Concise Binary Object Representation (CBOR) <xref
	be used		target="RFC7049" format="default" sectionFormat="of" derivedContent="RFC7049"/>
	for serialization of data in the JSON <xref target="RFC8259"/> data model or in		can be used for serialization of
	its own,		data in the JSON <xref target="RFC8259" format="default" sectionFormat="of
	somewhat expanded data model. When serializing a sequence of such		" derivedContent="RFC8259"/> data model or
	values, it is sometimes convenient to have a format where these		in its own, somewhat expanded, data model. When serializing a sequence of
	sequences can simply be concatenated to obtain a serialization of the		such values, it is sometimes convenient to have a format where these
	concatenated sequence of values, or to encode a sequence of values		sequences can simply be concatenated to obtain a serialization of the
	that might grow at the end by just appending further CBOR data items.</t>		concatenated sequence of values or to encode a sequence of values that
			might grow at the end by just appending further CBOR data items.</t>
	<t>This document describes the concept and format of “CBOR Sequences”,		<t pn="section-1-2">This document describes the concept and format of "CBO
	which are composed of zero or more encoded CBOR data items. CBOR		R Sequences",
	Sequences can be consumed (and produced) incrementally without		which are composed of zero or more encoded CBOR data items. CBOR
	requiring a streaming CBOR parser that is able to deliver		Sequences can be consumed (and produced) incrementally without requiring
	substructures of a data item incrementally (or a		a streaming CBOR parser that is able to deliver substructures of a data
	streaming encoder able to encode from substructures incrementally).</t>		item incrementally (or a streaming encoder able to encode from
			substructures incrementally).</t>
	<t>This document defines and registers the “application/cbor-seq” media		<t pn="section-1-3">This document defines and registers the "application/c
	type in the media type registry, along with a CoAP Content-Format		bor-seq" media
	identifier. Media type structured syntax suffixes <xref target="RFC6838"/>		type in the "Media Types" registry along with a Constrained Application
	were introduced as a way for a media type to signal that it is based		Protocol (CoAP) Content-Format identifier. Media type structured syntax
	on another media type as its foundation. CBOR <xref target="RFC7049"/> defines		suffixes <xref target="RFC6838" format="default" sectionFormat="of" derive
	the		dContent="RFC6838"/> were introduced as a
	“+cbor” structured syntax suffix. This document defines and registers		way for a media type to signal that it is based on another media type as
	the “+cbor-seq” structured syntax suffix in the “Structured Syntax		its foundation. CBOR <xref target="RFC7049" format="default" sectionForma
	Suffix Registry”.</t>		t="of" derivedContent="RFC7049"/> defines
			the "+cbor" structured syntax suffix. This document defines and
	<section anchor="conventions-used-in-this-document" title="Conventions Used in T		registers the "+cbor-seq" structured syntax suffix in the "Structured
	his Document">		Syntax Suffix Registry".</t>
			<section anchor="conventions-used-in-this-document" numbered="true" toc="i
	<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL		nclude" removeInRFC="false" pn="section-1.1">
	NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,		<name slugifiedName="name-conventions-used-in-this-do">Conventions Used
	“MAY”, and “OPTIONAL” in this document are to be interpreted as		in This Document</name>
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and		<t pn="section-1.1-1">
	only when, they		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	appear in all capitals, as shown here.</t>		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
			D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
	<t>In this specification, the term “byte” is used in its now-customary		OT RECOMMENDED</bcp14>",
	sense as a synonym for “octet”.</t>		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be interpreted as
	</section>		described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
	</section>		f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
	<section anchor="cbor-sequence-format" title="CBOR Sequence Format">		mat="of" derivedContent="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
	<t>Formally, a CBOR Sequence is a sequence of bytes that is recursively		</t>
	defined as either</t>		<t pn="section-1.1-2">In this specification, the term "byte" is used in
			its now-customary
	<t><list style="symbols">		sense as a synonym for "octet".</t>
	<t>an empty (zero-length) sequence of bytes</t>		</section>
	<t>the sequence of bytes making up an encoded CBOR data item <xref target="RFC		</section>
	7049"/>,		<section anchor="cbor-sequence-format" numbered="true" toc="include" removeI
	followed by a CBOR Sequence.</t>		nRFC="false" pn="section-2">
	</list></t>		<name slugifiedName="name-cbor-sequence-format">CBOR Sequence Format</name
			>
	<t>In short, concatenating zero or more encoded CBOR data items generates		<t pn="section-2-1">Formally, a CBOR Sequence is a sequence of bytes that
			is recursively
			defined as either 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 of bytes</li>
			<li pn="section-2-2.2">the sequence of bytes making up an encoded CBOR d
			ata item <xref target="RFC7049" format="default" sectionFormat="of" derivedConte
			nt="RFC7049"/>
			followed by a CBOR Sequence.</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		a CBOR Sequence. (Consequently, concatenating zero or more CBOR
	Sequences also results in a CBOR Sequence.)</t>		Sequences also results in a CBOR Sequence.)</t>
			<t pn="section-2-4">There is no end-of-sequence indicator. (If one is des
	<t>There is no end of sequence indicator. (If one is desired,		ired, CBOR
	CBOR-encoding an array of the CBOR data model values being encoded —		encoding an array of the CBOR data model values being encoded, employing
	employing either a definite or an indefinite length encoding — as a		either a definite or an indefinite length encoding, as a single CBOR
	single CBOR data item may actually be the more appropriate		data item may actually be the more appropriate representation.)</t>
	representation.)</t>		<t pn="section-2-5">CBOR Sequences, unlike JSON Text Sequences <xref targe
			t="RFC7464" format="default" sectionFormat="of" derivedContent="RFC7464"/>, do n
	<t>CBOR Sequences, unlike JSON Text Sequences <xref target="RFC7464"/>, do not u		ot use a
	se a		marker between items. This is possible because CBOR-encoded data
	marker between items. This is possible because CBOR encoded data		items are self delimiting and the end can always be calculated. (Note
	items are self-delimiting and the end can always be calculated. (Note
	that, while the early object/array-only form of JSON was		that, while the early object/array-only form of JSON was
	self-delimiting as well, this stopped being the case when simple		self delimiting as well, this stopped being the case when simple
	values such as single numbers were made valid JSON documents.)</t>		values such as single numbers were made valid JSON documents.)</t>
			<t pn="section-2-6">Decoding a CBOR Sequence works as follows:</t>
	<t>Decoding a CBOR Sequence works as follows:</t>		<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 byte
	<t><list style="symbols">		s, the result is an
	<t>If the CBOR Sequence is an empty sequence of bytes, the result is an		empty sequence of CBOR data model values.</li>
	empty sequence of CBOR data model values.</t>		<li pn="section-2-7.2">Otherwise, one must decode a single CBOR data ite
	<t>Otherwise, decode a single CBOR data item from the bytes of the CBOR		m from the bytes
	sequence, and insert the resulting CBOR data model value at the		of the CBOR Sequence and insert the resulting CBOR data model value at
	start of the result of repeating this decoding process recursively		the start of the result of repeating this decoding process recursively
	with the remaining bytes. (A streaming decoder would therefore		with the remaining bytes. (A streaming decoder would therefore simply
	simply deliver zero or more CBOR data model values, each as soon as		deliver zero or more CBOR data model values, each as soon as the bytes
	the bytes making it up are available.)</t>		making it up are available.)</li>
	</list></t>		</ul>
			<t pn="section-2-8">This means that if any data item in the sequence is no
	<t>This means that if any data item in the sequence is not well-formed,		t well formed,
	it is not possible to reliably decode the rest of the sequence. (An		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		implementation may be able to recover from some errors in a sequence
	of bytes that is almost, but not entirely a well-formed encoded CBOR		of bytes that is almost, but not entirely, a well-formed encoded CBOR
	data item. Handling malformed data is outside the scope of this		data item. Handling malformed data is outside the scope of this
	specification.)</t>		specification.)</t>
			<t pn="section-2-9">This also means that the CBOR Sequence format can reli
	<t>This also means that the CBOR Sequence format can reliably detect		ably detect
	truncation of the bytes making up the last CBOR data item in the		truncation of the bytes making up the last CBOR data item in the
	sequence, but not		sequence, but it cannot detect entirely missing CBOR data items at the end
	entirely missing CBOR data items at the end. A CBOR Sequence decoder		. A
	that is used for consuming streaming CBOR Sequence data may simply		CBOR Sequence decoder that is used for consuming streaming CBOR Sequence
	pause for more data (e.g., by suspending and later resuming decoding)		data may simply pause for more data (e.g., by suspending and later
	in case a truncated final item is being received.</t>		resuming decoding) in case a truncated final item is being received.</t>
			</section>
	</section>		<section anchor="the-cbor-seq-structured-syntax-suffix" numbered="true" toc=
	<section anchor="the-cbor-seq-structured-syntax-suffix" title="The “+cbor-seq” S		"include" removeInRFC="false" pn="section-3">
	tructured Syntax Suffix">		<name slugifiedName="name-the-cbor-seq-structured-syn">The "+cbor-seq" Str
			uctured Syntax Suffix</name>
	<t>The use case for the “+cbor-seq” structured syntax suffix is analogous		<t pn="section-3-1">The use case for the "+cbor-seq" structured syntax suf
	to that for “+cbor”: It SHOULD be used by a media type when parsing the		fix is
	bytes of the media type object as a CBOR Sequence leads to a		analogous to that for "+cbor": it <bcp14>SHOULD</bcp14> be used by a
	meaningful result that is at least sometimes not just a single CBOR		media type when the result of parsing the bytes of the media type
	data item. (Without the qualification at the end, this sentence is		object as a CBOR Sequence is meaningful and is at least
	trivially true for any +cbor media type, which of course should		sometimes not just a single CBOR data item. (Without the qualification
	continue to use the “+cbor” structured syntax suffix.)</t>		at the end, this sentence is trivially true for any +cbor media type,
			which of course should continue to use the "+cbor" structured syntax
	<t>Applications encountering a “+cbor-seq” media type can then either simply		suffix.)</t>
			<t pn="section-3-2">Applications encountering a "+cbor-seq" media type can
			then either simply
	use generic processing if all they need is a generic view of the CBOR		use generic processing if all they need is a generic view of the CBOR
	Sequence, or they can use generic CBOR Sequence tools for		Sequence or use generic CBOR Sequence tools for
	initial parsing and then implement their own specific processing on		initial parsing and then implement their own specific processing on
	top of that generic parsing tool.</t>		top of that generic parsing tool.</t>
			</section>
	</section>		<section anchor="practical-considerations" numbered="true" toc="include" rem
	<section anchor="practical-considerations" title="Practical Considerations">		oveInRFC="false" pn="section-4">
			<name slugifiedName="name-practical-considerations">Practical Consideratio
	<section anchor="specifying-cbor-sequences-in-cddl" title="Specifying CBOR Seque		ns</name>
	nces in CDDL">		<section anchor="specifying-cbor-sequences-in-cddl" numbered="true" toc="i
			nclude" removeInRFC="false" pn="section-4.1">
	<t>In CDDL <xref target="RFC8610"/>, CBOR sequences are already supported as con		<name slugifiedName="name-specifying-cbor-sequences-i">Specifying CBOR S
	tents of		equences in Concise Data Definition Language (CDDL)</name>
	byte strings using the <spanx style="verb">.cborseq</spanx> control operator (Se		<t pn="section-4.1-1">In Concise Data Definition Language (CDDL) <xref t
	ction 3.8.4 of		arget="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/>,
	<xref target="RFC8610"/>), by employing an array as the controller type:</t>		CBOR Sequences are already supported as contents
			of byte strings using the <tt>.cborseq</tt> control operator (<xref targ
	<figure><artwork type="CDDL"><![CDATA[		et="RFC8610" sectionFormat="of" section="3.8.4" format="default" derivedLink="ht
	my-embedded-cbor-seq = bytes .cborseq my-array		tps://rfc-editor.org/rfc/rfc8610#section-3.8.4" derivedContent="RFC8610"/>) by e
			mploying an
			array as the controller type:</t>
			<sourcecode type="cddl" markers="false" pn="section-4.1-2">my-embedded-c
			bor-seq = bytes .cborseq my-array
	my-array = [* my-element]		my-array = [* my-element]
	my-element = my-foo / my-bar		my-element = my-foo / my-bar
	]]></artwork></figure>		</sourcecode>
			<t pn="section-4.1-3">Currently, CDDL does not provide for unadorned CBO
	<t>CDDL currently does not provide for unadorned CBOR sequences as a		R Sequences as a
	top-level subject of a specification. For now, the suggestion is to		top-level subject of a specification.
	use an array, as for the <spanx style="verb">.cborseq</spanx> control operator,
	for the
	top-level rule and add English text that explains that the
	specification is really about a CBOR sequence with the elements of the
	array:</t>
	<figure><artwork type="CDDL"><![CDATA[		For now, the suggestion is to use an array for the top-level rule, as is used
	; This defines an array, the elements of which are to be used		for the <tt>.cborseq</tt> control operator, and add English text that
	; in a CBOR sequence:		explains that the specification is really about a CBOR Sequence with the
			elements of the array:</t>
			<sourcecode type="cddl" markers="false" pn="section-4.1-4">; This define
			s an array, the elements of which are to be used
			; in a CBOR Sequence:
	my-sequence = [* my-element]		my-sequence = [* my-element]
	my-element = my-foo / my-bar		my-element = my-foo / my-bar
	]]></artwork></figure>		</sourcecode>
			<t pn="section-4.1-5">(Future versions of CDDL may provide a notation fo
	<t>(Future versions of CDDL may provide a notation for top-level CBOR		r top-level CBOR
	sequences, e.g. by using a group as the top-level rule in a CDDL		Sequences, e.g., by using a group as the top-level rule in a CDDL
	specification.)</t>		specification.)</t>
			</section>
	</section>		<section anchor="diagnostic-notation" numbered="true" toc="include" remove
	<section anchor="diagnostic-notation" title="Diagnostic Notation">		InRFC="false" pn="section-4.2">
			<name slugifiedName="name-diagnostic-notation">Diagnostic Notation</name
	<t>CBOR diagnostic notation (see Section 6 of <xref target="RFC7049"/>) or exten		>
	ded		<t pn="section-4.2-1">CBOR diagnostic notation (see <xref target="RFC704
	diagnostic notation (Appendix G of <xref target="RFC8610"/>) also does not provi		9" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-edit
	de		or.org/rfc/rfc7049#section-6" derivedContent="RFC7049"/>) or extended
			diagnostic notation (<xref target="RFC8610" sectionFormat="of" section="G" forma
			t="default" derivedLink="https://rfc-editor.org/rfc/rfc8610#appendix-G" derivedC
			ontent="RFC8610"/>) also does not provide
	for unadorned CBOR Sequences at this time (the latter does provide for		for unadorned CBOR Sequences at this time (the latter does provide for
	CBOR Sequences embedded in a byte string in Appendix G.3 of		CBOR Sequences embedded in a byte string as per <xref target="RFC8610" sectionFo
	<xref target="RFC8610"/>).</t>		rmat="of" section="G.3" format="default" derivedLink="https://rfc-editor.org/rfc
			/rfc8610#appendix-G.3" derivedContent="RFC8610"/>).</t>
	<t>In a similar spirit to the recommendation for CDDL above, this		<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.		specification recommends enclosing the CBOR data items in an array.
	In a more informal setting, where the boundaries within which the		In a more informal setting, where the boundaries within which the
	notation is used are obvious, it is also possible to leave off 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>		outer brackets for this array, as shown in these two examples:</t>
			<artwork type="CBORdiag" name="" align="left" alt="" pn="section-4.2-3">
	<figure><artwork type="CBORdiag"><![CDATA[
	[1, 2, 3]		[1, 2, 3]
	1, 2, 3		1, 2, 3
	]]></artwork></figure>		</artwork>
			<t pn="section-4.2-4">Note that it is somewhat difficult to discuss zero
	<t>Note that it is somewhat difficult to discuss zero-length CBOR		-length CBOR
	Sequences in the latter form.</t>		Sequences in the latter form.</t>
			</section>
	</section>		<section anchor="optimizing-cbor-sequences-for-skipping-elements" numbered
	<section anchor="optimizing-cbor-sequences-for-skipping-elements" title="Optimiz		="true" toc="include" removeInRFC="false" pn="section-4.3">
	ing CBOR Sequences for Skipping Elements">		<name slugifiedName="name-optimizing-cbor-sequences-f">Optimizing CBOR S
			equences for Skipping Elements</name>
	<t>In certain applications, being able to efficiently skip an element		<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		without the need for decoding its substructure, or efficiently fanning
	out elements to multi-threaded decoding processes, is of the utmost		out elements to multi-threaded decoding processes, is of the utmost
	importance. For these applications, byte strings		importance. For these applications, byte strings
	(which carry length information in bytes) containing embedded CBOR can		(which carry length information in bytes) containing embedded CBOR can
	be used as the elements of a CBOR sequence:</t>		be used as the elements of a CBOR Sequence:</t>
			<sourcecode type="cddl" markers="false" pn="section-4.3-2">; This define
	<figure><artwork type="CDDL"><![CDATA[		s an array of CBOR byte strings, the elements of which
	; This defines an array of CBOR byte strings, the elements of which		; are to be used in a CBOR Sequence:
	; are to be used in a CBOR sequence:
	my-sequence = [* my-element]		my-sequence = [* my-element]
	my-element = bytes .cbor my-element-structure		my-element = bytes .cbor my-element-structure
	my-element-structure = my-foo / my-bar		my-element-structure = my-foo / my-bar
	]]></artwork></figure>		</sourcecode>
			<t pn="section-4.3-3">Within limits, this may also enable recovering fro
	<t>Within limits, this may also enable recovering from elements that		m elements that
	internally are not well-formed — the limitation is that the sequence		internally are not well formed; the limitation is that the sequence
	of byte strings does need to be well-formed as such.</t>		of byte strings does need to be well formed as such.</t>
			</section>
	</section>		</section>
	</section>		<section anchor="security-considerations" numbered="true" toc="include" remo
	<section anchor="security-considerations" title="Security Considerations">		veInRFC="false" pn="section-5">
			<name slugifiedName="name-security-considerations">Security Considerations
	<t>The security considerations of CBOR <xref target="RFC7049"/> apply. This for		</name>
	mat		<t pn="section-5-1">The security considerations of CBOR <xref target="RFC7
	provides no cryptographic integrity protection of any kind, but can be		049" format="default" sectionFormat="of" derivedContent="RFC7049"/> apply. This
	combined with security specifications such as COSE <xref target="RFC8152"/> to d		format
	o so.		provides no cryptographic integrity protection of any kind but can be
	(COSE protections can be applied to an entire CBOR sequence or to each		combined with security specifications such as CBOR Object Signing and
			Encryption (COSE) <xref target="RFC8152" format="default" sectionFormat="of" der
			ivedContent="RFC8152"/> to do so.
			(COSE protections can be applied to an entire CBOR Sequence or to each
	of the elements of the sequence independently; in the latter case,		of the elements of the sequence independently; in the latter case,
	additional effort may be required if there is a need to protect the		additional effort may be required if there is a need to protect the
	relationship of the elements in the sequence.)</t>		relationship of the elements in the sequence.)</t>
			<t pn="section-5-2">As usual, decoders must operate on input that is assum
	<t>As usual, decoders must operate on input that is assumed to be		ed to be
	untrusted. This means that decoders MUST fail gracefully in the face		untrusted. This means that decoders <bcp14>MUST</bcp14> fail gracefully in the
			face
	of malicious inputs.</t>		of malicious inputs.</t>
			</section>
			<section anchor="iana-considerations" numbered="true" toc="include" removeIn
			RFC="false" pn="section-6">
			<name slugifiedName="name-iana-considerations">IANA Considerations</name>
			<section anchor="media-type" numbered="true" toc="include" removeInRFC="fa
			lse" pn="section-6.1">
			<name slugifiedName="name-media-type">Media Type</name>
			<t pn="section-6.1-1">Media types are registered in the "Media Types" re
			gistry
			<xref target="IANA-MEDIA-TYPES" format="default" sectionFormat="of" deriv
			edContent="IANA-MEDIA-TYPES"/>.
	</section>		IANA has registered the media type for CBOR Sequence,
	<section anchor="iana-considerations" title="IANA Considerations">
	<section anchor="media-type" title="Media Type">
	<t>Media types are registered in the media types registry <xref target="IANA.med
	ia-types"/>.
	IANA is requested to register the MIME media type for CBOR Sequence,
	application/cbor-seq, as follows:</t>		application/cbor-seq, as follows:</t>
			<t pn="section-6.1-2">Type name: application</t>
	<t>Type name: application</t>		<t pn="section-6.1-3">Subtype name: cbor-seq</t>
			<t pn="section-6.1-4">Required parameters: N/A</t>
	<t>Subtype name: cbor-seq</t>		<t pn="section-6.1-5">Optional parameters: N/A</t>
			<t pn="section-6.1-6">Encoding considerations: binary</t>
	<t>Required parameters: N/A</t>		<t pn="section-6.1-7">Security considerations: See RFC 8742, <xref targe
			t="security-considerations" format="default" sectionFormat="of" derivedContent="
	<t>Optional parameters: N/A</t>		Section 5"/>.</t>
			<t pn="section-6.1-8">Interoperability considerations: Described herein.
	<t>Encoding considerations: binary</t>		</t>
			<t pn="section-6.1-9">Published specification: RFC 8742.</t>
	<t>Security considerations: See RFCthis, <xref target="security-considerations"/		<t pn="section-6.1-10">Applications that use this media type: Data seria
	>.</t>		lization and deserialization.</t>
			<t pn="section-6.1-11">Fragment identifier considerations: N/A</t>
	<t>Interoperability considerations: Described herein.</t>		<t pn="section-6.1-12">Additional information:</t>
			<ul spacing="normal" bare="false" empty="false" pn="section-6.1-13">
	<t>Published specification: RFCthis.</t>		<li pn="section-6.1-13.1">Deprecated alias names for this type: N/A</l
			i>
	<t>Applications that use this media type: Data serialization and deserialization		<li pn="section-6.1-13.2">Magic number(s): N/A</li>
	.</t>		<li pn="section-6.1-13.3">File extension(s): N/A</li>
			<li pn="section-6.1-13.4">Macintosh file type code(s): N/A</li>
	<t>Fragment identifier considerations: N/A</t>		</ul>
			<dl newline="false" spacing="normal" pn="section-6.1-14">
	<t>Additional information:</t>		<dt pn="section-6.1-14.1">Person &amp; email address to contact for fu
			rther information:</dt>
	<t><list style="symbols">		<dd pn="section-6.1-14.2">
	<t>Deprecated alias names for this type: N/A</t>		cbor@ietf.org</dd>
	<t>Magic number(s): N/A</t>		</dl>
	<t>File extension(s): N/A</t>		<t pn="section-6.1-15">Intended usage: COMMON</t>
	<t>Macintosh file type code(s): N/A</t>		<t pn="section-6.1-16">Author: Carsten Bormann (cabo@tzi.org)</t>
	</list></t>		<t pn="section-6.1-17">Change controller: IETF</t>
			</section>
	<t><list style="hanging">		<section anchor="coap-content-format-registration" numbered="true" toc="in
	<t hangText='Person &amp; email address to contact for further information:'>		clude" removeInRFC="false" pn="section-6.2">
	cbor@ietf.org</t>		<name slugifiedName="name-coap-content-format-registr">CoAP Content-Form
	</list></t>		at Registration</name>
			<t pn="section-6.2-1">IANA has assigned a CoAP Content-Format ID for the
	<t>Intended usage: COMMON</t>		media
			type "application/cbor-seq", within the "CoAP Content-Formats" subregistry
	<t>Author: Carsten Bormann (cabo@tzi.org)</t>		of the "Constrained RESTful Environments (CoRE) Parameters" registry
			<xref target="IANA-CORE-PARAMETERS" format="default" sectionFormat="of" derivedC
	<t>Change controller: IETF</t>		ontent="IANA-CORE-PARAMETERS"/>, from the "Expert Review" (0-255)
			range (<xref target="RFC8126" format="default" sectionFormat="of" derivedContent
	</section>		="RFC8126"/>). The assigned ID is shown in <xref target="tbl-coap-content-forma
	<section anchor="coap-content-format-registration" title="CoAP Content-Format Re		ts" format="default" sectionFormat="of" derivedContent="Table 1"/>.</t>
	gistration">		<table anchor="tbl-coap-content-formats" align="center" pn="table-1">
			<name slugifiedName="name-coap-content-format-id">CoAP Content-Format
	<t>IANA is requested to assign a CoAP Content-Format ID for the media		ID</name>
	type “application/cbor-seq”, in the CoAP Content-Formats subregistry		<thead>
	of the core-parameter registry		<tr>
	<xref target="IANA.core-parameters"/>, from the “Expert Review” (0-255)		<th align="left" colspan="1" rowspan="1">Media type</th>
	range. The assigned ID is shown in <xref target="tbl-coap-content-formats"/>.</		<th align="left" colspan="1" rowspan="1">Encoding</th>
	t>		<th align="left" colspan="1" rowspan="1">ID</th>
			<th align="left" colspan="1" rowspan="1">Reference</th>
	<texttable title="CoAP Content-Format ID" anchor="tbl-coap-content-formats">		</tr>
	<ttcol align='left'>Media type</ttcol>		</thead>
	<ttcol align='left'>Encoding</ttcol>		<tbody>
	<ttcol align='left'>ID</ttcol>		<tr>
	<ttcol align='left'>Reference</ttcol>		<td align="left" colspan="1" rowspan="1">application/cbor-seq</td>
	<c>application/cbor-seq</c>		<td align="left" colspan="1" rowspan="1">-</td>
	<c>-</c>		<td align="left" colspan="1" rowspan="1">63</td>
	<c>TBD63</c>		<td align="left" colspan="1" rowspan="1">RFC 8742</td>
	<c>RFCthis</c>		</tr>
	</texttable>		</tbody>
			</table>
	<t>RFC editor: Please replace TBD63 by the number actually assigned and		</section>
	delete this paragraph.</t>		<section anchor="structured-syntax-suffix" numbered="true" toc="include" r
			emoveInRFC="false" pn="section-6.3">
	</section>		<name slugifiedName="name-structured-syntax-suffix">Structured Syntax Su
	<section anchor="structured-syntax-suffix" title="Structured Syntax Suffix">		ffix</name>
			<t pn="section-6.3-1">Structured Syntax Suffixes are registered within t
	<t>Structured Syntax Suffixes are registered within the “Structured		he "Structured
	Syntax Suffix Registry” maintained at <xref target="IANA.media-type-structured-s		Syntax Suffix Registry" maintained at <xref target="IANA-STRUCTURED-SYNTAX-SUFFI
	uffix"/>. IANA is requested to		X" format="default" sectionFormat="of" derivedContent="IANA-STRUCTURED-SYNTAX-SU
	register the “+cbor-seq” structured syntax suffix in accordance with		FFIX"/>. IANA has
	<xref target="RFC6838"/>, as follows:</t>		registered the "+cbor-seq" structured syntax suffix in accordance with
			<xref target="RFC6838" format="default" sectionFormat="of" derivedContent="RFC68
	<t><list style='empty'>		38"/> as follows:</t>
	<t>Name: CBOR Sequence</t>		<ul empty="true" spacing="normal" bare="false" pn="section-6.3-2">
	</list></t>		<li pn="section-6.3-2.1">Name: CBOR Sequence</li>
			</ul>
	<t><list style='empty'>		<ul empty="true" spacing="normal" bare="false" pn="section-6.3-3">
	<t>+suffix: +cbor-seq</t>		<li pn="section-6.3-3.1">+suffix: +cbor-seq</li>
	</list></t>		</ul>
			<ul empty="true" spacing="normal" bare="false" pn="section-6.3-4">
	<t><list style='empty'>		<li pn="section-6.3-4.1">References: RFC 8742</li>
	<t>References: RFCthis</t>		</ul>
	</list></t>		<ul empty="true" spacing="normal" bare="false" pn="section-6.3-5">
			<li pn="section-6.3-5.1">Encoding considerations: binary</li>
	<t><list style='empty'>		</ul>
	<t>Encoding considerations: binary</t>		<ul empty="true" spacing="normal" bare="false" pn="section-6.3-6">
	</list></t>		<li pn="section-6.3-6.1">Fragment identifier considerations: The synta
			x and semantics of
	<t><list style='empty'>		fragment identifiers specified for +cbor-seq <bcp14>SHOULD</bcp14> be the same
	<t>Fragment identifier considerations: The syntax and semantics of		as that specified for "application/cbor-seq". (At the time of publication of t
	fragment identifiers specified for +cbor-seq SHOULD be as		his
	specified for “application/cbor-seq”. (At publication of this
	document, there is no fragment identification syntax defined for		document, there is no fragment identification syntax defined for
	“application/cbor-seq”.)</t>		"application/cbor-seq".)</li>
	</list></t>		</ul>
			<ul empty="true" spacing="normal" bare="false" pn="section-6.3-7">
	<t><list style='empty'>		<li pn="section-6.3-7.1">
	<t><list style='empty'>		<ul empty="true" spacing="normal" bare="false" pn="section-6.3-7.1.1
	<t>The syntax and semantics for fragment identifiers for a		">
	specific “xxx/yyy+cbor-seq” SHOULD be processed as follows:</t>		<li pn="section-6.3-7.1.1.1">The syntax and semantics for fragment
	</list></t>		identifiers for a
	</list></t>		specific "xxx/yyy+cbor-seq" <bcp14>SHOULD</bcp14> be processed as follows:</li>
			<li pn="section-6.3-7.1.1.2">
	<t><list style='empty'>		<ul spacing="normal" bare="false" empty="false" pn="section-6.3-
	<t><list style='empty'>		7.1.1.2.1">
	<t><list style='empty'>		<li pn="section-6.3-7.1.1.2.1.1">For cases defined in +cbor-se
	<t>For cases defined in +cbor-seq, where the fragment		q, if the fragment
	identifier resolves per the +cbor-seq rules, then process as		identifier resolves per the +cbor-seq rules, then process as
	specified in +cbor-seq.</t>		specified in +cbor-seq.</li>
	</list></t>		<li pn="section-6.3-7.1.1.2.1.2">For cases defined in +cbor-se
	</list></t>		q, if the fragment
	</list></t>
	<t><list style='empty'>
	<t><list style='empty'>
	<t><list style='empty'>
	<t>For cases defined in +cbor-seq, where the fragment
	identifier does not resolve per the +cbor-seq rules, then		identifier does not resolve per the +cbor-seq rules, then
	process as specified in “xxx/yyy+cbor-seq”.</t>		process as specified in "xxx/yyy+cbor-seq".</li>
	</list></t>		<li pn="section-6.3-7.1.1.2.1.3">For cases not defined in +cbo
	</list></t>		r-seq, process as
	</list></t>		specified in "xxx/yyy+cbor-seq".</li>
			</ul>
	<t><list style='empty'>		</li>
	<t><list style='empty'>		</ul>
	<t><list style='empty'>		</li>
	<t>For cases not defined in +cbor-seq, then process as		</ul>
	specified in “xxx/yyy+cbor-seq”.</t>		<ul empty="true" spacing="normal" bare="false" pn="section-6.3-8">
	</list></t>		<li pn="section-6.3-8.1">Interoperability considerations: n/a</li>
	</list></t>		</ul>
	</list></t>		<ul empty="true" spacing="normal" bare="false" pn="section-6.3-9">
			<li pn="section-6.3-9.1">Security considerations: See RFC 8742, <xref
	<t><list style='empty'>		target="security-considerations" format="default" sectionFormat="of" derivedCont
	<t>Interoperability considerations: n/a</t>		ent="Section 5"/></li>
	</list></t>		</ul>
			<ul empty="true" spacing="normal" bare="false" pn="section-6.3-10">
	<t><list style='empty'>		<li pn="section-6.3-10.1">Contact: CBOR WG mailing list (cbor@ietf.org
	<t>Security considerations: See RFCthis, <xref target="security-considerations		), or any IESG-designated successor.</li>
	"/></t>		</ul>
	</list></t>		<ul empty="true" spacing="normal" bare="false" pn="section-6.3-11">
			<li pn="section-6.3-11.1">Author/Change controller: IETF</li>
	<t><list style='empty'>		</ul>
	<t>Contact: CBOR WG mailing list (cbor@ietf.org), or any IESG-designated succe		</section>
	ssor.</t>		</section>
	</list></t>
	<t><list style='empty'>
	<t>Author/Change controller: IETF</t>
	</list></t>
	</section>
	</section>
	</middle>		</middle>
	<back>		<back>
			<references pn="section-7">
	<references title='Normative References'>		<name slugifiedName="name-references">References</name>
			<references pn="section-7.1">
	<reference anchor="RFC7049" target='https://www.rfc-editor.org/info/rfc7049'>		<name slugifiedName="name-normative-references">Normative References</na
	<front>		me>
	<title>Concise Binary Object Representation (CBOR)</title>		<reference anchor="IANA-CORE-PARAMETERS" target="https://www.iana.org/as
	<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></		signments/core-parameters" quoteTitle="true" derivedAnchor="IANA-CORE-PARAMETERS
	author>		">
	<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></		<front>
	author>		<title>Constrained RESTful Environments (CoRE) Parameters</title>
	<date year='2013' month='October' />		<author>
	<abstract><t>The Concise Binary Object Representation (CBOR) is a data format wh		<organization showOnFrontPage="true">IANA</organization>
	ose design goals include the possibility of extremely small code size, fairly sm		</author>
	all message size, and extensibility without the need for version negotiation. T		</front>
	hese design goals make it different from earlier binary serializations such as A		</reference>
	SN.1 and MessagePack.</t></abstract>		<reference anchor="IANA-MEDIA-TYPES" target="https://www.iana.org/assign
	</front>		ments/media-types" quoteTitle="true" derivedAnchor="IANA-MEDIA-TYPES">
	<seriesInfo name='RFC' value='7049'/>		<front>
	<seriesInfo name='DOI' value='10.17487/RFC7049'/>		<title>Media Types</title>
	</reference>		<author>
			<organization showOnFrontPage="true">IANA</organization>
	<reference anchor="IANA.media-type-structured-suffix" target='http://www.iana.or		</author>
	g/assignments/media-type-structured-suffix'>		</front>
	<front>		</reference>
	<title>Structured Syntax Suffix Registry</title>		<reference anchor="IANA-STRUCTURED-SYNTAX-SUFFIX" target="https://www.ia
	<author><organization>IANA</organization></author>		na.org/assignments/media-type-structured-suffix" quoteTitle="true" derivedAnchor
	<date/>		="IANA-STRUCTURED-SYNTAX-SUFFIX">
	</front>		<front>
	</reference>		<title>Structured Syntax Suffix Registry</title>
			<author>
	<reference anchor="IANA.core-parameters" target='http://www.iana.org/assignments		<organization showOnFrontPage="true">IANA</organization>
	/core-parameters'>		</author>
	<front>		</front>
	<title>Constrained RESTful Environments (CoRE) Parameters</title>		</reference>
	<author><organization>IANA</organization></author>		<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	<date/>		119" quoteTitle="true" derivedAnchor="RFC2119">
	</front>		<front>
	</reference>		<title>Key words for use in RFCs to Indicate Requirement Levels</tit
			le>
	<reference anchor="IANA.media-types" target='http://www.iana.org/assignments/med		<author initials="S." surname="Bradner" fullname="S. Bradner">
	ia-types'>		<organization showOnFrontPage="true"/>
	<front>		</author>
	<title>Media Types</title>		<date year="1997" month="March"/>
	<author><organization>IANA</organization></author>		<abstract>
	<date/>		<t>In many standards track documents several words are used to sig
	</front>		nify the requirements in the specification. These words are often capitalized.
	</reference>		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
	<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>		Community, and requests discussion and suggestions for improvements.</t>
	<front>		</abstract>
	<title>Key words for use in RFCs to Indicate Requirement Levels</title>		</front>
	<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></		<seriesInfo name="BCP" value="14"/>
	author>		<seriesInfo name="RFC" value="2119"/>
	<date year='1997' month='March' />		<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	<abstract><t>In many standards track documents several words are used to signify		</reference>
	the requirements in the specification. These words are often capitalized. This		<reference anchor="RFC7049" target="https://www.rfc-editor.org/info/rfc7
	document defines these words as they should be interpreted in IETF documents.		049" quoteTitle="true" derivedAnchor="RFC7049">
	This document specifies an Internet Best Current Practices for the Internet Comm		<front>
	unity, and requests discussion and suggestions for improvements.</t></abstract>		<title>Concise Binary Object Representation (CBOR)</title>
	</front>		<author initials="C." surname="Bormann" fullname="C. Bormann">
	<seriesInfo name='BCP' value='14'/>		<organization showOnFrontPage="true"/>
	<seriesInfo name='RFC' value='2119'/>		</author>
	<seriesInfo name='DOI' value='10.17487/RFC2119'/>		<author initials="P." surname="Hoffman" fullname="P. Hoffman">
	</reference>		<organization showOnFrontPage="true"/>
			</author>
	<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>		<date year="2013" month="October"/>
	<front>		<abstract>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>		<t>The Concise Binary Object Representation (CBOR) is a data forma
	<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth		t whose design goals include the possibility of extremely small code size, fairl
	or>		y small message size, and extensibility without the need for version negotiation
	<date year='2017' month='May' />		. These design goals make it different from earlier binary serializations such
	<abstract><t>RFC 2119 specifies common key words that may be used in protocol s		as ASN.1 and MessagePack.</t>
	pecifications. This document aims to reduce the ambiguity by clarifying that on		</abstract>
	ly UPPERCASE usage of the key words have the defined special meanings.</t></abs		</front>
	tract>		<seriesInfo name="RFC" value="7049"/>
	</front>		<seriesInfo name="DOI" value="10.17487/RFC7049"/>
	<seriesInfo name='BCP' value='14'/>		</reference>
	<seriesInfo name='RFC' value='8174'/>		<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
	<seriesInfo name='DOI' value='10.17487/RFC8174'/>		174" quoteTitle="true" derivedAnchor="RFC8174">
	</reference>		<front>
			<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	</references>		tle>
			<author initials="B." surname="Leiba" fullname="B. Leiba">
	<references title='Informative References'>		<organization showOnFrontPage="true"/>
			</author>
	<reference anchor="RFC6838" target='https://www.rfc-editor.org/info/rfc6838'>		<date year="2017" month="May"/>
	<front>		<abstract>
	<title>Media Type Specifications and Registration Procedures</title>		<t>RFC 2119 specifies common key words that may be used in protoco
	<author initials='N.' surname='Freed' fullname='N. Freed'><organization /></auth		l specifications. This document aims to reduce the ambiguity by clarifying tha
	or>		t only UPPERCASE usage of the key words have the defined special meanings.</t>
	<author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></		</abstract>
	author>		</front>
	<author initials='T.' surname='Hansen' fullname='T. Hansen'><organization /></au		<seriesInfo name="BCP" value="14"/>
	thor>		<seriesInfo name="RFC" value="8174"/>
	<date year='2013' month='January' />		<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	<abstract><t>This document defines procedures for the specification and registra		</reference>
	tion of media types for use in HTTP, MIME, and other Internet protocols. This m		</references>
	emo documents an Internet Best Current Practice.</t></abstract>		<references pn="section-7.2">
	</front>		<name slugifiedName="name-informative-references">Informative References
	<seriesInfo name='BCP' value='13'/>		</name>
	<seriesInfo name='RFC' value='6838'/>		<reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6
	<seriesInfo name='DOI' value='10.17487/RFC6838'/>		838" quoteTitle="true" derivedAnchor="RFC6838">
	</reference>		<front>
			<title>Media Type Specifications and Registration Procedures</title>
	<reference anchor="RFC7464" target='https://www.rfc-editor.org/info/rfc7464'>		<author initials="N." surname="Freed" fullname="N. Freed">
	<front>		<organization showOnFrontPage="true"/>
	<title>JavaScript Object Notation (JSON) Text Sequences</title>		</author>
	<author initials='N.' surname='Williams' fullname='N. Williams'><organization />		<author initials="J." surname="Klensin" fullname="J. Klensin">
	</author>		<organization showOnFrontPage="true"/>
	<date year='2015' month='February' />		</author>
	<abstract><t>This document describes the JavaScript Object Notation (JSON) text		<author initials="T." surname="Hansen" fullname="T. Hansen">
	sequence format and associated media type &quot;application/json-seq&quot;. A J		<organization showOnFrontPage="true"/>
	SON text sequence consists of any number of JSON texts, all encoded in UTF-8, ea		</author>
	ch prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII L		<date year="2013" month="January"/>
	ine Feed character (0x0A).</t></abstract>		<abstract>
	</front>		<t>This document defines procedures for the specification and regi
	<seriesInfo name='RFC' value='7464'/>		stration of media types for use in HTTP, MIME, and other Internet protocols. Th
	<seriesInfo name='DOI' value='10.17487/RFC7464'/>		is memo documents an Internet Best Current Practice.</t>
	</reference>		</abstract>
			</front>
	<reference anchor="RFC8259" target='https://www.rfc-editor.org/info/rfc8259'>		<seriesInfo name="BCP" value="13"/>
	<front>		<seriesInfo name="RFC" value="6838"/>
	<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>		<seriesInfo name="DOI" value="10.17487/RFC6838"/>
	<author initials='T.' surname='Bray' fullname='T. Bray' role='editor'><organizat		</reference>
	ion /></author>		<reference anchor="RFC7464" target="https://www.rfc-editor.org/info/rfc7
	<date year='2017' month='December' />		464" quoteTitle="true" derivedAnchor="RFC7464">
	<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, lan		<front>
	guage-independent data interchange format. It was derived from the ECMAScript P		<title>JavaScript Object Notation (JSON) Text Sequences</title>
	rogramming Language Standard. JSON defines a small set of formatting rules for		<author initials="N." surname="Williams" fullname="N. Williams">
	the portable representation of structured data.</t><t>This document removes inco		<organization showOnFrontPage="true"/>
	nsistencies with other specifications of JSON, repairs specification errors, and		</author>
	offers experience-based interoperability guidance.</t></abstract>		<date year="2015" month="February"/>
	</front>		<abstract>
	<seriesInfo name='STD' value='90'/>		<t>This document describes the JavaScript Object Notation (JSON) t
	<seriesInfo name='RFC' value='8259'/>		ext sequence format and associated media type "application/json-seq". A JSON te
	<seriesInfo name='DOI' value='10.17487/RFC8259'/>		xt sequence consists of any number of JSON texts, all encoded in UTF-8, each pre
	</reference>		fixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Fe
			ed character (0x0A).</t>
	<reference anchor="RFC8091" target='https://www.rfc-editor.org/info/rfc8091'>		</abstract>
	<front>		</front>
	<title>A Media Type Structured Syntax Suffix for JSON Text Sequences</title>		<seriesInfo name="RFC" value="7464"/>
	<author initials='E.' surname='Wilde' fullname='E. Wilde'><organization /></auth		<seriesInfo name="DOI" value="10.17487/RFC7464"/>
	or>		</reference>
	<date year='2017' month='February' />		<reference anchor="RFC8091" target="https://www.rfc-editor.org/info/rfc8
	<abstract><t>Structured syntax suffixes for media types allow other media types		091" quoteTitle="true" derivedAnchor="RFC8091">
	to build on them and make it explicit that they are built on an existing media t		<front>
	ype as their foundation. This specification defines and registers &quot;+json-s		<title>A Media Type Structured Syntax Suffix for JSON Text Sequences
	eq&quot; as a structured syntax suffix for JSON text sequences.</t></abstract>		</title>
	</front>		<author initials="E." surname="Wilde" fullname="E. Wilde">
	<seriesInfo name='RFC' value='8091'/>		<organization showOnFrontPage="true"/>
	<seriesInfo name='DOI' value='10.17487/RFC8091'/>		</author>
	</reference>		<date year="2017" month="February"/>
			<abstract>
	<reference anchor="RFC8152" target='https://www.rfc-editor.org/info/rfc8152'>		<t>Structured syntax suffixes for media types allow other media ty
	<front>		pes to build on them and make it explicit that they are built on an existing med
	<title>CBOR Object Signing and Encryption (COSE)</title>		ia type as their foundation. This specification defines and registers "+json-se
	<author initials='J.' surname='Schaad' fullname='J. Schaad'><organization /></au		q" as a structured syntax suffix for JSON text sequences.</t>
	thor>		</abstract>
	<date year='2017' month='July' />		</front>
	<abstract><t>Concise Binary Object Representation (CBOR) is a data format design		<seriesInfo name="RFC" value="8091"/>
	ed for small code size and small message size. There is a need for the ability		<seriesInfo name="DOI" value="10.17487/RFC8091"/>
	to have basic security services defined for this data format. This document defi		</reference>
	nes the CBOR Object Signing and Encryption (COSE) protocol. This specification		<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
	describes how to create and process signatures, message authentication codes, an		126" quoteTitle="true" derivedAnchor="RFC8126">
	d encryption using CBOR for serialization. This specification additionally desc		<front>
	ribes how to represent cryptographic keys using CBOR.</t></abstract>		<title>Guidelines for Writing an IANA Considerations Section in RFCs
	</front>		</title>
	<seriesInfo name='RFC' value='8152'/>		<author initials="M." surname="Cotton" fullname="M. Cotton">
	<seriesInfo name='DOI' value='10.17487/RFC8152'/>		<organization showOnFrontPage="true"/>
	</reference>		</author>
			<author initials="B." surname="Leiba" fullname="B. Leiba">
	<reference anchor="RFC8610" target='https://www.rfc-editor.org/info/rfc8610'>		<organization showOnFrontPage="true"/>
	<front>		</author>
	<title>Concise Data Definition Language (CDDL): A Notational Convention to Expre		<author initials="T." surname="Narten" fullname="T. Narten">
	ss Concise Binary Object Representation (CBOR) and JSON Data Structures</title>		<organization showOnFrontPage="true"/>
	<author initials='H.' surname='Birkholz' fullname='H. Birkholz'><organization />		</author>
	</author>		<date year="2017" month="June"/>
	<author initials='C.' surname='Vigano' fullname='C. Vigano'><organization /></au		<abstract>
	thor>		<t>Many protocols make use of points of extensibility that use con
	<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></		stants to identify various protocol parameters. To ensure that the values in th
	author>		ese fields do not have conflicting uses and to promote interoperability, their a
	<date year='2019' month='June' />		llocations are often coordinated by a central record keeper. For IETF protocols
	<abstract><t>This document proposes a notational convention to express Concise B		, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
	inary Object Representation (CBOR) data structures (RFC 7049). Its main goal is		<t>To make assignments in a given registry prudently, guidance des
	to provide an easy and unambiguous way to express structures for protocol messa		cribing the conditions under which new values should be assigned, as well as whe
	ges and data formats that use CBOR or JSON.</t></abstract>		n and how modifications to existing values can be made, is needed. This documen
	</front>		t defines a framework for the documentation of these guidelines by specification
	<seriesInfo name='RFC' value='8610'/>		authors, in order to assure that the provided guidance for the IANA Considerati
	<seriesInfo name='DOI' value='10.17487/RFC8610'/>		ons is clear and addresses the various issues that are likely in the operation o
	</reference>		f a registry.</t>
			<t>This is the third edition of this document; it obsoletes RFC 52
			26.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="26"/>
			<seriesInfo name="RFC" value="8126"/>
			<seriesInfo name="DOI" value="10.17487/RFC8126"/>
			</reference>
			<reference anchor="RFC8152" target="https://www.rfc-editor.org/info/rfc8
			152" quoteTitle="true" derivedAnchor="RFC8152">
			<front>
			<title>CBOR Object Signing and Encryption (COSE)</title>
			<author initials="J." surname="Schaad" fullname="J. Schaad">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2017" month="July"/>
			<abstract>
			<t>Concise Binary Object Representation (CBOR) is a data format de
			signed for small code size and small message size. There is a need for the abil
			ity to have basic security services defined for this data format. This document
			defines the CBOR Object Signing and Encryption (COSE) protocol. This specificat
			ion describes how to create and process signatures, message authentication codes
			, and encryption using CBOR for serialization. This specification additionally
			describes how to represent cryptographic keys using CBOR.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8152"/>
			<seriesInfo name="DOI" value="10.17487/RFC8152"/>
			</reference>
			<reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8
			259" 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 ECMAScri
			pt 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 interoperabi
			lity guidance.</t>
			</abstract>
			</front>
			<seriesInfo name="STD" value="90"/>
			<seriesInfo name="RFC" value="8259"/>
			<seriesInfo name="DOI" value="10.17487/RFC8259"/>
			</reference>
			<reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8
			610" quoteTitle="true" derivedAnchor="RFC8610">
			<front>
			<title>Concise Data Definition Language (CDDL): A Notational Convent
			ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
			res</title>
			<author initials="H." surname="Birkholz" fullname="H. Birkholz">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="C." surname="Vigano" fullname="C. Vigano">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="C." surname="Bormann" fullname="C. Bormann">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2019" month="June"/>
			<abstract>
			<t>This document proposes a notational convention to express Conci
			se Binary Object Representation (CBOR) data structures (RFC 7049). Its main goa
			l is to provide an easy and unambiguous way to express structures for protocol m
			essages and data formats that use CBOR or JSON.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8610"/>
			<seriesInfo name="DOI" value="10.17487/RFC8610"/>
			</reference>
			</references>
	</references>		</references>
			<section numbered="false" anchor="acknowledgements" toc="include" removeInRF
	<section numbered="no" anchor="acknowledgements" title="Acknowledgements">		C="false" pn="section-appendix.a">
			<name slugifiedName="name-acknowledgements">Acknowledgements</name>
	<t>This draft has mostly been generated from <xref target="RFC7464"/> by Nico Wi		<t pn="section-appendix.a-1">This document has mostly been generated from
	lliams		<xref target="RFC7464" format="default" sectionFormat="of" derivedContent="RFC74
	and <xref target="RFC8091"/> by Erik Wilde, which do a similar, but slightly mor		64"/> by <contact fullname="Nico Williams"/>
	e		and <xref target="RFC8091" format="default" sectionFormat="of" derivedContent="R
	complicated exercise for JSON <xref target="RFC8259"/>. Laurence Lundblade rais		FC8091"/> by <contact fullname="Erik Wilde"/>, which do a similar but slightly m
	ed an		ore
			complicated exercise for JSON <xref target="RFC8259" format="default" sectionFor
			mat="of" derivedContent="RFC8259"/>. <contact fullname="Laurence Lundblade"/> r
			aised an
	issue on the CBOR mailing list that pointed out the need for this		issue on the CBOR mailing list that pointed out the need for this
	document. Jim Schaad and John Mattsson provided helpful comments.</t>		document. <contact fullname="Jim Schaad"/> and <contact fullname="John Mattsson
			"/> provided helpful comments.</t>
	</section>		</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">Uni
			versitä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>		</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>		</rfc>
End of changes. 40 change blocks.
	703 lines changed or deleted		860 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/