►
From YouTube: IETF114 JMAP 20220728 1400
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
All
right,
10
o'clock,
so
I
guess
we
should
probably
start
to
be
on
time,
I'm
jim
fenton.
Of
course
this
is
braun
you're
in
the
jmap
session,
or
of
the
of
the
gmap
extra
joint
session
extra
will
be
following
jmap.
A
A
If
you
haven't
read
this
in
detail
and
read
the
reference
documents,
you
need
to
do
that
because
it
by
participating
here
there
are
all
sorts
of
issues
with
respect
to
to
intellectual
property
rights
and
so
forth
that
you're
granting
and
also
we
expect
you
to
abide
by
the
anti-harassment
procedures
and
so
forth
and
to
continue
wearing
your
masks
when
you're
not
eating
breakfast.
A
A
So
please
use
the
the
the
meat
echo
tool.
You
can
scan
the
qr
code
at
the
front
if
you're
not
there
already,
it
looks
like
there's
a
yeah.
We've
got
pretty
pretty
good
turnout
for
the
for
the
meat
echo
tool
at
this
point.
So
that's
great
and
use
that
when
you're
going
to
join
the
microphone
queue,
if
you're
not
doing
if
you're
not
actively
presenting,
please
turn
off
your
audio
and
video,
and
also
your
other
audio
noise
maker
sorts
of
devices.
A
And
continue
to
wear
your
masks
unless
you're
actively
speaking
at
the
microphone,
and
actually
we
found
that
as
I'm
doing
right
now,
when
you're
actively
speaking
in
the
microphone,
you
can
probably
be
understood.
Even
if
you
keep
your
mask
on.
A
And
this
is
this
is
kind
of
very,
very
top
level
we'll
be
starting
with
the
jmap
following
with
extra
and
any
other
business,
and
was
there
a
more
detailed
one
for
yeah
on
next
page?
Okay,
so
here
are
the
the
the
different
drafts
we're
going
to
be
basically
going
through
the
current
drafts,
and
we
have
a
couple
of
proposed
work
items
that
we're
going
to
discuss
following
that
and
then
we're
going
to
go
back
over
over
our
milestones
as
we
usually
do,
and
then
extra
will
be
following
a
similar
format.
B
B
B
B
It's
there
refresh
text
ready
to
be
shared.
It's
not
there
wow,
okay,
I'm
doing
great
with
data
tracker
so
far,
not
only
of
with
the
medical
thing,
not
only
these
slides,
not
in
there.
Despite
the
fact
that
I
did
hit
the
refresh
there,
you
go
now
they're
there.
But
apparently,
if
you
direct
message,
somebody
what
you
write
doesn't
show
up
in
the
system
anymore,
hey,
there's
really
not
much
to
say
since
last
iatf.
B
B
So
that
seems
quite
a
useful
thing
to
do
and
you
can
also
request
a
digest
of
the
entire
content
of
a
blob,
which
again
will
be
quite
handy
for
checking
that
you
have
the
right
thing
downloaded,
and
so
I
need
to
add
some
more
text
around
that
advice
to
implementers
and
some
examples
at
which
point
we'll
do
the
third
working
group
last
call,
and
hopefully
the
final
working
group
last
call
before
shipping.
This
thing
I
don't
think,
there's
anything
else.
We
want
to
add
to
blob
at
the
moment.
B
So
let's
just
get
this
one
done
any
comments
on
that
anything.
I
see
a
thumbs
up
awesome
I
think
I'm
done
then.
Let's
move
on.
A
Yeah,
okay,
so
quotas
is
the
next
one.
We
have.
C
C
To
stop
to
to
block
the
user
to
for,
to
send
outgoing
events
like,
like
outgoing
emails,
outgoing,
creating
new
calendar
events
and
stuff,
but
you
would
still
be
able
to
get
emails
even
get
incoming
events
like
emails
and
calendar
events
created
by
somebody
else,
the
example
as
well.
I
I
missed
when
we
changed
the
result
from
size
to
octet.
I
I
missed
changing
it
in
the
example.
So
that's
that's
a
good
catch.
C
I
fixed
that,
and
I
added
also
some
more
content
to
the
security
consideration
section
regarding
the
alexa's
rsc,
what
he
did
as
well
for
kota's
on
imap,
and
so
I
didn't
get
some
warnings
and
advice
on
the
implementation
and
that's
pretty
much
it
for
me.
If
anybody
has
questions
or
I
feel
good.
B
Just
before
you
disappear,
what
do
you
want
to
do
for
the
next
step,
so
we're
ready
to
work
and
grip
last
call
list.
C
C
D
Yeah,
just
a
quick
reminder,
so
this
is
basically
for
sending
s
mime,
signed
and
or
encrypted
messages.
The
two
main
attributes
on
email
set
is
s
mime
sinus,
my
encrypt.
This
hasn't
changed
next
slide.
D
D
D
This
is
a
feature
of
s
mime.
There
is
a
document
in
lamps
about
how
to
do
this
and
suggestion
was
to
make
the
default
rule.
So
the
address
is
all
the
email.
Header
is
always
protected
next
slide,
so.
E
Yeah,
I
I
read
the
draft,
I
think
it's
looking
pretty
good.
I
just
had
one
bit
of
bike
shedding
was
related
to
the
previous
thing
slide,
which
was
just
the
name
of
that
header.
Protect
field
seems
inconsistent
with
the
others.
Could
we
rename
it
something
like
s,
mind,
protect
headers
or
something
like
that?
Like
mine,
sign
a
page.
F
D
D
I
yeah
I
ran
out
of
time
to
to
do
this
this
this
this
round,
but
yeah.
I
think
that's
only
thing
outstanding,
so
I'll
get
to
it
next
time.
B
Timing,
I
guess
what,
when
do
you
expect
to
to
have
this
ready
for
working
group?
Last
call.
A
A
You
need
to
go
to
the
microphone
and
you
should
probably
join
the
queue
via
the
tool.
If
you
can.
F
F
I
had
just
a
quick
question
about
the
last
point
that
alexa
mentioned
about
the
decryption
of
part
of
the
s
mine
thing
and
to
be
fair,
I
haven't
really
read
the
specs.
I
mean
I'm
coming
from
something
which
is
zero.
My
only
point
is
the
decryption
part.
Should
it
not
be
handled
by
the
client,
I
mean
how
would
the
whatever
the
server
would
know?
Actually
what
keys
to
use
to
decrypt
it
that's
a
sort
of
a
question
and
how
this
thing
works
might
be
a
slightly
off
topic.
D
Right,
and
so
basically,
because
that
is
part
of
the
extension
is
to
be
able
to
sign
and
encrypt
there
are
already
keys.
So
if,
if
it
has
assumption
is
there
is
some
kind
of
directory
or
storage
which
is
trusted
by
by
the
user
associated
with
jmap.
D
D
Yes,
yes,
and
I
mean
in
my
implementation,
we
actually
have
keys
kind
of
well
csr
and
certificate
author
generated.
So
again
you
know
you
can
extend
this
to
automatically
create
and
install
certificates
in
your
you
know,
store
and
then
use
this
to
sign.
Encrypt.
A
H
I'm
yours
yeah,
so
in
general
tasks,
just
a
quick
reminder:
what's
the
goal
that
we
want
to
have
what
we
want
to
achieve.
We
want
to
make
a
common
standard
also
for
kanban
boards
and
issue
trackers,
so
not
just
for
groupware
next
step.
Please!
H
Oh
there's
a
that's
a
screen,
okay,
so
yeah.
So
basically,
this
is
a
list
of
all
the
things
that
we
discussed
at
last
itf
that
should
now
be
hopefully
sufficiently
worked
in.
So
the
first
thing
is
was
an
error
of
mine.
I
edit
related
to
instead
of
extending
relation,
which
should
not
be
fixed
with
new
values
like
depend
on
then
the
the
second
one
was
a
suggestion
of
of
braun
about
how
to
add
colors
to
categories
and
keywords.
H
I
yeah
I
added
that
to
the
spec,
then
the
third
one
having
estimated
work
as
so.
There
was
a
the
point
raised
that
estimated
work
isn't
sufficiently
specified
because
I
said
it's
just
some
value,
it's
in
addition
to
estimated
duration,
because
some
systems
don't
use
the
duration.
They
use
some
abstract
value
and
I
tried
to
come
up
with
a
more
a
better
definition
for
it,
and
I
now
chose
fibonacci
scale
that
that's
like
a
recommendation
to
to
use
fibonacci
scale.
H
That's
a
common
common
scale,
people
use
in
agile
to
estimate
their
work
yeah.
That's
that's
what
I
came
up
with,
I'm
not
perfectly
happy
with
that,
but
yeah.
For
now
I
don't
know
first
iteration
it
should
be
good,
I
hope
yeah.
So
then,
another
thing
mentioned
at
last
itf
was
that
it's
a
bit
un.
H
It
was
a
bit
unclear
why
we
have
impact
in
addition
to
priority,
and
now
the
text
mentions,
that
impact
is
one
of
the
things
that
can
be
used
to
determine
the
priority
later
on,
but
it's
not
necessarily
the
same
thing,
basically
just
to
make
that
a
bit
more
clear,
then
yeah,
I
threw
I
had
this.
I
added
this
source
property
during
the
last
revision.
H
I
threw
that
out
because
we
already
have
prod
id,
which
we
can
use
for
exactly
the
same
thing,
which
is
something
that
robert
mentioned
last
itf,
which
is
a
good
thing
yeah,
and
there
are
two
other
bigger
things
that
I
already
bootstrapped
during
last
itf,
which
I'm
gonna
explain
the
next
in
the
next
two
slides.
H
Next
slide,
please
so
the
first
more
or
less
big
thing
is
progress.
Tracking.
There
was
a
comment
that
it's
it
was
a
bit
unclear
that
the
pro
that
it
has,
I
extended
the
values
of
progress
and
I
created
a
suggested
mapping
of
progress.
H
And
it
was
a
bit
unclear
about
that
that
there
were
several
values
that
were
not
really
easily
distinguished
from
each
other.
When
is
a
work
item
resolved
when
is
it
completed?
When
is
it
confirmed?
When
is
it
in
process
and
so
on,
and
there
was
also
the
suggestion
that
some
systems
even
allow
defining
custom
workflows
on
a
project
level.
So
in
the
end
it
doesn't
really
depend
on
the
system
on
its
own.
It
also
depends
on
the
project
how
people
design
their
own
workflows.
H
So
the
thing
I
came
up
with
for
extending
progress
or
like
like
extending
the
the
spec
to
have
yeah,
better
tracking
of
a
workflow
that
that
should
also
be
that
should
reflect
what's
there
in
in
issue
trackers
or
kanban
boards
is
workflow
and
in
two
extra
properties,
one
for
the
task
list
and
one
for
tasks
which
is
workflow
statuses
and
workflow
status.
H
So
in
the
task
list
you
can
define
all
the
allowed
values
of
your
workflow.
Basically
so,
like
you
can
already
do
in
jira,
and
there
are
the
workflow
status
is
then
defined,
which
must
be
a
value
of
of
those
that
you
defined
in
the
task
list
and
it
yeah.
It
says
which
of
the
status
which
of
the
work
where.
H
I
H
Is
there
yeah,
maybe
yeah
we
can
go
on
all
right
and
there's
grouping.
Is
the
next
big
thing,
so
here
again
as
a
reminder,
the
idea
is
that
we
have
different
use
cases
and
task
systems
are
more
heterogeneous
than
typical
grouper
systems.
So
the
idea
was
that
also
to
to
make
it
interesting
for
for
task
systems
that
don't
have
calendars
that
don't
have
a
lot
of
features
to
reduce
the
implementation
overhead
for
those
okay.
Next
slide,
please
so
I
came
up
now.
I
already
triggered
from
first
discussion
during
last
itf.
H
I
came
up
now
with
those
groups,
so
it's
basically
common
recurrences,
assignees
alerts,
localizations,
custom
time
zones,
so
they're,
grouped
by
the
feature
set.
Basically
the
methodology
I
used
was
I
I
looked
at
three
good
reasons
for
grouping
certain
properties,
so,
first
of
all
they
should
be
uncommon
in
a
certain
type
of
system.
H
Then
they
they,
then
they
should
not
belong
to
the
like.
They
should
not
belong
to
the
common
group.
If
they
are
uncommon
in
certain
types
of
system,
then
I
moved
it
to
out
of
the
common
group.
They
should
be
optional
within
js
calendar,
so
otherwise
it
doesn't
make
sense
to
exclude
them
from
a
common
group
and
they
should
require
some
additional
business
logic
as
well.
So
simple,
key
value
pairs
is
not
something
that
necessarily
needs
to
be
in
a
different
group
than
the
common
group.
H
It's
yeah
it's
easily
implementable
by
vendors,
so
yeah
as
it
is
right
now,
each
group
is
a
separate
capability
in
the
spec
last
time
we
discussed
about
using
sub-capabilities,
I
decided
against
using
sub-capabilities
because
it
avoids
the
additional
complexity.
We
talked
about,
having
a
not
supported
or
set
error,
for
example
yeah,
and
it
was
just
for
me-
was
just
more
natural
and
simpler
this
way.
H
Of
course,
you
can
leave
some
comments
on
that
yeah.
What
I'm
a
bit
unsure
about
is
if
it
makes
some
developers
unhappy
that
want
to
support
all
the
different
use
cases
now,
because
then
they
need
to
supply
six
different
capabilities
now,
instead
of
a
single
one
yeah,
so
that's
basically
kind
of
a
trade-off.
I
don't
know
or
something
that
I
don't
really
like
about
having
six
different
capabilities.
H
Yeah,
it's
not
just
a
question
in
the
room:
do
you
still
like
it
how
it
turned
out?
Do
you
have
some
comments
on
it?
Yeah?
So
I'm
not
sure.
Maybe
we
can
we
can
go
to
the
next
slide.
This
should
be
the
last
one
for
grouping.
So
basically,
here
it's
just
a
list
of
systems
and
what
kind
of
groups
they
would
need
to
implement,
just
as
a
as
a
validation
that
it
kind
of
makes
sense
that
the
grouping
that
that's
now
there
all
right,
robert.
J
Yeah
this
is
robert
stepanek.
I
have
a
couple
of
other
points
I
would
like
to
bring
up
for,
but
for
grouping
specifically.
So
what's
the
idea
of
how
should
systems,
what
should
systems
do
if
they
get
a
js
task?
That
includes
properties
that
are
in
a
group
this
they
do
not
support.
Are
they
I'm
supposed
to
reject
that
then,
or
are
they
supposed
to?
Let
just
store
it.
What's
what's
the
idea
here.
J
Like
if
you,
if
you
have,
if
you
have
a
recurring
task,
but
that
we
see
in
the
list,
but
simbra
right,
what
should
simbra
do
when
they
do
not
support
recurrences?
Should
they.
H
Yeah
they
can
just
so
it's
just
the
normal
capability
definition
as
it
is.
So
if
you
don't
understand
the
capability
as
a
server,
I
don't
exactly
remember
what
the
spanx.
J
Is
I
think
they
would
reject
it,
then
right
so?
Okay,
so
you
would
so
one
would
need
to
send
for
the
js
for
the
js,
the
js
task
in
chamber
for
tags,
along
with
the
capabilities
that
the
data
contains,
so
that
the
server
can
identify.
H
H
E
Yeah
robert,
like
I
think
it's
you
know,
this
is
a
client
talking
to
a
server,
so
it's
kind
of.
If,
if
you
implementing
it
the
capabilities,
let
the
client
negotiate
with
the
server
what
it
supports
and
turn
on
off
features.
If
you
were
importing
the
data
from
elsewhere,
so
it
had.
You
know
you
had
exported
something
with
recurrences
from
google
workspace.
You
know
importing
into
microsoft.
Planner
that
didn't
support
it
then
it'd
be
up
to
the
import
tool
to
say
sorry.
This
has
stuff
in
it
that
we
don't
support.
E
E
H
H
H
Maybe
I
should
have
looked
a
bit
deeper.
That's
a
good
point
that
might
that
might
have
gone
lost.
In
my
what
I
looked
at
yeah.
B
F
Yeah,
so
I
had
a
couple
of
things:
one
is
this
particular
point
about
between
the
client
and
the
server.
If
I
remember
in
the
internet
world,
we
have
this
whole
concept
of
be
send
or
be
very
conservative
in
what
you
send
and
be
very
broad-minded
in
what
you
accept.
So
I
think
that
philosophy
about
if
zimbra
doesn't,
if
I'm
getting
something
from
zimbra
and
there
are
alerts
there,
I
don't
support
it.
Okay,
fine
forget
it.
F
If
I'm
sending
some,
I'm
I'm
not
sure
whether
the
other
servers
actually
use
that
that
philosophy
are
built
on
that
philosophy,
that
if
I
send
them
two
three
different
things,
will
they
just
neglect
what
they
don't
know
and
or
how
do
so?
That's
so,
but
I
think
if
it's
going
to
be
for
a
particular
implementation,
it
needs
to
be
pretty
broad-minded
in
what
it
accepts
and
if
it
doesn't
implement
it,
fine,
that's
sorry,
it
does
not
support
it.
F
H
A
A
H
H
D
Quite
a
lot
of
people,
robert
letting
me
in
yeah
in
regards
to
reject
rejecting
properties.
You
don't
understand
versus
you
know,
just
being
able
to
store
any
extra
properties.
I
would
rather,
the
server
is
able
to
store
any
extra
properties
because
it
doesn't
doesn't
advertise
the
capability.
Obviously
it
cannot
do
any
automation
based
on
them
or
any.
You
know,
derived
property
or
anything
like
that,
but
I
think.
H
H
J
I'm
robert
stepanek
again,
I
have
two
remarks
not
related
to
grouping,
so
I
I
think
we're
done
with
the
grouping
discussion,
all
right,
okay,
so
the
first
one
is
just
an
uneducated
remark
regarding
the
estimated
work
property
yeah.
So
I
understood
that
there
are
multiple
scales
of
how
to
estimate
work,
but
at
the
moment
there's
just
a
single
numeric
value
to
start
it
would
it
make
sense
to
define
to
add
an
additional
value
to
define
the
scale
it
is
done
in
when
there
are
different,
estimating
schemes
that
that
can
be
used.
H
Okay
yeah,
the
thing
is,
I
I
didn't
really
find
like.
Typically,
it's
just
a
value.
You
know
it
just
says:
how
much
work
is
this
and
this
now
it
doesn't
say
that
there's
an
actual
unit
to
it,
but
I
try
to
come
up
with
a
like
the
common
thing
that
people
do
in
in
the
agile
world
and
the
common
thing
that
I
found
was
the
fibonacci
scale
yeah.
But
I
I.
H
G
J
That's
how
I
understood
the
definition
of
the
property,
although
I
then
would.
Rather
I
wouldn't
understand
why
even
the
fibonacci
scale
should
be
mentioned
if
it's
really
yeah
an
internal
decision.
Okay,.
J
J
Yeah,
okay:
the
other
remark
is
organizational
and
goes
more
to
the
chairs
chairs,
which
is
now
that
shame
up
tasks
defines
updates
to
js
calendar
tasks,
but
she
is
kind
of
the
test
it,
but
she
is
calendar
is
currently
getting
reworked.
I
don't
know
how
to
solve
these
dependencies.
B
We'd
probably
send
them
through
together,
that's
fairly
normal
to
cluster
documents
together
when
they're
related
to
each
other.
So
hopefully
these
two
can
go
together.
Otherwise,
we'd
need
to
wait
for
js
calendar
to
go
first.
H
Okay,
yeah,
the
last
slide
is
just
that
we
are
still
working
on
feedback
gathering
feedback,
so
we
have
through
the
ngi
project.
We
have
some
initial
feedback
from
the
weekend
developer
and
the
developer
from
to
do
also
gave
some
feedback
within
the
chi
connect
rounds
yeah,
but
there's
still
more
to
come,
there's
still
more
work
to
do
yeah.
There
are
still
some
next
steps
before
we
can
go
to
a
last
call.
Definitely.
A
G
Yeah,
it's
not
a
question
for
the
work
in
particular.
It's
actually
more
directed
to
the
chairs
in
the
working
group
as
a
whole.
Calex
has
never
been
something
I
know
a
lot
about
in
depth.
So
as
I'm
reading
the
charter,
the
word
tasks
doesn't
appear
anywhere
in
it
and
I'm
starting
to
think.
Oh,
no,
you've
strayed
from
the
charter
and
I
didn't
catch
it
in
time,
but
then
someone
said
that
tasks
sort
of
falls
under
calendaring
generally.
So,
like
that's
fine
and
then
in
that
case
the
only
thing
missing
is.
G
Yes,
calendaring
in
general,
and
you
already
are
chartered
to
do
calendaring
related
work.
So
that's
what
I
was
getting
at.
I
didn't
know
how
tasks
were
related
to
the
charter.
That's
all
yeah.
A
Right
and
yeah:
let's,
let's
hit
those
before
we
go
to
the
to
the
new
topics,
so
let's
bring
up
the
the
agenda
for.
A
Neil
well,
calendars
is
robert.
I
think
right
right.
E
M
E
So
basically,
calendars
is
waiting
on
resolving
the
js
calendar
discussion.
That's
happening
in
calyx
at
the
moment,
particularly
around
identifying.
E
Who
participants
are
corresponding
participants
with
who
you
are
so
hopefully
we'll
get
that
resolved
soon,
and
then
you
know
it
was
been
basically
done
for
a
while
now
so
hopefully
we'll
be
able
to
face
it
off
and
sharing
too
we'll
probably
want
to
publish
sharing
calendars
tasks
kind
of
together,
they're
all
related.
E
L
A
L
N
Okay,
so
sieve,
I
don't
have
any
slides,
because
there's
not
much
to
talk
about
the
only
change
since
since
vienna
was
tracking
the
changes
in
the
blob
spec
other
than
that.
This
has
been
kind
of
idling
for
the
last
two
cycles,
waiting
for
implementation
experience
with
the
test
method,
which
has
yet
to
come.
So
I
think
what
I'd
like
to
do
is
pull
that
out
of
this
spec
and
leave
it
as
an
extension.
N
It's
already
optional
in
this
particular
spec,
and
I
think,
with
the
process
I
met
draft,
which
will
be
talked
about
in
the
extra
session.
There
might
be
a
couple
additions
needed
for
the
test
method
anyways.
So,
rather
than
hold
this
up,
I
think
that's
probably
the
best
way
forward.
We've
got
this
running
in
production
at
fast
mail.
It's
totally
replaced
our
managed
implementation,
and
so
far
we
haven't
seen
any
problems
with
it.
N
D
N
N
D
No,
I
don't
know
no,
I
don't
feel
strongly
about
it,
but
I
think
maybe
what
we
should
do
is
you
want
to
investigate
how
to
extend
imp
action
anyway
for
this
right
right,
so
maybe
just
look
at
it
and
see
how
it
will
extend
and
whether
you
already
have
genetic
ability
to
have.
You
know
stuff
extra
options
that
that
the
engine
can
act
on
which
is
kind
of
part
of
that.
N
B
M
Yeah
this
is
rick
sickness,
the
as
as
for
incompleteness
with
management.
I
can
tell
you
it's
definitely.
There
is
no
capability
that
matches
the
civ
script.
Jmap
testing
behavior
in
manage
ziv.
It's
a
it's
a
novel
thing
designed
to
replace
an
internal
system
at
faz
mail,
so
manage
it,
has
check
script
right.
It
doesn't
compile
and
we've
we've
built
that
into
the
existing
civ
script
behavior,
and
I
think
it's
a
great
idea
to
split
them.
M
The
basic
problem
being
one
of
the
reasons
we
don't
have
an
implementation
to
test
with
our
a
user-facing
implementation
to
test
at
fast
mail
is
we've
never
figured
out
the
right
way
to
present
it
to
users
and
if
we
can't
find
a
way
to
say
here's
how
to
simulate
this
and
present
it
to
users.
It's
unclear
that
it's
technically
sound
right.
M
We
might
realize
that
the
the
testing
of
the
input
and
output
can't
be
made
useful
as
an
actual
simulation
tool,
but
meanwhile
is
a
replacement
for
managed
script
manager
sieve
it's
it's
done
the
job.
We're
done.
We've
shut
off
manchester,
so
publishing
everything
done
now
seems
like
it.
It
can
replace
the
old
facility,
and
this
new
thing
is
still
it's
just
an
idea.
N
If
there's
no
other
comments,
I
will
proceed
to
remove
this
out
of
the
current
draft
and
then
ask
for
workinggroup.com.
A
A
On
to
newark
I'll
start
with
migration
and
portability,
I
think
that
was
the
first
one
on
the
agenda.
H
H
H
So
what
we're
looking
for
is
an
api
to
be
used
for
the
the
task
of
migrating
away
from
the
old
system
to
a
new
system,
and
what
would
be
great
would
be
to
have
to
point
developers
that
get
this
task
to
an
api
specification
that
they
can
just
they
can
say.
Okay,
we.
H
Legacy
system:
we
can
just
put
this
api
in
front
of
it
and
be
done
with
it.
Basically,
so
it's
it
may
it
makes
the
job
a
bit
easier
for
developers
for
this
specific
use
case,
and
we
looked
at
jmap
for
this
use
case,
you
can
use
jma
for
a
lot
of
different
data
types,
which
is
great,
so
it's
it's
powerful
enough.
It
has
a
lot
of
features
more
than
enough
actually
than
we
need.
H
H
So
let
me
go
to
the
next
slide,
so
what
we
tried
to
use
jmap
for
this
use
case
is
to
bend
it
a
bit
to
make
it
more
rapid
to
make
it
easier
for
for
third-party
developers
to
implement
the
jmap
api,
and
so
these
are
just
some
ideas
that
we
had
so
how
we
change
the
the
the
core
api,
so
so
developers
are
actually
interested
in
implementing
this
without
too
much
overhead.
H
H
H
So
basically,
what
we
right
now
have
is
a
document
stating
what's
important
and
what's
not
important
for
our
for,
for
this
particular
use
case,
to
make
it
easy
to
implement
so
also
what
we
did
is
we
skipped
the
session
object,
which
is
a
quite
a
big
one.
In
my
opinion,
we
can
do
that
when
the
username
equals
the
the
account
that
you
use
for
login.
H
Basically,
so
if
you
only
have
a
single
user
in
a
single
account,
you
don't
need
the
whole
complexity
about
mapping
an
account
to
a
lot
of
different
user
ids
yeah-
and
this
just
reduces
quite
some
overhead
yeah.
Not
such
a.
I
don't
know
easy
choice
to
do
that.
Also
we
introduced
a
simplified
request
for
this.
H
Can
you
go
to
the
next
slide
for
this
or
yeah
so
yeah,
so
to
make
it
really
easy
for
people
some
people
might
don't
want,
maybe
don't
even
want
to
pass
json
in
their
api.
They
just
want
to
give
us
some
json
that
we
can
parse.
H
H
H
Other
people
will
be
more
interested
in
implementing
jmap.
I
we
think
it
can
be
beneficial
for
the
whole
ecosystem
because
it
might
spark
interests
that
that's
not
already
there
yeah.
There
are
some
related
problems
that
we
ran
into
like
we.
We
could
one
could
also
expose
certain
archives
laying
around
on
the
system
and
a
file
system.
For
example,
some
people
have,
I
don't
know,
folders
with
icalendar
files
or
vcards
that
you
could.
H
You
could
easily
expose
with
this
with
this
with
the
wrapper
yeah,
so
those
are
basically
some
thoughts
that
we
have
some
some
work
that
we
did
and
I
just
wanted
to
put
this
out
there
and
the
idea
was
that
we
right
now
we
have
some
internal
document
that
we
point
people
to,
but
it
would
be
nice
to
have
it
to
some
to
put
it
in
some
public
place,
it's
probably
not
worth
an
rfc,
I
would
say,
but
yeah
I
want
to
leave
that
open
for
a
discussion.
B
I'll
just
pop
myself
in
the
queue
here.
One
thing
I
was
thinking
of
way
back
even
was
doing
more
of
a
rest
type
api
so
rather
than
the
the
query
parameters
to
actually
have
a
path,
object,
type
and
then
id
underneath
that,
and
if
you
do
a
query
on
on
just
the
object
type,
you
get
a
list
of
all
the
ids
and
then
you
can
request
each
of
them
as
a
single
item
so
making
it
feel
more
like
a
a
standard.
B
H
H
D
Yeah
alexi,
it
looks
like
you're
modifying
or
extending
things
you
know
to
make
it
simple
to
use
for
certain
cases,
so
this
should
be
a
document
whether
we
choose
to
publish
it
now,
it's
kind
of
a
separate
issue,
but
I
think
there
should
be
a
draft
yeah.
H
H
All
right
yeah
would
they
be
interested
in
in.
F
H
H
H
I
just
wanted
to
present
here,
just
to
get
some
to
give
you
some
ideas,
what
one
can
do
with
jmap,
so
grouper
preferences
are
not
very
well
standardized.
Everybody
does
his
own
thing
yeah.
There
are
different
ways
like
they're
different
dimensions,
even
to
it,
so
they
can
be
in
a
certain
context-
the
preferences,
for
example,
in
in
out
of
office
in
a
male
context,
or
for
for
calendars
there.
There
are
specific
preferences
that
one
can
have,
but
they
can
also
be
in
a
global
context
as
well
and
there's.
H
For
example,
you
have
an
extra
object
like
calendar
preferences,
or
they
can
reuse
other
mechanisms
that
are
already
there.
For
example,
you
can
have
some
preferences
as
sieve
filters.
Then
there
are
also
the
third
dimension.
Is
that
there's
a
diff?
It
can
be
a
different
scope,
so,
for
example,
preferences
can
be
in
the
user
scope,
but
there
are
also
some
systems
where
they
are.
An
admin.
Scope
is
what
we
call
it.
For
example,
some
civ
rules
might
be
there
for
a
certain
user,
but
the
user
actually
doesn't
see
them.
H
It's
it's
somewhere
on
the
system.
Some
admin
created
those
rules,
or
this
is
preferences
and
it's
there,
but
hidden
from
the
user
visible
to
the
admin.
That's
just
about
the
state
right
now
for
grouper
preferences.
Can
you
go
to
the
next
site
yeah?
So
recently
we
did
a
project
or
we
currently
do
it
do
it
where
a
vendor
wants
to
expose
certain
settings
for
a
big
migration,
and
here
they
wanna
wanna,
expose
allow
lists
and
block
lists
for
this.
We
defined
a
new
jmf
preferences,
object,
yeah,
just
a
normal.
H
The
link
is
down
there
with
which
contains
some
documentation
on
it,
and
we
did
this
because
having
a
jammer
preferences
object
is
or
we
we.
We
did
this
for
this
isp
project,
because
again
we
can
use
jmap.
Jmap
is
something
we
already
support,
and
it's
something
that
that
we
can
point
others
to
to
easily
implement
and
yeah,
maybe
there's
also.
H
So
the
way
we
currently
did
this
just
to
give
you
some
some
example
what
we
did
or
some
example
how
you
can
use
jmap
is:
oh
no.
A
H
A
kind
of
preferences
object,
for
example.
We
just
have
a
generic
preferences
object
in
this
case,
because
it's
about
allows
and
block
lists
is
a
generic
kind
of
thing
and
yeah,
because
it's
it
was
very
easy
for
our
use
case
right
now.
We
have
a
separate
capability
for
this.
Generic
preferences
object
that
you
know
that
extends
the
the
general
object
with
settings.
H
Okay,
can
you
go
to
the
next
slide
yeah?
Why
do
we
do
this
yeah?
We
want
to
want
to
stress
the
the
usefulness
of
jmap
for
for
the
data
portability
use
case
for
the
the
migration
use
case.
You
can
use
it
in
a
lot
of
different
contexts.
Contexts
it's
easy
to
extend
yeah.
We
are.
We
did
this
on
our
own,
so
we're
interested
in
some
feedback.
Some
opinions
on
it
yeah,
and
I
think
it's
also
good
to
to
have
to
just
to
go
forward,
standardize
a
bit.
H
What
preferences
should
look
like
to
understand
them
a
bit
better
because
it's
it's
currently
not
very
well
standardized
and
the
net.
The
next
step
is
for
us
is
also
like
similar
to
the
migration
use
case
is
to
have
some
kind
of
document
that
describes
what
preferences
are
yeah,
how
you
could
standardize
them,
but
we're
not
very
confident
of
having
that
as
an
rfc.
Yet
but
yeah
that's
open
for
discussion
yeah,
that's!
Basically
it
just
to
share
some
experiences
to
yeah
get
some
feedback
all
right.
H
F
F
H
Okay,
so
you're
saying
it's
out
of
scope
for
the
protocol,
but
it's
still
nice
to
have
like
get
a
deeper
understanding
and
to
I
don't
know,
describe
what's
out
there,
how
it
can
be
done.
H
Makes
sense,
I
also
said
it's
probably
more
of
a
best
practice
document
than
part
of
the
protocol.
Yeah.
E
Yeah,
I
I
mean
I
I
think
just
talking
about
the
previous
point.
Briefly,
the
you
know
jmat
is
the
protocol,
but
this
is
still
data
and
it's
still
something
you
want
to
either
synchronize
or
be
able
to.
You
know,
send
from
the
client.
So
whatever
else
so
that's
kind
of
the
point
of
this,
but,
as
you
mentioned
earlier,
I
don't
think
there's
any
kind
of
common
enough
subset
that
we
could
choose
to
be
worth
kind
of
publishing
a
standard
on
the
data
type.
E
At
least
I
I
doubt
it
but
a
best
practice
document
of
if
you're,
creating
a
preferences
object.
This
is
the
kind
of
things
you
should
consider.
That
sounds
pretty
reasonable
to
me,
like
we
have
a
bunch
of
them
at
fast
mail
kind
of
like
the
calendar
preferences
one,
but
the
actual
data
types
themselves.
The
specific
properties
like
that's
just
going
to
be
quite
service
specific,
I
suspect
mostly.
G
O
Great
thanks
yeah,
so
I
I
I
agree
which
was
said
previously,
so
I
think
certainly
it's
the
client
service
thing,
because
this
is
something
that
is
that
some
uis
and
clients
do
manipulate
on
the
server
side.
So
it's,
I
think,
certainly
something
that
fits
into
the
you
know:
client
server
interaction.
O
Reference
within
jmap
would
maybe
help
vendors
to
adopt
a
more
standardized
solution
and
thus,
in
the
future,
promotes
portability
and
interoperability
with
respect
to
those
settings
that
might
not
apply
to
each
and
every
setting,
but,
for
instance,
for
this
particular
one
we
made
as
an
example
here.
This
could
well
be
if
this
needs
to
be
an
rc.
I
don't
know
anyway,
so
it
can
also
be
a
document.
I'm
I
agree
with
that,
but
I
I
don't.
E
Just
regarding
block
list
in
you
know
as
a
specific
example,
I
would
consider
that
a
separate
data
type
like
each
you
know
item
is
a
block
like
an
email
address
or
a
domain,
and
that's
certainly
how
we
model
it,
because
that
makes
it
any
you
know
more
efficient
to
add
stuff
to
or
to
remove
stuff
and
to
you
know,
resync
it
to
another
client.
If
you've
added
a
you
know
a
blocked
address
on
one
client
and
you
want
to
resync
another
one
rather
than
being
just
like
a
whole
blob
in
your
preferences.
E
O
Maybe
what
can
I
answer?
It's!
Okay!
Oh,
are
you
finished
sorry.
I
didn't
want
to
interrupt
you.
Sorry.
I
think
what
we
can
agree
upon
are
concluded
at
this
point.
Is,
it
might
might
make
sense?
Maybe
it
might
make
sense
to
work
out
some
more
of
these
settings
and
discuss
about
them
in
in
more
detail
at
a
later
session,
maybe
and
see
if
there
is
some
common
ground
for
that
or
not
actually.
O
Too
much
into
the
detail
here
for
that
particular
discussion
yeah,
because
that
was
not
the
intent,
but
I
see
there
might
be
a
good
that
might
be
a
good
opportunity
at
a
later
session
to
think
about
more
deeply.
And
maybe
we
come
with
more
examples
which
systems
use
using
which
fashion
also
gives
the
time
right
now.
B
All
right,
thank
you.
I
think
that
is
we're
now
at
the
point
of
milestones
or
any
other
business
for
the
german
working
group.
What's
that,
do
you
think?
Oh
yeah?
That's
extra,
so
I
think
that
might
be
it
for
jmap
any
other
business
for
jmap
before
we
move
on
to
milestones.
B
Putting
it
in
the
notes
and
having
to
move
it
otherwise,
so
starting
with
blobs
we're
obviously
moving
that
along
to
august.
Given
that
I
need
to
update
the
draft
and
send
it
off
to
my
co-chair
for
working
group
last
call,
and
then
we
will
hopefully
submit
this.
Finally,
in
august,
submit
civ
document,
I
think
we
agreed
likewise,
it
will
basically
be
ready
to
go
straight
after
this.
B
H
Is
it
on
yeah?
I
don't,
I
don't
think
the
next
one
is
already
it
will
be
finished
by
then
maybe
the
afternoon
it's
and
regarding
tasks.
It's
not
not
even
on
the
milestone
list.
Yet.
E
B
I'll
just
move
it
to
december.
For
now,
then
yeah
quotas,
we
think,
is
basically
ready
to
go
so
that
will
be
august
as
well
s.
My
sender,
extensions.
B
October,
gem
up
address
books,
we're
not
we've
got
that
ready
to
be
adopted
in
november,
so.
E
J
B
Cool
all
right,
so,
let's
add
some
more
milestones.
We
say:
submit
js
general
tasks,
document
asg
and
we
said
that
is
probably
going
to
be
early
next
year.
A
If
addresses
are
ready
before,
if
addresses
are
ready
before
we
don't
necessarily
have
to
wait
for
the
next
ietf
to
do
the
call
for
adoption,
we
can
do
that
on
the
list.
So
let
us
know.
B
Yeah,
it's
nice
when
it
happens
all
right
so
tasks.
I've
got
one
ready
for
that
to
go
in
there.
What
else
did
we
have
that?
We
had
said
so,
sharing
that
we
don't
have
a
milestone
for
sharing
I'll,
create
a
separate
milestone
for
that,
and
I
don't
think
we
had
a
milestone.
Well,
yeah
we've
got
sev,
we've
got
tasks,
we've
got
blob,
we've
got
quotas.
That
might
be
it
then,
and
this
other
work
is
going
to
be.
B
B
B
B
B
D
B
B
L
N
One
it's
in
production
at
fast
mail
seems
to
do
do
the
job,
I'm
not
sure
how
many
people
have
actually
read
it,
but
maybe
working
last
call
would
get
some
reviews.
B
N
B
E
Yeah
just
on
the
process,
I'm
at
draft,
I
read
that
it
refers
to
a
calendar
id,
but
there's
no
information
at
all
about
what
the
scope
of
that
is
or
where,
when
we're
getting
calendar
id
or
what
a
calendar
id
is.
E
I
Yeah,
it's
it's
a
good
point.
It's
kind
of
outside
the
scope,
though,
because
it's.
B
N
N
That's
fine,
all
right
I'll
I'll,
add
some
text
to
that
and
then
perhaps
we
go
to
last
call.
Thank
you.
B
So
it's
updated
draft
and
then
work
and
grip
last
call
cool
and
for
snooze
did
anyone
have
anything
to
add
for
snooze
otherwise
we'll
send
that
to
working
group
last
call
as
well.
B
Excellent
next
on
our
agenda:
where
is
our
agenda.
D
L
B
Civ
registry
was
the
other
thing
that
we
had
on
this
list.
Alexi.
D
D
N
This
is
kenny,
I
I
think
we've
covered
everything
and
just
as
a
point
of
reference,
I
added
in
this
in
this
news
draft.
I
added
an
entry
for
the
registry,
so
presumably
they
will
either
go
together
or
the
registry
goes
first
and
then
snooze
follows.
M
See,
if
I
remember
what's
on
my
slides,
okay
yeah,
so
this
is
snoozing
the
imap.
I
think
the
idea
of
this
feature
is
probably
well
understood
at
this
point,
especially
since
ken
was
talking
about
sieve
via
the
snooze
via
sieve.
This
is,
if
you
got
a
message
in
a
mailbox,
and
you
want
to
hide
it
away
until
some
future
time.
It's
present
in
a
bunch
of
clients
and
just
a
few
servers
next
slide.
M
So
what
you
see
in
servers
and
clients
implement
this,
is
you
take
a
message,
and
you
say
I
don't
want
to
think
about
this
message
for
some
period
of
time.
The
message
vanishes
from
your
view,
unless
you
go
looking
for
it
and
when
that
time
expires,
the
message
comes
back
and
I've
seen
this
implemented
in
half
a
dozen
clients
in
two
or
three
major
servers.
M
M
M
The
idea
is
this:
you
take
a
message
and
you
snooze
it
which
moves
the
message
using
move
semantics
into
a
snooze
mailbox.
This
is
a
new
special
use
mailbox
when
the
message
is
there.
It's
picked
up
three
new
data
items
on
the
message
and
those
are
the
awaken
to
awaken
flags
and
awaken
at
this
tells
you,
when
the
message
stops.
Snoozing,
where
will
it
be
put?
How
will
its
flags
change
and
when
does
that
happen?
M
If
you
snooze
it
from
any
mailbox
other
than
snoozed,
it
will
awaken
to
wherever
you
snooze
it
from
and
if
you
snooze
it
from
snooze,
you
just
leave
it
awakening
to
the
same
place.
M
M
Right
I've
covered
this.
This
is
what
we
do
with
it.
If
you
can't
unsnooze
it
to
the
predefined
mailbox,
it
goes
to
inbox,
but
hopefully
that
never
happens
next.
M
We
also
yeah.
M
Well,
okay,
so
one
thing
I'll
throw
in
here
we
use
flags
I'll
talk
about
why
when
we
snooze
and
unsnooze
these
messages,
you
just
get
a
list
of
flag
changes
to
make
when
it
wakes
up.
This
is
this
is
supposed
to
talk
about
unsnooze.
I
believe
I
think
I've
got
some
typo
on
my
slide
here
when
you
unsnooze
a
message
right,
you're
saying:
cancel
the
snooze,
I'm
ready
to
deal
with
it
early.
What
do
we
want
to
do
with
the
awaken
flags?
M
M
The
snoozed
mailbox
is
it's
read-only,
you
can't
put
mail
in
it
except
via
snooze.
You
can't
remove
mail
from
it
except
via
unsnooze,
and
we
create
it
as
needed.
M
This
is
not
the
same
design
we
see
in
every
implementation.
There
are
implementations
that
leave
the
message
in
the
current
mailbox
and
we'll
flag
the
message
with
the
flag
or
we'll
give
it
some
other
metadata
to
indicate
that
it's
been
snoozed
or
implementations
that
put
the
message
into
the
snooze
mailbox
to
snooze
it
and
to
unsnooze
it
remove
it
from
the
mailbox.
But
if
you're
using
move
to
implement
snoozing
you're
losing
the
ability
to
enforce
that
the
metadata
has
been
set
correctly,
which
is
why
we're
proposing
a
separate
verb.
B
E
Yeah,
so
it
didn't
look
like
you
currently
have
any
way
of
specifying
the
folder
to
return
to
other
than
like
implicitly,
it's
like
wherever
I
snoozed
it
from.
We
actually
do
use
both
because
in
labels
mode
it
always
snoozes
from
the
inbox
and
returns
back
to
the
inbox,
regardless
of
where
you
choose
from
that'd
be
great.
Now
you
want
to
add
that
here
too,.
M
E
P
Phillip
yeah
phil
handbaker
yeah,
have
you
considered
the
interaction
of
this
with
tasks
and
when
I'm,
when
I'm
using
this
sort
of
functionality?
It's
really
because
I
want
to
create
a
task
for
myself
later
on,
and
my
client
doesn't
support
that.
So
it
might
be
worth
thinking
about
the
two
together
yeah.
M
I
mean,
I
think,
the
answer
I
can
give
you
on
that
thinking
about
this
and
with
respect
to
tasks
is
as
a
as
a
individual
human.
I
have
daydreamed
about
how
I
would
use
that,
but
we
haven't
done
any
serious
protocol
discussion
of
it
and
we
can
bring
that
up
on
the
list.
How
we
might
do
something.
O
Yeah
thanks
rick,
that's
interesting,
but
I
have
couple
of
questions
I'm
not
sure
if
some
of
them
might
be
answered
in
following
slides,
so
interrupt
me.
Maybe
if
I'm
asking
something
stupid
which
you
will
explain
anyway,
so
a
very
minor
question
is
so
how
does
it
interact
with
a
recent
flag?
So
because
you
know
clients
use
that
already,
as
a
kind
of
you
know,
to
denote
some
message:
that's
fresh
on
the
server.
O
Will
this
reactivate
reason
until
unsnoozed
or
not
then,
what's
not
quite
clear
for
me
is
the
client
is
who
is
doing
this
news
interaction.
So
I
understand
that
somehow
the
server
implements
that
snooze
mechanism,
the
moving
out
of
the
smooth
states
when
the
date
has
been
passed
and
so
on,
but
it's
actually
the
clients
that
need
to
be
taking
action.
I
guess
so.
O
I
wonder
a
little
bit
how
that
kind
of
it's,
how
it
ensured
that
once
the
server
moves,
the
message
back
in
the
unsmooth
states,
you
know
what
is
the
client's
respect
expected
to
do
and
third
question:
if
you
can
still
take
one,
is
you
say
it's
not
allowed
to
append
messages
to
that
news
mailbox.
So
I
wonder
about
what
is
about
migration
here.
So
if
we
migrate
a
mailbox
which
has
this
feature,
we
might
need
to
migrate
messages
which
are
the
smooth
state
into
a
new
destination
system.
So
this
would
require
append
actually
properly.
M
Okay,
first,
let
me
apologize.
The
audio
quality
in
here
is
not
perfect.
I
may
have
missed
some
of
your
question
as
regards
to
what
is
the
client
expected
to
do.
This
does
come
up
a
bit
later,
but
the
short
answer
is
the
client
is
simply
expected
to
show
the
user
that
the
message
has
returned
to
its
previous
state.
So
this
means
number
one.
M
The
message
is
back
in
its
awakened
to
mailbox
and
number
two:
what
we
do
at
fast
mail
with
the
flags
is
we
use
a
flag
to
indicate
that
a
message
it
has
entered
that
mailbox
by
awakening
from
snooze
and
then
it
it
will
display
differently.
I
think
a
convention
on
that
would
be
useful,
but
not
necessary.
M
I
do
think
it's
important
to
talk
about
this
being
a
server
function
to
awaken
the
message,
because
you
would
like
your
message
to
awaken
no
matter
whether
no
matter
which
client
you
are
using
and
you
don't.
You
don't-
want
your
mail
client
to
have
to
awaken
it
if
you're
using
a,
not
snooze,
capable
client
to
read
your
mail
when
you
snooze
it
from
one
that
can.
As
for
migration,
I
don't
it's
not
a
question.
I've
thought
about.
I
don't
have
a
great
answer.
I
think
the
simple
one
is.
M
You
would
migrate
the
message
to
its
awakening
target
and
snooze
it.
Then
it
would
get
the
job
done,
even
though
it's
a
little
silly.
M
Okay,
barry.
L
Hi
this
is
barry
liba,
so
I
I
haven't,
read
the
draft
yet.
So
this
is
a
question.
L
Oh
okay,
the
question
is
about
the
use
of
the
special
use
mailbox,
the
the
user
may
not
move
mail
out
of
this
mailbox.
That's
as
far
as
I
can
remember
unique
at
this
point,
the
special
use
mailboxes
are
like
every
other
mailbox,
except
they're
used
for
certain
other
things.
L
How
are
you
planning
to
write
this
up?
Is
that
going
to
be
a
requirement,
because
I
think
some
servers
do
not
have
that
capability
in
them,
yet
that.
M
I
think
we
have
two
options.
One
is
to
one
is
to
eliminate
the
requirement
and
instead
to
say
that
if
the
message
is
moved
in
is
that
the
message
is
moved
in
there's
some
default
behavior,
which
I'm
not
sure
what
it
would
be
and
if
the
message
is
moved
out,
it
is
implicitly
awoken.
M
Another
option-
I
I
think
in
my
imap
might
be
too
poor
to
to
be
correct
here
is
that
we
could
require
that
apple
support
is
present
and
that
this
mailbox
must
have
access
control
that
restricts
you
from
adding
to
it.
But
I
yeah,
I
see
a
thumb
down.
Yeah.
D
This
I
actually
I'm
not
going
to
fight
you
on
this.
I
agree
with
you
magic
mailboxes,
ideally
not
a
good
idea
so,
and
so
the
other
side
of
another
thing
I
wanted
to
say
is
not
yet
fully
sold
on
the
new
command,
but
I
think
it
basically,
we
need
to
review
all
extensions
that
affect
uag
copy
and
uid
move
yeah
to
make
sure
that
this
is
handled
in
exactly
the
same
way.
Yeah
or
you
know,
you
know,
module
of
the
differences,
obviously
so
that
it
kind
of.
D
I
know
it's
more
like
if
we
can
manage
that
it's
a
to-do
item.
We
need
to
do
yeah
but
yeah.
I
suspect,
from
the
reaction
from
you
know,
people
in
the
room
and
remote
that
there
is
enough
interest
in
this.
K
Pete
resnick,
so,
as
you
were
describing
this,
I
thought
what's
the
use
of
the
snooze
mailbox
in
the
first
place,
I
understand
implementation
wise,
why
that
makes
it
easier,
because
now
you've
got
all
the
messages
that
you
have
to
deal
with
later
in
one
place,
and
then
you
can
do
the
trigger
off
that,
but
that
seems
arbitrary.
K
K
The
move
mailbox
seems
like
it
could
be
removed
from
this,
and
and
you
could
still
implement
it
that
way,
but
it
seems
like
you
could
just
do
this
as
a
much
more
generic
protocol
proposal
and
then
leave
to
the
implementation,
whether
they
use
a
snooze
mailbox
or
whether
they
have
a
list
of
messages.
You
know
that
are
waiting
to
be
snoozed
seems
perfectly
good.
M
K
And
then
it's
a
normal
mailbox,
you
know,
you
may
in
your
ui,
say
no
can't
move
anything
into
snooze.
That's
fine,
but
your
ui
is
dealing
with
the
idea
of
the
snooze
mailbox
and
for
all
I
care
that
could
be
a
flag.
D
Yeah
thanks
yeah.
I
will
actually
second
beat
on
this.
It's
probably
implementable
with
flags
you,
you
still
need
to
store
extra
metadata
because
you
want
to
substitute
flags
at
a
later
date,
but
you
can
do
it
in
place
by
just
defining
and
you
keep
you
know
one
or
two
more
extra
keywords
saying
this
is
snoozed,
so
basically
clients
when
they
scan
for
mailbox,
they
will
just
don't
show
it
or
something.
I
don't
know.
F
This
is
actually,
I
think,
my
what
I
was
pointing
out
for
has
actually
been
by
alex
and
p
was
about
that.
Instead
of
doing
the
concept
of
the
mailbox
per
se,
we
should
actually
use
the
flags
things
and
then
let
the
client
decide
whether
they
want
to
implement
it
as
a
mailbox
thing,
or
they
just
want
to
put
tags
or
flags
and
work
on
it.
That
way,
and
that
way
all
your
flags
that
information
for
the
snooze
flag
would
be
awakened
too,
and
all
of
that
may
come
up
there.
D
N
M
K
Yeah
this
is
pete
again
and
I'm
glad
to
review
it.
I
I
have
no
dog
in
this
fight.
I
I
you
know.
However,
you
guys
want
to
implement
this.
This
seems
like
a
cool
feature
and,
and
that's
fine,
just
architecturally.
It
seems
like
an
easier
thing
to
make
it
much
more
generic,
so
yeah.
I.
I
took
a
quick
glance
through
the
the
document,
because
this
came
up
and
I
thought
okay
well
yeah
same
ideas.
E
So
I
I
disagree
about
making
it
more
generic.
I
think
that
kind
of
the
point
of
this
is
it's
two
things:
it's
there's
a
common
paradigm,
that's
implemented
in
a
whole
bunch
of
places
and
they
pretty
much
all
work
the
same
way
and
so
trying
to
support
like
extra
cases
beyond
that
makes
it
less
likely.
This
will
be
implemented
because,
like
for
example,
you
know
if
it's
you
can
arbitrarily
do
some
defer
command
later,
there's
a
good
chance.
E
Most
people
won't
implement
that
because
that's
not
what
they're
back
in
sports
they're
back
in
audi
sports
snooze
and
it's
pretty
they're
all
pretty
similar.
So
I
think
that's
a
downside
to
trying
to
make
it
more
generic
and
yeah.
I
actually
think
that
makes
it
more
complicated
and
I've
lost
whatever
other
thought
I
had
on
this
right
now,
so
stop
that.
M
Yeah,
that's
for
the
record.
That's
my
tentative
feeling.
Also
I
I
defer
sounds
very
neat
and
I
think
I
want
to
think
about
it
and
write
about
it
more,
but
it
it
feels
to
inch
a
bit
towards
all
things
to
all
people,
which
is
the
very
dangerous
in
a
lot
of
designs.
Yeah
yeah.
E
Other
things
so
I'll
just
get
really
bit.
It
was
someone
mentioned,
oh
and
then
the
clients
could
you
know,
implement
this.
However,
they
want
it
with
the
server,
but
that
loses
the
point,
which
is
that
this
is
synchronized
to
the
clients
and
they
can
all
provide
a
consistent
view,
which
again
is
a
reason
to
make
it
less
generic,
so
that
you're
more
likely
to
see
something
consistent.
If
you
use
different
clients.
K
So
this
is
pete
again
and
neil
used
the
magic
words
that
send
my
hackles
up,
which
is
because
that's
the
way
the
backing
does
it,
and
this
has
been
the
disaster
of
imap
from
the
get-go-
is
that
you
know
when
mark
designed
it.
It
was
because
that's
the
way
his
file
system
worked
and
that's
what
screwed
over
a
lot
of
clients,
because
they
didn't
deal
with
the
world
that
way,
and
you
end
up
with
that
semantic.
B
Yeah,
no,
I
popped
myself
in
the
queue
here
to
actually
ask
a
more
general
question
which
says:
yes,
we've
got
this
in
civ.
We've
got
this
here
in
imap.
Presumably
we
also
want
to
publish
a
jmap
version
of
it.
Do
we
want
to
do
all
these
together
and
then
I
guess
the
question
is
going
to
come
up
for
our
area
directors
at
some
point,
are
we
going
to
try
and.
H
B
M
To
respond
really
briefly
to
to
pete,
I
think
that
something
neil
said
that
is
also
relevant,
is
putting
putting
aside
what
the
back
end
server
does.
If
what
we
want
is
for
different
clients
to
be
able
to
interpret
the
semantics
of
what
the
server
plans
to
do
then
indicating
it,
as
this
message
is
snoozed
until
such
time
is
easier
to
interpret
than
client
a
has
indicated,
this
message
should
be
moved,
moved
or
unflagged
at
some
future
time
and
client
b
must
understand.
M
That's
the
common
parlance
for
snooze
so
being
able
to
apply
a
name,
I
think,
has
a
lot
of
value
to
it,
regardless
of
the
back
end,
semantics,
alexi,.
E
In
just
before
lexi
in
the
queue
again,
I
was
just
going
to
reply.
My
approach
is
not
from
this
is
what
how
back-ends
have
implemented
it.
My
approach
was:
this
is
how
it
works
as
a
product
in
various
different
services.
It's
it's.
You
know
from
a
user's
point
of
view,
there's
quite
a
lot
of
consistency.
D
B
D
D
E
Just
it
has
to
be
a
mailbox,
because
otherwise
it
will
only
work
in
clients
that
have
explicitly
added
support
for
it,
whereas
when
it,
if
it's
a
keyword,
look
like
you're,
just
not
gonna,
do
anything
in
other
clients.
If
it's
a
mailbox,
they
will
sync
the
stuff
and
it
will
have
moved
out
of
the
inbox.
It
will
move
back
into
the
appropriate
time.
They
don't
have
to
know
anything
about
it,
so
it
can't
be.
A
keyword
has
to
be
in
the
mailbox.
D
M
F
My
question
is
based
off
on
what
pete
said
about
the
backing
store
and
the
implementation
being
true.
So
this
is
very
basically
a
concept
of
what
really
is
a
mailbox
in
the
mail
dire
world
or
the
mbox
world.
It's
a
file,
it's
a
file
that
recites
a
particular
place.
But
if
you
take
this
whole
concept
into
a
database
sort
of
a
bad
thing,
then
it
becomes
basically
some
table
or
something
in
a
database
hierarchy.
F
So
me.
So
what
I'm
going
to
say
is
a
mailbox
as
a
concept
versus
a
mailbox
as
a
particular
place
or
something
so.
A
mailbox
has
a
concept
that
is
implemented
using
tags
or
mailbox.
That
is
a
concept
that
is
implemented
using
a
directory.
I
think
we
might
need
to
just
think
a
slightly
more
into
how
it
may
actually
happen
in
the
real
world
and
excuse
me
if
I'm
speaking,
something
which
you
guys
already
know,
because
I'm
very
very
new
in
this
area.
M
I
think
we've
reached
the
end
of
the
queue.
Okay,
let's
take
a
next
slide.
I
think
I'll
try
and
I
think
that's
about
it.
Just
about
yeah,
okay,
there's
one
two
more
things:
one
is
it's
worth
noting
that
what
fast
mail
does
and
its
implementation
is.
We
have
a
conventional
flag
that
is
used
to
indicate
a
message
recently
awoke
that
lets.
You
see
the
message
isn't
just
back
in
your
mailbox.
You
didn't
forget
that
you
ever
snoozed
it
it
is.
You
can
see
this
has
been
deferred.
M
I
think
a
suggestion
and
a
registered
common
flag,
for
that
would
be
useful
or
we've
taken
a
got
a
bit
off
the
rails
on
exactly
what
happens,
but
this
function
is
useful.
Similarly,
the
save
date
extension
is
useful
here
because
you
can
see
when
the
message
returned
to
the
mailbox,
if,
in
fact
it
has
left
and
returned
to
the
mailbox
as
part
of
being
snoozed
and
awoken
next,
I
think
that's
the
last
slide
on
snooze
yeah,
but
let's
talk
about
the
sieve.
One
well
we'll
do
that.
M
Next,
okay,
shall
we
move
on
to
the
next
topic?
Yeah.
M
I
like
to
think
this
one
is
simpler,
but
let's
see
it
does
call
into
question
what
is
a
mailbox
so
right.
So
a
number
of
implementations
now
client
implementations,
let
you
visualize!
Well,
they
let
you
see
mail
with
labels
stuck
on
it
implemented
in
one
of
several
ways.
Sometimes
it
is
using
user
flags,
sometimes
you're.
M
Putting
the
message
in
multiple
mailboxes
gmap
is,
to
some
extent
built
around
the
idea
that
you
will
put
an
email
in
multiple
mailboxes
and
these
can
be
treated
like
labels
and
because
you
truck
with
emails
in
terms
of
a
single
email
in
multiple
emails,
no
special
work
is
required,
but
if
we
want
to
expose
this
in
imap
for
clients
that
would
like
to
show
the
various
mailboxes
in
which
a
message
appears,
which
is
to
say
the
various
labels
on
the
mailbox,
we
need
to
do
some
work
next.
M
So
if
we
want
to
implement
what
I
will
call
labels
mode
today,
you
need
the
server
to
implement
object
id
because
we're
going
to
want
to
map
from
emails
found
in
a
mailbox
to
the
mailboxes
in
which
they
are
found,
and
then
to
do
that.
Mapping
we're
adding
a
data
item
to
the
messages
called
mailbox.
Ids
mailbox
ids
is
a
list
of
the
object
ids
of
the
mailboxes
in
which
this
email
appears
and
the
email
here
is
as
per
the
object
id
capability.
M
It's
it's
any
message
with
the
same
email
id,
which
I
believe
is
defined
as
the
same
uid
validity
uid,
and
it's
all
the
all
the
non-changeable
content
of
the
message
between
mailboxes
every
mailbox
that
appears
in
when
you
fetch
its
mailbox
ids.
You
will
be
told
what
the
mailboxes
are.
You
can't
change
this
property,
it's
computed
for
you
when
you
copy
move
delete
whatever
else
these
messages,
that's
how
you
change
the
mailbox
ids.
O
M
The
complication
we've
been
talking
about
internally,
and
I'm
sure
there
will
be
many
complications-
is
that
if
you
have
this
computed
property
on
a
message
in
mailbox
1
and
that
message
is
also
found
in
mailbox
2,
but
you
delete
it
from
mailbox.
2
you'd,
like
the
mod
seek
in
mailbox
1
to
be
updated
because
its
mailbox,
ids
property
has
been
updated
through
action
at
a
distance.
M
This
is
going
to
be
either
complicated
or
not
depending
on
your
implementation.
Unfortunately,
it's
a
little
complicated
for
our
implementation.
Your
mileage
may
vary
next
yep.
If
you
want
to
set
the
mailbox
ids
or
the
labels
on
a
message,
you
just
move
it
around.
It's
all.
It
should
all
be
able
to
work
implicitly.
M
One
thing
that
does
come
up
is
this
leads
us
to
want
a
the
ability
to
copy
a
message
into
a
mailbox
only
if
it
does
not
already
exist
by
email
id.
This
should
probably
be
spun
off
into
a
separate
conversation,
so
I
don't
want
to
get
too
far
into
it.
B
Next,
that
could
possibly
be
done
with
mod
seek
checks,
but
I
can't
remember
whether
copy
and
move
allow
you
to
test
mod
seek
store,
certainly
does.
M
Yeah,
I
don't
know
yeah
yeah
great
much
more
prosaic
concern
any
client.
That's
any
good
that
allows
you
to
use.
Labels
allows
you
to
color
the
labels
and
we'd
like
to
allow
that
for
labels
mode
of
imap.
So
this
is
registering
a
piece
of
metadata
for
the
mailbox
where
we
store
the
color
define
the
way
we
do
everything
these
days
as
a
css3
named
color
or
rgb
code.
M
D
B
M
So
I
won't.
But
if
you
can't
get
the
metadata
in
the
list
and
that's
where
we've
put
the
color
you're
going
to
have
to
select
every
mailbox
to
display
the
labels
efficiently
and
that's
no
good.
J
B
M
Those
changes
are
in
concept
straightforward,
but
I
think
they
led
us
to
efficiently
bootstrap
an
imap
client
to
display
multi-mailbox
labels
with
with
color
and
to
keep
it
in
sync
efficiently.
Depending
on
the
implementation,
we
have
one
person
in
queue,
sir.
F
Just
thinking
about
this
color
thing
is
what
makes
the
jmap
preferences
object
actually
become
part
of
the
protocol
in
this
particular
use
case,
as
I
understand,
because
we're
talking
about
thunderbird
on
one
machine
on
my
linux
box
and
the
thunderbird
on
the
windows
box.
Basically,
I
want
to
have
the
same
interface
and
the
best
place
to
keep
that
information
is
in
the
server.
So
that's
where
we
could
put
something
like
a
preferences
object,
preferences
for
the
mailbox
and
the
preferences
object
per
se
could
be
actually
opaque
in
terms
of
whatever
information
you
put
it.
M
E
M
I
think
it's
absolutely
it's
absolutely
plausible
to
talk
about
jmap
being
useful
as
a
sort
of
a
generic
key
value
store
for
well-known
properties,
but,
on
the
other
hand,
being
able
to
say
there's
one
specific
property
which
is
color,
which
we
apply
to
the
mailbox,
gets
rid
of
a
lot
of
complexity
and
thinking
about
what
else
people
will
use
a
generic
key
value
store
for
fastmel's
already
got
an
extension
for
the
color
property
on
mailboxes.
We
already
implement
it
in
terms
of
metadata
on
the
mailbox
and
it's
dead,
simple.
M
B
B
There
we
go
list
return
metadata.
This
is
for
anyone.
Who's
seen
list
return
my
rights.
This
will
look
very
familiar
to
you
it
it's
very
similar.
Basically,
you
say
well
you're
giving
me
a
list
for
each
mailbox
call
get
metadata
on
that
mailbox
with
the
following
properties,
and
it
looks
like
this
is
that
readable
at
that
size,
maybe
not.
B
Thanks
we
we
have
plenty
of
time
for
that.
I
should
have
you.
I
should
have
removed
some
more
things
from
it
anyway,
as
you
can
see
here,
if
you
say
list
return
and
you
say
metadata
and
you
give
a
list
of
the
metadata
items
you
would
like
it
to
return
after
each
list.
It
then
returns
the
get
metadata
response,
as
you
can
see,
looks
absolutely
identical
between
the
trash
line
there
and
the
get
metadata
on
the
same
trash
with
the
same
properties,
and
it
just
says
here's
the
value
of
these
things.
B
So
it's
very
simple
and
it
allows
you
to
do
a
full
listing
on
the
server
and
get
the
metadata
at
the
same
time,
this
is
implemented
in
cyrus.
Imap
has
been
for
very
many
years.
I
can't
remember
whether
I
added
an
x
capability
for
it
or
not-
probably
not,
but
it
would
be
very
easy
to
do
so.
I
will
write
a
draft
and
ask
my
co-chair
to
do
a
call
for
adoption
on
this,
and
it
should
be
pretty
trivial.
I
imagine
any
comments.
N
This
is
candice
one
comment,
so
this
is
really
the
only
way
to
get
all
the
information.
As
rick
was
saying
in
one
go
since
when
get
metadata
was
changed
from
annotate
more,
I
think
we
removed
the
ability
to
wild
card
the
list
of
mailboxes
that
you
want
to
fetch
that
item
on,
so
unless
we
put
that
back
in
the
wild
carding
back
in,
I
think
this
is
probably
the
most
efficient
way
to
do
this
and
we
already
have
a
handful
of
return
options
anyway.
So
adding
this
one
makes
sense
to
me.
L
D
B
D
Well,
I
do
wonder
whether
we
can
just
kind
of
start.
Adoption
call
well
ask
stefan
to
refresh
it
and
say
we'll
adopt
it.
You
know,
but
if
obviously
you
know
no
guarantee
that
it
get
done,
I
suppose,
but
I
would
rather
adopt
it
and
work
it
in
the
working
group.
Even
if
we
run
out
of
steam
at
some
point
and
decide
it's
not
tractable.
I.
B
B
L
This
is
barry,
if
he's
not
willing
to
continue
with
it,
I'm
happy
to
take
it
over
but
yeah,
regardless
of
what
state
it's
in.
I
think
we
should
just
adopt
it
and
go
from
there.
B
Mid
next
year,
we
can
do
other
things
for
that.
Okay
extra
milestones
submit.
What
do
we
want
to
submit
here?
We've
got
a
bunch
of
documents,
don't
we
that
we
have
agreed
are
going
to
go.
I'm
at
partial
process.
Imip
snooze
sounds
like
we
may
be,
delaying
that
a
little
bit
just
because
we're
all
the
snow
stuff
will
will
happen,
but
sieve
registry.
L
B
All
right
so,
but
I
will
put
in
adopt
a.
B
B
B
F
B
F
Right,
so
what
google
did
was
it
it
added
its
own
things
with
the
x
dash
tag,
while
the
my
map
basic
thing
has
the
labels
it,
but
it
seems
outlook.
There's
exchange
does
not
really.
Sometime
back
when
I
checked
it,
wasn't
a
supporting
some
sort
of
labels.
I'm
I'm
just
that's
one
of
the
issues.
The
implementation
issue
that.