Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt

Julian Reschke <julian.reschke@gmx.de> Thu, 12 April 2012 14:10 UTC

Return-Path: <julian.reschke@gmx.de>
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 18A0221F859A for <apps-discuss@ietfa.amsl.com>; Thu, 12 Apr 2012 07:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.779
X-Spam-Level:
X-Spam-Status: No, score=-102.779 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 CJNa1bJ-GqD0 for <apps-discuss@ietfa.amsl.com>; Thu, 12 Apr 2012 07:10:38 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A140321F856C for <apps-discuss@ietf.org>; Thu, 12 Apr 2012 07:10:37 -0700 (PDT)
Received: (qmail invoked by alias); 12 Apr 2012 14:10:34 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp072) with SMTP; 12 Apr 2012 16:10:34 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+ONR0QgUmOdS7eI93b2DSho6H9Gwfv/Tja50RX1l T88d0B/UE6rMPj
Message-ID: <4F86E258.3040409@gmx.de>
Date: Thu, 12 Apr 2012 16:10:32 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> <1332261146.2171.7.camel@neutron> <4F68B37E.9060608@gmx.de> <1332262482.2171.11.camel@neutron> <4F68BDB7.7030808@gmx.de> <1332269074.2171.21.camel@neutron> <4F68D295.2040401@gmx.de> <1332277294.2171.25.camel@neutron> <4F68F2F8.7000207@gmx.de> <9452079D1A51524AA5749AD23E0039280949C7@exch-mbx901.corp.cloudmark.com> <4F697B48.1050305@it.aoyama.ac.jp> <4F699B49.1010108@gmx.de>
In-Reply-To: <4F699B49.1010108@gmx.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt
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: Thu, 12 Apr 2012 14:10:39 -0000

On 2012-03-21 10:11, Julian Reschke wrote:
> On 2012-03-21 07:55, "Martin J. Dürst" wrote:
>> On 2012/03/21 6:40, Murray S. Kucherawy wrote:
>>
>>> Does there need to be one-and-only-one?
>>
>> In theory, not necessarily. In practice, not having a lot of variation
>> usually helps.
>>
>>> Or I guess more accurately, do we need to say this is the one and only
>>> way to do this? Seems like that closes the door to someone coming up
>>> with a better idea.
>>
>> Fragment pointers into datastructures such as JSON isn't exactly a brand
>> new field with lots of new possibilities. And XPointer has shown that
>> making it too complicated cuts out most implementations. My proposal
>> would be to somehow include an extensibility hatch, but then say this is
>> the one and only one.
>
> In XML, as far as I understand, the escape hatch is that identifiers do
> not allow brackets, and thus these are free for defining new addressing
> schemes. So in JSON Pointer, we'd need to escape a few more characters
> when using in fragment identifiers.
>
> Also, it seems this needs to be coordinated with a potential spec
> defining a "+json" media type suffix...
> ...

It would be good if we made up our minds whether we are defining a 
fragment identifier syntax for application/json or not.

My proposal is to keep things simple for now and thus not to do it; that 
implies removing or clarifying the examples in the spec.

Best regards, Julian