Re: [Json] Proposed minimal change for duplicate names in objects

Vinny A <> Mon, 08 July 2013 07:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FE9D21F9DB6 for <>; Mon, 8 Jul 2013 00:16:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.602
X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MIME_QP_LONG_LINE=1.396]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qDsgdVTCmRkY for <>; Mon, 8 Jul 2013 00:16:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5FC9621F99D9 for <>; Mon, 8 Jul 2013 00:16:44 -0700 (PDT)
Received: from [] by with NNFMP; 08 Jul 2013 07:16:42 -0000
Received: from [] by with NNFMP; 08 Jul 2013 07:16:42 -0000
Received: from [] by with NNFMP; 08 Jul 2013 07:16:42 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1373267802; bh=/lEHcIaT6UqX5BJ+JKFWkOatwro55aj6ViEzedA9hVc=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=vmNzVpUGGePeMMTuvXVQDlka3D2P6Ud375QlkdBoFWWLxbewx5ruX2KS8Tg336FhKPn9OUr58YRJoJG0AFKzFokVDhRjvSvzmRf9woiiLa7rKFiIOBApqwPIDqkp6ghKOy2IHYOOKcQVK6pp1kW7p5ICeAK7ZsM1TrbwE5YZI6s=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 6BN2GIkVM1lNix9voIMTTQTj63slSZs1PKx3uhLFIlQDfdy kkRq9jTyUjtMGxjyxMJUobimeqVDXH38Wc8gDYvo35FnEZ.i49rnAF0fxGNH 1FrpwX0hWUJ70SW71dk6_zkzQTIRpDziLBcmqz0sYLQ1WWbYaN0BIXs9Rfyj se6WrnmVsZhmrlN_5o0GrX1Y64SwRBjJnVmrAITvrlsj14A2Dx04hDC8YqST 4WdX7eUy7u6yfy2s93QJDRlBjt1iOnk7O1y2hFB9nvruetObM4xHNJpuUIsK UcmFHSRNHfUX9NWyMF8YapE2klJi_3wNrBbjhG1yW4Hprrl7gOiesQJDwYDD Pv6adZf0bHYWMC_ob4BzbEuoVZ6_bTY.Y4BiQ9kdQTSoA2Urrl0jsv8oKls5 hRNiXanisOOxce32yvZ3Rkm8V7MH9OYfJmAPbQfQNw9BQX.eJzk4QHGE.UOq .UDAVvxbhULCX43cX3jwuzoIooBryQaUidxDnIetNyOjfnK2n1QpAqc.yiPU RcCuzuRFZ9UkUj_5y7vRS7HRp0hyMI0_eBLqRJIwYnsAaPUfiqq4TMu.WMbQ 1eP.GreNAvThVkqF1w5YvIpdPmGkr
X-Yahoo-SMTP: indQcmSswBC8IKsm6t4aCAPskK3T
X-Rocket-Received: from [] (jsontest@ with ) by with SMTP; 08 Jul 2013 00:16:42 -0700 PDT
References: <> <> <> <> <> <00cd01ce7a9f$19adeaa0$4d09bfe0$> <00d701ce7aa6$cc5fe700$651fb500$> <> <>
In-Reply-To: <>
Mime-Version: 1.0 (1.0)
Content-Type: multipart/alternative; boundary=Apple-Mail-815B28AE-536A-4049-8201-A6E3B7928F63
Content-Transfer-Encoding: 7bit
Message-Id: <>
X-Mailer: iPod Mail (9B206)
From: Vinny A <>
Date: Mon, 8 Jul 2013 02:16:39 -0500
To: Stephan Beal <>
Cc: "" <>
Subject: Re: [Json] Proposed minimal change for duplicate names in objects
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Jul 2013 07:16:50 -0000

On Jul 7, 2013, at 1:09 PM, Stephan Beal <> wrote:

>  Streaming or not, enforcing the implied level of infrastructure and potential performance hits which MUST  implies is not something i plan on doing, even if it means not being fully compliant. "Duplicate keys lead to unspecified behaviour," end of story.

The TL;DR of this discussion seems to be that MUST is too restrictive for some (streaming parsers, overhead, etc) yet SHOULD leaves too much space for ambiguity (as it does in the current  RFC 4627).

I'd like to point this list's attention to a post Eliot made a while ago, where he suggested wording that 1) expresses heavy disapproval on an implementation, 2) still allows for an alternative implementation if (1) is not acceptable, 3) is relatively minimal wording (which seems to be a priority given last week's discussions), and 4) has been used in previous RFCs. Here's the relevant comment:

On Jun 5, 2013, at 3:08 PM, Eliot Lear <> wrote:
> Demonstrating my age, an old trick we've done that goes back to RFC-1123
> is to say MUST NOT send, and then implementations MAY NOT process, and
> if they do MUST process thusly...

Could people come to a consensus on this if the proposed wording was similar to the above? I.e "Implementations MUST NOT send duplicate names; if received, parsers MAY NOT process the JSON, instead issuing an error. If implementations insist on supporting duplicated names, they MUST process in the following manner (insert boilerplate warnings about undesirable behavior)."