http://permalink.gmane.org/gmane.ietf.imapext hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.imapext/4974 <pre>As co-chairman: On Mon, May 20, 2013 at 8:53 PM, Michael M Slusarz &lt;slusarz&lt; at &gt;horde.org&gt;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&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/imapext </pre> Dave Cridland 2013-05-20T20:20:08 http://permalink.gmane.org/gmane.ietf.imapext/4973 <pre>Quoting Dave Cridland &lt;dave&lt; at &gt;cridland.net&gt;: 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&lt; at &gt;horde.org] _______________________________________________ imapext mailing list imapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/imapext </pre> Michael M Slusarz 2013-05-20T19:53:03 http://permalink.gmane.org/gmane.ietf.imapext/4972 <pre>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&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/imapext </pre> Dave Cridland 2013-05-20T18:20:26 http://permalink.gmane.org/gmane.ietf.imapext/4971 <pre>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&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/imapext </pre> Eliot Lear 2013-05-16T04:47:21 http://permalink.gmane.org/gmane.ietf.imapext/4970 <pre> (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&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/imapext </pre> Dan Karp 2013-05-15T16:08:19 http://permalink.gmane.org/gmane.ietf.imapext/4969 <pre> 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 </pre> Jan Kundrát 2013-05-15T15:52:46 http://permalink.gmane.org/gmane.ietf.imapext/4968 <pre>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&lt; at &gt;ietf.org Reply-To: internet-drafts&lt; at &gt;ietf.org To: i-d-announce&lt; at &gt;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</pre> Alexey Melnikov 2013-05-14T19:32:07 http://permalink.gmane.org/gmane.ietf.imapext/4967 <pre>Hi Brandon, --On May 10, 2013 1:41:49 PM -0700 Brandon Long &lt;blong&lt; at &gt;google.com&gt; wrote: Also disconnected clients - they may need to thread messages without support from the server and ideally would want to use the same threading algorithm as the server when displaying messages whilst offline. Indeed, when I implemented THREAD in Mulberry I copied the REFERENCES algorithm for use client-side. </pre> Cyrus Daboo 2013-05-11T00:57:25 http://permalink.gmane.org/gmane.ietf.imapext/4966 <pre> Why else would the threading model need to be so specified and have multiple choices? My assumption was because it allowed the client to know where a message it appended to the server (or maybe copied to another folder) would end up in the threading. Or even that it could just download the new messages in the folder and update the local thread information and know it was in-sync with the server. I would think with THREAD=REFS, you can download the headers and lookup the possible matches using a SEARCH HEADER MESSAGE-ID construct to find the other messages. I've tried to address this waste of bandwidth by the INCTHREAD proposal Ah, yes, we sort threads in our interface by the INTERNALDATE of the latest message in the thread. We just mapped INTERNALDATE to our "received time" for the message, so checking if that corresponds to the SHOULDs... yes, those should all be true. We have "implementation defined" exceptions when messages are migrated where we sometimes have to try and infer the original r</pre> Brandon Long 2013-05-10T20:41:49 http://permalink.gmane.org/gmane.ietf.imapext/4965 <pre>Refs can be computed at delivery time. You have to sort the lines at read time, that is all. Arnt _______________________________________________ imapext mailing list imapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/imapext </pre> Arnt Gulbrandsen 2013-05-10T16:02:01 http://permalink.gmane.org/gmane.ietf.imapext/4964 <pre> Thanks, this answers my question perfectly. Could you elaborate a bit? Trojita does not have any builtin knowledge of any threading algorithm, yet will happily issue and use THREAD={REFS,REFERENCES,ORDEREDSUBJECT} and display the result to the user. It works pretty well, actually. Best when combined with Dovecot due to its THREAD=REFS support. Yes, this means that upon an arrival of a new message, it has to ask for the threading info for a whole mailbox again simply because we might not know the Message-Id of the existing threads, and therefore cannot replicate the server's algorithm. This is the "joy" of lazy loading in action :(. I've tried to address this waste of bandwidth by the INCTHREAD proposal [1], but I didn't have time to push for its inclusion in FLOSS IMAP servers yet. THREAD=REFERENCES and THREAD=ORDEREDSUBJECT both sort the list of threads by the INTERNALDATE of the thread root. Trojita will always display the threads in the order in which the THREAD response contained them. This means </pre> Jan Kundrát 2013-05-10T10:51:02 http://permalink.gmane.org/gmane.ietf.imapext/4963 <pre> You should be able to consider X-GM-THRID as immutable, that should have been called out in the documents. We never join threads. Gmail does not thread by references, its closest to threading by subject. Our user facing parlance is typically "conversation" instead of thread. A conversation is basically up to 100 messages with the same "clean" subject. IIRC, we will start a new conversation if there is sufficient time gap between the two, but we will use references to put a reply on an old conversation regardless of time... though the 100 message is a "hard" limit. Having a limit was chosen for performance reasons, we don't want to load a couple thousand message indexes from disk or have paging in the conversation view interface. The conversation view doesn't lend itself to true threading either, where "new" messages may be in multiple places in the page.... and most email communication doesn't have that complicated of a thread structure to begin with. It also fixes the typical use cases of "find a </pre> Brandon Long 2013-05-09T21:53:44 http://permalink.gmane.org/gmane.ietf.imapext/4962 <pre> I will be working on a CONDSTORE draft next week. Are chairs Ok with accepting 1 draft at a time? _______________________________________________ imapext mailing list imapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/imapext </pre> Alexey Melnikov 2013-05-09T19:39:50 http://permalink.gmane.org/gmane.ietf.imapext/4961 <pre> Actually no, I think the WG should look at adopting http://datatracker.ietf.org/doc/draft-melnikov-5162bis/ List of changes for the current version (-01) is: Appendix A. Changes since RFC 5162 Addressed erratum #1365: http://www.rfc-editor.org/errata_search.php?eid=1365 Addressed erratum #1807: http://www.rfc-editor.org/errata_search.php?eid=1807 Addressed erratum #1808: http://www.rfc-editor.org/errata_search.php?eid=1808 Addressed erratum #1809: http://www.rfc-editor.org/errata_search.php?eid=1809 Addressed erratum #3322: http://www.rfc-editor.org/errata_search.php?eid=3322 Fixed some examples to report data that match requirements specified Obviously the WG (once the draft is adopted by the WG) can decide to address these issues differently, but for now I assume that they are adequately addressed. I don't have any pending changes to -01. I do have a list of pending issues though, which I can post here. __________________________________________</pre> Alexey Melnikov 2013-05-09T19:35:35 http://permalink.gmane.org/gmane.ietf.imapext/4960 <pre>Hi, this might be a bit OT for this mailing list, but given that GMail is a rather dominant player among the IMAP service providers and due to the usefulness of having data available to other, I'm posting here anyway. - It isn't clear to me what the immutability guarantees of the returned data of the X-GM-THRID [1] extension are. It would be terrific if it was safe to cache these values in the same manner as any other immutable per-message data, but I suspect this is not possible -- if the threading is "right", delivery of any new message could potentially join independent threads together, thereby changing the thread IDs. How is GMail handling this? How is the threading computed? - Any plans to support the THREAD=REFS [2] in GMail? - Any plans for support of the SORT extensions? - Any plans for CONTEXT=SORT and CONTEXT=SEARCH? :) The reason why I'm asking is because I'd like to enable threading for Trojita's users who are accessing GMail. Any threading algorithm apart from THREAD=REFS has significant l</pre> Jan Kundrát 2013-05-09T16:27:43 http://permalink.gmane.org/gmane.ietf.imapext/4959 <pre> As chairman. Just so everyone's on the same page, the plan for the working group is essentially as follows: - Alexey's putting together starting drafts, which we'll be looking to adopt. - Once those drafts are out, we'll need reviewers on them to gauge what milestones we should have - we currently just have a publication request milestone of December; Eliot and I suspect this could be moved much sooner if we feel that the issues are well-known. - We're not intending meeting. This includes online meetings - all discussion will therefore be solely on this list. Just to refresh your memories, all discussion on this list (working- group related or not) is covered by the Note Well; if you're unclear what your responsibilities are under this, please ask. Sent with [inky: &lt;http://inky.com?kme=signature&gt;] _______________________________________________ imapext mailing list imapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/imapext </pre> Dave Cridland 2013-05-08T15:29:59 http://permalink.gmane.org/gmane.ietf.imapext/4958 <pre>Hi everyone, Please note, the intent is to have some more detailed milestones drawn out quickly for Barry's approval. I look forward to working with you. Eliot On 4/29/13 7:39 PM, The IESG wrote: _______________________________________________ imapext mailing list imapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/imapext </pre> Eliot Lear 2013-04-29T17:57:56 http://permalink.gmane.org/gmane.ietf.imapext/4957 <pre>A new IETF working group has been formed in the Applications Area. For additional information please contact the Area Directors or the WG Chairs. IMAP QRESYNC Extension (qresync) ------------------------------------------------ Current Status: Proposed Working Group Chairs: Dave Cridland &lt;dave&lt; at &gt;cridland.net&gt; Eliot Lear &lt;lear&lt; at &gt;cisco.com&gt; Assigned Area Director: Barry Leiba &lt;barryleiba&lt; at &gt;computer.org&gt; Mailing list Address: imapext&lt; at &gt;ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/imapext Archive: http://www.ietf.org/mail-archive/web/imapext/ Charter of Working Group: The Internet Message Access Protocol (IMAP), defined in RFC 3501, specifies a protocol for accessing email messages on a server that implements a message store from a client. It also includes commands for manipulating the message store -- creating, deleting, and renaming mailboxes, adding a message to a mailbox, and copying messages from one mailbox to another. Base IMAP as described in RFC 3501 requires that in order to </pre> The IESG 2013-04-29T17:39:20 http://permalink.gmane.org/gmane.ietf.imapext/4956 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond2< at >hushmail.com 2013-04-27T16:51:04 http://permalink.gmane.org/gmane.ietf.imapext/4955 <pre> while we're talking about such things, we should revisit the hard-limit on any IMAP message of 4GB (max unsigned 32 bits). I think the time will come quite soon where this limit is unsufficient As for LITERAL+ limits, our implementation drops to file over a threshold, so can go as large as there is free disk space. It would be more work to figure out a limit to advertise than it's worth for us, so lack of advertisement should mean no restriction. Until there is some sort of append / catenate there's no opportunity to split the literals up anyway. Adrien ------ Original Message ------ From: "Michael M Slusarz" &lt;slusarz&lt; at &gt;horde.org&gt; To: "imapext&lt; at &gt;ietf.org" &lt;imapext&lt; at &gt;ietf.org&gt; Sent: 24/04/2013 7:18:04 a.m. Subject: Re: [imapext] I-D Action: draft-melnikov-rfc2088bis-00.txt _______________________________________________ imapext mailing list imapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/imapext </pre> Adrien W. de Croy 2013-04-23T22:15:26 http://permalink.gmane.org/gmane.ietf.imapext/4954 <pre>Quoting Dan Karp &lt;dkarp&lt; at &gt;zimbra.com&gt;: I'm with Timo that I don't think there should be hardcoded limits within the RFC itself. But I agree with you, and I don't think Timo is arguing otherwise, that a server can, and most likely should, advertise limits on what it will accept. The latter allows the data limitations to be scaled to whatever resource constraints exist in the future (say: 802.11zzz connections, with 5000 Gb/s bandwidth). And if a server wants to accept gigabytes of data, more power to it - that is their design choice and they shouldn't be prevented from doing so. I think if we are going to announce limits, then it makes sense to advertise separate limits for 1) APPEND data and 2) everything else. The latter would aid clients in determining the maximum command size allowed on a server, rather than the nebulous "shouldn't send more than 1000 octets" we currently have in RFC 2683 -- the assumption/requirement being that the literal command limit should be equal to a s</pre> Michael M Slusarz 2013-04-23T19:18:04 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.imapext