One document matched: draft-williams-json-text-sequence-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc5234 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY rfc7159 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7159.xml">
]>
<rfc docName="draft-williams-json-text-sequence-00" ipr="trust200902" category="std">
  <front>
    <title abbrev="JSON Text Sequences">JavaScript Object Notation (JSON) Text Sequences</title>
    <author initials="N." surname="Williams" fullname="Nicolas Williams">
      <organization abbrev="Cryptonector">Cryptonector, LLC</organization>
      <address>
        <email>nico@cryptonector.com</email>
      </address>
    </author>
    <date month="March" year="2014"/>
    <area>
Apps Area
</area>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>
This document describes the JSON text sequence format and associated media type.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction and Motivation" anchor="d1e170">
      <t>
The JavaScript Object Notation (JSON) <xref target="RFC7159"/> is a very handy serialization format. However, when serializing a large sequence of values as an array, or a possibly indeterminate-length or never-ending sequence of values, JSON becomes difficult to work with.</t>
      <t>
Consider a sequence of one million values, each possibly 1 kilobyte when encoded, which would be roughly one gigabyte. If processing such a dataset requires first parsing it entirely, then the result is very inefficient and the processing will be limited by virtual memory. “Online” parsers help, but they are neither widely available or widely used, nor are they easy to use.</t>
      <t>
Ideally such datasets could be parsed and processed one element at a time. Even if each element must be parsed in a not-online manner due to local choice of parser, the result will usually be sufficiently online: limited by the size of the biggest element in the sequence rather than by the size of the sequence.</t>
      <t>
This document describes the concept and format of “JSON text sequences”, which are specifically not JSON texts themselves.</t>
      <section title="Conventions used in this document" anchor="d1e194">
        <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
      </section>
    </section>
    <section title="JSON Text Sequence Format" anchor="d1e209">
      <t>
The ABNF <xref target="RFC5234"/> for the JSON text sequence format is as follows:</t>
      <t>
</t>
      <t>
        <figure anchor="magicparlabel-104" title="JSON text sequence ABNF">
          <artwork>  JSON-sequence = *(JSON-text 1*(text-separator))
  text-separator = %x20 / %x09 / %x0A / %x0D / %2C
  JSON-text = <given by RFC7159></artwork>
        </figure>
      </t>
      <t>
A JSON text sequence is a sequence of JSON texts, each followed by JSON whitespace (see the 'ws' rule in the JSON ABNF) separator.</t>
      <t>
Requirements:</t>
      <t>
        <list style="symbols">
          <t>
Encoders MUST emit one or more JSON whitespace separator characters after each JSON text in a sequence. Two contiguous separators do not denote an empty JSON text between them.</t>
          <t>
Parsers MUST be able to parser a JSON text sequence consisting of JSON texts which do not contain newlines (except, of course, escaped within strings), and which are separated by either newlines, or carriage return and newline character pairs (U+000D U+000A).</t>
        </list>
      </t>
      <t>
Recommendations:</t>
      <t>
        <list style="symbols">
          <t>
Parsers SHOULD NOT emit outputs which do not correspond to arrays, objects or strings until the separator is read. For example, an input of 'truefalse' is not a valid sequence of two JSON values, true and false! Neither is 'true0' a valid sequence of true and zero. Some parsers might in fact accept such sequences, which creates an ambiguity that is resolved by requiring (see above) that encoders never omit the separator.</t>
        </list>
      </t>
      <t>
Options:</t>
      <t>
        <list style="symbols">
          <t>
Parsers MAY parse sequences where the separator is missing between any two consecutive texts provided that no ambiguity results (namely: when the first of the two texts is an array, an object, or a string).</t>
          <t>
Encoders MAY have an option for encoding JSON texts “compactly”, without using newlines in the encoding. This maximizes interoperability with JSON text sequence parsers that utilize non-incremental, non-online JSON text parsers.</t>
        </list>
      </t>
    </section>
    <section title="Security Considerations" anchor="sec_Security_Considerations">
      <t>
All the security considerations of JSON <xref target="RFC7159"/> apply.</t>
      <t>
JSON text sequence parsers based on non-incremental, non-online JSON text parsers will not be able to efficiently parser JSON texts in which newlines appear; attempting to parse such sequences with non-incremental, non-online JSON text parsers creates a compute resource exhaustion vulnerability.</t>
      <t>
Parsers which accidentally parse invalid sequences like 'truefalse' (as the same as 'true\nfalse') create a mildly dangerous ambiguity. Encoders must never produce such sequences; parsers should not accept them.</t>
    </section>
    <section title="IANA Considerations" anchor="sec_IANA_Considerations">
      <t>
The MIME media type for JSON text sequences is application/json-seq.</t>
      <t>
Type name: application</t>
      <t>
Subtype name: json-seq</t>
      <t>
Required parameters: n/a</t>
      <t>
Optional parameters: n/a</t>
      <t>
Encoding considerations: binary</t>
      <t>
Security considerations: See <this document, once published>,  <xref target="sec_Security_Considerations"/>.</t>
      <t>
Interoperability considerations: Described herein.</t>
      <t>
Published specification: <this document, once published>.</t>
      <t>
Applications that use this media type: JSON text sequences have been used in applications written with the jq programming language.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">&rfc2119;
&rfc5234;
&rfc7159;
</references>
  </back>
</rfc>