idnits 2.17.1 draft-hallambaker-jsonbcd-12.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 (May 24, 2018) is 2157 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 644 -- Looks like a reference, but probably isn't: '2' on line 646 == Missing Reference: 'RFC2119' is mentioned on line 179, but not defined -- Looks like a reference, but probably isn't: '3' on line 648 ** 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 Comodo Group Inc. 4 Intended status: Informational May 24, 2018 5 Expires: November 25, 2018 7 Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D 8 draft-hallambaker-jsonbcd-12 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 November 25, 2018. 42 Copyright Notice 44 Copyright (c) 2018 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 Figure 1 254 The following lexical values are unchanged: 255 begin-array = ws %x5B ws ; [ left square bracket 256 begin-object = ws %x7B ws ; { left curly bracket 257 end-array = ws %x5D ws ; ] right square bracket 258 end-object = ws %x7D ws ; } right curly bracket 260 ws = *( %x20 %x09 %x0A %x0D ) 262 false = %x66.61.6c.73.65 ; false 263 null = %x6e.75.6c.6c ; null 264 true = %x74.72.75.65 ; true 266 Figure 2 268 The productions number and string are defined as before: 270 number = [ minus ] int [ frac ] [ exp ] 271 decimal-point = %x2E ; . 272 digit1-9 = %x31-39 ; 1-9 273 e = %x65 / %x45 ; e E 274 exp = e [ minus / plus ] 1*DIGIT 275 frac = decimal-point 1*DIGIT 276 int = zero / ( digit1-9 *DIGIT ) 277 minus = %x2D ; - 278 plus = %x2B ; + 279 zero = %x30 ; 0 281 string = quotation-mark *char quotation-mark 282 char = unescaped / 283 escape ( %x22 / %x5C / %x2F / %x62 / %x66 / 284 %x6E / %x72 / %x74 / %x75 4HEXDIG ) 286 escape = %x5C ; \ 287 quotation-mark = %x22 ; " 288 unescaped = %x20-21 / %x23-5B / %x5D-10FFFF 290 Figure 3 292 4. JSON-B 294 The JSON-B encoding defines the b-value and b-string productions: 296 b-value = b-atom | b-string | b-data | b-integer | 297 b-float 299 b-string = *( string-chunk ) string-term 300 b-data = *( data-chunk ) data-last 302 b-integer = p-int8 | p-int16 | p-int32 | p-int64 | p-bignum16 | 303 n-int8 | n-int16 | n-int32 | n-int64 | n-bignum16 305 b-float = binary64 307 Figure 4 309 The lexical encodings of the productions are defined in the following 310 tables where the column 'tag' specifies the byte code that begins the 311 production, 'Fixed' specifies the number of data bytes that follow 312 and 'Length' specifies the number of bytes used to define the length 313 of a variable length field following the data bytes: 315 +--------------+-----+-------+--------+-----------------------------+ 316 | Production | Tag | Fixed | Length | Data Description | 317 +--------------+-----+-------+--------+-----------------------------+ 318 | string-term | x80 | - | 1 | Terminal String 8 bit | 319 | | | | | length | 320 | string-term | x81 | - | 2 | Terminal String 16 bit | 321 | | | | | length | 322 | string-term | x82 | - | 4 | Terminal String 32 bit | 323 | | | | | length | 324 | string-term | x83 | - | 8 | Terminal String 64 bit | 325 | | | | | length | 326 | string-chunk | x84 | - | 1 | Terminal String 8 bit | 327 | | | | | length | 328 | string-chunk | x85 | - | 2 | Terminal String 16 bit | 329 | | | | | length | 330 | string-chunk | x86 | - | 4 | Terminal String 32 bit | 331 | | | | | length | 332 | string-chunk | x87 | - | 8 | Terminal String 64 bit | 333 | | | | | length | 334 | data-term | x88 | - | 1 | Terminal String 8 bit | 335 | | | | | length | 336 | data-term | x89 | - | 2 | Terminal String 16 bit | 337 | | | | | length | 338 | data-term | x8A | - | 4 | Terminal String 32 bit | 339 | | | | | length | 340 | data-term | x8B | - | 8 | Terminal String 64 bit | 341 | | | | | length | 342 | data-term | X8C | - | 1 | Terminal String 8 bit | 343 | | | | | length | 344 | data-term | x8D | - | 2 | Terminal String 16 bit | 345 | | | | | length | 346 | data-term | x8E | - | 4 | Terminal String 32 bit | 347 | | | | | length | 348 | data-term | x8F | - | 8 | Terminal String 64 bit | 349 | | | | | length | 350 +--------------+-----+-------+--------+-----------------------------+ 352 Table 1 354 Table 1: Codes for String and Data items 355 +------------+-----+-------+--------+-------------------------------+ 356 | Production | Tag | Fixed | Length | Data Description | 357 +------------+-----+-------+--------+-------------------------------+ 358 | p-int8 | xA0 | 1 | - | Positive 8 bit Integer | 359 | p-int16 | xa1 | 2 | - | Positive 16 bit Integer | 360 | p-int32 | xa2 | 4 | - | Positive 32 bit Integer | 361 | p-int64 | xa3 | 8 | - | Positive 64 bit Integer | 362 | p-bignum16 | Xa7 | - | 2 | Positive Bignum | 363 | n-int8 | xA8 | 1 | - | Negative 8 bit Integer | 364 | n-int16 | xA9 | 2 | - | Negative 16 bit Integer | 365 | n-int32 | xAA | 4 | - | Negative 32 bit Integer | 366 | n-int64 | xAB | 8 | - | Negative 64 bit Integer | 367 | n-bignum16 | xAF | - | 2 | Negative Bignum | 368 | binary64 | x92 | 8 | - | IEEE 754 Floating Point | 369 | | | | | Binary 64 bit | 370 | b-value | xB0 | - | - | True | 371 | b-value | xB1 | - | - | False | 372 | b-value | xB2 | - | - | Null | 373 +------------+-----+-------+--------+-------------------------------+ 375 Table 2 377 Table 2: Codes for Integers, 64 Bit Floating Point, Boolean and Null 378 items. 380 A data type commonly used in networking that is not defined in this 381 scheme is a datetime representation. To define such a data type, a 382 string containing a date-time value in Internet type format is 383 typically used. 385 4.1. JSON-B Examples 387 The following examples show examples of using JSON-B encoding: 389 A0 2A 42 (as 8 bit integer) 390 A1 00 2A 42 (as 16 bit integer) 391 A2 00 00 00 2A 42 (as 32 bit integer) 392 A3 00 00 00 00 00 00 00 2A 42 (as 64 bit integer) 393 A5 00 01 42 42 (as Bignum) 395 80 05 48 65 6c 6c 6f "Hello" (single chunk) 396 81 00 05 48 65 6c 6c 6f "Hello" (single chunk) 397 84 05 48 65 6c 6c 6f 80 00 "Hello" (as two chunks) 399 92 3f f0 00 00 00 00 00 00 1.0 400 92 40 24 00 00 00 00 00 00 10.0 401 92 40 09 21 fb 54 44 2e ea 3.14159265359 402 92 bf f0 00 00 00 00 00 00 -1.0 404 B0 true 405 B1 false 406 B2 null 408 Figure 5 410 5. JSON-C 412 JSON-C (Compressed) permits numeric code values to be substituted for 413 strings and binary data. Tag codes MAY be 8, 16 or 32 bits long 414 encoded in network byte order. 416 Tag codes MUST be defined before they are referenced. A Tag code MAY 417 be defined before the corresponding data or string value is used or 418 at the same time that it is used. 420 A dictionary is a list of tag code definitions. An encoding MAY 421 incorporate definitions from a dictionary using the dict-hash 422 production. The dict hash production specifies a (positive) offset 423 value to be added to the entries in the dictionary followed by the 424 UDF fingerprint [draft-hallambaker-udf] of the dictionary to be used. 426 +------------+-----+-------+--------+-------------------------------+ 427 | Production | Tag | Fixed | Length | Data Description | 428 +------------+-----+-------+--------+-------------------------------+ 429 | c-tag | xC0 | 1 | - | 8 bit tag code | 430 | c-tag | xC1 | 2 | - | 16 bit tag code | 431 | c-tag | xC2 | 4 | - | 32 bit tag code | 432 | c-def | xC4 | 1 | - | 8 bit tag definition | 433 | c-def | xC5 | 2 | - | 16 bit tag definition | 434 | c-def | xC6 | 4 | - | 32 bit tag definition | 435 | c-tag | xC8 | 1 | - | 8 bit tag code and definition | 436 | c-tag | xC9 | 2 | - | 16 bit tag code and | 437 | | | | | definition | 438 | c-tag | xCA | 4 | - | 32 bit tag code and | 439 | | | | | definition | 440 | c-def | xCC | 1 | - | 8 bit tag dictionary | 441 | | | | | definition | 442 | c-def | xCD | 2 | - | 16 bit tag dictionary | 443 | | | | | definition | 444 | c-def | xCE | 4 | - | 32 bit tag dictionary | 445 | | | | | definition | 446 | dict-hash | xD0 | 4 | 1 | UDF fingerprint of dictionary | 447 +------------+-----+-------+--------+-------------------------------+ 449 Table 3 451 Table 3: Codes Used for Compression 453 All integer values are encoded in Network Byte Order (most 454 significant byte first). 456 5.1. JSON-C Examples 458 The following examples show examples of using JSON-C encoding: 460 C8 20 80 05 48 65 6c 6c 6f "Hello" 20 = "Hello" 461 C4 21 80 05 48 65 6c 6c 6f 21 = "Hello" 462 C0 20 "Hello" 463 C1 00 20 "Hello" 465 D0 00 00 01 00 20 Insert dictionary at code 256 466 e3 b0 c4 42 98 fc 1c 14 467 9a fb f4 c8 99 6f b9 24 468 27 ae 41 e4 64 9b 93 4c 469 a4 95 99 1b 78 52 b8 55 UDF (C4 21 80 05 48 65 6c 6c 6f) 471 Figure 6 473 6. JSON-D (Data) 475 JSON-B and JSON-C only support the two numeric types defined in the 476 JavaScript data model: Integers and 64 bit floating point values. 477 JSON-D (Data) defines binary encodings for additional data types that 478 are commonly used in scientific applications. These comprise 479 positive and negative 128 bit integers, six additional floating point 480 representations defined by IEEE 754 [IEEE754] and the Intel extended 481 precision 80 bit floating point representation [INTEL] . 483 Should the need arise, even bigger bignums could be defined with the 484 length specified as a 32 bit value permitting bignums of up to 2^35 485 bits to be represented. 487 d-value = d-integer | d-float 489 d-float = binary16 | binary32 | binary128 | binary80 | 490 decimal32 | decimal64 | decimal 128 492 Figure 7 494 The codes for these values are as follows: 496 +------------+-----+-------+--------+-------------------------------+ 497 | Production | Tag | Fixed | Length | Data Description | 498 +------------+-----+-------+--------+-------------------------------+ 499 | p-int128 | xA4 | 16 | - | Positive 128 bit Integer | 500 | n-int128 | xAC | 16 | - | Negative 128 bit Integer | 501 | binary16 | x90 | 2 | - | IEEE 754 Floating Point | 502 | | | | | Binary 16 bit | 503 | binary32 | x91 | 4 | - | IEEE 754 Floating Point | 504 | | | | | Binary 32 bit | 505 | binary128 | x94 | 16 | - | IEEE 754 Floating Point | 506 | | | | | Binary 64 bit | 507 | Intel80 | x95 | 10 | - | Intel extended Floating Point | 508 | | | | | 80 bit | 509 | decimal32 | x96 | 4 | - | IEEE 754 Floating Point | 510 | | | | | Decimal 32 | 511 | Decimal64 | x97 | 8 | - | IEEE 754 Floating Point | 512 | | | | | Decimal 64 | 513 | Decimal128 | x98 | 16 | - | IEEE 754 Floating Point | 514 | | | | | Decimal 128 | 515 +------------+-----+-------+--------+-------------------------------+ 517 Table 4 519 Table 4: Additional Codes for Scientific Data 521 7. JBCD Frames and Records 523 Tag codes in the range xF0-XFF are reserved for specifying markers 524 for frames and records. These tags are not used to encode JSON data, 525 they are only used to encapsulate opaque binary data blobs as a unit. 527 A JBCD record consists of consist of the tag, a length and the data 528 item. The length indication provided by the record format allows 529 efficient traversal of a sequence of records in the forward direction 530 only. 532 A JBCD Frames consists of consist of the tag, a length and the data 533 item followed by the tag-length sequence repeated with the bytes 534 written in the reverse order. The first length indication allows 535 efficient traversal of a sequence of records in the forward direction 536 and the second allows efficient traversal in the reverse direction. 538 [[This figure is not viewable in this format. The figure is 539 available at http://mathmesh.com/Documents/draft-hallambaker- 540 jsonbcd.html [3].]] 542 JBCD Records and Frames 544 The JBCD-Frame tags currently defined are: 546 +------------+---------+-------+--------+-----------------------+ 547 | Production | Tag | Fixed | Length | Data Description | 548 +------------+---------+-------+--------+-----------------------+ 549 | uframe | xF0 | - | 1 | Record, 8 bit length | 550 | uframe | xF1 | - | 2 | Record, 16 bit length | 551 | uframe | xF2 | - | 4 | Record, 32 bit length | 552 | uframe | xF3 | - | 8 | Record, 64 bit length | 553 | bframe | xF4 | - | 1 | Frame, 8 bit length | 554 | bframe | xF5 | - | 2 | Frame, 16 bit length | 555 | bframe | xF6 | - | 4 | Frame, 32 bit length | 556 | bframe | xF7 | - | 8 | Frame, 64 bit length | 557 | | xF8-xFF | - | - | Reserved | 558 +------------+---------+-------+--------+-----------------------+ 560 Table 5 562 The author does not expect additional framing tags to be added but 563 codes F8-FF are reserved in case this is desired. 565 It may prove convenient to represent message digest values as large 566 integers rather than binary strings. While very few platforms or 567 programming languages support mathematical operations on fixed size 568 integers larger than 64, this is not a major concern since message 569 digests are rarely used for any purpose other than comparison for 570 equality. 572 +------------+-----+-------+--------+--------------------------+ 573 | Production | Tag | Fixed | Length | Data Description | 574 +------------+-----+-------+--------+--------------------------+ 575 | p-int128 | Xa4 | 16 | - | Positive 128 bit Integer | 576 | p-int256 | Xa5 | 32 | - | Positive 256 bit Integer | 577 | p-int512 | Xa6 | 64 | - | Positive 512 bit Integer | 578 +------------+-----+-------+--------+--------------------------+ 580 Table 6 582 8. Acknowledgements 584 This work was assisted by conversations with Nico Williams and other 585 participants on the applications area mailing list. 587 9. Security Considerations 589 A correctly implemented data encoding mechanism should not introduce 590 new security vulnerabilities. However, experience demonstrates that 591 some data encoding approaches are more prone to introduce 592 vulnerabilities when incorrectly implemented than others. 594 In particular, whenever variable length data formats are used, the 595 possibility of a buffer overrun vulnerability is introduced. While 596 best practice suggests that a coding language with native mechanisms 597 for bounds checking is the best protection against such errors, such 598 approaches are not always followed. While such vulnerabilities are 599 most commonly seen in the design of decoders, it is possible for the 600 same vulnerabilities to be exploited in encoders. 602 A common source of such errors is the case where nested length 603 encodings are used. For example, a decoder relies on an outermost 604 length encoding that specifies a length on 50 bytes to allocate 605 memory for the entire result and then attempts to copy a string with 606 a declared length of 1000 bytes within the sequence. 608 The extensions to the JSON encoding described in this document are 609 designed to avoid such errors. Length encodings are only used to 610 define the length of x-value constructions which are always terminal 611 and cannot have nested data entries. 613 10. IANA Considerations 615 [TBS list out all the code points that require an IANA registration] 617 11. References 619 11.1. Normative References 621 [draft-hallambaker-udf] 622 Hallam-Baker, P., "Uniform Data Fingerprint (UDF)", draft- 623 hallambaker-udf-10 (work in progress), April 2018. 625 [IEEE754] IEEE Computer Society, "IEEE Standard for Floating-Point 626 Arithmetic", IEEE 754-2008, 627 DOI 10.1109/IEEESTD.2008.4610935, August 2008. 629 [INTEL] Intel Corp., "Unknown". 631 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 632 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 633 2014. 635 11.2. Informative References 637 [draft-hallambaker-mesh-architecture] 638 Hallam-Baker, P., "Mathematical Mesh: Architecture", 639 draft-hallambaker-mesh-architecture-04 (work in progress), 640 September 2017. 642 11.3. URIs 644 [1] http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html 646 [2] http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html 648 [3] http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html 650 Author's Address 652 Phillip Hallam-Baker 653 Comodo Group Inc. 655 Email: philliph@comodo.com