►
From YouTube: CBOR WG Interim Meeting, 2021-01-13
Description
CBOR WG Interim Meeting, 2021-01-13
A
A
A
A
A
So
I
can
maybe
do
a
quick
recap
of
what's
the
status
of
that
one
and
if
you
want
to
say
anything
or
if
you
have
any
update,
let
us
know
so.
The
working
group
last
call
has
ended
a
while
ago
and
I
was
a
bit
late,
but
I
have
done
a
review
now
and
it's
posted
my
list
and
I
haven't
seen
any
reply
to
that
one
and
also
I
was
hoping
to
get
a
couple
more
eyes
on
it.
Even.
A
Very
loud,
even
if
it's
not
no
worries,
even
if
it's
not
a
very
detailed
review,
but
just
the
approval
of
that
someone
else
has
has
looked
at
it
and
think
that
it's
it's
good
to
move
forward
and
I
think
carsten
you
mentioned
that
you
know
you
knew
of
someone
else
who
was
was
going
to
do
that.
But
I
haven't
seen
anything
yet.
A
A
C
A
A
A
C
But
it's
probably
a
good
idea
to
pick
up
what
we
learned
during
discussion
of
the
date
tag
and
see
whether
we
can
apply
those
learnings
to
the
time
tag
document
and
move
this
forward.
So
it
can
be
a
working
group,
a
document.
I
don't
consider
this
high
priority,
but
the
other
way
it
would
be
nice
if,
if
we
could
get
this
done.
A
A
A
C
So
the
the
question
is
is:
is
that
a
problem
if
we
wait
a
little
longer
until
we
have
implementations
of
that
in
place
as
well,
or
do
we
split
it
off
and
and
complete
the
first
one?
So
as
soon
as
there
is
a
document
that
actually
uses,
for
instance,
the
dot
feature
control,
it
would
be
nice
if,
if
we
were
getting
close
to
working
group,
last
call
as
well.
A
A
C
A
A
Awesome-
and
I
that
was
it
for
working
group
documents-
is
there
anything
about
working
like?
Is
there
anything
that
we
need?
That
would
be
good
to
have
like
more
resources
or,
for
example,
for
the
oi
document.
I
realized
we
probably
need
more
people.
Looking
at
the
document,
do
you
feel
like
that
anybody
like
would
be
good
to
have
more
people
participating
or
set
up
better
communication
with,
for
example,
other
working
groups.
A
A
C
A
Well,
the
the
id
was
an
example
for
for
seaport,
but
since
we're
starting
a
new
year,
you
know
I'm
just
wondering
like
this
working
group.
In
my
opinion,
it's
worked
very
well
and
has
progressed
and
has
done
a
lot
of
good
stuff,
but
it's
it's
good
to
keep
keep
in
mind.
Okay,
what
can
we
do
to
make
it
even
better,
for
example,
for
the
oil
document?
D
So
my
suggestion
is
that
actually
we
should
do
a
presentation
on
seabor,
including
oids,
at
sag
as
a
standard
encoding
and
just
more
focused
on
the
security
advantages
of
a
standard
encoding
and
maybe
talk
a
little
bit.
It
will
be
a
bit
more
of
a
general
talk,
because
what
I
think
is
that
the
parts
that
of
the
itf
that
know
c
bar
know
it
well
and
the
parts
that
don't
know
the
I,
the
c
board,
don't
know
it
at
all.
A
D
B
A
D
Exactly
so,
it's
not
a
tutorial,
it's
an
overview.
The
other
thought
I
had
francesca
is
so
I've
been
through
about
six
seabor
libraries
in
rust
and
c
and
they're.
Definitely
not
all
equip
all
equal,
and
I
would
say
some
of
them
are
actually
perhaps
actively
hostile
to
the
what
I
think
of
the
seabor.
D
Good
points,
so
I
don't
know
what
we
can
do
in
terms
of
welcoming
some
more
implementers
into,
maybe
not
the
mailing
list,
but
maybe
at
least
the
github
to
deal
with
some
things.
In
particular,
I
think
that
there's
the
issue
of
so
and
so
says
that
they'd
really
like
to
have,
for
instance,
seaboard
tags
in
this
implementation,
but
so
and
so
thinks
it's
irrelevant
to
the
whole
discussion,
and
it
would
be
very
useful
if
somehow
that
could
come
into
the
working
group
as
a
discussion.
D
A
D
D
Well
so,
for
instance,
the
rust
cerdez
will
never
implement
tags
actively.
They've
made
it
a
a
design
decision
that
it
does
not
work
and
they
cannot
implement
tags
right.
Okay,
so
that
is
a
serious.
You
know
knife
in
the
back
to
the
whole
process,
because
that's
the
standard
way
of
getting
of
annotating
things
in
rust
to
get
things
serialized
is
to
do
it
with
surgery.
So
unfortunately
that
means
that
in
this
case
we
have
this
problem.
D
If
we
want
to
have,
you
know
implement,
if,
if
we
just
want
to
serialize
structures
to
disk
and
back
into
rust
with
cbor,
well,
that's
great,
but
you
could
do
with
any
any
process.
It's
it's.
The
tags
become
so
important
when
you
want
to
communicate
with
other
implementations
with
a
protocol,
and
so
suddenly
we
can't
do
that
with
that.
So
that's
a
problem.
A
C
So
this
is
the
the
approach
of
this
implementation.
Matrix
is
to
to
come
from
an
enumeration
of
sibo
features,
and
I
think
the
the
idea
of
doing
an
implementation
survey
would
actually
come
from
the
other
end
and
discuss
how
how
are
people
designing
apis
for
for
cbo
implementations
and
not
all
zebra
implementations
are
sibo
implementations.
C
They
often
are
implementations
of
a
set
of
encoding
mechanisms,
and
it
probably
would
be
a
good
idea
to
have
this.
This
api
side
survey,
because
that's
really
the
the
problem
with
putting
tags
in
30,
is
not
that
this
is
somehow
hard
to
to
implement
or
something
it's
just
that
the
the
api
is
not
designed
to
to
enable
that.
C
A
A
A
A
C
The
the
part
that
we
haven't
done
yet
is
actually
putting
tags
in
the
other
sense
of
that
word
in
there.
So
people
who,
who
look
for
for
an
implementation
that
actually
can
do
tags
the
way
they
are
used
in
protocols
can
can
slog
through
the
long
list
and
and
find
those
implementations
that
do
something
for
them.
C
E
E
C
D
A
A
A
A
D
Won't
it,
I
think
it's
not
yeah,
it's
not
something
that
we're
racing
to
do
for
march.
I
think
it's
something
we
we
want
to
show
significant
progress
at
the
end
of
the
year.
I
don't
know
if
this
is
something
that
we
would
publish,
I
think
as
an
as
an
rfc.
I
don't
think
so.
I
think
that
it's
just
marketing,
if
you
like
technical
marketing,.
A
Yeah
absolutely
and
carson.
That
was
your
your
idea
to
have
an
internet
draft,
but
also
documenting
the
gita
buy
in,
like
whatever
works.
Whatever
is
easiest,
I
mean
there
is
some
some
something
associated
to
keeping
it
alive
and
submitting
a
new
version,
etc
that
just
you
don't
have
that
type
of
pressure
with
with
the
github
document.
A
B
B
It
would
be
a
real
good
idea
to
carry
that
too,
because
I
agree
with
michael.
There
are
a
lot
of
people
in
itf
and
the
rest
of
the
world
who
know
what
sibor
is
and
appreciate
some
of
its
merits,
and
then
there
are
a
whole
lot
who
know
nothing
about
sibor
which
amazes
me
at
this
point.
But
it's
true
and
I
don't
think
they
realize
honestly,
that
there's
a
standards
based
open
standard
for
a
better
way
to
do
strong
on
the
wire
encoding.
B
Yeah,
I'm
suggesting
that
we
use
the
sag
and
the
feedback
from
that
to
polish
that
and
make
it
a
perennial
or
a
recurring
activity
and
take
it
around
to
other
area.
Specific
groups
like
dispatch
to
to
make
people
a
little
more
aware
that
there's
this
tool-
and
there
are
many
library,
implementations
and
more
coming.
B
A
A
B
Thank
you
michael,
and
I
I
was
thinking
because
you
had
put
out
you
know,
reach
out
to
other
sdos,
specifically
of
contacts
that
I
and
my
immediate
colleagues
in
trusted.
Computing
group
have
with
global
platform,
although
they're
well
aware
generally
of
seaboard
but
etsy,
which
has
lots
of
groups
who
aren't
aware
of
c
c
bore
and
3
gpp
and
so
on,
and
they
because
in
particularly
in
3gpp,
they
tend
to
subscribe
to
not
invented.
Here
they
go
on
inventing
unique
crypto
algorithms
for
no
clear
reasons.
A
A
D
I
think
that,
aside
from
people
telling
us
that
they're
doing
it
and
us
noticing
that
it's
happening,
I
think
that
ultimately,
it
involves
probably
chairs
and
other
people
simply
making
you
know
it's
it's
about.
You
know
personal
contacts
which
we
don't
get
to
do
until
four
more
months,
and
then
you
know
it.
It
might
be
that
I
don't
know
imagining
some
kind
of
sibor
announced
mailing
list
or
something
like
this,
but
I
probably
that's
not
quite
right
but
but
effect
effectively.
D
A
B
And
yeah
and
many
of
us
get
too
much
email
because
not
of
sibor
mailing
list,
but
because
of
dozens
of
other
mailing
lists,
not
just
in
ietf
and
the
collective
effect
is.
I
have
40
to
60
new
non-junk
mails
every
morning
when
I
open
my
email
and
I
have
to
wait
through
them
and
and
I
have
to
wade
through
them
because
at
least
a
half
a
dozen
contain
something
I
really
don't
want
to
miss.
B
B
Day,
I
was
thinking
michael
and
francesca
also
that
we
all
have
colleagues
one
way
and
another
who
are
active
in
other
sdos,
because
that's
their
day,
job
or
their
interest
or
both
and
those
sorts
of
contacts
reaching
out
to
somebody
to
say.
Could
you
speak
to
the
chair
of
the
such
and
such
working
group
and
perhaps
take
this
canned
presentation
and
we'll
get
michael
or
karsten
or
someone
who
could
answer
beyond
the
second
question?
B
B
A
B
B
C
A
C
C
C
So
the
the
proposal
here
is
to
come
up
with
a
set
of
tags
that
are
kind
of
anonymous,
but
they
are
chosen
in
such
a
way
to
be
relatively
efficient.
So
you
are
not
penalized
too
much
by
by
using
them
for
discriminating
unions
and
yeah
you
get.
You
can
look
at
the
proposal
how
they
they
propose
to
do
this.
Specifically,
I
have
a
few
little
suggestions
that
I
could
make
at
this
point.
C
So
my
plan
for
for
supporting
this
from
the
working
group
was
to
put
it
into
a
draft
right
now.
I
I
was
proposing
to
put
it
into
notable
tags,
but
we
could
also
do
a
separate
draft.
I
don't
have
a
strong
opinion
on
that
and
just
at
some
point
turn
it
into
a
working
group
document.
So
people
see
okay.
This
is
not
just
a
a
tag
that
somebody
has
registered,
but
that
is
actually
meant
to
be
cbo's
main
support
go
to
support
for
compiler
generated,
discriminated
unions.
E
I
gotta
admit
I
haven't
read
this
in
the
quick
time,
but
how
is
I
mean
the
kind
of
the
thing
that
comes
to
my
mind
when
I
think
of
the
problem
is
just
put
it
into
a
basically
have
a
tagged,
two
tuple.
Is
this
just
more
efficient,
or
is
this
in
addition
to
that
something
else
as
well?
It's
more
efficient,
okay,.
C
So
tags
ncba
only
have
an
arity
of
one,
which
means
they
are
kind
of
inefficient.
If
you
use
the
pretty
common
design
pattern
of
of
taking
a
pair
of
some
things
which,
by
the
way
seaboard
does
in
in
its
tags,
four
and
five,
for
instance,
so
using
the
the
number
inside
the
tag
as
as
a
crutch
to
to
get
the
same
kind
of
functionality
is
the
way
to
go
and
they
are
proposing
to
reserve
some
tag.
D
C
Yeah,
let
me
give
you
an
example
where
actually,
what
would
would
be
of
interest
to
a
protocol
designer?
So
you
know
that
that
yang
also
has
type
unions
and
now
for
for
some
reason,
these
are
non-discriminated
units.
But,
let's
assume
yang
had
discriminated
unions
in,
in
which
case
we
would
probably
define
a
set
of
tags
specifically
for
yang
to
represent
them,
and
I
think
it
would
be
nice
to
just
have
a
standard
on-board
feature
of
of
sibo
that
can
be
used
for
for
protocols
like
like
that.
As.
E
Yeah-
but
you
can't
so
in
in
in
the
yang
case,
yes,
but
in
if
you
think
of
more
general
general
protocol,
if
you're
thinking
of
general
protocols
that
might
at
some
point
use
some
take
something
else
inside
there,
they
would
need
to
say
and
starting
from
here
now
the
the
general
tags
mean
this
protocols
thing,
whereas
the
various
tags,
the
the
text
as
described
in
zebor,
can
be
used
in
any
context,
and
maybe
they
are
not
valid
there.
But
at
least
there
are
semantically
unique.
C
Yes,
my
suggestion
would
be
if
you
want
that
if
you
need
that
go
ahead
and
register
unique
tags,
but
if,
if
you
actually
have
an
environment
where
these
compiler
generated
discriminators
make
sense,
then
then
you
have
something
you
can
use
without
having
to
register
something.
That's
specific
to
your
environment
makes
sense
here.
So
the
the
assumption,
the
the
unsaid
assumption,
is
that
these
tags
would
be
interpreted
in
context.
D
D
A
C
A
Sounds
good
and
we
have
five
minutes
left.
I
thought
today
will
be
a
quick
meeting
for
some
reason.
I
don't
know
why
this
weird
strange
idea:
okay,
last
five
minutes,
I
just
wanted
to
say
that
we
chairs
have
to
we
haven't
done
yet,
but
we
have
to
request
a
session
and
in
the
code
dmd,
I
posted
the
the
list
of
working
groups
that
are
our
usual
conflicts,
and
we
also
have
a
comment
about
any
security
and
iot
related
buff
to
avoid
conflict
with
those.