Subject: [Json] Fwd: New Version Notification for draft-ietf-json-rfc4627bis-03.txt

From: Tim Bray <[email-masked]>
Date: Thu, 19 Sep 2013 14:03:56 -0700

Thanks for the invite to stand in for Douglas, whom I hope is OK and I’m
sad if our mob-pedantry drove him away.

- A *real* HTML version is at
https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-03.html

- Paul insisted that I load up section 1.3 with all the changes I made. I
checked by diffing the XML, so I think they’re about right.

- The language is 95% straight outta the consensus calls, with the
exception of the new section 1.2 (Introduction to this version), which I
thought was necessary, and 8.3 (String comparison) which we’d agreed on
generally but nobody’d written language.

Have fun!

---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, Sep 19, 2013 at 1:57 PM
Subject: New Version Notification for draft-ietf-json-rfc4627bis-03.txt
To: Tim Bray <[email-masked]>

A new version of I-D, draft-ietf-json-rfc4627bis-03.txt
has been successfully submitted by Tim Bray and posted to the
IETF repository.

Filename:        draft-ietf-json-rfc4627bis
Revision:        03
Title:           The JSON Data Interchange Format
Creation date:   2013-09-18
Group:           json
Number of pages: 13
URL:
http://www.ietf.org/internet-drafts/draft-ietf-json-rfc4627bis-03.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis
Htmlized:        http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-03
Diff:
http://www.ietf.org/rfcdiff?url2=draft-ietf-json-rfc4627bis-03

Abstract:
   JavaScript Object Notation (JSON) is a lightweight, text-based,
   language-independent data interchange format.  It was derived from
   the ECMAScript Programming Language Standard.  JSON defines a small
   set of formatting rules for the portable representation of structured
   data.

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: Rick Waldron <[email-masked]>
Date: Thu, 19 Sep 2013 17:21:31 -0400

In section 2, JSON Grammar the definition of JSON-text is wrong. It
shouldn't be restricted to just "object/array". JSON-text is the top most
production and may consist of any JSON-value: object, array, string,
number, true (literal), false (literal), null (literal)

>  A JSON text is a sequence of tokens.  The set of tokens includes six
structural characters, strings, numbers, and three literal names.
>
>  A JSON text is a serialized object or array.
>
>  JSON-text = object / array

This is a compatibility breaking change.

Rick

On Thu, Sep 19, 2013 at 5:03 PM, Tim Bray <[email-masked]> wrote:

> Status:
> http://datatracker.ietf.org/doc/draft-ietf-json-rfc4627bis
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>
>

---

From: Tim Bray <[email-masked]>
Date: Thu, 19 Sep 2013 14:24:22 -0700

> number, true (literal), false (literal), null (literal)

I think it can’t be a breaking change because it’s not a change.  I didn’t
touch that part.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Sep 2013 14:37:10 -0700

<chair hat on>

On Sep 19, 2013, at 2:21 PM, Rick Waldron <[email-masked]> wrote:

> In section 2, JSON Grammar the definition of JSON-text is wrong.

It is identical to what is in RFC 4627.

> It shouldn't be restricted to just "object/array". JSON-text is the top most production and may consist of any JSON-value: object, array, string, number, true (literal), false (literal), null (literal)
> 
> >  A JSON text is a sequence of tokens.  The set of tokens includes six structural characters, strings, numbers, and three literal names.
> >

You mean compatibility with ECMAScript, yes? RFC 4627 and ECMAScript disagree on this, and have disagreed on this for a very long time. Is your proposal that the -bis document breaks compatibility with RFC 4627 in the definition of JSON-text in order to be compatible with ECMAScript?

--Paul Hoffman

---

From: John Cowan <[email-masked]>
Date: Thu, 19 Sep 2013 17:45:06 -0400

Rick Waldron scripsit:

> shouldn't be restricted to just "object/array". 

It always has been so restricted.  123 is not a valid JSON text, nor is true.

