►
From YouTube: IETF-CBOR-20210616-1400
Description
CBOR interim meeting
2021/06/16 1400
A
Peter,
please
try
follow
the
link
in
the
chat.
Where
is
this
one.
A
A
Okay,
thanks
and
yeah.
If
anyone
wants
to
speak
just
please
unmute
yourself
and
speak
behaves
a
bit
different
from
from
webex,
but
I
think
you
should
all
be
familiar
with
this.
A
A
Funny
thing
is:
he
is
kind
of
actively
editing
the
the
kodi
md,
which,
by
the
way,
should
be
a
good
pointer
to
paste
in
here
in
the
chat
again,
it's
mainly
all
it's
already
in
the
topic,
but
just
to
be
sure.
So
please
take
take
note
of
your
presence
in
the
linked
in
the
link
cody
md,
as
we
always
do
with
the
with
the
blue
sheets,
speaking
of
which
this
is
an
itf
meeting.
A
So
please
be
aware
of
the
rules
by
which
we
do
this,
which
includes
ipr,
but
also
being
nice
to
each
other.
Given
that
you're
all
regulars,
I
won't
go
into
any
further
details
and
with
that
jump
to
the
agenda
for
today
for
this
sibo
meeting,
oh.
A
Carson
will
be
joining
us
momentarily,
given
that
he's
copy
pasting
the
thing
from
the
code
dmd
so
I'll
just
start
going
through
the
agenda.
There
are
a
few
four
five
document
topics
have
been
put
in
for
today.
The
tax
oid
just
for
brief
status,
update
cddl
control
and
and
packed
cyborg
for
the
given
the
brandon
center
review.
A
A
Working
groups
is
seeing
a
bit
of
a
block
in
what,
with
the
yangtze
war,
maybe
custom
can
say
a
few
words
there,
but
things
look
like
they
can
progress
with
the
pull
requests
that
are
open
and
finally,
there's
been
a
big
topic
of
sea
war
being
used
by
other
organizations
in
this
case
for
antivirus
the
the
physical
one
with
the
european
union.
Digital
grain
certificates
for
cover,
vaccinations
and
I'll
just
hand
out
a
few
points,
and
we
can
have
a
bit
of
a
chat
on
kind
of
what
that
means
for
general
adoption.
A
A
Okay,
so
let's
get
started
with
the
very
easy
part:
the
white,
the
text
oid,
is
in
the
in
the
rc
editor
queue.
So,
as
I
understand
it's
just
waiting
for
it's
just
waiting
for
the
rc
editors
to
kind
of
pick
it
up
and
acknowledge
that
things
are
going
on
there
and
I
don't.
I
don't
know
of
much
further
action.
That's
needed
on
our
part
here.
A
A
The
next
topic
is
a
bit
a
bit
of
a
trickier
one.
That's
the
status
of
cdl
control,
so
the
I've
started.
A
working
group
last
call
on
this
two
weeks
ago,
but
made
a
point
of
stating
clearly
there
that
we
will
need
a
bit
more
of
more
feedback.
So
custom
has
been
quite
responsive
on
on
the
general
topic
and
even
even
provided
a
few
notes
by
himself,
but
my
my
sharepoint
write-up
will
be
hard
to
process
further.
A
If
we
don't
get
any
any
any
any
reviews
on
the
document
as
it
before
it's
leaving
the
working
group.
C
A
I
know
that
hank
is
in
a
in
a
conflicting
meeting,
but
especially
carson.
If
you
have
anyone
still
who
you
can
still
ask
for
further
input
or
of
the
of
the
others
in
the
group.
If
you
see
any
way
of
reviewing
this,
please
do
so
because
otherwise
this
will
get
a
bit
stuck,
doesn't
necessarily
need
to
be
one
of
the
of
the
regulars
here
so,
for
example,
from
asdf.
A
If
people
there
can
provide
a
review,
that
would
just
as
well
be
helpful.
D
A
B
B
B
Yeah
and
and
just
to
add
to
what
christian
said,
I
expect
that
the
iesg
will
we'll
ask
questions
about
it
if,
like
this,
is
not
necessarily
blocking
at
the
working
group
level,
but
it
will
be
blocking
at
the
ist
evaluation
level.
D
A
B
If,
if
a
couple
of
people
from
aspf
would
read
it
and
provide
feedback,
that
would
be
very
valuable.
A
A
So
I
on
on
the
procedural
side,
I
just
keep.
The
working
group
last
call
open
and
extend
that
a
bit
for
now,
but
casting
if
you
could
kind
of
not
not
nudge,
a
few
people
that
might
help
get
this
or
get
this
along.
D
D
A
By
the
way,
I've
forgotten
to
to
ask
about
this,
but
I'm
can
you
given
that
today,
I'm
I'm
alone
in
the
cheering
role,
if
someone
could
help
out
with
taking
a
few
notes
of
kind
of
things
like
this
can
be
done
in
part
two
that
will
be
helpful
because
otherwise
I'll
just
switch
around
a
lot
between
talking
and
typing,
and
this
those
things.
A
A
A
I'm
I'm
not
sure
whether
this
needs
much
discussion
or
can
just
be
factored
into.
The
next
iteration
does
sound
like
there
is
a
preferred,
json
way
of
doing
multi-maps
so
that
that
could
help
us
here,
especially
given
that
the
the
last
iterations
direction
was
more
senseless,
yeah.
A
Let's
now
that,
now
that
the
data
model
is
kind
of
kind
of
figured
out,
let's
try
not
to
to
overdo
any
compression
parts
which
is
doing
anything
different
than
than
the
proposed
multi-map
solutions
with
having
one
key
and
then
a
list
of
values
would
be
so
so
maybe
that's
all
there
is
to
it
on
anything
to
add.
A
Apologies,
yes,
I've
kind
of
sorry.
I
can
completely
mix
those
things
up.
Sorry
brandon's
review
was
on
the
on
the
use
of
nested
yeah,
let's,
let's
stick
with
with
the
maps,
because
that's
what
I've
been
talking
about
just
using
these
wrong
labels,
so
I'll
just
switch
those
around
but
yeah.
A
So
the
last,
the
last
point
on
the
maps
was
there
seems
to
be
a
adjacent
way
of
doing
things
and
there's
not
too
much
pressure
for
compression.
So
probably
that's
the
that's.
That's
a
good
direction
for
the
for
the
current
iteration
of
the
document
for
the
document.
As
we
could
imagine
this
working
group
and
revisit
when,
when
there
comes
more
need
for
super
compact
expressions,.
C
This
is
email
here.
Can
I
say
something
about
that.
C
Right
so,
like
you
said,
I
think
it
would
be
worth
surveying
what
jason
is
doing
for
multi-maps
and
it
might
be
worth
while
mimicking
what
the
consensus
is.
The
goal
is
to
make
it
easier
to
transcode
between
seabor
and
jason,
so
that.
C
So
I'd
like
more
time
to
unless
someone
else
wants
to
take
that
on
to
kind
of
survey
what's
going
on
in
the
json
world
and
also
take
some
time
to
analyze
what
the,
how
difficult
it
would
be
to
decode
and
encode
the
various
compression
schemes
that
carson
proposed.
D
C
Well,
if
good,
if
we
are
to
mimic
what
jason
is
doing,
it
would
be
better
to
do
the
something
similar
to
the
endless
compression.
D
Beforehand
right,
so
you
you're
talking
about
replacing
what
what's
in
there,
which
is
essentially
an
uncompressed
form
by
one
of
the
compact
forms.
C
C
So
if
we
leave
the
document,
as
is
right
now,
it
assumes
that
multi-maps,
the
keys
are
repeated
and
if
we
later
change,
we
can't
add
the
m
list
without
breaking
backward
compil
compatibility
with
what
the
document
currently
is.
I
don't
know
if
I'm
making
sense
here.
C
Oh
so
you're
suggesting
tags
for
the
compressed
cases.
D
D
D
A
So
the
implication
there
would
be
that
applications
are
not
by
default
compatible
across
them,
but
it
should
be
relatively
straightforward
to
convert
between
one
and
the
other,
so
that
then
so
that
you
can
get
the
data
from
one
application
to
the
other.
D
Yeah,
so
maybe
we
should
just
try
to
generate
some
pseudo
code
for
how
to
convert
between
the
various
packing
forms.
C
C
We
could
list
the
enumerate
the
parse
events
that
occur
when
we
receive
these
structures
to
see
if
there's
any
memorization
or
weird
stuff.
That
has
to
happen.
D
C
That
okay,
perhaps
like,
unless
someone
else
wants
to
take
it
on
that,
could
be
something
I
look
at
after.
In
addition
to
the
survey
of
what
javascript
does.
A
D
D
D
D
A
That,
with
that
on
to
brandon
brandon's
review
on
the
on
the
topic
of
pact,
not
really
what
one
point
he
raises
is
the
topic
of
whether
what
does
it
mean
to
have
have
nested,
decompressions
and
carson.
I
see
that
you
just
posted
an
answer.
So
can
you
just
say
a
few
words
there.
D
Well,
first
of
all,
I
think
we
we
we
have
a
pretty
good
common
understanding
now
that
the
the
table
population
mechanism
needs
to
allow
some
hierarchy,
so
the
table
population
may
come
from
various
places
and
needs
to
be
merged
before
you
can
do
the
unpacking.
D
So
I
think
that
that's
consensus
and
I
think
that
consensus
is
already
reflected
in
the
current
draft,
although
one
can
always
check
whether
maybe
some
more
text
is
needed
now,
brandon's
main
comment
was
that
we
should
have
a
way
to
say
where
additional
table
content
is
coming
from,
and
he
just
said
there
should
be
an
identifier
now,
of
course,
there
are
tons
of
different
kinds
of
identifiers,
and
I
I
just
wrote
a
quick
response
with
four
of
those,
so
the
these
identifiers
have
the
the
usual
identifying
data
problem,
the
uri
context,
the
in
a
registry
thing
and
also
we
we
are
probably
better
off.
D
D
So
this
also
could
be
under
tag
51
or
it
could
be
a
different
tag.
We
can
decide
that
what
we
probably
should
decide
on
on
how
this
looks
like
so
people
can
put
this
on
their
web
servers
and
and
know
what
the
the
hash
input
should
be
for
the
hash
case
and
so
on.
So
I
think
that
that's
the
obvious
next
step
and
then
the
question
is
how
many
of
those
variants
do
we
actually
want
to
specifically
support
so
the
ionia
registry?
D
We
already
have
an
ina
registry,
which
is
the
the
tags
registry,
so
here
we
would
essentially
say
how
the
the
specification
that
is
referenced
from
the
tax
registry
would
indicate
what
the
the
content
of
that
pre-population
is.
D
So
I
think
that
that's
pretty
obvious
once
we
have
defined
that
that
canned
table
and
the
same
thing
is
true
for
the
hash
case
and
probably
also
for
the
ni
uri
case,
I'm
not
quite
as
comfortable
with
something
like
https,
because
there
there's
a
little
bit
of
an
invitation
to
to
actually
change
what
is
at
this
https
ui
and
yeah.
D
But
in
any
case,
if
we
ignore
that
aspect,
we
can
simply
say
that
under
the
https
ui,
there
could
again
be
just
a
canned
table
population
in
in
the
same
structure
that
that
we
have
everywhere
else.
So
I
think
that
that
would
be
a
nice
round
set
of
of
alternatives.
A
A
Kind
of
convert
converge
on
a
common
pattern
here,
no
matter
whether
it's
then
implemented
using
the
same
means
or
not,
because
also
the
the
uride
thing
could
have
the
could
have
the
the
implied
difficulty
of
check
of
chain
of
compatible
change
control.
So
if
there
is
a
uri
and
people
change
it,
there
are
changes
that
are
just
extensions.
That
would
be
okay
and
changes
that
are
that
are
more.
So
that's
that's
something
to
consider
to
provided.
A
That
is
that
the
way
of
importing
the
the
number
of
the
the
entry
entities
from
the
uri
is
somehow
limited
by
limited
by
something
in
the
in
the
importer.
So
you
will
say
that
from
that
uri
we
import
20
the
the
20
values
that
are
there
and
if
there's
21
there,
then
that
would
be
ignored.
A
D
A
Okay,
then
next
item
that
would
be
the
state
of
zebra
used
in
other
working
groups
with
the
young
cyborg
being
blocked
currently
custom.
You
put
this
on
the
list.
D
Yeah,
I
just
wanted
to
use
this
and
the
next
item
a
little
bit
as
a
reminder
that,
as
a
working
group,
we
not
only
need
to
focus
on
getting
the
sibo
part
right,
but
we
we
need
to
think
about
the
integration
of
sibo
in
various
contexts,
and
so,
for
instance,
one
thing
we
we
stumble
about
each
time
I
mean
it
never
has
run
smoothly,
it's
getting
the
media
types
defined
and
that
that
has
happened
here
again.
D
Maybe
the
choice
that
we
made
in
the
co-working
group
wasn't
wasn't
too
bright,
having
a
single
media
type
with
a
parameter
that
can
take
two
values
which
simply
wasn't
correctly
reflected
in
in
the
formal
parts
of
the
iana
registration,
and
we
should
start
to
get
this
right.
D
D
I
think
so
I
think
we
have
one
one
minor
detail
open
in
in
the
pull
request
that
is
referenced
in
in
the
notes,
and
I
just
need
to
find
time
to
actually
fill
that
thing
in,
but
I
think
we
have.
We
now
understand
the
main
aspect
of
it.
It's
a
bit
there's
another
problem
there,
which
is
that.
D
And
I
think
that
that's
something
we
need
to
discuss
with
the
normative
reference
aficionados,
because
that
problem,
I
think,
has
occurred
in
other
places,
and
it
requires
a
little
bit
of
of
thinking
about
the
the
purpose
of
of
having
registries
and
so
on.
To
understand
that
that
allocating
points
in
registry
is
not
necessarily
creating
a
normative
reference
for
for
the
base
document,
so
that
that
is
going
to
bite
us
next.
If,
if
we
don't
get
this
right.
A
D
A
So
green
certificate,
when,
when
last
I
got
tested,
I
got
one
of
these
nice
qr
code
and
turned
out
when
reading
it
that
this
is
this.
Is
that
lip
compressed
keyboard?
So
that's
another
use
case.
That's
a
real
world
and
widely
deployed
use
case
for
zebras.
A
What
they
are
putting
in
the
certificates
in
detail
is
they
put
in
the
there
is
a
cozy
in
there,
so
it's
in
particular
it's
a
cozy
sign
one
structure
that
contains
a
few
header
data
items
and
then
a
plain
text
that
basically
describes
who
got
tested
when
valid
for
how
long,
by
whom
and
the
person
that
is
tested
is
described
with
a
few
properties
that
can
be
then
valid
kind
of
kind
of
be
changed
with
the
with
a
physical
physical
id
and
then
there's
a
signature
of
that
with
one
of
the
keys
that
are
identified
by
key
id
and
kept
currently
by
kind
of
some
people
that
are
currently
doing
this,
their
security
and
they
do
have
plans
for
kind
of
evolving
the
key
distribution
for
all
this,
but
right
now
they
have
to
ship
it
in
14
days
from
now,
so
so
yeah.
A
A
Also,
a
few
few
odd
things
like
there
is
set
lip
compression
that
doesn't
really
help
a
lot,
but
they
they
do
not
kind
of
their.
Their
target
specification
is
moving
so
given
their
time
frame.
It's
it's.
It's
a
difficult
thing,
yep
and
that's
out
in
the
wild
and
probably
being
deployed
to
smartphones
as
we
speak,.
D
Yeah,
so
I
I
just
copied
over
the
content
of
one
of
the
example
certificates
here
and
the
the
fun
part
is
that
in
the
certificate
there
is
a
piece
of
of
jason.
D
So
we
take
a
json
document
that
everybody
can
be
comfortable
with
and
turn
it
into
the
the
seaborg
content
that
goes
into
a
sibo
web
token,
under
the
claim
-260,
that's
registered
already,
so
it's
in
the
ina
registration,
and
so
everybody
who
sees
this
cwt
knows
what
the
claim
actually
is
about
it.
It's
about
this
health
certificate
thing,
and
so
we
have
one
json
to
c
bar
conversion.
D
D
I
wouldn't
have
thought
that,
but
but
I
looked
at
the
examples
and
and
they
are
usually
like
700
bytes
or
so-
and
they
are
700
bytes
before
the
compression
at
700
bytes
after
the
compression
whatever
and
then
the
the
result
of
the
z-lip
compression
goes
into
a
base.
45
encoding
to
turn
it
into
a
qr
code
and
well
base
45
is
is
not
so
bright
because
it
one
of
the
characters
it
generates
is
a
percent
sign
and
the
other
characters
is
a
space.
D
So
you
really
have
to
be
careful
with
these
base.
45
encoded
strings
and
there
are
some
qr
code
implementations
that
decode
percent
encoding
for
you,
so
that
percent
sign
is
going
to
mess
up
so
yeah
yeah.
That's
one
place
where,
where
just
the
the
packaging
is
not
so
bright
but
anyway,
so
this
turns
into
a
qr
code
into
text
for
a
qr
code,
but
to
make
sure
that
this
text
is
not
misinterpreted.
D
They
also
add
the
prefix
hc1
colon
in
front
of
that.
So
it
looks
like
a
uri
to
those
people
who
interpret
qr
codes
as
uris,
and
so
it
doesn't
land
in
in
any
unrelated
application.
But
it
lands
in
in
the
application
that
knows
what
what
hc1
is,
so
that
that's
a
kind
of
armor
against
misinterpretation
and
that's,
ultimately,
what
gets
encoded
into
the
qr
code
that
you
get
on
your
piece
of
paper
with
a
digital
green
certificate
on
it.
D
So
I
think
we
can
learn
quite
a
bit
from
here.
First
of
all
that
it's
nice
with
that
we
have
a
defined
json
to
see
what
conversion
in,
in
eight
nine
four
nine
that
was
work
that
was
well
in
invested.
D
Then
we
have
good
ways
of
of
actually
defining
sign
statements
in
cwt,
because
we
can
just
allocate
a
claim
number
-260
in
this
case
and
yeah.
Then
then
we
are
done
with
the
products
of
of
the
itf
and
then
again
we
go
into
zlip
compression
and
base
45
and
and
so
having
a
a
standard.
Interface
to
qr
code
would
be
a
nice
thing
and
I
think
michael
has
been
working
on
on
something
like
that
before
as
well.
A
But
I
fully
agree
that,
having
something
having
a
good
thing,
some
kind
of
more
or
less
default
way
of
encoding
cozy
into
a
qr
code
would
be
useful,
and
especially
given
that
then
we
could
use
self-describing
keyboard
to
kind
of
dispatch
that
even
further,
although
I
don't
know
how
well
this
it,
it
might
make
sense
to
pick
a
com
pick
a
conversion
that
allows
this
mapping
of
a
that
allows
self-describing
seabor
thing
that
is
attacked
entity
to
easily
go
on
through
the
dispatch
mechanisms
that
are
usually
in
place
with
for
4c
for
qr.
A
A
One
thing
I
did
notice
is
that
they
that
there's
a
lot
of
not
a
lot
of
date
times
in
in
in
iso
format
in
there,
which
could
just
as
well
be
expressed
with
the
tags
that
probably
doesn't
fly
because
of
their
internal
use
of
json.
D
You
accept
that,
sadly,
it
lives
from
repetition
and
there
there
is
very
little
repetition
here
so
that
really
or
the
deflate
algorithm.
Actually,
that
is
underlying.
That
really
cannot
do
very
much,
and
even
the
the
last
name
mustafa
here,
for
instance,
that
is
once
in
uppercase
and
once
in
lowercase
and
and
zedlib
cannot
make
any
use
of
that
redundancy
or
the
the
last
name
we're
guessing
that
is
in
in
an
ascii
transliteration
once
and
in
in
backslash
you
unicode
characters.
Otherwise,
so
there's.
D
A
D
Okay,
I
have
to
check
that,
but
maybe
it's
actually
no
you're
right.
A
But
still
you
can't
compress
across
these,
so
my
certificate
at
least
had
a
kind
of
valid
from
and
valid
two
component
in
there,
and
that
was
encoded
in
date
times
and
and
those
would
be
partially
redundant.
But
it's
like
eight
bytes
so
not
sure
how
much
of
that
would
really
really
be
compressed
away.
D
Here
you
can
see
both
the
iso
8601
date
and
posix
posts
are.
D
Present
so
the
one
162
and
so
on,
that's
posing
stage,
and
the
other
ones
of
course
are
8601
dates
anyway.
So
yeah,
I
think
what
what
I
learned
from
this
episode
is
that
we
we
haven't,
really
covered
our
base
on
on
the
way.
How
how
does
the
siba
data
structure
get
useful
in
the
qr
code
world,
and
we
probably
should
have
addressed
that
and
by
the
way
there
is
a
draft
out
there
with
that
base.
D
54
45
encoding
that
I
actually
originally
commented
on
that
that
the
character
set
is,
is
not
so
brightly
chosen.
But
of
course
it's
the
the
character
set
that
qr
code
supports
so
for
for
some
reason
that
that
is
opaque
to
me.
They
decided
that
they
have
to
use
all
these
characters
which
they
don't
because
base
41
is
enough,
and
so
they
could
have
left
four
of
these
characters
unused
anyway.
So
this
is
the
kind
of
integration
problem
that
that
you
get
when
you
put
sibo
into
qr
code.
A
So
for
for
for
this
particular
deployment,
my
understanding
is
that
they
won't
change
anything
about
their
basic
coding
because
they
have
a
deadline
like
in
two
weeks,
but
given
that
kind
of,
if
that
document
progresses
and
or
we
want
to
do
something-
to
give
a
default
encoding
for
for
sibo
for
qr
codes,
then
that
could
still
be
using
using
something
base,
41ish
or
even
base32.
A
If
the
point
can
be
made
that
the
other
thing
is
just
too
complicated
and
that's
good
enough
as
well-
and
I
think
that
would
be
a
good
thing
to
have.
The
question
is:
do
we
have
energy
in
the
working
group
to
to
take
down
to
to
give
to
to
create
what
would
that
be
kind
of
best
practices
in
using
best
practices
using.
A
D
And
I
know
that
michael
has
done
a
lot
of
work
there.
So
I
I
was
delighted
to
see
his
name
in
the
attendance
list,
but
he's
only
there
using
jabber.
So.
A
A
What
I
found
out
on
about
this,
I
think
I've
covered
as
well,
so
was
some
time
left,
any
any
more
comments,
voices,
opinions
and
related
news.
C
This
is
the
mill
here.
I
have
a
question
for
karsten
concerning
the
maps.
If,
if
you
have
time,
if
not,
I
can
ask
you
by
email.
C
You
had
suggested
that
the
various
compression
schemes
would
have
different
tags,
so
would
that
tag
be
stacked
on
top
of
the
tag
that
indicates
that
this
is
a
multi-map
or
would
there
be
several
multi-map
multi-map
tags
for
the
various
compression
schemes.
D
So,
given
that
we're
talking
about
oneplus
one
tags
right
now,
having
stacked
tags
would
take
four
bytes
and
allocating
a
1
plus
2
tag
for
the
combination
would
be
3
bytes.
D
So
I
think
we
are
better
off
not
going
for
the
stacked
approach,
but
of
course,
maybe
there
is
a
reason
to
to
have
a
oneplus
one
tag
just
for
the
packing
scheme,
which
is
different
from
from
what
we
are
discussing
in
the
map
like
data
draft.
So
I
I
don't
have
a
complete
answer
for
that,
but
I
think
that
generally,
we
would
prefer
just
allocating
more
tags,
then,
from
from
a
larger
space
over
stacking
them,
unless
we
really
have
a
situation
where
you
mix
and
match
very
freely.
D
So
it's
it's
not
it's
better
to
to
have
the
full
cross
products
of
of
both.
I
understand.
C
D
If
you
add
bits
that
actually
are
in
the
second
byte,
so
you
just
use
the
existing
tag,
numbers
and
add
bits
for
for
the
actual
packing
scheme
in
the
second
byte.
Then
you
might
be
able
to
come
up
with
a
scheme
that
works
nicely.
D
I
don't
follow
so
the
the
tags.
We
have
now
essentially
fill
bits
in
in
a
single
byte,
so
they
come
off
the
oneplus
one
tag
space,
and
if
we
go
into
the
one
plus
two
take
space,
then
we
have
another
byte
and
that
byte
we
can
fill
with
additional
bits
which
need
to
that.
The
byte
needs
to
be
different
from
zero,
so
we
actually
are
in
the
one
plus
two
tank
space,
but
otherwise
we
can
use
that
whole
byte
for
allocating
for
the
bits.
A
If
we
go
down
that
direction,
I
suggest
we
try
to
keep
the
allocated
tags
compact
in
the
sense
that
they
can
all
significant
bits
go
to
the
end,
because
otherwise
we'd
create
a
situation
where
the
tag
number
space
is
fragmented
by
different
things.
Allocating
different
hyper
rectangles
in
in
different
bit
alignments,
and
these
might
at
some
point
get
messy
like
so
just
be
sure
that
we
have
a
an
easy
to
be
compatible
with
allocation
scheme.
C
I
know
personally,
I
don't
really
care
if
the,
if
the
bits
align
nicely
with
the
various
traits,
because
let's
say
there
are-
I
don't
know
20
tags
total
for
the
maps.
C
In
my
implementation,
I
can
just
build
a
lookup
table
just
subtract
the
tag
number
from
the
first
tag
and
that
becomes
the
entry
in
my
lookup
table
where
I
have
all
my
traits
where
you
know
tag
one
two,
three.
Well,
it's
a
multi-map
with
and
so
on.
C
B
A
I
think
that's
all
for
today
and
see
you
on
the
mailing
list
and
in
two
weeks
here
again
on
me,
decker,
because
I
think
this
worked
out
pretty
fine
and
I'll
stick
around
for
a
bit
of
testing
of
screen,
sharing
and
video.
If
anyone
wants
to
do
more
dry
out
that
that
that
could
be
done
in
the
next
two
minutes
to
the
others.
Thank
you
and
see
you
next
time.
Bye.
D
D
C
I
wouldn't
mind
trying
to
share
a
screen.
Yep
go
ahead.
C
Okay,
it's
I
have
to.