idnits 2.17.1 draft-ietf-cbor-packed-05.txt: -(3): 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 3 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 (20 April 2022) is 730 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 Universität Bremen TZI 4 Intended status: Informational 20 April 2022 5 Expires: 22 October 2022 7 Packed CBOR 8 draft-ietf-cbor-packed-05 10 Abstract 12 The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94) 13 is a data format whose design goals include the possibility of 14 extremely small code size, fairly small message size, and 15 extensibility without the need for version negotiation. 17 CBOR does not provide any forms of data compression. CBOR data 18 items, in particular when generated from legacy data models, often 19 allow considerable gains in compactness when applying data 20 compression. While traditional data compression techniques such as 21 DEFLATE (RFC 1951) can work well for CBOR encoded data items, their 22 disadvantage is that the receiver needs to uncompress the compressed 23 form to make use of the data. 25 This specification describes Packed CBOR, a simple transformation of 26 a CBOR data item into another CBOR data item that is almost as easy 27 to consume as the original CBOR data item. A separate decompression 28 step is therefore often not required at the receiver. 30 Note to Readers 32 This is a working-group draft of the CBOR working group of the IETF, 33 https://datatracker.ietf.org/wg/cbor/about/ 34 (https://datatracker.ietf.org/wg/cbor/about/). Discussion takes 35 places on the GitHub repository https://github.com/cbor-wg/cbor- 36 packed (https://github.com/cbor-wg/cbor-packed) and on the CBOR WG 37 mailing list, https://www.ietf.org/mailman/listinfo/cbor 38 (https://www.ietf.org/mailman/listinfo/cbor). 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on 22 October 2022. 57 Copyright Notice 59 Copyright (c) 2022 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Revised BSD License text as 68 described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Revised BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Packed CBOR . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2.1. Packing Tables . . . . . . . . . . . . . . . . . . . . . 4 77 2.2. Referencing Shared Items . . . . . . . . . . . . . . . . 5 78 2.3. Referencing Affix Items . . . . . . . . . . . . . . . . . 6 79 2.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7 80 3. Table Setup . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 3.1. Basic Packed CBOR . . . . . . . . . . . . . . . . . . . . 9 82 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 86 6.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 88 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 The Concise Binary Object Representation (CBOR, [STD94]) is a data 94 format whose design goals include the possibility of extremely small 95 code size, fairly small message size, and extensibility without the 96 need for version negotiation. 98 CBOR does not provide any forms of data compression. CBOR data 99 items, in particular when generated from legacy data models, often 100 allow considerable gains in compactness when applying data 101 compression. While traditional data compression techniques such as 102 DEFLATE [RFC1951] can work well for CBOR encoded data items, their 103 disadvantage is that the receiver needs to uncompress the compressed 104 form to make use of the data. 106 This specification describes Packed CBOR, a simple transformation of 107 a CBOR data item into another CBOR data item that is almost as easy 108 to consume as the original CBOR data item. A separate decompression 109 step is therefore often not required at the receiver. 111 This document defines the Packed CBOR format by specifying the 112 transformation from a Packed CBOR data item to the original CBOR data 113 item; it does not define an algorithm for a packer. Different 114 packers can differ in the amount of effort they invest in arriving at 115 a minimal packed form; often, they simply employ the sharing that is 116 natural for a specific application. 118 Packed CBOR can make use of two kinds of optimization: 120 * item sharing: substructures (data items) that occur repeatedly in 121 the original CBOR data item can be collapsed to a simple reference 122 to a common representation of that data item. The processing 123 required during consumption is limited to following that 124 reference. 126 * affix sharing: data items (strings, containers) that share a 127 prefix or suffix (affix) can be replaced by a reference to a 128 common affix plus the rest of the data item. For strings, the 129 processing required during consumption is similar to following the 130 affix reference plus that for an indefinite-length string. 132 A specific application protocol that employs Packed CBOR might allow 133 both kinds of optimization or limit the representation to item 134 sharing only. 136 Packed CBOR is defined in two parts: Referencing packing tables 137 (Section 2) and setting up packing tables (Section 3). 139 1.1. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in 144 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 Packed reference: A shared item reference or an affix reference. 149 Shared item reference: A reference to a shared item as defined in 150 Section 2.2. 152 Affix reference: A reference that combines an affix item as defined 153 in Section 2.3. 155 Affix: Prefix or suffix. 157 Packing tables: The triple of a shared item table, a prefix table, 158 and a suffix table. 160 Current set: The packing tables in effect at the data item under 161 consideration. 163 Expansion: The result of applying a packed reference in the context 164 of given Packing tables. 166 The definitions of [STD94] apply. Specifically: The term "byte" is 167 used in its now customary sense as a synonym for "octet"; "byte 168 strings" are CBOR data items carrying a sequence of zero or more 169 (binary) bytes, while "text strings" are CBOR data items carrying a 170 sequence of zero or more Unicode code points, encoded in UTF-8 171 [STD63]. 173 Where bit arithmetic is explained, this document uses the notation 174 familiar from the programming language C (including C++14's 0bnnn 175 binary literals), except that, in the plain text form of this 176 document, the operator "^" stands for exponentiation, and, in the 177 HTML and PDF versions, subtraction and negation are rendered as a 178 hyphen ("-", as are various dashes). 180 2. Packed CBOR 182 This section describes the packing tables, their structure, and how 183 they are referenced. 185 2.1. Packing Tables 187 At any point within a data item making use of Packed CBOR, there is a 188 Current Set of packing tables that applies. 190 There are three packing tables in a Current Set: 192 * Shared item table 194 * Prefix table 195 * Suffix table 197 Without any table setup, all these tables are empty arrays. 198 Table setup can cause these arrays to be non-empty, where the 199 elements are (potentially themselves packed) data items. Each of the 200 tables is indexed by an unsigned integer (starting from 0). Such an 201 index may be derived from information in tags and their content as 202 well as from CBOR simple values. 204 2.2. Referencing Shared Items 206 Shared items are stored in the shared item table of the Current Set. 208 The shared data items are referenced by using the reference data 209 items in Table 1. When reconstructing the original data item, such a 210 reference is replaced by the referenced data item, which is then 211 recursively unpacked. 213 +===========================+==============+ 214 | reference | table index | 215 +===========================+==============+ 216 | Simple value 0-15 | 0-15 | 217 +---------------------------+--------------+ 218 | Tag 6(unsigned integer N) | 16 + 2*N | 219 +---------------------------+--------------+ 220 | Tag 6(negative integer N) | 16 - 2*N - 1 | 221 +---------------------------+--------------+ 223 Table 1: Referencing Shared Values 225 As examples in CBOR diagnostic notation (Section 8 of [STD94]), the 226 first 22 elements of the shared item table are referenced by 227 simple(0), simple(1), ... simple(15), 6(0), 6(-1), 6(1), 6(-2), 6(2), 228 6(-3). (The alternation between unsigned and negative integers for 229 even/odd table index values -- "zigzag encoding" -- makes systematic 230 use of shorter integer encodings first.) 232 Taking into account the encoding of these referring data items, there 233 are 16 one-byte references, 48 two-byte references, 512 three-byte 234 references, 131072 four-byte references, etc. As CBOR integers can 235 grow to very large (or very negative) values, there is no practical 236 limit to how many shared items might be used in a Packed CBOR item. 238 Note that the semantics of Tag 6 depend on its tag content: An 239 integer turns the tag into a shared item reference, whereas a string 240 or container (map or array) turns it into a prefix reference (see 241 Table 2). Note also that the tag content of Tag 6 may itself be 242 packed, so it may need to be unpacked to make this determination. 244 2.3. Referencing Affix Items 246 Prefix items are stored in the prefix table of the Current Set; 247 suffix items are stored in the suffix table of the Current Set. We 248 collectively call these items affix items; when referencing, which of 249 the tables is actually used depends on whether a prefix or a suffix 250 reference was used. 252 +===================================+================+ 253 | prefix reference | table index | 254 +===================================+================+ 255 | Tag 6(suffix) | 0 | 256 +-----------------------------------+----------------+ 257 | Tag 225-255(suffix) | 1-31 | 258 +-----------------------------------+----------------+ 259 | Tag 28704-32767(suffix) | 32-4095 | 260 +-----------------------------------+----------------+ 261 | Tag 1879052288-2147483647(suffix) | 4096-268435455 | 262 +-----------------------------------+----------------+ 264 Table 2: Referencing Prefix Values 266 +===================================+===============+ 267 | suffix reference | table index | 268 +===================================+===============+ 269 | Tag 216-223(prefix) | 0-7 | 270 +-----------------------------------+---------------+ 271 | Tag 27647-28671(prefix) | 8-1023 | 272 +-----------------------------------+---------------+ 273 | Tag 1811940352-1879048191(prefix) | 1024-67108863 | 274 +-----------------------------------+---------------+ 276 Table 3: Referencing Suffix Values 278 Affix data items are referenced by using the data items in Table 2 279 and Table 3. The tag number indicates the table used (prefix or 280 suffix) and a table index (an unsigned integer); the tag content 281 contains a "rump item". When reconstructing the original data item, 282 such a reference is replaced by a data item constructed from the 283 referenced affix data item (affix, which might need to be recursively 284 unpacked first) "concatenated" with the tag content (rump, again 285 possibly recursively unpacked). 287 * For a rump of type array and map, the affix also needs to be an 288 array or a map. For an array, the elements from the prefix are 289 prepended to the rump array, while the elements from a suffix are 290 appended. For a map, the entries in the affix are added to those 291 of the rump; prefix and suffix references differ in how entries 292 with identical keys are combined: for prefix references, an entry 293 in the rump with the same key as an entry in the affix overrides 294 the one in the affix, while for suffix references, an entry in the 295 affix overrides an entry in the rump that has the same key. 297 | NOTE: One application of the rule for prefix references is to 298 | supply default values out of a dictionary, which can then be 299 | overridden by the entries in the map supplied as the rump 300 | value. Note that this pattern provides no way to remove a map 301 | entry from the prefix table entry. 303 * For a rump of one of the string types, the affix also needs to be 304 one of the string types; the bytes of the strings are concatenated 305 as specified (prefix + rump, rump + suffix). The result of the 306 concatenation gets the type of the rump; this way a single affix 307 can be used to build both byte and text strings, depending on what 308 type of rump is being used. 310 As a contrived (but short) example, if the prefix table is ["foobar", 311 "foob", "fo"], the following prefix references will all unpack to 312 "foobart": 6("t"), 224("art"), 225("obart") (the last example is not 313 an optimization). 315 Taking into account the encoding, there is one single-byte prefix 316 reference, 31 (2^5-2^0) two-byte references, 4064 (2^12-2^5) three- 317 byte references, and 26843160 (2^28-2^12) five-byte references for 318 prefixes. 268435455 (2^28) is an artificial limit, but should be high 319 enough that there, again, is no practical limit to how many prefix 320 items might be used in a Packed CBOR item. The numbers for suffix 321 references are one quarter of those, except that there is no single- 322 byte reference and 8 two-byte references. 324 | Rationale: Experience suggests that prefix packing might be 325 | more likely than suffix packing. Also for this reason, there 326 | is no intent to spend a 1+0 tag value for suffix packing. 328 2.4. Discussion 330 This specification uses up a large number of Simple Values and Tags, 331 in particular one of the rare one-byte tags and two thirds of the 332 one-byte simple values. Since the objective is compression, this is 333 warranted only based on a consensus that this specific format could 334 be useful for a wide area of applications, while maintaining 335 reasonable simplicity in particular at the side of the consumer. 337 A maliciously crafted Packed CBOR data item might contain a reference 338 loop. A consumer/decompressor MUST protect against that. 340 | Different strategies for decoding/consuming Packed CBOR are 341 | available. 342 | For example: 343 | 344 | * the decoder can decode and unpack the packed item, 345 | presenting an unpacked data item to the application. In 346 | this case, the onus of dealing with loops is on the 347 | decoder. (This strategy generally has the highest memory 348 | consumption, but also the simplest interface to the 349 | application.) Besides avoiding getting stuck in a 350 | reference loop, the decoder will need to control its 351 | resource allocation, as data items can "blow up" during 352 | unpacking. 353 | 354 | * the decoder can be oblivious of Packed CBOR. In this 355 | case, the onus of dealing with loops is on the 356 | application, as is the entire onus of dealing with Packed 357 | CBOR. 358 | 359 | * hybrid models are possible, for instance: The decoder 360 | builds a data item tree directly from the Packed CBOR as 361 | if it were oblivious, but also provides accessors that 362 | hide (resolve) the packing. In this specific case, the 363 | onus of dealing with loops is on the accessors. 364 | 365 | In general, loop detection can be handled in a similar way in 366 | which loops of symbolic links are handled in a file system: A 367 | system-wide limit (often 31 or 40 indirections for symbolic 368 | links) is applied to any reference chase. 370 | NOTE: The present specification does nothing to help with the 371 | packing of CBOR sequences [RFC8742]; maybe such a specification 372 | should be added. 374 3. Table Setup 376 The packing references described in Section 2 assume that packing 377 tables have been set up. 379 By default, all three tables are empty (zero-length arrays). 381 Table setup can happen in one of two ways: 383 * By the application environment, e.g., a media type. These can 384 define tables that amount to a static dictionary that can be used 385 in a CBOR data item for this application environment. Note that, 386 without this information, a data item that uses such a static 387 dictionary can be decoded at the CBOR level, but not fully 388 unpacked. The table setup mechanisms provided by this document 389 are defined in such a way that an unpacker can at least recognize 390 if this is the case. 392 * By one or more tags enclosing the packed content. These can be 393 defined to add to the packing tables that already apply to the 394 tag. Usually, the semantics of the tag will be to prepend items 395 to one of the tables. Note that it may be useful to leave a 396 particular efficiency tier alone and only prepend to a higher 397 tier; e.g., a tag could insert shared items at table index 16 and 398 shift anything that was already there further down in the array 399 while leaving index 0 to 15 alone. Explicit additions by tag can 400 combine with application-environment supplied tables that apply to 401 the entire CBOR data item. 403 For table setup, the present specification only defines a single tag, 404 which operates by prepending to the (by default empty) tables. 406 | We could also define a tag for dictionary referencing (or 407 | include that in the basic packed CBOR), but the desirable 408 | details are likely to vary considerably between applications. 409 | A URI-based reference would be easy to add, but might be too 410 | inefficient when used in the likely combination with an ni: URI 411 | [RFC6920]. 413 3.1. Basic Packed CBOR 415 A predefined tag for packing table setup is defined in CDDL [RFC8610] 416 as in Figure 1: 418 Basic-Packed-CBOR = #6.51([[*shared-item], [*prefix-item], 419 [*suffix-item], rump]) 420 rump = any 421 prefix-item = any 422 suffix-item = any 423 shared-item = any 425 Figure 1: Packed CBOR in CDDL 427 (This assumes the allocation of tag number 51 for this tag.) 429 The arrays given as the first, second, and third element of the 430 content of the tag 51 are prepended to the tables for shared items, 431 prefixes, and suffixes that apply to the entire tag (by default empty 432 tables). 434 The original CBOR data item can be reconstructed by recursively 435 replacing shared, prefix, and suffix references encountered in the 436 rump by their expansions. 438 Packed item references in the newly constructed (low-numbered) parts 439 of the table need to be interpreted in the number space of that table 440 (which includes the, now higher-numbered, inherited parts), while 441 references in any existing, inherited (higher-numbered) part continue 442 to use the (more limited) number space of the inherited table. 444 4. IANA Considerations 446 In the registry "CBOR Tags" [IANA.cbor-tags], IANA is requested to 447 allocate the tags defined in Table 4. 449 +=======================+========+=========+========================+ 450 | Tag |Data |Semantics| Reference | 451 | |Item | | | 452 +=======================+========+=========+========================+ 453 | 6 |integer |Packed | draft-ietf-cbor-packed | 454 | |(for |CBOR: | | 455 | |shared);|shared/ | | 456 | |text |prefix | | 457 | |string, | | | 458 | |byte | | | 459 | |string, | | | 460 | |array, | | | 461 | |map (for| | | 462 | |prefix) | | | 463 +-----------------------+--------+---------+------------------------+ 464 | 225-255 |text |Packed | draft-ietf-cbor-packed | 465 | |string, |CBOR: | | 466 | |byte |prefix | | 467 | |string, | | | 468 | |array, | | | 469 | |map | | | 470 +-----------------------+--------+---------+------------------------+ 471 | 28704-32767 |text |Packed | draft-ietf-cbor-packed | 472 | |string, |CBOR: | | 473 | |byte |prefix | | 474 | |string, | | | 475 | |array, | | | 476 | |map | | | 477 +-----------------------+--------+---------+------------------------+ 478 | 1879052288-2147483647 |text |Packed | draft-ietf-cbor-packed | 479 | |string, |CBOR: | | 480 | |byte |prefix | | 481 | |string, | | | 482 | |array, | | | 483 | |map | | | 484 +-----------------------+--------+---------+------------------------+ 485 | 216-223 |text |Packed | draft-ietf-cbor-packed | 486 | |string, |CBOR: | | 487 | |byte |suffix | | 488 | |string, | | | 489 | |array, | | | 490 | |map | | | 491 +-----------------------+--------+---------+------------------------+ 492 | 27647-28671 |text |Packed | draft-ietf-cbor-packed | 493 | |string, |CBOR: | | 494 | |byte |suffix | | 495 | |string, | | | 496 | |array, | | | 497 | |map | | | 498 +-----------------------+--------+---------+------------------------+ 499 | 1811940352-1879048191 |text |Packed | draft-ietf-cbor-packed | 500 | |string, |CBOR: | | 501 | |byte |suffix | | 502 | |string, | | | 503 | |array, | | | 504 | |map | | | 505 +-----------------------+--------+---------+------------------------+ 507 Table 4: Values for Tag Numbers 509 In the registry "CBOR Simple Values" [IANA.cbor-simple-values], IANA 510 is requested to allocate the simple values defined in Table 5. 512 +=======+=====================+========================+ 513 | Value | Semantics | Reference | 514 +=======+=====================+========================+ 515 | 0-15 | Packed CBOR: shared | draft-ietf-cbor-packed | 516 +-------+---------------------+------------------------+ 518 Table 5: Simple Values 520 5. Security Considerations 522 The security considerations of [STD94] apply. 524 Loops in the Packed CBOR can be used as a denial of service attack, 525 see Section 2.4. 527 As the unpacking is deterministic, packed forms can be used as 528 signing inputs. (Note that if external dictionaries are added to 529 cbor-packed, this requires additional consideration.) 531 6. References 533 6.1. Normative References 535 [IANA.cbor-simple-values] 536 IANA, "Concise Binary Object Representation (CBOR) Simple 537 Values", 538 . 540 [IANA.cbor-tags] 541 IANA, "Concise Binary Object Representation (CBOR) Tags", 542 . 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, 546 DOI 10.17487/RFC2119, March 1997, 547 . 549 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 550 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 551 May 2017, . 553 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 554 Definition Language (CDDL): A Notational Convention to 555 Express Concise Binary Object Representation (CBOR) and 556 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 557 June 2019, . 559 [STD94] Bormann, C. and P. Hoffman, "Concise Binary Object 560 Representation (CBOR)", STD 94, RFC 8949, 561 DOI 10.17487/RFC8949, December 2020, 562 . 564 6.2. Informative References 566 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 567 version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, 568 . 570 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 571 Keranen, A., and P. Hallam-Baker, "Naming Things with 572 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 573 . 575 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 576 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 577 October 2013, . 579 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 580 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 581 . 583 [STD63] Yergeau, F., "UTF-8, a transformation format of ISO 584 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 585 2003, . 587 Appendix A. Examples 589 The (JSON-compatible) CBOR data structure depicted in Figure 2, 400 590 bytes of binary CBOR, could lead to a packed CBOR data item depicted 591 in Figure 3, ~309 bytes. Note that this particular example does not 592 lend itself to prefix compression. 594 { "store": { 595 "book": [ 596 { "category": "reference", 597 "author": "Nigel Rees", 598 "title": "Sayings of the Century", 599 "price": 8.95 600 }, 601 { "category": "fiction", 602 "author": "Evelyn Waugh", 603 "title": "Sword of Honour", 604 "price": 12.99 605 }, 606 { "category": "fiction", 607 "author": "Herman Melville", 608 "title": "Moby Dick", 609 "isbn": "0-553-21311-3", 610 "price": 8.99 611 }, 612 { "category": "fiction", 613 "author": "J. R. R. Tolkien", 614 "title": "The Lord of the Rings", 615 "isbn": "0-395-19395-8", 616 "price": 22.99 617 } 618 ], 619 "bicycle": { 620 "color": "red", 621 "price": 19.95 622 } 623 } 624 } 626 Figure 2: Example original CBOR data item 628 51(["price", "category", "author", "title", "fiction", 8.95, "isbn"], 629 / 0 1 2 3 4 5 6 / 630 [], [], 631 [{"store": { 632 "book": [ 633 {simple(1): "reference", simple(2): "Nigel Rees", 634 simple(3): "Sayings of the Century", simple(0): simple(5)}, 635 {simple(1): simple(4), simple(2): "Evelyn Waugh", 636 simple(3): "Sword of Honour", simple(0): 12.99}, 637 {simple(1): simple(4), simple(2): "Herman Melville", 638 simple(3): "Moby Dick", simple(6): "0-553-21311-3", 639 simple(0): simple(5)}, 640 {simple(1): simple(4), simple(2): "J. R. R. Tolkien", 641 simple(3): "The Lord of the Rings", 642 simple(6): "0-395-19395-8", simple(0): 22.99}], 643 "bicycle": {"color": "red", simple(0): 19.95}}}]) 645 Figure 3: Example packed CBOR data item 647 The (JSON-compatible) CBOR data structure below has been packed with 648 shared item and (partial) prefix compression only. 650 { 651 "name": "MyLED", 652 "interactions": [ 653 { 654 "links": [ 655 { 656 "href": 657 "http://192.168.1.103:8445/wot/thing/MyLED/rgbValueRed", 658 "mediaType": "application/json" 659 } 660 ], 661 "outputData": { 662 "valueType": { 663 "type": "number" 664 } 665 }, 666 "name": "rgbValueRed", 667 "writable": true, 668 "@type": [ 669 "Property" 670 ] 671 }, 672 { 673 "links": [ 674 { 675 "href": 677 "http://192.168.1.103:8445/wot/thing/MyLED/rgbValueGreen", 678 "mediaType": "application/json" 679 } 680 ], 681 "outputData": { 682 "valueType": { 683 "type": "number" 684 } 685 }, 686 "name": "rgbValueGreen", 687 "writable": true, 688 "@type": [ 689 "Property" 690 ] 691 }, 692 { 693 "links": [ 694 { 695 "href": 696 "http://192.168.1.103:8445/wot/thing/MyLED/rgbValueBlue", 697 "mediaType": "application/json" 698 } 699 ], 700 "outputData": { 701 "valueType": { 702 "type": "number" 703 } 704 }, 705 "name": "rgbValueBlue", 706 "writable": true, 707 "@type": [ 708 "Property" 709 ] 710 }, 711 { 712 "links": [ 713 { 714 "href": 715 "http://192.168.1.103:8445/wot/thing/MyLED/rgbValueWhite", 716 "mediaType": "application/json" 717 } 718 ], 719 "outputData": { 720 "valueType": { 721 "type": "number" 722 } 723 }, 724 "name": "rgbValueWhite", 725 "writable": true, 726 "@type": [ 727 "Property" 728 ] 729 }, 730 { 731 "links": [ 732 { 733 "href": 734 "http://192.168.1.103:8445/wot/thing/MyLED/ledOnOff", 735 "mediaType": "application/json" 736 } 737 ], 738 "outputData": { 739 "valueType": { 740 "type": "boolean" 741 } 742 }, 743 "name": "ledOnOff", 744 "writable": true, 745 "@type": [ 746 "Property" 747 ] 748 }, 749 { 750 "links": [ 751 { 752 "href": 753 "http://192.168.1.103:8445/wot/thing/MyLED/colorTemperatureChanged", 754 "mediaType": "application/json" 755 } 756 ], 757 "outputData": { 758 "valueType": { 759 "type": "number" 760 } 761 }, 762 "name": "colorTemperatureChanged", 763 "@type": [ 764 "Event" 765 ] 766 } 767 ], 768 "@type": "Lamp", 769 "id": "0", 770 "base": "http://192.168.1.103:8445/wot/thing", 771 "@context": 772 "http://192.168.1.102:8444/wot/w3c-wot-td-context.jsonld" 774 } 776 Figure 4: Example original CBOR data item 778 51([/shared/["name", "@type", "links", "href", "mediaType", 779 / 0 1 2 3 4 / 780 "application/json", "outputData", {"valueType": {"type": 781 / 5 6 7 / 782 "number"}}, ["Property"], "writable", "valueType", "type"], 783 / 8 9 10 11 / 784 /prefix/ ["http://192.168.1.10", 6("3:8445/wot/thing"), 785 / 6 225 / 786 225("/MyLED/"), 226("rgbValue"), "rgbValue", 787 / 226 227 228 / 788 {simple(6): simple(7), simple(9): true, simple(1): simple(8)}], 789 / 229 / 790 /suffix/ [], 791 /rump/ {simple(0): "MyLED", 792 "interactions": [ 793 229({simple(2): [{simple(3): 227("Red"), simple(4): simple(5)}], 794 simple(0): 228("Red")}), 795 229({simple(2): [{simple(3): 227("Green"), simple(4): simple(5)}], 796 simple(0): 228("Green")}), 797 229({simple(2): [{simple(3): 227("Blue"), simple(4): simple(5)}], 798 simple(0): 228("Blue")}), 799 229({simple(2): [{simple(3): 227("White"), simple(4): simple(5)}], 800 simple(0): "rgbValueWhite"}), 801 {simple(2): [{simple(3): 226("ledOnOff"), simple(4): simple(5)}], 802 simple(6): {simple(10): {simple(11): "boolean"}}, simple(0): 803 "ledOnOff", simple(9): true, simple(1): simple(8)}, 804 {simple(2): [{simple(3): 226("colorTemperatureChanged"), 805 simple(4): simple(5)}], simple(6): simple(7), simple(0): 806 "colorTemperatureChanged", simple(1): ["Event"]}], 807 simple(1): "Lamp", "id": "0", "base": 225(""), 808 "@context": 6("2:8444/wot/w3c-wot-td-context.jsonld")}]) 810 Figure 5: Example packed CBOR data item 812 Acknowledgements 814 CBOR packing was originally invented with the rest of CBOR, but did 815 not make it into [RFC7049], the predecessor of [STD94]. Various 816 attempts to come up with a specification over the years didn't 817 proceed. In 2017, Sebastian Käbisch proposed investigating compact 818 representations of W3C Thing Descriptions, which prompted the author 819 to come up with essentially the present design. 821 Author's Address 823 Carsten Bormann 824 Universität Bremen TZI 825 Postfach 330440 826 D-28359 Bremen 827 Germany 828 Phone: +49-421-218-63921 829 Email: cabo@tzi.org