# JMAP / EXTRA at IETF115 London {#jmap--extra-at-ietf115-london} Date: Thu 10 Nov 2022 Time: 13:00-15:00 local (12:00-14:00 UTC) Chairs: Bron, Jim and Jiankang - all present in person! Jim presented the notewell. ## JMAP {#jmap} ### blob {#blob} * new draft update based on SECDIR review * Murray has no comments yet, may later No actions required. ### sieve {#sieve} * People had comments in WGLC. * Wanted to find why an action had failed through this protocol. Might be a good extension. * Currently to deactivate a script, you use activate script with an empty string. Request was to add an explicit deactivate. No strong opinion. Alexey: don't mind, just tell me what to do Ken: just followed Managesieve. Neil: spec says should be NULL, not empty string * Advantage to separate property is you don't have to submit every argument, which could be valuable for strongly typed languages. * There's no value you can pass that doesn't do something in current spec. Ken: no big deal, will add. Hans-Joerg: remember quite some time ago discussed sieve for JMAP - related to sieve in non-JMAP context (how people build sieve rules from another system). * Concern with sieve for JMAP, would be nice to know the underlying system which owns the sieve. Could there be a property? Can it be derived from JMAP response? Alexey: is it library or author? H-J: sieve structured by underlying software. Helpful for client to know. There's a greeting via ManageSieve. In ManageSieve RFC this is described as: IMPLEMENTATION - Name of implementation and version. This capability MUST always be returned by the server. Bron: server header via HTTP? Ken: if this is important, we can add a property to the capability which lists the implementation, but guess some sites might want to suppress that and not leak the implementation. ACTION: H-J and Ken to discuss on the list about representation ACTION: Ken to add "disable" ### calendars {#calendars} Joris: recently synced the jstasks draft with changes from calendars, there are a lot of parallels. * stumbled on the "CalendarPreferences" object, haven't tagged along yet. * in JMAP Mail, there's a "role" property. For calendars, this was also there. "inbox" only for now, to say "this is the default folder". In the newest version this is moved to a separate object, wanted to understand. * Don't like that we have two approaches, different from mail to calendars. Want to know reason. Neil: * discussed this. In mail it's immutable. Want to enforce "at most one is the default". Easier to enforce with a single object, there's no way to specify multiple. Robert: * Regarding the dependency -> at calext we set the deadline for jscalendarbis to July 2023. Under assumption that there's no hard dependency but will see if that's really the case. Bron: * yep, we'll wait and do them together. Robert: * Regarding role vs calendarpreferences, it's more straightforward to have one property where the default is defined rather than implementations having to look at all roles and make sure requirements are satisfied. Already have to do it for JMAP Mailbox. Don't have a strong opinion on either. Joris: * one crazy thing you could do is have both. Calendar Preferences is already defined as an extension, so only have role as a property inside the folder, or also have the preferences object. Don't need to look at all calendars, just fetch the preferences object. * For our use case, would be easier if inside the folder. * Might make sense to take it to the list. * Feedback on both? Neil: prefer NOT both, it would get confusing. H-J: * didn't have time to look up in spec, but sounded like the default folder is the only role in mind so far? Neil: * yeah, it's not called that any more. H-J: * Might be other roles that are interested like "autogenerated birthdays", etc. * If more than one role, might be worth adding that. Bron: * Fastmail has something like that too. H-J: * some systems won't allow you to do things. Neil: * Can tell from ACLs * Might want to have more thane with these too. ACTION: role vs preferences discussion to the list. ### sharing {#sharing} Extracted changes out, much simpler. Probably publish at the same time as JMAP Calendars. Ken: * if this applies to JMAP email, go ahead and publish straight away. Neil: * it's kind of abstract, but could apply to mail - but you'd have to make a separate spec for it. Bron: * suggest publish it first. ACTION: Neil to fix editorial ACTION: Jim will take WGLC when it's ready ### quotas {#quotas} In last call too. Thanks Murray for reviewing it. Implementation in James server. Screen share done! ### identities {#identities} When frontend team started implementing, asked for a way to get default identity to show. Joris: * Also looked at this and saw the same thing, a lot of systems have a default signature. Also came up with own thing, will post it in the chat. * Own extension has signature name, and some systems have default for new vs reply vs forward signatures. Rene: * could discuss more on the list. Neil: * sort order might not be the right thing to do. Implies you might be able to manually order them. Have seen lots of "drag and drop mailboxes around" but generally identities are sorted alphabetically by a client. * Specifying default seems fine, ordering might be too complex. Rene: * Rene dkg: * Wanted to +1 the last two. There are potentials for multiple types of defaults, default for particular reply, etc. * Might want a different default when replying to a paricular person - want default or default in different contexts. * Leaves room for somebody to specify defaults for other contexts. Bron: * Fastmail has more powerful stuff too, per-recipient address, different folder. Neil: * The reason we didn't do more is it's hard to specify something universal that's powerful enough. Rene: * Agree, yeah it's too complex. But at least a flag saying this is the default. Neil: * Would definitely be a common thing Jim: * A common case is with an organisation, where you might have a different signature for internal vs external email. Joris: * With JMAP you can create your own extension and write your own capability, but if interest then discuss in IETF context. ACTION: Rene will start discussion on the mailing list. ### tasks {#tasks} * slide 6 -> should be VTODO not VEVENT Robert: * Haven't given much thought on which I would prefer. * If this isn't a list, why is there a sort order property? * Why not a map of ID to propery (standard JMAP property) * Can be good reasons to use a list, but with key-value idiom you can patch update - add or remove, don't have to use whole list. * If you want to preserve the order, then the sortOrder property wouldn't be of use. * Second proposal looks more familiar to me in terms of how things are in other JMAP. Jim Fenton: * Less about representation of multiple checklists, and how they will be handled. * Some clients support multiple, others don't. Joris: * Didn't try to use clients, but Trello has API. Jim: * Need to consider what clients can render, so if you have a client that doesn't support multiple checklists, do we determine client capabilities and handle them, or do the other checklists disappear? Joris: * up to client how to handle. Jim: * Not sure if client or server responsibility. Joris: * Have a flag on the server to say "I do multiple checklists" Jim: * does the client say it doesn't support multiple checklists? Joris: * With how JMAP works now, would be easier other way. Robert: * Other thing I was wondering about, are "assignee" and "isComplete" properties. * What's different between assignee and participant? Joris: * Trying to keep checklist item as simple as possible, so not pull in whole complexity of task. Much simpler to have assignee. * Hmm, you're right - iit should be a participant. Goal is to make it simpler. Robert: * Am biased obviously, thinking that using full blown task achieves everything you want minus the simplicity. Maybe a middle-ground to define what's necessary to achieve checklist. Use already defined scheduling properties and just not require implementation to do ALL of scheduling. Joris: * If already implemented, should be easy to use. * Already a capability for "I support scheduling" Robert: * want to support this for implementations that don't implement scheduing. H-J: * For Jim, the case with mulitple checklists for Trello is a specific case, don't think we need to overengineer here. * From Audriga, coming from portability side, so interoperability is useful but format needs to be portable. * See this as an issue for the client, need to either support this or give a message to the user. * We're a third party system, in the middle - need to convert data, merge things together or whatever. * To Joris -> think it's necessary to have a "checklist" type, otherwise clients may be tempted to add properties to the task. * Issue for client - have to have all the instances and filter through them -> e.g. fetch a task and its related items. Bron: * Propose that if doing muliple checklists, they're a single set of check items with IDs, and you can patch them - and a c ACTION: Bron will send something to the list Darrel: * Github issues allow you to create multiple checklists within a single issue as well. ACTION: Joris keep working ### smime {#smime} No changes ### migration and portability {#migration-and-portability} Last time Bron suggested path based H-J: * One clarification -> the motivation is that we consider JMAP a good choice to wrap an existing legacy data store. * Increasingly seeing JMAP as a good option to lift existing data for migration purposes. * Not necessarily for public exposure, but restricted usage to move data. ACTION: Joris will create a draft. ## EXTRA {#extra} ### partial {#partial} * Comments from Murray ACTION: Alexey to publish changes when last call finishes ### sieve action registry {#sieve-action-registry} * Replied to Murray, he asked about a column. Need to decide. ACTION: Alexey to publish changes ### MESSAGELIMIT {#messagelimit} split off There is desire for server to be able to do this WITHOUT the client opting in. Client doesn't want to opt in, no benefit for client. Barry: * what's the actual benefit to the server? If the client wants to copy 10k messages, it just does 10 copy commands. You've made the client more complicated and the server doesn't have to do any less work. Vikram: * primarily need this on fetch and search * problem is clients don't understand that there's a large set of messages and they give 1:\* and it gets timeouts on server. Barry: * so you want the client to do 10 copy commands? Alexey: * can have the server keep sending untagged responses? Can do that to stop timeouts. Barry: * if we make copy checkpointable (server just sends a checkpoint every N messages) then the client doesn't have to retry it and it fixes the timeout, but doesn't require client to resend every command. Ken: * Want to clarify - we still allow server to return "NO MESSAGELIMIT" if too large. Alexey: yes Barry: * And we'll think about an alternative for copy that works better for Vikram's case. Alexey: * then we remove ENABLE messagelimit. * unextended client will be unable to copy large message sets then. * Extra SEARCH criteria * Right now, you can't do a UID based range without doing two queries that you can't pipeline. * do we WANT to do this? Barry: * It looks clever, will anybody implement this and care about it? Alexey: * am writing a webmail server -> get lowest message that is non-junk non-deleted. Barry: * Don't object if there are clients who will want to implement it? Just "will we write it up because it's cool" Alexey: * Will play with it, and only write up if it's interesting. Not part of this document. Bron: * re searchres: save what you found, so if limit, safe the limited bit. Ken: * wouldn't be hard to implement (server side) in the Cyrus server * Don't think we'd implement at Fastmail * It'll be an option in the server. Alexey: * if you can do it, would be good to have feedback. Vikram: * will do interop testing in early Dec. ACTION: Alexey do another revision and wait for implementations. Interop testing in early Dec. ### process imip {#process-imip} Don't think there's outstanding issues. Got running code in production. ACTION: Bron to do last call. ### snooze {#snooze} There was an issue with snooze via IMAP and special purpose mailbox. Pete had an issue, haven't heard back. Ken will ask during emailcore. ### JMAP upgrade {#jmap-upgrade} Ken: * think it's worthwhile * is there any reason to not put the URI in the capabilities post authentication? Bron: * don't want to generate one for every single connection. H-J: * I have a different use-case, platform migration. * Wonder if there's a bigger picture for this. Need to think more. * Maybe need to think more and come back on mailing list Alexey: * IMAP has REFERAL extension which has a URI. There's a "server" and a "mailbox". If server, can just say "HTTPS URI is now legal, go there". Don't know if it's a good idea or not. * If we're going to automatically generate auth token when requested, it goes against OAuth philosophy, you'll get a token or it will fail. User might never see the page saying "you're connecting to this server". In which case doing SASL Oauth. Bron: * sounds like an argument for "using OAuth via IMAP, same token". H-J: * migration enthusiast. * Maybe some relationship to the draft in HTTPAPI working group for non-interactive OAuth. * Would it be better to support changing auth schemes in a different fashion. If provider is shutting down IMAP, client can tell user they now need to upgrade. * If we want clients to adopt, it will need to be explained. Ken: * Getting too far into weeds, feels like poeple are interesting Bron: * anyone want to speak AGAINST adopting? Alexey: * Think there's enough interest in the room to investigate this problem. Don't think the proposal on the table is cooked enough to be adopted. Barry: * Don't think things need to be fully baked to be adopted. * There's enough here to start thinking, can use that. ACTION: Bron to put together a draft, then we can talk. ## AOB {#aob} John Levine: * Have a draft to revivify Expires: header, do we want to add something to IMAP? Alexey: * This is boolean, and flags aren't boolean. * Are you trying to get the server to annotate with "ISEXPIRED"? John: * I think that's what I'm asking. ACTION: To the list.