Skip to main content

Minutes IETF109: jmap

Meeting Minutes JSON Mail Access Protocol (jmap) WG
Date and time 2020-11-16 07:30
Title Minutes IETF109: jmap
State Active
Other versions plain text
Last updated 2020-11-18

JMAP session minutes - IETF109 (Bangkok virtual)

Monday 2020-11-16 14:30 - 15:30

## Intro and Note Well: 2 min

## Submitted documents:

### draft-ietf-jmap-mdn - 3 min

Barry is not here...has been in AD followup state. No known action required at

## Discussion of current work items:

### draft-ietf-jmap-calendars - 10 min

Neil Jenkins: Currently getting implementation experience.

- Adding invitations: You don't normally have permission to modify someone
else's events. Should server handle adding/updating invites? Not sure what
CALDAV is doing, maybe permissions aren't enforced. Perhaps add event without
claiming ownership of it (no email updates, for example). - Participant
identities: Planned move to one set of identities per account (rather than per
calendar). Datatype, not just account property? If so, merged with mail
identity? Are identity and partipant URI comparisons case sensitive?

Alexey: how different are they from Email identities?

* things like signatures are relevant for email, not calendar
* calendaring, may not be an email address - another update system may exist.
* some but not complete overlap

* update the principal on the calendar?
* how would we implement something like secretary mode?

* that calendar would come from a different account.  Would only be an issue if
the user wanted to share two different calendars, one in secretary mode, one
not. * Generally you'd have team calendars in a team account, plus individual
calendars would always be shared from individual accounts in secretary mode.

* Caldav format currently has one set of addresses per principal.  The thing we
build from here was a calconnect thing based an early Apple spec which is not
what Apple are using now.

* think it should be the same datatype, repurpose the existing Identity object.

* case specification: what do we compare case sensitive vs insensitive? 
Mailbox is potentially case sensitive but in practice nobody does. * 99% of the
time, ASCII case insenitive is the right thing to do.

* almost a question for emailcore.  If you ever have a system where localparts
are case sensitive, then you'll break things!  Don't do that.

* maybe a best practice to say "don't do that"

* can't compare generic URIs case insensitively.

* mostly mailto: right now, but could see different schemas in the future.

* https: host is case insensitive, path is not.

* will update spec for next IETF.  Think we've got ideas.

ACTION: Neil to update jmap-calendars spec before next IETF

### draft-ietf-jmap-jscontact - 10 min

Robert Stepanek presenting

jscontact-02 (no changes since last IETF)
jscontact-vcard-01 (has been updated)

* JAVA library which implements conversion between VCARD and JSContact and
validation of JSContact objects.

* during the mapping we cover everything of the available VCARD properties, is
that right?

* Tested the library against all the card objects found on the web, included
responses from RDAP service.  More than 1000 responses! * If anyone has
examples which aren't covered, would be happy to test against those!

* in any case, will provide a strong foundation for any changes.

What remains:
* weak points of vcard are still dragged into jscontact.   Address parts are
very "Western".  Expect that will be the biggest thing to get right. * Robert
will update the core spec. * We need more implementations!  Robert will do the
Cyrus IMAP implementation.

* challenge with vcards was the "groups".

ACTION: Robert to get more implmenentation experience with jscontact

### draft-ietf-jmap-sieve - 10 min

Ken Murchison presenting

Changes since IETF 108:
* accountCapabilities: new capabilities
* SieveScript object property changes (name and isActive)
* Nesting of scripts? (no comments)
* SieveScript/set
* SieveScript/query (filter and sort on name and isActive)

Alexey: would like isIncluded now that that idea was mentioned

* SieveScript/test request

Bron: asks about email blobs

* SieveScript/test reply

Should :fcc be its own sub-object?

Alexey: suggests not

Rate limits for test?

Bron: there is already a rate limit for setError, use that or http rate limit

ACTION: Bron to issue Working Group Last call for sieve draft soon

## New work:

### draft-gondwana-jmap-blob - 10 min

Bron Gondwana presenting

Several have read it. Jim to issue call for adoption.

Alexey: pretty sensible. Example for deletions.

Bron: Ephemeral yes/no?

Ken: get method: return raw octets?

Bron: Can only request as text, base64, or hex

Open question about range operators (in draft)

Alexey: this makes sense

RDIFF data about blob? Maybe too advanced for this spec.

Robert: properties mandatory?

Bron: default to data as text if text and base 64 otherwise, but maybe better
to require the format

ACTION: Jim to issue call for adoption for blob draft

## Discussion:

### Notes, Files, etc ... JMAP for data portability - 10 min

JMAP for data transfer: calendars/contacts underway, Fastmail has basic spec
for notes

Joris Baum: Interested in tasks as well. Is there a JMAP for tasks? Looking at
possibility of contributing in this area.

Neil: JMAP for this would be straightforward, referencing this data type.

ACTION: Joris to propose drafts for notes / tasks / etc.

## Milestone review: 5 min

Quotas, S/MIME still pending
Alexey: S/MIME in Spring (northern hemisphere :) )

Guidance document: still todo!  Pushed back a bit more.  2020 man.
Blobs pushed back a bit
JSContact: 4-6 months
JMAP Sieve: Fairly close, pending reviews. Last call once there is
implementation experience  probably December still/