►
From YouTube: IETF115-MEDIAMAN-20221108-1500
Description
MEDIAMAN meeting session at IETF115
2022/11/08 1500
https://datatracker.ietf.org/meeting/115/proceedings/
A
B
B
B
A
A
B
C
B
B
B
B
A
B
B
I'd,
like
this
working
group,
to
finish,
preferably
soon
so
Martin
couldn't
be
here
either
online
or
not
so
I'll
speak
to
that
changes.
Since
last
idea,
we
now
have
a
working
group,
repo,
a
working
group,
git
organization,
and
it
has
a
report
git
repository
that
contains
the
medium
and
top
level
drafts.
B
C
B
B
D
D
So
it's
up
to
you
how
you
do
it,
but
don't
feel
like
that's
the
only
way
to
get
people
to
comport
with
whatever
you
want
to
say,
and
the
other
thing
is
that
all
three
of
the
documents
I
just
went
through
them
very
quickly.
Looking
for
a
few
things
that
I
typically
trip
on
when
I'm
looking
at
things
that
get
to
the
isg,
none
of
them
use
BCP
14
properly.
So
the
authors
will
need
to
fix
that.
B
D
B
Five
out
of
seven
or
something
like
that,
I'm,
not
yeah
and
creative
organization,
and
who
thinks
the
current
criteria
are
approximately
right,
I
think
so
approximately
so
you
know
they
don't
think
it's
obviously
I
mean
Martin
does
not
often
the
right
field
is
more
or
less
where
we
want
to
be.
But
of
course,
there's
always
details.
C
Alexi
yeah
I
wish
the
criteria
was
very
crisp
about.
You
know
you
just
know
and
go
through
checklists
and
just
decide,
but
it's
it's
not
and
I.
Think
that's
just
real
world
with
this
sort
of
thing
we
need
to
find
out
is
there
is
enough
interest
or
is
documenting
existing
use,
and
you
know
all
of
these
things
so
yeah
I
think
yeah.
So
basically
I'm
saying
you
know,
yeah
I
wish
it
was
better,
but
it's
the
way
it
is,
and
that's
probably
good
enough.
Yeah.
B
B
B
A
Okay,
I'm
not
quite
sure
what
problem
is
being
solved
here,
but
I'm,
hesitant
to
say
too
much,
because
I
haven't
I'm
not
up
to
speed
with
the
draft.
But
it
seems
that
top
level
types
are
sufficiently
rare
that
the
overhead
of
having
to
write
a
new
RFC
to
create
one
doesn't
seem
to
be
that
out
of
out
of
line.
B
C
So,
yes,
maybe
it
can
be
just
dealt
with
by
edging
references
to
RFC
numbers
on
the
media
type
page
and
that
might
be
sufficient,
but
I
kind
of
think
that
it
might
be
easier
to
just
have
a
registry
and
registration
procedures
are
actually
required,
which
is
whatever,
which
is
already
what
we.
What
we're
doing
anyway,.
B
B
B
B
B
B
E
A
E
Go
I
was
looking
for
the
shared
window
as
opposed
to
the
entire
screen.
I
found
it
okay,
now
I'm
gonna
go
into
slideshow
mode
and
ask
the
question
again:
are
you
able
to
see
my
screen
now?
Yes,
okay,
great
hi,
everyone.
My
name
is
yashwant
mutasami
and
I'm,
going
to
give
a
quick
update
on
the
Optics
internet
draft,
just
a
quick
rundown
of
what
has
happened
since
the
last
time.
E
I
I
uploaded
a
version
of
the
draft
which
is
version
zero
one
in
back
in
May
the
in
there
have
been
a
lot
of
haptics
related
development
in
a
MPEG
which
are
quite
quite
relevant
to
what
is
happening
here.
The
impact
guy
haptics
phase,
one
codec
is
now
in
CD
back
palette,
which
is
a
first
of
three
rounds.
E
That's
specifies
how
haptics
interplays,
with
interactivity
and
user
representations,
and
so
on
and
I,
have
done
a
scrub
of
Martin's
draft
and
to
see
whether
the
haptics
IV
satisfies
all
the
all
the
requirements
as
listed
in
the
two
sections
and
the
next
few
slides
are
going
to
be
effectively
kind
of
a
q
a
on
whether
those
requirements
are
being
satisfied
or
not.
So
let's
jump
right
into
it.
The
first
one
I'm
not
going
to
read
through
all
of
his
his
criteria.
You
you
have
that
with
you.
E
Just
the
blue
Parts,
which
are
my
answers
to
whether
they
are
they
are
being
satisfied
or
not.
They
intended
status
of
this
draft
is
indeed
as
standards
track.
Rfc
and
I
have
received
evidence
of
interest
from
three
organizations
so
far.
You've
you
might
have
seen
the
emails
to
the
media
types
mailing
list.
They
are
from
tencent
interdigital
and
Razer.
The
interdigital
is
kind
of
hot
off
the
presses
I
just
forward
it
to
the
group.
E
Just
now,
I
wasn't
sure
if
it's
going
to
show
up
by
itself,
I
I,
don't
think
that
there
is
any
confusion
here,
because
all
subtypes
that
pertain
to
any
formats
pertaining
to
haptics
or
any
of
the
sub
moralities
of
haptics
would
fall
under
this
top
level
type.
So,
in
my
opinion
at
least,
there
is
zero
scope
for
confusion.
E
Moving
on
the
I
have
two
actual
subtypes
defined
in
this
draft.
As
soon
as
this
draft
is
approved,
the
registration
of
the
actual
types
will
be
done
and
reflected
on
the
final
RFC
document,
but
there
are
also
a
number
of
subtypes
which
I
talk
about
in
this
in
this
deck
and
we
can
go
about.
We
can
look
at
that,
and
these
are
the
haptics
subtypes
which
are
actually
in
use.
As
we
speak.
A
a
hap
is
is
a
format
that
represents
all
of
the
encoding
used
in
iOS
devices.
E
Right
now
you
know
over
a
billion
mobile
devices
worldwide
or
org
is
a
proprietary
extension
to
the
org
for
for
format,
for
haptics
done
by
Google
by
Google
and
and
IBS
is
a.
He
invent.
A
specific
haptic
for
format
that
we
at
immersion
are
using
and
many
of
our
our
customers
are
using
same,
goes
for
hacked
in
a
decision
to
this.
E
There
are
a
number
of
Standards
related
haptic
for
subtypes,
which
are
in
Flight
in
various
stages
of
standardization,
and
a
few
of
them
are
documented
in
section
2.6,
but
based
on
the
last
meeting
in
the
month
of
October
at
MPEG,
there
are
a
few
more
which
are
worth
mentioning
and
you
see
them
all
here.
The
Peg
is
the
phase
one
coding
format,
H
Jeff
is
The.
Interchange
format
mih1,
as
I
mentioned
already,
is
a
streaming
format
and
then
the
highee,
according
for
formats,
are
actually
invalid.
E
This
is
the
idea
in
the
final
IEEE
essay
that
the
ballot
and
they
have
one
vibro
tactile
and
two
kinesthetic
coding
for
formats
and
the
he
enum
and
the
havc
are
the
are
the
in
enumerated
effects
or
the
A
to
B
or
audio
to
Y
coding
formats.
So
there
is
a
lot
of
subtypes
which
are
in
haptics,
which
are
kind
of
waiting
for
the
door
to
be
open,
so
to
speak
once
that
top
level
haptics
type
type
is
approved.
These
can
all
be
is
registered.
E
That
tactics,
the
top
level
type
and
then
of
course,
as
I
mentioned
already
hey
immersion,
has
testified
two
success
to
two
subtypes
and
we
have
control
over
and
in
the
email
from
from
from
laser.
They
have
indicated
strong
interest
in
to
in
having
two
of
their
own
subtypes,
be
under
the
haptics.
It's
a
top
level
type.
The
apps
and
the
chaps
and
I
think
the
email
from
Razer
actually
provides
an
a
Exemplar
as
a
subtype
registration
I
will.
E
Let
you
read
through
that
email,
it's
on
the
list
and
as
I
mentioned,
they're
MPEG
subtypes
are
there
which
are
in
the
previous
slide.
These
will
become
part
of
the
impact
standard
over
the
course
of
the
next
12
to
18
months
and
the
IEEE
subtypes
are
going
to
be
used
in
the
5G
tactile
internet
application
space,
a
quick
rundown
to
the
section
2.2
there
is
no.
There
are
no
undefined
top
level
types
currently
in
news,
of
course
it
is.
E
It
is
actively
being
discussed
in
this
working
group
right
now,
so
no
issues
there
all
data
for
formats
or
subtypes
under
the
Optics
ID.
They
all
put
into
the
sense
of
touch
and
they
need
to
be
under
the
proposed
top
level
type,
and
the
key
common
feature
of
all
of
these
subtypes
is
that
they
all
require
some
kind
of
a
haptic
subsystems,
such
as
low
level
haptics
apis,
which
in
turn
will
require
Hardware
capabilities
such
as
one
or
more
haptic
actuators,
to
actually
do
the
rendering
of
the
haptic
haptic
media.
E
So
they
do
all
share
these
common
features
and
attributes
and
the
and
the
last
one
is
that
that
these
are
all
pertaining
to
the
sense
of
touch
in
much
the
same
way
that
audio
and
video
top
level
types
pertain
to
the
sense
of
hearing
and
with
vision,
and
then
common
restrictions
yeah
the
applied.
This
is
what
I
could
think
of
and
I
didn't
quite
understand
the
ask
in
this
last
criteria.
This
might
be
something
that
we
discussed
on
the
list.
E
D
D
D
D
One
thing
that
your
two
registrations
in
four
three
two
correct
two
short
corrections
as
I
I,
see
this
a
lot
when
I'm
looking
at
media
type
registrations,
you
have
required
parameters,
none,
it
has
to
be
n
a
otherwise
none
is
interpreted
as
there's
a
parameter
called.
None
that
you
need
to
describe.
D
D
Okay,
I
think
that
should
be
made
crisp,
because
this
is
going
to
be
the
document
that
I
as
a
media
type
reviewer
come
to
look
for,
should
I
allow
this
haptics
registration.
This
is
all
the
guidance
I'm
going
to
come
to
so
I
need
to
know
if
this
stuff
applies
to
that
these
two
haptics
things
or
to
all
future
haptics
things.
So
just.
B
B
E
B
G
E
I
have
to
look
at
what
you
are
referring
to.
It's
been
a
while,
if
you
can
give
me
just
a
minute
here
like
and
pull
it
up,
okay
to
just
to
answer
your
question,
there
could
be
some
haptics
files
like
the
descriptive
formats
like
ahap,
which
has
basically
an
extension
of
the
Json
standard,
so
that
I
think
is
what
is
being
referred
to,
that
that
would
be
the
text
part
where
they
provide
a
specification
of
the
haptic
effect
in
Json
format.
In
other
cases,
the
haptic
file
is
just
a
binary
signal.
B
C
B
C
G
E
B
Okay,
I
think
we're
at
the
end
of
the
a
lot
of
time
for
this
one
and
I
believe
that
we
have
two
reasons
why
this
cannot
be
last
call
at
this
time.
The
one
is
that
there
are
some
issues
that
needs
to
be
fixed
and
the
other
one
is
that
it
depends
on
the
top
level
draft
that
is
not
fixed,
not
finished,
but
I
think
we
all
very
happy
to
see
this
go
be
substantially
closer
to
ready
than
it
was
last
time
we
looked
at
it.
B
B
F
F
F
F
Well:
okay:
well,
then,
I
will
try
and
just
read
through
for
those
of
you
that
have
access
to
the
slides,
please
feel
free
to
you
know,
click
through
to
them.
The
first
issue
was
a
request
by
Harold
to
add
something
to
the
security
consideration
section
around.
You
know:
how
could
people
abuse
this
this
new
kind
of
suggestion
on
how
you
can
process
multiple
structured
suffixes?
F
F
So
Harold
asked
for
some
language
there
we've
added
it.
It
feels
a
bit
contrived.
The
current
text
in
the
specification
feels
a
bit
contrived,
but
at
least
it's
there
to
warn
people
and
we've
been
looking
for
reviewers
to
provide
a
better
example.
So
that's
issue
two
just
keeping
that
issue
open
in
case
somebody
has
a
better
idea
of
a
more
serious
attack
with
this
kind
of
processing
model.
The
issue
three
is
adding
guidance
around
fragment
processing.
F
So
if
you
choose
to
process
a
document
not
according
to
the
entire
media
type,
but
according
to
just
the
structured
suffix
and
the
spec,
how
should
you
interpret
the
fragment
because
it
will
be
different
in
some
cases
than
the
entire
thing,
and
is
that
valid
sorry,
the
entire
media
type,
and
is
that
valid?
So
we
need
guidance
on
that.
I
would
love
to
hear
suggestions
from
anyone.
F
I
think
what
we
were
thinking
of
doing
was
saying.
It
is
okay
to
interpret
a
fragment
according
to
the
specification
that's
associated
with
the
structured
suffix.
So
if
you've
got
this
big
media
type
and
it
ends
in
I,
don't
know
plus,
let's
just
say
a
plus
LD
plus
Json-
that's
Json
LD
thing:
it
isn't:
okay
to
interpret
the
fragment
per
the
Json
LD
specification
and
not
per
the
more
specific
media
type
specification.
F
So
thoughts
on
that
would
be.
You
know
fantastic!
That's
the
text
that's
going
to
be
written
unless
we
hear
a
different
idea.
There
next
issue
was
review
by
Mark
Nottingham.
Thank
you.
Mark
I
apologize
for
taking
so
long
to
get
back
to
your
review,
but
in
the
issue,
I
did
try
and
break
down
the
concerns
that
Mark
raised
many
of
them.
You
know
good
good
and
fine
concerns
I.
Think,
there's,
there's
a
there's,
a
question
here
and
I.
Don't
know
the
answer
to
this.
F
So
again
would
love
to
hear
thoughts
on
this
around
what
happens
if
you've
got
a
big
media
type
and
you
use
a
structured
suffix
to
to
process
it
in
some
way
in
the
way
the
pipeline
algorithm
goes.
Is
you
can
keep
lopping
off
structured,
suffixes
and
processing
them
according
to
the
more
generalized
specification?
F
But
at
the
end
of
the
day,
sometimes
what
you
end
up
with
when
you
Lop
those
things
off,
is
you
end
up
with
a
media
type
that
is
not
registered
anywhere,
meaning
that
it's
like
what
you're
left
with
is
some
meta
model?
It
has
no
serialization,
and,
and
what
do
we
do
in
that
case
right?
So
that's
the
big
question.
Mark
Nottingham
suggested
that
maybe
what
we're
looking
at
here
is
a
new
top
level
type
feels
kind
of
top
level
typey,
but
that
creates
a
number
of
other
issues.
So
there's
a
concern
here.
F
The
the
guidance
right
now
or
the
guidance
I
think
that's
going
to
be
written
into
the
specification
is,
if
you
choose
to
lob
these
structured,
suffixes
off
and
process
them.
You
know
in
that
order,
you
can
keep
doing
that
until
you
end
up
with
a
media
type
that
has
no
registration.
At
that
point
you
have
you,
don't
know
what
to
do.
You
can
process
it
full
stop
right,
so
I
think
that's
the
suggestion
there
I
have
no
idea.
F
If
that's
a
terrible
idea
or
not,
it
feels
I
feel
pretty
uncomfortable
with
that,
but
I
can't
think
of
a
better
way
to
address
that
issue
and
that
concern
so
there's
some
text
that
needs
to
be
written
there
based
on
Mark's
review
and
then
I
also
need
to
know
from
Mark.
If
he's
okay
with
the
other
answers
in
there
and
then.
F
Finally,
the
last
issue
is
from
Ted
Thibodeaux
Jr
issue
number
five
and
he
just
found
a
number
of
grammatical
issues
that
need
to
be
fixed
in
as
some
questions
that
I
think
need
to
be
clarified
in
the
in
the
spec
by
just
modifying
spec
text.
So
that's
it
for
the
issues
if
we
can
go
to
the
next
slide
Harold.
F
So
what
we
have
at
this
point,
Who's
read
the
draft
new
reviewers.
We
had
a
bunch
of
old
reviews,
new
reviewers
Mark,
Nottingham,
Harold,
Reddit,
Roberto
pulley,
because
they're
doing
a
plus
yaml
in
a
potentially
a
plus
LD
plus
yaml
extension
and
then
Ted
Thibodeau
new
reviewers
they're.
In
the
issue
tracker
there's
some
there's
probably
about
two
to
three
paragraphs
that
need
to
be
added
to
the
spec.
F
Based
on
that,
we
should
not
go
to
last
call
just
yet
because
we
have
things
that
need
to
be
added,
but
my
hope
is
by
the
next
ITF.
We
will
be
ready
to
go
to
last
call
so
I
think
we're
going
to
add
those
paragraphs.
If
nobody
has
any
objections
to
them.
We're
going
to
ask
for
broader
review
from
the
did
working
group
and
the
verifiable
credential
working
group
and
get
some
reviewers
from
there
and
then
and
then
that's
it
so
I
think
that's
the
plan.
B
G
Hi,
my
name
is
Daryl
Miller,
just
it.
It's
probably
more
of
a
question
here
in
some
of
the
suffix
are
different
than
other
suffix
like
plus
Json
plus
XML
is
just
adding
another
lower
level
layer
of
semantics.
But
then
things
like
plus
the
gzip
are
completely
changing.
The
stream
of
bytes
like
if
you
do,
plus
LD,
Plus,
gzip
or
sorry
say,
let's
say,
do
plus
Json
plus
gzip
can
I
still
use
a
fragment
identifier
for
Json,
or
does
that?
Is
that
no
longer
valid
because
of
the
last
plus
Jesus.
F
Yeah,
that's
it
that's
an
excellent
question.
That's
where
I'm
really
stuck
it's
it's
those
kinds
of
edge
cases
that
are
just
really
difficult
to
write
to
so
one
thing
we
could
say
is
like:
if
you
choose
to
process
multiple
structured
suffixes
in
this
way,
all
bets
are
often
fragment
processing
right.
F
A
G
F
Okay,
so
if
there's
fragment
processing
for
Jason
pointer-
and
you
have
a
Jason
pointer,
plus
gzip,
if
you
want
to
apply
you
know,
if
you
want
to
ungzip
it
and
then
apply
the
fragment
processing
to
the
Json
pointer
thing,
it
seems
like
you
should
be
able
to
do
that,
like
that
seems
like
a
legitimate
thing
to
do.
I,
just
don't
it's
the
edge
cases.
I,
don't
know
if
that
results
in
some
kind
of
security
compromise
on
some
crazy
combination
of
the
structured
suffixes.
That's
the
thing!
F
B
But
I
think
that
we
can't
make
a
general
rule
for
that,
because
if
you
transform
something
from
XML
to
Json,
well
that
that
probably
doesn't
have
the
same
fragment
fragment
to
identify
syntax.
So
you
would
have
to
re
rewrite
the
fragments
too.
So
I
think
I.
Think
the
this.
This
draft
needs
to
say
that
dealing
with
the
transformation
suffixes
under
transformation
needs
to
be
specified
as
part
of
this,
of
the
transformation
descriptions.
A
B
A
B
B
B
H
Some
of
that
has
to
do
with
what
we
allow
them
to
register
I.
Think
and
so.
The
two
kind
of
conversations
that
I'd
like
to
start
are
around
whether
we
can
do
things
to
the
registration
process
to
encourage
and
facilitate
more
registrations,
and
that
might
be
you
know,
I
I
I
proposed
GitHub,
because
we've
started
using
GitHub
issue
cues
for
a
lot
of
other
Registries
and
especially
ones
where
the
audience
with
registry
is
not
just
an
ietf
audience.
H
It's
one
of
the
places
where
they
actually
do
have
some
infrastructure
for
letting
people
do
a
registration
I.
Think
the
difference
is
that
excuse
me
with
with
the
GitHub.
You
create
an
issue,
and
then
you
have
evidence
of
that
issue.
You
can
go
back
and
check
its
status.
You
can
have
a
conversation
in
the
issue
and
that's
not
true
with
the
Forum,
with
the
form.
It's
it's
more
fire
and
forget,
and
and
and
I
have
this.
H
Unfortunately,
you
know
this
is
the
expense
of
a
lot
of
registrations.
Is
that
the
register
follows
something
somewhere
or
sends
an
email?
And
then
they
don't
really
know
what
the
status
of
the
request
is
and
and
or
or
what
the
the
the
guarantees
on
getting
a
response
are.
It
Ayanna
is
very
good
about
meeting
their
slas,
but
experts
often
are
not,
and-
and
so
that's
one
discussion
to
have
I
think
about
what
we
can
do-
I'm
happy
if
we
keep
the
form
I.
Think
that's
great
I
would
ask
that
we
think
about.
H
You
know
whether
we
have
the
right
documentation
and
words
around
the
form
to
make
that
process
easy
and
whether
we
can
do
anything
to
make
the
results
of
the
form,
processing,
more
transparent
or
or
if
people
are
going
to
use
GitHub,
as
in
all
the
Registries
I've
used
it
for
it's
a
parallel
process.
People
can
still
file
by
email
and
we
don't
want
to
make
people
use
the
specific
tool.
S
Excuse
me.
Yes,
technically
yeah
you
need
to
make
a
request
directly
to
Ayanna.
H
Maybe
one
of
the
reasons
why
GitHub
has
been
more
successful
is
that
you
can
iterate
much
more
quickly
with
that
you
can
go
and
and
tweak
the
text,
and
if
somebody
has
a
question
you
realize
you
haven't
covered
a
point,
you
can
go
and
put
it
in,
whereas
right
now,
through
no
fault
of
their
own,
we
have
to
go
and
ask
Ayanna
to
tweak
the
test
on
the
page
and
that's
a
very
manual
and
kind
of
clunky
process.
So
that's
one
area
to
investigate.
H
We
do
that
with
a
lot
of
other
registries,
including
HTTP
headers
URI
schemes,
link
relations,
there's
no
concept
of
trays
in
any
of
these,
and,
and
especially
when
you
have
something
go
from,
you
know,
not
a
proprietary
use
or
or
limited
use
to
standard
use.
If
it
does
become
common,
then
you
have
that
awkward
transition
of
well.
H
So
so
that
was
kind
of
my
starting
point,
I
think
in
discussion.
You
know
it
was
pointed
out
that
maybe
we
should
just
open
up
somewhat
and
say
you
know,
be
more
welcoming
and
and
make
it
clear
that
we're
more
welcoming
to
open
source
projects,
for
example,
and
maybe
that's
the
right
line.
But
we
need
to
have
a
discussion
about
what's
the
right
line
for
getting
into
the
standards
tree.
H
How
can
we
make
sure
that
you
know
that
people
who
want
to
do
the
right
thing
in
registered
media
types
can
do
so
and
I?
Don't
think
that
that
saying
well
because
you're
not
a
recognized
standards,
developing
organization,
you
have
to
go
into
this
ghetto
over
here
that
that's
not
really
an
acceptable
solution
for
the
the
world
that
we
live
in,
but
we
do
need
to
maybe
have
some
criteria.
H
I
I
will
say
that
in
the
other
registries,
we
we
put
more
of
the
work
on
the
expert
to
say
well,
if
somebody
comes
along
and
they
don't
seem
to
have
a
vital,
you
know
a
project,
that's
actually
getting
adoption
and
they
try
and
squat
on
a
name.
That's
you
know
quite
common
and
quite
short,
don't
let
them
do
that.
Make
them
use
a
longer
name,
that's
more
specific
to
what
they're
doing
so
that
we
don't
consume
potentially
valuable
names
as
easily
I.
Think
you
know.
B
Thank
you
speaking
as
participants
and
since
I
joined
the
queue
first
and
the
the
reason
for
making
a
somewhat
onerous
process
for
unprefixed
names
is
I.
Think
that
when
we
have
two
things
that
have
the
same
name,
we
want
to
make
sure
that
they
actually
have
the
same
definition
so
that
they
can
tell
whether
they
conform
to
the
definition
or
not,
and
we
kind
of
come
down
that
by
requiring
a
stable
reference
and
we're
kind
of
required
a
stable
reference.
B
A
So
can
I
the
points
you
made
about
open
source
projects,
an
observation
from
what
happens
with
URI
scheme
registrations.
One
of
the
criteria
that
I've
learned
to
apply
on
occasion
is,
if
some,
if
the
scheme
is
in
widespread
use,
then
this
can
usually
be
found
by
doing
a
bit
of
hunting
out
on
the
web,
and
that
could
be
sufficient
reason
to
allow
that
as
a
permanent
registration.
So
it
could
be
a
similar
thing
that
applies
here,
something
you
you
think
the
issue
of
two
things
should
should
be
referring
to.
A
B
F
Yeah
I
just
wanted
to
speak
in
favor
of
what
Mark
was
suggesting.
In
fact,
this
is
exactly
how
we
operate
the
decentralized
identifier
registry
at
at
w3c,
so
I,
A,
plus
one
to
making
it
you
know
be
driven
through
GitHub.
That's
what
we
do.
We
provide
a
very
easy
template
that
just
about
any
implementer
can
fill
out.
It
just
has
a
few
fields
in
it.
F
It's
a
GitHub
issue,
template
and
when
they
raise
that
you
know
the
experts
are
pinged,
and
then
we
do
a
review
threaded
review
just
on
the
issue
on
the
pull
request
itself.
So
on
the
whole,
it
has
definitely
led
to
more
engagement
from
non-standards
people.
We
have
a
140.
Basically
145
of
these
things
were
registered
within
the
course
of
around
two
years.
F
So
we
had
a
massive
rapid
rise
in
registered.
Did
methods
somewhat,
you
know
synonymous?
Well,
they
have
the
same
kind
of
usage
patterns
as
as
media
types,
so
I
think
it's
a
good
thing,
but
what
we
have
found
is
we
have
a
bunch
of
people
that
don't
know
anything
about
standards
that
jump
in
and
try
and
register
these
things,
and
sometimes
it
takes
an
enormous
amount
of
effort
from
the
experts
to
teach
people
about
what
they
need
to
do
right.
F
So
so
that's
stressing
out
the
experts,
because
not
a
week
goes
by
before
we
you
know
we.
We
have
to
teach
these
folks
like
what
it
means
to
have
a
decent
spec
and
a
stable
reference
and
all
that
kind
of
stuff,
and
even
if
we
give
them
something
to
go
and
read,
they
don't
read
it
right.
So
so
that
takes
that's
a
a
an
increased
stressor.
F
F
It's
really
really
easy
for
someone
to
go
in
and
try
and
squat
in
a
namespace,
and
then
we
we
ended
up
spending
I
mean,
and
it's
still
going
on
the
registration
procedures
we're
having
to
keep
changing
because
people
keep
trying
to
game
it
because
there's
so
many
more
people
that
are,
you
know
attempting
to
do
this
so
I
think
the
upsides
certainly
outweigh
the
downsides,
but
you
know
you
have
to
be
ready
for
the
downsides.
If
you
adopt
such
a
system,
they
are
manageable.
C
Okay,
Alexis
so
in
regards
to
GitHub
I
mean:
let's
try
it
and
see.
We
don't
actually
need
to
change
any
documents
for
this
to
try
it
out
and
if
it's
successful
then
well,
you
know
we
can
document
it
after
the
fact,
and
in
regards
to
sgo
I
think
my
preferred
short-term
fix
is
to
expand
the
list
and
say
that
recognize
open
source
projects
are
should
be
treated.
The
same
for
this
we'll
need
to
write
an
RFC
async
like
as
I
said
on
the
mailing
list.
C
G
F
G
Just
one
of
the
impacts
of
the
honors
process
is
in
the
HP
API
space.
Most
people
just
don't
bother,
they
send
application,
slash
Json,
most
devs,
don't
even
know
what
content
type
is
for,
because
the
only
thing
they've
ever
seen
there
is
applications.
Last
Json
I've
been
being
harassed
for
four
years
now
to
go
and
register
the
open,
API
media
type,
and
we
haven't
because
we
didn't
have
a
stable
organization
despite
its
widespread
use,
so
it
does
have
a
negative
impacts,
I
believe
the
the
and
positive
impacts.
But
there
are
some
negative.
H
I
think
what
we
might
be
talking
about
is
giving
the
experts
a
bit
more
discretion
as
well
as
guidelines
about
who
they
admit
into
the
standards
tree
and
I'm.
Glad
ones
are
necessary,
but
discretion
is
going
to
be
necessary
as
well,
because
if
the,
if
we
just
say
open
source
well,
I
can
create
an
open
source
project
in
about
20
seconds.
H
That's
no
barrier,
and
so
you
need
to
have
some
some
qualifications.
You
need,
and
it's
going
to
require
judgment.
There's
an
appeal
process
there.
So
I'm
not
too
worried
about
that.
You
know
they
can
always
appeal
to
the
80s
if
they
feel
like
the
expert.
Get
it's
wrong,
gets
it
wrong,
but
we're
going
to
need
to
be
comfortable,
allowing
the
experts
to
make
those
sorts
of
decisions
and
we
might
put
in
gardens.
H
H
But
but
if
you
know
this
is
what
we
do
often
with
HTTP
headers
is
we
say
you
know
you
you're
doing
this
application?
This
is
specific
to
your
application,
so
prefix
it
with
your
application
name
so
that
we
don't
worry
about
conflicting
with
anybody
else's
use
and
and
everybody's
clear
about.
What's
Happening
Here,
we
can
talk
about
that
as
well.
H
A
So
the
issue
about
registrations
being
onerous
is
intention
intention,
with
the
issue
of
wanting
to
get
people
to
register
stuff,
that
they're
actually
doing
in
real
life.
And
this
was
behind
the
structure
we
introduced
for
message.
Headers
and
URI
schemes
which
allows
a
provisional
registration,
which
has
got
very
light
touch
entry
requirements
that
doesn't
have
the
full
status
and
doesn't
have
the
same
level
of
expectation
that
it's
there
forever
and
then
the
permanent
registration
which
elevates
it
to
something
closer
to
a
standard
or
recommendation
level.
B
Thank
you,
and
now
we
are
over
time,
so
I'll
ask:
do
we
have
anyone
who's
who
wants
to
volunteer
to
write
up
a
note
or
something
about
yeah
Mark?
It's
volunteering
yeah,
so
he's
going
to
write
something
that
we
can
in
the
form
of
an
ID
or
in
the
form
of
something
else
that
we
can
then
criticize
and
file
banks
on
and
do
pull
requests
on
right.