►
From YouTube: CBOR WG Interim Meeting, 2021-01-27
Description
CBOR WG Interim Meeting, 2021-01-27
A
A
This
is
the
first
time
I'm
doing
this
in
a
rule,
as
as
working
group
co-chair
moderating
this
one
administrative
point,
I'd
like
to
bring
up
is
to
congratulate
francesca
on
having
on
being
the
next
area
director
for
us
taking
over
from
barry.
So
thanks
barry
for
doing
this
and
for
the
time
you've
done
it
and
welcome
francesca
and
congratulations
relations
in
europe,
which
unfortunately
also
means
that
I.
A
A
The
other
thing,
the
other
topics
for
today
are
working
implementation
survey.
This
is
something
that
michael
can
then
say
a
bit
about
it.
Basically,
a
follow-up
from
the
last
meeting
and
the
other
topic.
That's
not
on
the
agenda
yet,
but
came
in
on
short
notice
is
paxibor
with
potentially,
if
we
have
time
for
it.
The
third
item
of
the
other
male
carson
sent
in-
and
I
don't
find
on
my
screen
right
now-
also.
B
D
D
Yep,
okay,
so
this
is
really
the
crux
of
what
I'm
thinking
about
is
that
that
this
is
something
that
I'd
like
to
go
and
see
boar
dot.
Io.
I
think
if
you
know
carsten
agrees,
I
don't
think
this
is
intended
to
be
an
rfc,
but
maybe
maybe
we
would
want
to
draft
part
of
it
in
the
form
of
an
internet
draft.
I'm
not
sure
about
that.
D
So
so,
what's
the
purpose
of
this,
in
my
mind
my
mind
is
that
when
I
went
through
just
pick
some
implementations
a
couple
weeks
ago
to
work
to
work
with,
I
found
that
I
I
really
had
to
get
well,
I'm
gonna
say
very
deeply
into
implementations.
There's
quite
a
few.
Some
languages
have
quite
a
few
implementations
and
they're,
really
not
all
equivalent.
D
So
if
you
made
a
video
game
in
rust,
let's
say,
and
you
wanted
to
make
a
save
file,
a
self-describing
save
file
and
then
you're
going
to
reload
it
later
on.
This
would
be
a
great
thing
because
it
would
allow
you
to
serialize
any
structure
that
you
could
define
in
rust,
but
the
results
would
be
in
some
rust-defined
sebor
protocol
right.
So
if
you
tried
to
build
a
cddl
for
it
or
something
like
this,
you
probably
would
find
that
it
was
unstable,
but
it's
self-describing.
So
it
would.
D
I
don't
know
what
happens
when
you
upgrade
your
game.
I
don't
know
if
you
wind
up
with
free
upgrades
to
your
save
files
or
not,
but
in
any
case,
if
your
purpose
was
then
to
send
the
save
file
across
the
internet
and
reload
it
into
a
version
written
in
c,
sharp
you're,
probably
out
of
luck
because
it
probably
doesn't
have
any
kind
of
stable
facility.
D
So
that's
that's
the
kind
of
thing
that
I
would
like
to
get
into
the
survey.
I've
also
been
through
a
couple
of
c
implementations,
because
I
actually
have
some
c
code
and
some
rest
code
that
need
to
interoperate,
surprise,
surprise,
and
so
I
I
kind
of
went
down
some
of
the
same
space
again.
So
what
I'm
hoping
to
do
is
kind
of
describe
these.
Not
I
don't
want
to
judge
them
because
they
have
different
purposes,
but
I
think
it's
really
important
for
us
to
understand.
D
Yeah
there's
a
lot
of
implementations
out
there,
but
in
fact,
in
some
cases,
there's
six
implementations,
none
of
which
do
what.
I
think
that
many
people
in
this
working
group
would
expect
them
to
do
because
they
all
cover
a
different.
A
different
different
part
of
the
elephant-
if
you
know
the
analogy,
so
I
think
that
part
of
the
things
that
we
part
of
the
questions
I
would
I
intend
to
ask-
is
so,
for
instance,
like
tags,
for
instance,
does
that
are
they?
D
D
And
some
implementations
are
tolerant,
but
they
don't
give
you
tags,
but
no
user
interaction,
so
you
put
whatever
tags
you
like,
but
it
just
it
doesn't
do
anything
with
them.
It
just
skips
them.
No.
How
about
no
api
interaction?
So
that's
something
that
I
that
I
think
is
very
different
among
things
another
another
one
is
is
floating
point.
For
instance,
it
can
be
supported
mandatory
and
then
we
have,
you
know,
half
versus
full
or
double.
D
I
guess
support
so,
for
instance,
many
embedded
people,
they
might
say.
I
have
no
use
for
floating
point.
I'd
really
like
to
be
able
to
compile
it
out
and
some
some
libraries.
This
is
not
a
problem
and
some
of
them.
If
you
don't
use
any
floating
point
well,
then
the
code
is
arranged
such
that
the
linker
probably
doesn't
include
any
and
others
don't
have
that
problem.
You
have
to
explicitly
compile
it
out.
D
So
that's
something
I
would
like
to
get
at
and
then
there's
I
there's
a
lot
of
of
variability
in
decode.
We
obviously
have
pull
parsers
that
people
have
described.
Okay,
we
have
sacs
like
parsers,
where
you
get
a
callback
per
thing
and
then
we
have
ones
that
are
like
get
next
object,
and
then
we
have
ones
that
roll
your
own
right.
So
they
they
basically
provide
decoders
for
all
the
major
types
and
that's
it.
D
D
B
You
you
know
that
what
the
non-allocating
parser
is
and
then
what
an
allocating
browser
is,
and
you
have
dom
and
and
event
and
pull
type
parsers
and
so
on
and
so
on,
and
then
based
on
that
draft,
we
can
actually
do
a
survey
and
ask
you,
but
where
do
you
put
your
implementation
or
is
your
implementation?
Maybe
something
that
really
requires
modifying
that
draft
once
more.
D
D
That
sounds
reasonable.
The
other
thing
I
want
to
ask
is:
I
want
to
know
what
to
do
with
with
implementations
where
they,
where
I
don't
get
responses
or
where,
like
there
are,
there
are
what
appear
to
be
sometimes
active,
github
code
repositories
with
pull
requests
that
are
say
less
than
six
months
old,
but
no
actual
activity
for
more
than
that
time.
So,
in
other
words,
there's
people
that
that
would
like
to
contribute
to
it,
but
they
are
if
they
aren't
able
to
and.
D
D
D
Closed
pointer
loop
of
please
don't
use
this
implementation,
use
that
one
and
you
go
around
the
loop
and
you
realize
that
that
it's
not
going
to
work.
You
have
to
pick
one
of
them
or
you
have
to
make
your
own.
I
guess
so.
I
don't
know
what
to
do
about
that.
As
far
as
you
know,
from
a
political
point
of
view,
I
want
to
be
inclusive,
but
I
also
don't
want
to
put
inaccurate
or
dead
information
into
this.
A
D
E
D
E
D
D
D
D
E
D
B
D
D
A
A
B
But
I
think
the
the
most
important
change
between
0,
0
and
0
1
is
that
the
draft
now
has
a
clear
split
between
the
unpacking
operation,
which
is
really
the
part
that
that
needs
to
be
rock
solid
and
standardized
and
be
part
of
as
many
sibo
libraries
as
possible
and
the
table
setup
part
that
will
always
be
a
little
bit
more
application
specific
and
we
will
have
some
application,
specific
static
dictionaries
and
and
all
that
stuff.
So
the
the
intent
with
the
current
draft
is
to
to
have
a
clear
separation
between
those
two.
B
The
other
changes
which
are
in
part
quite
significant,
have
to
do
with
adding
suffix
packing.
Oh
zero.
Zero
only
had
prefix
packing
item
sharing
and
prefix
packing,
so
we
now
have
added
suffix
packing
and
are
calling
the
whole
thing.
Ethics
packing.
If
we
don't
care,
whether
it's
prefix
or
suffix,
and
the
other
thing
is
that
both
for
suffix
and
for
prefix
packing,
we
specify
how
to
apply
them
to
containers.
B
So
that's
an
overview
next
slide,
so
adding
suffix
packing
is
is
well
kind
of.
Obviously,
what
you
need
to
do,
but
doing
this
in
a
naive
way
would
mean
that
we
we
allocate
the
same
number
of
tags.
We
have
allocated
for
the
prefix
part
for
the
suffix
part
and
that
that
creates
a
little
bit
of
cognitive
dissonance
for
me,
and
my
hunch
is
that
prefix
packing
is
actually
way
more
important
than
suffix
packing
and
I'm
really
looking
forward
to
be
corrected
on
this.
B
B
So
there
are
a
lot
lots
of
not
so
interesting
but
detailed
and
and
in
the
end,
probably
important
decisions
that
that
have
to
be
made
here
and
I'd
rather
do
those
based
on
a
corpus
than
based
on
hunches
so
creating
a
corpus
of
sibo
data
items
that
we
want
to
work
well
with
sibo.
Packing
is
probably
an
important
next
step.
B
B
B
A
D
Yeah,
imagine
you
had
a
seabor
protocol
that
was
processed
through
a
series
of
steps.
It
starts
off
really
well
compressed,
and
then
you
know
things
get
changed
in
the
data
in
the
in
the
rump
and
at
some
point
it
turns
out
the
rum.
The
compression
provides
no
value
whatsoever
and
that's
unfortunate,
but
it,
but
it
was
cheaper
to
do
that
than
bother
fixing
the
rest
of
it
or
figuring
it
out.
D
B
B
So
it's
32,
plus
4096,
plus
a
number
that
I
have
no
idea
where
it
came
from.
It's
probably
2
to
the
18
or
something
like
that.
I
have
to
look
it
up
again,
so
yeah.
That
needs
some
some
more
thinking,
but
I
thought
before
I
I
put
energy
into
that
thinking.
I
should
have
a
corpus
to
look
at
so
that
that's
just
a
reminder
from
last
time.
Next
slide.
B
So
going
to
the
table
setup
again,
I
hope
that
the
the
actual
packing
can
get
stable
relatively
soon
and
the
the
table
set
up.
One
we
want
to
do
should
be
simple,
and
we
should
keep
in
mind
that
there
will
be
application,
specific
versions
of
that,
and
we
need
to
provide
a
framework
for
the
table
setup
because
yeah,
otherwise,
the
the
actual
unpackers
will
need
to
to
be
very
different
for
for
each
of
those.
So
we
should
give
some
guidance
for
how
this
table
setup
stuff
works.
B
So
basically,
what
what
I'm
proposing
here
is
that
in
a
c-bar
structure
for
for
every
data
item
in
there,
so
the
the
total
data
item
and
all
the
sub-trees
there
is
a
table
set
up.
That
applies
to
that
data
item
and
normally
it
just
inherits
through
the
the
tree
and
the
default
table.
Setup,
of
course,
is
three
empty
tables.
B
Actually,
if
there
is
any
reason
to
put
something
there
that
that
is
really
useful
for
any
kind
of
sibo,
then
we
could
do
it
in
the
default
put
it
into
the
default
table,
but
I
didn't
find
anything
for
that.
But
maybe
again,
that's
just
lack
of
imagination,
so
there
is
a
default
table
setup
and
then
I
expect
that
that
different
application
environments
will
define
different
table
setups
that
that
are
applied
to
the
root
of
the
data
items
defined
by
the
the
media
types
for
the
application
environment.
B
B
So
if
the
the
media
type
says
you
have
these
five
keywords,
you
would
be
able
to
put
in
another
set
of
keywords,
and
that
would
be
prepended,
so
it
would
get
the
better
places
and
yeah
there
is
some
there.
There
are
some
ideas
how
to
do
this
differently,
but
the
the
basic
approach
and
the
one
used
by
this
basic
practice
would
be
to
always
prepend
them,
because
the
specific
document
specific
data
item
knows
better
how
to
use
these
than
the
the
static
actually
provided
to
it.
B
B
So
one
thing
we
we
did
next
slide.
One
thing
we
did
discussed
last
time
was
that
actually
there
are
not
increasingly
worse
positions
in
that
number
of
space,
but
we
have
different
buckets
so
the
first
16
numbers
are
actually
all
the
same,
and
then
the
next
48
are
all
the
same
in
the
next
5
12
are
all
the
same
and
so
on.
So
maybe
there
is
a
good
reason
to
actually
use
this
structure
to
define
alternative
insertion
points,
so
you
don't
necessarily
insert
at
the
start.
B
What
I
would
like
to
do
next
is
look
at
this
one
draft
answer
the
issues
that
are
in
there
and
and
generate
a
02
and
then
see
whether
we
actually
can
use
that
already
or
whether
we
need
to
cook
it
some
more.
So
my
hope
would
be
that
we
can
cook
this
without
completing
the
definition
of
all
application,
specific
tags
that
we
will
ever
need
to
define
for
for
packing.
B
Unfortunately,
they
had
to
define
define
their
own
little
application
specific
scheme
for
this,
because
we
were
too
late
with
this,
but
then
in
other
application
environments
that
need
this.
We
would
also
start
discussion
about.
How
would
we
apply
this
here?
Is
this
something
that
you
you
even
want
to
have
in
that
application
environment?
B
C
B
D
D
C
D
D
D
B
B
D
D
Okay,
I
forgot
that
the
simple
values
was
not
what
was
that
that
part
and
that
there's
a
bunch
of
unencoded,
so
that's
major
type,
seven
right.
So
that's
what
I
forgot
that
it
was
called
that
there
was
floating
point
numbers
and
simple
values,
and
so
we
had
a
four
byte
four
bits
of
of
unallocated
space
there.
D
A
That
that
already
sets
a
few
good
action
points
on
the
on
the
topic
of
what
to
talk
about
next
is
there
I
mean
discriminated
unions
are
still
on
the
list.
Do
you
think
that
there
is
much
more
to
be
gained
from
continuing
this
discussion,
because
otherwise
I'd
suggest
to
move
on
to
the
discriminated.
A
B
Well,
I'll
take
all
feedback
I
can
get
for
this,
so
my
plan
is
to
have
a
next
version
of
this
draft
pretty
quickly.
So
please
keep
those
pull
requests
coming
and
then
maybe
it
should
be
easier
to
read
and
we
can
circulate
it
a
little
bit
more
widely,
so
people
can
can
application
developers
can
can
start
commenting
on
it
and
so
on.
E
E
B
B
F
B
Yeah,
so
this
is
one
of
the
the
items
that
came
in
from
implementers
and
actually
it's
a
good
example
of
the
usage
of
sibor
in
a
language
environment.
So
just
as
michael
you,
you
mentioned
surgery
in
in
rust,
there
are
other
people
who
are
using
sibo
for
their
language.
Runtime
support
and
many
language
environments
actually
need
something
like
this,
and
traditionally
they
all
have
defined
their
own
things.
B
B
This
need
for
a
discriminated
union,
so
they
actually
came
a
while
ago
that
they
needed
a
time
tag,
and
this
is
what
turned
into
tag
1001,
and
we
already
have
tag
27,
which
was
motivated
by
pearl
and
so
on,
so
that
that's
going
to
be
a
sub
genre
of
of
sibo
attack
development,
making
sure
that
language
environments
can
do
something
useful
with
sibo.
So
this
is
not
coming
from
the
protocol
development
side,
but
from
the
language
environment
site
next
slide.
B
Some
address
component
can
be
a
house
number
or
a
post
office
box
number.
It
doesn't
help
you.
You
need
to
discriminate
the
various
branches,
the
various
alternatives
of
that
union.
That's
where,
where
discriminators
come
in,
if
we
actually
write
protocols,
then
we
usually
define
labels
for
those
discriminators,
so
we
often
set
up
maps
and
discriminate
the
various
cases
by
by
having
different
labels,
but
that's
not
necessarily
what
you
would
find
in
a
programming
language
and
what
we
have
on
slide.
Four
here
is
an
example
from
a
programming
language,
and
I
think
that's
haskell.
B
Actually
I
haven't
checked
that,
but
it
looks
very
much
like
haskell,
so
here
we
have
a
type
called
exper,
and
this
actually
is
a
discriminated
union
with
six
branches
and
the
terms
lit
at
subnet
maldive
are
actually
the
discriminators,
so
they
identify
which
of
the
the
choices
are
actually
taken
and
the
the
things
behind
that
the
in
explorer
explorer
and
so
on.
These
are
the
the
content
of
the
discrimination.
B
So
that's
the
data
that
come
with
that
specific
choice.
So
that's
what
the
haskell
compiler
would
see
as
input
and
next
slide.
The
after
compiler
really
would
like
to
translate
this
into
something
like
this,
where
you
have
discriminators
that
look
like
tags
which
are
put
on
the
actual
parameters
for
that
specific
alternative.
So
you
would
have
tag
zero
for
the
the
lit
case
and
take
one
for
the
add
case
and
so
on.
B
So
there
is
no
point
in
carrying
lich
and
and
edge
and
so
on
as
strings,
because
this
is
all
done
by
a
compiler
which
knows
what
what's
going
on
here.
So
we're
not
going
to
do
the
the
json
thing
here
and
actually
yeah.
We
really
would
like
to
have
integers
here
in
a
tag
like
a
construct
and
if
this
looks
familiar
after
looking
at
zebra
pack-
yes,
this
is
kind
of
familiar,
but
it's
a
very
different
application.
B
So,
of
course,
if,
if
we
ever
come
into
a
situation
where
we
would
define
a
protocol,
we
would
probably
define
tags
for
additional
subtraction
and
so
on.
But
again
this
is
the
compiler.
The
compiler
doesn't
want
to
reach
out
to
ayanna
and
register
these
tags.
The
compiler
just
wants
a
pool
of
tags.
It
can
use
next
slide.