Subject: [Json] The text in draft-ietf-json-text-sequence

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Jul 2014 13:57:45 -0700

Greetings again. There is still disagreement in the WG about what the text separator should be for draft-ietf-json-text-sequence. The current draft, draft-ietf-json-text-sequence-04, specifies it as the LF character, and gives rationale for that decision in Section 2.2. Many people in the WG have expressed a preference for a different character, one that would not require any stripping from the normal whitespace that can exist inside the JSON text. There were many suggestions for such a different character; the one that seemed most favored was the ASCII record separator (RS) character, U+001e.

In order to simplify the decision, I'd like to ask a few simple questions:

- Do you feel that the protocol will be significantly broken if it uses LF as the text separator?

- Do you feel that the protocol will be significantly broken if it uses RS as the text separator?

- Do you feel that using LF or RF as the text separator is essentially the same for the protocol?

Answers of "yes", "no", and "don't know" are most appreciated. Explanation of a "yes" and "no" are probably not helpful at this time because they are likely to cause the thread to go off into discussion of the explanation, not of the questions.

Wearing my chair hat, I'm not sure how I will respond depending on different patterns in the results. Let's answer the questions and then see what we think it means.

--Paul Hoffman

---

From: Tim Bray <[email-masked]>
Date: Mon, 7 Jul 2014 16:30:19 -0700

> - Do you feel that the protocol will be significantly broken if it uses LF

​Yes​
​

> ​​

​No
​

> ​

​No​, assuming you mean LF or RS.

​​

>
> Answers of "yes", "no", and "don't know" are most appreciated. Explanation
> of a "yes" and "no" are probably not helpful at this time because they are
> likely to cause the thread to go off into discussion of the explanation,
> not of the questions.
>
> Wearing my chair hat, I'm not sure how I will respond depending on
> different patterns in the results. Let's answer the questions and then see
> what we think it means.
>
> --Paul Hoffman
> _______________________________________________
> 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: "Manger, James" <[email-masked]>
Date: Tue, 8 Jul 2014 09:43:10 +1000

No

Yes

No

--
James Manger

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 08 Jul 2014 10:09:31 +0900

On 2014/07/08 05:57, Paul Hoffman wrote:
> Greetings again. There is still disagreement in the WG about what the text separator should be for draft-ietf-json-text-sequence. The current draft, draft-ietf-json-text-sequence-04, specifies it as the LF character, and gives rationale for that decision in Section 2.2. Many people in the WG have expressed a preference for a different character, one that would not require any stripping from the normal whitespace that can exist inside the JSON text. There were many suggestions for such a different characte
 r;
>    the one that seemed most favored was the ASCII record separator (RS) character, U+001e.
>

Yes.

> - Do you feel that the protocol will be significantly broken if it uses RS as the text separator?

Yes.

> - Do you feel that using LF or RF as the text separator is essentially the same for the protocol?

Yes.

> Answers of "yes", "no", and "don't know" are most appreciated. Explanation of a "yes" and "no" are probably not helpful at this time because they are likely to cause the thread to go off into discu…

