►
From YouTube: IETF108-CALEXT-20200731-1300
Description
CALEXT meeting session at IETF108
2020/07/31 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
That
is
too,
I
mean
only
that
is
only
valuable
for
the
itf,
so.
B
B
Okay,
because
it's
it's
a
matter
of
having
the
applications,
the
the
data
moving
from
application
to
application,
but
I
think
the
standards
are
there
to
support
it.
A
So
yeah
that
would
be
my.
I
got
crazy
to
just
yeah.
B
I'll
talk
I'll
talk
with
people
about
whether
we
can
have
the
secretariat
handle
some
of
that
for
you,
so
at
least
so
that
because
they're
doing
a
number
of
steps
anyway.
So
if
they
do
the
linking
that
might
be
less
error-prone,
I'll
I'll
discuss
that
with
people
we'll
see
what
we
can
do.
A
So
we
so
welcome
to
the
calyx
interim.
Oh
no!
It's
not
an
interim
meeting
this
time.
It's
the
real
itf
meeting.
Please
have
a
look
at
the
not
wells.
I
guess
you're
pretty
much
familiar
to
those.
If
you're
not
take
the
time
to
read
those
and
if
you
have
any
questions,
just
come
back
to
your
chairs
or
your
80
and
we'll
be
happy
to
make
any
clarification.
A
My
my
feeling,
so
I
can
start
my
and
you
correct
me
if
you
want,
if
I'm
saying
something
wrong
or
if
you
want
to
add
something,
we're
essentially
pushing
for
the
gs
calendar
draft
now,
so
that's
where
our
focus
is
in
and
we
put
on
hold
all
the
other
draft.
That
requires
some
somehow
some
minor
steps,
two
wider
steps,
but
our
focus
is
to
throughout
the
gs
calendar
and
we
had
the
v
alarm.
That
is
almost
ready.
A
Barry
I
mean
braun
or
barry.
Do
you
want
to
add
something
or
do
you
have
something
to
say
for
the
working
group.
C
No,
I
was
just
dropping
in
to
say
that
that
seems
pretty
right
to
me.
Glancing
at
the
milestones
that
we
have
coming
up
that
also
fits
in
with
submitting
vlam
and
submitting
js
calendar
are
the
things
we're
expecting
to
do
now
and
the
next
things
are
all
set
for
december
2020
and
out
apart
from
the
scheduling
controls
document,
which
I
have
not
updated,
that's
that's
document.
C
D
Yeah
I
yeah
just
looking
here.
Neil
is
also
here,
so
please
jump
in
when,
when
you
think
so,
the
status
is
that
for
after
the
interim
meeting,
we
we
did
the
points
we
updated.
Based
on
the
points
discussed.
We
there
were
only
some
minor
tweaks
in
the
last
few
weeks,
which
didn't
do
any
further
semantic
changes
in
the
model.
D
I
don't
really
see
any
blocking
open
point
for
entering
last
call
and
then
all
the
focus
should
be
on
also
finalizing
the
mapping
document
where
mike
has
put
in
a
lot
of
effort.
Thankfully,.
E
Yeah,
I
just
wanted
to
just
briefly
mention
so
in
terms
of
so
following
the
interim
meeting,
we
added
things
that
were
discussed
there,
just
some
other
things
that
were
missing
from
previous.
I
calendar
that
people
wanted
compatibility.
E
So
just
some
brief
comments
on
those
the
schedule
force
send
property
on
participants,
that's
something
you
can
set
to
ask
the
server
to
send
an
item
message
again,
essentially,
even
though
it
normally
wouldn't
in
I
calendar,
that's
the
method
name
you
put,
but
given
there's
only
one
allowed
method,
name
in
any
particular
context.
I
just
made
that
a
boolean
of
true,
so
just
noting
that
if
anyone
objects,
please
speak
now
or
ever
hold
your
base.
E
E
I've
made
one
slight
difference
to
how
two
two
four
five
does
it,
so
these
were
deprecated
in
five
five,
four
five,
but
we've
put
them
back
in
again.
The
difference
is
what
how
it
combines
with
our
date,
which
would
be
kind
of
weird,
if
you
were
doing
this
anyway,
but
in
r2245
the
r
date
is
overridden
by
the
excluded
recurrence
rule.
So,
even
though
you
explicitly
said
it's
going
to
happen
on
this
day,
that
gets
cancelled.
E
I've
put
it
the
other
way
around,
because
one
of
the
explicit
goals
in
js
calendar
one
of
the
things
we
fixed
was.
E
You
can't
have
these
kind
of
orphaned
overrides
that
have
data
that
doesn't
actually
apply,
because
in
the
the
current
overrides
property
in
js
calendar,
it's
either
matches
the
recurrence
rule,
in
which
case
overrides
properties
or
it's
an
implicit
rdate.
So
it
causes
a
recurrence
then.
So
I
wanted
to
keep.
I
want
to
keep
that
property,
but
that
doesn't
mean
there's
a
slight
difference
to
two
two
four:
five,
because
in
just
calendar
it
goes
you
do
your
recurrence
rules
and
then
you
do
excluded
recurrence
rules
to
omit
that.
E
Then
you
are
dates.
Then
you
do
your
x
dates
essentially,
which
I
think
is
much
more
logical
ordering.
But
I
wanted
to
to
note
that
so
anyone
got
any
comments
on
that.
A
So
I'm
just
wondering
who
challenged
you
on
that
or.
E
Rules
which
were
way
back
in
two
four
four
five,
but
that's
a
deprecating
five,
five,
four
five
and
I'm
just
saying
that
adding
them
back
in
there's
a
slight
change
in
semantics,
because
the
original
version-
I
I
don't,
I
think
it's
poor
for
semantics.
I
really
wouldn't
want
to
have
that
in
js
calendar.
F
So
neil
this
is
ken.
I
I
think
what
you
did
make
sense
to
me.
In
fact,
given
that
our
date
is
additions
to
the
r
rule,
I'm
not
sure
how
an
ex
rule
would
match
in
our
date,
anyways.
E
F
Ex
rule
would
be,
it
would
be
subtracting
from
the
r
rule.
So
I
think
what
you
did
make
sense.
A
For
example,
if
we
are
updating
this,
do
we
have
a
gs
calendar
version,
one
version
two
or.
E
B
A
E
Like
generally
we've,
I
I
think
it's
better
to
define
different
properties.
Instead,
you
can
define
alternate
property
name
and
find
the
semantics
that
and
then
use
that
instead
and
then,
if
you
need
backwards
compatibility,
you
can
include
the
old
the
best
mapping
you
can
of
the
with
the
old
property
name
too.
A
D
A
What
is
an
uncle
to
me
is
so
if,
in
the
future,
we
have
some
of
those
minor
changes.
A
How
easy
it's
going
to
be
to
update
the
specification,
so
I
mean
that's,
what's
my
question
behind:
do
we
need
a
version
just
to
say
yeah
we're
using
version
blah,
so
we
are
taking
the
not
to
to
bring
to
to
keep
all
these
legacy
thanks.
C
E
Yeah,
I
I
think
you
you
have
the
app
type
property
which
you
could
always
change
that
to
something
different
if
you
really
wanted
to
signify
a
different
version,
so
instead
of
that
type
js
event,
you
know
type
js
event
2
or
whatever,
but
I
I
think,
that's
probably
a
last
resort.
I
think
a
better
approach
generally,
as
I
said,
is
to
change
the
semantics
through
defining
new
properties.
Either
they
replace
existing
ones
or
augment
them.
E
So
you
could
define
a
property
that
you
know,
let
you
define
exactly
what
order
you
interpret
x,
rules,
rules
and
other
stuff.
I
don't
think
we
do
this,
but
you
could,
if
you
wanted
to
change
that
semantics
later
and
then
clients
understood
that
property
would
be
able
to
look
at
it
and
use
that
for
interpreting.
Other
ones
would
just
ignore
it.
But
I
I
think
that
that
to
me
is
the
more
I
think,
extensible
model
that
it's
like
to
work.
E
D
So
I
I
am
ready
as
well
just
seen
the
discussion
on
the
classifier
on
the
description,
but
I
mean
this
is
a
discussion.
That's
been
going
in
circles
over
the
last
year,
so
yeah.
D
Yeah,
so
I
see
no
open
points
other
than
I'd
just
like
to
talk
with
you,
neil
shortly
later
on
on
the
about
the
time
zone,
property
name
so
that
we
are
consistent
there.
But
that's
I
mean
the
truth
is
a
few
minutes.
A
Okay
right,
so
I
think
we
are
still
in
working
group
last
call
what
I'm
wondering
is.
Should
we
start
a
new
working
group
last
call,
or
is
it
fine
to
to
keep
the
the
current
last
goal?
That's
maybe
something
I
have
to
discuss
with
with
brown.
D
Yeah
I
mean
what
I
don't
understand
the
the
process
of
what
what
would
be
the
difference.
H
A
Difference
with
right,
so
the
difference
would
be
either
we
could
still
consider.
We
are
still
in
the
same
working
group
last
goal
and
we
ended
up
that
when
everything
is
fixed
or
we
we
start
a
new
working
group
last
goal,
which
is
yeah
we've
made
during
the
last
working
group.
Last
call
we
made
a
few
fixes,
and
now
this
is
the
real
working
group
classical.
A
So
it's
it
doesn't
really
change
anything
given
that
it
just
I
mean
the
the
advantage
I
see
of
having
a
new
working
group
last
call
is
just
that
we
keep.
People
adds
up
that
now
I
mean
within
you
have
to
two
weeks
to
respond.
Otherwise
it's
going
to
be
shipped
while
now.
Maybe
some
people
are
not
very
aware
that
there
is
a
working
group,
lascal
ongoing,
so.
C
I
think
just
an
email
to
the
list
saying
we're
planning
to
ship
it
on
the
15th
of
august
or
something
like
that.
Okay,
please,
please
get
your
input
in
by
then
or
forever
hold
your
piece.
E
C
Well,
yes,
obviously,
that'll
start
almost
immediately,
but
I
mean
it's
still
going
to
go
through
all
the
itf
reviews
as
well.
So
there's
going
to
there's
going
to
be
more
stuff,
I
think
I
think
if
we
say
two
weeks
from
now
put
up
or
shut.
A
Up
that
should
be
fine,
just
wondering
what
I
mean
if
barry
has
an
opinion
on.
A
So
we
were
asking
should:
should
we
send
to
the
mailing
list
to
say
an
email
saying
yeah,
the
working
group
last
call
is
going
to
end
up
in
july
15.
So
if
you
have
any
comments,
just
provide
your
input
or
we
just
start
a
second
working
group
last
goal.
A
C
A
A
Then
we
have,
I
mean
a
bunch
of
slides,
but
I
think
I
don't
know
I
I
think
mike
put
most
of
those,
but
so
no,
I
calendar
series,
so
I
think
that's
mike,
but
he's
not
attending
the
meeting.
I
guess
oh
ken.
F
A
A
But
I
mean
to
me,
I
mean:
does
anyone
has
any
comments
to
say
regarding
or
or
this
draft
my
understanding
is
that
they're
still
waiting
a
smaller
changes
and
that
it's
going
to
be
updated?
The
reason
it
has
not
been
updated
now
is
just
that
we
were
focused
on
js
calendar.
A
I
calculations
that
yeah,
so
this
draft
was
somehow
a
little
bit
forgotten.
F
I
did
a
little
bit
of
digging
on
one
of
our
our
calls
on
this
one.
This
appears
to
have
gone
through
working
group
last
call,
and
I
think
braun
was
going
to
move
this
forward
back
in
november
as
as
a
part
of
a
bigger
batch
of
things.
He
did.
I
think
this
one
just
got
missed.
C
Yeah,
but
do
we
agree,
bro
yeah,
I
was
just
gonna,
say
ken
just
just
press
the
button
that
turns
your
audio
straight
on,
rather
than
asking
to
come
in
the
queue
I
reckon
with
a
group,
this
small,
it's
easy
just
to
hop
into.
B
C
Yes,
yeah,
I
I
haven't
been
pushing
on
that
because
I
didn't
want
to
distract
mike
from
getting
js
calendar
out
the
door,
but
it
should
be
easy
enough
just
to
do
this.
One.
F
B
C
A
Okay,
but
but
the
draft
I
mean
I
mean
we
had
consensus
on
that,
so
yeah
yeah,
that's
part.
I
I
I
suppose
this
one
one
is
also
from
with
the
minor
updates
that
just
need
to
be
fixed
before
moving
to
working
group
last
classical-
and
this
one
was,
I
don't
know,
robert
o'neill,
oh
brown,
you
want
to
say
something
on
jesus
calendar
like
calendar
robert
probably
knows
more
than
I
do.
Okay,.
D
D
So
what
I
gather
from
this
is
that
also
this
document
is
quite
matured
now
and
it
should
most
likely
be
done.
Soonishly
after
the
gs
calendar
spec
is
rubber,
stamped.
A
Okay,
so
that's
good,
because
I
was
a
little
bit
afraid
after
the
last
interim
meeting
that
it's
gonna
last
forever
but
yeah.
If
we
could
move
that
on
it's
a
it's.
It's
really
great.
A
D
A
D
No
it's,
it
should
be
timely.
Finalized
as
as
soon
as
the
js
calendar
data
model
is,
is
finalized.
C
All
right
I'll
put
an
action
for
myself
on
that
as
well
to
to
make
sure
there's
a
milestone
for
it.
F
In
in
regards
to
the
url
I
know,
mike's
concern
is
that
he
wants
to
make
sure
that
that
is
round-trippable
from
icalendar
to
js
calendar
and
back.
I
think
the
concern
is
that
if
the
url
property
just
becomes
a
link
in
js
calendar
and
there's
multiple
links
from
you
know,
whatever
they
might
be
locations
or
something
else,
how
do
you
know
which
one
of
those
links
goes
back
to
the
url
property,
and
I
calendar.
A
So,
okay,
that's
good!
I
think
we've
been
through
all
the
draft
yeah.
Do
you
want
to
say
something
can
on
the
v
alarm
or.
F
There's
not
much
there.
I
upload
a
new
draft
based
on
your
review
daniel,
thank
you
for
that
and
assuming
that
you're
happy
with
what
I
submitted,
and
I
addressed
all
your
your
comments.
I
think
we're
ready
to
move
forward.
A
C
It
might
be
four
actually
because
the
js
calendar
mapping
the
icalendar
relations
vlm
and
js
calendar
itself.
A
Okay,
so
I
don't
think
we
have
anything
else
to
to
add
unless
someone
wants
to
say
something.
A
And
I
also
believe
that
we
we
had
significant
reviews
on
the
document,
which
is
also
something
that
is
good,
so
I'm
pretty
happy
braun.
C
C
Shorter,
I
expect
we
will
do
probably
another
interim
at
some
point
once
the
js
calendar
documents
are
done
to
to
then
look
at
the
other
documents,
possibly
at
a
time,
that's
more
suitable
for
everybody,
yeah
yeah.
So
I'm
sorry
here
you
go
yeah
go
ahead.
C
C
Jazz
calendar,
we
find
scheduling,
controls
I
need
to
fix
up,
but
that
that
should
be
fine.
I
think
it's
going
to
become
a
very
short
draft.
It's
about
five
lines
long,
and
that
will
say
just
makes
the
schedule
reply.
Header,
which
is
already
defined,
also
apply
to
things
which
are
not
replies.
I
think,
rather
than
defining
additional
headers
and
all
the
other
stuff,
it
will
just
be
schedule.
C
Reply
means
don't
send
any
scheduling
messages
regardless,
because,
if
you're
going
to
add
a
new,
if
you're
going
to
add
server
side
support,
you
won't
be
able
to
detect
whether
it's
there
anyway.
So
why
not
just
use
the
header
that
that's
already
defined
so
that'll
become
a
very
short
document,
and,
apart
from
that,
we
we're
going
to
add
the
js
calendar
mapping,
which
I
think
will
be
september,
probably
give
it
give
a
bit
of
time
after
that
and
the
other
things
still
seem
fine
to.
C
A
And
yeah,
so
thank
you,
everyone
for
attending
the
meeting.
I
think
we
can
adjourn
that
meeting.
I
will
probably
hang
out
in
gather
the
town
for
some
time,
so
I'm
happy
to
be
being
there
and
but
I
would
say
see
you
see
you
in
the
next
interim
meeting.
That
is
to
be
seen
to
be
plain
awesome.
Thank
you.