►
From YouTube: IETF111-CBOR-20210730-2130
Description
CBOR meeting session at IETF111
2021/07/30 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
I'd
wait
a
few
more
moments
to
get
started
also
because
carson,
who
will
be
do
the
most
most
of
the
presenting
today,
is
not
here
yet
meanwhile,
david
or
ira.
Could
you
help
with
a.
A
A
I
see
marco
on
the
on
the
code.
Emd.
Can
I
take
this
as
a
sign
that
you
would
help
whoever
whoever
does
the
main
minutes
or
even
take
that
drill.
A
Thank
you
and
I
think
presenter-wise
we
are
now
complete.
So
I'll
start
this
meeting
hello,
everyone.
This
is
the
sibo
meeting
at
itf
111
we're
meeting
in
san
francisco.
As
you
all
know,.
A
A
The
first
point
of
the
agenda
is
the
agenda
bashing,
so
I
run
I'll
run
through
this
quickly.
We're
having
a
few
working
group
documents
that,
where
I'll
start
with
what
has
been
published
and
then
karsten
will
take
over
and
go
through
the
documents,
there's
already
one
change.
That
will
that's
not
reflected
in
the
agenda.
Yet
that
is
that
carsten
will
do
the
main
talking
on
the
also
on
michael's
documents,
because
michael
is
switching
back
and
forth
between
another
meeting.
A
That
happens
at
the
same
time,
and
then
we
have
notable
tags
and
the
cdl
freezer
as
individual
documents.
That
may
not
stay
like
that
forever
and
if
you
sum
that
up
we'll
have
a
few
minutes
to
spare-
and
let's
hope
we
make
good
use
of
our
time
any
comments
on
that
anything
you'd
like
to
bring
up
now
before
we
go
over
to
the
actual
documents.
A
A
Just
about
two
weeks
ago,
thanks
to
carstenshaw
and
all
the
reviewers,
this
wall
used
to
be
a
tags
oid
and
will
be
put
into
good
use
in
various
kinds
of
documents
that
would
deal
with
object,
ids,
but
want
to
do
this
in
a
in
a
keyboard
environment.
A
D
Okay,
so
I
think
I
have
52
minutes
to
talk
about
10
documents.
Some
of
them
need
more
talking
than
others,
so
I
will
be
very
brief
and
your
job
is
to
slow
me
down
when.
D
D
A
cdi
control,
completed
working
group
last
call
and
the
one
thing
we
did
was
to
to
make
that
both
handed
it
was
right-handed
before
and
the
tool
already
has
been
updated,
so
you
can
play
with
it
and
what
I
need
to
do
in
the
next
few
hours
after
the
meeting
is
process
christian's
remaining
comments
and
submit
the
show
for
and
then
we
should
have
an
isg
submission
soon.
D
D
We
have
two
documents
whose
working
plus
call
ends
today,
and
they
are
both
michael's
documents.
So
the
sibo
file
magic
is
a
very
nice
document.
I
think
we
really
have
achieved
what
we
wanted
out
of
that,
but
there
was
no
feedback
whatsoever
in
the
working
class
core
and
one
problem
with
that
is
that
I'm
now
a
co-author.
So
I
couldn't
send
my
review
and
I
probably
need
to
make
a
habit
out
of
sending
reviews
for
documents
that
I'm
a
co-author
on.
So
please
look
at
this
document.
D
It's
not
big,
but
it
will
shape
the
way
we
will
be
labeling
our
files
going
forward.
So
we
have
to
get
that
right.
One
question
is
whether
we
want
to
do
the
other
tax
registration
registration.
We
already
have
50
5
800
registered,
but
do
we
want
to
do
the
content
format,
tags
that
are
proposed
in
the
appendix
as
well
at
this
point
in
time,
so
that
that
would
be
a
nice
thing
to
give
feedback
for
here
or
on
the
mailing
list
yeah?
So
please
review
this
document
and
and
send
feedback.
D
D
The
the
other
one
is
network
addresses
where
we
had
some
some
pretty
lively
discussion
on
on
various
aspects,
and
I
thanks
john,
and
I
think
we
we
have
converged
on
on
having
formats
for
addresses
for
prefixes
and
for
addresses
with
prefixes
like
you.
Would
find
in
an
interface
specification
one
last
minute
last
hour
last
week
comment
what
that
came
up
was.
D
Do
we
actually
want
to
address
zone
ids?
For
instance,
the
yang
ipv
x,
address
data
types:
do
support
zone
ids,
that's
these
percent
e
and
zero
things
you,
you
probably
have
never
seen
because
you
haven't
used
that
feature.
Yet
we
got
some
interesting
feedback
from
young
people
that
the
fact
that
these
are
included
in
yang
ip
addresses
makes
it
too
easy
to
actually
specify
a
zone
by
mistake
when
you
didn't
want
that,
so
that
that
was
an
interesting
point.
D
The
other
point
is
that
the
whole
zone
do,
you
think,
is
pretty
fluid
at
the
moment,
because
rc
684
47,
which
tells
you
how
to
put
the
zone
id
into
a
uri,
is
being
re-visited,
and
so
we
we
also
have
some
some
confusion
about
zone
ids
versus
zone
names
versus
zone
numbers
and
photo
4007
tells
you
that
zone
numbers
are
the
canonical
way,
but
most
people
seem
to
be
using
zone
names.
D
It's
probably
a
good
idea
to
to
wait
for
that
discussion
to
end
and
go
ahead
with
the
unzoned
network
addresses
first,
and
I
would
expect
the
zone
ids
to
be
addressed
by
by
draft
ietf
core
href,
which
defines
the
ui
the
the
concise
ui
format,
the
cri
format,
and
there
we
certainly
need
to
put
in
a
way
to
do
zone
ids
in
the
8647
way.
D
D
Okay,
so
what
we
recently
adopted
was
the
draft
ietfc
time
tag
that
has
actually
been
a
stable
document
for
a
while,
and
I
think
what
we
need
to
decide
now
is.
Is
that
something
that
we
want
to
add
to
now,
or
is
that
stable
document
good
enough
as
a
vr
v1,
and
you
can
always
go
ahead
and
define
more
properties
that
can
go
into
the
map
defined
by
this
document?
D
D
D
D
It
started
at
this
ietf
meeting,
yeah
very
good,
so
I
think
we
can
just
see
what
happens
there
and
either
update
our
tag.
Zero
or
come
up
with
another
text
based
tag
and
for
the
the
binary
base
tag.
One
this
tank,
1001
and
the
related
tanks
are
an
extension
with
more
functionality,
so
you
can
actually
say
this
is
tai
and
not
utc,
and
so
on
and
so
on.
So
we
need
reviews
from
people
who
were
programming
this
stuff.
D
Of
course
it
would
also
be
good
to
get
one
or
two
reviews
from
people
who
really
know
their
way
around
times,
so
some
real
time
nuts.
What
would
be
great
to
have
as
well.
C
Yeah
I
was
just
coming
over
here
to
to
say
to
let
people
know
about
the
sedate
working
group.
Apologies
that
I
haven't
really
been
paying
much
attention
to.
What's
going
on
in
seaboard,
I
will
review
this
document
to
cross-check
whether
anything
is
an
issue
with
today.
I'm
one
of
the
sedate
working
group
chairs,
and
certainly
anyone
who
is
interested
in
this
please
do
come
and
contribute
to
sedate
as
well.
I'm
very
keen
to
make
sure
that
everything's
cross-compatible
between
the
two
specs
thanks.
D
D
So
I'm
pretty
sure
that
the
the
shared
prefix
suffix
tags
that
are
in
the
document
right
now
work
as
they
are,
but
we
need
to
build
the
tables
that
that
these
reference-
and
maybe
we
have
to
think
about
other
modes
that
that
are
interesting.
So
I'm
going
to
talk
about
chris
zips
records
at
the
end
and
there's
also
the
the
template
definition.
D
So
I
think
these
are
two
candidates
that
could
go
in
there
as
well,
or
maybe
we
don't
even
need
them
to
go
in
there.
Maybe
we
can
define
packed
in
such
a
way
that
you
can
just
put
backpacks
on
the
packed
specification
and
if
you
need
templates,
you
just
use
them
and
make
sure
that
you
understand
how
they
actually
enter
the
terry
building,
so
that
that's
various
process
approaches
are
thinkable
there
and
we
need
to
find
out
what
we
want
to
do
so.
D
Yeah
use
cases
are
probably
needed
to
actually
exercise
these
implementations
and
we
have
a
nice
set
of
of
c509
objects.
That,
from
from
john
watson,
that
I
plan
to
work
on
with
my
implementation.
Unfortunately,
those
uncovered
a
bug
in
my
implementation-
and
I
didn't
have
time
before
the
itf
to
fix
the
bug.
But
that's
certainly
one
thing
we
will
look
at,
but
if
you
have
other
use
cases,
please
try
this
out.
D
D
So,
for
instance,
if
we
have
a
static
dictionary
that
goes
with
a
particular
area
of
application,
then
we
want
to
make
sure
that
the
static
dictionary
which
is
defined
outside
the
c-board
data
item
works
together
with
any
dictionary
that
is
any
table
set
up
that
is
defined
inside
the
document.
So
having
good
use,
cases
for
that
would
also
be
useful.
D
So
yeah
my
question
would
be:
is
that
something
we
want
to
think
about
possibly
splitting
the
document
between
table
set
up
and
and
the
referencing
tags,
because
those
are
starting
to
get
stable?
Maybe
we
want
to
do
this
entirely
without
a
basic
table
setup.
D
In
that
case
the
the
referencing
tags
would
be
defined,
but
not
unusable,
or
maybe
we
want
to
put
in
just
a
simple
basic
table
set
up
approximately
what's
in
the
current
document
and
wait
for
more
understanding
of
our
use
cases
and
so
on
before
we
do
the
more
complicated
heavy
setup
mechanisms.
D
Of
course
we
also
should
be
talking
to
our
various
customers.
Suit
might
have
been
a
customer,
but
we
were
too
slow
for
that.
But
it's
still
a
use
case.
We
can
try
to
fulfill,
but
there
are
also
other
work
groups
that
maybe
can
use
this
out
of
the
area
of
attestation
and
security
and
so
on,
and
we
could
throw
coverim
or
cosmet
or
something
like
that
in
there
and
see
whether
there's
anything
useful
happening.
E
Hi
brendan
morin
at
the
mic
and
speaking
in
terms
of
what
we
would
have
done
in
suit.
E
If
we'd
adopted
seabor
pact,
we
definitely
would
need
nested
dictionaries
and
not
one
pre-shared
and
one
received
with
the
manifest,
but
in
fact,
two
dictionaries
or
even
more
in
a
single
in
a
single
manifest
envelope,
and
the
way
that
this
would
work
is
that
suit
has
a
few
pieces
that
get
put
into
a
container
and
there's
one
of
them
that's
signed
and
the
others
are
authenticated
by
digest.
E
So
when
the
point
of
this
is
that
they
can
be
removed
and
the
removable
pieces
would
also
want
to
be
able
to
make
use
of
the
of
the
table,
the
table,
that's
in
the
in
the
signed
part,
the
other
parts
might
have
their
own
metadata.
That
needs
to
be
packed
separately,
and
so
those
tables
would
need
to
be
discarded
when
the,
when
the
metadata
that
they
are
with
gets
discarded.
So
essentially,
we
would
end
up
with
a
tree
of
tables.
E
A
Suit
just
a
question
for
understand
for
understanding
this:
did
you
say
that
the
there
is
a
this
tree
with
the
innermost
thing
being
the
being
the
the
non-detachable
part,
but
the
definition
from
in
there
would
be
used
outside
of
that
tree
as
well.
E
So
the
idea
would
essentially
be
that
the
root
of
the
tree
is
the
the
shared
table.
But
then
each
of
the
leaves
in
the
tree
have
their
own
table
and
that's
simply
because
they
are
detachable
from
the
root
they
wouldn't
ever
be
used
separate
from
the
root
they'd
be
discarded
just
to
be.
A
F
F
C
D
Do
you
have
a
spec
that
you
could
point
to
john.
F
I
don't,
unfortunately,
and
and
even
more
unfortunately,
the
the
folks
doing
this
work
would
prefer
not
to
do
it
in
the
ivf.
So
it's
a
it's
a
it's
an
out
of
space
customer.
C
D
Well,
bronze
says
feels
like
xml
namespaces
and
actually
the
the
the
one
document
that
pushed
us
forward
with
was
doing.
The
spec
work
is
the
coral
document,
which
is
essentially
doing
something
a
bit
like
xml
namespaces
in
the
form
of
queries
and
that
that's
another
form
of
packing
long
uris.
So
I
think
this
is
all
pretty
pretty
much
related.
There's
really
nothing
new.
C
D
The
sun
here
but
yeah
again,
we
have
to
make
sure
that
our
design
actually
works.
Well
with
that
and
it's
going
to
be
more
complicated
than
carries.
D
F
One
of
the
other
challenges
that
we've
had
just
in
the
area
of
using
seaboard
just
generally
for
efficient
document
transfer
is
that,
sometime
with
when
you're
you
know,
if
I
have
a
client
that
is
asking
for
you
know
xml,
json
or
cbor,
then
they
use
the
accept
encoding.
To
signal
that
I
don't
currently
have
a
way
to
use
accept
encoding.
F
To
signal
that
I
want
packed
seaborne,
because
paxibor
is
really
quite
different
than
regular
seaboard.
Technically.
C
F
Is
just
seymour
but
you're
not
going
to
understand
it
unless
you
understand
pax
seaborg,
and
so
I
mean
we
can
use
out
of
band
signaling
mechanisms,
but
it
feels
like
the
you
know.
It
should
be
seabor
plus
packed
or
something
there
should
be
some
way
to
signal
in
the
mind
type
that
this
fairly
sizable
extension
to
seabor
should
be
understood.
D
A
Kristen
amsas
from
the
floor,
but
isn't
this
the
same
with
basically
any
any
seaboard
extension
not
only
packed
that
it
may
or
may
not
be
part
of
a
particular
document?
I
mean
you
usually
what
you
do
when
you
request
with
with
accept
with
say,
say
an
xml,
json
or
c
format.
A
Is
that
you
don't
say
you
just
take
c,
but
you
just
take
a
particular
a
particular
instant,
a
particular
shape
of
seabor,
and
then
that
shape
could
mandate
the
use
of
packed
zebra
or
could
have
a
distinction
between
whether
it
can
use
that
shape
and
all
that
shape
was
packed,
but
it
might
have
profiling
on
it.
That
says
that
you
can
only
do
these
or
those
packings
and
it
might
also
in
its
versioning
or
features
allow
other
tags.
So
I'm
not
sure
a
structured
suffix
would
what
would
be
the
solution
here.
F
Right
so
you
had,
I
hope,
I'm
not
interrupting
the
I.
I
realized
that
what
I
was
suggesting
could
go.
You
could
be
infinitely
detailed
about
right.
You,
you
could
try
to
like
describe
all
possible
extensions
at
all
types
that
you
understand
and
that
that's
obviously
crazy.
F
But
if
you
have
the
pax
cbor
feels
kind
of
special
to
me
right.
It's
one
really
big
component
and
most
of
the
complexity
on
what
you
support
for
pax
sebor
is
different
ways.
You
support,
putting
it
together
and
encoding
it
right.
F
How
smart
are
your
various
table
formats
and
and
whatnot,
whereas
on
the
accepting
it
on
the
parsing
it
it's
really
fairly
straightforward.
You
follow
the
rules,
and
so
pax
seymour
feels
different
to
me,
but
maybe
it's
not.
D
D
D
A
We
are
a
bit
ahead
of
time,
but
maybe
I
didn't
elect
enough
for
notable
tags
in
the
freezer,
so
go
ahead.
If,
if
there
are
no
more
questions.
D
D
So
the
the
observation
is
that
the
tanks
registry
is
just
this
unsorted
brain
dump
and
if,
if
you
are
approaching
that
and
and
wondering
what's
the
best
way
to
put
in
a
128-bit
floating
point
number
into
seaboard
that
that
french
history
is
not
going
to
be
very
helpful,
so
the
idea
is
to
have
a
document
that
provides
an
overview
over
important
tags.
That
doesn't
mean
that
other
tags
are
not
important.
D
But
of
course,
if
you
are
you
care
about
cheese
firmness,
and
there
is
a
tag
for
cheese
form
in
terms,
you
will
find
it.
D
But
if
you
care
about
floating
point
numbers,
there's
lots
of
stuff
in
there
there's
rational
numbers
and
all
kinds
of
interesting
stuff,
and
it's
probably
good
to
have
some
narrative,
which
part
actually
needs
to
be
used
for
what
so.
My
hope
was
that
this
document
could
be
also
be
a
little
bit
more
opinionated
than
the
registry,
but
we
already
have
started
with
that.
So
the
the
network
address
document
refers
to
tag
261
and
says
that's
interesting,
but
unfortunately
it's
underspecified,
so
you
cannot
use
it.
D
So
I
think
we
when
that's
true.
We
just
have
to
to
take
that
opinionated
view
as
well,
and
that
document
might
be
a
replacement
for
for
trying
to
add
something
like
a
recommended
column
or
something
where
we
say.
Oh
this.
This
is
something
you
should
use,
and
this
is
something
you
should
maybe
use
less
and
that
that's
problematic,
because
the
attack
may
be
used
in
a
particular
application
specification
and
that
application
specification
doesn't
suddenly
become
out
of
date
just
because
they
are
using
a
tag
that
is
less
flexible
than
what
we
have.
D
So
it's
a
little
bit
different
from
security
specifications
where
a
specification
really
gets
out
of
date
and
broken,
and
you
should
no
longer
use
it.
So
we
shouldn't
use
that
as
as
a
model
and
that's
why
we
don't
have
recommended
columns,
but
instead
have
this
document
so
yeah
the
the
discussion
came
up
whether
we
should
add
something
like
a
recommended
column,
and
this
is
essentially
just
a
reminder.
We
have
this
document
and
pull
requests
are
welcome
and
yeah.
This
needs
lots
of
more
work
before
it
really
becomes
useful,
but
we
can
do
that
incrementally.
D
So
at
some
point
we
can
write
the
the
section
about
the
zero
number
system
and
which
tanks
support
it,
and
then
we
can
do
something
else,
so
this
this
can
grow
over
time.
I
think
this
will
be
a
couple
years
before.
That
really
is
useful
and
of
course
the
question
is:
when
do
we
publish
it,
then,
because
publishing
it
is
kind
of
anathema
to
it
being
a
current
directory
anyway.
D
So
I
think
we
we
don't
have
immediate,
immediate
rush
to
to
move
this
forward,
but
we
also
have
this
as
a
work
item
that
actually
can
help
people
who
are
not
finding
the
right
tags.
A
So
the
registry
note
currently
just
basically
describes
what
tags
are
and
with
with
basically
working
group
consensus
and
ad
blessing.
We
can
update
that
note
to
refer
to
a
future
itfc
for
notable
text
document.
That
would
then
be
something
that
even
while
not
published,
is
usable
guidance
for
people
using
that
registry.
D
D
So
having
having
a
document
with
a
revision,
history
and
comments
and
pull
requests,
and
so
on
is
probably
a
good
idea,
and
when
we
do
did
similar
things
in
the
rock
working
group,
we
we
did
decide
at
some
point
to
actually
publish
it
because
it
had
a
shape
where,
where
it
was
useful.
But
of
course
further
issues
came
up
later
on.
So
it's
just
okay
to
publish
a
working
document
at
some
point
and
then
start
with
abyss
right.
D
D
D
Okay,
let
me
move
forward
to
some
some
newer
stuff,
so
we
have
this
freezer
document
that
that
we
generated
briefly
before
8610
was
published
the
city
specification,
and
that
was
good
for
two
reasons.
It
captured
what
we
had
in
mind,
and
it
also
was
a
freezer
because
we
could
say
yeah.
D
This
is
a
good
idea,
but
we're
going
to
do
this
in
the
next
version
and
we
will
put
the
idea
in
the
freezer,
so
we
can
get
it
fresh
from
there
when
we
finally
have
time
to
do
this,
and
we
did
quite
a
few
of
those
things
in
terms
of
control
operators.
So
I
think
we
have
like
10
more
control
operators
than
8610
had,
but
the
question
is:
when
do
we
actually
touch
the
language
again
and
the
we
can
probably
group?
What's
in
there
into
three
categories?
D
One
is
more
control
operators.
There
are
a
few
things
in
there,
but
I
think
they
they
can
stay
in
the
freezer
for
a
while.
We
are
not
that
hungry
for
for
them
at
the
moment.
D
So
I
think
we
we
pull
them
out
when
we
have
a
use
case
that
can
immediately
make
use
of
that.
So
I
think
that
that
some
people
would
be
pretty
happy
with
the
midfield
design,
but
we
have
to
work
on
that
a
little
bit
more
so
that
that
may
be
an
exception
to
what
I
had
here
and
christian
of
course
has
a
great
idea
how
to
do
bitfields
with
dot
catch,
but.
D
So
yeah.
The
second
point
is
things
that
really
would
change
the
language,
so
I'm
sure
we
have
to
work
on
cuts
for
for
cda
2.0,
I'm
not
so
sure
we
need
to
work
on
a
literal
syntax,
so
I
I
said,
give
one
a
zero
and
one
and
minus
we
definitely
will
have
to
to
put
in
the
clarifications
that
we
are
collecting
so
that
there
are
some
errata
that
that
have
rather
reports
that
have
some
good
clarifications.
D
D
So
we
just
had
that
in
the
bundle
spec
in
the
dtn
bundle,
where
the
security
spec
of
course
needs
the
cdl
from
the
base
back
and
right
now
that
that's
just
there
in
english,
so
you
have
to
sit
down
and
actually
copy
and
paste
all
that
stuff
and
that
that's
getting
tedious.
So
we
need
a
good
way
to
actually
export
things
from
from
a
document
and
to
import
it
into
another
document.
So
I
have
some
slides
on
that
and
then
there
are
some
some
other
things
that
are
essentially
independent
of
cddl
itself.
D
They
can
just
be
additional
documents
so,
for
instance,
the
alternative
representations
section.
I
think
at
some
point.
We
want
to
have
a
canonical
ast,
abstract,
syntax
tree
for
cddl,
so
tools
can
interoperate
based
on
that
canonical
ast,
but
that's
something
that
that
doesn't
have
to
be
synchronized
with
the
rest
of
the
cdi
development
at
all.
So
we
can
do
that
at
any
time
we
want
and
right
now
there
is
a
workable
ast
spec
in
the
freezer
documents.
D
So
I
really
want
to
talk
about
namespaces
and
and
the
cross
universe.
References
now
and
basically,
when
we
defined
the
the
character
set
for
an
identifier,
we
already
decided
that
we
wanted
to
be
a.
D
We
want
to
have
a
few
more
characters
in
there
than
people
usually
put
into
identifiers
not
to
make
the
the
job
of
the
people
who
write
code,
generators
harder,
but
to
to
be
able
to
to
be
flexible
with
what
we
do
with
these
names
and
so
rfc8610
in
its
prelude
defines
something
that's
called
int
and
really.
You
would
like
to
be
able
to
reference
this
as
rfc8610.int.
D
So
yeah,
that's
the
the
basic
syntax
that
I
would
propose
simple
name
spacing,
and
then
we
would
need
essentially
two
operations,
operators,
export
and
import.
D
Yeah
we
we
could
simply
import
that
something
weird
happened
with
the
syntax
here,
so
we
could
just
use
an
identifier
here
and
and
assume
that
the
tool
knows
that
that
name,
that
has
a
dot
in
it
and
starts
with
rfc
and
and
four
or
five
numbers
might
be
an
external
reference.
So
this
this
would
be
just
on
the
conventional
side
or
we
could
have
special
syntax
that,
for
instance,
imports
oid
from
rfc
1990
and
also
puts
that
into
the
namespace
of
the
current
specification.
D
So
you
don't
no
longer
have
to
qualify
it
with
rfc
1990,
but
can
just
use
it.
So
that's
something
that
that's
pretty
well
known
from
programming
languages
and-
and
we
probably
just
need
to
see
how
much
complexity
do
we
actually
want
here
and
and
confine
us
to
the
complexity.
We
can
bear
and
still
get
something
readable,
because
having
nemesis
prefixes
all
over
the
place,
probably
isn't
isn't
too
nice
either.
D
So
one
related
question
is
how
how
do
we
export
things?
Well,
in
a
new
rfc,
we
could
use
the
new
syntax,
but
in
an
existing
rfc
that
already
has
cdl
in
it.
C
D
There
are
a
couple
dozen
now
it
probably
is
convenient
to
say
to
assume
something
like
there
is
an
export
all
in
there,
and
so
we
can
just
import
them
wholesale,
or
maybe
just
a
section
like
like
appendix
d
of
rc
8610,
which
is
the
prelude
and
yeah.
But
what
we
probably
need
to
do
is
find
a
space
where
people
can
find
these
pieces
of
cdd,
so
they
don't
have
to
do
what
I
had
to
do
today:
copy
paste
and
fix
cdl
from
from
respect
just
so
I
can
check
it.
D
E
D
But
yeah,
so
the
idea
would
be
that
we
have
a
space
where
people
can
can
reference.
Those
fully
extracted
pieces
in
a
way
that
tools
can
actually
make
use
of
that
it
could
be
a
github.
It
could
be
a
ana,
I
don't
know
so
so
they
wouldn't
have
to
do
all
the
work
each
time
they
need.
This.
E
If
ryana
has
an
api,
then
I
have
a
strong
preference
for
putting
it.
There.
D
So
once
we
have
something
like
that,
we
can
just
include
from
from
that
focal
space
where
these
specifications
live,
and
we
might
even
want
to
include
other
documents
like
like
the
european
digital
green
card
specification
or
other
places
that
that
define
schemas.
That
would
be
useful
to
have
available
in
cdl
form.
So
I
think
we
we
should
plan
for
that
being
a
part
of
the
solution
and
have
syntax
that
just
seamlessly
makes
use
of
that.
D
So
yeah,
so
we
we
have
essentially
two
operations,
an
export
which,
which
adds
a
prefix
and
and
makes
the
namespace
available
to
other
specs,
and
maybe
at
some
point
we
want
to
hide
things
in
in
a
document
and
say
yeah.
The
cdl
is
in
this
document,
but
it's
really
not
meant
for
you
to
use
it.
It's
just
an
example
or
it's
a
bad
example.
B
D
Interface,
that
is
a
bit
more
selective
about
that.
So
one
one
hack
that
we
can
use
in
in
xml
is
in
an
xml.
We
can
define
a
file
name
for
every
piece
of
source
code,
that
is
in
the
document,
and
we
could
just
simply
come
up
with
a
file
name
convention
that
we
use
to
indicate
which
parts
are
meant
for
extraction
and
which
parts
out
so
that
that's
the
export
side
and
on
the
import
side
again.
D
We
need
to
pull
stuff
from
a
source
and
then
either
use
it
in
a
namespace
way
or
unprefix
it
and
use
it
in
an
unprefixed
way,
and
we
already
are
doing
this
in
one
place.
The
the
preload
defined
in
appendix
d
of
rfc
8610
is
implicitly
included
in
in
every
city
specification.
D
Okay,
so
what's
the
the
temperature
reading
here
so
yeah,
we
need
to
find
a
solution
to
finding
those
things.
We
maybe
won't
even
want
to
do
something
like
like
an
something
this
that
actually
changes.
The
namespace
version
numbers-
oh
my
god
yeah.
D
So
there
are
quite
a
few
things
that
come
up
when
when
you
start
working
on
this
in
earnest-
and
I
think
we
are
going
to
need
a
design
team
working
on
this
sometime
in
autumn-
and
I
have
a
few
candidates
that
I
hope
will
be
interested
in
this-
and
maybe
we
could
set
this
up
after
the
summer
break.
D
D
So
emil
is
working
on
that
and
I
mistyped
his
name,
I'm
sorry
and
yeah.
So
I
I
would
expect
that
this
will
be
done
before
ietf
112.
D
D
So
maybe
we
want
to
to
address
the
other
sets
as
well.
We
already
have
one
tag
defined
for
sets,
but,
for
instance,
we
don't
have
a
way
to
indicate
a
list
as
supposedly
unique.
We
can
say
that
in
cdl
at
some
point,
maybe
but
yeah,
so
so
what?
What
else
do
we
need
here?
How
important
is
that
for
people?
Do
you
feel
constrained
by
not
being
able
to
identify
the
specific
kind
of
list
or
set
that
an
array.
E
So
I
care
very
much
about
one
specific
use
case,
which
is
a
list
of
pairs,
but
where
the
pairs
aren't
actually
encoded
as
pairs
they're,
just
alternating
items
in
the
list,
essentially
an
array
of
key
values.
That
would
be
a
map
if
it
didn't
have
a
list
tag.
E
Yes,
indeed,
so
I
I
don't
really
have
other
feelings
about
lists
and
different
ways
of
doing
that.
That's
the
only
one
I
really
care
about.
D
Yeah
in
the
ruby
environment,
you
actually
represent
a
set
as
a
map
that
only
ever
has
the
world
the
way
you
true,
which
is
probably
not
how
you
want
to
interchange
it,
but
these
are
often
step
child
steps.
B
A
Was
kind
of
hoping
for
a
chance
to
to
to
use
this
this
show
of
hands
tool
to
just
get
a
rough
impression
of
who
has
had
at
least
a
rust
look
at
the
documented
as
it
is
now
or
as
it
was
in
the
in
the
dash
0
version
from
the
room
to
to
get
a
bit
of
a
better
better
view
on
the
on
the
interest
on
the
working
group.
A
So
I'm
starting
I'm
starting
a
show
of
hands
now
with
read
some
version
of
maps.
A
So
please
raise
your
hand
if
you,
if
you
have
read
some
version
of
that,
and
we
I'd
like
to
use
the
do
not
raise
hand
for
I
really
don't
care
about
this
about
this,
about
applications
of.
A
A
A
Okay,
so
that's
in
a
in
a
room
of
I'll
have
to
take
the
numbers
later,
because
it's
a
bit
mixed
with
the
jabber
users,
but
in
a
room
of
of
an
estimate
of
of
30
people
actually
participating.
That's
five
people
who
have
read
this
and
two
that
don't
care
at
all.
So
there
is
some
interest,
but
I
it
would
be.
It
would
be
good
for
if
there
are
more
people
that
are
interested
to
voice
their
opinions
on
the
mailing
list,
because
otherwise
this
looks
a
bit
low
profile
right
now.
D
Yeah,
there's
a
reason
why
we
we
haven't
done
this
in
2013,
I
mean
you
can
you
can
always
get
by
with
what
we
have
it's
just
that
sometimes
would
be
nice
to
to
not
have
to
invent
new
stuff
each
time
you
would,
when
you,
your
cgi
specification
or
invent
a
new
presentation,
brandon.
E
You
can
get
by
with
what
we
have
now
and
while
arguably
that
is
correct,
it's
not
as
easy
as
it
sounds.
So
I
came
across
the
need
for
this
when
I
was
attempting
to
do
code
generation
for
a
parser
for
a
schema
based
parser,
and
the
issue
that
I
found
was
that
if
I
tried
to
do
code
generation
for
a
schema
parser,
my
code
could
not
tell
the
difference
based
solely
on
the
syntax
on
the
ast
between
a
list
and
a
list
of
key
value
pairs.
E
E
D
Okay,
I
certainly
will
agree
with
that.
I
want
to
use
the
the
last
three
minutes
for
the
last
slide,
which
is
about
records.
D
The
word
record
has
a
meaning
in
in
cdl,
so
this
is
not
exactly
the
same
meaning,
but
it's
the
the
meaning
that
the
tris
has
been
using
here.
So
it's
essentially
a
bit
like
the
way
you
would
look
at
a
csv,
a
commercial
separated
values
document
where
you
have
a
first
line.
That
tells
you
what's
in
there
and
from
then
on
you.
D
You
just
have
lines
that
have
the
actual
data
and
you
you
get
the
the
meaning
of
these
data
by
association
from
from
the
column
that
they
are
in,
and
what
chris
proposed
was
essentially
a
bit
like
sibo
packed
for
these
records.
D
So
you
would
say
something
like
I
have
a
record
with
a
name
and
and
an
address,
and
each
time
I
use
that
particular
tag.
I
mean
that
the
two
values
that
I
have
here
actually
are
name
and
address,
and
there
are
two
aspects
to
this:
one
is
the
the
semantic
identification
by
saying
the
tuple
that
you
actually
see
there
represented
as
a
sibo
array.
C
D
Great
that
that
the
meat
echo
managed
to
actually
get
this
encoded
correctly
so
much
better
than
what
I
saw
in
the
previous
meetings
anyway.
So
that
may
be
something
we
have
to
look
at,
but
I
think
that
that's
the
less
interesting
part,
the
interesting
part
is
really
should
we
look
at
this
in
in
the
super
pac
framework,
and
should
we
do
the
rest
of
that
in
in
a
kind
of
semantic
tagging
or
yeah.
D
I
think
there
are
many
ways
to
to
look
at
this,
and
I
would
like
people
to
actually
look
at
this
proposal,
which
is
currently
just
on
github
and
not
an
internet
drop
and
think
how
they
would
fit
into
the
packed
framework
and
into
also
into
other
frameworks
like
the
way
we're
doing
cinema
and
and
so
on.
So
we
can
pick
this
up
and
and
make
it
part
of
our
portfolio.
D
A
That's
actually
not
not
a
bad
idea
that
so
with
the
question
what
the
question!
Yes?
What
the
question
once
I
get,
the
right
tab
open
is
being
should
this
be.
A
Probably
pulled
in
pulled
in
was
packed.
D
That's
really
a
difficult
question
and
I
really
would
like
to
raise
my
hand
here,
so
we
need
to
think
about
that,
but
we
do
need
to
think
about
that
which
is
different
from
I
don't
care.
A
But
I
think
that
we
do
need
to
think
about.
This
is
pretty
much
the
outcome
with
three
hands
raised
and
three
hands
not
raised,
so
this
definitely
warns
a
bit
more
discussion
on
the
mating
list
because
we
are
actually
running
out
of
time
here
now,
but
I
think
we
are
also
out
of
large
topics,
so
this
would
be
a
good
point
to
conclude
this
meeting.
Unless
someone
has
a
something
urgent
to
raise,
it
want
to
say
something
about
interim
meetings.
A
Thanks
for
the
reminder,
indeed,
interim
meetings,
there
is
no
fixed
time
yet
when
they
will
continue,
but
the
current
plan
is
to
continue
them
at
the
two
week,
cadence
that
they
had
before
and
at
least
for
this
year's
day
within
the
pattern
that
has
been
established,
which
makes
them
well
compatible
with
core
meetings,
which
is
wednesday,
wednesday
afternoons
and
european
time
zones.
A
And
if
the,
if
anyone
sees
an
urgently
need
to
schedule,
please
please
send
something
to
the
mailing
list,
because
now
would
be
a
good
time
to
do
that
if
it's
needed
with
the
note
that
it
will
definitely
be
tricky
to
find
a
spot
that
works
well
for
the
people,
it
works.
Well,
for
you.
A
Good,
okay,
with
that,
thanks
karsten
for
your
52
minutes
of
10
documents,
a
bit
more.
Actually
thanks
mike
thanks
marco
for
taking
minutes
and
all
of
you
for
your
input
to
the
to
this
meeting.
I
have
a
nice
last
session
and
a
good
flight
home
yes
and
fly
well.