►
From YouTube: IETF-CBOR-20220518-1400
Description
CBOR meeting session at IETF
2022/05/18 1400
https://datatracker.ietf.org/meeting//proceedings/
A
D
A
Okay,
we
have
two
large
okay,
it's
changed.
We
have
three
and
a
half
fields
of
discussion
plan
for
today,
one
being
the
tag
38,
the
extension
to
problem
details
that
does
the
language
direction
and
the
half
discussion
attached
to
that
is
that
we
might
want
to
talk
a
bit
about
how
we
evolve
types
in
general
and
on
the
topic
of
file
of
working
group
documents.
There's
a
question
of
the
status
of
file,
magic
and
carson.
A
A
C
Package,
so
we
we
just
finished
the
programming
last
call.
We
got
a
few
responses.
We
got
a
lot
of
offline
thingies
coming
up
here
and
there,
so
I'm
not
even
sure
that
the
list
that
is
on
on
that
slide
is
is
even
complete.
So
I
think
the
the
overall
outcome
is
this
can
be
done
as
it
is,
but
there
are
still
lots
of
ideas
of
of
maybe
improving
or
changing
it
in
one
way
or
the
other.
C
C
But
of
course
that's
something
that
that
any
document
that
uses
the
the
packed
scheme
as
a
normative
reference
might
might
be
doing.
Oh
marco
was
it
thank
you
and
the
the
other
thing
packing
deterministic
would
be
making
sure
that
our
unpacking
algorithm
actually
leaves
something
behind
that
can
again
be
used
as
a
deterministic
encoding,
and
I
think
we
we
haven't,
really
thought
about
that
that
issue
either.
C
C
E
One
of
the
points
of
of
packed
seabor
is
that
it
can
be
used
in
place
so
unpacking
it
and
expecting
to
have
deterministic
encoding
doesn't
make
sense.
To
me,
I'd
say
that
if
you've
signed
something,
then
what
you've
signed
is
what
you
get
trying
to
pack
something
post
signature
makes
no
sense
to
me.
C
E
Right
right-
and
I
I
appreciate
this-
but
what
what
I'm
trying
to
say
is
that
these
are
these.
That
use
case
doesn't
seem
compatible
with
pact
to
me,
there
are
use
cases
that
are
compatible
with
pact.
This
isn't
one
of
them.
So
I
think,
if
you're,
if
you're,
trying
to
construct
things
in
that
way,
packed
seabor
is
probably
not
for
you
that
or
there's
got
to
be
a
fallback
deterministic
packing
algorithm.
One
of
the
two.
C
Yeah
so
far,
we
we
have
discussed
packing
with
respect
to
generic
pekkas,
which
are
really
hard
to
get
deterministic,
but
if
we
have
an
application,
specific
format
such
as,
for
instance,
suit,
we
might
have
very
defined
points
where
the
packing
mechanism
comes
in.
So
I
I
even
think
it
would
be
easier
for
these.
These
application
specific
packed
formats
to
be
useful
in
a
deterministic
manner
as
well.
C
E
C
C
Yeah
this
is
at
least
now
something
that
we
understand
the
application
developer
may
want
to
do
at
some
point.
Next
question:
do
how
do
we
handle
sequences
now?
Obviously,
you
can
pack
each
element
of
the
sequence,
but
that
doesn't
really
allow
you
to
to
use
the
full
redundancy
between
the
elements.
So
what
we
really
would
like
to
be
able
to
do
is
pack
a
sequence,
and
how
do
you
do
that?
C
C
C
C
So
again
the
the
application
would
have
to
be
very
warned
about
that,
but
I
think
it
can
be
done
in
cases
where,
where
you
still
would
want
to
use
a
sequence,
because
it's
usually
the
the
more
efficient
way
of
doing
things.
But
if
you
actually
want
to
put
some
packing
in
there
packing
across
elements
of
the
sequence,
this
unwrap
splicing
thing
would
do
it.
C
So
that's
something
we
could
define
in
this
document.
That's
something
we
could
define
later.
So
it's
not
really
necessary
to
define
this
now,
but
I
think
we
should
think
about
whether
we
have
use
cases
that
would
want
to
use
redundancy
across
items
in
a
sequence
or
elements
in
a
sequence
and
whether
this
particular
solution
already
solves
that
problem.
C
C
D
F
C
A
C
C
C
So
we
we
have
the
domain
impact.example
in
all
three
entries
of
of
the
array
or
three
elements
of
the
array,
and
we
we
extract
the
pack.example
into
the
prefix
table,
and
now
we
can
do
something
with
that.
Prefix
table
use
prefix
0
to
build
the
pack.example.html
and
again
use
that
for
bardot,
sibo
and
so
on
and
yeah.
The
example
works
well
for
the.
C
Case
where
we
only
have
a
single
concatenation,
but
if
we
need
two
concatenations,
then
we're
kind
of
missing
a
construct.
So
we
don't
have
a
tag
that
would
allow
us
to
outright
concatenate
two
strings
or
other
things
that
can
be
concatenated.
The
concatenation
is
always
combined
in
the
current
document
with
accessing
the
prefix
table
or
the
suffix
table.
C
Of
course
you,
if
you
would
know
that
you
want
to
do
this,
you
can
simply
throw
the
the
strings
that
you
you
need
to
concatenate
into
the
prefix
table,
https
and
and
co-op
s
and
still
build
what
what
you
need,
but
that's
not
very
useful
for
static
dictionaries.
So
the
the
use
case
where,
where
the
mid
fix
stuff
is
really
missing,
is
a
use
case
where
you
would
use
static,
dictionaries
yeah,
so
the
the
the
status
quo
is
we.
C
A
C
A
C
E
C
Okay,
I
will
have
another
slide
about
extensibility
and
our
strategy
for
doing
extensibility
here,
but
it
seems
to
me
this
is
again
something
that
is
best
discussed
in
the
context
of
a
specific
application.
And
if
we
have
the
extensibility
in
place
to
make
use
of
this,
then
we
can
do
it
when
we
come
to
that
application.
C
C
C
C
So
when
you
look
at
chris
zipp's
record
type,
then
you
immediately
have
about
10
ideas
of
how
you
could
use
splicing
together,
arrays
and
maps.
I
haven't
actually
defined
any
one
of
these,
but
it
would
be
possible
and
when
you're
thinking
about
combining
arrays
and
strings,
you
immediately
think
about
python
join.
C
So
I
think
that
there
are
a
number
of
combinations
that
are
possible
here.
That
actually
makes
sense
again.
It
would
be
nice
to
have
the
applications
that
that
really
need
that
but
yeah.
When
we
look
at
the
cri
problem
there,
we
have
a
again
a
situation
where
we
actually
would
like
to
combine
things
that
are
structurally
not
quite
the
same,
but
we
haven't
even
started
to
understand
what
we
want
to
do
there.
C
A
A
There
I
think,
you'll
come
back
to
this
later.
There
is
this
point
about
possibly
merging
pre
and
postfix
styles,
and
if
we,
if
we
in
some
way
generalize
the
pre
and
postfix,
maybe
that
joining
operation
will
not
so
much
be
a
property
of
referencing
into
a
prefix
or
postfix
item
and
then
that
this
addition
here
would
be
described
in
in
in
pre
and
postfix
terms.
A
C
C
Of
course,
you
could
also
do
a
static
dictionary
by
by
referencing
some
data
using
ui
or
hash
and
so
on.
But
if
it's
actually
static
and
and
standardized
like
like
what
was
it
three
four
eight
five
was,
then
you
would
just
give
it
a
tag
and
then
it's
there
so
that
that's
an
obvious
extension
point
and
we
can
define
new
reference
tags,
so
we
could
define
reference
tags
for
midfix,
circumfix,
template
expansion
and
and
so
on.
C
But
of
course,
if
we
have
new
reference
tags,
these
either
need
to
use
the
existing
table.
So
they
would,
in
the
current
situation,
use
one
of
the
three
tables
sharing
prefix
and
suffix,
or
they
would
define
the
the
new
table
type,
the
new
table
types
and
then
we
would
have
to
explain
how
the
table
setup
works
so
that
that's
pretty
much.
The
extension
points
that
we
have
at
the
moment,
and
I
think
you
said
that
you
wanted
to
bring
up
the
ability
to
put
something
into
the
tables
beyond
just
putting
the
the
data
item
itself.
C
A
Yeah
yeah,
so
I
think
whether
it's
in
the
table
or
in
the
data
item
in
model-wise
doesn't
matter
so
much.
I
would
view
it
more
in
being
inside
the
table
entry,
but
it's
how
it's
set
up
doesn't
need
to
occur,
needs
to
match
one
by
one
to
to
how
it's
in
the
table.
So,
for
example,
it
there
could
be
a
table
setup
that
still
says
we
have
a
list
of
prefix
things
and
list
of
suffix
things,
but
that
populates
a
single,
a
single
sequence
of
somehow
typed
entries
in
the
table.
A
That,
for
example,
then
contains
three,
the
first
three
items
that
are
prefixes
and
thus
use
string
concatenation
if
there
are
strings
and
every
concatenation,
if
they're
areas
and
some
post-fix
entries
and
then,
if
there's
different,
different
table
setup
or
an
additional
entry
to
the
an
additional
type
of
yeah.
If
the,
if
the
table
is
set
up
differently,
then
that
could
allow
inserting
elements
to
the
into
the
table
that
have
yet
again
different
rules.
That
would
then
be
any
kind
of
the
circle
made
or
other
fixed
entries.
C
C
So,
for
instance,
we
could
say
that
that
one
of
these
tables
actually
is
not
a
data
item
but
a
functional,
and
so
you
apply
the
functional
to
the
argument
of
the
the
the
content
of
the
reference
tag
so
that
that
would
solve
most
of
the
problems
and
we
could
even
hijack
one
of
the
existing
tables
by
by
saying
the
default
situation.
Unless
you
do
this
and
this,
the
the
functional
is,
is
essentially
created
by
by
doing
the
prefix
or
suffix
operation.
C
C
But
that's
maybe
related
to
the
next
item.
So
so
one
question
was:
do
we
really
need
to
have
a
separate
prefix
table
from
a
suffix
table
and
clearly
having
one
less
table
means
that
you
save
a
byte,
because
in
in
the
table
setup
tag
you
no
longer
have
to
reserve
an
array
for
the
prefix
ones
and
the
reserve
an
array
for
the
suffix
ones,
and
it
also
makes
it
easier
to
actually
use
the
same.
C
Piece
of
of
text
or
the
same
piece
of
array
in
both
the
prefix
and
the
suffix
position
right
now,
you
essentially
have
to
use
one
of
the
entries
to
refer
to
the
other
entry
concatenating
it
to
the
empty
string
which
does
work,
but
that's
kind
of
ugly.
Of
course.
The
the
next
question
is:
why
do
we
separate
the
sharing
table
from
the
ethics
table?
C
C
The
question
is:
wasn't
there
a
downside
and
of
course
there
was
a
downside,
because
when
you
actually
write
down
a
reference
tag
and
have
exceeded
the
the
range
of
of
a
particular
length
or
size
of
reference
tag,
then
you
get
into
the
next
one
and
the
the
way
we
have
structured
these
things
for
prefix
tags.
We
have
this.
This
first
group
of
oneplus
31
or
32
references
which
are
significantly
more
efficient
and
for
suffix
tanks.
We
actually
only
have
eight
of
them.
C
A
C
C
Yeah
these
also
require
some
processing,
then,
and
and
so
on,
yeah.
Of
course
it
would
be
much
nicer
to
have
a
single
range
of
referencing
tags
that
says,
do
whatever
the
table
says
and
the
table
sent
then
says:
I'm
a
prefix,
I'm
a
suffix,
I
am
a
functional
and
then
we
have.
We
don't
need
to
spend
another
space
of
reference
tags
for
the
suffixes.
C
E
E
But
I
I
don't
know
I
it
would
be
really
nice
if
we
could
get
a
quantification
for
actual
applications
on
the
impact
this
has.
But
I
don't
think
we
have
enough
actual
samples
that
for
for
real
applications
that
we
can
make
a
properly
informed
decision,
so
this
is
going
to
end
up
being
finger
in
the
air,
regardless
of
what
we
do.
Unless
we
do
that.
C
I
mean
this
would
be
a
little
wart
in
in
the
grand
scheme
of
things,
but
it
would
it
easy
to
share
the
same
string
as
a
prefix
and
suffix,
and
it
would
still
keep
the
idea
of
open
that
if
you
put
a
tag
in
there,
then
that
tag
tells
you
what
the
the
actual
functional
is.
That
is
applied
to
the
argument
of
the
tag
of
the
referencing
tag.
E
A
C
C
C
C
C
C
So
the
sharing
only
profile
of
pac
will
be
perfect
for
very
constrained
devices,
and
the
the
sharing
plus
fx
situation
is
probably
the
other
profile
where
that
that's
everything,
but
you
could
possibly
split
this
into
a
strings
only
case
and
a
full
implementation
that
does
arrays
and
and
maps
too,
because
I
think
quite
a
bit.
Fewer
cases
will
really
benefit
from
doing
arrays
and
maps,
but
they
are
really
useful
for
some
cases,
so
I
would
like
to
keep
them
in
yeah.
So
do
we
suggest
these
as
profiles?
C
That
was
the
main
question
I
had
on
this
slide
and
the
other
question
was:
do
we
maybe
do
specific
tags,
just
as
we
have
take
51
by
the
way?
I
give
that
thing
a
new
number
in
in
the
next
version,
because
51
is
actually
the
number
three.
So
that's
not
something
we
want
to
spend
here
anyway.
So
should
we
have
separate
tags
for
these
profiles
now
that
we
are
about
to
merge
prefix
and
suffix?
Maybe
the
expense
of
having
a
single
tag
for
both
is
no
longer
as
big
yeah.
B
B
E
C
C
C
But
there
is
also
an
auto
case,
and
of
course
you
could
say
you
get
this
if
you
don't
put
in
this
optional
element,
but
if,
if
this
is
used
to
override
something
that
is
inherited
from
the
context,
you
may
want
to
reset
the
context
back
to
the
default.
So
that's
why
it
may
be
a
good
idea
to
have
a
third
alternative
there
and
more
generally,
that
that
opens
the
question:
do
we
want
to
have
some
extensibility
there?
C
So
if
we
nail
this
down
to
those
two
or
three
values,
what
do
we
do
next
week
when
we
find
out
that
the
direction
this
needs
more
cases
and
that
maybe
leads
into
the
the
agenda
item
that
we
may
not
have
time
for
anymore,
which
is
how
do
we
even
evolve
tags?
So
this
is
the
first
time
we
we
actually
are
changing
the
the.
C
A
I
think
I
think
I
read
one
of
the
documents
about
this
and
I
think
they
said
that
there
are
there's
an
explicit
list
of
languages
where
it's
recommended
not
to
spa
stated
even
that
when
it's
right
to
left.
But
there
are
languages
where
it
should
be
explicitly
stated
because
it's
necessary,
but
that
that's
all
in
the
in
the
details
of
the
languages.
C
C
C
Setting
that,
of
course,
would
be
a
clean
solution,
except
that
the
the
internationalization
people
tell
me
these
really
should
be
coming
together.
It
should
not
be
separated
out
so
yeah,
but
that
would
be
an
alternative
that
would
make
it
unnecessary
to
change
tag
38,
but
it
would
keep
attack
38
there.
That
is
essentially
much
less
usable
without
the
explicit
direction
information
attached
to
it
and
then,
of
course,
we
could
just
define
as
many
take
38
analogs
as
we
have
directions.
C
So
the
the
thing
we
are
doing
in
many
other
places
as
well,
that
we
encode
some
of
the
information
in
into
the
tag
number
that
that
is
certainly
an
alternative
that
that
we
should
think
about.
But
looking
at
all
this,
I'm
still
happy
with
what
we
have
in
the
document.
But
but
I
wanted
to
hear
whether
people
have
a
strong
preference.
A
A
point
I'd
like
to
make
for
you
for
the
one
we
have
in
the
document
now
is
that
it's
easy
for
implementations
that
don't
that
basically
discard
language
and
or
directionality
information,
because
they
can't
process
it,
because
these
will
just
see
it's
tag.
38.
I
take
element
number
one
in
the
array
and
use
that
and
discard
everything
else,
and
if
we
get
two
or
three
or
an
extensible
number
of
tags,
that's
just
a
list
of
tags
that
I
text
to
basically
to
ignore
and
pick
this
or
that
element
from
the
tag
for
for
those
implementations.