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

Nico Williams <> Wed, 03 July 2013 16:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 280C121F9CB1 for <>; Wed, 3 Jul 2013 09:04:57 -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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id prR5YVStozq6 for <>; Wed, 3 Jul 2013 09:04:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4777521F99D5 for <>; Wed, 3 Jul 2013 09:04:52 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id F0E7B6B007B for <>; Wed, 3 Jul 2013 09:04:51 -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=dIlNIuUJ+3swuTxK33lQ 3AdJi7E=; b=jISMwCsMxLpaDUYunDBqxBDUCaRTrFaaM7XV0L/CBfsMoguKhHN5 wHHHZ3rdBq66QWu047bik5zdaDWW7rNSh8oPxdMIjlcEa3RmORcDn+L/BAwyQUms o6DpHVAjSqzFK9RXvOjJfEwMFxc7D9kFGpHBVjuaXQt5EOEgWShJQNg=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 812436B0056 for <>; Wed, 3 Jul 2013 09:04:51 -0700 (PDT)
Received: by with SMTP id w57so285125wes.15 for <>; Wed, 03 Jul 2013 09:04:50 -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=1DHDv/rX+BM+OdJSOuKSI0MHYWEnlU+k7cZnP9JKyRE=; b=AgC55TWErFuodCmeK4t2bmxTSG69mCGkugJedRfoE6tFn7Oij9mNRm1v8gTtvDEnYp WclW385lmWFoH7wrhthXCuNrHpfCwnCigMojGe2T+bmos5PF/ZTqyVvgt6VOVaQaGMP9 FjzabVLDEJeGKsc9667/TkgGaylotJbiQ8FK0krtjNwjG+xGrJyNBGsWhCmCZj+LRnGR qJxdF01UotqTIk2noasfAeIdxKyAQ9zmawA7pzrxtLDLQie+r3uhV5J+Yk21n6Xuy0wY 8b3SuMOpLQJCU5qcLyONi6aHBP38JoqP5HIks7qzP9dx1Ag5KaMvH/ZrjimtSitT3rWr adtQ==
MIME-Version: 1.0
X-Received: by with SMTP id ha7mr763627wib.28.1372867490164; Wed, 03 Jul 2013 09:04:50 -0700 (PDT)
Received: by with HTTP; Wed, 3 Jul 2013 09:04:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 3 Jul 2013 11:04:50 -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 16:04:57 -0000

On Wed, Jul 3, 2013 at 1:57 AM, Eliot Lear <> wrote:
> On 7/3/13 8:45 AM, Nico Williams wrote:
>> On Wed, Jul 3, 2013 at 1:35 AM, Eliot Lear <> wrote:
>>> 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:
>> ObjectStart(context)
>> 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).
> You've got to retain state.  You don't have to retain the value, but you
> do have to retain the name.  It's O(k), and knowing you I know you're
> smart enough to approach that (because I am and so I'm using inductive
> theory ;-).  And I'll bet you a nickel that this is not going to be
> anyone's high order bit.

You'd only have to retain state to satisfy this up-till-now
non-existent requirement.

>>> "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.
> That's a fair point about security, but even in THAT context one should
> be conservative in what one sends.  And yes we CAN be more exacting, but
> at a cost.  What we're debating is the cost of ambiguity.

It's a psychological cost too.  No one wants their code rendered
non-compliant by a new RFC.  That's part of what's making it hard to
get consensus.

To be clear I have no implementations that would be broken (because I
own no implementations, but I've worked on two that also wouldn't be
broken) by any of the proposed changes.  But I have written a
streaming XML encoder, for example, and I wouldn't want to have to
write O(N) state streaming encoders for JSON.

>> 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.
> Nothing to be done about installed base, as I wrote.  Let's write down
> what the right thing to do is.  These are RFCs we're generating, now laws.

There's no IETF police, that's for sure, but these are law-like
documents.  We should write ones that people can strive to meet.

*My* opinion here is that in the case of streaming generators and
parsers the burden of avoiding/dealing with duplicate names should be
one layer higher: at the applications using them.  But it's also my
opinion that some such apps may not be able to do anything about this
either, which is why my proposal is we write SHOULD and explain when
it's OK to not stick to the SHOULD.

>> 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.
> WGs often retread.  Sometimes we find ways to get around our blocks.  We
> both have no time for blame.

Understood.  I was voicing what I thought the consensus was.  I wanted
to make sure that was clear.