From barryleiba.mailing.lists@gmail.com Wed Apr 17 06:20:35 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8331521F8E76 for ; Wed, 17 Apr 2013 06:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.931 X-Spam-Level: X-Spam-Status: No, score=-102.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T33-szwn0iEC for ; Wed, 17 Apr 2013 06:20:33 -0700 (PDT) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id AEC1A21F8E6E for ; Wed, 17 Apr 2013 06:20:25 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id d10so1430669vea.28 for ; Wed, 17 Apr 2013 06:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=6YHgEKpERHWJemPDZhf7UL0mwPprgmdu3+TBXAkD268=; b=G5b0naIOYGa7wC0BdXGEHEhbrac9Iv2oWysc/9UmaHdl41w74oR+mIreGMcfboclwd NuPIYt7Qu+OSlSGXElUDeJdSDA9z/c1Hi7uNAc5Ja7wB9jaCrcXl8BBQMtVPErqY3QyK sWzMg4WU0KiNwX3mB3Jg4nYvk089BYluKVP1jxYilU3fkLa80tRvO1kBBL475o4RkO99 zVNKSdRr3X/Pc3kAjCwnP+zK/quKXbh98in4lnmeVJf6eDw+gybdao+t+11tBwIKqjh4 MY0BY77JMPspozts/FDckcPgpF04kygFaeaNr8I/mMZL4wOMTx+ivTiPsJD3qcAg0YFr 7JLg== MIME-Version: 1.0 X-Received: by 10.52.89.229 with SMTP id br5mr4079097vdb.24.1366204825019; Wed, 17 Apr 2013 06:20:25 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Wed, 17 Apr 2013 06:20:24 -0700 (PDT) In-Reply-To: <513607D5.4090808@isode.com> References: <513607D5.4090808@isode.com> Date: Wed, 17 Apr 2013 09:20:24 -0400 X-Google-Sender-Auth: rlNM6tUhUjui26gdrOVcNARa7JU Message-ID: From: Barry Leiba To: "imapext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [imapext] Proposal for a new IMAP Working Group to revise CONDSTORE & QRESYNC X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 13:20:35 -0000 Just to give everyone an update on this: The charter proposal was approved last Thursday by the IESG: http://datatracker.ietf.org/doc/charter-ietf-qresync/ The charter is currently in review within the IETF and with associated standards organizations: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg11408.html It will be on the agenda for approval on next week's IESG telechat (25 April). We're working on selecting chairs, and are interested in input: if you would like to chair this working group (whether or not you've chaired an IETF working group before), let Pete and me know off list, at . We're especially seeking new chairs who want to learn the process and continue work chairing other working groups in the future. Barry, Applications AD From barryleiba@gmail.com Wed Apr 17 06:30:47 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B0821F8D02 for ; Wed, 17 Apr 2013 06:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mcaoF4SwlRS for ; Wed, 17 Apr 2013 06:30:46 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 90AAD21F8D31 for ; Wed, 17 Apr 2013 06:30:44 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id er20so1499567lab.0 for ; Wed, 17 Apr 2013 06:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=FJ1P0mfgsyooypAMGAp4xgdXMddFPP3u6o0IhBwKqMw=; b=mFUiV2SRJVuCFwscX4yz0YBOn2Wrv1yvxb1ZyH/cASkAdsNNQQf3sFWDcqMKHAZ2Q6 QX3Nj23nj4qN1nLZ7RZjFLsrO1/aIbaR65DAMA9/+CVGDwF7yVomJzKWOEOUNIl+Hu5e QO+bo5GJuLQX+O8jsNARDDEJBgfqKmX1Nw1gfKZspHdYkY/+Klmj2VZS9A+YwHr+C6nH VodvRqZ4ZROuLSO+4b5/LFyKI/vH8Efwu6dgdbQyRYW6zj1oToRvC5l9soajqOihnY+E brLo5dXG+N6caV39DALAiQWwe+RvMfAgYFSSti9P5S8LNoO52Mh8nx9id3paZyEoX/z4 1M6w== MIME-Version: 1.0 X-Received: by 10.112.134.135 with SMTP id pk7mr3629463lbb.54.1366205441140; Wed, 17 Apr 2013 06:30:41 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.117.225 with HTTP; Wed, 17 Apr 2013 06:30:41 -0700 (PDT) Date: Wed, 17 Apr 2013 09:30:41 -0400 X-Google-Sender-Auth: jON3sXE2a2ii9g7xzulCMCKvIs8 Message-ID: From: Barry Leiba To: "imapext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-iceman-imap-specialuse-important@tools.ietf.org Subject: Re: [imapext] New Version Notification for draft-iceman-imap-specialuse-important-02.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 13:30:47 -0000 Hey, all. Reviving this, after not having time for it for a while. When last we spoke, the recommendation was to recast this proposal in terms of a $Important message keyword. This version of the draft does that. Comments, please. Is this what people had in mind? Remember that the model for this is Gmail's "important" flag, where messages are marked as "important" heuristically, based on what the system has seen you do with similar messages. Users can also set or clear the "important" flag, and the system will use that action to modify its heuristics. The "\Important" mailbox is then a collection of some of the "important" messages (in Gmail's case, those that are important and not archived). This spec aims to generalize that, because Eric and I think it's a useful model, apart from what Gmail specifically does with it. Barry On Mon, Apr 15, 2013 at 1:56 PM, wrote: > > A new version of I-D, draft-iceman-imap-specialuse-important-02.txt > has been successfully submitted by Barry Leiba and posted to the > IETF repository. > > Filename: draft-iceman-imap-specialuse-important > Revision: 02 > Title: IMAP $Important Keyword and \Important Special-Use Attribute > Creation date: 2013-04-15 > Group: Individual Submission > Number of pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-iceman-imap-specialuse-important-02.txt > Status: http://datatracker.ietf.org/doc/draft-iceman-imap-specialuse-important > Htmlized: http://tools.ietf.org/html/draft-iceman-imap-specialuse-important-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-iceman-imap-specialuse-important-02 > > Abstract: > RFC 6154 created an IMAP Special-Use LIST extension and defined an > initial set of attributes. This document defines a new attribute, > "\Important", and establishes a new IANA registry for IMAP folder > attributes, registering the attributes defined in RFCs 3348, 3501, > and 6154. This document also defines a new IMAP keyword, > "$Important", and registers it in the registry defined in RFC 5788. From tss@iki.fi Wed Apr 17 06:43:07 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661C321F8480 for ; Wed, 17 Apr 2013 06:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwUmoKRFSQ9w for ; Wed, 17 Apr 2013 06:43:06 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB8E21F86DD for ; Wed, 17 Apr 2013 06:43:06 -0700 (PDT) Received: from [10.217.1.201] (unknown [194.157.98.74]) by dovecot.org (Postfix) with ESMTP id 673F31AE835C for ; Wed, 17 Apr 2013 16:43:04 +0300 (EEST) Message-ID: <1366206183.11047.298.camel@innu> From: Timo Sirainen To: imapext@ietf.org Date: Wed, 17 Apr 2013 16:43:03 +0300 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [imapext] New Version Notification for draft-iceman-imap-specialuse-important-02.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 13:43:07 -0000 On Wed, 2013-04-17 at 09:30 -0400, Barry Leiba wrote: > Hey, all. Reviving this, after not having time for it for a while. > When last we spoke, the recommendation was to recast this proposal in > terms of a $Important message keyword. This version of the draft does > that. Comments, please. Is this what people had in mind? Looks ok to me. BTW. This reminds me about wanting to create a standardized $HasAttachments keyword that is set by the server and the client can read/change it. From cyrus@daboo.name Wed Apr 17 07:43:21 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0544A21F86BA for ; Wed, 17 Apr 2013 07:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfOLGX1q3oMw for ; Wed, 17 Apr 2013 07:43:20 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 41B9F21F86A5 for ; Wed, 17 Apr 2013 07:43:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id AB15F4173039; Wed, 17 Apr 2013 10:43:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVlc_AkVZJv8; Wed, 17 Apr 2013 10:43:18 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 39143417302E; Wed, 17 Apr 2013 10:43:16 -0400 (EDT) Date: Wed, 17 Apr 2013 10:43:12 -0400 From: Cyrus Daboo To: Barry Leiba , imapext@ietf.org Message-ID: <3CB1725987A08F00F9958841@caldav.corp.apple.com> In-Reply-To: References: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=2625 Cc: draft-iceman-imap-specialuse-important@tools.ietf.org Subject: Re: [imapext] New Version Notification for draft-iceman-imap-specialuse-important-02.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 14:43:21 -0000 Hi Barry, --On April 17, 2013 at 9:30:41 AM -0400 Barry Leiba wrote: > Hey, all. Reviving this, after not having time for it for a while. > When last we spoke, the recommendation was to recast this proposal in > terms of a $Important message keyword. This version of the draft does > that. Comments, please. Is this what people had in mind? > > Remember that the model for this is Gmail's "important" flag, where > messages are marked as "important" heuristically, based on what the > system has seen you do with similar messages. Users can also set or > clear the "important" flag, and the system will use that action to > modify its heuristics. The "\Important" mailbox is then a collection > of some of the "important" messages (in Gmail's case, those that are > important and not archived). > > This spec aims to generalize that, because Eric and I think it's a > useful model, apart from what Gmail specifically does with it. I am still having a hard time figuring out how $Important is really any different from \Flagged. Taking a look at the two points in the definition in the current draft (Section 2): 1. Importance vs urgency. I don't see how users are expected to understand the difference between these. Even if it is, I don't like the fact that you say it is used for triage as I think that implies more than a two-level state (e.g., the popular "getting things done" methodology uses multiple "levels" of priority for tasks and workflows). Maybe a combination of \Flagged and $Important provides multiple levels, e.g., \Flagged+$Important == top priority, \Flagged=next level down, $Important=next level below that, neither=low priority (and of course we also have $Junk which arguably means the lowest "priority" of all). But using those in combination does not seem right. Perhaps we need $Priority1, $Priority2, ... keywords to cover a multi-level priority. 2. Heuristically set: the fact that the server might set it is irrelevant - nothing stops a server from doing that with \Flagged (or indeed any other keyword or flag). It is also not clear whether there might be side-effects of the user changing $Important. One thing Eric Iceman mentioned was that users can "train" their (GMail) server by copying/moving messages into the \Important mailbox - that is not discussed as a possibility for \Important in the draft right now. But wouldn't the same also apply to adding/removing the $Important keyword? If so, then I would tend to see that as a distinction from $Flagged, and that should probably be mentioned in the spec too. -- Cyrus Daboo From barryleiba@gmail.com Wed Apr 17 08:03:20 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAD921F85ED for ; Wed, 17 Apr 2013 08:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNKWaTd1uqjl for ; Wed, 17 Apr 2013 08:03:19 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5051A21F85DB for ; Wed, 17 Apr 2013 08:03:19 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id fo12so1597071lab.38 for ; Wed, 17 Apr 2013 08:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YLPH9C8OKPmCNDrba0uiS6306ALddApftiRnyskU3PI=; b=hcE4I3ZGzaatJZ/B4j0G1YslET0YFMs32wPb4exWnvMDp3djdGWUXwvKnse9XIoTrM /NGd4c3vAwD6VzxxC0ZFpfGk+++5AOac4nRQ2Lz26F2JURB5CJbAXP/jAgMBkOZnYXXK yaHL4JUxAeTnWkpDNj4bU6ogz65mFlyx34NrEtRE14y166KTDwabDIhTBfjvI21kp/+4 X2t/Lxp1iHFjkz4hWky/ERG/jqUC++h/+hk4dmkWMQ4eN+xS/NJbm8emxTD4mqxNVv45 UXNkMkL5HPmrCFKPJ+CnOy5o+anVMD64aioEdeMVUplI+K7mIEjkEDIxOLOdCq7TEYSk u/UA== MIME-Version: 1.0 X-Received: by 10.112.209.38 with SMTP id mj6mr3312111lbc.52.1366210998262; Wed, 17 Apr 2013 08:03:18 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.117.225 with HTTP; Wed, 17 Apr 2013 08:03:18 -0700 (PDT) In-Reply-To: <3CB1725987A08F00F9958841@caldav.corp.apple.com> References: <3CB1725987A08F00F9958841@caldav.corp.apple.com> Date: Wed, 17 Apr 2013 11:03:18 -0400 X-Google-Sender-Auth: NiPYv7c4htVyQ8egjRIPXMwQ_wU Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-iceman-imap-specialuse-important@tools.ietf.org, "imapext@ietf.org" Subject: Re: [imapext] New Version Notification for draft-iceman-imap-specialuse-important-02.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 15:03:20 -0000 > 1. Importance vs urgency. I don't see how users are expected to understand > the difference between these. Gmail users seem to. It's the sense of "this message came from someone you often correspond with," "this message is part of a discussion thread you've been participating in," or "this message has keywords that you seem to consider significant," as opposed to "this message comes from someone you don't know, and it's inviting you to attend a conference you've never paid attention to before." Whereas "urgency" has the sense that "this message is something you need to deal with right away." Usually, that's because you marked it that way. In Gmail terms, that's "starred", and that's exposed as \Flagged in IMAP. > Even if it is, I don't like the fact that you > say it is used for triage as I think that implies more than a two-level > state (e.g., the popular "getting things done" methodology uses multiple > "levels" of priority for tasks and workflows). It might be that something other than a binary indicator would be useful. This isn't that, and isn't meant for that. Do you think the distinction I made above is not useful? There are certainly a lot of Gmail users who think it is. Do you, perhaps, have a suggestion for a better way to say this than what I've said in the document? (I can certainly put some of what's above into the document, as an example use case.) > 2. Heuristically set: the fact that the server might set it is irrelevant - > nothing stops a server from doing that with \Flagged (or indeed any other > keyword or flag). I don't agree at all that it's irrelevant. In the vast majority of cases, \Flagged is set by the user. It might also be set by a Sieve script or the equivalent (I do have some Gmail filters that set it), but that's also set by the user through a rule the user created. Do you actually know of any servers that set \Flagged heuristically, without an explicit rule from the user? The whole point here is that $Important is *intended* to be set heuristically, whereas \Flagged is *intended* to be set by the user. That it might sometimes be done otherwise is a side point. > It is also not clear whether there might be side-effects of the user > changing $Important. One thing Eric Iceman mentioned was that users can > "train" their (GMail) server by copying/moving messages into the \Important > mailbox - that is not discussed as a possibility for \Important in the draft > right now. But wouldn't the same also apply to adding/removing the > $Important keyword? If so, then I would tend to see that as a distinction > from $Flagged, and that should probably be mentioned in the spec too. Hm. I took this out, because I understood that people thought that use case was problematic. I'm happy to add it back in (I think it's a significant and useful case). Barry From jkt@flaska.net Wed Apr 17 08:05:21 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29AA21F85D9 for ; Wed, 17 Apr 2013 08:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39QZ+ryoipLZ for ; Wed, 17 Apr 2013 08:05:21 -0700 (PDT) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id E8AB221F85D6 for ; Wed, 17 Apr 2013 08:05:20 -0700 (PDT) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 41CF662B32; Wed, 17 Apr 2013 17:05:18 +0200 (CEST) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Wed, 17 Apr 2013 17:03:11 +0200 User-Agent: trojita/v0.3.92-95-g3a2a076; Qt/4.8.4; X11; Linux; MIME-Version: 1.0 Message-ID: <1ab91a26-9a10-46cc-8bb4-8609463443fb@flaska.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [imapext] GENURLAUTH pipelining X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 15:05:21 -0000 Hi,=0AI'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 on= ce could send wrong ones to wrong senders). What I need to know is a re= liable way of mapping the returned URLs into the commands which issued = them. I suspect this might not be an easy problem to solve, though. Unl= ike ESEARCH, the GENURLAUTH contains no tag information to "tie" it bac= k to the issuing command, so I think that one should either disable pip= elining of GENURLAUTH altogether, or somehow guess the correct bidning = based on the received URLs.=0A=0AOne could rely on the strict wording o= f RFC 4467's Chapter 5:=0A=0A An initial URL is built, ending with ";= URLAUTH=3D" but without=0A the "::" components. = An authorization mechanism is=0A selected and used to calculate the = authorization token, with the=0A initial URL as the data and a secret= known to the IMAP server as the=0A key. The URLAUTH-authorized URL = is generated by taking the initial=0A URL and appending ":", the URL = authorization mechanism name, ":", and=0A the ASCII-encoded hexadecim= al representation of the authorization=0A token.=0A=0AThis means "ign= ore any URLs which do not begin with the string I sent". However, I can= imagine all sorts of transformations a server might want to perform on= the URLs they hand out -- the most trivial is case mangling for userna= mes/hostnames/mailboxes, but there are even harder-to-detect, yet legit= imate (?) transformations like using a real FQDN for a server's hostnam= e.=0A=0AApart from that, there's also the possibility of some semi-evil= mangling like providing a different UID/UIDVALIDITY/mailbox triplet wh= ich might make a certain level of sense when e.g. dealing with virtual = mailboxes like "[All messages]".=0A=0AWhat is your advise here?=0A=0AWi= th kind regards,=0AJan=0A=0A-- =0ATrojit=C3=A1, a fast Qt IMAP e-mail c= lient -- http://trojita.flaska.net/ From arnt@gulbrandsen.priv.no Wed Apr 17 13:05:37 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817BC21E8091 for ; Wed, 17 Apr 2013 13:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXrA4+UV-8z1 for ; Wed, 17 Apr 2013 13:05:37 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D64721E808F for ; Wed, 17 Apr 2013 13:05:36 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3C10FFA0064; Wed, 17 Apr 2013 20:05:36 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1366229134-9044-9042/12/4; Wed, 17 Apr 2013 20:05:34 +0000 User-Agent: Kaiten Mail In-Reply-To: <1ab91a26-9a10-46cc-8bb4-8609463443fb@flaska.net> References: <1ab91a26-9a10-46cc-8bb4-8609463443fb@flaska.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=----QXHRPHNU45ZLMP1CLXNNDA9IHOVH48 From: Arnt Gulbrandsen Date: Wed, 17 Apr 2013 22:05:30 +0200 To: Jan =?ISO-8859-1?q?Kundr=E1t?= , imapext@ietf.org Message-Id: Subject: Re: [imapext] GENURLAUTH pipelining X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 20:05:37 -0000 ------QXHRPHNU45ZLMP1CLXNNDA9IHOVH48 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In cases like that, the server is required to process the commands = strictly in the order received. That solves the ambiguity. Arnt ------QXHRPHNU45ZLMP1CLXNNDA9IHOVH48 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

In cases like that, the server is required to process the = commands strictly in the order received. That solves the ambiguity.


Arnt ------QXHRPHNU45ZLMP1CLXNNDA9IHOVH48-- From groups@maclean.com Wed Apr 17 14:49:06 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21ADC21F8C08 for ; Wed, 17 Apr 2013 14:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7Bq4vVh+kj4 for ; Wed, 17 Apr 2013 14:49:05 -0700 (PDT) Received: from cs8-dallas.accountservergroup.com (unknown [108.174.144.176]) by ietfa.amsl.com (Postfix) with ESMTP id B137F21F8B3A for ; Wed, 17 Apr 2013 14:49:05 -0700 (PDT) Received: from pool-96-228-82-9.lyncva.east.verizon.net ([96.228.82.9]:50765 helo=Samsung-RF711.maclean.com) by cs8-dallas.accountservergroup.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1USaDw-000ACS-Mz; Wed, 17 Apr 2013 21:49:04 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 17 Apr 2013 17:48:57 -0400 To: Barry Leiba , "imapext@ietf.org" From: Pete Maclean In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cs8-dallas.accountservergroup.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - maclean.com Message-Id: <20130417214905.B137F21F8B3A@ietfa.amsl.com> Subject: Re: [imapext] New Version Notification for draft-iceman-imap-specialuse-important-02.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 21:49:06 -0000 I made a pitch before for clarification to be added as to whether a mailbox flagged as \Important is intended to hold only $Important messages or not. I see this has not been done and I am wondering why. Does the document make it clear to others and just not to me? Or is there an intention to leave this deliberately vague? I also wonder if there is an intention that a user's mail store should only ever have, at most, a single \Important mailbox. The phrase the identity of a user's "\Important" mailbox at the top of page 3 suggests that this is the case but it seems hardly as clear as something should be in an RFC. Pete Maclean From barryleiba.mailing.lists@gmail.com Wed Apr 17 15:08:07 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974001F0D16 for ; Wed, 17 Apr 2013 15:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bp3LViYO+vCa for ; Wed, 17 Apr 2013 15:08:07 -0700 (PDT) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 099E81F0D12 for ; Wed, 17 Apr 2013 15:08:06 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id pb11so1877665veb.39 for ; Wed, 17 Apr 2013 15:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IuVm3ew92JzwdAT+4WH1OXHzNZGsiVH6iH0061gWzUQ=; b=eKf7EY72/5ohu3lsty7kNR4X9a2aaceokXylVQVRul2mNSsSLTf9l57LuASUSiaCEI vE0hhzoqbLqRGNMMi/1buUxs4dGHQFCQRFqL2t2xW8UL29cI0rNzGleTeQ7bviMgVP82 z1+wB4cJk/f5HhcH51tXNlDxc4Ls6S+kRD1YEM5XlVSOqjVmCRWtVmGR43YoxI8RTJb/ h9pdfJxBLPMmz8EdHJj2aq8ekMfHmiMpkBZk1iKke+K4QIN7HYTXnfV4NNawZqcIuJP6 j3pcc6M1l5vA6CoM+GmQ8GJMWxMtjvqj427chH2m8Kf26a25qfouANna8H9LEIFDMF/s TT4A== MIME-Version: 1.0 X-Received: by 10.52.121.112 with SMTP id lj16mr5409426vdb.84.1366236486431; Wed, 17 Apr 2013 15:08:06 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Wed, 17 Apr 2013 15:08:06 -0700 (PDT) In-Reply-To: <20130417214905.B137F21F8B3A@ietfa.amsl.com> References: <20130417214905.B137F21F8B3A@ietfa.amsl.com> Date: Wed, 17 Apr 2013 18:08:06 -0400 X-Google-Sender-Auth: eOHoo1eCxJJiFJpwQAVdpQ83wAk Message-ID: From: Barry Leiba To: Pete Maclean Content-Type: text/plain; charset=ISO-8859-1 Cc: "imapext@ietf.org" Subject: Re: [imapext] New Version Notification for draft-iceman-imap-specialuse-important-02.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 22:08:07 -0000 > I made a pitch before for clarification to be added as to whether a mailbox > flagged as \Important is intended to hold only $Important messages or not. > I see this has not been done and I am wondering why. Does the document make > it clear to others and just not to me? Or is there an intention to leave > this deliberately vague? Hm. You don't think this is clear?: In an implementation that also supports the "$Important" keyword, this special use is likely to represent a virtual mailbox collecting messages (from other mailboxes) that are marked with the "$Important" keyword. This is in the same vein as the descriptions in RFC 6154 of "\Flagged" and "\Drafts". It's "deliberately vague" in the same way: it's suggesting an implementation, but not requiring it. > I also wonder if there is an intention that a > user's mail store should only ever have, at most, a single \Important > mailbox. The phrase > > the identity of a user's "\Important" mailbox > > at the top of page 3 suggests that this is the case but it seems hardly as > clear as something should be in an RFC. Again, from RFC 6154: All of the above attributes are OPTIONAL, and any given server or message store may support any combination of the attributes, or none at all. In most cases, there will likely be at most one mailbox with a given attribute for a given user, but in some server or message store implementations it might be possible for multiple mailboxes to have the same special-use attribute. This attribute is no different to any other attribute in that regard. Barry From alexey.melnikov@isode.com Fri Apr 19 02:00:22 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B1721F92C4 for ; Fri, 19 Apr 2013 02:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.307 X-Spam-Level: X-Spam-Status: No, score=-101.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Gq64D-Ae6wI for ; Fri, 19 Apr 2013 02:00:22 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 41F9F21F8F29 for ; Fri, 19 Apr 2013 02:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1366362018; d=isode.com; s=selector; i=@isode.com; bh=0M073+1Xy1WPdTYWeXfyk1pIBCg4l6wrkSxqpwVSIlc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=rR1Vt9gpF1vNDphB7kH5dA/YIMMM+hLH2o6zWyan3IqV3G/kis0IbnSuJPFPupcrOHHLzj ooGlIOnrU48IT0dtHoPrX034vow8XY5mGGTr08EDGPBRCvPf0+UmVX2CTi/TYUJh3MkQtz RaqJ/z1ekCpFrtd5+WVHGCG6WZq9Eus=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 19 Apr 2013 10:00:17 +0100 Message-ID: <5170420A.6050509@isode.com> Date: Thu, 18 Apr 2013 19:57:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: =?UTF-8?B?SmFuIEt1bmRyw6F0?= References: <1ab91a26-9a10-46cc-8bb4-8609463443fb@flaska.net> In-Reply-To: <1ab91a26-9a10-46cc-8bb4-8609463443fb@flaska.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: imapext@ietf.org Subject: Re: [imapext] GENURLAUTH pipelining X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 09:00:23 -0000 On 17/04/2013 16:03, Jan Kundr=C3=A1t wrote: > Hi, > I've noticed that my code for GENURLAUTH is rather dumb and also quite=20 > buggy -- it breaks when there are multiple GENURLAUTH commands in=20 > flight (yes, it's a serious bug, users sending multiple messages at=20 > once could send wrong ones to wrong senders). What I need to know is a=20 > reliable way of mapping the returned URLs into the commands which=20 > issued them. I suspect this might not be an easy problem to solve,=20 > though. Unlike ESEARCH, the GENURLAUTH contains no tag information to=20 > "tie" it back to the issuing command, so I think that one should=20 > either disable pipelining of GENURLAUTH altogether, or somehow guess=20 > 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=3D" but without > the "::" 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 URLAUTH-authorized URL is generated by taking the initial > URL and appending ":", the URL authorization mechanism name, ":", and > the ASCII-encoded hexadecimal representation of the authorization > token. > > This means "ignore any URLs which do not begin with the string I sent". I think this is right. > However, I can imagine all sorts of transformations a server might=20 > want to perform on the URLs they hand out -- the most trivial is case=20 > mangling for usernames/hostnames/mailboxes, but there are even=20 > harder-to-detect, yet legitimate (?) transformations like using a real=20 > FQDN for a server's hostname. Maybe this needs clarifying in the RFC, but I would expect the server to=20 return the prefix unchanged (or it should refuse to sign it). I suppose you can do case insensitive comparison for the domain part of=20 the URI. > Apart from that, there's also the possibility of some semi-evil=20 > mangling like providing a different UID/UIDVALIDITY/mailbox triplet=20 > which might make a certain level of sense when e.g. dealing with=20 > virtual mailboxes like "[All messages]". > > What is your advise here? > > With kind regards, > Jan > From ned.freed@mrochek.com Fri Apr 19 04:25:13 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E0421F94FF for ; Fri, 19 Apr 2013 04:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjE796stm0sK for ; Fri, 19 Apr 2013 04:25:12 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4763321F94D9 for ; Fri, 19 Apr 2013 04:25:11 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OSNJE2IZ3K00411R@mauve.mrochek.com> for imapext@ietf.org; Fri, 19 Apr 2013 04:20:08 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OSDA15QVCW000054@mauve.mrochek.com>; Fri, 19 Apr 2013 04:20:05 -0700 (PDT) Message-id: <01OSNJE0O5NO000054@mauve.mrochek.com> Date: Fri, 19 Apr 2013 04:15:10 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 18 Apr 2013 19:57:14 +0100" <5170420A.6050509@isode.com> References: <1ab91a26-9a10-46cc-8bb4-8609463443fb@flaska.net> <5170420A.6050509@isode.com> To: Alexey Melnikov Cc: =?UTF-8?B?SmFuIEt1bmRyw6F0?= , imapext@ietf.org Subject: Re: [imapext] GENURLAUTH pipelining X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 11:25:13 -0000 > > One could rely on the strict wording of RFC 4467's Chapter 5: > > > > An initial URL is built, ending with ";URLAUTH=" but without > > the "::" 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 URLAUTH-authorized URL is generated by taking the initial > > URL and appending ":", the URL authorization mechanism name, ":", and > > the ASCII-encoded hexadecimal representation of the authorization > > token. > > > > This means "ignore any URLs which do not begin with the string I sent". > I think this is right. I concur. > > However, I can imagine all sorts of transformations a server might > > want to perform on the URLs they hand out -- the most trivial is case > > mangling for usernames/hostnames/mailboxes, but there are even > > harder-to-detect, yet legitimate (?) transformations like using a real > > FQDN for a server's hostname. > Maybe this needs clarifying in the RFC, but I would expect the server to > return the prefix unchanged (or it should refuse to sign it). > I suppose you can do case insensitive comparison for the domain part of > the URI. Agreed as well. While I guess I could come up with cases where the server might want to return an alternate URL, it's not the model the RFC defines. In particular, the access control and security considerations associated with such a transformation have not been looked at AFAIK. Ned From alexey.melnikov@isode.com Tue Apr 23 09:16:56 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0250021F96E5 for ; Tue, 23 Apr 2013 09:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.981 X-Spam-Level: X-Spam-Status: No, score=-101.981 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUcyvuOoSWEb for ; Tue, 23 Apr 2013 09:16:55 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2160821F96BD for ; Tue, 23 Apr 2013 09:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1366733813; d=isode.com; s=selector; i=@isode.com; bh=hBce+sn0j9uBsaM6MlOGUDq2DeAnBG4257ocYuVULn0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=COZzSbKUVI03WraKmqeAgOymWP95XSkC0srNxw648dx7Ugm1J6wD/+kJffZfuV9XU/GoHE 4SfhOK6gHJdeuEb0sLYIgqdkkWJPCFuveHp7oqKdkDA8H6sipZoNrIXr7YnWEqD5Wbwrt0 se5I3OIlAD7licRZzatp4n4DJKES3bU=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 23 Apr 2013 17:16:53 +0100 Message-ID: <5176B3F6.7000503@isode.com> Date: Tue, 23 Apr 2013 17:16:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: "imapext@ietf.org" References: <20130423161230.28695.18755.idtracker@ietfa.amsl.com> In-Reply-To: <20130423161230.28695.18755.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130423161230.28695.18755.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------030909050905030202060807" Subject: [imapext] Fwd: I-D Action: draft-melnikov-rfc2088bis-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 16:16:56 -0000 This is a multi-part message in MIME format. --------------030909050905030202060807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I've decided to start on update to LITERAL+ based on the recent mailing list discussion. Please let me know what you think. -------- Original Message -------- Subject: I-D Action: draft-melnikov-rfc2088bis-00.txt Date: Tue, 23 Apr 2013 09:12:30 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IMAP4 non-synchronizing literals Author(s) : John G. Myers Alexey Melnikov Filename : draft-melnikov-rfc2088bis-00.txt Pages : 5 Date : 2013-04-23 Abstract: The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal which does not require this network round trip. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-melnikov-rfc2088bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-melnikov-rfc2088bis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --------------030909050905030202060807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,
I've decided to start on update to LITERAL+ based on the recent mailing list discussion. Please let me know what you think.

-------- Original Message --------
Subject: I-D Action: draft-melnikov-rfc2088bis-00.txt
Date: Tue, 23 Apr 2013 09:12:30 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 

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


	Title           : IMAP4 non-synchronizing literals
	Author(s)       : John G. Myers
                          Alexey Melnikov
	Filename        : draft-melnikov-rfc2088bis-00.txt
	Pages           : 5
	Date            : 2013-04-23

Abstract:
   The Internet Message Access Protocol (RFC 3501) contains the
   "literal" syntactic construct for communicating strings.  When
   sending a literal from client to server, IMAP requires the client to
   wait for the server to send a command continuation request between
   sending the octet count and the string data.  This document specifies
   an alternate form of literal which does not require this network
   round trip.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-melnikov-rfc2088bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-melnikov-rfc2088bis-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
--------------030909050905030202060807-- From dkarp@zimbra.com Tue Apr 23 09:22:53 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1AA21F96FA for ; Tue, 23 Apr 2013 09:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvOXNsfbZdmJ for ; Tue, 23 Apr 2013 09:22:52 -0700 (PDT) Received: from edge01-zcs.vmware.com (edge01-zcs.vmware.com [208.91.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id B87A421F969F for ; Tue, 23 Apr 2013 09:22:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by edge01-zcs.vmware.com (Postfix) with ESMTP id 629DA4A0C; Tue, 23 Apr 2013 09:22:51 -0700 (PDT) Received: from edge01-zcs.vmware.com ([127.0.0.1]) by localhost (edge01-zcs.vmware.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id NgMkiQDQ8-mY; Tue, 23 Apr 2013 09:22:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by edge01-zcs.vmware.com (Postfix) with ESMTP id 77BAD4F02; Tue, 23 Apr 2013 09:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at edge01-zcs.vmware.com Received: from edge01-zcs.vmware.com ([127.0.0.1]) by localhost (edge01-zcs.vmware.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id h54-rsk6IDGv; Tue, 23 Apr 2013 09:22:41 -0700 (PDT) Received: from mbs01-zcs.vmware.com (mbs01-zcs.vmware.com [10.113.162.14]) by edge01-zcs.vmware.com (Postfix) with ESMTP id 57EDE4A0C; Tue, 23 Apr 2013 09:22:41 -0700 (PDT) Date: Tue, 23 Apr 2013 09:22:40 -0700 (PDT) From: Dan Karp To: Alexey Melnikov Message-ID: <83544432.40701.1366734160986.JavaMail.zimbra@zimbra.com> In-Reply-To: <5176B3F6.7000503@isode.com> References: <20130423161230.28695.18755.idtracker@ietfa.amsl.com> <5176B3F6.7000503@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.4_GA_5706 (ZimbraWebClient - GC26 (Mac)/8.0.4_GA_5706) Thread-Topic: I-D Action: draft-melnikov-rfc2088bis-00.txt Thread-Index: Lm1UrkSkVLVarv1iXvpoVaL4xx7Hag== Cc: imapext@ietf.org Subject: Re: [imapext] Fwd: I-D Action: draft-melnikov-rfc2088bis-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 16:22:53 -0000 > I've decided to start on update to LITERAL+ based on the recent mailing list > discussion. Please let me know what you think. I think that if you're revising LITERAL+, it might not be a bad idea to set a hard cap on both the size of a single LITERAL+ literal and the number of LITERAL+ literals permissible in a single command. - Dan From alexey.melnikov@isode.com Tue Apr 23 10:02:22 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B2C21F9704 for ; Tue, 23 Apr 2013 10:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.136 X-Spam-Level: X-Spam-Status: No, score=-102.136 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1MJTeivgEx3 for ; Tue, 23 Apr 2013 10:02:21 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id D859021F9703 for ; Tue, 23 Apr 2013 10:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1366736540; d=isode.com; s=selector; i=@isode.com; bh=G26eHg7Siuf9AWGeLO9vyeQgk5MDWssZ583Xuo0L4ts=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Hk15geZ6RqsKBCoEi43BFEwau1K2G/32j0LvBv9pWDnP70M+w5phbUP+KSu1gQRV9S6xAi gOMXIj0wEt/sm6cjpeqyYSIR6F13nB76WokwhikuuYjFKDBuKO1tXvEUQVSogbx144mBDq TYPsrtt/1/oa5HagaGENbOtQWwuRK5Q=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 23 Apr 2013 18:02:19 +0100 Message-ID: <5176BE9D.5050108@isode.com> Date: Tue, 23 Apr 2013 18:02:21 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Dan Karp References: <20130423161230.28695.18755.idtracker@ietfa.amsl.com> <5176B3F6.7000503@isode.com> <83544432.40701.1366734160986.JavaMail.zimbra@zimbra.com> In-Reply-To: <83544432.40701.1366734160986.JavaMail.zimbra@zimbra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imapext@ietf.org Subject: Re: [imapext] Fwd: I-D Action: draft-melnikov-rfc2088bis-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 17:02:22 -0000 On 23/04/2013 17:22, Dan Karp wrote: >> I've decided to start on update to LITERAL+ based on the recent mailing list >> discussion. Please let me know what you think. > I think that if you're revising LITERAL+, it might not be a bad idea to set > a hard cap on both the size of a single LITERAL+ literal and the number of > LITERAL+ literals permissible in a single command. I don't think we can retroactively introduce the limit for all implementations. We can however add a new capability (or something similar) for advertising limits for implementations that want to enforce them. (And this is one of my ToDo items). We can of course add recommendations about minimal limits, etc. But these should not break existing implementations, IMHO. From tss@iki.fi Tue Apr 23 10:08:44 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B666821F9675 for ; Tue, 23 Apr 2013 10:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUa5wpQkLcKF for ; Tue, 23 Apr 2013 10:08:44 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id E505D21F9679 for ; Tue, 23 Apr 2013 10:08:43 -0700 (PDT) Received: from [10.217.1.157] (unknown [194.157.98.74]) by dovecot.org (Postfix) with ESMTP id 581201AE87EC; Tue, 23 Apr 2013 20:08:42 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Timo Sirainen In-Reply-To: <5176BE9D.5050108@isode.com> Date: Tue, 23 Apr 2013 20:08:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <987E7FE1-E453-4B12-B83D-4C37748B9FBB@iki.fi> References: <20130423161230.28695.18755.idtracker@ietfa.amsl.com> <5176B3F6.7000503@isode.com> <83544432.40701.1366734160986.JavaMail.zimbra@zimbra.com> <5176BE9D.5050108@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1503) Cc: imapext@ietf.org, Dan Karp Subject: Re: [imapext] I-D Action: draft-melnikov-rfc2088bis-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 17:08:44 -0000 On 23.4.2013, at 20.02, Alexey Melnikov = wrote: > On 23/04/2013 17:22, Dan Karp wrote: >>> I've decided to start on update to LITERAL+ based on the recent = mailing list >>> discussion. Please let me know what you think. >> I think that if you're revising LITERAL+, it might not be a bad idea = to set >> a hard cap on both the size of a single LITERAL+ literal and the = number of >> LITERAL+ literals permissible in a single command. > I don't think we can retroactively introduce the limit for all = implementations. We can however add a new capability (or something = similar) for advertising limits for implementations that want to enforce = them. (And this is one of my ToDo items). >=20 > We can of course add recommendations about minimal limits, etc. But = these should not break existing implementations, IMHO. Any hardcoded limits (or recommendations) will become outdated in a few = years. At some point I'm sure people would rather waste sending 1GB of = traffic than wait for the latency roundtrip. From dkarp@zimbra.com Tue Apr 23 11:25:33 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300E321F86D9 for ; Tue, 23 Apr 2013 11:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDLKJ+D3issy for ; Tue, 23 Apr 2013 11:25:32 -0700 (PDT) Received: from edge02-zcs.vmware.com (edge02-zcs.vmware.com [208.91.2.23]) by ietfa.amsl.com (Postfix) with ESMTP id 158ED21F965E for ; Tue, 23 Apr 2013 11:25:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by edge02-zcs.vmware.com (Postfix) with ESMTP id 98CA87558; Tue, 23 Apr 2013 11:25:25 -0700 (PDT) Received: from edge02-zcs.vmware.com ([127.0.0.1]) by localhost (edge02-zcs.vmware.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id vEgniKjEbYkv; Tue, 23 Apr 2013 11:25:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by edge02-zcs.vmware.com (Postfix) with ESMTP id A68D7754D; Tue, 23 Apr 2013 11:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at edge02-zcs.vmware.com Received: from edge02-zcs.vmware.com ([127.0.0.1]) by localhost (edge02-zcs.vmware.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LWnMlNi76trX; Tue, 23 Apr 2013 11:25:15 -0700 (PDT) Received: from mbs01-zcs.vmware.com (mbs01-zcs.vmware.com [10.113.162.14]) by edge02-zcs.vmware.com (Postfix) with ESMTP id 7D8B2657D; Tue, 23 Apr 2013 11:25:15 -0700 (PDT) Date: Tue, 23 Apr 2013 11:25:14 -0700 (PDT) From: Dan Karp To: Timo Sirainen Message-ID: <1718757010.61888.1366741514919.JavaMail.zimbra@zimbra.com> In-Reply-To: <987E7FE1-E453-4B12-B83D-4C37748B9FBB@iki.fi> References: <20130423161230.28695.18755.idtracker@ietfa.amsl.com> <5176B3F6.7000503@isode.com> <83544432.40701.1366734160986.JavaMail.zimbra@zimbra.com> <5176BE9D.5050108@isode.com> <987E7FE1-E453-4B12-B83D-4C37748B9FBB@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.4_GA_5706 (ZimbraWebClient - GC26 (Mac)/8.0.4_GA_5706) Thread-Topic: I-D Action: draft-melnikov-rfc2088bis-00.txt Thread-Index: ziF+NQSzG0mRzppfMNSw3HGKp75VDQ== Cc: Alexey Melnikov , imapext@ietf.org Subject: Re: [imapext] I-D Action: draft-melnikov-rfc2088bis-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 18:25:33 -0000 > Any hardcoded limits (or recommendations) will become outdated in a few > years. At some point I'm sure people would rather waste sending 1GB of > traffic than wait for the latency roundtrip. If we're trying to clarify the original RFC, it's better to make the constraints on non-synchronizing literals explicit. A client may be fine sending an extra 1GB of data... or it might not. Likewise for a server. It seems like a good idea to give client authors enough context that they don't make the mistake of sending a too-large LITERAL+ literal in the first place. If we want to draw the line between non-synchronizing literals for commands and non-synchronizing literals for data, I don't see a problem with setting a hard upper limit for non-synchronizing literal size in the RFC. If we don't want to draw such a line, then perhaps an untagged response (e.g. "* [MAXLITERAL 10000000]") sent upon authentication. But we really should tell the client what the limits are. - Dan From slusarz@horde.org Tue Apr 23 12:18:14 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5922921F976A for ; Tue, 23 Apr 2013 12:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kow04S+D3Zw for ; Tue, 23 Apr 2013 12:18:13 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id B937521F9778 for ; Tue, 23 Apr 2013 12:18:13 -0700 (PDT) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta01.emeryville.ca.mail.comcast.net with comcast id TRKl1l00x0b6N64A1XJ7kP; Tue, 23 Apr 2013 19:18:07 +0000 Received: from bigworm.curecanti.org ([71.229.167.0]) by omta03.emeryville.ca.mail.comcast.net with comcast id TXJ51l00900qwSn8PXJ5Vn; Tue, 23 Apr 2013 19:18:06 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) (Authenticated sender: slusarz) by bigworm.curecanti.org (Postfix) with ESMTPSA id A483868075 for ; Tue, 23 Apr 2013 13:18:04 -0600 (MDT) Received: from schrute.curecanti.org (schrute.curecanti.org [172.18.5.4]) by bigworm.curecanti.org (Horde Framework) with HTTP; Tue, 23 Apr 2013 13:18:04 -0600 Date: Tue, 23 Apr 2013 13:18:04 -0600 Message-ID: <20130423131804.Horde.4Ti2FtSlqX0L1kvp3eEn8Q1@bigworm.curecanti.org> From: Michael M Slusarz To: imapext@ietf.org References: <20130423161230.28695.18755.idtracker@ietfa.amsl.com> <5176B3F6.7000503@isode.com> <83544432.40701.1366734160986.JavaMail.zimbra@zimbra.com> <5176BE9D.5050108@isode.com> <987E7FE1-E453-4B12-B83D-4C37748B9FBB@iki.fi> <1718757010.61888.1366741514919.JavaMail.zimbra@zimbra.com> In-Reply-To: <1718757010.61888.1366741514919.JavaMail.zimbra@zimbra.com> User-Agent: Internet Messaging Program (IMP) H5 (6.1.0-git) Accept-Language: en X-Originating-IP: 172.18.5.4 X-Remote-Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366744687; bh=zI0PTsWnEdLWD2rkSaNlvAcrHVzjaoF2mFcClyc2v3w=; h=Received:Received:Received:Received:Date:Message-ID:From:To: Subject:Content-Type:MIME-Version; b=C12B2z26B8qXiGjIu/nw46QwZa8t9bvN3RoqmSzsFx/o6hl4K84uTjU1mJTrPZyKa vBeDuGFsispooYCZ7eQoYXBtZH8sLG5ksbjZyI1Cy67P6VkpiUQwtES/DAIR9nC450 RVEhmjh9WIXKGcYqJkvmypFGti5fpCUOQvNzCUViS2imipu4HgyPLunqDR46s9cevI zxsr3F0/v6jL1Ubuy5yGCb2lAe7wfoOoj9fKFfmSIc+e/Yt8TV6HI5FxdmEFqzWEv7 Eln6EeUTwi1v5d+kPkOHM8tcZJ58OLOAzSk4gJBzxRbTMfOTAAlTDkKqB6qHOkb1Do RqMMEbK/+splQ== Subject: Re: [imapext] I-D Action: draft-melnikov-rfc2088bis-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 19:18:14 -0000 Quoting Dan Karp : >> Any hardcoded limits (or recommendations) will become outdated in a few >> years. At some point I'm sure people would rather waste sending 1GB of >> traffic than wait for the latency roundtrip. > > If we're trying to clarify the original RFC, it's better to make the > constraints on non-synchronizing literals explicit. A client may be > fine sending an extra 1GB of data... or it might not. Likewise for a > server. It seems like a good idea to give client authors enough context > that they don't make the mistake of sending a too-large LITERAL+ literal > in the first place. > > If we want to draw the line between non-synchronizing literals for > commands and non-synchronizing literals for data, I don't see a problem > with setting a hard upper limit for non-synchronizing literal size in > the RFC. If we don't want to draw such a line, then perhaps an untagged > response (e.g. "* [MAXLITERAL 10000000]") sent upon authentication. 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 server's maximum allowable command size. michael ___________________________________ Michael Slusarz [slusarz@horde.org] From adrien@qbik.com Tue Apr 23 15:15:30 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF9121F91CA for ; Tue, 23 Apr 2013 15:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWTKQF3Iglhd for ; Tue, 23 Apr 2013 15:15:29 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2549521F9399 for ; Tue, 23 Apr 2013 15:15:29 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v8.0.0 (Build 4539)) with SMTP id <0019669036@smtp.qbik.com>; Wed, 24 Apr 2013 10:15:27 +1200 From: "Adrien W. de Croy" To: "Michael M Slusarz" , "imapext@ietf.org" Date: Tue, 23 Apr 2013 22:15:26 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <20130423131804.Horde.4Ti2FtSlqX0L1kvp3eEn8Q1@bigworm.curecanti.org> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.17595.0 Subject: Re: [imapext] I-D Action: draft-melnikov-rfc2088bis-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 22:15:30 -0000 while we're talking about such things, we should revisit the hard-limit=20 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=20 threshold, so can go as large as there is free disk space. It would be=20 more work to figure out a limit to advertise than it's worth for us, so=20 lack of advertisement should mean no restriction. Until there is some sort of append / catenate there's no opportunity to=20 split the literals up anyway. Adrien ------ Original Message ------ From: "Michael M Slusarz" To: "imapext@ietf.org" Sent: 24/04/2013 7:18:04 a.m. Subject: Re: [imapext] I-D Action: draft-melnikov-rfc2088bis-00.txt >Quoting Dan Karp : > >>>Any hardcoded limits (or recommendations) will become outdated in a=20 >>>few >>>years. At some point I'm sure people would rather waste sending 1GB=20 >>>of >>>traffic than wait for the latency roundtrip. >> >>If we're trying to clarify the original RFC, it's better to make the >>constraints on non-synchronizing literals explicit. A client may be >>fine sending an extra 1GB of data... or it might not. Likewise for a >>server. It seems like a good idea to give client authors enough=20 >>context >>that they don't make the mistake of sending a too-large LITERAL+=20 >>literal >>in the first place. >> >>If we want to draw the line between non-synchronizing literals for >>commands and non-synchronizing literals for data, I don't see a=20 >>problem >>with setting a hard upper limit for non-synchronizing literal size in >>the RFC. If we don't want to draw such a line, then perhaps an=20 >>untagged >>response (e.g. "* [MAXLITERAL 10000000]") sent upon authentication. > >I'm with Timo that I don't think there should be hardcoded limits=20 >within the RFC itself. But I agree with you, and I don't think Timo is=20 >arguing otherwise, that a server can, and most likely should, advertise= =20 >limits on what it will accept. The latter allows the data limitations=20 >to be scaled to whatever resource constraints exist in the future (say:= =20 >802.11zzz connections, with 5000 Gb/s bandwidth). And if a server wants= =20 >to accept gigabytes of data, more power to it - that is their design=20 >choice and they shouldn't be prevented from doing so. > >I think if we are going to announce limits, then it makes sense to=20 >advertise separate limits for >1) APPEND data and >2) everything else. > >The latter would aid clients in determining the maximum command size=20 >allowed on a server, rather than the nebulous "shouldn't send more than= =20 >1000 octets" we currently have in RFC 2683 -- the=20 >assumption/requirement being that the literal command limit should be=20 >equal to a server's maximum allowable command size. > >michael > >___________________________________ >Michael Slusarz [slusarz@horde.org] > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext From johnsonhammond2@hushmail.com Sat Apr 27 09:52:53 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD4221F982D for ; Sat, 27 Apr 2013 09:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSOjFT2BrPMb for ; Sat, 27 Apr 2013 09:52:53 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by ietfa.amsl.com (Postfix) with ESMTP id 6075121F9742 for ; Sat, 27 Apr 2013 09:52:53 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id 653271B5302 for ; Sat, 27 Apr 2013 16:51:05 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp10.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 16:51:05 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 271B214DBDE; Sat, 27 Apr 2013 16:51:05 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 12:51:04 -0400 To: imapext@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427165105.271B214DBDE@smtp.hushmail.com> Subject: [imapext] Biggest Fake Conference in Computer Science X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:23:40 -0000 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 any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From iesg-secretary@ietf.org Mon Apr 29 10:39:22 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2805321F9A78; Mon, 29 Apr 2013 10:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.34 X-Spam-Level: X-Spam-Status: No, score=-102.34 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuGQnJdChF-V; Mon, 29 Apr 2013 10:39:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F24E21F9A7C; Mon, 29 Apr 2013 10:39:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130429173920.23855.7303.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2013 10:39:20 -0700 Cc: qresync WG Subject: [imapext] WG Action: Formed IMAP QRESYNC Extension (qresync) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 17:39:22 -0000 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 Eliot Lear Assigned Area Director: Barry Leiba Mailing list Address: imapext@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 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. The IMAP QRESYNC extension (RFC 5162) extends CONDSTORE to also cover expunged messages, and reduces the number of round trips needed to resynchronize by extending the SELECT/EXAMINE command. The CONDSTORE and QRESYNC extensions are deployed in both clients and servers. These deployments have exposed errors and clarity issues in the specifications, and they need correcting. The IMAP QRESYNC Extension working group has the task of updating CONDSTORE and QRESYNC extensions on the Standards Track. The working group might produce one (combined) or two separate documents (as now) updating these extensions. The working group will review errata and update the documents as needed to incorporate those, and will correct significant errors and inconsistencies, but will keep changes at this stage to a minimum and avoid incompatible changes. No other IMAP extension work is in scope for this working group. Milestones: Dec 2013 - Request publication on updated qresync/condstore spec(s) From lear@cisco.com Mon Apr 29 10:58:05 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388E921F9ACE for ; Mon, 29 Apr 2013 10:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQH1wApqzmsr for ; Mon, 29 Apr 2013 10:58:00 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7E91321F9ACB for ; Mon, 29 Apr 2013 10:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2925; q=dns/txt; s=iport; t=1367258280; x=1368467880; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=WmfOt+Vap0bR1UYyhrtbh8pjufR5uSY4X/DGr/Hsxrc=; b=W+SelNLxftB7BT3PgVgCKKaZ9MHLyudqFVb63vEY2NlEAuw2RGidzMtY O1yEwFJQFHEvh6XDXgWCSfHoz9sOYXjL9zAMdf4oXqFZ4FdWZulCC93Zf iV/UUguPHlfOjei41HwlX5fKj9IPvNBC9kPAJY/V2Oi95W2VDcReQ6b6p w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAaABi0flGQ/khN/2dsb2JhbABTgW8GAYERNoM3uwyBBhZ0gh8BAQEEAQEBIEsGFQsYAgIFAx4CAg8CFhYaBg0GAgEBBYgNDKwfkEKBI4wrCQEPAYE5gjyBEwOTT4NPkSqDEzqBNw X-IronPort-AV: E=Sophos;i="4.87,575,1363132800"; d="scan'208";a="153460103" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 29 Apr 2013 17:57:59 +0000 Received: from mctiny.local ([10.61.213.131]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3THvu5o005942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Apr 2013 17:57:57 GMT Message-ID: <517EB4A4.40603@cisco.com> Date: Mon, 29 Apr 2013 19:57:56 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: qresync WG References: <20130429173920.23855.7303.idtracker@ietfa.amsl.com> In-Reply-To: <20130429173920.23855.7303.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [imapext] WG Action: Formed IMAP QRESYNC Extension (qresync) X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 17:58:05 -0000 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: > 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 > Eliot Lear > > Assigned Area Director: > Barry Leiba > > Mailing list > Address: imapext@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 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. The IMAP > QRESYNC extension (RFC 5162) extends CONDSTORE to also cover expunged > messages, and reduces the number of round trips needed to resynchronize > by extending the SELECT/EXAMINE command. > > The CONDSTORE and QRESYNC extensions are deployed in both clients and > servers. These deployments have exposed errors and clarity issues in > the specifications, and they need correcting. The IMAP QRESYNC > Extension working group has the task of updating CONDSTORE and QRESYNC > extensions on the Standards Track. > > The working group might produce one (combined) or two separate documents > (as now) updating these extensions. The working group will review errata > and update the documents as needed to incorporate those, and will > correct significant errors and inconsistencies, but will keep changes at > this stage to a minimum and avoid incompatible changes. > > No other IMAP extension work is in scope for this working group. > > Milestones: > Dec 2013 - Request publication on updated qresync/condstore spec(s) > > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext > >