Change:
using "(i)PATCH" to refer to both PATCH methods Clarified defaulting rules Clarified name resolving rules Clarified use of "resource" Added note that application of Patch Packs is idempotent Removed "more details in RFC-AAA" from media type encoding considerations (there are no more details actually)

Discussion:
or configuration parameters.  The CoAP iPATCH, PATCH, and FETCH methods enable accessing and updating parts of a resource or multiple resources with one request.  This document defines new media types <del> for the CoAP iPATCH, and FETCH methods for resources represented with the SenML data model. </del> <ins> for the CoAP iPATCH, PATCH, and FETCH methods for resources represented with the SenML data model. </ins> 1.

model can be used to transmit collections of resources, such as batches of sensor data or configuration parameters. <del> Example of a SenML collection is shown below: </del> <ins> An example of a SenML collection is shown below: </ins> Here three resources "3306/0/5850", "3306/0/5851", and "3306/0/5750", of an IPSO dimmable light smart object IPSO are represented using a

same base name "2001:db8::2/3306/0/", hence full names for resources are "2001:db8::2/3306/0/5850", etc. <del> The CoAP RFC7252 iPATCH and FETCH methods RFC8132 enable accessing and updating parts of a resource or multiple resources with one request. </del> <ins> The CoAP RFC7252 iPATCH, PATCH, and FETCH methods RFC8132 enable accessing and updating parts of a resource or multiple resources with one request. </ins> This document defines two new media types, one using the JavaScript Object Notation (JSON) RFC8259 and one using the Concise Binary Object Representation (CBOR) RFC7049, that can be used with the CoAP iPATCH, PATCH, and FETCH methods for resources represented with the SenML data model.  The semantics of the new media types are the same <del> for the CoAP PATCH and iPATCH methods. </del> <ins> for the CoAP PATCH and iPATCH methods.  The rest of the document uses term "(i)PATCH" when referring to both methods. </ins> 2.

of a Fetch or Patch Record and hence is a target for a Fetch or Patch operation. <ins> A term that refers to both CoAP "PATCH" and "iPATCH" methods when there is no difference in this specification in which one is used. </ins> 3. <del> The FETCH/iPATCH media types for SenML are modeled as extensions to </del> <ins> The FETCH/(i)PATCH media types for SenML are modeled as extensions to </ins> the SenML media type to enable re-use of existing SenML parsers and generators, in particular on constrained devices.  Unless mentioned otherwise, FETCH and PATCH Packs are constructed with the same rules <del> and constraints as SenML Packs.  The only difference to SenML media type is allowing the use of "null" value for removing records with the iPATCH method. </del> <ins> and constraints as SenML Packs. The key difference to the SenML media type is allowing the use of a "null" value for removing records with the (i)PATCH method.  Also the Fetch and Patch Records do not have default time or base version when the fields are omitted. </ins> 3.1. <del> The FETCH method can be used to select and return parts of one or more SenML Packs.  The SenML Records are selected by giving the name(s) of the resources using the SenML "name" and/or "base name" Fields. </del> <ins> 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 giving a set of names that, when resolved, match resolved names in a 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 the base name with the name field as defined in RFC8428. </ins> <del> For example, to select resources "5850" and "5851" from the example in intro, the following Fetch Pack can be used: </del> <ins> For example, to select the IPSO resources "5850" and "5851" from the example in intro, the following Fetch Pack can be used: </ins> The result to a FETCH request with the example above would be: When SenML Records contain also time values, a name may no longer uniquely identify a single Record.  When no time is given in a Fetch <del> Record, all SenML Records with the given name are matched.  When time is given in the Fetch Record, only a SenML Record (if any) with equal time value and name is matched. </del> <ins> Record, all SenML Records with the given name are matched (i.e., unlike with SenML Records, lack of time field in a Fetch Record does not imply time value zero).  When time is given in the Fetch Record, only a SenML Record (if any) with equal resolved time value and name is matched. </ins> The resolved form of records (Section 4.6 of RFC8428) is used when comparing the names and times of the Target and Fetch Records to

3.2. <del> The iPATCH method can be used to change the values of SenML Records, to add new Records, and to remove existing Records.  The names and times of the Patch Records are given and matched in same way as for the Fetch Records, except each Patch Record can match at most one Target Record.  Patch Packs can also include new values and other SenML Fields for the Records. </del> <ins> The (i)PATCH method can be used to change the values of SenML Records, to add new Records, and to remove existing Records.  The names and times of the Patch Records are given and matched in same way as for the Fetch Records, except each Patch Record can match at most one Target Record.  Patch Packs can also include new values and other SenML Fields for the Records.  Application of Patch Packs is idempotent. </ins> When the name in a Patch Record matches with the name in an existing <del> Record, the time values are compared.  If the time values do not exist or are equal in both Records, the Target Record is replaced with the contents of the Patch Record. </del> <ins> Record, the resolved time values are compared.  If the time values either do not exist in both Records or are equal, the Target Record is replaced with the contents of the Patch Record. </ins> If a Patch Record contains a name, or combination of a time value and a name, that do not exist in any existing Record in the Pack, the

If a Patch Record has a value field with value null, the matched Record (if any) is removed from the Pack. <del> For example, the following document could be given as iPATCH payload to change/set values of two SenML Records for the example in intro: </del> <ins> For example, the following document could be given as (i)PATCH payload to change/set values of two SenML Records for the example in intro: </ins> If the request is successful, the resulting representation of the example SenML Pack would be as follows:

4. The security and privacy considerations of SenML apply also with the <del> FETCH and iPATCH methods. </del> <ins> FETCH and (i)PATCH methods. </ins> <del> In FETCH and iPATCH requests, the client can pass arbitrary names to the target resource for manipulation.  The resource implementer must take care to only allow access to names that are actually part of (or accessible through) the target resource. </del> <ins> In FETCH and (i)PATCH requests, the client can pass arbitrary names to the target resource for manipulation.  The resource implementer must take care to only allow access to names that are actually part of (or accessible through) the target resource. </ins> 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

Optional parameters: none Encoding considerations: Must be encoded as using a subset of the <del> encoding allowed in RFC8259.  See RFC-AAAA for details.  This simplifies implementation of very simple system and does not impose any significant limitations as all this data is meant for machine to machine communications and is not meant to be human readable. </del> <ins> encoding allowed in RFC8259.  This simplifies implementation of a very simple system and does not impose any significant limitations as all this data is meant for machine to machine communications and is not meant to be human readable. </ins> Security considerations: See seccons of RFC-AAAA.

Optional parameters: none <del> Encoding considerations: Must be encoded as using RFC7049.  See RFC- AAAA for details. </del> <ins> Encoding considerations: Must be encoded as using RFC7049. </ins> Security considerations: See seccons of RFC-AAAA.