rfc9237.original.xml		rfc9237.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.6 (Ruby 3		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" xml:lang="en" ipr="trust200902"
	.1.1) -->		docName="draft-ietf-ace-aif-07" number="9237" submissionType="IETF" category="st
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft		d" consensus="true" tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true
	-ietf-ace-aif-07" category="std" consensus="true" submissionType="IETF" tocDepth		" updates=""
	="4" tocInclude="true" sortRefs="true" symRefs="true" version="3">		obsoletes="" version="3">
	<!-- xml2rfc v2v3 conversion 3.12.1 -->
			<!-- xml2rfc v2v3 conversion 3.12.1 -->
	<front>		<front>
	<title abbrev="ACE AIF">An Authorization Information Format (AIF) for ACE</t		<title abbrev="ACE AIF">An Authorization Information Format (AIF) for Authen
	itle>		tication and Authorization for Constrained Environments (ACE)</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-ace-aif-07"/>		<seriesInfo name="RFC" value="9237"/>
	<author initials="C." surname="Bormann" fullname="Carsten Bormann">		<author initials="C." surname="Bormann" fullname="Carsten Bormann">
	<organization>Universität Bremen TZI</organization>		<organization>Universität Bremen TZI</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Postfach 330440</street>		<street>Postfach 330440</street>
	<city>Bremen</city>		<city>Bremen</city>
	<code>D-28359</code>		<code>D-28359</code>
	<country>Germany</country>		<country>Germany</country>
	</postal>		</postal>
	<phone>+49-421-218-63921</phone>		<phone>+49-421-218-63921</phone>
	<email>cabo@tzi.org</email>		<email>cabo@tzi.org</email>
	</address>		</address>
	</author>		</author>
	<date year="2022" month="March" day="15"/>		<date year="2022" month="August"/>
	<area>Internet</area>		<area>sec</area>
	<workgroup>ACE Working Group</workgroup>		<workgroup>ACE</workgroup>
	<keyword>Internet-Draft</keyword>
	<abstract>		<abstract>
	<t>Information about which entities are authorized to perform what		<t>Information about which entities are authorized to perform what
	operations on which constituents of other entities is a crucial		operations on which constituents of other entities is a crucial
	component of producing an overall system that is secure. Conveying		component of producing an overall system that is secure. Conveying
	precise authorization information is especially critical in highly		precise authorization information is especially critical in highly
	automated systems with large numbers of entities, such as the		automated systems with large numbers of entities, such as the
	"Internet of Things".</t>		Internet of Things.</t>
	<t>This specification provides a generic information model and format for		<t>This specification provides a generic information model and format for
	representing such authorization information, as well as two variants		representing such authorization information, as well as two variants
	of a specific instantiation of that format for use with REST resources		of a specific instantiation of that format for use with Representational State T ransfer (REST) resources
	identified by URI path.</t>		identified by URI path.</t>
	</abstract>		</abstract>
	<note removeInRFC="true">
	<name>About This Document</name>
	<t>
	Status information for this document may be found at <eref target="https
	://datatracker.ietf.org/doc/draft-ietf-ace-aif/"/>.
	</t>
	<t>
	Discussion of this document takes place on the
	Authentication and Authorization for Constrained Environments (ace) Work
	ing Group mailing list (<eref target="mailto:ace@ietf.org"/>),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
	wse/ace/"/>.
	</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/cabo/ace-aif"/>.</t>
	</note>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction">		<section anchor="introduction">
	<name>Introduction</name>		<name>Introduction</name>
	<t>Constrained Devices as they are used in the "Internet of Things" need		<t>Constrained devices, as they are used in the Internet of Things, need
	security in order to operate correctly and prevent misuse.		security in order to operate correctly and prevent misuse.
	One important element of this security is that devices in the Internet		One important element of this security is that devices in the Internet
	of Things need to be able to decide which operations requested of them		of Things need to be able to decide which operations requested of them
	should be considered authorized, need to ascertain that the		should be considered authorized, ascertain that the
	authorization to request the operation does apply to the actual		authorization to request the operation does apply to the actual
	requester as authenticated,		requester as authenticated,
	and need to ascertain that other devices they make		and ascertain that other devices they make
	requests of are the ones they intended.</t>		requests of are the ones they intended.</t>
	<t>To transfer detailed authorization information from an authorization ma nager		<t>To transfer detailed authorization information from an authorization ma nager
	(such as an ACE-OAuth Authorization Server <xref target="I-D.ietf-ace-oauth-auth z"/>) to a device, a		(such as an ACE-OAuth authorization server <xref target="RFC9200"/>) to a device , a
	compact representation format is needed.		compact representation format is needed.
	This document defines such a format, the		This document defines such a format -- the
	Authorization Information Format (AIF).		Authorization Information Format (AIF).
	AIF is defined both as a general structure that can be used for many		AIF is defined both as a general structure that can be used for many
	different applications and		different applications and
	as a specific instantiation tailored to REST resources and the permissions		as a specific instantiation tailored to REST resources and the permissions
	on them, including some provision for dynamically created resources.</t>		on them, including some provision for dynamically created resources.</t>
	<section anchor="terminology">		<section anchor="terminology">
	<name>Terminology</name>		<name>Terminology</name>
	<t>This memo uses terms from CoAP <xref target="RFC7252"/> and the Inter
	net Security Glossary <xref target="RFC4949"/>; CoAP is used for		<t>This memo uses terms from the Constrained Application Protocol (CoAP)
	the explanatory examples as it is a good fit for Constrained Devices.</t>		<xref target="RFC7252"/> and the Internet Security Glossary <xref target="RFC494
	<t>The shape of data is specified in CDDL <xref target="RFC8610"/> <xref		9"/>; CoAP is used for
	target="RFC9165"/>.		the explanatory examples as it is a good fit for constrained devices.</t>
	Terminology for Constrained Devices is defined in <xref target="RFC7228"/>.</t>		<t>The shape of data is specified in Concise Data Definition Language (C
	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp		DDL) <xref target="RFC8610"/> <xref target="RFC9165"/>.
	14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL		Terminology for constrained devices is defined in <xref target="RFC7228"/>.</t>
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO		<t>The term "byte", abbreviated by "B", is used in its now customary
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
	nterpreted as
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
	only when, they
	appear in all capitals, as shown here.</t>
	<t>The term "byte", abbreviated by "B", is used in its now customary
	sense as a synonym for "octet".</t>		sense as a synonym for "octet".</t>
			<t>
			The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be
			interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
			target="RFC8174"/> when, and only when, they appear in all capitals, as shown
			here.
			</t>
	</section>		</section>
	</section>		</section>
	<section anchor="information-model">		<section anchor="information-model">
	<name>Information Model</name>		<name>Information Model</name>
	<t>Authorizations are generally expressed through some data structures		<t>Authorizations are generally expressed through some data structures
	that are cryptographically secured (or transmitted in a secure way).		that are cryptographically secured (or transmitted in a secure way).
	This section discusses the information model underlying the payload of		This section discusses the information model underlying the payload of
	that data (as opposed to the cryptographic armor around it).</t>		that data (as opposed to the cryptographic armor around it).</t>
	<t>The semantics of the authorization information defined in this		<t>The semantics of the authorization information defined in this
	document are that of an <em>allow-list</em>:		document are that of an <em>allow-list</em>:
	everything is denied until it is explicitly allowed.</t>		everything is denied until it is explicitly allowed.</t>
	<t>For the purposes of this specification, the underlying access control m odel		<t>For the purposes of this specification, the underlying access control m odel
	will be that of an access matrix, which gives a set of permissions for		will be that of an access matrix, which gives a set of permissions for
	each possible combination of a subject and an object.		each possible combination of a subject and an object.
	We are focusing the AIF data item on a single row in the access matrix		We are focusing the AIF data item on a single row in the access matrix
	(such a row has often been called a capability list), without		(such a row has often been called a "capability list") without
	concern to the subject for which the data item is issued.		concern to the subject for which the data item is issued.
	As a consequence, AIF <bcp14>MUST</bcp14> be used in a way that the subject of t he		As a consequence, AIF <bcp14>MUST</bcp14> be used in a way that the subject of t he
	authorizations is unambiguously identified (e.g., as part of the armor		authorizations is unambiguously identified (e.g., as part of the armor
	around it).</t>		around it).</t>
	<t>The generic model of such a capability list is a list of pairs of		<t>The generic model of such a capability list is a list of pairs of
	object identifiers (of type <tt>Toid</tt>) and the permissions (of type <tt>Tper m</tt>) the subject has on the		object identifiers (of type <tt>Toid</tt>) and the permissions (of type <tt>Tper m</tt>) that the subject has on the
	object(s) identified.</t>		object(s) identified.</t>
	<figure anchor="genaif">		<figure anchor="genaif">
	<name>Definition of Generic AIF</name>		<name>Definition of Generic AIF</name>
	<sourcecode type="cddl"><![CDATA[		<sourcecode type="cddl"><![CDATA[
	AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]]		AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]]
	]]></sourcecode>		]]></sourcecode>
	</figure>		</figure>
	<t>In a specific data model (such as the one also specified in		<t>In a specific data model (such as the one specified in
	this document), the object identifier (<tt>Toid</tt>) will often be		this document), the object identifier (<tt>Toid</tt>) will often be
	a text string, and the set of permissions (<tt>Tperm</tt>) will be represented		a text string, and the set of permissions (<tt>Tperm</tt>) will be represented
	by a bitset in turn represented as a number (see <xref target="data-model"/>).</ t>		by a bit set, which in turn is represented as a number (see <xref target="data-m odel"/>).</t>
	<figure anchor="specaif">		<figure anchor="specaif">
	<name>Commonly used shape of a specific AIF</name>		<name>Commonly Used Shape of a Specific AIF</name>
	<sourcecode type="cddl"><![CDATA[		<sourcecode type="cddl"><![CDATA[
	AIF-Specific = AIF-Generic<tstr, uint>		AIF-Specific = AIF-Generic<tstr, uint>
	]]></sourcecode>		]]></sourcecode>
	</figure>		</figure>
	<section anchor="rest-model">		<section anchor="rest-model">
	<name>REST-specific Model</name>		<name>REST-Specific Model</name>
	<t>In the specific instantiation of the REST resources and the		<t>In the specific instantiation of the REST resources and the
	permissions on them, for the object identifiers (<tt>Toid</tt>), we		permissions on them, we use the URI of a resource on a CoAP server for
	use the URI of a resource on a CoAP server. More specifically, since the		the object identifier (<tt>Toid</tt>). More specifically, since the
	parts of the URI that identify the server ("authority" in		parts of the URI that identify the server ("authority" in <xref
	<xref target="RFC3986"/>) are what are authenticated during REST resource access		target="RFC3986"/>) are authenticated during REST resource access (<xref
	(<xref section="4.2.2" sectionFormat="of" target="I-D.ietf-httpbis-semantics"/>		section="4.2.2" sectionFormat="of" target="RFC9110"/> and <xref
	and <xref section="6.2" sectionFormat="of" target="RFC7252"/>), they		section="6.2" sectionFormat="of" target="RFC7252"/>), they naturally
	naturally fall into the realm handled by the cryptographic armor; we therefore f		fall into the realm handled by the cryptographic armor; we therefore
	ocus on		focus on the "path" ("path-abempty") and "query" parts of the URI
	the "path" ("path-abempty") and "query" parts of the URI (<em>URI-local-part</em		(<em>URI-local-part</em> in this specification, as expressed by the
	> in		Uri-Path and Uri-Query options in CoAP).
	this specification, as expressed by the Uri-Path and Uri-Query options		As a consequence, AIF <bcp14>MUST</bcp14> be used in a way that it is clear
	in CoAP). As a consequence, AIF <bcp14>MUST</bcp14> be used in a way that it is		who is the target (enforcement point) of these authorizations
	clear who is the target (enforcement point) of these authorizations
	(note that there may be more than one target that the same		(note that there may be more than one target that the same
	authorization applies to, e.g., in a situation with homogeneous		authorization applies to, e.g., in a situation with homogeneous
	devices).</t>		devices).</t>
	<t>For the permissions (<tt>Tperm</tt>), we use a simple permissions mod el that		<t>For the permissions (<tt>Tperm</tt>), we use a simple permissions mod el that
	lists the subset of the REST (CoAP or HTTP) methods permitted.		lists the subset of the REST (CoAP or HTTP) methods permitted.
	This model is summarized in <xref target="im-example"/>.</t>		This model is summarized in <xref target="im-example"/>.</t>
	<table anchor="im-example">		<table anchor="im-example">
	<name>An authorization instance in the AIF Information Model</name>		<name>An Authorization Instance in the REST-Specific AIF Information M
			odel</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">URI-local-part</th>		<th align="left">URI-local-part</th>
	<th align="left">Permission Set</th>		<th align="left">Permission Set</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">/s/temp</td>		<td align="left">/s/temp</td>
	<td align="left">GET</td>		<td align="left">GET</td>
	skipping to change at line 175 ¶		skipping to change at line 173 ¶
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">/dtls</td>		<td align="left">/dtls</td>
	<td align="left">POST</td>		<td align="left">POST</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>In this example, a device offers a temperature sensor <tt>/s/temp</tt > for		<t>In this example, a device offers a temperature sensor <tt>/s/temp</tt > for
	read-only access, a LED actuator <tt>/a/led</tt> for read/write, and a		read-only access, a LED actuator <tt>/a/led</tt> for read/write, and a
	<tt>/dtls</tt> resource for POST access.</t>		<tt>/dtls</tt> resource for POST access.</t>
	<t>As will be seen in the data model (<xref target="data-model"/>), the representations		<t>As shown in the data model (<xref target="data-model"/>), the represe ntations
	of REST methods provided are limited to those that have a CoAP method		of REST methods provided are limited to those that have a CoAP method
	number assigned; an extension to the model may be necessary to represent		number assigned; an extension to the model may be necessary to represent
	permissions for exotic HTTP methods.</t>		permissions for exotic HTTP methods.</t>
	</section>		</section>
	<section anchor="limitations">		<section anchor="limitations">
	<name>Limitations</name>		<name>Limitations</name>
	<t>This simple information model only allows granting permissions for		<t>This simple information model only allows granting permissions for
	statically identifiable objects, e.g., URIs for the REST-specific		statically identifiable objects, e.g., URIs for the REST-specific
	instantiation. One might be tempted to extend the model towards URI		instantiation. One might be tempted to extend the model towards URI
	templates <xref target="RFC6570"/> (for instance, to open up an		templates <xref target="RFC6570"/> (for instance, to open up an
	authorization for many parameter values as in		authorization for many parameter values as in
	<tt>/s/temp{?any*}</tt>).		<tt>/s/temp{?any*}</tt>).
	However, that requires some considerations of		However, that requires some considerations of
	the ease and unambiguity of matching a given URI against a set of		the ease and unambiguity of matching a given URI against a set of
	templates in an AIF data item.</t>		templates in an AIF data item.</t>
	<t>This simple information model also does not allow expressing		<t>This simple information model also does not allow expressing
	conditionalized access based on state outside the identification of		conditionalized access based on state outside the identification of
	objects (e.g., "opening a door is allowed if that is not locked").</t>		objects (e.g., "opening a door is allowed if it is not locked").</t>
	<t>Finally, the model does not provide any special access for a set of		<t>Finally, the model does not provide any special access for a set of
	resources that are specific to a subject, e.g., that the subject		resources that are specific to a subject, e.g., that the subject
	created itself by previous operations (PUT, POST, or PATCH/iPATCH <xref target=" RFC8132"/>) or that were		created itself by previous operations (PUT, POST, or PATCH/iPATCH <xref target=" RFC8132"/>) or that were
	specifically created for the subject by others.</t>		specifically created for the subject by others.</t>
	</section>		</section>
	<section anchor="ext-rest-model">		<section anchor="ext-rest-model">
	<name>REST-specific Model With Dynamic Resource Creation</name>		<name>REST-Specific Model with Dynamic Resource Creation</name>
	<t>The REST-specific Model With Dynamic Resource Creation addresses the		<t>The <em>REST-specific model with dynamic resource creation</em> addre
	need to provide defined		sses
	access to dynamic resources that were created by the subject itself,		the need to provide defined access to dynamic resources that were
	specifically, a resource that is made known to the subject by		created by the subject itself, specifically, a resource that is made
	providing Location-* options in a CoAP response or using the Location		known to the subject by providing Location-* options in a CoAP
	header field in HTTP <xref target="I-D.ietf-httpbis-semantics"/> (the Location-i		response or using the Location header field in HTTP <xref
	ndicating mechanisms).		target="RFC9110"/> (the Location-indicating mechanisms). (The concept
	(The concept is somewhat comparable to "ACL inheritance" in NFSv4		is somewhat comparable to "Access Control List (ACL) inheritance" in
	<xref target="RFC8881"/>, except that it does not use a containment relationship		the Network File System version 4 (NFSv4) protocol <xref
	but the fact that the dynamic resource was created from a resource to		target="RFC8881"/>, except that it does not use a containment
	which the subject had access.)		relationship but rather the fact that the dynamic resource was created
	In other words, it addresses an important subset of the third		from a resource to which the subject had access.) In other words, it
	limitation mentioned in <xref target="limitations"/>.</t>		addresses an important subset of the third limitation mentioned in
			<xref target="limitations"/>.</t>
	<table anchor="im-example-dynamic">		<table anchor="im-example-dynamic">
	<name>An authorization instance in the AIF Information Model With Dyna mic Resource Creation</name>		<name>An Authorization Instance in the REST-Specific AIF Information M odel with Dynamic Resource Creation</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">URI-local-part</th>		<th align="left">URI-local-part</th>
	<th align="left">Permission Set</th>		<th align="left">Permission Set</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">/a/make-coffee</td>		<td align="left">/a/make-coffee</td>
	<td align="left">POST, Dynamic-GET, Dynamic-DELETE</td>		<td align="left">POST, Dynamic-GET, Dynamic-DELETE</td>
	skipping to change at line 249 ¶		skipping to change at line 248 ¶
	another explicit switch between the basic and the model extended by		another explicit switch between the basic and the model extended by
	dynamic resource creation; the		dynamic resource creation; the
	extended model is always presumed once a Dynamic-X permission is present.</t>		extended model is always presumed once a Dynamic-X permission is present.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="data-model">		<section anchor="data-model">
	<name>Data Model</name>		<name>Data Model</name>
	<t>Different data model specializations can be defined for the generic		<t>Different data model specializations can be defined for the generic
	information model given above.</t>		information model given above.</t>
	<t>In this section, we will give the data model for simple REST		<t>In this section, we will give the data model for simple REST
	authorization as per <xref target="rest-model"/> and <xref target="ext-rest-mode l"/>.		authorization as per Sections <xref target="rest-model" format="counter"/> and < xref target="ext-rest-model" format="counter"/>.
	As discussed, in this case the object identifier is specialized as a text string		As discussed, in this case the object identifier is specialized as a text string
	giving a relative URI (URI-local-part as absolute path on the server		giving a relative URI (URI-local-part as the absolute path on the server
	serving as enforcement point).		serving as the enforcement point).
	The permission set is specialized to a single number <tt>REST-method-set</tt> by		The permission set is specialized to a single number <em>REST-method-set</em> by
	the following steps:</t>		the following steps:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The entries in the table that specify the same URI-local-part are me rged		<li>The entries in the table that specify the same URI-local-part are me rged
	into a single entry that specifies the union of the permission sets.</li>		into a single entry that specifies the union of the permission sets.</li>
	<li>The (non-dynamic) methods in the permission sets are converted into		<li>The (non-dynamic) methods in the permission sets are converted into
	their CoAP method numbers, minus 1.</li>		their CoAP method numbers, minus 1.</li>
	<li>Dynamic-X permissions are converted into what the number would have		<li>Dynamic-X permissions are converted into what the number would
	been for X, plus a Dynamic-Offset chosen as 32 (e.g., 35 is the		have been for X, plus a Dynamic-Offset that has been chosen as 32 (e.g., 35 is
	number for Dynamic-DELETE as the number for DELETE is 3).</li>		the number for Dynamic-DELETE as the number for DELETE is 3).
	<li>The set of numbers is converted into a single number <tt>REST-method		</li>
	-set</tt> by taking two to the		<li>The set of numbers is converted into a single number REST-method-set
			by taking two to the
	power of each (decremented) method number and computing the inclusive OR of the		power of each (decremented) method number and computing the inclusive OR of the
	binary representations of all the power values.</li>		binary representations of all the power values.</li>
	</ul>		</ul>
	<t>This data model could be interchanged in the JSON		<t>This data model could be interchanged in the JSON
	<xref target="RFC8259"/> representation given in <xref target="dm-json"/>.</t>		<xref target="RFC8259"/> representation given in <xref target="dm-json"/>.</t>
	<figure anchor="dm-json">		<figure anchor="dm-json">
	<name>An authorization instance encoded in JSON (40 bytes)</name>		<name>An Authorization Instance Encoded in JSON (40 Bytes)</name>
	<sourcecode type="json"><![CDATA[		<sourcecode type="json"><![CDATA[
	[["/s/temp",1],["/a/led",5],["/dtls",2]]		[["/s/temp",1],["/a/led",5],["/dtls",2]]
	]]></sourcecode>		]]></sourcecode>
	</figure>		</figure>
	<t>In <xref target="aif-cddl"/>, a straightforward specification of the da ta model		<t>In <xref target="aif-cddl"/>, a straightforward specification of the da ta model
	(including both the methods from <xref target="RFC7252"/> and the new ones from		(including both the methods from <xref target="RFC7252"/> and the new ones from
	<xref target="RFC8132"/>, identified by the method code minus 1) is shown in CDD L		<xref target="RFC8132"/>, identified by the method code minus 1) is shown in CDD L
	<xref target="RFC8610"/> <xref target="RFC9165"/>:</t>		<xref target="RFC8610"/> <xref target="RFC9165"/>:</t>
	<figure anchor="aif-cddl">		<figure anchor="aif-cddl">
	<name>AIF in CDDL</name>		<name>AIF in CDDL</name>
	skipping to change at line 300 ¶		skipping to change at line 300 ¶
	PATCH: 5		PATCH: 5
	iPATCH: 6		iPATCH: 6
	Dynamic-GET: 32; 0 .plus Dynamic-Offset		Dynamic-GET: 32; 0 .plus Dynamic-Offset
	Dynamic-POST: 33; 1 .plus Dynamic-Offset		Dynamic-POST: 33; 1 .plus Dynamic-Offset
	Dynamic-PUT: 34; 2 .plus Dynamic-Offset		Dynamic-PUT: 34; 2 .plus Dynamic-Offset
	Dynamic-DELETE: 35; 3 .plus Dynamic-Offset		Dynamic-DELETE: 35; 3 .plus Dynamic-Offset
	Dynamic-FETCH: 36; 4 .plus Dynamic-Offset		Dynamic-FETCH: 36; 4 .plus Dynamic-Offset
	Dynamic-PATCH: 37; 5 .plus Dynamic-Offset		Dynamic-PATCH: 37; 5 .plus Dynamic-Offset
	Dynamic-iPATCH: 38; 6 .plus Dynamic-Offset		Dynamic-iPATCH: 38; 6 .plus Dynamic-Offset
	)		)
			Dynamic-Offset = 32
	]]></sourcecode>		]]></sourcecode>
	</figure>		</figure>
	<t>For the information shown in <xref target="im-example"/> and <xref targ et="dm-json"/>, a		<t>For the information shown in <xref target="im-example"/> and <xref targ et="dm-json"/>, a
	representation in CBOR <xref target="RFC8949"/> is given in <xref target="dm-cbo		representation in Concise Binary Object Representation (CBOR) <xref target="RFC8
	r"/>; again,		949"/> is given in <xref target="dm-cbor"/>; again,
	several optimizations/improvements are possible.</t>		several optimizations and improvements are possible.</t>
	<figure anchor="dm-cbor">		<figure anchor="dm-cbor">
	<name>An authorization instance encoded in CBOR (28 bytes)</name>		<name>An Authorization Instance Encoded in CBOR (28 Bytes)</name>
	<artwork type="hex-dump"><![CDATA[		<artwork><![CDATA[
	83 # array(3)		83 # array(3)
	82 # array(2)		82 # array(2)
	67 # text(7)		67 # text(7)
	2f732f74656d70 # "/s/temp"		2f732f74656d70 # "/s/temp"
	01 # unsigned(1)		01 # unsigned(1)
	82 # array(2)		82 # array(2)
	66 # text(6)		66 # text(6)
	2f612f6c6564 # "/a/led"		2f612f6c6564 # "/a/led"
	05 # unsigned(5)		05 # unsigned(5)
	82 # array(2)		82 # array(2)
	65 # text(5)		65 # text(5)
	2f64746c73 # "/dtls"		2f64746c73 # "/dtls"
	02 # unsigned(2)		02 # unsigned(2)
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>Note that choosing 32 as Dynamic-Offset means that all future CoAP		<t>Note that having chosen 32 as Dynamic-Offset means that all future CoAP
	methods that can be registered can be represented both as themselves		methods that are registered can be represented both as themselves
	and in the Dynamic-X variant, but only the dynamic forms of methods 1		and in the Dynamic-X variant, but that only the dynamic forms of methods 1
	to 21 are typically usable in a JSON form <xref target="RFC7493"/>.</t>		to 21 are typically usable in a JSON form <xref target="RFC7493"/>.</t>
	</section>		</section>
	<section anchor="media-types">		<section anchor="media-types">
	<name>Media Types</name>		<name>Media Types</name>
	<t>This specification defines media types for the generic information		<t>This specification defines media types for the generic information
	model, expressed in JSON (<tt>application/aif+json</tt>) or in CBOR (<tt>applica tion/aif+cbor</tt>). These media types have		model, expressed in JSON (application/aif+json) or in CBOR (application/aif+cbor ). These media types have
	parameters for specifying <tt>Toid</tt> and <tt>Tperm</tt>; default values are t he		parameters for specifying <tt>Toid</tt> and <tt>Tperm</tt>; default values are t he
	values "URI-local-part" for <tt>Toid</tt> and "REST-method-set" for <tt>Tperm</t t>, as		values "URI-local-part" for <tt>Toid</tt> and "REST-method-set" for <tt>Tperm</t t>, as
	per <xref target="data-model"/> of the present specification.</t>		per <xref target="data-model"/> of the present specification.</t>
	<t>A specification that wants to use Generic AIF with different <tt>Toid</ tt>		<t>A specification that wants to use generic AIF with different <tt>Toid</ tt>
	and/or <tt>Tperm</tt> is expected to request these as media type parameters		and/or <tt>Tperm</tt> is expected to request these as media type parameters
	(<xref target="registries"/>) and register a corresponding Content-Format (<xref target="content-format"/>).</t>		(<xref target="registries"/>) and register a corresponding Content-Format (<xref target="content-format"/>).</t>
	</section>		</section>
	<section anchor="iana-considerations">		<section anchor="iana-considerations">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t><cref anchor="replace-xxxx">RFC Ed.: throughout this section, please re
	place RFC
	XXXX with the RFC number of this specification and remove this note.</cref></t
	>
	<section anchor="media-types-1">		<section anchor="media-types-1">
	<name>Media Types</name>		<name>Media Types</name>
	<t>IANA is requested to add the following Media-Types to the "Media Type s" registry.</t>		<t>IANA has added the following media types to the "Media Types" registr y. The registration entries are in the following subsections.</t>
	<table align="left">		<table align="left">
	<name>New Media Types</name>		<name>New Media Types</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Name</th>		<th align="left">Name</th>
	<th align="left">Template</th>		<th align="left">Template</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">aif+cbor</td>		<td align="left">aif+cbor</td>
	<td align="left">application/aif+cbor</td>		<td align="left">application/aif+cbor</td>
	<td align="left">RFC XXXX, <xref target="media-types"/></td>		<td align="left">RFC 9237, <xref target="media-types"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">aif+json</td>		<td align="left">aif+json</td>
	<td align="left">application/aif+json</td>		<td align="left">application/aif+json</td>
	<td align="left">RFC XXXX, <xref target="media-types"/></td>		<td align="left">RFC 9237, <xref target="media-types"/></td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>For <tt>application/aif+cbor</tt>:</t>		<section anchor="media-type-template1">
	<dl spacing="compact">		<name>application/aif+cbor</name>
			<dl spacing="normal">
	<dt>Type name:</dt>		<dt>Type name:</dt>
	<dd>		<dd>
	<t>application</t>		<t>application</t>
	</dd>		</dd>
	<dt>Subtype name:</dt>		<dt>Subtype name:</dt>
	<dd>		<dd>
	<t>aif+cbor</t>		<t>aif+cbor</t>
	</dd>		</dd>
	<dt>Required parameters:</dt>		<dt>Required parameters:</dt>
	<dd>		<dd>
	<t>N/A</t>		<t>N/A</t>
	</dd>		</dd>
	<dt>Optional parameters:</dt>		<dt>Optional parameters:</dt>
	<dd>		<dd>
	<ul spacing="normal">		<t><br/></t>
	<li>		<dl newline="true" spacing="normal">
	<tt>Toid</tt>: the identifier for the object for which permissio		<dt>
	ns are		<tt>Toid</tt>:</dt><dd>the identifier for the object for which p
			ermissions are
	supplied.		supplied.
	A value from the media-type parameter sub-registry for <tt>Toid</tt>.		A value from the "Sub-Parameter Registry for application/aif+cbor and applicatio
	Default value: "URI-local-part" (RFC XXXX).</li>		n/aif+json" subregistry for <tt>Toid</tt>.
	<li>		Default value: "URI-local-part" (RFC 9237).</dd>
	<tt>Tperm</tt>: the data type of a permission set for the object		<dt>
			<tt>Tperm</tt>:</dt><dd>the data type of a permission set for th
			e object
	identified via a <tt>Toid</tt>.		identified via a <tt>Toid</tt>.
	A value from the media-type parameter sub-registry for <tt>Tperm</tt>.		A value from the "Sub-Parameter Registry for application/aif+cbor and applicatio
	Default value: "REST-method-set" (RFC XXXX).</li>		n/aif+json" subregistry for <tt>Tperm</tt>.
	</ul>		Default value: "REST-method-set" (RFC 9237).</dd>
			</dl>
	</dd>		</dd>
	<dt>Encoding considerations:</dt>		<dt>Encoding considerations:</dt>
	<dd>		<dd>
	<t>binary (CBOR)</t>		<t>binary (CBOR)</t>
	</dd>		</dd>
	<dt>Security considerations:</dt>		<dt>Security considerations:</dt>
	<dd>		<dd>
	<t><xref target="seccons"/> of RFC XXXX</t>		<t><xref target="seccons"/> of RFC 9237</t>
	</dd>		</dd>
	<dt>Interoperability considerations:</dt>		<dt>Interoperability considerations:</dt>
	<dd>		<dd>
	<t>none</t>		<t>N/A</t>
	</dd>		</dd>
	<dt>Published specification:</dt>		<dt>Published specification:</dt>
	<dd>		<dd>
	<t><xref target="media-types"/> of RFC XXXX</t>		<t><xref target="media-types"/> of RFC 9237</t>
	</dd>		</dd>
	<dt>Applications that use this media type:</dt>		<dt>Applications that use this media type:</dt>
	<dd>		<dd>
	<t>Applications that need to convey structured authorization data fo r		<t>Applications that need to convey structured authorization data fo r
	identified resources, conveying sets of permissions.</t>		identified resources, conveying sets of permissions.</t>
	</dd>		</dd>
	<dt>Fragment identifier considerations:</dt>		<dt>Fragment identifier considerations:</dt>
	<dd>		<dd>
	<t>The syntax and semantics of fragment identifiers is as specified for		<t>The syntax and semantics of fragment identifiers is as specified for
	"application/cbor". (At publication of RFC XXXX, there is no		"application/cbor". (At publication of RFC 9237, there is no
	fragment identification syntax defined for "application/cbor".)</t>		fragment identification syntax defined for "application/cbor".)</t>
	</dd>		</dd>
	<dt>Person &amp; email address to contact for further information:</dt >		<dt>Person &amp; email address to contact for further information:</dt >
	<dd>		<dd>
	<t>ACE WG mailing list (ace@ietf.org),		<t>ACE WG mailing list (ace@ietf.org)
	or IETF Applications and Real-Time Area (art@ietf.org)</t>		or IETF Applications and Real-Time Area (art@ietf.org)</t>
	</dd>		</dd>
	<dt>Intended usage:</dt>		<dt>Intended usage:</dt>
	<dd>		<dd>
	<t>COMMON</t>		<t>COMMON</t>
	</dd>		</dd>
	<dt>Restrictions on usage:</dt>		<dt>Restrictions on usage:</dt>
	<dd>		<dd>
	<t>none</t>		<t>N/A</t>
	</dd>		</dd>
	<dt>Author/Change controller:</dt>		<dt>Author/Change controller:</dt>
	<dd>		<dd>
	<t>IETF</t>		<t>IETF</t>
	</dd>		</dd>
	<dt>Provisional registration:</dt>		<dt>Provisional registration:</dt>
	<dd>		<dd>
	<t>no</t>		<t>no</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>For <tt>application/aif+json</tt>:</t>		</section>
	<dl spacing="compact">		<section anchor="media-type-template2">
			<name>application/aif+json</name>
			<dl spacing="normal">
	<dt>Type name:</dt>		<dt>Type name:</dt>
	<dd>		<dd>
	<t>application</t>		<t>application</t>
	</dd>		</dd>
	<dt>Subtype name:</dt>		<dt>Subtype name:</dt>
	<dd>		<dd>
	<t>aif+json</t>		<t>aif+json</t>
	</dd>		</dd>
	<dt>Required parameters:</dt>		<dt>Required parameters:</dt>
	<dd>		<dd>
	<t>N/A</t>		<t>N/A</t>
	</dd>		</dd>
	<dt>Optional parameters:</dt>		<dt>Optional parameters:</dt>
	<dd>		<dd>
	<ul spacing="normal">		<t><br/></t>
	<li>		<dl newline="true" spacing="normal">
	<tt>Toid</tt>: the identifier for the object for which permissio		<dt>
	ns are		<tt>Toid</tt>:</dt><dd>the identifier for the object for which p
			ermissions are
	supplied.		supplied.
	A value from the media-type parameter sub-registry for <tt>Toid</tt>.		A value from the media-type parameter subregistry for <tt>Toid</tt>.
	Default value: "URI-local-part" (RFC XXXX).</li>		Default value: "URI-local-part" (RFC 9237).</dd>
	<li>		<dt>
	<tt>Tperm</tt>: the data type of a permission set for the object		<tt>Tperm</tt>:</dt><dd>the data type of a permission set for th
			e object
	identified via a <tt>Toid</tt>.		identified via a <tt>Toid</tt>.
	A value from the media-type parameter sub-registry for <tt>Tperm</tt>.		A value from the media-type parameter subregistry for <tt>Tperm</tt>.
	Default value: "REST-method-set" (RFC XXXX).</li>		Default value: "REST-method-set" (RFC 9237).</dd>
	</ul>		</dl>
	</dd>		</dd>
	<dt>Encoding considerations:</dt>		<dt>Encoding considerations:</dt>
	<dd>		<dd>
	<t>binary (JSON is UTF-8-encoded text)</t>		<t>binary (JSON is UTF-8-encoded text)</t>
	</dd>		</dd>
	<dt>Security considerations:</dt>		<dt>Security considerations:</dt>
	<dd>		<dd>
	<t><xref target="seccons"/> of RFC XXXX</t>		<t><xref target="seccons"/> of RFC 9237</t>
	</dd>		</dd>
	<dt>Interoperability considerations:</dt>		<dt>Interoperability considerations:</dt>
	<dd>		<dd>
	<t>none</t>		<t>N/A</t>
	</dd>		</dd>
	<dt>Published specification:</dt>		<dt>Published specification:</dt>
	<dd>		<dd>
	<t><xref target="media-types"/> of RFC XXXX</t>		<t><xref target="media-types"/> of RFC 9237</t>
	</dd>		</dd>
	<dt>Applications that use this media type:</dt>		<dt>Applications that use this media type:</dt>
	<dd>		<dd>
	<t>Applications that need to convey structured authorization data fo r		<t>Applications that need to convey structured authorization data fo r
	identified resources, conveying sets of permissions.</t>		identified resources, conveying sets of permissions.</t>
	</dd>		</dd>
	<dt>Fragment identifier considerations:</dt>		<dt>Fragment identifier considerations:</dt>
	<dd>		<dd>
	<t>The syntax and semantics of fragment identifiers is as specified for		<t>The syntax and semantics of fragment identifiers is as specified for
	"application/json". (At publication of RFC XXXX, there is no		"application/json". (At publication of RFC 9237, there is no
	fragment identification syntax defined for "application/json".)</t>		fragment identification syntax defined for "application/json".)</t>
	</dd>		</dd>
	<dt>Person &amp; email address to contact for further information:</dt >		<dt>Person &amp; email address to contact for further information:</dt >
	<dd>		<dd>
	<t>ACE WG mailing list (ace@ietf.org),		<t>ACE WG mailing list (ace@ietf.org)
	or IETF Applications and Real-Time Area (art@ietf.org)</t>		or IETF Applications and Real-Time Area (art@ietf.org)</t>
	</dd>		</dd>
	<dt>Intended usage:</dt>		<dt>Intended usage:</dt>
	<dd>		<dd>
	<t>COMMON</t>		<t>COMMON</t>
	</dd>		</dd>
	<dt>Restrictions on usage:</dt>		<dt>Restrictions on usage:</dt>
	<dd>		<dd>
	<t>none</t>		<t>N/A</t>
	</dd>		</dd>
	<dt>Author/Change controller:</dt>		<dt>Author/Change controller:</dt>
	<dd>		<dd>
	<t>IETF</t>		<t>IETF</t>
	</dd>		</dd>
	<dt>Provisional registration:</dt>		<dt>Provisional registration:</dt>
	<dd>		<dd>
	<t>no</t>		<t>no</t>
	</dd>		</dd>
	</dl>		</dl>
	</section>		</section>
			</section>
	<section anchor="registries">		<section anchor="registries">
	<name>Registries</name>		<name>Registries</name>
	<t>For the media types application/aif+cbor and application/aif+json,		<t>For the media types application/aif+cbor and application/aif+json,
	IANA is requested to create a sub-registry within		IANA has created a subregistry within
	<xref target="IANA.media-type-sub-parameters"/> for the two media-type parameter		<xref target="IANA.media-type-sub-parameters"/> for the media-type parameters
	s		<tt>Toid</tt> and <tt>Tperm</tt>, populated with the following:</t>
	<tt>Toid</tt> and <tt>Tperm</tt>, populated with:</t>
	<table align="left">		<table align="left">
	<name>New Media Type Parameters</name>		<name>New Media Type Parameters</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Parameter</th>		<th align="left">Parameter</th>
	<th align="left">name</th>		<th align="left">name</th>
	<th align="left">Description/Specification</th>		<th align="left">Description/Specification</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">Toid</td>		<td align="left">Toid</td>
	<td align="left">URI-local-part</td>		<td align="left">URI-local-part</td>
	<td align="left">local-part of URI</td>		<td align="left">local-part of URI</td>
	<td align="left">RFC XXXX</td>		<td align="left">RFC 9237</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Tperm</td>		<td align="left">Tperm</td>
	<td align="left">REST-method-set</td>		<td align="left">REST-method-set</td>
	<td align="left">set of REST methods represented</td>		<td align="left">set of REST methods represented</td>
	<td align="left">RFC XXXX</td>		<td align="left">RFC 9237</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>The registration policy is Specification required <xref target="RFC81		<t>The registration policy is Specification Required <xref target="RFC81
	26"/>.		26"/>.
	The designated expert will engage with the submitter to ascertain the		The designated expert will engage with the submitter to ascertain whether the
	requirements of this document are addressed:</t>		requirements of this document are addressed:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The specifications for <tt>Toid</tt> and <tt>Tperm</tt> need to re alize the		<li>The specifications for <tt>Toid</tt> and <tt>Tperm</tt> need to re alize the
	general ideas of unambiguous object identifiers and permission lists		general ideas of unambiguous object identifiers and permission lists
	in the context where the AIF data item is intended to be used, and		in the context where the AIF data item is intended to be used, and
	their structure needs to be usable with the intended media types		their structure needs to be usable with the intended media types
	(application/aif+cbor and application/aif+json) as identified in the		(application/aif+cbor and application/aif+json) as identified in the
	specification.</li>		specification.</li>
	<li>The parameter names need to conform to <xref section="4.3" section		<li>The parameter names need to conform to <xref section="4.3" sectionFormat="of
	Format="of" target="RFC6838"/>, but preferably are in <xref target="KebabCase"/>		" target="RFC6838"/>, but preferably they are in <xref target="KebabCase"/> so t
	so they can		hey can be easily
	easily be translated into names used in popular programming		translated into names used in APIs with popular programming
	language APIs.</li>		languages.</li>
	</ul>		</ul>
	<t>The designated experts will develop further criteria and guidelines a s		<t>The designated experts will develop further criteria and guidelines a s
	needed.</t>		needed.</t>
	</section>		</section>
	<section anchor="content-format">		<section anchor="content-format">
	<name>Content-Format</name>		<name>Content-Format</name>
	<t>IANA is requested to register Content-Format numbers in the "CoAP		<t>IANA has registered Content-Format numbers in the "CoAP
	Content-Formats" sub-registry, within the "Constrained RESTful		Content-Formats" subregistry, within the "Constrained RESTful
	Environments (CoRE) Parameters" Registry <xref target="IANA.core-parameters"/>,		Environments (CoRE) Parameters" registry <xref target="IANA.core-parameters"/>,
	as		as
	follows:</t>		follows:</t>
	<table align="left">		<table align="left">
	<name>New Content-Formats</name>		<name>New Content-Formats</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Content-Type</th>		<th align="left">Media Type</th>
	<th align="left">Content Coding</th>		<th align="left">Encoding</th>
	<th align="left">ID</th>		<th align="left">ID</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">application/aif+cbor</td>		<td align="left">application/aif+cbor</td>
	<td align="left">-</td>		<td align="left">-</td>
	<td align="left">TBD1</td>		<td align="left">290</td>
	<td align="left">RFC XXXX</td>		<td align="left">RFC 9237</td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">application/aif+json</td>		<td align="left">application/aif+json</td>
	<td align="left">-</td>		<td align="left">-</td>
	<td align="left">TBD2</td>		<td align="left">291</td>
	<td align="left">RFC XXXX</td>		<td align="left">RFC 9237</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>// RFC Ed.: please replace TBD1 and TBD2 with assigned IDs and remove
	this note.</t>
	<t>In the registry as defined by <xref section="12.3" sectionFormat="of"
	target="RFC7252"/> at the time of
	writing, the column "Content-Type" is called "Media type" and the
	column "Content Coding" is called "Encoding".</t>
	<t>Note that applications that register <tt>Toid</tt> and <tt>Tperm</tt> values are		<t>Note that applications that register <tt>Toid</tt> and <tt>Tperm</tt> values are
	encouraged to also register Content-Formats for the relevant		encouraged to also register Content-Formats for the relevant
	combinations.</t>		combinations.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="seccons">		<section anchor="seccons">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>The security considerations of <xref target="RFC7252"/> apply when AIF		<t>The security considerations of <xref target="RFC7252"/> apply when
	is used with		AIF is used with CoAP; <xref section="11.1" sectionFormat="of"
	CoAP, and, if complex formats such as URIs are used for <tt>Toid</tt> or		target="RFC7252"/> specifically applies if complex formats such as URIs
	<tt>Tperm</tt>, specifically <xref section="11.1" sectionFormat="of" target="RFC		are used for <tt>Toid</tt> or <tt>Tperm</tt>. Some wider issues are
	7252"/>.		discussed in <xref target="RFC8576"/>.</t>
	Some wider issues are discussed in <xref target="RFC8576"/>.</t>
	<t>When applying these formats, the referencing specification needs to be		<t>When applying these formats, the referencing specification needs to be
	careful to:</t>		careful to ensure:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>ensure that the cryptographic armor employed around this format		<li>that the cryptographic armor employed around this format
	fulfills the referencing specification's security objectives, and that the armor		fulfills the referencing specification's security objectives and that the armor
	or some		or some
	additional information included in it with the AIF data item		additional information included in it with the AIF data item
	(1) unambiguously identifies the subject to which the authorizations		(1) unambiguously identifies the subject to which the authorizations
	shall apply and (2) provides any context information needed to derive the		shall apply and (2) provides any context information needed to derive the
	identity of the object to which authorization is being granted		identity of the object to which authorization is being granted
	from the object identifiers (such as, for		from the object identifiers (such as, for
	the data models defined in the present specification, the scheme and		the data models defined in the present specification, the scheme and
	authority information that is used to construct the full URI), and</li>		authority information that is used to construct the full URI), and</li>
	<li>ensure that the types used for <tt>Toid</tt> and <tt>Tperm</tt> prov ide the		<li>that the types used for <tt>Toid</tt> and <tt>Tperm</tt> provide the
	appropriate granularity and precision so that application requirements on the		appropriate granularity and precision so that application requirements on the
	precision of the authorization information are fulfilled, and that		precision of the authorization information are fulfilled and that
	all parties have the same understanding of each Toid/Tperm pair in		all parties have the same understanding of each <tt>Toid</tt>/<tt>Tperm</tt> pai
			r in
	terms of specified objects (resources) and operations on those.</li>		terms of specified objects (resources) and operations on those.</li>
	</ul>		</ul>
	<t>For the data formats, the security considerations of <xref target="RFC8 259"/> and		<t>For the data formats, the security considerations of <xref target="RFC8 259"/> and
	<xref target="RFC8949"/> apply.</t>		<xref target="RFC8949"/> apply.</t>
	<t>A plain implementation of AIF might implement just the basic REST		<t>A plain implementation of AIF might implement just the basic REST
	model as per <xref target="rest-model"/>. If it receives authorizations that		model as per <xref target="rest-model"/>. If it receives authorizations that
	include permissions that use the REST-specific Model With Dynamic		include permissions that use the REST-specific model with dynamic
	Resource Creation <xref target="ext-rest-model"/>, it needs to either		resource creation (<xref target="ext-rest-model"/>), it needs to either
	reject the AIF data item entirely or act only on the		reject the AIF data item entirely or act only on the
	permissions that it does understand.		permissions that it does understand.
	In other words, the semantics underlying an allow-list as discussed		In other words, the semantics underlying an allow-list as discussed
	above need to hold here as well.</t>		above need to hold here as well.</t>
	<t>An implementation of the REST-specific Model With Dynamic Resource		<t>An implementation of the REST-specific model with dynamic resource
	Creation <xref target="ext-rest-model"/> needs to carefully keep track of the		creation (<xref target="ext-rest-model"/>) needs to carefully keep track of the
	dynamically created objects and the subjects to which the Dynamic-X		dynamically created objects and the subjects to which the Dynamic-X
	permissions apply -- both on the server side to enforce the permissions		permissions apply -- both on the server side to enforce the permissions
	and on the client side to know which permissions are available.</t>		and on the client side to know which permissions are available.</t>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3
	986">
	<front>
	<title>Uniform Resource Identifier (URI): Generic Syntax</title>
	<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
	">
	<organization/>
	</author>
	<author fullname="R. Fielding" initials="R." surname="Fielding">
	<organization/>
	</author>
	<author fullname="L. Masinter" initials="L." surname="Masinter">
	<organization/>
	</author>
	<date month="January" year="2005"/>
	<abstract>
	<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
	aracters that identifies an abstract or physical resource. This specification d
	efines the generic URI syntax and a process for resolving URI references that mi
	ght be in relative form, along with guidelines and security considerations for t
	he use of URIs on the Internet. The URI syntax defines a grammar that is a supe
	rset of all valid URIs, allowing an implementation to parse the common component
	s of a URI reference without knowing the scheme-specific requirements of every p
	ossible identifier. This specification does not define a generative grammar for
	URIs; that task is performed by the individual specifications of each URI schem
	e. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="66"/>
	<seriesInfo name="RFC" value="3986"/>
	<seriesInfo name="DOI" value="10.17487/RFC3986"/>
	</reference>
	<reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7
	252">
	<front>
	<title>The Constrained Application Protocol (CoAP)</title>
	<author fullname="Z. Shelby" initials="Z." surname="Shelby">
	<organization/>
	</author>
	<author fullname="K. Hartke" initials="K." surname="Hartke">
	<organization/>
	</author>
	<author fullname="C. Bormann" initials="C." surname="Bormann">
	<organization/>
	</author>
	<date month="June" year="2014"/>
	<abstract>
	<t>The Constrained Application Protocol (CoAP) is a specialized we
	b transfer protocol for use with constrained nodes and constrained (e.g., low-po
	wer, lossy) networks. The nodes often have 8-bit microcontrollers with small am
	ounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wir
	eless Personal Area Networks (6LoWPANs) often have high packet error rates and a
	typical throughput of 10s of kbit/s. The protocol is designed for machine- to-
	machine (M2M) applications such as smart energy and building automation.</t>
	<t>CoAP provides a request/response interaction model between appl
	ication endpoints, supports built-in discovery of services and resources, and in
	cludes key concepts of the Web such as URIs and Internet media types. CoAP is d
	esigned to easily interface with HTTP for integration with the Web while meeting
	specialized requirements such as multicast support, very low overhead, and simp
	licity for constrained environments.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7252"/>
	<seriesInfo name="DOI" value="10.17487/RFC7252"/>
	</reference>
	<reference anchor="I-D.ietf-httpbis-semantics" target="https://www.ietf.
	org/archive/id/draft-ietf-httpbis-semantics-19.txt">
	<front>
	<title>HTTP Semantics</title>
	<author fullname="Roy T. Fielding">
	<organization>Adobe</organization>
	</author>
	<author fullname="Mark Nottingham">
	<organization>Fastly</organization>
	</author>
	<author fullname="Julian Reschke">
	<organization>greenbytes GmbH</organization>
	</author>
	<date day="12" month="September" year="2021"/>
	<abstract>
	<t> The Hypertext Transfer Protocol (HTTP) is a stateless applic
	ation-
	level protocol for distributed, collaborative, hypertext information
	systems. This document describes the overall architecture of HTTP,
	establishes common terminology, and defines aspects of the protocol
	that are shared by all versions. In this definition are core
	protocol elements, extensibility mechanisms, and the "http" and
	"https" Uniform Resource Identifier (URI) schemes.
	This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions		C.3986.xml"/>
	of RFC 7230.		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.7252.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.9110.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.8126.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.6838.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.8610.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.9165.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.2119.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
			C.8174.xml"/>
	</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics-
	19"/>
	</reference>
	<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
	126">
	<front>
	<title>Guidelines for Writing an IANA Considerations Section in RFCs
	</title>
	<author fullname="M. Cotton" initials="M." surname="Cotton">
	<organization/>
	</author>
	<author fullname="B. Leiba" initials="B." surname="Leiba">
	<organization/>
	</author>
	<author fullname="T. Narten" initials="T." surname="Narten">
	<organization/>
	</author>
	<date month="June" year="2017"/>
	<abstract>
	<t>Many protocols make use of points of extensibility that use con
	stants to identify various protocol parameters. To ensure that the values in th
	ese fields do not have conflicting uses and to promote interoperability, their a
	llocations 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 des
	cribing the conditions under which new values should be assigned, as well as whe
	n and how modifications to existing values can be made, is needed. This documen
	t defines a framework for the documentation of these guidelines by specification
	authors, in order to assure that the provided guidance for the IANA Considerati
	ons is clear and addresses the various issues that are likely in the operation o
	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="RFC6838" target="https://www.rfc-editor.org/info/rfc6
	838">
	<front>
	<title>Media Type Specifications and Registration Procedures</title>
	<author fullname="N. Freed" initials="N." surname="Freed">
	<organization/>
	</author>
	<author fullname="J. Klensin" initials="J." surname="Klensin">
	<organization/>
	</author>
	<author fullname="T. Hansen" initials="T." surname="Hansen">
	<organization/>
	</author>
	<date month="January" year="2013"/>
	<abstract>
	<t>This document defines procedures for the specification and regi
	stration of media types for use in HTTP, MIME, and other Internet protocols. Th
	is memo documents an Internet Best Current Practice.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="13"/>
	<seriesInfo name="RFC" value="6838"/>
	<seriesInfo name="DOI" value="10.17487/RFC6838"/>
	</reference>
	<reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8
	610">
	<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 fullname="H. Birkholz" initials="H." surname="Birkholz">
	<organization/>
	</author>
	<author fullname="C. Vigano" initials="C." surname="Vigano">
	<organization/>
	</author>
	<author fullname="C. Bormann" initials="C." surname="Bormann">
	<organization/>
	</author>
	<date month="June" year="2019"/>
	<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>
	<reference anchor="RFC9165" target="https://www.rfc-editor.org/info/rfc9
	165">
	<front>
	<title>Additional Control Operators for the Concise Data Definition
	Language (CDDL)</title>
	<author fullname="C. Bormann" initials="C." surname="Bormann">
	<organization/>
	</author>
	<date month="December" year="2021"/>
	<abstract>
	<t>The Concise Data Definition Language (CDDL), standardized in RF
	C 8610, provides "control operators" as its main language extension point.</t>
	<t>The present document defines a number of control operators that
	were not yet ready at the time RFC 8610 was completed: , , and for the constru
	ction of constants; / for including ABNF (RFC 5234 and RFC 7405) in CDDL specifi
	cations; and for indicating the use of a non-basic feature in an instance.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9165"/>
	<seriesInfo name="DOI" value="10.17487/RFC9165"/>
	</reference>
	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	119">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	le>
	<author fullname="S. Bradner" initials="S." surname="Bradner">
	<organization/>
	</author>
	<date month="March" year="1997"/>
	<abstract>
	<t>In many standards track documents several words are used to sig
	nify the requirements in the specification. These words are often capitalized.
	This document defines these words as they should be interpreted in IETF document
	s. This document specifies an Internet Best Current Practices for the Internet
	Community, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
	174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author fullname="B. Leiba" initials="B." surname="Leiba">
	<organization/>
	</author>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying tha
	t only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="RFC4949" target="https://www.rfc-editor.org/info/rfc4
	949">
	<front>
	<title>Internet Security Glossary, Version 2</title>
	<author fullname="R. Shirey" initials="R." surname="Shirey">
	<organization/>
	</author>
	<date month="August" year="2007"/>
	<abstract>
	<t>This Glossary provides definitions, abbreviations, and explanat
	ions of terminology for information system security. The 334 pages of entries of
	fer recommendations to improve the comprehensibility of written material that is
	generated in the Internet Standards Process (RFC 2026). The recommendations fol
	low the principles that such writing should (a) use the same term or definition
	whenever the same concept is mentioned; (b) use terms in their plainest, diction
	ary sense; (c) use terms that are already well-established in open publications;
	and (d) avoid terms that either favor a particular vendor or favor a particular
	technology or mechanism over other, competing techniques that already exist or
	could be developed. This memo provides information for the Internet community.<
	/t>
	</abstract>
	</front>
	<seriesInfo name="FYI" value="36"/>
	<seriesInfo name="RFC" value="4949"/>
	<seriesInfo name="DOI" value="10.17487/RFC4949"/>
	</reference>
	<reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8
	259">
	<front>
	<title>The JavaScript Object Notation (JSON) Data Interchange Format
	</title>
	<author fullname="T. Bray" initials="T." role="editor" surname="Bray
	">
	<organization/>
	</author>
	<date month="December" year="2017"/>
	<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="I-D.ietf-ace-oauth-authz" target="https://www.ietf.or
	g/archive/id/draft-ietf-ace-oauth-authz-46.txt">
	<front>
	<title>Authentication and Authorization for Constrained Environments
	(ACE) using the OAuth 2.0 Framework (ACE-OAuth)</title>
	<author fullname="Ludwig Seitz">
	<organization>Combitech</organization>
	</author>
	<author fullname="Goeran Selander">
	<organization>Ericsson</organization>
	</author>
	<author fullname="Erik Wahlstroem">
	</author>
	<author fullname="Samuel Erdtman">
	<organization>Spotify AB</organization>
	</author>
	<author fullname="Hannes Tschofenig">
	<organization>Arm Ltd.</organization>
	</author>
	<date day="8" month="November" year="2021"/>
	<abstract>
	<t> This specification defines a framework for authentication an
	d
	authorization in Internet of Things (IoT) environments called ACE-
	OAuth. The framework is based on a set of building blocks including
	OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
	transforming a well-known and widely used authorization solution into
	a form suitable for IoT devices. Existing specifications are used
	where possible, but extensions are added and profiles are defined to
	better serve the IoT use cases.
	</t>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	</abstract>		C.4949.xml"/>
	</front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	<seriesInfo name="Internet-Draft" value="draft-ietf-ace-oauth-authz-46		C.8259.xml"/>
	"/>
	</reference>		<reference anchor='RFC9200' target="https://www.rfc-editor.org/info/rfc9200">
	<reference anchor="RFC7493" target="https://www.rfc-editor.org/info/rfc7		<front>
	493">		<title>Authentication and Authorization for Constrained Environments Using the O
	<front>		Auth 2.0 Framework (ACE-OAuth)</title>
	<title>The I-JSON Message Format</title>		<author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
	<author fullname="T. Bray" initials="T." role="editor" surname="Bray		<organization />
	">		</author>
	<organization/>		<author initials='G' surname='Selander' fullname='Goeran Selander'>
	</author>		<organization />
	<date month="March" year="2015"/>		</author>
	<abstract>		<author initials='E' surname='Wahlstroem' fullname='Erik Wahlstroem'>
	<t>I-JSON (short for "Internet JSON") is a restricted profile of J		<organization />
	SON designed to maximize interoperability and increase confidence that software		</author>
	can process it successfully with predictable results.</t>		<author initials='S' surname='Erdtman' fullname='Samuel Erdtman'>
	</abstract>		<organization />
	</front>		</author>
	<seriesInfo name="RFC" value="7493"/>		<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
	<seriesInfo name="DOI" value="10.17487/RFC7493"/>		<organization />
	</reference>		</author>
	<reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8		<date year='2022' month='August' />
	949">		</front>
	<front>		<seriesInfo name="RFC" value="9200"/>
	<title>Concise Binary Object Representation (CBOR)</title>		<seriesInfo name="DOI" value="10.17487/RFC9200"/>
	<author fullname="C. Bormann" initials="C." surname="Bormann">		</reference>
	<organization/>
	</author>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	<author fullname="P. Hoffman" initials="P." surname="Hoffman">		C.7493.xml"/>
	<organization/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	</author>		C.8949.xml"/>
	<date month="December" year="2020"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	<abstract>		C.8132.xml"/>
	<t>The Concise Binary Object Representation (CBOR) is a data forma		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	t whose design goals include the possibility of extremely small code size, fairl		C.8576.xml"/>
	y small message size, and extensibility without the need for version negotiation		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	. These design goals make it different from earlier binary serializations such a		C.6570.xml"/>
	s ASN.1 and MessagePack.</t>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
	<t>This document obsoletes RFC 7049, providing editorial improveme		C.7228.xml"/>
	nts, new details, and errata fixes while keeping full compatibility with the int
	erchange format of RFC 7049. It does not create a new version of the format.</t
	>
	</abstract>
	</front>
	<seriesInfo name="STD" value="94"/>
	<seriesInfo name="RFC" value="8949"/>
	<seriesInfo name="DOI" value="10.17487/RFC8949"/>
	</reference>
	<reference anchor="RFC8132" target="https://www.rfc-editor.org/info/rfc8
	132">
	<front>
	<title>PATCH and FETCH Methods for the Constrained Application Proto
	col (CoAP)</title>
	<author fullname="P. van der Stok" initials="P." surname="van der St
	ok">
	<organization/>
	</author>
	<author fullname="C. Bormann" initials="C." surname="Bormann">
	<organization/>
	</author>
	<author fullname="A. Sehgal" initials="A." surname="Sehgal">
	<organization/>
	</author>
	<date month="April" year="2017"/>
	<abstract>
	<t>The methods defined in RFC 7252 for the Constrained Application
	Protocol (CoAP) only allow access to a complete resource, not to parts of a res
	ource. In case of resources with larger or complex data, or in situations where
	resource continuity is required, replacing or requesting the whole resource is
	undesirable. Several applications using CoAP need to access parts of the resour
	ces.</t>
	<t>This specification defines the new CoAP methods, FETCH, PATCH,
	and iPATCH, which are used to access and update parts of a resource.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8132"/>
	<seriesInfo name="DOI" value="10.17487/RFC8132"/>
	</reference>
	<reference anchor="RFC8576" target="https://www.rfc-editor.org/info/rfc8
	576">
	<front>
	<title>Internet of Things (IoT) Security: State of the Art and Chall
	enges</title>
	<author fullname="O. Garcia-Morchon" initials="O." surname="Garcia-M
	orchon">
	<organization/>
	</author>
	<author fullname="S. Kumar" initials="S." surname="Kumar">
	<organization/>
	</author>
	<author fullname="M. Sethi" initials="M." surname="Sethi">
	<organization/>
	</author>
	<date month="April" year="2019"/>
	<abstract>
	<t>The Internet of Things (IoT) concept refers to the usage of sta
	ndard Internet protocols to allow for human-to-thing and thing-to-thing communic
	ation. The security needs for IoT systems are well recognized, and many standar
	dization steps to provide security have been taken -- for example, the specifica
	tion of the Constrained Application Protocol (CoAP) secured with Datagram Transp
	ort Layer Security (DTLS). However, security challenges still exist, not only b
	ecause there are some use cases that lack a suitable solution, but also because
	many IoT devices and systems have been designed and deployed with very limited s
	ecurity capabilities. In this document, we first discuss the various stages in
	the lifecycle of a thing. Next, we document the security threats to a thing and
	the challenges that one might face to protect against these threats. Lastly, we
	discuss the next steps needed to facilitate the deployment of secure IoT system
	s. This document can be used by implementers and authors of IoT specifications
	as a reference for details about security considerations while documenting their
	specific security challenges, threat models, and mitigations.</t>
	<t>This document is a product of the IRTF Thing-to-Thing Research
	Group (T2TRG).</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8576"/>
	<seriesInfo name="DOI" value="10.17487/RFC8576"/>
	</reference>
	<reference anchor="RFC6570" target="https://www.rfc-editor.org/info/rfc6
	570">
	<front>
	<title>URI Template</title>
	<author fullname="J. Gregorio" initials="J." surname="Gregorio">
	<organization/>
	</author>
	<author fullname="R. Fielding" initials="R." surname="Fielding">
	<organization/>
	</author>
	<author fullname="M. Hadley" initials="M." surname="Hadley">
	<organization/>
	</author>
	<author fullname="M. Nottingham" initials="M." surname="Nottingham">
	<organization/>
	</author>
	<author fullname="D. Orchard" initials="D." surname="Orchard">
	<organization/>
	</author>
	<date month="March" year="2012"/>
	<abstract>
	<t>A URI Template is a compact sequence of characters for describi
	ng a range of Uniform Resource Identifiers through variable expansion. This spec
	ification defines the URI Template syntax and the process for expanding a URI Te
	mplate into a URI reference, along with guidelines for the use of URI Templates
	on the Internet. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6570"/>
	<seriesInfo name="DOI" value="10.17487/RFC6570"/>
	</reference>
	<reference anchor="RFC7228" target="https://www.rfc-editor.org/info/rfc7
	228">
	<front>
	<title>Terminology for Constrained-Node Networks</title>
	<author fullname="C. Bormann" initials="C." surname="Bormann">
	<organization/>
	</author>
	<author fullname="M. Ersue" initials="M." surname="Ersue">
	<organization/>
	</author>
	<author fullname="A. Keranen" initials="A." surname="Keranen">
	<organization/>
	</author>
	<date month="May" year="2014"/>
	<abstract>
	<t>The Internet Protocol Suite is increasingly used on small devic
	es with severe constraints on power, memory, and processing resources, creating
	constrained-node networks. This document provides a number of basic terms that
	have been useful in the standardization work for constrained-node networks.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7228"/>
	<seriesInfo name="DOI" value="10.17487/RFC7228"/>
	</reference>
	<reference anchor="IANA.core-parameters" target="https://www.iana.org/as signments/core-parameters">		<reference anchor="IANA.core-parameters" target="https://www.iana.org/as signments/core-parameters">
	<front>		<front>
	<title>Constrained RESTful Environments (CoRE) Parameters</title>		<title>Constrained RESTful Environments (CoRE) Parameters</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	<date/>		<date/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="IANA.media-type-sub-parameters" target="https://www.i ana.org/assignments/media-type-sub-parameters">		<reference anchor="IANA.media-type-sub-parameters" target="https://www.i ana.org/assignments/media-type-sub-parameters">
	<front>		<front>
	<title>MIME Media Type Sub-Parameter Registries</title>		<title>MIME Media Type Sub-Parameter Registries</title>
	<author>		<author>
	<organization>IANA</organization>		<organization>IANA</organization>
	</author>		</author>
	<date/>		<date/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="KebabCase" target="http://wiki.c2.com/?KebabCase">		<reference anchor="KebabCase" target="http://wiki.c2.com/?KebabCase">
	<front>		<front>
	<title>KebabCase</title>		<title>Kebab Case</title>
	<author>		<author>
	<organization/>		<organization/>
	</author>		</author>
	<date year="2014" month="August" day="29"/>		<date year="2014" month="August" day="29"/>
	</front>		</front>
	</reference>		</reference>
	<reference anchor="RFC8881" target="https://www.rfc-editor.org/info/rfc8
	881">		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8881.
	<front>		xml"/>
	<title>Network File System (NFS) Version 4 Minor Version 1 Protocol<
	/title>
	<author fullname="D. Noveck" initials="D." role="editor" surname="No
	veck">
	<organization/>
	</author>
	<author fullname="C. Lever" initials="C." surname="Lever">
	<organization/>
	</author>
	<date month="August" year="2020"/>
	<abstract>
	<t>This document describes the Network File System (NFS) version 4
	minor version 1, including features retained from the base protocol (NFS versio
	n 4 minor version 0, which is specified in RFC 7530) and protocol extensions mad
	e subsequently. The later minor version has no dependencies on NFS version 4 mi
	nor version 0, and is considered a separate protocol. </t>
	<t>This document obsoletes RFC 5661. It substantially revises the
	treatment of features relating to multi-server namespace, superseding the descr
	iption of those features appearing in RFC 5661.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8881"/>
	<seriesInfo name="DOI" value="10.17487/RFC8881"/>
	</reference>
	</references>		</references>
	</references>		</references>
	<section numbered="false" anchor="acknowledgements">		<section numbered="false" anchor="acknowledgements">
	<name>Acknowledgements</name>		<name>Acknowledgements</name>
	<t><contact fullname="Jim Schaad"/>,		<t><contact fullname="Jim Schaad"/>,
	<contact fullname="Francesca Palombini"/>,		<contact fullname="Francesca Palombini"/>,
	<contact fullname="Olaf Bergmann"/>,		<contact fullname="Olaf Bergmann"/>,
	<contact fullname="Marco Tiloca"/>,		<contact fullname="Marco Tiloca"/>,
	and		and
	<contact fullname="Christian Amsüss"/>		<contact fullname="Christian Amsüss"/>
	provided comments that shaped the		provided comments that shaped the
	direction of this document.		direction of this document.
	<contact fullname="Alexey Melnikov"/> pointed out that there were gaps in the me dia		<contact fullname="Alexey Melnikov"/> pointed out that there were gaps in the me dia
	type specifications, and <contact fullname="Loganaden Velvindron"/> provided a s hepherd		type specifications, and <contact fullname="Loganaden Velvindron"/> provided a s hepherd
	review with further comments.		review with further comments.
	Many thanks also to the IESG reviewers, which provided several small		Many thanks also to the IESG reviewers, who provided several small
	but significant observations.		but significant observations.
	<contact fullname="Benjamin Kaduk"/> provided an extensive review as responsible		<contact fullname="Benjamin Kaduk"/> provided an extensive review as Responsible
	Area		Area
	Director, and indeed is responsible for much improvement in the document.</t>		Director and indeed is responsible for much improvement in the document.</t>
	</section>		</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIANOHMGIAA+1ca3IbSXL+X6eoxUSsQS0AiiD1gnZmlyKpGe3qtSLl2fXE
	2GqgC0CPGt1wP0hhKG74ED6Af/gY/uW9iU/i/DKrqqsboDRjOxzh8DJiRkCj
	HllZmV8+KquHw6Gqkio1E32c6eO6WuZF8mNUJXmmn2XzvFjJ56f8SfePnz3d
	0/RYH5+cqWg6LczlBJ81/aDifJZFKxoqLqJ5NUxMNR9GMzOMkvkwjSpTVuoL
	HdOHiR7fHY+Hd8fDgyOlyirK4n+I0jyjH6qiNkol64I/ltX47t1Hd8cqKkw0
	IYoqU2SmUlcLmfXbvHifZAv9dZHXa/X+qmkyPAUNahZVE11WsZrlWWmysi7t
	FGU9XSVlSWurNmua99nZxVOl1slEaV3ls4nemFI+xmZdLSf6iL6VeVEVZl66
	X8vNqvmqLk1WG/RfgJoJc9NkVTITFtIiOwwGH0+IrqqIkszE+iy7TIo8W1Gn
	UveJc3s02CpK0ommL78FP0d5scAMSbWspxM9i6b5vmWxUhGPDgrwN7T/ap1k
	ROLJSD/BJmaZfy6bdRIVZWWyrV9ppol+myWXpiiT6i//WuknhSHa9MXfPfON
	iHZjiMWv87KaR7OlPjy8e3R01/8+S6rNxHZsHuYxzXs6HD88vPcoeFpnVUGt
	vzYgZON/WC9ZMn519Gh4ND4Yjg8eDu8fPhof+AZGeARm/Lb6MWEeqUxk95J3
	5M3Tk8NHD+9PdF0k8vXB+N6YuuTRmr4/G56OWFqXVbWeJuWwpCGxc8Q3PGq+
	S+eHB2MaK4myCGIlz+4/PHw40SsTJ9EQIjUszMK2vn9wl6aK41S+Pzq4f0++
	r9Oa5CZxeuZpPXp09GiiF2leugnH9+jBD2WehdRi43Ns+hD/+5GlRB6QnrWb
	xVVaDiMrfdBQ/j4zWw3zcpYXZrgu8nkCVMD3aM1NhW9Hjw5p6UNLC2hjYmfT
	vHDMOSTOrqNqtrQP7j0gbpVmFjDr3oO7vBnDyqzWjA1uW8bERVLhFRZ6/PJ4
	JOREBckqPS4n7nnAadLlTovfm2k0PYlKI8pQRcUCUoq9nOzvXyXvk9FsTEOv
	9n/jm0pLwcL2QwdZB0fDuw+H40dKDYdDHU2huLNKqRAoSQbrSl8tE9IFKH+V
	mFITemnP/JhARa9NgT7UMKpUTt+4d6lpBOkLXlHvmrEgn+ucsKRoRkxoUD0r
	6lkSpYRtqzWpSFahIe1cTI8JFKNM56S8UZoSUJGKr3RFs6Er7UVdmJEG+lya
	DTVW68LMkrIhU1aTBCujfqZcG8yYbmjuBMiWUhO9TBbLdAP4yaktLVCmK/UV
	wZROwXyd1aspbQ4odIsY6LKmlUYl0WVUzyE3mlwsiaayN1KKPhG9mHbugJRW
	eJnEYKtemMwUyaxF54rQJWW0lWf4RxWGFlhiZmKMTHvbQgeg6MoQ10DZVa4v
	o4JUvSoVERZ5WoCqFUBBBqDfmLvNnLomdjIH3pydX2iaPq+LGQk60U7d5gkx
	arrRb988g7Isaa3f/X1CCJgfDL+ftOzCqblMZlgvc2rD4kSDx+A9PdC7WKcz
	Y2KWXt5sgmG0zouYpIjkT0TOkJgVtPEVbSgYRjy6hBiRZaTxR9z9VWZ0QvJV
	YLHapEDySpbrJIkHL2X9saXVkuYtNlsURx0TBzKmJHDT1OBjTGyNjZX+QCMK
	8481eQ7Unuc0K1nUMq/TGP2hKNSxoAaNig38DFE5M0Q6k0PkQdLQv7371M5O
	w0T72XWcg+3rNfGH2uA3Uvg6SnkMR1mBjYkaY0/TyxzE0VvIEG12vOJNXUXv
	TTgsqwp2minKXDOSEJPFJm7EZQxxYTUh/6vm3YnNPEEPEXQrkwO/+J/m5sn2
	0yfsrYxIDCfKebmieqT/JKU18YQJpa4zQp2pFU8ogbfkcTKf0y4RdeCn1eUS
	TBJmlbfrFvEtzQthZFuXmMdgEO2YdedKETUWv9WARpqldcxan6+MYEfpnK94
	Qy4QUIwBzTB2+bFHAvOrhAy1AchXjKygSH0Z/IV6S3hFYlJEWTnn/QXlgWBu
	g+q8yFcA6nYLYlq0MIXqO4CkFuTuDl9h5zrbd24KAnl9fd24Azc3eyxzVsAI
	0NhEkOhqj4PeA12JSYCgQqoaoaK1gKlZnuaLDVjh/iwor8wqxz6XbK5LWcpJ
	fvwatMBpuLnx2+MB6tzhxddwbqJig8bs6NzcPJbeNLSTHoW+5gM5CFlU5dTY
	fIjIXRAoTCqxgos8p8ZJteVOW9hkI2IIMaK1gU6RNY90Y1QERk9OT58z3bTZ
	RLf9BP/s5mYUMuK2WUIlofFoAHAFnXn296S6V4S+pe69eHt+0RvIv/rlK/78
	5uwPb5+9OTvF5/Nvjp8/9x+UbXH+zau3z0+bT03Pk1cvXpy9PJXO9FS3Hqne
	i+M/0S/Yid6r1xfPXr08ft4TeA4hg5GGARkIU5CUQBmiUpGhJVs/lWU9OXn9
	7/9ycETL+wU5a+ODg0fMrF+w2/fgiL5cEQrKbHlGWiVfgVyK1N5EBUaBRzKL
	1kkVpSVbW0LzK3IjCB6IXXe+A2cI0349na0Pjr6yD7Dg1kPHs9ZD5tn2k63O
	wsQdj3ZM47nZet7hdJve4z+1vju+Bw9FLCAjujfdVAZbxOF0wihEjkHvCT1z
	ykBcS8gkZPmVnlFUTH5WsVEIaI1Fzk2WZ5sVS2cvn1WmgvMUQvsLuEUt4LLo
	1YIT8VUttqdQOOAFKKiWFNUulgKjrEMe+UvF0I+es2KzrvJFEa2XFlfF14x1
	nyhjZFwlVSUriuyP+irakLm5sA6FWN6kpIWWYvZ2+Hc1GcEihesq+B9t0jyC
	jyC0MIF9Yk2+XuelmA60a9FHFK+IqogWRvKaVHsOKly0Z12OT+B3oPLQJ9XW
	Jzb1c6D3HeJFfjVMk7K6M1HkZRWbCq6QwEYGFKLoN0ktqgHzEoqd4ZehI9v7
	p+Ag1loXWFPZOGGhe8zaFrInmhE8lfCTCNdTYZ+6SkgHpy0SbTtaWJF8GFhH
	bEFBKcuXOJeBmWV8Ngj5iZgygRdHRmaaZN4fpl719AfaT4YDRCP8baS+Ncye
	OfGqdBsIP0OQGYFKzsJBv9GoBcm89SZbJDrryA2W2Oo50hhTQ/+D6AG+ADPR
	NElhccD7vQF75BSiISFELlnmBMORCgWSpeNpQ1EChC9rbMQxx17IJ5GjlsG+
	gnjGqGnjmEeQau90+vFFolTUVjqoObki02RR53VJux7ECH0zWowYJinGrbxI
	QnTVlui6gEiUhNpaHnX4IJaTP2FXo4QjMyUb1ExOT/uYj4Js/e4iT+J3e7s8
	rrARHlOrcMm8N7yBdoJ+uRcskCj/85//LPkRYuTwa1nCrzHfQPOAX+kv9Xd3
	9HfBo++/Ry91PdFf0JqjZC6h+5e9U2hk4mTQDoYd6t0AEEMvk3dXONUPQlF4
	26R2Zd5yEVTLXu6Jmm0xTPcdn1jDnEiqiKD+QwXIJKEeeCbuUKu+56HTUe+z
	UUBHdiHSUzIF1BFKUZMEB7+LMZBYm9ZkDBlnrHLIqyS/sMvsc8eLL3XI+4oI
	HeiaXIGvPJvBjIDPJ/lqxSaeBd57VwF7Lc8VXPahf8p2SF9/QSRXlqzQuWyc
	zGei85+Kt80t4YAKGepDgbnFz11SbneN4MEoxO1oh8icV+TGF1hiJ7Vkr3uk
	aTlFQyMM3gC4NTNCBimsNyIYThIwMvHGSgC77/2eRYRqA+dMkf9IfjIceSDl
	lTOvrShTxzWkqc0Dh5H96+tzMaXqaDQejUHFsJ3LtP65b6jvSzObHaXJredG
	kF6LOzCH60ZSIZhJEVO6IvXO4lRcllss7GPiKn4rzDx3uE+8ZO++h9xHj9aP
	f4fR1KzWxAKBmR7ha0H82GJj/w79f5jmxHAk/qo7Xj87pjAqAw/GEvi2SIav
	I4SxNAW+/AGzkKPAUKwQDNAO79He/mygZ+OtZin83KtlLkkRY9OPBORwHGaS
	QFnnxMY9u6hu3q1U/SyvjLcexLQVzUGTrnLxKzIGKTtwY2SiVce0SLANLyof
	aDEk4nglVS0NOEO1zFc5TAcZH2WzEnuhx7ELn6ArnOPCaIjKWs0EVkGZgpkp
	nUWwiOd1t8/qRPN8c3Hxeo+CSiKeoiQeCn6idQtlOGxwvSLfl9OoHGYlq6EN
	CjnW+qjbkqE/6teeKoo+6QG12S/3kXdGouCj/vrsQgd//Hu0D4mW31+/vRgE
	jfh3pM+1+/3V+UWrP8CyIcvh5XE3yBc8mxnn3EC2thx2a7RYtu2AAx/YEyPn
	QC8YlxXnrOBMIyogfr6zi3xn859RPGS4FnzAIM/PTiWdVXFzXjO3hmLH+1cE
	RkZMVaTe8ZLfNTCDZrxyGY9Yf1x6i1XCB7PLCo1sxxgNLIqEKQnOsrJkeFGQ
	dG/MAJgmJBbOnc9LqyLL6NI4ZJZuytrAiDZ+QQ76Y/ifZIGJNzbhh6mFLKta
	mcFCkJLgdKAlSnVcXhokJ/BkcXUk0uKfgy67gO1UidWP7ShGdgQefqkJMiU9
	3XWySwwswZSzWZw0FTtWOr0mwS+9jWvZXNUynSPJ6a6SxbLiEACQKyxlBsUB
	a6r8KkLSgsZW/qRGi3Fqjm7IkPQxsZPogc0wZ7peE987iOSygtof2ejLKK1t
	UidTXnKvf0Ot7ty8IyT6hkIgMpMD2W5kSJMC+U3Eoi4B7E5Q5pI1ioBMWez9
	ari+JFornEtxWMSxTcb2JFpEoN3HOcFagZZZOzoZfW5X2Xfk1DGhuGyvM0M4
	aiGCY3ZQo5RxzFrsaQSDQoNgv2l36wrLkvDXbvvM+T7WkS5dcNADt2VVcY6d
	KF3cqJO5P/YBNQSN703cY3SnWI0dlma/PdFW6TT2yR76ODqxf55RjevlUwDe
	YeMUpA0CnJB24yHl0q5wadM5bDQOIZIcHkJzCNBnEAbeDGArXh9fnHyzn/A/
	kEY+bISzxNJPM1yRyVShV+bTu05BXHBCE3IyHkq8y1H9FubxVPLE+o1DvxOM
	hq24/oJ0ZvgZX7YFBx3d/GnTRHHMTowclblDBbdJNgmh7AbhMMWO1NkesMVz
	wrpDjhGyAQPV9mUD59dJ0SqiKd9nyNh1YufpRglJkMTnuUjr8I5zrcTzYJCm
	QdfwqzQfk7kcgOuilmR/CBbIN0/ZzDPY0j5v+a/9sNswIb3CRxpuZWbkJCXl
	Cn5MH1zneH8tx58EG+xSc1a8cCdQveOT5zQbCUPCMMZZ0pdPzy+PyB3/DVKc
	Dx8e3NyQKH/gkZzL55VGnCEkWghO2MsrTCoSvEzWalqL6M+RiPeK0N0q8ibL
	Rlr5eCDYg1w1yYkmvnYYMtqDsyCHS5xtHoC+RngIyZqjvLYzRh5GEavUmzEN
	+ulf52c1v5Q/0dHa8Wd9Kxx1DWdwXoz1nwZO9ofkaDVfTs+en12cbblUQ8ez
	/5Zr9Rmdg+f1lKFOrLz+owCl+AUzG+w6Sv8YWG3qEGXlNtQt89R5tqXzQswH
	U/C5O2OwnQhGoKO57OEgtUWIi6DfhR7j0d0D3R/T/05EZPYa3eJcwSeVQyC6
	Ofq0B6ROsFjTfaxn+QNvHm65Dc+dlysp/I5L7jYKSsPOYqvSQb1ry8I765PI
	Cnn0NPcmL1SD4NzOGxAJ87UVq1UEK29ByzpY8OFpNYSVsUKRhpRq8A6RZMPg
	zMXdtWJHbWeQonQQjDwkgmHE/UpIF85dwM8IYBWqcTY7OWKf4rZHpTG5QDOb
	2xEpYMXDRtmhdglZObCBIdt1OWeGsxhltlLEZpB1SQEeAcbUVFfwyjEeeRoI
	zVuenrh+bBbUFiTNrE48ZvHwTX1QFqUUApesGvWK9wKJiN3KkZRWhSri3Cl8
	qu7JBD32Z8VB9GDdEJ8z9ewT7jrDbjOgatstE3+Pdv3SjJqoyu4GR7Mcv6BZ
	N3LB4Nbdg/Xuxtis1ST5gR/gcisd9+CG08fucCMeeKGYRRYEtlOKLq3h3EUJ
	+Hw2URHB4vqJtbm0OZIOPqPbtMzTujJcb+IURhJQCv/wKBRnbqUpRuy3BJvI
	6cc2WeLtScreBl/v2NMRVCOzXb1zPsc8h0byoXxl1uVEqTsaM9CMRdIUj1Ri
	maHC4pVsfJaja33geK5MseCaF05QeWIw6CYcJbGHSnUWJBLbiyNvUCjqZwSd
	Vh+a7ISlr9NHDsBQUVXIARdZa42GSRGGpq4UakBwlxHqHGCunSq+Y0BJBWJy
	y+MrroOBeaC5+OwDskq2CmfXgQ6+ms+xaTMEzSyxh2MXPBzes4kqGsGOijE6
	RtjmxsMG8gP1Pdxz/LIehav2Ssou/T9NRhhjufhKzA9RtqZopuDyMZw59WMz
	46JSNnktxrLiwbOrK+dYchFICc149cadwBC3KP4hyejkH9jUpKlsMM8p0amL
	+gJUmLkaJD4yh01dNEVZvzt/9RJpXBRKEhp0Ci8Ei9hcxivbRnLzXFj53Xc9
	GwT3BgffD+gbZ2d6g3v8BbmY3mAcnIHYQT7vEZHrksdCJSjU/aO7GufP5Z5N
	NV1fo1xb6iDg/3OhA5ll2nHkAjq1eFZ7GqaoflNxw8VCjWNjS0S2q0MycyUV
	TvhdNfHcQLdL5QIfCYtw+rPHUOT8D1RyqFsqOSbM4eD4gxNN7aMPByrVcqA7
	svmVan6kXjgkIaf2McOtx144dV0AVZ2BqDPOVvQIJzmOO8px6Uv9yz6JJ7kr
	E41KanhOE41yZ4qCJ3pMH0T1JvqQPj89oyhY6tM5IJ7oe8BA+/k+Wje+NXUZ
	P9Z39YjhoQ0OQUuZ8vDwsT74bFPQdHj0WI8/19ITfe+xPvxcY7uqw/uP9dFn
	SZClHj54rO99rq3jy+HDx/r+7sZ7LCSsVk4VvF6hGk5kzMUH3fKEnY6wdwe8
	sqMoq4MJGPgJARREdpoX1Ifkug0U8vyxJKwoVjdc38sB9so5Rvvkp1AUbuQa
	AUyIO6AXgFmaD8O4Xq3Vw8NdMRr+vqBuRbTpH+ICgn44/mSj8Z4txL//YFcj
	eCr9B64N/Y3nDw7pv6P79+7HD+5yGw92thWFMztGqjPJ5fYPfh5Z928l636L
	rPsH9N+MyDqybRzqOqrufZKqez+Pqp2DMVX32lQdEatmDw59Gwv/jqgd8wVE
	jfdCEwHx+VkmguWxP34YmIiX/mCKfImcczfkSkRdLQqDYJjTec2HE/CDPNCF
	BaOFWSCwRKWQf9Ica7uyUxzklia9NKWCPllT2zhPtlR7oJFr4eR6mGKBkrJ9
	dwQcKELr8YEU62zWNlVYl+x3cnzNNpIr9Ukrk8ZQv8DtA32xWRMlrWqqHfXq
	rhqXbyxwnUTZjVZCBFFsRwfBwaW31e+C0tl9wqZfgZ53nPb0m7XVBpv+DseZ
	F3zQGFLBbmNzc0LCHPG0sa9yKM7IZQ/9HmMxUZ1WPmUvBcrKfu213fIejxgM
	0+sYQteAB8dxrZJAKjwm8h66SEObuTh36rBbMp0o2IctRkQeFIHIcWdTiyy0
	QZj2G0JsBRZH5Z3acKm3a3jYHGKUqo8AEFKMGIaP7rPYyzUnBgvJzbBzdJKj
	krsaupLr6+uZfSKSIMUauOrC5abNCcd2DZ/UIJO+pCgB/kB/3289mOBYX5/F
	o4m2lXyS/AgjYDJUiEJtP3SwIPNH+hPO8dkSDWRd7Z0VaHbdq5zjaDl3MB2d
	aVd6YJFJWOqPQCGOO7Ei9x9yf5eV6gVj9iyviw2nJ18iSsTfR31hT3NaIPlR
	vzEsBDPTxU/OUzrVoYa7NAr9iQ/gzIAEtrmNhLS0688u+XZ/+/hT/QmwKa5e
	ZF/2UjMnNbGg/ZI85XDJ1gfZrfPk7dIw5TrCbaAve7YEnPqgr1z+U5OQOKXO
	62nV+tGOpdQbOXOLdXjRaqJf7h8r9Wotp1md3+5Y7Zq0zrBs8BikOpqSu07s
	Kzc9aq5giO11BAEeiSQkHnCMC84TcSHMCUMAQTLEaYhgk23I6rt9gf5pXgWj
	wqSJdHg6Tkl2ciLtlfF0QQhzSfsWtWj5Ly+HKdq9ni2IbS3oDMYd2tQ+NsV+
	2Xi4DzuyR7LgSvW3W15f29t8gs5ufL4kYQpOjdpiw+2+GUV6Sr2up2lSLk0n
	npTB28rQmuA4vDvCSC/VWkkIyhhlu6E7NeOExKapXu5ez+AdnvNtxmDvfD5+
	YAfg7JWRuqRAbnGuWkQLjv0Ckd/mA2dLNuT7f2C8bNUcz7dHkCt/4a0FIbEX
	qj5UtUeWvn9MgSc43ETpDdgEaWPqvzWV7WJJC7OrO6YiMXlNtFH7X8otXHfY
	ZBldRVa/53XBaenAz+Fdwh3ur/mOM/jJBan98K7zHq5SUX9cz27vKZj2xpDW
	XiQE9MeFQb13UTU9RRo5UU0e3YKlAuX6r14CzWClZ/7OpW8g0ikl8fsnnNFx
	ldOpKdBCLoq/dveICPWsavpFEV9vgWV21/6HYJnzRH+F5f8/sMwhAKnt24un
	w4dDF6QhYvwrWP9fBGso8P8SWMtUfwXr28CapnBxmwoDE5ffC2PmncEAF0nu
	APvB7thGzqylOqqBEARYXPr96fcbkJY5PMMByS5oKtV26E7hXb6uUz4rx0wT
	BEmvPZh9ZOPSDpBO+eofW5H981aEtx1CUcgTxHTh59uefKoFAiiswM3TOe2j
	J8E3Uhhk4DshnFciCeeYCe6XTjb+ozu2atWdhvmn9mg/KThreMth2sXStGSP
	doOkhe/Nt1lbOIuOhJN9wwjfQYWVM0jr8RYiP0Fr5xNrky1II5oAnd9tU1Vy
	0z+8eW6UHX3lXiuxfQnUVQvF/lS2BfplN6XjciYOsXEpIPnR2DM2d0ucAItv
	aIXXnHZdxOC3EDTGm0vH+UTXlmBkfPB9xajoKnval7QcjMhl1poP2eWSuZzE
	NvfVQXHp23HOz7PQDxOoPg3R/1nav8cVrY1Zsnugt1JYwufGs4AqlqEN5Awk
	fWzuahyNDlF/qfWw/coZnCwg+UmyO4dlT+V1EXyA4N9qQhBScgJlg2QrDUKb
	k6RcBc1XNAUl+LxWSHF3HQRCClQeLojYFcoPtE4JeWtI4PHrZ+669Zao2urw
	2FyaNF97G4P3iJgCHhgxcVETt1JOlkalclfSVTtV1qmwvCV95PNunTybP5m2
	r87ghHS7Tdlr4fLAArNr31z9BlzM61S139t0kr852wu1X79xCG+hvfNKGz4M
	KpUkukrGZUcQA0kDafYx/cu+4kf97HQbhm9LVw27AHnx5PRgCydvyVXt6jz+
	6bDYZTAB4v5+k5HsJB6ZMMgDT8I66er4acXlbflFW5Hm7WkUvLZiE6jOwZh1
	R/tjaCmoqOCakErh3gNf0hPESetVxtvuN6THZQ1yw9QmICt+7G6fdTrZ7Wp1
	c/4+bmk3JyrRlh/sxXgH4jYpeIVooCbn0KZOUX9+iwI0Rw+FSc0lubEquLYL
	7W1iiXbeWV9/4QKJXSlod/xhmnfCbFXmh2f//FIVvB7AvWKEMQabraCTDNoD
	VK8jQE7NB/uuitK/NIjvO/hX4QRWiVxt7/O0asADETgYHQQiMFLnuElwBWLl
	mq+M7Ou07CsdfCBFbPoWpPMqbJVJaRyJ7l6LKCXHHi0THxgeNaN5CEPoG9tb
	vKLO3Ryvdt+m08hm5xu+EMO3f1kHZGrECHU6J6AtP03D3wSv7hEzjIve7mKq
	nVymw5kQcYeGJtfA3ltovxiKCz7cSwoaG9qyzTCeB3u33XL218PYIeAyJ1fl
	3LkYh1f/4DxR5Afk9sd7wSuhso33EkIaxZbIe4YKW+DnY0a5GRKkPjwBnRPS
	knYMrOSrOlxq5jMEuy6VWkkd2OivXShTtutCbznfElEqZ0ty2awb4y+Kthbo
	qvPr0jsN4unIIUpNLCOF2RNfaIegSXDTVaUQbtxtA+Ec8b/I1wXeVsHsgFsA
	muxrpGbykh32MtrAptsuqHOJmj6ffecCvztApNw6dzwJiEo52cVvSOOKaV8u
	yO9D4BdN2rpariLDIvclMsAdeL59ZN9mg6vzPnr3t218YkEO99ovbuMLacGt
	SZebaCDh08hoK8WwQU0JCMs5n3KSbUy4fl9eweWTBVAzKZz2v+kfavsqKyn1
	5ZpVezdpV63qSOtnc+gubYKRNz6030/A/LV63koHBlmdz19sUTvuz2wVyPKV
	BY+QJoGXSGGL6OWWxw9tI0O2AUohfcFn/laotuh0dzUaYRht3ZeQbXLpnfA1
	Gplu3uHBvoUzDopLir27jjJ/fpeNe48cdm/Xxv0Ulvl7CeoTLGvYZa0J8eC9
	MWs487P3ruBx18uunGD79xHU9kELgn19RYulgsD/8U//LNUZrXJiLVfXfClc
	p1xWqjdcxX6aMOzZHrhZtDvvrKPLKEkjKWQiz5+Ee/aeeDtDF4KChWDKlnMC
	x1TcfhN/2ctyeJ/X19e/S1b6fLaMoviGpA5PnhaofylnEXnvKTtFifvpVRrN
	9RNTLPCKVPfwRVTMcn2RIBfBz0R1r0+WBclIgnuDq/Iv/4Z3W90of42V/BnB
	PilJxosTxG2Mk8K6J93AfIRRj8kJooDthUmz5H1+SWNKcSG2sW5ub+B1Afjf
	Ilr7KIdDRMU5onYwP7BladfP80WURWS89N+a9DLJ4gJYdBNcviVKzZqGjxXu
	55FPz3beh3F2USP1AiYYN9Tfl+KI2qP6Z2fnX2vpysXPdovd+K6UrVyRgPJV
	KTj8TCleNziFXDkXleh9YrIfSCYz/fsort+3KfUXfS+NnRCaaK/F8ItqkIBU
	p8zuvBAe0JKhv0m7Id9VhRUPaur8xWa/OSyM87Sez5X69S/oM9+6Sb8Fokz0
	jncitb06xJNXJFecxeJ4VA+HX+0aCdgX3mdt3SQFSPEZAc5vbx2iVSrYeadG
	52KqjPGf7uZ9eiJaAAA=
	</rfc>		</rfc>
End of changes. 90 change blocks.
	922 lines changed or deleted		270 lines changed or added
This html diff was produced by rfcdiff 1.48.