►
From YouTube: IETF105-CALEXT-20190724-1550
Description
CALEXT meeting session at IETF105
2019/07/24 1550
https://datatracker.ietf.org/meeting/105/proceedings/
A
A
D
F
B
G
D
H
That
one
does
work,
yeah,
okay,
so
yes,
so
this
is
in
last
call
I
did
publish
a
new
draft
yesterday,
which
is
mainly
formatting
and
editorial
revision
to
just
try
and
make
it
as
readable
and
understandable
as
possible.
There
were
two
small
additions
which
I've
noted
here
on
the
slide.
One
was
a
extra
property
on
the
participant
where
you
could
record
a
comment
that
they
made
whilst
applying.
H
This
is
a
common
feature
that
is
already
being
represented
in
iCalendar
with
custom,
vendor
specific
properties,
and
so
I
thought
with
a
standard
property
for
like,
if
you
said,
maybe
you
can
write,
because
I
just
my
kids
birthday
or
something
and
recurrence
ID,
which
is
also
needed.
Mapping
from
iCalendar,
which
is
exactly
the
same
as
it
is
in
iCalendar,
so
I'm
going
to
actual
changes,
I
think
the
we
have
the
calyx
V
alarm
extensions
draft.
H
H
Snooze
snoozing
alert
is
defined
in
that
extension
is
actually
a
protocol
thing
rather
than
a
data
representation
thing,
there's
no
data
representation
for
that,
so
it's
not
needed
in
J's
calendar.
The
only
thing
left
there
for
in
there
is
proximity
alerts,
I,
don't
know
if
we
want
to
add
that
to
the
data
model
here
or
we
can
always
go
in
an
extension.
H
F
H
H
It's
the
property
name,
that's
standardized
and
so
that
property
name
shouldn't
be
used
because
it's
a
beforehand
because
it's
either
until
it's
it's
not
a
cleaning
on
one
you
can
use
with
a
vendor
specific
property
and
so
until
it's
in
a
icy-pop
or
defined
in
a
future
standard,
this
just
doesn't
exist.
This
is
just
the
same
as
in
my
calendar
other
formats
as
I
said,
because
it's
a
format,
not
the
protocol.
You
can't
negotiate
a
version
or
something
else.
That's
up
to
whatever's,
using
Jess
calendar
or
using
a
calendar.
H
H
E
D
H
J
H
D
D
D
H
Thank
you.
Oh
there's
one
one
next
slide,
so
there's
another
related.
So
this
is
an
informational
RFC
which
we're
also
going
to
publish
they
don't
need
to
be
published.
Concurrently,
I
think
this
one
will
go
out
afterwards,
advising
on
J's
calendar
to
iCalendar
translation,
it's
informational
because
deliberately
it's
it's
not
a
straight:
it's
not
just
a
syntactical
version
of
iconic
like
Jake
Ali's,
so
some
translation
bits
for
obscure
edge
cases.
You
can't
do
exact
translation,
so
you
might
want
to
do
different
things
in
different
situations.
H
I
think
almost
all
commonly
used
features
and
I
calendars
quite
straight
forward,
and
so
it's
worth
documenting
just
so.
People
have
that
reference
I
think
Robert
stepanak,
who
is
the
co-author
on
Jess
calendar,
will
finish
this
document
off
he's
away
on
leave
for
the
next
month
or
so,
but
I,
don't
think,
there's
a
rush
to
get
that
out.
So,
just
noting
that
that's
there's
a
draft
up,
it's
actually
reasonably
complete
and
we'll
finish
that
off
after
Jess
calendars
published
okay,.
H
I
I
So
first
thing
it
does.
This
I
think
is
fairly
uncontroversial.
It
standardizes
that
pretty
much
every
component
now
should
have
a
UID,
so
they
can
be
uniquely
identified
and
that's
all
this
does
so.
If
you
got
multiple
arms
they
each
have
their
own
UID.
So
if
any
reason
to
address
them
and
some
shape
or
form
it's
easily
to
do
so
next
slide
as
Neil
had
mentioned
earlier,
and
not
a
lot
of
acknowledgment
is
a
big
thing.
I
I
Next
slide
with
this
new
acknowledged
property,
which
Neil's
our
to
discussed,
is
basically
just
the
UTC
time
that
you
acknowledge
the
alarm
when
the
event
gets
updated.
Other
clients
should
see
it
and
not
continue
to
fire
smoothing
up
snoozing
alarms.
This
is
a
pretty
standard
thing
that
people
won't
like
to
do.
What
this
does
is
just
formalize
a
procedure
for
doing
so.
So
when
you
hit
snooze
on
your
device,
what
happens
is
a
new
alarm?
I
That's
a
sibling
of
the
one
that
fired,
meaning
it's
under
the
same
parent
component
will
get
created
with
a
UTC
time
to
fire,
and
you
in
theory
you
could
add
multiples
of
these.
If
you
wanted
to
and
when
each
one
reaches
its
conclusion,
you
can
do
the
same
thing
with
the
acknowledge
property
to
stop
that
last
item,
location-based
alarms
or
proximity
alarms
is
as
Neil
described.
I
Anybody
it's
has.
A
iPhone
is
probably
see
this
in
action.
Basically,
what
it,
what
it
means!
Is
you
fire
the
alarm
as
you
get
as
you
enter,
or
leave
a
particular
location
in
this
case?
There's
a
new
structured
location
property
which
is
defined
in
Mike's
event,
publication
Draft
in
this
particular
situation,
the
URI
you
would
use
would
be
a
Geo
URI,
specifying
the
location
that
you
want
to
fire
upon.
I
There's
also
two
other
values
that
can
be
used
for
the
proximity
alarm
that
Apple
is
currently
using.
We
felt
would
be
fine
to
standardize
them
here
as
well.
This
is
the
connect
and
disconnect
these
actually
occur,
I
believe
with
apple
carplay.
So
when
you
enter
your
car
and
a
Bluetooth
signal
or
Bluetooth
connection
gets
made,
you
can
fire
alarms
based
on
those
I.
Don't
know
what
the
use
cases
but
apples
seem
to
think
it
was
important
enough
to
put
them
in
their
draft
I.
F
H
No,
yes,
yes,
Neil
Jenkins,
oh
yeah!
They
connect
disconnect
just
wonder
if
we
want
to
have
some
other
property
of
saying
connect
disconnect
what
like
it
could.
If
you
omit
it,
it
could
be
device
specific,
which
then
is
whatever
Apple
wants
it
to
be
we're
now
using
it,
but
it
is
perhaps
slightly
overly
specific
at
the
moment,
I
think
in
the
spec.
It's
like
a
car
Bluetooth,
which
you
wouldn't
infer
necessarily
directly
from
the
fact
that
just
says
school
connect
exactly
right
right
from
the
spec.
It
is
a
to
make
our
places.
I
I
A
I
J
H
A
H
K
A
I
D
A
D
D
G
D
So
well
maybe
I
can
start
the
time
zone
discussion
we
had
and
any
time
Michael
is
ready.
You
take
the
slot.
Does
it
work
for
the
people
in
the
room
as
well?
Yes,
okay,
so
time
zone
distribution
system
is
basically
a
discussion
we
initiated
a
few
weeks
ago,
I,
think
and
or
maybe
one
week
ago,
and
the
reason
for
that
for
that
for
starting,
that
discussion
was
mostly
that
IANA
had
this
budget
discussion
for
a
four
years
plan.
So
we
just
wanted
to
see.
D
So
so
far,
I'm
just
gonna
try
to
summarize
all
the
different
things
we
that
have
been
discussed
on
the
mailing
list
and
but
the
big
conclusion
is
well
they're.
The
awesome
people,
people
are
quite
enthusiastic
about
doing
something
so
that
the
teas
that
data
be
appropriately
distributed
with
a
given
protocol
time
zone
distribution.
D
So
among
the
different
feedbacks
we
received,
we
perceive
them
well.
I
would
say
some
insight
that
we're
clearly
not
ready.
We
need
to
better
understand
the
global
ecosystem,
better
reach
out
the
people,
people
that
are
expected
to
deploy
this
time
zone
distribution
before
the
defining
the
system
to
understand
what
their
needs
are
and
then
to
elaborate
the
system
to
understand
the
resources
involved
for
that
system
to
better
quantify
qualify
all
the
requirements
in
terms
of
resource,
as
well
as
a
usage,
and
probably
then,
if
evaluate
how
the
product
will
be
a.
D
D
So
on
the
list,
there
were
at
least
two
two
different
things
that
have
been
suggested.
As
the
time
zone
distribution
service,
one
which
was
a
sort
of
global
service
and
another
one
which
was
a
sort
of
distribution
master,
so
we
need
to
to
really
focus
on
well,
apparently,
the
distributed
master
is
probably
the
one
we
want
to
target.
But
we
need
to
have
this
kind
of
discussion
to
understand
exactly
where
whether
what
our
target
should
be.
D
And
the
reason
and
a
global
service
may
not
make
sense-
is
that
the
people
distributing
the
time
zone
data
sometimes
do
do
not
actually
necessarily
distribute
the
time
zone
data
as
provided
by
the
INR,
but
sometimes
they
add
some
tweaks
and
some
adjustments.
So
that's
a
how
close
data
is
being
used
that
we
I
mean
our
protocol
needs
to
feel.
D
L
D
M
G
D
So
the
frequencies,
so
that's
the
frequencies
of
the
release,
which
it's
not
exactly
the
same
as
how
many
changes
appears,
because,
usually
you
have
a
set
of
changes
that
is
being
that
generates
one
release
and
so
data
I,
don't
really
know
so.
Some
people
were
complaining
that
the
sad
thing
is
that
they
have
to
wait
for
the
next
release
so
that
the
thing
that
I've
been
fixed
that
are
not
directly
pushed
or
they
can't
deliver
those
changes.
So
it
might
be
something
by
improving
the
synchronization.
D
D
What
our
I
mean
the
impact
of
one
time
zone
server
being
offline,
or
sometimes
they
post
suggested,
that
being
in
ninety
nine
plus
nine.
Ninety
percent
would
be
something
feasible
and
valuable,
so
not
a
huge
constraint,
except
for
the
minutes
that
maybe
a
messenger,
misunderstood
minutes
protocol
changes
the
time
zone,
distribution.
D
Does
not
it's
not
that
you
cannot
retrieve
the
full
data,
but
there
is
no
currently
no
no
wait
to
retrieve
the
database
because
it's
only
Jason
and
I
don't
know
how.
If
there
is
a
game
to
provide
a
full
database
that
versus
said
it
passed
in
to
Jason.
So
that's
I
think
that's
was
some
of
the
protocol
changes
that
have
been
suggested
and
in
any
case
the
idea
is
to
be
able
to
optimize
the
synchronization
process
to
the
data.
We
need
I
think
overall
checking
the
leap.
M
N
D
H
D
H
A
ninety
percent
uptime
is
never
gonna
work
like
the
own
initial
startup.
It
means
you
won't
have
any
cache.
Data
I
need
to
be
fetch
it.
So
that's
at
that
point
that
doesn't
work.
So
what
doesn't
work
well,
you
mentioned
that
they
thought
90%
availability
will
be
fine
because
people
cache
stuff-
oh
that
doesn't
work
if
it's
their
primary
source
as
it
would
have
to
be
pre-loaded
and
then
how
out-of-date
is
it
I?
The
other
thing
is
that
either
they
I
mean
a
single
source
that
gets
pushed
out
everywhere
immediately.
I
L
H
Again
sure,
but
B
you
don't
need
the
I
on
a
server
bit
for
that,
like
in
changes
so
infrequently.
As
we
said,
it
would
be
trivial
for
the
OS
vendor
to
have
a
separate
server.
They
can
just
update
that
it
seems
from
there's
not
part
of
their
patch
process,
which
is
the
main
thing
in
that
system.
Not
the
fact
that
there's
not
an
ax,
so
I.
F
Hop
in
here
with
the
going
back
to
that
previous
slide,
where
we
said
that
they've
been
at
most
eighteen
updates,
for
you
part
of
the
reason
for
that.
Yes,
that
places
can't
update
immediately
and
guarantee
that
every
device
will
get
it.
If
you
could
update
your
timezone
and
guarantee
that
every
device
in
the
world
would
be
correct,
I
suspect
it
might
happen
more
frequently.
So
we
don't
want
to
encourage
governments
to
do
silly
things.
J
O
If
this
is
not
something
which
you
know
a
CDN
could
handle,
you
know
yes
scaling
out
the
ability
of
you
know
eventually
billions
of
people
receiving
it.
We've
done
something
wrong,
because
that's
what
they're
good
at,
especially
when
we're
talking
about
things
that
are
in
the
you
know,
tens
of
kilobytes.
D
And
so
a
last
point
was
about
how
to
authenticate
the
data
provided
by
the
IANA,
because
well
so
that
that
would
provide
a
means
to
do
not
authenticate
as
a
source,
you're
retrieving
the
data,
and
so
that
might
help
to
be
able
to
publish
intermediary
results.
So
the
teaser
database
is
on
github,
so
you
have
to
the
commit
also
and
then
the
other
thing
is
to
be
able
to
to
authenticate
the
data
as
well
as
what
your
publisher
has
been
published.
I
mean
no
tweaking
to
that.
So.
D
D
Maybe
I
did
I
didn't
remember
the
second
bullet
were
there,
but
let's
go
to
the
third
one,
to
define
a
discuss
a
little
bit
better.
What
is
with
them
the
time
zone,
distribution
system
requirement
the
users
and
so
on
and
go
to
the
protocol
the
data,
because
some
of
the
metadata
have
not
yet
being
standardized,
and
so,
if
there
is
significant
interest,
we
go
to
the
ID
and
proud
we
have
a
dedicated
working
group
can.
A
E
B
K
A
E
P
N
N
N
N
So
there
was
a
lot
of
discussion
around
my
changes
to
the
source,
property,
I,
think
and
I
I
suggested.
The
rear,
I
should
probably
do
is
just
drop
that
and
use
structured
data.
Instead.
The
whole
intent
of
sauce
was
to
provide
some
other
way,
a
way
to
to
provide
a
link,
all
the
content
of
something
that
was
providing
the
data
for
say,
a
participant
of
e-card
or
something
of
that
kind.
I
think
structured
data
actually
works.
Fine
for
that.
N
N
It's
I
think
it
can
raise
the
point
that
some
implementations
have
measure
tassel,
so
they
strip
attachments
off
and
and
just
provide
a
pointer
to
them.
We
don't
want
that
happening
with
structured
data,
it's
really
to
be
carried
along
the
thing
and
we
didn't
want
to
extend
attach
anyway,
because
we're
gonna
run
into
some
strengths,
backward
compatibility
issues
here
so
so,
which
in
the
end,
we
decided
a
new
properly
was
a
cleaner
and
easier
way
of
dealing
with
this,
and
it's
we've
done
this
kind
of
thing.
N
I
did
this
kind
of
thing
before
we
even
thought
of
structured
data
for
oasis,
there
is
a
need
to
transport
a
well-defined
payload.
It
may
not
be
calendar
data
as
such,
but
it's
related.
It's
something
that
is
is
a
is
related
to
the
event,
and
so
we
invented
something
in
in
Oasis
for
the
smart
grid
stuff,
but
in
fact,
out
of
his
structured
data,
if
that
had
been
appropriate.
N
N
Allows
them
to
steer
events
to
different
calendars
if
they
recognize
was
such
as
I.
Think
in
the
discussion
about
what
was
it
called
the
maintenance
thing
that
brought
up
the
whole
structured
data
discussion?
That
was
one
of
his
requirements
as
as
these
events
come
through,
they
don't
go
straight
into
a
regular
count
or
they
get
steered
to
a
different
calendar
and
that's
related
to
maintenance.
You
can
recognize
that
from
the
schema
without
actually
parsing
it
and
that's
I
think
is
an
advantage.
So
what
was
the
next
slide?
N
Oh
yeah
and
you
know,
there'd
been
a
suggestion
that
we
should
use
a
mind
type
instead
of
schema
and
that
attached
already
supported
that.
But
that
means
we
have
to
keep
defining
mime
types
to
map
them
onto
schemas.
When
we
already
have
a
schema,
the
mime
type
doesn't
define
the
the
data
model.
It
simply
defines
the
way
you
represent
it.
It's
Jason
or
or
XML
or
whatever
and
and
schema.org
has
a
specific
mime
type
for
their
JSON
data.
N
N
And
that's
not
to
say
you
couldn't
use,
attach,
that's
not
to
say
you
couldn't
use
a
mind
type.
If
that's
inappropriate
and
it's
not
to
say
you
couldn't
redefine
all
this
data
as
counter
data.
If
again,
that
seemed
appropriate,
but
a
lot
of
stuff
for
transport
isn't
counter
data,
it's
a
payload
and
yeah
and
I
guess.
My
last
point
was,
though,
we've
been
talking
about
schema.org.
It
wouldn't
have
to
be
schema.org
that
could
be
defined
anywhere,
including
in
the
IETF
and
the
the
other.
N
The
other
point
I
was
going
to
make
about
this
is
there's
a
good
there's,
a
big
advantage
to
keeping
all
this
payload
separate
from
counter
data.
We
want
to
keep
the
model
simple
if
we
start
extending
the
eye
calendar
or
the
j/s
calendar
or
whatever
data
model.
Every
time
we
want
to
transport
something
it's
gonna
get
ridiculously
complicated
and,
and
it's
simply
not
necessary.
We
don't
have
to
absorb
everything
into
the
data
model.
We
just
need
to
recognize
with
transporting
data
along
with
the
event.
So
that's
that
really
is
allowed
to
say.
Like
any
comments.
N
P
P
Yes,
yes,
okay,
so
he
said
he
spoke
with
you,
but
he
did
say
that
the
there
were
some
remaining
issues
that
needed
discussion
and
feedback
from
the
working
group
list
and
so
I
think
that's
just
one
part
of
preventing
Ayana
from
saying,
okay,
just
curious
of
what
you
discussed
here.
If
that's
part
of
what
Cyrus
had
a
problem
with
and
has
it
been
fixed
or
is
that
still
yeah
yeah.
N
Yes,
the
I
think
I've
got
a
draft
ready,
which
covers
a
lot
of
the
points
he
talked
about
were
to
do
with
the
the
a
B
and
F
issues
on
the
rest
of
it,
but
he
did.
One
of
his
big
problems
was
was
sauce
and
how
that
was
being
extended,
and
so
that
this
is
what
sort
of
triggered
my
thoughts
about
that
and
with
the
other
comments
people
have
made
about
sauce,
I'd,
say
in
the
end
it
occurred
me.
N
D
King
and
any
other
questions
feedback.
N
H
That
I
think
as
far
as
icon
properties
is
overkill
and
makes
everything
way
more
complicated
and
it's
necessary,
especially
when
there
are
existing
schemas
like
the
ones
you
reference
you
so
I
I
do
I
would
strongly
disagree
with
that.
As
a
solution,
I
think
what's
happening,
is
fine.
I
can
see
how
you
could
embed
them
as
attach
things,
but.
H
N
Would
say
that
for
going
forward
with
chairs
calendar,
we
should
perhaps
maybe
we
could.
We
wouldn't
have
the
backward
compatibility
issues.
I
mean
the
to
us
are
close.
You
know
just
this
generic
attachment
and
and
this
this
payload
we
could
probably
combine
the
two
andreas
calendar
because
we
can
move
forward
and
we
could
distinguish
between
the
things
and
that
may
be
worth
thinking
about,
but
I
think,
if
I
counter
to
avoid
backward
compatibility
issues
in
the
rest
of
it.
This
makes
more
sense.
H
New
him
yeah
well
with
the
chairs
Condor,
you
have
a
nice
thing.
Is
these
scheme
of
things
have
in
JSON
as
well,
so
you
could
just
embed
them
in
Tripoli
and
that's
a
definite
advantage
of
the
attaches
you're
not
having
to
pass
anything
again.
It's
just
reading
further
properties,
but
also
yes,
they
are
not
part
of
the
Jay's
calendar
thing,
you're,
not
finding
new
properties
for
every
single
one
of
these
things.
So
it
certainly
makes
a
lot
of
sense
in
that
context,
I
think.
D
N
F
Yes,
hello,
I
just
slept
this
together
last
night
cuz,
you
know
being
organized
and
all
that
this
is
just
I,
guess
a
a
primer
for
anyone
who
doesn't
know
what's
with
Cal
Connect,
which
I
suspect
is
pretty
much
nobody
here,
but
also
letting
people
know
the
dates
of
the
next
Cal
Connect
meeting
and
inviting
people.
So
if
we
could
go
to
the
next
slide,
please
so
a
bit
of
background
on
Cal
Connect.
F
It
was
set
up
to
allow
companies
who
are
working
on
new
products
to
test
an
interoperability
without
the
public
relations
problem
of
the
whole
world.
Knowing
what
they're
working
on
and
and
starting
to
harass
them
about
it,
we've
now
moved
to
meeting
just
twice
a
year,
so
we're
meeting
October
in
Philadelphia
and
then
it
will
be
in
San,
Francisco
and
I
think
April.
So
moving
to
a
six
months
league
schedule,
the
I
put
the
link
in
here
to
the
minutes.
F
F
We
store
public
drafts
in
github
from
Cal
Connect.
There
are
many
documents
there
in
various
states.
The
documents
Mike
and
Ken
have
been
talking
about,
have
been
cherry
picked
out
of
there
s,
the
ones
which
we
think
her
in
good
enough
said
to
bring
to
IOT
F
some
things.
There
we've
looked
at
and
said
they've
either
they've
died
in
the
meantime,
no
one's
interested
in
them
or
they've
been
subsumed
into
joyous
calendar,
but
there
is
additional
work
there.
F
In
some
cases,
it's
things
that
have
been
in
the
wild
for
years
and
so
we're
going
to
try
and
bring
those
ones
to
ATF
as
informational
standards.
Subtlest.
There
is
a
public
document,
that's
in
a
fixed
place
that
people
can
come
and
see
how
random
stuff
they
see
on
the
wire
actually
works
next
slide
yep.
So
the
other
thing
that
Cal
connects
working
on
is
contacts.
F
The
jeaious
contact
specification
is
over
in
dispatch,
didn't
manage
to
get
dispatched
at
the
last
IGF
and
we're
not
quite
there
for
this
HF,
but
we
found
a
co-author
and
that's
moving
forwards.
This
additional
work
on
vCard
happening
and
over
the
last
year,
Cal
Connect
became
a
member
of
ISO
and
is
working.
You
know
ISO
on
the
dates
and
name
standards
which
we'll
need
for
that.
The
last
thing,
of
course,
is
that
we
are
keen
to
get
additional
people
working
on
this.
F
At
the
moment,
ken
and
Mike
are
taking
all
the
documents,
as
he
saw
the
event.
Pub
Mike
basically
took
a
document
that
was
originally
written
by
an
author
at
Apple
and
has
been
shepherding
it
since
then,
we'd
love
to
have
more
people
come
in
and
volunteer
to
work
on
these
documents.
The
main
thing
that
delays
our
bandwidth
is
reviewer
time
within
this
group,
but
also
the
number
of
authors
that
we
have
available.
O
A
I
thought
it
was
supposed
to
be
on
the
joint
meeting
agenda
for
the
last
time,
but
it
has
to
do
with
the
extensive
use
of
URIs
or
this
extensive
option
of
putting
URI
Xin
in
the
event
pop
stuff
and
and
my
concern
about
URIs
that
get
automatically
resolved
by
calendar
clients
and
what
that
can
do
when
you
have
URIs
that
can
be
militia
that
can
point
to
malicious
things.
So
that's
a
discussion.
We
need
to
have
somewhere
either
here
or
with
Cal
Connect
during.
H
H
H
We
would
have
to
start
doing
the
same
thing
stuff
in
calendar
events,
and
we
can
do
that,
but
it
increases
the
risk
of
those
kind
of
privacy
leaks
and
makes
it
harder,
whereas
the
structured
data
thing
suffice
must
be
embed.
It
makes
a
lot
easier
because
there
isn't
an
external
thing
you
have
to
fetch
in
order
to
be
able
to
display
it
right.