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

Nico Williams <> Sun, 07 July 2013 01:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7BE0A21F9A4A for <>; Sat, 6 Jul 2013 18:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.956
X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YNX0v6UxQY+N for <>; Sat, 6 Jul 2013 18:20:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8B55721F9980 for <>; Sat, 6 Jul 2013 18:20:23 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 033341F007C for <>; Sat, 6 Jul 2013 18:20:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type;; bh=ph6UsZXYpsJlpU2kFOue 5fMGvx0=; b=l6Lubt9MVqrABpRo7eJK9r5fS8ejVjPm5MbTtZeyFoZJaZSFvH2/ UWKmCqfDX2fWlVhnW/fNFw79fn1Y2TQXvANI/5P5m9MyiOgBRyfnX9Jqn13Li6OG mPMtYMyp9YH5s2o/ICJvszoS/z2hhIBBuXc3rVbXRabrARZv9QIyXBE=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 9D2931F0081 for <>; Sat, 6 Jul 2013 18:20:22 -0700 (PDT)
Received: by with SMTP id t59so2790272wes.20 for <>; Sat, 06 Jul 2013 18:20:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0Cv3ofJIz8fp1gruHKWWaclGJMtTKthqCZ3aK/tkN14=; b=ajMFIravGuVgmL/BgnbuHuK0vpq2NpxXY5LwmE7lcjAEdPEBl6m5fI5qC20uQyNoWF Uk3FuEMNXG7JVQ77Ck2KZ0TWSlqrytQ2TK+hQXtMQDXJO3kI7WVSBm6o0MIpZcv5UsXc KrzFRRUKpR+BBoZCllKdBWr4SEM4ot+OUnVOL3XXHTQhGjfiiyzyp/Yl3Q0p/A3HznXk U4blEXB60AcBukRpCLI+PDeqpf7Hwt/uHBbVQsE+YI3ysMMf+vnyDHtABNY8sro4IgIz SfeFs5xwbR9fXSD858Yea43r9HJnafbbvavaY/1faZK0ZN009b0IwKReRF3VD05n44BZ d1hA==
MIME-Version: 1.0
X-Received: by with SMTP id mu20mr26072776wic.38.1373160020760; Sat, 06 Jul 2013 18:20:20 -0700 (PDT)
Received: by with HTTP; Sat, 6 Jul 2013 18:20:20 -0700 (PDT)
In-Reply-To: <00d701ce7aa6$cc5fe700$651fb500$>
References: <> <> <> <> <> <00cd01ce7a9f$19adeaa0$4d09bfe0$> <00d701ce7aa6$cc5fe700$651fb500$>
Date: Sat, 6 Jul 2013 20:20:20 -0500
Message-ID: <>
From: Nico Williams <>
Content-Type: text/plain; charset=UTF-8
Cc: Jim Schaad <>
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: Sun, 07 Jul 2013 01:20:28 -0000

On Sat, Jul 6, 2013 at 7:13 PM, Jim Schaad <> wrote:
> Tim is not the only person saying this.  The JOSE working group has this as
> a requirement to be enforced in the documents it is producing.
> Specification that JOSE objects MUST fail validation if there are duplicate
> names in an object.

But does it follow (did you even mean to say) that since JOSE wants
requirement X (no dup names here) JSON should have it itself?

One might argue that otherwise JOSE implementations would have to use
JSON parsers that implement JOSE's requirement even though JSON
doesn't have the same requirement.  But then. JOSE implementations
also could use streaming JSON parsers and check for dup names
themselves.  So I don't think JOSE's requirement adds anything new to
the discussion.

We still need to decide (directly or indirectly) whether to impose dup
name checking on all JSON parsers, even minimal-state streaming
parsers, whether we want to impose a requirement on the parser and the
application (so we need not mention streaming), or on the parser if
it's not a streaming parser *and* the application if the parser is

My view (for whatever it counts) is that we don't have consensus [yet]
for imposing a requirement on parsers to reject objects with dup
names.  We've had at least a number of examples of streaming parsers
that cannot implement such a requirement -- the whole point of
streaming being nullified by state-keeping requirements like this one.
 So we'd have to explicitly decide that we don't want to allow minimal
state streaming parsers.  Might as well call for consensus on that.