►
From YouTube: IETF109-JMAP-20201116-0730
Description
JMAP meeting session at IETF109
2020/11/16 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
I'll
leave
my
video
up
but
put
myself
on
me
when
other
people
are
talking,
and
it
is
time
so,
let's
get
started-
welcome
to
the
jam
up
session
at
iatf-
109,
sadly
not
in
bangkok,
which
I'm
very
disappointed
about,
because
I
was
sick
last
time
we
were
in
bangkok
and
did
not
get
to
enjoy
the
city
as
much
so
I
would
have
liked
to
anyway.
As
always,
all
of
the
work
we
do
here
is
under
the
note.
Well,
this
is
the
same
slide
I
used
a
year
ago,
so
hopefully
it
is
still
accurate.
A
I
don't
think
anything's
changed
in
that
time.
All
the
work
you
do
here
contributes
to
the
itf
and
is
under
all
of
the
policies,
the
ietf,
which
I'm
sure
you
have
already
in
great
detail
and
will
obey.
Thank
you
very
much.
A
Moving
along
to
our
agenda.
We
have
one
hour
to
get
everything
done
here,
so
we're
going
to
be
discussing
first
status
of
gem
at
mdn,
which
is
a
little
bit
tricky
because
our
area
director
is
not
here
and
that's
waiting
on
him
then
discuss
the
three
current
work
items
that
we
have
talk
about.
My
gem
at
blob,
spec
and
then
a
discussion
about
jam
up
for
data
portability.
This
came
up
in
the
calconet
core.
A
Europe
is
working
on
data
portability,
requirements
for
a
whole
stack
of
services
and
a
lot
of
the
data
about
people
and
personal
information
management
is
things
that
jmap
or
jmf
adjacent
work
is
building
data
formats.
For
so
talking
about
whether
some
of
the
other
formats
for
personal
data
should
also
have,
I
guess
something
like
a
js
contact
defined
and
then
a
jmap
way
to
access
that
data,
which
can
hopefully
become
the
standard,
interchange
format
for
different
services
that
provide
that
kind
of
data.
A
B
A
A
A
C
Cool
okay
right,
so
this
is
just
an
update
on
gmat
for
calendars,
they're
kind
of
jamming
according
to
calder
for
those
that
are
new
here,
their
current
status
is
basically
getting
implementation,
experience
now
and
then
making
further
refinements.
Based
on
that,
so
some
of
the
things
I've
got
a
few
questions.
I'd
like
to
discuss
on
the
next
two
slides
about
some
things
run
into
whilst
implementing
their
current
draft.
C
So
the
first
point
is
about
adding
invitations
to
a
calendar.
So
if
you
receive
an,
I
message
via
email-
and
you
want
to
add
that
into
your
calendar-
it's
fine!
If
the
calendar
server
itself
is
processing
the
imit
message,
because
it
doesn't
have
to
follow
your
normal
permissions.
But
if
some
client,
that's
completely
external
to
calendar,
is
trying
to
do
this
via
jmap.
C
Normally,
the
permissions
would
not
necessarily
let
you
add,
an
event
where
you're,
not
the
owner,
and
you
may
not
have
the
permission
to
update
it
either.
If
you
receive
an
update
from
the
from
the
organizer,
because
it
doesn't
know
that
it's
not
really
you
that's
updating
it.
It's
you've
received
this
and
you're
kind
of
passing
it
on
to
the
calendar
server.
C
So
I
was
just
want
to
bring
that
up,
as
is
this
something
we
want
to
handle,
or
should
it
just
be
that
you
know
you
have
to
have
the
calendar
server
should
integrate
properly
with
your
email
and
have
some
back
channel
for
updating
it,
and
if
we
do
want
to
handle
this,
how
should
that
happen
like,
without
that
really
kind
of
making
the
whole
permissions
model
pointless?.
C
That
is
a
very
good
question.
I'm
not
actually
100
sure.
I
need
to
check
that
again.
I
think
they,
I
think
they
don't
really
enforce
the
permissions.
I
think
commission's
always
just
kind
of
done
in
the
clients
to
stop
users
from
making
changes.
That
kind
of
are
considered
frowned
upon,
perhaps
would
be
the
way
of
putting
it,
but
it's
more
gentleman's
agreement
than
actual
enforcement
yeah,
but
yeah.
C
Yes,
we
should
definitely
double
check
that,
and
this
is
probably
something
you
know
like
all
the
german
calendar
stuff
to
discuss
it
calculated
to
the
next
time
we
meet
there,
but
I
thought
I'd
bring
that
up
as
this
yeah.
This
is
one
of
the
issues
I
think
needs
to
be
resolved.
Now,
for
this.
A
C
I
guess
that,
yes,
that's
fine,
so
long
as
then,
you
need
some
way
of
adding
the
event
while
saying
I
do
not
claim
ownership
of
it.
So
don't
send
out
invitations
and
stuff
for
this
potentially,
which
you
could
know
just
by
looking
at
the.
A
To
say
I
want
to
send
invitations
for
this
rather
than
having
them
be
automatic.
A
C
But
I
think,
there's
still
a
a
permissions
thing
of
you
know,
generally
we're
moving
away
from
letting
the
server
just
arbitrarily
send
invitations
from
any
address,
without
checking
that
the
user
owns
that
address,
yeah,
yeah,
cool,
yeah,
okay,
I'll
think
about
that
and
we'll
discuss
it
next
calculate
perhaps
and
so
go
on
to
the
next
slide.
C
This
has
got
a
bunch
of
questions
all
related
to
scheduling
again,
of
course-
and
this
point
in
this
case
the
participant
identities.
So
this
is
about
who,
who
you
are
in
the
calendar
essentially
like
which
which
email
addresses
or
it's
not
actually
necessarily
email
addresses,
because
it
could
be
different
scheduling
protocols
but
which
participants
in
an
event
should
be
considered
as
the
user.
That's
currently
using
the
calendar.
C
So
at
the
moment
they
are
on
the
calendar,
as
I
just
property
on
the
calendar
objects.
But
as
we
discussed
the
last
meeting,
I
think
we're
gonna
move
those
to
be
per
account
from
the
calendar
because
we're
going
to
allow
an
event
to
be
in
multiple
calendars,
and
so
it
doesn't
make
sense
that
those
calendars
would
have
different
sets
of
identities.
And
I
think,
generally,
it's
you're
going
to
have
different
accounts
where
you
have
different
sets
of
identities,
so
that
should
be
fine
once
we
do
that.
C
My
first
thing
should
this
be
a
data
type
rather
than
just
a
property
on
the
account
subject,
which
I
think
it
probably
should.
So
it's
just
you
can
do
a
standard,
get
and
fetch
them,
and
that
makes
a
lot
easier
if
there's
changes
on
the
server,
you
use
the
standard,
push
method
and
everything
else
to
get
the
latest.
C
The
updates,
rather
than
being
stuck
on
the
account
capabilities,
object
the
more
interesting
question:
if
we
make
it
a
day's
type,
is
then
should
that
be
merged
with
the
mail
identity,
data
type,
which
is
a
very
related
concept
of
the
addresses
I
can
send
as
if
over
mail
or
is
it
should
it
remain
separate,
says
anyone
have
any
thoughts
on
on.
D
C
C
The
friendly
name
and
the
email
address,
but
then
you
have
other
things
that
are
only
going
to
be
relevant
for
mail
like
signatures
and
stuff,
whereas
with
calendars,
the
name
and
email
being
useful,
but
you
also
have,
I
said
it's
not
necessarily
an
email
address,
we're
associating.
It
could
be
a
different
protocol,
that's
being
used
for
scheduling,
and
so
it's
more
uri.
That's
this
uri
is
representing
this,
this
user,
so
that's
kind
of
a
separate
property.
So
there's
some
overlap,
but
not
complete
overlap.
E
So
why
wouldn't
we
want
participated
entities
on
both
the
calendar
and
the
principal
or
account
or
whatever.
C
No,
no,
no,
no,
we
wouldn't
we
we'd
take
them
off
the
calendar
and
it
would
be
its
own
data
type
that
belonged
to
the
account
and
there's
one
set
of
data
type,
a
set
of
participant
identities
for
the
account
that
applies
to
all
calendars.
In
that
account.
Does
that
make
sense.
C
Well,
so
that
that
calendar
would
come
from
a
different
account,
this
would
only
get
problematic
if
that
user
wanted
to
share
two
different
calendars
in
a
single
account,
one
in
secondary
mode
and
one
with
not
in
sector
mode
that
wouldn't
be
possible
under
this
system.
So
I
I
don't
think
that's
too
bad
a
restriction.
Like
generally,
you
might
have
team
calendars
like
that
that
you're
in
yeah
personal
mode,
not
secondary
mode.
C
I
don't
know
what
we
call
it
and
those
would
be
in
an
account
that
belonged
to
the
group
and
then
my
individual
calendars.
I
might
share
with
specific
people
and
those
would
be
in
secondary
mode,
but
I
wouldn't
share
one
of
my
individual
calendars
and
allow
you
to
act
as
yourself
on
it,
because
that
doesn't
really
make
a
lot
of
sense.
E
C
Well,
so
I
mean
that
this
goes
back
to
the
question
of
whether
an
event
should
be
allowed
in
multiple
calendars,
which
has
some
nice
properties
and
it's
more
consistent
and
that's
what
we're
going
to
try
doing.
But
if
we
do
that
does
that
make
compatibility
with
calder
harder,
because
obviously
it's
a
different
different
model
and
so
calendars
within
a
single
account
have
to
have
consultant.
A
The
caldav
model
that
we're
trying
to
use
at
the
moment
is
one
that's
a
a
draft
spec
that
is
not
the
same
way
that
apple's
doing
it.
It
was
something
that
they
proposed
a
while
back
and
then
cal
connect
went
and
rewrote.
So
I
don't
think
there's
anything
in
caldav.
That's
widely
supported
that
allows
for
a
set
of
participants
per
calendar
at
the
moment.
It's
all
per
per
principle,
and
then
the
principal
is
the
same
for
all
the
calendars.
A
E
Okay,
so
that's
what
apple
is
doing,
then
it's
splitting
it
up
for
principal
right.
A
F
F
C
Yep,
okay,
I'll,
try
that
and
see
how
that's
how
it
goes
so
so
the
other
question
I've
posed
on
here,
which
I
came
to,
is
so
when
you're
looking
at
an
event
and
trying
to
decide
if
this
is
which
participant
you
know,
looking
looking
at
the
participants
in
the
event
and
trying
to
decide,
if
anything
correspond
to
the
identity
that
you
have
you're.
Basically,
comparing
two
uris
and
I
came
into
the
issue
of
what
case
sensitivity.
C
Should
I
be
using
for
comparison
if
one,
if
I
have
a
participant,
that's
got
a
mail
to
ui,
for
example,
which
is
you
know,
mail,
two
column
and
an
email
address,
and
I
have
an
identity
with
mail.
Two
column
email
address.
C
Do
I
compare
those
case
sensitively,
but
the
scheme
bid
is
not
case
sensitive.
I
don't
think,
and
neither
is
necessarily
the
another's
domain
part
of
an
email.
So,
yes,
any
thoughts
on
what
we
should
do
there
shall
we.
C
C
I
think,
like
99
of
the
time
probably
case
insensitive,
you
know
ascii
case
insensitive
is
the
right
thing
to
do
and
will
work.
But
I
wonder
if
we
want
to
mandate
that,
because
that,
in
theory
could
hit
a
problem,
if
you
had
people
using
email
addresses
with
case-sensitive
mailbox
parts
and
conflicting
ones
of
that,
I
it
seems
unlikely,
but
I
don't
know
any
thoughts.
D
It's
almost
like
a
question
for
email
court
to
maybe
clarify
and
make
a
stronger
argument
saying
that
if
you
ever
do.
D
C
Yeah,
I
think
you
will
be
in
big
trouble
these
days
so
much
the
internet
presumes
that
is
case
insensitive
well,
a
lot
of
web
services
just
like.
C
A
C
D
C
Yeah,
I
mean
most
of
the
time
it's
going
male
2
schema
at
the
moment,
but
I
can
definitely
potentially
in
the
future
different
schemas.
D
You
so
you're
saying
you
can
or
you
can't
you
can't,
because
the
path
hostname
is
casey.
C
D
C
D
That
would
probably
require
quite
a
bit
of
text
explaining
this
or
you
know,
say
you
need
to
parse
the
scheme
and
then,
if
you
know
the
scheme,
then
maybe
you
can
compare
against
insensitive.
If
you
know
it
isn't
sensitive
but
and
then
give
examples
of
both
ways.
Maybe
I
don't
know.
C
Okay,
those
are
the
main
things
I
wanted
to
bring
up
with
issues
that
I've
encountered
so
far
with
implementation.
So
I
think
we've
got
some
paths
forward
on
at
least
some
of
those
and
I'll
try
and
update
the
spec
for
the
next
itf
and
bring
it
up
at
cal,
connect
anywhere
else,
guys
comments,
questions
or
anything
on
german
calendars,
while
we're
looking
at
this
or
should
we
move
on.
A
I
think
probably,
let's
move
on
that's
our
time.
E
Hello
yeah,
so
I'm
just
going
to
give
a
short
update
on
cheers
contact
that
I'm
working
on
together
with
mario,
who
is
also
in
the
meeting
today.
Hi
mario
next
slide,
please
so
with
js
contact.
We
are
doing
basically
for
for
context
and
contacts
what
we
are
trying
to
do
for
calendar
events
with
gs
calendar.
E
There
are
two
documents:
the
one
is,
the
the
the
specification
of
the
of
the
data
type:
that's
gs
contact
in
its
version
in
version
o2
and
totally
on
me.
There
have
been
no
changes
since
last
last
itf,
I'm
sorry
about
that,
and
there
is
another
document
which
is
which
describes
the
conversion
between
js
contact
and
vcard,
which
did
get
an
update
since
last
itf,
thankfully,
due
to
mario
and
it's
mainly
around
the
implementation
status,
where
mario
has
implemented
the
more
to
support
for
for
mapping
between
these
data
types.
E
G
It's
just
a
java
library,
which
is
that
implements
not
only
the
conversion
between
the
various
card
formats
to
js
content,
but
it
also
implements
validation
of
js
contact
object
and
the
creation
of
js
contact
object
based
on
the
baseball
builders.
So
it
is
the
library
that,
according
to
my
opinion,
covers
all
the
aspects
about
creation,
maintenance
of
just
contact
objects.
E
Coolant,
if
I
remember
correctly
during
the
mapping,
it
has
turned
out
that
we
are
covering,
I
think,
almost
everything,
or
even
everything,
of
the
available
vcard
properties
in
chess
contact.
Is
that
right
or
I'm
not
up
to
date
on
this?
If
we
missed
any,
if
we,
if
we,
if
there
are
only
if
there
are
known
missing
points
so
to
say.
G
I
I
I
tested
the
the
library
against
all
the
card
book
alex
card
or
j-card
objects.
I
I
found
on
the
web,
especially
for
j-card.
I
tested
the
library
against
the
response
responses
coming
from
the
art
of
servers
listed
in
the
ayana
bootstrap
registry
for
rdap,
so
I
tested
more
than
responses,
including
jaccard,
but
obviously,
if
anyone.
G
Can
provide
a
a
counter
example
that
is
not
covered
by
the
current
implementation
is,
is
welcome,
so
it
can
be
improved.
E
Okay,
cool
yeah,
I'm
also
going
to
look
into.
If
I
find
a
couple
of
more
files
to
test
this
with
in
either
case,
I
think
it
will
provide
a
strong,
it
will
provide
a
strong
foundation
or,
however,
we
might-
and
I
guess,
we'll
change
the
core
format
still
this
would
be
good
will
be
a
good
way
to
make
sure
that
we
are
that
nothing
gets
dropped.
E
While
doing
so.
Having
said
that,
I
guess
then
what
remains
is
that
the
probably
weak
points
of
wii
card
are
still.
I
guess
some
of
them
are
direct
with
into
the
into
js
contact
currently,
namely
that's
the
address
parts
which,
in
record,
were
very
driven
by
a
western
by
addresses
that
are
used
in
the
in
the
western
world
and
also
there,
I
guess
more
in
the
in
the
large
countries.
So
I
guess
the
address
part
will
be.
The
biggest
will
be
the
biggest
thing
to
get
right
in
js
contact.
E
If
we,
if
we
really
want
to
add
something
on
top
of
e-card
yeah,
so
that
probably
brings
us
to
the
next
slide.
The
next
and
the
last
slide,
which
is
basically
that
I
will.
I
will
now
work
on
updating
the
course
back.
It
expires
next
month
anyway,
so
I
guess
I
really
should
do
that
now
and
along
with
that,
we
will
need
more
implementations.
I
will
I
will.
E
I
will
work
on
on
looking
if
and
when
we
support
that
in
the
cyrus
imap
server,
for
example,
but
I
guess
I
can't
give
an
estimate
on
that
one
yet,
probably
I'll
I
work
on
it
on
a
feature
branch
just
to
make
sure
we
are.
I
get
implementation
feedback
early
on
yeah.
That's
that's
it
from
my
side.
I'm
not
sure
if
there
are
any
if
there
are
any
questions
or
or
or
input
at
this
point.
A
E
I
I'm
not
sure
if
we
even
have
groups
at
the
moment
in
scope
and
cheers
contact,
but
let
me
check
that
oh
yeah,
we
have
already
chase
card
group,
but
it's
really.
It's
really
just
a
very
thin
wrapper.
Yes,
okay,
yeah,
so
we'll
definitely
also
need
to
look
into
that.
F
All
can
hello
everybody,
hopefully
the
slides
are
more
more
coherent
than
I
feel
at
the
3am,
but
we'll
grind
through
here.
So
there's
been
a
couple
iterations
of
the
draft
since
we
adopted
it
in
ietf
108.
F
A
lot
of
that
churn
has
been
based
on
implementation
experience
in
cyrus
and
how
we
intend
to
use
this
at
fast
mail
so
covering
the
main
changes
in
the
account
capabilities.
Object.
We've
specified
that
the
capability
strings
are
case,
insensitive
also
added
a
max.
I
script
capability
and
one
other
thing
that
I
forgot
to
put
in
the
slide
was
there's
also
a
boolean
property
which
specifies
whether
the
implementation
supports
the
test
method
which
I'll
get
to
a
further
slide.
As
far
as
I
said,
the
subscript
object
goes.
F
We've
made
the
name
property
optional
when
using
the
set
method.
If,
if
it's
not
set
by
the
client,
then
the
server
will
assign
its
own
unique
name.
This
allows
for
blind
creations
where
the
the
client
may
not
want
to
do
an
extra
round
trip
to
see
what's
available
before
it
goes
and
creates
a
new
script.
F
Additionally,
the
is
active
property
is
now
set
on
the
server
via
a
new
argument
in
the
set
method
which
I'll
get
to
in
a
second.
This
prevents
the
possible
problem
of
a
client
trying
to
set
it
set
two
scripts
active
at
the
same
time,
so
that
this
new
argument
allows
this
to
be
an
atomic
action
question
here.
Is
there
any
other
additional
properties
we
see
of
value
that
might
go
in
this
object?
F
F
F
Additionally,
any
changes
made
to
any
of
the
objects
by
this.
This
action
must
be
reported
in
the
set
response,
so
if
you
created
a
script
and
activate
at
the
same
time,
obviously
it's
going
to
be
reported
as
created,
but
if
you
are
doing
something
which
activates
a
new
script
but
at
the
same
time
deactivates
another
one,
the
deactivated
script
would
also
appear
as
being
updated
in
the
response.
F
Additionally,
this
argument
can
be
used
even
if
you're
not
creating,
updating
or
describing
anything.
So
if
you
just
want
to
flip
a
particular
script
on
or
off,
this
argument
can
be
used
with
create
update,
destroy
being
null
next
slide.
Please.
F
I've
also
added
a
new
query
method:
pretty
straightforward:
you
can
filter
and
sort
based
on
the
name
or
the
active
properties.
Again
question
here
for
the
group:
do
we
see
the
need
for
any
other
additional
filter
or
sort
criteria.
A
F
A
Even
that's
kind
of
tricky
in
it.
Do
you
just
resolve
what.
G
D
Now
that
you
mentioned
is
included,
I
want
it.
I
want
to
use
it
now.
F
D
F
Okay
next
slide,
please.
F
So
here
this
is
the
biggest
addition
since
ietf108
we've
added
a
new
test
method.
The
request
looks,
as
you
see
there,
obviously
there's
an
account
id.
The
client
specifies
the
script,
either
with
script
content,
which
is
just
the
raw
octets
for
an
id.
An
existing
script.
That's
already
on
on
the
server,
also
gives
a
an
array
of
email,
blob
ids
of
messages
that
it
wants
to
test
against.
F
We've
reused
the
envelope
object
from
the
mail
spec
to
pass
the
interpreter
information
that
it
should
assume
it
was
present,
asmtp
transaction
that
delivered
a
message.
This
can
be
used
for
obviously
envelope
tests
or
vacation
actions.
F
F
I
don't
know
how
well
adapted
the
environment.
Spec
is,
or
the
duplicate
spec.
F
It
yeah
I'm
trying
to
remember
now
one
of
them
is
is
where
is
the
interpreter
actually
running?
Is
it.
F
Yeah,
I
I
don't
recall
what
the
other
ones
are
again.
I
don't
know
how
widespread
that
that
spec
is.
Obviously
we
could
always
extend
this
spec
if
there
was
a
need
for
this
kind
of
things.
You
know
the
duplicate.
You
know
basically
just
checks
to
see
if
the
existing.
If
the
message
already
exists,
this
could
be
a
fairly
simple.
You
know
boolean
type
argument
for
testing.
You
know
just
say
yes
or
no,
whether
that
this
you're
supposed
to
act
as
if
this
has
been
already
delivered
or
not.
F
F
So
reply
to
this
thing,
oh,
you
need
to
go
forward,
one
bro
so
reply
to
this.
In
addition,
the
account
id
basically
has
two
other
arguments
completed
or
not
completed,
both
of
which
are
arrays.
If
it's
completed,
it's
a
map
of
the
blob
id
to
a
set
of
action
types,
the
action
type
kind
of
mimics,
what
we
see
with
the
array
of
method
requests.
F
If
the
test
fails,
you'll
you'll
get
a
map
of
the
blob
id
of
the
message
and
any
set
error
that
identifies
what
the
problem
was
on
the
next
slide.
I've
got
an
example
of
what
one
of
these
action
objects
looks
like
pretty
straightforward,
so
this
would
be
a
vacation
action
and
the
various
arguments
that
you
might
see
this.
The
current
draft
has
a
bunch
of
text
which
describes
how
the
arguments
should
get
named.
F
Mainly
it
usually
either
uses
the
tagged
argument
name
for
those
that
are
tagged,
arguments
for
those
that
are
positional.
It
uses
the
the
name
that
is
in
in
the
actual
usage
part
of
the
spec.
F
One
question
on
the
format
of
the
reply
as
I
was
implementing
this
fcc
itself
has
its
own,
obviously
argument
value,
but
then
a
bunch
of
other
arguments
that
can
go
along
with
it
so
mission
fcc,
you
could
have
create
special
use
and
mailbox
id
and
a
bunch
of
other
ones
that
could
possibly
go
along
with
it.
So
my
question
was:
should
fcc
basically
be
its
own
sub-object
with
any
appropriate
arguments
along
alongside
of
it
or
just
leave
them
in
line
as
individual
arguments?
D
F
F
Do
we
need
any
kind
of
limits,
whether
it
be
rate
limits
or
other
other
types
of
limits
ron?
I
think
you
were
the
original
one
that
proposed
the
idea
of
a
rate
limit
for
this.
A
There's
already
a
rate,
limited
error
message
for
cetera,
so
I
would
just
say
that
we
can
use
that
you
can
say
rate
limit
and
reject
a
request
if
it's
given
and
it
hits
your
rate
limit
or
you
can
do
an
http
level
rate
limiting
response
as
well.
I
don't.
A
A
I
had
a
question
a
few
slides
back
and
since
I
have
the
remote
control-
and
I
can
just
do
it-
email
blob
ids
allows
you
to
specify
multiple
blobs,
but
the
envelope
is
presumed
to
be
the
same
for
every
single
one
of
those
email
blobs.
With
this.
F
Cool
yeah-
I
did
not
put
an
example
of
that
in
the
draft,
but
there
are
there's
a
set
of
examples
specific
showing
how
the
on
success
activate
script
works
in
various
scenarios.
So
please
check
the
draft
and
see
if
there's
anything
there
that
any
use
cases
that
people
could
imagine
that
wouldn't
be
covered
by
the
the
the
current
object
cool.
A
I
hope
yeah
cool
any
comments
about
the
direction
it's
it's
going.
Is
that
a
a
sensible
thing?
I
guess
I'm
gonna
have
to
call
for
adoption
as
well
or
ask
jim
to
do
a
call
for
adoption.
Since
it's
it's,
my
document.
A
D
C
D
A
Cool,
I
probably
should
do
an
example
of
it
being
used
immediately
afterwards
as
well,
so
show
it
being
used
in
line.
I
guess
the
only
question
I
had
was
whether
I
should
create
add
some
kind
of
bully
in
here
to
say
ephemeral.
A
So,
there's
no
there's
no
ability
to
say
get
s
raw
octets!
You!
Your
choices
are
data
as
text
space,
64
or
as
hex.
So
as
text
will
only
work
if
it's
text
data,
otherwise
you
need
to
do
space.
64
s,
hex
and
you'll.
Get
the
bytes
in
that
format.
A
All
right.
I
will
keep
working
on
that
and
I'll
ask
jim
to
do
a
call
for
adoption.
Since
I'm
the
author,
thanks
jim.
A
A
Basically,
in
this,
you
could
create
a
blob
as
a
catenation
of
the
following
ranges
out
of
the
following
blob,
ids
and-
and
you
could
use
it
to
implement
the
same
thing
that
the
catenate
operator
does
as
a
server-side
blob
creation
yeah,
it
did
make
sense
cool
the
next
thing
I
want
to
look
at
and
either
include
in
this
document
or
possibly
another
document.
A
A
A
All
right
and
the
final
topic
for
discussion
in
this
meeting
was
jamet
for
data
transfer.
We
had
a
request
during
the
calconnect
meeting
from
the
rodriguez
people
who
are
working
on
a
export
format
for
personal
information
from
from
many
different
things,
so
we
have
js
calendar
and
js
contact
underway
already
for
calendars
and
contacts.
A
First
now
has
a
basic
spec
for
notes
and
storage
node,
which
is
for
files,
so
just
exporting
as
a
zip
file.
Some
kind
of
directory
containing
files
is,
is
probably
going
to
be
more
useful.
There
are.
There
are
other
data
types
that
that
people
think
we
should
be
working
on
in
this
group
or
that
there's
a.
I
guess-
request
for
respect
for
or
proposed
specs
for.
H
Hi,
hello,
yeah,
so
we're
interested
in
tasks
as
well,
but
I
already
saw
that
in
js
calendar
there
is
some
kind
of
task
included,
but
it's
it's
not
there's
no
gmap
for
tasks
yet
so
that's
something
we!
We
are
currently
looking
into
yeah.
So
basically
we
look
if,
if
where
we
could
contribute
to
jmap,
which
is
a
bit
unclear
to
us
until
now,
but
I
guess
we
can
talk
about
this
later
on.
C
Presuming
you're
just
looking
for
the
data
format
for
export
purposes,
it's
js
calendar
that
you
want
there
anyway,
rather
than
jmap
really.
So
I
think
that
has
tasks.
C
H
A
Also
yeah,
this
is
definitely
the
right
working
group
for
it.
So
I
guess
the
question
is
whether
we
need
a
different
format
than
jmap
calendars
for
gmap
tasks,
specifically
that
ships
still
just
calendar
objects,
but
as
a
tasks
rather
than
calendars
thing.
A
C
No,
it
would
be,
I
think,
yes,
it's
just
it
would
be.
The
jmap
protocol
will
be
separate.
It
would
be
a
separate
gmail
separate
using
that
data
format,
so
the
jmap
bit
will
actually
be
fairly
straightforward.
It's
mainly
just
referencing
the
data
type
okay.
E
For
for
tests,
I
think
for
on
the
chamber
part.
The
interesting
part
will
be
defining
an
address
book
type
like
like
what
we
have
for
chamber
calendars
as
a
calendar
type.
This
is
what
might
most
likely
be
different
for
tasks.
Oh
sorry,
I
I
I
was
thinking
about
context
now,
but
for
tests
also,
what
what
is
the
bucket,
where
a
task
should
be
part
of,
and
that
might
differ
from
the
calendar,
yeah.
Okay,
sorry,
I
was.
C
H
Yes,
but
that's
actually
that's
like
some
question
I
had
so
you
have
this
js
group
object
as
well
in
js
calendar.
Why
don't
you
use
it
in
jm,
app
for
calendar.
C
Because
it's
it
wouldn't
be
very
efficient.
It's
it's
just
one
big
collection
of
items,
whereas
jmap
gives
you
a
way
much
more
efficiently
querying.
So
you
just
get
just
the
days
you
need
and
getting
updates
to
that
aren't
in
an
efficient
way.
So
the.
C
Is
more
for
publication
when
you're
just
pushing
out
a
file
and
that's
it
it'll
be
gone,
we'll
just
take
it
up!
Yeah,
whereas
when
you're
using.
H
B
A
A
The
milestones
we
have
at
the
moment
are
lots
of
stuff
submit
jam
up
quotas
to
isg
that
still
pending
and
jmf
s
mime
is
still
pending
as
well.
Alex
is
going
to
get
back
to
that
at
some
point,
but
has
been
busy
with
I'm
at
4
of
2.
A
blobs.
We'll
do
the
call
for
adoption
soon,
gem
up
sieve
we've
adopted
s1
key
management
will
push
further
back
alexi.
When
do
you
think
we'll
get
to
the
rest
of
the
s
mime
stuff.
A
Spring
spring
cool
all
right-
that's
that's
november,
here
in
australia
spring
so
next
year,
no
okay,
six
months
or
so
four
months,
something
like
that
cool!
I
will.
D
D
A
A
A
We
still
do
need
to
do
that.
I
guess
you
and
I
will
sit
down-
do
that
at
some
stage.
Neil
one
of
these
happy
days,
js
contact.
E
I
can't
hear
you
anymore
braun,
but
yeah.
I
guess
four
to
six
months
is
also
a
good
good
time
frame.
F
As
far
as
I'm
concerned,
it's
fairly
close,
you
know
pending
reviews.
I
don't,
I
think.