►
From YouTube: CBOR WG Interim Meeting, 2021-06-02
Description
CBOR WG Interim Meeting, 2021-06-02
A
There
is
a
few
items
on
the
agenda
for
today.
First
is
documents,
document
steps
and
updates,
and
then
we
emil
asked
that
we
talked
about
the
map
like
data
proposal,
on
which
carson
would
give
an
update,
and
there
is
this
new
proposal
around
that
came
out
of
the
file
magic
discussion
that
we
could
have
allocations
for
content
format
and
also
custom
will
close
a
bit
there
on
the
top.
Any
things
that-
and
you
want
to
put
on
the
agenda
on
short
notice.
A
So,
let's
go
ahead,
then,
with
text
oid
text
oid
is
now
with
the
rfc
editor,
so
there
is
basic.
Basically,
things
will
run
from
will
be
driven
from
from
them
from
there
on,
and
I
don't
yeah,
but
I
haven't
heard
back
from
rfc
editor,
but
at
least
the
the
allocations
are
already
through
with
diana,
so
things
are
progressing
on
cdl
control.
A
You
probably
noticed
that
I
sent
out
a
working
group
last
call,
even
though
we
didn't
really
get
any
recent
reviews.
This
is
based
on
the
observation
that
some
people
only
start.
Some
people
seriously
start
reviewing
documents
when
a
working
group
last
call
starts,
but
this
also
means
that
we
need
reviews.
So
if
ev
every
everyone,
especially
who
is
not
an
author
or
not
a
document
shepard,
because
I
will
be
doing
a
shepherd
review
anyway
later
on.
Please
look
at
this
document.
A
Please
review
it
because
this
will
be
the
base
for
the
later
chatbot
right
up
carson.
You
mentioned
that
there
is
the
asdf
meeting
later
on.
So
if
you
could
con,
if,
if
we
don't
find
people
around
here,
it
might
be
a
possibility
that
we
can
get
some
feedback
from
downstream
from
downstream
to
given
that
asdf
is
depending
on
this.
B
If
I
briefly
make
my
my
observations
known
and
there
is
a
little
bit
of
a
little
trap
that
we
are
setting
up
with
a
feature
control,
so
I
of
course
I
immediately
ran
into
it.
So
if
I
say
this
is
feature
1.1,
I
sometimes
write
the
floating
point
number
1.1.
Instead
of
the
string
1.1,
and
that
creates
some
confusion.
I
think
that
that's
mostly
a
tools
issue.
A
B
All
well,
we
only
have
operators
with
two
arguments
in
okay,
yeah
cdn,
so
yeah.
We
might
want
to
think
about
adding
different
numbers
of
arguments
there.
But
that's
what
we
have
at
the
moment
and
right
now
it
only
dedants
the
right
hand,
side,
and
it
actually
turns
out
that
in
real
life
specifications,
then
you
have
to
do
more
gymnastics
than
if
it
did
end
at
both
sides,
and
you
always
can
use
combinations
with
empty
springs
to
to
limit
the
extents.
B
B
B
A
Then,
let's
proceed
with
the
brief
touch
on
the
on
the
file
magic
and
network
addresses,
so
on
the
and
I
mixed
those
up
in
the
comments.
So,
let's
start
with
the
network
addresses
there
is.
There
is
one,
the
one
issue
that
was
discussed
on
the
waiting
list,
not
even
some
recently
on
the
on
whether
we
need
something
additional
for
for
addresses
that
contain
that
that
include
a
net
mask
michael.
If
I
understood
you
correctly,
it
was
a
matter
of
yeah.
A
A
Okay,
so
my
understanding
of
this
document
is
that
the
author
is
pretty
happy
with
the
general
state,
so
we
could
in
the
end
we
could.
We
could
state
at
some
point
basically
there's
the
question
of.
Is
there?
Is
there
anything
within
the
working
group
that
would
we
would
like
to
add
or
change
to
this,
because
otherwise
we
can
send
this
on
the
way
to
being
done.
A
B
D
A
C
A
A
B
B
So
co-op
has
these
16-bit
ids
for
media
types
that
are
likely
to
occur
in
in
quebec
documents
and
graph
interchanges,
and
those,
of
course,
are
also
likely
to
occur
in
zero
data
items,
and
you
can
always
define
new
ones.
So
16
bits
is,
there
are
some
8
000
media
types
defined
in
in
the
iona
register
right
now,
so
we
we
have
space
anyway.
B
So
the
the
idea
is
to
allocate
a
range,
a
16-bit
range
of
tank
numbers,
and
this
is
one
billion
six
hundred
sixty
eight
million
five,
forty
six,
five
sixty
to
the
same
thing,
plus
sixty
five
thousand
five,
thirty
five,
and
once
we
have
allocated
these
things,
then
we
can
do
things
like
tag,
something
as
thing
description
plus
json,
which
is
a
media
type
that
has
content
format.
Number
432
so
use
just
using
this
tag.
Number
would
identify
this
as
a
thing
description,
plus
json
or
last
slide.
B
In
the
second
example,
we
use
the
application
json
in
deflate
encoding
content
format,
so
we
kind
of
form
it
not
only
has
a
media
type.
It
also
has
a
content.
You
can
have
a
content,
encoding
and
json
is
often
compressed
and
we
have
a
content
format
number
allocated
to
to
deflate
compressed
json
so
that
that's
all
there
is
not
much
more
context
here
and
I'm
wondering
my
main
problem
with
this
is
that
it's
too
small
for
for
a
document
to
push
through
the
isg.
B
We
don't
even
have
to
have
the
document
approved
to
allocate
these
numbers.
So
if,
if
we
decide
this
is
the
the
right
thing
to
do,
then
we
should
just
go
ahead
and
register
them
and
start
using
them
and
yeah.
Then
it's
not
so
important,
which
document
this
finally
is
attached
to
as
long
as
the
draft
is
out
there
for
for
that
period,
any
comments.
D
B
A
The
the
tags
from
from
the
self
from
the
from
the
file
magic
document
usually
applied
to
the
see
kind
of
are
packed
around
the
the
internals
of
the
of
the
cedar
or
document
that
is
they
take
and
they
take
an
enemy.
And
if
that,
if
that
format
happens,
to
be
defined
as
b
string,
but
most
simple
formats
are
not,
and
then
it's
b
string,
but
usually
it's
an
any
your
examples,
all
show
b
string,
which
kind
of
makes
sense
with
deflate.
A
A
B
So
byte
string
is
really
the
only
tag
content
that
makes
sense,
but
one
might
want
to
make
an
exception
if
it's,
if
it
happens,
to
be
a
text
string
like
with
json.
If
you
go
back
to
example,
one
then
of
course
the
the
question
is:
why
is
that
td
plus
json
actually
encoded
as
a
byte
string,
but
it
is
because
representations
in
in
the
media
types
we
have
are
usually
byte
strings,
the
the
few
other
cases
seven
bit
and
eight
bit
really
don't
make
sense
in
2021.
A
Or
phrased
differently,
that
someone
could
go
along
and
register
all
those
kind
of
do
the
same
work
again,
but
for
the,
but
with
the
with
the
tag,
meaning
the
same
thing,
but
for
the
decoded
form,
which
would
then
be
more
aligned
with
file
magic
and,
of
course,
only
make
sense
for
any
content
format.
That
is
an
a
plus
c
is
a
plus
c
board,
and
not
for
all
the
others
and
would
be
kind
of
indistinguishable
between
plus
c
or
inc,
with
deflate
encoding
and
plus
c,
with
identity,
encoding.
B
D
A
C
A
D
B
So
we
have
this,
this
long
running
discussion
about
map
like
data
and
tags
for
those
in
in
sibo
and
next
slide.
We
have
a
current
proposal
which
essentially
provides
the
number
of
knobs
non-ordered.
This
is
ordered,
whether
duplicate
keys
are
provided
for
allowed
and
whether
keys
or
maybe
even
keys
and
values
are
homogeneous
and
next
slide.
This
leads
to
to
this.
B
These
12
tag
allocations,
and
this
is
pretty
much
stable.
So
what
what
we
maybe
want
to
hone
a
little
bit
is
our
discussion
of
how
existing
tags
that
address
similar
problems
relate
to
what's
in
here.
So
this
is
meant
to
replace
the
proposals
to
the
the
tags
that
were
proposed
to
be
279
and
280,
and
it's
related,
but
not
entirely
replacing
259
and
275.
B
B
So
the
the
fact
that
there
are
related
tags
that
that
are
not
entirely
subsumed
by
this
might
be
considered
a
diagnostic
that
this
proposal
isn't
really
covering
all
bases
but
yeah
the
the
those
tags
are
different
because
they
they
address
certain
differences
in
existing
platforms
and
those
differences
are
bizarre.
So
it's
it's
not
surprising
that
they
don't
exactly
fit
the
the
ordered
structure
that
that
we
have
come
up
with
here.
B
B
So
c-bar
has
maps
which
are
essentially
arrays
with
a
bit
set,
which
says
that
the
the
elements
of
the
array
actually
are
alternating
keys
and
and
values,
and
the
the
representation
that
we're
using
here
is
essentially
that
representation.
But
with
that
with
not
set
because
with
it
said
it
would
just
become
a
normal
c
bar
map,
so
we're
using
an
array
with
alternating
key
and
value
entries
or
elements,
and
so
this
this
is
not
the
traditional,
a
list
that
that
people
who
do
lisp
may
know.
B
B
B
B
Now,
that's
great,
but
of
course
it
costs
one
array
head
per
key
value
pair,
one
byte
per
key
value
pair.
So
next
slide.
Now
we
can
start
trying
to
optimize
this
so
yeah.
We
either
can
assume
that
we
never
have
arrays
as
values.
Then
we
can
use
the
om
list
form
or
we
can
actually
do
something
special
if
v
is
an
array
which
is
what
the
oem
list
here
does.
B
B
Obvious
that
that
the
values
are
to
be
taking
a
trace
value
or
you
have
a
value-
and
that
happens
to
be
an
array,
then
you
put
it
into
a
single
element
array
and
if
the
value
is
not
an
array-
and
you
only
have
one
of
them,
then
you
actually
can
put
the
whole
thing
right
by
the
the
key.
So
it's
as
efficient
as
the
the
original
form
for
keys
and
values
that
that
are
not
duplicate
and
they're,
not
arrays,
and
then
we
have
various
optimizations
and
pessimizations
for
various
forms
of
content.
B
B
B
So
this
optimization
comes
with
further
strings
that
get
attached
to
the
information
model,
fortunately
not
on
the
homogeneity
side,
but
on
on
the
ordering
and
the
duplicate
side,
so
that
that's
maybe
the
reason
why
we
never
got
around
to
actually
handling
these
representation
optimizations
and,
of
course,
one
one
decision
we
could
make
is
yeah.
We
know
that
this
can
be
done,
but
this
is
outside
the
scope
of
the
the
current
map,
like
data
proposal,
or
we
could
actually
embrace
one
or
more
of
these
representation
variants.
B
A
B
B
So
that
does
happen,
but
it's
not
the
usual
way
of
of
doing
things,
so
your
protocol
probably
would
pick
136
and
say
this
is
the
the
tag
that
you
are
using,
so
that
that's
about
the
information
model
side
which
this
slide
is
about.
On
the
representation
side,
I
think
we
we
are
not
going
to
get
rid
of
fa
list,
because
that's
just
the
the
simplest
way
to
do
this,
so
the
the
question
is
essentially.
B
B
Yeah
one
problem,
of
course,
is
that
it's
hard
to
discuss
this
when
the
main
use
case
we
had
in
mind
when
we
discussed
this,
which
was
the
the
yang
zebra
use
case,
has
decided
to
do
this
in
a
different
way,
but
it's
very
likely
that
that
other
use
cases
will
come
up
in
in
actual
protocol
specifications.
So
I
I
don't
think
it
was
a
fluke
that
we
came
up
with
this
in
the
young
zebra
case.
B
A
B
Well,
corp
options
also
have
data
encoding,
which
is
yet
another
optimizations
minimization.
So
I
didn't
even
discuss
this
very
much
on
on
the
slide.
But
of
course,
if
you
have
ordering
at
the
representation
level,
then
you
can
put
data
encoding
on
top
of
that,
and
that
gives
you
an
essentially
non-ordered
information
model,
because
you
have
to
to
sort
your
your
co-op
options
in
order
to
be
able
to
use
the
data
encoding.
B
B
B
Yeah,
if
we
don't
see
a
pressing
need
to
address
the
optimized
versions,
of
course
these
can
be
added
later,
so
we
don't
don't
have
to
do
them
now,
and
we
can
just
finish
with
the
12
tags.
We
have
defined
right
now
and
complete
the
document
and
address
the
the
optimizations
when
we
have
the
next
use
case
that
needs
them,
which
of
course
makes
it
slow
to
actually
have
that
use
case.