Subject: [Json] draft-williams-json-text-sequence-00

From: Nico Williams <[email-masked]>
Date: Fri, 14 Mar 2014 19:58:33 -0500

Just submitted.

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Fri, Mar 14, 2014 at 7:57 PM
Subject: New Version Notification for draft-williams-json-text-sequence-00.txt
To: Nicolas Williams <[email-masked]>

A new version of I-D, draft-williams-json-text-sequence-00.txt
has been successfully submitted by Nicolas Williams and posted to the
IETF repository.

Name:           draft-williams-json-text-sequence
Revision:       00
Title:          JavaScript Object Notation (JSON) Text Sequences
Document date:  2014-03-14
Group:          Individual Submission
Pages:          8
URL:
http://www.ietf.org/internet-drafts/draft-williams-json-text-sequence-00.txt
Status:
https://datatracker.ietf.org/doc/draft-williams-json-text-sequence/
Htmlized:       http://tools.ietf.org/html/draft-williams-json-text-sequence-00

Abstract:
   This document describes the JSON text sequence format and associated
   media type.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: John Cowan <[email-masked]>
Date: Sat, 15 Mar 2014 15:41:23 -0400

> Just submitted.

1) Your terminology of "online parsers" and "incremental parsers"
is very confusing.  What you call an "online parser", I would call a
"streaming parser", because it returns portions of arrays, objects, and
possibly even strings as a stream of events.  Your "incremental parser"
is simply a parser that stops reading when it reaches the end of a JSON
text without insisting that there be no additional characters.

2) The sentence "Encoders MUST emit" should refer explicitly to
the grammar.  Currently the grammar is completely unmoored from the
requirements.  "Encoders MUST emit JSON text sequences that conform to
the ABNF" is sufficient.

3) The sentence "Two contiguous separators do not" is unnecessary,
because there are no empty JSON texts.

4) In "Parsers MUST be able", for "to parser" read "to parse".  But as
in #2, this should simply say "Parsers MUST be able to parse any text
conforming to the ABNF" for the same reasons.

5) The recommendation seems entirely unnecessary to me.

6) I still don't see that there is any ambiguity in "truefalse" considered
as two JSON-texts.  So I would strip "Parsers MAY parse" to just say
"sequences where the separators are missing."  Note that such sequences
don't conform anyway.

7) If you want newline-free JSON-texts to be in serious use, the second
MAY should be promoted to a SHOULD.

-- 
"The serene chaos that is Courage, and the phenomenon   [email-masked]
of Unopened Consciousness have been known to the        John Cowan
Great World eons longer than Extaboulism."
"Why is that?" the woman inquired.
"Because I just made that word up", the Master said wisely.
        --Kehlog Albran, The Profit             http://www.ccil.org/~cowan

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 15 Mar 2014 16:53:03 -0400

> MAY should be promoted to a SHOULD.

I am thinking that the best way to show off JSON sequence would be to
update this draft from '96

http://www.w3.org/TR/WD-logfile.html

It is a widely used format but it has problems, every entry has to specify
entries for precisely the set of data advertised at the start.

I am thinking of redoing the spec in JSON using the same tags to identify
the data elements.

-- 
Website: http://hallambaker.com/

---

From: Nico Williams <[email-masked]>
Date: Sun, 16 Mar 2014 02:44:01 -0500

> text without insisting that there be no additional characters.

Oops, in an earlier version (not submitted) I defined these terms, but
after someone made a convincing argument to not require that texts not
have embedded newlines... I removed it.  I didn't remove the remaining
references to online/incremental parsers.

> requirements.  "Encoders MUST emit JSON text sequences that conform to

True.  Also a remnant of an earlier version.  I'll fix this too.

> because there are no empty JSON texts.

I know this.  I just figure someone will wonder if I don't say it.

> conforming to the ABNF" for the same reasons.

Sure.

> 5) The recommendation seems entirely unnecessary to me.

Well, it's superfluous if encoders must adhere to the ABNF, that's true.

> "sequences where the separators are missing."  Note that such sequences

It's true that 'trusfalse' does not conform to the ABNF, therefore
it's not a legal sequence.  Removing the options (and recommendation)
would suffice.

> MAY should be promoted to a SHOULD.

I no longer do.  I wasn't ever sure that was a good idea either.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 16 Mar 2014 02:52:59 -0500

On Sat, Mar 15, 2014 at 3:53 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> I am thinking that the best way to show off JSON sequence would be to update
> this draft from '96
>

Speaking of which... what is the best way to longpoll (tail -f) a log
file over HTTP?

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 16 Mar 2014 08:01:04 -0400

> Speaking of which... what is the best way to longpoll (tail -f) a log

Make a HEAD request to find out the Content-Length, then to poll for
updates after that point, use the range parameter.

But a Web Service to fetch the info would make matters a lot easier.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 16 Mar 2014 08:23:11 -0700

> I know this.  I just figure someone will wonder if I don't say it.

Exactly right. Thus, please leave it in.

--Paul Hoffman

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Sun, 16 Mar 2014 21:44:33 +0000

>Speaking of which... what is the best way to longpoll (tail -f) a log

A WebSocket.  One WS message containing each JSON object log message.  No
need for new formats.

-- 
Joe Hildebrand

---

From: Nico Williams <[email-masked]>
Date: Sun, 16 Mar 2014 17:30:22 -0500

> A WebSocket.  One WS message containing each JSON object log message.  No

A WS works for some apps, yes.  Suppose the log is something like a
database replication log...  Initially I may want to fetch the whole
log, then I may want to tail it, and tailing could be "dumb", sending
what's available, when it's available, without having to find JSON
text boundaries.

Nico
--

---

From: "Manger, James" <[email-masked]>
Date: Mon, 17 Mar 2014 16:47:43 +1100

> http://tools.ietf.org/html/draft-williams-json-text-sequence-00

Nico,

Did you really mean to allow commas as separators (%2C in ABNF)?

I would be tempted to say:

  A JSON sequence is a concatenation of any number of JSON values,
  remembering that each value (matching <JSON-text> in [RFC7159])
  can be preceded and followed by insignificant whitespace.
  Whitespace MUST be present between two JSON values when both
  values are true, false, null, or a number. Whitespace between
  values is allowed, but not required, when either value is an
  object, array, or string.

  Concatenating JSON values, each terminated with a newline (U+000A),
  is a simple way to match the syntax rules.

  An empty text and texts consisting only of whitespace are both valid
  JSON sequences of zero JSON values.

  The media type "application/jsons" indentifies content that is
  a UTF-8-encoded JSON sequence.

--
James Manger

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Mar 2014 10:37:32 -0500

> Did you really mean to allow commas as separators (%2C in ABNF)?

No, I hadn't (I'd just argued in response to Phillip that it was a bad
idea).  However, I'm not as convinced of it as I'd like to be.  I
think there may indeed be some value in it.  Suppose you expect a JSON
text to be a very large (possibly never-ending) array... you might
parse it as a sequence by skipping the initial '[' and going from
there.  You'd get streaming parsing of the sequence without streaming
parsing of the individual JSON texts.  That seems worthwhile as a way
of dealing with any cases that might exist of very large arrays.

>   object, array, or string.

I like that, but it's important that the separator always _follow_
each text.  Whitespace may also precede a text, sure, but that's not
important here.

>   is a simple way to match the syntax rules.

Yes.

>   JSON sequences of zero JSON values.

s/empty text/empty sequence/, but yes, that's nice.

Nico
--