Skip to main content

Minutes IETF110: jmap

Meeting Minutes JSON Mail Access Protocol (jmap) WG
Date and time 2021-03-11 16:00
Title Minutes IETF110: jmap
State Active
Other versions plain text
Last updated 2021-04-14

# JMAP @ IETF 110
11 March 2021

## Agenda

Intro and Note Well: 5 min

Calendars and related topics: 40 min

* draft-ietf-jmap-calendars - 20 min
* draft-baum-jmap-tasks - 10 min
* draft-jenkins-jmap-sharing - 10 min

Contacts and related topics

* draft-ietf-jmap-jscontact (+vcard) - 30 min

Sieve and related topics

* draft-gondwana-jmap-blob - 10 min
* draft-ietf-jmap-sieve - 10 min

Any other business: 20 min

Milestone review: 5 min


* Bron presented the Note Well and agenda. No agenda changes proposed.

### jmap for calendars -- Neil Jenkins

New features: shareesActAs, ParticipantIdentity, events on multiple calendars,
sharing now separate spec

Next: Should tasks be integrated into calendars spec?

* Fastmail hoping to have real world implementation experience by next IETF. 
Development is mostly done, but not yet deployed to real users.

* Biggest discussion for Tasks: should we merge with Calendar spec like CalDAV
does, or keep separate?

* Robert S: question for calendar events in multiple calendars -> what are the
semantics for deleting or changing an event in multiple calendars?
    * Changes: updates all calendars
    * Delete: deletes from all calendars
    * You can't have multiple copies of the event within a single account with
    different content.

### tasks -- Hans-Jörg Happel

* there's been some discussion already on the mailing list.  Discussion about

* Audriga observation: from an interoperability perspective, they are quite
different.  Data model for calendars are similar between different systems.

Tasks are much more different between different systems, e.g. Google Tasks are
quite simple.  Other systems have more complex models.

Also a question of philosophy - see JMAP as a way to have data portability. 
Way for a mechanism for tools with slip task approach able to support the task,
but also tools with more advanced features.  Fine-grained capabilities may
help. * Flip side: can make it more complex to implement.  Find the sweet spot.

Neil: want to find the balance.
* Agree that it's more of an issue with tasks.
* Think we could come up with a set of capabilities.  Doesn't affect whether
it's a separate spec to calendars.  Even in the same spec it would have a
separate capability.

Bron: is there any benefit to combining them in the same document?
* Neil, not really - mainly to reduce copy-paste.  still think it might be best
to keep separate. * Hans-Jörg: also if you're just building tasks, may be less
overwhelming to not read both docs. * HJ: another reason, at different levels
of maturity, may slow down jmap for calendars if we wait for tasks. *
Recurrances in tasks are not well supported, though some systems do. * Neil:
Haven't done a survey - how different are task lists from calendars?  There's a
manual order in most task systems, drag and drop. * HJ: not aware of any
groupware systems using tasks that do ordering. * Ken: depends on the type of
task list. * Mike: isn't sort mostly a UI and search feature?
    * Neil: yes, but we need to store it and share it between different clients.
* Mike: what about if you want different sorts on different clients, or shared
views that different people sort differently? * Neil: this is about allowing
the user to manually order things. * HJ: should there be a distinction by
client so different clients can sort differently.  That might be
over-engineering.  If teams share a task list, the sorting is a designed order
that the team shares.  Would be confused if I shared a list and everyone
mainted a separate order. * Neil: for the tasks, the sort order is part of the
data for the task, because it allows users to manually manage them.  For task
lists, users might want to sort them separately.

Discussion about manual sort and how to persist that.

Dave Crocker: discussion we're having is one I've heard before many times. 
Dictating underlying implementation choices that might be more expensive than
others. If modeling is "every query is a search" then it adds to the cost. If a
task can only be in one todo list then it adds cost.

* Neil: depends how many task are in a list?  If you expect it not to be many,
you could always fetch the entire list which had an array of tasks.

* Jim: compare something like Trello than CodiMD - do we want to provide the
underlying capability for a fully featured shared tasks system. * Neil: I think
we probably should. * Should we survey existing systems?

* HJ: we already started this process.  Would be good to see if something like
Trello fits into something like this.  Didn't dig into every detail yet. 
Overall goal is to try to make it compatible so it can be used as an exchange
format for Trello/Kanban style systems. * Mike: had a discussion with somebody
who got very excited about some of the features in ICALENDAR tasks -
transporting project manager data between other systems.  Missing import and
export tools on the applications - they work on their own formats and don't
allow it to be transported.  It's pretty much a perfect match.  Would be a pity
to lose that capability.

