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

"Paul C. Bryan" <> Sun, 06 January 2013 23:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C089B21F8586; Sun, 6 Jan 2013 15:35:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZBk35INM1-ZQ; Sun, 6 Jan 2013 15:35:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 006FA21F8584; Sun, 6 Jan 2013 15:35:12 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id AFBE56AB7; Sun, 6 Jan 2013 23:35:11 +0000 (UTC)
Message-ID: <1357515310.6827.23.camel@polyglot>
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
From: "Paul C. Bryan" <>
To: Robert Sayre <>
Date: Sun, 06 Jan 2013 15:35:10 -0800
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Content-Type: multipart/alternative; boundary="=-B1xg1qOCqeQSYLxluh/N"
X-Mailer: Evolution 3.4.4-1
Mime-Version: 1.0
X-Mailman-Approved-At: Mon, 07 Jan 2013 08:26:31 -0800
Cc: Mark Nottingham <>, IETF Discussion <>, IETF Apps Discuss <>
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: Sun, 06 Jan 2013 23:35:13 -0000

> On Sat, 2013-01-05 at 16:19 -0800, Robert Sayre wrote:


> 1) The ambiguity around arrays makes the patch format unsuitable for
> common concurrent editing algorithms.

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.


> 3) It's not possible to tell whether a JSON Pointer document is
> syntactically correct in isolation.

There is no such thing as a JSON Pointer document.

> This issue is a problem in practice, and it's a problem in theory as
> well. JSON-Patch messages aren't sufficiently self-descriptive, so
> they aren't appropriate for use in a RESTful system.

99% of RESTful systems I'm familiar with are based on HTTP. Where
optimistic concurrency is acceptable, HTTP preconditions seems to
provide acceptable coverage. Where more granularity or more pessimistic
concurrency is required, implementors are free to use their own
mechanisms, including more expressive predicates (as has been proposed
here, with my endorsement) and/or resource locking. These are
intentionally out of scope for JSON Patch.

Later in this thread, you wrote:

> Ah. I meant that the WG seems to be favoring "running code" a little
> too heavily in the presence of a bug. It's an old argument, and it's
> boring: "We can't change it now, there are already twelve users!"

I don't agree that this is a bug; it lacks a feature that you and some
others have requested. Our reasoning for resisting such change is

The reason I value implementations is because they endorse the
specification through tangible action. Some of their authors have
participated in this forum to help improve the specification and create
consensus around it. Unfortunately, you've raised objections quite late
in the process, and I'm personally not persuaded that the issues you've
raised warrants (likely significant) changes.