►
From YouTube: IETF104-CALEXT-20190325-1120
Description
CALEXT meeting session at IETF104
2019/03/25 1120
https://datatracker.ietf.org/meeting/104/proceedings/
B
B
Excellent
all
right
welcome
to
calyx
time
bran
I'm
your
new
chair,
but
you
already
know
that
and
you're
who's
been
doing
it
for
a
while.
Now
here
is
the
note:
well,
we've
all
seen
this
document
very
many
times.
Everything
happens
in
here
doesn't
just
stays
in
here.
This
is
the
agenda
that
I
put
together
the
other
day.
Sorry,
it
is
small
and
hard
to
read
any
agenda
bashing
at
this
point.
C
This
is
Barry
liebe,
no,
no
agenda
bashing,
but
just
a
quick
note
since
Alexa
has
got
his
said,
this
buried
in
his
laptop
right
now
that
we
have
reshift
at
the
working
groups
now
that
I'm
the
new
ad
and
alexei
has
passed
this
one
on
to
me.
So
I
will
be
the
responsible
ad
for
calyx
and
I
also
wanted
to
call
out
Michael.
Who
is
here
for
the
first
time
in
person
we've
seen
his
name
on
the
mailing
lists.
Michael
slusarz
is
actually
we
know
his
face
now.
Hi.
D
E
D
B
B
This
has
had
a
recent
update
drafted
sitting
in
the
queue
for
Alexia
to
deal
with
it's
a
horrible
abuse
of
HTTP,
but
it's
already
in
the
field,
so
we
were
talking
about
publishing.
What's
there
as
informational,
so
at
least
people
can
understand
what
the
Apple
clients
and
servers
are
doing
right
now,.
F
Yeah
I'm
not
going
to
recap
the
whole
history
of
it,
but
I
think
the
last
time
I
looked
at
it.
There
was
things
that
potentially
required
double
checking
with
HTTP
this
working
group.
Even
so,
we
downgraded
the
document
from
proposed
standard
to
informational,
but
it
was
still
using
content.
Disposition
on
responses
which
apparently
wasn't
defined
for
requests,
was
only
defined
for
quests,
so
I
need
to
double
check
where.
F
F
E
F
H
H
F
I
B
F
Would
ask
the
question
of
what
do
you
think
is
the
best
thing
for
this
particular
element
to
do?
Is
it
sufficient,
as
far
as
Julian
is
concerned,
to
just
mention
it
as
a
special
case?
I
mean
I've.
Ideally
it
probably
worth
registering
it
properly,
but
I
understand
it's
going
to
be
probably
a
separate
document
and
exit
delay,
but
also
trying
to
figure
out
what
Julian
thinks
is
the
right
thing,
whether
we
agree
or
disagree,
you
probably
would
be
a
good
idea.
D
H
F
F
F
D
F
D
F
C
Yeah,
so
that
brings
up
the
question
Alexey
what
we
do
with
the
transition
from
you
to
me.
I
certainly
would
like,
given
that
the
attachments
has
been
held
up
for
over
a
year
and
is
through
iesg
evaluation.
I
would
like
you
to
finish
up
with
that,
but
the
this
one
hasn't
gone
to
ia
SGA
hasn't
gone
to
last
call
yet
so
perhaps
once
you're
finished,
when,
when
you're
satisfied
with
your
ad
evaluation
pass
it
on
to
me
and
I'll,
take
it
from
there
because
I
mean
if
you
want
to
keep
with
the
document.
That's
okay!
C
J
Okay,
I'm
a
my
own,
yes,
okay,
so
hey
everybody,
given
that
the
majority
of
the
audience
seems
to
know
about
Gia's
calendar
already,
I'm
gonna
skip
the
introductory
part.
So
let's
please
jump
to
slide
number
three
status,
so
we
we
had
entered
last
call
with
version
10
about
quarter
ago.
If
I
recall
correctly.
J
Since
then,
we
had
received
substantial
feedback
and
changed
quite
some
parts
of
the
specification
we
are
now
at
version
twelfth,
and
we
are
we
now
it's
it's
now
stabilizing
very
much
and
we
would
like
to
further
discussed
and
if
to
enter
a
lot
of
colic
and
all
what's
the
next
step
coming
shortly
to
to
some
of
the
changes
on
slide
number
four.
We
there
shouldn't
be
many
surprises
in
first
glance,
glance.
J
What
has
changed
is
that
for
time
zones
we
now
also
define
allowed
to
define
custom
time
zones
to
be
embedded
in
the
chase
calendar
object
that
has
been
requested
by
a
couple
of
people
to
stay
backwards
compatible
with
their
existing
data.
So
there
is
now
full
support
for
what
you
can
basically
put
into
a
V
time
zone.
Chia's
calendar.
J
J
J
B
J
J
D
E
B
The
some
of
them
were
renaming
fields,
so
they
make
more
sense
in
isolation.
Things
like
parts,
debt,
for
example.
You
have
to
go
back
every
time
and
understand
what
that
means
from
the
RFC.
Everyone
who
discovers
that
newly
doesn't
understand
so
that
got
fully
spelled
out
as
participation
status,
they're
a
bunch
of
things
like
that,
where
we
we
looked
at
the
naming
and
said,
does
this
make
sense
in
isolation?
Let's
choose
names
that
that
make
sense
to
someone
reading
this
data
format
without
iCalendar.
This
is
a
reference.
J
C
C
Yeah
I
want
to
try
we're
gonna
red
button.
You
out
come
back
in
while
we're
doing
that
I
sense.
The
reason
that
I
don't
care
that
I
think
it's
up
to
you
is
that
it's
a
very
small
working
group
with
just
a
few
very
active
participants
who
I
presume
have
been
following.
What's
going
on
so
I'm
not
really
worried
if
we
go
straight
to
publication
requested
and
we
do
a
community
last
call
and
then
one
of
our
participants
pops
up
and
says.
C
D
B
B
F
F
D
F
F
Some
people
were
misbehaving
there
right,
so
my
early
advice
to
Elliott
was
start
acting
like
a
working
group
and
if
you
do
a
good
job,
you
probably
will
be
one
so
I'm
tempted
with
this
one
to
actually
create
a
working
group
for
the
remaining
two
documents,
especially
considering
the
Reggio
location
stuff
there,
and
this
is
a
bit
of
a
hot
button
for
some
of
our
steamed
art
qualities.
And
you
know
it
would
be
nice.
M
F
A
F
B
B
C
Are
some
people
with
particular
bones
to
pick
about
any
of
the
time
zone,
stuff
and
I?
Don't
want
anybody
to
be
able
to
accuse
us
of
trying
to
hide
it
and
I?
Don't
want
those
people
to
come
here
and
disrupt
this
working
group?
That's
why
I
think
another
a
separate
working
group
would
be
good
and
I
hope
that
a
working
group
that's
tightly
chartered
would
keep
the
disruptors
from
getting
too
annoyed
or
annoying
cool.
B
All
right,
moving
on
to
the
Cal
Connect
work,
there
are
many
drafts
in
the
Cal
connect.
Public
drafts,
repository
or
expired.
Drafts
have
been
proposed
as
individual
drafts
to
those
yes
and
and
haven't
been
followed
up
on
I've
been
working
within
Cal
connect
to
convince
them
that
it
is
worth
bringing
this
work
to
the
OSF
and
that
it
it
will
actually
get
discussed
here.
It
won't
disappear.
B
The
relationship
got
fairly
sour
a
few
years
ago
and
there
was
talk
within
Cal
Connect
of
screw.
These
IGF
guys
we're
just
going
to
publish
everything
for
ourselves
or
through
I,
so
I'm,
trying
to
discourage
that
as
a
pathway
forwards,
particularly
for
things
that
update
existing
ICF
documents.
So
I
would
like
to
than
to
bring
the
work
here.
F
F
B
Yes,
all
right,
so
looking
at
the
drops,
there
are
two
drafts.
The
V
poll
and
subscription
upgrades
that
I
would
like
to
propose
that
we
adopt
into
this
working
group
to
work
on.
They
are
somewhat
complete,
but
not
entirely
done
and
in
a
good
state
to
bring
to
the
mailing
list
here
and
propose
that
Cal
Connect
work
on,
and
it's
sorry
that
calyx
work
on
and
that
hopefully
can
be
published
fairly
soon.
C
H
B
Hops
from
Melbourne
Prague
is
two
hops
from
Melbourne.
It's
the
same
distance
most
places
in
the
world
of
the
same
distance.
Alright,
so
I'll
do
a
corporate
option
to
the
mailing
list
for
those
two
documents
there
are
other
things:
the
auto
discovery
calendar
push
and
the
calendar
sharing
documents
that
I
could
also
throw
them
straight
into
call
for
adoption
now
or
we
can
try
and
bring
things
very
slowly,
I,
don't
know
what
you
prefer
to
do
us
a
drink,
to
throw
em
all
in
awesome.
C
B
C
H
B
F
F
C
Right
I
think
at
the
moment
the
vCard
stuff
is
still
in
the
dispatch
queue
discussion
there
about
where
to
bring
it.
You
needs
to
settle
and
as
far
as
I
know,
there
hasn't
been
a
whole
lot
of
discussion
about
that.
So
have
that
discussion
and
then
we'll
see
what
happens
as
you've
heard
in
the
dispatch
meeting.
My
opinion
is
that
it
shouldn't
be
here.
It
should
be
in
its
own
working
group
or,
if
not
in
J
map,
but
that's
my
opinion
and
I'm.
Not
gonna
I
have
no
more
say
than
anyone
else.
B
C
B
Might
just
read
through
what's
here
and
and
then
see
if
it
makes
sense,
read
outloud
it'll,
take
a
couple
of
minutes.
Calendar
extension
working
group
has
charged
us
to
develop
extensions
to
our
calendar,
I
tip
and
Cal
dev
standards.
Working
group
will
do
the
following
to
find
a
new
JSON
based
format
for
calendaring
and
a
mapping
from
our
calendar.
It's
a
new
format
which
is
J's
calendar
defined
a
new
set
of
iCalendar
properties
to
improve
management
of
alarms
and
default
notifications
and
calendar
events.
B
That's
one
of
the
pieces
of
work
that
we're
bringing
through
very
soon
to
find
a
standard
way
for
caldo
clients
to
control
creation
and
delivery
of
scheduling
messages
by
a
server
while
cleaning
up
after
abuse
migrating
events
or
us
throwing
for
backups,
which,
for
some
reason,
doesn't
appear
to
be
in
the
slides.
That
was
my
draft
that
I've
just
written
up
quite
recently.
Google
do
exactly
the
same
thing
in
house
in
their
server
and
we
use
it
now.
C
B
C
B
I'll
change
that
were
to
suppress
their
ego
to
find
a
new
set
of
a
set
of
new
iCalendar
properties
and
parameters
to
standardize
some
existing
experimental
ex
properties
in
common
use,
based
on
a
survey
of
existing
implementations
to
find
an
extension
to
our
count
of
support,
consensus
scheduling
where
members
of
an
event
or
task
voted
on
alternatives.
This
is
the
a
poll
stuff
sort
of
a
poll
stuff
maintain
the
existing
standards
for
calendaring
by
betting
errata
and,
where
necessary,
writing
specifications
to
clarify,
update
or
replace
the
existing
documents.
B
The
working
group
will
work
under
the
following
parameters.
The
extensions
developed
are
expected
to
be
backwards
compatible
with
the
existing
calendar.
Standards
in
incompatibilities
must
be
identified,
minimized
and
justified
for
each
set
of
extinct.
Extensions,
examine
the
impact
on
the
archer
protocol
and
define
any
necessary
extensions
to
our
chip
to
accommodate
such
impact
for
each
set
of
extensions,
examine
our
impact
on
the
caldera
protocol,
defining
a
necessary
extensions
to
quell
doubt
to
accommodate
such
impact
interface
with
HTTP
abyss
to
ensure
that
any
culled
out
changes.
B
The
consistent
was
good
at
shape
your
practices,
where
any
implementations
already
exist
and
have
been
shipping
for
some
time
either
document
existing
behavior
as
well
as
preferred
standard
or
just
document
the
existing
behaviors
informational,
which
deals
with
things
like
to
CalDAV
attachments
that
have
been
shipping
for
years
and
there's
not
much.
We
can
do
about
it
other
than
at
least
make
sure
people
know
out
of
scope
is
any
change
that
impacts
backwards.
B
A
B
B
D
B
D
B
B
F
Considering
I'm
no
longer
going
to
be
your
ad
at
this
point,
so
better
can
override
me.
I
suggest
a
limit
into
a
couple
of
documents
at
a
time
yeah,
at
least
in
the
same
state.
You
know
you
cannot
send
two
documents
at
a
time
you
have
to
bury
for
review
and
have
like
two
more
in
working
group
last
call,
but
don't
send
like
four
documents
at
the
same
time.
This
is
should,
should
you
succeed
at
this?
This
would
be.
You
know,
pick
over
load
for
reading.
So
all.
B
C
C
B
B
So
we
think
this,
this
current
set
of
milestones
is
still
reasonable
and
then
we'll
set
some
milestones
further
in
future
for
the
documents
that
come
through
all
right,
I'll
lay
them
out
over
the
rest
of
the
year
as
they
come
in
cool.
That's
good
plans
for
Montreal
I
expect.
We
will
have
a
couple
of
drafts
in
progress
by
then
hopefully,
I,
don't
know
whether
we'll
need
a
meeting
or
not
but
I
guess
we
can
make
that
call
a
month
or
so
out.
H
B
I'll
arrive
early
morning
and
the
friends
have
email
dinners.
Tomorrow,
night
7
p.m.
at
I
didn't
fill
in
the
details.
I
did
actually
fill
in
the
details,
but
the
URL
blanked
out
on
the
slide
for
some
reason.
But
anyway,
the
emails
sent
around
I
think
pretty
much
everyone.
Here's
in
the
email
working
groups
as
well
so
I'll
ask
for
a
short
ends
this
afternoon,
any
other
business.