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

Tim Bray <> Sun, 07 July 2013 01:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAA7F21F9D8E for <>; Sat, 6 Jul 2013 18:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.867
X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id blZZeh5IZnEU for <>; Sat, 6 Jul 2013 18:44:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 160BA21F9C4D for <>; Sat, 6 Jul 2013 18:44:09 -0700 (PDT)
Received: by with SMTP id ha12so2503585vcb.35 for <>; Sat, 06 Jul 2013 18:44:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=HpdZ4gDsO3sY9Yd1Q8n0y396xT/1nVEb6fz8A4Wwyk8=; b=mosCwdq0wVi4Ion6Fde3JkoprHB3w9c2zVmKmB9pPK0hxLet6IW7NpnZgBoRKLZa/b qJM8oe6mJr1UskLJnepnMzE9yqjH79+SVowtYInq0a0838BXD6svN3TLhjtDd3AS7bsx BJewtEG6pIJC94LNJbk7QSmE+TVWRUUeiFSEr7LIC1YJs/gwBTU0cbsXu2yNXvvga1zv jmez3+jdLxSrB0Kf6wAc8kz6UcpRJWfSuDZwHrWjZ/739Erietb69/ZlF3pOjOKhyroV bpiyoAVRau9WZDHUtS15wuQ3IQfghWEPHBPmfwdCaFYicpzrOK7zCg1yc26BTNad3T2L 1Tlw==
MIME-Version: 1.0
X-Received: by with SMTP id xg18mr11000911vcb.57.1373161448109; Sat, 06 Jul 2013 18:44:08 -0700 (PDT)
Received: by with HTTP; Sat, 6 Jul 2013 18:44:07 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <00cd01ce7a9f$19adeaa0$4d09bfe0$> <00d701ce7aa6$cc5fe700$651fb500$> <>
Date: Sat, 6 Jul 2013 18:44:07 -0700
Message-ID: <>
From: Tim Bray <>
To: Nico Williams <>
Content-Type: multipart/alternative; boundary=001a11331c08558aab04e0e21021
X-Gm-Message-State: ALoCoQleeLObqECdSewjUR8hx+rojHHafexGKn777dhBjV9mEnLgx+YR/MFQk5hw0tcG8cxMPBHF
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:44:15 -0000

This feels like a no-brainer to me, but that’s probably because (as I’ve
said before) I’m an API guy, and the only use for JSON objects in my world
is to transfer a hash table or database record or whatever from here to
there, and there, and in such a situation dupes can never be useful or
intended and can only be a symptom of breakage (or, in the JOSE case, a
symptom of a malicious attack on my crypto).


On Sat, Jul 6, 2013 at 6:20 PM, Nico Williams <> wrote:

> 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
> streaming.
> 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.
> Nico
> --
> _______________________________________________
> json mailing list