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