Thank you for your comments. Even if I don't always agree, they are very
valuable since they indicate issues which need to be addressed.
For most of your issues regarding sequences, watch for draft 19. The text has
been completely rewritten, and should be a lot better. I should be posting it
in the next day or two.
On Thu, 26 Sep 2002 08:38:28 -0700, Vladimir A. Butenko wrote:
> a) "1,1,1,1,1" is not an error and is the same as "1"
> b) "1,3,2" is not an error and is the same as "1,2,3"
> c) "1:5,2:6" is not an error and is the same as "1:6"
Correct, and this is now explicit in the draft 19 that I am preparing.
> Our servers allow FETCH 2:2 in a mailbox that has zero or 1 message, and I
> will say that they are compliant with the current version of the RFC.
I would counter with the following:
A client which sents FETCH 2:2 (as opposed to UID FETCH 2:2) in a mailbox that
has zero or 1 message is NOT compliant with IMAP or any version of the RFC.
Your server, on the other hand, IS compliant, because the RFC does NOT
stipulate "correct" handling of non-compliant client commands. FETCH 2:2
could be a secret administrative command in your server to get superuser
power, and your server would still be compliant.
> C: .....
> S: 1 EXISTS
> S: aaaa OK
> C: bbbb FETCH * (FLAGS BODY[HEADER.FIELDS ({4}+
> * 2 EXISTS
> + proceed
> DATE
> FROM)])
If a judgement most be made, I would contend that since the command-ending
CRLF was sent AFTER the EXISTS arrived, the value of * would be 2. But I
wouldn't be at all surprised if many servers treated it as 1, or if it was
indeterminate due to timing.
Furthermore, it is not clear to me that it really is a problem. "*" basically
means "last message" at a time chosen by the server in the processing of a
command. This is intrinsically nebulous.
Fortunately, the situation is easily avoided by the client; a client never
needs to use a message sequence number of *. * exists primarily for UIDs, and
in that case the nebulous nature is desirable.
So, I don't think that this needs to be fixed.
> This implies ("command continuation request is still pending") that untagged
> data can only be sent BEFORE the continuation request line (the + line).
> BTW, it means that the word "before" must be used here, not the word "with".
I don't see how you reached that conclusion. A command continuation request
is pending until the command continuation is sent from the client. Untagged
data can be sent before or after the + line.
Before is probably more useful, since a synchronous client won't read untagged
data sent after the + line until after it has sent the continuation request.
But it isn't required. IDLE, by its nature, requires a client to be
asynchronous.
-- Mark --
