►
From YouTube: IETF109-CBOR-20201119-0730
Description
CBOR meeting session at IETF109
2020/11/19 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
A
So
welcome
everybody.
This
is
our
itf-109
seabor
working
group
meeting.
We
only
have
one
hour
today,
so
we
try
to
be
quicker
than
usual.
My
name
is
francesca
palumbini
and
I'm
your
chair
today.
This
is
an
official
itf
meeting,
so
the
note
well
applies
and
by
now
I'm
sure
that
all
of
you
have
seen
this
a
couple
of
times.
A
A
A
A
A
A
A
A
He
started
his
engineering
career
as
a
microsoft
employee
and
continued
continued
contributing
as
an
individual
to
the
atf,
even
after
he
retired,
and
opened
his
winery
august
sellers
after
he
retired
from
microsoft,
teacup
working
on
itf
topics
just
for
the
challenge
of
it-
and
this
was
this-
was
not
his
daytime
job.
This
was
just
one
of
his
passions
and
he
did
it
selflessly
with
no
rewards
in
mind
just
for
the
good
good
of
the
atf.
A
A
In
fact,
jim
agreed
to
co-chair
to
seaboard
in
march
2019,
he
has
helped
progress
a
lot
of
our
documents
forward
and
even
before
then,
as
I
said,
his
participation
and
great
reviews
of
almost,
if
not
all,
of
our
documents
have
been
instrumental
to
progress.
All
the
documents
in
this
working
group.
So
I
like
for
you
to
join
me
and
take
a
moment
of
silence
for
jim.
A
Continue
back
to
our
working
group
documents,
yes
happy
to
report
and
congratulations!
The
author
that
rfc
8943
to
be
has
been,
which
is
in
auth
48
state,
will
be
approved
very
shortly.
It
has
been
approved
by
the
author,
so
it
should
be
published
very
very
shortly
and
thank
you
mike
and
congratulations
to
working
group
and
everybody
for
doing
the
job.
A
A
A
C
C
C
So,
let's
quickly
go
through
maybe
five
of
the
more
interesting
questions
or
six.
First
of
all,
we
we
updated
the
reference
to
c
plus
plus
20..
Now,
why
is
c
plus
plus
20
of
interest
just
because
they
finally
got
rid
of
one
unnecessary
variation
that
was
allowed
by
by
earlier
c
and
c,
plus
plus
document.
C
C
So
we
generated
some
text
that
explains
this
unfortunate
reality
and
people
will
have
to
live
with
that.
If
that
change
is
accepted
and
similar
things
happen
with
monospace,
we
would
like
to
to
write
some
some
things
in
monospace
and
typewriter
font,
for
instance,
things
that
happen
in
the
diagnostic
notation.
But
the
problem
is
the
text
fallback
from
monospace
uses
double
quotes.
So
in
the
text
version
it
looks
like
we
are
notating
a
string
and
and
not
a
reserved
word
from
the
diagonal
segmentation.
So
this
is
really
confusing.
C
So
this
is
the
the
kind
of
problem
we
are
grappling
with
right
now
or,
for
instance,
there
are
now
artwork
and
source
code
and
it
never
has
been
defined
where
exactly
the
boundary
between
the
two
is
and
and
so
on.
And
finally,
as
you
know,
we
have
a
limited
report
repertoire
in
rfcs,
and
so
we
have
to
do
some,
some
weird
things
and
can't
have
proper
minus
signs,
and
so
we
always
have
a
hyphen
where
minus
sign
would
be
needed,
which
can
be
very
confusing
in
the
math.
C
C
C
We
never
got
around
to
actually
replacing
positive
big
numbers
by
unsigned
big
numbers
and
that's
a
change
that
that
we
are
now
proposing,
because
it's
not
the
preferred
serialization
to
have
a
big
num
with
the
value
zero,
but
it
is
possible
and
we
should
make
sure
that
the
statements
in
the
document
are
true.
So
all
this
is
in
the
draft.
C
We
probably
need
another
week
to
do
the
full
reread
that
is
recommended,
so
that
will
probably
be
done
on
black
friday
or
what's
it
called
something
monday
and
of
course
again
you
are
invited
to
to
help
and
do
your
own
full
reread
and
cyber
monday
thank
you
mohit,
and
we
should
be
able
to
finish
all
48
by
the
end
of
the
month.
That's
a
prediction:
not
a
promise,
but
I
think
we
are.
We
have
good
timing
and
just
generally
I'm
currently
impressed
by
the
rfc
editor
velocity.
C
C
C
If
you
know
ascii
112
is
the
ascii
character
p.
There
was
a
comment
that
we
probably
should
do
something
about
ayana
private
enterprise
numbers
and
those
actually
occur
so
often
in
non
ietf
documents.
I
have
been
involved
with
that
that
I
think
this
is
really
a
great
idea
and
structurally
this
looks
like
a
relative
oid,
so
like
tbd110,
but
it
is
understood
to
be
relative
to
one
three
six,
one,
four
one,
which
is
the
the
base
oid
of
ayana
private
enterprise
numbers.
C
So
that
that's
one
big
change,
but
I
think
it
was
not
particular
difficult
to
do.
Then
it
was
suggested
to
to
have
cddl
type
names,
so
the
the
prelude
in
rfc
7049
is
designed
to
never
change.
So
we
cannot
change
the
prelude
here,
but
we
can
simply
suggest
cd
daily
type
names
that
people
could
include
in
their
specifications
so
that
everybody
uses
the
same
type
names
for
them
and
those
are
oid
roid
and
penn.
C
C
C
But
if
you
look
more
closely,
this
is
really
just
prefix
removal
in
byte
strings.
So
there's
nothing
specific
to
oh,
it's
going
on
there.
So
addressing
this
issue
in
this
document
might
miss
a
few
requirements
we
we
have
for
this
control
operator
in
in
other
applications.
So
my
proposal
would
be
to
not
address
issue
3
here
in
this
document,
but
to
move
it
over
to
the
city
control
document
and
add
something
there
that
that
is
like
dot
cat
just
the
other
way
around.
So
so
it's
not
adding
something
to
a
string.
C
C
D
Yes,
hi
carson,
hi,
everyone
yeah,
I
I
love
it,
I
I
was
aware
of
it
and
I
still
love
it
and
I
think
it's
very
useful.
As
carson
said
I
I
think
that
the
removal
of
prefixes
is
everything
in
name.
Spaces
might
need
that
and,
of
course,
beyond
name
spaces.
So
I
see
the
otherwise.
I
think
that's
the
cdi
thing.
Yes
and
it's
it's
somehow
the
I
don't
know
inverse
of
cut,
I
guess,
and
so
yeah
I'm
happy
with
not
having
the
ctdi
in
here.
D
A
C
A
C
C
So
basically,
we
know
that
that
cbo
is
is
more
efficient
than
json
in
most
cases,
but
you
only
get
really
good
zebra
efficiency.
If
the
data
model
is
specifically
designed
for
sibo
and
if
you
just
encode
json.
data
in
sibo,
then
you
get
still
get
much
of
the
redundancy
that
is
in
in
json
documents
and
that
redundancy,
of
course
can
be
removed
by
by
running
deflate
over
the
the
encoded
data
item.
C
But
that
means
that
whoever
wants
to
use
the
data
item
has
to
decompress
it
before
using
it,
and
that
may
be
something
that
a
constrained
node
doesn't
want
to
do
and,
and
maybe
also
a
high
performance
node
doesn't
want
to
do
so.
The
the
alternative
idea,
which
is
not
a
replacement
for
compression
but
just
something
that's
better
than
compression
in
many
cases,
is
to
to
use
sibo
itself
to
do.
Structure
and
prefix
sharing
actually
should
be
saying
fx
sharing
now
by
packing.
C
C
The
other
thing
we
decided
to
actually
was
to
actually
look
at
suffix
sharing
as
well.
So
we
now
have
the
item
sharing
where
we
are
sharing
a
whole
item
like
like
a
json
key
that
occurs
multiple
or
even
a
whole
substructure
that
occurs
multiply,
and
then
we
have
prefix
sharing
and
suffix
sharing,
which
is
sharing
of
prefixes
or
suffixes
of
strings,
but
also
of
arrays
and
even
of
maps.
So
you
can
do
a
lot
of.
C
So
we
essentially
have
four
efficiency
buckets
or
in
some
of
them
only
three
and
it
doesn't
make
a
difference
whether
the
table
setup
restructures
things
within
the
buckets,
but
when
something
is
pushed
over
into
the
next
bucket,
the
the
efficiency
goes
down.
So
that's
something
that
that
should
not
happen
lightly.
C
C
C
So
just
a
reminder
what
these
buckets
were
about
so,
for
instance,
item
references,
references
to
shared
items
there
we
have
16
simple
values:
we
propose
to
allocate
and
one
single
byte
tag
that
gives
us,
depending
on
the
length
of
the
argument:
48
512
and
130
1072,
one
plus
one,
one
plus
two
and
one
plus
four
buckets,
and
similarly
prefix
references
have
various
buckets.
So
the
the
point
here
is
that
a
very
small
documents
probably
can
get
by
with
just
the
very
efficient
buckets.
C
C
C
So
actually
the
the
dictionary
mechanism
could
even
be
application
specific.
So
you
could
have
something
like
in
a
suit
manifest
where
it's
just
clear
from
the
context
where
the
dictionaries
are
so
you
don't
even
have
to
encode
anything,
just
the
fact
that
you're,
using
a
data
structure
within
a
manifest
already
tells
you
how
the
tables
for
that
are
are
set
up.
C
So
I
think
there
is
a
clear
benefit
in
having
that
separation
and,
of
course,
if
we
want
to
export
these
application
specific
parts
into
other
environments,
we
could
even
define
zero
tags
for
the
various
ways
of
doing
these
things
anyway.
The
the
actual
reference
could
be
a
ui
which
is
great
because
it
identifies
something
and
locates
something.
C
C
So
maybe
we
want
to
unify
that
mechanism
a
little
bit,
but
that
is
to
be
discussed
and
third,
there
may
be
iana
registered
dictionaries,
and
these
are
could
be
great
because
the
ayana
reference
could
be
very
compact,
so
the
the
whole
dictionary
reference
could
be
a
single
tag
that
has
been
registered
and
the
tag
implies
a
certain
dictionary
which
of
course,
is
immutable
with
the
registration
of
the
tag.
You
would
define
this
dictionary
once
and
for
all,
but
this
gives
you
a
very
inexpensive
way
to
to
pull
in
a
dictionary.
C
C
C
For
instance,
what
is
the
relative
importance
of
prefix
and
suffix
referencing
and
have
a
reality
check
how
much
of
the
tank
space
we
actually
consume
here?
I
would
assume
that
that
a
lot
of
sibo
data
items
in
the
future
will
use
this.
So
it's
quite
okay
to
be
to
not
be
be
too
frugal
about
them,
but
we
also
don't
want
to
use
half
the
space
or
something
like
that.
C
It's
not
quite
clear
where
the
the
right
delimitation
is
whether
we
put
the
simple
table
setup
scheme
right
into
the
document
that
also
defines
the
referencing,
so
that
would
be
a
batteries
included
version.
You
can
go
ahead
and
use
that
right
away
or
whether
we
give
ourselves
different
timelines
of
father
too.
C
Yeah,
I
would
really
be
interested
in
hearing
on
on
the
list
ideas
where
people
think
that
this
packing
scheme
actually
might
be
beneficial
most
of
the
push
to
to
do.
This
now
came
from
the
suit
working
group,
but
we
are
too
late
for
that,
so
they
will
be
finished
before
we
are
finished,
so
they
they
will
do
something
specific
to
suit,
but
I'm
sure
that
there
are
other
cases
where
this
kind
of
functionality
is
quite
useful
and
it
would
be
good
to
hear
about
those
cases
and
what
specific
requirements
these
cases
might
have.
D
Sure
hi
think
we
coming
from
the
red
space
a
little
bit
there
is
this.
This
indeterministic
chaos
when
a
tester
boots
up
and
things
are
not
in
deterministic
sequence,
anymore,
entropy
hits
and
then
you
need
logs.
One
corner
are
basically
basically
a
very
prominent
case
is
that
you
create
hashes
for
all
software
components
before
executions.
D
On
a
typical,
I
don't
know,
work
desktop
station.
That's
that's
quite
a
lot
of
files
and
all
these
files
on
a
file
system.
All
these
are
then
have
five
paths.
These
paths
could
be
segregated
and
packed.
It's
it's
an
implicit
doubling
of
a
lot
of
these
items.
There
are
structures
like
ghostwood
that
recreate
the
file
tree
structure
to
avoid
this
problem.
If
there
could
be
a
native
thing
that
is
enabling
this
packing
for
a
lot
of
similar,
looking
path,
sequences
here,
so
sequences
of
path
names.
D
But
everybody
is
talking
about
that.
People
talk
about
json
encoding
because
human
readable
and
it
will
be
a
string
in
any
way
because
also
see
what
does
not
provide
a
big
benefit.
If
you
convey
ten
thousand
actual
file
paths
as
a
solid
file
system
paths
and
then
so
that
again
yeah.
That
is
a
relatively
straightforward
thing
here.
I
think.
B
Well
so
predefined
static
dictionaries
is,
is
actually
one
of
the
things
that
would
be
difficult
to
handle
with
a
mime
type,
for
example
right.
Yes,
if
all
of
the
information
is
encoded
directly
in
the
object,
then
all
we
need
to
know
is
that
pax
cbor
is
part
of
the
standard
or
part
of
the
negotiation
right,
because
just
because
I
say
I
can
accept
cbor
doesn't
mean,
I
necessarily
understand
pax
seabor
extensions.
C
Well,
you
could
do
something
like
the
the
profile
parameter
in
html
that
never
took
off
to
to
identify
the
static
dictionary
that
you
are
using.
So
that's
easy
in
the
text
mime
type.
Then,
when
you
think
about
a
coil
solution,
you
need
a
content
format,
identifier
for
each
of
them.
So
there's
another
thing.
You
need
to
register
to
to
make
that
happen,
but
in
many
cases
it
will
just
be
more
expedient
to
to
have
the
data
in
there
once
and
instead
of
repeat
it
all
over
right.
The
place.
C
Yeah,
so
when
we
did
something
similar
for
the
the
sub
protocol
some
20
years
ago,
we
decided
that
we
could
define
an
application,
independent
static
dictionary
and
that
has
been
updated
once
I
I
think
so.
There
are
now
two
versions
of
that
dictionary,
and
that
was
good
enough
for
for
the
the
strings
that
typically
occur
in
sip.
B
C
Yeah,
we
probably
need
some
some
text
about
use
cases
in
in
the
document,
so
people
will
know
which
of
those
various
variants
they
should
apply,
and
we
should
probably
also
need
them
to
filter
the
variance.
So
we
don't
create
a
monster
with
thousands
of
different
configurations
that
don't
interpret.
A
C
A
C
Yeah,
there
are
quite
a
few
documents
that
we
actually
should
be
picking
up
again,
like
the
the
time
tag
which
is
registered,
so
people
can
use
it,
but
we
will
probably
want
to
spend
the
the
effort
to
turn
this
into
a
more
complete
rfc.
At
some
point-
and
I
think
when,
when
we
are
done
with
the
current
slate,
we
really
should
have
one
rounds
through
the
community.
What
what
are
they
are
working
on
so,
for
instance,
the
haskell
people
have
made
a
suggestion.
C
They
actually
have
type
choices
in
haskell,
which
are
not
pure
type
unions,
but
in
encoding
you
actually
encode,
which
of
the
branches
of
the
type
choice
you
have
taken
and
they
need
a
couple
of
tags
and
and
probably
hundreds
of
thousands
of
tags
to
be
able
to
represent
this
for
for
arbitrarily
complex
data,
and
things
like
that
are
coming
up
all
the
time,
and
I
think
we
need
to
get
better
in
picking
them
up
and
so
don't
be
surprised.
If
I
carry
some
of
these
to
the
working
group
in
the
next
couple
of
months.
A
C
A
C
Yes,
so
that
that
is
actually
being
used
in
the
asdf
working
group
and
there
was
a
tiny
extension
to
the
dot
feature
mechanism
that
I
put
into
the
most
recent
draft
forget
what
the
number
was,
and
we
just
discussed,
maybe
doing
something
around
the
dot
cat
which,
by
the
way,
is
now
implemented
together
with
dot
plus
and
the
the
third
area
where
we
do
not
have
an
implementation.
Yet
is
the
ab
abn
f
part,
and
I
would
expect
once
that
is
implemented,
and
a
christmas
tree
is
a
great
environment
to
to
implement
this.
C
A
A
A
A
A
E
A
Okay,
good,
I
will
make
sure
to
check
with
you.
I
don't
really
want
to
go
through
the
whole
effort
of
of
the
poll,
because
it's
not,
I
don't
think
it's
good
representation
of
participants
anyway,
but
I
I
might
do
that,
but
I
was
just
hoping
that
today
we
might
agree
on
it
and
then
confirm
that
in
the
main
list
to
make
sure
that
nobody's
left
out-
and
yes,
the
interim,
I
would
say-
would
resume
after
new
year,
because
there
is
a
bunch
of
celebration
and
holidays
coming
up.
E
E
A
C
C
Application
is
now
in
an
iso
icdis
stage,
which
means
it's
technically
stable
and
sea
walls
in
there,
and
I
think
other
components
that
from
the
iitf
are
in
there,
and
I
think
it
would
be
good
for
us
to
actually
watch
this
and
and
learn
about
how
sibo
is
used
by
by
other
people.
I
think
they
they
also
use
cddl,
so
I
think
they
they
really
have
taken
the
whole
package.