Re: [Json] RFC 4627bis vs RFC 6902 (JSON Patch)

Nico Williams <> Thu, 20 February 2014 17:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7C7961A0053 for <>; Thu, 20 Feb 2014 09:44:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rC9zt1FvgUcW for <>; Thu, 20 Feb 2014 09:44:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2672E1A01AF for <>; Thu, 20 Feb 2014 09:44:40 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id B19682F4075 for <>; Thu, 20 Feb 2014 09:44:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type;; bh=UysC+H3MAshMARjT5uq8 3mGeV/U=; b=MzX1LpcJRMwH8dMz2eTj+QQULAY2QQs8gpGSiktEWRsXKHOCh99e l3wA1yDVHueS1nVR4Kt+hEaAyz9G8447cqyAlDR84khz7i5hZx0G4626zUGgSPcg +ptSiDKVwGeFpRK9XWk9C2zKcb+HA9NjWNJYtJYuOZQUEH7obIIX5JM=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 57B7E2F406D for <>; Thu, 20 Feb 2014 09:44:36 -0800 (PST)
Received: by with SMTP id w61so1673497wes.26 for <>; Thu, 20 Feb 2014 09:44:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C1AGKpVjzEFodxtJHIm82OOim0HIP185IYAcucajlGY=; b=eKkBlSO/qsIeoyb7B18EgS7FbxxMkE7cquG7EZbrbcyNI2gCOrsQkbOnoi1IglMOZ8 yDKP7qVHwYiC6wdVd9j4OOHgfGkHPDTr1NRoWjGOc4E6Fv06rRuVCZdQ992pGfRcazCi VdSWhVeQrFpbTKaotzhsDYH+0xlYg3YXUJYr7nWsnCQ0r1wtRsObYgFs94YLnAMGYNaR q2WUG63ztmA7vjvE1WXk6GYta3bdcC1B0yeWs+V+lSge8rFXEoCtmMtA3/gDrdWLhoSE d7ad5tiooOrl3cQYRsGrsKFBC3bDPXvIFkBXeknw18H1Ji29Ea+gmoXXW15hzT7SpVNC BAiQ==
MIME-Version: 1.0
X-Received: by with SMTP id ef3mr8225665wib.39.1392918274992; Thu, 20 Feb 2014 09:44:34 -0800 (PST)
Received: by with HTTP; Thu, 20 Feb 2014 09:44:34 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 20 Feb 2014 11:44:34 -0600
Message-ID: <>
From: Nico Williams <>
To: Francis Galiegue <>
Content-Type: text/plain; charset="UTF-8"
Cc: Barry Leiba <>, "" <>
Subject: Re: [Json] RFC 4627bis vs RFC 6902 (JSON Patch)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Feb 2014 17:44:41 -0000

On Thu, Feb 20, 2014 at 11:35 AM, Francis Galiegue <> wrote:
> On Thu, Feb 20, 2014 at 6:31 PM, Barry Leiba <> wrote:
>>> The latter makes sense on the _producer_ of a patch operation;
>>> however, on the parser side, should a parser receive a "malformed"
>>> (f.e duplicated "op") operation, it seems to me that RFC 6902 expects
>>> the parser to raise an error -- which RFC 4627bis does not mandate.
>> What do you see as a conflict?
>> The JSON spec gives general parameters for JSON, and allows duplicates.
>> The JSON Patch spec gives specific parameters for a specific use of
>> JSON.  For that use, duplicates are not allowed.
>> That all looks just fine to me, and absolutely consistent.
> Not to me. As I see it, 75+% of JSON parsers on the "market" just
> cannot parse JSON Patch correctly because of the restrictions imposed
> by RFC 6902. Note: parse, not emit (or "consume, not produce" -- or
> whatever metaphor suits you).

JSON Patch predates the discussions as to RFC4627bis, so a bit of
mismatch is to be expected.  JSON Patch says "objects MUST have
exactly one ..." but parser behavior is not specified, so it's unclear
if that's a requirement for encoders or parsers.  Even if you
interpret that as a requirement for parsers, the requirement may be
met by the application rather than the parser (e.g., when the
application uses an online JSON parser).

We had very many very lengthy threads on subjects like this in the
JSON WG, and I'm pretty sure that we discussed JSON Patch in
particular as well.  You might want to look at the archives.

> IOW: I don't see "MUST have a unique member named 'foo'" and
> "behaviour is unpredictable" as being consistent with one another.

The former is insufficiently prescriptive, therefore ill-defined,
therefore consistent with the latter.

FWIW, the JSON WG had proposals to improve this and other aspects of
JSON, but it was heavily constrained by _actual_ practice in the wild.