On Wed, 25 Sep 2002 07:39:40 -0700, Vladimir A. Butenko wrote:
> If FETCH 2:2 is legal for a mailbox that contains one message, I do not
> understand why Fetch 1:1 is illegal in an empty mailbox, or why FETCH 1:* is
> illegal in an empty mailbox.
FETCH 2:2 is *NOT* legal for a mailbox that contains one message. So your
argument falls apart:
x select foo
* 1 EXISTS
* 1 RECENT
* OK [UIDVALIDITY 1032968134] UID validity status
* OK [UIDNEXT 2] Predicted next UID
* FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
* OK [PERMANENTFLAGS ()] Permanent flags
* OK [UNSEEN 1] first unseen message in /u/mrc/foo
x OK [READ-ONLY] SELECT completed
y fetch 2:2 flags
y BAD Bogus sequence in FETCH
FETCH 2:2 is legal for a message that contains two messages. It is equivalent
to FETCH 2.
On the other hand...
UID FETCH 2:2 is legal for all mailboxes.
UID FETCH 1:1 is legal for all mailboxes.
UID FETCH 1:* is legal for all mailboxes.
Do you see the pattern?
Message sequence numbers must be greater than or equal to 1, and less than
2^32. Furthermore, they must be less than or equal to the number of messages
in the mailbox. Thus, if the mailbox is empty, no message sequence numbers
are valid, and a FETCH can not be done.
UIDs must be greater than or equal to 1, and less than 2^32. All UID values
are valid, even if the mailbox is empty. Thus, even if the mailbox is empty,
a UID FETCH can be done.
> Since the 17th century the number zero is
> considered to be a regular plain number, LEGAL, not much different from
> numbers 1 and 2 - at least, in Europe.
That is interesting, but not particularly relevant to this discussion. IMAP
defines both message sequence numbers and UIDs as non-zero unsigned values.
Even mathematics has domains in which zero is not permitted, the most obvious
being as a divisor.
> So zzz FETCH 1:1 and FETCH 1:* in any empty mailbox should just return zzz
> OK.
IMAP has not done so for 17 years. This has been a useful debugging feature.
It would declare current servers to be non-compliant.
I see no benefit in doing this.
> Now, there is a scenario that is comletely legal from the current IMAP
> standard point of view, and still it empties the mailbox when the client has
> no way to change its mind, and it has ALREADY started the FETCH command:
>
> C: .....
> S: 1 EXISTS
> S: aaaa OK
> C: bbbb FETCH * (FLAGS BODY[HEADER.FIELDS ({4}+
> * 1 EXPUNGE
> + proceed
> DATE
> FROM)])
This scenario is prohibited in section 7.4.1.
> As it can be seen in this sample and a similar sample for the SEARCH (though
> not for STORE command), the client has started to send a legal FETCH command
> that became "illegal" (this is the meaning of the "BAD" response) while it
> was being sent.
Of course. That is why we have that prohibition in section 7.4.1.
> I seriously doubt that many clients do process untagged responses that are
> send together with continuation requests. Because of the troubles this
> "feature" provides, I'd suggest its removal from the IMAP standard (i.e. no
> untagged responses can be sent with continuation requests).
Every application built with c-client handles this. That's a lot of clients
(don't forget that PHP uses c-client).
Among other things, this facility is used by IDLE.
