On Thu, 26 Sep 2002 09:15:34 -0700, Larry Osterman wrote:
> On the other hand, it is NOT a protocol
> error for the following to occur:
> S: * 2 EXISTS
> S: tag OK
> C: tag FETCH 2
> S: * 2 EXPUNGE
> S: * FETCH 2 (NIL)
> S: tag OK Fetch completed but message deleted.
Actually, that scenario is invalid. The server isn't allowed to send the
untagged EXPUNGE in that situation. Valid scenarios which illustrate your
point (albeit not as strongly):
S: * 2 EXISTS
S: tag OK
C: tag FETCH 2 RFC822.HEADER
S: * 2 FETCH (RFC822.HEADER NIL)
S: tag OK Fetch completed but message deleted.
C: tag NOOP
S: * 2 EXPUNGE
S: tag OK
Here a dummy message was returned for message 2 cause the untagged EXPUNGE had
to be deferred until the client did a command which permits the transmission
of untagged EXPUNGE. Personally, I think that it is better, until the
untagged EXPUNGE is sent, to retain a message ghosts that has all the message
data.
Here's another scenario that is closer to your point:
S: * 2 EXISTS
S: tag OK
C: tag FETCH 2 UID
S: * 2 FETCH (UID 23)
S: tag OK
C: tag UID FETCH 23 RFC822.HEADER
S: * 2 FETCH (UID 23 RFC822.HEADER NIL)
S: * 2 EXPUNGE
S: tag OK Fetch completed but message deleted.
Unlike FETCH, UID FETCH permits sending untagged EXPUNGE. However, the
untagged EXPUNGE can not be sent until *AFTER* the untagged FETCH, since
otherwise the "2" in the untagged FETCH would be invalid.
Alternatively, the server could do the same scenario without sending any
untagged FETCH:
S: * 2 EXISTS
S: tag OK
C: tag FETCH 2 UID
S: * 2 FETCH (UID 23)
S: tag OK
C: tag UID FETCH 23 RFC822.HEADER
S: * 2 EXPUNGE
S: tag OK Fetch completed but message deleted.
Note that scenarios such as the latter two can never happen with message
sequence numbers.
