►
From YouTube: IETF112-MEDIAMAN-20211109-1430
Description
MEDIAMAN meeting session at IETF112
2021/11/09 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
A
A
So
it's
it's
a
bit
like
speaking
into
the
void
when
you
do
this,
but
anyway
we're
at
the
at
the
itf
we're
at
the
working
group
meeting.
We
have
a
working
group,
it's
called
mediaman.
We
have
an
hour,
and
the
first
thing
to
do
is
always
note.
Well,
we
all
seen
it
before.
A
A
A
And
I
do
see
this
hedgehog
thing
that
I
have
never
seen
before.
A
A
A
A
A
And
broke
them
out
into
rc
2048
and
revised
them
a
couple
of
times,
and
if
you
read
them
from
a
sociological
viewpoint
and
not
from
a
not
strictly
as
a
technical
viewpoint,
you
will
see
that
we
have
many
made
many
attempts
at
directing
how
media
types
should
be
used,
what
the
principles
are
and
what
and
what
people
should
do
and
register
them.
And
well.
A
A
A
A
A
Why
should
I
work
here
and
we
added
font
in
2017,
which
was
kind
of
well?
Someone
was
already
using
it,
so
we
should
just
admit
it.
This
comes
by
so
new
top
level
types
are
rare.
I
mean
we
go
10
years
without
adding
one
easily,
but
it's
still
unclear
why
we
add
them
and
it
still
don't
care
how
we
measure
whether
it
was
good
or
not.
A
A
C
This
is
more
a
question
actually
for
you,
harold
or
anyone
who
has
those
experiences
a
long
time
is.
It
seems
to
me
that,
in
the
way
these
are
actually
used
that
you
could
actually
remove
the
top
level
type
and
it
would
make
absolutely
no
difference
to
anything
like
it's
not
like
the
con.
It's
not
like
the
subtypes
ever
managed
to
conflict
that
we
had
a
like
two
subtypes
that
had
the
same
different
top
levels.
C
I
understand
how
people
use
the
subtypes
yeah
sure
you
want
to
know
it's
an
image
jpeg,
but
you
know
as
long
as
we
don't
ever,
you
know
name
an
audio
format
jpeg
I
I
I
don't
know
so.
This
just
comes
back
to
like.
A
A
Because
so
we
have.
C
A
A
D
Sorry,
there
is
one
case
in
which
the
top
level
type
is
actually
used,
and
it's
inside
the
web
browser
in
that
there's
a
content
negotiation
scheme
in
there,
and
so
it
does
actually
make
sense
to
negotiate
between.
D
You
know.
I've
got
this
image
in
three
different
formats.
You
can
have
it
in
jpeg,
png
or
gif,
and
so,
if
it
is
used
anywhere
at
all,
that
is
where
the
top
level
thing
is
used,
and
not
necessarily
in
the
browser,
it's
possible
that
it
is
used
in
the
servers
and
the
platforms
underlying.
D
E
I
pro
I
probably
could,
but
that's
not
what
I
came
to
talk
about
here
today.
What
I
was
actually
going
to
ask
is
I
yeah
I
mean
I
think.
E
Well,
I'm
just
if
you
do
want
to
ask,
but
the
rtp
thing
was
kind
of
far
as
I
know
a
hack,
which
is
that
somebody
noticed
that
the
me,
the
m-line
formats,
that
stp
was
using
where
this
mat
happened
to
match
the
the
media
types
they
were
using
for
mime
and
said:
oh
hey,
we
should
make
these
the
same
thing,
which
I'm
not
positive,
was
a
good
idea,
but
because
the
packetization
for
file
formats
and
packetization
for
rdp
encoding
are
really
not
the
same
thing
at
all.
E
E
Various
content,
inspection
tools
are
more
paranoid
about
things,
labeled
application
slack.
They
are
about
other
types,
even
if
they're
unknown
pipes
that
they
think
oh.
This
is
something
that
could
be
active
content.
I'm
going
to
reject
that
or
if
it
is
not,
you
know,
application
slash,
I'm
gonna
be
more.
You
know
tolerant
out,
because
it's
probably
something
that's
safe.
That's
all
the
people
wanted
font
flash
rather
than
applications
whatever.
Is
that
true?
Or
was
that
me
misunderstanding
or
misinformation
at
the
time
or
rumor?
Or
what
did
anybody
know.
C
I
know
it's
probably
a
little
slight
answer
that
I
think
that,
whatever
I
mean,
I
know
firewalls
content
protection
systems
used
to
look
at
that
long
ago.
I'm
not
sure
they've
like
had
very
intelligent
things
to
do
with
it.
They
probably
checked
that
if
you
pretended
a
jpeg
was
audio
that
nice
vice
versa,
but
I
mean
I,
the
type
of
firewall
is
pretty
much
gone
at
this
point
I
mean
I
only
know
who
makes
them
anymore.
So
I,
if
it
was,
you
know,
I
suspect
that
information
is
becoming
rapidly,
not
true.
A
There
was
a
series
of
hacks
that
were
that
involved,
sending
something
with
a
with
a
particular
media
type
or
file
name
suffix,
and
then
having
the
content,
be
content
sniffed
by
a
dispatcher
which
would
then
happily
dispatch
it
to
something
that
was
completely
different
from
the
content
type,
and
so
I
mean
insecure.
Insecures
want
to
be
insecure,
phil.
A
F
Yeah,
just
repeating
something
that
was
mentioned
on
chat
by
madden
myself,
is
that
top
level
type
is
used
in
among
other
systems.
You
know
in
ml
systems
deciding
top
level
processing
for
certain
groups
of
things
so
yeah,
I
don't
think
eliminating.
It
is
going
to
be
useful
at
this
point
we
can
decide.
We
don't
want
to
create
more
categories,
that
that
would
be
a
fair
discussion,
but
I
think,
removing
and
making
everything
being
equally
registerable
under
any
top-level
media
type.
That
would
not
be
a
good
thing,
probably.
A
Yeah,
so
I
think
that
we're
more
more
or
less
saying
that
we
like
we
have
like
top
level
types
before,
because
they're
pretty
and-
and
nobody
really
cares,
what
the
top
level
type
is
that
they
care
about
the
whole
string,
or
at
least
that's
what
they
should
be
doing.
E
E
It
doesn't
know
about
it'll
just
say
this
is
the
create
this
like,
like
a
you
know
like
everything
else,
so
I
guess
my
question
is:
if
we
don't
care
about
top
level
types,
it
seems
like
the
two
choices
we
could
make
were
never
having
top
level
types
or
sure
everyone
could
have
a
top
level
type.
You
know
register
google
slash
if
you
want,
so
I
think
email
or
maybe
not
quite
that
free
form,
but
you
know
something
a
pretty
open,
iana
registry.
E
A
C
Okay,
I
just
wanna.
I
I'm
not
saying
this
changes.
Any
conclusion
we
do
on
this,
but
like
the
the
multi-part
thing,
is
that
the
top
level
doesn't
matter
it's
the
multi-part
mix,
multi-part
parallel
those
matter
I
mean
the
thing
has
to
understand
the
sub-level:
it's
not
the
top
level
that
matters
in
email.
Yes,
the
top
level.
It
checks
the
string
because
it
expects
the
string
to
be
there,
but
if
that
it
doesn't
really
need
it
in
any
way,
because
it's
not
like
it
deals
completely.
C
If
it
it
sees
a
second
level
after
multipart,
it
doesn't
understand,
there's
nothing,
it
can
do
with
it
right.
It
might
right,
and
similarly,
with
scanning
email
and
everything
you
have
to
understand
the
subtype,
it's
all
the
subtype,
that's
being
understood,
not
you
know.
As
long
as
the
subtypes
didn't
conflict,
I,
the
top
level,
doesn't
actually
do
anything
for
any
email
scanner
or
firewall
scanner.
I've
ever
seen
so
because
they
have
to
understand
the
subtype
to
be
able
to
do
anything
with
it.
C
So
I
mean,
I
think,
if
we're
going
to
design
something
here,
that's
going
to
be
good
or
we're
going
to
argue
strongly.
There's
a
strong
design
constraint
somewhere
another
we
would
have
to
just
find
a
use
case
that
really
required
you
to
understand
the
top
level,
but
be
able
to
totally
ignore
those
sub
levels.
Underneath
of
that-
and
I
I
no
one's
brought
one
up
here,
so
I
think
that
makes
a
strong
argument.
This
doesn't
matter
much
one
way
or
another
whatever
we
do
thanks.
F
Yes,
it's
a
response.
Actually,
both
ned
and
myself
are
screaming.
That's
not
correct.
I
I
can
handle
any
multi-part
slash
full
in
my
webml
client,
just
fine
without
knowing
what
it
is,
and
this
is
handled
by
knowing
it's
a
multi-part
slash.
So
there
aren't
many
that
many
examples
of
things
like
this,
but
there
are
examples.
A
A
H
Okay,
I
thought
I
would
start
off
with
a
quick
introduction.
So
haptics
refers
to
the
generation
of
touch
related
sensations.
It
is
used
in
a
wide
range
of
consumer
devices.
Mobile
devices,
automobiles
gaming
and
haptic
technologies
requires
some
kind
of
actuation
to
actually
create
the
tactile
sensation
in
game
controllers
and
mobile
devices.
That's
typically
a
small
vibrating
motor
of
some
kind,
the
haptic
actuator
in
large
automotive
touchscreens.
These
these
are
specialized
piezo.
Electric
materials.
H
Haptic
capabilities
are
now
pretty
commonplace
in
every
modern
smartphone
game.
Vr
controllers
the
latest
and
the
the
best
example
is
a
sony,
ps5,
dual
sense
controller
and
pretty
much
all
of
the
late
model,
iphones
and
android
types
and
the
version
two
of
the
internet
draft
that
proposes
haptics
as
a
top-level
media
type,
was
uploaded
in
may
of
this
year.
Next
slide,
please!
H
So
what
has
happened
since
version
two
was
uploaded.
I
thought
it
was
important
to
mention
the
latest
developments
in
that
area.
The
iso
based
media
file
format,
seventh
edition,
which
is
iso
14496,
has
been
approved
and
is
listed
under
under
publication,
and
it's
a
due
out
on
the
3rd
of
december,
and
this
is
significant
because
it
contains
our
proposal
that
we
made
back
in
april
of
2020
that
specifies
haptics
as
a
top
level
media
track
in
an
iso
bmf
file
at
the
same
level
as
audio
and
video.
H
H
Somewhat
in
other
areas
of
mpeg,
we
have
a
the
phase.
One
cfp
has
been
completed.
Four
four
four
proponents
provided
there
that
that
their
codex
three
of
them
have
been
chosen
as
their
reference
model
zero,
and
they
are
progressing
to
the
next
stage
of
the
standardization
and
in
mpegai,
which
is
a
immersive
media
portion
of
mpeg,
haptic,
use
cases
and
requirements.
H
H
As
I
just
mentioned,
the
user
experience
and
enjoyment
of
media
content
can
be
significantly
enhanced
by
adding
haptics
to
audio
video
content
in
the
iso,
bmf
files
in
media
streams
and
streaming
games
and
mobile
advertising,
and
here
I
want
to
respond
to
a
question
I
got
already
this
morning
and
yes,
haptics
won't
just
be
in
files,
but
they
will
also
be
part
of
of
rpp
streams
and
streaming
games
and
wearable
devices
and
xr
applications
is
where
we
see
haptics
being
used
in
as
part
of
rtp
streaming,
and
that,
and
also
the
next
success
section
here,
talks
about
how
the
the
the
mp4
files
would
be
would
look
like
once
the
haptic
stop
level
type
has
been
registered,
so
haptic,
slash,
mp4
would
be
mp4
files
with
just
haptic
tracks
in
them
and
for
the
sake
of
consistency,
video
mp4
would
would
stay
video
mp4
for
files
which
have
the
video
audio
and
haptics,
which
each
and
shows
consistency
with
existing
video
mp4
files,
and
the
same
goes
for
a
audio
audio,
slash,
mp4.
H
Okay,
I
can
move
on
to
the
next
slide.
Please.
H
Media
type
called
haptics,
placing
haptics
under
audio
or
video
or
application,
is
not
reflective
of
the
kinds
of
files
or
use
cases
that
we
would
like
that
would
need
haptics
and
have
nothing
to
do
whatsoever
with
audio
or
video
or
applications
move
to
the
next
slide.
Please
there
are
a
number
of
sub
modalities
of
haptics.
A
few
of
them
are
already
in
the
process
have
found
their
way
into
the
empaga
use
cases
and
and
and
requirements.
H
I
mean
you
have
vibro
tactile
haptics,
which
is
the
touch
vibration.
You
have
kinesthetic,
you
have
surface
haptics,
you
have
spatial
non-contact
haptics.
This
is
an
emerging
field
that
that
is
gaining
a
lot
of
traction
in
in
different
areas,
called
ultrasound
haptics
you
have
thermal,
haptics
and
and
so
having
haptics
as
a
top
level.
Media
type.
Would
enable
the
definition
of
the
data
formats
pertaining
to
these
sub
modalities
in
a
more
streamlined
manner?
H
H
H
In
android,
11
google
introduced
a
proprietary
extension
to
the
rf
format,
specifically
for
haptic
media,
and
there
is
the
high
ibs
for
format
which
is
used
in
a
number
of
mobile
phones
in
asia,
from
lg
and
asus,
and
then
the
hacked
for
format
has
also
found
use
among
the
number
of
game
developers
around
the
world
and,
more
importantly,
we
envision
the
following
standardized
haptic
coding
for
formats
that
we
expect
expect
to
be
registered
too
soon
and
they
would
live
as
such.
H
A
subtypes
under
haptics
one
is
the
hmpeg
which,
which
would
be
the
outcome
of
the
impact,
call
for
proposals
that
I
was
just
talking
about
and
h.
I,
which
is
ieee
p1918.1.1
coding
standard
that
is
currently
under
ballot
in
ieee
and
will
probably
be
out
much
sooner
than
the
tech
you
can
move
on
to
the
next
slide,
please
so
this
is
actually.
I
think
my
last
last
slide
here.
H
We
believe,
based
on
the
arguments
I've
made
so
far,
that
haptics
doesn't
really
belong
under
any
other
media
type,
and
the
main
reasons
just
to
reiterate,
haptics,
connects
to
a
sensory
system,
touch
motion
that
directly
and
is
more
specific
than
the
abstract
application.
Type
application
has
historically
been
used
for
applications.
That
is
code
means
that
is
viewed
and
treated
with
great
care
for
security,
for
viruses
with
the
and
other
active
code.
Haptics
is
not
code
in
much
the
same
way.
Audio
and
video
are
not
code
either.
H
Haptics
is
a
property
of
a
media
stream.
It
is
not
an
application
under
any
normal
definition.
As
such,
we
believe
it
should
be
its
own
type.
Next
slide,
I
believe,
would
be
the
thank
you
and
questions
so.
D
Hi,
I
I
seem
to
have
backed
the
queue
yeah.
I
was
going
to
say
the
summary
of
the
discussion
so
far
as
I
see
it
is
that
one,
the
use
of
top
level
names
don't
give
rise
to
any
critical
concern
that
we
need
to
be
particularly
concerned
about
and
number
two.
If
we
file
this
new
haptic
stuff
under
a
new
top
level
name,
it's
going
to
be
much
easier
going
forward
for
everybody
concerned,
because
this
is
not
going
to
be
the
definitive
haptics
format.
D
D
I
send
g-code
to
my
cnc
machines
and
that's
moving
around.
I
I
guess
I'm
up
just
to
clarify
what
phil
just
said.
You
said
the
use
of
top
level
names
does
not
give
rise
to
critical
concerns.
Does
that
mean
the
creation
of
new
ones,
or
are
you
speaking
retroactively
that
we're
fine
with
the
way
top
level
ones
have
worked
so
far?
I
just
wanted
to
clarify
what
you
mean
there.
D
Basically,
I'm
saying
that
the
discussion
that
we
had
the
first
time
was
not.
It
was
saying
we
didn't
find
any
dragons.
We
don't
need
to
worry
about
breaking
things
by
creating
a
new
top
level
domain
here,
there's
no
special
magic,
there's,
no
special
advantage,
there's
no
special
reason
not
to
so.
Let's
do
it.
A
Forgotten
no,
the
mp4
example
was
illustrative.
The
haptics
will
occur
in
files
that
have
previous
definitions,
because
they're
going
to
extend
their
definitions
to
allow
haptics,
so
registration
of
those
under
haptics
will
only
have
an
advantage
for
saying
that
this
is
stuff.
That
makes
sense
to
sense,
if
you
don't
have
audio
or
video
output,
but
just
have
haptics
outputs
yeah.
E
Yeah,
so
I
guess
two
points,
john
on
the
general
question
of
you
know
whether
I
said
this
in
the
java,
but
I'll
repeat
it
for
the
meeting.
You
know
the
question
of
you
know
whether
a
new
name
is
a
concern.
I'd
say
in
a
new
name:
it's
not
a
concern
for
any
types
which
would
otherwise
have
to
go
under
application.
E
So
I
think
you
know
I'm
not
going
to
say
a
new
double
type
you
know
for,
but
having
a
new
top-level
type
for
a
new
kind
of
multi-part
would
cause
havoc
having
a
new
top-level
type
for
haptics
is
absolutely
fine.
The
other
question
I
had,
which
is
related
to
the
issue
that
was
just
raised
with
mp4,
is
there's
kind
of
an
implicit
hierarchy
in
that
you
know
obviously
many
streams.
E
Many
formats
like
mp4
contain
more
than
one
type,
and
so
we
have
this
rule
that
if
it
only
has
audio
it's
audio,
if
it
has
audio
and
video
it's
video,
and
so
I
guess
haptics
have
the
same
property,
and
so
I
guess
I
think,
from
what
I
read
or
remember,
of
your
presentation
last
time.
Haptics
is
kind
of
the
bottom
of
that
hierarchy,
which
is
to
say
if
it's
only
haptics,
it's
haptics.
E
H
Yes,
I
mean
just
to
clarify
the
the
reason
we
have
it
that
that
way
is
because
haptics
is
the
newest
skill.
Is
the
newest
kid
on
the
block
and
we
don't
want
to
rock
the
boat,
and
so,
if
it's
all
audio
and
haptics,
then
you
probably
won't
want
to
keep
it
as
audio
slash
and
before.
But
if
it's
haptics
only
then
it
makes.
E
J
E
Yeah
so,
and
you
know,
and
then
so
yeah
I
think
you
know
we
want,
we
probably
explicitly
call
that
out,
but
you
know
in
this
you
know
I'm
not
sure
the
audio
and
video
was
that
explicitly
called
out
in
the
original
definitions
of
the
top
level
types
that
audio
and
video
is
video
or
would
edit
everybody
to
assume.
That
was
the
case.
H
E
E
Yeah
yeah,
that's
right
that
I
mean,
I
think
everybody
knew
it
works.
That
way,
I'm
just
wondering
how
explicitly
that
was
said.
So
I
think
we
want
to
explicitly
say
that
yes,
haptics
is
it's
you
only
put
under
haptics
if
it's
only
haptics,
if
it's
a
combined
thing,
you
put
it
under
the
rules
for
the
combined
thing
I
mean,
maybe
you
already
say
that
I'm
afraid
I
haven't
read
your
draft
and
I
apologize
yeah
so.
A
A
Whether
that's
the
property
of
mp4
or
it's,
a
property
of
of
the
the
top-level
domain
hierarchy.
A
J
So
I
put
this
into
chat,
so
I
think
in
one
of
jonathan's
comments
he
talked
about
you
know,
maybe
browsers
from
middle
boxes
or
whatever
take
image
formats
and
stick
them
into
say:
image,
tags
and
html
and
the
more
we
see
haptics
being
included
in
standards,
whether
it's
mpeg
or
other
things.
J
I
wonder
if
there's
some
chance
that
w3c
would
start
adding
haptics
tags
like
an
image
tag
and
if
so,
that's
another
reason
why
there's
an
actual
technical
benefit
to
having
a
haptics
as
a
top-level
domain
type
if
it
helps
creation
of
dynamic
html.
So
just
wondering
I
don't
know
if
that
will
ever
happen,
but
it
is
a
possible
thing
to
keep
in
mind.
H
Yeah,
actually
harold,
if
you
go
to
slide
13,
which
is
in
the
backup
slides,
I
actually
have
a
slide
on
the
w3c
haptics
work.
There
you
go
so
the
this
is.
We
have
added
this
as
one
of
the
justification
slides,
but
we
wanted
to
have
it
in
the
in
the
backup
in
case
this
kmark
right
now.
They
don't
yet
have
a
well-defined
haptic
format
and
I
think
they
would
benefit
having
haptics
as
a
top
level
type
there
as
well.
H
I
A
I
K
A
A
L
L
Okay,
I
think
someone's
got
to
give
me
the
ability.
A
L
Sorry,
I
don't
have
a
camera
on
my
workstation,
my
apologies
static
image.
Only
did
you
want
to
say
a
bit
more
or
do
you
want
me
to
just
kind
of
jump
all
right?
So
this
item
is
about
multiple
suffixes
in
media
types.
Just
really
quickly.
L
We're
gonna
look
at
the
problem
space
talk
about
the
current
draft
a
bit
there's
some!
Maybe
pending
concerns
really
that
need
to
be
discussed
that
harold
sent
out
and
mark
weighed
in
on
and
then
maybe
some
next
steps.
I
think
folks
should
probably
feel
free
to
just
ask
questions
as
we
go
there
only
like
five
slides
here,
so
real
quick
about
the
plot
problem
space,
there's
a
question
about
how
we
should
interpret
media
subtype
names
that
contain
more
than
one
character.
So
there
are
examples
here
at
the
bottom.
L
The
top
one
is
a
real
one,
that's
being
considered
the
bottom.
One
is
just
kind
of
an
attempt
to.
You
know
suggest
that
it
may
apply
to
other
existing
formats,
but
really
it's
it's
around.
L
You
know
what
what
do
we
mean
with
a
structured
suffix?
Are
structured
suffixes
allowed
to
have
two
plus
signs?
If
we
do
that,
what's
the
registration
criteria,
do
we
even
want
to
allow
that
things
of
that
nature?
This
all
came
about
because
at
least
some
of
us
in
some
w3c
working
groups,
tried
to
register
something
with
two
pluses
in
the
name
and
the
response
was
well
there's
not
a
clear
there's,
not
a
clear
decision
on
what
that
would
mean.
So
why
don't
we
clarify
what
that
means
all
right.
L
So
what
are
some
of
the
options
here?
One
of
the
options
is
that
you
know
media
sub
tape.
Subtypes
are
opaque,
they're
defined
by
specification,
and
you
shouldn't
read
anything
into
it
other
than
what's
already
written
right.
L
So
if
you
have
two
pluses
in
there,
maybe
the
spec
needs
to
say
it
or
maybe
we
should
just
not
allow
that
at
all
another
thing
that
we
could
say
is
media
subtypes
are
structured,
but
can
only
be
one
level
deep.
I
believe
that's
kind
of
sort
of
what's
there
today,
but
of
course
defer
to
the
experts
on
that
and
then
finally,
you
know,
media
subtypes
are
structured,
they
can
be
many
levels
and
we
need
to
clearly
specify
and
define
what
it
means
to
have.
L
L
So
if
we
just
look
at
one
of
the
examples
here,
vc
is
a
verifiable
credential
w3c.
You
know,
wreck
ld's,
linked
data,
that's
a
bit
hand
wavy,
but
there's
the
assertion
is
that
there
is
a
specification
that
defines
that
data
model
and
then
plus
json
is
a
serialization
of
that.
So
the
one
suggestion
on
the
way
that
we
could
read
this
is
if
it
has
a
plus
json
extension
on
it,
any
media
type.
L
It
can
be
processed
as
json
if
it
has
a
plus
ld
plus
json,
which
is
a
registered,
you
know
type
as
json
ld.
It
can
be
processed
as
json
ld,
but
you
could
also
point
a
json
processor
and
get
something
reasonable
out
of
it.
If
you
pointed
at
that
that
media
type
and
then
the
final
one
is,
you
know,
we
have
two
plus
signs
you
know
in
here,
and
that
means
that
you
know
it's
a
verifiable
credentials.
L
Data
model
expressed
as
a
linked
data
data
model,
which
is
more
generic,
which
is
then
serialized
as
json.
So
the
current
draft
basically
says
that's
the
way
you
interpret
multiple
plus
signs
in
a
media
type
and,
of
course,
their
concerns
around
this.
Of
course
right.
So
one
of
the
concerns
here
is
that
the
w3c
did
working
groups
already
shipping
stuff
with
multiple
plus
signs.
It
doesn't
mean
that
we
I
mean
we
can
go
back
and
tell
them
stop
doing
that.
L
That's
bad
do
something
else,
but
right
now,
there's
software
that's
implemented.
Nobody
has
screamed
that
it's
anything's
broken
on
them
yet,
but
clearly
it
doesn't
have
super
broad
deployment.
Harold
asked
the
question
on
the
mailing
list
you
know,
is
the
order
of
the
suffixes
significant
or
meaningless
such
that.
So,
for
example,
you
know
vc
plus
ld
plus
json
is
does
that
the
same
thing
as
vc
plus
json
plus
ld,
the
current
draft
says
the
order
has
meaning
so
there's
a
very
specific
way,
you're
supposed
to
interpret
it.
L
The
draft
establishes
that
you
can't
just
mix
and
match
suffixes.
They
probably
need
to
come
in
a
certain
order.
L
There's
a
question
raised
on
whether
or
not
that
ship
is
already
sailed,
meaning
that
we
already
have
at
least
you
know,
plus
xml
and
plus
json,
but
you
know
we
could
make
the
decision
that
well
we're
gonna,
stop
there
we're
not
gonna,
allow
you
know
multiple
kind
of
nested
suffixes
and
of
course
there
are
other
concerns,
like
I'm
sure
chad
has
chat,
has
raised
a
number
of
them.
So
this
is
kind
of
you
know,
discussion.
The
next
slide
is
just
kind
of
what
are
the
next
steps
and
harold.
L
I
think
you
said
you
wanted
to
defer
that
to
the
end
of
the
meeting.
So
why
don't
we
use
this
time?
To
kind
of
raise
concerns,
is
you
know,
is
anyone
concerned
with
the
current
draft
saying
what
it
does
or
any
other
you
know,
concerns
related
to
multiple
suffixes
or
structured
suffixes.
J
Dave
so
sorry,
I've
not
read
the
draft,
but
I
thought
your
explanation
was
great.
The
second
bullet
of
this
slide
confused
me
because
what
it
says
to
me
on
the
screen
and
what
I
heard
in
audio
don't
seem
to
match.
So
I
had
a
clarifying
question
because
I
thought
what
you
said
was
that
the
order
does
matter
and
what
the
slide
says
is
the
order
the
same
if
you
switch
them
around.
The
current
draft
says:
yes,
I'm.
L
Sorry,
yes,
yeah,
that's
that's
confusing.
The
current
draft
says
that
order
has
meaning.
J
Okay,
then,
personally,
I
like
the
direction
that
you're
going.
I
think
that
the
order
should
be
significant.
I
think
that
the
example
that
you
showed
on
the
screen
of
the
three
different
interpretations
of
that
one
was
a
good
example.
You
don't
have
to
go
to
it,
but
I'm
saying
yeah
that
one
I
tend
to
like
that
direction.
I
don't
see
a
problem
with
that.
If
the
order
was
not
significant,
I
would
see
problems
with
that
right.
J
If
you
had
an
unrecognized
one
and
trying
to
deal
with
all
possible
shufflings,
I
think,
would
just
get
too
complex
and
I'm
scared
of
that,
and
so,
if
order
is
significant
than
what
you
showed
here,
I
may
not
be
the
expert
on
this,
but
this
looks
reasonable
to
me,
so
I
think
you're
going
in
the
right
direction.
L
D
I
like
this,
I
support
working
on
it.
I
I've
come
up
with
basically
exactly
the
same
issue
with
wrapping
yeah.
I
have
json
data
structures,
I
wrap
them
in
a
cryptographic
envelope
and
that
json
data
structure
has
a
semantic.
I
do
take
issue
how
I
I
agree
agree
that
the
order
should
be
significant.
D
D
The
sub-semantic
is
ld
and
then,
within
that
I've
got
it
encoded
in
json,
so
I'd
use
exactly
the
same
order,
but
here's
how
it's
mat
it's
going
to
matter
when
we
are
registering
these
things
in
the
iana
registry,
there's
going
to
be
a
top
level
registration
of
application
bc.
D
Now
the
question
is:
are
you
going
to
have
a
sub-registry
of
what
the
interpretations
of
the
things
that
come
after
mean,
or
are
you
going
to
have
that
controlled
by
application,
vc
right?
If
this
becomes
a
thing
in
content,
media
type
world?
That
means
application,
slash
bc
star
anything
afterwards
or
rather
application.
Slash,
vc,
plus
anything
that
follows,
has
to
be
governed
by
a
draft
that
talks
about
application
is
listed
under
application
bc
and
so
on.
It
might
be
that
you
eventually
come
up
with
plus
jason.
D
If
you
specify
a
plus
jason,
it
must
mean
the
same
thing
across
the
whole
itf,
because
it
would
be
ridiculous
to
have
plus
jason
meaning
it's
in
xml,
but
you
know.
Maybe
we
don't
need
to
write
rules
for
that,
because
people
probably
won't
be
that
silly.
L
Yeah
I
mean
you,
you
bring
up
a
really
good
point.
Philip.
I
think
one
of
the
challenges
here
is
that
I
don't
think
there
is
such
a
thing
as
application.
Slash,
vc
the
vc,
it's
it's,
it's
not
it's
kind
of
an
abstract,
it
is
an
abstract
data
model
and
you
could
argue
that
the
linked
data
thing
is
an
abstract
data
model
as
well.
It
has
no,
you
know
it.
L
It
exists
in
kind
of
the
math
sense,
but
it
doesn't
serialize
until
you
shove
it
to
json,
and
so
I
think
there
is
concern
there
around
vcs
and
abstract
data
data
model.
Ld
is
an
abstract,
formally
defined
data
model,
but
it
doesn't
spring
into
existence
until
you
serialize
it
to
json
or
cbor
or
things
of
that
nature,
and
so
I
don't
know
how
to
actually
address
that
concern
right.
The
the
other
thing
that
you
know
we're
struggling
with
here
is,
you
know.
L
Verifiable
credentials
is
kind
of
a
subset
of
a
linked
data
in
a
model,
so
it
feels
that
it's
going
more
specific.
Sorry.
A
L
K
There,
the
little
graph
is
moving
okay.
So
if,
if
I've
been
following
the
the
jabber-
and
I
think
we're
kind
of
resolving
to
a
place
where
we
agree
that
you'd
register,
you
know
jason
or
ld,
plus
jason
as
a
structured
suffix
type,
and
then
that
would
allow
someone
to
register
immediate
type
of
application.
K
You
know
vc,
plus
ld,
plus
json
or
whatever,
and
if
that's
the
case,
it
makes
me
wonder
if
the
only
thing
we
really
need
to
do
here
is
to
clarify
that
structured
suffixes
can
include
the
plus
character,
just
clarify
that
little
point
which
the
draft
sorry,
the
rfc,
I
think,
is
currently
ambiguous
amount
and
it
is-
and
my
question
is-
is
that
enough
and
I'd
like
to
hear
what
people
think
you
know
if
we
just
did
that
or
or
do
we
need
to
go
into
the
potential
swamp
of
what
structured
suffixes
are
and
how
you
might
process
them
and
so
forth?
K
A
So
we
do
have
the
question
of:
does
l
plus
ld
plus
jason
need
to
obey
the
rules
for
plus
jason
anyway?
I
think
we
have
to
ask
our
questions
now.
Let
me
see
if
I
can
get
to
to
share
share
some
slides
again.
A
A
A
I
think
we
have
do
you
have.
A
Yeah,
though
so
for
the
first
one,
it
was
ten
to
two
and
then
and
the
the
second
one
was
fourteen
to
one
now
fourteen
to
zero
and
the
question
three:
should
we
adopt
the
suffixes
draft.
A
I
Yeah,
just
briefly,
I
am
looking
for
a
co-chair
to
back
up
harold
in
this
working
group.
If
anybody
is
interested,
please
reach
out
to
either
of
us,
and
let
us
know.