Re: [Jsonpath] May interim meeting minutes

Carsten Bormann <cabo@tzi.org> Sun, 13 June 2021 05:23 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: jsonpath@ietfa.amsl.com
Delivered-To: jsonpath@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAFA3A308A for <jsonpath@ietfa.amsl.com>; Sat, 12 Jun 2021 22:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mI80nAipl6zz for <jsonpath@ietfa.amsl.com>; Sat, 12 Jun 2021 22:23:51 -0700 (PDT)
Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69923A3089 for <jsonpath@ietf.org>; Sat, 12 Jun 2021 22:23:49 -0700 (PDT)
Received: from smtpclient.apple (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4G2jfn6f6Yz2xH0; Sun, 13 Jun 2021 07:23:45 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail-1E807AAB-6298-4825-95B0-ABD065FA2A63"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <1473679330.3620773.1623558032906@mail.yahoo.com>
Date: Sun, 13 Jun 2021 07:23:45 +0200
Cc: Tim Bray <tbray@textuality.com>, jsonpath@ietf.org, James <james.ietf@gmail.com>
Message-Id: <2DA4072F-3FB1-4498-B529-8187002A1BBD@tzi.org>
References: <1473679330.3620773.1623558032906@mail.yahoo.com>
To: Greg Dennis <gregsdennis@yahoo.com>
X-Mailer: iPhone Mail (18F72)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jsonpath/AhU5-Ril-V0hZBqTuBWTmSJDPNI>
Subject: Re: [Jsonpath] May interim meeting minutes
X-BeenThere: jsonpath@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A summary description of the list to be included in the table on this page <jsonpath.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jsonpath>, <mailto:jsonpath-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jsonpath/>
List-Post: <mailto:jsonpath@ietf.org>
List-Help: <mailto:jsonpath-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jsonpath>, <mailto:jsonpath-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Jun 2021 05:23:56 -0000

The authors. 

Sent from mobile, sorry for terse

> On 13. Jun 2021, at 06:21, Greg Dennis <gregsdennis@yahoo.com> wrote:
> 
> Regarding #94, who has merging responsibility? It was my understanding that it was the chairs.  I've asked this question before, and the result was for me to leave it for someone else.
> 
> Greg
> 
> On Sun, 13 Jun 2021 at 3:10 am, Carsten Bormann
> <cabo@tzi.org> wrote:
> On 2021-06-11, at 22:49, Carsten Bormann <cabo@tzi.org> wrote:
> > 
> >> Since that PR has a bunch of changes, it may be helpful to pull out a few for independent discussion/decision?
> > 
> > Yes, please.
> > There is lots of good stuff in there, but as a package it is inedible.
> 
> Well, I ate that sandwich now.
> 
> Given that some of us seem to like #97, I have picked (and slightly fixed up) most of #97 into #101.
> 
> I would propose that we merge that quickly and get on to the problematic aspect of #97:
> While the terms "object", "array", "number" are used in RFC 8259, it is never clear whether they refer to the concept or its representation in a JSON text.  That problem is irrelevant in RFC 8259 (which, after all, only defines the JSON text), but not here.
> The specimen showing this best is a new definition of "String" in #97, which is neither defining the JSON strings JSONPath operates on nor does it make clear that JSONPath has redefined string literals with respect to RFC 8259.
> ➔ We’ll need to decide whether there also is a different data model for strings in JSONPath or JSONPath just has a different notation.
> 
> I would expect that we'll go in and fix the other gaps opened by this PR later; right now I'd rather focus on technical work.
> 
> (Oh, and why are we stuck with #94?
> Three approvals.)
> 
> 
> Grüße, Carsten
> 
> -- 
> Jsonpath mailing list
> Jsonpath@ietf.org
> https://www.ietf.org/mailman/listinfo/jsonpath