IETF Logo Mail Archive

Re: [Json] Counterproposal on work items

Francis Galiegue <fgaliegue@gmail.com> Wed, 27 February 2013 18:45 UTC

Return-Path: <fgaliegue@gmail.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 3F01521F89C3 for <json@ietfa.amsl.com>; Wed, 27 Feb 2013 10:45:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.546
X-Spam-Level:
X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XiTGXmkHZOG for <json@ietfa.amsl.com>; Wed, 27 Feb 2013 10:45:28 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DAC1D21F89A6 for <json@ietf.org>; Wed, 27 Feb 2013 10:45:27 -0800 (PST)
Received: by mail-ee0-f44.google.com with SMTP id l10so813257eei.3 for <json@ietf.org>; Wed, 27 Feb 2013 10:45:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=j9BuRUkz2lCTGnDa33mA7yrn5m7XzYOLBEaPG9Pf9cY=; b=nrIJdNl5FVwlnzJ3wLMl2S5NeAcGdXd0RZw8p1Y98gjf+LtQyEM4BwHO4Nvh589jU8 5fC+c3aSJbSRir0z8wapA7hNVAbtDPPj3Pzv8FPBPK2Jf+EHiqY/HowJMdZ/qhquvkzp zMrw6zs3Ibz9c+cUu+REr3qUcsDFqWPePg+q2WO0MZb0rG3CD2jD/WAtUyck/9ZvtTla TWXsIdcYmm2LXrekaFMlP6esTQOIxdpYcTqj2CYxBcAyPOJ52tKRmx+K1loOMZum/pyF H2uAvMTNWX0P0GCaiUaRlLYENcv3TNDc7bNhDBQ5jipund17lNp9jbcA/nT2zpiRAPGS F3Qw==
MIME-Version: 1.0
X-Received: by 10.14.205.68 with SMTP id i44mr8590098eeo.25.1361990727119; Wed, 27 Feb 2013 10:45:27 -0800 (PST)
Received: by 10.14.1.7 with HTTP; Wed, 27 Feb 2013 10:45:27 -0800 (PST)
In-Reply-To: <012801ce1519$f146fc90$d3d4f5b0$@packetizer.com>
References: <CAHBU6ityBeA+M-PEme09gO_jVySr33-X308i1UttxrQwSgYmGQ@mail.gmail.com> <0F513426-F26D-48F4-A7A8-88F3D3DA881B@vpnc.org> <CAK3OfOjFCnR8k1csVOkSKTDpA8exDvYdAijn80HKD5zwNzzeSw@mail.gmail.com> <4514F5D7-4A7E-476F-987D-C4C617F2BCBD@vpnc.org> <4D80AE86-4DBA-4236-9E2A-A06F2F9C30F7@mnot.net> <00b001ce1509$c4c99fc0$4e5cdf40$@packetizer.com> <CAC4RtVDXwPRL-Cz_Xf-kjU3dzzY+JheDGivSE9hF2v1NLkWEgQ@mail.gmail.com> <CALcybBApAiJYaEAV+aOCxNaWHQUBSiJRvXNzDVVBbnaTFNN_1A@mail.gmail.com> <012801ce1519$f146fc90$d3d4f5b0$@packetizer.com>
Date: Wed, 27 Feb 2013 19:45:27 +0100
Message-ID: <CALcybBAqzR23omVELsXc=-KW9q+eM7Hnp+1JL1nkCKhU6U6xDg@mail.gmail.com>
From: Francis Galiegue <fgaliegue@gmail.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Content-Type: text/plain; charset="UTF-8"
Cc: Mark Nottingham <mnot@mnot.net>, Barry Leiba <barryleiba@computer.org>, Paul Hoffman <paul.hoffman@vpnc.org>, json@ietf.org
Subject: Re: [Json] Counterproposal on work items
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion related to JavaScript Object Notation \(JSON\)." <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, 27 Feb 2013 18:45:30 -0000

On Wed, Feb 27, 2013 at 7:40 PM, Paul E. Jones <paulej@packetizer.com> wrote:
>> Which means there will always be the sour point of specs like JSON Patch
>> having to specify that an operation must have one and only one member
>> named "op". Because "doesn't break compatibility" means the "no
>> duplicate member names" will remain a SHOULD, right?
>
> If you want more than one member named "op", why not just use an array?
>

That is not the problem here.

The problem is that one JSON Patch operation is an object, and this
object must have a member named "op", so far so good.

BUT due to RFC 4627 being lax here, the draft says that there should
be "one and only one member" by that name. It should not have to say
that. RFC 4627 should make duplicate member names outright illegal.
Well, not 4627, but whatever will supersede/complement it.

-- 
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com

v2.23.0 | Report a Bug | By Email