gmane.ietf.imapext

Re: "NOMODSEQ until needed" optimization

Timo Sirainen — 2013-05-23T22:49:22



It's getting less and less useful. Originally when nobody really used them and Dovecot was using only Maildir, where adding extra 64bits to each message did about double the (heap) memory usage for a mailbox. But nowadays other mailbox formats use up more memory already and modseqs are very useful for other purposes as well (dsync mainly), so they are getting enabled more and more often anyway. The complexity now would be to change the code so it wouldn't need to be explicitly enabled :)

Mainly I was thinking that the comment in RFC could be about how NOMODSEQ was already used for this purpose, and/or recommending that if somebody else plans on doing that they would keep tracking the highestmodseq regardless of whether per-message modseqs are being tracked.

_______________________________________________
imapext mailing list
imapext< at >ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Re: qresync WG adoption call

Jan Kundrát — 2013-05-23T22:00:12

Hi Adrian,
Dovecot defers creating MODSEQs until they are "enabled" for a mailbox for the first time. This "enabling" happens apparently when the client opens a mailbox after having issued a "CONDSTORE-enabling command" for the first time. This is a safe optimization -- MODSEQs are turned on as soon as they are required. After that, they are apparently always tracked even if the user never executes a CONDSTORE-enabling command, ever.

Some users access their mailboxes only from clients which do not issue ENABLE CONDSTORE, ENABLE QRESYNC or any other similar command. His point is, apparently, that there is no point in having the MODSEQs tracked under these circumstances. Unfortunately, they only way to do so under RFC 4551 is rather strange, via the NOMODSEQ, and some clients are apparently confused by that. I cannot blame them.

Cheers,
Jan

Re: qresync WG adoption call

Adrien W. de Croy — 2013-05-23T21:51:32

are you talking about using the client setting to determine whether the 
server will track / store modseqs?

this seems dangerous.  The server never knows when it will be asked by a 
client for modseq, so if it supports it, it should track them always.  
It's common for the same mailbox to be accessed by multiple different 
agents (e.g. desktop + iOS)

As for deprecating shared/private and metadata modseq... +1

Adrien

------ Original Message ------
From: "Jan Kundrát" <jkt< at >flaska.net>
To: "imapext< at >ietf.org" <imapext< at >ietf.org>
Sent: 24/05/2013 8:33:06 a.m.
Subject: [imapext] Re: qresync WG adoption call

_______________________________________________
imapext mailing list
imapext< at >ietf.org
https://www.ietf.org/mailman/listinfo/imapext

"NOMODSEQ until needed" optimization

Dave Cridland — 2013-05-23T21:40:10

This is a great conversation to be having, but please remember to change
the subject line...
On 23 May 2013 22:17, "Jan Kundrát" <jkt< at >flaska.net> wrote:

_______________________________________________
imapext mailing list
imapext< at >ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Re: qresync WG adoption call

Jan Kundrát — 2013-05-23T20:33:06

This is probably worth explaining in the updated version. I see the benefits of not tracking MODSEQs when not ever requested, but I also understand that clients might want to set a local "don't bother with MODSEQs" bit in their cache if the server returns a NOMODSEQ. I can also see that a client might want to open a mailbox and bypass the usual sycnhronization steps (perhaps it just wants to quickly fetch an item, etc), so the use case for a MODSEQ-supporting client not enabling MODSEQs within some sessions seems valid to me. It's a corner case with potential to cause unpleasant surprises.

Originally, I wanted to suggest not returning either of HIGHESTMODSEQ or NOMODSEQ at SELECT time, but this is explicitly forbidden by the RFC.

Do you have any numbers on how much performance is gained by not tracking the MODSEQs -- i.e. is your optimization actually worth the complexity?

Cheers,
Jan

Re: qresync WG adoption call

Alexey Melnikov — 2013-05-23T20:36:00


3 errata are addressed, mostly minor.

(I will reply to the rest of your message in a separate email.)

_______________________________________________
imapext mailing list
imapext< at >ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Re: qresync WG adoption call

Tony Hansen — 2013-05-23T19:40:30

+1

I also like the idea of a combined document, following Alexey's outlined
approach.

    Tony Hansen

On 5/20/2013 2:20 PM, Dave Cridland wrote:

