►
From YouTube: CBOR WG Interim Meeting 2020-10-28
Description
CBOR WG Interim Meeting 2020-10-28
A
A
A
Okay-
and
this
is
the
agenda
for
today,
so
we
have
a
short
working
group
update
with
some
sad
news
and
some
more
happy
news.
Well,
then,
we
will
talk
about
the
document
working
group
document
status,
especially
the
oi
tags
and
the
new
proposal
dictionaries
and
any
other
business
that
we
want
to
discuss.
A
A
This
is
a
picture
from
march
2017
at
the
itf.
I
really
like
this.
I
had
to
go
into
the
archives
and
to
find
it,
and
I
hope
that
I
I'm
not
breaking
any
copyright
or
anything
by
posting
it
here
yeah.
I
just
wanted
to
say
a
few
words.
Jim
has
been
a
pillar
of
the
idea
for
a
very
long
time
and
he's
been.
A
A
A
I
know
that
many
people
here
have
seen
these
greater
views
very
to
the
point
and
yeah
jim
agreed
to
co-chair
this
working
group
seabor
in
march
2019,
and
he
has
helped
progress,
are
working
working
group
documents
forward
and
even
before
that,
his
participation
and
reviews
have
been
instrumental
to
progress
a
lot
of
the
working
group
documents
so
yeah.
He
will
be
missed
a
lot
so
and
also
I
want
to
say
if
any
of
you
want
to
get
in
contact
with
jim's
family.
A
A
A
A
Published
and
now
to
the
next
topics
in
the
agenda
or
before
we
talk
about
the
oi
tags.
I
just
want
to
mention
that
I
noticed
when
I
was
looking
at
the
documents
that
the
seaboard
date
tag
is
in
the
rc,
editor
queue
and
it's
in
auth
48
and
it's
been
authority
for
44
days,
but
I
don't
really
know
more
than
that.
C
A
B
A
B
A
D
B
Good
well
command
plus
always
helps
but
yeah.
So
we
we
haven't
done
much
with
the
document
in
the
last
month,
but
actually
what
what
we
need
to
do
is
rather
limited.
As
far
as
I
can
see.
So
we
we
were
in
september.
We
were
trying
to
find
out
the
level
of
complexity
we
wanted
to
have
for
for
tag
factory,
and
I
think
what
is
currently
in
in
dash
01
is
the
right
level
of
complexity.
So
if
everybody
agrees
with
that,
I
think
we
are
done.
B
We
just
have
to
delete
the
editors
note
and
then
I
have
a
small
number
of
editorial
changes
that
are
on
github,
but
but
I
haven't
shown
anyone
because
they
are
really
small
editorial
changes.
But
while
doing
that,
I
noticed
that
section
9.1
contains
some
security
considerations
about
conversion
between
basic
encoding
rules
and
dotted
decimal,
and
we
don't
really
need
these
anymore,
because
the
decimal
doesn't
play
a
role
in
the
document
anymore.
B
So
my
suggestion
would
be
to
delete
the
section.
That's
usually,
we
don't
delete
stuff
from
from
the
security
considerations,
because
it's
good
to
have
those
security
conservations,
but
this
is
now
really
out
of
scope
and
we
already
have
a
warning
in
the
third
paragraph
of
section
nine
of
the
series
security
considerations
that
points
out
the
general
problem,
even
if
it
is
out
of
scope.
B
So
these
are
the
two
things
I
would
propose.
Apart
from
my
small
editorial
changes,
delete
the
editors
node
in
section
five
delete,
section
9.1,
and
then
I
think,
essentially,
the
the
only
way
we
can
get
some
attention
is
to
go
for
one
group
call,
so
that
would
be
my
proposal
once
I
have
generated
a
dash
or
two
based
on
the
above
changes.
We
should
go
for
working
with
call
and
try
to
get
the
reviews
that
we
need.
A
A
Yeah,
that's
true,
that's
true
yeah
and
then
we
can
start
working
group
last
call.
I
don't
know
if
two
weeks
the
the
default
will
be
good
enough.
I
don't
know
if
we
want
to
also
forward
to
other
a
working
group,
or
you
know
we
just
do
it
yeah
to
get
more
more
reviews,
because
I'm
noticing
that
our
working
group
is
quite
it's
always
the
usual
suspects.
B
A
So
I'm
just
just
foreseeing
a
possible
issue
that
might
not
even
happen
if
we
got
enough
reviews
with
the
working
or
plus
call
all
of
this
is
we
don't
need
to
bother
about,
but
yeah,
okay
yeah?
We
will
wait
for
the
update,
then
what
you
said
makes
sense.
I
don't
know
if
anybody
else
wants
to
has
had
time
to
see
the
update,
but
otherwise
go
ahead
and
and
do
the
changes.
A
A
E
A
A
A
B
B
The
the
the
basic
idea
is
that
we
want
to
put
something
into
a
sebor
that
that
improves
the
coding
efficiency
without
going
full
out
into
compression
land,
because
compression
means
you
cannot
use
the
data
without
decompressing
them,
and
the
idea
behind
packing
is
that
we
just
do
things
in
a
way
that
the
data
can
be
operated
on
in
the
packed
state
so
that
that's
the
the
basic
new
idea
and
that
that's
the
the
guiding
principle.
So
we
don't
want
to
do
things
where,
where
it
suddenly
becomes
hard
to
to
use
the
data.
B
B
B
Aspect
of
it-
and
there
is
a
there-
is
a
20
aspect
that
comes
from
prefix
sharing
in
in
the
examples
I
looked
at,
we
often
have,
for
instance,
lots
of
uris
in
in
a
data
structure,
and
these
uis
all
start
the
same
way,
so
it
makes
sense
to
be
able
to
share
prefixes,
and
recently
people
have
had
examples
where
it
actually
makes
sense
to
share
suffixes.
So,
let's
call
the
whole
thing:
ethics
sharing.
If
your
linguistics
are
up
to
speed,
you
know
that
an
fx
is
either
a
prefix
or
suffix.
B
So
I
use
that
here
and
the
idea
is
to
do
this
in
a
rather
similar
way,
so
we
have
arrays
that
contain
prefixes
or
suffixes
and
in
the
places
where,
where
a
copy
is
needed,
these
are
referenced
together
with
the
the
the
rest
so
for
for
the
prefix
that
would
be
a
suffix
and
for
the
suffix
table.
That
would
be
a
prefix
that
is
put
together
with
that
reference.
B
Dash.
Zero
zero
only
defined
this
for
byte
and
text
strings,
and
it
seems
that
there
are
good
examples
why
you
want
to
do
this
to
arrays
and
maps
as
well.
So
so,
from
from
a
specification
perspective,
that's
a
trivial
change,
of
course,
from
an
implementation
perspective.
It
gets
interesting
next
slide.
B
So
this
is
what
is
in
in
dash
zero,
zero.
The
the
overall
structure
of
a
packed
item
is
an
array
attacked
array
that
has
the
ramp
so
the
the
data
item
that
has
all
the
the
references
to
shared
items
and
to
items
with
the
prefixes
and
at
that
time,
not
yet
suffixes
and
with
pre-physics
prefixes
in
them,
and
then
we
have
a
prefix
table
and
an
item
table
and
the
prefix
table
is
an
array
embedded
into
that
array,
and
the
item
table
is
just
the
continuation
of
that
array.
B
B
We
found
that
maybe
this
structure
is
a
little
bit
too
inflexible,
so
we
could
separate
out
the
the
two
major
components
of
sibo
pact.
One
is
the
definition
of
reference
of
referencing
structures,
so
these
reference
can
be
used
in
place
of
a
data
item
and
they
point
to
an
shared
item
or
they
point
to
a
shared
fx
plus
contain
some
data
that
is
combined
with
the
the
effects
and
for
both
kinds
of
pointing
we
need
an
efficient
name
space.
B
So
these
are
essentially
small
numbers
and
it
turns
out
if
there
are
a
lot
of
things
that
can
be
referenced
which
occurs
in
particular.
If
you
are,
if
you're
using
an
external
dictionary,
then
you
have
to
make
sure
that
you
put
the
frequently
frequently
referenced
stuff
into
the
good
pieces
of
the
namespace
and
the
less
frequently
referenced
parts
in
into
further
pieces
of
the
namespace.
B
In
the
current
proposal,
items
prefixes
and
and
maybe
in
the
future
suffixes
are
separate.
There
is.
There
are
a
few
examples
I
have
found
where
you
actually
want
something
in
both
places
and
well,
if
you
want
it
in
both
places,
you
can
make
it
a
shared
item,
so
it's
not
like
that.
That
is
not
supported.
It
just
requires
a
pointer
from
the
prefix
table
to
the
item
table
or
from
the
suffix
table
to
the
item
table.
So
it's
a
couple
bytes
spent
there,
but
it's
not
a
a
big
problem.
B
That's
why
we
are
using
separate
name
spaces
there.
So
that's
one
half
the
the
referencing
of
these
namespaces
and
the
other
part
is
building
the
tables
that
populate
the
namespaces.
So
in
the
existing
proposal,
the
the
tables
are
just
there
in
in
the
packed
item
and
the
proposal
was
to
add
external
dictionaries,
so
the
the
fun
part
will
be
to
control
how
the
namespaces
merge.
B
So
if
you
only
have
an
external
dictionary,
that's
easy,
but
if
you
want
to
have
an
external
dictionary
together
with
some
local
data
or
even
multiple
external
dictionaries,
and
then
you
have
to
do
some
work,
so
we
need
to
find
out
how
much
a
generality
we
actually
want
to
support
there.
For
now,
I'm
assuming
that
we
want
to
support
all
all
these
kinds
of
combinations,
multiple
external
dictionaries
and
and
plus
a
local
dictionary.
But
maybe
there
is
a
reason
to
restrict
that
or
to
define
a
profile.
B
B
B
So
what
was
considered
less
important
within
one
source
also
needs
to
be
less
important
in
the
combined
table
and
I'm
proposing
to
just
identify
those
buckets
that
we
had
in
the
previous
slide.
So
we
have
four
buckets
for
items
and
three
buckets
each
for
prefixes
and
and
suffixes,
and
we
just
combine
these
tables
based
on
the
buckets
so
yeah
again
again,
if
you
only
import
a
dictionary
or
use
a
locally
defined
table.
The
combination,
of
course,
is
trivial,
but
when
these
are
combined,
then
the
secant
sequence
becomes
important
next
slide.
B
B
We
probably
will
never
have
more
than
100
registered
dictionaries,
so
we
can
do
this
with
a
single
byte,
while
the
other
references
are
can
be
pretty
large,
so
any
useful
hash
will
be
like
32,
bytes
and,
and
you
your
eyes,
also
tend
to
be
10
or
20
bytes.
So
these
will
kind
of
go
against
the
the
advantage
of
using
an
external
dictionary
in
the
first
place
next
slide.
B
B
In
the
end,
we
will
have
some
complexity
for
the
cases
where
we
actually
combine
dictionaries
or
dictionaries
and
local
tables,
but
I
think
that
complexity
is
justified
for
those
applications
that
need
it
and
in
other
cases
we
may
just
want
to
refer
to
a
global
table
like
we.
We
originally
did
for
signaling
compression
20
years
ago,
so
that
there
is
one
global
table
that
that
everyone
uses
and-
and
that
is
registered.
And
so
we
have
a
very
simple
scheme
here.
That
is
very
easy
to
implement
for
a
specific
application.
B
Yeah,
the
next
step
will
be
to
write
this
up
in
in
the
next
version
of
of
the
draft,
but
before
we
do
this,
I
wanted
to
hear
whether
people
have
ideas
that
could
simplify
this
or
make
it
more
useful,
more
general
and
yeah.
I'm
probably
going
to
start
writing
this
only
next
week,
because
the
term
is
starting
here
right
now
and
we
still
have
a
lot
of
organization,
organizational
administrative
issues
with
doing
this
in
the
pandemic
era.
A
B
Yeah,
I
think
this
may
need
some
thinking,
so
you
may
want
to
look
at
the
slides
after
the
meeting
and
we
may
want
to
point
other
people
to
the
recording
of
this
meeting
to
find
out
what's
going
on.
Yes,
so
I'm
not
sure
that
we
can
do
a
lot
today,
but
we
we
may
get
some
knee
jerks.
So
if
there
are
knee
jerks,
please
go.
A
E
B
B
D
E
B
A
A
A
B
A
A
B
I
really
would
like
to
resurrect
the
time
tag,
so
we
have
run
into
another
case
where
we
may
need
this
tag.
So
the
the
because
with
people
are
a
little
bit
unhappy
with
the
floating
point
stuff,
but
I
I
don't
know
yet
what
exactly
the
requirements
are
there?
So
I'm
just
sensing
that
the
time
tag,
maybe
the
1001
time
tag,
may
be
the
the
best
way
to
handle
that
set
of
requirements.
A
B
Well,
this
was
done
at
a
time
when
we
weren't
really
chartered
to
do
this
kind
of
thing
yeah.
So
I
think
maybe
we
can
use
the
next
two
weeks
and
and
look
into
our
various
sibo
related
projects
and
see
where,
where
the
the
current
vocabulary
for
time
and
date
is
insufficient
and
go
into
the
discussion
with
an
assessment
of
whether
the
the
time
tag
document
is
making
some
progress
there
or
not,.
A
C
A
C
We
talked
about
the
possibility
of
leaving
her
as
the
only
chair
which
might
be
suitable,
but
I
tend
not
to
like
that
and
I
think
there's
a
reasonable
chance.
That
francesca
might
be
my
replacement
as
a.d,
which
reminds
me
to
remind
everybody
to
please
make
nomcom
comments
about
the
candidates
but
anyway,
so
if
any
of
you
have
a
good
idea
of
who
might
be
a
suitable
chair
for
working
with
francesca,
ideally
somebody
with
less
chair
experience
whom
francesca
can
help
you
know,
I
would
like
to
hear
it.
A
C
I'll
add
that
that
would
be
an
excellent
choice.
The
the
iesg
prefers
not
to
have
interim
meetings
the
week
before
the
ietf
meeting
and
yeah.
Actually
we
actually
talked
about
that
and
I
said
that
if,
if
you
guys
really
thought
it
was
important
to
have
a
prep
meeting
that
we
should
leave
it
on
the
schedule,
but
as
of
next
ietf,
you
won't
be
allowed
to
schedule
it.
Okay,
so.
E
A
E
A
Yes,
thank
you
actually.
That
was,
I
mean
we
scheduled
these
meetings
also
with
core
and
ace
not
to
overlap,
and
actually
we
need
this.
Then
it
was
the
last
interim
if
we
cancel
the
next
one
and
we
have
to
reschedule
the
next
series
of
interims-
and
I
don't
remember
now,
if
core
has
already
fixed
theirs,
no,
but
I
think
it
now
they
they
have
theirs
on
thursday,
so
they
wouldn't
overlap
with
us
anymore.