►
From YouTube: IETF111-JMAP-20210727-2300
Description
JMAP meeting session at IETF111
2021/07/27 2300
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
It's
nice
here
right
now,
oh
good!
Well,
I'm
glad
for
you,
it's
actually
not
too
horrible
here
in
melbourne
today
that
I'm
looking
forward
to
going
outside
in
a
couple
of
hours
and
getting
some
fresh
air,
but
it's
certainly
not
not
warm
all
right.
As
always.
This
is
under
the
noteworld.
The
jam
map
working
group's
been
going
for
a
while
now,
so
I
think
everyone
here
is
familiar
with
the
noteworld.
If
you're
not,
please
do
familiarize
yourself
with
it.
These
are
the
conditions
under
which
we're
working.
A
This
is
the
rough
agenda
of
what
we
are
thinking
working
through
today,
starting
with
drafts
that
address
core.
I
have
my
gm
at
blob
draft
to
talk
about
briefly
alexis
jammup
s,
mime
draft
he
doesn't
have
slides
for
and,
unfortunately,
he's
not
able
to
join
us
today
because
he
has
a
conflict.
He
is
chairing
another
working
group
at
the
same
time,
so
we're
not
going
to
do
much
other
than
saying
it
exists.
A
Please
read
it
and
then
we'll
talk
about
the
calendar
drafts,
the
contact
and
and
v
card
relationship
drafts
I
have
thrown
in
the
discussion
topic
of
the
large
email
program
problem
that
I
brought
up
at
dispatch
on
monday.
Basically,
because
we
had
a
whole
stack
of
time,
it
turns
out,
we
probably
won't
use
the
full
two
hours.
So
this
is
quite
padded
if
you
have
any
other
business
or
if
you'd
like
to
do
some
agenda
bashing
before
we
even
start.
A
C
Just
a
tiny
thing:
they've
been
some
errata
for
the
core
spec
and
I
was
just
wondering:
do
they
need
to
be
approved
or
do
they
can
automatically
get
approved
because
they
were
submitted
by
one
of
the
editors
because
I
submitted
them
in
the
end?
I
don't
know
I
just
wanted
to
raise
that
because
I
wasn't
sure
if
we
should
be
doing
anything
with
those
or
whether
that's
all
done.
A
A
All
right,
so
the
blob
draft,
I
have
uploaded
an
adopted
version
of
it
since
it
it
went
through
its
call
for
adoption.
The
draft
has
concatenation
support
added
to
it,
so
you
can
concatenate
parts
of
blobs
similar
to
how
imap
concatenation
works.
You
can
specify
a
blob
id
and
a
range
of
bytes
within
that
blob
or
octets,
as
specs
like
to
say,
and
then
have
those
concatenated
together
to
produce
a
single
file
which
allows
you
to
save
uploading
data
that
you
already
have
in
various
ways.
A
I
guess
the
this
iana
registry's
purpose
is
to
allow
you
to
to
take
a
data
type
name
and
from
that
reference
back
to
see
where
it's
specified,
and
certainly
the
big
to
do
here
is
implementation
experience.
I
have
not
yet
implemented
this
at
all.
I've
only
written
it
up
and
I
doubt
anyone
else
has
implemented
it
either.
So
I
would
like
to
do
that,
obviously,
before
it's
submitted
for
publication,
so
the
iona
registry
unfortunately
looks
quite
unreadable
in
this
text,
but
that's
what
we've
got
on
this
slide.
A
So
the
the
questions
I
have
for
this
group,
I
guess
is,
do
we
think
this
ayanna
registry
is
necessary
or
not
it's.
When
I
raised
this
to
neil
at
the
time.
I
was
writing
this.
We
weren't
really
sure
whether
it
was
necessary
or
not.
So
I
thought
we'd
discuss
that
here,
particularly
since
data
types
are
defined
by
the
capabilities
and
there's
already
a
registry
for
capabilities,
so
you
can
always
map
through
that
way,
but
the
terminology
for
data
type
and
defining
what
a
data
type
is
in
the
germap
context.
A
I
think,
does
need
to
be
handled
and
also
do
we
need
limits.
Yeah,
the
the
blob
set
and
cyrus
map,
and
particularly
blob,
get
and
cyrus
on
map
ken.
Is
it's
going
to
be
a
two-stage
process?
Gonna
have
to
define
the
the
new
blob
lookup
api
and
then
convert
our
middleware
code
to
use
that,
and
then
we
can
get
rid
of
the
blob
get
that's
currently.
A
C
As
you
can
see,
the
yeah,
the
the
big
question
of
the
registry
for
me,
is
whether
you
actually
need
to
forbid
duplicate
data
type
notes.
Now,
probably
mostly,
that's
not
going
to
happen
anyway,
but
the
the
kind
of
the
capabilities,
if
you
have
a
duplicate
name.
Obviously,
you
can't
use
those
capabilities
both
at
the
same
time,
but
maybe
that
you
know
it's
a
completely
different
context.
That
would
never
overlap
with
this,
but
it's
still
just
the
right
name
for
that,
for
that
and
like
you,
don't
want
to
forbid
it.
C
C
A
A
Yeah
I
will
email,
ayanna
and
and
ask
them
to
take
a
look
at
the
draft.
I'll,
add
some
additional
texts
to
the
draft.
Are
you
taking
notes
on
this
yeah?
I
see
yes,
there
yep
cool,
great
yep,
so
yeah.
I
I
will
ask
diana
to
take
a
look
at
the
at
the
draft.
Once
I've
updated
some
text
to
basically
say
there
may
be
duplicates
here
and
that's
fine.
It
just
means
that
you
can't
use
the
the
two
yeah.
C
Capabilities,
the
uniqueness
constraint
is
capability
plus
days
type
name
and
if
the
same
type
name
appears
in
two
capabilities,
you
cannot
use
those
two
capabilities
together.
So
you
know,
if
you're,
defining
a
new
capability
make
sure
it's
if
it
does
clash,
it's
not
something
that
you
feasibly
want
to
use
together,
which
is
perfectly
fine
and
plausible.
A
C
C
A
A
A
A
C
C
A
C
A
C
Yep,
so
I
have
another
question
on
this,
so
I
think
the
is
it
all
one
capability
at
the
moment,
because
the
set
and
get
are
going
to
be
very
straightforward
to
implement.
I
think
anyone
that
has
a
has
jrap
stuff
and
I
guess
you
might
as
well,
if
you
want
to
as
an
alternate
to
so
you
can
do
stuff
in
band
if
you
really
want,
whereas
look
up
is
potentially
very
different,
much
harder.
A
A
C
D
G
A
C
A
H
A
Yeah
yeah,
it's
it's
more!
If
the
client
just
just
blindly
tries
it,
there's
a
sensible
error
code
regardless,
but
certainly
the
server
should
slash
must
specify
what
it
supports
correctly.
So
we'll
define
that
awesome.
I've
got
work
to
do
and
I
think
that's
roughly
the
time
we
had
allocated
for
this
anyway.
A
Next
on
the
list,
was
this
gemma
s
mime
advanced?
It's
it's
not
that
advanced.
It's
very,
very
simple!
It's
basically
adding
two
keys
to
email
set.
That
say
please,
please
do
the
s
mime
and
then
the
responsibility
is
on
the
the
server
to
know
what
your
keys
are
and
how
to
do
the
s
miming.
So
it
it
is
quite
simple.
I
don't
know
whether
we
want
to.
C
H
A
C
C
Yeah,
I
mean
actually
it's
not
here's
a
problem
on
this,
but
the
interesting
thing
perhaps
here
is
because
it's
going
to
change
the
body
structure
that
you
pass
in.
It
should
probably
be
returning
what
the
new
body
structure
is
in
the
creative
response.
I
don't
know
we'll
put
in
discussion.
That's
what
you
would
jump,
that's
kind
of
what
the
core
spec
says.
You
would
normally
do
here.
C
A
A
C
Okay,
so
I've
published
a
small
update
overnight,
but
it's
it's
mainly
just
it
doesn't
have
it
doesn't
have
any
semantic
changes.
It's
just
fixing
some
making
some
things
a
bit
clearer,
we're
getting
some
implantation
experience
on
this
now,
not
quite
as
much
as
I'd
hoped
to
have
by
this
point.
We
should
have
a
full
experience
of
it
by
the
next
meeting
and
mostly
the
spec
seems
to
be
holding
up
pretty
well.
C
G
A
A
C
See
got
it
yeah
cool
all
right,
so
here's
an
interesting
case
which
is
you're
invited
to
a
recurring
event.
So
let's
say
it's
because
every
day
from
monday,
through
to
friday
of
the
week-
and
you
can't
go
to
wednesday
but
you're
going
to
the
rest
of
your
rsvp,
yes
for
the
general
recurring
event,
but
then
you
delete
the
wednesday
one
out
of
the
calendar
because
you're
not
going
you,
don't
don't
want
it.
This
is
something
you
can
do
in
kaladab
at
the
moment.
C
C
So
the
the
issue
is:
if
the
organizer
then
updates
the
event
again
and
sends
you
the
update,
then
your
service
can
apply
this
update
and
it's
going
to
see.
There's
this
there's
no
longer
a
cancellation
on
wednesday
because
it
doesn't
know
that
it
was
you
that
canceled,
it
necessarily
and
so
we'll
gen
often
add
back
the
event
into
your
calendar,
and
that
happens
quite
a
lot
I'll
have
to
check
more
providers,
but
that
doesn't
that
seems
quite
common.
So
I
think
there's
a
couple
of
options
to
handle
this
better.
C
One
is
that
rather
so,
so
we
have
this
excluded.
True
property
in
js
calendar,
which
is
is
added
to
the
current
overrides.
To
say
this
recurrence
is
excluded.
Like
next
state
we
could
add
an
extra
property
to
say
something
like
participant
excluded
or
some
other
name
saying
it
was
the
user
deleted
it,
not
the
organizers
event.
So
if
you
get
an
update,
it
still
keep
this
one
deleted.
C
Another
option
is
just
to
forbid
it.
You
could
just
say
the
user
should
actually
just
say:
rsvp
is
no,
for
that
particular
instance,
and
the
cloud
user
agent
will
generally
hide
those
events
anyway.
So
it
comes
to
much
the
same
for
the
user
and
you
could
have
it
so
you
know
if
the
user
click
delete.
Actually,
they
just
said
nice
vpn
or
maybe
some
other
options,
so
I'm
interested.
If
anyone
has
thoughts,
ideas
comments
did
I
explain
that
well
enough,
yeah.
F
Mike
yeah,
I've
got
one.
I
I
don't
remember
how
cal
dab
handles
this,
but
if
the
change
to
the
recurring
event
was
something
like
a
rescheduling
of
it
that
the
invitee
is
now
able
to
attend.
Doesn't
the
invitee
want
an
opportunity
to
accept
the
the
thing
that
they'd
rejected
that
they've
declined
before
this?
Isn't
it.
F
H
Well,
the
the
protocols
immaterial.
Isn't
it
it's
it's
that
the
point
is
that
your
your
you
shouldn't,
you
probably
shouldn't
be
deleting
the
instance
as
a
as
an
attendee.
It's
like
deleting
the
you
know,
removing
the
description
or
or
changing
the
time
or
anything.
There
are
things
you
can't
do
to
the
event,
because
you
don't
own
it,
the
organizer
owns
it
and
when
they
send
another
copy,
they're
going
to
overwrite
what
your
what
you
made
as
local
changes.
H
A
C
Sure
I
I
think
yes
for
being
is
reasonable,
so
we
define
that
as
one
of
the
things
you
have
to
be
the
owner
to
be
able
to
to
to
do
the
oh,
I
said
the
kind
of
why
I'm
writing.
This,
though,
is
as
far
as
I
can
tell
most
existing
calendar
systems
do
allow
you
to
do
this.
It's
just
yeah,
perhaps
they're
all
wrong,
which
is
perfectly
possible
they're
all
wrong.
In
many
respects,
I've
found
when
you
start
testing
edge
cases,
but.
H
C
A
C
D
For
what
it's
worth,
I
agree
that
the
client
is
the
correct
way
to
go
anyways.
I
think
we're
blurring
the
line
between
delete
and
decline
here
I
know
like
with
apple
calendar,
if
I
delete
a
specific
instance
that
gets
translated
to
a
decline
when
it
goes
back
to
the
server
you're,
not
actually
physically,
removing
the
component
you're.
Just
basically
stating
I'm
not
going
to
this
particular.
C
C
A
A
One
thing
with
the
previous
situation,
which
is
that
what
you
can
do
as
a
participant
is
basically
fork
off
a
new
override,
that's
not
in
the
original
event,
because
you're
overriding
your
attendance
to
a
particular
event,
which
is
not
part
of
that.
It's
not
a
that's
right,
not
a
separate
override
for
the
organizer.
Until
your
update
comes
back
so
you
can.
You
can
still
create
new
updates.
C
C
Basically,
if
you
have
permission
to
update
your
own
events,
but
not
other
events
in
the
calendar,
should
you
be
allowed
to
update
that
event
such
that
you
are
no
longer
the
owner,
because
at
that
point
you
can
no
longer
update
it
further.
For
example,
you
can't
even
undo
what
you
just
did,
because
at
that
point
you're
not
you'd
have
permission
to
so
should
we
forbid
you
from
doing
that
is
essentially
the
question,
and
if
we
do,
we
probably
need
to
split.
C
F
C
You
so
you
were
the
original
organizer
you
created
it,
but
suppose
you
have.
If
you
have
a
shared
team
calendar,
you
might
have
that
that
you
know
a
number
of
different
people
within
your
team
can
update
that
calendar,
but
they
can't
update
events.
They
didn't
organize,
but
you
might
want
to
transfer
ownership.
So
you
can
say
I
used
to
own
this,
but
now
I'm
leaving
so
I'm
gonna
say
someone
else
does
now.
You
could
add
those
as
a
second
owner
with
js
calendar
this.
C
I
C
H
H
A
C
Well,
that
also
depends
on
permissions
here.
For
all
your
personal
character,
calendars,
you
will
probably
have
may
update
all
and
stuff.
You
like.
The
client
probably
restricts
you
from
changing
things
in
events,
you
don't
own
that
you
shouldn't,
but
yes
it
does.
Let
you
you
eat
it.
This
is
primarily
going
to
be
of
importance
in,
like
you
know,
internal
shared
calendars,
where
yeah
you
can
involve
stricter
permissions.
A
C
C
Rather
than
just
have
have
one,
we
have
multiple
people
often
have
aliases.
You
know
your
full
name
at
example.com,
and
maybe
just
your
first
name
as
well.
Both
email
addresses
that
get
to
you
at
your
company
and
someone
can
send
you
an
invite
via
either,
and
so
you,
the
calendar,
needs
to
know
that
either
those
are
you
when
you're
creating
new
scheduled
events
in
your
calendar,
though
you
probably
want
to
default
to
a
particular
one
rather
than
be
prompted
every
time
now.
C
This
could
just
be
stored
on
a
per
client
basis
and
we
don't
need
to
synchronize
this,
in
which
case
we
don't
need
this
at
all.
But
if
we
do
think
it's
worth
being
able
to
store
that
preference
kind
of
in
in
the
server
so
that
any
client
you
connect
automatically
knows
which
one
it
should
default
to.
Then
we
store
that
somewhere
and
where
should
we
put?
That,
essentially,
is
the
question.
We
can
just
add
a
is
default
property.
C
Some
name
like
that
to
the
participant
identity
object,
but
then
you've
got
to
update
like
two
at
a
time
go
set
one
to
true
and
one
to
false.
At
the
same
time
and
you've
got
to
make
sure
that
exactly
one
has
true,
probably
which
is
all
doable
but
a
bit,
we
could
stick
on
the
capabilities
object,
but
that's
only
really
feasible
if
it's
a
read-only
thing,
which
I
don't
think
this
should
be,
there's
no
reason
why
the
user
can't
change
their
default
and
so
and
then
the
other
option
is.
C
Is
you
have
some
reference
on
some
other
object
like
a
calendar
preferences
object
that
has
default
participant,
identity
id
and
gives
the
id,
and
then
it's
easy
to
update.
So
you
just
change
the
id
that's
set
there,
but
we
don't
have
any
particular
objects
like
that
right
now,
and
is
it
worth
creating
a
whole
one
just
for
this
property,
but
maybe
there'll
be
others
in
the
future
anyway.
There's
the
options
that
I
see.
But
if
you
have
any
other
suggestions,
let
me
know.
H
I
would
if
yeah
I
would
vote
for
the
for
the
last
one.
I
think
I
think
this
has
come
up
before
that
it
would
be
useful
to
have
somewhere
to
store.
I
mean
there's
going
to
be
more
than
one
preference.
You
know
more
than
one
property,
yes,
and
and
at
the
moment
there
is
no
standardized
way
to
store
and
share
that.
H
C
Guess
the
question:
is
you
know
what
other
properties
do
we
want
to
find?
We
have.
We
have
an
object
like
this
and
a
whole
bunch
of
preferences
kind
of
internally.
Like
you
know
what
day
of
the
week,
do
you
want
to
start
on
and
stuff
like
that,
but
yeah?
I
don't
know
how
much
that
should
be
synchronized.
H
H
C
F
C
H
C
H
A
H
B
H
H
C
C
Okay
sounds
like
broad
support
for
defining
a
yeah
calendar
preferences,
object
and
I'll
have
a
look
at
the
list
of
props
and
see
what
other
stuff
we
should
be
putting
on.
There
sounds
like
that.
Actually
might
be
a
few.
A
few
things
great.
That
sounds
reasonable
to
me.
Okay,
that's
those
were
the
three
things
that
I
came
across
so
far
with
implementation
that
I
thought
worth
discussing.
C
I
said
hopefully
by
next
next
itf.
We've
done
a
full
implementation
on
both
client
and
server
and
see
if
anything
else
comes
up
that
we've
noticed
and
if
anyone
else
has
experience,
please
also
post
on
the
list
or
just
communicate
in
some
other
way,
and
hopefully
we
can
look
towards
finalizing
this
document
by
the
end
of
the
year.
I
think
I
can't
know
what
the
milestone
is,
but
yeah
that
seems
possible.
Now.Js
calendar
has
been
approved
and
published
yep.
Okay,
thanks.
Everyone.
J
J
C
C
A
J
All
right,
you
have
some
other
things,
robert,
yes,
two
other
things,
the
one
thing
being
so
the
calendar
role,
the
inbox
role
is
defined
as
the
calendar
where
invites
get
put
into,
and
this
is
currently
optional.
So
it's
possible
to
remove
that
role
and
or
transfer
to
other
calendars,
and
the
idea
would
be
that
to
make
this
role
the
inbox
role
mandatory
and
if
server
supports
scheduling
and
the
server
can
indicate
this
with
an
additional
capability,
because
otherwise
the
issue
might
be
that
someone
removes
all
their.
C
Yeah,
I
actually
think
if
we're
gonna
create
this
calendar
preferences
object.
We
talked
about
just
before
that.
We
should
move
to
defining
this
there
rather
than
having
the
input
box
roll.
This
seems
a
better,
better
place
for
to
me
again
for
kind
of
the
same
reasons,
it's
easier
to
say:
yeah,
here's,
the
people
calendars
to
use
for
new
events,
here's
the
people
calendar
for
limitations,
et
cetera,.
C
J
Yeah
I
mean
the
difference
would
be
that
if,
in
my
opinion,
the
difference
would
be,
if
the
server
has
this
scheduling
capability
it,
it
will
not
be
allowed
to
end
up
with
no
inbox
role,
whereas
if
the
calendar
preferences
object
is
mutable-
and
I
guess
it
is,
we
still
have
the
same
issue
that
someone
might
just
remove
their
inbox
role
without
and
then
they
have
again.
We
have
no
idea.
J
J
D
J
Cool,
so
as
long
as
as
we
can
state
that
the
server
can
reject
it,
I'm
that
would
be
a
perfect
solution.
Yeah
so
and
the
only
the
last
question
is
not
necessarily
only
related
to
cmap
calendars,
but
for
calendar
implementations
in
january.
So
so
we
have
these
standalone
instances
of
an
event.
So
let's
say
you
have
a
recurrent
recurring
event,
and
but
you
do
not
have
the
main
event
with
the
r
rule.
You
just
get
an
invite
to
one
of
the
recurrent
instances,
and
I
do
wonder
how
how
current
implementations
are
handling
this.
J
J
J
A
J
I
I
Okay,
that's
nice
cool
new
feature,
okay
yeah,
so
yeah
yeah
for
us
for
jmf
for
tasks,
not
a
lot
since
has
happened
since
the
last
interim
meeting,
but
yeah
for
for
us
personally.
Quite
a
lot
has
happened
since
last
itf,
at
least
so
mainly
I
I
dumped
the
changes
that
happened
since
last
itf
in
in
here.
What
we
did
is
we
we
changed
the
sword.
All
we
added
sort
order
to
the
task,
object,
no
wait
that
is
actually
oh
yeah.
I
I
I
C
I
don't
actually
have
any
questions
right
now,
but
I
will
make
sure
I
review
it
again
before
the
next
meeting
and
if
you
yeah,
looking
forward
to
hearing
about
your
invention,
experience
with
that
as
well,
which
he
said
you'll
hopefully
have
by
then
I
think
this
server
capabilities
research
was
also
important.
I've
seen
to
remember
discussing
that
last
time,
just
to
kind
of
get
a
good
sense
of
how
broadly
this
is
likely
to
cover
the
the
use
cases
that
people
seem
to
have
yep.
J
J
J
Option
then
I
will
I,
in
my
opinion
this
this
means
we
have
consensus
by
the
people
who
have
an
interest
in
how
it
should
look
like
the
just.
Another
minor
thing
is
that
we
currently
do
not
use
this
special
type
property
to
indicate
the
the
the
the
object
type
within
a
within
a
json
object.
So,
for
example,
the
type
would
be
address
for
an
address
object.
Obviously
we
intend
to
add
that
for
all
for
our
object,
types
that
we
define
in
jscontact.
J
Except
if
someone
is
not
in
favor
of
this,
please
let
me
know,
and
then
there
is
two
items
that
I
got
feedback
quite
a
while
ago
already,
but
we
haven't
started
to
address
this
yet
so
I'll.
Take
the
opportunity
to
do
this
now,
so
the
first
is
that
there
was
the
request
to
be
able
to
track
metadata
per
fields,
field
being
a
property.
J
J
Now,
I'm
I'm
not.
I
do
not
have
all
the
details
on
the
exact
use.
Cases
that
are
are
intended
to
be
supported
by
this,
but
basically
not
saying
that
we
necessarily
should
do
this,
but
if
we
want
to
do
this,
I
think
this
could
be
done
rather
easily
with
a
patch
object
path
to
a
metadata
object.
That
then
defines
the
properties
one
wants
to
track
in
them.
H
H
H
C
C
A
H
H
I
have
the
same
problem
with
with
every
so
often
somebody
will
will
raise
that
with
our
public
event
system,
you'd
like
to
know
who,
so
you
can
do
that
by
throwing
through
your
own
logs
and
and
extracting
stuff.
But
it
makes
a
lot
of
sense
to
attach
it
directly
to
the
event
or
or
to
the
contact
and
then
simply
have
it.
D
H
A
change
reporting
mechanism
and
it's
actually
used
the
same
thing-
is
used
by
the
apple
calendar
application
to
show
that
what
the
changes
are
to
a
shared
current.
You
know
you
if
an
event
changes
in
a
shared
calendar.
The
only
thing
is
missing.
Is
it's
not
actually
attached
directly
to
the
to
the
changed
object?
It
comes
through
as
a
separate
notification
stream.
A
C
Yeah,
like
I
can
see
yeah,
I
guess
when
the
js
contact
you
just
define
that
as
a
property
of
you
know,
it
could
exist
and
then
something
like
gmap
contacts.
You
might
say
this
is
actually
only
server
set.
So
you
know
it
can't
be
faked
by
the
client
or
stupid
stuff
and
the
server
obviously
might
truncate
it
after
a
certain
time
as
well.
So
you
don't
keep
unbounded
history
or
it
doesn't
have
to
yeah,
and
you
probably
have
to
explicitly
request
it.
It's
not
like
one
of
the
default
fields
that
will
be
returned.
J
H
H
C
J
C
Not
a
data
format
and
the
only
thing
in
the
data
format
is,
I
guess,
the
uid,
which
I
think
we
already
have
right.
So
you
can
say
this
is
for
sure
the
same
same
thing
because
it
has
the
same
uid.
Clients
may
also
try
and
do
it
based
on
other
stuff.
If
it
can't
make
up
your
ideas
like,
which
is
gonna,
be
less
viable.
D
G
J
H
J
H
I
G
C
J
J
Approach
seems
to
have
gotten
interest,
so
I'd
say
we.
We
can
start
defining
this
under
the
umbrella
of
of
the
js
contact
work.
But,
as
we
said
it,
it
should
be
object,
type,
agnostic,
yeah.
I
can.
I
can
write
something
up
in
the
in
the
next
time,
but
the
main
focus
will
be
js
contact
until
we
got
that
defined
and
done
properly
cool.
A
A
The
problem
statement's
pretty
obvious,
we've
all
seen
this
end
users
want
to
send
big
files
to
each
other
as
emails
also,
they
want
to
attach
large
files
to
calendar
events
and
possibly
also
attach
large
files
to
contacts
at
the
moment.
That's
generally
a
high
resolution
photograph,
but
who
knows
in
the
next
couple
of
years,
people
might
want
to
attach
a
video
of
themselves
with
the
other
person
to
a
contact
at
that
stage.
A
I
don't
know
if
you've
seen
the
discussion
discussion
on
the
dispatch
mailing
list
since
monday,
there's
been
a
bit
of
pushback
at
the
idea
that
this
is
something
we
can
even
do
so,
we'll
we'll
see
there,
but
certainly
for
gmap.
This
is
of
interest
to
all
our
data
types
and
tasks,
obviously
are
also
going
to
want
to
be
able
to
link
to
large
files.
So
we
all
care
about
this.
I
took
some
screenshots
of
myself
emailing
large
files
around
and
with
google
drive
you
go
with
gmail
it
uploads
to
google
drive.
A
It
appears
as
a
recent
document.
New
google
drive,
so
it
messes
with
all
your
history
and
all
sorts
of
stuff
with
icloud
again
it
winds
up
being
stored
on
their
server
in
this
case,
just
for
30
days
before
it
gets
deleted
and
the
attachment
is
just
a
a
reference
to
it's
a
link
inside
the
html
body
of
the
email
and
with
outlook
exactly
the
same
thing
again
you
upload
it.
It
gets
stored
in
your
storage
drive
at
the
source
and
then
a
link
gets
emailed
this
the
problems.
Obviously
the
upload
of
large
files.
A
You
want
to
be
able
to
restart
and
upload
jmap,
doesn't
have
any
solution
to
this,
and
that
really
is
an
issue
for
http.
So
I'm
going
to
be
talking
to
the
chairs
of
the
https
working
group
and
see
if
this
is,
if
they
have
work
in
that
area
already
or
if
it's
something
that
we
need
to
talk
to
them
about
getting
done.
A
The
big
question
is
the
ownership
or
responsibility
for
the
data
who
is
responsible
for
keeping
a
copy
of
this
data
and
keeping
it
online
for
the
lifetime
of
the
object,
and
this
particularly
matters
with
calendar
events,
where
you
have
managed
attachments
who's
responsible
for
keeping
that
attachment
alive.
If
you
invite
someone
to
an
event,
the
organizer
being
responsible
kind
of
makes
sense,
but
if
you're
sending
out
something
that's
supposed
to
be
a
long-lived
calendar
calendar
event
that
that's
not
an
invitation,
then
who's
responsible
for
keeping
that
copy.
A
F
F
A
Yeah
that
that
is
very
easy,
so
if
you
just
require
that
there's
a
digest
or
even
a
couple
of
different
digests
with
a
couple
of
different
algorithms
included
in
there
for
whatever
level
of
I
mean
it's
not
100.
Obviously,
if
someone
finds
a
way
to
to
break
char
256,
then
maybe
we've
got
problems,
but
specifying
that
I
think,
would
be
fair.
A
So
yeah,
the
other
question
is:
where
is
the
copy
sent
and
ref
counts?
Ref
counted
again.
This
is
much
more
solved
if
you
send
the
digest
of
the
content
along
with
your
email,
in
a
way
that
the
recipient
system
can
reliably
extract
and
see
that
this
is
a
reference
to
some
external
content
and
where
to
get
it
from
because
the
recipient
server
can
then
download
in
case
you
copy
or
people's
individual
individual
clients.
Even
if
you
even
phones
these
days
have
enough
storage
on
them.
That
10
megabytes
is
pretty
small.
A
You
could
have
your
local
email,
client
pull
a
copy
and
case
it
locally,
along
with
your
email
archive,
your
pop3
client
download
a
copy
as
well
so
long
as
you
can
tell
that
this
is
a
resource
and
and
has
an
id
and
ideally,
some
kind
of
globally
unique
idea
which
the
digest
is
sufficient
in
some
ways.
For
that
whether
you
need
a
separate
global
idea
as
well,
then
I'm
not
sure
there.
So
that's
the
thing
that
I
think
is
worth
discussing,
but
certainly
within
the
first
mile
system.
A
It's
not
really
broken
for
anything
other
than
some
very
explicit
cases,
yeah,
because
right
now,
as
I
said
in
these
slides,
if
you
can
read
it
at
all-
and
this
it's
just
got
an
href
to
an
external
file.
There's
there's
nothing
in
it
that
identifies
that.
As
this
is
supposed
to
be
attached
content
thanks,
ned
cool.
A
Your
recipient
server
has
the
responsibility
as
saying
in
the
comments
in
the
chat
here,
you
can't
guarantee
anywhere
near
as
much
as
you
can
if
the
content
is
all
kept
together,
but
the
questions
has
enough
change,
since
this
was
done
back
in
rfc
1000
series
that
more
systems
are
more
likely
to
support
this,
because
clearly
people
are
working
around
it
and
their
every
big
email
system
now
dumps
the
file
and
and
sends
a
link
to
it,
and
at
least
something
more
structured
and
discoverable
would
be
better
than
what's
happening.
Now.
A
A
A
B
Okay
is
my
microphone
working
yep?
Yes,
oh
good
yeah,
I
mean
I
agree.
This
is
a
problem
that
we
need
to
solve
because
because
we
have
users
saying
like
why?
Because
we
have
users
who
are
baffled,
that
they
try
to
email
their
30
minute
video
and
it
doesn't
work,
but
I
really
yeah
I
I
realize
it
seems
crude
and
primitive
to
divide
it
into
chunks
and
send
them,
but
like
that,
avoids
all
sorts
of
other
problems
like
like
where,
where
is
the
data
stored?
B
We
know
you
know
and
yep
yep,
and
we
have
a
proof
of
concept
that
it's
worked
in
using
that
for
20
years,
although
I
realize
using
that's
a
little
different,
but
it's
still,
you
know
you
send
the
messages
and
you
glue
them
back
together.
So
and
the
other
thing
is
that
I
think
the
that,
like
before
this
starts
like
we
need
a
whole
surf.
We
had
a
whole
document
just
to
try
to
upload
outline
the
threat
model,
and
you
know
all
the
horrible
things
that
people
will
do
once
you
can
like.
A
B
C
Think
that's
why
I
prefer
the
kind
of
model
promise
protein
because
which
is
more
of
a
pull
than
a
push
model,
because
if
you're,
you
know,
if
you're
putting
these
in
the
messages
that,
if
I'm
understanding
you're
at
john,
then
look
your
recipients
got
to
deal
with
that
huge
amounts
of
data
like
keeping
it
all
in
memory.
Well,
concatenates.
These
fits
right
well,
not.
C
Sure
they
can
categorize.
What
I
mean
is
they
don't
have
the
option?
Not
if
they
want
that
data
at
all.
They
have
to
keep
track
of
it
right
then,
and
there,
and
then
you
could
easily
fill
up
a
user's
quota,
whereas
if
it's
kind
of
here's
a
link
with
a
digest,
the
server
can
fetch
you
immediately,
which
is
better
privacy,
but
it
can
also
balance
that
with
I,
you
know,
I'm
not
going
to
blow
the
user's
quota,
because
you
know
sender
x
has
already
sent
me
too
much
of
this
yeah.
C
A
B
Yeah
I
mean,
I
think
this
is
all
part
of
why
I
would
like
to
write,
write
down
the
threat
model.
I
mean
the
threat,
I
mean
the
threat
model
if
you
fetch
stuff
immediately
and
virus
check
it
sort
of
reduces
to
what
we
already
understand,
and
you
know
the
longer
the
gap
between
when
you
send
it
and
when
you
look
at
it
the
more
interesting
the
threats
are.
So
I'm
looking
forward
to
a
lot
of
interesting
work
on
this
project.
C
Yeah,
I
I
think
the
important
point
for
me
is
that
the
threat
is
going
to
be
strictly
less
than
what
is
currently
the
case
with
all
these
systems.
Brown,
just
you
know,
pointed
out,
like
people
are
doing
this,
whether
you
want
them
to
or
not
so
almost
whatever
we
do
is
going
to
be
at
most
as
risky
as
that
and
probably
less
risky,
and
we
just
try
and
make
it
as
good
as
possible.
Yeah.
A
A
G
F
The
the
thing
that
concerns
me
a
little
bit
about
the
pull
model
is
making
it
clear
whether
or
not
you
actually
have
the
message
or
not.
I
mean
I
can
picture
a
situation
where
somebody
sends
me
a
big
pdf
and
I
decide
that
I'm
gonna
review
it
on
the
plane
and
then
I
get
on
the
plane,
and
I
don't
have
it.
A
A
Yeah
cool,
so
we
might
be
able
to
whack
the
whole
thing
in
a
jwt
data
uri
or
something
if
the
symmetric
keys
are
short
enough.
Cool
we've
still
got
half
an
hour
and
we've
got
no
other
specific
topics
to
cover.
So
I'm
I'm
quite
happy
to
be
chatting
about
this,
even
though,
obviously
this
is
probably
not
the
working
group
where
the
work
will
happen.
G
C
A
C
C
C
D
D
A
A
Cool
yeah,
if
we
do
a
last
call
at
112,
then
submitting
in
december
sounds
right,
adopted
document
for
jam
up
access
to
address
books.
We
haven't
even
started
with
that,
yet
so
that
might
need
to
pop
through
to
december
as
well,
if
we
again
propose
it
at
next
iatf
and
do
a
call
for
adoption
and
then
december
would
be
right,
submit
jmap
calendars.
C
A
C
A
A
So
march
2022,
I
guess
or
april
2022,
so
after
isf-113
gem
up
s
mime
will
be
submitted
in
july
2021.
I've
got
two
days,
maybe
three
it's
ready
to
go.
It
just
just
needs
me
to
actually
submit
it.
Likewise
adopt
a
document
for
s.
My
key
management
will
be
august
2021
because
that's
I'll
send
out
the
call
for
adoption
straight
after
this
submit
js
contact.
Robert.
A
A
I
A
A
A
G
There
are
a
bunch
of
different
rss
feed
readers
that
have
some
sort
of
api
for
separating
the
portion
of
the
code
that
goes
out
and
checks.
You
know.
Are
there
new
updates
in
this
rss
feed
from
the
ui
that
lets?
You
actually
read
those
updates
so
very
much
like
mail,
but
as
far
as
I
can
tell,
none
of
the
existing
protocols
have
any
facility
for
push
notifications
or
any
way
for
the
client
to
maintain
cash,
a
local
cache
of
any
of
the
data.
G
C
I
I
agree
that
jmf,
I
think,
is
a
perfect
fit
for
this
kind
of
thing,
like
it's
very
similar
kind
of
problem
to
male.
I
think
it
would
in
many
ways
it's
actually
just
a
lot
simpler.
You
know
things
like
conversations
or
threads
which
make
things
more
complicated.
So
if
people
want
to
do
this,
I
think
it'd
be
straightforward
to
do
I
just
yeah,
I
don't
know,
I
guess
it's
just
needing
to
find
people
that
are
interested
enough
to
do
that
and
see
if
they
want
to
come,
propose
it
and
adopt
it.