_______________________________________________
imapext mailing list
imapext< at >ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Re: qresync WG adoption call

Timo Sirainen — 2013-05-23T19:30:08


OK.


I don't think rfc4551-bis has any actual content changes compared to rfc4551? Some new things that come to my mind:

1. Dovecot doesn't enable modseq tracking until client has requested it in some way by enabling CONDSTORE or QRESYNC. Until then it says at SELECT:

* OK [NOMODSEQ] No permanent modsequences

I know at least one client thought this meant that modseqs couldn't be used even if CONDSTORE enabling command was used. I'm thinking about changing this so that highestmodseq is tracked always in any case, but that's not the easiest change. Anyway, should the -bis RFC mention something about this?

2. Per-metadata item modseqs. I didn't pay attention to this previously since I wasn't planning on implementing it anyway. But now looking at it..:


…

The last sentence seems to be somewhat wrong, because that would be necessary even if the server stores separate mod-sequences.

So as far as I see, the only benefit of having per-metadata modseqs would be for SEARCH MODSEQ? Seems like the document t

Re: qresync WG adoption call

Ken Murchison — 2013-05-23T13:22:08

+1

Re: qresync WG adoption call

Cyrus Daboo — 2013-05-23T13:18:19

Hi Dave,

--On May 20, 2013 7:20:26 PM +0100 Dave Cridland <dave< at >cridland.net> wrote:


+1

Re: WG participants please READ Re: qresync WG adoptioncall

Adrien W. de Croy — 2013-05-23T11:16:03

we already have support for CONDSTORE, but without mainstream client 
support for QRESYNC (esp with current status of Thunderbird) it's hard 
to justify the investment (refactoring to allow persistence of 
information about deleted messages) in that one.

So I would be keen to implement it, but I'd want to see some indication 
that popular clients are going to use it.

Also would be great if we could get a universal modseq for the entire 
user account, so you can query for changed folders.

Adrien


------ Original Message ------
From: "Eliot Lear" <lear< at >cisco.com>
To: "Dave Cridland" <dave< at >cridland.net>
Cc: "imapext< at >ietf.org" <imapext< at >ietf.org>
Sent: 23/05/2013 11:11:56 p.m.
Subject: [imapext] WG participants please READ Re: qresync WG adoption 
call
imapext mailing list
imapext< at >ietf.org
https://www.ietf.org/mailman/listinfo/imapext

WG participants please READ Re: qresync WG adoption call

Eliot Lear — 2013-05-23T11:11:56

<co-chair hat on>

I'm going to echo Dave's point.  This organization does its best work
when there are many eyes and its worst when people don't pay attention. 
If this work is important to you, PLEASE take a few minutes to read both
documents and comment on this call for adoption.

Eliot

On 5/23/13 12:27 PM, Dave Cridland wrote:

_______________________________________________
imapext mailing list
imapext< at >ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Re: qresync WG adoption call

Dave Cridland — 2013-05-23T10:27:40

Given we have only one response (which I can't actually read as being in
favour or not), I'm going to repeat this call - we need some noise, in
favour or against.

Can people say their piece by Monday, please?

Thanks,

Dave. (as co-chairman)
_______________________________________________
imapext mailing list
imapext< at >ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Re: qresync WG adoption call

Alexey Melnikov — 2013-05-23T09:01:47

As Dave said, our WG Charter doesn't restrict us in what we can do here. 
If people want a single document, my preferred way of doing that would be:
1) first post 2 separate drafts updating CONDSTORE and QRESYNC first (so 
that people can use wdiff to see what changed)
2) then produce a combined document with CONDSTORE inserted into QRESYNC 
(again, so that people can diff relevant parts)
3) start rearranging & rewriting text to make sure that CONDSTORE and 
QRESYNC bits are consistent with each other.

This is going to be more work, but I am happy to try if people see benefits.

_______________________________________________
imapext mailing list
imapext< at >ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Re: qresync WG adoption call

Dave Cridland — 2013-05-20T20:20:08

As co-chairman:

On Mon, May 20, 2013 at 8:53 PM, Michael M Slusarz <slusarz< at >horde.org>wrote:

It means this is the current proposal on the table, not that a single
document is ruled out. Either is explicitly allowed by our charter.
Adopting these as working group drafts would not preclude either, as far as
I'm concerned - once they're the working group's, we can do whatever we
have consensus on.



