IETF Logo Mail Archive

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

Eliot Lear <lear@cisco.com> Mon, 08 July 2013 09:05 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 12FF621F9A6C for <json@ietfa.amsl.com>; Mon, 8 Jul 2013 02:05:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.463
X-Spam-Level:
X-Spam-Status: No, score=-110.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 vt5D92Z+M37i for <json@ietfa.amsl.com>; Mon, 8 Jul 2013 02:05:45 -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 2EA6E21F84B6 for <json@ietf.org>; Mon, 8 Jul 2013 02:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=591; q=dns/txt; s=iport; t=1373274323; x=1374483923; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mja6zBGf8M+RNwhpYXCGJ/P17gaX9LKC8MPhi82vmFc=; b=MWHghU4wIIfuhjFpZ0CBdOLJwS1BMPNMT3e6PbQWQ7V+8rMIsXgbWdGI NMFnnyqSsVjqHm4Cd0o8ISa3/eomevfQcofyTcHU2O56FxhBqIBqmIMJA m5WRVWcO7b5zHGkXVZgDbijWR3TX9Uj7hfzdC2nXpmGyh2aDw+mUv+M5Z s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgYFAG9/2lGQ/khR/2dsb2JhbABagwmEB71ZgRAWdIIjAQEBAwEjVQEQCw4MAgUWCwICCQMCAQIBKxoGDQEHAQGIBQanM5BagSaORQeCVIEcA5dTkUiDEzo
X-IronPort-AV: E=Sophos;i="4.87,1019,1363132800"; d="scan'208";a="14959545"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 08 Jul 2013 09:05:05 +0000
Received: from mctiny.local ([10.61.211.183]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r68952i6029437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jul 2013 09:05:02 GMT
Message-ID: <51DA80BE.8000902@cisco.com>
Date: Mon, 08 Jul 2013 11:05: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: Stephan Beal <sgbeal@googlemail.com>
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> <72BA0BFC-1C4D-4537-8B39-8B32F38D63E3@yahoo.com> <51da79b4.84e9440a.45eb.ffffaadeSMTPIN_ADDED_BROKEN@mx.google.com> <CAKd4nAhinYSTRz_-Xnms0CxEz_zik1kM0WyY_LNfWj2do70GPQ@mail.gmail.com>
In-Reply-To: <CAKd4nAhinYSTRz_-Xnms0CxEz_zik1kM0WyY_LNfWj2do70GPQ@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "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 09:06:02 -0000

On 7/8/13 10:46 AM, Stephan Beal wrote:

>
>
> From me, certainly. i don't see "MUST NOT SEND" as being too helpful
> because the receivers need to be able to recognize the existence of
> dupes in that case. i.e. it implies a MUST on the consumers, and the
> "must" on the consumers is what i find most prickly in this particular
> topic.
>

No such implication exists.  Often we say "MUST NOT" to the sender and
then prescribe  "MAY or SHOULD" some behavior (like an error) the
receiver.  There are many reasons for this, but a good one is security
or resource processing.

v2.23.0 | Report a Bug | By Email