►
From YouTube: IETF110-CALEXT-20210310-1430
Description
CALEXT meeting session at IETF110
2021/03/10 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
All
right,
according
to
the
clock,
it
is
time
so
welcome
everybody
to
calex
in
prague
virtually
so,
of
course,
we
always
start
with
the
noteworld,
which
I
imagine
everyone
here
has
read
by
now,
but
this
is
basically
the
instructions
to
behave
yourself
and
to
tell
us
if
you
know
of
anything,
any
intellectual
property
that
affects
this
work
and
otherwise
be
nice
to
each
other.
A
We're
good
at
that
already.
This
is
the
rough
agenda
that
I've
put
forward
for
the
hour
that
we
have,
so
I
don't
know
how
accurate
it
will
stick
to
these
timings.
There's
no
particular
need
to
stick
accurately
to
this
timings,
better
off
just
spending
the
time
on
what
we
want
to
spend
the
time
on.
Does
anybody
have
any
agenda
bashing
before
we
get
into
it
anything
else,
you
want
to
discuss.
D
Well
sure
I'll
say
thank
you
all
for
the
work
you've
done
and
for
the
support
you've.
Given
me
as
a.d
and
I'm
happy
to
turn
over
the
a.d
job
to
francesca
for
this
working
group,
I
think
you'll
enjoy
working
with
francesca.
C
A
All
right,
let's,
let's
dig
straight
in
then
js
calendar
there,
it's
in
aust
48
at
the
moment
the
mapping
document's
still
being
worked
on
and
there
are
specific
slides.
So
I'm
going
to
switch
to
those
now.
E
You
go
ahead,
I'll
just
jump.
I
need
okay
to
okay,
so
js
calendar
we're
talking
about
two
rfcs
here.
One
is
the
core
document:
the
cad
exchange
calendar,
the
next,
the
other
one
is
the
chase
calendar
I
calendar,
which
is
concerned
with
defining
how
to
map
between
icon
and
the
ngs
calendar
next
slide.
Please.
E
So
for
js
calendar
djs
calendar
document,
yes,
brown
said
we
are
in
oath
48.
We
got
ice
iesg
review,
so
we
are
as
good
as
done
for
the
jsk
and
I
calendar
document
we
are
in
a
more
early
stage.
E
We
made
sure
that
that
can-
and
I
cover
the
I
calendar-
to
js
calendar
mapping
before
this
session,
because
we
came
to
the
conclusion
that
this
is
having
a
clean
mapping
from
I
calendar
to
js
calendar
is
is
important
to
us
for
giving
js
calendar
the
final
goal
and
we
reached
consensus
on
almost
all
points
already,
but
there
are
two
points
that
are
still
open,
and
so
we
want
to
squash
them
now,
as
as
fast
as
possible.
E
Yeah
for
the
other
direction
for
js
can
do
I
clean
them.
I
think
this
will
take
considerably
longer-
I
guess
at
least
half
a
year
so
we'll
have
to
define
new.
I
calendar
properties
and
this
is
going
to
be
more
work,
but
for
now
the
other,
the
mapping
from
icalendar
is
more
important
to
us
next
slide.
E
E
So
it
says,
sharing
events,
it's
really
about
scheduling.
This
is
one
of
the
two
points
that
where
I
have
the
feeling
we
do
not
have
consensus
reached
for
js
calendar
and
I
think
we
should
and
then
whatever
decision
we
we
come
up
with
now
should
be
the
final
goal
for
js
calendar.
E
The
thing
is,
while
working
on
the
icon
and
the
js
calendar
document,
we
we
came
to
realize
that
there
is
not
necessarily
a
clean
mapping
between
I
calendar.
E
The
way
I
can
the
attendees
are
defined
in
js
calendar
in
js
calendar.
A
participant
can
have
multiple
methods
to
reach
the
participant
for
scheduling
requests,
whereas
in
in
in
I
calendar
you
have
you
have
one
calendar
user
address,
which
is
the
value
of
the
property
and
then
optionally,
an
email
parameter
that
apple
introduced
a
couple
of
a
while
ago,
because
they
are
using
calendar,
addresses
user
addresses
that
are
not.
E
Usable
for
imit
internally-
and
we
now
have
the
the
the
the
thing
that
that
we
can't
clearly
map
between
these
two
formats,
because
if
we,
if
we
map
an
I
calendar
to
a
js
calendar
and
then
someone
changes
the
sent
to
method
entries,
probably
having
them
giving
them
more
than
one
entry,
we
won't
be
able
to
identify
which
one
to
use
as
the
calendar
user
address.
In
I
canada.
This
is
the
one
issue.
The
other
issue
is
that
in
I
calendar
the
can.
E
The
user
address
is
used
to
to
cross-reference
between
attendees,
for
example.
If
you
have
delegates
in
cheers
calendar,
we
have
this.
E
We
are
using
participant
ids
to
do
this,
which
basically,
where
we
can
basically
achieve
the
same,
but
it
will
require
us
to
include,
for
example,
multiple
participants
in
when
we
send
an
itip
response
with
jscanda,
because
and
this
this
again
is
a
difference
to
I
calendar,
because
in
I
calendar,
if
you
reply
as
an
attendee,
you
only
allow
to
have
exactly
one
attendee
in
the
itip
response
in
js
calendar.
E
We
just
include
to
to
have
a
clean
mapping
to
the
delegates,
for
example,
and
so
we
think
we
should
address
this,
and
one
of
the
options
that
we
came
up
with
was
to
define
calendar
user
address
property
in
js
calendar
which,
uniquely,
which
has
a
clean
bi-directional
mapping
between
the
iq
and
the
property
value
of
an
attendee
organizer
and
the
js
calendar
participant,
but
that's
one,
but
not
necessarily
the
only
solution
to
these
two
gaps
that
we
identified.
E
So
we
are
wondering
probably
me
you
have
thoughts
on
this.
I
saw
on
the
mailing
list.
Probably
someone
else
might
share
their
opinions.
F
F
We
could
add
a
uid
property
if
we
want
to
be
able
to
have
these
the
dangly
references
essentially
be
able
to
say
it's
delegated
from
this
person.
We're
not
going
to
tell
you
anything
about
this
person
in
this.
F
If
you
know,
if
you
know
who
that
your
id
results
do
that,
you
might
know
who
it
was
delegated
from.
That's
I'm
not
any
particularly
huge
fan
of
that
anyway,
because
I
think
it's
weird
but
yeah
we
could
have
some
kind
of
uid
roughly
and
then
we
map
that
in
some
way,
but
otherwise
I
said,
I
think
the
send
two
does
map.
F
E
E
So
if
that
would
be
the
only
send
to
value,
then
basically,
but
there
would
be
an
email
parameter
property.
Then
we
would
have
two
entries
in
the
same
two,
one
yeah.
B
F
B
B
B
F
B
What
he
said
was
a
bug
was
the
format
of
the
of
the
current
user
address,
because
it's
not
a
it's,
not
actually
a
valid
uri.
It's
missing
the
scheme,
but
the
point.
The
point
is
that
what
was
sent
to
me
using
my
my
thunderbird
client
was
an
event
with
a
currently
user
address.
It
was
a
in
parentheses,
invalid
uri,
that's
not
a
mail
to,
and
he
used
the
email
parameter
value
as
the
destination
of
the
of
the
imit
message.
B
There
was
no.
There
was
no
attendee
in
there
that
that
referenced
me
with
a
counter
user
address
of
only
of
a
mail
to
so
apple's
practice
at
the
moment
is
to
send
you
something
where
the
email
parameter
is
the
actual
imip
address
you're
using,
and
I
don't.
F
F
B
B
There
was
a
lot
of
of
pushback
from
other
people
saying.
Why
have
you
suddenly
switched
to
using
this
email
parameter
and
and
given
us
a
value
that
we
can't
use
and-
and
it
was
more
of
a
reaction
from
will
freighter,
but
that
that
was
the
basically
thing
was
well
that's
the
way
it
has
to
be,
and-
and
they
explained
why
sort
of,
but
it
wasn't
something
that
just
escaped
into
the
wild-
it's
what
they
did
and
we
had
to
follow.
A
B
F
A
F
B
The
open
source
no
longer
is
no
longer,
in
fact
they
completely
written
internally.
I
think
they
so
no
that
that
that
example
was
generated
at
the
time
I
sent
the
message.
B
F
Yeah
I
mean
try
to
make
compatibility
with
something.
That's
not
following
existing
specs
is
always
fun,
but
okay.
We
can
try
and
find
more
examples
of
that
and
see
what's
going
on
and.
H
F
F
F
B
Is
that
right,
I
I
no
no,
I
exported.
I
sent
it
to
myself
via
an
email
address,
because
the
one
of
the
problems
I've
always
had
with
with
looking
at
at
the
the
internal
form
of
apple's
events
is
there's
no
easy
export
from
from
ical.
So
what
I
do
is
I
use
all
my
other
email
addresses
as
a
as
an
attendee,
so
I
sent
it
to
one
of
my
other
email
addresses
and
that
and
then
I
picked
that
up
from
thunderbird
so
yeah
it's
going,
I'm
it.
B
Also,
I
also
said
I
want
to
to
to
ken
around
the
same
time,
because
there
was,
I
was
trying
to
to
verify
that
this
invalid
urn
value
that
they
were
using
you,
the
in
the
in
the
county
user
address
actually
was
what
they
were
sending.
E
By
the
way,
I
now
also
recall
that
actually
the
the
email
parameter
was
what
was
not
necessarily
should
be
used
for
for
imip.
I
got
that
wrong
before,
but
nevertheless,
and
even
irrespective,
I
think
of
of
the
specific
apple
example,
we
want
the
js
calendar
icon
and
the
rfc
to
be
a
standard,
and
we
wanted
it,
and
it's
so
important
to
get
scheduling
right
in
both
formats
to
interrupt
that,
we
need
to
define
a
standard
way
how
a
participant
should
map
to
an
attendee,
including
their
property
value.
E
At
the
moment,
we
have
two
entries
in
the
in
the
send
to
we
don't
want
clients
to
come
up
with
different
different
mappings,
because
then
it
breaks
all
apart
as
long
as
I
calendar
is
still
is
still
around
it.
I
guess
it
will
be
for
a
long
time
yeah.
So
so
we
need.
We
need
to
define
some
standard
mapping
and.
F
I
think
that's
that's
straightforward!
If
there's
an
imp
value
use
that
one
as
the
the
calendar
value
in
in
our
calendar,
because
that's
likely
to
be
the
one
they
understand,
if
not
pick
any
one,
because
no
one's
gonna
understand
anything
else
like
you,
you
can't
you
can't
end
up
with
this
from
going
from
my
calendar
to
just
calendar,
so
you're,
starting
from
a
richard
just
calendar
one
and
coming
back.
Yes,.
F
E
Yeah
and
if
everyone
agrees,
that's
that's
the
same
decision
assuming
that
there
is
at
least
one
mailto
uri
in
the
send
to,
of
course,
or
one
eyelid
method.
I'm
just
saying
that
if
we
would
have
a
specific
one,
specific
property
b
that
uid
apparently
use
address
or
whatever
it
would
be
totally
clear
which
one
to
use.
B
B
Oh,
can
I
just
raise
a
quick
point
here
about
whether
this
should
be
appearing
or
not
appearing
cyrus.
In
his
in
his
first
message
about
the
email
parameter
says
the
server
actually
does
write
the
email
parameter.
He
actually
implies
that
this
goes
out
and
the
in
the
message
that's
sent
out.
Yeah
the.
B
A
This
is
an
email
that
I
just
sent
myself
from
icloud
right
now:
logging
into
the
icloud
web
interface
and
sending
it-
and
you
can
see
that
the
attendee
has
a
slash
ss.
Not
you
proper
uri
and
the
organizer
has
a
mail
to
address
at
imep.me.com
with
a
matching.
Yes,.
F
A
Mail
to
address,
and
then
the
attendee
is
me,
so
I
see
rubbish
in
like
non-understandable
things
in
these
other
fields,
but
the
only
ones
that
I
need
to
care
about
are
the
attendee.
That
is
me
and
the.
F
Organizer
yeah,
so
apart
from
the
fact
that
those
were
both
mapped
to
a
single
ascend
to
with
a
single
component
in
the
organizer's
case,
it
would
be
a
imip
male
2
and
in
the
attendee
case
it
would
be
an
other
here's,
a
uri.
We
don't
know
how
you
would
without
to
this.
F
E
Okay.
So,
but
if
you
add
an
imid
now
to
the
gs
participant,
we
would
convert
it
back
to
an
icon,
the
attendee,
with
a
different
value
than
the
one
with
the
rubbish,
and
I.
A
B
A
F
Yes,
so
you're
always
mapping
the
value
to
the
calendar,
address
value
to
the
send
to
property,
and
if
it's
a
male
2
uri,
then
we
presume
that's
an
imip
and
so
that
maps
the
iomit
and
if
it's
just
random
other
uri,
then
it
maps
just
to
other
as
the
the
type
in
in
the
center.
Because
you
know
there
is
no
way.
You
know
how
to
reach
that.
It's
essentially
in
a
page.
F
Well,
if
they're
sending
back
js
calendar,
they
could,
but
that,
like,
I,
I
think,
saying
I
tip
with
js
calendars-
is:
is
too
broad
thing,
it's
there's
kind
of
two
different
scenarios
here
you
you
could
be
just
doing
it
with
I
calendar,
which
is,
is
more
likely
and
you're
doing
js
calendar
translation
just
from
the
server
down
to
to
to
a
client.
That's.
E
F
Yeah,
there's
a
there's
an
upgrade
goal
here
and
the
whole
point
of
the
multi
of
century
being
multi-value
is
being
able
to
one
of
the
ways
of
being
able
to
get
us
past
just
having
imip
everywhere
and
and
be
able
to
get
something
a
bit
better.
B
B
F
We're
eating
a
lot
a
lot
of
time
here,
and
this
might
be
better
done
on
main
list
where
we
can
like
write
in
more
detail
rather,
okay,
here
they
but
yeah,
I
mean
okay.
I
I
I
going
back
to
the
original
question
on
this.
I
stick
by.
I
think
there
is
a
good
translation.
We
don't
need
to
add
an
extra
property.
E
B
Just
a
quick,
quick
point
about
this
that
was
touched
on
is
the
the
values
of
the
delegated
two
from
sent
by.
G
B
All
the
rest,
the
sent
by
actually
was
one
of
the
things
which
triggered
me
off
into
doing
this,
because
on
our
spam
calls,
we've
been
talking
about
these
scenarios
that
have
occurred
with
people
who
send
stuff
on
behalf
of
somebody
else
and
and
they're
doing
that
in
in
a
an
environment
where
they
have
multiple
email
domains,
because
it
was
a
merged
company
and
and
then,
of
course,
you
factor
in
dkim
and
everything
goes
to
hell
and
so
send
by
became
a
a
real
issue.
B
So
we
need
to
ensure
that
those
parameters,
work
and,
I
think,
sent
by
you,
know
having
a
participant
id-
is
actually
a
more
complicated
way
of
dealing
with
it.
If
we
can
fix
on
what
actually
the
calendar
user
address
is,
then
that
could
be
the
value
that's
sent
by
as
it
is
in
I
calendar
and
you
don't
need
to
add
extra
participants
to.
F
F
B
Well,
yeah
it,
but
it
sort
of
has
the
same
issues
as
delegated
to
and
from
you.
You
delegate,
two,
you
delegate
to
an
imip.
You
know
an
email
address,
a
mail
to
and
at
some
future
point
the
that.
That
message
appears
with
that
with
an
attendee
with
a
delegated
from
and
a
an
a
and
a
a
and
a
mail
to
value.
A
A
E
Yeah,
but
it
this
is
the
only
other,
interesting
thing
so
as
for
mapping
between
jsk
and
the
icon
of
attendees,
we
also
found
a
few
gaps
for
recurring
events.
One
is
with
our
r
dates
where
in
icon
and
it's
clear
that
an
rdate
is
an
r
date
in
addition
to
whatever
the
artworks
are
producing
in
js
canada.
It
is
not
so
this
might
come
into
play
when
changing
the
r
rule.
E
Firstly,
because
if
you
change
the
recurrence
rule,
you
will
have
to
figure
out
if
the
what
state
is
in
order
and
what
really
could
go
into
the
recurrence
rule.
But
it
also
means
that
if
the
intention
was
of
an
rdate
regardless
of
the
recurrency
word,
you
have
to
figure
out.
We
can't
currently
tell
if
we
should
preserve
these
as
our
dates
when
in
our
routine.
F
This
is,
I
mean
you'll
change
the
overall,
that's
just
from
the
client
to
deal
with.
No,
I
don't
think,
there's
an
issue.
I
mean
two
things
here.
Firstly,
our
date
could
coincide
with
the
recurrence
rule
already
in
icalendar.
There's
nothing
that
says
it
has
to
be
a
date
that
doesn't
get
generated
by
the
rule
yeah
and
the
the
but
the
other.
A
H
D
A
F
A
Yes,
but
I
guess
the
the
idea
is,
if
you
create
a
blank
date,
so
it's
a
recurrence
that
has
nothing
but
there's
something
happening
at
this
date.
Then
does
that
get
retained
when
you
change
the
rule-
and
I
think
the
answer
is
yes,
you
always
retain
them.
A
E
And
the
other
thing
I
think
this
was
already
discussed
on
the
on
the
mailing
list.
It's
about
standalone
events.
I
saw
a
standalone
recurrence.
E
Of
an
event
on
the
previous
slide,
so
the
question
was
there
that,
with
the
standalone
standard,
no
recurrence
instance,
you
don't
know
the
time
zone
of
the
of
the
main
event,
which
means
you
also
don't
have
the
for.
I
calendar
the
necessary
time
zone,
the
boss
of
the
main
event
and
which
makes
up
the
complete
value
of
the
recurrence
id
in
I
calendar.
E
So
the
thought
was
that
to
add
a
recurrence
id
time
zone
property
which
only
is
allowed
to
be
set
if
the
event
has
a
recurrence
id.
So
if
it's,
if
it's
really
a
recurrence
instance
yeah.
F
Yeah,
I
I
think
we
could
do
this.
I
think
the
property
should
be
defined
in
the
icon
of
js
kind
of
the
translation
document,
because
the
only
time
you
would
use
it
is
when
translating
I
calendar
into
js
calendar
to
ensure
that
can
be
round
tripped.
If
you.
B
B
B
We
can't
just
treat
it
as
an
opaque
object,
so
to
convert
it
correctly
and
use
it
correctly.
We
have
to
have
its
time
zone
that
that
was
the
point
where,
where
things,
and
so
even
if
you
don't
have
the
master
event,
you
don't
you
have
no
idea
whether
the
what
what
the
real
time
of
that
recurrence
id
is.
B
So
you
can't
do
things
like
check
to
see
whether
this
falls
inside
the
time
range,
even
though
the
thing
has
been
overridden,
so
it's
outside
the
time
range,
which
is
part
of
of
the
searches
we
do
that's.
That
was
the
issue,
and
I
I
think
we
should
just
have
this
and
we
put
in
there
every
time
you
have
a
standalone
override
instance
of
an
event.
You
add
a
recurrence
id.
You
know
time
zone
to
it,
it's
simple
and
it
it
allows
us
to
do
what
we're
doing
now.
B
A
C
So
maybe
I
missed
the
problem,
but
do
we
have
a
time
zone
into
the
into
any
single
occurrence,
or
is
that
not
specified
yet.
B
B
Time
things
there
values
as
dt
star
dt
ends,
but
the
recurrence
ids
are
time
zone
time
time
yeah
at
a
real
time,
and
when
you
do
time
range
searches,
you
you're
actually
searching
for
recurrence
ids
as
well
as
all
the
dt
starts
and
things
because
the
the
what
where
the
problem
occurs
here
is,
you
might
have,
you
might
be
invited
to
a
single
instance
of
of
a
an
event
and
the
recur
and
that
the
time
zone
of
that
instance
might
have
been
shifted
so
that
you
know
you
express
the
dt
start
in
it.
B
You
know
you
say
you
got
a
meetings
in
in
new
york
and
you're
using
american
new
york
as
your
time
zone
for
the
master
event,
and
then
oh
we'll
have
one
meeting
in
london
and
you
change
the
time
zones
and
the
dt
start,
but
you
can't
without
in
I
calendar
you
can
you
you
have
the
time
zone
as
explicitly
set
on
the
recurrence
id.
So
you
don't
that's,
not
a
problem
in
js
calendar
there
isn't
a
an
explicit
time
zone
id
for
the
recurrence
id.
B
E
F
The
yeah,
I
guess
my
why
I'm
a
bit
puzzled
is
you.
You
said
you
want
the
time
zone
for
date
for
querying,
but
if
you
aren't
invited
to
the
master
you're
only
inviting
this
recurrence
id.
Why
I
I
would
wouldn't
expect
the
query
to
look
at
the
time
range
queries.
Look
at
the
recurrence
id
at
all.
Just
look
at
the
start
times
of
the
particular
instances.
B
Do
you
do
queries
on
these
things
to
see
whether
an
instance
of
the
event
has
been
moved
outside
of
the
time?
Maybe
you're
saying
what
meetings
have
I
got
this
week
and
then
yeah.
B
B
A
A
G
Yeah
not
much
to
say
about
this
real,
quick
next
slider,
let's
go
through
the
changes.
Since
the
last
itf,
we
found
out
that
the
alternate
extensible
quote:
extensible
syntax
for
defining
the
alarms,
wasn't
quite
as
extensible
as
we
thought
so
that
was
fixed
following
the
changes
in
the
event
pub
spec,
we
had
removed
the
structure,
location
property
and
replaced
that
with
the
location
sub-component
for
proximity
alarms
and
due
to
some
confusion
during
the
iesg
reviews,
I
recognized
and
hopefully
clarified
the
process
of
snoozing
alarm
and
added
an
example
showing.
G
What
pro,
what
components
are
getting
added?
What
properties
are
being
changed?
After
all,
it
was
done.
It
is
now
in
the
rfc
editor
queue,
so
we
are
done
thanks
to
cyrus
for
writing
the
original
document,
thanks
to
all
the
con
contributions
from
everybody
in
the
group
here,
oh
and
and
thanks
to
barry
for
helping
me
get
two
revisions
posted
during
the
blackout
period
to
move
this
thing
along.
A
Awesome
all
right
next
slide
was
event
pub.
There's
questions
from
expert
review
and
a
discuss
from
ben
kerdick.
B
The
one
question
I
have
on
this
one
is
am
I
supposed
to
what
do
I
do
about
the
the
the
avian
f
for
one
thing,
because
the
tide
seems
to
have
shifted?
Do
I
put
it
back
to
the
5545
format?
Does
it
matter
and
do
I
and
should
I
resubmit
with
a
new.
B
B
And
what
about
the
abn
f?
Do
I
mean
what
be
somebody
who
uses
the
stuff?
I'm
not
too
concerned
whether
it
matches
the
5545
format,
I'm
more
concerned
that
it
that
it's
understandable
and
you
can.
D
Yeah
as
the
one
who
pushed
that
change
and
then
had
to
agree
that
this
isn't
the
right
time
to
do
the
change,
I'm
of
a
mixed
mind
on
this
document,
because
it's
a
pretty
small
amount
of
abnf.
So
if
you
want
to
leave
it
with
the
changed
version,
that's
fine
yeah.
D
On
the
other
hand,
the
only
calendar
related
one,
that's
different
from
the
five
five
four
five
syntax,
so
I
I'm
happy
either
way
like
I
said
I
was
the
one
who
pushed
the
change
and
I've
been
convinced
that
this
is
the
wrong
place
and
time
to
do
it.
So
your
judgment
on
this.
B
Let
me
take
a
look
again
and-
and
maybe
I
can
quickly
come
up
with
the
because
there
were
some
there
were
some
bugs
in
it
originally
anyway,
but
let
me
see
if
I
can
come
up
with
a
more
five
five,
four
five.
B
D
Believe
that
in
this
document,
that's
fine
because
it's
it's
not
a
lot
of
abnf,
but
when
we
tried
to
do
that
in
the
in
the
other
document
where
there
was
a
lot
more
abnf
involved,
it
just
got
out
of
hand
and
we
decided
it
was
a
bad
idea.
G
I
agree:
I
agree
that
the
the
new
abm
enough
is
certainly
preferable
but
having,
as
barry
said,
having
gone
through
this
with
vl
arms
I'll,
make
it
a
task
for
myself
to
look
what
you've
got
mike
and
make
sure
that
it
actually
does
what
we
think
it
does,
because
for
the
longest
time
we
thought
that
the
v
alarm,
syntax
that
cyrus
had
come
up
with,
was
actually
extensible
and
it
was
not
so
yeah
I'll
review.
What
you've
got
to
make
sure
it's
not
doing
something
strange.
A
A
Ago
was
question
was
twofold
and
particularly
clement's
equivalent.
We
should
mention
that
in
the
document
in
order
to
reassure
readers,
there
are
no
hidden
changes.
Have
we
validated
it's
already
equivalent
overarching
considerations?
We
shouldn't
put
false
statements
in
the
document
and
that's
the
that's
all
about
questions
that
was
a
referendum.
A
A
A
B
My
recollection
is,
I
think,
they're
partially
there,
so
maybe
it
would
just
make
sense
to
make
sure
they're
all
there.
This
would
be
easier
to
then
say,
and
it's
just
a
matter
of
adding
values,
essentially.
A
Cool
all
right,
so
what
do
we
want
to
do
for
this
mic?
Should
you
and
I
just
chat
about-
what's
involved
there?
Do
you
want
to
look
at
at
js
calendar?
Do
you
want
someone
else
to
look
at.
B
I'll
have
a
quick
look
at
js
calendar
and
see
where,
where
we
are
in
relation
to
that
and
yeah,
we
can
do
it
over
email,
cool.
B
I
did
add
them
to
ical
for
jay
at
least
my
my
version.
I
I
have,
and
I
I
I
once
it's
a
little
further
on
I'll
I'll,
try
to
get
that
into
the
then
ben
fortuna's
version.
A
F
C
A
C
A
All
right
server
side
subscriptions.
A
B
V-Pole,
I
think,
probably
still
stands
there
as
it
is
yeah.
I
am.
I
can't
remember
where
I,
whether
I
resubmitted.
B
Yes,
I
have,
I
have.
I
have
done
updates
with
participants
I'll
try
and
get
that
submitted
as
a
soon.
I
think
I
think
it's
just
waiting
to
go.
I
can
submit
that
fairly
quickly
and
and
I
have
updated
ical4j
for
the
the
the
new
form,
but
I
haven't
implemented
it
in
there
in
my
server
yeah.
I
don't
think
it
really.
A
C
Old,
I'm
wondering
regarding
gs
calendar
how
much
the
discussion
with
the
calendar
user
id
is
affecting
the
viewpole
calendar
section.
B
Only
as
much
as
as
it's
the
account
user
id
is,
that
is
the
target
for
the
way
you
send
stuff
vipol
uses
standard
itip
to
send
something.
Well,
he
uses
it
with
with
some
extensions
in
that
it
has
some
new
methods,
because
you
want
to
indicate
that
it's
a
a
response
to
a
you
know:
it's
a
new
vote
coming
in
also
that
kind.
So
there
are
a
few
new
methods
in
in
the
thing,
but
it's
basically
standardized
it.
So
yeah
everything.
D
B
Yes,
and-
and
I
think
at
the
other
point
brown
raised-
that
we-
this
will
probably
a
spec
that
will
have
a
js
calendar
section
added
to
it,
because
by
the
time
this
comes
out,
js
calendar
will
be
a
done
deal.
A
All
right
and
that's
all
that
I've
got
slides
for
the
rest
was
the
milestone,
review
and
other
business.
So
do
we
have
any
other
business?
Will
I
find
the
milestones.
A
I
guess
not
so
daniel
already
updated
this,
which
makes
me
think,
there's
probably
very
little
for
us
to
do
except
we
may
be
doing
I
calendar
series
later
and
submitting
subscription
update
and
relations
earlier,
they've
been
dumped
to
june
when
they're
going
to
happen
right
now
or
very
soon
from
now
scheduling
controls.
Yes,
that's
on
me
I'll
get
back
to
that.
I
didn't
even
want
to
talk
about
it
this
time
around.
A
H
B
Well,
we
do
have
the
thursday
where
we
could
shift.
We
have
some
calls
at
a
different
time.
A
A
A
D
A
All
right,
let's,
let's
do
an
interim-
I
guess
during
cal
connect,
then
we'll
find
find
the
time
that
works
best
for
everybody
and
and
put
a
calyx
to
interim
in
connect
again
and
then
we
can
can
cover
these
topics.
There.
A
Sounds
good
all
right
thanks
everybody,
let's
enjoy
our
five
extra
minutes.
Gran,
hello,.
A
G
I'll
just
say,
thanks
to
barry
for
all
his
his
work
over
the
last
few
years,.