►
From YouTube: IETF-MOQ-20230307-1400
Description
MOQ meeting session at IETF
2023/03/07 1400
https://datatracker.ietf.org/meeting//proceedings/
C
So
can
folks
can
see
the
participant
account
is
still
creeping
up,
so
we're
probably
going
to
wait
just
a
minute
or
two,
but
while
we're
waiting,
perhaps
you'd
consider
volunteering
to
serve
as
a
scribe
or
backup
scribe.
All
you
need
to
do
is,
let
us
know
your
name
by
putting
it
in
the
chat
room
or
speaking
it
aloud
either.
One
would
be
great
thanks.
C
D
C
Remember
reminder
we
don't
need
this
person
said
this
and
then
the
next
person
said
that
style
we
have
a
recording,
that's
all
going
to
be
handled
by
the
recording,
we're
just
taking
note
of
the
decisions.
So
it's
a
relatively
low
effort
type
of
thing
to
do
and
we
would
really
appreciate
it.
Thanks.
C
Okay,
well,
we've
climbed
up
enough
that
I
think
it's
probably
time
to
go
ahead
with
the
note.
Well,
if
you
are
new
to
the
IHF,
this
no
will
is
not
the
sum
total
of
ITF
policies.
In
effect,
it
is
instead
a
pointer
to
them.
You
can
read
these
reminders
at
the
top
and
then
the
definitive
information
is
instead
of
linked
documents
in
the
in
the
bottom.
Essentially,
there
are
some
IPR
requirements
and
some
behavioral
requirements
that
you
must
adhere
to.
C
C
D
C
Source
is
noting
in
the
chat
that
he
can
see
and
hear
fine,
that's
great
to
hear
we
are
still
looking
for
a
primary
Note,
Taker
and
one
backup.
So
if
you
can
serve
as
one
or
the
other
now
would
be
a
great
time
to
let
us
know,
because
we
will
have
to
pause
the
entire
process
of
three
hours.
While
we
wait
for
somebody
to
to
sign
up
for
this,
and
it
could
get
very
tedious
for
three
hours
worth
of
looking
at
this
one
slide.
C
Alan
asks
if
there's
a
prize
for
the
scrub.
No,
our
next
step
is
I
will
start
asking
my
phone
to
roll
a
22-sided
die
for
me
and
we'll
ask
people
to
invent
excuses
on
the
Fly
depending
on
when
their
number
on
the
die
comes
up.
So
really
this
would
this
would
go
a
lot
faster
if
somebody
would
just
agree
to
serve
this
scribe.
C
Martin
Duke,
thank
you,
Martin
everybody
else.
We
will
deputize
you
as
Deputy
scribes,
just
leap
into
the
note
thinking,
tool
there
and
help
art
now.
Remember
you
don't
have
to
write
everything
down,
Martin
it's
just
if
we
make
a
decision
and
hopefully
fingers
crossed,
there
will
be
a
few
decisions
today
for
Martin
and
the
backup
scribes
to
write
down
and
we
can
go
on
from
there.
Thank
you
for
not
making
me
break
up
the
22-sided
die.
C
And
again,
to
reflect
from
the
chat.
Martin
has
suggest
that
if
you
do
say
something
in
the
mic
and
you
want
to
make
sure
it's
captured
corruptly,
please
do
check
out
the
notes
as
soon
as
possible.
Well,
obviously,
you'll
get
a
chance
to
look
at
them
again
when
they
get
turned
into
formal
minutes,
but
we
can
check
them
out
earlier.
If
that's
even
better,
now,
agenda
bashing:
this
is
our
current
agenda
Mr
via
and
rules.
We
are
two
minutes
away
from
the.
C
F
B
B
We
were
starting
to
get
into
some
things
that
might
go
better
in
an
architecture
draft,
so
maybe
just
adjusting
the
agenda
to
include
something
about
you
know.
Maybe
this
is
under
planning
for
Yokohama,
but
basically
what
the
plan
is
for
those
two
ideas
between
now.
You
know
between
you,
know,
Yokohama
and
then,
of
course,
Beyond
we're
not
going
to
finish
that
instantly.
G
C
Okay,
so
let's
do
this
as
Spencer
suggests,
in
the
wrap
up
and
planning
for
Yokohama
I
think
that
might
stretch
the
amount
of
time
we
need
for
that
20
minutes
so
we'll
take
that
out
of
the
issue.
Discussion
unless
object,
model
or
relays
goes
a
little
faster
than
that
is
everybody.
Okay,
with
that
change.
B
C
C
C
We
think
for
today
we're
trying
to
get
consensus,
at
least
from
those
of
you
who
joined
us
today
on
the
big
rocks
the
object
model
and
relays
and
then
try
during
the
issue
section
to
determine
which
issues
need
to
be
resolved
before
a
draft
is
adopted.
So
that's
the
goals
for
the
meeting
and
I
think
we're
ready
to
go
and
Maria
is
saying
that
the
audio
is
fine,
so
I
will
not
log
out,
but
I
think
I
will
hand
it
over
to
Alan.
C
J
C
A
C
A
K
J
Okay,
the
first
thing
that
I've
tried
to
do
is
start
with
the
almost
consensus
that
we
have
and
the
almost
consensus
that
we
have
is
to
use
tracks
as
the
building
block
in
the
moq
protocol.
Basically,
we
think
of
a
truck
as
a
specific
encoding
of
a
media
stream.
I'm
happy
to
have
someone
suggest
another,
what
the
mega
stream,
because
a
major
stream
kind
of
conflict
with
the
stream
issue
in
quick
Etc.
J
J
D
J
Now.
Second
part
of
the
thing
that
we
almost
have
in
a
oh
good,
the
consensus
on
is
the
presentation
of
what
the
track
is
and
the
almost
consensus
is
the
track.
Is
we
presented
a
series
of
objects
and
an
object
is
carrying
some
content.
I
mean
the
part
of
the
of
the
media
stream,
a
part
of
the
track
and
that
content
typically
will
be
encrypted.
J
Will
Point
not
be
visible
by
realize
I
mean
we,
we
can
decide
to
have
extension
of
the
architecture
with
the
equivalent
of
back-to-back
user
agents
and
things
like
that.
But
as
a
basis
I
mean
the
realized,
do
not
see
the
inside
of
the
media
and
the
object
doesn't
have
just
a
binary.
Blob,
of
course,
also
has
metadata
and
the
metadata
is
used
to
manage
transmission
and
we'll
go
to
the
definition
of
metadata.
Later
different
application
can
Define
what
an
object
is
in
different
ways.
J
J
J
J
E
J
But
the
track
itself
is
opaque.
The
talking
that
means,
if
it's
opaque
so
in
the
equivalent
of
HTTP
you'll,
be
that
the
pass
component
will
be
a
whatever
the
application
says.
It
is
it'll,
be
sufficient
to
identify
the
track,
but
nobody
can
go
inside
nobody,
but
the
application
can
go
inside
that
blob
and
and
find
that.
Oh,
these
parts
is
composed
of
this
and
this
and
that
components
that
I
can
use
I
mean
gnome
and
maybe
they
are,
but
that's
for
the
application
to
decide.
That's
not
for
the
transport
level
or
the
relays.
L
L
So
when
we
have
that
authentication
tag,
you
typically
can't
do
anything
with
the
media
until
you
get
that
authentication
tag
and
do
and
do
the
decryption.
So
we
need
to
be
mindful
that
that
the
object
granularity
may
be
dictated
by
what
the
application
wants
to
render,
and
it
can't
render
anything
until
it
has
authentication
tags
for
the
Indian
encryption
context.
J
And
yes-
and
that's
probably
some
some
kind
of
Overlook
there
I
have
this
mental
model
that
the
authorization
is
performed
when
the
client
or
the
relay
first
tries
to
access
the
track
by
asking
the
origin.
Hey
can
I
do
that
in
fact.
That's
the
very
reason
why
we
have
a
URL
and
another
genius
that
I
can
have
a
transaction
there
and
that
transaction
says:
hey
I
am
a
relay.
I
am
getting
a
client
that
wants
to
connect
to
these
moq
interim
video
conference.
D
J
Object
with
a
higher
granularity
I
did
not
envisage
that
because
we
typically
do
not
do
that
today
we
say
HTTP,
even
you
either
you
are
allowed
to
read
the
content
of
a
URL
or
you
are
not.
You
are
seldom
a
lot
tool,
just
read
them
in
the
old
lines,
but
we
can
still
debate
that
later.
I
I
suggest
that
you
you
open
an
issue
for
that
is
that
okay,
MO.
J
Okay,
so
let's
continue
I
mean
the
the
way
we
see
authorization
here
is
that
it's
pretty
much
the
same
as
HTTP.
It's
there,
the
the
client
or
the
relays
I
mean
do
a
transaction
with
the
origin
or
a
representative
of
the
origin
to
define
whether
they
are
able
to
access
the
media
or
not,
and
the
relays
enforce
that
now
there
is
a
little
bit
of
architecture
there
and
at
some
level
this
kind
of
authorization
issue
is
very
similar
to
what
we
have
in
EAP.
J
J
In
particular,
we
have
one
debate
which
is
very
clear
in
the
discussion
which
it
says:
hey
An
Origin,
that
is
basically
The
Logical
owner
of
the
track.
It's
not
necessarily
the
publisher.
There
are
many
systems
in
which
the
publishing
is
delegated
to
some
kind
of
content
management
system.
In
video
conferences,
the
publishing
can
be
done
by
the
different
participants
themselves.
J
I
mean
there
is
a
rich
thing
there,
so
it
may
well
be
that
the
transaction
there
that
we
do
is
there
that
doing
the
transaction
the
user
will
tell.
Oh,
you
want
to
be
look
at
this
football
game.
This
is
the
URL
you
shall
actually
use,
and
probably
the
UI
is
decorated,
with
authorization
tokens
and
whatever,
so
that
you
can
get
the
actual
content
so
that
there
might
be
some
redirection
happening
at
that
level.
J
J
Second
proposition:
we
have
a
lot
of
discussion
on
GitHub
on
Not,
Just,
Trucks,
but
also
emissions
or
broadcast
or
think
the
values
nature
and
we
discussed
composition.
We
say:
okay,
the
composition
is
saying
that
I'm
going
to
have
questions
video
on
that
video
and
and
the
and
the
shared
slide.
That's
a
composition,
issue
yeah.
J
B
J
J
J
Am
I
am
not
terribly
convinced,
I
I
think
we
could
get
pretty
much
the
same
service
by
carrying
a
list
of
track,
URL
that
are
born
to
be
on
the
same
origin
in
a
single
transaction.
Okay.
That
will
be
that
will
be
just
probably
just
equivalent
in
terms
of
transport
and
number
of
messages
and
number
of
transactions
and
wait
time
Etc
and
will
not
need
to
add
another
concept.
B
H
J
No
no
I
mean
I'm
looking
at
other
questions,
I'm
putting
on
the
on
the
chat
room
as
well,
yeah
and
and
and
clear
I
mean
that's
a,
but
my
my
good
feeling
is
that
like
to
have
a
model
that
is
as
simple
as
possible
to
say
we
do
drugs.
Maybe
we
do
several
trucks
at
the
same
time
and
and
then,
if
you
want
to
have
a
higher
level
construct,
the
application.
Does
it
but
I
mean,
as
I
said
it's,
we
can
have
a
consensus
description.
The
consensus
discussion
at
the
end
of
this
presentation.
B
B
B
J
Clearly
we
have
cases,
we
have
basically
two
views
on
publishing.
You
have
one
publishing
that
says:
hey
publishing
media
is
done
through
some
kind
of
content.
Management
Service,
it's
not
exactly
the
point
of
moq
the
the
URL
that
Define
the
track
points
you
to
the
content,
Management
Service
and
you
get
the
content
from
there
right.
J
S
of
view,
which
is
quite
common
in
video
conferences
in
which
the
content
is
contributed
in
real
time
by
the
participants,
and
if
the
content
is
provided
in
real
time
by
the
participant,
then
it
would
make
sense
to
have
that
content
through
relays
or
for
whatever,
and
it
would
also
obviously
make
sense
to
have
an
authorization
transaction
to
decide.
Whether
Christian
is
indeed
authorized
to
send
video
automatico
right
now.
F
J
J
J
You
can
join
a
conference
what
it
is
in
the
middle
of
the
flow,
and
then
you
have
to
be
able
to
join
that
in
a
way
that
is
not
showing
you
have
to
be
able
to
re-synchronize
your
experience
after
you
have
had
a
network
event
of
some
kind,
so
it
makes
sense
to
have
synchronization
points
which
are
defined
as
you
can
start
transmission
from
that
point,
and
if
you
have
started
with
receiving
transmission
from
the
point
from
this
point,
then
you
can
safely
play
the
media
and
it
will
be.
It
will
be
good.
J
And
what
can
be
also
done
is
that
that's
what
we
see
in
some
implementation
is
that
if
the
system
is
overwhelmed
and
cannot
send
everything,
it
might
Amazon
a
current
group
and
jump
to
the
next
one
to
diminish
the
load
on
the
network,
so
that
we
drop
in
the
tail
I
think
I
mean
decide.
That
groups
are
indeed
synchronization.
Point
is
something
that
we
should
have
consensus
today,
because
otherwise
I
mean
we
are.
We
are
going
to
I
would
say
Wonder
in
the
movies,
but.
J
Is
a
on
the
group
metadata
object
and
group
metadata
for
congestion
response?
I
mean
we
know,
especially
if
we
have
relays
that
relays
would
have
to
implement
some
kind
of
congestion
response,
because
if
they
find
out
that
they
are
receiving
data
from
the
Upstream
at
the
rate
higher
than
what
the
downstream
can
process,
they
have
to
prune.
Some
of
that
otherwise
you're
going
to
make
big
cues
and
those
big
cues
make
the
experience
terrible.
C
J
L
M
L
L
So
one
one
thing
that
immediately
comes
to
mind
is
we
we
may
want
to
consider
something
like
the
groups
are
always
stateless
and
the
objects
may
be
stateful
between
them.
That's
a
little
bit
like
saying
that
there's
dependencies,
but
I
think
it's
a
little
bit
more
in
the
line
with
understanding
what
relays-
and
you
know
it
should
be
like
elements
would
already
understand.
Stateless
transactions
would
correspond
to
a
group,
but
then
stateful
objects
would
be
more
like
you
know:
subgroups
sub
transactions,
the
actual
transaction
itself.
You
know.
L
No
well,
it's
not
about
the
dependencies
between
the
objects.
It's
about
the
delivery
because
we're
not
trying
to
capture
the
application
semantics,
because
the
application
already
knows
it's
semantics:
we're
trying
to
capture
what
the
different
elements
of
the
data
model
need
to
know
about
these
semantics
and
for
for
the
relays
and
the
other
elements,
not
the
application
itself.
L
J
J
J
J
C
C
Think
you
might
have
missed
Cullen's
question
some
time
ago
about
whether
in
a
layered
encoding,
the
two
different
layers
would
be
in
one
track
or
two
so
I
think
we
we
may
need
to
to
come
here
and
make
sure
that,
when
we're
talking
about
things
above
the
track
layer
that
we
have
in
the
mental
model,
both
this
is
a
collection,
a
set
of
things
which
are
not
related,
and
this
is
a
group
and
I
really
wish
I'd
used
a
different
word.
Just
then
this
is
a.
C
Think
there's
a
good
bit
of
discussion
in
the
chat
at
this
point,
suggesting
that
for
the
synchronization
thing
we
might
want
to
rethink
the
naming
of
that.
To
talk
about
you
know
an
access
point
or
or
something
different,
but
I
I.
Think
from
my
perspective,
the
the
kind
of
basic
thing
of
like
is
this
group
handled
together.
C
I
had
missed
before
this
proposition
2
and
Cullen's
question
that
handled
together
was
by
itself
even
ambiguous
when
you
were
dealing
with
layered
encodings.
So
we
may
want
to
think
a
little
bit
more
about
a
more
generic
mechanism
for
indicating
the
interrelationships
that
that
may
not
be
as
simple
as
required
and
not
required.
E
C
What
what
this
means
is
we're
pushing
this
to
the
application
layer
and,
if
that's
where
it
belongs,
that's
where
it
belongs
and
I'm.
Okay
with
that
as
a
as
a
proposition
for
this.
What
that
turns
out
to
mean,
then,
is
that
the
only
case
where
you'll
get
this
track
set
or
bundle
or
whatever
you
want
to
end
up
calling
it
is
when
they're
not
required
they're
authorized
together,
but
not
required
to
be
rendered.
J
D
C
I
I
So,
firstly,
yeah
there's
a
lot
of
discussion
on
the
thread
with
this,
and
she
spoke.
Synchronization
I
think
is
a
misleading
term
here,
because
it
invokes
sort
of
time
sync
as
we're
used
to
its
syncing
audio
and
video.
This
is
more
about
joining
the
stream
or
accessing
the
Stream.
So
I
think
it
is
a
fundam.
It
should
be
a
fundamental
property
of
a
group
as
part
of
its
definition.
I
Second
point:
it
should
also,
by
virtue
of
you
being
able
to
access
it
at
this
point,
it's
going
to
be
independent
or
stateless,
as
has
been
previously
described
so
I,
don't
need
any
other
information
to
start
consuming
this
track.
It
may
not
be
audio
video,
it
could
be
long
location
or
something
like
that.
But
those
key
attribute
is
it's
independent.
From
this
point
on
the
objects
within
the
group
may
depend
upon
that
group,
so
they
may
depend
upon
you
receiving
the
start
of
the
group.
The
third
point,
I
think
is
important.
I
Is
it
should
have
a
numeric
identifier,
because
that
automatically
conveys
a
sequence
and
it's
going
to
be
important
for
relays
to
be
able
to
find
the
last
group
in
order
for
you
to
join
the
track
automatically.
A
client
will
not
know
where,
where
how,
where
the
data
looks
like
in
a
track,
and
it's
going
to
ask
for
give
me
the
last
group
that
I
can
join
and
I
think
by
having
them
numeric,
we
simplify
the
sequence.
Otherwise,
we
have
to
convey
it
as
a
separate
attribute.
J
D
D
J
J
K
Hello,
so
first
off
I
think
this
is
a
great
summary
I
think
these
slides
are
fantastic
because
there's
been
way
too
much
text.
This
is
a
good
way
of
distilling
it
down.
I
just
want
to
go
over
a
slide
two
or
the
proposition
two,
as
in.
What's
the
the
point
of
an
emission,
the
goal
in
my
mind,
a
mission
broadcast
is
the
same
thing
in
my
mind,
but
it
was
always
meant
to
be
a
way
of
saying
these
tracks
are
synchronized,
as
in
they
share
presentation
timestamp.
K
They
share
delivery
order,
so
they
can
be
prioritized
relative
to
each
other.
So
you
can
say
audio
from
this.
Emitter
should
arrive
before
before
a
video
from
the
same
emitter,
for
example,
there's
a
bigger
question
is:
if
you
can
do
that
synchronization
when
you
have
unrelated
sources
as
in
two
separate
emitters,
how
do
you
prioritize
between
them
and
my
current
answer?
Is
you
can't
like
this
is
effectively
a
property
of
an
emission?
K
Is
that
it
is
synchronized,
so
I
think
it
should
be
there
I
think
composition,
just
a
layer
on
top
that
effectively
says
we
don't
know
how
to
synchronize
these
two
emissions.
So
have
that
at
client
but
yeah,
that's
just
my
two
cents
and
tracks
the
scope
to
an
emission
so
I'm,
not
even
sure
if
they
need
to
separate
URL
or
if
they
should
just
be
scoped.
K
J
K
K
G
Okay,
I
I
think
my
my
question
and
little
it
in
some
ways.
Oddly
follows
up
a
little
bit
on
it's
more
an
observation
about
about
this
layered
track.
So
look
clearly,
I
think
you
know
the
relay
needs
to
understand.
What
it
drops
is
the
right
way
of
thinking
about
these
two
different
tracks.
When
we're
talking
about
audio
and
video-
and
it
seems
like
priorities,
are
you
know
a
very
direct
way
to
do
that?
G
But
when
we
get
to
a
a
layered
codec,
we
have
to
wait.
There's
two
decisions
designed
paths.
We
could
go
down
here
right.
We
could
put
them
in
one
track
or
we
could
put
the
two
different
layers
in
two
tracks
and
the
either
way
the
relay
is
going
to
have
to
have
enough
information
to
know
understand
that
it
should
drop
the
high
quality
or
the
you
know
the
higher
quality
track
before
the
lower
quality
track
right
and
it
I
think
it's
all
right.
G
If
layered
codecs
are
a
little
bit
more
complicated
for
the
application
to
to
deal
with
so
I
could
certainly
see
that
we
could
easily
do
this
as
those
the
adaptation
layer
was
a
separate
track
and
the
relays
didn't
really
need
to
know
any
more
than
they
know
that
audio
or
video
are
connected.
They
just
know
the
priorities
for
this
thing
that
you
know.
It's
that
all
the
complexity
of
conducting
those
two
layers
together
was
handled
by
the
Manifest
or
was
sort
of
application
knowledge.
G
G
But
now,
if
we
put,
if,
if
we
put
the
layered
codec
the
two
layers
in
the
same
track,
then
we
definitely
have
to
be
putting
enough
information
on
each
object
that
it
understands
the
priorities
of
those
objects
in
the
relays
notes
which
of
those
objects
to
track
to
drop
inside
of
the
track,
and
it
also
makes
it
a
little
bit
harder
for
a
client
to
sort
of
say
something
like
I
only
want
the
low
bit
rate
version.
The
I
only
want
the
low
bit
rate
layer.
G
I,
don't
want
to
receive
the
high
bit
right
layer
and
at
the
point
where,
where
you
know
you
want
you're
receiving
the
low
bit
rate
layer
and
you
want
to
temporarily
try
the
high
bit
right
layer
and
then
go
back
again,
I
don't
know
so.
I
think
that
those
I
think
that
would
be
pretty
easy
to
map
out
what
the
there's
really
only
two
designs.
There's
only
you
know
we
have
to
go
A
or
B.
There's
no
other
designs,
they're
going
to
work
here.
G
J
J
J
J
How
do
we
organize
it?
Is
it
easier
to
organize
it
with
several
drugs?
Is
it
easier
to
organize
that
is
a
single
track
with
metadata
linking
the
object?
I
mean
the
single
track
has
the
advantage
that
you
will
get
a
single
sequence,
number
of
other
objects.
That
gives
you
an
implicit
delivery
order,
but
I
think
at
that
point
the
the
discussion
I've
seen
on
GitHub
are
a
bit
exploratory
and-
and
we
should
have
probably
a
focused
discussion
on
that.
C
C
J
N
N
My
my
thinking
here
is
that
we
are
talking
object
as
an
output
of
an
encoding
like
like
an
encoder
frame
at
a
certain
quality
on
on
certain
temporal
dependency.
That's
kind
of
my
definition
of
an
object
is
I
just
want
to
make
sure
if
that
kind
of
Alliance.
What
you're
thinking
that's
on?
That's,
basically,
the
proposition
one
slide,
if
I'm,
not
wrong
and
and
second
thing
thing
is
that
on
the
like,
we
can
go
one
by
one.
N
N
J
J
I
think
a
lot
of
what
you
said.
There
are
falls
back
into
this
initiative.
We
have
to
have
on
how
exactly
do
we
deal
with
layout
encoding
and,
yes,
you
could
have
a
complete
dependency
graph,
saying
that,
oh
in
my
group,
object.
10
depends
on
object,
nine
and
seven
and
four
and
two
and
one,
and
if
any
of
those
is
not
arrived.
Yet
there
is
no
point.
J
J
E
Okay,
I
wanted
to
comment
on
preposition
to
specifically
the
issue
of
tracks
being
related,
so
there
is
the
there
are
two
when
doing
the
live
streams,
or
are
often
two
priorities
that
do
kind
of
things
to
goals
we
want
to
simultaneously
achieve
one
is
we
want
to
prioritize
audio
over
video
generally
and
the
second
is
we
want
to
prioritize
new
content
over
old
content
and
the
problem
here
is
well.
How
do
we
combine
those
priorities?
E
Do
we
always
prioritize
new
audio
and
old
audio
over
new
video
and
old
video,
and
the
answer?
Is
you
usually
want
new
videos
and
New
audios
and
new,
all
I'm,
sorry,
old,
new
audience
and
new
videos
and
all
the
ideas
and
old
videos?
But
the
problem
here
is
that
new.
In
order
to
do
that,
you
have
to
have
some
shared
timing
model
between
those
two,
since
you
generally,
you
want
newer
audio
before
the
catch
here.
E
Is
you
want
to
prioritize
new
video
over
all
the
audio
and
in
order
to
do
this
kind
of
prioritization
in
order
you,
since
you
don't
care
about
in
order
to
do
this
kind
of
prioritization,
they
need
to
be
synchronized.
Since
it
doesn't
make
sense
between
two
sources,
which
are
not
synchronized,
but
you
can
do
that
with
the
resources
which
are
too
high,
oh,
and
that
is
where
roughly
the
concept
of-
and
this
is
roughly
the
reason
why
a
transport
would
need
to
know
about
things
more
than
individual
tracks.
From
my
perspective,.
J
Yeah
I
mean
the
basically
what
you,
what
you
propose
is
something
like
we
discussed
that
I
think
before
is
after,
if
to
ask,
are
part
of
a
bundle
force
them
to
have
the
same
structure
of
groups
or
or
something
of
that
nature.
So
we
can
say
that,
okay,
if
we
go
fast
forward
to
group
10
on
video,
we
should
also
go
fast
forward
to
group
10
on
audio.
E
Well,
well,
it's
not
just
that!
It's
like
I
If
I
have
a
player
buffer
of
10
seconds.
I
want
to
only
have
10
seconds
of
video
and
audio,
because
I
don't
care
anything
in
the
past,
but
of
course,
that
kind
of
buffer,
the
kind
of
time
control
is
per
clock,
Source,
not
per
track
or
per
multiple
independent
tracks,
which
don't
share
a
clock
source.
J
Yeah
I
mean
yes,
I
mean
I
I,
hear
you
I
I
must
say
that
I
am
a
concern
about
the
extra
complexity
of
having
synchronization
point
between
two
arcs
and
that
in
practice
it
may
be
that
sending
the
audio
fast
enough
is
good
enough.
But
so
basically
that's
another
very
concrete
point
that
you
want
to
discuss
suppose
that
I
have
an
audio
track
and
a
video
track.
J
O
O
We
are
saying
that
the
groups
is
a
is
a
group
of
objects
that
belongs
to
the
same
track,
that
they
start
with
a
tap
with
a
with
an
access
point
that
says,
with
the
they
are
decodable
from
from
the
beginning,
and
they
are
also
have
monotonically
increasing
ideas.
Okay,
so,
basically,
if
the
group
always
starts
with
a
decodable
access
point
and
the
objects
are
identified
also
with
monotic
monotocol
increasing
ideas,
why
do
we
need
groups?
So
what
groups
give
us?
O
K
J
O
O
J
J
J
O
J
D
J
L
L
I
think
on
groups
I
think
it's
relevant
to
consider
them
directly
in
the
protocol,
because
people
have
been
assuming
that
groups
are
addressable,
we've
always
talked
about
objects
being
interrupted,
but
I
think
really
more
likely.
The
groups
are
the
most
addressable
things
and
entities
are
subscribing
for
or
grabbing
the
groups,
not
the
individual,
logics.
C
L
C
C
Think
we'll
we'll
we're
going
to
ask
the
folks
working
on
this
to
do
is
to
go
back
through
the
chat,
because
I
think
we're
still
looking
for
agreement
on
the
properties
of
objects
for
and
now
that
thing
which
might
be
a
above
track
and
I,
think
that
there
were
some
emerging
agreement
in
the
chat,
in
particular
about
the
relationship
between
the
application,
selected,
decodability
or
or
encoder
behavior
and
its
relationship
to
each
one
of
those,
and
so
that
might
be
the
way
that
we
can
approach.
This
next
is
to
say:
okay,
assign.
C
Say
a
represents
this
relationship
to
the
encoders
presumption
of
behavior
by
the
decoder
and
by
the
relay
and
I
think
that
might
help
us
when
we
come
to
Yokohama
I,
do
think
that
there's
a
lot
of
valuable
stuff
on
these
slides
and
I
think
the
conversation
has
been
very
useful.
Thank
you
very
much,
but
I
think
there's
still
a
bit
left
to
do.
C
B
B
Great
quote
from
Luke,
like
Ted
mentioned,
we've
all
got
our
own
preconceived
notions
of
how
media
is
supposed
to
work
over
the
last
30
years.
We
need
to
step
back
and
really
explore
the
different
roles
why
they
exist,
what
data
they
need
to
function
we'll
be
able
to
justify
any
messages
and
their
contents.
Once
we
can
map
out
how
data
needs
to
flow,
so
I
thought
that
was
a
great
great
quote
and
it
made
me
think
a
little
bit
because
we
work
on
some
similar,
but
not
identical
media
use
cases.
B
B
So
one
of
the
things
we
were
talking
about
is
one
of
the
ways
we
got
started
was
basically
saying.
Well,
what
are
the
roles
and
if
we're
Our
intention
is
to
describe
what
relays
are
doing,
let's
talk
about
what
relays
are
not
doing
just
so
that
we
understand
what's
already
being
handled
somewhere
else
in
the
in
the
mock
universe
before
before
you
involve
relays
I
what
yeah.
B
But
so
like
I
said,
we've
got
things
to
think
about,
especially
after
we've
heard
what
other
people
are
saying
and
that
subscribers
handle
the
other.
The
other
side
of
that
basically
providing
subscriber
requests,
consuming
catalog
messages
and
consuming
object
messages,
and
then
the
media
Source
was
generating
media
content,
encoding
it
possibly
and
encrypting
it
possibly,
and
the
media
I
think
would
be
doing
the
same
thing
that
the
media
Source
did
in
reverse
order.
B
Like
I,
say,
I
think
this
is
probably
a
good
yeah.
This
is
a.
This
is
a
good
place
for
me
to
just
mention
the
other
ideas
we've
been
suddenly
talking
about
in
the
design
team.
One
was
what
was
about
a
so
an
entity
that
creates
catalogs
or
creates
a
composite
of
catalogs,
and
then
we
have
some
discussion
about
a
definition
for
something
called
an
emitter
and
receiver
and
we
are
try.
B
B
So
that
takes
us
to
like
I
say
this
is
stuff
we
started
out
with
for
will,
but
basically
looking
at
what
minimal
distribution
topologies
would
would
look
like,
and
so
this
is,
if
you
don't
have
a
relay
and
if
you
do
and
then
maybe
a
more
interesting
topology
like
I
say
this
is
the
one.
This
is
the
one
where
we're
showing
like
a
full
ingest
and
full.
You
know
and
distribution
again
this
this
was
a.
This
was
a.
B
This
was
a
figure
diagram
that
was
originally
taken
from,
will
and
then
discussed
a
bit
and
modified
a
few
places.
So
people
may
have
seen
something
like
that.
This,
the
the
one
thing
that
changed
during
our
discussions
was
thinking
about
what
it
means
to
be
an
origin
and
potentially
a
back-to-back
subscriber
publisher,
and
there
may
be-
and
there
may
be
some
more-
there
may
be
some
more.
B
So-
and
this
is
actually
a
another-
will
diagram
that
we
had
modified
a
bit
to
try
and
to
try
and
explain
what
the
different
you
know
the
different
roles
are
and
between
between
media
sources
and
media
syncs,
and
then
what
relays
and
what
Origins
actually
look
like
there
a
bit.
So
you
know,
we've
got
again
starting
at
the
top.
B
What
exactly
it
means
to
be
a
media
mixer,
for
instance,
and
then
two
endpoints
having
a
Web
Conference
through
a
relay
where
each
endpoint
may
have
all
of
the
roles,
publisher
or
subscriber
media
source
and
media
sync.
And
then
a
publisher
streaming.
The
game
through
a
CDN
to
a
client
where
there's
just
a
Cascade
of
of
relays.
B
I
Hey
Spencer,
thanks
for
putting
all
this
up
just
a
quick
comment
as
we're
looking
at
this,
the
the
diagram
here
for
two
endpoints
having
a
Web,
Conference
or
a
relay
both
endpoints
would
be
publishing
and
subscribing
the
diagram
shown
there
is
it's.
The
one
on
the
left
is
publishing
on
the
one
on
the
right
is
subscribing.
You
would
actually
need
two
lines
right:
they
they
should
both
be
publishing
and
both
subscribing.
It's.
B
Right
and
thank
you
these
so
I
think
one
of
the
things
that
I
told
the
design
team
I
hope
we
push
down
more
on
is,
basically
you
know,
we
kind
of
have
an
understanding
from
about
some
of
the
lines,
but
making
sure
that
we
have
all
the
lines,
because
you
know
these,
you
know
as
you.
As
you
see,
these
pictures
don't
include
the
lines
for
the
media
flow.
This
is
basically
kind
of
the
relationship
on
publishing
publish
subscribe,
but
yes,
hi
Tim.
B
P
P
So
we
want
to
make
sure
that
we
don't
send
data
back
to
the
publisher
now
how
I'm
doing
that
today
is
tracking
the
published
request,
flow
stream
or
or
flow
ID
of
some
kind.
That
says
that
that
was
where
the
Subscribe
also
came
from
and
then
we'll
not
send
it
back
so
I
feel
like.
We
need
to
have
some
standard
for
handling
that,
especially
in
the
case
of
multiple
streams
and.
D
B
Excellent
and
I
see
that
I
see
that
the
note
takers
are
typing
away
on
that
point,
and
thank
you
again
thank
you
for
that
note,
takers
and
just
for
anybody.
That's
in
the
conference,
if
you
keep
an
eye
on
what
the
notes
say
to
make
sure
that
you
were
captured
correctly,
we'll
probably
all
be
happier
so
Alan.
A
Yeah
I
have
one
question
on
this
slide
on
the
right
hand:
side
where
it
says
mock
origin,
and
it
has
the
four
boxes.
Yeah
I
understand
that
in
the
picture
there
are
some
Origins
that
have
four
boxes,
but
I'm
not
sure
why
every
origin
would
need
to
be
for
a
Subs
scrub,
subscriber,
for
example,
or
a
sink.
B
N
Yep
thanks
man,
sir
and
I,
agree
with
Adam,
not
every
origin
required
to
to
be
a
media
source
and
a
media
sync
in
in
many
cases,
it's
the
opposite
of
that,
where
we
don't
want
Origins
to
be
involved
in
any
encrypted
flows
to
access
the
raw
payload,
it's
more
like
less
like
in
webex.com.
It
does
not
look
into
media,
that's
going
through
that.
B
B
B
B
C
B
Cool
thank
you,
and
so,
if
I
go
into
slide
eight,
these
were
the
examples
of
mock
endpoints
that
we
had,
which
I
think
that
may
be
starting
to
head
towards
that.
The
suggestion
that
Ted
raised-
and
so
you
know
we're
publishing
a
stream
or
we
are
a
Web
Conference
client,
which
may
have
a
lot
of
things
going
back
and
forth,
but
also
three
of
our
examples
were
for
where
for
middlebox
functionality,
which
we
were.
B
B
P
Q
D
B
Yeah
I
think.
Another
thing
we
are
figuring
out
as
we're
going
along
is
exactly
what
the
responsibilities
of
the
division
of
responsibilities
is
between
the
application
and
the
mark
protocol.
You
know
basically
how
much
how
much
does
a
mock?
How
much
does
a
mock
implementation
do
for
you
so
I,
like
I,
said
I'm
I'm
nodding
my
head
up
and
down
there.
Yes,.
B
B
So
what
we
are
trusted
to
do
to
modify
an
object
header
to
forward
subscriptions
to
other
entities
to
forward
the
Publishers
to
match
subscribers
to
store
the
published
content,
which
is
we'll
talk
about
more
I'm
sure
to
validate
authorization,
credentials
for
published
subscriber
Quest
and
I've
I've
had
a
question
in
my
mind
about
how
how
involved
Origins
are
in
in
authorization
and
I.
Think
this
this
conversations
we're
having
here
have
been
very
helpful
for
me
with
that
as
well.
B
So
no
questions
on
this
slide,
then
let
me
go
to
the
next
slide,
things
that
mock
relays
are
not
trusted
with,
and
the
design
team
has
talked
about
this
a
bit
less,
but
this
list
has
been
out
there
in
our
shared
space
for
pretty
much
the
whole
time.
We've
been
a
design
team,
not
parsing,
catalog
messages,
not
parsing,
object,
message:
payloads,
not
originating
subscribe
messages
and
not
originating
published
messages.
A
Good
morning
Spencer
question
about
originating
subscribe
messages.
So
I.
Imagine
if
you
have
a
relay
where
you're
waiting
for
a
consumer
to
your
subscriber
to
show
up
issue
a
subscribe,
then
a
relay
can
subscribe
on
their
behalf
to
an
upstream,
for
example,
but
it
also
seems
like
you
might
want
to
have
relays
that
are
pre-subscribed
to
certain
things
which
you
anticipate
subscriptions
for,
so
is
that
something
that
is
allowed,
or
does
it
just
not
fit
into
this
particular
taxonomy
of
of
relay.
B
So
I
would
I
think
I
would
answer
that
to
say
it
doesn't
fit
into
this
taxonomy
yet,
but
one
of
the
things
that
I
think
we
also
have
to
do
to
move
ahead
and
make
progress
here
is
to
figure
out
what
what
is
actually
relay
functionality
and
what
is
actually
back
to
back
endpoint
functionality,
and
that
may
be
a
bit
more
obvious
on
the
next
on.
The
next
slide
is
that
does
that?
Does
that
work
for
you,
Ellen.
B
Yes,
yes,
exactly
exactly
so
a
thing
we
have
been
talking
about
is,
of
course,
the
definition
of
minimal
relay
functionality,
so
that
you
know
exactly
what
you're,
what
what
we're
saying,
which
is,
if
I
tell
you
that
I'm
a
relay
can
I
actually
forward
anything.
You
know
so
I
mean
that's
like
Basics
right,
but
if
I
tell
you
that
I'm
a
relay,
what
other
things
can
I
do
and
that's
actually
the
next
slide,
so
please
be
ready
to
jump
back
into
queue
for
that.
N
N
I
agree
with
Adam's
concerned:
there
I
think
we
need
to
take
a
step
back
and
think
about.
There
are
roles
like
publisher
role
and
relay
role,
sorry
publish
a
role
on
the
subscriber
role
and
there
is
a
physical
or
virtual
entity
that
are
sitting
in
somewhere.
That's
performing,
that's
called
a
mock
relay
and
we
need
to
basically
say
what
roles
that
apply
to
mock
relay
and
on
both
publisher
and
subscriber
role
would
apply
to
mock
relay.
N
That
means
that
they
can
subscribe
on
behalf
or
publish
on
behalf
of
the
previous
relay
or
the
previous
client
they're,
connecting
to
to
the
to
the
to
that
mock
relay
and
when
we
kind
of
take
these
roles
a
separate
thing,
and
then
you
apply
apply
to
these
boxes
like
the
mock
release
or
mock,
end
points
or
a
transcoder
or
something.
Then
we
can.
N
We
can
basically
say
the
roles
Define,
the
functionalities,
that,
if
that
that
really
could
do
and
I
would
strongly
think
for
kind
of,
like
encourages
not
to
think
about
the
core,
minimal,
relay
functionality
and
maximum
relay
functionality.
Yeah
to
keep
it
simple,
I
would
just
say
realize
anything
that
that
does
publish
a
role,
a
subscriber
role
and
it
does
not
have
access
to
end-to-end
encrypted
Keys.
Anything
beyond
that
should
be
have
a
new
name,
not
something
some
special
form
of
relay
thanks.
B
I
agree
that
so
you
said,
step
back,
I
would
say
step
sideways
to
step
forward
that
that,
for
us
to
push
down
to
the
next
layer,
the
next
level
of
what
we've
been
talking
about
and
saying
much
like
Alan
was
asking.
If
does
this
taxonomy
do
what
we
needed
to
do
and
if
it
doesn't,
what
do
we
need
to
change
in
order
to
do
be
able
to
do
what
we
need
to
do
so
definitely
definitely
agree
on
that.
B
The
the
you
know,
so
you
we're
also
talking
about
the
definition
of
we're.
Also
talking
about
the
definition
of
what's
the
relay
and
what's
a
back-to-back,
lock,
endpoint
and
I
think
I,
say
I
think
the
next
slide
actually
helps
us
guide
that
conversation
a
little
bit,
but
we've
been
having
a
spirited
conversation
among
the
design
team
members
within
the
last
24
hours
on
that
so
I
know,
there's
more
work
to
do,
but
I'm
I'm,
like
I'm
liking.
What
suha
said?
B
P
Audio
yeah
there
we
go
yeah,
it's
cool
I
I
had
to
rejoin
excellent
I
was
just
gonna
quickly.
Add
a
use
case
for
the
reason
why
a
publisher
or
a
relay
may
need
to
originate
a
published
message,
and
that
reason
is
with
fragmentation
and
double
fragmentation.
If
we
allow
that,
so,
if
I
have
a
transmitter
publishing
at
9000
into
you,
my
messages
will
be
larger
and
datagram
messages,
and
then
there
will
be
fragments
within
that.
The
relay
is
going
to
receive
that
pass
it
around,
providing
it.
P
B
B
I
Hey
Spencer
I,
just
I,
want
to
see
how
to
answer
Ellen's
original
question,
but
I
also
want
to
answer
Tim's
and
yours
relays
can't
subscribe
on
their
own
behalf
because
look
look
at
what
they're
not
trusted
with
passing
catalog
messages,
the
catalogs
Define
the
subscription
IDs
so
relays,
don't
know
what
to
subscribe
to
because
they
they're
not
trusted
with
reading
the
catalogs.
They
are
simple
components:
they're
given
instructions
and
they
follow
the
rules.
I
If,
if
they're
asked
to
do
more
than
that,
then
by
this
taxonomy
they're,
not
a
relay
anymore,
so
I
I
think
per
Allen's
question.
If
you
want
to
pull
content
to
the
edge
of
your
relay
you
the
relay,
can't
do
it
because
it
doesn't
know
what
to
pull.
You
have
to
give
it
a
message
through
your
command
system
or
through
your
call
to
the
edge
system
that
would
instruct
the
relay
what
to
subscribe
to,
and
it
may
and
then
it'll,
be
there
in
advance
of
your
true
clients,
but
I.
I
Don't
think
we
should
break
the
model
here.
That
a
relay
is
the
simple
component,
because
that's
the
one
that
we
can
really
scale
up.
If
it
has
to
understand
catalogs,
then
we
have
to
constantly
update
the
relays
every
time
there
is
a
new
Behavior.
We
don't
want
that.
We
want
a
reliable,
reliable,
simple
thing.
B
N
There
we
go
clarification,
or
you
know
asking
for
to
what
will
said
I
think
a
relay
should
definitely
be
able
to
forward
a
subscribe,
yeah
down,
I
I,
think
I,
don't
know
if
we
are
capturing
that
or
not
according
to
subscribe
or
publish,
because
if,
if
real
does
not
have
the
content,
it
has
to
forward
it
somewhere
towards
the
origin
like
what
Christian
was
talking
about
and
that
needs
to
be
captured.
Probably
we
need
to
basically
add
that
as
what
it
can
do,
that
should
be
the
meanwhile
functionality.
B
P
B
B
Like
I
said,
you'll
notice,
you'll
notice
that
what
we're
talking
about
here
is
now
in
a
document
yet
because
I
don't
think
we're
through
suhas
could
I
ask
you
to
take
a
look
at
the
notes.
It
looks
like
your
last
comment
may
have
been
been
missed
and
I
was
agreeing
with
two
or
three
different
things.
You
said,
so
please
please
check
and
make
sure
that
the
notes
include
what
what
I
was
agreeing
with
sure
I'll.
Do
that
thanks
Mr!
Thank
you.
B
So
let's
I
don't
have
anybody
else
in
queue.
So
let's
go
to
what
mock
relays
do
so
the
meta
the
the
prime
directive
for
relays
that
I've
gotten
is
that
they're
doing
things
that
do
not
require
access
to
unencrypted
Media
payloads
and
that's
that's
what
I've
been
working
with
in
my
mind
for
a
while
and
then
in
conversations
with
Will
in
the
last
36
hours
or
something
like
that
he
was.
He
was
also
mentioning
the
thing
about
not
wanting
to
have
everything
in
the
universe.
B
That's
able
to
see
unencrypted
media
metadata.
So
that's
actually
that,
like
I,
said
that's
actually
more
restricted
than
the
model
I
had
been
using.
In
my
mind
and
I'm
still
processing
through
what
the
implications
of
agreeing
with
Will,
which
I
want
to
do,
what
those,
what
those
implications
are,
but
just
going
down
the
list
that
we've
been
working
with,
we
said
so
replication
a
word
that
basically
says
I'm
subscribing
to
one
broadcast
and
I'm
replicating
the
same
broadcast
to
a
subscribe.
B
Basically,
you
know
once
you've
decided
to
cash,
how
much
you
cash
and
what
you
can
do
with
that
that
amount
of
media
information
is
going
to
be
kind
of
up
to
the
network
designers
and,
let
me
say
the
last
thing
and
then
we
can
just
go
crazy
at
the.
This
is
my
last
slide,
but
we've
been
talking
about
rate
at
rate
adaptation
and
that
had
made
it
onto
my
list
of
what
relays
to
because
we've
got
this
we've
got
this
item
in
the
mock
Charter.
B
B
C
C
We
have
some
elasticity
in
the
issues
resolution.
Let's
take
the
the
questions
now.
If
there
are
questions
on
on
this
presentation
and
we'll
see
how
it
goes,
we
are
a
little
bit
over
time,
but
not
as
badly
over
time
as
we
were
before
you
had
a
fair
amount
that
came
in
during
the
presentation,
so
hopefully.
B
A
Yeah
I
just
wanted
to
maybe
highlight
something
that
the
question
that
I
had
that
and
will
and
I
were
discussing
in
the
chat
so
which
is
about
this.
This
idea
of
preceding
content.
So
what
he
said
there
I
think
makes
a
lot
of
sense,
which
is
that
most
streams
like
this
are
not
of
interest
and
there's
no
way
a
third
party
CDN
could
handle
preceding
all
of
them,
and
that
makes
a
lot
of
sense.
A
B
B
Q
It's
a
good
morning,
thanks
Spencer,
having
trouble
reasoning
about
this
relay
because
I
guess
I,
don't
understand
the
end
to
end
encryption
relationships
and
I
I,
wonder
if
this
is
in
scope
of
this
work
like
if
like
if,
for
instance,
each
publisher
has
a
one-to-one
encryption
relationship
with
in
terms
of
content.
Encryption
with
the
subscriber
then
relays
have
no
point
right,
because
the
like,
because
there's
no
content
scaling
like
I,
mean
everything
every
like
individual
byte
stream
has
to
come
from
the
origin.
So
clear
is
not
what
we
mean.
So
how
does?
Q
How
does
this
work
do?
All
subscriptions
have
to
eventually
go
up?
If,
if
the
relays
can't
know
about
the
content
encryption,
then
to
what
extent
does
everything
need
to
go
back
to
the
origin
to
go
issue
keys
and
all
that
stuff
and
I
I
don't
know
it's,
maybe
not
a
question
for
you
Spencer,
but
for
the
group,
is
this
in
scope
or
does
or
do?
Does
everyone
know
the
answer
to
this
except
me
already.
I
I
I
just
wanted
to
answer
Martin's
question
and
he
makes
a
good
point.
If
it's
a
one-to-one
encryption
right,
then
actually
every
the
publisher
must
talk
directly
to
the
subscriber.
Why
do
you
need
relays
in
the
way?
So
you,
the
case
where
you
might
want
relays
is
if
your
publisher
is
very
far
from
your
subscriber
say
you
have
a
publisher
in
Miami
on
a
bad
internet
connection
and
the
the
subscribers
in
Seattle.
I
You
can
wrap
that
traffic
up
I,
think
op
and
over
10
different
asses,
which
will
happen
if
you
connect
directly
or
the
Miami
subscriber,
would
connect
to
a
local
relay,
which
is
then
connected
over
dedicated
fiber
to
another
relay,
because
it's
a
CDN,
so
part
of
the
purpose
of
the
CDN
is
to
offer
Midwest
traffic
that's
higher
quality
than
than
the
general
routing.
So
that
would
be
a
use
case
of
putting
relays
in
between.
Even
if
you've
got
a
one-to-one
encryption.
B
H
I
I
want
to
also
have
a
quick
stab
at
answering
Martin's
question,
but
covering
a
sort
of
expanding
it.
A
bit
further
you're
right
that
will
will
was
right
about
the.
Why
would
you?
Why
would
you
do
it
when
there's
only
a
if
there's
a
one-to-one
that
you
can
then
build
networks
that
are
shorter
paths
and
all
the
rest
of
it?
H
You
can
also
do
it
for
privacy
measures
such
as
a
few
skating,
the
the
sender
or
the
publisher,
IP
addresses
from
one
another
in
the
case
of
online
telephony
or
or
whatever,
but
there's
I
think
the
vast
majority
of
use
cases
where
we
will
need
to
encrypt
the
media
one
to
many
or
many
to
many
use
cases,
in
which
case
the
this.
This
gets
a
lot
more
more
complicated
and
actually
it
gets
a
bit
more
beneficial
and
I.
H
Think
that
there's
two
things
we
need
to
to
work
out
here
as
a
whole
and
we're
talking
about
this
sort
of
stuff
is
firstly
that
all
the
key
exchanges
and
all
the
rest
of
that
really
needs
to
be
kept
outside
of
the
protocol,
and
we
just
need
to
provide
enough
information.
So
that
the
eventual
media
sync
I
think
is
a
language
that
the
design
team
is
using
knows
how
to
do
the
key
exchange.
H
D
B
N
I'm,
basically,
echoing
what
James
and
we'll
talk
about
with
another
example,
saying
that
in
a
conferencing
scenario
where
you
you
would
like
to
have
multiple
people
in
a
meeting
that
would
the
best
use
case.
But
there'll
be
a
series
where
for
one-on-one
calls
between
Alice
and
Bob,
you
will
still
prefer
going
through
relay
because
it
does
provide
benefits
of
not
having
to
do
with
peer-to-peer
topology
understanding
and
setting
up
the
eyes,
Nat
traversal
and
those
kind
of
things,
because
something
cloud
and
that's
kind
of
lets.
N
You
kind
of
go
from
a
meeting
that
can
be
scaled
from
one
one,
one
to
one
meeting
to
say
one
to
many
meetings,
and-
and
in
that
case,
in
both
the
cases
it
becomes
natural
to
use
one
protocol
to
kind
of
support
both
and
in
most
of
the
cases
that
we
are
thinking
about
the
mock
as
games
thought
about
it's
like
for
the
media.
It
would
be
a
symmetric
encryption
and
that
would
require
either
a
DRM
based
something
a
key.
N
That's
been
set
and
sent
to
everyone,
or
it
would
be
something
more
on
the
lines
of
an
MLS
keying.
That
would
happen
outside
the
scope
of
the
mock
to
set
up
the
group
key
and,
and
that
gets
typically
used
for
for
the
endpoints
through
the
MLS
exchanges.
Nothing
to
do
with
Mock
and
keeping
those
things
separate
would
be
would
make
the
transport
more
or
specific
to
delivering
encrypted
media
thanks
cool.
D
C
They're
starting
to
talk
about
key,
exchanging
in
particular
whether
the
use
case
that
Will
was
outlining
was
geographical
in
nature
was
important
and
I
I
just
wanted
to
say
from
a
scope
perspective.
I,
don't
think
that
I
read
the
charter
as
limited
to
that
that
end
to
end
does
not
necessarily
mean
that
that
it
is
encrypted
from
a
single
publisher
to
a
single
subscriber,
using
a
single
key
and
I
think
that
the
DRM
cases
and
other
cases
people
have
raised
are
am
important
to
that.
I.
C
Think
the
key
point
to
this
for
give
the
overloaded
thing
is
that
my
reading
of
our
scope
is
that
we're
not
trying
to
presume
that
the
relays,
especially
the
fan
out
style
relays,
as
opposed
to
the
back-to-back
user
agents,
have
any
access
to
the
immediate
and
that's
important
both
from
a
privacy
perspective,
but
also
from
a
design
perspective,
because
that
means
that
anything
they
have
to
know
about
the
media
in
order
to
do
their
jobs
has
to
be
in
the
transport
metadata
in
some
way
and
I.
Think
from
my
perspective,
the
the
whole.
C
It's
very
hairy
and
we've
already
got
enough
very
hairy
things
to
deal
with,
but
the
biggest
thing
that
we
have
to
do
is
assume
that
any
one
of
these
devices-
that's
not
acting
as
a
client,
has
no
access
to
the
media
for
the
purposes
of
determining
what
we,
as
the
protocol
designers,
need
to
put
into
the
rest
of
the
system
and-
and
that
to
me
is
a
main
point
here-
that
scoping
in
the
charter
and
and
that's
just
what
I
wanted
to
say.
Thanks
right.
B
B
Basically
the
media
level
stuff
that
we've
talked
about,
putting
anything
that
the
yeah
relays
use
that
word
that
the
relays
need
to
in
order
to
do
their
job
as
relays
putting
you
know
just
copying
that
into
a
mock
header
that
they
would
that
they
would
have
understand
access
to
and
be
able
to
understand.
So
it's
not
that
they
can
read
it's
not
that
they
can
read
the
media
metadata.
J
B
H
J
B
Christian
I
I
almost
interrupted
you
in
the
middle
of
what
you
were
saying
to
say
that
you
were.
You
were
making
a
very
profound
comment
that
I'm
making
sure
is
in
the
minutes.
I
I,
I
I
agree
with
that.
You
know
the
basically
that
I've
I
hope
we
don't
end
up
with
like
30
different
special
case
relays,
but
that's
a
distinction
that
I
I
definitely
think
is
worth
is
work,
but
it's
worth
capturing.
So
thank
you.
Thank
you
for
that.
B
P
P
It's
been
very
challenging
to
get
media
to
go
through
firewalls
through
the
through
the
customer
infrastructure
and
having
consistent
access
to
in-region.
Resources
has
been
a
very
big
ask
by
many
people,
including
like
most
of
the
European
countries,
want
to
talk
to
only
European
U.S
folks
want
to
talk
to
us
only.
B
C
So
I
think
the
next
steps
are.
We
need
to
take
them
the
minute
so
that
of
the
meeting
and
review
them
and
make
sure
that
we
have
the
points
that
were
captured,
reflected
in
the
documents
and
that's
the
the
Baseline
here
I
think
we're
once
again,
I
think
we've
made
a
good
bit
of
progress
in
shared
understanding,
but
I
think
we
have
to
have
it'll
written
into
the
documents
before
we
can
kind
of
colic
success,
as,
as
you
see
at
the
moment,
we're
we're
at
26.
People
in
the
room.
C
K
B
D
B
Excellent,
so
just
for
me,
please
don't
feel
like
you
need
to
answer
this
question
on
the
on
the
on
the
call,
but
when
you
say
making
sure
things
are
getting
in
the
documents,
it
seems
like
a
lot
of
what
I'm
talking
about
here
is
relying
on
the
terminology.
You
know
relying
on
terminology
that
the
intermediaries
group
has
kind
of
been
making
up
if
they
go
along
and
that
it
we're
talking
about
ideas
that
might
reasonably
go
in
an
architecture
draft
James.
B
C
So
I
think
that
we
can,
let
me
check
with
Alan
about
that
and
we'll
try
and
figure
out
what
home
this
needs
and
I
think
there
are
two
pieces
to
it.
One
is
speak
right,
I
mean
no.
Our
requirement,
strapped
is
definitely
further,
along
than
an
architecture
draft
that
we
just
started
would
be
and
having
this
available
now
might
be
valuable,
even
if
it
later
moved
into
a
different
document.
So
the
good
thing
is,
we
have
the
slides
and
we'll
have
the
minutes
and
we
can
go
from
there.
M
B
D
B
D
A
Our
agenda
was
going
through
some
issues:
I
didn't
see
anybody
flag,
any
particular
issues
on
the
list
or
via
tags,
so
Emir
we
have
about
15
minutes
where
we
could
talk
about
them.
So
I
I'm
gonna
go
ahead
and
share
the
current
issue
list,
but
I
guess
I
would
solicit
from
the
draft
authors
and
we'll
look
at
the
work
draft.
First.
A
A
I
I
There
has
been
some
eye
ideas.
There's
there's
two
basic
I
think
fundamental
things
that
that
were
quite
interesting
came
out.
The
first
is
that
we
can
consider
the
catalog
as
another
track,
and
this
is
interesting
right,
a
catalog
before
it
was
a
special
entity
or
a
document,
and
it
it
then
described
tracks
which
themselves
were
different,
but
in
this
case
we
can
consider
the
the
catalogers
just
to
track
it
has.
I
It
has
a
join
point,
which
is
a
independent
catalog
and
then,
as
as
new
content
becomes
available
in
this
in
the
broadcast
or
the
package
of
content,
so
the
catalog
gets
updated
and
you
can
issue
updates
to
it
and
clients
joining
would
want
the
latest
version
of
the
catalog,
so
I
thought
that
was
a
an
interesting
outcome
from
the
discussion.
The
second
point
is,
and
you
see
it
there
and
Luke
filed
an
issue
on
it.
I
After
a
proposal
from
myself
that
we
can
actually
merge
a
a
URL,
the
web
transport
URL,
we
can
use
it
to
carry
information
about
the
content
that
the
client
wishes
to
consume,
in
other
words
the
catalog
definition,
and
we
can
either
Supply
this
as
two
pieces
of
data
or
we
can
merge
it
into
the
one
and
that
I
think
is
also
a
fundamental
point.
That
I
I
would
like
us
to
discuss
and
I
have
different
I
have
pictures
of
this
that
I
can
share.
If,
if
it's
easier
to
debate
that
versus
the
text.
A
N
I
I
I've
been
part
of
this
discussion
for
a
while,
so
I
agree
that
catalog,
as
reading
like
going
back
to
Christian's
point
about
treating
mortgage
delivering
tracks,
makes
sense
to
treat
catalog
as
another
kind
of
track
and
and
the
same
set
of
properties
with
groups.
The
that
also
falls
really
cleanly
for
catalog
as
well
and
I
would
on
the
having
the
your
the
web
transport
URL,
also
in
having
information
about
either
the
broadcast
or
the
or
your
url
or
the
track
URL.
N
K
E
K
K
A
A
That
seems
fine,
but
it
seems
like
if
we're
gonna
start
doing.
Interoperability
we'll
also
need
some
kind
of
another
document
which
defines
some
kind
of
catalog.
That
says
like
here
are
the
tracks
you
can
subscribe
to.
Otherwise
we're
we're
lacking
some
information
about
what
we're
going
to
need
to
do
so.
I
think
it's
totally
okay
to
have
a
base
protocol
where
it
says
it's
opaque,
but
I
think
that
we'll
also
need
to
have
some
kind
of
placeholder,
at
least
in
the
short
term,
and
that
would
handle
like
the
questions
that
Luke
destroys.
A
Is
it
Dependable
they're
Delta
encodings
like
what?
How
does
that
work
as
a
track?
So
that's
one
point.
The
other
point
I
wanted
to
talk
about
is
using
the
web
transport
URL
for
broadcast,
and
so
we
hadn't
conversation
earlier
in
this
meeting
about
emissions
groups
of
tracks
and
sort
of
mission
or
an
emission
is
a
broadcast.
So
it
just
means
that
sounds
like.
If
we
make
the
broadcast
part
of
the
web
transport
URL,
then
that
means
that
web
transport
can
only
convey
one
emission
and
I
guess
I.
A
I
Yeah
I
wanted
to
answer
first.
Firstly,
Luke's
comment
about
how
do
we?
How
do
we
do
Delta
updates
on
catalogs
I?
Think
if
we
follow
the
group
construct
that
we
followed
earlier,
then
it
fits
quite
naturally.
In
other
words,
you
would
issue
you
would
issue
independent
catalogs,
in
other
words
the
full
catalog
as
your
group,
and
then
you
would
do
Delta
updates
on
it
as
your
subgroup
objects
and
a
new
client
joining
the
relay
would
know.
I
I
have
to
go
back,
find
the
last
full
group
and
then
give
it
give
that
plus
all
the
Delta
updates
from
that
to
the
client
when
they
join,
and
then
it
could
build
up
it's
good.
It's
fresh
object
model
of
the
catalog
and
in
terms
of
best
practice
about
how
to
update
it.
I
think
that's
a
function
of
how
frequently
it's
changing.
I
A
K
Sure
I
think
the
only
other
thing
worth
considering
with
the
the
track
zero
and
somebody
will
run
into
this
when
they
write
it
down.
But
how
do
you
negotiate
track
formats
or
catalog
formats,
as
in
I?
Don't
know
that
needs
that
negotiation
like
do
I
use?
What
format
do
I
use
for
the
catalogings
to
be
somewhere,
and
that
was
part
of
the
purpose
of
the
catalog
message?
Is
you
could
specify
what
format
the
catalog
was
in.
I
I
forgot
to
answer
that,
Luke
that
we
have
in
the
proposal.
It's
like
three
different
ways
to
specify
the
catalog
type
and
I
was
also
talking
with
suhas
about
if
we
have
a
catalog
right
and
there
could
be
many
different
types
of
catalogs,
so
we
need
some
way
to
convey
it.
This
it's
catalog
number
six
and
a
registry
of
catalogs,
and
then
we
need
a
separate
spec
So
speaking
with
suhas
about.
We
need
to
be
writing
a
base.
Spec.
I
K
N
A
I
K
I
I
was
just
gonna
say
that
everything
scoped
to
an
emission
like
the
catalog
is
for
a
single
emission.
The
web
transport
session
is
for
a
single
emission.
If
you
want
to
receive,
like
you
know,
compositions,
which
is
different
emissions
from
different
sources
over
different
possible
links
and
different
cdns,
even
I
I,
just
think
that's
out
of
the
scope
of
of
the
transport
protocol.
A
It's
like
these
are
the
tracks
that
make
up
this
emission
if
we
want
to
also
have
something
that
says
here
is
a
description
of
what
I
want
to
show
on
my
screen,
which
is
actually
emissions
from
a
lot
of
different
sources
that
which
can
be
coming
from
different
cdns
different
links.
That's
fine!
But
it's
that
wouldn't
necessarily
be
scoped
to
a
web
transport
session
or
a
quick
connection,
so
I
I
think
I'm.
A
Just
trying
to
I,
don't
think
I'm
being
very
clear
about
it,
but
I'm
trying
to
agree
with
what
Luke
just
said
that
one
web
transport
session
for
one
admission
and
there's
one
catalog,
which
is
also
scoped
on
admission,
I,
think
that's!
Those
are
useful
and
and
I
noticed
that
Ted
has
locked
the
queue
and
we're
down
about
a
little
bit
less
than
15
minutes.
So
we'll
try
to
drain
the
queue
here
and
then
move
on
to
just
planning
for
our
next
meeting
go
ahead.
Christian.
J
When
I
hear
that,
basically,
we
have
a
group
emitters
Etc.
What
is
concrete?
There
is
the
authorization
issue
we
could
have
a
model
in
which
the
authorization
is
done
pair
web
transport
I
mean
I.
Do
a
web
transport
for
the
purpose
of
getting
this
kind
of
I
mean
this
particular
URL
emitter
domain
whatever,
and
and
then
we
have
all
the
authorization
done
at
that
level.
I
C
D
B
Yeah
so
I
had
just
sent
a
email
to
the
working
to
the
chairs
copy,
the
working
group
about
the
requirements
draft
and
just
suggesting
that
James
and
I
do
submit
a
dash
04
before
the
cut
off
on
Monday,
and
let
you
all
do
a
start,
Polly
working
group
for
adoption
on
that.
So
we
don't.
We
didn't
need
to
talk
about
anything
today,
except
for
me
to
say
that
out
loud,
but
putting
something
in
you
know
putting
yourself
again
in
Yokohama
about
provide.
B
C
Okay,
so
yes-
and
thank
you
for
the
reminder
to
everybody
about
when
the
draft
deadline
is
because
that
that
will
Drive
some
of
this.
So
if
you
are
one
of
the
folks
who
was
presenting
today
and
got
feedback
that
should
be
incorporated
into
the
the
documents
you're
working
on,
if
you
could
do
that
before
the
draft
cutoff,
then
those
will
go
into
the
hopper
for
air
time
in
Yokohama,
suhas.
N
F
A
No
I
guess
if,
if
you
know
we're
we're,
obviously
not
that
far
away,
so
if
you,
if
folks,
have
other
things
they
want
to
talk
about,
please
we'll
send
out
a
call
for
agenda
items
on
the
list.
Soon,
as
we
try
to
build
the
agenda,
we
do
have
two
meetings
scheduled
they're
late
in
the
week.
They
are
there's
not
that
much
time
between
them.
So
there's
that's
some
Advantage
for
starting
late
means.
A
C
Okay,
then,
just
a
reminder
to
everybody
that
we
are
actually
quite
late
in
the
week,
so
we
have
a
final
agenda
now
and
we
have
the
last
slot
on
Friday.
So
after
our
discussions,
you
will
definitely
be
able
to
go
out
for
a
beverage
or
some
other
refreshment
in
the
Yokohama
Hinterlands,
if
you're
not
getting
into
cab
to
get
to
one
of
the
airports.