A Media Type Structured Syntax Suffix for JSON Text Sequences
CA Technologies
erik.wilde@dret.net
http://dret.net/netdret/
example
Structured syntax suffixes for media types allow other media types
to build on them and make it explicit that they are built on an
existing media type as their foundation. This specification defines
and registers "+json-seq" as a structured syntax suffix for JSON text
sequences.
Media type structured syntax suffixes
were introduced as a way for a media type to signal that it is based
on another media type as its foundation. Some structured syntax
suffixes were registered initially ,
including "+json", for the widely popular JSON format .
JSON text sequences is a recent
specification in the JSON space that defines how a sequence of
multiple JSON texts can be represented in one representation. This
document defines and registers the "+json-seq" structured syntax
suffix in the "Structured Syntax Suffix Registry".
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 .
The use case for the "+json-seq" structured syntax suffix is the
same as for "+json": It SHOULD be used by media types when parsing
the JSON text sequence of a media type leads to a meaningful result,
by simply using the generic JSON text sequence processing.
Applications encountering such a media type can then either simply
use generic processing if all they need is a generic view of the JSON
text sequence, or they can use generic JSON text sequence tools for
initial parsing and then implement their own specific processing
on top of that generic parsing tool.
Structured Syntax Suffixes are registered within the "Structured
Syntax Suffix Registry" maintained at .
IANA has registered the "+json-seq" structured syntax
suffix in accordance with .
Name: JSON Text Sequence
+suffix: +json-seq
References: , RFC 8091
Encoding considerations: See Section 2.2
Fragment identifier considerations: The syntax and semantics
of fragment identifiers specified for +json-seq SHOULD be as
specified for "application/json-seq". (At publication of this
document, there is no fragment identification syntax defined
for "application/json-seq".)
The syntax and semantics for fragment identifiers for a
specific "xxx/yyy+json-seq" SHOULD be processed as
follows:
For cases defined in +json-seq, where the fragment
identifier resolves per the +json-seq rules, then
process as specified in +json-seq.
For cases defined in +json-seq, where the fragment
identifier does not resolve per the +json-seq rules,
then process as specified in "xxx/yyy+json-seq".
For cases not defined in +json-seq, then process as
specified in "xxx/yyy+json-seq".
Interoperability considerations: n/a
Security considerations: See Section 3
Contact: Applications and Real-Time Area Discussion
(art@ietf.org), or any IESG-designated successor.
Author/Change controller: The Applications and Real-Time
Area Working Group. IESG has change control over this
registration.
All the security considerations of JSON text sequences apply. They are as follows:
All the security considerations of JSON
apply. This format provides no cryptographic integrity protection of
any kind.
As usual, parsers must operate on input that is assumed to be
untrusted. This means that parsers must fail gracefully in the face
of malicious inputs.
Note that incremental JSON text parsers can produce partial
results and later indicate failure to parse the remainder of a
text. A sequence parser that uses an incremental JSON text parser
might treat a sequence like '<RS>"foo"<LF>456<LF><RS>' as
a sequence of one element ("foo"), while a sequence parser that uses
a non-incremental JSON text parser might treat the same sequence as
being empty. This effect, and texts that fail to parse and are
ignored, can be used to smuggle data past sequence parsers that don't
warn about JSON text failures.
Repeated parsing and re-encoding of a JSON text sequence can
result in the addition (or stripping) of trailing LF bytes from (to)
individual sequence element JSON texts. This can break signature
validation. JSON has no canonical form for JSON texts, therefore
neither does the JSON text sequence format.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Media Type Specifications and Registration Procedures
This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.
JavaScript Object Notation (JSON) Text Sequences
This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A).
The JavaScript Object Notation (JSON) Data Interchange Format
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.
Additional Media Type Structured Syntax Suffixes
A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. This document is not an Internet Standards Track specification; it is published for informational purposes.
Thanks for comments and suggestions provided by Ben Campbell, Allan Doyle, Warren Kumari, Sean Leonard, Alexey Melnikov, Brian Raymor, and Peter Yee.