idnits 2.17.1 draft-hallambaker-jsonbcd-14.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 4, 2019) is 1820 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 630 -- Looks like a reference, but probably isn't: '2' on line 632 == Missing Reference: 'RFC2119' is mentioned on line 179, but not defined -- Looks like a reference, but probably isn't: '3' on line 634 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft April 4, 2019 4 Intended status: Informational 5 Expires: October 6, 2019 7 Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D 8 draft-hallambaker-jsonbcd-14 10 Abstract 12 Three binary encodings for JavaScript Object Notation (JSON) are 13 presented. JSON-B (Binary) is a strict superset of the JSON encoding 14 that permits efficient binary encoding of intrinsic JavaScript data 15 types. JSON-C (Compact) is a strict superset of JSON-B that supports 16 compact representation of repeated data strings with short numeric 17 codes. JSON-D (Data) supports additional binary data types for 18 integer and floating-point representations for use in scientific 19 applications where conversion between binary and decimal 20 representations would cause a loss of precision. 22 This document is also available online at 23 http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html [1] . 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 6, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 64 2.3. Related Specifications . . . . . . . . . . . . . . . . . 4 65 2.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Extended JSON Grammar . . . . . . . . . . . . . . . . . . . . 5 67 4. JSON-B . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. JSON-B Examples . . . . . . . . . . . . . . . . . . . . . 9 69 5. JSON-C . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.1. JSON-C Examples . . . . . . . . . . . . . . . . . . . . . 11 71 6. JSON-D (Data) . . . . . . . . . . . . . . . . . . . . . . . . 12 72 7. JBCD Frames and Records . . . . . . . . . . . . . . . . . . . 13 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 11.2. Informative References . . . . . . . . . . . . . . . . . 15 79 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 JavaScript Object Notation (JSON) is a simple text encoding for the 85 JavaScript Data model that has found wide application beyond its 86 original field of use. In particular JSON has rapidly become a 87 preferred encoding for Web Services. 89 JSON encoding supports just four fundamental data types (integer, 90 floating point, string and boolean), arrays and objects which consist 91 of a list of tag-value pairs. 93 Although the JSON encoding is sufficient for many purposes it is not 94 always efficient. In particular there is no efficient representation 95 for blocks of binary data. Use of base64 encoding increases data 96 volume by 33%. This overhead increases exponentially in applications 97 where nested binary encodings are required making use of JSON 98 encoding unsatisfactory in cryptographic applications where nested 99 binary structures are frequently required. 101 Another source of inefficiency in JSON encoding is the repeated 102 occurrence of object tags. A JSON encoding containing an array of a 103 hundred objects such as {"first":1,"second":2} will contain a hundred 104 occurrences of the string "first" (seven bytes) and a hundred 105 occurrences of the string "second" (eight bytes). Using two byte 106 code sequences in place of strings allows a saving of 11 bytes per 107 object without loss of information, a saving of 50%. 109 A third objection to the use of JSON encoding is that floating point 110 numbers can only be represented in decimal form and this necessarily 111 involves a loss of precision when converting between binary and 112 decimal representations. While such issues are rarely important in 113 network applications they can be critical in scientific applications. 114 It is not acceptable for saving and restoring a data set to change 115 the result of a calculation. 117 1.1. Objectives 119 The following were identified as core objectives for a binary JSON 120 encoding: 122 o Easy to convert existing encoders and decoders to add binary 123 support 125 o Efficient encoding of binary data 127 o Ability to convert from JSON to binary encoding in a streaming 128 mode (i.e. without reading the entire binary data block before 129 beginning encoding. 131 o Lossless encoding of JavaScript data types 133 o The ability to support JSON tag compression and extended data 134 types are considered desirable but not essential for typical 135 network applications. 137 Three binary encodings are defined: 139 JSON-B (Binary) Encodes JSON data in binary. Only the JavaScript 140 data model is supported (i.e. atomic types are integers, double or 141 string). Integers may be 8, 16, 32 or 64 bits either signed or 142 unsigned. Floating points are IEEE 754 binary64 format [IEEE754] 143 . Supports chunked encoding for binary and UTF-8 string types. 145 JSON-C (Compact) As JSON-B but with support for representing JSON 146 tags in numeric code form (16 bit code space). This is done for 147 both compact encoding and to allow simplification of encoders/ 148 decoders in constrained environments. Codes may be defined inline 149 or by reference to a known dictionary of codes referenced via a 150 digest value. 152 JSON-D (Data) As JSON-C but with support for representing additional 153 data types without loss of precision. In particular other IEEE 154 754 floating point formats, both binary and decimal and Intel's 80 155 bit floating point, plus 128 bit integers and bignum integers. 157 Each encoding is a proper superset of JSON, JSON-C is a proper 158 superset of JSON-B and JSON-D is a proper superset of JSON-C. Thus a 159 single decoder MAY be used for all three new encodings and for JSON. 160 Figure 1 shows these relationships graphically: 162 [[This figure is not viewable in this format. The figure is 163 available at http://mathmesh.com/Documents/draft-hallambaker- 164 jsonbcd.html [2].]] 166 Encoding Relationships. 168 2. Definitions 170 This section presents the related specifications and standard, the 171 terms that are used as terms of art within the documents and the 172 terms used as requirements language. 174 2.1. Requirements Language 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 2.2. Defined Terms 182 The terms of art used in this document are described in the Mesh 183 Architecture Guide [draft-hallambaker-mesh-architecture] . 185 2.3. Related Specifications 187 The JSON-B, JSON-C and JSON-D encodings are all based on the JSON 188 grammar [RFC7159] . IEEE 754 Floating Point Standard is used for 189 encoding floating point numbers [IEEE754] , 191 2.4. Terminology 193 No new terms of art are defined 195 3. Extended JSON Grammar 197 The JSON-B, JSON-C and JSON-D encodings are all based on the JSON 198 grammar [RFC7159] using the same syntactic structure but different 199 lexical encodings. 201 JSON-B0 and JSON-C0 replace the JSON lexical encodings for strings 202 and numbers with binary encodings. JSON-B1 and JSON-C1 allow either 203 lexical encoding to be used. Thus any valid JSON encoding is a valid 204 JSON-B1 or JSON-C1 encoding. 206 The grammar of JSON-B, JSON-C and JSON-D is a superset of the JSON 207 grammar. The following productions are added to the grammar: 209 x-value Binary encodings for data values. As the binary value 210 encodings are all self delimiting 212 x-member An object member where the value is specified as an X-value 213 and thus does not require a value-separator. 215 b-value Binary data encodings defined in JSON-B. 217 b-string Defined length string encoding defined in JSON-B. 219 c-def Tag code definition defined in JSON-C. These may only appear 220 before the beginning of an Object or Array and before any 221 preceding white space. 223 c-tag Tag code value defined in JSON-C. 225 d-value Additional binary data encodings defined in JSON-D for use 226 in scientific data applications. 228 The JSON grammar is modified to permit the use of x-value productions 229 in place of ( value value-separator ) : 231 JSON-text = (object / array) 233 object = *cdef begin-object [ 234 *( member value-separator | x-member ) 235 (member | x-member) ] end-object 237 member = tag value 238 x-member = tag x-value 240 tag = string name-separator | b-string | c-tag 242 array = *cdef begin-array [ *( value value-separator | x-value ) 243 (value | x-value) ] end-array 245 x-value = b-value / d-value 247 value = false / null / true / object / array / number / string 249 name-separator = ws %x3A ws ; : colon 250 value-separator = ws %x2C ws ; , comma 252 The following lexical values are unchanged: 253 begin-array = ws %x5B ws ; [ left square bracket 254 begin-object = ws %x7B ws ; { left curly bracket 255 end-array = ws %x5D ws ; ] right square bracket 256 end-object = ws %x7D ws ; } right curly bracket 258 ws = *( %x20 %x09 %x0A %x0D ) 260 false = %x66.61.6c.73.65 ; false 261 null = %x6e.75.6c.6c ; null 262 true = %x74.72.75.65 ; true 264 The productions number and string are defined as before: 266 number = [ minus ] int [ frac ] [ exp ] 267 decimal-point = %x2E ; . 268 digit1-9 = %x31-39 ; 1-9 269 e = %x65 / %x45 ; e E 270 exp = e [ minus / plus ] 1*DIGIT 271 frac = decimal-point 1*DIGIT 272 int = zero / ( digit1-9 *DIGIT ) 273 minus = %x2D ; - 274 plus = %x2B ; + 275 zero = %x30 ; 0 277 string = quotation-mark *char quotation-mark 278 char = unescaped / 279 escape ( %x22 / %x5C / %x2F / %x62 / %x66 / 280 %x6E / %x72 / %x74 / %x75 4HEXDIG ) 282 escape = %x5C ; \ 283 quotation-mark = %x22 ; " 284 unescaped = %x20-21 / %x23-5B / %x5D-10FFFF 286 4. JSON-B 288 The JSON-B encoding defines the b-value and b-string productions: 290 b-value = b-atom | b-string | b-data | b-integer | 291 b-float 293 b-string = *( string-chunk ) string-term 294 b-data = *( data-chunk ) data-last 296 b-integer = p-int8 | p-int16 | p-int32 | p-int64 | p-bignum16 | 297 n-int8 | n-int16 | n-int32 | n-int64 | n-bignum16 299 b-float = binary64 301 The lexical encodings of the productions are defined in the following 302 tables where the column 'tag' specifies the byte code that begins the 303 production, 'Fixed' specifies the number of data bytes that follow 304 and 'Length' specifies the number of bytes used to define the length 305 of a variable length field following the data bytes: 307 +--------------+-----+-------+--------+-----------------------------+ 308 | Production | Tag | Fixed | Length | Data Description | 309 +--------------+-----+-------+--------+-----------------------------+ 310 | string-term | x80 | - | 1 | Terminal String 8 bit | 311 | | | | | length | 312 | string-term | x81 | - | 2 | Terminal String 16 bit | 313 | | | | | length | 314 | string-term | x82 | - | 4 | Terminal String 32 bit | 315 | | | | | length | 316 | string-term | x83 | - | 8 | Terminal String 64 bit | 317 | | | | | length | 318 | string-chunk | x84 | - | 1 | Terminal String 8 bit | 319 | | | | | length | 320 | string-chunk | x85 | - | 2 | Terminal String 16 bit | 321 | | | | | length | 322 | string-chunk | x86 | - | 4 | Terminal String 32 bit | 323 | | | | | length | 324 | string-chunk | x87 | - | 8 | Terminal String 64 bit | 325 | | | | | length | 326 | data-term | x88 | - | 1 | Terminal String 8 bit | 327 | | | | | length | 328 | data-term | x89 | - | 2 | Terminal String 16 bit | 329 | | | | | length | 330 | data-term | x8A | - | 4 | Terminal String 32 bit | 331 | | | | | length | 332 | data-term | x8B | - | 8 | Terminal String 64 bit | 333 | | | | | length | 334 | data-chunk | X8C | - | 1 | Terminal String 8 bit | 335 | | | | | length | 336 | data-chunk | x8D | - | 2 | Terminal String 16 bit | 337 | | | | | length | 338 | data-chunk | x8E | - | 4 | Terminal String 32 bit | 339 | | | | | length | 340 | data-chunk | x8F | - | 8 | Terminal String 64 bit | 341 | | | | | length | 342 +--------------+-----+-------+--------+-----------------------------+ 344 Table 1 346 Table 1: Codes for String and Data items 347 +------------+-----+-------+--------+-------------------------------+ 348 | Production | Tag | Fixed | Length | Data Description | 349 +------------+-----+-------+--------+-------------------------------+ 350 | p-int8 | xA0 | 1 | - | Positive 8 bit Integer | 351 | p-int16 | xa1 | 2 | - | Positive 16 bit Integer | 352 | p-int32 | xa2 | 4 | - | Positive 32 bit Integer | 353 | p-int64 | xa3 | 8 | - | Positive 64 bit Integer | 354 | p-bignum16 | Xa7 | - | 2 | Positive Bignum | 355 | n-int8 | xA8 | 1 | - | Negative 8 bit Integer | 356 | n-int16 | xA9 | 2 | - | Negative 16 bit Integer | 357 | n-int32 | xAA | 4 | - | Negative 32 bit Integer | 358 | n-int64 | xAB | 8 | - | Negative 64 bit Integer | 359 | n-bignum16 | xAF | - | 2 | Negative Bignum | 360 | binary64 | x92 | 8 | - | IEEE 754 Floating Point | 361 | | | | | Binary 64 bit | 362 | b-value | xB0 | - | - | True | 363 | b-value | xB1 | - | - | False | 364 | b-value | xB2 | - | - | Null | 365 +------------+-----+-------+--------+-------------------------------+ 367 Table 2 369 Table 2: Codes for Integers, 64 Bit Floating Point, Boolean and Null 370 items. 372 A data type commonly used in networking that is not defined in this 373 scheme is a datetime representation. To define such a data type, a 374 string containing a date-time value in Internet type format is 375 typically used. 377 4.1. JSON-B Examples 379 The following examples show examples of using JSON-B encoding: 381 A0 2A 42 (as 8 bit integer) 382 A1 00 2A 42 (as 16 bit integer) 383 A2 00 00 00 2A 42 (as 32 bit integer) 384 A3 00 00 00 00 00 00 00 2A 42 (as 64 bit integer) 385 A5 00 01 42 42 (as Bignum) 387 80 05 48 65 6c 6c 6f "Hello" (single chunk) 388 81 00 05 48 65 6c 6c 6f "Hello" (single chunk) 389 84 05 48 65 6c 6c 6f 80 00 "Hello" (as two chunks) 391 92 3f f0 00 00 00 00 00 00 1.0 392 92 40 24 00 00 00 00 00 00 10.0 393 92 40 09 21 fb 54 44 2e ea 3.14159265359 394 92 bf f0 00 00 00 00 00 00 -1.0 396 B0 true 397 B1 false 398 B2 null 400 5. JSON-C 402 JSON-C (Compressed) permits numeric code values to be substituted for 403 strings and binary data. Tag codes MAY be 8, 16 or 32 bits long 404 encoded in network byte order. 406 Tag codes MUST be defined before they are referenced. A Tag code MAY 407 be defined before the corresponding data or string value is used or 408 at the same time that it is used. 410 A dictionary is a list of tag code definitions. An encoding MAY 411 incorporate definitions from a dictionary using the dict-hash 412 production. The dict hash production specifies a (positive) offset 413 value to be added to the entries in the dictionary followed by the 414 UDF fingerprint [draft-hallambaker-udf] of the dictionary to be used. 416 +------------+-----+-------+--------+-------------------------------+ 417 | Production | Tag | Fixed | Length | Data Description | 418 +------------+-----+-------+--------+-------------------------------+ 419 | c-tag | xC0 | 1 | - | 8 bit tag code | 420 | c-tag | xC1 | 2 | - | 16 bit tag code | 421 | c-tag | xC2 | 4 | - | 32 bit tag code | 422 | c-def | xC4 | 1 | - | 8 bit tag definition | 423 | c-def | xC5 | 2 | - | 16 bit tag definition | 424 | c-def | xC6 | 4 | - | 32 bit tag definition | 425 | c-tag | xC8 | 1 | - | 8 bit tag code and definition | 426 | c-tag | xC9 | 2 | - | 16 bit tag code and | 427 | | | | | definition | 428 | c-tag | xCA | 4 | - | 32 bit tag code and | 429 | | | | | definition | 430 | c-def | xCC | 1 | - | 8 bit tag dictionary | 431 | | | | | definition | 432 | c-def | xCD | 2 | - | 16 bit tag dictionary | 433 | | | | | definition | 434 | c-def | xCE | 4 | - | 32 bit tag dictionary | 435 | | | | | definition | 436 | dict-hash | xD0 | 4 | 1 | UDF fingerprint of dictionary | 437 +------------+-----+-------+--------+-------------------------------+ 439 Table 3 441 Table 3: Codes Used for Compression 443 All integer values are encoded in Network Byte Order (most 444 significant byte first). 446 5.1. JSON-C Examples 448 The following examples show examples of using JSON-C encoding: 450 C8 20 80 05 48 65 6c 6c 6f "Hello" 20 = "Hello" 451 C4 21 80 05 48 65 6c 6c 6f 21 = "Hello" 452 C0 20 "Hello" 453 C1 00 20 "Hello" 455 D0 00 00 01 00 20 Insert dictionary at code 256 456 e3 b0 c4 42 98 fc 1c 14 457 9a fb f4 c8 99 6f b9 24 458 27 ae 41 e4 64 9b 93 4c 459 a4 95 99 1b 78 52 b8 55 UDF (C4 21 80 05 48 65 6c 6c 6f) 461 6. JSON-D (Data) 463 JSON-B and JSON-C only support the two numeric types defined in the 464 JavaScript data model: Integers and 64 bit floating point values. 465 JSON-D (Data) defines binary encodings for additional data types that 466 are commonly used in scientific applications. These comprise 467 positive and negative 128 bit integers, six additional floating point 468 representations defined by IEEE 754 [IEEE754] and the Intel extended 469 precision 80 bit floating point representation [INTEL] . 471 Should the need arise, even bigger bignums could be defined with the 472 length specified as a 32 bit value permitting bignums of up to 2^35 473 bits to be represented. 475 d-value = d-integer | d-float 477 d-float = binary16 | binary32 | binary128 | binary80 | 478 decimal32 | decimal64 | decimal 128 480 The codes for these values are as follows: 482 +------------+-----+-------+--------+-------------------------------+ 483 | Production | Tag | Fixed | Length | Data Description | 484 +------------+-----+-------+--------+-------------------------------+ 485 | p-int128 | xA4 | 16 | - | Positive 128 bit Integer | 486 | n-int128 | xAC | 16 | - | Negative 128 bit Integer | 487 | binary16 | x90 | 2 | - | IEEE 754 Floating Point | 488 | | | | | Binary 16 bit | 489 | binary32 | x91 | 4 | - | IEEE 754 Floating Point | 490 | | | | | Binary 32 bit | 491 | binary128 | x94 | 16 | - | IEEE 754 Floating Point | 492 | | | | | Binary 64 bit | 493 | Intel80 | x95 | 10 | - | Intel extended Floating Point | 494 | | | | | 80 bit | 495 | decimal32 | x96 | 4 | - | IEEE 754 Floating Point | 496 | | | | | Decimal 32 | 497 | Decimal64 | x97 | 8 | - | IEEE 754 Floating Point | 498 | | | | | Decimal 64 | 499 | Decimal128 | x98 | 16 | - | IEEE 754 Floating Point | 500 | | | | | Decimal 128 | 501 +------------+-----+-------+--------+-------------------------------+ 503 Table 4 505 Table 4: Additional Codes for Scientific Data 507 7. JBCD Frames and Records 509 Tag codes in the range xF0-XFF are reserved for specifying markers 510 for frames and records. These tags are not used to encode JSON data, 511 they are only used to encapsulate opaque binary data blobs as a unit. 513 A JBCD record consists of consist of the tag, a length and the data 514 item. The length indication provided by the record format allows 515 efficient traversal of a sequence of records in the forward direction 516 only. 518 A JBCD Frames consists of consist of the tag, a length and the data 519 item followed by the tag-length sequence repeated with the bytes 520 written in the reverse order. The first length indication allows 521 efficient traversal of a sequence of records in the forward direction 522 and the second allows efficient traversal in the reverse direction. 524 [[This figure is not viewable in this format. The figure is 525 available at http://mathmesh.com/Documents/draft-hallambaker- 526 jsonbcd.html [3].]] 528 JBCD Records and Frames 530 The JBCD-Frame tags currently defined are: 532 +------------+---------+-------+--------+-----------------------+ 533 | Production | Tag | Fixed | Length | Data Description | 534 +------------+---------+-------+--------+-----------------------+ 535 | uframe | xF0 | - | 1 | Record, 8 bit length | 536 | uframe | xF1 | - | 2 | Record, 16 bit length | 537 | uframe | xF2 | - | 4 | Record, 32 bit length | 538 | uframe | xF3 | - | 8 | Record, 64 bit length | 539 | bframe | xF4 | - | 1 | Frame, 8 bit length | 540 | bframe | xF5 | - | 2 | Frame, 16 bit length | 541 | bframe | xF6 | - | 4 | Frame, 32 bit length | 542 | bframe | xF7 | - | 8 | Frame, 64 bit length | 543 | | xF8-xFF | - | - | Reserved | 544 +------------+---------+-------+--------+-----------------------+ 546 Table 5 548 The author does not expect additional framing tags to be added but 549 codes F8-FF are reserved in case this is desired. 551 It may prove convenient to represent message digest values as large 552 integers rather than binary strings. While very few platforms or 553 programming languages support mathematical operations on fixed size 554 integers larger than 64, this is not a major concern since message 555 digests are rarely used for any purpose other than comparison for 556 equality. 558 +------------+-----+-------+--------+--------------------------+ 559 | Production | Tag | Fixed | Length | Data Description | 560 +------------+-----+-------+--------+--------------------------+ 561 | p-int128 | Xa4 | 16 | - | Positive 128 bit Integer | 562 | p-int256 | Xa5 | 32 | - | Positive 256 bit Integer | 563 | p-int512 | Xa6 | 64 | - | Positive 512 bit Integer | 564 +------------+-----+-------+--------+--------------------------+ 566 Table 6 568 8. Acknowledgements 570 This work was assisted by conversations with Nico Williams and other 571 participants on the applications area mailing list. 573 9. Security Considerations 575 A correctly implemented data encoding mechanism should not introduce 576 new security vulnerabilities. However, experience demonstrates that 577 some data encoding approaches are more prone to introduce 578 vulnerabilities when incorrectly implemented than others. 580 In particular, whenever variable length data formats are used, the 581 possibility of a buffer overrun vulnerability is introduced. While 582 best practice suggests that a coding language with native mechanisms 583 for bounds checking is the best protection against such errors, such 584 approaches are not always followed. While such vulnerabilities are 585 most commonly seen in the design of decoders, it is possible for the 586 same vulnerabilities to be exploited in encoders. 588 A common source of such errors is the case where nested length 589 encodings are used. For example, a decoder relies on an outermost 590 length encoding that specifies a length on 50 bytes to allocate 591 memory for the entire result and then attempts to copy a string with 592 a declared length of 1000 bytes within the sequence. 594 The extensions to the JSON encoding described in this document are 595 designed to avoid such errors. Length encodings are only used to 596 define the length of x-value constructions which are always terminal 597 and cannot have nested data entries. 599 10. IANA Considerations 601 [TBS list out all the code points that require an IANA registration] 603 11. References 605 11.1. Normative References 607 [draft-hallambaker-udf] 608 Hallam-Baker, P., "Uniform Data Fingerprint (UDF)", draft- 609 hallambaker-udf-12 (work in progress), January 2019. 611 [IEEE754] IEEE Computer Society, "IEEE Standard for Floating-Point 612 Arithmetic", IEEE 754-2008, 613 DOI 10.1109/IEEESTD.2008.4610935, August 2008. 615 [INTEL] Intel Corp., "Unknown". 617 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 618 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 619 2014. 621 11.2. Informative References 623 [draft-hallambaker-mesh-architecture] 624 Hallam-Baker, P., "Mathematical Mesh Part I: Architecture 625 Guide", draft-hallambaker-mesh-architecture-06 (work in 626 progress), August 2018. 628 11.3. URIs 630 [1] http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html 632 [2] http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html 634 [3] http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html 636 Author's Address 638 Phillip Hallam-Baker 640 Email: phill@hallambaker.com