►
From YouTube: CORE WG Interim Meeting, 2020-06-10
Description
CORE WG Interim Meeting, 2020-06-10
A
To
the
interim,
the
core
interim
sorry,
we
couldn't
have
it
last
week
on
the
incurring
list
we
do
have
for
those
who
join
in
particular
for
those
from
ome.
We
do
have
in
the
to-do
list
for
the
future
to
have
the
discussion
of
resource
directory
and
authorization
in
general
and
how
other
is
the
u.s.
can
apply?
This
is
an
interesting
topic,
but
maybe
not
today
we
didn't
have
enough
quorum
for
or
having
that
discussion
today,
but
hopefully
we
can
have
it
in
the
future
and
I
will
keep
you
updated
on
that.
A
We
will
keep
you
updated
on
that
and
who
is?
We
is
the
Marco
and
I
the
Church
of
the
core
working
group.
We
were
duly
noted
that
we
have
to
present
the
note
well
also
in
the
interim
meeting.
So
here
it
is.
As
you
know,
the
normal
applies
to
all
IDF.
Communications
is
not
just
for
IPR
considerations,
but
also
the
general
goodwill
and
participation
of
people
in
the
in
the
meeting,
so
I
think
I
hope
you
all
know
it
I
hope
you
all
have
read
it
and
I
think.
A
C
C
D
C
B
C
Okay,
so
all
right,
so
this
just
is
a
slide
that
we
had
last
time
just
the
background
of
what
we
need,
the
particular
options
for,
and
so
since
we
last
talked
the
changes
that
we've
made
we're
now
in
revision
to
some
of
the
updates
we've
made,
we
added
applicability
scope
just
to
kind
of
make
sure
that
we
couldn't
cause
network
congestion
and
recover
from
stuff.
But
so
we
clarified
on
the
use
of
probing
rate
and
we've
also
introduced
something
called
max
payload
so
that
you
can
send
up
to
max
payloads
in
the
stream.
B
B
We
are
okay
with
that
or
if
this
is
something
that
is
missing
or
I
would
say,
more
consideration
about
the
conditional
control
that
we
have
to
consider
and
the
I
would
say
in
the
draft,
because
we
don't
have
a
slide
specific
rule
at
once.
I
wanted
that
that
we
we
can
post
on
it
right
now
to
have
some
discussion
on.
Only
on
this
particular
point.
B
F
F
The
part
that
I'm
not
sure
about
is
where
the
next
payroll
can
actually
be
constant,
so
but
yeah
again
we're
having
the
problem
that
we
are
trying
to
do
congestion
control
in
a
situation
where
we
already
know
everything
has
maliciously
congested,
so
we
may
not
be
able
to
do
the
usual
things
here
and
I.
Think
starting
out
with
10
is
a
really
good
way
to
be
a
good
citizen.
C
Well,
thank
you
very
much.
Thanks
for
the
feedback
about
the
ten
max
payloads,
we
certainly
think
that's
a
good
idea.
Detailed
descriptions
block
three
is
no
longer
a
repeatable.
It
has
to
be
a
single
entry
within
the
option
list
and
there
is
creation
of
a
new
response
code
which
describes
what
which
blocks
are
missing
from
the
server
perspective,
so
that
the
client
can
we
transmit
them,
as
is
appropriate.
It
follows
along
the
lines
of
what
Christian
came
up
with
the
4.08
in
this
so
and.
D
C
Added
in
the
RFC
cat6
13
definitions
to
the
OS
core
type
stuff
and
there's
been
some
general
takes
tidy
up
as
well
as
trying
to
make
it
clearer
in
terms
of
how
you
do
stuff
so
into
more
specific
blocks.
Three
updates,
the
a
bit
the
all
bits
has
now
been
removed.
We've
now
left
that
as
unassigned,
we
did
look
at
putting
in
streaming
at
some
point
and
that
could
be
a
streaming
bit,
but
we
left
it
as
unassigned,
but
as
a
reserve
bit,
so
that
things
could
be
extended
by
other
protocols,
perhaps
well.
C
They
usage
RFC's
later
for
usage
of
the
blocks
we
put
in
terms
of
the
block
ID.
We
need
to
be
able
to
differentiate
between
different
puts
or
different
bodies
that
are
being
sent
to
the
server
so
that
if
there
is
an
error,
loss,
type
environment,
the
server
can
work
out
that
this
particular
body
block
that's
come
in
is
for
a
different
body
as
opposed
to
the
same
body.
We
need
to
differentiate.
C
We
did
look
at
using
tokens
as
a
way
of
having
a
the
same
token
for
a
particular
body
of
data
being
sent,
but
the
issue
there
is
that,
if
there's
any
partial
errors
with
any
of
the
blocks
that
go,
we
need
really
to
identify
the
client
which
block
is
giving
an
error,
and
so
we
need
to
have
unique
tokens
to
define
which
block
that's
giving
trouble
or
whatever
it
may
be.
So
we've
had
to
go
stay
with
a
block
ID
concept
sitting
here.
C
We've
said
that
they
can't
have
a
value
of
zero,
because
that's
a
special
case
in
the
block
form,
and
we've
also
said
that
tokens
must
not
be
empty
again,
so
that
we
can
pick
up
on
errors.
Should
there
be
a
server,
try
to
tell
us
something's,
not
working
correctly,
for
whatever
reason,
so
we
can
handle
that
particular
block.
F
Yeah
in
my
video
that
I
sent
you
working
two
minutes
before
the
start
of
the
meeting
I'm
asking
whether
we
cannot
use
the
request
tag,
that
is
in
a
different
draft
that
has
just
passed
when
were
plus
four
and
it's
going
to
the
SG
now,
so
the
request
tag
is
seems
to
be
pretty
close
to
blog
ID.
Why
do
we
need
something
new,
okay,.
F
C
Haven't
I
have
issue
with
that
at
all,
so
providing
we
have
the
block
three
gives
the
ability
to
change
the
semantics,
but
the
format
of
block
three
is
the
same
in
how
its
laid
out
and
then
the
separate
option
that
contains
the
request
tag
that
works
absolutely
fine.
For
me,
as
straight
off
the
top
of
my
head
for
something
else,
but
didn't
principle.
That
sounds
right.
So.
F
Maybe
we
should
have
a
offline
unwillingness
discussion,
how
exactly
that
would
work
with
a
request
tag
but
I'm
pretty
optimistic
that
well,
my
practical
problem
with
block
three
is
that
it's
moving
into
a
64-bit
space
and
we
have
been
trying
to
avoid
that.
I
mean
it's
not
a
locker
at
all,
but
if
we
can
avoid
it-
and
we
already
have
an
option
around
that-
that
has
the
right
semantics,
then
I
think
we
should
be
using.
That
makes.
F
F
F
B
It
is
bad
cards
and
what
we
see
and
the
answer
from
John
is
that
we
are
using
it
for
specifically
and
I
would
say
to
identify
a
specific
usage
in
the
in
the
draft,
so
it's
not
using
in
here,
but
we
we
are
seeing
a
specific
meaning
to
that.
I
think
that
we
have
some
text
in
the
draft
John
about
this.
This
part.
F
B
C
B
In
the
way
we
are
defined
the,
for
instance,
if
we
are
using
the
request
tag
to
to
to
be
use
as
the
beat
for
instance,
and
given
that
the
Roku's
tag
is
a
non
critical
and
we
are
defining
the
all
the
the
option.
The
block
three
and
book
has
critical
ones.
Ii,
wouldn't
that
be
I
would
say,
I'm
an
issue
to
to
use
the
tag
for
the
purpose
we
have
in
this.
In
the
same
in
these
drafts,
in.
D
C
So
we
just
made
some
comments
about
the
partial
bodies
being
received
how
we
clean
up
from
those
we
note
that
a
408
is
not
applicable
here
as
caused
problems,
because
blocks
may
arrive
out
of
order,
there's
no
longer
any
lock
stepping.
So
you
know
block
one
can
arrive
after
block
to
and
we
don't
a
for
a
generator.
C
It
just
happens
because
the
network
delivered
them
in
a
different
order,
whereas
going
for
the
418
missing
payloads
in
Scylla
before
eight,
we
can
then
indicate
the
missing
blocks
and
we
can
go
into
recovery
scenario
and
in
that
they
would
be
within
the
payload.
Just
a
counter
and
list
of
missing
block
numbers
to
us
does
make
sense
that
we
support
that
block
three
uses.
The
tooth
31
continue.
F
C
F
D
D
Please
Christie
in
combination
with
this,
except
from
this
example,
and
the
previous
slide
on
231
not
being
used.
Is
there
any
possibility
for
the
client
to
ask
for
an
intermediate
status,
or
is
that
is
that
always
just
either
for
18
or
the
complete
one,
like
a
like
a
positive
response
on
on
okay,
everything's
good
so
far
as
opposed
to
me,
you're
showing
almonds
here?
Is
there
any
way
the
client
can
can
can
ask
for?
Okay
is
this?
Is
this
now
good,
so
far,
ask
for
a
explicit
confirmation,
interesting.
C
Question
in
in
the
actual
text
we
have,
we
talked
about
Matt's
payloads
and
at
the
max
payload
point
we
could
either
pause
for
a
couple
of
seconds
or
we
could
send
a
confirmable
at
that
point
so
that
one
can
recover.
The
thing
is
determined,
the
things
were
okay,
but
we
haven't
really
thought
about
the
client
giving
the
ability
to
be.
You
know
health
check
in
the
middle
of
this
transfer.
Okay,.
D
D
There
I
think
there
will
need
to
be
something
like
this.
If
this
is
going
to
ever
work
over
proxies
because
the
proxy
might
you
might
be
on
the
fast
link
to
the
proxy
and
the
proxies
then
on
the
service.
Okay,
now
I'm
I
can't
keep
up
with
that
pace,
so
so
the
con
alone
will
probably
not
be
sufficient.
C
D
C
Request
tag
or
a
response
tag,
or
something
like
that
as
an
alternative,
but
we
can't
use
a
tag
because
the
client
could
send
off
a
get
request
of
the
tag
we'll
get
back
a
203
which
is
not
basically
saying
I
want
the
this
missing
block
or
anything
like
that.
It
just
comes
yep,
you've
already
got
it
so
what
the
value
you
have
is
valid.
D
D
If
we
assume
that
this
is
all
using
only
into
each
X
and
if
it
doesn't
have
a
representation
and
asked
for
some
asks
for
something,
it
would
not
send
any
block,
ID
or
e
tag
at
all
and
then
get
something
back
that
has
knee
tag
that
either
matches
the
rest
of
what
the
client
has
or
it
doesn't
adding
in
a
block.
Id
would
allow
the
client
to
dig
through
historical
representations
of
that
resource,
and
unless
that
is
the
intention,
I
don't
see
why
doing
this
with
something
different
than
attack
would
add
any
value.
Okay,.
C
D
This
is
not.
This
is
about
observation.
Observation
is
inherently
eventually
consistent.
If
there
is,
if
there
is
about
two
and
the
client
is
already
receiving
part
of
body,
then
all
that
matters
is
that
body
arrives
in
its
entirety
and
body
1
is
obsolete
by
the
time
that
body
comes
along
if
you're.
If,
if
there
is
any
interest
in
your
application
in
having
each
and
every
individual
body
that
is
sent
in
an
observation
sent
along,
then
observation
as
it
is,
is
probably
not
what
you
want
to
use.
C
F
Think
about
the
two
cases
here.
So
if
you
do
a
get
or
fetch
and
do
the
the
very
same
get
a
fetch
again,
then
you
might
run
into
two
or
three,
which
is
fine.
The
server
just
tells
you
whether
you
still
have
the
same
information
there
and
you
are
done.
If
you
do
something
like
like
a
push
but
something
like
a
post
or
an
eyepatch
where
you
are
waiting
for
an
action
result,
then
of
course
doing
the
same
request
twice,
can
give
you
a
different
action
result,
at
least
for
petrify
fetch
and
for
post.
C
F
Was
specifically
talking
about
requests
that
don't
return
the
current
resource
value,
which
is
where,
where
the
UTech
comes
in
but
requests
that
have
an
action
result,
so
you
say
something
like
make
me
a
coffee
and
then
the
coffee
machine
says
in
progress,
we'll
take
50
seconds,
and
that
is
of
course
response.
That
is
very
specific
to
the
request
and
and
that's
something
where
you
need
a
request
tag
to
make
sure
you
can
split
that
up
into
blocks
because
really
doing
the
same
request
again
make
me
a
coffee.
C
My
layman's
terms,
if
we
do
a
post
and
the
response
is
coming
back
and
we
follow
that
by
a
separate
post
and
there's
a
separate
responses
coming
back.
Both
responses
require
the
use
of
block
4
then,
which
is
gonna,
make
sure
we
just
get
the
right
ones.
Coming
back
to
the
right
things.
Should
we
need
to
recovery?
C
C
F
D
C
B
C
C
D
C
F
Well,
it's
saying
that
we
adopted,
as
a
workgroup
document,
has
yes
to
connotations.
One
is
that
we
as
we're
interested
in
doing
work
on
this
and
I
think
it
has
been
demonstrated
that
this
is
the
case,
so
that
that
should
be
obvious.
The
other
question
is
whether
we
are
making
a
statement
that
this
is
exactly
the
way.
F
The
approach
we
want
to
use
here
and
I
think
we
have
seen
during
the
development
of
this
so
far
that
there
are
some
some
bends
and
corners
in
the
development
of
this
as
we
get
new
ideas,
so
I
would
expect
that
this
is
still
still
possible,
even
though
I
think
we
we
are
slowly
converging
now.
So
what
we
have
now
looks
pretty
good
for
me
as
a
particular
design,
I'm
still
trying
to
understand
the
implications
on
the
ecosystem,
but
I
think
that
takes
a
little
bit
more
time
anyway.
So.
A
So
in
general
lines,
I
see
why
work
shouldn't
continue
on
this
document
even
before
any
kind
of
working
robot
option
is
the
adoption
of
the
of
the
document,
something
that
you
need
urgently
at
this
point.
Or
is
it
something
that
could
wait
a
bit
longer
because,
as
it
is,
he
seems
to
be
a
still
working
progress,
there's
a
few
things
that
need
to
be
fixed
and
he
hasn't
been
presented
in
a
proper
when
this
interns
are
proper
and
this
person
is
kind
of
a
bit.
A
This
is
so
you'll
be
nice
to
get
a
full
presentation
of
the
traffic
one
of
the
meetings.
Maybe
this
has
a
bit
more
fix
it
a
bit
more
and
then
call
for
adoption.
I,
don't
see
why
we
shouldn't
have
it
in
the
in
principle,
but
I
don't
see
also
why
it
should
be
so
urgent,
because
we
have
plenty
of
all
the
documents
that
require
the
attention
and
reviews,
and
you
know
general
care
for
already
in
core
anyways.
B
Thank
You
Jaime
for
this
I
think
this
is
what
we
have,
and
we
say
indicated
last
time
is
that
we
we
we
have
another
work
working
of
document
which
we
have
indeed
dots
working,
which
is
the
telemetry
and
that
we
are
targeting
to
have
a
we
said
in
the
working
class
called
way
I
would
say
by
by
July.
So
what
we
wanted
is
that,
to
make
sure
I
would
say
the
extension
that
will
be
I
would
say
that
we
are
discussing
here.
B
If
there
is
I
would
say
there
is
probably
to
be
adopted
in
working
group,
and
we
will
try.
I
would
say
to
officially
integrate
the
equipment
from
the
working
group
and
the
the
design
modification
that
will
make
I
would
say
before
will
be,
will
reflect
worked.
You
as
core
working
group
want
us
to
to
do
so.
Having
I
would
say
this
this.
This
adoption
call
at
least
in
the
core
working
group.
We
will
give
us
this.
I
would
say
this
this
right
signal
and
also
for
us.
B
It's
also
to
reconsider
whether
we
will
add
I
would
say
the
dependency
in
our
core
in
our
telemetry
specification
to
this.
To
the
specification,
so
otherwise
that
will
be
the
other
plan
that
he
had
mentioned
last
time
is
that
yeah,
the
telemetry
specification
is
adults
working
on,
which
is
the
client,
which
is,
which
is
the
one
that
will
use
this
specification,
and
we
will
I
will
judge
between
out
without
I
would
say
this
this.
B
B
I
would
say
happily
to
continue
this
I
would
say
D
and
to
go
in
all
the
comments
from
you
and
she's
really
appreciated,
and
here
for
for
us
and
this
in
this
industry
as
individual,
but
if
we
can
do
it
officially,
that
will
be
for
me
better
and
will
give
me
as
an
editor
of
this
limited
specification,
that's
working
good,
the
right
in
cinema,
whether
I
will
add
or
not
any
normativity
here
to
this
one.
So
that's
the
I
would
say
to
give
you
the
fall,
the
fall
picture
we
have
so
far.
B
A
G
B
I,
don't
I,
don't
want
that
and
I
don't
want
to
yet.
So
if,
if
it
is
I
would
say
a
matter
of
six
months,
that
will
be
fine.
So
if
we,
if
we
have
an
adoption
earlier,
that
means
that
we
will
have
at
least
some
time
so
that
we
can
have
the
specification
that
will
integrate.
The
I
would
say,
documents
from
the
working
group
and
try
to
cover
something
which
is
really
I
would
say,
Metron,
stable
and
will
I
would
say,
solve
the
various
corner
business
we
we
didn't
had
investigated
so
far.
B
A
So
I
mean
I
will
so
in
principle.
I
could
think
of
giving
a
presentation
of
the
document
and
the
current
form
in
the
next
idea,
which
is
in
July
Mon
and
then
during
the
idea.
For
a
few
weeks
later,
adoption
call
but
I'm
pretty
open
for
others
in
the
call
to
give
right
now
to
give
their
opinion
as
well.
That
is
something
that
they
they
they
could
see
working
out
or
if
they
would
prefer
to
slow
down
a
bit
or
go
faster.
F
So
my
view
is
that
we
should
allow
other
working
groups
to
do
useful
work
on
top
of
co-ed
and
if
that
involves
coming
up
with
new
options,
that's
why
we
have
this
extension
point
in
coop
and
I.
Think
we're
currently
having
a
very
productive
discussion
about
how
to
do
this
in
a
way
that
doesn't
damage
the
existing
co-ed
ecosystem.
So
I
don't
see
a
big
problem
with
adopting
it.
If
that
helps
the
other
do
their
work.
I.
E
Here
the
Wi-Fi
that
was
catching
up
from
the
minutes:
okay,
yeah,
you
just
don't
bring
in
another
option
that
was
raised
at
the
previous
interim
on
this
Mohamad
dimension
that
well
as
an
extreme
alternative.
This
can
also
wait
possibly
for
later
updating
time
of
the
telemetry
document
when
things
are
more
stable,
possibly
in
core,
be
still
a
viable
alternative.
B
It
will
say
this
is
what
I
said.
Is
that
if
there
is,
if
we
don't
see,
I
would
say
signals
that
we
will
have
something
soon
we
won't,
we
will
just
add
they
will
say
a
statement
in
the
in
the
telemetry
specification
to
say
that
we
are
aware
this
is
an
issue
and
this
current
version
of
the
specification
won't
solve
it,
and
this
is
for
future
and
then
in
the
future
we
can.
We
can
have
something.
It
will
update
that.
B
That
part,
that
that's
what
I
have
said
last
time-
and
this
is
what
I
have
repeated
in
my
earlier
comment
to
say:
that's
and
that's
why
I
see
that's
a,
we
won't
add
any
normative
text
there
until
we
have
something
which
is
that
we
are
I
would
say
sure
we
will
get
from
the
front
from
I
would
say
the
co-working
group
or
in
the
dots
working
so
yeah.
That's
that's,
that's
still
an
option
for
me,
but
it's
not
my
preferable
one.
B
What
I
want
is
that
you,
this
is
an
issue
that
witnesses
I,
would
say
important
for
the
DT
limit
free
work.
If
we
can
work
together
in
order
to
make
some
progress
and
to
I
would
say
to
solve
the
problem,
we
have
there
with
full
alignment
or
your
other
constant,
that
you
are
very
familiar
with
and
I
would
say
that
will
satisfy
you
without
destroying
other
part
of
the
ecosystem.
B
That's
that's
what
my
my
favorite
option
and
that's
why
I
am
really
open
to
the
discussion
and,
as
you
know,
I
have
already
worked
in
the
past
for
the
hop
limit
and
so
on.
So
we
are
responsive
to
comments.
We
are
I
would
say
in
a
positive
spirit
so
to
to
to
collaborate.
So
my
favorite
is
to
to
see
the
specification
work
advance,
if
not
I'm
afraid
that
yes,
the
year
the
other
I
would
say,
D
option
to
go
forward
without
having
this
adoption
is,
will
be
the
way
to
put
it
to
proceed.
B
Fully
agree
with
you
with
your
crystal
and
thank
you
again
for
raising
this
comment.
So
this
is
why
we
have
removed
that
that
part
from
the
from
the
junior
version,
because
we
wanted
something
which
is
really
focused
and
in
in
the
last
meeting
we
told
that
there
is
some
I
would
say
some
tension
to
to
include
something
more
generic
than
the
dots
use
case,
and
that's
why
we
have
added
that
streaming.
Key
is
there,
but
with
your
comment,
a
real
I
agree
with
that.
B
Yes,
so
whether
we
need
to
keep
focused
so
that
we
can
make
some
progress
or
to
agree
to
add
new
stuff
and
I
fully
agree
that
you
do
that
we
need
to
be
focused
and
if
this
use
case
the
streaming,
one
is
interesting
for
you
for
the
generic
use
case.
Please
just
record
it
and
add
it
to
Wendy.
Do
you?
Okay,
we'll
have
to
revise
I,
would
say
more
generally.
Did
this
deal
but.
C
B
We,
our
our
our
intent,
is
really
to
cut
focus
and
to
solve
this
specific
problem
with
the
applicability
setting
that
we
have
added
there.
We
can
also
add
more
text
to
see
that
this
is
a
really
specific
to
and
not
advised
or
whatever
language
that
you
want.
So
this
is
not
something
this
is
really
recommended
in
the
generic
generic
use
case.
That's
also
something
that
we
are
really
open
to
discuss.
A
So
whether
we
want
to
discuss
it
right
now
on
the
mailing
list
or
in
a
different
meeting
in
principle,
I
doubt
that
we
can
perform
that
we
can
do
a
clockwise
peace
in
six
months.
I
think
they'll
be
pretty
ambitious
and
I
mean
I'm,
trying
to
measure
a
bit
the
energy
of
the
group
on
the
the
time
allocation
and
considering
the
amount
of
drafts
that
we
have.
A
A
Okay,
I
mean
we
can
also
take
it
on
the
mailing
list.
This
this
discussion,
I,
think
I.
Think
the
adoption
of
specifically
use
case
or
document
should
be
feasible
in
a
month
in
in
the
ITF
I
mean
it'll,
be
really
happy.
You
could
present
the
draft
in
a
meeting
that
will
be
useful
for
us,
we'll
have
an
attorney
the
interims,
and
it
could
also
give
more
time
for
people
to
make
an
opinion
I
think
Marco.
What
do
you
think
will
be
your
yeah
great.
A
You
mean
the
idea
will
be
like
discussion
in
July
during
the
next
IDF
in
principle
and
extension
for
a
specific
use
case.
Unless
the
group
really
wants
to
do
clockwise
peace
and
in
which
case
I
think
you
should
have
probably
just
an
informative
reference
in
your
document.
I
do
not
know
what
the
group
will
say
because
they
are
not
saying
anything
concrete
right
now,
so
the
Middle
East
also
work.
So
we
can
have
it
on
the
mailing
list.
B
Yeah,
so
that's
yeah,
that's
an
option.
I
it's
really
your
call
to
to
make
and
they
I
will
I
would
say,
but
I
don't
think
there
is
a
point
to
wait
for
the
the
IDF
meeting
to
me
this
kind
of
discussion,
so
we
have
the
mailing
list.
The
mail
lists
are
therefore
I
would
say
to
figure
these
nations
I,
don't
see
why
we
cannot
do
it
right
now,
but
it's
it's
again
as
I
mentioned,
it's
your!
It's
really.
A
You
will
get
the
same
answers
that
you
have
right
now
and
that'll
be
only
a
handful
of
people,
so
you
know
I
would
guess
that
you
have
more
chances
to
get
in
more
feedback
if
we
give
people
a
bit
of
time
to
to
read
it.
The
drugs
on
make
an
opinion,
but
it
could
happen
that
you
don't
get
more
feedback.
So
I,
don't
know
a
lot
of
time,
helping
or
not,
but
I
would
I
would
wager
that
you'll
get
more
positive
feedback.
B
Ok,
so
at
least
for
our
self,
we
will
do
that.
We
will
yeah
we'll
update
the
I
would
say
the
draft
reflect
the
cameras
that
we
received
today
we
will
get
back
to
the
question
and
also
to
Carson
about
the
the
use
of
the
request
tag
and
to
to
to
see
if
we
can
glue
these
pieces
to
together
what
we
have,
what
we
have
so
far
and
then
we'll
communicate,
inform
the
working
opti
when
this
new
version
will
be
available
and
then
we
can,
we
can
take
it
there.
A
A
G
Hi,
no
I
don't
have
slides
it's
just
informal,
just
to
talk
a
little
bit
about
the
coop
technology
side
and
you
might
have
seen
that
I
sent
an
email
to
the
mailing
list
a
while
ago
and
the
idea
was
to
add
the
tab.
So
this
is
not
a
core
I
want
to
say.
This
is
not
the
core
working
group
item,
but
it
is
related
to
a
core
working
item
which
is
coop
and
and
it's
Karsten,
who
is
maintaining
and
hosting
this
cooperative
technology
website.
G
G
We
won't
be
able
to
merge
the
pull
requests
right
now,
so
I
think
Carsten.
You
and
I
will
probably
need
to
talk
offline.
If,
if
we
are
going
to
make
this
we're
going
to
merge
this,
which
you
seem
positive
about
yes,
so
I
volunteered
to
to
change
my
HTML
request
to
a
markdown
per
request.
If
you
put
the
markdown
online
somewhere
on
a
github.
F
G
And
and
maybe
might
be
good
because
there
are
all
the
poor
requests,
so
it
might
be
good
to
tell
other
people
that
you're
poor
quest
has
not
been
merged
just
because
yeah,
that's
the
constants
website
is
originally
marked
down
and
yeah.
So
he
would
want
to
transport
your
request
to
mark
down
before
merging
it.
G
Yeah
I
just
wanted
to
point
this
out
and
say,
for
example,
Thomas
volunteered
to
to
add
some
text
about
DTLS
and
really
happy
about
that.
It's
still
my
my
pull
request
and
it's
still
gonna
go
through
Carsten
approval,
afterward,
but
feel
free
to
to
add
to
my
text.
If
you,
if
you,
if
you
want
to,
should.
G
F
G
G
You
so
this
is
mostly
a
question
to
Jim
as
our
cozy
expert
Jim,
if
you're
around
good.
So
this
is
about
the
group
of
score
document
so
just
for
status
update
for
anybody
interested.
We
are
working
on
the
group
of
score
document
and
we
will
be
submitting
a
new
version
soon,
and
one
of
the
updates
is
that
we
finally
did
the
change
about
using
the
cozy
cap
abilities
instead
of
defining
our
own
registry
and
while
we
were
implement
what
we
were
implementing
is
change.
G
The
question,
because,
right
now
the
cozy
cap
abilities
of
the
algorithms
doesn't
have
any
any
field
that
is
not
in
the
cozy
key
type
right
now,
it's
only
the
key
type
in
in
that
column
there.
So
we
were
wondering.
If
do
you
think
that
in
the
future
there
might
be
other
other
algorithms
that
do
register
their
parameters?
That
will
not
be
found
in
the
cosas
key
type
capabilities.
G
Let's
see
I
didn't
see
that
right
now,
because
I
only
saw
that
in
Section
ten,
so
I'm.
Looking
at
section
ten
point,
two
of
changes
to
cause
the
algorithms
registry-
and
this
is
where
you
introduced
the
capabilities
column,
and
you
say
that
the
new
column
is
populated
with
the
array,
including
key
type
for
all
current
non
provisional
registrations.
So.
G
H
G
G
E
You-
and
there
was
also
another
point
raised
by
dream-
on
jumper-
about
status
of
the
stateless
document.
So
the
last
thing
I
could
see
on
the
list
was
a
reply
from
Bank
a
dock
on
the
latest
revision
of
Klaus.
That
seemed
to
wrap
up
the
discussion
actually
saying
that
an
open
point
was
okay.
Maybe
Klaus
has
more
news
on
that.
I
The
second
of
a
quick
status
update
and
so
from
there
is
D
comments
that
I
have
a
sister
I
haven't
addressed
the
one
from
Roman
Daniel.
If
yet,
and
then
cadets
reveal
I
have
gun
question
by
question
and
the
questions
that
I
have
come
through
have
resolutions.
But
there
are
few
more
points
that
been
raised.
That
I
haven't
addressed
yet.
A
E
A
A
H
Yes,
so
I
I
pushed
a
new
version
of
the
document
and
for
me
the
only
remaining
question
is
whether
we
should
turn
him
sit,
how
I
sit
as
it
was
suggested,
I
think
by
handy
and
there
were
some
people
having
voicing
support
for
this.
I
also
talked
with
Alexander
elephant
there.
He
was
not
very
keen
on
the
idea,
so
I
asked
him
to
voice
his
opinion
on
the
married
way
so
that
it's
documented,
but
that's
the
situation
there
I
believe
there.
F
H
H
Trapped
in
github,
so
there
is
I
believe
for
that
matter
and
out
there,
including
moving
the
media
types
outside
of
the
specification
for
some
cases
as
it
was
requested,
so
that
sweet.
If
anyone
is
interested,
please
review
the
new
version.
So
if
I
don't
have
any
new
comments,
I
will
publish
a
new
version
of
all
the
documents.
You
can
also
review
to
me
at
that
point
of
time.
Just
let
me
know
so.