idnits 2.17.1 draft-williams-json-text-sequence-00.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 (March 14, 2014) is 3686 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Williams 3 Internet-Draft Cryptonector 4 Intended status: Standards Track March 14, 2014 5 Expires: September 15, 2014 7 JavaScript Object Notation (JSON) Text Sequences 8 draft-williams-json-text-sequence-00 10 Abstract 12 This document describes the JSON text sequence format and associated 13 media type. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 15, 2014. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 50 1.1. Conventions used in this document . . . . . . . . . . . . . . 3 51 2. JSON Text Sequence Format . . . . . . . . . . . . . . . . . . 4 52 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 54 5. Normative References . . . . . . . . . . . . . . . . . . . . 7 55 Author's Address . . . . . . . . . . . . . . . . . . . . . . 8 57 1. Introduction and Motivation 59 The JavaScript Object Notation (JSON) [RFC7159] is a very handy 60 serialization format. However, when serializing a large sequence of 61 values as an array, or a possibly indeterminate-length or never- 62 ending sequence of values, JSON becomes difficult to work with. 64 Consider a sequence of one million values, each possibly 1 kilobyte 65 when encoded, which would be roughly one gigabyte. If processing 66 such a dataset requires first parsing it entirely, then the result is 67 very inefficient and the processing will be limited by virtual 68 memory. "Online" parsers help, but they are neither widely available 69 or widely used, nor are they easy to use. 71 Ideally such datasets could be parsed and processed one element at a 72 time. Even if each element must be parsed in a not-online manner due 73 to local choice of parser, the result will usually be sufficiently 74 online: limited by the size of the biggest element in the sequence 75 rather than by the size of the sequence. 77 This document describes the concept and format of "JSON text 78 sequences", which are specifically not JSON texts themselves. 80 1.1. Conventions used in this document 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 2. JSON Text Sequence Format 88 The ABNF [RFC5234] for the JSON text sequence format is as follows: 90 JSON-sequence = *(JSON-text 1*(text-separator)) 91 text-separator = %x20 / %x09 / %x0A / %x0D / %2C 92 JSON-text = 94 Figure 1: JSON text sequence ABNF 96 A JSON text sequence is a sequence of JSON texts, each followed by 97 JSON whitespace (see the 'ws' rule in the JSON ABNF) separator. 99 Requirements: 101 o Encoders MUST emit one or more JSON whitespace separator 102 characters after each JSON text in a sequence. Two contiguous 103 separators do not denote an empty JSON text between them. 105 o Parsers MUST be able to parser a JSON text sequence consisting of 106 JSON texts which do not contain newlines (except, of course, 107 escaped within strings), and which are separated by either 108 newlines, or carriage return and newline character pairs (U+000D 109 U+000A). 111 Recommendations: 113 o Parsers SHOULD NOT emit outputs which do not correspond to arrays, 114 objects or strings until the separator is read. For example, an 115 input of 'truefalse' is not a valid sequence of two JSON values, 116 true and false! Neither is 'true0' a valid sequence of true and 117 zero. Some parsers might in fact accept such sequences, which 118 creates an ambiguity that is resolved by requiring (see above) 119 that encoders never omit the separator. 121 Options: 123 o Parsers MAY parse sequences where the separator is missing between 124 any two consecutive texts provided that no ambiguity results 125 (namely: when the first of the two texts is an array, an object, 126 or a string). 128 o Encoders MAY have an option for encoding JSON texts "compactly", 129 without using newlines in the encoding. This maximizes 130 interoperability with JSON text sequence parsers that utilize non- 131 incremental, non-online JSON text parsers. 133 3. Security Considerations 135 All the security considerations of JSON [RFC7159] apply. 137 JSON text sequence parsers based on non-incremental, non-online JSON 138 text parsers will not be able to efficiently parser JSON texts in 139 which newlines appear; attempting to parse such sequences with non- 140 incremental, non-online JSON text parsers creates a compute resource 141 exhaustion vulnerability. 143 Parsers which accidentally parse invalid sequences like 'truefalse' 144 (as the same as 'true\nfalse') create a mildly dangerous ambiguity. 145 Encoders must never produce such sequences; parsers should not accept 146 them. 148 4. IANA Considerations 150 The MIME media type for JSON text sequences is application/json-seq. 152 Type name: application 154 Subtype name: json-seq 156 Required parameters: n/a 158 Optional parameters: n/a 160 Encoding considerations: binary 162 Security considerations: See , 163 Section 3. 165 Interoperability considerations: Described herein. 167 Published specification: . 169 Applications that use this media type: JSON text sequences have been 170 used in applications written with the jq programming language. 172 5. Normative References 174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 175 Requirement Levels", BCP 14, RFC 2119, March 1997. 177 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 178 Specifications: ABNF", STD 68, RFC 5234, January 2008. 180 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 181 Interchange Format", RFC 7159, March 2014. 183 Author's Address 185 Nicolas Williams 186 Cryptonector, LLC 188 Email: nico@cryptonector.com