►
From YouTube: IETF113-JMAP-20220321-1330
Description
JMAP meeting session at IETF113
2022/03/21 1330
https://datatracker.ietf.org/meeting/113/proceedings/
A
All
right,
everybody
welcome
to
the
jmap
and
extra
session
at
iatf
in
vienna
and
remotely
thanks
for
joining
us.
There's
a
few
people
here
in
the
room,
probably
a
few
more
remotely
I'm
having
to
pop
up
here
to
this
microphone
to
speak
because
the
table
microphone
is
dead.
So
I'm
just
going
to
drag
this
back
down
to
the
desk.
While
I
read
through
these
initial
slides
and
then
we'll
get
straight
down
to
business,
so
this
is
this:
is
the
slides
we've
been
given
here
we're
doing
both
chairman
and
extra?
A
The
plan
is
to
the
gym
at
first
there's
about
75
minutes
of
that
and
then
about
45
minutes
of
extra
according
to
what
we
put
into
the
agenda.
But
of
course
that
is
things
will
change
as
we
go
the
noteworld.
I
think
everyone
in
this
room
has
been
in
additional
sessions
this
morning.
So
you've
probably
already
seen
this
for
everyone
remote
everything
you
do
here
is
covered
under
the
note.
Well,
so
you
you
have
to
follow
the
iotf's
processes
and
policies.
A
Little
tips
for
people
in
the
room.
There
are
qr
codes
all
over
the
place
that
you
can
scan
from
your
mobile
device
or
you
can
use
the
little
mobile
device
on-site
tool
thing.
Otherwise
you
can
log
in
with
the
full
meet
echo
client
if
you
would
prefer
either
way.
Logging
into
medieco
is
the
way
that
you
indicate
you're
present
for
blue
sheets.
Everyone
remote,
obviously
has
already
done
that
cool
links
to
resources.
You
can
find
all
of
this
directly
from
data
tracker,
so
I
won't
spend
long
on
this
page.
A
Here's
the
agenda
for
the
jmap
session,
so
planning
to
start
with
jmf
s
mime,
because
that's
with
the
editors
already
then
work
our
way
through
the
active
drafts
with
each
person.
Speaking
to
what's
happening
with
that
and
finally
review
our
milestones,
and
then
we
will
do
the
same
for
extra,
starting
with
with
things
that
are
further
along
and
going
back
to
things
that
are
less
far
along.
A
B
C
C
C
Hopefully
I
did
it
correctly,
and
so
there
is
just
a
few
minor
formatting
things
and
it
should
be
done.
Maybe
even
announced
this
week,
cool
fantastic.
D
E
D
A
For
it,
because
there's
no
state
for
blobs
and
there's
no
update
or
destroy
this
only
create
so
blob
upload
is,
is
basically
a
set
that
can
only
do
creates.
It
still
creates
creation
ids,
because
you
need
to
have
them
to
be
able
to
back
reference,
which
is
the
large
point
of
doing
inline
blob
creates.
A
I
also
removed
the
catinate
both,
because
what
even
does
that
mean
nobody
knows
and
because
it
makes
it
much
simpler
if
it's
always
just
a
list
of
of
bite
sources,
octet
sources
in
order
that
you
append
together
to
create
a
final
result
which
could
be
zero
if
you're
uploading,
the
nothing
file
or
it
could
be
one
or
more
sources,
also
made
the
capabilities
simpler.
You
used
to
be
able
to
specify
a
maximum
applied
upload
size
for
blob,
and,
if
you
didn't
specify
it
there,
then
it
should
get
it
from
the
upload
endpoint.
B
A
A
Is
that
instead
of
it
saying,
create
and
then
an
id
and
then
just
text
the
data
as
text?
It's
got
a
data
and
then
an
array,
and
then
the
data
is
text
item
in
it.
S1
hash
within
an
array
it
does.
Are
we
done
it's?
This
was
in
working
group
last
call
it's
a
fairly
significant
change,
but
it's
been
posted
for
two
weeks
now
and
I
told
everyone
on
the
list.
So
if
you
have
feedback,
please
send
feedback.
If
not
I'll,
ask
jim
to
push
the
button
and
send
it
off
to
the
editors.
A
Yes,
yep
feel
free
to
push
the
button
pop
up
whatever
you
want.
Just
just
go
talk
to
the
microphone.
It's
fine.
Just
tell
people
who
you
are.
You
don't
need
to
do
this?
G
G
G
Okay,
because
it
might
be
worthwhile,
in
my
opinion,
to
point
that
explicitly
out,
because
this
is
the
only
single
operation
which
will
only
give
you
metadata
from
the
server
without
having
the
server
to
touch
the
actual
files
on
disk.
Okay.
This
is
an
operation.
Typically,
we
do,
for
instance,
during
some
scanning
kind
of
operation
exactly,
and
this
is
a
reason
why
I
would
say
also
for
implementers
to
have
that
in
mind.
G
Cool
second
related
thing
is
actually
so
the
question
is:
would
there
be
a
case
actually
for
a
list
or
blob
thing
in
case
you
know
you
want
to
have
a
full
migration
from
one
mailbox
to
the
other
one.
Obviously
you
could
get
that
from
the
actual
items
where
you
get
the
references
from,
but
sometimes
it's
more
handy
also
for
some
reasons
for
polarization.
Also,
if
you.
B
While
we're
stopped,
who
was
who
was
speaking,
I
didn't
catch
your
name.
A
All
right,
let
me
bring
you
the
microphone
here.
You
go
okay,
so.
G
So
so
this
is
hubble
hello
should,
I
repeat,
everything
or
yeah.
Okay,
I
give
it
short,
so
I
have
basically
two
remarks.
So
first
remark
is
on
blob,
get
as
far
as
I
interpret
rc,
it's
possible
to
explicitly
mention
the
properties
to
retrieve
from
the
server,
so
it
should
be
possible,
for
instance,
also
to
only
retrieve
the
size,
which
is
basically
a
metadata,
and
sometimes
it
comes
handy
to
only
get
set
data
before
deciding.
G
Maybe
you
know,
for
forgetting
knowledge
about
the
size,
calculating
some
duration
and
so
on
without
having
the
server
read
the
file
physically
or
something
like
that.
So
it
would
be
helpful.
I
think,
to
point
out
this
possibility
also
for
implementers
to
make
that
distinction
in
the
implementation
to
make
it
more
efficient
to
read
size
only.
B
A
To
respond
to
that
second
one:
yes,
it
would
be
possible
to
add
a
blob
query.
I
imagine
service
might
reject
it,
but
they
can
reject
anything.
Certainly
the
ability
to
look
through
everything.
It
could
be
quite
a
lot
of
data,
but
yep.
Okay,
I
think
alexia
is
next.
Let
me
give
you
back
the
microphone.
C
I'm
sorry
can
I
be
the
naughty
child
in
the
room
that
I
haven't
read
the
latest
draft,
I'm
not
always
okay,
so
I
think
taking
out
catenate
for
simplicity
is
probably
fine.
Can
you
just
remind
me
what
the
use
case
for
it
was?
Was
it
like
I'm
a
catenate
kind
of
case
right.
A
To
answer
that,
what
I
did
by
taking
out
cat
mate
was
made
everything
a
cat
note.
So,
instead
of
having
a
type
that
was
either
a
single
item
or
a
type
that
was
a
list
of
items,
it's
always
a
list,
and
so
you
list
may
have
only
one
item
in
it,
but
instead
of
having
a
key
called
catinate
that
meant
concatenating
multiple
of
these
together
everything's
just
a
list.
We
good
now
hello.
C
B
F
What
yeah,
I
just
wanted
to
say,
I'm
not
sure
about
having
a
blog,
slash,
query,
and
I
don't
know
that's
a
good
idea,
like
the
point
of
this
draft
was
to
be
able
to
do
kind
of
in
band.
You
know
upload
and
download
of
blobs,
so
it's
kind
of
the
same
functionality
you
already
have,
but
just
without
having
to
have
a
separate
connection
for
those.
F
If,
for
some
reason,
that's
what
you
needed,
but
knob
slash,
query
is
quite
a
different
functionality
and
also
is
a
bit
weird
with
you
know:
blobs,
not
a
base
type
in
the
same
way,
a
normal
managed
object.
Is
you
you
don't
have
state
strings
to
be
able
to
do
change,
tracking
and
stuff?
I
don't.
It
just
seems
a
lot
of
extra
stuff
to
add
without
really
thinking
about
it.
A
A
Ones
that
maybe
aren't
referenced
by
anything,
if
you,
if
you're,
using
this
as
a
replication
mechanism
between
a
system
and
a
hot
standby
type
of
thing,
then
doing
a
an
rsync
type
situation
where
you
fetch
the
full
list
and
then
grab
blobs
that
aren't
copied
across
would
allow
you
to
do
a
failover
safely.
So
I
imagine
that's
the
kind
of
case
that's
being
looked
at
here.
A
The
the
main
issue
with
it
is
it's
a
lot
of
data,
so
you'd
have
to
page
it
or
something,
and
because
there's
no
state
string,
pagination
becomes
quite
difficult.
There.
A
All
right,
thank
you.
I
will,
I
guess,
post
responses
to
what's
happened
here
to
the
mailing
list,
possibly
do
an
updated
draft
with
the
the
advice
around
fetching
size.
I
A
A
I
A
A
Oh,
that's
not
what
I
meant
chair,
slides
so
back
on
the
chair,
slides
for
a
second.
J
Yes,
hello,
can
you
hear
me
hello?
Yes,
yeah,
yeah,
hello,
I'm
renee,
so
yeah,
I'm
gonna
present
quickly.
I
mean
what's
new
in
gemma
quota,
not
so
much
to
be
honest,.
A
J
Thank
you,
so
I
mean
there's
not
much
changes
lately,
but
I
mean
thanks
to
neil
that
did
a
few
more
feedback,
so
I
think
it's
pretty
stable.
Now.
Also
in
kota
capability
I
mean
yeah,
it
was
useless
to
have
kota
ids.
We
can
just
fetch
them
with
a
quota,
slash,
get
method
for
the
scope
and
resource
type
as
well.
I
mean
we
don't
need
to
specify
the
some
custom
extension.
J
And
then
the
resource
type
just
renaming
size
to
octet.
So
it's
it's
more
clear
about
what
we
want
here
and
and
limit
as
well
a
bit
more
generic
definition,
and
that's
that's
pretty
much
it.
J
So
if
people
have
questions
or
maybe
feedbacks
on
kuta's,
I
mean
yeah
you're
free
to
ask
questions
here
or
to
to
answer
the
mailing
list
as
well.
J
J
I
guess
I
can
give
you
the
handbag,
bronn
yeah
cool.
C
Yeah,
just
my
apologies,
I
haven't
read
the
latest
document,
but
now
that
the
quarter
I'm
up
quarter
rfc
is
about
to
be
published.
I
I
can
you.
I
can
give
full
attention
to
your
document
to
make
sure
it's.
You
know
consistent
with
mine,
or
at
least
if
there
are
differences,
then
we
discuss-
and
you
know,
agree
why
they
are
good
thing.
C
A
A
So
I
guess
I
can
share
it
and
then,
oh,
no
sorry
being
shared
fantastic.
I
do
not
need
to
do
that,
or
is
that
me
sharing
it's
hard
to
tell.
A
F
Yes,
sorry
about
that,
I
don't
have
any
sharing.
I
just
had
some
calendars
sharing,
though,
actually
it's
pretty
complete.
I
was
just
somebody
look
at
that
again
before
this
meeting
and
I
think
it
needs
some
a
bit
of
wordsmithing
just
to
make
sure
everything's
as
clear
as
possible,
but
it
it.
You
know
it's
reasonably
short:
it's
only
kind
of
10
pages,
I
think
in
rc
format
and
reasonably
straightforward,
so
that
one
could
possibly
progress
pretty
soon.
F
I
don't
know
whether
we
want
to
wait
to
do
it
at
the
same
time
as
calendars
and
stuff,
but
it's
not
exactly
tied
to
it.
It's
kind
of
it's
related,
but
I
think
just
yeah
go.
F
F
Oh
yes,
excellent,
okay,
cool
okay!
So,
since
the
last
meeting
been
quite
a
few
updates,
we've
got
quite
a
bit
of
implementation
experience
with
this
now,
which
has
been
great
mainly
for
servicing,
just
little
edge
cases
which
needed
to
be
properly
documented.
So
that's
obviously
why
we
do
that
before
we
try
and
publish
this.
There
are
still
a
few
questions
also
that
came
up
while
from
the
implantation
experience.
F
So
I
just
want
to
talk
through
a
few
of
those
and
see
what
people
in
the
room
have
to
say
about
things,
any
thoughts
so
I'll
just
step
through
that
now
now
the
first
one
of
these
is
actually
one
of
those
ones
where,
when
I
was
writing
it
up,
I
realized
that
the
answer
was
kind
of
obvious,
but
I'll
just
talk
to
it
briefly
anyway,
because
it's
kind
of
interesting
there's
a
concept
that
I've
called
whether
the
server
is
the
source
of
an
event,
and
I
wonder
whether
that's
actually
the
best
way
of
naming
this,
but
essentially
this
comes
down
to
whether
it
was
created
on
that
server
or
whether
it
was
created,
say
on
completely
different
server
run
by
different
company.
F
But
you
received
knight
message
that
added
it
and
the
the
that
affects
a
few
things
in
terms
of
how
it
behaves,
for
example,
whether
when
you
update
the
event
sending
an
rsvp
or
whether
it's
sending
out
the
invitations
to
all
the
other
people-
and
you
can't
just
look
at
the
apples
here,
because
you
have
full
permission
to
edit
it.
It's
just
that.
Actually,
you
shouldn't
edit
most
of
it
because
you're
not
really
the
one
that
controls
it
and
another
update,
may
completely
blatant
your
changes.
F
So
generally,
clients
already
have
this
concept.
I
don't
know
what
other
clients
call
it
necessarily,
but
they
look
at
the
organizer
to
know
and
see.
Is
that
someone
they
know?
F
Is
you
to
determine
whether
they
think
this
is
the
source
or
not,
but
that
won't
necessarily
work
in
all
circumstances,
because
you
might
have
a
per
event
or
per
account
reply
to
address
which
lets
you
do
some
nice
other
things,
but
it
means
it's
not
necessarily
easy
to
work
out
whether
this
event
is
the
source
of
this
event,
is
this
server
that
you're
on
or
somewhere
else?
F
So
basically,
the
episode
of
this
is,
I
think
we
probably
do
need
to
add
a
new
property
to
the
event
that
the
server
will
set
when
you
create
it
for
the
server
to
say.
Does
it
think
it's
the
source
that's
spent
or
not,
so
the
client
can
change
his
behavior
based
on
this.
So
I
guess,
first
of
all
just
any
objections
to
that,
and
also
does
anyone
know
of
a
standard
naming
for
this
concept
or
other
names
or
who
should
I
stick
with
sauce,
that's
kind
of
the
name
for
that.
L
A
F
Well,
I
don't
know
about
that,
because
so
so
it's
defined
at
the
moment
in
the
spec
of
that
the
server
is
the
source
if
it
will
receive
messages
sent
to
the
reply
to
sent
to
the
organizer
essentially,
and
so
it
will
know
that
even
when
you
import
them,
you
won't
need
to
set
it
explicitly.
It's
just
the
client
can't
necessarily
know
that
it
doesn't
know
all
of
the
addresses
that
the
server
might
receive
stuff
on,
but
the
server
does.
So
I
don't
know
you
do
need
that
to
import.
F
F
I
So
I
just
wanted
to
state
that
I
also
added
a
source
property
for
jmf
for
tasks
currently,
so
this
this
is
supposed
to
signal
if
a
task
comes
from
a
was
automatically
created
from
a
mail
or
originated
from
a
web
application
or
a
mobile
application.
H
F
Maybe
people
can
think
about
it
in
email
list
if
they
have
other
thoughts,
but
yeah
it
looks
like
source
is
not
the
best
term
to
describe
here.
So
we
should
come
up
with
something
better
because
it
turns
out
to
be
a
reasonably
important
concept.
That's
referenced
a
few
times
in
respect
for
different.
F
Okay,
so
the
next
question
is
back
about
about
default
calendars
and
you
know
first
of
all:
does
there
have
to
be
one
for
each
account
or
can
there
be
none
set,
which
basically
means
at
that
point,
you
can
pick
whichever
calendar
you
want.
If
you
need
one
like
to
add
an
incoming
invitation
to,
for
example,
we,
the
expected
company,
says
no,
which
is
based
on
our
previous
discussion
because,
as
I
recall
just
because
it's
like
you're
picking
one
at
random
anyway,
so
you
know
why.
F
Why
bother
just
say
explicitly,
I
didn't
pick
what
I
don't
know,
which
one
is
default,
but
it
but
cal
dev
mandates,
one
it.
I
think
ken
reminded
me,
so
perhaps
we
should
match
so
anyone
got
thoughts
on
that
and
then
also
it
is
mandated
like
what
happens
if,
in
various.
B
The
end
of
the
source
discussion-
I
haven't
had
a
chance
to
think
about
this
very
much,
but
is
there
a
by
the
way
I've
got
a
long
echo
that
I'm
hearing.
So
that's
why
I'm
talking
a
little
bit
in
here
I'll
try
to
ignore
it,
but
is
there
any
sort
of
a
security
aspect
to
who
has
the
right
to
send
an
update
to
an
event
and
is
there?
Is
there
a
question
of
whether
the
gmap
server
can
be
trusted
to
not
change
that
that
property
inappropriately.
F
So
this
is
talking
about
the
source
stuff.
Again,
I
presume,
I
think,
yeah
you
you.
F
We
presume
that
you
trust
your
own
calendar
server
to
not
do
something
deliberately
malicious,
because
it
has
all
of
your
data
already
anyway,.
F
And
in
terms
of
processing,
the
updates
and
the
security
bits
around
that,
whether
you
should
accept
like
a
change
of
stuff,
that's
kind
of
out
of
scope
of
jmap.
That's
part
of
it
really.
A
L
That's
barry
lieber
this
this
back
to
the
default
calendar
thing.
This
seems
to
be
analogous
to
the
imap
inbox,
where
imap
specifies
things
that
you
have,
you
have
to
have
an
inbox.
If
you
delete
it,
it
gets
recreated
with
inbox.
If
you
rename
it,
then
a
new
one
is
created
with
the
name
inbox.
You
probably
don't
want
that
for
this,
but
maybe
you
want
to
do
the
same
kind
of
thing
with
this,
as
imap
does
with
inbox.
L
M
Okay,
ken
richardson
yeah,
I'm
clearly
in
favor
of
default
calendar
as
it's
made
by
caldev
and
if
you've
got
a
server,
that's
automatically
processing
itip,
whether
it's
implicit
scheduling
or
or
via
imep.
You
need
to
put
new
invites
someplace.
So
if
the
user
expects
to
receive
invites
they
need
a
calendar
and
they
need
to
tell
us
which
one
it's
going
to
go
to
and
if
you've
only
got
one
calendar.
Well,
then
that's
the
default.
F
F
And
I
guess
well
I,
if
you
look
at
the
slide,
then
you
also
get
questions
of.
Are
there
other
conditions
like
what,
if
this
is
a
read-only
calendar,
so
I
can't
actually
add
stuff
to
it.
So
I
have
a
calendar,
but
it's
not
sufficient
to
be
my
default
calendar.
If
that
makes
sense,
do
we
have
restrictions
on
what
can
be
said?
L
I
said
it's
analogous
to
imap
in
imap
the
inbox
can't
be
read
only
and
like
I
said
you
can't
fail
to
have
an
inbox.
F
M
N
This
is
robert
speaking,
so
I
have
to
say
I
don't
care
so
much
if
a
default
calendar
must
be
specified,
so
I
find
it
perfectly
reasonable
that
the
default
calendar
id
and
the
preferences
might
be
null,
but
it
of
course,
must
still
be.
N
Then
we
could
still
state
that
servers
might
then
pick
whatever
calendar
they
want
to
put
an
invite
into,
and
if
there
is
no
calendar,
as
we
said
has
been
said
before,
while
then
there
is
no
no
invent
can't
be
delivered
at
all
anyway,
but
separate
from
the
fact
if
you
can
set
or
cannot
set
the
default
calendar
id
to
null
what
we
are
doing
in
our
current
implementation.
N
Currently,
we
allow
to
delete
the
default
calendar,
but
we
immediately
pick
a
new
one,
so
this
might
also
be
stated
in
this
back
then
that
the
server
might
pick
a
new
default
calendar
immediately
after
they
destroy
or
implied
not.
That
depends
on
the
implementation.
F
N
Yeah
then,
I
think
it
might
make
sense
if
we
decide
on
that,
to
put
it
also
in
the
spec,
where
it's
currently
saying
that
it's
possible
to
destroy
default,
and
then
it's
set
to
null
still
make
clear
that
the
server
might
choose
what
what
it
seems
appropriate
in
that
situation,
and
that
being
said
for
participant
identities
the
which
we,
which
we
mapped
to
the
caldf
calendar
user
user,
address,
set
property.
N
I
think
these
should
these
two
properties
in
cal,
def
and
jmap
should
be
aligned,
but
the
califs
back
in
6638
definitely
says
that
if
the
if
the
property
is
destroyed
in
caldev,
then
this
disabled
scheduling
for
that
account.
So
in
that
regard
it's
in
that
regard,
it
speaks
to
me
that
the
participant
identities
in
gmap
must
be
non-empty
as
well.
N
F
N
Yes,
what
I'm
trying
to
say
is
also
that
it
shouldn't
be
a
magic.
B
N
F
C
F
Yeah,
it's
more
kind
of
a
data.
Consistency
thing
it's
hard
to.
You
know.
If,
if
you
say
you
have
to
you
can't
delete
the
default
one,
so
you
have
to
you
have
to
end
up
doing
this
dance.
Where
you
create
a
new
one
assign
a
different
default,
then
it's
it's
easier.
I
think
if
you
can
allow
it
to
delete,
delete
the
default,
but
then
there's
the
question
of
what
happens
at
that
point.
Basically
and.
C
That's
where
I
specify
that,
and
actually
from
my
map
experience,
there
are
certain
operations
that
allows
allow
multiple
outcomes
and
it's
actually
having
multiple
outcomes
is
more
difficult
to
code
for
clients.
So
if
you
can
decide
on
one,
then
you
either
don't
allow
deletion
or
if
it's
deleted
it
can
always
be
recreated
unless
there
are
reasons
not
to.
B
B
B
A
G
All
right,
this.
G
One
more
point,
so
I
think
I'm
also
in
favor
of
having
definitely
a
default
calendar,
because
I'm
not
aware
of
a
single
other
system
that
doesn't
have
that,
so
some
systems
even
only
have
the
default
calendar,
groupware
systems
and
so
on.
I
also
wonder
you
know
from
a
ui
perspective:
if
there
wouldn't
be
anyone,
what
would
the
ui
display?
Would
it?
You
know,
need
the
user
to
create
a
calendar
first.
I
think
that
would
be
also
very
weird
and
another
point
it
was
mentioned
before.
G
If
I
delete
the
default
calendar,
some
other
calendar
might
be
promoted
to
be
the
default
calendar.
I
just
want
to
raise
a
point
that
typically
the
default
calendar
in
most
systems,
since
it
pre-exist
doesn't
have
a
particular
name.
So
some
systems
give
it
a
you
know
some
weird
name
like
default
or
the
identity
of
the
user,
or
something
like
that,
and
so
some
systems
might
get
confused
if
the
default
calendar
after
such
and
delete
operation
and
another
calendar
is
promoted
to
be
default,
has
now
a
proper
name.
G
So
there
might
also
be
internet
internet
generalization
issues
we
set
because
uis
will
have
the
default
calendar
displayed
typically
with
a
predefined
string
in
the
system
and
not
with
a
user
given
name
and
that
might
be
broken.
If
you
promote
another
calendar,
this
would
be
the
default
calendar.
So
the
case
I'm
making
here
is
probably
not
being
able
to
delete
the
default
calendar
and
make
another
calendar
as
a
default
calendar.
F
N
M
F
Yeah
yeah
yeah,
I
I
I
think
I
understood
that
like
you,
can
choose
a
different
calendar
to
be
your
default
like
in
caldave,
and
it
can
have
a
arbitrary
name.
We
don't
you
know,
I
don't
think
any
client
just
shows
the
word
default.
F
B
M
Camera
just
said
again:
I
can't
speak
to
the
interrupt
potential
problems
that
hans
york
just
brought
up,
but
to
try
to
clarify
my
previous
thoughts
on
this
and
wrap
things
up.
So
my
opinion
is:
if
the
user
expects
to
have
scheduling
they
need
at
least
one
read:
write
calendar
the
default
calendar
essentially
is
a
user
option
that
if
they
have
multiple
read
write
calendars,
they
tell
you
which
one
they
would
like
new
invites
to
go
into.
M
It's
not
a
mandatory
thing
on
the
server,
it's
a
user
preferences.
This
is
where
I
want
to
see
all
my
new
invites.
That's
really
all
it
is
in
cal
dev,
and
I
don't
think
we
should
make
it
more
than
what
that
is
in
gmat.
M
F
Yep,
let's
move
on
thanks
for
that
everyone,
so
this
is
about
default
alerts
on
calendars.
So
we've
discussed
this
bit
before
that
you
can
have
specified
default
loads
on
cameras
and
then
you
can
specify
on
an
event
to
use
default
alerts
and
just
get
whatever
the
ones
are
on
the
calendar.
That's
in
so
the
first
question
is
about:
if
I
create
a
new
calendar,
should
I
should
the
server
copy
over
the
default
alerts
from
your
default
calendar?
F
If
you
have
a
default
calendar,
I
think
from
the
previous
discussion,
because
at
the
moment
the
the
spec
just
says
the
default
is
null.
So
if
you
create
a
new
calendar,
it
doesn't
have
any
default
alerts
until
you
explicitly
add
them.
F
I
think
again,
while
I
was
writing
up
this
slide,
I
came
to
the
conclusion,
and
so
I'll
just
see
if
other
people
disagree
with
it,
which
was
that
this
can
actually
made
vendor
specific,
because
the
way
jmap
works,
the
server
will
return
if
it
created,
if
it
said
anything
like
copied
over
the
ones
from
your
default
calendar
and
if
you,
if
and
the
client
can
always
explicitly
set
null
or
whatever
he
wants
on
create.
If
he
doesn't
want
the
server
to
pick
something.
A
M
F
M
F
Yeah,
but
I
mean
in
this
case
it's
not
attaching
anything
to
it
in
the
spec
as
such,
it's
just
saying
that
the
when
you
create
a
new
calendar,
if
you
don't.
F
One:
okay,
all
right,
that's
yeah!
What
I'm
saying
really
here
is,
if
you
create
a
new
calendar
and
the
client
doesn't
explicitly
say,
use
these
default
alerts,
including
the
category
of
I
don't
want
any.
Then
the
server
is
allowed
to
set
whatever
default
alerts
it
wants,
which
might
be
copying
over
from
your
default
calendar
or
might
be
something
entirely
different,
whatever
it's
going
to
tell
the
client.
So
it's
up
to
the
server.
M
F
F
Possibly
the
more
interesting
question
is
the
one
on
the
bottom.
This
slide
here,
which
is,
are
you
allowed
to
set
default
alerts
on
a
calendar?
If
you
don't
have
the
may
update
private
apple,
which
is
the
app
we
need
to
be
able
to
update
alerts
on
individual
events
in
that
calendar.
F
A
N
N
Set
to
true
for
you,
it
would
be,
it
would
be
set.
Well.
That
brings
up
the
question
that
we
currently
have
around
shared
calendars,
but
by
the
default
value
of
the
js
calendar
object,
it
would
default
to
false.
So.
F
N
Yeah,
in
that
case,
you
would
you
wouldn't
need
to
be
able
to
set
them
for
this
calendar,
but
yeah
at
the
moment,
where
sherry
of
a
shared
calendar
defaults
to
true
with
usd
for
the
alerts,
then
I
think
it
definitely
needs
to
be
possible
for
them
to
set
the
defaults
on
the
calendar.
Otherwise
they
don't
get
any
alerts
at
all
for
the
event.
N
F
Yeah
yeah
I'll
I'll
go
check
the
cases
and
yeah
try
and
come
up
with
some
insane
cool
all
right.
Let's
have
something
on
that
I'll.
Just
move
on
this
one's
simply
we've
got
this
calendar
preferences
object,
we've
talked
about
last
time
and
we've
got
to
store
now
what
the
default
calendar
is
and
what
your
default
participant
is.
Your
default
identity
is.
Do
we
want
to
put
anything
else
in
there?
F
The
one
thing
that
came
to
mind
is
the
user's
first
day
of
week,
preference,
which
is
just
a
cultural
thing,
if
you
want
monday
or
sunday
as
the
first
day
of
your
week
or
in
a
few
cases
saturday
and
some
other
stuff,
but
mostly
one
of
those
two
is
that
worth
putting
in
here
or
do
we
just
keep
it
simple
for
now
it's
just
the
default
identity
and
calendar,
or
is
there
anything
else,
people
think
should
it's
worth
storing
here
as
a
kind
of
at
the
data
model
layer.
M
F
A
Cool
thanks
ken
daniel.
E
Apologies
for
asking
a
question:
maybe
everybody
else
here
already
knows:
I'm
not
sure
I
understand
why
default
timezone
would
be
a
principal
level
thing,
as
opposed
to
a
per
calendar
thing.
If
I'm
scheduling
for
a
group
that
regularly
meets
on
east
coast
time,
I
want
that
calendar
to
default
to
east
coast
time
and
if
I'm
scheduling
for
a
group
that
meets
in
utc,
I
want
that
group
to
meet
in
utc.
F
Calendars
also,
calendars
also
have
a
time
zone,
but
if,
if
it's
null,
then
it
inherits
from
the
particle
from
the
principle
there
into
the
calendar.
F
F
Because
it
doesn't
actually
affect
me,
the
scheduling,
this
is
purely
a
kind
of
display
preference.
If
you
like.
F
Is
more
stuff,
that's
required
for
scheduling
and
like
if
you
were
looking
up
someone
else
in
your
company
to
you
know
schedule
something
with,
whereas
this
to
me
is
just
purely
a
yeah
user
preference,
which
is
why
it's
in
separate
place.
E
But
that
sounds
like
it
belongs
the
same
place
that
the
that
the
I
mean,
the
the
date
format
belongs
as
well.
Right,
like
everybody
wants
to
see
it
in
their
own
in
their
own
perspective,.
F
F
Okay,
final
slide
of
question
stuff-
I
have-
is
just
nyana
one,
so
the
spec
lists
a
set
of
properties
which
are
treated
as
per
user
properties.
So
this
means,
if
you're
in
team
mode,
then
each
user,
that's
accessing
the
calendar,
they
can
write
to
the
properties,
but
they
would
just
get
their
own
copy
of
them.
F
It
doesn't
affect
the
other
users,
like
your
alerts,
for
example,
so
that
if
you
know
we
both
have
a
shared
calendar
with
with
the
you
know,
team
meeting
next
week,
I
could
have
an
alert
two
hours
before
and
bron
could
have
an
alert
the
day
before.
So
at
the
moment,
the
list
of
properties
that
are
considered
per
user
is
hard
coded
inspect.
F
Do
we
want
to
have
this
in
a
registry
somewhere,
probably
like
it
seems
possible
that
there
might
be
others
in
the
future
that
you
want
to
treat
in
the
same
way?
And
if
so,
do
we
modify
the
js
calendar
spec,
which
already
lists
all
the
properties
but
to
add,
like
an
extra
column,
to
say
whether
it
should
be
treated
per
using
germap
calendars?
Or
is
this
something
we
should
create
just
a
separate
jmap
calendars
registry
for.
A
F
F
Yeah,
okay,
that
sounds
good
to
me
great,
so
just
wrapping
up,
I
think,
we're
almost
there.
With
this
now
implementation
experience
has
been
great.
I
need
to
make
changes
based
on
the
discussions.
We've
had
here
and
add
some
examples
which
I
saw
and
yeah,
but
hopefully
that
none
of
that's
going
to
take
too
long,
and
I
hope
to
get
this
to
last
school
before
the
next
itf
meeting
fingers
crossed.
A
Excellent
next
is
gemma
tasks.
A
Sorry,
neil,
I
just
turned
off
your
audio,
because
this
this
system
is
very
good
at
moving
things
under
you
when
you're
about
to
click,
I
will
put
gen
up
tasks
up
unless
you
want
to
share
it
from
your
phone
and
hand
you
the
microphone.
Thank
you.
I
Hi,
I'm
jos
baum,
so
yeah,
I'm
just
gonna
present
you
what
the
last
changes
are
of
general
for
tasks
and
yeah
present
you
some
of
the
like
most
of
the
changes
resulted
from
the
the
survey
that
I
did
last
time
and
I
also
prepared
some
discussion
points
that
resulted
from
this
survey.
I
So
if
you
can
continue
to
the
next
slide,
yes,
so
here
again
is
the
link
to
the
survey
I
published
on
github.
I
The
goal
of
the
survey
was
to
make
you
know
to
make
jammer
for
tasks
a
more
common
standard,
that's
not
only
specific
to
groupware
systems,
but
also
specific
to
kanban
boards
or
issue
trackers.
So
we
extend
the
idea
is
to
extend
the
spec
here
and
there
to
make
it
a
more
common
thing.
I
Yeah,
so
I
started
with
yeah
some
more
obvious
or,
for
me
at
least
obvious
properties
that
I
added
to
the
spec
and
here's
a
here's,
a
list
of
the
changes.
Basically
so
the
first
thing
I
I
added
is
a
source
property
that
I
saw
in
several
systems,
so
this
describes
where
a
task-
oh
also,
this
is
only
these-
are
only
changes
to
the
task
object.
For
now
they
are
not
not
for
the
task
list
object,
so
the
source
property
describes
from
which,
from
where
the
the
task
comes
from.
I
That's
just
basically
a
simple
string
value,
then
there's
also
an
next
value
is
estimated
work,
which
is
similar
to
estimated
duration,
which
was
already
ready
there,
but
it's
more
of
an
more
abstract
estimation
of
the
amount
of
work
required
for
a
certain
task,
which
is
a
more
or
less
popular
thing
in
kanban.
I
So
you
don't
have
a
time
estimate.
You
have
more
like
a
more
abstract
measure,
then
there's
an
impact
property,
which
is
also
a
simple
string,
which
is
more
popular
in
issue
tracking,
which
has
some
values
like
major
or
block,
for
example,
and
then
there's
a
the
progress
property.
I
Was
I
extended
the
progress
property
with
some
more
values
which
you
will
see
in
the
next
slide,
and
then
I
slipped
in
a
small
mistake
that
nobody
noticed-
and
I
just
noticed
it
like
a
few
days
after
I
published
the
spec
I
added
related
to
which
was
already
in
j's
calendar.
It's.
What
I
wanted
to
do
is
like
to
extend
the
relation
object
with
more
values
so
related
to
can
also
contain
blocked
by.
O
I
Example
currently
it
contains
values
like
child
next
things
like
that.
Okay,
if
you
can
go
on
to
the
next
slide
yeah,
so
the
progress
property
is
a
bit
is
a
bit
of
a
bigger
change.
There
already
were
certain
values
for
it.
The
the
progress
property
basically
displays
yeah
the
progress.
I
Task
and
yeah
there
already
was
needs
action
in
process,
completed,
failed
and
cancelled
and
they're
just
a
bunch
of
other
values
that
exist
in
various
systems.
I
So,
for
example,
there
are
some
simple
systems
that
have
only
done
or
not
done,
which
was
not
so
obvious
for
me
how
to
map
the
simple
done
or
not
done,
progress
indicator,
and
also
yes,
there
were
some
issue
tracking
specific
values
like
deferred
or
waiting
or
resolved,
or
feedback
yeah.
So
basically,
this
is
this
is
the
mapping
here
I
came
up
with.
B
I
N
Yeah,
I
think
it
looks
good
and
I
think
it
would
be
just
simple
to
add
these
to
the
registry
as
sellout
values
for
the
enums
in
I'm.
Not
sure,
if
is
it
also
for
is,
is
it
for
I
calendar
v
to
do's?
I
think
we
already
have
the
needs
action
process
completed
already
or
not
was
the
chest
just
in
the
task
draft,
but
nevertheless.
N
H
N
I
I
They
typically
don't
want
to
have
some
scheduling
mechanism
built
in
or
recurrent
issues
in
an
issue.
Tracker
are
just
not
really
a
thing
so
yeah.
So
that's,
but
that's
like
a
big,
a
big
one
that
I
wanted
to
discuss.
First
because
yeah,
I
think
it's
I
don't
know
it's
kind
of
a
big
change
so
yeah,
so
it
contains
a
lot
of
group,
very
specific
properties
right
now.
I
Yeah,
that's
why
I
tried
to
split
it
into
groups,
and
the
idea
here
was
to
split
it
into
certain
feature,
sets
but
keep
it
in
line
with
jmap,
so
use
the
capability
mechanism
to
to
display
what
the
server
understands,
what
the
client
understands,
but
also
not
make
it
all
too
fine-grained
at
the
same
time.
So
we
don't
want
to
have
20
different
capabilities,
yeah.
So
and
one
thing
I
wanted
to
notice
that
it's.
I
If
we
go
that
road,
then
systems
will
need
to
implement
a
bit
more
than
they
absolutely
need.
But
I
think
that's
just
that's
just
I
don't
know
one
that's
just
necessary
and
what
we
can
do
is
we
can
make
sure
the
overhead
is
just
small
enough
for
kanban
boards
or
issue
trackers
to
spot
to
have
some
interest
in
the
current
spec.
E
Thank
you
for
this
work.
Can
we
go
one
slide
prior?
I
just
had
a
comment
on
on
the
chat
that
I
was
asked
to
take
to
the
mic
confirmed
seems
orthogonal
to
the
other
states
here
and
it
sounds
to
me
like
each
task
has
exactly
one
progress
property,
and
so
I
don't
know
how
you're
expecting
like.
How
do
I
indicate
something
is
say,
confirmed
and
deferred
or
confirmed
and
in
process.
E
That
seems
a
little
bit
confusing.
I'm
also
not
sure
why
we
have
both
resolved
and
completed.
I
wouldn't
know
which
one
to
pick
in
most
contexts.
I
I
E
I'm
not
I'm
not
suggesting
this
problem
is
specific
to
your
document.
Here.
I've
certainly
seen
issue
trackers
where
there
is
a
separate
state
that
is
confirmed,
but
it
is
not
assigned,
but
I
know
that
I
use
issue
trackers
where
whether
something
is
confirmed
or
not
is
independent
of
whether
it
is
assigned
it's
useful
to
know.
Okay,
you
know
here's
a
here's,
something
that
someone's
actually
been
able
to
replicate,
for
example,
so.
E
I
A
I
B
I
It's
actually
yeah,
you
actually
fixed
something.
That's
maybe
I
need
to.
I
mean
to
need
to
specify
that
a
little
bit
more,
that's
a
that's
a
very
good
feedback,
because
yeah,
I
me
too.
I
think
the
the
whole
terminology
is
not
very
obvious.
I
agree
yeah,
but
maybe
also
it
would
need
some
splitting
up.
It's
a
it's,
a
good
feedback
that
I
need
to
look
into
it
a
bit.
M
M
M
So
I
apologize,
I
haven't,
read
the
current
spec,
but
regarding
the
grouping
thing
so
just
to
wrap
my
head
around
the
issue,
are
there
mandatory
properties
in
js
event
that
the
task
folks
don't
want
to
see
or
I'm
trying
to
figure
out
why
we
need
to
either
remove,
not
show
properties?
In
the
event,
that's
the
intent
that
I'm,
I
think
I'm
getting
from.
What's
going
on
here,.
I
I
M
I
I
just
just
wanted
to
understand.
Sorry,
you
said
you
if
they're
not
show
properties
or
no,
I
didn't.
I.
M
I
Yeah
is
my
question
so
the
way
I
understood
it,
a
server
still
needs
to
understand
or
you
if
you
have
a
server
that
implements
the
whole
js
calendar
spec
and
it
it
tells
you
with
its
capability
that
it's
able
to
understand
it.
Then
you
expect
it
to
understand
all
the
properties.
Even
though
they're
optional
or
not,
you
can
just
leave
out
the
not
optional
properties
but
yeah.
G
A
little
bit,
I
think,
the
reason
or
what
we
found
out
in
the
survey
I
think
that
was
presented
at
the
last
itf
is
a
little
bit.
We
found
that
task
systems
in
general
are
much
heterogeneous
and
the
calendar
systems,
so,
for
instance,
each
calendar
system
typically
will
include
recurrences,
whereas
this
is
rather
exceptional,
even
in
groupware
systems.
So
some
like
google
tasks,
for
instance,
there
is
no
such
no
such
thing
as
such
a
recurrence,
and
so
we
argued
somehow,
if
you
want
to
use
this
also
for
an
interoperability
issue
like
systems
might
adopt
jmap.
I
F
I
think
it
was
just
that
I
I
think
the
grouping
idea
with
like
a
reasonably
small
set
of
capabilities
that
can
divide
up
kind
of
like
you've,
said
there
seems
like
a
reasonable
idea.
I
will
have
to
see
you
know
the
the
the
details
and
the
specs,
but
I
I
think
the
virginia
idea
is
kind
of
changed.
I
Okay
yeah,
so
the
current
idea
here
is,
I
don't
know
to
to
group
the
the
the
way
I
tried
to
solve.
It
is
that
I
I
currently
have
a
grouping
of
three
different
in
three
different
groups,
so
the
common
properties
across
all
task
systems
and
there's
a
time
estimation
features
that
are
that
are.
B
I
Like
recurrences
recurrent
tasks
or
some
automated
scheduling
features,
so
if
you
can
go
on
to
the
next
slide,
I
have
them.
I
have
them
a
bit.
Yes,
okay,
so
there
again
the
three
the
three
ones.
Yes
so,
and
here
is
a
list
of
the
of
the
classes
that
would
be
inside
the
common
group.
I
don't
want
to
go
through
all
of
them.
It's
just
to
get
you
like
a
glimpse.
What's
what
what's
my
first
initial
idea
of
having
in
there
yeah?
I
Yeah,
so
it
makes
sense
to
group
them
somehow.
If
you
continue
to
the
next
one
are
the
time
estimation
properties
which
basically
would
add
alerts
and
time
zone
classes
and
yeah
also
add
some.
Some
time
estimation
properties.
As
I
said,
the
estimated
work,
estimated
duration.
I
So
yeah,
that's
a
the
first
idea
of
grouping
that
and,
as
you
can
see,
it's
quite
a
lot
already
and
it
I
just
think
to
spark
interest
for
issue
tracking
and
and
also
kanban
boards.
It
makes
sense
to
yeah
so
either
we
we
say
it's
not
really
required
to
implement
the
whole
thing
in
general,
or
we
say
it's,
there
are
certain
sets
that
you
can
choose
from
like
yeah
yeah,
okay,.
M
This
is
kind
of
again,
so
I
I
think
I
finally
understand
where
we're
going
here.
So,
okay,
I
I
think
what,
rather
than
specifying
which
properties
go
in
various
groups,
I
think
you
should
just
come
up
with
different
levels
of
capability,
so
anything
in
common
which
would
you
describe
in
the
text
would
essentially
be
mandatory
to
to
implement
four.
B
M
Which
we
all
we
need
to
be
interoperable
anyways
and
I'm
either
very
repeat,
probably
said
that
before
I
did,
then,
if
you've
got
other
levels
of
feature,
sets
you
describe
in
the
text
what
that
feature
set
entails
in
terms
of
properties
and
just
make
those
sub
capabilities
underneath
the
actual
js
task
capability.
So
within
the.
M
M
I
A
N
Okay,
so
so,
if
that
grouping
comes,
then
I
would
suggest
to
also
introduce
a
new
set
error
for
a
task
set
so
that
you
don't
have
necessarily
an
invalid
properties.
Error
might
not
be
appropriate,
because
the
system
most
likely
will
know
about
the
property,
but
decides
not
to
implement
it.
So
probably
I
don't
know
like
a
not
supported
set
error
that
might
even
give
the
required.
N
Might
be
a
good
thing,
but
yeah
I
would
just
as
to
use
a
set
error.
That's
that
can
be
discerned
from
a
from
a
regular
invalid
properties.
Error.
N
Sorry
about
that
yeah,
but
on
the
other
hand,
it
needs
to
know
that
it
only
advertises
in
its
capabilities
a
subset
of
the
js
task
properties.
So,
in
a
way
I
would
expect
the
implementation
to
be
able
to
at
least
know
about
properties.
It
doesn't
support
so
but
anyway,.
M
This
is
kind
of
again
so
agreeing
with
robert
that
for
the
the
base
draft.
Yes,
an
implementation
should
know
if
it's
excluding
certain
features
and
properties,
but
if
there's
an
extension
to
this
draft
down
the
road,
you
can't
expect
the
current
implementation
to
know
what
hasn't
been
implemented
yet
so
I
can
see
there
makes
there's
a
case
for
unsupported
capability,
but
then
for
other
things
that
it's
totally
unaware
of
not
supported,
still
makes
sense.
M
N
I
Is
it
fine
okay?
So,
here
again
I
I
wrote
down
a
mapping
between
different
task
systems
and
the
groups
that
I
currently
am
using
just
to
double
check
that
the
grouping
kind
of
makes
sense
so
for
grouper
system.
Obviously
we
typically
want
to
have.
I
I
Can
imagine
there
is
one
out
there
that
doesn't
need
time
estimation
or
advanced
scheduling
for
kanban
systems
yeah
they
would.
They
would
typically
use
a
time
estimation
thing,
but
they
could
do
without
recurrences
and
and
scheduling
properties,
for
example,
microsoft,
planner
and
extorted
trello,
and
for
issue
tracking
systems.
I
They
typically
make
do
with
the
common
group
already
with
some
slight
exception
for
gyra
and
red
monday.
They
have
one
do
property,
as
I
saw
yeah,
but
I
think
roughly
the
it
kind
of
looks
like
it
makes
sense
right
now.
The
groups
that
I
chose
but
yeah,
of
course
it's
not
the
final
iteration.
So,
okay,
if
you
could
go
to
the
next
slide,
yes
blob
created,
I
already
sent
the
mail
to
the
mailing
list
about
that.
So
I
saw
that
in
several
systems
as
well,
so
they
they
tag
an
attachment.
I
Basically,
with
the
time
it
was
created,
it
was
uploaded.
The
first
question
I
I
would
have
is:
do
we
actually
want
to
have
this
in
this
back?
It's
not
a
very
important
thing.
I
think,
but
it's
it's
a
nice
to
have,
I
would
say
and
yeah
and
if
you
want
this
yeah.
B
I
F
Yes,
I
was
just
going
to
say
it
should
definitely
be
the
thing
that
references,
the
blob
that
has
created
that's
the
thing
that
has
all
the
metadata.
The
blob
itself
is
just
the
bytes
of
data
like
you
can't
assume
that
you
know
it
could
reuse
it
between
users,
even
if
you
know
to
save
space
and
reference
count.
It
like
the
metadata
is
all
in
the
thing:
that's
referencing
it.
So
that's
where
that
should
go.
If
you
have
it.
I
So
and
the
the
question
that
I
have
is:
would
that
be
the
for
jay's
calendar?
It
would
be
the
the
for
this
particular
thing.
It
would
be
the
links
the
the
link
object.
I
So
I'm
not
sure
would
we
just
extend
the
link
object
with
a
single
property,
or
would
that
be
sufficient?
I
don't
know.
F
N
Okay
yeah,
as
I
wrote
on
the
mailing
list
already
yeah,
we
can
add
we
could
add
the
created
timestamp
to
the
link
object.
N
If
we
do
that,
I'd
rather
say
we
should
add
it
to
any
object,
because
why
only
for
link,
then,
if
you
really
want
to
track
the
timestamp,
when
this
object
was
added
and
with
that
being
said,
I
promised
two
itfs
ago
to
come
up
with
a
spec
that
tracks
property
changes
in
a
in
a
that
that
fits
all
jmap
object
types
basically,
so
we
could
also
take
this
as
a
as
an
initiative
now
to
where
this
might
be
already
useful,
so
yeah,
I
would
even
prefer
the
last,
but
it
means
more
work
for
me,
but
I
might
find
time
to
come
up
with
a
draft
and
and
and
that
it
comes
quite
in
time
for
gmat
tasks
too
yeah.
A
A
A
I
want,
I
want
to
say
this
file
was
created
six
months
ago
and
that
you're
not
going
to
be
able
to
a
gem
up
event.
History
is
not
going
to
give
you
that,
so
it
would
be
a
separate
property
yeah.
N
This
is
what
I
wrote
on
the
mailing
list,
so
it
very
much
depends
on
the
semantics
of
the
created
timestamp.
If
it's
to
create
a
timestamp
for
the
link,
then
I
would
assume
that's
when
the
link
object
was
created
when
it's
the
created
timestamp
for
the
underlying
data
on
disk,
then
that's
something
different,
so
I
don't
know
what
what's
the
purpose
of
of
the
created
timestamp
in
this
context.
I
G
G
You
know
potential
items
which
is
something
you
typically
can't
do
in
most
other
systems.
So
I
think
what
we
are
talking
about
here
is
really
like
when
the
user
linked
it
to
the
actual
item,
irrespective
of
when
the
actual
file
was
already
created,
which
I
understand
which
I
understand
in
the
jmap
system
might
even
be
from
another
user.
Probably
I
don't
know
yeah.
So
I
think
what
we're
talking
about
here
is
really
in
the
context
of
the
item,
the
link,
the
time
of
link.
I
I
It
probably
makes
sense
to
keep
that
in
sync
with
the
category
categories
property
so
to
be
able
to
do
that
with
that
as
well,
and
it
might
also
make
sense
to
do
that
in
gmo
for
calendars
as
well
to
not
be
able
to
do
that
for
tasks
only,
but
also
for
calendar
events.
So
is
there
an.
F
I
F
F
You
know
you
should
have
a
like
a
taskless
object,
because
it's
a
this
is
another
way
of
it's
like
a
label
essentially,
and
then
you
just
reference
that.
I
Right
now,
but
yeah,
it
might
make
sense
to
sync
that
with
categories
as
well,
so,
okay,
yes,
future
work
is
basically
we
still
have
to
get
some
more
feedback
or
yeah.
From
from
the
from
the
task
system,
vendors
we
already
prepared
something
for
that
still
needs
to
happen,
and
also
there
are
still
two
more
or
less
complex
properties
like
comment
which
we
don't.
I
N
Okay,
I
just
have
com
short
commands
for
the
properties
that
were
mentioned
at
the
beginning,
so,
okay
for
estimated
work.
N
I
think
this
property
is
useful,
I'm
not
sure
if
it's
useful,
if
it
has
an
arbitrary
number
in
it,
because
I
would
assume
that
the
meaning
of
these
numbers
will
differ
by
teams
or
by
products
so
yeah,
I'm
not
sure
how
much
value
is
in
allowing
just
any
number
without
giving
hints
what
number
range
indicates.
What
for
the
impact
property?
N
I
wonder
if,
if
that
can
be,
if
that,
if
that
is
necessary,
if
the
priority
property
is
enough
and
what
was
the
last
year
for
the
source
property,
I
wonder
how
how
much
value
it
provides
if
it's
just
a
free
text,
if,
with
different
implementations,
put
the
same
thing
in
or
could
there
be
an
enumeration
of
of
of
typical
cases
where
source
property
is
set
or
should
that
be
the
product
id
of
whatever
product
generated
was
the
source
of
that
task
yeah,
so
I'm
I'm
not
sure
how
a
free
text,
video
alone
will
be
inter-available
between
systems.
I
H
A
C
So
yeah
as
a
reminder,
this
is
to
gmap
extension
to
allow
signing
and
or
encrypting
on
send.
So
there
are
two
boolean
attributes
added
by
default.
They
are
absent
and
you
know,
may
the
signing
or
no
encryption
would
happen
if
both
are
specified,
then
its
first
message
is
first
signed
and
encrypted
next
slide.
C
One
is
to
what
extent
we
need
to
control
how
the
sign
message
is
generated.
There
are
two
common
ways
of
doing
this:
using
multiple
sign
or
application.
Pks7
mime-
if
I
don't
get
any
feedback
learning
tentatively
I'll,
probably
suggest
that
there
is
a
boolean
to
control
this
with
application
cases,
seven
mind
being
the
default
as
far
as
header
protection
is
concerned.
Lamps
working
group
is
working
on
this,
and
actually
this
atf
will
announce
that
we
made
some
progress
on
this,
so
there
is
some
hope
that
this
document
will
complete.
C
So
I
would
say:
yes,
we
probably
need
to
have
another
boolean
to
control
this,
for
backward
compatibility
with
the
default
being,
probably
no
don't
protect.
Headers.
A
E
Yeah
I
mean
lexi
may
feel
differently
about
where
we're
landing
on
the
header
protection
draft,
but
I
believe
we're
in
the
position
where
the
default
should
be
able
to
be
true,
because
I
think
the
generated
messages
won't
actually
have
problems.
E
The
second
question
is
about:
how
do
you
think
the
s
mime
signing
we're
talking
about
delegating
here,
secret
keys
to
the
jmap
server?
Yes,
okay,
that
definitely
changes
the
idea
of
end
to
end
at
some
level.
C
Yes,
and
depending.
E
A
Yeah,
the
theory
here
is
that
maybe
the
gem
app
server
and
the
jmf
client
are
within
devices
under
your
control,
so
that
is
still
your
end
for
that
purpose,
gmap's,
not
really
designed
so
much
to
to
only
pass
encrypted
blobs.
If
you
did,
then
there's
no
point
having
this
at
all.
So
if
you
are
using
this,
it's
because
you
believe
that
you
control
the
server
as
well,
and
so
it's
part
of
your
end.
E
C
So
yeah
I
will
at
least
implement
the
first
two
changes
next
time
and
then
we
talk.
We
can
talk
about
decryption,
which
is
it's
kind
of
complementary
feature,
but
it
will
require
different
approach.
A
Yeah,
that's
the
last
slide,
yeah
the.
So
what
I
think
I
understood
from
that
was
that
we
could
make
it
be
default
to
was
it
signing
true
if
you
request
the
capability
for
this.
Obviously,
if
you
don't
request
the
capability,
then
then
this
property
doesn't
exist,
but
we
could
default
it
to
true.
C
Everything
I
think
gkg
was
talking
about
header
protection,
actually.
A
A
So
looking
at
the
agenda
for
extra,
the
first
item
we
had
on
here
was
extra
quota,
which
is
with
the
editors.
Is
there
anything
to
say
on
extra
quota.
C
No
I've
said
it.
I
basically
noticed
that
some
text
to
an
eye
on
a
website
was
out
of
date.
I
sent
a
separate
ticket
to
anna
to
update
it.
It's
sort
of
a
procedural.
I
think
they
they
don't
want
to
publish
rfc
unless
this
is
sorted,
but
even
like
the
page
saying
you
know
who
approved
the
rfc
publication
already
disappeared.
So
I
assume
that
it's
sort
of
like
it's
near
imminent.
A
C
Yes
very
quickly
about
this.
C
C
I
think
we
have
one
little
pending
things
about
reject.
We
want
to
add
a
comment
saying
that
it
with
which
actions
it
conflicts,
which
might
be
useful
information.
O
C
Basically,
I
think
people
need
to
check
what
we've
done
and
you
might
as
well
send
it
to
working
group
last
call.
M
This
is
ken
regarding
sif's
news:
no
updates
to
the
draft.
It's
been
implemented
in
cyrus
imap,
it's
been
deployed
at
fast
mail.
It
works
as
intended
as
expected
firing
any
other
feedback.
I'd
like
to
ask
for
working
group
last
call.
C
A
All
right
we
now
since
what's
up
there,
we
might
as
well
talk
about
process
imap.
M
Sure
so
this
is
an
idea.
I
sent
an
email
to
the
mailing
list.
A
few
months
back,
sketching
out
what
we
intended
to
implement
in
cyrus
imap
went
back
and
forth
between
an
action
to
a
test
back
to
an
action.
I
finally
documented
what
we
have
implemented
in
cyrus
imap,
which
is
on
the
next
slide.
M
So
this
is
what
it
looks
like.
We've
got
five
different
options
there.
First
one
is
a
list
of
addresses
if
they
are
outside
of
what
the
server
would
normally
know.
This
is
analogous
to
the
addresses
parameter
in
vacation
so
that
the
user
would
tell
the
server.
These
are
the
identities
that
I
have
normally
email
addresses,
so
any
invite
or
reply
that
I
get
for
one
of
these
addresses
you
can
go
ahead
and
process.
For
me,
next
set
is
a
it's
a
mutually
exclusive
pair.
M
Ultimately,
if
you
do
not
want
to
get
spammed
with
invites
from
untrusted
users,
you
can
tell
the
server
only
process
updates,
which
would
mean
replies
from
other
users
or
or
I'm
sorry.
It
would
mean
updates
only
meaning
changes
from
an
existing
event
on
your
calendar
or
cancel,
or
that
kind
of
thing
third
option.
We
tell
the
server
if
I
do
receive
a
cancel.
Please
remove
this
from
my
calendar
and
then
the
other
two
are
optional.
M
If
you've
got
the
variables
extension
enabled
two
different
variable
names,
one
to
give
you
a
set
of
thick
strings,
what
the
outcome
of
the
action
was.
This
could
be
anything
from
no
action
to
updated
to
added,
and
I
think
there's
one
other
one
in
the
spec.
I
forget
what
it
is
off
top
my
head
and
the
last
option
is
another
optional
variable
which
would
give
you
a
human
readable
string
explaining
the
actual
outcome
most
notably
if
it's
a
an
error
or
a
failure.
M
So
that's
what
we
have
I'm
here
to
see
if
there's
interest
from
anybody
else
and
moving
this
forward
and
formalizing
this
as
a
spec.
This
has
been
implemented
again,
as
I
said
in
cyrus
imap.
We
deployed
it
to
some
of
our
users
last
week
and
it
appears
to
be
doing
what
we've
had
previously
done
in
middleware,
as
opposed
to
directly
in
civ.
P
C
C
Wrong
is
just
unusual,
but
I
think
that's
a
fine
solution
as
far
as
the
outcome
values
concerned,
I
think
it
would
be
better
if
you
split
update
and
cancel
into
two
different
values
it
just
I
don't
know
it
seems
cancelling
and
possibly
removing
the
event
might
mean
something
different
from
just
updating
it,
so
I
might
want
to
do
something
different
based
on
that.
C
The
other
comment
is
now
that
cf
action
is
going
to
be
in
last
call.
We
need
to
add
it
to
this
to
the
document.
M
Yeah,
this
is
kind
of
guy.
I
realized
that
last
week
and
didn't
get
a
chance
to
push
another
update
figuring
that
I
was.
I
got
added
unknowingly
to
the
civ
action
spec.
I
should
probably
follow
that
spec.
There
actually
is
a
a
example
of
what
this
looks
like
on
the
next
slide,
but
it
still
doesn't
change
the
question
out.
There
is
if
anybody
else
feels
this
is
work
worth
adopting
in
the
working
group
and
moving
forward.
G
Hi
this
is
jerk.
I
have
just
a
tiny
question
and
maybe
I
actually,
I
have
to
admit
I
didn't
read
the
draft
yet.
But
my
question
is
from
what
I
see
I'm
asking
myself,
you
know:
is
there
a
standard
way?
Imap
is
currently
implemented
in
systems,
because
it's,
I
guess,
not
really
standardized
how
it's
done.
Architecturally
and
this
somehow
hooks
in
you
know
somehow
of
kind
of
a
dependency
which
in
some
systems
might
you
know,
create
architectural
issues
in
some
way,
which
is
not
necessarily
an
overall
issue.
G
But
I'm
just
wondering
this
is
something
one
should
maybe
state
for
potential
implementers
of
this
that
there
might
be
wider,
ranging
consequences
of
implementing
that.
M
P
C
Before
probably
the
it
was,
primary
processing
might
have
been
unconditional
on
hard-coded
how
it's
handled
now,
you
can
say
only
accept
invitations
from
this
set
of
people.
For
example.
You
know
and
do
a
few
fancy
things.
A
I'll
do
a
call
for
adoption
on
the
list.
It
sounds
like
this
there's
nobody
violently
objecting
to
the
idea,
so
we
may
as
well
go
ahead
if
adopted.
I
might.
C
L
A
C
Right,
I,
I
actually
updated
the
title
of
the
document
because
it
actually
has
sort
of
two
related
extensions.
Now.
C
Do
you
want
to
know
so?
Basically,
in
imap,
if
you
do
search
typically
search
will
do
the
full
mailbox
search,
you
can
say
only
return
and
messages,
and
first
or
second
page
whatever.
C
This
helps
the
client
to
receive
less
data
as
well
as
servs
saves
server
work
once
it
reaches
the
number
of
messages
it
can
stop
doing
it
somewhat.
Similar
example
is
with
uig
fetch.
You
can
have
a
uid
range
where
you
don't
actually
necessarily
know
how
many
messages
in
the
range.
So
again
you
say
if,
if
my
client
can
only
show
10
000
messages,
there
is
no
reason
to
return
hundred
thousand.
C
You
know
if
it's
so
many
in
the
range,
so
you
can
say
just
just
return
me
first
or
you
know
yeah
next
slide
and
I
mean
for
smaller
mailbox
on
mailboxes.
It
doesn't
matter
that
much,
but
this
is
concerned
with
large
mailboxes,
say
50k
and
more
so,
as
I
said,
search
return
option
for
returning
page
or
mul.
It's
a
range
of
messages
in
the
response.
C
C
A
C
What
minus.
C
C
C
C
Cool-
and
this
is
how
the
fetch
example
works
again,
you
know
some
cl
if
you
know
how
many
messages
in
the
range
or
in
the
uid
fetch
range.
That
is
not
as
useful,
but
if
you
don't
or
if
you
want
to
page
through
results,
then
it
gives
you
more
control
over
this
next
slide.
C
K
C
C
Do
the
search
and
save
the
result
in
a
variable
right
and
the
interaction
between
the
two
weren't
actually
specified
so
timothy
ryan
and
from
duff
code
asked
about
interactions,
and
now
this
is
clarified
next
slide.
C
So
there
were
actually
a
fair
amount
of
changes
since
version
zero,
but
most
of
them
were
not
related
to
the
partial.
The
main.
C
Clarification
about
partial
is
that
if
it's
used
with
constore
it
exp,
it
is
explicit
how
they
use
together.
So
you
can
say,
send
me
flag
changes
for
all
messages,
change
this
timestamp
and
only
return.
So
many
of
them.
C
C
C
I
think
they,
a
message
limit
and
sort
can
be
used
together,
but
you
either
need
to
have
a
special
index
or
you
say
well,
this
mailbox
is
too
big,
so
I
cannot
do
it
thread
and
message
limit
cannot
be
used
together.
If
the
mailbox
has
more
than
message
delivered
messages,
it's
just
not
going
to
work
because
threading
doesn't
work
with
partial
sub
data,
basically
well
sort
of
gives
you
corrupted
threats
which
are
not
very
useful.
C
Don't
remember!
Do
I
have
a
next
slide.
C
One
of
the
things
that
this
is
trying
to
address
is
the
client
can
say.
Well,
I
want
to
copy
all
messages
from
the
mailbox
to
another
mailbox.
You
have
hundred
thousand
messages
message
limit.
Is
ten
thousand
so
do
you
just
fail
to
do
the
operation
altogether
or
do
you
copy
ten
thousand
messages
and
say?
Well,
I
only
partially
completed
you
need
to
retry
with
other
with
the
remainder
of
them.
If
you
care,
this
is
kind
of
tricky
because
we
never
had
copy
failed
partially
before,
but
this
is
trying
to
do.
C
We
want
to
all
the
clients
that
don't
support
this
become
unusable
because
they
don't
understand
this
response
code
or
so
that's
kind
of
a
tricky
question.
I.
C
No,
it's
not
how
it
works.
I
mean
yes,
it
might
be
a
valid
reason,
but
the
way
it
works
at
the
moment
is
it
says
he
says,
copy
hundred
thousand
messages.
It
will
copy
ten
thousand
and
return
okay
with
message
limit,
so
the
naive
client
will
say:
oh
all,
the
hundred
thousand
messages
got
copied,
but
on
actually
only
ten
thousand
for
a
pocket.
A
C
C
That's
the
thing
the
client
basically
needs
to
be
updated
to
know
about
about
the
limit
and
doing
batches.
I
don't
know
I
I
keep
flipping
back
and
forth
about
this.
This
is
kind
of
tricky,
but
we
can
discuss
yeah.
M
L
L
L
So
I
think
that
if
the
server
has
a
limit
and
the
client
tries
to
do
something
above
that
limit,
it
just
gets
no
and
nothing
happens,
and
then
the
client
that
a
client
that
understands
message
limit
knows
what
to
do
with
that
or
shouldn't
have
done
it
in
the
first
place.
But
a
client
that
doesn't
know
just
has
to
throw
up
its
hands
because
it
has
no
way
to.
C
So
what
we
are
saying
users
will
try
their
clients
with
the
server
like
this
will
be
unable
to
do
it.
We'll
have
to
complain
to
their
client
client
says.
Well,
I
didn't
I
I
didn't
implement
this.
Why
do
I
want
to?
Then
there
is
a
discussion
with
the
server
vendor,
whether
you
know
whether
they
want
to
implement
it.
C
A
C
L
And
still
barry
the
to
go
to
what
ken
said
with
what
do
you
do
if
you
rename
inbox?
I
think
that
has
to
be
an
exception
to
message
limit.
I
think
the
server
just
has
to
do
it,
even
if,
if
the
server
has
a
message
limit
of
100
and
there
are
10
000
messages
in
the
inbox
and
you
rename
the
inbox
while
the
server
can
say
no
or
the
server
just
has
to
do
it
and
move
all
10
000
right.
C
O
C
Can
you
actually
send
this
in
send
the
email
to
the
mailing
list,
because
I
think
it's
probably
worth
just
saying
this
explicitly:
no
send
the
reminder
to
the
mailing
list
saying
about
what
about
renaming
box
with
more
than
message
limit
messages?
What
will
happen
and
we'll
just
say
server
just
has
to
do
this.
We
can
add
an
explicit
statement
as
a
reminder
for
server
implementations
to
do
this.
A
Great
thanks
alexi
is
that
everything
you
got
one
more
slide.
Next
step
seems
ready.
M
This
is
kent,
so
I,
as
a
server
dev,
I
think
partial,
is
pretty
straightforward.
To
implement
question
for
alexi
is
a
as
a
client
of
have
you
actually
implemented
on
your
site,
so
we
know
it
operates
the
way
you
expect
expected
to
operate.
B
C
Implement
it
in
the
client
side,
but
I
didn't
test
it
with
my
server
yet
so
that's
why
I
was
hesitating.
I
did
it,
but
I
just
I
think
it
worked
it's
fine.
It
actually
makes
handing
off
big
mailboxes.
Like
webmail
clients,
you
know,
if
you
can
only
display
you
know
10
pages
or
15
messages.
It
makes
it
much
easier
to
implement
because
you
don't
need
to
download.
You
know
the
whole
map
for
100.
A
C
C
A
Yeah,
I'm
happy
to
to
have
a
working
group
last
call
on
this
as
one
or
two
documents,
and
I
have
to
do
a
separate
working
group.
Adoption
call
sorry
on
on
one
or
two
all
right.
M
A
Got
submit
document
for
blobs
via
gmap
to
asg
is
going
to
have
to
move
forwards
to
next
months,
basically
submit
civ
document
to
isg,
that's
also
for
april.
I
guess
we
decided
that
the
gem
up
sieve
is
ready
for
last
call.
M
I
was
hanging
on
to
this
because
I
wanted
to
get
some
implementation
experience
with
the
civ
test
method.
Okay,
but
if
we
want,
I
could
break
that
out
and
we
could
make
it
a
an
extension
down
the
road.
No,
I
think.
A
It
should
be
fine
just
to
we
can.
We
can
test
that
within
a
month
we'll
send
it
to
working
group
last
call
and
test
it
during
that
time.
Fine
sender,
extensions,
we're
ready
to
last
call
that
now
alexi,
no
fair
enough.
A
A
A
Yep
I'll,
say
july:
we'll
get
it
by
next
time
here:
jason
contact
document
and
I
need
to
move
that
because
it
belongs
in
the
other
work
group.
Now.
Q
A
That's
I
mean
it
should
have
been
done
by
april
2021,
but
we're
where
we
are.
Thank
you
for
that.
I've
deleted
the
js
contacts,
that's
being
moved.
Gmap
we
said,
was
basically
ready
to
go
and
that
that
says
june
all
right.
A
D
A
A
A
A
A
Yep,
this
was
more
whether
we
were
going
to
this
was
going
to
take
on
the
other
email
related
stuff.
A
Is
before
email
call
started,
I
think
we
decided
to
question
whether
it
was
going
to
happen
here
or
not.
Oh
yeah,
the
discussion
that
happened
in
dispatch
this
morning.
I
think,
probably
that
whole
question
will
either
just
close.
The
update
charter
here
delete
it
and
work
out
what
we
want
to
do
later.
A
A
A
It
was
a
little
bit
wild,
not
having
a
microphone
at
the
table.
I
had
to
hold
this
thing
the
whole
time.