* Dave: folder vs search: everything is a search, you can set a default and
that's what you get if you don't say a new search.  A different approach is
"default is just give it to me".  You can set default to be a search, and
underlying implementation can reject it.

* Neil: JMAP works with everything being a /query, but you can allow the server
to say "unsupportedSearch" for anything.

* Dave: more concerned with imposing the gmail-style "everything is a search".

* HJ: would support claim on simple folder model - in tasks system you
typically don't have as many items as in an email system.  Might be more than
10, but not usually 5000.

* Mike: there's lots of things you could imagine doing - there's things like
projects that have 8000 tasks open.  We should assume large.  People do want to
see filtered views.

* Ken: let's get some running code with some core features before we get into
the weeds!

* Neil: this mostly comes down to what should be required to be supported by

* HJ: is there a standard way to survey and find IETF contacts for other orgs?
Nope :(

ACTION: call for adoption
ACTION: survey existing tools and what they provide

### jmap sharing - Neil J

* nothing much to say.
* Mike: parallels what's been done with DAV sharing.  We realised it was
distinct from calendars. * Alexey: had a quick read today, it looks reasonable.
 Will send specific questions to the mailing list.  General comment: more
examples would be useful. * Neil: yes, all these specs need more examples -
will do once we have implmented, then we can get them off the wire.

### jscontact - Robert S

* if you know other RFCs that are relevant please let us know!
* issues from last meeting to discuss.

Only "categories" doesn't require ordering.  For everything else, ordering is
necessary for display across multiple clients.

* Neil: yeah, think the order is important.  But don't think clients let you
re-order them particularly easily.  Is the order just because it's what we
currently do, or is it important? * Don't feel strongly about order. * Mike:
this is order per attribute?  E.g. phones being ordered. * Mike: would be
surprised if this is supported in any meaningful way.  You'll see them in the
order they appear. * Neil: they'll probably appear in the order they appear. *
Mike: ical4j uses underlying list data type.  Unless you add properties to
force order, implementations stand a chance of losing it. * ICAL says that
order is not defined. * Robert: question is "if clients are displaying, do they
typically display in a fixed order"? * Mike: saying that libraries aren't
explicitly attempting to maintain order, so it's likely to change.  Don't think
it's explicitly specified anywhere. * Robert: that suggests using sets for
more. * Ken: don't think clients preserve an entire sort order, but there's the
"pref" parameter you can set. * Mario: we're not keeping the pref parameter, we
map the pref parameter as a boolean "isPreferred".  It's a numeric value in
VCARD, so it's kind of a sort order. * Mike: even if not a sort order, can see
why you'd want numeric - try these in order. * ACTION: check which list
properties have a pref parameter and for those which don't, see if we switch to
same model. * Mario: you can assign the pref parameter to almost all elements.
* Bron: generic construct is good. * Bron: "group construct" on cards that
group related fields. * Ken: agree with general approach to sorting. * HJ:
don't know of many tools that preserve order - might prefer home/work for
address, etc.  Don't think many clients would use the possibility or sort
addresses. * See three solutions:
    * Lists
    * Numerical approach
    * Pref approach (star)
* Disadvantage of list - users might be confused to not know if it's sorted.
* Not sure if numeric approach is the way to go.  In terms of usability, "pref"
approach is best. * Robert: numeric ID is a superset of favourites. * Mike: the
point isn't to allow the viewer to nominate their favourite, it's for the
person being referred to.  They can give the ordering if they have a
preference. * HJ: for email addresses for example, it's "work, home, etc" *
Mike: there's been years of discussion on VCARD how to create it.  We can put
it aside and say "there's no use", but they thought there was. * HJ: agree with
putting compatibility with what's there. * Ken: agree with Mike's point - if we
want to remove things, we should look at why VCARD4 wasn't adopted as much as
3.  If we know why, we might know what we don't need. * Mike: reasons for
VCARD4 are well documented - lots of reasons.  Inadequate sort ordering was
part of it.  VCARD4 is a better model to follow.
    * Why nobody did it?  VCARD4 didn't provide enough value to justify the
    time and effort of moving forward - found workarounds like adding X
    properties. * Let's follow VCARD4.  This is an opportunity to get to a
    better data model.
* ACTION: will switch many properties to sets, to be compatible with VCARD pref
parameter and because it's most versatile.

#### decision - name type vs address type

* Names switched to a list type.
* fullName property (preserve from vcards that don't have anything but FN)
* If there are objections, please speak up!

* Addresses - have pushed back decision about complex type vs list.
* Why?  For addresses we want to enforce more structure.  We assume that
clients and applications will expect more structure there than for a name. *
Want to make sure we capture all components that make up an address.  Looked at
VCARDs and APIs of major players. * Concluded that current model captures the
properties that they are returning for addressses. * People say that some
addresses can't be represented - would be good to get experience from those who
know other systems. * Mike: this is motivation for ISO work on this.  VCARD
representation isn't enough. * Robert: yes, know that there's work at ISO -
look forward to presentation at CalConnect next month. * They are defining
address profiles, and each profile can have different fields.  That might
overcomplicate JSContact.  Require implementations to implement all the
profiles which are defined in a registry. * Mike: CalConnect can publish these.
 Lack of usability of the VCARD address format makes it unusable in large
areas.  VCARD4 was supposed to address some of the issues, but it's still very
western/USA/European oriented. * Robert - also heard it.  From there and
universal postal blob, it seems that there's not many addresses that can't be
addresses internationally in this form.  Would be great to have concrete
examples and concrete hints.  Mike will contact DHL person. * For addresses -
not at the point to find a hard decision.  Need to get experts to the table. *
ACTION: Mike to find DHL contact. * via Jabber: Chinese addresses, adapt to the
stucture, but ISO effort is going to improve this (Barry and Alexey)

#### names

* on name type -> Mike, one of the properties was "name order".  There was a
sort order property. * Do we have a "sort order" for this?  Depends on culture.
* Robert: current model has just a single "name". * Mike: when creating the
card. * Neil: it's sort by FirstName or SurName.  This system is designed to
solve the problem. * ACTION: examples to the list on how sort should be done.

#### decision - groups

* in VCARD (KIND=GROUP) -> can have any other property as well.  If we want to
map cleanly, we may throw away lots of information. * Bron: are there groups in
the wild that have all the properties? * Neil: yes, this feels like massive
overkill and a pain. * Mike: it's unknowable if people use this. * Bron: yes,
but we want to make something easy * Neil: this is an important object for
interop. * Robert: it's like with addresses, we don't really know if we're
making it hard. * can check at next CalConnect. * Bron - at least we're not
representing something in the outside world. * Robert - if we revert - did we
allow a group to contain groups?
    * In previous definition, a group could only contain cards as members. 
    Should we allow it to contain either? * e.g. mailing lists - multi-levelled
* Neil: do we have examples of nested groups in the wild?
    * Robert: Microsoft exchange has things like this - departments, sub
    departments, etc. * Neil: sure

Are others interested in implementing?  Please contact Mario and Robert!
* Thanks Neil for feedback.
* Roles property - mapping from VCARD role property.  There its purpose is to
define roles from a specific set of organisational roles from X520 ISO
standard.  Don't know if we should restrict it. * Mike: played with Contacts
app, you can add groups to groups on mac. * ACTION: will ask about removing

## blob

* Neil, let's not spend time on it right now.  It's pretty rough right now,
there's not much description on what the things do - they need to be specified
rather than guessed at from the names.

## sieve

* Ken - everything in this draft is in Cyrus.  Everything except /test is
running in production at Fastmail. * without Bron's Blob/set you need a
separate round trip. * everyone agreed on slide 2 (vacation response) * slide
3-5: pros and cons, will take to the list * Do we still need "isIncluded"
    * Suggestion: try to implement it and see.
* Test method: can specify an array of EmailIds.  Can run it against multiple
emails.  Test request, can specify "has sender been replied to previously".
    * Should state be maintained between emails, i.e. vacation response only to
    first email if multiple from same user. * Ditto duplicate test. * Allow
    client to synthesise received date, etc.
* Bron: argue to drop array - you can make multiple method calls in a single
JMAP call. * Bron: but array can be handy for backreferences to an Email/query,
so maybe keep it! * Ken: we can pass in vacation state - should we do it for
other tests?
    * Alexey: yes if it's not too hard.
    * Ken: OK, I'll do that.


* Milestone review:
* Blobs: April 2021 / July
* sieve: June 2021
* addressbooks: Aug 2021
* submit JMAP calendars: Aug 2021
* jmap quotas: expired.
* jmap smime signature: expired, but June 2021 (revive and last call)
* jmap smime: Aug 2021.
* submit JSContact: Aug 2021

* adopt tasks (Apr 2021)
* sharing (Apr 2021)