Skip to main content

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.