►
From YouTube: IETF-CBOR-20230823-1400
Description
CBOR meeting session at IETF
2023/08/23 1400
https://datatracker.ietf.org/meeting//proceedings/
A
B
C
D
D
C
C
A
C
Yeah,
thank
you.
So,
on
the
sibo
package
side
I
think
we
we
still
have
validation
by
implementation
on
our
schedule
and
the
use
case
dnsc
board.
So
as
vacation
time
is
slowly
going
to
an
end
in
Germany
I.
Think
Martin
will
also
have
more
data
to
look
at
so
I
think
we
should
look
at
that
at
one
of
the
next
interims.
C
So
that's
the
not
this
time
slide.
So,
let's
just
quickly
recap
with
what
most
of
you
probably
know.
Sibo
is
a
representation
format
and
it
comes
with
two
languages:
the
diagnostic
notation,
which
allows
us
to
look
at
c-bar
without
having
to
decode
a
binary
or
X
and
cddl,
which
allows
us
to
describe
data
models.
And
originally
we
said
the
diagnostic
notation
is-
is
really
a
second
class
citizen.
C
We
don't
even
Define
a
grammar
for
it
and
so
on,
and
it
seems
that
there
are
now
more
applications
where
it
makes
sense
to
do
that.
So
the
document-
the
edn
literal
document
that
originally
just
was
meant
to
provide
a
way
to
do
domain-specific
literals
in
diagnostic
notation
that
actually
has
acquired
an
ABN,
F
Syntax
for
Diagnostic,
notation
and
and
some
more
information
about
Iran
versus
cddl.
C
C
So
it
would
be
nice
to
to
have
a
way
to
handle
that
one
would
be
to
have
something
like
like
the
slash
star
syntax
of
C
but
yeah.
There
are
a
few
problems
with
putting
this
into
ABN
F,
so
maybe
the
other
thing
that
has
been
asked
for
repeatedly
our
end
of
line
comments,
and
there
are
three
candidates
for
End
of
Line
comments.
C
The
the
hash
mark,
the
semicolon,
which
would
give
some
commonality
with
a
CDL
and
the
double
slash,
which
would
give
some
Community
with
JavaScript
and
looking
at
various
documents,
even
actual
rfcs
hash
mark
and
semicolon
have
been
seen
in
the
wild,
even
though
they
are
not
not
officially
part
of
the
syntax.
So
maybe
we
should
just
legalize
them.
C
The
the
double
slash
would
be
more
like
JavaScript,
but
it
clashes
with
the
existing
slash
syntax,
so
I
I'm
not
sure
we
want
to
do
that.
So
I
would
probably
propose
going
for
hash
and
semicolon,
or
just
one
of
them,
I'm
completely
open
here,
but
make
sure
we
have
one
form
of
End
of
Line
comments
and
then
it's
much
easier
to
to
add
information.
C
So
that
would
be
my
proposal
going
forward
on
the
trailing
commas.
Json
famously
creates
an
editing
problem.
Each
time
you
you
Edge,
align
or
delete
a
line
at
the
end
of
a
Json
array
or
a
map
you
forget
to
add
or
delete
the
comma
and-
and
that's
just
a
lot
of
wasted
time
so
enabling
training
commas
has
been
requested.
A
lot
and
I
have
written
a
PR
which,
as
with
the
other
ABN
F,
still
needs
to
be
tested,
but
maybe
people
can
can
have
a
look
at
that.
C
So
these
These
are
essentially
the
the
user.
Visible
features,
there's
also
a
maintenance
issue
for
some
reason:
hex
floating
Point
didn't
make
it
into
diagnostic
notation
and
that
that
is
often
useful
when
working
with
exact
floating
Point
numbers,
so
I
propose
adding
that.
So
that
would
also
be
a
user
visible
feature,
but
not
one
that
we
inherit
from
from
Json
groups,
and
there
are
also
a
couple
of
ABN
F
fixes
that
are
out
there
as
for
requests
and
that
that
you
just
just
need
to
be
checked
and
applied.
C
And
finally,
there's
the
editorial
issue
that
that
we
never
mentioned
that
that
the
basic
integer
format
without
dots
or
exponents
gives
you
integers
in
diagnostic
notation
and
anything
with
plots
or
exponents
gives
you
a
floating
Point
values
that
that's
implicit.
If
you
look
at
appendix
a
of
RC
7049-
that's
already
in
there,
but
we
not
never
actually
thought
about
writing
it
down,
because
it
was
so
obvious
to
many
of
us
and
that's
of
course,
not
so
great.
C
A
E
Thank
you,
I
am
in
favor
of
adding
and
of
defining
the
use
for
End
of
Line
comments
of
both
pound
and
semicolon,
because
one
or
the
other
are
very
widely
used
in
a
variety
of
rfcs
and
and
it
seems
harmless
to
enable
both
and
perhaps
to
make
a
recommendation
for
the
use
of
one
over
the
other,
and
for
that
Carson
and
Barry
and
Marco
I
are
Christian.
I
would
suggest
you
guys
chime
in
I'm,
strongly
opposed
to
adding
double
slash,
because
it
just
adds
too
much
ambiguity
and
too
many
contents.
E
C
Okay,
so
I
go
to
the
detronistic
encoding
documents,
so
the
the
mailing
list
has
pretty
much
exploded
in
the
last
two
months
with
discussion
about
the
gymnastic
encoding.
When
we
originally
put
this
into
RFC
7049,
we
thought
well,
nobody
is
going
to
use
that,
but
it's
so
easy
to
do.
Why
don't
we
put
it
in?
C
So
that's
why
it's
in
there
and
now
we
have
increased
attention
to
this-
probably
at
least
partially
caused
by
the
the
need
to
do
privacy,
oriented
data
formats
where
parts
of
data
structure
are
blanked
out
and
replaced
by
hashes
and
and
that's
difficult
to
do.
If
you
don't
have
deterministic
encoding,
but
of
course,
all
the
old
use
cases,
some
of
which
we
may
or
may
not
like
very
much
are
there
as
well.
C
So
that's
what's
going
on
and-
and
this
has
been
push
forward
by
by
wolf,
mcnelly's
deterministic
sibo
document,
a
number
of
other
documents
are
there.
Unders
has
written
another
document
which
does
one
thing
well.
It
provides
a
lot
of
examples
which
we
will
have
to
put
into
the
other
documents
or
with
the
ones
that
we
want
to
go
forward
with.
A
So
in
interjecting
there,
one
of
the
things
that
Elliot
has
independent
stream
editor
has
asked
is
for
the
chairs
to
weigh
in
and
I've
held
back
so
far,
because
I
wanted
to
have
this
discussion.
But
my
view
is
the
same
thing
that
it
may
be
appropriate
for
Anders
document
to
go
to
the
independent
stream
at
some
point,
but
not
now
we're
still
having
active
discussion
about
what
to
do
with
this
whole
issue
and
I
think
that
our
input
to
the
independent
stream
editor
should
be
to
hold
off
until
until
that
discussion
completes.
A
C
Okay,
so,
given
that
we,
we
have
had
this
in
the
document
for
about
10
years
and
and
have
implementations
out
there
and
so
on,
I
thought
it
might
be
a
good
idea
to
actually
write
up
some
of
the
knowledge
that
that
we
have
Acquired
and
that
doesn't
necessarily
have
gone
into
the
update
rc8949.
So
I
wrote
this
background
document.
C
I
haven't
updated
this
since
originally
submitted
that
that's
probably
next
to
do
but
I
hope
to
have
an
informational
document
already
soon
that
that
provides
all
this
background
information
I
mean
people
talk
about
sub-normals
and
and
have
very
little
idea
of
why
they
are
relevant
to
deterministic,
encoding
and
so
on.
So
this
is
really
the
kind
of
information
that
that
I
was
trying
to
capture
in
in
this
document.
C
So
at
some
point
we
should
decide
whether
this
is
useful
as
an
Information
Network
group
document,
but
yeah
we
can
do
this
later.
We
can
just
collect
more
information
in
that
the
other
document
I
wrote
was
trying
to
get
some
structure
into
this
by
splitting
up
what
what
Wolf's
document
did
into
two
parts.
One
part
that
deals
with
encoding
and
one
part
that
deals
with
more
application,
specific
or
wolf,
has
suggested
saying
domain
a
specific
issue,
so
one
is
really
about
c-bar
and
the
other
one
is
really
about.
C
So
we
we
put
another
thing
on
top
of
that
which
is
the
the
common
deterministic
encoding
profile
or
CDE
for
short,
that
closes
those
holes
and
provides
us
with
a
common
profile.
So
the
basic
idea
is
that
there
are
some
things
that
will
be
common
to
the
majority.
Probably
not
all,
but
the
majority
of
deterministic
encoding
applications
that
use
C1
and
that's
CDE,
and
on
top
of
that
we
have
domain
profiles,
and
these
are
because
CDE
already
handles
the
the
bytes
of
the
representation
from
it.
C
The
the
domain
profiles
really
are
about
mapping
data
from
the
application
data
model,
which
is
often
influenced
strongly
by
the
the
platform
data
models.
So
when,
when
you
only
have
in
64
and
and
you're
in
64,
then
you
probably
have
a
certain
view
of
of
the
data
that
that
you,
you
will
send
around
and
and
it's
good
to
capture
this
in
a
domain
specific
profile.
C
The
the
figure
may
look
nice,
but
it
completely
hides
the
fact
that
sibo
is
an
extensible
format.
So
it's
really
hard
to
maintain
the
the
beauty
and
simplicity
of
this
figure.
Once
you
add
extensions,
so
that's
why
Community
medicine
encoding
requires
a
little
bit
of
work
beyond
what
section
421,
actually
not
411,
defines
in
the
the
sibo
standard,
and
then
the
next
step
is
taking
this
set
of
generic
data
model
items
so
see.
Sibo
has
a
generic
data
model.
C
One
is
exclusion,
so
the
domain
data
model
May
simply
say
you
cannot
represent
minus
10
to
the
power
of
19..
In
this
domain
data
model,
which
is
perfectly
fine
if
the
domain
doesn't
need
that
it
does
create
some
implementation
complexity,
because
it's
outside
the
the
range
of
N64
and
un64.
So
you
you
have
to
to
somehow
manage
negative
integers
that
are
more
negative
than
you
can
express
using
in
64..
C
These
are
different
at
the
generic
data
model
level.
These
are
different
at
the
application
Level
at
least
in
most
platforms.
Javascript
is
the
one
important
exception
and
what
the
reduction
does
is.
It
looks
for
numbers
that
are
for
floating
Point
numbers
that
are
equivalent
to
an
integer
number
and
converts
them
to
integers
in
certain
specific
cases.
C
So
this
is
really
the
the
layering
that
has
come
out
of
the
discussion
and
I'm
really
glad
we
had
this
discussion,
because
the
the
structure
of
section
4.2
is
really
a
demonstration
that
we
didn't
understand
all
this
when
we
actually
wrote
up
the
the
crop
data
okay.
So
what
this
work
does
or
is
supposed
to
do
from
my
point
of
view,
so
my
objectives
are:
we
want
to
facilitate
wider
use
of
the
gymnastic
serialization
for
a
number
of
use
cases.
The
the
background.
C
The
document
has
a
number
of
them
both
sent
a
longer
list
of
use
cases
to
to
the
list
to
the
mailing
list
today.
So
there
are
a
lot
of
cases
where
it
helps
to
have
the
gymnastic
civilization,
and
we
want
to
facilitate
that
without
somehow
devaluing
the
the
unconstrained
use
of
sibo
that
that
we
have
in
many
other
places.
C
So
we
would
use
CDE
as
a
common
diffusing
recording
profile
as
a
common
set
of
encoding
decisions,
which
is
essentially
identical
with
section
four
two
one
and
a
few
tweaks,
and
that
can
be
implemented
in
a
generic
encoder
decoder.
So
much
of
the
work
that
is
needed
to
get
deterministic
civilization
out
there
would
only
need
to
be
done
once
and
then,
on
top
of
that
we
can
create
one
or
more
simple
domain
profiles,
so
we
don't
need
10
or
20
Page
documents.
We
need
one
page
documents
and
wolves.
C
C
So
the
the
documents
that
I
think
should
come
out
of
the
working
group
is
the
informational
document.
If
we
decide
to
agree
on
that,
the
CDE
part
of
the
the
senastrec
draft
that
I
wrote
and
the
domain
profile,
part
of
which
is
currently
in
the
same
document,
so
we
we
will
see
how
we
handle
that
Wolf's
proposal
is
slated
as
an
experimental
protocol
I'm,
not
even
sure
that
is
necessary.
So
I
think
this
could
be
go
through
as
a
standard
structure,
track
document
and
yeah.
C
The
question
is:
can
we
absorb
the
information
in
the
the
other
two
documents?
So
we
we
don't
need
more
documents
on
DC
bar.
We
just
have
a
single
one,
and
should
we
split
this
off
from
the
CDE
part,
or
should
we
use
this
as
as
an
example
as
a
motivation
for
the
CDE
part?
So
we
can
actually
make
our
points
in
a
document
that
has
bought
layers
in
it.
C
C
C
C
E
E
C
One
effect
of
that
is
that
people
look
at
this
and
say:
oh
this
civilization
format
only
has
20
pages
of
documentation
and
the
other
one.
It
says,
60
pages,
so
the
60
pages
one
is
likely
to
be
more
complicated
and
we'll
use
the
20,
Page,
documentation
and
I.
Think
splitting
off
informational
documents
is
a
good
thing
we
should
do
more
often-
and
in
this
case
it
came
pretty
naturally.
E
Thank
you,
I
I
think
it
is
a
good
direction
today
for
workroom
for
documents,
shorter
rfcs
that
are
concise
and
that
don't
constantly
restate
rate
the
old
thing
as
well
as
having
enter
interspersed
rationale,
are
a
lot
easier
to
read
and
to
implement
the
IEEE
seven.
Whatever
number
is
with
the
nans
ETC,
the
IEEE
float
15,
something
or
other
the
floating
Point
is
that
is
that
hard?
C
I
think
it's
mainly
hard
because
the
the
actually
Source
leaves
a
lot
to
implementation
on,
not
the
numbers,
and
we
we
probably
want
to
extract
something
that
that
is
still
useful
for
those
few
people
who
actually
want
to
use
Nan,
payloads
but
I.
Think
the
vast
majority
of
of
the
civil
applications
only
need
a
single
nand
value
so
that
that
is
likely
to
be
what
what
the
most
people
are.
Going
for
and
I
must
admit.