►
From YouTube: IETF108 DISPATCH 20200727 1100
Description
DISPATCH session at IETF108
2020/07/27 1100
A
Thanks
so
we
should
go
ahead
and
get
started.
I
see
some
people
in
queue
already,
so
I'm
going
to
see
if
I
can
pick
up
well.
Actually
I
think
I'm
going
to
run
the
slides
and
mc
this
morning
and
patrick
is
going
to
be
managing
the
queue.
So
I
do
see
some
people
in
cued,
patrick,
let's
see
if
they
need
to
actually
speak.
B
B
A
C
A
A
A
Please
add
yourself
to
the
queue.
If
you
need
to
speak,
even
though
you're
in
the
queue
and
we're
in
meet
echo
and
everyone
can
see
each
other's
name,
please
say
your
name
before
speaking,
because
this
is
recorded
and
there
it
will
be
a
separate
audio
stream
where
people
won't
have
all
the
metadata.
A
Since
we
are
fully
virtual,
I
expect
there
will
be
some
side
discussions
that
pop
up
over
there
and
that's
perfectly
fine,
but
please
remember
if
you're
having
interesting
substantive
discussions
in
jabber
that
are
relevant
to
what's
going
on
in
the
room
audio.
Please
consider
taking
important
points
to
the
queue
you
don't
have
to
worry
about
blue
sheets
that
are
magic.
This
time,
blue
chips
will
be
taken
from
our
roster.
A
A
A
And
this
is
our
agenda
for
the
day,
all
of
our
actual
topic.
Discussions
are
going
to
be
in
dispatch.
We're
going
to
cover
ted's
rfc
3405
update
a
proposed
working
group
on
http
api
building
blocks,
a
json
path
draft
and
a
secure
frames
draft.
Is
there
anything
that
needs
to
be
on
this
agenda?
That's
not
or
any
other
agenda
matching.
A
A
And
we
often
have
some
confusion
about
the
fact
we
have
a
separate
dispatch,
mailing
list
and
art
mailing
list,
so
we
like
to
remind
people,
the
the
art
mailing
list
and
the
art
part
of
our
meeting
is
for
discussion
of
general
art
topics
that
might
be
of
interest.
So,
if
you're
working
on
something,
you
think
other
people
might
be
interested,
you
want
to
check.
That's
the
place
to
go.
A
A
So
as
we
go
through
these,
I
would
like
people
to
keep
in
mind
one
whether
this
is
work.
We
think
the
ietf
needs
to
do
and
two
what's
the
proper
venue
for
doing
that,
work
and
it
certainly
makes
sense
to
have
clarification
discussions
on
the
technical
aspects
of
a
of
a
proposal,
but
we
don't
want
to
dive
too
deeply
into
trying
to
fix
all
the
technical
aspects
right
now.
So
what
I
would
recommend
is
people
think
about
clarifying
questions
and
then
think
about
the
question
about
how
should
we
proceed
with
this
work?
A
D
D
D
D
D
D
A
F
F
B
F
I
I
I
probably
don't
have
more
to
say
about
this.
I
I
don't
have
any
strong
opinions
about
words
to
be
discussed.
I'm
just
worried
about
allocation
resources
to
a
to
a
protocol
which
is
not
in
use
and
and
consequently
the
registrations
in
which
are
are
likely
to
be
vanity
things.
We
don't
care
about,
or
we
shouldn't
clutter
up
registries
or
dns
tree
about,
but.
G
Next,
okay,
thank
you.
This
is
barry
lieber
a.d,
I'd
like
to
hear
from
the
people
who
think
we
should
not
handle
it
as
a
simple
administrative
registration
document
in
the
dispatch
working
group
itself
and
wanted
a.d
sponsored
why?
What
is
why
do
you
object
to
having
it
handled
by
the
dispatch
working
group.
B
B
H
Actually
sending
audio
and
video
at
this
point
it
looks
like
I
am.
How
am
I
exciting
the
is
so
I
I
I
was
actually
going
to
suggest
that
in
the
in
dispatch
working
group
is
administratively
was
fine,
but
I
think
80
sponsored
is
fine
as
well.
It
gives
the
id
a
little
bit
more
coverage
and
given
there's
likely
to
be
appeals
around
this
having
a
working
group
consensus
around,
it
might
be
a
slight
advantage.
G
This
is
a
little
more
than
that
so
because
it
is
changing
rules
for
registration.
So
it's
there's
a
debate
about
that.
There's
already
an
appeal
on
this,
so
we
we
should
consider
whether
having
the
working
group
consensus
is
useful,
given
that
somebody
is
upset
about
the
situation
or
whether
the
working
group
doesn't
want
to
touch
it,
which
I
would
appreciate
as
well.
So
I'm
willing
to
do
it
either
way.
I'm
just
trying
to
push
on
why
white
people
don't
want
the
working
group
to
handle
it.
That's
all.
B
I
will
note
this
is
patrick,
I
mean
I
will
note
that
the
amount
of
last
call
time
would
probably
be
similar
through
either
path.
We
discussed,
probably
a
you
know,
an
anticipated
four
week
last
call
if
this
was
to
be
handed
handled.
You
know
by
an
a.d
path,
and
you
know
two
weeks
of
working
group
last
call
plus
two
weeks
by
atf
last
call
forward.
It
happened
through
the
working
group.
My
concern
about
the
working
group
is
the
you
know.
B
The
fundamental
purpose
of
the
working
group
is
to
dispatch
work
to
other
places
and
that
we
might
not
have
the
the
critical
mass
of
people
who
are
expecting
to
process
documents
within
our
group
and
therefore
you
know
some
concern
about
whether
or
not
those
two
weeks
of
last
call
within
the
group
are
really
accomplishing
anything
they're,
actually
giving
it
sort
of
less
visibility
for
something
that
isn't
strictly
administrative
as
it
were.
That
would
just
be
my
my
question
about
the
group
taking
it
on.
D
Yes,
thank
you
so
direct
answer
to
barry.
Why
not
do
this
in
dispatch,
even
if
it
was
just
a
simple
administrative
thing,
the
point
of
dispatch
is
to
provide
a
venue
for
people
to
figure
out
where
to
get
work
done
and
as
noise
around
other
topics
comes
up.
We
start
a
simple
administrative
thing
and
it
becomes
horribly,
not
administrative.
D
I
A
G
B
B
B
J
A
A
A
A
B
B
B
A
Okay,
so
hum
number
one
and
I'm
about
to
hit
the
button
that
offers
it
will
be,
should
we
do
this?
Should
this
work
happen
in
the
should
the
itf
do
this
work
and
when
I
hit
this
you'll
see
the
hum
tab
at
the
top
of
your
column,
over
where
your
media
options
and
chat
and
stuff
are,
and
here's
cullen
with
the
comment.
H
A
A
A
F
A
A
A
A
A
I
don't
see
one
of
the
q,
so
in
that
case,
if
you
believe
that
to
be
the
case,
you
know
please
state
your
opinion
on
the
list
really
soon.
Now
that
we're
going
to
progress
with
the
hums,
as
we
had
so
far
for
right
now,
and
so
now
our
second
round
of
homes
come
now.
If
you
think
dispatch
should
adopt
this
work,.
A
A
A
A
We're
gonna
have
to
start
asking
people
to
sing
during
the
hum
periods
we
have
forte
on
80
sponsors,
so
we
should
take
this
to
the
list
for
confirmation
and
of
course
we
have
to
get
make
sure
the
area
directors
will
agree
to
a
d
sponsor
that
barry
you've
had
some
opinions
here.
Do
you
want
to
make
any
comment
over
now
that
we
have
the
thumbs.
A
A
B
A
A
L
You
know
that
there
is
something
like
xpath
in
the
xml
world
next
slide,
please
and
now
that
we
essentially
have
finished
moving
over
from
xml
to
json.
Of
course,
we
often
have
the
same
problem.
We
want
to
identify
elements
or
subtrees
in
a
json
tree
without
actually
transferring
the
whole
tree
or
maybe
after
having
transferred
the
old
tree
identifying
something
in
there.
L
So
the
xma
world
is
happy
to
to
have
xpath,
which
is
a
big
turing,
equivalent
monster
and
well
jason,
never
standardized
anything
for
that.
However,
in
2007
something
called
jsonpath
was
proposed,
and
people
started
using
that,
unfortunately,
it
never
came
to
actually
standardizing
it.
You
can
go
to
the
next
slide,
so
these
are
examples
from
the
original
2007
blog
article,
and
this
is
about
all
there
is
in
in
terms
of
formal
definition
of
json
path
right
now.
L
So
if
you
know
xpath,
you
probably
will
feel
at
home
pretty
quickly
that
there
are
a
few
ways
in
which
this
is
done
differently,
and
there
is
also
an
interesting
thing.
What
is
red
on
this
slide
or
purple
is
an
escape
to
an
external
query-
language
expression,
language,
I'm
going
to
come
back
to
that.
L
Now,
of
course,
this
is
not
the
only
way
of
doing
things.
So,
for
instance,
we
have
rfc
6901
json
pointer,
which
is
very
similar
in
idea,
but
has
a
slightly
different
syntax,
of
course,
because
syntax
is
where
you
deviate
first,
and
also
the
the
scope
of
things
you
can
do.
There
is
somewhat
more
limited,
so
you
can
point
to
a
single
place
in
a
known
structure,
but
you
cannot
say
give
me
all
books
that
cost
more
than
twenty
dollars.
L
L
This
I've
been
chastised
for
making
a
comment
like
this
before
in
the
ihf,
but
I
will
do
it
again.
This
looks
like
somebody
got
a
memo
from
their
boss.
We
need
a
check
mark
for
jason
for
xpath.
Can
you
put
something
in
and
that
that
was
faithfully
executed
and
xpath
can
now
do
json,
but
I
haven't
met
any
anyone
who
actually
wants
to
use
this?
L
L
L
L
L
So
this
is
not
not
just
a
slam
dunk,
because
after
13
years
of
course,
there
have
been
a
lot
of
how
shall
I
put
it,
improvements
in
in
various
implementations
and
since
jsonpath
left
expressions
and
filters
to
an
underlying
scripting
language.
Of
course,
there
are
particular
differences
in
how
these
scripting
languages
are
are
used.
So
a
php
version
in
the
javascript
version
may
not
have
the
same
expression
language
in
them.
L
So
there
are
lots
of
details.
But
again
we
have
this.
This
amazing
open
source
project
where
they
put
225
test
cases
against
37
implementations
next
slide
and
they
collected
all
this
information.
That's
a
screenshot
of
the
website
with
a
little
accept
through
through
the
loop.
So
we
have
a
lot
of
information
now
and
we
can
start
making
decisions
and
actually
that
open
source
project
has
started
making
decisions,
so
we
don't
even
have
to
to
start
from
scratch
next
slide.
L
L
Do
we
examine
the
landscape
and
level
all
all
the
depressions
and
and
fill
everything
up
by
concrete?
I'm
not
sure
that
that's
really
what
we
do.
I
want
to
do
either.
So
this
will
be
very
much
about
defining
a
middle
ground
finding
out.
Where
do
we
actually
have
a
sizeable
usage
out
there
and
there
will
be
some
some
hard
decisions.
We
may
even
have
something
like
profiles,
a
basic
profile,
more
useful
profile.
L
So
that's
something
that
working
group
needs
to
decide
and,
of
course
the
working
group
needs
to
do
the
actual
work
of
writing
things
down
there
are.
There
are
two
internet
drafts
right
now.
Why
not?
One
has
actually
been
submitted.
The
other
is
only
on
on
github,
so
I
I'm
very
optimistic
that
this
work
could
could
lead
to
a
result
and
even
lead
to
it
quickly
and
next
slide.
The
question,
of
course,
is:
where
do
we
want
to
do
this,
so
the
size
of
the
work
would
say.
L
Maybe
a
new
working
group
is
not
entirely
wrong.
We
have
been
spinning
up
and
shutting
down
small
working
groups
before
so
that
that
would
be
one
way
of
doing
this.
Another
way
would
be
reviving
the
json
working
group.
There
are
a
lot
of
people
in
the
json
working
group
who,
who
are
very
much
very
much
aware
of
this
problem,
so
this
would
allow
us
to
start
with
with
an
audience
that
already
can
contribute
a
lot.
L
We
could
do
this
in
the
zebra
working
group,
because
the
zebra
working
group
is
going
to
need
this
in
in
any
case
in
in
some
form,
or
we
could
put
it
into
the
new
working
group
that
we
haven't
heard
about
from
mark,
yet
that
he
was
trying
to
talk
about
a
couple
of
minutes
ago,
because
jsonpath
often
is
used
over
http,
as
is
everything
else.
So
for
me,
this
is
a
little
bit
of
a
wildcard
working
group
and
I
wouldn't
object
too
much
against
doing
jsonpath
india.
But
I
think
it's
it's
a
better
thing.
L
B
B
M
M
If,
if
it
would
be
a
shame
to
to
cause
more
confusion
in
the
marketplace
by
trying
to
standardize
something
here,
I
think
we
all
know
the
cartoon
that
applies
in
terms
of
where
we
want
to
do
it.
I
think
the
first
two
options
are
fine,
a
new
working
group
or
reviving
the
json
working
group,
although
probably
a
new
working
group
would
be
better
just
to
keep
it
well.
Scoped
I
don't
think
doing
in
cbor
is
a
good
idea,
because
it's
one
consumer
for
this
work.
It's
not
everyone.
M
I
agree
that
doing
it
in
http.
Api
would
might
be
interesting
in
scope,
but
I
worry
that
I
I
want
then
we'll
talk
about
this
more
hopefully
later.
I
want
that
work
that
group
to
get
off
on
its
feet
first,
before
taking
on
really
big
things,
and
this
might
be
too
much
to
ask
at
first,
I
don't
think
putting
it
there
if
it's
successful
at
some
place,
you'd
want
to
do
this
kind
of
work,
but
maybe
not
as
one
of
the
first
work
items
is
how
it
would.
N
It'll
be
sticky,
and-
and
I
will
but
I'm
I'm
pretty
confident
that
I
we
really
need
this-
I
I
really
need
it.
I'm
gonna
work
on
it.
I
really
don't
care
where
it
is.
I
mean
I
think
seabor
is
probably
the
wrong
place,
but
all
the
others
seem
fine
to
me
and
I
don't
care
I'll
show
up
wherever
it
wherever
that
is,
I
I
would
say
to
to
mark
if
you
start
a
new
working
group
and
you
started
an
http
api.
N
H
The
are
people
hearing
me.
Yes,
okay,
so
I
think
this
should
be
a
new
working
group
and
the
reason
why
is
that
yeah?
It
certainly
can
be
done
in
something
like
seaboard.
It
is
not
really,
you
know,
that's
just
a
consumer,
but
there's
many
consumers
of
it.
I
think
a
new
working
group
makes
it
easier
for
people
who
have
one
of
those
37
implementations
to
not
be
working
in
a
working
group.
That's
trying
to
do
a
bunch
of
other
stuff
at
the
same
time,
and
so
that's
that's
a
good
reason
for
that.
H
But
I
don't
think
that
you
know
I
I
before
we
can
dispatch
really
to
a
new
working
group.
We
need
a
proposed
charter.
I
mean
that's.
What's
supposed
that's
supposed
to
be
an
inter
in
a
proposal
like
this
a
dispatch,
it's
a
requirement
for
it,
in
fact,
and
clearly
the
scoping
of
a
charter
like
this
pretty
complicated
question.
E
Yeah,
I'm
one
of
the
implementers
and
we've
formed
a
little
group
of
about
19
of
us,
mostly
most
of
the
implementers
to
discuss
this,
and
some
people
want
to
adopt
a
standard
if
it
comes
along.
Other
people
are
happy
to
describe
their
behavior
of
their
implementations
relative
to
a
standard,
so
it
doesn't
necessarily
impact
users.
E
It's
just
some
sort
of
better
documentation
in
a
sense,
and
the
way
I
see
this
might
work
out
is,
if
we
end
up
with
a
standard
and
an
implementation
that
implements
that
standard,
then
that
could
feed
into
the
the
comparison
project,
and
so
people
could
then
read
off
the
differences
of
the
various
implementations
they're
using
relative
to
the
standard
and
go
and
read
about
the
standard
there.
So
I
was
just
kind
of
concerned
about
the
not
necessarily
been
an
impact
to
end
users.
A
M
Can
you
hear
me?
Yes,
no,
it
doesn't
make
a
difference
to
the
earlier
comment.
It
doesn't
make
a
a
difference
from
the
standpoint
of
this
proposal
as
to
whether
a
new
json
working
group
or
hp
api,
but
it
doesn't
make
a
difference
for
the
hp
api
working
group
because
that's
an
effort
trying
to
build
a
new
community
and
so
taking
on
a
huge
piece
of
work
to
start
with,
might
interfere
with
that.
That's
all
that's
the
point
I
was
trying
to
make.
A
So
that's
everyone
I
have
seen
in
the
queue
so
far.
I
think
that
what
I
am
hearing
is
that
there
is
interest
in
this
work.
People
seem
to
be
leaning
towards
starting
a
new
working
group
for
it
with
the
possibility
of
putting
it
with
http
api,
but
we
just
heard
what
mark
had
to
say
there.
We
can
discuss
that
group
in
a
minute
and
that
might
give
us
some
more
clarity.
Cullen
had
a
good
point
that
if
we
are
going
to
move
forward
with
a
working
group,
we
need
a
charter.
A
So
what
I'm
hearing
from
the
sense
of
the
room
so
far
is
that
people
think
this
work
is
interesting.
We
should
do
it
and
dispatch
should
start
talking
about
a
charter
for
a
potential
new
working
group
or
in
the
process
of
talking
about
that
charter
might
decide.
It
needs
to
go
somewhere
like
http
api.
If
anyone
thinks
that's
the
wrong
approach,
please
speak.
A
I
A
L
Yeah,
so
I
think
we
have
our
work
cut
out
for
us,
so
I
write
the
request
for
the
mailing
list
and
maybe
we
can
get
the
charter
proposal
from
from
the
various
proponents
of
this
in
the
next
few
weeks,
it's
august
in
europe,
so
it's
maybe
going
to
be
a
little
slowly,
but
by
the
middle
of
august.
I
think
we
should
have
something,
but
there
is
cullen
in
the
queue.
H
So
the
I
I
like,
oh
great,
to
form
a
mailing
list
to
discuss
the
actual
work
and
get
that
moving,
no
problem
with
that.
But
I
think
the
discussion
of
the
charter
should
happen
on
the
dispatch
list,
where
we
can
call
some
consensus
on
it
and
and
get
that
moving
forward.
Everything,
because
I
do
think
that
that's
the
hard
part
of
this
working
group.
So
I
think
that
dispatch
is
a
good
place
to
discuss
formation
of
that
charter,
primarily
because
you
have
chairs
to
call
just
to
consensus.
That's
that's!
H
H
A
B
A
B
N
N
If,
if
we
do
get
held
up
and
then
and
discussion
about
how
to
get
going
is
useful,
then
I
think
above
is
useful.
I'm
hoping
that
that
doesn't
happen.
But
if
it
is,
then
then
we'll
do
it
off
and
maybe
virtual
and
maybe
not,
but
I
I
I
right
now,
I
I
think
we're
going
to
be
able
to
get
through
a
fairly
straightforward
charter
discussion
and
and
then
and
then
we'll
just
figure
out
how
to
dispatch
it.
B
P
A
B
A
L
M
Okay,
so
I'm
going
to
talk
briefly
about
a
proposal
that
has
been
stewing
for
a
little
while
now.
Obviously,
http
is
used
to
build
a
lot
of
apis
in
the
world
these
days.
When
we
talk
about
this,
I'm
not
talking
about
apis
to
use
http,
which
is
what
some
people
in
in
this
context
might
be
more
familiar
with
it's
using
http
to
build
apis
to
things
in
the
network.
M
So
next
slide
to
give
just
a
very
few
examples:
if
you
have
the
original
slide,
you
can
follow
all
these
links
to
find
lots
of
different
apis
or
for
lots
of
different
public
projects
and
companies.
This
is
a
very
small
sample
that
I
just
did
for
memory
more
or
less
it's
it's
next
slide.
Hp
is
also
being
used
for
for
even
even
other,
more
interesting
things.
M
So,
despite
broad
use
of
the
protocol
for
lots
of
different
things
that
we
call
http
apis
and
if
folks
want
to
talk
about,
why
I'm
not
saying
rest
apis,
we
can
have
that
discussion,
but
I'd
rather
not.
Thank
you.
Thank
you.
So
much
man
practice
of
of
building
these
things
is,
is
very
fragmented.
We've
been
talking
about
this
in
standards
world
for
at
least
a
decade
and
a
half.
There
were
the
rest
wars
in
the
soap
wars
back
in
the
2000s.
M
The
knots
and
people
building
little
functional
things
on
kind
of
one-off
basis,
but
there's
still
lots
of
open
questions
and,
and
generally
what
happens
is
a
company
once
they
build
a
certain
number
of
apis.
They
have
a
team
of
people
building
them
and
they
have
to
create
everything
from
scratch.
They
have
to
answer
all
these
questions
and
more.
M
And-
and
so
we
have
done
this
sort
of
thing
in
the
itf
in
the
past,
but
we've
always
done
them
as
very
much
one-off
sorts
of
things
on
the
independent
stream.
I
have
a
few
there
or
80
sponsored
so
uri
templates,
json
pointer,
which
we
were
just
discussing,
which
is
kind
of
the
analogy
exploiter
in
the
xml
world
web
linking
sunset
htv,
header
field
and,
and
so
the
itf
does
have
a
track
record
here.
M
But
but
there
doesn't
seem
to
be
much
of
a
unified
approach
to
an
architecture
or
to
to
solving
problems
that
you
know,
people
are
having
this
field
and,
most
importantly,
I
don't
think
we're
doing
a
very
good
job
in
terms
of
building
a
community
of
people
that
can
contribute
to
the
work.
It's
all
very
much.
M
Well,
this
proposal
was
brought
to
us
and
the
proponents
decided
to
come
the
itf.
Therefore,
that's
the
idf
way
to
do
it.
I'd
rather
have
a
broader.
You
know
especially
get
into
things
like
api
description.
There
are
a
lot
of
different
viewpoints
on
there
and
I
think,
as
a
standard
spot,
it
would
be
more
well
served
to
to
have
a
broader
set
of
people
contributing,
rather
than
just
proponents,
for
one
particular
approach.
M
We
want
to
increase
interoperability
and
reuse,
of
course,
and
again
connects
in
within
between
the
industry
and
practitioners
and
users.
So
next
slide.
I
think
it's
the
last
slide.
Yes,
so
this
is
the
charter
proposal.
I've
talked
to
the
ads
about
this
for
a
little
while
and
indeed
the
dispatch
chairs.
Thank
you
very
much
for
your
input
and
I've
been
talking
to
a
lot
of
people
who
do
this
sort
of
thing
as
their
full-time
jobs
and
getting
their
feedback
and
getting
their
interest.
M
M
My
I've
definitely
gotten
a
lot
of
emails
since
this
proposal
went
out.
I
think
it's
interesting
and
I
think
it's
worth
doing
personally,
but
I
also
think
it's
risky
in
that
we're
going
to
need
to
enculture
a
number
of
new
people
in
the
itf
to
make
it
work
properly,
and
I
think
that's
going
to
take
a
fair
amount
of
time
and
work.
M
There
there's
no
technical
deliverables
in
this,
but
for
it
to
consider
what
building
blocks
it
should
start
working
on
and
once
against
consensus
to
start
shipping
those
and
then
the
presumption
being
that
in
six
months,
nine
months
a
year,
the
community
looks
and
says:
okay,
is
this
working
group
successful?
Is
it
producing
things?
Is
it
representative
of
the
broader
community
which
it's
supposed
to
be
representative
of?
If
so,
it
should
continue
and
if
not,
maybe
we
need
to
rethink
it.
So
it's
a
little
bit
of
an
experiment,
but
I
think
a
worthwhile
one.
Q
M
I
did
comprehend,
so
you
don't
have
to
repeat.
I
I'm
hearing
a
lot
from
people
who
have
specs
that
they
think
might
be
interesting.
I'm
hearing
a
bit
from
folks
in
the
industry,
who
are
the
people
who
have
the
most
time
for
this,
and
probably
the
most
long-term
motivation,
are
those
people
I
spoke
of
in
those
api
teams
who
you
know
whether
it's
for
github
or
stripe
or
any
of
those
companies.
M
They
are
charged
with
making
sure
that
their
apis
are
usable
and
sustainable
and
doing
best
practice
and
defining
what
the
best
practices
are,
and
I
think
they
do
talk
amongst
themselves
in
different
communities.
But
if
the
itf
were
to
start
work
here,
I
think
that
they
would
be
interested
in
participating.
Q
B
R
M
M
I
think
if
especially
if
we
focus
on
small
building
blocks
rather
than
if
again,
if
this
working
group
were
to
say,
let's
come
up
with
the
framework
for
all
http
apis
and
you
have
to
buy
into
the
whole
thing
or
or
never
mind,
I'm
I
would
be
very
concerned.
It
really
does
need
to
be
small
pieces
loosely
joined.
I
think
to
be
successful
and
the
other
thing
I'll
mention
is
that
and
I'm
sorry
I
forgot
to
mention
before
these
sorts
of
things
come
up
regularly
in
the
http
working
group.
M
We
occasionally
adopt
one
or
consider
one,
like
the
rate
limiting
headers.
I
think
we're
kind
of
having
had
an
eye
on
for
a
little
while
but
they're,
not
clearly
in
the
scope
for
that
group
and
and
we,
the
people
in
the
room,
are
more
implementers
at
a
lower
layer
and
so
they're
not
terribly
comfortable
with
it,
and
the
folks
who
are
coming
in
aren't
terribly
comfortable
or
maybe
a
little
intimidated
by
all
these
low
layer
implementers.
So
that
that's
why
the
the
separation
from
the
http.
G
J
G
M
Sure
I
I
think
the
the
most
damaging
factors
in
ws
star
were
a
handful
of
large
vendors
with
a
tremendous
amount
of
power
and
using
that
to
try
and
get
market
share.
Rather
than
do
technically
good
things.
I
think
that
there
was
a
a
strong
flavor
of
what
some
called
after
architectural
astronautics.
M
And
and
yeah
and
frankly,
there
was
some
a
lot
of
or
a
fair
amount
of
participation
in
that
faith,
so
it
was,
there
was
lots
of
badness
happening
there.
Certainly,
if
we
see
the
same
factors
here,
I'd
be
worried,
but
I
don't
I
don't
see
too
much.
I
mean
yeah
yeah
middleware,
making
things
too
middleware
focused
is
definitely
concerned,
and
there
are
these
api
gateway
vendors.
M
K
K
Hey
this
was
partly
said
in
jabba
in
the
meantime
as
well,
but
I
just
wanted
to
respond
to
rich's
point
that
yes,
ideally
it
would
have
been
great
to
do
it
earlier,
but
the
alternative
that
we
have
available
to
us
are
now
or
later
so.
The
question
is
is
now
better
than
later,
and
I
think
to
that
the
answer
is
probably
yes.
F
S
A
S
Yes,
we
can
hear
you
okay,
fantastic
yeah,
so
yes,
I'm
interested
in
primarily
here
in
point
2d,
so
you
know
well,
two,
a
three
c
may
be
interesting.
My
impression
that
people
who
do
apis
is
they
often
don't
want
to
screw
with
header
when
do
headers
and
status
codes
because
they
want
to
make
they
want
to.
They
want
to
make
browser
apis.
S
You
know
they're
accessible
via
fetcher
xhr,
not
everybody
else,
of
course,
but
so
I
know
there's
been
a
lot
of
discussion
in
the
hp
community
about
like
or
about
you
know
what
the
best
way
to
actually
design
apis
is,
you
know,
should
you
just
be
exposing
your
rms
at
higher
level,
apis
et
cetera,
so
you
get
things
like
tasty,
pi
or
whatever.
I
guess.
How
much
of
that
do,
you
think,
is
the
scope
for
this
under
2d.
M
M
S
S
J
A
I'm
hearing
a
few
questions
about
the
charter.
I
think
that
without
putting
myself
in
the
queue,
I
think
the
idea
of
the
work
that
group
that
starts
here
are
harold
to
the
back.
But
I'll
finish
my
comment.
I
think
that
the
group,
the
idea
of
the
group
that
starts
up
and
then
figures
out
its
work,
is
kind
of
interesting
a
little
different
than
we
normally
do.
A
N
Brian,
I
sorry
you
you
said
you
wanted
to
move
on,
so
I
pulled
pulled
back.
I
I
think
we
should
go.
I
think
we
could
probably
pick
a
couple
of
things
you
mentioned
and
make
them
initial
charter
items.
I
I
mean
versioning
is
the
one
that
strikes
me
as
immediately
useful,
an
immediate
problem
happy
to
work
on
it.
So
I'm
I'm
very
optimistic
about
this.
Let's
get
going.
M
Api
versioning
is
one
of
the
more
controversial
bits
out
there
yeah.
I.
I
would
really
like
to
see
this
group
do
a
couple
of
really
small
things
first
and
prove
itself,
and
also
give
external
folks
enough
time
to
to
come
to
the
venue,
rather
than
taking
on
something
really
meaty
as
its
first
item.
But
that's
just
my
personal
take.
B
T
I'm
trying
I'm
trying
to
get
my,
I
get
my
placing
cue,
but
I
keep
losing
it,
and
the
big
thing
here
is
when
we
have
when
we're
talking
apis.
We
traditionally
talk
to
the
wtc
and
the
charter
does
not
mention
language
and
it
doesn't
mention
a
wtc.
I
think
the
the
charter
has
proposed
this
therefore
incomplete,
even
if
you
have
anything
to
believe
that
we
can
have
a
friendly,
a
friendly
cooperation
with
them.
With,
with
the
with
this
work
being
done
in
the
ietf,
then
we
we
need
to
say
that
explicitly
why
we
believe.
T
So
what
do
you
mean
by
language
herald
and,
frankly,
every
every
attempt
I've
seen
that
tries
to
define
an
api
without
defining
which
languages
is
the
the
the
definition
language
has
failed
in
practice.
Wjc
is
currently
specifying
for
all
their
apis
in
terms
of
in
terms
of
javascript
and
than
the
others.
T
M
T
A
M
U
Oh
good,
to
see
you,
okay,
awesome,
hi
everyone.
My
name
is
for
google,
so
I'm
here
going
to
discuss
as
a
frame
enter
in
description
for
video
conferencing
proposal.
So
I
only
got
20
minutes,
I'm
not
going
to
deep
into
the
document
drafted
set.
I
hopefully
everyone
gets
a
chance
to
read
the
draft,
I'm
just
a
very
high
level
overview
of
the
document.
Then
the
goal
of
this
presentation
just
see
what's
next
step
for
this
work.
U
U
So
the
ghost
recent
frame
is,
of
course,
security,
going
into
encryption
for
all
and
frame
points
in
video
conferencing.
The
key
the
next
two
ones
are
very
important
simplicity.
We
need
to
we
always
minimize
the
changes
needed
for
existing
media
servers
and
endpoints
to
adapt
as
frames
and
the
other
one
is
efficiency,
minimize
the
encryption
overhead
as
much
as
we
can
for
endpoints
and
compatibility
with
existing
protocol
like
rtc,
still
working
with
error
correction
mechanism
like
ac,
rtx
and
also
transport
agnostic,
can
be
used
with
rtb.
U
It
can
be
used
in
the
future.
Electrodes
called
like
like
next
like
this,
so
this
is
usually
how
video
conferencing
works
in
these
settings.
Clients
in
multiple
streams
like
center
server
like
low,
relational
hierarchical
resolution,
and
this
streams
are
encrypted
to
the
server,
only
does
not
have
access
to
the
media
and
then
the
server
decide
which
which
destination
gets
which,
which
stream
next
slide.
Please.
U
So
with
this
frame
is
we
add
another
layer
of
encryption
where
we
encrypt
the
entire
media
frame
for
each
stream,
and
then
we
give
the
metadata
only
if
it's
a
server
server
can
only
access
the
metadata
of
the
media
to
route
to
news
to
know
how
throughout
the
media
but
doesn't
get
access
to
media
itself,
the
entering
keys
are
located
into
and
out
expand
it's
encrypted
into
ends.
Only
here,
increment
is
hot.
By
half
issues
are
using
their
own
sender
key
to
encrypt
their
outgoing
traffic.
U
It's
just
only
going
to
make
slide
plays,
and
this
is,
for
example,
is
in
the
integration
group
rtc,
so
it's
the
frame
injected
after
the
encoder
and
before
bacterization,
and
then
it
includes
the
entire
frame
press,
the
the
full
frame
to
the
background,
and
then
the
the
oxidizer
displace
the
frame
into
smaller
packets,
and
these
smaller
packs
are
encrypted
only
to
the
server
the
encryption
decrypter
communicates
with
the
messaging
server
to
change.
The
keys
usually
use
a
signature
for
this
next
slides.
U
This
is
the
encryption
schema
it's
very
resisted
forward,
so
it
encrypts
the
entire
frame,
as
I
said
so.
Basically,
what
user
exchange
is
actually
master
key
now
from
this
master
key
to
derive
three
different
keys,
encryption,
key
authentication,
keys
and
salt
key,
as
the
entire
frame
includes
the
encryption
key
metadata
and
header
and
and
the
encryption
in
synthetic
with
the
authentication
key
and
subscribe
to
just
drive
the
iv.
U
U
And
this
is
this:
is
a
y
format,
just
a
big
chunk
of
encrypted
frame,
it
prefixes
with
sfm
header,
which
has
iv
some
metadata
and
sorry
suffix
with
authentication
tag.
There
are
two
versions
of
the
of
the
header
short
header,
which
only
have
the
key
id
in
case.
The
incubation
stream
is
for
qid,
so
support
up
to
from
0
to
70
and
the
counter
length
which
is
iv-
and
this
is
encoded
in
environment
in
case
of
tid-
is
increased.
Then
more
than
eight
we
actually
use
a
long
header.
U
Please
encryption
overhead
is
actually
usually
comes
from
the
iv
and
application
tag,
and
all
these
frames
actually
beats
existing
or
rather
ecoe
principles,
because
the
authentication
iv
are
amortized
over
the
frame
are
not
per
packet,
of
course,
for
audio
one
frame
make
one
packet,
but
for
video
one
free,
usually
split
into
multiple
brackets,
also
even
more,
with
s
frame
using
var
end
as
a
response
slide
to
encode
iv,
so
that
it
reduce
overhead.
Even
more
next
slide.
U
U
We
still
need
a
couple
more
different
ways
to
have
like
a
more
more
convinced
solution
like
that,
for
example,
there's
a
key
initiation.
Can
we
integrate
with
existing
mls?
It's
gonna
be
more
efficient,
using
a
single
root
key
with
usually
designed
actually
designed
for
larger
group
like
57
participants,
it's
even
be
more
efficient
and
maybe
another
draft
for
how
this
individual
loop
rtc,
how
the
key
are
using
the
signal
channel.
What
should
be
the
bailout
type,
how
the
metadata
are
passed?
U
This
is
in
terms
of
displays
in
terms
of
implementation,
has
been
in
production,
at
least
in
google
for
the
last
two
years
it
lasted
in
double
last
year.
I
know
other
other
like
studios
using
it.
Other
servers
are
reading.
I
believe
also
other
implementations
are
coming
out
very
soon
and
then
last
slide.
U
So
I
think
what
should
be
the
next
day
so,
as
I
mentioned
like
this,
work
has
been
done
like
for
the
last
two
years,
but
what
actually
triggers
the
leader
recently
is,
since
the
dynamics
started.
Everyone's
video
conference,
like
the
industry,
has
shown
a
huge
interest
in
having
antoine
decrypted
video
conferencing.
U
Everyone
likes
just
trying
to
lose
their
own.
We
wrote
this
threat
people.
There
are
huge
interests
in
the
industry
in
this
proposal.
This
is
why
we
wrote
this
draft
and
I
I
wanna
like
okay,
this
present
dispatch
and
see
if
people
are
interested.
If
so,
what
will
be
the
next
step?
Ideally,
you
should
have
like
a
new
working
group
to
isolate,
to
check
all
these
type
of
documents
very
focused
to
get
this
done,
or
maybe
existing
groups,
but
yeah.
This
is
the
this
is
the
discussion.
We
have
right.
U
V
V
So
I
think
we
need
to
nail
down
a
couple
of
things
like
this,
but
I
think
the
overall
approach,
especially
in
its
simplicity,
is,
is
really
on
the
right
path
and
we
should
charter
a
small
focus
working
group
on
this.
There
are
just
so
folks,
though
there
is
a
draft
charter.
That's
been
kicked
around
on
the
s
frame,
millions
a
little
bit,
so
I
think
we're
we
could
be
in
a
pretty
good
position
to
go
ahead
and
form
something.
V
W
I
know
I'm
here
you're
here,
okay,
yes,
it's
hard
to
know
when
I'm
supposed
to
be
talking,
so
I
I'm
certainly
supportive
of
the
work.
I
say
I'm
supportive
of
solving
this
problem
and
this
type
of
approach
has
been
adopted
in
a
a
number
of
previous.
You
know,
there's
been
a
number
of
previous
that
is
work.
Taking
this
sort
of
approach.
U
W
W
X
X
The
are
you
get
to
have
the
rtp
scaling
properties
are
dramatically
better.
We've
discussed
on
the
list
that
there's
certain
things
like
signing.
That
can
really
only
be
done
with
this,
because
it
dramatically
reduces
the
overhead,
because
you
only
would
would
sign
a
frame,
not
a
individual
packets,
so
I
think
we
we
basically
should
go
ahead
and
standardize
this
somewhere.
Thank
you.
X
S
Okay,
so
that's
exciting,
so
I
I
guess,
I'm
generally
positive
on
this
bernard,
I
don't
think
you're
quite
about
signing,
there's
been
quite
a
bit
of
discussion
about
how
to
sign
in
rgb
context,
going
back
about
10
or
15
years.
The
problem
is
the
same
problem
here,
which
is
amortizing
this
integer
across
multiple
packets,
so
that
may
or
may
not
be
a
good
idea.
We
probably
should
figure
that
out.
I
I
do
like
the
fact
that
this
emphasizes
that
we
need
some
end-to-end
keying.
S
I
don't
think
avt
core
is
probably
the
right
place
for
this.
Most
of
the
things
that
would
have
to
do
are
not
gonna
evt
and
from
previous
experiences.
I
think
that
there's
a
bit
of
like
having
a
several
working
group
just
has
the
right
set
of
people
in
the
room
without
having
sort
of
people
kind
of,
like
you
know,
having
to
have
like
a
lot
of
people
sort
of
sit
through
one
working
group
for
the
five
minutes
actually
to
talk
about
something.
B
C
Back,
apologies.
We,
you
know
the
world
was
all
you
know.
We
were
much
more
many
working
groups,
I
would
have
said
avt
car,
but
now
that
I
feel
like
you
know,
for
instance,
perk
for
all
that
perk
may
not
have
been
successful
as
a
protocol.
I
think,
as
a
working
group
model
pulling
it
out
and
getting
the
right
people
in
the
group
was
successful.
C
There
is
going
to
be
a
lot
of
media,
specific
complexity
here,
which
I'm
not
sure
the
current
people
understand.
So
it's
going
to
need
a
lot
of
the
people
from
abt
core,
but
I
think
it's
going
to
need
a
lot
of
people
who
are
not
currently
navy,
decor
as
well,
so
probably
a
new
working
group
as
well
as
useful.
Also
I
somehow
have
not
actually
personally
can
you
could
somebody
send
the
link
to
that
mailing?
That
was
mentioned
and
are
the
archives?
J
J
A
A
Hopefully
many
working
group,
so
I
think
the
next
step
is
to
there
was
talk
about
a
charter
being
floated
around
when
people
are
ready.
We
need
to
bring
that
charter
into
the
dispatch
working
group
list
and
go
through
the
dispatch
discussion
on
that
charter.
I
notably
did
not
hear
a
single
person
say
we
should
do
this
in
perk,
so
I
think
the
answer
to
that
is
no.
I
don't
think
anyone
thinks
we
should,
but
if
anyone
does
think
we
should,
you
can
say
that
in
the
list
we
don't
have
time
right
now.
A
A
Was
that
asap
right
right?
Yes,
so
that
that
meeting
is
not
actually
going
to
happen?
Apparently,
discussion
decided
that
they
didn't
need
to
meet.
Today
we
have
a
couple
of
buffs
happening
in
the
art
area,
the
asdf
on
semantic
somatic
data
definitions
for
iot,
and
then
we
also
have
the
webcore
for
revision
of
core
email
specs
coming
out
on
wednesday,
so
first
one's
tuesday,
the
next
one's
wednesday.
A
My
understanding
is
that
there
is
some
move
to
email
core
to
advance
the
standards
to
the
next
level
and
some
other
interesting
meetings.
A
little
bit
later
today,
we've
got
the
rfc
editor
future
development
program.
That
is
a
iab
program
for
on
the
rfc
editor
futures,
but
it
is
open
for
open
participation.
A
Tomorrow
we
will
have
something
new
from
the
ieb,
the
iub
open
meeting.
Then,
on
thursday
we
will
have
both
security
dispatch
and
general
area
dispatch,
and
the
ads
asked
me
to
mention
that
the
general
area
dispatch
meeting
is
going
to
include
a
discussion
on
changes
for
the
non-com
eligibility
criteria.
So
that's
pretty
important
for
our
core
culture.