►
From YouTube: IETF-JSONPATH-20220614-0800
Description
JSONPATH meeting session at IETF
2022/06/14 0800
https://datatracker.ietf.org/meeting//proceedings/
A
B
A
Anyhow,
maybe
we
should
just
begin
sorry
good
morning,
good
afternoon,
good
evening,
folks,
this
is
the
jason
path
june
interim
meeting
the
usual
disclaimers
of
noting
well
as
this
is
an
ietf
meeting
and
follows
the
same
rules
and
procedures
as
all
other
ietf
meetings,
the
usual
disclaimers
of.
If
you
have
any
questions
about
this,
you
can
speak
to
tim
or
myself
or,
if
francesca's
around.
Maybe
at
some
point
later
you
can
always
speak
to
her
as
lady
just
to
get
through
the
the
checklist
notes.
A
A
I
guess
we'll
just
keep
an
eye
out
on
java
chat,
because
there's
only
a
few
reviews
are
agenda.
Bashing,
noting
that
I've
put
a
couple
of
issues
that
I
think
are
priority
in
getting
through
given
they're
quite
outstanding
and
kind
of
important,
and
just
like,
we
need
to
wrap
them
up
after
the
last
session.
G
G
G
B
G
G
G
A
A
F
B
I
I
B
A
A
H
B
Great
in
terms
of
scheduling,
I'd
be
perfectly
happy
to
do
both
the
drafts
together.
The
but
the
constraint
that
is
is
not
definitely
true
is
that
jsonpathbase
cannot
precede
iregx
because
it
has
a
dependency
on
iregas.
So,
if
they're
going
to
be
done
at
a
different
time,
my
request
has
to
be
done.
First,.
A
A
Actually
that
doesn't
sound
like
a
terrible
idea.
I
think
I
think
what
we
need
to
do
then,
is
just
work
out.
The
timing
of
that,
in
terms
of
when
you
think
it'll
be
ready
for
that,
and
then
we
can
say
okay.
Well,
then
I've
said
that
I
can
do
that
and
then
allowing
plotting
out
when
it
can
then
go
after
that
for
working.
A
B
So
I
I
think,
we'll
probably
be
ready
pretty
as
soon
as
we
get
through
this
current
pull
request,
which,
frankly
I
haven't
looked
at
yet,
but
I
I
will
quickly-
and
I
don't
think
it's
out
to
be
controversial
and
I'll
be
I'll,
be
happy
to
help
with
the
with
the
shepherding
document
help
collaborate
on
that.
So
I
think
we
could
do
this
pretty
soon.
Pretty
quick.
A
A
So
last
last
session,
just
really
quickly
just
to
frame
this,
we
we've
had
a
bit
a
couple
of
in
the
past
couple
of
interviews.
We've
had
a
few
discussions
about
getting
the
considerations
in
because
we
kind
of
have
to
put
something
there
and
there's
a
few
things.
There's
clearly
a
few
subjects
in
the
case
we've
got
185
and
going
in
second
186..
A
B
B
B
B
B
B
G
I
haven't
looked
at
the
the
details.
I
mean
both
comments
are
really
editorial
comments
on
on
how
to
say
things
right
and
I'm,
I
think,
being
very,
very
explicit
and
reminding
people
of
things
that
that
they
should
know,
but
maybe
don't
is,
is
always
a
good
thing.
So
maybe
we
can
make
use
of
your
text
in
some
form
to.
E
B
B
B
C
A
B
K
A
B
A
A
We've
certainly
seen
a
lot
of
interest
in
including
various
bits
of
functionality
into
json
path
and
with
on
a
few
occasions,
we've
largely
held
the
consensus
of
that
would
be
good
as
an
extension,
because
it
doesn't,
you
know,
we're
trying
to
keep
the
base
back
exactly.
You
know
what
the
name
is
on
the
tin,
but
then
we
have
actually
haven't
really
got
around
to
defining.
A
G
G
G
G
B
B
G
A
G
B
K
G
So
I
would
ship
this
draft
with
an
initial
registry
that
has
just
length
in
it
or,
however,
we
want
to
call
this
thing,
but
but
what
has
been
asked
for
in
in
154
and
then
we
would
have
a
policy,
a
registration
policy,
that
we
have
to
decide
how
things
get
added,
and
you
can
do
this
in
a
very
permissive
way.
You
can
do
this
in
a
very
conservative
way.
The
rfc
8126
has
a
number
of
policies
we
can
choose
from
or
we
can
invent
our
own
policy.
B
I
think
the
assumption
has
been
that
functional
syntax
is
a
promising
direction.
Okay,
I
am
probably
against
this.
I
hate
optional
features
in
standards.
I
hate
them
and
I,
my
favorite
standards
are
things
that
just
have
you
must
do
this
and
you
must
not
do
that
and
that's
the
end
of
the
game
because
they
grow
like
cancer,
and
you
know
if
you're
not
you're,
careful
you're
on
the
slippery
path
that
leads
to
sql,
which
has
essentially
zero
interoperability.
H
A
And
the
counter
argument
that
I
would
make
is
that
sql
doesn't
have
something
like
an
iona
registry
for
managing
our
extensions
and
where,
where
we've
gone
with
these
discussions
is
having
that,
which
means
that
you
know.
If
we
do
implement
extensions,
there
is
a
controlled
mechanism
of
management
of
the
main
spacing
of
extensions
and
the
likes.
A
A
A
We
think
that
that's
an
inevitable
based
off
of
the
fact
that,
during
the
work
that
we've
done
over
the
past
year
in
a
bit,
the
numerous
requests
have
come
up
asking
for
hey.
I
want
to
have
this
feature,
so
the
demand
for
it
and
the
intent
of
the
wider
community
is
definitely
there
for
people
to
be
extending
it,
either
with
implementations
that
are
to
be
interrupt
or
even
implementation,
extensions
that
are
not
to
be
interrupt
for
whatever
reason.
A
B
Fair
enough,
this
is
a
reasonable
debate
to
have
I
mean
I
would
point
out
that
json
itself
has
no
extensions.
Xml
has
no
extensions.
There
are
lots
of
very
successful
things
that
have
no
extensions,
but
let's
not
argue
that
right
now
so
do
we
have
somebody
who's
going
to
write
a
concrete
proposal
for
this.
K
Can
I
just
a
perspective,
I
think
if
we
were
coming
up
with
a
new
standard
here,
then
I'd
be
in
favor
of
the
extension
point
mechanism
and
an
example
with
length.
I
think,
because
this
is
mainly
from
our
perspective,
a
rearguard
action
and
we've
got
30
odd
implementations
of
jsonpath
in
the
wild
which
effectively
extend
the
standard.
Well,
you
know
somewhat
extend
the
standard
in
different
ways.
K
A
I
disagree.
I
don't
think
that
it
is
too
late,
because
we
shouldn't
set
the
expectation
that
all
implementations
have
to
implement
all
of
the
extensions,
only
the
the
mechanisms
of
which
they
identify
where
an
extension
is,
and
then
it's
up
to
an
implementation,
or
even
a
configuration
of
an
implementation,
to
determine
whether
or
not
it's
actually
going
to
do
something
about
it.
And
one
of
the
things
that
we'll
need
to
include
is
what
happens
if
an
implementation
stumbles
upon
a
json
path.
Theory
that
has
an
extension
that
it
just
simply
does
not
support.
A
What
is
the
behavior
there?
Is
it
to
fail?
Is
it
to
do
something
else?
You
know
I'm
of
the
argument
of
fail,
hard
and
vast,
but
this
is
something
that
needs
to
be
explicitly
called
out.
So
no,
I
don't
think
it
is
too
late.
We
already
diverge
away
from
the
other
implementations
in
varying
levels.
This
is
nothing
completely
radical
in
that
regards.
K
A
Yep-
and
I
I
I
I
I
think,
you're
probably
right
on
that
and
another
way
that
that
can
be
evidenced-
is
that
when
we've
seen
proposals
for
extensions
in
the
design,
the
way
that
those
have
been
proposed
as
as
sort
of
straw,
man
or
examples
or
whatever
have
also
been
immune
system.
So
that
actually
gives
me
a
reason
to
argue
in
favor
for
it
so
that
we
do
have
an
attempt
to
try
and
normalize
down
a
common
way
of
accepting
it.
A
J
B
Of
the
proposal,
of
course,
so
so
yeah,
so
stefan
this
is
actually
a
well-blazed
path.
I
mean
I'm,
I'm
not
crazy
about
this
idea,
but
the
registry
is
okay.
I
mean
that's
how
we
have
media
types
and
content
types
on
the
internet
right.
We
have
a
registry
and
if
you
want
a
new
one,
there
are
rules,
but
you
have.
You
have
to
have
a
an
unmodifiable
published
spec
and
you
know
there's
some
other
rules
and
so
on.
So
we
have
all
the
machinery
to
do
a
registry
and
make
it
work.
A
E
B
Actually,
we
had
draft
status,
and
I
think
I
settled
the
issue
on
that
quite
nicely
on
the
iregas
part.
What
I
I'd
before
we
jump
into
the
next
issue,
I'd
like
to
just
you
know,
get
the
sense
of
the
group
on
what
what
is
our
draft
status
on
on
jsonpath
base,
because
my
impression
is
that
we're
close
that
you
know.
I
would
like
at
this
interim,
to
have
a
very
short
list
of
things
that
get
us
to
work
group
to
to
last
call.
G
G
B
G
A
B
B
K
A
F
G
B
G
B
B
G
B
A
E
C
J
B
D
B
G
I
K
G
B
K
B
B
I
B
K
J
B
B
A
B
A
A
K
A
G
G
A
E
A
G
G
I
I
have
a
quick
observation
so
right
now
the
milestones
look
like
what
I
just
posted
to
the
chat,
but
obviously
the
the
date
is
not
quite
in
there,
but
we
usually
tell
if
we
add
a
document.
We
usually
tend
to
record
that
in
the
milestone.
So
maybe
the
chairs
should
quickly
put
in
the
additional
milestone
and
get
that
agreed
by
the
80s
yep.
B
F
A
A
We
certainly
can
maybe
a
better
way
of
approaching
this
is
to
post
onto
our
mailing
list
post.
A
request
will
lead
to
the
draft
if
you've
got
it
in
version
control
or
submitted
somewhere
and
the
wider
mailing
list,
which
is
a
lot
more
people
can
review
it
and
see
if
it
makes
sense
to
be
as
part
of
this
work.
B
If
you
post
it
to
the
mailing
list,
absolutely
yes,
I'm
sure
that
if
you
post
your
draft
to
the
so
there's
really
a
couple
of
ways
forward,
one
one
thing
would
be
to
post
a
draft
to
email
address.
You
know
itf.jsonpath
or
just
jasonpath
at
itf.
Pardon
me
the
other
would
be
to
go
into
our
github
and
propose
a
an
issue
and
a
optionally
a
pull
request
to
implement
the
issue.
C
C
B
Yeah,
the
the
correct
way
to
to
start
a
discussion
in
the
ietf
is
to
post
a
draft
to
the
mailing
list,
because
right
now
on
this
on
this
conference,
we
have
five
people
or
something
like
that,
but
on
the
mailing
on
the
on
the
mailing
list,
we
have
many
more
people
and
you
would
get
a
better
discussion
if
you
post
your
draft.
There.
B
C
C
B
Is
to
send
an
email
to
the
working
group
to
start
a
discussion,
so
there's
the
jason
path.
Working
group
that
francesca,
who
is
our
area
director,
has
proposed
that
you
would
be
better
to
send
it
to
the
yeah.
If
you
look
in
the
comments
yeah,
you
see,
you
see
the
comments
so
that
we
have
suggestions
for
how
to
move
forward.