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

Nico Williams <nico@cryptonector.com> Wed, 03 July 2013 21:37 UTC

Return-Path: <nico@cryptonector.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 B42DE11E8263 for <json@ietfa.amsl.com>; Wed, 3 Jul 2013 14:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 i-VIvn7Prpo8 for <json@ietfa.amsl.com>; Wed, 3 Jul 2013 14:37:39 -0700 (PDT)
Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id C5F4411E80EA for <json@ietf.org>; Wed, 3 Jul 2013 14:37:39 -0700 (PDT)
Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id BA56A678069 for <json@ietf.org>; Wed, 3 Jul 2013 14:37:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Q3fweBcwX6B9AoA0M4Wh CqCJ+BY=; b=t270mgzAu+agkni7BCuenSourPfR2nXm7EpqBTpF0h9hR4BkxEXk fbKPxjyLOsteeDVzMNEH0Hqjz2JESG4VI7dFMgAX/h5ET7wsxt/aHQxHBTRhcqcI g+TuZ2pUdCJDqkXMEG2Wu88JConZHWNkdtCIboWMJI36FK9YQhUzp/Q=
Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 68D16678063 for <json@ietf.org>; Wed, 3 Jul 2013 14:37:38 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id c10so6708774wiw.2 for <json@ietf.org>; Wed, 03 Jul 2013 14:37:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CSm6lJ2bLgggueBKbrPyD3YuZyJO9NJP9F6E/Guv5yE=; b=CsBWcSDp6Xs+XM4wV2ppco8MQU4sK9ltpKCv9UmHsY26exiA5H0MTTzryhrolgAZoo W2LdmP9OOQflzgC9PErZuuWwu8/RmvNA4gzMr+BnTTZ1Y4MiVf7/Rxliau9FpwKOAUlQ QkwhX3JnwqgqpRp5HCbJZm574PHAwm3SyOoVDrdGWo98G2kQVFjGWTr5VzuaHaeztuT3 I/FKFf1AFZEMm5uwLAooJUdk1z2TS22DqQvSInifk8JHxZKc5I+odcag4KhZw3BR7hAb LuxXfM6YOR+Rn4ZtZ8GDoSFB38f6qu/rjyDH3cqpcMay2F4rBK7Zei6qljmt6jEPEGuq Rl6g==
MIME-Version: 1.0
X-Received: by 10.180.73.68 with SMTP id j4mr3185682wiv.10.1372887457112; Wed, 03 Jul 2013 14:37:37 -0700 (PDT)
Received: by 10.216.152.73 with HTTP; Wed, 3 Jul 2013 14:37:37 -0700 (PDT)
In-Reply-To: <51D48990.7090305@cisco.com>
References: <B86E1D4B-1DC8-4AD6-B8B3-E989599E0537@vpnc.org> <CAK3OfOj3MNNhjwo2bMa5CgoqynzMRVvviBXC8szxt5D17Z7FDg@mail.gmail.com> <51D3C63C.5030703@cisco.com> <51D48023.1020008@qti.qualcomm.com> <51D48990.7090305@cisco.com>
Date: Wed, 3 Jul 2013 16:37:37 -0500
Message-ID: <CAK3OfOijGyGMEaeM6CmV+AbRHq2aJ3KaEc7sbrGDvQYuzSCc3Q@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Eliot Lear <lear@cisco.com>
Content-Type: text/plain; charset=UTF-8
Cc: Pete Resnick <presnick@qti.qualcomm.com>, 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 21:37:44 -0000

On Wed, Jul 3, 2013 at 3:29 PM, Eliot Lear <lear@cisco.com> wrote:
> On 7/3/13 9:48 PM, Pete Resnick wrote:
>> Let's remember the meaning of these capitalized words in IETF
>> parlance. We use them "where it is actually required for
>> interoperation or to limit behavior which has potential for causing
>> harm." So a MUST would mean that not doing so would prevent
>> interoperation or cause harm. RECOMMENDED (like SHOULD) would also
>> mean that not doing so would prevent interoperation or cause harm, but
>> "that there may exist valid reasons in particular circumstances to
>> ignore a particular item, but the full implications must be understood
>> and carefully weighed before choosing a different course."
>
> I have to say that ambiguity of a language implies an introduction to
> interoperability problems.  But MUST we use MUST in those cases?   I
> would prefer the catch the problem when we have the opportunity.  If the
> WG feels differently, Meh.  As Nico said, deal with it at a higher layer.

I think we're very likely to get consensus for SHOULD language with an
out for streaming generators/parsers pushing the MUST to the
application.

We could force MUST with an out for streaming generators/parsers
pushing the MUST to the application, but it'd leave some implementors
on the rough side of consensus and unhappy.

I'd be very happy either way.

In the case of the application I mentioned object well-formedness is a
feature of the underlying DB so there's never a way to end up with
duplicate names, so using non-conformant generators/parsers is not a
problem: the result would be conformant.  As long as that's OK I'll be
happy.

Nico
--