User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e
Mime-Version: 1.0
Message-Id: <d2ab505d-bc99-482d-a8e5-694f67ce932b@www.fastmail.com>
In-Reply-To: <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org>
References: <159467093010.19477.7181341398452455173@ietfa.amsl.com>
 <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org>
Date: Wed, 15 Jul 2020 19:40:03 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: dispatch@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/TAPdKDOl35iYlLiIUoPoPcgMU4E>
Subject: Re: [dispatch] draft-goessner-dispatch-jsonpath-00.txt
Precedence: list

I see three major differences here from JSON pointer:

1. this selects multiple values in the same way that XPath does, so this=
 includes // and * and other such things
2. predicates (the execution of script is a major concern and really beg=
s for a security model), which is largely a consequence of having multip=
le values but not strictly
3. syntax

Of these, the syntax difference seems gratuitous.  JSON pointer isn't ex=
actly awesome~1but it has fewer variants and it isn't inclined toward im=
plementation by eval(), which is an anti-feature.

Personally, I would much rather see a new JSON pointer developed, which =
would be evolutionary rather than revolutionary; more version 2 than com=
petition.  It would be relatively simple to add multi-value and relative=
 evaluation to JSON pointer if those are the key use cases.  That said, =
I don't have a lot of insight into what the implementation landscape is.=
  If JSON pointer is moribund, then we might want to acknowledge that.  =
My sense is that it has some relatively wide support, including modifica=
tions for relative references (https://json-schema.org/draft/2019-09/rel=
ative-json-pointer.html).

Predicates are where this gets tricky, but I would suggest that you need=
 to decide the question of whether they are included from the outset.  P=
ersonally, these seem like they could be a big risk and I would defer th=
eir addition if not cut them out, but I don't know what sort of use case=
s are driving this.

This seems big enough to be a working group (particularly if you put the=
 predicate stuff in scope).


On Tue, Jul 14, 2020, at 15:14, Carsten Bormann wrote:
> (Reply-To set to dispatch@ietf.org)
>=20
> I would like to initiate discussion for draft-goessner-dispatch-jsonpa=
th:
>=20
> https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html
>=20
> It says:
>=20
> > This document picks up the popular JSONPath specification dated
> > 2007-02-21 and provides a more normative definition for it.
> > It is intended as a submission to the IETF DISPATCH WG, in order to
> > find the right way to complete standardization of this specification=
.
> > In its current state, it is a strawman document showing what needs t=
o
> > be covered.
>=20
> (For some reason the abstract landed in the Contributing note; typical=
=20
> Internet-Draft deadline day botch.)
>=20
> This is a widely implemented specification that has been around for=20=

> more than a decade; now may be a good opportunity to finally go ahead=20=

> and turn it into a proper Internet standards document.  The immediate=20=

> cause for writing this up now is that some IoT discovery work (some of=
=20
> which happens in W3C) can make good use of JSONPath.  Clearly, we=20
> already have JSON Pointer (RFC 6901) for a more limited set of=20
> applications; the specification would do good in defining how these tw=
o=20
> fit together.
>=20
> There is no active WG that immediately fits this work.
>=20
> Eventually CDDL may pick JSONPath up in the form of a predicate=20
> operator; this might make the CBOR WG the right group (which probably=20=

> would then go ahead and write up another specification that makes=20
> JSONPath useful for querying CBOR instances that go beyond the JSON=20=

> generic data model).
>=20
> Reopening the JSON WG may be another approach, as may be creating a=20=

> short-lived targeted WG.
>=20
> Please discuss!
>=20
> Gr=C3=BC=C3=9Fe, Carsten
>=20
>=20
>=20
> > Begin forwarded message:
> >=20
> > From: internet-drafts@ietf.org
> > Subject: New Version Notification for draft-goessner-dispatch-jsonpa=
th-00.txt
> > Date: 2020-07-13 at 22:08:50 CEST
> > To: "Stefan G=C3=B6ssner" <stefan.goessner@fh-dortmund.de>, "Stefan =
Gossner" <stefan.goessner@fh-dortmund.de>, "Carsten Bormann" <cabo@tzi.o=
rg>
> >=20
> >=20
> > A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt
> > has been successfully submitted by Carsten Bormann and posted to the=

> > IETF repository.
> >=20
> > Name:		draft-goessner-dispatch-jsonpath
> > Revision:	00
> > Title:		JSONPath -- XPath for JSON
> > Document date:	2020-07-12
> > Group:		Individual Submission
> > Pages:		14
> > URL:            https://www.ietf.org/internet-drafts/draft-goessner-=
dispatch-jsonpath-00.txt
> > Status:         https://datatracker.ietf.org/doc/draft-goessner-disp=
atch-jsonpath/
> > Htmlized:       https://tools.ietf.org/html/draft-goessner-dispatch-=
jsonpath-00
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-goessner=
-dispatch-jsonpath
> >=20
> >=20
> > Abstract:
> >   insert abstract here
> >=20
> >=20
> >=20
> >=20
> > Please note that it may take a couple of minutes from the time of su=
bmission
> > until the htmlized version and diff are available at tools.ietf.org.=

> >=20
> > The IETF Secretariat
> >=20
> >=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>