►
From YouTube: IETF112-JMAP-20211109-1200
Description
JMAP meeting session at IETF112
2021/11/09 1200
https://datatracker.ietf.org/meeting/112/proceedings/
C
C
We'll
begin
with
the
with
the
note
well
which
from
looking
at
the
participants
list,
it
looks
like
everybody
is
familiar
with,
but
we'll
we'll
again
say
if
you're,
if
you're,
not
that
you
should
pay
attention
to
this,
because
it
governs
the
policies
on
intellectual
property
rights
for
things
that
you
say
in
ietf
meetings
and
participation
in
ietf,
mailing
lists
and
so
forth.
So
if
you're
not
familiar
with
it,
please
do
read
it.
C
And
we'll
start
with
an
agenda
bash
we're
doing
the
intro
and
note
well
now,
as
you
know,
ron's
gonna
start
with
gmap
blob.
C
Contacts
and
then
alexi
will
be
talking
about
some
work
that
is
going
on
in
the
extra
working
group.
That
is
comparable.
That
you
know
has
a
relationship
to
things
that
we
might
want
to
do
when
I'm
in
jmap
as
well.
So
that's
that's.
Coming
up
afterwards,
we've
got
a
little
bit
of
spare
time,
15
minutes
or
so
at
the
end.
If
we're
on
schedule
and
then
we
will
go
through
our
usual
milestone
review
at
the
very
end,
any
adjustments
or
comments
on
the
schedule
from
anyone.
B
If
you
add
this
up
carefully,
you'll
discover
this
isn't
even
filling
the
full
two
hours.
I
was
expecting
more
work
to
appear
at
this
meeting,
but
we
had
an
interim
just
a
couple
of
weeks
ago.
So
a
lot
of
stuff
was
resolved
there
and
not
much
new
work's
been
generated,
since,
in
fact
the
next
sli
slide
on
this
set
is
my
blob
slide
so
I'll.
If
there's
no
agenda
bashing
I'll,
just
go
straight
off
this
set
of
slides
if
you
want
to
keep
them
going
jim.
B
The
other
thing
I
did
want
to
say
up
the
front
of
this
is
that
I've
seen
in
some
other
working
groups,
there's
been
a
bit
more
discussion,
discussion
around
the
code
of
conduct,
bcp
54
area
and
in
particular,
being
welcoming
to
new
people
and
not
scaring
them
away
too
much
with
weird
jargon
and
and
dismissal,
so
definitely
to
anyone
who
does
come
in,
though,
of
course,
I'm
talking
to
people
who
aren't
here
yet
in
a
lot
of
cases,
please
feel
free
to
pop
in
and
ask
questions.
B
If
there's
something
you
don't
understand,
it's
quite
likely
there
might
be
someone
else
who
doesn't
as
well.
So
please
do
ask
questions
if
anything's
unclear,
so
this
slide
here
is
talking
about
blob,
and
this
is
a
draft
that
is
close
to
finished
now.
B
I
have
not
uploaded
the
latest
edits
in
it
that
have
come
since
a
couple
of
weeks
ago.
The
one
thing
that
was
pointed
out
that
I
really
hadn't
done
was
defining
the
encodings
really
well.
We
have
space64,
but
base64
wasn't
specifically
referenced
where
it
came
from,
was
just
assumed.
So
I'm
going
to
add
references
specifically
to
rfc
4648,
which
defines
it,
but
the
question
then
is:
should
we
define
as
hex
as
being
a
fixed
case
at
the
moment
it's
defined
as
being
lower
case
in
the
document,
but
rfc
4648
says
that
it's
case
insignificant.
B
Does
anyone
have
any
comments,
one
way
or
the
other
on
that?
Likewise,
should
we
rename
as
hex
to
ask
base
16
just
to
align
nicely,
and
would
anyone
want
base
32
should
I
include
it
for
completeness
or
just
leave
it
out,
because
I
didn't
see
a
use
case.
B
So
I
welcome
comments
on
any
of
that.
Once
I
have
the
feedback,
I
will
update
the
document.
I
think
jim
I'll
ask
you
to
do
a
working
group
last
call
at
that
stage,
because
it's,
I
believe
it's
basically
done.
Neil.
D
My
views
on
those
three
would
be
mo.
Everything
else
in
gmap
is
case
sensitive,
and
it's
generally
nicer.
If
you
can
assume
that
it
is
because
then
you
can
just
do
easier
comparisons
rather
having
two
case
and
sensitive
comparisons,
so
I
would
lean
towards
specify
must
be
lower
case.
It's
generally
what
we
use
for
that
kind
of
thing.
D
I
would
pick
as
hex
instead
of
as
base
16,
because
I
think
it's
more
obvious.
Just
if
you
haven't
read
the
specs,
what
you're
gonna
get
and
I
suspect
no
one
will
ever
use
base
32.
But
who
knows,
but
probably
not
that's
my
thoughts.
B
E
Don't
have
a
strong
opinion
either
way
if
we
think
it's
useful,
it
should
be
fairly
straightforward
to
document.
I
would
expect
cool.
E
B
C
C
So
I
guess
s
mime
is
next.
Is
there
is
there
any
more
discussion
on
blob.
C
Alexi
go
ahead,
I'm
hello,
can
you
hear
me?
Yes,
I
can.
G
Are
you
happy
with
flipping
through
slides
or
I
forgot
how
to
do
that?
To
be
honest,
I'm.
C
Happy
with
flipping
the
slides,
if
I
can
figure
out
how
to
oh
there's
the
closed
deck
button,
it's
down
there.
Okay,
I
was
trying
to
hit
the
little
a
little
chair
icon
for
it,
so
all
right
hold
on
a
sec
here.
C
G
So
there
are
actually
two
is
mime.
One
is
the
old
one
which
isn't
just
went
through
hg
last
call-
and
I
will
talk
about
this
first
and
then
I'll
talk
about
the
new
one.
G
So
yeah,
I
think
there
were
quite
a
few
changes
since
last
time.
I
I
really
remember
I
couldn't
make
it
to
jmap
session
in
july,
so
yeah
lots
of
changes
between
version
3
and
10,
which
is
the
current
one.
G
Major
things
is
basically
addressing
comments
from
gen
art,
art,
directorate,
etc.
Some
comments
about
better
formatting,
you
know
split
into
sub
sections.
You
know
make
it
easier
to
read
some
missing
references.
G
The
biggest
one
were
clarify
the
implicit
trust
model
that
basically,
you
need
to
trust
your
server
with
the
trust,
anchors
and
doing
the
right
thing
and
not
not
returning
bogus
information
to
you
and
then
roman
also
suggested
some
extra
checks
for
the
security
considerations.
G
It's
basically
stating
why
certain
things
are
not
a
problem,
but
instead
of
just
assuming
people
will
figure
it
out,
just
sort
of
spell
it
out.
So
that
was
good.
There
were
also
some
changes
related
to
s.
Mind
status,
attribute
extensibility
main
issues
around
there.
I
I
will
actually
have
a
slide
on
this,
but
the
document
allows
for
sign
messages,
but
it's
also
kind
of
explicitly
allows
for
sign
and
encrypted
without,
but
that
is
supposed
to
be
an
extension
to
this.
G
That's
why
the
complexity
here,
yeah
and
then
there
was
also
requests
to
extend
email
query
to
actually
be
able
to
search
for
all
this
mime
send
messages
all
these
names
and
messages
with
valid
signature.
This
sort
of
thing
next
slide.
G
So
I
will
just
go
through
various
issues
that
sometimes
I
have
an
opinion,
but
I
thought
it
would
be
really
good
good
idea
to
check
with
the
working
group
several
people
asked
about
why
specifically
10
minutes,
caching
time.
To
be
honest,
I
sort
of
picked
it
from
the
air.
G
I
thought
you
know
I
didn't
want
it
like
to
be
30
seconds.
The
reason
for
this
is
because
serial
retrieval
and
certificate
verification
and
signature
calculation,
it
is
kind
of
cpu,
intensive
and
possibly
network
intensive.
So
we
want
to
protect
from
the
denial
of
service
attacks
certificates,
don't
expire
very
often.
G
So
if
there
were
no
crl
in
existence,
then
probably
checking
once
a
day
would
have
been
okay,
but
if
we
actually
want
to
allow,
I
don't
know.
Suddenly
I
discovered
that
my
certificate
is
macro
keys.
Compromise
I
requested
revocation
and
how
quickly
do
you
want
the
service
to
figure
out
that
the
certificate
was
revoked?
G
So
I'm
thinking
10
minutes,
it's
probably
on
the
low
side,
maybe
maybe
change
it
to
one
day
or
something
like
that,
but
I
sort
of
really
don't
have
an
idea.
Any
suggestions.
D
C
I
I
guess
one
one
comment
I
have
on
on
the
revocation
time
is,
I
mean
verification
doesn't
actually
have.
I
mean,
doesn't
happen
all
that
often
I
mean
when
it's
revoked
you.
You
perhaps
want
to
pay
attention
to
it
fairly
quickly,
but
a
day
certainly
seems
reasonable.
I
mean
if
you,
if
you
are
checking
crls,
you
I
mean
checking
a
crl.
Every
10
minutes
is
a
lot.
So
I
think
a
day
is
is
a
is
a
good
ballpark.
G
Okay
yeah,
I
was
just
I
was
thinking
about
like
star
certificates,
very
short
certificate.
They
don't
have
relocation
time.
They
just
have
very
quick,
revocation
time,
a
very
quick
expiration
time
and
I
was
wondering
what
they're
doing
there.
What's
the
granularity
just
for
comparison,
but
yeah
tend
to
think
that
one
day
is
probably
good
enough.
G
Basically,
I
had
weasel
words
in
the
document
saying.
Well,
you
can
add
extensions,
and
various
people
started
asking
me
what
exactly
it
means
and
how
does
it
affect
calculation?
Certain
properties
like
there
is
one
property
that
depends
on
all
messages
of
the
valid
signatures.
So
if,
if
a
new
value
is
added,
which
is
sort
of
similar
to
signed
verified
like
what
I
had
in
mind
was
encrypted
plus
sign
verified,
then
it
should
be
treated
similar,
so
two
options
here.
G
B
I
have
an
opinion
of
sorts,
which
is
basically
that
jmap
is
designed
to
have.
You
have
to
opt
into
capabilities
to
get
additional
things,
so
I
don't
think
you
need
either
an
extension
or
adding
known
values,
because
a
new
extension
would,
by
opting
into
using
it,
would
automatically
make
those
values
become
available
and
that
extension
would
also
define
them.
E
G
B
D
G
G
D
I
was
just
saying:
can
you
speak
up
you
a
bit?
Oh
sorry,
I
was
just
agreeing
with
braun.
I
I
think
yeah,
because
you
have
to
opt
into
the
capability.
That's
the
extension
point
and
so
yeah
no
need
to
create
a
actual
registry.
Here.
A
I
think
I
agree
just
to
play
devil's
advocate
the
ex.
The
an
iona
registry
might
be
useful
as
an
index
to
these
if
more
of
them
were
to
appear,
but
if
you're
it
also
allows
for
creation
of
an
s
mime
status,
value
that
maybe
doesn't
refer
to
an
rfc.
Maybe
it's
defined
as
someplace
else.
If
you
think
those
things
are
unlikely,
then
I
don't
think
it's
really
necessary.
D
Of
gmat
extensions,
so
you'll
be
able
to
kind
of
find
it
kind
of
via
that,
I
guess
for
the
capabilities.
B
Yeah,
I
would,
I
would
probably
recommend
that
if
another
extension
comes
along,
that
extends
it
that
could
create
the
registry
as
well
at
that
point,
but
it
saves
us
having
an
iona
registry
with
two
values
in
it
that
never
gets
updated,
which
is
kind
of
the
alternative.
There.
G
All
right,
so
I
think
I
know
what
needs
to
be
done.
It's
more
like
option
two.
G
So
in
email
get,
there
is
a
attribute
that
says,
give
me
as
mime
status
at
the
time
of
delivery.
Do
we
want
to
be
able
to
do
something
similar
in
email
query
we
have
so.
The
document
has
has
verified
this
mime
or
has
a
smile
or
something
like
that
for
smile
messages
that
have
valid
smile
signature
at
the
time
of
request.
B
B
Cool,
I
think
neil
was
probably
going
to
say
the
same
thing
I
was,
which
is
yeah.
You
might
as
well
define
it.
The
server
can
always
say,
cannot
do
it
if
you
try
and
query
it
and
it
can't,
but.
D
G
B
D
H
D
G
Yeah
this
is
another
thing.
Basically,
another
optimization
in
the
document
is
that
a
lot
of
clients
what
they
do?
They
just
want
initially
to
just
play
a
list
of
messages,
and
they
want
to
display
an
icon
saying
that
this
message
is,
like
I
don't
know,
as
mime
signed
or
bgp
signed,
and
then,
when
you
click
on
the
message,
then
they
will
tell
you
whether
signature
is
valid
or
not
so
signed.
Attribute
value
allows.
G
Basically,
the
question
was
asked:
can
the
server
ever
return
sign
just
sign,
as
opposed
to
signed,
failed
or
signed
verified.
G
The
way
I
implemented
it
is
a
bit
of
cheating
in
a
sense
of
actually
as
mime
status,
so
a
delivery
doesn't
need
to
be
calculated
at
delivery
it
just
when
you
ask
for
it.
It
will
calculate
the
status,
as
you
know,
as
was
valid
at
delivery
and
just
cache
it
from
that
point.
So
it's
actually
despite
the
name,
it
doesn't
have
to
be
done
at
delivery
time.
G
So
proposal
is
keep
signed
because
it's
still
useful,
optimization
and
clarify
what
this
mime
status
of
delivery
means
how
it
can
be.
You
know
if
it's
easy
to
calculate
a
delivery
it
can
be,
but
it
doesn't
have
to
be.
C
G
That
that
will
be
done
when
specif
asmr
status
is
explicitly
requested
for
the
message
and
then
it
will
be
signed,
verified
or
signed
failed
if
it's
misaligned
right,
but.
G
Only
actually,
I
should
have
double
checked,
I'm
pretty
sure
that
s
mime
status
said
delivery
is
marked
as
server
set,
and
I
just
checked
yesterday
that
it's
not
the
same
as
immutable,
so
server
can
change
the
status
if
an
anchor
got
added,
and
now
it
became
valid,
basically
yep.
So
I
think
that's
right,
just
clarify
that
that
this
might
happen.
C
B
I
I'm
just
looking
at
this
and
looking
at
the
name
and
thinking.
Maybe
what
we
want
is
s.
Mime
was
once
valid,
which
covers
delivery,
which
covers
you
change
the
trust
anchors
and
it
became
valid
a
your
case
saying
in
the
past.
The
s
mime
status
of
this
was
validated
and
good,
and
you
can
also
clear
that
if
there's
a
certificate
revocation
but
otherwise,
you
keep
it
because
it
was
good.
It
was
good
for
any
other.
D
B
B
C
Well,
there's
also
the
converse
case:
isn't
there
where
the
you
know
a
new
trust
anchor
gets
added
af.
Maybe
after
the
message
was
delivered
and
it
looks
invalid
and
but
actually
is.
C
It
was
valid
at
some
point,
then
you
know.
Perhaps
it
still
means
that
the
the
server
status
needs
to
be
updated
after
the
after
the
initial
delivery-
and
I
I
guess
my
question
is
whether
whether
we're
explicitly
requiring
the
server
to
go
through
and
make
sure
that
all
of
those
things
are
valid.
I
can
imagine
for
a
a
large
email
service
that
you
know
if,
if
a
trust
anchor
was
added
or
removed,
there
might
be
significant
overhead
and
trying
to
make
sure
that
all
of
the
client
mailboxes
had
all
their
messages
checked.
B
Yet
you
would
need
to
key
the
messages
in
some
way
being
able
to
search
them
by
which
which
signature
was
on
the
messages
right.
G
B
Yeah,
as
a
user,
if
I
had
this
feature
on
my
server,
what
I
would
be
wanting
to
see
is:
should
I
trust
this
message.
Like
that's,
that's
the
signal
I
want
yeah
and
that
that
is
true
in
the
case
where
the
message
arrived
and
was
signed
by
a
key
that
was
valid
at
the
time
and
was
validated
by
the
server
as
being
valid
for
that
signature,
even
after
that
that
time
now
expires.
B
E
C
B
B
F
I
Well,
but
the
the
point
is
that
revocation
says
I
know
this
was
compromised,
you
might
you
you
don't
want
to
trust
things
that
were
signed
before
the
revocation
where
expired
says
that
it
was
good
until
it
expired
and
anything
that
was
valid
before
the
expiration
needs
to
continue
to
be
valid.
So
that's
the
difference
in
the
semantics.
I
Does
it
can,
can
it
be
predated
so,
but.
C
As
a
crl,
typically
go
ahead,
very
good,
a
crl
typically
doesn't
have
entries
for
certificates
that
have
already
expired.
I
mean
part
of
the
reason
for
expiration
is
to
constrain
the
sizes
of
the
crls,
get
to
be.
B
So
what's
the
risk
case
here
that
do
you
discover
later
that
the
certificate
was
compromised,
but
it
has
already
also
expired,
so
people
may
have
received
messages
from
it
before
the
expiry
date
that
they
should
no
longer
trust
that
the
question
is:
do
we
need
to
handle
that
case
and
if
so,
how
do
we
handle
it?
But
otherwise
you
don't
want
the
message
itself
to
just
disappear
when
the
key
expires,
which
it.
C
I
Right,
if
you
validate
a
message
today
with
a
valid
certificate
and
a
year
from
now
that
certificate
expires,
the
message
is
still
considered
to
have
been
validated
and
any
user
experience
that
doesn't
include.
That
is
going
to
be
terrible.
D
We
have
first-hand
experience
of
this
because
apple
profiles,
which
is
how
you
can
easily
install
mail
contacts
et
cetera
settings,
do
exactly
this
after
our
certificate
certificates
valid
at
the
time
of
installation
later
pointed
expires.
D
We
renew
it
and
now,
if
you
go
to
your
settings,
it
says
that
the
profile
is
marked
as
scary
red
warning
thing,
even
though
it
works
fine,
but
then
the
users
ask
us:
what's
what's
going
on
and
yeah
it's
so
silly,
it
was
valid
when
they
installed
it
and
then
suddenly
you
decided
later
that
now
it's
expired,
you're
going
to
show
a
warning
on
it.
D
Alexi,
I
just
have
another
question
on
this:
actually:
okay,
not
because
because
it's
not
immutable,
does
that
mean
if
it
changes
or
could
have
changed,
the
email
will
show
up
in
email
changes.
J
B
Yeah,
the
semantics
and
description
need
to
match,
but
what
I
want
from
this
is
to
say
this
was
considered
trustworthy
at
the
time
it
was
inserted
into
the
mailbox.
It
was
validated
by
the
server
it
hasn't.
The
key
hasn't
been.
The
certificate
hasn't
been
revoked
since.
D
B
D
B
Yeah
all
right
I'll,
put
myself
in
action
to
think
about
that
name
and
see
if
we
can
come
up
with
anything
clearer
to
propose.
G
G
G
I
will
try
to
add
references
well,
they
already
mentioned
earlier
in
the
document,
but
I'll
try
to
clean
this
up,
to
make
it
more
explicit,
saying
that
these
are
important
examples
of
things
that
need
to
be
checked.
G
And
yes
answering
my
own
question,
I
I
think
I
do
try
to
fix
some
minor
deficiencies
in
prior
rfcs,
but
I
kind
of
don't
want
to
propagate
them
to
new
implementations.
G
So
yeah
this
was
actually
quite
curious,
very
good
comments
from
isg,
but
none
of
them
are
blocking
so
in
theory.
I
could
have
just
ignored
them
all,
but
I
think
it
was
a
good
discussion
to
actually
they
made
me
think-
and
I
think
it
was
a
good
discussion
today,
so
I'll
I'll
post,
a
new
new
draft
I'll
ask
people
to
double
check
on
the
maining
list
and
and
then
we'll
hopefully
get
this
approved.
G
Right
shall
we
move
on
to
the
of
this
mime
draft
now.
K
B
I
G
Previous
draft
was
about
signature,
verification
on
received
mail,
and
this
one
is
how
to
generate
sign
and
only
encrypted
messages
when
sending
fairly
simple,
really
email
set,
has
two
extra
attributes,
both
optional
and
both
by
default
false.
So
if
they're
not
specified,
then,
basically,
if
the
gj
map
behaves
just
as
without
this.
G
G
That
looked
very
awkward,
so
I
just
noticed
it
a
few
days
ago.
So
I
yesterday,
I
think
I
posted
the
new
version
to
restore
the
text,
so
otherwise
there
was
no
changes
from
zero
one
to
zero
zero.
So
open
issues.
G
B
I
have
a
suggestion
yep
these,
these
sound,
like
they're,
the
kind
of
things
that
you
want
to
set
on
on
an
identity
rather
than
on
individual
emails.
So
you
would
set.
G
B
Presumably,
that's
where
you
would
set
key
names
or
or
key
data
as
well.
G
D
G
Yeah,
I
would
rather
not
put
put
the
key
material
itself,
it
just
say
that's
out
of
band
whatever
you
know,
however,
you
manage
it
for
your
system
like
for
us,
is
going
to
be
like
pkcs12
stored
in
ldap,
for
example,
which
is
as
much
as
I
like
our
implementation.
I
don't
think
everybody
will
implement
it
like
this.
D
I
just
wanted
to
ask
with
the
creating
the
structure
if
the
idea
you
would
create
the
body
structure,
as
you
normally
would
with
jmap
and
then
wrap
that
whole
thing
in
a
new
kind
of
mime
like
the
multi-part
signed
or
yeah
yeah,
okay,
cool.
G
So
I
actually
to
be
honest.
I
struggled
here
a
little
bit
because
what
my
implementation
does,
it's,
actually
it
creates
message
on
send,
but
I
thought
it
would
be
slightly
better
to
create
a
message
and
then
just
like
keep
the
send
sort
of
simple,
but
I'm
open
to
suggestions.
C
G
D
Yeah
I'll
read
through
that
and
see
if
anything
jumps
out.
G
Right
so,
okay
suggestion
so
far
is
multi-part
sign
versus
application,
because
seven
of
mine
have
a
boolean
in
identity.
I
assume
header
protection
is
similar
thing
and
the
identity
possibly
be
able
to
list
keys
without
managing
key
material
itself
in
the
identity,
object.
G
Is
an
open
issue
is
whether
automatic
smile
decryption
is
something
we're
going
to
have
there
here
as
well.
G
G
G
Nest
specification:
I
forgot
what
what
the
specification
was.
It
suggested
that
you
automatically
decrypt
and
store
decrypted
version
and
secure
store
so
that
you
avoid
the
issue
of
the
expiration.
All
of
this.
D
D
G
There
are
lots
of
things
that
can
be
if
it's
a
single,
simple
structure
like
if
it's
application,
pkcs7
mime
with
just
encryption
or
signature
and
encryption,
then
you
can
sort
of
do
that
automatically.
If
it's,
if
you
have
a
bunch
of
encrypted
attachments
in
a
message,
then
it
becomes
more
interesting.
G
I'm
happy
to
leave
this
be,
and
just
people
can
think
about
this,
because
obviously
it
does
have
quite
a
bit
of
complexity.
B
B
G
Can
you
can
we
minute
this,
or
can
you
send
me
an
email
yeah
both?
Oh
definitely
thank
you.
G
G
I
mean
in
certain
way
this
documented
is
other
than
decryption
it's
kind
of
much
easier,
because
there
aren't
that
many
attributes
on
the
sending
side.
But
there
is
quite
a
bit
of
complexity
implementing
it,
obviously,
where
the
s9
signature,
verification,
sort
of
the
reverse.
B
Cool
I
assumed
that
these
would
go
a
lot
faster
than
they
did,
which
is
probably
because
I
didn't
read
through
the
slides
and
work
things
out,
so
we're
well
behind
on
the
agenda.
But
luckily
we
have
heaps
of
extra
time,
but
I
guess
we're
up
to
germap
calendars,
which
is
not
going
to
take
the
20
minutes
that
it
that
we
would
expect
that
isn't
to
nothing.
Much
for
this
one.
D
I
don't
think
there's
actually
much
to
say
like
especially
as
we
talked
about
this
at
the
interim
meeting
a
few
weeks
ago
and
honestly,
it's
not
a
lot
of
time
for
much
to
happen.
We're
still
trying
to
get
some
implementation
experience.
I'd
hope
to
have
that
by
this
meeting,
but
various
things
got
in
the
way,
but
we
are
so
close
to
rolling
it
out
in
quite
a
few
places.
D
So
definitely
by
the
next
meeting
we
will
I've
got
a
small
list
of
to
do's
to
the
spec,
based
on
our
previous
meetings
and
I'm
being
a
bit
lacks
and
updating
that
so
apologies
I'll
also
get
to
that
yeah.
I
don't
think
there's
much
to
say
today,
though,
unless
someone
wants
to
talk
about
it,
I
suggest
we
move
on
to
the
tasks.
L
N
Yeah
quicker
than
expected:
okay
yeah,
so
today,
haryo-
and
I
are
gonna
talk
about
jimmy
for
tasks.
So
there
is
one
minor
change
that
I
did
since
the
last
intro
meeting
perfect.
N
I
I
essentially,
I
I
made
assignee
part
of
a
js
kind
of
participant
role
property.
So
so
it's
a
new
value
that
it
can
be
instead
of
having
it
as
an
extra
object.
That,
basically,
is,
was
the
renaming
of
the
the
thing
that
is
in
js
calendar
in
jmf
calendar,
and
we
also
have
published
the
survey
of
various
task
systems,
and
this
is
where
I
give
over
to
how
you
to
give
an
introduction
to
it.
M
All
right
thanks,
yeah,
just
to
to
give
some
more
context,
I
think,
with
jammer
for
tasks.
M
We
are,
you
know
in
an
earlier
stage
than
we
are
miss
with
a
lot
of
other
jmet
stuff,
which
I
think
started
much
earlier,
and
our
observation-
which
I
think
we
in
part
already
discussed
in
the
previous
meeting,
is
a
little
bit
that,
unlike
email,
contact
and
calendaring
functionality,
there
seems
to
be
more
differences
in
tools,
supporting
tasks
and
that
led
us
basically
to
survey
also
different
tools
and
to
look
a
little
bit
into
them
in
terms
of
how
to
design
the
jammer
for
tasks
specification.
M
There
is
one
major
question
which
comes
out
from
time
to
time
and
is
also
touched
a
little
bit
by
the
recent
discussion
on
jaime
fosseef
on
the
mailing
list,
and
this
is
a
little
bit
the
discussion
about
you
know
what
is
what
is
the
intention
or
goal
of
jmf
in
a
certain
sense
so
and
in
in
how
far
is
it
really
desired?
M
N
N
So
the
the
initial
scope
of
the
survey
was
that
we,
we
chose
three
different
kind
of
systems
group
s
systems
like
ox,
for
example,
kanban
style
systems
like
trello
as
well
as
issue
tracking
systems
like
mantis.
N
Okay,
you
can
go
to
the
next
slide,
so
the
first
results
can
be
found
at
the
github
feel
free
to
leave
comments
there.
If
you
want,
you
can
also
could
also
upload
new
revisions
in
case
that
makes
sense
if
there
are
some
some,
if
there's
some
important
feedback.
N
So
the
most
of
the
most
important
observations
of
that
survey
are
that
task
systems
are
heterogeneous
regarding
some
features,
so
I
didn't
find
of
this
of
the
system
surveyed.
I
didn't
found
this
find
a
system
that
had
implemented
all
features
of
jmf
for
tasks,
and
so
the
result
of
that
is
that
probably
developers
that
look
at
the
jmf
for
tasks
back
will
not
want
to
implement
the
whole
thing.
Basically,
and
especially
some
more
complex
features.
N
Is
something
that
that
some
developers
might
want
to
skip
and
it
might
make
sense
to
to
identify
some
that
might
be
optional
or
separate
from
the
core
features,
but
yeah
core
features
is
a
good
point
there.
This
is,
it
also
has
become
obvious
that
task
systems
are
homogeneous
regarding
most
core
features.
N
Yeah,
that's
basically
the
main
point
here
I
can.
I
think
you
can
go
to
the
next
slide
again
yeah,
so
here
to
spark
some
discussion.
Maybe
we
listed
a
bunch
of
properties
or
features
that
are
currently
within
jmap
for
tasks
but
are
not
supported
by
all
systems.
N
That
I
surveyed,
for
example,
alerts
and
sne
attachments
recurrence
or
relation
especially
recurrence
is,
for
example,
a
quite
a
complex
thing
to
implement,
and
if
you
don't
need
it
at
all
for
your
application,
it
it
it
might
make
the
the
spec
a
bit
easier
to
read.
Maybe
I
don't
know
it's
it's
it's
a
point
for
discussion.
The
suggestion
here
is
to
to
come
up
with
a
way
to
group
them
somehow
and
have
a
make
them
like
an
optional,
separate
capability.
Maybe
some
kind
of
an
optional
feature,
maybe
okay
and
yeah.
N
So
they're
also
there.
I
also
identified
some
features
that
are
not
yet
present
in
gmap
for
tasks,
but
I
found,
but
some
systems
are
using
them.
There
are
some
kind
of
complex
properties
like
a
checklist
which
we
already
shortly
talked
about
in
previous
meetings,
also
a
comment
list
or
a
discussion
that
is
attached
to
a
task.
N
Which
quite
a
lot
of
systems
used?
Also
quite
a
lot
of
systems
used
history,
where
you
could
look
at
old
revisions
of
a
certain
task
and
there
were
some
additional
simple
key
value
style
properties
observed.
So
the
suggestion
here
is
maybe
to
to
extend
gemma
for
tasks
somehow,
with
those
features
to
support
most
systems
observed,
maybe
yeah.
N
I
think
we
can
go
to
the
next
slide
again
and
probably
discuss
afterwards.
So
the
next
step
here
in
general
for
the
survey
are,
we
would
continue
this
survey
a
bit
further
and
refine
it
get
the
feedback
work
it
in.
N
M
M
But
sounds
good.
D
Yeah
I've,
if
I
can
make
a
suggestion,
so
one
idea
here
for
path
forward
is,
is
so
the
the
extra
the
data
format
is
actually
kind
of
js
calendar.
It's
the
task
object
within
that
right
and
then
jmap
tasks
is
kind
of
the
having
a
server
to
support.
That
and
being
able
to.
You
know,
store
it
and
communicate
in
a
few
ways.
D
So
the
data
format
is
easily
extensible,
because
there's
registry
for
everything
you
can
register
extra
stuff.
So
I
wouldn't
worry
about
all
the
little
like
key
value
stuff.
Where
there's
one
you
know
app,
that's
using
it
like
they
can
always
just
register
a
new
property
in
with
ayanna.
It's
pretty
straightforward.
If,
if
us
trying
to
do
everything,
it's
not
worth
it
there's
common
stuff,
then
we
should
try
and
register
those.
D
D
And
then
the
final
thing
I
was
gonna
say
is:
is
the
server
could
we
could
have
a
set
of
common
functionality
that
we
know
is
highly
common
that
must
be
supported
by
any
server
if
it
wants
to
support
gmap
tasks
just
because
otherwise
it's
impossible
for
a
client,
but
then
it
server
could
advertise
and
hear
all
the
other
property
names
that
I
support
and
in
the
capabilities,
so
you
can
just
check.
Does
it
support
the
recurrence
tools?
Property?
If
it
does
I'll
show
my
recurrence
rules
ui?
D
If
not,
I
won't
because
I
know
the
server
doesn't
support
it.
So
that's
my
suggestion
for
them
making
it
adaptable
because,
as
you
say,
yeah
there's
a
lot
more
differences
here.
M
Michael
is
next,
I
think
okay,
maybe
as
a
shortcoming
before
mike,
speaks
because
it's
just
related
to
one
comment.
I
think
he
made
earlier
so
I
think
neil
mentioned
the
history
thing,
so
it
was
actually
put
in
brackets,
because
I
think
I
remember
mike
you
mentioned
it
in
a
previous
car
connect
meeting
as
a
generic
thing.
You
were
thinking
about
or
even
having
implemented
somewhere
in
either
I
calendar
or
somewhere
right.
Do
you
remember
yeah.
L
Well,
that
was
gonna,
be
my
point
is
I
I
don't
see
anything
that
you've
said.
You
know
suggested
that
isn't
applicable
to
you
know,
regular
events,
because
we've
had
the
same
kind
of
you
know
idea.
We
want
some
sort
of
auditing
for
for
events
and
how
that
what
happened
to
them.
L
I
think
all
of
these
are
features
that
could
be.
I
mean
recurrences.
Support
recurrences
is
even
sketchy
in
a
lot
of
event
tools,
so
it
I
don't
think,
there's
any
difference
there.
We
really
only
want
one
form
of
recurrence,
support
and
those
things
get
really
confusing,
so
you
either
support
it
or
you
don't
yeah.
I
I
just
don't
I
don't
I
don't.
I
think
we
want
to
try
it.
I
don't
think
we
want
to
try
and
have
much
in
the
way
of
different
support
between
one
or
the
other.
M
M
L
B
K
So
just
for
about
the
history
topic
again,
so
that
was
me
who
at
last
itf
was
discussing
this
in
context
of
js
contact
and,
I
think
to
remember.
I
promised
to
write
up
a
draft
for
that.
But
I
didn't
do
it
yet
so,
but
these
topics
seem
to
converge
on
the
various
data
types
so
that
might
that
might
be
a
booster
for
my
ambitions
on
coming
up
with
a
document
so
I'll
I'll
do
that.
M
So
so
certainly
yeah
like
an
audit
trail,
is
somehow
right
and
my
remark
is
basically
in
the
direction.
It's
certainly.
I
think
it's
an
interesting
thing.
M
I
think
not
so
many
systems
expose
it
currently
via
api
or
something
because
they
consider
that
rather,
as
some
you
know,
system
generated
and
displayed
thing,
not
something
you
can
influence
or
read
out
with
the
tool
even,
but
that
I
think,
even
makes
it
interesting
because
it
shows
up,
as
you
said,
that,
since
a
lot
of
tools
are
using
these
kind
of
concepts
that
this
is
my
might
be
something
that
needs
or
can
can
have
some
attention.
K
K
Yeah,
I
got
it
all
so
in
terms
of
expectations.
So
what
I'm?
What
we
discussed
in
terms
of
js
contact
was
to
have
a
and
not
only
being
defined
only
for
gs
contact,
but
rather
a
generic
history
that
that
that
tells
the
values
of
of
a
property
at
various
points
in
time.
So
I'm
not
sure
now,
if
that
is
in
line
with
what
you
were,
what
you
mean
when
you
were
talking
about
history
in
in
context
of
tasks,
but.
K
Hello
again
yeah,
so
that
next
slide,
that
slide
is
basically
the
unchanged
version
of
what
we
discussed
at
the
interim
meeting
a
month
ago.
So
I
think
almost
everybody
here
was
also
there.
So,
basically,
the
main
point
to
take
away
from
that
light
is
we
are.
K
We
are
waiting
for
our
implementations
or
other
implementations
to
get
to
get
better
hands-on
experience
with
with
the
data
format.
K
Has
implemented
the
most
of
the
data
format
we
at
fast
mail
are
are
working
with
with
an
old
version
of
context
data,
and
I
hear
that
also
the
rdap
working
group
at
itf
are
working
on
implementations
there,
although
I
haven't
yet.
I
have
no
further
details
on
on
which
aspects
they're
covering
mario,
probably
you
want
to
have
a
word
on
this.
K
O
No,
I
just
to
make
an
additional
note.
I
was
informing
last
rejects
the
interim
meeting
that
there
are
some
just
contact
implementation
inside
rdap,
so,
as
robert
has
just
said,
the
this
content
in
our
that
doesn't
cover
all
the
information
that
could
be
represented
by
just
contact
only
subset,
even
if
this
subset.
I
think
that
this
this
implementation
could
be.
O
O
Obviously,
the
guest
contact
representation
is
more
satisfactory
in
in
the
adapt
context.
So
I
I
don't.
I
don't
feel.
I
don't
believe
that
we
will
have
relevant
feedback
real
one
feedback
to
to
change
the
current.
Yes
contact
us
batch.
K
K
The
the
issue
is
open
for
comments
until
the
end
of
this
year
and
while
reading
it
so
basically
it
it's
concerned
with
the
formatting
and
sorting
of
names
and
and
uses
patterns,
mainly
that
define
how
to
format
several
name
components
depending
on
the
context,
for
example,
context
would
be
if
you
are
addressing
a
person
or
if
you
are
referring
to
a
person
which,
given
as
an
example
in
russian
these
the
order
of
name
components
is
used
differently
then,
and
it's
also
covering
several
other
aspects.
K
But
the
main
the
main
point
for
js
contact
is
that
it's
also
that
it's
using
name
fields
which
basically
are
very
much
aligned
with
what
we
are
calling
name
components
in
js
contact.
So,
that's
kind
of
so
that
that's
good
news
that
we
that
we
at
least
seem
to
think
in
the
same
direction
as
other
groups
working
on
the
same
topic.
K
So
the
in
terms
of
impact
on
the
js
contact
implementation.
We
would
like
to
be
sure
to
be
alive
to
align
our
name
components,
type
with
that
unicode
effort,
but
at
the
same
stage,
keep
deformating
and
sorting
aspects
out
of
scope.
So
that's
basically
something
where
an
application
then
could
use
the
unicode
library
or
or
or
or
implement
their
own,
based
on
their
definitions
on
how
to
format
names
in
various
contexts.
K
And
that
means
in
practice
on
the
next
slide.
Please
that
we
are
just
renaming
two
fields
or
the
personal
name
we
suggest
to
rename
to
given
and
the
additional
name.
We
want
to
rename
to
middle
one
thing
that
we
haven't
covered
so
the
unicode
document
discerns
between
a
surname
and
a
secondary
surname.
K
The
first
intuition
was
that
the
order
of
a
certain
in
in
js
contact
would
just
could
just
be
deferred
from
its
position
in
the
array
of
name
components.
However,
that's
that,
in
my
opinion,
is
not
good
enough.
First,
we
cannot
trust
the
fields
to
name
components
to
be
in
any
meaningful
order.
K
K
What
is
the
secondary
surname
in
that
context,
so
we
suggest
what
I
wrote
is
this
these
slides,
I
was
thinking
of
having
a
surname
followed
by
a
digit
where
digit
is,
and
at
least
two
or
higher,
but
the
more
I
think
of
it
we
might
even
want
to
since
the
name
component
already
is
a
complex
object.
K
We
might
just
want
to
add
an
additional
optional
property
nth,
which
then
can
be
an
unsigned,
integer
and
and
and
then
we
could
basically
use
the
same
order
thing
for
all
different
for
all
kinds
of
name
components,
even
if
that
would
cover
more
than
or
allow
more
than
the
unicode
document
is
aiming
at
any
any
opinions
or
remarks
or
other
input
on
this
one.
N
Is
it
am
I,
on,
I,
don't
see
a
big
difference
between
having
an
array
and
just
stating
in
the
text
that
the
order
should
be
the
order
of
the
surname
in
the
array
or
having
a
separate
property
for
each
surname,
like
with
the
and
with
the
number
in
the
end.
In
the
end,
it's
the
same
thing
and
the
the
array
thing
in
my
opinion
is:
is
a
bit
more
elegant,
a
bit
shorter,
at
least
the.
B
Problem
is,
they
may
appear
in
different
orders
in
the
way
that
the
name
is
displayed
than
the
the
meaning.
So
there
are
languages
where,
where
that
does,
they
could
be
either
way
around,
but
still
be
the
primary
surname
and
secondary
surname.
N
K
I'm
not
sure,
maybe
just
to
clarify
what
do
you
mean
when
you
speak
of
an
array,
so
at
the
moment
the
sorry
at
the
moment,
the
name
is,
is
an
array
of
name
components
and
these
name
components
have
a
type
which
is
one
of
these
in
the
column
that
you
are
seeing.
N
K
N
N
B
My
only
question
is
whether
it's
possible
to
give
feedback
to
unicode
and
say
hey.
This
is
what
we're
doing
with
this.
Do
we
have
any
any
communication
with
the
group
that's
working
on
this.
K
No
not
yet,
but
yes,
I
was
thinking
of
contacting
them.
I
just
read
document
yesterday
actually
so,
but
we
should
do
that.
Yeah.
J
K
H
K
K
We
haven't
come
up
with
solution,
yet
I
remember
that
we
were
thinking
of
looking
at
where
to
ask
at
itf
if
there
is
a
like
a
recommendation
by
itf
across
working
groups,
for
how
to
deal
with
that.
K
The
main
expectation,
the
main
use
case,
as
I
understood,
is
mainly
to
to
understand
in
languages
that
have
different
pronouns
or
addressing
like
a
mr
or
mrs,
how
to
address
that
person
or
that
contact
depending
on
their
on
their
gender.
K
K
Where
the
gender
plays
a
role,
that
being
said,
the
v
card,
the
v
property,
already
defines
discerns
between
gender
and
also
has
the
optional
field
for
sexual
identity.
K
I
think
it
is
so
the
main
gist
still
is,
which
also-
which
I
also
stated
at
the
last
meeting-
is
both
mario
and
I
do
not
feel
confident
in
that
field
to
really
come
up
with
a
standard
for
this.
So
we
might
need
to
talk
more
with
people
who
are
working
on
this
topic
more
extensively,
and
we
don't
really
know
we
haven't
really
figured
out
it.
How
to
do
that.
Basically,.
B
K
That
being
said,
also,
the
the
unicode
document
also
has.
This
is
an
open
issue,
so
we
will
talk
with
them,
also,
what's
their
what's
their
opinion,
although
they
they
only
need
to
narrow
it
down
to
cases
where
the
formating
of
the
name
depends
of
the
gender
of
that
person.
B
Pete
mentioned
in
the
chat
that
the
ihf
does
have
a
formal
liaison
manager
with
unicode
and
gave
the
name
as
well,
so
we
have
somebody
to
to
contact
about
that,
so
it
might
be
worth
mentioning
both
these
issues
in
that
discussion.
K
Yeah
the
implementation
implementation
experience.
I
think
that
would
be
good
to
to
go
into
la
before
going
into
last
call
to
to
to
have
a
good
understanding
that
we
are
covering
everything
we
want
to
cover.
B
C
Okay,
then
so
the
next.
The
next
topic
is
from
alexi
again,
let
me
find
the.
G
So
yeah
very
quickly
there
is
no
extra
working
group
meeting
today
or
this
week,
but
there
are
some
people
who
are
active
in
both
gm
and
extra,
so
ask
for
extra
time
to
introduce
this.
So
yes,
what's
a
problem
statement.
G
How
how
do
you,
how
server
implementations
deal
with
very
big
mailboxes
and
what
is
a
good
client-side
behavior
to
help
servers,
handle
this
and
not
overload
them
when
I
say
big
mailbox,
what
do
I
mean
it's
at
least
50
000
messages.
G
On
the
server
side,
it
can
be
quite
memory
and
resource
usage
intensive.
Some
servers
struggle
with
keeping
message
number
to
uid
map,
depending
on
exactly
what
back-end
they're
using.
G
And
clients,
some
clients
just
cannot
handle
this.
You
know
there
are
clients
that
are
limited
to
their
they're
happy
to
open
any
mailbox,
but
they
only
show
the
last
10
000
messages
so
yet,
at
the
same
time
they
still
fetching
flag,
flag
changes
or
just
general
flags
for
all
messages,
even
though
they
are
going
to
ignore
most
of
them.
So
some
of
this
was
already
tackled
so
constant
quickly.
Sync
extensions
are
definitely
helping
if
clients
were
to
use
them,
but
this
a
bit
more
can
be
done
next
slide.
Please.
G
So
the
proposal
is
extend,
search
and
fetch
by
specifying
that
only
so
many
messages
I
expected
in
the
result
so
for
search.
This
is
actually.
G
Using
the
partial
search
result
option,
however,
the
proposal
is
to
extend
it
a
little
bit
because
partial
can
say
well
return.
The
first
end
messages
or
you
know,
a
certain
block,
but
it
starts
from
lower
messages.
So
extension
here
is.
G
To
allow
to
to
ask
for
the
the
and
last
messages,
for
example,
so
what's
the
advantage
of
this?
This
helps
the
server
by
saying.
Well,
you
cannot.
G
You
only
need
to
search
end
messages
and
then
you
can
stop
so
server
implementations
can
optimize
what
they
do
and
also,
if
the
client
doesn't
care
about,
you
know
50
000
results,
then
it
can
say
well,
I
only
need
hundred
so
this
also
optimize
network
traffic
and
similar
extension
to
uig
fetch,
because
uid
fetch
can
specify
uid
range
where
the
client
doesn't
actually
know
how
many
messages
are
in
the
range
again
saying
you
know,
I
only
care
about
so
many
messages
next
slide.
Please.
G
So
yeah
search
extension.
G
Partial
originally
defined
in
rfc
526,
but
an
extended
syntax
to
allow
negative
ranges
for
addressing
so
many
last
messages,
as
opposed
to
so
many
first
messages.
So
this
is
an
example.
G
G
So
what
also
good
is
actually
we
do
have
a
wonderful
imap
feature
when
multiple
extensions
interact
with
each
other
in
lots
of
interesting
ways,
we
actually
never
defined
how
partial
and
safe
interact.
G
B
We're
going
to
hear
you
first
thing,
I
have
to
say
is:
don't
make
the
windows
key
on
your
keyboard,
the
screen
lock
key
when
you
accidentally
hit
it
occasionally,
because
I
just
locked
my
whole
system
up
and
then
mistyped
my
password
trying
to
log
back
in
so
I
couldn't
get
in
to
re-enable
myself.
I
was
smiling
about
the
minus
one,
because
that
is,
that
is
what
the
asterisk
or
star
operator
is
the
well
very
much
misunderstood
operator.
That
means
the
last
with
the
last
item
or
the
item
with
the
highest
uid.
B
Specifically,
this
whole
minus
one
syntax
is
yet
another
weird
thing
in
imap,
and
it's
fine,
but
it's
also
like
imap
is
so
so
syntactically
edgy
and
tricky
to
deal
with.
B
But
yeah,
I
think
it's
it's
definitely
worth
taking
it
to
extra
and
asking
for
adoption.
It
looks
implementable.
B
And
if
you
get
one
client
and
server
using
it,
then
it
could
expand
out
so
sure
I
saw
in
the
chat
that
ken
and
pete
talked
about
the
imap
x
view
extension,
which
was
published
some
long
time
ago
july.
2000
there
you
go.
E
G
G
Yeah
because
it
it
tried
to
be
like
yeah
yeah
more
like
a
mailbox
which
caused
all
kind
of
interesting
things
and
partial
also
doesn't
try
to
deal
with
updates,
which
is
quite
nasty.
G
C
So
I
guess
the
next
thing
is
to
go
through
working
group
milestones
so
ron.
That's,
I
think,
that's
your
thing.
M
This
is
about
this
thief
implicit
standard
thing
I
mentioned
in
the
last
tech
connect
into
a
meeting
and
I
think
alex
say
you
asked
me
to
send
this
to
the
extra
group.
However,
it
didn't
really
spark
in
there.
So
the
question
is
how
to
proceed
with
that.
M
G
Still
owe
your
response:
well,
it
is
difficult
in
the
sense
that
I
don't
well.
We
probably
wouldn't
want
to
modify
civ
syntax,
because
that
will
be
just
too
disruptive,
but
if
we
can
have.
G
M
No,
no,
don't
worry,
no
worries,
absolutely
fine,
maybe
also
in
the
direction
of
ken,
because
I
think
our
use
case
initially
was
stemming
from
jmap
our
implementation
of
jmapreceive
in
jmap,
even
though
we
experienced
the
same
problem
with
raw
thief
under
managed
c
so,
but
for
for
jmap.
Actually,
we
currently
also
could
do
with
it
by
ourselves
with
the
means
of
the
standard,
because
we
thought
about
also
transmitting
basically
a
product
id
via
the
capabilities.
M
So
that's
a
little
bit.
Maybe
I
don't
know
if
this
is
intended
usage
of
the
capabilities,
but
I
think
it's
not
strictly
forbidden,
and
that
would
actually
allow
us
to
do
what
we
want.
So
we
can
currently
live
with
that
and
work
around.
It's
the
same
way
we
work
around
with
it
in
the
in
the
managed
thief
case.
Maybe
that
is
an.
J
E
I
had
to
stay
muted
because
my
dog
was
barking
at
the
fedex
guy
yeah,
so
the
issue
you're,
having
is,
is
that
the
implementation
that
you're
trying
to
write
or
trying
to
use
doesn't
support
vlogs,
I'm
not
right
now.
M
Oh
no,
no,
so
the
blob
thing
is
a
different
thing,
and
that
is
that
is
also
okay.
We
can
work
with
that.
So
some
of
my
remarks
were
there
were
also
maybe
for
other
people
having
to
deal
with
the
same
issues.
So
we
just
found
that
a
little
bit
difficult,
but
we
certainly
were
able
to
do
it
yeah.
So
so.
M
The
things
that
I
think
neil
presented
makes
sense,
so
we
can
do
it
that
way.
The
only
open
issue.
Another
open
issue
was
that
issue
with
implicit
conventions,
so
so
to
make
a
particular
particular
example,
for
instance,
we've
wrote
a
jmet
for
forcive
wrapper
for
harder
groupware
and,
for
instance,
already
internally
has
names
for
the
rules
which
it
displays
in
the
ui
to
the
user,
because,
typically
you,
you
define
the
thief
rule
in
the
web.
Ui.
E
M
E
M
Yeah,
that's
that's
also
an
interesting
question.
I
think
which
I
wrote
in
the
in
the
in
the
post.
So
typically
the
kind
of
systems
we
deal
with.
When
we
deal
with
thief,
I
I
think
there
is
actually
in
the
wild.
There
is
two
major
things:
how
people
use
sieve.
One
is
people
engineering,
their
own
whole
script
and
one
is
c
scripts
basically
generated
by
systems
such
as
a
web
mailer,
and
these
thieves
scripts
tend
to
be
quite
regular,
so
they
consist
basically
of
a
set
of
individual
rules.
M
M
Certainly
that
second
case
is,
I
think,
a
valid
case,
because
you
have
safe
rules
within
systems
like
corey
yeah
and
which
are
which
are
created
by
users
and
within
that
single
script,
which
which
hordi
maintains
in
the
back
end.
There
are
the
individual
rules
which
the
user
created
in
the
ui,
like
you
know,
move
set
mail
from
braun
to
folder,
broad
and
so
on.
E
Yeah,
I'm
mentally
I'm
trying
to
figure
out
if
we
could
even
use
jmap
to
manage
a
set
of
rules
without
having
just
crazy,
crazy
things
happen,
because
if
you've
got
a
handful
of
rules,
they
probably
need
to
be
executed
in
a
particular
order
which
the
webmailer
or
the
fast
mail
ui
is
well
aware
of,
and
that
one
constructs
the
script.
That
does
it
in
the
correct
order.
M
B
So
the
interesting
question
is:
can
you
annotate
the
rules
with
something
that
allows
you
to
to
have
the
name,
so
it
displays
in
the
ui
in
the
fast
mail
ui
they
display?
I
think
it's
just
a
description
of
the
actual
content
of
the
rule.
We
don't
have
a
way
to
to
label
them
with
a
label
as
well,
but
I
could
see
what
happened.
I
know
there
is
a.
There
is
a
here.
We
have
a
thing.
You
can
name
your
rule.
There
you
go
so
the
fastener
ui
does
precisely
that.
E
F
B
F
B
B
H
B
Look,
I
can,
I
can
show
you
right
now.
Oh
sorry,
that's
blocked
senders.
I
clicked
the
wrong
thing.
I
wanted
to
see
my
custom
zip
code.
B
B
M
Okay,
so
so
I
have
basically
two
two
points
here.
So
one
point
is:
this
is
certainly
an
interoperability
issue.
If
you
think
about
you,
know
migrating
rules
from
one
system
to
the
other
and
probably
also
with
tools,
editing
scripts,
because
you
know
if
you
now,
I
don't
know
if
you
expose
manage
thief
braun
but,
for
instance,
if
a
client.
E
M
Is
basically-
and
there
is
not
just
comments-
there
is
also
a
sketch
in
the
initial
mail
there's
priority.
Sometimes
you
can
define,
or
you
know
those
special
use
kind
of
annotations
you
have
to
roots
which
may
sort
it
in
some
way
or
the
other
in
the
in
the
ui.
So
that's
point
one
and
we
don't
need
to
discuss
further
here.
I
think
that
was
the
mail
I
sent
to
the
extra
group,
and
probably
it's
better
there
than
here
in
the
gmap
working
group,
just
to
sort
things
out.
M
My
second
point
was
we
have
the
practical
problem
of
doing
the
implementation
for
gma
proceed
in
a
particular
case,
where
we
need
a
way
to
know
how
to
interpret
the
rule
coming
from
the
gem
at
backend,
so
we
so
to
know.
For
instance,
this
jmf
perceive
server
is
actually
serving
us
a
rule
coming
from
a
haudi
convention,
so
we
can
actually
apply
some
special
logic
that
are
passing
where
we
know.
M
This
is
how
hard
he
does
format
the
rule
name
or
something
like
that,
because
otherwise
we
cannot
correctly,
you
know,
transfer
it,
and
my
message
was
for
the
second
aspect.
We
found
a
workaround,
so
we
can
use
the
jmap
capabilities
in
order
to
you
know
convey
the
information.
This
is
holly
implementation,
so
we
are
basically
fine
here
which
brings
us
back
to
the
first
aspect,
which
was
actually
a
successor
of
the
second
one
in
the
initially
which
we
can
follow
up
in
extra
sorry.
I
just
wanted
to
yeah
yeah.
B
Okay,
so
it
looks
like
alexi
and
I
both
have
actions
to
reply
to
you
on
the
extra
mailing
list.
E
One
other
comment
on
the
the
blob
thing:
hans
york.
I
know
he
would
you
would
had
some
concerns
about
multiple
round
trips
to
fetch
touch
the
scripts.
I
uploaded
a
new
version
of
the
draft
yesterday
morning.
I
think,
which
shows
how
to
use
blob
get
in
addition
to
either
subscript
get
or
or
a
query
to
basically
effects.
That's
the
script
content
in
one
round
trip.
M
Okay,
awesome
I'll
have
a
look,
maybe
as
a
media
remark
here
and
and
maybe
also
to
to
neil,
especially
who
took
quite
some
some
effort
to
to
respond
to
my
email.
So
most
of
these
comments
were
also
meant
to
be
some
feedback
which
we
had
based
on
how
we
perceived
on
how
to
implement
this
yeah.
So
personally,
I
think
this
could
be
so.
M
The
gmat
perceived
thing,
I
think,
could
be
in
practice,
be
really
useful
for
many
people
using
sieve
to
finally
allow
to
expose
existing
safe
rules,
which
probably
didn't
want
to
expose
manage
thief
so
far
implemented
and-
and
my
feeling
was
that
you
know
this.
Blob
kind
of
thing
makes
it
a
little
bit
difficult
to
to.
M
You
know
understand
on
how
to
do
it,
or
you
know,
poses
some
restrictions
on
people
that
maybe
have
a
a
bunch
of
rules
on
a
local
fire
drive,
because
sometimes
they
are
just
stored
in
on
a
file
system
and-
and
I
thought
things
could
probably
be
easier
in
there,
but
I'm
totally
fine.
I
see
your
argument
that
it
also
makes
sense
to
keep
things
a
little
bit
consistent,
but
that's
just
part
of
my
larger
mission
to
also
raise
a
voice
a
little
bit
for
for
thinking
in
in
the
design
of
jmap.
M
Also
about
you
know,
people
which
don't
design
a
whole
system
from
scratch
in
a
nice
and
funky
way,
but
maybe
want
to
use
only
pieces
of
jmap
and
it
might
a
little
bit
be
be
overwhelmed
by
some
restrictions
in
there.
I
I
I
know
there
is
no
a
clean
way
out
of
this,
and
I
appreciate
the
feedback
by
neil.
I
hope
that
wasn't
too
aggressive
on
the
email
list
or
something
like
that
yeah.
I
just
wanted
to
make
that
point.
B
Yeah,
if
you
compare
it
to
the
body
parts
in
an
email,
we
allow
you
to
fetch
the
text
of
part
of
the
body
of
an
email
in
line
rather
than
giving
you
a
blob
id
and
telling
you
to
go
fetch
that
blob
id
and
partly
because
we
didn't
have
all
this
blob
infrastructure
then,
but
it
I.
I
can
see
an
argument
for
doing
the
same
thing
with
siv
to
allow
you
to
fetch
the
the
raw
text
of
it
as
part
of
the
fetch,
as
well
as
giving
you
a
blob
id.
So
that
becomes
different
things.
B
C
Sorry
I
forgot
to
call
that
before
so
braun
you're
on.
B
B
Gem
up
access
to
address
books.
When
do
we
think
we're
going
to
get
to
that
robert.
K
Not
before
we
got
gs
contact,
at
least
until
we
got
the
implementation
experience
with
js
contact
so
yeah
spring
next
year.
I
don't
know
when
next
itf
is
but
yeah.
B
I'm
going
to
say
april
2022
yeah
submit
jmap
calendars
to
isg.
B
E
Still
waiting
on
some
implementation
experience
with
the
test
method
and
I
guess
we
probably
still
need
to
revisit
the
blob
versus
inline
script.
Data
issue.
E
So
I
I
I
think
december
is
probably
not
doable
probably
early
next
year.
I
hope.
B
G
B
And
after
all
that
we
only
have
seven
minutes
left,
does
anybody
have
anything
else?
Let
me
unshare.
A
B
E
A
Be
gentle
yeah
a
little
bit
more.
I've
been
working
working
while
listening
and
yeah.
I
agree
it's
pretty
productive
thanks
thanks
for
tuning
into
your
milestones
too.
Some
groups
are
kind
of
slack
about
that.
B
Yeah
I
stood
up
in
a
working
group
chairs,
meeting
and
told
people
that
they
were
it's
reasonable
to
be
held
accountable
three
times
a
year
to
what
you
promised
to
do
so
I
figured
I'd
better
set
a
good
example
because
otherwise
I'm
a
hypocrite,
and
although
I
am
a
hypocrite,
that's
good
not
to
be
a
hypocrite.
In
this
specific
thing,.