Bron: Intro and Note Well (particularly highlighted for CalConnect folks) Agenda review - no quotas discussion this time Minutes review from last time (Singapore) MDN - Raphaël Ouazana --- Currently -10 draft A few wording fixes Capabilities: only accountCapabilities finalRecipient, settable by client Use SetError instead of MDNError (registry issue?) $mdnsent flag explicitly set by client, add onSuccessUpdateEmail, server-side checks Alexey: for MDN Sent, how can I add extra field? Raphaël: Use body Alexey: No. Machine readable part. Would be nice to have an example Raphaël: Right, user can't add extensions currently. Discussion of the fact that extensions are ONLY server-set, so adding the ability to set them via JMAP as well when creating MDNs is good. ACTION: Raphael to wait a few days for feedback on the list then issue one more update to MDN doc with the ability to set extensions. ACTION: Bron to write up Shepherding doc for MDN doc. JSContact - Robert Stepanek --- Currently -02 draft, adopted by WG in Feb 2020 Major changes: mapping from/to VCARD (see draft-loffredo-jmap-jscontact-vcard-02) Requests adoption of above draft Next: revisit core data format Recommend that you read both drafts in tandem, and welcome any input about properties missing. Mike Douglass: Work going on in the ISO for addresses - do you want to let people know. Robert: for VCard there's an effort to define a method for global addressing. Believe there will be an update in the CALEXT meeting tomorrow. Don't know the timeline. This will update VCARD, which we're interested in mapping over to jscard. Might get away with implementing just one profile for the core spec. ISO is also doing names. For Names - don't know about the status of that work. We aim to allow localisation of addresses or other free text. There's a proposal in the draft, but it may change. Mike: was heavily involved in the last round of vcard changes, which went nowhere because people didn't think there was sufficient value. Currently defined address format is useless for about half the world's population. ACTION: Bron to issue call for adoption of JSContact vcard mapping document. S/MIME - Alexey Melnikov --- draft-ietf-jmap-smime-01 Added smimeErrors property (human readable explanation of problems verifying) smimeStatus can change Text about caching the above properties Issue: Should date/time of last verification be returned as a property? Two documents - this one is just signature verification, the other will be more complex - encryption and decryption. Might want to add another property - the date used for verifying. Bron: do we want to keep track of the last date it was valid. Jim Fenton: Security issue? DKIM signatures used in Wikileaks for proof of validity - there's some potential security/non-repudiation issues. ACTION: Alexey will prepare a revision of S/MIME document by IETF108, it should be ready for WGLC then. JMAP Calendars - Neil Jenkins --- draft-ietf-jmap-calendars-03 "updated" date Bump only if per-user properties changed? Set for non-organizer changes (e.g., RSVP)? Mike: which copy? Raphael: could it be an option? Mike: what's it even useful for? Should we have it at all? Neil: we could make it never update. Bron: it's valuable to know when it was last edited. Jim: RSVP is visible to other people right? Neil: depends! Proposal: updated value is stored per-user if there are per-user properties updated, and shared if shared properties are updated Party Crashing Barry: do you have a use-case where an attendee couldn't invite others but someone could invite themselves? Neil: it's a difference between internal and external. Anyone on team can add themselves, but outside people can't invite other outside people. Can't stop people forwarding things, but it can decide whether they can add themselves. (whether RSVPs are accepted) Mike: you need two separate properties because there's protections for "can see" that you cant' get with arbitrary emailing. Proposal: two separate values, one for "can add self" on shared calendars, another for "can forward invitation to externals". Take over event Mike: we should take a look at this. Gets closer to "social calendering". We should come up with something which works across servers. Having multiple owners helps, but we need to verify where to reply to. Jim: this could be subject to abuse. Need to think about the permissions model to make sure there isn't a way to hijack calendar items. Neil: yeah, this is out of scope if it needs changes to the ITIP messages. Neil: inclined to punt it because it can't be done with ITIP. Want full implementations to make sure it works. ACTION: Neil to do more work on JMAP Calendars spec. CDDL for JSContact - Henk Birkholz --- Henk: Wanting to create a CDDL of the text definition. The text is ambiguous. Do you have example instances? If you have those, we could test. Robert: except for examples in the second draft document (the vcard one) we don't have examples. Will check with Mario if he has a tool, and if that's public. That could be used to create any examples. Robert: good if we can define a formal spec - haven't looked into it yet. Henk: Will send updated version soon. ACTION: Henk to send updated JSContact CDDL definition ACTION: Robert and Mario to give examples or tool for jscontact/vcard translation to test CDDL against Milestones: --- Jun 2020 submit mdn Jul 2020 submit smime Aug 2020 adopt JMAP addressbooks ACTION: Bron to update milestones for JMAP working group