►
From YouTube: IETF-JSONPATH-20220426-0800
Description
JSONPATH meeting session at IETF
2022/04/26 0800
https://datatracker.ietf.org/meeting//proceedings/
A
D
Always
I'm
always
echoey.
Unfortunately,
I've
not
yet
put
dampening
up
on
my
walls.
D
Yeah,
I
can
stop
I'll
just
do
the
formalities
really
quickly
for
the
record
so
good
morning,
folks
or
afternoon
or
evening.
This
is.
E
D
No
well,
this
is
an
official
atf
interim
meeting,
so
the
the
usual
rules,
disclaimers
and
procedures
are
applied.
Please
know
well
administrator.
Note.
Takers,
folks,
are
welcome
to
take
notes,
but
I
will
probably
do
what
I
usually
do,
which
is
make
notes
out
of
the
vod
when
it
ends
up
on
youtube.
Probably
at
some
point
in
the
next
week
or
so,
blue
sheets
are
automatic
javascribe.
I
don't
think
we
need.
I've
got
the
chat
open.
We
can
look
off.
D
B
B
There
we
go
greg.
Are
you
in
north
american
time
as
well.
F
B
I'm
glad
you
made
it
okay,
so
on
the
draft
status,
the
number
of
issues
that
still
need
to
address
is
is
growing
fairly
small
in
the
usual
last
minute
fashion.
You
know
when
we
went
through
when
we
started
talking
about
this
like
48
hours
or
actually
was
last
friday.
I
guess
we
started
talking
about
this
or
thursday.
B
The
the
the
number
has
grown
in
our
conversation
in
the
last
48
hours,
but
the
number
that
I
called
out
from
the
existing
issues
list
that
I
thought
we
should
talk
about
was
was
quite
small,
so
I
think
we
are
getting
close
to
being.
Can
you
hear.
G
C
B
Hey
yeah,
so
so
so
so
I
I
would
hope
that
we
could
take
this
to
a
working
group
last
call
in
the
relatively
near
future
and
assuming
that
goes
well
to
iatf
last
call
prior
to
the
next
iatf,
which
is
when
somebody
know
end
of
july,
and
it's
like.
Oh
sorry,
so
I
think
we
should
be
able
to
do
that.
So
that
is
speaking.
You
know
as
an
opinion
under
my
under
my
chair
hat.
I
think
that
you
know
last
time
we
did
this.
B
We
agreed
that
we
would
take
the
question
of
adopting
iregex
to
the
working
group.
We
did
that
we
did
not
hear
any
significant
pushback.
We
did
not
actually
announce
that
or
declare
consensus,
but
unless
something
surprising
happens
at
this
meeting
we
will.
I
think
we
should
go
ahead
and
do
that
and
move
the
draft
over
from
karstenster
land
to
to
to
our
own
to
our
own
github.
B
D
B
Does
anybody
else
anybody
disagree
that
we'd
be
able
to
take
this
to
itf
last
call
before
the
next
ietf.
B
Oh
yeah
excellent,
so
I'm
glad
about
both
those
things.
Excellent.
So
now,
as
I
said,
I
lost
my
sidebar.
Do
you
know
how
to
get
it
back.
B
D
Two
yeah
so
I've
based
this
off
of
what
we've
been
talking
about
in
the
mailing
list.
Last
sort
of
18
24
hours.
D
B
Yes,
please,
so
I
guess,
as
glenn
pointed
out,
there's
nothing
in
the
spec
right
now
that
that
that
says,
that
comparison
is
by
is
this
by
igf
character
by
character.
E
Yeah
my
understanding
was
at
the
last
meeting.
We
kind
of
all
settled
on
this,
adding
some
text
and
it
just
needs
to
be
added.
C
So
we
have
two
places
where
we
need
to
discuss
comparison.
One
is
the
actual
comparison
operator
and
the
other
is
where
we
do
a
member
selection
and
compare
the
the
given
member
name
with
the
actual
member
name.
So
I
think
these
are
the
two
places
where
we
need
to
explain
that
we
do
not
do
any
normalization.
B
Okay,
so
I
think
we
have
consensus
here.
I
will
volunteer
to
do
a
small
pr
to
do
somebody
else
unless
somebody
else
wants
to.
G
B
So,
at
the
current
time
we
do
not
require
parentheses
per
the
text
of
the
most
recent
draft,
and
the
examples
reflect
that
I
believe
greg.
You
were
arguing
the
other
side
of
that
that
we
should
require
them.
F
Yeah,
for
me,
it's
not
a
it's,
not
a
technical
issue.
I
guess
from
a
parsing
perspective,
you
know
with
or
without
them
it's
it's
feasible
to
parse
the
expression.
F
If
a
person
who
is
is
writing
a
path
includes
the
the
parentheses
I
think
it's
much
more
readable
and
also
in
stefan's
original
blog
post,
as
I
mentioned
at
the
bottom,
he
does
include
the
the
parentheses
there
as
well,
which
tells
me
that
the
vast
majority
of
implementations
will
require
them.
So
by
having
them
listed
as
optional,
I
don't
believe
that's
actually
a
backwards,
compatible
change,
or
rather
a
change.
It
would
be
compatible
with
existing
implementations.
F
Now
I
I
I
think
it's
a
readability
issue.
I
I
think
a
parser
could
figure
that
out
figure
it
out
without
the
parentheses
fairly
easily.
H
F
But
visibly
when
I
look
at
look
at
it
with
parentheses,
I
can
isolate
what
the
expression
is
much
more
easily
than
than
without
the
parentheses.
B
I
see
so
rehability
is
a
very
subjective
thing.
The
other
thing
you
said
was
interesting
to
me.
I
have
no
idea.
If
it's
true,
are
we
actually
going
to
get
greater
interoperability
across
existing
implementations?
If
we
do
require
parentheses,
does
it
I?
I
did
what's
his
name
bergman
test
that.
H
Everybody
who
wants
to
have
a
parenthesis
can
can
have
it
can
write
it
down
and
if
I
remember
correctly,
there
may
be
some
implementations
who
who
don't
need
them.
Is
this
correct.
F
That's
the
question
that
was
asked.
I
don't
know
if
we
actually
have
that
in
in
the
test
or
in
the
comparison
suite.
H
I
think
that
if
your
implementation
does
require
a
single
implementation,
who
doesn't
explicitly
require
parenthesis.
B
F
H
H
H
B
H
B
I
think
I
think
I
think
the
the
argument
that's
being
made
is
not
the
specifics
of
of
greg's
implementation.
It's
that
there
would
be
multiple
implementations
that
have
this
behavior,
that
require
the
parentheses.
And
if
that
is
true,
then
that
is
an
argument
that
we
should
require
them
just
because
our
goal
is
to
maximize
interoperability.
C
We
have
two
different
terms
where
we
need
to
be
sure
we
use
there
is
backward
compatibility
and
there
is
forward
compatibility
and
backward
compatibility
means
if
you
have
an
existing
json
path.
Expression
will
that
be
accepted
by
the
json
path
standard,
and
I
think
that
that
is
the
case
here.
What
we
don't
have
is
forward
compatibility.
C
So
if
people
write
their
adjacent
paths
to
the
to
the
new
spec,
they
won't
necessarily
work
with
existing
json
path
implementations.
So
I
think
it's
pretty
clear.
We
don't
have
forward
compatibility
with
at
least
a
sizable
chunk
of
the
existing
implementations,
even
though
I
don't
know
that
that
in
the
bugner
test,
there's
actually
a
test
specifically
for
this
question
we
probably
should
should
add
that.
C
C
Well,
I
can
definitely
write
unreadable
json
paths
today
and
it's
a
little
bit
on
on
the
writer
of
the
jsonpath
query
to
to
write
this
in
such
a
way
that
it's
readable
and
I
think
it's
a
mistake
to
to
try
to
change
the
language
to
only
allow
readable
instances.
So
if
you
you
want
to
have
a
certain
style,
you
can
just
write
that
style.
I
think
that's
what
what
stefan
already
said.
C
I'm
actually
old
enough
to
remember
the
time
when,
when,
in
the
c
language
we
wrote
the
thing
that
comes
after
the
keyword
return,
we
wrote
that
in
parenthesis-
and
that
was
a
style
that
actually
died
out
at
the
end
of
the
70s
and
it
took
a
long
time
to
die
anyway.
So
I
think
the
the
the
there
is
no
technical
argument,
except
for
the
forward
compatibility
argument.
C
The
stylistic
argument
is
really
one
where
we
think
it's
it's
up
to
the
the
rewriter
to
write,
readable
queries
and
the
the
procedural
argument
we
we,
I
think
we
already
have
discussed
that.
So
I
I'm
not
going
to
comment
on
that.
So
I
think
the
the
question
really
is:
is
this
change
worth
reducing
forward
compatibility
and
yeah?
C
I
think
we
we
will
have
to
accept
that
we
are
reducing
forward
compatibility
here
and
we
probably
shouldn't
do
that.
B
F
Okay,
I
think
we
need
to
actually
put
this
as
a
a
test
in
the
comparison
suite
and
find
out
get
data
on
what
actu,
what
current
implementations
actually
do.
Yeah.
I
know.
J
E
So
I'm
not
a
gambling
man,
but
I
bet
that
the
all
implementations
will
not
support
this
new
syntax
and
I
think,
to
some
extent
it
it
could
be
perceived
as
a
kind
of
gratuitous
implementation
hurdle
for
implementers
of
jsonpath.
So
if
you
want
to
adopt
the
standard,
then
it's
just
an
extra
thing,
which
you
know
it's
very
hard
to
justify
to
them.
I
think.
H
I
would
like
to
agree
to
greg's
proposal
to
test
it
with
the
bulkmast
test
suite
and
get
a
feeling
about
the
number
of
implementations
that
don't
require
the
parenthesis.
H
I,
if
the
majority
wants
to
have
them
part
in
in
the
spec,
I
will
follow
the
vote.
H
Let's
wait
for
a
test
and
a
small
statistic
result
how
many
implementations
really
accept,
leaving
parenthesis
out.
C
C
Do
you
well,
we
could
simply
ask
kristoff
to
do
this.
So
just
just
one
comment:
we
don't
usually
vote
on
things
in
the
ietf.
You
know
this
is
actually
something
that
could
be
called
a
bike
shed
issue
where,
where
flipping
a
coin
would
be
as
appropriate
as
as
voting,
so
this
is
not.
E
K
Big
thing
but
yeah:
let's.
B
L
So
in
the
past
I've
added
I've
had
tests
added
via
issues
or
prs.
I
don't
know
if
any.
F
You
do,
can
you,
can
you
add
a
test
case
or
two
that
that
covers
this
and
we
can
see
what
the
results
are.
F
E
Environment,
so
I
can't
I
can't
generate
the
for
pr.
Currently,
I
can
make
the
source
change.
I
don't
think
it
can
generate
the
full.
B
Okay,
I
I
think
our
takeaway
from
here
is
that
if
it
turns
out
that
a
high
proportion
of
the
existing
implementations
do
require
parentheses,
then
we
should
change
and
do
that.
If
it
turns
out
that's
not
true,
then
we
need
to
argue
some
more
because
it
comes
back
to
issues
of
readability
which
are
imponderables,
but
you
know
we'll
deal
with
that
if
we
have
to,
but
I
think
most
of
us
agree
that
if
a
high
proportion
of
the
implementations
require
that
we
we
would
then
go
with
parentheses.
Does
anybody
disagree
with
that?
H
B
A
B
C
Yeah,
I
think
that
that's
really
the
interesting
question
here.
This
is
an
addition
that
that
may
be
useful
for
for
some
diagnostic
purposes
during
testing,
but
it
doesn't
really
do
much
and
if,
if
people
want
this
in
as
a
foot
in
the
door
to
put
the
rest
of
jason
in
there
as
well,
I
would
be
inclined
to
say
no,
because
we
are
not
putting
the
rest
of
jason
in
there
right
now.
Unless
we
completely
change
our
direction
here.
C
So
I
think
the
the
only
argument
that
that
really
holds
water
so
far
was.
I
would
like
to
be
able
to
go
into
a
json
path,
expression
and
replace
something
by
true.
So
I
can
test
the
rest
of
the
adjacent
path,
expression
and
that's
a
weak
argument
for
me,
but
certainly
one
I'm
willing
to
consider.
C
So
I
have
an
expression
and
that's
not
returning
anything
and
I'm
wondering
why.
So
I
have
two
branches
of
an
all
condition
or
something-
and
I
I
replace
one
branch
with
true
where
I
could
take
out
the
entire
o.
But
then
I
have
to
juggle
parenthesis
and
and
all
that,
so
it's
easier
to
just
replace
the
the
branch
by
true
and
that's
a
convenience
which
I
wouldn't
want
to
dismiss.
B
Glenn,
I
have
the
feeling
you
have
the
bergman
in
front
of
you
yeah.
Do
you
see
anything
we
should
know
about.
E
I
I
just
tried
to
post
something
into
the
chat
yeah
there
we
go
so
it
looks
like
there
isn't
a
consensus.
E
C
E
F
E
B
B
C
Well,
there
are
a
lot
that
don't
even
support,
filter
expressions,
so
that's
a
bit
of
a
problem
with
the
presentation
style
here
that
that
you
don't
know
why
it
doesn't
support
this.
So
you
have
to
actually
compare
a
similar
query
that
just
doesn't
contain
the
the
ampersand
eps
epson
falls,
and
you
have
to
do
this
manually.
B
I
mean
the
correct
if
we
believe
in
this,
the
correct
thing
should
be
what
you
see
from,
for
example:
well,
the
the
what's,
the
first,
the
from
cpp,
the
jason
cons.
So
that
is
what
you
would
hope
to
see,
and
I'm
just
saying
that
there's
a
lot
that
are
not
doing
that.
They're
doing
other
things,
whether
it
ranges
from
errors
to.
E
B
Yours
accepts
also
just
key
true,
so
it
it
regarded.
H
You
could
the
two
or
fours
by
two
equals
two
that
should
work
or
one
equals
one
yeah.
B
I
I
don't
really
have
strong
opinions
on
this.
Is
there
somebody
on
the
call
who
wants
to
make
a
strong
argument
for
yes
or
no
on
this.
F
E
Yes,
the
only
other
this
I'm
scratching
stretching
around
for
scenarios,
but
the
only
other
thing
is,
if
you're
doing
predicate
logic
and
you've
got
a
complex
filter
expression,
you
can
do
the
usual
thing
of
spotting.
The
summing
in
brackets
is
say,
you
might
have
keys
greater
than
zero
and
key
is
less
than
zero
and
you
might
replace
that
with
false
as
a
kind
of
refactoring
step,
but
then
you'd
end
up
with
temporarily
an
invalid
json
path,
and
you
have
to
get
rid
of
that.
Keep
going
so
yeah.
F
F
B
B
F
Question
scenario:
if
go
ahead:
if,
if
we
do,
if
you're
searching
for
if
you're
searching
for
not
exists,
but
specifically
properties,
that
are
items
that
contain
properties
with
the
value
of
true
or
with
the
value
of
false,
can
you
do
that
without
the
literal.
C
H
You
you
you,
you
must
compare
it
with
true
or
false.
If
you
explicitly
want
to
know
if
the
value
in
question
is
or
has
that
value.
C
F
H
F
C
C
We're
currently
separating
the
domain
in
which
json
values
can
occur
from
the
domain
in
which
we
are
making
boolean
decisions.
C
F
C
F
H
A
single
one
or
zero
isn't
allowed
singular
one
or
zero
is
not
as
a
boolean
expression,
but
true
and
false
are
so
there
should
they
should
be
boolean
expressions
or
interpreted
as
such.
I
think.
H
C
It's
a
very
healthy
thing
to
have
a
separation
between
the
the
things
that
the
json
path,
query
expression
operates
on,
and
the
json
values
themselves
which
occur
in
in
comparison,
expressions.
F
Yeah,
okay,
I
we
will
need
to
be
very.
I
I'm
fine
with
that,
but
we
need
to
be
very
clear
with
how
we
state
that
in
in
the
spec.
B
F
E
Can
you
say
that
again
carson
I,
he
broke
up.
C
We
probably
should
express
me,
explain
the
domain
separation
between
json
values
and
and
the
boolean
values
that
jsonpath
uses
itself
and
use
the
the
false
an
expression
with
false
in
in
such
a
boolean
context.
As
an
example.
B
C
C
We
maybe
have
to
to
put
in
a
little
bit
of
knowledge
about
this.
This
idf
thing
that
has
been
going
on
for
40
years,
and
people
really
like
to
have
security
considerations
in
specifications
and
generally
the
the
trend
has
been
to
be
on
the
inclusive
side
in
what
should
be
explained
in
the
security
considerations.
C
So
this
first
item
here
I
don't
know
if
you
can
show
the
the
the
actual
spec,
maybe
slightly
easier
to
read
the
first
item
in
section.
What
was
it
5.1
is?
Is
I
mean
we
know
that
we
all
know
that,
but
that's
really
the
problem
with
security
considerations
that
actually
the
people
who
are
writing
the
spec
often
know
all
that.
C
But
since
we
are
not
writing
down
that
information,
an
implementer
may
actually
never
come
come
upon
this
information
because
they
are
just
reading
the
spec
and
all
the
security
implications
that
that
the
spec
has
may
not
be
available
to
them.
So
I
think
we
we
give
an
ietf
tradition
and
given
the
fact
that
there
there
will
be
implementers
here
that
are
not
necessarily
used
to
thinking
in
terms
of
implementation
security.
C
B
Enough
that
so
concretely
we're
having
kristen
and
I
are
having
an
argument
in
which
I
am
suggesting
just
dropping
the
first
paragraph
here
under
5.1.
B
The
thinking
is
that
you
know
so,
nor
in
a
lot
of
protocols
you
have
json
okay
and
whenever
you
are
processing
json,
you
should
never
use
eval,
of
course,
because
you
know
if
you're
in
javascript,
you
should
never
use
eval,
because
all
sorts
of
terrible
things
can
happen
and
and
in
in
the
case
where
you're
writing
an
ietf
rfc.
You
should
say
that
if
you
have,
if
you're
handling
json,
you
should
say,
please
do
not
use
eval
to
process
the
json,
and
I
believe
that
is
more
or
less.
B
What
the
first
paragraph
here
in
5.1
is
is
saying.
C
B
F
I
I
I
don't
come
from
a
javascript
world
javascript
I
I
can
read
the
language
and
and
write
it
a
little
bit,
but
I
don't
have
a
lot
of
experience
in
it
and
I
don't
understand
what
running
eval
on
jason
data
is
why
that's
bad
because
to
me,
json
data
is
just
json
data.
D
B
C
Well,
essentially,
what
what
I'm
trying
to
explain
here
is
that
taking
an
attacker,
controlled,
jsonpath
expression
and
transmogrifying
into
something
you
send
to
your
interpreter
is
bad.
H
In
my
original
implementation,
I
pragmatically
reused
the
underlying
scripting
engine,
and
I
indeed
he
pragmatically
used
eval
and
evil
is
evil
because
it
simply
runs
the
code
in
which
which
it
sees
and
it's
in
fact,
source
or
possible.
Injection
attacks,
but
serious
implementations
shouldn't
should
be
aware
of
never
ever
use
evel
in
javascript.
I
don't
know
about
the
other
languages.
I
can't
imagine
that
c
sharp
allows
to
without
critics
evaluate
any
code.
I
don't
know,
but.
H
I'm
not
sure
if
this
first
sentence
is
first,
should
we
I
I
see
it
addressing
the
javascript.
I
don't
know
if
this
is
really
necessary
to
have
it
inside.
F
If
you're
doing
nested
paths,
maybe
you
could
construct
a
very
deeply
nested
path,
nested,
json
path
that
effectively
doses
a
server
possibly,
but
I
don't
think
that
we're
doing
nested
paths
that
extensively
we've
got
a
open
discussion
in
the
emails.
Apparently.
C
E
C
Yes,
but
people
do
write,
parsers,
doing
regular
expressions
and
regular
expression
substitutions
so
in
in
the
issues
comments
I
I
gave
an
example
of
how
how
that
might
look
like
in
an
implementation-
and
this
is
essentially
just
a
warning
for
for
people
not
to
do
that,
so
actually
what
what
I
was
going
to
propose,
but
now
that
now
the
text
is
gone.
C
What
I
was
going
to
propose
was
the
maybe
getting
rid
of
the
third
sentence,
because
it's
kind
of
redundant-
and
I
think
the
first
two
sentences
can
contain
all
the
warning.
That's
needed.
E
Yeah
I
mean
it
may
be
slightly
different,
but
it's.
This
is
similar
to
my
concern
about
regex's.
If
we
allow
arbitrary
regulators
outside
of
our
iregxp
and
someone
could
do
a
a
cpu
attack
by
exploiting
an
implementation
that
takes
a
long
time
on
a
particular
regex,
so
it's
the
same
kind
of
issue.
Isn't
it.
B
So
you're
saying
don't
feed
this
to
some.
Let
me
see
feeding
parts
of
the
query
to
an
underlying
programming
language
engine,
eg
javascript.
So
in
this
case
I
I
you
know
if
I
were
implementing
jsonpath
in
javascript,
I
would
definitely
feed
the
expression
to
to
javascript
code
to
parse
it
using
the
parse
constructed
hand,
constructed
parser
or
parser
generator.
C
B
C
E
I
mean
we
could
imagine
a
language
which
had
a
subset
very
similar
to
the
filter
expression
language
in
jsonpath
and
should
such
a
language
come
along
in
the
future.
We
wouldn't
want
people
to
delegate
bits
of
this
syntax
to
the
engine,
so.
E
Yeah
absolutely,
but
you
know
the
exact
example
of
jsonpath
I
think
has
has
changed,
because
we
don't
have
expressions
in
the
same
way
that
we
used
to
have,
or
it
doesn't
talk
about
delegating
to
the
underlying
scripting
language.
E
C
F
M
B
So
greg,
I
think,
you're
you're
in
a
minority
there
I
think
you
know
the
culture
is
to
be
super
aggressive
about
highlighting
things
that
could
be
insecure,
even
if
they're
dumb.
I
guess
my
complaint
here
is,
I
guess.
Maybe
this
is
just
an
editorial
issue,
I'm
just
I'm
just
arguing
this
paragraph
is
not
helpful
enough,
and
so
I'm
saying,
okay,
remove
it
and
carson's
saying
no
and
prove
it.
So,
let's
see
if
we
can
improve
it.
Okay,
anybody
want
to
talk
about
this
one
further.
F
So
this
particular
issue,
aside
of
of
not
passing
portions
of
the
expression
to
the
underlying
engine,
are
we
going
to
be
editing
the
spec
every
time
we
come
up
with
a
new
new
vulnerability,
or
so
how
are
those
going
to
be
managed.
C
D
Every
potential
vulnerability
we
just
have
to
answer
to
the
ones
you
know
we
find
you
know
some
some,
absolutely
crazy
stuff.
The
heart
bleed
of
jason
path,
for
example,
then
you
know
we
can
publish
additional
documents
about
that
or
business
spec.
D
B
For
example,
if
you
look
at
that
same
section
5.1,
if
you
look
at
the
second
paragraph,
it
just
points
out
that,
since
we
have
regular
expressions
if
you're
going
to
allow
attackers
to
submit
arbitrary,
regular
expressions,
then
a
smart
attacker
can
probably
do
a
denial
of
service
attack
on
you
with
a
pathological,
regular
expression,
particularly
if
they
control
both
the
the
json
data
and
the
regular
expression
in
the
path
and
that
kind
of
thing
yeah.
That
kind
of
thing
has
to
be
in
here.
B
Okay,
now
the
second
since
we're
since
we
started
this,
I'm
going
to
say,
let's
talk
briefly
about
the
issue
I
raised
on
the
second
one
5.2
here,
which
I
I
which
once
it
occurred
to
me,
struck
me
as
a
real
issue,
which
is
that
if
you,
if
you
require
I
json,
which
is
to
say,
j,
doesn't
allow
duplicate
keys
and
it
doesn't
have
numbers
outside
of
the
ieee
754
range
and
doesn't
have
totally
broken
unicode.
E
B
Yeah,
so
you
could
write
a
json.
You
could
write
if
you're
using
jsonpath
to
enforce
a
security
policy.
You
say
you
must
not
process
a
message
that
has
you
know,
source
russia
in
it.
Okay,
but
you
know
if
you
allow
bad
json,
where
you
can
have
an
object
containing
the
source
field
three
times
well,
depending
on
the
implementation.
Sometimes
it's
going
to
see
source
russia,
and
sometimes
it's
not.
F
I
do
know
that
there
are
languages
that
the
parser
itself
is
non-deterministic
in
in
those
duplicate
key
scenarios.
B
Well,
it's
absolutely
the
case.
There
are
some
that
take
the
first
one.
There
are
some
that
take
the
last
one.
There
are
some
that
throw
syntax
error,
there's
some
that.
C
C
Is
where
the
json
path
implementations
will
always
be
used
with
validating
I
json
parsers
and
of
course
the
answer
is
no,
so
I
think
this
security
conservation
here
is
needed.
The
question
is:
how
many
examples
do
we
actually
have
to
give
in
the
second
paragraph?
C
So
do
again,
do
you
actually
have
the
spec
we
could?
So
we
could
look
at
those
paragraphs.
C
B
So
I'm
having,
I
had
a
problem
with
that,
so
I
could
easily
understand
how,
if,
if,
if
you
didn't
have
an
ijson
enforcement,
you
an
attacker
could
send
things
that
would
be
likely
to
you
know:
non-deterministic
behavior.
I
didn't
really
understand
how
ordering
of
object
members
could
be
used
to
work
around
security
policies
or
our
creative
vulnerability.
C
Yeah
the
example
is
actually
one
where,
where
I
json
filtering
is
not
being
done
and
the
protective
application
uses,
one
order
to
resolve
duplicate
keys
and
the
the
protected
application
uses
another
order
right.
So
the
protective
application
makes
sure
that
that
foo
is
not
set
to
bar,
but
fool's
actually
said
twice
and
the
protected
application
happens
to
pick
up
the
other
one.
G
B
Be
used
to
to
to
look
for
vulnerabilities,
you
know
huge
number
of
parsing
toxic
etf-16.
B
A
little
bit
of
text
saying
that
you
know
in
particular
here
is
a
well-known
set
of
sources
of
inconsistent
behavior.
B
B
E
Yeah,
I'm
thinking
of
it
in
the
context
of
the
iraq
xp
spec
itself,
though,
because
I
feel
that
I'm
missing
something
in
terms
of
carson's
statements
about
it
being
just
quotes
just
to
format,
and
we
don't
need
to
describe
what
happens
when
you
step
outside.
M
The
the
subject
glenn's
point
is
that.
B
B
Secondly,
it's
not
interoperable,
because
a
lot
of
implementations
would
presumably
follow
our
rules
and
simply
just
not
not
take
that,
and
so
it
would
be
reasonable
to
re
in
in
the
iregas
to
say
that
implementations
must
report
things
that
are
not
allowed
by
iregafs
and
the
argument
we
were
having
is
that
is
that
a
good
idea?
Yes,
I
think
we
can
all
probably
agree,
that's
a
good
idea,
so
should
that
be
a
must
or
a
may
or
I
should
carson.
I
haven't
heard
from
you
on
this
one.
C
Yeah,
I
think
I
sent
a
few
messages,
but
I
think
my
main
point
is
that
we're
having
the
same
problem
we're
having
at
the
json
path
level.
That's
why
I
would
like
to
discuss
this
together
so
right
now.
I
I
don't
think
a
lot
of
people
are
arguing
that
the
json
path
implementation
must
reject
anything
that
isn't
standard
json
path,
because
that
would
essentially
kill
a
backward
compatibility.
C
So
I
think
we
we
we
have
to
be
careful.
What
what
we
ask
for
here.
So
if,
if
we
say
jsonpath
implementations
only
ever
can
accept
valid
unextended
json
path,
then
we
ask
all
the
the
implementers
of
jsonpath
to
to
implement
a
special
mode
that
does
all
the
checking
and,
of
course,
about
5.5
percent
of
them
will
actually
do
that
so
that
that's
the
one
end
of
the
argument.
C
C
So
if,
if
I'm
going
to
to
propose
a
version
of
ctd
output,
2.0
that
uses
iregex,
I
will
probably
want
to
be
rather
open
to
other
w3c,
regular
expressions
for
reasons
of
compatibility,
so
an
existing
ctdl
spec
that
that
uses
character.
Subtraction
character
set
subtraction
may
not
be
particularly
useful,
but
yeah,
making
it
invalid
right
now
on
all
implementations
that
do
implement.
That
is
not
the
right
thing
to
do.
So.
It's
really
the
the
job
of
the
referencing
specification
to
say
which
level
of
compliance
checking
is
appropriate.
C
E
I'd
be
comfortable
with
that,
provided
we
could
say
something
in
our
reg
xp
security
section
to
say
something
about
non-strict
implementations.
M
Good
point
I
mean
the
the
the
value.
B
When
I
paste
that
in-
and
it
says
you
know-
that's
probably
not
going
to
work
in
many
implementations.
So
so
I
think
it's
the
the
the
the
I
think.
So
I
think
we
should
do
more
than
what
you
said
karsten.
I
think
yes,
that's
a
perfectly
valid
way
to
go.
B
It
is
to
define
implementation
classes,
you
know
strict
and
non-strict,
but
I
think
there's
a
place
for
a
little
bit
of
preaching
here
and
encouraging
implementers
to
provide
the
the
syntax
checking
and
reporting
I
I
wouldn't
go
as
far
as
a
must,
but
I
think
it's
it's.
It
would
be
beneficial
for
implementation.
To
do
that,
we
should
say
so.
F
That
echoes
my
suggestion
as
well,
in
that
an
implementation
should
implement
just
what's
in
irejects,
which
you
know
it
yeah
just
this
subset.
Anything
out
of
that
to
me
should
be
an
option
that
is
enabled
by
the
consumer
of
the
implementation.
F
I
F
Regex
or
if
it's
just
a
a
generic
regex
library
say
nets
regex
built-in
system,
you
could
have
a
compatibility
mode
setting
like
there's
a
like
the
dot
net
regex
you
can
set
it
up.
You
can
give
it
an
option
to
run
it
as
a
javascript,
regex
or
various
other
flavors
of
regex.
It
supports
three
or
four,
and
so
you
can
tell
it,
which
particular
flavor
you
want
it
to
support
and
irregex
could
be
one
of
those.
E
I
mean
that
was
my
starting
point.
I
thought
well,
actually
I
thought
reg
xp
should
be
straight,
it
must
be
strict,
but
I
was
then
thinking
about
should
be
strict
and
tim's
counter
to
that
was
that
the
implementation
cost
with
any
putting
an
implementation
cost
on
every
implementer
who
follows
the
should
requirements,
so
we
can
need
to
make
and
it
lets
them
off
the
hook
slightly
and
and
the
interop
is,
is
an
issue.
E
Isn't
it
so,
oh
yeah,
so
so
the
point
being
that
if
we
say
should
essentially
what
we're
saying
is
every
I
reg
xp
implementer
should
write
a
parser
or
generator
parser
for
this.
This
subset.
G
Julian,
are
you
trying
to
speak?
We
don't
hear
you.
Can
you
hear
me?
No?
Okay,
oh
yeah!
Yeah.
Now
I
hear
you
hello.
K
Good
morning,
sorry
for
jumping
in,
but
just
one
thought
about
rejecting
or
not
ejecting
things
that
are
not
in
iraq
ex
we
had
we,
as
in
the
java
content
repository
working
group
ages
ago,
when
we
defined
the
language
that
looked
like
sql,
but
wasn't
sequel
struggled
with
this
problem
that
people
wanted
to
add
extensions
that
are
like
sql
from
somebody
else
and
the
problem
being
that
you
close
extension
points
for
the
future.
If
you
allow
extensions
to
be
made
outside
the
spec.
K
So
if
you
say
iraq
x
by
default,
configuration
should
only
allow
what's
in
the
spec,
and
you
actually
should
force
people
to
reject
everything
that
looks
like
an
extension
to
be
rejected
just
to
state
the
arguments
right,
because
in
people
you
can
have
annotations
that
get
ignored.
K
But
if
people
start
relying
on
these,
this
extension
point
is
essentially
taken
away
from
future
versions
of
iraq.
If
that
ever
happens.
K
So
this
is
a
pattern
in
very
languages
or
things
that
look
like
strings
where
people
could
interview
things
and
and
can
get
away
with
that
and
if
a
conforming
implementation
just
ignores
that
later
on,
you
want
to
define
something
that
it.
What
it
means
then
you're
in
trouble
so
be
careful
in
how
you
define
the
potential
extension
points
in
the
future.
K
Unless
you
are
absolutely
sure
you
won't
don't
that
you
don't
need
extension
points
in
the
future,
so
it's
a
tricky
path
between
having
a
strict
syntax
and
then
allowing
people
to
support
more
than
that,
because
if
people
start
supporting
more
than
that,
you
might
be
unable
to
standardize
that
in
the
future,
when
implementations
diverge
so
just
sorry
for
jumping
in.
But
I
just
had
that
thought
crossing
my
mind.
C
I
think
that
that's
a
pretty
good
point,
and
I
also
think
that
there
is
a
slight
difference
here,
because
when
you
do
a
sql
extension,
you
actually
are
sitting
down
and
extending
sql
when
you
are
writing
a
iraq
implementation
that
isn't
strict
you're,
probably
saving
work
by
by
just
handing
over
stuff
to
to
the
regex
engine
that
you're
using
and
the
question
really
is.
Do
we
want
to
put
the
the
owners
of
nudging
people
to
only
use
interoperable
jsonpath
queries?
C
Do
we
want
to
put
that
onus
on
every
implementer
of
jsonpath,
or
is
that
something
we
just
recommend
people
to
do,
but
the
json
path
implementation
doesn't
get
wrong
by
by
not
catching
a
deviation.
C
B
At
the
moment
you
know
just
based
on
listening
to
the
discussion.
This
feels
to
me
like
a
should,
not
a
must
and-
and
I
would
certainly
be
friendly
to
both
for
iraq
and
and
jsonpath
saying
you
know,
implementers
should
report
on.
B
Strings
that
do
not
comply
with
the
grammar
here,
you
know,
with
the
ex,
with
the
understanding
that
would
mostly
be
extensions
and
supersets
and
so
on
must
seems
like
too
high
a
barrier
and
and
would
probably
scare
off
some
implementers.
But
you
know
this
is
clearly
something
that
I
think
would
be
beneficial
to
end
users.
C
So,
what's
your
definition
of
when
that
doesn't
need
to
be
heated?
If
you
don't
care
about
interop,
wait,
wait
a
minute
wait
a
minute.
The
thing
is
still
interoperable.
It
just
doesn't
help
model.
Excuse
me,
query
writers,
to
write
interoperable
queries,
but
the
thing
itself
is
interoperable.
That's
a
very
big
distinction.
B
E
I
was
thinking
about
the
test
testing
side
and
if
you
generate
the
the
parser
from
a
something
that's
kind
of
can
be
compared
to
the
abnf
in
our
egg
xp,
then
you
should
be
in
pretty
good
shape
without
testing.
I
think
testing
is
going
to
be
a
a
bottomless
pit
in
this
area.
B
L
C
I
think
I'd
I'd
rather
simply
define
terms
that
allow
you
to
to
distinguish
an
implementation
of
eggs
from
a
checking
implementation
of
eggs
or
a
strict
implementation
or
whatever
term.
We
come
up
with
and
explain
why.
It
actually
is
a
bonus
to
have
a
checking
implementation
and
then
let
the
market
sort
out
whether
people
will
want
to
be
able
to
advertise
their
implementations
as
checking
or
not.
B
So
I
think
the
answer
is
is
roughly
the
same
for
the
two
specs
one
for
iraq
x
and
the
other
for
for
json
path,
and
it
would
be
quite
high
up
near
the
front
of
the
document
saying
you
know
we.
We
divide
software
implementations,
the
process
x
with
our
xsi
regas
or
jsonpath
as
checking
or
non-checking
and
explain
you
know
what
that
means
and
then
say
that
checking
provides
the
following
benefit.
It
allows
you
know
a
a
writer
of
these
things
to
have
a
higher
assurance
of
interoperability.
K
E
Can
I
just
check,
while
we're
together
a
kind
of
meta
discussion
that
came
up
about
whether
this
kind
of
language
should
go
in
our
regexp
as
well
as
jsonpath,
because
carson
was
kind
of
pushing
back
and
saying
arrogance?
Please
just
format.
We
should
keep
this
kind
of
language
out
of
there.
If
I
understood
correctly,.
J
C
I
was
pretty
against
actually
making
a
single
decision.
I
think
what
tim
just
said
is
exactly
what
I
plan
to
do
in.
E
B
B
I
think
we
agreed
that
they're
not
going
to
be
in
1.0.
F
That's
fair:
does
that
mean
that
length
isn't
going
to
be
in
one
1.0
because
that's
pretty
common.
B
C
Well,
there
are
two
things
missing.
First
of
all,
we
don't.
We
don't
have
that
extension
point
and
I
think
that
actually
may
be
a
mistake
and
the
other
one
may
be
defining
length
and
we
definitely
could
fill
a
whole
document
on
what
length
actually
means-
probably
not
so
much
for
arrays,
but
definitely
for
for
objects
and
for
strings
and
certainly
for
numbers
yeah.
C
So
maybe
we
want
to
define
the
extension
point
and
use
length
as
as
our
exercise
to
do
this,
but
length
itself
actually
is
pretty
difficult
to
define.
C
We
already
restrict
comparisons
to
a
certain
domain,
so
we
want
to
restrict
length
to
a
certain
domain
as
well,
and
the
question
is
whether
we
just
want
arrays
in
there
but
or
whether
we
also
want
strings
in
there
and
if
you
want
strings
in
there.
This
is
a
very,
very
big
kind
of
font.
B
C
B
Well,
I
think,
there's
something
we
can
talk
about,
which
is
that,
as
karsten
just
said
on
several
occasions,
people
have
have
argued
that
it
would
be
good
to
in
the
1.0
json
path
identify
what
extension
points
are
and
that
proposal
that
idea
has
been
raised
several
times.
Nobody
has
ever
written
a
pr
saying
what
what
that
might
look
like
and
whereas
I
think
that's
perhaps
a
desirable
thing
to
do.
I
I
I'm
not
gonna,
write
the
pr
and
unless
somebody
else
does,
I
don't
think
we're
going
to
do
anything
about
that.
B
So
I
think
I
think,
greg
I
think
you
know
the
the
current
time
the
working
group
can
live
with
not
having
length
in
there.
C
B
B
Just
decide
we
agreed
that
the
spec
currently
does
not
allow
length
that,
for
the
moment,
the
working
group,
my
my
my
perception
is
that
we're
okay
with
that
and
that
nobody
has
yet
submitted
a
pr
to
define
extension
points.
I'm
sure,
if
somebody
did,
we
would
look
at
it
and
think
about
it,
but.
H
Say
again,
I
didn't
index
what
at
index
to
to
address
keys
all
right
in
in
in
filter,
expressions.
C
First
of
all,
we
need
an
extension
point
and
if
we
use
the
same
extension
point
we
use
for
length,
it
would
be
index
open,
parenthesis,
edge,
closing
parenthesis
which
is
yeah
okay,
but
yes-
and
the
second
observation
is
that
we
are
violating
the
don't
look
up
property
that
the
the
processing
model
currently
has
well,
we
are
looking
sideways,
not
not
really
up,
but
so
far
we
only
could
look
down
and
I
think
that
that's
a
decision
that
can
be
made
at
the
point
in
time
extending
that
processing.
C
C
D
We
talked
about
this
at
the
previous
meeting
and
then
the
direction
that
the
conversation
went
was.
We
need
to
reconcile
the
changes
to
the
processing
model
like
carson
described
before
we
can
include
it
into
the
base
spec,
but
that
itself
would
be
a
bit
of
a
can
of
wounds.
F
Yeah,
if
you
include
the
the
current
object
key
or
the
array
index,
that
you're
processing
within
a
filter,
expression
context
as
part
of
the
the
processing
model,
then
I
think
some
of
that
is
resolved.
I
don't
know
that
you're
really
looking
up
per
se
you're,
just
widening
the
the
scope
of
the
context.
E
I
suppose
the
the
point
is
that
the
if
we
allowed
extension
points,
then
they
are
not
limited
in
future
to
just
looking
at
index
and
length.
They
could
generally
look
up
as
well.
F
C
Yeah
and
so
that
that's
actually
interesting,
because
we,
if
we
define
this
this
functional
syntax,
we
have
to
define
what
goes
between
the
parenthesis.
Yeah.
H
F
Yeah
in
terms
or
in
in
regard
to
the
the
index
being
what
we
think
or
or
even
the
length
being
like
index,
open
parentheses
at
close
parenthesis,
I
don't
know
that
we
would
necessarily
need
to
do
that.
I
would
suggest-
and
I
think
I've
written
this
somewhere,
I
would
suggest
having
an
empty
parameter
list
and
the
the
the
app
would
be
just
part
of
the
context.
F
E
Yeah,
the
passing
that
explicitly
opens
the
door
to
passing
other
things
explicit
explicitly
like.
L
D
F
At
dollar,
sign
or
index
dollar
sign,
which
would
just
be
very
confusing.
B
Okay,
folks,
barring
any
other
things
being
brought
forward,
I
suggest
we're
finished.
D
B
D
We
plan
when
our
next
our
follow-up
interim
meeting
is
noting
that
next
itf
visit
towards
the
end
of
july.
G
E
Just
so
people
are
aware,
I'm
on
vacation
for
most
of
may
we're
away
from
keyboard.
So
that's
a
limitation
for
me.
Perhaps
perhaps
we
should
do
something.
D
I
B
B
Made
some
good
progress
and
see
you.
F
Next
time,
oh
one,
one
minor
note
that
this
group
should
be
aware
of-
I
am
in
the
process
of
interviewing
at
postman
for
their
open
source
division.
With
my
work
with
jason
schema.
They
are
also
tangentially
related
tangentially
interested
in
my
my
work
here
as
well.
So
I
I
may
be
soon
representing
postman
a
little
bit
as
well
going
forward
news
to
come,
but
I
thought
it
was
worth
mentioning
to
the
group.