On Tue Mar 11 07:50:42 2008, Timo Sirainen wrote:
> A client sends two commands pipelined:
>
> 1 fetch 1 flags
> 2 expunge
>
> Assuming message 2 is marked \Deleted, is server allowed to reply
> with:
>
> * 1 fetch flags ()
> * 2 expunge
> 1 ok
> 2 ok
>
>
No.
> Or must it always be:
>
> * 1 fetch flags ()
> 1 ok
> * 2 expunge
> 2 ok
>
>
Yes.
> I think the important part of RFC 3501 is:
>
> "because servers are prohibited from sending EXPUNGE responses
> while any
> of those commands are in progress."
>
> Does "in progress" stop only after tagged reply is sent, or after
> all
> relevant untagged replies have been sent?
Firstly, yes, in progress only stops after the completion response is
sent.
Secondly, whenever there's a difference in the outcome depending on
the order the commands are processed in, the server has to resolve
this by sequentially processing the commands.
This can be shown more clearly if instead of a fetch, the client
pipelines a UID FETCH+EXPUNGE sequence. Here, the server is allowed
to send the EXPUNGE during the UID FETCH, but it MUST do so after the
FETCH response, at least, in order to avoid the ordering being
significant - a strict reading of the RFC states that the EXPUNGE
response would occur after the tagged completion response of the UID
FETCH, in fact.
The relevant text is in Section 5.5, second paragraph:
The exception is if an ambiguity would result because of a command
that would affect the results of other commands. Clients MUST NOT
send multiple commands without waiting if an ambiguity would
result.
If the server detects a possible ambiguity, it MUST execute
commands
to completion in the order given by the client.
You'll note that clients are banned from sending this, too. Arguably
there's an escape clause there, since you could say "but I don't
detect the ambiguity!", but I think the intent it pretty clear that
you should.
By far the simplest method of handling this case is to simply not
have multiple commands in progress, or if you do, limit it to certain
cases where there is no ambiguity, rather than attempting to detect
all possible ambiguities on the fly.
Dave.
--
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade