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