# JMAP @ IETF 113 -- combined with EXTRA Monday 2022-03-21 13:30-15:30 UTC # AGENDA Approximate time estimates - 75 min JMAP, 45 min EXTRA Intro and Note Well: 5 min ## JMAP With Editors: - draft-ietf-jmap-smime / RFC9219 to be Active Drafts: 65 min - draft-ietf-jmap-blob - 5 min - draft-ietf-jmap-quotas - 5 min - draft-ietf-jmap-sharing - 10 min - draft-ietf-jmap-calendars - 20 min - draft-baum-jmap-tasks - 20 min - draft-ietf-jmap-smime-sender-extensions - 5m JMAP Milestone review: 5 min ## EXTRA With Editors: - draft-ietf-extra-quota / RFC9208 to be Active Drafts: 30 min - draft-ietf-extra-sieve-action-registry - 10 min - draft-ietf-extra-sieve-snooze - 10 min - draft-ietf-extra-imap-partial - 10 min (if adopted) Proposed: 10 min - draft-murchison-sieve-processimip - 10 min EXTRA Milestone review: 5 min # NOTES Bron presented the Note Well and meeting tips. ## jmap-smime Alexey is working out a few formatting things with the RFC editor. After that, will be done. ## jmap-blob Blob-set now Blob/upload Catenate removed Capabilities simpler (blob size etc) Has gone through WGLC, so make comments soon if needed. Otherwise Jim will pass it on to IESG Comment: Hans-Jörg Happel -- * possible to explicitly only fetch the size, which is cheaper than fetching just the data, so create an example with that, and point out the possibility. Second: does it make sense to have a list of all blobs? (Blob/query) Alexey: think taking out catenate is good. Neil: not sure Blob/query is a good idea. Point was in-band upload and download. Blob isn't a real object in the same way. ACTION: Bron to push out another revision of jmap-blob and then Jim will repeat WGLC. ## jmap-quotas - Rene Cordier QuotaIds removed, capability now an empty object Removed custom extension for scope and resource type Resource type in octets ACTION: Bron to WGLC jmap-quotas ## jmap-sharing - Neil Jenkins Draft is fairly simple, can probably progress quickly 1 more update then WGLC ACTION: Neil to update jmap-sharing draft, then Bron to WGLC ## jmap-calendars - Neil Jenkins Fair amount of implementation experience now. ### CalendarEvent#isSource - property indicating if the JMAP server is the source or elsewhere - Whether to send RSVPs or if you control it - Any better names for this? (Barry Leiba suggests Controller) Bron: Need to think about how this is set on import/export. Server needs to know addresses it receives at. Joris Baum: Added a source property for jmap-tasks so might be confusing to have isSource and Source ### Default calendars: Does there need to be one? Barry: default calendar is like IMAP INBOX. * if needed and doesn't exist, create a new one. So require a default. Would be useful to have Ken Murchison: clearly in favour. If a server processes iTIP, need somewhere to put them. * Neil - does that mean MUST always be at least one? * What if you delete it? Have to create a new default? Prohibit delete. Barry Thumbs Up. Pete / Barry -> maybe like with INBOX. Robert S: don't care so much if default calendar MUST be specified. Could still state that servers might pick whatever calendar, or create one, or invite can't be delivered. * Fastmail implementation: allow delete default, but immediately pick a new one. * Might make sense in the spec to say "set to NULL, but server might choose something else". For participant identities -> should align JMAP and CalDAV spec. 6638 says "if destoryed in caldav, this disables scheduling for that account" - suggests that JMAP must be non-empty participant IDs. * Neil: Server is allowed to reject destroy, and might reject you destorying your username. Allow or not should be a flag in capabilities. Alexey: what are benefits of not having a default calendar? * from IMAP experience, multiple outcomes is bad for clients. Hans-Jorg: in favour of default calendar, unaware of systems that don't have one. And from UI perspective, would be weird. * most systems, default pre-exists with a particular name and is a problem if it's deleted. * Case is: not allow delete. Ken: can't speak to interop, but: * if the expects scheduling, they need at least one read-write calendar. Default is just "please put new invites here". Shouldn't make it more than that in JMAP. ### Default alerts for new calendar - Default to null or default calendar alerts? or vendor specific? Ken: Attach default alerts to principal - Can you set default alerts if you don't have mayUpdatePrivate ACL? Robert: Agree that setting default alerts then doesn't make sense ### Other preferences like first day of week, date format Daniel: Not sure why default timezone is by principal, rather than by calendar. Neil: Calendar has a timezone, but inherits from principal Daniel: feels like it belongs in the same place. Ken agrees. ### IANA registry for per-user properties? Bron: Should modify existing registry rather than create a new one. IANA can handle registry mods. Almost there, need to add examples. Hope to get to last call before next IETF meeting. ACTION: Neil to update jmap-calendars draft with more examples. ## jmap-tasks - Joris Baum Task survey posted on GitHub Added `source` property, `estimatedWork`, `impact`. Extended `progress` property, `relation` object. ### progress property New values: deferred, resolved, needs-feedback, confirmed Robert: think we can just extend the existing registry in jscalendar. dkg: confirmed seems orthoganal to other properties. Also not sure why both Resolved and Completed. Joris: methodology was looked at issue tracking systems - they have properties like status, impact, etc. Not sure if there's an issue tracker that allows confirmed vs assigned. dkg: have seen issue trackers where there's a separate state for "confirmed" vs "assigned". Useful to have separate tracking. Would also be worth clarifying resolved vs completed. Joris: believe resolved == fixed, but completed might be a wontfix. Just not working on any more. Maybe needs to be specified better. ACTION: Joris to specify the progress tracking better, or split up. Ken: agree that they're probably the same thing, naming is UI. ### grouping properties Adding lots more properties to jsevent object, some systems don't need certain properties. Ken: why do we need grouping? What's the goal? Joris: if server does the whole JS calendar spec, you expect it to understand all the properties. Hans-Jorg: replying to Ken. Found that task systems are much more hetrogenous than calendar systems. So many won't support all our fields. If you want to use this for interoperability, you need to be able to say what the servers support somehow. Neil: think that the grouping idea with a small set of possibilites makes sense. Ken: rather than specifying which properties go in various groups, come up with levels of capability. Make the common stuff mandatory, then if you have other feature sets, you describe the properties required. Make the rest sub-capabilities. Robert: if grouping comes, then suggest also introduce a new setError -> notSupported, gives the required capability? Ken: agree with Robert that for base draft, we can expect implementations to know they don't support it, but for future extensions we're stuck either way. ### blob.created When blob was created: do we want this? Neil: we should put it on the referencing object (so inside the task/event) not on the blob. Robert: promised to come up with a spec for all JMAP object types for property changes. * depends on the semantics -> if it's for the link, then it would be when that was created - if it's for the underlying data, it's different. * Joris: no consensus on this. * Hans-Jorg: think this is JMAP specific. Most systems don't let you reference items. So what you're talking about is when the user linked it. ### keywords Discussed on the mailing list -> having the colour property on the task list makes sense. Same for calendar? Neil -> haven't seen it there. Neil: should it be a separate datatype? TaskList object? It's like a label. Robert: like Bron's proposal. ### future work Still need to get feedback from task system vendors. ### final notes. Robert: for estimated work, think property is useful. Not sure if arbitrary number is useful, because probably mean different things for products and teams -> may not be useful for interchange. Wonder if impact is necessary, or if priority is enough. For source property _ wonder how much value it provides if free-text. Would different implementations do the same, or do we want to enumerate? Or product ID? ACTION: Joris to produce an updated jmap-tasks draft based on feedback from this meeting ## jmap-smime-sender-extensions - Alexey No recent update to draft S/MIME signing control Daniel: believe we're reaching where default could be true. Also how would SMIME signing work? Delegate keys to server -> Bron: yes, server is part of your "end" in the JMAP case. Alexey: we can talk about decrypting next time. # EXTRA ## extra-quota Alexey: IANA issue being resolved, will publish soon. ## sieve-action-registry Basically done - send to WGLC ACTION: Bron to WGLC sieve-action-registry ## sieve snooze Implemented at Fastmail in Cyrus. Want WGLC Alexey: checked diff, is fine. ACTION: Bron to WGLC sieve-snooze ## sieve process IMIP Ken suggested this. Decided on action vs test. Documented what we implemented. Deployed to Fastmail users last week, appears to be doing the right thing. Alexey: have scanned the spec, seems to make sense. Couple of comments: * first time there's two output parameters, but seems OK. * outcome: might be better to split into two different values * Now that sieve action is in last call, have to deal with that. Hans-Jorg: is there a standard way that IMIP is currently implemented in systems? And this hooks in a dependency. Ken: only two ways known are: * a) clients do processing * b) server has an out-of-band way. * this is a way for the user to be in control in a standard way. Alexey: before it was hard coded everything or specific limits. Ken: yep, and this doesn't tell you when to do processing, just how - you can wrap sieve. Bron: will do call for adoption on the list. Alexey: not everybody will implement, but it looks sensible and belongs in this group. ACTION: Bron to call for adoption sieve-process-imip ## imap partial Extension to deal with large mailboxes (large >~50k) - Paged search Do we allow a mix of negative or positive? No, it's one or the other. E.g. -1:-100. Clarified use of PARTIAL and CONSTORE ogether New extenson: MESSAGELIMIT Should COPY/UID COPY fail partially? Bron: Should return an error Ken: Does this affect inbox renaming? Barry: previously don't have any stuff in IMAP where the server puts limits on things that the client may not know about. This is the first. Don't like this. If the server tries to do anything above the limit, it should get NO. A client that understands the limit knows what to do. A client that doesn't understand won't do weird things. Users will try clients, get error, complain, client has to discuss with server vendor. Bron: agree, we should reject operation rather than partial complete. Barry: as with what Ken said with INBOX rename. Have to have an exception to message limit for INBOX rename. Server can say "NO" or has to do the lot. Alexey: please send reminder to mailing list. ACTION: update draft to say about INBOX rename. Ken: as a server dev, think partial is straightforward to implement. Have you implemented in clients? Would like to see running code. Alexey: Did implement on client side. But didn't test with server. Actually makes handling big mailboxes with webmail clients etc nicer. Don't need to map 400k messages. ACTION: Alexey to update imap-partial draft based on discussion at this meeting ## Milestone review (both WGs) Appropriate adjustments made directly in datatracker.