idnits 2.17.1 draft-ietf-core-senml-data-ct-04.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 8 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 July 2021) is 995 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 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 1590 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Keränen 3 Internet-Draft Ericsson 4 Intended status: Standards Track C. Bormann 5 Expires: 9 January 2022 Universität Bremen TZI 6 8 July 2021 8 SenML Data Value Content-Format Indication 9 draft-ietf-core-senml-data-ct-04 11 Abstract 13 The Sensor Measurement Lists (SenML) media type supports multiple 14 types of values, from numbers to text strings and arbitrary binary 15 data values. In order to simplify processing of the data values, 16 this document proposes to specify a new SenML field for indicating 17 the Content-Format of the data. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 9 January 2022. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. SenML Content-Format ("ct") Field . . . . . . . . . . . . . . 4 55 4. SenML Base Content-Format ("bct") Field . . . . . . . . . . . 4 56 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 6. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 62 9.2. Informative References . . . . . . . . . . . . . . . . . 8 63 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 The Sensor Measurement Lists (SenML) media types [RFC8428] can be 69 used to send various kinds of data. In the example given in 70 Figure 1, a temperature value, an indication whether a lock is open, 71 and a data value (with SenML field "vd") read from an NFC reader is 72 sent in a single SenML pack. 74 [ 75 {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":7.1}, 76 {"n":"open","vb":false}, 77 {"n":"nfc-reader","vd":"aGkgCg"} 78 ] 80 Figure 1: SenML pack with unidentified binary data 82 The receiver is expected to know how to interpret the data in the 83 "vd" field based on the context, e.g., name of the data source and 84 out-of-band knowledge of the application. However, this context may 85 not always be easily available to entities processing the SenML pack. 86 To facilitate automatic interpretation it is useful to be able to 87 indicate an Internet media type and content-coding right in the SenML 88 Record. The CoAP Content-Format (Section 12.3 of [RFC7252]) provides 89 just this information; enclosing a Content-Format number (in this 90 case number 60 as defined for content-type application/cbor in 91 [RFC8949]) in the Record is illustrated in Figure 2. All registered 92 CoAP Content-Formats are listed in the Content-Formats subregistry of 93 the CoRE Parameters registry [IANA.core-parameters]. 95 {"n":"nfc-reader", "vd":"gmNmb28YKg", "ct":"60"} 97 Figure 2: SenML Record with binary data identified as CBOR 99 In this example SenML Record, the data value contains a string "foo" 100 and a number 42 encoded in a CBOR [RFC8949] array. Since the example 101 above uses the JSON format of SenML, the data value containing the 102 binary CBOR value is base64-encoded (Section 5 of [RFC4648]). The 103 data value after base64 decoding is shown with CBOR diagnostic 104 notation in Figure 3. 106 82 # array(2) 107 63 # text(3) 108 666F6F # "foo" 109 18 2A # unsigned(42) 111 Figure 3: Example Data Value in CBOR diagnostic notation 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in 118 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 Media Type: A registered label for representations (byte strings) 122 prepared for interchange, identified by a Media-Type-Name 123 [RFC1590], [RFC6838]. 125 Media-Type-Name: A combination of a type-name and a subtype-name 126 registered in [IANA.media-types] as per [RFC6838], conventionally 127 identified by the two names separated by a slash. 129 Content-Type: A Media-Type-Name, optionally associated with 130 parameters (separated from the media type name and from each other 131 by a semicolon). In HTTP and many other protocols, used in a 132 "Content-Type" header field. 134 Content-Coding: a registered name for an encoding transformation 135 that has been or can be applied to a representation. Confusingly, 136 in HTTP the Content-Coding is then given in a header field called 137 "Content-Encoding"; we *never* use this term (except when we are 138 in error). 140 Content-Format: the combination of a Content-Type and a Content- 141 Coding, identified by (1) a numeric identifier defined by the 142 "CoAP Content-Formats" subregistry of [IANA.core-parameters] as 143 per [RFC7252] or (2) a Content-Format-String. 145 Content-Format-String: the string representation of the combination 146 of a Content-Type and a Content-Coding. 148 Content-Format-Spec: the string representation of a Content-Format; 149 either a Content-Format-String or the (decimal) string 150 representation of a Content-Format number. 152 Readers should also be familiar with the terms and concepts discussed 153 in [RFC8428]. 155 3. SenML Content-Format ("ct") Field 157 When a SenML Record contains a Data Value field ("vd"), the Record 158 MAY also include a Content-Format indication field, using label "ct". 159 The value of this field is a Content-Format-Spec, i.e., one of: 161 * a CoAP Content-Format identifier in decimal form with no leading 162 zeros (except for the value "0" itself). This value represents an 163 unsigned integer in the range of 0-65535, similar to the CoRE Link 164 Format [RFC6690] "ct" attribute). 166 * or a Content-Format-String containing a Content-Type and 167 optionally a Content-Coding (see below). 169 The syntax of this field is formally defined in Section 6. 171 The CoAP Content-Format number provides a simple and efficient way to 172 indicate the type of the data. Since some Internet media types and 173 their content coding and parameter alternatives do not have assigned 174 CoAP Content-Format numbers, using Content-Type and Content-Coding is 175 also allowed. Both methods use a string value in the "ct" field to 176 keep its data type consistent across uses. When the "ct" field 177 contains only digits, it is interpreted as a CoAP Content-Format 178 identifier. 180 To indicate that a Content-Coding is used with a Content-Type, the 181 Content-Coding value (e.g., "deflate" [RFC7230]) is appended to the 182 Content-Type value (media type and parameters, if any), separated by 183 a "@" sign. For example: "text/plain; charset=utf-8@deflate". If no 184 "@" sign is present outside the media type parameters, the Content- 185 Coding is not specified and the "identity" Content-Coding is used -- 186 no encoding transformation is employed. 188 4. SenML Base Content-Format ("bct") Field 190 The Base Content-Format Field, label "bct", provides a default value 191 for the Content-Format Field (label "ct") within its range. The 192 range of the base field includes the Record containing it, up to (but 193 not including) the next Record containing a "bct" field, if any, or 194 up to the end of the pack otherwise. Resolution (Section 4.6 of 195 [RFC8428]) of this base field is performed by adding its value with 196 the label "ct" to all Records in this range that carry a "vd" field 197 but do not already contain a Content-Format ("ct") field. 199 5. Examples 201 The following examples are valid values for the "ct" and "bct" fields 202 (explanation/comments in parenthesis): 204 * "60" (CoAP Content-Format for "application/cbor") 206 * "0" (CoAP Content-Format for "text/plain" with parameter 207 "charset=utf-8") 209 * "application/json" (JSON Content-Type -- equivalent to "50" CoAP 210 Content-Format identifier) 212 * "application/json@deflate" (JSON Content-Type with "deflate" as 213 Content-Coding -- equivalent to "11050" CoAP Content-Format 214 identifier) 216 * "text/csv" (Comma-Separated Values (CSV) [RFC4180] Content-Type) 218 * "text/csv@gzip" (CSV with "gzip" as Content-Coding) 220 6. ABNF 222 This specification provides a formal definition of the syntax of 223 Content-Format-Spec strings using ABNF notation [RFC5234], which 224 contains three new rules and a number of rules collected and adapted 225 from various RFCs [RFC7231] [RFC6838] [RFC5234] [RFC8866]. 227 ; New in this document 229 Content-Format-Spec = Content-Format-Number / Content-Format-String 231 Content-Format-Number = "0" / (POS-DIGIT *DIGIT) 232 Content-Format-String = Content-Type ["@" Content-Coding] 234 ; Cleaned up from RFC 7231: 236 Content-Type = Media-Type-Name *( *SP ";" *SP parameter ) 237 parameter = token "=" ( token / quoted-string ) 239 token = 1*tchar 240 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" 241 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 242 / DIGIT / ALPHA 243 quoted-string = %x22 *qdtext %x22 244 qdtext = SP / %x21 / %x23-5B / %x5D-7E 246 ; Adapted from section 3.1.2.1 of RFC 7231 248 Content-Coding = token 250 ; Adapted from various specs 252 Media-Type-Name = type-name "/" subtype-name 254 ; RFC 6838 256 type-name = restricted-name 257 subtype-name = restricted-name 259 restricted-name = restricted-name-first *126restricted-name-chars 260 restricted-name-first = ALPHA / DIGIT 261 restricted-name-chars = ALPHA / DIGIT / "!" / "#" / 262 "$" / "&" / "-" / "^" / "_" 263 restricted-name-chars =/ "." ; Characters before first dot always 264 ; specify a facet name 265 restricted-name-chars =/ "+" ; Characters after last plus always 266 ; specify a structured syntax suffix 268 ; Boilerplate from RFC 5234 and RFC 8866 270 DIGIT = %x30-39 ; 0 – 9 271 POS-DIGIT = %x31-39 ; 1 – 9 272 ALPHA = %x41-5A / %x61-7A ; A – Z / a – z 273 SP = %x20 275 Figure 4: ABNF syntax of Content-Format-Spec 277 7. Security Considerations 279 The indication of a media type in the data does not exempt a 280 consuming application from properly checking its inputs. Also, the 281 ability for an attacker to supply crafted SenML data that specify 282 media types chosen by the attacker may expose vulnerabilities of 283 handlers for these media types to the attacker. This includes 284 "decompression bombs", compressed data that is crafted to decompress 285 to extremely large data items. 287 8. IANA Considerations 289 (Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" 290 with the RFC number of this specification and remove this note.) 291 IANA is requested to assign new labels in the "SenML Labels" 292 subregistry of the SenML registry [IANA.senml] (as defined in 293 [RFC8428]) for the Content-Format indication as per Table 1: 295 +=====================+=======+===========+==========+===========+ 296 | Name | Label | JSON Type | XML Type | Reference | 297 +=====================+=======+===========+==========+===========+ 298 | Base Content-Format | bct | String | string | RFC-AAAA | 299 +---------------------+-------+-----------+----------+-----------+ 300 | Content-Format | ct | String | string | RFC-AAAA | 301 +---------------------+-------+-----------+----------+-----------+ 303 Table 1: IANA Registration for new SenML Labels 305 9. References 307 9.1. Normative References 309 [IANA.core-parameters] 310 IANA, "Constrained RESTful Environments (CoRE) 311 Parameters", 312 . 314 [IANA.media-types] 315 IANA, "Media Types", 316 . 318 [IANA.senml] 319 IANA, "Sensor Measurement Lists (SenML)", 320 . 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, 324 DOI 10.17487/RFC2119, March 1997, 325 . 327 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 328 Specifications: ABNF", STD 68, RFC 5234, 329 DOI 10.17487/RFC5234, January 2008, 330 . 332 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 333 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 334 DOI 10.17487/RFC7231, June 2014, 335 . 337 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 338 Application Protocol (CoAP)", RFC 7252, 339 DOI 10.17487/RFC7252, June 2014, 340 . 342 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 343 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 344 May 2017, . 346 [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 347 Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, 348 DOI 10.17487/RFC8428, August 2018, 349 . 351 9.2. Informative References 353 [RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590, 354 DOI 10.17487/RFC1590, March 1994, 355 . 357 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 358 Separated Values (CSV) Files", RFC 4180, 359 DOI 10.17487/RFC4180, October 2005, 360 . 362 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 363 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 364 . 366 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 367 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 368 . 370 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 371 Specifications and Registration Procedures", BCP 13, 372 RFC 6838, DOI 10.17487/RFC6838, January 2013, 373 . 375 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 376 Protocol (HTTP/1.1): Message Syntax and Routing", 377 RFC 7230, DOI 10.17487/RFC7230, June 2014, 378 . 380 [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 381 Session Description Protocol", RFC 8866, 382 DOI 10.17487/RFC8866, January 2021, 383 . 385 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 386 Representation (CBOR)", STD 94, RFC 8949, 387 DOI 10.17487/RFC8949, December 2020, 388 . 390 Acknowledgements 392 The authors would like to thank Sérgio Abreu for the discussions 393 leading to the design of this extension and Isaac Rivera for reviews 394 and feedback. Klaus Hartke suggested not burdening this draft with a 395 separate mandatory-to-implement version of the fields. Alexey 396 Melnikov, Jim Schaad, and Thomas Fossati provided helpful comments at 397 Working-Group last call. Marco Tiloca asked for clarifying and using 398 the term Content-Format-Spec. 400 Authors' Addresses 402 Ari Keränen 403 Ericsson 404 FI-02420 Jorvas 405 Finland 407 Email: ari.keranen@ericsson.com 409 Carsten Bormann 410 Universität Bremen TZI 411 Postfach 330440 412 D-28359 Bremen 413 Germany 415 Phone: +49-421-218-63921 416 Email: cabo@tzi.org