idnits 2.17.00 (12 Aug 2021) /tmp/idnits64450/draft-bormann-cbor-cddl-map-like-data-01.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 2 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (1 June 2021) is 347 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCthis' is mentioned on line 452, but not defined -- Looks like a reference, but probably isn't: '136' on line 594 -- Looks like a reference, but probably isn't: '139' on line 596 -- Looks like a reference, but probably isn't: '132' on line 596 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann, Ed. 3 Internet-Draft Universität Bremen TZI 4 Intended status: Informational B. Moran 5 Expires: 3 December 2021 Arm Limited 6 H. Birkholz 7 Fraunhofer SIT 8 E. Cormier 9 1 June 2021 11 Map-like data in CBOR and CDDL 12 draft-bormann-cbor-cddl-map-like-data-01 14 Abstract 16 The Concise Binary Object Representation (CBOR, RFC 8949) is a data 17 format whose design goals include the possibility of extremely small 18 code size, fairly small message size, and extensibility without the 19 need for version negotiation. 21 Basic CBOR supports non-ordered maps free of duplicate keys, similar 22 to the way JSON defines JSON objects (RFC 8259). Using the CBOR 23 extension point of tags, tags for a selection of variants of maps and 24 multimaps have been registered, but gaps remain. The present 25 document defines a consolidated set of CBOR tags for map-like data 26 items involving key-value pairs. 28 The Concise Data Definition Language (CDDL), standardized in RFC 29 8610, is often used to express CBOR data structure specifications. 30 It provides "control operators" as its main language extension point. 31 The present document defines a number of control operators that 32 enable the description of CBOR data structures that make use of the 33 newly defined tags or that employ the same underlying structures. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 3 December 2021. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Simplified BSD License text 62 as described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. CBOR tags for map-like data items . . . . . . . . . . . . . . 3 70 2.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.2. Key/Value Type . . . . . . . . . . . . . . . . . . . . . 5 72 2.3. Ordering . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2.4. Key Uniqueness . . . . . . . . . . . . . . . . . . . . . 5 74 2.5. Data Item . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2.6. Related Tags (Informative) . . . . . . . . . . . . . . . 6 76 2.6.1. Tag 259 . . . . . . . . . . . . . . . . . . . . . . . 6 77 2.6.2. Tag 275 . . . . . . . . . . . . . . . . . . . . . . . 6 78 2.6.3. Tag TBD279 . . . . . . . . . . . . . . . . . . . . . 6 79 2.6.4. Tag TDB280 . . . . . . . . . . . . . . . . . . . . . 7 80 3. CDDL Support for Map-Like Data Items . . . . . . . . . . . . 7 81 3.1. Map notation for map-like data items . . . . . . . . . . 7 82 3.2. Uniqueness . . . . . . . . . . . . . . . . . . . . . . . 8 83 4. CDDL typenames . . . . . . . . . . . . . . . . . . . . . . . 9 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 5.1. Tags . . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 5.2. CDDL control operators . . . . . . . . . . . . . . . . . 10 87 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 88 7. Security considerations . . . . . . . . . . . . . . . . . . . 10 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 91 8.2. Informative References . . . . . . . . . . . . . . . . . 11 92 Appendix A. Implementation Considerations . . . . . . . . . . . 11 93 A.1. Programming Language Containers (Informative) . . . . . . 11 94 A.1.1. ECMAScript . . . . . . . . . . . . . . . . . . . . . 12 95 A.1.2. Python . . . . . . . . . . . . . . . . . . . . . . . 12 96 A.1.3. C++ . . . . . . . . . . . . . . . . . . . . . . . . . 13 98 A.2. CDDL Implementation Considerations . . . . . . . . . . . 14 99 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 100 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 103 1. Introduction 105 (See abstract for now.) 107 1.1. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in 112 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 This specification uses terminology from [RFC8949] and [RFC8610]. In 116 particular, with respect to CDDL control operators, "target" refers 117 to the left hand side operand, and "controller" to the right hand 118 side operand. The terms "array" and "map" (if unadorned) refer to 119 CBOR major type 4 and CBOR major type 5; this is not called out 120 explicitly. 122 2. CBOR tags for map-like data items 124 This document defines a consolidated set of CBOR tags for map-like 125 entities involving key-value pairs. These tags encode the following 126 meta-data concerning map-like data items: 128 * the homogeneity of the types of the keys, and of the types of the 129 values; 131 * whether the order of the key-value pairs carries semantic value 132 ("ordered") or needs to be ignored ("non-ordered"); 134 * the uniqueness of the keys; and 136 * the major type used to encode the key-value pairs. 138 Note that the term "ordered" as used in this document is distinct 139 from "sorted" -- "ordered" implies that the order in the data item 140 interchanged conveys a semantically relevant ordering, while a 141 property "sorted" can easily be established after interchange (by, 142 simply, sorting), less often needs to be indicated, and is more 143 complex to indicate as it may need details about the sorting. 145 2.1. Summary 147 +===+====+===========+=============+========+=========+=====+=======+ 148 |Tag|LSBs|Homogeneous| Homogeneous |Ordering|Duplicate|Data |Related| 149 | | |Value | Key | |Keys |Item |Tag | 150 | | | | | |Allowed | | | 151 +===+====+===========+=============+========+=========+=====+=======+ 152 |128|0000|No | No |Non- |No |map |259 | 153 | | | | |Ordered | | | | 154 +---+----+-----------+-------------+--------+---------+-----+-------+ 155 |129|0001|No | No |Non- |Yes |array|TDB280*| 156 | | | | |Ordered | | | | 157 +---+----+-----------+-------------+--------+---------+-----+-------+ 158 |130|0010|No | No |Ordered |No |array|TBD279*| 159 +---+----+-----------+-------------+--------+---------+-----+-------+ 160 |131|0011|No | No |Ordered |Yes |array| | 161 +---+----+-----------+-------------+--------+---------+-----+-------+ 162 |132|0100|No | Yes |Non- |No |map |275 | 163 | | | | |Ordered | | | | 164 +---+----+-----------+-------------+--------+---------+-----+-------+ 165 |133|0101|No | Yes |Non- |Yes |array| | 166 | | | | |Ordered | | | | 167 +---+----+-----------+-------------+--------+---------+-----+-------+ 168 |134|0110|No | Yes |Ordered |No |array| | 169 +---+----+-----------+-------------+--------+---------+-----+-------+ 170 |135|0111|No | Yes |Ordered |Yes |array| | 171 +---+----+-----------+-------------+--------+---------+-----+-------+ 172 |136|1000|Yes | Yes |Non- |No |map | | 173 | | | | |Ordered | | | | 174 +---+----+-----------+-------------+--------+---------+-----+-------+ 175 |137|1001|Yes | Yes |Non- |Yes |array| | 176 | | | | |Ordered | | | | 177 +---+----+-----------+-------------+--------+---------+-----+-------+ 178 |138|1010|Yes | Yes |Ordered |No |array| | 179 +---+----+-----------+-------------+--------+---------+-----+-------+ 180 |139|1011|Yes | Yes |Ordered |Yes |array| | 181 +---+----+-----------+-------------+--------+---------+-----+-------+ 183 Table 1: New CBOR tags defined in this document 185 *TBD279: https://github.com/Sekenre/cbor-ordered-map- 186 spec/blob/master/CBOR_Ordered_Map.md 188 *TBD280: https://github.com/ecorm/cbor-tag-multimap 190 [The intention of the present document is to obviate the need for 191 defining TBD279/TBD280.] 192 Appendix A.1 provides information about constructs in a few 193 programming languages that are related to the tags being defined. 195 2.2. Key/Value Type 197 Bits 2 and 3 of the tag provide information on the map's key and 198 value types: 200 * 0b00xx Unspecified: There is no specified type for the map's keys 201 and values 203 * 0b01xx Homogeneous Key: All keys have the same data type 205 * 0b10xx Homogeneous Key/Value: All values have the same data type 206 in addition to all keys having the same data type (the types for 207 keys and values may be distinct). 209 The semantics for homogeneity shall be the same as for [RFC8746] 210 homogeneous arrays (tag 41). That is, "which CBOR data items 211 constitute elements of the same application type is specific to the 212 application" (Section 3.2 of [RFC8746]). 214 Maps with arbitrary keys and homogeneous values are considered 215 unusual, so they are left out of this specification so that fewer tag 216 numbers need to be allocated (12 instead of 16). 218 2.3. Ordering 220 Bit 1 of the tag represents the map's ordering semantics: 222 * 0: The order of key-value pairs is unspecified 224 * 1: Key-value pairs are encoded in the same order in which they 225 were inserted 227 2.4. Key Uniqueness 229 Bit 0 of the tag represents the uniqueness of the map's keys. 231 * 0: Keys are unique within the map 233 * 1: Keys may be duplicated (i.e., multimaps) 235 2.5. Data Item 237 All these map-like data items could be represented as a tag with an 238 enclosed array of alternating key-value pairs, as in: 240 129(["key1", 1, "key2", 2]) 242 However, representing the key-value pairs as a CBOR map for those 243 cases where this is possible enables generic decoders that are 244 oblivious of these tags to represent the data in a more appropriate 245 platform type. 247 Specifically, the key-value pairs are represented as a map if and 248 only if 250 * the ordering is unspecified and 252 * the keys are unique; 254 otherwise, they are represented as an array of alternating keys and 255 values ("flattened alist", see Figure 1). 257 FAList = [* (K, V)] 259 Figure 1: CDDL for order-preserving representation of maps 261 *Issue*: [MAPREP] discusses alternative representations of (ordered 262 and other) maps. How much of this do we need to address here? 264 2.6. Related Tags (Informative) 266 2.6.1. Tag 259 268 Specification: https://github.com/shanewholloway/js-cbor- 269 codec/blob/master/docs/CBOR-259-spec--explicit-maps.md 271 The above defined tag 128 may be used instead to guide a JavaScript 272 decoder into interpreting a CBOR map as a JavaScript Map instead of 273 an Object. 275 2.6.2. Tag 275 277 Specification: https://github.com/ecorm/cbor-tag-text-key-map 279 The above defined tag 132 may be used instead to guide a decoder into 280 interpreting a CBOR map as a JavaScript-like Object having only text 281 string keys. The decoder would have to verify the first key to 282 establish that the map has homogeneous text string keys. 284 2.6.3. Tag TBD279 286 Draft specification: https://github.com/Sekenre/cbor-ordered-map- 287 spec/blob/master/CBOR_Ordered_Map.md 288 The above defined tag 130 may be used instead to encode map-like data 289 items where the order of the key-value pairs is semantically 290 significant. 292 2.6.4. Tag TDB280 294 Draft specification: https://github.com/ecorm/cbor-tag-multimap 296 The above defined tag 129 may be used instead to encode a multimap as 297 an array of key-value pairs. 299 3. CDDL Support for Map-Like Data Items 301 The Concise Data Definition Language (CDDL), standardized in RFC 302 8610, provides "control operators" as its main language extension 303 point. 305 The present document defines a number of control operators that 306 enable the use of group notation (enclosed in a CDDL map) to specify 307 any of the above map-like data structures: 309 +=========+=========================+ 310 | Name | Purpose | 311 +=========+=========================+ 312 | .omm | Ordered (Multi-)Map | 313 +---------+-------------------------+ 314 | .nomm | Non-Ordered (Multi-)Map | 315 +---------+-------------------------+ 316 | .unique | Uniqueness requirement | 317 +---------+-------------------------+ 319 Table 2: New control operators in 320 this document 322 3.1. Map notation for map-like data items 324 [needs better examples] 326 CDDL already can describe both arrays of alternating keys and values 327 and maps (non-ordered and with unique keys). The two control 328 operators ".omm" and ".nomm" introduced in this section enable the 329 use of CDDL map notation for map-like types beyond actual maps, 330 increasing readability and possibly even reusability. 332 In a simple example that provides an non-ordered collection of zero 333 or more home addresses and zero or more work addresses, each labeled 334 as such, we use traditional map notation to describe that collection: 336 [* (text, any)] .nomm { 337 * home: address 338 * work: address 339 $$more-addresses 340 } 342 The ".omm" and ".nomm" control operators convert a group definition 343 enclosed into a CDDL map given as a controller type into an array 344 type given as the target type. The controller type given is 345 unwrapped (Section 3.7 of [RFC8610]) into a group. Keys and values 346 of the entries in that group are then alternatingly matched as 347 elements in the target array. Note that both target and controller 348 type can contribute to the shaping of the data; declaring the key 349 type as "text" limits what can be added to the "$$more-addresses" 350 socket. 352 ".omm" and ".nomm" differ in the semantics of the array type created: 353 ".omm" defines an ordered (multi)map, i.e., the order of the key/ 354 value element pairs in the array matters, while ".nomm" defines an 355 non-ordered (multi)map, i.e., data items that present the same set of 356 key/value pairs in different orders are equivalent. 358 The ability to specify specific ("homogeneous") types is provided by 359 the ability to specify the target type, as in the example above. 361 Note that there is not strictly a need to define a control operator 362 for building non-ordered maps with non-duplicate keys, as existing 363 CBOR maps already fill this role, however the use of a map type as 364 the target is allowed for symmetry (implying uniqueness of the keys), 365 allowing the following: 367 {* text => any} .nomm { 368 ? home: address 369 ? work: address 370 $$more-addresses 371 } 373 3.2. Uniqueness 375 The ".unique" control annotates the target as requiring uniqueness, 376 within the enclosing container(*), of its value, among the other data 377 items in that enclosing container that are also marked ".unique", 378 under the same label (given as the controller). 380 E.g., 381 feature-set = [* feature .unique "set"] 382 ordered-pairs-with-unique-keys-and-values = 383 [* (any .unique "key", any .unique "value") ] 385 defines a "feature-set" as an array of zero or more "feature" values 386 that need to be all different (as they are unique under the label 387 "set"), and "ordered-map-with-unique-keys-and-values" as an array of 388 zero pairs of keys and values, where the keys need to be unique among 389 themselves and the values need to be unique among themselves (the 390 latter example could employ an ".omm" or ".nomm" operator to further 391 restrict what can be in these keys and values). 393 Discussion: (*) while it is probably not a big problem to define 394 what exactly the "enclosing" container is, it may be useful to 395 actually define a larger scope of the uniqueness. CDDL currently 396 does not have a way to establish and point to such a larger scope; 397 we might define one ad hoc here or leave that for later extension. 399 4. CDDL typenames 401 For the use with CDDL [RFC8610], the typenames defined in Figure 2 402 are recommended unless there is a need for more specific shaping of 403 the data. 405 anymap = {* any => any} 407 tbd128 = #6.128(anymap) 408 tbd129 = #6.129([* (any, any)] .nomm anymap) 409 tbd130 = #6.130([* ((any .unique "mm"), any)] .omm anymap) 410 tbd131 = #6.131([* (any, any)] .omm anymap) 411 tbd132 = #6.132({* k => any}) 412 tbd133 = #6.133([* (k, any)] .nomm anymap) 413 tbd134 = #6.134([* ((k .unique "mm"), any)] .omm anymap) 414 tbd135 = #6.135([* (k, any)] .omm anymap) 415 tbd136 = #6.136({* k => v}) 416 tbd137 = #6.137([* (k, v)] .nomm anymap) 417 tbd139 = #6.138([* ((k .unique "mm"), v)] .omm anymap) 418 tbd139 = #6.139([* (k, v)] .omm anymap) 420 Figure 2: Recommended typenames for CDDL 422 *Issue*: fill in better names for tbdnnn 424 Note that there is no need to call out the uniqueness of the keys 425 explicitly in tbd128, tbd132, or tbd136, as the use of maps as a 426 representation format already provides that key uniqueness. 428 5. IANA Considerations 430 5.1. Tags 432 IANA is requested to allocate the tags of Table 1 in the CBOR tags 433 registry [IANA.cbor-tags], using this document as the specification 434 reference. 436 The allocations are requested to be assigned from the "specification 437 required" space (24..255). The values in the column labeled "Tag" in 438 Table 1 are suggested as the allocated tag numbers. 440 5.2. CDDL control operators 442 This document requests IANA to register the contents of Table 3 into 443 the CDDL Control Operators registry [IANA.cddl]: 445 +=========+===========+ 446 | Name | Reference | 447 +=========+===========+ 448 | .omm | [RFCthis] | 449 +---------+-----------+ 450 | .nomm | [RFCthis] | 451 +---------+-----------+ 452 | .unique | [RFCthis] | 453 +---------+-----------+ 455 Table 3: New control 456 operators to be 457 registered 459 6. Implementation Status 461 TBD 463 7. Security considerations 465 The security considerations of [RFC8610] apply. 467 8. References 469 8.1. Normative References 471 [IANA.cbor-tags] 472 IANA, "Concise Binary Object Representation (CBOR) Tags", 473 . 475 [IANA.cddl] 476 IANA, "Concise Data Definition Language (CDDL)", 477 . 479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, 481 DOI 10.17487/RFC2119, March 1997, 482 . 484 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 485 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 486 May 2017, . 488 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 489 Definition Language (CDDL): A Notational Convention to 490 Express Concise Binary Object Representation (CBOR) and 491 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 492 June 2019, . 494 [RFC8746] Bormann, C., Ed., "Concise Binary Object Representation 495 (CBOR) Tags for Typed Arrays", RFC 8746, 496 DOI 10.17487/RFC8746, February 2020, 497 . 499 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 500 Representation (CBOR)", STD 94, RFC 8949, 501 DOI 10.17487/RFC8949, December 2020, 502 . 504 8.2. Informative References 506 [MAPREP] Bormann, C., "Re: [Cbor] "ordered hash"", cbor@ietf.org 507 mailing list message, 30 July 2020, 508 . 511 Appendix A. Implementation Considerations 513 This non-normative appendix provides information about the use on 514 implementations of the tags and control operators defined. 516 A.1. Programming Language Containers (Informative) 518 The following subsections describe how the tags in this document 519 relate to various programming language containers. Containers that 520 are not part of the programming language or its standard libraries 521 are not considered here. 523 The _Encoding Tag_ column in the following tables provide the 524 recommended tag that best represents the given container type. For 525 example, it's possible to use tag 132 for encoding an ECMAScript 526 "Map" if all keys happen to be of the same type, however tag 128 is 527 more general and applies to any "Map". When encoding an ECMAScript 528 "Object", tag 128 would be technically correct but is too general; 529 tag 132 best presents the fact that an "Object" has text keys only. 531 The _Decodable Tags_ column in the following tables, are for data 532 items can be decoded into the destination container without having to 533 inspect the following: 535 * the uniqueness of the keys, 537 * the ordering of the keys, and, 539 * the data types of *every* keys/value pair. 541 It may however be necessary to inspect the data types of the *first* 542 key-value pair in the case of tags representing homogeneous keys/ 543 values. 545 A.1.1. ECMAScript 547 +==================+==============+================+ 548 | Container | Encoding Tag | Decodable Tags | 549 +==================+==============+================+ 550 | Object | 132 | 132, 136 | 551 +------------------+--------------+----------------+ 552 | Map | 128 | 128, 132, 136 | 553 +------------------+--------------+----------------+ 554 | "Array" of pairs | 131 | All | 555 +------------------+--------------+----------------+ 557 Table 4 559 A.1.2. Python 561 +====================+==============+================+ 562 | Container | Encoding Tag | Decodable Tags | 563 +====================+==============+================+ 564 | TypedDict | 136 | 136 | 565 +--------------------+--------------+----------------+ 566 | namedtuple | 132 | 132, 136 | 567 +--------------------+--------------+----------------+ 568 | dict | 128 | 128, 132, 136 | 569 +--------------------+--------------+----------------+ 570 | OrderedDict | 130 | 130, 134, 138 | 571 +--------------------+--------------+----------------+ 572 | "list" of 2-tuples | 131 | All | 573 +--------------------+--------------+----------------+ 575 Table 5 577 A.1.3. C++ 579 +======================+==============+================+ 580 | Container(s) | Encoding Tag | Decodable Tags | 581 +======================+==============+================+ 582 | Map | 136 | 136 | 583 +----------------------+--------------+----------------+ 584 | Map | 132 | 132, 136 | 585 +----------------------+--------------+----------------+ 586 | Map | 128 | 128, 132, 136 | 587 +----------------------+--------------+----------------+ 588 | MultiMap | 137 | 137 | 589 +----------------------+--------------+----------------+ 590 | MultiMap | 133 | 133 | 591 +----------------------+--------------+----------------+ 592 | MultiMap | 129 | 128, 129 | 593 +----------------------+--------------+----------------+ 594 | Sequence> | 139 | [136, 139] | 595 +----------------------+--------------+----------------+ 596 | Sequence> | 135 | [132, 139] | 597 +----------------------+--------------+----------------+ 598 | Sequence> | 131 | All | 599 +----------------------+--------------+----------------+ 601 Table 6 603 Legend: 605 * "K": Static key type 607 * "T": Static value type 609 * "D": Suitable dynamic type, such as "std::any" or "std::variant" 611 * "Map": "std::map" or "std::unordered_map" 613 * "MultiMap": "std::multimap" or "std::unordered_multimap" 615 * "Sequence": Sequence container that maintains order (e.g. 616 "std::vector") 618 * "Pair": Object containing a key and a value, such as "std::pair", 619 or "std::tuple". 621 Note that a C++ "std::map" stores its key-value pairs in a sorted 622 fashion, and does *not* preserve insertion order in the same manner 623 as Python's "OrderedDict". 625 A.2. CDDL Implementation Considerations 627 TBD 629 Acknowledgements 631 The CBOR tags defined in this document were developed by Emile 632 Cormier under the sponsorship of Duc Luong, based on discussions with 633 Kio Smallwood and Joe Hildebrand. The CDDL control operators defined 634 in this document were developed by Carsten Bormann, Brendan Moran, 635 and Henk Birkholz. 637 Contributors 639 Kio Smallwood 641 Joe Hildebrand 643 Authors' Addresses 645 Carsten Bormann (editor) 646 Universität Bremen TZI 647 Postfach 330440 648 D-28359 Bremen 649 Germany 651 Phone: +49-421-218-63921 652 Email: cabo@tzi.org 654 Brendan Moran 655 Arm Limited 657 Email: Brendan.Moran@arm.com 659 Henk Birkholz 660 Fraunhofer SIT 661 Email: henk.birkholz@sit.fraunhofer.de 663 Emile Cormier 665 Email: emile.cormier.jr@gmail.com