►
From YouTube: IETF113-CALEXT-20220322-0900
Description
CALEXT meeting session at IETF113
2022/03/22 0900
https://datatracker.ietf.org/meeting/113/proceedings/
A
Hello,
daniel
good
morning,
yes,
one
of
those
good
morning
good
afternoon,
it
is,
I
think
I
generally
count
5
a.m
as
being
more
morning
than
night,
but
it
is
it's
certainly
on
the
cusp.
Isn't
it
it's
hard
to
have
to
tell
which
one
it
is
welcome
to
the
calex
session
first
session
of
the
day
here
on
tuesday,
at
what
did
I
put
the
wrong
date
on
that?
I
did
there
you
go
that's.
A
It's
still
yesterday,
somewhere
in
the
world
right.
Let's
move
on,
nobody
saw
that
this
is
the
noteworld,
where
I
believe
everyone
in
this
room
is
very
familiar
with
the
noteworld
and
probably
everyone
remotely
as
well.
We
have
a
a
small
but
high
quality
group
of
people
here.
A
So
yes,
note
the
noteworld
some
tips
for
this
one.
If
you're
in
the
room,
please
scan
the
qr
code
or
pop
into
the
data
tracker
and
get
online
in
meet
echo.
Somehow,
that
is
how
you
get
blue
sheeted
and
how
we
know
you
are
here
and
we'll
allow
you
to
speak,
because
if
you
don't,
if
you
don't
follow
the
process,
exactly
there's,
no
speaking
for
you
all
right
some
resources,
whatever
that's
just
on
the
hi
barry,
you
can
talk.
No,
you
can't
here's
the
agenda.
A
As
you
can
see,
it
is
long
and
detailed
with
very
many
documents,
but
this
is.
We
don't
have
to
stick
to
this.
Whoever
feels,
like
speaking,
let
me
know
pop
up.
Do
your
thing.
A
That's
alexi
breaking
protocol
not
standing
in
the
microphone
sitting
drinking
his
tea,
with
no
mask
on
disgraceful
and
giving
me
giving
me
crap
from
the
heckling
from
the
back
row
of
this
room
which,
for
those
of
you
who
are
remote,
is
three
rows
deep.
So
it's
not
very,
not
very
remote.
All
right.
A
Congratulations:
everybody.
We
are
now
the
maintenance
working
group
for
everything,
calendar
contacts
and
and
related
enough
to
to
stick
itself
into
this
pile
as
well.
I
think
everyone's
seen
this
charter,
we
we
say
we're
going
to
be
maintaining
the
existing
standards.
The
important
thing
here
is
that
we
expect
everything
to
be
backwards.
Compatible.
One
thing
that's
come
out
of
this
is
that
any
work
on
I
calendar
or
js
calendar
is
required
to
update
the
mapping
document
and
update
the
other
things
there.
A
So
please
keep
that
in
mind
for
any
documents
that
are
in
progress
or
that
we
do
from
now
on.
We
have
to
make
sure
we
do
both
those
formats,
and
I
suspect
that
the
same
thing
is
going
to
happen
with
vcard
and
jscontact
as
they
come
along
because
it
says
with
the
existing
standards.
It
doesn't
specify
what
specifies,
in
fact,
for
those
those
two
that
we
expect
things
but
yeah
anything
where
we
have
multiple
representations,
we're
expected
to
update
the
model
and
then
update
the
representation
in
both
cool.
A
This
was
basically
just
a
summary
for
for
the
hundreds
of
people
who
came
in
to
check
out
what's
happening
and
who
the
millions
who
are
going
to
watch
this
on
youtube
when
it
goes
viral,
so
welcome
everybody.
Shall
we
move
on
excellent
woohoo
according
to
the
agenda.
A
Let
me
pull
up
my
chair,
slides
again,
the
work
that's
actually
at
the
isg,
which
is
ical
relations
mike
did
you
want
to
say
anything
about.
E
I
guess
I
guess
the
only
there's
I
uploaded
once
you
know
a
small
slide
deck
for
that,
and
because
there's
only
one
slide
for
it
and
there
was
one
remaining
yes,
it's
next,
the
next
one
I
think
yeah
there's
a
section
there's
a
section
where
using
existing
link
relations
and
whether
there
should
be
some
text
to
say
you
really
need
to
write
an
rfc
if
you're
going
to
use
existing
link
relations
to
say
how
you're
going
to
use
them,
and
so
other
people
know
what
you're
doing.
E
There's
no
text
as
such
at
the
moment
other
than
to
say
you
can
use
existing
link
relations,
I'm
a
little
uneasy
about
having
nothing
so
there's
some
suggestion
from
benjamin
suggested
something
of
that
kind
at
the
bottom,
and
I
guess
the
other
question
is:
does
this
need
a
section
on?
Does
it
need
js
calendar
examples.
E
It
sort
of
started
off
before,
and
one
of
the
reasons
for
getting
this
moved
along
is
because
it's
sort
of
used
by
the
js
calendar
mapping
draft.
E
So
so
that's
they're
the
two
questions.
I
think
it's
pretty
much
done
it
sort
of
started
before
the
new
new
charter,
and
it's
so
do
you
think
I
should
I
should
put
in
some
js
calendar
stuff
or
is
it
going
to
be
covered
by
the
mapping
drone
actually.
D
F
Yeah
hi,
I
don't
have
a
like
opinion
about
that,
but
I
just
wanted
to
mention
that
the
isg
is
changing
tomorrow,
so
we
will
lose
some
ballots
and
I
was
hoping
to
kind
of
so.
The
document
is
all
green,
which
means
that
it
could
be
approved,
but
I
know
we're
waiting
for
this
small
update,
and
so
I
was
thinking
of
changing
its
status
to
approve
approved
announcement
to
be
sent
revised
that
he
needed
to
kind
of
like
freeze
the
fact
that
it's
approved,
but
small
changes
are
quite
so
very
nodding
so
yeah.
F
E
Great
yeah,
I
mean
it's
only
a
minor
change
anyway,
so
so
I
think
it
doesn't
really
change
the
any
specification.
G
Hey
this
is
robert
speaking
so
for
link
in
terms
of
link
relations.
I
see
that
we
are
currently
doing
duplicate
work
for
defining
link
relations,
both
in
the
I
js
calendar,
icalendar
mapping
document
and
in
the
in
this
draft.
G
So
we
should
certainly
just
make
sure
that
we're
using
one
of
these
options
and
not
introducing
two
options
to
do
the
same
thing.
Basically,
we
might
come
back
to
this
discussion
when
we
discuss
the
gs
calendar.
I
calendar
mapping
graph
okay,.
A
A
A
H
Do
you
think
mike?
Do
you
think
you
you
will
be
able
to
do
that
this
week,
for
example,.
E
Yeah,
I
think
I
mean
this-
is
the
only
the
only
it's
really
just
adding
this
one
sec
sentence
to
the
to
the
text
and
it
could
just
be
left
as
part
of
the
editorial
process.
So
I
think
it's.
D
H
So
it's
it's
time
aim,
let's
target
that
we
we,
this
draft
is
going
to
be
done
by
by
this
week.
E
Yeah
I
was,
I
was
gonna.
I
was
gonna
put
some
text
in
there
last
night,
but
I
thought
I
might
as
well
leave
it
till
till
with
at
least
a
chance
to
talk
about
it.
A
E
Yeah
I
thought
I
could
do
a
subscription
upgrade.
I
took
I
took
another
look
at
this
and
I
think
I
think
actually
it's
pretty
much
ready.
I
did.
I
did
see,
as
I
say
here,
that
I
was
referring
to
the
wrong
spec,
because
this
has
some
link
relations
uses
link
relations
as
well.
E
So
I
need
to
I
need
to
update
it
to
reference
the
right,
spec
and-
and
I
did
also
notice
that
somehow
the
privacy
section
that
got
its
header
screwed
up,
so
it
got
tagged
onto
the
end
of
the
security
section.
But
apart
from
that,
it
looks
pretty
much.
A
Cool,
so
does
this
sound
like
you
push
a
new
copy
with
that
fixed
and
I
do
a
working
group
last
call
on
it.
E
And
I
can
probably
get
that
done
as
well.
The
next
two
three
days,
fantastic.
A
Well,
we're
making
good
progress
then,
thanks
mike
all
right
next
on
our
list:
let's
do
one
of
the
js
contact
things
so
I'll
pop
up
robert
slides.
G
All
right
so,
let's
discuss
j's
contact
and
the
gs
js
contact
v
card
mapping
drafts
together
next
slides,
please
so
yeah.
G
Both
of
these
drafts
are
now
adopted
by
calyx,
which
is
a
great
thing,
because
now
we
can
can
make
sure
to
be
better
aligned
also
with
the
existing
vcard,
and
I
calendar
vcard
drafts.
G
Scoped
to
the
use
case
of
knowing
how
to
address
a
contact,
so
we
we,
we
were
not
keen
on
reproducing
the
gender
property
definition
of
vcard,
which,
in
our
understanding,
is
not
appropriate
for
for
use
in
terms
of
it
defined
the
biological
sex
which,
and
it
defined
a
free
text
for
gender
and
both
understanding
current
gender
studies.
G
Advancements
are
not
really
appropriate
to
either
know
knowing
how
to
address
a
person
in
languages
that
require
a
grammatical,
gender
and
and
and
also
the
free
text
for
gender,
was
not
deemed
to
be
the
right
approach
and
we
are
waiting
for
defining
gender
identities.
We
are
waiting
for
people
who
have
knowledge
in
this
area
to
come
up
with
an
additional
proposal,
but
that's
not
going
to
be
part
of
the
core
js
contact
specification.
G
What
we
did
defined
was
a
new
property
called
speak
to
us.
The
speak
to
us.
Property
is
scoped
to
define
the
grammatical
gender
and
it
allows
a
free
text
field
for
pronouns,
typically
used
in
english,
like
they
slash
them,
but
it's
really
up
to
the
user
to
to
enter
whatever
they
want
there.
There
is.
No.
This
also
means
that
it's
more
informative
to
the
people.
G
Looking
at
the
card,
it's
not
not
that
useful
for
machines
to
like
like
it's
it's,
it's
not
that
easy,
then,
to
use
this
information
in
an
automated
way
in
in
any
in
any
situations,
but
this
is
what
we've
seen
in
other
proprietary
formats
being
used
as
well.
For
example,
google,
the
google
people
api
also
uses
a
free
text
feed
only
and
we
figured
we
go
with
that.
G
Yesterday
there
were
two
discussions,
so
basically
we
we,
we
didn't
see
any
further
discussion
on
js
contact,
but
yesterday
two
topics
were
brought
up
and
we'll
be
happy
to
discuss
them
here.
Now
one
is
around
there
this
and
these
concern
context
and
labor
properties
in
contact
resources.
G
G
I'm
working
on
an
implementation
at
fast
mail-
and
I
understand
that
also
other
vendors
rodrigo,
for
example-
have
their
already
have
an
experimental
implementation?
So
that's
going
along
well
in
my
understanding
and
we
target
for
for
a
lot
of
working
group.
G
Last
call
before
or
at
the
next
itf
in
philly
next
slide,
please,
the
the
topics
that
came
up
very
recently
is
one
is
the
context
property
so
in
at
a
couple
of
places
in
the
js
contact
properties,
we
have
specific
object,
types
say
for
telephone
numbers
for
online
accounts
for
email
addresses
and
all
these
have
a
share,
a
property
which
is
called
contexts
which
allows
to
define
in
which
context
this
contact
method
should
be
used.
So
the
example
I've
been
giving
here,
you
can
have
a
phone
number
you
can
say
this
is
my.
G
This
should
be
used
for
work
related
stuff
or
for
private
stuff.
At
the
moment
we
only
have
work
and
private.
We,
if
I
recall
correctly,
we
originally
also
had
the
value
other,
but
in
one
of
the
latest
versions
I
removed
all
mentions
of
any
any
enum
value
that
was
called
other,
because
it's
really
it
doesn't
tell
anything
at
all.
So
the
I
now
came
to
understand
that
some
address
book
applications
still
use
this
like
using
a
like
a
a
generic
value.
G
If
there
is
really
not
much
known
else
about
it,
I
do
not
think
we
should
do
that
in
js
contact,
but
I'm
open
for
discussion
what
the
benefits
of
allowing
like
a
catch-all
value
would
be.
G
The
options
that
are
on
the
table,
of
course,
are
to
extend
the
enum,
which
would
then
also
go
through
ayanna,
at
least
for
the
ones
that
we
don't
define
in
in
the
course
back
or
if
we
really
should
just
allow
a
free
text
value,
with
the
benefit
of
being
that
people
are
really
able
to
put
in
whatever
they
want.
But
of
course
that
might
degrade
interoperability.
G
So
I
don't
know
if
there
are
opinions
around
here.
Alexi
did
you
want
to
pop
up
here
in
the
key.
C
Yeah,
hello,
alexis
monica
good
question:
what
are
the
other
values
that
people
do
want
to
use
it
for
other
than
work
and
private.
G
Yeah,
that's
that's
the
main
question
at
the
moment.
I
I
don't
know
that's
why
we
restricted
it
to
work
in
private
if
there
are
other
use
cases,
of
course
we
can
add
them
to
the
spec
now,
but
most
maybe
we
will
never
be
able
to
catch,
to
identify
all
situations,
and
so
the
question
then
is:
should
we
expect
implementers
to
register
the
new
enum
at
diana,
or
should
we
just
allow
to
put
in
everything?
C
Yeah,
I
would
like
to
try
to
find
out
what
people
using
other
form
at
the
moment.
No
is
it
because
you
know
like
yeah,
we
can
add
the
iron
registry,
but
if
it's
unclear
whether
it
will
ever
be
extended,
what's
the
point-
and
you
can
just
defer
it
until
the
point
when
you
know
that
you
need
extra
values,
but
if
you
know
now
or
suspect
now
that
it's
a
you
probably
will
need
to
extend
them
just
to
the
registry,
so
I
hope
it
helps
cool.
Oh,
we
got
a
whole
list
here
here.
Okay,.
I
Hi,
I'm
yours
yeah
for
us
it's
just
we.
We
saw
that
in
several
systems
that
they
are
currently
using
other,
and
it
might
be
a
more
generic
question
how
to
map
that
to
js
contact
as
long
as
the
the
information
as
long
as
it's
possible
to
transfer
it
to
js
contact
and
back
to
vcards
doesn't
necessarily
need
to
be
an
official
value,
maybe,
but
just
it
should
be
mentioned
somewhere
in
the
in
the
conversion.
Spec
a
question
to
that
please!
So
if
these
applications
allow.
G
Since
the
context
is,
I
think,
optional
in
js
contact,
if
not,
it
should
be,
then
a
non-existing
context
would
be
would
map
to
other
in
in
in
other
applications
or
of
application
formats.
Actually.
G
Okay,
what
of
course
would
be
very
interesting,
is
if
there
are
contexts
that
we
can
like
that,
are
scoped
to
some
specific
context.
That
would
be
really
interesting,
but
yeah
for
other.
I
would
just
say
the
absence
of
context
describes
it
as
good
as
yes.
B
G
No,
maybe
I
I
so
what
I've
tried
to
say
is.
We
should
register
enums
at
iana
that
can
be
extended,
but
I
wouldn't
say
that
I
mean
free
texts.
Registering
at
diana
doesn't
make
sense.
So
I
I
wanted
to
say
either
it
should
be
an
extendable
list
of
enums,
but
the
extension
must
go
through
the
regular
iana
registry
process
of
adding
another
value,
or
it
should
be
a
free
text
value
that
at
json
level
it's
going
to
be
a
string
value
either.
A
B
Right
so
that's
fine,
I
mean,
I
think
the
right
answer
is
to
have
the
context
registered
with
ayanna
with
specification
required.
Yes,
yes,
that's.
J
All
right,
hello-
this
is
here
so
maybe
to
shed
some
light
on
this
other
thing
a
little
bit
from
what
I
know
so
historically,
I
think
it
was
exchange
introducing
this
word
home
other,
so
they
just
have
three
fields
for
addresses
for
email
for
everything.
J
So
that's
the
scheme
they
just
had
and
a
lot
of
systems
followed
that
approach,
yeah
and
then
some
systems
came,
I
think,
maybe,
for
instance,
google
started
with
that
like
they
resolved
all
that
and
allowed
you
to
do
more
than
three
email
addresses
more
than
three
postal
addresses
and
so
on,
and
they
basically
came
on
with
a
more
or
less
free
form
context
thing
yeah.
So
you
could
basically
define
everything
so
the
question
now,
if
we
need
in
terms
of
together
with
work
and
home
other
yeah,
actually
it's
not
really
defined.
J
It's
just
legacy
thing,
because
there
were
just
those
three
fields.
Yeah,
my
point
would
be.
There
is
a
lot
of
applications
based
on
that
a
little
bit,
because
it's
long,
it's
there
for
quite
some
time,
so
that,
in
my
opinion,
would
be
maybe
one
reason
to
consider
this
as
a
as
a
standard
field.
As
well,
because
it's
super
established
in
a
lot
of
applications
already,
that
is
for
the-
why
there
is
other.
Also
I
mean
there's
not
so
much
magic
beyond
that
around
it.
J
You
know
standard
model
of
those
three
context
properties
baked
in
to
your
second
question
with
the
hana
registry,
I
would
probably
say
in
my
opinion,
I
mean,
as
far
as
I
know,
for
instance,
if
you
do
it
in
in
google
or
something
like
that,
you
can
even
add
free
form,
connect
properties,
and
I
think
people
use
it
more
like
a
keyword
thing
or
something
like
that,
so
probably
a
hana
registry
to
do
it
really
formally
specify
what
a
certain
value
means
beyond
these
work,
home
and
private
private
work,
private
and
other
probably
over
engineering,
and
make
it
too
slow
as
a
process,
because
I
think
nobody
might
do
the
work
on
submitting
it
to
a
inaudible.
A
G
There
is
for
every
property
in
or
any
type
in,
js
contact.
It
has
a
context
or
contexts.
Actually,
there
is
also
a
free
text
label
field,
and
this
is
and
the
in
in
earlier
drafts.
We
had.
I
think
this
other
context,
but
it
basically
meant,
if
you
write
other
in
here,
put
the
free
text
value
whatever
you
want
into
label,
but
you
can
still
do
that.
G
J
C
J
J
G
Okay,
then
I
suggest
we
go
to
the
next
slide.
Please,
okay
and
that's
that's
bringing
us
to
the
label
property,
so
the,
as
I
said
before,
the
label
is
a
free
text,
value
that
you
can
assign
to
any
contact
method.
G
It's
basically
meant
to
to
accommodate
for
the
use
case
that
in
several
applications
you
can
like
add
additional
information
like
a
free
text,
value
to
a
telephone
number
or
whatever,
and
the
expectation
is
that
usually
this
will
be
used
by
applications
to
display
to
the
user,
so
it's
more
informative
to
user,
rather
than
informative
to
the
implementations.
G
However,
the
current
js
contact
vcard
mapping
document,
uses
under
some
circumstances
the
labor
property
to
contain
information,
that's
relevant
for
mapping
between
js
calling
the
js
calendar
and
icalendar.
So,
notably,
if
you
have
a
cal,
uri
property
in
vcard
that
defines
the
calendar
address
for
this
contact,
then
that's
currently
mapped
with
the
label
property
set
to
cal
uri.
G
G
So
I
would
suggest
that
we
not
use
the
label
property
for
defining
any
mapping
related
information,
because
that's
really
useful
for
the
machine,
but
not
useful
for
the
for
the
for
the
for
the
user.
So
we
should
rather
extend
the
type
enumeration
values
if
uri
is
too
generic
to
convey
the
specific
type
of
to
convey
the
specific
type
of
of
of
uri
or
the
context
where
it's
used,
the
alternative
would
be
a
sub-type
property,
but
that
might
go
too
far
in
my
under.
G
In
my
opinion,
however,
this
shows
that
there
is
the
necessity
since
we
are
mapping
a
couple
of
vcard
of
distinct
vcard
properties
into
the
same
object
type
in
in
js
calendar
and
and
using
the
label
in
the
current
mapping
document
clearly
shows
that
we
are
lacking
a
way
to
convey
to
to
to
keep
the
information
which
property
was
mapped
to
where
so,
I'd
rather
suggest.
G
We
look
into
defining
a
january
scheme
where
we
can
define
for
for
these
situations
which
property
mapped
to
where
this
could
be
an
extension
property
on
on
the
js
calendar
object
type.
Sorry,
the
js
contact
object,
type
which,
like
tells
okay.
I
came
from
this
vcard
property
or
probably
we
come
up
with
other
schemes,
but
I
would
say
I
would
not
use
free
text
values
to
to
to
use
that,
especially
not
something
that's
shown
to
the
user.
Any
opinions
on
that.
I
strongly
agree.
G
Instructions
separate
okay,
so
what
it
shows
that
we
are
lacking
this
this
this
way
to
keep
information
for
the
mapping,
and
this
we
have
the
exact
same
situation
in
chairs
calendar
anyway.
G
A
G
I
mean
the
next
important
step
is
to
to
do
interop
testing.
I
don't
know
if
that,
if
that
should
be
a
step
within
itf
that
we
should
track.
G
Yes,
I
think
that's
next
month
already,
so
we
might
not
be
ready
to
do
that,
though
cool
it's
may.
Okay,
that
could
work.
A
E
Nothing's
happening,
oh,
you
did
that
amazing
technology.
Isn't
that
great,
so
the
the
when
we
when
we,
when
we
were
originally
putting
this
this
this
spec
together,
we
were
still
frightened
of
using
new
components.
Some
reason-
and
I
was
taking
a
look
through
it
once
I
resurrected
this
thing
and
realized
that
a
lot
of
the
stuff
we've
done
was
to
try
and
group
properties
together.
E
E
So
it
I
decided
to
invent
a
v
status
component,
which
would
be
a.
We
should
encapsulate
information
about
about
a
status
and
probably
the
three
main
things
is
is
to
have
with
that
would
go
within
a
v
status.
Are
the
current
status
property
most
likely
a
comment,
because
that's
what
it
was
largely
about
is
what
what
happened,
what
why
did
the
status
change
or
whatever
and
a
and
a
dates
down?
E
There
could
be
other
other
properties,
but
those
are
the
main
ones
that
we
were
trying
to
group
together.
The
idea
with
with
this
all
these
updates
was
originally
was
to
try
and
express
things
that
go
on
in
in
in
processes
and
tracking.
This,
in
particular
interest
for
the
the
other
author
was
was
of
cm
because
he's
dhl
was
was
tracking
packages
and
things
of
that
kind
through
a
system
so
so
I've.
E
I
actually
added
a
v
status
property
to
the
last
one
I
published,
and
this
is
largely
what
what
is
likely
to
change
as
a
result-
and
mostly
it's
did
I
jump
to
there.
No,
we
had
a
reason
parameter,
which
was
indicating
why
there
was
a
change
in
status,
so
that
could
be
a
new
property.
I
was
sort
of
toying
in
my
mind
over
the
last
couple.
E
Would
that
just
be
a
summary,
or
could
we
actually
have
a
new
reason
property
for
tying
these
things
together
in
with
an
attendee,
I
think
the
thing
to
use
there
is
the
participant
component
and
the
what
was
the
event
pub
draft
and
a
comment
on
the
rfc,
which
defines
the
participant
component
has
a
way
of
tying
it
to
the
attendee.
So
you
can
sort
of
add
metadata
about
attendees,
though
that's
already
covered.
So
if
we
invent
a
new
reason
property,
you
should
just
be
free
text.
E
I
think
that
covers
what
was
being
done.
This
draft
it's
it's,
certainly
simpler
in
pro
in
concept.
I
did
wonder
the
summary
meant
the
same
thing,
but
I
don't.
I
don't
think
it's
quite
the
same
thing.
E
This
seems
to
be
there's
a
delay
or
I
don't
know
here
we
go
and
in
the
text
of
the
thing
it
defines
the
idea
of
a
substate
parameter
and,
and
has
some
text
around,
that
I
think
again,
that
would
just
be
turned
into
into
a
property
to
go
inside
the
v
status.
E
Take
two
presses
and
the
attendee
changes
yeah.
These
are
just
I
mean,
there's
so
many
slides,
because
these
are
partly
my
my
noting
this
stuff
down,
as
I
went
through
the
thing
again,
as
I
said,
with
the
10d,
we
just
use
the
participant
component
and
show
everything
inside
that,
which
means
we
get
rid
of
this
group,
parameter
that
we
were.
We
invented.
E
There
we
go,
we
had
yes
and
we
had
some
changes.
Section
142
was
changed
to
comment
which
to
add
some
of
the
bits
and
pieces
that
were
before
with
grouping.
We
don't
need
that
anymore,
so
that
section
would
just
disappear.
This
way
again,
another
section
that
would
drop.
E
And
that
was
a
quick
first
pass
that
I
shoved
in
there
before
I
put
to
see
what
it
looks
like
it'll
need
some
updating
if
to
add
the
reason
properly,
but.
E
Apart
from
that,
it
greatly
simplifies
the
spec
and,
and
the
other
question
was:
do
we
need
to
do
a
v
calendar
mapping
because
some
of
this
js
canon-
I
think
some
of
this
stuff
is
referred
to
in
the
js
calendar
mapping.
E
So
that
was
another
reason
I
was
trying
to
get
this
thing
moved
along
for
that
and
let's
just
take
two
button,
presses
to
get
something
to
happen,
or
maybe
I've
hit
the
end.
Maybe
that's
the
end.
E
So
that's
that's!
That's
where
my
thoughts
were
going.
It's
adding
the
b
status
just
seems
to
making
it
a
lot
cleaner
and
simpler.
D
This
is
ken
again,
yes
yeah,
so
mike,
if
my
recollection
is,
is
correct.
A
lot
of
those
parameters
were
just
mirroring
properties
at
a
per
attendee
basis,
correct.
E
D
Together
understood
yep,
basically,
I
was
going
to
say
I'm
all
in
favor
of
moving
these
per
participant
parameters
into
properties
within
participant
itself
and
same
thing,
with
v
status.
D
As
far
as
where
to
put
the
mapping
my
gut
is
we
should
this
is
we're
gonna
have
some
churn
on
this
draft,
so
my
gut
is
to
put
the
mapping
in
this
draft
and
pull
it
out
of
what
robert's
currently
working
on
or
you
and
robert
are
currently
working
on.
So
at
least
we
have
a
example
of
how
future
specs
need
to
include
a
mapping.
E
G
E
G
That
what
that
is
what
I
would
appreciate
and
I
would
rather
say
the
the
general
mapping
of
the
participant
component
to
js
calendar
and
the
other
way
around
should
be
in
the
js
calendar.
Icalendar
draft
that
we
are
working.
D
G
E
E
Yeah
my
concern
when
I
started
on
the
work
with
the
js
calendar
mapping
was:
I
realized
that
we
were.
We
had
something
that
was
related
to
this.
This
spec
and
I
didn't
want
to
see
us
end
up
hanging
around
waiting
for
this
spec
or
having
to
pull
stuff
out.
So
I
think
I
think
they're
going
to
move
along
together,
we'll
figure
out
any
okay,
great.
H
All
right,
yeah,
one
thing
I'd
like
to
to
avoid
is
that
the
mapping
introduced
in
the
ical
gs
format,
translation,
some
complexity,
so
that
when
we
read
the
main
document,
we
don't
really
understand
where
this
complexity
come
from.
So
but.
H
That's
that's
the
only
thing
I'm
I'd
like
to
avoid,
but
a
lot
of
I
mean
a
lot
of
the
reference
should
be
from
the
main
document,
which
is
the
ical
gs,
but
I
suppose
we
will
still
have
some
small
adaptation
or
things
like
that
in
that
document,
in
the
task
document.
A
Yeah,
I
I
would
like
to
see
us
reach
a
point
fairly
soon,
where
we
have
every
everything
in
js
calendar
representable
in
our
calendar
and
vice
versa,
and
this
document's
certainly
part
of
that
and
then
get
to
the
point
where
all
new
documents
just
define
both
and
we
don't
have
to.
We
don't
have
a
separate
mapping
stage
happening.
So
the
question
really
is
how
many
documents
do
we
need
to
complete
that
we
we
reach
that
milestone
where
everything's
everything's
representable
in
both.
E
Yeah,
I
think
that
I
think
they'll
come
clear
as
we
work
through
the
the
things
we'll,
but
I
mean
it's
only.
The
only
thing
it
might
make
sense
to
have
the
the
show
how
the
v
status
component
is
mapped
in
this
spec,
but
we
can
make
that
decision
down
the
road.
A
Cool
all
right,
thanks
mike
anything
else
on
this
document.
What's
our
expected
next
step
timing
here.
E
I
I
think
that
the
first
thing
I
can
do
is
is
is
is
make
those
changes
I
I
outlined
is:
is
drop
the
the
group
and
modified
parameters
and
create
add
a
reasoned,
a
reason,
a
reason,
property
and
then
redo
the
the
spec
along
those
lines
which
shouldn't
take
very
long
and
I
could
bring.
I
could
I
could
publish
that
draft
and
then
we
can
move
from
there.
E
H
A
A
Looking
back
at
the
agenda,
we've
moved
through
very
fast,
so
far
we're
what
47
minutes
in
we
have
we've
done
the
js
contact
work.
We've
got
js
calendar,
I
calendar
still
to
go,
and
then
there
was
I
calendar
series
and
server
side
subscription
and
vpol
are
drafts
in
progress,
but
I
don't
think
we
have
slides
for
all
of
those,
so
we
might
skim
over
the
remaining
ones
at
the
end.
G
All
right
so
yeah,
like
the
previous
discussions,
already
have
shown,
we
quite
have
the
need
for
defining
finally
defining
on
how
to
map
the
gs
the
rfc8984
to
I
calendar
and
that
it's
not
being
done
is
to
a
good
part.
Also
on
me
that
I
didn't
have
the
bandwidth
to
work
on
it,
but
it
now
it.
G
It
clearly
showed
in
the
last
weeks
already
months,
actually
that
it's
that
we
really
should
get
this
now
out
of
the
door
as
soon
as
possible,
and
that's
now
my
top
priority
to
do
next
slide.
Please.
G
So
before
going
to
the
mapping
we
have,
we
have
an
errata
for
8984.
I
think
I
covered
it
on
the
next
slide.
We
have
implementations,
experimental
implementations
of
the
mapping
in
cyprus,
imap
and
betawork
in
cyrus
imac.
We
actually
have
two
mappings,
the
the
one
that
proprietary
mapping
using
lots
of
x
properties
in
icalendar,
that's
very
stable,
but
of
course
not
the
thing
we
want
to
keep
for
the
future,
and
there
is
an
experimental
mapping.
That's
not
yet
complete
that
I'm
working
on.
G
For
the
mapping,
we
now
have
a
better
understanding
on
where
we,
where
the
formats
are
lacking
to
map
in
one
or
the
other
direction,
and
I'm
going
to
present
quite
a
number
of
properties
that
we
want
to
introduce
for
either
icon.js
calendar
today,
and
apart
from
that,
we
do
have
the
need
to
still
then
decide
on
how
to
map
properties
for
for
which
there
is
for
which
we
have
no
specific
mapping
defined.
G
Mainly
that's
going
to
be
the
x
properties
that
we
see
might
see
in
icalendar
and
it
and
the
equivalent
of
those
are
the
vendored
properties
in
the
vendor
extension
properties
in
js
calendar,
which
look
like
like
a
domain
name
controlled
by
the
vendor,
slash
and
then
the
property
name.
G
We
definitely
need
to
come
up
with
something
to
map
these,
and
that's
also
what
has
been
discussed
before
already
shortly
for
vcard,
where
we
have
the
exact
same
need
next
slide,
please
so
the
rata
very
shortly.
There
was
a
mistake
in
the
definition
of
so
let
me
step
one
one
step
back
so
in
by
default
a
js
event.
G
The
properties
of
a
chase
event
all
are
visible,
but
you
one
can
define
js
event
to
be
private,
in
which
case
only
a
subset
of
the
of
the
properties
are
visible,
namely
there
is
no
information
included
which
conveys
the
the
contexts
or
meanings
of
this
event.
It's
more
that
you
know
when
it
happens,
but
you
don't
know
very
much
more
than
that
and
we
there
is
a
list
of
properties
that
can
be
shown
for
private
events.
G
G
We
mistakenly
constrained
that
events
that
have
a
recurrence
id
set
so,
which
are
an
instance
of
a
recurring
event,
must
have
a
recurrence
id
timezone
set,
but
that's
wrong
because
an
occurrence
is
an
instance
of
a
of
a
recurring
event
in
floating
time
still
is
in
floating
time.
There
is
no
time
zone
bound
to
that.
So
these
are,
I
don't
know
about
this
exact
status
of
these
if
they
are
like
accepted
already
or
yeah.
G
Yeah,
thank
you
yeah
any
comments
on
the
errata.
G
I
guess
not
so
then.
Next
slide,
please
all
right-
and
this
brings
me
now
to
a
couple
of
property
definitions
that
we
would
want
to
discuss
that
have
been
shown
to
be
lacking
currently
in
the
js
calendar
icalendar
mapping.
So
the
first
thing
is
the
geoproperty.
In
icalendar,
the
property
in
icalendar
is
defined
to
be
two
float:
values
specifying
latitude
and
longitude
separated
by
a
semicolon.
G
G
The
alternative
would
be
to
do
not
extend
the
value
type
of
a
geoproperty
and
keep
it
with
the
two
floats,
but
at
the
high
fidelity
resolution
in
the
alt
wrap
parameter.
J
So
this
is
jerk,
so
it's
basically
a
question
if
I
understood
it
correctly,
so
what
you
propose
is
in
order
to
have
some
mapping
set
up
to
retrospectively
modify
the
icon
on
the
spec
in
order
to
be
able
to
use
a
more
rich
geo
representation
within.
I
can
alright,
yes,
okay,
I
mean
I
would
have
a
little
bit
to
concern
your
race
by
yourself
with
respect
to
back
backwards.
J
Compatibility,
and
my
question
would
be:
isn't
it
just
possible
to
you
know,
derives
the
value
for
the
legacy
geo
property
within
I
calendar
from
that
more
rich
presentation.
G
D
G
One
dimension
more:
it
also
allows
to
explicitly
define
the
coordinate
reference
system.
That's
the
crs
parameter,
and
it
also,
for
example,
allows
to
set
the
uncertainty.
So
it's
like
a
40,
that's
actually
the
address
of
a
church
in
vienna,
okay,
which
has
like
a
40
meter
radius.
J
G
B
So
this
is
barry
the
the
problem
with
you
can
add
another
another
parameter,
another
field,
whatever
that
that
lets,
you
specify
the
richer
information.
I
don't
think
it's
worth
it.
I
think
it's
better
to
break
the
backward
compatibility
in
this
case,
yeah
yeah.
C
Yeah,
I'm
also
in
favor
of
your
eyes.
That
seems
just
it's
also.
The
way
you
extend
it
is
a
is
a
genetic
way.
You
extend
other
properties,
so
I
mean
it's
kind
of
in
spirit
of
original
format,
right
so
yep.
As
far
as
I,
I
think
saying
that
it
has
to
be
jio.
Uri
is
probably
fine,
but
maybe
not
saying
completely
that
you
know
nothing
else
can
ever
been
be
used
there
in
the
sense
of
you
know.
Who
knows,
maybe
somebody
invents
a
better
uri
representation
for
this.
G
F
A
J
Okay,
final
remarks
that
bringing
a
little
bit
of
the
devil's
advocate
so
since
you're
arguing
not
so
many
people
are
using
it
anyway,
yeah,
so
why
you
know
doing
the
effort
of
you
know
even
improving
it
in
a
way
I
mean.
G
Well,
I
think
if
we
do
that,
we
might,
it
might
get
even
used
more
than
it
currently
is,
for
example,
apple,
have
their
have
a
next
property
x,
appreciate
location
which
basically
is
like
when
you
use
their
clients,
and
you
select,
you
give
it,
you
enter
an
address
and
it
picks
it.
On
the
apple
maps,
that's
going
to
be
a
geo
uri
in
the
x
approach,
structured
location,
so,
okay,.
A
I'll
put
myself
in
the
queue
here,
because
I
have
a
question
upper
layer
here.
This
document
is
currently
slated
to
be
an
informational
draft.
So
if
we
are
planning
to
update
anything
in
our
calendar,
we
might
need
to
do
a
proposed
standard
level
document
defining
those
changes
to
icalendar
as
a
separate
document.
So
is
that
the
intention
here
just
to
do.
G
A
B
This
is
barry
being
as
I'm
yeah
being
as
I'm
in
the
queue
I'll
just
I'll
comment
on
that.
I
think
it
should
be
standard
standard
track.
The
the
other
thing
about
usage
of
the
field
is
that
if
we
had
this
more
detailed
information,
I
would
I
would
make
more
use
of
it.
B
So
I
can
support
that
what
what
robert
just
said,
because
well,
for
instance,
I'm
I
don't
want
to
put
my
home
address
in
my
id
card,
but
if
I
could
use
the
uncertainty,
I
would
be
happy
to
put
it
in
with
a
broad
level
of
uncertainty
that
that
just
got
it
into
my
town
without
giving
me
the
specific
address.
So.
G
Yeah
all
right,
so
then,
let's
see
we
go
to
the
next
property,
please,
which
is
the
chainmap
id
property
and
parameter
so
the
chain
map
course
base
specifications
defines
the
id
type
and
the
id
type
is
restricted
to
base64
url
characters
with
a
given
with
the
maximum
length
of
255
octets,
and
we
currently
do
not
have
a
standard
way
to
preserve
these.
G
In
icalendar
icalendar
has
the
notion
of
using
uids,
typically
for
unique
identifiers,
but
the
unit
uid
property
is
defined
as
a
utf-8
text,
value
of
any
length
and
any
characters
so,
and
we
typically
see
these
also
being
non
chip
id
strings
in
in
practice.
So
a
couple
of
implementations,
for
example,
append
to
each
uid,
they
append
their
their
domain.
G
G
So
we
are
going
to
need
a
way
to
keep
the
chain
map
id,
which
typically
are
only
which
are
always
only
scoped
within
a
jmap
object
like
if
you
have
three
locations,
they
could
be
called
location,
one
location,
two
location
three
in
chain
in
in
chase
in
a
chase
event,
so
we
want
to
preserve
these,
and
the
suggestion
is
that
we
allow
that
we
lose
both
properties
and
parameters
that
have
this
exact
same
requirements
as
a
chemical
specification
and,
for
example,
as
you
see
in
the
example,
this
is
coming
from
an
idea
how
to
map
this
to
a
relocation.
G
G
All
right,
the
content,
id
parameter
so
in
js
events
or
js
calendar
objects.
It's
also
gs
task.
We
have
link
objects,
a
link,
yeah
a
link
is
basically
an
attachment
to
the
to
this
up
to
this
js
event.
G
For
example,
in
js
events,
we
have
we
allow
the
text
description
of
a
js
event
to
not
only
be
plain
text,
but
also
to
be
html
or
any
any
subtype
of
the
text
mime
type
actually,
especially
for
html,
though
we
tried
to
replicate
in
js
calendar,
what's
being
done
in
my
messages
with
content
id
so
that
you
can
have
that
you
can
in
an
html
text,
can
reference
a
content,
an
attachment
by
content
id
to
embed
the
html
and
for
js
calendar.
G
G
Oh
yeah
and
we
suggest
to
allow
this
to
be
attached
to
attach
and
image
properties
mike,
I'm
not
sure
if
that
should
also
go
on
a
link
properly.
Probably
I
don't
know
up
to
you
will.
E
No
I'd
have
to
dive,
look
at
the
speck
and
think
about
it.
Okay,.
G
Any
other
thoughts
on
that
great
so
then
continue.
Please.
A
Cool
alexia-
and
I
will
probably
be
coming
along
and
trying
to
attack
a
digest
in
here
as
well
with
our
large
file
thing
so
that
you
can
have
a
url
and
a
digest.
So
you
can
say
fetch
it
from
over
here,
but
here's
what
it
should
be.
G
All
right-
and
that
brings
us
to
what
has
been
brought
up
already
in
the
relations
draft,
where
I
said
we
might
risk
duplicate
work
here.
So
again,
the
link
object
in
a
js
calendar
object
has
a
rel
parameter,
which
is
restricted
to
the
to
the
same
iana
registered
link
relations
that
are
currently
used
in
html
contexts.
G
So
the
really
link
relation
parameter
that
we
propose
here
is
is
again
attached
to
an
attach
or
image
properly
to
keep
that
information.
I
do
see
that
the
link
rel
parameter
that
you
introduced
mike
in
the
relations
document,
allows
for
more.
It
also
allows
the
value
to
be
a
uri
or
the
hard-coded
value
source.
G
So
I
do
not
know
how
we
best
handle
that,
if,
if,
if
we
go
with
the
link,
rel
definition,
which
could
be
perfectly
fine,
we
would
need
to
update
the
js
calendar
link
object
that
the
rel
values
are
not
restricted
only
to
the
registry
defined
in
a288,
but
I
do
not
know
if
the,
if
that's
appropriate,
because
the
source
string
value
relation
seems
to
be
very
explicitly
defined,
that
the
link
is
the
event
that
this
relation
is
linking
to.
G
E
I
I
mean
the
the
point
of
of
the
link
relations.
Is
they
point
to
metadata
about
the
about
the
object?
That's
that's
doing
the
pointing
so
in
the
in
this
case,
this
is
just
adding
a
link
relation
which
says
this.
This
is
where
the
the
event
was
derived
from.
This
is
the
source
of
the
event,
it's
a
particular
kind
of
relationship,
and
if
you
look
through
all
the
link,
relations
they're
all
they're,
all
like
that-
and
in
fact
eight
eight,
two
eight
eight
is
where
it
defines
the
idea
of
using
uri.
E
No
no
related
related
to
point
very
specifically
used
uids.
E
E
I
I
very
explicitly
said
in
the
in
the
in
to
draft
that
you
don't
use
a
link
relation
to
to
handle
what
we
treat
as
attachments
now,
specifically
because
attachments
are,
are
not
metadata
as
such
they're
just
a
they're
they're,
a
bunch
of
data
like
the
agenda
or
something
like
that
attached
to
the
to
the
to
the
event
and
there's
this
whole
thing
about
managed
attachments
in
in
which
which
sort
of
puts
makes
puts
them
on
a
different
level.
E
Okay,
so-
and
I
don't
know
how
that's
going
to
be,
you
know
I
mean
the
question:
is
how
that's
going
to
work
in
js
calendar?
What
happens
if
you
have
a
huge
object,
pointed
to
by
a
link.
G
Yes,
it
sounds
to
me
as
if
the
the
link
property
and
the
link
rel
parameter
defined
in
the
ical
relations
draft
is
something
that
it
might
be
currently
missing
in
3s
calendar
so
that
we
might
need
to
introduce
new
properties
to
the
gs
calendar
in
as
part
of
publishing
the
iq
relations
draft
probably-
and
we
might
then
need
to
figure
out
if
the
link
rel
parameter
should
get
another
name,
because
it
obviously
means
something
else.
Then
the
relation
parameter
proposed
here
right.
G
I
mean
the
alternative
would
be
to
define
just
the
link
rail
or
the
link
relation
parameter,
whatever.
The
name
then
is
with
the
value
types
that
is
required
for
the
relations
ical
relations
rfc,
but
restricting
the
values
that
make
sense
for
a
js.
Can
the
link
object
to
the
ones
defined
at
iana,
for
I
say,
actual
link
relations
in
in
the
meaning
of
what
rfc8288.
G
Yes,
the
js
calendar
spec
currently
defines
for
link
object
for
the
rel
property
to
be
restricted
to
the
values
defined
by
the
link
relations
rfc,
the
88288.
I.
G
No,
I
see
that
in
the
in
the
draft.
It
defines
also
it
allows
the
values
of
eight
to
eight
eight,
but
it
also
allows
the
value
to
be
a
new
uri
or
to
be
the
hard-coded
string
source.
If
I
misread
it,.
E
G
Okay,
great,
then,
that
that
solves
that,
so
the
only
remaining
value
not
covered
in
js
calendar
for
rel
would
be
a
generic
uri.
E
And
I
think
I'd
have
to
look
back
at
8
28,
but
I
think
I
think
in
eight
to
eight
eight,
it's
that's
that's
how
it
recommends
you
specify
an
unregistered
link.
Relation
okay,
okay,
I
mean
I,
I
was
pretty
much
following
the
the
eight
to
eight
eight
spec.
G
Okay,
then,
then,
I
might
have
seen
an
issue
that
is
not
an
issue
so
in
in
any
case,
we
should
just
introduce
one
parameter
and
not
have
two
doing
the
same
thing.
Yeah.
E
The
link
real
parameter
could
be
used
elsewhere.
It's
just
that.
I
I
I
think
we
need
to
look
at
how
this
is
gonna
work
with
things
like
managed,
attachments,
okay
and
that's
more
a
matter
of
of
looking
back
at
js
calendar.
I
guess,
because
that
that
sort
of
got
got
ignored
in
that
there's,
no
special
attachment,
you
know
object.
So
how
do
you
figure
out
that
you
need
to
actually
manage
it?.
G
Yes
agreed,
so
if
it,
if
the
link
rail
parameter
then
comes
with
the
iq,
if
the
iq
relations
document
is
published
sooner
than
the
js
kind
of
the
icon
mapping,
then
then
you
just.
K
I've
got
the
spec
in
front
of
me
now,
linked
with
the
relevant
enclosure,
must
be
considered
by
the
client
to
be
attachments.
So,
specifically
that
kind
of
link.
E
G
Okay,
great,
so
in
my
understanding,
if
ever
there
has
been
an
issue,
it's
solved
now
anyway,
so
let's
continue
to
the
next
slide.
Please.
G
So
they're
related
to
property
that
we
have
already
in
icalendar,
we
in
js
calendar
we
have
a
location,
object,
type
and
the
location
object
type
can
can
also
define
if
it
relates
to
the
start
or
end
of
the
embedding
object
that
being
either
an
event
or
a
task.
G
G
The
alternative
thought
could
be
if
if
one
could
define
any
temporal
relation
in
between
started
and
two,
that
would
then
deviate
from
what's
currently
defined
in
js
calendar,
but
it
might
if
there
is
the
need
to
define
for
a
location
that
it
that
it
relates
to
sometime
in
between
the
start
and
the
end
of
the
event.
G
If
you
have
like,
I
don't
know,
I
don't
know
how
to
say
in
english,
like
a
schnitzel
act
like
if
you
are
like
running
around
and
collecting
clues
for
a
puzzle
you
have
to
solve,
or
whatever
we
didn't
cover
that
in
js
calendar.
G
We
mainly
introduced
the
the
relation
to
allow
an
end
relation
to
be
set
on
a
location,
because
that
would
then
would
be
the
time
zone,
identifier
of
the
btn
property
in
my
calendar,
but
the
question
now
is:
should
we
just
introduce
start
and
end,
or
should
we
extend
the
definition
right
now?
I
don't.
E
G
E
I
think
I
think
it's
it's
it's
simpler
and
it
it
seems
odd,
too
complicated
related
to
for
this
one
case.
G
G
Oh
yeah
and
that's
bringing
up
a
specific
question
that
then
might
later
be
discussed
as
a
generic
question.
So
with
the
relocation
component
and
the
participant
component
in
I
calendar
having
a
uid,
we
we
will
need,
we
might
need
to
introduce
the
uiv
property
also
on
the
location,
participant
objects
in
js
calendar.
G
These
would
be
optional
in
js
calendar
and
if
one
would
map
from
js
calendar
location
to
I
calendar
where
there
is
no
uid
defined
by
the
client,
the
implementation
would
just
generate
a
uid
that
it
from
then
on
uses
for
both
are
there
any,
and
the
generic
question
will
come
up
very
soon
on
the
slides
later
is
how
to
map
how
we
can
typically
map
properties
for
which
we
already
have
a
well-defined
mapping
to
js
calendar,
but
in
other
contexts,
for
example,
we
already
have
a
uid
property
in
in
js
calendar
defined
for
the
for
the
main
for
the
event
and
the
task
and
this
the
question
came
up
during
work
on
the
on
the
mapping
document,
how
we
should
deal
with
well,
let
me
get
back
to
this
then.
G
So,
first
of
all,
are
there
any
any
specific
points
to
discuss
for
uid
in
this
context?
Yeah?
K
K
G
G
G
So
in
js
calendar
the
id
that
we
use
in
the
in
the
in
the
in
the
map
of
all
locations.
Within
that
event,
the
id
only
needs
to
be
unique
within
that
locations.
Property,
whereas
a
uid
property
in
icalendar
is,
is
meant
to
be
globally
unique,
so
they
cover
different
scopes,
and
so
yes,
one
would
expect
a
uid
property
of
location
for
the
same
location.
To
be
the
same,
if
that's
really
done
in
practice,
I
would
very
much
doubt,
but.
G
A
I
mean
I
guess
you
could
take
a
digest.
That's
always
short
enough.
You
can't
guarantee
a
two-way
mapping,
because
the
uid
might
also
be
longer
than
255
characters.
Yeah,
that's
true.
G
And
I
don't
know
if,
because
we
we,
we
discussed
that
the
ids
in
a
js
calendar
event
should
persist
in
the
same
in
the
same
js
calendar
object
instance
at
least
so
I
I
don't
know
if
applications
are
going
to
have
their
own
idea,
what
what
ids
they
generate,
which
might
not
necessarily
then
map
to
a
might
not
necessarily
would
be
a
good
choice
for
a
uid
property
because
it
might
just
not
be
unique
enough
or
something
like
that.
G
So
if
we
keep
them
separate,
I
think
we
have
the
least
friction
when
mapping
between
icalend
and
js
calendar.
A
D
G
The
thing
is,
an
alert
in
gs,
calendar
is,
is
not
as
sophisticated
as
it
is
in
the
alarm,
and
I
do
not
think
that
we
currently
preserve
the
uid
that
there
is
the
need
to
preserve
the
uae
at
all.
We
might
need
to.
I
need
to
check
our
implementation,
what
we
are
doing,
but
then
I
can't
recall
that
there
is
a
uid
property
in
the
in
an
alert
currently
yeah.
D
D
E
G
Yeah
and
this
discussion
leads
already
kind
of
to
the
to
the
next
discussion
point
I
think,
but
let's
if
we
scope
it
just
to
you
eddie
the
more
we
introduce
icalendar
components
that
are
that
have
a
mapping
to
a
js
calendar
object,
type,
be
that
allocation,
a
link,
a
participant.
Whatever
we
will.
G
We
will
always
need
uids
or
also
for
v
alarms.
So
the
question
then
remains:
should
we
define
the
uid
property
explicitly
for
all
these
object
types,
or
should
there
rather
be
allowed
to
be
a
uid
set
on
any
on
any
on
any
js
calendar
type?
Probably
ron?
If
you
could
show
the
next
slide,
please
I
think
that
already
maybe
you
can
skip
this
slide
and
we
get
back
to
this
and
this
because
what
we
would
like
to
discuss
is
currently.
G
There
are
like
different
understandings
how
to
deal
with
properties
and
and
component
definitions
in
icl
energy
is
kind
of
in
js
calendar.
We
explicitly
register
at
iana
an
explicit
list
of
things
allowed
in
an
object.
If
you
want
to
put
more
in
it,
either
register
diana
or
use
a
vendor
extension
properly
in
icalendar
we
for
almost
any
definition
of
a
component.
G
The
last
thing
always
will
be
ianaprop,
and
that
means
you
can
stuff
anything
anywhere
in
a
component.
That's
defined
somewhere
else,
and
we
don't
really
like,
as
you
see
with
uid,
for
example,
we
now
run
in
this
situation
that
there
might
be
stuff
in
an
icalendar
object
for
which
we
didn't
make
room
in
a
js
calendar
object,
and
this
is
going
to
come
up
more
and
more,
the
more
and
more
stuff
we
met.
G
So
I
would
like
to
discuss
the
general
options
that
we
have
to
to
do
that,
maybe
on
the
on
the
next
slide,
I
think
I
I
introduced
a
couple
of
approaches
yeah,
so
the
the
one
thing
is:
whenever
we
see
something
not
being
able
to
map
to
a
jscanda
object-
type,
for
example
the
uad,
we
could
just
define
it
there
or
the
other
way
around,
like
we
did
with
chainmap
id
that's
in
a
way
that
always
will
make
clear.
G
What's
the
exact
purpose
of
this
property,
the
lexan
version
of
that
this
would
be
like
that
we
define
if
there
is
already
a
well-defined
mapping,
for
example,
for
the
dt
stamp
in
a
v
event.
We
mapped
it
to
an
updated
property
in
the
js
event.
G
We
could
say:
okay,
if
the
dt
stamp
shows
up
in
a
v
location,
then
map
that
to
the
to
an
updated
property
of
the
js
calendar
location,
object
type,
although
the
current
spec
doesn't
allow
that
and
that
still,
then,
that
still
doesn't
cover
everything,
because
there
might
still
be
stuff
that
we
don't
know
how
to
map
from
icalendar
to
gs,
canada
and
for
the
for
this
part.
In
any
case,
we
need
to
come
up
with
a
mapping
that
somehow
it
somehow
preserves,
preserves
mapping
related
information.
G
What
was
the
source
of
this
property
if
we
want
to
be
able,
if
we
want
to
be
able
to
always
be
able
to
convert
back
and
forth
between
the
two
formats
and
that's?
The
third
point
is
the
thing
that
also
came
up
before
for
vcard
mapping.
Actually
so,
where
I
said,
we
should
use
the
same
scheme,
whatever
we
use
mike.
I
think
you
you
wanted
to
discuss
this
point
anyway,
or
are
you
yeah?
E
I
I
just
I
I
I
felt
that
it
was
like
to
lead
to
a
more
robust
mapping.
Process
is
if
we
allow.
If
you
recognize
the
property
I
mean
clearly,
I
think
your
example
there
is.
You
know,
dt
stamp
to
to
update
it
somewhere,
you're,
going
to
know
that
if
you
get
a
dt
stamp
you're
going
to
create
a
js
calendar,
updated
property.
E
The
only
thing
we're
talking
about
is
whether
that's
supposed
to
be
allowed
within
the
the
the
the
object
you're
translating,
and
I
I'm
inclined
to
just
allow
it
and
just
just
put
it
in
there.
It
just
seems
a
bit
weird
to
to
turn
them
all
into
vendor
properties.
E
Just
because
you
you
somewhere,
it
says
you
shouldn't
have
that
in
this
particular
object,
because
you're
going
to
end
up
with
the
situations
where
you're
not
keeping
up
with
the
current
state
of
the
registry
and
and
so
something
will
turn
up
with
this
property
in
it,
and
you
won't
in
your
code.
You
won't
recognize
that
supposed
to
be
in
that
in
that
object,
but
it
in
reality.
It
is
it's
just
you're
out
of
date.
E
It.
It
just
seems
more
robust
to
to
allow
these
things
to
to
go
in
there
and
there
were
places
where
back
in
I
calendar,
where
the
the
the
I
think
you
have
of
say,
availability
where
it
has
this
this
construct
it.
It
has
a
certain
number
of
properties
which
which
are
called
out
in
the
spec,
because
they
have
some
particular
meaning
in
the
context
of
availability.
E
And
then
it
says
you
put
anything
else
you
like
inside
there
and
and
the
reason
for
that
was
that
you
might
want
to
say
certain
things
about
that
available.
Time
like
it
has
a
particular
location,
or
it
has
some
other
characteristic
and
and
restricting
it
didn't,
allow
all
sorts
of
use
cases
to
to
you
know.
So
I
I
just
just
feel
we
shouldn't
necessarily
we
should.
If
we
can,
if
we
have
a
mapping
for
the
property,
we
should
just
do
it,
even
if
it's
not
in
the
current
spec.
G
Yes,
I
agree
with
caveats.
I
mean
for
metadata
like
created
and
updated,
for
example,
or
comment-
probably
also
that
that
makes
sense
to
me.
But
somehow
we
need
to
update
the
js
calendar
spec
because
it
currently
would
reject
such
such
properties
as
invalid.
G
The
the
the
type
of
stuff
that
can
go
anywhere,
or
should
we
really
allow
like
okay,
we
just
provide
the
generic
mapping
and,
if
it
ever
shows
up
anywhere,
just
put
it
to
the
appropriate
place.
If
you
don't
know
any
better
like
just
for
an
example,
if
we
find
a
geo
uri
in
and
participant,
we
would
not
map
that
to
a
she
coordinates
property,
probably
in
a
participant.
We
would
map
it
to
a
location,
and
that
is
referenced
as
it
currently
is
possible
by
this
js
calendar
participant.
Then.
E
I
think
there's
the
difference
between
you
know
wanting
to
validate
a
a
an
object.
You
know
a
calendar
object
or
whatever
and
actually
just
accept
it.
So
you
can
process
it
and
strict
adherence
to
what
you
believe
the
standard
to
be
at
a
time
leads
to
problems,
because
you're
inevitably
going
to
get
an
object
that
is
actually
adhering
to
the
spec.
E
It's
just
you're,
not
up
to
date
with
it,
and
somebody
did
raise
exactly
that
problem
on
on
the
ical4j
list,
where
they
they
got
a
property
and
because
they
got
strict
validation
running
on
their
at
their
end.
It
rejected
this
thing
because
it
had
a
property
they
didn't
recognize,
which
is
actually
in
a
spec.
E
So
the
the
because
of
this
I
mean
there
are
ways
to
avoid
having
to
do
all
this
stuff.
If,
as
I
was
saying
to
the
other
day,
part
of
the
reason
for
having
to
do
this
complete
transformation
and
trying
to
get
as
complete
as
possible
is
because
we
have
this.
This
update
by
replacement
thing
going
on.
E
So
I
I'm
inclined
to
just
allow
properties
that
you
don't
recognize
as
being
part
of
the
object
simply
for.
C
I
think
I
tend
to
agree
with
michael
that
it
looks
like
the
original
js
calendar
restriction
is
not
useful
anymore,
or
at
least
you
know
for
interrupt
for
you
know
by
direction
conversions,
so
you
need
some
mechanism
of
converging
arbitrary
properties.
C
C
It
doesn't
seem
practical
yeah,
so
you
need
some
kind
of
variant,
whether
it's
magic
prefix,
like
vendor
extension
or
no
extension,
which
is
what
michael
is
talking
about.
I
think
you
need
a
generic
mechanism.
E
D
This
is
ken
yeah.
I
was
going
to
suggest
that
and
neil
might
throw
up
when
he
hears
my
suggestion,
but
perhaps
we
just
come
up
with
a
json
representation
of
a
generic
high
calendar
parameter,
property
and
component
and
for
everything
we
don't
understand.
We
create
an
object
or
an
array
over
these
particular
things.
G
Yes,
the
idea
of
this
vendor
extension
thing
would
actually-
and
it's.
G
To
to
use
json,
of
course,
as
a
value
but
use
a
gs
cal
so
which
allows
like
a
direct
mapping
yeah,
it's
good.
D
That's
why
I
said
you
know:
neil
might
not
like
my
suggestion:
yeah
but
yeah
jkl's,
fine.
G
Yeah,
so
I
think
the
open
discussion
point
still
is
what
to
do
with
stuff
that
that
we
could
just
map,
because
we
have
the
mapping
defined
already
somewhere
else
so
in
in
the
term
of
we
have
some
generic
well-defined
properties.
As
I
said
off,
the
top
of
my
head
created,
updated
command.
A
That's
tricky
because
if
we,
if
we
don't
register
everything
up
front,
then
you'll
get
implementations
that
do
different
levels
of
quality
of
mapping
here.
Okay,
but
if
we
don't
register,
if
we
don't
have
a
specific
list
of
things
that
are
the
ones
you
should
map,
then
yeah.
The
question
is
what
what
do
you
do
with
and
what
don't
you
do
this
with?
Maybe
we
should
just
say
everything:
that's
not
specifically
defined
gets
this
jkl
treatment,
and
that
way
everyone
will
will
have
the
same
representations.
A
G
Think
for
I
calendar
she
has
kind
of
mapping.
I
think
that's.
I
also
would
like
to
go
with
that
approach.
That
still
leaves
the
point
that
mike
proud
brought
up
like
that
implementations.
Currently,
that
implement,
like
one
snapshot
of
the
state
of
js
calendar
rfcs,
would
reject
js
events
that
use
properties
of
later.
E
It's
the
same.
It's
the
same.
It's
the
same
thing,
whether
whether
whether
you're
doing
a
mapping
or
whether
you're
accepting
js
calendar
into
your
system,
it's
if
it's
a
recognized
if
it's
a
known,
js
calendar
property
when
you're
doing
the
mapping,
then
just
convert
it
to
that
known,
js
calendar
property,
even
if
the
spec
that
the
other
end
is
using,
doesn't
recognize
that
as
being
valid
within
that
object,
you
may
as
well
just
just
put
it
there.
E
Yeah,
if
you
don't
know
about
it,
you
just
ignore
it
yes
and
which
is
sort
of
what
we
do
in
in
our
calendar.
I
don't
think,
there's
a
distinction
between
them
as
us
doing
the
mapping
particularly
and-
and
we
just
do
the
same
thing
there
you've
got
a
property
that
you
recognize
then
map
it
and
the
other
end
will
ignore
it.
C
Just
saying
that,
if
you
need
to
change
the
semantic
from
you
know
ignoring
instead
of
rejecting
unknown
stuff,
do
it
early
do
it
in
a
draft?
So
hopefully
whoever
follows.
The
discussion
now
will
implement
the
new
semantic
if
it
makes
sense
good
as
early
as
possible,
and
then
you'll
figure
out
the
exactly.
G
So
from
what
I
gather
from
this
here
is
that
we
won't
be
able
to
come
to
an
agreement
within
this
session.
There
are
too
many
unknowns,
and
it's
up
to
mike
and
me
to
now
write
up
a
proposal.
G
Well,
I'm
we
are
writing
the
draft
anyway,
already
so
yeah
we
should.
We
should
come
up
with
something
and
then
sent
to
the
list
or
and
or
present
in
the
interim
in
when
is
it
in
may
yeah.
G
Okay
next
slide,
please,
I
think
we
are
yeah.
We
skipped.
G
Yeah,
but
there
are
more
specific
mapping
that
doesn't
need
to
be
discussed
properly,
probably
now
yeah.
So
next
steps
are
in
top
testing
and
or,
as
I
already
wrote,
we
need
to
define
how
to
how
to
to
map
these
new
properties.
G
D
The
given
effect
we're
going
to
change
the
mapping
document
from
informational
to
standards
track
and
we're
also
extending
js
calendar
a
little
bit,
and
we
have
two
errata
already
for
js
calendar
that
perhaps
we
refresh
that
at
the
same
time
we're
doing
the
mapping
and
send
them
to
the
editor
as
a
group
and
then
they'll
have
consecutive
rfc
numbers
as
well,
so
they're
easy
to
find
if
somebody
goes
to
use
them.
Yeah.
E
I
I
raised
this.
I
think
what
the
other
thing
I
suggested
a
fusion
when
we
started
talking
about
the
geo
and
allowing
a
new
uri,
I
was
sort
of
favoring
the
idea
of
splitting
that
out
into
a
separate
rfc,
updating,
5545,
largely
because
it
just
makes
it
more
visible
and
and
the
the
idea
of
using
a
uri
value
for
the
geo
thing
is
something
that
is
of
general
usefulness
just
in
the
icalendar
world.
D
This
is
kind
of
I
stood
back
up
to
say
that
if
we
are
going
to
refresh
js
calendar,
I
would
volunteer
to
be
editor
on
that.
If
no
one
else
wants
to
do
it,
I
know
you
guys
are
already
busy,
and
similarly,
if
we
decide
to
split
out
the
updating
geoproperty
to
take
a
uri,
I'd
also
be
willing
to
do
that.
Work.
Take
that
off
your
guys,
plate.
G
E
G
E
Yeah,
I
think
I
think
so
because
I
I
did-
I
did
create
that
draft
fractional
thing
that
it
was
based
on
on
what
we
originally
talked
about.
But
then
I
realized
part
of
the
problem.
With
the
whole
thing
is
negotiation:
do
you
know
somebody
can
accept
fractional
seconds
or
whatever?
There
is
a
demand
for
it,
but
it's
it's
not
something
that
is
generally
needed.
It's
it's
more
for
people
doing
things
like
process
control
or
things
of
that
kind.
E
So
I
was
more
inclined
to
just
do
that
as
a
as
a
separate
rfc
which,
because
it
touches
on
so
many
things,
is
simply
extend
the
things.
So
you
accept
fractional
stuff
everywhere.
Okay,
but.
D
G
Yeah,
I
generally
agree,
but
it
if,
if
we
don't
have
that,
then
the
conversion
from
gs
calendar
to
icalendar
is
probably
lossy.
E
G
This
sounds
good
to
me,
but
still
yeah.
So
then
we
would
not
be
able
to
map.
E
In
fact,
the
the
yeah,
the
just
kind
of
spec,
is
actually
not
quite
fully
capable
of
doing
fractional
seconds
either
because
there's
something
missing,
I
forgot
what
it
is
now.
A
Okay,
so
just
to
note
down
what
I'm
hearing
here
sounds
like
we've
got
four
documents
in
total:
we've
got
the
sub
second
time.
We've
got
the
update
for
geo
and
potentially
a
couple
of
other
little
bits
and
pieces
for
five
five.
Four
five
we've
got
a
refresh
of
js
calendar
and
we've
got
the
js
calendar,
icalendar
mapping
document
we're
going
to
keep
this
for.
Do
we
refresh
js
calendar
and
put
the
mapping
in
it.
G
D
A
I
don't
have
a
strong
preference
either
way.
I
do
think
that
if
we're
going
to
do
that,
then
it's
probably
not
worth
blocking
tasks
on
having
a
js
calendar
representation
in
it
we're
better
off
doing
tasks,
as
maybe
the
fifth
of
this
series
of
documents
which
is
another
icon
to
update
and
then
do
the
js
calendar
keeping
that
in
mind
and
then
that
becomes
our
alignment
point.
A
Yeah
yeah,
but
if
we're
refreshing
it
anyway,
maybe
we
should
do
the
I
calendar
dot,
just
referencing
our
calendar
and
not
referencing.
That
and
then
have
our
two
js
calendar
documents,
be
the
alignment
point
together
and
then
we
can
make
sure
everything's
fully
aligned
across
those
documents.
Yes,.
B
E
Ahead,
the
the
only
the
only
thing
I
I
raised.
I
raised
a
point
with
robert
the
other
day
that
the
mapping
the
mapping
document
and
and
carrying
out
this
mapping.
It
depends
on
the
context
you're
in
and
I
was
I
was
suggesting.
We
should
have
an
initial
section
in
the
mapping
document.
E
If
you're,
if
you're
doing
imip
the
mapping
can
be
a
lot
simpler
because
you,
you
really
don't
have
to
have
a
full
representation
of
what's
in
the
js
calendar
document
and
the
replies
that
come
back
in
only
the
only
thing
you
need
to
pay
any
attention
to
are
the
parts
that
and
and
other
things.
So,
if
you're,
if
you
have
it,
it
seemed
that
it
might
be
worth
having
an
imp
section,
which
would
be
a
lot
easier
to
do
to
to
do.
G
Yeah,
so
about
that,
I
think
I
would
prefer
a
separate
rfc.
We
didn't
cover
the
scheduling
parts
in
terms
of
the
protocols
involved
at
all,
and
I
think
there's
there's
still
quite
some
stuff.
We
need
to
figure
out
in
there.
So
in
terms
of
timeline,
I
very
much
would
rather
just
define
the
format
mapping
without
any
protocol
specific
editions,
because
otherwise
it
I
have
the
fear
that
it
will
just
drag
on
and
on
as
a
draft,
and
I
think
we
should
get
it
published
to
chase
calendar.
I
killed
the
mapping
as
soon
as
possible.
G
A
All
right,
we
have
10
minutes
left
in
this
session.
Is
there
anything
else
on
this
document
now
or
is
it
keep
working
on
it?
It's
keep
working
on
it.
A
I
think
that's
everything
that
I
had
slides
for,
but
there
were
also
a
calendar
series
server
side
subscription
and
vpol
potentially
to
discuss
mike.
Did
you
have
anything
any
progress.
E
No,
not
not
at
this
stage
v
poll
I'm
trying
to
upgrade
my
implementation,
but
I
think
we
should
just
leave
that
until
next
time,
maybe
other
stuff
will
be
out
the
way
then
so
well.
D
This
is
ken
mike,
rather
than
send
you
an
email
or
text,
or
what
have
you?
I,
I
read
a
service
type
subscription
and
vpol
this
morning
the
example
in
server
side
subscription
is
supposed
to
be
a
make
collection
example,
and
it's
actually
a
post,
so
it
just
needs
to
be
fixed
and
as
far
as
vpol,
I
don't
recall
the
discussions
about
the
actual
pulse
status
method
and
I'm
wondering
why
we
needed
a
separate
method
as
just
as
opposed
as
using
request
to
refresh
the
voters
with
the
current
vote.
D
Do
you
call
why
that
is
at
this
stage?
No
yeah,
because
we
we
send
the
initial
poll
out
with
a
request.
We
send
the
final
result
as
a
request,
but
updating
the
existing
voters
with
the
current
status.
We
have
a
separate
method
which
seems
contrary
to
what
we
do
with
events
where
we
use
requests
for
both
the
initial
event
and
any
updates.
Well.
E
I
think
probably
because
is
it
okay,
I
I
mean
we
we
can.
We
can.
A
All
right:
here's
our
shiny
new
milestones,
submit
task
draft
asg,
that's
the
first
one
on
the
list.
It
was
supposed
to
be
january
this
year.
Where
do
we
think
we're
at
with
that.
E
I
think
so
I
mean
I'll
I'll
make
those
updates
today
outlined
and
resubmit.
Possibly
this
week.
A
B
A
It'll
take
about
that
long.
All
right,
good
subscription
upgrade
was
also
going
to
be
that's,
probably
even
faster,
because
that's
got
less
work
to
do.
Yep,
js,
calendar
mapping
document
that's
a
little
way
down
the
line.
Robert
rough
estimate.
A
All
right
so
july,
jason
contact
same.
A
A
Done
all
right,
anything.