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

R S <sayrer@gmail.com> Mon, 10 March 2014 03:38 UTC

Return-Path: <sayrer@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE79E1A03B9 for <json@ietfa.amsl.com>; Sun, 9 Mar 2014 20:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3s0CifBIupb5 for <json@ietfa.amsl.com>; Sun, 9 Mar 2014 20:38:05 -0700 (PDT)
Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 009811A03BA for <json@ietf.org>; Sun, 9 Mar 2014 20:38:04 -0700 (PDT)
Received: by mail-qc0-f181.google.com with SMTP id e9so6991628qcy.40 for <json@ietf.org>; Sun, 09 Mar 2014 20:37:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CBTBkv50sY3ImZbdthL5zxx7tpY5s3O/rkR89U5wFS4=; b=Sxos/FEXMyTQzDhtxfj3CCKSUmOu/A/xBt+HUKUP3+H2p92+rBobc+nALlE+O3t2BC ylgnBQYSz3XDFhfpDR6GhUqBTmruVHe/zan1SQ8XhKiRWzTBVcnMn05DBCFLTa7OBOc9 DTPsB8GRgcbvf5FAkycWoM6jx+dN5xb3cwGSSXIogEOfIu7uqsUDvhjCtOonKFRS2rGc McgMMRYljc/Yk0QB294pYaiOtXZvsP6PBCSVW2u1FBUDMsRm0VMqwbzgfWjUI3DUrHTI ZtwC30/9qkrhnsJgNi+ZRDK9KzDMyZOOv5J+F664qk5+oCYCWi66xEKPB5thtdeW6GzN a/TA==
MIME-Version: 1.0
X-Received: by 10.140.32.37 with SMTP id g34mr32535117qgg.37.1394422679523; Sun, 09 Mar 2014 20:37:59 -0700 (PDT)
Received: by 10.140.42.164 with HTTP; Sun, 9 Mar 2014 20:37:59 -0700 (PDT)
In-Reply-To: <CF3F74B5.3CE74%jhildebr@cisco.com>
References: <CAHBU6ivCDjZ2rLP6XZws2aUR8_c+5L6qL2RmHNEJCRkg2NS5rg@mail.gmail.com> <em36b68433-9adf-4d3e-8035-a8c1b5b0e60f@sydney> <CF3F74B5.3CE74%jhildebr@cisco.com>
Date: Sun, 9 Mar 2014 20:37:59 -0700
Message-ID: <CAChr6Sw_MnGgw0upKP7YvDpRfLszTvw+7vyNgJpWfK_5uUbh0A@mail.gmail.com>
From: R S <sayrer@gmail.com>
To: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
Content-Type: multipart/alternative; boundary=001a1139717a7ad76f04f4385425
Archived-At: http://mailarchive.ietf.org/arch/msg/json/4LqRPX_sMaqlHReYKtGpUtbBWxg
X-Mailman-Approved-At: Mon, 10 Mar 2014 00:55:34 -0700
Cc: Pete Resnick <presnick@qti.qualcomm.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>, "Paul E. Jones" <paulej@packetizer.com>, Tim Bray <tbray@textuality.com>, "Matt Miller \(mamille2\)" <mamille2@cisco.com>, Barry Leiba <barryleiba@computer.org>, "rfc7158@schmorp.de" <rfc7158@schmorp.de>, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Mar 2014 03:38:09 -0000

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>et>; "RFC Errata System"
> ><rfc-editor@rfc-editor.org>r.org>; "Pete Resnick" <presnick@qti.qualcomm.com>om>;
> > "Paul Hoffman" <paul.hoffman@vpnc.org>rg>; "json@ietf.org" <json@ietf.org>rg>;
> >"Matthew Miller" <mamille2@cisco.com>om>; "Barry Leiba"
> ><barryleiba@computer.org>r.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.orgorg;
> >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
>