Re: [apps-discuss] JSON Patch

"Manger, James H" <James.H.Manger@team.telstra.com> Fri, 25 November 2011 01:58 UTC

Return-Path: <James.H.Manger@team.telstra.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 F317E21F8549 for <apps-discuss@ietfa.amsl.com>; Thu, 24 Nov 2011 17:58:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.468
X-Spam-Level:
X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=-2.467, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RELAY_IS_203=0.994]
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 djoFDDEF+1DS for <apps-discuss@ietfa.amsl.com>; Thu, 24 Nov 2011 17:58:43 -0800 (PST)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id ED60E21F8548 for <apps-discuss@ietf.org>; Thu, 24 Nov 2011 17:58:41 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.69,568,1315144800"; d="scan'208";a="57769702"
Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 25 Nov 2011 12:58:39 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6540"; a="43578273"
Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipccni.tcif.telstra.com.au with ESMTP; 25 Nov 2011 12:58:39 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Fri, 25 Nov 2011 12:58:38 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>, Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 25 Nov 2011 12:58:37 +1100
Thread-Topic: [apps-discuss] JSON Patch
Thread-Index: AcyqeK61EdldVFNhQn2VEHzqx3rt4wAj5tQw
Message-ID: <255B9BB34FB7D647A506DC292726F6E113885C474E@WSMSG3153V.srv.dir.telstra.com>
References: <4EB1482E.1040600@adobe.com> <4EB14C2E.8040208@gmx.de> <1320254564.2622.37.camel@neutron> <4EBBA0DD.9020605@gmx.de> <4ECBC843.60900@gmx.de> <255B9BB34FB7D647A506DC292726F6E113884047C4@WSMSG3153V.srv.dir.telstra.com> <CABkgnnWMWL43cjBYpXP2tfxUCwLbt5Q2hYvBvtK3A6BKKhm=BA@mail.gmail.com> <4ECDEEC4.3050007@it.aoyama.ac.jp>
In-Reply-To: <4ECDEEC4.3050007@it.aoyama.ac.jp>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] JSON Patch
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, 25 Nov 2011 01:58:44 -0000

>> <James.H.Manger@team.telstra.com>  wrote:
>>> On escaping: how about replacing every '/' in an object member's name with the Unicode REPLACEMENT CHARACTER U+FFFD when creating a JSON pointer.

>On 2011/11/24 11:08, Martin Thomson wrote:
>> Interesting that you choose U+FFFD in the same way that backslash was
>> chosen as an escape character in the first place.  I'm not a big fan
>> of that approach.

On 2011/11/24, Martin J. Dürst wrote:
> Yes, please don't. The semantics of U+FFFD is mostly a character that 
> wasn't successfully converted from some other encoding. Overloading that 
> with "escaping a slash" is a bad idea.

JSON pointer theoretically needs a proper escaping mechanism since it reserves 1 char as a delimiter. However, choosing 1 char not to support avoids a fair amount of inevitable confusion and complexity. I chose U+FFFD REPLACEMENT CHARACTER. If you don’t like that choice, how about U+001F INFOMATION SEPARATOR ONE.

Not supporting pointers for names with, say, a U+FFFD char is not ideal but hinders almost no practical uses.
Escaping '/' with '\/' could be worse. It seems certain to cause significant confusion. You can no longer simply split a pointer on '/' characters, but need to use, say, a regular expression to parse a pointer. A / can be legitimately escaped in a JSON string as "\/", and apparently often is [http://stackoverflow.com/questions/1580647/json-why-are-forward-slashes-escaped] so developers will read and write 0, 1, 2, or 3 backslashes (but only 1 %2F), when they are dealing with a name with a '/', or a '\'. Will "\x" be undefined when x isn’t \ or /?
 
Object member name:
Logically:  Bjørn/Carsten and bar
In JSON  : "Bjørn/Carsten" and "bar"
      Or : "Bjørn\/Carsten" and "bar"

JSON pointer:
Logically:  Bjørn\/Carsten/bar
In JSON  : "Bjørn\\/Carsten/bar"
      Or : "Bjørn\\\/Carsten\/bar"
In IRI   :  Bjørn%2F/Carsten/bar


--
James Manger