|
RFC 7454 conformance
John Cowan
(18 Jan 2020 21:58 UTC)
|
|
Re: RFC 7454 conformance
Amirouche Boubekki
(19 Jan 2020 03:20 UTC)
|
|
Re: RFC 7454 conformance
John Cowan
(19 Jan 2020 03:21 UTC)
|
|
Re: RFC 7454 conformance Amirouche Boubekki (21 Jan 2020 10:50 UTC)
|
|
Re: RFC 7454 conformance
John Cowan
(21 Jan 2020 17:08 UTC)
|
|
Re: RFC 7454 conformance
Amirouche Boubekki
(21 Jan 2020 17:14 UTC)
|
|
Re: RFC 7464 conformance
Lassi Kortela
(21 Jan 2020 22:42 UTC)
|
|
Re: RFC 7464 conformance
John Cowan
(21 Jan 2020 23:02 UTC)
|
Re: RFC 7454 conformance Amirouche Boubekki 21 Jan 2020 10:49 UTC
Le dim. 19 janv. 2020 à 04:20, John Cowan <xxxxxx@ccil.org> a écrit : > > Correct. > > On Sat, Jan 18, 2020 at 10:20 PM Amirouche Boubekki <xxxxxx@gmail.com> wrote: >> >> Le sam. 18 janv. 2020 à 22:58, John Cowan <xxxxxx@ccil.org> a écrit : >> > >> > I suggest that the stream reader conform to RFC 7454. This is a protocol for having multiple JSON values in the same stream by making sure that no two values can run together. For example, outputting 12 followed by 24 would be reread as 1224. Furthermore, 7454 allows recovering from a broken JSON object and synchronizing correctly on the next object. >> > >> > For the stream reader, this basically means that it is legal to have a single U+001E in the input just before parsing a top-level value. >> > >> > The json-stream-writer procedure would have an additional argument, which if true would cause it to write U+001E before every top-level value and U+000A after every top-level value. >> >> Are you referring to https://tools.ietf.org/html/rfc7454? >> Does the RFC contradict JSON lines pseudo-standard: http://jsonlines.org/