Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension

From: Samsung SVL <[email-masked]>
Date: Tue, 3 Dec 2013 14:21:17 -0800 (PST)

Hi Dave/Alexy,

I have gone through the https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/ draft. Regarding the issue reported earlier, some server explicitly expects ENABLE command to increment the HIGHESTMODSEQ and some server automatically increments. To make the thing clear and also to follow the consistent behavior across various IMAP clients. It would be better to insist a point about enabling the CONDSTORE service in the server by sending ENABLE CONDSTORE command.

So, even-though server advertises the supported capability, its client responsibility to send ENABLE CONDSTORE command to enable the service. In case, if IMAP server did not support the ENABLE extension, then how client should enable the service can also mentioned to make it clear for client implementation. 

Please consider and if you feel its worthy, kindly update the draft. 

Regards,
Jay

>________________________________
> From: Dave Cridland <[email-masked]>
>To: Samsung SVL <[email-masked]> 
>Cc: Chris Newman <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Tuesday, 3 December 2013, 0:52
>Subject: Re: [lemonade] Regarding CONDSTORE IMAP extension
> 
>
>
>Just to remind folk, the update to RFC 4551 - now also documenting QRESYNC as well - is currently in Working Group Last Call, which ends on the 6th of December.
>
>
>https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/
>
>
>
>If you think this needs to be clearer in the new document, please let the document authors, and the mailing list at [email-masked] know.
>
>
>
>On Tue, Dec 3, 2013 at 12:02 AM, Samsung SVL <[email-masked]> wrote:
>
>Hi Chris,
>>
>>
>>Thanks for your clarification.
>>
>>
>>Regards,
>>Jay
>>
>>
>>
>>>________________________________
>>> From: Chris Newman <[email-masked]>
>>>To: Samsung SVL <[email-masked]>; [email-masked] 
>>>Sent: Monday, 2 December 2013, 18:10
>>>
>>>Subject: Re: [lemonade] Regarding CONDSTORE IMAP extension
>>>
>>>
>>>
>>>--On December 2, 2013 13:51:24 -0800 Samsung SVL <[email-masked]> 
>>>
>>>wrote:
>>>
>>>> Hi All,
>>>>
>>>> Kindly clarify my below query regarding "CONDSTORE" IMAP Extension.
>>>>
>>>> When IMAP server advertises the "CONDSTORE" support as part of
>>>> CAPABILITIES, client assumes that server support IMAP CONSTORE
>>>> extension. 
>>>>
>>>> As
 per RFC 4551,  client issues SELECT command  for a mailbox in the
