IETF Logo Mail Archive

Re: [Json] Counterproposal on work items

Francis Galiegue <fgaliegue@gmail.com> Wed, 27 February 2013 18:21 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 16D3621F8947 for <json@ietfa.amsl.com>; Wed, 27 Feb 2013 10:21:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.543
X-Spam-Level:
X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 Pj7htWaElywG for <json@ietfa.amsl.com>; Wed, 27 Feb 2013 10:21:20 -0800 (PST)
Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id BC39521F8942 for <json@ietf.org>; Wed, 27 Feb 2013 10:21:19 -0800 (PST)
Received: by mail-ee0-f45.google.com with SMTP id b57so793883eek.32 for <json@ietf.org>; Wed, 27 Feb 2013 10:21:18 -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=lveRsT/LrQpCKwEHbWFTyt+SkKeJpz3HBGKwtG+oKo4=; b=CU2DJv6QPysB4bRAOqjj0Gn6jGenCvgLS+5ZcFWRbV2M3ulIExqUMq+eoqJLWIZPRq /MUAdDpTb+BS4u0zAelew8ve5QxcIseuWdtR5XdNyekH+B1Q0mEtbraor0zxriEvK+sA vk2FAVdpqijbYp2cniy3rfjwHhpE0IKIkEnxFRB8xeW473RE0nQHKT/mrSQfI3axerSb m7wIVL3hLd2CHdqI5BXHJ5uO1PwU15ZZkgJD4rs9HqRNfQ+6qUX4L7Gtxvtjn5bmoSld ntVxAt+iikQR8d0LNA0t7r4yMMJFi6U1P03uWaDzMN5gsNkBehS6u6jSSPPN9TYLhINp R1uA==
MIME-Version: 1.0
X-Received: by 10.14.194.198 with SMTP id m46mr8507764een.8.1361989278471; Wed, 27 Feb 2013 10:21:18 -0800 (PST)
Received: by 10.14.1.7 with HTTP; Wed, 27 Feb 2013 10:21:18 -0800 (PST)
In-Reply-To: <CAC4RtVDXwPRL-Cz_Xf-kjU3dzzY+JheDGivSE9hF2v1NLkWEgQ@mail.gmail.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>
Date: Wed, 27 Feb 2013 19:21:18 +0100
Message-ID: <CALcybBApAiJYaEAV+aOCxNaWHQUBSiJRvXNzDVVBbnaTFNN_1A@mail.gmail.com>
From: Francis Galiegue <fgaliegue@gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Content-Type: text/plain; charset="UTF-8"
Cc: "Paul E. Jones" <paulej@packetizer.com>, Mark Nottingham <mnot@mnot.net>, 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:21:21 -0000

On Wed, Feb 27, 2013 at 7:15 PM, Barry Leiba <barryleiba@computer.org> wrote:
[...]
>
> Indeed; I had talked with him back in August, as well, with the same
> response.  And as the likely responsible AD for any WG that forms, I
> can say that I strongly agree with the "doesn't break compatibility"
> point.
>

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?

I personally hate this wording in JSON Patch because it doesn't really
impose constraints on the format of JSON Patch itself, it also imposes
constraints on _parsers_. And this is a problem. Many parsers will
just _not_ yell on duplicate member names, and RFC 4627 currently
allows them to do so.

Just my 2e-42 cents,
-- 
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com

v2.23.0 | Report a Bug | By Email