Subject: [Extra] Meeting minutes and notes from today

From: Bron Gondwana <[email-masked]>
Date: Wed, 15 Nov 2017 16:30:36 +0800

Meeting minutes (and slides, and agenda) are up!

https://datatracker.ietf.org/group/extra/meetings/

*Minutes:*

Action Items

- Bron will poll the WG list for objections to adopting SAVEDATE and
  STATUS=SIZE- Barry will bring his IMPORTANT special use extension draft back to
  life- Discuss Ned's objection about whether IMAP server can do the
  FCC extension- Wait to address SIEVE EAI until after our current batch of
  documents is done

>From my memory, I also had action points to post each of the
current drafts and ask if there are any objections to any of the
existing drafts:*
*
*We believed in the room that these ones are basically done:*

https://datatracker.ietf.org/doc/draft-ietf-extra-imap-list-myrights/
https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-special-use/
*
*
*There is an open question for this one:*

https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/

Ned Freed objected to supporting :fcc for the REJECT action because it
allows the sieve server to "lie" about whether it's keeping a copy of
the message.  There was debate about whether we should stop people lying
at this level, especially since a mail flow could take a copy of every
single email before it reached sieve.
*Alexey made a mistake in this draft and will update it again!
*

https://datatracker.ietf.org/doc/draft-ietf-extra-imap-64bit/

but it's pretty much otherwise ready, nobody had any problems with any
of the concepts.
*Quota
*

There was discussion of bringing an old RFC2087bis out of mothballs -
that may happen after this current round of documents.
*SAVEDATE and STATUS=SIZE
*

These both had broad support in the room, and will be sent to the list
for objections, but otherwise will be placed on track for processing
before London.
*x-<vendor>-msgid and friends
*

There was discussion of 63bit number vs string, and the consensus in the
room was that opaque blob string is best, with the standard specifying a
minimum length that clients must support, and a security considerations
section suggesting that both ends sanity-check lengths, but not
specifying a maximum.
These will also be addressed after the current set of documents
are added.
*IMAP4rev2
*

Alexey will spend some time on this, but not today!

*Co-Chair*

Last but not least, Jiankang Yao <[email-masked]> has agreed to come
onboard as a co-chair for this working group.  Thanks Jiankang.
*
*
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Stan Kalisch <[email-masked]>
Date: Thu, 16 Nov 2017 17:06:52 -0500

Hi,

> On Nov 15, 2017, at 3:30 AM, Bron Gondwana <[email-masked]> wrote:
> 
> There is an open question for this one:
> 
> Ned Freed objected to supporting :fcc for the REJECT action because it allows the sieve server to "lie" about whether it's keeping a copy of the message.  There was debate about whether we should stop people lying at this level, especially since a mail flow could take a copy of every single email before it reached sieve.

I haven't been able to watch any video of the meeting yet, but would it be fair to say the main points of this debate were laid out in this thread on the Sieve mailing list earlier this year?

https://www.ietf.org/mail-archive/web/sieve/current/msg05362.html

Thanks,
Stan