Subject: [lemonade] QRESYNC again

From: Timo Sirainen <[email-masked]>
Date: Sun, 12 Oct 2008 14:02:36 +0300

I think we decided two things when QRESYNC is enabled:

1) FETCH replies will always contain UID
2) CLOSE doesn't send HIGHESTMODSEQ and it's recommended against using
it at all.

But I'm not really sure if anything was decided about the 3rd issue
where:

C1: a EXPUNGE
S1: * VANISHED 1234
S1: a ok [highestmodseq 2]

C2: b STORE 1 -FLAGS \Seen
S2: * 1 fetch (flags () modseq 3)
S2: b ok
[[Client 2 disconnects]]

Client 2 loses the VANISHED reply. My idea was that server would be able
to detect this and send just before the "b ok":

* OK [HIGHESTMODSEQ 1]

Which would tell the client that it doesn't know all the modseqs yet.

_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 12 Oct 2008 14:12:25 +0300

> to detect this and send just before the "b ok":

And as a small optimization alternatively the [HIGHESTMODSEQ] could be
added to the tagged reply's resp-text-code as long as it didn't already
have a resp-text-code.

I've implemented this HIGHESTMODSEQ sending generically to all commands,
which also means I haven't added extra special code for EXPUNGE
handling. Any thoughts on of this would be ok:

Client 1 first expunges UID 1234 with modseq=2 and then updates UID 1
flags with modseq=3. Client 2 then does EXPUNGE:

a EXPUNGE
* VANISHED 1234
* 1 FETCH (FLAGS (\Seen) MODSEQ 3)
a OK

HIGHESTMODSEQ 3 wouldn't be sent because MODSEQ 3 already told the
client to update the modseq.

I guess it doesn't really even violate RFC 5162 because the EXPUNGE
command itself didn't really expunge anything, it just showed what
another session did.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 19 Oct 2008 12:01:15 +0100

>Which would tell the client that it doesn't know all the modseqs yet.
While I originally had some reservations about this solution, it looks 
sensible to me now.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 19 Oct 2008 21:08:56 +0100

Hi Timo,
I've started updating my copy of the QRESYNCbis document.

>> 1) FETCH replies will always contain UID
I've just updated my copy by adding the following text:

    Once a "CONDSTORE enabling command" is issued by the client,
    the server MUST automatically include both UID and mod-sequence data
    in all subsequent untagged FETCH responses (until the connection is 
closed),
    whether they were caused by a regular STORE, a STORE with UNCHANGEDSINCE
    modifier, or an external agent.

This is similar to the text in the CONDSTORE RFC.

>> 2) CLOSE doesn't send HIGHESTMODSEQ
>
I've added the following text to address that:

    The server MUST NOT send the updated per-mailbox modification sequence
    using the HIGHESTMODSEQ response code (defined in [CONDSTORE]
    in the tagged OK response, as this might cause loss of synchronization
    on the client.

>> and it's recommended against using it
>
Can you elaborate on what do you mean by "it" here?

>> at all.

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 19 Oct 2008 23:27:48 +0300

On Oct 19, 2008, at 11:08 PM, Alexey Melnikov wrote:

>   in all subsequent untagged FETCH responses (until the connection  
> is closed),

What about FETCH command without UID parameter?

> Can you elaborate on what do you mean by "it" here?

I guess I was thinking something like "Since the client probably cares  
about knowing the latest mailbox modseq state, it should use EXPUNGE +  
SELECT/UNSELECT/LOGOUT instead of CLOSE command."

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 19 Oct 2008 21:36:36 +0100

> What about FETCH command without UID parameter?

Ok, I will add this to the list.

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 19 Oct 2008 23:38:44 +0300

> Ok, I will add this to the list.

I was rather thinking that maybe that shouldn't contain the UID since  
if client wanted it it would have used the UID parameter. But I don't  
really care that much :)

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 19 Oct 2008 21:59:32 +0100

> if client wanted it it would have used the UID parameter. But I don't  

Why did you mention FETCH then, as it was clearly NOT in the list above :-)?

I can go either way with FETCH, I don't really care.

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 20 Oct 2008 00:03:33 +0300

On Oct 19, 2008, at 11:59 PM, Alexey Melnikov wrote:

>>>>> in all subsequent untagged FETCH responses (until the  
>>>>> connection   is closed),
>> I was rather thinking that maybe that shouldn't contain the UID  
>> since  if client wanted it it would have used the UID parameter.  
>> But I don't  really care that much :)
>

Because it says "all untagged FETCH responses", and I think that also  
means the FETCH responses to FETCH commands even though it's not  
explicitly in the following list (they seem like examples rather than  
a definitive list).
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 19 Oct 2008 22:11:36 +0100

>>> On Oct 19, 2008, at 11:36 PM, Alexey Melnikov wrote:
 [...]

> explicitly in the following list (they seem like examples rather than  

Ok, how about the following text:

    Once a "CONDSTORE enabling command" is issued by the client,
    the server MUST automatically include both UID and mod-sequence data
    in all subsequent untagged FETCH responses (until the connection is 
closed),
    whether they were caused by a regular STORE/UID STORE, a STORE/UID STORE
    with UNCHANGEDSINCE modifier, or an external agent.
    Note that this rule doesn't affect untagged FETCH responses caused 
by a FETCH
    command that doesn't include UID and/or MODSEQ FETCH data item, or 
UID FETCH
    without the MODSEQ FETCH data item.

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 20 Oct 2008 00:26:30 +0300

>   without the MODSEQ FETCH data item.

That looks good to me.