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

Eliot Lear <lear@cisco.com> Wed, 03 July 2013 06:57 UTC

Return-Path: <lear@cisco.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87ACD11E8166 for <json@ietfa.amsl.com>; Tue, 2 Jul 2013 23:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.331
X-Spam-Level:
X-Spam-Status: No, score=-110.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nefrLjdStir for <json@ietfa.amsl.com>; Tue, 2 Jul 2013 23:57:26 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0C58811E8168 for <json@ietf.org>; Tue, 2 Jul 2013 23:57:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2754; q=dns/txt; s=iport; t=1372834646; x=1374044246; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Fny5qZ0RSDKcPAxekgZZmZhLfPZu1TqYRMC2qRRWqAk=; b=WZbBm+sxJph8UoieeW1E5IzTANx45MYMx4/I3TBfzLH5QVXtemA2kPTB kjvdzacUWid7mYQ/WeER0kxPcL6tDJtZ3teMCLECZ6jc+Gs23Ip2E2OFv mg2ykWieSsX4haqsCfX/YbdsAnX501kTHM71U9wYMa9hSTWlSqT2lsNxc g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAOzK01GQ/khN/2dsb2JhbABagwmEAr0bgQAWdIIjAQEBAwEjVQEQCxgCAgUWCwICCQMCAQIBKxoGDQEFAgEBiAUGqX6RHoEmjj8HglGBHAOTd4NTkUWDEzo
X-IronPort-AV: E=Sophos;i="4.87,986,1363132800"; d="scan'208";a="14783660"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 03 Jul 2013 06:57:24 +0000
Received: from mctiny.local ([10.61.175.226]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r636vMuC019790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 06:57:23 GMT
Message-ID: <51D3CB52.7040902@cisco.com>
Date: Wed, 03 Jul 2013 08:57:22 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <B86E1D4B-1DC8-4AD6-B8B3-E989599E0537@vpnc.org> <CAK3OfOj3MNNhjwo2bMa5CgoqynzMRVvviBXC8szxt5D17Z7FDg@mail.gmail.com> <51D3C63C.5030703@cisco.com> <CAK3OfOg5ErNO5zozaCB-qchSaUb-dy4Da5b1KKJNTM0Bnpm+1A@mail.gmail.com>
In-Reply-To: <CAK3OfOg5ErNO5zozaCB-qchSaUb-dy4Da5b1KKJNTM0Bnpm+1A@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org WG" <json@ietf.org>
Subject: Re: [Json] Proposed minimal change for duplicate names in objects
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2013 06:57:31 -0000

Hi Nico,

On 7/3/13 8:45 AM, Nico Williams wrote:
> On Wed, Jul 3, 2013 at 1:35 AM, Eliot Lear <lear@cisco.com> 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:
>
> 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.
>
>> "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 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.
>
> 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.

Eliot