On 05/31/12 10:42, Bron Gondwana wrote: > If you want VANISHED responses you can ENABLE QRESYNC. I see no reason > not to spit regular EXPUNGED responses otherwise. The clients that know > how to handle VANISHED can just turn on QRESYNC, the others won't have to > deal with it.
As a client writer, I'd expect the UID MOVE to return either explicit
EXPUNGE or explicit VANISHED messages. I do see that omitting that leads
to slightly bigger bandwidth usage (easily mitigated by VANISHED), but
such a behavior would surprise me, based on the way how the rest of the
IMAP works.
In my opinion, section 3 of the draft shall read:
3. UID MOVE Command
***** I'm adding explicit info about the responses here *****
Arguments: message set, mailbox name
Data: untagged responses: EXPUNGE or VANISHED
Result: OK - at least one message has been moved
NO - none of the messages were moved
BAD - command unknown or arguments invalid
***** The following remains the same from the 01 draft *****
The UID MOVE command takes two arguments: a set of UIDs and a named
mailbox. It moves each message indicated by UID set to the named mailbox.
The UID MOVE command is the same as a sequence of UID COPY, UID STORE
+FLAGS \DELETED and UID EXPUNGE, with two added requirements:
First, each message SHOULD either be moved or unaffected. The server
SHOULD NOT leave a message in neither or both mailboxes afterwards (even
if the server returns a tagged NO response).
Second, the messages MUST NOT have the \Deleted flag set in the target
mailbox.
***** And here are some additions ******
If at least one message was successfully moved to the target mailbox,
the command MUST report success with a tagged OK response. If none of
the messages could be moved, the server MUST respond with a tagged NO.
Clients are informed about the fate of the individual messages through
regular untagged EXPUNGE responses, as defined in RFC 3501. In case the
current session has enabled the QRESYNC extension, untagged VANISHED
shall be send instead of the EXPUNGE responses.
***** The example is also modified with EXPUNGEs and the number of
messages is reduced *******
An example:
C: a UID MOVE 42:45 forble
S: * 15 EXPUNGE
S: * 15 EXPUNGE
S: * 15 EXPUNGE
S: * 15 EXPUNGE
S: a OK [COPYUID 432432 1202:1205] Done
****** End ******
I see a few issues to be discussed, though:
- There's a requirement that a message in the target mailbox must not
have the \Deleted flag. What is supposed to happen when I UID MOVE a
message which was already marked as \Deleted before?
- Sending the untagged EXPUNGE/VANISHED and only after them the COPYUID
might be troublesome for some clients -- for example, my code will react
to EXPUNGE by removing the cached data for that message from the on-disk
cache. When the COPYUID arrives, the data is already gone. (My code
actually ignores COPYUID for now anyway, but that's not relevant here.)
- Postponing of the untagged EXPUNGE/VANISHED until after the tagged OK
is probably a bad idea, so what about a special "VANISHED (MOVED)" which
would hint the client that the data shall not be purged immediately?
- Section 4.3 shall probably say that servers supporting the UIDPLUS
extension SHOULD include the COPYUID response code in the tagged OK, but
that means that the introduction in section 4 shall not claim that there
are no requirements in that section.
Cheers,
Jan
--
Trojita, a fast e-mail client -- http://trojita.flaska.net/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
