►
From YouTube: IETF114-MLS-20220729-1630
Description
MLS meeting session at IETF114
2022/07/29 1630
https://datatracker.ietf.org/meeting/114/proceedings/
A
All
right:
well,
it
is
12
30.,
we're
gonna,
give
it
a
couple
minutes.
There's
a
grand
total
of
five
people
in
here
and
some
others
are
straggling
in.
So
we
also
are
not
going
to
take
the
full
two
hours,
so
everybody
just
kind
of
relax
for
a
little
bit.
C
It
is
popular
we're
just
you
know,
popular
from.
A
A
So
for
those
that
are
remote,
I've
got
all
the
slides
lined
up.
So
when
you're,
when
you're
presenting-
and
you
want
to
go
to
the
next
slide-
just
say
next.
E
Is
anyone
in
the
room
or
online
willing
to
be
note
taker.
D
A
A
A
I'd
say:
that's
a
pretty
good
way
to
start
all
right.
Well,
let's
get
started
here.
Welcome
to
the
illness
working
group,
it's
the
end
of
the
week.
Hopefully
everybody's
seen
all
the
slides
a
couple
of
times.
A
If
you
didn't
mean
to
be
here,
go
back
to
bed
or
go
have
lunch
or
wherever
you
are
in
your
time
zone.
Here's
the
note!
Well,
it's
the
end
of
the
week
again,
you
should
have
seen
this.
This
is
the
say
something
if
you
know
something
about
ipr.
A
You
know
other
policies
about
you
know
not
harassing
each
other
coda
conda
and
the
like
we'd
also
like
to
bring
up
the
itf
code
of
conduct,
guidelines
which
are
enshrined
in
rfc
7154
about
trading
quality
with
respects
the
one
that
I
think
they
put
in
for
me,
which
is
to
speak
slowly
and
limit
the
use
of
slang
dispute
ideas
with
recent
argument.
Use
best
engineering
judgment
find
the
best
solution
for
the
whole.
A
The
internet
contribute
to
the
ongoing
work
of
the
itf
and
remind
yourself
that
this
applies
both
to
in
person
and
in
java,
zulip
or
wherever
the
heck
you
are
when
you're
contributing
in
this
working
group
we've
had,
I
think,
zero
problems
and
that's
been
very
nice
all
right
our
agenda.
So
another
reminder:
if
you're,
local
and
you're
in
the
room
mask
up,
I
will
call
you
out.
A
A
little
closer
yeah
sure
the
note
well,
if
you're
gonna,
if
you're
local,
please
use
the
online
tool
so
that
we
can
manage
the
queue
fairly
with
those
that
are
remote.
We've
identified
a
note
taker.
Thank
you
to
our
area
director.
We
have
a
jab
prescribed.
This
is
somebody
I
assume
is
in
the
chat
room
that
will
thank
you,
dkg
we're
going
to
go
through
some
quick
status
and
then,
basically,
the
agenda
is
to
talk
about
the
drafts
that
we
have
and
one
that's
up
for
consideration.
A
The
two
are
protocols
are
the
protocol
and
the
architecture
document,
the
federation
document,
extensions
and
content
negotiation.
Any
agenda
bashing,
all
right,
so
our
status
we've
got
our
architecture
draft,
which
is
basically
waiting
on
the
chairs
to
complete
the
review
to
get
to
the
ad.
Technically
I'm
waiting
on
all
the
authors
to
respond
to
the
questions
before
I
send
it
to
paul-
and
I
started
that
wrangling
I
think
yesterday
afternoon,
so
it
shouldn't
take
that
long.
A
The
the
federation
draft
we
actually
revived
since
the
last
meeting
and
the
extension's
draft
is,
is
brand
new,
and
this
is
our
little
for
those
who
don't
know
how
this
works.
This
is
kind
of
the
winding
path
that
we
go
through
to
get
to
an
rfc
and
we're
after
working
group
last
call.
I
have
changed
these
slides
over
time.
A
So
if
you
remember
to
look
back
at
the
other
ones,
the
the
list
of
drafts
12
through
16
were
kind
of
spread
out
on
the
rest
of
the
path
and
as
usual,
sometimes
you
do
a
working
group
last
call
and
then
you,
you
iterate
a
bunch
before
you
actually
get
out
the
door.
So
that's
that's
basically
what
happened?
A
We
may
even
have
another
one
before
we
end
up
sending
it
paul
or
before
it
goes
on
to
the
isg,
because
paul
will
have
his
comments
and
that
may
result
in
changes
as
well,
and
so
we
just
kind
of
iterate
through
the
drafts,
as
we
go
through
the
various
processes,
and
that
is
it
for
the
status
update.
I
guess
I'd
say
I
didn't
make
one
of
these
for
the
architecture
document,
because
we
they're
going
to
kind
of
have
to
go
together,
and
so
the
numbers
are
different,
but
it
it.
A
It
got
last
called
and
got
reviewed
what
I
was
really
happy
with
during
the
working
group.
Last
call
for
the
for
the
protocol
document
was
that
you
know
when
we
started
this
whole
process.
We
made
this
kind
of
like
promise
what
the
security
researchers
like
to
take
their
input
and
they
actually
provided
and
put
directly
back
to
us
to
say,
hey.
We
thought
it
was
good,
so
I'm
pretty
happy
with
that.
C
All
right,
so
I
mean
this
is
a
super
quick
update
on
the
protocol
document,
because
we
had
several
interims
where
we
covered
all
the
interesting
stuff
and
now
we're
kind
of
in
quiet
period
waiting
for
the
adhd,
but
I
thought
I'd
at
least
give
the
folks
in
a
room
a
brief
catch
up
on.
What's
happened
since
the
last
ietf
meeting
so
next
slide.
Please.
C
So,
since
the
last
ietf,
we
had
a
working
group
last
call
shortly
after
the
ietf
that
led
to
a
bunch
of
good
comments,
got
a
bunch
of
good
feedback.
As
a
result
of
that
last
call
had
several
interims
every
couple
weeks
thereafter
trying
to
get
work
through
those.
So
it
took
us.
You
know
three
or
four
cycles
to
get
through
that,
but
that
led
to
draft
15,
which
was
last
called
again
and
that
one
went
clean.
C
I
think
there
was
just
a
couple
minor
edits,
I'll
talk
about
in
a
second
that
was
draft
16
and-
and-
and
here
we
are-
the
f16-
we're
ready
to
go
to
the
dad
next
slide.
Please.
C
So
just
brief
update
on
draft
15..
This
is
the
changelog
I've
been
doing
this
last
few
drafts,
like
you,
can
see.
There's
there's
a
bunch
of
substantive
stuff
here,
which
I
got
fixed
in
as
a
result
of
working
group.
Last
call
I'm
not
going
to
go
through
all
of
these,
I'm
just
going
to
go
through
the
first
one,
because
it's
the
the
biggest
one,
it's
kind
of
the
most
substantial
one.
C
Next
slide
at
least
one
of
the
things
that
was
noted
as
folks
were
taking
a
detailed
look
at
the
algorithms
was.
There
are
some
cases
where
there
are
ambiguities
that
had
arisen
because
we
were
suppressing
redundant
nodes,
and
so
you
wouldn't
always
have
you
know
a
path
that
would
go
all
the
way
to
the
the
root
of
a
tree
and
things
like
that.
C
Now,
instead
of
adding
one
leaf,
you
double
the
size
of
the
tree
and
you
add
one
leaf
and
a
bunch
of
blanks.
So
that
means
you
have
bigger
trees.
Logically
speaking,
oh
sorry,
the
other
mechanistic
view
is
when
you,
when
you
remove
people
from
the
group,
you
kind
of
garbage
collect
the
trees.
You
go
before
you,
you
know,
as
when,
adding
you
would
remove
the
last
leaf
and
you
would
remove
individual
leaves
until
you
got
to
the
next
non-blankly.
C
With
this.
You
know,
when
you
remove
the
last
person
out
of
that
right
hand,
sub
tree,
you
cut
the
tree
in
half,
you
take
the
left,
sub
tree
and
so
on,
and
so
you
get
to
the
next
non-blank
leaf.
So
you
have
this
kind
of
doubling
and
halving
style
of
change
to
the
tree
as
opposed
to
one
by
one's
more
continuous
change.
C
This
makes
the
tree
math
a
lot
simpler
as
it
as
a
nice
consequence
and
especially
around
the
parent
hash.
A
lot
of
the
complexity
we
had
around
the
parent
hash
was
the
need
to
kind
of
recompute
an
earlier
form
of
the
tree
structure.
At
the
time
the
parent
hash
was
computed.
Here
we
don't
change
the
structure
of
the
tree.
C
You
know
once
you
know,
a
node
is,
is
in
place
like
structure
beneath
it
doesn't
change,
so
we
save
a
lot
of
complexity
there
so,
like
I
said
a
moment
ago,
like
that,
you
end
up
with
a
lot
of
extra
blank
nodes
on
the
right
edge
of
the
tree
in
some
cases,
so
as
I've
shown
on
the
bottom
here,
when
you
add
the
ninth
leaf,
you
end
up
with
seven
extra
blank
nodes
and
all
their
parents.
C
C
So
you
can
kind
of
generate
these
on
the
fly
as
you
need
them
and
the
only
time
you
ever
need
them
is
when
you're
computing,
the
tree
hash
of
the
overall
tree,
and
even
for
that
you
can
kind
of
pre-compute
the
sub-trees
you're
likely
to
need
the
all-blank
sub-trees
in
certain
positions.
C
So,
even
though,
there's
a
bunch
of
kind
of
extra
nodes
in
theory
here
they
don't
actually
end
up
having
much
performance
impact
on
the
protocol.
So
that's
that's
the
biggest
change
in
draft
15.
C
And
draft
16
was
again
after
our
second
last
call.
Didn't
really
get
any
any
substantive
comments
here.
I
think
jfio,
while
has
noticed
that
there
was
a
field
missing
in
the
to
be
signed
version
of
group
info.
We
added
that
back
colin
suggested.
We
move
a
reference
to
normal
so
for
informative,
so
it
made
that
change
that
that's
the
only
stuff
in
the
diff.
C
A
Or
comments
yeah,
so
I
think
we're
going
to
be
good.
The
write-up
will
be
done
probably
sometime
next
week
and
then
I'll
pass
it
over
to
you
and,
depending
upon
your
vacation
schedule
for
the
rest
of
the
you
know
the
summer
we'll
we'll
get
through
it.
So
I'm
hoping
I'm
cautiously
optimistic
that
we
can
start
the
reviews
because
you'll
press
the
button
you
know
before
the
end
of
august
and
then
for
those
who
might
not
have
been
involved
in
the
itf
for
a
long
time.
A
The
cycle
will
kind
of
continue
we'll
get
director
reviews
from
other
areas.
So
they'll
start
looking
at
all
kinds
of
things
that
we
never
even
thought
about
and
we'll
have
to
address
those
comments
as
we
move
forward.
So,
okay,
so
next,
I
believe,
is
benjamin.
A
All
right,
well,
I
mean
so.
The
nice
thing
is
the
architecture
document
was
kind
of
like
it's
the
one
that's
going
to
go
with
the
protocol
document
and
explains
a
bunch
of
things.
I
think
he
was
really
good
about
keeping
them
aligned
to
make
sure
things
were
explained.
So
mostly
what
he
said
in
an
email
to
me
was.
A
There
are
some
things
that
we
could
talk
about,
that
we
could
do
for
the
future,
but
I
think
we
should
get
done
what
we're
doing
now
before
moving
on
to
the
next
thing,
because
that
often
causes
problems
so
all
right.
Well
that
then,
we'll
move
over
to
raphael-
and
I
see
him.
F
Think
we're
going
to
need
that
much
time
so,
especially
since
last
time
we
already
touched
on
the
federation
document,
so
this
is
actually
just
a
brief
overview
again
for
those
who
didn't
attend
last
time,
so
the
federation
document
has
been
there
for
a
while,
it's
been
updated
now
and
then
we
also
want
to
talk
about
brand
new
document.
Like
sean
said,
the
extensions
document
next
slide.
Please.
F
So
the
federation
document
hadn't
seen
any
updates
in
a
while,
and
so
now
the
scope
is
is
more
clear
than
in
the
beginning.
So
this
is
clearly
a
non-normative
document,
conceptually
more
like
the
architecture
document,
but
with
a
narrower
scope,
focusing
on
interrupt
and
federation
and
outlining
different
deployment
scenarios,
giving
some
high-level
guidelines
on
how
applications
could
structure
things,
whether
it's
different
servers
that
interoperate
or
clients
from
different
vendors
that
all
talk
to
the
same
server,
and
there
are
few
security
considerations
as
well.
F
So
since
it's
not
normative
it's,
it's
not
prescriptive
in
the
way
of
how
federation
should
be
done
with
mls,
it's
really
just
there
to
give
an
overview.
It
doesn't
give
any
any
wire
format
for
messages
in
a
federated
context,
or
anything
like
that.
So
we
think
there
was
a
consensus
that
we
said
that
the
charter
of
this
working
group
shouldn't
accommodate
for
that.
F
That
describe
all
of
these
different
aspects
of
federation
and
that
might
very
well
be
the
case
going
forward,
for
example,
with
the
soon
to
be
hopefully
mimi
working
group,
and
once
that
is
there
and
and
the
scopes
are
aligned,
then
potentially
this
document
could
actually
reference
specific
normative
documents.
There.
F
Yeah,
that
was
federation
next
slide.
Thank
you
so
yeah
over
the
just
to
zoom
out
a
bit
over
the
past
few
years,
we've
really
tried
to
make
mls
work
for
different
kinds
of
deployment
types,
different
applications,
etc.
So
the
outcome
of
that
is
that
the
mls
protocol
is
relatively
versatile.
F
So
the
idea
here
was
to
outsource
that
into
an
extensions
document,
so
we
specifically
started
with
the
app
act
mechanism
that
used
to
be
in
the
mls
protocol
document,
and
that
is
now
the
first
extension
in
the
mls
extensions
document.
There
is
a
pr.
F
That
we
discussed
in
the
past-
and
there
are
a
few
applications
that
were
interested
in
it
and
that
is
targeted
messages.
So
that's
not
in
the
document
yet,
and
it's
going
to
need
some
more
review.
B
Yeah
yeah,
it
just
took
a
really
long
time
for
my
my
mute
button
to
turn
off.
So
thanks
thanks
for
for
writing
this
up
raphael.
I
my
my
only
question
here
is
whether
we
want
to
have
individual
doc,
like
small
documents,
where
we
have
an
mls
app
back
document
and
an
mls
targeted
messages
document.
B
My
intuition
is
that
having
a
handful
of
small
ones
is
better
than
having
one
sort
of
you
know,
one
catch-all,
because
the
maturity
of
in
the
individual
extensions
may
be
very
different,
and
the
security
considerations
would
be
easier
to
understand
if
they
are
individual.
So
that's
just
a
preference.
I
don't
have
a
huge.
You
know
strong
feeling,
but
just
something
I
wanted
to
bring
up.
F
Yeah,
that's
definitely
a
good
point
and
I
think
we
discussed
it
in
the
past
as
well.
So
I
guess
for
now
the
the
consensus
is
that
we
should
have
this
one
document,
especially
since
what
we
are
concretely
discussing
is
relatively
small.
F
What
wouldn't
work,
for
example,
is
if
we
had
extensions
that
are
very
complex
and
that
would
mandate
a
very
long
description,
etc,
so
that
that
would
be.
That
would
put
too
much
strain
on
the
extensions
document,
and
in
that
case
it
would
probably
have
to
be
a
separate
document.
But
the
idea.
C
F
See
if
we
can
collect
some
of
these
low-hanging
fruits,
essentially
that's
in
the
case
of
the
apec
mechanism
that
didn't
make
it
into
the
protocol
and
that's
relatively
short,
and
the
same
goes
for
targeted
messages,
but
it's
not
prohibitive.
I
think,
in
the
sense
that
you
could
always
have
an
extra
document
for
something
much
more
specific.
F
C
Yeah,
I
was
just
gonna
basically
post
whatever
rafael
said,
I
I
looked
into
the
kind
of
precedent
for
this
in
the
ietf
stream
that
the
apps
comparison
here
that
I
found
was
rfc
6066,
which
I
linked
in
the
chat,
which
is
a
bucket
of
small
extensions
to
tls
that
was
published
shortly
after
tls
1.2.
C
So
it
seems
like
that,
there's
precedent
for
either
approach
here.
I
think
raphael's
spot
on
that.
If
these
are
small
things
that
aren't
sort
of
big
enough
and
complex
enough
to
merit
their
own
documents,
then
it's
fine
to
just
make
a
document
that
this
has
several
of
them
together
and
I'll
note
that
6066
is
highlight
has
such
important
things
as
things
like
server,
name
indication
and
the
cert
is
ocsp
stapling
extension
as
well.
C
So
there's
there's
some
widely
used
extensions
that
went
in
there,
but
still
were
simply
enough.
It's
like
a
multi-extension
document.
A
Run,
I
think,
basically,
if,
if
somebody's
really
hard
over
on
wanting
to
make
sure
there's
like
a
generic
extensions
document
and
then
little
ones
and
and
littler
ones
for
the
actual
extensions
themselves
and
they
can
get
to
the
microphone.
But
I
think
this
is
a
editorial
kind
of
thing
and
I
think
the
maybe
the
isg
will
will
get
it'll
get
through
easier
because
there's
an
actual
extension
in
the
extension
document
from
the
chew
on.
I
can
imagine
some.
A
You
know
that
we
sent
a
blank
extension
document
forward
to
them
and
they'd
be
like
what
are
you
going
to
use
it
for,
if
you
don't
need
it,
while
you're
wasting
our
time?
So
I
don't
know,
I
can
kind
of
see
it
both
ways.
So
unless
somebody
really
has
a
strong
opinion
about
this,
we're
just
going
to
launch
forward.
F
Yeah,
that's
pretty
much
the
the
status
quo
for
extensions,
I'm
curious
to
see
if
folks
have
comments
on
it
going
forward
in
a
way.
This
might
also
be
the
escape
patch
for
things
that
we
didn't
think
about
in
the
context
of
the
protocol,
but
that
we
now
discover,
as
we
implement
mls
into
existing
systems.
A
Can
I
see
a
show
of
hands
for
people
who
have
read
the
draft
in
the
room?
Let
me
get
rid
of
it
all
right,
so
there
there
was
nobody
raised
there
or
one
thank
you.
Mallory
that
have
read
it
so
we'll
have
to
we'll
have
to
beat
the
drum
granted
it's
a
new
draft.
So
maybe
that's
understandable.
B
A
B
Okay,
I
saw
raphael's
and
sean's
all
right
next
slide.
Please.
B
Well,
what
is
the
what's
the
format
of
application
data,
because
it's
completely
opaque
this
that
attribute
makes
it
really
difficult,
for
example,
to
if
you
have
a
long-lived
group
like
in
an
instant
messaging
context,
you
could
easily
imagine
a
group
that
has
been
around,
for
you
know
two
three
five
years:
switching
content
formats,
because
you
upgraded
some
software
because
you
added
a
new
feature.
That's
really
difficult!
If
you
don't
have
some
kind
of
content,
negotiation
mechanism
and
interoperability
is
also
challenging.
B
B
So
I
wrote
up
another
two
mls
mls
extensions
as
a
proposal.
B
So
if
you,
when
you
publish
key
package,
you
can
list
this
and
you
can
just
go
nuts
and
lists
a
bunch
of
different
media
types
that
you
support
for
your
particular
client
and
then
in
the
group
context.
Then
there's
a
separate,
a
separate
extension
required
media
types,
and
so
if,
if
the
creator
of
a
group
wanted
to
say
all
members
in
this
group
need
to
support
this,
this
media
type
or
this
list
of
media
types,
they
could
express
that
with
the
required
media
types
extension.
B
So
what
is
a
media
type
there
is
you
know
if
you're
using
http
you're
using
them
every
day,
there's
an
extensive.
I
am
a
media
types
registry.
B
You
know
you
probably
have
seen
you
know
image.
Jpeg
text
plain
text
markdown,
but
there
are
there's
an
extensive
list
that
already
exists.
You
can
define
new
ones
via
via,
I
think
specification.
B
B
Okay,
so
in
terms
of
the
format
of
a
of
an
mls
of
the
application
data
in
an
mls
message,
the
this
extension
says:
okay,
if
there
is
a
required
media
types
in
the
group
context,
then
that
implies
that
you
want
to.
B
You
want
to
use
this
additional
little,
very
lightweight
application
framing,
which
uses
the
tls
presentation
language.
So
there's
the
struct
right
here
there
is
a
single
media
type
and
then
there
is
the
rest
of
your
application
content
and
the
media
type
itself.
It
could
be
a
zero
length
vector
and
if
you
put
a
zeroing
vector
there,
then
the
you
know
this
proposal
says
assume
the
first
media
type
listed
in
the
required
media
types
list.
B
So
if
you
wanted
to
use
this
application,
framing
the
amount
of
extra
overhead
is
very
small.
It
would
be
between
three
and
four
bytes
if
you,
if
you
think
you're,
always
going
to
be
sending
the
same
media
type,
and
if
you
want
to
be
able
to
do
something
in
the
future
and
use
a
different
media
type,
then
you
can
still
do
that
and
there's
no
confusion
about
what
the
format
is
of
the
application.
Data
ted.
G
Howdy,
I
actually
put
my
my
hand
up
when
we
were
still
talking
about
the
ayanna
registry
aspect
of
it,
and
I'm
going
to
suggest
that
you
may
want
to
think
about
how
you
interact
with
the
registry
a
little
more
in
depth,
because,
in
addition
to
having
some
top-level
types,
which
are
almost
certainly
going
to
be
very
difficult
to
to
imagine,
use
here
like
model
there,
there
are
also
a
whole
bunch
of
media
types
where
the
interesting
bits
actually
start
occurring
in
the
parameters
rather
than
in
the
media
type
itself.
G
So
when
you're
looking
at
the
media
type
here,
you
may
want
to
think
about
whether
you
want
to
break
it
down
into
media
type
and
parameters
and
carry
those
separately
in
the
application
content
here,
so
that
people
can
actually
do
the
kind
of
content
negotiation
applications
that
you
actually
see
in
in
in
other
protocols,
and-
and
I
will
tell
you
that,
having
led
one
of
those
content,
negotiation
working
groups
through
to
its
fiery
death
connect
that
there
are
a
whole
bunch
of
these
things
that
that
people
do
add
as
bells
and
whistles
that
don't
get
used.
G
But
then
there
are
also
some
aspects
of
it
that
you
really
do
need
that
go
beyond
just
the
media
type
itself.
So
I
would
suggest
making
this
a
little
bit
more
complic
complex
in
the
structure
to
allow
for
required
parameters
and
also
to
limit
the
number
of
media
types.
You're
actually
willing
top
level
media
types
you're
willing
to
deal
with,
just
because
otherwise,
you're
you're,
probably
going
to
give
yourself
a
little
bit
of
pain.
B
Okay,
so
if,
if
I'm
understanding
you
correctly
in
you
can
see
in
required
media
types
wanting
to
specify
parameters
in
required
media
types,
that
may
be
a
subset
of
what
you
would
put
in
the
media
type
in
the
application
framing.
G
You
have
here
I'm
going
to
pick
something
out
of
the
registry.
E
G
So
that
car
said
one
of
the
most
complex
possible
examples,
but
a
good
example.
Despite
that,
you
will
find
that
there
are.
There
are
going
to
be
cases
where
you're
like
look.
I
don't
really
speak
anything
but
utf-8,
and
so
it's
required
that
you,
if
you're,
going
to
specify
a
car
set
to
to
your
textual
one
that
it's
gonna
be
utf-8,
because
if
you
send
me
some
weird
old,
japanese
one
from
the
the
70s,
I'm
just
going
to
work
all
over
you
anyway,
so
you
might
as
well
give
up
now.
G
E
Daniel
khan
gilmore,
most
of
what
I
wanted
to
say
ted
has
already
said
so
one
plus
one
those
comments.
I
wanted
to
also
flag
that
in
your
example,
you
had
mentioned
a
multi-part
alternative,
which
seems
to
imply
like
a
mime
framing,
but
I
don't
see
mime
in
the
rest
of
this,
and
so
I
just
wanted
to
you
know,
maybe
I'll
add
that,
to
the
add
multi-part
to
the
list
of
scary
things,
scary
top
levels
that
you
might
want
to
consider
ruling
out
here.
E
And
there's
a
lot
of
multi-part
there
and
it
you
know
multi-part
is,
is
basically
flexible
enough
to
destroy
you
or
to
destroy
itself.
If
you
get
it
wrong,
so
yeah
there's
just
there's
a
lot
of
dragons
there
that
I'm
not
sure
you
want
to
easily
claim
support
for.
B
So
before
you
sit
down,
I
just
want
to
say
that
the
inclusion
of
multi-part
alternative
was
intentional,
because
I
think
we
want
the
semantics
of
multi-part
alternative
and
if
somebody
wants
to
propose
some
alternate
syntax
that
doesn't
use
my
boundaries,
then
that
would
be.
That
would
be
welcome,
and
I
also
can
imagine
a
number
of
multi-part
types
that
I
really
really
like.
Multi-Part
report
is
going
to
be
completely
irrelevant.
I
think
that
we
will
never
ever
want
to
use.
E
I'm
just
aware,
as
someone
who
tends
to
prefer
to
read
the
text
plain
parts
of
multi-part
alternatives
that
the
intent
of
multi-part
alternative
is
not
often
honored
by
the
sender
and
in
fact
the
sender
often
doesn't
know
that
they're
using
it
and
I
regularly
get
mail
that
doesn't
make
any
sense.
And
then
I
switch
to
the
text
to
the
text.
Html
part,
and
I
learn
that
the
content
is
entirely
different
and
the
majority
of
the
semantics
for
what?
What.
E
As
far
as
I
can
tell
the
vendors
that
are
flaunting
their
use
of
multi-part
alternative
these
days
is
we
know
how
to
stuff
a
tricky
thing
into
the
email
summary
that
you
see
in
your
inbox,
because
that's
what
the
text
plain
part
gets
used
for
in
some
in
some
male
user
agents
and
that
doesn't
have
anything
to
do
with
the
content
of
the
message.
So
I'm
just
I'm
just
observing
that
multi-part,
alternative
and
and
some
of
the
other
pieces
can
be,
can
be
very
subtly
abused.
E
E
I
mean
it's
there's
I
don't
think
we
know
how
to
do
it
in
email
and
we've
been
trying
to
do
it
for
40
years,
30
30
years,
at
least
in
email
and
and
so
importing
that
into
mls
might
or
might
not
be
what
you
actually
want
to
do.
D
Speaking
as
an
individual,
I'm
a
little
worried
about
the
part
where
you
say
if
the
media
type
is
empty.
The
first
media
type
is
assumed,
because
this
is
a
typical
thing,
where
there's
a
list
of
10
media
types
and
10
years
down
the
line.
Nobody
uses
the
first
entry
anymore,
everybody
switched
to
the
fifth
one
and
now
there's
a
bug
in
some
10
year
old
code,
and
now
you
can
send
a
malicious,
a
message
that
triggers
you
you
to
use
that
gold
path
that
you
haven't
used
for
10
years.
B
Well
so
I'll
point
out
that
the
so
if
people
don't
you
know,
this
is
a
proposal.
So
if
people
don't
ever
want
to
have
a
sort
of
an
abbreviated
way
and
always
want
to
send
a
media
type,
then
we
can
just
remove
the
first
media
type
is
assumed,
and
so
that's
one
discussion
separately.
B
B
Let's
see
it's
called
the
group
context
extension
or
something
like
that
there
there's
a
proposal,
type
that
you
can
send
to
the
group
that
updates
your
group
extensions,
so
that
everybody
agrees
that
these
are
the
new
extensions,
and
so
that
would
be
an
easy
way
to
update
the
required
media
types
extension
to
have
a
different
list,
and
all
you
would
require
is
that
all
of
the
all
of
the
members
at
that
moment
in
that
epic
had
support
for
the
for
the
media
types
that
were
in
the
required
media
types
list.
Then
the
new
list.
A
G
So
I
wanted
to
to
kind
of
go
back
to
a
bigger
principle
here,
because,
as
I
was
thinking
when
daniel
kahn
gilmore
was
talking
about
multi-part,
I
was
thinking
oh
yeah
and
multilingual.
Don't
get
me
started
right
because
there's
a
whole
bunch
of
stuff
where
in
in
order
to
get
the
multilingual
stuff
to
look
even
vaguely
realistic,
you
have
to
know
a
whole
bunch
more
than
you
could
possibly
get
into
this
into
this
structure
and,
frankly,
a
whole
bunch
more
even
than
the
mime
parameters
typically
tell
you.
G
So
what
I
would
suggest
here
is
that
you
actually
consider,
instead
of
making
this
people,
can
send
anything
that
you
actually
consider
starting
out
with
this
being
an
mls
registry
of
mime
types
that
are
permitted
and
you
can
decide
whenever
you
get
the
registry
expert
assigned
what
level
that
needs
to
be
right.
G
Whether
it's
like
all
of
image
is
okay
and
people
can
send
whatever
proposal
for
the
image
type,
that
that's
that's
cool
or
they
can
send
anything
for
text
and
that's
cool,
and
if
somebody
tells
you
that
they
want
to
to
add
you
know
font
or
model
or
multi-part
you,
you
go
down
and
say:
okay,
we're
going
to
say
these
are.
These
are
now
described
in
a
way
that
these
are
comprehensible
and
we
can
say
yes
right,
then
this
is
okay.
G
So
you
might
end
up
saying
multi-part
report
is
the
multi-part
that's
accepted
into
the
registry,
where
image
slash
is
just
to
that
level
of
differentiation,
because
I
have
a
strong
suspicion
that
over
time
you
would
develop
the
muscle
that
would
say
you
this.
This
is
an
easy
job
for
the
for,
for
the
the
registry
expert
four
years,
five
years
in,
but
the
first
few
going
through
people
really
are
gonna
have
to
have.
G
You
know
somebody
like
murray
who's
done
with
media
type
registration
for
a
long
time
to
sit
down
with
them
and
say:
have
you
thought
about
x?
You
know,
and
do
you
understand
what
it's
going
to
mean
when
you
you
do
something:
that's
like
a
binary
type
which
doesn't
convey
any
actual
semantics
or
something
like
mp4,
where
it's
all
actually
inside
the
container
and
the
media
type
doesn't
tell
you
anything,
you
know.
B
Okay,
so
one
thing
I
wanted
to
clarify
ted,
I
think
you
meant
probably
like
a
mimi
specific
registry
because,
like
for
mls
like
I
could,
I
could
use
mls
to
distribute
fonts
among
my
laser
printers,
and
I
could
have
an
mls
group
that
I
used
to
exchange
those
fonts
and
I
could
use
the
font
type
and
that
would
be
like
up
to
me
to
figure
out
how
to
make
that
work
nicely.
But
for
instant
messaging
like
I
would
want
a
profile
that
says.
B
No
worries:
okay,
let's,
let's
move
on
to
the
next
slide,
please
so.
B
All
right,
so
we
had
a
lot
of
discussion
about
the
content
negotiation
part
of
this,
but
if
we
want
to
use
an
mls
extension
in
order
to
signal
any
of
this,
then
some
of
this
work
needs
probably
needs
to
happen
in
the
mls
working
group.
B
And
so
then
a
question
is:
do
we
want
to
do
this
work?
Do
we
want
this
work
to
go
into
the
generic
extension
you
know?
Do
we
want
the
extension
part
to
go
into
a
generic
extensions
document?
Do
we
want
a
separate
document?
B
You
know?
Is
this
a
reasonable
start
to
that
problem?
If
we
want
to
do
that
problem,
so
the
number
of
questions
here
so
I
would
like
to
oh
yeah-
and
I
just
wanted
to
say,
like.
B
That
please
please,
if
you,
if
you've,
got
something
that
you
want
to
say
about.
Oh
you
know
I
don't
like
this
or
I
like
that
or
whatever.
Please
try
to
focus
on
the
semantics
first,
because
I
really
don't
care
very
much
about
the
syntax
of
this
document.
B
I
want
to
get
the
semantics
right
and
most
of
the
comments
of
the
mic
have
all
been
about
semantics.
So
I'm
quite
pleased
about
that.
So
maybe
I
will
pass
it
over
to
to
to
sean
to
talk
about
the.
A
Right
so
the
reason
why
this
obviously
isn't
in
the
extensions
draft
is
because
it's
kind
of
a
little
different
than
some
of
the
other
things.
The
first
thing
is
actually
a
question
that
we
have
to
ask
our
area
director
is
because
this
will
be
the
first
thing
that
is
about
enabling
interoperability
among
the
applications.
A
Where,
specifically
the
charter
says,
we
won't
do
that
now,
we
didn't
do
it
in
the
base
protocol.
We're
gonna
do
an
extension.
So
if
you
look
at
it
all
right,
I
think
it
probably
could
fit,
but
this
would
be
a
question
because
it
specifically
said
it
is
not
a
goal
of
this
group
to
enable
interoperability
federation
between
messaging
applications
beyond
the
key
establishment,
authentication
and
confidentiality
services,
so
we're.
But
I
would
look
at
that
as
kind
of
like
in
the
base
protocol.
A
This
is
an
extension,
so
I
kind
of
see
like
I
could
fit
and
we
won't
have
to
like
change
the
cart
charter
or
whatever,
to
like
call
it
extensions,
but
it
would
be
the
first
thing
so
and
you'll
know
that
the
discussion
that
we
had
for
20
minutes
about
media
types
is
one
of
the
reasons
why
this
working
group
didn't
want
to
do
any
of
that,
because
it's
all
a
specialized
expertise
area
that
not
a
lot
of
us
have.
So
I
guess
really.
A
C
C
That
kind
of
makes
me
wonder
if
this
might
be
a
little
simpler
if
it
were
a
little
bit
more
like
alpn
in
terms
of
abstraction,
so
you
could
have
say
a
generic
protocol
identifier
that
could
say
you
know
how
what
what
goes
on
inside
the
the
payload.
So
you
know
you
have
a
syntax
here
for
what
goes
inside
the
message.
Payloads,
maybe
a
different
app
wants
to
do
it
differently
or
something
like
that.
I
I'm
not
sure
that's
that's
worth
the
extra
indirection,
but
it
is
an
approach
out
there.
C
I
think,
generally,
in
terms
of
where
this
this
lives
it
kind
of
comes
down
on
to
how
much
of
the
complexity
that
was
just
discussed.
We're
gonna
have
to
take
on
here.
If
this
is
at
the
layer
of
this
kind
of
string
comparison,
I
think
it's
probably
compact
enough
to
take
on
here
and
take
on
in
the
just
let's
put
in
the
extensions
document.
C
If
it's
gonna
have
to
go
into
a
whole
bunch
of
mime
details
that
might
belong
a
little
higher
up.
The
stack.
A
C
While
you're
firing
that
I'm
just
going
to
repeat
something,
it's
a
comment,
ted
made
in
the
chat
that
the
the
mls
a
lpn
sort
of
thing
I
was
meaning,
would
be
like
to
have
an
extension,
an
mls
that
says
this
is
me
me,
and
then
you
know
whatever
content
negotiation,
you
did
would
be
the
specifics
of
the
content.
Negotiation
would
be
specific
to
the
mini
protocol.
A
Yeah,
so
if
you've
read
it,
I'm
starting
a
poll
just
raise
your
hand.
If
you
read
it,
I
mean
we
got.
You
know
out
of
10
people,
we
got
five,
that's
pretty
good.
Actually,
all
right!
So
are
there
any
objections
to
adopting
this
draft?
Obviously,
assuming
that
paul
says
yes,
it's
good
and
we
won't
we're
not
going
to
get
slapped
down
because
of
the
charter.
Are
there
any
objections
to
it.
A
F
Yeah,
I
think
the
the
point
you
brought
up.
So
it's
not
not
an
objection
per
se,
but
the
point
you
just
production
is
it's
quite
important
because
the
nature
of
the
discussion
we're
having
now
it's
fundamentally
different
from
the
discussions
we've
had
in
the
past
around
mls
and
and
you
you
bring
up
a
good
point
where
the
question
is
really
whether
the
expertise
that
is
required
for
these
kind
of
discussions,
you
know,
is
within
the
mls
working
group
at
this
point.
F
So
obviously
there
are
some
experts.
We
saw
that
in
the
past
20
minutes,
but
I'm
wondering
if
from
a
technical
perspective,
it
wouldn't
be
even
better
if,
if
that
was
done
somewhere
else,
like
I
think
in
in
the
comment
section
it's
just
from
from
ted
question
whether
this
couldn't
punt
the
whole
thing
to,
for
example,
the
mimi
working
group
to
be
something
like
that.
F
A
D
A
So
rohan,
I
know
you
were
looking
for
a
working
group
call
for
adoption,
but
I
think
we're
gonna
we're
gonna
we're
gonna,
wait
a
little
bit
and
try
to
beat
the
drum
to
get
people
going
and
yeah
I
mean
so.
The
great
part
is
you're,
actually
leading
the
effort
for
mimi
as
well.
So
you
know
if
we
get
that
kicked
off
and
going
maybe
it's
the
first.
Maybe
what's
the
thing
they
do
or
we
do
it
here
because
it
it
is
kind
of
simple,
but
it
is
kind
of
thorny.
A
It's
all
right,
and
that
brings
us
to
the
end
of
our
agenda.
Does
anyone
else
have
anything
to
add.