Minutes interim-2020-jmap-01: Wed 23:00
minutes-interim-2020-jmap-01-202006172300-00

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