►
From YouTube: IETF-CORE-20220706-1400
Description
CORE meeting session at IETF
2022/07/06 1400
https://datatracker.ietf.org/meeting//proceedings/
A
D
D
D
You
so
let's
get
started
then
welcome
everyone
to
this
interim
meeting
of
the
co-working
group.
I'm
marketiloka,
my
coaches
are
jaime
jimenez
and
carson
bormann
and,
as
usual,
the
usual
not
well
applies
get
familiar
with
that,
if
you're
not
already
it's
about
ipr
patterns
and
so
on,
but
it's
also
especially
about
our
color
conducts
so
be
nice,
polite
and
professional
to
each
other,
and
the
agenda
for
today
has
two
items:
a
new
document
that
thomas
and
hank
proposed
on
parameterized
content
format
for
co-op
and
then
hopefully
the
wrap-up
around
the
problem.
C
D
C
Yeah,
what
happens
if
I
move?
Okay,
cool
cool?
Thank
you
very
much,
okay.
So
so
right.
So
this
is
for
this
parameterized
content
format
drafted,
and
can
I
push
through
the
data
tracker
a
couple
of
weeks
ago?
I
think,
but
yeah.
So
it's
about
you
know
extending
content
formats
and
yeah.
Of
course
you
know
co-op
what
it
does.
C
Is
it
compresses
aggressively
across
the
board
and-
and
you
know
in
particular
in
the
case
of
representation
formats-
it
takes
these
three-dimensional
objects
and
replaces
them
with
sort
of
hologram
that
we
call
the
content,
format
right
and
and
the
content
formats
build
on
on
the
on
the
observation
that
in
a
lot
of
cases,
the
the
three-dimensional
space
is
really
a
single
point.
So
we
can.
We
can
squash
it
into
into
a
p
right
and
and
on
top
of
that,
what
we?
C
So
yeah
we
have
these
two
slightly
different
spellings,
so
parameterize
and
parameterized.
I
don't
know
which
one
is
the
the
right
one.
So
I
will
call
it
pcf
for
short,
so
we
avoid
any
holy
wars
on
naming
which
could
hamper
progress
and
and
while,
while
the
spelling
of
this
thing
may
be
maybe
somewhat
tricky,
the
the
idea
is
is
is
pretty
straightforward
and.
C
C
Yeah
so
a
couple
of
a
couple
of
excerpts
from
6838,
which
is
the
which
is
the
media
type
rfc
right.
So
this
is
the
authority,
the
overall
authority
of
this
meta
and
what
it
says
is
that
names
are
case
insensitive
and
the
order
is
not
important
and
then
also
that
is
an
error
for
if
we
get
duplicated
keys
and
as
far
as
parameters
are
concerned,
says
that
there's
no
defined
syntax,
so
there's
no
priority
syntax.
We
could
say
that's.
C
Why
there's
a
reason
to
have
the
dna
here
right
in
the
cddl,
because
we
don't
know
what
that
is,
and
the
registrations
must
specify
the
the
syntax
for
for
each
of
the
parameters
that
they
define
so
and
also
it
says
it's
going.
It
goes
on
and
say
you
know:
some
transports
impose
restriction
on
parameters,
parameter
values,
syntax,
which
means
when
registering
one,
should
look
for
the
least
problematic
encoding
which,
which
usually
means
you
know
avoiding
binary,
okay
applications.
C
406
and
415
want
them
to
apply
aziz
and,
and
the
thing
is
that
by
using
pcf
as
the
option
value
one
gets,
you
know
supposedly
increased
flexibility,
so
I'll
go
forward
and
look
at
the
and
show
you
the
the
tables
for
for
the
p
content
format
and
and
p
accept
options
which
basically
mirror
their
their
non-parameterized
pair
in
a
sense
that
they
have.
You
know
the
same
layout
in
terms
of
cu
and
our
bits
and
the
only
the
only
difference.
C
So
compared
to
the
to
the
normal,
accept,
you
can
have
multiple
things
squashed
into
into
a
single
option:
yeah.
So
so
what
does
it
mean?
Moving
to
this
multivalued
p
accept,
since
we
wanted
to
retain
the
the
the
exact
semantics
has
accept
the
critical
bit
is
up
and
and
because
the
critical
bit
is
up,
the
implication
is
that
a
request
which
is
not
understood
by
the
server
will
fail
with
402.
C
That's
it
okay,
so
yeah
prior
art
custom
suggested
to
go
through
some
prior
art
and
gave
me
a
couple
of
pointers.
Then
this
morning
chris
mentioned
he's
accept
any
draft
that
managed
to
fall
through
the
cracks
of
my
inbox.
Unfortunately,
but
except
any
also
his
prior
art
here
and
should
be,
you
know
just
below
ocf,
so
you
can
see
that
invisible
link
there,
but
you
know
the
the
other
priorities:
effectively:
cinema
cinema
data
value,
content,
format
and
and
ocf
content
format,
version
which
I
will
you
know
go
through
quickly.
C
So
19193
defines
this
content
form
a
spec
which
is
a
string
representation
of
the
content
formats,
either
as
a
as
a
string,
a
content
form
a
string.
So
you
know
media
type
and
parameters
and
whatnot
or
the
or
another
string,
which
is
the
decimal
representation
of
the
content.
Format
number
and
in
a
way,
roughly
very
roughly
speaking,
pcf
is
a
third
type
of
this
content
format,
spec,
which
is
a
sort
of
binary
version
of
the
string.
C
So
how
that
the
two
compare
well,
this
is
something
missing
in
this
slide,
but
anyway
you
know.
Obviously
the
pcf
based
is,
is
more
compact,
because
and
but,
but
on
the
other
side,
pcf
depends
on
the
existence
of
a
content
format
that
has
been
registered
in
the
ayana
right,
because
you
know
you
need.
C
You
need
the
integer
value
to
put
into
into
the
into
the
array-
and
this
is
quite
quite
a
significant
difference,
because
it's
not
that
once
you
have
defined
a
media
type,
you're
done
you're
said
and
done
you.
You
also
need
to
round
trip
to
I
through
ryana
to
get
the
the
code
point
that
you
can
stash
into
into
the
pcf.
C
C
C
The
interesting
thing
here
is
that,
because
they,
you
know,
they
solved
this
problem
in
a
very
specific
way.
They
did.
You
know
they
optimized
for
that,
of
course,
and
intelligently
they
split
these
2b
two
bytes
into
five
five
and
six
bits,
respectively
to
encode
the
the
core
semantic
version
from
format
which
is
major
minor
and
patch,
and
so
you
have
one
one:
zero
that
encodes
to
you
know
that
thing
which
end
up
in
into
into
a
to
to
to
by
integer.
C
So
looking
at
how
that
would
translate
into
pcf.
Maybe
this
is
a
bit
small,
but
you
know
in
in
in
pcf.
This
would
look
like.
First
of
all,
there
would
be
one
single
option,
because
you
you
you
put
together
the
content,
format
and
any
parameters
and
and
the
way
you
would
do
that.
You
know
you
you
take
ten
thousand,
which
is
the
application
vendor
ocf,
plus
cbor
content
format.
C
I
think
right.
So
the
questions
here
are
two
a.
Is
there
any
interest
for
per
person?
This
feature,
which
has
you
know,
popped
up
at
various
intervals
in
different
ways.
It
seems
to
be
in
in
the
working
group
history,
but
it
has
never
been.
You
know
tackled
in
in
you
know
in
some
definitive
way
and
secondly,
if
and
subordinate
to
that.
C
A
Yeah,
so
I
just
just
typed
why
why
thomas
was
speaking?
This
is
probably
not
the
complete
list
of
questions,
but
I
seem
to
remember
that
that
the
the
specific
idea
came
up
like
2013
or
so,
and
I
I
have
already
forgotten
what
what
the
draft
was
that
that
in
the
end
we
decided
not
to
do
so.
The
the
the
question
here
really
is.
This
is
clearly
missing
functionality.
A
A
A
These
text
strings
may
have
some
structure
in
it,
and
typically
part
of
that
structure
is
obtained
by
simply
having
several
media
type
parameters
that
you
need
to
specify
at
the
same
time.
So
if
you
have
a
structure
of
values,
you
need,
you
just
define
a
number
of
parameters
and
they
all
need
to
be
set.
A
But
what
I'm
trying
to
say
is
that
we
cannot
just
refer
to
a
media
type
registration
and
imagine
that
we
have
a
well-defined
way
to
translate
the
textual
nature
of
the
parameters
into
a
sibo
any,
and
I
think
we
might
be
able
to
do
something
that
that
solves
that
problem
for
80
percent
of
the
cases,
but
we
we
need
to
do
this
explicitly.
So
we
could
say
something
like
if
the
parameter
value
looks
like
like
a
decimal
number,
then
you
can
put
the
number
in
binary
there.
A
A
Is
it
actually
necessary
to
have
mutual
exclusion
between
the
content
format
that
maybe
already
has
defined
one
parameter
so,
for
instance,
content
from
a
zero
defines
one
parameter,
which
may
be
a
bad
example,
because
you
never
want
to
change
that.
But
imagine
that
you
actually
want
to
change
that.
You
would
have
to
register
a
new
content
format
that
does
not
have
the
parameter
which
may
be
illegal
according
to
the
medium
type,
because
that's
the
required
parameter.
C
A
A
C
A
Thing
we
have
a
few
content
formats
that
that
are
just
existing
content
formats,
plus
a
content
coding
slab
on
them,
and
so
these
would
be
potential
use
cases
where
you
might
want
to
separate
out
the
content,
type
and
and
content
coding
again.
So
I'm
just
again
you,
you
said
the
right
thing.
I
didn't
find
a
use
case
so
having
the
right
use.
Cases
will
guide
us
in
in
making
these
kinds
of
decisions.
C
Yeah:
okay,
thanks
for
the
excellent
feedback-
and
you
know
the
only
thing
I
can
probably
answer-
and
very
very
you
know
from
my
from
my
small
corner.
Is
we
give
you
a
couple
of
examples
which
are
these
media
types
coming
from
from
rats
one
for
each
and
one
well,
multiple
for
it
and
and
and
and
a
couple
from
for
quorum
as
well,
which
are
parameterized,
and
if
we
want
to
have
restful
apis
based
on
co-op,
not
just
on
http
that
that
exchange
exchanges,
these
payloads,
then
we
probably
need
to
have
a
way.
C
C
So
you
know-
and
this
comes-
this
is
coming
from
a
single
vendor,
so
yeah
we,
we
might
be.
You
know
pathologic
in
this.
I
don't
know
exactly,
but
that
seems
like
you
know,
there's
a
use
case
for
this,
and
if,
if
we,
if
we
managed
to
produce
four
profiles
in
say
a
couple
of
years,
then
I
suppose
the
ecosystem
is
going
to
be.
You
know
even
more
prolific
in
this
so
having
having
to
go
through
through
ayanna
to
to
get
all
these
good
points
all
the
time,
and
that
might
be.
C
C
So
the
draft
the
the
draft
is
referred
in
from
informationally
from
from
the
the
draft
that
I'm
talking
about
one
of
the
two,
in
fact,
because
the
other
one
is
not
from
the
from
the
parameterized
cf
draft
and
it's
called
it
media
types.
If
I
remember
correctly,
that's
the
use
case
I
have
to
put
on
the
table.
D
F
C
C
A
The
the
idea
is
that
if
you
want
to
combine
content
from
it
with
the
the
traditional
except
with
the
multi-accept,
then
you
could
do
it
in
the
way
shown
here.
So
you
take
the
first
content
from
it
out
of
the
accept,
and
then
the
additional
option
would
provide
the
parameters
for
that,
except
and
additional
pairs
of
all.
C
D
Thomas,
I
had
a
few
comments
on
on
the
actual
options,
as
they
are
defined
in
section
four
and
five.
Yes,
so
on
the
first
one.
Maybe
it's
just
worth
adding
a
note,
because
if
it
is
only
about
the
the
original
content
format
with
no
additional
parameters
to
add,
then
it
should
really
be
about
using
the
original
content
format.
Option
right.
D
Yes,
yes,
yeah,
because
the
new
one
would
be
just
inefficient,
so
maybe
it's
even
worth
should
a
normative
should
right
because,
okay,
yes,
yes,
you
never
know
you,
may
you
may
hit
a
server
that
doesn't
even
support
any
option.
Well,
you'd
be
just
fine,
yeah,
okay
and
on
the
second
option.
Instead
as
understanding
you
may
want
to
use
it
to
indicate
multiple
content
formats,
as
they
were
defined
originally
with
no
new
parameters
right,
but
based
on
the
on
the
data
model,
then
you
have
well
the
outer
array,
including
multiple
arrays,
with
one
element.
D
C
C
D
B
B
Well,
maybe
we
can
start
if
you
thomas
have
to
drop
at
top
of
the
hour
but
yeah.
Maybe
I
can
do
a
quick,
quick
summary
of
I
hear
a
bit
of
echo.
I
don't
know
where
it's
coming
from
so
I
I
sent
this
last
call
for
comments
on
version
7
and
what
I've
heard
until
now
or
yeah
until
today
is
that
there
was
rough
consensus
for
keeping
the
appendix
and
the
main
body
of
the
document
together.
B
That
made
me
think
that
maybe
we
want
to
no
obviously
not
in
this
document,
but
to
make
it
even
more
clear.
We
could
think
about
adding
like
a
note
about
that
tag,
saying
deprecated
or
something
like
that
in
the
registry-
and
I
think
maybe
that's
that's
a
job
for
the
notable
tags
document.
That's
an
aside
and
custom
feel
free
to
jump
in
and
disagree.
If
you
don't
think
that
I
just
thought
that,
because
the
conversation
was
a
bit
unclear
so.
A
A
I
I
didn't
really
want
to
to
push
this
into
the
internet
draft
repository
yet,
but
it's
on
the
github
github
repo.
So
if
you
are
interested
in
internationalization,
please
have
a
look
at
the
the
notable
tags
document,
but
I
think
we
can
evolve
that
separately
from
from
this
document,
and
martin
actually
took
a
first
look
at
what
I
wrote
and
and
seem
to
think
that
this
was
the
the
right
direction
forward.
A
So
I
think
we
are
making
some
progress
there
as
well,
and
I
think
we
have
a
more
general
issue
about
tag
evolution
that
just
comes
up
in
a
completely
different
place
again,
where,
where
somebody
is
lamenting
that
the
existing
multi-dimensional
array
tag
is
limited
to
exactly
the
arrays
that
are
defined
in
that
spec
and
he
wants
to
actually
add
a
couple
of
array
types
and
do
we
really
need
to
define
a
new
tag
for
that
or
not?
I
think,
that's
a
discussion
we
have
to
have
over
in
the
sibo
working
group.
B
Yeah,
I
also
wanted
to
underline
one
comment
that
has
come
up
a
couple
of
times
that
was
not
really
answered
in
the
mailing
list,
but
the
fact
that
this
tag
tag
38
is
the
fine.
With
these
I
mean,
I
think
you
said
it
carson,
but
it
was
never
really
like
agreed
in
the
middle
east.
I
think-
or
I
missed
it-
that
there
was
there
was
some
comments
about.
B
B
A
B
E
A
F
A
B
For
example,
when
I
was
reviewing
the
situation
with
tag
35
and
looking
at
you
know
this
deprecated,
there
is
text,
of
course,
about
tag
35
in
8949,
but
that
text
is
not
it's
not
like
linked
from
the
ayana
registry,
so
kind
of
to
find
that
text
you
kind
of
have
to
like
do
a
long
tour
around
the
documents
and
so
maybe
like
yeah.
The
notable
tags
can
deal.
B
Maybe
so
my
suggestion
would
be
the
notable
task
to
take
a
look
at
the
iona
registry
and
possibly
possibly
update
the
registry
in
a
way
that
it
adds
maybe
a
column
for
notes
or
column
for
like
applicability,
usability
or
something
like
that.
So
it
can
also
have
references
to
other
documents,
not
only
the
one
where
it
was
initially
defined.
B
B
B
C
A
C
C
C
A
Yeah,
I'm
just
trying
to
make
up
my
mind
with
whether
it
would
be
good
idea
to
add
a
pointer
to
that
document.
So
the
the
the
reason.
One
of
the
reasons
why
I
wanted
to
have
this
in
the
notepad
notable
tags
document
is
that
that
text
in
turn
has
tons
of
pointers
to
w3c
documents
that
that
are
snapshots
in
time,
that
that
are
useful
to
consult,
but
that
that
are
not
normative
in
any
considerable
way.
C
A
I
think
the
the
one
interesting
observation
is
that
we
typically
learn
about
that
when
the
tag
has
been
defined
and
has
been
stable
for
a
while
and
has
been
used
in
applications.
That's
actually
the
point
in
time
when
we
can
write
that
text
now
with
tag
38.
We
are
a
little
bit
ahead
of
ourselves
because
that
tag
actually
has
been
around
for
eight
years
already.
A
C
A
C
C
A
D
A
A
B
I
also
wanted
to
just
mention
that
I,
when
I
started
this
one
week
called
for
comments.
I
also
informed
the
rest
of
the
asg
that
there
had
been
updates
following
isu
evaluation,
just
to
make
sure
that
the
ids
had
the
opportunity
of
reviewing
the
changes
since
yeah.
The
document
they
have
reviewed
has
changed,
so
they
I've
gotten
feedback
and
there
is
no
additional
raised
comments
or
blocking
discuss
from
the
ids.
B
So
just
for
your
information,
the
issue
is
fine
with
the
changes,
and
I
think
this
additional
paragraph
is
is
minor
enough,
that
I
don't
think
that
would
be
require
any
more
attention
from
them.
So
I
think
I
will
send
this.
What
I
just
said
now
about
the
summary
about
the
consensus
and
the
asg,
and
I
will
send
this
as
a
conclusion
mail
to
the
very
long
last
call
and
art
and
core
thread,
and
once
you
have
submitted
version
8,
I
will
move
the
document
forward.