►
From YouTube: IETF-CBOR-20230308-1500
Description
CBOR meeting session at IETF
2023/03/08 1500
https://datatracker.ietf.org/meeting//proceedings/
A
Hello,
just
in
case
this
wasn't
clear
from
the
mailing
list:
the
the
actual
chairs
I'm,
just
a
second
chair
for
the
first
half
hour.
They
actually
shares
cannot
be
here
before
half
past,
so
we
have
half
an
hour
time
for
General,
hallway
discussions
and
yeah.
We
just
should
keep
in
mind
that
this
is
being
recorded
So.
The
best
thing
we
can
use
this
time
for
is
is
doing
discussions
that
we
actually
want
to
record.
A
So
on
the
agenda
for
for
the
actual
working
meeting,
we
have
a
discussion
about
Citi,
dial,
2.0
and,
given
that
we
only
have
half
an
hour
and
two
items
on
the
agenda
or
actually
three
together
with
the
IDF
116.
A
agenda,
one
thing
we
could
look
at
is
the
remaining
slides
that
I
want
to
use
for
the
CDL
2.0
discussion.
So
everybody
who
thinks
that's
a
good
thing
to
do
with
the
first
10
minutes
or
so.
Please
raise
your
hand.
B
A
A
So
if
you
have
something
complicated
like
Karim,
which
is
built
out
of
several
files,
you
can
essentially
do
an
include,
but
also,
very
importantly,
the
ability
to
use
existing
CDL
as
a
library
which
is
the
import
keyword
and
two
functions
that
both
of
these
have
is.
You
can
put
included
or
imported
CDL
into
a
namespace,
so
you,
you
can
use
multiple
libraries
that
may
have
conflicting
names
by
by
adding
a
namespace
to
them,
and
you
also
can
limit
the
import
to
specific
names.
A
So
those
were
the
objectives.
That's
a
very
small
set
of
objectives,
I'm,
not
saying
that
that
we
are
done,
but
we
have
done
this,
but
this
these
are
the
objectives
that
the
current
prototype
is
providing
and
yeah
I'm
going
to
go
through
a
couple
of
examples
here.
A
So,
on
the
left
side,
you
see
a
command
line
that
is
used
to
actually
called
The
Tool
and
in
this
case,
two
lines
of
actual
sibo
of
actually
cddl
one
is
a
cddl
ruled
that
that
is
actually
CDO
one
and
one
is
an
import
directive,
which
is
what
what
we
are
adding
here
in
in
this
video
to
iteration.
So
in
this
case
is
very
short,
it
just
says
the
start.
A
Production
is
cozy
key,
and
apart
from
that,
we
are
importing
everything
we
need
from
RFC
1952.
A
So
the
the
tool
actually
copies,
the
start
equals
Cosi
key,
and
then
it
looks
into
RFC
1952
for
any
rules
that
we
might
want
to
use
because,
of
course,
the
key
apparently
is
not
defined
at
this
point
in
time
in
in
this
CDL
module
so
from
the
RFC
1952
module,
it's
going
to
get
the
Cozy
key
rule
and
now
that
rule
again
has
requirements
for
for
the
two
rules,
label
and
values
and
those
actually
can
be
found
in
RFC
1952.
So
these
are
then
recursively
copied
over.
A
So
the
the
thing
you
see
on
the
right
hand,
side
is
exactly
what
the
cdlc
tool
produces.
So
this
can
then
be
processed
by
a
city
A1
tool
like
the
original
CDL
to
CDA
code
gen
or
whatever.
You
are
choosing.
A
So
that's
a
similar
case
when
we
have
the
problem
that
what
we
are
importing
might
be
conflicting.
So,
for
instance,
we
might
be
in
a
piece
of
c-bar
that
has
its
own
idea
of
CDA.
That
has
its
own
idea
of
what
a
label
or
what
values
are
you
can
embellish?
The
import
statement
was
as
a
name,
so
in
this
case
we
use
lowercase
cozy
as
a
name.
I
don't
have
a
feeling
what
the
convention
should
be
here,
but
this
is
the
example.
A
A
Now
you
don't
necessarily
necessarily
always
want
to
import
or
include
everything
that
that
is
currently
undefined
in
your
city
there.
You
want
to
be
very
specific
about
what
you
pull
and
you
can
do
this
by
adding
a
from
clause
which
is
preceded
by
a
number
of
names.
So
in
the
first
example
on
this
slide
we
would
say
we
include
label
and
values
from
RFC
1952,
and
then
we
get
exactly
those
two
rules
included
and,
of
course
we
can
do
that
namespaced
again.
A
A
Yeah
and
explicit
names
also
use
the
transitive
closure
mechanism.
No,
it's
getting
really
small.
So
if
you
say
import,
cozy,
dot,
MDR
serialized
map
from
RFC
1952
as
cozy,
then
you
get
the
below.
First
of
all,
the
what
the
the
one
rule
that
also
was
in
the
CDL
file
with
my
data
is
just
copied
verbatim
are
actually
not
quite
verbum.
A
You
can
see
that
there
is
some
processing
going
on
here,
but
the
the
result
is
supposed
to
be
equivalent
and
then
the
tool
pulls
empty
or
serialized
map
from
the
library
prefix
is
that
with
cozy,
and
then
there
are
further
things
that
needs
to
pull
including
header
map,
generic
headers
label
and
values
which
are
again
prefixed
by
the
name
given
so
the
S
cozy
turns
MPR
serialized
map
into
cozy.mdr,
serialized
map
and
so
on.
A
So
this
is
again
a
lot
of
automatics.
That
gives
you
exactly
what
you
need
in
a
particular
context,
and
there
is
one
more
little
feature,
which
is
a
convenience
I
think
we
can
discuss
whether
that's
useful,
but
we
discussed
it
in
the
design
team
meeting,
so
I
implemented
that
as
well.
This
is
almost
the
same
as
the
previous
slide,
except
that
empty
or
serialized
map
now
also
is
aliased.
So
the
second
line
of
the
result,
essentially
is
an
alias
rule.
A
Empty
or
serialized
map
is
an
alias
for
cozy
dot,
mpo
serialized
map,
and
that
is
also
automatically
generated.
So
you
can
just
say:
I
want
to
use
RFC
1952
as
a
library
with
a
prefix
cozy,
but
the
things
that
I
specifically
import
should
be
in
my
namespace
and
and
not
just
in
cozy
namespace.
So
in
this
case
they
are
in
both
namespaces.
A
And
the
the
final
thing
is
the
ability
to
do
some
of
this
from
the
command
line.
So
if
you
actually
don't
want
to
to
write
up
a
file
that
that
contains
the
cddl
that
has
the
import
statement,
then
you
can
use
Dash
I
for
import
or
Dash
capital
I
for
include
and
cozy
equals.
Just
means
import,
RFC
19532
as
cozy,
and
you
also
can
have
automatically
generated
start
rules.
So
the
S
cozy,
dot,
cozy
dot
underscore
key
becomes
the
rule
on
the
lower
left
of
the
slide.
A
So
if
you
run
this,
you
get
a
result
that
is
on
on
the
right
hand,
side
of
the
slide
and
that's
often
really
useful
to
be
able
to
simply
pull
out
one
name
from
from
a
piece
of
CDL,
not
just
the
library
but
also
code
that
you're
actually
writing
right.
Now
about
your
designing
and
just
pull
out
that
one
rule
and
generate
the
the
cddl
all
the
CDL
that
is
needed
to
to
make
this
thing
useful
for
validation,.
A
Okay,
that's
a
quick
overview.
I
wanted
to
to
give
again
for
those.
Coming
later.
We
are
in
the
hallway
part
of
the
meeting,
because
the
actual
chair
is
only
going
to
come
in
at
15
30
UTC
in
in
16
minutes.
A
So
we
thought
we
might
want
to
use
the
time
here
for
for
some
discussion.
So
is
there
any
question
or
comment
on
what
I
have
shown.
C
Seems
to
have
all
the
capabilities
I'm
used
to
be
good
with
the
various
other
tools
with
other
languages.
A
Great,
so
it
would
be
good
to
get
the
feedback
from
people
who
actually
have
tried
to
use
this
for
something
useful,
whether
it
solves
their
problems.
D
Chris
so
so
I've
I've
been
trying
to
use
this,
and
this
isn't
directly
related
to
what
you
were
talking
about.
But
there's
little
enough
conversation
I,
think
I'll
I'll
bring.
B
D
Up
one
of
the
challenges
I'm
running
into
is
actually
very
close
to
what's
on
your
screen,
so
you
know
you
talk
about.
You
know
you're,
defining
cozy
key
right
there
and
you
can
imagine
a
scenario
where
you
have
lots
of
other
drafts
that
are
trying
to
Define
new
values
for
that
cozy
key
and
it
seems
like
the
right
way
to
do.
This
is
with
the
cut
syntax
right.
So
you
would
say
you
know
right
now.
You
have
optional
two
points
to
be
stir
right.
D
It
would
be
more
correct
to
say
to
use
the
cut
notification
for
two
to
be
stir,
but
I
run
into
composability
problems
there,
where
it's
hard
to
refer
to
another
another
area,
it's
not
as
clear
as
I
would
like
to
like
it
to
be
how
to
define
new
keys
and
values
for
an
existing
object,
and
maybe
that's
worth
thinking
about
yeah.
A
Yeah,
definitely
that
that
is
something
that
most
of
us
have
experienced
and
we
we
currently
use
crutches
like
this
star
cozy
label
Arrow
Cosi
videos,
but
that,
of
course,
doesn't
allow
us
to
to
specify
what
what
exactly
that
is.
A
So,
of
course,
it
was
nes
is
not
what
you
want
to
have
so
composing
a
map
out
of
different
Library
sources.
That's
definitely
something
that
that
we
are
not
supporting
very
well
at
this
point.
D
Yeah
and
and
you're
right,
this
works
fine
as
a
workaround.
It
just
feels
like
there
might
be
a
clearer
solution
at
some
point.
A
Well,
the
the
solution
that
most
people
who
are
building
larger
things
are
using
right
now
is
to
actually
use
a
socket
in
place
of
cozy
label,
error,
cozy
values
and
have
things
add
to
that
socket
now,
that's
something
that
my
implementation
of
the
cdo2
functionality
doesn't
fully
support.
Yet
so
that's
the
one
big
to
do.
I
have
on
my
list
to
do
a
socket.
A
The
the
reason
I
haven't
shown
a
socket
here
is
that
I
was
just
using
RFC
1952
as
as
a
convenient
library
that
that
everyone
probably
knows
a
little
bit
about
so
RC
1952
doesn't
have
that
that
socket
convention
in
it
I
could
have
used
something
like
current
or
crossword
or
one
of
the
complicated
specifications.
For
for
that.
D
D
So
the
this
one
is
actually
work
outside
the
ietf,
but
we're
working
with
the
CT,
the
CTA,
to
develop
a
common
access
token
and
that
access
token
is
built
on
cwts
and
we
are
attempting
to
we're
gonna
as
part
of
the
specification
we're
going
to
Define
all
of
the
seaboor
for
all
the
Cozy
elements,
and
for
some
of
them
we
can
just
reference
the
other
specifications
that
Define
them
and
then
for
other
ones.
D
We
have
to
Define
them
ourselves,
which
was
another
thing
that
is
a
little
bit
odd
in
the
specification
is
that
there
are
a
lot
of.
There
are
a
lot
of
these
elements
that
are
not
already
defined
in
cbdl,
but
are
defined
in
Pros,
but
in
order
to
have
a
complete
cdvl
document
that
could
be
validated,
we
effectively
have
to
provide
cdvl
for
things
that
are
defined
in
other
documents,
and
that
feels
weird
but
yeah.
It's
also
it's
also
reasonably
doable.
A
So
what
what
I've
started
putting
together
is
a
draft
called
RFC
cddl
models
which
is
essentially
pulling
in
those
models
from
the
the
various
rfcs
that
already
have
published
cddl,
and
it's
not
complete
at
this
point
in
time,
but
it's
just
the
start
and
it
kind
of
make
them
more
integratable
by
by
removing
things
that
are
examples.
Adding
things
like
these
sockets
I
I
have
talked
about.
So
the
the
objective
of
this.
A
The
draft
is
to
essentially
build
a
collection
of
referenceable
models
that
that
work
better
for
integrating
them
with
with
models
that
use
these
models.
So
that's
maybe
something
that
that
we
want
to
pay
a
little
bit
more
attention
to.
So,
if
you
have
any
any
RFC
based
models
where
you're
already
starting
to
to
add
the
the
write
connections,
I
would
definitely
be
interested
in
getting
those
as
input
for
this
RFC.
For
this
draft.
D
Trying
to
see
if
on
this
list,
if
you
have
there's
a
draft
out
there,
that
has
that's
collecting
all
of
the
definitions
for
commonly
used
things
that
includes
the
Alternatives
format.
A
D
Yeah
Noble
tax
is
an
expired
draft.
At
the
moment,
I
was
just
wondering
if
the
plan
was
to
continue
work
on
it.
Definitely.
A
And
I
think
the
the
idea
to
make
sure
that
we
have
referenceable
City
day
wherever
that
makes
sense
for
one
of
these
drafts
that
that's
a
great
that's
great
input.
D
So
one
of
the
things
I
run
in
one
of
the
things
I
have
observed
is
odd,
and
you
could
tell
me
to
stop
talking
if,
if
we
have
the
right
people
to
begin
the
meeting
proper,
but
one
of
the
things
I'm
finding
that's
a
little
bit
odd
is
that
in
seaboor
we
have
a
number
of
registrations
that
register
things
that
are
defined
in
drafts
and
it
makes
it
confusing
in
terms
of
implementation
and
the
ability
to
use
those
in
other
drafts,
because
the
registration
of
something
even
in
a
draft
suggests
that
you
shouldn't
register
another
thing:
that's
almost
identical
right.
A
Can
if
you
can
use
the
registration,
you
should
keep
with
that.
So
let
me
just
give
an
example:
how
we
dealt
with
that
recently
that
there
has
been
tag
38
around
for
for
almost
a
decade.
No,
that
tells
you
how
to
provide
language
tag,
information
with
some
some
zero
text
string
and
that
that
was
essentially
just
a
GitHub
repo.
A
It
wasn't
even
an
internet
draft
that
defined
that
thing,
and
recently
we
needed
that
in
an
RFC
in
the
concise
problem,
details
document
RFC
9290-
and
we
found
that
we
actually
have
to
extend
this
a
little
bit
because
the
the
original
work
didn't
address,
directionality
so
right
to
left
left
to
right.
So
we
asked
the
the
original
registrant
whether
we
could
pull
his
registration
in
to
this
RFC,
which
we
have
done.
So
this
is
maybe
the
the
high
maintenance
end
of
that
Spectrum,
but
that's
something
you
can
do.
A
A
D
Yeah
like
like,
if,
if
it's
a
lot,
the
the
registry
for
C
board
is
a
lot
lower,
friction
and
I
think
that's
a
good
thing
on
average
on
the
whole
for
participation,
but
it
definitely
does
have
have
some
other
have
some
reusability
impacts.
D
A
So
what
what
I
try
to
start
with
the
notable
tags,
work
and
I
wish
I
had
been
able
to
put
more
time
into
that
is
to
have
something
like
an
on-ramp
where,
where
we
continue
to
to
make
them
more
interesting,
more
useful,
more
reusable
Tech
definitions,
more
accessible
and
explain,
for
instance,
explain
their
their
area
of
application,
which
the
original
registrations
often
don't,
and
that
would
be
something
that
that
we
could
move
forward.
A
One
question
here
is,
of
course,
is
this:
something
the
working
group
should
control,
or
is
this
something
that
that
actually
works
best
as
an
individual
draft,
because
you
can
be
much
more
opinionated
individual
draft.
D
Yeah,
it's
a
good
question
and
it'll.
It
would
depend
on
the
tag
the
one
that
I'm
running
into
the
problem
with
I,
send
an
email
to
the
to
the
list
and
I'll
follow
up
at
some
point.
The
is
the
it's.
The
coordinate
reference
system
tag.
D
The
I
I
send
them
an
email
before
I
send
an
email
to
the
list
to
see
if
I
can
talk
to
them,
but
I
have
received
no
response.
I
was
hoping
kind
of
the
put.
The
posting
on
the
list
would
result
in
the
original
registrant
popping
up
because
it
was
registered
originally
as
a
draft
intended
to
the
attention
of
the
working
group.
D
A
Yeah
so
I
think
I
replied
to
that
that
we
maybe
should
make
a
little
bit
more
attempt
to
find
the
original
registrant.
But
if
that
doesn't
work,
we
can
still
use
his
work
as
as
input
for
a
new
draft
and
yeah.
The
the
interesting
thing
about
the
CIS
thing
itself
is
that
it
is
pulling
in
a
standard
from
an
entirely
different
universe
that
has
its
own
representation
from
it
and
so
on.
Oh
yeah,
oh
yeah,
no.
D
It
one
of
the
things
that
we're
doing
on
a
number
of
places
with
this
token
that
I'm
working
on
elsewhere
is
that
the
there's
a
ton
of
pulling
in
additional
work
from
different
groups
and
kind
of
putting
it
together
so
that
nobody's
Reinventing
the
wheel
yeah.
That's.
A
Good
stuff,
yeah,
let
let's
try
to
work
on
the
CIS
thing,
I
think
it
would
be
good
to
to
have
a
community
of
people
work
on
this
and
not
just
the
singer
author,
but
we
should
try
to
find
find
him
first
and
and
only
steal
this
work
when,
when
we
have
to
give
up
on
that
good
I
think
we
have
15,
30.
E
I'm
here
thanks
thanks
for
keeping
things
running
here
so
far.
Is
there?
Is
there
anything
that
you,
you
know,
I've
owned,
I'm
still
only
skimming
through
the
nose?
Is
there
anything
that
you
would
like
to
wrap
up
on
those
topics
or
is,
or
are
there
outcomes
that
we
can
that
we
can
go
through
in
in
the
next
half
hour
anyway?.
A
Well,
we
had
some
some
useful
feedback
on
on
the
example,
so
I
showed
the
examples
from
from
these
slides,
starting
with
slide
three,
but
we
probably
should
discuss
the
the
working
group
view
of
this
as
well.
So
I
think
we
have
recorded
those
feedback
items
in
the
notes,
I'm
not
sure
we
have
to
to
revisit
them.
Well,
probably.
E
E
So
thing
things
that
have
been
discussed
now
are
basically
cddl
to
all.
Basically,
the
cdl2
roadmap.
A
Yes,
but
Chris
has
made
several
points
that
are
kind
of
tributaries
to
this
stream
and
I
think
it's
good
to
be
remembered
to
be
reminded
that
we
actually
have
to
address
these
other
issues
as
well.
A
E
E
So,
basically
picking
picking
up
here
in
the
middle
and
and
going
through
agenda
items,
quite
quite
frankly,
can
you
just
continue?
Can
you
just
continue
where,
where
you
left
off,
because
yeah.
A
Let's,
let's
go
through
the
agenda
quickly,
because
there
is
one
item
there
time
tag
that
I
would
like
to
quickly
talk
about,
and
then
we
can
go
back
to
the
CDL
too.
So
the
the
problem
with
time
tag
is
we.
We
have
a
pretty
complete
document.
From
my
point
of
view.
We
have
one
problem
that
came
up
in
the
discussion
half
an
hour
ago,
which
is
that
the
cddl
inside
this
document
isn't
as
complete
as
it
could
be.
A
So
the
the
that's
half
solved
right
now,
but
it's
only
half
solved,
but
the
more
interesting
thing
we
are
stuck
on
is
that
the
this
is
supposed
to
be
in
a
cluster
with
a
seedage
worked,
and
that
has
been
submitted
to
to
the
isg
quite
a
few
months
ago,
and
it's
not
quite
clear
how
this
is
moving
forward.
A
So
we
cannot
well.
We
can
just
submit
our
work
and
and
let
the
isg
figured
out,
but
maybe
it's
better
to
to
actually
work
on
this
in
the
working
group
until
we
fully
understand
what
will
happen
with
sedate
so
that
that's
at
least
slowing
me
down
at
some
point
we
have
may
have
to
give
up
on
on
waiting
for
that,
but
not
sure
we
are
quite
there
yet.
A
There
are
several
proposals
for
such
documents.
So
of
course,
the
next
thing
after
a
Time
tag,
is
that
you
want
to
have
something
like
designed
timestamps,
so
that
that's
interesting
for
Reds,
for
instance,
but
I
I
cannot
fully
answer
that
question.
It
would
be
nice
if
Hank
could
be
here,
but
Hank
and
Thomas
in
some
other
meeting
right
now,
so
they
have
a
standing
conflict
with
our
regular
interim
at
a
time.
That's
maybe
something
we
can
discuss
at
iitf116.
E
A
A
So
we
we
had
several
interim
meetings
with
with
segments
about
cdl2
and
to
me
it
seems
we
we
are
converging
on
a
pretty
well
defined
plan,
what
we
want
to
achieve
in
this
year
and
and
maybe
even
in
early
2024.
So
let
me
quickly
talk
about
this
plan
and
then
then
we
can
use
the
the
old
adage
that
no
plan
survives.
The
first
contact
with
the
well
enemy
doesn't
apply
here,
but
with
the
real
world
or
something
so
in
the
city
day.
A
2
draft
document
we
have
a
number
of
grammar
fix
some
of
these
router
fixes.
Some
of
these
are
genuine
emissions
in
the
original
38
syntax.
The
non-literal
tags
are
the
Omission
we
should
be
addressing
now
because
we
understand
it,
and
there
is
another
very
simple
change
which
allows
empty
files
because
it's
useful
to
be
able
to
use
empty
files
in
the
CDD
I
do
environment
so
that
that
could
be
extracted
from
the
draft
and
of
course,
we
probably
need
to
do
a
little
bit
more
checking
on
this.
A
So
in
particular,
the
non-literal
tags
turn
out
to
be
pretty
important
at
this
point
in
time,
and
since
we
understand
how
this
needs
to
be
done,
I
I
think
it
would
be
good
to
bundle
this
up
with
your
router
fixes
and
and
the
empty
files
thing.
A
So
that's
something
that
I
would
call
CDL
1.1,
because
it's
not
not
sweeping
changes,
it's
just
fixes
and
and
things
we
forgot
to
to
do
in
the
original
cddl,
so
yeah.
Let's
do
them
now.
In
parallel
to
that,
we
also
have
this
defined
extension.
Point
control
operators
and
the
more
control
draft
defines
a
few
more
control
operators
that
turned
out
to
be
useful
in
in
various
work,
where
we
are
interacting
with
other
data
representations,
so,
for
instance,
being
able
to
say
that
that
something
is
encoded
as
a
base64.
A
Text
string
is
useful
and
we
are
right
now
getting
feedback
from
people
who
want
to
use
this.
So
that's
also
something
that
is
already
implemented
in
in
the
way
that
that
it's
in
the
draft,
but
probably
will
get
a
little
bit
of
additional
feedback
before
we
can
Define
this.
So
this
is
I
mean
everybody
can
Define
control
operations.
This
is
a
registry,
but
having
a
few
more
that
are
a
little
bit
more
official
and
tailored
to
be
used
in
in
specifications
in
the
IHF
is
useful.
A
So
I
would
try
to
get
this
into
a
bundle
with
grammar
fixes
and
yeah
there's
precedent
for
that.
We
already
did
91.65
as
another
set
of
control
operators,
and
this
would
just
be
the
second
document
in
that
series
so
that
that's
short
term
and
I
like
to
call
this
CDA
1.1,
because
it's
not
really
not
not
changing
much.
Then
we
have
the
of
the
CDI
2.0
discussion.
A
We
have
the
modules
discussion
and,
at
the
start
of
the
hallway
part
of
this
meeting,
I
showed
a
few
slides
with
examples
how
this
module
stuff
looks
like
at
the
moment.
A
So
the
the
feedback
has
been
generally
positive,
although
it's
clear
that
there
are
things
in
cddl
that
that
would
benefit
from
more
composability
as
well.
So
I
would
expect
that
we
will
need
a
little
bit
longer
to
finish
that
than
the
the
grammar
fixes
and
control
operators
part,
but
we
should
be
done
before
ietf
well
before
IDF,
118,
I.
Think
again
it's
it's
implemented.
A
We
have
a
draft,
so
it's
we
are
not
no
longer
in
the
finding
out
what
we
actually
want
to
do
phase
we
we
are
in
the
actually
doing
it
phase,
so
that
would
be
the
Serie
A
2.0
part
and
then
of
the
various
things
that
are
left
in
the
freezer
and
and
the
CD
Electro
draft
document.
A
The
next
item,
quite
obviously,
are
annotations
and
ways
of
using
annotations
and
that's
something
where
we
we
all
have
wild
ideas,
but
I
think
we
haven't
really
started
to
to
bring
our
wide
ideas
together
and
and
see
what
we
can
do
with
that
and
whether
that's
useful
and
so
on.
So
annotations
is
not
a
new
idea.
Of
course.
Relax
and
G
has
annotations
so
so
that
that's
kind
of
a
minimal
backstop
we
can
have.
A
If
we,
we
don't
have
any
good
ideas.
We
just
steal
the
relax
NG
annotations,
and
that
would
be
section
three
of
the
cdl2
draft
and
of
course,
one
of
the
annotations
that
we
want
to
have
is
being
able
to
put
in
co-occurrence
constraints
like
schematron,
provides
them
via
annotations
to
relax
NG
but
yeah,
of
course
not
for
XML,
but
for
for
Jason
Siva,
like
data
and
I
mentioned
that
the
Json
path
is
producing
something
that
might
go
into
that
as
well,
so
that
that
would
flow
together
then.
A
A
We
probably
want
to
get
some
interability
and
Tool
integration,
and
there
is
a
section
in
the
freezer
document
that
shows
a
CDL
and
Json
format,
and
we
probably
want
to
agree
on
that.
I
mean
this
is
this
is
not
not
for
the
actual
interchange
of
of
the
data
that
are
described
by
Citadel,
but
it's
for
interchange
of
CDL,
between
tools,
and
that
is
useful
if
we
can
agree
on
on
the
right
way
to
do
this.
A
So
cdisc
already
defined
such
a
format
and
I
think
this
can
be
improved
on
and
but
it's
something
that
that
will
naturally
fall
out
of
the
implementation
work.
So
I
would
expect
that
we
will
have
that
together
with
cddl
2.0
and
should
just
decide
to
actually
write
this
up
and
I'm
putting
the
the
letter
I
here
for
informational,
because
it
that's
not
really
something
that
that
we
need
to
standardize.
But
it's
still
something
we
want
to
agree
on.
A
The
second
item
is
collecting
cddl
models
from
rfcs,
so
the
the
serial
C
tool
comes
with
a
collection
of
models
from
existing
rfcs
which
isn't
complete.
But
it's
a
start.
I
think
some,
some
20
CDA
models
are
in
there
and
we
we
probably
want
to
make
them
available
in
a
way
that
we
actually
can
reference
them
right.
C
Thank
you.
You
know
the
the
gang
guys
have
this
thing
gang
catalog.org.
Are
you
familiar
with
it?
Yes,
okay,
so
I
wonder
if
we
should
be
thinking
about
ccdl
catalog.org,
wouldn't
that
provide
an
infrastructure
for
other
stos,
as
well
as
the
iitf
to
provide
those
modules
in
a
way
that
everybody
can
find
them.
It's
just
a
brainstorm.
A
A
C
Not
100,
true
because
it's
run
by
the
iitf
tools,
team
and
the
ietf
loc
funded.
A
Recognize
that
both
statements
are
true,
correct,
correct,
so
just
provided
the
other
side
of
the
coin
yeah,
but,
but
still,
we
would
probably
need
to
think
about
how
this
this
CDI
catalog
would
work
in
in
such
a
way
that
it
can
be
as
useful
as
the
catalog.org
without
being
entirely
dominated
by
iitf
processes.
C
Indeed,
in
fact,
in
fact,
Yang
catalog
went
through
a
struggle
with
that
for
a
little
while,
but
came
to
a
place
that
ietf
and
IEEE
802
are
now
both
comfortable
in
all
the
IPR
stuff
has
been
sorted
out.
A
A
I'm,
not
sure
that
this
makes
the
the
draft
I
was
talking
about
Superfluous,
because
the
the
serial
models
draft
would
would
essentially
be
referenceable
in
iitf
and
other
SEO
documents.
I'm,
not
sure
whether
we
would
achieve
that
with
a
CDA
catalog
.org.
So
there
would
be
some
work
that
that
brings
the
the
models
that
have
been
defined
in
the
last
six
or
seven
years
up
to
to
a
level
that
they
are
easily
referenceable.
A
Okay,
so
the
the
two
eyes
here
are
pretty
important
from
my
point
of
view
that
there
are
three
more
items
that
I
would
think
are
useful,
but
maybe
a
little
bit
more
on
the
back
burner.
One
is
the
literals
issue,
application
specific
literals.
A
So
we
probably
want
to
bring
this
together
in
a
way
and
and
see
what
what
we
can
put
there.
So
the
point
here,
of
course,
would
be
to
have
that
in
an
extensible
way,
you
would
be
able
to
register
a
prefix
for
these
things,
and
so
somebody
like
something
like
the
CRI
document
draft
IDF
call
href
could
simply
Define
a
way
to
annotate
Cris.
That
is
looks
better
on
whiteboards
than
than
the
fully
rolled
out
sibo
for
that.
A
So
at
some
point,
cdda
tool
should
should
be
able
to
to
consume
these
literates
number
four
is
an
attempt
to
write
up
how
a
useful
process,
how
we
actually
deal
with
numbers
out
of
number
spaces
that
Ayana
actually
has
to
allocate
during
the
development
of
drafts.
So
if
you
haven't
seen
that
document,
that
would
be
great.
A
If
you
have
a
look
at
it
and
and
comment
on
it,
this
doesn't
even
have
to
be
published
as
an
RFC,
but
it's
it's
has
already
turned
out
to
be
useful
to
appoint
other
people
to
as
a
way
of
of
solving
that
problem,
so
that
an
internet
drafters,
look
like
it's.
It's
squatting
on
on
numbers
and
finally,
I
know:
that's
probably
not
that
important
for
ietf
documents,
but
there
are
so
many
things
that
are
done
in
CSV
and
comma
separated
variables.
A
A
Whether
people
consider
this
useful
so
just
for
fun,
I
took
the
core
Sid
format
and
defined,
which
is
done
in
in
Json,
using
Ying
model
and
I
did
a
CSV
version
of
that
and
actually
provided
the
CDA
for
that
CSV
version
and
well,
you
can
put
this
stuff
into
Excel,
so
it's
it's
really
great
to
use
during
development.
Is
that
a
feature
or
a
bug?
E
More
seriously,
we
are
approaching
approaching
the
end
of
it
of
the
time
that
DC
board
block.
Is
that
something
you
want
to
spend
many
words
on,
because
if
so
will
we
might
aren't
here?
E
A
Let
me
just
quickly
say
it's
really
fun
to
look
on
at
the
YouTube
presentation,
the
YouTube
presentation
on
DC
board
I.
Rarely
look
at
YouTube
presentations
that
I
can
essentially
check
off
almost
all
slides
off.
There's
one
slide
where
I
would
have
comments
on,
but
everything
else
is
really
nice
or
send
this
presentation
to
other
people
who
are
trying
to
understand
why
people
are
using
a
c
boy
and
watch
what
way
they
are
using
it.
That's
pretty
good
anyway,
so
yeah
any
any
comments
on
the
CSV
thing,
foreign.
B
I
have
a
comment,
but
on
draft
numbers,
so
I
read
version
0
of
the
draft.
Thanks
for
writing.
It
I
was
wondering
and
there's
also
in
the
mailing
list.
You
consider
especially
receiver
maps
to
give
examples
and
you
focus
on
the
identifiers
used
for
the
map
keys,
but
can
the
same
approach
be
used
also
for
the
map
values.
B
B
A
So
now
now,
I
would
like
to
to
ask
whether
the
the
mainline
plan,
plus
augmented
by
the
information,
what
we
are
not
doing
in
the
main
line,
because
we
are
doing
in
these
other
documents,
whether
that
that
looks
like
a
good
way
forward.
Of
course,
we
can
can
refine
this
plan
at
any
point
in
time,
but
it
would
be
good
to
know
whether
that
is
something
we
want
to
go
forward
on.
A
F
I
wanted
to
ask:
is
cddl
2.5,
really
cddl
2.5
a
second
RFC
and
document,
or
is
it
work
in
2024
on
a
cddl
2.0
that
is
not
published
until
foreign.
A
F
F
A
B
A
E
A
So
may
have
had
a
time
zone
problem
there.
F
E
Let's
pre
I
suggest
we
briefly
wrap
up
the
things
that
we
can
kind
of
officially
do,
and
we
can
then
still
use
the
time
that
the
room
is
open
if
people
are
still
around
to
at
least
coordinate
a
bit
further
on
the
agenda
for
for
the
ipf
160,
because
that
is
something
that
we
need
to
that.
We
should
get
a
good
grasp
on
today.
Time
tag
already
has
a
good
slot.
There
cddl2
will
as
I
understand.
E
This
roadmap
need
both
some
some
general
talking
time
about
the
directions
and
sometimes
for
individual
documents.
E
Custom,
do
you
have
preferences
which
one
you
would
like
to?
Are
there
something?
Are
there
concrete
ones
that
you
want
to
prioritize
in
presenting.
A
A
This
should
probably
just
be
just
be
a
dissemination
thing
and
we
probably
should
focus
on
the
modules
part
and
we
definitely
won't
have
good
input
for
the
annotations
yet
so
the
the
first
three
items
on
the
slide
we
are
looking
at
I
think
should
go
on
116.,
possibly
with
some
of
the
next
slide,
but
the
first
three
other
ones
where
we
really
want
to
make
progress
so
obviously
for
all
three
working
group
adoption
is,
is
necessary.
Next,
Step
and
yeah
I
leave
it
to
the
chairs
to
decide
how
we
are
going
to
do
this.
A
E
E
A
Yeah
I
think
well,
maybe
the
draft
numbers
thing
is
is
worth
some
some
discussion,
but
I
think
the
others
are
really
items
that
can
be
done
very
well
on
the
mailing
list
and
in
future
entrance.
E
E
That
I
think
we're
a
bit
over
time
and
done
with
the
with
the
agenda
points.
So
I'd
like
to
conclude
the
official
part
of
the
meeting,
but
also
welcome
world
first
joined
us.
Did
you
was?
Was
there
an
issue
with
the
time
zones?
Would
you
would
you
present?
G
Hello
yeah
hello,
good
morning
our
good
morning
here,
where
I
am
yes:
well,
I,
don't,
apparently
there
was
some
miscommunication
about
the
times
or
time
zones
and
I
was
expecting
it
to
be
at
7
30
a.m.
Pacific
time
and
I
apparently
didn't
get
the
link
in
time
as
well.
So
you
know
I'm
happy
to
either
answer
any
questions.
G
People
have
if
they
have
time
and
want
to
stick
around
for
that
I
think
we
are
planning
on
coming
to
the
next
IET
general
meeting
at
that
point,
we're
just
about
to
publish
the
internet
draft
for
our
recommendations
and
practices
for
discernments
at
seabor,
and
so
you
know
I'm
I'm
at
your
service.
If,
if
you
have
any
initial
questions,
I
can
also
post
the
link
to
the
to
the
editor's
draft
on
GitHub
docs.
E
Given
that
shortly
means
by
by
the
start
of
next
week,
I
think
that
would
be
a
good
starting
point
seeing
that
people
are
not
leaving
yet
and
frankly,
I
haven't
managed
to
follow
the
discussion.
Could
you
give
like,
while
people
are
still
here,
just
a
brief
intro
to
what
you're
doing
and
what
the
goals
are.
G
Yeah
so
obviously
well
blockchain
Commons
I'm,
the
lead
researcher
for
blockchain
Commons
is
a
non-profit
working
in,
as
it
suggests,
the
name
suggests
in
the
blockchain
space,
we're
trying
to
help
wallet
developers,
but
also
other
kinds
of
developers
who
work
with
either
cryptography
or
secure
kinds
of
documents
not
have
to
reinvent
the
wheel.
In
a
lot
of
cases
and
the
stack
of
Technologies
we've
been
developing,
which
is
entirely
open
source.
G
You
know,
we've
often
had
the
need
to
serialize
various
kinds
of
data,
and
we
want
to
do
it
in
a
very
kind
of
stable
way,
because
when
we're
talking
about
possibly
hashing
and
or
even
things
like
signing
or
encrypting,
you
know,
the
actual
stability
of
the
data
is
very
important,
especially
if
there's
going
to
be
many
people
who
are
verifying
documents
or
in
the
case
of
our
Guardian
envelope,
standard
or
proposed
that
you
know
even
like
the
user,
can
aligned
parts
of
the
document
and
that
relies
on
a
Merkle
tree.
G
That's
baked
into
the
document,
and-
and
so
you
know
we
as
we're
developing
these
things-
we've
done
a
number
of
seaboar
structures
that
we've
published
on
our
GitHub,
repellent
on
our
research
repo
and
then,
when
we
developed
recording
envelope,
we
decided
that
okay,
we
need
to
make
sure
that
the
the
binary
level
that
we're
basing
this
on
is
very
stable,
and
so
we
not
only
receivable,
but
we
started
to
zoom
in
on
the
deterministic
aspect
of
Seymour
and
as
we
started
looking
for
because
obviously
we'd
like
people
to
you
know
adopt
these
structures.
G
We
wanted
to
make
it
so
that,
and
as
an
engineer
for
over
40
years,
I
personally,
you
know
want
apis
and
structures
and
so
on
that
are
inviting
in
easy
to
use
and
some
of
the
Alternatives
in
the
space
like
Jason,
LD
and
so
on
are
in
you
know,
just
in
my
humble
opinion,
a
bit
of
a
mess
and
very
hard
to
approach
in
many
ways
and
I
wanted.
It
was
easier
to
approach
both
on
an
API
level
as
well
as
the
actual
structure
that-
and
you
know
so.
G
Seabor
was
an
obvious
choice.
Actually,
it
took
us
a
little
research
to
decide
that
SeaWorld
was
throughout
his
choice,
but
we
landed
on
that
and
but
the
deterministic
specification
did
have
a
number
of
loose
ends
to
it
that
we
realized.
We
would
like
to
kind
of
tighten
up,
and
so
we
actually
implemented.
We
have
a
rust
and
a
swift
implementation
of
our
deterministic
sea
war,
and
then
we
realized
okay.
G
Well,
we
definitely
need
to
document
this,
and
so
that
has
become
our
our
internet
draft
that
we'll
actually
probably
be
published
as
a
zero
zero.
Within
an
hour,
and
mostly
it's
about
things
like
it's
a
it's
both
it's
it's
a
set
of
requirements
primarily
for
for
codex
for
C
War,
both
in
terms
of
things
that
DC
bore
codex,
must
Implement
and
also
a
suggested
set
of
best
practices
for
C
implementers.
G
It's
not
actually
a
replacement
or
a
different
dialect
of
Seaboard
itself,
and
everything
that
conforms
to
DC
board
is
decodable
is
straight
Seaboard.
Not
everything
that
is
encoded
in
Seaboard
is
validatable
as
DC
War,
for
instance.
You
know.
Obviously,
Seaboard
allows
out
of
order
map
Keys,
whereas
we
require
map
keys
to
be
in
order,
and
we
want
to
put
as
much
burden
on
the
actual
codec
and
remove
as
much
burden
as
possible
from
the
engineer
working
with
the
API.
G
So
so
there's
certain
things
that
we
are
requiring
the
codec
to
do
that
is
DC,
more
compliant
and
other
things
that
we're
we
are
admonishing
the
developers
to
do,
because
the
codec
can't
do
them,
but
that's
both
the
both
of
those
are
in
the
internet
draft.
G
You
know
with
that
said,
I'd
be
happy
to
you
know,
answer
other
questions
or
go
in
other
directions.
If
you
wish.
E
C
A
G
Wow
thanks.
Thank
you.
I'm
I'm,
flattered
yeah,
the
the
right
our
blockchain,
Commons,
YouTube
channel,
does
have
a
number
of
videos
up
on
both
in
our
Technologies
and
the
various
technological
choices
we've
been
making
and
our
motivations
for
those-
and
you
know,
and
I
always
want
to
make
sure
that
we're
you
know
we're
building
on
the
best
of
of
what
already
exists
and
inventing
as
little
as
possible.
But
when
we
do,
we
want
to
make
sure
our
motivations
for
our
inventions
and
and
new
proposals
are
clear.