* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Extra Status Pages

Email mailstore and eXtensions To Revise or Amend (Active WG)
Art Area: Barry Leiba, Murray Kucherawy | 2017-Sep-13 —  
Chairs
 
 


IETF-109 extra minutes

Session 2020-11-18 1430-1530: Room 1 - extra chatroom

Minutes

minutes-109-extra-00 minutes



          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.
          
          



Generated from PyHt script /wg/extra/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -