On Thu, May 31, 2012 at 10:20:12AM -0400, Cyrus Daboo wrote: > - §2: what is the problem with sequence MOVE and EXPUNGE? For what > it is worth Mulberry has always preferred sequence over uids when > online (it uses UID commands when doing disconnected play back). > That said, mapping to uids is no big deal (and should not be a big > deal for any other client that might use sequence in normal > operation).
Yeah, I don't see a problem either. I see that my implementation supports both just fine. Sequence based moves are handy when you're fiddling around by hand, if nothing else. > - §3, ¶4: states that \Deleted must not be set in the target > mailbox. But what if the messages being moved already had \Deleted > set prior to the move? Shouldn't we just state that the > flag/keywords prior to the move must be set on the messages in the > target mailbox? That's a really good catch. Agree with your interpretation absolutely. Should be copied with exactly the same flags. The only potentially sticking point here is awful things like non-shared \Seen state. Cyrus (the IMAP server, yay for namespaces) has per-user seen state. The actual behaviour at the moment would be that the owners' \Seen state always gets copied, nobody else's does. It might also make sense to copy your OWN \Seen state if you are not the owner. But basically it's fluff wording. The final result shall be as if COPY + STORE + UID EXPUNGE had happened in precisely that order. In other words "the messages in the destination mailbox must not show any state that would not have happened if COPY had been used instead of MOVE". The only difference between COPY and MOVE is the eventual state of the source folder. > - §3: As already mentioned, EXPUNGE responses need to be present. > Might be worth pointing out that there could be a * EXPUNGE for a > message not being moved, but which got expunged in another session. > Actually, more complicated is the case where a message being moved > was expunged in another session - presumably that message is not > moved? Yet it would get reported in a * EXPUNGE, but not be part of > the COPYUID set. There's no other choice here. The only rule is that the STORE and UID EXPUNGE only happen to the messages which were successfully copied. Which leads to this interesting little thing. Two sessions, S1 and S2. S1: SELECT AFolder S2: SELECT AFolder S1: STORE 3 +Flags \Deleted S2: MOVE 1:5 OtherFolder S1: EXPUNGE S1 will see 5 expunges, including the one it was expecting. S2 will see the 5 expunged it was expecting as well - but will store the message as \Deleted in OtherFolder. I wonder indeed if that was an intention in the spec, that \Deleted gets explicitly CLEARED by the MOVE operation. Which is kind of surprising actually. Hmm, I wonder. Yep - COPY copies messages with \Deleted and they have \Deleted in the destination folder as well. OK - I take it back, this isn't surprising. This is the natural way it should be. Yes, S1's expunge missed the mark - but that's the unfortunately downside of two-stage EXPUNGE. There is literally no way to avoid this... whenever you do a COPY or MOVE you need to check your destination messages to make sure you didn't pick up something half way through being deleted. Even S1 doing UID EXPUNGE wouldn't avoid this. BUT - even if there are other \Deleted messages in the folder, the "EXPUNGE" part of MOVE never deletes them. It's a "UID EXPUNGE" on just the UIDs which were actually affected by this message. Which also gives it the dubious honour of including "ERASE". "ERASE" of course being just the "STORE" and "UID EXPUNGE" parts of the above command combined together atomically(ish) such that you don't get the race condition listed above. In fact it would be atomic in Cyrus. I think I'm going to implement this one now in fact, we would use it immediately. Er, I'm going to write a separate email for it too. > - §4: whilst no one may implement it, there still ought to be a > reference to the interaction with ANNOTATE. ANNOTATE §4.6 has > detailed text on the interaction with COPY and something similar is > needed for MOVE. "As Above" ;) Literally, it should be enough to say "ANNOTATions are treated exactly as specified for COPY and for EXPUNGE". _______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
