rfc8790xml2.original.xml   rfc8790.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc strict="no"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<rfc ipr="trust200902" docName="draft-ietf-core-senml-etch-07" category="std"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
docName="draft-ietf-core-senml-etch-07" category="std" obsoletes=""
updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
tocDepth="3" symRefs="true" sortRefs="true" consensus="true" version="3" nu
mber="8790">
<!-- xml2rfc v2v3 conversion 2.41.0 -->
<front> <front>
<title abbrev="FETCH &amp; PATCH with SenML">FETCH &amp; PATCH with Sensor M <title abbrev="FETCH and PATCH with SenML">FETCH and PATCH with Sensor Measu
easurement Lists (SenML)</title> rement Lists (SenML)</title>
<seriesInfo name="RFC" value="8790"/>
<author initials="A." surname="Keranen" fullname="Ari Keranen"> <author initials="A." surname="Keränen" fullname="Ari Keränen">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal>
<street/>
<city>Jorvas</city><code>02420</code>
<country>Finland</country>
</postal>
<email>ari.keranen@ericsson.com</email> <email>ari.keranen@ericsson.com</email>
</address> </address>
</author> </author>
<author initials="M." surname="Mohajer" fullname="Mojan Mohajer"> <author initials="M." surname="Mohajer" fullname="Mojan Mohajer">
<organization></organization> <organization/>
<address> <address>
<email>mojanm@hotmail.com</email> <email>mojanm@hotmail.com</email>
</address> </address>
</author> </author>
<date month="June" year="2020"/>
<date year="2020"/> <keyword>CoAP</keyword>
<keyword>IoT</keyword>
<keyword>Internet-Draft</keyword> <keyword>data model</keyword>
<abstract> <abstract>
<t>The Sensor Measurement Lists (SenML) media type and data model can be
<t>The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or
used to send collections of resources, such as batches of sensor data or configuration parameters. The Constrained Application Protocol (CoAP)
configuration parameters. The CoAP FETCH, PATCH, and iPATCH methods FETCH, PATCH, and iPATCH methods enable accessing and updating parts of
enable accessing and updating parts of a resource or multiple resources a resource or multiple resources with one request. This document defines
with one request. This document defines new media types for the CoAP new media types for the CoAP FETCH, PATCH, and iPATCH methods for
FETCH, PATCH, and iPATCH methods for resources represented with the SenML resources represented using the SenML data model.</t>
data model.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default">
<section anchor="intro" title="Introduction"> <name>Introduction</name>
<t>The Sensor Measurement Lists (SenML) media type <xref target="RFC8428"
<t>The Sensor Measurement Lists (SenML) media type <xref target="RFC8428"/> and format="default"/> and data
data
model can be used to transmit collections of resources, such as model can be used to transmit collections of resources, such as
batches of sensor data or configuration parameters.</t> batches of sensor data or configuration parameters.</t>
<t>An example of a SenML collection is shown below:</t>
<t>An example of a SenML collection is shown below:</t> <sourcecode name="" type="json"><![CDATA[
<figure><artwork><![CDATA[
[ [
{"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":true}, {"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":true},
{"n":"5851", "v":42}, {"n":"5851", "v":42},
{"n":"5750", "vs":"Ceiling light"} {"n":"5750", "vs":"Ceiling light"}
] ]
]]></artwork></figure> ]]></sourcecode>
<t>Here, three resources, "3311/0/5850", "3311/0/5851", and "3311/0/5750",
<t>Here three resources “3311/0/5850”, “3311/0/5851”, and “3311/0/5750”, of a dimmable light smart object <xref target="IPSO" format="default"/> are repr
of an IPSO dimmable light smart object <xref target="IPSO"/> are represented usi esented using
ng
a single SenML Pack with three SenML Records. All resources share the a single SenML Pack with three SenML Records. All resources share the
same base name “2001:db8::2/3311/0/”, hence full names for resources same base name "2001:db8::2/3311/0/"; hence, full names for the resources
are “2001:db8::2/3311/0/5850”, etc.</t> are "2001:db8::2/3311/0/5850", etc.</t>
<t>The CoAP <xref target="RFC7252" format="default"/> FETCH, PATCH, and iP
<t>The CoAP <xref target="RFC7252"/> FETCH, PATCH, and iPATCH methods <xref targ ATCH methods <xref target="RFC8132" format="default"/>
et="RFC8132"/>
enable accessing and updating parts of a resource or multiple resources enable accessing and updating parts of a resource or multiple resources
with one request.</t> with one request.</t>
<t>This document defines two new media types, one using the JavaScript
<t>This document defines two new media types, one using the JavaScript Object Notation (JSON) <xref target="RFC8259" format="default"/> and one using t
Object Notation (JSON) <xref target="RFC8259"/> and one using the Concise Binary he Concise Binary
Object Representation (CBOR) <xref target="RFC7049"/>, which can be used with th Object Representation (CBOR) <xref target="RFC7049" format="default"/>, which ca
e n be used with the
CoAP FETCH, PATCH, and iPATCH methods for resources represented with the CoAP FETCH, PATCH, and iPATCH methods for resources represented using the
SenML data model (i.e., for both SenML and Sensor Streaming Measurement SenML data model (i.e., for both SenML and Sensor Streaming Measurement
Lists (SenSML) data). The rest of the document uses term “(i)PATCH” when Lists (SenSML) data). The rest of the document uses the term "(i)PATCH" when
referring to both methods as the semantics of the new media types are the referring to both methods as the semantics of the new media types are the
same for the CoAP PATCH and iPATCH methods.</t> same for the CoAP PATCH and iPATCH methods.</t>
</section>
</section> <section anchor="terminology" numbered="true" toc="default">
<section anchor="terminology" title="Terminology"> <name>Terminology</name>
<t>
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
“OPTIONAL” in this document are to be interpreted as described in NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, th "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
ey appear in "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
all capitals, as shown here.</t> to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
<t>Readers should also be familiar with the terms and concepts discussed as shown here.
in <xref target="RFC8132"/> and <xref target="RFC8428"/>. The following addition </t>
al terms are used in <t>Readers should also be familiar with the terms and concepts discussed
in <xref target="RFC8132" format="default"/> and <xref target="RFC8428" format="
default"/>. The following additional terms are used in
this document:</t> this document:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Fetch Record:</dt>
<t hangText='Fetch Record:'> <dd>
One set of parameters that is used to match SenML Record(s).</t> One set of parameters that is used to match SenML Record(s).</dd>
<t hangText='Fetch Pack:'> <dt>Fetch Pack:</dt>
One or more Fetch Records in an array structure.</t> <dd>
<t hangText='Patch Record:'> One or more Fetch Records in an array structure.</dd>
<dt>Patch Record:</dt>
<dd>
One set of parameters similar to Fetch Record but also containing One set of parameters similar to Fetch Record but also containing
instructions on how to change existing SenML Pack(s).</t> instructions on how to change existing SenML Pack(s).</dd>
<t hangText='Patch Pack:'> <dt>Patch Pack:</dt>
One or more Patch Records in an array structure.</t> <dd>
<t hangText='Target Record:'> One or more Patch Records in an array structure.</dd>
<dt>Target Record:</dt>
<dd>
A Record in a SenML Pack that matches the selection criteria of A Record in a SenML Pack that matches the selection criteria of
a Fetch or Patch Record and hence is a target for a Fetch or Patch a Fetch or Patch Record and hence is a target for a Fetch or Patch
operation.</t> operation.</dd>
<t hangText='Target Pack:'> <dt>Target Pack:</dt>
A SenML Pack that is a target for a Fetch or Patch operation.</t> <dd>
<t hangText='(i)PATCH:'> A SenML Pack that is a target for a Fetch or Patch operation.</dd>
A term that refers to both CoAP “PATCH” and “iPATCH” methods when <dt>(i)PATCH:</dt>
there is no difference in this specification in which one is used.</t> <dd>
</list></t> A term that refers to both CoAP "PATCH" and "iPATCH" methods when
there is no difference in this specification as to which one is used.</dd>
</section> </dl>
<section anchor="using-fetch-and-ipatch-with-senml" title="Using FETCH and (i)PA </section>
TCH with SenML"> <section anchor="using-fetch-and-ipatch-with-senml" numbered="true" toc="def
ault">
<t>The FETCH/(i)PATCH media types for SenML are modeled as extensions to the <name>Using FETCH and (i)PATCH with SenML</name>
SenML media type to enable re-use of existing SenML parsers and <t>The FETCH/(i)PATCH media types for SenML are modeled as extensions to t
he
SenML media type to enable reuse of existing SenML parsers and
generators, in particular on constrained devices. Unless mentioned generators, in particular on constrained devices. Unless mentioned
otherwise, FETCH and PATCH Packs are constructed with the same rules and otherwise, FETCH and PATCH Packs are constructed with the same rules and
constraints as SenML Packs.</t> constraints as SenML Packs.</t>
<t>The key differences from the SenML media type are allowing the use of a
<t>The key differences to the SenML media type are allowing the use of a "null" value for removing Records with the (i)PATCH method and the lack of
“null” value for removing records with the (i)PATCH method and lack of value fields in Fetch Records. Also, the Fetch and Patch Records do not
value fields in Fetch Records. Also the Fetch and Patch Records do not have a default time or base version when the fields are omitted.</t>
have default time or base version when the fields are omitted.</t> <section anchor="senml-fetch" numbered="true" toc="default">
<name>SenML FETCH</name>
<section anchor="senml-fetch" title="SenML FETCH"> <t>The FETCH method can be used to select and return a subset of Records
, in
<t>The FETCH method can be used to select and return a subset of records, in
sequence, of one or more SenML Packs. The SenML Records are selected by sequence, of one or more SenML Packs. The SenML Records are selected by
giving a set of names that, when resolved, match resolved names in a giving a set of names that, when resolved, match resolved names in a
Target SenML Pack. The names for a Fetch Pack are given using the SenML Target SenML Pack. The names for a Fetch Pack are given using the SenML
“name” and/or “base name” fields. The names are resolved by concatenating "name" and/or "base name" fields. The names are resolved by concatenating
the base name with the name field as defined in <xref target="RFC8428"/>.</t> the base name with the name field as defined in <xref target="RFC8428" format="d
efault"/>.</t>
<t>A Fetch Pack MUST contain at least one Fetch Record. A Fetch Record MUST <t>A Fetch Pack <bcp14>MUST</bcp14> contain at least one Fetch Record. A
contain a name and/or a base name field.</t> Fetch Record <bcp14>MUST</bcp14>
contain a name and/or base name field.</t>
<t>For example, to select the IPSO resources “5850” and “5851” from the <t>For example, to select the resources "5850" and "5851" from the
example in <xref target="intro"/>, the following Fetch Pack can be used:</t> example in <xref target="intro" format="default"/>, the following Fetch Pack can
be used:</t>
<figure><artwork><![CDATA[ <sourcecode name="" type="json"><![CDATA[
[ [
{"bn":"2001:db8::2/3311/0/", "n":"5850"}, {"bn":"2001:db8::2/3311/0/", "n":"5850"},
{"n":"5851"} {"n":"5851"}
] ]
]]></artwork></figure> ]]></sourcecode>
<t>The result to a FETCH request with the example above would be:</t>
<figure><artwork><![CDATA[ <t>The result of a FETCH request with the example above would be:</t>
<sourcecode name="" type="json"><![CDATA[
[ [
{"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":true}, {"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":true},
{"n":"5851", "v":42}, {"n":"5851", "v":42},
] ]
]]></artwork></figure> ]]></sourcecode>
<t>The SenML time and unit fields can be used in a Fetch Record to furth
<t>The SenML time and unit fields can be used in a Fetch Record to further er
narrow the selection of matched SenML Records. When no time or unit is narrow the selection of matched SenML Records. When no time or unit is
given in a Fetch Record, all SenML Records with the given name are given in a Fetch Record, all SenML Records with the given name are
matched (i.e., unlike with SenML Records, lack of time field in a Fetch matched (i.e., unlike with SenML Records, the lack of time field in a Fetch
Record does not imply time value zero). When time is given in the Fetch Record does not imply a time value of zero).
Record, only the SenML Records (if any) with equal resolved time value
and name are matched. Similarly, when unit is given, only the SenML When time is given in the Fetch
Records with equal resolved unit and name are matched. If both time and Record, a Target Record is matched only when its resolved time value and name
unit are given in the Fetch Record, both MUST to match for the SenML are equal to those of the Fetch Record. Similarly, when unit is given, a
Record to match. Each Target Record MUST be included in the response at Target Record is matched only when its resolved unit and name are equal to
those of the Fetch Record. If both the time and unit are given in the Fetch
Record, a Target Record is matched only when both are equal to those of the
Fetch Record. Each Target Record <bcp14>MUST</bcp14> be included in the response
at
most once, even if multiple Fetch Records match with the same Target most once, even if multiple Fetch Records match with the same Target
Record.</t> Record.</t>
<t>For example, if the resource "5850" had multiple sensor
<t>For example, if the IPSO resource “5850” would have multiple sensor readings (SenML Records) with different time values, the following Fetch
readings (SenML Records) with different time values, the following Fetch Pack can be used to retrieve the Record with time "1.276020091e+09":</t>
Pack can be used to retrieve the Record with time “1.276020091e+09”:</t> <sourcecode name="" type="json"><![CDATA[
<figure><artwork><![CDATA[
[ [
{"bn":"2001:db8::2/3311/0/", "n":"5850", "t":1.276020091e+09} {"bn":"2001:db8::2/3311/0/", "n":"5850", "t":1.276020091e+09}
] ]
]]></artwork></figure> ]]></sourcecode>
<t>The resolved form of Records (<xref target="RFC8428"
<t>The resolved form of records (Section 4.6 of <xref target="RFC8428"/>) is use sectionFormat="of" section="4.6"/>) is used when
d when
comparing the names, times, and units of the Target and Fetch Records to comparing the names, times, and units of the Target and Fetch Records to
accommodate for differences in use of the base values. In resolved form accommodate differences in the use of the base values. In the resolved form,
the SenML name in the example above becomes “2001:db8::2/3311/0/5850”. the SenML name in the example above becomes "2001:db8::2/3311/0/5850".
Since there is no base time in the Pack, the time in resolved form is Since there is no base time in the Pack, the time in resolved form is
equal to the time in the example.</t> equal to the time in the example.</t>
<t>If no SenML Records match, an empty SenML Pack (i.e., array with no
<t>If no SenML Records match, empty SenML Pack (i.e., array with no
elements) is returned as a response.</t> elements) is returned as a response.</t>
<t>Fetch Records <bcp14>MUST NOT</bcp14> contain other fields than
<t>Fetch Records MUST NOT contain other fields than name, base name, time, name, base name, time,
base time, unit, and base unit. Implementations MUST reject and generate base time, unit, and base unit. Implementations <bcp14>MUST</bcp14> reject and g
an error for a Fetch Pack with other fields. <xref target="RFC8132"/> Section 2. enerate
2 an error for a Fetch Pack with other fields. <xref target="RFC8132"
provides guidance for FETCH request error handling, e.g., using the 4.22 sectionFormat="comma" section="2.2"/> provides guidance for FETCH request error
handling, e.g., using the 4.22
(Unprocessable Entity) CoAP error response code.</t> (Unprocessable Entity) CoAP error response code.</t>
</section>
</section> <section anchor="senml-ipatch" numbered="true" toc="default">
<section anchor="senml-ipatch" title="SenML (i)PATCH"> <name>SenML (i)PATCH</name>
<t>The (i)PATCH method can be used to change the fields of SenML Records
<t>The (i)PATCH method can be used to change the fields of SenML Records, to , to
add new Records, and to remove existing Records. The names, times, and add new Records, and to remove existing Records. The names, times, and
units of the Patch Records are given and matched in same way as for the units of the Patch Records are given and matched in the same way as for the
Fetch Records, except each Patch Record MUST match at most one Target Fetch Records, except each Patch Record <bcp14>MUST</bcp14> match at most one Ta
rget
Record. A Patch Record matching more than one Target Record is considered Record. A Patch Record matching more than one Target Record is considered
invalid (patching multiple Target Records with one Patch Record would invalid (patching multiple Target Records with one Patch Record would
result in multiple copies of the same record). Patch Packs can also result in multiple copies of the same Record). Patch Packs can also
include new values and other SenML fields for the Records. Application of include new values and other SenML fields for the Records. Application of
Patch Packs is idempotent; hence PATCH and iPATCH methods for SenML Packs Patch Packs is idempotent; hence, the PATCH and iPATCH methods for SenML Packs
are equivalent.</t> are equivalent.</t>
<t>When the name in a Patch Record matches with the name in an existing
<t>When the name in a Patch Record matches with the name in an existing
Record, the resolved time values and units (if any) are compared. If the Record, the resolved time values and units (if any) are compared. If the
time values and units either do not exist in both Records or are equal, time values and units either do not exist in both Records or are equal,
the Target Record is replaced with the contents of the Patch Record. All the Target Record is replaced with the contents of the Patch Record. All
Patch Records MUST contain at least a SenML Value or Sum field.</t> Patch Records <bcp14>MUST</bcp14> contain at least a SenML Value or Sum field.</
t>
<t>If a Patch Record contains a name, or combination of a time value, unit, <t>If a Patch Record contains a name, or the combination of a time value
and a name, that do not exist in any existing Record in the Pack, the , unit,
and name, that does not exist in any existing Record in the Pack, the
given Record, with all the fields it contains, is added to the Pack.</t> given Record, with all the fields it contains, is added to the Pack.</t>
<t>If a Patch Record has a value ("v") field with a null value, it <bcp1
<t>If a Patch Record has a value (“v”) field with value null, it MUST NOT be 4>MUST NOT</bcp14> be
added but the matched Record (if any) is removed from the Target Pack.</t> added, but the matched Record (if any) is removed from the Target Pack.</t>
<t>The Patch Records <bcp14>MUST</bcp14> be applied in the same
<t>The Patch Records MUST be applied in the same sequence they are in the sequence as they are in the
Patch Pack. If multiple Patch Packs are being processed at the same time, Patch Pack. If multiple Patch Packs are being processed at the same time,
the result MUST be equivalent to applying them in one sequence.</t> the result <bcp14>MUST</bcp14> be equivalent to applying them in one sequence.</
t>
<t>Implementations MUST reject and generate an error for Patch Packs with <t>Implementations <bcp14>MUST</bcp14> reject and generate an error for
Patch Packs with
invalid Records. If a Patch Pack is rejected, the state of the Target invalid Records. If a Patch Pack is rejected, the state of the Target
Pack is not changed, i.e., either all or none of the Patch Records are Pack is not changed, i.e., either all or none of the Patch Records are
applied. <xref target="RFC8132"/> Section 3.4 provides guidance for error handli ng applied. <xref target="RFC8132" sectionFormat="comma" section="3.4"/> provides g uidance for error handling
with PATCH and iPATCH requests, e.g., using the 4.22 (Unprocessable with PATCH and iPATCH requests, e.g., using the 4.22 (Unprocessable
Entity) and 4.09 (Conflict) CoAP error response codes.</t> Entity) and 4.09 (Conflict) CoAP error response codes.</t>
<t>For example, the following document could be given as an (i)PATCH pay
<t>For example, the following document could be given as an (i)PATCH payload load
to change/set values of two SenML Records for the example in to change/set the values of two SenML Records for the example in
<xref target="intro"/>:</t> <xref target="intro" format="default"/>:</t>
<sourcecode name="" type="json"><![CDATA[
<figure><artwork><![CDATA[
[ [
{"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":false}, {"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":false},
{"n":"5851", "v":10} {"n":"5851", "v":10}
] ]
]]></artwork></figure> ]]></sourcecode>
<t>If the request is successful, the resulting representation of the
<t>If the request is successful, the resulting representation of the
example SenML Pack would be as follows:</t> example SenML Pack would be as follows:</t>
<sourcecode name="" type="json"><![CDATA[
<figure><artwork><![CDATA[
[ [
{"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":false}, {"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":false},
{"n":"5851", "v":10}, {"n":"5851", "v":10},
{"n":"5750", "vs":"Ceiling light"} {"n":"5750", "vs":"Ceiling light"}
] ]
]]></artwork></figure> ]]></sourcecode>
<t>As another example, the following document could be given as an (i)PA
<t>As another example, the following document could be given as an (i)PATCH TCH
payload to remove the two SenML Records:</t> payload to remove the two SenML Records:</t>
<sourcecode name="" type="json"><![CDATA[
<figure><artwork><![CDATA[
[ [
{"bn":"2001:db8::2/3311/0/", "n":"5850", "v":null}, {"bn":"2001:db8::2/3311/0/", "n":"5850", "v":null},
{"n":"5851", "v":null} {"n":"5851", "v":null}
] ]
]]></artwork></figure> ]]></sourcecode>
</section>
</section> </section>
</section> <section anchor="fragment-identification" numbered="true" toc="default">
<section anchor="fragment-identification" title="Fragment Identification"> <name>Fragment Identification</name>
<t>Fragment identification for Records of Fetch and Patch Packs uses the
<t>Fragment identification for Records of Fetch and Patch Packs uses the same mechanism as SenML JSON/CBOR fragment identification (see <xref
same mechanism as SenML JSON/CBOR fragment identification (see Section 9 target="RFC8428" sectionFormat="of" section="9"/>), i.e., the "rec" scheme follo
of <xref target="RFC8428"/>), i.e., “rec” scheme followed by a comma-separated l wed by a comma-separated list of
ist of
Record positions or range(s) of Records. For example, to select the 3rd Record positions or range(s) of Records. For example, to select the 3rd
and 5th Record of a Fetch or Patch Pack, a fragment identifier “rec=3,5” and 5th Record of a Fetch or Patch Pack, a fragment identifier "rec=3,5"
can be used in the URI of the Fetch or Patch Pack resource.</t> can be used in the URI of the Fetch or Patch Pack resource.</t>
</section>
</section> <section anchor="extensibility" numbered="true" toc="default">
<section anchor="extensibility" title="Extensibility"> <name>Extensibility</name>
<t>The SenML mandatory-to-understand field extensibility mechanism (see
<t>The SenML mandatory to understand fields extensibility mechanism (see <xref target="RFC8428" sectionFormat="of" section="4.4"/>) does not apply to Pat
section 4.4 in <xref target="RFC8428"/>) does not apply to Patch Packs, i.e., un ch Packs, i.e., unknown
known fields <bcp14>MUST NOT</bcp14> generate an error, but such fields are treated li
fields MUST NOT generate an error but such fields are treated like any ke any
other field (e.g., added to Patch target records where applicable).</t> other field (e.g., added to Patch target Records where applicable).</t>
<t>This specification allows only a small subset of SenML fields in Fetch
<t>This specification allows only a small subset of SenML fields in Fetch Records, but future specifications may enable new fields for Fetch Records
Records but future specifications may enable new fields for Fetch Records
and possibly also new fields for selecting targets for Patch Records.</t> and possibly also new fields for selecting targets for Patch Records.</t>
</section>
</section> <section anchor="seccons" numbered="true" toc="default">
<section anchor="seccons" title="Security Considerations"> <name>Security Considerations</name>
<t>The security and privacy considerations of SenML also apply to the
<t>The security and privacy considerations of SenML apply also with the FETCH and (i)PATCH methods. CoAP's security mechanisms are used to
FETCH and (i)PATCH methods. CoAP’s security mechanisms are used to
provide security for the FETCH and (i)PATCH methods.</t> provide security for the FETCH and (i)PATCH methods.</t>
<t>In FETCH and (i)PATCH requests, the client can pass arbitrary names to
<t>In FETCH and (i)PATCH requests, the client can pass arbitrary names to
the target resource for manipulation. The resource implementer must take the target resource for manipulation. The resource implementer must take
care to only allow access to names that are actually part of (or care to only allow access to names that are actually part of (or
accessible through) the target resource. In particular the receiver needs accessible through) the target resource. In particular, the receiver needs
to ensure that any input does not lead to uncontrolled special to ensure that any input does not lead to uncontrolled special
interpretation by the system.</t> interpretation by the system.</t>
<t>If the client is not allowed to do a GET or PUT on the full target
<t>If the client is not allowed to do a GET or PUT on the full target
resource (and thus all the names accessible through it), access resource (and thus all the names accessible through it), access
control rules must be evaluated for each record in the pack.</t> control rules must be evaluated for each Record in the Pack.</t>
</section>
</section> <section anchor="iana" numbered="true" toc="default">
<section anchor="iana" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document registers two new media types and CoAP Content-Format IDs
<t>This document registers two new media types and CoAP Content-Format IDs
for both media types.</t> for both media types.</t>
<section anchor="coap-content-format-registration" numbered="true" toc="de
<t>Note to RFC Editor: Please replace all occurrences of “RFC-AAAA” with fault">
the RFC number of this document.</t> <name>CoAP Content-Format Registration</name>
<t>IANA has assigned CoAP Content-Format IDs for the SenML PATCH
<section anchor="coap-content-format-registration" title="CoAP Content-Format Re and FETCH media types in the "CoAP Content-Formats" subregistry, within
gistration"> the "Constrained RESTful Environments (CoRE) Parameters" registry <xref target="
RFC7252" format="default"/>. The assigned IDs are shown in
<t>IANA is requested to assign CoAP Content-Format IDs for the SenML PATCH <xref target="tbl-coap-content-formats" format="default"/>.</t>
and FETCH media types in the “CoAP Content-Formats” sub-registry, within <table anchor="tbl-coap-content-formats" align="center">
the “CoRE Parameters” registry <xref target="RFC7252"/>. The assigned IDs are sh <name>CoAP Content-Format IDs</name>
own in <thead>
<xref target="tbl-coap-content-formats"/>.</t> <tr>
<th align="left">Media Type</th>
<texttable title="CoAP Content-Format IDs" anchor="tbl-coap-content-formats"> <th align="left">Encoding</th>
<ttcol align='left'>Media type</ttcol> <th align="left">ID</th>
<ttcol align='left'>Encoding</ttcol> </tr>
<ttcol align='left'>ID</ttcol> </thead>
<c>application/senml-etch+json</c> <tbody>
<c>-</c> <tr>
<c>TBD-320</c> <td align="left">application/senml-etch+json</td>
<c>application/senml-etch+cbor</c> <td align="left">-</td>
<c>-</c> <td align="left">320</td>
<c>TBD-322</c> </tr>
</texttable> <tr>
<td align="left">application/senml-etch+cbor</td>
</section> <td align="left">-</td>
<section anchor="senml-etchjson-media-type" title="senml-etch+json Media Type"> <td align="left">322</td>
</tr>
<t>Type name: application</t> </tbody>
</table>
<t>Subtype name: senml-etch+json</t> </section>
<section anchor="senml-etchjson-media-type" numbered="true"
<t>Required parameters: N/A</t> toc="default">
<name>senml-etch+json Media Type</name>
<t>Optional parameters: N/A</t> <dl newline="false">
<dt>Type name:</dt><dd>application</dd>
<t>Encoding considerations: binary</t> <dt>Subtype name:</dt><dd>senml-etch+json</dd>
<dt>Required parameters:</dt><dd>N/A</dd>
<t>Security considerations: See <xref target="seccons"/> of RFC-AAAA.</t> <dt>Optional parameters:</dt><dd>N/A</dd>
<dt>Encoding considerations:</dt><dd>binary</dd>
<t>Interoperability considerations: N/A</t> <dt>Security considerations:</dt><dd>See <xref target="seccons" format="default"
/> of RFC 8790.</dd>
<t>Published specification: RFC-AAAA</t> <dt>Interoperability considerations:</dt><dd>N/A</dd>
<dt>Published specification:</dt><dd>RFC 8790</dd>
<t>Applications that use this media type: Applications that use the <dt>Applications that use this media type:</dt><dd>Applications that use the
SenML media type for resource representation.</t> SenML media type for resource representation.</dd>
<dt>Fragment identifier considerations:</dt><dd>Fragment identification for
<t>Fragment identifier considerations: Fragment identification for
application/senml-etch+json is supported by using fragment identifiers as application/senml-etch+json is supported by using fragment identifiers as
specified by RFC AAAA.</t> specified by <xref target="fragment-identification"/> of RFC 8790.</dd>
<dt>Additional information:</dt>
<t>Additional information:</t> <dd><t><br/></t>
<dl>
<t>Deprecated alias names for this type: N/A</t> <dt>Deprecated alias names for this type:</dt><dd>N/A</dd>
<dt>Magic number(s):</dt><dd>N/A</dd>
<t>Magic number(s): N/A</t> <dt>File extension(s):</dt><dd>senml-etchj</dd>
<dt>Windows Clipboard Name:</dt><dd>"SenML FETCH/PATCH format"</dd>
<t>File extension(s): senml-etchj</t> <dt>Macintosh file type code(s):</dt><dd>N/A</dd>
<dt>Macintosh Universal Type Identifier code:</dt><dd><t><br/>org.ietf.senml-e
<t>Windows Clipboard Name: “SenML FETCH/PATCH format”</t> tch-json
conforms to public.text</t></dd>
<t>Macintosh file type code(s): N/A</t> </dl>
</dd>
<t>Macintosh Universal Type Identifier code: org.ietf.senml-etch-json <dt>Person &amp; email address to contact for further
conforms to public.text</t> information:</dt><dd><t><br/><contact fullname="Ari Keränen"/> &lt;ari.keranen@e
ricsson.com&gt;</t></dd>
<t>Person &amp; email address to contact for further information: <dt>Intended usage:</dt><dd>COMMON</dd>
Ari Keranen ari.keranen@ericsson.com</t> <dt>Restrictions on usage:</dt><dd>N/A</dd>
<dt>Author:</dt><dd><t><contact fullname="Ari Keränen"/> &lt;ari.keranen@ericsso
<t>Intended usage: COMMON</t> n.com&gt;</t></dd>
<dt>Change controller:</dt><dd>IESG</dd>
<t>Restrictions on usage: N/A</t> </dl>
</section>
<t>Author: Ari Keranen ari.keranen@ericsson.com</t> <section anchor="senml-etchcbor-media-type" numbered="true"
toc="default">
<t>Change controller: IESG</t> <name>senml-etch+cbor Media Type</name>
<dl newline="false">
</section> <dt>Type name:</dt><dd>application</dd>
<section anchor="senml-etchcbor-media-type" title="senml-etch+cbor Media Type"> <dt>Subtype name:</dt><dd>senml-etch+cbor</dd>
<dt>Required parameters:</dt><dd>N/A</dd>
<t>Type name: application</t> <dt>Optional parameters:</dt><dd>N/A</dd>
<dt>Encoding considerations:</dt><dd>binary</dd>
<t>Subtype name: senml-etch+cbor</t> <dt>Security considerations:</dt><dd>See <xref target="seccons" format="default"
/> of RFC 8790.</dd>
<t>Required parameters: N/A</t> <dt>Interoperability considerations:</dt><dd>N/A</dd>
<dt>Published specification:</dt><dd>RFC 8790</dd>
<t>Optional parameters: N/A</t> <dt>Applications that use this media type:</dt><dd>Applications that use the
SenML media type for resource representation.</dd>
<t>Encoding considerations: binary</t> <dt>Fragment identifier considerations:</dt><dd>Fragment identification for
<t>Security considerations: See <xref target="seccons"/> of RFC-AAAA.</t>
<t>Interoperability considerations: N/A</t>
<t>Published specification: RFC-AAAA</t>
<t>Applications that use this media type: Applications that use the
SenML media type for resource representation.</t>
<t>Fragment identifier considerations: Fragment identification for
application/senml-etch+cbor is supported by using fragment identifiers as application/senml-etch+cbor is supported by using fragment identifiers as
specified by RFC AAAA.</t> specified by <xref target="fragment-identification"/> of RFC 8790.</dd>
<dt>Additional information:</dt>
<t>Additional information:</t> <dd><t><br/></t>
<dl newline="false">
<t>Deprecated alias names for this type: N/A</t> <dt>Deprecated alias names for this type:</dt><dd>N/A</dd>
<dt>Magic number(s):</dt><dd>N/A</dd>
<t>Magic number(s): N/A</t> <dt>File extension(s):</dt><dd>senml-etchc</dd>
<dt>Macintosh file type code(s):</dt><dd>N/A</dd>
<t>File extension(s): senml-etchc</t> <dt>Macintosh Universal Type Identifier code:</dt>
<dd><t><br/>org.ietf.senml-etch-cbor conforms to public.data</t></dd>
<t>Macintosh file type code(s): N/A</t> </dl>
</dd>
<t>Macintosh Universal Type Identifier code: org.ietf.senml-etch-cbor <dt>Person &amp; email address to contact for further information:</dt>
conforms to public.data</t> <dd><t><br/><contact fullname="Ari Keränen"/> &lt;ari.keranen@ericsson.com&gt;</
t></dd>
<t>Person &amp; email address to contact for further information: <dt>Intended usage:</dt><dd>COMMON</dd>
Ari Keranen ari.keranen@ericsson.com</t> <dt>Restrictions on usage:</dt><dd>N/A</dd>
<dt>Author:</dt><dd><t><contact fullname="Ari Keränen"/> &lt;ari.keranen@ericsso
<t>Intended usage: COMMON</t> n.com&gt;</t></dd>
<dt>Change controller:</dt><dd>IESG</dd>
<t>Restrictions on usage: N/A</t> </dl>
</section>
<t>Author: Ari Keranen ari.keranen@ericsson.com</t> </section>
<t>Change controller: IESG</t>
</section>
</section>
<section anchor="acks" title="Acknowledgements">
<t>The use of FETCH and (i)PATCH methods with SenML was first introduced by
the OMA SpecWorks LwM2M v1.1 specification. This document generalizes the
use to any SenML representation. The authors would like to thank Carsten
Bormann, Christian Amsuess, Jaime Jimenez, Klaus Hartke, Michael
Richardson, and other participants from the IETF CoRE and OMA SpecWorks
DMSE working groups who have contributed ideas and reviews.</t>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8428.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7252.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8132.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8259.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7049.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
</references>
<references>
<name>Informative References</name>
<references title='Normative References'> <reference anchor="IPSO" target="http://www.openmobilealliance.org/tech/
profiles/lwm2m/3311.xml">
<reference anchor="RFC8428" target='https://www.rfc-editor.org/info/rfc8428'> <front>
<front> <title>IPSO Light Control Smart Object</title>
<title>Sensor Measurement Lists (SenML)</title> <author>
<author initials='C.' surname='Jennings' fullname='C. Jennings'><organization /> <organization>IPSO</organization>
</author> </author>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></au <date year="2019"/>
thor> </front>
<author initials='J.' surname='Arkko' fullname='J. Arkko'><organization /></auth </reference>
or> </references>
<author initials='A.' surname='Keranen' fullname='A. Keranen'><organization /></
author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></
author>
<date year='2018' month='August' />
<abstract><t>This specification defines a format for representing simple sensor
measurements and device parameters in Sensor Measurement Lists (SenML). Represe
ntations are defined in JavaScript Object Notation (JSON), Concise Binary Object
Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Inte
rchange (EXI), which share the common SenML data model. A simple sensor, such a
s a temperature sensor, could use one of these media types in protocols such as
HTTP or the Constrained Application Protocol (CoAP) to transport the measurement
s of the sensor or to be configured.</t></abstract>
</front>
<seriesInfo name='RFC' value='8428'/>
<seriesInfo name='DOI' value='10.17487/RFC8428'/>
</reference>
<reference anchor="RFC7252" target='https://www.rfc-editor.org/info/rfc7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></au
thor>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></au
thor>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></
author>
<date year='2014' month='June' />
<abstract><t>The Constrained Application Protocol (CoAP) is a specialized web tr
ansfer protocol for use with constrained nodes and constrained (e.g., low-power,
lossy) networks. The nodes often have 8-bit microcontrollers with small amount
s of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireles
s Personal Area Networks (6LoWPANs) often have high packet error rates and a typ
ical throughput of 10s of kbit/s. The protocol is designed for machine- to-mach
ine (M2M) applications such as smart energy and building automation.</t><t>CoAP
provides a request/response interaction model between application endpoints, sup
ports built-in discovery of services and resources, and includes key concepts of
the Web such as URIs and Internet media types. CoAP is designed to easily inte
rface with HTTP for integration with the Web while meeting specialized requireme
nts such as multicast support, very low overhead, and simplicity for constrained
environments.</t></abstract>
</front>
<seriesInfo name='RFC' value='7252'/>
<seriesInfo name='DOI' value='10.17487/RFC7252'/>
</reference>
<reference anchor="RFC8132" target='https://www.rfc-editor.org/info/rfc8132'>
<front>
<title>PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)</
title>
<author initials='P.' surname='van der Stok' fullname='P. van der Stok'><organiz
ation /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></
author>
<author initials='A.' surname='Sehgal' fullname='A. Sehgal'><organization /></au
thor>
<date year='2017' month='April' />
<abstract><t>The methods defined in RFC 7252 for the Constrained Application Pro
tocol (CoAP) only allow access to a complete resource, not to parts of a resourc
e. In case of resources with larger or complex data, or in situations where res
ource continuity is required, replacing or requesting the whole resource is unde
sirable. Several applications using CoAP need to access parts of the resources.
</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="RFC8259" target='https://www.rfc-editor.org/info/rfc8259'>
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author initials='T.' surname='Bray' fullname='T. Bray' role='editor'><organizat
ion /></author>
<date year='2017' month='December' />
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, lan
guage-independent data interchange format. It was derived from the ECMAScript P
rogramming Language Standard. JSON defines a small set of formatting rules for
the portable representation of structured data.</t><t>This document removes inco
nsistencies with other specifications of JSON, repairs specification errors, and
offers experience-based interoperability guidance.</t></abstract>
</front>
<seriesInfo name='STD' value='90'/>
<seriesInfo name='RFC' value='8259'/>
<seriesInfo name='DOI' value='10.17487/RFC8259'/>
</reference>
<reference anchor="RFC7049" target='https://www.rfc-editor.org/info/rfc7049'>
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></
author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></
author>
<date year='2013' month='October' />
<abstract><t>The Concise Binary Object Representation (CBOR) is a data format wh
ose design goals include the possibility of extremely small code size, fairly sm
all message size, and extensibility without the need for version negotiation. T
hese design goals make it different from earlier binary serializations such as A
SN.1 and MessagePack.</t></abstract>
</front>
<seriesInfo name='RFC' value='7049'/>
<seriesInfo name='DOI' value='10.17487/RFC7049'/>
</reference>
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></
author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify
the requirements in the specification. These words are often capitalized. This
document defines these words as they should be interpreted in IETF documents.
This document specifies an Internet Best Current Practices for the Internet Comm
unity, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
</references>
<references title='Informative References'>
<reference anchor="IPSO" target="http://www.openmobilealliance.org/tech/profiles
/lwm2m/3311.xml">
<front>
<title>IPSO Light Control Smart Object</title>
<author >
<organization>IPSO</organization>
</author>
<date year="2018"/>
</front>
</reference>
</references> </references>
<section anchor="acks" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The use of the FETCH and (i)PATCH methods with SenML was first
introduced by the OMA SpecWorks Lightweight Machine to Machine (LwM2M)
v1.1 specification. This document generalizes the use to any SenML
representation. The authors would like to thank <contact
fullname="Carsten Bormann"/>, <contact fullname="Christian Amsüss"/>,
<contact fullname="Jaime Jiménez"/>, <contact fullname="Klaus Hartke"/>,
<contact fullname="Michael Richardson"/>, and other participants from
the IETF CoRE and OMA SpecWorks DMSE working groups who have contributed
ideas and reviews.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAPOiZl4AA+1ba28bOZb9zl/BVYCJjZFkW3EmiRYNjOI40+6J7YztTGOx
WCyoKspiXK8tVlmtzqR/+94HyWKV5STdgwZ2F9sfOq4qPi7v49xzSWoymQjb
qCL9T5WVhZ7Lpm61MFVNf9lmdnj46nAm0jIpVA6f01qtmonRzWqSlLWeWF3k
2UQ3yXpy+ELc6e2mrNO5PCsaXRe6mbzB9iJRzVzaJhWVmQspmzKZy6dbbZ/y
Q5lXKml6r1JdNWt488w9myLVRdTEbvNar2z0oqyb/hsYNoc+0RtTZAbXGPo0
taF5i9J1cHLws22X/VeNaTLo/vb05uR7+Qf5foH/bkyzlte6AAHkuVa2rTVO
K98Z21i5B1/O3+0LtVzW+v6xvufvRKoaGHp2ODsUqm3WZT0XExAYpF9M5V91
rQpdgExshUVtondlfTuXp7AUa0t81rky2Vyq2kzvuNGftfs6hQX5cc+n8rxc
q4+6DuOelx9VEb11I+X4Ov/zumzwmcYoyjpXjbnXaM+rtycvj2cv58IUq/j9
2fvrS/wXLKjqWw1qXDdNNT842Gw207IC1ymXJtMqy4wqEj2FhRw0OlkfVHW5
gg/2INvks/zg2bOjo+lPecZDsRGe4uCg5Nt1I0/KoqnLTF7nqm7k5fKjTpqn
1NirEv+esKKwHz17jR+9FEJMJhOpluAQYG0hbtb6qyaVuU6Nks220hLiB4dT
oKlUZzIBJS61aK1OwXclxEgKzpVlIJYpCyvLlay1Lds60XYMbpaspbJyqSCK
NH21PDcNWdYiKYuVuW1rhd1lpWowFsSXnUoU9KRcvGe/GrNbjUkewy4GLddl
aoUu1DIDSROY05riltq0FUyBDzBmQzOrIBlMLPM2a0wF3YK4glwWkAJe/Ver
bYMyGCsBIFrSUapXEGNWFnoTachKcAzZOGnF16Sl1mFO+KuCBxgd9EnzN2wf
Dhun9SkbMTdpmmmw6BMEobpMW1K6/PTE4OPnX2/cT5+cf3/+HAwtYkNLb2jw
nsLmpvm6scWjxpaPGluIRSH1TypHg5CpSNZoMgmGsOtyg0Jl5WYuxC+//CL+
XchPo2Uxmo8AzI/m6fLlfD6jmDo4PBiN5Qg/PX/5/BD/vl+O5pgCPo+xl/ty
RF9G8+NZ9PqF62Dh4USbDN0ow3AcfRb/QROL73WtwVa1jhxIjtzMfsbuEadB
BYdXNIXApRYUtjI1eU5uTBNJS/FeUryDmbAJ2qjWPY9p0d2FkvhP5vxGvlfJ
nfcllI/fXmlIainE1SLLIpHtWtFCtLBgDAhUqwkw5SMaXWtAM7lqYRBsNnBn
gYPt6uk0Asl0yl5Kkf3p07+A/72YPZ/B2r4aONz65dEzaP37xTyKtyvom005
DPwxdSQbUNj+oO7VdVKbqhEM1PKibNjX9364vrzY90uYPX/lAq4/AIB9YsAA
r02h6q0f5Mob3A118vryyg/14vAYhhrLzdpA8MUx68FEfBOGfgMqCfajKBfs
mamejqnrsvTZngZ3GHQNtEXluLoIjUSHRtcIRzjgPsM9zNmg1VAXwQCwGtC+
rnM52jP7JPUI1gv0ADiRrmtSXskS+NVAysExLCT5ogF64AcdInfP92MYdyTm
oaKmiL43II0pyqy83bI3AzmUyA4BAs4/XN9g7OO/8uKS/r46/duHs6vTN/j3
9feLd+/CH9xCwMPlh3fuO/7V9Ty5PD8/vXjDneGtHLw6X/wbY4sYXb6/Obu8
WLwbAQmClcReTAst0TkM0lewLpoW1JRqCx67hAdTiNcn7+XRsXOt2dEReqmP
uhfH8IBqHzvHzbbuEXS2laqqtKpxEKA84IiVaVQGEaI8bK8BMEF5V1qlgPj4
ss1AgsySVCtwE2BKdZcD0eKWpoKskQBlBlmNTVoLzg1kzKUuAgNqFaUydqYV
5I5yQ9CQpgZDR2V+1NoFCYjb0xOklbdI+B1azsVcXhboR+SWXcICCVWDKcmn
xxxzXg9p9+z+1I+GiOzHQhiC6kLG81g0GMSuqmu1ReoOib0ldb1X3yKNNaA9
UB4IEg8rl23DGgYVNsoUmCyAH9P4nMDBLuUG+yVrVdxqyMEQnKizLpXwQliQ
XQuJRXx8ITfEkqOVLLyQ2CPOXKTa3HEIjmLPAcBTYb0QveUKkh4vFcSIJSBf
4CQF5lGOnVNsD3sIoOlMRTr5/AIXDyT62mgyHs0DFQ9F4EWDEGLZAFeENCMH
aUQPjHvwQEY412DsoABFCTGwgiF4fS7IbaUTszIJpwd4y8kAU4vzUAKtD5Rm
uEjDubyMcaVGYEZNDsLnIdN1KA8SURZgGNE/NQD55FNIFkO2iLgmvHdJG2pr
kAp9eOBu4NIW9YNodqsL1GdZA4gYIosA5C16OTpCiV4MHg2zp/reQM6ayg8F
lFVWYhyDIIASJSpuAwl1HC2bF4V2ZRzgocBPYwJO+aBuM82yhOkaSi2da9hp
h/+dZbwO5AMd4ITKwxK2cHpQYlQApRrJe5W12iXjvLzHZrWLrCBcZBl0ElpV
hn4KUeH6G51xLPZQBrmfZcn4PemjF74pkJyyEWt1r5H5KCBMUJXmFO3EDe/B
Puhm6Jg0kpsLV1ZCfdCwtz1xaye9R27lZR5UFxziJA9kprZGSLDt0iGd0wD6
gbBI00DHY/xQRjAUG0XerAe0l+TjWWDG5VbcGlKu8mjKZBaDdMxrQzKU3et0
7LDdP7uWiFoeNLqpeeaOGHuQIBhBEWBaGLtjfBx2I+xBCHAAnUaBhI+cduNh
uQRwsiy3lB2h2i+I+CJURBw+uAw90Vic81cUOSGLctaEIiwWlwiMSxwSsCsD
CteQymOnAp/q5xzsJkI3ntktTEWikTCYIOG9K/zGkSeg0FQWRcUV1RAMk1RR
yVVd5oQ1vnKkBXEt/HnM3hlIQLSyyPl+dR05KB5DPejoK8VLiXYnb3dFRWcI
L6lalhBhG+JAS/37VLORZOyhFMhUJxVQyLvAjSORLNazJqxl1daIowJKkhq5
Qi8jQ+Rwqk6HZeaPGESQsDx60JzGCo6ABzONERcHMRu0xn3YlWot/Iyu/miL
zNzpKI35AcYeFlkI9v9uZuHWmJa4p1OCdGCaLbdlHP1Z1+W+Wwq9hnwa5A8w
KvwKiBM3D6Bnz2CVv91nCcEjVNZFcDebQMv4NXqtTuU1c7ts63DJ6ZHlGM4p
eqobTEU9d09ytmJC4j1EcNsAWPFyg8GoB6FEIMC+hIqFCV+n8lRBmx4T5P5U
liRZm7IPNhxLFWRdkKYReUnAg6CvSZpVV8n3aTRL0U/jPJ8TZog4ZvUQajzS
cHRSKgzT8YYWVJ4qBVDxe2p+fmdizwSayLp2Jx6JIR6hsiAD1gYWSh2cmnhJ
ONroaDp78adDPLw40n88fDX6LeDRjOaDYYZAxi6DW95RBsblctwfT/+E76P0
sR/KIeKsdLpQ+zRHqWtMC7DjAEGhLHcuge/79mxKoRI87ChxR5vcK6ZZpvAE
KuQ9VjZ4dNFfhejiktzfuVkfj5cwLebYR3ewpuLaIPWOGTlNy+jAY6JN2dr+
bV+fAIIcmY4lxn2dPOCmEJIweB9JyL0hCPKq2cYFigNCrrrIVYpSAEbTGREZ
hlkVc3UVgmvaL3et9JsWIe8ThfapAtgRo/C4S+Rs1LEIWhiTadnI9BIfwR64
rNxvYrmZav3R0z5H9xEFpYZEUz/kT7xVFwk07W0CeNecTWeiqoE7p2DJ29ak
inYsYbR+TuZZYEkp7u+CVqe3mEwCNTuezmZi70MBY+EeI1Uup1BaNIDkVLjx
AAGoEqiGYurraTqH1JC0D2Leld8RoQanHiQzDIY0pT2s8A5VR5CRo/+Gcipk
4ZtdwSd6wdcvADrMx6F9pgVPICzdgH+pcODRdx7Q4E+4TyO1IosNOKHDZqzt
S8cj+8gMRLLXidrjYojek+91ncLmgaUCDmxd07YQhL8BYlCFvh64e91cfsTh
elMS4gtH42DNoXdSVkYHjXF1SF2AHXQ7I0ymcMNFuHRGxmJI4l0z8l62q7Oz
T5ldjVZVmS/moaKLh4fVwkrzqgS+3/yr2+Z4bKcyKtapN+3Ng+8bkAe6g6v+
6Gs4j4hqhwW0HZQRvMPjXS2QnybOG1Hei9A+ECGuuzFBOPKBzrS7jzakMq5L
eVaUgLiHNyYCBa9NZWMRJZTOSWpdAReMS3xEOITHXWFAhySiHxi7yyG/c/V3
4ouo8DYPtc3ZaqhR19+6wmjMh2L50hTe3rjJFBThsJSYoe9B+0hDdYBWh8H/
IBs55u3tRYpAzh1hDh3vsYRj2vBKU3f65wbauag15RRmzHtQfew7pk0z8Gvc
3Bjj8CHBLLXg0XGPEof3UOMGDb5CxkN0S0O9J6PNOrcBs8NWgK4KQ6njlBS3
fgPBbVvXPvVGgUYuGWI/DkBsvtR0wsRZATNq0w3OubDpakEvSRd3VB6CXFuX
Z3Kcvyw6wVDH35gsZS9ZxoKi7gMcBmiJbEcZlXT7kfZEOIBtg6P2WJnwLdHh
OE1BYyYcLjjRi2D+grZjHkkqwtlid85+Nj2Wu3N2P0vzcd0DxHMp3e5O4rKf
xIVP4jjA8fTwldw7KYsVYG7zeGK3D7YqemQ+nLMkrqL3ORShrMv9ldpmpUpF
SPgHuPvkMA81txkyPp8duh0OEXY4fuuuwQoy1O5tg6PDUAYwKAeyhNvMLZ21
rtosgD2GCO1Q9g4o2QXCpkx8KO21QxwClWd/l0X8qpP8BdqIE/M/ZV3hrBvx
MWL3Q5v+phWP5gihO9dLH/xinsi3tbolYc/wVlk4FwD39R9M7wO5WMikqwc7
w4wnfAjrT0pzje5rbN7thuP59gGeTANK755nz9JdBA74V2JQPXpIGQGvGkkL
qSD3JuB9TkWX3tTEajz4wl3czNBpsd9mqEpr3KkWBC9G1x7UPjBNgL8v7DU+
q1PKss8DreBcPDjj4WSqHq4RnAcl/+7Z+PlIDLbUcPwPV2ceGncMGbYe6KDm
lM9SluCtzTbev8tBQjwR2aLwbYHnqHi90WdvHfeLbISKFzYU7seDfd/9bgOM
8hIOHpneG6Yt7opyUwg3WUjkD3MRZnS6CxQdDeBFALbZHbbciqiOk3uM2oFt
8OzurC0cf1DJrZgcA4zv+5sa/eMvOl2xvC2m8BYN5KbuJKHHvP3xSNg0Q8FX
LR5Y9gfFwnvrD6+Q0UfUvVcCkQuBH4IRcHo8bBk0dzunmJ1oeTbK3N5P0Qcg
TtoazXjiqhsnyKcnYEiseNxlL+vb0cw1cIxkGyoiFW5puTM7Mi+JFS517DgP
9DcdKBk+td0cwaWiE3QoSl3i7tr5pPWFsSHBFLu+d5mcODowBoRdhed/Fmdd
mqZWEADuuKYkrhU8xe3f4fwQK6ZqMz6Q9ZdL+LPx7ErjjSDAkEbdaQhaviLB
noNe5C4X4cvudIiP8JIGSg1oV9ElrZXcK2vhriKhjzTrumxv1/tyh3S0NRWd
ZnIqTTRkFKBQWoMX0UkpXpdxMwK5N0XVNl2gQvGRMggkfD8Uj2HJZ1Umwg0P
jogl7w/brW10Pg2Z3enWETvlgBbGTPH44i+nNwRRH27wuJXSIV754rWIoMo9
2n9YtzZUEu6Q6oEugPwDxvN74YR2J6xkA+TISIQIJYj4KTp0i0uZivn+E3m2
uFg8jAyjCvV5eH2r1reQJujQ/eEFLvI9onwnXA1O3tIdX3n2xopwrSnqALNf
QPGNagL8lKepATiey/dYDGpfZDIfTiAY3DYlOMgImk8W8N+IqTlV/DBC0eZL
sDulhkhs3kfaJdkVrad2OZ0UQSyewoYNCJFibovH1tXfo2cuTbjlz2c77Ti1
j3aMZEeIqhPWbr3lcpJu01D7q1PANH89ZSR9M047fN+Pg5JlBblRMjqjpctC
RHObZTZJSlVNXKk+4QvYlo4q/yHPu2P1h//9Q55CaOAePfx59sa9hF6q2105
6C74//GjBTeHppNugJvXbybPZodf6pUsQZe7es2g16e5fPLYEvBiq/1ulMls
xJe+v9ulZFQK8FTyhaGsvPobWD14POqAb7lHggpx3S6b7tNgBLyKBUVpDbrv
bhLN5cXBQojLyl2XevAlaLWfY+ZyyVcWRUhcwwbXGq8b++z1mYiZiwnKBjAJ
3aBx9GXYnWZ/3y6B9K091vn8PA8jAZvvFOAAG08IKLg6157Lx5rtuLcS34wc
lDrTHaxa1w9k/wLzFl/yRyq6qqqs+c6CK2t3cE+8lSKcSrgpYotT7aK7/RZ+
wwA6E+INriUhwFWZASbf3VsgfbGmSPHn6tYkDqyAVbu3b02mu5s/9L5bwkch
fjRFimTsJDPVslQA5BfkiaPobsgB532Wa4QzJZC/SovsEbMHWgAL8G7WrsWH
ApOmhYVRBJzFFkhhnrK+neLPeabRL3nI9fEeeokXAQEtK/SpZNrAOsDBYDhQ
/B/41yHISGvHAGhfLOGrX+5EvK/O6Hcrj/88hfy8SOnmtroFEfEq5+UFxiL/
YMffynOfacEL/qGH/LYZTvgkIfAC6Hh2ev2XIYgQdP1TIIIj/D+I/E8GEbLx
/2oQSX5/QCA33gEI9FOY/9uAIBcJ1vRQO9zyUTGQaCz5XW3pjtYfr+LiKzcb
3NIzNR1H8E+T+J4dEsLL84W8Bsf6sazvrHy3OZ+dy/uj6VE/AIe/tuKNhcz8
7HaeKLZKqoZ4ykEYMZ8k1Vi300i7DXR8oYo7eaJAPF2I12ijohjLk3WNRyZQ
XS5yC/wZqs4fFB6+/AD/K/TPY/nXTEFt8z1Ua3d6LM8N1L86E1f4L1Tqpb8L
T8bnms5UChUZjirOTm/eSiLE2LKnCfHm/PoUfzZwhxF5C2VShdscJV85IXuZ
ZYuRBUGqrLsdeW/0BusQ+kXYEswl/htdm7HZ6DoAAA==
</rfc> </rfc>
 End of changes. 64 change blocks. 
656 lines changed or deleted 375 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/