idnits 2.17.00 (12 Aug 2021) /tmp/idnits23409/draft-bormann-apparea-bpack-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 3365 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-lwig-terminology has been published as RFC 7228 -- Obsolete informational reference (is this intentional?): RFC 4627 (Obsoleted by RFC 7158, RFC 7159) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 APP area C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational February 25, 2013 5 Expires: August 29, 2013 7 The BinaryPack1pre2 JSON-like representation format 8 draft-bormann-apparea-bpack-01 10 Abstract 12 JSON (RFC 4627) is an extremely successful format for the 13 representation of structured information, supporting Boolean values, 14 numbers, strings, arrays, and tables. Recently, a number of 15 applications have started to look for binary representation formats 16 that solve a similar problem. In particular, constrained node 17 networks can benefit from such a binary representation format. 19 A very successful binary representation that is otherwise comparable 20 to JSON is MessagePack. Recently, a number of implementations have 21 modified or extended MessagePack such that it allows for 22 distinguishing UTF-8 strings from binary data. Further discussion on 23 the MessagePack repository has resulted in proposals how to integrate 24 such an addition back into the MessagePack community. 26 This draft, as an independent effort, documents one such format, 27 tentatively calling it BinaryPack1pre2 while the MessagePack 28 extension proposals make their way through the MessagePack community. 30 The current version -01 of this document is a snapshot that 31 demonstrates a general direction. The details may change in future 32 versions based on the development of the MessagePack specification. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 29, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. The BinaryPack1pre2 Representation Format . . . . . . . . . . 5 72 2.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 5 73 2.2. Integers . . . . . . . . . . . . . . . . . . . . . . . . 6 74 2.3. Floating Point Values . . . . . . . . . . . . . . . . . . 6 75 2.4. Special Values . . . . . . . . . . . . . . . . . . . . . 6 76 2.5. Binary: Opaque Byte Strings . . . . . . . . . . . . . . . 7 77 2.6. UTF-8 Strings . . . . . . . . . . . . . . . . . . . . . . 7 78 2.7. Arrays . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 2.8. Tables . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 3.1. JSON roundtripping . . . . . . . . . . . . . . . . . . . 9 82 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 87 7.2. Informative References . . . . . . . . . . . . . . . . . 10 88 Appendix A. Unicode Considerations . . . . . . . . . . . . . . . 11 89 Appendix B. Potential future work . . . . . . . . . . . . . . . 12 90 B.1. Reserved Code Points . . . . . . . . . . . . . . . . . . 12 91 B.2. 16-bit floating point . . . . . . . . . . . . . . . . . . 12 92 B.3. DateTime . . . . . . . . . . . . . . . . . . . . . . . . 12 93 B.4. Prefixing extensions . . . . . . . . . . . . . . . . . . 13 94 B.5. Extension Points . . . . . . . . . . . . . . . . . . . . 13 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 97 1. Introduction 99 (To be written - for now please see the Abstract.) 101 A description of the MessagePack binary representation format can be 102 found in [msgpack]. A recent proposal for an update, still under 103 discussion, is in [msgpack-update]. 105 One of the early proposals implementing separate types for byte 106 strings and UTF-8 strings was called BinaryPack. An implementation 107 of BinaryPack is available in [binarypack]. (An extension similar in 108 spirit, but different in details, was made for the [msgpack-js] and 109 [msgpack-js-browser] projects.) 111 1.1. Objectives 113 (TBD, but this is a rough first approach:) 115 The objectives of the present specification, roughly in decreasing 116 order of importance, are: 118 o Representing a reasonable set of basic data types and structures 119 using binary encoding. "Reasonable" here is largely influenced by 120 the capabilities of JSON, with the single addition of adding raw 121 byte strings. The structures supported are limited to trees; no 122 loops or lattice-style graphs. 124 o Being implementable in a very small amount of code, thus being 125 applicable to constrained nodes [I-D.ietf-lwig-terminology], even 126 of class 1. (Complexity goal.) As a corollary: Being close to 127 contemporary machine representations of data (e.g., not requiring 128 binary-to-decimal conversion). 130 o Being applicable to schema-less use. For schema-informed binary 131 encoding, a number of approaches are already available in the 132 IETF, including XDR [RFC4506]. (However, schema-informed use of 133 the present specification, such as for a marshaling scheme for an 134 RPC IDL, is not at all excluded. Any IDL for this is out of scope 135 for this specification.) 137 o Being reasonably compact. "Reasonable" here is bounded by JSON as 138 an upper bound in size, and by implementation complexity 139 maintaining a lower bound. The use of general compression schemes 140 violates both of the complexity goals. 142 o Being reasonably frugal in CPU usage. (The other complexity 143 goal.) This is relevant both for constrained nodes and for 144 potential usage in high-volume applications. 146 o Supporting a reasonable level of round-tripping with JSON, as long 147 as the data represented are within the capabilities of JSON. 148 Defining a unidirectional mapping towards JSON for all types of 149 data. 151 1.2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 The term "byte" is used in its now customary sense as a synonym for 158 "octet". 160 All multi-byte integers in this protocol are interpreted in network 161 byte order. 163 Where arithmetic is used, this specification uses the notation 164 familiar from the programming language C, except that the operator 165 "**" stands for exponentiation. 167 1.3. Notation 169 This specification uses a trivial notation for code bytes and the 170 bitfields in them the meaning of which should be mostly obvious. 171 More formally speaking, the meaning of the notation is: 173 Potential values for the code bytes themselves are expressed by 174 templates that represent 8-bit most-significant-bit-first binary 175 numbers (without any special prefix), where 0 stands for 0, 1 for 1, 176 and variable segments in these code byte templates are indicated by 177 sequences of the same letter such as kkkkkkk or ssss, the length of 178 which indicates the length of the variable segment in bits. 180 In the notation of values derived from the code bytes, 0b is used as 181 a prefix for expressing binary numbers in most-significant-bit first 182 notation (akin to the use of 0x for most-significant-digit-first 183 hexadecimal numbers in the C programming language). Where the above- 184 mentioned sequences of letters are then referenced in such a binary 185 number in the text, the intention is that the value from these 186 bitfields in the actual code byte be inserted. 188 Example: The code byte template 190 101nssss 192 stands for a byte that starts (most-significant-bit-first) with the 193 bits 1, 0, and 1, and continues with five variable bits, the first of 194 which is referenced as "n" and the next four are referenced as 195 "ssss". Based on this code byte template, a reference to 197 0b0ssss000 199 means a binary number composed from a zero bit, the four bits that 200 are in the "ssss" field (for 101nssss, the four least significant 201 bits) in the actual byte encountered, kept in the same order, and 202 three more zero bits. 204 Also, 0xhh stands for the hexadecimal value hh, and 1B, 2B, 4B, 8B, 205 nB stand for 1, 2, 4, 8, or n bytes of data following; (1B) etc. 206 stand for the numerical value of these bytes as an integer 207 interpreted in network byte order; nD stands for n data objects, each 208 in turn in BinaryPack1pre2 representation format. 210 2. The BinaryPack1pre2 Representation Format 212 2.1. Data Types 214 The BinaryPack1pre2 representation format is able to represent the 215 following data types: 217 o Integers (represented in signed and unsigned forms) 219 o Floating point values (in IEEE 754 32-bit and 64-bit forms) 221 o special values nil, false, true 223 o opaque ("raw") byte strings, or "binary strings" 225 o UTF-8 strings 227 o arrays, which can contain any combination of data types 229 o tables (often called maps, hashes, dictionaries; objects in JSON), 230 which contain pairs, key and value, which may in turn be of any 231 data type 233 This list is mostly faithful to JSON [RFC4627], which however does 234 not distinguish integer from floating point number types. Based on 235 recent discussions on the use of binary representation formats, the 236 present specification distinguishes UTF-8 strings from opaque binary 237 strings. (Interestingly, such a separation was already done in the 238 binaryjs implementation of a "95 % MessagePack" format [binarypack], 239 so the author of the present specification started out by just lazily 240 copying that; more recent input taken from the msgpack developers 241 [msgpack-update] is the technical basis for the current proposal.) 243 2.2. Integers 245 BinaryPack1pre2 provides a number of representations for integer 246 values, assuming that these occur often. The encoder is free to 247 choose any of these representations that is able to represent the 248 desired value. 250 +----------+--------------+----------------------------+ 251 | Bits | Value | Description | 252 +----------+--------------+----------------------------+ 253 | 0nnnnnnn | 0bnnnnnnn | Positive Integer (0..127) | 254 | | | | 255 | 111nnnnn | 0bnnnnn - 32 | Negative Integer (-32..-1) | 256 | | | | 257 | 0xcc 1B | 1B as uint | Unsigned Integer | 258 | | | | 259 | 0xcd 2B | 2B as uint | Unsigned Integer | 260 | | | | 261 | 0xce 4B | 4B as uint | Unsigned Integer | 262 | | | | 263 | 0xcf 8B | 8B as uint | Unsigned Integer | 264 | | | | 265 | 0xd0 1B | 1B as sint | Signed Integer | 266 | | | | 267 | 0xd1 2B | 2B as sint | Signed Integer | 268 | | | | 269 | 0xd2 4B | 4B as sint | Signed Integer | 270 | | | | 271 | 0xd3 8B | 8B as sint | Signed Integer | 272 +----------+--------------+----------------------------+ 274 2.3. Floating Point Values 276 BinaryPack1pre2 provides 32-bit and 64-bit IEEE 754 values. (See 277 also Appendix B.2.) 279 +---------+-----------------------+-------------+ 280 | Bits | Value | Description | 281 +---------+-----------------------+-------------+ 282 | 0xca 4B | 4B as 32-bit IEEE 754 | Float | 283 | | | | 284 | 0xcb 8B | 8B as 64-bit IEEE 754 | Double | 285 +---------+-----------------------+-------------+ 287 2.4. Special Values 288 Similar to the special literals "false null true" in JSON, 289 BinaryPack1pre2 provides three special values: 291 +------+-------+---------------+ 292 | Bits | Value | Description | 293 +------+-------+---------------+ 294 | 0xc0 | nil | null, nothing | 295 | | | | 296 | 0xc2 | false | Boolean false | 297 | | | | 298 | 0xc3 | true | Boolean true | 299 +------+-------+---------------+ 301 2.5. Binary: Opaque Byte Strings 303 (Note that the specific codepoint allocations in this section are 304 very much up for discussion. It can also be argued that we should be 305 spending some of the remaining reserved codepoints for short byte 306 strings.) 308 +------------+----------+----------------------------------+ 309 | Bits | Value | Description | 310 +------------+----------+----------------------------------+ 311 | 0xd5 1B nB | n = (1B) | byte string (0..(2**8-1) bytes) | 312 | | | | 313 | 0xd6 2B nB | n = (2B) | byte string (0..(2**16-1) bytes) | 314 | | | | 315 | 0xd7 4B nB | n = (4B) | byte string (0..(2**32-1) bytes) | 316 +------------+----------+----------------------------------+ 318 2.6. UTF-8 Strings 320 +-------------+-------------+-----------------------------------+ 321 | Bits | Value | Description | 322 +-------------+-------------+-----------------------------------+ 323 | 101nnnnn nB | n = 0bnnnnn | Short UTF-8 string (0..31 bytes) | 324 | | | | 325 | 0xd9 1B nB | n = (1B) | UTF-8 string (0..(2**8-1) bytes) | 326 | | | | 327 | 0xda 2B nB | n = (2B) | UTF-8 string (0..(2**16-1) bytes) | 328 | | | | 329 | 0xdb 4B nB | n = (4B) | UTF-8 string (0..(2**32-1) bytes) | 330 +-------------+-------------+-----------------------------------+ 332 The strings transported MUST be UTF-8 strings [RFC3629]. (The 333 general assumption is that these UTF-8 strings are in Network Unicode 334 form [RFC5198], see Appendix A for some more discussion.) 336 2.7. Arrays 338 +-------------+------------+------------------------------------+ 339 | Bits | Value | Description | 340 +-------------+------------+------------------------------------+ 341 | 1001nnnn nD | n = 0bnnnn | Short array (0..15 data elements) | 342 | | | | 343 | 0xdc 2B nD | n = (2B) | array (0..(2**16-1) data elements) | 344 | | | | 345 | 0xdd 4B nD | n = (4B) | array (0..(2**32-1) data elements) | 346 +-------------+------------+------------------------------------+ 348 2.8. Tables 350 +-------------+----------------+---------------------------------+ 351 | Bits | Value | Description | 352 +-------------+----------------+---------------------------------+ 353 | 1000nnnn nD | n = 2 * 0bnnnn | Short table (0..15 data pairs) | 354 | | | | 355 | 0xde 2B nD | n = 2 * (2B) | table (0..(2**16-1) data pairs) | 356 | | | | 357 | 0xdf 4B nD | n = 2 * (4B) | table (0..(2**32-1) data pairs) | 358 +-------------+----------------+---------------------------------+ 360 The sequence of n elements is a sequence of pairs of data objects, 361 each pair represented as one data object representing the key 362 followed by the data object representing its associated value. 364 3. Discussion 366 This draft tries to be faithful to the successful MessagePack 367 [msgpack] format, including an recent extension proposal that enables 368 the distinction between opaque binary byte strings and UTF-8 byte 369 strings [msgpack-update]. 371 Little analysis has been made whether a slightly different bit 372 allocation (e.g., using up fewer of the code combination for single- 373 byte integers) would be advantageous. However, the gains from a 374 different allocation are likely to be limited except for pathological 375 cases. (The main benefit achievable may be to have more codepoints 376 reserved for future expansion.) 377 A short floating point (e.g., based on the 16-bit IEEE 754 floating 378 point value) might be a useful additional representation format. 379 Adding decimal floating point values probably is not so useful, 380 except where high fidelity to JSON is desired. 382 Some additional data types might be useful for some protocols, e.g. 383 UUIDs [RFC4122], date/time. See also Appendix B. This would further 384 increase the distance from JSON that BinaryPack1pre2 creates by 385 distinguishing opaque and UTF-8 strings. 387 3.1. JSON roundtripping 389 BinaryPack1pre2 enables mostly lossless translation to JSON. JSON 390 [RFC4627]. JSON roundtripping, however, is not necessarily the 391 primary design goal of BinaryPack1pre2, but it is a consideration. 393 In the translation of BinaryPack1pre2 to JSON, opaque byte strings 394 SHOULD be converted to equivalent base64url [RFC4648] UTF-8 strings. 395 Without a schema, it is hard to do the inverse consistently, as 396 base64url encoded byte strings are not specially marked up in JSON. 398 When translating BinaryPack1pre2 floating point values to JSON, the 399 usual problem of converting binary fractions to decimal 400 representation arises. In the other direction, the choice of a 401 floating point format may be hard to do properly. Clearly, any 402 number that can be transformed from a 64-bit IEEE 754 number to a 403 32-bit IEEE 754 number without loss of information can be represented 404 as the latter. Without schema information, it may be hard to find 405 other cases where the precision maybe is not that important. 407 4. IANA Considerations 409 Once this has received some discussion, we will understand how 410 exactly to register Internet media types for this. 412 The potential extension mechanisms discussed in Appendix B may need 413 an IANA registry. 415 5. Security Considerations 417 (Nothing but generic warnings about correctly implementing protocol 418 encoders/decoders so far; this section will certainly grow as 419 additional security considerations become known.) 421 6. Acknowledgements 423 MessagePack was developed and promoted by Sadayuki Furuhashi 424 ("frsyuki"). 426 BinaryPack is a minor derivation of MessagePack that was developed by 427 Eric Zhang for the binaryjs project. A similar, but different 428 extension was made by Tim Caswell for his [msgpack-js] and 429 [msgpack-js-browser] projects. 431 The author of the present specification deserves absolutely no 432 credits whatsoever for any of this. 434 7. References 436 7.1. Normative References 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, March 1997. 441 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 442 10646", STD 63, RFC 3629, November 2003. 444 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 445 Encodings", RFC 4648, October 2006. 447 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 448 Interchange", RFC 5198, March 2008. 450 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 451 Time Protocol Version 4: Protocol and Algorithms 452 Specification", RFC 5905, June 2010. 454 7.2. Informative References 456 [I-D.ietf-lwig-terminology] 457 Bormann, C. and M. Ersue, "Terminology for Constrained 458 Node Networks", draft-ietf-lwig-terminology-00 (work in 459 progress), February 2013. 461 [N4246R2] Lunde, K., "Stabilizing CJK Compatibility Ideographs 462 through the use of Standardized Variants", ISO/IEC JTC1/ 463 SC2/WG2 N4246R2, March 2012, . 466 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 467 Internet: Timestamps", RFC 3339, July 2002. 469 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 470 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 471 2005. 473 [RFC4506] Eisler, M., "XDR: External Data Representation Standard", 474 STD 67, RFC 4506, May 2006. 476 [RFC4627] Crockford, D., "The application/json Media Type for 477 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 479 [binarypack] 480 Zhang, E., "BinaryPack for Javascript browsers", 2012, 481 . 483 [msgpack-js-browser] 484 Caswell, T., "msgpack for the browser", 2012, . 487 [msgpack-js] 488 Caswell, T., "msgpack for node", 2012, . 491 [msgpack-update] 492 Furuhashi, S., "msgpack-update-proposal1.md", February 493 2012, . 495 [msgpack] Ohta, K. and S. Colebourne, "MessagePack format 496 specification", 2011, . 499 Appendix A. Unicode Considerations 501 (TBD. Some initial guidelines at [msgpack-update]. This section 502 should make clear that:) 504 o At the BinaryPack1pre2 encoding/decoding layer, implementations 505 are never concerned about Unicode normalization. 507 o Internet usage of Unicode is governed by [RFC5198]. The present 508 specification will not try to second-guess the evolution of this 509 standards-track document. 511 o [RFC5198] states that >>Before transmission, all character 512 sequences SHOULD be normalized according to Unicode normalization 513 form "NFC"<<. There may be some need to interpret this "SHOULD" 514 in the context of the present specification, as follows. 516 o There is a very strong expectation that applications making use of 517 BinaryPack1pre2 will lean towards using Unicode in NFC form, as 518 opposed to NFD. In other words, receivers may expect data in the 519 maximally composed form, as opposed to decomposed form. 521 o The Normalization component of NFC may create problems in some 522 applications (e.g., see [N4246R2]). Before this is repaired in 523 some future version of Unicode, there is no expectation that all 524 applications generating BinaryPack1pre2 always perform the 525 canonical normalization where information loss would result. 527 o There is a strong expectation that BinaryPack1pre2 receivers be 528 resilient to the small variations in Unicode usage discussed here. 530 Appendix B. Potential future work 532 Two data types have been discussed for addition to BinaryPack1pre2. 534 B.1. Reserved Code Points 536 As of today, the following code points are reserved and could be used 537 for further extension, if required: 539 0xc1, 0xc4..0xc9, 0xd4, 0xd8 541 B.2. 16-bit floating point 543 16-bit floating points have become popular recently. BinaryPack1pre2 544 could enable the efficient transport of small floating point numbers 545 by adding a Half-precision floating point representation: 547 +---------+-----------------------+-------------+ 548 | Bits | Value | Description | 549 +---------+-----------------------+-------------+ 550 | 0xc9 2B | 2B as 16-bit IEEE 754 | Half | 551 | | | | 552 | 0xca 4B | 4B as 32-bit IEEE 754 | Float | 553 | | | | 554 | 0xcb 8B | 8B as 64-bit IEEE 754 | Double | 555 +---------+-----------------------+-------------+ 557 B.3. DateTime 559 Many applications need the transport of Date/Time information. Some 560 need micro- or nanosecond resolution, some are more concerned about 561 significant range. 563 In the IETF, both NTP timestamps [RFC5905] and ISO8601 dates 564 [RFC3339] are popular. The former probably require short and long 565 versions to accommodate the different requirements in precision and 566 range. As a start, a 32.32 and a 64.64 NTP timestamp could be 567 defined. ISO8601 dates would need a length indicator and could 568 therefore look close to the string8 form in BinaryPack1pre2. It is 569 worth limiting the set of choices based on some more input on what is 570 actually required. 572 B.4. Prefixing extensions 574 As the small number of remaining code points could be used up 575 quickly, some additions might preferably be expressed by a prefixing 576 scheme. E.g., if 0xc1 is picked for prefixing, the format 578 0xc1 0xnn 0xd5 0x08 ... 580 could be used for designating an 8-byte binary string (0xd5 0x08 ...) 581 as e.g. a date/time in 32.32 NTP timestamp format; the same value 582 for 0xnn could also be followed by a 16-byte binary string for a full 583 64.64 NTP timestamp and maybe even followed by an UTF-8 string for 584 GeneralizedTime _or_ an ISO8601 time, depending on which of these 585 formats are desirable. Implementations unaware of the semantics for 586 a specific value of 0xnn could still process the information as a 587 binary or UTF-8 string. 589 The number of extensions defined this way should be kept very small, 590 not only to preserve coding efficiency by making do with the single- 591 byte discriminator. The values for 0xnn would then be maintained in 592 an IANA registry, with a suitably careful allocation policy. This 593 needs further discussion. 595 B.5. Extension Points 597 More generally, evolution of a format always raises considerations 598 about compatibility. There are two directions of compatibility: - 599 Old data/old senders to new receivers (forward compatibility) and - 600 new data/new senders to old receivers (backward compatibility). 602 Further extension of the msgpack format currently always loses 603 backward compatibility, as there is no way for an older 604 implementation to find out the length that is consumed by a construct 605 that uses a new codepoint. In addition to a prefixing mechanism, the 606 BinaryPack1pre2 format could include deliberate extension points that 607 would at least allow an old receiver to decode future versions of the 608 BinaryPack1pre2 format without losing synchronization in the byte 609 stream, while possibly having to treat some of the information as 610 opaque. 612 Author's Address 613 Carsten Bormann 614 Universitaet Bremen TZI 615 Postfach 330440 616 Bremen D-28359 617 Germany 619 Phone: +49-421-218-63921 620 Email: cabo@tzi.org