-- 
John Cowan      <[email-masked]>       http://www.ccil.org/~cowan
                Charles li reis, nostre emperesdre magnes,
                Set anz totz pleinz ad ested in Espagnes.

---

From: Tim Bray <[email-masked]>
Date: Thu, 19 Sep 2013 15:04:34 -0700

I ran a quick check on the languages with their guts open on my desktop, to
see how they behave given a top-level data item claimed to be JSON.

Ruby: Blows up.
Go: Works fine.

On Thu, Sep 19, 2013 at 2:37 PM, Paul Hoffman <[email-masked]> wrote:

> > It shouldn't be restricted to just "object/array". JSON-text is the top
> most production and may consist of any JSON-value: object, array, string,
> You mean compatibility with ECMAScript, yes? RFC 4627 and ECMAScript
> disagree on this, and have disagreed on this for a very long time. Is your
> proposal that the -bis document breaks compatibility with RFC 4627 in the
> definition of JSON-text in order to be compatible with ECMAScript?
>
> --Paul Hoffman

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Thu, 19 Sep 2013 15:51:17 -0700

I was wondering about the required behaviour of JSON parsers on inputs that 
represent strings that are not valid JSON string (which are a sequence of zero 
or more Unicode characters).   One such input is

[ "\uDEAD" ]

Are JSON parsers required to silently accept such inputs, and produce some 
valid JSON data, for example turning the above input into an array of the 
one-character string of the Unicode OBJECT REPLACEMENT CHARACTER (U+FFFC) (or 
something else).

Or are JSON parsers required to silently accept such inputs, and produce an 
output that mirrors the input, here an array of the one-element sequence of 
the number 0xDEAD?

Or are JSON parsers required to signal that this input is illegal, even though 
it matches the JSON grammar?

This question is not about the behavior of software that uses the output of a 
JSON parser, just about the required behaviour of JSON parsers.  (I'm very 
much hoping that JSON parsers are allowed to signal that such inputs are 
illegal so that downstream software does not have to worry about malformed 
strings nor about infidelities between the input and the output of a JSON parser.)

Peter F. Patel-Schneider
Nuance Communications

---

From: Tim Bray <[email-masked]>
Date: Thu, 19 Sep 2013 16:01:12 -0700

The RFC says the parser MUST accept it if it matches the grammar, and {"a"
: "\uDEAD" } does, so it has to be accepted.

The -bis says that emitting such JSON will potentially lead to
interoperability problems including downstream crashes.

I’m not sure that anything further can be said in the context of our
current charter.  -T

On Thu, Sep 19, 2013 at 3:51 PM, Peter F. Patel-Schneider <
[email-masked]> wrote:

> I was wondering about the required behaviour of JSON parsers on inputs
> that represent strings that are not valid JSON string (which are a sequence
> of zero or more Unicode characters).   One such input is
>
> [ "\uDEAD" ]
>
> one-character string of the Unicode OBJECT REPLACEMENT CHARACTER (U+FFFC)
> (or something else).
>
> Or are JSON parsers required to silently accept such inputs, and produce
> an output that mirrors the input, here an array of the one-element sequence
> of the number 0xDEAD?
>
> Or are JSON parsers required to signal that this input is illegal, even
> though it matches the JSON grammar?
>
>
> This question is not about the behavior of software that uses the output
> of a JSON parser, just about the required behaviour of JSON parsers.  (I'm
> very much hoping that JSON parsers are allowed to signal that such inputs
> are illegal so that downstream software does not have to worry about
> malformed strings nor about infidelities between the input and the output
> of a JSON parser.)
>
>
>
> Peter F. Patel-Schneider
> Nuance Communications
>
>
>
>

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Thu, 19 Sep 2013 16:14:10 -0700

OK, {"a":"\uDEAD"} matches the grammar, so a JSON parser is obligated to 
accept it.  (YUCK!)

