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

"Paul C. Bryan" <paul.bryan@forgerock.com> Fri, 30 December 2011 05:24 UTC

Return-Path: <paul.bryan@forgerock.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0675211E8089 for <apps-discuss@ietfa.amsl.com>; Thu, 29 Dec 2011 21:24:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.298
X-Spam-Level:
X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soTz4bkKqC9Q for <apps-discuss@ietfa.amsl.com>; Thu, 29 Dec 2011 21:24:53 -0800 (PST)
Received: from eu1sys200aog118.obsmtp.com (eu1sys200aog118.obsmtp.com [207.126.144.145]) by ietfa.amsl.com (Postfix) with SMTP id 8866E11E807F for <apps-discuss@ietf.org>; Thu, 29 Dec 2011 21:24:52 -0800 (PST)
Received: from mail-yx0-f169.google.com ([209.85.213.169]) (using TLSv1) by eu1sys200aob118.postini.com ([207.126.147.11]) with SMTP ID DSNKTv1LIz59UQlKwUrV/KIznu8YK9govqfL@postini.com; Fri, 30 Dec 2011 05:24:52 UTC
Received: by yenq10 with SMTP id q10so9326584yen.14 for <apps-discuss@ietf.org>; Thu, 29 Dec 2011 21:24:50 -0800 (PST)
Received: by 10.236.73.230 with SMTP id v66mr50458585yhd.61.1325222690789; Thu, 29 Dec 2011 21:24:50 -0800 (PST)
Received: from [192.168.1.5] (S0106a021b762dbb3.vf.shawcable.net. [174.1.40.184]) by mx.google.com with ESMTPS id c44sm53581451yhm.5.2011.12.29.21.24.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Dec 2011 21:24:49 -0800 (PST)
Message-ID: <1325222688.18477.25.camel@neutron>
From: "Paul C. Bryan" <paul.bryan@forgerock.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Date: Thu, 29 Dec 2011 21:24:48 -0800
In-Reply-To: <4EFC8A08.7000105@gmx.de>
References: <4ED64A26.5030003@gmx.de> <BC564D94-6D00-4D63-863A-8AAD00E57B3A@tzi.org> <4ED77513.3070506@gmx.de> <6E443D75-D1AC-451F-9B17-115C9A6C7696@mnot.net> <4ED7F8C2.9030804@gmx.de> <37E09A53-E9F4-45D2-BB8F-79655BECDBB2@mnot.net> <1322779521.1958.1.camel@neutron> <4EFC8A08.7000105@gmx.de>
Content-Type: multipart/alternative; boundary="=-VS8u/qoIW7xiHB+rnuuK"
X-Mailer: Evolution 3.2.2-1
Mime-Version: 1.0
Subject: Re: [apps-discuss] more feature requests, was: JSON patch: "test" operation
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Dec 2011 05:24:54 -0000

On Thu, 2011-12-29 at 16:40 +0100, Julian Reschke wrote:

> Hi there,
> 
> in discussions in Apache Jackrabbit space, two more features have
> been 
> mentioned as potentially useful:
> 
> 1) The ability to send additional data along with the actual patch;
> such 
> as a plain text string describing the change (think "commit"
> message), 
> or user information.


I've had a few thoughts here.

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.

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).

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?
 

> 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.

Paul