idnits 2.17.1 draft-ietf-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 (April 28, 2014) is 3650 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 json N. Williams 3 Internet-Draft Cryptonector 4 Intended status: Standards Track April 28, 2014 5 Expires: October 30, 2014 7 JavaScript Object Notation (JSON) Text Sequences 8 draft-ietf-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 October 30, 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" (a.k.a., "streaming") parsers help, but they are 69 neither widely available 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 but are 79 composed of JSON texts. 81 1.1. Conventions used in this document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. JSON Text Sequence Format 89 The ABNF [RFC5234] for the JSON text sequence format is as follows: 91 JSON-sequence = *(JSON-text 1*(ws)) 92 ws = %x20 / %x09 / %x0A / %x0D 93 JSON-text = 95 Figure 1: JSON text sequence ABNF 97 A JSON text sequence is a sequence of JSON texts, each followed by 98 JSON whitespace (see the 'ws' rule in the JSON ABNF) separator. 100 Requirements: 102 o JSON text sequence encoders MUST emit one or more JSON whitespace 103 separator characters immediately after any JSON text. 105 o JSON text sequence parsers MUST NOT interpret any sequence of two 106 or more contiguous whitespace as a sequence of empty JSON texts. 107 Two contiguous separators do not denote an empty JSON text between 108 them as there is no such thing as an empty JSON text. 110 An input of 'truefalse' is not a valid sequence of two JSON values, 111 true and false! Neither is 'true0' a valid sequence of true and 112 zero. Some existing JSON parsers that might be used to construct 113 sequence parsers might in fact accept such sequences, erroneous 114 parsing when of sequences of two or more numbers. E.g., a sequence 115 of two numbers, 4 and 2, encoded without the required whitespace 116 between them would parse incorrectly as the number 42. This 117 ambiguity is resolved by requiring that encoders never omit the 118 separator. 120 3. Security Considerations 122 All the security considerations of JSON [RFC7159] apply. 124 There is no end of sequence indicator. This means that "end of 125 file", "end of transmission", and so on, can be indistinguishable 126 form a logical end of sequence. Applications where this matters 127 should denote end of sequence by convention (e.g., Content-Length in 128 HTTP). 130 JSON text sequence parsers based on non-incremental, non-online JSON 131 text parsers will not be able to efficiently parser JSON texts in 132 which newlines appear; attempting to parse such sequences with non- 133 incremental, non-online JSON text parsers creates a compute resource 134 exhaustion vulnerability. 136 The first requirement given in Section 2 (otherwise-ambiguous JSON 137 texts must be separated by whitespace) is critical and must be 138 adhered to. It is best to always emit a whitespace separator after 139 every JSON text emitted. 141 4. IANA Considerations 143 The MIME media type for JSON text sequences is application/json-seq. 145 Type name: application 147 Subtype name: json-seq 149 Required parameters: n/a 151 Optional parameters: n/a 153 Encoding considerations: binary 155 Security considerations: See , 156 Section 3. 158 Interoperability considerations: Described herein. 160 Published specification: . 162 Applications that use this media type: JSON text sequences have been 163 used in applications written with the jq programming language. 165 5. Normative References 167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 168 Requirement Levels", BCP 14, RFC 2119, March 1997. 170 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 171 Specifications: ABNF", STD 68, RFC 5234, January 2008. 173 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 174 Interchange Format", RFC 7159, March 2014. 176 Author's Address 178 Nicolas Williams 179 Cryptonector, LLC 181 Email: nico@cryptonector.com