Internet Engineering Task Force (IETF) S. Gillies Request for Comments: 8142 Mapbox Category: Standards Track April 2017 ISSN: 2070-1721
GeoJSON Text Sequences
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document describes a specialization of JSON text sequences. A GeoJSON text sequence is a document of arbitrarily large size containing one or more GeoJSON objects (e.g., multiple GeoJSON texts that can be produced and parsed incrementally) and not just a single GeoJSON FeatureCollection, Feature, or Geometry.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Defined in prose similar to the description of the JSON text sequence in [RFC7464], a GeoJSON text sequence is any number of GeoJSON [RFC7946] texts, each encoded in UTF-8 [RFC3629], preceded by one ASCII [RFC20] record separator (RS) character, and followed by a line feed (LF).
The GeoJSON text sequence format conforms to all the rules of [RFC7464] and adds the following constraint: each JSON text MUST contain a single GeoJSON object as defined in [RFC7946].
Gillies Standards Track [Page 2]
RFC 8142 GeoJSON Text Sequences April 2017
Heterogeneous sequences containing a mix of GeoJSON Geometry, Feature, and FeatureCollection objects are permitted. How producers and parsers of GeoJSON text sequences communicate rules for allowed GeoJSON types in exchanged sequences is not specified in this document.
The advantage of using ASCII character RS "0x1e" to denote a text is that sequence producers and parsers need not enforce a canonical form of GeoJSON. Any valid GeoJSON, pretty-printed or compact, can be used in a GeoJSON text sequence.
A variety of parsers designed for newline-delimited sequences of compact JSON text are deployed on the internet today. While there is no canonical form for JSON texts, and pretty-printed and compact forms are equally valid, GeoJSON text sequences containing compact GeoJSON texts with no internal newlines are more interoperable with existing non-standardized parsers.
In a distributed system where order and exactly-once delivery of messages are difficult to achieve, GeoJSON text sequences that do not rely on order of texts for extra semantics are more interoperable than those that do.