However, what can a JSON parser produce for this input?   JSON strings are 
sequences of Unicode characters, so, as I read the document, a sequence 
consisting of only 0xDEAD is not a JSON string, and a JSON parser that 
produces such an output is not compliant.

peter

On 09/19/2013 04:01 PM, Tim Bray wrote:
> The RFC says the parser MUST accept it if it matches the grammar, and {"a" : 
> "\uDEAD" } does, so it has to be accepted.
>
> I’m not sure that anything further can be said in the context of our current 
> charter.  -T
>
>
> On Thu, Sep 19, 2013 at 3:51 PM, Peter F. Patel-Schneider 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     that represent strings that are not valid JSON string (which are a
>     sequence of zero or more Unicode characters). One such input is
>
>     [ "\uDEAD" ]
>
>     Are JSON parsers required to silently accept such inputs, and produce
>     some valid JSON data, for example turning the above input into an array
>     of the one-character string of the Unicode OBJECT REPLACEMENT CHARACTER
>     (U+FFFC) (or something else).
>
>     an output that mirrors the input, here an array of the one-element
>     sequence of the number 0xDEAD?
>
>     of a JSON parser, just about the required behaviour of JSON parsers.
>      (I'm very much hoping that JSON parsers are allowed to signal that such
>     inputs are illegal so that downstream software does not have to worry
>     about malformed strings nor about infidelities between the input and the
>     output of a JSON parser.)
>
>
>
>     Peter F. Patel-Schneider
>     Nuance Communications
>
>
>
>

---

From: Tim Bray <[email-masked]>
Date: Thu, 19 Sep 2013 16:19:28 -0700

The RFC describes the interchange format and is entirely silent on the
subject of software behavior except to say that the text in question must
be accepted.

Getting into the business of specifying behavior, or what it is that a JSON
parser emits, is a first step onto a very long and slippery slope. Let’s
not go there.

On Thu, Sep 19, 2013 at 4:14 PM, Peter F. Patel-Schneider <
[email-masked]> wrote:

>> The RFC says the parser MUST accept it if it matches the grammar, and
>> {"a" : "\uDEAD" } does, so it has to be accepted.
>>
>> [email-masked] <mailto:[email-masked]**>> wrote:
>>

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Thu, 19 Sep 2013 16:19:56 -0700

I find the advice about parsers somewhat contradictory, even though it carried 
over from the RFC.  The first paragraph says that parsers must accept all JSON 
texts but then implementations may set limits on the size of texts that they 
accept.

Are implementations parsers?  If so, then they have to accept all JSON texts.  
If not, then what are they, and how do they reject JSON texts that are too 
big, or too complex, or ...?  It might be a good idea to clarify this section.

Peter F. Patel-Schneider

  9.
  <https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-03.html#rfc.section.9>
  Parsers <https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-03.html#parsers>

A JSON parser transforms a JSON text into another representation. A JSON 
parser MUST accept all texts that conform to the JSON grammar. A JSON parser 
MAY accept non-JSON forms or extensions.

An implementation may set limits on the size of texts that it accepts. An 
implementation may set limits on the maximum depth of nesting. An 
implementation may set limits on the range of numbers. An implementation may 
set limits on the length and character contents of strings.

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Thu, 19 Sep 2013 16:30:06 -0700

Yeah, it's a tricky business to achieve interoperability.  However, without 
touching on these issues, can JSON ever be used where the either the sending 
or the receiving software is unknown?

It does appear that "An implementation may set limits on the length and 
character contents of strings." could provide cover for a JSON parser that 
signals an error on JSON texts that contain illegal Unicode characters.   I do 
hope that this section is clarified to indicate that "implementation" includes 
"JSON parser" and that the entire paragraph overrides the previous paragraph.

peter

