►
From YouTube: IETF112-CALEXT-20211110-1430
Description
CALEXT meeting session at IETF112
2021/11/10 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
All
right
well,
according
to
my
clock,
it
is
time,
hello,
everybody
and
welcome
to
beautiful,
sunny
madrid
where
we're
enjoying
ietf,
and
this
is
the
calexed
session.
So
if
that's
what
you
want
to
be
it's
here,
you
are,
I'm
just
going
to
run
us
very
quickly
through
the
first
couple
of
slides
here,
the
notewell
which,
by
now,
I
think
most
of
us
know
very
well
either
we've
seen
it
this
week
during
the
calls,
or
at
other
times
everything
that
you
contribute
during
this
session
is
covered
under
these
various
best
common
practices.
A
So
please
note
these
well.
I've
also
added
another
slide
that
I
have
seen
floating
around
at
this
meeting.
Basically
saying
please
be
nice,
please
behave
well.
People
please
be
aware
that
there
will
be
people
who
might
be
quite
new
to
your
area
and
don't
know
all
the
jargon
and
all
the
the
backstories
on
everything
so
make
them
feel,
welcome
as
well
and
and
don't
assume
too
much
knowledge.
A
Thank
you
sound
all
right
with
that
said,
here's
the
agenda.
So
this
is
what
we
were
planning
to
talk
about
so
far
at
this
call.
If
anyone
has
anything
you
would
like
to
to
change
or
talk
about
here,
please
pop
in
the
queue
and
let
us
know.
B
I
mean
there's
nothing
changed
really
for
the
the
drafts
in
progress.
Unfortunately,
since
we
spoke
what
two
weeks
three
two
and
the
relations
thing
probably
will
take
a
little
more
than
five
minutes.
A
Cool
the
other
thing
I'd
say
just
up
to
start
before
we
we
get
into
this
with
a
group,
this
small,
I
think,
unless
things
start
getting
a
bit
crazy
about
anything,
feel
free
to
just
hop
in
and
talk.
If
you
want
to
talk
rather
than
raising
your
hands
and
waiting
to
be
requested,
and
it
makes
things
a
little
bit
smoother
in
a
small
group
like
this,
so
mike,
would
you
like
to
control
the
slides
or
do
you
want
me
to
pop
them
up
and
and
go
through
them,
for
you.
B
If
you
could
put
them
up
for
me,
there's
only
three
and
the
title:
cool.
B
Move
on
then,
so,
among
the
various
comments
somebody
said,
the
security
section
ought
to
have
some
comment
about
the
the
perils
of
xml,
because
there's
an
xml
reference.
I
couldn't
find
any
anything
I
could
lazily
copy
and
paste
from
anywhere.
B
Oddly
enough,
I
did
find
plenty
of
blog
entries
about
the
problems
of
with
xml
things
that
the
xml
specifications
don't
appear
of
anything
like
a
security
section.
So
I
think
I
made
up
something
like
that
last
paragraph.
B
B
Useful,
I
could
point
at
or
whether
that
last
paragraph
will
do
as
a
warning
to
read
further.
I
guess
if
people
are
using
xml,
maybe
they
know
the
pos,
maybe
that's
a
wrong
assumption
to
make.
C
Come
up
with,
but
was
the
comment
something
generic
or
was
it.
B
Yes,
it's
just
the
generic
problems
with
xml,
because
there's
an
xml
reference
introduced
in
this
relations
draft,
and
it's
just
that,
given
that
we're
pointing
at
xml,
then
maybe
you
should
say
something
about
the
various
securities
who's
surrounding
xml,
which
was
a
reasonable
enough
comment.
Just
I
couldn't
find
anything.
C
Not
pointing
to
a
specific
problem,
no.
B
No,
no,
no
or
something
yeah.
No!
No!
It
didn't
didn't
offer
anything
like
that.
So
I
did
some
digging
around
and
that's
I
would
say
the
best
I
could
come
with
next
within
rfcs
was
the
web.
Dev
spec
has
something
about
xml
entities,
which
I
think
is
the
main
problem,
but
I'm
sure
there
are
others,
but
that
last
paragraph
is
essentially
where
I
was
gonna.
B
I
was
gonna
update
the
the
spec
with
with
that
in
the
security
section
which
so
that's
that's
the
xml
thing,
and
I
think
the
only
the
only
other
major
comment
is
the
next
slide.
Bronn.
B
B
B
Links
in
html
and
atom
and
it
allows
you
to
express
them
as
a
as
a
link
header
and
what
caught
my
eye
was
that
what
was
it?
B
The
various
types
of
link
relation,
it's
useful
to
have
something
where
you
could
link
to
external
entities
and
say
exactly
what
type
of
external
entity
it
was
you
you
were
linking
to
so
I
this
was
proposed
some
time
ago
without
any
comment
from
anybody
and
then
mark
nottingham
was
made
aware
of
it
and
I,
in
actual
fact,
as
I
read
through
the
spec
again,
I
think
the
relations
draft
actually
is
a
reasonable
serialization
of
the
link
header.
B
B
B
I
mean
he
suggested,
defining
our
own
registry
or
whatever
we're
not
getting
tangled
into
it,
but
I
think
that
just
leads
to
more
overlap
and
confusion,
because
we're
trying
to
do
the
same
yeah
I
agree
having
having
your
own
registry,
is
just
more
work,
yeah
and
it
just
doesn't
make
sense,
defining
exactly
the
same
thing
and
one
of
the
comments
he
made
was
well.
B
You
may
get
an
idea
whether
it's,
whether
you
ought
to
be
using
the
same
rights
by
looking
at
the
current
link
relations,
so
I
hadn't
actually
been
explicit
about
any
of
the
existing
link
relations.
I
did
define
a
source
relation,
which
is
one
of
the
things
I
think
we're
missing
in
them.
B
Initially,
there
is
something
of
the
kind
for
a.
B
A
v
counter
object
that
cyrus
defined,
which
allows
you
to
reload
the
v
calendar
object,
but
there's
nothing
that
allows
you
to
say.
Where
can
I
go
to
to
find
a
live
copy
of
this
thing
somewhere
an
event
publication?
That's
very
useful,
because
you,
where
you
may
want
to
be
able
to
point
people
back
to
a
site
which
is
displaying
events
or
whatever,
which
is
what
I
do
with
our
calendar
system,
so
having
a
source
property.
Would
you
link
back
to
the
the
the
event
as
it
appears
on
the
site
it
came
from?
B
Is
is
useful,
so
I
think
I
think
I
just
need
to
to
be
more
explicit,
that
this
is
a
serialization
of
the
link
link,
header,
so
I'll
add
a
paragraph
to
make
that
the
case
and
I'll
I'll
actually
explicitly
specify
that
the
label
is
the
same
as
as
title
and
and
and
format
type
is
the
same
as
type
in
in
that
header
and
they've
got
things
like
title
star
or
whatever,
which
allows
it
for
a
different
encoding
of
of
the
title
things.
B
I
don't
think
that
we
would
do
that.
I
think
if
you
want
also,
if
you
want
different,
I
think
it
allows
for
accented
characters
and
weird
things
like
that,
which
sounds
more
like
localization
than
anything
else.
So
I
guess
we
could
deal
with
that
in
a
localization
thing
and
and
to
address
his
comment
about
what
sort
of
overlap
is
there
between?
You
know
current
link
relations.
B
I
noted
a
few
of
them,
which
seemed
immediately
useful
for
mostly
in
in
event
publication,
but
perhaps
not
all
together,.
B
We
a
long
time
back
there
was
a
discussion
in
cal
connect
about
being
able
to
add
copyright,
information
and
and
so
on,
to
to
events,
and
we
we
actually
spent
some
time
discussing
it
and
then
and
it
then
just
got
dropped.
I
think,
for
some
reason
I
think
the
person
who
was
trying
driving
it
actually
actually
left
those.
B
Those
look
immediately
useful
to
me,
especially
in
event,
publication
being
able
to
specify
you
know
terms
of
service,
any
privacy
policy
if
there
is
any
and
and
the
copyright
information
just
looks
useful
author
might
be
useful
payment.
Actually,
we've
had
a
lot.
We
do
have
a
feature
in
our
system
where
you
can
register
for
events
and
pay
them.
That
might
actually
be
useful.
There
are
a
few
other
things.
B
A
web
mention
was
an
interesting
thing
and
and
there's
a
whole
bunch
of
other
ones,
that
I
hadn't
really
noticed,
which
look
more
like
countering
things.
There's
a
whole
bunch
of
them
called
interval,
something
other
which
relates
things
together,
which
seems
to
overlap
with
the
relations
and
the
the
related
two
temporal
relations
that
I
added,
but
it
looks
like
it
might
be
another
useful
document
on
how
to
use
some
of
the
other
link
relations
that
already
exist.
So
I
think
there's
a
lot
that
we
could
use.
B
D
Just
a
couple
comments
from
from
my
standpoint,
I
I
want
to
agree
with
mike
I
don't
and
brian.
I
don't
think
we
need
to
define
our
own
registry.
I
also
think
that
by
using
the
format,
type
and
label
properties,
we
actually
do
have
a
serialization.
We
just
as
mike
said,
we
just
need
to
mention
that
and
as
far
as
the
title
star
parameter
in
in
the
actual
hdb
header,
I
think
that's
for
non-ascii
characters
and
since
we're
utf-8
anyways,
I
don't
think
we
have
to
worry
about
that.
Mike.
A
Yeah
back
on
the
xml
issue,
this
working
group's
probably
not
the
best
place
to
find
people
with
a
lot
of
expertise
in
xml
security
but
yeah.
I
that
looked
fine
to
me.
Okay,
I
I
just,
I
guess,
francesca's,
probably
the
one
to
check
with
as
the
responsible
area
director.
If
that's
if
she
thinks
that's
going
to
be
sufficient.
D
B
I
don't
think
the
original
comment.
It
wasn't
so
much
that
we
need
to
go
into
any
detail
about
this,
but
at
least
just
mention
that
there
are
security
issues
with
with
xml.
So
I
think
at
least
I've
answered
that
whether
having
raised
the
issue,
other
people
think
it's
sufficient
yeah.
I
think
we'll
just
see
how
that
goes.
B
C
F
A
B
No
and
I
haven't,
I
haven't
managed
to
do
anything
with
the
testing
in
the
last
few
weeks.
Just
briefly,
I
think
I
I
this
has
been
lying
dormant
for
a
long
time
and
then
I
I
noticed
that.
B
Oh
sorry,
can
I
can
I
just
step
back
a
moment
to
to
relations
what
one
other
slight
make
is
mark,
not
even
notice.
The
relations
draft
is
actually,
you
know,
is
referencing
that
the
h288,
but
in
fact
so
does
js
calendar
and
and
and
ken's
current,
so
maybe
we're
already
due
for
another
errata
in
there.
In
that,
I
think
I
guess
what's
going
to
happen,
is
we'll
have
to
in
some
way
refer
to
what
I
what
I
mentioned
in
the
relations
draft
in
js
calendar.
B
B
Of
explicitly
referring
to
the
whatever
comes
out
in
the
relations
spec,
sorry,
yes,
anyway,
back
to
to
tasks
because
they've
been
dormant,
so
long,
they've
been
the
world
has
changed
a
bit
around
it.
So
I
need
to
update
the
whole
spec
to
refer
to
the
relations
work.
That's
moved
on
a
bit
since
then,
and
also
probably
to
make
use
of
the
participant.
B
Components
to
group
things
together,
one
of
the
big
things
that
was
going
on
with
with
them
the
tasks
specification
was
to
try
to
improve
reporting
of
status
and
also
status
related
to
particular
actors.
In
the
when
you
have
a
task,
that's
been
carried
out
by
a
bunch
of
actors
which
correspond
to
attendees.
B
You
want
to
be
able
to
relate
to
the
status
of
that
for
per
attendee
or
actor
in
the
thing,
so
that
is,
we
had
a
a
parameter.
B
The
group
parameter
which,
which
basically
said
this
this
is
part
of
a
group
of
properties.
It
was
a
bit
of
a
crude
way
of
doing
things,
and,
and
it
was
because
we
were
frightened
of
having
new
components
at
a
time
we
stopped
being
frightened
of
that.
So
participant
is
a
more
reasonable
way
to
do
that,
and
also
the
status
property
in
icalendar
is
is
really
has.
It
has
the
same
problems
that
you
want
more
than
just
status.
B
You
want
to
have
an
associated
comment
and
all
the
rest
of
them
and
which
we
have
sort
of
that
in
in
just
counting.
So
I
think
the
thing
to
do
there
is
probably
to
just
introduce
a
new
component
which
groups
those
things
together
and
allows
you
to
have
a
status,
that's
much
more
complex,
and
so
I
I
it's
a
there's,
a
fair
amount
of
rewriting
to
be
done
there.
So
I
I
need
to
get
that
done.
A
B
H
Hello
yeah,
so
the
basically
there
is.
Unfortunately,
no
progress
has
been
made
since
our
interim
a
month
ago,
so
that
is,
we
are
still
in
a
design
phase
of
defining
the
mapping
from
gs
calendar
to
I
calendar
or
do
the
other
direction
already.
H
As
has
been
said
earlier,
is
already
supported
quite
well,
and
so
what's
waiting
for
us
to
go
into
last
call
for
this
is
to
have
implementation
experience
with
mapping
from
js
current
to
icalendar
I'll
put
priority
for
the
cyrus
imap
server
that
we
now
get
started
with
this,
so
that
this
rfc
doesn't
lean
us
around
too
long.
B
H
B
Yeah
I
have
the
another
implementation
is
that,
yes,
we
and
I've
been
a
little
bogged
down
in
there
trying
to
get
a
new
release
out,
but
yeah.
I
will
try
and
and
push
along
with
the
implementation
of
of
of
this
mapping
and
the
same
time
update
the
place.
The
spec,
let's
see
if
we
get
get
it
wrapped
up.
H
B
Yeah,
that's
what
I
was
trying
to
resolve
with
the
the
tasks
and
the
relations
again.
The
relations
thing
moved
along
because
yeah
there's
there's
a
couple
of
things
that
it
depends
on.
H
Yeah,
okay,
so
I
I
guess
the
next
step
is
that
we
to
get
together
and
and
sort
this
out
how
we,
how
we
get
started
with
this
one.
Then
yep,
okay,
cool
yeah,
that's
that's!
It.
A
B
B
A
B
Let's
say,
let's
say
very
s
very
soon:
it's
it's
a
smallish
draft,
so
I
I
I
probably
need
to
re.
Take
a
last
run
through
it
and
and
perhaps
refresh
it
that
might
be.
The
thing
to
do
is
take
a
a
good
look
through
it
push
out
another
another
version
just
to
to
refresh
the
dates
on
it,
and
then
we
can
decide
whether
it's
good
enough
to
get
a
last
call.
Would
that
do
it.
A
All
right,
the
next
item
on
our
agenda
after
this
is
future
work,
section
vpol,
server-side
subscription
planning
to
once
these
documents
are
out.
What
does
this
working
group
do?
Next.
B
Yeah
people,
the
I
did
I
did
do
some
updates
on
the
on
the
vpol
spec
to
make
use
of.
B
Participant
component
we
had,
we
had
a
a
component
defined
in
there,
which
is
the
voter,
and
it
makes
a
lot
more
sense
to
use
the
participant
component
that
defined
already
and
so
that
I've,
I
think,
I've
I've
done
that.
I
I
haven't
updated
my
implementation
fully
and
I
think
the
the
only
other
active
implementation
that
might
be
around
which
needs
updating
is
cairns
in
cyrus.
D
Yeah,
I
have
not
updated
it
to
the
current
draft.
B
And
so
I
I
think
it
I
probably
ought
to
again
take
another
look
at
where
I
am
with
with
that
trap.
I
think
it's
I
think
it's
I
think
I
updated
it
all
I
can
reap.
I
can
publish
it
again,
there's
a
new
version
and
maybe
that
will
wake
things
up
a
little.
A
D
Oh
for
sure,
yeah
I
can
try
to
make
an
effort
to
have
updated
implementation
by
the
merge
itf,
if
not
sooner,.
A
A
All
right
and
service
side
subscription
was
the
other
thing
that
was
specifically
on
the
list
to
talk
about
here.
We,
I
think,
we're
still
just
waiting
on
apple
to
get
back
to
us
on
that
aren't
we.
A
Cool
that
is
all
we
have
on
our
agenda.
Is
there
any
other
business.
D
E
D
There
mike-
and
I
have
talked
this
on
on
some
of
our
cal
connect-
calls
that
five,
five
four
five
and
four
six
probably
are
due
for
a
refresh
I'm
just
looking
at
five
five,
four
five
right
now,
there's
17
there
fight
errata
there's
looks
like
seven
five
other
specs
that
have
updated
it,
which
could
probably
be
rolled
in
and
given
some
of
the
current
discussion
with
dmarc
and
imip,
I
think
5546
probably
needs
some
new
language
in
terms
of
how
to
properly
deal
with
someone
sending
invites
replies
on
someone
else's
behalf.
B
B
One
of
the
things
I
have
suggested
in
in
the
in
the
past
that
we
we
really
are
lacking
is
a
is
a
document
that
is
just
specifically
describes
the
the
countering
data
model
independent
of
of
representation.
B
You
can
disentangle
it
from
my
calendar.
If
you
look
closely
enough
and
when
we
have
things
like
js
calendar,
it's
trying
to
support
essentially
that
same
data
model
with
a
different
representation,
but
it's
really
hard
to
tell
whether
we're
doing
it
right
or
not,
and
there
are
other
representations
that
are
around
now
and
could
be
around
in
the
future
and
and
perhaps,
rather
than
simply
you
know,
bringing
out
a
new
unreadable
document,
we
could
consider
the
possibility
of
producing
a
document
that
describes
the
country
data
model
it
it.
B
It
won't
be
any
less
work,
but
it
it
might.
It
might
be
more
valuable
than
simply.
B
B
Yeah
it's
more
valuable
going
forward
because
I
think
it
it
allows
us
to
define
a
different
extra
for
other
formats
and
representations
and
and
be
able
to
have
something
you
can
say.
Will
it
correspond?
It
actually
does
represent
this
data
model
and
it's
what
they
do
in
oasis.
They,
I
think
they
are
required
to
produce
these
things.
They
call
like
there's,
pins
and
puzzles,
which
is
a
platform
independent
model
and
a
platform-specific
model,
which
is
you
know
one
is
the
actual
data
model
one's
a
representation?
A
B
There
there
is
actually
a
there
is
actually
a
data
model
specification
which
isn't
complete,
but
it
it
it
could
be.
It
could
actually
take
a
lot
of
the
work
out
of
it.
It's
it's
going
back
to
a
oasis.
B
When
we
did
ws
calendar,
they
defined
a
a
a
pin
for
the
ws
calendar
spec,
which
is
a
subset
and
a
subset
and
a
modification
of
of
I
calendar,
so
it
it
may
be
worth
looking
at
so
there
may
be.
There
may
be
something
to
start
with.
C
But
I'm
wondering
to
me
if
I
have
to
refer
to
the
model,
I'm
going
to
read
the
gs
calendar
and
I'm
wondering
how
who,
who
is
the
target
for
such
a
document
and
how
is
it
gonna
be
more
readable
than
a
gs
calendar.
C
Or
even
if
we
we
take
the,
I
mean
the
ical
specification.
G
G
G
Yes,
I
think
you
you
do
it
as
just
another
bit
in
your
text
alternative
and
yeah
yeah,
which
will
fall
out
kind
of
upgrade
parts
as
well
to
get
away
from
it
for
everything
yeah.
We
can
do
easily.
A
All
right
that
sounds
like
it's
definitely
going
to
be
some
upcoming
work
in
terms
of
actions
from
this.
A
D
A
A
A
A
So
out
of
scope
is
changes
that
impact
backwards,
compatibility
with
existing
stuff
and
any
attempt
to
develop
non-gregorian
calendar
systems
so
yeah
we
would
probably
want
to
to
specifically
say
we're
going
to
go
back
and
and
redo
all
the
documents.
I
think
people
might
might
have
questions
about
redoing
them
entirely,
rather
than
just
extensions
too.
G
G
We
know
is
commonly
confusing
yeah,
maybe
merging
if
there's
extensions,
that
should
all
be
part
of
one.
E
E
So
I
think
I
would
I
would
put
the
isp
and
ask
before
the
surgery
is
absolutely
because
I
mean
it
will
be
reasonable.
A
A
A
A
Please
come
here
if
you
have
calendaring
stuff
and
and
that
way
we
say
yes,
we
we
own
and
look
after
this
section
and
work
will
happen
here
rather
because
this
the
length
of
a
charter
like
this
and
the
very
specificness
of
it,
it
does
sound
like
it.
It's
just
it's
a
waste
of
everyone's
time
to
be
rechartering.
Every
time
you
do
a
new
document.
B
Yeah,
I
agree,
I
mean
that's
essentially
what
it
is.
Isn't
it.
C
Yeah,
I
am
so
two
thing:
if
we
don't
need
to
recharter,
I
I'm
not
for
it,
so
whatever
we
want
to
do,
if,
if
there
is
an
agreement
and
it
can't
fall
in
into
the
charter,
it's
it's
good
to
avoid
this
work.
C
If
we
feel
we
do
really
have
to
recharter,
then
I
agree
with
brown
that
we
should
not
be
so
much
specific.
So
to
avoid
rechartering
every
time
we
have
a
new
idea.
F
The
idea
at
the
time
was
that
there
was
a
fixed
set
of
things
that
needed
to
be
worked
on
that
was
being
brought
in
from
cal
connect
and
we
chartered
it
to
handle
those
items
without
the
without
thinking
that
it
would
be
a
long-running
working
group
that
would
just
keep
processing
new
stuff
over
time.
F
So
I
agree
if,
if,
if
we're
going
to
spend
the
time
rechartering,
we
should
recharter
it
in
the
latter
form
as
a
long-running
working
group
to
deal
with
calendar
stuff,
and
I
think
that
would
be
a
good
idea.
A
F
That
I
I
disagree
with
francesca
that
chartering
is
a
big
deal.
It
should
not
be
a
big
thing
to
do.
You
ought
to
be
able
to
spend
a
reasonably
short
amount
of
time,
putting
together
a
charter
that
describes
what
you
want,
and
it's
not
a
big
process
in
the
iesg.
It
should
take
about
a
month.
So
so
I
I
don't.
I
think
you
should
do
it
because
then
it
gets
you
ready
for
the
future
and.
C
Jim
for
berry,
do
you
feel
that
we
should
recharge
her
now
or.
F
A
personality
this
to
be
a
long-running
calendar
calendar
related
stuff
working
group
that
rechartering
to
make
it
clear
that
that's
what
this
is
is
worth
the
trouble,
because
then
you
will
not
get
issues
from
ads,
saying:
wait:
how
how
does
this
fit
into
your
charter
and
that's
always
a
danger?
If
you
don't
recharter
that
somebody
might
call
you
on.
A
Sedate
being
the
the
date
time,
stuff
yeah,
no,
that's
fine,
and
I
know
one
of
the
chairs
in
that
group.
I'm
sure
I'll
be
fine
with
it
all
right
I'll.
Do
the
first
pass
at
this
daniel
and
and
discuss
it
with
you
sound
good.
A
A
Cool
subscription
upgrade
we
that
we
said
it's
basically
ready
to
go.
Didn't
we
so
yeah.
We
should
be
able
to
submit
that
next
month,
js
calendar
mapping
document
robert.
C
Why
april,
and
not
why
april
not
later
not
before,
is
it
a
specific
day?
I.
C
Okay,
okay,
because
I
I
mean
one
of
the
the
reason
I
am
raising
that
question.
Is
you
mentioned
that
you
need
some
more
deployment?
So,
yes,.
H
Yes,
so
there
are
two
things
to
that
so
for
js
calendar
specifically,
since
we
are
in
the
in
the
progress
of
of
working
with
chamber
calendars,
this
is
also
an
occasion
to
to
finalize
the
mapping.
So
that's
about
the
time
frame,
I
was
looking
at
to
get
that
done.
Okay,
good.
A
All
right
calendar
series
mike
yes,.
A
A
It's
set
for
march
2022,
which
is
already
off
in
the
future,
but
is
that
too
aggressive?
It
probably
is
given
that
I
haven't
had
a
chance
to
even
look
at
it
for
the
last
few
months.
Let's
kick
it
to
july.
That's
slides.
E
A
At
the
next
itf
and
ditto
server
side
subscription.