# AGENDA JMAP/EXTRA at IETF116 {#agenda-jmapextra-at-ietf116} 2023-03-28: 13:00-15:00 (Yokohama time) ## Intro and notewell 5 min {#intro-and-notewell-5-min} ## JMAP - 50 min {#jmap---50-min} ### Existing drafts: {#existing-drafts} * blob / quotas (at RFC Editor) - 5 min Nothing to report * calendars / contacts (on hold for CALEXT) - 5 min Neil Jenkins: Calendars is nearly done. Small changes 10->11 Joris Baum: CalendarPreferences object different. Prefer to have more roles.. Autogenerated birthdays etc. then this will be an event property and not on the folder. Hans-Joerg: Many systems have autogenerated folders, don't want to duplicate. Special use role property? Currently use heuristics based on folder name to avoid duplication on migration (we know it will be created by target system as well) Neil: please follow up on list. Neil: we have time while jscalendar update happens. Hoping to take to last call after this meeting. Robert: would like to comment on default alerts. Recently implemented default alerts. JMAP Calendar spec currently defines "if in multiple calendars, use alerts set on all calendars that the event is in" - do wonder if we should allow a way for the implementation to say "two equal alerts on different calendars with same trigger and action don't trigger twice." Bron: propose that the default alert IDs - if the same across multiple calendars - be suppressed. Robert: yes, but maybe have different IDs but the same semantics. * sharing 5 min Neil: hoping to take it to last call directly after this meeting. * sieve 5 min Ken Murchison: Added onSuccessDeactivateScript argument to /set Otherwise ready for Last Call Hans-Joerg: Will be talking in Extra, but might have an impact on sieve. Stay tuned. * smime-sender 5 min Alexey: Working through to-do list, have prototype version of auto decryption now. Might need extension to query. Probably done next time. * tasks 10 min *Joris Baum* Version 6 released. Restructured Person object. New comments and checklists properties. Checklists - single object Future work to restructure Person usage, survey usage, finalize folder extensions, etc. ደሳለኝ መኳንንት: Does this also support internationalized scripts? ### New work: {#new-work} * jmap for Migration and Data Portability 15 min *Joris Baum* Motivation - Move existing data between systems, have an API spec for legacy systems, combine with other solutions RFC8620 is feature rich and generic, but complex "how to quickstart JMAP" - minimal requirements for one-time migration Example: no query method, or no copy or changes methods Simplified request scheme Overview table for specific applications Feedback from list that this doesn't conform with RFC8620. Possible approach to use constant values of error responses instead of simply omitting parts of RFC8620. For example, only one account with accountID "self" Neil Jenkins: Think this makes sense. Some implementations are very strict and might fail otherwise. Hans-Joerg: The use case they're focusing on is migration/portability, especially export from legacy systems. No point in asking vendors to implement methods they will never use. Q Misell: Agree with overall approach. Less happy about internal errors for core echo Bron: Why not require core echo? It's very simple, not a big ask. Jim Fenton: Think of this as a profile of the jmap spec. Simplified request scheme - put request properties in the URI? Neil: This is either extra work or something. Duplicating ways to do something Q Misell: Its own spec document would be useful Jim Fenton: Be careful about anything that might be secret that goes into the URI. Bron: Consider http2 request that links to individual things you might request. This would be a standards-track spec JMAP debug - supply log messages alongside usual data exchange. Helps with running on 3rd party infrastructure. JMAP backend info - ability to identify servers that don't properly follow RFC 8620 Hans-Joerg: These last 2 make sense when dealing with legacy situations. For syncing contacts minimal API may be sufficient, so might be useful beyond portability applications as well. ## EXTRA - 50 min {#extra---50-min} ### Existing drafts: {#existing-drafts-1} * partial / actionregistry (at RFC Editor) - 5 min Murray Kucherawy: One issue - document says informational, rest says proposed standard. Alexey: Don't care which really. Barry Leiba: What's wrong with publishing a new draft? Decision: Alexey will publish a new draft with proposed standard in headers. * imap-messagelimit - 5 min Alexey: WIll be ready for next IETF. * imap-uidonly - 5 min Alexey: Don't remember if there are open issues. Would like to experiment a bit more with implementations but the text is almost done. * sieve-processimip - 5 min Ken Murchison: Problem with some automated systems that don't send a request in the data, user would like to have the event added to their calendar. Should this be renamed? (not imip any more) Neil Jenkins: Lean toward renaming Alexey: Agree with Neil for simplicity. Should this wait for structured email? Bron: Calling this process-calendar is a better idea Hans-Joerg: Don't see a sieve extension for structured email soon, and this might be useful sooner so don't wait. Alexey: (agree) * sieve-snooze - 5 min Ken Murchison: Only outstanding issue was Pete was unhappy with haing a special "snoozed" mailbox. Pete Resnick: Lowercase the MAY because it's not a protocol option. * imap-jmapaccess (in last call) - 5 min Bron filling in: Help IMAP clients migrate to JMAP. We really want implementations. Arnt (later):Would really like to see an implementation. ### New work: {#new-work-1} * list-return-metadata - 5 min Ken Murchison: Request annotation data along with LIST commend. Is this worth WG adoption? Alexey: Seems sensible. Bron will issue call for adoption. * imap-inprogress - 10 min Marco Battini: Command progress notifications for search on very large folders and copy/move. Helps avoid user confusion. Send progress as a percentage, consolidated among things happening in parallel. Bron: Looks really good. Does there also need to be a way for clients to ask the server to stop? Tags in responses: Don't put \] in your tags. Need security considerations to make sure clients don't make assumptions and divide by 0. Total and goal can change in both directions. Alexey: All good points. Like this a lot. Having a structured field for this is good. Pete Resnick: This is good, but disagree with Bron: progress always has to be positive. Clients can't act on this if it's random stuff. Support adopting it. Hans-Joerg: Also support this, second Pete's comments but think the count could change because it may be hard to measure. Possible security issue: is the server exposing information that might be exploited? Concern re throttling: limitation on what a server allows a single user to do. Alexey: Throttling might be a separate thing. Bron will issue a call for adoption on the list. * sieve-filter-rule-metadata - 10 min Hans-Jörg Happel: How is Sieve used in the wild? direct usage (expert users) via direct file access or ManageSieve vs. indirect usage used by regular users. The latter is the dominant form. Indirect rules tend not to use things like ELSE and ELSEIF. Problem: interoperability - More sophisticated Sieve UI may interfere with vendor-specific scheme. So perhaps define standard set of rile comments, recommended deeactivation method, etc. Do we need "Sieve lite"? Pete Resnick: Coming up with a document would be great, this is a severe problem. Lots of interesting ways to approach this. Hans-Joerg: Perhaps do something constrained like the comment thing. Alexey: All implementations need to do things like comments so having a common way to do this would be good. Like the document, glad we're making progress. Ken Murchison: Might affect jmap-sieve, but think this is outside the scope. Hans-Joerg: Being able to identiogy the source of the script would be good. Bron: Proxies might interfere as well. ## AOB - 10 min {#aob---10-min}