On Thu, 26 Sep 2002 08:47:08 -0700 (PDT)
Mark Crispin <[EMAIL PROTECTED]> wrote:
> 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.
I'm not talking about "fixing" anything here. I'm talking about making the
standard a definitive document. If the "*" thing is allowed in the
seq_subset
specs, it can be used, and it will be used by someone, and that author has
all rights to do so - even if you think that it is useless or risky (and I'd
agree with your judgement here). But this case should be specified/noted in
the docs.
Please note that in my attempt to use formal specifications for that part of
IMAP I used the word "current number of messages". The word "current" is
important here. The protocol should more explicitly specify the following
thing:
the "current number of messages in the mailbox" is a fixed number, delivered
via the EXISTS response when the mailbox is selected. The current number
changes ONLY when (AFTER) the client receives the EXPUNGE or EXISTS response
from the server.
This actually implies that the server must maintain "ghosts" for all those
messages that it has deleted (by request of some other client), but for
which it has not delivered the EXPUNGE response to this client. I'd also
vote for the clause in the specs that the server must NOT show a new message
(
in the FETCH, SEARCH responses) before it sends the EXISTS response to the
client.
Yes, this is probably what you think every sever should do. That's what I
think, too. That's what probably most of the servers really do. That's what
probably the protocol implies - but it is not specified explicitly, as it
should be specified.
> > 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.
Unfortunately, all info I have is the RFC2060 standard/draft. And it has
only one section about this situation:
This response is prefixed with the token "+".
Note: If, instead, the server detected an error in the
command, it sends a BAD completion response with tag
matching the command (as described below) to reject the
command and prevent the client from sending any more of the
command.
It is also possible for the server to send a completion
response for some other command (if multiple commands are
in progress), or untagged data. In either case, the
command continuation request is still pending; the client
takes the appropriate action for the response, and reads
another response from the server. In all cases, the client
MUST send a complete command (including receiving all
command continuation request responses and command
continuations for the command) before initiating a new
command.
See the "the client takes the appropriate action for the response, and reads
another response from the server". I have to conclude that because the
client is required to read another request after getting untagged data, that
untagged data cannot be sent AFTER the "+" request, since after the "+"
request the client cannot sit and wait for/read another response from the
server - the server may not send anything.
> 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.
responses sent BEFORE the "+" request are responses sent "when no command is
in progress". Responses sent AFTER the "+" request cannot be considered as
responses sent "when no command is in progress" - the client might have
already sent the complete command, and those responses cannot be considered
as "sent with the continutation request", since for the server the
"continuation" phase should be considered complete as soon as it sends "+".
Example (illegal):
C: aaa CREATE {10}
S: * EXPUNGE 20
S: + proceed
C: ZUZUZUZUZU
C:
S: aaa OK created
is illegal (* Expunge cannot be sent with the continuation request, as at
this
time no command is in progress).
C: aaa CREATE {10}
S: + proceed
C: ZUZUZUZUZU
C:
S: * EXPUNGE 20
S: aaa OK created
is, definitely, legal - but since there is no additional synching between
the server and client, the same transaction can be presented as:
C: aaa CREATE {10}
S: + proceed
S: * EXPUNGE 20
C: ZUZUZUZUZU
C:
S: aaa OK created
And it must be legal, too - and it is the case when the untagged response is
sent AFTER the continuation request. It definitely has a different meaning.
It can and should be called an untagged response sent WHEN A COMMAND IS IN
PROGRESS, so it cannot be called as a response "sent with the continuation
request". So, there can be no such thing as "sent with continuation request,
but after it" - only BEFORE it. Anything after "+" cannot be considered as
sent "with" it.
> But it isn't required. IDLE, by its nature, requires a client to be
> asynchronous.
Not exactly. If a client is truly asynchronous, it would not need any IDLE
or NOOP command. It would just sit idle, being prepared to whatever status
update the server sends to it (though it won't be able to get the EXPUNGE
things). The IDLE command allows the client to be designed as a synchronous
one - it sends the NOOP, gets the continuation request (that it ignores),
and then it just sits and waits for any untagged response - all in the
synchronous manner. Then, when it's time to do some other work, it sends
"DONE", and again, synchronously reads all remaining responses from the
server till it gets the tagged OK response. No real aynch processing here -
i.e. everything can be done within other thread using synch i/o calls only.
So, IDLE is a very special case. Untagged responses there are not sent WITH
the continuation request (which is used just to confirm that the server has
received the IDLE command). More if there were sent "with", they could not
include EXPUNGE - as when the continuation request is sent, there is still
no command in progress.
The untagged responses in the IDLE state are those "sent unilaterally"
responses that any client should be ready to get at any time( according to
the protocol specs - " A client MUST be prepared to accept any server
response at all times"), but in reality few clients can do this (they must
be truly asynch to do this), and in order to provide what initial IMAP specs
wanted the IDLE thing was introduced.
This also one of the problems of the protocol specs: it says that phrase ("A
client MUST be prepared to accept any server response at all times"), but in
reality, most existing clients are synch ones, so the protocol has to
include this phrase: "Server implementations that send such responses MUST
deal with flow control considerations.". How can they? Can they assume that
a channel can consume one untagged * FETCH 123 FLAGS (), but it will block
if they send 20 of those? If the clients would really follow the spec, so
they can accept all server untagged responses at any time, there whould be
no flow-control clause in the protocol.
Because most clients are not capable of accepting any server response at any
time, most servers do not send untagged responses when there is no command
in progress. And most servers just provide the IDLE extension to deal with
those synch-ed clients w/o forcing them to send NOOPs every second.
I think this current situation should also be addressed. Using any method -
by means of the new "ENABLE UNTAGGED" command that would tell the server
that it can send untagged responses to this client at any time, or with any
other meathod, but currently the situation is, hmm, inconsistent.
> -- Mark --
>
Sincerely,
Vladimir
