# JSONPath IETF March 2022 Interim Meeting Agenda   {#jsonpath-ietf-march-2022-interim-meeting-agenda}

Date: 2022-03-09  
Time: 10:00 - 12:00 UTC

Chair: Tim Bray  
Chair: James Gruessing  
Area Director: Francesca Palombini

* [Datatracker][1]
* [Jabber](xmpp:jsonpath@jabber.ietf.org?join)
* [Minutes][2]

## Agenda   {#agenda}

* Draft Status
* Issues
* AOB
* Scheduling of Next Meeting

### Administrivia   {#administrivia}

* Note Takers
* Jabber Scribe
* Agenda Bashing

## Discussion   {#discussion}

### Draft Status   {#draft-status}

Tim: We are within 1 IETF of a versionto submit to IESG, does anyone
disagree?

Carsten: I agree

### Issues   {#issues}

Carsten: I don't know what "edit table 1 is", we should have some
examples, unsure what we have left to do with string normalization, we
should go through each of the issues

James: "Edit table 1" is an issue you created Carsten

Carsten: We should have a good look at the security considerations

Tim: Is there anything that won't get done if we don't assign it?

Carsten: We have people in the call that will take that responsibility

Carsten: The appendix should have a slightly larger example... there's
two ways: we have a single document and refer to it, or keep the in-line
examples simple, we need to decide

Glyn: We should gravitate towards strange use cases

Carsten: We previously decided to keep weird edge cases away from the
main document

Tim: We should have good examples as people will copy and paste them

Tim: We do need a security consideration section, for iregex DoS, but
what should go in ours?

Carsten: There's considerations for JSONPath itself - parser issues,
DoS, etc. And considerations for implementators about the wrong
expectations.

Tim: All JSONPath can do is extract information and doesn't work if you
don't have access to the document, you could say it doesn't introduce
any new vulnerabilities

Carsten: You introduce DoS if the runtime performance is unpredictable,
and if people think they can use it in certain ways without the
guarantees, e.g. normalization. If you're using it for a negative list,
as there may be ways to parse the list differently.

James: We should cover information exposure, i.e. if you allow external
input of a query an attacker could expose more data than intended

Tim: I have a hard time seeing a scenario here with that one

Stefan: There's a request to refer other documents, if we did include
that there would security considerations

Tim: We should have a thing there that says "Don't use `eval()`!"

Carsten: Maybe in 5 years we'll look at all our applications for
JSONPath injection as we do SQL injection today

Glyn: Can we assign the issues the issues in my email?

James: I have been doing that in the background.

Carsten: I can pick up #117

Glyn: #148? Put me down if you like.

Carsten: This is a quick thing to do.

Glyn: The first is #150, we already covered it. PR was merged yesterday.

Stefan: List selectors can contain all other selectors?

Glyn: Not all

Stefan: We need to include a list of included

Glyn: Which is now included, but doesn't include recursive descent

Carsten: I wouldn't mine swapping the sections

Glyn: I wanted to do that once #164 was done

Carsten: Make a new issue with the sections, and I'd love the ABNF be
defined

Glyn: I'll do that as part of the re-arrangement

Tim: Now for normalization and normalization paths #117

Glyn: The outstanding thing from #155 to bring out a single path and use
in the rest of the draft

Carsten: It's defined by its syntax, the singular path is defined by its
semantics, maybe we need to do this exercise

Tim: What else would we include?

Carsten: What we are trying to capture is the envelope of what relative
path can capture

Stefan: Wouldn't it be possible to name distinct selectors that will
return singular paths?

Carsten: That's the effect of the ABNF, yes

Glyn: My approach is to restrict it so only singular paths are allowed,
is that okay?

Stefan: We discussed this recently, how should we deal with it? Simply
we state we want singular path, or discuss returning nodesets?

Glyn: This is in #164

Carsten: We have to be careful where we need it, e.g. regex doesn't need
it

Glyn: Should we discuss this now?

Carsten: We need "exists all", looking for either one or all, if one
exists it doesn't matter if there's one or two of them

Glyn: The exists case is easier as the values have been computed, for me
regex is difficult, I don't know to AND or OR it

Tim: I find that quite convincing

Carsten: We go for singular paths for comparison and regex, and general
paths for exists

Stefan: General path also means nested filters?

Carsten: You could do that

Stefan: Do we restrict the selectors with existance tests or are all
allowed again?

Tim: Is this out in the wild?

Carsten: We would need to look at the tests

Stefan: I think we need some real world examples

Glyn: Carsten, can you put examples on #164

**Action**\: Carsten to look at examples where nested filters would be
useful, and find out if Christoph Burgmer has made tests.

Tim: Function notation is not in the current draft?

Stefan: I see a problem with functions returning numeric values, which
would require artimatic operators

Carsten: We've talked about "index", which violates our processing
model, would be nice to have a way to put names into the query

Tim: I'm a fan of YAGNI

Carsten: That's for software, not protocols which has to plan for the
unplanned

Stefan: I would like to do regex analysis on names, it doesn't qualify
as a function as it requires specifying the arguments

Glyn: Do you accept this breaks the processing model?

Carsten: It's maybe not a strong violation but it is outside what we've
been doing so far

Glyn: Is the idea for extension points to be used with or without an
RFC?

Carsten: There's a BCP about that

Glyn: How strict are we on the syntax checking?

Carsten: It should be stable.

Stefan: We can choose one the characters you're prosposing

Glyn: What happens to interop with this kind of model?

Carsten: The effect is obvious from a parse of the query

Glyn: Is it not possible to extend later?

James: That's where interop problems come about

Carsten: That will be too late

Tim: We want to avoid what happened with SQL

James: This doesn't eliminate that, but provides a sink-hole for
implementors and implementations

Carsten: We should write the policy, and some examples

James: We'll need IANA considerations right?

Carsten: Yes

Stefan: Could we include names or array indicies as a first extension?

Tim: Only if we can get consensus should we include it in the spec

Tim: @ sign optional #162

**Consensus**\: No

**Action**\: Message the Github issue

Tim: Related standards? #161

Carsten: It is useful if people coming from that document to this need
to relate to it, might be worth doing if someone writes a paragraph
about it

Glyn: I'm nervous about making reference to a non-free standard

Tim: Who's going to write this paragraph?

**Action**\: Request the issue maker on Github to write aforementioned
paragraph

Stefan: We shouldn't be referencing implementations of JSONPath

Tim: Output of normalized paths

Carsten: People should be able to find the syntax in the document, we
don't need to do anything else

Tim: Singular path - I think we've already discussed this one

Tim: Equality comparisons #145 - where did we get with it ?

Carsten: We don't. Can we close it?

**Consensus**\: Don't do it

**Action**\: Tim to describe why we're doing it

### AOB   {#aob}



[1]: https://datatracker.ietf.org/group/jsonpath/about/
[2]: https://notes.ietf.org/notes-ietf-interim-2022-jsonpath-02-jsonpath