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

Bjoern Hoehrmann <> Fri, 05 July 2013 14:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51E4211E80E9 for <>; Fri, 5 Jul 2013 07:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NnMD5Izn604v for <>; Fri, 5 Jul 2013 07:11:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B372021F9F7A for <>; Fri, 5 Jul 2013 07:11:34 -0700 (PDT)
Received: from ([]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lrp0S-1UDUoF28zO-013elD for <>; Fri, 05 Jul 2013 16:11:33 +0200
Received: (qmail invoked by alias); 05 Jul 2013 14:11:32 -0000
Received: from (EHLO netb.Speedport_W_700V) [] by (mp002) with SMTP; 05 Jul 2013 16:11:32 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX19q1eQIA8pq1aNFp0Kcaus3zsHjLxRc9ejU9O57Q8 voq+LjXApmiBSN
From: Bjoern Hoehrmann <>
To: Matthew Morley <>
Date: Fri, 05 Jul 2013 16:11:31 +0200
Message-ID: <>
References: <> <>
In-Reply-To: <>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: " WG" <>
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: Fri, 05 Jul 2013 14:11:39 -0000

* Matthew Morley wrote:
>#1 I guess. Duplicate keys *SHOULD* fail, IMHO.
>I feel like I am being disruptive by posting this, but I really think we
>are going down a path of splitting hairs and missing the broader point of
>this issue. All the same, I'm posting as a reply to the initial thread
>post, instead of all along the chain of replies.

The broader point here is that the Working Group is supposed to document
the JSON format based on running code and rough consensus and changes to
what is in RFC 4627 require very strong justification and support. That
means duplicate names in objects will be permitted and parsers will not
be required to detect and report duplicate names.

Relying on duplicated names is a bad practise, and for parsers that
report only one of the names, it is a good practise to pick the last in-
stance, and of course parsers are always free to reject any content for
security reasons as they see fit, this's all largely agreed in the group
and people do not care terribly much how the specification conveys this.

I for instance would prefer telling people that picking the last value
is the logical and typical choice and the behavior of standard APIs like
JSON.parse and picking the first one or a random one instead is sure to
cause interoperability, security, migration, and other headaches -- over
fiddling with RFC 2119 keywords, but in the end it does not really have
an effect on how people are going to use and implement JSON in the wild.

We know all the open questions, as far as I am concerned we could just
write them all down and survey the Working Group; one implied question
above, as an example, is

  JSON parsers that treat objects with duplicate keys as malformed
  for security reasons should be made non-conforming in JSONbis.

I would strongly disagree with that and am quite sure other participants
would do the same; in studying the survey results the chairs might find
there is indeed a rough consensus JSON parsers should be allowed to re-
ject such JSON documents for security reasons, and then task editors or
whoever volunteers with implementing that in the specification prose.
Same for all the other issues, say

  Allow Unicode Signature in UTF-8 encoded application/json entities.

  Allow Strings at the top level.


Then we would be getting somewhere...
Björn Höhrmann · ·
Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·