►
From YouTube: IETF106-JMAP-20191119-1710
Description
JMAP meeting session at IETF106
2019/11/19 1710
https://datatracker.ietf.org/meeting/106/proceedings/
A
B
A
Session
for
Gemma
this
yeah
well
yeah
a
decade,
certainly
not
the
last
one
ever,
but
you
seem
to
keep
keep
accumulating
new
workers.
We
go
along
I'm
sure
you
are
all
well
aware
of
the
note
well
by
now,
but
if
not
searched
a
chef
not
well
and
you
will
find
it
very
very
easily
and
you
can
read
it
at
your
leisure.
A
C
D
I'll
get
that
out
of
the
way
so
I'm.
The
document
Shepherd
for
WebSocket
I,
had
one
set
of
last
call
comments
that
can
just
submitted
a
revision
to
cover
those
I
think
on
Monday
after
the
internet,
craft,
freeze,
thawed
and
so
I
just
need
to
go
through
that
and
revise
my
my
Shepherd
comments,
get
those
submitted
and
we'll
be
submitting
it
to
iesg,
hopefully
within
just
a
couple
of
days.
F
So
since
montreal
has
been
quite
a
big
update
to
this
spec
that
really
fleshed
it
out,
it
was
kind
of
just
the
rough
outlines
on
the
zero
zero
version.
Zero
one
is
fairly
complete
missing
a
boatload
of
examples
which
I
think
definitely
gonna
be
needed,
because
it's
very
hard
to
describe
really
what
I'm
describing
everything
in
prose
but
I
think
it's
much
easier
to
understand.
F
F
F
What
we
really
need
next
is
to
get
some
implementation
experience,
just
it's
always
going
to
find
edge
cases
and
things,
so
we
hope
to
at
least
get
some
implementation
experience
first
of
all,
over
the
next
three
to
six
months.
Anyone
else
wants
to
do
that
as
well.
I
would
love
to
hear
it.
There
are
a
few
open
issues,
though,
or
interesting
edge
cases.
I
thought
we
talked
about
today
if
you
can
get
onto
the
next
slide.
F
Just
before
that,
I
thought
I'd
give
a
brief,
brief
description
of
the
data
model
and
the
slight
changes
from
last
time
anymore.
The
really
good
memory
we'll
have
seen
a
slide
similar
to
this
at
the
last
ITF,
but
there
are
some
more
things
in
it
now,
in
particular,
notification
things
so
there's
this
calendar
share
notification,
object
based
type
and
the
calendar
event,
notification,
data
type,
essentially
a
calendar
event,
notification
dose
time
to
start
with.
That
is
just
a
log
of
every
change.
That's
happened.
F
Events
in
this
account,
so
when
you
add
something
update
something
or
destroy
something,
and
then
you
expose
a
subset
of
that.
Basically,
you
expose
everything
where
the
change
was
not
made
by
the
user.
That
is
viewing
the
account.
So
this
is
because
calendars
systems
involve
a
lot
of
people,
editing
the
same
stuff
you
get
invitations
coming
in
so
on.
Cal
deaf
has
a
concept
of
an
inbox
which
covers
one
small
part
of
this,
which
is
when
you
receive
invitations
and
updates
fire
I
tip.
This
is
kind
of
just
extending
that
concept
to
any
time.
F
G
F
There's
a
few
things
see
if
people
have
seen
the
spec
there's
a
lot
of
permissions
involving
calendaring
there's.
The
calendar
object
has
gained
a
lot
of
different
permission
options
that
you
can
assign
to
people
more
than
mailbox
and
I
do
think
we
need
them
all
I'm,
just
wondering
whether
need
to
add
one
more,
which
is
whether
can
you
share
a
calendar
with
someone
where
they
have
write
access,
but
they
don't
have
permission
to
add
new
invitees
to
events
at
the
moment.
I'm
just
tying
those
together,
but
I
think
some
systems
might
make
that
separate.
F
A
F
So
probably
rather
not
add
yet
another
Akal,
as
I
said,
there's
a
lot
of
them
already,
but
I
took
any
one
things
we
need
need.
That
next
thing
is
when
a
calendar
is
shared
with
someone,
they
need
the
ability
to
change
the
name
to
make
it
more
understandable
to
them.
Otherwise
you
might
have
a
load
of
calendars
or
called
work,
because
everyone
shares
their
work
calendar
with
you,
but
you
want
to
be
named
work
to
Barry's
work
or
to
Lexi's
work,
and
that's
just
your
view
of
that
calendars.
Renamed.
F
You
don't
want
it
renamed
everywhere
else.
So
there's
no
two
options
here.
One
is
that
you
make
the
name
property
writable
for
these
Sherri's,
but
once
they've
written
it
is
their
local
copy
and
they
don't
have
acts
and
that
doesn't
affect
their
else,
which
is
fine,
but
also
they
don't
see
the
original
then
or
we
could
have
a
separate
property
that
they
can
write.
So
they
still
have
access
to
the
original
name.
Does
that
make
sense
so
that
you
could
you
have?
F
You
have
two
properties
on
the
object,
one
which
is
the
immutable
original
name
which
only
the
owner
can
change
and
one
which
is
their
local
name.
So
I
don't
know
if
anyone
has
experience
with
systems
lights
before
with.
Is
it
better
to
have
that
explicitly
a
separate
property
or
as
just
you
can
update
the
call
property?
But
then
you
overwrite
whatever
was
there
before,
and
you
don't
really
have
access
to
that.
F
D
F
H
H
F
So
we
could
the
current
speck
just
has
it
doesn't
have
a
separate
property
just
yet
does
override
it,
and
you
never
happy
personal
name
after
that
we
could.
We
could
leave
that
I.
Just
yeah
was
wondering
whether
this
is
the
kind
of
thing
I
can
imagine
someone's
had
experience
with
and
either
is
fine
or
they've
got
some
other
way.
Oh
this
is
it
gotcha,
because
you
need
the
original
name
at
this
point,
because
the.
H
H
F
I
I
H
A
F
You
want
to
expose
the
original
name
as
opposed
to
local
man.
Yeah
okay,
sounds
my
mind.
A
bit
of
bike
sharing,
I,
guess:
there's
a
Sherri's
access
property
on
a
calendar
which
is
does
this
acting
team
mode
where
everybody
is
acting
as
themselves
and
a
shared
cameras.
So
Barry
adds
an
event
Barry's.
F
You
know
Barry
the
organizer
Alexi,
then
the
Lacey's
organizer,
who
are
you
acting
as
whoever
owns
that
calendar
like
Barry's,
acting
as
a
Lexy
secretary,
and
is
that
the
at
the
moment
I'm
giving
the
that
there's
a
property
that
says
who
you
acting
out
on
the
calendar,
which
is
either
owner
or
self
as
in
the
owner
of
the
calendar?
But
the
word
owner
is
used
in
a
variety
of
contexts
in
calendaring
and
I'm
wondering
whether
it's
better
just
to
rename
that,
even
though
it's
in
a
different
place
here
just
to
avoid
confusion,
but
so.
F
Basically,
which
I
think
probably
I'll
rename
it
to
avoid
confusion
anyway.
Okay,
so
tell
events,
there's
a
couple
of
extra
properties
I'm,
whether
we
add
which
not
in
CalDAV
or
that
kind
of
thing,
but
do
seem
to
be
quite
common
I.
Both
exchange
and
Google
Calendar
have
very
similar
stuff,
which
you
can
probably
guess
from
the
names
what
they
do,
one
where,
when
you
send
out
I
tip
messages,
you
don't
send
out
all
the
participants
with
them.
Just
yourself.
F
Should
we
actually
try
to
standardize
this
thing,
given
that
I
said
seems
to
be
common,
various
proprietary
systems
and
in
some
way,
similar
one
is
some
indication
of
whether
the
organizer
is
prepared
for
other
people
to
turn
up
it's.
You
can't
stop
people
actually
forwarding,
obviously
information,
but
you
can
give
an
indication
of
whether
that's
likely
to
be
approved
or
not,
and
then
clients
might
actually
do
something.
Do
I
at
least
err
sure.
A
F
Yeah,
so
this
is
a
curious
thing
like
these
would
be
extra
properties
that
we'd
register
against
J's
calendar.
But
that's
fine,
there's
a
whole
registry
with
that.
They
don't
need
to
be
in
the
initial
spec
and
the
point
of
them
is
they
they
only
really
affect
stuff
when
you're
using
it
viral
protocol
when
you're
using
it,
then
fact
the
only
really
effective.
We
didn't
miss
chairman
calendars,
because
it's
about
when
you
I
send
out
invitations,
should
I
include
this
information
or
not
it's
not
it's
not
in
heaven,
property
or
necessarily
of
the
event.
F
Okay,
so
I
will
look
at
adding
those
okay,
so
this
is
so
one
of
the
capabilities
is
how
big
an
event
object.
Is
the
server
willing
to
store
which
sounds
sensible
as
probably
something
we
want
and
there's
a
very
similar
capability
in
CalDAV?
The
trouble
is
it's
a
bit
harder
and
gerrant
to
say
what
actually
is
the
size,
and
you
know
how
we
made
it
useful
to
the
client,
because
you've
got
this
kind
of
JSON
object.
F
Is
it
like
the
stringify
JSON
encoding
in
bytes
or
the
then
depends
how
the
Jason's
formatted,
maybe
slightly
or
what
I
yeah
exactly
and
it
might
depend
on
if
the
server
adds
in
extra
properties
or
something
when
it
saves
it,
which
you
don't
have
in
the
client,
because
there
are
a
few
cases
where
the
server
like
the
server
might.
In
the
really
extreme
case,
the
server
might
bunt
the
sequence
number
from
999
to
1000,
you've
added
an
extra
character
and
something
you've
gone
over
there
over
over
the
size
limit
I.
F
Danger
is
if
people
start
I
mean
so
calendar
event.
It
kind
of
can't
contain
arbitrary
key
values,
and
some
of
those
properties
can
be,
you
know,
can
be
as
big
as
you
like.
You
can
embed
a
data
URL
in
there
with
three
Meg's
of
attachment
data.
Now
it's
not
the
way
you
meant
to
do
it.
You
meant
to
upload
up.
You
should
upload
a
blob
like
you
normally
do
enjoy
math
and
reference
that,
but
you
could
embed
data
URLs,
and
so
you
could
have
like
an
arbitrary
big
object.
F
F
A
billion
participants,
although
there's
actually
separate
capability
on
the
maximum
number
of
participants,
you
can
have
I
think
but
yeah
so
I
don't
know
that
they
obviously
has
to
be
some
size
limit
in
the
server
it's
just
how,
if
or
even
if
it
should
be
exposed.
Maybe
we
just
don't
need
to
is
its
ex-con
sanity
and
if
you
hit
it,
you'll
get
a
error,
but
you
should
you
don't
need
to
know
it
because
you
should
never
hit
it
if
you
did
not
doing
something.
Silly,
I,
don't
maybe
that's
reasonable.
A
Yeah
I'm
kind
of
comparing
in
my
head
to
the
in
extra
where
it
says
the
the
fact
that
you
quote
us
says
you've
only
got
this.
Many
bytes
left
isn't
a
reason
to
reject
uploading
any
particular
message
from
the
client.
The
client
should
not
say
you
kind
of
load,
Gordon
I
think
it
must
not
stop
uploading,
even
though
it
can
warn
because
the
server
may
store
it
and
compressed
in
such
a
way
that
it
still
fits,
and
likewise
the
server
may
reject
a
message
which
is
smaller
than
what
the
quota
quota
said.
A
C
F
F
F
F
We
have
some
pseudo
a
pseudo
type
thing
in
male,
where
you
can
register
for
a
type
just
to
be
pushed
when
changes
to
when
you
must
just
arrive
rather
than
any
change.
So
this
is
kind
of
similar
to
that,
except
that
the
push
type
you
get
back
is
not
state
change
type
is
completely
different.
Bush
type,
which
has
information
about
the
alert
in
I,
think
it's
still.
Okay,
but
I.
Don't
people
found
it
particularly
weird
I.
F
Probably
no
one
here
has
had
a
look
enough
detail,
the
event
the
push
stuff
and
jam
up
to
really
say.
But
if
you
do
have
any
comments,
no
okay,
yeah
well
I'll
leave
it
as
it
is.
If
people
play
it
later
in
view,
we
can
look
at
options,
but,
as
I've
mentioned,
it's
a
bit
weird
but
seem
to
be
the
right
thing.
Okay.
F
Finally,
then
I
just
wanted
to
talk
about
the
other
things
I
haven't
put
in
yet,
but
some
of
them
I
will
probably
delegation
is
in
my
calendar,
it's
even
it's
also
in
J's
calendar,
it's
not
widely
used
but
is
used
in
some
places.
It's
kind
of
a
formal
method
of
saying
I'm
not
coming
to
this
meeting,
but
someone
else
is
and
I've
invited
them.
F
F
It
says
you
can
agree
outer
band
that
someone
else
is
organizing
this
event
now
and
then
there
you
take
over
as
the
organizer
caroled
I've
never
really
offered
a
way
to
do
this,
but
the
stands
I'd
be
saying
that,
yes,
you
do
need
to
do
from
time
to
time,
so
I
thought
it'll
be
worth
putting
in
just
how
you
should
do
this
over
the
protocol.
The
last
one
I
don't
planter
out
because
as
far
as
I
can
tell
no
one
used
it
anymore,
which
is
a
countering
via
I
tip
again.
F
This
was
never
had
it
Kaldur
that
I,
don't
think,
there's
any
clients
that
offer
way
of
doing
it
and
it
looks
like
the
once
you're
starting
to
negotiate
over
what
time
the
meeting
should
be.
You
want
something
much
more
like
doodle,
which
is
coming
with
the
veep
old
stuff,
which
is
happening
in
calyx
at
the
moment
and
so
I
think.
That's
really
much
better
solution
to
this
in
the
Stannis
world,
so
I.
Unless
anyone
really
really
wants
it,
I
wasn't
find
edge.
F
They
can't
proposal
sport.
So
that's
just
a
brief
preview
of
I.
Don't
think
any
of
those
are
super
important
as
I
said,
I
think.
The
big
thing
now
is
to
implement
the
core
bits
which
all
specified
and
get
some
experience
with
that
and
then
we
add
some
examples
and
I
know
things
in
the
details
like
that
into
the
document,
and
hopefully
yeah.
Maybe
middle
next
year
will
be
kind
of
finished,
that's
kind
of
a
rough
timeline.
A
F
And
while
we
discuss
this
as
well,
so
they
make
sense
yes
happy.
Hopefully,
though,
yeah
people
from
Google,
Calendar
and
Apple
etc.
Again,
we
can
talk
about
that.
There,
okay,
I,
think
that's
all
I
have
fun
calendaring.
If
anyone
else
wants
tarts
and
questions
about
it
do
so.
Otherwise,
let's
move
on
I.
H
D
A
F
My
my
I
was
thinking
more
so
fermentation.
Although
client
implementation
of
C
is
useful
too
and
I
think
the
the
main
thing
is
that
this
is
somewhere
where,
ideally
anyone
that's
implanting,
it
would
come
to
Cal
connect
where,
where
we
do
try
to
do
interoperability
testing
as
well
as
discussion
stuff,
but
we
can
also
arrange
other
times
to
do
interoperability,
testing
at
ITF
or
whatever,
also
hackathon,
yeah
or
just
feedback
on
experience.
When
implanting.
F
If
there's
bits
that
are
unclear
convictions
things
you
can't
implement
for
whatever
reason:
yeah
it's
calendaring
stuff,
get
surprisingly
complicated
once
you
have
all
the
different
things
going
on
and
so
yeah
I
think
we
need
just
a
bit
of
experience
just
to
make
sure
that
that
got
the
details.
Right
so
said.
Well,
we'll
be
working
on
implementation.
Hopefully
we
can
find
some
other
people
as
well
and
yeah.
Next,
three
months
will
can
experience
for
that.
Just.
I
D
A
A
J
A
B
A
Mdn
is
pretty
much
ready.
The
discussion
last
time
was,
everyone
was
happy
with
the
changes
were
discussed
where
the
MDM
was
too
short,
but
everyone
knows
what
mdn
means
unluckily.
Something
else
will
grab
that
name.
So
we're
happy
with
that.
I
think
we're
ready
to
go
to
last
call.
I
will
query
that
also
as
on
the
mailing
list
and
check,
but
I
think
everyone
was
happy
with
the
the
most
recent
draft
is
version
2
now
Neil.
Do
you
remember
anything
else
on
that?
A
A
A
K
F
Question
poses
separate:
you
could
specify
the
scope
of
the
usage
separate
to
the
scope
of
the
total,
which
I
didn't
really
understand
and
I
was
hoping.
The
authors
could
try
and
it
did
yes
like
I.
You
know
you
have
a
thousand
gigabytes
of
quota
and
that
quota
scopes
to
the
server
your
usage
is
10
gigabytes,
which
is
scoped
to
the
user.
A
A
A
A
You
see
what
happened
there,
all
right
and
we'll
try
and
get
this
done
early
next
year.
Hopefully
it
doesn't
look
like
it's
going
to
be
particularly
difficult
to
get
done,
but
I
know
this.
There's
a
few
different
people
interested
in
making
sure
that
it
covers
everything
they
want
to
cover
and
certainly
having
having
the
same
types
as
the
IMAP
quota
in
terms
of
storage.
A
G
A
C
Now
I
should
be
able
to
do
something
by
Vancouver
I
think
there
are
also
discussion
last
time
and
I
think
there
would
be
two
documents.
Yeah
one
is
extension
of
the
current
one
which
is
simpler.
I
want
to
verify
this
as
my
signature
of
this
message
and
they
are
more
complicated
one.
If
you
want
to
use
service
TNC
to
cut
storage,
then
you
can
both
do
both
signing
and
encryption
and.
A
A
F
F
We
talked
a
bit
about
this
Cal
connect
a
few
months
ago
as
well.
So
your
big
issue
is
things
like
addresses
and
names
which
can
be
complicated
in
ways.
I
still
can't
imagine
fully,
even
though
I
know
about
some
of
the
weird
edge
cases,
so
that
makes
them
interesting.
If
you
want
a
format,
that's
suitable
for
worldwide
use.
I
think
we
came
up
with
quite
a
neat
solution
for
this,
though
so
the
trouble
is.
F
You
have
this
tension
of
not
wanting
to
make
the
kind
of
data
format
ridiculously
complicated
when
you
want
to
do
just
something
simple.
That's
always
been
a
key
requirement,
at
least
to
me
for
the
this
format
and
for
the
calendar.
One
simple
thing
should
be
simple,
but
you
also
want
to
be
able
to
make
the
other
things
possible
and
you
just
needs
flexibility.
So
I
think
what
we
come
with
is
kind
of
concept
of
tagged
words.
So
if
you
had
a
name
like
mr.
Joe
Bloggs,
rather
than
having
separate
title
field,
mr.
F
first
name
field,
Joe
last
name,
field,
blogs,
new,
that's
great
for
the
Western
world,
but
there's
lots
and
lots
of
other
ways.
You
could
describe
names
and
people
have
alternate
names
and
all
sorts
of
things.
So
instead,
what
I
think
we're
heading
towards
is
a
kind
of
a
simple
property
called
name
which
would
be
an
array
of
objects
and
the
object
will
be
like
the
first
one
would
have
a
value
of
mr.
second
one
value
named
Joe
last
one
buddy
blogs,
and
then
you
can
add
other
attributes
onto
that
object.
F
So
you
could
tag
it
as
this
is
a
first
name.
This
is
a
title.
This
is
a
prefix
and
we
can
make
that
as
rich
as
you'd
like,
and
you
only
have
to
include
the
tax
you
want,
so
that
both
gives
you
the
ability
to
describe
things
pretty
much
in
as
much
detail
as
you
need
and
also
for
simple
clients.
You
don't
have
to
understand
any
of
those
tags.
You
just
join
all
the
words
together
and
you
have
the
name
to
display
to
the
user
in
you
know,
in
a
reasonable
way.
F
H
Text
and
I'd
have
to
see
some
examples
with
different
kinds
of
names.
You
know
maybe
Spanish
names
versus
Burmese
names
versus
yeah
I
think
we
did.
A
H
H
H
To
go
seek
out
people
from
different
countries
to
help
you
with
the
examples.
Yes,
we
don't
need
that
you
know,
for
instance,
those
Spanish
names
have
various
family
names
in
there
and
this
side
of
the
family
and
that
side
of
family
and
the
name
that
you,
the
surname
for
the
person
is
somewhere
in
the
middle
Aaron.
Yes,
is.
F
F
H
H
H
F
A
F
H
F
H
H
H
G
D
G
Pinyin
in
the
phonetic
name
and
I've
got
the
English
name
that
the
person
uses
in
in
the
nick
name
now
rarely
do
clients
that
use
that
address
book,
get
it
all
right.
Most
of
them
just
display
the
real
name,
although
they
generally
put
the
order
right.
That
may
do
family
name
first,
if
it's
a
Han
name,
but.
G
But
well
I,
don't
know
if
they
do
or
not.
They
apples
pretty
cute
about
doing
things
in
interesting
ways.
So
I
I,
don't
think
you
should
get
into
the
sub
semantics
of
it.
I
think
you
should
stay
at
name
and
you
know
give
phonetic
name
it
possibly
or
some
other
romanized
name,
latinized
name
whatever
you
want
to
call
it.
F
F
Think
just
some
of
them
I
mean
concept
is
good.
Yes,
lean
towards
kind
of,
maybe,
as
Pete
said,
properties
like
name
phonetic
name
and
nickname,
are
probably
a
couple
most
cases,
but
at
least
for
the
name
one.
It's
an
array
of
tagged
objects,
whereas
the
other
two
may
be
just
be
straightens.
Phonetic
name
is
just
yeah.
Whatever
a
nickname
is
just
a
string.
I
think.
F
F
F
F
And
I
said
you
want
at
least
four
simple
things:
I
just
want
the
address
to
print
great
just
map,
dot
value,
join
they've,
told
you
how
it
should
be
presented.
You
get
the
value
and
you
write
it
down,
but
if
you
do
yeah
exactly
so
yeah,
that's
the
concept.
I
think
this
works
at
least
better
than
the
other
things
we've
seen
so
far
better
than
B
card.
Another
garbage
does
so
it
will
have
some
kind
of
draft
by
next
time.
F
The
good
news
is
this:
is
the
hard
bit
of
j
map
contacts,
the
data
format
once
once
we
have
that
defined.
I
I
think
that's
gonna
be
much
easier
spec
than
my
gem
account,
so
J
map
mail
to
put
together,
and
then
we
have
that
the
full
suite
of
contacts
mail
calendar
which
we
very
nice
over
consistent
protocol,
so
we'll
see
when
this
gets
finished,
but
yeah,
maybe
but
in
the
next
year,
if
we're
lucky.
F
A
A
A
A
F
But
if
we
can
kind
of
say
this
is
how
you
set
it
up
in
a
way
that
we
pretty
much
we
use
everywhere.
That
will
be
easier
for
servant
hunters
and
what
keeps
it
easier
for.
Everyone
I
think
that's
the
main
goal
as
far
as
I.
Well,
that
person
actually
having
maybe
a
one
for
y
map
that
uses
that.
So
you,
maybe
it's
even
just
a
best
contractors
document
for
the
kind
of
abstract,
or
this
is
how
you
set
up
a
push
channel
thing.
C
A
Yeah
there's
two
drafts
that
are
both
in
a
similar
area,
which
is
why
I
thought
bring
me
the
question
of.
Should
all
this
happen.
In
one
place,
one
of
them
came
from
Cal
connect
from
Martin,
and
that
has
already
been
published
as
an
ITF
personal
draft
a
couple
of
years
ago
and
expired
since
he'd
like
to
bring
that
back
up
again
and
the
other
ones
quite
recently
from
dovecot
for
IMAP.
As
part
of
that
she
had
over
IMAP
stuff,
they
wanted
to
add
push
there.
A
A
A
A
D
L
A
Know
why
no
one
is
listen
because
they're
not
perfect,
all
right,
so
next
thing
on
the
list
is
milestone
review.
Those
are
the
three
milestones
that
we
currently
have
listed:
a
submit
document
with
guidance
for
implementation
of
time
of
servers
and
proxies,
which
we
promise
that
early
on
we
have
not
done.
Yes,
we
did
you
signed
up
from
the
initial
charter.
We.
H
H
H
It's
a
question
whether
you
prefer
having
a
milestone
that
is
known
to
be
totally
unrealistic,
but
near-term,
and
you
know
that
they're
gonna
keep
changing
it
and
changing
it
and
changing
it
or
whether
you
just
want
to
admit
that
this
is
work.
You're,
gonna
Park
for
a
while,
but
you
will
get
back
to
it
eventually
and
then
you'll
change.
The
milestone
is
something
reasonable.
My
preference
is
the
latter,
but
you're
the
responsible
ad.
For
this
so
I
said.
C
C
A
A
C
A
Corps
but
he
keeps
having
other
priorities
all
right.
No,
it's
all
right.
We
will
NEX.
Next
year's
plan
includes
cleaning
things
up,
and
this
is
part
of
that.
All
right
submit
message:
disposition
notification,
September
2019
that
one
I
will
bump
to
December,
because
I
think
the
only
reason
didn't
get
submitted
was
that
I
didn't
follow
up
with
the
authors
and
say:
let's
go
Jemma.
Hoho
WebSockets
likewise
is
going
November.
C
A
Gonna
say
2020s
mom
I've
already
said:
I
was
gonna,
say
Feb
20
24,
the
simple
one,
and
likewise
for
adopting
an
addition
document
for
the
more
complex
s/mime.
Fine
cool
ambience
covers
jamot
calendars.
We've
said
we'll
push
that
out
to
July
next
year
and
then
decide.
What's
do
that
and
jeaious
contact
realistically
well
we'll
go
to
adopt
it
first,
so
we
won't
set
a
milestone
for
it
at
this
meeting.
Well.
A
A
C
A
A
No,
we
have
a
plenty
of
work
to
get
on
with,
but
I'd
love
to
certainly
see
some
more
interrupts
with
the
general
calendars,
but
I
expect
that
will
mostly
be
happening
through
Cal,
Connect
and
other
than
that.
The
quota
works.
Probably
the
immediate
thing
that
we
should
be
discussing
on
the
list
and
giving
that
nailed
down
mdn
almost
would
be
contact.
Meiosis
and
saying:
do
you
think
you're
ready
to
go?
Maybe
you
should
implement
as
well
tester
all
right
anything
else.