Expunges

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

Or must it always be:

* 1 fetch flags ()
1 ok
* 2 expunge
2 ok

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?

_______________________________________________
Imap-protocol mailing list
Imap-protocolu.washington.edu
https://mailman1.u.washington.edu/mailman/listin
fo/imap-protocol

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:davecridland.net - xmpp:dwdjabber.org
  -
acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Imap-protocol mailing list
Imap-protocolu.washington.edu
https://mailman1.u.washington.edu/mailman/listin
fo/imap-protocol

On Tue, 2008-03-11 at 09:16 +0000, Dave Cridland wrote:
> > 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.

Yes, I understand the ambiguity problems, and the commands
are processed
sequentially in my first example, so it shouldn't cause any
actual
problems. The only difference was when the final tagged
reply for FETCH
was sent.

I had changed Dovecot to work like:

1. Process all commands in input buffer, send their replies
and finally
add them to "sync queue" (EXPUNGE doesn't send
anything here yet)
2. Perform mailbox synchronization, sending untagged replies
for changes
(EXPUNGEs are sent here)
3. Send tagged replies to commands in sync queue.

But my imaptest started to complain about EXPUNGEs being
received while
FETCHes were being processed, so I was wondering if I should
again
change Dovecot or imaptest or both.. 

_______________________________________________
Imap-protocol mailing list
Imap-protocolu.washington.edu
https://mailman1.u.washington.edu/mailman/listin
fo/imap-protocol