>>>> below format and receives the response with HIGHESTMODSEQ value as  "1"
>>>>
>>>> C: A142 SELECT INBOX
>>>>
>>>> During the subsequent SELECT command, client receives "HIGHESTMODSEQ"
>>>> value always set to "1". Its not getting incremented with respect to the
>>>> changes in the mailbox. 
>>>>
>>>> Some IMAP server changes the HIGHESTMODSEQ value only when client issues
>>>> SELECT command in the below format.
>>>>
>>>> C:A142 SELECT "INBOX" (QRESYNC ("UIDVALIDITY" "HIGHESTMODSEQ"))
>>>>
>>>> Kindly clarify which format is right one, because most of the IMAP server
>>>> behaves differently. 
>>>
>>>Technically, the former command is correct only if you've previously issued 
>>>a condstore-enabling command (or don't want to use condstore) and the 
>>>latter is correct only if the server advertises QRESYNC and you have issued 
>>>"ENABLE QRESYNC" previously. For more details see RFC 4551 and RFC 5162.
>>>
>>>Have you tried using:
>>>
>>>C: A142 SELECT INBOX (CONDSTORE)
>>>
>>>That's a condstore-enabling command that servers advertising the CONDSTORE 
>>>capability are required to support. Servers are free to not return 
>>>HIGHESTMODSEQ at all until a condstore-enabling command occurs, and then 
>>>they MUST return either HIGHESTMODSEQ or NOMODSEQ.
>>>
>>>Of course, if a server is returning HIGHESTMODSEQ and not updating it after 
>>>flag
 changes, that server may have a bug, so you may have to fallback to 
>>>not using CONDSTORE with that server and just do a full resync every time. 
>>>You might want to report that bug to the server vendor so they have the 
>>>opportunity to fix it in a subsequent release.
>>>
>>>        - Chris
>>>
>>>
>>>
>>>
>>_______________________________________________
>>lemonade mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/lemonade
>>Supplemental Web Site:
>>http://www.standardstrack.com/ietf/lemonade
>>
>
>
>

---

From: Bron Gondwana <[email-masked]>
Date: Wed, 04 Dec 2013 10:30:35 +1100

That doesn't make sense.

If the mailbox supports CONDSTORE then it needs to update the MODSEQ on
affected messages and the HIGHESTMODSEQ on the mailbox regardless of
the source of the change, whether it be a CONDSTORE supported client or
not.

If it didn't, then other clients wouldn't see the changes.

What is possible is to delay the HIGHESTMODSEQ update until a CONDSTORE
supporting client connects, and then create a new MODSEQ value for the
folder and apply it to every message that has had any change since the
last CONDSTORE client connected.

As Chris said in the email that you're quoting - the server has a bug.
If it returns a HIGHESTMODSEQ value at all, then it MUST increment that
value if any message changes.  There's no ambiguity here.

Regards,

Bron.

On Wed, Dec 4, 2013, at 09:21 AM, Samsung SVL wrote:

Hi Dave/Alexy,

I have gone through
the [1]https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/ draft.
Regarding the issue reported earlier, some server explicitly expects
ENABLE command to increment the HIGHESTMODSEQ and some server
automatically increments. To make the thing clear and also to follow
the consistent behavior across various IMAP clients. It would be better
to insist a point about enabling the CONDSTORE service in the server by
sending ENABLE CONDSTORE command.

So, even-though server advertises the supported capability, its client
responsibility to send ENABLE CONDSTORE command to enable the service.
In case, if IMAP server did not support the ENABLE extension, then how
client should enable the service can also mentioned to make it clear
for client implementation.

Regards,
Jay
  __________________________________________________________________

Cc: Chris Newman <[email-masked]>; "[email-masked]"
<[email-masked]>

Just to remind folk, the update to RFC 4551 - now also documenting
QRESYNC as well - is currently in Working Group Last Call, which ends
on the 6th of December.

[2]https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/

If you think this needs to be clearer in the new document, please let
the document authors, and the mailing list at [3][email-masked] know.

On Tue, Dec 3, 2013 at 12:02 AM, Samsung SVL <[4][email-masked]>
wrote:

Hi Chris,

Regards,
Jay
  __________________________________________________________________

From: Chris Newman <[5][email-masked]>
To: Samsung SVL <[6][email-masked]>; [7][email-masked]
Sent: Monday, 2 December 2013, 18:10

--On December 2, 2013 13:51:24 -0800 Samsung SVL
<[8][email-masked]>

wrote:

> As per RFC 4551,  client issues SELECT command  for a mailbox in the

Technically, the former command is correct only if you've previously
issued
a condstore-enabling command (or don't want to use condstore) and the
latter is correct only if the server advertises QRESYNC and you have
issued
"ENABLE QRESYNC" previously. For more details see RFC 4551 and RFC
5162.

Have you tried using:

That's a condstore-enabling command that servers advertising the
CONDSTORE
capability are required to support. Servers are free to not return
HIGHESTMODSEQ at all until a condstore-enabling command occurs, and
then
they MUST return either HIGHESTMODSEQ or NOMODSEQ.

Of course, if a server is returning HIGHESTMODSEQ and not updating it
after
flag changes, that server may have a bug, so you may have to fallback
to
not using CONDSTORE with that server and just do a full resync every
time.
You might want to report that bug to the server vendor so they have the
opportunity to fix it in a subsequent release.

        - Chris

lemonade mailing list

[9][email-masked]

[10]https://www.ietf.org/mailman/listinfo/lemonade

Supplemental Web Site:

[11]http://www.standardstrack.com/ietf/lemonade

imapext mailing list

[12][email-masked]

[13]https://www.ietf.org/mailman/listinfo/imapext

--
Bron Gondwana
[email-masked]

References

1. https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/
2. https://ietf.org/doc/draft-ietf-qresync-rfc5162bis/
3. mailto:[email-masked]
4. mailto:[email-masked]
5. mailto:[email-masked]
6. mailto:[email-masked]
7. mailto:[email-masked]
8. mailto:[email-masked]
9. mailto:[email-masked]
  10. https://www.ietf.org/mailman/listinfo/lemonade
  11. http://www.standardstrack.com/ietf/lemonade
  12. mailto:[email-masked]
  13. https://www.ietf.org/mailman/listinfo/imapext

---

From: Jayantheesh S B <[email-masked]>
Date: Wed, 4 Dec 2013 11:53:04 -0600

Hi All,

Based on the below statement from RFC, client can enable the CONDSTORE by sending the ENABLE CONDSTORE command.
If CONDSTORE supported IMAP server, increments the HIGHESTMODESEQ for any changes in the mailbox automatically without any
request from the IMAP client, what would be the use of ENABLE CONDSTORE command to enable the service.

Please clarify.
A client supporting CONDSTORE extension indicates its willingness to
   receive mod-sequence updates in all untagged FETCH responses by
   issuing:

an ENABLE command containing "CONDSTORE" as one of the parameters.
      (This requirement only applies to servers that also implement the
      ENABLE extension [RFC5161].)

Regards,
Jay

From: Bron Gondwana [mailto:[email-masked]]
Sent: Tuesday, December 03, 2013 6:31 PM
To: [email-masked]
Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension

That doesn't make sense.

If the mailbox supports CONDSTORE then it needs to update the MODSEQ on affected messages and the HIGHESTMODSEQ on the mailbox regardless of the source of the change, whether it be a CONDSTORE supported client or not.

What is possible is to delay the HIGHESTMODSEQ update until a CONDSTORE supporting client connects, and then create a new MODSEQ value for the folder and apply it to every message that has had any change since the last CONDSTORE client connected.

As Chris said in the email that you're quoting - the server has a bug.  If it returns a HIGHESTMODSEQ value at all, then it MUST increment that value if any message changes.  There's no ambiguity here.

Regards,

Bron.

Regards,
Jay

________________________________
From: Dave Cridland <[email-masked]<mailto:[email-masked]>>
To: Samsung SVL <[email-masked]<mailto:[email-masked]>>
Cc: Chris Newman <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, 3 December 2013, 0:52
Subject: Re: [lemonade] Regarding CONDSTORE IMAP extension

If you think this needs to be clearer in the new document, please let the document authors, and the mailing list at [email-masked]<mailto:[email-masked]> know.

On Tue, Dec 3, 2013 at 12:02 AM, Samsung SVL <[email-masked]<mailto:[email-masked]>> wrote:
Hi Chris,

Regards,
Jay

________________________________
From: Chris Newman <[email-masked]<mailto:[email-masked]>>
To: Samsung SVL <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Sent: Monday, 2 December 2013, 18:10

--On December 2, 2013 13:51:24 -0800 Samsung SVL <[email-masked]<mailto:[email-masked]>>

Have you tried using:

flag changes, that server may have a bug, so you may have to fallback to

        - Chris

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

_______________________________________________
imapext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/imapext

--
Bron Gondwana
[email-masked]<mailto:[email-masked]>

---

From: Dave Cridland <[email-masked]>
Date: Wed, 4 Dec 2013 17:58:41 +0000

On Wed, Dec 4, 2013 at 5:53 PM, Jayantheesh S B <[email-masked]>wrote:

> If CONDSTORE supported IMAP server, increments the HIGHESTMODESEQ for any
> changes in the mailbox automatically without any
>

I think you've not quite understood what the passage you quote states.

>       ENABLE extension [RFC5161].)
So ENABLE enables the use of that extension's protocol changes for the rest
of that session.

It doesn't cause the server to start performing the extension's
requirements internally; a server can choose to do that at any time - but
one any client has used condstore with a mailbox, it has to continue
performing those requirements.

Does that help?

Dave.

---

From: Jayantheesh S B <[email-masked]>
Date: Wed, 4 Dec 2013 13:56:13 -0600

Thanks Dave for your detailed explanation.

Coming to my initial question. If IMAP server advertises the CONDSTORE capability indicates the support of IMAP CONDSTORE extension.

*         For SELECT/EXAMINE command IMAP server should send the HIGHESTMODESQ value modified with respect to change in the mailbox

(Or)

*         IMAP Client should send ENABLE CONDSTORE to enable the service for that session to get the correct HIGHESTMODSEQ value from server.

Please clarify.

Regards,
Jay
From: Dave Cridland [mailto:[email-masked]]
Sent: Wednesday, December 04, 2013 12:59 PM
To: Jayantheesh S B
Cc: Bron Gondwana; [email-masked]
Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension

On Wed, Dec 4, 2013 at 5:53 PM, Jayantheesh S B <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

Please clarify.

So ENABLE enables the use of that extension's protocol changes for the rest of that session.

It doesn't cause the server to start performing the extension's requirements internally; a server can choose to do that at any time - but one any client has used condstore with a mailbox, it has to continue performing those requirements.

Does that help?

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 4 Dec 2013 20:09:01 +0000

On Wed, Dec 4, 2013 at 7:56 PM, Jayantheesh S B <[email-masked]>wrote:

> Coming to my initial question. If IMAP server advertises the CONDSTORE
> capability indicates the support of IMAP CONDSTORE extension.
>
>
>
> ·         For SELECT/EXAMINE command IMAP server should send the
> HIGHESTMODESQ value modified with respect to change in the mailbox
>
> (Or)
>
> ·         IMAP Client should send ENABLE CONDSTORE to enable the service
> for that session to get the correct HIGHESTMODSEQ value from server.
>
>
>
> Please clarify.
>
>
>
Can I first check if you've read the latest draft:

http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis/

I'm hoping this should make the protocol clearer, and if it's still not
clear from this document, we should be addressing this now.

Dave.

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 5 Dec 2013 10:27:00 -0600

Thanks Dave.

It's clear in http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis/ draft.

Regards,
Jay
From: Dave Cridland [mailto:[email-masked]]
Sent: Wednesday, December 04, 2013 3:09 PM
To: Jayantheesh S B
Cc: [email-masked]
Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension

On Wed, Dec 4, 2013 at 7:56 PM, Jayantheesh S B <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Dave for your detailed explanation.

(Or)

Please clarify.

I'm hoping this should make the protocol clearer, and if it's still not clear from this document, we should be addressing this now.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 5 Dec 2013 18:01:51 +0000

On Thu, Dec 5, 2013 at 4:27 PM, Jayantheesh S B <[email-masked]>wrote:

> Thanks Dave.
>
>
>
> It’s clear in
> http://datatracker.ietf.org/doc/draft-ietf-qresync-rfc4551bis/ draft.
>
>
Thanks, that's really helpful - have you read the entire draft, and do you
have any further comments?

The Working Group Last Call ends tomorrow, and it'd be particularly good to
get any comments from a new implementor at this stage.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 06 Dec 2013 11:43:47 +0000

On 04/12/2013 20:09, Dave Cridland wrote:
>     Coming to my initial question. If IMAP server advertises the
>     CONDSTORE capability indicates the support of IMAP CONDSTORE
>     extension.
>
>     ·For SELECT/EXAMINE command IMAP server should send the
>     ·IMAP Client should send ENABLE CONDSTORE to enable the service
I think this is still an open issue which I haven't addressed in the 
document. Some people seem to have preference for the latter behaviour, 
but some servers implemented the former.

> I'm hoping this should make the protocol clearer, and if it's still 
> not clear from this document, we should be addressing this now.
>

---

From: Jayantheesh S B <[email-masked]>
Date: Fri, 6 Dec 2013 10:29:59 -0600

Hi Alexey,

Thanks for your response.

As a IMAP client implementer, to avoid any interoperability issue, we have modified our client to send ENABLE CONDSTORE, if IMAP server advertises the ENABLE and CONDSTORE IMAP extension as part of CAPABILITY response.

This solves the problem for us irrespective of IMAP server implementation.

Regards,
Jay
From: Alexey Melnikov [mailto:[email-masked]]
Sent: Friday, December 06, 2013 6:44 AM
To: Dave Cridland; Jayantheesh S B
Cc: [email-masked]
Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension

(Or)

Please clarify.
I think this is still an open issue which I haven't addressed in the document. Some people seem to have preference for the latter behaviour, but some servers implemented the former.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 14 Dec 2013 23:38:11 +0000

Hi,

On 05/12/2013 16:27, Jayantheesh S B wrote:
> It's clear in 
> *From:*Dave Cridland [mailto:[email-masked]]
> *Sent:* Wednesday, December 04, 2013 3:09 PM
> *To:* Jayantheesh S B
> *Cc:* [email-masked]
> *Subject:* Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension
>
I updated the draft to say the latter. Any other CONDSTORE enabling 
command would have the same effect.

---

From: Jayantheesh S B <[email-masked]>
Date: Mon, 16 Dec 2013 10:52:09 -0600

Thanks Alexey.

From: Alexey Melnikov [mailto:[email-masked]]
Sent: Saturday, December 14, 2013 6:38 PM
To: Jayantheesh S B
Cc: Dave Cridland; [email-masked]
Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension

Hi,

Regards,
Jay
From: Dave Cridland [mailto:[email-masked]]
Sent: Wednesday, December 04, 2013 3:09 PM
To: Jayantheesh S B
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [imapext] [lemonade] Regarding CONDSTORE IMAP extension

(Or)

*         IMAP Client should send ENABLE CONDSTORE to enable the service for that session to get the correct HIGHESTMODSEQ value from server.
I updated the draft to say the latter. Any other CONDSTORE enabling command would have the same effect.

Please clarify.