►
From YouTube: CBOR WG Interim Meeting, 2021-04-21
Description
CBOR WG Interim Meeting, 2021-04-21
A
A
B
Yes,
so
we
we
have
errata
reports
about
cddl
from
someone
who
actually
wasn't
implementing
cdn.
He
was
implementing
the
sibo
diagnostic
notation,
but
because
that
doesn't
come
with
an
abnf,
he
was
looking
for
the
cddl
abnf
for
inspirations
and
it
turns
out
there
are
two
problems
in
that
abnf
and
there
also
is
an
actual
problem
in
the
description
of
the
diagnostic
notation.
B
B
B
B
B
So
we
we
had
to
address
this
bug
and
that
of
course
raises
the
question:
is
there
there
do?
We
really
have
consensus
on
on
the
on
using
just
the
the
json
notation
there,
the
the
abn
f
was
different,
so
it's
not
quite
clear
what
the
working
room
consensus
here
actually
was
so
that
there's
a
little
space
for
interpretation
open.
B
B
The
second
question,
of
course,
is:
do
we
handle
this
as
part
of
the
errata
report,
because
it's
well,
it's
it's
a
few
lines
of
abn
f
that
that
are
new.
That
now
have
been
looked
at
by
by
the
unicode
mailing
lists
of
the
itf
as
well,
and
we
got
some
feedback
and
so
on.
So
there
has
been
some
discussion:
it's
not
just
a
random
idea
of
a
single
person
anymore,
and
it
seems
also
that
cushion
is
converging
but
yeah.
B
So
if
you
can
probably
don't
have
a
split
screen
capability
right,
otherwise
I
would
ask
you
to
to
go
into
the
freezer
document
and
just
show
those
three
lines
of
four
lines
of
yes
exactly
so.
This
is
mostly
copied
and
somewhat
cleaned
up
from
what's
in
rfc
8259
the
json
rfc,
but
it
explicitly
calls
out
the
rules
for
using
surrogate
characters
in
utf-8.
C
C
B
A
C
B
So
this
was
the
the
number
of
the
thing
6527
and
then
there
is
another
errata
report
about
byte
strings
and
yeah.
So
these
are
actually
changed
by
by
the
text
frame
change,
because
that
there
are
two
kinds
of
byte
strings.
There
are
byte
string,
literals
that
exactly
look
like
fixed
strings,
except
for
using
a
single
quote.
So
this
is
handled
by
by
the
text
in
the
section
dealing
with
65
27
and
then
there
is.
B
So
this
is
what
the
first
example
is
doing.
So
when
you
pass
such
a
text
string
you,
you
have
to
be
aware
that
it
excusing
such
a
white
string.
You
have
to
be
aware
that
it's
a
hex
or
base64
byte
string
and
have
to
follow
the
the
syntax
of
hex
base64
versus
comments
and
the
the
alternative
is
to
say
no,
we
we
do
the
the
parsing
of
the
the
text
between
the
single
quotes
first,
and
do
it
exactly
like
with
byte
strings
that
have
the
form
of
text
strings?
A
B
A
B
C
C
A
A
B
So
the
question
was:
is
there
anything
we
want
to
make
special
about
optional
and
the
authors
who
are
among
the
people
who
are
driving
the
the
development
of
the
haskell
language?
The
authors
said:
no.
This
is
going
to
mess
up
the
thing
and
it's
clean
as
it
is,
and
if,
if
we
actually
try
to
identify
which
of
the
alternatives
are
null
like
and
which
of
the
ones
are
not,
that
opens
another
can
of
worms
and-
and
they
would
like
to
keep
this
clean
of.
E
C
E
E
C
A
B
Yeah,
so
the
the
oid
draft
is
from
like
2014
and
has
been
pretty
stable.
We
did
cut
back
on
some
of
the
fringe
cases
and
so
on,
but
we
all
thought
that
that
it
was
clear
what
this
was
going
to
be,
and
then
there
was
a
late
edition,
which
is
this
tag,
which
I
call
tvd112
112.
I
think,
which
is
an
abbreviated
version
of
an
absolute
oid.
B
So
you
remove
the
first
five
bytes
of
our
absolute
id
that
that
in
text
form
is
the
one
three
six
one
four
one
and
the
the
the
thing
that
we
didn't
think
through
when
we
edit.
This
is
that
it
creates
one
of
those
preferred
encoding
issues
that
we
talked
so
much
in
in
finishing
7049
bis,
which
was
that
an
encoder
now
has
a
choice
whether
it
wants
to
use
the
tbd
110
tag,
the
the
standard,
absolute
id
or
the
abbreviated
tbd
112
tag.
B
B
D
I
think
you
should
always
use
the
shorter
tag,
I
think
would
be
the
should
recommendation,
and
I
don't
know
what
I
don't
know
what
the
exception
would
that
to
be?
Why
it
wouldn't
be,
must
the
reason
I
guess
it
wouldn't
be.
Musk
is
because
we
can
tolerate
having
the
other
one
in
the
stream.
For
some
reason,
I
guess
the
reason
why
it
might
not
be
must
is
because
you
might
not
know
you
know
you're
putting
a
tag
there,
but
you
don't
know
which
one
yet
and
you're
going
to
come
back
and
insert
it.
B
B
X500
distinguished
name,
and
there
are
tons
of
oids
in
there,
and
most
of
these
oids
can
be
described
as
absolute
oils
and
you're
right.
I
meant
dvd-111,
and
there
are
a
few
in
there
that
would
need
to
be
described
as
tbd-112,
which
you
can
so
you.
You
can
go
ahead
and
put
in
a
tbd
112
everywhere
that
there
is
this
one,
three,
six
one,
four
one
and
it's
still
shorter,
because
the
the
additional
tag
costs
two
bytes
and
you
save
five
bytes.
So
so
this
is
an
optimization.
B
E
E
B
Now
the
the
other
responses
on
different
subjects,
I
think
we
can
take
them
off,
so
we
could
say
yes,
this
is
a
good
point,
but
but
we
don't
care
about
it.
That's
number
one.
The
second
approach
is
to
say
we
we
do
declare
112
as
the
preferred
encoding
if
the
absolute
oid
starts
with
that
prefix
and
to
a
means.
B
B
B
for
me.
That's
the
the
the
one
that's
easiest
to
implement,
because
I
don't
have
to
look
at
all
the
various
cases,
but
it
also
means
that
recipient
has
to
do
some
additional
checking,
whether
there's
that
maybe
an
absolute
oid
with
the
tbt-111
sneaked
in
and
the
implementation
has
to
reject
that.
And
then
there
is
the
question
there
is
this
big
company
that
implemented
that
wrongly?
So
you
don't
want
to
reject
that
and
yeah.
We
know
how
these
things.
D
I
think
that
encoders
should
use
112
whenever
they
can
and
I
don't.
I
don't
care
too
much
about
the
array
optimization,
except
that
decoders
have
to
deal
with
it
right.
Okay,
so
well,
they
already
have
to
deal
with
it.
They
already
have
to
deal
with
it
right.
So
I
I
I
I
think
this
is
a
bit
like
packed
seaboard
right.
We
need
to
make
the
decoding
rules
really
clear
and
we
won't
always
get
the
best
encoding,
but
sometimes
it
doesn't
matter.
B
B
A
A
D
D
A
B
Yeah
one
one
thing
I
could
say
about
the
working
group
document
is
the
the
sibo
pact
work.
I
promise
to
to
make
my
implementation
available
and
I'm
really
really
close
to
doing
that,
but
I
didn't
manage
to
finish
this
before
this
meeting
so
expect
this
to
hit
get
up
any
moment
now,
and
I
think
if
we
have
an
implementation
to
stay
ahead,
it's
maybe
easier
to
to
then
go
forward.