►
From YouTube: IETF111-DISPATCH-20210726-1900
Description
DISPATCH meeting session at IETF111
2021/07/26 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
Okay,
hello:
everyone
welcome
to
dispatch
itf
111,
the
start
of
itf
111.
This
meeting
is
actually
also
my
10th
itf
meeting,
so
I
feel
like
I
deserve
a
cake
or
something.
Hopefully
you
can
all
see
the
slide
deck
in
front
of
you.
You
can
all
hear
me:
okay,
it's
great
to
have
us
all
together
for
another
virtual
itf
meeting
you're
here
in
dispatch,
hopefully
you're
expecting
to
be
in
dispatch
which
is
combined
with
the
art
area
meeting,
and
it's
myself
and
patrick
mcmanus,
who
are
co-chairing
dispatch
today.
Yeah.
A
Thank
you,
everyone
putting
cake
in
the
chat
that
that
does
actually
make
me
feel
quite
good,
so
welcome
whatever
time
of
day
it
is
for
you
we're
just
gonna
run
through
a
few
instructions.
This
is
the
first
session
of
every
itf
week,
so
you
may
not
be
as
familiar
with
the
technology
or
kind
of
the
protocols,
no
pun
intended
and
that
you
need
during
the
week
so
we'll
just
go
through
them
now.
A
A
A
Okay,
so
this
session
is
being
recorded.
Participation
tips,
please
use
headset.
If
you
can
add
yourself
to
the
meet
echo
cue
to
speak,
you
just
do
plus
q,
so
writer
plus
q
or
you
can
raise
your
hand.
If
you
look
at
the
top
left
of
your
meet
echo
chat,
there's
a
join
queue,
which
looks
like
a
hand
with
a
slash
through
it.
A
Please
say
your
name
before
speaking,
so
that
would
just
be
kirsty,
p
or
kirsty
payne
ncsc
for
me,
so
that
we
can
keep
an
account
of
who
is
discussing
and
who
is
bringing
points
to
the
queue.
Do
you
use
jabber,
that's
just
on
the
side
of
the
session
for
you
and
you
don't
have
to
worry
about
blue
sheets.
That's
taken
from
the
meet
echo
roster.
So
there
are
some
useful
links
that
are
uploaded
on
the
meeting
materials
as
well
in
dispatch.
A
So
yeah
welcome
to
their
itf
111
dispatch
virtual
meeting-
it's
the
26th
of
july
in
sometimes
welcome
and
here's
our
agenda
for
today
we're
going
to
spend
the
first
five
minutes
just
taking
a
check
of
where
we
are
and
doing
an
agenda
bash.
And
then
we
have
a
few
topics
in
dispatch
today
and
jws
clear
text,
json
signature
options,
then
we've
got
10
minutes
on
image,
webp,
mine
type
registration,
then
20
minutes
on
nicer,
which
is
a
usage
profile
of
ice
sdb
coming
up
for
10
minutes
afterwards
is
not
recommended.
A
A
Then
we've
got
an
update
on
a
new
code,
expect
from
the
seller
working
group,
ipv6
owner
identifiers
and
uris,
and
reliable
and
reliable
streaming
protocol
rush,
and
so,
if
you
are
interested
in
all
of
these
talks,
that's
the
agenda.
We're
sticking
to
today.
All
of
the
slides
and
meeting
materials
are
uploaded
on
the
ietf
pages
as
well.
Under
the
dispatch
session.
A
A
But
hearing
nothing
we'll
start
with
our
dispatch
topics.
A
So
first
up
we've
got
samuel
edmond
presenting
on
jws
cleartext
json
signature
option.
B
Thank
you.
I
hope
everyone
can
hear
me.
Do
I
click
the
slides
or
do
I
ask
you
to
do
it
christy
I'll,
just
try
to
do
it.
Song
jvs?
Yes,
I'm
saying
not
your
clear
text!
Yeah,
it's
a
signature
option.
I
will
go
into
the
rationale
and
then
just
a
rough
overview,
how
it's
meant
to
work
and
then
we
can
go
into
questions
and
comments.
B
And
next
slide,
if
I'm
not
the
one
doing
that
yeah,
so
this
is
more
or
less
copied
from
from
the
document.
But
if
you
haven't
read
it
so
jvs
clear
text,
json
signature
option
describes
a
method
for
extending
json
web
signature
standard
called
jbs
ct
by
combining
the
detached
mode
of
uavs
with
json
connection,
schema,
maintaining
sign
json
data
in
json
format,
as
it's
probably
being
transmitted
or
stored,
or
whatever
next
slide.
B
So
there
is
a
set
of
reasons
when
one
might
not
want
to
only
use
the
abs,
as
is,
and
just
to
list
them
here,
and
go
into
slightly
more
detail.
So
in
situation
where
you
have
predefined
json
structures
that
you
want
to
use
and
you
have
want
to
maintain
backwards
compatibility
as
you
add
signatures,
it
does
not
work
to
repackage
the
whole
thing
into
a
jbs,
but
you
have
to
instead
add
the
signature
on
the
side
in
some
ways.
So
this
document
describes
how
to
do
that
and
add
it
into
the
json
structure.
B
You
might
have
large
data
structures
in
json
format
that
are
shared
between
organizations
and
you
signatures
added
in
later
steps.
You
might
augment
the
json
as
you
go
along
and
assign
it
as
you
go
along
and
then
it's
also
very
inconvenient
to
put
it
within
the
jvs
signature.
So
there
it's
very
convenient
to
have
the
option
to
create
the
signature
and
add
it
into
the
json
doc
document
afterwards,
adding
multiple
signatures
and
nesting
data
structures.
B
B
Even
though
it's
technically
usually
often
doable,
and
then,
if
you
need
or
want
to
transmit,
unsigned
data,
it's
convenient
to
you
to
just
not
add
the
signature
instead
of
packaging
jps
and
then
have
the
non-algorithm
being
used.
B
B
And
yes,
so
constructs
so
next
slide
again
so
and
the
as
it
specified
today
the
canonicalization
to
get
something.
Designable
uses
jcs
rfc8785,
which
takes
json
and
puts
it
in
a
canonical
json
format.
It's
100
json
valid,
but
it
limits
the
expressibility
of
json
slightly
by
limiting
it
to
I
json.
B
B
B
But
while,
if
you
do
the
detach
signature,
you
just
leave
out
the
data
part
from
the
signature,
so
you
have
the
header,
the
red
part
and
then
the
blue,
which
is
the
signature
bytes
next
slide.
B
B
Then
we
go
to
the
next
slide,
where
you
prepare
the
json
to
be
signed
by
canonicalizing
it
as
it
becomes
slightly
shorter,
removing
white
spaces
and
so
on.
But
that's
another
specification
then
next
step
next
slide,
then
you
can
use
the
like,
whatever
jvs
library,
implementation,
you
use
and
use
the
canonicalized
bytes
as
input
for
the
signature,
but
you
can
remove
it
as
described
in
independence
of
the
detached
signature,
and
then
this
is
what
you
get
and
next
slide,
and
then
you
assemble
it
together.
B
B
We
don't
dictate
that
it
would
be
called
signature
or
at
what
level
to
put
it
but
or
we
say,
root
level,
but
don't
think
that
the
naming,
because
that's
very
application,
specific
in
our
opinion
next.
B
Next
slide,
please
thank
you.
You
extract
out
the
the
signature
attribute,
the
signature
property
yeah
detached
nothing
strange.
You
go
to
the
next
slide,
remove
the
signature
property
because
it
wasn't
there
when
you
cannot
collect
and
signed
it.
So
you
need
to
remove
it
and
then
we
go
to
the
next
slide
and
here
it's
again
canonicalized
and
then
you
do
the
last
step
next
slide,
where
you,
where
you
have
taken
the
canonicalized
bytes
and
put
it
into
a
jvs
signature,
then
do
the
invalidation
step
according
to
the
jbs.
B
So
here
it
you
see
the
data
part
to
make
it
possible
to
use
like
any
jvs
library.
So
this
makes
it
like
super
compatible
and
super
easy
to
implement
with
existing
libraries.
B
Object
since
it's
json
and
possible,
and
then
you
parse
it
again
to
make
sure
that
you
actually
operate
on
what
was
canonicalized
and
signed
in
practice.
Next
slide.
B
B
B
So
this
work
has
been
up
on
the
discard
in
in
different
forms
on
different
mailing
lists.
We
suggest
that
we
move
forward
as
ise
since
the
canonicalization
rfc
8785
is
published
as
an
independent
submission
and
since
the
jose
working
group,
where
it
could
suit.
If
I
understand
things
correctly,
that
working
group
is
closed,
but
it
has
also,
which
might
be
more
important,
being
very
limited
interest
expressed
by
the
people
from
that
list.
Even
though
we
see
interest
from
other
groups
next
slide.
B
However,
if
you're
interested,
we
would
love
to
get
reviews
and
comments
and
suggestions
to
make
this
work
even
better
next
slide
and
yeah.
Thank
you
for
listening
it's
time
for
questions
and
comments.
I've
seen
carson
here,
but
I
just
wanted
to
mention
that
he
something
if
he
does
not
have
time
to
speak
for
himself.
During
this
meeting
yeah,
he
sent
an
email
being
explicit
that
he
does
not
like
the
clear
text
name.
A
That's
okay!
Thank
you
for
your
presentation.
So
now
we
look
at
the
queue
we've
got
a
few
people
in
the
queue
really
interested
to
hear
your
thoughts
on
the
dispatch
question
where
they
should
go
and,
of
course,
any
clarifying
questions
that
you
have
for
samuel.
So
if
you
want
to
manage
the
queue
yourself
samuel,
it's
cast
in
first
and
just
a
reminder,
please
state
your
name
before
making
your
comment
or
question
thanks.
C
B
Thank
you
carsten.
I
think
so.
I
would
not
personally
be
against
changing
the
name.
If
we
come
can
come
up
with
something
more
suitable.
I
guess
I
would
propose
here
to
maybe
yeah
if
I
don't
have
suggestions
but
I'll.
Take
like
the
naming
discussion
on
the
mailing
list.
For
example,
that's
something
that
could
be
very
well
done
in
asynchronously.
D
D
I
have
a
clarifying
question:
do
you
think
that
this
will
this
this
you
know
rfc
will
end
up
being
referenced
by
other
working
groups,
because
if
you
go
to
the
isc
you're
going
to
be
stuck
at
at
most
informational.
So
if
you
think
that
this
is
going
to
become
like
a
standard
normative
reference
you're
going
to
have
to
uplift
it
anyways,
so
that
would
kind
of
dictate
that
you'd
want
to
be
not
through
the
ise
you'd
want
to
be
through
an
ad
or
a
working
group.
D
B
B
B
Based
on
the
reception,
I
would
maybe
not
actually
expect
many
other
working
groups
to
adopt
this,
but
rather
actually
my
perception
is
that
it's
more
of
a
in
the
wild
de
facto
thing
people
wants
to
do
something
like
this.
They
want
a
document
where
it's
defined
so
that
they
can
implement
it
and
get
some
interoperability.
B
E
So
I
sent
some
comments
via
email,
roughly
speaking,
I'm
not
like
really
frustrated.
This
is
a
good
idea,
but
I
guess,
if
you
take
it
to
isa,
it
can
sit
with
many
other
bad
ideas
that
have
also
been
published
by
isa.
So
I
think
that's
the
appropriate
place
to
do
it.
I
said
some
technical
comments
under
the
circumstances
can
endure
or
not
ignore.
E
I
sent
them,
I
sent
them
an
email,
I
think
probably
the
most
relevant
one
is
like,
I
think,
having
the
canonicalization
part
of
the
signature
process
is
quite
unwise.
It'd
be
much
better
to
phrase
this
as
the
channel
for
these
are
transmitted,
it
needs
to
be
transparent,
needs
to
be
transparent
to
the
json,
and
then
you
should,
and
then
people
can
accomplish
that
by
canonical
by
canonicalizing
on
either
end
or
not
as
they
please,
but
but
having
this
be
part
of
the
figure
process
is
like
how
we
got
like
the
messes.
B
E
E
You
propose
to
you
supposed
to
accomplish
that
by
adding
a
canonicalization
phase
to
both
prior
to
signature
and
verification,
and
what
I'm
saying
instead
is
that
you
should
make
this
an
application
problem
as
the
application's
responsible
for
delivering
data
in
an
unmodified
format,
and
it
can
do
that
in
a
number
of
ways,
one
of
which
is
actually
having
a
transparent
channel
and
one
of
which
is
canonicalizing
on
either
end
right
and
and
then
we
don't
and
then
we're
not
like
building
and
then
and
then,
for
instance,
that
then
that
doesn't
require
any
specific
canonicalization
formula
at
all,
because
this
application's
problem,
not
this
positive
system's
problem.
E
B
It
depends
on
what
you
would
what
you
want
to
hand
off
to
the
to
the
application
implementation.
What
you
think,
what
you
believe
is
valuable
to
specify
and
define
and
and
so
on,
but
it's
definitely
a
valid
comment.
I
guess,
if
we
look
at
the
the
classic
abs,
they
they
do
that
by
they
define
the
mechanicalization
as
an
ascii
armoring
solution.
Instead,
and
here
we
define
it
as
as
json
chemicalization
and
the.
G
Yeah,
so
this
is
patrick
before
we
jump
to
cohen
who's
next,
in
the
queue
I
just,
we
didn't
maybe
cover
the
dispatch
process
and
hey.
We
have
colin
as
a
working
group
chair
emeritus
here,
who
can
let
us
in
on
it,
but
just
to
remind
folks
the
the
primary
goal
here.
G
Our
agenda
is
to
consider
whether
we
want
to
find
a
home
for
these
work
items
within
the
ietf
and
if
we
do
where
we
think
that
might
best
be
formed,
be
that
a
new
working
group,
an
existing
working
group.
G
Perhaps
we
don't
want
the
ihf
to
adopt
at
all.
The
chat
has
mentioned
the
ise,
just
the
ise
isn't
really
in
our
purview,
so
certainly
things
that
we
recommend
we
don't
adopt
may
pursue
may
want
to
pursue
that
path
independently
of
what
we
do
and
a
reminder
that
really,
this
is
just
a
an
opportunity
for
the
collective
wisdom
of
helping
things
find
a
home
in
the
ietf
really
be
brought
to
bear
the
final
decisions,
even
though
we
sometimes
talk
about
dispatch
consensus.
G
The
final
decisions
really
belong
with
the
aeds.
So
with
that,
we're
still
talking
about
this
particular
draft
colin.
What
do
you
think
man
you're
the
best.
H
The
best
chair
of
this
group,
ever
I
was
just
going
to
basically
point
out
that
problem,
like
all
I
was
going
to
say,
is
when
we
say
send
this
to
the
ise.
What
we
mean
from
a
dispatch
decision
point
of
view
is
the
ietf
should
not
take
this
off,
which
is
a
perfectly
valid
way
to
dispatch
things,
but
I
think
that
that's.
H
I
I
Hi
there,
so
I
ecker's
explanation
of
what
should
happen
with
this
was
actually
quite
helpful
to
me.
I
think
that
the
idea
of
having
a
signature
that
doesn't
require
ascii
armoring
is
interesting
for
a
variety
of
things,
not
just
jason,
but
I
agree
with
ecker
that
this
approach
of
trying
to
come
up
with
the
canonicalization
is
going
to
cause
great
pain
and
suffering
and
shouldn't
be
done
in
the
itf.
I
If
you
want
to
do
it
in
the
itf
and-
and
I
think
shawn's
reasoning
behind
that
that
this
might
be
adopted
by
others-
is
a
good.
You
know
a
good
point,
I
think,
taking
on
what
ecker
was
saying
and
actually
thinking
about
how
to
make
this
an
application
layer
problem
might
be
a
good
idea.
It
might
solve
problems
for
other
folks
along
the
way
that
might
be
more
work
than
you're
interested
in
doing,
but
I
think
it's
at
least
something
that
you
should
consider.
A
Thank
you
pete,
so
we're
just
coming
to
the
end
of
the
slot
here.
So
I'm
going
to
start
a
show
of
hands.
So
for
those
of
you-
and
this
is
the
first
session
so
if
you're
not
familiar
with
the
tool,
we're
asking,
should
the
ietf
take
this
on?
So
if
you
think
the
itf
should
take
this
work
on
in
some
way,
then
you
raise
hand
if
you
think
that
is
not
an
option
then
do
not
raise
hands
should
be
what
you
select
and
that.
A
G
Can
you
hear
me,
I
can't
hear
christy
either?
Okay,
you
can
hear
me
so
christy
set
up
a
poll
over
in
the
raised
hands
section
here
where
we're
going
to
draw
a
poll
here.
Christie
have
the
language
figured
out
and
I
just
got
to
wing
it.
Chrissy
set
up
a
poll
about
whether
or
not
we
want
to
so
the
idea
of
taking
on
this
work,
which
is
positively
or
negatively
with
the
implication
being
that
we
would
recommend
no
working
group
action
be
taken.
G
Should
we
not
want
to
take
this
on
kirsty?
Can
you
open
it
up?
Can
you
talk?
Kirsty
pete
says
it
sounds
like
christy
came
back.
J
A
G
All
right,
I'm
going
to
end
this
session
in
just
a
couple
more
seconds.
There
haven't
been
many
participants
at
this
point
and
what
we'll
do
is
christy
and
I
will
chat
separately
during
for
future
presentations
and
come
back
and
sort
of
give
a
summary
of
what
the
room
thought
later
in
the.
G
G
G
Thank
you
all
for
that.
G
A
Yeah,
I'm
back
now
sorry,
everyone
yeah!
So
thank
you
very
much
samuel
for
bringing
your
work
here.
Yes
and
we'll
move
on
to
our
next
presenter.
So
it's
james
cern,
I'm
presenting
on
webp
media
type,
registration,
hi
james.
F
Hi
thanks
thanks
christy
and
thanks
for
the
help
and
in
setting
all
this
up
and
running
the
slides,
so
just
for
some
quick
background,
I'd
like
to
introduce
the
webp
image
format,
the
motivation
and
then
move
on
to
talking
about
where
this
best
fits
in
in
working
groups.
So
next
slide
please
for
people
not
not
aware
of
the
format
it's.
F
It
started
off
as
a
lossy
compression,
replacing
or
looking
to
fit
the
jpeg
use
case
and
we
kind
of
iterated
on
it
through
this
time
period,
adding
lossless
alpha
and
transparency
and
then
animation.
So
roughly
the
format
was
finished
and
finalized
hasn't
had
modifications.
Since
about
2013.,
I
will
say
that
during
this
time,
image
slash
web
b
was
used,
which
made
it
a
bit
nebulous
what
that
meant.
F
Fortunately,
we
were
controlling
some
of
the
integration
at
that
point,
so
it
wasn't
a
huge
issue
and
then
maybe
next
slide
and
for
general
availability,
we're
in
all
major
browsers-
and
these
are
all
have
been
using
this
mime
type
since
they
added
support,
as
well
as
a
set
of
image,
viewing
editing
applications
and
things
of
that
nature.
F
So
really
the
the
goal
of
the
format
was
to
is
to
replace
use
cases
for
jpeg,
png
and
and
gif
for
animation,
and
that's
really
very.
K
F
Background
on
on
the
history
here-
and
maybe
the
next
slide,
I'd
like
to
open
it
up
to
discussion
about
where
this
best
fits
so
that
we
can
get
this
registered
because
I
think
it
it's
blocking
a
little
bit
of
other
standards,
work
based
on
our
our
bug,
tracker
for
the
project.
So
I'd
like
to
get
this
registered
and
allow
them
to
move
forward.
A
Okay,
thank
you
james.
You
can
see
people
joining
with
you
just
as
a
reminder
to
join
the
queue.
Click
that
hand
with
the
line
through
it
and
barry
lieber
you're
up
first.
L
All
right,
this
is
barry
lieber.
It
seems
to
me
there's
no
reason
this
should
even
go
into
an
rfc.
This
can
just
be
requested
using
the
expert
review
path
and
that's
what
I
think.
That's
what
I
think
you
should
do.
Write
up
the
specification
post
it
somewhere
and
submit
it
to
iana.
L
Yeah,
okay,
you
probably
got,
I
don't
know,
maybe
you
got
most
of
it.
I
will
put
the
microphone
closer.
The
this
should
just
be
written
up
and
posted
somewhere
and
then
submitted
to
ayanna
as
a
expert
review
request.
There's
no
reason
to
do
an
rfc
for
this.
F
Right-
and
I
I
guess
I
should
have
led
in
with
that-
thank
you
for
the
comments
I
had
originally
started
with
the
ina
iana.
K
F
They
actually
requested
that
I
go
this
path
filing
a
registration
rfc
to
give
it
a
place
to
to
gather
all
this
information.
So
the.
F
L
L
F
The
mailing
list,
but
yes,
I
I
had
started
there
and
actually,
at
the
same
time,
there's
murray
murray
maze,
probably
has
a
better
description
and
thank
you,
murray,
for
the
help
and
and
brings.
L
Me
to
emery
is
one
of
the
expert
reviewers,
so
you
could
answer
that.
Yeah.
M
I
suggest
let
me
try
to
find
the
email
it's
in
a
different
tab
here.
I
remember
suggesting
that
that
was
an
option
under
the
idea
that
this
working
group
is
its
charter,
allows
it
to
do
simple
administrative
documents.
If
this,
if
dispatch
agrees
that
that's
all
this
is,
it
could
be
processed
this
way.
L
M
If
it's
necessary
to
do
so,
I
I
think
I
think
I
agree
with
barry
at
this
point
that
we
should
just
see
if
it
can
go
through
the
regular
media
type
registry,
but
this
has
to
be.
This
is
asking
for
a
standards,
registration
right,
the
standards
tree.
M
Okay,
let
me
follow
up
with
on
this,
rather
than
taking
up
the
working
groups
time,
I
I'm
fine
with
either
those
two.
This
is
relatively
lightweight.
I
think
that
I'm
I
can
dust
myself
off
from
the
last
one
and
and
sponsor
it
if
I
have
to,
but
otherwise,
but
let's
try
the
expert
review
way.
First,.
J
F
There
are,
and-
and
I
think
that
was
probably
part
of
the
some
of
the
concerns
in
the
ina
n-
a
since
it's
a
combination
of
different
compression
algorithms-
we
have
resources
for
both,
but
we
don't
have
a
blessed
official
specification.
If
you
want
I,
I
would
argue
that
the
the
information
is
there
and
we're
it's
it's
within
this,
this
draft.
Actually,
so
I
I
think
the
details
are
there
for
an
implementation
to
happen.
Yes,.
J
Yeah
I
mean
that
seems
like
the
core
thing
to
me.
I,
I
don't
favor
white,
just
registering
a
media
type
unless
there's
a
document
that
a
competent
influencer
can
go,
look
at
and
write
code,
so
it'll
work
on
whatever
box
they're
running.
If
such
a
thing
exists,
then
I'd
be
dubious
about
the
wisdom
of
taking
investing
the
time
and
turning
it
into
rfc
format.
If
it's
already
perfectly
good,
if
it
doesn't
exist,
that's
I
was
a
little
worried
what
you
said
to
be
honest
there.
Well
it's
kind
of
here
and
there
and
you.
F
Know
it's
that's
boring,
I
would
say
it's
three
documents
is,
is
what
it
is.
There's
not
an
all-in-one
spec.
If
you
want
for
like
a
what
you
would
see
in
in
a
video
specification
like
we
might
have
for
av-1
or
264
things
of
that
nature.
It
is,
we
have
a
container
reference
and
then
we
have
as
part
of
it.
The
lossy
compression
is
vp8.
K
F
We
have
a
specification
for
that
and
we
also
have
a
specification
for
the
lossless
component
of
the
of
the
format.
So
really
the
the
effect
of
the
draft
is
that
it
gathered
those
bits
of
information.
Together,
though
they
are
gathered
on
our
our
hosting
site
as
well.
A
H
I've
clicked
the
five
buttons
the
five
times.
Can
you
hear
me
now?
H
Okay,
thank
you.
So
I
think
it'd
be
it's
not
so
much
the
stand.
The
specifications
for
the
the
bits
inside
the
compressed
and
uncompressed
bits,
but
the
definition
of
like
any
tags
or
other
attributes
that
go
along
this
last
time
I
looked.
I
couldn't
find
those
pre
very
well
defined
anywhere,
and
it
seems
that
having
those
well
defined
in
some
documents
somewhere
would
be
really
useful,
whether
it
was
just
an
informational
draft,
but
something
that
was
a
stable
reference
that
we
could
refer
that
ayanna
could
refer
to
in
in
their
registration.
H
F
You
thank
you
for
the
the
feedback
we
we
have,
some
of
the
the
format
documentation.
I
think
that's
covering
what
you
which
is
suggesting,
so
I
think
we
have
the
path
forward.
H
There
I
agree,
the
format
is,
is
well
enough
to
find
that
someone
could
implement
it.
It's
not
stable
references,
but
it's
well
enough
defined,
okay,
but
the
part
with
the
the
other
part,
but
the
other
parts
that
go
along
with
this
registration.
I'm
not
sure
that
you
do
have
them
all
defined
anywhere,
or
at
least
I
can't
find
them
so
that'd
be
well
worth
making
very
clear.
F
Okay,
yeah,
and
if
you
want
to
follow
up
on
the
the
email,
then
the
the
list,
I
can
take
a
look
into
specifically
what
you're
asking
sure.
A
Okay,
thank
you.
Thank
you
thanks
very
much
james
for
bringing
your
work
to
dispatch
we'll
roll
on
to
our
next
presentation
now-
and
this
is
nicer
nice
eyes
based
on
rtt,
so
harold.
N
Hello
in
a
while
and
just
nicer,
it
was
a
very
nice
acronym
and
it's
it's
actually
not
based
on
marketing
just
to
so
it's
also
wrong,
which
is
kind
of
traditional
for
acronyms,
but
it's
about
all
about
getting
connections
running
and
getting
getting
the
right
connection
to
to
send
packets
at
the
right
time
so
that
stuff
after
week
we've
started
sending
packets,
it
continues
so
next
slide.
Please.
N
So
the
canonical
description
from
jonas
is
about
when
he
comes
walking
back
to
his
house,
while
talking
on
the
on
the
phone
on,
of
course,
web
artists
equals
so
he
walks
up
to
his
house.
N
It
starts
getting
just
the
bare
connection
to
the
right
to
the
wi-fi
in
the
house
and
brings
up
the
interface
gets
the
address
and
the
edges
get
gets
trickled
to
his
his
connection,
and
it
says:
oh,
that's,
a
wi-fi:
it's
not
cheaper
than
4g,
so
I'll
switch
over,
so
he
walks
a
bit
closer
and
it
actually
becomes
strong
enough
to
be
usable,
and
then
he
starts
the
path
curves
around
the
corner
of
the
house.
N
N
N
The
basic
idea
of
nicer
is
that,
rather
than
throwing
away
all
these
other
paths,
you
keep
them
around,
at
least
if
you
suspect
that
they
might
come
in
handy
and
aren't
just
alias
of
the
same
path
in
order
to
keep
them
around.
You
got
to
keep
probing
them
ping
ping
ping
ping,
because
the
path
that
isn't
working
anymore
isn't
terribly
good
and
when
one
path
deteriorates
in
quality,
so
that
you
suspect
that
another
part
is
better.
N
What
we
think
based
on
experience
is
that
if
we
have
these
three
things
standard,
we
think
that
any
nice
controller
nicer
controller
endpoint
should
be
interoperable
with
any
controlled
endpoints
and
the
actual
tricks
and
treats
and
optimizations
be
left
as
a
matter
of
local
implementation.
We
don't
have
to
standardize
those
next
slide.
N
N
N
N
You
have
to
adapt
to
what
actually
is
happening.
On
the
connection
I
mean,
if
things
are
varying
very
quickly,
as
observed
in
different
rtt's
different
timeouts
different
loss
rates
for
different
things,
that's
a
an
indication
that
you
should
be
pinging
more
frequently
to
figure
out.
When
are
we
stable?
N
If
some
interface
is
expensive,
you
probably
don't
want
to
ping
it
so
often
and
of
course,
when
you,
when
you
switch,
might
account
into
rtt
ping
failure
rate
and
whether
whether
you're
paying
unlimited
data
on
your
on
your
4g
or
whether
you
have
dollars
per
gigabyte
lots
of
things,
you
could
think
take
into
considerations,
but
these
don't
have
to
be
standardized
next.
N
There
are
some
tricks
learned.
I
mean
this
technique
is
actually
being
used
in
google's.
What
is
it
a
third
or
fourth
level
communications
tool,
duo
which
is
kind
of
based
on
webrtc
standards,
but
it
does
something
else
too.
N
N
N
When,
when
you
switch
three
megabits
video
call
onto
a
connection
that
had
a
16,
kilobit
ping
and
and
handle
left
at
it,
you
might
get
congestion,
so
the
bandwidth
management
needs
to
integrate
with
nicer
so
that
you
stop
off
back
off
and
don't
use
that
much
bandwidth
until
you're
sure
you
have
it
next
slide.
N
N
And
it
is
a
great
way
of
learning
learning
from
experience.
What
to
that.
Your
theory
is
is
flawed,
so
that's
one
of
the
places
where,
where
the,
where
the
bunching
of
pings
came
from
next
slide,
so
I
pushed
this
on
to
the
itf
again,
because
I
think
that
the
world
would
be
a
better
place
for
the
if
every
everyone
was
was
nice
and
compatible.
N
You
might
say
that
okay
you're
doing
this,
don't
tell
anyone
or
tell
people
make
an
ic
ise
document
or
whatever
document
it
in
public.
It
could
be
a
small
good
idea.
It
is
sponsored
probable
standard
or
such
a
big
good
idea
that
there's
a
an
existing
working
group
or
a
new
working
group
that
should
take
this
on.
A
O
Sure,
hi
harold,
I
think
it's
a
small
but
useful
idea.
We've
had
a
couple
of
shots
at
this
before
one
was
turn
mobility,
which
is
I've
seen
you
for
a
similar
purpose,
basically
keep
it
turn
candidate
alive
and
switch
over
just
move
it
to
a
different
interface
or
something
that's
that's
used
frequently
another
one
is
you
know.
I've
always
found
it
odd
that
when
you
actually
nominate
something
these
other
alternative
candidates
go
away,
whereas
before
nomination
you
know
you're
able
to
switch
at
any
time.
O
So
I've
always
found
that
a
kind
of
an
odd
sort
of
a
weird
contradiction
that
the
things
you
describe
are
possible
until
a
certain
point,
but
then
they
become
impossible.
It's
never
been
really
clear
to
me
why?
Why
that's
required
that
that,
basically,
you
you
stop
being
able
to
switch
at
any
time.
O
For
those
those
are
my
comments
I
mean,
I
think
this
should
have
been
something
like
this
should
have
always
been
part
of
ice,
and
I
think
people
have
been
making
it
part
of
ice
for
years
by
kind
of
less
standardized
ways
of
doing
things
so
which
don't
always
work,
so
I
think
of
it
as
basically
taking
something
that's
already
out
there
and
trying
to
make
it
interoperate,
specifying
it
somewhat
better,
but
it's
not
like
it
doesn't
exist.
It's
existed
in
various
forms.
E
Hi
harold,
so
I
guess
I'm.
I
think
I'm
unable
to
answer
this
question
because
I'm
still
trying
to
work
out
what
the
thing
that's
being
standardized
is.
So
I
guess
I
I
guess
for
some
things
I
think
I
can
tell
you
definitely
a
wrong
answer,
which
is
do
not
ask
for
an
80
sponsor
for
standard.
E
I
I
guess
I
can't.
I
think
I
can't
tell
the
other
ones.
It
doesn't
sound
like
it's
a
big
idea,
but
I
can't
I'm
not
quite
sure
yet.
I
guess
I
have
some
technical
thoughts
on
it,
but
I
think
I'll
spare
people,
those
in
the
interest
of
maybe
trying
to
get
some
sharpness
on
what
what
exactly
you
think
needs
to
be
documented
by
itf
and
then
maybe
give
you
a
better
answer
where
I
should
go.
N
E
E
As
a
as
as
a
now,
I
will
share
a
comment,
which
is
that
I
think
you
can,
I
think,
you're
saying
a
little
better
than
keeping
all
the
connections
open
because,
like
they're
going
to
be
like
you
know,
it's
not
like
you,
you
know
necessarily
want
to
keep
the
turn
connection
open
at
the
same
time
like
like
this
is
like
kind
of
slow
to
keep
that
up
so,
but
presumably
that's
something
that
could
be
dealt
down
in
a
in
some
extension.
N
But
what
I
found
is
that
there's
a
lot
of
scenarios
out
there
and
limiting
limiting
this,
the
limiting
ourselves
to
us
to
a
specific
subset
is
problematic,
but
there
are
so
where
it's
really
stupid
to
keep
multiple
connections
open
like
if
you
have
six
ipv6
addresses
connecting
to
six
other
ipv
visa
guys.
That's
36
addresses
36
pairs,
usually
one
of
those.
E
Right
so
it
sounds,
it
sounds
like
we're
in
agreement.
There's
some
work
to
do
here
to
specify
what
those
things
are
that
we
could
have
a
working
group.
A
P
Okay,
can
you
hear
me
harold
all
right
excellent?
So
I
think
it's
very
interesting
draft.
I'm
also
not
sure
I
know
what
answer
I
think
is
the
right
answer
to
these,
but
I
will
say
it:
it
seems,
like
you've
tried
hard
to
build
something
that
minimizes
the
amount
of
changes
required
for
the
thing.
P
That's
not
the
controller,
but
that
answer
is
not
zero
like
it
does
require
some
changes
and
as
soon
as
you
do
that
you
have
the
traditional
problem
of
a
you
know,
a
network
effect
protocol
change
where
you
need
everyone
to
upgrade
or
a
lot
of
people
upgrade
before
this
comes
useful.
In
that
regard,
I
sort
of
feel
like
it
doesn't
quite
go
far
enough
delivering
a
set
of
tools
in
the
toolbox.
That
would
help
you
deal
with
this
problem.
P
So
the
obvious
gap
to
me
seems
to
be
there's
nothing
here
about
using
multi-path
to
actually
send
media
on
multiple
different
interfaces.
You
yourself
going
down
the
draft
you're,
not
sending
data,
makes
it
hard
to
do
things
like
bandwidth,
measurements
or
effective
packet
loss
measurements
in
an
effective
way.
So,
like
my
preference
would
be,
I
think,
there's
a
real
problem
here
that
would
be
great
to
solve.
P
I
I
think,
if
I
had
to
pick,
I
would
prefer
something
that
provides
a
richer
set
of
tools
in
the
toolbox.
So
we
have
one
solution
to
this,
rather
than
you
know,
every
little
different
bit,
someone
needs
becomes
a
separate
standard
and
then
everyone
implements
some
non-overlapping
subset
of
those
things,
and
we
have,
you
know,
continue
the
interoperable
mess
we
have
today.
P
So
so,
along
those
lines,
I
would
sort
of
advocate
for
picking
up
this
work
in
some
other
working
group,
my
music
or
whatever,
but
I
would
suggest
the
scope
of
the
problem
be
expanded
to
whatever
is
needed
to
better
support
multi-interface.
N
Yeah,
I
have
a
personal
opinion
about
multi-path,
which
is,
if
there's
a
if
there's
some
some
case,
where
it's
significantly
useful.
I
haven't
seen
it
yet,
but
usually
you
get
much
less
problems
by
having
by
just
picking
picking
a
path
and
sticking
with
it.
But
that's
something
that
that
we
could
debate.
P
So
much
is
that
you've
picked,
like
a
very
like
you've,
tried
to
minimize
the
changes
on
the
other
side
and
like
it's
one
of
these,
like
zero
one
like
as
soon
as
you
made
some
change.
You
may
as
well
put
in
enough
to
make
sure
you
don't
need
another
spec
in
the
future
and
it
feels
like
you
probably
could
do
more.
That's
what
I
mean.
N
G
Q
Hey
yeah:
this
is
not
a
new
idea,
but
it's
good
to
see
it
again.
I
think
it
really
boils
down
to
three
things
that
you
need.
You
know
some
way
to
basically
say
I
participate
in
renomination.
Q
Q
I
think
you
know,
as
you
indicate
harold,
like
there's
a
lot
of
value
in
doing
this,
I
think
you
probably
could
get
a
lot
of
the
benefits
of
like
multi-path
things,
because
the
controller
can
try
sending
different
paths
and
do
that
within
this
framework-
and
it
was
easy
to
add
things
like
yeah,
it
would
be
nice
to
expand
the
scope,
maybe
a
little
bit,
but
not
too
much
to
avoid
the
boat
anchor,
and
I
think
music
is
probably
the
right
place
to
do
this.
So
I
I
support
this
work.
A
Thank
you,
justin
colin
you're.
Next,
in
the
queue.
H
Okay,
so,
first
of
all
to
avoid
the
pun-
nice
work
like
it-
I
don't
I
mean
I
think
music
music
is
on.
This
clearly
needs
a
working
group.
Okay,
this
is
a
non-trivial
thing,
that's
gonna
branch
into
a
few
other
things
and
anytime
you
try
and
do
something
on
ice.
It's
complicated,
so
I
mean
yeah.
I
think
we
should
proceed
with
this
work.
Yes,
I
think
we
should
do
it
in
a
working
group.
H
I
don't
think
in
music
is
the
right
working
group
for
this
and
the
reason
why
it's
just
like,
I
only
know
why
we
threw
ice
there.
To
start
with,
I
mean
that's
a
long
historic
thing,
but
the
the
skills
and
everything
else
don't
even
really
align
right
with
the
other
work
going
on
in
that
working
group.
H
So
I
think
the
best
thing
for
this
would
be
to
recharter
a
new
working
group
that
was
sort
of
probably
responsible
for
ice
in
general
and
had
this
as
one
of
the
things
it
was
going
to
go,
do,
and
I
think
that
really
what
you're
hinting
at
here
is:
it's
not
it's
not
multi-path
in
the
transport
center
multi-path,
but
you're
talking
about
having
multiple
different
usable
interfaces
that
you
can
move
between
as
it
becomes
the
right
way
to
do
them
and
how
to
you
know,
improve
the
user
experience.
H
I
think
we
should
form
a
working
group
responsible
for
solving
all
the
beats
and
pieces
to
make
that
happen
in
ice,
which
this
is.
This
is
part
of
the
story,
but
not
everything.
So
I
I
favor
creating
a
new
working
group
to
go.
Do
this
and
that's
what
I
I
think
is
the
best
way
to
proceed
on
this
one.
H
Maybe
it
might
just
be
it's
a
whole
new
thing,
that's
totally
different.
That
has
to
do
purely
with
media
that
the
like
for,
for
you
know
if,
in
the
webrtc
context,
we
have
multiple
media
paths
and
any
given
one
point
in
time,
one
of
them's
active,
maybe
we
have
some
hope
of
a
make
before
break,
maybe
effect
could
be
over
one
and
not
over
the
other.
I
mean
you
know
none
of
the
other
solutions.
I've
seen
for
this
really
solve
the
make
before
break,
which
creates
a
hideous
user
experience,
and
we
have
real
this.
H
The
work
you're
talking
about
here
really
leads
exactly
to
that
type
of
solution.
Where
you
could
do
make,
I
mean
you
even
said
it,
you
know
switch
before
it's
broken
right
switch
when
it's
getting
bad,
not
before
it's
broken,
so
I
think
you're
opening
up
a
can
of
worms
here
which,
which
would
make
a
better
user
experience
than
anything
else.
We've
had
is
a
great
chunk
of
work
for
us
to
take
on,
and
do
it's
really
close
to
what
we
already
have
today.
H
So
it's
within
striking
distance
of
solving
it,
but
I
don't
think
it's
just
as
simple
as
the
few
as
the
bullet
points
you
have
in
this
draft.
I
think
that
these
are
part
of
the
tools.
You
need
to
be
able
to
achieve
that,
in
fact,
a
big
part,
but
not
the
full
thing
so
again,
I'd
favor,
a
new
working
group.
R
All
right,
yeah,
so
yeah,
I
think
you
know
these.
There
are
some
good
requirements
here,
but
also
some
complicated
problems,
mostly
about
how
the
controlled
endpoint
gets
to
have
any
control,
which
is
perhaps
contradictory,
which
is
the
problem
so
yeah,
and
I
think
I
I
think
you
know
that
that
music
has
took
ownership
device
back.
But
on
the
discussion
here
I
agree.
It's
and
music
is
a
little
too
much
of
a
grab
bag
and
either
resurrecting
the
ice
working
group
or
some
new
name
with
a
you
know.
R
People
are
coming
up
with
various
clever
acronyms
and
you
know
clever
names
which
they
can
reverse
engineer
acronyms
for
but
yeah
something
some
working
group
to
do.
Various
extensions
and
then
have
device
would
probably
be
a
good
idea.
Okay,
yeah.
I.
R
S
Yeah,
I'm
just
going
to
say
that
some
of
this
stuff's
going
to
be
coming
up
at
the
side
meeting
fight
tomorrow.
I
don't
know
when
that
is
yet,
but
apparently
an
announcement
should
go
out
to
the
list.
The
meeting
list
today.
S
S
That's
a
really
difficult
thing:
if
you've
got
information
going
through
tunnels
that
are
on
fixed
ip
addresses
and
you're
choosing
the
nearest
one,
that
gives
you
something:
that's
more
stability
and
so
you're.
Looking
at
these
six
things,
comparing
them
to
things
as
a
static
things
that
are
static
to
the
other
sticks
thing,
and
it
can
get
you
around
that
problem,
I
believe
so
it
might
be
that
onion
routing
will
solve
problems
instead
of
introduce
them.
But
anyway,
as
far
as
dispatches
go,
I
think
we
need
a
new
working
group.
A
Okay,
thank
you
very
much.
We
have
to
cut
it
there.
I
think
we
had
a
lot
of
support
for
the
work
being
done,
but
the
question
is
whether
it's
a
new
working
group
or
m
music,
so
we'll
revisit
all
of
the
dispatch
results
at
the
end
before
we
get
into
our
area
meeting,
but
I
think
we're
hearing
support
for
the
work.
It's
just
a
question
of
where
okay.
Thank
you
very
much
harold
and
we'll
move
on
to
john's
present.
T
T
T
Another
big
problem
is
that
security
description
use
so-called
plaintext
keys,
so
the
keys
often
end
up
in
log
files
and
data
retention
systems,
and
these
system
have
have
lower
security
and
a
lot
more
people
have
access
to
them
than,
for
example,
lawful,
intercept
systems
and
getting
access
to
these
keys
gives
the
opportunity
to
decrypt
the
voice.
Calls
it's
not
a
good
idea
to
store
your
keys
in
a
text
file
then.
T
T
Next
slide,
and
in
many
cases,
even
if
the
there
is
an
encapsulating
security
protocols,
this
might
not
have
enough
security
by
today's
standard,
for
example,
it
might
not
use
the
hellman
key
exchange
and
not
offer
tfs,
meaning
that
an
attacker
in
case
of
key
leakage,
which
can
happen
in
a
large
number
of
different
ways
and
has
happened
in
a
large
number
differently.
An
attacker
can
decrypt
calls
current
in
the
past
and
and
or
in
the
future.
T
The
situation
is
maybe
best
summarized
by
hacking.
As
this
analysis,
which,
right
that
false
sense
of
security
might
be
more
dangerous
than
simply
leaving
your
voice
called
unencrypted.
T
Yes,
this
gives
a
false
sense
of
security,
which
is
what
nsa
recently
said
about
tls
1.0,
which
is
now
forbidden
to
negotiate
new
systems
and
recommendations
like
webrtc
perk
and
the
bcp8862
mandate,
support
of
the
etl
srtp
and
webrtc
for
good
reasons
for
bids
and
in
negotiation
in
support
of
estes
the
alternative
and
best
current
practices,
of
course,
gtls
with
a
good
profile,
meaning
fmro,
the
helman,
aad
and
so
on.
T
Then
you
get
a
good
security
level,
you
know
what
you
get
and
you
probably
it
provides
good
security
against
the
key
leakage.
Next
slide.
T
To
summarize,
stp
security
description
does
not
at
all
offer
the
security
level
expected
by
an
enforced
itf
proposed
standards
report
standard.
There
are
also
alternatives,
namely
dtlssotp
ddls
srp
is
supported
by
many
devices,
implementation
and
libraries.
I
think
the
question
is
not
if
yes,
test
should
be
phased
out
long
term,
but
rather
how-
and
this
will
take
time,
so
we
should
begin
as
soon
as
possible.
T
The
current
drafts-
yes
to
make
yes,
this
historic
and
obsolete
the
rfc
here-
also
note
that
that
estes
is
not
recommended
that
existing
deployments
should
mandate,
support
of
dtl,
srtp
and
long-term
phase
out
is
then,
if
it's
known
that
other
endpoints
support
ptlsssrtp,
you
must
not
negotiate
estes
or
offer
estus.
If
it's
unclear,
you
should
offer
both
for
a
transition
period,
a
new
deployment
should
forbid.
Yes,
then
the
next
question
is:
where
should
this
then
be
done?
T
Yes,
this
was
standardized
in
music
would
be
normal
to
do
the
work
there.
One
thing
one
reason
why
you
might
consider
something
else
is
that
their
music
doesn't
typically
do
any
security,
but
I
think
this
is
not
the
security.
The
security
weaknesses
are
well
known.
The
what
needs
to
be
handled
here
is
how
to
handle
the
loan
term
transition
to
world
without
justice.
A
H
Okay,
so
I
think
this
needs
a
bunch
more
discussion
of
people
that
are
more
involved
with
us
before
we
make
that
decision.
I
do
think
that
it
would
be
great
to
be
able
to
have
a
replacement
for
s-desk.
I
don't
think
we
have
a
great
one
right
now,
so
can
we
go
back
to
your
first
slide?
First,
I'd
like
to
go
through
a
couple
of
these
points.
H
H
T
H
So
you
know
similarly
with
some
of
these
other
ones.
I
think
that
though
they're
understood
they're
they're,
they
are
worked
around
and
we
don't
have
a
good
alternative.
Go
to
your
next
slide
for
a
second
we'll
talk
about
the
alternative
for
a
second,
so
you
know
one
of
the
things
that
we
will
try
and
do
security
proofs
about
these
systems.
Sdas
is
very
easy
to
do
the
security
proofs
with
and
yes,
it
is
like
any
other
token
that
we
use
in
a
web
context.
You
have
to
be
careful.
H
H
Now,
I'd
like
to
have
something
better
but
detail,
srtp
forces
us
to
a
centralized
thing
where
our
private
keys
are
lying
around
on
cloud
servers
that
allow
a
lot
of
this
to
happen,
which
is
even
worse.
So
let
me
just
go
to
this
other
thing
here.
This
false
sense
of
security
might
be
more
dangerous
than
simply
leaving
your
voice
calls
encrypted.
Do
you
believe
that
hey
colin
I'm.
G
G
Should
focus
on
that
like
yeah
like
where
are
the
the
correct
experts
gathered
to
have
this
discussion
because
I
don't
think
they're
in
dispatch
collectively?
That's
that's
just
why
I'm
not
saying
we
need
to
adopt
and
work
on
this
work
but
like
where
are
where's
the
collective
wisdom
to
make
that
decision.
H
It's
actually
my
key
so
deployed
much
wider,
and
you
know
that
so
the
most
widely
deployed
alternative
on
this
is
something
the
authors
of
this
draft
have
a
patent
on
which
isn't
disclosed
in
any
of
this
right,
and
you
know
like
so
there's
some
pretty
there's
a
lot
of
considerations
in
this,
but
I
think
we
need
to
have
a
much
broader
discussion
between
people
actually
use.
These
systems
have
worked
with
the
security
of
this
before
we
sort
of
get
down
to
dispatching
this
yeah.
T
So
to
answer
your
question:
yes,
I
think
this
is
quite
good
description,
as
this
gives
in
many
cases
gives
a
very
false
assumption
of
false
assumption
of
security.
I
think
the
security
proofs
of
estes
is
easy
to
make
because
they
make
assumption
that
doesn't
not
hold
in
reality
and
these
keys
of
them.
T
H
The
the
issue
is:
what's
the
alternative?
That's
better
right,
and
I
think
that
that's
like
I'm
all
for
us
doing
some
work
on
something
that
works
better
and
involve
mls
keying
for
srtp
calls.
Okay,
that's
what
would
be
better
and
I'd
be
all
for
doing
that,
but
we
don't
have
that
yet
and
obviously
I
don't
believe
perk
will
ever
be
widely
deployed.
So
that's
not
an
answer
right.
So.
H
V
Okay,
hi
everybody.
I
think
the
please.
Let
me
know
if
you
can
hear
me,
but
my
issue
is:
there
are
serious
problems
with
what's
proposed
to
be
as
alternatives
like
they
don't
solve
all
the
possible
cause
scenarios.
V
I
think
in
general
what
makes
sense
is
to
start
a
group
which
will
be
responsible
for
a
replacement
for
sds
srtp
so
that
there
is
a
new
security
protocol,
be
that
dtls
or
tpp,
with
necessary,
updates
or
something
new
which
actually
addresses
all
the
call
scenarios
for
ssrtp
before
we
actually
deplete
depreciate
deprecate.
That
so
that's
my
suggestion.
V
Just
to
have
probably
to
have
a
new
group
which
is
dedicated
for
essentially
whatever
is
the
replacement
for
secure
rtp
protocol,
which
is
future
proof,
and
once
it's
in
place
deprecate
things
that
we
consider
unsecured
and
again
a
lot
of
things
that
calendar
brought
up
are
consideration,
and
you
know
it
requires
a
lot
of
work
before
something
else
before
we
can
just
essentially
dismiss
as
the
ssrtp.
O
O
O
Having
worked
on
sip
trunking,
it
took
an
enormous
amount
of
time
before
we
even
had
secure
signaling
and
estes
deployed
I've
after
I
think
step
four
and
worked
on
this
like
10
years
ago,
and
I've
only
been
able
to
get
secure,
sip
trunks
in
quantity
like
in
the
last
year
so
and
for
those
kind
of
scenarios
like
hipaa.
Actually
estes
works
very
well
and
I
would
argue
against
many
of
the
security
arguments
that
are
described
here,
because
all
you're
really
trying
to
do
is
just
get
a
hop
by
hop.
O
You
know,
security
on
the
path.
Many
of
the
phones,
for
example,
can
upgrade
to
something
like
dtls
srtp.
You
know
going
against
their
pbx,
but
the
big.
The
big
issue
is
that
hop
up
to
the
carrier
on
the
sip
trunk,
and
I
can
tell
you
that
I
wouldn't
be
in
favor
of
anything
that
a
carrier
is
not
willing
to
deploy
and
their
bar
is
very,
very
high.
It's
taken
them
enormous
amounts
of
time
just
to
get
estabs
into
their
sip
trunking
offerings.
E
Hi,
john
thanks
for
bringing
this
up.
I
I
think
this
is
like,
as
I'm
saying
in
the
chat
you
know,
I
think,
like
it's
disappointing,
that
no
one
said
this
before
and
that
we
were
all
too
lazy
and
you
were
not
so.
Thank
you
again.
I
I
I
think
it's
clear
like
as
dez
is
like
a
nightmare.
E
E
That
that
the
point-to-point
thing
like
these
accessories
does
not.
I
certainly
agree
that,
like
you
know,
there
are
settings
in
which
the
usb
does
not
do
what
you
like
to
do,
and
hence
the
interest
in
mlss,
rtv
and
and
things
like
it.
But
my
goal,
my
impression
from
going
through
these
is
this-
does
also
not
solve
those
problems.
It's
just
that
they're
both
kind
of
inadequate,
so
it
does
seem.
E
I
agree
that
deprecation
with
alternatives
is
bad,
and
I
certainly
like
easily
prepared
to
believe
that
there
are
things
that,
for
one
reason
or
another,
a
point-to-point
solution
like
digital
hustler
to
be
does
not
does
not
address,
and
we
should
like
figure
those
out
and
figure
out
how
to
fix
them
or
or
hand
wave
in
some
other
direction.
E
I
originally
kind
of
hoped
we
could
deal
with
this
by,
but
by
just
like
cramming,
this
document
through
which
like,
but
but
I
think
that
probably
the
situation
is
that
there's
enough
installed
base
that
we
probably
have
to
at
least
give
people
a
roadmap
for
how
to
get
out
of
it,
how
to
get
a
hold
of
currently
and
which
I
think
you,
you
kind
of
you
know,
indicated
that
earlier.
So
I
think,
probably
a
new,
a
new
working
of
some
kind,
you
know,
probably
is
necessary.
E
At
least
I
mean
at
least
that
roadmap,
and
that
would
also
be
an
opportunity,
I
think,
to
you,
know
to
to
to
to
understand
colin's
objections
and
and
their
validity
further
and
figure
out,
which
ones
are
important
weapons
or
not.
E
I
think
that
a
you
know
that
I
I
didn't
hear
anybody
speak
against
the
idea
that
we
should
get
rid
of
expeditiously
once
we
actually
agreed
that
we
covered
all
the
use
cases,
and
so
I
think
you
know
maybe
that's
like
a
long
word
and
maybe
it's
a
short
road,
but
that
would
function
that
working
group
would
be
established
that
so
I
I
would
be
in
favor
of
forming
a
working
group
with
the
intent
of
deprecating
as
des
and
then
with
any
luck.
E
A
Very
much
enter
everyone
in
the
queue
thanks
very
much
for
presenting
john
we'll
discuss
dispatch
chairs
and
get
back
to
you
on
the
on
the
outcome
here.
Thank
you
for
bringing
the
work
here.
Thank
you,
okay.
So
next
it's
braun
presenting
on
the
big
file,
emailing
problem.
W
I
have
I
have
a
promise
to
make
to
you.
I
will
not
ask
for
this
to
be
dispatched
to
m
music
next
slide,
please
cool!
So
here's
the
problem
statement
and
users
want
to
send
files
to
each
other
and
emails
have
remained
limited
to
sizes
between
10
and
50
megabytes.
In
basically,
every
single
system
end
users
keep
creating
bigger
files
and
there's
no
standard
solution
for
them
to
email
those
files
to
each
other.
Next
slide.
Please.
W
W
W
So,
there's
a
few
problems
to
solve
if
you
wanted
to
be
able
to
send
large
files
via
emails.
First
thing
is
the
upload
and
being
able
to
restart
and
upload
of
a
large
file.
If
you
lose
your
network
connection,
which
still
happens
when
you're
doing
really
large
files,
I
don't
believe
there's
any
standard
here,
but
we'll
talk
about
that
later.
W
There's
also
who
owns
or
is
responsible
for
the
large
file
data
and
finally,
there's
discovering
that
this
is
an
attachment,
rather
than
just
some
inline
text,
so
put
quite
a
lot
of
content
content
in
these
slides.
If
we
look
over
the
next
three
slides
just
leave
each
one
up
for
a
few
seconds-
oh
no
sorry
I
didn't
get.
I
put
that
later
upload
a
file
so
that
I
don't
know
where
this
should
go.
W
It's
a
general
problem
for
email
that
imap
and
smtp
doesn't
support
any
restarting
of
uploads
at
all
for
jmap,
I'm
I've
got
a
draft
for
doing
blog
management
which
in
theory
you
could
upload
chunks
and
then
concatenate
them
together
on
the
server,
but
it's
horrible.
We
want
a
more
general
way
of
doing
this.
W
I'm
seeing
in
the
chat
there-
yes,
all
right,
our
next
slide
we'll
get
to
all
this.
At
the
end,
the
other
thing
is
ownership
of
the
data
with
regular
email
the
entire
contents
sent.
So
you
don't
need
to
care,
particularly
about
the
data
once
you've
sent
it.
You
can
keep
a
copy
if
you
want,
but
the
recipient
has
the
full
email
they
have
the
full
context
and
the
lifetime
is,
however
long.
They
keep
that
email
for
if
you
send
an
attached
link
to
something
that's
kept
at
your
end,
then
there's
no
lifetime
handling
on
that.
W
W
And,
as
you
can
see,
this
is
the
the
gmail.
If
you
extract
the
url
from
this,
you
can
actually
download
this
yourself
and
see
me
singing
four
different
parts
of
a
motet
and
it
all
combined
together
into
a
video
yay
all
right.
So
that's
that's
the
gmail
one.
You
can't
tell
that
that's
without
specifically
gmail
scanning.
You
can't
tell
that
this
is
an
attachment,
rather
than
just
a
random
link.
That's
ahref!
Next
one.
W
Icloud
is
even
bigger
and
again
it's
it's
got
just
a
an
href,
a
link
in
the
html
and
finally,
the
third
slide.
This
is
the
microsoft
one
and
it's
got
an
href
all
right.
Next.
W
So
there's
two
problems
with
checking
the
content
of
the
links
number
one
that
arbitrarily
following
links
from
emails
is
known
to
be
dangerous.
Sometimes
get
links,
have
side
effects,
there's
certainly
privacy
considerations
here
that
you
can.
You
can
wind
up
pulling
content
that
you
didn't
expect
you
can
wind
up
doing
letting
the
other
end
know
that
you're
reading
the
email,
unless
you
always
check,
in
which
case
you
have
the
alternative
problem-
that
it
looks
like
the
you're
always
reading
the
emails
and
so
senders
will
assume
you're
active
rather
than
timing.
W
You
out,
if
you
never
look
at
the
content
and
it's
very
hard
to
know
which
links
are
attached
files,
so
we
want
some
kind
of
solution
that
that
says
this
is
an
attached
file
and,
of
course
the
final
problem
is
that
the
content
can
change
after
you've,
the
email
has
been
received.
There's
been
a
lot
of
stuff
at
morgue
and
in
the
the
spam
scanning
community
around
the
idea
that
you
show
some
some
safe
content.
W
W
So
I
would
propose
that
the
upload
work
definitely
happens
in
one
of
the
http
groups,
because
that's
everything's
moving
towards
that
for
ownership
discovery.
I
I
think
a
new
mime
type,
which
we
can
see
in
the
discussion
in
the
chat
message.
External
content
already
exists,
which
I
wasn't
aware
of
when
I
wrote
these
slides
up,
because
this
all
all
came
together
just
in
the
last
few
days.
But
discussing
what
to
do.
There
is
going
to
be
a
question
where
it
happens:
definitely
digests
for
content,
integrity
protection,
definitely
an
explicit
expiry
time.
W
I
commit
to
hold
on
to
this
data
until
such
and
such
time
content
id
that
allows
you
to
link
the
content
from
within
the
message,
as
you
would
with
a
regular
attachment
and
an
expectation
that
the
recipient
server
keeps
a
copy
asset
virus
checks
it
and
then
retains
it
for
the
lifetime
of
that
email
so
that
it
stays
together,
and
you
have
your
immutable
message
next
slide,
I
slap
together
an
example
kind
of
thing,
but
obviously
this
is
very
much
open
for
change
and
then
the
final
slide
is
the
discussion
points.
W
A
S
Now
one
of
the
things
that
is
happening
in
that
icloud
workflow
is
that
icloud
or
dropbox
or
google
drive
or
whoever
are
actually
providing
a
role
as
a
trusted.
Third
party
and
it's
hidden.
W
S
W
Underst,
I
don't
understand
what
you,
what
the
difference
is
between
attaching
the
blob
and
attaching
something
that
has
a
some
kind
of
digest
that
authenticates
the
content
as
being
what
was
what
was
uploaded.
S
No
there's
a
difference
if
I
send
you
an
attachment
that
will
go
through
the
smtp
server
and
we'll
go
through
the
spam
filtering
and
malware
filtering
at
your
company.
S
W
X
So
I
will
do
with
bill.
If
it's
going
to
happen,
it's
going
to
be
a
working
group.
I
would
say
that
one
of
the
biggest
problems
that
we've
had
in
in
the
history
of
this
is
figuring
out
who's
going
to
pay
and
who's
incentivized
to
actually
deploy
that,
and
I
think
that's
why
most
of
the
previous
systems
have
not
worked
going
back
to
why
we
had
ftp
by
email,
and
I
I
think
that
there's
actually
three
sets
three
steps
and
I
think
that
it's
important
to
talk
about
all
three
steps.
X
There's
upload,
there's
transfer
and
there's
download
and
in
particular
one
of
the
virtues
of
email
is
it's
offline,
nature
of
it
and
one
of
the
things.
I
don't
want
to
wait
when
I
send
you
that
three
gigabyte
file
of
you
singing
is,
I
don't
really
want
to
wait
for
that
to
happen
before
I
go
on.
X
So
a
lot
of
that
has
to
happen,
and
I
may
not
even
afford
to
be
able
to
do
it
in
the
place
that
I'm
in
at
that
moment
so
and
when
you
receive
it,
you
may
not
want
to
afford
to
download
that
at
that
time,
but
you
may
still
want
it
to
happen
overnight.
I
don't
know
whatever
so
there's
a
whole
there's
a
whole
process
there
and
I
think
the
other
part
of
that
asynchronous
nature
is
that
the
network
between
my
server
and
your
server
might
not
be
very
fast.
We
really
should
be
talking
about.
X
This
is
a
delay,
tolerant,
network
kind
of
problem,
and
that's
where
I
think
we
should
be
addressing
it.
How
do
I
send
big
things
without
waiting
for
them
and
working.
A
Okay,
john
levine,
with
a
focus
on
the
dispatch
question
which
is
not
dispatching,
but
just
what
do
you
think
would
be
a
sensible
route
for
the
work.
Y
Do
say
this
is
clearly
something
people
want
to
do
with
email.
Whether
or
not
that's
you
know,
other
people
think
that's
what
they
should
be
doing
and
they're
already
doing
this,
and
that's
why
lots
of
services
are
trying
to
offer
support
for
this,
and
so
a
standardized
version
is
worthwhile.
A
Sorry,
john,
we
can't
get
your
audio,
I'm
afraid
if
you
want
to
write
what
you're
going
to
say.
A
Thank
you,
brown
for
bringing
the
problem
to
the
group,
so
we're
just
going
to
do
a
recap
of
the
dispatch
outcomes
for
this
session
before
we
move
into
the
art
area
of
the
meeting.
So
to
start
with,
all
these
outcomes
are
preliminary,
it's
quite
hard,
as
you
might
imagine,
to
take
the
mood
of
a
room
when
we
are
virtual,
but
we're
doing
our
best,
and
so
all
of
these
outcomes
will
go
to
the
list
to
be
confirmed.
A
So
for
the
first
item
on
jws
ct
the
dispatch
outcome,
we
didn't
hear
support
for
the
itf
taking
on
the
work
at
this
time,
so
dispatch
will
not
recommend
doing
so
if
the
authors
want
to
put
new,
isc
or
otherwise,
they'll
call
free
to
do
that
for
webp,
the
dispatch
outcome
got
murray,
deciding
between
expert
review
and
ad
sponsorship
and
he'll
confirm
that
on
the
list
as
well
for
nicer,
the
dispatch
outcome
was
either
a
new
working
group
or
m
music
to
be
decided
by
ads
and
then
reported
to
the
list
as
well
and
then
for
sdp.
A
We
heard
support
for
the
work,
just
not
consensus,
really
on
how
to
do
it.
So
suggestions
range
from
a
music
to
a
new
working
group
to
it's
not
ready
yet
to
someone
suggesting
a
buff
as
well
in
their
charter.
Sorry,
in
the
chat,
so
possibly
a
charter
to
discuss
further
coloring.
H
Sorry,
just
a
clarifying
question
about
that,
when
you
say
support
for
the
work,
the
work
that
was
presented
was
deprecating
estes,
so
you
mean
the
work
of
developing
a
replacement
for
us
desp,
which
I'm
all
in
favor
of
and
if
we're
forming
a
working
group
for
deprecating
estes,
then
I
like
to
think
that
that's
like
lulu
like
crazy
land,
so
I'm
trying
to
clarify
which
one
it
is.
G
Yeah,
I'm
sorry,
we
haven't
had
a
chance
to
write
it
up
and
edit
it.
So
I
I
think,
you're
correct.
That's
just
part
of
what
there
wasn't
consensus
on
was
that
whole
direction,
but
I
think
we
will
note
in
the
write-up
that
there
wasn't
consensus,
whether
doing
a
replacement
or
sorry
whether
doing
a
deprecation
without
a
replacement
was
reached.
So,
okay.
A
Great
okay,
so
we
move
into
the
art
area
of
the
meeting.
Now,
first
up,
it's
michael
richardson,
just
very
quickly
presenting
on
seller.
X
A
very
quick
next
slide,
please
spencer,
is
going
to
do
this
originally
and
I
I'm
the
co-chair.
So
this
is
just
to
let
people
know
what's
happening,
is
sort
of.
What's
going
on
atrocity
and
evml,
they
go
back
to
2002,
there's
a
lot
of
running
code.
If
you're
familiar
with
webm,
then
that
is
essentially
kind
of
fork.
X
It's
a
container
for
multimedia.
It's
widely
supported
has
a
lot
of
open
source,
but
it
has
some
issues.
They
needed
some
rough
consensus
next
slide
and
so
working
group
was
formed
in
2015
we
published
a
first
rfc,
we're
likely
to
revise
it
and
we
have
a
second
one,
which
is
for
the
codec
ffv1,
and
it's
last.
You
know
you
might
see
it
this
week
is
1943.
X
and
there's
an
ffv1
version.
4
that's
being
worked
on
and
then
the
container
format
which
is
implemented
in
terms
of
ebml,
which
is
extended,
binary,
markup
language.
We
would
have
done
it
in
cbore,
but
it
wasn't
seaboard
didn't
exist,
yet
it
will
probably
be
finished
in
2021..
X
We
don't
tend
to
have
meetings
in
person
ever
the
fourth
tuesday
of
the
month
is
our
virtual
interim,
except
in
july,
when
it's
almost
always
opposite
ietf.
So
our
next
meeting
is
the
end
of
august
and
it's
mostly
open
source
authors,
mostly
working
after
hours,
but
also
includes
archivists,
for
whom
part
this
is
part
of
their
day.
Job
next
slide,
please
what
next
well
so
ffv1.
X
This
is
why
we're
coming
to
talk
to
you
and
let
you
know
this
is
happening
because
we'd
like
to
kind
of
hear
from
you,
is,
what's
more
important
than
other
things.
People
have
a
number
of
ideas
that
they
want
to
implement
and
but
not
always
things
that
they
know
is
what's
going
on.
So
there's
a
bunch
of
things
that
I
put
on
the
slide
here
about
the
different
types
of
things.
X
So
but,
for
example,
one
of
the
things
that
you
might
not
think
of
as
video,
but
obviously
it
is-
is
radar,
infrared
images,
someone
said
heighten
age
in
temperature,
and
I
don't
really
understand
that.
So
I'm
not
going
to
explain
that
to
you,
but
apparently
that
is
also
a
thing
you
could
be
measuring
charge
or
elasticity
or
some
other
kind
of
thing.
In
some
three-dimensional
process
height
is,
I
think,
mountains
and
other
stuff
and
stuff
like
that,
and
I
can't
explain
each
and
then
people
have
talked
about
attestation.
X
I
think
the
courts
would
like
to
know
they
weren't.
There
was
no
tampering
with
and
that
they're
getting
the
real
raw
data
in
whatever
format
it
needs
to
be,
and
so
I
kind
of
invite
you
to
to
a
working
group
if
you
have
any
interest
in
that
or
if
you
have
colleagues
that
may
be
working
in
things
like
this,
please
spread
the
word
thanks.
I
think
that's
the
last
slide.
A
Z
Okay,
thanks,
you
seem
to
have
jumped
into
the
middle
there.
Could
you
get
back
to
the
beginning.
Z
Can
you
go
to
the
next
second
one
there?
So
we
did
discuss
this
before
back
in
etf
85
and
we
produce
an
rfc
for
representing
ipv6
zone
identifiers
in
uris,
and
why
are
we
here
today?
Z
That's
doing
the
reconfiguration,
so
there
are
real
use
cases
for
this,
which
are
not
for
the
general
purpose
user
that
are
for
specialists
and
there's
at
least
one
application
that
uses
linked
local
addresses
or
http
commands,
and
that's
the
cups
printing
application,
which
isn't
an
itf
standards.
But
it
is
out
in
the
real
world.
So
next,
please.
Z
R
Z
Z
So
there
are
problems
and
here's
the
sort
of
most
awkward
one.
It
modifies
the
syntax
for
uris
to
add
a
percent
25
f
0,
where
cut
and
paste
from
ping
command
would
be
percent
f
0.
It
does
that,
of
course,
because
that
is
the
way
you
encode
characters
in
a
uri
and
what
you're
encoding
is
a
percent
sign.
So
you
end
up
with
percent
25,
meaning
percent.
AA
AA
K
Z
Decided
to
fix
by
removing
a
rather
screwy
suggestion
from
the
rfc.
So
what
is
the
point
here?
The
point
is:
we've
got
some
unused,
but
useful
syntax
and
we'd
like
it
to
be
used
so
over
in
six
man.
We
can
discuss
the
details
of
how
to
make
it
more
usable,
but
then
the
final
slide.
Please,
is
why
we're
here
we
need
feedback
from
this
part
of
the
ietf.
Z
You
know
I've
gone
through
this
pretty
quickly.
There's
a
lot
more
background.
If
people
are
interested
that
that's
going
to
come
up
in
six
man
in
a
couple
of
days
time,
so
my
real
purpose
here
is
to
tell
people
that
this
is
going
on
and
to
ask
people
who
have
expertise
or
or
an
interest
in
this
to
take
notice
of
the
draft
either
join
the
six
man
discussion
or
send
us
lots
of
email
and
we'll
proceed
as
best
we
can.
So
that's
it.
K
Hi
I
raised
and
dispatched
the
question
about
at
what
point
do
we
take
on
resolving
the
difference
between
rfc
3986
3987
and
the
one
working
group
living
standard
and
which
proposes
some
extensions,
and
the
answer
I
got
was
not
yet,
but
maybe
soon
that's
how
I
interpreted
the
response,
but
I
think
if
the
problem
is
the
implementations
don't
match
your
suggestions,
then
for
you
with,
and
you
wanted
to
work
in
browsers
in
particular,
then
I'd
start
there.
K
Z
Z
There's
an
issue
there's
an
issue
open
on
their
their
issue
tracker
anyway,
so
we'll
certainly
do
that.
K
I
was
encouraged
that
someone
has
developed
a
more
ietf,
acceptable,
grammatical
specification
of
urls
that
was
compatible
with
the
webwork
group
style
of
a
parsing
algorithm
expressed
in
pseudocode
and
and
so
that
that
may
be
a
good
element
to
bridge
the
gap
between
rfc,
3987
and
3980s
and
the
where
we
style.
G
Thank
you
both
for
the
discussion.
It
sounds
like
six
man
and
brian
and
bob
are
the
ways
to
follow
up
if
you're
interested
in
this
work.
Thank
you
all.
We
have
one
left
right.
Rush.
U
Hey
everyone.
Can
you
hear
me.
U
Awesome,
thank
you
hey.
My
name
is
carol
pogen
and
this
presentation
is
about
streaming
protocol
and
the
drafts
that
we
recently
published
a
few
weeks
ago.
Next
slide.
Please
please
so.
First,
let's
talk
about
the
motivation,
so
there
are
multiple
applications
that
have
different
latency
requirements
in
live
video
streaming
world
so,
for
example,
live
streaming
or
soccer
match.
U
Users
may
be
okay
with
10
30
seconds
latency,
however
streaming
gaming
or
other
interactive
type
of
videos
would
really
benefit
from
low
latency
and
something
like
five
second
latency,
probably
even
that
is
high,
so
the
other
motivation
is
extensibility,
so
new
audio
video
codecs
support.
So
we
have
a
few
audio
video
codecs
coming
up
in
recent
years.
New
client
service
interactions,
multi-track
support,
including
captions,
is
also
one
of
the
desired
features.
Next
slide.
Please
and
the
other
really
important
aspect
is
reliability
and
so
live
streaming.
U
U
The
other
and
the
last,
but
not
the
least,
is
quality
so
having
a
better
signals
from
network
transport
to
be
able
to
adjust
your
video
bitrate
and
to
match
network
conditions
is
really
really
important.
Next
slide,
please.
U
So
there
are
obviously
number
of
existing
protocols
that
could
be
considered
rtc,
rtmp
or
any
sort
of
like
dash,
lag
or
really
like
http
based
protocols.
U
So
the
rtc,
for
example,
is
mostly
focused
on
video
calling
experience,
and
so
the
latency
is
paramount
there,
whereas
in
our
applications
we
would
really
like
to
have
a
ability
to
choose
one
or
another
and
have
a
sort
of
slight
slight
slider.
Like
experience.
Rtmp,
it's
iris
to
me
is
a
little
bit
dead
in
the
sense
that
it's
old
and
there's
no
new
codec
support.
U
Some
implementations.
Don't
support
the
connecting
dash,
doesn't
really
allow
for
frame
level
control.
So
it's
a
hard
to
control.
Latency
next
slide.
Please.
U
Yeah,
by
the
way,
the
the
other
like
like
it's,
not
a
problem
with
rtc,
but
it's
it's
a
complex
protocol,
and
so
we
were,
we
were
aiming
for.
Something
really
simple.
U
So
rush
is
a
bidirectional
application
level
protocol
designed
for
live
video
suggestions
that
runs
on
top
of
quick,
so
it's
built
as
a
replacement
for
rtmp
that
we
used
before
with
the
goal
to
provide
support
of
new
video,
codecs
accessibility
and
multitrack
support.
In
addition,
the
protocol
is
also
provides
an
application,
an
option
to
control
data
delivery
guarantees
by
utilizing
quick
streams.
U
Next
slide,
please
so
at
the
core,
the
client's
server
exchange
information
using
frames-
or
you
can
call
them
messages,
doesn't
matter,
frames
can
be
different
types
and
data
passed
within
the
frames
depend
on
the
type
the
each
frame
has
a
generic
header
format.
Next
slide.
Please.
U
So
like
length
id
length
is
tells
how,
like
the
size
of
the
data
within
the
frame
id
is
a
sequence
number.
So
every
frame
must
have
a
sequence
number
that
is
greater
than
of
the
previous
frame
within
the
same
track
and
the
type
to
identify
type
of
frames
next
slide.
Please
rush
defined
the
protocol
itself
defines
say,
frame,
seven
frame
types
are:
connect
frame,
connect,
acknowledgement,
frame,
end
of
video
frame,
error,
audio
video
and
go
away
frame
next
slide.
U
Please,
there
are
two
modes
defined,
so
rush
has
actually
defined
two
modes,
normal
and
multi-stream
mode
in
normal
mode
rush
uses
bi-directional
quick
stream
to
send
date
to
send
and
receive
data
using
one
stream
guarantee
is
reliable
in
order
delivery,
four
applications,
and
so
they
can
rely
on
transport
to
retransmit
lost
data.
U
U
So,
in
normal
mode,
client
sends
a
connect
frame
on
assuming
there
is
a
quick
connection
sends
a
connect
frame
on
bi-directional
stream
and
then
start
sending
audio
and
video
data.
U
Only
one
video
can
be
sent
on
the
on
the
same
connection.
Server
upon
receiving
the
connect
frame
send
the
connect
acknowledgement
frame
on
the
same
quick
stream,
because
frames
arrive
and
motor.
So
a
server
doesn't
need
to
worry
about
it
once
client
needs
to
indicate
that
it's
done
streaming
the
data
it
sends
end
of
video
frame
and
to
indicate
that
it's
done
and
close
the
quick
connection
next
slide,
please
in
normal
mode.
U
What
might
happen
is
that
one
of
the
frames
like
packets
for
belonging
to
one
of
the
frames
can
be
lost
and
all
frames
and
after
it
will
not
be
available
to
the
server
until
that
frame
is
retransmitted.
So
this
kind
of
variation
of
head
of
line
blocking
and
can
affect
latency
introduce
jitter
next
slide.
Please.
U
So
this
this
is
what
multi-stream
mod
is
aimed
to
solve,
so
it
addresses
height
of
line
blocking
and
also
gives
more
control
to
application
over
delivery
delivery
guarantees
in
multi-stream
mode.
Every
new
frame
is
sent
on
new,
quick,
bi-directional
stream
and
since
quick
streams
are
independent
from
each
other,
this
allows
server
to
receive
data
as
it
tries
and
not
to
wait
for
a
transmission
of
loss
packet
that
belongs
to
other
frames.
Next
slide,
please.
U
This
mode
frames
are
arrived
out
of
order,
server,
uses
frame
id
within
track
to
detect
missing
frames,
and
it's
up
to
the
server
to
restore
an
order
using
frame.
Ids
client
can
stop
retransmissions
by
resetting
the
corresponding
quick
stream,
so
it
can
set
up
timer
or
other
ways,
or
just
basically
try
to
send
data
and
then
reset
the
stream
immediately.
U
There
are
two
ways
to
two
types
of
reconnect
is
one
is
initiated
by
the
client
and
the
other
one
cheated
initiated
by
a
server
one
client
wants
to
reconnect
could
be
for
different
reasons,
either
just
connection
lost
or
a
client
wants
to
switch
from
wi-fi
to
cell
and
so
on.
So
client
just
opens
up
a
new,
quick
connection,
close
the
current
one
and
initiate
the
normal
normal
connect
flow
and
continue
sending
the
data
on
a
new
connection
next
slide.
Please.
U
So
in
server
initiated
scenario,
server
sends
a
go
away.
Method
a
client
may
send
frames,
continue
sending
frames
on
the
current
connections.
That's
usually
required
to
just
drain
the
current
gop
gop
interval
decline
then
establish
new
connection
and
continue
with
the
normal
flow.
U
It's
important
to
know
the
ceremony
close
the
connection
after
sending
go
away
frame
so
but
before
the
client
finished
sending
frames
on
the
correction
connection,
so
this
may
result
in
data
loss
next
slide,
please.
A
AB
AB
Okay,
I'm
sorry
haven't
used
this
laptop
in
a
while.
Is
it
better
now?
Yes,
okay,
so
everything
is
going
out
on
the
same
five
tuple
right
and
everything
is
encrypted
correct.
So
if
a
router,
if
a
router
wants
to
apply
different
drop
priorities
to
audio
and
video,
that's
a
problem
that
also
exists
in
webrtc.
AB
AB
A
I
think
if
we
can
encourage
you
to
take
the
conversation
to
the
side
meeting
and
sorry
we're
just
gonna,
because
we're
finishing
now
so
we've
just
run
through
the
last
couple
of
slides.
Thank
you
carol
for
coming
and
for
presenting
your
work
and
do
go
to
the
video
in
just
over
quick
side
meeting
for
more
discussion.
This
is
just
an
fyi,
and
hopefully
me
echo
is
just
hiding
the
arrow
that
I
need
to
advance
this
lives,
which
is
there.
A
We
go
so
yeah,
just
a
note
that
there
are
some
buffs
coming
up
this
week
that
you
may
be
interested
in
the
first
one
is
tomorrow:
danish
is
having
another
buff
and
oblivious
ohttp,
sorry,
oblivious,
http
or
ohttp,
and
the
medina's
work
on
wednesday
sins
on
thursday
apn
on
friday.
There's
a
new
art
working
group
tomorrow,
as
well
all
of
these
times
of
utc
and
but
that's
sedate,
which
was
a
result
of
a
dispatch
item
at
the
last
meeting
and
then
just
other
interesting
meetings,
sex
dispatches
earlier
than
usual.
A
So
it's
normally,
I
think,
on
a
thursday,
but
this
itf
meeting
it's
today.
So
do
you
not
miss
that?
If
that's
one
of
your
dispatchers
on
your
gender
there's,
also
gender
dispatch,
schmoo,
rsc,
editor,
future
development
program
and
finally,
the
iab
open
meeting
as
well
and
patrick
anything
to
kind
of
add.
G
We
had
a
really
full
agenda
and
91
slides
and
I
really
appreciate
the
dedication
people
gave
to
addressing
the
dispatch
questions
in
particular,
but
that's
great,
hopefully
we'll
all
be
together
in
a
meeting
or
two.
I
think
this
is
a
forum,
that's
definitely
easier
to
do
in
person,
but
I
really
appreciate
people
sticking
with
it.
A
That's
great,
then
yeah,
that's
the
end
of
dispatch.
Itf111,
we'll
share
all
the
results
to
the
list
and
the
minutes
as
well.
Okay,
thanks,
everyone
have
a
great
itf.