MBOX-Line: From dkarp at zimbra.com  Thu May 24 00:08:09 2007
To: imap-protocol@u.washington.edu
From: Dan Karp <dkarp@zimbra.com>
Date: Fri Jun  8 12:34:39 2018
Subject: [Imap-protocol] Re: FLAGS response
In-Reply-To: <alpine.OSX.0.99.0705232250240.10455@pangtzu.panda.com>
Message-ID: <1738689467.102591179990489448.JavaMail.root@dogfood.zimbra.com>

> The FLAGS response lists the flags which are applicable to a mailbox. 
> A FETCH response that contains flags can only contain flags which are 
> applicable to the mailbox.  Therefore, if a FETCH response desires to
> contain a flag which is not in the current FLAGS response, a new FLAGS
> response must be issued that lists that flag.

It certainly makes sense that changes in FLAGS elicit unsolicited
responses in much the same way as changes in EXISTS and RECENT do.
Along those lines, should the server be sending untagged notifications
with the appropriate response codes when the next message UID [UIDNEXT]
and lowest-sequenced unseen message [UNSEEN] change?

> I think that it is alright (from a protocol point of view) to remove
> unused flags in a new session (but NOT during a session!).  That's one
> reason why flags are announced; to show what is there.
> 
> Put another way: a subsequent FLAGS response in a session should only add
> flags at the end of the list, but a FLAGS response in a new session can
> reorder/remove flags.

Will any clients fail if either of these two suggestions are not followed
by the server?  They both seem reasonable, but there doesn't appear to be
anything in RFC 3501 that requires that servers behave in that manner.

