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

The new RFC is backward compatible:

"In telecommunications and computing, a product or technology is backward
or downward compatible if it can work with input generated by an older
product or technology"
<http://en.wikipedia.org/wiki/Backward_compatibility>

> this only opens the door for
> future implementations to produce things that do not work reliably.

Nope. This door has been wide open for quite some time, as both the new and
old RFC state:

"A JSON parser MAY accept non-JSON forms or extensions."

- Rob

On Fri, Mar 7, 2014 at 5:09 AM, Joe Hildebrand (jhildebr) <
jhildebr@cisco.com> wrote:

> 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" <paulej@packetizer.com> 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" <tbray@textuality.com>
> >To: "Paul E. Jones" <paulej@packetizer.com>
> >Cc: "Bjoern Hoehrmann" <derhoermi@gmx.net>; "RFC Errata System"
> ><rfc-editor@rfc-editor.org>; "Pete Resnick" <presnick@qti.qualcomm.com>;
> > "Paul Hoffman" <paul.hoffman@vpnc.org>; "json@ietf.org" <json@ietf.org>;
> >"Matthew Miller" <mamille2@cisco.com>; "Barry Leiba"
> ><barryleiba@computer.org>;
> >rfc7158@schmorp.de
> >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
> ><paulej@packetizer.com> 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" <derhoermi@gmx.net>
> >To: "RFC Errata System" <rfc-editor@rfc-editor.org>
> >Cc: presnick@qti.qualcomm.com;
> >paul.hoffman@vpnc.org <mailto:paul.hoffman@vpnc.org>; json@ietf.org;
> >tbray@textuality.com <mailto:tbray@textuality.com>; mamille2@cisco.com;
> >barryleiba@computer.org;
> >rfc7158@schmorp.de <mailto:rfc7158@schmorp.de>; rfc-editor@rfc-editor.org
> >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:bjoern@hoehrmann.de ·
> >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
> >json@ietf.org
> >https://www.ietf.org/mailman/listinfo/json
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Joe Hildebrand
>
>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>