Mark Crispin <[EMAIL PROTECTED]> writes:
> On Tue, 24 Sep 2002, Simon Josefsson wrote:
>> > That is also impossible in IMAP. Review sections 5.5 and 7.4.1.
>> The sections seem to only discuss multiple commands from one client.
>> I was thinking of server initiated emptying of mailboxes, or multiple
>> concurrent clients where one of them empties the mailbox.
>
> Those sections also address that issue, but indirectly. See my answer to
> Larry Osterman's message for a more detailed answer.
Yes, I had not fully grasped 5.5 it seems. Thanks for educating me.
> SITUATION 1: server initiated emptying of mailboxes, or multiple
> concurrent clients where one of them empties the mailbox, and the server
> has NOT yet transmitted any untagged EXPUNGEs.
>
> The messages still exist, and will continue to exist until the untagged
> EXPUNGEs are transmitted. RFC 2180 offers NO as an option; however I
> contend (and empirical evidence has shown) that OK is what works best.
> RFC 2180 offers three ways that OK can happen:
> 1) not allow the mailbox to be emptied
> 2) allow it but keep a "ghost" copy behind
> 3) allow it and return a dummy (mostly NIL) representation.
>
> BAD is *NOT* a correct response in this situation, and I contend that NO
> is also an ill-advised choice.
I agree. (Although technically, RFC 2180 is not really an Internet
standard.)
> SITUATION 2: server initiated emptying of mailboxes, or multiple
> concurrent clients where one of them empties the mailbox, and the server
> has ALREADY transmitted the untagged EXPUNGEs to reduce the exists count
> to zero.
>
> An attempt by the client to access any message sequence number results in
> a BAD until such time as the server transmits an EXISTS with a non-zero
> value.
>
> OK or NO are *NOT* correct responses in this situation.
Would it improve the standard to make this more obvious? The text
that the argument is based on is located inside parentheses in a
comment inside the ABNF without saying how to handle the error or why
it is an error. An idea:
; * represents the largest number in use. In
; the case of message sequence numbers, it is
; the number of messages in a non-empty mailbox
; (it is an error to use message sequence numbers
; in an empty mailbox, and should result in a BAD
; response -- see section 5.5 and 7.4.1). In the case
; of unique identifiers, it is the unique identifier
; of the last message in the mailbox or, if the
; mailbox is empty, the UIDNEXT value.
