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

Nico Williams <> Wed, 03 July 2013 06:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4F5A21F9A84 for <>; Tue, 2 Jul 2013 23:45:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MQdeP+BYaKyF for <>; Tue, 2 Jul 2013 23:45:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C41C821F9C63 for <>; Tue, 2 Jul 2013 23:45:21 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 30D0020203C for <>; Tue, 2 Jul 2013 23:45:19 -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=itr8nUQGeMQaxiYfnTjR QAlidr0=; b=gxy5+LEOe8632U2NAGqBBZWMGeXhIFgzxYMI7uEcqZxH96i5rQel QByIifRQZSvgmPK8NBC/rWvPbgmOfBIXkAZVRwbCiq89VyRqWGbSGwXsCgk9dmk1 n91fdn7N0gw7c9r1OoqHJDEMRa3enxlGxhSkeEvbcLhWdcdCMhmwPIA=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id BC968202038 for <>; Tue, 2 Jul 2013 23:45:18 -0700 (PDT)
Received: by with SMTP id t56so4820865wes.7 for <>; Tue, 02 Jul 2013 23:45:17 -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=F8pZ8ecaZqAvK2il6Pm8BGEcKVMd6wXr7Q71jnwASvE=; b=FB0ZKNAVFmzIit91regdWgXO0e6DSFkgv/oNUMIkgDw+HAmDxrnHIkmiRY88eZNzrH JkbQBBieA3N7WCc45ZCLrd1s9kH4CgxJ1763BJKW3ClDnjaY9A6nhmSCClN7tAN5E5T/ PTW2IJcOB0ANfZDXWHyg49hoD7mdcZ7fMrdi6pxWa5KFgMWCDUSQRxOA7xYY4qU4d5dY NLfr+pv5NokIsUTKi+fqm+4c+WCl2+ZT3aZ0oCQTUDyrKRR0WdETdeyN5jFBTQqvnj5b MR9V/8JqhzM+MSgIReprC9hV/+dsQUmCzZkzfELBO0h345q6pAOjY8e4lOAndd56jZbV luIA==
MIME-Version: 1.0
X-Received: by with SMTP id b1mr8337182wiz.28.1372833917282; Tue, 02 Jul 2013 23:45:17 -0700 (PDT)
Received: by with HTTP; Tue, 2 Jul 2013 23:45:17 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 3 Jul 2013 01:45:17 -0500
Message-ID: <>
From: Nico Williams <>
To: Eliot Lear <>
Content-Type: text/plain; charset=UTF-8
Cc: Paul Hoffman <>, " 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: Wed, 03 Jul 2013 06:45:26 -0000

On Wed, Jul 3, 2013 at 1:35 AM, Eliot Lear <> wrote:
>> In short, for streaming parsers (and generators) there's nothing we can do.
>> What we can do is RECOMMEND that a) generators not produce duplicates
>> (and explain how streaming ones cannot prevent dups), and b) that
>> parsers use the last name (and explain how streaming ones will produce
>> all dups).
> To me this isn't strong enough.  I have some sympathy for both the
> existing base and for parsers, but generators as an architectural
> component should generate unambiguous output, streaming or otherwise.
> And that follow's Postel's Law:

How can a streaming generator do that?  The API for one might look like:

ObjectAdd(context, name, value)

There's no way a minimal-state streaming generator (but I repeat
myself; the whole point of a streaming interface is to keep minimal
state :) can detect duplicates with O(1) state (probabilistic
structures with false positives won't be acceptable either).

> "In general, an implementation must be conservative in its sending
> behavior, and liberal in its receiving behavior."

I've seen this maligned too.  How many times have we heard this as a
root cause of security vulnerabilities on receiver sides?  We should
be much more exacting, but in *this* case we can't be.

It's not a question of what is ideal...  If we were starting from
scratch we might forbid O(1) state generators and even parsers.  But
it's too late for that and we have consensus to achieve.

BTW, we're retreading.  We should try not to, but it's difficult to
avoid as no one can have read *every* post since the WG's inception.
I think it's fair to say that on this issue there's no consensus to
ban the bad behavior (duplicate names).  Please don't blame me for
that lack of consensus.