MBOX-Line: From MRC at CAC.Washington.EDU  Wed Jan  9 20:21:07 2008
To: imap-protocol@u.washington.edu
From: Mark Crispin <MRC@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:41 2018
Subject: [Imap-protocol] Question on FETCH example in RFC3501
In-Reply-To: <b6f3249e0801092004x584dac51t2156511e43b7a7d6@mail.gmail.com>
References: <b6f3249e0801091938m12cbccd6j4fff9f406cf0fee1@mail.gmail.com>
	<alpine.WNT.1.00.0801091945320.3080@Tomobiki-Cho.CAC.Washignton.EDU>
	<b6f3249e0801092004x584dac51t2156511e43b7a7d6@mail.gmail.com>
Message-ID: <alpine.WNT.1.00.0801092005220.3080@Tomobiki-Cho.CAC.Washignton.EDU>

On Thu, 10 Jan 2008, Liam Clarke wrote:
> Thanks for that - my vague fear is that a poorly behaved server could
> mix responses to one request with responses for another

It all depends upon what you mean by this.

A server can not intertwine one response with another; that is, given 
responses

* 12 FOO BAR ZAP
* 13 GOLLY GEE WOW

A server can not send

* 12 FOO * 13 GOLLY GEE WOW
BAR ZAP

However, a server most definitely MAY send ANY untagged response to ANY 
command.  A client MUST NOT assume that (for example) if it is sending a 
SEARCH command that it will not receive a FETCH command.

More to the point: a client MUST NOT be modal in its untagged response 
processing based upon what command it is sending.

For example, the following is the WRONG way to implement SEARCH:
 	send a SEARCH command
 	read an untagged SEARCH response and use it
 	read the tagged OK/NO/BAD response

The following is the RIGHT way to implement SEARCH:
 	erase "list of searched messages"
 	send a SEARCH command
 	read and process some number of untagged responses
 	read the tagged OK/NO/BAD response
 	use the "list of searched messages"
with the following untagged response processor:
 	if response is ... then ...
 	else if response is SEARCH then
 		add value to the "list of searched messages"
 	else if response is ... then ...

Now...under normal circumstances in today's protocol, you will not get a 
SEARCH response except during a SEARCH command.  But you MUST NOT assume 
that, since maybe, just maybe, a protocol extension will cause SEARCH 
responses to happen at other times.

Most untagged responses can, and do, happen at any time in IMAP in real 
life: OK, NO, BAD, BYE, FLAGS, EXISTS, RECENT, EXPUNGE (some exceptions 
here), FETCH, CAPABILITY.

Only a few responses seem to be limited to specific commands in the base 
protocol: LIST, LSUB, SEARCH, STATUS.  But this can change at any time, so 
don't assume that it is so limited.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