[The above are just a reflection of the fact that I think that this 
format (it's not really a protocol) is unnecessary and therefore broken 
from the start, and therefore it's broken with whatever separator there 
is (except with ',', i.e. simply as a JSON array). The problem of 
diverging opinions is best solved by abandoning this spec.]

Regards,   Martin.

---

From: John Cowan <[email-masked]>
Date: Mon, 7 Jul 2014 21:15:04 -0400

> uses LF as the text separator?

No.

> uses RS as the text separator?

No.

> the same for the protocol?

Yes.  (However, it would be bad to allow both.)

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
First known example of political correctness: After Nurhachi had united
all the other Jurchen tribes under the leadership of the Manchus, his
successor Abahai (1592-1643) issued an order that the name Jurchen should
be banned, and from then on, they were all to be called Manchus.
                --S. Robert Ramsey, The Languages of China

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 8 Jul 2014 11:50:54 +0000

On 7/7/14, 10:57 PM, "Paul Hoffman" <[email-masked]> wrote:

>Greetings again. There is still disagreement in the WG about what the
>text separator should be for draft-ietf-json-text-sequence. The current
>draft, draft-ietf-json-text-sequence-04, specifies it as the LF
>character, and gives rationale for that decision in Section 2.2. Many
>people in the WG have expressed a preference for a different character,
>one that would not require any stripping from the normal whitespace that
>can exist inside the JSON text. There were many suggestions for such a
>different character; the one that seemed most favored was the ASCII
>record separator (RS) character, U+001e.
>

Somewhat.

No.

No.

-- 
Joe Hildebrand

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Jul 2014 13:55:23 +0200

> - Do you feel that the protocol will be significantly broken if it uses LF as the text separator?

Yes.  [if “not very useful” counts as “broken"]

No.

No.

Grüße, Carsten

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 Jul 2014 14:02:33 -0700

[[ Another nudge on the topic. If no one else cares, that's fine, but I suspect there are people who have not answered the questions who have opinions. ]]

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Jul 2014 01:20:51 -0500

> > - Do you feel that the protocol will be significantly broken if it uses LF

Not at all.  Consider:

 - a logger has to check that the input doesn't contain any RS, if we go
   with RS, therefore checking for and replacing LFs with SP is no more
   burdensome: it costs a few more writes to memory in the infrequent case;

 - replacing LFs (unescaped LFs; remember that LFs in strings MUST
   always be escaped) with SP is a valid transformation that does not
   change the content nor meaning of a JSON text

Therefore, LF and RS are equivalent in terms of: work for the
implementor, and run-time burden.  Also: in terms of what happens if a
logger doesn't check (or transform) the texts it logs to make sure they
don't contain the text separator.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Jul 2014 01:30:24 -0500

> - Do you feel that the protocol will be significantly broken if it uses RS as the text separator?

I agree.  I think RS will hurt and won't help.

To begin with: there exists running code using LF as the separator.  I
just demonstrated (separate post, new sub-thread) that RS/LF are
equivalent in terms of functionality, semantics, and cost.  So why break
running code??

And then there's all the text-oriented tools that won't handle RS.
Examples have been given in past posts.  There's no value to using RS or
anything other than LF.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Jul 2014 01:32:36 -0500

On Tue, Jul 08, 2014 at 10:09:31AM +0900, "Martin J. Dürst" wrote:
> [...]
> format (it's not really a protocol) is unnecessary and therefore
> broken from the start, and therefore it's broken with whatever
> separator there is (except with ',', i.e. simply as a JSON array).
> The problem of diverging opinions is best solved by abandoning this
> spec.]

Do you feel that the IESG ought to request that the RFC-Editor do not
publish if we pursue Informational RFC publication?  Please explain in
detail how this protocol is harmful the Internet.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Jul 2014 01:34:08 -0500

> Yes.  (However, it would be bad to allow both.)

Thanks.  I agree, though I think LF is better than RS for various
reasons (given separately), therefore though they are equivalent on some
level, RS is not as useful (not to say harmful) as LF.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Jul 2014 01:38:54 -0500

> >LF as the text separator?

Considering that...

 - ...LFs cannot appear unescaped in strings,
 - therefore LFs in JSON texts are just whitespace,
 - therefore LFs in JSON texts may safely be removed or replaced with
   other JSON whitespace,

and considering that if we used RS a logger would still have to check
that a text to be logged does not include RS,...

...what might be broken if we use LF instead of RS?

Loggers would have to s/LF/SP/g or s/LF//g or equivalent.  But in the
common case this is equivalent to checking that a text to be logged has
no RS.

For loggers that produce their own texts, all they have to do is select
a "compact" encoding, as provided by most libraries, or s/LF/SP/g if no
such option is available.

(My apologies, I'm now repeating myself somewhat.)

Nico
--

---

From: John Cowan <[email-masked]>
Date: Tue, 15 Jul 2014 03:06:14 -0400

> that a text to be logged does not include RS,...

How so?  JSON cannot contain unescaped RS; an RS in a string must
appear as \u001F.

> common case this is equivalent to checking that a text to be logged has

No such check is called for.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
A rose by any other name may smell as sweet, but if you called it
an onion you'd get cooks very confused.          --RMS

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 15 Jul 2014 17:14:00 +0900

Hello Nico,

> detail how this protocol is harmful the Internet.

"harmful" is a bit too strong. I used the word "unnecessary". Good 
engineering includes *not* doing stuff that isn't necessary. Good 
engineering includes avoiding unnecessary minor variants. Good 
engineering includes exploiting reusing solutions (i.e. JSON arrays), 
rather than reinventing (a slightly edgy) wheel.

In my opinion, the IESG should never have chartered the WG for this work 
item, because the WG wasn't ever actually asked whether we want to work 
on this. It was just included in the follow-up work after completing the 
base spec for reasons that I can only speculate about (e.g. the new WG 
charter otherwise looking a bit thin?).

In my view, it's never too late to abandon this work; I'd be sorry for 
the work you invested in drafting, but we could save the IESG, the IETF, 
and the RFC editor some work. The former two might be avoided if this is 
published as an independent contribution, but this would happen outside 
the WG. If that avenue is persued, I'd probably urge the IESG to request 
the addition of a comment explicitly saying that JSON arrays are a 
better solution.

Anyway, I hope I don't have to spend too much time anymore on this, sorry.

Regards,   Martin.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 Jul 2014 06:16:13 -0700

Nico: The poll was meant as a poll, not a discussion. As you know, the poll said:

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Jul 2014 18:13:10 -0500

> How so?  JSON cannot contain unescaped RS; an RS in a string must

But if a logger is just logging a string purported to be a JSON text,
then it has to validate.  OTOH, if the logger is logging a JSON _value_
then it can trivially encode with no newlines (or remove/map them).

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Jul 2014 18:13:33 -0500

> Nico: The poll was meant as a poll, not a discussion. As you know, the

Oops.

What now?

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Jul 2014 00:15:28 -0500

> uses LF as the text separator?

Not in the least.

> - Do you feel that the protocol will be significantly broken if it uses RS as the text separator?

No, but it will be inconvenient.

> - Do you feel that using LF or RF as the text separator is essentially the same for the protocol?

Yes, except that LF is much more convenient.

Nico
--