idnits 2.17.1 draft-ietf-core-senml-etch-01.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 (February 12, 2019) is 1897 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: August 16, 2019 u-blox UK 6 February 12, 2019 8 FETCH & PATCH with Sensor Measurement Lists (SenML) 9 draft-ietf-core-senml-etch-01 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, and FETCH methods for resources represented with 19 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 August 16, 2019. 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 iPATCH with SenML . . . . . . . . . . . . . . 3 58 3.1. SenML FETCH . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. SenML iPATCH . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 5.1. CoAP Content-Format Registration . . . . . . . . . . . . 5 63 5.2. senml-etch+json Media Type . . . . . . . . . . . . . . . 6 64 5.3. senml-etch+cbor Media Type . . . . . . . . . . . . . . . 7 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 7.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 The Sensor Measurement Lists (SenML) media type {{RFC8428} and data 74 model can be used to transmit collections of resources, such as 75 batches of sensor data or configuration parameters. 77 Example of a SenML collection is shown below: 79 [ 80 {"bn":"2001:db8::2/3306/0/", "n":"5850", "vb":true}, 81 {"n":"5851", "v":42}, 82 {"n":"5750", "vs":"Ceiling light"} 83 ] 85 Here three resources "3306/0/5850", "3306/0/5851", and "3306/0/5750", 86 of an IPSO dimmable light smart object [IPSO] are represented using a 87 single SenML Pack with three SenML Records. All resources share the 88 same base name "2001:db8::2/3306/0/", hence full names for resources 89 are "2001:db8::2/3306/0/5850", etc. 91 The CoAP [RFC7252] iPATCH and FETCH methods [RFC8132] enable 92 accessing and updating parts of a resource or multiple resources with 93 one request. 95 This document defines two new media types, one using the JavaScript 96 Object Notation (JSON) [RFC8259] and one using the Concise Binary 97 Object Representation (CBOR) [RFC7049], that can be used with the 98 CoAP iPATCH, PATCH, and FETCH methods for resources represented with 99 the SenML data model. The semantics of the new media types are the 100 same for the CoAP PATCH and iPATCH methods. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 Readers should also be familiar with the terms and concepts discussed 111 in [RFC8132] and [RFC8428]. Also the following terms are used in 112 this document: 114 Fetch Record: One set of parameters that is used to match SenML 115 Record(s). 117 Fetch Pack: One or more Fetch Records in an array structure. 119 Patch Record: One set of parameters similar to Fetch Record but also 120 containing instructions on how to change existing SenML Pack(s). 122 Patch Pack: One or more Patch Records in an array structure. 124 Target Record: A Record in a SenML Pack that is matching the 125 selection criteria of a Fetch or Patch Record and hence is a 126 target for a Fetch or Patch operation. 128 3. Using FETCH and iPATCH with SenML 130 The FETCH/iPATCH media types for SenML are modeled as extensions to 131 the SenML media type to enable re-use of existing SenML parsers and 132 generators, in particular on constrained devices. Unless mentioned 133 otherwise, FETCH and PATCH Packs are constructed with the same rules 134 and constraints as SenML Packs. The only difference to SenML media 135 type is allowing the use of "null" value for removing records with 136 the iPATCH method. 138 3.1. SenML FETCH 140 The FETCH method can be used to select and return parts of one or 141 more SenML Packs. The SenML Records are selected by giving the 142 name(s) of the resources using the SenML "name" and/or "base name" 143 Fields. 145 For example, to select resources "5850" and "5851" from the example 146 in Section 1, the following Fetch Pack can be used: 148 [ 149 {"bn":"2001:db8::2/3306/0/", "n":"5850"}, 150 {"n":"5851"} 151 ] 153 The result to a FETCH request with the example above would be: 155 [ 156 {"bn":"2001:db8::2/3306/0/", "n":"5850", "vb":true}, 157 {"n":"5851", "v":42}, 158 ] 160 When SenML Records contain also time values, a name may no longer 161 uniquely identify a single Record. When no time is given in a Fetch 162 Record, all SenML Records with the given name are matched. When time 163 is given in the Fetch Record, only a SenML Record (if any) with equal 164 time value and name is matched. 166 The resolved form of records (Section 4.6 of [RFC8428]) is used when 167 comparing the names and times of the Target and Fetch Records to 168 accommodate for differences in use of the base values. 170 3.2. SenML iPATCH 172 The iPATCH method can be used to change the values of SenML Records, 173 to add new Records, and to remove existing Records. The names and 174 times of the Patch Records are given and matched in same way as for 175 the Fetch Records, except each Patch Record can match at most one 176 Target Record. Patch Packs can also include new values and other 177 SenML Fields for the Records. 179 When the name in a Patch Record matches with the name in an existing 180 Record, the time values are compared. If the time values do not 181 exist or are equal in both Records, the Target Record is replaced 182 with the contents of the Patch Record. 184 If a Patch Record contains a name, or combination of a time value and 185 a name, that do not exist in any existing Record in the Pack, the 186 given Record, with all the fields it contains, is added to the Pack. 188 If a Patch Record has a value field with value null, the matched 189 Record (if any) is removed from the Pack. 191 For example, the following document could be given as iPATCH payload 192 to change/set values of two SenML Records for the example in 193 Section 1: 195 [ 196 {"bn":"2001:db8::2/3306/0/", "n":"5850", "vb":false}, 197 {"n":"5851", "v":10} 198 ] 200 If the request is successful, the resulting representation of the 201 example SenML Pack would be as follows: 203 [ 204 {"bn":"2001:db8::2/3306/0/", "n":"5850", "vb":false}, 205 {"n":"5851", "v":10}, 206 {"n":"5750", "vs":"Ceiling light"} 207 ] 209 4. Security Considerations 211 The security and privacy considerations of SenML apply also with the 212 FETCH and iPATCH methods. 214 In FETCH and iPATCH requests, the client can pass arbitrary names to 215 the target resource for manipulation. The resource implementer must 216 take care to only allow access to names that are actually part of (or 217 accessible through) the target resource. 219 If the client is not allowed to do a GET or PUT on the full target 220 resource (and thus all the names accessible through it), access 221 control rules must be evaluated for each record in the pack. 223 5. IANA Considerations 225 This document registers two new media types and CoAP Content-Format 226 IDs for both media types. 228 Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with 229 the RFC number of this document. 231 5.1. CoAP Content-Format Registration 233 IANA is requested to assign CoAP Content-Format IDs for the SenML 234 PATCH and FETCH media types in the "CoAP Content-Formats" sub- 235 registry, within the "CoRE Parameters" registry [RFC7252]. All IDs 236 are assigned from the "Expert Review" (0-255) range. The assigned 237 IDs are show in Table 1. 239 +-----------------------------+-----+ 240 | Media type | ID | 241 +-----------------------------+-----+ 242 | application/senml-etch+json | TBD | 243 | | | 244 | application/senml-etch+cbor | TBD | 245 +-----------------------------+-----+ 247 Table 1: CoAP Content-Format IDs 249 5.2. senml-etch+json Media Type 251 Type name: application 253 Subtype name: senml-etch+json 255 Required parameters: none 257 Optional parameters: none 259 Encoding considerations: Must be encoded as using a subset of the 260 encoding allowed in [RFC8259]. See RFC-AAAA for details. This 261 simplifies implementation of very simple system and does not impose 262 any significant limitations as all this data is meant for machine to 263 machine communications and is not meant to be human readable. 265 Security considerations: See Section 4 of RFC-AAAA. 267 Interoperability considerations: Applications MUST ignore any key 268 value pairs that they do not understand unless the key ends with the 269 '_' character in which case an error MUST be generated. This allows 270 backwards compatible extensions to this specification. 272 Published specification: RFC-AAAA 274 Applications that use this media type: Applications that use the 275 SenML media type for resource representation. 277 Fragment identifier considerations: N/A 279 Additional information: 281 Magic number(s): none 283 File extension(s): senml-etchj 285 Windows Clipboard Name: "SenML FETCH/PATCH format" 286 Macintosh file type code(s): none 288 Macintosh Universal Type Identifier code: org.ietf.senml-etch-json 289 conforms to public.text 291 Person & email address to contact for further information: Ari 292 Keranen ari.keranen@ericsson.com 294 Intended usage: COMMON 296 Restrictions on usage: None 298 Author: Ari Keranen ari.keranen@ericsson.com 300 Change controller: IESG 302 5.3. senml-etch+cbor Media Type 304 Type name: application 306 Subtype name: senml-etch+cbor 308 Required parameters: none 310 Optional parameters: none 312 Encoding considerations: Must be encoded as using [RFC7049]. See 313 RFC-AAAA for details. 315 Security considerations: See Section 4 of RFC-AAAA. 317 Interoperability considerations: Applications MUST ignore any key 318 value pairs that they do not understand unless the key ends with the 319 '_' character in which case an error MUST be generated. This allows 320 backwards compatible extensions to this specification. 322 Published specification: RFC-AAAA 324 Applications that use this media type: Applications that use the 325 SenML media type for resource representation. 327 Fragment identifier considerations: N/A 329 Additional information: 331 Magic number(s): none 333 File extension(s): senml-etchc 334 Macintosh file type code(s): none 336 Macintosh Universal Type Identifier code: org.ietf.senml-etch-cbor 337 conforms to public.data 339 Person & email address to contact for further information: Ari 340 Keranen ari.keranen@ericsson.com 342 Intended usage: COMMON 344 Restrictions on usage: None 346 Author: Ari Keranen ari.keranen@ericsson.com 348 Change controller: IESG 350 6. Acknowledgements 352 The use of FETCH and iPATCH methods with SenML was first introduced 353 by the OMA SpecWorks LwM2M v1.1 specification. This document 354 generalizes the use to any SenML representation. The authors would 355 like to thank Carsten Bormann, Christian Amsuess, Jaime Jimenez, 356 Klaus Hartke, and also everyone in the IETF CoRE and OMA SpecWorks 357 DMSE working groups for their contributions and reviews. 359 7. References 361 7.1. Normative References 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, 366 . 368 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 369 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 370 October 2013, . 372 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 373 Application Protocol (CoAP)", RFC 7252, 374 DOI 10.17487/RFC7252, June 2014, 375 . 377 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 378 FETCH Methods for the Constrained Application Protocol 379 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 380 . 382 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 383 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 384 May 2017, . 386 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 387 Interchange Format", STD 90, RFC 8259, 388 DOI 10.17487/RFC8259, December 2017, 389 . 391 [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 392 Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, 393 DOI 10.17487/RFC8428, August 2018, 394 . 396 7.2. Informative References 398 [IPSO] IPSO, "IPSO Smart Object Guidelines", 2018, 399 . 402 Authors' Addresses 404 Ari Keranen 405 Ericsson 407 Email: ari.keranen@ericsson.com 409 Mojan Mohajer 410 u-blox UK 412 Email: Mojan.Mohajer@u-blox.com