►
From YouTube: IETF114 CALEXT 20220727 1730
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
So,
according
to
to
my
clock,
it
is
time
for
us
to
start
this
session,
so
hello,
everybody,
and
welcome
to
this
this
massively
packed
collect
session.
I
will
just
quickly
flick
through
these
slides
here.
I
think
everyone
in
the
room
has
has
checked
in
to
the
system.
So
that's
all
good.
The
note
well
applies,
I'm
sure
you
have
all
seen
this
and
if
you
have
not,
please
read
it.
I
expect
everyone
will
be
behaving
themselves
perfectly.
A
Hello,
welcome
just
flipping
through
the
the
chair,
slides
here
meeting
tips
we're
about
halfway
through
this
atf
now,
so
most
of
you
have
probably
already
seen
how
to
add
yourself
in
we're
pretty
happy
for
people
just
to
pop
in
and
chat.
I
don't
think
we'll
use
the
queue
unless
we
have
to
but
feel
free
to
pop
yourself
in
the
queue
or
just
pop
yourself
straight
on
audio,
if
you're
remote
good
morning,
neil
and
here's
some
links
handy
links,
but
basically
go
to
the
data
tracker
and
everything's
available
from
the
agenda.
A
B
C
C
So
we
already
had
two
rfcs
in
the
work
js
contact.
O3
is
the
current
version
of
the
js
contact
format.
Specification
js,
contact,
vcard
o2
is
the
specification
for
mapping
between
js
contact
and
vcar
and
as
a
new
addition
we
have
now.
We
are
also
defining
vcard
extensions
for
js
contact,
which
define
new
vcart
properties
and
parameters
that
we
require
for
dgs
contact,
vcard
mapping.
C
C
That
being
so,
what
are
the
main
changes
for
js
contact?
We
clarified
that
the
id
values
that
that
you
use
in
these
options
objects
for
mapping
specific
types
like
addresses
and
others
to
short
identifiers.
These
identifiers
must
be
persisted,
that's
mainly
because
we
want
to
make
patching.
C
Existing
js
contact
objects,
easy
and
it's
way
more
way
more
easier
than
if
you,
if
you
can
rely
on
being
these
ids
being
set
as
you
had
stored
them
on
your
client
or
whatever.
C
We
combined
most
of
them
into
a
resources
property,
but
we
came
to
realize
that
for
some
some
of
these
resources,
we
need
to
specialize
one
of
them,
and
this
is
the
latest
addition,
our
online
services,
so
that
you
can
specify
as
the
service
this
uri
is
for,
which
should
where
the
service
name
should
be
the
canonical
name
of
the
of
the
service
and,
as
I
said
before,
we
now
define
new
vcard
properties
and
parameters.
As
you
can
see,
there
is
there's
the
list
of
current
ones.
C
I
think
there
are
a
few
more
if
not
they
will
get
more
and
some
of
them.
We
will
share
with
the
exact
same
semantics,
between
new
I
calendar
properties
and
vcard
properties.
C
So
I
would
like
to
now
use
the
time
more
to
talk
about
the
stuff,
but
that
we
that
is
currently
in
discussion
and
the
next
slide
starts
with
that.
C
So
for
js
contact
we
in
almost
every
complex
object
type.
We
have
a
label
property.
The
label
property
is
meant
to
is
meant
for
users
to
set
any
any
human
readable
text
they
want
to
set
in
there.
There's
no
semantics
art
in
that.
So
it's
it's
not
expected
that
machines
parse
it
and
extract
values
from
it.
C
Now
that
we
want
to
standardize
this
also
for
vcard,
we
need
to
define
how
a
short
history
on
labels
in
vcard,
so
there
is
already
a
label
parameter
defined
for
the
address
property
in
the
vcard,
which
is
like
really
meant
to
be
like
the
the
label.
You
would
put
in
a
package
if
you
want
to
send
that
package
there,
so
it
contains
delivery
address.
C
Interestingly,
it
the
rfc6350
defines
this
parameter,
but
it's
not
included
in
the
iana
registry.
I
think
that's
just
an
omission,
but
if
somebody
knows
better,
please
let
me
know,
but
also
there
was
already
a
label
property
in
the
vcard
3
rfcs,
but
which
also
were
used
for
delivery
addresses,
but
these
got
obsoleted.
So
at
least
we
now
know
that
the
name
label
for
either
a
parameter
or
a
property
in
vcard
is
loaded
and
most
likely,
we
will
not
be
able
to
use
this
name
for
the
type
of
thing
we
want
to
use
with
jscontact
label.
C
If
we
map
it
to
vcard
or,
as
I
said
before,
already
on
the
next
slide,
there
exists
a
mechanism
for
that,
but
it's
disputable.
If
this
really
is
what
we,
what
the
current
js
contact
label
properly
defines,
and
that
is
apple,
address
books,
so
apple
address
books
since
a
long
time
use
both
vcard
groupings
of
properties
and
the
specific
xab
label
property
to
assign
a
label
to
another
item
or
a
couple
of
items
in
the
nd
card.
So
in
this
case
we
would
have
an
address
with
the
label.
C
My
label,
you
you
can
assign
that
also
to,
I
don't
know,
basically
any
property
that
the
apple
address
books
allow
you
to
define
now,
having
had
a
look
at
how
apple
implements
this
in
their
clients,
for
example,
the
context
app
in
mac
os.
C
C
C
So
the
topic
I
would
like
like
now
to
bring
up
is
how
to
how
to
deal
with
labeling
js
contact
and
mapping
it
in
vcard.
I'm
also
not
sure,
actually,
that
the
jscontact
label
property
necessarily
is
defined
as
how
we
want
it
to
be
defined.
C
As
I
said
before,
it
was
really
motivated
by
mapping
the
xav
labels
from
apple
into
our
structures,
but
now
it
seems
that
the
definitions
like
kind
of
got
out
of
sync.
It
won't
be
like
a
free
text
how
long
you
ever
wanted
to
be
labor
and
a
promo,
seemingly
using
it
only
for
very
short
identifiers.
So
maybe
someone
who
is
using
the
labels
can
shed
more
light
on
their
experience
with
it.
C
Hansiak
also
says
he
needs
to
look
it
up
yeah,
so
I
think
at
least
we
can
say
here
that
there
is
more
work
required
on
identifying
if
the
js
contact,
labor
property,
as
it
currently
is
defined,
really
is
useful.
C
C
Would
we
want
to
have
something
similar
to
map
and
shares
context
or
not,
and
if
there
is
no
opinion
on
that
in
the
room
today,
then
we
will
continue
working
with
this,
both
mario
and
me,
and
will
come
up
with
a
proposal.
C
C
The
question
I
think
on
the
next
slide.
I
even
posed
a
question:
if,
if
we
should
just
use
xab
label,
because
I
would
assume
that,
since
it's
defined
since
20
years,
the
majority
of
clients
who
do
care
implement
it,
so
maybe
we
should
just
use
that
one,
but
that
will
only
be,
in
my
opinion,
useful
if
we
have
a
full
understanding
of
what
this
property
is
supposed
to
do.
B
B
B
C
Context
properties
we
have
yeah
but
yeah.
There
are
pros
and
cons
of
just
reusing
the
xav
label
or
introducing
a
new
one.
I
think,
with
the
current
definition
of
the
label
property
in
js
contact,
we
should
use
a
new
one,
because
I
would
very
much
assume
that
clients
that
use
the
xab
label
expected
to
be
very
short
and
have
their
user
interfaces
designed
as
such.
C
If
we
come
to
the
conclusion,
there
is
really
no
need
for
a
free
text.
Thingy
you
can
tag
on
everything
in
shares
contact.
Then
we
should
clarify.
It
is
meant
for
very
short
identifiers.
B
C
Okay,
there
is
no
further
input
on
that
next
slide.
Please
we
already
brought
it
up
property
groups,
so
vcard
allows
to
group
properties,
as
you
can
see,
on
the
left.
There
is
a
group
with
identifier
group,
one
vcard
says
there
is
no
further
meaning
to
that.
It's
just
like
an
opaque
identifier
and
you
can
group
two
or
more
properties
in
vcard
with
that
we
already
define
in
the
in
the
mapping
rfc
a
way
how
to
preserve
them.
C
It's
it's
it's
a
draft
version
still,
but
basically
we
will
just
use
js
json
pointers
to
define
the
members
of
the
group.
C
What
I'm
not
sure
about
is
is
if
property
groups
should
be
a
thing
in
js
contact
in
the
format
2
at
the
moment,
as
you
can
see,
we're
using
our
special
mapping
properties,
which
really
are
meant
only
to
preserve
stuff
that
exists
in
vcart,
but
we
do
not
map
to
a
chase
contact,
but
I
wouldn't
know
of
a
use
case
where
property
groups
are
used,
but
if
somebody
here
uses
them
or
knows
of
use
cases
for
them
and
says
they
are,
they
should
be
a
regular
feature
in
js
contact.
D
I
was
just
waiting
to
be
called
so
this
is
hanseaux
speaking
no
particular
strong
opinion
right
at
the
moment,
but
just
an
a
note,
I
think
the
only
system,
I'm
aware
of
that's
I've
ever
seen
using
these
kind
of
group
properties
is
really
apple.
So
I'm
not
aware
of
any
other
system.
I've
never
seen
it
before.
D
I
might
still
need
to
look
into
if
the
case
for
apple
is
valid
or
makes
sense
so
might
make
sense,
because
apple
is
quite
a
big
usage
factor
here,
but
yeah.
That's
just
as
a
short
note
for
the
moment.
I'll
also
keep
that
on
my
list
for
rechecking.
C
Okay,
thank
you
yeah,
as
I
said,
so
I
surely
want
to
preserve
them
in
the
js
contact
data
so
that
we
can
map
that
cleanly
back
again
to
a
vcard.
C
All
right,
then,
the
next-
and
if
I
remember
correctly,
the
last
slide
for
gs
contact
is
stuff
that
we
do
not
intend
to
cover
in
js
contact.
We
want
this
to
be
quite
short,
but
it's
never
going
to
be
completely
empty.
So
what
we
do
not
what
we
will
not
map
to
standard
properties
in
js
contact
are
the
pid
and
client
pid
properties.
C
I
haven't
seen
this
in
use
anywhere.
I
also
have
doubts
that
this
is
really
this.
This
is
this
is
how
synchronization
should
be
done.
C
C
Similarly,
for
the
vcard
defines
a
couple
of
temporal
values,
timestamp
being
like
a
regular
utc,
timestamp
a
date
end
or
time,
but
also
just
the
date
and
time
and
all
of
them
can
have
partial
values.
So
you
can
define
a
time
where
you
do
not
know
the
minutes
or
you
can
have
a
date
or
you
just
know
the
year.
C
We
we
do
not
intend
to
support
the
date
and
time
types
mainly
because
there
is
no
property
using
them,
also
in
vcard,
at
least
as
far
as
we
know,
we
do
support
the
date
and
or
time
type
for
anniversaries,
and
here,
at
the
current
definition,
we
support
partial
dates.
We
do
not
support
time,
only
birthdays,
which
I
think
makes
sense.
C
But
if
somebody
disagrees,
let
me
know
what
we
might
change
is
that
at
the
moment,
if
I
recall
correctly,
but
I
might
be
wrong,
I
think
we
do
not
support
time
in
a
birthday,
and
I
think
if
we
do
not
support
it,
we
should
support
it,
because
people
might
know
their
exact
time
of
birth.
I
do
know,
for
example,
so
I
think
that
should
also
be
supported
and,
as
I
said
again
all
this
is
just
the
discussion
of
what
to
were
to
provide
standard
properties
in
js
contact.
C
All
right,
cool,
just
calendar
next
slide.
Please
again
the
same
story
like
with
vcard.
We
have
three
rfcs,
the
latest,
the
last
one
being
the
latest
edition,
which
defines
a
couple
of
new
eye
credit,
the
properties
at
the
moment.
We
are
it
for
these
extension
rfcs
for
both
weaker
and
icalendar.
C
For
example,
the
prop
id
parameter
that
you
currently
see
just
defined
in
the
icard
and
the
js
calendar
extensions
will
also
use
them
for
vcard
and
similarly
in
the
in
the
in
the
v
card
extension,
I
think
in
one
of
them
we
have
defined
already
the
mapping
of
of
of
properties
that
are
in
icalendar
vcard
to
chase
contact.js
calendar.
C
So
I
encourage
you
to
look
at
the
latest
one,
the
extensions
draft
and
see
if
how
you
think
about
that.
That
being
said
on
the
next
slide,
we
will
discuss
a
couple
of
changes
for
js
calendar
biz.
C
We
currently
identify
the
number
of
of
changes
that
are
mainly
improving
the
design
or
were
just
clarifying
things
that
were
not
as
clearly
defined
by
and
as
we
came
to
learn
while
we
were
implementing
the
standard
mapping
between
js
calendar
and
icalendar
that
so
the
the
main
points
that
we
want
to
get
into
gs
calendar
biz.
I've
kept
for
this
discussion
today
as
there
are,
as
there
is
not
consensus
about
them
for
all
the
changes
that
already
made
it
into
the
rfc.
C
C
The
summary
is,
we
are
using
an
extension
property
mechanism
for
that,
where
we
use
a
uri
in
the
urn
namespace
to
which
allows
us
to
use
the
already
itf
registered
namespace
for
urns,
and
we
can
exactly
point
to
the
rfc
where
we
define
this
mapping
so
that
the
property
also
kind
of
self-documents,
where
it
is
defined.
C
The
last
one
I
already
talked
about
so
next
slide.
Please,
and
that
brings
up
the
first
point
for
discussion,
which
we
have
seen
on
the
mailing
list
already.
I
will
just
give
a
short
summary
and
then
I
would
like
to
ask
mike
and
neil
to
join
the
discussion
and-
and
hopefully
we
can
sort
this
out
today.
So
in
js
calendar
we
have
reply
to
property,
it's
a
multivalued
property
which
allows
to
define
multiple
ways
to
send
rsr
rsvps
or
invites
keyed
by
the
identifier
of
the
scheduling
method.
C
Currently,
the
scheduling
methods
imap
web
and
other
are
defined.
For
reply
to
where
web
is
basically
link,
the
user
is
expected
to
click
on
to
to
rsvp
and
similarly
in
participant
oops,
there
is
a
s
missing.
So
it's
participant
sent
to
this
defines
where
to
send
invites
to
this
participant.
C
Next
slide.
Please
now
the
issue
that
came
up
during
the
conversion
to
icalendar
and
from
I
calendar
to
js
calendar
was
that,
as
as
we
said,
there
is
a
multivalued
property
in
gs
calendar
using
various
scheduling
methods,
but
I
canada
really
only
allows
one
which
is
a
calendar
address
aka
uri,
almost
always
a
mail
to
uri,
but
the
spec
does
not
require
that
that
you
can
put
in
the
organizer
or
attendee
properties
in
a
calendar
resource
de
facto
scheduling
is
done
over
is
over.
It
is
with
itip
over
imip.
C
So,
as
I
said,
typically,
you
will
see
male
2
uris
in
the
organization,
but
there
can
be
anything
else
now.
This
brings
up
the
issue
that
we
cannot
unambiguously
map
from
the
sent
to
property
or
the
reply
to
properties
to
the
organizer
or
attendee
respectively,
and
there
are
a
couple
of
options:
how
we
make
this
unambiguous,
that
are,
that
that
were
discussed
on
the
list
and
maybe
yeah.
C
C
C
But,
of
course
there
is
data
where
there
is
no
mailto
uri
in
the
original
icard
and
the
data.
So
what
happens?
If
you
add
in
js
calendar,
in
addition
to
an
an
existing
other
scheduling
method
in
imap?
Should
that
overrule?
C
What's
in
the
icon,
the
data,
or
should
you
stick
to
what
was
in
the
ikland
data
before
we
just
don't
know
and
and
most
likely
also
the
people
updating
the
data
will
not
be
even
aware
of
the
rules
and
if
we
use
heuristic
like
this,
we
need
to
be
aware
that,
for
every
additional
scheduling
method
defined,
we
need
to
update
the
rule,
because
we
always
want
to
be
unambiguous.
C
The
alternative
would
be
that
we
merge
the
other
and
imit
methods.
The
other
method
really
just
came
up
because
we
realized,
in
rare
cases
there
are
non-male
to
uris
in
an
attendee
or
organizer,
and
we
can't
map
the
two
imaps,
so
we
introduced
other.
So
the
idea,
really
one
of
the
ideas
now
would
be.
Okay,
we
just
say
it's
not
other
or
image.
We
just
say
it's
imit,
I
tip
sorry
and
then
it's
absolutely
clear.
Whatever
you
put
into
this
value
will
end
up.
C
If
you
schedule
over
itip
will
end
up
in
the
in
the
it
message,
and
the
last
option
that
was
brought
up
was
to
do
not
use
a
multivalued
property,
but
for
each
scheduling,
method
define
its
own
property,
which
still
might
be
uri,
might
be
something
more
complex.
That
very
much
depends
on
the
scheduling
method.
C
Speaking
of
scheduling
methods-
and
this
will
be
my
last
comment
before
I
hope,
neil
and
mike-
can
join
at
the
moment.
We
have
the
scheduling
methods
that
we
have
defined,
are
imip
and
and
or
itip,
but
really
it's
itip
over
imap,
the
web
scheduling
method
seems
rather
straightforward
to
understand
if
it's,
if
it
means
to
click
on
something
and
let
the
user
do
manual
action
at
the
moment.
I
wouldn't
know
of
any
other
scheduling
method
that
should
go
into
js
calendar,
so
we
might
not
know
the
requirements,
the
full
requirements
for
additional
scheduling
methods.
A
A
A
E
A
E
That's
much
better
sorry
about
that.
It
was
impossible
to
concentrate
with
your
own
words
coming
back
new
year
like
two
seconds
later,
so
I
think
the
at
the
moment
there's.
Basically
there
there's
two
types
of
address
we
can
get
here.
It's
a
itup
address,
that's
mailed
to,
and
so
we
understand
I
can
use
the
admit
one
eye
to
address
that
is
not
and
so
can
only
be
used
essentially
internally
with
calder.
Now
there
is
a
poor
name
for
that,
and
we
should
probably
rename
that
to
something
else
to
make
it
explicit.
E
We
could
merge
those
two
into
a
single
item
thing,
but
I
prefer
them
separate.
I
think
like
put
on
the
mailing
list
that
at
the
moment,
you've
got
servers
trying
to
do
this
translation
on
the
edges,
which
doesn't
always
work,
and
so
sometimes
they
leak
out
the
they
they
you
don't
get
the
mail
to
address
when
you
need
it
because
they
didn't
translate
it
within
an
external
system
and
you'll
be
much
cleaner
for
them
if
they
could
have
both
stored
inside
it.
E
Now
the
the
thing
about
having
multi-value
property
in
general
is
essentially
it's
kind
of
a
name.
Spacing
you'd
say:
all
of
these
are
properties
are
kind
of
the
scheduling
properties
rather
than
having
them
with
the
separate
top
level
names,
and
the
reason
that's
important
is
for
when
you
have
something
like
jmap
calendars,
you
could
have
the
servers
add
support
for
a
new
scheduling
thing
without
the
clients
having
to
explicitly
know
about
it.
E
So
the
all
the
the
jmat
spec
can
say
that
you
can
identify
which,
which
participant
is
you
by
looking
for
a
corresponding
kind
of
key
value
within
the
send
to
and
like
the
identity
for
that
user?
So
saying
this
user?
E
If
you
add
this
user
to
an
event
here
are
the
scheduling
methods
for
it,
and
you
just
add
that
as
a
single
property,
so
it
might
have
say
this
is
mail
to
neil
jay
at
fastmailteam.com
and
a
future
thing
new
uri
and
the
client
doesn't
have
to
know
anything
about
how
those
scheduling
methods
work.
It
just
gets
told
by
the
server.
E
Those
are
that
that
object
is
what
you
add
for
the
send
to
and
if
it
wants
to
know,
if,
if
an
existing
event
is
for
that
user,
it
just
has
to
look
for.
If
there's
a
corresponding
uri
within
that
object,
otherwise
it
wouldn't
know
which
properties
it
could
look
at
so
you'd
have
to
hard
code
kind
of
which
protocols
you
support
and
that's
going
to
make
it
much
harder
to
extend
in
in
the
future.
E
So
I
I
I
do
think
the
current
design
is
correct.
The
I
in
terms
of
of
translating
I
would
probably
go
with
just
a
simple
yeah,
if
well
from
calendar,
to
just
count,
I
can't
stress
down
as
a
straightforward,
there's
a
single
value.
If
it's
because
icalendar
is,
you
know
currently
quite
limited,
it's
it's.
It's
always
got
to
be
an
item
value.
E
It's
either
a
mail
to
one
or
something
else,
and
that's
pretty
much
all
we
care
about,
and
so
it
either
goes
to
I'm
it
or
to
whatever
the
other
one's
called
depending
on
whether
it's
a
mail
to
and
then
reverse.
I
take
the
item
one
first
and
if
not
take
the
the
other
one
to
go
back
and
I
I
just
like,
I
think
that's
actually
absolutely
gonna
be
fine
in
practice.
E
That's
we
just
if
we
want
to
just
be
able
to
store
the
other
values
in
eye
calendar,
we'll
need
to
find
some
extra
properties
to
store
them.
Obviously,
you
know
existing
clients
won't
support
the
other
properties
yet,
and
that's
fine,
because
they
can't
that's
kind
of
the
point
of
js
calendar
was
giving
us
an
extension
method
for
the
future
yeah,
so
that
that's
a
summary
of
my
position
on
that.
C
F
And
I
just
don't-
and
I
just
don't
really
see
what
what
problems
he's
trying
to
solve
it
doesn't
map
onto
what
it
does
at
the
moment
it.
I
definitely
disagree
with
the
idea
of
referring
to
it
as
imip
anyway,
but
that's
that's
just
a
naming
thing.
It's
really.
I
tip
we're
doing,
and
it
it's
up
to
servers
or
clients
to
figure
out
having
identified
the
the
attendee
is
to
figure
out
how
to
get
it
to
the
attendee.
F
F
And
I
think
the
only
thing
that
we've
identified
as
a
as
as
something
that
needs
changing
and
this
predates
js
calendar
is-
is
separating
out
the
organizer.
From
from
the
the
reply
to
address
that
that
became
a
problem
with
sharing
and
shared
calendars,
the
the
organizer
really
shouldn't
be
the
one
you
reply
to
necessarily,
but
that's
that's
that's
something
we
can
easily
deal
with.
We
can
extend
it
to
add
a
a
reply
to,
but
that's
the
only
thing
I'm
seeing.
F
I
think
we
really
need
to
simplify
this
back
down
to
what
we
do
and
not
not
try
to
anticipate
some
scheduling,
approach
that
we
don't
have
yet
and
it
and
I'm
not
even
sure
we
should
try
and
deal
with
the
the
web
thing.
F
I
mean
that's
an
extension
again
it'd
be
nice
to
standardize
the
having
a
a
way
of
of
responding
to
an
invitation
through
some
other
mechanism
such
as
the
web
and
the
the
you
know,
the
current
approach
of
adding
http
bodies
to
the
to
the
message
it
works
sort
of,
but
it'd
be
nice
to
standardize
that
I
guess,
but
I
don't
think
I
said,
that's
something
we
necessarily
have
to
deal
with
here.
It's
something
we
can
add
later
I'd
just
like
to
see
us
get
it
working
minimize
js
calendar.
F
F
The
I
think
the
only
thing
we
need
to
do
with
is
identify
the
the
recipient
and,
and
we're
done
that's
all.
We
have
at
the
moment.
A
Just
popping
myself
in
the
queue
with
with
my
chair
hat
off
here,
I
think
I'd
definitely
say
the
the
point
in
having
a
single
object
that
all
the
reply
to
is
inside.
A
So
then
you
can
patch
overwrite,
whatever
happens
to
be
in
it
with
new
replacements,
without
needing
to
keep
a
full
list
of
all
the
possible
fields
in
future.
So
having
that
one
level
of
indirection
is
still
makes
a
nice
easy
extension
point
here,
even
if
we
only
need
to
find
one
thing
inside
it,
and
I
think
that
that
might
be
the
way
to
say
we
only
define
one
item
and
that
maps
directly
to
whatever's
in
our
calendar.
E
A
E
The
values
are
currently
defined
to
be
your
eyes,
we
could
relax.
That
say
they
could
be
anything
I
I
don't
know.
We
necessarily
need
to
do
that,
but
that's
that's
an
option
that
would
make
it
harder
by
saying
they
have
to
be
your
eyes.
We,
I
said
that
the
advantage
is
that
a
client
can
check.
Is
there
a
match
between
this
property
and
a
uri?
I
know
about
identifies
this
user
without
having
to
know
anything
about
how
the
uri
works
without
how
that
scheduling
method
works.
E
So
I
said
you're
you're
dis,
you're,
not
coupling
the
ability
to
add
this
other
method
to
the
to
the
client.
Knowing
about
it.
C
C
So
the
point
I'm
I
want
to
make
is
given
the
charter
and
also
practically
all
practical
purposes.
I
think
it's
necessary
that
scheduling
with
js
calendar
I
calendar
should
be,
should
be
seamless.
There
should
be
no
source
for
implementers
to
mess
this
up,
because
this
is
really
the
core
of
the
specification.
C
So
whatever
we
come
up
with,
it
needs
to
be
absolutely
critically
clear
what
to
do
and
it
it
should
be
simple
to
implement.
What
I
wanted
to
ask
for
clarification
is
neil.
What.
C
Before
that,
the
like
the
client
might
not
necessarily
know
the
scheduling
methods
of
the
people
they
invite,
so
that
this
kind
of
is
the
same
thing
like
in
icalendar,
currently
that
the
uri
both
acts
as
an
identifier
like
as
of
the
user,
but
also
as
a
way
to
reach
that
user.
And
wouldn't
that
speak
more
of
what
you
were
saying
to
like
splitting
this.
So
why?
Why
would
I
necessarily
define
the
imit
method
to
identify
someone
and
not
just
identify
with
the
uri?
C
C
C
Are
wondering
if
we
are
conflating
identification
of
a
participant
with
their
scheduling
method
uris,
which
is
what
I
calendar
is
doing.
F
That
was
that
was
where
that
was
where
I
actually
started
to
experience.
Difficulties
with
seeing
how
this
would
work
is,
is
being
able
to
unequivocally
identify
the
the
attendee
we're
dealing
with
the
participant
and-
and
that
was
where
what
I
wanted
to
simplify
this
to,
to
ensure
that
that
was
was
the
case
that
it
looked
to
me.
It's
gonna
be
too
easy
for
me
to
get
a
invitation
where
I
couldn't
even
identify
the
the
participant
we're
talking
about.
E
E
If
I
have
an
event
in
my
calendar,
how
do
I
know
which
one
of
the
participants
is
me
so
to
speak
and
the
way
we
do
it
at
the
moment
is
one
of
the
presumings
added
by
mail
to
one
of
those
mail
to
send
two
things
on
the
participant
matches,
an
email
address
that
I
own
or
possibly,
if
you're,
using
implicit
scheduling.
You
know
that
this
uri
matches
my
own.
C
Yeah,
I
think
that
this
is
something
that
already
was
kind
of
trying
to
address
in
the
new
icon,
the
properties
rfc
7986.
I
think
it
is
where
this
this
email
parameter
right.
This
was
exactly
meant
to
like
you
can
provide
the
email
address
of
someone
who
identifies
them.
I
think
the
description
was
in
a
con
in
an
address
book,
but
that's
not
that's,
not
necessarily
the
address
where
you
send
the
imap
to,
and
I
think
this
is
exactly
going
in
the
same
direction.
C
If
there
is
the
need
to
separate
scheduling
from
identification,
because,
as
you
described
before
you,
you
really
would
expect
the
server
to
better
know
the
various
scheduling
methods
rather
the
client,
and
at
the
moment
it
seems
not
so
clear
to
me
if,
as
a
client
implementer
one
what
what
they
would
put
into
the
reply
to
are
they
expected
to
not.
They
know
all
the
scheduling
methods
for
the
participants.
E
No,
I
mean
the
recommendation
in
the
jmf
spec
is
they
do
not
set
a
reply
to
the
server
sets
it
when
you
create
it
and
the
server
can
put
in
any
methods
it
knows
about.
If
the
client
wants
to
it
can
create
an
explicit
one,
you
know
wants
to
save
whatever
we
can
reply
to
this
way-
and
I
know
this
is
going
to
work,
but
the
recommendation
is
they
don't
set
it
in
the
services.
E
So
sure,
but
for
your
send
to
again
you
get
those
from
the
server
the
server
says:
here's
the
identity
so
to
you
for
each
of
these
identities.
This
is
the
center
object.
You
just
put
this
object
in
verbatim
and
that
may
have
whatever
scheduling
methods.
The
server
knows
how
it's
going
to
receive,
and
so
in
both
cases
the
client
doesn't
have
to
know
how
those
protocols
work,
which
the
server
just
says,
here's
the
value
to
use.
What
the
client
needs
to
know
is.
C
Yeah,
so
at
the
moment
I
I
I
get
the
impression
that
we
haven't
progressed
from
the
state
of
consensus
or
non-existence
of
consensus
from
the
mailing
list.
E
C
F
No,
I
I
don't.
I
don't
see
that
we've
progressed.
G
So
I
hesitate
to
offer
a
number
four
both
because
it's
a
number
four
and
because
I
may
be
deadly
wrong-
this
is
rick
sickness.
It
sounds
like
part
of
the
problem.
Here
is
the
conflation
of
identity
and
reply
mechanism,
and
right
now
we
have
a
single
value.
Attendee,
who
is
you
know
we
conventionally
always
use
their
mail
to?
G
I
wonder
if
the
this
a
simpler
answer
is
to
always
have
that,
with
the
assumption
that,
if
you
only
have
that
that
is
your
single
reply
mechanism,
you
can
always
reply
with
imip
to
the
attendee,
as
you
said,
like
their
email
address.
So
instead
of
saying,
add
an
email
property
which
is
their
address
book
email
and
the
organizers
addresses
the
the
reply
to
we
say
the
the
field
that
is
there
now,
which
is
doing
two
jobs.
That's
the
default
reply
to
for
imep,
and
if
you
wish
you
can
supply
alternate
reply
mechanisms.
G
G
So
you
could
say:
look
if
there's
nothing
here.
Imip
will
work.
You
have
my
mail
too
and
if
I
didn't
use
a
mail
to
as
my
identifier
uri,
what
am
I
doing
and
if
we
have
other
mechanisms
that
we
would
like
transport
to
upgrade
to,
we
can
supply
those
as
alternative
preferential
methods.
So
this
is
this
is
an
idea
shot
from
the
hip,
but
I
haven't
been
able
to
see
why
it's
a
terrible
one.
Yet.
E
G
C
But
for
this
I
would
understand
that,
so
we
can't
do
that
with
itip
as
it
is
right
now,
so
we
would
need.
I
mean.
C
Currently,
at
the
moment
is
what
do
we
need
to
provide
to
to
make
it
in
interoperate,
with
the
current
eye
tip
over
with
I
calendar
yeah.
D
C
And,
of
course,
we
can
build
something
on
top,
but
we
need
to
extend
it.
But
if
I
understood
correctly
what
you
were
saying
like
we,
there
are
a
couple
of
scheduling,
addresses
and
then
there
is
one
where
you
say
this
is
the
preferred,
and
this
is
what
the
preferred
one
also
should
go
into
the
eye
tip
right.
G
No,
no,
I
don't
well.
We
can
follow
those
up
on
the
list
where
I
can
write
it
down
very
clear,
but
my
suggestion
is:
we
have
a
canonical
identifier,
that's
what
we're
currently
using
the
single
uri
for
the
user,
which
is
which
is
now
the
identifier
for
the
user
and
can
be
used
for
itip
if
nothing
for
sending
imap
right
if
it's
mailed
to
and
nothing
else
is
present,
but
to
offer
an
upgrade
path
to
to
richer
forms
of
reply
than
imip
allows.
G
A
I
think
I
get
it
so
just
as
a
point
here
we
have
10
minutes
left
in
the
session.
We
have
six
more
slides
on
this
plus
task,
so
let's
not
spend
too
much
longer
on
this.
H
Yeah,
so
real
quick,
I
originally
stood
up
to
basically
thumbs
up
what
ron
and
mike
said
earlier
and
partially
what
rick
just
said.
So
I
think
there's
three
points
we
need
to
look
at.
We
need
to
preserve
the
identifier
in
the
attendee
or
the
organizer,
which
may
or
may
not
be
a
mail
to
uri.
H
If
it's,
if
it's
a
url
or
something
else,
we
need
to
preserve
the
mail
property,
it
should
be
a
mail
parameter
because
that's
the
address
we
actually
need
to
use
for
itunes.
I'm
with
mike
on
this
there's
no
distinction
between
itip
and
imip
they're,
both
the
same
thing.
That's
the
address
currently
being
used
and,
as
braun
said,
I
think
we
should
allow
this
to
be
extensible.
H
C
Okay,
send
buyer
make
this
quick,
so
there
is
it
sent
by
property,
property's
calendar
defined
to
be
the
email
address
of
the
the
from
header
from
the
email
that
this
this
calendaring
data
got
received
from.
There
is
a
send
by
parameter
on
an
attendee
in
I
calendar,
which
is
defined
differently.
C
Okay,
I
hear
thumbs
up
perfect
next
one,
please,
okay,
so
very
quick.
We
propose
to
change
the
vendor
extension
naming
schemes.
Currently
it's
defined
to
be
a
domain
and
the
property
name
while
mapping
by
defining
the
standard
mapping
for
js
kind
of
icon
that
we
realized.
We
don't
have
a
domain,
we
can.
We
are
authorized
to
use.
C
So
we
want
to
change
the
extension
mechanism
on
the
next
slide.
There
is
the
proposal
we
propose
to
allow
any
https
uri,
which
should
point
to
the
definition
of
the
property
this
any
any
vendor
extend
vendor
can
use.
For
extension,
we
also
allow
uris
in
the
urn
namespace
if
they
use
the
itf
namespace,
so
basically
for
every
property,
it
will
be
self-documented
in
which
I
receive
they
were
defined.
C
Any
all
right
that
was
quick.
Thank
you.
Sorry,
yours,
okay,
last
point:
at
last
itf
we
were
saying
that
unknown
properties
should
be
preserved
so
that
that
unknown
properties
in
js
calendar
should
not
lead
to
clients
invalid
invalidate
the
js
calendar
data.
That
was
mainly
because
we
were
saying:
okay,
maybe
some
implementations
will
not
keep
up
with
all
the
extensions,
so
currently
they
would
reject
legit
js
calendar
data.
C
There
are
two
ways
to
deal
with
that,
and
the
next
slide
is
the
first
option.
The
first
option
would
be
to
validate
known
properties,
but
to
demand
that
all
others
should
be
ignored
but
stored,
but
this,
in
my
opinion,
can
lead
to
name
squatting.
For
example,
if
you
have
a
vendor
a
using
prop
a
later
on,
an
rfc
defines
prop
a
but
with
a
different
value,
type
or
semantics.
C
There's
going
to
be
data
with
that
property
already
out
there
and
we
do
not
want
it
because
it
would
it
would
clash.
We
already
have
quite
a
lenient
way
to
add
things
to
js
calendar.
We
have
expert
review
and
not
specification
review,
but
I
would
propose
even
something
more
lenient,
so
that
vendors
are
encouraged
to
at
least
document
their
extensions,
and
this
is
on
the
next
slide.
C
I
would
like
to
propose
that
we
do
not
support
any
unvendered
properties
at
all.
After
we
have
defined
js
calendar
implicitly,
all
properties
that
do
not
have
have
a
prefix
will
be
the
properties
of
js
calendar
biz.
Everything
else
will
be
prefixed,
either
by
an
https
uri
or
by
the
urn
of
the
rfc
that
the
extension
is
defined
in
this
way.
This
is
very
similar
to
chain
map
capabilities.
C
In
a
way
it
decreases
the
payload,
because
we
have
longer
strings
in
a
way,
but
using
complex
types
like
I've
shown
with
the
examples
on
the
right
side.
I
think
it
would
be
worth
it
so
that
we
do
not
have
any
issue
with
name
clashes
and
hopefully,
all
the
properties
one
sees
are
self-documented
in
the
payload.
F
C
C
We
obviously
require
implementations
to
implement
the
js
calendar
spec
and
there
can
be
nothing
else
in
a
js
calendar
data,
either
an
extension
properties
from
future
extensions
or
the
ones
that
are
defined
in
the
specification
that
the
implementation
is
expected
to
implement.
So,
in
that
using
this
scheme,
there
can't
be
any
unprefixed
unknown
property
ever.
A
Okay,
so
I
have
questions
around
patching
and
and
path
objects
with
all
the
slashes
that
are
in
these.
It's
going
to
be
very
easy
for
people
to
screw
up
the
quoting
I'm,
not
I'm,
not
a
fan
of
all
those
slashers.
I'm
seeing
in
these
examples
here,
given
that
that's
a
special
character
in
in
our
patch
syntax.
C
C
So
maybe
we
can
separate
https
domains
from
which
of
the
two
options
or
other
set
is
option,
two
something
that
people
tend
to
agree
with
other
than
me.
Are
there
any?
C
Would
you
see
any
reason
not
to
do
the
second
option,
which
is
saying
that
only
the
the
only
non
vendor
extended
properties
in
the
js
calendar
are
the
ones
in
the
rfc
that
this
js
kind
of
is
and
everything
else
is
added
as
an
extension
properly
with
the
proper
rfc
number,
where
this
property
is
defined.
A
H
C
C
But
taking
points,
I
brought
point
into
account
for
option
one.
There
is
the
unresolved
question
of
how
to
deal
with
name
squatting
of
non-vendor
extended
properties.
Given
the
time
I
don't
think
we
will
be
able
to
resolve
that.
A
I'd
just
say
that
you
can't
create
non
non
vendor
properties
unless
you
specify
an
rfc
done.
C
A
E
C
E
C
So
it
will
so
it
will
mean
that
clients
or
services
can
store
data
with
standard
named
properties
that
are
not
standard
and
in
the
future
the
same
same
standard
property
will
come
up
and
it
will
have
a
different
semantic
or
value
fight.
F
It
could
happen,
it
could
happen
now
and-
and
it's
not
it's
not
that
much
of
a
problem,
but
I
think
I
think
he
can
avoid
it
happening
when
people
are
trying
to
do
stuff
legitimately
by
making
a
very
easy
registration
process
or
pre-registration
process
for
names.
F
This
came
up
as
part
of
discussions.
We
were
having
about
other
possibilities
for
for
the
tasks
specification,
and
somebody
pointed
this
out-
and
I
hadn't
even
noticed
this,
so
it
says
in
rfc
5545
the
v2du
explicitly
disallows
a
duration
on
its
own,
so
I
hadn't
noticed
this
bit
of
text.
F
F
F
It
matters
in
things
like
one
of
the
things
with
our
aims
with,
with
the
the
tasks
update,
was
to
try
and
make
the
more
compatible
things
like
project
management
and
when
you
string
tasks
together
using
temporal
relationships,
it's
quite
probable
that
the
these
subsequent
tasks
in
the
in
the
chain
will
not
have
a
start,
because
they
depend
on
previous
tasks
in
the
chain.
F
You
may
know
how
long
you
you're
going
to
allow
for
the
task,
but
you
don't
necessarily
know
exactly
when
it's
going
to
start
so
having
a
duration
on
its
own
is
perfectly
reasonable
there.
In
fact,
I
think
duration
is
perfectly
reasonable
on
a
standalone
task.
Your
if
you
don't
have
a
start
on
a
task
or
on
end
it
just
floats
along,
and
it's
supposed
to
appear
there
in
your
in
your
ui
every
day
until
you
do
something
about
it
having
a
duration
on
it.
F
Just
as
I
say,
I
think
this
is
going
to
take
an
hour
and
it
can
just
carry
on
floating
along,
like
that.
I
I
believe
that
was
probably
the
intent
of
two
four
four
five
was
you
you
want
to
know
how
long
this
thing's
going
to
take,
but
you
don't
necessarily
know
when
you're
going
to
do
it
so
next
slide.
Please
my
suggestion
is:
we
simply
drop
the
constraint
because
there's
no
real
indication
of
why
it
was
added.
F
I
did
have
a
call
with
bernard
and
asked,
and
he
couldn't
remember-
and
I
don't
think,
there's
any
discussion
online.
It
just
appeared
there
and
then
I
had
a
look.
I'd
look
at
ical
for
jay.
I
think
ken
is
that
ken
wandering
up
there
looks
at
liv
ical
ice.
Alpha
j
doesn't
doesn't
apply
the
constraint
most
of
these
libraries,
I
suspect,
were
written
around
two
four
four
five
times
and
up
and
they
they
weren't
changed
for
this
thing.
So
I'm
not
sure
it's
going
to
cause
any
problem.
H
Family,
so
this
is
yeah
yeah,
so
I
agree
with
mike's
assessment.
I
also
believe
that
this
text
crept
into
545
by
mistake
and
duration
should
be
allowed
by
itself,
which
brings
up
the
question
of
what
do
libraries
currently
do
with?
Would
they
choke
if
it
saw
a
duration,
while
the
dt
start?
I
did
check
lib
ical,
which
I'm
a
maintainer
of
it,
does
not
enforce
dt
start
with
duration,
presumably
because
it
was
based
on
two
four
four
five
and
it's
been
very
minimally.
G
H
H
H
F
I
mean
clearly
something
was
in
somebody's
mind
when
they
added
this,
it's
probably
bernard's
mind
and,
and
he
added
it
I
don't
know
why,
and
I
don't
think
he
does
now.
H
Just
think
add
one
more
point.
So,
yes,
it
was
added
in
an
intermediate
draft
and
it
is
not
mentioned
as
one
of
the
changes
in
the
appendix
of
545..
So.
F
H
I
could
find
no
traffic
on
the
mailing
list
with
discussion,
so
my
gut
feeling
is
this
was
some
kind
of
copy
and
paste
mistake
that
wasn't
even
noticed
in
review
and
neither
by
the
author
or
by
the
working
group.
B
F
Yeah
yeah,
that's
where
that's
where
it
came
up,
and
I
was
I
there
was
a
lot
of
talking
across
purposes,
because
I
hadn't
realized
that
the
constraint
was
there
in
in
5545.
A
A
All
right,
our
area
director
is
officially
francesca
for
this
working
group,
but
obviously
she's
on
leave
at
the
moment.
So
I
guess
we
talked
to
murray.
For
now,
kenya
were
going
to
talk
to
him.
A
Cool
perfect
all
right
thanks,
everybody
we're
done
enjoy
the
rest.