►
From YouTube: IETF109-JSONPATH-20201116-0900
Description
JSONPATH meeting session at IETF109
2020/11/16 0900
https://datatracker.ietf.org/meeting/109/proceedings/
A
Okay,
well,
it
looks
to
me
like
it's
time
for
us
to
start
first
order
of
business,
can
you
hear
me
somebody
speak
up
or
wave
or
something.
A
Excellent
is
that
james?
Yes,
yes,
okay!
Well,
on
behalf
of
james
and
myself,
welcome
to
everybody
good
morning
good
evening,
good
afternoon,
depending
of
which,
depending
where
that
applies,
wherever
you
are,
I'm
actually
kind
of
surprised
and
delighted
at
the
number
of
people
here.
So
so,
let's
get
straight
to
it,
oh
and
more,
coming
in
all
the
time,
can
we
move
along
there.
James
next
slide
yep
right.
So
whether
or
not
you
have
been
involved
in
the
ietf
before
read
this
it
it
matters.
A
There
are
certain
rules
that
apply
as
regards
intellectual
property
and
conduct,
and
so
on
and
and
they're
not
optional.
So
please
do
read
this
and
take
it
seriously.
A
A
A
Excellent,
who
is
that
speaking
sorry
was
michael.
A
Richardson,
michael
richardson,
thank
you
very
much,
michael.
Let
me
know
when
you've
got
that
running.
B
A
Excellent.
Thank
you
for
that.
For
those
of
you
who
haven't
used
the
interface
before
you
can
detach
the
chat,
so
you
can
see
both
the
user
list
and
the
chat
that
that's
that's
quite
useful.
A
Okay,
thank
you
both
for
for
pitching
in
now.
If
the
agenda,
that's
posted,
as
the
agenda
was
very
minimal,
but
then
there's
a
larger
agenda,
maybe
james,
we
could
look
at
that
and
before
we
do
anything
else,
just
a
couple
of
words.
My
notion
was
to
see
if
there
were
a
few
sort
of
big
and
unsubtle
issues
that
we
might
have
a
good
hope
of
making
progress
on
here
in
real
time.
A
But
I'm
not
religious,
and
I
don't
think
james
is
about
this
either.
Anybody
would
like
to
object
to
one
of
these
or
or
add
something
they
think
would
be.
A
good
candidate.
Now
would
be
a
good
time
to
speak
up.
D
Yeah,
I
was
thinking
of
one.
I've
been
developing
one
in
line
with
one
of
the
drafts
to
kind
of
exercise
the
draft
and
push
out
any
corners
along
with
it
just
a
way
just
to
help
to
as
a
way
of
developing
the
draft.
A
May
I
suggest
that
what
we
do
is
when
we
get
to
compliance
test
suite
in
the
agenda.
We
we
cover
that,
together
with
a
reference
implementation,
since
the
two
are
closely
linked.
A
Okay,
without
further
ado,
then,
let's
get
into
this
now.
The
general
issue
here
is
the
writing
and
review
process.
There
are
you
know
the
vast
majority
of
working
groups.
A
And
at
a
metal
level,
if
you're
going
to
speak
up,
let's,
let's
use
the
the
list,
you
push
the
little
up,
raise,
hands
button
and
and
we'll
call
on
you
things
work
better
that
well!
So
I,
if
I'm
going
to
shut
up
and
if
I
hear
silence
for
a
little
while
I'm
going
to
assume
that
means
everybody's
fine
with
the
typical
hybrid
github
and
mailing
list
approach.
A
Okay,
so
found
excellent.
Now,
there's
one
meta
issue:
james
and
I
have
been
discussing
a
bit
about
so
we're
going
to
have
to
name
and
edit
an
editor
or
co-editors,
and
several
of
you
have
have
expressed
willingness
to
put
cycles
into
that.
So
thank
you
so
much
for
that.
It's
it's
so
great
to
have
people
who
have
energy
to
do
that
speaking.
You
know
personally,
my
instinct
and
I've
talked
about
this.
A
To
some,
you
know
really
seasoned
iatf
hands
is
to
have
you
know
fewer
rather
than
more
editors,
so
so
I
think
most
most
likely
will
probably
want
to
ask
one
of
you
to
step
forward,
and
the
idea
is
that
if
you're,
not
netter,
that
on
enables
unleashes
more
energy,
you
can
put
into
the
discussions
and-
and
we
would
like
to
have
lots
of
people
putting
energy
into
the
discussions.
A
A
Okay,
we
have
two
existing
input
drafts
we're
going
to
have
to
get
to
the
point
where
we
have
a
succession
of
working
of
working
group
drafts.
I
think
people
on
the
call
probably
understand
the
the
normal
process
that
works.
You
have
working
group
drafts
and
we
have
consensus,
calls
and
update
the
drafts
and
eventually
we're
all
happy
and
take
it
and
convince
our
ads
that
things
are
fine
and
take
it
forward.
E
Yeah,
so
we
have
two
drafts.
One
was
essentially
generated
from
the
original
2007
article
and
essentially
just
updated
a
little
bit,
but
not
completely
for
2020
and
one
is
charging
ahead
and
and
defining
some
details,
and
I
think
that's
actually
a
very
good
situation,
because
we
have
input
for
both
the
introductory
part
and
and
the
detail
part
of
the
document.
So
the
next
step,
I
think
we
should
do,
is
just
merge
the
two
drafts,
which
is
probably
easier
when
we
have
had
the
discussions
we
have
to
have
today.
B
Ahead,
I
guess
the
question
I
would
have
to
the
to
the
working
group
is:
do
we
have
we've
got
glenn
here,
so
we've
got
the
editor
for
one
of
the
documents
without
me.
Having
to
scroll
through
would
would
would
both
of
the
editor
would
both
of
the
editors
to
that
be
willing
to
put
in
the
time
to
help
editorialize.
B
What
would
then
become
the
the
starting
working
group,
a
doctor
adopted
document.
D
Okay,
I
have
to
join
the
queue.
Thank
you
so
edward
shiroff
and
I
were
nominally
editors
of
the
the
other
draft
marco
has
been
joining
in
the
writing
process.
So
I
don't
have
a
strong
feeling
about.
You
know.
Continue
I'm
happy
to
offer
that
if
anybody
else
wants
to
kind
of
take
the
lead
on
that,
I'm
very
happy
I
think
edward
has
has
got
some
time
available.
A
There,
okay,
so
I
I
think
I'm
hearing
consensus
that
nobody
is
really
attached
to
the
notion
that
it
must
start
from
document
a
or
document
b
and
nobody
is
objecting
to
the
notion
of
creating
you
know
a
working
draft
taking
input
from
both
of
them.
So
would
I
be
correct
in
saying:
that's
that's
the
feeling
that
I'm.
A
D
Yeah
I'll
just
voice
one
concern,
which
is
that
there
are
a
number
of
things
in
the
original
gerstner
article
which
were
kind
of
dangling
links.
You
know
things
that
weren't
dereferencable
promises
that
weren't
delivered
and
such
like,
and
there's
a
little
bit
concerned
that
if
we
took
that
as
a
starting
point,
the
camel
would
have
got
its
nose
under
our
tent
as
it
were,
and
we
could
soon
end
up
with
the
whole
camel
there.
D
D
D
So
I
was
trying
to
be
conservative
there,
so
it'd
be
easy
to
adopt.
But
I
don't
mind
if
we
start
from
a
blank
sheet
and
cut
and
paste
from
both
of
them,
but
just
be
a
little
bit
nervous
about
taking
the
whole
of
the
ghost
document.
To
start
with,
because
it's
very
difficult
to
remove
text,
it's
easier
to
add
text
incrementally
that's
my
personal
position.
A
E
Stefan
told
me
that
his
interest
in
this
work,
his
focus,
has
shifted
back
from
from
computer
related
stuff
to
mechanical
engineering
related
stuff
in
in
the
last
decade,
or
so
so
he's
not
going
to
put
in
major
cycles,
but
he's
certainly
interested-
and
he
has
already
asked
me
about
the
progress
of
this
activity,
because
things
take
some
time
starting
up
in
the
ietf.
So
I
think
he
will
be
around.
E
So
maybe
we
have
different
sets
of
experiences
here.
Of
course,
not
not
all
of
the
the
original
2007
article
has
has
become
true,
so
we
will
have
to
to
look
at
that
and
that's
maybe
a
welcome
opportunity
to
to
actually
check
whether
there
are
maybe
some
some
nooks
and
crannies
of
the
jason
parker
universe,
where
some
of
this
has
actually
happened
and
that
we
may
have
to
to
look
at.
E
But
yes,
so
there
is
an
appendix
that
describes
the
current
implementation
of
2007
and
that
that's
probably
not
useful
anymore
at
this
point
in
time,
and
so
on.
A
Excellent,
I
mean
I
like
what
I'm
hearing
it
sounds
like
nobody
is
particularly
religious
about
how
we're
going
to
use
this
and
we'll
use
the
material
from
from
both
of
them
to
work
towards
a
an
actual
working
group
draft
great
okay.
So
I
think
I
think
we
all
understand
where
we
stand
on
that
one.
Does
anybody
want
to
say
anything
else
about
about
the
existing
drafts
and
how
we're
going
to
move
forward.
A
Excellent,
okay,
so
moving
on
the
agenda,
there's
the
compliance
test
suite
and
the
related.
You
know
reference
implementation.
You
know
I
I
I'm
I'm
perhaps
being
a
little
bit
self-indulgent
and
putting
on
this.
Having
had
a
lot
of
experience
in
this
stuff,
I
I
think
that
compliance
tests
are
insanely
valuable
and
I
understand
they
are
never
the
part
of
the
official
output
of
a
working
group,
but
I
I
just
wanted
to
put
on
the
record
that
I
I'd
like
I'd
like
it.
A
D
Yeah,
the
cts
as
part
of
the
reference
implementation
repos
is
my
day.
Yeah
yeah
one
or
two
people
may
have
chipped
away
at
it,
but
it's
mainly
my
day.
A
Okay
and
you're,
okay
with
posting
that
and
I
haven't
looked
I
it's
on
a
repo
and
and
you'll
be
open
to
taking
pr's
and
things
like
that.
D
D
A
D
An
approach
I
took
with
this
test
suite
was
to
make
it
lag
strictly
behind
the
draft,
because
it's
easy
to
get
ahead
of
the
draft,
and
then
you
end
up
with
essentially
tested
behavior,
that's
not
specified,
which
I
think
is
anathema
to
this
this
group.
So
I
kind
of
recommend
that
approach
really
to
try
and
let
you
know
if
there's
a
reference
implementation.
Certainly
if
there's
a
compliance
test
suite
to
have
it
lag
behind
the
the
words
in
the
text
rather
get
ahead
of
the
words
in
the
text.
D
E
Thank
you
kirsten
yeah,
what
glenn
said.
So
it's
really
easy
to
have
a
document
that
that
doesn't
really
describe
things
and
the
compliant
test
suite
that
that
does
and
then
you
you
run
into
ambiguities
and
so
on.
So
it's
probably
a
good
idea
to
to
have
a
good
way
to
reference
back
from
the
test
suite
to
the
document
to
make
sure
that
things
that
are
in
there
are
either
rooted
in
the
document
or
are
actually
proposals
for
something
that
needs
to
be
put
in
the
document,
but
isn't
there
yet.
E
But
I
would
like
to
repeat
my
my
observation
that
it's
not
really
the
job
of
the
working
group
to
do
compliance
test,
suites
and
and
reference
implementations.
Actually,
some
itfa
groups
have
done
that
so,
for
instance,
the
opus
people
have
actually
generated
a
reference
implementation,
so
we
could
do
that,
but
it
would
be
a
somewhat
unusual.
F
Okay,
I
understood
alexander.
Yes
thanks
everyone.
I
want
this
account.
What
what
carson
has
said?
I
I
think
we
should
be
careful
so
that
not
the
reference
implementation
actually
drives
the
standardization
effort,
because
what
could
happen
is
that
people
actually
look
us
sideways
on
the
implementation
and
say:
oh,
we
actually
found
out
that
it
would
be
not
much
nicer
if
we
tweaked
here
and
there,
so
that
the
implementation
suddenly
becomes
the
driving
force
in
standardization.
I
think
that
shouldn't
happen
yeah,
so
so
the
the
the
reference
implementation.
F
A
Yeah
good
point:
I
hadn't
actually
considered
the
issue
of
the
official
status,
but
but
that's
a
good
one.
We
should
look
at
I
I
had
seen
it
as
unofficial.
You
know,
just
in
I'm
reflecting
the
personal
bias.
I've
found
that
having
a
test
suite
actually
more
than
a
reference
implementation
to
be
tremendously
useful
and
what
you
cautioned
against.
A
G
I'll
try
again
unmuted,
actually
tim,
you
just
covered
pretty
much.
My
point,
which
was
test
suite
as
a
working
group
item,
seems
a
bit
of
a
stretch
but
a
a
a
a
set
of
worked
examples
with
canonical
results
so,
rather
than
the
test
suite
implementation,
the
the
the
the
body
of
data.
Sorry,
it's
early
and
my
brain's
not
running
at
full
speed,
a
body
of
data
to
use
as
a
as
a
sweet
check
for
your
own
implementation
would
be
incredibly
useful
and
possibly
a
valid
working
group.
Working
group
item.
A
E
Yeah,
so
let
me
contribute
myself:
we
like
to
have
good
examples
in
specifications
and
that
may
be
somewhat
of
an
anathema
to
to
people
who
think
that
specifications
should
be
overly
formal
documents
that
you
need
a
phd
to
understand,
and
so
that's
not
usually
the
way
we
look
things
in
the
itf.
E
So
good
examples
are
kind
of
a
test
suite
a
little
bit
and
we
actually
have
built
test
suites
out
of
the
examples
in
an
rfc,
but
there
is
essentially
never
a
way
to
be
complete
in
that.
But
implementers
tend
to
read
the
examples
first
and
then
the
text
and
not
the
other
way
around
and
julian
has
agreement
well
julian.
Do
you
want
me
to
say
that
sorry,
sega
julian,
has
a
comment
in
the
chat.
D
Yeah
I
understand
that
the
a
piece
of
software
is
going
to
rot
over
time,
and
so
it
can't
be
a
deliverable
of
a
working
group
because
it
will
just
become
irrelevant.
D
F
Thank
you.
I
actually
it
just
came
to
my
mind.
I
see
one
opportunity
and
one
risking
that
in
that
compliance
test
street
the
risk
is
that
any
implement
of
any
any
chest
path.
Implementation
would
like
run
their
code
against
that
compliance
suit
and
consider
it
100
compliant.
Even
if
that
compliance,
it
probably
doesn't
cover
100
percent
of
the
specification.
F
That's
the
risk
that
I
see.
So
we
need
to
be
very
clear
on
what
that
compliance.
You
does
actually
cover,
and
and
now
to
the
better
thing
to
the
opportunity.
I
think
as
soon
as
we
we
have
final
residue
in
jsonpass,
the
idf
will
want
to
have
a
validation
tool
that,
whenever
jsonpass
appears
in
their
documents
in
future
drafts,
they
want
to
validate
it.
So
you
might
want
to
talk
to
the
idf
tools,
people
to
see
if
they
have
experience
with
other
languages,
that
they
integrated
into
the
authoring
tools.
H
Julian
hello,
can
you
hear
me?
Yes,
I
had
to
grab
a
headset
sorry,
so
the
http
structured
header
spec,
is
something
that
defines
a
new
microsyntax
for
header
fields
in
http,
so
because
of
the
whites.
H
Because
of
the
many
differences
that
we
have
in
header
syntax,
so
this
is
essentially
a
micro,
a
language
to
to
describe
header
fields
and
tags,
and
so
that
spec
is
currently
an
auth
for
the
edge
so
to
be
published
and
the
the
working
group
are
actually
the
editor
of
the
spec
mark.
Nottingham
came
up
with
a
set
of
test
inputs
and
expected
test
output.
H
So
that's
not
part
of
the
spec,
but
but
that
happened
in
parallel
to
writing
the
spec
and
following
up
to
what
was
just
asked
before
in
in
the
new
v3
rfc
format,
world,
we
can
tag
source
code
and
artwork
with
types
and
based
on
the
type.
We
can
run
validation
tools
on
that.
That's
not
yet
part
by
part
of
the
rfc
publication
pro
process
but,
for
instance,
it's
part
of
the
tool
chains
that
many
working
groups
or
some
working
groups
use
to
build
their
specs
from
markdown.
H
So
in
particular,
mark
nottingham,
just
wrote
a
validator
for
http
messages
that
you
might
have
in
examples.
So
this
is
relatively
new,
but
we
should
look
into
that
and
that's
clearly
possible.
G
That
rick
again
hi
guys
I
just
had
a
quick
look
at
the
jason
pointer
rfc,
just
as
a
sort
of
cross-reference,
and
that
has
some
examples
which
you
know
personally,
I
found
extremely
useful
to
start
building
a
test,
validation
suite
from
so
perhaps
as
a
pragmatic
approach,
at
least
having
some
examples
that
are
fairly
canonical
and
cover
most
of
the
corner.
Cases
within
the
actual
specification
goes
a
long
way
and
then
the
working
group
can
can
worry
about
producing
a
test
suite
as
a
further
charter
item.
A
Yep
cool,
I
I
mean
my
experience-
is
I've.
You
know
been
engaged
in
the
development
of
various
dsls
of
one
kind
or
another,
and
I
notice
the
ones
that,
when
they
launch
have
a
command
line
validator
that
anybody
can
just
download
and
run
people
find
that
just
just
insanely
helpful
and
I
recognize
the
risk
that
you
know
somebody
might
over
rely
on
that
and
assume
that
if
it
passes
the
validator
everything's
fine,
but
but
still
it's
a
useful
tool.
Okay,
I
think
I'm
hearing
julian
go
ahead.
H
Can
clearly
sorry
yeah
yeah
one
more
thought
about
test
cases,
so
if
we
have
test
cases,
it's
extremely
helpful
to
have
also
test
cases
for
invalid
syntax
and
potentially
also,
for
example,
diagnostics
that
you
might
want
to
produce,
because
that's
a
good
way
to
avoid
having
implementations
except
things
that
they
shouldn't
accept.
H
A
Okay,
I
think
I
could
summarize
our
consensus
as
everybody
seems
to
be
friendly
to
the
idea
of
you
know
something
ranging
from
one
extreme
to
having
good
examples
to,
on
the
other
extreme,
having
a
fairly
complex
to
you
know,
another
option
having
you
know,
test
inputs
and
outputs
to
actually
having
runnable
code,
and-
and
you
know,
I
think
we
can
all
agree
that
work
done
in
any
of
these
areas
is
helpful.
A
We'll
have
to
see
if
any
of
it
has
official
standing,
but
you
know
I
certainly
think
we
we're
all
friendly
to
such
work
and
would
appreciate
it.
Anybody
who
does
it
anything
more
on
the
subject
before
I
move
along.
A
Okay,
that
was
useful.
Thank
you,
okay,
an
actual
material,
technical
issue
and-
and
maybe
we
can-
we
can
settle
this.
So
as
everybody
knows,
the
original
gessner
spec
specifies
syntax
for
how
you
could
how
you
could
jsonpath
could
reach
out,
and
you
know,
invoke
functions
but
didn't
actually
specify
anything
about
what
the
functions
would
be
or
what
language
it
would
be.
And
you
know
various
implementations
have
done
various
things,
and
I
would
be
very
interested
to
hear
the
sense
of
the
working
group
as
to
well.
What
should
we
do?
A
E
Yeah,
I
don't
understand
the
question,
so
what
does
specified
scripting
language
mean
the
the
original
article
says
use
whatever
scripting
language
you
have
and
that's
certainly
not
a
model
that
that
is
very
useful
and
specifying
a
scripting
language
might
mean
we
come
up
with
an
expression
language
that
can
be
used
in
jsonpath,
or
it
might
mean.
E
Oh,
let's
all
do
python
and-
and
you
can
do
python
in
in
these
parenthesis
and
problem
solved,
and
I
think
the
the
answer
to
the
second
approach
is
no,
and
the
answer
to
the
first
approach
is
yes,
so,
let's
specify
that
expression
language
and
find
out
what
is
actually
needed
in
that
expression
language.
So
the
the
original
code
from
from
stefan
had
essentially
a
regex
parser
for
this
expression
language.
E
So
it
was
very
limited
in
the
level
of
complexity
you
you
could
express
with
it,
but
it
actually
already
turned
out
to
be
useful
for
people.
So
I
think
yes,
we
should
specify
that
expression,
language.
G
Rick
carsten
beat
me
to
it:
I'm
I'm
in
full
agreement
with
carsten,
so
specifying
the
syntax
for
the
expressions
used
for
for
searching
absolutely
specifying
external
function.
Access
is,
is
a
step
too
far
and
I
think
is
out
of
scope.
Having
implemented
jsonpath
parsers
in
non-scripting
languages,
the
ability
to
have
a
constrained
but
reasonably
flexible
expression.
Language
is
incredibly
powerful
and-
and
I
really
support
that
effort,
but
expecting
that
your
entire
implementation
is
javascript
or
python
or
or
whatever.
That's
that's
a
non-starter
for
me
anyway.
G
D
There
is
a
bit
of
a
distinction
in
my
mind
between
filters,
the
square
brackets
question
mark
round
brackets
stuff
and
the
the
camera
scripting
expression
side
of
things
which
seems
more
open-ended,
and
certainly
when
I've
implemented
this
in
the
past,
the
filters
came
out
fairly
cleanly
and
didn't
seem
to
you
know
the
there's
quite
a
lot
of
consensus
amongst
the
implementations
about
what
filters
are
valid,
but
on
the
other
side
there
was
complete
lack
of
consensus
and
my
concern
there
is
just
how
would
we
as
a
group,
come
to
any
kind
of
consensus,
because
I
could
imagine
people
just
arriving
at
a
late
stage
and
saying?
D
A
Well,
on
the
ladder:
yes,
there
is
when
you
publish
your
rfc
you've
published
your
rfc
and
it's
immutable.
Now
you
know
they
can
be
replaced
or
superseded
by
by
subsequent
rfcs,
but
you
know
I
I
I
think
we
probably
don't
want
to
become
like
another
ekma
owning
a
language
for
the
foreseeable
future.
Please
no!
But
you
know
what
I
I
hear.
What
you're
saying
rick.
G
I'm
I'm
agreeing
again
roughly
with
everyone.
I
think
the
tipping
point
with
filters
from
my
implementation
experience
is
when
language
features
such
as
the
name
of
the
type
of
the
property
attribute,
is
string.
Then
you've
sort
of
crept
into
language
implementation.
Detail
when
it's
you
know
is,
is
the
length
of
the
string
less
than
10.
Fine
is
the
value
of
the
property
1.1,
that's
all
great,
but
when
you
start
to
implement
what
looks
an
awful
lot
like
language
implementation
features,
I
think
that's
the
line
in
the
sand
which
we
shouldn't
cross
as
a
working
group.
H
For
instance,
in
the
http
2
work,
we
found
that
things
that
were
supposed
to
be
extension
points
and
be
useful
for
future
modifications
of
the
protocol
were
not
implemented
properly.
So
once
those
things
get
exercised,
these
implementations
break.
So
we
need
to
have
a
plan
for
what
is
must
ignore
and
what
what
is
must
understand.
If,
if
you
see
something
that
you
don't
expect,
just
a
thought.
E
E
If
the
first
specification,
the
first
rfc,
should
already
use
its
own
extension
point
mechanism
and
in
the
itf
we
have
a
pretty
good
way
to
organize
these
extension
points
by
running
ayana
registries
with
designated
experts
that
serve
as
a
gating
function
to
what
what
gets
into
the
extension
point
and
and
what
doesn't
so
one.
One
of
the
interesting
questions
here
will
be
to
to
decide
how
liberal
or
how
conservative
that
that
gating
function
needs
to
be.
E
So
I
don't
want
to
to
anticipate
the
discussion
here,
but
extension
points
are
really
important
and
one
of
the
nice
things
of
having
a
good
extension
point
mechanism
is
that
the
base
mechanism
of
the
language
can
actually
get
pretty
small,
because
you
can
put
lots
of
stuff
into
extension
parts.
We
notice
that
that
in
cddl,
where
all
of
the
new
stuff
we
have
been
doing
in
the
last
one
or
two
years
went
into
the
one
extension
point
we
provided
and
for
for
some
reason
it
just
worked
and
we
consider
ourselves
very
lucky.
E
I
A
comment
back
on
the
adjacent
on
on
the
on
whether
we
can
use
the
type
freely
or,
if
there's
that,
a
implementation
detail.
I
think
we
should
reason
whether
the
well-known
types
defined
in
the
json
standard
itself
are
still
whether
they
do
belong
here,
and
I
think
they
should
so.
We
can
freely
talk
about
what
types
of
the
node
have
in
the
filter,
language.
A
Cool
okay,
I
put
myself
on
the
cube
because
I
actually
wanted
to
say
something
technical
here.
So
when
you
start
talking
about
extension
points,
I
start
to
get
a
little
bit
nervous.
The
you
know
the
classic
example
of
a
standard
with
a
lot
of
extension.
Points
is
sql,
which
has
an
infinite
number
of
extension
points
and
has
zero
interoperability.
So
you
have
to
be
careful
that
an
extension
point
isn't
an
excuse
for
vendors
to
stake
out
land
grabs
and
so
on.
A
So
I
think
what
I'm
hearing
is
that
the
sense
of
the
group
for
the
people,
at
least,
who
are
speaking
up,
is
that
the
filtering
capability
is
seems
to
have
fairly
broad
support.
A
But
but,
as
I
said,
filtering
has
a
strong
support
and
we've
heard
a
couple
of
voices
talk
about
the
importance
of
having
good,
clean
extension
points,
and
I
really
admit
I
don't
know
what
that
means.
But
we
should
record
that
concern
and
and
make
sure
we
address
it
as
we
go
forward.
A
Okay,
this
is
an
important
issue,
so
I
don't
want
to
move
off
it.
Let
me
see
we're
doing
just
fine
for
time,
wow
we're
doing
excellent
for
time.
We
have
a
full
two
hours
here.
No
further
comments
on
scripting
and
filters.
A
Fine,
okay,
next
one,
what
can
we
say
about
the
result
of
evaluating
a
json
path?
Now
the
reason
this
came
up
was
in
the
discussion,
the
early
discussion
we
had
somebody
said
well,
of
course,
everything
that
comes
back
is
by
definition,
an
array,
and
I
went
oh
really
and
so
clearly
the
document
you
reproduce
has
to
be
very
clear
about
the
syntax
of
you
know
what
can
what's
legal
in
a
json
path
and
what
it
means.
A
But
given
this
is
going
to
be
embedded
in
many
programming
languages,
I'm
wondering
what
in
fact
we
can
say
about
what
the
result
of
evaluating
a
json
path
is.
Does
anybody
have
have
strong
opinions
on
that.
A
G
G
Let
me
rephrase
that
ignore
the
json
pointer
comment,
the
if
you're
returning
an
array
of
results,
then
that
array
is
effectively
you're,
creating
an
array
and
returning
it
so
find
me
all
the
items
with
a
a
property
of
red
within
this
large
data
set
and
that
that
will
return
you
an
array
of
the
five
items
that
that
match
your
filter.
G
That
is
a
that
is
a
new
array.
That's
required
a
memory
allocation
and
requires
some
sort
of
maintenance
using
your
your.
If
you've
got
a
garbage
collected
scripted
in
the
scripting
language,
that's
absolutely
fine,
compare
and
contrast
that
with
a
filter
which
will
only
return
you,
the
one
result,
you're
looking
for
and
can
effectively
return,
you
a
pointer
to
an
existing
item
and
requires
no
memory
allocation
as
a
little
better
background.
I
I
work
for
airbus.
G
I
work
in
the
aeronautical
industry
and
bizarrely,
we
actually
use
a
lot
of
these
so-called
scripting
style
languages,
but
we
use
them
in
very
formal
environments
where
we
care
a
lot
about
memory,
allocation
and
a
lot
about
performance,
and
this
applies
to
iot
and
embedded
as
well,
so
having
the
the
the
standard
result
set
from
a
json
path.
Expression
be
something
that
has
to
be
immutable.
A
Interesting
julia.
H
So
thinking
about
what
could
what
program
could
do
with
the
result
of
a
json
path?
Query
isn't
one
obvious
use
case,
something
like
find
these
things
in
my
json
and
once
I
found
them,
I
want
to
delete
them,
so
that
would
mean
that
returning
an
array
containing
copies
of
these
items
will
not
really
be
helpful
right.
H
A
And
the
takeaway
from
that
is
that
there
are
different
ways
to
use
the
result
of
a
json
path
that
are
wildly
different
in
the
requirements
they
would
impose
on
the
on.
Whatever
comes
back,
I
don't
know
what
I
take
from
that,
but
it's
an
observation
that
sounds
true
to
me:
glenn.
D
Yeah,
I'm
sympathetic
to
that
issue
of
memory
allocation
and
one
of
the
implementations
I
worked
on
had
a
essentially
a
dom
of
the
json
file
as
input
and
a
collection
of
pointers
as
output
into
the
dom
and
the
the
reason
for
that
was
so.
We
could
mutate
the
contents
and
then
produce
a
new
document
by
picking
out
particular
points
and
mutating
the
nodes.
D
But
I
think
the
crucial
thing
for
me
is
that
in
the
spec
we
need
to
be
very
clear
what
the
difference
is
between
a
single
node
result
and
an
array
of
length,
one
and
think
in
the
past.
There
have
been
some
ambiguities
there
and
confusions.
A
E
Kirsten
yeah,
so,
basically,
I
think
the
the
abstract
model
should
be
that
we
get
a
json
tree
as
as
input,
and
this
json
tree
has
positions
in
it
which,
which
are
the
various
places
in
the
other
branches
and
the
leaves
and
so
on,
and
then
what
what
a
json
path
spec
gives.
You
is
a
set
of
those
positions
subset
or
essentially,
a
mapping
of
these
positions
to
a
boolean
or,
however,
you
want
to
think
about
it.
E
E
And,
of
course,
there
is
no
natural
representation
for
the
set
of
positions,
for
instance
in
json,
so
stefan's
original
document
talks
about
returning
the
values
at
those
positions
or
returning
output,
parts
that
are
essentially
json
pointers
in
into
the
structure
and
both
are
representations.
But
I
think
we
should
not
think
in
terms
of
those
representations.
We
should
think
in
terms
of
the
concept
of
marking
the
json
tree
with
part
of
the
result
and
not
part
of
the
result,
and
that's
essentially
what
the
json
path
expression
reach.
Ups.
A
I
put
myself
on
the
cue,
so
I'm
going
to
speak
here.
Listening
to
this
makes
me
a
little
bit
pessimistic
about
our
ability
to
specify
the
output,
because
I
I
can
think
of
you
know
so
many
different
needs.
You
know
we
use
this
very,
very
heavily
in
a
couple
of
products
at
aws.
A
You
know
that
we're
running
a
million
events
a
second
through
something-
and
you
know
you
if
you
match
an
event,
then
you
would.
You
could
apply
a
json
path
to
the
event
to
say
what
would
what
the
customer,
what
the,
what
the
receiver
of
the
event
would
see
and
if
you
said
something
like
dollar
dot
a
dot
b,
and
that
was
just
the
number
four.
A
Then
that
meant
that
the
customer
expected
to
get
a
four
and
that's
all
I
expected
to
get,
and
I
think
that's
also
a
perfectly
used
reasonable
use
case,
which
would
be
you
know
it
would
be
unfortunate
if
our
spec
ruled
out
any
of
these
perfectly
reasonable
use
cases.
A
I
I've
just
heard
about
which
bothers
me
a
little
bit,
because
I
it
would
also
be
nice
to
have
you
know
a
level
of
precision
about
what
you
can
expect
to
get
and
to
the
expected
people
who
map
it
into
a
new
programming
language
wouldn't
be
surprised
by
the
mapping
you
get
and
yeah.
I
know
I
don't
know
what
I
think
about
this.
Yet
anyhow,
marco.
I
Just
to
complicate
things
no
further,
if
you
have
like
an
array
of
arrays
at
the
top
level-
and
you
have
one
array
that
contains
only
one
one
such
element-
one
array
when
you
then
select
all
the
all
the
elements
of
the
top
level
array
you
will
get
as
a
result.
One
array
so
is
the
result
like
under
one
array
or
a
singleton
array
that
contains
an
array
or
is
it
the
array?
Is
that
the
top
level
array
you
know
it's?
D
That
was
essentially
a
similar
point.
Really
the
my
mom
went
blank
come
back
to
me.
G
To
rick
this
is
a
discussion
around
return
by
value
or
return
by
reference,
and
there
are
pros
and
cons
to
both.
Of
course,
I
think
carsten
touched
on
the
fact
that
we
we
have
the
mechanisms
for
reference.
It's
it's
jsonpointer,
it
exists.
It
will
give
us
a
reference
back
into
to
the
original
tree.
I
think
this
is
solvable.
I
think
it
just
needs
to
be
covered
and
not
ignored,
so
I'm
not
too
worried,
but
it's
and
I'm
glad
we're
having
this
discussion.
E
Okay,
karsten
yeah
again.
I
think
it's
really
useful
to
be
able
to
separate
the
abstract
concept
of
the
result
of
a
json
path,
expression
and
the
various
forms
in
which
they
they
can
be
returned,
and
I
said
tim
I
think
the
the
example
you
gave
where
you
expect
the
json
path
expression
to
return
exactly
one
position,
and
they
are
actually
interested
in
the
value
from
that.
That
is
indeed
a
very
common
use
case
and-
and
we
definitely
should
make
sure
that
gets
some
attention
for
a
json
path.
Processor.
E
So
do
you
do
you
want
to
get
a
set
of
nodes
back,
or
do
you
want
to
get
a
single
node
back,
so
it
essentially
becomes
an
exception
if
if
there
is
more
than
one
node
or
even
an
exception,
if
there
is
only
only
zero
nodes
being
returned
so
that
that's
one
of
the
the
little
problems
that
I
have
with
jsonpath,
where
I
don't
know
whether
we
are
going
to
to
solve
that,
but
I
think
the
the
model,
the
high
level
model
should
be
flexible
enough
to
actually
address
these
different
use.
Cases.
D
Remember
what
I
was
going
to
say
the
I'm
sympathetic
to
the
idea
of
an
abstract
model-
and
you
know
the
idea
of
just
coloring
a
tree
to
say
which
nodes
were
selected
is
great.
But
looking
at
the
consensus
of
current
implementations,
you
know
that
excellent
project
that
was
done
by
someone
else,
which
covers
30,
odd
implementations,
that
there
is
often
duplication
in
the
outputs
and
and
questions
about
the
ordering.
D
F
I
The
biggest
problem
here
is
the
distinction
between
reference
between
and
and
copies
and
the
the
the
the
allocation
comes
from
from
the
the
allocation
problems
comes
from
the
the
selection
problem,
so
the
the
the
arity
of
the
results
is
is
what
I
think
is
one
thing
matters
most
here
is:
do
we
want
to
force
multiple
iot,
or
do
we
want
to
to
somehow
automatically
detect
the
one
versus
the
multipolarity,
or
do
we
want
to
let
the
user
select
in
the
syntax,
whether
you
expect
one
result
or
multiple.
G
G
So
as
an
implementer
I
can
say
I
don't
care
about
these
by
values,
because
in
my
environment
it's
not
important,
I
will
return
via
ref
and
we
can
specify
by
reference
means
return
adjacent
pointer
as
in
rfc.
I
can't
remember
the
number,
but
it's
specified,
so
I
think
that
gives
us
the
flexibility
without
having
to
have
different
expression,
forms
or
different
search
path,
criteria,
etc.
A
A
G
References
back
or
values-
I
I'm
not
sure
I
go
as
far
as
an
api
because
we
we
step
into
well
what's
the
binding
for
my
favorite
language,
but
I
think
some
elegant
way
of
saying
an
implementation
may
provide
a
mechanism
to
return
by
value,
and
here
are
the
considerations
that
need
to
be
applied
or
a
mechanism
that
should
return
by
reference
and
when
we
say
reference
we
mean
json
pointer,
which
would
be
my
proposal
and
the
following
things
apply
and
you
could
have
another
section
which
differentiates
between
find
me
the
first
and
find
me
all
with
relevant
considerations,
but
don't
say
and
here's
how
you
do
it
in
rust
and
here's
how
you
do
it
in
insert
favorite
language
here.
G
Right,
I
would
go
for
normative
to
say:
look.
The
working
group
has
has
realized
that
there
are
use
cases
where
you
want
one
item
and
you
can
stop
the
search
as
soon
as
you
hit
one
item,
but
there
are
also
use
cases
where
you
want
all,
and
there
are
an
implementation
may
realize
that
there
are
performance,
implications,
etc,
associated
with
finding
first
and
finding
all.
So
this
is
or
should
it
be
normative?
I
I
don't
know,
but
it
should
definitely
be
strong
guidance
for
implementers
to
say
really.
G
You
should
implement
this
twice
and
if
and
if
this,
if
the
output
of
the
working
group
is
picked
up
by
ecma
or
or
the
java,
standardization
guys
or
whatever,
and
they
say
well
yeah
we're
going
to
have
this
in
our
next
version
of
our
language,
then
this
guidance
can
apply
to
them
to
say
you
need.
G
C
E
Yeah,
I
just
wanted
to
point
out
you.
You
said
fine
first
and
of
course,
another
interesting
case
is
to
find
any
which
is
different
from
trying
first,
that
you
don't
get
to
guarantee
that
it's
actually
the
first
so
yeah.
I
think
right
in.
G
E
Yeah,
so
I
think
the
if
the
mental
model
is
this,
this
model
that
we
didn't
call
marking
the
tree,
then
we
can
derive
those
various
api
variants
from
that
model
easily.
Yes,
absolutely.
G
E
Get
a
really
nice
separation
of
concern.
We
have
one
mental
model
that
that
governs
jsonpath
and
we
we
have
the
ability
to
specify
a
few
apis
or
abstract
apis
that
we
might
want
to
see.
But,
of
course,
that
not
everybody
has
to
implement
all
of
them.
G
B
A
G
Anymore,
they
said
they
had
chat
problems
which
was
the
cause
of
the
reboot,
so
the
chat
might
be
running
behind
well,.
A
A
A
A
But
there
is
certainly
scope
for
us
to
write
strong
guidance
into
the
document
for
implementers
about
the
kinds
of
requirements
they
should
be
prepared
to
to
to
solve.
G
Rick
go
ahead,
so
one
last
thought
on
this
subject.
I
think
it
may
be
worth
in
the
actual
json
path
specification
enumerating
these
different
methods
of
of
of
of
acquiring
a
result,
the
reason
being
I'm
doing
a
fair
amount
of
heavy
lifting,
with
jason
schemer
at
the
moment,
and
jason
schemer
uses
jason
pointer
as
part
of
its
structure.
So
a
certain
part
of
a
schema
is
defined,
as
this
is
a
json
pointer
to
somewhere
else.
D
And
there
was
discussion
about
whether
to
call
one
of
the
apis
find
first
or
find
any.
I
think
that
raises
a
really
important
point,
which
is
what's
our
attitude
to
non-determinism
in
the
spec
I
see.
Non-Determinism
has
been
a
a
strength
because
it
gives
you
freedom
to
implement
in
a
more
efficient
way
or
a
different
way.
Some
people
think
non-determinism
in
a
spec
is
a
weakness
and
it's
something
to
be
avoided
at
all
across.
So
I
just
want
to
raise
that
in
case.
Anybody
has
strong
feelings
about
that.
Apart
from.
D
A
It's
that
is
definitely
a
tricky
point
and
I
don't
know
what
I
think
marco.
I
I
I
have
some
strong
feelings
against
using
json
path
as
a
way
to
point
to
things
just
because
other
some,
some
other
standards
of
pointers,
are
too
weak
to
actually
find
their
ways
through
a
document
that
has
a
a
complex
schema
in
in
particular
json
pointer,
doesn't
have
the
ability
to
to
find
things
through
arrays
I
mean
other
than
using
using
positions,
and
so
I
seen
people
drawn
to
jason
path
precisely
for
that
reason
for
the
the
expressiveness
of
json
path,
but
I
don't
think
you
can
you
can
ensure,
with
jason,
pat
that
you
are
actually
you
know
pointing
to
one
thing
you
know
rather
to
than
getting
you
know
just
you
know
too
much
things
unexpectedly,.
A
So
I
guess
all
that
I
can
say
on
this-
is
that
our
discussion
on
this
is
going
to
be
aided
by
the
introduction
of
lots
of
use
cases.
So
fortunately,
jsonpath
is
in
the
field
has
been
there
for
a
while
it's
heavily
used,
I
speaking
only
for
myself,
I'm
going
to
have
a
much
easier
time,
understanding
these
kinds
of
propositions
saying.
Well
suppose
I
have
this
data
and
this
json
path
in
this
scenario.
Here's
what
I
want
to
happen.
A
How
do
we
you
know?
How
should
I
not
want
to
not
happen?
I
think
that's
going
to
get
us
to
to
consensus
faster
marco
you're.
Still
at
the
head
of
the
queue
are
you
we
want
to
say
some
more.
A
A
A
Okay,
at
this
point,
we
have
run
through
our
agenda
and
any
other
business
things
that
we
forgot
to
discuss
things
that
I
foolishly
suppressed,
because
I
thought
we'd
be
short
on
time,
but
we're
not
karsten.
E
Yeah,
I
think
it
may
be
a
bit
early
to
ask
this
question,
but
early
is
the
the
operative
word
here.
We
probably
need
to
develop
an
understanding
of
the
timelines
we
are
operating
on
here.
It's
really
hard
to
estimate
the
amount
of
work
that
goes
into
such
a
specification
effort,
but,
on
the
other
hand,
yeah.
If
we
don't
do
any
planning
at
all,
then
it's
going
to
be
even
more
chaotic.
E
E
Have
it
with
them,
and
I
think
the
the
the
next
milestone
for
me
is
actually
spending
time
on
on
getting
these
merged
drafts,
or
this
merge
draft
out
there,
and
I
probably
also
could
write
some
text
on
this
abstract
model
that
we
talked
about
so
that
that
might
be
going
on
independently
or
might
go
into
the
smudge
draft,
depending
on
on
what
the
timelines
on
of
either
thing
is,
and
the
other
thing,
of
course,
is
to
get
people's
favorite
examples.
E
There
are
lots
of
examples
in
the
that
other
project
that
has
been
mentioned,
but
maybe
people
still
have
examples
from
their
practical
work
that
they
are
very
interested
in
getting
right.
A
In
terms
of
dates,
I
I
just
looked
at
our
charter
and
it
has
no
dates
in
it.
I
thought
it
did.
I'm
surprised
I
could
have
sworn
I
said.
B
Tim
tim,
it
was
my
understanding
that
that
there
was
a
placeholder
milestone
for
iesg
submission
for
mid
next
year.
I
I
would,
I
would
like
to
propose
if,
if,
if
the
the
various
people
who
are
interested
in
editing,
this
have
have
the
time
and
the
brainpower
to
do
it.
B
If
we
could
aim
between
sort
of
now
and
the
next
ietf
meeting
in
late
march
to
to
have
sort
of
a
you
know
the
the
merged
document,
as
as
it
were,
of
of
the
existing
personal
drafts
that
are
out
there
and
to
have
an
os,
an
oo
draft
out
there,
and
so
that
when
we
come
around
to
the
next
meeting
in
the
end
of
march,
you
know
we
should
be
fully
into
the
into
the
motions
of
of
working
through
a
lot
of
the
issues
that
we
have
discussed
today.
B
I
think
that
that
would
be
a
fairly
fairly
achievable
goal.
I'd
be
interested
to
know
what
the
what
what
the
rest
of
the
working
group
thinks.
A
Yeah,
I
see
glenn's
at
the
top
of
the
roof,
but
I
also
see
murray
our
a.d
there
and
I
think
his
opinion
is
highly
relevant
to
this.
J
Yes,
murray,
would
you
like
to
go
ahead?
Please
yeah!
I
I
you
just
have
the
one
milestone
for
june
next
year,
which
is
the
standards
track
document
defining
json
path,
but
that's
that
can
be
renegotiated.
So
there
is
one
there,
but
it's
not
set
in
stone.
So
tell
me
what
else
you're
thinking
of
I'm
listening.
A
Just
glenn,
I
haven't
forgotten
about
you,
but
I
I
believe
I
heard
if
I
understood
what
james
was
proposing
was
he's
proposing
that
we
have
a
working
group
draft
with
consensus
with
consensus.
Backing
of
the
working
group,
which
nonetheless
is,
is
not
complete
by
the
next
ietf,
which
is
march.
A
You
said
yeah
and,
and
my
opinion
is
that
the
smart
way
to
do
this
is
going
to
start
with
a
very,
very
small
draft
and
build
it
out,
because
I
mean
there
are
certain
aspects
of
jsonpath
that
are
not
controversial
at
all
I
mean
dollar.a.b,
you
know,
and
dollar
square
brackets.
Three,
you
know
kind
of
thing
are
are
not
controversial
and
if
we
had
something
with
a
really
good
job
of
capturing
that
and
even
in
that
there's
a
few
corner
cases
and
so
on.
A
If
we
could
get
to
that
by
march,
I
think
that
would
be
pretty
good.
Other
opinions,
glenn
back
to
you,
sorry,
for
interrupting.
D
Well
before
I
make
my
point
I
was
going
to
make,
I
would
say
that
the
draft
I've
been
working
on
is:
is
that
form
it's
the
non-controversial
subset
and
it
tries
to
cover
the
corner
cases,
so
you
know,
let's
have
a
look
at
that
as
a
working
group.
What
I
was
going
to
mention
was
the
json
jsonpath
comparison
project.
D
That's
been
done.
I
mentioned
30
odd
implementations
that
are
covered
just
wondered
about
you
know
since
we're
talking
in
real
time.
It
might
be
good
to
discuss
people's
attitudes
to
existing
implementations
and
how
we
see
migration
to
the
eventual
standard
going.
You
know
how
disruptive
do
we
want
to
be?
How
accommodating
do
we
want
to
be?
D
A
Yeah
I
put
myself
on
the
list
because
I
I
on
this
one,
so
you
know
at
aws
we
built
a
a
a
couple
of
large
complex.
You
know
vast
numbers
of
users,
vast
number
amounts
of
data
services,
and
we
didn't
even
realize
what
we
were
doing.
We
just
built
them
with
j-way
and
so
the
semantics.
You
know
the
language
we
we
actually
de
facto
supported
with
whatever
j-way
did,
and
that
was
a
little
unfortunate
and
realistically
the
chance
that
that
we
would.
A
You
know
that
that
product
will
ever
adopt
a
new
json
path.
Syntax,
it's
inconsistent
with
something
that
joey
does
today
is
effectively
zero,
because
there's
literally
hundreds
of
thousands
of
people
just
using
it.
So
my
take
away
from
that
is
we
should.
You
know,
try
to
minimize
that,
but
let's
let's
face
facts
and
realize
that
what
we're
building
is
probably,
for
you
know
future
implementers
and
future
adopters
of
jsonpath,
because
existing
adopters,
mostly
just
aren't
going
to
change
karsten.
E
Yeah,
I
think
in
in
the
end,
there
are
costs
to
to
any
decision
and
there
are
costs
in
making
the
wrong
decision
as
well.
So
when
we
do
something
that
is
not
supported
by
the
majority
of
the
implementations,
then
we
have
the
cost
of
causing
them
pain
or
losing
them
and
so
on.
When
we
make
a
decision
that
actually
is
well
bad,
we
cause
cost
for
for
future
users
of
the
specification
and
we
have
to
balance
these
two
costs.
E
E
Just
we
want
to
drag
a
specific
implementation
along.
That's
also
wrong,
so
I
don't
think
this
can
be
discussed
in
the
absolutes.
It
will
depend
on
every
single
case
whether
we
go
for
documenting
existing
practice
or
maybe
cleaning
up
things
a
little
bit
and
so
far
I
think
I've
heard
from
most
people
that
there
probably
needs
to
be
a
really
good
reason
to
go
for
cleaning
up
things,
but
I
would
be
unhappy
if
we
cannot
do
that
at
all.
J
Marie
just
wanted
to
mention
that
the
charter
actually
talked
about
this.
We
anticipated
this
coming
up
and
it
talks
about
how
you
might
break
ties
or
try
to
accommodate
the
consensus
of
the
common
implementations
and
that
sort.
So
just
you
might
want
to
review
that.
We
can
always
tweak
this
too
if
it
needs
additional
guidance,
but
it
seems
like
we
did
think
about
this.
A
little
bit
already.
A
Yeah
I'm
just
going
to
read
from
the
charter.
It
says
the
working
group
will
discover
will
develop
a
standards
tracks,
jsonpath
specification
that
is
technically
sound
and
complete,
based
on
the
common
semantics
and
other
aspects
of
existing
implementations.
Where
there
are
differences,
the
working
group
will
analyze
those
differences
and
make
choices
that
rough
consensus
considers
technically
best
with
an
aim
towards
minimizing
disruption.
A
So,
to
get
back
to
where
glenn
launched
us
about
you
know,
target
dates.
I've
heard
the
proposal
of
of
the
next
ietf
for
a
working
group
draft
with
with
consensus
backing
that
will
probably
not
be
complete,
but
will
be
correct
for
this
episode.
It
covers.
B
Just
as
a
just
as
a
housekeeping
thing,
what
we
can
do
is
now
that
we
have
our
github
organization
created.
Thank
you
very
much
carsten.
We
can
create
the
repositories
and
and
and
the
necessary
boilerplate,
so
the
editors
can
just
get
on
with
with
the
editing
part,
and
I
can
disseminate
information
about
that
later
today.
D
Glenn
yeah,
before
all
this
started,
I
picked
on
a
github
org
name,
which
is
probably
unfortunate,
now
jason
path
standard
just
as
a
place
in
the
sand,
so
I'll,
probably
ditch
that
and
move
somewhere
else
for
the
reference,
implementation
and
cts,
because
that's
you
know,
may
end
up
being
entirely
informal,
but
there's
also
a
slack
instance.
I'll,
probably
kill
that
as
well,
because
it's
not
going
to
be
archived.
D
It's
not
appropriate,
so
just
wanted
to
mention
that
I'll
be
kind
of
killing
off
those
things
so
that
we
centralize
on
the
official
organization
and
mailing
list.
A
Right,
there's
actually
a
procedural
thing:
is
it
appropriate
to
do
the
compliance
test?
If,
in
fact,
we
decide
it's,
not
an
official
output
in
that
organization?
I
don't
know
I'm
gonna,
I'm
gonna
ask
around
you
know
julian
will
have
experience
what
they
did
on
the
structured
headers,
so
you're,
probably
correct
glenn
that
that
that
that's
probably
not
the
right
place
to
do
it
with
the
under
that
name.
But
but
let's
not
there's
no
hurry.
Let's
make
sure
we
get
this
right.
A
A
We
can't
hear
you
julian,
and
we
don't
have
any
chat
that
I
can
see.
Does
it
work
now?
Oh
there
you.
H
Are
okay,
complicated
interface,
sorry
for
structured
headers?
It
actually
is
a
mark,
nottingham's
private
repository,
so
we
I
think,
on
the
working
group
materials
page.
We
have
a
link
to
that
test,
suite
or
test
cases
pointing
out.
That
is
not
a
working
group
work
item,
but
it's
relevant
anyway.
H
A
Sure,
murray
I'll
talk
we'll
talk
to
murray
about
this
and
see
you
know
what
the
what
the
feeling
is
about
this
kind
of
thing.
I'm
you
know
I'm
a
cheerleader.
I
I
think
that
that
that
specs
that
have
supporting
software
are
are
winners,
but
let's
see
what
the
community
feel
feels
about
this
kind
of
there.
A
E
D
You'd
like
to
ask
a
question:
actually
sorry,
I'm
not
on
the
queue
none
of
that.
A
D
A
Well,
working
groups
are
different.
There
are
some
working
groups
that
have
lots
and
lots
and
lots
of
interim
meetings
and
address
these
things,
others.
Firstly,
you
know
the
only
time
they
meet
at
all
is
at
itf
meetings,
and
there
are
you
know,
chair
calls,
consensus
periodically
and
drafts
are
produced.
Karsten.
E
Yeah,
so
I
think
it's
a
good
idea
to
be
very
adaptive
in
that,
so
that
there
is
no
one
right
answer
in
several
work
moves
that
I'm
involved
in.
E
We
do
have
periods
of
quick
progress
where
we
have
about
bi-weekly
meetings
and
we
try
to
time-box
them
into
one
hour.
So
it's
not
it's
not
becoming
epic,
but
we
can
actually
use
face
to
face
time,
but
your
face
to
facetime
to
to
get
progress,
and
we
also
have
which
is
very
important
milestones
to
which
people
have
to
have
their
preparations
in
place.
But
even
those
groups
who
have
these
bi-weekly
periods
also
have
silent
periods.
E
A
And
on
the
other
extreme
I've
been
a
member
of
one
working
group
where
it
was
all
done
between
between
a
couple
of
iatfs,
and
I
don't
think
there
was
ever
a
face-to-face.
Everything
was
just
done
on
the
mailing
list
and
with
consensus
calls
so
so
we'll
we'll
be
flexible.
I
I
don't
think
any
of
us
are
religious
about
how
to
do
it.
We'll
we'll
talk
about
it,
and
you
know.
I
obviously
I
think
james
and
I
would
agree
that
if
people
feel
the
need
for
such
a
thing
feel
free
to
say
so,.
E
Then,
of
course,
we
might
have
something
like
design
team
meetings
or
editors
meetings.
Things
like
that.
So
when
we
are
trying
to
make
progress
on
things
where
we
already
have
direction
from
the
working
group,
but
simply
have
to
do
medial
work
to
get
that
reflected
in
in
the
document.
So
I
think
that
that
will
also
happen
because
in
the
end
we
will
need
to
have
a
document
that
is
good.
D
Glenn,
sorry,
it's
me
again
but
taking
the
opportunity,
while
we're
face
to
face
what's
the
process
for
kind
of
drafting
and
and
reflecting
consensus
into
a
draft,
because
the
approach
I've
taken
so
far
has
been
to
for
the
draft
to
kind
of
lead
the
process
and
put
up
a
pr
and
then
invite
people
involved
to
comment
on
the
pr
and
then
merge.
That
is
this.
Some
other
approach
that
we
anticipate
where
we
kind
of
discuss
an
area
on
the
mailing
list
and
elsewhere
and
then
edit.
It
into
shame.
A
E
A
E
And
that
works
well
before
you,
you
dive
into
other
bureaucracies
and
so
on.
In
a
smaller
group,
it's
sometimes
also
a
good
idea
to
have
leading
documents,
so
you
are
not
waiting
for
consensus
to
form,
but
people
are
actually
writing
up
things
that
can
be
in
a
pull
request
or
it
can
be
in
the
main
document
that
depends
on
the
style
of
editing
things.
E
It
depends
a
bit
on
how
many
of
these
things
are
going
on
in
parallel,
which
one
works
better,
but
it's
much
easier
to
get
consensus
on
something
that
already
is
in
the
document,
because
you
are
not
not
discussing
it
on
a
theoretical
level.
You
have
actually
text
to
to
look
at
and
you
can
make
pull
requests
to
the
the
changes
and
improve
it
before
there
is
actually
a
consensus,
so
yeah
good.
A
So
I
agree
with
what
carson
said.
You
know,
that's
what
I
was
saying
as
well.
Sometimes
the
best
way
to
argue
for
a
particular
change
is
to
make
the
change
you
know
put
in
a
pr
saying.
Yes,
I
want.
It
also
depends
on
whether
we're
arguing
about
the
best
way
to
express
a
shared
understanding
or
the
situation
which
you
know
regularly
arises.
There's
actually
a
disagreement
in
principle
about
what
needs
to
be
done
and
then
there's
usually
a
lot
more
work
that
has
to
go
into
discussing
and
then
making
an
official
consensus
call
glenn.
D
A
Well,
de
facto,
the
people
who
have
more
time
and
resources
to
put
in
tend
to
you
know,
do
a
lot
of
driving,
but
the,
but
the
mechanism
in
in
is
is
that
the
chairs
are
supposed
to
steer
the
discussions
and
and
make
the
consensus.
D
Calls
passive
to
me:
it's
like
there
is
a
discussion
going
on
and
the
chair
derives
consensus
and
oversees
it
just
wondering
you
know
you
know,
for
those
of
us
in
the
frame
to
potentially
be
an
editor.
I'm
just
wondering
how
much
we're
taking
on
by
agreeing
to
do
that.
A
Well,
but
you
know,
when
you
become
the
editor,
the
the
change
control
is
belongs
to
the
working
group
and
the
working
group
you
know
expresses
it
by
debating
and
then
by
eventually
by
consensus,
calls
in
the
happy
case
where
you
know
there's
a
shared
vision
of
exactly
what
we're
trying
to
build.
You
know,
then,
everybody
pitches
in
to
get
to
the
best
language,
the
real.
In
my
experience,
the
real
difficulties
arise
when
there's
genuine
disagreement
on
what
the
shape
we're
trying
to
build
is.
A
But
aside
from
that,
I
have
not
had
ex
you
know
had
a
lot
of
difficulty
with
the
experience.
It
seems
to
work
reasonably
well.
C
B
And
it's
probably
worth
clarifying
that
it
based
on
how
we're
how
we've
been
discussing
things
in
this
in
our
first
meeting,
I
think
that
we'll
be
able
to
come
to
consensus
on
a
lot
of
the
topics
quite
easily
and
where
we
don't
have
that
consensus.
I
think
that's
that's
the
job
for
tim
and
myself
to
try
and
work
through
the
subject
with
the
working
group
to
try
and
figure
out
some
sort
of
outcome
to.
E
That
yeah,
what
what
timber
said?
It's
of
course
right,
but
it's
only
true
once
the
working
draft
has
been
adopted
so
right
now
there
are
two
individual
drafts
and
of
course
we
can
just
go
ahead
and
change
them
as
much
as
you
want,
which
will
in
turn,
influence
the
probability
that
part
of
the
text
turns
up
in
a
working
group
draft
so
in
larger
working
groups
that
have
more
than
one
draft
to
look
at.
E
It's
sometimes
better
not
to
do
the
work
adoption
too
early,
because
as
long
as
drafts
are
individual
draft,
the
owners
of
those
drafts
can
charge
ahead
and
fix
things
without
waiting
for
for
a
lot
of
cycles
through
the
working
group.
So
I'm
not
sure
we
are
in
this
situation
here,
but
as
a
general
statement,
I
wanted
to
point
out
that
adoption
actually
completely
changes
the
dynamics
of
how
a
document
is
being
processed.
D
A
Consensus
you
know,
based
on
the
discussion
we've
had
today,
I'm
I
I
agree.
Whoever
was
said.
I'm
I'm
not
too
worried.
I
think
we'll
probably
be
relatively
straightforward
for
us
to
build
consensus
and
that's
helped
by
the
fact
that
we're
not
inventing
anything
right,
I
mean
jason
path-
exists,
large
parts
of
it
have
you
know
everybody
agrees,
what
it
means
and
and
getting
that
just
written
down.
The
shared
understanding
in
a
clean,
comprehensible
way
is
is,
is
is
non-trivial.
A
I
think
it's
worth
working
on
and
I
wouldn't
expect
a
lot
of
disagreements
along
the
way,
but
I
also
agree
with
what
carson
said
you
know:
there's
there's
a
lot
of
value
in
individual
drafts,
but
once
again
I
I.
I
really
am
optimistic
that
we
can
get
to
shared
consensus,
incomplete
draft
by
by
march.
B
Is
it
then
worth
us
just
just
to
be
explicit
and
clear?
Is
it
worth
us
just
saying
that
what
we,
what
we
could
do
is
is
adopt
lindstraft
as
it
stands,
with
the
full
anticipation
that
we
would
be
merging
in
the
works
from
other
other
documents.
B
The
the
other
draft,
as
well
as
any
any
other
contributions
as
the
starting
point
for
the
working
group
document
is
anybody
have
any
particular
thoughts
about.
H
Can
you
hear
me?
Yes,
yes,
hey!
I
I
just
wanted
to
know,
that's
typically
something
that
you
will
call
for
consensus
on
either
on
the
mailing
list,
or
I
think
this
meet
echo
thing
has
a
show
of
hands
tool
that
we
could
use,
which
would
replace
the
hum
that
we
are
doing
in
actual
itf
meetings.
H
B
I
I'm
I'm
happy
to
do
that
as
in
the
medical
now,
if,
if,
if
that's
the
easiest
way
to
get
to
a
conclusion
on
this.
H
And
that
said,
the
show
of
hands
or
the
hum
in
a
working
group
meeting
is
taken
as
input
for
the
consensus
finding.
But
it
would
still
need
to
be
confirmed
on
the
mailing
list.
So
for
those
for
those
who
are
unable
to
show
up
at
the
virtual
meeting
or
the
actual
meeting.
A
Yeah,
I'm
a
little
bit
nervous.
You
know
simply
because
of
the
distributed
nature
of
this
of
this
meeting,
and
I'm
really
pleased
by
the
number
of
people
who
showed
up
here,
which
is
much
greater
than
I
expected.
But
you
know
it
is,
after
all,
a
an
odd
time
for
a
lot
of
people
and
I'd
be
maybe
a
little
nervous
about
adopting,
based
on
on
on,
at
the
basis
of
a
virtual
show
of
hands
here
without
at
least
taking
it
to
the
mailing
list.
Sure,
let's
take
it
to
the
list.
G
As
a
chair
of
a
couple
of
other
groups,
it's
really
best
practice
to
to
handle
adoptions
on
the
mailing
list
by
all
means.
Ask
during
a
session
that's
great,
but
the
decision
should
be
on
the
mailing
list
really
for
for
completeness.
D
A
Fair
enough
glenn's
raised
the
point:
does
anybody
have
any
specific
objections
kirsten.
E
In
larger
groups,
it's
often
a
good
idea
to
do
adoption
with
questions
in
the
working
group
meeting,
because
we
need
to
find
out
who's
actually
going
to
work
on
the
document,
who's
going
to
write
code,
who's,
going
to
review
the
document
and
so
on.
So
all
of
that
doesn't
occur
here.
We
we
are
all
here
in
this
virtual
room
right
now,
because
we
care
about
this
effort.
So
that's
the
part
we
just
don't
need
to
do
and
the
other
part
actually
works
better
on
the
meetings.
E
A
Well,
I
don't
see
any
reason
not
to
do
a
show
of
hands,
so
the
specific
proposal,
if
I
understand
it,
is
that
the
working
group
adopts
the
current
state
of
the
glenn
marco
and
somebody
else.
I
forget
the
name
draft
and
let
me
see,
let
me
use
the
show
of
hands
meeting,
so
I'm
going
to
try
and
do
this
so.
A
Let
the
working
group
adopt
the
current
state
of
the
gwen
at
I'll
draft
as
a
draft
okay.
So
I've
started
that
and.
A
If
you
do,
people
know
how
to
do
this,
there's
a
little
graph
bar
graph
thing.
Just
under
your
your
name.
You
click
on
that.
A
A
H
So,
just
to
repeat
what,
in
the
spirit
of
what
cast
and
said,
I
did
not
raise
my
hands,
but
that's
for
the
only
reason,
because
I
haven't
looked
at
the
draft,
so
I
need
more
time
would
be
the
answer
so
ask
on
the
name
of
this
and
give
a
few
days.
A
To
be
honest,
I
have
the
same
situation.
I
did
read
the
draft,
but
that
was
a
while
ago
and
frankly,
I
don't
have
a
strong
opinion,
so
I'm
just
not
my
hand
is
not
raised
at
the
moment.
K
K
A
Okay,
fair
enough,
but
de
facto
there
is
a
real
difference
between
clinton.
Do
not
raise
your
hand
and
not
clicking
anything
at
all.
A
Okay,
so
at
this
point
I'm
seeing
three
hands
raised
six
explicitly
not
raised
out
of
22s.
That's
probably
less
than
half
the
people.
J
Normally,
when
we
take
homes,
you
would
ask
both
questions,
so
you
would
say:
does
anybody
want
this
hum
now
and
then
you
would
say:
does
anybody
object
to
this
hum
now
sort
of
thing?
So
you
might
ask
the
question
twice
just
to
eliminate
that.
But
this
is
that's
not
a
major
point.
I
don't
think
since
you're
planning
to
take
this
to
the
list
anyway,
yeah.
A
No,
this
is
useful
input,
so
it
shows
us
that
a
lot
of
people
haven't
made
up
their
minds
that
there
are
people
who
are
nervous
about
doing
it.
And,
let's,
let's
take
this
idea
to
the
list-
and
it
also
may
help
for
james
and
I
to
do
our
jobs
and
and
and
make
decisions
about
editorial
roles
and
things
like
that
too,
to
help
yeah
that
move
along.
A
A
Well
with
that,
I'm
going
to
say
thank
you
one
once
again
good
morning,
good
afternoon
and
good
evening.
Thank
you
for
coming
out.
I'm
I'm!
I'm
really
pleased
with
the
it
seems
like
we
have,
broadly
speaking,
a
shared
understanding
of
what
it
is,
we're
trying
to
do
here
and
a
good
understanding
of
the
problem.
So
I'm
super
optimistic
that
we
are
going
to
get
a
good
result.
So,
thank
you,
everybody
james.
Any
closing
remarks.
B
No,
I
think
you've
done
a
good
job
covering
it.
Thank
you,
everyone
for,
for
your
time
and
participation.