Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard

Robert Sayre <> Mon, 07 January 2013 01:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3520B21F84F8; Sun, 6 Jan 2013 17:15:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pPiw64mRZ-Bq; Sun, 6 Jan 2013 17:15:07 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::229]) by (Postfix) with ESMTP id 09FBB21F84F6; Sun, 6 Jan 2013 17:15:06 -0800 (PST)
Received: by with SMTP id ds1so1765670wgb.4 for <multiple recipients>; Sun, 06 Jan 2013 17:15:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cerFm2Nwtrzw/JgZDkqrf/mLp5kDOiTPKeIMc5/Si4E=; b=maSQOtsZTCbPbcNXJtr6yUdwI0Dgu/NEqc6x+CqmspBZqdHggdmHiNCmAogyUU8M5/ GVBqA5MCk2dr2TL/rFU3vbfXXUXYK3NJIg6bwdVIRips5OxkdoYWvCUvJ+kmoy1ME3n6 uvS1zp1vSDqnXXAi7J1UZIJlM+hsT2x8BilrXEe7iyi0RYaYETDUWj13vpuzPUi9b/8P N8Acj7DmjcTetotwhr743TPc+nA2m8YeMGe08wdnAhcPA1m6qBb1D8GPdAwyI4uIfofb JSKNwu4cqhxv43//yP+zFiuDQuSFImu8ydFpGrYXinEAdmIOkGWyT/WHzAGrXgqLzJlW 4o2A==
MIME-Version: 1.0
Received: by with SMTP id bd8mr6568125wib.33.1357521305755; Sun, 06 Jan 2013 17:15:05 -0800 (PST)
Received: by with HTTP; Sun, 6 Jan 2013 17:15:05 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <1357515310.6827.23.camel@polyglot> <>
Date: Sun, 06 Jan 2013 17:15:05 -0800
Message-ID: <>
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
From: Robert Sayre <>
To: "Paul C. Bryan" <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Mark Nottingham <>, IETF Discussion <>, IETF Apps Discuss <>, IESG <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Jan 2013 01:15:08 -0000

On Sun, Jan 6, 2013 at 4:01 PM, Robert Sayre <> wrote:
> On Sun, Jan 6, 2013 at 3:35 PM, Paul C. Bryan <> wrote:
>> Common concurrent editing algorithms should, in my opinion, use techniques
>> to ensure the state of the resource (relative to the edits) is known. In
>> HTTP, we have ETag and If-Match/If-None-Match preconditions. In JSON Patch,
>> we have (a rudimentary) test operation.
> links to make sure we're not talking past each other:

Actually, let me restate my point in terms of RFC5789 (HTTP PATCH).
That will make it easier to communicate.

RFC 5789 Section 2.2 (Error Handling) defines error conditions which
correspond directly to the point at hand: 'Conflicting state' and
'Conflicting modification'. Section 5 of the JSON Patch document
directly references RFC5789, Section 2.2.

With that in mind, let's note that there are several normative
requirements in the JSON Patch document directed at conflicting state.
One such example is from Section 4.2 'remove'. It reads: "The target
location MUST exist for the operation to be successful.". If a server
received an HTTP JSON Patch request attempting to delete a
non-existent location, this text from RFC5789 would seem to apply:

"Conflicting state:  Can be specified with a 409 (Conflict) status
      code when the request cannot be applied given the state of the
      resource.  For example, if the client attempted to apply a
      structural modification and the structures assumed to exist did
      not exist ..."

The text above wouldn't be necessary in JSON Patch or RFC5789 if
RFC5789 required checking ETags and preconditions for all use cases
(it doesn't). The larger point is that RFC5789, and patch formats in
general, make all sorts of allowances for *non-conflicting* concurrent
edits to a common ancestor. The problem with leaving this JSON Pointer
array ambiguity in the draft is that patch messages which should
trigger '409 Conflict' errors can be mistakenly and 'successfully' (in
the HTTP sense) applied to a different structure than intended.

In summary, the JSON Patch draft allows patch documents to be
formulated that make it impossible to correctly implement RFC5789, a
normative reference.

Here are the questions the IESG focuses on during review:
"Reviews should focus on these questions: 'Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?'"

For JSON Patch, the answer to the first question is 'no', because of a
deficiency in JSON Pointer. The change needed to make these documents
acceptable as part of the Internet infrastructure is to make Arrays
explicit in JSON Pointer syntax.

- Rob