►
From YouTube: IETF108-JMAP-20200730-1150
Description
JMAP meeting session at IETF108
2020/07/30 1150
https://datatracker.ietf.org/meeting/108/proceedings/
A
Thursday,
more
than
halfway
through
this
first
real
multi-track
virtual
meeting,
this
is
the
agenda
that
we
have
so
far.
Is
there
any
agenda
bashing?
Does
anybody
wish
to
speak
about
anything
else
or
reorganize?
Any
of
this
give
you
a
moment
to
do
that.
Nobody
needs
to
do
blue
sheets,
of
course,
which
gets
rid
of
one
of
our
annoyances.
It's
all
automatic
all
right
with
that
said.
A
B
Cool,
yes,
so
j
map
calendars
so
since
last
time
I've
added
the
basically
action
all
the
things
that
we
agreed
last
time
we
met,
which
was
a
while
ago
now,
which
has
added
in
a
few
new
features,
mainly
the
stuff
about
allowing
invitees
to
invite
other
guests
and
allowing
people
who
have
access
to
share
calendars,
to
add
themselves
to
events
being
able
to
give
permission
for
that.
B
B
We've
got
the
calyx
session
tomorrow,
so
hopefully
we'll
have
that
done
very
shortly,
which
is
the
kind
of
data
model
underneath
and
then
jmat
calendars
is
nearly
ready,
but
waiting
on
some
implementation
experience
mainly
once
we've
got
that
I'll,
also
flesh
out
a
load,
more
examples
which
will
be
easier
when
we
have
implementations,
because
I
can
just
use
those
to
copy
and
paste
the
json
and
then
you
don't
mess
up
as
you
do
by
hand
and
some
tidying
up
to
do
at
that
point.
B
But
so
that's
kind
of
the
stages.
It's
a
bit
blocked
really
on
implementation.
The
in
terms
of
other
s,
stuff,
there's
one
other
thing
I
mentioned
is
the
I
calendar
and
cal
devon.
Has
this
formal
delegation
system
where
you
can
invite
someone
to
an
event
and
then
they
can
formally
delegate
their
attendance
to
someone
else
and
there's
a
whole
handshake
of
sending
to
the
organizer
into
the
tea
and
stuff?
B
I
am
intending
to
leave
that
out
and
we
can
add
that
as
an
extension,
if,
if
people
actually
want
to
do
it,
my
impression
is
that
that's
less
used
mainly
these
days
and
the
new
abilities
which
aren't
in
the
original
card,
I
have
to
just
add
other
people
is
much
simpler
and
is
normally
quite
sufficient
and
that's
more
what
we
see
in,
like
google,
calendar
and
facebook
events,
and
that
kind
of
thing
it's
just
much
simpler
people
understand
and
you
normally
don't
need
this
whole
formal
delegation
system.
It's
just
yeah.
B
I
can't
go
but
I'll
add
someone
else
the
event
whatever.
So,
basically,
if
anyone
objects
to
that
and
thinks
they
should
be
part
of
the
core
spec
rather
than
left
to
an
extension,
should
someone
want
it?
Let
me
know,
and
that's
it
any
questions,
comments
on
status
or
other
stuff
to
regenerate
calendars.
A
B
A
B
Yeah-
and
I
think
that
is
an
interesting
use
cases,
so
this
is
worth
considering.
That's
that
could
work
quite
nicely.
It's
certainly
definable
the
downside
is,
it
does
get
slightly
more
complex
because
if
your
event
says
use
default
alerts
and
it's
in
two
different
calendars
with
two
different
sets
of
default
alerts,
then
you
have
to
kind
of
merge
those
together
for
that
event
again
doable,
but
just
slightly
more
complicated
yeah.
A
Certainly,
in
that
use
case,
it
would
be
an
alert
that
sends
to
each
per
each
calendar
would
have
the
alert
for
that
person.
I
guess
for
display
that
might
be
a
bit
weird.
I
guess
yeah,
but
often
each
person
would
only
be
looking
at
one
calendar
anyway,
so
they
might
only
get
the
alerts
for
their
own.
B
That's
true
for
that
particular
situation.
Yeah
yeah!
I
am
coming
around
to
this
idea
a
bit
more.
I
was
not
particularly
keen
in
previous
meetings.
If
the
minutes
were
probably
show,
I
think
the
probably
the
biggest
disadvantage
is
just
simply
that
I
don't
know
it's
it's
all
the
existing
calendar
systems.
B
I
know
don't
allow
it
and
therefore
it
makes
the
implementation
a
bit
more
of
a
challenge
because
it's
going
to
map
not
quite
as
closely
but
we
can
we'll
probably
do
what
we
did
in
mail,
which
is
you
allow
it
in
terms
of
the
spec.
B
But
you
allow
the
server
to
say
the
maximum
number
of
calendars,
an
event
can
be
in
and
you
can
always
set
it
to
one
if
it
doesn't
want
to
support
this
basically,
so
then
the
server
doesn't
have
to
spoil
this,
but
it's
in
the
approach,
that's
what
we
have
in
mail
and
that
seems
reasonable,
yeah.
Okay,
anyone
else
got
comments
on
on
this.
Anyone
know
what
we're
talking
about.
C
Ken
go
ahead;
this
is
ken.
My
concern
is:
how
does
this
gonna
interoperate
with
scheduling?
B
C
B
B
A
B
I
do
like
the
symmetry
box
ids.
It
does
yeah
make
that
anita
more
consistent,
all
right
I'll.
Look
at
that
as
it
doesn't
seem
too
many
objections,
unless
I
think
of
some
other
reason
why
it's
not
going
to
work
when
I
start
documenting
it,
but.
B
I
said
I
think,
hopefully
we'll
get
some
implementation
of
of
respect
in
the
next
few
months
and
we'll
be
able
to
then
go
from
there
cool
all
right.
A
A
Leave
up
in
the
top
left,
or
I
can
just
kick
you.
E
So
hello
next
slide,
please
so
for
js
contact.
We
we
had
discussed
in
the
interim
mainly
about
adopting
the
vcard
mapping
that
mario
has
been
mostly
working
on
in
the
in
the
last
in
the
last
weeks.
I
see
mario
was
here
so
please,
please
jump
in
mario
whenever
you
deem
appropriate.
E
So
this
document
is,
in
my
understanding
very
very
far
already.
There
are
only
very
few
spots
that
still
need
some
sorting
out
of
mapping
between
between
vcard
and
the
js
contact
format
that
we
propose,
which
is
contact
formatter
in
for
chairs
contact
for
the
data
model
itself.
There
hasn't
been
much
progress
itself.
That's
mainly
on
me
still
being
been
working
on
the
js
calendar
topic.
From
our
last
session
we
had
a
we
had
a
look
at
for
we
they're
still
open
to
define,
probably
a
other
address
format.
E
There's
still
the
idea
to
check
what
the
iso
group
is
doing
in
terms
of
address
profiles,
I
still
have
still
don't
have
a
clear
picture
on
on.
What's
the
state,
the
stair,
an
alternative
that
that
that
might
be
interesting
is
that
what
we
did
for
names,
which
also
had
the
issue
of
being
originally
defined
in
a
in
a
western-centric
format
and
where
we
basically
now
are
using
an
array
of
of
typed
name
properties,
and
this
allows
way
more.
This
allows
way
more
different
structures
in
name
than
than
original.
E
This
might
also
come
useful
for
addresses,
so
basically
you
we
define
an
ordered
list
of
building
blocks
of
typed
building
blocks
of
an
ad
of
address
strings.
If
you
want
to
get
to
the
full
address
you
just
concatenate
the
complete
list,
but
still
since
the
blocks
itself
are
typed
like
street
or
municipal
or
whatever,
you
can
still
pull
out
the
the
metadata
about
each
string
component.
I
I
get
I
I
I
think
we'll
look
more
into
that.
E
If
it's,
if
it's
useful
and
then
tandem
also
will
look
more
into
the
iso
address
group
formats,
which
brings
me
already
to
the
next
slide.
Please.
E
So
basically,
the
next
steps
I
see
for
this
for
this
effort
is
that
want
to
look
into
addresses.
The
other
is
revisiting
the
way
we
organize
the
data
within
js
content.
I
think
we've
pretty
much
nailed
down
all
that
we
want
to
cover
and
the
mapping
document
that
was
mentioned
before
is
it's
giving
us
if
it's
giving
us
a
kind
of
certainty
that
we
are
not
missing
approach
stuff
from
vcard.
E
However,
looking
at
the
mapping
in
in
the
in
the
wire
representation,
there
is
a
whole
bunch
of
properties
named
value
and
stuff,
so
it's
it's
it's
kind
of
variables
how
how
it
comes
across
on
the
wire,
and
I
want
to
revisit
the
layout
to
make
it
more
intended,
with
the
with
the
jmap
way,
how
we
disorganized,
for
example,
for
email
and
what
we
also
were
leaning
much
on
when
we
defined
js
calendar.
E
So
that's
that's
one
of
the
next
steps
I'd
like
to
be
working
on
and
when
we
do
that,
that's
also
going
to
make
it
more
nicely
with
the
patch
object
that
we
also
are
using
for
jmap,
email
and
js
calendar
to
to
come
to
concise
representation
of
changes
to
an
existing
contact.
In
this
example,
that's
basically
the
status
and
I'm
not
sure
if
mario
would
you
have
something
to
add.
E
E
I
don't
think
so.
No,
at
least
for
me,
I
think
every
a
thorough
review
of
the
working
group
will
will
be
very
useful
once
we
we
got
a
good
grasp
on
the
on
the
on
the
data
structure
that
we
want
to
finally
have,
but
this
is
on
me
first
to
come
up
with
that.
I
in
that
respect,
I
think
it
also
doesn't
make
sense
to
set
a
deadline
or
something
at
this
point.
I
think
we'll
just
keep
working
on
this
over
the
next
over
the
next
time.
A
A
I
guess
just
I'm
just
going
to
flick
through
the
slides.
Now,
I'm
not
going
to
read
it
all
out
to
you,
because
we
can
all
read.
A
Hopefully
does
anyone
have
any
questions
based
on
what's
been
published
or
any
feedback
on?
What's
there?
I
think
probably
the
next
thing
I
would
ask
the
group
to
do
is
read:
what's
there
and
give
feedback
on
it
and
then
assuming
there
are
no
other
changes
required.
I
would
go
to
a
working
group
last
call
fairly.
F
But
I
will
probably
make
sure
it's
consistent
with
emma
quarter
great.
Thank
you.
Only
a
subset
of
you
know,
information
available.
F
So
just
the
changes
is
zero.
Two,
I
posted
new
version.
F
Previous
version
contained
two
server
generated
attributes
as
mom
status,
which
is
like
where
it
was
signed
and
whether
signature
verified
or
failed,
etc,
and
as
mime
errors,
which
is
a
list
of
human
readable
errors
encountered
during
verification,
and
now
there
is
an
extra
property
as
mine,
verified
at
which
says
what
time
the
that's
my
status
and
s
mime
errors
was
set
basically,
and
then
there
was
also
a
clarification
that
this
map
errors
can
be
affected
by
language
selection
as
per
base.
Jmap
next
slide,
please
so
yeah.
F
I
think
the
only
remaining
question
is.
Do
we
want
to
say?
Was
the
signature
valid
at
type
thing,
so
in
case
at
the
moment?
It's
basically
the
first
time
you
reque
request
a
smile
status
or
maybe
on
mail
message,
delivery.
It
will
be
set
for
the
first
time
and
then
it
it
all
has
to
be
refreshed
by
the
server
every
10
minutes
or
so,
which
is
a
caching
period.
F
Do
we
want
to
have
a
way
of
saying?
Was
the
signature
valid
at
the
time
of
the
you
know,
the
message
was
supposedly
sent,
for
example,.
D
B
Maybe
I
I
actually
have
a
question
slightly
related
to
that
it's,
so
this
is
essentially
a
mutable
property
on
the
email
object
because
it
can
change.
But
it's
not
it's
it's.
We
don't
expect
it
to
like
push
a
state
change
when
it
is
invalidated
right.
F
B
F
G
F
A
B
Yeah,
I
don't
think
you
need
this.
I
wonder
whether
what
you
want,
though,
is
it's
always
kind
of
set
on
delivery,
because
that
seems
to
be
when
it
should
be
done
and
you
could
have
a
valid
until
if
you
really
want
to
say
when
did
the
certificate
expire
that
we
validated
it
with?
I
don't
know
if
that's
actually
useful,
but
you
could.
B
F
A
F
B
G
A
If
the
server
says
I
validated
it
at
the
time
and
it
was
valid
at
the
time
that
has
value-
I
think,
but
anything
else
saying
if
I
had
validated
it
in
the
past,
it
would
have
been
valid
that
I
don't
think
that
is
meaningful.
A
H
I
think
there
is
some
some
value
in
having
sort
of
historical
validity
for
forensic
reasons,
for
you
know,
evidentiary
reasons
or
whatever,
I'm
not
sure
that
it's
a
a
use
case
that
necessarily
needs
to
be
implemented.
You
know
for
for
most
people,
though.
F
So
I
think
we're
basically
going
towards
just
validating
it
once
and
then
that's
it
right
that.
F
B
D
B
F
All
right,
I
think
this
is
pretty
close
to
being
done.
Then
I'll
just
do
one
pass
and
and
see.
If
anything
is
clarifying.
H
F
It's
an
optimization
if
you
trust
the
store.
A
Great
thank
you.
Next
thing
we
have
is
ken's
gem
up
sieve,
which
I
did
not
add
the
slides
to
to
the
data
tracker
for
so
I'm
just
searching
for
them
now
and
I
will
upload
them.
So
I
can,
if
you
want
to
start
talking,
while
I
find
them
and
get
them
displaying.
C
A
A
C
C
All
right,
so
what
are
we
talking
about
here?
So
basically
we're
talking
about
using
jmap
to
manage
zip
scripts
on
a
server?
The
current
draft
essentially,
is
just
a
one-to-one
mapping
of
current
mandate.
Civ
functionality,
semantics
onto
jmap
next
slide.
C
Please
current
draft
here's
what
it
looks
like
within
the
account
capabilities.
C
We
have
the
list
of
jpegs
in
the
set
extensions,
any
other
print
information
such
as
max
redirects
notification
methods,
all
the
stuff
you
normally
see
in
the
capabilities
within
mana
civ,
a
civ
script
object
is
fairly
simple,
has
a
server
set
id
a
name,
its
content
and
whether
or
not
it's
active
one
downside
of
using
string
for
the
content
is
escaping
within
json
becomes
not
problematic,
just
tricky
cumbersome
but
I'll
discuss
a
little
bit
about
that
further
down
next
slide,
please
in
terms
of
the
protocol
itself,
it's
fairly
simple,
there's
only
three
methods
at
this
point:
there's
a
standard
get
method
which
gives
us
what
get
script
and
list
script
do
within
manatsiv.
C
The
set
method
gives
us
virtually
everything
else
in
terms
of
manipulating
the
script
and
then
there's
a
new
validate
method
which
provides
the
same
functionality
that
we
get
with
the
current
check
script
within
manusif
next
slide.
Please
possible
things
to
change
if
we
move
move
this
forward
within
the
group.
One
question
I
had
was:
does
anybody
use
have
space
and,
if
so,
do
we
need
to
add
that
to
this
particular
protocol?
C
C
Bronze
ideas
is
to
use
blob
ids
to
reference
a
script
rather
than
using
a
string.
This
could
be
done
via
either
uploading
the
script
and
referencing
the
blob
or
use
a
new
object
and
method
that
brawn
has
implemented
in
our
server
for
doing
blobs,
basically
setting
blobs
within
a
set
of
calls.
I
don't
brown.
Do
you
want
to
discuss
that
at
all
here
or
yeah.
A
C
Okay
next
slide,
please.
C
And
there's
also
some
discussion
on
the
list,
amongst
mostly
fast
male
people,
about
the
is
active
flag
and
being
able
to
set
that
as
an
atomic
action.
Amongst
other
things,
I
don't
want
to
get
into
the
weeds
here
too
deeply
until
we
actually
decide.
This
is
going
to
be
a
working
group
item,
but
maybe
it's
brown,
let's
just
go
to
the
next
slide
and
see
if
people
have
interest
and
if
there
is
interest.
C
Maybe
we
can
discuss
this
a
little
bit
here
so
bottom
line
is:
is
there
any
interest
here
to
add
this
to
the
group
or
should
the
fast
mail
folks
just
kind
of
keep
this
as
their
own
private
extension
alexi.
F
Right
as
one
of
the
people
with
the
community
of
rfc,
I
think
that
would
be
a
great
addition
to
gmap.
C
A
It's
very
quarter-ish
and-
and
you
would
probably
return
the
over
quota
jam
up
response.
If
you
tried
to
set
something
that
that
ran
you
over
space.
A
C
Okay,
well,
how
does
how
does
this
work?
Do
we
adopt
this
pendant.
A
Yeah,
I
think
the
next
step
is
for
me
to
do
a
call
for
adoption
on
the
mailing
list.
I'm
pretty
sure
it
belongs
in
the
jam
up
working
group
rather
than
the
extra
working
group,
since
it
is
a
gmap
extension.
I
agree
it
there's
more.
It
makes
more
sense
to
be
here.
C
F
And
then,
in
regards
to
have
space,
hopefully
once
this
is
adopted,
I
suggest
there
is
an
example
using
quota
to
show
how
this
is
going
to
look
like.
A
A
All
right,
so
these
are
the
milestones
that
we
have
mdn
has
been
submitted.
Js
contact
v
card
has
been
adopted.
Germa
s,
mine
will
be
submitted
soon.
That's
going
to
go
to
last
call.
A
Quotas
august
looks
tight
s,
mime
key
management
and
server
side
signing
slash
encryption
alexia.
Are
you
interested
in
submitting
a
document
for
that
still.
F
A
October
cool
and
jam
map
access
to
address
books.
This
is
going
to
be
on
top
of
jscontact.
I
might
push
that
one
out
to
december.
I
think
realistically,
submit
gmap
calendar
to
isg.
That
looks
november
looks
viable
for
that
I'd
say,
given
that
we
are
close
to
done
with
it
and
it's
just
waiting
for
gmap
calendars,
which
is
also
nearly
done
so
js
calendar.
A
The
informational
document
is
still
sitting
with
december
assets
as
its
deadline,
we'll
leave
it
there
and
see
what
we
get
to,
and
I
think
js
contact
looks
reasonable
too.
So
we
just
have
a
couple
of
couple
of
things
to
push
back
a
little
bit.
A
Obviously
I
will
add
something
for
the
sieve
jam
to
this,
and
I
think,
probably
december
ken.
Do
you
think
that's
reasonable
after
the
next
ietf
meeting.
C
All
depends
how
contentious
some
of
the
outstanding
issues
are.
You
know
whether
we
want
to
go
with
with
you
know,
blob
set
and
some
other
things,
but
yeah
I'm
willing
to
work
on
it.
That's
for
sure.
A
All
right
I'll
set
myself
a
deadline
for
call
for
adoption
for
the
blob
to
be
fairly
soon
as
well,
and
that
should
be
able
to
to
float
fairly
close
with.
I
imagine
it's.
The
blob
is
quite
a
simple
spec.
C
I
will
mention
the
other
half
for
people
for
people
that
are
interested
in
james.
There
is
a
brief
discussion
right
now,
just
amongst
three
of
us
at
fast
mail
already
on
the
list.
So
people
want
to
chime
in.
Please
do.
A
Excellent,
thank
you
yeah.
The
other
thing.
Why
not
turn
my
video
on?
So
I'm
just
not
just
a
disembodied
voice.
If
I'm
going
to
be
doing
a
bunch
of
talking.
The
other
thing
with
blob
is
that
I'll
probably
split
it
into
two
documents,
one
of
which
will
be
totally
non-contentious
and
involves
setting
a
blob
for
use
purely
within
the
session
that
it's
being
used
in
or
possibly
with
with
an
option
to
make
it
a
permanent
blob
rather
than
a
temporary
blob.
A
The
other
one
is
much
more
complex
thing
that
we've
implemented
in
our
server,
which
is
basically
a
reverse
index.
Lookup
of
a
blob.
You
pass
a
blob
id
and
say
which
emails
reference.
This
blob,
which
calendar
events
reference
this
blob
etc,
which
is
used
for
permission
checks
in
some
of
our
stuff,
in
particular,
for
when
our
support
agents
look
at
a
mailbox.
A
It
checks
whether
the
email
is
referenced
from
a
particular
mailbox,
a
particular
folder
that
that
is
allowed
for
support
agents
to
look
at
and
everything
else
gets
suppressed,
so
that
that's
probably
worth
documenting
that
as
well.
But
that
is
going
to
be
a
more
complex
and
less
simple
thing
to
push
through.
So
getting
just
the
blob
set
as
a
separate
document
makes
sense.
A
A
H
A
Bob
no
wait.
That's
just
taking
the
l
out.
A
We
will
have,
I
guess
another
meeting
in
bangkok,
probably
right
here
in
in
meat,
echo
or
whatever
solution.
We
we're
using
that
time
around.