# 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 ## MINUTES * 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 capabilities. * 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 /query * 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 groups. * 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 roles. ## 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" filter? * 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. WGLC * 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)