Subject: [Json] Coming to better consensus on draft-ietf-json-text-sequence

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Aug 2014 07:30:32 -0700

Greetings again. The WG seems unable to come to consensus on the choice of the record separator in draft-ietf-json-text-sequence. The recent poll finds that there is not even rough consensus about whether using the LF is better or worse than using the RS character in the current draft, and yet people on both sides feel vehement on their choice.

However, the earlier threads about this document show some common ground. There is definite WG interest in log files with sequences of JSON texts, but no agreement in the result as it stands. There was also early statements about the protocol being more complex than was needed, with procedures for receivers dealing with partial texts and truncated entries.

If the protocol is focused on just system log files (not hand-typed files), and without trying to deal with partial texts and truncated entries, the protocol becomes much simpler and the choice of record separator becomes much clearer.

Given this, the chairs ask the document author to produce a new draft:

- Move the first paragraph of Section 3 into the introduction.

- Change the description in Section 2 to be:

    JSON-sequence = ws *(JSON-text ws RS ws)
    RS = %x1E
    ws = <given by RFC7159>
    JSON-text = <given by RFC7159>

- Remove Sections 2.1, 2.1.1, 2.2, and 3. Remove the last paragraph of the Security Considerations.

The chairs believe that such a draft will be more likely to achieve at least rough WG consensus.

--Paul Hoffman and Matt Miller

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 14:45:51 -0500

On Mon, Aug 04, 2014 at 07:30:32AM -0700, Paul Hoffman wrote:
> If the protocol is focused on just system log files (not hand-typed

It isn't.  Logfiles is but one use case.  I mentioned Riak's use of JSON
text sequences for serializing databse query results.

> files), and without trying to deal with partial texts and truncated
> entries, the protocol becomes much simpler and the choice of record
> separator becomes much clearer.

I don't agree.  Log writers can just s/LF/SP/g then use LF as the
separator.

>     JSON-text = <given by RFC7159>

I don't understand.  There's no consensus as to LF vs. RS, so you're
picking one of the alternatives?  On what basis?

Nico
--

---

From: Tim Bray <[email-masked]>
Date: Mon, 4 Aug 2014 13:13:47 -0700

On Mon, Aug 4, 2014 at 12:45 PM, Nico Williams <[email-masked]>
wrote:

> ​​
> ​​

​The chairs think they have a better chance of getting to consensus with
the changes they outline.  They’re the chairs, that’s their job.  Make the
changes and see what happens; it might work.

-T​

​​

​​

>
> Nico
> --
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Aug 2014 13:23:03 -0700

On Aug 4, 2014, at 12:45 PM, Nico Williams <[email-masked]> wrote:

> It isn't.  Logfiles is but one use case.

Logfiles are the use case that members seem to be universally interested in.

> I mentioned Riak's use of JSON

Yes, you did. That did not help the WG come to consensus, which is what we are trying to do here. Further, at least one person reading that post (me) did not see how that use case was at all different than log files.

> I don't agree.  Log writers can just s/LF/SP/g then use LF as the

Yes, they can. There was not consensus in the WG that this was simple enough, given all the rest of the text in the draft.

> I don't understand.  

I suspect that you do.

> There's no consensus as to LF vs. RS, so you're

On the basis of simplifying the protocol, as described in the message.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 15:50:08 -0500

> I suspect that you do.

I didn't when I said so.  I wasn't being disingenuous if that's what you
mean.

> On the basis of simplifying the protocol, as described in the message.

Tim's response was a better explanation, I thought.

I do understand now, at least on the basis of Tim's response, but I
don't believe you've made a simplification, or one worth making.  I
understand now but I also disagree with your rationale.  Thanks for
explaining though.

I'll make the changes and submit if that's what you want, but I don't
agree with them.

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Aug 2014 13:52:29 -0700

> I'll make the changes and submit if that's what you want, but I don't

Thank you.

--Paul Hoffman