►
From YouTube: IETF-CBOR-20210908-1400
Description
CBOR meeting session at IETF
2021/09/08 1400
https://datatracker.ietf.org/meeting//proceedings/
A
C
B
B
B
B
C
C
C
Okay,
so
the
one
of
them
was
the
sillier
control
document
and
francesca
they
kindly
put
in
her
adv
review
today,
and
this
is
a
very
concise
idea
review,
and
it
has
this
observation
that
there
is
a
double
double
quoted
text
string
in
the
text,
and
that
is
a
discussion
that
we
actually
are
having
on
on
one
of
the
lists.
I
don't
remember
if
it's
tools
this
the
rfc
interest
right
now.
C
How
are
we
going
to
to
work
with
parts
of
of
a
document
of
the
rfc
of
a
draft
that
are
marked
as
typewriter
phase
the
tt
element
of
rfcxml
or
the
back
quotes
in
markdown,
and
traditionally
the
those
have
been
shown
as
a
typewriter
face
in
the
html
and
have
been
as
kind
of
indicated,
with
double
quotes
in
the
plain
text?
But
of
course,
if
the
text
marked
up
that
way
already
has
double
quotes,
it
looks
very
strange
and
unfortunately,
the
the
rfcxml.
C
That
always
looks
weird
in
in
the
text,
so
that
there
is
no
solution
to
this
problem
because
rfc
xml
is
simply
broken
and
we,
the
rfc
editor,
will
fix
when
the
time
comes
yeah.
No,
they
can't
because
the
the
rfc
is
is
defined
by
its
xml
and
the
xml
only
has
a
way
to
say
there
is
something
that
is
typewriter
face
and
that's
something.
D
C
C
D
Okay
but
yeah,
the
document
is
in
last
call
now
and
it
will
end
last
quarter
in
two
weeks
and
I
just
wanted
to
ask
carsten
if
you
are
going
to
be
quick
to
reply,
as
you
always
are
to
reply
to
the
last
call
reviews
I
might
calculate
for
the
next
stellar
chat,
so
so
that
you
don't
have
to
wait
two
more
weeks
if
there
is
otherwise.
If
you
don't
think
there
is
hurry,
we
can
just
wait.
C
D
C
D
D
D
This
one
point
so
when
I
was
reviewing
this,
I
asked
to
myself:
why
are
we
having
these
two
tags,
260
and
261?
And
why
can't?
Why?
Don't
we
obsolete
them
with
this
document?
And
I
know
that,
like
I
looked
in
the
mail
archive
to
see
if
there
had
been
some
discussion
about
it,
and
indeed
some
other
people
had
had
the
same
comment,
and
I
I
saw
your
answer
michael,
you
said
that
you
didn't
really
care
either
way
or
and
carsten.
D
You
were
saying
that
you
don't
wanna,
be
doing
restructuring
of
the
whole
ayanna
registry
at
this
moment,
and
I
think
that
we
don't
need
to
do
the
the
whole
restructuring
of
the
ayanna
register.
But
we
could
do
what
other
ayana
registries
do,
which
is
to
add
a
note
saying,
obsoleted
in
favor
of
52
and
54.,
and
the
document
already
states
that
you
know
these
are
that
these
are
meant
to
replace
260
and
261..
D
C
Yeah,
so
I
think
I
agree
with
with
your
approach.
I
have
a
little
problem
with
the
word
obsolete.
You
know
that
we
have
had
a
multi-year
discussion
about
the
word.
Update
and
obsolete
is
the
next
one
is
going
to
be
the
next
one,
because
those
tags
still
exist
and
and
out
there
that
there
are
still
documents
that
have
those
tags.
C
B
D
Yeah,
I
would
be
very
happy
with
the
deprecated
and
also
another
another
knit
that
we
could
discuss.
If
is,
if
you
would
have
it
in
the
now
in
the
in
the
mail
I
sent.
I
put
this
note
on
the
like
the
tag
number
column.
You
could
also
put
the
note
in
the
semantics
column
instead,
so,
where
it
says
network
address,
you
could
add
deprecated
in
favor
of
52
and
54.,
but
I
think
that.
A
C
D
E
D
D
That's
great
okay!
So,
since
we
agreed
on
this,
then
I'm
gonna
push
the
button
and
request
last
call
and
same
comment.
If
let
me
know
if
you
think
that
if
you
want
this
on
the
isg
telechat
in
two
weeks,
which
would
be
two
weeks
and
one
day,
which
means
that
I
will
have
to
put
it
on
the
agenda
before
the
last
call
is
over
and
that
will
that
will
mean
that
I
will
ask
you
to
be
quick
to
update
for
any
last
couple
comments.
D
E
D
C
So
we
can
actually
change
it,
because
it's
not
that
much
meant
for
interchange,
but
in
reality,
of
course,
people
write
their
tools
around
it,
so
we
still
have
to
be
a
bit
careful
that
we
don't
break
it,
but
we
might
want
to
think
about
additions
to
the
diagnostic
notation
to
support
specific
applications
and
the
application
that
that
came
up
is
coral.
The
constrained
restful
application
language,
which
is
a
hypermedia
format
and
being
hypermedia
format.
It
mostly
contains
links,
links
to
resources
with
some
type
information
and
target
attributes,
and
things
like
that.
C
C
There
are
places
where
you
can
just
put
some
resource
metadata
that
maybe
aren't
directly
attached
to
links
or
forms
or
yeah.
The
type
information,
of
course,
is
metadata
as
as
well,
so
it's
a
pretty
simple
sibo
format
and
this
this
essentially
came
out
the
the
earlier
discussion
in
the
car
working
group
about
lynx
json
and
link
sibo,
which
was
a
cleaned
up
version
of
rfc
6690
link
format.
C
C
So
we
had
a
lot
of
discussion
in
the
thing
to
think
research
group
and
now
the
drafts
have
gone
into
the
car
working
group
and
are
being
discussed
there.
So
that's
the
the
background
and
the
current
graph
defines
two
representation
formats,
a
primary
representation
followed
which
is
cbo
based,
of
course,
that's
the
format
that
the
constraint
devices
are
supposed
to
work
on.
C
C
So
that's
generally
the
the
problem
with
handcrafted
examples
and
and
this
a
nice
text-based
format
exactly
but
exacerbates
the
the
problem
with
handcrafted
examples
by
one
order
of
magnitude
and
then
people
came
and
said:
oh,
you
are
doing
sibo
based
version.
Are
you
going
to
do
a
json
version
too
yeah?
C
So
that's
a
question
that
that's
still
up
for
discussion
and
not
on
the
agenda
today,
because
that's
really
a
core
working
group
issue
and
not
not
a
civil
working
issue,
but
the
the
whole
discussion
kind
of
brought
up
the
question:
can
we
actually
maybe
do
something
with
sibo
diagnostic
notation?
So
we
can
stay
close
to
cbo
in
our
text
format
and
don't
need
this.
C
This
beautiful,
but
somewhat
two
steps,
remote
format
and
the
the
answer
to
that
is
it's
actually
incredibly
tedious,
because
most
of
coral
actually
is
links
and
links
are
transported
in
coral
in
in
a
pre-passed
form.
The
the
concise
resource.
Excuse
me
constrained
resource
identifiers,
and
these
essentially
are
the
the
meat
in
the
ui.
So
you
no
longer
have
syntax
there.
C
C
C
We
have
for
byte
strings
and
we
are
generalizing
this.
There
actually
is
one
example
that
exactly
looks
like
this
in
coral
today,
which
is
the
date
time
information
which
is
in
the
text
form
taking
essentially
this
this
syntax.
So
it
seems
kind
of
natural
to
do
this,
and
I
I
since
learned
that
rust
actually
has
has
a
similar
mechanism
and
yeah.
C
E
So
irony
here
is
that
I
wrote
the
only
rust
macro
I
have
written
has
been
one
to
allow
me
to
parse
sivor
hex
format
from
the
tools
there.
But
I,
if,
if
I
understand
you
right,
this
would
be
primarily
something
that
goes
is
on
the
input
side
and
that
we
would
not
expect
anything
to
emit
this
necessarily
unless
it
was
a
very
much
a
chorale
specific
tool.
Is
that
that
what
I
understand.
C
E
E
Yeah,
but
that's
basically
that
that
that's
that's
that's,
maybe
a
little
bit
more
people
are
it's
a
little
bit
easier
for
people
to
come
to
to
see
that
as
just
syntax,
but
I
don't
have
a
problem
with
that.
I
think
that
it's
probably
a
good
idea.
I
I
I
I
do
want
to
know
whether
or
not
the
lack
of
a
space
after
the
cri
is
intentional,
because
that
matches
the
rest
of
it.
C
C
So
again,
this
is
a
question
whether
people
have
an
opinion
on
this
right.
Now,
I'm
a
bit
frustrated
that
I
cannot
simply
say,
okay,
this.
This
covers
all
we
currently
have
in
in
the
text
format,
because
we
haven't
designed
cris
to
to
be
sequences
of
things.
That
then,
would
need
to
be
passed
that
we
want
them
to
be
prepared.