►
From YouTube: IETF113-MLS-20220323-1200
Description
MLS meeting session at IETF113
2022/03/23 1200
https://datatracker.ietf.org/meeting/113/proceedings/
B
E
F
B
All
right,
I
think
it's
probably
time
to
get
going
here-
hey
everyone!
This
is
the
mls
meeting
at
itaf
1.3.
Here's
some
particulars
about
the
meeting
as
much
as
kind
of
a
resting
slide
for
us.
B
B
You've-
probably
hopefully
seen
this
by
now,
since
it's
wednesday,
this
is
about
the
policies
and
procedures
that
you
need
to
follow
are
that
you've
agreed
to
follow
as
part
of
participating
in
the
ihf
meeting.
A
lot
of
us
do
with
ipr
patent
policy
kind
of
stuff.
B
If
you
know
something
say
something,
you
know
working
group
process,
a
bunch
of
other
things
there
anti-harassment
procedures,
code
of
contact,
et
cetera.
B
This
working
group
has
been
well
is,
in
my
mind,
is
doing
very
well,
but
I
just
want
to
remind
everyone
of
the
itif
code
of
conduct
guidelines
here
that
are
documented
in
rfc.
7154,
basically
treat
everyone
with
respects,
try
to
speak
slowly
and
limit
the
use
of
slang.
I
feel
like
that
was
probably
written
for
me.
Dispute
ideas
by
reason
to
argument
use
your
best
engineering
judgment
find
the
best
solution
for
the
whole
the
internet
and
contribute
to
the
ongoing
work
of
this
group
and
the
rest
of
the
itf.
B
Again,
please
keep
in
mind
that
both
the
mic
on
the
jabber
and
the
meat
echo
are
on
the
thing.
I
guess
is
to
please
state
your
name
when
you
get
to
the
microphone.
B
It
makes
it
easier
for
the
note
takers
to
to
figure
out
who
said
what
here's
our
agenda,
which
is
our
typical
kind
of
light
agenda.
We
got
some
of
the
ministrivia
we're
gonna
go
through
some
things:
virtual
meeting
tips,
the
virtual
blue
sheets.
That's
right!
I
forgot
to
say
this:
if
you're
in
the
room,
please
go
ahead
and
zap
the
qr
code,
because
that's
that
that
takes
that
takes
the
place
of
signing
up
on
the
blue
sheet,
so
you
don't
have
to
touch
the
aki
aki
pen
sheet
of
paper.
B
So
I
appreciate
that.
Thank
you
very
much.
If
you
are
going
to
join
the
queue
and
when
you're
in
the
room,
please
the
the
q
tool-
and
we
can-
I
can
manage
it
because
I
can
see
the
key
just
fine
and
basically
we're
gonna
go
through
the
protocol
architecture
and
federation
drafts.
The
quick
synopsis
is
we're
getting
pretty
close
on
the
first
two
and
the
third
one.
We're
gonna
try
to
revive
all
right,
so
the
next,
the
next
one,
the
status.
You
know.
B
Basically,
it's
time
to
review
these
are
all
it's
time
to
it's
time
for
review,
for
the
architecture
draft
the
mls
protocol
documents
pretty
close
to
being
done,
and
the
mls
federation
draft,
like
I
said
we're
gonna
revive
this-
should
look
pretty
familiar.
This
is
the
timeline
we've
had
for
a
slide
for
a
couple
of
meetings.
Now,
basically,
we
did
a
working
group
last
call.
B
We
did
a
feature
freeze
and
we've
done
a
bunch
of
versions
of
the
draft
to
try
to
get
through
the
github
issues
and
pull
requests,
and
we've
done
that
now
we're
on
draft
13.
We
may
need
a
draft
14.
Then
we'll
do
a
working
group
last
call
and
then
we
kind
of
you
know,
go
back
out
and
see
what
happened
and
so
we're
getting
there
slowly.
B
But
surely
the
other
thing
to
note
is
that
the
way
we've
structured
these
documents
is
that
there's
no
way
that
the
protocol
document
can
really
get
to
the
isg
before
the
architecture
document.
Because
of
the
way
we
split
things
out
that
they
basically
have
to
progress
together.
B
So
when
we're
doing
the
kind
of
progressing
the
documents
to
the
area
director
that
the
architecture
document
is
going
to
have
to
go
with
the
protocol
document,
because
otherwise
it
just
won't
make
a
lot
of
sense
all
right,
so
that's
pretty
much
the
end
of
that
stuff.
Now
we're
going
to
jump
into
richard
slides
and
hopefully
he
has
arrived
there.
He
is
great.
I
will
stop
talking
richard.
Do
you
want
to?
Maybe
I
stopped
showing
this
and
you
grabbed
the
ball.
B
B
G
All
right,
so
is
that
showing
up
for
folks
yeah,
it
looks
good,
looks
good
cool,
so
we
were
at
draft
12
at
the
last
ietf
meeting.
As
I
recall,
we
have
since
issued
draft
13,
and
I
think
we're
going
to
do.
G
This
was
a
really
active
version,
thanks
to
all
the
folks
that
did
really
good
analysis
on
here,
and
I
think
a
lot
of
this
was
due
to
implementation
works,
which
is
exciting.
So
I'm
glad.
H
G
More
implementation
effort
here,
I'm
not
going
to
go
through
all
these,
but
I'll
go
through
a
couple
highlights.
One
thing
we
did
was:
we
did
a
stoppage,
a
temporary
stoppage
on
all
the
technical
work
to
just
put
the
document
in
a
more
sensible
order.
G
So,
as
you
can
see
with
the
arrows
here,
we
kind
of
move
things
around.
So
they
read
a
lot
better
note
like
I
said,
no
technical
changes
to
that,
but
I
think
that
the
document
flows
overall
a
lot
better,
so
it
should
be
more
comprehensible
when
we
send
it
out
to
last
call-
and
you
know
when
people
pick
it
up
later
on
another.
You
know,
building
up
more
technical
from
here.
One
of
the
changes
we
made,
that
is,
is
a
little
different.
G
If
you're
coming
from
a
tls
background,
is
we
streamline
the
the
vector
syntax
down
a
little
bit
in
tls?
You
say
you
know
how
many
bytes
of
length
you
want
to
put
at
the
front
of
a
vector
which
constrains
how
long
the
vector
can
be
in
bytes,
which
means
that
if
you
have
two
implementations
on
an
interrupt,
they
have
to
agree
on
how
many
bytes
that
they're
going
to
put
there.
So
we
found
when
we
did
some
interrupt
testing
on
earlier
address.
G
This
led
to
a
bunch
of
stupid,
interrupt
bugs,
and
you
know,
there's
obviously
more
code
to
kind
of
negotiate
which
which
sizes
you
use
so
the
pr
we
did.
We
just
made
the
the
length
field
of
the
vector
encoding
a
variable
length
integer,
so
that
you
just
put
as
many
bytes
of
length
as
you
need
and
there's
some
signaling
to
say
how
many
bytes
there
are
stealing
a
scheme
here
from
quick,
which
you
know
I
think
eckerd
proposed
putting
into
ctls
is
a
compact
way
of
doing
vectors
there.
G
Let's
see
what
else
another
nice
kind
of
conceptual
cleanup
we
did
was
to
split
leaf
nodes
and
key
packages,
so
key
package,
as
you
recall
in
prior
address,
were
used
both
for
initializing
pre-publishing,
my
capability,
so
I
can
be
initialized
into
a
group
and
for
representing
my
appearance
in
the
group
in
the
tree
after
I
joined.
G
We
split
the
those
kind
of
two
roles
so
the
leaf.
We
now
have
a
leaf
node
struct,
which
is
what
represents
a
member
in
the
group
in
the
tree
and
then
that
leaf
node
gets
wrapped
up
in
a
key
package,
and
the
key
package
is
used
only
for
pre-publishing
information
about
a
client,
so
they
can
be
initially
initiated
into
a
group.
G
G
G
We
now
have
two
hpke
public
keys,
so
the
tree,
the
key
that
goes
into
the
tree
and
is
used
for
treechem,
is
different
from
the
key
that
is
used
to
encrypt
the
welcome
message
when
you
join,
so
you
have
kind
of
that
nice
crypto
separation
between
the
one-time
initialization
operation
and
the
ongoing
tree
cam
membership
in
the
group.
G
Finally,
the
last
thing
this
let
us
do
is-
I
had
really
illustrated
the
slide
here-
is
that
when
you
have
leaf
node,
that's
added
by
an
update
or
commit
that
leaf,
node
gets
re-signed
and
that
signature
covers
the
group
id.
So
your
leaf
nodes
are
now
bound
to
the
group
they're
participating
in
and
by
the
way
people
should
feel
to
step
in.
G
If
there's
comments
or
questions
here,
I'm
just
kind
of
rolling
through
the
high
points
of
graph
13.,
a
nice
suggestion
from
martin
mullarczek,
which
gives
us
a
little
bit
more
efficiency
here-
is
that
we've
updated
the
algorithms
for
how
we
update
the
tree
so
that
we
no
longer
generate
what
we
call
redundant
nodes
where
we're
done
by
redundant.
We
mean
a
node
that
only
has
one
child,
that's
populated,
so
here
I've
put
keys
nodes
that
have
key
pairs
attached
to
them
in
black
nodes
that
are
blank
and
in
white.
G
We
no
longer
need
any
of
those
intermediate
nodes,
and
so
we
save
on
key
generations
on
this
streamlines
tree
truncation
later
on
generally
makes
things
a
little
bit
cleaner.
So
it's
a
nice
simplification.
G
One
thing
that
took
us
a
few
iterations
to
figure
out
is
this
tree
hash
based
parentheses,
another
thing
from
from
tafil
and
then
the
inria
folks,
right
now,
with
some
parent
house
you'll
recall,
is
how
we
enable
someone
who's
joining
the
group
to
verify
that
the
keys
in
this
you
know
who
who
has
access
to
the
keys
in
the
tree,
that
the
trees
are
actually
following,
the
what
we
call
a
tree
invariant
that
the
key
is
only
accessible
to
the
the
nodes
below
it
in
that
parent
hash.
G
The
parent
hash
here
at
v
would
cover
its
parent
x
and
a
representation
of
its
sibling,
zed
and
so
right
now
in
draft
12.
We
use
the
resolution
of
that
sibling
because
z
is
populated
here
with
the
resolution
is
just
the
node
zed,
and
so
the
change
we
made
was
to
use
the
tree
hash
of
the
sibling
which
binds
in
all
of
the
the
entire
sub
tree
under
the
sibling
node,
which
obviously
gets
you
a
tighter
binding
to
the
structure
of
the
tree.
G
So
you
type
in
the
whole
structure
of
subtree
tie
in
the
things
that
are
in
the
leaves
like
the
credentials.
So
you
get
a
lot
more
more
information
tied
into
that
parent,
hash
and
so
more
rigidity.
In
the
tree
fewer
ways
an
attacker
can
lie.
G
The
challenge
you
get
with.
That
is
that
when
you
do
this
at
the
right
edge
of
the
tree,
that
you're
binding
the
tree
structure,
but
the
tree
structure
at
the
right
edge
of
the
tree
can
change.
When
you
add
someone,
so
in
this
example,
you
know
someone
has
added
this
node
h
as
new
member
h
without
sending
an
update
path,
which
is
legal,
so
everyone
just
ratcheted
you
know
symmetric
ratcheted
forward
and
as
a
result,
h
and
the
blank
parent
of
h
got
added
to
the
tree.
G
So
it's
going
to
need
to
you
know
in
addition
to
computing
the
treehouse,
the
hashes
of
the
trees
that
exist
today.
It
needs
to
compute
some
historical,
hashes
and
teo
field,
provided
some
nice
analysis
on
which
we
validated
an
implementation.
It
shows,
if
you
do
a
super
naive
algorithm
here.
You
end
up
with
doing
n
log
n
hashes,
I'm
having
because
you're
having
to
recompute
some
things.
If
you
do
a
smarter
algorithm
that
has
minimization,
you
can
get
down
to
n
log
log
n,
and
so
there
is
some
cost
to
this.
G
It's
it's
worse
than
o
n,
but
not
worse
by
much
of
a
factor.
It
doesn't
get
to
do
much
and
so
just
to
validate
that
that
cost
wasn't
too
much.
I
prototyped
this
out
in
in
mlsp
the
c
plus
base
stack
that
we're
using
in
webex
and
looked
at
a
few
cases.
G
So
the
the
the
thing
that
really
makes
this
algorithm
challenging
is
unmerged
leaves
because,
as
you
can
see,
the
the
way
that
tree
structure
change
happens
is
when
you
have
unmerged
leaves
so
simulated
a
few
cases
here,
you
know
looking
at
a
full
tree
with
no
unmerged
leaves
and
then
synthetically
made
some
trees
that
were
either
like
half
on
merged
or
three
quarters
of
merge
to
really
try
and
drive
out
the
painful
cases
for
this
new
algorithm
and
then
finally,
it's
tested.
G
You
know
a
case
where
we
have
one
very
sparse
tree
with
one
path
populated
as
if
you
had
you
know
someone
adding
a
bunch
of
folks
to
the
tree
and
looking
what
they
had
to
do
to
join.
Basically,
this
path
case
is
the
best
case.
In
fact,
in
that
case,
you're
actually
doing
your
performance
looks
better
than
the
previous
algorithm,
even
in
the
worst
case,
you're
you're
at
about
a
factor
of
two
worst
case
performance
and
quantitative.
G
In
absolute
terms,
you
know
the
you
can
see
the
the
top
right
graph
there,
you're
still
taking
on
the
order
of
30
milliseconds
to
verify
the
tree
when
you
join,
which,
when
you
consider
these
trees
at
you
know,
200
plus
members
or
in
the
order
of
megabytes,
it's
going
to
take
you
much
longer
than
that
to
download
the
tree
at
all.
So
it's
not
really
a
salient
performance
hit
to
do
this
parent
hash
and
get
the
increased
binding.
G
So
I
think
that's
everything
that
went
into
draft
13,
so
I
think
you
know
the
upshot
of
all
this
discussion,
especially
after
we
close
out
our
last
few
issues.
Here
is,
I
think,
we're
we're
pretty
much
ready
for
working
group
last
call.
G
So
with
that
I
think
it's
time
to
ponder
draft
14,
which
is
you
know,
going
to
incorporate.
I
think
just
the
the
prs
we
have
outstanding.
So
sean
did
you
want
to
drive.
You
want
to
share
github
and
and
walk
us
through
that.
B
I
can,
I
think
that
you
need
to
relinquish
it
or
I
take
it
from
you
hold
on.
Yes,
so
I
have
relinquished
you
relinquished
it
now.
Let
me
see
if
I
can
screen
share,
do
you
really
want
to
stream
scare?
Yes,
I
do,
let
me
tell
you
which
thing
I
want
to
screen
share,
how
about.
B
G
G
G
Content
here
it's
just
saying
that
you
know
this:
this
one's
tls,
this
one
is
ascier
this
one's
pseudocode.
This
allows,
if
you
pause
it,
one
of
the
aasvg
ones
they're
shown.
Actually
this
is
you
know
the
tls
bits.
I
came
across
this
because
actually
I
was
trying
to
extract
the
tls
syntax
to
help
with
implementation.
The
other
cute
trick.
You
can
do
here's
this
aasvg
tool
that
martin
thompson
wrote
we'll
actually
convert
this
ladder
diagram
to
an
svg
file,
so
it
looks
a
little
prettier
in
the
html
rendered
version.
G
So
I
think
we
can
probably
just
merge
this
because
I
think
it's
just
editorial,
but
I
thought
I'd.
Let
people
know
in
case
there
are
this.
G
If
you
want
to
go
to
the
changes,
it's
a
small
change,
but
it's
again
trying
to
go
for
more
key
separation.
So
right,
I
already
said
we
one
of
the
things
I
mentioned
in
the
key
leaf,
node
key
package
separation
that
was
nice
is
we
have
these
two
hpke
keys
now
one
for
initialization
and
one
that
is
my
long
term
key
in
the
tree.
G
There's
no
requirement
right
now
that
there's
actually
be
different
keys,
and
so
this
pr
is
just
adding
that
requirement
in
there
so
require
that
they'd
be
different.
Main
draw
vector.
Is
it's
the
other
key,
so
you
need
more
entropy
to
generate
it,
but
I
suppose
you
could
comply
with
the
protocol
by
deriving
them
from
some
common
secret
as
well.
So
I
don't
think
that
the
entropy
requirement
is
too
terrible.
G
617,
I
think
we've
got
pretty
good
agreement
on
this
as
well
on
the
mailing
list.
617
we
had
some
discussion
about.
I
guess
the
discussion
started
here
about
deniability,
where
folks
were
there's
some
ambiguity
or
some
disagreement
in
how
people
read
the
spec
when
it
came
to
what
keys
were
used
for
signatures
and
as
part
of
that
discussion,
it
came
out
that
there
was
ambiguity
around
these
pre-configured
centers
as
well.
G
There
wasn't
it
wasn't
kind
of
defined
interoperab
interoperably
how
you
would
make
sure
everyone
agrees
on
who's
pre-configured,
so
this
pr
cleans
that
up.
Basically,
it
ensures
that
every
everyone
in
the
group
agrees
on
who
the
external
senders
are
so
they'll.
Everyone
make
sure
that
everyone
will
agree
on
who
the
valid
signers
of
a
message
are.
G
So
I
think
we
discussed
this
pretty
thrilling
list.
I
think
it's
got
a
couple
of
approvals
in
github,
but
I
thought
we'd
bring
it
up
here.
Just
in
case
there
are
any
further
comments.
G
Okay,
so
now
that
these
last
two
are
maybe
a
bit
more
controversial,
so
rowan
proposed
this
one
to
indicate
the
mime
type
of
the
application
data.
That's
carried
in
an
application
message.
G
My
comment
here
in
the
pr,
so
my
inclination
to
just
a
bottom
line
up
front
is
to
to
close
this
one
with
no
action.
I
think
this
is
probably
kind
of
getting
a
bit
premature
in
terms
of
signaling
inner
content
types.
G
I
think
we've
got
the
tools
to
add
this
later
on,
but
rowan
did
you
want
to
tee
this
up.
D
Yes,
hi
good
morning,
everybody,
so
I
think
mls
is
a
little
bit
unique
among
itf
protocols
and
not
either
having
a
place
where
you
can
describe
what
the
next
layer
is
or
defining
explicitly
what
the
next
year
will
be,
and
so
this
was
my
attempt
to
to
fix
this.
So
I
don't
think
it's
premature
at
all.
I
think
this
is
this:
is
basic
hygiene
protocol
hygiene
and
pretty
essential
if
you're
in
a
group,
an
mls
group
that
doesn't
require
you
know
that
that
is
completely
heterogeneous.
D
Where
you
say:
okay,
I'm
the
thing
that
I
am
sending
is
a
this,
and
if
you
need
something
more
fancy
than
than
a
specific
mime
type
with
parameters,
then
you
can
send
a
mime
type
that
has
further
descriptions
and
it
you
know
just
because
it's
just
because
it's
a
mime
type
doesn't
mean
that
that
thing
needs
to
be
text,
you
could
send
applications
or
you
know,
application
slash,
vnd
dot.
D
You
know,
example
vendor
this
crazy,
special
message
format.
So
those
things
are
all
possible.
G
Yeah
and
just
to
kind
of
make
an
analogy
for
people.
I
think
if
folks
are
coming
from
a
tls
context.
I
think
the
right
analogy
here
is
something
like
alpn,
which
was
added
to
tls
as
an
extension.
But
you
know
you
could
ask
the
question
is:
if,
if
we
were
doing
tls
over
from
scratch,
would
we
develop
alpn
from
the
start
eric.
I
I
was
intending
to
speak,
but
you
know
then
didn't
I
mean
I
think
so.
The
airplane
is
an
interesting
analogy.
I
guess
you
know
I
I
tend
to
think
of
this.
As
you
know,
like
mls
is
designed
to
be
embedded,
you
know
in
other
protocols.
It
is
in
itself
like
a
complete
protocol,
and
so
I
would
think
that
the
largest
are
those
protocols
to
define
what
what
what
the
contents
of
those
messages
are
and
so
like
why
I'm
a
little
suspicious
of
the
lpn
analogy.
I
I
think
that's
what
I
mean.
I
might
think
of
this
more
like
aed,
in
fact
as
and
say
that,
there's
that
information,
obvious
it'll
be
elsewhere.
I
guess
I
don't
quite
understand
why,
like
you
know,
it
seems
to
me
that
that
you
know
one
might
wish
to
have.
You
know
that.
I
If
I
want
to
build
a
if
I
want
to
build,
you
know,
you
know
if
I
want
to
build
my
own
messaging
system
like
they
use
mls
like
I'm,
going
to
want
to
dictate
like
how
how
the
how
what
kind
of
message
is
going
on
and
how
that
how
those
message
types
are
conveyed,
and
it's
not
quite
any
an
mls
solves
that
problem.
D
So
in
regards
to
whether
you
want
to
convey
the
content
on
the
outside,
then
I
think
the
reason
is
obvious
that
that
you
are
leaking
information
which
would
which
could
otherwise
be
private
if
you're
putting
it
on
the
if
you're,
sending
it
possibly
unencrypted
or
sending
it.
I
That's
not
what
I'm
saying
well,
what
I'm
saying
is
like
that,
that
you
define
the
message
types
and
inside
the
message
inside
inside
the
message.
Bodies
can
convey
the
types
of
messages
any
further
that
have
information
right.
So
so,
like
you
can
say,
external,
like
I
say
like
if
I
want
to
do
my
message
system,
I
say
all
my
messages
are
mine
and
everything
inside
is
mine,
and
so
you
look
at
the
interest
inside
the
message
right
and
so
that's,
I
think,
that's
the
correct
the
correct
locus
for
defining
the
message.
D
I
think
I
I'm
not
really
understanding
where
what
you're
getting
at
here,
because
I'm
on
type
doesn't
need
to
be.
You
know
like
rfc,
28,
22
style,
mine
right,
I
could
send.
I
could
send
like
a
vendor
specific
mime
type.
I
could
spend
send
cbor.
I
could
send
protobuf,
I
could
send
json.
I
like,
I
just
need
a
way
to
say
the
thing
that
I'm
sending
inside
has
this,
because
this
framing
this
structure
whatever
and
I
can
further
define,
if
that's
not
explicit
enough,
then
that
can
further
describe
its
own
content.
I.
J
Can
I
try
restating
just
sure
so
so
I
think
what
what
eric
is
is
saying
is
that
to
deploy
mls,
you
need
a
number
of
specific
things
defined
like
the
specific
transport
that's
going
to
be
used,
who
the
authorities
are
that
it
depends
on
and
what
I
think.
J
Why
not
use
that?
Why
not
put
the?
How
how
to
deal
with
the
application
data
in
that
parameterization
right
and
a
common
pattern
may
well
be
that
the
beginning
of
the
application
data
is
a
mime
type,
but
there
may
be
other
situations
where
that's
not
necessary,
and
it's
not
clear
what
what
we
gain
from
sticking
this
in
here.
J
If
we
don't
actually
have
a,
you
know
a
meaningful
way
to
to
deal
with
that
right
like
what,
if
I
have
an
application,
where
I
expect
all
of
the
messages
to
be
image
png's
where
people
are
just
like,
I
don't
know,
texting
each
other
photos
or
something
yeah,
and
then
suddenly
you
get
something
that
doesn't
say
image
png
in
it.
What's
supposed
to
happen
to
your
protocol,
there.
D
Right
so
it
precisely
as
you
described,
this
is
a
this
helps
solve
that
problem.
It
is
just
a
tool
and
help
helping
to
solve
that
problem.
But
if
you,
if
you
define
your
group
so
that
your
group
only
ever
sends
pngs,
then
you
could
leave
this.
You
could
leave
this
blank
and
only
incur
an
extra
byte
of
overhead.
D
If
you
wanted
to
explicitly
signal
that
you
were
sending
one
of
several
types
of
supported
content,
then
you
could
put
in
this
in
this
field
before
the
application
data,
you
could
put
the
the
type
that
you
happen
to
be
sending
among
the
types
which
were
were
predefined
by
your
application,
that
they
are
acceptable
types
you
would
send
that
type
and
then
the
application
data
doesn't
have
to
have
any
mime
texts.
D
And
that's
the
the
value
there
is
that
you
have.
You
have
some
agility
in
that.
If
the
group
allows
it,
you
can
send
optional
types
which
could
be
ignored,
you
could
send
you
could.
If
you
have
multiple
choices
which
are
all
acceptable,
you
can
signal
which
one
you're
sending
it
provides
a
lot
of
flexibility,
and
so
it
provides
a
basic
way
of
signaling.
What
is
what
is
this
content
inside.
A
D
The
content
that
you
would
be
sending
as
your
application
content
if
you
wanted
to
send,
for
example,
a
multi-part
alternative,
then.
A
I'm
thinking
of
the
case
where
I
know
I'm
using
some
bad
api
and
I
can't
get
the
mime
type
in
my
upper
level
application.
So
I
just
put
it
also
in
the
application
data
just
so
that
it's
there
and
then
somebody
says:
here's
an
image,
png
and
then
at
the
upper
level
it
says
it's
actually
an
image
jpeg
and
suddenly
it's
all
broken
and
bad
things
are
happening.
For
no
apparent
I
mean
I
I
I
feel.
D
D
D
K
Colin
go
ahead,
I'm
just
playing!
Oh,
it
looks
like
I'm
on
okay,
so
I'm
not
arguing
for
against
this
one
way
or
another.
I'm
just
sort
of
saying
that,
like
this
is
a,
I
think
the
analogy
to
lpn
is
actually
really
quite
good.
K
I
think
that's
a
fairly
clean
analogy
to
what's
going
on
here,
like
whether
you
should
do
it
or
not.
Who
cares
I
mean
you
can
either
put
this
identifier
of
what
the
data
is.
You
can
either
put
as
the
first
bytes
of
what
you
find
in
the
message,
or
you
can
put
it
in
the
metadata
outside
of
the
message.
We
can
go
either
way,
but
I
think
this
is
a
I
I
think
saying
this
is
very
different
than
tls.
I
I
don't
I
I
don't
see
that
at
all.
I
Well,
I
mean
so,
I
think.
First
of
all,
I
think
the
tlc
analogy
is
a
little
odd
in
that
the
reason
the
airplanes
are
the
way
it
is
is
because
this
client
had
to
discover
what
the
server's
properties
were
and
it
had
to
be
done
in
the
first
round
trip.
So
that's
not.
The
situation
does
not
apply
here,
but
I
mean
we're
not
we're
not
actually
debate
what
we're
not
this.
I
I
think
we
generally
have
this
problem
in
systems
where,
when
you
have
like
an
opaque
transport-
and
you
want
to
demux,
you
give
us
the
types
of
things
under
it.
What
specific
specifies
like
you
know
how
that
debossing
happens,
and
what
you
propose
is
to
find
the
specific
define
the
in
this
in
this
specification
that
you
almost
must
have
the
unboxing
of
a
particular
type
and
the
other
option.
No,
it
is
you're
saying
you
always
have
to
have
this.
I
Okay,
but
like
that,
which
is
which-
and
this
is
the
case
we
always
come
into
when
we
have
these
things
and
and
what
I'm
saying
and
what
I'm
saying
is
that
the
description
of
what
to
form
demoxing,
including
the
zero
or
not,
should
be
on
another
layer,
and
you
could
have
precisely
the
same
wire
formats
by
the
way,
namely
that
what
I'm
saying
is
that
in
your
ml
specification,
mls
mls
concrete
deployment,
you
say
we
use
the
unboxing
specified
in
this
pr,
and
so
the
wirefront
will
be
precisely
identical.
I
D
I
Think
it's
just
no,
I'm
not
all
right,
because
I
see
as
many
like
precisely
as
many
layers
we're
talking
about
in
every
every
case.
You
have
mls
and
then
you
have
a
concrete
messaging
protocol
that
makes
use
of
it
and
and
in
and
as
I
said,
the
wiring
coding
was
precisely
identical
and
the
question
is
merely
who
specifies
which,
where
the
wire
encoding
is
specified-
and
so
we
and
what
you're
saying
is
every
use
of
mls
must
use
this
prefix
monitor
encoding.
I
G
Well,
actually,
a
concrete
suggestion
occurs
to
me
here
so
rowan.
You
presented
this
draft
on
mime
type
negotiation
in
dispatch,
which
I
think
is
a
fine
idea.
I
mean
like,
if
you're
doing
that
extension,
you
could
extend
the
in
the
semantic
of
that
extension
so
that
it
also
said
put
this
mime
type
in
front
of
the
application
data.
It
would
be
a
trivial
increment
on
that
extension.
D
G
G
L
Jump
in
here
and
try
and
d
do
something
so
like.
I
think
the
point
that
I've
heard
several
people
trying
to
make
is
that,
like
our
foundational
assumption,
is
that
we
are
not
specifying
a
complete
interoperable
protocol
here,
like
we're
building
a
framework,
and
we
expect
as
any
precondition
as
a
precondition
for
any
deployment
that
you're
going
to
have
some
sort
of
integration
glue
to
integrate
the
thing
we
produce
into
your
actual
complete
deployed
system-
and
you
know
it's
it's
a
very
good
question
to
say:
okay.
L
Well,
how
is
the
actual
structure
and
payload
interpretation
of
the
payload
to
be
conveyed
like
thank
you
for
raising
this
question?
It's
it's
good
to
consider
where
this
should
happen,
but
because
what
we're
building
is
sort
of
a
framework
rather
than
a
concrete
protocol.
It's
not
immediately
clear
where
the
right
place
is
to
include
this
information.
We
could
say
as
a
precondition
of
using
mls.
You
must
supply
your
own
form
of
this
content
negotiation.
L
We
could
also
say
we
will
provide
this
thing
that
you
can
use,
but
because,
like
we
don't
have
people
with
a
wide
community
of
deployed
implementations
using
our
stuff.
L
We
can't
really
say:
is
it
going
to
be
more
convenient
more
of
the
time
to
have
this
be
part
of
the
integration
blue,
or
is
it
going
to
be
more
convenient
more
of
the
time
to
have
it
as
part
of
core
mls,
and
so,
unless
somebody
can
propose
a
way
to
like
have
a
metric
to
decide
which
form
of
the
integration
is
going
to
be
more
useful?
Overall,
we
don't
really
have
a
way
to
answer
this
question
and
in
that
sort
of
scenario
we
might
consider
it
quite
flat.
D
So
I
will,
I
will,
I
think,
that's
a
nice
way
of
framing
it,
benjamin
but
or
sorry
a
nice
way
of
framing
it
that
I
think
the
an
analogy
for
me
would
be
if
somebody
had
imagine
if
somebody
had
defined
http
without
having
any
place
to
put
a
content
type,
and
it
said
we're
going
to
just
leave
this
up
to
the
to
the
application
and
the
first
application
that
anybody
ever
used
was
they
put
some.
D
D
So
you
know
you
have
you
have
this
extra?
You
know
like
html
and
then
some
you
know
some
extra
thingy
inside.
Maybe
it's
only
20
or
30
bytes,
but
it's
always
in
this
ancient
format
that
we
don't
care
about.
D
I
think
that
that's
that's
precisely
the
cop-out
that
we
are
making
right
now.
If
we
don't
do
something
like
this,
if
we
were
to
say
you
must
always
put
an
extra
tls
record
layer,
formatted
thing
at
the
beginning,
that
has
some
format.
D
L
So
I
guess
my
very
quick
reply
is
that,
yes,
this
is
an
easy
way
to
specify.
What's
inside
it's
possible,
somebody
could
come
up
with
a
different
easy
way
that
is
a
better
fit
for
their
application
in
the
future,
and
if
we
specify
this
way
now,
there's
a
decent
argument
that
we're
locking
somebody
else
out
from
doing
something
better
in
the
future.
D
So
if
you
say
that
you
would
be
locking
somebody
out
of
doing
it
in
the
future,
so
I'm
countering
that
you,
wouldn't
you
could
define
it
in
your
group.
D
L
Yeah
I
mean
my
my
sense
here
was
that
the
topic
that
I
think
jonathan
was
bringing
up
about
like
if
you
have
two
different
similar
values.
How
do
you
enforce
consistency
between
them
and
you
may
not
be
able
to
enforce
that?
You
always
have
access
to
it,
but
I
think
I'm
also
probably
running
over
time
here.
So
maybe
I
should
shut
up
yeah.
B
I
had
a
bit
of
a
death
there,
so
the
show
of
hands
tools,
we're
gonna.
Do
you
know
we
talked
about
us
a
lot,
so
this
is
gonna,
be
a
merger,
not
merge
kind
of
questions
so
whatever?
What's
the
number
of
this
pr
doesn't
matter,
doesn't
matter.
C
B
B
B
B
All
right:
well,
what
happens?
We
take
it
to
the
list
in
the
poll
we'll
take
it
to
the
list.
There's
one
other
pr
related
to
protocol
that
we're
also
going
to
take
to
the
list.
So
I
will
go
ahead
and
do
that
the
other
the
next
draft.
I
think
we're
going
to
switch
over
here
to
benjamin
to
give
us
a
kind
of
quick
walk
through
of
the
architecture
draft.
N
N
So
the
the
like,
I
think
if
the
protocol
document
is
done
richard
and
I
did
a
pass
on
the
architecture
document
over
the
last
week
and
and
typically
richard
made
sure
that
we
are
lined
between
the
the
architecture
document
and
the
protocol
document,
so
that
we
don't
have
any
any
differences
in
terms
of
the
the
way
we
name
the
group
id
things
like
this.
N
N
One
is
75,
which
is
tactics,
the
expected
type
of
deployments,
and
typically,
what
we
have
been
what's
been
asked
here
is
documenting
more
kind
of
deployments,
meaning
like
like
the
the
framework
on
which
we
built
mls
is
mostly
the
centralized
deployment,
but
we
made
sure
that
the
protocol
can
handle.
You
know,
like
animals
deployments
a
different
kind
of
delivery
system
for
messages,
and
you
know
some
people
typically
brandon
actually
asked
whether
we
should
document
more
use
cases
more
kind
of
architectures
in
this
document.
N
I
at
this
point
I
don't
think
we
should
do
that.
I
think
a
much
better
place
to
do
you
know
federated
deployments.
Decentralized
deployments
is
in
the
federation
document
because,
like
the
the
main
one,
the
centralized
deployment
is,
is
the
one
we
refer
to
for
the
for
the
for
the
deployment
of
the
protocol,
and
you
know
so
it's
it's
it's
an
id,
I
mean,
but
I'm
not
convinced
that
we
should
go
there,
so
we
propose
that,
basically,
we
don't
do
anything.
N
We
keep
the
centralized
deployment
as
the
main
use
case,
but
I
mean
to
you
know
to
make
a
point.
I
mean
the
document
is
written
to
make
explicit
that
this
is
not
the
only
deployment
right
like
we
can
deploy
in
many
ways,
and
we
have
like
only
in
the
architectural
document.
The
minimal
assumptions,
which
is,
we
need
some
kind
of
authentication
service
which
will
authenticate
these
or
provide
keys
for
for
signatures
later
on.
N
In
the
protocol
for
authentication-
but
we
don't
say
we
explicitly
say
oh
by
the
way
this
can
be,
you
know
a
consensus
mechanism.
This
can
be
a
central
server.
This
can
be
so
we
already
have
this
notion
that
the
centralized
deployment
is
not
the
main
domain,
the
only
framework
so
for
this
one
I
would.
N
So
are
there
any
questions
about
this?
Any
comments,
I
think
you
know
like
the
point
is
that
this
document
is
very
clear,
that
there
are
other
deployments
that
the
central
one
and
it
actually
already
provides
intuitions
or
explicit
recommendations
of
other
kind
of
deployments.
But
you
know,
I
think,
writing
down
a
full,
federated
or
decentralized
architecture
is
like
a
separate
thing
if
we
want
to
instantiate
this
like
this
is
really
focused
about
the
minimal
things
that
we
need
for
the
protocol
to
run
so
yeah,
I
would
say,
not
touch
not
touching.
B
That's
chair.
I
think
this
is
definitely
one
of
these.
Please
bring
pr
if
you
think
that
this
is
needed,
so.
B
If,
if
brandon
shows
up
with
you
know
50
pages,
like
hey
great,
we'll
review
it,
I
I
I
imagine
that
sometimes
which
he
might
it's
very
possible
right-
that
if
it's
not
forthcoming,
that
it's
okay,
that
we
put
it
in
the
federated
document
or.
H
G
Belongs
in
the
federation
document
because
I
think
that'll
be
a
little
bit
more
protocol
oriented
than
talking
about
these
deployment
considerations,
but
I
I
don't
think
it's
actually
all
that
useful
to
talk
about
these
kind
of
aggregate
deployment
scenarios
either,
because
the
individual
properties
that
are
talked
about
here
get
covered
in
the
architecture
document,
so
net
net.
I'm
I'm!
Okay!
Closing
this
with
new
action
as
well.
B
I
I
don't
know
if
brandon's
here
or
if
anybody
else
wants
to
get
speakers.
But
let's
go
ahead
and
proceed
with
that.
And
if
there's
a
rush
to
the
microphone.
M
M
N
Yes
and
that's
also
very,
very
straightforward-
I
think
chelsea
actually
wanted
to
make
sure
that
the
phrasing
in
the
architecture
document
is
is
good
enough,
so
that
people
just
assume
that,
because
there
is
an
key
package
or
an
init
key
that
is
used,
that
is
added
to
a
group,
means
that
the
the
the
participant
is
actively
contributing,
meaning
that
you
know
like
anyone
can
take.
I
can
take
the
init
key
for
jobin
or
whatever
and
like
do
an
x3dh
session
with
him.
N
It's
not
gonna
mean
that
he
wants
to
talk
to
me
right
or
that
we're
in
an
active
discussion,
and
we
have
a
very
slightly
similar
issue
in
in
mls
the
way
I
see
it.
So
I
want
I
like
things.
She
wanted
to
improve
the
phrasing
to
say
that
only
when
a
participant
actually
committed
to
that
group
in
response
for
this
ad,
we
should
consider
this
as
a
participation.
N
So
I
don't
even
want
to
go
that
way
and
say
he
is
like
this
person
is
participating,
but
I
want
to
make
sure
that
the
phrasing
doesn't
imply
that,
because
someone
is
added
to
a
group,
because
it's
other
two
group
that
person
accepted
to
be
part
of
that
group
until
there
is
no
until
there
is
an
actual
action
from
that
person,
you
know
you
can't
assume
anything
of
its
active
participation.
N
So
that's
the
I
think,
that's
like
very
straightforward.
I
am
waiting
for
chelsea
or
someone
else.
Maybe
you
know
that
wants
to
do
a
pr
for
that
one,
but
it's
like
really
a
simple
editorial
pr
to
ensure
that
there
is
no
confusion
right
and
at
this
point
I
think
the
only
thing
that
we
really
need
is
his
review
for
the
architecture.
Draft
like
last
review
is
from
richard
last
week.
I
think
he
made
a
nice
set
of
editorial
comments
to
that
document.
N
We
merged
them
because,
like
there
was
no
change
that
needed
to
be
discussed.
This
was
purely
editorial,
like
changing
names
for
the
for
the
types
that
were
used
in
the
protocol
documents,
and
things
like
this.
G
G
So
on
number
71
here
I
think
that
it,
there
is
probably
a
conceptual
distinction
to
make
between
membership
and
liveness,
because
when
when
someone
has
been
added
even
before
they
commit,
they
are
a
member
of
the
group
in
the
sense
that
they
can
access
the
group's
secrets,
decrypt
messages,
etc.
I
I
agree
that
they
may
not
have
you
know,
consented.
They
may
not
be
actively
involved
in
this
group.
It
may
be
a
stale
key
package
or
whatever,
but
you
know.
H
G
Regardless,
whoever
has
has
access,
the
private
key
is,
has
access
to
their
secrets,
and
it's
just
a
member
in
that
sense,
so
I
think
we
may,
if
we
really
want
to
clarify
this.
One
up
we
may
need
to
you,
know,
clarify
that
and
make
a
distinction
make
a
distinct
notion
of
kind
of
liveness
and
consent.
That's
a
separate
from
membership.
N
That
would
be
great
apart
from
that
I
mean
the
the
last
two
issues
are
really
like
making
sure
that
we
have
all
the
citations
for
the
paper
that
we
wanted
in
the
architectural
document
and
ensures
that
the
affiliations
and
the
contributors
are
correct.
The
rest
is
like
yeah.
If
anyone
has
like,
I
don't
know,
do
you
want
to
proceed
sean
with
the
timeline.
B
Come
on,
I
want
to
make
sure
that
robin
you're
in
the
queue.
O
Yeah
thanks
sean
is
the
audio
okay
yep,
yes,
good
yeah.
I
wanted
to
pick
up
on
the
point
that
richards
alluded
to
here,
because
the
alarm
bell
that
set
off
in
my
mind,
was:
are
we
opening
the
door
there
for
the
kind
of
proposal
that
was
put
forward
in
the
uk,
the
so-called
ghost
protocol
or
silent
listener?
O
What
I
don't
want
to
see,
I
think,
in
a
spec
like
this,
is
a
a
staged
view
of
someone
being
a
member
of
the
group
that
would
make
it
possible
for
someone
to
participate
in
the
key
exchange,
but
for
some
reason,
because
they're
not
at
that
point
considered
to
be
a
full
participant
of
the
group
for
other
people
in
the
group
not
to
be
notified
that
that
person
has
has
undertaken
the
key
exchange.
I
think
that
would
be
bad
and
dangerous.
N
So
we
don't
have
that.
Definitely
we
don't
allow
that,
because
the
protocol
actually
enforces
that
everyone
sees
the
same
thing.
N
I
mean
that
would
not
be
visible
by
other
members.
The
only
the
I
mean,
let's
be
clear,
any
application
can
do
that
right,
like
any
application,
can
link
that
or
any
any
programs
that
forwards
the
message
to
from
so
any
malicious
participant
can
do
that.
But,
like
forwarding
messages
I
mean,
but
they
cannot
add
people
that
won't
be
detect.
That
won't
be
actual
members
of
the
group.
N
What
I
mean
by
that
is
that
the
cryptographic
state
will
include
the
the
key
from
someone
that
has
been
added,
but
the
application
must
know
that
you
know
the
this
person
hasn't
sent
them.
A
message
to
that
to
that
group
is,
it
is,
is
what
I
said
here
I
mean
the.
The
fact
is
that,
philosophically
you
can't
either
participant
you
can't
do
like
the
uk
backdoor
thing
thing.
O
Okay,
yeah,
that's
it's
it's
reassuring
and
I
think
it
suggests
that
chelsea's
comment
is
really
about
clarity
of
the
text
rather
than
safe
safeness
of
the
protocol.
Thank
you.
B
I'm
going
to
do
is
I'll
benjamin
to
answer
your
question.
I'm
going
to
ask
for
volunteers:
is
there
anybody
that
wants
to
go
on
the
record
for
saying
that
they're
willing
to
review
this
soon,
because
otherwise
we
are
actually
going
to
do
a
working
group
last
call
and
there
I
would
love
to
have
some
people
also
volunteer
on
the
record,
to
have
a
review.
B
It's
hard
it's
hard
for
me
to
tell
benjamin
hey,
make
some
changes
he's
like
nobody's
asked
for
any,
so
I
do
think
that,
as
we
progress
this
into
a
working
group
last
call
that
the
reviewers
will
come
out
of
the
woodwork
and
that's
certainly
when
we
progress
this
to
the
air
director.
We'll
probably
get
some
reviews.
I
don't
know,
I
assume
we're
probably
gonna
get
paul.
B
I
think
we'll
get
some
reviews,
but
I
know
that
when
we
leave
the
working
group,
we're
gonna
get
comments
from
people,
so
so
all
right
cool.
I
didn't
get
any
people
that
volunteered,
but
we'll
we'll,
I
think
we're
gonna
get
some
by
force
of
nature
here.
So
the
last
little
bit
here.
H
B
Federation,
so
raphael,
if
you
want
to
jump
in.
P
So
yeah
a
really
long
time
ago,
the
working
group
created
a
document
called
federation,
because
at
the
time
a
number
of
parties
had
expressed
some
interest
in
that
we
haven't
really
been
working
on
it
because
we've
been
focusing
on
the
protocol
itself
and
the
delivery
service
and
the
authentication
service.
P
So
it's
become
quite
stale
at
this
point,
but
in
the
meantime
the
protocol
has
matured
and
we
are
relatively
close
to
the
work
group.
Last
call
now
we
have
several
implementations.
We
even
have
one
deployment,
so
that
means
that
we
can
actually
we're
now
in
a
better
position
to
talk
about
federation
with
all
the
experience
we
have
now.
P
So
the
idea
here
is
to
see
if
we
can
resurrect
the
federation
documents
and
the
old
version
is
still
around.
You
can
use
that
as
a
starting
point
and
modernize.
It
specifically
rowan
has
proposed
to
make
some
initial
contributions
to
that
and
as
a
reminder,
maybe
this
document
is
a
non-normative
document,
meaning
it's
not
intended
to
specify
a
full
wire
format
to
do
federation.
P
B
Yeah,
so
the
only
thing
I
want
to
add
for
those
process,
wonks
that
might
be
in
the
room
or
on
the
in
the
thing
here
is:
we've
already
adopted
this
draft
and
there's
a
repo
for
it
that
we're
gonna,
let
the
editors
do
their
thing.
If
they've
they
want
to
rewrite
the
document
or
whatever
they're
just
going
to
go
ahead
and
do
that
we're
not
going
to
do
the
whole
individual
re-adopt
process
delay
we're
just
going
to
set
them
free.
B
Basically-
and
so
I
thank
you
for
reinvigorating
that,
because
it's
one
of
the
things
that's
on
our
to-do
list.
So
thanks
and
thanks
everybody
for
showing
up
it's
901.
thanks
for
staying
that
extra
minute
go
get
some
libations
before
the
plenary
or
the
ohio
or
wherever
else,
you're
gonna
go
next
thanks
a
lot
thanks.
So
bye
expect
some
mail
to
list
ciao.