Subject: [dispatch] draft-goessner-dispatch-jsonpath-00.txt

From: Carsten Bormann <[email-masked]>
Date: Tue, 14 Jul 2020 07:14:13 +0200

(Reply-To set to [email-masked])

I would like to initiate discussion for draft-goessner-dispatch-jsonpath:

https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html

It says:

> 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 to
> be covered.

(For some reason the abstract landed in the Contributing note; typical Internet-Draft deadline day botch.)

This is a widely implemented specification that has been around for more than a decade; now may be a good opportunity to finally go ahead and turn it into a proper Internet standards document.  The immediate cause for writing this up now is that some IoT discovery work (some of which happens in W3C) can make good use of JSONPath.  Clearly, we already have JSON Pointer (RFC 6901) for a more limited set of applications; the specification would do good in defining how these two fit together.

There is no active WG that immediately fits this work.

Eventually CDDL may pick JSONPath up in the form of a predicate operator; this might make the CBOR WG the right group (which probably would then go ahead and write up another specification that makes JSONPath useful for querying CBOR instances that go beyond the JSON generic data model).

Reopening the JSON WG may be another approach, as may be creating a short-lived targeted WG.

Please discuss!

Grüße, Carsten

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-goessner-dispatch-jsonpath-00.txt
> Date: 2020-07-13 at 22:08:50 CEST
> To: "Stefan Gössner" <[email-masked]>, "Stefan Gossner" <[email-masked]>, "Carsten Bormann" <[email-masked]>
> 
> 
> 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.
> 
> 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-dispatch-jsonpath/
> Htmlized:       https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath
> 
> 
> Abstract:
>   insert abstract here
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
>

---

From: Tim Bray <[email-masked]>
Date: Mon, 13 Jul 2020 22:31:49 -0700

During my time at AWS I worked very heavily with JSONPath and lamented a
useful referenceable spec. I would be happy to invest cycles into this
work. There currently isn't a JSON working group but I suppose it wouldn't
be too hard to reconstitute it for this purpose.

On Mon, Jul 13, 2020 at 10:14 PM Carsten Bormann <[email-masked]> wrote:

> This is a widely implemented specification that has been around for more
> than a decade; now may be a good opportunity to finally go ahead and turn
> it into a proper Internet standards document.  The immediate cause for
> writing this up now is that some IoT discovery work (some of which happens
> in W3C) can make good use of JSONPath.  Clearly, we already have JSON
> Pointer (RFC 6901) for a more limited set of applications; the
> specification would do good in defining how these two fit together.
>
> Eventually CDDL may pick JSONPath up in the form of a predicate operator;
> this might make the CBOR WG the right group (which probably would then go
> ahead and write up another specification that makes JSONPath useful for
> querying CBOR instances that go beyond the JSON generic data model).
>
> > To: "Stefan Gössner" <[email-masked]>, "Stefan Gossner"
> <[email-masked]>, "Carsten Bormann" <[email-masked]>
> >
> >
> > URL:
> https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/
> > Htmlized:
> https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath
> >
> >
> > Abstract:
> >   insert abstract here
> >
> >
> >
> >
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 14 Jul 2020 09:33:53 +0200

Il 14/07/2020 07:31, Tim Bray ha scritto:
> During my time at AWS I worked very heavily with JSONPath and lamented 
> a useful referenceable spec. I would be happy to invest cycles into 
> this work. There currently isn't a JSON working group but I suppose it 
> wouldn't be too hard to reconstitute it for this purpose.

+1

Mario

>
> On Mon, Jul 13, 2020 at 10:14 PM Carsten Bormann <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     (Reply-To set to [email-masked] <mailto:[email-masked]>)
>
>     (For some reason the abstract landed in the Contributing note;
>     typical Internet-Draft deadline day botch.)
>
>     This is a widely implemented specification that has been around
>     for more than a decade; now may be a good opportunity to finally
>     go ahead and turn it into a proper Internet standards document. 
>     The immediate cause for writing this up now is that some IoT
>     discovery work (some of which happens in W3C) can make good use of
>     JSONPath.  Clearly, we already have JSON Pointer (RFC 6901) for a
>     more limited set of applications; the specification would do good
>     in defining how these two fit together.
>
>     Eventually CDDL may pick JSONPath up in the form of a predicate
>     operator; this might make the CBOR WG the right group (which
>     probably would then go ahead and write up another specification
>     that makes JSONPath useful for querying CBOR instances that go
>     beyond the JSON generic data model).
>
>     > From: [email-masked] <mailto:[email-masked]>
>     > To: "Stefan Gössner" <[email-masked]
>     <mailto:[email-masked]>>, "Stefan Gossner"
>     <[email-masked]
>     <mailto:[email-masked]>>, "Carsten Bormann"
>     <[email-masked] <mailto:[email-masked]>>
>     >
>     >
>     > until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>     >
>     > The IETF Secretariat
>     >
>     >
>
>     [email-masked] <mailto:[email-masked]>

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo

---

From: Brian Rosen <[email-masked]>
Date: Tue, 14 Jul 2020 08:25:24 -0400

+1

And I note the discussion of an HTTP API working group, to which this work would fit in.

I’m currently working on a spec for emergency services that uses jsonpath, and the lack of a referenceable spec was a big concern.  

Brian