There's pros and cons each way; if anyone feels strongly (or would like to
explore the pros and cons) feel free to speak up.

Dave.
_______________________________________________
imapext mailing list
imapext< at >ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Re: qresync WG adoption call

Michael M Slusarz — 2013-05-20T19:53:03

Quoting Dave Cridland <dave< at >cridland.net>:


Does this mean the current inclination is to issue updates of the  
current documents rather than trying to combine into a single "IMAP  
synchronization extensions" doc?

I personally feel the latter makes more sense from a protocol  
implementor's standpoint, especially since the subtleties and  
interplay between the two extensions could more easily be explained.   
Although I understand this requires drafting of an entirely new  
document rather than incremental tweaking of existing text.

michael

___________________________________
Michael Slusarz [slusarz< at >horde.org]

_______________________________________________
imapext mailing list
imapext< at >ietf.org
https://www.ietf.org/mailman/listinfo/imapext

qresync WG adoption call

Dave Cridland — 2013-05-20T18:20:26

Folks,

We now have two drafts by Alexey published:

 - draft-melnikov-rfc4551-bis-00 (CONDSTORE)
 - draft-melnikov-5162bis-00 (QRESYNC)

I'd like to propose that the working group adopt these as our start point.

Therefore this constitutes a call for adoption of both documents; reviews
would be very useful at this stage and I'll prod people if there's no
volunteers.

Thanks,

Dave. (As qresync co-chairman)
_______________________________________________
imapext mailing list
imapext< at >ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Fwd: Corrected References, More Exhortation - NomCom 2013-2014 Call for Volunteers V1.2

Eliot Lear — 2013-05-16T04:47:21

Please consider volunteering for NOMCOM.  Leadership in the IETF is
chosen by NOMCOM, and this is your chance to participate in that selection.

Eliot
_______________________________________________
imapext mailing list
imapext< at >ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Re: GMail's extensions: X-GM-THRID immutability

Dan Karp — 2013-05-15T16:08:19

(Just a note: Any server that advertises a capability starting with "SORT"
must also implement the entire SORT extension.  So you'd need to call it
something else.)

   A server that supports the base-level SORT extension indicates this
   with a capability name which starts with "SORT".  Future, upwards-
   compatible extensions to the SORT extension will all start with
   "SORT", indicating support for this base level.

- Dan
_______________________________________________
imapext mailing list
imapext< at >ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Re: GMail's extensions: X-GM-THRID immutability

Jan Kundrát — 2013-05-15T15:52:46

I agree that it is good to have the threading algorithm well-specified. However, for me, the only bonus of the server-side threading is that it allows for threading of messages which have not been downloaded yet. The idea is that transferring a list of threading is cheaper than fetching the required headers for all messages.


True, but this leads to the O(n) latency (the pathologic case are deep ancient threads with the "References" header all containing just a single message). That's a lot of round trips.

[...]

From what you said, it looks like your server supports sorting by INTERNALDATE. I understand that mapping this into some message attribute would not be terribly useful, no matter whether per-thread or per-message -- if it's a message attribute, one could just as well fetch the INTERNALDATE and be done with it.

However, suppose there was a hypothetical SORT=INTERNALDATE capability which would work exactly like the existing SORT extension, but only allowing/requiring to sort via INTERNALDATE. The

Fwd: I-D Action: draft-melnikov-rfc4551-bis-00.txt

Alexey Melnikov — 2013-05-14T19:32:07

This is nearly identical to the RFC, but with references updated, errata 
3401 and 3506 fixed.

-------- Original Message --------
Subject: I-D Action: draft-melnikov-rfc4551-bis-00.txt
Date: Tue, 14 May 2013 12:25:26 -0700
From: internet-drafts< at >ietf.org
Reply-To: internet-drafts< at >ietf.org
To: i-d-announce< at >ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title           : IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization
Author(s)       : Alexey Melnikov
Filename        : draft-melnikov-rfc4551-bis-00.txt
Pages           : 23
Date            : 2013-05-14

Abstract:
    Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
    a common IMAP mailbox.  Examples include different clients working on
    behalf of the same user, and multiple users accessing shared
    mailboxes.  These clients need a mechanism to synchronize state
    changes for messages within the mailbox.  They must be able to
    guarante