idnits 2.17.1 draft-ietf-core-senml-etch-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 27, 2019) is 1583 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Keranen 3 Internet-Draft Ericsson 4 Intended status: Standards Track M. Mohajer 5 Expires: June 29, 2020 u-blox UK 6 December 27, 2019 8 FETCH & PATCH with Sensor Measurement Lists (SenML) 9 draft-ietf-core-senml-etch-06 11 Abstract 13 The Sensor Measurement Lists (SenML) media type and data model can be 14 used to send collections of resources, such as batches of sensor data 15 or configuration parameters. The CoAP FETCH, PATCH, and iPATCH 16 methods enable accessing and updating parts of a resource or multiple 17 resources with one request. This document defines new media types 18 for the CoAP FETCH, PATCH, and iPATCH methods for resources 19 represented with the SenML data model. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 29, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Using FETCH and (i)PATCH with SenML . . . . . . . . . . . . . 3 58 3.1. SenML FETCH . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. SenML (i)PATCH . . . . . . . . . . . . . . . . . . . . . 5 60 4. Fragment Identification . . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. CoAP Content-Format Registration . . . . . . . . . . . . 7 64 6.2. senml-etch+json Media Type . . . . . . . . . . . . . . . 7 65 6.3. senml-etch+cbor Media Type . . . . . . . . . . . . . . . 8 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 8.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 The Sensor Measurement Lists (SenML) media type [RFC8428] and data 75 model can be used to transmit collections of resources, such as 76 batches of sensor data or configuration parameters. 78 An example of a SenML collection is shown below: 80 [ 81 {"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":true}, 82 {"n":"5851", "v":42}, 83 {"n":"5750", "vs":"Ceiling light"} 84 ] 86 Here three resources "3311/0/5850", "3311/0/5851", and "3311/0/5750", 87 of an IPSO dimmable light smart object [IPSO] are represented using a 88 single SenML Pack with three SenML Records. All resources share the 89 same base name "2001:db8::2/3311/0/", hence full names for resources 90 are "2001:db8::2/3311/0/5850", etc. 92 The CoAP [RFC7252] FETCH, PATCH, and iPATCH methods [RFC8132] enable 93 accessing and updating parts of a resource or multiple resources with 94 one request. 96 This document defines two new media types, one using the JavaScript 97 Object Notation (JSON) [RFC8259] and one using the Concise Binary 98 Object Representation (CBOR) [RFC7049], which can be used with the 99 CoAP FETCH, PATCH, and iPATCH methods for resources represented with 100 the SenML data model. The rest of the document uses term "(i)PATCH" 101 when referring to both methods as the semantics of the new media 102 types are the same for the CoAP PATCH and iPATCH methods. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 Readers should also be familiar with the terms and concepts discussed 113 in [RFC8132] and [RFC8428]. The following additional terms are used 114 in this document: 116 Fetch Record: One set of parameters that is used to match SenML 117 Record(s). 119 Fetch Pack: One or more Fetch Records in an array structure. 121 Patch Record: One set of parameters similar to Fetch Record but also 122 containing instructions on how to change existing SenML Pack(s). 124 Patch Pack: One or more Patch Records in an array structure. 126 Target Record: A Record in a SenML Pack that matches the selection 127 criteria of a Fetch or Patch Record and hence is a target for a 128 Fetch or Patch operation. 130 Target Pack: A SenML Pack that is a target for a Fetch or Patch 131 operation. 133 (i)PATCH: A term that refers to both CoAP "PATCH" and "iPATCH" 134 methods when there is no difference in this specification in which 135 one is used. 137 3. Using FETCH and (i)PATCH with SenML 139 The FETCH/(i)PATCH media types for SenML are modeled as extensions to 140 the SenML media type to enable re-use of existing SenML parsers and 141 generators, in particular on constrained devices. Unless mentioned 142 otherwise, FETCH and PATCH Packs are constructed with the same rules 143 and constraints as SenML Packs. 145 The key differences to the SenML media type are allowing the use of a 146 "null" value for removing records with the (i)PATCH method and lack 147 of value fields in Fetch Records. Also the Fetch and Patch Records 148 do not have default time or base version when the fields are omitted. 150 3.1. SenML FETCH 152 The FETCH method can be used to select and return a subset of 153 records, in sequence, of one or more SenML Packs. The SenML Records 154 are selected by giving a set of names that, when resolved, match 155 resolved names in a Target SenML Pack. The names for a Fetch Pack 156 are given using the SenML "name" and/or "base name" fields. The 157 names are resolved by concatenating the base name with the name field 158 as defined in [RFC8428]. 160 A Fetch Pack MUST contain at least one Fetch Record. A Fetch Record 161 MUST contain a name and/or a base name field. 163 For example, to select the IPSO resources "5850" and "5851" from the 164 example in Section 1, the following Fetch Pack can be used: 166 [ 167 {"bn":"2001:db8::2/3311/0/", "n":"5850"}, 168 {"n":"5851"} 169 ] 171 The result to a FETCH request with the example above would be: 173 [ 174 {"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":true}, 175 {"n":"5851", "v":42}, 176 ] 178 The SenML time and unit fields can be used in a Fetch Record to 179 further narrow the selection of matched SenML Records. When no time 180 or unit is given in a Fetch Record, all SenML Records with the given 181 name are matched (i.e., unlike with SenML Records, lack of time field 182 in a Fetch Record does not imply time value zero). When time is 183 given in the Fetch Record, only the SenML Records (if any) with equal 184 resolved time value and name are matched. Similarly, when unit is 185 given, only the SenML Records with equal resolved unit and name are 186 matched. If both time and unit are given in the Fetch Record, both 187 MUST to match for the SenML Record to match. 189 For example, if the IPSO resource "5850" would have multiple sensor 190 readings (SenML Records) with different time values, the following 191 Fetch Pack can be used to retrieve the Record with time 192 "1.276020091e+09": 194 [ 195 {"bn":"2001:db8::2/3311/0/", "n":"5850", "t":1.276020091e+09} 196 ] 198 The resolved form of records (Section 4.6 of [RFC8428]) is used when 199 comparing the names, times, and units of the Target and Fetch Records 200 to accommodate for differences in use of the base values. In 201 resolved form the SenML name in the example above becomes 202 "2001:db8::2/3311/0/5850". Since there is no base time in the Pack, 203 the time in resolved form is equal to the time in the example. 205 If no SenML Records match, empty SenML Pack (i.e., array with no 206 elements) is returned as a response. 208 All other Fetch Record fields than name, base name, time, base time, 209 unit, and base unit MUST be ignored. 211 3.2. SenML (i)PATCH 213 The (i)PATCH method can be used to change the fields of SenML 214 Records, to add new Records, and to remove existing Records. The 215 names, times, and units of the Patch Records are given and matched in 216 same way as for the Fetch Records, except each Patch Record MUST 217 match at most one Target Record. Patch Packs can also include new 218 values and other SenML fields for the Records. Application of Patch 219 Packs is idempotent; hence PATCH and iPATCH methods for SenML Packs 220 are equivalent. 222 When the name in a Patch Record matches with the name in an existing 223 Record, the resolved time values and units (if any) are compared. If 224 the time values and units either do not exist in both Records or are 225 equal, the Target Record is replaced with the contents of the Patch 226 Record. All Patch Records MUST contain at least a SenML Value or Sum 227 field. A Patch Pack with invalid Records MUST be rejected. 229 If a Patch Record contains a name, or combination of a time value, 230 unit, and a name, that do not exist in any existing Record in the 231 Pack, the given Record, with all the fields it contains, is added to 232 the Pack. 234 If a Patch Record has a value ("v") field with value null, it MUST 235 NOT be added but the matched Record (if any) is removed from the 236 Target Pack. 238 For example, the following document could be given as an (i)PATCH 239 payload to change/set values of two SenML Records for the example in 240 Section 1: 242 [ 243 {"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":false}, 244 {"n":"5851", "v":10} 245 ] 247 If the request is successful, the resulting representation of the 248 example SenML Pack would be as follows: 250 [ 251 {"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":false}, 252 {"n":"5851", "v":10}, 253 {"n":"5750", "vs":"Ceiling light"} 254 ] 256 As another example, the following document could be given as an 257 (i)PATCH payload to remove the two SenML Records: 259 [ 260 {"bn":"2001:db8::2/3311/0/", "n":"5850", "v":null}, 261 {"n":"5851", "v":null} 262 ] 264 4. Fragment Identification 266 Fragment identification for Records of Fetch and Patch Packs uses the 267 same mechanism as SenML JSON/CBOR fragment identification (see 268 Section 9 of [RFC8428]), i.e., "rec" scheme followed by a comma- 269 separated list of Record positions or range(s) of Records. For 270 example, to select the 3rd and 5th Record of a Fetch or Patch Pack, a 271 fragment identifier "rec=3,5" can be used in the URI of the Fetch or 272 Patch Pack resource. 274 5. Security Considerations 276 The security and privacy considerations of SenML apply also with the 277 FETCH and (i)PATCH methods. CoAP's security mechanisms are used to 278 provide security for the FETCH and (i)PATCH methods. 280 In FETCH and (i)PATCH requests, the client can pass arbitrary names 281 to the target resource for manipulation. The resource implementer 282 must take care to only allow access to names that are actually part 283 of (or accessible through) the target resource. 285 If the client is not allowed to do a GET or PUT on the full target 286 resource (and thus all the names accessible through it), access 287 control rules must be evaluated for each record in the pack. 289 6. IANA Considerations 291 This document registers two new media types and CoAP Content-Format 292 IDs for both media types. 294 Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with 295 the RFC number of this document. 297 6.1. CoAP Content-Format Registration 299 IANA is requested to assign CoAP Content-Format IDs for the SenML 300 PATCH and FETCH media types in the "CoAP Content-Formats" sub- 301 registry, within the "CoRE Parameters" registry [RFC7252]. The 302 assigned IDs are shown in Table 1. 304 +-----------------------------+----------+---------+ 305 | Media type | Encoding | ID | 306 +-----------------------------+----------+---------+ 307 | application/senml-etch+json | - | TBD-320 | 308 | | | | 309 | application/senml-etch+cbor | - | TBD-322 | 310 +-----------------------------+----------+---------+ 312 Table 1: CoAP Content-Format IDs 314 6.2. senml-etch+json Media Type 316 Type name: application 318 Subtype name: senml-etch+json 320 Required parameters: N/A 322 Optional parameters: N/A 324 Encoding considerations: binary 326 Security considerations: See Section 5 of RFC-AAAA. 328 Interoperability considerations: Applications MUST ignore any key 329 value pairs that they do not understand unless the key ends with the 330 '_' character in which case an error MUST be generated. This allows 331 backwards compatible extensions to this specification. 333 Published specification: RFC-AAAA 335 Applications that use this media type: Applications that use the 336 SenML media type for resource representation. 338 Fragment identifier considerations: Fragment identification for 339 application/senml-etch+json is supported by using fragment 340 identifiers as specified by RFC AAAA. 342 Additional information: 344 Deprecated alias names for this type: N/A 346 Magic number(s): N/A 348 File extension(s): senml-etchj 350 Windows Clipboard Name: "SenML FETCH/PATCH format" 352 Macintosh file type code(s): N/A 354 Macintosh Universal Type Identifier code: org.ietf.senml-etch-json 355 conforms to public.text 357 Person & email address to contact for further information: Ari 358 Keranen ari.keranen@ericsson.com 360 Intended usage: COMMON 362 Restrictions on usage: N/A 364 Author: Ari Keranen ari.keranen@ericsson.com 366 Change controller: IESG 368 6.3. senml-etch+cbor Media Type 370 Type name: application 372 Subtype name: senml-etch+cbor 374 Required parameters: N/A 376 Optional parameters: N/A 378 Encoding considerations: binary 380 Security considerations: See Section 5 of RFC-AAAA. 382 Interoperability considerations: Applications MUST ignore any key 383 value pairs that they do not understand unless the key ends with the 384 '_' character in which case an error MUST be generated. This allows 385 backwards compatible extensions to this specification. 387 Published specification: RFC-AAAA 389 Applications that use this media type: Applications that use the 390 SenML media type for resource representation. 392 Fragment identifier considerations: Fragment identification for 393 application/senml-etch+cbor is supported by using fragment 394 identifiers as specified by RFC AAAA. 396 Additional information: 398 Deprecated alias names for this type: N/A 400 Magic number(s): N/A 402 File extension(s): senml-etchc 404 Macintosh file type code(s): N/A 406 Macintosh Universal Type Identifier code: org.ietf.senml-etch-cbor 407 conforms to public.data 409 Person & email address to contact for further information: Ari 410 Keranen ari.keranen@ericsson.com 412 Intended usage: COMMON 414 Restrictions on usage: N/A 416 Author: Ari Keranen ari.keranen@ericsson.com 418 Change controller: IESG 420 7. Acknowledgements 422 The use of FETCH and (i)PATCH methods with SenML was first introduced 423 by the OMA SpecWorks LwM2M v1.1 specification. This document 424 generalizes the use to any SenML representation. The authors would 425 like to thank Carsten Bormann, Christian Amsuess, Jaime Jimenez, 426 Klaus Hartke, Michael Richardson, and other participants from the 427 IETF CoRE and OMA SpecWorks DMSE working groups who have contributed 428 ideas and reviews. 430 8. References 431 8.1. Normative References 433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 434 Requirement Levels", BCP 14, RFC 2119, 435 DOI 10.17487/RFC2119, March 1997, 436 . 438 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 439 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 440 October 2013, . 442 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 443 Application Protocol (CoAP)", RFC 7252, 444 DOI 10.17487/RFC7252, June 2014, 445 . 447 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 448 FETCH Methods for the Constrained Application Protocol 449 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 450 . 452 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 453 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 454 May 2017, . 456 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 457 Interchange Format", STD 90, RFC 8259, 458 DOI 10.17487/RFC8259, December 2017, 459 . 461 [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 462 Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, 463 DOI 10.17487/RFC8428, August 2018, 464 . 466 8.2. Informative References 468 [IPSO] IPSO, "IPSO Light Control Smart Object", 2018, 469 . 472 Authors' Addresses 474 Ari Keranen 475 Ericsson 477 Email: ari.keranen@ericsson.com 478 Mojan Mohajer 479 u-blox UK 481 Email: Mojan.Mohajer@u-blox.com