Hi,
after the recent discussion on being not allowed to send unsolicited EXPUNGE
messages while FETCH,STORE or SEARCH commands are in progress or when no
command is in progress, I really got baffled thinking about this issue.
I have read 5.5 of the IMAP4-RFC and RFC2180 in addition to that, which I
take as the common way of looking at it. I see these rules are mainly
invented because of the possibility a client sends some commands without
waiting for any result, which needs the message sequence numbers "in order",
and I can accept that.
But I wonder how this (not uncommon) situation could be resolved:
Client A (not supporting/using IDLE command) selects mailbox FOO with 10
msgs and is waiting, maybe issuiung a NOOP every 29 minutes.
Client B selects mailbox FOO, and expunges messages 1-5.
Now the server has NO WAY to inform Client A about this situation, until it
sends any command other than FETCH/SEARCH/STORE. Depending on the client,
the EXPUNGE information may never get through.
So - I see the explanation in RFC2180, and given I do not want to bother
with ghost messages or absurdly complicated server states to keep track of
"imaginary" sequence numbers for this client, what can a server to
conforming to the specs?
My answer would be the following: I'd do the expunge immediately to the
message store. I then postpone the expunge messages as required by the specs
for Client A. Any request to FETCH/STORE/SEARCH would be answered with a
tagged NO response then (as described in RFC2180 4.1.2) until the EXPUNGE
could be delivered.
Is this (Scenario A) ok?
Furthermore, this would mean that if a client is issuing multiple commands
like the following without waiting:
A FETCH 1 (FULL)
<--------messages are expunged by another session
B FETCH 2 (FULL)
C FETCH 3 (FULL)
The server would answer:
* FETCH 1 (.....)
A FETCH OK
B NO FETCH failed (expunge pending)
C NO FETCH failed (expunge pending)
It would mean that a Client SHOULD treat a NO as an indication to send a
NOOP and try again; hopefully without giving an Error to the User(?).
Is this (Scenario B) ok too?
This is just a clarification for me, thanks for any help.
Christof
--
-----------------------------------------------------------------
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/imap-list.html
-----------------------------------------------------------------
