IETF Logo Mail Archive

Re: [apps-discuss] json-pointer #5 - semantics [was: Feedback on draft-ietf-appsawg-json-pointer-00]

Mike Acar <macar@cloudmark.com> Tue, 05 June 2012 18:10 UTC

Return-Path: <macar@cloudmark.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 565CB21F8716 for <apps-discuss@ietfa.amsl.com>; Tue, 5 Jun 2012 11:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 w5sR7unIcqgE for <apps-discuss@ietfa.amsl.com>; Tue, 5 Jun 2012 11:10:03 -0700 (PDT)
Received: from mail.cloudmark.com (cmgw1.cloudmark.com [208.83.136.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6004821F85DB for <apps-discuss@ietf.org>; Tue, 5 Jun 2012 11:10:03 -0700 (PDT)
Received: from ht1-outbound.cloudmark.com ([72.5.239.25]) by mail.cloudmark.com with bizsmtp id Ji9r1j0010ZaKgw01i9ryV; Tue, 05 Jun 2012 11:09:51 -0700
X-CMAE-Match: 0
X-CMAE-Score: 0.00
X-CMAE-Analysis: v=2.0 cv=dpJZ+ic4 c=1 sm=1 a=LdFkGDrDWH2mcjCZERnC4w==:17 a=OzVNOVH2-ZIA:10 a=H8j7-3xrJYgA:10 a=-bUu6MBLYPwA:10 a=zutiEJmiVI4A:10 a=8nJEP1OIZ-IA:10 a=b6nfwRhkAAAA:8 a=48vgC7mUAAAA:8 a=_xtiB1xY00unlXvkgRsA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=LdFkGDrDWH2mcjCZERnC4w==:117
Received: from [172.20.2.21] (172.20.2.21) by auth-smtp.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 5 Jun 2012 11:09:52 -0700
Message-ID: <4FCE4B6F.8070708@cloudmark.com>
Date: Tue, 05 Jun 2012 11:09:51 -0700
From: Mike Acar <macar@cloudmark.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <4F4FD8A5.6010603@cloudmark.com> <1330638350.2531.11.camel@neutron> <4F514AF9.5010506@cloudmark.com> <9452079D1A51524AA5749AD23E003928077013@exch-mbx901.corp.cloudmark.com> <01173171-110F-4FBE-993A-E858B51E9068@mnot.net> <9452079D1A51524AA5749AD23E00392813E630@exch-mbx901.corp.cloudmark.com>
In-Reply-To: <9452079D1A51524AA5749AD23E00392813E630@exch-mbx901.corp.cloudmark.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.20.2.21]
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudmark.com; s=default; t=1338919791; bh=yyYpTP9TzkC14z5rnNjGA9zFuTjyv2RSWnSKaQd1kSM=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=HeJEf0Woz2E8lV9CCfYrFlS9LyKIh5BfmIZnd0B3ZBVkLM2Uv43PGbbP1zy26FVwe 5JAfzwKT02e/6XUrTv9wrErjtInb5/J4eOcmBVR7600+pjkjVqOMc3onm2aUeakjma 88CUfKe01+8muRsrI63MQ69rXwHcogtFcpX6yb0U=
Subject: Re: [apps-discuss] json-pointer #5 - semantics [was: Feedback on draft-ietf-appsawg-json-pointer-00]
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: Tue, 05 Jun 2012 18:10:04 -0000

On 05/31/2012 09:42 AM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mark Nottingham
>> Sent: Wednesday, May 30, 2012 8:46 PM
>> To: IETF Apps Discuss
>> Subject: [apps-discuss] json-pointer #5 - semantics [was: Feedback on draft-ietf-appsawg-json-pointer-00]

>> It seems like we need to add language stating that failing to match
>> a particular token can be considered an error, or can be used by a
>> particular application to effect some other behaviour. Make sense?

At first blush. But I think a spec that says "this can be an error or it 
can be implementation-defined" doesn't really constrain an 
implementation's behavior enough to be useful.

As Murray writes:

> I think the right approach is to say explicitly in pointer that it's
> left to the application using pointer to decide whether a match
> failure is an error or should be handled in some other way.

I think language that says "An application of JSON pointer needs to 
define semantics for these cases" would be helpful, maybe with an 
example for Patch.

-- 
Mike Acar -                                 - macar at cloudmark dot com

v2.26.15 | Report a Bug | By Email | System Status