Re: [Json] [Technical Errata Reported] RFC7158 (3907)

["Paul E. Jones" <[e-mail]>]

Joe,

But if my understanding is correct, it's not just a matter of 
backward-compatibility.  There is the question of "how does a serializer 
write out data now"?

As Marc pointed out, if one has two integers and requests a stateless 
serializing function to write those out to a file or on the wire, it 
will write out "1" and "999", using his examples.  Reading it back in, 
it would look like a single integer ("1999").  This means the serializer 
would have to be explicitly told whether to insert space before or after 
writing out data.  Alternatively, the application would have to ask the 
serializer to serialize it to a string and the application deal with 
whitespace itself.

Paul

------ Original Message ------
From: "Joe Hildebrand (jhildebr)" <[e-mail]>
To: "Paul E. Jones" <[e-mail]>; "Tim Bray" 
<[e-mail]>
Cc: "Pete Resnick" <[e-mail]>; "Bjoern Hoehrmann" 
<[e-mail]>; "Paul Hoffman" <[e-mail]>; 
"[e-mail]" <[e-mail]>; "Matt Miller (mamille2)" 
<[e-mail]>; "Barry Leiba" <[e-mail]>; 
"[e-mail]" <[e-mail]>; "RFC Errata System" 
<[e-mail]>
Sent: 3/7/2014 8:09:30 AM
Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907)

>Paul: ECMA's version of JSON has allowed anything at the top level for
>quite a while. The WG explicitly decided that having the two specs in
>sync was more important to us than the backward-compatility issue, 
>which
>we documented. This isn't a "mistake" in the sense that we didn't know 
>it
>was happening - it was the consensus of the people who were 
>participating.
>
>
>On 3/4/14 8:12 PM, "Paul E. Jones" <[e-mail]> wrote:
>
>>Tim,
>>
>>Yeah, I saw that. However, I still think this only opens the door for
>>future implementations to produce things that do not work reliably. As
>>Marc Lehmann rightfully pointed out (and, BTW, his Errata text appears 
>>to
>>have disappeared), a serializer that
>>  is requested to serialize a series of integers like 1 and 999 might
>>produce 1999. Reading that back in, the single value 1999 would be 
>>read.
>>  Likewise, a serializer might produce truefalse as output, but then 
>>fail
>>when one tries to read that back. One might
>>  argue to start all serialization with whitespace to avoid having 
>>values
>>serialized adjacent to each other. That would work, but unfortunate.
>>
>>Maybe I missed it, but I could not see _why_ the change was made to 
>>this
>>production. What was wrong with allowing only an object or array?
>>
>>Looking at some of the messages hanging off of the link Björn 
>>provided, I
>>can see people are worried, too, about the BOM. The previous text made
>>it very clear how to determine whether the text is UTF-16LE or 
>>UTF-16BE,
>>for example. That text seems to
>>  have disappeared. Is there a reason? I think the same approach 
>>spelled
>>out in Section 3 of RFC 4627 would still work, no?
>>
>>Paul
>>
>>------ Original Message ------
>>From: "Tim Bray" <[e-mail]>
>>To: "Paul E. Jones" <[e-mail]>
>>Cc: "Bjoern Hoehrmann" <[e-mail]>; "RFC Errata System"
>><[e-mail]>; "Pete Resnick" 
>><[e-mail]>;
>>  "Paul Hoffman" <[e-mail]>; "[e-mail]" 
>><[e-mail]>;
>>"Matthew Miller" <[e-mail]>; "Barry Leiba"
>><[e-mail]>;
>>[e-mail]
>>Sent: 3/4/2014 12:27:51 PM
>>Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907)
>>
>>
>>On this issue, also please read the interoperability note in the
>>paragraph before the new production.
>>
>>
>>On Tue, Mar 4, 2014 at 6:17 AM, Paul E. Jones
>><[e-mail]> wrote:
>>
>>I've not been following the list closely, as I thought this was more 
>>of
>>an editorial exercise than anything else. This is definitely more than
>>editorial. This could definitely break things and the commenter is 
>>right
>>that there are instances where there could
>>  be misinterpretation.
>>
>>Why was it decided to change this:
>>
>>     JSON-text = object / array
>>
>>to
>>
>>     JSON-text = ws value ws
>>
>>Was there some misunderstanding of what 4627 said?
>>
>>Paul
>>
>>------ Original Message ------
>>From: "Bjoern Hoehrmann" <[e-mail]>
>>To: "RFC Errata System" <[e-mail]>
>>Cc: [e-mail];
>>[e-mail] <mailto:[e-mail]>; [e-mail];
>>[e-mail] <mailto:[e-mail]>; 
>>[e-mail];
>>[e-mail];
>>[e-mail] <mailto:[e-mail]>; 
>>[e-mail]
>>Sent: 3/2/2014 4:31:07 PM
>>Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907)
>>
>>
>>
>>* RFC Errata System wrote:
>>
>>Since RFC7158 breaks compatibility with the specifications, this 
>>should be
>>duly noted.
>>
>>
>>
>>It is in Appendix A., "Changes from RFC 4627":
>>
>>    o Changed the definition of "JSON text" so that it can be any JSON
>>       value, removing the constraint that it be an object or array.
>>
>>Failing to note this in the Introduction is not ideal, but the errata
>>system is not a good place to record that (holding it for document up-
>>date probably does not make sense, if and when the document does get
>>updated, this particular issue will not require prominent notice).
>>--
>>Björn Höhrmann · mailto:[e-mail] ·
>>http://bjoern.hoehrmann.de <http://bjoern.hoehrmann.de/>
>>Am Badedeich 7 · Telefon:
>>+49(0)160/4415681 <tel:%2B49%280%29160%2F4415681> ·
>>http://www.bjoernsworld.de <http://www.bjoernsworld.de/>
>>25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·
>>http://www.websitedev.de/ <http://www.websitedev.de/>
>>
>>
>>
>>_______________________________________________
>>json mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/json
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>--
>Joe Hildebrand
>
>
>