►
From YouTube: IETF-JSONPATH-20220309-1000
Description
JSONPATH meeting session at IETF
2022/03/09 1000
https://datatracker.ietf.org/meeting//proceedings/
B
A
C
D
D
E
I
was
planning
to,
but
then
austria
decided
to
liberate
all
the
the
there
is
restrictions
they
had
and
now
they
have
twice
the
the
incidence
of
germany
which
is
rising
right
now,
so
no
I'm
not
coming.
Okay,
I
need
to
to
take
out
my
registration.
You
actually
can
find
out
who
is
registered
online
and
and
yeah
who's
registered
remote.
E
B
A
A
F
A
B
So,
unlike
last
time,
I
did
not
go
through
the
whole
draft
and-
and
you
know,
have
opinions
about
which
parts
needed
work
and
which
parts
did
not,
but
I
have
been
tracking
it.
You
know
better
than
I
had
before,
and
you
know.
I
think
that
the
list
of
issues
we
have
before
us
probably
exceeds
I
mean
in
in
in
in
glen's,
email
and
and
so
on.
The
list
of
issues
before
us
probably
exceeds
what
we
really
need
to
do
to
to
finish
a
draft.
B
F
B
I
you
know
qualitatively,
I
I
I'll
defer
on
the
and
the
formalities,
but
we
simply
have
to
achieve
declare
consensus
that
there
is
a
draft
that
we
think
represents
the
consensus
of
the
working
group
and
we
think
there
are
no,
no,
you
know
vital
outstanding
issues.
Then
we
we
do
a
working
group
last
call.
Do
we
do
an
iatf
last
call.
A
Eventually,
what
we'll
do
is
we'll
get
to
the
point
where
we
run
out
of
things
to
include
into
the
document
we'll
go
we'll
we'll
ask.
The
chairs
will
ask
people
in
the
working
group.
If
there's
for
we'll
we'll
do
a
working
group
last
call
and
if
there's
no
objections
to
us
submitting
it,
it
will
go
through
the
rest
of
the
the
rfc
document
grinder
for
which
it'll
go
through
isg
and
several
other
reviews
where
people
will
from
various
parts.
A
It
is
kind
of
frozen,
but
there
may
be
feedback
given
by
the
various
reviewers
along
the
way.
They
may
review
the
document
and
say
this
is
ready,
but
I
need
you
to
there's
some
suggestions
on
what
to
change,
in
which
case
the
editors
will
make
those
changes
and
then
it
it'll
get
reviewed
again
and
they'll
go
okay,
yeah,
I'm
happy
with
it.
B
A
lot
of
reviews
that
happen
it
can
go
to
various
directorates.
You
know
I
see
francesca
joined
us
hi
francesca
and
when
you,
when
you
get
ready
to
do
this,
you
you
get
a
document
shepard,
which
would
normally
be
your
id,
and
then
they
decide
to
direct
need
to
review
this,
for
example,
security,
directorate
operations,
director
at
art,
heart
and
so
on.
At
some
point,
there's
an
ietf
last
call
too.
I
forget
the
exact
sequence
where
you
just
send
an
email
to
the.
E
Yes,
so
the
the
sequence
is
that
the
working
group
decides
that
the
draft
is
ready
and
submits
it
to
the
isg.
Now
the
working
group
usually
wants
to
have
consensus
on
the
document.
That's
criteria,
one,
but
the
criteria
two
is:
is
the
document
in
a
shape
where
it
will
just
die
in
in
the
review
processes
that
follow
it.
E
So
we
also
have
to
make
sure
that
that
it's
simply
good
enough
to
survive
the
next
steps,
and
the
next
step
is
an
av
review
where
the
the
responsible
area
director
looks
at
the
document
and
sends
us
some
comments,
so
we
get
to
fix
those.
Then
we
have
an
ietf
last
call
where
people
come
in
with
comments.
F
E
E
The
document
will
will,
at
the
end,
get
stuck
in
the
rfc
editor
queue
because
it
cannot
be
published
without
normative
references
having
been
published.
So
that's
the
formal
thing,
but
in
in
practice
the
isg
is
not
going
to
be
happy
to
review
a
document
with
an
open,
normative
reference,
so
it
should
be
at
the
same
stage.
The
two
documents
should
be
at
the
same
state.
B
Yeah,
you
really
have
to
go
forward
together
and
I
you
know
I
certainly
would
not
be
happy
with
submitting
either
without
the
other
yeah.
Thank
you.
Actually,
that's
not
true.
I'd
be
okay
with
submitting
iregas,
but
that's
what
I
just
wanted
to
say.
Yes,
but
it
seems
unlikely
I
think,
we'll
probably
end
up
doing
both
at
the
same
time.
E
I
G
B
B
B
B
I
think
it's
still
a
borman
draft
at
this
point
that
that
provides
a
small
subset
of
regexp
that
we
believe
should
be
portable
across
the
vast
majority
of
popular
implementations,
and
then
we
would
refer
to
that
normatively
from
the
jsonpath
based
draft.
So
so
so
we
expect
to
bring
forward
two
drafts
they're,
both
pretty
short.
G
F
E
F
E
F
E
Well,
we
had
that
discussion
in
a
different
draft.
I
forget
which
one
the
href
draft
and
we
decided
that
we
wanted
to
keep
the
main
document
clear
of
weird
edge
cases
I
mean
unless
they
they
really
are
illustrating
the
the
the
works.
Then,
of
course
you
can
put
there.
So
if,
if
you
are
describing
something
and
are
not
not
saying
what
what
an
empty
string
is
causing,
that
of
course
has
to
be
in
the
main
document.
A
E
F
B
E
B
B
You
know.
The
big
thing
you
have
to
worry
about
is
denial
of
service
attacks.
So
that's
something
should
be
mentioned,
I'm
having
a
little
I'm.
You
know
I've
written
a
lot
of
security,
consideration,
sections
and
I'm
sort
of
scratching
the
bottom
of
the
barrel
here
trying
to
think
of
what
should
go
in
ours.
E
So
we
can
only
give
give
a
very
rough
indication
of
what
the
security
considerations
there
might
be.
For
the
first
part,
the
security
considerations
of
jsonpath
itself.
I
think
we
should
try
to
make
sure
we
we
capture
all
of
them
and,
of
course
we
can
point
to
to
the
ira
gaps
document
for
the
regex
security
considerations.
I.
E
E
A
I
think
I
think,
there's
also
some
value
in
covering
information
exposure
as
a
sort
of
hand,
wavy
concept-
and
what
I
mean
by
that
is-
is
that
if
you
allow
users
to
allow
for
human
input
external
input
of
a
json
path,
an
attacker
could
craft
a
query
that
would
expose
more
data
than
what
the
implementation
had
inferred
and
by
implementation.
It
could
be
a
deployment
or
it
could
be
a
json
path,
implementation
itself,
acting
with
under
a
bug
or
something
I'm
being.
A
C
B
B
D
H
E
F
E
B
B
F
This
is
looking
back
at
that
list.
That
was
security
items.
I
think
we've
covered
that
okay,
69
and
136.
I
was
just
warning
that
you
know
what
whoever
takes
it
on.
It's
gonna
be
a
bit
of
a
memory
test
getting
the
appropriate
level,
so
it
might
need
a
bit
of
iteration
in
the
pr
and
that's
in
the
pr.
So
that's
fine,
sorry
for
what
are
69.
B
F
F
B
F
E
C
C
C
E
F
E
Because
of
the
conflicts
yeah,
so
maybe
just
make
a
separate
issue
that
says:
rearrange
sections
in
3.5
and
also
I
would
I
would
love
to
have
the
the
actual
abn
f
that
says:
question
mark
as
boolean
expression
be
defined
by
by
filter
selector.
So
you
can
just
say
we
we
have
the
for
each
selector.
We
have
av
f
rule
for
the
innards
of
that
selector
and
we
have
an
abn
rule
that
adds
the
brackets
and
the
spaces
around
that.
So
we
have
list
selector
and
and
list.
E
So
what
do
you
want
to
change
kirsten,
just
factor
the
abn
f?
If
you
look
at
the
abn
f1
from
358
and
from
359
both
have
this
question
mark
as
boolean
expert,
and
I
would
just
like
to
give
that
thing
a
name
and
I
right
now
I
don't
have
an.
I
have
a
name
for
the
whole
selector,
but
I
don't
have
a
name
for
for
the
innards
of
that
selector.
We
probably
have
to
invent
a
name
for
that,
so
the
airbnf
becomes
consistent.
B
B
H
E
E
E
So
we
we
can
now
look
at
jsonpath
and
see
what
is
the
set
of
adjacent
path,
queries
that
have
that
property
and
we
will
come
up
with
something
that
looks
a
lot
like
normalized
path
plus
a
few
other
cases,
but
I'm
not
sure
that
that
this
is
that
we
need
to
to
do
this
exercise.
But
maybe
we
do
to
make
sure
that
that,
in
a.
B
E
F
So
my
intention,
my
approach
in
that
pr
was
to
take
the
current
relative
path.
Sorry,
the
I've
got
the
wrong
draft
now,
but
just
was
yeah
okay,
so
it
was
to
take
the
is
it
gone
yeah,
so
we've
got
path,
equals
relative
path
or
json
path,
and
relative
path
has
the
constraint
that
we've
been
talking
about.
So
it's
singular,
but
json
path
is
wide
open
and
can
be
more
plural
if
you
like.
So
I
was
trying
to
restrict
the
abn
s
so
that
only
singular
json
paths
were
allowed.
C
C
F
E
Yeah,
I
agree
with
that,
but
we
have
to
be
careful
where
we
actually
need
that
property.
So,
for
instance,
an
exist
expression
does
not
need
a
singular
path,
and
I
would
actually
even
argue
that
the
regex
expression
doesn't
need
a
singular
path.
Of
course
we
have
to
define
what
it
means
to
to
match
a
plural
path
to
a
regular
expression,
but
I
think
that
that's
pretty
obviously
a
one-off
thing,
but
yeah
we
need
to
discuss
this.
F
B
C
F
Yeah,
I
think
I
think
the
exist
cases
is
clearer,
because
the
the
existence
test
is
against
a
set
of
nodes
or
values
which
have
been
computed
and
therefore
exist.
Whereas
the
regex
is
a
bit
more
tricky.
I
think
no,
the
same
is
true
there,
but
for
me
the
the
regex
is
a
difficult
one,
because
I
don't
know
whether
to
end
the
requirement
or
so
we've
got
two.
F
C
C
K
E
E
F
C
E
C
E
B
C
C
E
F
I
would
apply
the
the
memory
test
again,
what
the
what
the
user
is
going
to
be
able
to
remember
here-
and
I
would
have
thought-
was
using
the
same
rule
for
existence.
Expressions
as
for
regex's,
as
for
comparisons,
will
be
the
easiest
rule
to
remember,
rather
than
special
casing
existence,
unless
it
gives
some
major
use
case
advantage,
which
I
don't
think
it
does.
E
B
E
E
Do
we
find
a
way
to
restrict
things,
so
the
semantics
always
stay
simple
and
singular
paths
seem
to
be
a
way
of
doing
that
restriction.
So
we
can
get
simple
semantics
for
comparison,
but
then
we
have
to
look
at
other
things
like
like
nested
filters,
which
are
not
scaring
me
at
all,
but
which
of
course
require
implementing
something
that
you
wouldn't
be
implementing.
Otherwise,.
C
C
E
B
B
Right,
let's
try
and
do
what
our
charter
says,
which
is
to
find
the
interoperable
subset
of
you
know
what
the
state
of
the
art
is
considered
to
be
now.
You
know
I'm
happy
to
have
the
the
the
normalized
path
that
actually
met
an
application
need
I
had
in
the
previous
life,
so
I
know
that
actually
has
a
use.
I
am
puzzled
to
be
honest
about
singular
so.
E
C
F
B
E
So
I
think
I
took
the
action
to
look
at
examples
where
nested
filters
would
be
useful,
and
I
think
that
that's
the
first
step-
and
maybe
I
can
also
find
out
whether
christian
bergman
has
done
a
test
for
those
and
from
that
we
can
decide
whether
we
need
to
to
open
up
relative
path
or
whether
we
can
survive
with
a
single,
singular
path.
Production,
okay,.
B
E
I
just
see
one
one
danger:
when
we
start
adding
attributes
like
like
singular
to
the
productions
in
our
grammar,
then
we
can
have
an
explosion
of
of
a
combinatorial
explosion
of
of
rules,
or
we
can
do
something
like
like
what
ecmascript
does,
where
they
essentially
have
hidden
a
little
bit
of
an
attribute
grammar
or
two-level
grammar
in
their
grammar
notation.
But
I
think
I
would
like
to
avoid
that
and
stick
with
abn
f,
if
possible.
E
Path,
I
think
that
that's
a
very
important
point,
so
we
have
talked
about
ad
index,
which
is
is
a
weird
thing,
because
it
violates
our
processing
model
that
that
we
have
a
particular
node
we
are
looking
at
and
now
we
are
looking
at
the
parent
relationship
of
that
node
or
if
we
are
talking
talking
about
member
value,
we
are
talking
about
looking
at
the
member
name.
So
that's
one
issue.
E
We
can
discuss
this,
but
I
don't
want
to
discuss
this
now,
but
it's
another
example
besides
length
where
it
would
be
nice
to
have
a
way
to
put
names
into
the
jspath
query.
So
we
have
that
name
as
the
place
where
we
can
put
in
additional
operations
without
having
to
to
change
the
grammar
each
time
we
do
that.
E
So,
if
you
ask
me,
I
would
do
regular
expressions
by
using
something
that's
called
matches
and
not
by
equals
student,
but
that's
not
existing
practice.
So
so,
let's,
let's
ignore
that,
but
I
think
that
that's
just
another
example
of
how
we
could
be
using
a
name
as
as
an
extension
point
in
in
the
grammar.
B
I,
if
I
can
summarize
I
I
think
what
I'm
hearing
is
that,
whereas
nobody
has
a
burning
example
of
a
function
that
they
want
to
put
in
right
now
that
it's
a
very,
very
natural
and
idiomatic
extension
mechanism
for
things
that
might
be
put
in
later.
So
there
might
be
a
benefit
to
putting
it
into
the
grammar
now,
which
you
know,
give
implementers
and
people
with
bright
ideas.
E
E
A
H
E
C
There
are
some
a
few,
a
few
implementations
that
allow
functions
at
the
end
of
a
query,
but
this,
from
my
point
of
view,
is
just
some
kind
of
post
processing
with
with
the
results.
This
is
not
a
json
path
thing,
that's
any
other
application
that
will
get
a
list
of
normalized
path
can
do
that
separately,
but.
C
Index
of
the
current
element,
I
think
it's
a
demand
that
is
rising
arising
very
often,
I
think
so
it's
it
does
not
qualify
for
a
function.
Why?
Not?
Because
with
each
func
function,
you
need
to
specify
what
kind
of
parameters
does
this
function
accept,
so
index
function
of
the
current
element?
But
if
we
allow
this,
we
we
can
also.
C
E
So
you
would
apply
the
the
index
operator
when
you
are
on
on
a
particular
node,
and
the
index
operator
looks
into
the
vicinity
of
that
node
to
find
out
what
what
the
index
of
of
that
node
was
so
you're
kind
of
ascending
through
the
tree
again,
of
course,
another
way
of
modeling.
This
would
be
that
whenever
you
have
a
node,
you
keep
some
some
context
for
that
node
as
an
attribute
of
that
node.
So
you
know
what
the
index
was.
You
use
to
get
there.
E
But
I
was
not
trying
not
to
do
the
the
index
thing
at
the
moment,
but
stick
with
length
as
an
example
for
something
where
we
could
use
this
extension
point.
Obviously
I
have
a
I'm
having
a
hard
time
to
write
an
example,
because
we
don't
have
a
syntax
for
that
so
percent
hash.
Mark
ampersand
is
my
proposed
syntax.
For
the
moment.
I
know
we
will
change
that,
and
so
this
is
an
example
where
we
are
looking
for
all
perpetrators.
E
That
already
have
more
than
two
convictions,
and
I
think
that
that's
a
pretty
normal
query
you
would
put
in
somewhere
and
yeah
from
you.
You
you
have
this
path.
Add
that
conviction
and
this
path
is
not
singular,
so
you
would
look
at
the
the
size
of
that
node
set
and
if
that
size
is,
is
greater
than
2,
then
this
comparison
would
return.
True.
F
F
B
E
I
think
everybody
must
have
read
that
document,
because
it
summarizes
20
years
of
experience
with
a
particular
way
of
using
extension
points
that
didn't
work
out
very
well
at
all.
So
we
have
to
be
careful
about
that
namespace,
but
yeah.
Stefan,
that's
just
one
one
character
we
could
use
for
for
the
extension
point.
E
C
E
G
C
E
The
the
fact
that
the
extension
is
being
used
is
rather
obvious
from
a
simple
part
of
the
query,
so
you
can
look
at
a
query
and
extract
the
set
of
extension
names
that
have
been
used
in
the
query.
I
think
that's
one
important
property,
because
many
extension
points
don't
have
that
property
and
that
that
that
means
you.
E
F
E
B
B
Yeah,
I
you
know
just
listening
to
this
discussion
is
not
making
me
happy
about
this
idea.
You
know
I
I
you
know.
I
like
the
idea
of
having
length,
I
like
the
idea
of
having
index
because
that's
sort
of
a
big
hole
in
json
path
at
the
moment,
but
inventing
a
general
purpose
function,
notation
with
a
new
syntax
character
and
so
on.
B
E
B
F
E
E
So
if
we
agree
on
the
hashmark
syntax,
then
we
can
just
look
for
the
hashmarks
and
then
we
have
a
list
of
the
extensions
that
need
to
be
supported
to
to
run
this
query.
We
then
also
have
to
to
curate
that
namespace.
So
that's
the
hard
part
of
the
problem,
but
the
easy
part
is
things
become
easy
if
you
at
least
have
a
common
syntax
and
not
everybody
who
wants
to
extend
things
invents
their
own
syntax.
For
that.
B
Yeah
the
reason
I'm
I'm
having
trouble
warming
up
to
this
is,
you
know.
Json
path
is
out
there.
Lots
of
people
use
it,
it
works,
but
the
reason
this
rfc
exists
is
to
define
the
interoperable
subset
so
that
you
know,
if
you
use
this,
then
if
somebody
breaks
on
it,
it's
their
problem,
not
yours,
you
know
to
oversimplify
and
that's
what's
motivating,
at
least
in
my
mind
this
work.
A
I
I
see
it
from
the
alternative
approach,
whereas
if
we
provide
a
commonality
for
extensions,
it
means
that
future
implementations
can
ignore
extensions
in
a
consistent
way
and
and
implementers
can
decide
we're
not
implementing
these.
These
various
extensions
before
for
our
particular
deep,
whatever,
and
so,
where
there's
a
high
degree
of
future
proofiness
against
that.
E
B
A
This
doesn't
eliminate
the
problem,
the
the
the
kind
of
problem
that
you're
describing
with
sql,
but
it
at
least
provides
a
sinkhole
for
people
willing
to
extend
it
and
for
implementations
willing
to
implement
those
extensions.
Sql,
never
provided
that
in
expect
it
was
a
bit
too
rigid
and
then
people
went
off
piste.
B
E
A
B
E
B
K
E
C
A
B
D
B
E
E
B
A
E
Then
this
is
useful.
It
is
useful
to
have
text
during
the
relationship
like
we
have
our
appendix
a
for
xboth,
assuming
that
people
who
are
still
in
the
xml
to
json
migration,
we'll
know
experts
and
we'll
try
to
find
out
what's
going
on
with
jason
pass,
that's
useful
so
that
that's,
I
think,
the
the
position
on
this.
I
wasn't
even
aware
about
this
jason
path,
expression,
but
I'm
sure
that
there
is
a
community
out
there.
E
E
E
B
E
E
This
payroll
are
argument,
but
I
think
it's
not
a
strong
argument
anyway,
because
the
whole
thing
is
about
writing
a
paragraph
making
it
simpler
for
people
already
coming
there
to
to
understand
what
jsonpath
is
about,
and
so
the
really
question
is:
can
isg
vet
that
paragraph
and
who's
going
to
write?
The
paragraph
I
mean
I,
I
don't
really
yeah
somebody
who
knows
your
json
path.
So,
let's
find
that
person.
Okay,.
B
A
A
No
usually
glenn
for
restricted
documents,
one's
either
behind
paywalls,
or
I
know
that
there's
another
there's
a
specification
in
another
part
of
the
ietf,
where
it's
classified
or
top
secret
or
something
one
of
the
ref
normative
references.
Is
that
there's
usually
an
arrangement
made
with
a
small
subset
of
the
iesg
or
co
of
people
qualified
or
they
or
in
the
case
of
iso.
They
usually
provide
a
draft
version
to
a
handful
of
people
at
an
ad
hoc
basis.
C
E
C
B
F
C
E
D
B
C
A
A
C
C
E
A
C
E
B
F
Yep
yeah,
okay
I'll
leave
it
open
in
the
tab.
We
just
probably
closed
this
one
off
so
we're
if
we
have
an
expression
like.
Let
me
put
this
in
the
chat
question
mark
at
dot:
foo
equals
equals
dollar
bar
and
those
select
structured
types
then
we're
just
going
to
say
false,
even
if
they
happen
to
be
from
a
human
point
of
view,
equal.
K
E
Today,
yeah,
what
makes
me
uncomfortable
of
course,
is
that
when
we
do
our
json
path
category
at
some
point
later
on,
then
we
may
want
that
expression
to
have
a
different
meaning,
and
that's
always
bad.
If
extending
something
means
that
existing
things
get
a
different
meaning,
and
there
there's
no
way
to
recognize
this
as
a
syntax
error
or
something
because
we
don't
know
what
is
going
to
hide
behind
the
the
at
dot,
foo
and
dollar
dot
bar.
B
E
C
F
E
E
B
I
E
That's
the
the
cop
out
that
people
have
invented
because
you
you
can't
get
normalization
right.
It
means
you
define
a
comparison
operator
that
essentially
is
defined
in
a
similar
way.
You
would
define
a
comparison
operator
if
you
had
normalization,
but
you
don't
require
the
normalization
to
actually
take
place.
Yeah.