On 09/19/2013 04:19 PM, Tim Bray wrote:
> subject of software behavior except to say that the text in question must be 
> accepted.
>
> parser emits, is a first step onto a very long and slippery slope. Let’s not 
> go there.
>
>
> On Thu, Sep 19, 2013 at 4:14 PM, Peter F. Patel-Schneider 
>         The RFC says the parser MUST accept it if it matches the grammar,
>         and {"a" : "\uDEAD" } does, so it has to be accepted.
>
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>

---

From: John Cowan <[email-masked]>
Date: Thu, 19 Sep 2013 19:47:39 -0400

> generally but nobody’d written language.

There's a bug.  The use of "code unit" in 8.3 is undefined unless it's
specified whether 8-bit, 16-bit, or 32-bit code units are intended
(see the Unicode glossary).  I think changing the first instance to
"16-bit code units" will suffice.

-- 
John Cowan      http://www.ccil.org/~cowan      [email-masked]
Be yourself.  Especially do not feign a working knowledge of RDF where
no such knowledge exists.  Neither be cynical about RELAX NG; for in
the face of all aridity and disenchantment in the world of markup,
James Clark is as perennial as the grass.  --DeXiderata, Sean McGrath

---

From: John Cowan <[email-masked]>
Date: Thu, 19 Sep 2013 19:57:03 -0400

Peter F. Patel-Schneider scripsit:

> some valid JSON data, for example turning the above input into an
> array of the one-character string of the Unicode OBJECT REPLACEMENT
> CHARACTER (U+FFFC) (or something else).

They MAY do that, but are not REQUIRED to.  An internal string
containing U+FFFD is also reasonable.

> Or are JSON parsers required to silently accept such inputs, and
> produce an output that mirrors the input, here an array of the
> one-element sequence of the number 0xDEAD?

I'd say that's too far away from reasonableness.  Strings aren't
numbers.

> Or are JSON parsers required to signal that this input is illegal,
> even though it matches the JSON grammar?

They MAY do that, but are not REQUIRED to.

Finally, if the parser's internal representation of JSON strings
consists of a sequence of 16-bit code units, then of course it MAY
return an array of a one-member sequence consisting of that code unit.
This is what parsers written in Java, C#, or JavaScript generally do.

-- 
weirdo:    When is R7RS coming out?                  John Cowan
Riastradh: As soon as the top is a beautiful         [email-masked]
           golden brown and if you stick a toothpick
          in it, the toothpick comes out dry.        www.ccil.org/~cowan

---

From: Rick Waldron <[email-masked]>
Date: Thu, 19 Sep 2013 20:02:21 -0400

On Thursday, September 19, 2013, Tim Bray wrote:

> On Thu, Sep 19, 2013 at 2:21 PM, Rick Waldron <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> > wrote:
>
Apologies, I was comparing to the JSON grammar spec in ES5.1

Rick

---

From: Tatu Saloranta <[email-masked]>
Date: Thu, 19 Sep 2013 17:07:11 -0700

On Thu, Sep 19, 2013 at 4:30 PM, Peter F. Patel-Schneider <
[email-masked]> wrote:

> Yeah, it's a tricky business to achieve interoperability.  However,
> without touching on these issues, can JSON ever be used where the either
> the sending or the receiving software is unknown?
>
>
It is and has been used that way for years now. Twitter, Facebook et al do
not know or care about kind of JSON processing library that the other end
has.
As nice as it would be to straighten these out, these potential issues
haven't slowed down JSON adoption in any meaningful way so far.

-+ Tatu +-

>> Getting into the business of specifying behavior, or what it is that a
>> JSON parser emits, is a first step onto a very long and slippery slope.
>> Let’s not go there.
>>
>>
>>         <[email-masked] <mailto:[email-masked]**>
>>         <mailto:[email-masked] <mailto:[email-masked]**>>>
>> wrote:
>>
>>             I was wondering about the required behaviour of JSON parsers
>> on
>>         inputs
>>         produce
>>             inputs are illegal so that downstream software does not have
>> to
>>         worry
>>             about malformed strings nor about infidelities between the
>> input
>>         and the
> ______________________________**_________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>