►
From YouTube: IETF113-MEDIAMAN-20220323-1200
Description
MEDIAMAN meeting session at IETF113
2022/03/23 1200
https://datatracker.ietf.org/meeting/113/proceedings/
A
So
it's
now
12
noon
and
we
have
a
whole
four
people
in
the
room
and
12
people
signed
in
to
the
to
the
media
to
the
meet
ago,
which
is
about
approximately
what
I
should
expect.
I
think.
A
A
B
A
A
I
must
admit
that
I
have
no
idea,
speaking
of
pronouns,
whether
manu
is
he
or
she
manus
pony
the
one
that
got
that.
Does
the
slides
have
me
multiple
suffixes
for
media
types,
but
I
I
got
that
person
shreds.
A
A
D
The
first
point
I
want
to
get
across
is
that
our
current
chart
this
currently
doesn't
say
that
we
have
to
create
such
a
document,
but
we
have
to
determine
whether
we
need
such
a
document.
So
keep
that
in
mind.
D
I
just
thought
I
would
kind
of
go
through
and
find
all
the
documents
that
actually
do
define
top
level
media
types
and
here's
what
I
found
rc
20
7070
is
not
mentioned
in
the
current
draft,
but
alex
malikov
sent
me
a
mail
and
told
me
that
that
was
the
number
that
I
needed
there's
also
first
of
april
one
and
there's
the
haptics
top
level
proposal
that
we'll
discuss
later
and
then
also,
I
found
a
chemical
top
level
type
that
is
not
officially
adjusted
and
it
has
a
lot
of
x,
hyphen
types
subtypes
in
it.
D
D
D
D
This
is
mostly
well
kind
of
putting
section
three
of
my
draft
on
a
slide.
This
is
just
a
collection
of
potential
criteria
that
we
could
actually
use.
D
Well,
one
thing
is
that
each
new
level,
top
level
type
should
be
air
and
therefore
each
probably
needs
separate
consideration,
and
if
there
are
a
lot
of
types
actually
in
the
wild,
that
was
the
case
for
font,
and
this
is
the
case
now
for
a
fan
chemical
that
might
be
an
indication
of
the
need
to
actually
formally
define
that
top
level
type
and
also,
on
the
other
hand,
undefined
top
level
types
should
be
highly
discouraged,
yeah,
and
so
these
two,
the
last
two
points,
are
a
little
bit
in
contest
to
each
other.
A
Just
I
forgot
one
important
thing
betty:
can
you
take
notes.
D
Okay,
then,
this
lists
the
formal
criteria
which
standard
stack
rfc.
We
probably
want
to
keep
that,
but
we
can
of
course
discuss
that
we
need
clear
criteria
for
what
belongs
in
the
new
top
level
type
and
whatnot,
and
we
need
some
initial
registrations
if
there's
just
an
idea
for
a
new
type,
if
I
know
actual
actual
types
there,
that's
probably
not
gonna
work
in
some
document.
D
D
C
So
this
is
barry
lieber.
Can
you
flip
the
slide
back
carl?
Thank
you.
The
I
want
to
just
want
to
make
sure
we
don't
just
do
that.
First
bullet
standards
track
rfc
without
thinking
about
it.
C
As
long
as
we're
changing
the
rules
for
this,
we
might
consider
whether,
having
standards,
whether
having
new
top
level
types
go
through
the
expert
reviewer
rather
than
having
to
have
standards
track
rfc
we
may
decide
we
want
to
keep
the
standards
track,
rfc
path,
but
I
just
want
to
make
sure
we
don't
just
blow
that
off
out
of
hand
alexei.
Do
you
have
a
thought
on
that
as
one
of
the
reviewers.
D
A
Yeah,
so
let's,
let's
try
to
to
take
the
discussion
after
the
full
presentation,
yeah.
So
fine.
D
Okay
on
this
slide,
I
put
a
few
points
that
they
found
in
previous
definitions
of
top
level
types,
these
previous
definitions,
like
the
font,
like
the
model
type
and
so
on.
They
have
to
kind
of
advertise,
they
have
to
advocate
for
this
new
type
and
they
bring
forward
various
criteria.
D
But
although
the
technology
for
that
is
maybe
not
ready
yet
also
whether
some
types
have
a
temporal
aspect
or
not
or
a
spatial
aspect,
it
can
affect
that
also,
whether
it's
easy
to
convert
within
a
type,
a
top
level
type,
then,
between
top
level
types,
for
example,
it's
easier
to
con,
convert
an
audio
format
to
an
audio
format
than
to
an
image
and
so
on,
and
also
the
practice
or
need
for
dispatch
on
top
level
types
and
the
existence
of
actual
subtypes
of
potential
subtypes
might
be
criteria
and
then,
of
course,
type
specific
criteria.
D
D
Iana
considerations,
what
I
discovered
is
that
there
is
currently
no
registry
for
top
level
types.
There
is
a
registry
for
subtypes
that
is
organized
by
top
level
types,
but
the
documentation
varies.
For
example,
you
can
find
that
there
is
a
model
top
level
type,
but
you
it's
not
possible
from
the
industry
to
find
where
this
is
defined
yeah.
D
So
maybe
we
have
to
tell
iona
to
organize
this
a
slightly
tiny
little
bit
better,
at
least
have
the
type
name
and
the
defining
rfc,
maybe
some
other
things.
Okay,
next
slide.
D
Okay,
these
are
mostly
notes
to
myself.
In
most
cases,
the
documents
speak
about
type
and
subtype,
whereas
it's
easier
to
say
top
level
type
to
make
it
clear.
Also
the
questions
where
the
top
level
should
be
with
five
now,
without
and
so
on,
but
that's
that's
really
details.
Okay
next
slide.
C
Okay,
this
is
barry
lieber
first
I'll
go
to
the
the
last
point
of
do
we
need
a
media
type
registry.
We
do
have
it
at
the
beginning
of
the
media
types
registry,
there's
a
section
that
lists
the
the
sub
registries
for
each
media
type
for
each
top
level
type.
So
we
actually
do
have
that
in
the
registry.
I
think
that's
that
point
is
not
necessary
to
address
at
all,
and
so
I
want
to
get
back
to
the.
E
I
think
there
is
actually
a
minor
subtle
issue
that
it
is
in
the
registry,
but
that's
what
ayanna
created
there
is
actually
no
creation
of
the
top
level
registry.
So
I
think
martin's
point
about
that.
Knowing
rfc
is
defining
top-level
types
is
sometimes
tricky.
E
D
C
Right,
it's
a
small
issue
yeah,
so
the
other
one
is
that
what
I
brought
up
before
the
my
reason
for
saying
we
should
think
about
at
least
is
I'm
looking
at
chemical
as
as
a
thing?
That's
it's
not
anything.
We
have
any
expertise
over
whether
that
should
be
a
top
level
registry
or
not
the
I.
The
ietf
participants
in
general
are
not
really
steeped
in
whether
a
new
media
type
should
be
created.
C
It's
the
experts,
you
ned
murray,
who
are
the
ones
who
really
have
a
sense
of
that,
and
basically
the
ietf
is
going
to
do
whatever
you
suggest.
So
why
not
just
skip
the
whole
standards
track
thing
and
and
let
that
go
through
the
media
types
experts
as
well
and
I'm
ambivalent.
I
can
go
either
way,
I'm
just
bringing
up
the
issue.
E
With
my
yeah
alex
a
alexey
with
media,
my
media
type
expert
hat
on
sometimes
experts
need
help.
So
I
don't
mind
considering
the
question
of
registration
procedure.
That
is
fine.
A
possible
tweak
on
it
might
be
specification
required,
as
in
expert
review.
E
Coming
back
to
the
question
about
document
adoption,
I
think
we
should
it's
quite
clear.
There
are
lots
of
open
issues
and
things
that
are
not.
You
know
yet
to
be
resolved,
but
I
think
well,
martin
did
better
job
than
any
anybody
else
of
us,
so
he
has
a
document,
so
I
think
we
should
adopt
it.
Let's
see
one
more
random
comment
about
possible
criteria
for
the
top
level
media
types
might
be.
E
If
all
subtypes
have
a
shared
property
or
restriction-
and
I
actually
can
give
examples
like
for
text
for
all
text-
media
types-
they
all
have
to
be
crlf,
each
line
is
here
left.
So
if
your
chair,
certain
coding,
doesn't
allow
for
that,
it
cannot
be
text.
Media
type,
that's
a
restriction
that
is
common
for
all
of
them.
Take
start
here.
E
I
think
it
still
applies
to
that.
The
like
the
thunderbird
used
to
to
support
utf-16
variants
for
text,
and
I
think
they
took
it
out,
because
probably
they
were
told
that
you
cannot
do
that.
A
I'm
closing
the
queue
after
after
alex.
I
finished.
E
But
finishes
by
the
way
and
similar,
like
multipart,
has
certain
restrictions
about
what
can
be
inside
it,
how
it's
formatted
so
again,
if,
if
there
is
a
set
of
related
things,
they
have
common
properties
or
common
restrictions
that
might
be
a
criteria
for
top
level.
E
F
So,
yes,
we
should
have
dropped
the
draft.
The
principle
that
I
think
that
we
need
to
adopt
here
is
permissionless
innovation,
so
that
anybody
can
get
access
to
register
any
media
type
without
having
to
kiss
rings.
F
G
I'm
speaking
with
my
non-existent
hack
as
the
author
of
as
co-author
of
one
of
the
relevant
documents
here,
it's
been
cleared
in
discussions
and
other
topics
in
the
last
few
weeks
that
that
probably
there
is
a
problem
with
the
standards
track,
categorization
and
and
and
the
next
step
there,
which
is
that
putting
requiring
something
beyond
standards
track
actually
involves
two
separate
things.
G
One
of
them
is
that
the
isg,
after
listening
to
the
type
of
viewers
and
and
waving
its
hands
and
running
a
last
call,
which
often
gets
no
response
order
having
blessed
something,
but
the
other
is
that
it
provides
an
opportunity
for
community
input
and
responsibility,
input
and
discussion.
G
The
media
type
reviewers
are
wonderful
people,
they
have
done
a
great
job,
but
they
are
not
experts
in
all
possible
fields
which
might
be
covered
by
top
level
types
and
forcing
the
opportunity
for
a
community
discussion
on
those
things,
if
only
to
inform
them,
but
under
the
current
procedures.
There's
no
way
to
do
that,
so
it's
informed
the
isg
is,
is
actually
a
valuable
contribution
to
this
process.
G
So
until
and
unless
we
revise
the
categories
of
approval
for
for
top
level
categories,
approval
for
any
iana
register
we're
better
off
leading
the
top
level
types
as
as
standards
track,
even
if
the
ia,
even
if
the
isbx
is
a
little
bit
pro-forma
thanks.
H
I
also
support
standards
track
for
most
of
the
reasons,
given,
I
think
john
said
more
elegantly
than
what
I
was
about
to
say,
which
is
as
a
media
type
reviewer
for
something
big
like
this,
I
would
prefer
the
air
cover
of
you
know,
making
sure
that
I'm
not
making
a
mistake
by
approving
a
top
level
type.
So
I
and
I
also
support
adoption
of
the
document.
Thank
you,
martin,
for
putting
it
together.
A
Oh
drop
out
so
I'm
hearing
consensus
for
adopting
the
document,
I'm
hearing
a
strong
propo
preponderance
of
speakers
who
are
in
favor
of
using
standards
track
for
as
a
getting
criterion
for
new
tuple
types,
and
I
don't
think,
there's
any
reason
to
run
a
poll
on
this.
We
should
confirm
it
on
the
list,
but
let's
do
let.
Let's
assume
that
let's.
A
We
have
now
the
driving
example
of
muthusami's
haptics
drafts,
the
first
candidate
to
be
processed
on
the
process.
We
decided.
A
I
A
I
A
I
Thanks
harold
good
morning,
good
afternoon,
good
evening,
everybody,
my
name
is
yeshwanth
muthusami.
I
So
what
has
happened
since
the
last
time?
I
I
was
since
the
time
that
I
uploaded
version
zero
zero
of
the
media
man
draft
for
haptics
in
mpeg,
the
iso
bmf's
seventh
edition-
was
approved
and
and
published
in
january
of
2022,
and
that
is
significant
because
in
that
we
specify
haptic
tracks
as
a
top-level
media
track
at
the
same
level
as
audio
and
video
and
in
mpeg
the
haptics
phase.
One
codex
standard
is
making
good
progress
towards
his
first
ballot,
which
is
expected
in
in
october,
of
of
2022.
I
in
mpegi,
which
is
in
immersive
media
scene
description.
The
haptics
phase,
two
use
cases
and
requirements
have
been
approved.
I
These
are
those
which
pertain
to
xr
and
avatars,
and
interactivity
and
work
is
underway
to
define
the
three
haptics
related
extensions
to
gltf,
which
is
a
framework
used
in
scene
description,
just
an
update
on
what
has
happened
since
I
uploaded
the
medium
and
haptics
draft
and
in
ietf
itself,
thanks
to
martin,
we
just
went
through
the
top
level
draft
and
from
our
reading
we
believe
that
the
haptics
in
internet
draft
does
indeed
satisfy
all
the
all
the
criterion,
all
the
criteria
that
were
listed
in
in
section
three
and
in
the
in
the
rest
of
this
presentation,
I'm
going
to
be
going
into
a
little
bit
deeper
into
how
the
draft
that
does
do
that.
I
So
with
that
just
a
quick
recap
of
the
basics.
Since
I
haven't
seen
much
traffic
on
the
haptics
draft
on
the
media
types
list,
it
haptics
refers
to
the
generation
of
touch
related,
sensations
in
a
device
or
interface.
It's
widely
used
in
a
variety
of
consumer
devices
to
provide
touch
feedback
and
the
haptic
technologies
require
some
form
of
activation
to
create
a
tactile
sensation
in
smaller
devices
like
mobile
phones
or
controllers.
These
are
typically
small
vibrating
motors.
I
If
you
go
to
large
automotive
touch
screens
the
actuators
as
specialized
pso,
electric
materials
and
haptic
capabilities
are
now
part
of
every
modern,
smartphone
gaming
and
vr
controller,
the
most
pro
prominent
of
which
is
the
sony
ps5
dual
sense:
controller.
Okay,
so
going
right
down
into
the
the
the
criteria
that
martin
had
had
listed.
So
I
had
I
I
I
list
each
criteria
and
the
parts
in
blue
is
our
response
or
our
understanding
of
how
the
haptics
internet
draft
does
indeed
meet
those
meet
that
criterion.
I
So
the
two
new
new
top
level
types
are
rare
enough
and
different
enough
that
each
application
needs
to
be
well
evaluated
separately.
We
believe
that
the
haptic
structure
top
level
type
is
unlike
any
of
the
top
level
types
that
are
currently
currently
recognized
by
ietf,
and
it
does.
It
is
different
enough
to
to
merit
top
level
status
for
all
the
reasons
that
we
mention
in
our
draft,
and
it
needs
to
be
documented
in
a
standard
track
rfc,
and
that
is
indeed
the
intended
status
of
our
draft.
I
It
should
include
initial
registrations
of
the
actual
types
as
soon
as
our
draft
is
approved.
We
do
plan
to.
It
will
be
blue
plan
to
register
the
actual
types
which
are
currently
defined
in
the
in
the
draft
and
may
or
may
not
need
a
working
group.
Well,
we
are
talking
about
it
right
now
in
this
working
group,
so
the
existence
of
a
certain
number
of
subtypes
would
be
grouped
under
the
new
top
level
type
at
a
minimum.
I
At
least
one
success,
subtype
should
exist,
but
the
existence
of
one
test
subtype,
is
not
enough.
We
none
of
these
subtypes
that
you
see
here
have
actually
been
been
registered.
Yet
I
just
want
to
make
that
clear,
but
they
have
been
described
in
the
in
section
in
in
section
2.5
of
the
haptics
draft.
For
example,
we
talk
about
these
potential
subtypes,
which
are
actually
very
widely
in
use.
Right
now,
for
example,
a
hap
is
the
standard
encoding
on
all
ios
devices
and
ios
connected
game.
I
Peripherals
org
is
a
proprietary
extension
to
the
arc
format
to
store
haptic
media
that
made
its
debut
in
android.
11.
ibs
is
an
xml-based
vendor-specific
for
format.
That's
used
in
many
mobile
phones
from
lg
and
gaming
phones
from
asus
and
hacked
is
also
a
vendor-specific
format,
that's
using
mobile
haptic
advertising
and
certain
japanese
games.
In
addition,
in
section
2.6
of
our
draft,
we
we
envision
in
a
number
of
haptic
subtypes
as
part
of
the
various
haptic
standards
which
are
in
various
10
various
stages
of
standardization,
the
hmpg,
which
would
be
the
mpeg
haptics
phase.
I
One
coca-cola
standard,
which
is
which
I,
as
I
mentioned,
is
likely
to
go
into
see
into
cd
ballot
in
october
of
this
year,
the
h-I-e-e,
which
is
the
ieee
p1918.1.1
vipro,
tactile
coco
coding
standard,
that
is,
that
is
currently
under
ieee
sa
by
ballot
and
then
the
last
two
are
are
subtypes
that
we
are
planning
to
register
which
is
based
on
in
in
numerated
effects,
haptic
coding
format,
that's
based
on
midi
and
the
audio
to
vibe,
haptic
coding
format.
So
there
are
a
number
of
existing
haptic
subtypes
which
can
be
registered
under
this
new
type.
I
I
No
undefined
top-level
haptic
types
are
are
currently
in
use
as
far
as
as
far
as
we
can
tell
top
level
types
mostly
help
humans.
It
is
unclear
to
what
extent
level
types
can
be
used
by
applications
as
used
and
and
therefore
evaluating
how
a
new,
not
top
level
type
helps
humans.
Understand
types
may
be
crucial.
I
I
All
right,
I'm
almost
done
here,
so
need
for
clear
criteria
for
what
types
do
and
don't
fall
under
the
new
top
level
type,
any
subtype
that
deals
with
one
of
the
haptic
submodalities
which
which,
which
are
described
in
the
draft,
which
is
vibrotactile
kinesthetic
spatial
surface
of
the
thermal
haptics,
is
a
clear
candidate
for
inclusion
under
the
haptic
top
level
type.
I
As
far
as
the
desirability
for
common
parameters
is
concerned,
all
data
formats
which
are
in
the
haptics
id
which
put
into
the
sense
of
touch,
would
need
to
be
under
the
proposed
tactics,
top
level
type
and
another
feature
that
is
common
to
all
of
these
haptic
subtypes
is
that
they
all
would
require
a
haptic
subsystem,
such
as
low
level
haptics
apis,
which
in
turn
would
require
hardware
capabilities,
such
as
one
or
more
actuators
in
the
device,
as
I
mentioned
earlier,
to
actually
render
the
haptics
media.
I
I
If
you
notice
on
the
slides,
I
have
a
whole
bunch
of
backup
slides,
which
are
meant
for
the
audience
to
go
through
or
go
over
on
their
own
time,
but
I
included
them
because
of
the
relative,
no
level
type
and
but
I'm
happy
to
take
any
questions
at
this
point.
D
D
I
F
Yeah,
taking
a
point
that
john
made
in
the
last
discussion
and
applying
it
here,
it
occurs
to
me
that
one
of
the
very
useful
areas
for
having
reasons
for
having
different
top
level
types
is
going
to
be.
F
The
ads
may
want
to
assign
different
experts
according
to
top
level
type,
and
that
is
likely
to
be
exceptionally
useful
in
a
case
like
this,
where
you've
got,
you
know,
the
whole
haptic
field
is
going
to
be
something
that
needs
quite
a
bit
of
expertise.
F
F
H
Just
responding
to
martin
quickly,
I
think
we
have
an
advantageous
situation
here
where
we're
defining
both
the
the
standards
track
document,
that's
going
to
explain
how
you
create
a
top
level
type
and
then
a
first
case
coming
along
with
it
developing
them
in
parallel
and
shipping
them
both
to
the
isg
at
the
same
time
is
perfectly
fine,
and
I
think
that
I
think
the
two
moving
the
two
of
them
together
is
going
to
work
pretty
well.
A
G
Yeah,
I
I
want
to
be
careful
that
we
don't
invent
too
much
procedure
here,
because
it
just
gets
in
the
way
it
slows
things
down
so
so
two
observations,
one
of
which
is
that
we'd
have
to
ask
the
current
set
of
reviewers,
but
my
guess
is
based
upon
when
I
was
actually
actually
involved
in
the
reviewer
process
that
that
decisions
who
gets
to
review
which
application
are
partially
based
on.
G
Who
knows
something
about
it
and
and
if
that's
not
true,
we
could
go
off
and
formalize
it,
but
I
don't
think
would
accomplish
anything.
G
It
does
imply
something
which
has
gotten
involved
in
the
pre-working
group
haptics
discussion
and
is
consistent
with
what
phil
said,
which
is
that,
implicitly,
the
requirement
for
a
new
top
level
type?
Is
we
figure
out
who
reviews
it
and
and
if
that
means
tuning
the
reviewer
process?
That's
fine!
If
that
means
that
we
may
have
to
add
a
review
of
each
top
level
type,
that's
fine,
but
I
don't
know
that
we
need
to
tie
ourselves
up
and
do
procedures
for
this.
Or
maybe
we
do
thanks.
A
Thanks,
I
think
I
think
that
the
the
problem
of
whether
or
not
to
allow
for
multiple
reviews
actually
comes
back
to
the
top
level
type
discussion
and
no,
actually
it
doesn't
it.
It
comes
to
a
lit
another
point,
which
is
the
possible
redesign
of
the
registration
procedures
for
subtypes,
because,
after
all,
reviewers
is
part
of
the
subtype
okay.
I
think
we
have.
A
I
think
we
have
exhausted
this
topic
for
the
moment
and
we
seem
to
have
found
no
new
reasons
why
this?
Why
haptics
is
a
bad
idea
so
and
some
some
compelling
arguments
for
why
it's
a
good
idea,
so
we'll
just
have
to
wait
a
little
bit
until
we
get
the
rest
of
the
stuff
fixed
up,
so
that
we
can
actually
move
those
documents
forward.
K
Wonderful,
hello,
everyone,
my
name
is
manu
sporney,
I'm
the
editor
of
a
couple
of
specifications
over
at
the
w3c,
jason,
ld,
decentralized,
identifiers
and
verifiable
credentials,
and
that
work
kind
of
spawned
the
need
for
the
media.
Man
suffixes
work
really
quickly
going
to
cover
today
some
of
the
goals
for
mediaman
suffixes
the
changes
made
since
the
last
time.
We
met
some
topics
of
concern
that
have
come
up
in
the
past
a
couple
of
months
since
december
and
then
see
what
the
group
feels
are
the
appropriate
next
steps.
K
Next
slide,
please,
okay!
So
what
are
the
goals
here?
We're
trying
to
establish
how
multiple
media
type
suffixes
should
be
processed?
So
if
you
get
a,
if
you
get
a
message
with
a
media
type
with
multiple
suffixes,
what
should
you
be
able
to
do
with
that?
So
this
you
know,
question
was
brought
up
by
media
types
like
image,
slash,
svg,
plus
xml,
plus
gzip
in
application,
slash
did
plus
ld
plus
json
anything
that
has
multiple
plus
signs
in
it.
K
When
we
went
to
register
these
media
types,
the
ones
with
multiple
plus
signs,
the
registration
folks
processing,
the
registration
were
like
well.
What
exactly
does
that
mean
right?
So
that's
what
we're
trying
to
answer
with
this
document
we're
trying
to
establish
registration
policies
for
media
types
with
multiple
suffixes.
K
That's
the
that's
the
problem
that
the
verifiable
credentials
working
group
at
w3c
hit
when
they
tried
to
register-
or
they
were
thinking
of
registering
you
know
their
media
type
with
multiple
plus
signs
same
thing
with
the
decentralized
identifier
working
group
in
in
it
looks
like
we're
we're
just
getting
more
media
types
that
have
multiple
suffixes
in
them.
K
We
also
want
to
provide
some
security
considerations
when,
when
processing
media
types
with
multiple
suffixes
and
I'll
get
into
that
here
in
a
bit,
but
these
are,
I
think,
the
the
high
level
goals
that
I
heard
the
working
group
said
that
they
were
interested
in
establishing
in
this
draft
next
slide,
please,
okay!
So
what
changes
have
we
made
since
the
last
time
you
met
the
old
processing
model
in
the
draft
that
was
submitted
to
the
working
group
was
just
broken.
K
It
worked
for
things
in
application,
slash,
but
it
did
not
work
for
image,
slash,
svg,
plus
xml,
plus
gzip,
so
the
pros
has
been
rewritten.
We've
added
a
few
examples
to
demonstrate
what
the
how
you
should
think
about:
processing
media
types,
multiple
suffixes
and
the
new
pros.
Basically,
I
believe,
works
with
all
of
the
media
types.
K
Third
change
that
was
made
is
there
was
a
structured,
syntaxes,
suffixes
registry.
This
is
not
my
area
of
expertise
and
I
had
no
idea
that
registry
existed,
but
the
fact
that
that
registry
exists
is
really
useful
and
that
the
existence
of
that
registry
and
using
it
to
do
processing
has
been
included
in
the
the
latest
draft
and
finally,
a
security
consideration.
Section
has
been
added
because
there's
at
least
one
attack
that
we've
identified
that
people
need
to
be
aware
of
when
they
build
tooling
that
processes
media
types,
multiple
suffixes
next
slide.
Please.
K
K
There
still
hasn't
been
enough
review
and
I'm
struggling
to
figure
out
how
to
get
that
review.
I
know
that
people
have
said
things
in
the
past
and
they
haven't
spoken
up
recently,
so
I'm
thinking
of
just
like
trying
to
get
them
on
the
phone
and
talking
through
the
draft
with
them.
I
think
it'd
be
good
to
engage
folks
like
ned,
because
he
did
write
the
multiple
suffixes
registry
thing.
K
I
don't
think
he's
provided
feedback
yet
you
know
other
people
have
done
reviews,
so
thank
you
to
murray
and
and
others
that
have
provided
input,
but
but
I'm
wondering
if
we
should
be
more
targeted
and
I
should
just
go
after
people
that
should
have
opinions
about
this
people
that
have
written
drafts
in
in
this
particular
orbit.
K
K
There's
a
link
to
the
new
processing
model
from
the
slides
there
and
then
finally,
there's
this
new
security
consideration
section
one
of
the
one
of
the
things
people
were
concerned
about
was
this
concept
of
what
happens
if
someone
sending
you,
the
media
type,
lies
to
you
on
purpose,
to
try
and
trick
your
tool
chain
into
doing
something:
weird
like
bypassing
some
kind
of
security
scanning
process
by
un-g-zipping,
something
and
then
sending
the
resulting
value
directly
to
an
application,
instead
of
sending
it
through
like
a
a
virus
checker
or
something
like
that,
I'm
grasping
at
straws
for
that
attack,
but
I'm
trying
to
establish
that
people
need
to
think
about
that
harold.
K
You
also
raised
another,
I
think,
maybe
another
attack
in
an
email,
but
when
I
went
to
write
it
up,
I
got
confused
about
whether
or
not
you
were
talking
about
the
media
type
fibbing
attack
or
if
there
was
another
one.
So
I'd
appreciate
some
feedback
on
other
security
considerations.
Other
ways
that
that
things
can
go
wrong
with
processing,
multiple
suffixes,
okay,
so
those
are
the
topics
of
concern-
would
appreciate
some
feedback
on
each
one
of
those
items
during
discussion.
Next
slide.
K
Okay,
so
what
are
the
next
steps
concrete
things
I'd
like
to
maybe
interview,
ned
and
murray
I'd,
like
some
feedback
from
you
and
clearly
anyone
else.
Martin
would
appreciate
some
feedback
if
you
have
any-
and
I
know
that
mark
nottingham
said
at
one
point-
he
thought
the
spec
was
a
bad
idea,
and
so
I'd
like
to
chase
him
down
and
see
if
he
still
thinks
that,
then
you
know
revise
the
spec
based
on
that
and
then
I'm
wondering
about
a
finalization
timeline.
K
There's
there's
no
real
rush,
but
there
are
multiple
w3c
working
groups
that
are
just
in
a
holding
pattern.
Right
now,
in
fact,
the
working
groups
have
shut
down
and
they're
just
like.
Well,
I
guess
we'll
register
the
media
type
whenever
the
multiple
suffix
thing
is
is
handled,
so
we've
got
at
least
three
different
specs
there
that
are
waiting
to
register
their
their
media
types
on
the
spec,
and
it
would
be
good
to
kind
of
understand
where
the
group
feels
we
are
on.
You
know
finalization.
A
A
The
other
thing
I
was
thinking
of
when
reading
through
your
security
section
is
that
it
needs
to
say
explicitly
that
when
you're
doing
unpacking
you
do
you
have
to
consider
security
for
all
the
thing.
The
levels,
for
instance,
there's
a
well-known
attack
on
gzip,
which
called
gz
bomb,
where
you
just
provide
certain
primitives
in
gzip
that
expand
to
a
file
of
a
near
infinite
size,
and
if
you
just
blindly
unpack
anything
without
proper
guard
guards
against
such
things,
then
you
will
be
sorry.
A
G
It's
also
true
whether
you
classified
a
security
problem
or
not
that
sometimes
lying
on
media
types
is
is,
is
a
problem
as
well
and
and
occurs
inadvertently,
but
is
no
less
disruptive
and
and
if
people
need
examples
of
that,
contact
me
offline
and
I
will
send
you
an
appropriate
message,
but
the
other
observation
is
and-
and
I
don't
know
if
there's
anything
useful
to
be
said
about
it
now
or
done
with
it
now,
but
back
at
the
dawn
of
time
when,
when
rfc
1590
was
written.
G
My
recollection
is
that
we
had
a
brief
discussion
about
structured
subtypes
and
we
came
to
the
conclusion.
The
right
solution
was
parameters
and
not
structured
subtypes,
because
structured
subtypes
led
to
precisely
the
slippery
slope.
G
Confusion
multiple
suffixes
example
which
was
given
to
be
in
this
talk,
and
I
don't
know
how
much
further
we
want
to
go
down
this
path.
This
is
a
problem
that
we
failed
to
deal
with
at
the
time
the
media
types
became
a
male
and
weapons.
G
Maybe
other
things
thing
rather
than
a
male
thing,
a
process
we
didn't
bring
the
parameter
stuff
over,
but
but
my
concern
is
that
we're
we're
moving
down
a
path
as
we
go
from
one
suffix
to
multiple
suffixes
and
possibly
questions
about
which
suffixes
are
more
important
than
which
other
suffixes
in
which
we
really
dig
ourselves
into
a
whole
and
then
and
then
reach
out
for
a
bigger
shovel,
and
I
don't
know
the
solution.
D
D
D
A
So
we
have
thank
you,
so
we
have
four
minutes
left
on
there
on
agenda.
So
we'll
just
have
to
say.
A
Of
what
needs
to
be
registered
in
order
to
do
this
multi-level
processing
is
a
very
key
one
we
might
have.
We
might
decide
that
we
have
to
register
all
legal
combinations,
so
we
might
have
to
decide
that
we
have
to
register
only
the
suffixes
and
say
nothing
about
which
they,
which
types
they
can
be
used
to
it
or
it
might
come
down
on
some
alternative.
I
mean
is
text,
slash,
plain
plus
gzip
legal
mind
type.
A
A
D
E
Alexa
yeah
alexi
not
sure
about
the
whole
reopening
thing
that
might
be
a
bit
process
heavy,
but
as
far
as
mag
types
is
concerned,
I
kind
of
tend
to
defer
completely
to
net
on
this
because
he's
a
mac
user.
He
has
more.
E
I
wouldn't
like
to
take
it
out
until
he
comments-
and
I
know
at
the
moment
he's
not
available
so.
L
L
I
think
is
no
new
thing,
but
I
think
there
may
still
be
legacy
support
for
the
old
mac
types,
but
it's
legacy
support.
It's
certainly
not
used
underneath.
So
I
don't
think
there's
any
point
in
having
them
on
the
form.
We
could
leave
a
space
for
notes,
and
you
know
people
can
include
that
information
if
for
legacy
purposes,
they
think
they
need
to,
but
I
don't
think
it
should
be
a
requirement
of
the
form
anymore.
L
Right
and
barry
said
he
thinks
they're
gone
with
os
10
and
it's
been
out
for
so
many
years.
I
believe
in
the
original
go
around
of
os
10.
They
still
existed
underneath,
but
all
of
the
operating
system
stuff
uses
the
file
extensions
now
and
not
those
underneath
things.
So
I
I
like,
I
said
I
think
it's
perfectly
reasonable
to
deprecate
and
put
it
in
notes,
someplace
in
the
form.