►
From YouTube: IETF108-CBOR-20200727-1300
Description
CBOR meeting session at IETF108
2020/07/27 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
The
hour,
I
think
we
can
start
so
welcome
everybody
to
the
seaboard
working
group
meeting
itf
108..
My
name
is
francesca
palumbini
and
together
with
jim
chad.
We
are
your
chairs
for
this
session
here.
In
the
second
slide,
there
are
some
useful
links
and
you
can
find
the
session
slides
in
the
chat,
both
in
the
mythical
or
in
the
jumper,
wherever
you
are,
and
we
have
a
minutes,
a
link
for
the
minutes
at
the
core
dmd-
and
thank
you
michael,
I
hope
michael
is
here
because
he
volunteered
to
take
minutes.
A
Okay
and
jim
is
also
taking
minutes.
Thank
you
great
next
slide.
Yes,
this
is
an
itf
meeting,
so
the
note
well
applies,
please
take
a
moment
to
read
and
understand
it,
and
if
you
have
any
question,
please
talk
to
your
working
group,
chairs
or
air
directors.
A
A
So
this
is
our
agenda.
For
today
I'm
gonna
give
you
a
short
status,
update
on
working
group
documents,
seaboard,
biz
and
the
seaboard
date
tag
document.
Then
karsten
will
take
the
floor
and
he
will
talk
about
cddl
seaboard
tags
for
oid,
packed,
cyborg
and
notable
tags
document.
A
A
A
You
can
find
all
the
recordings
and
minutes
in
the
link
and
a
cbor
based
document
has
been
submitted
for
publication.
Finally,
so
that
was
the
17th
of
june-
and
I
also
didn't
write
it
here,
but
it
is
right
now
in
las
cole,
which
ends
the
14th
of
august.
A
A
Thanks,
okay,
so
for
the
date
tag
document
version
5
has
also
been
submitted
for
publication
last
week
and
it's
also
in
las
call
and
at
the
same
time
than
the
seaboard-based
document,
and
then
we
are
starting
to
discuss
or
we
have
started
discussing
the
new
work
that
has
been
brought
to
the
working
group
and
it
will
be
discussed
today.
A
So
before
I
leave
the
floor
to
carsten.
I
just
wanted
to
mention
that
we're
still
gonna
have
interims
so
we're
gonna,
restart
the
interims,
the
2nd
of
september
every
2
weeks
and
the
time
slot
will
be
the
same
5
to
6
cst
or
I
guess
that's
gonna.
No,
that's
not
going
to
change
up
to
the
4th
of
november.
I
don't
know
if
we
should
do
longer
than
that.
A
B
A
A
C
Okay,
so
I'm
going
to
talk
about
the
number
of
drafts,
hopefully
quickly
remind
me
to
speed
up
please
so.
Cpdl
currently
has
a
discussion
going
on
what
should
be
done
for
the
the
next
phase
of
cdl,
where
we
have
a
module
structure
and
can
build
larger
cda
specifications
out
of
existing
specifications
and
new
specifications,
and
so
on.
That
is
a
discussion
that
is
currently
going
on,
but
hasn't
led
to
drafts.
C
Yet,
except
for
this
one
draft,
which
defines
a
few
additional
control
operators
for
cddi,
because
that's
a
very
low
threshold,
low
overhead
way
of
adding
functionality
to
a
cdd.
So
right
now
there
are
three
features
in
this
draft.
The
the
cad
and
plus
are
used
for
building
strings
out
of
components.
C
We
have
dot
a
b
and
f
and
dot
a
b
and
f
b,
which
allow
you
to
put
a
b
and
f
into
a
cdl,
and
we
have
dot
feature
which
allows
you
to
indicate
that
some
aspect
of
the
specification
actually
uses
a
specific
uses,
a
feature
of
the
the
specification
of
the
protocol.
C
The
other
four
have
not
been
implemented,
but
probably
will
be
soon,
and
since
this
is
the
the
the
meeting
before
the
one
where
it
probably
will
be
implemented,
maybe
it's
good
to
to
verify
that
that
this
is
actually
the
path
we
want
to
take
here.
We
I
want
to
implement
it,
see
that
it
works
register.
C
The
operators
do
a
working
plus
call
and
or
maybe
adopt
the
document
first
and
then
get
a
few
reviews
and
then
do
a
regular
blast
call
and
and
so
on.
So
I
would
be
interested
to
hear
who
thinks
this
is
not
not
a
good
way
to
handle
this.
B
A
A
So
just
for
to
clarify
for
the
charter.
The
point
was
that
what
I
read
today
was
that
the
working
group
will
collect
these
features.
Talking
about
cdl
features,
evaluate
their
utility
and
address
to
a
second
edition
of
the
specification.
A
A
Okay-
but
I
don't
hear
anybody
being
against
this-
I
think
it
would
be
good
if
more
people
would
read
it
at
least
and
possibly
review
it,
but
this
seems
pretty
straightforward.
C
There
was
an
implementer
who
who
said
that
the
diagnostic
notation
should
be
subjective,
or
in
other
words,
every
potential.
Sibo
data
item
should
have
at
least
one
piece
of
diagnostic
notation,
that
maps
to
it
and
and
right
now
we
are
not
fulfilling
this
for
empty
indefinite
length
strings
and
for
another
numbers.
C
So,
just
as
a
reminder,
diagnostic
notation
is
defined
in
section
6
of
7049
and
in
appendix
g
of
the
the
cddl
specification
there,
it's
called
extended
diagnostic
notation
because
it
extends
on
70,
49
and
yeah.
Almost
all
see
what
data
items
can
be
expressed
in
extended
diagnostic
notation,
except
that
open
paranthesis
under
closing
parenthesis
is
ambiguous.
C
Whether
this
is
a
white
string
or
a
text
string
and
the
payloads
of
floating
point,
not
a
number
values
are
lost
and
there
are
well
yeah,
probably
still
to
be
discussed,
proposals
how
to
do
this.
They
kind
of
do
the
job,
but
we
probably
want
to
see
whether
we
actually
want
to
adopt
this,
so
this
can
be
fixed.
C
C
So
I'm
not
sure
that
that's
a
sane
thing
to
propose,
but
implementers
are
using
it
so
so
maybe
giving
them
an
abnf
is.
Is
a
nice
thing
to
do
and
it's
it
hasn't
happened
that
people
were
starting
to
use
diagnosis,
mutation
for
interchange.
So
I
think
we
are
kind
of
safe.
D
So
you
would
remove
it
all
from
70
49
bits.
No,
no
you'd
leave
what
we
have
and
then
you'd
write
a
new
document.
C
A
A
B
B
C
Well,
if
you
are
building
a
set
of
test
cases,
you
probably
want
to
do
this
in
source
form
and
not
being
able
to
to
build
test
cases
for
these
funny.
Two
little
exceptions
from
the
the
subjectiveness
property
is
weird.
A
Salesforce,
okay,
so
I
also
have
a
comment
francesca
palumbini
from
from
the
floor.
If
we
do
this,
could
we
add
diagnostic
notation
for
c
more
sequences
that
is
not
defined?
I
think.
A
And
I
know
that
it
would
have
been
helpful.
I
think
if
hank
is
here,
I
know
at
least
one
draft
where
this
has
come
up.
E
Yeah,
I'm
hi,
I'm
in
the
very
curious
situation
that
I
always
have
to
reauthorize
my
audio.
So
can
you
hear
me.
E
Okay,
thanks
so
yeah.
I
am
surprised
that
you
know
that
I
I
thought
I
haven't
floated
that.
But
yes,
I
encountered
a
draft
and
they
they
said
it's
a
conception
actually
in
inside
a
draft.
That's
not
really
really
written
out
that
sequences
and
arrays
are
in
notation
indistinguishable
or
that
there's
nothing
there.
So
so
I
really
really.
It
would
be
like
a
few
days
to
understand
what
the
actual
problem
is
and
now
that
I
think
I
understood
it.
E
It
is
the
diagnostic
notation
and-
and-
and
maybe
this
translates
to
cddl
also,
although
I
have
no
idea
why
that
would
be
the
case,
but
maybe
we
have
to
have
something
that
is
more
intuitively
highlighted
there,
but
that's
a
second
order
problem.
First
order
is
here
that
yeah
it's
a
diagnostic
notation.
E
E
C
Thanks
so
I
think
that
that's
very
good
input-
and
it's
really
another
motivation
to
to
tackle
the
diagnostic
notation
thing
a
little
bit
more
from
the
front
than
just
fixing
this
this
one
little
gap
so
yeah.
That
certainly
encourages
me
to
to
look
at
this
look
into
this.
C
So
the
the
main
point
is,
we
are
not
putting
this
into
a
7049
bis
on
the
chat.
There
was
the
question:
why?
Why
would
we
not
do
that,
and
the
answer
is
it's
already
out
of
the
working
room?
This
would
delay
things
it's
in
last
call,
and
we
also
probably
don't
want
to
get
in
a
rush
about
fixing
this.
So
anybody
who
has
experience
experience
with
not
a
number
values
in
floating
point
will
probably
agree
with
that.
C
Yes,
so
the
oid
draft
that
has
been
around
for
a
long
time,
six
years,
sean
leonard,
wrote
the
the
original
version
of
that
and
I'm
not
sure
if
I'm
seeing
him.
Yes,
he
is
here
mars
and
yeah
on
the
way
it
kind
of
was
getting
more
functionality
stuck
to
it
than
we
really
needed.
C
We
now
have
use
cases
in
reds
and
and
related
documents,
and
that
is
creating
some
urgency
of
getting
done
with
us.
So
I
I
just
went
ahead
and
reduced
the
draft
to
what
I
think
is
really
needed
in
this
area.
We
had
an
adoption
call.
I
haven't
heard
a
chess
evaluation
of
that
adoption
call
yet
and
we
probably
have
to
examine
the
the
tag
factoring
functionality
a
little
bit
more
because
that
is
currently
not
fully
defined.
A
C
Right,
so
there
is
a
deck
in
my
slide
in
my
deck
that
I
don't
need
anymore
because
under
yesterday,
hadn't
reached
shown,
but
that
that
has
been
fixed.
So
next
item
packed
sibo.
C
C
If
the
data
model
is
designed,
knowing
what
you
can
do
in
switzerland,
like
putting
integer
labels
into
maps
so
simply
encoding,
existing
json
existing
json
data
in
cbor
gives
you
less
benefit,
and
the
reason
is
that
there
is
usually
a
lot
of
redundancy
in
there
and,
of
course,
you
can
remove
this
redundancy
by
sending
the
encoded
data
item
through
deflate
and
for
a
lot
of
applications.
That
is
exactly
what
you
want
to
do,
but
the
disadvantage
is
that
you
have
to
do
a
full
decompression
before
you
actually
can
use
the
data.
C
C
C
The
item
and
the
reason
why
this
works
so
well,
is
that
that
much
of
the
redundancy
can
be
addressed
by
structure
sharing,
so
you're
having
the
same
strings
over
and
over
again,
you
have
some
subtrees
that
could
be
shared,
so
the
idea
is
to
provide
one
copy
of
the
repeated
items
and
replace
all
other
copies
by
pointers
to
that.
But
of
course
we
don't
have
pointers
in
in
c
wall,
so
we
have
to
invent
something
to
to
be
able
to
do
this.
C
The
other
place
where
we
actually
can
can
save
a
little
bit
more
is
prefix
sharing,
so
data
items
that
share
prefix
http
your
eyes
often
do
that
the
first
20
bytes
are
the
same,
and
then
they
start
to
differ
there.
We
provide
one
copy
of
the
shared
prefix
of
the
repeated
prefix
and
share
that,
so
we
build
something
that
looks
a
little
bit
like
an
indefinite
length
string,
except
that
it's
built
out
of
two
parts
and
one
part
comes
out
of
the
prefix
array
and
the
other
part
is
right
in
the
data
item.
C
Then
we
have
a
prefix
list
and
a
shared
list,
and
because
we
cannot
have
two
arrays
there,
because
you
wouldn't
know
where,
where
one
ends
and
the
next
starts,
the
prefix
list
actually
is
nested
in
into
the
big
array.
C
So
a
ramp,
a
prefix
list
and
a
shared
list,
and
and
that's
where
we
work
from
and
we
actually
did
an
experiment
in
2016
17
when
it
was
discussed
how
w3c
thing
descriptions
could
be
encoded
at
the
time
no
no
decision
was
taken,
but
we
took
a
few
w3c
thing
descriptions
and
put
them
to
a
very
similar
form
of
of
that
sibo
packing,
and
the
first
thing,
of
course,
we
notice
is
that
most
of
the
redundancy
in
json
files
is
white
space.
C
There
are
other
compression
schemes
that
maybe
are
a
bit
more
appropriate
for
constrained
nodes
like
lz4
yeah.
These
are
not
so
good,
but
they're,
still
nice
from
for
going
from
1500
to
400.
C
when
you
encode
the
the
json
in
c
bar,
it
gets
a
little
smaller,
but
not
that
much
and
again,
if
you
deflate
it,
you
essentially
get
the
same
numbers
now,
if
you
do
the
sibo
packing
algorithm
and
and
the
the
emit
your
implementation,
I
wrote
for
that
and
only
exploit
the
sharing
possibility.
You
go
from
1200
to
800,
so
you
save
about
a
third
and
when
you
then
add
prefix
compression,
which
is
very
useful
for
json
av
documents
because
they
have
these
tons
of
ui's
in
them.
C
C
It
can
save
a
certain
amount,
but
not
perfectly,
but
of
course,
if
you
design
your
data
to
be
packable,
maybe
you
can
go
beyond
that
and
the
one
big
thing
we
didn't
try
was
adding
a
static
dictionary.
Actually,
I
I
tried
this,
but
it's
not
part
of
the
current
proposal,
so
aesthetic
actually
saves
119
bytes.
So
we
are
getting
close
to
deflate.
C
You
can
see
the
static
dictionary
for
for
this
specific
application
down
on
on
the
slide.
So
that's
the
the
experiment.
The
one
thing
we
noticed
while
building
this
is
that
the
references
need
to
be
efficient.
C
So
we
looked
at
efficient
ways
of
representing
references
in
sibo
and
you
have
to
make
sure
that
they
are
very,
very
clearly
distinct
from
from
actual
data.
You
would
find
so
we
we
said,
let's
allocate
16
of
the
simple
values
to
that.
That
actually
has
been
part
of
of
the
initial
zebra
proposal,
but
we
took
it
out
because
we
didn't
want
to
complicate
superb
by
that
and
allocate
one
single
byte
tag.
So
these
are
pretty
precious
resources.
C
Excuse
me
and
then
we
have
a
few
longer
tanks,
so
we
don't
get
in
a
situation
where
we
have
an
artificial
limitation
to
the
number
of
of
shared
or
prefixed
shared
data.
C
So
this
is
taking
a
chunk
out
of
the
space
we
have.
So
this
is
470
for
seventh
of
the
remaining
simple
values:
one
twenty
fourth
of
the
remaining
one
plus
zero
tags,
one
h
of
the
one
plus
one
tags,
and
so
on,
so
that
that's
maybe
something
that
that
can
be
discussed.
C
But
apart
from
that,
I
think
this
is
very
much.
The
proposal
we
want
to
have
one
discussion
we
have
had
is
whether
it's
okay
to
have
the
usual
way
compression
is
defined.
You
define
the
decompression,
the
the
unpacking
mechanism,
but
you
are
not
defining
how
to
do
compression.
C
So
this
is
something
where
different
implementations
can
differ
in
in
the
thoroughness
with
which
they
actually
find
the
minimum
size,
so
that
that's
something,
for
instance,
we
couldn't
do
a
deterministic
version
of
this,
because
compression
is
not
something
where
you
tend
to
define
exactly
how
how
you
do
it,
except
in
the
very
simple
compression
schemes.
C
So
some
implementations
may
just
want
to
find
the
shared
strings
and
and
be
done
with
it.
That's
already
a
a
pretty
good
gain
or
find
general
shared
items
in
general
or
go
the
whole
way
and
and
do
common
prefix
detection,
so
the
the
algorithm
for
that
is
left
as
an
exercise
to
the
reader.
But
one
comment
was
we.
We
may
need
a
reference
algorithm
here.
C
So
the
the
question
is:
is
this
something
we
want
to
go
forward
with?
C
One
interesting
thing
that
that's
happening
in
w3c
right
now
is
that
they
have
noticed
that
json
ld
is
not
very
efficient,
so
there's
actually
a
proposal
for
a
sibo
led
which
you
may
want
to
google,
and
that
takes
most
of
its
gains
from
using
external
dictionaries
plus
using
integer
labels
for
compression.
So
it
would
not
be
useful
for
compressing
general
c
bar,
but
for
compressing
json
led
it's
actually
quite
good.
It
would
give
you
approximately
the
same
improvement
that
packed
zebra
would
give
you
with
external
dictionaries.
C
We
could
decide
to
add
external
dictionaries
to
packed
zebra
and
we
could
fix
one
little
gap.
Prefixes
are
currently
only
defined
for
strings,
but
it
actually
turns
out
that
a
lot
of
maps
have
common
subsets,
which
we
could
handle
using
the
same
prefix
mechanisms,
because
maps
are
not
ordered
so
that
that
complicates
compression,
but
the
the
result
would
be
very,
very
good
for
things
like
json
led,
so
we
could
do
this.
While
this
is
a
working
group
document
and
as
usual,
my
question
is:
can
we
go
ahead
with
this?
D
So
I
didn't
understand
the
rump
part,
so
I
scan
the
document
quickly.
I
guess
the
rump
part
is
the
the
sevore
which
contains
the
references
to
the
other
parts.
C
C
A
E
Yeah
change
to
browsers:
oh
there's
that
yeah
there's
some
so
many
things
about
this.
First
of
all,
this
work
is
necessary,
but
what
I
personally
often
encountering
is
this
huge
amounts
of
redundant
data
in
the
iri
uri
url
space.
That
is
a
detriment
to
the
benefits
that
we
typically
want
to
achieve
here.
E
E
The
actual
matter
at
hand
is
that
you
string
copy
typically,
so
many
uris
into
a
a
sea
bar
item
that
that
then
you
can
come
up
with.
Why
do
we
don't
pack
this
with
ez54
and
destroy
the
the
immediate
use
that
is
so
useful
in
the
end
and
and
what
I
would
like
to
do,
or
what
I
like
to
see
is
to
have
something
as
as
established
as
like
a
cdl
prelude.
That
is
the
dictionary
and
then
I
have
a
lot
of
witty
and
nice
ways
to
refer
to
that
in
even
composing.
E
The
data
definition,
which
then
will
use
again
later
on
and
micrometer,
would
point
about
this
with
the
rump
this
dictionary
by
parsing
and
and
or
processing
the
data
item.
That
would
be
an
a
tremendous
benefit
to
yeah
the
the
most
serious
pushback
we
get
today
when
we
employ
sibo
data
items,
I
think
that's
yeah.
We
really
have
to
do
this.
A
Okay
brandon
giving
you
the
floor.
F
So
I
think
this
is
really
necessary,
in
fact
it's
so
necessary
that
in
suit
I
pretty
much
had
to
invent
it
myself,
and
you
can
see
that
reflected
in
component
id
definitions
in
suit.
If
you
take
a
look,
I
would
just
caution
two
things.
The
first
is
that
using
the
two
nested
lists
is
going
to
make
it
very
difficult
for
pull
parsers
specifically
to
handle
this
kind
of
data,
and
I
I
guess
the
way
that
I've
dealt
with
that
in
suit
is
to
well.
F
In
this
case
it
would
be
to
wrap
those
two
elements
in
a
a
byte
string
each,
and
that
way
you
don't
end
up
with
the
the
double
list
problem
that
you
were
describing.
F
F
A
Okay,
thank
you
and
giving
the
floor
to
robert
robert
wilton.
G
Hi,
I
just
one
quick
comment
or
question
is
my
my
concern
here
is:
maybe
that
would
we
end
up
creating
two
different
variants
of
c
board?
We've
got
implementations
that
have
implemented
the
current
zero
spec
and
by
adding
this
new
functionality,
how
can
we
be
sure
that
all
cbo
implementations
will
then
be
able
to
accept
this,
this
new
functionality
or
we're
going
to
have
a
sort
of
split
in
the
ecosystem?
G
C
Yes,
so
this
is
a
lot
like
any
other
tag.
Whenever
you
add
a
tag
to
sibo,
you
have
implementations
that
do
that
tag
and
others
that
don't,
and
I
mean,
if
you
have
a
generic
decoder
that
that
doesn't
know
about
this.
It
will
just
present
the
the
pixel
to
the
application
and
then
the
application
has
to
deal
with
that.
So
we
we
don't
have
any
any
deployment
thresholds
that
that
need
to
be
taken.
C
So
we
we
probably
want
to
to
have
what
I
would
call
a
dom
parser
that
that
actually
makes
it
simpler
for
you
to
access
this.
But
actually,
I
think,
looking
at
how
implementations
look
like
today,
that's
relatively
easy
to
add:
okay,.
H
All
right
audio,
coming
through
yes,
delightful,
so
yeah,
I'd
like
to
speak
up
in
support
for
this
as
well.
The
the
lack
of
a
packed
seabor
option
has
effectively
prevented
the
use
of
sebor
in
two
other
standards
that
I've
been
working
with,
and
so
yes,
this
is,
this
is
critical.
H
The
the
one
thing
I'd
like
to
also
comment
on
is
the
need
for
a
packed
compressed
dictionary
efficient
uri.
We
have
uris
all
over
the
place.
They
are
by
far
the
biggest
consumer
of
seaboard
real
estate
and
so
without
supporting
one
specific
proposal
over
another,
the
huffman
encoded
or
the
other
one
who
mentioned
a
uri
tag
here
would
be
of
significant
value,
so
external
dictionaries
as
well.
I
think
this
is
fantastic
work
and,
and
we
should
adopt
it.
A
A
Before
we
talk
about
that
option,
I
would
like
to
see
a
bit
more
work
on
it
also.
I
would
like
to
point
out
that
this
is
not
only
registering
a
new
tag,
new
tags,
which
is
in
scope
of
our
charter,
but
it's
also
registering
the
simple
values
and,
as
you
pointed
out,
custom
that
might
have
some
more
discussion
about.
A
Are
we
going
to
register
those
precious
values?
So
I
I
think
I
would
like
to
see
more
progress
on
the
content
of
the
document
also
see,
I
think,
having
some
examples
or
something
to
make
it
easier
to
understand
would
be
good.
A
Sounds
like
no
casting
anything
you
want
to
add,
or
is
this
a
good.
C
Yeah,
I
think
the
the
the
obvious
thing
I
need
to
do
is
publish
my
implementation,
so
people
actually
can
can
play
with
this
more
and
we
can
generate
more
examples.
Well,
this
was
a
proof
of
concept
implementation,
so
it
does
require
a
little
bit
of
polishing
before
I
can
do
that,
so
that
that
would
be
something
that
maybe
could
be
done
together
with
a
new
version
of
of
the
spec.
So
please
do
put
in
comments
like
put
romp
at
the
end
and
package
things
into
bite,
strings
and
so
on.
A
Sounds
good,
I
think
you
can
go
ahead
with
the
last
item
on
the
agenda.
C
Yeah
now
this
is
really
just
a
very
quick
reminder
that
we
have
this
notable
tags
document
and
this
is
still
going
forward.
This
needs
work,
but
on
the
other
hand,
it
already
contains
some
information.
So
if
you
just
can
occasionally
look
in
there
and
see,
does
that
provide
you
with
any
useful
information?
C
So
what
one
point
is
just
copying
tag
definition,
specifications
that
are
hard
to
reach
or
that
are
not
written
in
a
language
that
is
immediately
accessible
to
people
and
the
other
one
is
to
provide
some
structure
to
this
field
and
say
here
are
six
different
tags
by
three
different
groups
of
authors
and
they
they
would
actually
work
together
to
solve
a
particular
set
of
problems.
C
So
yeah,
please,
please
send
feedback
and-
and
look
at
this
occasionally
when
I
post
a
new
version.
A
Great
just
one
question
that
I
forgot
to
ask
about
the
seaboard
pact:
it's
if
any
participants
or
people
who
has
spoken
up
about
needing
this.
Do
you
have
a
timeline
in
mind
or
that
you
know
you
would
need
this
so
brendan,
giving
you
the
floor.
F
The
suit
manifest
is
almost
done,
and
that's
what
I
need
it
for
so
it's
probably
too
late
already
it's
and
it's
a
shame,
because
I
would
really
love
to
have
included
this,
but
I
I
kind
of
don't
want
to
delay
the
suit
manifest
if
this
is
only
just
being
adopted
so
yeah.
I
yesterday
would
be
great.
A
Yesterday,
okay
got
it
hank.
E
Excellent
but
I'm
better
video
or
whatever
I'd
like
to
say
yesterday,
but
it
was
four
hours
ago,
so
we
just
moved
to
isg
with
co-switch
and
they
have
a
lot
of
links
in
them.
C
It
is
immediate,
you
can
use
pact
with
any
existing
new
specification,
so
you
just
put
slap
the
tag
on
it
and,
and
then
you're
done.
So
this
is
a
one-page
document
which
you
you
always
can
do.
Of
course,
if
you
like,
like
brandon,
actually
have
put
in
mechanism
to
do
part
of
this,
for
you
then
then
yeah,
that's
that's
too
bad.
F
Yeah
yeah:
this
is
what
I
was
going
to
say.
Also
if
it
were
already
a
specification,
I
could
mandate
that
it
was
always
present
and
and
that's
what
I
want
to
do,
but
I
can't
do
that
if
it
doesn't
exist
yet
and
adding
a
tag
later
is
helpful,
but
it's
actually
going
to
introduce
a
lot
of
incompatibility
problems.
For
me.
A
E
Feature
control
but
but
that
would
be
nice.
I
think
yep.
A
Okay
got
it
and
I'm
reading
from
jabber
chat.
Chris
saying
I
have
no
specific
timeline.
The
time
has
passed
on
the
specs,
I'm
working
on
that
could
use
this
okay,
so
kind
of
the
same
answer
from
everybody
yesterday,
but
yeah,
okay,
but
carson.
Please
go
ahead
and
just
work
on
the
comments
that
you
have
gotten
today
and
also
we
will
try
to
get
more
people
to
read
and
review
and
then
okay
jeffrey
is
also
saying.
Web
packaging
will
probably
have
time
to
evolve,
to
use
paxibor.
C
C
C
A
A
I
think
I
will
go
ahead
and
close
the
meeting.
Thank
you
so
much
for
joining
today
and
I'll
talk
to
you
in
the
next
interim
bye.