[Json] discoverability of separators in draft-ietf-json-text-sequence

["Joe Hildebrand (jhildebr)" <[e-mail]>]

What if you could use basically any separator you wanted in a text
sequence, every sequence MUST start with that separator, and we gave
suggestions for ones we think would work with some text about the
trade-offs?

Processors would read up to the first [, {, ", n, t, f, ., -, or number,
and treat that as the separator (potentially ignoring an irrational BOM if
they like).  The separator MUST be escaped in any of the JSON texts in the
sequence.  Whenever the separator is read, a new JSON text starts
immediately after it.  Any pending text that was not (yet) a valid JSON
text that was waiting to be processed when the separator is encountered
signifies a write error, and MAY be ignored.  Whitespace could trail a
JSON text before the next separator, which could be ignored according to
the previous rule.

ABNF such as:

JSON-sequence = *(sep value ignorable-ws)
sep = 1*(not [{"ntf.-0123456789)
ignorable-ws = ws
ws = <given by RFC7159>
     value = <given by RFC7159>

The other syntactically valid characters in a JSON text should probably be
forbidden in a separator as well.

Alternately, we could decide that the separator was always exactly one
byte, but keep everything else the same as above, simplifying the
processors a good amount.


-- 
Joe Hildebrand