Re: [Json] Working Group Last Call on draft-ietf-json-text-sequence

On reflection, I support Carsten’s option #1; choose a suitable delimiter
that can’t occur in UTF-8-encoded JSON.  It makes the syncing problem
vanish and removes worrying attack vectors.

On Sat, May 24, 2014 at 12:02 PM, Carsten Bormann <cabo@tzi.org> wrote:

> On 23 May 2014, at 08:53, Martin J. Dürst <duerst@it.aoyama.ac.jp> wrote:
>
> > it's not too difficult to parse the delimiters separately and only have
> the values parsed by a JSON parser
>
> Indeed.  I continue to believe that this is the only reasonable way to
> operate on sequences of JSON instances.
> Either
>
> 1) use a delimiter that cannot occur in JSON (staying in UTF-8 with ASCII
> control characters as in NUL, FF or RS; or breaking out of UTF-8 as in
> using 0xFF bytes);
> 2) use LF as the delimiter, and remove the LFs from the JSON instances.
>
> Using LFs as inter-stream delimiters, while also retaining their
> insignificant whitespace role within JSON instances, strikes me as the most
> complicated way to approach this problem.
> There may be practical reasons to use this most-complicated way, but it
> seems suboptimal to standardize on it.
>
> (I’m not a big fan of wrapping separate JSON instances in outermost JSON
> arrays for the kinds of applications addressed here.
> This can obviously already be used for those cases where it works (no need
> for concatenation, no need for resilience), but except in those cases where
> a combined JSON instance had been the right thing to use in the first
> place, it combines all the same problems of dual-use LFs with the need to
> add wrapping brackets.)
>
> Grüße, Carsten
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)