IETF Logo Mail Archive

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

Eliot Lear <lear@cisco.com> Mon, 08 July 2013 07:32 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 3D0E011E81A3 for <json@ietfa.amsl.com>; Mon, 8 Jul 2013 00:32:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.459
X-Spam-Level:
X-Spam-Status: No, score=-110.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 jB3vrYDehPk4 for <json@ietfa.amsl.com>; Mon, 8 Jul 2013 00:32:10 -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 90AE711E81B0 for <json@ietf.org>; Mon, 8 Jul 2013 00:32:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=936; q=dns/txt; s=iport; t=1373268727; x=1374478327; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=t5FjVk28QVBCYZGf0+eIlugjQbWIdFSMlZO+Rk0xksU=; b=imc3HQAG6S1mie+apVy+89vAVka0U+WmU1ZeVOfbHBdh+meqIbPjrjT5 QDpAdTv7+fOv5fX1+tof5pMs/NRfVpiaCbKc/kx+zStpgh7aatbuhhSDA JI8RKe/8sBqTrNqbY/3o9FKJH07X4QB9bPNBzz2oKQzNQHfFld3e0XqzU k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgYFAN5o2lGQ/khL/2dsb2JhbABagwmEB71ZgQ4WdIIjAQEBBCNVARALGAICBRYLAgIJAwIBAgErGgYNAQcBAYgLp1CQToEmjkUHglSBHAOXU5FIgxM6
X-IronPort-AV: E=Sophos;i="4.87,1018,1363132800"; d="scan'208";a="14956807"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 08 Jul 2013 07:32:04 +0000
Received: from mctiny.local ([10.61.160.194]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r687W2dK010285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jul 2013 07:32:02 GMT
Message-ID: <51DA6AF2.8050205@cisco.com>
Date: Mon, 08 Jul 2013 09:32:02 +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: John Cowan <cowan@mercury.ccil.org>
References: <B86E1D4B-1DC8-4AD6-B8B3-E989599E0537@vpnc.org> <CAK3OfOj3MNNhjwo2bMa5CgoqynzMRVvviBXC8szxt5D17Z7FDg@mail.gmail.com> <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <20130703201143.GL32044@mercury.ccil.org> <00cd01ce7a9f$19adeaa0$4d09bfe0$@augustcellars.com> <00d701ce7aa6$cc5fe700$651fb500$@augustcellars.com> <CAK3OfOiWrWCvNQneokyycV1Jb98M=UR-U7z0dhxUjzVdf+PwDw@mail.gmail.com> <CAKd4nAhMfz_NAFL4YmLFX_=69JizWoPvLac+1_yr0K2LJap3DQ@mail.gmail.com> <20130707181121.GB11346@mercury.ccil.org>
In-Reply-To: <20130707181121.GB11346@mercury.ccil.org>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Stephan Beal <sgbeal@googlemail.com>, "json@ietf.org" <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: Mon, 08 Jul 2013 07:32:15 -0000

And this is where we simply can't code ourselves out of a paper bag. 
The reason one generally doesn't hardcode rules at the lower layer is
that you don't have visibility as to what the poor practice is.  Here we
do.  ALSO, I'll go one farther.  The generator itself needn't always
keep state.  It simply needs to be told to keep state or not.  If it is
told not to, then the upper layer is assumed to be doing so, but at that
point it is not a matter for the wire protocol, which is where we are.

Eliot

On 7/7/13 8:11 PM, John Cowan wrote:
> Stephan Beal scripsit:
>
>> i'm for not splitting them into categories, as this document really has no
>> business (IMO) specifying that level of implementation detail. Specify the
>> duplicate keys as poor practice leading to
>> unspecified/implementation-defined behaviour, and be done it.
> +1 to that.  "Unspecified behavior" is another way of saying "is an error".
>

v2.23.0 | Report a Bug | By Email