Skip to main content

Minutes IETF112: jmap
minutes-112-jmap-00

Meeting Minutes JSON Mail Access Protocol (jmap) WG
Date and time 2021-11-09 12:00
Title Minutes IETF112: jmap
State Active
Other versions plain text
Last updated 2021-11-15

minutes-112-jmap-00
# JMAP at IETF112

Agenda bash: No changes

# Blob

Bron Gondwana presenting

Bron introduced latest changes to the Blob draft
Should 'expires' go away - yes

Neil Jenkins: Everything else in jmap is case-sensitive, so leans toward lower
case. Also preferes asHex, doubt anyone will use base32

Ken Murchison: Do we need asHex?
Bron: Can ditch it, base64 does everything you need.

ACTION: Bron will upload a new blob draft, then ask Jim to issue a WGLC.

# SMIME

Alexey Melnikov presenting

Alexey was not available for the JMAP session at last IETF, but lots done since
then.

Caching time:

Neil: does it need to be specified.

Alexey: would be good to have it be consistent, maybe SHOULD be no more than.

Jim: revocation only happens rarely, but if it does then maybe you want to
notice quickly!  Checking a CRL every 10 minutes is a lot.  Think a day is a
good ballpark.

Alexey: if you have opinions, please send on the mailing list, otherwise will
change default to 1 day.

### IANA registry for smimeStatus?

Bron: JMAP is designed so you have to opt in to extensions already, so you
don't need to do either.

Neil: agree, you need to opt in to the capability, so that's the extension
point.

Murray K: think IANA registry might be useful as an index to this.  If you
think that is unlikely, then don't bother.

Alexey will propose some text, more like option 2 (no registry)

### make Email/get property available for query?

Bron: for sure you don't want to allow Email/query across your entire store for
"is valid now" if it needs to be caluculated, but at delivery time is good.

Neil agrees.

### is "signed" useful if "status at Delivery" is needed?

Jim: could `signed` mean signed by anybody?

Alexey: spec says that it has to match from.

Neil: proposal on slide seems fine.

### smimeStatusAtDelivery could go to valid

Bron: what I want as a user is "should I trust this message", including 20
years later when the key has expired.

Barry: semantics of revoked and expired are different.

Barry: does the CTL have a revocation date on it that can be pre-dated?

Jim: CRL doesn't usually have entries for certificates that have expired.

The user experience is terrible if all messages from the past lose their
trustworthyness.

Neil: Apple client profiles expire since they were signed with our old key when
they installed it and that's now expired for example.

Neil: if it changes, does this mean that the email shows up in Email/changes? 
It should, if this changes.

ACTION: Neil to remind Alexey of Email/changes issue with changing smime status.

ACTION: Bron to think of other names for smimeStatusAtDelivery.

### just reference existing RFCs?

Alexey: think it doesn't include "from must match".  Make sure to document that.

ACTION: Alexey will publish a new draft for smime, then ask IESG to publish.

## SMIME-ADVANCED (encryption)

Two new attributes on Email/set.

Need to control how S/MIME signing is done?

Something changed in XMLRFC rendering.

Bron: should we put this in identities?

Alexey: probably don't want to store the key material on the identity.

return blobId of decrypted message and let the client do Email/parse on it? 
Does the client need to ask explicitly?  Maybe have it auto-decrypt on
Email/get?

ACTION: Bron to suggest a "decryptBody: true" parameter to Email/get for
smime-advanced.

# JMAP Calendars

Neil Jenkins presenting

Was talked about at the interim.  We were hoping to have experience by this
meeting, but haven't yet deployed.

ACTION: Neil to update jmap-calendars draft based on the feedback from previous
meetings.

# JMAP Tasks

Joris Baum and Hans-Jörg Happel presenting.

Unlike Email/Calendar/Contacts - there's more difference in tools that support
tasks.

Discussion about "what is the goal of JMAP" - e.g. that you need to have a Blob
store!

No system supports ALL of JMAP for tasks, so some features may need to be
optional to get adoption.

Suggestion: extend with support for extra features.

ACTION: Joris and Hans-Jörg to continue refining surveys and contacing
developers/vendors for jmap-tasks.

Neil: data format is JSCalendar - JMAP Tasks is the server for it.  Format is
easy to extend.  They can register a new property easily.  Common stuff we
should try to register ourselves.

Neil: Should complex stuff be a separate datatype?  Could require a core set of
supporter capabilities, and have the server advertise which additional bits it
supports in the capability.

Joris: the History thing was already suggested as a generic thing.

Mike Douglass: don't see anything which isn't applicable to regular events.  We
want auditing/history.  Think all of these are features that we want.

Bron: agree that the capability object is a great place to show which bits are
supported (based on a survey of current systems) - it's going to be mapping
into some internal thing.

Robert: this 'history' stuff is something that might be useful generally, so
will work on that.

ACTION: Robert to work on a document for general way of doing history for JMAP
objects.

# jscontact

Robert Stepanek and Mario Loffredo presenting

Almost everybody here was at the interim - not much appears to have changed.

There's a subset of jscontact already implemented in RDAP.

Naming from unicode -> formatting and sorting mostly, which is out of scope
thankfully.

Add an 'nth' property for all components, even if allows more than unicode
covers with surname.

ACTION: Robert will contact Unicode and let them know what we're doing with
jscontact names.

Pete Resnick: FYI: If some formal liaison stuff needs to happen with Unicode,
Patrik Fältström is the liaison manager.

At the interim meeting, we discussed the GENDER property.  We haven't yet come
up with a solution for this.  Is there any discussion across the IETF? * In
some languages, the gender changes syntax. * VCARD has Gender and Sexual
Identity.

Unicode also has this as an open issue.

TODO: implemenation experience and deal with these issues before last call.

# IMAP Partial

Alexey Melnikov speaking

No EXTRA group, so came here for questions!

Extend SEARCH and FETCH to allow "fetch last N messages".

Ken: did we already try this with "VIEW"?

https://www.ietf.org/archive/id/draft-ietf-imapext-view-00.txt

Partial is easier to implement.  View tried to do too much.  Alexey will look
and see if there's anything work keeping from it though.

ACTION: Bron will call for adoption in the EXTRA working group for imap-partial.

# AOB

Blob stuff - it's an issue that many might need to deal with, but can do it.
* Ken on blob stuff - uploaded a new version of the sieve draft with an example
of how to use Blob/get to fetch script content in a single round trip.

This is also feedback on implementation experience.  Could be useful for many
sieve servers who don't want to expose via Managesieve.  Adds some challenges
for people who have rules on a local drive.

Bron: with Email/get you can fetch the bodyValues as well - maybe we could also
let you fetch.

ACTION: Bron and Ken to re-visit inline options for sieve scripts in jmap-sieve.

Discussion of sieve an mapping names of rules into and out of script.
* Horde has names for the rules which are displayed in the UI.

Ken: could we even manage this in sieve?

HJ: technically these are sieve scripts.

Bron: demonstrated how the Fastmail system works.

This is an issue if we try to make these things exposed via managesieve or
similar.

Practical problem of doing JMAP for sieve where we need a way to know how to
interpret the rule from the backend, so we can apply parsing logic.

Can use JMAP capabilities to tell which implementation is on the backend, BUT -
need to follow up in extra.

ACTION: Bron and Alexey to reply on the EXTRA mailing list.

# Milestones

SMIME advanced is adopted.

JMAP Addressbooks - after jscontact to WGLC, so... April 2022.

Maybe March for sieve.

QUOTA - maybe after EXTRA quota is done - Alexey will look.