►
From YouTube: IETF111-CALEXT-20210729-2330
Description
CALEXT meeting session at IETF111
2021/07/29 2330
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
B
B
You
probably
have
seen
this
slide,
the
not
well
so
if
you
haven't
please
the
time
to
to
read
it
very
very
fast
and
we
have
a
hello
from
francesca
and
I'm
wondering
francesca,
do
you
want
to
say
something
before
we
go
to
the
working
group
status
or
after
the
working
group
status.
B
Okay,
so
working
up
status,
so
we
have
an
rfc.
We
have
the
gs
calendar,
but
we
have.
We
are
close
to
have
two
additional
rfcs
with
the
event
pub
extension
and
the
alarm
extension.
B
So
the
working
of
documents
I
have
listed
are
the
the
I
calendar
series,
the
gs
calendar.
I
calendar
conversion,
server,
server,
id
server
side
subscriptions,
subscription,
updates
and
a
vpool
draft.
B
So
I
think
we
will
have
a
presentation
on
the
gs
calendar
I
calendar.
So
this
is
where
we're
gonna
start
with,
and
I
mean
the
other
draft
from
mike.
So
I'm
wondering
if
mike
is
here
and
if
he
wants
to
say
something
at
some
point.
B
Oh
prediction
so
yeah
I
I
might
have
missed
this
one,
so
the
question
I
would
have
for
you
is,
which
is
the
one
we
should
pick.
D
And
well
there's
a
couple
actually
that
are
missing.
There's,
there's
task,
extensions
and
and
relations
are
not
on
the
list
and
and
I'm
inclined
to
say
we
should
try
and
and
concentrate
on
those
two
because
they're
useful
for
the
js
calendar.
I
counter
mapping.
B
D
B
D
Yeah
both
of
those
have
are
referenced
either
implicitly
or
explicitly
buy
the
js
counter
icon
on
the
mapping.
B
Okay,
and
do
you
know
when
we
will
have
those
draft
being
I
I
guess,
they're
pretty
much
advanced.
D
D
From
losing
anybody,
who's
had
time
to
push
along,
so
I've
taken
that
on
okay,
but
relations,
I
think,
has
been
pretty
well
looked
at
and
and.
D
A
Tasks
finished
just
before
itf
started,
so,
yes
that
is
adopted,
we
just
need
to
ask
them
to
up
upload
a
new
version
of
the
draft.
Yeah
that'll.
Be
me
cool
all
right
mike.
If
you
upload
a
new
version
of
the
draft,
we'll
approve
it.
B
B
And
so
the
relation
we
can
expect
the
relation
to
be
pushed
pretty
easily
in
the
next
few
in
the
next
next
month.
D
I
I
think
so
it's
been
pretty
well
discussed
and
looked
at.
I
don't
think
that
there
are
any
particular
problems.
It's
relatively
simple,
rfc
draft
rc
that
really
just
codifies
a
lot
of
pre-existing
stuff.
B
Okay,
okay,
so
let's
focus
on
the
relation
in
for
the
next
month
and
then
the
task,
and
so
we
clean
the
queue.
So
is
that
nail
or
rubber.
C
Before
we
remove
the
presentation,
there
is
actually
something
I
wanted
to
say
well,
first
of
all,
congratulations
well
done.
Working
before
it's
published,
I
arrived
very
late
and
for
the
delayed
process
a
little
bit
but
good
job
and
the
rsc
actually
has
a
number
of
registries,
and
I
have
now
a
task
to
find
experts
for
this
ayanna
registry.
C
B
We
have
a
few
people
that
have
problem
hearing
you.
C
B
C
Nothing.
Okay,
so
I
was
saying
first
of
all
that
I
wanted
to
congratulate
the
working
group
and
good
job
on
publishing,
roc
8984,
of
course-
and
I
arrived
quite
late
to
the
publication
process
and
possibly
delayed
it
a
little
bit
but
well
done
to
get
it
done,
and
I
also
was
saying
that
this
rfc
has
a
number
of
ayana
registries
that
need
designated
experts.
C
So
I
have
this
task
to
to
actually
select
the
significant
experts.
I
do
not
recall
right
now
if
I
have
sent
an
email
to,
but
I
think
I
have
to
the
chairs
and
authors
I'll
be
looking
for
experts
for
these
registries,
so
yeah
so.
B
I
think
I
I
mean
I
I'm
sure
you
you
send
that
email,
because
I
had
in
mind
that
I
responded
to
it
and
yeah.
We
proposed
you.
I
think
we
proposed
nail
robert
mike
and
they're.
Probably
in
the
working
group
I
mean
they're,
probably
attending.
B
B
E
Hello,
hi,
hello,
okay,
so
cheers
can
I
kill
into
some
mic-
and
I
have
been
working
on
this
since
last
itf
and
the
next
slide
please.
E
So
the
part
of
converting
from
I
calendar
to
j
is
calendar.
I
wouldn't
say
it's
done,
but
we
are
it's.
We
are
quite
far
with
that.
Already
we
are,
we
are
covering
all
the
properties
and
eye
calendar
parameters
that
we
that
we
tend
to
cover,
except
for
the
event
pubs
or
even
event,
top
is
already
in
in
there
for
for
this
conversion
direction.
E
So
what
we
will
do
now
is
that
we
will
cross
check
that
with
our
our
implementations,
both
mike
and
I
have
an
implementation
in
that
direction
already,
and
I
guess
we
we
will
adapt
the
draft
a
bit
there,
but
it
all
looks
quite
reasonable.
Already
next
slide,
please
for
the
other
direction
from
converting
js
current
to
I
calendar
we
are.
E
This
is
our
main
focus
at
this
moment.
A
couple
of
decisions
we
made
there
were
that
in
js
calendar
you
can
have
fraction
seconds,
but
you
you
can't
currently
in
I
calendar
for
quite
a
while.
We
we
had
thought
we
can.
We
can
cover
this
within
with
a
pro
with
a
parameter
on
date,
time,
values,
properties,
either
called
fractional
or
sub.
Second,
we
had
discussed
a
couple
of
options
how
to
how
to
do
that
in
eye
calendar,
but
it's
really
something
that
we
came
to
realize.
E
We
would
only
do
a
half
half
way
job
defining
that
in
our
conversion
draft.
It
really
warrants
a
separate
rfc
that,
irrespective
of
js
calendar,
thinks
about
how
to
what's
needed
for
fractional
segments
and
probably
also
sub-second
frequencies
and
recurrences
to
make
this
happen
high
calendar.
E
So
it's
we
are
not
going
to
cover
that
anymore
in
the
conversion,
and
in
that
respect
we
see.
Okay,
fractional
seconds
won't
just
be
supported
in
eye
canada
during
the
conversion.
Right
now,.
E
And
another
thing
is
that,
with
the
event
pop
draft
now
being
in
auth
48
already,
we
definitely
want
to
use
the
new
components
and
properties
that
it
that
it
gives
us,
namely
these
are
dv
participant
and
structured
data
properties,
mainly
which
we
want
to
use
to
to
to
map
the
js
calendar,
participant
and
js
link
objects
and,
and
others
I've
already
defined.
The
event
pub
is
the
is
it
backwards
compatible
way
that
the
view
participant
still
has
to
have
a
corresponding
attendee?
So
that
should
be.
E
That
should
be
all
good
for
clients
that
have
no
that
do
not
implement
event
pub
at
this
stage,
however,
what's
uncovered
at
the
moment.
This
is
a
general
issue
with
I
calendar
is
that
we
will
have
to
decide
when
to
when
to
trim
down
the
eye
candidate
that
we
produced
for
clients
that
have
noah
that
that
might
choke.
Otherwise,
if
we
sent
them
components,
they
do
not
know.
E
E
I'm
not
sure
if
anyone
in
the
working
group
here
has
already
experienced
with
with
how
to
handle
handle
these
situations.
It's
it's
not
really
related
to
js
calendar,
but
but
it's
something
we
need
to
solve
for
I
calendar
and
cal
dev
to
make
that
work
properly.
D
Well,
I
mean
yeah,
I
mean
things
are
supposed
to
accept
valid.
I
calendar
data
whatever
that
means
which
does
mean.
I
do
know
that
I
count
the
ical
for
j
was,
would
actually
not
manage
components
nested
as
deeply
as
they
could
go
with
with
the
event
problem
depot,
and
I
I
provided
fixes
for
that.
That
might
be
the
case
for
other
libraries,
but
I
I
mean,
unfortunately,
unless
you've
got
a
protocol,
you
can't
negotiate.
E
Yeah
I
mean
if,
if
we
can't
negotiate
like
in
imep,
I
think
in
our
implementation
we'd
rather
assume
that
they
cannot
handle
it.
So
we
send
out
the
trim
version
rather
than
hoping
but
yeah.
I
know
it's
basically
falls
back
to.
I
don't
know
kind
of
a
b
testing
and
see
see
when
you
got
issues
with
that,
but
it's
it's
really
sub
optimal.
D
Before
we
go
on
too
far,
can
we
go
back
to
fractional
a
minute?
Oh.
D
I
think
what
we
would
suggested
when
we
were
talking
about
the
the
whole
thing
and
we
and
we
were
coming
to
some
realizations
over
the
implementation,
problems
of
fractional
seconds
and
one
of
the
issues.
While
I
can
implement
js
calendar,
I
won't
necessarily
have
fractional
seconds
underlying
it
to
start
with.
D
So
I
think
one
of
the
things
we
talked
about
was
having
being
able
to
indicate
whether
or
not
you
supported
fractional
seconds
at
all
and
and
the
the
default
case
is
probably
that
we'll
start
off
not
supporting
fractional
seconds,
because
we,
the
internal
representation,
doesn't
so,
I
think,
there's
a
sort
of
a
sub
bullet
there
about
having
some
sort
of
capability
or
whatever,
and
something
in
caldave
as
well
to
to
indicate
whether
or
not
you
support
fractional
seconds
and
and
there's
a
sort
of
slight
addition.
D
One
of
the
things
I
think
I
did
post
that
extracted
draft
for
the
fractional
parameter,
which
I
extracted
from
the
you
know
the
mapping
draft
almost
immediately.
I
I
decided
that
we
shouldn't
be
doing
that
really
what
we
should
do
in
icon.
D
If
we
want
to
support
fractional
seconds
is
just
support
fractional
seconds
properly
in
all
in
throughout,
because
I
think
it's
a,
I
think,
while
there's
been
repeated
requests
for
fractional
seconds
in
calendar
data,
they
they're
they're
coming
from
people
who
have
a
fairly
specialized
use,
they're,
either
wanting
to
record
stuff.
That's
happening
down
to
the
sub
second
interval,
or
they
want
to
do
things
like
create
very
frequent.
You
know,
or
at
least
very
short
interval
iterations.
I
know
in
the
smart
grid.
D
So,
but
in
those
cases
you
can
negotiate
that
you're
going
to
support
it
and
if
and
and
if
I
counter
terms
up
with
sub
seconds
on
the
dt
start
or
whatever,
that's
fine,
it's
better
than
doing
this.
This
weird
parameter
thing,
I
think,
is,
is
just
just
support
fractional
seconds.
E
Okay,
yes
agreed
so
I'll,
continue
then,
or
do
you
have
more
more
to
just?
Do
we
have
more
to
discuss
on
the
backwards
compatibility
also
with
the
new
event,
components?
E
Nope,
okay,
okay,
so
so
one
of
the
things
we
want
to
do
is
preserve
the
so
in
js
calendar
we
have
a
couple
of
properties
which
are
which
are
multivalued
and
and
we
use-
and
we
almost
everywhere
use
the
pattern
of
having
that
mighty
value
as
a
map
with
with
identifiers
and
then
the
values
whatever
they
are.
Okay,
and
these
these
maps
have
these
identifiers
and
the
map
have
only
meaning
within
the
event,
but
we
want
to
preserve
these
identifiers.
Also
in
I
calendar,
so
we
can
loop.
C
E
Properly,
between
jsc
and
icon
and
the
other
direction,
so
what
I
think
we
we
should
do
is
to
add
a
new
icann.
The
property
called
id,
which
is
text
value
with
no
further
restrictions,
and
this
this
id
property
then
will
allow
us
to
to
put
it
on
or
actually
sorry,
an
iv
parameter,
and
this
property
then
will
allow
us
to
to
take
put
this
on
everywhere,
where
we
need
it,
I
think.
E
Actually,
it
also
opens
the
possibility-
and
we
might
also
need
that
for
gs
calendar
to
refer
from
one
property
or
component
within
the
ev
calendar
to
other
properties.
Within
that
same
weave
and
say
I'm
thinking
of
the
fact
that
links
so
I'm
thinking
of
the
fact
that,
for
example,
a
link
object
in
js
calendar
can
also
have
no
sorry,
a
location
can
also
have
links,
and
now
we
could
cross-reference
also
declare
this
cross-reference
within
the
I
calendar.
E
But
of
course,
implementations
can
also
use
this
id
property
for
something
else.
I
guess,
if
they
do
not
care
about,
is
canada?
Are
there
any
opinions
about
such
a
new
parameter.
E
It
doesn't
sound
like
it,
so
I
guess
we'll
go
with
it
if
it
turns
out
to
be
useful
in
our
tests,
and
the
last
thing
is
one
thing
I
haven't
attacked
it.
I.
A
A
E
I
think
it
depends,
in
my
opinion,
it
depends
on
if
we,
if
we
want
to
use
this
just
for
our
gs
calendar,
then
it
should
get
a
a
name
that
really
reflects
this
effect
or
if
we
keep
it
as
a
generic
parameter.
That
could
also
be
used
for
something
else,
but
of
course
that
might
then
we
might
run
into
issues
when
people
are
using
it
actually,
indeed,
for
something
else:
yeah.
A
I
think
the
the
main
place
we're
going
to
run
into
issues
is,
if
we
don't
constrain
it
down
to
being
an
object
id
in
the
js
calendar,
specific
constraints
on
what's
allowed
to
be
in
it,
if
we
just
allow
any
any
random
string
in
there,
that
could
cause
issues.
So
we
probably.
E
Yeah
right
I
mean,
I
also
thought
of
that.
I
mean
we
would
just
I'll
try
to
ignore
it,
but
basically,
but
of
course
we
can
also
really
call
this
a
gs
calendar
id,
and
then
we
can
put
all
the
constraints
on
it
that
we
want
for
that.
A
But
it
still
wants
to
have
the
constraints.
I
think
okay
in
the
spec.
D
Yeah,
I'm
I'm
yeah.
Well,
it's
one
of
these,
we'll
probably
we'll
probably
discuss
it
for
a
while
about
what
exactly
it's
called,
but
I
would,
I
don't
think
we
ought
to
make
it
specific
to
just
counter
at
least
the
name,
we're
bound
to.
E
Yeah,
okay
works
for
me
great.
So
then
we'll
discuss
this
in
our
next
rfc
draft
session
and
okay
and
localizations.
So
this
I
haven't
really
spent
much
time
still
on
covering
this
in
our
in
our
own
implementation,
but
all
the
attempts
that
I'm
made
were
really
sub-optimal,
so
we
might
need
to
have
a
v-localization
component
to
define
that
that
allows
us
to
really
really
map
all
the
all
the
contents
of
the
localizations
object
in
gs
calendar
properly.
E
I'm
not
I'm
I'm
seeing
this
differently,
I'm
not
aware
of
any
any
of
any
current
solution
being
the
length
parameter.
That
is
enough
for
no.
D
There
isn't
you
you,
I
am
and,
as
I've
been
a
proponent
of
ios,
I
I've
been
saying
we
need
localization
for
some
time,
so
I'm
prepared
to
help
define
that
and
you're
right.
I
think
I
think,
didn't
we
decide
in
the
last
the
last
chat
we
had
that
we
would
probably
put
localization
off
for
the
time
being
in
the
in
the
mapping
and
do
do
that
as
a
separate.
E
Yes,
I
think
I
think
we
already
discussed
it
and,
if
not,
I
would
have
proposed
it
now.
D
D
D
So
we
can
cover
it
as
a
separate,
a
separate
draft,
then
rfc
yeah.
E
Sounds
good
to
me:
these
are
the
points
I
had
prepared.
Is
there?
Is
there
any
other
thing
to
discuss
for
js
calendar?
I
canada
now.
B
Okay,
good,
so
maybe
that's
something
we
will
discuss
while
we
were,
we
will
be
looking
at
the
the
milestones,
but
I'm
wondering
when
do
you
think
that
the
document
is
going
to
be
ready.
B
Okay,
so,
but
I
mean
do
you,
do
you
expect
to
have
it
ready
in
december
or
june.
E
Oh,
I
mean
we
can,
we
can
aim
for.
E
B
Okay
right,
okay,
so
I
think
that's
all
for
the
presentation
now
brown
should
we
go
to.
Oh,
you
want
to
say
something.
C
A
Two
of
those
so
just
get
a
brief
status
update
on
each
of
those.
B
Yeah,
so
I
I
see
those,
do
you
see
my
screen.
B
Okay,
so
the
the
two
documents
very
we're
mentioning,
I
guess-
is
the
event
pub
and
the
alarm,
and
so
the
reason
they
have
been.
F
F
B
Okay,
so
so,
basically
end
of
june,
we
we
received
a
feedback
from
the
rfc
editor
for
the
auth
48
and
it
has
been
responded.
I
think
now
they're
waiting.
Oh,
it's
not
what
I
expected,
but
they
are
waiting
for
the
80
to
validate
those.
B
So
here
we
do
have
so
that's
the
event
and
if
I'm
clicking
here
so
I
think
that
francesca
it's
on
the
end
of
francesca
and
I
think
for
the
other
one.
It's
the
same.
So
that's
the
v
alarm.
B
It's
everything
has
been
done
by
the
co-author,
so.
G
Yeah
regarding
the
alarm
extensions
that
is
pretty
much
ready
to
walk
out
the
door.
There
was
a
discussion
about
some
ayanna
language
and
whether
we
want
to
mention
rfc8126
and
that
I'm
fine,
either
way,
barry
seems
to
think
the
language
as
it
is,
is
fine,
but
obviously
he's
just
a
participant.
Now
he's
no
longer
the
ad,
so
francesca
said
she
would
look
at
it
next
week,
so
hopefully
it'll
be
out
soon.
B
Yeah,
so
here
we're
good
now,
considering
that
we
have
draft
that
are
missing,
I
mean
the
task
and
the
relation
one
I'm
wondering
do
we
want
to
go
to
the
milestone.
C
B
So
when
do
we
do
do
we
want
to?
Can
we
expect
that
to
be
done
by
the
end
of
the
year?
A
A
D
Mute
on
my
volume-
yes,
I
I
agree
and
push
it
into
next
year.
Right,
there's
other
things
that
really
need
to
be
done
before
that
so
march.
Probably
good.
D
D
Let's
say
september,
I
think
that
one
we'd
like
to
get
through
faster
because,
let's
see
because
of
the
tie
into.
B
A
B
A
Draft
to
isg,
and
then
you
can
type
in
the
drafts
section
to
find
it.
B
A
So
yeah
maybe
change
the
title
to
submit
tasks.
Draft
yeah,
yeah.
G
That's
a
good
question
mike
I
haven't
heard
back
from
apple
as
to
what
they're
doing
so.
I
guess
we'll
just
keep
kicking
that
can
down
the
road.
B
B
Oh,
we
can't
submit
earlier
yes,
so
this
one.
We
aim
for
december
v,
pool.
B
D
B
Yeah
yeah
so
looks
good,
so
we
have
december
the
upgrade
the
task.
B
Which
is
the
one
we're
missing?
The
relationship.
D
A
I
think,
let's
just
remove
that
document
entirely.
Actually
looking
at
it,
there's
there's
really
no
points,
so
that
does
my
draft.
If
I
do
something
like
that,
I
think
it'll
just
be
a
extend.
The
the
schedule
reply,
false
header,
to
apply
to
everything.
A
And
yeah
just
just
delete
it,
I've
let
the
document
expire,
I
think
we'll
just
let
that
one
die.