From alexey.melnikov@isode.com Sat Nov 2 15:00: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 1B95E21E8106 for ; Sat, 2 Nov 2013 15:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 ht50UARCvwhm for ; Sat, 2 Nov 2013 15:00:43 -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 0D48B21E80E6 for ; Sat, 2 Nov 2013 15:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1383429641; d=isode.com; s=selector; i=@isode.com; bh=PjjmTo3yHYcsdEGcMXjlmwK8e83wDv7+l3O25rRwXRo=; 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=exHEAdcwH/MTGoN+IyYFXzz6+rpB0paXGEOMpaUPLBDvonx+IpuOScaQrlXvzg77C0aivi yxzh3+Ni8f4KSOTnOAhBgNNkl9hU51/CyLfe8v0rutGyI0yKlxNMVQkWFQXBCvT09cgFD7 ZnX2CmYyoDZsu9FHScvCVEXvRKlIFc8=; Received: from [172.16.0.7] ((unknown) [184.69.150.122]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 2 Nov 2013 22:00:40 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING Message-ID: <52757603.2030702@isode.com> Date: Sat, 02 Nov 2013 15:00:35 -0700 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Chris Newman References: <1378803519.64574.YahooMailNeo@web190602.mail.sg3.yahoo.com> <522EF253.4070607@isode.com> <1378818642.2785.YahooMailNeo@web190604.mail.sg3.yahoo.com> <967C0899554A5377C0C16597@nifty-silver.us.oracle.com> <920FE75F-A0C2-49F8-96A6-466F98C1C6EB@iki.fi> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Cyrus Daboo , Timo Sirainen , Nigar Sultana , imapext@ietf.org Subject: [imapext] IMAP UNAUTHENTICATE (was Re: RFC 3501 - IMAP CREATE) 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, 02 Nov 2013 22:00:44 -0000 Hi Chris, On 22/10/2013 21:54, Chris Newman wrote: > --On October 21, 2013 23:14:00 +0300 Timo Sirainen wrote: >> On 21.10.2013, at 23.02, Chris Newman wrote: >>> I just submitted a draft describing the mechanism we've used for >>> this scenario: >>> >> ... >> Seems a bit scary extension to me. > > LDAP has UNBIND in the base specification. I think UNAUTHENTICATE is > only 'scary' because I bothered to think through the security > implications and write them down. Indeed. I like your draft, as it spells out pretty much everything. >> I'm going to try to avoid implementing >> it, although I guess there could be a time when someone really really >> wants it. But perhaps at that point it would be better to use something >> else entirely than IMAP. > > I'm proposing this as an extension that's useful for the > server-acting-on-behalf-of scenario. I don't think every IMAP server > should implement it; only those that need it. Of course if my server > is the only implementation then there's no point going standards > track. Is anyone else interested in implementing this? I nearly implemented this a couple of years ago. I might revisit this. One comment about the draft: I am not sure about SASL security layer termination on UNAUTHENTICATE, but this is a minor point, considering that they are not used very often. > If you're interested in traffic isolation, I've been contemplating the > idea of running IMAP on two ports with different behaviors -- an > end-user port and an admin port. If I do that, in addition to having > UNAUTHENTICATE only on the admin port, I'd make SASL-admin-proxy > authentication only work on the admin imap port. If the admin imap > port is blocked at the firewall, that's better security then doing > everything on 143/993. I'm thinking of mentioning this as a mitigation > in the security considerations. Any thoughts on whether it would be > helpful to register a well-known port for admin imap? This might be a good idea. [...] > --On October 21, 2013 16:29:25 -0400 Cyrus Daboo wrote: >> Would it be reasonable to require the authentication after an >> UNAUTHENTICATE to use the same "authentication identifier" as was >> used in >> the original authentication? i.e. it is OK to change the authorization >> identity within the same connected IMAP session, but it is not OK to >> change the authentication identity? I think that covers the main use >> case >> whilst adding a little more security. > > That makes the security model more complex and increases the size of > the security sensitive code (thus increasing the attack surface). I'd > then have to save the identity information between authentication > session contexts, provide a way to pass in previous-identity > information, and provide behavior variations based on > previous-identity information. It adds some new rather complex test > cases. I'm not a fan of this idea. I don't like it either. >> Also, I would imagine servers would have a config option to only enable >> UNAUTHENTICATE once authentication has been done, and the authenticated >> user is a known "trusted" user (i.e., one of the admin accounts). >> Certainly allowing UNAUTHENTICATE for "arbitrary" users would be >> scarier. > > This is an excellent idea. The code to do this is all > post-authentication so there's no impact to the primary attack > surface. I'll add it to the next version of the specification. From lear@cisco.com Thu Nov 21 10:01:42 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F7D1AE0EF for ; Thu, 21 Nov 2013 10:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ki6kk8zBg7Gz for ; Thu, 21 Nov 2013 10:01:41 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3EF1AE1E0 for ; Thu, 21 Nov 2013 10:01:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=396; q=dns/txt; s=iport; t=1385056894; x=1386266494; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=MtHphTNXXtgEqhyJ27aVcS+SFHec2Obbv8pZ38k3afM=; b=X6P4TqIiaMT9jx8pNIzs4obbO+xspmObmpiWyR3vrZci7Dqn+j0Qae86 VGU/m163CCa49nbZ+4lIjx0zv+uc2VBrnilE5ugK1HboxLFHAcDyU4CoH hf6Nn4Gh5CB8JBgMJ8b+g1fMPsor8175dq74Fe2Irx4U96eVe+Int7Vd0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAHJJjlKQ/khR/2dsb2JhbABZgweEA7sDFnSCT1U2AgUWCwILAwIBAgFLDQgBAYd9oROPCJEKF4EpkTSBRwOYEpIQgWqBPzs X-IronPort-AV: E=Sophos;i="4.93,746,1378857600"; d="scan'208";a="381366" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 21 Nov 2013 18:01:33 +0000 Received: from ams3-vpn-dhcp1864.cisco.com (ams3-vpn-dhcp1864.cisco.com [10.61.71.72]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rALI1RfO020698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Nov 2013 18:01:29 GMT Message-ID: <528E4A77.9060006@cisco.com> Date: Thu, 21 Nov 2013 19:01:27 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: qresync WG X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [imapext] preparing shepherd write-up for draft-ietf-qresync-rfc5162bis-03.txt: are you implementing? X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 18:01:42 -0000 Dear IMAP folk, As I prepare the shepherd write-up, one of the questions I must answer is whether or not there are implementations. Can you please reply to this message if you (a) have implemented QRESYNC or CONDSTORE as specified in the document or (b) are planning to do so in the near future? Also, this is a very good time to take another look at the document. Thanks, Eliot From lear@cisco.com Thu Nov 21 10:35:01 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB781AE23F for ; Thu, 21 Nov 2013 10:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q718RHjTKevS for ; Thu, 21 Nov 2013 10:35:00 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3651A1ADFEF for ; Thu, 21 Nov 2013 10:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1396; q=dns/txt; s=iport; t=1385058894; x=1386268494; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=wohCOPyLO5U0rsG64Fq6YKtdAaHdVzhuYN6/Ojqp9dk=; b=CoxopUOiKO1cwmzxJz4qu2eiFhx+DSI51AC7mVSbCIKirZk/raQiaecb GBS07Dp9xvO2TuQuSP846avJkMcjf1gKZ7hN46t8CJ78Wb2XU4frG2YE8 Th47/XSzk8LBUXfWMdx5dsD24XrpXiXK6R/W0x7Pt5+FmVQxaGw1tnIk2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAK1RjlKQ/khM/2dsb2JhbABTBoMHhAO6exZ0giUBAQEDJFUGMAIFFgsCCwMCAQIBSwEMCAEBh3cGsB6RH4EpjRWEH4FHA5gSkhCDKTs X-IronPort-AV: E=Sophos;i="4.93,746,1378857600"; d="scan'208";a="383282" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 21 Nov 2013 18:34:53 +0000 Received: from ams3-vpn-dhcp1864.cisco.com (ams3-vpn-dhcp1864.cisco.com [10.61.71.72]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rALIYkdf002819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Nov 2013 18:34:48 GMT Message-ID: <528E5246.4040506@cisco.com> Date: Thu, 21 Nov 2013 19:34:46 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: qresync WG , Alexey Melnikov , Dave Cridland X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [imapext] Shepherd review of draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 18:35:02 -0000 Dear Alexey & Dave, Here is my review for draft-ietf-qresync-rfc5162bis-03.txt as it stands. Note that I realize that you are merging two documents. The result still needs to read as a single document. The introduction does not. Also, it is unusual to have normative language in the introduction, and in the 2nd sentence to boot. You've put the motivation for the work on the bottom of page 4 and into page 5. Please move that up to the top. Make clear the difference without the extension in use and then with. > Mod-sequences allow a client that supports the CONDSTORE extension to > determine if a message metadata has changed since some known moment. Please explain why this is important. 3.1. syntax: is the word SEARCH missing from the front? Minor issues The abstract is too long. Much of the content belongs in the introduction. Use of system clock could be allowed so long as a check is made to insure that the value is guaranteed to increase. For example: if ((mod_sequence=clock()) <=last_mod_sequence) { mod_sequence=last_mod_sequence+1; } Your reference to RFC1305 should probably be RFC5905. Please check other references for similar updates since RFC5162. Can you please confirm with me that you have (re)tested the examples to make sure they're accurate? I've checked the ABNF and it looks good. Eliot From groups@maclean.com Thu Nov 21 18:46:55 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440F61ADED6 for ; Thu, 21 Nov 2013 18:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.297 X-Spam-Level: * X-Spam-Status: No, score=1.297 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITz6rLeoincS for ; Thu, 21 Nov 2013 18:46:53 -0800 (PST) Received: from cs8-dallas.accountservergroup.com (cs8-dallas.accountservergroup.com [108.174.144.176]) by ietfa.amsl.com (Postfix) with ESMTP id 979CD1AC7F3 for ; Thu, 21 Nov 2013 18:46:53 -0800 (PST) Received: from pool-96-235-209-118.lyncva.east.verizon.net ([96.235.209.118]:50156 helo=Samsung-RF711.maclean.com) by cs8-dallas.accountservergroup.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Vjgla-0000bz-0Y; Fri, 22 Nov 2013 02:46:46 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 21 Nov 2013 21:46:36 -0500 To: Eliot Lear ,qresync WG From: Pete Maclean In-Reply-To: <528E4A77.9060006@cisco.com> References: <528E4A77.9060006@cisco.com> 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 X-Get-Message-Sender-Via: cs8-dallas.accountservergroup.com: authenticated_id: pete+maclean.com/only user confirmed/virtual account not confirmed Subject: Re: [imapext] preparing shepherd write-up for draft-ietf-qresync-rfc5162bis-03.txt: are you implementing? X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 02:46:55 -0000 I have implemented both CONDSTORE and QRESYNC. The former is thoroughly tested and in release. The latter is rough and may not be released for some time. Please excuse me if I have missed something but could you please tell me what this shepherd write-up is. Pete Maclean At 01:01 PM 11/21/2013, Eliot Lear wrote: >Dear IMAP folk, > >As I prepare the shepherd write-up, one of the questions I must answer >is whether or not there are implementations. Can you please reply to >this message if you (a) have implemented QRESYNC or CONDSTORE as >specified in the document or (b) are planning to do so in the near future? > >Also, this is a very good time to take another look at the document. > >Thanks, > >Eliot >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext From lear@cisco.com Fri Nov 22 00:06:50 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557031AE30F for ; Fri, 22 Nov 2013 00:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.512 X-Spam-Level: X-Spam-Status: No, score=-8.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAcV_6Wsw3UE for ; Fri, 22 Nov 2013 00:06:48 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5F81A1F7B for ; Fri, 22 Nov 2013 00:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1380; q=dns/txt; s=iport; t=1385107601; x=1386317201; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=P1OENZjcdRkB/snyGP3jnXcSkGh6v94KlZGjlOQrYgg=; b=FIuE1Q/pLzmOjgNoUFrrCcwZTl2u30jyLW7JLmhmKy2zAgZNtRKXs4sa 0j2C8+KakanUln6OyE7XIPDK7M0Dny84NrlvKzQj5kmIu3XW9Foore4b5 uELShjd76GDysApvDQMHNxbm3FM6MkUtK9PBjo/TYaWfLBew64uzePhSj Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFACsQj1KQ/khR/2dsb2JhbABZgwc4g0u4R06BHxZ0giUBAQEEAQEBIEsbCw4KAgIFGgcCAg8CFjAGAQwGAgEBh30NsBWRDRMEgSmNX4JrgUcDmBOSEIFqgT87 X-IronPort-AV: E=Sophos;i="4.93,750,1378857600"; d="scan'208";a="1070566" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 22 Nov 2013 08:06:40 +0000 Received: from ams3-vpn-dhcp4249.cisco.com (ams3-vpn-dhcp4249.cisco.com [10.61.80.152]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAM86UvJ030357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Nov 2013 08:06:32 GMT Message-ID: <528F1086.40707@cisco.com> Date: Fri, 22 Nov 2013 09:06:30 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Pete Maclean , qresync WG References: <528E4A77.9060006@cisco.com> <20131122024658.341221AC7F3@ietfa.amsl.com> In-Reply-To: <20131122024658.341221AC7F3@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [imapext] preparing shepherd write-up for draft-ietf-qresync-rfc5162bis-03.txt: are you implementing? X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 08:06:50 -0000 A shepherd write-up is part of the process by which the IESG evaluates the quality of a document. Knowing that there is rough consensus and running code is both part of that process. Thank you very much for your contribution. Anyone else? Eliot On 11/22/13 3:46 AM, Pete Maclean wrote: > I have implemented both CONDSTORE and QRESYNC. The former is > thoroughly tested and in release. The latter is rough and may not be > released for some time. > > Please excuse me if I have missed something but could you please tell > me what this shepherd write-up is. > > Pete Maclean > > At 01:01 PM 11/21/2013, Eliot Lear wrote: >> Dear IMAP folk, >> >> As I prepare the shepherd write-up, one of the questions I must answer >> is whether or not there are implementations. Can you please reply to >> this message if you (a) have implemented QRESYNC or CONDSTORE as >> specified in the document or (b) are planning to do so in the near >> future? >> >> Also, this is a very good time to take another look at the document. >> >> Thanks, >> >> Eliot >> _______________________________________________ >> imapext mailing list >> imapext@ietf.org >> https://www.ietf.org/mailman/listinfo/imapext > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext > > From dave@cridland.net Fri Nov 22 00:09:52 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2F21AE31B for ; Fri, 22 Nov 2013 00:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.136 X-Spam-Level: X-Spam-Status: No, score=0.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HC0A2S_SnupP for ; Fri, 22 Nov 2013 00:09:51 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD8A1AE316 for ; Fri, 22 Nov 2013 00:09:51 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id gq1so966530obb.32 for ; Fri, 22 Nov 2013 00:09:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xcw3wZ4CgI/YY3wMTnw5Tu7kAKJe22ViepihRLbuHPU=; b=LbyD+/Z+kovUW2InRSKyo/WFgeVBOTs/Q422aXVAV2AqyqOgHad2VRzjzDUYIekg9i pZGV4MjZWQaaxonjxgxUxMseSsnlHrHKaQKp9b2qjP4fh1IwqlfUIHmOoPFIYQgUVLbS 5sKQ2NWU10Na7EkMOaYE92iSJnDW7FaIljUuo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Xcw3wZ4CgI/YY3wMTnw5Tu7kAKJe22ViepihRLbuHPU=; b=WKWJY76qCEZpm4bPXM3ozEdqP9khPV1C4+uokxDUI4HP/NxIvzkGmFH2S1vAa+/cpW /QQxdLxLqTXUjwGJA3GTQhg/1pEg65reu6aNnSXDADNXa3ZfBp2CFlYvaiVNSKO7xUr6 fnGQMqUGRmVNY9WP476SCbVJffop2RmGbUE3okha98wKP8ynF+OhhIhuyBOOQTfpAyBi T/EaHmIezzc3oDaXQ8zZNumAsfbArHIrCYn0XIJ0EC/7YvdkmL1qT2omXaXIhZntXU7z n+dQf7Ji5effpLVsTw4slYj0uP8RE79kakcspbMiPyn1a1XrsHhNiwZacn29oUzLJ1lI 0e/w== X-Gm-Message-State: ALoCoQlFdoz8iCAXR5OlIc0++sPNn3jLJZxDJ78r+t5IV8JqGjo2yhCUGfQT+uTPxbg5UCgLAxuK MIME-Version: 1.0 X-Received: by 10.182.80.196 with SMTP id t4mr9634434obx.1.1385107784015; Fri, 22 Nov 2013 00:09:44 -0800 (PST) Received: by 10.60.121.97 with HTTP; Fri, 22 Nov 2013 00:09:43 -0800 (PST) In-Reply-To: <528E4A77.9060006@cisco.com> References: <528E4A77.9060006@cisco.com> Date: Fri, 22 Nov 2013 08:09:43 +0000 Message-ID: From: Dave Cridland To: Eliot Lear Content-Type: multipart/alternative; boundary=047d7b2e4eda7139a004ebbf8935 Cc: qresync WG Subject: Re: [imapext] preparing shepherd write-up for draft-ietf-qresync-rfc5162bis-03.txt: are you implementing? X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 08:09:52 -0000 --047d7b2e4eda7139a004ebbf8935 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 21, 2013 at 6:01 PM, Eliot Lear wrote: > As I prepare the shepherd write-up, one of the questions I must answer > is whether or not there are implementations. Can you please reply to > this message if you (a) have implemented QRESYNC or CONDSTORE as > specified in the document or (b) are planning to do so in the near future? > I have implemented it according to the original specification in Polymer, and have read the new specification to ensure it matches. I am intending to implement the new specification in Inky in the near future. Dave. --047d7b2e4eda7139a004ebbf8935 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 21, 2013 at 6:01 PM, Eliot Lear <lear@cisco.com<= /a>> wrote:
As I prepare the shepherd write-up, one of the questions I must answer
is whether or not there are implementations. =A0Can you please reply to
this message if you (a) have implemented QRESYNC or CONDSTORE as
specified in the document or (b) are planning to do so in the near future?<= br>

I have implemented it according to the = original specification in Polymer, and have read the new specification to e= nsure it matches.

I am intending to implement the new specification in In= ky in the near future.

Dave.
--047d7b2e4eda7139a004ebbf8935-- From alexey.melnikov@isode.com Fri Nov 22 04:37:35 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E2E1ADF7B for ; Fri, 22 Nov 2013 04:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.011 X-Spam-Level: X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7Bx2xHX5w9N for ; Fri, 22 Nov 2013 04:37:33 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id B13081AD9B8 for ; Fri, 22 Nov 2013 04:37:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1385123844; d=isode.com; s=selector; i=@isode.com; bh=K0okXZjT5UwnmTZu/yWcSSBGqJ/fZtzadQelJWgtMf8=; 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=VFI6AGgS106pjsOL++A+PLEyX8QZTxsUJXQGsCtdApaWB23aMg05at2tC4rA+pRbLlIYq3 zlzt+UPmmtozW5dJo7wLmgXv2QN5GGApuUdq6osHVnyPMBffdLlhD4RG7KvaE/+rsH3d/v R7urluWrr2gnaNdwjKoLh1EjsHjKLMs=; Received: from [172.16.1.224] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 22 Nov 2013 12:37:24 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <528F5005.5060708@isode.com> Date: Fri, 22 Nov 2013 12:37:25 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Eliot Lear References: <528E4A77.9060006@cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070804050401090907030902" Cc: qresync WG Subject: Re: [imapext] preparing shepherd write-up for draft-ietf-qresync-rfc5162bis-03.txt: are you implementing? X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 12:37:35 -0000 This is a multi-part message in MIME format. --------------070804050401090907030902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 22/11/2013 08:09, Dave Cridland wrote: > On Thu, Nov 21, 2013 at 6:01 PM, Eliot Lear > wrote: > > As I prepare the shepherd write-up, one of the questions I must answer > is whether or not there are implementations. Can you please reply to > this message if you (a) have implemented QRESYNC or CONDSTORE as > specified in the document or (b) are planning to do so in the near > future? > > > I have implemented it according to the original specification in > Polymer, and have read the new specification to ensure it matches. > > I am intending to implement the new specification in Inky in the near > future. Isode have implemented both extensions in our IMAP server and IMAP client. This includes errata/clarifications from the latest draft. There might be one bug outstanding in the IMAP server, but I am planning to fix it shortly. --------------070804050401090907030902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 22/11/2013 08:09, Dave Cridland wrote:
On Thu, Nov 21, 2013 at 6:01 PM, Eliot Lear <lear@cisco.com> wrote:
As I prepare the shepherd write-up, one of the questions I must answer
is whether or not there are implementations.  Can you please reply to
this message if you (a) have implemented QRESYNC or CONDSTORE as
specified in the document or (b) are planning to do so in the near future?

I have implemented it according to the original specification in Polymer, and have read the new specification to ensure it matches.

I am intending to implement the new specification in Inky in the near future.
Isode have implemented both extensions in our IMAP server and IMAP client. This includes errata/clarifications from the latest draft. There might be one bug outstanding in the IMAP server, but I am planning to fix it shortly.

--------------070804050401090907030902-- From murch@andrew.cmu.edu Fri Nov 22 04:52:37 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C621AD9B8 for ; Fri, 22 Nov 2013 04:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 613DNDUOXpas for ; Fri, 22 Nov 2013 04:52:35 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.11.96]) by ietfa.amsl.com (Postfix) with ESMTP id 642D21ADBFF for ; Fri, 22 Nov 2013 04:52:35 -0800 (PST) Received: from [192.168.137.22] (cpe-76-180-197-142.buffalo.res.rr.com [76.180.197.142]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.4/8.14.4) with ESMTP id rAMCqRDo028910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 22 Nov 2013 07:52:27 -0500 Message-ID: <528F538B.3000701@andrew.cmu.edu> Date: Fri, 22 Nov 2013 07:52:27 -0500 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: imapext@ietf.org References: <20649_1385056898_rALI1b7B030426_528E4A77.9060006@cisco.com> In-Reply-To: <20649_1385056898_rALI1b7B030426_528E4A77.9060006@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.4.9.4220 X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_500_599 0, BODY_SIZE_7000_LESS 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, TO_NO_NAME 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __RDNS_POOLED_2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __USER_AGENT 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.60 on 128.2.11.96 Subject: Re: [imapext] preparing shepherd write-up for draft-ietf-qresync-rfc5162bis-03.txt: are you implementing? X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 12:52:37 -0000 On 11/21/2013 01:01 PM, Eliot Lear wrote: > Dear IMAP folk, > > As I prepare the shepherd write-up, one of the questions I must answer > is whether or not there are implementations. Can you please reply to > this message if you (a) have implemented QRESYNC or CONDSTORE as > specified in the document or (b) are planning to do so in the near future? Cyrus IMAP has both extensions implemented per the original RFCs and will be updated to reflect any changes in the new spec. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From dave@cridland.net Fri Nov 22 05:54:58 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAB71ADF26 for ; Fri, 22 Nov 2013 05:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eri4GsLksaCQ for ; Fri, 22 Nov 2013 05:54:58 -0800 (PST) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id D23DA1ADEBB for ; Fri, 22 Nov 2013 05:54:57 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id n16so1350988oag.23 for ; Fri, 22 Nov 2013 05:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=XuNXNl8reHfdQYjjNIZR14xp6NWwRtJy3ChgMKjkbRk=; b=QJop0yzgxgGuxmx96prJzRJ4UUw/8CRsbuV9n+tN+eUZtXloXOXdZF2kpwaBR2HC2K L9UXotQ/+FwQek8/SzdN3UcoZxgrk9w8MNlsa896ayd1a+PNdXLjK8+eZhyB7pdfzpQ9 +KfJWQt1EZDfWNrmVtVtVUiqkmxukIbMB+cPc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=XuNXNl8reHfdQYjjNIZR14xp6NWwRtJy3ChgMKjkbRk=; b=UUIBVxtFlq0QqtbgcR8QpS2Qzpxtu9YbO1xJhScAmMNUDBQ2QjV26HG5vEouiWKZ6x aVFRztgrZLSsCUF062/GOgA3IewiNPvIndJ7OLLea2erG7zHL6o0mAUkIMUQaRCJ5Vc1 0gSPTlY4W8xFl6R8A0mjpe9Sq5EatBBrWrQy7kICbiX3CJ1VXfejrXAmfiJAOaZ1z2qe bU1TYQ/RqQBQeSGINDi55qWI7fphzWuUraZNH1WtF6uPNiGqGz5Igq9aTavcSXh+UTLg nb3lLn3Kcnevjk78jDV5w8qPWAtf83qQq+At1uR9fkptLVWkpqzarg0bkJ7F4FdMY8YJ 7h4g== X-Gm-Message-State: ALoCoQmfTIeM0aXocRPN1kRE9/EUgNaKCTaSp8ZNtpjTo2CyUvsoFJOWYV4ZQTqyRqKtV/oxAdJE MIME-Version: 1.0 X-Received: by 10.60.99.37 with SMTP id en5mr398192oeb.78.1385128490707; Fri, 22 Nov 2013 05:54:50 -0800 (PST) Received: by 10.60.121.97 with HTTP; Fri, 22 Nov 2013 05:54:50 -0800 (PST) Date: Fri, 22 Nov 2013 13:54:50 +0000 Message-ID: From: Dave Cridland To: "imapext@ietf.org" Content-Type: multipart/alternative; boundary=047d7b33d7e4a8419f04ebc45b4f Subject: [imapext] WGLC on QRESYNC, Ending 6th December. X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 13:54:59 -0000 --047d7b33d7e4a8419f04ebc45b4f Content-Type: text/plain; charset=ISO-8859-1 Folks, This begins a two week last call period for draft-ietf-qresync-rfc5162bis-03.txt. Please submit any comments you have on or before 6th December 2013. I know we have some reviews in progress, we'll deal with the results of those as they arrive. Thanks, Dave. (Ex Cathedra) --047d7b33d7e4a8419f04ebc45b4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Folks,

This begins a two wee= k last call period for draft-ietf-qresync-rfc5162bis-03.txt. =A0Please subm= it any comments you have on or before 6th December 2013.

I know we have some reviews in progress, we'll deal with the resul= ts of those as they arrive.

Thanks,

=
Dave.
(Ex Cathedra)
--047d7b33d7e4a8419f04ebc45b4f-- From jkt@flaska.net Fri Nov 22 08:33:15 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4881AE057 for ; Fri, 22 Nov 2013 08:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cl3qEl89L2V0 for ; Fri, 22 Nov 2013 08:33:10 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id 953721AE02E for ; Fri, 22 Nov 2013 08:33:07 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id CA1FA63184; Fri, 22 Nov 2013 17:32:58 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Fri, 22 Nov 2013 17:32:58 +0100 User-Agent: Trojita/v0.3.96-113-g94d266f; Qt/4.8.5; X11; Linux; MIME-Version: 1.0 Message-ID: <368e22b4-930e-4882-bca4-8b23bc3d4b06@flaska.net> In-Reply-To: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 16:33:15 -0000 Hi Alexey, thanks a lot for working on this. Here's a couple of comments=20 from my point of view: - The new version now requires VANISHED for all expunges, which is great. I=20= don't understand why is it limited to mailboxes which do not announce=20 NOMODSEQ, though. Surely the server already tracks UIDs for each and every=20= message in a given mailbox *while the session is open*. But that's a very=20 minor point, I guess -- upon NOMODSEQ, the general usefullness of this=20 extension is substantially reduced anyway. - The document now forces the server to either support the modseq tracking=20= all the time, or not at all for a given mailbox. I believe that Dovecot at=20= least used to enable this "lazily", i.e. it isn't active by default, but=20 activated on demand when any client first issues a CONDSTORE-enabling=20 command on a particular mailbox. My understanding is that after that=20 happens, HIGHESTMODSEQ is properly updated for each session started=20 afterwards. Timo, could you please confirm this? If that is the case, the=20 new wording disables this. - You probably wanted to make "RFC3501" a link in the ABNF grammar for the=20= "status-att" nonterminal. - The ABNF has a comment for the status-att-val nonterminal saying [...]=20 "as described in Section 3.1.2 [[Check the ref]]". I don't think the last=20 part is intentional. - The ABNF allows for HIGHESTMODSEQ to be 0 and contains a comment=20 clarifying that this is for situations where the server doesn't support=20 MODSEQ tracking on this mailbox. That conflicts with the NOMODSEQ response=20= code. My suggestion is to get rid of zero HIGHESTMODSEQ and make it clear=20 that the alternatives are either NOMODSEQ or a non-zero HIGHESTMODSEQ;=20 allowing two ways of conveying the same intention is not needed here, IMHO. - Section 8 shall probably refer to both CONDSTORE and QRESYNC, not just=20 QRESYNC. - It appears that the interaction with the METADATA extension is not=20 defined anywhere. Maybe at least mandate that changing any per-mailbox=20 metadata MUST change the HIGHESTMODSEQ as well? - The same for the ANNOTATE-EXPERIMENT-1 (or is it dead already?). Should=20 changes to per-message metadata bump the message's MODSEQ? - Finally, I still feel that there's a room for misinterpretation of the=20 VANISHED. Suppose that the mailbox contains UIDs 2 and 4, the UIDNEXT is 6.=20= Which of the following responses are valid and which demonstrate a broken=20 server? * VANISHED 1 * VANISHED 3 * VANISHED 5 * VANISHED 7 In my opinion, it is all of them. On the other hand, if it was about=20 VANISHED EARLIER, only the VANISHED (EARLIER) 7 would be invalid and all of=20= the others have to be allowed. I therefore propose the following update, replacing this paragraphs: Note that a VANISHED response caused by EXPUNGE, UID EXPUNGE, or messages expunged in other connections MUST only contain UIDs for messages expunged since the last VANISHED/EXPUNGE response sent for the currently opened mailbox or since the mailbox was opened. That is, servers MUST NOT send UIDs for previously expunged messages, unless explicitly requested to do so by the UID FETCH (VANISHED) command. This is required to prevent a possible race condition where new arrivals for which the UID is not yet known by the client are expunged. with something like this: A VANISHED response without the EARLIER tag MUST only refer to a UID which was visible to the session at the time the response is sent. In particular, this means that VANISHED response MUST NOT refer to a message whose removal was already communicated to the client, or to a message whose UID has not been present in the mailbox yet. This is required to prevent a possible race condition where new arrivals for which the UID is not yet known by the client are expunged. The VANISHED EARLIER response MIGHT refer to messages whose removal was already known to the client. However, it MUST NOT refer to a UID which has not been present in the mailbox yet (following the usual UIDVALIDITY semantics). - I'm happy to see that the scenario of going out-of-sync upon new arrivals=20= was addressed by the requirement to always include UID in unsolicited FETCH=20= responses. Thanks! Cheers, Jan --=20 Trojit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From jkt@flaska.net Fri Nov 22 08:36:49 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3BF1AE34A for ; Fri, 22 Nov 2013 08:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D29m-o1T9uia for ; Fri, 22 Nov 2013 08:36:48 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id 329A51AE342 for ; Fri, 22 Nov 2013 08:36:48 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id D07AD63184; Fri, 22 Nov 2013 17:36:39 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Fri, 22 Nov 2013 17:36:40 +0100 User-Agent: Trojita/v0.3.96-113-g94d266f; Qt/4.8.5; X11; Linux; MIME-Version: 1.0 Message-ID: In-Reply-To: <528E4A77.9060006@cisco.com> References: <528E4A77.9060006@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] =?iso-8859-1?q?preparing_shepherd_write-up_for_draft-ie?= =?iso-8859-1?q?tf-qresync-rfc5162bis-03=2Etxt=3A_are_you_implementing=3F?= X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 16:36:49 -0000 On Thursday, 21 November 2013 19:01:27 CEST, Eliot Lear wrote: > (a) have implemented QRESYNC or CONDSTORE as specified in the document Trojita is an IMAP client which speaks both CONDSTORE and QRESYNC; it has=20 been shipping in releases for more than one year. The clarifications=20 provided in the updated version fix a number of bugs where the client's=20 idea of how the mailbox looks like might get out of touch from what the=20 server provides, and therefore I'm very happy to see an updated version. KMail's IMAP backend, the Akonadi IMAP resource, supports CONDSTORE.=20 Support for QRESYNC is planned, as far as I know. With kind regards, Jan --=20 Trojit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From alexey.melnikov@isode.com Mon Nov 25 10:10:06 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AD81AE015 for ; Mon, 25 Nov 2013 10:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.471 X-Spam-Level: X-Spam-Status: No, score=-0.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYg59W_DUWEY for ; Mon, 25 Nov 2013 10:10:04 -0800 (PST) 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 3A1A21AE012 for ; Mon, 25 Nov 2013 10:10:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1385403002; d=isode.com; s=selector; i=@isode.com; bh=eK8HkKMsF96aPYU4Nwqc1cK6uMMRaDFOHXwbGMrbRHc=; 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=FkzcIbePy3VImCb38DNkCo6YvnenAH05LxAjKcEunTa1WBZ3DSJhi0KkY/i6UF1vObdI1h ZIL6kFd3w8IhOd+bX/CT/iw4/nzvmhhWBlAn4dTOkM++U6EWZm5qmTAwApq9miLP9MTmV0 mbu1ntooIM8jW2iBPaITQvPWUchGC5s=; Received: from [192.168.0.7] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 25 Nov 2013 18:10:02 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52939279.4000504@isode.com> Date: Mon, 25 Nov 2013 18:10:01 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Eliot Lear References: <528E5246.4040506@cisco.com> In-Reply-To: <528E5246.4040506@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qresync WG , Dave Cridland Subject: Re: [imapext] Shepherd review of draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 18:10:06 -0000 On 21/11/2013 18:34, Eliot Lear wrote: > Dear Alexey & Dave, Hi Eliot, Thank you for your review. > Here is my review for draft-ietf-qresync-rfc5162bis-03.txt as it stands. > > Note that I realize that you are merging two documents. The result > still needs to read as a single document. The introduction does not. > Also, it is unusual to have normative language in the introduction, and > in the 2nd sentence to boot. You've put the motivation for the work on > the bottom of page 4 and into page 5. Please move that up to the top. > Make clear the difference without the extension in use and then with. Yes, I will update. If people have good suggestions for this section, that would also be great. >> Mod-sequences allow a client that supports the CONDSTORE extension to >> determine if a message metadata has changed since some known moment. > Please explain why this is important. Resynchronization of metadata (e.g. flag changes) is one of the reasons to resynchronize at all. (Other reasons are to find new and deleted messages). Why do you think this needs explanation? > 3.1. syntax: is the word SEARCH missing from the front? There is no syntax in the section 3.1. Unless you meant one of the subsections? > Minor issues > > The abstract is too long. Much of the content belongs in the introduction. I am not sure about this. I wanted to show that there are two extensions defined in the document. Do you think this is too much detail? > Use of system clock could be allowed so long as a check is made to > insure that the value is guaranteed to increase. For example: > > if ((mod_sequence=clock()) <=last_mod_sequence) { > mod_sequence=last_mod_sequence+1; > } The sentence in the document is about naive use (without the check you suggest). I can clarify, but I believe it is correct as written. > Your reference to RFC1305 should probably be RFC5905. Please check > other references for similar updates since RFC5162. Yes. And there was a duplicated reference. Fixed in my copy. > Can you please confirm with me that you have (re)tested the examples to > make sure they're accurate? Yes. > I've checked the ABNF and it looks good. Great. From alexey.melnikov@isode.com Mon Nov 25 11:25:50 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162A41ADFBB for ; Mon, 25 Nov 2013 11:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.171 X-Spam-Level: X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cL--aji7gSaI for ; Mon, 25 Nov 2013 11:25:49 -0800 (PST) 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 BEB741AD942 for ; Mon, 25 Nov 2013 11:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1385407547; d=isode.com; s=selector; i=@isode.com; bh=57W0tO+y+DvVwMuGdJBKCd5MyTb/Np3t60++it1n6oQ=; 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=Xk/q+fJvH7DP/lLBC6JRx1ugICTMx4gl5/fusaeDuTJnBnuVFkuNGbzE5fN5HzGankMQ1e rvFZIqQ4g/JR8RIy9R+BNmFQPzcipS+m7Ya5AeXI/pBZIRHYUNFlI7RthVSYoMB1nVnAqf UUk4GB8WQbZ1hRVpKRmDn8Z0bndHECg=; Received: from [192.168.0.7] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 25 Nov 2013 19:25:47 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <5293A43A.8080408@isode.com> Date: Mon, 25 Nov 2013 19:25:46 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= , Timo Sirainen References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <368e22b4-930e-4882-bca4-8b23bc3d4b06@flaska.net> In-Reply-To: <368e22b4-930e-4882-bca4-8b23bc3d4b06@flaska.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: imapext@ietf.org Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 19:25:50 -0000 On 22/11/2013 16:32, Jan Kundr=E1t wrote: > Hi Alexey, thanks a lot for working on this. Here's a couple of=20 > comments from my point of view: > > - The new version now requires VANISHED for all expunges, which is=20 > great. I don't understand why is it limited to mailboxes which do not=20 > announce NOMODSEQ, though. Surely the server already tracks UIDs for=20 > each and every message in a given mailbox *while the session is open*.=20 > But that's a very minor point, I guess -- upon NOMODSEQ, the general=20 > usefullness of this extension is substantially reduced anyway. This was pretty much my conclusion. But I am happy to change that if=20 other WG members agree with you. > - The document now forces the server to either support the modseq=20 > tracking all the time, or not at all for a given mailbox. I believe=20 > that Dovecot at least used to enable this "lazily", i.e. it isn't=20 > active by default, but activated on demand when any client first=20 > issues a CONDSTORE-enabling command on a particular mailbox. My=20 > understanding is that after that happens, HIGHESTMODSEQ is properly=20 > updated for each session started afterwards. Timo, could you please=20 > confirm this? If that is the case, the new wording disables this. I am personally ambivalent on this (and would be happy to change that).=20 Timo? > > - You probably wanted to make "RFC3501" a link in the ABNF grammar for=20 > the "status-att" nonterminal. Changed. > - The ABNF has a comment for the status-att-val nonterminal saying=20 > [...] "as described in Section 3.1.2 [[Check the ref]]". I don't think=20 > the last part is intentional. It was a reminder to me :-). Actually the section number was wrong, so I=20 corrected it now. > - The ABNF allows for HIGHESTMODSEQ to be 0 and contains a comment=20 > clarifying that this is for situations where the server doesn't=20 > support MODSEQ tracking on this mailbox. That conflicts with the=20 > NOMODSEQ response code. My suggestion is to get rid of zero=20 > HIGHESTMODSEQ and make it clear that the alternatives are either=20 > NOMODSEQ or a non-zero HIGHESTMODSEQ; allowing two ways of conveying=20 > the same intention is not needed here, IMHO. I think you are confused here: HIGHESTMODSEQ=3D=3D0 is only used in STATUS= =20 responses. I don't think we need NOMODSEQ there. > - Section 8 shall probably refer to both CONDSTORE and QRESYNC, not=20 > just QRESYNC. The second paragraph references both. I think the first one only applies=20 to QRESYNC. > - It appears that the interaction with the METADATA extension is not=20 > defined anywhere. Maybe at least mandate that changing any per-mailbox=20 > metadata MUST change the HIGHESTMODSEQ as well? Hmm. QRESYNC covers all message related changes. METADATA is about other=20 mailbox state. I haven't thought about tracking that. I would like to=20 hear other opinions on this! > - The same for the ANNOTATE-EXPERIMENT-1 (or is it dead already?).=20 > Should changes to per-message metadata bump the message's MODSEQ? It already does. Metadata was defined to cover both flags and per=20 message annotations. Do you think this is unclear? I will reply to your last comment (omitted in this reply) in a separate=20 message. From alexey.melnikov@isode.com Mon Nov 25 11:29:05 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C088A1ADF54 for ; Mon, 25 Nov 2013 11:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.171 X-Spam-Level: X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRcj5gLmFfOb for ; Mon, 25 Nov 2013 11:29:04 -0800 (PST) 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 9CDEA1AD942 for ; Mon, 25 Nov 2013 11:29:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1385407744; d=isode.com; s=selector; i=@isode.com; bh=GfBEdnuiJd7aj01mivDD7ptRHP3bFj/4crMrpq/27EI=; 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=L4rNHIxTJpx9mLasXAkLKCmxk95OlbA6WpuxuZfOc7T4RFdupcwkh/UzCL9GwUBY1xpJQ7 fgYpFRrs6jwuGa6wgmpCjJYZtgN0T79eOHBF6QIipzOwgQsqxKLwGH+Sl8bCJcUYAznARE 3H81Fol+z0C4z46m8LhF6Uj12kMnY5A=; Received: from [192.168.0.7] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 25 Nov 2013 19:29:04 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <5293A4FF.6030406@isode.com> Date: Mon, 25 Nov 2013 19:29:03 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <368e22b4-930e-4882-bca4-8b23bc3d4b06@flaska.net> In-Reply-To: <368e22b4-930e-4882-bca4-8b23bc3d4b06@flaska.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: imapext@ietf.org Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 19:29:06 -0000 Hi Jan, On 22/11/2013 16:32, Jan Kundr=E1t wrote: > - Finally, I still feel that there's a room for misinterpretation of=20 > the VANISHED. Suppose that the mailbox contains UIDs 2 and 4, the=20 > UIDNEXT is 6. Which of the following responses are valid and which=20 > demonstrate a broken server? > > * VANISHED 1 > * VANISHED 3 > * VANISHED 5 > * VANISHED 7 > > In my opinion, it is all of them. On the other hand, if it was about=20 > VANISHED EARLIER, only the VANISHED (EARLIER) 7 would be invalid and=20 > all of the others have to be allowed. > > I therefore propose the following update, replacing this paragraphs: > > Note that a VANISHED response caused by EXPUNGE, UID EXPUNGE, or > messages expunged in other connections MUST only contain UIDs for > messages expunged since the last VANISHED/EXPUNGE response sent for > the currently opened mailbox or since the mailbox was opened. That > is, servers MUST NOT send UIDs for previously expunged messages, > unless explicitly requested to do so by the UID FETCH (VANISHED) > command. This is required to prevent a possible race condition where > new arrivals for which the UID is not yet known by the client are > expunged. > > with something like this: > > A VANISHED response without the EARLIER tag MUST only refer to a UID > which was visible to the session at the time the response is sent. > In particular, this means that VANISHED response MUST NOT refer to a > message whose removal was already communicated to the client, I am agreeing with this part. > or to > a message whose UID has not been present in the mailbox yet. I think you meant what wasn't announced to the client yet. However, I don't see a problem with this. Can you elaborate why sending=20 VANISHED for UIDs the client hasn't seen yet is a problem? > This is > required to prevent a possible race condition where new arrivals for > which the UID is not yet known by the client are expunged. > > The VANISHED EARLIER response MIGHT refer to messages whose removal > was already known to the client. However, it MUST NOT refer to a UID > which has not been present in the mailbox yet (following the usual > UIDVALIDITY semantics). Best Regards, Alexey From tss@iki.fi Mon Nov 25 11:51:22 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FF71ADFC0 for ; Mon, 25 Nov 2013 11:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.554 X-Spam-Level: X-Spam-Status: No, score=-5.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agsVsffLInEV for ; Mon, 25 Nov 2013 11:51:20 -0800 (PST) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5D71ADFDF for ; Mon, 25 Nov 2013 11:51:20 -0800 (PST) Received: from [192.168.123.81] (14.21.90.92.rev.sfr.net [92.90.21.14]) by dovecot.org (Postfix) with ESMTP id 63BE11AE886E; Mon, 25 Nov 2013 21:51:18 +0200 (EET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Timo Sirainen In-Reply-To: <5293A43A.8080408@isode.com> Date: Mon, 25 Nov 2013 20:51:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D48C6CF-ABC0-4FCF-B85D-E08F2800100C@iki.fi> References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <368e22b4-930e-4882-bca4-8b23bc3d4b06@flaska.net> <5293A43A.8080408@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1822) Cc: =?windows-1252?Q?Jan_Kundr=E1t?= , imapext@ietf.org Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 19:51:22 -0000 On 25.11.2013, at 20.25, Alexey Melnikov = wrote: >> - The document now forces the server to either support the modseq = tracking all the time, or not at all for a given mailbox. I believe that = Dovecot at least used to enable this "lazily", i.e. it isn't active by = default, but activated on demand when any client first issues a = CONDSTORE-enabling command on a particular mailbox. My understanding is = that after that happens, HIGHESTMODSEQ is properly updated for each = session started afterwards. Timo, could you please confirm this? If that = is the case, the new wording disables this. > I am personally ambivalent on this (and would be happy to change = that). Timo? I=92ve been thinking I should make it always track HIGHESTMODSEQ (but = not per-message modseqs) to get rid of this issue, but haven=92t really = had time yet. But even if I do, there are quite a lot of old Dovecot = installations left for many more years. So I think it would be good to = say something to highly encourage clients to issue ENABLE = CONDSTORE/QRESYNC before SELECT or issue CONDSTORE/QRESYNC-enabling = SELECT command. >> - It appears that the interaction with the METADATA extension is not = defined anywhere. Maybe at least mandate that changing any per-mailbox = metadata MUST change the HIGHESTMODSEQ as well? > Hmm. QRESYNC covers all message related changes. METADATA is about = other mailbox state. I haven't thought about tracking that. I would like = to hear other opinions on this! I don=92t know if this should be a MUST, but Dovecot does increase = HIGHESTMODSEQ on METADATA changes because it=92s useful for syncing to = know when mailbox has changed. From jkt@flaska.net Mon Nov 25 14:54:37 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FC61AE094 for ; Mon, 25 Nov 2013 14:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrPZPOsK-HOE for ; Mon, 25 Nov 2013 14:54:35 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA431AE085 for ; Mon, 25 Nov 2013 14:54:34 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id A9A0361BB6; Mon, 25 Nov 2013 23:54:31 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Mon, 25 Nov 2013 23:54:31 +0100 User-Agent: Trojita/v0.3.96-116-ga1d78a2; Qt/4.8.5; X11; Linux; MIME-Version: 1.0 Message-ID: <08f2fdeb-957f-4ed4-a827-bdce2094275f@flaska.net> In-Reply-To: <5293A4FF.6030406@isode.com> References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <368e22b4-930e-4882-bca4-8b23bc3d4b06@flaska.net> <5293A4FF.6030406@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 22:54:37 -0000 On Monday, 25 November 2013 20:29:03 CEST, Alexey Melnikov wrote: >> or to >> a message whose UID has not been present in the mailbox yet. > I think you meant what wasn't announced to the client yet. Yes. However, "announced" refers to stuff like EXISTS responses, i.e.=20 servers should really issue VANISHED even for messages whose UIDs are still=20= unknown to the client, but which were announced by the EXISTS response. (When a new message arrives, the server always have to send EXISTS at=20 first, and only then has a chance of either issuing untagged FETCH or=20 waiting for client to ask for the UIDs explicitly.) > However, I don't see a problem with this. Can you elaborate why=20 > sending VANISHED for UIDs the client hasn't seen yet is a=20 > problem? Safety. QRESYNC is a complex extension and there's quite a potential for=20 both servers and clients to introduce subtle bugs which only manifest=20 themselves in uncommon situations. When my client sees something which=20 doesn't make any sense, it's much better to reject this explicitly and=20 point out that either the server or the client are broken than to lose=20 data. One example: (two messages exists, UIDs 1 and 2) S: * 4 EXISTS S: * VANISHED 5 What UIDs are present at this point? Are there two, three or four messages=20= in there, i.e. did VANISHED actually remoev anything? This is why I proposed replacing EXISTS with something like the UID-based=20 ARRIVED [1]. This was rejected in an attempt at reducing the amount of=20 changes needed in the existing software, which makes sense. However, I=20 believe that these corner cases have to described in the spec. Cheers, Jan [1] http://tools.ietf.org/html/draft-kundrat-qresync-arrived-00 --=20 Trojit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From jkt@flaska.net Mon Nov 25 15:20:25 2013 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1F61AE051 for ; Mon, 25 Nov 2013 15:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVBVtrL6sZOL for ; Mon, 25 Nov 2013 15:20:24 -0800 (PST) Received: from latimerie.flaska.net (latimerie.flaska.net [IPv6:2a02:2b88:2:1::4a7:333]) by ietfa.amsl.com (Postfix) with ESMTP id 68D9F1AE089 for ; Mon, 25 Nov 2013 15:20:24 -0800 (PST) Received: by latimerie.flaska.net (Postfix, from userid 1000) id 42A1761BB6; Tue, 26 Nov 2013 00:20:23 +0100 (CET) From: =?iso-8859-1?Q?Jan_Kundr=E1t?= To: Date: Tue, 26 Nov 2013 00:20:22 +0100 User-Agent: Trojita/v0.3.96-116-ga1d78a2; Qt/4.8.5; X11; Linux; MIME-Version: 1.0 Message-ID: In-Reply-To: <5293A43A.8080408@isode.com> References: <20131008141122.25649.73956.idtracker@ietfa.amsl.com> <368e22b4-930e-4882-bca4-8b23bc3d4b06@flaska.net> <5293A43A.8080408@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] I-D Action: draft-ietf-qresync-rfc5162bis-03.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 23:20:25 -0000 On Monday, 25 November 2013 20:25:46 CEST, Alexey Melnikov wrote: > I think you are confused here: HIGHESTMODSEQ=3D=3D0 is only used in=20 > STATUS responses. I don't think we need NOMODSEQ there. Yup, you're right, I missed that this is just about STATUS. I agree that=20 introducing another STATUS attribute is not backwards compatible and=20 therefore cannot really be used here unless we want to change the=20 capability string. Trojita would disconnect upon seeing an unrecognized=20 item in the STATUS response. >> - Section 8 shall probably refer to both CONDSTORE and=20 >> QRESYNC, not just QRESYNC. > The second paragraph references both. I think the first one=20 > only applies to QRESYNC. Section 8 is about the security impact. I believe that both of these=20 paragraphs apply to CONDSTORE and QRESYNC in exactly the same manner, but=20 it's a style issue at most. That said, my preference is changing the text=20 so that it better fits the unification of the two older RFCs. >> - The same for the ANNOTATE-EXPERIMENT-1 (or is it dead=20 >> already?). Should changes to per-message metadata bump the=20 >> message's MODSEQ? > It already does. Metadata was defined to cover both flags and=20 > per message annotations. Do you think this is unclear? That's good to hear and it certainly matches my opinion on how things=20 should work, but I'm having troubles finding a reference to this behavior=20 in the specs. What I see is section 2 defining "metadata" to mean "any=20 [...] keyword" with a possibility of future RFCs including other items. I=20 don't see anything relevant in RFC 5257, nor in the current draft. With kind regards, Jan --=20 Trojit=C3=A1, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/