Minutes interim-2022-jsonpath-03: Tue 10:00
minutes-interim-2022-jsonpath-03-202204261000-00

Discussion

Tim: Number of issues is growing fairly small, I was hoping to take this to WGLC soon

Tim: We've heard no objections to adopting iregexp, does anyone disagree with adopting?

[No objections or comment made by the attendees]

String Normalization (#117)

Tim: Nothing in the spec right now that says comparison character by character

Glyn: At least meeting I thought we settled on this

Carsten: We have two places, comparison operator and member selection

Tim: I think we have consensus here

Action: Tim to put a small PR together

Filter Expressions (#183)

Tim: We currently don't require parenthesis and Greg you argued for them?

Greg: It's not a technical issue, however it's more readability with, Stefan's
original blog post does include them, which means the vast majority will include
them.

Stefan: Are there any implementation aspects that you see for having parenthesis
in the expressions, or is it purely readability?

Greg: I think it's a readability issue, a parse could figure it out without

Tim: Readability is a subjective thing. Will this impact interop if we require it?

Stefan: Everybody who wants it, can have it, there may be some implementations
who don't need them, is this correct?

Greg: That's the question, I don't know if we have this in the comparison suite

Tim: A lot of implementations would require them, for interop that's a strong
argument to have them

Glyn: I just checked, all examples have them

Greg: We haven't tested without, and if an implementation requires them, giving
it an expression without them will not pass.

Stefan: There should be no backwards compatibility issue if we leave it out

Tim: I think the argument is that there would be multiple implementations, and
our goal is interop

Carsten: There's backwards and forward compatibility - what we don't have is
forwards compatibility with the existing implementations. Is this change worth
doing reducing forward compatibility, and we probably shouldn't do that.

Tim: If the plurality of implementations are doing a thing, we should do it too.

Greg: I know my implementation would fail, but I don't know about others.

Stefan: I agree with Greg to test it and get a feeling of the number of
implementations that don't require it, let's wait for the results

Carsten: We could just ask for it to be include

Greg: I've had test added via issues/PRs

Action: Glyn to add a test case

Tim: If it turns out a high proportion of implementations require it, we should
change our document.

Boolean Literal (#178)

Greg: I am happy for filters to have any and all JSON

Carsten: This is an addition for diagnostics, but doesn't really do much

Greg: Are you saying in a debugging scenario?

Carten: Yes

Tim: Do existing implementations support this?

Greg: Mine does, can't speak for others

Stefan: You can always write true == true instead but that's somehow crazy

Tim: Glyn do you see anything in the comparison test?

Glyn: Looks like there isn't any consensus, with a variety of results

Greg: Interesting that some give non-numeric results

Tim: I get the feeling a lot of implementations don't support this, and think we
should not introduce this

Greg: Are there quire a few that say "not supported"?

Tim: There's a lot not doing the right thing

Greg: I'd like to point out all the .NET implementations are in aligmment

Tim: Does someone want to make a strong argument for this?

Greg: The only practical use case is the debug scenario

Tim: I suggest we don't do this

Carsten: We should explain JSON values and boolean values that JSONPath uses itself

Consensus: Leave this, and leave an explanation

Security Considerations (#185)

Carsten: We should put a little bit of knowledge on this, and the problem is
that an implementor may not come upon the information, we really want to be
inclusive here.

Tim: The suggestion is to drop the first paragraph in 5.1, and as an implementor
it is difficult to understand what this text is telling me to do

Greg: I don't understand why Javascript eval() is bad.

Tim: It assumes it's code

James: JSON is valid Javascript code

Carsten: ... it can be ...

James: When you mix up data and code, things can go wrong, you shouldn't execute
JSON

Tim: And Javascript has JSON.parse()

Stefan: I originally used the underlying scripting engine, and used eval()
because it simply runs the code, and is a source of injection attacks.

Greg: We're not building this on the engine, we're defining what the expression
content should be, I don't know of an instruction that could be passed and
executed

Carsten: What is was going to propose was getting rid of the third sentence, and
the first two can contain all the warnings.

Glyn: This is similar to my concern about regexps

Tim: What specifically are we telling people not to do?

Carsten: It's not okay to inject attacker controlled text into your programming
runtime.

Greg: I wouldn't expect any serious programmers to do this

Tim: Maybe this is just an editorial issue, I'm saying remove it, Carsten says
improve it - I think we should improve it

Greg: Are we going to be editing the spec every time we find a new
vulnerability?

Carsten: There's a limitation, and we know this problem and if we don't write
this now the IESG will make us

James: We just have to answer to the vulnerabilities we know of at this point in
time. There's no exhaustive requirement.

Tim: As for the second paragraph, if you require I-JSON you should get
deterministic results. If you don't you may provoke non-deterministic behaviour.

Carsten: It's not limited to that specific case, and the question is will all
implementations use I-JSON and the answer is no

Tim: I don't understand how object ordering would be a vulnerability

Carsten: It's where two implementations don't use I-JSON, and they use different
ordering for duplicate key filtering

Carsten: Tim would you propose the text refers to I-JSON?

Tim: A little bit of text, yeah

Glyn: iregexp and handling non-iregexp expressions

Carsten: We just haven't defined extensions

Glyn: I'm speaking about the iregexp document

Carsten: I don't think there's a lot of people arguing that JSONPath must reject
that isn't standard, that would kill backward compatibility, we have to be
careful what we're asking for here. We just need to define for JSONPath what the
goals are.

Glyn: We should say something in iregexp about non-strict implementations

Julian: We had a problem where we wanted to add extensions, you close extension
points in the future if you allow those outside of the specification. If people
start using these it takes away from future implementations.

Carstejn: Do we want to put the onus on every implementor of JSONPath, or is
just something we recommend?

Tim: This feels to me like a SHOULD not a MUST.

Carsten: When you put in a SHOULD is when it doesn't need to be heeded.

Glyn: When you don't care about interop.

Tim: When it makes that implementation not cost effective.

Glyn: Testing is going to be a bottomless pit in this area.

Tim: You would not be friendly to SHOULD?

Carsten: I would rather defined terms that allow to distinguish implementations,
and why a checking implementation is a good idea

Tim: I'd be okay with that

Stefan: Where do you propose to write the SHOULD?

Tim: It would be towards the front of the document

Glyn: Should this go in iregexp and JSONPath?

Carsten: What Tim said is exactly what I plan to do

Other topics

Greg: Are we going to talk about functions?

Tim: I think we agreed not in 1.0

Greg: Does that mean length() won't be in 1.0?

Tim: Currently not supported

Carsten: We don't have that extension point, defining length is difficult

Greg: Real question is can we solve this in the next 30 minutes?

Tim: We should identify what extension points are or what they'd look like

Consensus: Length not to be part of spec

Carsten: I might right a PR on extensions