> On Jul 14, 2020, at 3:33 AM, Mario Loffredo <[email-masked]> wrote:
> 
> 
> 
>> During my time at AWS I worked very heavily with JSONPath and lamented a useful referenceable spec. I would be happy to invest cycles into this work. There currently isn't a JSON working group but I suppose it wouldn't be too hard to reconstitute it for this purpose.  
> +1
> 
> Mario
> 
>> 
>> On Mon, Jul 13, 2020 at 10:14 PM Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:
>> https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html <https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html>
>> 
>> It says:
>> 
>> > To: "Stefan Gössner" <[email-masked] <mailto:[email-masked]>>, "Stefan Gossner" <[email-masked] <mailto:[email-masked]>>, "Carsten Bormann" <[email-masked] <mailto:[email-masked]>>
>> > 
>> > 
>> > URL:            https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.txt <https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.txt>
>> > Status:         https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/ <https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/>
>> > Htmlized:       https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00 <https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00>
>> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath <https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath>
>> > 
>> > 
>> > Abstract:
>> >   insert abstract here
>> > 
>> > 
>> > 
>> > 
>> > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> > 
>> > The IETF Secretariat
>> > 
>> > 
>> 
>> https://www.ietf.org/mailman/listinfo/json <https://www.ietf.org/mailman/listinfo/json>
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/json <https://www.ietf.org/mailman/listinfo/json>
> -- 
> Dr. Mario Loffredo
> Web: http://www.iit.cnr.it/mario.loffredo <http://www.iit.cnr.it/mario.loffredo>_______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 15 Jul 2020 19:40:03 +1000

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 begs for a security model), which is largely a consequence of having multiple values but not strictly
3. syntax

Of these, the syntax difference seems gratuitous.  JSON pointer isn't exactly awesome~1but it has fewer variants and it isn't inclined toward implementation 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 competition.  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 modifications for relative references (https://json-schema.org/draft/2019-09/relative-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.  Personally, these seem like they could be a big risk and I would defer their addition if not cut them out, but I don't know what sort of use cases 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:
> This is a widely implemented specification that has been around for 
> more than a decade; now may be a good opportunity to finally go ahead 
> and turn it into a proper Internet standards document.  The immediate 
> cause for writing this up now is that some IoT discovery work (some of 
> which happens in W3C) can make good use of JSONPath.  Clearly, we 
> already have JSON Pointer (RFC 6901) for a more limited set of 
> applications; the specification would do good in defining how these two 
> fit together.
> 
> operator; this might make the CBOR WG the right group (which probably 
> would then go ahead and write up another specification that makes 
> JSONPath useful for querying CBOR instances that go beyond the JSON 
> generic data model).
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 15 Jul 2020 08:37:39 -0400

I haven’t seen json pointer in the wild, pretty much ever.  I’ve seen A LOT of jsonpath.  
But I’m not exactly doing mainstream interfaces.

Brian

> On Jul 15, 2020, at 5:40 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: Kévin Dunglas <[email-masked]>
Date: Wed, 15 Jul 2020 15:35:07 +0200

Hi,

In the Vulcain Internet-Draft we also have the need to select multiple
values. To do so I proposed a very simple extension to JSON Pointer (by
adding a new token: `*`):
https://tools.ietf.org/html/draft-dunglas-vulcain-00#section-4.1

The Vulcain draft also allows the negotiation of the selector format to
use. This feature has been added to support more document formats (such as
XML using XPath), but also to allow the use of JSONPath which is indeed
popular and more powerful.
However we have voluntarily decided to not recommend JSONPath and to not
implement it in the reference implementation because of the security
considerations already pointed out by Martin and because it would allow (as
GraphQL) a bad client to run easily very complex queries (which may be a
DOS/DDOS attack vector).

Kévin,

Le mer. 15 juil. 2020 à 14:38, Brian Rosen <[email-masked]> a écrit :

> > 2. predicates (the execution of script is a major concern and really
> begs for a security model), which is largely a consequence of having
> multiple values but not strictly
> > 3. syntax
> >
> > Of these, the syntax difference seems gratuitous.  JSON pointer isn't
> exactly awesome~1but it has fewer variants and it isn't inclined toward
> implementation 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
> competition.  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 modifications for
> relative references (
> https://json-schema.org/draft/2019-09/relative-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.
> Personally, these seem like they could be a big risk and I would defer
> their addition if not cut them out, but I don't know what sort of use cases
> are driving this.
> >
> >>> To: "Stefan Gössner" <[email-masked]>, "Stefan
> Gossner" <[email-masked]>, "Carsten Bormann" <[email-masked]
> >
> >>>
> >>>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Jul 2020 20:56:38 +0200

On 2020-07-15, at 15:35, Kévin Dunglas <[email-masked]> wrote:
> 
> However we have voluntarily decided to not recommend JSONPath and to not implement it in the reference implementation because of the security considerations already pointed out by Martin and because it would allow (as GraphQL) a bad client to run easily very complex queries (which may be a DOS/DDOS attack vector).

Security considerations are an important point in the definition of JSONPath.
Instead of other formats adopting varying subsets of JSONPath that they happen to deem secure, I think it would be better to have a “secure” profile of JSONPath.
Note that this isn’t XPath (which is Turing equivalent…).

Grüße, Carsten

---

From: Brian Rosen <[email-masked]>
Date: Wed, 15 Jul 2020 16:19:10 -0400

+1

> On Jul 15, 2020, at 2:56 PM, Carsten Bormann <[email-masked]> wrote:
>