Minutes IETF109: extra
minutes-109-extra-00
Meeting Minutes | Email mailstore and eXtensions To Revise or Amend (extra) WG | |
---|---|---|
Date and time | 2020-11-18 07:30 | |
Title | Minutes IETF109: extra | |
State | Active | |
Other versions | plain text | |
Last updated | 2020-11-18 |
minutes-109-extra-00
EXTRA session minutes - IETF109 (Bangkok virtual) === Wednesday 2020-11-18 14:30 - 15:30 We didn't have slides, so we worked directly from the online agenda. There was commentary that we rushed through the first few items very quickly and hence someone arriving a little late could miss things. We will try to avoid this in future. # Submitted documents: ## draft-ietf-extra-imap-fetch-preview * Barry just had to check if there was anything left to do, and submitted it for editing during the call! ## draft-ietf-extra-sieve-mailboxid Discussion that it doesn’t make sense to specify both Special-Use and MailboxId in the same fileinto. Everyone agreed. ACTION: Bron will update the sieve-mailboxid document to disallow use of special-use and mailboxid in the same fileinto. # Current work items: ## draft-ietf-extra-imap4rev2 Bron: 64bit -> issue with messages that are too big on the server when you’re looking with imap4rev1 -> what do we do? Can’t switch modes because UIDs will appear that didn’t show. DECISION: add text telling clients not to mix and match with IMAP4rev2 enabled and disabled with the same server. Always use it or never. Other suggested extensions: * Recommending is pretty light weight! * bits of ACL spec is useful - mostly in favour, and LIST-MYRIGHTS too. * MULTI MAILBOX SEARCH? Not sure how widespread. DECISION: include ACL, Alexey to decide if MULTIMAILBOX is worthwhile. Leave in weasel wording "other extensions may also be great". ACTION: Bron to submit imap4rev2 for publication now ACTION: Alexey to add the advice around 64 bit and suggested extensions to imap4rev2 during the IESG review phase. ## draft-ietf-extra-quota Alexey just posted -03. tied status items to be tied to capabilities, everyone agrees that is fine. overquota SP tag issue with ] DECISION: just drop the feature, don’t do it. ACTION: Alexey to drop "OVERQUOTA SP tag" from quota draft ACTION: Bron to WGLC quota draft immediately with a note about overquota ## draft-ietf-extra-sieve-snooze version -00 is what’s at Fastmail. will update specialuse and mailboxid to be mutually exclusive per above. fileinto option; more complex syntax. COULD use test-list syntax, but it would be ugly. Alexey: pro of updating fileinto -> in future people are less likely to forget to detail how this will interact with it! Regarding setting flags on unsnooze: Neil described that it’s for unsnooze creating flags to say that it’s been unsnoozed, because you can see the Snoozed folder over IMAP, etc. Maybe we can work around it, will check. Discussion of threading and some messages being snoozed, others not - implementation considerations about how clients display cross-mailbox threads. Ned Freed: there are some security considerations about how you implement this - if it’s snoozed until delivery, users can’t see that it exists at all, which could be confusing. And if in a special mailbox, different issues. Also, date headers depending on delivery. Maybe right thing is “you have to have implement it this way”. Neil: spec was written this way to accomodate other systems doing things differently, but don’t know any systems that are doing delayed delivery. Ned: no idea what people will do in the future. If they already have future release, they might just use that. Barry: need to say more in the document to guide people who are implemting it. Daniel Gillmor: also concerned about making sure we specify it. Don’t agree with Barry that users will know what they’re doing with flags - mostly users won’t be crafting this themselves, it will be generated code as part of a system with a snoozing button. Support the idea of saying “you shouldn’t do this with SMTP delayed delivery”. Neil: agree, it is better to have a single mechanism. Neil: The reason we want to have flags on awaken is that they want it unread on awaken, but not unread before that! Daniel: include this as an example! It’s a good example. Alexey: yep, without example it’s hard to understand why the complexity. Neil: let’s register the special-use and require that you use that! Ken: fine with that. Regarding syntax: we can reuse fileinto, but it adds lots of additional options, that also need to be updated. Neil: seems cleaner to have a separate command. Alexey: do we have an IANA registry for sieve actions? no, just for extensions. Ken - Ned, do you have any strong opinions? No, not really. Concerned about using tricky syntax to do things. Limited by 5228 not allowing arguments to arguments. Ned: not that hard to deal with all the interactions, go through the code and look at all the places where you do fileinto. Ken: our code does that too, treats it like a fileinto with different semantics. Alexey: leaning towards separate action. Ken: same. DECISION: keep snoozing as a separate action ACTION: Alexey volunteers to write a draft to create an actions registry. ACTION: Ken to rewrite sieve-snooze and register snoozed mailbox special-use. Are we going to limit it to IMAP? Works with JMAP too. # Milestone review Expect all the remaining stuff (except sieve-EAI) to be done by next IETF.