Re: [apps-discuss] more feature requests, was: JSON patch: "test" operation

Sam Johnston <> Fri, 30 December 2011 10:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90D1621F8BAC for <>; Fri, 30 Dec 2011 02:10:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.143
X-Spam-Status: No, score=-5.143 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ox-OsoK3VOjm for <>; Fri, 30 Dec 2011 02:10:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 136CB21F8B76 for <>; Fri, 30 Dec 2011 02:10:33 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Fri, 30 Dec 2011 10:10:34 UTC
Received: by with SMTP id r1so7845819ghr.1 for <>; Fri, 30 Dec 2011 02:09:36 -0800 (PST)
Received: by with SMTP id v66mr51045555yhd.61.1325239776219; Fri, 30 Dec 2011 02:09:36 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 30 Dec 2011 02:09:15 -0800 (PST)
In-Reply-To: <1325222688.18477.25.camel@neutron>
References: <> <> <> <> <> <> <1322779521.1958.1.camel@neutron> <> <1325222688.18477.25.camel@neutron>
From: Sam Johnston <>
Date: Fri, 30 Dec 2011 11:09:15 +0100
Message-ID: <>
To: "Paul C. Bryan" <>
Content-Type: multipart/alternative; boundary="20cf300513921a926e04b54c6e75"
Cc: IETF Apps Discuss <>
Subject: Re: [apps-discuss] more feature requests, was: JSON patch: "test" operation
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Dec 2011 10:10:36 -0000

On Fri, Dec 30, 2011 at 6:24 AM, Paul C. Bryan <>wrote:

> **
> First, I think commit messages should probably be out of scope for JSON
> Patch specifically. That said, we should allow the ability to build on the
> specified format, allowing for extensions, including additional (more
> domain-specific) operations.

Maybe so, but saying what you're doing when manipulating an object is often
a good idea.

>  I'm generally against the idea of using out-of-band metadata such as
> header fields in an HTTP request, mostly because it ties metadata to the
> transfer protocol rather (what I believe rightly should be tied to the
> document).

The distinction between data and metadata isn't always clear — to me a
document detailing manipulations could just as easily be separated from the
description of it (or it could be redundant — with the headers reflecting
data contained within the document). It's also not always possible to
define what goes in a document, so if you have metadata (like commit
messages) then I'd argue you should use HTTP's existing metadata channel
rather than an "envelope" like SOAP (or JSON).

> I'm interested in feedback on the possibility that I add text stating that
> if an operation cannot be determined for a given patch object, then an
> implementation should ignore it. Thoughts?

To me this sounds dangerous — add versioning and if there's sufficient
demand for extensions then just include them in a future version?

>  2) The ability to *copy* (not *move*) objects around.
> This is another example of something trivial for the patch implementation
> to perform, so I'm inclined to add it to the next draft.

This begs the question as to whether PATCH should be creating new
resources; the scope of PATCH ("to modify an existing HTTP resource") is
fairly clear on this IMO. Furthermore, MOVE and COPY verbs are useful for
other applications (e.g. cloud APIs) so promoting them from WebDAV, sans
XML dependency, would likely be useful for other applications.