idnits 2.17.1 draft-ietf-core-senml-etch-05.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 (August 17, 2019) is 1708 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: February 18, 2020 u-blox UK 6 August 17, 2019 8 FETCH & PATCH with Sensor Measurement Lists (SenML) 9 draft-ietf-core-senml-etch-05 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 iPATCH, PATCH, and FETCH 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 iPATCH, PATCH, and FETCH 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 February 18, 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 . . . . . . . . . . . . . . . . . . . . . 4 60 4. Fragment Identification . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 6.1. CoAP Content-Format Registration . . . . . . . . . . . . 6 64 6.2. senml-etch+json Media Type . . . . . . . . . . . . . . . 6 65 6.3. senml-etch+cbor Media Type . . . . . . . . . . . . . . . 7 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 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] iPATCH, PATCH, and FETCH 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], that can be used with the 99 CoAP iPATCH, PATCH, and FETCH methods for resources represented with 100 the SenML data model. The semantics of the new media types are the 101 same for the CoAP PATCH and iPATCH methods. The rest of the document 102 uses term "(i)PATCH" when referring to both 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]. Also the following terms are used in 114 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 is matching the 127 selection criteria of a Fetch or Patch Record and hence is a 128 target for a Fetch or Patch operation. 130 (i)PATCH: A term that refers to both CoAP "PATCH" and "iPATCH" 131 methods when there is no difference in this specification in which 132 one is used. 134 3. Using FETCH and (i)PATCH with SenML 136 The FETCH/(i)PATCH media types for SenML are modeled as extensions to 137 the SenML media type to enable re-use of existing SenML parsers and 138 generators, in particular on constrained devices. Unless mentioned 139 otherwise, FETCH and PATCH Packs are constructed with the same rules 140 and constraints as SenML Packs. 142 The key difference to the SenML media type is allowing the use of a 143 "null" value for removing records with the (i)PATCH method. Also the 144 Fetch and Patch Records do not have default time or base version when 145 the fields are omitted. 147 3.1. SenML FETCH 149 The FETCH method can be used to select and return a subset of 150 records, in sequence, of one or more SenML Packs. The SenML Records 151 are selected by giving a set of names that, when resolved, match 152 resolved names in a SenML Pack. The names for a Fetch Pack are given 153 using the SenML "name" and/or "base name" Fields. The names are 154 resolved by concatenating the base name with the name field as 155 defined in [RFC8428]. 157 For example, to select the IPSO resources "5850" and "5851" from the 158 example in Section 1, the following Fetch Pack can be used: 160 [ 161 {"bn":"2001:db8::2/3311/0/", "n":"5850"}, 162 {"n":"5851"} 163 ] 165 The result to a FETCH request with the example above would be: 167 [ 168 {"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":true}, 169 {"n":"5851", "v":42}, 170 ] 172 When SenML Records contain also time values, a name may no longer 173 uniquely identify a single Record. When no time is given in a Fetch 174 Record, all SenML Records with the given name are matched (i.e., 175 unlike with SenML Records, lack of time field in a Fetch Record does 176 not imply time value zero). When time is given in the Fetch Record, 177 only a SenML Record (if any) with equal resolved time value and name 178 is matched. 180 The resolved form of records (Section 4.6 of [RFC8428]) is used when 181 comparing the names and times of the Target and Fetch Records to 182 accommodate for differences in use of the base values. 184 3.2. SenML (i)PATCH 186 The (i)PATCH method can be used to change the values of SenML 187 Records, to add new Records, and to remove existing Records. The 188 names and times of the Patch Records are given and matched in same 189 way as for the Fetch Records, except each Patch Record can match at 190 most one Target Record. Patch Packs can also include new values and 191 other SenML Fields for the Records. Application of Patch Packs is 192 idempotent. 194 When the name in a Patch Record matches with the name in an existing 195 Record, the resolved time values are compared. If the time values 196 either do not exist in both Records or are equal, the Target Record 197 is replaced with the contents of the Patch Record. 199 If a Patch Record contains a name, or combination of a time value and 200 a name, that do not exist in any existing Record in the Pack, the 201 given Record, with all the fields it contains, is added to the Pack. 203 If a Patch Record has a value ("v") field with value null, the 204 matched Record (if any) is removed from the Pack. 206 For example, the following document could be given as an (i)PATCH 207 payload to change/set values of two SenML Records for the example in 208 Section 1: 210 [ 211 {"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":false}, 212 {"n":"5851", "v":10} 213 ] 215 If the request is successful, the resulting representation of the 216 example SenML Pack would be as follows: 218 [ 219 {"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":false}, 220 {"n":"5851", "v":10}, 221 {"n":"5750", "vs":"Ceiling light"} 222 ] 224 As another example, the following document could be given as an 225 (i)PATCH payload to remove the two SenML Records: 227 [ 228 {"bn":"2001:db8::2/3311/0/", "n":"5850", "v":null}, 229 {"n":"5851", "v":null} 230 ] 232 4. Fragment Identification 234 Fragment identification is supported by analogously applying fragment 235 identifiers as specified in Section 9 of [RFC8428] to the Fetch/Patch 236 Records. 238 5. Security Considerations 240 The security and privacy considerations of SenML apply also with the 241 FETCH and (i)PATCH methods. 243 In FETCH and (i)PATCH requests, the client can pass arbitrary names 244 to the target resource for manipulation. The resource implementer 245 must take care to only allow access to names that are actually part 246 of (or accessible through) the target resource. 248 If the client is not allowed to do a GET or PUT on the full target 249 resource (and thus all the names accessible through it), access 250 control rules must be evaluated for each record in the pack. 252 6. IANA Considerations 254 This document registers two new media types and CoAP Content-Format 255 IDs for both media types. 257 Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with 258 the RFC number of this document. 260 6.1. CoAP Content-Format Registration 262 IANA is requested to assign CoAP Content-Format IDs for the SenML 263 PATCH and FETCH media types in the "CoAP Content-Formats" sub- 264 registry, within the "CoRE Parameters" registry [RFC7252]. The 265 assigned IDs are shown in Table 1. 267 +-----------------------------+----------+---------+ 268 | Media type | Encoding | ID | 269 +-----------------------------+----------+---------+ 270 | application/senml-etch+json | - | TBD-320 | 271 | | | | 272 | application/senml-etch+cbor | - | TBD-322 | 273 +-----------------------------+----------+---------+ 275 Table 1: CoAP Content-Format IDs 277 6.2. senml-etch+json Media Type 279 Type name: application 281 Subtype name: senml-etch+json 283 Required parameters: none 285 Optional parameters: none 286 Encoding considerations: binary 288 Security considerations: See Section 5 of RFC-AAAA. 290 Interoperability considerations: Applications MUST ignore any key 291 value pairs that they do not understand unless the key ends with the 292 '_' character in which case an error MUST be generated. This allows 293 backwards compatible extensions to this specification. 295 Published specification: RFC-AAAA 297 Applications that use this media type: Applications that use the 298 SenML media type for resource representation. 300 Fragment identifier considerations: Fragment identification for 301 application/senml-etch+json is supported by using fragment 302 identifiers as specified by RFC AAAA. 304 Additional information: 306 Magic number(s): none 308 File extension(s): senml-etchj 310 Windows Clipboard Name: "SenML FETCH/PATCH format" 312 Macintosh file type code(s): none 314 Macintosh Universal Type Identifier code: org.ietf.senml-etch-json 315 conforms to public.text 317 Person & email address to contact for further information: Ari 318 Keranen ari.keranen@ericsson.com 320 Intended usage: COMMON 322 Restrictions on usage: None 324 Author: Ari Keranen ari.keranen@ericsson.com 326 Change controller: IESG 328 6.3. senml-etch+cbor Media Type 330 Type name: application 332 Subtype name: senml-etch+cbor 333 Required parameters: none 335 Optional parameters: none 337 Encoding considerations: binary 339 Security considerations: See Section 5 of RFC-AAAA. 341 Interoperability considerations: Applications MUST ignore any key 342 value pairs that they do not understand unless the key ends with the 343 '_' character in which case an error MUST be generated. This allows 344 backwards compatible extensions to this specification. 346 Published specification: RFC-AAAA 348 Applications that use this media type: Applications that use the 349 SenML media type for resource representation. 351 Fragment identifier considerations: Fragment identification for 352 application/senml-etch+cbor is supported by using fragment 353 identifiers as specified by RFC AAAA. 355 Additional information: 357 Magic number(s): none 359 File extension(s): senml-etchc 361 Macintosh file type code(s): none 363 Macintosh Universal Type Identifier code: org.ietf.senml-etch-cbor 364 conforms to public.data 366 Person & email address to contact for further information: Ari 367 Keranen ari.keranen@ericsson.com 369 Intended usage: COMMON 371 Restrictions on usage: None 373 Author: Ari Keranen ari.keranen@ericsson.com 375 Change controller: IESG 377 7. Acknowledgements 379 The use of FETCH and (i)PATCH methods with SenML was first introduced 380 by the OMA SpecWorks LwM2M v1.1 specification. This document 381 generalizes the use to any SenML representation. The authors would 382 like to thank Carsten Bormann, Christian Amsuess, Jaime Jimenez, 383 Klaus Hartke, Michael Richardson, and other participants from the 384 IETF CoRE and OMA SpecWorks DMSE working groups who have contributed 385 ideas and reviews. 387 8. References 389 8.1. Normative References 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, 393 DOI 10.17487/RFC2119, March 1997, 394 . 396 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 397 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 398 October 2013, . 400 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 401 Application Protocol (CoAP)", RFC 7252, 402 DOI 10.17487/RFC7252, June 2014, 403 . 405 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 406 FETCH Methods for the Constrained Application Protocol 407 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 408 . 410 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 411 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 412 May 2017, . 414 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 415 Interchange Format", STD 90, RFC 8259, 416 DOI 10.17487/RFC8259, December 2017, 417 . 419 [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 420 Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, 421 DOI 10.17487/RFC8428, August 2018, 422 . 424 8.2. Informative References 426 [IPSO] IPSO, "IPSO Light Control Smart Object", 2018, 427 . 430 Authors' Addresses 432 Ari Keranen 433 Ericsson 435 Email: ari.keranen@ericsson.com 437 Mojan Mohajer 438 u-blox UK 440 Email: Mojan.Mohajer@u-blox.com