►
From YouTube: IETF-MOQ-20230607-1500
Description
MOQ meeting session at IETF
2023/06/07 1500
https://datatracker.ietf.org/meeting//proceedings/
D
B
D
D
B
A
Okay,
so
welcome
everybody
to
the
interim
working
group
meeting
for
the
mock
working
group.
This
session
is
being
recorded.
It's
will
eventually
turn
up
on
YouTube,
but
it's
being
recorded
by
the
media
Co
system,
even
as
we
speak
here
is
the
note.
Well,
if
you
are
not
familiar
with
the
ITF,
then
it
will
give
you
the
pointers.
You
need
to
understand
the
consequences
of
participation
both
for
your
IPR
responsibilities,
primarily
about
disclosure
and
the
personal
code
of
conduct
that
we
kind
of
expect
how
people
should
behave.
F
A
We
are
in
the
administrivia
portion
of
it
and
the
next
bits
are
going
to
go
through
the
new
candidates
for
working
group
drafts.
The
transport
overview
presentation
will
be
Cullen,
then
Victor
will
do
a
deep
dive
on
the
namespaces
names
and
uniqueness.
We'll
we'll
talk
about
a
draft
that
shows
you
how
to
use
media
over
this
set
of
transports
and
then
Luke
will
go
through
example,
flows.
What
it
just
looks
like
distribution
like
conferencing,
then
there's
a
big
whack
of
time
for
discussion
about
well
almost
an
hour.
B
A
Hearing
on
the
next
bit
of
administrative
Is,
We
I
still
have
not
seen
anybody
volunteer
to
be
a
note
taker.
So
if
there's
anybody
who's
here,
who
can
just
record
what
our
decisions
are?
That's
that
would
be
very
handy
again.
We
we
do
have
the
recordings.
We
don't
need
a
you
know.
Martin
said
this:
Luke
replied
that
Mo
responded
with
something
else.
This
is
just
a
high
level.
The
group
Matt
discussed
this
level
of
notes.
If
anybody
can
take
that
we'd
appreciate
it.
D
Sort
of
I
am
in
the
headstock,
and
I
am
I
at
least
copied
the
agenda
into
it,
but
I
am
I,
have
I
will
not
be
doing
well.
If
I
am
the
only
Note
Taker,
so
I
would
suggest
that
at
least
a
couple
of
people
join
in
there
with
me
so
that
I
don't
zone
out
and
if
the
chairs
could
say-
and
you
know,
and
so
what
the
nose
needs
to
say
is.
That
will
be
very
helpful
for
me.
G
A
A
I
always
like
bribery
in
the
form
of
chocolate.
He
said
clarifying
for
the
record
to
to
the
note
takers.
The
chairs
are
in
favor
of
chocolate
is
what
you
should
write
down
and
and
with
that
first
comment
to
the
Nokia
takers.
I
think
we're
now
out
of
administrivia
and
over
to
transport
overview
and
that's
Cohen.
D
C
So
I'm
going
to
be
talking
about
just
sort
of
the
the
high
level
picture
of
the
mock
transport,
which
is
you
know,
sort
of
a
key
draft
sort
of
ties
things
together
here
and
it's
a
little
bit
weird
for
me
to
be
talking
about
this
I'm.
Not
one
of
the
authors
that
this
represents
I
have
helped
do
some
of
the
work
on
it,
but
this
you
know,
really
comes
out
of
a
combination
of
a
bunch
of
things,
but
mostly
out
of
Luke's
warp
draft
and
and
that
splits
some
stuff
apart.
C
So
over
the
past,
you
know,
since
the
last
ITF
meeting,
there's
been
a
ton
of
energy
by
a
bunch
of
people
to
try
and
split
these
apart,
get
some
modular
models
really
get
this
narrowed
down
to
the
part
that
everybody
agrees
on
and
get
this
to
a
a
state
that
we,
we
think
is
adoptable,
so
I'm
going
to
be
explaining
this
and
then,
at
the
very
end,
talking
a
little
bit
more
about
why
I
think
this
is
a
pretty
good
job,
pretty
good
shape
to
be
adopted
by
the
working
group.
So
next
slide.
C
C
There
it
came
up
so
just
going
to
hit
on
reminding
people
that
we
have
a
lot
of
different
goals
for
all
of
this
work,
and
you
know
combining
together,
lower
latency,
better
scalability,
unified
protocol
for
ingest
and
distribution,
and
these
aren't
all
the
goals
for
the
working
group.
But
these
are
the
goals
that
really
hit
this
this
particular
piece
in
the
layer
and
where
I'm
going
to
talk
about
it
and
a
lot
of
these
things
are
why
we
ended
up
with
some
of
these
things
designed
the
way
they
are
in.
C
This
draft
is
to
sort
of
simultaneously
meet
the
needs
of
all
the
different
sort
of
groups
that
are
coming
together
to
try
and
bring
these
things
in
the
same
time.
So
with
that
jumping
on
to
the
next
slide
here,
foreign
you're
going
to
see
various
versions
of
this
slide
today,
through
you
know,
from
from
Luke
from
Will
from
other
people,
mostly
better
than
my
version
of
it.
But
I
want
to
just
sort
of
put
where
the
mock
transport
fits
in
this
space
Okay.
C
C
So
what
the
mock
transport
draft
does
at
this
point
is
it
allows
you
to
sort
of
say,
I'm
going
to
talk
about
what
a
track
is
later,
but
you
know,
I
want
to
receive
this
track
or
I
want
to
send
this
track
or
I
have
this
many
tracks?
It
doesn't
talk
about
what's
in
the
tracks,
what
the
tracks
mean
all
of
those
things
that
happens
at
the
streaming
formats
layer
where
you
might
be
using
cmaf
related
stuff
and
some
various
things
or
other
ways
of
doing
it
to
say
the
details
of
this.
C
But
this
is
about
how
you
move
the
bits
of
the
track
and
say
what
you
want
now
it
sits
directly
on
top
of
web
transport
or
raw
quick,
and
you
know
that's
the
thing.
That's
actually
more
like
a
transport,
it's
giving
you
the
congestion
control,
the
security
of
those
things,
even
though
we
call
this
mock
transport
and
really
none
of
those
are
transports.
C
Udp
is
the
transport
it's
all
sitting
on
top
of,
but
when
we
say
mock
transport
here
we
mean
something
that's
sitting
on
top
of
the
web
transport
and
quick
and
it's
exposing
to
the
layers
above
it
a
way
to
sort
of
name
and
ask
for
media
and
get
and
receive
media
both
for
all
the
very
variety
of
use
cases.
So
next
slide.
C
I'm
going
to
jump
in
a
bit
of
terminology
here
so
I'm
going
to
take
this
simple
ingest
case.
On
the
left
hand
side:
you
know
you
got
somebody
some
device
with
a
camera
and
yeah
it's
sending
media
off
to
somebody
off
to
some
server
in
the
cloud.
Now
we
use
the
words,
client
and
server
a
bunch
and
client
and
server
we
mean
in
very
much
the
you
know,
quick
meaning
of
these
words.
Okay,
it's
it's
like
the
TLs
and
quick
meaning
of
them.
C
The
the
client
is
the
thing
that
initiates
the
connection
to
the
server
okay,
that's
that's
all
we
mean
by
client
and
server,
and
you
know
for
the
ingest
case.
We've
got
that
going
up
that
way.
The
distribution
case
too.
It's
still
the
client
that
connects
to
some.
You
know:
media
provider
server,
that's
going
to
give
us
up
so
the
other
terms
we
use
are
producer
and
consumer,
so
producers
producing
media
consumers
consuming
media,
the
media
flows
in
that
general
direction.
C
C
That's
not
what
we're
specifying
we're
specifying
between
the
you
know
the
the
devices
out
on
the
edge
how
they
connect
up
to
this
set
of
relays,
so
the
sort
of
producer
to
the
relay.
On
the
other
side,
there
are
some
devices
with
screens
that
are
also
connecting
to
the
same
relay
other
relays,
whatever
okay,
so
server.
You
know
the
server
client,
the
client
server
terminology
here
is
the
same,
and
also
the
producer
consumer
is
like
the
screens
over
here
consuming
media
the
producer
with
the
cameras
producing
the
media
next
slide.
C
Now
the
this
doesn't
stop.
Obviously,
in
like
the
video
conferencing
case,
you're
both
a
producer
of
media
and
a
consumer
of
media,
and
that's
fine
you're,
just
you're
producing
different
tracks
and
you're
consuming
different
tracks.
It's
all
fine
and
there
could
also
be
other
elements
in
the
system
that
were
also
producers
and
consumers.
Like
I
wrote
a
transcoder
on
this
one
as
it's
not
like.
The
protocol
describes
a
transcoder
or
anything.
C
The
protocol
describes
how
a
producer
and
consumer
can
send
media
to
each
other
so
that
the
transcoder
is
getting
media
from
a
lot
of
the
producers
and
then
producing
some
own
media
itself
that
that
other
consumers
do.
That's
all
fine.
That's
like
that's
an
application
that
happens
outside
of
this,
and
we
support
that
type
of
use
case
fine,
but
we
don't
need
to
talk
about
it,
deeply
other
than
the
producers
and
consumers.
So
next
slide.
C
So
I
need
to
talk
about
the
model
of
what
we're
moving
around
and
there's
I
want
to
not
confuse
this
with
it,
the
streaming
media
layer
layer,
you
know
later
Will's
going
to
be
talking
about.
You
know
how
there's
a
ranging
of
catalog
and
cmaf
and
fragments
and
sort
of
Direct
Media
objects
at
the
transport
layer.
We
that
this
mock
transport
layer.
We
don't
really
know
about
those
things.
What
we
know
about
are
tracks
tracks
would
probably
contain
and
carry
in
in
some
form
or
another
media.
C
It
could
be
video,
it
could
be
audio,
it
might
be
text
media.
It
could
be
something
totally
not
I
mean
like
this.
This
protocol-
you
could,
probably
you
know,
I,
don't
know,
maybe
you
could
use
it
to.
You
know,
distribute
haptics
information
for
for
something
else
or
text
information.
It's
not
we're
really
talking
about
how
to
organize
the
data
into
a
model
and
move
it
around.
We
don't
care
deeply.
What
the
data
is
at
this
level.
C
The
groups
form
join
points.
So,
basically,
when
you
want
to
start
receiving
a
track,
you
can,
you
can
start
getting
the
latest
group
and
all
the
information
in
that
group
of
it.
So
the
groups
are
information
that
you
might
need
earlier
information
in
the
group
to
be
able
to
decode
it.
We
try
and
make
the
groups
be
that
they
only
that
each
group
is
all
the
data.
All
the
objects
in
a
group
are
D.
You
can
decode
them
and
understand
what
they
mean.
C
You
can
feed
them
through
a
video
Codec
and
decode
and
get
something
out
of
them
using
only
the
informations.
That's
in
that
group,
they
don't
depend
on
objects
in
different
groups.
Now,
there's
some
caveats
to
that:
we
get
scalable
codecs.
That
may
not
be
exactly
true.
You
can
talk
about
whether
lip
sync
violates
that,
but
for
the
most
part
we
sort
of
think
of
these
things
as
being
an
independent
coding
of
information.
C
So,
for
example,
we
might
have
our
HD
video
in
one
track,
and
you
know
so
low
definition,
video
and
another
track
and
a
you
know:
client-side
receiver,
bandwidth
control,
my
baseline's
band
with
select
switch
track.
It
wants
to
receive
the
important
thing
from
the
mock
transport.
Is
you
can
ask
for
these
tracks?
You
can
get
the
information
in
them
and
that
the
relays
can
help
distribute
it.
The
consumers
and
producers
know
what
what
data
to
send
and
how
to
send
around
that's
what
this
protocol
is
about.
C
So
we
do
name
these
tracks
and
the
the
full
track
name
is
is
has
two
parts
of
it:
okay,
it
has
a
track
name
space.
It's
sort
of
you
know,
consider
that
the
hierarchy
bits
and
then
inside
of
that
a
track
name,
and
these
are
just
a
bunch
of
binary
bits.
As
far
as
this
protocol
works
right,
maybe
they're
part
fragments
of
a
URL
who
knows
maybe
there's
something
else,
maybe
whatever
it
doesn't
really
matter.
C
From
this
protocol's
point
of
view,
all
it
ever
does
is
match
these
okay
combine
those
two
combined
together
that
the
term
we
use
for
those
two
combined
together
is
the
full
track
name
now,
the
full
track
name
in
many
cases
be
long,
and
we
don't
want
to
send
that
in
all
of
our
objects
or
something.
So
we
often
have
a
short
integer
that
in
the
way
the
protocol
sets
up
you,
you
know
what
the
value
is
for
a
given
name,
that
is,
is
just
a
short
Alias
for
the
full
track
name.
C
So
this
is
called
the
track
ID
and
it's
just
a
short
Alias
for
for
the
full
track
name,
and
we
use
that
it's.
It's
only
exists
to
just
make
some
of
the
messages
smaller,
so
you
don't
have
to
send
the
full
track
name
all
the
time.
Okay,
we
also
have
a
group
Sequence,
so
this
is
an
integer
that
identifies
which
group
it
is
inside
of
the
track,
and
then
inside
of
of
that
we
have
remember,
we
have
the
objects.
C
Inside
of
a
group,
we
have
an
object
sequence,
which
is
an
integer
that
identifies
which
object.
It
is
inside
of
the
group,
and
one
thing
that's
important
about
that
one
is:
it
starts
at
zero
in
each
group
right,
so
you
can
tell
where
the
beginning
of
the
group
is
just
looking
at
these
these
integers.
C
C
The
objects
that
we're
going
to
send
all
this
media
around
in
and
what
level
that's
known
about
here
when
we
send
each
one
of
the
objects
and
there's
some
other
there's
some
messages
that
go
back
and
forth
to
set
up
sending
objects
say
what
you
want
I'm
going
to
get
to
those
messages
in
a
second
but
I
just
want
to
talk
about.
What's
in
an
actual
object
that
we're
going
to
send
over
the
wire
the
relevant
information.
C
That's
really
in
it
here
is
you
got
the
track
ID,
so
you
basically
can
look
that
up
to
find
you
know
the
full
track.
Name
of
it.
You've
got
the
group
Sequence.
That
knows
it
identifies
which
it
is.
You've
got
the
object
sequence,
and
then
you
have
some
some
extra
metadata
that
might
that
the
the
relays
and
the
components
along
the
path
need
to
be
able
to
see
about
this.
So
right
now,
there's
only
one
piece
of
that,
which
is
what
we
call
send
order,
or
priority
and
I'll
talk
more
about
that
later.
C
But
this
is
just
some
bits
that
help
provide
information
to
relays
to
sort
of
know.
You
know
which
packet
to
send
next
what
the
priority
is.
However,
you
want
to
think
about
it,
but
gives
it
extra
meta
information
to
know
which
packet
to
send
first,
when
they
have
multiple
packets
that
all
need
to
go
somewhere,
then
we
have
the
payload.
This
would
be
where
the
actual
media
goes
into
it.
It
is
opaque
to
the
relays.
C
The
mock
transport
doesn't
know
anything
about.
It
doesn't
look
in
it.
It's
it's
just
like
that's
moving
the
bits
that
have
meaning
at
a
higher
level.
There's
been
discussion
of
other
pieces
of
metadata
that
can
be
added
in
here
like
time
to
live,
or
things
like
that.
But
the
only
thing
that's
in
draft
right
now
is
just
this.
This
send
order
that
that
gives
the
information.
C
C
C
How
to
ban
this
like
what
is
connection
URL
is
that
it's
going
to
connect
to-
and
you
know
a
track
name
that
it
might
be
interested
in
or
not
and
that's
sort
of
an
application,
Level
thing,
but
it
might
have
some
information
like
that,
so
it
sets
up
the
web
transport
connection.
Then
it
sends
a
setup
message
and
right
now,
this
setup
message
just
has
version
negotiation
and
role
in
it,
where
the
role
is
basically,
whether
it's
going
to
send
video,
whether
it's
a
consumer,
a
producer
or
both.
C
Okay,
the
server
respond.
You
know
the
server
you
know
can
respond
to
this
I.
Don't
have
all
the
I'm
missing
some
of
the
okay
messages
in
here,
but
you
know
sends
an
okay
message
on
this.
The
server
then
can
announce.
This
is
an
optional.
It
can
announce
track,
name
spaces
that
it's
willing
to
publish
that
might
be
useful
in
some
use
cases
it
might
not
be
in
other
cases.
C
The
client
at
this
point
sends
a
subscribe
with
the
full
track
name
of
what
it
wants
to
receive
and
remember.
It
may
have
just
gotten
a
track
name
space
from
the
server
to
understand
what
the
server
is
even
willing
to
send
it
or
it
may
not
have,
but
that
doesn't
really
matter
too
much.
The
key
thing
here
is:
it
does
a
subscribe
and
passes
the
full
track.
Name:
The
Scribe!
You
can
come
back
with
an
error.
Obviously,
but
if
it
doesn't
come
back
with
an
error,
there
could
be
some
authorization
information.
C
Now
at
that
point,
and
that's
how
the
form
and
the
mapping
forms
here
on
between
the
through
the
full
track
name
and
the
track
ID
at
that
point,
the
server
can
just
start
sending
it
mini
media
objects,
so
those
are
going
to
start
flowing
across
okay,
and
that
is
pretty
much
the
whole
protocol
like
that's
it.
That's
it
it's
a
fairly.
C
You
know
fairly
simple
sort
of
approach
to
this
and
I
like
the
way
that
this
splits
it
between
what
happens
at
a
higher
level
where
we're
going
to
be
dealing
with
the
catalogs
and
understanding
what
tracks
you
want
and
which
to
get
and
what
happens
here,
which
is
just
pretty
straightforward.
So
let
me
go
to
the
next
slide.
C
Foreign.
The
contribution
flow,
so
somebody,
the
camera,
that's
trying
to
send
some
video
up
to
the
server
is
nearly
exactly
the
same
right.
Web
transport
setup
role,
negotiation
there
again,
you
have
this
optional,
announce
I'll
talk
a
little
bit
more
in
a
minute
about
why
that's
there
and
then
the
server
this
time
subscribes
to
a
full
track.
Name
and
the
subscriber
sends
the
track
ID
and
starts
sending
it,
and
then
the
producer
here
can
start
sending
these
these
many
objects
of
data
up
to
the
server.
C
So
I
want
backup
just
one
slide
for
a
second,
when
we're
dealing
with
the
case
with
relays
these
flows
don't
send
at
all,
I
mean
right
here,
I
wrote
on
server,
it's
just
a
server
from
it.
It
does
know
as
a
relay.
It
doesn't
know
whether
it's
like
the
the
only
server
in
the
world
that
the
client
that
connected
to
it
doesn't
even
really
care
exactly
what
it's
talking
to
Okay,
because
the
the
protocol
is
about
the
same
for
it
either
way,
and
that
you
know,
that's
that.
C
That's
you
know
one
of
the
things
that
we've
tried
to
keep
it
through.
This
draft
is
that
what
changes,
because
you're
talking
to
a
relay
is
extremely
minimal
on
the
draft.
There's
not
much
changes,
because
that's
it's
basically
the
same
same
text
throughout
for
both
for
anybody
who's.
You
know
if
you're
sending
media
you
do
this,
it
doesn't
matter
whether
you're
a
relay
or
a
producer
or
what
you
are,
and
likewise,
okay,
so
I
missed
that
one
I
was
talking
about
next
slide.
C
The
code
needs
to
be
able
to
figure
out
which
code,
what
what
you
send
next,
given
the
congestion
limits
of
the
the
quick
connection,
you're
about
to
send
it
on
and
you've
got
a
bunch
of
things
queued
up
that
need
to
go
and
how
you
pick,
which
one
to
send
next.
Okay,
we
know
that
we
want
more
or
less
the
same
algorithm
for
relays
and
endpoints.
We
know
that
that
algorithm
needs
to
be
based
on.
You
know.
C
So
there's
two
algorithms
that
are
defined
in
the
draft
right
now,
and
neither
one
of
the
these
are
just
like.
These
are
potential
options
as
starting
points
for
the
working
group
to
choose
one.
This
is
not
a.
We
think
the
working
group
should
have
both
of
these
or
anything
like
that.
It's
just
like
there's
not
consensus
on
this.
We
don't
know
why
it
would
do
so.
C
We
wrote
down
two
things
that
start
to
give
a
flavor
and
I'm
sure
that
the
work
will
want
to
do
something
as
a
working
group
is
a
little
bit
different
than
either
of
these,
but
at
least
get
something
concrete
that
can
give
you
a
feeling
of
the
type
of
thing
we
mean
here
by
this
in
in
a
strong
way,
so
the
send
order,
one
is
on
the
left
here,
the
the
producer
like
look,
it
knows
what
tracks
it's
dealing
with.
It
knows
how
they're
important
of
them
it
is.
C
Given
everybody
else
along
the
path
is
going
to
execute
this
rule
of
within
a
track.
Namespace
the
largest
send
orders
first
and
it's
Envision.
These
numbers
just
keep
growing
like
they're
variable
ants
they
get
very
large.
They
can
just
keep
growing
forever
for
the
length
of
the
whole
session.
They
can
get
larger
and
larger.
C
This
one's
a
little
bit
different
in
in
it
still
has
an
integer
that
we
write
into
the
packet
that
people
look
at
to
decide
what
to
do,
but
each
object
is,
is
given
a
priority
order
and
these
aren't
envisioned
as
just
they
they
keep
incrementing
and
getting
larger
over
time.
It's
just
like
okay,
we'd,
probably
be
giving
our
audio
like
one
priority
level
and
other
things.
You
know
a
different
priority
level.
It
might
be
that
iframes
got
a
different
priority
level
in
pre-frames
inside
of
a
group.
C
Those
types
of
ideas
So
within
a
group,
the
lower
priority
number,
so
priority
ones,
most
important,
lower
priority
are
sent
first
within
a
group
of
priorities
are
equal,
then
the
lower
object
sequence
is
sent
first
So
within
a
group
you're
sending
your
first
stuff
sooner
than
your
later
stuff,
and
that
between
groups
later
groups
are
normally
sent
ahead
of
other
earlier
groups.
And
you
know
all
of
these
have
some
problems.
We're
trying
to
generate
some
there's
so
awesome
I'm
trying
to
generate
some
data
on.
You
know
how
these
various
algorithms
perform.
C
So
what
I
really
want
to
sort
of
get
at
from
the
from
the
point
of
you
know
coming
out
of
the
meeting
today?
Is
this
draft?
We
put
you
know,
that's
the
flavor
of
it,
that's
the
big
picture
of
how
it
fits
together.
That's
the
picture
of
how
other
things
split
up.
On
top
of
it
I'm.
Definitely
a
fan
of
how
how
this
has
come
out
this
way.
You
know
I
strongly
think
this.
C
F
C
The
corners
of
the
tent
pin
to
the
ground
in
a
way
that
we
can
really
make
some
some
rapid
progress
in
the
working
group.
So
if
there's
any
questions
or
sort
of
meta
concerns
that
people
would
like
to
raise
that
bring
them,
you
know
of
concerns
about
adopting
it
now.
I'd
really
like
to
try
and
address
those
right
now,
as
best
I
can
or
have
any
of
the
the
co-authors
or
actual
authors
of
this
draft
step
in
and
speaking
on.
C
D
Okay
and
I
can
I
can
cut
and
paste
what
I'm
saying
into
the
notes.
Just
for
the
for
the
note
takers
Cullen,
thank
you
for
this
presentation.
I
support.
Adoption
of
this
draft
full
stop.
I
have
a
couple
of
comments
about
how
this
draft
fits
into
the
charter
deliverables
for
the
working
group,
you're
talking
you're,
talking
about
both
architecture
or
you're,
talking
about
architectural
Concepts
and
you're
using
terminology,
and
we
really
need
to
at
least
nail
down
the
basics
on
both
those
real
soon.
D
So
I
have
two
questions
for
the
group
we're
talking
about
adopting
this.
As
the
protocol
deliverable
protocol
specification
for
common
media
publication
protocol
over
quick,
that's
in
our
Charter
can
we
adopt
the
draft
as
it
is
today,
and
it
possibly
move
that
material
into
another
draft
later
or
perhaps
the
architecture
specification
for
common
media
delivery
protocol
over
quick?
D
So
that's
that
so
that's
what
I'd
like!
That's
what
I'd
like
to
see
happen
and
basically
for
us
to
you
know,
we've
talked
about
needing
to
focus
on
architecture
and
terminology,
but
now
that
we're
adopting
drafts
that
are
assuming
in
architecture
and
using
terminology,
it
would
be
great
if
the
different
drafts
that
we
are
adopting
use
something
like
the
same
architecture
and
use
something
like
the
same
terms
to
describe
it.
C
D
D
Yes,
so
so
that
was
one
thing
the
other
one
was
for
the
for
the
work
for
the
people
who
have
drafts
in
this
working
group.
Can
we
have
some
specification
that
doesn't
include
mock
transport
in
the
title,
because
it's
like
how
many
how
many
mock
transport
layers
you
know
how
many
transport
layers
are
we
talking
about
to
transport,
media
and
I
mean
I?
Don't
I,
don't
want
I
I,
don't
want
to
bike
shed
on
this.
Certainly
not
you
know
not
in
a
beating
like
this,
but
it
would.
D
It
would
be
great
if,
if
we
could,
we
could
look
at
the
protocol
stack
that
you
presented
and
see
if
we
can
think
of
better
ways
to
describe
that.
That
would
be
clearer
for
someone
who's,
not
a
member
of
the
working
group,
but
it
might
have
to
be
implementing
this
later,
and
that
is
that
that
is
everything.
I
was
going
to
say
and
I
will
put
my
stuff
in
the
in
the
notes.
D
D
A
I
There's
one
thing:
that's
not
in
the
drafts
as
I've
read
them,
and
maybe
it's
implicit
but
I-
think
it's
really
important,
which
is
the
how
how
how
gaps
are
addressed.
For
example,
you
know,
obviously
in
RTP
we
have
our
TCP,
where
you
get
this
feedback
I'm
assuming
in
mock.
We
don't
have
the
equivalent
thing
for
scalability
reasons,
but
it's
not
explicitly
stated
and,
for
example,
on
ingest
if
I'm
sending
something
if
a
frame
doesn't
get
received.
Is
it
up
to
the
res
sender
to
decide
whether
to
resend
it?
I
How
does
it
know
that
the
reason
I'm
asking
this
Colin
is
there's
a
pretty
big
differences
between
quick
and
web
transport
in
that
respect?
You
know
if
you're
running
directly
over
quick,
there's
a
lot
more
information
that
the
application
can
have
about
the
transport
and
what
got
received
and
what
didn't
versus
in
web
transport.
C
Right,
Bernard
I
think
that's
this,
that's
a
whole
kettle
of
fish
for
sure.
Now.
Obviously,
if
we're
running
on
reliable
streams,
mostly
that
question
doesn't
exist
quite
the
way,
it's
more
of
a
rate
control
question
of
what
you
subscribe
to
largely
controls.
What's
happening
and
they're
and
from
an
RTP
point
of
view,
you
do
have
reliable
retrans.
C
You
have
our
hop
by
hop
RTX
effectively
right,
because
that's
what
the
quick,
the
reliable,
quick
streams,
if
we're,
not
using
quick
in
a
reliable
way
at
all,
then
I
I
think
that
that
gets
more
complicated
and
I
and
the
drafts
have
carefully
avoided.
Get
you
know
really
nailing
that
down
one
way
or
another
at
this
point,
so
I
would
definitely
leave
it.
C
But
that
was
definitely
left
as
as
fairly
open
and
a
bunch
of
possibilities
there,
but
it
was
more
seen
as
a
hop
by
hop
mechanism
and
most
envisioning
of
it
than
a
end-to-end
mechanism,
because
for
a
lot
of
the
use
cases,
obviously
we
can't
have
you
know
the
equivalent
of
an
fir
frame
coming
all
the
way
back
to
the
producer
yeah
right.
So
it's
it's
mostly
the
other
direction
of
it
and
the
drafts
are
you're
totally
right.
The
drafts
are
silent
on
the
topic.
I
think
right
now,
they're
fairly
open
up.
I
C
K
Look
at
the
questions
that
burnout
is
is
giving
us
and
and
that's
very
good
input
and
I
would
very
much
like
that
input
to
arrive
from
the
working
group
and
from
Bernard
and
from
other,
rather
than
having
a
continued
discussion
of
the
author
in
a
closed
group.
So
that's
one
of
my
main
motivation
for
saying:
hey.
We
should
adopt
this
sooner
rather
than
later,
so
that
we
can
have
an
actual
working
group
discussion
instead
of
a
restricted
of
author's
discussion.
That's
the
first
reason
then
yeah
I
mean
there
are
issues.
K
K
F
K
To
be
a
transport
protocol,
it's
kind
of
idiotic
to
see
that
as
a
transport
protocol,
UDP
is
a
way
to
give
IP
visibility
to
the
application.
That's
it
so
and
also
I
mean
the
point
that
two
points
that
burnout
were
making
the
point
about
the
feedback
we
planted
on
that.
Yes,
we
planted
at
that
because
of
scalability
issues,
because
I
mean
if
you
are
sending
a
video
to
a
million
receivers,
I
mean
the
fact
that
one
of
them
doesn't
receive
it
completely
is
kind
of
a
fact
of
life.
K
It's
gonna
happen
and
that's
it,
but
that
means
pretty
much
open
loop
transmission
and
if
we
are
using
that
in
a
small
group,
say
half
a
dozen
receivers,
then
it
does
make
sense
to
get
feedback
from
the
individual
receivers.
That's
one
of
the
tension
that
we
have
to
resolve
and
we
resolve
it.
Probably
in
the
working
group.
The
same
thing
goes
about
this
business
of
priorities.
I
mean
it's,
it's
very
only
the
handling
of
priorities
and
others
is
very
unclear.
K
We
have
a
Temptation
that
says
it
shall
be
entirely
defined
by
the
sender,
which
does
make
sense
in
the
sending
to
a
million
receiver
scenario,
but
does
not
make
sense.
So
much
in
small
group
scenarios
suppose
that,
for
example,
we
have
sandals
sending
10
video
streams
and
a
particular
receiver
is
only
interested
in
one
of
them.
K
I
mean
the
fact
that
the
receiver
is
interested
for
now
in
one
of
them
and
one
the
other
one.
In
the
background
just
to
be
ready
that
has
to
be
expressed
somehow,
and
that
means
the
receiver
shall
be
able
to
implement
the
file
to
affect
the
priorities
that
are
used.
So
all
that
I
said
that.
Well
we
have
many
points
that
will
need
to
be
resolved
in
the
working
group,
but
please
adopt
it.
So
we
can
actually
resolve
it
in
the
working
group
and
not
infrared
discussions.
B
B
G
There
are
six
slices
okay,
so,
as
Colin
has
mentioned
in
the
previous
presentation,
Mark
has
a
concept
of
a
full
track
name,
which
is
what
you
asked
for
when
you
subscribe
to
a
track.
A
track
name
is
so
a
full
track.
Name
has
two
parts
tracking
space
and
track
name
they're,
currently
defined
to
be
fully
opaque,
blobs
that
are
directly
concatenated
to
full
form,
a
full
track
name.
There
is
no
specific
syntax
beyond
that.
G
That
is
all,
of
course,
is
subject
to
a
bike
shot
or
the.
So
what
is
the
difference
between
track
name,
space
and
a
track
name?
Currently,
it's
we
don't
go
much
into
it
in
the
draft
and
it's
mostly
to
the
application.
But
there
are
two
notable
features.
Is
that
one
we,
when
you
publish
you,
only
announce
a
track
name
space
and
not
a
track
name,
but
when
you
subscribe,
you
subscribe
to
individual
tracks.
G
The
reason
for
that
is,
we
expect
track
namespace
to
basically
belong
to
the
same
producer,
and
whenever
you
publish
something,
if
you
publish
a
video
track
and
an
audio
track,
and
you
successfully
publishing
video
track
and
then
you
failed
to
publish
an
audio
track.
This
leaves
you
in
an
awkward
State
and
this
decision
to
publish
it
to
announce
at
the
name.
Space
level
avoids
at,
and
the
second
is
that
in
some
priority
related
proposals
track
name.
Spaces
are
like
the
boundaries,
which
is
a
priorities
are
sent
in
particular
send
order.
G
So
the
important
here
are
some
examples
that
are
copied
directly
from
the
draft
of
how
you
can
structure.
One
of
them
is
the
first
example
is
for
a
video
conference.
The
second
example
is
video
conference,
but
like
it's,
a
press
track
name,
space
and
track
name
at
a
different
level,
and
the
third
one
is
an
example
of
what
you
would
do.
If
you
have
a
like
a
direct
device,
you
connect
to
directly
the.
G
Important
property
of
a
full
track
name
that
makes
it
different
from
what
you
would
typically
expect,
for
instance,
with
HTTP
URLs,
is
that
in
mock
transport
we
Define
full
track
name
is
like
the
full
name
of
the
track,
and
there
are
no
extra
keys.
You
can
add
so
there
the
full
tracks
there.
If
you
want
to
Cache
something
the
full
track.
Name,
is
your
cash
key.
G
This
is
this
means
that,
like
whenever
you
talk
to
a
server,
and
you
ask
for
a
track,
the
track
gives
you
that
specific
track,
and
there
is
no
content
negotiations
or
no
extra,
very
headers
Etc
and
that
significantly
simplifies
implementing
implementing
caching.
So
when
I
say
unique,
the
I
said
that
the
full
track
name
is
unique.
G
There's
a
caveat
that
well
I'll
talk
about
later,
but
okay,
so
the
property
of
the
track
name
is
note
that,
while
those
examples
have
domain
names
and
they're
meant
to
be
unique,
those
do
not
those
are
entirely
logical.
They
do
not
actually
tell
you
where
to
connect.
The
sixth
question
of
where
you
to
connect
is
entirely
orthogonal
and
it
is,
is
determined
by
a
third
saying
called
The.
Connect
URL
in
the
connect
URL
is
just
the
web
transport
URL
to
you,
connect
to
or
for
real
quick.
G
We
have
a
special
syntax
of
how
you
connect
to
a
specific
server
or
via
real,
quick
to
speak
mock
transport,
and
so,
if
you
are
a
client
and
you
have
no
prior
information
of
how
to
connect
to
something
and
if
you
want
to
fetch
some
specific
track,
the
three
bits
of
information
you
need
is
a
connect,
URL
tracking
space
and
track
name.
But
the
letter
to
our
orthogonal
to
the
connect
URL.
G
So
I
mentioned
that
the
track
names
are
unique.
There
are
some
requirements
of
to.
How
widely
is
that
uniqueness
is
intended,
I,
don't
want
to
say
guaranteed,
but
how
much
you
have
to
widely
you
have
to
provide
the
naming
Agnes
specifically,
if
you
want
to
run
a
complex
application
which
forwards
media
between
multiple
parties
like,
for
instance,
a
video
conference
with
a
lot
of
participants.
G
You
want
all
of
the
servers
to
provide
you
consistent
track
names,
and
you
want
multiple
servers,
so
you
can
connect
one
CDN,
node
or
and
make
sure
that,
like
the
traffic
from
that
CDN
now
it
would
reach
potentially
the
other
CDN
node,
because
that's
how,
because
all
you
have
is
a
track
name
which
would
theoretically
tell
you.
This
is
a
video
conference,
and
this
is
the
participant
Etc
like
that.
That
would
be
in
society
track
name,
but
the
connect
URL,
which
tells
you
which,
which
CDN
server
you
can
connect.
G
So
the
draft
introduces
the
notion
of
a
scope.
A
scope
is
a
set
of
servers
to
which
you
can
connect
and
receive
the
same
tracks
from
the
same
name
or
you're,
not
guaranteed
to
always
receive
them.
But
if
you
will
receive
them,
they
will
do
the
same
track.
So
in
very
simple
point-to-point
cases,
the
scope
is
just
one
connection
in
cases
when
you
do
things
like
video
conferencing,
you
need
all
of
your
notes
to
be
within
the
same
scope.
Otherwise
the
video
conference
will
not
work.
I.
G
B
F
L
L
So,
unfortunately,
the
animation
didn't
build
here
for
the
slide
sharing,
but
at
the
very
bottom
we
have
raw,
quick
and
rev
transport
layered
over.
That
is
our
media
over
quick
transport
and
then
on
top
of
it.
We
have
a
number
of
these
streaming
formats
and
as
as
we
discussed
at
the
last
face-to-face,
we
may
want
more
than
one
because
we
can
either
make
one
that's
so
complex.
L
L
We
want
as
few
as
possible
of
these
streaming
formats
that
meet
our
use
cases,
while
dividing
them
into
groups
that
allow
us
to
be
simple,
precise
and
efficient
within
a
given
set
of
use
cases,
and
what
I'm
presenting
here
is
the
very
first
one
of
these
and
we've
named
it
warp
streaming
format
and
it's
its
name
comes
from
Luke
Curley.
It's
it's
about
70,
on
what
I'm
presenting
here
comes
directly
from
Luke's
initial
contribution.
So
my
thank
him
for
that.
L
So
at
a
very
high
level,
it's
designed
to
deliver
cmaf
packaged
content
and
provide
good
interrupt
with
existing
encoders,
Packaging,
Systems
and
player
decoders.
So
cmap
is
widely
deployed
within
the
Adaptive
streaming
World.
It
makes
a
lot
of
sense
to
leverage
the
ecosystem
we
already
have
for
that
distribution,
be
able
to
play
it
immediately
for
a
mock
transport,
streaming
format,
there's
a
focus
on
live
and
near
live
streaming.
L
That's
a
consensus
view.
It
can
also
be
used
for
VOD
and
I'm
personally
interested
in
that.
But
that's
a
point
we
have
to
debate
here.
It
works
at
a
high
level
by
fragmenting
a
bit
stream
into
objects,
so
mock
transport
provides
the
objects.
What
warp
streaming
format
tells
you
is,
how
do
I
take
my
media
and
compartmentalize
it
into
those
objects
and
it
uses
for
congestion
response
a
notion
of
prioritization
and
send
order.
These
are
the
it.
L
It
can
only
twiddle
the
norms
and
levers
that
mock
transport
provides
and
since
mock
transport
has
not
settled
on
the
log,
knobs
and
levers.
Yet
this
is
not
defined
for
warp
streaming
form
and
other
than
we
intend
to
use
that
to
address
congestion
at
relays
or
at
any
node.
That
is
retransmitting
data.
L
So
for
packaging
you
need
to
encode
each
bit
stream
and
that's
a
media
bit
stream
now
into
a
sequence
of
objects,
a
contiguous
sequence
of
objects.
These
media
tracks
should
be
time
aligned.
So
if
you're
familiar
with
cmap
switching
sets,
they
meet
this
requirement.
The
idea
is
that
a
receiver
should
be
able
to
cleanly
switch
media
tracks
at
the
group
boundaries.
L
So
I
have
a
diagram
below
we
see
three
tracks.
Our
traditional
multi-bitrate
stack,
the
dark
color
in
each
block
indicates
an
IDR
or
the
start
of
the
GOP.
The
idea
is
that
just
like
in
adaptive
streaming,
if
either
the
client
or
server
which
wish
to
switch
in
the
transmission,
it
can
do
so
cleanly
at
the
start
of
any
group
and
this
Maps
very
directly
to
cmap
switching
sets.
L
So
what
media
objects
can
you
place
to
meet
this
requirement?
So
there's
flexibility
here
at
the
top
level
we've,
the
group
is
holding
a
cmap
fragment
and
there's
only
one
object
in
each
group
and
it's
holding
the
whole
fragment
as
well,
and
this
isn't
entirely
feasible
and
can
work
very
nicely
in
fact,
and
if
you
have
content,
that's
hls,
Dash
package,
this
will
map
directly
using
this
format
where
each
each
segment
is
in
fact
an
object
and
there's
one
object
per
group.
L
The
second
level
down
the
group
is
still
holding
a
fragment,
which
is
an
independently
addressable
cmf
object.
But
now
we
have
chunks
and
these
chunks
can
be
a
number
of
frames.
The
the
frame
count
doesn't
matter,
but
there
are
not.
Every
trunk
is
an
addressable
point.
So
the
first
chunk
at
the
start
of
every
fragment
is
independently
decodable.
The
subsequent
chunks
are
not,
but
now
we
have
multiple
objects
per
group
and
then
the
next
level
down
or
the
ultimate
level
down
on
on
the
video
video
side
would
be
one
frame
per
object.
L
So
now
we
might
have
30
cmf
fragment,
that's
one
second
long
and
we'll
have
30
objects
per
second
in
that
group.
The
first
object
holding
the
keyframe
and
the
rest
being
P's
and
B's
and
clearly
frame
per
object
is
probably
better
for
real-time
delivery,
but
the
spec
is
not
going
to
dictate.
You
must
use
one
or
the
other.
Any
one
of
these
requirements
meets
the
constraint
of
using
cmath
content
and
making
the
group
start
Point,
independently,
accessible.
L
So
now
we
introduce
the
notion
of
a
catalog,
so
a
catalog
is
like
a
menu
or
a
description
of
what's
available
from
a
given
publisher
and
it
is
itself
a
track.
So
it's
a
special
track
that
when
it's
published
describes
the
other
tracks
and
the
catalog's
job
is
to
both
describe
the
the
track
content
what's
available
as
well
as
give
the
the
consumer
information
that
it
might
need
to
use
to
select
between
various
tracks.
So
it
might
give
you
the
resolution,
the
codec,
the
bitrate
things
you
need
to
know
to
make
a
choice.
L
It's
also
going
to
provide
information.
You
need
to
initialize
the
decode,
in
other
words,
to
begin
decoding
the
content
on
the
on
the
receiver
side.
Catalog
objects
can
represent
Deltas
from
other
prior
objects.
So
if
we
have
a
complex,
a
complex
offering
coming
out
of
of
a
producer
might
be
producing
10
different
streams
and
one
of
them
changes.
We
don't
want
to
replicate
all
of
that
information
again,
so
we
can
simply
issue
the
change
as
a
change
from
a
prior
state.
So,
just
like
tracks
have
the
notion
of
groups.
L
We
can
break
our
catalog
into
groups
as
well,
so
we
can
have
Delta
updates
within
a
group
that
apply
to
previous
or
only
make
sense
when
combined
with
previously
previous
objects
within
that
group.
But
every
group
emission
of
a
catalog
should
be
independent
and
not
rely
on
on
prior
catalog
updates.
So
on
the
right
hand,
side
is
the
syntax
denoting
the
the
catalog
payload.
It's
a
binary
one
at
the
highest
level.
I
was
going
to
build
these
in
the
animation,
but
it
dictates
the
format
type.
L
So
the
first
variant
you
see
in
the
payload
would
be
one
and
that
tells
the
receiving
client
that
the
rest
of
the
catalog
can
be
interpreted
as
being
a
warp
streaming
catalog
because
they
can
be
meta,
many
catalogs
you
might
receive
so
and
since
you
can
always
be
guaranteed
that
the
the
first
Varin
defines
the
type
and
it's
registered,
you
know
how
to
parse
the
rest
of
the
object,
there's
a
version,
because
we
might
want
to
change
this
over
time.
There's
the
parent
object:
sequence,
This,
Is,
How,
We,
Do,
Delta
updates.
L
You
simply
refer
to
the
object
sequence
number
on
which
this
particular
object
depends.
Then
there's
you
can
have
a
number
of
track
changes
and
each
one
of
them
carries
a
descriptor
for
the
descriptor,
which
is
a
section
in
green.
You
specify
the
full
track
name,
you
need
its
length
and
then
the
track
name
bits
and
then
there's
a
single
bit
flag
for
the
operation
and
there's
two
operations
currently
defined
either
add
or
delete,
which
are
one
or
a
zero.
If
you're
adding
a
track
in
in
this
catalog,
you
supply
the
initialization
header
and
cmap.
L
L
Trying
to
click-
oh,
let's
go
this
way,
so
the
workflow
again
at
a
very
simple
level,
a
war
publisher
must
make
available
a
catalog
track
after
announce
and
before
or
concurrently
with
any
media
track
objects.
So
you
mustn't
be
firing
off
tracks
that
you
haven't
described
in
your
catalog
and
your
publisher
only
pushes
content
in
response
to
a
validated
subscribe
request.
This
is
core
mock
transport
Behavior.
L
So
we're
just
inheriting
that
and
then,
at
the
completion
of
a
session,
the
publisher
publishes
a
catalog
that
removes
all
the
prior
tracks
that
had
previously
published,
and
this
should
be
interpreted
by
receivers
to
say,
the
publish
session
is
complete.
I
think
we
need
very
precise
ways
to
say
when
sessions
have
started
and
stopped-
and
this
is
one
proposed
solution.
L
Now,
there's
a
proposal
for
how
we
can
join
together
the
connect
URI
and
the
notion
of
the
catalog
track
name.
This
is
just
a
proposal
and
you
see
there
for
an
example.
We
have
a
a
single
URI,
which
is
a
mange
of
the
connect
URL
and
the
path.
So
the
client
would
make,
in
this
case
a
web
transport
connection
to
that
entire
string.
L
So
we
can
remove
a
round
trip
of
the
client
needing
to
subscribe
to
the
catalog,
we're
not
actually
removing
it,
because
the
client
could
make
a
parallel
subscribe
request.
However,
there
is
a
certain
convenience
in
being
able
to
use
the
connect
URL,
along
with
the
catalog
full
track
name.
This
is
just
a
proposal.
There's
obviously
merits
for
and
against
this.
L
Another
proposal
for
client
initiated
server
side
ABR,
so
the
proposal
currently
does
not
address
at
all.
How
you
might
a
client
or
a
server
might
want
to
switch
between
these
tracks
as
a
response
to
congestion.
So
we
have
the
inter-track
prioritization
that
we've
discussed.
However,
I
might
want
to
switch
from
my
1080
to
my
720
to
my
360p
content.
How
would
I
do
that?
So
one
idea
here
is
that
in
my
subscribe
message,
I
append
an
optional
object.
L
That
says
this
subscription
is
part
of
a
group
group.
One
and
I
set
a
throughput
level.
Now
we
don't
want
too
many
variables,
but
we
throughput
is
one
thing.
Perhaps
we
can
standardize
around
so
clearly,
I
set
the
throughput
level
here
and
the
as
soon
as
this
this
ABR
object
has
sent
on
the
Subscribe.
L
So
there's
reasons
why
this
can
work
reasons.
Why
this
cannot
work
again?
This
is
just
a
proposal
for
how
the
client
might
ask
the
server
to
send
it
the
most
appropriate
track
at
any
time.
The
client
could
obviously
make
this
subscription
decision
itself
and
switch,
but
there's
an
idea
that
we
might
want
to
have
this
on
the
server.
L
Thank
you
there's
a
lot
of
things
still
to
solve.
With
this
and
I'll,
you
can
read
them,
but
I'll
quickly
go
through
them
prioritization
strategy.
This
is
somewhat
very
well,
not
somewhat
it's
very
dependent
on
what
mocked
offers,
but
even
once
mocked
off
is
it?
How
should
warp
streaming
format
use
that
we
need
to
find
an
ABR
strategy?
L
Maybe
it's
client-side,
maybe
it's
server
side,
and
if
it's
that
server-side
one
I
just
showed
that
has
to
be
part
of
core
mocked
as
well,
because
it's
a
core
requirement
that
every
relay
is
going
to
need
to
offer
up,
should
track
names,
be
strings
all
the
examples
we've
shown.
They
are
strings,
although,
as
Cullen
mentioned,
they're
just
binary
blobs,
so
maybe
for
warp
streaming
format.
We
want
to
constrain
them
to
Be
Strings,
because
they're
so
much
easier
for
us
to
work
with,
and
if
so,
we
need
to
specify
the
the
wire
the
wire
protocol.
L
For
those.
This
is
a
big
one.
Number
four
can
catalogs
hold
content
from
different
track
name
spaces.
So
as
soon
as
we
allow
this
there's
additional
complexity,
but
there
is
there's
use
case
reasons
where
this
might
make
sense.
So
we
need
to
explore
catalogs,
not
literally
being
a
directory
if
your
catalog,
if
your
stream
names,
if
your
catalog
simply
held
the
track
name
and
it
could
infer
the
track
namespace
from
the
catalog
path,
just
like
we
do
with
hls
or
Dash,
then
they
would
all
be
relative
to
that
and
I
could
move
them
around.
L
We
know
that
works
at
scale.
That
might
be
something
we
want
to
look
at
yeah,
but
that
would
prohibit
using
different
track
name
spaces.
Number:
five.
Should
common
group
numbers
hold
media
time?
Sync
data,
that's
somewhat
implicit
in
what
I
just
described
when
you
could
switch
between
groups,
but
if
I
switch
from
group
5
and
track
a
to
group
5
and
track
B.
Is
there
a
hard
requirement
that
the
media
time
is
identical
between
those
two
with
cmat
switching
sets?
It
would
be,
but
we
need
to
state
that
explicitly
number
six.
L
L
However,
in
that
naming
syntax
I
showed
you,
it
doesn't
necessarily
need
to
end
with
catalog.
It
could
have
ended
with
alpha
one
two:
three,
it's
simply
a
track
that
happens
to
describe
other
tracks.
So
do
we
need
the
reserve
name
for
it?
Number
seven
content
protection,
there's
an
open
issue
for
this
number.
L
Eight
I
I
believe
we
should
try
to
standardize
content
protection
for
this
from
day,
one
to
prevent
the
split
we've
had
in
adaptive
media,
where
we
have
multiple
incompatible,
Cipher
modes
that
are
out
there
and
therefore
silos
of
content,
but
which
format
to
go
for
is
open
to
debate
issue
13.
Do
we
want
to
relax
the
cmap
packaging
requirement?
That's
a
big
change
to
this
protocol.
This
protocol
was
designed
to
leverage
cmap
and
its
its
industry
ubiquity,
but
there's
good
reasons
for
allowing
other
protocols.
L
Non-Non-Cmaf
compliant
codecs,
for
example,
to
be
used
is
raised
number
nine.
What
about
SVC
support?
So
we
speak
about
ABR,
switching
and
there's
many
models
here
that
are
compatible
with
the
Adaptive
switching
world,
but
as
we
moved
into
into
a
layered
distribution,
how
do
we
describe
the
relationships
between
these
these
tracks?
Do
we
want
that?
L
Do
we
want
to
increase
what
warp
streaming
format
offers
or
do
we
want
to
make
another
streaming
format
that
is
dedicated
to
SVC,
based
distribution,
and
that's
a
big
debate
for
the
group
and
then
last
one
I'll
mention
here
number
seven:
do
we
want
to
support
multiple
catalog
types
within
a
streaming
format,
so
there
there
is
still
a
lot
of
dissension
about
this
notion
that
a
streaming
format
has
one
catalog
associated
with
it,
and
there
are.
There
are
some
people
who
have
asked
for
I
want
multiple
catalog
types.
L
L
M
Will
just
just
to
clarify
back
at
the
catalog
section
you
you
said
that
there's
an
identifier
of
him
and
you
put
number
one
as
first
the
just.
This
is
a
bit
of
a
clarifier
and
I'm
sure
Cullen
will
want
to
chime
in
and
correct
me
here.
But
what
we're
saying
is
is
that
the
the
identity
for
for
a
client
identifying
what
format,
whether
it's
warm
or
some
other
that's
happening
in
the
format
itself
and
not
part
of
mock
transport.
M
L
Yes,
the
what
I
proposed
was
every
you
can
invent
whatever
catalog
format
you
like
with
one
particular
requirement,
the
first,
the
first
variant
must
hold
a
number,
and
that
number
must
identify
a
registered
type
and
that
type
tells
you
how
to
parse
the
rest
of
the
catalog.
With
that
in
place,
a
client
can
receive
any
catalog
and
know
how
to
parse
it,
assuming
it's
compliant
with
parsing.
It
recognizes
the
type
or
else
I
could
say.
I,
don't
recognize
this
type
I
can't
pass
this
catalog.
L
Is
the
client
typically
knows
what
format
it's
asking
for
when
it's,
when
it's
given
something
when
an
hls
client
doesn't
inspect
the
m3u8
and
check
to
see
if
it's
Dash
formatted
right,
it
just
expects
it
to
be
m308,
and
it
throws
an
error
if
it
can't
pass
it.
That
also
works.
So
we
could
get
rid
of
this
consistent
registration
as
long
as
we're
willing
to
accept
that
each
client
must
know
the
type
of
format
it's
asking
for
before
it
asks
for
it.
L
Yeah,
that's
a
great
question,
I
think
during
setup
the
publisher
could
say:
I'm
publishing
two
formats
at
the
same
time
or
I'm
only
publishing
one
and
as
part
of
the
setup,
the
client
could
be
told
what
formats
are
available.
The
question
will
then
be:
how
do
you
ask
the
specific
format?
How
do
I
ask
for
the
catalog
of
type
1?
We
haven't
addressed
that
yet,
but
that's
a
great
idea.
C
You
know
will
I
was
going
to
ask
if
you
could
just
talk
for
a
minute
about
the
sort
of
more
generic
version
of
this.
So,
if
somebody
is
writing
a
new
streaming
format,
what
are
the
things
they
need
to
Define
it
and
I'm
trying
to
sort
of
you
know,
scope
this
work
from
a
sort
of
adopting
point
of
view
and
that
type
of
stuff
like
what's
what's
the
key
things
that
need
to
be
defined
in
any
one
of
these
that
writes.
L
In
any
streaming
format,
you
need
again,
the
idea
was
you
would
you
would
Define
how
to
identify
your
catalog
type,
so
you
would
have
you
would
write
a
catalog
that
at
least
the
first
variant
was
a
number
to
be
consistent
with
mock.
If,
if
we
go
that
way,
then
you
also
need
to
find
how
you
map
your
your
objects
to
the
core
mocked
messages,
in
other
words,
announce
how
how
to
subscribe
and
announce
and
publish
mapped
to
workflow
Behavior
within
your
streaming
format,
and
how
do
you?
L
How
does
your
media,
the
binary
media
payload
map
to
the
objects
that
are
being
transmitted,
and
then
you
need
to
define
the
workflow
issues
around?
How
do
you
authenticate
it?
How
do
you
encrypt
it
consistently?
How
do
you
signal
the
level
of
encryption?
What
type
of
error
messages
do
you
expect
that
are
particular
to
your
application
and
not
particular
to
mocked?
L
I
would
think
these
are
the
things
any
streaming
format
would
need
to
provide.
That
makes
sense,
and
maybe
yep,
maybe
there's
some
of
them.
We
need.
We
need
to
bake
a
few
requirements
into
mock
transport
itself,
which
says:
if
you've
got
to
make
a
streaming
format,
you
must
do
a
couple
of
things
and
then
we
list
as
few
things
as
possible.
But
by
doing
that,
we
get
interrupt
right.
We
get
in,
we
get
interoperable
streaming
formats
and
that
should
be
the
ultimate
goal.
H
Suhas
yeah
thanks
Phil
for
the
presentation,
I
think
this.
This
is
this
is
a
good
start,
given
that
more
and
I've
been
working
on.
How
do
we
do
like
the
the
point
that
you
made
on
having
us
other
streaming
formats
that
is
more
real-time
friendly
and
going
back
to
Collins
question
I?
Think
if
we
can
I'm
asking
you
in
general,
would
it
help
if
it
makes
sense
to
have
if
anyone
who
wants
to
define
a
container
or
streaming
format?
H
This
is
what
you
should
do
as
a
catalog
format
as
a
separate
thing
on
its
own,
and
then
we
have
the
what
us
seeing
how
cmaps
will
be
used
and
the
other
thing
the
lock,
which
we
are
called
overhead
container
levels.
They'll
say
how
that
will
be
used.
Would
that
make
harder
split
that
way
generate
anyone
who
wants
to
have
a
streaming
format
or
container
format
defined
they
they
all
Define
the
same
way
the
catalogs.
The
things
in
the
catalogs
should
be
defined
too.
L
L
We
can
certainly
do
that.
My
opinion
is
that
the
the
packaging
is
part
and
parcel
of
the
streaming
format
and
I'm,
not
convinced,
there's
enough,
there's
enough
repetition
or
or
repeat
use
of
of
a
precise
packaging
format
that
it
warrants
breaking
it
out
into
a
separate
spec.
We
already
have
cmath
it's
an
established
body
of
work.
We
can
just
ref.
Anyone
who
wants
to
use
cmap
can
make
a
little
reference
and
and
incorporate
it
in
their
document.
L
Do
I
need
another
RFC,
saying
I'm,
incorporating
cmath
in
in
cmaps
case
I,
don't
think
so
for
maybe
more
advanced
formats
that
are
particular
or
unique
to
mock
transport
that
we
developed
that
might
warrant
a
separate
content.
I'm
not
opposed
to
it
at
all
and
I
think
this
is
a
core
discussion
we
should
have
should.
Should
these
streaming
formats
become
basically
an
assembly
of
other
rfcs
that
Define
naming
and
packaging
and
they're,
basically
just
telling
which
of
these
are
going
to
work
together?
It's
definitely
something
to
consider.
L
E
Hi,
thanks
for
this
I'm
I,
just
want
to
understand
the
positioning
of
this.
So
the
idea
here
is
that
I
mean
this.
Presumably
this
would
be
an
internet
draft
and
it
would
propose
one
possible
streaming
for
an
example
of
a
streaming
form
that
could
exist
on
top
of
it
mock
transport,
but
any
streaming
format
would
have
to
have
this
common
varrant
at
the
beginning
to
Define
the
streaming
format
and
use,
but
then,
of
course,
other
other
documents
could
follow.
This
template
is
that.
L
That's
not
that
here
there
can
be
a
multiplicity
like
if
I
was
writing
a
VR
or
ar
format.
I
think
it
would
look.
Quite
there
would
be
enough
differences
that
I
wouldn't
want
to
try
to
expand
this
to
support
equirectangular
distribution
of
talent-based
media
I.
Think
there's
that
to
I
would
make
a
separate
one
for
that.
E
Like
a
straightforward
and
the
correct,
like
separation
of
functions
in
in
what
the
work
we're
doing
here
is
that's
good.
It
just
is
a
minor
knit
I
wonder
if
that
that
catalog
Baron
should
go
into
the
transport
just
because
well,
misconceptions
make
sense
to
me
that
the
transport
you
have
that
thing
says
here's
the
point
that
tells
you
what
what
extreme
requirement
Implement.
So
that's,
that's
kind.
L
Of
a
net
thanks,
it
might
except
I,
could
conceivably
have
objects
that
were
part
of
two
streaming
formats
for
some
reason
and
then
would
I
carry
both
both
bits
in
it.
But
yeah
we
could
add
a
header
to
every
object,
saying
what
streaming
format
it's
part
of
that
would
be
fine.
We
could
also
get
rid
of
that
warrant.
We
could
just
invent
unique
names
for
the
catalog,
and
that
would
let
me
call
call
a
particular
type
of
format
that
I
might
want
from
a
client
when
multiple
are
available
on
the
publisher.
E
B
G
G
We
have
to
figure
out
how,
if
a
client
supports
multiple
formats,
and
it
doesn't
know
what
it
can
request
or
by
contrast,
if
the
server
can
offer
multiple
formats,
what
happens
then
and
I
I
believe
status
like
The
Guiding
problem
for
What,
specifically,
we
should
end
up
picking
and
since
I
said,
like
it's
an
interaction
that
would
probably
have
to
go
into
transport.
The
second
thing
is
about
whether
warp
should
be
tied
to
cmf
I,
don't
think
it
should
be,
and
in
fact
the
at
least
draft
04
version.
G
The
previous
version
did
not
have
that
limitation.
Specifically.
The
observation
here
is
that,
in
order
to
define
a
stream
like
immediate
container
thing,
that's
layered
onto
mock,
you
usually
need
only
two
things.
You
need
things
that
goes
in
the
catalog,
and
that
tells
you
how
to
decade,
and
then
you
need
to
things
that
goes
into
the
objects
themselves
and
I
believe
the
original
draft,
like
calls
them
the
init
objects
format.
G
H
L
I
agree
with
you
on
on
both
points.
I
I'd
be
open
to
expanding
this,
to
include
non-cmf
based,
Packaging
I.
Think
that's
reasonable.
We
don't,
it
doesn't
only
have
to
be
cmaf
and
this,
as
you
point
out,
there's
not
that
assuming
my
packaging
is
reasonably
consistent
and
I
maintain
the
notion
that
I
can
switch
it
group
boundaries.
L
G
B
F
F
Maybe
the
version
or
something
like
that?
Maybe
the
version
of
each
streaming
format
spec
can
be
upgraded.
But
does
that
mean
we
have
to
constantly
rev
all
of
those
as
as
new
codecs?
Come
on
board,
those
kinds
of
questions
are
still
kind
of
fuzzy
to
me,
but
I
think
this
is
generally
going
in
the
right
direction.
We
need
to
get
to
those
details.
Next,
yeah.
L
I
agree
on
both
point
on
on
the
versioning
side.
Yes,
you
put
I
put
a
version
flag
in
there
because,
as
cmath
evolves
or
as
anything
evolves,
different
versions
of
this
draft
of
this
RFC
would
support
different
codec
combinations.
We
don't
want
to
imply
an
automatic
adoption
with
future
ones,
so
we
do
need
constrain
it
either
through
profiles
or
through
versioning.
It's
how
it's
typically
done
and
on
your
first
point,
the
to
be
clear.
There
isn't
a
separate
catalog
RFC
right
this.
L
F
Right
I
didn't
mean
the
RFC
I
meant
like
a
Martin's
Point
about.
Where
is
this
going
to
be
registered
these
variants?
For
for
identification?
Are
we
only
identifying
the
streaming
format
RFC
as
as
the
as
the
thing,
so
that
means
only
certain
tracks
were
specifically
only
the
only
the
catalog
tracks
would
have
identifying
information
and
the
actual
media
tracks.
You
wouldn't
really
know
how
to
identify
those
unless
you
first
looked
at
the
identifier
for
the
for
the
catalog
track,
so
are
we
only
going
to
register
streaming
formats?
L
I
I
think
we're
going
to
need
to
register
the
catalogs,
because
that's
the
only
that's
that's
where
you
want
to
stop
People
Bridge
idea,
putting
the
same
I
ID
bit
in
in
the
same
place
and
meaning
two
different
things.
So
we
need
registration
in
terms
of
the
media.
I,
don't
believe
we
need.
We
need
to
register
that
it
doesn't
matter.
It's
once
once.
I
know
my
format,
I'm,
just
transmitting
AV
content.
I,
don't
need
Flags
to
tell
me
that
this
is
cmf.
L
F
I
I
tend
to
agree
it
just
kind
of
breaks.
The
symmetry
of
all
these
things
are
just
tracks
and
if
you
can
identify
the
catalog
tracks,
you
know
deterministically
and
have
a
pointer
to
an
RFC
for
them.
But
you
can't
do
that
for
the
actual
media
tracks.
It
seems
a
little
odd
but
I'm
willing
to
live
with
that.
B
J
B
J
N
Cool
Hello
everybody,
wake
up,
I'm,
tired,
I
I
made
a
mistake
of
drawing
these
slides
again,
but
hopefully
it's
fun.
So
I
want
to
go
over
how
media
and
data
in
general
is
not
media.
Specific
I
think
that's.
The
thing
with
mock
transport
is
yeah.
There's
media
in
the
name
mock
transfer,
but
this
could
be
any
data.
It
could
be
chat
messages,
it
could
be
a
catalog,
it
could
be
Media
or
whatever
I,
just
kind
of
wanted
to
cover
what
actually
happens.
N
What's
an
end-to-end
flow
when
somebody's
producing
media
to
going
through
relays
to
consuming
it.
So
in
an
example,
we
have
a
producer's
OBS,
they
want
to
publish
some
media
and
we
have
a
consumer
VLC
and
they
want
to
consume
that
media.
These
are
two
separate
entities.
It
could
be
other
side
of
the
world
and
they're
they're
both
configured
with
some
upfront
information
based
on
the
service
right
now,
it's
the
connect
URL.
Basically,
where
you
connect
to
to
establish
the
connection
tracking
namespace,
what
what
do
you
publish
versus?
N
N
This
is
what
you
actually
connect
to
to
establish
the
connection
in
this
case.
It's
web
transport
because
it
has
the
HTTP
prefix
protocol.
A
namespace
I
took
one
of
the
Google
meeting
codes
and
I,
that's
my
namespace,
so
it's
Unique
within
that
connect,
URL
and
then
I.
Add
the
participant
at
the
end,
just
as
a
way
of
saying
like
I,
am
John,
Cena
or
I'm
publishing
on
behalf
you
know
or
consuming
John
Cena's
feed
and
then
an
auth
token.
N
N
It
works
in
some
situations
for
sure,
but
it's
the
easiest
thing
to
talk
about
and
kids
sexually
understand.
So
what
do
we
do
with
this
information?
Well,
the
first
thing
is:
we've
got
to
connect
to
that
URL
we
were
given,
so
the
url's
broken
the
three
pieces.
This
is
just
a
standard,
URL
stuff.
It's
a
protocol
host
path.
N
We
use
the
host
name
to
establish
the
quick
connection.
The
protocol
decides
if
we
use
web
transport
or
if
we
do
Native
quick.
Basically,
if
it's
yeah,
we
just
do
the
web
transport
handshake.
If
it's
in
there,
but
in
both
cases
we
send
we
do
a
little
mock
setup
which
includes
the
path.
So
we
have
all
the
information,
regardless
of
whatever
protocol
you
use.
N
N
Here's
the
full
diagram,
if
you
care
about
which
packets
are
being
sent,
we're
adding
the
blue
at
the
bottom
lock,
which
is
just
a
little
setup
frame
that
the
client
sends
first
and
then
the
server
replies
it's
very
similar
to
the
web
transport
connect,
request
and
response.
It
could
be
sent
in
parallel.
If
you
have
a
good
implementation
and
that's
that
little
asterisk
there
anyway,
we
got
a
connection.
The
producer
needs
to
tell
the
server
like.
Let's
say
a
client
is
connecting
like
OBS
is
connecting
some
ingest
server.
N
It
has
this
mechanism
to
say
by
the
way
here's
that
namespace
I
was
told
to
produce.
So
it
sends
this
extra
message
and
says:
hey
here's,
the
namespace,
you
told
me
to
publish
with
and
here's
off
and
then
the
other
side
says
yes
or
no
for
the
it's
in
the
announce,
okay
or
error.
I
should
have
clarified
as
well.
Green
is
just
my
the
producer.
The
person
trying
to
send
the
media
and
red
is
the
consumer
or
the
other
end.
N
We'll
talk
about
the
announce
a
little
bit,
because
it's
it's
not
necessarily
symmetrical,
but
it
will
get
there.
But
that's
really
all
you
need
for
the
producer
to
be
ready,
so
OBS
connected
to
a
server.
It
said:
hey
I,
want
to
publish
this
track.
This
WebEx
track
I'm
John
Cena,
nobody's
requested
it
yet,
but
it's
it's
technically
valid
it
is,
it
is
a
live
stream
and
yeah
namespace
is
effectively
tracked
bundle
Martin,
Duke,
it's
just
a
different
name
and
different
conceptually,
because
it's
not
tied
to
a
web
transport
session.
N
Anyway,
we
have
a
subscriber
Quest,
so
the
consumer
finally
decides
they
want
to
actually
watch
the
media.
Maybe
it's
the
first
viewer,
or
maybe
the
transcoder
started
up
or
something,
and
it
will
send
a
subscribe
request.
It
chooses
a
a
track
ID,
although
I'd
like
to
probably
rename
that
it
gives
it
six.
It's
a
way
of
a
shorthand
number
to
say
from
that.
N
If
you
send
any
objects,
the
Mark
6
I
know
that
it's
part
of
the
subscription
you
send
the
namespace
either
the
one
that
was
you're
configured
to
subscribe
to
or
the
one
that
you
received
from
the
announce,
that's
kind
of
why
I
say
it's
not
quite
symmetrical
or
symmetric,
and
then
the
name
you
subscribe.
You
need
this
catalog.
The
catalog
as
we've
discussed,
describes
other
tracks.
Well,
you
need
to
know
how
to
request
it.
N
That's
currently
undefined
it
could
be
with
like
having
a
well-known
name
like
catalog
as
the
string
or
we
could
use
some
sort
of
track
format,
some
way
of
deciding
that
this
is
a
catalog
track.
So
I
should
request
it
to
learn
about
other
tracks
and
of
course
you
can
send
off.
If
you
want
so
so
yeah
the
VLC
sent
to
subscribe,
it
says
give
me
the
catalog
and
the
other
side
says
sure.
N
I'll
start
I'll
start
doing
that,
so
the
producer
starts
pushing
objects
with
the
given
request
of
track
ID.
So
in
this
example,
they
request
a
track
id6
for
some
reason,
we're
gonna
sure,
let's
just
use
that
this
is
just
a
little
way
of
compressing.
So
we
don't
send
the
full
string
as
every
object
and
then
we
start
saying:
here's
group
15
object.
Zero
group
15
object,
one.
N
So
we
talked
about
a
little
bit
about
the
catalog
track.
I
wanted
to
talk
about
a
little
bit
more.
It's
just
attractive,
describes
other
tracks.
It's.
This
is
maybe
where
this
is
a
little
different
than
bundle
in
bundle.
I,
had
this
very
clear,
like
a
catalog
describes
the
entire
bundle,
but
now
it's
kind
of
vague
or
Cala
can
describe
other
name
spaces.
We
haven't
figured
it
out.
This
is
a
big
TVD
and
it's
not
part
of
the
draft
right
now.
This
is
not
part
of
mock.
Transport
relay
doesn't
know
that
catalogs
exist.
N
This
is
Media
encoding
parameters,
and
this
is
for
the
consumer.
Only
the
catalog,
so
OBS
creates
this.
It
says
here's
you
know
what
each
track
is
contains
and
VLC
reads:
this
relay
should
not
read
this
at
all.
It
should
not
parse
this
catalog
track.
It
could
be
encrypted,
so
yeah
we'll
still
do
that.
Here's
just
a
quick
example
of
what
data
it
contains.
N
So
let's
say
we
have
three
tracks.
We
have
the
name
of
each
of
these
tracks.
We
call
HD
SD
and
audio.
This
is
what
actually
gets
sent
with
the
Subscribe
message,
so
the
consumer
VLC
will
be
like
subscribe,
SD
and
the
relay
will
will
fall
forward
that
it
won't
know
what
the
contents
of
SD
are.
It
just
knows
how
to
forward
that
to
the
producer,
and
then
it
will
contain
some
other
information
that
actually
describes
the
contents
of
the
track
like
which
codec
it
uses.
N
N
That
shows
the
words
it's
a
way
of
advertising
what's
supported
and
we
have
to
figure
out
what
format
this
uses.
I
added
some
examples
at
the
bottom
move
is
what
warp
is
like.
We
just
use
the
existing
MP4
spec,
but
you
could
use
the
hls
dash
playlist.
You
could
use
something
custom.
We
could
make
this
Json
encoded,
or
this
is
kind
of
like
sdp,
there's
a
lot
of
existing
standards
that
try
to
describe
what
multiple
media
tracks
look
like
and
I.
N
So
once
we
know
the
catalog,
we
we
VLC
receives
a
catalog,
it
parses
it.
It
figures
out
that
there's
this
shd
SD
track
it'll
come
back
and
make
a
new
subscription.
This
time
is
a
new
ID.
This
is
I'm
calling
the
Subscribe
ID,
but
in
the
draft
it's
called
track.
Id
the
namespace
we
haven't
figured
this
out,
but
it
could
be
relative
to
the
catalog
and
then
it's
the
same
namespace
as
the
catalog
or
it
could
be
something
wholly
different.
N
So,
what's
really
missing
here-
and
this
is
probably
the
thing
that's
most
confusing
I.
Think
with
this
whole
thing
is
how
relays
actually
handle
this.
We
got
one
side
that
says
announce
I'm
willing
to
support
this
track,
name,
space
and
I
connected
some
URL,
and
you
get
another
side
that
says
I
want
to
subscribe
to
this
check
name
space,
how
on
Earth
like
do
relays
consolidate
them.
N
So
the
first
thing
I
want
to
make
make
clear
is
that
the
connect
URL
changes
on
every
hop
like
it
has
to,
because
it
contains
the
host
to
connect
to
like
it
can't
be
the
same
across
every
host.
It
could
be
different
protocols
too,
so
the
connect
URL
will
change
at
every
hop
and
it's
up
to
a
relay
to
have
a
routing
table
to
know
that
if
somebody
connects
to
this
URL
and
requests
this
resource
I
need
to
go
to
this
other
server
to
get
that
resource.
N
But
with
the
relative
track
names
you
can
also
rewrite
the
namespace,
that's
completely
optional
and
here's
one
example
that
I
would
personally
do
that's.
Why
I
wanted
to
do
it,
where
OBS
would
be
given
a
connect?
Url,
that
is,
connect
to
mock
with
live.twitch.tv
pixelated
and
some
namespaces,
some
random
random
things
to
make
sure
you
can
tell
unique
broadcasts
apart.
That
does
not
need
to
be
the
same
thing.
That's
given
to
VLC.
N
In
fact,
VLC
is
given
a
in
twitch's
case
and
is
given
a
an
edge
in
San,
Francisco
and
livevideo.net,
and
the
namespace
contains
routing
information
in
it
like
which
origin
it's
at
some
unique,
ID
blah
blah.
So
this
is
the
same
broadcast,
but
both
either
end
of
the
pipeline
are
configured
with
different
information
again
completely
optional.
It's
up
to,
in
this
case
twitch's
CDN,
to
figure
out
how
I
map
a
connect,
URL
and
namespace
to
the
origin
into
the
ingest
side,
and
it
can.
It
can
rewrite.
N
N
You
said
the
Senate.
The
client
always
sends
a
setup
message
and
then
it
will
send
an
announce
and
say
Here's
the
track
name.
Space
I
want
to
produce.
The
other
side
says
sure,
give
me
that
catalog,
the
client
says
sure
here's
the
catalog
as
object
zero
and
then,
if
a
request
comes
in
later,
somebody
wants
to
receive
like
the
HD
track.
Then
there
will
be
a
follow-up
subscribe
to
actually
get
that
track.
N
So
this
is
really
cool
because
you
can
have
a
case
where
a
client
connects
to
a
ninja
server
and
doesn't
send
anything
until
until
it's
asked
to
send
data.
So
you
can
imagine
a
broadcast
with
no
viewers
or
a
a
conference.
Call
that
has
no
other
participants
like
everything's
established
the
catalog's
published
it's
subscribed,
but
it's
not
pushing
any
data.
Yet
it's
not
pushing
data
until
somebody
asks
for
it.
With
a
subscribe
for
the
distribution
side,
the
client
is
connecting
to
a
server
again.
N
N
The
announce
is
really
only
used
in
contribution
case,
but
if
it's
symmetrical,
then
it
should
also
work
for
distribution
where
the
server
can
say
by
the
way,
here's
a
track,
namespace
I'm
willing
to
provide
and
the
client
either
either.
It's
told
that
which
track
name
space
is
configured
to
that's
kind
of
why
I
say
announce
is
optional,
then
the
client
says
give
me
the
catalog
subscribe,
send
it
as
object,
zero
and
and
then
eventually
can
request
the
proper
media
track
once
it's
parsed
the
catalog
and
then
finally,
here's
both
sides.
N
It's
a
mess,
but
I
think
it's
just
really
important
to
visualize
that
this
is
not
meant
to
be
a
contribution
or
distribution
protocol.
This
is
meant
to
be
both
simultaneously,
so
they
don't
share
any
number
namespaces.
So
subscribe
zero.
Either
both
sides
can
send
subscribe,
zero
and
it
will
work
just
fine
yeah.
That's.
J
B
B
Okay,
the
next
part
of
our
agenda
was
sort
of
just
an
open
discussion.
I
know
we've
kind
of
we're
a
little
bit
behind
I
think
what
we
originally
said
for
time,
but
some
of
that
discussion
is
happened
as
we've
gone
along
so,
but
if
people
want
to
just
have
General
discussion
about
the
drafts,
the
examples
how
this
is
supposed
to
work
now
is
your
moment.
B
E
I
I,
don't
think
I'm
gonna
have
50
minutes
worth
of
comment,
but
just
so
it
could
be
just
in
terms
of
the
way
forward.
So
it
sounds
like
the
deliverables
of
this
group
will
be.
The
moq
I
mean
assumingly,
something
like
the
moq
transport
draft
and
then
a
at
least
one
format.
Draft
like
like
the
warp
one
and
maybe
more.
If
other
people
want
to
make
them,
is
there
something
else
that
we
expect
to
produce.
C
C
E
B
B
B
E
N
L
F
E
Guess,
I'll
repeat:
yeah
I
mean
I
think
this
seems
like
a
sensible,
I
I'm,
not
I've,
read
the
the
mock
transport
thing,
but
not
this.
What
media
thing
as
you
might
imagine,
but
it
seems
like
the
from
what
has
been
explained.
This
is
a
reasonable
separation
of
of
of
functionality
on
the
two
documents
and
I
think
we
should
progress
towards
adopting
both
or
so
some
some
form
of
both
thanks.
H
To
kind
of
say
that
a
couple
of
us
will
be
submitting
a
updated
version
of
the
low
or
at
Continental
draft
that
would
kind
of
reflect
catalog
changes
and,
and
some
of
the
like,
the
payload
header
that
that
might
be
useful
for
some
of
the
real-time
use
cases,
and
also,
we
will
plan
to
update
the
architecture
spec
to
reflect
the
new
mock
transport
changes
for
ITF
117,
though
those
would
be
probably
come
Landing
in
before
that.
Thanks.
D
Glad
I'm
glad
that
I
went
after
suhas
I
I,
just
just
as
a
request
to
the
group,
especially
people
who
have
drafts
floating
around
I.
If
you,
if
you
could
make
sure
that
the
that
the
GitHub
repo
that
you're
using
for
your
draft
is
included
in
the
draft
that
that
that
would
be
great
Martin,
Thompson's
Martin
Thompson's
template
for
IDs
like
produces
that
semi-automatically
just
you
know
it
puts
up
at
the
top
of
the
drafts.
D
D
B
I
B
A
So
I
did
not
hear
anybody
in
today's
meeting
who
sounded
like
they
were
opposed
to
us
issuing
a
call
for
adoption,
which
of
course
goes
to
the
list
for
the
transport
draft.
I
think
the
the
moment
has
come.
Where
I
will
ask
explicitly.
Is
there
anybody
who
thinks
that
the
chair
should
not
issue
a
call
for
Dutch
the
transport
crowd.
A
A
So,
even
though
the
working
group
has
not
seen
this
particular
split
before,
and
even
though
this
is
currently
an
example,
rather
than
the
only
way
to
do
this,
I
I
think
personally,
the
right
thing
to
do
is
to
go
ahead
and
adopt
it
and
know
that
it
may
simply
have
either
a
higher
level
of
change
or
some
adaptive
radiation
into
multiple
graphs
describing
different
container
formats.
So
I
guess
my
question
to
the
to
working
with
with
Cullen
first
in
queue
is
knowing
that
it
might
be
the
first
of
several.
A
Does
anybody
object
to
us
going
ahead
and
bringing
it
in
to
a
working
group
repo
so
that
we
can
work
on
it
together
and
if
you,
if
you
don't
feel
my
thumb
on
the
scale
there
I
will
turn
on
my
my
I
think
for
adjusted
just
a
moment
and
send
the
video
of
me
putting
oh
I
have
to
find
it
putting
my
thumb
down.
So
you
you
know
what
my
personal
opinion
is,
but
we
have
several
people
in
queue
now:
Cullen
Spencer
and
Lucas
calling
her
first.
C
C
I
just
I
I
want
a
chance
to
go
in
common
and
work
on
those
and
I
wanted
to
focus
all
my
attention
on
getting
the
base
transport
draft
in
first.
So
I
would
appreciate
a
bit
of
time
to
actually
go
work
on
those
drafts,
like
you
know,
get
them
submitted
to
the
repo,
for
example,
before
we
agreed
to
before.
C
A
D
Oh
I'm,
sorry,
that's
because
I
I
didn't
realize
that
you
had
called
on
me
yet
so,
just
just
a
note
to
the
to
the
team
here
that
the
requirements
draft
is
not
in
a
GitHub
in
the
working
group,
GitHub
repo
and
that
you
know
so
not
in
the
mock
GitHub
organization.
I
think
is
the
way
our
iitf
organization,
so
we
would
pl
we.
So
we
should
plan
to
move
that
as
soon
as
you
all
have
a
repo
setup
is
that
right.
A
B
A
D
O
We
could
adopt
it
and
say
we're
going
to
throw
this
away,
but
I
I,
just
don't
see
why
we
need
to
do
that
right
now,
maybe
in
a
few
months
time
or
whatever,
like
after
the
next
ITF
work,
we
made
like
a
bit
more
progress
at
that
point,
whatever
there's
two
or
or
things,
I
think
that
the
approach
you
outline
Ted
is
is
good.
I
just
think
it's
slightly
too
early
to
make
an
adoption
call
for
those
things
cheers.
C
I
just
want
to
be
clear
on
a
move
to
particularly
with
the
the
the
warp,
the
the
repo
that
was
warped
and
now
became
transport.
It
has
so
many
open
issues
on
it
and
so
much
discussion
I
want
to
really
move
that
one
so
that
we
don't
lose
all.
That
would
be
my
one
request:
I
don't
care
about
the
other
week.
Those
people
may
think
it's
good
to
do
it
or
not.
B
A
A
But
we
would
have
a
single
GitHub
repository
so
that
if
there
were
issues
that,
for
example,
people
wanted
to
raise
against
it,
they
only
had
to
go
to
that
one
repo
And
subscribe
to
the
individual
pieces
they
cared
about.
So
that's
what
I'm
hearing
as
the
result
of
this
discussion
is
there?
Anybody
who
thinks
that's
not
a
fair
summary.
C
Ted
I
just
want
to
make
sure
you're
precise
on
something
here,
because
I
took
it.
I
heard
things
that
sort
of
like
we
will
have
multiple.
Each
draft
will
have
its
own
repo
inside
of
the
working
group.
Org
right,
that's
that's!
Our
plan
of
record
I
just
want
to
be
clear
on
that
because
it
sounded
like
you
were
thinking,
they'd
be
in
the
same
repo,
which
I
don't
think
they
will
be
like.
A
Okay,
so
an
action
item
for
for
Will
and
for
the
lock
authors
to
go
ahead
and
publish
into
the
internet
drafts
directory.
Whatever
you
think,
the
current
state
of
play
is
and
then
share
with
the
chairs
the
The
Source
you'd
like
to
have
put
into
the
repos
under
the
mock
Dash
WG
org
in
the
meantime,
chairs
will
issue
the
call
for
adoption
for
the
transport
craft
and
we'll
move
with
the
help
of
James
and
Spencer
the
existing
requirements
draft
under
the
same
work.
A
A
B
D
Sounds
like
a
deal
and
let
me
start
a
side
show
so
that
I
have
something
to
ask
about,
and
I
am
asking
you
to
share
the
screen
and
just
for
the
people
who
are
taking
notes.
I
am
not
taking
notes
for
this
right
now,
so
please
do
oh,
and
it
asked
do
I
really
want
to
share
my
screen.
Yes,
I
do
cool
and.
D
D
This
has
been
adopted,
and
this
is
just
the
details
on
the
the
adoption
poll
and
the
feedback
we
got
and
US
replying
to
the
comments
on
the
mock
mailing
list,
and
then
we
submitted
uh-05
version
May
31st.
Last
week
we
were
closing
so
in
our
repo
tags
mean
something
we
closed,
all
the
tags
that
issues
that
were
tagged
for
adoption
in
the
GitHub
repo.
D
And
so,
if
you
click
on
those
links
in
in
the
in
the
presentation,
that's
in
the
meeting
materials
you
see
that
and
we
provided
the
devs
for
zero
four
to
zero
five
and
then
the
diffs
from
zero
five
to
the
zero
zero
working
group
draft,
and
that
was
submitted,
June
5th,
which
was
what
two
days
ago
and
the
chairs
approved
that.
So
that's
how
we
got
where
we
are,
and
so
let's
talk
about
where
we're
going.
D
So
one
of
our
labels
that
we're
using
is
current
author
Focus,
which
is
authors,
are
working
on
PR
text
and
one
of
the
things
that
we
had
talked
about
in
Yokohama.
We
had
the
suggestion
for
Bernard
that
a
significant
portion
of
the
draft
called
exploration
of
mock
scenarios
and
data
model
would
be
better
placed
in
the
use
case
requirements
draft
and
we
agreed
with
that.
We
just
haven't
done
that
waiting
for
adoption
of
our
draft
just
so
we're
not
just
randomly
moving
text
around
between
individual
contributions.
D
D
Think
for
my,
my
understanding
of
where
we
are
in
the
protocol
drafts
is
that
we
have
a
lot
better
understanding
of
the
nuances
there,
but
just
for
us
to,
because
you
know,
because
we
have
a
section
about
security
and
Indian
Security
in
the
requirements
section
of
our
draft,
just
basically
making
making
sure
that
we
can
that
we
can
explain
to
people
what
what
that
means
so
that
they,
you
know,
so
that
they
understand
what
to
look
for
in
the
in
the
requirements.
On
that.
Any
questions
on
that.
D
If,
if
done,
and
if
people
can
jump
in
anytime
so
for
priority
for
discussion,
is
the
label
we're
using
basically
that
we
need
other
issues
to
be
resolved?
First,
one
that
we've
had
using
terminology
correctly
for
relays
and
caching
and
replication
points
and
media
translators
which,
if
I
remember
correctly,
those
were
the
things
that
are
named
in
the
Charter?
D
That
seems
like
a
really
reasonable
start
to
produce
the
architecture
draft
that
we
are
I
charted
to
produce,
and
this
is
something
this
is
something
that
I
want
to
contribute
to,
because
it's
it.
You
know
it
it's
kind
of
gating
for
a
lot
of
the
things
we
want
to
say
in
the
use
case,
especially
requirements
draft.
We
want
you
know
we
want
to
describe.
D
So
two
things
to
do
things
to
be
sure
and
mention
about
this
is
our
thinking
is
that
mock
requirements
in
our
draft
apply
to
them
the
way
a
mock
system
works
and
the
mock
protocol
specifications
may
have
their
own
requirements
that
are
specific
to
that.
You
know
to
that
protocol
or
that
or
that
or
to
that
format
or
whatever
you
know,
whatever
we're
doing
and
any
any
comments
on
this
one
yet.
D
D
an
easy,
an
easy
one
is
that
we
reread
Dash
05
after
we
submitted
it,
and
we
had
proudly
announced
that
we
were
going
to
submit-05
as
the
working
group
zero,
zero
draft
with
no
changes,
and
but
we
do
have
a
a
largely
editorial
issue
that
will
be
working
to
resolve
by
117,
and
we
also
have
one
from
I
believe
this
one's
from
Martin
Duke
about
filtering
use.
Cases
based
on
quick
properties
is
the
title.
D
The
idea
is
basically
for
each
use
case
that
we're
talking
about
what
value
does
doing
that
use
case
over
quick,
add,
like
I
said
just
because
you
can
use
mock,
doesn't
mean
you
should
use
mocker
that
you
need
to
use
mock
so
basically
trying
to
identify
what
the
basically
trying
to
identify.
What
the.
I
I
D
D
O
Hey
Spencer,
yeah
I,
just
I
just
want
to
pick
up
on
this
last
Point,
not
not
just
from
mock
but
like
anything
just
because
you
can
use
characters,
I
mean
you,
you
should,
but
you
see
like
a
whole
load
of
of
drafts,
of
like
X
over
quick
and
whatever,
and
it's
always
clear
what
the
benefits
are.
So
for
some
people
they
don't
care
like
they.
They
it
doesn't
matter.
They
just
want
to
try
something
out
or
or
there's.
O
There's
benefits
aren't
specifically
from
the
protocol
itself,
but
in
the
kind
of
the
the
the
deployment
and
operations
of
something.
So
you
know
quick
has
features
like
connection
IDs,
which
help
load
balancing
or
things
we've
tried
to
capture
in
the
applicability
OR
manageability
drafts.
So
for
the
specific
issue
in
the
question,
I
probably
can't
help
in
any
way.
O
But
definitely
this
is
something
kind
of
I'm
trying
to
raise
awareness
for
in
in
a
general,
quick
using
community
that
we
want
people
to
use
Quick
where
it
makes
sense
and
maybe
there's
ways
we
can
help
them
identify
where
it's
good
or
bad
for
them
and
still
let
them
make
their
own
decision.
And
but
if.
E
O
From
from
the
current
drafts,
we
have
maybe
at
some
point
in
the
future.
You
know
we
needed
to
define
the
thing
before
we
see
how
people
use
it
and
what
patterns
emerge.
So
maybe
maybe
we
should
just
grab
a
coffee
when
I
see
you
in
person,
we
can
chat
a
bit
more
about
that,
but
yeah
got
my
support.
Yeah.
That.
D
D
You
know
what
what
what
advantages
are
you
getting
and
if
you're,
giving
up
anything
or,
if
you're,
exposing
yourself
to
any
problems?
What
what
problems
are
they
so
I
think
that
I
think
that
this
is
a
really
important
point
for
both
this
draft
and
the
RTP
over
quick
draft
in
an
avd
core
I.
Don't
know
if
how
many
people
in
this
working
group
have
noticed,
but
the
RTP
over
quick
work
has
now
been
renamed
as
roq,
so
rock
so
we're
Contin.
D
K
Something
like
a
commission
that
they
give
to
them
like
once,
and
it's
weird
and
I
think
that
yeah
I
mean
my
concern
is
that
the
walking
group
is
very
focused
on
the
real
estate
scenarios.
I
mean
we
it's
clearly.
One
of
the
world
is
one
of
the
big
features
one
to
have
be
able
to
use
a
CDN
to
distribute
a
large
conferences
yeah,
but
he
used
the
peer-to-peer
operation.
K
I
So
we
see
that
today
in
streaming,
where
you
could
have
an
hls
stream
coming
into
a
company
and
then
have
a
peer-to-peer,
quick
or
caching
going
on
within
the
company.
So
anyway,
it's
something
to
figure
out
whether
this
is
part
of
mock
or
just
something
completely
separate,
but
there
are
use
cases
for
it.
It
is
used
today
very
widely
in
streaming.
So
it's
it
is
a
real
thing,
typically
with
a
webrtc
data
Channel,
but
you
know,
obviously
quick
is
better
than
sap
for
that
purpose.
D
D
You
know
that
it
applies
to
other
things
running
over
quick
as
well,
and
so
I
think
what
what
you're
talking
about
there,
especially
if
that
becomes
a
generic
here's,
how
to
do
quick
over
ice
document
would
be,
would
be
a
maybe
a
good
example
of
that,
but
we
we
could.
But
we
can
talk
about
that
more
on
the
mailing
list
that
we
have.
K
Yes
and
I
I
think
there
should
be
an
initiative
of
doing
something
that
quick
with
our
eyes
or
whatever
it
is
that
we
use
instead
of
eyes
and
but
once
we
have
quick
over
eyes
or
even
if
we
have
just
basically
think
of
people
running
quick
because
they
are
on
the
same
local
network,
the
land
of
the
scenario.
Then
we
we
should
make
sure
that
the
moq
works
in
that
case,
if
you
do
have
ice,
gives
you
connectivity.
D
D
J
D
D
D
We
do
have
work
to
do
and
the
goal
that
I'm
one
of
the
girls
that
I
have
is
to
try
to
make
mock
systems
easier,
to
implement
and
deploy
based
on
what's
in
the
use
cases
and
requirements
draft.
So
that's
not
the
that's
not
you
know,
that's
Spencer's
goal,
that's
not
the
only
goal,
but
that's
what
I'm
shooting
for
any
other
questions
on
anything
that
I've
talked
about.
D
I
Yeah
I
I
think
it
would
be
useful.
You
know
if
it
would
help
I'm
willing
to.
You
know,
give
to
provide
tutorials
on
web
codex
or
web
transport
or
coding,
or
anything
like
that.
No,
we
even
have
Now
sample
code
that
people
could
play
around
with
I
know.
Jordy
has
put
out
some.
You
know
we
have
other
sample
codes,
so
I
think
there's
some
resources
that
people
could
use.
B
Okay,
that's
that's
cool.
One
thing
I
was
thinking.
Is
that
I
think
several
folks
maybe
pointed
out
is
that
the
transport
protocol
does
not
actually
need
to
transport
media.
You
can
so
we
some
you
know
we
could
come
up
with
a
you
know,
an
interop
type
draft
that
transports
something
simpler
than
than
video.
If
people
want
to
make
sure
that
the
transport
and
Pub
sub
pieces
are
working
as
expected,
independently
from
being
able
to
actually
send
media
bits,
but
anyway,
Luke.
N
K
As
we
should
have
some
recommend
on
that,
a
very
minimal
things
that
we
transport
I
mean,
like
maybe
mimic
the
movement
of
a
mouse
or
something
like
that,
so
that
we
can
have
something
that
was
real
time
and
and
can
be
displayed
but
and
and
yeah
it's
tight
I
mean
my
UF
estimate.
Is
that
it's
about
four
weeks
of
work
to
be
ready.
So
we
are
hardly
have
four
weeks
until
the
ietf.
So
it's
it's.
B
O
That's
looking
at
other
things
related
to
Quick,
you
know
and
we
shouldn't
try
and
make
a
quick
mega
super
table.
I
think
that's
unmanageable,
but
there
are
some
overlaps
like
key
technology
things
here,
and
you
know
you
could
effectively
divide
that
table
up
into
little
sub
projects
and
to
me
that
would
seem
to
work
the
sub
projects,
particularly
for
remote
folks,
who
can't
be
there
in
person
that
that
need
to
kind
of
focus
on
whatever
they're
doing
and
I.
O
Don't
know
what
the
the
population
constituency
is
for
mock
of
people
who
will
be
there
in
person
versus
remote
and
stuff.
So
maybe
you've
got
a
better
handle
on
that,
but
it
feels
definitely
we
should
try
and
do
something.
You
know,
there's
no,
there's
no
like
we're
going
to
be
assessed
at
the
end
of
if
we
achieved
our
goals
or
not.
Really
it's
just
just
fun.
B
D
D
So
I
applaud
the
planning
for
a
hackathon
whatever
that
means
and
because
I
think
I
think
this
group
does
really
well
with
the
opportunity
when
they
have
the
opportunity
to
spend
time
talking
to
each
other
for
an
extended
period
of
time.
So
you
know
no
matter
what
you
all
do
at
the
hackathon
sounds
like
a
good
use
of
time.
D
To
me,
the
the
one
thing
that
I
was
going
to
ask
is:
we've
we've
I
we've
been,
we
mentioned
the
use
of
an
architecture
and
the
use
of
terminology
to
describe
the
architecture
that
are
starting
to
get
into
actual
drafts.
That
people
are
submitting
and
requesting
publication
on
is
is
do
people
think
that
that's
a
thing
that
we
could
talk
about
at
our
meeting
in
San
Francisco?
D
B
So
this
was
you're
correct.
That
was
also
part
of
the
topic
we
were.
We
wanted
to
cover
in
this
section
in
the
agenda.
One
was
hackathon,
the
other
one
was.
What
should
we
talk
about
in
the
meeting
time
so
yeah?
Let
me
just
quickly
if
nobody
else
wanted
to
talk
about
happening.
Let
me
summarize
that
I
Heard
lots
of
people
say
they're
interested
in
participating,
so
we
will
make
sure
that
we
set
up
a
table,
we'll
coordinate
with
web
transport.
B
This
is
something
that
people
want
to
hack
on
or
if
anyone
has
any
other
ideas,
you
know
please
prescribing
them
to
the
list
yeah.
Moving
on
to
what
Spencer
want
to
talk
about,
which
is
what
we're
going
to
do
in
San,
Francisco
eating
wise,
so
I
we
requested
two
90-minute
sessions.
I
think
they
have
announced
the
scheduling
thereof.
B
We
will
we
will
get
to
argue
about
different
things
and
we
have
been
arguing
about
so
far
because
there
seems
to
be
some
coordination
around
transport
now.
I.
Imagine
by
that
time,
there'll
be
plenty
of
issues.
We
would
like
to
start
digging
into
that
have
been
identified
or
will
be
identified
against.
The
transport
sounds
like
we
will
want
some
agenda
time
to
talk
about
streaming
formats,
possibly,
and
then
you
mentioned
architecture,
Spencer
and
I.
B
Think
I
heard
suas
earlier
say
that
there
was
planning
a
revision
of
the
architecture
draft,
so
I
I
think
at
least
right
now.
It
doesn't
seem
unreasonable
to
add
some
time
to
talk
about
what
we're
look,
what
we
think
we're
going
to
do
to
meet
our
architecture,
requirements
and
and
getting
on
the
same
page
terminology
is
also
also
heard.
Mention
was
a
little
bit
of
a
to
do
so.
That
seems
pretty
reasonable
to
me.
I'm,
not
sure
if
anybody
else
has
clots
on
that.
D
N
Yeah
I
wanted
to
say
as
well
like
I
know
we're
returning
for
an
architecture,
but
I
really
want
to
plus
one
what
Christians
said
like
this
should
work
pop
the
Hop.
You
shouldn't
need
to
spin
up
a
big
architecture,
so
I
think
there's
a
lot
of
overlap
between
a
non-normative
architecture
and
requirements
document
and
they
could
be
combined.
D
B
Okay,
so
I
mean
other
than
that.
If
folks
have
other
things,
they
want
to
bring
or
request
agenda
time
before
San
Francisco,
please,
you
know,
send
notes
to
the
chairs.
You
know
we'll
be
making
the
agenda
obviously
sometime
before
then,
but
those
are
kind
of
that's
the
rough
shape
of
things
we
think
we'll
be
talking
about,
and
somebody
who
thinks
we
should
be
talking
about
something
else.
Let
us
know
I'm,
not
sure
I
had
anything
else
so,
but
Spencer
does.
D
Well,
I
just
wanted
to
thank
the
chairs
and
the
working
group
for
a
really
productive
meeting
to
enter
a
meeting
today.
It
see
you
know,
it
seems
like
to
me
that
we
get
we're
getting
better
every
time
we
meet
and
so
and-
and
it
seems
to
me
that
the
virtual
interim
meetings
really
really
have
really
helped
also,
but
thank
you
all
for
the
work
you're
doing
and
thank
you
to
the
chairs
for
the
way
you
are
leading
the
pack
of
squirrels.
B
It
may
not
have
been
visible
unless
you
were
carefully
following
the
the
mocti
repo,
but
there
was
a
there
was
a
lot
of
work,
a
lot
of
I
know.
A
lot
of
discussions
happened
a
lot
of
time,
investment
and
I.
Think
I
just
want
to
acknowledge
folks,
or
this
is
a
volunteer
job
and
people
are
putting
a
lot
of
time
in,
and
we
appreciate
that
foreign.
A
Am
always
in
favor
of
sending
people
home
if
we're
done
and
I
think
we're
done.
So
let
me
add
my
thanks
to
to
everybody
for
putting
in
the
work
today
and
to
those
who've
been
putting
it
in
consistently
both
on
both
sets
of
our
author
teams
for
getting
us
to
here.
We'll
take
up
the
action
items
and
see
you
on
the
list.