# JMAP Working Group - IETF 111 Tuesday, July 27, 2021 16:00-18:00 PDT (23:00-01:00 UTC) Chairs: Bron Gondwana, Jim Fenton Minute takers: Bron and Jim ## Agenda ## Intro and Note Well: 5 min Neil Jenkins: Asks about errata that have been filed for core spec. Bron will check on that. ACTION: Bron to check who needs to approve errata for core spec. ## Core: 10 min ### draft-gondwana-jmap-blob - 10 min Bron presented the blob draft, now adopted by the WG. Adds concatenation support, named datatypes, IANA registry for datatypes Still needs implementation experience! Ken Murchison says Blob/set has been implemented in Cyrus JMAP, but may need tweaks to catch up with latest draft IANA registry details, in fine print. Do we need an IANA registry for this, or redundant with capabilities registry? Limits, e.g., MaximumBlobSize? MaxSizeUpload? Ken: push uses datatype names. Neil: Need to forbid duplicate datatype names? Bron to ask IANA if duplicate names (keys) are allowed. Will add some additional text describing this to next revision of the draft. Q: Do we need a separate draft to create the registry? A: everyone said no. Q: Lookup capability separate from get/set? Or boolean? A: discussion settled on "list of datatypes for which lookup is supported in the capabilities object" ACTION: Bron to publish new jmap-blob draft with capability information and registry instructions ## Mail: 5 min ### draft-melnikov-jmap-smime-advanced - 5 min Alexey is chairing another session so Bron presenting. Not actually all that "advanced" Bron will issue call for adoption to mailing list. Neil: Should probably return what the new body structure is, as all JMAP methods do when the server makes a change to the object being created. ACTION: Bron to issue a call for adoption for draft-melnikov-jmap-smime-advanced ## Calendar: 30 min ### draft-ietf-jmap-calendars - 20 min Neil Jenkins presenting Small update submitted. Some implementation experience but would like more. Spec seems to be holding up well. Interesting case: deleting instances as an invitee. How to handle updates to recurring events if an invitee has deleted an instance? Options: - Add extra property if user deleted it - Just forbid it Jim Fenton: what about if the event was updated to a new time? Maybe the user wants an offer to attend again. Mike Douglass: as an attendee, you don't own the event, so you can't delete it! The correct thing is to not let them do it, you can only update your attendence to it. Neil: yes, but existing systems appear to let you do it. Ken Murchison: agree that declined is the right thing. E.g. with Apple calendar a delete turns into a decline. Neil: see a consensus for forbid the user from deleting individual instances. Event ownership: Should you be alllowed to update an event so you are no longer the owner? (transferred ownership) ... Event ownership edge case: * if no owner, "may update own" allows. Joris Baum: should just allow the change. Mike: if you can't undo, you can't undo! Let things fall as they may! ... Default identity: * could put on a per-client basis, but if we're going to store on the server we need a place! add 'isDefault' property? But have to make sure exactly one has true. Or put on capabilities, but only if it's read-only. Mike: suggest a general preferences object - there will be other properties. Fastmail has something internally for this -> Mike, you probably want that synchronised. You may want different preferences per account. Mike: if we go through the list of the DAV properties, that would be a good starting point. Good to have it as a fetchable object. At the start of any caldav session is a fetch of a bunch of properties. Can have an object with its own last modified, etc. Can use standard JMAP update logic. ACTION: ALL keep working jmap-calendars design on the list, hopefully finalise by end of the year. Robert Stepanek: 3 things. #### 1. CalendarEvent/query expansions CalendarEvent/query allows for expand recurrences. This creates synthetic events. Need to make clear that these will NOT be reported in changes. Only the master event ID will be included in changes. Bron: do we need a property on the synthetic events? Robert: common property would be UID, but that doesn't tell what the JMAP ID is. Neil: that would allow invalidating all the events. Robert: alternative would be relation parent/child, but parentId would be better choice. ACTION: Neil to add property for parent JMAP ID to server-side expanded event recurrences #### 2. inbox role: right now optional Robert: idea, make `inbox role` mandatory. If the server supports scheduling it can indicate it with a capability. If removed, we have nowhere to put calendar invites. Neil: if we're going to create the calendar preferences object, we can move it there. Robert: how do we deal with not requiring all implementations to support scheduling? Neil: allow `null` if you don't support scheduling. Mike: can see situations where the server might allow certain accounts to have scheduling disabled. Bron: if you remove it, then you're turning off scheduling! Robert: so long as we say that the server can reject it, that's OK. #### 3. Invited to a recurrence instance only (or multiple) Robert: What if you're invited to a recurrence first, then to the full event? What happens? Mike: if the master event arrives, you throw away the individual instance. Robert: maybe it has a different resource? Neil: you can either have a master event, or 1 or more individual recurrences. This is mostly a problem for the iTIP handler (it needs to merge all your local alerts, etc) ### draft-baum-jmap-tasks - 10 min Joris Baum: Not much has happened since the interim, been busy with other things! Collecting implementation experience with various JMAP specs. Still need to publish a survey about various task systems. Be happy to hear of others who have collected experience. Bron: any requests from the group? Joris: not right now - next time will present notes and experience. Not in a very finished stage yet. Neil: don't have any questions right now, but will make sure to review it again. Agree that server capability research is important to cover use-cases that people have. ## Contacts: 30 min ### draft-ietf-jmap-jscontact (+vcard) - 30 min Robert Stepanek presenting Localising content - preference of most participants was patch object (same as jscalendar). Will wait on mailing list for feedback. * If nothing else, we have consensus from those who have an opinion! Intend to add `@type` property. Speak up if you object! Per-field metadata (e.g. update time.) Unsure exact use-cases, but could do with a patch-object path. Does anyone else have an opinion? Mike: has been raised for both calendar and contacts. Some kind of standard audit-trail. Neil: this isn't an audit trail, it's just the "last updated". Mike: in this form, yet - but a change-log would give an audit trail instead. Bron: so a "reverse changes" log? Would be great. Mike: there's already a model in caldav-sharing, a "change reporting mechanism". Used by Apple Calendar application to show changes too. Only thing missing is not attached to the changed object. Neil: allow only server-set, truncate over time, etc. Not a default field. Robert: so this might be a general extension RFC for any datatype? Use for JSCalendar, JSContact, etc Mike: same format could be used to report changes too! Look at this across both calendars and contacts. ### Multi-sourced contact Allow providing a unified view for a contact from multiple sources. Neil: that's a client thing, not a data format thing. Same UID or "match on things". Bron: tricky thing is where to write updates to. Neil: again, needs to be a client thing. Mike: the Apple client does that, unified view. Robert: yes, but client does that. Mike: indication of source would be good. Joris: concept is interesting. UID is randomly generated so could be different on different systems, could be clashes between sources. Neil: very unlikely to get a clash unless it's the same object. Bron: sometimes users edit things in different systems in different ways without realising that they have the same object identifier! Robert: that's all. Mario: no additional points. Field metadata approach has interest -> start definining under umbrella of JSContact but make general. Robert will write up before next meeting. ACTION: Robert to write a draft for storing metadata/history on JMAP objects. ## Discussion topic: the large email problem (20 min) Bron presented slides from DISPATCH yesterday. Problem: want to send large files in email, also attach to events and contacts Problem: files keep getting biger Current solutions: Google Drive, Mail Drop (iCloud) Problems to solve: * Upload of large files * ownership/responsibility * discoverability and embeddability (attachment/inline, virus checking, search for attachments) * Also privacy issues Global ID for attachments needed? Ned Freed: Hash of reference object defined in RFC 1864 Discoverability: Following links from emails is dangerous, hard to know what links are attachments, lifetime uncertain, content changes John Levine: consider sending pieces and reassemble, ala Usenet. This is a problem we need to solve, because users are running into this. Neil: prefer pull model rather than push, so users aren't overwhelmed by data. John: Would also like to write down the threat model. Jamey Sharp: Could encrypt the attachment and send a symmetric key in the email with the link (+digest for integrity). Ned: This also allows AS/AV scanning Hans-Jörg Happel: Need to standardize URL-based sharing, then apply to email Ned: If content can't be scanned, enterprises with security concerns will not deploy. Ned: URL type that wraps existing URL plus hash may already exist. Larry Masinter maybe? ACTION: Bron to follow up with DISPATCH about large file problem work ## Milestone review: 5 min Blobs is adopted Sieve had some feedback, so is still to be submitted - Dec 2021 Calendars - now December 2021. Needs examples, etc. Blobs - December 2021 if we get implementation experience Quotas - status unclear. Has expired. April 2022. S/MIME - submit in July (this month!) Key management: Adoption in August 2021 jscontact: December at earliest Informational document on guidance: No progress, now April 2022 ACTION: Bron to update milestones for JMAP WG ## Any other business: 15 min Jamey Sharp: Any interest in JMAP for RSS? John Levine: Watch out for collision between XML and json Bron: Generally yes, if you bring it we're interested in considering it, but not much RSS experience in this group. If JMAP can be helpful then we're happy to help!