idnits 2.17.1 draft-bormann-cbor-sequence-00.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 : ---------------------------------------------------------------------------- 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 (February 24, 2019) is 1887 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) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track February 24, 2019 5 Expires: August 28, 2019 7 Concise Binary Object Representation (CBOR) Sequences 8 draft-bormann-cbor-sequence-00 10 Abstract 12 This document describes the Concise Binary Object Representation 13 (CBOR) Sequence format and associated media type "application/cbor- 14 seq". A CBOR Sequence consists of any number of encoded CBOR data 15 items, simply concatenated in sequence. 17 Structured syntax suffixes for media types allow other media types to 18 build on them and make it explicit that they are built on an existing 19 media type as their foundation. This specification defines and 20 registers "+cbor-seq" as a structured syntax suffix for CBOR 21 Sequences. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 28, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 59 2. CBOR Sequence Format . . . . . . . . . . . . . . . . . . . . 3 60 3. The "+cbor-seq" Structured Syntax Suffix . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 4 64 5.2. CoAP Content-Format Registration . . . . . . . . . . . . 5 65 5.3. Structured Syntax Suffix . . . . . . . . . . . . . . . . 6 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 6.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 The Concise Binary Object Representation (CBOR) [RFC7049] can be used 75 for serialization of data in the JSON [RFC8259] data model or its 76 own, somewhat expanded data model. When serializing a sequence of 77 such values, it is sometimes convenient to have a format where these 78 sequences can simply be concatenated to obtain a serialization of the 79 concatenated sequence of values, or to encode a sequence of values 80 that might grow at the end by just appending further CBOR data items. 82 This document describes the concept and format of "CBOR Sequences", 83 which are composed of zero or more encoded CBOR data items. CBOR 84 Sequences can be consumed (and produced) incrementally without a 85 streaming parser (or streaming encoder). 87 This document defines and registers the "application/cbor-seq" media 88 type in the media type registry. Media type structured syntax 89 suffixes [RFC6838] were introduced as a way for a media type to 90 signal that it is based on another media type as its foundation. 91 CBOR [RFC7049] defines the "+cbor" structured syntax suffix. This 92 document defines and registers the "+cbor-seq" structured syntax 93 suffix in the "Structured Syntax Suffix Registry". 95 1.1. Conventions Used in This Document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in 100 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 2. CBOR Sequence Format 105 Formally, a CBOR Sequence is a sequence of bytes that is either 107 o an empty (zero-length) sequence of bytes 109 o the sequence of bytes making up an encoded CBOR data item 110 [RFC7049], followed by a CBOR Sequence. 112 In short, concatenating zero or more encoded CBOR data items 113 generates a CBOR Sequence. 115 There is no end of sequence indicator. (If one is desired, CBOR- 116 encoding an array of the CBOR data model values being encoded -- 117 employing either a definite or an indefinite length encoding -- as a 118 single CBOR data item may actually be the more appropriate 119 representation.) 121 This specification makes use of the fact that CBOR data items are 122 self-delimiting. Decoding a CBOR Sequence works as follows: 124 o If the CBOR Sequence is an empty sequence of bytes, the result is 125 an empty sequence of CBOR data model values. 127 o Otherwise, decode a single CBOR data item from the bytes of the 128 CBOR sequence, and insert the resulting CBOR data model value at 129 the start of the result of decoding the rest of the bytes as a 130 CBOR sequence. 132 This means that if any data item in the sequence is not well-formed, 133 it is not possible to reliably decode the rest of the sequence. (An 134 implementation may be able to recover from some errors in a sequence 135 of bytes that is almost, but not entirely a well-formed encoded CBOR 136 data item. Handling malformed data is outside the scope of this 137 specification.) 139 This also means that the CBOR Sequence format can reliably detect 140 truncation of the last CBOR data item in the sequence, but not 141 entirely missing CBOR data items at the end. A CBOR Sequence decoder 142 that is used for consuming streaming CBOR Sequence data may simply 143 pause for more data (e.g., by suspending and later resuming decoding) 144 in case a truncated final item is being received. 146 3. The "+cbor-seq" Structured Syntax Suffix 148 The use case for the "+cbor-seq" structured syntax suffix is the same 149 as for "+cbor": It SHOULD be used by a media type when parsing the 150 CBOR Sequence of the object of the media type leads to a meaningful 151 result, by simply using the generic CBOR Sequence processing. 153 Applications encountering such a media type can then either simply 154 use generic processing if all they need is a generic view of the CBOR 155 Sequence, or they can use generic CBOR Sequence tools for initial 156 parsing and then implement their own specific processing on top of 157 that generic parsing tool. 159 4. Security Considerations 161 The security considerations of CBOR [RFC7049] apply. This format 162 provides no cryptographic integrity protection of any kind, but can 163 be combined with security specifications such as COSE [RFC8152] to do 164 so. 166 As usual, decoders must operate on input that is assumed to be 167 untrusted. This means that decoders must fail gracefully in the face 168 of malicious inputs. 170 5. IANA Considerations 172 5.1. Media Type 174 Media types are registered in the media types registry 175 [IANA.media-types]. IANA is requested to register the MIME media 176 type for CBOR Sequence, application/cbor-seq, as follows: 178 Type name: application 180 Subtype name: cbor-seq 182 Required parameters: N/A 184 Optional parameters: N/A 186 Encoding considerations: binary 188 Security considerations: See RFCthis, Section 4. 190 Interoperability considerations: Described herein. 192 Published specification: RFCthis. 194 Applications that use this media type: Data serialization and 195 deserialization. 197 Fragment identifier considerations: N/A 199 Additional information: 201 o Deprecated alias names for this type: N/A 203 o Magic number(s): N/A 205 o File extension(s): N/A 207 o Macintosh file type code(s): N/A 209 Person & email address to contact for further information: 210 cbor@ietf.org 212 Intended usage: COMMON 214 Author: Carsten Bormann (cabo@tzi.org) 216 Change controller: IETF 218 5.2. CoAP Content-Format Registration 220 IANA is requested to assign a CoAP Content-Format ID for the media 221 type "application/cbor-seq", in the CoAP Content-Formats subregistry 222 of the core-parameter registry [IANA.core-parameters], from the 223 "Expert Review" (0-255) range. The assigned ID is shown in Table 1. 225 +----------------------+----------+-------+-----------+ 226 | Media type | Encoding | ID | Reference | 227 +----------------------+----------+-------+-----------+ 228 | application/cbor-seq | - | TBD63 | RFCthis | 229 +----------------------+----------+-------+-----------+ 231 Table 1: CoAP Content-Format ID 233 RFC editor: Please replace TBD63 by the number actually assigned and 234 delete this paragraph. 236 5.3. Structured Syntax Suffix 238 Structured Syntax Suffixes are registered within the "Structured 239 Syntax Suffix Registry" maintained at 240 [IANA.media-type-structured-suffix]. IANA is requested to register 241 the "+cbor-seq" structured syntax suffix in accordance with 242 [RFC6838], as follows: 244 Name: CBOR Sequence 246 +suffix: +cbor-seq 248 References: RFCthis 250 Encoding considerations: binary 252 Fragment identifier considerations: The syntax and semantics of 253 fragment identifiers specified for +cbor-seq SHOULD be as 254 specified for "application/cbor-seq". (At publication of this 255 document, there is no fragment identification syntax defined for 256 "application/cbor-seq".) 258 The syntax and semantics for fragment identifiers for a 259 specific "xxx/yyy+cbor-seq" SHOULD be processed as follows: 261 For cases defined in +cbor-seq, where the fragment 262 identifier resolves per the +cbor-seq rules, then process as 263 specified in +cbor-seq. 265 For cases defined in +cbor-seq, where the fragment 266 identifier does not resolve per the +cbor-seq rules, then 267 process as specified in "xxx/yyy+cbor-seq". 269 For cases not defined in +cbor-seq, then process as 270 specified in "xxx/yyy+cbor-seq". 272 Interoperability considerations: n/a 274 Security considerations: See RFCthis, Section 4 276 Contact: CBOR WG mailing list (cbor@ietf.org), or any IESG- 277 designated successor. 279 Author/Change controller: IETF 281 6. References 283 6.1. Normative References 285 [IANA.core-parameters] 286 IANA, "Constrained RESTful Environments (CoRE) 287 Parameters", 288 . 290 [IANA.media-type-structured-suffix] 291 IANA, "Structured Syntax Suffix Registry", 292 . 295 [IANA.media-types] 296 IANA, "Media Types", 297 . 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, 301 DOI 10.17487/RFC2119, March 1997, 302 . 304 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 305 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 306 October 2013, . 308 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 309 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 310 May 2017, . 312 6.2. Informative References 314 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 315 Specifications and Registration Procedures", BCP 13, 316 RFC 6838, DOI 10.17487/RFC6838, January 2013, 317 . 319 [RFC7464] Williams, N., "JavaScript Object Notation (JSON) Text 320 Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015, 321 . 323 [RFC8091] Wilde, E., "A Media Type Structured Syntax Suffix for JSON 324 Text Sequences", RFC 8091, DOI 10.17487/RFC8091, February 325 2017, . 327 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 328 RFC 8152, DOI 10.17487/RFC8152, July 2017, 329 . 331 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 332 Interchange Format", STD 90, RFC 8259, 333 DOI 10.17487/RFC8259, December 2017, 334 . 336 Acknowledgements 338 This draft has mostly been generated from [RFC7464] by Nico Williams 339 and [RFC8091] by Erik Wilde, which do a similar, but slightly more 340 complicated exercise for JSON [RFC8259]. Laurence Lundblade raised 341 an issue on the CBOR mailing list that pointed out the need for this 342 document. 344 Author's Address 346 Carsten Bormann 347 Universitaet Bremen TZI 348 Postfach 330440 349 Bremen D-28359 350 Germany 352 Phone: +49-421-218-63921 353 Email: cabo@tzi.org