Subject: Re: [imapext] Last Call: <draft-ietf-imapmove-command-02.txt> (The IMAP Move Extension) to Proposed Standard,

From: Michael M Slusarz <[email-masked]>
Date: Wed, 14 Nov 2012 00:50:44 -0700

Scanning the draft text, this was the one section that stuck out to me:

4.4. RFC 5162, QRESYNC

    The QRESYNC extension [RFC5162] directs the server to send VANISHED
    rather than EXPUNGE in response to the UID EXPUNGE command.  The same
    requirement applies to the UID MOVE command.

My opinion: this is a slightly inaccurate representation of QRESYNC.   
QRESYNC only states that servers "SHOULD start sending VANISHED  
responses . . . instead of EXPUNGE responses." (RFC 5162 [1]).  See  
also RFC 5162 [3.5] (as a result of UID EXPUNGE command, "those  
messages that are removed are reported using a VANISHED response or  
EXPUNGE responses.").

The use of "directs" and "requirement" in draft section 4.4 implies  
that VANISHED messages MUST be sent.  At least that's the way I read  
this section the first several times scanning the document.  As a  
disconnected IMAP client author, this would be fantastic if true but,  
alas, that is not the case.

Complaints without suggestions are not very useful, so here's a  
possible rephrasing:

    The QRESYNC extension [RFC5162] advises that the server send VANISHED
    rather than EXPUNGE in response to the UID EXPUNGE command.  A  
QRESYNC enabled client
    MUST be prepared to handle both VANISHED and EXPUNGE responses to  
a UID MOVE command.

thanks,
michael

___________________________________
Michael Slusarz [[email-masked]]

---

From: Barry Leiba <[email-masked]>
Date: Wed, 14 Nov 2012 09:15:18 -0500

Good catch, Michael.  Let me suggest a slight variant of your suggestion:

OLD

>    requirement applies to the UID MOVE command.

NEW

> advice applies to MOVE, and a QRESYNC-enabled client
>    needs to handle both VANISHED and EXPUNGE responses to a UID MOVE
> command.

Barry

---

From: Ned Freed <[email-masked]>
Date: Wed, 14 Nov 2012 08:26:30 -0800 (PST)

> >    needs to handle both VANISHED and EXPUNGE responses to a UID MOVE

Except that's not correct either. RFC 5162 uses a SHOULD; that's requirements
language, not merely advice. In fact the current text is not that far off.

Instead of trying to come up with a way of rephrasing what RFC 5162 says,
how about we restate what it actually says?

   The QRESYNC extension [RFC5162] states that the server SHOULD send VANISHED
   rather than the EXPUNGE in response to the UID EXPUNGE command.
   The same requirement applies to MOVE, and a QRESYNC-enabled client
   needs to handle both VANISHED and EXPUNGE responses to a UID MOVE
   command.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Wed, 14 Nov 2012 12:04:50 -0500

>    needs to handle both VANISHED and EXPUNGE responses to a UID MOVE

Oui.  Parfait.

Barry

---

From: Michael M Slusarz <[email-masked]>
Date: Wed, 14 Nov 2012 10:12:23 -0700

>>    needs to handle both VANISHED and EXPUNGE responses to a UID MOVE

A clarity suggestion: we have the MOVE extension, the MOVE command,  
and the MOVE addition to the the UID command.  It would be useful to  
clarify that it is the MOVE extension being referred to in this context:

       The QRESYNC extension [RFC5162] states that the server SHOULD  
send VANISHED
       rather than the EXPUNGE in response to the UID EXPUNGE command.
       The same requirement applies to [the MOVE | this] extension,
       and a QRESYNC-enabled client needs to handle both VANISHED and  
EXPUNGE responses
       to a UID MOVE command.

michael

---

From: Ned Freed <[email-masked]>
Date: Wed, 14 Nov 2012 09:33:30 -0800 (PST)

> Oui.  Parfait.

Great. I've updated the doc with this text.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Wed, 14 Nov 2012 09:35:27 -0800 (PST)

>        and a QRESYNC-enabled client needs to handle both VANISHED and

We use "MOVE" as shorthand for the MOVE extension all over the place; I see
no reason to change this one occurence.

				Ned