Minutes IETF111: jmap
minutes-111-jmap-00

# 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!