idnits 2.17.1 draft-ietf-cbor-packed-03.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 (13 August 2021) is 986 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 13 August 2021 5 Expires: 14 February 2022 7 Packed CBOR 8 draft-ietf-cbor-packed-03 10 Abstract 12 The Concise Binary Object Representation (CBOR, RFC 8949) is a data 13 format whose design goals include the possibility of extremely small 14 code size, fairly small message size, and extensibility without the 15 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 unpack the compressed form 23 to make use of 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 14 February 2022. 57 Copyright Notice 59 Copyright (c) 2021 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 Simplified BSD License text 68 as described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . 4 78 2.3. Referencing Affix Items . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 86 6.2. Informative References . . . . . . . . . . . . . . . . . 12 87 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 88 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 (TO DO, expand on text from abstract here; move references here and 94 neuter them in the abstract as per Section 4.3 of [RFC7322].) 95 The specification defines a transformation from a Packed CBOR data 96 item to the original CBOR data item; it does not define an algorithm 97 for an actual packer. Different packers can differ in the amount of 98 effort they invest in arriving at a minimal packed form. 100 Packed CBOR can employ two kinds of optimization: 102 * item sharing: substructures (data items) that occur repeatedly in 103 the original CBOR data item can be collapsed to a simple reference 104 to a common representation of that data item. The processing 105 required during consumption is limited to following that 106 reference. 108 * affix sharing: data items (strings, containers) that share a 109 prefix or suffix (affix) can be replaced by a reference to a 110 common affix plus the rest of the data item. For strings, the 111 processing required during consumption is similar to following the 112 affix reference plus that for an indefinite-length string. 114 A specific application protocol that employs Packed CBOR might allow 115 both kinds of optimization or limit the representation to item 116 sharing only. 118 Packed CBOR is defined in two parts: Referencing packing tables 119 (Section 2) and setting up packing tables (Section 3). 121 1.1. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 Packed reference: A shared item reference or an affix reference 131 Shared item reference: A reference to a shared item as defined in 132 Section 2.2 134 Affix reference: A reference that combines an affix item as defined 135 in Section 2.3. 137 Affix: Prefix or suffix. 139 Packing tables: The triple of a shared item table, a prefix table, 140 and a suffix table. 142 Expansion: The result of applying a packed reference in the context 143 of given Packing tables. 145 The definitions of [RFC8949] apply. The term "byte" is used in its 146 now customary sense as a synonym for "octet". Where bit arithmetic 147 is explained, this document uses the notation familiar from the 148 programming language C (including C++14's 0bnnn binary literals), 149 except that, in the plain text form of this document, the operator 150 "^" stands for exponentiation, and, in the HTML and PDF versions, 151 subtraction and negation are rendered as a hyphen ("-", as are 152 various dashes). 154 2. Packed CBOR 156 This section describes the packing tables, their structure, and how 157 they are referenced. 159 2.1. Packing Tables 161 At any point within a data item making use of Packed CBOR, there is a 162 Current Set of packing tables that applies. 164 There are three packing tables in a Current Set: 166 * Shared item table 168 * Prefix table 170 * Suffix table 172 Without any table setup, all these tables are empty arrays. 173 Table setup can cause these arrays to be non-empty, where the 174 elements are (potentially themselves packed) data items. Each of the 175 tables is indexed by an unsigned integer (starting from 0), which may 176 be computed from information in tags and their content as well as 177 from CBOR simple values. 179 2.2. Referencing Shared Items 181 Shared items are stored in the shared item table of the Current Set. 183 The shared data items are referenced by using the reference data 184 items in Table 1. When reconstructing the original data item, such a 185 reference is replaced by the referenced data item, which is then 186 recursively unpacked. 188 +===========================+==============+ 189 | reference | table index | 190 +===========================+==============+ 191 | Simple value 0-15 | 0-15 | 192 +---------------------------+--------------+ 193 | Tag 6(unsigned integer N) | 16 + 2*N | 194 +---------------------------+--------------+ 195 | Tag 6(negative integer N) | 16 - 2*N - 1 | 196 +---------------------------+--------------+ 198 Table 1: Referencing Shared Values 200 As examples in CBOR diagnostic notation (Section 8 of [RFC8949]), the 201 first 22 elements of the shared item table are referenced by 202 "simple(0)", "simple(1)", ... "simple(15)", "6(0)", "6(-1)", "6(1)", 203 "6(-2)", "6(2)", "6(-3)". (The alternation between unsigned and 204 negative integers for even/odd table index values makes systematic 205 use of shorter integer encodings first.) 207 Taking into account the encoding of these referring data items, there 208 are 16 one-byte references, 48 two-byte references, 512 three-byte 209 references, 131072 four-byte references, etc. As integers can grow 210 to very large (or negative) values, there is no practical limit to 211 how many shared items might be used in a Packed CBOR item. 213 Note that the semantics of Tag 6 depend on its content: An integer 214 turns the tag into a shared item reference, a string or container 215 (map or array) into a prefix reference (see Table 2). 217 2.3. Referencing Affix Items 219 Prefix items are stored in the prefix table of the Current Set; 220 suffix items are stored in the suffix table of the Current Set. We 221 collectively call these items affix items; when referencing, which of 222 the tables is actually used depends on whether a prefix or a suffix 223 reference was used. 225 +===================================+================+ 226 | prefix reference | table index | 227 +===================================+================+ 228 | Tag 6(suffix) | 0 | 229 +-----------------------------------+----------------+ 230 | Tag 225-255(suffix) | 1-31 | 231 +-----------------------------------+----------------+ 232 | Tag 28704-32767(suffix) | 32-4095 | 233 +-----------------------------------+----------------+ 234 | Tag 1879052288-2147483647(suffix) | 4096-268435455 | 235 +-----------------------------------+----------------+ 237 Table 2: Referencing Prefix Values 239 +===================================+===============+ 240 | suffix reference | table index | 241 +===================================+===============+ 242 | Tag 216-223(prefix) | 0-7 | 243 +-----------------------------------+---------------+ 244 | Tag 27647-28671(prefix) | 8-1023 | 245 +-----------------------------------+---------------+ 246 | Tag 1811940352-1879048191(prefix) | 1024-67108863 | 247 +-----------------------------------+---------------+ 249 Table 3: Referencing Suffix Values 251 Affix data items are referenced by using the data items in Table 2 252 and Table 3. Each of these implies the table used (prefix or 253 suffix), a table index (an unsigned integer) and contains a "rump 254 item". When reconstructing the original data item, such a reference 255 is replaced by a data item constructed from the referenced affix data 256 item (affix, which might need to be recursively unpacked first) 257 "concatenated" with the tag content (rump, again possibly recursively 258 unpacked). 260 * For a rump of type array and map, the affix also needs to be an 261 array or a map. For an array, the elements from the prefix are 262 prepended, and the elements from a suffix are appended to the rump 263 array. For a map, the entries in the affix are added to those of 264 the rump; prefix and suffix references differ in how entries with 265 identical keys are combined: for prefix references, an entry in 266 the rump with the same key as an entry in the affix overrides the 267 one in the affix, while for suffix references, an entry in the 268 affix overrides an entry in the rump that has the same key. 270 | ISSUE: Not sure that we want to use the efficiencies of 271 | overriding, but having default values supplied out of a 272 | dictionary to be overridden by a rump sounds rather handy. 273 | Note that there is no way to remove a map entry from the table. 275 * For a rump of one of the string types, the affix also needs to be 276 one of the string types; the bytes of the strings are concatenated 277 as specified (prefix + rump, rump + suffix). The result of the 278 concatenation gets the type of the rump; this way a single affix 279 can be used to build both byte and text strings, depending on what 280 type of rump is being used. 282 As a contrived (but short) example, if the prefix table is 283 "["foobar", "foob", "fo"]", the following prefix references will all 284 unpack to ""foobart"": "6("t")", "224("art")", "225("obart")" (the 285 last example is not an optimization). 287 Taking into account the encoding, there is one single-byte prefix 288 reference, 31 (2^5-2^0) two-byte references, 4064 (2^12-2^5) three- 289 byte references, and 26843160 (2^28-2^12) five-byte references for 290 prefixes. 268435455 (2^28) is an artificial limit, but should be high 291 enough that there, again, is no practical limit to how many prefix 292 items might be used in a Packed CBOR item. The numbers for suffix 293 references are one quarter of those, except that there is no single- 294 byte reference and 8 two-byte references. 296 | Rationale: Experience suggests that prefix packing might be 297 | more likely than suffix packing. Also for this reason, there 298 | is no intent to spend a 1+0 tag value for suffix matching. 300 2.4. Discussion 302 This specification uses up a large number of Simple Values and Tags, 303 in particular one of the rare one-byte tags and half of the one-byte 304 simple values. Since the objective is compression, this is warranted 305 if and only if there is consensus that this specific format could be 306 useful for a wide area of applications, while maintaining reasonable 307 simplicity in particular at the side of the consumer. 309 A maliciously crafted Packed CBOR data item might contain a reference 310 loop. A consumer/decompressor MUST protect against that. 312 | Different strategies for decoding/consuming Packed CBOR are 313 | available. 314 | For example: 315 | 316 | * the decoder can decode and unpack the packed item, 317 | presenting an unpacked data item to the application. In 318 | this case, the onus of dealing with loops is on the 319 | decoder. (This strategy generally has the highest memory 320 | consumption, but also the simplest interface to the 321 | application.) Besides avoiding getting stuck in a 322 | reference loop, the decoder will need to control its 323 | resource allocation, as data items can "blow up" during 324 | unpacking. 325 | 326 | * the decoder can be oblivious of Packed CBOR. In this 327 | case, the onus of dealing with loops is on the 328 | application, as is the entire onus of dealing with Packed 329 | CBOR. 330 | 331 | * hybrid models are possible, for instance: The decoder 332 | builds a data item tree directly from the Packed CBOR as 333 | if it were oblivious, but also provides accessors that 334 | hide (resolve) the packing. In this specific case, the 335 | onus of dealing with loops is on the accessors. 336 | 337 | In general, loop detection can be handled in a similar way in 338 | which loops of symbolic links are handled in a file system: A 339 | system wide limit (often 31 or 40 indirections for symbolic 340 | links) is applied to any reference chase. 342 | ISSUE: The present specification does nothing to help with the 343 | packing of CBOR sequences [RFC8742]; maybe it should. 345 3. Table Setup 347 The packing references described in Section 2 assume that packing 348 tables have been set up. 350 By default, all three tables are empty (zero-length arrays). 352 Table setup can happen in one of two ways: 354 * By the application environment, e.g., a media type. These can 355 define tables that amount to a static dictionary that can be used 356 in a CBOR data item for this application environment. Note that, 357 without this information, a data item that uses such a static 358 dictionary can be decoded at the CBOR level, but not fully 359 unpacked. The table setup mechanisms provided by this document 360 are defined in such a way that an unpacker can at least recognize 361 if this is the case. 363 * By one or more tags enclosing the packed content. These can be 364 defined to add to the packing tables that already apply to the 365 tag. Usually, the semantics of the tag will be to prepend items 366 to one of the tables. Note that it may be useful to leave a 367 particular efficiency tier alone and only prepend to a higher 368 tier; e.g., a tag could insert shared items at table index 16 and 369 shift anything that was already there further down in the array 370 while leaving index 0 to 15 alone. Explicit additions by tag can 371 combine with application-environment supplied tables that apply to 372 the entire CBOR data item. 374 For table setup, the present specification only defines a single tag, 375 which operates by prepending to the (by default empty) tables. 377 | We could also define a tag for dictionary referencing (or 378 | include that in the basic packed CBOR), but the desirable 379 | details are likely to vary considerably between applications. 380 | A URI-based reference would be easy to add, but might be too 381 | inefficient when used in the likely combination with an "ni:" 382 | URI [RFC6920]. 384 3.1. Basic Packed CBOR 386 A predefined tag for packing table setup is defined in CDDL [RFC8610] 387 as in Figure 1: 389 Basic-Packed-CBOR = #6.51([[*shared-item], [*prefix-item], 390 [*suffix-item], rump]) 391 rump = any 392 prefix-item = any 393 suffix-item = any 394 shared-item = any 396 Figure 1: Packed CBOR in CDDL 398 (This assumes the allocation of tag number 51 for this tag.) 400 The arrays given as the first, second, and third element of the 401 content of the tag 51 are prepended to the tables for shared items, 402 prefixes, and suffixes that apply to the entire tag (by default empty 403 tables). 405 The original CBOR data item can be reconstructed by recursively 406 replacing shared, prefix, and suffix references encountered in the 407 rump by their expansions. 409 Packed item references in the newly constructed (low-numbered) parts 410 of the table need to be interpreted in the number space of that table 411 (which includes the, now higher-numbered inherited parts), while 412 references in any existing, inherited (higher-numbered) part continue 413 to use the (more limited) number space of the inherited table. 415 4. IANA Considerations 417 In the registry "CBOR Tags" [IANA.cbor-tags], IANA is requested to 418 allocate the tags defined in Table 4. 420 +=======================+========+=========+========================+ 421 | Tag |Data |Semantics| Reference | 422 | |Item | | | 423 +=======================+========+=========+========================+ 424 | 6 |integer |Packed | draft-ietf-cbor-packed | 425 | |(for |CBOR: | | 426 | |shared);|shared/ | | 427 | |text |prefix | | 428 | |string, | | | 429 | |byte | | | 430 | |string, | | | 431 | |array, | | | 432 | |map (for| | | 433 | |prefix) | | | 434 +-----------------------+--------+---------+------------------------+ 435 | 225-255 |text |Packed | draft-ietf-cbor-packed | 436 | |string, |CBOR: | | 437 | |byte |prefix | | 438 | |string, | | | 439 | |array, | | | 440 | |map | | | 441 +-----------------------+--------+---------+------------------------+ 442 | 28704-32767 |text |Packed | draft-ietf-cbor-packed | 443 | |string, |CBOR: | | 444 | |byte |prefix | | 445 | |string, | | | 446 | |array, | | | 447 | |map | | | 448 +-----------------------+--------+---------+------------------------+ 449 | 1879052288-2147483647 |text |Packed | draft-ietf-cbor-packed | 450 | |string, |CBOR: | | 451 | |byte |prefix | | 452 | |string, | | | 453 | |array, | | | 454 | |map | | | 455 +-----------------------+--------+---------+------------------------+ 456 | 216-223 |text |Packed | draft-ietf-cbor-packed | 457 | |string, |CBOR: | | 458 | |byte |suffix | | 459 | |string, | | | 460 | |array, | | | 461 | |map | | | 462 +-----------------------+--------+---------+------------------------+ 463 | 27647-28671 |text |Packed | draft-ietf-cbor-packed | 464 | |string, |CBOR: | | 465 | |byte |suffix | | 466 | |string, | | | 467 | |array, | | | 468 | |map | | | 469 +-----------------------+--------+---------+------------------------+ 470 | 1811940352-1879048191 |text |Packed | draft-ietf-cbor-packed | 471 | |string, |CBOR: | | 472 | |byte |suffix | | 473 | |string, | | | 474 | |array, | | | 475 | |map | | | 476 +-----------------------+--------+---------+------------------------+ 478 Table 4: Values for Tag Numbers 480 In the registry "CBOR Simple Values" [IANA.cbor-simple-values], IANA 481 is requested to allocate the simple values defined in Table 5. 483 +=======+=====================+========================+ 484 | Value | Semantics | Reference | 485 +=======+=====================+========================+ 486 | 0-15 | Packed CBOR: shared | draft-ietf-cbor-packed | 487 +-------+---------------------+------------------------+ 489 Table 5: Simple Values 491 5. Security Considerations 493 The security considerations of [RFC8949] apply. 495 Loops in the Packed CBOR can be used as a denial of service attack, 496 see Section 2.4. 498 As the unpacking is deterministic, packed forms can be used as 499 signing inputs. (Note that if external dictionaries are added to 500 cbor-packed, this requires additional consideration.) 502 6. References 504 6.1. Normative References 506 [IANA.cbor-simple-values] 507 IANA, "Concise Binary Object Representation (CBOR) Simple 508 Values", 509 . 511 [IANA.cbor-tags] 512 IANA, "Concise Binary Object Representation (CBOR) Tags", 513 . 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, 517 DOI 10.17487/RFC2119, March 1997, 518 . 520 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 521 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 522 May 2017, . 524 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 525 Definition Language (CDDL): A Notational Convention to 526 Express Concise Binary Object Representation (CBOR) and 527 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 528 June 2019, . 530 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 531 Representation (CBOR)", STD 94, RFC 8949, 532 DOI 10.17487/RFC8949, December 2020, 533 . 535 6.2. Informative References 537 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 538 Keranen, A., and P. Hallam-Baker, "Naming Things with 539 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 540 . 542 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 543 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 544 October 2013, . 546 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 547 DOI 10.17487/RFC7322, September 2014, 548 . 550 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 551 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 552 . 554 Appendix A. Examples 556 The (JSON-compatible) CBOR data structure depicted in Figure 2, 400 557 bytes of binary CBOR, could lead to a packed CBOR data item depicted 558 in Figure 3, ~309 bytes. Note that this particular example does not 559 lend itself to prefix compression. 561 { "store": { 562 "book": [ 563 { "category": "reference", 564 "author": "Nigel Rees", 565 "title": "Sayings of the Century", 566 "price": 8.95 567 }, 568 { "category": "fiction", 569 "author": "Evelyn Waugh", 570 "title": "Sword of Honour", 571 "price": 12.99 572 }, 573 { "category": "fiction", 574 "author": "Herman Melville", 575 "title": "Moby Dick", 576 "isbn": "0-553-21311-3", 577 "price": 8.99 578 }, 579 { "category": "fiction", 580 "author": "J. R. R. Tolkien", 581 "title": "The Lord of the Rings", 582 "isbn": "0-395-19395-8", 583 "price": 22.99 584 } 585 ], 586 "bicycle": { 587 "color": "red", 588 "price": 19.95 589 } 590 } 591 } 593 Figure 2: Example original CBOR data item 595 51(["price", "category", "author", "title", "fiction", 8.95, "isbn"], 596 / 0 1 2 3 4 5 6 / 597 [], [], 598 [{"store": { 599 "book": [ 600 {simple(1): "reference", simple(2): "Nigel Rees", 601 simple(3): "Sayings of the Century", simple(0): simple(5)}, 602 {simple(1): simple(4), simple(2): "Evelyn Waugh", 603 simple(3): "Sword of Honour", simple(0): 12.99}, 604 {simple(1): simple(4), simple(2): "Herman Melville", 605 simple(3): "Moby Dick", simple(6): "0-553-21311-3", 606 simple(0): simple(5)}, 607 {simple(1): simple(4), simple(2): "J. R. R. Tolkien", 608 simple(3): "The Lord of the Rings", 609 simple(6): "0-395-19395-8", simple(0): 22.99}], 610 "bicycle": {"color": "red", simple(0): 19.95}}}]) 612 Figure 3: Example packed CBOR data item 614 The (JSON-compatible) CBOR data structure below has been packed with 615 shared item and (partial) prefix compression only. 617 { 618 "name": "MyLED", 619 "interactions": [ 620 { 621 "links": [ 622 { 623 "href": 624 "http://192.168.1.103:8445/wot/thing/MyLED/rgbValueRed", 625 "mediaType": "application/json" 626 } 627 ], 628 "outputData": { 629 "valueType": { 630 "type": "number" 631 } 632 }, 633 "name": "rgbValueRed", 634 "writable": true, 635 "@type": [ 636 "Property" 637 ] 638 }, 639 { 640 "links": [ 641 { 642 "href": 644 "http://192.168.1.103:8445/wot/thing/MyLED/rgbValueGreen", 645 "mediaType": "application/json" 646 } 647 ], 648 "outputData": { 649 "valueType": { 650 "type": "number" 651 } 652 }, 653 "name": "rgbValueGreen", 654 "writable": true, 655 "@type": [ 656 "Property" 657 ] 658 }, 659 { 660 "links": [ 661 { 662 "href": 663 "http://192.168.1.103:8445/wot/thing/MyLED/rgbValueBlue", 664 "mediaType": "application/json" 665 } 666 ], 667 "outputData": { 668 "valueType": { 669 "type": "number" 670 } 671 }, 672 "name": "rgbValueBlue", 673 "writable": true, 674 "@type": [ 675 "Property" 676 ] 677 }, 678 { 679 "links": [ 680 { 681 "href": 682 "http://192.168.1.103:8445/wot/thing/MyLED/rgbValueWhite", 683 "mediaType": "application/json" 684 } 685 ], 686 "outputData": { 687 "valueType": { 688 "type": "number" 689 } 690 }, 691 "name": "rgbValueWhite", 692 "writable": true, 693 "@type": [ 694 "Property" 695 ] 696 }, 697 { 698 "links": [ 699 { 700 "href": 701 "http://192.168.1.103:8445/wot/thing/MyLED/ledOnOff", 702 "mediaType": "application/json" 703 } 704 ], 705 "outputData": { 706 "valueType": { 707 "type": "boolean" 708 } 709 }, 710 "name": "ledOnOff", 711 "writable": true, 712 "@type": [ 713 "Property" 714 ] 715 }, 716 { 717 "links": [ 718 { 719 "href": 720 "http://192.168.1.103:8445/wot/thing/MyLED/colorTemperatureChanged", 721 "mediaType": "application/json" 722 } 723 ], 724 "outputData": { 725 "valueType": { 726 "type": "number" 727 } 728 }, 729 "name": "colorTemperatureChanged", 730 "@type": [ 731 "Event" 732 ] 733 } 734 ], 735 "@type": "Lamp", 736 "id": "0", 737 "base": "http://192.168.1.103:8445/wot/thing", 738 "@context": 739 "http://192.168.1.102:8444/wot/w3c-wot-td-context.jsonld" 741 } 743 Figure 4: Example original CBOR data item 745 51([/shared/["name", "@type", "links", "href", "mediaType", 746 / 0 1 2 3 4 / 747 "application/json", "outputData", {"valueType": {"type": 748 / 5 6 7 / 749 "number"}}, ["Property"], "writable", "valueType", "type"], 750 / 8 9 10 11 / 751 /prefix/ ["http://192.168.1.10", 6("3:8445/wot/thing"), 752 / 6 225 / 753 225("/MyLED/"), 226("rgbValue"), "rgbValue", 754 / 226 227 228 / 755 {simple(6): simple(7), simple(9): true, simple(1): simple(8)}], 756 / 229 / 757 /suffix/ [], 758 /rump/ {simple(0): "MyLED", 759 "interactions": [ 760 229({simple(2): [{simple(3): 227("Red"), simple(4): simple(5)}], 761 simple(0): 228("Red")}), 762 229({simple(2): [{simple(3): 227("Green"), simple(4): simple(5)}], 763 simple(0): 228("Green")}), 764 229({simple(2): [{simple(3): 227("Blue"), simple(4): simple(5)}], 765 simple(0): 228("Blue")}), 766 229({simple(2): [{simple(3): 227("White"), simple(4): simple(5)}], 767 simple(0): "rgbValueWhite"}), 768 {simple(2): [{simple(3): 226("ledOnOff"), simple(4): simple(5)}], 769 simple(6): {simple(10): {simple(11): "boolean"}}, simple(0): 770 "ledOnOff", simple(9): true, simple(1): simple(8)}, 771 {simple(2): [{simple(3): 226("colorTemperatureChanged"), 772 simple(4): simple(5)}], simple(6): simple(7), simple(0): 773 "colorTemperatureChanged", simple(1): ["Event"]}], 774 simple(1): "Lamp", "id": "0", "base": 225(""), 775 "@context": 6("2:8444/wot/w3c-wot-td-context.jsonld")}]) 777 Figure 5: Example packed CBOR data item 779 Acknowledgements 781 CBOR packing was originally invented with the rest of CBOR, but did 782 not make it into [RFC7049], the predecessor of [RFC8949]. Various 783 attempts to come up with a specification over the years didn't 784 proceed. In 2017, Sebastian Käbisch proposed investigating compact 785 representations of W3C Thing Descriptions, which prompted the author 786 to come up with essentially the present design. 788 Author's Address 790 Carsten Bormann 791 Universität Bremen TZI 792 Postfach 330440 793 D-28359 Bremen 794 Germany 796 Phone: +49-421-218-63921 797 Email: cabo@tzi.org