http://blog.gmane.org/gmane.ietf.imapext hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.imapext/5019 <pre>(Ex Cathedra*) Just to summarize where we are and next steps: - Ken Murchison reviewed the two drafts, comparing them to the implementation in Cyrus IMAP. - Short discussion afterward concerning per-metadata modification sequences (and whether we need them). As chairmen, we'd like to see more reviews, and any opinions on whether per-metadata modification sequences can be removed entirely or not. If you're intending checking the current drafts against your implementation, writing an implementation against the current drafts, or simply would like to volunteer to read through the drafts and point out areas they can be improved. Our impression is that there's an overall feeling that the two drafts should be combined; if anyone has strong feelings either way it'd be useful to make these known. Thanks, Eliot / Dave * - From The Chair _______________________________________________ imapext mailing list imapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/imapext </pre> Dave Cridland 2013-06-14T14:33:09 http://comments.gmane.org/gmane.ietf.imapext/5014 <pre>I have quickly read Alexey's refresh of these specs and they both seems to capture the relevant errata and implementation experience. I think that we might want to consider combining both specs into one document since they are so tightly coupled to one another, especially given that we really want clients to support QRESYNC (and not just CONDSTORE) as mentioned in the last 2 paragraphs of section 1 or QRESYNC. FWIW, Cyrus IMAP fully supports both extensions including errata 1807-1809, with the exception of the MODIFIED response code. Cyrus does not support separate per-metadata modseq, and always returns unsolicited FETCH responses for changed messages, so I don't know if the lack of a MODIFIED response code is an issue for client implementations. I don't believe that it would be a heavy lift to add MODIFIED to Cyrus. </pre> Ken Murchison 2013-06-10T19:48:05 http://comments.gmane.org/gmane.ietf.imapext/5013 <pre>I have quickly read Alexey's refresh of these specs and they both seems to capture the relevant errata and implementation experience. I think that we might want to consider combining both specs into one document since they are so tightly coupled to one another, especially given that we really want clients to support QRESYNC (and not just CONDSTORE) as mentioned in the last 2 paragraphs of section 1 or QRESYNC. FWIW, Cyrus IMAP fully supports both extensions including errata 1807-1809, with the exception of the MODIFIED response code. Cyrus does not support separate per-metadata modseq, and always returns unsolicited FETCH responses for changed messages, so I don't know if the lack of a MODIFIED response code is an issue for client implementations. I don't recall why we didn't add MODIFIED to Cyrus, but I don't believe that it would be a heavy lift to do so. </pre> Ken Murchison 2013-06-10T17:31:24 http://comments.gmane.org/gmane.ietf.imapext/5009 <pre>Hi, RFC3501 defines a LOGINDISABLED property that is used prior to STARTTLS (or some out of band security) being in place to ensure the LOGIN command is not used in an insecure environment. Some servers also offer configuration to also disable plain text authentication even when a security layer is in place. In that situation, should (must) the server advertise LOGINDISABLED in capabilities sent after STARTTLS? The spec really does not cover that case explicitly. Personally I think anytime the server is going to reject LOGIN it ought to advertise LOGINDISABLED to ensure clients don't "blindly" send the clear text credentials - because the purpose of disabling LOGIN is to stop that happening in the first place. </pre> Cyrus Daboo 2013-06-07T16:59:53 http://comments.gmane.org/gmane.ietf.imapext/5007 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IMAP QRESYNC Extension Working Group of the IETF. Title : IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization Author(s) : Alexey Melnikov Filename : draft-ietf-qresync-rfc4551bis-01.txt Pages : 24 Date : 2013-06-06 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 guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility pr</pre> internet-drafts< at >ietf.org 2013-06-06T13:34:20 http://comments.gmane.org/gmane.ietf.imapext/5001 <pre>Hi all, Which servers and clients are known to support the 2971 "ID" extension? I can tell that Gmail supports it, not sure about other servers, nor clients. </pre> Andrew Laurence 2013-06-04T21:44:03 http://comments.gmane.org/gmane.ietf.imapext/5000 <pre>Hi all, I thought this would be noteworthy in this group: http://blogs.technet.com/b/openness/archive/2013/05/31/feedback-exchange-server-and-outlook-standards.aspx </pre> Andrew Laurence 2013-05-31T21:34:52 http://comments.gmane.org/gmane.ietf.imapext/4999 <pre>Hello everyone, Forgive the massive list cross-posting, but I thought this noteworthy enough to spread around. Via their Openness&lt; at &gt;Microsoft blog, Microsoft invites input on their standards support in Outlook and Exchange. I'm sure they'd like to hear thoughtful, detailed, insightful responses from the customer world at large. http://blogs.technet.com/b/openness/archive/2013/05/31/feedback-exchange-server-and-outlook-standards.aspx Cheers, Andrew -- Andrew Laurence Office of Information Technology atlauren&lt; at &gt;uci.edu University of California, Irvine atlauren&lt; at &gt;me.com (Lists)_______________________________________________ imapext mailing list imapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/imapext </pre> Andrew Laurence 2013-05-31T22:18:42 http://comments.gmane.org/gmane.ietf.imapext/4998 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IMAP QRESYNC Extension Working Group of the IETF. Title : IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization Author(s) : Alexey Melnikov Filename : draft-ietf-qresync-rfc4551bis-00.txt Pages : 24 Date : 2013-05-30 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 guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility pr</pre> internet-drafts< at >ietf.org 2013-05-30T17:39:11 http://comments.gmane.org/gmane.ietf.imapext/4996 <pre>I saw nobody opposed, and plenty for. We'll sort out the mechanics of the adoption now. (Well, probably Eliot, rather than me). Dave. _______________________________________________ imapext mailing list imapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/imapext </pre> Dave Cridland 2013-05-28T10:42:57 http://comments.gmane.org/gmane.ietf.imapext/4985 <pre>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" &lt;jkt&lt; at &gt;flaska.net&gt; wrote: _______________________________________________ imapext mailing list imapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/imapext </pre> Dave Cridland 2013-05-23T21:40:10 http://comments.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://comments.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://comments.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://comments.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://comments.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://comments.gmane.org/gmane.ietf.imapext/4943 <pre>Hi, I've noticed that my code for GENURLAUTH is rather dumb and also quite buggy -- it breaks when there are multiple GENURLAUTH commands in flight (yes, it's a serious bug, users sending multiple messages at once could send wrong ones to wrong senders). What I need to know is a reliable way of mapping the returned URLs into the commands which issued them. I suspect this might not be an easy problem to solve, though. Unlike ESEARCH, the GENURLAUTH contains no tag information to "tie" it back to the issuing command, so I think that one should either disable pipelining of GENURLAUTH altogether, or somehow guess the correct bidning based on the received URLs. One could rely on the strict wording of RFC 4467's Chapter 5: An initial URL is built, ending with ";URLAUTH=&lt;access&gt;" but without the ":&lt;mech&gt;:&lt;token&gt;" components. An authorization mechanism is selected and used to calculate the authorization token, with the initial URL as the data and a secret known to the IMAP server as the key. The U</pre> Jan Kundrát 2013-04-17T15:03:11 http://comments.gmane.org/gmane.ietf.imapext/4932 <pre>Is there a kind soul that can convert my textual copy of rfc4551bis to XML? I can guarantee an acknowledgment and a beer (or an alternative drink of your choice) at one of IETF meetings. Also, if people can point me to a tool that might help with the conversion process, that would be awesome as well. _______________________________________________ imapext mailing list imapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/imapext </pre> Alexey Melnikov 2013-03-07T10:51:00 http://comments.gmane.org/gmane.ietf.imapext/4915 <pre>Hi, I've noticed some surge in activity related to implementing CONDSTORE (RFC 4551)/QRESYNC (RFC 5162) in both clients and servers, so I drafted a new WG charter proposal to update/clarify these: ----------- 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 discover flag changes and expunged messages in a mailbox, the client has to fetch flags for all messages it knows in the mailbox and compare returned results with its own state. This can generate a significant amount of traffic for big mailboxes. The IMAP CONDSTORE extension (RFC 4551) provides a facility for IMAP clients to quickly resynchronize mailbox flag changes in a mailbox. </pre> Alexey Melnikov 2013-03-05T14:57:25 http://comments.gmane.org/gmane.ietf.imapext/4905 <pre>Hi, it turned out that a certain IMAP server sends out non-standard "ESORT" responses in response to the ESORT command (the correct way is to respond with an ESEARCH). I've filed a bugreport with an attached patch which hopefully fixes the issue, but even if they accept it soon, there's the usual problem with releases taking time and sysadmins delaying updates etc, and in the end, it's always the client which gets the blame "because other MUAs work just fine". The server the reporter is using was released roughly 10 months ago; I have unfortunately no idea about when they started advertising the ESORT capability, the publicly available git mirror doesn't go that far back in time. Do you guys see any problem with a client simply accepting "* ESORT ..." in the same way and using the same syntax as an ESEARCH response? Would you leave such a workaround in your codebase indefinitely, or remove it after some time period? With kind regards, Jan </pre> Jan Kundrát 2013-02-25T14:59:58 http://comments.gmane.org/gmane.ietf.imapext/4885 <pre>Alexey has put the current information about implementations into the working group wiki: http://tools.ietf.org/wg/imapmove/trac/wiki This completes the last chartered milestone (a few weeks early, actually), and the Secretariat has marked that milestone as done: http://datatracker.ietf.org/wg/imapmove/charter/ Additionally, the MOVE specification, which is in the RFC Editor queue, is now in AUTH48 state -- the final editing and author review before it's published, which means that it should be published as an RFC within the next week or two. As soon as the RFC is published, I will ask the Secretariat to formally close down the working group. I want to take this opportunity to send out some thanks to * Arnt for taking the lead on the document, * everyone who reviewed, commented, and implemented, * Alexey and Ned for chairing (and Ned for doing editing while Arnt was under the weather). I consider this working group a smashing success: we chartered it quickly and gave it a focused, short-term task, i</pre> Barry Leiba 2013-01-16T23:42:54 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.imapext