72 lines
2.6 KiB
Plaintext
72 lines
2.6 KiB
Plaintext
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.
|
|
|