►
From YouTube: IETF109-EXTRA-20201118-0730
Description
EXTRA meeting session at IETF109
2020/11/18 0730
https://datatracker.ietf.org/meeting/109/proceedings/
B
I
yes
quickly
interrupt
you
who's,
taking
notes.
A
I'll
probably
take
notes.
Actually
I
have
the
session
open
to
do
that.
A
A
Documents
so
we
have
fetch
preview
and
sieve
mailbox
id
that
are
both
sitting
submitted
for
publication
and
in
area
director
follow-up,
so
barry.
If
you
are
available
to
to
talk
to
what's
happening
there.
That
would
be
great.
C
Which
one
the
fetch
preview?
Okay,
I
mean,
I
guess
what's
status
of
that
is,
I
need
to
go.
Look
at
it
so
yeah.
Let
me
do
while
we're
having
this
meeting
and
I'll
get
back
to
you.
A
D
A
To
go,
go
and
follow
the
special
use
process,
which
includes
creating
a
new
mailbox
with
that
special
use
if
it
doesn't
exist.
But
it's
it's
basically
binding
the
mailbox
I
do
most
tightly,
which
I
think
does
actually
also
make
most
sense,
because
it's
the
most
explicit
thing,
but
it's
very
unlikely
that
anybody
would
ever
specify
both.
C
Well-
and
that's
that's
really
my
question-
that
it
doesn't
make
sense
to
me
to
specify
both
and
it
would
make
me
happier,
although
I'm
not
going
to
hold
out
on
this
one
too
long.
But
I
wanted
to
have
the
discussion
it.
It
would
make
more
sense
to
me
to
say
that
they
that
you
can't
put
them
together,
because
in
the
one
case,
you're
looking
for
a
specific
mailbox
by
id
and
in
the
other
case,
you're
looking
for
a
function
and.
A
A
B
C
B
Now
I
understand
I
was
just
trying
to
think
of
if
we
are
to
leave
the
combined,
allow
the
combination
of
the
two,
what
the
semantic
is
going
to
be.
C
The
semantics
would
be
that
if
the
mailbox
id
exists,
then
you
use
it.
Otherwise,
you
fall
back
to
the
special
use.
D
C
C
But
what
you
create,
I
guess,
would
have
the
the
special
use
attached
to
it,
but
would
be
a
different
mailbox
id
it.
It
all
seemed.
C
A
I'm
happy
to
do
that
as
well.
I
think
I
can't
think
of
a
reasonable
case
where
you
would
have
to
have
both.
A
I
guess
it's
a
nice
fallback
in
in
the
case
where
that
mailbox
gets
deleted,
that
it
would
get
recreated
with
the
special
use,
but
if
it
gets
deleted
and
then
something
creates
something
with
that
special
use
already,
then
it
will
file
into
there
without
having
to
create
a
new
one,
and
this
is
I'm
thinking
kind
of
on
my
feet
here,
but
the
example
I'm
thinking
of
is
that
you
had
to
file
into
with
the
specific
mailbox
id
defined
just
because
your
system
automatically
does
that.
A
A
E
I
I
think
I'm
leaning
towards
very
suggestion
of
making
them
mutually
exclusive
and
they
cannot
be
used
together,
especially
in
light
of
the
fact
that
we
have
a
test
for
both
if
the
mailbox
id
exists
and
a
special
use
exists.
So
you
can
write
a
script
that
will
handle
both
cases
just
by
using
the
tests,
as
opposed
to
having
everything
jammed
into
one
action.
A
A
B
Cool,
so
we
do
have
murray
here.
So
that's
great
right,
quick
update
and
the
war.
I
think
there
were
like
three
revisions
since
july.
B
Catching
few
other
remaining
things
like
list
of
recommended
extensions
and
stuff
next
slide.
Please.
B
Yeah,
so
on
pointed
out
that
the
text
in
the
at
the
front
of
the
document
was
still
talking
about
sort
of
changes
in
rfc
3501,
which
is
previous
version
so
needed
to
be
adjusted.
B
I
didn't
quite
go
all
the
way
with
on
suggestions
to
list
everything
that
changed,
but
I
think
I
added
enough
pointers.
So
hopefully
this
is
clear.
A
few
clarifications.
B
I've
noticed
that
star,
tls
description,
command
description
was
saying
that
it
can
return
bad
if
command
is
not
recognized.
Well,
how
can
it
be
not
recognized
if
it's
here
so
that
sort
of
sounded
like
a
silly
case,
but
there
is
a
more
useful
one,
which
is
if
somebody
issues
30
ls,
when
tls
is
already
active,
whether
just
repeated
start
tls
or
on
telesport.
B
So
this
now
is
clear
that
this
returns
bad.
We
had
several.
B
There
were
several
remaining
issues
from
last
atf
about
making
sure
that
list
responses
are
mandatory
for
selected
and
examine.
B
So
this
is
fixed
and
examples
were
updated.
If
people
can
send
you
check
examples.
That
would
be
great
some
clarification.
There
was
some
old
text
about
uid
and
x
and
ud
validity
about
what
the
behavior
is.
If
they're
not
there.
At
the
same
time,
they
are
mandatory
elsewhere
in
the
text.
So
it's
it
wasn't
entirely
consistent.
So
I
think
yeah.
I
basically
deleted
the
old
text.
B
And
we
also
added
some
text
about
how
mailbox
canonicalization,
whether
it's
due
to
normalization
or
some
other
kind
of
mapping
rules
can
be
done
and
how
this
is
written.
Returning
list
responses
for
when
mailboxes
get
deleted,
when
mailboxes
get
renamed
like
to
specify
that
client
issued
this
name,
but
now
new
name
is
you
know
something
else?
B
So
please
text
about
that?
I
think
that's
all
changes,
oh
actually!
No,
I
think
there
is
another
slide
next
slide.
B
Please
yes,
there
are
there.
Are
there
were
a
few
more
things?
B
We
had
discussion
last
itf
that,
whether
to
clarify
that
each
you
search
with
the
currently
specified
options
like
mean
man
max
count
and
all
whether
it
allowed
to
return
multiple
research
responses
that
have
to
be
amalgamated,
and
now
the
document
says
that
that's
not
allowed.
You
can
write
an
extension
which
allows
for
that,
but
you'll
need
to
specify
this
explicitly.
B
B
There
were
several
comments
from
stefan
about
like
for
well-formed
messages.
It's
clear
what
the
date
should
be,
what
you
know
in
in
envelope
and
various
other
places.
So
there
is
now
more
clarity
about
how
this
kind
of
football
formed
or
draft
messages
so
like
when
you
wrote
an
empty
strings
when
you
return
nails
and
stuff
like
that,.
B
B
B
B
I
rationalized
that
I
think
I
removed
everything
that
was
done
now,
because
we're
really
late
in
in
the
process-
and
there
shouldn't
be
any
open
issues
about
that,
and
then
there
is
a
new
section
about
recommended
extensions
I'll
revisit
this
very
quickly
today,
just
to
make
sure
that
people
are
comfortable
for
now
it.
It
mentioned
quicker,
sync
on
store
and
object
id,
but
we
can
discuss
if
people
want
to
add
something
else.
B
B
Right,
I
was
checking
my
notes
and
I
was
like
I
thought
I
I
did
everything
and
then
I
found
out
that
there
was
some
changes
in
relationship
to
supporting
64-bit
message
sizes.
B
I
forgot
to
do
this
change.
I
think
I
still
I
or
somebody
or
chairs
should
probably
still
double
check
on
the
main
english
that
people
are
happy
to
go
with
this,
because
this,
your
servers,
don't
have
to
support
this,
but
the
clients
always
have
to
support
this
because
they
they
have
to
accommodate
bigger
message,
sizes,
basically
orbit
bar
sizes.
B
That
shouldn't
take
very
long.
I
had
a
separate
draft
on
this,
which
was
parked
few
years
back,
so
this
is
mostly
just
debian
f
fixes
to
allow
for
bigger
sizes.
B
If
you
have
opinions
one
way
or
the
other,
please
shout
I
double
checked
with
teemo,
see,
ryan
and
yesterday
he
said
that
he
served
already
support
64-bit
message
and
body
part
sizes,
so
he
will
be
quite
happy
with
this
change
and
from
notes
from
our
previous
meeting.
I
think
braun
was
happy
with
this
as
well,
but
if
somebody
really
doesn't
like
it,
please
let
me
know.
A
Yeah
the
only
challenge
with
it
is:
what
happens
if
you
have
a
message
in
your
store,
which
is
more
than
32
bits
and
a
non-imap4rev2
client
connects?
Does
it
get
a
truncated
version?
Does
the
message
not
appear
to
it
and
how
does
that
work
and
we
haven't
solved
this
problem?
A
No
particular
trick
is:
if
you
connect
us
an
imap
for
rev1,
do
some
queries
decide
to
upgrade
to
imac,
4,
rev,
2
and
suddenly
uids
appear
that
were
not
present
as
rev1,
so
it
does
mean
that
you
need
to
treat
rev1
and
rev2
as
completely
separate
for
caching
message
id
number
purposes
if
you're
going
to
have
messages
that
disappear
and
reappear,
depending
which
mode
you're
in.
A
This
is
going
to
be
very
tricky.
To
be
honest,
I
said
I
mean
the
the
main
thing
is
to
say
either
always
use
it
for
f2
or
never
use
I'm
at
402
with
the
same
server.
Don't
mix
them,
yes,
which
is
probably
a
good
good
advice
anyway
yeah.
So
it
might
be
worth
putting
specific
suggestion
for
that
in
the
text.
B
So
that
we
don't
forget-
and
I
I
think
yeah
we
might
need
to
discuss
the
whole
concept
of
hiding
some
messages
which
are
too
big
to
be
exposed.
How
this
is
going
to.
B
B
However,
irrespective
of
this
question,
I
think
the
document
as
far
as
our
responsible
id
is
concerned,
I
think
murray
can
just
review
the
document,
as
is
once
this
is
implemented.
This
will
be
a
very,
very
small
small
patch
to
the
draft,
so
murray,
don't
make
it
stop
you
from
reviewing
the
document.
F
A
That
should
be
closed.
Okay,
yep,
the
working
group
last
call
is
finished.
I
was
just
checking
if
there's
anything
to
oh,
I
would
have
submitted
it
a
couple
of
weeks
ago,
but
life
got
in
the
way,
and
now
I
thought
we're
going
to
be
talking
about
now,
anyway,
I'll
submit
it
after
this
just
in
case
some
last
minute
thing
comes
up.
F
B
A
B
Next
slide
just
to
triple
check
fairly
new
section
about
recommended
extensions.
B
Writing
a
client
I
found
bits
of
acl
expect
to
be
useful.
For
example,
some
clients
issue
my
rights
very
frequently
just
to
see
whether
they
are
allowed
to
do
various
operations
which
so
I
would
be
weakly
suggesting
to
add
acl
to
the
list.
Just
as
a
you
know,
obviously
it
might
not
work
for
access
control
models
for
some
mail
stores,
but
if
you
do
it,
you
know
do
it.
This
way,
kind
of
thing.
B
All
right,
multi-mailbox
search,
I
think
it
it's
a
great
functionality,
not
sure
how
widespread
it
is.
So,
maybe
not
just
yet.
B
Yeah,
well,
I
did
add
some
weasley
words
in
the
document
saying
that
if
you
don't
see
your
favorite
extension
here,
it
doesn't
mean
that
it's
not
recommended
so.
A
A
C
For
me,
so
just
back
on
fetch
preview,
I
put
in
an
rfc
editor
note
for
the
a
small
edit
that
we
had
talked
with
rob
wilton
about
and
that
michael
hadn't
put
in,
but
other
than
that
I
it's
fine.
So
I
I
gave
it
the
final
approval.
You
should
see
it
going
to
the
rfc
editor
queue
anytime.
A
Cool
then
we
are
done
with
I'm
at
four
rev
two
and
we
are
well
ahead
of
schedule
at
the
moment,
but
I
guess
we
may
as
well
move
on
to
our
next
topic,
which
is
quota
so
alexi
welcome
back.
B
Yeah,
I
was
my
apologies
for
I
just
posted
the
zero
three
yesterday,
because
I
haven't
done
much
on
it.
B
Yeah,
so
I
was
debating
this
for
very
long
time
about
whether
the
document
specifies
status,
deleted
and
capability
storage,
which
is
number
of
deleted
messages
and
number
total
ties
of
delete
messages.
B
I
was
sort
of
debating
four
months
with
myself
whether
they
should
be
tied
to
specific
capabilities.
As
in
you
know,
if
your
server
supports
quarter
on
message
numbers,
then
you
should
support
my
status
deleted.
B
I
didn't
get
much
feedback
on
this,
but
I
thought
I'll
just
go
ahead
and
go
with
it
and
make
it
slightly
easier
to
implement.
Obviously,
if
you
do
both
already
that
make
no
change,
you
know
it
doesn't
make
any
difference
for
you.
But
if
you
are
thinking
about
implementing
one
another,
then
it
makes
it
slightly
easier
to
implement
on
the
server
side
and
then
the
idea
is
deleted
and
stated
deleted.
Storage
is
client.
Can
answer?
Ask
the
question:
how
much
space
can
I
free
to
get
under
quarter?
G
B
Do
people
have
a
strong
opinion
either
way
I
on
one
hand
we
can
tighten
definition
of
tag
to
disallow
this,
but
if
there
is
any
client
that
decides
to
generate
tags
with
this,
then
they
will
become
non-compliant
with
this
change.
I'm
slightly.
B
A
B
Bogus
yeah,
I
suppose
we
can
say
that
you
know
it
will
work
most
of
the
time
as
in
you
know,
unless
you
have
a
stupid
tag,
it
will
work
over
quarter
has
actually
two
forms.
One
is
just
over
quarter
with
no
tag.
It
means
you
know,
for
the
current.
B
The
current
operation
and
over
quarters
space
tag
is
for
cases
where
you're
moving
message
like
from
one
mailbox
to
another.
You
sort
of
want
to
know
whether
your
current
one
is
reporter
or
the
destination
one.
So
it
helps
a
little
bit.
B
How
important
is
this?
Do
people
think,
as
in
to
convey
this
information
that
over
quarter
relates
to
a
specific.
A
A
B
Okay,
so
actually
yeah
sort
of
just
like
this,
but
I
think
you
answered
my
question
that
it's
probably
just
drop
this
feature
and
don't
bother
with
this
will
avoid
all
sort
of
complications.
Fine,
let's
do
that
unless
I
hear
otherwise
I'll
do
this
in
an
extra
vision.
I
think
that's
it
what's
the
next
is.
There
are
more
slides
to
this.
I
don't
remember
now
future
directions
yeah
my
usual
questions.
Basically
anything
missing
anything
should
be
removed.
A
Cool
should
I
do
that
with
the
next
document,
whether,
where
the
over
quota
space
tags
been
removed,.
A
A
A
Awesome
all
right,
thank
you.
Alexi
next
topic
is
gmap
civ
snooze
from.
E
Ken
okay,
so
the
first
revision,
zero,
zero,
pretty
much
encapsulates
what
we
have
implemented
and
are
using
at
fast
smell
at
this
moment.
The
next
slide.
If
you
want
to
move
forward,
please.
E
E
Currently,
we
use
a
special
mailbox
at
fast
mail
next
slide,
please
so
here's
a
current
syntax
there's
one
required
argument,
which
is
a
list
of
times
in
hour
minute.
Second
format:
along
with
that,
there's
a
time
zone
id
string,
which
is
a
a
timezone
ib.
E
So,
basically,
the
combination
of
weekdays
and
times
forms
a
chronological
list
of
awakened
times.
So
when
a
message
arrives,
it
gets
snoozed
until
the
next
awaken
time.
In
that
list,
so
a
couple
quick
examples.
Obviously,
if
you've
got
something
that's
monday
through
friday,
awaken
times
of
9
00
a.m
and
3
p.m.
The
message
arrives
at
8
a.m.
It'll
awaken
the
same
day
at
nine.
It
arrives
at
three
pixel
if
it
arrives
at
noon.
E
E
So
we
also
support
with
our
current
implementation
of
these
various
extensions.
So
if
you
have
imp
for
flags,
you
can
specify
and
add
flags
and
remove
flags
option
which
will
set
an
unset
flags.
When
the
message
is
awakened,
you
can
use
the
map4
flags
with
the
variables
if
you
want
to
set
something
at
snooze
time,
that's
done
via
the
internal
variable,
so
that
would
be
a
set
flag
or
add
flag
actions
separately.
E
Additionally,
going
back
to
one
of
our
earlier
conversations,
we
actually
support
create
special
use,
a
mailbox
id.
I
will
certainly
update
this
draft
to
discuss
that
mailbox.
Id
and
special
use
are
mutually
exclusive
in
that
respect,
but
in
any
case,
all
three
of
those
options
have
to
do
with
the
awaken
mailbox,
not
the
snooze
mailbox
next
slide.
Please.
E
So
it
was
mentioned
on
the
list
by
stefan.
I
believe
he
asked
why
this
is
a
separate
action
versus
just
being
additional
parameters
or
arguments
keep
and
file
into,
which
seems
like
a
logical
discussion
to
have
two
questions
are:
what's
the
syntax
going
to
look
like
and,
more
importantly,
at
least
for
our
use
case?
How
do
you
specify
flags
to
be
set
at
snooze
time
and
at
the
awaken
time?
E
Next
slide,
please
in
terms
of
syntax,
I
think
there
are
three
possible
options,
maybe
more.
If
someone
here
has
alternate
solutions,
I'm
open
to
hearing
them,
so
we
could
just
jam
all
the
additional
arguments
in
line
with
the
existing
file
into
arguments.
E
But
if
you've
got
something,
that's
gonna
support,
you
know
the
times
the
weekdays
the
timezone
id
create
and
special
use.
The
the
list
of
arguments
is
going
to
get
pretty
unwieldy
kind
of
what
we
already
have
with
fcc.
E
I
did
some
digging
around
the
abn
f
for
civ
itself,
and
it
appears
as
if,
even
though
it
might
be
ugly,
we
could
use
the
test
list
syntax
at
the
end
of
a
command
which
appears
to
be
legal.
So
there's
an
example
there
of
what
this
may
look
like.
E
It
kind
of
encapsulates
all
this
new
specific
stuff
into
its
own
apprentice.
Its
own
structure
at
the
the
very
tail
end,
don't
know
how
people
feel
about
that.
Additionally,
on
the
next
slide,
it
also
looks
like
we
could
use
a
block
at
the
end
of
filing
to
or
keep
which
also
appears
to
be
legal
for
the
syntax.
E
A
B
When
people
list
interactions
with
other
actions,
this
is
less
likely
to
be
forgotten.
If
it's
already
an
existing
action
that
I
know
it
might
not
be
a
strong
argument,
but
the
fewer
actions
we
have
the
easier
it
is
to
list
how
you
interact
with
all
of
them.
B
Can
ken,
can
you
remind
me
why
you
want
flags
to
be
both
at
the
snooze
time
and
then
at
delivery
time.
E
I
could
let
neil
make
that
argument
if
he
wants
to
jump
in
otherwise
I'll
I'll
go
ahead.
H
Sure
is
this
on
yes,
yes,
we
can
hear
you
yep
all
right,
great
yeah,
so
basically
at
delivery
time,
the
flags
are
set
as
pony
normal
stuff,
so
you
might
mark
red
or
pin
or
whatever,
but
then
at
awaken
time.
We
set
a
particular
dollar
new
flag
so
that
we
can
mark
out
those
messages,
especially
when
they
move
back
to
your
inbox
and
then
once
when
you
actually
open
the
message.
We
clear
that
flag,
we
and
because
conversations
amalgamate
different
messages,
some
of
which
may
be
snooze
you.
H
E
The
other
issue
we
have
in
our
implementation
is
because
we
actually
have
a
news
mailbox
that
that
an
imap
client
can
see
the
user
could
fiddle
with
flags
and
change,
something
that
they
may
actually
may
want
to
have
set
or
run
set
when
it
actually
does
get
awakened
right.
B
H
Yeah
I
can
have
I'll
bring
up
the
code
down,
have
a
quick
look,
but
it
might
be
okay
if
you
only
set
them
on
delivery,
but
I'd
have
to
double
check
all
the
things
we
do
to
see.
If
that
is
going
to
work,.
C
H
I
mean
as
long
as
the
if
all
the
messages
are
actually
delivered
to
a
mailbox.
It's
just
it's
delivered
to
a
snooze
mailbox
and
the
conversation
view
in
your
client
shows
all
of
them.
Then
you
won't
like
miss
some
that
were
snoozed
earlier.
If
something
else
comes
in,
like
that's
actually
a
valid
use
case,
if,
like
you
normally,
you
would
snooze
it,
because
if
it's
from
a
main
list
you
don't
care
about
too
much.
But
if
it
comes
from
a
particular
person
you
do
care
about.
You
don't
want
that
to
be
snooze.
C
So
it
might
be
worth
putting
something
like
that
in
as
non-normative
text
in
in
the
document
somewhere
of
maybe
implementation
considerations,
just
warning
that
this
can
cause
some
funny
things
depending
on
how
the
client
displays
the
messages.
That's
all.
D
This
up
on
the
list
that
there's
some
security
in
you
know
implications
here,
and
they
they
vary
pretty
dramatically.
Depending
on
how
you
implement
this.
If
you
implement
it
like
using
a
future
release
sort
of
mechanism,
then
the
messages
aren't
visible
at
all
anywhere
until
they're
unsnoozed,
and
that
has
some
really,
I
think,
potentially
you
know
serious
implications.
D
You
know
to
users
and
if
you
use
the
mailbox
trick,
where
you
put
them
in
one
and
then
switch
them
to
another,
you
get
different
behavior.
But
the
other
thing
you,
you
know
when
you
use
those
different
tricks.
You
know
the
delivery.
Dates
are
going
to
be
very
different
and
the
threading
situation
is
going
to
be
different.
You
know
lots
of
potential
confuse.
You
know
for
confusion
here.
H
Yeah
I
mean
we
didn't
really
go
with
the
deliver
to
a
special
mailbox,
one
which
I
think
solves
the
most
these
problems.
The
delivery
date
is
the
regular
delivery
date
because
it's
not
delivered
late.
It's
threaded
in
with
all
the
other
messages
immediately.
If
you
want
to
go
find
you
can
search
with
everything
else.
I
I
think
that
the
the
reason,
the
spot's
kind
of
more
open
on
that.
H
Yeah,
I
think
it
was
the
spec
was
written
this
way
to
just
try
and
make
it
easier
to
accommodate,
for
if
there's
existing
systems
doing
something
different.
But
having
said
that,
I
don't
think
any
I
know
of
are
doing
a
delayed
delivery.
But
please
correct
me:
if
someone
knows
about
one
that
is
implementing
this
in
a
different
way,.
D
C
Sorry,
the
issue
that
ned
and
I
are
bringing
up-
isn't
that
we
shouldn't
do
this,
but
that
you
need
to
say
more
in
the
document
to
guide
people
who
are
implementing
it
on
what
the
pitfalls
are.
And
you
know
you
can
say
that
if
this
is
implemented
this
way
it
works
better
than
if
it's
implemented
that
way
or
something
like
that.
D
A
In
the
queue
for
a
while
too
so,
let's
not
forget.
I
I
So
I
I
want
to
second
that
the
other
thing
I
think
is
right
on
that.
We
should
think
about
how
this
is
going
to
actually
perform
for
for
the
user.
I
think
barry's
concerned
that,
like
if
someone
setting
flags
that
they
know
what
they're
doing
is
maybe
not
maybe
not
correct
what
we're
specifying
here
is
not
actually
something.
That's
like
a
user-facing
feature.
This
is
like
a
mechanism
that
I
would
imagine
good
male
clients
will
use
to
implement
something
that
the
user
is
going
to
understand.
I
Right,
like
they'll,
have
a
fuse
button
in
it
and
they'll
choose
one
standard
set
of
behaviors
and
they'll
implement
and
they'll
they'll
encode
that
maybe
via
active
command
on
the
back
end,
but
the
user
is
not
going
to
be
like
crafting
what
these
specific
options
are
right.
That
just
seems
unlikely
to
me,
so
I
think
you
know,
I
think
that
kind
of
guidance
for
male
user
agent
implementers
is
going
to
depend
on
what
the
back
ends
actually
do,
and
so
I
think
that
you
know
this.
I
This
idea
that
will
make
it
generic
and
you
can
do
arbitrary
back
ends,
isn't
actually
a
safe
thing
to
specify.
So
I
I
support
the
idea
of
saying
that
this
is
you
know
you
really
shouldn't
do
this
with
smtp,
you
know
delayed
delivery
or
anything
like
that.
H
Yeah,
I
I'd
be
happy
with
that.
I
also
think
it
makes
sense,
because,
if
you're,
this
is
just
for
basically
creating
rules
that
snooze,
if
you're,
going
to
implement
snooze
like
manually
for
a
user
you're
going
to
need
a
special
folder
for
anyway,
the
best
years
have
already
been
delivered,
so
it
it's
much
better
to
use
a
single
mechanism
and
have
two
different
mechanisms
of
doing
snooze,
depending
whether
it's
on
delivery
time
or
manually
afterwards.
H
I
also
I
just
had
another
quick
look
at
what
we're
doing
the
reason
we
want
to
be
able
to
set
flags
on
awaken
time.
The
main
one
is
some:
some
users
said
that
they
want
it
to
be
marked
unread
when
it's
awakened,
but
they
don't
want
it
to
be
marked
unread
immediately,
because
they
might
have
a
view
that
shows
all
on
their
mail
they
currently
have,
and
so
you
don't
want
it
showing
up
there
until
it's
news.
I
We
include
that
as
an
example
right
I
mean
as
you're
writing
this
draft
we're
thinking
about
how
implementers
are
likely
to
use
it
and
just
having
you
know,
a
sentence.
Example
of
you
know.
This
is
one
way
that
you
can
use.
It
might
might
be
useful
that.
H
B
E
B
B
E
B
E
E
E
The
tags
are
unordered,
so
you
know
you
could
have
these
things
intermingled
with
any
other
file
into
argument
like
we
had
with
with
fcc,
which
you
know
after
having
written
that
and
implemented
it
it.
This
looks
kind
of
ugly.
H
Yeah,
I
think
it's
gonna
be
cleaner
as
a
separate
command,
because
you
have
multiple
arguments.
You
need
for
the
snows
and,
as
ken
said,
if
they're
intermixed
with
other
arguments-
and
they
only
make
sense,
if
you
like
a
snooze,
add
flags
argument
only
makes
sense
if
you
have
a
separate
snooze
argument.
So
it's
invalid.
If
you
have
one,
not
the
other,
it
seems
cleaner
to
me
to
have
a
separate
command,
but
I
don't
really
care
what
the
syntax
is.
Usually
I'm
just
it's
just
might
be.
D
B
I
know,
but
it
would
be
nice,
you
know
even
if
you're
writing
you
like,
if
you're
considering
interactions
or
you
know,
look
up
in.
D
D
E
D
I
don't
have
a
strong
opinion,
though
I
really
don't
there's
arguments
either
way.
I
I'm.
I
am
a
little
concerned
about
the
whole.
You
know
using
tricky
syntax
to
do
things.
I
wonder
if
I
mean
I
can
handle
that
in
my
implementation,
but
I
I
mean
I
have
the
ability
to
you
know
evaluate
arguments
you
know
it
says.
D
All
right,
I'm
not
I
I
mean
you
know
the
way.
I
though
you
know
I
I
this
will
probably
sound
stupid,
but
you
know
basically
what
you
do.
Is
you
go
through
the
code
and
look
for
all
the
places
where
you're
doing
those
you're
looking
around
at
file
enters
and
you
make
sure
that
they're
looking
at
snoozes
where
it's
appropriate?
D
E
B
B
And
we
can
have
a
separate
discussion.
You
know,
registry
for
actions
that
might
be
just
a
nice
thing
to
do
anyway.
A
I
I
noted
that,
as
potentially
a
separate
draft,
anyone
want
to
volunteer
to
author
that.
E
A
Yep,
that's
the
final
slide
all
right,
so
I
guess
the
next
step
is
for
you
to
go
back
and
rewrite
having
made
it
that
it
requires
the
message
to
be
placed
into
into
a
folder
somewhere
that
the
user
can
see
somehow
and
creating
the
snoozed
registration.
B
E
A
Yeah,
so
we
can
make
it
that
if,
if
you're
using
an
imap
or
jam
up
server,
then
you
should
file
these
messages
into
a
mailbox
with
special
use
snoozed,
as
registered
here.
B
E
A
The
last
thing
that
we
have
here
is
just
a
glance
at
our
milestones,
looks
like
civ
ai.
We
still
need
to
come
back
to
quota.
Is
there
to
be
sent
off
timings
about
right
there,
ima
402
will
be
submitted
now,
sip
mailbox
id
has
been
submitted,
so
I
can
mark
that
one
as
done
and
sif's
news
has
been
adopted.
So
I'll
update
that
and
mark
that,
as
done,
I
don't
think
we've
got
anything
new
to
add
there
other
than
to
adopt
a
document
creating
the
civ
actions
registry.
A
That
was
a
a
not
really
because
I
suspect
that,
given
that
we
will
finish
this
work
off
fairly
early
next
year
and
we'll
be
very
quiet
for
a
little
bit.
A
All
right
thanks
everybody
in
that
case,
we've
basically
finished
our
time
here,
so
go
grab
yourself,
some
popcorn
and
a
stiff
drink
and
prepare
for
the.