►
From YouTube: IETF110-JMAP-20210311-1600
Description
JMAP meeting session at IETF110
2021/03/11 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
All
right,
according
to
the
clock,
it's
time
so,
let's
get
started.
Welcome
to
the
gem
map
virtual
meeting
in
prague,
except
not
and
with
random
sleep
as
usual.
We
we
cover
right
at
the
start
that
we
are
covered
under
this
note.
Well,
we
often
just
kind
of
skip
through
this,
because
most
of
us
are
very
used
to
it.
It's
easy!
If
you
search
iatf
noteworld,
to
find
a
more
readable
version
of
this
and
what's
on
the
screen
here,
but
mostly
it's.
If
you're
aware
of
any
patents,
then
then
you
need
to
mention
disclose
them.
A
If
you
participate
in
discussion,
these
recordings
may
be
made
public
and
behave
yourself,
be
a
good
non-harassy
code
of
conduct
the
following
person.
This
is
the
rough
agenda
that
I
put
put
together.
I
probably
should
put
a
disclaimer
on
these
agendas
when
I
put
them
together
that
we
often
don't
spend
exactly
the
time
that's
mentioned,
for
each
document
we'll
spend
longer
on
some
shorter
on
others.
A
So,
don't
assume
that
you
can
show
up
exactly
70
minutes
into
the
meeting
and
you'll
be
at
exactly
the
thing
that
we
say
is
going
to
be
70
minutes
in,
but
we'll
try
and
stick
to
this
order
before
we
get
started.
Does
anyone
have
anything
you
want
to
change
on
this?
Any
anything
to
add,
remove
the
whole
agenda
bash.
A
Not
seeing
anything
awesome,
I
guess
let's
get
straight
into
I've,
divided
it
roughly
up
into
three
sections
the
calendars
and
related
things,
calendars
tasks
and
sharing
all
come
under
that
no
necessary
need
to
stay
in
a
particular
order,
but
this
is
what
we
have
then
js
contact
and
all
the
stuff
related
to
that
there's
a
couple
of
different
drafts
in
there.
But
I've
just
mentioned
just
one
thing
and
then
blob
is
there
with
sieve,
because
it's
mostly
set
up
for
that,
but
will
also
be
used
for
other
things
and
any
other
business.
A
B
Hi,
yes,
so
I
think.
B
As
as
japan
said,
would
be
gender
well
time,
stuff's
not
being
quite
right
but
j,
but
for
calendars,
so
I've.
B
I
think
we
had
a
discussion
last
time
and
so
there's
been
quite
a
few
changes
in
the
draft.
Based
on
that,
so
I
thought
I'd
just
give
a
quick
summary
of
what
those
changes
are
see.
If
there's
any
things
people
discuss
about
that
and
then
I
think
the
main
thing
to
talk
about
is
really
how
the
tasks
relate
to
it
and
yeah.
So
we'll
get
to
that.
So
if
we
go
into
the
next
slide.
B
So
the
main
changes
in
the
version
five
draft,
which
is
the
new
one
since
last
meeting,
is
whether
you
act
as
yourself
or
as
the
person
owns
the
calendar
is,
is
now
the
same
for
all
calendars
within
a
particular
account
which
just
simplifies
some
things
and
the
the
set
of
identities
of
the
the
to
determine
who
you
you
are
comes.
B
It
is
a
proper
data
type
rather
than
just
being
a
random
property
on
stuff,
so
that
they
can
just
simplify
things
and
an
event
may
belong
to
multiple
calendars
within
an
account.
Although
this
is
up
up
to
the
server
the
server
can
say
as
with
bail
that
I
only
supported
being
in
one
if
it
was.
But
yes,
this
is
one
of
this
is
one
of
those
ones.
B
We've
talked
about
quite
a
bit
last
time
and
it's
kind
of
tricky,
because
there
are
many
systems
that
it's
out
there
at
the
moment
that
do
have
it
more
than
one
and
it
does
increase
complexity,
but
if
we
put
it
in
there,
it's
more
consistent
with
the
male
spec
and
gives
us
kind
of
the
protocol
the
ability
to
support
multiple.
B
Even
if
we
don't
need
it
all
the
time,
because
the
server
can
say
I
only
I
actually
wanted
to
be
in
one
at
a
time
and
then
the
biggest
thing
is
splitting
sharing
out
to
a
separate
spec,
because
I
realized
that
this
was
actually
quite
generic
and
something
that
we
would
want
to
use
for
various
alpha
for
mail
and
for
various
other
things
as
well.
B
So
the
sharing
spec
defines
principles,
which
is
all
the
entities
in
a
shared
system
like
individuals
or
groups,
or
resources
and
kind
of
get
sets
up
the
framework
for
how
you
would
then
assign
permissions
to
one
of
those
entities
to
give
permission
for
for
for
shared
data
access
and
also
the
model.
Where
you
have
a
permission
system
say
you
can
access
it
and
then
the
person
that's
had
been
shared
with
then
gets
to
subscribe.
To
that
to
say.
B
Yes,
I
actually
want
to
to
access
this
one,
which
is
basically
what
we
were
doing
before,
but
just
yeah
making
it
a
separate
spec.
So
it's
easily
reusable
as
we'll
see
with
the
task
stuff,
because
the
task
will
want
to
use
all
of
that
as
well
as
calendars.
B
So
if
we
just
move
on
to
the
next
slide,
if
anyone
has
any
questions
or
comments
do
jump
in
so
the
next
steps,
still
big
thing,
we
need
to
save
this
last
time
is
implementation
experience.
But
this
time
we
are
we're
getting
close
to
actually
having
implemented
all
of
this
stuff.
I
think,
and
at
least
and
having
one
set
of
experience
to
talk
about
by
the
next
meeting.
B
I
would
hope
we'll
have
some,
so
we
can
share
any
experiences
there
and
obviously
any
find
any
problems
that
we
run
into,
and
I
hope
we
might
see
some
others
as
well
and
then
yes,
I
think
tasks
is
probably
the
best
thing
to
discuss.
At
this
meeting.
B
We've
had
people
coming
along,
saying
that
they're
interested
in
that
as
well
and
spec
has
been
contributed,
and
so
I
think
that
the
biggest
discussion
is
whether
we
should
be
merging
that
with
calendar
spec
like
kaladev,
does
or
keeping
it
separate,
and
how
much
there's
that
there's
you
know
what
what's
cleaner.
What's
easier
from
that.
B
So
I
think,
john,
I
don't
know
how
you
want
to
do
this
like
yeah,
unless
anyone
has
any
particular
calendar.
Various
things
I
think
talking
about
tasks
will
be
the
best
thing
to
do
here.
Is
there
a
separate
presentation
or.
A
Sure
we
don't
have
slides
for
it,
but
we
have
people
to
talk
so
yeah.
C
Question
so,
regarding
the
calendar
events
in
multiple
calendars,
I
was
just
wondering
if
we
have
already
figured
out
the
semantics
of
deleting
or
changing
an
event
what
it
means
for
events
in
that
are
in
multiple
calendars.
So,
if
you,
I
guess
changing
an
event,
would
change
it
in
all
calendars
where
this
event
is
located
in.
D
B
Yeah,
okay,
so
if
you
destroy
the
event
you're
destroying
it
everywhere,
but
you
can
update
it
to
change
which
calendar
it's
in.
D
B
Or
removing
them
and
there's
only
one
and
it's
the
same
in
all
of
them.
Obviously,
it's
one
copy
of
the
event
they're
more
like
labels.
E
A
E
Yeah,
my
audio
did
get
cut
off
there
yeah.
So
it's
it's
basically
we're
limiting
the
problem
that
kel
dev
scheduling
had
with
things
in
multiple
calendars.
As
long
as
you
find
one
of
the
instances
you
go
ahead
and
update
all
of
them,
with
whatever
changes
have
come
back
from
the
organizer
of
the
attending.
B
B
Yeah
one
restriction,
it
adds
I
I
don't
know
if
I
think
this
is
audio
section,
you
can't
have
yes
the
same
event
but
different
in
different
calendars.
Within
the
same
account,
you
can
have
it
different
within
different
accounts
like
people
might
have
different
versions
of
it
or
different
permissions
to
view
different
bits
with,
but
within
a
single
account
which,
like
you
know,
one
user's
set
of
calendars,
there's
a
consistent
view
of
that.
B
F
F
All
right,
yeah,
so
hello,
everybody.
So,
as
neil
already
introduced,
we
came
upon
gemma
calendars
and
found
basically
that
something
something
similar
would
also
be
fine
for
tasks,
particularly
due
to
the
fact
that
related
standards,
like
calderf
actually
already
deal
also
with
both
of
them
and
many
tools
actually
also
do
it
handle
in
in
a
dual
way.
So
it's
kind
of
natural
in
that
sense
to
think
about
also
having
some
gmap
representation
for
tasks.
F
So
what
we
did
basically
is
we
we
drafted
a
very
initial
or
created
a
very
initial
draft.
You
see
the
url.
G
F
For
this
jmap
for
tasks,
there
is
certainly
a
lot
of
stuff
still
open,
not
everything
even
mentioned
here,
so,
in
contrast
to
jmf4
calendars,
this
is
like
you
see
the
zero
zero
version
of
the
draft,
so
don't
expect
too
much
about
it
already.
F
But
obviously
this
is
a
nice
way
here
to
to
kick
it
off.
Also
a
little
bit.
There
was
a
little
bit
discussion
on
it
also
already
on
the
mailing
list.
So
one
thing
that
was
some
weeks
ago
already
is
a
point
about
capabilities
which,
which
I
think
yogurt
initially
raised,
who
was
the
main
author
but
cannot
be
with
us
here
today?
F
Unfortunately,
and
one
thing
here,
I
think
which
which
should
be
differentiated
a
little
bit-
and
I
think
that
goes
also
in
the
direction
like
neil
raised
if
it
would
be
an
option
to
merge
it
into
the
jmap
calendar
draft
or
keep
it
separate,
and
what
what
our
observation
is
a
little
bit,
even
though
both
things
are
tightly
related,
as
I
said
also
in
calderf,
I
think,
from
an
interoperability
perspective,
there
is
a
little
bit
of
a
difference
so
calendars,
I
think,
by
nature
quite
interoperable
right
now.
F
You
know
many
calendar
tools
can
work
together
and
also
the
data
models
for
calendars
are
in
a
way.
Quite
you
know
similar
between
different
tools,
but
for
for
tasks.
We
actually
see
more
heterogeneity
here.
If
you,
for
instance,
consider
something
like
google
task,
it's
super
limited.
I
think
it's
just
three
or
four
properties.
You
cannot
do
that
much
there
and
the
more,
I
would
say,
extensive
models
like
you
also
have
in
in
calder
or
icalendar.
F
F
Let's
say,
slim
approach
to
tasks
have
been
being
possible
or
able
to
support
the
standard,
but
also
tools
which
do
support
more
advanced
features
like
reminders,
and
I
think
for
that
something
like
more
fine-grained
capabilities
would
certainly
make
sense.
F
I
mean,
I
see
the
point
I
think
neither
was
it
that
raised
it
on
the
mailing
list
that
obviously
it
also
makes
things
more
difficult
for
some
implementers
of
the
standards,
and
I
think
that's
one
important
design
decision
or
trade-off
to
discuss
here,
like
you
know,
where's
the
sweet
spot
or
what
is
what
is
like
the
aspect.
F
We
want
to
put
more
focus
on
yeah,
so
I
don't
know
if
I
should
first
skip
through
the
points
or
if
we
want
to,
if
there's
some
feedback
directly
on
that
or
some
some
opinion,
I
don't
know.
B
F
B
Yeah,
sorry,
I
think
you
you
want
to
find
that
right
balance.
You
want,
you
know
enough
capabilities
to
support
different
use
cases,
but
not
so
many
that
becomes
impossible
to
write
a
client
because
you
just
have
a
infinite
combination
of
possible
server.
Support
to
you
know
deal
with,
which
is
a
bit
what
we
see
with
ibap,
with
the
different
extensions
and
capabilities
there,
and
so
people
end
up
just
using
the
very
basic
stuff
that
they
can
rely
on
everywhere.
B
Yeah-
and
I
agree
this
is
more
of
an
issue
with
with
tasks
and
calendars
probably,
but
I
I
think
I
think
this
probably
is
quite
doable,
though,
as
you
say
I
think,
but
you
know
there's
some
big
ones
that
you
can
say
you
know.
Can
you
assign
people
to
a
task?
That's
yeah,
a
pretty.
H
B
And
reminders
and
stuff,
so
I
I
I
think
we
could
come
up
with
set
of
capabilities
and
and
it
doesn't
really
affect
necessarily
whether
it's
in
a
separate
draft
like
it's
a
separate.
You
know
spec
to
calendar
smash,
because
even
if
it
was
in
the
same
spec,
it
would
definitely
be
behind
a
separate
capability.
B
Set
of
yeah
stuff
like
this
separate
to
canada
yeah,
but
it's
an
important
point,
because
this
is
yeah.
One
of
the
main
things
we're
trying
to
work
out
here
is:
where
does
task
differ
from
calendars?
And
how
much
does
it
differ?
I
think
and
yeah.
A
Of
those
areas,
yeah.
B
B
Is
there
any
it's
just
if
there's
a
lot
of
copy-paste
stuff,
I
think
really
which
there
is
at
the
moment,
but
I
think
probably
could
be
sorted
more
through
editing
without
necessarily
merging
the
documents
yeah
like
I
I
you
know,
I
definitely
initially
wanted
them
separate.
I
kind
of
still
think
that
would
be
cleaner,
but
I
think
we'll
see
a
bit
as
we
progress.
F
A
F
I
mean
in
either
way
I
think
it's
perfect
because,
as
you
said,
I
mean
certainly
there
is
some
sort
of
an
overlap,
and
it's
always
not
so
nice
to
have
you
know
to
maintain
reference
and
copy
paste
stuff.
So
we
might
also
see
a
little
bit
like
how
this
evolves
in
in
one
more
version.
F
Also,
I
think
one
point
for
keeping
it
separate,
maybe
is
also
the
the
current
stage
since
I
think
the
jmf
for
calendars
it's
much
more
advanced
already,
and
this
is
in
a
way
earlier,
even
though
might
not
be
that
complicated
in
the
end,
but
still
combining
it
in
that
way.
Might
you
know
make
it
slower
for
jme
for
calendars?
F
Somehow,
also
I
don't
know
or
complicated,
but
yeah
that's
something
yeah,
okay,
and
for
the
capabilities
I
I
would
yeah,
I
would
say,
as
you
said,
I
think
the
things
that
come
to
my
mind
is
maybe
just
three
or
four
core
things.
So,
like
people
are
assignees
attendees,
this
kind
of
stuff
recurrences.
Certainly
so
not
many
tools
are
supporting
recurrences
in
tasks,
even
though
some
do.
F
What
else
did
I
mention
attachments?
Certainly
is
one
thing
which
not
every
tool
supports
for
tasks,
and
I
think
that
I
think
I
had
one
more,
but
I
think
I
mentioned
even
one
more
already.
I
think
that
reminds.
F
Yeah,
so
so
these
are
the
core
things
which
I'm
aware
of
which
you
know
are
not
the
standard
feature
set
in
in
a
task
system,
whereas
they
are
in
in
a
calendar
system,
and
so
it
would
be
nice
and
I
think
it
would
just
be
doable
for
implementers
to.
I
think
it's
not
as
complicated
as
in
the
imap
case.
Actually
with
all
those
features
there
I
think,
are
much
more.
A
B
Yeah,
I
think
those
are
all
easily
put
buying
capabilities,
so
I
think
that
that's
okay,
I
think
the
bigger
question
to
me
again
how
different
this
is
between
different
task
matches.
I
haven't
really
done
a
survey
or
anything.
D
B
This
kind
of
issue
of
how
different
is
a
task
list
from
a
calendar
like
so
one
of
the
main
differences
is
at
least
in
the
to-do
list.
I
use
it's
there's
a
manual
order
for
the
set
of
to-do's
in
a
list
and
you
can
drag
and
drop
to
rearrange
them
and
stuff,
and
so
I
think
that's
something
you
can't
support,
whereas
with
events
there's
no
ordering
within
the
calendar
other
than
by
date
or
whatever
other
property.
You
want
to
use.
F
That's
actually
a
very
good
point.
Actually
there
was
one
I
was
personally
missing.
Obviously
so
I
didn't
think
about
it.
I
I
still
need
to
look
it
up.
It
doesn't
it.
It
seems
to
make
sense
what
you
say,
but
and
actually
at
least
from
the
from
the
groupware
system
supporting
tasks.
Let's
put
it
that
way,
I'm
not
aware
of
any
really
using
that
so
most
just
sort
the
tasks
by
date
or
status,
or
something
like
that,
but
I'm
pretty
sure
you
find
something
where
the
order
makes
some
difference.
F
Maybe
even
it's
google,
I
I
need
to
look
it
up.
I
think.
E
E
B
E
B
Yeah,
I
think
you
definitely
need
support
for
that.
I
I
agree.
It's
it.
You
know
different
mountain
to
do.
Taskless
managers
have
different
approaches
to
this,
but
that's
kind
of
what's
kind
of
the
point
earlier
is:
there
is
more
heterogeneity
here,
and
so
the
interesting
thing
to
me,
then,
is
if
they
have
a
sort
order
doing
a
many
to
many
mapping.
You
know
the
whole
thing
you
know
makes
less,
perhaps
less
sense
that
you've
been
with
events.
I
don't
know
kind
of
to
do
be
in
more
than
one
to-do
list.
B
If
it
is,
you
probably
need
multiple
sort
order
properties
as
well,
because
otherwise
you
can't
you
know
you
need
to
specify
where
it
is
in
each
of
those
lists
so
yeah.
I
don't
know
whether
you
want
to
make
it,
but
just
one
too
many
rather
many
too
many
mapping.
F
Personally,
I
would
say
first
of
all,
I
would
say
the
sort
of
thing
sort
of
makes
some
sense
and
I
agree
with
you.
It
will
be
complicated
in
the
situation
of
multiple
task
lists
and
it
will
make
you
crazy
to
support
multiple
thought
orders
for
different
task
lists.
I'm
not
sure
if
this
is
really
what
somebody
wants,
and
especially
since
this
multiple
tasks
is
sort
of
motivated
by
this
kind
of
label
kind
of
stuff
right
and
here
actually.
F
We
are
in
a
sort
of
systems,
you
know
shuffling
together
the
concept
of
a
folder
and
a
label
like
you
have
in
gmail.
Actually
you
see
so
in
gmail
you
can.
You
can
actually
effectively
have
a
label
in
the
gmail
sense,
but
if
how
google
exposes
it
via
imap,
it's
a
folder
yeah,
so
it
already
breaks
in
their
own
exposition
within
their
own
ui
and
how
they
do
it
on
imap.
So
you
see
this
discrepancy
a
little
bit
between
using
folders
as
labels
and
labels
as
folders.
B
Feature
no
well,
you
need
to
be
able
to
store
it
somewhere,
because
you
know,
if
I
have
my
tasks,
a
b
c,
I
want
to
see
them
as
a
then
b,
then
c
in
both
clients.
You
know,
in
fact,
more
than
one.
I
I
B
I
I
B
The
the
thing
is
this
is
not
like
storing,
oh,
you
should
sort
by
this
property.
You
know
by
by
date,
it
it
say,
is
the
ability
for
the
user
to
store
for
the
server
a
manual
order
for
stuff
that
makes
sense.
F
I
I
think
the
point
mike
wanted
to
make
is
a
little
bit
like
if
there
should
be
a
distinction
yeah
by
client.
First
of
all,
where
I
would
also
disagree.
This
is
strictly
required
because
I
don't
see
really
a
use
case
for
that
or
if
there
is
one
client
to
do
it
by
themselves,
and
the
second
point
mike,
if
I
got
you
correctly,
is
for
a
collaborative
approach
where
I
share
a
certain
task
list.
If
there
should
be
different,
thought
orders
possible
for
different
uses.
Is
that
what
you
meant
right.
F
And-
and
my
point
on
that
would
also
be-
I
think
it's
it
would
be-
maybe
engineered
a
little
bit
over
the
top.
So
I
would
assume
if
a
team
shares
really
a
task
list
there
is
I
mean
if
they
decide
to
share
the
task
as
an
artifact.
I
think
also
the
sorting
is
sort
of
an
you
know
designed
order
which
the
team
shares,
so
I
I
would
be.
I
think
I
would
be
rather
confused
in
the
team.
If
I
shared
half
this
and
everybody
would
maintain
a
separate
order
of
it
on
the
shared
list.
F
I
I
think
I
see
where
you're
coming
from
mike.
I
think
you're
you're
thinking
a
little
bit
about
the
chat
calendar
issues
here,
but
I
think
it's
a
little
bit
different
for
for
a
private
copy
of
an
event.
I
have-
and
I
want
to
maintain
some
some
private
state
for
that.
F
B
I
think
the
difference
here
is
within
it
for
for
a
task.
The
source
order
is
actually
kind
of
part
of
the
data,
because
it's
quite
a
way
for
you
for
the
user
to
ad
hoc
and
say
what
order
should
these
things
be
done
in
roughly,
probably
because
by
manually,
dragging
and
dropping
them,
whereas
for
the
task
list
like
calendar,
that
would
also
have
a
sort
order.
B
I
I
B
B
B
If
you
want
to
like
to
say
like
on
the
to-do
list
itself
to
say
default,
sort
by
due
date,
rather
than
buy
the
sort
order,
property
right,
but
it's
this
is
for,
if
you,
if
you're
in
your
clients,
yours
you've
covered
sort
of
drop
down
instead
of
sorting
by
due
date,
you
click
sort
manually,
and
now
you
want
to
drag
and
drop
them
into
some
particular
order.
Just
for
you
well,
not
just
yeah.
B
B
J
J
J
The
the
the
use
of
the
folder
construct
as
an
actual
storage
model
is
really
simple
and
extremely
useful.
If
the
model
laying
on
top
of
the
access
mechanism
is
one
that
says,
every
query
is
a
search
which
is
what
I
think
I'm
hearing,
even
though
I
don't
think
it's
quite
what
you
think
you're
saying
then
you've
just
altered
the
cost
of
using
this
by
a
lot.
B
Yeah,
I
think
that's
mainly
to
do
with
whether
we
have
a
one
to
many
or
many
too
many
mapping
for
the
dave
to.
B
If,
if
a
task
can
just
be
one
to-do
list,
well
then
it
also
it
depends
whether
we
want
yet
another
kind
of
level
of
hierarchy
as
well
over
you
know,
can
does
a
to-do
list
get
to
create
folders
for
those
as
well.
That
kind
of
thing,
but
I
I
I
guess
there
is
there-
is
a
bit
of
a
query
in
terms
of
how
many,
how
many
tasks
are
in
a
list
like
do
you?
B
If,
if
we
expect
it
always
to
be
a
you
know,
not
too
high
number,
you
could
say
that
the
list
itself
is
the
unit
of
data
and
you
fetch
the
whole
list,
which
is
an
array
of
tasks
rather
than
querying
the
server
for
tasks
and
saying
find
me
ones
that
match
this
list,
which
requires
it
to
do
some
kind
of
filtering,
but
I
don't
think
the
spec
requires
you
to
do.
B
I
don't
think
spec
with
the
current
kind
of
approach
is
forces
you
not
not
to
be
able
to
use
folders
and
stuff
like
you'd
say
I
I
so
I
I
don't
think
we
straight
into
that,
but
it's
a
good
point.
A
Having
implemented
some
other
gmap
stuff,
often
what
we've
done
is
we
detected
a
search
is
a
in
folder
id
this
and
no
other
conditions
and
convert
that
into
a
very
cheap
return.
The
list
of
the
folders.
So
it's
more
like
an
sql
optimizer
than
a
pure
mapping
to
underlying
behavior.
So
you
you
can
make
those
kinds
of
queries
cheap,
even
if
they
are
expressed
as
a
search.
D
B
I
I
think
it
probably
should,
or
at
least
we
should
survey
kind
of
you
know,
does
it
look
like
this
data
model
would
meet
that
use
case
if
trello
decided
they
wanted
to
support
an
open
data.
You
know
access
format
next
year
kind
of
thing,
and
if
it
doesn't,
then
we
should
at
least
discuss
why
it
doesn't,
whether
that
we
should
make
changes
or
whether
we're
happy
with
that.
F
F
We
already
started
yeah,
so
we
looked
already
a
little
sorry.
We
looked
already
a
little
bit
into
it
and
I
would
also
from
again
data
portability
perspective.
We
try
actually
to
to
see
if
something
like
trello
fits
in
here
as
well,
because
what
we've
seen
so
far,
we
looked
already
into
it.
It
fits
in
already
quite
well,
so
I
think
we
cover
a
lot
already.
F
We
didn't
dig
into
every
detail
yet,
and
I
think
that
will
be
very
interesting
for
some
of
these
points
we
just
discussed,
but
the
overall
goal
would
actually,
if
it's
not,
you
know
totally
stepping
away
from
from
the
core
task
model
here.
We
should
certainly
try
to
make
that
compatible
as
well,
so
it
can
be
used
as
an
exchange,
format
or
interoperability
approach
for
those
trello
style,
kanban
style
systems
as
well.
F
I
I
know
some
time
back.
I
had
a
discussion
with
somebody
who
got
very
excited
about
some
of
the
features
we
were
talking
about
with
with
the
eye
counter
tasks
and
and
his
he
had
a
job
of
transferring
this
gets
to
date,
availability
because
he
he
had
the
task
of
transporting
project
management,
data
from
between
different
systems
and
the
icon.
The
data,
essentially
is
a
perfect
match.
What
was
missing
is
as
any
export
and
import
tool
on
those
on
those
applications.
I
They
they
tend
to
work
in
their
own
and
because
nobody's
tried
to
force
them
into
it.
They
they
produce
their
own
data
and
they
don't
allow
you
to
to
transport
it,
but
it's
a
pretty
much
of
a
perfect
match.
You
know,
you've
got
people
you
assign
stuff
to
you've,
got
a
lot
of
properties
and
so
on
and
so
forth.
So
it
would
be
a
pity
to
lose
that
capability
in
in
the
in
the
in
this
world,
always
I
mean
but
base.
I
J
So
so
apologize
for
the
audio
problems
I
was
having
medico
doesn't
do
echo
suppression
the
way
other
systems
do.
Oh.
D
J
Yeah
the
echo
does
meet
yes,
so
I
I
I
think
I
can
clarify
what
I'm
thinking
about
the
folder
versus
search
there.
There
is
a
model
that
says
everything
is
a
search.
You
can
set
a
default
and
that
becomes
what
you
get,
if
you
don't
say
some
new
search
and
that
imposes
a
potentially
very
substantial,
underlying
complexity
on
the
implementation.
J
There's
a
different
approach,
which
says
default
well
start
with
default,
which
says,
however,
you
want
to
give
it
to
me,
give
it
to
me
and
that
supports
a
folder
model.
If,
if
that's
what
the
underlying
implementation
wants
to
do
and
then
search
is
something
separate
and
then
the
way
you
can
merge
them
is
by
saying
that
you
can
go
to
set
the
default
to
be
a
search,
but
the
underlying
implementation
can
reject
that
effort.
F
J
Is
its
way
of
saying
no,
I've
got
my
way
of
doing
things.
That
is
not
a
search,
and
you
don't
get
to
change
that
and
that
lets
the
the
things
proceed
with
a
potentially
cheap
implementation
that
continues
to
work
within
the
model
that
you've
got
where
search
is
still
available,
but
it
doesn't
alter
the
implementation
requirements.
B
Yeah,
I
think
I
think
in
jmap
the
way
that
works
is
so.
The
kind
of
api
is
consistent
in
that
it's
all
slash
query,
which
is
kind
of
a
search,
but
we
we
could
allow
the
server
to,
for
example,
only
support
a
search
which
is
really
return
everything
in
this
folder,
if
that
makes
sense.
So
in
that
case
this
you
know
it's
not
really
a
search
anything
else.
It
can
go.
As
you're
saying
I
don't
support
that.
I
only
support
these
simple
type
of
queries.
J
So
the
scope
of
the
search
is
a
different
issue.
I
hadn't
been
thinking
about,
and-
and
I
I
I'm
more
concerned
with
I
mean
gmail-
is-
is
an
environment
where
everything
is
a
search,
no
surprise,
that's
who
they
are,
but
that's
not
the
way.
An
awful
lot
of
email
systems,
mua
environments
are
designed
and
my
concern
is
imposing
the
gmail
activity,
which
is
which
is
great
when
you
like
it,
but
not
so
great.
If
you're
trying
to
do
a
more
classic
kind
of
implementation,.
F
I
I
think
dave
I
would
support
actually
your
claim
on
the
on
the
simple
folder
model
here,
also
due
to
a
little
bit
of
a
practical
experience,
because
I
think
typically
in
a
task
system,
you
won't
have
as
many
items
as
you
have
in
an
email,
folder
or
something
like
that,
because
in
the
end
any
task
is
do
not.
I
can
craft
it
and
it
might
be
more
than
10.
I
think
somebody
mentioned
before,
but
it
won't
be
five
thousand
physically.
At
least
I
have
not
seen
that
in
fact,.
F
Yeah,
obviously,
but
I
think
in
based
on
empirics,
I
think
it's
it's
rather
unusual
and
I
think
the
advantage
of
many
of
those
search
based
approaches
and
actually
jmap
in
a
way
has
some.
You
know
tendency
towards
that
for
optimization
of
mobile
clients
like
to
only
transfer
data,
which
is
like
really
required
in
a
certain
situation,
somehow
yeah.
F
So
I
think
this
is
maybe
a
question
to
the
you
know
more
godfathers
of
jmap
here,
like
what
is
do
we
want
to
preserve
the
jmf
spirit
on
that
or
would
be
fine
actually
to
go,
which
I
would
actually
be
fine
with
to
go
with
a
more
simple
approach
here
for
the
task
to
leave,
maybe
something
like
the
sorting
to
the
client
even
submitting
all
tasks
for
a
folder
to
the
client,
even
if
that
might
be
more
tasks
than
the
client
want
to
display.
At
one
point.
F
Actually,
I
also
don't
see
so
much
of
a
use
case
for
just
querying
a
subset
of
the
tasks,
because,
typically,
if
I
want
to
manage
tasks,
I
want
to
see
all
tasks.
Somehow
I
don't
want
to
have
for
for
a
re-order
or
re-prioritization.
I
don't
want
to
have
actually
the
client
need
to
re-sync
with
the
server.
Probably
I
don't
know.
I
Why
not?
I
mean,
I
think
somebody
who's
trying
to
do
stuff
like
what
have
I
got
to
get
finished
today?
What
are
what
are
the
top
10
easiest
tasks
to
deal
with
one
of
the
yeah
and
there's
all
sorts
of
things
you
could
imagine
doing
as
a
as
a
quick
search
and
and
on
size
of
things
I
mean
there's
a
a
mobile
development
system,
which
currently
has
some
like
8
000,
outstanding
tickets
on
it
yeah?
What
about
an
imac?
What
about
your
mail
inbox
when
you
have
people
with
multi-megabyte
gigabyte
indexes?
I
A
A
In
there,
so
that
you
can
see
in
the
history,
there's
37
and
a
half
thousand
tasks.
I
In
there
at
the
moment,
yeah
I
mean
scientists
need
to
be
able
to
feel
it.
We
should
just
assume
large
and
yes
and
support
small,
but
it
that
people
do
want
to
see
filtered
views
of
of
stuff.
I
What's
the
stuff
related
to
the
kernel,
what's
the
stuff
related
to
this
particular
device
driver
or
whatever
and
and
the
even
you
know
what
have
I
got
to
buy
today
when
I
go
out
shopping.
B
Yeah
I
mean
I
actually.
I
think
this
discussion
is
really
just
down
to
again
what
capabilities
the
servers
are
mandated
to
support
and
which
ones
they
can
optionally
support
for
slash,
query
the
standard
kind
of
call
for
tasks,
that's
really
what
it
comes
down
to
and
I'm
sure
we
can
find
a
solution
like
we
did
with
mail
that
allows
existing
servers
to
support
it
reasonably
easily,
but
also
allows
for
advanced
capabilities
if
yeah,
if
they
can.
A
No,
no,
it's
just
those
two,
so
I
guess
we
we're
pretty
much
coming
up
at
time
for
this,
so
we
probably
should,
I
think,
there's
two
things.
We
should
do
a
call
for
adoption
for
this
document
if
we
think
that
this
is
something
we
want
to
adopt
into
the
working
group,
because
we
haven't
officially
done
that
yet
that
would
be
done
on
the
mailing
list,
but
do
we
think
that's
something
we
should
be
going
ahead
with
yeah?
I
do
guess
yeah,
I
do
cool
well,
some.
A
We
will
we'll
do
that
then,
and
so
yeah,
the
question
of
whether
a
task
can
be
in
multiple
tasks.
I
think
a
lot
of
these
questions
come
down
to
surveying
what's
out
there
now.
So
I
think
that's
probably
a
good
next
step
is
to
collect
some
examples
of
systems
that
we
want
to
support,
and
ideally
even
maybe
talk
to
people
who
work
on
those
systems
and
get
an
idea
of
what
their
challenge
points
have
been.
F
But
but
for
instance,
if
there's
some
whatever
itf
tool
that
says
you
give
me
the
trello
representative
in
itf,
if
there
is
any
or
something
like
that.
A
F
A
Liaisons
page
and
it's
got
1
600
lines
in
it
going
back
to
1995
and
it's
it's
unusable
to
figure
out
who
people
are
and
they're
generally
liaisons
for
the
standards,
but
he's
not
with
individual
companies.
D
Okay,
but
but
if
people
have
particular
contacts
have
friends
at
these
places,
you
know
please
speak
up
and
we'd
like
to
take
advantage
of
that.
I'm
sure.
A
B
I
think
it
was
just
in
my
earlier
point
about
separating
it
out,
but
that's
really
here
is
this
the
same
model
as
before?
It's
just
in
a
separate
document,
so
you
can
easily
reference
it.
I
Cool
well,
it's
it
sort
of
parallels
what
we
did
with
what
what's
been
done
with
with
dev
sharing.
I
mean
we
realized
that
it
was
really
distinct
from
calendars.
B
G
Yeah,
I
I
had
a
quick
read
today
and
it
looks
reasonable.
I
probably
will
send
some
specific
questions
where
things
might
be
unclear
general
comments.
Probably
more
examples
would
be
useful.
B
A
Cool
moving
right
along
then
whoop,
sorry.
A
C
Hello,
yeah
jay's
contact
is
is
worked
on
by
mario
lofreedo
is
also
in
the
in
this
meeting
today
and
me.
So
I
I
say:
let's
start
next
slide.
C
Please,
okay,
so
we
updated
both
rfc
documents:
the
first
one
defining
similar
to
gs,
calendar,
the
the
data
format,
the
other
rfc,
defining
the
mapping
between
the
vcard
data
format
and
js
contact.
C
We,
we
took
great
care
to
cover
the
the
very
majority
of
vcard
properties
that
we
and-
and
you
can
see
here,
the
rfcs
that
we
took
into
took
into
account
during
mapping.
If
you,
if
you
know
of
some
other
rfcs
that
are
that
you
think
are,
are
relevant
and
please
let
us
know
next
slide.
Please.
C
C
So
there
was
the
ongoing
task
of
identifying
properties
in
js
contact,
which
should
be
lists
versus
sets,
as
we
use
in
other
in
some
other
cmap
object
or
chamber
element
objects,
and
we
we
looked
at
the
properties
that
we
have,
which
are
multivated
currently,
and
we
try
to
separate
them
where
we
think
that
the
order
of
entries
is
relevant
versus
whether
or
not
we
only
identify
one
where
we
are
pretty
sure
that
the
order
is
totally
irrelevant,
which
is
categories
we
kept
the
other
others
currently
as
list
values,
under
the
assumption
that
that
the
order
is
relevant
for
display
across
different
clients
of
the
same
data.
C
So
we
that
was
our
basic
assumptions
if
client
implementers
are
telling
us
now
that
this
is
really
not
relevant,
then
I
would
say
that
the
the
the
whole
this
type
discussion
can
be
decided
pretty
quickly
and
we
will
use
sets
where,
wherever
it,
it
makes
more
sense.
So
my
question
would
be
here
at
this
point
to
other
implementers
or
do
people
using
contacts
on
especially
contact.
C
C
C
B
Yeah,
it's,
I
think,
probably
the
order
is
important.
It's
a
really
tricky
one
like
I.
I
certainly
think
existing
clients,
obviously
all
do
share
stuff
in
whatever.
On
the
other
hand,
I
don't
think
they'll,
let
you
reorder
them
particularly
easily,
which
is
yeah
it's
one
of
the
things.
That
is
the
order
just
because
that's
what
we
currently
do
or
is
actually
an
important
attribute,
I'm
not
sure,
certainly
the
being
patched
up
with
sets
is,
is
nice
and
makes
you
less
likely
to
accidentally
write
data.
B
You
want
it,
but
I'd
probably
lean
slightly
towards
leaving
his
list,
but
I
don't
feel
too
strongly
from
our
client
right.
This.
C
I
I
The
reason
I
I
I'm
a
little
dubious
is
that
I
know
at
least
ical
for
jay
and
his
vcard
implementation
just
uses
the
underlying
types.
You
know
that
java
lists
and
things
first
so
it'll
pass
it
all
into
a
list
and
the
order
that
you
get
is
is
not
necessarily
the
order
that
they
they're
parsed
in
depends
on
the
implementation
of
the
list.
Now
I
suspect
that
other
things
are
the
same
unless
you
add
properties
to
to
force
an
order
or
or
mandate
that
the
the
parsed
order
be
maintained.
I
C
Yeah,
that's
basically
the
question
currently,
if,
if
clients
are
displaying
vcard,
do
they
typically
tend
to
display
them
in
order
of
the
I
don't
know,
email,
property
or
whatever,
and
so
is
it
more
important
that
we
can
preserve
this
order
or
because
it's
how
it's
currently
done
or
if
you
are
saying,
if
what
you
are,
I.
I
Think
I'm
saying
that
they
are
ignoring
order
anyway,
I
think
that's.
What
I'm
saying
is
that
I
think
the
libraries
are
not
explicitly
attempting
to
retain
order,
so
it
it's
likely
that
it
will
it
it'll
change.
I
mean
I
guess
some
people
are
assuming
and
maybe
by
chance,
it's
sort
of
staying
that
way,
but
I
don't
think
it's
explicitly
specified
anywhere.
C
Okay,
so
that
would
that
would
speak,
I
mean
we
don't
need
to
make
the
decision
now,
but
I
hear
that
it
might
make
more
sense
to
use
sets
with
some
artificial
identifier
like
we
are
doing
in
js
calendar,
for
example,
right.
E
Yeah
also
to
mike's
point,
I
I
don't
think
clients
preserve
an
entire
sort
order.
What
I
have
seen
is
there's
there's
the
pref
parameter
that
you
can
put
on
certain
properties,
and
I
think
you
know
in
the
case
of
emails
or
phone
numbers,
your
clients
will
let
you
specify,
which
is
your
preferred,
even
though
you
could,
you
could
actually
specify
an
order
by
by
varying
the
the
pref
values.
I
think
a
lot
of
clients
just
specify,
whichever
their
top
choice
is
and
that
one
always
gets
sorted
to
the
top.
E
C
Mario,
I
don't
recall
at
this
point,
I
think
we
we
keep
the
pref
parameter
in
v
card,
but
at
the
top
of
my
head
I
don't
know
how
we
are
exactly
mapping
it.
Do
you
know.
K
C
C
I
Well,
it's
a
sort
of
a
I
mean
I
I
even
if
it
wasn't
treated
as
fully
as
a
sort
order.
I
I
see
why
you
want
the
numeric,
because
you
know
try
this
phone
number
first
and
if
that
fails,
try
this
one
and
then
try
that
one.
I
C
Then
I
would
say
we
will
check
for
the
lists
properties,
which
of
them
have
a
pref
parameter
in
vcard.
At
this
moment
and
for
any
which
have
not,
we
can
then
still
decide
if
we
want
to
switch
to
the
same
model
or
or
not.
B
K
You
can
assign
the
prefer
the
breath
parameter,
almost
all
the
elements
so,
and
maybe
I
have
to
check,
but
probably
all
the
elements
here
this
shown
as
list
can
can
be
assigned
a
prep
parameter.
A
A
A
If
you
live
in
the
middle
there,
I
have
seen
in
the
wild
cards
that
have
grouping
constructs
ahead
of
the
the
keys
so
that
that
allows
you
to
group
related
fields
together.
Do
we
have
support
for
that
in
here,
because
that
that's
also
going
to
be
something
that
that
gives
us
sorting
of
some
sort
I'll
see?
If
I
can
find
some
examples,
yeah.
C
Yeah
for
so
for
for
names
and
and
that
we
are
kind
of
switching
to
a
to
a
different
model,
but
we
can
of
course
see
if
and
how
to
preserve
preference
there.
But
I
agree
that
for
the
general
case
we
should
have
a
generic.
We
should
have
the
same
approach
now
and
not
many
for
different
object.
Types.
F
All
right
all
right,
I
just
wanted
to
make
one
short
point
here.
So,
first
of
all,
from
from
my
practical
experience
so
far,
I
don't
know
many
tools
or
web
uis
of
contacts
that
really
preserve
some
sort
of
order.
What
they
mainly
do
is
they
show
the
field
fields
first,
for
instance,
or
they
may
prefer
the
homework
over
other
fields
like
in
addresses,
or
something
like
that.
I
so
that
so
I
also
don't
think
many
clients
would
actually
use
that
possibility
of
rearranging
that
stuff.
F
F
There
is
this
numerical
thing
somebody
proposed,
and
there
might
be
something
like
more
like
a
star
or
pref
approach,
where
I
can
maybe
individually
select
one
or
two
really
favorites,
or
something
like
that.
F
I
think
one
disadvantage
of
this
list
like
it
is
proposed
here
in
a
way,
I
think
so
somehow
is
that
users
might
be
confused
not
to
know
if
it's
really
sorted,
because
you
know
if,
if
they
just
see
the
list,
they
might
not
remember
if
they
did
that
deliberately,
maybe
that,
as
a
point
a
little
bit
cautioning
against
the
way
it's
written
here.
F
I'm
also
not
sure
if
the
numerical
approach
of
really
having
an
you
know,
a
dedicated
number
for
each
sorted
thing
is
a
way
to
go
because,
as
I
said,
I
doubt
a
little
bit
that
people
will
make
that
effort
for
five
email
addresses
to
really
assign
a
dedicated
priority
for
each
of
them.
So
I
think,
in
terms
of
usability
at
least
my
heart
would
be
probably
for
a
very
simple
favorite
or
star
approach
in
a
way
where
I
can
select
your
favorite
one
but
yeah.
C
I
That's
why
you
don't
want
to
over
engineer
it?
It's
not
it's
not.
I
mean
I
don't
know
what
the
the
point
I
think
of
the
preference
is
not
to
for
for
a
viewer
to
nominate
their
favorite.
It's
for
the
it's
for
the
person.
Who's
been
referred
to,
to
specify
ways
in
which
they
may
be
contacted
and
to
prioritize
them
is
is
more
about
what
we're
talking
about.
So
when
you
have
multiple
emails,
you
might
well
want
to
order
them
as
the
one
you
should
use
this
one
for
for
contact.
I
F
But
is
that
really
the
case
mike,
like
I
mean
for
organizations
like,
would
there
be?
Would
I
use
that
to
define
which
organization?
What
would
it
mean
in
that
sense,
and
I
mean
even
for
email
addresses
you?
Typically,
you
have
like
work
home
or
something
and
the
person
that
wants
to
contact
you
decides
on
on
her
own.
If,
if
there
is
a
work,
contacts
or
a
whole,
it's
a
home
purpose
and
you
rather
seldomly
will
use
multiple
work.
Addresses
email
addresses
in
your.
I
They're
they're
all
good
points.
The
problem
I
have
with
this
kind
of
discussion
is
there
have
been
years
and
years
of
discussion
on
on
creating
a
vcard,
and
this
stuff
has
been
hashed
out
by
by
people
in
hours
and
hours
and
hours
of
discussion.
We
can.
We
can
simply
put
that
aside
and
say
we
don't
think,
there's
a
use
for
it,
but
on
the
other
hand,
at
the
time
they
thought
there
was,
and
perhaps
there
still
is-
I
don't.
F
I
A
H
E
Quickly
to
follow
on
mike's
point,
I
agree
with
what
he
said,
but
if
we
are
going
to
remove
things,
we
may
want
to
consider
try
to
come
up
with
the
reasons
why
vcard
4
wasn't
as
widely
adopted
as
as
three
was
it
because
the
stuff
that
was
added
before
wasn't
useful
or
was
it
laziness
or
was
there
some
other
reason,
and
that
might
help
inform
us
as
to
what
may
be
able
to
be
trimmed
out
of
the
current
d-card
specs.
I
Card
4
trimmed
anything
it
actually
added,
quite
a
bit
of
stuff
and
and
and
it
the
reason
for
vcard
4
is
actually
well
documented
because
years
ago,
in
in
car
connect,
we
had
a
workshop
and
there
are
a
whole
bunch
of
bullet
points
on
why
we
needed
to
a
new
version
of
vcard
and,
unfortunately,
all
those
bullet
points
still
apply.
I
You
know
the
inadequate
sort
ordering
names
coming
out
in
the
wrong
order,
not
being
able
to
determine
things
were
the
right
way
around.
Uid
is
missing,
so
you
got
duplications
and
all
the
rest
of
it.
So
vcard
four's
a
better
model
to
follow,
because
it
tried
to
address
a
lot
of
known
deficiencies
as
to
why
nobody
did
it.
It's
I
they.
The
best
reason
that
I've
heard
is
stated
is
that
vcard
4
didn't
provide
enough
enough
value
to
justify
the
the
time
and
effort
of
moving
forward.
I
D
C
Yes,
so
for
the
specific
topic
in
question
for
for
list
types
versus
sets,
I
I
very
much
hear
that
we
will
switch
to
a
couple
a
couple
of
these
properties
to
sets
and
using
a
numeric
preference
or.
However,
we
might
call
it
firstly
because
it
allows
us
to
to
be
compatible
with
the
vcord
pref
parameter
and
also
because
it's
the
most
versatile
and
doesn't
really
make
things
that
much
more
difficult
than
a
simple
favorite
approach.
C
Good
I'd
say:
let's
switch
to
the
next
slide,
because
I
think
we
will
explain
some
questions.
D
A
C
Please,
okay,
so
names
and
addresses,
but
especially
addresses
so
for
for
names.
We
already
previously
decided
that
we
are
that,
instead
of
having
a
a
complex
object
that
has
fields
like
first
name
surname,
whatever
we'll
switch
to
a,
we
switch
to
a
more
generic
approach,
which
is
where
a
name
is
basically
defined
by
a
list
of
tag,
tag
values.
So
a
tag
would
be
personal
name
and
its
value
would
be
robert.
C
We
did
that
mainly
because
we
saw
that
there
are
that
names
are
very
much
different
between
cultures
and
this
approach
allows
to
to
express-
hopefully,
the
the
majority
of
them
in
a
more
meaningful
way
than
it's
currently
done,
and
it
also
allows
to
still
generate
a
complete
name
by
generating
a
string
out
of
the
value
of
the
of
these
tag,
name:
components
in
order.
C
In
addition
to
that,
we
still
have
a
full
name
property,
which
is
a
localized
string.
That's
both
because
we
we
we
have
v
cards
which
do
not
have
an
n
property,
so
a
structured
name
at
all
and
only
an
fn
property.
So
we
so
we
want
to
preserve
that.
But
the
other
thing
and
that's
why
it's
a
low
clustering
is
that
we
want
to
have
a
full
name
which
allows
to
express
the
name
in
in
in
the
locality
of
the
of
the
contact
or
probably
even
several,
several
ways.
C
So
that's
for
name-
and
I
think
we
already
had
the
decision
here,
but
of
course,
if
there
are
thoughts
or
objections
to
that
now,
please
let
me
know,
but
the
the
other,
the
other,
the
other
object
are
addresses
and
there
we
had
them
push
back
the
decision,
how
to
express
them
using
a
complex
type
or
was
a
detect
value
approach
for
a
long
time.
C
I
still
would
say
we
still
haven't
a
hundred
percent
decided
yet,
but
at
the
moment
we
think
that
a
complex
type
for
an
address
that
more
speaks
for
a
complex
type
of
an
address.
So
why
is
that?
We
think
that
addresses
are
that
for
addresses.
C
We
want
to
enforce
more
structure,
because
we
assume
that
that
it's
it's,
that
the
clients
and
applications
will
ex
more
we'll
expect
more
structure
there
than
foreign
name
and
so
in
either
case
either
you
if
you
use
the
tags
or
if
we
use
properties
like
we
do
now.
C
We
want
to
make
sure
that
we
capture
all
different
components
that
can
make
up
an
address,
and
for
that
we
of
course
looked
at
e-card,
but
but
we
also
looked
at
at
apis
of
major
major
commercial
internet
players,
be
that
google,
microsoft
or
baidu-
and
we
came
to
to
the
conclusion
that
the
current
model
seems
to
capture
it
captures
at
least
all
the
properties
that
they
are
returning
for
addresses.
C
Now
I
I
I
I
came
to
this
also
with
the
thought
that
many
addresses
addresses
on
this
world
cannot
be
expressed
with
that
scheme,
but
and-
and
I
also
hear
people
saying
that
and
I'm
not
necessarily
doubting
it,
but
I've
never
seen
an
example
for
that.
C
So
I
think
what
we
are
lacking
here
is
is
expertise
so,
first
of
all,
it
would
be
great,
for
example,
mike
if,
if
we
could
contact
our
contact
at
cal
connect
at
dhl,
who
might
bring
more
expertise
into
that,
but
also,
of
course,
probably
people
here
in
this
session
have
have
more
experiences
with
addresses
that
cannot
be
expressed
in
the
current
model
yeah.
I.
I
Mean
that
the
person
that
to
raise
I
mean
that's
essentially
they've
been
the
motivation
for
the
iso
work
on
on
this.
Is
that
it?
The
v
card
representation,
just
doesn't
work
for
many
areas.
C
That's
correct:
I
wanted
to
mention
that,
so
we
know
there
is
work
in
iso
on
that
and
I
look
forward
to
their
presentation
at
cali
connect
next
month.
I
looked
at
their
approach
and
it
the
way
I
understand
it.
They
are,
they
are
defining
profiles
and
address
profiles
and
each
profile
can
have
different
fields,
but
I
wonder
if
that
would
be
over
complicate
js
contact.
C
So
if
you
would
require
implementers
to
to
implement
these
profiles
most
likely,
as
I
understand
being
defined
in
some
profile
registry,
I
wonder
I
wonder
if
that's
not
too
complex
and
it
rather
scares
away
people
from
using
that
format.
If
I
also
don't
know
if
that
iso
standard
will
be
open,
so
I
don't.
I
don't
have
enough
information
if
we
should
just
take
what
they
are
doing,
because
it's.
I
Because
I
don't
have
enough
well
that
was
part
of
the
the
motivation
behind
getting
a
liaison
relationship
with
with
iso
that
that
we
can
as
calcutta.
We
can
publish
these
these
as
calconet
standards,
which
would
be
free
and
open
to
use.
But
the
the
the
issue,
I
think,
is
that
essentially
this,
this
lack
of
usability
of
the
addresses
makes
v
cards
unusable
in
certain
certain
areas
and
a
large
in
large
areas.
C
I
mean
I
also.
I
also
heard
this
I
mean
wikipedia
wikipedia,
not
necessarily
always
is
a
great
source,
but
as
far
as
I
understand
from
there
and
also
the
universal
postal
blob
that
they
include
there,
it
seems
to
me-
and
I'm
I'm
a
diligent
in
that
area-
that
that
it
that's
not
necessarily
the
case
that
that
many
addresses
can't
be
expressed
internationally.
C
To
see
to
have
concrete,
either
examples,
or
at
least
more
concrete
hints,
on
what
isn't
covered
currently,
okay,.
I
Let
me
try
and
contact
you
I'll,
try
and
contact
the
dhl
person,
because
they,
as
they
were
motivated
enough
to
to
rejoin
calcnet
because
of
the
liaison
relationship.
But
what
was
driving
them
was
this.
This
problem
with
addresses
so
I'll,
see
if
I
can
contact
them
and
find
out
what
it
was
specifically
that
they
they
had
as
a
problem,
but
it's
significant
enough
that
they
they
they
rejoin.
C
Yeah
cool,
so
then
I
would
then
I
look
forward
to
this
to
this,
and
also
probably
we
can
talk
with
them
at
next
connector.
A
C
C
So
I
would
say
for
addresses,
I
don't
think
we're
yet
at
the
point
where
to
make
a
hard
decision
on
on
how
to
do,
how
to
define
them
in
shame
up
in
cheers
contacts,
but
I
think
we
won't
ever
be
able
to
do
that
if
we
don't
really,
if
don't
really
get
the
experts
at
the
table.
C
So
at
the
moment
I
I
hear
that
it
seems
to
me
that
the
people
who
are
currently
interested
in
this
draft
or
are
not
necessarily
the
ones
who
also
have
the
expertise
of
really
of
of
really
defining
the
the
international
gaps
that
we
see
with
the
current
address
scheme
so
yeah.
I
guess
the
next
step
is
to
identify
who
can
who
can
tell
us
more
other
thoughts
on
this.
A
A
I
That,
I
think,
just
just
briefly
my
recollection
of
of
how
the
v
card
four
was
was
supposed
to
be
with.
So
one
of
the
one
of
the
one
of
the
properties
was
a
name
order.
I
I
think
where
you
could
specify
what
components,
how
to
order
the
components-
the
name.
Oh,
I
think
it
was
called.
It
was
a
sort
order,
property
or
something
like
kind
and
and
I
and
what
that
one.
One
of
the
problems
with
with
with
vcard
3
and
previous
was
that
applications
would
choose
to
sort
the
data
in
all
sorts
of
different
ways:
they'd
try
and
break
the
name
up
and
then
sort
either
on
the
last
name
or
the
first
name
or
whatever,
and
people
couldn't
find
stuff.
I
I
A
I
Yeah,
so
the
the
sort,
the
sort
order
thing,
simply
lists
the
names
of
the
components
that
you
sort
by
and
in
the
order
by
which
you
sort
them.
So
that,
and
and
the
point
there
of
course
is-
which
is
the
specific,
the
name
that
matters
when
you
sort
and
it
def
depends
on
culture.
It's
not
a
thing
you
can
derive
from
you
know:
do
you
sort
by
the
family
names
you
saw
by
the
personal
name?
I
So
that's
that
was
in
v
card
four,
as
a
as
an
attempt
to
resolve
known
issues
with
with
with
these
things
and
and
that
sort
of
was
also
trying
to
resolve
some
of
the
issues
over
merging
of
of
cards
is,
is
how
do
you
identify
two
as
being
well
a
uid
works.
If
you
give
you
two
identical
cards,
but
what
if
you've
got
two
cards
that
refer
to
the
same
person,
but
the
names
are
ordered
differently
for
some
reason,.
C
Yeah,
I'm
just
looking
looking
this
up
in
the
in
the
v-cut
draft
and
yeah.
So
it's
it's
sorting,
multiple
names,
as
you
mean
and
yeah
we're
checking
how
we
are
okay.
So
actually
I
see
that
we
only
the
name
in
our
current
model
is
a
single,
valued
property,
so
we
wouldn't
even
allow
for
multiple
names.
A
So
this
this
isn't
multiple
names
within
a
single
card.
This
is
you've,
got
a
hundred
addresses
and
you
want
to
display
them
in
a
sorted
order,
sorted
by
name
and
is
that
sorted
by
surname?
Is
it
sort
of
by
first
name
where
alphabetically?
What's
the
collation
order
that
they
sought
with
yeah?
That's
that's
the
interesting
challenge
here.
I
C
I
C
I
A
C
B
Yeah,
that's
why
we
have
the
tagged
version
here,
because,
yes,
they
may
not
be
in
that
order,
so
this
lets
you
put
them
in
order
like
in
cultures
where
the
family
name
comes
first,
if
you
like,
but
you
can
still
tag
them.
This
is
a
family
name,
not
their
personal
name
and
so
sort
by
the
correct
thing.
I
think,
basically,
I
think
I'm
saying
is
this:
this
system
is
designed
to
solve
this
problem.
Are
there
any
changes
you're
proposing
here
or
are
you
do
you
actually
agree
with
that?
I'm.
C
Yes,
this
is
also
my
understanding
and
mike.
I
understand
that
this
sort,
s
parameter
and
v
card
allows
you
to
define
the
order
of
the
parameters
to
take
into
account,
and
if
we
want
to
preserve
that,
then
we
would
need
to
have
some
multi-valued
sword
order.
A
B
A
I
think
I
think
we
definitely
need
some
examples
of
how
interfaces
sought
and
and
how
this
stuff
was
designed
to
be
used,
because
I
I
think
that
mike's
right
that
there's
more
to
this
than
just
you
sort
by
personal
or
you
sort
by
surname
there.
There.
C
Okay
groups,
so
in
the
previous
draft
we
had
a
very
simple
object,
called
contact
group,
I
think,
or
card
group
or
whatever,
which
basically
had
a
name
and
at
least
and
a
list
type
property
which
defined
the
the
uids
that
are
members
of
this
group.
Then
we
came
to
realize
that
the
in
vcard
this
is
actually
done
by
having
a
kind
equals
group
property
in
the
v
chord
and
that
basically
meant
that
the
v
card
with
kind
equals
group
can
have
any
other
record
property
too.
C
So
we
came
to
realize
if
we
want
to.
If
we
want
to
map
clearly
from
vcard
to
js
contact,
then
we'd
be
throwing
away
lots
of
information
for
mapping
these
to
a
group.
So
we
changed
it
in
the
current
draft
to
defining
js
card
group
to
be
kind
of.
Allow
me
the
term
subclass
of
the
of
a
js
card.
So
basically
it
has
an
a
new
property
members
and
it
requires
the
kind
property
of
the
of
the
inherited
property
so
to
say
as
group.
C
So
this
this
does
away
with
all
the
issue
of
throwing
away
too
much
information
for
group
records.
But
of
course
it
comes
with
the
cost.
So,
first
of
all
we
now
have.
We
now
have
nested
groups,
and
since
we
are,
since
these
groups
are,
are
nested
together
by
uads,
we
need
to
check
for
circular
groups,
for
example,
and
and
we
also
need
to
enforce
that
the
js
card
groups
and
the
chase
cards,
so
basically
the
leaf
objects
and
the
and
the
group
objects
share
the
same
uid
name
space.
C
So
at
this
point
we
might
wonder
if
we
even
need
a
gs
card
group,
if
it's
just
a
js
card
that
can
be
grouped
or
not
there
again.
I
wonder
first
for
applications
if
it
makes
sense
to
have
a
to
have
a
distinct
type
of
groups
and
if
it
makes
sense
for
these
groups
to
basically
have
all
the
properties
of
the
regular
contact
and.
C
Yeah,
that's
what
I'm
uncertain
about.
I
also
don't
know
any,
but
it
doesn't
has
to
mean
that
probably
some
some
services
are
using
them
and
I
just
haven't
seen
it
so.
B
D
A
To
have
a
call
and
see
if
anyone
is
using
those
facilities
and
if
not
define
a
group
that
doesn't
include
those
and
if
you
need
something
fancier,
then
and
maybe
there's
properties
that
make
sense
to
have
in
a
group.
But
I
don't
think
a
full
card
on
a
group
makes
sense.
I
A
But
we
can
define
something
and
say
use
this,
and
if
everyone
uses
it
then
happy
days
and
there's
a
clear
mapping
between
cards
that
don't
have
these
additional
properties
and
this
and
cards
that
do
have
these
additional
properties.
If,
if
they
get,
if
they
hit
one
of
these
translation
systems,
then
then
they
will
pop
up
and
say
hey.
A
We
need
this,
but
allowing
all
the
things
that
were
accidental
side
effects
of
it
not
being
locked
down
enough
before,
just
because
someone
might
possibly
be
using
them
somewhere
in
the
wild
who's
has
never
spoken
up
or
never
shown
up
in
any
data
that
anyone's
seen.
B
C
Yeah,
okay,
so
it
basically
boils
down
to
the
same
thing
as
for
addresses,
so
we
don't
really
know
if
we
are
making
it
hard
for
some
people
who
would
be
interested
in
respect
to
to
use
it.
But
again,
I
also
don't
have
a
good
idea
how
how
can
can
come
to
a
consensus
rather
other
than
asking
on
the
list
we
can
address
this
next
can
connect.
Probably
there
are
more
people.
There
is
the
record
group
there.
So
probably
they
they
have.
They
know
more
about
this.
A
C
A
C
Actually,
one
one
thing,
though,
is
if
we
revert
it
back
to
before.
Let
me
just
check
if
we
already
allowed
for
multi-leveled.
C
Group
cards
yeah
because
in
in
the
previous
definition
a
js
card
group
could
only
could
only
have
cards
as
members,
but
we
might
want
to
allow
this
to
have
cards
or
card
groups
so
that
you
can
basically
expand
a
tree
of
groups
and
contacts.
I
could
imagine
this
being
useful,
for
example,
for
mailing.
I
don't
know
if
mailing
list
is
the
right
name,
but
I
saw
and
for
example,
some
in
microsoft
productivity
tools.
I
think
they
have
these
multi-leveled
mailing
lists
change.
C
Okay,
so
there
is
consensus
that
we
want
to
have
this,
that
we
want.
A
I
don't
know
that
we've
we've
discussed
that
yet
did
anyone
else
want
to
speak
on
this
area.
Yeah.
H
C
Actually
used
it,
but
I
I
think,
for
example,
in
microsoft,
environments
or
on
exchange
service.
You
have
these
organizations
tend
to
organize
their
departments
and
groups,
but
those
are
the
sub
departments.
A
C
Okay,
so
if
there
are
no
other
points
or
groups
at
this
moment,
we
can
switch
to
the
next
slide
yeah.
So
I
was
wondering
if
other
people
at
this
stage
are
already
interested
in
implementing
more
implementations
the
earlier
the
better.
So
if
you
do,
please
please
contact
mario
and
me
or
just
say
now
and
of
course,
we'd
appreciate
any
more
feedback
on
the
draft.
I'd
say
better
wait
until
we've
updated
draft
with
today's
decisions
need
to
thank
you
for
your
thorough
feedback
before
this
session.
C
Two
of
the
points
that
we
haven't
discussed
of
your
feedback
in
this
at
this
meeting.
Yet
now
is
the
roles
property
where
you
were
basically
saying
that
you
don't
understand
the
purpose
of
it
and
looking
at
it
did.
C
I
now
agree
it's
basically
a
mapping
from
the
v
code,
road
property,
and
I
understand
that
there
it
what
its
purpose
is
to
define
roles
from
a
specific
set
of
organizational
roles
defined
in
the
x
x,
520
iso
standard-
I
I
really
don't
know
if
that's
it
for
this
property,
I
really
don't
know
if
it's
stick
red
event
or
and
if
we,
if
we
should
restrict
it
to
the
same
values.
Probably
chopped
title
is
enough
mike
you're,
in
the
queue.
I
C
Oh
yeah,
okay
and
yeah
so
for
roles.
I
can
imagine
that
we
are
that
we
are
removing
that
property.
We
will
ask
for
that
and-
and
the
other
thing
is
the
resource
type,
but
we,
I
don't
think
we
need
to
discuss
that
now
I'll
send
something
on
the
list.
C
A
B
I
mean
I
do
I:
don't
it's
not
worth
spending
much
time
on
right.
Now,
though,
I
don't
think
it
is
obviously
pretty
rough
at
the
moment
like
there's
no
description
of
what
a
lot
of
the
stuff
means,
like
you
can
probably
guess
pretty
accurately
from
the
names,
but
you
know
like
what
data
as
basics
for
data
aztecs,
actually
do
you
know,
would
need
to
be
specified.
Welcome
just
yes
that.
B
Yeah
it's
this
is
it's
been
vague
places,
it's
probably
the
main
thing
but
yeah.
I
don't
know.
B
E
All
right
a
couple
opening
remarks,
robert
and
I
did
not
coordinate
our
shirts
in
case
anybody's
interested.
E
Secondly,
everything
in
this
current
draft
is
implemented
in
the
cyrus
gmap
server
and
everything
other
than
the
test
method
is
currently
running
in
production
at
fast
mail
and
we've
effectively
shut
down
our
managed
civ
stack
internally.
So
it's
a
viable
alternative
to
manage
civ
in
that
respect.
First
slide.
E
Please
so
changes
since
we
last
met
I've
reverted
back
to
using
only
blob
ids
for
specifying
the
strip
content
in
set,
validate
and
test.
This
is
goes
back
to
looking
more
like
the
the
core
j-map
methods.
E
E
Basically,
as
I
outlined
it,
I
think
this
is
fairly
non-controversial,
but
if
anybody
has
any
other
opinions,
please
let
me
know
basically
stated
that
you
can
fetch
the
vacation
response
with
a
get.
You
can
activate
it
or
deactivate
it
with
set
using
the
unsuccess
activate
script
argument,
and
you
cannot
update
or
destroy
this
with
set.
The
reason
for
the
last
item
is
vacation.
Response
is
specified
to
be
a
singleton
type
object,
so
it's
either.
E
E
Okay,
one
other
change
that
we
didn't
discuss
last
time,
but
I
found
was
was
kind
of
lacking
the
the
past
draft
did
some
hand
waving
in
terms
of
how
the
names
for
positional
arguments
would
be
generated.
E
It
basically
said
you
pull
them
from
the
the
syntax
or
usage
portion
of
the
relevant
spec,
and
I
did
some
research
and
each
one
of
the
civ
extension
drafts
tends
to
outline
their
arguments
slightly
different,
so
it
seemed
like
it
was
better
off
to
have
a
more
concrete
way
of
of
specifying
these.
So
what
I
did
was
I
removed
the
positional
arguments
from
the
hash
of
arguments
and
put
them
into
their
own
separate
array,
obviously,
in
order
of
the
required
position
for
the
further
spec
so
on
the
next
slide.
E
There's
an
example
of
what
this
looks
like
as
currently
implemented
in
cyrus
I'll
defer
to
the
json
experts
as
to
whether
or
not
this
is
json
enough
on
the
second,
the
next
slide.
After
this,
I
have
a
another
possible
structure
for
how
this
response
would
look.
E
I
don't
care
either
way
it's
pretty
much
syntactic
sugar.
As
far
as
I'm
concerned,
any
strong
opinions.
One
way
or
the
other.
B
It's
it's
three.
Yes,
it's
always
going
to
be
three
and
they're
always
going
to
be
at
the
same
time,
within
that,
it's
just
that.
There's
no
separate
people
typing.
A
B
E
So
one
thing
we
did
discuss
last
time-
and
I
forgot
to
put
in
this
draft-
was
we
had
discussed
whether
we
want
a
is
included
or
some
other
such
name
property
on
the
subscript
object
itself
that
can
be
filtered
upon,
so
the
user
could
determine
that.
You
know
they
have
a
script,
that's
being
included
someplace
else,
and
you
don't
want
to
delete
it
or
you
know
whatever
other
the
use
cases
could
possibly
be.
I
don't
know
lexi.
E
E
E
E
E
E
I've,
given
some
thought
about
how
best
to
handle
some
of
the
various
extensions,
for
instance
vacation
the
test
request
right
now.
You
can
specify
whether
or
not
the
sender
has
been
replied
to
previously.
E
We
don't
do
anything
similar
for,
let's
say
a
duplicate
test,
so
my
thinking
was
given
that
we've
got
the
array.
Should
the
state
be
maintained
between
the
emails
as
they
get
run.
So,
for
instance,
you
you
have
any
incoming
email
that
you're
going
to
test
against
from
user
foo
the
first
time
they'll
get
a
vacation
response.
If
you
send
another
test
email
from
the
same
user,
they
won't
get
it
the
second
time
or
similarly,
with
the
duplicate
test.
E
A
G
So
was
there
ray
a
reason
to
be
able
to
carry
over
state,
or
was
it
just
a
kind
of
useful
side
effect.
G
E
A
Actually,
the
one
argument
in
favor
of
having
the
email
ids
for
that
is
that
you
can
use
back
references
from
a
query
rather
than
having
to
construct
the
individual
commands.
So
you
could
do
a
query
and
then
back
reference,
the
resulting
ids
and
pass
that
straight
into
sieve
test.
That
would
be
quite
nice.
G
Alternatively,
you
are
just
basically
sort
of
now
so
you're,
not
even
completely.
E
G
If
you're
doing
it
for
one,
you
might
as
well
do
it
for
all.
If
it's
not
too
much
pain,.
E
Okay,
if
there's
nothing
further,
I
am
done
great
thanks
for
the
feedback.
A
And
I
believe
we're
now
up
to
milestone
review
here's
our
milestones.
A
Adopt
document
for
creating
blobs,
I
don't
even
remember
whether
we
did
a
call
for
adoption
on
that.
I
think
we
did
so.
That
should
hopefully
happen
now
ish
april
2021
civ,
we
should
be
that's
already
been
submitted
yeah,
so
I
should
actually
mark
that
as
done
or
has
it.
E
A
A
Cool
address
books,
we
haven't
done
a
document
for
jam
up
address
books,
yet
neil
or
robert.
A
Contacts
is
the
format
address
books.
Is
the
the
gmap
server
to
client
way
of
shipping
those
contacts
around
it.
A
Yeah,
I
think
so
so,
should
we
bump
that
out
to
maybe
like
september
october,
what
do
you
mean.
D
A
Like
I'm,
going
to
say
august
must
be,
let's
be
optimistic,
all
right
jam
at
blobs.
Obviously,
that's
that's
gonna
have
to
wait
because
it's
january
there
so
I'll
say
april
and
then
july.
A
B
A
D
B
A
All
right
I'll
follow
up
with
the
authors
on
that
s:
mime
alexi.
G
Right
so
let's
do
x,
mime
signature.
I
think
it
expired,
but
that
I
think
it
can
be
sent
to
asg
by
june
I'll
just
revive
it,
and
then
you
can
do
last
call
the
other
one.
I
can
pull
something
by
august.
A
A
Cool,
that's
the
adopt,
yep
and
then
submit
js
contact.
What
do
we
think
we're
for
that.
A
Cool
so
make
that
august
as
well,
which
just
makes
sense
that
we
submit
it,
and
then
we
adopt
address
books
at
the
same
time,
informational
guidance
document,
that's
still
in
the
future,
so
we'll
see
how
we
get
to
for
that.
A
D
A
A
A
All
right,
some
of
the
material
that
came
up
today,
will
be
discussed
during
the
cal
connect
meeting,
which
is
in
the
second
week
of
april.
So
it's
a
month
from
now,
so
I
there's
a
plan
to
do
an
intro
meeting
for
calex,
probably
already
during
that.
I
don't
know
if
we
want
to
also
do
an
interview
meeting
for
jmap
or
do
a
combined
interim
meeting.