From lehmann@strato-rz.de Thu Feb 3 07:27:32 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221C73A69CB; Thu, 3 Feb 2011 07:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2aTn4xOk9tN; Thu, 3 Feb 2011 07:27:31 -0800 (PST) Received: from fredda.webgods.de (fredda.webgods.de [192.166.196.83]) by core3.amsl.com (Postfix) with ESMTP id 4682B3A69C7; Thu, 3 Feb 2011 07:27:31 -0800 (PST) Message-ID: <4D4ACA2A.3080401@strato-rz.de> Date: Thu, 03 Feb 2011 16:30:50 +0100 From: Steffen Lehmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: morg@ietf.org, apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [MORG] New draft at MORG: POP3 LIST+ Extension X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 15:27:32 -0000 Hello, there is a new draft at http://datatracker.ietf.org/doc/draft-lehmann-morg-pop3listplus/ describing the "POP3 LIST+ Extension". Although it is related to POP3 instead of IMAP, I have put it into MORG, because MORG's goals are fitting best. Comments and suggestions are solicited. Steffen From evnikita2@gmail.com Fri Feb 4 06:38:42 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E103A6930 for ; Fri, 4 Feb 2011 06:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fRFCpOLWZAZ for ; Fri, 4 Feb 2011 06:38:41 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 3D3863A68E4 for ; Fri, 4 Feb 2011 06:38:41 -0800 (PST) Received: by fxm9 with SMTP id 9so2622543fxm.31 for ; Fri, 04 Feb 2011 06:42:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uEa8N465lqQSNBgeBblaAKMSYRAbzZStKyqjw5TT5Lw=; b=q7cR+ZaI5ubggQfmQ/K3FjHTaGcdJPHLePvSeC9U4r7PofUv5Wwir9GpODioYqqou4 pIHQ50xpiBi5EdSxSRdAlIiFm2l7uazkjLwPfg8HvGKCr3Vbb/xsEIkaz+k/28jdlmMN NB8XfVs1rAKucn2Ylt+b4CIsNBAI/XiMKhW68= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=SnuCC6A0iEmdJ00OOO/4sy+BcAoRzWtU5bmML2A8v0XQC96iPDVcgT23VWtqyjLuaF oWvwkB+puty1XgcDyg+Sq11TJxQcvPBQcUu9dGiRZR39YDRslZBKysGfyp8+KQMmLwcD 1M30QQHjpOUrFoavLHc6nN6g6FHt/XYtncmWw= Received: by 10.223.123.142 with SMTP id p14mr82963far.56.1296830525820; Fri, 04 Feb 2011 06:42:05 -0800 (PST) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id 21sm252970fav.41.2011.02.04.06.42.03 (version=SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 06:42:04 -0800 (PST) Message-ID: <4D4C1053.3020106@gmail.com> Date: Fri, 04 Feb 2011 16:42:27 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: morg@ietf.org, Steffen Lehmann References: <4D4ACA2A.3080401@strato-rz.de> In-Reply-To: <4D4ACA2A.3080401@strato-rz.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 04 Feb 2011 09:51:06 -0800 Subject: Re: [MORG] [apps-discuss] New draft at MORG: POP3 LIST+ Extension X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 14:38:42 -0000 Hello all, I'm writing to comment Steffen's draft related to POP3 LIST+ extension. I would firstly ask whether allowing the LIST+ flags with no limited number of chars is acceptable? So I propose to say that (in Section 3) 'LIST+ flag MAY contain only 16-32 [?? - as you eant] characters' and appropriate changes to Appendix B. Firstly, IANA just won't be able to maintain the registry with possibly endless number of values; moreover, aspiration to keep flags as short as possible does nt imply such unlimited lengths for them. What is more, I propose to change the security considerations a bit in the following way: "Using LIST extended by LIST+ does not introduce any new security issues to it' or 'Using LIST extended by LIST+ is not more secure that its separate usage'. It is not right that it does not raise any security issues. I would also like to notice (I've already sent that to the author) that IANA considerations are not clear at all. Therefore I propose (of course, formatted in appropriate way): > 8. IANA Considerations > > 8.1. 'LIST+ Flags' Registry > > IANA is asked to create and maintain the 'LIST+ Flags' registry > following the guidelines below. > > The registry consists of two values: LIST+ flag and Reference. They > are described below. > > LIST+ flag - the text string, whose syntax is defined in Section 3. > > Reference - the reference to the document that described the LIST+ flag. > > Initial values are given below; new assignments are to be made > following the 'IETF Consensus' policies [RFC 5226 - normative ref] (or > other policy, as you want) > LIST+ flag Reference > +-------------------+-------------+ > | +UIDL | this doc. | > etc. > > 8.2. LIST+ Registration in 'POP3 Capabilities' Registry > > IANA is asked a new keyword "LIST+" in the "POP3 Capabilities" > registry [reference to the reg.] using the template in Section 2 of > this document. Finally, as editorial proposals: the places of Sections 1.1 and 1.2 should be exchanged; the same as for sections 2 and 3 - this IMO will improve the readability of the document. All the best, Mykyta Yevstifeyev 03.02.2011 17:30, Steffen Lehmann wrote: > Hello, > > there is a new draft at > http://datatracker.ietf.org/doc/draft-lehmann-morg-pop3listplus/ > describing the "POP3 LIST+ Extension". > > Although it is related to POP3 instead of IMAP, I have put it into MORG, > because MORG's goals are fitting best. > > Comments and suggestions are solicited. > > Steffen > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From tss@iki.fi Fri Feb 4 10:15:07 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED0B3A69DC for ; Fri, 4 Feb 2011 10:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVH5zgNaYWww for ; Fri, 4 Feb 2011 10:15:06 -0800 (PST) Received: from dovecot.org (dovecot.org [62.236.108.70]) by core3.amsl.com (Postfix) with ESMTP id BB3823A694A for ; Fri, 4 Feb 2011 10:15:06 -0800 (PST) Received: from [192.168.100.43] (a91-153-29-233.elisa-laajakaista.fi [91.153.29.233]) by dovecot.org (Postfix) with ESMTP id 5BCAAFA8C80; Fri, 4 Feb 2011 20:18:28 +0200 (EET) From: Timo Sirainen To: Barry Leiba In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-15" Date: Fri, 04 Feb 2011 20:18:28 +0200 Message-ID: <1296843508.18488.360.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: morg Subject: Re: [MORG] draft-ietf-morg-multimailbox-search-05 - WGLC X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:15:07 -0000 On Tue, 2011-01-25 at 12:43 -0500, Barry Leiba wrote: > We're halfway through the WGLC period, and have had no comments. > Please, let's get at least two or three reviews of this version, and > confirm (or refute) that it's ready to go. Pretty quiet in here.. I've anyway reviewed. Just one thing: > S: * ESEARCH (TAG "tag1" MAILBOX "folder1" UIDVALIDITY 1) UID ALL > 4001,4003,4005,4007,4009 > S: * ESEARCH (TAG "tag2" MAILBOX "folder1" UIDVALIDITY 6789023554) > UID ALL 195001:195004,169788 UIDVALIDITY changes rather suddenly in this example, so I think that's just unnecessary confusion. Also the second one's UID set isn't sorted as it should be. From tss@iki.fi Fri Feb 4 10:39:37 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74193A69CF for ; Fri, 4 Feb 2011 10:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKy7hN6bXvtJ for ; Fri, 4 Feb 2011 10:39:36 -0800 (PST) Received: from dovecot.org (dovecot.org [62.236.108.70]) by core3.amsl.com (Postfix) with ESMTP id 7693B3A694A for ; Fri, 4 Feb 2011 10:39:36 -0800 (PST) Received: from [192.168.100.43] (a91-153-29-233.elisa-laajakaista.fi [91.153.29.233]) by dovecot.org (Postfix) with ESMTP id 79E1CFA8B6C; Fri, 4 Feb 2011 20:43:01 +0200 (EET) From: Timo Sirainen To: Steffen Lehmann In-Reply-To: <4D4ACA2A.3080401@strato-rz.de> References: <4D4ACA2A.3080401@strato-rz.de> Content-Type: text/plain; charset="ISO-8859-15" Date: Fri, 04 Feb 2011 20:43:01 +0200 Message-ID: <1296844981.18488.385.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: morg@ietf.org Subject: Re: [MORG] New draft at MORG: POP3 LIST+ Extension X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:39:37 -0000 > POP3 clients using the LIST command, and, > immediately followed, the UIDL command to get the Message Number, > Message Size and Unique-ID, of all messages of a mailbox, to see if > new messages have arrived. On large mailboxes, holding hundreds or > thousands of mails, this causes serious resource consumption on the > server, and will prolong the duration a mailbox is hold in locked > state. This situation is even stressed by the fact that POP3 clients > will usually poll a mailbox for new messages periodically in short > intervals. I agree with the above, but > Using the LIST+ Extension, a server has to scan through the mailbox > only for a single time, and can send the Message Number, Message Size > and Unique-ID in a more compact form to the client (as shown in > Appendix A.2.1). I don't see this helping all that much with the server's resource consumption or even much with the client's bandwidth consumption. The server still has to look up all the sizes and UIDLs. In Appendix A the client downloads 22% less. Most of the time POP3 clients just poll an unchanged mailbox. It would be possible to get a much more dramatic bandwidth improvement by being able to tell clients that nothing had changed since the last time. Here's an example of how it could work: Client connecting for the first time: C: LIST +UIDL S: +OK 14758f1afd44c09b7992073ccf00b43d 3 messages, listing follows: S: 1 4536 7abcb6f4da22080e121f2824aef2be9a S: 2 4422 577151e65ea4e62bb9b1c5830a818fe7 S: 3 3828 2fe542ac6d1c29bb6a5161558f527e2e S: . Client connecting the second time when there are no changes: C: LIST +UIDL +ID=14758f1afd44c09b7992073ccf00b43d S: +OK 14758f1afd44c09b7992073ccf00b43d No changes S: . Client connecting the 3rd time when there are changes: C: LIST +UIDL +ID=14758f1afd44c09b7992073ccf00b43d S: +OK ddd2cae8a4a5ec890737d07adb537b99 4 messages, listing follows: S: 1 4536 7abcb6f4da22080e121f2824aef2be9a S: 2 4422 577151e65ea4e62bb9b1c5830a818fe7 S: 3 3828 2fe542ac6d1c29bb6a5161558f527e2e S: 4 3284 86519edbbe78d203c5c9618df50b21a7 S: . So, the client would just remember the value after the "OK". The server can use whatever value it wants there, but one simple possibility would be to just use a hash(all UIDLs). This could be made to save more bandwidth by allowing server to send only changes based on the given ID, such as: C: LIST +UIDL +ID=14758f1afd44c09b7992073ccf00b43d S: +OK ddd2cae8a4a5ec890737d07adb537b99 1 new message: S: 4 3284 86519edbbe78d203c5c9618df50b21a7 S: . Deleted messages could also be reported by adding more complexity. > The +UNREAD Flag requests to add the number of whole days, since the > message was read for last time, to the extended scan listing. What exactly is the "last read time" for a message? RETR time? When it was marked as \Seen in webmail/IMAP? From barryleiba@gmail.com Fri Feb 4 11:18:16 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805293A692E for ; Fri, 4 Feb 2011 11:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.866 X-Spam-Level: X-Spam-Status: No, score=-102.866 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujnZAzD8CcK5 for ; Fri, 4 Feb 2011 11:18:15 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C68233A68FC for ; Fri, 4 Feb 2011 11:18:14 -0800 (PST) Received: by iwc10 with SMTP id 10so2716854iwc.31 for ; Fri, 04 Feb 2011 11:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V7/wXZJpWElcsjFLhh5VY9ce5y6uBEiJh5ekC0q40oA=; b=tlsr7hKg/l5wWNSTQ0Rk1hB7nKCv0Ev5BKT6QwhdH1INRCROt65blWmWuBDPjEDG9X P0BF2NVqtWodjsq7az5X+xjbJkGNJLUgdgKnsdJExfHl56Z7/VcqWkx9j11zV8ChQ/MN rLsTO63IeiLBeQSmWIIBrgHEmGVjnQphZA9OY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=A3yzPZUANNHr0XGAsMBSRlhWm0Ks6CDcuTPreZLiGV2tkXkd0hn5YnpMf76o2Z5ehp znVVSsiUX3iJnzZosJJJqQA2p2n1cud56fFDSGDJ+uYZNiQjuI3YF4beuWRTd6R2OZfh bpXbwtywDH4DslwVQBH8AMKWS/+/7rrOgZT9U= MIME-Version: 1.0 Received: by 10.42.164.73 with SMTP id f9mr14908232icy.156.1296846755756; Fri, 04 Feb 2011 11:12:35 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.34.13 with HTTP; Fri, 4 Feb 2011 11:12:35 -0800 (PST) In-Reply-To: <1296843508.18488.360.camel@hurina> References: <1296843508.18488.360.camel@hurina> Date: Fri, 4 Feb 2011 14:12:35 -0500 X-Google-Sender-Auth: fhtT3FbAxjG6R6HertQQegeRjFE Message-ID: From: Barry Leiba To: Timo Sirainen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: morg Subject: Re: [MORG] draft-ietf-morg-multimailbox-search-05 - WGLC X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 19:18:16 -0000 Hi, Timo. >> =A0 =A0S: * ESEARCH (TAG "tag1" MAILBOX "folder1" UIDVALIDITY 1) UID ALL >> =A0 =A04001,4003,4005,4007,4009 >> =A0 =A0S: * ESEARCH (TAG "tag2" MAILBOX "folder1" UIDVALIDITY 6789023554= ) >> =A0 =A0UID ALL 195001:195004,169788 > > UIDVALIDITY changes rather suddenly in this example, so I think that's > just unnecessary confusion. Also the second one's UID set isn't sorted > as it should be. The UIDVALIDITY change does seem odd. Given the UID ranges, it seems intentional, but a little weird. Alexey, did you have a particular reason for including an example like that, without textual explanation? The sequence set does not need to be sorted; why do you say "as it should be"? According to RFC 3501, sorting it is a "MAY": sequence-set =3D (seq-number / seq-range) *("," sequence-set) ; set of seq-number values, regardless of order. ; Servers MAY coalesce overlaps and/or execute the ; sequence in any order. ; Example: a message sequence number set of ; 2,4:7,9,12:* for a mailbox with 15 messages is ; equivalent to 2,4,5,6,7,9,12,13,14,15 ; Example: a message sequence number set of *:4,5:7 ; for a mailbox with 10 messages is equivalent to ; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and ; overlap coalesced to be 4,5,6,7,8,9,10. I actually think it's good to have an example where they're not sorted, to make sure it's understood that clients MUST deal with that. Barry From tss@iki.fi Fri Feb 4 11:40:00 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E470A3A69D5 for ; Fri, 4 Feb 2011 11:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjUhQdzQnZKE for ; Fri, 4 Feb 2011 11:39:59 -0800 (PST) Received: from dovecot.org (dovecot.org [62.236.108.70]) by core3.amsl.com (Postfix) with ESMTP id 96A3A3A69CF for ; Fri, 4 Feb 2011 11:39:59 -0800 (PST) Received: from [192.168.100.43] (a91-153-29-233.elisa-laajakaista.fi [91.153.29.233]) by dovecot.org (Postfix) with ESMTP id 76F94FA8AEE; Fri, 4 Feb 2011 21:43:24 +0200 (EET) From: Timo Sirainen To: Barry Leiba In-Reply-To: References: <1296843508.18488.360.camel@hurina> Content-Type: text/plain; charset="ISO-8859-15" Date: Fri, 04 Feb 2011 21:43:23 +0200 Message-ID: <1296848603.18488.387.camel@hurina> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: morg Subject: Re: [MORG] draft-ietf-morg-multimailbox-search-05 - WGLC X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 19:40:01 -0000 On Fri, 2011-02-04 at 14:12 -0500, Barry Leiba wrote: > >> S: * ESEARCH (TAG "tag1" MAILBOX "folder1" UIDVALIDITY 1) UID ALL > >> 4001,4003,4005,4007,4009 > >> S: * ESEARCH (TAG "tag2" MAILBOX "folder1" UIDVALIDITY 6789023554) > >> UID ALL 195001:195004,169788 > > > > UIDVALIDITY changes rather suddenly in this example, so I think that's > > just unnecessary confusion. Also the second one's UID set isn't sorted > > as it should be. > > The UIDVALIDITY change does seem odd. Given the UID ranges, it seems > intentional, but a little weird. Alexey, did you have a particular > reason for including an example like that, without textual > explanation? I think textual explanation at least would be good if it's left. > The sequence set does not need to be sorted; why do you say "as it > should be"? According to RFC 3501, sorting it is a "MAY": I thought they were supposed to be sorted in ESEARCH ALL. I even verified it from the RFC, but looks like I just carelessly read what I expected to read instead of what it really read. :) So forget about this. From lehmann@strato-rz.de Sat Feb 5 13:10:50 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5C53A6C1A for ; Sat, 5 Feb 2011 13:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.95 X-Spam-Level: X-Spam-Status: No, score=0.95 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqMl7MNFIoEY for ; Sat, 5 Feb 2011 13:10:49 -0800 (PST) Received: from fredda.webgods.de (fredda.webgods.de [192.166.196.83]) by core3.amsl.com (Postfix) with ESMTP id 0EF103A6C13 for ; Sat, 5 Feb 2011 13:10:45 -0800 (PST) Message-ID: <4D4DBCD3.6000307@strato-rz.de> Date: Sat, 05 Feb 2011 22:10:43 +0100 From: Steffen Lehmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Timo Sirainen References: <4D4ACA2A.3080401@strato-rz.de> <1296844981.18488.385.camel@hurina> In-Reply-To: <1296844981.18488.385.camel@hurina> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: morg@ietf.org Subject: Re: [MORG] POP3 LIST+ Extension: Monitoring for mailbox changes X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 21:10:50 -0000 Hello Timo, >> POP3 clients using the LIST command, and, >> immediately followed, the UIDL command to get the Message Number, >> Message Size and Unique-ID, of all messages of a mailbox, to see if >> new messages have arrived. On large mailboxes, holding hundreds or >> thousands of mails, this causes serious resource consumption on the >> server, and will prolong the duration a mailbox is hold in locked >> state. This situation is even stressed by the fact that POP3 clients >> will usually poll a mailbox for new messages periodically in short >> intervals. > > I agree with the above, but > >> Using the LIST+ Extension, a server has to scan through the mailbox >> only for a single time, and can send the Message Number, Message Size >> and Unique-ID in a more compact form to the client (as shown in >> Appendix A.2.1). > > I don't see this helping all that much with the server's resource > consumption or even much with the client's bandwidth consumption. The > server still has to look up all the sizes and UIDLs. In Appendix A the > client downloads 22% less. To scan through all messages of a mailbox can be a time/CPU/memory consuming task for a server on big mailboxes. Servers do this usually in a loop. This could prevent the server to serve other client connections, while running in this loop (it strongly depends of the server implementation). Using LIST+, the server has to perform only one loop over the mailbox instead of two, to provide the same information. On big mailboxes, polled via slow connections (like Modem, ISDN/E1/BRI, Mobile/GSM/GPRS, Packet Radio, etc.), it could be a "lot of wood" if the server would save 22% output. When I say "big" mailboxes, I speak of mailboxes with about 50.000 messages. In my company, a large ISP provider in Germany, there are several customers having mailboxes as big as this. > Most of the time POP3 clients just poll an unchanged mailbox. It would > be possible to get a much more dramatic bandwidth improvement by being > able to tell clients that nothing had changed since the last time. > Here's an example of how it could work: > > Client connecting for the first time: > > C: LIST +UIDL > S: +OK 14758f1afd44c09b7992073ccf00b43d 3 messages, listing follows: > S: 1 4536 7abcb6f4da22080e121f2824aef2be9a > S: 2 4422 577151e65ea4e62bb9b1c5830a818fe7 > S: 3 3828 2fe542ac6d1c29bb6a5161558f527e2e > S: . > > Client connecting the second time when there are no changes: > > C: LIST +UIDL +ID=14758f1afd44c09b7992073ccf00b43d > S: +OK 14758f1afd44c09b7992073ccf00b43d No changes > S: . > > Client connecting the 3rd time when there are changes: > > C: LIST +UIDL +ID=14758f1afd44c09b7992073ccf00b43d > S: +OK ddd2cae8a4a5ec890737d07adb537b99 4 messages, listing follows: > S: 1 4536 7abcb6f4da22080e121f2824aef2be9a > S: 2 4422 577151e65ea4e62bb9b1c5830a818fe7 > S: 3 3828 2fe542ac6d1c29bb6a5161558f527e2e > S: 4 3284 86519edbbe78d203c5c9618df50b21a7 > S: . > > So, the client would just remember the value after the "OK". The server > can use whatever value it wants there, but one simple possibility would > be to just use a hash(all UIDLs). > > This could be made to save more bandwidth by allowing server to send > only changes based on the given ID, such as: > > C: LIST +UIDL +ID=14758f1afd44c09b7992073ccf00b43d > S: +OK ddd2cae8a4a5ec890737d07adb537b99 1 new message: > S: 4 3284 86519edbbe78d203c5c9618df50b21a7 > S: . > > Deleted messages could also be reported by adding more complexity. > This is an interesting idea. But doing it using the ID as proposed raises a couple problems: Hashes are no unique value. If this ID is a hash as proposed, the server has to compare its value with that hash it is just generating inside the loop on every line. Unfortunately, hash functions must be "finalized" to get the hash function output. If the hash does't match, the server hash to start the hash function again, and has to put in all data from the beginning up to the current line into the hash function again. This would be overkill, and makes using of a hash impractical for this purpose. A better way would be, the client tells the sever the tuple of message-number/UIDL of the very last message it knows. The server can easily compare this two values with the message-number/UIDL tuple of every message inside the loop, i.e.: Client connecting for the first time: C: LIST +UIDL +AGE +UNSEEN S: +OK S: 1 4536 7abcb6f4da22080e121f2824aef2be9a 32 16 S: 2 4422 577151e65ea4e62bb9b1c5830a818fe7 30 0 S: 3 3828 2fe542ac6d1c29bb6a5161558f527e2e 0 0 S: . The server has to send all messages, because of no message-number/UIDL tuple was given. The client does also fetch the AGE and UNSEEN values and stores it (these values are in units of days, so the client needs to fetch them ony one time per day). Client connecting the second time when there are no changes. Client sends UIDL with a message-number/UIDL tuple of the last message: C: LIST +UIDL=3/2fe542ac6d1c29bb6a5161558f527e2e S: +OK S: 3 3828 2fe542ac6d1c29bb6a5161558f527e2e S: . In this case, the server only sends the last message. The client can easily determine that this message is already known, and ignore it. Sending a non-empty list is necessary to indicate that there are still messages in the mailbox, an empty list would indicate an empty mailbox. Client connecting the 3rd time when a new message arrived, (but no other changes): C: LIST +UIDL=3/2fe542ac6d1c29bb6a5161558f527e2e S: +OK S: 4 3284 86519edbbe78d203c5c9618df50b21a7 S: . Only the new message(s) will be listed. 4/86519edbbe78d203c5c9618df50b21a7 becomes the new tuple. Client connecting the 4th time when message 3 was deleted by another client: C: LIST +UIDL=4/86519edbbe78d203c5c9618df50b21a7 S: +OK S: 1 4536 7abcb6f4da22080e121f2824aef2be9a S: 2 4422 577151e65ea4e62bb9b1c5830a818fe7 S: 3 3284 86519edbbe78d203c5c9618df50b21a7 S: . Former message 4 becomes message 3. The sever sends a complete list. 3/86519edbbe78d203c5c9618df50b21a7 becomes the new tuple. Client connecting the 5th time when all messages were deleted by another client: C: LIST +UIDL=3/86519edbbe78d203c5c9618df50b21a7 S: +OK S: . The server sends a complete list, which is empty in this case. The following rules apply: 1. The server has to send a complete message listing in following cases: - LIST command without +UIDL Flag, - +UIDL Flag without parameter - +UIDL Flag with parameter, but the server cannot find a message with matching message-number/UIDL tuple. This happens if messages on the server were deleted, resulting in renumbering of all messages above the deleted message. Renumbering the messages invalidates the message-number/UIDL tuples of all messages with message-numbers above the delete message. 2. When client's message-number/UIDL tuple matches the one of server's last message, the server just issues the last message. This indicates that there are no changes in the mailbox. 3. If client's message-number/UIDL tuple matches with the one of any message on the server, and this is not the last message, the server issues all messages having message-numbers greater than the message-number as indicated in the tuple (which are, in fact, all newly arrived messages). 4. If the client receives a message listing whose first message-number is one, or if the client receives an empty message listing, it MUST consider this message listing as a "complete" message listing. All messages known by the server are included in this message listing. 5. If the client receives a message listing whose first message-number is greater than one, it MUST consider this message listing as a "partial" message listing. The server should keep knowledge of all messages it already knows, and should add knowledge of all messages it does not already know. Note: The term "changes in a mailbox" means either message deletion or message delivery. Changes in the values of the +AGE and +UNREAD Flags, or any other meta data, cannot be monitored in this way. Monitoring of message deletion would require a more sophisticated approach. It has to create a context on the server, having an unique ID, where the server can store information about the state of each client. In IMAP, this state is represented by the client connection, but as with POP3, clients usually disconnect immediately after information retrieval, so the client connection cannot be used for this purpose. IMHO, this would things make too complex. Because most of the time POP3 clients just poll an unchanged mailbox, the mechanism as proposed above has already enough potential to reduce bandwith drastically. >> The +UNREAD Flag requests to add the number of whole days, since the >> message was read for last time, to the extended scan listing. > > What exactly is the "last read time" for a message? RETR time? When it > was marked as \Seen in webmail/IMAP? > I want to rename the +UNREAD Flag to +LASTREAD, and introduce another Flag +FIRSTREAD. This offers more flexibility for POP3 client developers, when they want to use these values as input for different kinds of automatic message deletion processes. The meaning would be: +FIRSTREAD: The time when the message was read for very first time (when i.e. IMAP sets the \Seen flag) +LASTREAD: The time when the message was read the very last time. In POP3, a message is to be considered as "read" after a successful RETR command has been issued for that message. Reading a message with the TOP command shall not mark a message as "read", even if all body lines were read. Steffen From mrc+ietf@panda.com Sat Feb 5 13:29:19 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B0C3A69E9 for ; Sat, 5 Feb 2011 13:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP26sLxT7IGt for ; Sat, 5 Feb 2011 13:29:18 -0800 (PST) Received: from Panda.COM (panda.com [206.124.149.114]) by core3.amsl.com (Postfix) with ESMTP id 038B73A696F for ; Sat, 5 Feb 2011 13:29:18 -0800 (PST) Received: from hsinghsing.panda.com ([206.124.149.116]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Sat, 05 Feb 2011 13:29:14 -0800 X-MailFrom: mrc+ietf@panda.com Date: Sat, 5 Feb 2011 13:29:13 -0800 (PST) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: morg@ietf.org In-Reply-To: <4D4DBCD3.6000307@strato-rz.de> Message-ID: References: <4D4ACA2A.3080401@strato-rz.de> <1296844981.18488.385.camel@hurina> <4D4DBCD3.6000307@strato-rz.de> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [MORG] POP3 LIST+ Extension: Monitoring for mailbox changes X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 21:29:19 -0000 On Sat, 5 Feb 2011, Steffen Lehmann wrote: > To scan through all messages of a mailbox can be a time/CPU/memory > consuming task for a server on big mailboxes. This discussion is fascinating, but it begs the question: If you care about such matters, why use POP3 and not IMAP? POP3 does a certain specific task, and it does that task well. POP3 was never intended for any other task. Each new extension (to either IMAP or POP3) creates new client/server incompatibility paths. You may think that you are staying on top of things by implementing every extension, no matter how minimal the market requirement. You learn otherwise when your customers slam you over interoperability problems that are fixed only by disabling the extension in your product. I can't help but thing that MORG has devolved into a group of people desperate to stay on the gravy train of Building New Email Protocols, never mind that the train has become increasingly irrelevant. The more realistic only care about placing a veneer of "IETF approval" on a private mechanism for their client/server products. But then there are the others, who live in a true Fantasy Land in which everybody will presently implement all 69 random extensions. This disease isn't confined to MORG either. The entire IETF suffers from it. I am thoroughly enjoying the IPv6 debacle as it unfolds, and look forward to many years of entertainment. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From lehmann@strato-rz.de Sun Feb 6 00:48:08 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B024E3A6874 for ; Sun, 6 Feb 2011 00:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[AWL=1.599, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLVWVng3nW-3 for ; Sun, 6 Feb 2011 00:48:08 -0800 (PST) Received: from fredda.webgods.de (fredda.webgods.de [192.166.196.83]) by core3.amsl.com (Postfix) with ESMTP id ABC553A687F for ; Sun, 6 Feb 2011 00:48:07 -0800 (PST) Message-ID: <4D4E6047.7070404@strato-rz.de> Date: Sun, 06 Feb 2011 09:48:07 +0100 From: Steffen Lehmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Crispin References: <4D4ACA2A.3080401@strato-rz.de> <1296844981.18488.385.camel@hurina> <4D4DBCD3.6000307@strato-rz.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: morg@ietf.org Subject: Re: [MORG] POP3 LIST+ Extension: Monitoring for mailbox changes X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 08:48:08 -0000 Am 05.02.2011 22:29, schrieb Mark Crispin: >> To scan through all messages of a mailbox can be a time/CPU/memory >> consuming task for a server on big mailboxes. > > This discussion is fascinating, but it begs the question: > > If you care about such matters, why use POP3 and not IMAP? About 80% our customers are using POP3, 20% IMAP. The decision, whether to use POP3 or IMAP, is not ours. > POP3 does a certain specific task, and it does that task well. POP3 was > never intended for any other task. I think you have never seen a customer using POP3 tryig desperately regain control over his mailbox when mailbox is under heavy load, perhaps due to a mailbomb attack, or simply because the customer has accidentally created an automatic mail responder ping-pong or a mail-forward loop. The only remaining chance is to call the ISP and beg for help. With POP3 - no chance. As long as customers use POP3, for whatever reasons, we should try to improve it, if possible. > Each new extension (to either IMAP or POP3) creates new client/server > incompatibility paths. You may think that you are staying on top of > things by implementing every extension, no matter how minimal the market > requirement. You learn otherwise when your customers slam you over > interoperability problems that are fixed only by disabling the extension > in your product. I (carefully) agree. But this can be avoided by well-engeneered extensions and well-tested implementations. > I can't help but thing that MORG has devolved into a group of people > desperate to stay on the gravy train of Building New Email Protocols, > never mind that the train has become increasingly irrelevant. > > The more realistic only care about placing a veneer of "IETF approval" on > a private mechanism for their client/server products. But then there are > the others, who live in a true Fantasy Land in which everybody will > presently implement all 69 random extensions. > > This disease isn't confined to MORG either. The entire IETF suffers from > it. I am thoroughly enjoying the IPv6 debacle as it unfolds, and look > forward to many years of entertainment. There is still a third group, trying honestly to improve things. Nobody (nothing) is perfect. Steffen From mrc+ietf@panda.com Sun Feb 6 09:55:00 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 915BE3A695F for ; Sun, 6 Feb 2011 09:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+UyVcEQDmjx for ; Sun, 6 Feb 2011 09:54:59 -0800 (PST) Received: from Panda.COM (panda.com [206.124.149.114]) by core3.amsl.com (Postfix) with ESMTP id 3A5D53A68CB for ; Sun, 6 Feb 2011 09:54:59 -0800 (PST) Received: from Shimo-Tomobiki.Panda.COM ([192.107.14.1]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Sun, 06 Feb 2011 09:54:54 -0800 X-MailFrom: mrc+ietf@panda.com Date: Sun, 6 Feb 2011 09:54:48 -0800 From: Mark Crispin To: Steffen Lehmann In-Reply-To: <4D4E6047.7070404@strato-rz.de> Message-ID: References: <4D4ACA2A.3080401@strato-rz.de> <1296844981.18488.385.camel@hurina> <4D4DBCD3.6000307@strato-rz.de> <4D4E6047.7070404@strato-rz.de> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) Sender: mrc@panda.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: morg@ietf.org Subject: Re: [MORG] POP3 LIST+ Extension: Monitoring for mailbox changes X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 17:55:00 -0000 On Sun, 6 Feb 2011, Steffen Lehmann wrote: > About 80% our customers are using POP3, 20% IMAP. The decision, whether > to use POP3 or IMAP, is not ours. You are making a staggering assumption: that your customers' decision is one to use POP3 vs. IMAP. I submit that the vast majority of your customers don't decide in those terms at all. Rather, their decision is to use certain software, whether due to comfort or inertia. Often, other than to getting it to function, they haven't spent much time in configurating their software. Put another way: most of your customers don't know a POP3 from an IMAP from a Bombastic Blurdybloop; and even if you told them they wouldn't care. You may be able to get some your customers to change the POP3/IMAP checkbook in their software on the grounds that it will "improve performance". Your odds of success increase if you give them specific instructions, with screen shots, on how to do it in their specific software. > I think you have never seen a customer using POP3 tryig desperately > regain control over his mailbox You are making a second staggering assumption: that a person who has been a professional in the email industry for over 30 years is somehow ignorant of such matters. > As long as customers use POP3, for whatever reasons, we should try to > improve it, if possible. This is the third staggering assumption: that by having IETF produce a document, you will somehow achieve technological progress for your users. It assumes that the vendors of client used by your users, and the vendor of your server, all implement this extension; that these implementations all interoperate; and that your users promptly upgrade to the new version of their client software. There are huge barriers in the way. The greatest of these is that there is no particular incentive for vendors to do it; and there are severe disincentives to vendors. Any extension to POP3 (or IMAP), no matter how trivial, requires hundreds of hours of time in R&D and testing. We're talking a great deal of money; and a compelling business case has to be made for it. Perhaps unlike you, I have dealt with getting engineering changes through the likes of Microsoft, Google, and Apple. The timeframe for getting things through these guys is measured in years; and that is when there is a compelling business case. There is none here. Nor do you particularly want them implementing your extension. It is virtually guaranteed that if they do it, it will be in a way that breaks your other implementations. Microsoft and Google especially are of the attitude that their software constitutes the "standard"; and that if some RFC disagrees it's a bug in the RFC. You may get a "free software" implementation or two to implements it. Even these are impacted by "it works fine with the competition" bug/regression report caused by implementation incompatibilities. > I (carefully) agree. But this can be avoided by well-engeneered > extensions and well-tested implementations. Any talk about new POP3 extensions (and arguably also IMAP extensions) is mental masturbation. The only business case that exists for extensions any more is to foil an attempt to bias competitive procurement in government purchases that writes in a requirement for some obscure RFC. I've seen RFPs that stipulated RFC 748 compliance! The end result of work on a POP3 extension is an obscure document, that may make it to an RFC, that hardly anyone ever implemented and is consigned to the scrap heap of history. There is a large pile of such documents in the IETF. I wrote some, long ago. The pile is growing. Adding to the pile will not solve your problem. You will presently be forced to seek another (hopefully more effective) solution, and come to realize that your work on this beautiful POP3 extension was a complete waste of your time. I am doing you a favor. Feel free to disregard it. You will learn either sooner, or later. The choice is yours. -- Mark -- http://panda.com/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. From lehmann@strato-rz.de Sun Feb 6 11:21:41 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FA3B3A69E0 for ; Sun, 6 Feb 2011 11:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOM4fuJcYJvL for ; Sun, 6 Feb 2011 11:21:40 -0800 (PST) Received: from fredda.webgods.de (fredda.webgods.de [192.166.196.83]) by core3.amsl.com (Postfix) with ESMTP id 931C23A6970 for ; Sun, 6 Feb 2011 11:21:40 -0800 (PST) Message-ID: <4D4EF4C4.1080002@strato-rz.de> Date: Sun, 06 Feb 2011 20:21:40 +0100 From: Steffen Lehmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Crispin References: <4D4ACA2A.3080401@strato-rz.de> <1296844981.18488.385.camel@hurina> <4D4DBCD3.6000307@strato-rz.de> <4D4E6047.7070404@strato-rz.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: morg@ietf.org Subject: Re: [MORG] POP3 LIST+ Extension: Monitoring for mailbox changes X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 19:21:41 -0000 Am 06.02.2011 18:54, schrieb Mark Crispin: >> I think you have never seen a customer using POP3 tryig desperately >> regain control over his mailbox > > You are making a second staggering assumption: that a person who has been > a professional in the email industry for over 30 years is somehow ignorant > of such matters. I bed your pardon. Steffen From tss@iki.fi Sun Feb 6 13:00:30 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6FC43A69DA for ; Sun, 6 Feb 2011 13:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y92tjD2O3tpn for ; Sun, 6 Feb 2011 13:00:29 -0800 (PST) Received: from dovecot.org (dovecot.org [62.236.108.70]) by core3.amsl.com (Postfix) with ESMTP id 293363A69AE for ; Sun, 6 Feb 2011 13:00:29 -0800 (PST) Received: from [192.168.100.12] (a91-153-29-233.elisa-laajakaista.fi [91.153.29.233]) by dovecot.org (Postfix) with ESMTP id 538C7FA8A4F; Sun, 6 Feb 2011 23:00:29 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <4D4DBCD3.6000307@strato-rz.de> Date: Sun, 6 Feb 2011 23:00:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <97BC70CA-027E-4DE9-A16C-80ACF9A40883@iki.fi> References: <4D4ACA2A.3080401@strato-rz.de> <1296844981.18488.385.camel@hurina> <4D4DBCD3.6000307@strato-rz.de> To: Steffen Lehmann X-Mailer: Apple Mail (2.1082) Cc: morg@ietf.org Subject: Re: [MORG] POP3 LIST+ Extension: Monitoring for mailbox changes X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 21:00:31 -0000 On 5.2.2011, at 23.10, Steffen Lehmann wrote: >> So, the client would just remember the value after the "OK". The = server >> can use whatever value it wants there, but one simple possibility = would >> be to just use a hash(all UIDLs). .. > But doing it using the ID as proposed raises a couple problems: >=20 > Hashes are no unique value. It wouldn't have to be a hash. It was just an example. > A better way would be, the client tells the sever the tuple of > message-number/UIDL of the very last message it knows. A server implementation would be free to use that as the ID as well. It = has one problem though: message UIDLs are not guaranteed to be always = unique (even POP3 RFC mentions this), so this has the potential of = missing changes in some situations. So I'd prefer that there was no = enforcement of a specific format for the ID to allow more flexible = server implementations. I doubt it's too much to ask for clients to = store one extra string for it. > +LASTREAD: The time when the message was read the very last time. > In POP3, a message is to be considered as "read" after a successful = RETR > command has been issued for that message. Reading a message with the = TOP > command shall not mark a message as "read", even if all body lines = were > read. Clients might become disconnected before RETR is complete. Server = wouldn't then necessarily know if message was fully received by the = client. Would that still be a successful RETR?= From tss@iki.fi Sun Feb 6 13:06:05 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D423A6A0B for ; Sun, 6 Feb 2011 13:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbaso2Z0e1qY for ; Sun, 6 Feb 2011 13:06:05 -0800 (PST) Received: from dovecot.org (dovecot.org [62.236.108.70]) by core3.amsl.com (Postfix) with ESMTP id DF6823A69DA for ; Sun, 6 Feb 2011 13:06:04 -0800 (PST) Received: from [192.168.100.12] (a91-153-29-233.elisa-laajakaista.fi [91.153.29.233]) by dovecot.org (Postfix) with ESMTP id C0397FA8A57; Sun, 6 Feb 2011 23:06:06 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Sun, 6 Feb 2011 23:06:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D4ACA2A.3080401@strato-rz.de> <1296844981.18488.385.camel@hurina> <4D4DBCD3.6000307@strato-rz.de> <4D4E6047.7070404@strato-rz.de> To: Mark Crispin X-Mailer: Apple Mail (2.1082) Cc: Steffen Lehmann , morg@ietf.org Subject: Re: [MORG] POP3 LIST+ Extension: Monitoring for mailbox changes X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 21:06:05 -0000 On 6.2.2011, at 19.54, Mark Crispin wrote: > It assumes that the vendors of client used by your users, and the = vendor > of your server, all implement this extension; that these = implementations > all interoperate; and that your users promptly upgrade to the new = version > of their client software. There's one other possibility also that doesn't involve changing the = client: User installing a transparent local POP3 proxy that talks = regular old POP3 (or IMAP) to the client but an extended protocol to the = remote server. Of course there wouldn't be a whole lot of users doing = this, but it's a possibility for some motivated ones. From lehmann@strato-rz.de Wed Feb 9 05:19:20 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98223A69C3 for ; Wed, 9 Feb 2011 05:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.416 X-Spam-Level: X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzpUNUccMgIv for ; Wed, 9 Feb 2011 05:19:20 -0800 (PST) Received: from fredda.webgods.de (fredda.webgods.de [192.166.196.83]) by core3.amsl.com (Postfix) with ESMTP id ACEFF3A69B9 for ; Wed, 9 Feb 2011 05:19:19 -0800 (PST) Message-ID: <4D5293EB.3060509@strato-rz.de> Date: Wed, 09 Feb 2011 14:17:31 +0100 From: Steffen Lehmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Timo Sirainen References: <4D4ACA2A.3080401@strato-rz.de> <1296844981.18488.385.camel@hurina> <4D4DBCD3.6000307@strato-rz.de> <97BC70CA-027E-4DE9-A16C-80ACF9A40883@iki.fi> In-Reply-To: <97BC70CA-027E-4DE9-A16C-80ACF9A40883@iki.fi> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: morg@ietf.org Subject: Re: [MORG] POP3 LIST+ Extension: Monitoring for mailbox changes X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 13:19:20 -0000 On 06.02.2011, at 22:00, Timo Sirainen wrote: > On 5.2.2011, at 23.10, Steffen Lehmann wrote: > >>> So, the client would just remember the value after the "OK". The server >>> can use whatever value it wants there, but one simple possibility would >>> be to just use a hash(all UIDLs). > .. >> But doing it using the ID as proposed raises a couple problems: >> >> Hashes are no unique value. > It wouldn't have to be a hash. It was just an example. > >> A better way would be, the client tells the sever the tuple of >> message-number/UIDL of the very last message it knows. > A server implementation would be free to use that as the ID as well. It has one problem though: message UIDLs are not guaranteed to be always unique (even POP3 RFC mentions this), so this has the potential of missing changes in some situations. So I'd prefer that there was no enforcement of a specific format for the ID to allow more flexible server implementations. I doubt it's too much to ask for clients to store one extra string for it. I agree. Using an ID offers most flexibility regarding server's implementation. >> +LASTREAD: The time when the message was read the very last time. >> In POP3, a message is to be considered as "read" after a successful RETR >> command has been issued for that message. Reading a message with the TOP >> command shall not mark a message as "read", even if all body lines were >> read. > Clients might become disconnected before RETR is complete. Server wouldn't then necessarily know if message was fully received by the client. Would that still be a successful RETR? The server has, for my opinion, five options, when the FIRSTREAD/LASTREAD values could be set: 1. After a successful RETR command (just before the server sends the terminating "." line). 2. After a successful RETR command (just after the server has sent the terminating "." line). 3. After a successful RETR command, when the server receives the next valid command, 4. After a successful RETR command, when the server enters the UPDATE state. 5. On behalf of the client, using any new "set" command. All five options have a time window, each of different duration, when something may happen, resulting in a FIRSTREAD/LASTREAD value not representing the actual state. Option 1: - The client might crash before finishing message processing. - The server might crash after it has updated the FIRSTREAD/LASTREAD value, but before it has sent the terminating "." line. Option 2: - The client might crash before it has finished message processing. - The server might crash after it has sent the terminating "." line, but before it has updated the FIRSTREAD/LASTREAD value. Option 3-5: - It doesn't guarantee the client has read the message (the client could have sent the next/QUIT/"set" command before finishing message processing; PIPELINING could be used). - The server might crash before the next command arrives. Unfortunately, there is no reliable option. But the FIRSTREAD value could be used by clients to make a decision like "don't retrieve messages which are marked as 'already read'". Using the FIRSTREAD value in this manner could result in never-read messages (if the server has updated the FIRSTREAD value, but the client crashed). On the other hand, If a FIRSTREAD values was not updated due to a server crash, and a client has a rule like "delete never-read messages after xx days", this could delete a message, although this message was read. Therefore, I think, it would be better not to introduce a FIRSTREAD value, and to leave the UNREAD value as it is. With the UNREAD value, things are not this dramatic as with FIRSTREAD. I prefer option 1. Option 1 ensures, that the UNREAD value will be updated in any case. Even if the server has updated the UNSET value, but the client has never seen the message (i.e. due to a crash), the updated UNREAD value indicates that someone is still interested in this message. The text "The +UNREAD Flag requests to add the number of whole days, since the message was read for last time, to the extended scan listing." should be changed to "The +UNREAD Flag requests to add the number of whole days, since the message was tried to read for last time, to the extended scan listing." -- Steffen From barryleiba.mailing.lists@gmail.com Wed Feb 9 08:45:40 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3C13A65A5; Wed, 9 Feb 2011 08:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEx-f5R4rN5J; Wed, 9 Feb 2011 08:45:39 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id E7F333A63CA; Wed, 9 Feb 2011 08:45:38 -0800 (PST) Received: by iym1 with SMTP id 1so364238iym.31 for ; Wed, 09 Feb 2011 08:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YKXBZ/BAEP3NaV7TK4POoMHVtx9ZArm5Lzd4wHqZPg0=; b=gkyHaqst0/PcbU3UDpZHaoDh36gIhiXTbpSCwi8sfIXPoX59f4uOfzQAOzXxv5C+vU 9e9RTAXjqsNVnuGWP7AW0VBmpcxkbMRK4MxzAVrlhFY/gcAccJZavn+f83/EoglNiPRd y0NspE85OMCTrTn5u2iiDZ8CiFl4AmxoTZgcM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=E9DPUhcgX/zTg7BvmvG89CxVXSCf3V9uAXJHuoga4miLBw3Yb7dVxRqqU8zLNIov8+ gsg5v0mtAbc4WV9/yt/PlBT0KT6PpbNPt5ktJjLjmKy4SdYcAhqpWhE/mq15bfCEyXyA wAyhIYVFOeM7qUppcno/IpfobVhviOsLVuJlY= MIME-Version: 1.0 Received: by 10.42.221.4 with SMTP id ia4mr22012665icb.400.1297269948564; Wed, 09 Feb 2011 08:45:48 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.228.74 with HTTP; Wed, 9 Feb 2011 08:45:48 -0800 (PST) In-Reply-To: <4D4ACA2A.3080401@strato-rz.de> References: <4D4ACA2A.3080401@strato-rz.de> Date: Wed, 9 Feb 2011 11:45:48 -0500 X-Google-Sender-Auth: 29QKpaURe1I42BasahfXvei5maA Message-ID: From: Barry Leiba To: Steffen Lehmann Content-Type: text/plain; charset=ISO-8859-1 Cc: morg@ietf.org, apps-discuss@ietf.org Subject: Re: [MORG] [apps-discuss] New draft at MORG: POP3 LIST+ Extension X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 16:45:40 -0000 > there is a new draft at > http://datatracker.ietf.org/doc/draft-lehmann-morg-pop3listplus/ > describing the "POP3 LIST+ Extension". > > Although it is related to POP3 instead of IMAP, I have put it into MORG, > because MORG's goals are fitting best. [Barry, as chair] I'll add, for those who aren't aware, that Steffen approached the MORG chairs to ask if it were appropriate to discuss this draft on the MORG list, and we said that we think it is. That does not mean that the document will be picked up by the MORG working group, which is wrapping up its work and is not likely to recharter. But we think the right people will see these messages on the MORG and APPSAWG lists. [Barry, as participant] I like this draft, and I think it would have been a useful extension if presented years ago. I'm not sure how useful it will be now; as Mark has pointed out, it'll be hard to get implementations, and then hard to get everyone to upgrade or change to server and client versions that support it. Most modern servers and clients support both POP and IMAP, and need no changes to have users switch to IMAP (especially for the more involved functions that are being discussed on the other thread. I think it's likely to be easier, when users need to use your servers as large-scale message stores, with their clients holding local caches and doing complex synchronization, to give those users instructions on switching to IMAP, rather than to have them change their client software (upgrade or switch entirely). Reconfiguring for IMAP is a few-minute task with little risk, and clear instructions for doing it on the most popular clients can be published, minimizing the support costs. Further, switching users to IMAP is a much more robust solution than trying to make POP into a sort of "IMAP light". I *strongly* advise against that, and suggest that the discussion going on in the other thread is not useful. But even this modest version, which is clever and concise, and which makes perfect sense, is unlikely to be useful in practice for several years, at least, and may well never get enough deployment to be useful. I'd feel much better if we saw a bunch of client and server implementors post here and say that they'd implement this soon, if it were standardized. In particular, on the client side, unless this is implemented in Outlook, Thunderbird, and Apple Mail (all three), I think it's swimming upstream. To the spec itself: as Mykyta says, the IANA considerations section needs to be made into proper instructions to IANA, if this goes forward. I recommend that you not bother with that until we're more certain that it will go forward... the IANA details can be filled in later. I see one technical point that I wonder about: The combination of AGE and UNREAD *almost* tells you what you need to know, I think. If AGE > UNREAD, you know the message was downloaded, perhaps on another client. But if AGE == UNREAD, you aren't sure. It would be nice if that were clear. Perhaps a special value of UNREAD (such as "-1") would work to indicate that the message has never been RETRieved. (And, yes, as Timo points out, the spec should make it clear what "read" means, even if it says that it's an implementation choice.) Barry From mrc+ietf@panda.com Wed Feb 9 09:05:42 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7A943A67C2; Wed, 9 Feb 2011 09:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UwHKbNKK24l; Wed, 9 Feb 2011 09:05:41 -0800 (PST) Received: from Panda.COM (panda.com [206.124.149.114]) by core3.amsl.com (Postfix) with ESMTP id A2DCC3A67D8; Wed, 9 Feb 2011 09:05:41 -0800 (PST) Received: from hsinghsing.panda.com ([206.124.149.116]) by Panda.COM ([192.107.14.50]) with ESMTP via TCP; Wed, 09 Feb 2011 09:05:35 -0800 X-MailFrom: mrc+ietf@panda.com Date: Wed, 9 Feb 2011 09:05:33 -0800 (PST) From: Mark Crispin Sender: mrc@hsinghsing.panda.com To: Barry Leiba In-Reply-To: Message-ID: References: <4D4ACA2A.3080401@strato-rz.de> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Steffen Lehmann , morg@ietf.org, apps-discuss@ietf.org Subject: Re: [MORG] [apps-discuss] New draft at MORG: POP3 LIST+ Extension X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:05:43 -0000 On Wed, 9 Feb 2011, Barry Leiba wrote: > Further, switching users to IMAP is a much more robust solution than > trying to make POP into a sort of "IMAP light". I *strongly* advise > against that, and suggest that the discussion going on in the other > thread is not useful. But even this modest version, which is clever > and concise, and which makes perfect sense, is unlikely to be useful > in practice for several years, at least, and may well never get enough > deployment to be useful. Indeed. There is little, if anything, technically wrong with this document. It is well written, and well thought-out. It is simply (at least) 15 years too late. Unfortunately, no matter how technically excellent a specification may be, a specification that is too late is doomed to failure. Barry is being kind in saying that it "is unlikely to be useful in practice for several years, at least, and may well never get enough deployment to be useful." The reality is harsher. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. From alexey.melnikov@isode.com Wed Feb 9 13:26:53 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C4EF3A6866 for ; Wed, 9 Feb 2011 13:26:53 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2WiepQ+Amtz for ; Wed, 9 Feb 2011 13:26:52 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 230C63A6925 for ; Wed, 9 Feb 2011 13:26:43 -0800 (PST) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 9 Feb 2011 21:26:52 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D530665.6000609@isode.com> Date: Wed, 09 Feb 2011 21:25:57 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Timo Sirainen References: <1296843508.18488.360.camel@hurina> In-Reply-To: <1296843508.18488.360.camel@hurina> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: morg , Barry Leiba Subject: Re: [MORG] draft-ietf-morg-multimailbox-search-05 - WGLC X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:26:53 -0000 Timo Sirainen wrote: >On Tue, 2011-01-25 at 12:43 -0500, Barry Leiba wrote: > > >>We're halfway through the WGLC period, and have had no comments. >>Please, let's get at least two or three reviews of this version, and >>confirm (or refute) that it's ready to go. >> >> >Pretty quiet in here.. I've anyway reviewed. Just one thing: > > >> S: * ESEARCH (TAG "tag1" MAILBOX "folder1" UIDVALIDITY 1) UID ALL >> 4001,4003,4005,4007,4009 >> S: * ESEARCH (TAG "tag2" MAILBOX "folder1" UIDVALIDITY 6789023554) >> UID ALL 195001:195004,169788 >> >> >UIDVALIDITY changes rather suddenly in this example, so I think that's >just unnecessary confusion. > Good point. Should be UIDVALIDITY 1 on the second quoted line as well. >Also the second one's UID set isn't sorted >as it should be. > From bienvenu@davidbienvenu.org Wed Feb 9 13:44:51 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470243A6903 for ; Wed, 9 Feb 2011 13:44:51 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vd+KN+lHsF7Z for ; Wed, 9 Feb 2011 13:44:50 -0800 (PST) Received: from homiemail-a19.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 230043A6866 for ; Wed, 9 Feb 2011 13:44:50 -0800 (PST) Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 6690E60407C; Wed, 9 Feb 2011 13:45:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=davidbienvenu.org; h=message-id :date:from:reply-to:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; q=dns; s= davidbienvenu.org; b=p4udZayb8g9l2QRaRt+tvXbbJg7QIpJul9v1SkHcJQj FopNMSkUJ550+4uCn7ZYz2EK5bI1tB855KKKEufMObhRnmosiQxnJzZpXAqfiQtP dTqxkQcPLmuDpJ44Uv3TtJn6OYT52wLrh+IzYUsCa5lAL+/88tRPCO+1VGsfv/GM = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=davidbienvenu.org; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; s=davidbienvenu.org; bh=7cXbOsyglmkpblDzWIeYFaevK3Y=; b=UDZIIEm TK5j4I4TVDQfiZB0A0nu7PjkHpVrjNPZChvSplhcuIcicaBjhWx86f0jjnLV4hUK wH6px3UkrRnuV/t/CnyBuzgMmdjaI7xTLiL51zXWZ2coGfEi9E9UYmmcCY3d7Y8F asSaCwo0fOqzsE0pRqjt5S1YSJ9GIWvdmV4I= Received: from [192.168.1.4] (c-24-5-68-155.hsd1.ca.comcast.net [24.5.68.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bienvenu@davidbienvenu.org) by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 3C863604069; Wed, 9 Feb 2011 13:45:00 -0800 (PST) Message-ID: <4D530B03.4050401@davidbienvenu.org> Date: Wed, 09 Feb 2011 13:45:39 -0800 From: David Bienvenu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110207 Thunderbird/3.3a3pre MIME-Version: 1.0 To: morg@ietf.org References: <4D4ACA2A.3080401@strato-rz.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Steffen Lehmann Subject: Re: [MORG] [apps-discuss] New draft at MORG: POP3 LIST+ Extension X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bienvenu@davidbienvenu.org List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:44:51 -0000 On 2/9/2011 8:45 AM, Barry Leiba wrote: > I'd feel much better if we saw a bunch of client and server > implementors post here and say that they'd implement this soon, if it > were standardized. In particular, on the client side, unless this is > implemented in Outlook, Thunderbird, and Apple Mail (all three), I > think it's swimming upstream. I've told Steffen that I'd be interesting in either adding support for this to Thunderbird, or helping someone else add it, since it should be relatively easy to add. Condstore-like capability would also be easy to add. We still have a lot of POP3 users, despite our IMAP bias. - David From barryleiba@gmail.com Wed Feb 9 13:59:59 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A56ED3A6A07 for ; Wed, 9 Feb 2011 13:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1BXq4UlhIai for ; Wed, 9 Feb 2011 13:59:59 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D9E3C3A687D for ; Wed, 9 Feb 2011 13:59:58 -0800 (PST) Received: by iwc10 with SMTP id 10so655266iwc.31 for ; Wed, 09 Feb 2011 14:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H3HMj1cvbFHPa4RZZxpPt1xcJSDMLtWCN0lhXvs/pk4=; b=XK6qbnKBX9qFvDuyBQOPhAKYq4+VbyhL5T27C7tlz+800jMB/HsGgs1vcjaMGXwAj1 Y05dPN8ESJmjhAPo0le/ZGU3QyZsZLSkinUoKg0RqK2ssBmbbWpwfmwuEXDj6Si75oJZ HSLMhSCBYJeEmGjLN4Hl+1hlSbsEiy74rLAsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=mWV5B2P8YVd9P5gbkr/mqqhPAGNmt3LjfbL+KFXPdfWHxSP/WZH1eZ3tIsuT8QExL3 GGahMKD42jADb5Oas/UfZEAkDV81mm57MBtGyyYyxWMriFv7noRI4L61e1uYuzu8IW9j 4lxPc6Qd1yHnqwiLJ3Jf7rzhrFha4QoufjD/M= MIME-Version: 1.0 Received: by 10.231.12.131 with SMTP id x3mr21442966ibx.76.1297288809130; Wed, 09 Feb 2011 14:00:09 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.34.13 with HTTP; Wed, 9 Feb 2011 14:00:09 -0800 (PST) In-Reply-To: <4D530665.6000609@isode.com> References: <1296843508.18488.360.camel@hurina> <4D530665.6000609@isode.com> Date: Wed, 9 Feb 2011 17:00:09 -0500 X-Google-Sender-Auth: jidVxpHfPNmJAVzpv9MCf8ZanUE Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Timo Sirainen , morg Subject: Re: [MORG] draft-ietf-morg-multimailbox-search-05 - WGLC X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:59:59 -0000 >>> =A0S: * ESEARCH (TAG "tag1" MAILBOX "folder1" UIDVALIDITY 1) UID ALL >>> =A04001,4003,4005,4007,4009 >>> =A0S: * ESEARCH (TAG "tag2" MAILBOX "folder1" UIDVALIDITY 6789023554) >>> =A0UID ALL 195001:195004,169788 >> >> UIDVALIDITY changes rather suddenly in this example, so I think that's >> just unnecessary confusion. > > Good point. Should be UIDVALIDITY 1 on the second quoted line as well. And I think we should make the UIDs closer to the range in the first line. They don't HAVE to be, but the way it is seems a little odd. Shall I submit the change and we say WGLC is done and we're ready to send this up to the IESG? Can we get a couple more reviews before we do that? Barry From stpeter@stpeter.im Thu Feb 10 14:48:17 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3FA53A6839 for ; Thu, 10 Feb 2011 14:48:17 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FGecKFNwoYq for ; Thu, 10 Feb 2011 14:48:16 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B47083A67D2 for ; Thu, 10 Feb 2011 14:48:16 -0800 (PST) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2A9EB40393; Thu, 10 Feb 2011 16:06:06 -0700 (MST) Message-ID: <4D546B3B.7040701@stpeter.im> Date: Thu, 10 Feb 2011 15:48:27 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Barry Leiba References: <1296843508.18488.360.camel@hurina> <4D530665.6000609@isode.com> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090700000108070905020509" Cc: Timo Sirainen , morg Subject: Re: [MORG] draft-ietf-morg-multimailbox-search-05 - WGLC X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 22:48:18 -0000 This is a cryptographically signed message in MIME format. --------------ms090700000108070905020509 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/9/11 3:00 PM, Barry Leiba wrote: >>>> S: * ESEARCH (TAG "tag1" MAILBOX "folder1" UIDVALIDITY 1) UID ALL >>>> 4001,4003,4005,4007,4009 >>>> S: * ESEARCH (TAG "tag2" MAILBOX "folder1" UIDVALIDITY 6789023554) >>>> UID ALL 195001:195004,169788 >>> >>> UIDVALIDITY changes rather suddenly in this example, so I think that'= s >>> just unnecessary confusion. >> >> Good point. Should be UIDVALIDITY 1 on the second quoted line as well.= >=20 > And I think we should make the UIDs closer to the range in the first > line. They don't HAVE to be, but the way it is seems a little odd. >=20 > Shall I submit the change and we say WGLC is done and we're ready to > send this up to the IESG? Can we get a couple more reviews before we > do that? Sounds good to me. I've just changed the state to "revised I-D needed" in the tracker. Once a new version magically appears, I'll request IETF Last Call. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090700000108070905020509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIx MDIyNDgyN1owIwYJKoZIhvcNAQkEMRYEFAG3fUGY0I9Zv6yzJcRkby+SVPWzMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAIzPtwzcIv/OON1HnSAmPXxinKRJ3f/BmLgLvErehETDVFvjjIxNqrqCOl fUHmxr+fWboSHZ3FOpGHO2/nViINH1tJefUWQ3mtlq09yzmyeurKoVtTT6dNkJ8kdwOSA1a/ 78wQALYZrDQD9/QDxZ0U7XszJXmdZZaw17uyecIQ/8nDqBwKtxx/lcUHppJ66N5/xIuacAts 0N6Bt9uFmD8cU8+kVXYqpAggDq5B/rG95YYA+w4qso2wvLHV5XvCWRozn4/QY3oG/GQUJA7c I4/w8Ni8clr5NR48kzSyTtVi3djrBQyf0Po18Px7q8B8MVoNC2bloMoMBi/nX2EgFwfxAAAA AAAA --------------ms090700000108070905020509-- From Internet-Drafts@ietf.org Thu Feb 10 15:00:04 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647443A6AE0; Thu, 10 Feb 2011 15:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rErT9hZ+Oyqe; Thu, 10 Feb 2011 15:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F8F03A67A7; Thu, 10 Feb 2011 15:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110210230002.2153.20853.idtracker@localhost> Date: Thu, 10 Feb 2011 15:00:02 -0800 Cc: morg@ietf.org Subject: [MORG] I-D Action:draft-ietf-morg-multimailbox-search-06.txt X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 23:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Message Organization Working Group of the IETF. Title : IMAP4 Multimailbox SEARCH Extension Author(s) : B. Leiba, A. Melnikov Filename : draft-ietf-morg-multimailbox-search-06.txt Pages : 10 Date : 2011-02-10 The IMAP4 specification allows the searching only of the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round-trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-morg-multimailbox-search-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-morg-multimailbox-search-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-10145951.I-D@ietf.org> --NextPart-- From barryleiba@gmail.com Thu Feb 10 15:00:43 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996043A6AE5 for ; Thu, 10 Feb 2011 15:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtYnKLEdmX1y for ; Thu, 10 Feb 2011 15:00:42 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6F7B03A67A7 for ; Thu, 10 Feb 2011 15:00:42 -0800 (PST) Received: by iwc10 with SMTP id 10so1937377iwc.31 for ; Thu, 10 Feb 2011 15:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5NsvHYU7t3XG9+9TYk59KOki/+zMisfl13k+waR8EqM=; b=IqQ1ZXCxlSMitWNXae7f+3ZE8l01EMlZcyeJL4alazgyk0Sfjq1KhuyBskdF3LkTlS Gr35LIVs+35o1oKJN9qF9SjVxx0XFucfP+zQecmMK09Acy/nLn9Gvq8UsCJVxNWvKmON eI7Z8wti23e0uO8f9SmnK1bvs9/hXZd88PR/c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=NiRA053aZZj/bUk6U7MvaODo5nGcjI98mjPhepJpuuMmoUg8eozgrqtudqZAgiXpiR JBRveKhpj4T2DIV/VcmWC1oGqQmbt8w0sw0bKNOuaUo83kMzrza7hDGdNCiY4xm164II 4HqeS3O/426NYIVtb5RIFpzTO16veGolese0E= MIME-Version: 1.0 Received: by 10.231.169.74 with SMTP id x10mr23210250iby.26.1297378855450; Thu, 10 Feb 2011 15:00:55 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.34.13 with HTTP; Thu, 10 Feb 2011 15:00:55 -0800 (PST) In-Reply-To: <4D546B3B.7040701@stpeter.im> References: <1296843508.18488.360.camel@hurina> <4D530665.6000609@isode.com> <4D546B3B.7040701@stpeter.im> Date: Thu, 10 Feb 2011 18:00:55 -0500 X-Google-Sender-Auth: xmLDVXBcsDAqX4YAp0z6J1C7SLM Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Timo Sirainen , morg Subject: Re: [MORG] draft-ietf-morg-multimailbox-search-05 - WGLC X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 23:00:43 -0000 >> Shall I submit the change and we say WGLC is done and we're ready to >> send this up to the IESG? =A0Can we get a couple more reviews before we >> do that? > > Sounds good to me. I've just changed the state to "revised I-D needed" > in the tracker. Once a new version magically appears, I'll request IETF > Last Call. The magic, she has happened. b From stpeter@stpeter.im Thu Feb 10 15:04:40 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E8A3A6849 for ; Thu, 10 Feb 2011 15:04:40 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONyjfW2BMWBR for ; Thu, 10 Feb 2011 15:04:40 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B83E63A6AE8 for ; Thu, 10 Feb 2011 15:04:39 -0800 (PST) Received: from dhcp-64-101-72-185.cisco.com (dhcp-64-101-72-185.cisco.com [64.101.72.185]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8F49340C89; Thu, 10 Feb 2011 16:22:29 -0700 (MST) Message-ID: <4D546F13.7000300@stpeter.im> Date: Thu, 10 Feb 2011 16:04:51 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Barry Leiba References: <1296843508.18488.360.camel@hurina> <4D530665.6000609@isode.com> <4D546B3B.7040701@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060909090206050504020702" Cc: Timo Sirainen , morg Subject: Re: [MORG] draft-ietf-morg-multimailbox-search-05 - WGLC X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 23:04:41 -0000 This is a cryptographically signed message in MIME format. --------------ms060909090206050504020702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/10/11 4:00 PM, Barry Leiba wrote: >>> Shall I submit the change and we say WGLC is done and we're ready to >>> send this up to the IESG? Can we get a couple more reviews before we= >>> do that? >> >> Sounds good to me. I've just changed the state to "revised I-D needed"= >> in the tracker. Once a new version magically appears, I'll request IET= F >> Last Call. >=20 > The magic, she has happened. Magic is good. Expect IETF Last Call soon. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060909090206050504020702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIx MDIzMDQ1MVowIwYJKoZIhvcNAQkEMRYEFB4i10AhhfSKXr5pGxQafMqq/+uxMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCc3jajeLS7vNucHTqz33hdZy8JEs+KDG8Ns30yRGuPyii9HKuVxF2L0xAE 9NxaGJAyXm4zHhC3no6R8WHvSwUHtcpFzYnwSGWv50tRHWvKLb6XQWTfSBcbmQ3o6w7yvIXm fex6nSQOd1mphcv+PBwdz/E0Q831Lb7PK6o14fF9MjlEbF6L59d7f9L4EWWSSp5REyPcjScQ km5az9LMpyKkkCtXXk//tHVcnmFCh9jNegHr3ql2WEM0WwXKID9j+iHYEIBbX0xAlhFQtCTG VnVHJPm1DDaNxEoTb7v4rUYrJRBB/1+0HkyTpVbO0z+EZrj42PVyJ5ykmxorUwCe2+SXAAAA AAAA --------------ms060909090206050504020702-- From stpeter@stpeter.im Thu Feb 10 16:44:32 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1AF3A6823 for ; Thu, 10 Feb 2011 16:44:32 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfUsPb8qpcQl for ; Thu, 10 Feb 2011 16:44:31 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 12D2B3A6B16 for ; Thu, 10 Feb 2011 16:44:31 -0800 (PST) Received: from squire.local (dsl-251-175.dynamic-dsl.frii.net [216.17.251.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7734640CFC for ; Thu, 10 Feb 2011 18:02:21 -0700 (MST) Message-ID: <4D548679.50508@stpeter.im> Date: Thu, 10 Feb 2011 17:44:41 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: morg@ietf.org References: <1296843508.18488.360.camel@hurina> <4D530665.6000609@isode.com> <4D546B3B.7040701@stpeter.im> <4D546F13.7000300@stpeter.im> In-Reply-To: <4D546F13.7000300@stpeter.im> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040506030502080901030808" Subject: Re: [MORG] draft-ietf-morg-multimailbox-search-05 - WGLC X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 00:44:32 -0000 This is a cryptographically signed message in MIME format. --------------ms040506030502080901030808 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/10/11 4:04 PM, Peter Saint-Andre wrote: > On 2/10/11 4:00 PM, Barry Leiba wrote: >>>> Shall I submit the change and we say WGLC is done and we're ready to= >>>> send this up to the IESG? Can we get a couple more reviews before w= e >>>> do that? >>> >>> Sounds good to me. I've just changed the state to "revised I-D needed= " >>> in the tracker. Once a new version magically appears, I'll request IE= TF >>> Last Call. >> >> The magic, she has happened. >=20 > Magic is good. >=20 > Expect IETF Last Call soon. But first I've reviewed the spec. :) IMHO this document looks to be in good shape and I've found no substantive issues. Section 2 says: [[fix-for-pub-1: "X-DRAFT-I05-MMBX" (changes for publication)]] When will this value be assigned, and by whom? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms040506030502080901030808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIx MTAwNDQ0MVowIwYJKoZIhvcNAQkEMRYEFN6tNd2nhwREkWbg9ud5wR0fDrcSMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCZmi1Sv6HEKTleMOSlNIvdThbP3V+l63HdAcXGRcGuR0Wwrv6fsHXFoAPo byE+6fZ8KhWZthG4ZwBpAtGAZNc4WXRhLiYcf3251OJ3806UhPvjMdFcZ9TaleKaQl0TnU50 qTGCe7rZIHsMoONnLDkOqyuJ84bAuYwjR/h2xB8Jhjw2QkacgTTkv4DYDo59S+vjQzTwTTOw JJx9TTzG3kRi7ByHEUcQR6tDl8qKr0Jaf258pz2iPsokTCRXXrVExet6chZ0EPte1vVkbzd9 XGmmWi2vmECjp9jfvnrwDjd3LzaM00a48xLQOYmzCb4v2ibNs1DR3cSf78bdj4xapjq5AAAA AAAA --------------ms040506030502080901030808-- From alexey.melnikov@isode.com Fri Feb 11 02:50:26 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E245B3A694F for ; Fri, 11 Feb 2011 02:50:26 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzHyF6KfWbdm for ; Fri, 11 Feb 2011 02:50:23 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id DD77B3A6AEE for ; Fri, 11 Feb 2011 02:50:22 -0800 (PST) Received: from [188.28.8.68] (188.28.8.68.threembb.co.uk [188.28.8.68]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 11 Feb 2011 10:50:28 +0000 Message-ID: <4D550FA3.2030606@isode.com> Date: Fri, 11 Feb 2011 10:29:55 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Peter Saint-Andre References: <1296843508.18488.360.camel@hurina> <4D530665.6000609@isode.com> <4D546B3B.7040701@stpeter.im> <4D546F13.7000300@stpeter.im> <4D548679.50508@stpeter.im> In-Reply-To: <4D548679.50508@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: morg@ietf.org Subject: Re: [MORG] draft-ietf-morg-multimailbox-search-05 - WGLC X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 10:50:27 -0000 Peter Saint-Andre wrote: >On 2/10/11 4:04 PM, Peter Saint-Andre wrote: > > >>On 2/10/11 4:00 PM, Barry Leiba wrote: >> >> >>>>>Shall I submit the change and we say WGLC is done and we're ready to >>>>>send this up to the IESG? Can we get a couple more reviews before we >>>>>do that? >>>>> >>>>> >>>>Sounds good to me. I've just changed the state to "revised I-D needed" >>>>in the tracker. Once a new version magically appears, I'll request IETF >>>>Last Call. >>>> >>>> >>>The magic, she has happened. >>> >>> >>Magic is good. >> >>Expect IETF Last Call soon. >> >> >But first I've reviewed the spec. :) > >IMHO this document looks to be in good shape and I've found no >substantive issues. > >Section 2 says: > > [[fix-for-pub-1: "X-DRAFT-I05-MMBX" > (changes for publication)]] > >When will this value be assigned, and by whom? > > The best thing is to do this in AUTH48 once it is clear that the document wouldn't change. So the change should be done by RFC Editor/IANA. From iesg-secretary@ietf.org Mon Feb 14 11:33:06 2011 Return-Path: X-Original-To: morg@core3.amsl.com Delivered-To: morg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6565F3A6DB8; Mon, 14 Feb 2011 11:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4PcNJwRu-PB; Mon, 14 Feb 2011 11:33:05 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD623A6D55; Mon, 14 Feb 2011 11:33:05 -0800 (PST) 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: 3.12 Message-ID: <20110214193305.5231.91331.idtracker@localhost> Date: Mon, 14 Feb 2011 11:33:05 -0800 Cc: morg@ietf.org Subject: [MORG] Last Call: (IMAP4 Multimailbox SEARCH Extension) to Experimental RFC X-BeenThere: morg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Messaging Organization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 19:33:06 -0000 The IESG has received a request from the Message Organization WG (morg) to consider the following document: - 'IMAP4 Multimailbox SEARCH Extension' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-morg-multimailbox-search/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-morg-multimailbox-search/ No IPR declarations have been submitted directly on this I-D.