►
From YouTube: IETF99-JMAP-20170717-1330
Description
JMAP meeting session at IETF99
2017/07/17 1330
https://datatracker.ietf.org/meeting/99/proceedings/
A
A
A
Okay
and
my
co-chair
has
just
returned
with
his
adapter
we're
about
to
see
curry
ten
door
on
the
screen.
I
think
so.
Well,
while
he's
setting
up
for
projecting
things,
I
will
welcome
everybody
to
the
J
Mapp
working
group,
which
is
in
Barcelona
the
back
part
over
there,
which
is
Athens,
is
not
going
to
be
used.
Everybody
come
up
to
Barcelona,
please,
unless
you're
just
here
to
read
your
email,
in
which
case
you
can
hang
out
in
Athens,
if
you
like,
we
appear
to
have
a
lot
of
people
remote
this
time.
A
A
So,
let's
flip
over
to
the
next
slide
here:
okay,
there's
there's
our
little
thing:
blue
sheets,
No
Aleksei,
kill
that
I'm
just
want
to
use
one
blue
sheet
and
there's
there's
a
blue
sheet.
There's
already
one
going
around,
so
we
have
a
blue
sheet
going
around
everyone.
Please
sign
it.
The
note
well
is
here-
and
you
should
note
the
note
well
well
as
I
am
well
known
to
note.
A
Basically
the
note
well
says
there
are
I
PR
things
that
you
I
PR
policies.
You
ought
to
be
aware
of.
Look
them
up
if
you
don't
understand
them.
So
today
we're
going
to
talk
about
J
map
nail
for
a
bit
and
then
the
J
map
core
document
for
a
bit
and
and
then
hit
any
other
business
we
might
have.
We
have
quite
a
bit
of
time
allocated
to
those
first,
two
and
I
expect
we
will
spend
it.
A
B
Wanted
to
quickly
go
over
why
J
map
these
are
slides.
We
used
at
the
last
meeting
as
well,
and
we
still
try
and
do
the
same
thing
basically
trying
to
come
up
with
a
protocol
that
will
replace
IMAP,
particularly
for
constrained
network
environments,
for
mobile
platforms
and
for
slow
networks,
so
something
that
works
well
with
latency.
At
the
moment.
It's
really
hard
to
write
a
good
client,
and
you
see
a
lot
of
people
who
say:
I'm
gonna,
write
an
IMAP
client
and
then
spend
the
first
six
months.
B
Just
writing
the
protocol
support
before
they
even
get
on
to
building
their
client,
and
so
some
JSON
over
HTTP
protocols
have
been
appearing
either
within
particular
companies
or
as
an
attempt
to
provide
API
as
a
service.
So
you
subscribe
to
someone's
API
that
then
wraps
mail
rather
than
having
to
do
mail
directly.
I
would
consider
it
a
failure
of
the
jameth
protocol
if
we're
in
a
position
where
people
start
selling
a
easy
adapter
over
the
top
of
J
map
to
allow
people
who
can't
cope
with
the
complexity
of
J
map
to
write
an
email
client.
B
A
Yeah
I
forgot
I
forgot
to
re-ask
that
I'm
not
asking
for
a
jabber
scribe
I,
don't
think
we
need
one.
What
I'm
asking
for
I
will
channel
people
from
remote
if
they
can't
use
me
Decca
see
what
I
am
asking
for
is
somebody
to
take
notes
for
minutes
and
by
that
I
mean
note
this
this
topic
was
discussed.
This
was
the
resolution,
those
or
action
items
yeah
though
that's
really
all
I
want
from
this,
not
a
lot
of
burden
here,
but
we
do
need
someone
to
do
it.
B
We
wanted
to
maintain
compatibility
with
existing
data
models,
specifically
IMAP,
to
allow
servers
to
have
a
way
to
upgrade
from
what
they
do
now
to
j-mac,
without
having
to
rewrite
everything
and
run
to
completely
separate
infrastructures,
and
we
specifically
said
we're
not
trying
to
solve
server-to-server
encryption
and
SMTP
on
port
25,
that's
a
whole
basket
of
worms.
We
do
not
want
to
dive
into
so
that's
specifically
out
of
scope
for
this
roughly.
B
This
is
a
slide
that
we
had
last
time
exactly
the
same
goals
to
jam
up
or
to
use
the
network
efficiently
to
be
easy
to
implement
and
to
be
compatible
with
IMAP
data
models.
There
are
some
small
points
there.
You
can
read
them
in
your
own
time.
Their
slides
are
all
uploaded.
We're
now
on
page
8,
game
up
mail
and
let's
hand
over
to
Neil.
C
Okay,
hi
everybody
I'll
just
hold
this,
so
this
is
an
area
that
we
has
changed
since
Chicago,
so
I'm,
just
gonna
go
over
what
we
discussed
on
the
mailing
list,
what
we
agreed,
essentially,
it's
adding
support
for
the
full
time
app
keywords,
so
we
previously
just
had
support
for
the
system
flags.
This
adds
support
for
accessing
any
I'm.
At
keywords.
C
The
specification
explicitly
says:
we're
sharing
the
registry
with
iMac
keywords
so
that
one
defined
in
one
place
is
available
in
both
IMAP
and
also
in
J
map,
which
will
provide
again
part
of
the
compatibility
and
upgrade
path
and
the
server
being
on
support
someone
using
both
an
IMAP
and
J
map,
client
to
view
the
same
mail
store,
we'll
get
a
consistent
view
of
their
data.
The
only
thing
that
we've
kind
of
changed
is
the
system.
Flags
in
IMAP
were
originally
demarked
with
a
leading
for
backslash.
C
This
was
never
then
added
to
and
all
future
keywords,
including
important
kind
of
system
level
ones
that
were
registered
used
a
dollar
prefix,
and
so
you
end
up
with
this
very
weird
mix
of
of
dollar
and
backslash,
since
backslash
is
a
real
pain
in
well
a
lot
of
languages,
because
it's
an
escaping
character
and
also
it's
really
inconsistent.
We're
gonna
map
the
backslash
seen
backslash,
there's
there's
for
system
keywords:
we
have
there,
those
all
get
mapped
to
dollar,
seen
dollar
answered,
etc,
which
makes
a
much
more
consistent
other
than
that.
The
next
slide.
C
Here's
a
quick
example
of
what
that
looks
like
basically
on
the
message
object.
You
now
have
a
keyword
property
because
there's
no
kind
of
map
type
in
JSON.
It's
the
key
of
the
object,
is
the
keyword
and
then
it
always
maps
to
true.
So
this
message
has
the
seen
the
answered
system,
flags
and
also
a
custom
flag,
which
is
just
custom,
and
this
places
the
previous
properties
we
had,
which
were
is
unread,
is
dropped
which,
with
boolean
properties
but
just
for
the
specific
system
ones.
So
that's.
Basically
the
change.
C
C
C
Not
a
list
because
two
reasons:
firstly,
a
list
is
ordered,
and
so
you
can
have
some
weird
inconsistencies
but,
more
importantly,
it's
much
easier
to
patch
a
keyword.
So
when
your
so
we
haven't
got
the
syntax
for
this
yet
but
plan
to
add
it
in
core
a
way
of
basically
saying
add
to
this
keyword
by
patching
the
object
or
remove
this
keyword.
Whereas
if
it's
a
list
you
can
do
it
by
index,
but
then
you
have
the
whole
ordering
problem.
It
gets
it's
a
lot
harder.
So
it's
yeah!
Basically,
that's
why
it's
it's
like
this.
A
F
F
C
C
We
have
a
next
slide,
please,
okay,
so
this
is
another
area
that
there's
been
quite
a
lot
of
discussion
on
on
the
mailing
list
since
the
last
conference-
and
there
have
been
quite
a
lot
of
change,
I
think
we're
very
close
to
a
consensus
consensus
now
on
on
what
to
do
here.
This
is
about
sending
email,
mail
submission.
One
of
the
core
requirements
for
J
map
was
that
you
don't
need
a
second
protocol
in
order
to
send
as
well
as
receive,
because
that
creates
all
sorts
of
support,
nightmares
that
we've
you've
ever
run
email.
C
So,
if
you've
probably
seen
so,
the
new
plan
is
the
previous
plan
was
to
have
an
outbox
mailbox
that
you
would
move
messages
to.
The
new
plan
gives
a
lot
more
control
and
ties
and
cell
phone
into
SMTP,
so
that
you
can
use
a
lot
more
of
the
available
features
in
SMTP
without
us
having
to
redefine
lots
of
new
mappings,
we
basically
define
a
new
object
type
called
the
message:
submission
object,
which
I'll
show
you
in
a
sec.
What
that
looks
like
creating
one
of
these?
C
Submission
object
ends
up
basically
as
a
log
of
email
that
you've
sent
and
we
can
also
update
or
what
the
server
can
update
the
object
with
delivery
status
of
the
message
as
it
gets
sent
through
the
system.
So
this
gives
you
a
lot
of
a
lot
more
capability
than
before
to
then,
if
you're
writing
a
client
be
able
to
not
just
send
the
message,
but
then
to
pull
up
that
message
submit
an
object
later
and
go.
What
happened
to
this
message?
C
Did
I
get
an
error
from
some
of
these
responses,
so
this
is
provides
a
lot
of
extra
flexibility
whilst
building
on
the
existing
RFC
standards.
So
I
think
I
said
we're
pretty
close
to
something
everyone
seems
to
be
happy
with
so
far
on
the
mailing
list.
So
if
we
just
move
to
the
next
slide,
it
might
be
a
little
bit
smaller,
it's
not
too
bad.
It's
gives
you
a
bit
of
an
idea
of
what
a
message
submission
object
looks
like
there's
a
reference.
The
message:
ID
reference
is
the
most
important
one.
C
J
map
has
identity
objects,
which
you
reference.
One
of
those
to
say
am
I,
who
am
I
sending
this
as
I'd
say,
see
the
identity
spec,
if
you're
not
sure
about
what
that's
about,
but
this
can
be
quite
important
for
the
server
to
be
able
to
apply
some
policy
and
check
you
allowed
to
send
that
message.
The
thread
ID
is
just
the
thread.
Eydie,
that's
associated
with
the
message
of
the
message.
C
Id
the
server
sets
that
to
make
it
easier
for
the
client
query
these
things
later,
then
we've
got
the
important
bits
which
is
basically
the
envelope.
This
will
change
slightly
still,
so
we
can
add
attributes
but
is
essentially
the
s
the
data
you
need
from
smtp
than
for
the
mail
from
and
the
receipt
to,
maybe
can't
unsend.
So
this
is
one
of
the
more
interesting
properties
is
for
systems
that
can
support,
undo,
send
or,
if
you,
if
they
support,
delayed,
send
and
you've
delayed
the
send
of
the
message.
C
C
This
starts
as
null,
but
after
the
server
starts
and
the
server
can
update
this,
it's
not
a
must,
because
it's
would
make
it
very
hard
to
build
simple
proxies
to
SMTP,
but
we're
hoping
the
future
the
service
that
will
implement
this
and
update
this
with
the
status
of
messages
to
show
what
happened
to
them
after
you've
sent
them,
which
will
make
it
possible
for
clients
to
much
more
easily
show
users
the
status
of
their
sent
messages.
So
that's
the
general
proposal
for
message
submission
so
I'm
gonna
pause
there
to
see.
E
C
E
C
E
A
And
yes,
pushing
this
button
makes
a
big
difference:
okay,
the
fact
that
when
I
touched
the
mic
without
pushing
that
button,
it
made
a
lot
of
noise
made
me
think
that
I
didn't
need
to
push
the
button,
but
I
think
the
people
remotely
will
hear
my
sepulchral
voice
better
now,
Dave
is
on
me
deco,
so
I'm
going
to
enable
him
with
the
big
red
button.
Dave
does.
I
So
this
is
a
really
small
point
that
isn't
a
really
small
point:
the
the
naming
of
message
ID
and
I
apologize
for
not
being
into
the
spec
deeply
enough
to
know
the
answer
to
this,
but
I
believe
you
said
that
it
is
not
a
RFC
5322
message.
Id
I
therefore
invite
you
to
not
make
it
be
the
same
name
so
that
there
will
be
less
opportunity
for
confusion.
You'll
get
enough
of
that
anyhow.
C
Thanks
Dave
yeah,
that's
a
good
point.
It's
slightly
tricky
at
the
moment
we're
very
consistent
off
there's
an
object.
Type
and
message
is
the
object
type
and
whenever
we
reference
an
ID,
we
want
to
use
that
type
name
plus
the
words
ID.
So
I
guess.
One
solution
is
to
object
type
name
in
J
map
from
message
to
something
else:
I'm
not
sure
if
we
can
come
up
with
something
suitable,
but
yeah
I
agree
that
that
is
likely
to
cause
confusion.
So
we
should
try
and
find
some
some
way
of
avoiding
that
confusion.
If
we
can.
J
John
Dowdle
from
Airbus-
and
this
is
my
first
time
in
this
group-
so
forgive
me
if
his
questions
been
answered
Aeons
ago,
I'm
old
enough
to
remember
the
days
when
mail
wasn't
abused
by
spammers
and
so
forth,
and-
and
you
know
nobody
seems
to
send
delivery
reports
and
things
these
days
for
fear
of
triggering
spamming
pots.
As
if
you,
when
you
were
thinking
this
up,
did
you
think
well?
Should
we
actually
try
and
do
it
a
different
way
and
then
discarded
that
and
came
up
with
this
or
what
was
so
specifically.
C
The
who
is
sending
is
tied
to
the
identity.
I
do
you
think,
but
the
the
delivery
site
of
stuff?
It's
it's
more
just
about
exposing
the
information
that
we
get
to
clients
in
an
accessible
way.
It's
it's
not
certainly,
no
guarantee
that
you'll
be
able
to
get
information
beyond
this
stuff.
Here
you
should
be
able
to
get.
This
is
the
final
status
code.
It
got
before
it
left
your
system,
but
delivery
status,
things
beyond
that.
C
Yes,
it
would
depend
if
it's
internal
mail,
then
maybe
you'll
always
get
them,
but
if
it's
external,
perhaps
it
won't
so
I-
think
exposing
that
is
important.
Hopefully
it's
exposed
in
a
way
that
perhaps
in
the
future,
yes,
you
can
add
other
mechanisms
that
might
might
my
more
suitable
to
today.
The
way
we're
seeing
most
new
systems
do.
This
is
with
web
bugs,
essentially
bypassing
SMTP
altogether
just
put
an
image
into
the
email.
If
people
actually
load
the
images,
then
you
say
yep
they've
read
it.
C
You
could
integrate
that
in
some
way,
as
well.
I
think
we're
we're
still
working
on
this,
as
Chris
mentioned
still,
proposals
on
how
this
is
going
to
be
represented,
and
certainly
it
should
be
open
to
accept
the
accessible
in
the
future,
but
there's
valuable,
there's
value
right
now,
I
think
in
exposing
information
that
we
currently
have
from
protocols
that
are
already
there
and
in
use
I.
C
I
So,
just
following
up
on
that,
even
a
bit
further
and
I
type,
this
into
jabber,
also
what's
occurring
to
me,
is
that
you've
got
three
sources
of
naming
532
5,
3,
2,
1
and
J
map
and
they're
co-occurring
within
this
single
environment,
and
you
may
want
some
meta
conventions
for
that,
so
that
you
just
don't
have
to
worry
about
particular
cases.
Colliding.
A
H
C
C
Don't
think
that
would
work
in
this
case
then
so
the
ID
is
or
there's
always
an
ID
property
with
on
any
object
and
that's
the
idea
of
that
particular
object.
The
rest
of
those
are
foreign
keys.
If
you
like
the
external
references,
and
so
they
certainly
can
be
lumped
in
with
the
ID
of
the
first
thing.
Ok,
so
change.
C
Again
would
I
don't
think,
that's
the
best
solution,
because
generally
we
make
everything
as
much
as
possible
key
value
on
the
top
top
level
to
make
it
I
think
it's
easier
to
track
changes
and
to
submit
just
patches
of
things
that
you
want,
but
I
think
I
think.
Well,
we
can
see
if
there's
any
more
suggestions
now
but
I
think
we
can
take
the
list
and
find
a
solution.
C
B
B
C
C
C
So
this
is
the
representation
in
JSON
of
the
obviously
five
three
to
two
message
and
kind
of
related
to
that
being
able
to
fetch
just
part
of
the
body.
So
if
you
have
a
text
body,
that's
multi
megabytes,
long,
allowing
client
to
just
fetch,
maybe
the
first
hundred
kilobytes
of
it
display
that
and
then,
if
user
really
wants,
it
explicitly
go
back
and
fetch
the
rest
of
it.
C
In
general,
NJ
map
we've
been
very
careful
to
make
sure
that
the
client
can
never
get
flooded
with
data.
It
always
is
control
of
how
much
data
within
rough
bounds.
It
will
get
back
from
the
server
in
response
to
a
request.
This
is
one
area
where
it
doesn't
know
how
big
the
body
is,
and
it
could
ask
for
body
and
get
back
50
megabytes
of
data
over
the
connection.
That's
not
great
you're
special!
C
If
you're
on
slow
mobile
connection
that
could
lock
up
your
whole
client
if
it
doesn't
know
how
to
cancel
that
and
try
and
do
something
else,
so
this
is
something
where
we
haven't.
You
got
a
proposal,
yet
it's
more
the
kind
of
open
for
ideas
stage,
the
other,
so
the
other
point
of
it
is
the
the
structure
we
have
at
the
moment,
representing
the
message,
hides
pretty
much
all
the
complexities
of
mime
and
represents
the
message
in
a
simple
body
which
could
be
text
body
or
HTML
body
or
both.
C
C
So
if
you
want
more
than
that
at
the
moment,
you
own,
the
other
option
is
to
fetch
the
raw
via
three
to
two
message
and
parse
it
yourself
and
do
everything
yourself,
which
is
an
option
in
J
map,
but
there's
no
in-between
stage
so
I
think
one
of
the
open
questions
is
whether
that's
a
sufficient
representation
in
JSON.
If
not,
what
else
should
be
there?
C
How
can
we
potentially
add
more
options
without
making
it
ridiculously
complex
and
also
making
sure
that
clients
that
do
the
things
that
most
clients
do
don't
have
to
deal
with
all
this
complexity?
Still
they
can
still
use
this
more
simple
representation.
So
I
think
this
is
more
kind
of
open
question
and
something
we'll
be
looking
at
on
the
main
list
over
the
next
few
weeks
a
few
months,
but
for
what
to
bring
up
now
to
see
if
anyone
had
particular
ideas,
comments
or
suggestions
on
this
area.
E
Chris
Newman,
the
ones
I
haven't,
thought
it
all
the
way
through
yet.
But
the
one
sort
of
starting
point
for
the
structure
problem
is
so
we
have
this
attachment
list
in
the
in
the
J
map
structure.
If
we
put
so
IMAP
has
a
new,
a
new
dotted,
numeric
string
that
says
we're
in
the
mime
structure.
This
part
up
here,
so
that's
something
that's
defined
and
I
met.
E
If
you
added
that
I
data
item
to
the
attachment
list,
you
know
clients
can
ignore
it
if
they
don't
care
about
it,
but
it
gives
clients
that
do
care
about
the
mine
structure,
that
additional
information
about
the
structure,
so
that
might
get
us
part
of
the
way
to
a
more
cleaner
semantic
mapping
and
you
might
be
able
to
from
those
numbers
figure
out.
You
know,
drop
a
number
and
fetch
that
or
something
like
that.
So
I
think
that
might
be
a
road
to
walk
down.
E
C
Well,
there
yeah
all
the
attachments
already
get
a
blob
ID
and
you
can
get
a
URL
that
represents
those
are
not
so
you
could
then
do
a
partial
range
fetch
on
that.
But
if
the
actual
just
text
body
an
HTML
body
I,
think
we
want
some
way
of
just
be
able
to
return
a
truncated
version
within
the
JSON
structure
within
a
batch
call
still
also
I.
Don't
think
that
HTTP
ranges
can.
B
Gonna,
yes,
but
it's
certainly,
this
is
gonna,
be
one
of
the
interesting
bits
that
we
need
to
spend
a
while
on
both
in
terms
of
working
out
the
mapping
even
for
what
we
have
now
and
how
to
get
there.
You
have
a
multi-part
mix
that
has
some
text
and
an
image
and
then
some
more
text
than
another
image.
What
does
that
look
like
over
J
map?
Thankfully
it's
immutable,
so
at
least
you
don't
get
a
round
trip
back
from
that.
H
A
A
C
C
H
C
I
A
synonym
for
flexibility
is
non
interoperability
to
the
extent
that
it
is
possible
or
to
reasonably
define
an
algorithm
that
does
the
mapping
between
the
two
forms.
It
will
increase
interoperability
a
lot.
It's
usually
a
pain
to
do
that
kind
of
mapping
to
do
that.
Kind
of
definition,
long
run
benefit
usually
is
pretty
high.
E
E
You
know
the
Minamoto,
some
minimum
set
of
things
you
do,
and
so
that
gets
you
closer
to
interoperability
but
yo
with
respect
what
why
I
think
we
do
need
a
little
a
little
wiggle
room
is
because
j.j
map
is
actually
quite
a
bit
closer
to
the
UI
than
IMAP,
and
so
in
order
to
get
the
easy
good
UI,
we
actually
do
need
to
allow
some
wiggle
room
to
make
improvements
and
in
the
conversion.
So
you
know
if
there's
some
some
broken
mail
format.
If
you
need
to
clean
it
up,
so
it
works
in
the
UI.
B
A
particular
example
that
you
run
into
a
lot
when
you're
getting
email
from
all
over
the
internet
is
the
charset
field
that
comes
in
on
mind.
Parts
can
be
all
sorts
of
crazy,
broken
I
get
a
lot
of
charset
equals
charset
equals
something
it's
a
really
basic
case
for
there's
all
sorts
of
weird
stuff
winds
up
in
there
that
it
looks
like
someone's
just
typed
around
a
bunch
of
texts
and.
C
I
think
just
there's
kind
of
a
related
area
just
on
the
idea,
not
necessarily
always
specifying
everything
and
it's
being
better.
It's
it's
search,
so
in
IMAP
search
is
very
explicitly
substring
based
and
as
such,
is
basically
impossible
to
implement
in
a
performant
way
and
be
compliant
with
the
spec.
So
that's
why?
Well
you
get
things
like
Gmail,
just
ignore
suspect.
H
C
It
would
be
useless
or
is
a
mess,
whereas
with
Jayma
what
we've
done
is
say.
This
is
how
you
should
interpret
the
filter,
but
we're
not
gonna.
Tell
you
how
to
stem
we're,
not
going
to
tell
you
exactly
how
you
should
match
what
your
algorithm
should
be
for
matching
the
text
chance.
This
is
more.
This
is
how
you
should
interpret
the
intent
and
give
us
back
results
and
I.
Think
that's
the
only
way
that
you,
otherwise,
you
wouldn't
have
conformed
implementations,
because
Gmail
are
not
going
to
change
their
stemming
out
within
them.
C
C
K
C
L
C
It's
just
text
respectful
dates.
It
tells
you
exactly
what
you
meant
to
be
doing
that.
Yes,
sir
I
should
hit
that
clear.
I
was
trying
to
I
guess
just
use
as
an
example
of
where
I
think
you
want
to
specify
enough
to
be
able
to
operable,
but
not
necessarily
the
fine
detail,
because
that
restricts
things
too
much.
C
A
E
C
C
So
extensions
over
time,
we
will
obviously
want
to
add
further
data
types
you
can
access
over
J
Matt
will
want
to
add,
potentially
extra
properties
to
objects
that
exist
in
previous
specs,
potentially
even
change
semantics
of
certain
methods,
and,
of
course,
if
you
have
a
proprietary
services,
are
probably
gonna
want
to
add
on
custom
things
which
don't
make
sense
necessarily
to
standardize.
But
you
want
to
expose
suppose
that
over
gemwrap
as
well,
so
we
need
to
come
up
with
a
flexible
way
of
allowing
for
extensions
in
the
future.
C
You
was
with
the
set
of
method,
calls
you're,
making
your
pass
it
a
using
and-
and
that
gives
you
and
that's
a
property
with
a
list
of
named
extensions,
and
you
can
have
vendor
extensions
in
there,
which
must
be
names
based
under
domain,
that
the
vendor
owns
to
make
sure
it
doesn't
clash.
There's
no
X
dash
prefixes
anywhere
in
the
thing
once
you've
opted
into
the
extension
that
just
that's
what
you
do.
C
That
means
that
that
then
applies,
but
if
you
don't
opt
in
then
must
conform
with
the
base
specification
without
without
the
extension
must
behave
without
the
extension.
If
there
are
extensions
that
are
not
compatible
with
each
other,
then
the
server
needs
to
reject
it.
If
the
client
tries
to
ask
for
both
to
be
used
at
the
same
time
and
then
the
server
advertisers
which
extensions
it
can
support
someone,
that's
the
base
idea
are
the
bib
on
using
GMAT
mail.
K
K
C
K
K
C
C
Yes,
oh
yeah
and
the
server
will
advertise
watch
extensions
it
supports
after
you
have
authenticated,
which
is
quite
important
cuz.
That
means
that
it
can
give
different
options
to
different
people,
which
we
found
before
is
useful
in
the
past
obvious.
If
it
wants
to
keep
the
same
to
everyone,
that's
easy
easy
to,
but
requiring
authentication
first
makes
things
more
flexible.
There.
K
C
E
Yeah
Chris,
Newman
I
think
the
experience
I've
seen
in
the
ITF
is
whenever
possible,
you
want.
You
know,
extensions
that
the
server
announces
and
the
client
uses
or
not
as
it
wishes.
But
you
know
in
IMAP
we
did
find
cases
where
we
needed
the
client
to
explicitly
opt-in
and
that's
what
the
enable
commands
for
yeah.
These
are
all
what
explicitly.
C
I
think
the
other
interesting
question
is
how
to
avoid,
if
possible,
the
situation
with
IMAP,
where
the
base
specification
over
time
becomes
essentially
useless,
and
you
need
a
very
long
list
of
extensions
to
be
a
useful
protocol,
but
how
you
convey
that
to
users,
in
particular,
of
my
service
pause,
IMAP,
your
service
port,
so
IMAP.
Why
is
this
not
work
as
well
with
yours,
as
it
does
with
mine,
because
they're
completely
different
things?
M
C
The
idea
of
vendor
extensions
is,
is
it's
just
a
way
of
avoiding
name
clashes
a
if
you
prefix
it
with
your
control
domain?
You
can
use
whatever
you
want,
and
you
know
those
are
custom
extensions.
If
someone
else
uses
it
here
be
dragons
on
them.
So
once
you
do
like
Joe's
telic
combat
Microsoft.
No,
no,
probably
should
be
something
like
that.
The.
C
C
We
don't
believe
that
the
there
is
an
existing
authentication
mechanism
that
fulfills
the
requirements
that
we
have
for
je
map.
There
is
a
specification
we
have
in
Java,
which
we
can
separate
out
into
a
separate
spec.
Certainly
if
we
go
forward
with
this,
I
think
needs
to
be
a
separate.
Spec
is
the
general
consensus
and
does
fulfill
the
requirements.
C
So
one
option
is
to
see
if
we
can
pursue
that
as
a
standardization
effort
and
use
use
that,
but
if
I
just
move
on
to
the
next
I'll
I'll
just
talk
briefly
about
what
we
think
are
the
requirements,
and
then
people
can
come
up
and
tell
us
if
there's
some
magical
solution
that
we've
missed.
That's
going
to
do
it.
So
if
we
could
just
skip
the
next
side,
okay,.
H
C
First
of
all,
basic
auth
is
out
like
it's:
it's
spacely,
deprecated,
Gmail,
there's
other
mail
servers
do
not
allow
you
to
use
username
password
directly
fast
mail.
We
don't
let
you
use
your
standard
password
directly.
No
one
wants
this.
It
creates
all
sorts
of
cutie
problems
which
I
hope
everyone's
aware
of
so
okay,
that's
out.
Secondly,
it
can't
require
the
client
author
of
the
mail
client
to
have
to
man
in
the
register
with
every
J
map
server
in
the
world.
You
know,
there's
a
hundred
thousands
millions
of
mail
servers
just
generally
the
earth,
something
like.
C
Oh
all,
you
have
to
pre
register
with
the
with
Google
to
get
your
before.
You
can
use
it
and
that
clue
does
not
scale
for
mail,
so
it
has
to
be
usable
without
manually
registering
beforehand.
We
think
it
should
allow
common
two-factor
authentication
if
you
use.
This
is
something
to
come,
widespread
and
hopefully
be
extensible,
and
it
needs
to
be
extensible
with
further
authentication
mechanisms
that
become
available
and
also
mail
is
using
quite
a
few
contexts
where
there
isn't
necessarily
browse
them.
C
We
think
it'll
be
much,
but
if
it
didn't
require
a
browser
necessary
to
perform
authentication
or
even
preformed
I've,
just
noticed
a
spelling
mistake
great.
So
those
are
the
general
requirements.
We
think
that
we
have
so
first
of
all,
I'm
sure
there
are
people
here
with
comments
on
are
those?
Do
you
think
those
are
the
right
requirements?
Is
there
something
that
meets
them
already?
Tell
us
more.
N
N
Just
you
know,
from
a
matter
of
practicality,
I
I
haven't
looked
at
the
Charter
in
a
little
while
I,
don't
know
the
timescale
of
this
working
group,
but
you
know
you
say
that
you
can't
just
use
basic,
but
over
TLS
you
know,
I
mean
when
I
configure
my
IMAP
client
to
talk
to
fast
mail,
loving
fast
now,
I.
You
know
you
give
me
a
token
that
I
put
in
and
and
and
that
is
used
even.
N
N
C
C
No
worse
than
IMAP
currently
well,
the
thing
is
with
IMAP.
Currently,
lots
of
vendors
are
turning
to
well,
not
something
that
the
big
vendors
that
can
force
it
through
are
turning
away
from
that
and
adding
on
proprietary
OAuth
extensions
to
IMAP
sure
which
yeah.
So
this
is
clear,
it's
kids
kind
of
a
an
IMAP,
but
this
is
a
problem
space.
That's
not
going
away.
I
and.
N
C
Well,
that's
it
yes!
So,
as
we've
said,
we
definitely
if
we're
gonna
go
forward
with
what
we
have
gonna
split
down
to
separate
spec
I
think:
what's,
there
is
actually
a
really
good
solution
for
this
criteria
and,
as
you
say,
that
is
definitely
generally
applicable,
so
should
not
just
be
purged.
A
match
should
be
more.
N
C
N
And
and
there's
a
really
active
effort
right
now
in
the
w3c
to
define
you
know
to
do
web
authentication
for
UTF
and
then
all
the
output
of
the
photo
stuff
and
yeah.
So
just
so,
you
know
I'm
also
the
liaison
from
the
IETF
to
the
w3c.
So
this
is
partially.
My
headache
to
is
that's
all
happening
on
their
side
of
the
trench,
and
we
may
need
to
get
more
involved
in
that,
and
maybe
we
should
be
anyway
just
regardless
of
this,
so
it
split
it
on
a
separate
document.
A
We
have
Sean
Leonard.
His
next
I
would
like
to
see
TLS
mutual
authentication,
which
is
already
supported
by
some
IMAP
clients.
Where
is
it,
and
can
we
devolve
to
another
spec
that
works
reliably
on
that
topic?
Don't
use
basic
off
I
somewhat
disagree
with
mark.
The
key
thing
is
that
the
user
prompt
is
not
username
and
password,
but
some
kind
of
token
prompt,
maybe
with
challenges
or
UI
elements,
and
then
he
goes
back
and
says.
User
prompt
should
read
protocol
elements.
C
Right
so
I
think
the
TLS
mutual
or,
if
I,
understand
correctly,
what
he's
referring
to
is
where
you
would
you
need
the
client
certificate
as
well?
Yes,
that's
not
always
possible
in
all
situations
and
I.
Do
you
have
the
problem
still
of
generating
as
difficult
and
getting
it
an
authenticating
I?
Don't
think
this
is
necessarily
a
general
surgeon.
K
A
O
O
C
C
So
the
implementations
that
we've
seen
mostly
if
I
will
so
far
tend
to
be
not
necessarily
compatible
with
each
other,
tend
to
require
you
to
register
beforehand
with
the
OAuth
provider
in
order
to
be
able
to
use
it
from
the
client
which
and
also
requires
a
browser
which
violates
at
least
three
or
two
of
the
ones
on
the
requirements.
Here
is
the
short
answer:
Torsten.
O
H
O
The
description
of
the
current
situation
that
doesn't
mean
that
the
situation
can't
be
changed.
I
mean
what
you're
proposing
in
your
code
specification
is
a
complete
new
product
for
authentication
for
HTTP
based
clients,
right
they've,
a
complete,
complete
message
exchange
which
incorporates
OTP,
u2f
and
all
the
other
stuff,
which
is
quite
complicated
for
my
for
my
experiences.
So
the
question
also
is:
if
you
do.
O
You
can't
just
answer
on
my
questions
instead
of
just
laughing
right,
so
I
mean
having
implemented
a
lot
of
this
IDP
crap
for
several
years
in
Miami
and
my
side.
I
know
how
complicated
it
is
to
really
implement
multi-factor
authentication,
and
you
were
up
to
define
a
new
protocol
which
which
will
allow
or
intends
to
allow
a
client
to
me
to
authenticate
towards
the
server
using
multi-factor
authentication.
So
you
even
have
included
you
AF
fight
or
to
push
notifications
to
to
authentication
absence
on.
Do
you
want
to
consider
all
of
them
in
your
protocol?
O
I
mean
the
other
option
is
to
use
OAuth.
To
answer
your
question
regarding
a
registration,
you
can
change
that,
there's
an
odd
dynamic
registration
piece
and
off
so
any
any
email
kind
or
there
can
be
registered
dynamically
with
the
OAuth
provider.
If
you
want
to
make
the
o
of
compressor
verb
compliant
to
you
or
to
your
specification,
go
and
sit
down
and
write
an
OAuth
profile
right
off
as
a
framework,
and
if
you
want
at
least
me,
I
would
like
to
contribute
to
this
activity
instead
of
saying,
oh,
oh
of
is
crap.
O
We
can
sit
down.
You
can
can
somewhat
draft
something
else,
but
from
my
perspective,
what
it
needs
is
a
discovery,
registration
and
a
definition
of
scopes.
That's
it
right.
So
the
rest
in
the
spec,
for
example,
token,
revocation,
there's
an
hour
seat
and
I
happen
to
be
the
editor
of
this
RC.
You
can
just
include
it.
Oh
can.
I
I
think
this
is
an
interesting
list.
It
looks
intelligent
to
me.
It
looks
appropriate
to
me
and
I
think
it
has
all
the
difficulty
that
the
past
few
minutes
have
been
demonstrating
this,
and
the
real
danger
here
is
that
discussion
will
get
dominated
by
people
who
have
their
favourite
solution
in
mind,
rather
than
really
trying
to
deal
with
the
reality
that
this
is
a
space
with
multiple
approaches.
There
is
no
dominant
solution
and,
worse
than
that,
things
change
over
time.
I
All
of
that
says,
in
all
likelihood,
the
goal
of
making
sure
this
is
not
built
into
J
map,
but
has
an
interface
is
the
right
one
that
it
doesn't
depend
on
a
particular
implementation.
Environment
like
browser
is
another
appropriate
of
requirement,
but
it
also
means
that
this
this
isn't
going
to
have
an
easy
solution.
Best
I
can
figure
is
it
needs
to
define
some
kind
of
interface
into
the
environment
and
I?
Don't
really
know
what
that
means
in
a
way.
That's
scalable.
L
N
H
H
So,
if
possible,
depending
librational
browser
is
a
good
thing.
It
seems.
The
other
thing
is
that
Earth
doesn't
always
require
each
fly
to
be
registered.
Just
like
Dawson
said
you
know,
so
it
can
be
completely
dynamic
register
dynamically
registered
or
we
can
think
of
something
else
as
well
as
when
it
comes
to
registering,
and
the
point
is
that
what
we
want
at
Jayma
probably
isn't
authentication.
H
C
I
think
everyone's
very
clear
that
separating
out
is
the
right
solution,
so
also
dim
doing
that
in
terms
of
yes,
existing
solutions.
Earth
is
clearly
the
only
option.
That's
out
there,
that's
an
existing
solution,
so
we
should
see
if
there's
a
profile
of
that,
that
seems
sensible.
That's
certainly
worth
investigating,
and
the
other
option
is
to
separate
out
the
inspect
that
we
currently
have
and
investigate
the
possibility
of
making
that
as
a
separate
standard
but
I
think
yeah.
Everyone
stay
that
it
needs
to
be
flexible.
C
B
Wanted
to
address
one
point
that
you
made
there,
which
is
all
you
need
to
do,
is
authorize
a
ssin.
You
don't
need
to
authenticate
the
specific
person.
One
difficulty
here
is
we're
not
just
giving
you
access
to
view
information,
we're
also
giving
you
permission
to
send
email
on
the
behalf
of
somebody.
So
knowing
exactly
who
is
sending
email,
rather
than
just
that
they
have
right
to
say
the
data
is
important.
E
Chris
Chris
Newman
one
other
point
that
was
raised.
Is
you
know
why
can't
we
just
require
browsers
and
the
answer
that
is:
there's
lots
of
of
agents
on
the
internet
that
submit
mail
for
all
sorts
of
reasons
that
are
automated
and
don't
it
don't
even
necessarily
have
a
user
in
front
of
them,
voicemail
systems
etc.
So
yeah
yo,
submitted
and
and
need
to
scan
some
information
about
the
email
as
well.
Yes,.
K
Aleksey
I
think
talking
about
OAuth
and
trying
to
see
some
text
would
be
useful
next,
but
rather
you
know
if
we're
going
to
separate
what
you
have
you
know,
I
can
talk
to
kitchen
working
group
and
see
you
know
whether
there
is
any
work
to
be
done
there,
and
you
know
we
yeah
most
likely.
Most
of
the
work
is
going
to
be
done
not
in
this
working
group.
N
New
York,
hopefully
one
last
time-
is
this
still
working.
Okay,
so
I'd
like
to
push
back
ever
so
gently
on
on
the
OAuth
notion:
I,
don't
think
we
should
use
it
just
because
it's
there,
but
but
let's,
let's
have
the
discussion
I
just
don't
want
there
to
only
be
positive
thoughts
about
it
off.
Here,
I
was
just
talking
to
our
Richard
Barnes
who's,
the
co-chair
of
the
w3c
web
authentication
working
group,
and
he
thinks
he's
pretty
sure.
Their
plan
for
HTTP
authentication
is
to
use
to
find
so
token
binding.
N
C
N
O
The
different
kinds
who
want
to
support
I
would
suggest
not
to
not
to
state
that
you
don't
want
to
use
a
browser.
Instead,
I
would
like
to
suggest
that
you
stayed
which
kind
of
clients
you
want
to
support
because
for
web
applications
Claire
natural
to
use
the
web,
they
were
browser
to
the
authorization
process
and
even
for
smartphone
applications.
That's
a
state
of
the
art.
There
are
out
tools
out
there,
libraries,
Safari
viewcontroller
2xx.
You
perform
authentication
authorization
processes
that
way,
which
also
gives
the
ID
PD
the
mechanism
to
do
a
risk-based
authentication.
O
All
the
stuff
you
want.
You
don't
want
to
deprive
it
to
put
that
into
your
protocol
and
if
it
comes
to
to
to
server
to
server
interactions,
to
voicemail
that
all
the
stuffs
there
are
other
grant
types
out
there.
That
could
be
used
for
that.
Have
you
ever
considered
to
use
refresh
tokens
or
the
client
credential
flow?
C
C
A
P
Q
C
Cuz,
that's
in
any
way,
you
can
get
push
things
to
them,
but
we'd
also
like
it
to
be
flexible
enough,
using
whatever
system
that
you
need
to
use
the
in
terms
of
what
data
is
transferred
over
push.
This
I
think
we
are
reasonably
happy
with
this.
Just
for
transferring
state
string
is
not
transferring
any
of
your
actual
email
data
or
any
other
content
data,
it's
just
the
type
name
like
message
or
thread,
and
the
state
string,
which
is
represents
the
current
state
on
the
server
of
that
type
of
the
set
of
objects
of
that
type.
C
One
extra
thing
we
do
want
to
add
to
the
data.
That's
pushed
is
some
kind
of
flag
of
what
triggered
this
change
so
that
clients
can
tell.
Was
it
a
message?
Delivery
that
changed
the
state
of
the
messages,
or
was
it
that
you
change
something
in
the
client
somewhere,
because,
if
you're
in
a
particularly
battery
constrained
environment,
you
might
be
more
interested
in
waking
up
with
the
radio.
C
We
also
need
something
that
works
on
the
web
and
on
desktop
on
desktop.
Ideally,
when
you
can
hold
over
in
a
persistent
TCP
connection,
that's
a
lot
simpler
to
deal
with
you
don't
have
to
go
by.
A
third
party
should
be
quicker,
more
reliable,
10th,
well,
more
reliable,
maybe
so,
basically,
at
the
moment
in
the
spec,
we
have
to
mechanize,
therefore
push
to
support
the
two
different
use
cases
for
the
web
and
desktop.
C
C
This
is
basically
a
long
held
TCP
connection.
The
other
option
is
you
basically
register
a
URL,
a
callback
on
the
server
and
the
je
map
makes
a
post
payment.
Server,
makes
a
post
request
to
that
URL
whenever
there's
a
push
and
then
so,
if
your
this
is,
if
the
je
map
version
is
compatible
with
the
with
RFC
80
30
in
terms
of
what
it
does
with
the
push
subscription
URL.
C
So
if
you
have
a
push
server,
which
is
up
to
the
client
to
have
its
own
push
server,
that
you
can
then
use
that
either
with
the
rest
of
RFC
a
t30
to
get
back
to
your
ua
r,
or
you
can
use
your
proprietary
APNs
GCM,
whatever
other
mechanism,
to
make
sure
that
that
data
ends
up
back
at
actual
client.
So,
basically,
that
you
have
to
have
your
own
push
server
in
that
situation,
but
it
gives
you
the
flexibility
of
either
using
the
full
standards
or
of
going
your
own
proprietary
to
have
it.
C
A
C
And
say
this
is
a
terrible
idea.
Both
of
those
are
terrible.
The
first
one
is
terrible.
The
event
source
is
terrible,
because
you
might
lose
that
in
very
situations.
It
doesn't
work,
you
can't,
and
people
are
moving
away
from
using
event.
Source
I
think
was
the
summary
of
what
he
was
saying
in
certain
situations.
The
TCP
connection
might
be
dropped
on
the
way.
Various
other
things
like
that
to
which
I
would
say.
Yes,
but
we
have
a
mechanism.
Their
server
also
sends
a
ping.
C
Every
five
minutes
can
tell
if
something's
gone
wrong
with
the
connection
on
the
line,
and
we
try
and
reopen
it
if
you,
obviously,
if
it
fails
every
time,
then
it
just
can't
open
a
push
connection.
The
other
thing
is
that
it
does
work
in
a
lot
of
situations,
including
in
current
browsers
and
it's
very
easy
to
implement
for
any
desktop
client
or
anything.
That's
that
can
hold
open
a
persistent
connection,
Marc
Marc.
N
N
Yes,
okay,
good,
so
you
can't
lose
events
and
that
in
at
least
in
those
scenarios,
I
the
the
strongest
kind
of
argument
that
I
heard
was
that
it
often
causes
a
lot
of
really
nasty
problems
when
there's
an
intermediary
like,
for
example,
a
virus
scanner
in
there,
and
they
do
a
lot
of
buffering
and
weird
stuff,
and
it's
really
hard
to
debug
those
problems,
I'm,
not
saying
that
that's
deal
killer,
I'm,
just
noting
it!
This.
C
C
One
option
is
that
we
just
add
HTTP
header
you
can
set,
which
says:
do
this
in
long
poly
mode
and
said
so
basic
loads.
The
connection
every
time
you
send
a
push
other
than
that,
it's
identical.
We
have
actually
amended
this
at
fast
mail
because
we
for
IE
8,
&
9.
They
you
couldn't
do
because
they
were
doing
buffering
things
similar
things,
so
it
uses
long
poly
instead,
so
the
client
could
detect
something's.
Not
working
here
doesn't
get
the
pings
through.
That's
it
it's
sending
things
every
5
minute.
C
D
Jeff's
it
back
again,
I,
don't
really
have
an
opinion
either
way,
but
I
don't
really
have
an
opinion
either
way,
but
I
would
be
a
little
worried
on
in
some
server
setups
of
just
you.
Having
way
too
many
persistent
TCP
connections
going
to
the
server
which
I
guess
is
that's
basically
what
you
get
with
IMAP.
So,
oh.
C
C
Also
true,
okay,
so
I
think.
Actually,
this
is
probably
a
reasonable
solution
for
that
side
of
the
push
which
is
good,
I
think
we
should
probably
maybe
look
at
yeah,
adding
the
option
of
setting
of
a
header
in
respect
to
switch
into
long
poly
mode,
which
I
think
is
a
good
fallback
position
for
for
when
you
have
into
intermediaries
getting
in
the
way.
C
As
mark
noted,
there's
no
me
because
of
buffering
issues
and
if
you
close,
the
connection
they
flush
the
buffer,
but
that's
a
very
trivial
change
and
I
think
that
that
will
be
ok.
So
the
other
mechanism
is
the
one
that
goes
via
a
callback.
Url
I
think
Martin's
main
objection
here
was
when
I
said
it
meets
a
t30.
He
was
like
yes,
but
actually
a
t30
is
not
the
current
state
of
the
art.
C
If
you
want
to
use
it
with
web
push,
for
example,
you're
gonna
need
all
this
extra
encryption
happening
on
the
push
which
is
in
a
draft
IFC,
which
is
not
actually
final
yet
so
the
question
is:
do
we
want
to
require
that?
Do
you
want
to
have
support
for
that,
but
make
it
optional?
So
they've,
if
you
don't,
if
your
client
and
push
it
over,
doesn't
want
to
use
that
it
doesn't
have
to
and.
N
So
mark
again
so
web
push.
You
know,
at
least
with
a
browser.
The
push
server
is
gonna,
be
something
that
is
probably
not
under
the
control
of
the
you
know,
end
user
or
the
mail
server
or
whatever
the
jam
app
server.
It's
gonna
be
a
third
party,
so
you're
probably
gonna
need
to
encrypt
it.
That's
why
that's
so
integrated
into
that
architecture.
Yeah.
C
L
C
Be
there's
some
things
you
can
glean
from
it,
but
most
of
those
things
you
could
clean
from
just
knowing
a
push
was
sent
from
the
server
to
this
client,
which
you
can't
hide
by
encryption
because
you're
still
pushing
the
data.
So
that's
the
question
of
how
much
actual
value
we're
getting
from
that.
However,
if
you're
going
to
where
yes
I
know,
you
can
always,
if
you're
going
to
make
it
work
with
web
push
directly,
then
obviously,
you
gonna
need
this
scription,
because
it
won't
work
without
that.
That's
I'm.
If.
N
So,
just
from
a
mechanical
standpoint,
it'll
get
eventually
done
the
worst
possible
situation
will
be
well,
not
the
worst
possible,
but
the
common
situation
will
be.
If
they
take
longer
than
you
do
then
you'll
sit
in
the
RFC,
editor
queue
and
wait
for
the
defense.
Then
you
won't
get
your
final
RFC
published,
but
everything
else
will
be
done
and
yeah
you
can
still
implement
I
guess.
C
This
will
support
browsers
on
on
browser
clients,
either
by
the
way
which
just
do
the
number
house.
Clients
also
have
to
act.
Implant.
The
same
encryption
yeah
for
the
browser
does
is
why
I'm
asking
really
oh
yeah
I
got
any
opinions
on
that.
Could
we
just
mandate
the
encryption,
so
it's
just
at
least
a
it's
the
same
with.
N
H
H
C
C
H
N
C
C
C
I
The
the
process
point
that
I
want
to
comment
on
is
a
suggestion
to
consider
incorporating
something
that's
being
developed
in
a
parallel
working
group
suffers
more
than
just
the
possible
queue
latency
that
was
cited.
It
just
generally
means
that
you're
leaving
your
fate
to
an
another
group
that
may
or
may
not
produce
something
useful
on
the
average.
That's
not
such
a
good
idea.
I
I
I
I
think
I
understand
what
you
just
said.
My
suspicion
is
that
when
it
gets
down
to
actually
having
random
clients
working
with
random
servers
that
what
you
said
will
turn
out
not
to
be
true
in
terms
of
the
push
server,
but
but
I
mostly
wanted
to
raise
a
flag
about
fate.
Sharing
here,
I
think
this,
like
the
authentication,
is
another
topic
that
needs
a
well-defined
interface
and
to
defer
the
solution
to
take
it
out
of
critical
path.
K
Likely
just
talking
about
where
push
working
group,
in
particular
I
think
most
of
their
work
is
done
and
they
about
to
close.
There
are
like
few
remaining
documents
going
through
his
G
review,
so
I
suspect
they
will
be
done
way
before
us,
so
referencing
their
specs
shouldn't
be
a
particular
problematic.
I
mean.
E
So
on
the
interoperability
point
with
this
there's
you
know:
there's
you
know,
you've
got
a
you've,
got
a
three-party
problem,
so
there's
interoperability
between
the
client
and
the
server
the
j-mac
client
in
the
j
map
server.
That's
you
know
the
key
thing
there
is.
You
have
to
have
a
client
to
identifier
and
the
client
has
and
then
the
client
will
get
something
out
of
band
and
the
client
has
to
know
how
to
use
what
it
gets
out
of
band
with
the
j
map
server
and
you
and
we've
defined
both
those
pieces.
E
So
that's
the
key
interoperability
thing
and
then
the
client
on
iOS
will
use
the
iOS
mechanism.
The
client
on
android
will
use
the
android
mechanism
and
the
people
operating
the
j
map.
Server
can
hook
it
up
to
the
right
mechanism
based
on
the
client.
So
I
think
you
do
get
interoperability
with
this
yeah.
E
C
It's
actually
very
simple
what
the
gemwraps
ever
does.
It
is
literally
just
making
a
post
request
to
the
URL.
The
client
gives
it
now
how
the
client
gets
that
URL
is
up
to
the
client
and
the
on
the
mechanism
it's
using
for
the
push,
what
pushed
over
its
using
and
that
kind
of
thing.
But
we
can't
and
should
not
define
anything
for
that,
because
that
entirely
depends
on
where
the
client
is,
whether
it's
on
iOS
or
on
o
in
a
browser
or
android
or
whatever.
A
Comment
from
sean
leonard
yep,
but
not
too
familiar
with
this
space.
But
what
if
this
Jamie
spec
defines
a
uniform
message,
type
message:
/j
mat
push
notification
or
application;
/j
mat
push
notification
that
is
packaged
and
encrypted.
According
to
the
relevant
push
mechanism,
then
the
web
push
/
iOS
push
modules
passed
that
to
the
Jay
map
Handler
to
deal
with
it.
A
C
C
I
C
Don't
think
this
is
as
complicated,
perhaps
as
we
is
kind
of
appearing,
because
there's
a
so
you
know
you
need
to
look
at
the
actual
specs
and
involved,
including
the
gemwrap
one.
What
we've
tried
to
do
is
make
it
very
simple.
Essentially
what
it
boils
down
to
is.
The
client
gives
the
served
a
map
server,
a
URL
when
something
changes,
the
server
posts
to
that
URL
and
the
way
it
posts
is
compatible
with
RFC
80
30.
C
If
you
want
to
use
web
push,
but
other
than
that,
you
can
forget
about
web
push
and
just
I
have
a
server
I
get
some
that
information
and
I
have
to
get
back
to
my
clock
to
the
client.
Somehow-
and
you
can
do
that,
however,
you
like
so
it's
it's
very
easy,
the
compatibility
as
as
was
mentioned
earlier
is
is
actually
crazy.
C
It's
just
how
do
I
handle
that
data
when
I
get
it
and
how
do
I
and
if
I
run
a
push
server,
it's
up
to
you
that
to
get
get
get
the
push
to
the
client,
so
I
think
yeah,
the
the
really.
The
only
thing
is
yes,
whether
you
have
to
encrypt
it
so
that
we
can
definitely
compatible
web
push.
So
if
their
specs
almost
done.
That
might
be
the
best
way
forward
and
you
can
always
decrypt
it
on
other
platforms
too.
C
Okay,
fine,
so
I
will
finish
amending
the
current
pull
request
proposal
on
this,
and
then
perhaps
people
can
review
this
further
on
the
list
when
they
have
a
had
look
through
the
actual
proposal
and
if
we
have
any
further
queries
we'll
go
from
there.
Okay,
let's
move
on
final
kind
of
worms,
the
transport
mechanism.
H
C
Sorry,
current
draft
on
recommendations
using
HTTP
of
why
you
might
not
want
to
just
tunnel
and
I
just
want
to
mention
briefly.
Why
I
think
in
this
case
it
actually
does
make
sense.
So
in
terms
of
caching,
because
this
is
all
kind
of
data
behind
a
login,
it's
all
sensitive
data
opener,
definitely
be
over
HTTPS
you're,
mainly
connecting
well
you're,
going
to
be
connecting
directly
to
the
J
map,
server
you're,
not
going
to
going
through
large
numbers
of
caches.
C
C
Partial
content
doesn't
make
sense
for
like
a
partial
bit
of
a
JSON
response.
It
makes
sense
for
your
binary
data
and
the
binary,
upload
and
download
is
all
very
standard
HTTP
and
you
can
of
course,
use
range
requests.
Everything
else
without
and
came
up
to.
This
is
just
for
the
API
request.
That's
tunneled,
versioning
extensions,
we've
spoken
about
I
think
we
need
guarantees
and
so
mechanism
to
what
to
be
a
good
fit
for
that
and
the
ability
to
interact
with
the
application
using
web
browsers.
C
We
can
certainly
build
a
full
gamut
client
in
a
web
browser.
I.
Guess
you
can't
just
stick
in.
You
have
to
send
post
requests
together
days.
So
in
that
respect
it's
slightly
more
difficult,
but
on
the
other
hand
you
can
just
use
curl
because
it's
tunneling
over
HTTP
and
that's
quite
nice.
So,
firstly
mark
you
want
to
say
anything
about
those.
N
Again
keeps
on
moving,
you
know,
I,
look
at
and
I've
just
started,
looking
your
stuff
and
apologize
for
that.
So
you
know
this
is
just
initial
impression.
I
think
that
you
know
the
intent
that
I
have
and
again
it
hasn't
been
adopted
by
anybody.
Yet
my
intent
in
BCP
56.
This
is
not
to
tell
you
know
people
you
can't
do
that
or
or
to
have
some
book
of
holy
law
of
you
know
how
thou
shalt
use
HTTP,
because
that
just
doesn't
work.
N
It's
just
more
to
make
sure
the
people
make
informed
decisions
when
they
you
do
use
the
HTTP
there
there's
some
stuff
in
the
draft
that
I'll
probably
file
some
issues
on
and
ask
for
changes,
but
it's
mostly
editorial
level
stuff
of
how
you
document,
how
you
use
HTTP
I,
don't
think
it
hopefully
won't
be
terribly
controversial,
but
the
the
the
tunneling.
You
know
the
batching
multiple
requests
over
over
as
I
understand
it
you're
doing
that,
because
you're
you're
not
just
batching
for
performance,
your
batching,
because
they're
semantically
dependent
yes,
there's.
C
N
N
M
C
N
You
know
I
subbed,
my
high-level
feedback
and
maybe
I'm
jumping
ahead
and
I
apologize.
My
high-level
feedback
is,
you
know,
I'll
file,
a
couple
little
issues
and
we
talked
about
that.
But
if
you
really
want
to
do
this
and
it
size
up
and
then
you
know,
I'm
not
gonna,
stand
in
the
road
and
say
no
because
I
don't
think
that's
appropriate
to
do
well,
a
little
surprised
that
this
group
got
chartered
to
put
everything
across
443
without
more
kerfuffle
I'm
interested
to
see
what
the
ops
people
are
gonna
say
about
that
but
I.
C
N
N
C
Yes,
although
just
saying
separate,
I
think
there
is
still
benefit
to
having
something
that
works
of
HTTP
1.1,
even
if
there
there
are
benefits
like
if
you're
not
getting
major
benefits
from
a
CP
2.
That
gives
you
so
much
easier
implementation
in
many
situations,
there's
many
more
platforms
that
support
it,
etc,
etc.
For
the
version
11.10,
that's
that's
not
really
what
I
want
to
go
through
here.
This
is
more
more
why
we
think
this
using
tunneling
works.
C
Well,
so
yes,
the
back
reference
is
one
of
the
things
is
that
you
can
create
one
object
and
then
refer
to
it.
Another
object
in
the
same
cool
and
importantly,
the
server
does
not
have
to
hold
any
state
between
the
different
requests.
You
don't
have
to
know
how
long
should
I
hold
this
state
in
case
I
get
the
following
requests,
but
I
don't
know
if
I'll
ever
get
it
back,
I
think
you've
either
got
all
your
references.
Will
you
do?
C
Similarly,
a
single
method
call
operates
on,
can
do
multiple
operations
on
the
same
data
type,
so
you
would
have
something
that
we
names
A
to
B
and
so
many
names
B
to
a
and
know
that
you
gonna
get
consistent
results.
If
you
had,
if
you
were
doing
this
with
multiple
things,
you
would
have
to
have
intermedius
and
you
don't
know
if
something's
gonna
fail
in
between
because
it
may
never
get
to
the
server.
Even
if
you
say
these
are
dependent,
you
may
not,
the
server
may
never
get
the
later
one.
For
whatever
reason.
C
It's
very
simple:
to
implement
clients
like
platformers,
we're,
saying
library,
supports
easy.
Debugging
is
really
easy
compared
to
multiple
concurrent
requests
and
trying
to
work
out
what
actually
happened
in
terms
how
they
received
atomic
fetch
from
multiple
sources
at
the
same
server
state.
If
I
asked
for
three
different
messages
in
a
single
method
request,
a
single
method
call
is
going
to
be
to
be
the
same
state
within
it,
and
so
I
will
get
back
consistent
State
for
those
three
messages.
C
That's
we
can't
go
into
atomic
State
between
even
between
method
calls
in
a
single
API
request,
which
is
a
single
ACP
thing.
We
don't
guarantee
atomic,
but
within
a
single
method.
You
do.
If
sorry
is
your
use
case,
they're
specifically
fetching,
for
example,
three
different
messages,
or
are
you
just
so
that
was
probably
a
poor
example.
It
was
more
just
that
within
a
single
method,.
N
B
C
So
it's
so
kind
of
the
summary
is
that,
yes,
the
we
think
for
this
situation,
what
we
are
doing
using
HTTP,
it
all
makes
a
lot
of
sense.
We
get
benefit
from
using
HTTP
rather
than
random,
other
TCP
protocol,
but
we
also
get
a
lot
of
benefits
from
batching
stuff
up
in
like
as
a
tunnel,
rather
than
necessarily
using
everything
as
a
separate
resource.
That's
something.
N
B
Takes
us
to
one
interesting
thing:
is
we
want
this
to
be
usable
by
developers
who
maybe
don't
have
much
skill,
and
so
certainly
they
Martin's
suggestions
last
night
of
ways
that
you
could
do
this
turned
out
to
be
a
lot
of
work
for
a
very
highly
skilled
developer,
rather
than
something
that
any
web
monkey
can
slap
together,
a
quick
little
tool
that
shows
them
some
informations
in
their
email?
That's
that's
an
interesting
challenge.
We
don't
need
you
don't
want
people
to
have
a
PhD
in
email
or
to
use
this
or
a
PhD.
N
C
Fine
you're
using
fast
that'll
be
good,
but
all
of
you
might
want
to
be
able
to,
but
I
think
more
general
point
is
by
even
things
like.
So
all
these
suggestions
use
some
of
the
more
complex
bases
to
be
most.
Those
capabilities
are
not
exposed,
for
example,
directly
in
the
browser
in
the
xhr
objects.
You
can't
interact
with
a
lot
of
sure
something
exit,
so
you
wouldn't
even
be
able
to
do
this
in
some
of
the
environments.
We
want
this
bill
to
operate,
ensure
I,
I,
said
I.
N
N
So
we
understand
your
requirements
more
and
feed
those
into
some
thinking
and
and
perhaps
an
extension
development,
and
it
might
be
that
our
timeline
for
those
extensions
exceed
what
you
need
and
you
won't
be
able
to
use
them,
but
it'd
be
great
to
have
your
input
and
feedback
just
so
we
understand-
and
it
might
be,
that
if
we
can
come
up
with
some
proposals
that
are
more
modest
to
make
it
a
little
more
well
aligned
with
HTTP
as
commonly
used.
That
would
be
good
to
talk
about
too,
but
I.
N
C
Oh
yeah,
we
know
this
method
works,
it's
been
tested
in
various
situations.
There
were
multiple
companies
even
running
this
style
thing
now
so
yeah,
it's
something
to
be
said
for
a
kind
of
a
system
that's
being
proved
rather
than
something,
that's
ideas
that
we
may
be
able
to
implement
in
the
next
year.
A
Comment
from
Sean
I
would
like
to
see
see
more
support
in
j-mac
core,
using
the
same
data
model
that
is
rather
than
submitting
an
accepting
application.
Json
application,
SIBO
or
would
also
be
defined
since
Sieber
is
a
superset
of
JSON.
It
should
be
an
easy
thing
to
add
and
support
results
in
increased
efficiency
on
the
wire,
both
ways
not
proposing
Seaboard
specific
data
model
elements
at
this
time.
N
D
Jeff's
epic,
so
one
one
thing
about
the
whole
caching
thing:
if
and
I'm,
not
saying
that
rest
is
great
I'm,
not
saying
that
what
he
proposes
is
bad
there.
The
caching
I
think
it
would
be
nice
to
be
able
to
have
the
brown
at
the
browser
itself
be
able
to
cache
the
bits
and
pieces
that
it
gets
from
the
server
so
stupid.
One
well
like
the
scenario
stupid
web
mail.
Javascript
thing
right,
you
close
the
browser.
C
If
you're
building
a
good
webmail
these
days,
you'd
want
to
do
the
caching
yourself
with
indexdb,
to
be
honest
with
you,
I
would
say,
and
the
and
you
just
don't
have
an
utter
control
of
the
occasion.
Validation
like
your
performance,
wins
are
not
gonna,
be
enough
to
offset
the
performance
losses.
I
think
that
you
get
from
the
changing
model,
because
it
would
still
have
to
revalidate
that
with
the
server
basically
every
time,
because
you
can't
tell
the
browser
cache
to
only
invalidate
when
you
get
a
state
string
push
from
the
server,
but.
D
As
far
as
I
know,
it
is
fairly
common
for
ISPs
to
set
up
their
deployment
in
multiple
tiers,
where
the
the
hosts
that
actually
store
the
emails
do
not
actually
have
internet
access,
and
there
are
two
levels
of
proxies
going
in
the
SSL
session
that
the
LS
sessions
are
terminated
at
the
border
and
inside
there
the
end
the
data
center.
It's
all
clear
text
which
presents
itself
to
all
sorts
of
wonderful
caching,
which
you
would
get
for
free
by
just
using
basically
reverse
proxies
with
HTTP,
with
the
list
of.
D
J
map
methods-
you
don't
get
that
you
sure
you
get
it
for
it
blobs,
but
I
guess
I'm
just
looking
at
this
and
going
so
you
want.
What
really
is
what
it
is
that
you're
proposing
is
an
our
email
fetching
on
top
of
an
RPC
mechanism
using
JSON
using
HTTP
using
TLS
I'm.
Just
thinking
do
we
need
another
RPC
mechanism.
D
L
Keith
more
in
response
to
the
commenter,
who
suggested
using
C
borer
is
an
alternative.
I
would
like
to
strongly
recommend
that
exactly
one
presentation,
layer,
B,
Bush
or
B,
be
part
of
this
protocol.
I,
don't
think,
there's
a
real
unfortunate
tendency
in
IETF
and
elsewhere.
I
think
the
sort
of
support
you
know
every
flavor
and
that's
not
a
good
thing
for
either
interoperability
or
for.
L
N
C
H
C
C
N
A
C
C
C
Some
of
some
of
the
nice
things
by
HTTP
is
just
is
completely
bippity
means
it
has
better
support
in
some
platforms
so
like
talking
to
Apple
and
I,
also
alphas.
They
have
a
lot
of
stuff
built
at
the
operating
system
to
coalesce
HTTP
requests
to
be
more
efficient
with
the
battery
usage
sure,
whereas
WebSockets
I
don't.
C
F
F
You
know
in
in
everything
in
a
very
restful
manner,
but
then
also
provide
for
the
cases
where
multiple
operations
do
need
to
be
batched.
To
avoid
those
extra
round
trips
that
do
really
impact
client
performance
over
IMAP
I
know
there
are
some
api's
that
offer
this
kind
of
dual
mode
of
operation.
For
example,
the
Google
Drive
REST
API
offers
a
batch
endpoint
where
you
can
post
a
multi-part
mixed
content,
type
request
to
a
batch,
API
endpoint,
but
all
the
other
you
know,
and
everything
else
can
still
go
over
regular
HTTP.
F
C
Think
something
we've
talked
about
a
little
bit
but
not
considered,
perhaps
deeply
a
proposal,
I
think
what
what
we
will
be
interesting
to
see
there
would
be
yes,
I'm
I
think,
because
what
you
don't
want
is
to
have
to
define
every
time
the
second
different
way
of
doing
it.
But
if
you
could
come
up
with
a
generic
mapping
of
saying
this
is
an
alternative
way,
you
can
just
use
an
HTTP
resource.
This
is
how
you
get
it's
your
I
for
this
component.
Then
I
guess
the
main
question
will
be.
B
F
I
think
that,
from
a
strictly
functional
perspective,
I
agree
with
most
of
the
contents.
That's
already
been
discussed
that
there
isn't
actually
a
huge
functional
benefit,
I
think
from
a
stylistic
perspective,
it'll
be
more
approachable
to
developers
for
the
first
time,
if
everything
is
a
little
bit
more
HTTP
like
I
also
am
not
convinced
that
the
tunneling
is
necessarily
going
to
provide
a
lot
of
performance
benefits
in
the
vast
majority
of
scenarios.
C
Okay,
I
think
one
of
the
issues
there
is
how
is
when
your
this
is,
where
you
probably
have
to
have
http/2
and
ATP
to
push
to
make
this
really
work,
because
so,
in
your
scenario
of
eye-opener
I'm,
app
and
I
want
to
get
updates
in
gem.
There's
a
single
ethical,
get
message
list
updates,
which
you'd
say:
here's
my
I'm
getting
updates
on
my
inbox
say:
here's
my
last
state
and
it
would
return
you.
C
Here's
you've
added
messages
at
position,
0
and
1,
and
this
is
their
IDs
now
in
j-mac,
you'd
also
pass
a
flag
to
the
cool
to
say:
Ashley
I
want
to
fetch
those
messages
as
well.
At
the
same
time
and
here's
the
properties
I
want
on
those,
and
so
you
make
a
single
request.
You
get
a
single
thing
back
so
with
HTTP.
C
Each
of
those
message
has
to
be
different:
the
source,
presumably,
if
we're
gonna,
make
this
map
cleanly,
so
you'd
have
to
have
a
teepee
to
push
to
be
able
to
presume
that
you
wanted
to
fetch
those
resources
as
well
and
return
those
responses
when
what
you
were
really
fetching
initially
with
the
URL
was
just
the
give
me
updates
to
list
what
are
the
new
IDs,
because
otherwise
you'd
have
to
wait
for
the
IDS,
come
back
and
then
make
the
fetch
to
those
IDs.
So
then
you'll
back
to
at
least
two
round-trips
again
with
ATP.
C
But
if
you
had
push
from
A
to
B
to
then
you
could
potentially
presume
the
client
wanted
those
or
have
the
client
able
to
indicate
that
and
return
those
responses
as
well
so
I
think
it's
doable.
I,
just
I
think
the
biggest
reason
to
have
a
way
of
doing
this
is,
as
Neil
sang
it's
more
approachable
to
developers
and
may
make
it
easier
for
new
people
to
adopt
I
think
the
current
version
is
better
on
the
whole,
from
a
technical
point
of
view,
it's
likely
to
result
in
better
network
usage
and
I,
so
I
think.
C
Maybe
we
should
look
into
if
there's
a
mapping
that
we
can
create,
and
so
this
can
provide
both
and
whether
then
I
said
that
the
question
is
just
kind
of.
Is
that
possible
to
do?
Probably?
If
so,
what
how
complex
is
that
implement
and
should
service
be
made
from
both?
Was
that
an
optional
thing
and
what
issues
arise
from
that?
C
C
We've
only
got
ten
minutes,
but
luckily
this
is
not
too
much
do
interesting
things
I
thought,
we'd
bring
up,
feel
free
to
file
more
tickets.
If
you
see
issues
or
bigger
issues,
obviously
discuss
on
the
main
list,
but
just
a
few
interesting
things
Lexy
raised
this
ticket
question
of
when
you
get
through
updates.
So
what
this
is,
if
you've
not
seen
Jarrett
for
is
I
have
a
type
through
and
saying
since
my
last
state
give
me
the
IDS
of
things
that
have
changed
within
this
type,
so
at
the
moment
it
so
it
returns
on.
C
He
says
these
have
been
changed,
which
means
either
created
or
updated
modified
and
these
IDs
have
been
destroyed,
obviously
the
destroyed
ones.
The
client
never
needs
to
fetch.
So
it's
helpful
to
have
those
separate
at
the
moment
created
and
updated
all
together.
You
just
get
a
single
set
of
ID's
that
are
changed.
C
The
main
reason
for
this
is
it's
easier
for
the
server,
because
it
doesn't
have
to
keep
know
when,
whether
you,
when
you
saw
it
to
know
whether
it's
been
created
or
updated
and
for
the
client,
it
shouldn't
make
much
difference,
because
if
it's
got
it,
it
needs
to
refresh
it
doesn't
have
it.
It
doesn't
matter
whether
it
was
updated
or
created.
C
C
C
You're
you're,
comparing
getting
changes
on
an
object
to
getting
changes
on
a
query
which
is
like
a
message
list,
which
is
a
query
on
the
message
type
and
that's
where
it
tells
you
as
tell
you.
This
has
been
added
to
your
query,
and
this
is
the
index
you
insert
it
at,
and
this
is
removed.
So
they
are
consistent
is
just
the
difference
between
okay.
C
Okay,
I'm
just
got
one
more.
This
is
yeah
interesting
to
you.
So
what
to
do?
If
you
try
to
destroy
a
mailbox
that
company
has
messages
in
it.
So
at
the
moment
the
spec
says
you
just
can't
do
it.
It's
an
error.
Just
allows
it
upside
sleep
more
days
across
more
effort
downside
you
also,
you
have
to
actually
explicitly
move
each
message
from
the
mailbox.
If
you
want
to
do
it.
C
So
there
are
other
alternatives
here,
though,
are
it
just
removes
it
automatically
from
the
mailboxes
of
us?
That's
right.
The
other
issue
with
this
is
so
J
map
supports
the
the
possibility
of
multiple
mailboxes
for
a
message.
If
you
want
to
ever,
can
support
that.
So
what
happens?
If
you
only
have
that
mailbox
left
in
the
message
that
actually
then
deletes
the
message,
rather
than
just
leaving
in
one
of
the
other
mailboxes
one
of
the
earlier
drafts
we
have
with
J
map,
moved
it
to
the
inbox.
C
If
it
was
the
last
one,
but
that's
even
weirder
yeah,
you
definitely
don't
that
so
I
guess
just
general
opinions
on
what
what
you
should
do
here,
whether
it
should
be
an
error
should
be
allowed
what
it
should
do
and
whether
kind
of
slightly
state
take
a
step
back.
Should
it
be
possible
to
have
a
message
with
0
mailboxes,
but
that's
still
in
the
system
is
not
deleted,
which
kind
of
is
no
I
mean
that
makes
high
map
support
harder,
actually
harder,
it's
kind
of
closer
to
the
gmail
model
in
some
ways.
C
A
As
not
these
guys,
Barry
I
I
see
it
as
maybe
you
warn
the
user
that
there
are
messages
in
the
mailbox.
Do
you
really
want
to
delete
it,
but
it
is
convenient.
Sometimes
I
have
messages
that
I've
accumulated
for
a
particular
purpose.
I,
don't
need
them
anymore.
I
delete
the
whole
batch
in
one
thing:
I
don't
need
to
do
transactions
to
delete
every
message
and
I
don't
want.
K
A
K
A
E
Chris
Newman
I'll
pre
fix
this
by
you
know,
I'll
be
happy
with
whatever
we
do
here,
but
I
think
I
think
there
is
a
you
know:
I'm
afraid
the
better
option
is
the
most
complex
one
and
what
I
leaned
towards
is
there's
a
deli
mailbox
method
with
an
optional
argument
that
says:
ok
to
delete.
If
it
has
messages-
and
you
know
I'm
sorry
I
know-
that's
that's
more
complicated,
but
why
I
would
suggest
this
is
the
knowledge
that
you're
removing
the
mailbox
and
the
messages
at
the
same
time
as
useful
knowledge
for
server
management,
I.
C
C
Yet
we
have
an
if,
in
the
state
option
with
set
stuff,
which
basically
says
only
apply
this
command
if
the
state
on
the
service
count
in
same
as
in
my
client
like
if
something
may
have
changed
in
between,
like
you
may
have
appended
message
to
this
abort
the
operation,
so
that
guarantees
then
that
you
know
it
had
no
messages
and
you
told
the
server.
It
must
be
the
same
state
for
you
to
delete
this
so
I.
Don't
actually
think
we
need
a
separate
custom
command.
C
C
E
I
leaned
that
way,
because
you
know
where
it's
where
it's
interesting
is
you
know,
servers
generally
have
to
have
some
mechanism
to
deal
with.
You
know
user
requests
where
they
accidentally
deleted.
Something,
and
you
know
two
separate
operations
of
moving
the
messages
to
the
trash
and
then
deleting
the
folder
that
creates
a
different
recovery
model
from
delete
the
messages
in
the
folder.
At
the
same
time
that
you
can
you
can
do
that
shortcut
on
recovery
of
the
folder
reappears
with
all
the
messages?
That's
so
it's
a
server
bag,
yeah.
H
B
Another
table,
which
is
very
much
a
SQL
style
constraint.
You,
a
foreign
key
constraint,
requires
this
idea
to
be
present,
and
then
you
can't
delete
the
mailbox.
While
is
still
something
refers
to
it.
That's
that's.
The
decision
we're
making
here
is,
which
philosophy
do
we
have
for
mail
box
message,
membership.
E
B
C
C
G
C
I'll
think
about
that
one
maybe
pay
something
hope
to
get
back
sounds
like
probably
will
change
that
to
remove
the
messages
and
let
you
do
it
rather
than
Harry,
okay,
very
quickly.
Oh
yes,
this
is
ammonia.
We
saw
the
datatype
the
keywords
we
saw.
It
mapped
from
a
keyword
named
true,
there's
question
about
why
that,
rather
than
a
list
and
because
it
makes
easier
to
patch,
especially
the
answer
currently
mailbox,
IDs
is
just
list.
C
So
really
they
need
to
be
aligned,
I
think
as
a
data
format,
because
they're
both
kind
of
the
same
thing,
it's
a
list,
it's
a
set
of
metadata
things
you
can
add
and
remove
them
and
there's
no
ordering
and
you
want
to
be
able
to
patch
it
rather
than
have
to
replace
the
whole
set
at
once.
So
it's
more
just
just
yes
does
that
make
sense,
people
or
any
comments
on
the
use
of
a
set
kind
of
thing.
Mappings,
true
name.
C
B
The
last
slide
here
was
other
business,
other
github
tickets
of
interest.
We
don't
have
time
to
look
at
them
now,
but
we
should
go
through
that
and
discuss
on
the
list.
All
the
tickets
are
currently
open,
so
I
will
open
it
thread
for
each
ticket.
That
looks
like
it
has
some
discussion
worth
doing
on
the
on
the
list,
so
we
can
deal
with
it
there
suggestion
of
doing
a
hackathon
on
J
map
in
Singapore.
A
B
A
Okay,
then
the
ietf
hackathon
started
a
while
ago,
and
there
the
thing
on
Saturday
and
Sunday
before
the
IETF
meetings
so
plan
your
travel,
so
you
arrive
sometime
Friday
have
a
little
recovery
and
pop
into
the
hackathon
it.
It
goes
from
9
a.m.
to
9
p.m.
on
Saturday.
You
don't
have
to
be
there
the
whole
time
and
from
9
a.m.
to
about
4
p.m.
B
Got
a
specific
item
there
for
testing
as
well.
We
have
to
start
our
test
framework,
forge
a
map
and
that's
one
of
the
goals.
The
next
little
while
is
to
have
some
fast
mail
people
work
on
flashing
that
out
so
that
we
can
actually
test
other
server
implementations,
at
least
for
compliance.
Client
testing
is
always
a
little
bit
trickier
because
there's
all
the
user
interface
side
of
things
with
the
server
you
can
more
check
that
it's
complying
with
what
you're
expecting
I'll
put
a
note
for
calendar
contact.
Future
extensions.