Change:
more details for security consideration on record names noted this applies to SenSML too updated extensibility mechanism
The CI checks fail because this PR has still year 2019 in the draft. The PR fixes that too.

Discussion:
Object Notation (JSON) RFC8259 and one using the Concise Binary Object Representation (CBOR) RFC7049, which can be used with the CoAP FETCH, PATCH, and iPATCH methods for resources represented with the <del> SenML data model.  The rest of the document uses term "(i)PATCH" when referring to both methods as the semantics of the new media types are the same for the CoAP PATCH and iPATCH methods. </del> <ins> 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 referring to both methods as the semantics of the new media types are the same for the CoAP PATCH and iPATCH methods. </ins> 2.

If no SenML Records match, empty SenML Pack (i.e., array with no elements) is returned as a response. <del> All other Fetch Record fields than name, base name, time, base time, unit, and base unit MUST be ignored. </del> <ins> Fetch Records MUST NOT contain other fields than name, base name, time, base time, unit, and base unit.  Implementations MUST reject and generate an error for a Fetch Pack with other fields. </ins> 3.2.

5. <ins> The SenML mandatory to understand fields extensibility mechanism (see section 4.4 in RFC8428) does not apply to Patch Packs, i.e., unknown fields MUST NOT generate an error but such fields are treated like any other field (e.g., added to Patch target records where applicable). This specification allows only a small subset of SenML fields in Fetch Records but future specifications may enable new fields for Fetch Records and possibly also new fields for selecting targets for Patch Records. 6. </ins> The security and privacy considerations of SenML apply also with the FETCH and (i)PATCH methods.  CoAP's security mechanisms are used to provide security for the FETCH and (i)PATCH methods.

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 <del> of (or accessible through) the target resource. </del> <ins> of (or accessible through) the target resource.  In particular the receiver needs to ensure that any input does not lead to uncontrolled special interpretation by the system. </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 control rules must be evaluated for each record in the pack. <del> 6. </del> <ins> 7. </ins> This document registers two new media types and CoAP Content-Format IDs for both media types.

Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with the RFC number of this document. <del> 6.1. </del> <ins> 7.1. </ins> IANA is requested to assign CoAP Content-Format IDs for the SenML PATCH and FETCH media types in the "CoAP Content-Formats" sub- registry, within the "CoRE Parameters" registry RFC7252.  The assigned IDs are shown in tbl-coap-content-formats. <del> 6.2. </del> <ins> 7.2. </ins> Type name: application

Change controller: IESG <del> 6.3. </del> <ins> 7.3. </ins> Type name: application

Security considerations: See seccons of RFC-AAAA. <del> Interoperability considerations: Applications MUST ignore any key value pairs that they do not understand unless the key ends with the '_' character in which case an error MUST be generated.  This allows backwards compatible extensions to this specification. </del> <ins> Interoperability considerations: N/A </ins> Published specification: RFC-AAAA