Subject: [imapext] Additional text about interaction between MOVE and QRESYNC

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Nov 2012 17:04:41 +0000

I've decided to implement MOVE in Isode's server and I think something 
like the following should be added to section 4.4. While this can be 
deducted from the fact that MOVE is sort of COPY+STORE+EXPUNGE, RFC 5162 
explicitly lists all commands affected by it. So I propose adding:

    If the server is capable of storing modification sequences for the
    selected mailbox, it MUST increment the per-mailbox mod-sequence if
    at least one message was permanently moved due to the execution of
    the MOVE/UID MOVE command.  For each permanently removed message,
    the server MUST remember the incremented mod-sequence and corresponding
    UID.  If at least one message got moved, the server MUST send the
    updated per-mailbox modification sequence using the HIGHESTMODSEQ
    response code (defined in [RFC4551]) in the tagged OK response.

    When a message is moved to a target mailbox, if the server is capable
    of storing modification sequences for the mailbox, the server MUST
    generate a new modification sequence that is higher than the highest
    modification sequence of all messages in the mailbox and assigns it
    to the moved message.

And add RFC 4551 to references (Informative is Ok, but Normative would 
do as well).
I think this also makes RFC 5162 Normative.

---

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

>     modification sequence of all messages in the mailbox and assigns it

This addition is being proposed pretty late in the game. OTOH, it's not
actually changing anything, only stating some requirements explicitly rather
than leaving them to implementors to work out.

I'm therefore inclined to add this text, modulo a couple of editorial tweaks.

Comments ASAP please.

> And add RFC 4551 to references (Informative is Ok, but Normative would

It's being used as a source of a definition used in a requirement. I think
that makes it normative.

> I think this also makes RFC 5162 Normative.

That's actually a little less clear to me, but I'm inclined to go along with
it.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Wed, 28 Nov 2012 12:42:19 -0500

> than leaving them to implementors to work out.
...
> Comments ASAP please.

Same analysis as yours.  Given that this comes directly from
implementation experience, I think it's valuable to add it.  Given
that it's a clarification, not any protocol change, I think it's OK to
add it now without going back through any process.

Barry, as participant

---

From: Timo Sirainen <[email-masked]>
Date: Wed, 28 Nov 2012 22:43:34 +0200

On 28.11.2012, at 19.04, Alexey Melnikov wrote:

> I've decided to implement MOVE in Isode's server and I think something like the following should be added to section 4.4. While this can be deducted from the fact that MOVE is sort of COPY+STORE+EXPUNGE, RFC 5162 explicitly lists all commands affected by it. So I propose adding:
> 

Hmm. I'm not sure if it MUST be sent in the tagged OK response. Untagged OK response would work as well. In some cases the resp-text in tagged OK might be something else (like in a partial failure).

---

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

> Hmm. I'm not sure if it MUST be sent in the tagged OK response. Untagged OK
> response would work as well. In some cases the resp-text in tagged OK might be
> something else (like in a partial failure).

RFC 4551 section 3.1.1 specifically says "OK untagged response". So I think
this is simply wrong.

Shall I drop "tagged" or change it to "untagged"?

				Ned

---

From: Timo Sirainen <[email-masked]>
Date: Thu, 29 Nov 2012 00:32:46 +0200

> RFC 4551 section 3.1.1 specifically says "OK untagged response". So I think

It talks about it as a reply to SELECT/EXAMINE commands. RFC 5162 talks about it being used in tagged replies to other commands. So returning HIGHESTMODSEQ in the tagged reply is the common case, but I think it's just as valid to send it as untagged just before the tagged reply.

> Shall I drop "tagged" or change it to "untagged"?

I'm not sure what's the cleanest way to say it. That or "tagged or untagged".

---

From: Ned Freed <[email-masked]>
Date: Wed, 28 Nov 2012 14:38:29 -0800 (PST)

> It talks about it as a reply to SELECT/EXAMINE commands. RFC 5162 talks about it being used in tagged replies to other commands. So returning HIGHESTMODSEQ in the tagged reply is the common case, b…

OK.

> I'm not sure what's the cleanest way to say it. That or "tagged or untagged".

"tagged or untagged OK response" is what I have now.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Nov 2012 10:47:10 +0000

>> It talks about it as a reply to SELECT/EXAMINE commands. RFC 5162 talks about it being used in tagged replies to other commands. So returning HIGHESTMODSEQ in the tagged reply is the common case,…

Agreed.

> "tagged or untagged OK response" is what I have now.

Works for me.