Subject: Re: a valid non-waiting command sequence or not

From: Jutta Degener <[email-masked]>
Date: Thu, 15 Jan 1998 04:24:13 -0500

Larry Osterman (Exchange) wrote:
> I don't believe that it is legal for the server to send untagged
> expunges between receiving a command and its continuation.

But wouldn't that prevent a client from sending any synchronized
literal while a command allowing EXPUNGE responses is pending?

Consider a client that checks on a second mailbox's status while
an EXPUNGE is in progress.
	..
	C: a001 EXPUNGE
	S: * EXPUNGE 100000
	S: * EXPUNGE 99999
	S: * EXPUNGE 99998
	C: a002 STATUS {23}
	S: + Go ahead.
	C: bottles not on the wall (UNSEEN)

Whether or not the "* EXPUNGE 99998" line arrives before, or after,
the client transmits its new request is entirely accidental.  The
conversation could just as well have been reported as:
        ..
	C: a001 EXPUNGE
	S: * EXPUNGE 100000
	S: * EXPUNGE 99999
	C: a002 STATUS {23}
	S: * EXPUNGE 99998
	S: + Go ahead.
	C: bottles not on the wall (UNSEEN)

> Otherwise how could it handle:
> 
> C:      A001 FETCH 1:15 BODY[HEADER.FIELDS ({7}
> S:      + Ok to send
> C:      Subject)]
> 
> In this case, the server cannot send expunge responses at all, because
> the client is sending a FETCH command.

Here's another way of looking at your FETCH case:

- If the server hasn't yet recognized the command, it cannot
  send * EXPUNGE responses because no command is in progress.

- After the server has recognized the command, it cannot
  send * EXPUNGE responses because it's in the middle of a FETCH.

As long as you agree to either recognize the command or not (there's
no state of limbo where you're processing a command, but you don't
know what it is), you don't really need to worry about synchronizing
literals and half-parsed commands---the existing rules suffice.

> The only way the server could
> send EXPUNGE responses is if it has already partially parsed the
> command, and I don't believe it is safe for a server to interpret
> responses based on a partial parse of the command because it would mean
> that the server might start responding with valid responses to a
> syntactically incorrect command.

If the valid response is untagged, I don't think you can avoid
that while clients are allowed to run commands in parallel.

Jutta Degener
<[email-masked]>