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]
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
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.
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
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
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
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