►
From YouTube: IETF104-JMAP-20190325-1450
Description
JMAP meeting session at IETF104
2019/03/25 1450
https://datatracker.ietf.org/meeting/104/proceedings/
A
B
Pointing
out
that,
from
my
point
of
view,
not
the
responsible
ad
for
this
one
but
from
my
point
of
view
it's
more
than
helping
out
it's
inappropriate,
I
think
for
Braun
to
be
the
only
chair
given
his
company
affiliation
and
you
know
I
trust
Braun
completely,
but
from
Optics
we
need
somebody
else.
Yeah.
C
B
D
Right
mideco
is
up,
people
are
in.
Thank
you,
remote
participants.
Thank
you.
People
who
are
here
here
is
the
note
well
again
for
those
of
you
who
have
come
in
recently.
Please
note
it
well,
starting
with
a
thank
you
to
Barry
for
for
your
time
and
your
mentoring
here,
I
very
much
appreciate
it.
I
look
forward
to
to
my
new
co-chair
when
we
find
one.
D
E
Don't
really
have
a
lot
to
say
other
than
I
believe
yeah.
We've
resolved
all
the
issues
they're
both
quad
mail
in
the
editor
q,
thanks
very
much
to
everyone
that
provided
feedback
and
all
the
tremendous
amount
of
work.
The
way
into
it
and
I
think
we've
ended
up
with
two
fantastic
documents
and
looking
forward
to
those
finishing
the
final
stages
being
published
and
seeing
people
I
think
this
is
a
big
improvement
on
we
had
before
so
I
just
want
to
say
thank
you
that
speed
invoke
about
yeah.
D
C
So
there's
been
a
few
changes
in
the
last
month
since
Bangkok,
first
of
which
we
now
identify
each
object,
that
the
compass
server
says
that
a
client-
this
is
related
to
the
third
item,
which
is
we
now
allow
push
over
the
WebSocket,
and
we
additionally
allow
out
of
order
processing
of
the
requests
next
slide.
Please
so
in
terms
of
identifying
each
object,
the
state
tames
object
already
had
a
type,
so
we've
leveraged
that
and
added
that,
to
the
response
object
and
to
the
problem.
Details
object
next
slide,
please
so
for
automotive
processing.
C
Next
slide,
please,
okay,
push!
This
takes
the
form
of
the
existing
state.
Change
object,
that's
already
in
core.
The
only
open
issue
with
this
is
how
the
server
should
advertise
support
and
how
the
client
enables
push
and
selects
which
push
notifications
that
they
would
like.
The
current
draft
I
leverage
what
is
already
documented
for
event
source
there's
a
type
query
parameter
on
the
URL.
That's
used
to
bootstrap
request
Neil
had
suggested
that
he
might
want
I
have
a
separate
object
for
this,
so
I'll.
Let
Neil
discuss
that
as
soon
as
I'm
done
here.
C
The
other
issue
which
this
comes
up
in
the
events
or
stuff
with
a
eventsource.
When
the
client
enables
notifications,
they
can
give
the
server
its
last
known
state
and
the
server
can
quickly
resync
with
a
bunch
of
notifications.
So
my
question
is:
do
we
want
to
do
something
similar
over
WebSockets,
the
only
I?
C
Guess
it's
not
only
a
downside,
but
the
only
new
behavior
the
server
would
have
to
have
would
be
basically
server
wide
token,
for
that
particular
account
so
that
when
it
comes
back
and
knows
what
width
of
the
sink,
this
would
most
likely
be
sent
on
each
push
notification.
So
the
client
has
its
last
known
state.
So
that's
one
of
the
open,
open
questions.
Neil.
Do
you
want
to
say
anything
about
using
a
new
object.
E
E
You
call
a
method
and
say
from
now
on
this
WebSocket
sends
me
push
notifications
state
changes
for
these
object
types
that
might
make
sense.
It's
a
bit
weird
in
some
ways.
It's
a
method
called
acting
on
your
connection
rather
than
on
any
actual
data
back
in
server,
but
then
again,
push-up
scription
is
also
slightly
weird
and
that's
acting
on
your
kind
of
session
ish
I
I,
don't
I'm
not
hugely
sold
on
either
approach.
D
C
Back
yeah
thanks
Neil,
so
I
don't
have
any
strong
opinions
either
way.
I
took
the
path
of
least
resistance
with
what
I
currently
documented,
but
I
am
totally
open
to
whatever
consensus
is
in
terms
of
which
way
we
want
to
go.
I
guess
that
one
plus
of
doing
as
a
new
object,
as
as
Neil
said,
you
can
change
this
in
flight
without
having
to
close
down
the
socket
and
reconnect.
C
If
we
do
this
as
no
object,
presumably
we
would
advertise
support
for
push
in
the
capabilities
response,
which
is
no
big
deal.
We
already
have
the
WebSocket
URL
listed
there,
so
this
would
just
be
a
probably
a
boolean
that
says
what
we
not
be
either
supported
or
not,
or
we
can
list
the
type
of
notifications
that
the
the
service
kick.
The
world
return.
E
E
D
E
D
C
D
E
D
A
D
C
Service
currently
supports,
basically
all
the
API
stuff.
The
only
thing
I
have
not
implemented
yet
is
the
push,
because
it's
still
one
state
of
flux,
cool,
okay!
That's
it
that's
it!
For
this
slide.
There
is
one
more
slide.
Does
anybody
care
about
even
looking
at
different
compression
algorithms
for
WebSockets
or
just
stick
with
deflate.
A
C
A
C
A
C
A
D
E
Just
wanna,
say:
I,
don't
think
impression.
Stuff
is
part
of
our
spec,
like
that's
a
WebSocket
protocol
thing,
as
Ken
said,
there's
already,
the
deflate
defined
I'm
having
others
define
could
be
interesting,
but
it
should
be
nothing
to
do
with
an
hour
specification
that
should
just
be
up
to
the
server
the
clients
in
the
go
shape,
which
WebSocket
extensionism
capabilities
they
support
and
then
pick
the
best
compression
method
that
they
both
support.
Like
that's,
this
would
be
like
saying
which
compression
method
we
want
for
HTTP
responses
in
the
core
spec
that
doesn't
seem
appropriate.
Oh.
A
Yeah
I
agree.
That's
that's
partially.
Why
I
said
you
know
this
is
margin
generic
question,
but
for
cases
of
fancy
standard
they
are
not
even
defining
for
WebSockets.
So
a
more
general
question
is:
do
people
want
to
get
involved
with
trying
to
figure
out
how
to
define
this
but
again,
I
think
we'll
need
if
people
want
to
experiment
and
see
how
much
benefit
there
is
actually
from
compression
of
different
things
using.
E
C
D
You
that's
everything,
that's
everything
great
thanks.
Again,
let's
go
back
to
the
chair,
slides
and
MDN
I,
don't
have
any
slides
for
this.
The
the
draft
was
updated
based
on
feedback
from
last
meeting.
I
suggest
that
we
asked
for
some
implementation
experience.
I
checked
with
the
leg
or
are
they
are
running,
something
that's
very
similar
to
it,
but
not
entirely
updated
to
the
the
latest
message:
submission
standard,
so
they're
not
doing
the
message
submission
part
of
it.
I
think
we
should
try
and
implement
it,
get
a
second
implementation
up
and
running
before
publishing.
F
D
I
will
ask
Ken
and
Robert
to
implement
it
in
Syrus,
so
we
can
test
it
there
and
it
will
have
a
second
implementation
of
it
and
we
can
give
feedback
on
implementing
from
the
draft.
I
think
that'll
be
a
good
point
to
then
go
to
publication
if
a
second
implementation
works
well
you'll
have
that
okay
cool!
D
We've
finished
Corrin
male
talking
to
Alexia
about
what
to
do
with
the
Charter.
We've
agreed
not
to
throw
everything
in
all
at
once.
Maybe
we
just
start
with
calendars.
Maybe
we
reach
other
for
calendars
and
contacts,
knowing
that
the
contact
form
at
still
needs
to
find
a
home,
any
particular
opinion
on
what
to
do
there.
Should
we
just
just
do
calendars
now.
A
D
A
D
D
E
E
A
C
D
D
E
E
If,
yes,
that's,
probably
considerably
more
difficult
to
implement
or
might
be,
it
would
be
more
difficult
implement,
because
you
have
to
notify
that
the
email
has
changed
with
the
you
know
the
update
mechanism
whenever
it
goes
in
or
out
of
a
virtual
mailbox.
That
can
be
very
hard
to
know
how
complex
the
virtual
mailboxes.
E
If
you
define
that
it's
not
going
to
be
inside
that
mailbox
IDs
bit
of
the
email,
then
this
is
something
the
same
as
save
search,
something
we
actually
have
a
fast
mail
and
basically
it
becomes
fairly
straightforward.
It's
just
kind
of
saving
the
filter
object
that
you
use
with
email
query
already
and
associating
that
with
a
name
and
saying
display
this
as
a
mailbox,
because
emails,
open,
opening,
email,
box
and
being
the
content
is
nothing
special
compared
to
research
in
J
map.
It's
just
a
simple,
simple
email
search
query.
A
Right
Alexi
here
we
spent
numerous
hours
in
I'm
a
plant
trying
to
make
virtual
mailboxes
work,
so
I
think
I
think
there
is
use
case
for
this
and
I
tend
to
agree
that
actually
associating
it
with
a
different
object,
like
filter,
might
be
easier
way
and
to
implement
for
everybody.
So
that
sounds
like
a
sensible
direction.
Yeah.
E
A
E
D
D
E
A
A
There
was
a
very
simple
extension
for
showing
just
status
of
I
spy
and
signature
verification,
but
this
can
be
built
on
top
if
you
want
to
deal
with
sending
side
of
things
and
assume
that
you
trust
the
server
with
the
keys
and
but
these
are
probably
sort
of
the
signature,
verification
one
is
straightforward
and
probably
is
it
well,
it's
definitely
easy
to
implement
and
it's
more
likely
to
be
implementable,
where
the
sending
side
is
probably
at
least
separate
capability.
Yeah.
D
D
D
D
A
B
E
I
guess
it's
possible
I
think
the
yeah.
The
main
thing
is
just
working
out:
how
we
do
the
scheduling
and
how
much
we
want
to
define
in
that
document.
I
think
one
of
the
tools
were
the
existing
specifications,
for
this
is
they
are
completely
intangible,
and
so
people
give
up
trying
to
base
the
implementation
on
those
and
just
try
and
copy
what
they
seem
to
see
going
around.
E
E
So
it
might
be
nice
if
we
could
do
a
similar
thing
with
the
Gemma
calendar
spec
in
terms
of
actually
making
it
understandable,
which
I'm
it
messages
should
be
sent
when
and
we
plan
to
make
them
all
explicit
to,
but
because
we
don't
that
I'm
not
quite
sure
how
much
work
that
is
right
now
and
I,
don't
know
exactly
when
we'll
get
to
it.
So
you
know
December's
a
fairway
offer,
it
could
be
done,
but
I
don't
know
necessarily
was
definitely
other
than
my
life
I'll.
D
Websockets
and
mdn
I've
put
md
info
just
in
brush
as
well:
yeah,
okay,
I'll
put
mdn
in
September
just
for
fun,
just
for
a
ruff-ruff
place
and
WebSockets
same.
We
should
have
the
first
two
I
feel
their
way
along
already
cool.
Alright
I
will
update
the
milestones
based
on
that
plans
for
what
we
want
to
do
in
Montreal
I
mentioned.
We
will
have
enough
to
talk
about
to
meet
again
in
Montreal.
There's,
there's
documents
in
progress.