MBOX-Line: From mrc at CAC.Washington.EDU  Wed May 23 23:13:11 2007
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:39 2018
Subject: [Imap-protocol] Re: FLAGS response
In-Reply-To: <1582938983.97731179982489618.JavaMail.root@dogfood.zimbra.com>
References: <1582938983.97731179982489618.JavaMail.root@dogfood.zimbra.com>
Message-ID: <alpine.OSX.0.99.0705232250240.10455@pangtzu.panda.com>

On Wed, 23 May 2007, Dan Karp wrote:
> If PERMANENTFLAGS included "\*" and I do a "A001 STORE 1 +FLAGS 
> (NEWFLAG)", is the server obliged to send back a new untagged FLAGS 
> response before the unsolicited FETCH?

Yes

> If someone else does the STORE which added the NEWFLAG in my selected 
> mailbox, is the server required to send me a new untagged FLAGS 
> response?

Yes.

> If the answer to either of these is "yes", can someone point me to the 
> section of RFC 3501 that I should have read more closely?

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.

There is no other interpretation that gives a purpose or point for the 
untagged FLAGS response to exist.  Nothing in IMAP is there out of 
caprice; there is always a reason even if that reason is subtle.

This is one of the reasons why I did NOT want to say "such-and-such 
response occurs as a result of such-and-such command" (I was forced to do 
so against my wishes); I knew that people would falsely presume that 
stating such implies that such-and-such response only occurs as a result 
of such-and-such command.  The fact that the text says "this response 
occurs as a result of that command" does NOT mean that the response can 
not occur at another time.

The unsolicited data model of IMAP requires that ANY response can occur as 
the result of ANY command.  Clients MUST be prepared to accept an untagged 
SEARCH even if you are not doing a SEARCH command, untagged LIST even if 
you are not doing a LIST command, etc.

Understanding the unsolicited data model of IMAP is key to understanding 
IMAP itself.  IMAP is two protocols; a command/response protocol that is 
client initiated (section 6, and tagged 7.1.1 - 7.1.3), and a 
data-transmission protocol that is server initiated (section 7).

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

