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

Matthew Morley <> Mon, 07 January 2013 03:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 735AA21F8555 for <>; Sun, 6 Jan 2013 19:23:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o5t0OqVliaML for <>; Sun, 6 Jan 2013 19:23:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B7F8A21F8542 for <>; Sun, 6 Jan 2013 19:23:48 -0800 (PST)
Received: by with SMTP id eg20so14315415lab.16 for <>; Sun, 06 Jan 2013 19:23:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=ro39O8NhduStT3XQnHzOKdba0RXxFCku6N1ZtKZwe+0=; b=T+lGO1V3ghs/jOKLpcj9T7zG6i+wXkEVVd9qgldI9Gujnk5bZZBQvLflo5qxqKr7Vh p9U2EwoxPZ4MO5AXpkIh/Gn6DT5bOqG2ZoOdEda2ViL0ElTRb2pXahrb6bqKZs7O1D+O hoUjQbtcgx9n/fZJXQao97j/geG0qL12DNW78jliBaNhCgqdEZA5Y0AQeajk3h5el9v4 d36+jfyumPccZgA25oh+iEnwd6isnGsAHz4tPXXir4CphVvq8Wlmrxkp5wFHnEHwdl1P zeZ//T3sk1MSpUuw1Sc98NkH6JvhaEQw6j0phZl3/SSzyfOG6/2U9gfZsdlgKQwoeyur HPaA==
MIME-Version: 1.0
Received: by with SMTP id u8mr24179427lbz.50.1357529027336; Sun, 06 Jan 2013 19:23:47 -0800 (PST)
Received: by with HTTP; Sun, 6 Jan 2013 19:23:47 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <1357515310.6827.23.camel@polyglot> <> <>
Date: Sun, 06 Jan 2013 22:23:47 -0500
X-Google-Sender-Auth: Ny6xVmqSjYgYU1tb3ochhYuU63Q
Message-ID: <>
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
From: Matthew Morley <>
To: Robert Sayre <>
Content-Type: multipart/alternative; boundary="bcaec554df40725ba304d2aa5b85"
X-Gm-Message-State: ALoCoQkseFN0BN9XMR5BpHemeDeMh+JmTe/uzFafyzJU4WYqijcqqNmAYh821wImFeRPyHqzQvfI
X-Mailman-Approved-At: Mon, 07 Jan 2013 08:26:22 -0800
Cc: IETF Apps Discuss <>, Mark Nottingham <>, IETF Discussion <>, "Paul C. Bryan" <>, 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 03:23:50 -0000

On Sun, Jan 6, 2013 at 8:15 PM, Robert Sayre <> wrote:

> 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

For me the deficiency is not in the pointer, but patch format being

One approach is to push that *one* test, structure conformity, into the
pointer syntax. Another is via the type operation.

If a vague patch is generated, vague results are to be expected.

Testing for *just* the structure does not really create a verbose patch
either. Which is why I am not overly in favor of a syntax specific to
arrays, with this argument.

For example, if you are replacing a key in a object, the json-pointer to
get there, *and* the value would be required to ensure it is not
vague. Setting /a/b/c to 6 when it was 4, and applying that patch without
such tests to a document where /a/b/c is 13, is also vague.

Without tests, the patch format is optimistic at best, there is no escaping
this fact. Changing the spec for the json-pointer syntax to address
vagueness in json-patch specification seems wrong to me.

If json-pointer is not well suited, because of the desire for a descriptive
path which includes structure and value, perhaps a different specification
is need. One that provides both path, structure, and value confirmation in
the pointer string. Though at that point is more of a query path, so
something like JsonPath (

I prefer the test/type operations and the json-pointer specification, with
optimistic patches.

Matthew P. C. Morley