Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PK1DxR016714; Mon, 25 Oct 2004 13:01:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PK1DY8016713; Mon, 25 Oct 2004 13:01:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PK1CTl016707 for ; Mon, 25 Oct 2004 13:01:13 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28952; Mon, 25 Oct 2004 16:01:14 -0400 (EDT) Message-Id: <200410252001.QAA28952@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-annotate-11.txt Date: Mon, 25 Oct 2004 16:01:14 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP ANNOTATE Extension Author(s) : R. Gellens, C. Daboo Filename : draft-ietf-imapext-annotate-11.txt Pages : 39 Date : 2004-10-25 The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "metadata" for messages stored in an IMAP mailbox. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-annotate-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-annotate-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-25162034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-annotate-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-annotate-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-25162034.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O08Yp8011277; Sat, 23 Oct 2004 17:08:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9O08Yh4011276; Sat, 23 Oct 2004 17:08:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O08XAE011239 for ; Sat, 23 Oct 2004 17:08:34 -0700 (PDT) (envelope-from leiba@watson.ibm.com) Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i9O08V933160 for ; Sat, 23 Oct 2004 20:08:31 -0400 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id i9NML3I35514 for ; Sat, 23 Oct 2004 18:21:03 -0400 Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id i9NML1i08976 for ; Sat, 23 Oct 2004 18:21:01 -0400 Received: from 9.2.249.2:6602 ([9.2.249.2]) by mars.watson.ibm.com ID IMFd1098570061.1; Sat, 23 Oct 2004 18:21:01 -0400 Date: Sat, 23 Oct 2004 18:21:00 -0400 From: Barry Leiba To: IMAP extensions Mailing List Subject: Re: WG meeting at IETF 61 Message-ID: In-Reply-To: <417A8E4C.2060706@isode.com> References: <417A8E4C.2060706@isode.com> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> Great: the IMAPext meeting is scheduled for Tuesday afternoon, >> conflicting with the FTC/NIST Email Signing Summit. Is there any >> chance of getting this moved to Monday? > > An alternative (I prefer it slightly over the above), is to have it > on Wednesday, so that IMAPEXT and Lemonade are on the same date. The FTC/NIST meeting is all day Tuesday and Wednesday. They planned it to coincide with the IETF, but had to avoid Thursday because it's a federal holiday (Veterans' Day). A good many e-mail people will be there, or will want to, so it'd be good to have all the e-mail-related IETF things on Monday or Thursday. Barry -- Barry Leiba, Pervasive Computing Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NK8CKJ056494; Sat, 23 Oct 2004 13:08:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NK8Cwd056492; Sat, 23 Oct 2004 13:08:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NK8B6s056434 for ; Sat, 23 Oct 2004 13:08:11 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [213.116.52.185] (1Cust185.tnt102.lnd4.gbr.da.uu.net [213.116.52.185]) by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 23 Oct 2004 21:07:56 +0100 Message-ID: <417A8E4C.2060706@isode.com> Date: Sat, 23 Oct 2004 18:01:00 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Barry Leiba CC: IMAP extensions Mailing List Subject: Re: WG meeting at IETF 61 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Barry Leiba wrote: >Great: the IMAPext meeting is scheduled for Tuesday afternoon, >conflicting with the FTC/NIST Email Signing Summit. Is there any >chance of getting this moved to Monday? > > That would be fine with me. An alternative (I prefer it slightly over the above), is to have it on Wednesday, so that IMAPEXT and Lemonade are on the same date. Barry, does this work for you? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MNL9oA037697; Fri, 22 Oct 2004 16:21:09 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MNL9TI037696; Fri, 22 Oct 2004 16:21:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.20.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MNL8rZ037652 for ; Fri, 22 Oct 2004 16:21:08 -0700 (PDT) (envelope-from leiba@watson.ibm.com) Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw3.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i9MNL5A63230 for ; Fri, 22 Oct 2004 19:21:05 -0400 Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id i9MNL5I44576 for ; Fri, 22 Oct 2004 19:21:05 -0400 Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id i9MNL4i44574 for ; Fri, 22 Oct 2004 19:21:04 -0400 Received: from 9.2.249.2:5937 ([9.2.249.2]) by mars.watson.ibm.com ID IMFd1098487264.1; Fri, 22 Oct 2004 19:21:04 -0400 Date: Fri, 22 Oct 2004 19:21:03 -0400 From: Barry Leiba To: IMAP extensions Mailing List Subject: WG meeting at IETF 61 Message-ID: X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Great: the IMAPext meeting is scheduled for Tuesday afternoon, conflicting with the FTC/NIST Email Signing Summit. Is there any chance of getting this moved to Monday? Barry -- Barry Leiba, Pervasive Computing Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JHfVmO008086; Tue, 19 Oct 2004 10:41:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JHfVsY008085; Tue, 19 Oct 2004 10:41:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JHfUB2008071 for ; Tue, 19 Oct 2004 10:41:30 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9JHfXwf023565; Tue, 19 Oct 2004 10:41:33 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9JHfWwA001240 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Oct 2004 10:41:33 -0700 Date: Tue, 19 Oct 2004 10:41:34 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov cc: ietf-imapext@imc.org Subject: Re: draft-melnikov-imap-search-res In-Reply-To: <41753F59.30508@isode.com> Message-ID: References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com> <41753F59.30508@isode.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 19 Oct 2004, Alexey Melnikov wrote: > One thing I wanted to do but hasn't: add a SEARCH option to "suppress" > untagged SEARCH responses. Something like > a SEARCH 1:10,20:30,47 (NORESULT) Parentheses already mean something in SEARCH. Fortunately, there is a precedent for initial atoms, such as tag SEARCH SILENT 1:10,20:30,47 etc. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JHfOpJ008053; Tue, 19 Oct 2004 10:41:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JHfOBq008052; Tue, 19 Oct 2004 10:41:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JHfMqb008022 for ; Tue, 19 Oct 2004 10:41:23 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id B280D1C386DA; Tue, 19 Oct 2004 20:41:14 +0300 (EEST) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 211D81C3531B; Tue, 19 Oct 2004 20:41:10 +0300 (EEST) In-Reply-To: <417542E6.50902@isode.com> References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com> <417542E6.50902@isode.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8--358615198" Message-Id: <0F855184-21F6-11D9-8450-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Timo Sirainen Subject: Re: draft-melnikov-imap-search-res Date: Tue, 19 Oct 2004 20:41:09 +0300 To: Alexey Melnikov X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-8--358615198 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 19.10.2004, at 19:37, Alexey Melnikov wrote: >> If client sends SEARCH + FETCH << pipelined, nothing prevents server >> from giving all the FETCH replies before the SEARCH reply, right? > > The server shouldn't reorder the commands if there are any data > dependencies. "<<" is a very explicit indication that there are. Reordering here wouldn't affect results, only the order in which the results are sent to client. > Is there any particular reason why you think that a server should > return FETCH responses before the SEARCH response? Mostly just performance benefits. Server could process the two commands simultaneously in one loop. But you also mentioned (NORESULT) which would make this possible in any case. --Apple-Mail-8--358615198 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBdVG1yUhSUUBViskRAieIAJ4nFMDIxgLOytaTeFe3P/Ur3mus6gCgg9Bi CQrzAhdLcNhtLptSrX7Amuc= =CgM6 -----END PGP SIGNATURE----- --Apple-Mail-8--358615198-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGcALJ098420; Tue, 19 Oct 2004 09:38:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JGcAnw098419; Tue, 19 Oct 2004 09:38:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGc99H098411 for ; Tue, 19 Oct 2004 09:38:09 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 19 Oct 2004 17:37:59 +0100 Message-ID: <417542E6.50902@isode.com> Date: Tue, 19 Oct 2004 17:37:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timo Sirainen CC: IMAP Extensions WG Subject: Re: draft-melnikov-imap-search-res References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: > On 19.10.2004, at 14:25, Alexey Melnikov wrote: > >> My guess is (at least from the times I was an IMAP client developer) >> that the result of a SEARCH command is usually used as input to a >> subsequent FETCH/COPY/STORE command. With the base IMAP protocol one >> has to wait for the result of SEARCH to feed it into the subsequent >> command. > > If client sends SEARCH + FETCH << pipelined, nothing prevents server > from giving all the FETCH replies before the SEARCH reply, right? The server shouldn't reorder the commands if there are any data dependencies. "<<" is a very explicit indication that there are. Is there any particular reason why you think that a server should return FETCH responses before the SEARCH response? Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGQw6a096031; Tue, 19 Oct 2004 09:26:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JGQwhK096030; Tue, 19 Oct 2004 09:26:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGQva5096005 for ; Tue, 19 Oct 2004 09:26:57 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 961141C386DA; Tue, 19 Oct 2004 19:26:47 +0300 (EEST) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 1B7FF1C3531B; Tue, 19 Oct 2004 19:26:43 +0300 (EEST) In-Reply-To: <4174F9C2.40304@isode.com> References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-7--363081270" Message-Id: Content-Transfer-Encoding: 7bit Cc: IMAP Extensions WG From: Timo Sirainen Subject: Re: draft-melnikov-imap-search-res Date: Tue, 19 Oct 2004 19:26:42 +0300 To: Alexey Melnikov X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-7--363081270 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 19.10.2004, at 14:25, Alexey Melnikov wrote: > My guess is (at least from the times I was an IMAP client developer) > that the result of a SEARCH command is usually used as input to a > subsequent FETCH/COPY/STORE command. With the base IMAP protocol one > has to wait for the result of SEARCH to feed it into the subsequent > command. If client sends SEARCH + FETCH << pipelined, nothing prevents server from giving all the FETCH replies before the SEARCH reply, right? --Apple-Mail-7--363081270 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBdUBDyUhSUUBViskRAnAuAKCQCDZQeEWCW3Ka5/r7TOJojHho6QCfb4D0 LAfSw32K+KCyUPKqDTPYBcA= =y3vw -----END PGP SIGNATURE----- --Apple-Mail-7--363081270-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGMsWC095438; Tue, 19 Oct 2004 09:22:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JGMrNR095437; Tue, 19 Oct 2004 09:22:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGMr2u095430 for ; Tue, 19 Oct 2004 09:22:53 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 19 Oct 2004 17:22:50 +0100 Message-ID: <41753F59.30508@isode.com> Date: Tue, 19 Oct 2004 17:22:49 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Mark Crispin CC: ietf-imapext@imc.org Subject: Re: draft-melnikov-imap-search-res References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > The problem is when the search result is long and sparse, meaning that > it can not be collapsed easily with range syntax. With large enough > mailboxes, the result is a command which is larger than the maximum > command length, and thus the command needs to be broken up into > multiple commands (which in turn creates its own problems). One thing I wanted to do but hasn't: add a SEARCH option to "suppress" untagged SEARCH responses. Something like a SEARCH 1:10,20:30,47 (NORESULT) I am not sure whether this should be a part of the SEARCHRES extension, or a more generic extension for SEARCH options. The latter might include other options like COUNT (return how many were found), MIN (minimal found message number/UID) & MAX. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGIYtC094784; Tue, 19 Oct 2004 09:18:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JGIYKs094783; Tue, 19 Oct 2004 09:18:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGIXCk094777 for ; Tue, 19 Oct 2004 09:18:33 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 19 Oct 2004 17:18:32 +0100 Message-ID: <41753E57.7020902@isode.com> Date: Tue, 19 Oct 2004 17:18:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Mark Crispin CC: ietf-imapext@imc.org Subject: Re: draft-melnikov-imap-search-res References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com> <4175371A.7030707@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Tue, 19 Oct 2004, Alexey Melnikov wrote: > >> One can also OR it, e.g. >> a SEARCH <<,90:120 > > > Ugh! This is something that few implementors will get right! > > I don't think that we should allow $ in sequences; $ should be a > complete sequence by itself. If the client really wants an OR, it can do > tag SEARCH OR $ 90:120 That is fine with me. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JG5fbe093037; Tue, 19 Oct 2004 09:05:41 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JG5fXk093036; Tue, 19 Oct 2004 09:05:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JG5f98093030 for ; Tue, 19 Oct 2004 09:05:41 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9JG5eWx000913; Tue, 19 Oct 2004 09:05:41 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9JG5egK022227; Tue, 19 Oct 2004 09:05:40 -0700 Date: Tue, 19 Oct 2004 09:05:40 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov cc: Arnt Gulbrandsen , ietf-imapext@imc.org Subject: Re: draft-melnikov-imap-search-res In-Reply-To: <4175371A.7030707@isode.com> Message-ID: References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com> <4175371A.7030707@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 19 Oct 2004, Alexey Melnikov wrote: > One can also OR it, e.g. > a SEARCH <<,90:120 Ugh! This is something that few implementors will get right! I don't think that we should allow $ in sequences; $ should be a complete sequence by itself. If the client really wants an OR, it can do tag SEARCH OR $ 90:120 -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JFljE5089807; Tue, 19 Oct 2004 08:47:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JFljwT089806; Tue, 19 Oct 2004 08:47:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JFli1K089792 for ; Tue, 19 Oct 2004 08:47:44 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 19 Oct 2004 16:47:39 +0100 Message-ID: <4175371A.7030707@isode.com> Date: Tue, 19 Oct 2004 16:47:38 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Mark Crispin CC: Arnt Gulbrandsen , ietf-imapext@imc.org Subject: Re: draft-melnikov-imap-search-res References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > The problem is when the search result is long and sparse, meaning that > it can not be collapsed easily with range syntax. With large enough > mailboxes, the result is a command which is larger than the maximum > command length, and thus the command needs to be broken up into > multiple commands (which in turn creates its own problems). > > I don't particularly like "<<", since it implies some sort of UNIX > like piping (and implications can cause a lot of problems!), and > suggest something like "$" or even an atom (such as "LASTSEARCH") instead. I will change it to "$", thanks. > One possibly messy consequence is if this is allowed in a SEARCH > command; this would AND previous search results with addition criteria. One can also OR it, e.g. a SEARCH <<,90:120 > I can see why people may want to do that. However, with complex > SEARCHes, especially using IMAP4-style nesting, this can get extremely > complicated. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JFgG0Y089017; Tue, 19 Oct 2004 08:42:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JFgGiY089016; Tue, 19 Oct 2004 08:42:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JFgB0N088992 for ; Tue, 19 Oct 2004 08:42:11 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout6.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9JFg96I028896; Tue, 19 Oct 2004 08:42:09 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9JFg99j020978; Tue, 19 Oct 2004 08:42:09 -0700 Date: Tue, 19 Oct 2004 08:42:09 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov cc: Arnt Gulbrandsen , ietf-imapext@imc.org Subject: Re: draft-melnikov-imap-search-res In-Reply-To: <4174F9C2.40304@isode.com> Message-ID: References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The problem is when the search result is long and sparse, meaning that it can not be collapsed easily with range syntax. With large enough mailboxes, the result is a command which is larger than the maximum command length, and thus the command needs to be broken up into multiple commands (which in turn creates its own problems). I don't particularly like "<<", since it implies some sort of UNIX like piping (and implications can cause a lot of problems!), and suggest something like "$" or even an atom (such as "LASTSEARCH") instead. One possibly messy consequence is if this is allowed in a SEARCH command; this would AND previous search results with addition criteria. I can see why people may want to do that. However, with complex SEARCHes, especially using IMAP4-style nesting, this can get extremely complicated. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JBQ1n6049028; Tue, 19 Oct 2004 04:26:01 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JBQ1IR049027; Tue, 19 Oct 2004 04:26:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JBQ0vG049021 for ; Tue, 19 Oct 2004 04:26:00 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 19 Oct 2004 12:25:56 +0100 Message-ID: <4174F9C2.40304@isode.com> Date: Tue, 19 Oct 2004 12:25:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: ietf-imapext@imc.org Subject: Re: draft-melnikov-imap-search-res References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> In-Reply-To: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Hi, > > what motivates this extension? My guess is (at least from the times I was an IMAP client developer) that the result of a SEARCH command is usually used as input to a subsequent FETCH/COPY/STORE command. With the base IMAP protocol one has to wait for the result of SEARCH to feed it into the subsequent command. 1). So the two commands can't be pipelined. 2). Some bandwidth is wasted (SEARCH untagged result and FETCH message sequence). Granted, this might not be much, but the same mechanism that addresses 1) also addresses 2). to some extend. I've meant to write this document a long time ago, then I saw the following in the Lemonade Jabber log for the latest interim meeting: Mark says major problems are: no way to have client ask server to redo last search, sort, etc. and show only what has changed; also no way to get a sequence (such as the result of a search) and use it for something without sending the sequence back to the server. The extension addresses the latter. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JB1Nnn038208; Tue, 19 Oct 2004 04:01:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JB1NDG038206; Tue, 19 Oct 2004 04:01:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9JB1HYs038153 for ; Tue, 19 Oct 2004 04:01:22 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by kalyani.oryx.com (Postfix, from userid 1005) id 1357B1BDE7A; Tue, 19 Oct 2004 13:01:18 +0200 (CEST) Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by kalyani.oryx.com (Postfix) with SMTP id 4964E1BDE7B; Tue, 19 Oct 2004 13:01:16 +0200 (CEST) Message-Id: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> Date: Tue, 19 Oct 2004 13:02:42 +0200 From: Arnt Gulbrandsen To: Alexey.Melnikov@isode.com Subject: draft-melnikov-imap-search-res Cc: ietf-imapext@imc.org Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, what motivates this extension? Why would I (as client author) want to implement it? From where I sit, the client implementation looks like this, in pseudocode: if ( extension present ) do something else do pretty much the same thing, only very slightly slower Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9II73kT074381; Mon, 18 Oct 2004 11:07:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9II732A074380; Mon, 18 Oct 2004 11:07:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9II73Ds074372 for ; Mon, 18 Oct 2004 11:07:03 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9II76hg011993 for ; Mon, 18 Oct 2004 11:07:06 -0700 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9II76mv007594 for ; Mon, 18 Oct 2004 11:07:06 -0700 Date: Mon, 18 Oct 2004 11:07:06 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG Subject: about LISTEXT Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've been largely staying out of the discussions, but I'm getting worried about the problem of over-engineering. Can we back up a bit and get a coherant statement as to the problems in the current LIST command that clients want solved? As a start, I offer the following: 1) Too many LIST commands; LIST and LSUB was bad enough, and RLIST and RLSUB clearly identified a problem. Need a unified command. 2) Need a way for the client to specify that it really needs something like children which may be a problem for the server to do. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGllQt058269; Mon, 18 Oct 2004 09:47:47 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IGll3Z058268; Mon, 18 Oct 2004 09:47:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9IGlksB058259 for ; Mon, 18 Oct 2004 09:47:47 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 2D51C1A6C5; Mon, 18 Oct 2004 18:47:49 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 92C661A6BB; Mon, 18 Oct 2004 18:47:44 +0200 (CEST) Message-Id: Date: Mon, 18 Oct 2004 18:47:38 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand Cc: Alexey Melnikov , Timo Sirainen References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> <416EA92C.3040706@isode.com> <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com> <26A8C406-211C-11D9-A914-000393CC2E90@iki.fi> <4173EB50.4060703@isode.com> In-Reply-To: <4173EB50.4060703@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > Timo Sirainen wrote: >> What did you think about Dave Cridland's new syntax idea? You didn't >> reply to that message >> (<20041006093514.3678.27139.polymer@peirce.gestalt.entity.net>). >> >> I think using that would make MATCHPARENT much more simpler: >> - allows dropping \PlaceHolder and \HasSubmailboxes > > The proposal avoids introduction of \PlaceHolder/\HasSubmailboxes > (which is a good thing), but the complexity of implementing > MATCHPARENT in servers is still present. Part of the complexity is still present, not all. IMO, that proposal strikes a good balance. It makes MATCHPARENT powerful enough to completely replace LSUB, but doesn't require anything that really taxes my brain. As language, how about this? "CHILDINFO is returned when the LIST command matches a child mailbox and the pattern matches only a parent of that child, not the child itself. CHILDINFO contains at least those flags of the child/children that caused the LIST response to be sent. It does not contain the name(s) of the child(ren)." Hm. Not 100% good. >> - drop \NonExistent (is there any real use for it?) > > I am personally Ok with this change (i.e. \NonExistent = \NoSelect), I > am just waiting for more people to confirm that there is no > difference for clients or give a useful* example when it is not true. > > * - I've recently shown an ACL example, that might not be very useful. Personally I don't think the ACL example was useful enough to justify the added complication. It sounded unrealistic to my ears. I cannot find a better example. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGOkcW053784; Mon, 18 Oct 2004 09:24:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IGOkGf053782; Mon, 18 Oct 2004 09:24:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGOjEp053724 for ; Mon, 18 Oct 2004 09:24:45 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id E74021C932AE; Mon, 18 Oct 2004 19:24:42 +0300 (EEST) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 411F61C386DA; Mon, 18 Oct 2004 19:24:37 +0300 (EEST) In-Reply-To: <4173EB50.4060703@isode.com> References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> <416EA92C.3040706@isode.com> <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com> <26A8C406-211C-11D9-A914-000393CC2E90@iki.fi> <4173EB50.4060703@isode.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-12--449607316" Message-Id: <33FDDB02-2122-11D9-A914-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit Cc: ietf-imapext@imc.org From: Timo Sirainen Subject: Re: listext: some things I can't understand Date: Mon, 18 Oct 2004 19:24:36 +0300 To: Alexey Melnikov X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-12--449607316 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 18.10.2004, at 19:12, Alexey Melnikov wrote: >> And other ideas mentioned before that would make LISTEXT simpler: >> - drop CHILDREN and replace it with MATCHPARENT (which is now >> disallowed) > > IMHO, CHILDREN is probably more useful than MATCHPARENT, but I don't > have a strong opinion. It is, but CHILDREN can be implemented with MATCHPARENT if you drop the requirement that it can't be the only selection option. --Apple-Mail-12--449607316 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBc+5FyUhSUUBViskRAjbaAJ9UO98Aq6BR9YDEbgVlN1vPJR5VtQCfbLuH wiZdayCcUJcLSNAi4EKJXVU= =Wlq4 -----END PGP SIGNATURE----- --Apple-Mail-12--449607316-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGDJnY051514; Mon, 18 Oct 2004 09:13:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IGDJX8051513; Mon, 18 Oct 2004 09:13:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGDI6J051501 for ; Mon, 18 Oct 2004 09:13:18 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 18 Oct 2004 17:13:18 +0100 Message-ID: <4173EB9D.20006@isode.com> Date: Mon, 18 Oct 2004 17:13:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> <416EA92C.3040706@isode.com> <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com> <4173EA9D.8030108@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Alexey Melnikov writes: > >> The requirement to return a mailbox information only once is a >> quality of implementation issue. I guess it can be relaxed to SHOULD. > > Good enough for me. In practice it shouldn't make a difference. An IMAP server can return an unsolicited LIST response, so this shouldn't be an issue for clients anyway. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGCLR9051342; Mon, 18 Oct 2004 09:12:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IGCL8L051341; Mon, 18 Oct 2004 09:12:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9IGCJE3051334 for ; Mon, 18 Oct 2004 09:12:20 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 85E851A6C5; Mon, 18 Oct 2004 18:12:22 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 67DB01A6C2; Mon, 18 Oct 2004 18:12:18 +0200 (CEST) Message-Id: Date: Mon, 18 Oct 2004 18:12:12 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand Cc: Alexey Melnikov , Philip Guenther References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> <416EA92C.3040706@isode.com> <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com> <200410181602.i9IG299b075457@lab.smi.sendmail.com> In-Reply-To: <200410181602.i9IG299b075457@lab.smi.sendmail.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Philip Guenther writes: > The CHILDINFO idea seemed to offer a means of simplifying the > description or logic some too, but interest in it didn't seem broad. Disagreement didn't seem broad, I'd say. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGCBk0051305; Mon, 18 Oct 2004 09:12:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IGCBTr051304; Mon, 18 Oct 2004 09:12:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGCAjp051297 for ; Mon, 18 Oct 2004 09:12:10 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 18 Oct 2004 17:12:00 +0100 Message-ID: <4173EB50.4060703@isode.com> Date: Mon, 18 Oct 2004 17:12:00 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Timo Sirainen CC: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> <416EA92C.3040706@isode.com> <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com> <26A8C406-211C-11D9-A914-000393CC2E90@iki.fi> In-Reply-To: <26A8C406-211C-11D9-A914-000393CC2E90@iki.fi> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Timo Sirainen wrote: > On 18.10.2004, at 16:39, Alexey Melnikov wrote: > >> Part of the problem is that existing (non-extended) LIST command >> already complex as is. We can't do match about this. >> >> Another part of the problem is MATCHPARENT. Thinking more about how >> complex the thing is, maybe we should drop it entirely? >> However, I am slightly reluctant to do this until several client >> authors say that MATCHPARENT is not that useful. > > What did you think about Dave Cridland's new syntax idea? You didn't > reply to that message > (<20041006093514.3678.27139.polymer@peirce.gestalt.entity.net>). > > I think using that would make MATCHPARENT much more simpler: > - allows dropping \PlaceHolder and \HasSubmailboxes The proposal avoids introduction of \PlaceHolder/\HasSubmailboxes (which is a good thing), but the complexity of implementing MATCHPARENT in servers is still present. > - avoids confusion with unsolicited responses I like that part, although I have some concerns about proposed syntax. I will try to formulate what my concerns are later on. > And other ideas mentioned before that would make LISTEXT simpler: > - drop CHILDREN and replace it with MATCHPARENT (which is now > disallowed) IMHO, CHILDREN is probably more useful than MATCHPARENT, but I don't have a strong opinion. > - drop \NonExistent (is there any real use for it?) I am personally Ok with this change (i.e. \NonExistent = \NoSelect), I am just waiting for more people to confirm that there is no difference for clients or give a useful* example when it is not true. Alexey * - I've recently shown an ACL example, that might not be very useful. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGB6tQ051109; Mon, 18 Oct 2004 09:11:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IGB6jh051107; Mon, 18 Oct 2004 09:11:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9IGB5hC051100 for ; Mon, 18 Oct 2004 09:11:05 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 7A2441A6C1; Mon, 18 Oct 2004 18:11:07 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 710E91A6B6; Mon, 18 Oct 2004 18:11:03 +0200 (CEST) Message-Id: Date: Mon, 18 Oct 2004 18:10:57 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand Cc: Alexey Melnikov References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> <416EA92C.3040706@isode.com> <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com> <4173EA9D.8030108@isode.com> In-Reply-To: <4173EA9D.8030108@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > The requirement to return a mailbox information only once is a quality > of implementation issue. I guess it can be relaxed to SHOULD. Good enough for me. In practice it shouldn't make a difference. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IG93bI050727; Mon, 18 Oct 2004 09:09:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IG93he050726; Mon, 18 Oct 2004 09:09:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IG92Ri050714 for ; Mon, 18 Oct 2004 09:09:03 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 18 Oct 2004 17:09:02 +0100 Message-ID: <4173EA9D.8030108@isode.com> Date: Mon, 18 Oct 2004 17:09:01 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> <416EA92C.3040706@isode.com> <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: >> Another part of the problem is MATCHPARENT. Thinking more about how >> complex the thing is, maybe we should drop it entirely? >> However, I am slightly reluctant to do this until several client >> authors say that MATCHPARENT is not that useful. > > If MATCHPARENT is dropped and servers are allowed to return > /fruit/banana twice for 'LIST "" (*ban* *ana*)', then I think LISTEXT > becomes nice and simple. The requirement to return a mailbox information only once is a quality of implementation issue. I guess it can be relaxed to SHOULD. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IG29av049364; Mon, 18 Oct 2004 09:02:09 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IG29pH049363; Mon, 18 Oct 2004 09:02:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IG28Fm049349 for ; Mon, 18 Oct 2004 09:02:08 -0700 (PDT) (envelope-from guenther@sendmail.com) Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id i9IG29Hv004949 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 18 Oct 2004 09:02:09 -0700 X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i9IG29Hv004949 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=FrVm2XP0b+MToth648Iz2uL5On+t9Vajs5nb/VJ9D/g0T2EbCfSj8A+eDNH4wGC7d NbLwfKkD7wvDSk2WP4HgOA+mLZ9GOGLUnpm04z2Y4kgrUl5Gz8RvuA0w8ytjlsVKL5D ldQ6q2KtpgjwkoIN7BsKuAJ7cCKe7FiqAQGujKA= Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i9IG299b075457; Mon, 18 Oct 2004 09:02:09 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com) Message-Id: <200410181602.i9IG299b075457@lab.smi.sendmail.com> To: Alexey Melnikov Cc: ietf-imapext@imc.org From: Philip Guenther Subject: Re: listext: some things I can't understand In-reply-to: <4173C785.9090901@isode.com> References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> <416EA92C.3040706@isode.com> <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com> Date: Mon, 18 Oct 2004 09:02:09 -0700 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: ... >Another part of the problem is MATCHPARENT. Thinking more about how >complex the thing is, maybe we should drop it entirely? As mentioned in a previous post, it appears to me that some form of \Placeholder is necessary for listing of subscribed** folders via hierarchy levels using '%'. If describing how MATCHPARENT works in the general case makes it too complicated, then perhaps we should draw back and simply describe how it operates when such a pattern is used, i.e., _if_ the last hierarchical component of the pattern is *just* '%', then . The CHILDINFO idea seemed to offer a means of simplifying the description or logic some too, but interest in it didn't seem broad. ** Actually, the logic applies to any situation where "foo/bar" may be selected without "foo" also being selected. This is true of normal LIST on servers like Cyrus where DELETE may remove a mailbox that has children, which makes me wonder how well clients handle such hierarchies and whether the restriction on MATCHPARENT to when there's another selection option should be removed. >However, I am slightly reluctant to do this until several client authors >say that MATCHPARENT is not that useful. Feedback from client authors about their use of '%' seems important here, yes. Philip Guenther Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IFfZIM045230; Mon, 18 Oct 2004 08:41:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IFfZAh045229; Mon, 18 Oct 2004 08:41:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IFfXqm045180 for ; Mon, 18 Oct 2004 08:41:34 -0700 (PDT) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 932611C38778; Mon, 18 Oct 2004 18:41:22 +0300 (EEST) Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id CF51C1C386DA; Mon, 18 Oct 2004 18:41:17 +0300 (EEST) In-Reply-To: <4173C785.9090901@isode.com> References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> <416EA92C.3040706@isode.com> <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-11--452206659" Message-Id: <26A8C406-211C-11D9-A914-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit Cc: ietf-imapext@imc.org, Arnt Gulbrandsen From: Timo Sirainen Subject: Re: listext: some things I can't understand Date: Mon, 18 Oct 2004 18:41:17 +0300 To: Alexey Melnikov X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on danu.procontrol.fi X-Spam-Level: X-Spam-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-11--452206659 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 18.10.2004, at 16:39, Alexey Melnikov wrote: > Part of the problem is that existing (non-extended) LIST command > already complex as is. We can't do match about this. > > Another part of the problem is MATCHPARENT. Thinking more about how > complex the thing is, maybe we should drop it entirely? > However, I am slightly reluctant to do this until several client > authors say that MATCHPARENT is not that useful. What did you think about Dave Cridland's new syntax idea? You didn't reply to that message (<20041006093514.3678.27139.polymer@peirce.gestalt.entity.net>). I think using that would make MATCHPARENT much more simpler: - allows dropping \PlaceHolder and \HasSubmailboxes - avoids confusion with unsolicited responses And other ideas mentioned before that would make LISTEXT simpler: - drop CHILDREN and replace it with MATCHPARENT (which is now disallowed) - drop \NonExistent (is there any real use for it?) --Apple-Mail-11--452206659 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFBc+QdyUhSUUBViskRAk0NAJ9tNu0hV82SIRRATybCVRJEETvrvQCglcS/ Dz6cs/iiGDN9UMCjoIyYsKw= =8OPv -----END PGP SIGNATURE----- --Apple-Mail-11--452206659-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IFTbYX042971; Mon, 18 Oct 2004 08:29:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IFTba5042970; Mon, 18 Oct 2004 08:29:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9IFTZDV042958 for ; Mon, 18 Oct 2004 08:29:36 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id C174F1A6C8; Mon, 18 Oct 2004 17:29:37 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id A76AA1A6C4; Mon, 18 Oct 2004 17:29:33 +0200 (CEST) Message-Id: Date: Mon, 18 Oct 2004 17:29:26 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand Cc: Alexey Melnikov References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> <416EA92C.3040706@isode.com> <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com> In-Reply-To: <4173C785.9090901@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > Part of the problem is that existing (non-extended) LIST command > already complex as is. We can't do match about this. Agreed. > Another part of the problem is MATCHPARENT. Thinking more about how > complex the thing is, maybe we should drop it entirely? > However, I am slightly reluctant to do this until several client > authors say that MATCHPARENT is not that useful. If MATCHPARENT is dropped and servers are allowed to return /fruit/banana twice for 'LIST "" (*ban* *ana*)', then I think LISTEXT becomes nice and simple. Keeping a simplified variety of MATCHPARENT may do, too. > P.S. I don't think I will be able to produce a new revision before > October 25 (submission deadline). I will make one after the face to > face (+Jabber) meeting in Washington. I will post a list of LISTEXT > issues before the meeting. OK. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IFG2KH039555; Mon, 18 Oct 2004 08:16:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IFG2KR039554; Mon, 18 Oct 2004 08:16:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IFFvF3039538 for ; Mon, 18 Oct 2004 08:15:57 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 18 Oct 2004 16:15:39 +0100 Message-ID: <4173C785.9090901@isode.com> Date: Mon, 18 Oct 2004 14:39:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> <416EA92C.3040706@isode.com> <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> In-Reply-To: <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > But perhaps the best way is to simplify LISTEXT to the point where, > ah, non-experts like me don't have a problem understanding it. Are you > simplifying LISTEXT much in -11? Part of the problem is that existing (non-extended) LIST command already complex as is. We can't do match about this. Another part of the problem is MATCHPARENT. Thinking more about how complex the thing is, maybe we should drop it entirely? However, I am slightly reluctant to do this until several client authors say that MATCHPARENT is not that useful. Alexey P.S. I don't think I will be able to produce a new revision before October 25 (submission deadline). I will make one after the face to face (+Jabber) meeting in Washington. I will post a list of LISTEXT issues before the meeting. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ID8ONU015239; Mon, 18 Oct 2004 06:08:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ID8OJg015238; Mon, 18 Oct 2004 06:08:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9ID8IT5015190 for ; Mon, 18 Oct 2004 06:08:23 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 4F6C51A6C1; Mon, 18 Oct 2004 15:08:14 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 174E01A6B6; Mon, 18 Oct 2004 15:08:10 +0200 (CEST) Message-Id: <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> Date: Mon, 18 Oct 2004 15:08:09 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand Cc: Alexey Melnikov References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> <416EA92C.3040706@isode.com> <4172AC1D.8010006@isode.com> In-Reply-To: <4172AC1D.8010006@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > One way to address this is to say that LISTEXT capability is just > support for extended LIST command and responses, with no default > options. Another capability string can advertise support for > SUBSCIBED+REMOTE+CHILDREN and maybe MATCHPARENT. Another would be to say that any server that advertises e.g. POSTADDRESS support has to implement the necessary syntax, even if that server does not advertise LISTEXT. But perhaps the best way is to simplify LISTEXT to the point where, ah, non-experts like me don't have a problem understanding it. Are you simplifying LISTEXT much in -11? Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9HHUGRr026222; Sun, 17 Oct 2004 10:30:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9HHUGEu026221; Sun, 17 Oct 2004 10:30:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9HHUFOU026175 for ; Sun, 17 Oct 2004 10:30:16 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 17 Oct 2004 18:30:07 +0100 Message-ID: <4172AC1D.8010006@isode.com> Date: Sun, 17 Oct 2004 18:30:05 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> <416EA92C.3040706@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Alexey Melnikov writes: > >> I don't think that for the POSTADDRESS extension it would make any >> difference. > > Certainly it would. Hmm, I was thinking about different thing. I wanted to say that POSTADDRESS didn't interact with MATCHPARENT, as it was a return option. > Can't implement POSTADDRESS without the extended list syntax. Can't > advertise support for the extended list syntax without handling > MATCHPARENT. Can't implement that without understanding \placeholder > and \hassubmailboxes. You are right, of course. One way to address this is to say that LISTEXT capability is just support for extended LIST command and responses, with no default options. Another capability string can advertise support for SUBSCIBED+REMOTE+CHILDREN and maybe MATCHPARENT. Alexey Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EKC7if048106; Thu, 14 Oct 2004 13:12:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EKC7vd048105; Thu, 14 Oct 2004 13:12:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9EKC21n048087 for ; Thu, 14 Oct 2004 13:12:07 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 6351F1A6C3; Thu, 14 Oct 2004 22:12:04 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 25B591A6B8; Thu, 14 Oct 2004 22:11:58 +0200 (CEST) Message-Id: Date: Thu, 14 Oct 2004 22:11:57 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand Cc: Alexey Melnikov References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> <416EA92C.3040706@isode.com> In-Reply-To: <416EA92C.3040706@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > I don't think that for the POSTADDRESS extension it would make any > difference. Certainly it would. Can't implement POSTADDRESS without the extended list syntax. Can't advertise support for the extended list syntax without handling MATCHPARENT. Can't implement that without understanding \placeholder and \hassubmailboxes. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EGSVQL015086; Thu, 14 Oct 2004 09:28:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EGSV8b015085; Thu, 14 Oct 2004 09:28:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EGSUFF015077 for ; Thu, 14 Oct 2004 09:28:30 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 14 Oct 2004 17:28:29 +0100 Message-ID: <416EA92C.3040706@isode.com> Date: Thu, 14 Oct 2004 17:28:28 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arnt Gulbrandsen wrote: > Alexey Melnikov writes: > >> Mark has proposed to have a single capability for all options >> mentioned in LISTEXT. He has justified his proposal by saying that >> IMAP had already too many options. > > The price of that is that whoever wants to implement POSTADDRESS must > understand the subtleties of \placeholder and \hassubmailboxes. (When answering the questions I was only thinking about the CHILDREN option.) I don't think that for the POSTADDRESS extension it would make any difference. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ED7Bd3081280; Thu, 14 Oct 2004 06:07:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ED7Bft081279; Thu, 14 Oct 2004 06:07:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ED77vk081264 for ; Thu, 14 Oct 2004 06:07:11 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: Date: Thu, 14 Oct 2004 15:08:17 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand Cc: Alexey Melnikov , Philip Guenther References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com> In-Reply-To: <416E76F3.2020506@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > Mark has proposed to have a single capability for all options > mentioned in LISTEXT. He has justified his proposal by saying that > IMAP had already too many options. The price of that is that whoever wants to implement POSTADDRESS must understand the subtleties of \placeholder and \hassubmailboxes. Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ECsM3K079732; Thu, 14 Oct 2004 05:54:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ECsM5S079731; Thu, 14 Oct 2004 05:54:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ECsLUI079719 for ; Thu, 14 Oct 2004 05:54:21 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 14 Oct 2004 13:54:12 +0100 Message-ID: <416E76F3.2020506@isode.com> Date: Thu, 14 Oct 2004 13:54:11 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Guenther CC: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand References: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> In-Reply-To: <200410051911.i95JB0cG011324@lab.smi.sendmail.com> Content-Type: multipart/alternative; boundary="------------040605040005040601030104" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------040605040005040601030104 Content-type: text/plain; charset="us-ascii" Philip Guenther wrote: >Arnt Gulbrandsen writes: >... > > >>1. The children return option. Isn't that a noop? The server may ignore >>the option, and may (per RFC 3501/3348) send the \haschildren and >>\hasnochildren attributes even if children isn't present. The 'then' >>and 'else' parts of that test look more than a little similar to me. >> > >I vaguely recall (but may be hallucinating) that someone proposed making >the CHILDREN option a separate capability with support implying that >when requested, every response would have \haschildren or >\hasnochildren. Scanning the list archive, it appears that was >kinda-sorta decided against based on the fact that the current children >support (RFC 3348) doesn't have a capability associated with it, but >that doesn't make logical sense as _that_ decision stems from the lack >of a way to request the info. > >Can anyone point to a reason for the decision to not make CHILDREN a >separate capability, perhaps a thread in the archive that I missed? > > As far as I remember: Mark has proposed to have a single capability for all options mentioned in LISTEXT. He has justified his proposal by saying that IMAP had already too many options. Originally Mark has been against inclusion of the CHILDREN extension, but he has changed his mind later on when the WG has agreed that the server was not required to return \HasChildren/\HasNoChildren unless explicitly asked by the client. Does this answer your question? Alexey --------------040605040005040601030104 Content-type: text/html; charset="us-ascii" Content-transfer-encoding: 7bit Philip Guenther wrote:
Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> writes:
...
  
1. The children return option. Isn't that a noop? The server may ignore 
the option, and may (per RFC 3501/3348) send the \haschildren and 
\hasnochildren attributes even if children isn't present. The 'then' 
and 'else' parts of that test look more than a little similar to me.   

I vaguely recall (but may be hallucinating) that someone proposed making
the CHILDREN option a separate capability with support implying that
when requested, every response would have \haschildren or
\hasnochildren.  Scanning the list archive, it appears that was
kinda-sorta decided against based on the fact that the current children
support (RFC 3348) doesn't have a capability associated with it, but
that doesn't make logical sense as _that_ decision stems from the lack
of a way to request the info.

Can anyone point to a reason for the decision to not make CHILDREN a
separate capability, perhaps a thread in the archive that I missed?
As far as I remember:
Mark has proposed to have a single capability for all options mentioned in LISTEXT. He has justified his proposal by saying that IMAP had already too many options.
Originally Mark has been against inclusion of the CHILDREN extension, but he has changed his mind later on when the WG has agreed that the server was not required to return \HasChildren/\HasNoChildren unless explicitly asked by the client.

Does this answer your question?

Alexey

--------------040605040005040601030104-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EBjPcl070717; Thu, 14 Oct 2004 04:45:25 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EBjPVA070716; Thu, 14 Oct 2004 04:45:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EBjOtC070709 for ; Thu, 14 Oct 2004 04:45:25 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: Date: Thu, 14 Oct 2004 13:46:34 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand Cc: Alexey Melnikov References: <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net> <416E6482.20304@isode.com> In-Reply-To: <416E6482.20304@isode.com> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov writes: > As I understand it, it wasn't the intention of the section 5.5 to list > all commands that [may] have dependencies. The server will just have > to process the extended LIST commands in the order received. Is this > sufficient? Sufficient, perhaps, but the requirement hardly seems justified. > I can come up only with a single strained example: If the server also > implements ACL extension, it may return \NoSelect if the current user > has the "l" right (i.e. can LIST), but doesn't have the "r" right > (i.e. can't SELECT). Although I am not aware of any server that > actually does this. > > But for all intensive purposes I can't come up with a reason why a > client would care about the difference between "mailbox doesn't > exist" and "mailbox exists but can't be selected". Agreed. It's just something that causes people like me to think, "this is too complex to implement - forget it." Arnt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EBZeeX069225; Thu, 14 Oct 2004 04:35:40 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EBZeO5069224; Thu, 14 Oct 2004 04:35:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EBZYow069198 for ; Thu, 14 Oct 2004 04:35:34 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 14 Oct 2004 12:35:31 +0100 Message-ID: <416E6482.20304@isode.com> Date: Thu, 14 Oct 2004 12:35:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnt Gulbrandsen CC: ietf-imapext@imc.org Subject: Re: listext: some things I can't understand References: <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030601010801060603070704" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------030601010801060603070704 Content-type: text/plain; charset="KOI8-R"; format="flowed" Content-transfer-encoding: 7bit Arnt Gulbrandsen wrote: >> \Placeholder implies that: >> >> 1) The mailbox *does* exist, but doesn't match the current criteria. >> 2) The mailbox has inferior mailboxes, some of which *do* match the >> current selection criteria. > > I see what you're saying now, but in order to make sense of it, I have > to think in terms of a command. More like a tagged response than an > untagged one. > > In fact, this requires an addition to RFC 3501 section 5.5, specifying > that two list commands cannot be issued concurrently when one uses > matchparent. As I understand it, it wasn't the intention of the section 5.5 to list all commands that [may] have dependencies. The server will just have to process the extended LIST commands in the order received. Is this sufficient? >>> Why do we need both \nonexistent and \noselect? >> >> Yeah, the difference is pretty subtle. >> >> Foo LIST "" "%" >> * LIST (\NoSelect) "/" "Stuff" >> Foo OK >> >> Bar LIST (SUBSCRIBED) "" "%" >> * LIST (\NonExistent \Subscribed) "/" "Other Stuff" >> Bar OK >> >> Neither Stuff nor Other Stuff exist. The difference is that a LIST of >> "Stuff/%" is pretty likely to give some responses, since the node >> exists in the mailbox heirarchy, as it were, whereas "Other Stuff/%" >> won't - if it would do, it'd have been returned in the first list. >> >> FWIW, I rewrote these paragraphs several times with agreements that >> one implied the other before I realised that they have subtly >> different usages. I'm still not entirely sure whether this is the >> case, in fact. >> >> Would: >> * LIST (\NoSelect \Subscribed) "/" "Other Stuff" >> >> be interpretable any other way, for the Bar command above? > > Optimism knows no bounds. A client author who trusts every server > author to understand the subtleties perfectly could read from that > response that Other Stuff might have child mailboxes. > > This seems to be the same as your \nonexistent response above: > > * LIST (\noselect \hasnochildren \subscribed) "/" "Other Stuff" I can come up only with a single strained example: If the server also implements ACL extension, it may return \NoSelect if the current user has the "l" right (i.e. can LIST), but doesn't have the "r" right (i.e. can't SELECT). Although I am not aware of any server that actually does this. But for all intensive purposes I can't come up with a reason why a client would care about the difference between "mailbox doesn't exist" and "mailbox exists but can't be selected". --------------030601010801060603070704 Content-type: text/html; charset="KOI8-R" Content-transfer-encoding: 8bit Arnt Gulbrandsen wrote:
\Placeholder implies that:

1) The mailbox *does* exist, but doesn't match the current criteria.
2) The mailbox has inferior mailboxes, some of which *do* match the current selection criteria.
I see what you're saying now, but in order to make sense of it, I have to think in terms of a command. More like a tagged response than an untagged one.

In fact, this requires an addition to RFC 3501 section 5.5, specifying that two list commands cannot be issued concurrently when one uses matchparent.
As I understand it, it wasn't the intention of the section 5.5 to list all commands that [may] have dependencies.
The server will just have to process the extended LIST commands in the order received. Is this sufficient?
Why do we need both \nonexistent and \noselect?
Yeah, the difference is pretty subtle.

Foo LIST "" "%"
* LIST (\NoSelect) "/" "Stuff"
Foo OK

Bar LIST (SUBSCRIBED) "" "%"
* LIST (\NonExistent \Subscribed) "/" "Other Stuff"
Bar OK

Neither Stuff nor Other Stuff exist. The difference is that a LIST of "Stuff/%" is pretty likely to give some responses, since the node exists in the mailbox heirarchy, as it were, whereas "Other Stuff/%" won't - if it would do, it'd have been returned in the first list.

FWIW, I rewrote these paragraphs several times with agreements that one implied the other before I realised that they have subtly different usages. I'mš still not entirely sure whether this is the case, in fact.

Would:
* LIST (\NoSelect \Subscribed) "/" "Other Stuff"

be interpretable any other way, for the Bar command above?
Optimism knows no bounds. A client author who trusts every server author to understand the subtleties perfectly could read from that response that Other Stuff might have child mailboxes.

This seems to be the same as your \nonexistent response above:

* LIST (\noselect \hasnochildren \subscribed) "/" "Other Stuff"
I can come up only with a single strained example: If the server also implements ACL extension, it may return \NoSelect if the current user has the "l" right (i.e. can LIST), but doesn't have the "r" right (i.e. can't SELECT). Although I am not aware of any server that actually does this.

But for all intensive purposes I can't come up with a reason why a client would care about the difference between "mailbox doesn't exist" and "mailbox exists but can't be selected".





--------------030601010801060603070704--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EB3o4N061791; Thu, 14 Oct 2004 04:03:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EB3okN061790; Thu, 14 Oct 2004 04:03:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EB3nWn061768 for ; Thu, 14 Oct 2004 04:03:49 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 14 Oct 2004 12:02:34 +0100
Message-ID: <416E5CC9.9050800@isode.com>
Date: Thu, 14 Oct 2004 12:02:33 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Cridland 
CC: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
References:  <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>
In-Reply-To: <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>
Content-Type: multipart/alternative; boundary="------------070800080806010008030807"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--------------070800080806010008030807
Content-type: text/plain; charset="us-ascii"

Dave Cridland wrote:

>> 1. The children return option. Isn't that a noop? The server may 
>> ignore the option, and may (per RFC 3501/3348) send the \haschildren 
>> and \hasnochildren attributes even if children isn't present. The 
>> 'then' and 'else' parts of that test look more than a little similar 
>> to me.
>
> It gets worse, actually. The server "MAY ignore" it, but "SHOULD 
> return" the information, which seems to give me two levels of 
> requirement for the same thing.
>
> One thing that CHILDREN (The new and improved LISTEXT return option, I 
> mean) gives me, the client author, is a way of saying "Look, I could 
> do with this information, but don't sweat it, I can always issue 
> another LIST to find out later." If you prefer, it's a useful method 
> of being nice to the server.

Exactly.


--------------070800080806010008030807
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit




  
  






Dave Cridland wrote:



  
1. The children return option. Isn't that a
noop? The server may ignore the option, and may (per RFC 3501/3348)
send the \haschildren and \hasnochildren attributes even if children
isn't present. The 'then' and 'else' parts of that test look more than
a little similar to me. 

  

It gets worse, actually. The server "MAY ignore" it, but "SHOULD
return" the information, which seems to give me two levels of
requirement for the same thing. 

  

One thing that CHILDREN (The new and improved LISTEXT return option, I
mean) gives me, the client author, is a way of saying "Look, I could do
with this information, but don't sweat it, I can always issue another
LIST to find out later." If you prefer, it's a useful method of being
nice to the server. 



Exactly.






--------------070800080806010008030807--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9BJe2Xg032602; Mon, 11 Oct 2004 12:40:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9BJe2vg032601; Mon, 11 Oct 2004 12:40:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9BJe1k7032590 for ; Mon, 11 Oct 2004 12:40:02 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09062; Mon, 11 Oct 2004 15:39:58 -0400 (EDT)
Message-Id: <200410111939.PAA09062@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: ietf-imapext@imc.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-imapext-i18n-04.txt
Date: Mon, 11 Oct 2004 15:39:58 -0400
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: Internet Message Access Protocol Internationalization
	Author(s)	: C. Newman, A. Gulbrandsen
	Filename	: draft-ietf-imapext-i18n-04.txt
	Pages		: 16
	Date		: 2004-10-11
	
Internet Message Access Protocol (IMAP) version 4rev1 has basic
    support for non-ASCII characters in mailbox names and search
    substrings.  It also supports non-ASCII message headers and content
    encoded as specified by Multipurpose Internet Mail Extensions
    (MIME).  This specification defines a collection of IMAP extensions
    which improve international support including comparator negotiation
    for search, sort and thread, language negotiation for international
    error text, and translations for namespace prefixes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-i18n-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-i18n-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-10-11155343.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-i18n-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-i18n-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-10-11155343.I-D@ietf.org>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98FXpC6046800; Fri, 8 Oct 2004 08:33:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i98FXpOU046799; Fri, 8 Oct 2004 08:33:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98FXok2046786 for ; Fri, 8 Oct 2004 08:33:51 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [192.168.2.79] (64.221.254.66.ptr.us.xo.net [64.221.254.66])  by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 8 Oct 2004 16:32:43 +0100
Message-ID: <4166B314.7000708@isode.com>
Date: Fri, 08 Oct 2004 16:32:36 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Cridland 
CC: IMAP extensions Mailing List 
Subject: Re: One command or several...
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com> 	<20041006154011.3678.64504.polymer@peirce.gestalt.entity.net>	<200410061616.i96GGDqS097315@lab.smi.sendmail.com> <20041006164309.3678.28353.polymer@peirce.gestalt.entity.net>
In-Reply-To: <20041006164309.3678.28353.polymer@peirce.gestalt.entity.net>
Content-Type: multipart/alternative; boundary="------------000000050908090900050204"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--------------000000050908090900050204
Content-type: text/plain; charset="us-ascii"

Dave Cridland wrote:

>> 
>> >Moreover, it introduces extra complexity into the syntax, especially 
>> >because it introduces special handling of the empty list-mailbox - 
>> or >more accurately, special handling of the special handling... As 
>> >wonderfully ironic as that is, I can't see the point in persuing that.
>>
>> Even if multiple patterns are removed, the empty pattern will have
>> to be mentioned to say what happens if you use options with it...even
>> if all it was to say was "the behavior of the empty pattern is
>> unspecified if list options are used".
>
>
> Not really. It's specified per-option, if at all. In principle, an 
> empty pattern used with REMOTE could tell you whether the entire 
> heirarchy was rooted remotely or not, for instance - that's 
> potentially useful information.

I think you are trying to attach a specific meaning to the empty mailbox 
path for the REMOTE option. How would you define what is the meaning of 
"" when both REMOTE and SUBSCRIBED are specified?

Alexey


--------------000000050908090900050204
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit




  
  


Dave Cridland wrote:



  
<regarding mbox-or-pat>
    

>Moreover, it introduces extra complexity into the syntax,
especially >because it introduces special handling of the empty
list-mailbox - or >more accurately, special handling of the special
handling... As >wonderfully ironic as that is, I can't see the point
in persuing that.
    

    

Even if multiple patterns are removed, the empty pattern will have
    

to be mentioned to say what happens if you use options with it...even
    

if all it was to say was "the behavior of the empty pattern is
    

unspecified if list options are used".
    

  

  

Not really. It's specified per-option, if at all. In principle, an
empty pattern used with REMOTE could tell you whether the entire
heirarchy was rooted remotely or not, for instance - that's potentially
useful information.
  



I think you are trying to attach a specific meaning to the empty
mailbox path for the REMOTE option. How would you define what is the
meaning of "" when both REMOTE and SUBSCRIBED are specified?



Alexey







--------------000000050908090900050204--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96MAoke008595; Wed, 6 Oct 2004 15:10:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96MAoED008594; Wed, 6 Oct 2004 15:10:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96MAkcV008575 for ; Wed, 6 Oct 2004 15:10:46 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.6) with ESMTP id i96M9qK4021320 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 6 Oct 2004 15:09:53 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i96M9qK4021320
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=cNuiM3w1E6Um5RhXxq+hu6KopuV5jgUVn5aEeEKeFZEy8+jT2bKyU5kqqy+kCe95V YA+LR/rBZ1/lNAGI0i0dB0MB7WDrA/mYJgdnLjXK/zra+bRadJsjmgIfUPdxCcDvXPK X+EqrYF/G92h3O4saje142b5zCrUf+1mML9sKRU=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i96M9pdx024488; Wed, 6 Oct 2004 15:09:51 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410062209.i96M9pdx024488@lab.smi.sendmail.com>
From: Philip Guenther 
To: Arnt Gulbrandsen 
cc: ietf-imapext@imc.org, Timo Sirainen , Dave Cridland 
Subject: Re: listext: some things I can't understand 
Date: Wed, 06 Oct 2004 15:09:51 -0700
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

I wrote:
>	* LIST () "/" "Veg" ((CHILDINFO ("\Subscribed")))

Oops.  As pointed out by Jutta, the backslash has to be doubled,
so that should be:
	* LIST () "/" "Veg" ((CHILDINFO ("\\Subscribed")))

and similar through the rest of the examples.

Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96KVFJh099516; Wed, 6 Oct 2004 13:31:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96KVF1H099515; Wed, 6 Oct 2004 13:31:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96KVAQp099497 for ; Wed, 6 Oct 2004 13:31:10 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.6) with ESMTP id i96KUuHZ019941 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 6 Oct 2004 13:30:56 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i96KUuHZ019941
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=cVnFAbfHCxWPG9UCefdCAHyOSPXUN7nH/6Y5rtcBbpUxt7Xud8LayqoeWMMHMeM1j f37xPMvpuZbEv7dl20A4aLRewVNASrWU9P4dwQujIG1CHBwWYImrUszI/q88PQtApoW iJI2+La/4tqOezWNqAYaE1UWWkGw8rXWUeyvZBk=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i96KUtIN016879; Wed, 6 Oct 2004 13:30:56 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410062030.i96KUtIN016879@lab.smi.sendmail.com>
To: Arnt Gulbrandsen 
Cc: ietf-imapext@imc.org, Timo Sirainen , Dave Cridland 
From: Philip Guenther 
Subject: Re: listext: some things I can't understand 
In-reply-to: <6HX949UaRSb7CKtb+zSNAQ.md5@libertango.oryx.com> 
References:  <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>  <20041006093514.3678.27139.polymer@peirce.gestalt.entity.net>   <6HX949UaRSb7CKtb+zSNAQ.md5@libertango.oryx.com> 
Date: Wed, 06 Oct 2004 13:30:55 -0700
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Arnt Gulbrandsen  writes:
>Timo Sirainen writes:
>> On 6.10.2004, at 12:35, Dave Cridland wrote:
>>
>>>  A0004 LIST (SUBSCRIBED MATCHPARENT) "" "%"
>>>  * LIST (\Subscribed) "/" "Fruit"
>>>  * LIST () "/" "Veg" ((CHILDINFO (\Subscribed))
>>>  A0004 OK
>>
>> I like this. Makes it very clear what was intended with it.
>
>Agreed. This one's good.

This makes sense, but there are still some things to hammer out or fix.

On the syntax side, the above doesn't match the mbox-list-extended
syntax, and not just because a closing paren was left off: \subscribed
isn't an nstring, so it needs to be returned as a quoted string or
literal:
	* LIST () "/" "Veg" ((CHILDINFO ("\Subscribed")))

(Note that it isn't an atom either, so switching the grammar from
nstring to astring wouldn't help.)


On the semantics side, the handling of CHILDINFO when there are multiple
selection criteria _other_ than MATCHPARENT (e.g., both REMOTE and
SUBSCRIBED) needs to be stated.  I think it should always be a single
list that has the union of the 'selection flags' (\Remote and
\Subscribed) of the selected children.  That is, if there are multiple
selected children with different flags (one's remote, the other isn't)
you _don't_ get multiple blocks of childinfo.

For example, given the following hierarchy:
	1 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
	* LIST () "/" "projects"
	* LIST (\Subscribed \Remote) "/" "projects/clients"
	* LIST (\Subscribed) "/" "projects/servers"
	* LIST () "/" "projects/servers/imap"
	1 OK

I think the following should be correct:
	2 LIST (SUBSCRIBED MATCHPARENT) "" "%"
	* LIST () "/" "projects" ((CHILDINFO ("\Subscribed")))
	2 OK
	3 LIST (REMOTE MATCHPARENT) "" "%"
	* LIST () "/" "projects" ((CHILDINFO ("\Remote")))
	3 OK
	4 LIST (REMOTE SUBSCRIBED MATCHPARENT) "" "%"
	* LIST () "/" "projects" ((CHILDINFO ("\Remote" "\Subscribed")))
	4 OK
	5 LIST (REMOTE MATCHPARENT) "" "projects/%"
	* LIST (\Remote) "/" "projects/clients"
	* LIST () "/" "projects/servers" ((CHILDINFO ()))
	5 OK


So, that would make the syntax of CHILDINFO be:

childinfo = "CHILDINFO" SP "(" [string *(SP string)] ")"
	     ; matches a subset of the mbox-list-extended-item-data syntax


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96HC4p4078598; Wed, 6 Oct 2004 10:12:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96HC4sU078597; Wed, 6 Oct 2004 10:12:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96HC3OI078583 for ; Wed, 6 Oct 2004 10:12:03 -0700 (PDT) (envelope-from daboo@isamet.com)
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i96GmUo3007591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2004 12:48:30 -0400
Date: Wed, 06 Oct 2004 13:12:00 -0400
From: Cyrus Daboo 
To: Dave Cridland 
cc: IMAP extensions Mailing List , Arnt Gulbrandsen , Philip Guenther 
Subject: Re: One command or several... 
Message-ID: 
In-Reply-To: <20041006165725.3678.93012.polymer@peirce.gestalt.entity.net>
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com> <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net> <278BADDE17C67F56F230ACD4@ninevah.cyrusoft.com> <20041006165725.3678.93012.polymer@peirce.gestalt.entity.net>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Hi Dave,

--On Wednesday, October 6, 2004 5:57 PM +0100 Dave Cridland 
 wrote:

>> However, at this point I wouldn't mind if we went back to just a
>> single list-mailbox syntax and left mbox-or-pat for a future
>> extension.
>
> I'm not wildly against the syntax, I'm just not convinced it's actually
> needed right now.
>
> Actually, I think the scenario you describe above could be better handled
> with arbitrary mailbox attributes - which, IIRC, ANNOTATEMORE introduces
> (Of course, you'd know that better than me). Then the client can simply
> define its mailbox sets on the server, effectively, by 'tagging'
> mailboxes, and then search for that tag, by using some
> ANNOTATEMORE+LISTEXT extension.
>
> This also has the benefit that mailbox 'sets' can be standardized
> themselves, and made interoperable.

Certainly I would like to see both an ANNOTATION selection option and a 
return option. However, I worry that that may encourage more use of "*" 
wildcard matching as likely clients would want to match mailboxes at any 
depth in the hierarchy.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96Gxkw8077510; Wed, 6 Oct 2004 09:59:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96GxkF2077509; Wed, 6 Oct 2004 09:59:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GxjK1077502 for ; Wed, 6 Oct 2004 09:59:45 -0700 (PDT) (envelope-from dave@cridland.net)
Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id C4210154009; Wed,  6 Oct 2004 16:59:47 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline; xpolymertype="coverletter"
From: Dave Cridland 
To: Cyrus Daboo 
Cc: IMAP extensions Mailing List , Arnt Gulbrandsen , Philip Guenther 
Subject: Re: One command or several... 
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com> <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net> <278BADDE17C67F56F230ACD4@ninevah.cyrusoft.com>
In-Reply-To: <278BADDE17C67F56F230ACD4@ninevah.cyrusoft.com>
Message-ID: <20041006165725.3678.93012.polymer@peirce.gestalt.entity.net>
X-Mailer: Infotrope Polymer/0.0.3
Date: Wed, 06 Oct 2004 17:57:25 +0100
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

On Wed Oct  6 17:19:30 2004, Cyrus Daboo wrote:
> --On Wednesday, October 6, 2004 4:40 PM +0100 Dave Cridland 
>  wrote:
> 
>> As for mbox-or-pat, I agree with Philip that there doesn't seem to 
>> be
>> much point - pipelining the LIST commands acheives the same goal 
>> in -
>> almost certainly - the same number of TCP packets, and only a small
>> increased data transfer cost.
> 
> That's not necessarily true - it depends on how large the 
> mbox-or-pat list is. Remember for each pipelined command, in 
> addition to the unsolicited responses there is always the tagged OK 
> - one for each command - and those do add overhead to the pipelined 
> approach that is not present in the single command approach.
> 
> 
Well, it does depend on the size of mbox-or-pat, and the contents, 
true.

It you have, say, twenty mailboxes you're tracking, and you use 
mbox-or-pat syntax to individually specify them, then you're saving 
quite a bit, I'll grant you. Also it makes a big difference whether 
the server flushes its output buffer on every command completion.


>> Moreover, it introduces extra complexity into the syntax, 
>> especially
>> because it introduces special handling of the empty list-mailbox - 
>> or
>> more accurately, special handling of the special handling... As
>> wonderfully ironic as that is, I can't see the point in persuing 
>> that.
>> 
>> Is there any implementor who really wants this syntax in?
> 
> I guess I was one person requesting it. As more and more people use 
> server-side filtering and plus-addressing techniques, users often 
> need to operate on 'discrete' sets of mailboxes - i.e. ones that 
> cannot be represented by a simple % or * LIST pattern. Being able 
> to get information on those sets in one go is useful. Really the 
> benefit of this comes if we look to potential extensions to LISTEXT 
> - e.g. being able to specify SEARCH criteria to do multi-mailbox 
> searches, or being able to request STATUS-like information.
> 
> However, at this point I wouldn't mind if we went back to just a 
> single list-mailbox syntax and left mbox-or-pat for a future 
> extension.

I'm not wildly against the syntax, I'm just not convinced it's 
actually needed right now.

Actually, I think the scenario you describe above could be better 
handled with arbitrary mailbox attributes - which, IIRC, ANNOTATEMORE 
introduces (Of course, you'd know that better than me). Then the 
client can simply define its mailbox sets on the server, effectively, 
by 'tagging' mailboxes, and then search for that tag, by using some 
ANNOTATEMORE+LISTEXT extension.

This also has the benefit that mailbox 'sets' can be standardized 
themselves, and made interoperable.

Dave.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96Gqb5E077020; Wed, 6 Oct 2004 09:52:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96Gqbgn077019; Wed, 6 Oct 2004 09:52:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GqaRV077011 for ; Wed, 6 Oct 2004 09:52:36 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Message-Id: <6HX949UaRSb7CKtb+zSNAQ.md5@libertango.oryx.com>
Date: Wed, 6 Oct 2004 18:53:12 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
Cc: Timo Sirainen , Dave Cridland 
References:  <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>  <20041006093514.3678.27139.polymer@peirce.gestalt.entity.net> 
In-Reply-To: 
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Timo Sirainen writes:
> On 6.10.2004, at 12:35, Dave Cridland wrote:
>
>>  A0004 LIST (SUBSCRIBED MATCHPARENT) "" "%"
>>  * LIST (\Subscribed) "/" "Fruit"
>>  * LIST () "/" "Veg" ((CHILDINFO (\Subscribed))
>>  A0004 OK
>
> I like this. Makes it very clear what was intended with it.

Agreed. This one's good.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GjTCg076172; Wed, 6 Oct 2004 09:45:29 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96GjTk7076171; Wed, 6 Oct 2004 09:45:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GjSfG076163 for ; Wed, 6 Oct 2004 09:45:28 -0700 (PDT) (envelope-from dave@cridland.net)
Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 30296154009; Wed,  6 Oct 2004 16:45:31 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline; xpolymertype="coverletter"
From: Dave Cridland 
To: Philip Guenther 
Cc: IMAP extensions Mailing List , Arnt Gulbrandsen 
Subject: Re: One command or several... 
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com>  <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net> <200410061616.i96GGDqS097315@lab.smi.sendmail.com>
In-Reply-To: <200410061616.i96GGDqS097315@lab.smi.sendmail.com>
Message-ID: <20041006164309.3678.28353.polymer@peirce.gestalt.entity.net>
X-Mailer: Infotrope Polymer/0.0.3
Date: Wed, 06 Oct 2004 17:43:09 +0100
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

On Wed Oct  6 17:16:13 2004, Philip Guenther wrote:
> 
> Dave Cridland  writes:
> >On Tue Oct  5 21:15:38 2004, Philip Guenther wrote:
> >> Arnt Gulbrandsen  writes:
> >> >AFAICT, there seems to be nothing mbox-or-pat and matchparent 
> can >> do >that cannot also be achieved using a series of simpler 
> list >> commands. >Correct?
> >> >> Yep.  Ditto for CHILDREN.
> >
> >Not exactly "Ditto", IMHO.
> 
> Given that you quoted my description of how a client can do CHILDREN
> with unextended LIST commands, I'm not sure what you mean by "Not
> exactly 'Ditto'"
> 
> 
Possibly a language issue: I read "Ditto" as meaning "Precisely the 
same".

I agreed with what you said, which implies that there is significant 
overhead in emulating CHILDREN by using multiple LISTs, unlike the 
mbox-or-pat syntax, for which the overhead is (I think) slight.

So "Ditto" is a little strong - it's possible to workaround the 
missing data, but it's definitely a workaround, unlike working around 
lack of mbox-or-pat, which is virtually no overhead at all, and 
produces precisely the same results for *almost* precisely the same 
data transfer.


> <...>
> >> Duplicating matchparent on the client side is even worse, as to 
> get
> >> placeholder info you have to add "*" to the end of the original
> >> pattern.
> >
> >% rather than *, presumably, but I largely agree with you, and the 
> >argument in general.
> 
> If you think that adding "%" (or "/%") to the end of a list command
> will get you matchparent info, then you forgot that \placeholder
> is returned if _any_ children are selected, even ones multiple
> levels of hierarchy down:

Yep, that had slipped my mind. Or at least, it had when I wrote 
that...

This further suggests that MATCHPARENT/CHILDREN are not exactly a 
"Ditto", see above. :-)


> 
> >Moreover, it introduces extra complexity into the syntax, 
> especially >because it introduces special handling of the empty 
> list-mailbox - or >more accurately, special handling of the special 
> handling... As >wonderfully ironic as that is, I can't see the 
> point in persuing that.
> 
> Even if multiple patterns are removed, the empty pattern will have
> to be mentioned to say what happens if you use options with 
> it...even
> if all it was to say was "the behavior of the empty pattern is
> unspecified if list options are used".

Not really. It's specified per-option, if at all. In principle, an 
empty pattern used with REMOTE could tell you whether the entire 
heirarchy was rooted remotely or not, for instance - that's 
potentially useful information.

Dave.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GgYxQ075944; Wed, 6 Oct 2004 09:42:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96GgYCP075943; Wed, 6 Oct 2004 09:42:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GgX6Y075898 for ; Wed, 6 Oct 2004 09:42:33 -0700 (PDT) (envelope-from tss@iki.fi)
Received: by danu.procontrol.fi (Postfix, from userid 106) id 046221C350C9; Wed,  6 Oct 2004 19:42:25 +0300 (EEST)
Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 1F6371C27E5D; Wed,  6 Oct 2004 19:42:20 +0300 (EEST)
In-Reply-To: <20041006093514.3678.27139.polymer@peirce.gestalt.entity.net>
References:  <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>  <20041006093514.3678.27139.polymer@peirce.gestalt.entity.net>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-46-662137989"
Message-Id: 
Content-Transfer-Encoding: 7bit
Cc: , Arnt Gulbrandsen 
From: Timo Sirainen 
Subject: Re: listext: some things I can't understand
Date: Wed, 6 Oct 2004 19:42:18 +0300
To: Dave Cridland 
X-Pgp-Agent: GPGMail 1.0.2
X-Mailer: Apple Mail (2.619)
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on danu.procontrol.fi
X-Spam-Level: 
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham  version=2.63
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--Apple-Mail-46-662137989
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 6.10.2004, at 12:35, Dave Cridland wrote:

> A0004 LIST (SUBSCRIBED MATCHPARENT) "" "%"
> * LIST (\Subscribed) "/" "Fruit"
> * LIST () "/" "Veg" ((CHILDINFO (\Subscribed))
> A0004 OK

I like this. Makes it very clear what was intended with it.

> A0005 LIST (SUBSCRIBED) "" "%" RETURN (CHILDREN)
> * LIST (\Subscribed) "/" "Fruit" (CHILDREN (\HasNoChildren))
> * LIST () "/" "Veg" (CHILDREN (\HasChildren \Subscribed))
> A0006 OK

\HasChildren and \HasNoChildren seems redundant here.

> Assuming that this syntax existed, would this:
> a) Remove the confusion over MATCHPARENT / \PlaceHolder / 
> \HasSubmailboxes ?

Yes, \PlaceHolder and \HasSubmailboxes could be dropped entirely then I 
think.

> b) Solve Philip's problem of parsing unsolicited responses (and Arnt's 
> problem of treating all responses as unsolicited.)?

I think this is the first solution where it would be easy for clients 
to parse mixed solicited/unsolicited LIST replies.

--Apple-Mail-46-662137989
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBZCBqyUhSUUBViskRAk0KAJ9HpLQXPLMpPEEv5pPLDc8ldA6eBQCfbpGX
yyUCykPEvqOuTb8G8MYHtWI=
=ei6l
-----END PGP SIGNATURE-----

--Apple-Mail-46-662137989--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GKBMc073951; Wed, 6 Oct 2004 09:20:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96GKBVj073950; Wed, 6 Oct 2004 09:20:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GKBNb073944 for ; Wed, 6 Oct 2004 09:20:11 -0700 (PDT) (envelope-from daboo@isamet.com)
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i96Fu0o3006116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2004 11:56:01 -0400
Date: Wed, 06 Oct 2004 12:19:30 -0400
From: Cyrus Daboo 
To: Dave Cridland , Philip Guenther 
cc: IMAP extensions Mailing List , Arnt Gulbrandsen 
Subject: Re: One command or several... 
Message-ID: <278BADDE17C67F56F230ACD4@ninevah.cyrusoft.com>
In-Reply-To: <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net>
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com> <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Hi Dave,

--On Wednesday, October 6, 2004 4:40 PM +0100 Dave Cridland 
 wrote:

> As for mbox-or-pat, I agree with Philip that there doesn't seem to be
> much point - pipelining the LIST commands acheives the same goal in -
> almost certainly - the same number of TCP packets, and only a small
> increased data transfer cost.

That's not necessarily true - it depends on how large the mbox-or-pat list 
is. Remember for each pipelined command, in addition to the unsolicited 
responses there is always the tagged OK - one for each command - and those 
do add overhead to the pipelined approach that is not present in the single 
command approach.

> Moreover, it introduces extra complexity into the syntax, especially
> because it introduces special handling of the empty list-mailbox - or
> more accurately, special handling of the special handling... As
> wonderfully ironic as that is, I can't see the point in persuing that.
>
> Is there any implementor who really wants this syntax in?

I guess I was one person requesting it. As more and more people use 
server-side filtering and plus-addressing techniques, users often need to 
operate on 'discrete' sets of mailboxes - i.e. ones that cannot be 
represented by a simple % or * LIST pattern. Being able to get information 
on those sets in one go is useful. Really the benefit of this comes if we 
look to potential extensions to LISTEXT - e.g. being able to specify SEARCH 
criteria to do multi-mailbox searches, or being able to request STATUS-like 
information.

However, at this point I wouldn't mind if we went back to just a single 
list-mailbox syntax and left mbox-or-pat for a future extension.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GHiSQ073672; Wed, 6 Oct 2004 09:17:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96GHi41073671; Wed, 6 Oct 2004 09:17:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GHinH073665 for ; Wed, 6 Oct 2004 09:17:44 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.6) with ESMTP id i96GGF6i029763 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 6 Oct 2004 09:16:18 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i96GGF6i029763
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=m520JHjkuHGirDx+P8XL204/lybyYVkeEh37Umcv1kAV4KqI172PHE01FjEIjfOvk W4yPiuESxgam4EzKuI9bIhEnBQ2eectsbJmyxvUv3j5WErkf0PHM3P3M4htny1qaUl8 5l4fm9yYUfYhCvtum5YZVIH0Yd7laKmAfw1IQ7U=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i96GGDqS097315; Wed, 6 Oct 2004 09:16:13 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410061616.i96GGDqS097315@lab.smi.sendmail.com>
To: Dave Cridland 
From: Philip Guenther 
Cc: IMAP extensions Mailing List , Arnt Gulbrandsen 
Subject: Re: One command or several... 
In-reply-to: <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net> 
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com>  <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net> 
Date: Wed, 06 Oct 2004 09:16:13 -0700
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Dave Cridland  writes:
>On Tue Oct  5 21:15:38 2004, Philip Guenther wrote:
>> Arnt Gulbrandsen  writes:
>> >AFAICT, there seems to be nothing mbox-or-pat and matchparent can 
>> do >that cannot also be achieved using a series of simpler list 
>> commands. >Correct?
>> 
>> Yep.  Ditto for CHILDREN.
>
>Not exactly "Ditto", IMHO.

Given that you quoted my description of how a client can do CHILDREN
with unextended LIST commands, I'm not sure what you mean by "Not
exactly 'Ditto'"

<...>
>> Duplicating matchparent on the client side is even worse, as to get
>> placeholder info you have to add "*" to the end of the original
>> pattern.
>
>% rather than *, presumably, but I largely agree with you, and the 
>argument in general.

If you think that adding "%" (or "/%") to the end of a list command
will get you matchparent info, then you forgot that \placeholder
is returned if _any_ children are selected, even ones multiple
levels of hierarchy down:
	10 LIST "" * RETURN (SUBSCRIBED)
	* LIST (\NoInferiors \Subscribed) "/" INBOX
	* LIST (\Subscribed) "/" bar/blip
	* LIST () "/" foo
	* LIST () "/" foo/bar
	* LIST (\Subscribed) "/" foo/bar/baz
	* LIST (\Subscribed) "/" quux
	10 OK Completed
	11 LIST (SUBSCRIBED MATCHPARENT) "" %
	* LIST (\NoInferiors \Subscribed) "/" INBOX
	* LIST (\NonExistent \PlaceHolder \HasChildren) "/" bar
	* LIST (\PlaceHolder \HasChildren) "/" foo
	* LIST (\Subscribed) "/" quux
	11 OK Completed
	12 LIST (SUBSCRIBED) "" %
	* LIST (\NoInferiors \Subscribed) "/" INBOX
	* LIST (\Subscribed) "/" quux
	12 OK Completed
	13 LIST (SUBSCRIBED) "" %/%                                         
	* LIST (\Subscribed) "/" bar/blip
	13 OK Completed

Neither of those last two returned anything to indicate that "foo"
has a subscribed mailbox below it.


Without matchparent in some form, there is no way to both efficiently
and completely list subscribed folders by hierarchical level.  Wave
goodbye to '%', say hello to '*'.  (The special handling of \Noselect
in LSUB was put there for a reason, folks!)



>Moreover, it introduces extra complexity into the syntax, especially 
>because it introduces special handling of the empty list-mailbox - or 
>more accurately, special handling of the special handling... As 
>wonderfully ironic as that is, I can't see the point in persuing that.

Even if multiple patterns are removed, the empty pattern will have
to be mentioned to say what happens if you use options with it...even
if all it was to say was "the behavior of the empty pattern is
unspecified if list options are used".


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96G5xUM072286; Wed, 6 Oct 2004 09:05:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96G5xNT072285; Wed, 6 Oct 2004 09:05:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96G5sf6072273 for ; Wed, 6 Oct 2004 09:05:54 -0700 (PDT) (envelope-from dave@cridland.net)
Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id AFA3B154009; Wed,  6 Oct 2004 16:05:56 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline; xpolymertype="coverletter"
From: Dave Cridland 
To: Arnt Gulbrandsen 
Cc: 
Subject: Re: One command or several...
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com> <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net> 
In-Reply-To: 
Message-ID: <20041006160334.3678.58915.polymer@peirce.gestalt.entity.net>
X-Mailer: Infotrope Polymer/0.0.3
Date: Wed, 06 Oct 2004 17:03:34 +0100
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

On Wed Oct  6 16:51:09 2004, Arnt Gulbrandsen wrote:
> Dave Cridland writes:
>> Worth noting that the existing CHILDREN extension, 3348, doesn't 
>> help ascertain whether clients are actually using it or not, so 
>> Arnt's suggestion that it's little used is difficult to assert. 
>> FWIW, a quick survey of IMAP clients on my machine suggested:
> 
> I did not mean to suggest so, and apologize for any 
> misunderstanding. I can easily imagine that RFC 3348 is fairly 
> widely used - it's easy for a client, and often comes in handy.
> 
> I believe I was trying to talk about matchparent's likelihood of 
> seeing wide use.

Ah... Sorry, I mentally lump them together. To me, they're the same 
functionality, but with different filters. (I'm thinking in terms of 
performing something like 'tag LIST "" "%" RETURN (REMOTE SUBSCRIBED 
CHILDREN)' as my 'usual' list command.)

FWIW, looks like I was wrong about Thunderbird - I can't find any 
evidence of it handling RFC3348, and it looks from 
http://lxr.mozilla.org/mozilla1.7/source/mailnews/imap/src/nsImapServerResponseParser.cpp#865 
as if it doesn't, to me.

Dave.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96Fohoo070277; Wed, 6 Oct 2004 08:50:43 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96FohS1070276; Wed, 6 Oct 2004 08:50:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id i96Fof0l070269 for ; Wed, 6 Oct 2004 08:50:42 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Received: by kalyani.oryx.com (Postfix, from userid 1005) id 6A6901BDE88; Wed,  6 Oct 2004 17:50:43 +0200 (CEST)
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by kalyani.oryx.com (Postfix) with SMTP id C92551BDE7F; Wed,  6 Oct 2004 17:50:41 +0200 (CEST)
Message-Id: 
Date: Wed, 6 Oct 2004 17:51:09 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: One command or several...
Cc: Philip Guenther , Dave Cridland 
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com> <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net>
In-Reply-To: <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Dave Cridland writes:
> Worth noting that the existing CHILDREN extension, 3348, doesn't help 
> ascertain whether clients are actually using it or not, so Arnt's 
> suggestion that it's little used is difficult to assert. FWIW, a 
> quick survey of IMAP clients on my machine suggested:

I did not mean to suggest so, and apologize for any misunderstanding. I 
can easily imagine that RFC 3348 is fairly widely used - it's easy for 
a client, and often comes in handy.

I believe I was trying to talk about matchparent's likelihood of seeing 
wide use.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96FgWWS068981; Wed, 6 Oct 2004 08:42:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96FgWR6068980; Wed, 6 Oct 2004 08:42:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96FgVnJ068973 for ; Wed, 6 Oct 2004 08:42:31 -0700 (PDT) (envelope-from dave@cridland.net)
Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 6D691154009; Wed,  6 Oct 2004 15:42:33 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline; xpolymertype="coverletter"
From: Dave Cridland 
To: Philip Guenther 
Cc: IMAP extensions Mailing List , Arnt Gulbrandsen 
Subject: Re: One command or several... 
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com>
In-Reply-To: <200410052015.i95KFcmx016253@lab.smi.sendmail.com>
Message-ID: <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net>
X-Mailer: Infotrope Polymer/0.0.3
Date: Wed, 06 Oct 2004 16:40:11 +0100
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

On Tue Oct  5 21:15:38 2004, Philip Guenther wrote:
> 
> Arnt Gulbrandsen  writes:
> >AFAICT, there seems to be nothing mbox-or-pat and matchparent can 
> do >that cannot also be achieved using a series of simpler list 
> commands. >Correct?
> 
> Yep.  Ditto for CHILDREN.

Not exactly "Ditto", IMHO.


> >If so, why? It seems to make life harder for servers just in case 
> a >client ever uses it. That sort of thing is a good tradeoff if 
> many >clients will use it, something I find hard to believe in this 
> >particular case.
> 
> The argument is that for some of the info, the server can do the 
> test
> much more efficiently than the client.  For example, the children 
> info
> can be obtained by a client by doing  for each 
> name
> returned by the previous command; if the client just wants the 
> boolean
> "has some/no children", then listing all the children is way 
> overkill.
> 
> Duplicating matchparent on the client side is even worse, as to get
> placeholder info you have to add "*" to the end of the original
> pattern.

% rather than *, presumably, but I largely agree with you, and the 
argument in general.

In addition, the use of multiple LIST commands in this case 
introduces a higher latency, as you've at least two round-trips to 
wait.

Worth noting that the existing CHILDREN extension, 3348, doesn't help 
ascertain whether clients are actually using it or not, so Arnt's 
suggestion that it's little used is difficult to assert. FWIW, a 
quick survey of IMAP clients on my machine suggested:

Evolution (Ximian): Apparently recognizes RFC3348 (based on output of 
strings)
Balsa: Likewise.
mutt: Appears to recognize \HasNoChildren, but treats it equivalently 
with \NoInferiors. (Whether that means it treats \NoInferiors as 
\HasNoChildren ought to be treated, or the other way around, I have 
no idea.) Checked by reading source.
Mine handles it fine. (And in fact assumes there are children unless 
told otherwise, and removes the "child" flag if subsequent expansion 
proves there are none, so it's actually ignoring \HasChildren, and 
only using \HasNoChildren and \NoInferiors.)

I read, but haven't checked, that Thunderbird and Apple's Mail 
program both support it - I couldn't actually find any evidence of 
Thunderbird supporting it from "strings", though, but Google 
suggested that Thunderbird fails to find submailboxes if \HasChildren 
isn't present in some versions... (Even when the server isn't 
advertising CHILDREN)

I'm guessing that Outlook and Outlook Express support it, given that 
it's a Microsoft initiated standard.

This suggests quite widespread use of the information, but not always 
correctly.


As for mbox-or-pat, I agree with Philip that there doesn't seem to be 
much point - pipelining the LIST commands acheives the same goal in - 
almost certainly - the same number of TCP packets, and only a small 
increased data transfer cost.

Moreover, it introduces extra complexity into the syntax, especially 
because it introduces special handling of the empty list-mailbox - or 
more accurately, special handling of the special handling... As 
wonderfully ironic as that is, I can't see the point in persuing that.

Is there any implementor who really wants this syntax in?

Dave.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i969bekV008407; Wed, 6 Oct 2004 02:37:40 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i969beSU008405; Wed, 6 Oct 2004 02:37:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i969bZMD008363 for ; Wed, 6 Oct 2004 02:37:36 -0700 (PDT) (envelope-from dave@cridland.net)
Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id BEAE6154009; Wed,  6 Oct 2004 09:37:35 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline; xpolymertype="coverletter"
From: Dave Cridland 
To: Arnt Gulbrandsen 
Cc: 
Subject: Re: listext: some things I can't understand
References:  <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net> 
In-Reply-To: 
Message-ID: <20041006093514.3678.27139.polymer@peirce.gestalt.entity.net>
X-Mailer: Infotrope Polymer/0.0.3
Date: Wed, 06 Oct 2004 10:35:14 +0100
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Since we're in a mood to try new syntaxes again...

On Tue Oct  5 18:24:50 2004, Arnt Gulbrandsen wrote:
> 
> I understand now why some of this is so hard on my brain: Part of 
> the listext response is about the mailboxes, and another part is 
> about the command.
> 
> My gut feeling is that IMAP works best when untagged responses can 
> be parsed independently of the command that caused them. This is 
> not currently the case for listext.
> 
> 
Agreed. As I was writing my last confused missive, I "got" what 
Philip has been saying, largely.


> Dave Cridland writes:
>> My head hurts quite a bit with some of the subtleties, too.
> 
> I'm sad to hear that. Makes it seem even less likely that clients 
> authors will be able to make use of this stuff.
> 
> 
Bear in mind I'm a client author of little brain. On the other hand, 
most IMAP client authors are.

> In fact, this requires an addition to RFC 3501 section 5.5, 
> specifying that two list commands cannot be issued concurrently 
> when one uses matchparent.
> 
> 
There's an argument here for proposing that extended LIST commands 
should actually have tagged intermediates, like ACAP does. (Actually, 
having them in lots of places would be handy. Perhaps a 
command-a-like similar to UID would be handy here.)

The trouble is that I suspect this'd really confuse a lot of existing 
parsers. (Depends on whether you look at the response or the tag 
first. If you look at the tag, see it's not "*", and assume command 
completion, you'd have a rewrite on your hands. My parser does not, 
because it's written around ACAP as well.)

So while I'd personally love to see tagged intermediates for LIST and 
SEARCH/SORT/THREAD, I doubt it'd be popular.

>> \Placeholder makes sense to me. It implies that *this* mailbox 
>> doesn't match the criteria, but has inferior mailboxes that do.
> ...
>> \HasSubmailboxes I find excessively confusing - it implies that 
>> this mailbox *does* match, but also that there are child mailboxes 
>> that, well, might. I would expect that a server should only return 
>> this when there *is* a child mailbox which matches the selection 
>> options, although potentially not the pattern[s].
> 
> These are the two that confused me so much. Still do, but now I 
> know why: Because they're not actually attributes of the mailbox, 
> they're attributes of the search being processed.

Yeah, \HasSubmailboxes is really \AlsoHasMatchingSubmailboxes.

So, alternative strategy:

For an extended LIST, we stick the child mailbox information 
somewhere else:

Given:

A0002 LIST "" "*"
* LIST () "/" "Fruit"
* LIST () "/" "Veg"
* LIST () "/" "Veg/Cabbage"
A0002 OK

And:

A0003 LIST "" "*" RETURN (SUBSCRIBED)
* LIST (\Subscribed) "/" "Fruit"
* LIST () "/" "Veg"
* LIST (\Subscribed) "/" "Veg/Cabbage"
A0003 OK

Then we could do:

A0004 LIST (SUBSCRIBED MATCHPARENT) "" "%"
* LIST (\Subscribed) "/" "Fruit"
* LIST () "/" "Veg" ((CHILDINFO (\Subscribed))
A0004 OK

The last tagged response can be parsed independently of the child. 
I've stuck with MATCHPARENT, but this could be, arguably, a RETURN 
(CHILDINFO) instead.

You could even:

A0005 LIST (SUBSCRIBED) "" "%" RETURN (CHILDREN)
* LIST (\Subscribed) "/" "Fruit" (CHILDREN (\HasNoChildren))
* LIST () "/" "Veg" (CHILDREN (\HasChildren \Subscribed))
A0006 OK

Again, this is semantically understandable outside of the command, I 
think, and means:

* LIST {A subscribed mailbox called "Fruit", which has no children.}
* LIST {An unsubscribed mailbox called "Veg", which has children, 
some of which are subscribed.}

Assuming that this syntax existed, would this:
a) Remove the confusion over MATCHPARENT / \PlaceHolder / 
\HasSubmailboxes ?
b) Solve Philip's problem of parsing unsolicited responses (and 
Arnt's problem of treating all responses as unsolicited.)?

Dave.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95LrOiO061454; Tue, 5 Oct 2004 14:53:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95LrOY8061453; Tue, 5 Oct 2004 14:53:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95LrNjm061443 for ; Tue, 5 Oct 2004 14:53:23 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.6) with ESMTP id i95LrF03013219 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 5 Oct 2004 14:53:15 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i95LrF03013219
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=AAIQyN8FL68A6usWsj8DDzx2x9iLvDGYri0Tx7c8p829PSl//JYeoLZYZbhyv1EFX fbl/unyq1iF1cwcvyhwfVHYFFEZ4hfY73Sld00bYlCSqdbEwOoD7y7I3oRvy+SnkhPQ mBar9o8oHKAajMsWg9QOb2V+Y0VQKdUvdlU95+Y=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i95LrFEx023504; Tue, 5 Oct 2004 14:53:15 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410052153.i95LrFEx023504@lab.smi.sendmail.com>
To: Timo Sirainen 
Cc: IMAP Extensions WG 
From: Philip Guenther 
Subject: Re: Listext 
In-reply-to: <21665028-1708-11D9-B9A0-000393CC2E90@iki.fi> 
References: <21665028-1708-11D9-B9A0-000393CC2E90@iki.fi> 
Date: Tue, 05 Oct 2004 14:53:15 -0700
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Timo Sirainen  writes:
>>Note that return options MUST NOT cause the server to report
>>information about additional mailbox names. If the client has not
>>specified any return option, only information about attributes should
>>be returned by the server.
>
>I don't understand at all what this is trying to say.

The first sentence says that adding a return option (e.g., CHILDREN)
can't make the server return more responses than it would without the
return option.  Adding a return option can only affect the flags
included in the responses.

The second sentence is trying to say that if you don't specify any
return options, the server should still send the stuff that it would
have for unextended LIST, such as \noselect, \noinferiors, \marked,
etc.


> >   The server MAY return data in the extended fields that was not 
>solicited
> >   by the client. The client MUST ignore all extended fields it doesn't
> >   recognize.
>
>But only after client has indicated it supports LISTEXT by sending 
>extended LIST command?

Hmm, yeah, the server should be forbidden from sending extended
information until the client does something to indicate it understands
the syntax, be it an extended LIST command or some other extension that
documents that it may trigger extended information.

...
>>However, absence of both \PlaceHolder and \HasSubMailboxes doesn't
>>tell whether there are any children that meet the selection criteria
>>and match the canonical LIST pattern.
>
>How about changing the last sentence to something like:
>
>However the mailbox may still have children that match the selection 
>criteria and canonical LIST pattern, they are then guaranteed to be 
>returned in a different LIST response so \HasSubMailboxes isn't needed.

Change the comma to a semicolon, and change "needed" to "required" and
it looks right.


...
>I'd actually recommend changing the meaning of \PlaceHolder to simply 
>mean that the mailbox didn't match the selection criteria and it's 
>listed there for some other reason. There would be two reasons:
>
>1) It also contains \HasSubMailboxes flag
>
>2) All unilateral LIST responses sent by server would have that flag, 
>which would make it easy for clients to detect.
>
>Their names could then be:
>
>\PlaceHolder -> \UnMatched
>\HasSubMailboxes -> \ChildMatched

Those should be something like \NotSelected and \ChildSelected, because
the named mailboxes _does_ match the pattern and the child(ren) in
question _doesn't_ match the pattern but _is_ selected.

So, you're suggesting approximately:

OLD			NEW
-----------------------------------------------------------
\HasSubMailboxes	\ChildSelected			(1)
\PlaceHolder		\ChildSelected \NotSelected	(2)

(1) named mailbox is both matched and selected, there exists a child
    that's selected
(2) named mailbox is matched but not selected, there exists a child
    that's selected


Do people find this easier to understand?

(I'm not convinced the "all unilateral LIST responses need flag '\foo'"
idea is a wise path to follow, partly because it's a change in the
'social contract' and partly because someone will try to extend the idea
to other types of server responses, which I think is a Bad Idea.)


...
>I find the MATCHPARENT naming a bit strange too, to me it seems more 
>like it's matching children, especially in \HasSubmailboxes case.

The child is _not_ matched (by the pattern), but rather meets the
selection criterium.


>Is \PlaceHolder LIST replies required at all if MATCHPARENT isn't 
>given? ie. is this right:
>
>1 LIST (SUBSCRIBED) "" *
>* LIST (\Subscribed) "/" "box/subscribed"
>1 OK
>2 LIST (SUBSCRIBED) "" %
>2 OK
>3 LIST (SUBSCRIBED MATCHPARENT) "" %
>* LIST (\PlaceHolder) "/" box
>3 OK

That's correct.  The observant may note that LSUB is closest to  except you drop the \hassubmailboxes flag
and the normal \noselect flag and translate \placeholder to \noselect.


>Should something here be said also about the order in which LIST 
>replies may come from server? ie. is this allowed or not:
>
>* LIST () "/" foo/bar
>* LIST () "/" foo

It's allowed.  Neither the base-spec nor the LISTEXT draft state any
requirements on the server for sorting of LIST replies.  Any
specification of that would require a means for the client to specify a
comparator to handle the i18n aspect.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95KFeJ3049110; Tue, 5 Oct 2004 13:15:40 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95KFdcw049109; Tue, 5 Oct 2004 13:15:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95KFdRo049103 for ; Tue, 5 Oct 2004 13:15:39 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i95KFcag012401 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 5 Oct 2004 13:15:38 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i95KFcag012401
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=pQU/XUVvX4FuwQNo1tDErOO7DtRLkfrVlXaiZHQI8nWbCSfEqE3mOMAPVrrop2Dvu y0US8B8/vE5+1jI7gXX0tZnD48x1ql/t1Dqq6F1AlSYSiplUg3a+DV3MsEVMTj45YJh GZyXo3ScC8Zd8qWBxdupyUgrZa6bEU1oiPr22Mw=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i95KFcmx016253; Tue, 5 Oct 2004 13:15:38 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410052015.i95KFcmx016253@lab.smi.sendmail.com>
From: Philip Guenther 
To: Arnt Gulbrandsen 
cc: IMAP extensions Mailing List 
Subject: Re: One command or several... 
Date: Tue, 05 Oct 2004 13:15:38 -0700
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Arnt Gulbrandsen  writes:
>AFAICT, there seems to be nothing mbox-or-pat and matchparent can do 
>that cannot also be achieved using a series of simpler list commands. 
>Correct?

Yep.  Ditto for CHILDREN.


>If so, why? It seems to make life harder for servers just in case a 
>client ever uses it. That sort of thing is a good tradeoff if many 
>clients will use it, something I find hard to believe in this 
>particular case.

The argument is that for some of the info, the server can do the test
much more efficiently than the client.  For example, the children info
can be obtained by a client by doing  for each name
returned by the previous command; if the client just wants the boolean
"has some/no children", then listing all the children is way overkill.

Duplicating matchparent on the client side is even worse, as to get
placeholder info you have to add "*" to the end of the original
pattern.


As for the multiple pattern bit, well, I can't say I'm completely
convinced that it should be there.  Indeed, my implementation** simply
does each pattern one after the other with no duplicate suppression.


Philip Guenther

** if you want to throw some commands at a server implementing draft-10,
   fire me a note.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95KET81049020; Tue, 5 Oct 2004 13:14:29 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95KETRa049019; Tue, 5 Oct 2004 13:14:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95KETxj049009 for ; Tue, 5 Oct 2004 13:14:29 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i95KEMit012021 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 5 Oct 2004 13:14:22 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i95KEMit012021
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=s6KdiIYi7EXzNwDuxHZoXYIOuPpxZK4I03/XPIEJ/PxdND3fx7rdgvT1z2nJw379Z My3DV8FbPzNmr4L1Ov5P2QSK/X5NyoU2JvnD/xFV5f3upa4YwcHP+beHRl5EfpoBqEt mekGOezJHvWrXuyupowP4NxhnEc+XIgEX311XiM=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i95KELo8015900; Tue, 5 Oct 2004 13:14:22 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410052014.i95KELo8015900@lab.smi.sendmail.com>
To: Arnt Gulbrandsen 
Cc: IMAP extensions Mailing List 
Subject: Re: One command or several... 
In-reply-to:  
References:  
Date: Tue, 05 Oct 2004 13:14:21 -0700
From: Philip Guenther 
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Arnt Gulbrandsen  writes:
>AFAICT, there seems to be nothing mbox-or-pat and matchparent can do 
>that cannot also be achieved using a series of simpler list commands. 
>Correct?

Yep.  Ditto for CHILDREN.


>If so, why? It seems to make life harder for servers just in case a 
>client ever uses it. That sort of thing is a good tradeoff if many 
>clients will use it, something I find hard to believe in this 
>particular case.

The argument is that for some of the info, the server can do the test
much more efficiently than the client.  For example, the children info
can be obtained by a client by doing  for each name
returned by the previous command; if the client just wants the boolean
"has some/no children", then listing all the children is way overkill.

Duplicating matchparent on the client side is even worse, as to get
placeholder info you have to add "*" to the end of the original
pattern.


As for the multiple pattern bit, well, I can't say I'm completely
convinced that it should be there.  Indeed, my implementation** simply
does each pattern one after the other with no duplicate suppression.


Philip Guenther

** if you want to throw some commands at a server implementing draft-10,
   fire me a note.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Jr2k3047408; Tue, 5 Oct 2004 12:53:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95Jr2UT047407; Tue, 5 Oct 2004 12:53:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Jr0ci047388 for ; Tue, 5 Oct 2004 12:53:01 -0700 (PDT) (envelope-from tss@iki.fi)
Received: by danu.procontrol.fi (Postfix, from userid 106) id EAFE81C35337; Tue,  5 Oct 2004 22:52:52 +0300 (EEST)
Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id E97141C3531B for ; Tue,  5 Oct 2004 22:52:47 +0300 (EEST)
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <21665028-1708-11D9-B9A0-000393CC2E90@iki.fi>
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-27-587166595"
To: IMAP Extensions WG 
From: Timo Sirainen 
Subject: Listext
Date: Tue, 5 Oct 2004 22:52:47 +0300
X-Pgp-Agent: GPGMail 1.0.2
X-Mailer: Apple Mail (2.619)
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on danu.procontrol.fi
X-Spam-Level: 
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham  version=2.63
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--Apple-Mail-27-587166595
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

 > Note that return options MUST NOT cause the server to report
 >   information about additional mailbox names. If the client has not 
specified
 >   any return option, only information about attributes should be 
returned by
 >   the server.

I don't understand at all what this is trying to say.

 >   The server MAY return data in the extended fields that was not 
solicited
 >   by the client. The client MUST ignore all extended fields it doesn't
 >   recognize.

But only after client has indicated it supports LISTEXT by sending 
extended LIST command?

 >   When the MATCHPARENT selection option was specified by the client,
 >   the absence of both \PlaceHolder and \HasSubMailboxes means that the
 >   mailbox meets the selection criteria, but doesn't have any children 
that
 >   also meets the selection criteria and doesn't match the canonical 
LIST
 >   pattern. However, absence of both \PlaceHolder and \HasSubMailboxes 
doesn't
 >   tell whether there are any children that meet the selection 
criteria and
 >   match the canonical LIST pattern.

How about changing the last sentence to something like:

However the mailbox may still have children that match the selection 
criteria and canonical LIST pattern, they are then guaranteed to be 
returned in a different LIST response so \HasSubMailboxes isn't needed.

 >   The "\PlaceHolder" and the "\HasSubMailboxes" attributes are 
mutually
 >   exclusive.

I agree Dave's comment here that "mutually exclusive" is a bit 
confusing because they are quite similiar.

I'd actually recommend changing the meaning of \PlaceHolder to simply 
mean that the mailbox didn't match the selection criteria and it's 
listed there for some other reason. There would be two reasons:

1) It also contains \HasSubMailboxes flag

2) All unilateral LIST responses sent by server would have that flag, 
which would make it easy for clients to detect.

Their names could then be:

\PlaceHolder -> \UnMatched
\HasSubMailboxes -> \ChildMatched

Or actually, alternative to \PlaceHolder or \UnMatched would be to just 
return \Matched to all matched replies. Then server could keep sending 
old style LIST replies unilaterally without making it ambiguous to 
client that they are unilateral. Of course, it also means 8 bytes more 
for each requested LIST reply.

I find the MATCHPARENT naming a bit strange too, to me it seems more 
like it's matching children, especially in \HasSubmailboxes case.

Is \PlaceHolder LIST replies required at all if MATCHPARENT isn't 
given? ie. is this right:

1 LIST (SUBSCRIBED) "" *
* LIST (\Subscribed) "/" "box/subscribed"
1 OK
2 LIST (SUBSCRIBED) "" %
2 OK
3 LIST (SUBSCRIBED MATCHPARENT) "" %
* LIST (\PlaceHolder) "/" box
3 OK

 > 3.1. General principles for returning LIST responses

Are these a MUST? Especially the "don't return mailbox more than once" 
rule?

Should something here be said also about the order in which LIST 
replies may come from server? ie. is this allowed or not:

* LIST () "/" foo/bar
* LIST () "/" foo

--Apple-Mail-27-587166595
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBYvuPyUhSUUBViskRAjN/AJ4jco+WlqbYjfU6i0vEqa325JyIMgCfXLED
4JyAkwZjmI3ZEJ/YutOPNQA=
=tVOS
-----END PGP SIGNATURE-----

--Apple-Mail-27-587166595--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95JBCms043998; Tue, 5 Oct 2004 12:11:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95JBCqg043997; Tue, 5 Oct 2004 12:11:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95JB7KL043989 for ; Tue, 5 Oct 2004 12:11:07 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i95JB0WT024906 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 5 Oct 2004 12:11:01 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i95JB0WT024906
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=lroMjgHTf3TzMi7AMzj7peHWLdMRdghSw1lV8daSq2b/JhZhudOAV4SrnK98yOoDA c+C2xCZRo675fhMrfX0Uh3StK+BHC2R+Hk8k/kLZh8b6MstdpJhT9LIFiE7vQ0c/096 bR0aG51nf51/qd/VdtPdnfTg4Fip/KSJ+l+w/r0=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i95JB0cG011324; Tue, 5 Oct 2004 12:11:00 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410051911.i95JB0cG011324@lab.smi.sendmail.com>
To: Arnt Gulbrandsen 
Cc: ietf-imapext@imc.org
From: Philip Guenther 
Subject: Re: listext: some things I can't understand 
In-reply-to:  
References:  
Date: Tue, 05 Oct 2004 12:11:00 -0700
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Arnt Gulbrandsen  writes:
...
>1. The children return option. Isn't that a noop? The server may ignore 
>the option, and may (per RFC 3501/3348) send the \haschildren and 
>\hasnochildren attributes even if children isn't present. The 'then' 
>and 'else' parts of that test look more than a little similar to me.

I vaguely recall (but may be hallucinating) that someone proposed making
the CHILDREN option a separate capability with support implying that
when requested, every response would have \haschildren or
\hasnochildren.  Scanning the list archive, it appears that was
kinda-sorta decided against based on the fact that the current children
support (RFC 3348) doesn't have a capability associated with it, but
that doesn't make logical sense as _that_ decision stems from the lack
of a way to request the info.

Can anyone point to a reason for the decision to not make CHILDREN a
separate capability, perhaps a thread in the archive that I missed?


>2. The matchparent thingy. The draft goes to great lengths to describe 
>the difference betweeen \hassubmailboxes and \placeholder, and I have 
>problems understanding the point of either.

A quick summary of the history as I understand it: the MATCHPARENT
option and its flags stem from LSUB's odd-ball \noselect handling.
Initially, there was only \placeholder, modelled directly on LSUB's
\noselect: it would be returned if there was a selected child that
didn't match the pattern.

\hassubmailboxes came about after a discussion about whether LSUB could
and should return the same mailbox twice, once with \noselect and once
without, if the mailbox is subscribed and also has subscribed children
that don't match the pattern.  This was felt to be more confusing than
having a single flag that conveyed those bits in one response.



>What does \placeholder convey that \noselect \haschildren does not?

\placeholder does not imply that the mailbox cannot be the target of
SELECT.  It says that it doesn't meet the selection criteria, e.g., it
isn't subscribed.


>Why do we need both \nonexistent and \noselect?

So, overload \noselect to mean that the mailbox might not exist at all?
That's a question for the client authors.  Is the distinction useful
enough to them that servers need to make it?


>Why do we need all of \placeholder, \hassubmailboxes, \haschildren, 
>\hasnochildren and \noinferiors?

I asked this question (why both MATCHPARENT and CHILDREN?) at the San
Diego meeting and the response by the room was that they're both
useful.  Sure, but are they both useful enough to be worth inflicting on
every server?

Note that the _main_ difference between MATCHPARENT and CHILDREN is what
happens in the SUBSCRIBED case, as they would be practically the same in
the sans SUBSCRIBED case: if it wasn't directly banned by the draft,
	tag LIST (MATCHPARENT) ref pat
would be effectively the same as
	tag LIST ref pat RETURNS (CHILDREN)
in that you could derive the children flags from the matchparent flags
(of the lack there of).

So, they're redundant when SUBSCRIBED isn't used (or would if that ban
wasn't there).  That makes the main question, in my opinion, whether
they're both useful where they differ, in the SUBSCRIBED case.  CHILDREN
tells you whether the mailbox has submailboxes that exist, subscribed or
not; MATCHPARENT tells you whether the mailbox has submailboxes that are
subscribed, whether they exist or not.  I'm not a client maintainer, but
I would expect the latter to be significantly more useful than the
former.

Is there consensus that both these are useful enough to require server
support?  If not, let's pick one to require and one to completely drop.


>Oh, and why is the opposite of \noinferiors not called \inferiors?

\noinferiors	-> can't have children
\hasnochildren	-> can have children, but doesn't (..that you can see...)
(nothing)	-> can have children, may or may not
\haschildren	-> can have children, and does

Which of those would be \inferiors?

Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HOu7O034417; Tue, 5 Oct 2004 10:24:56 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95HOuHi034416; Tue, 5 Oct 2004 10:24:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95HOohT034392 for ; Tue, 5 Oct 2004 10:24:55 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 7E1271A6BC; Tue,  5 Oct 2004 19:24:53 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 1C5FF1A6C2 for ; Tue,  5 Oct 2004 19:24:51 +0200 (CEST)
Message-Id: 
Date: Tue, 5 Oct 2004 19:24:50 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
References:  <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>
In-Reply-To: <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i95HOuhT034411
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

I understand now why some of this is so hard on my brain: Part of the 
listext response is about the mailboxes, and another part is about the 
command.

My gut feeling is that IMAP works best when untagged responses can be 
parsed independently of the command that caused them. This is not 
currently the case for listext.

Dave Cridland writes:
> My head hurts quite a bit with some of the subtleties, too.

I'm sad to hear that. Makes it seem even less likely that clients 
authors will be able to make use of this stuff.

...
> \Placeholder implies that:
>
> 1) The mailbox *does* exist, but doesn't match the current criteria.
> 2) The mailbox has inferior mailboxes, some of which *do* match the 
> current selection criteria.

I see what you're saying now, but in order to make sense of it, I have 
to think in terms of a command. More like a tagged response than an 
untagged one.

In fact, this requires an addition to RFC 3501 section 5.5, specifying 
that two list commands cannot be issued concurrently when one uses 
matchparent.

>> Why do we need both \nonexistent and \noselect?
>
> Yeah, the difference is pretty subtle.
>
> Foo LIST "" "%"
> * LIST (\NoSelect) "/" "Stuff"
> Foo OK
>
> Bar LIST (SUBSCRIBED) "" "%"
> * LIST (\NonExistent \Subscribed) "/" "Other Stuff"
> Bar OK
>
> Neither Stuff nor Other Stuff exist. The difference is that a LIST of 
> "Stuff/%" is pretty likely to give some responses, since the node 
> exists in the mailbox heirarchy, as it were, whereas "Other Stuff/%" 
> won't - if it would do, it'd have been returned in the first list.
>
> FWIW, I rewrote these paragraphs several times with agreements that 
> one implied the other before I realised that they have subtly 
> different usages. I'm  still not entirely sure whether this is the 
> case, in fact.
>
> Would:
> * LIST (\NoSelect \Subscribed) "/" "Other Stuff"
>
> be interpretable any other way, for the Bar command above?

Optimism knows no bounds. A client author who trusts every server author 
to understand the subtleties perfectly could read from that response 
that Other Stuff might have child mailboxes.

This seems to be the same as your \nonexistent response above:

* LIST (\noselect \hasnochildren \subscribed) "/" "Other Stuff"

>> Why do we need all of \placeholder, \hassubmailboxes, \haschildren, 
>> \hasnochildren and \noinferiors? And even if there's justification, 
>> isn't it a little too subtle for J. Client Author?
>
> \Placeholder makes sense to me. It implies that *this* mailbox doesn't 
> match the criteria, but has inferior mailboxes that do.
...
> \HasSubmailboxes I find excessively confusing - it implies that this 
> mailbox *does* match, but also that there are child mailboxes that, 
> well, might. I would expect that a server should only return this 
> when there *is* a child mailbox which matches the selection options, 
> although potentially not the pattern[s].

These are the two that confused me so much. Still do, but now I know 
why: Because they're not actually attributes of the mailbox, they're 
attributes of the search being processed.

(Thanks, Barry and Dave.)

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Gs4BI030739; Tue, 5 Oct 2004 09:54:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95Gs4HK030738; Tue, 5 Oct 2004 09:54:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Grxpv030691 for ; Tue, 5 Oct 2004 09:53:59 -0700 (PDT) (envelope-from dave@cridland.net)
Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id B0CB0154009; Tue,  5 Oct 2004 16:53:51 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline; xpolymertype="coverletter"
From: Dave Cridland 
To: Arnt Gulbrandsen 
Cc: 
Subject: Re: listext: some things I can't understand
References: 
In-Reply-To: 
Message-ID: <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>
X-Mailer: Infotrope Polymer/0.0.3
Date: Tue, 05 Oct 2004 17:51:31 +0100
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Hiya Arnt,

On Tue Oct  5 16:26:15 2004, Arnt Gulbrandsen wrote:
> 
> I like the ext part of listext. More flexible list command: good. 
> Forgetting that rlist and lsub exist: Highly desirable.
> 
> Some of the specific extensions are difficult for a small little 
> arnt to understand, though.
> 
> 
My head hurts quite a bit with some of the subtleties, too.


> 1. The children return option. Isn't that a noop? The server may 
> ignore the option, and may (per RFC 3501/3348) send the 
> \haschildren and \hasnochildren attributes even if children isn't 
> present. The 'then' and 'else' parts of that test look more than a 
> little similar to me.
> 
> 
It gets worse, actually. The server "MAY ignore" it, but "SHOULD 
return" the information, which seems to give me two levels of 
requirement for the same thing.

One thing that CHILDREN (The new and improved LISTEXT return option, 
I mean) gives me, the client author, is a way of saying "Look, I 
could do with this information, but don't sweat it, I can always 
issue another LIST to find out later." If you prefer, it's a useful 
method of being nice to the server.


> 2. The matchparent thingy. The draft goes to great lengths to 
> describe the difference betweeen \hassubmailboxes and \placeholder, 
> and I have problems understanding the point of either.
> 
> What does \placeholder convey that \noselect \haschildren does not?
> 
> 
\NoSelect \HasChildren implies that:

1) The mailbox cannot be the subject of a SELECT command - basically, 
it doesn't exist.
2) The mailbox has inferior mailboxes. It says nothing about whether 
those match the current selection criteria.

\Placeholder implies that:

1) The mailbox *does* exist, but doesn't match the current criteria.
2) The mailbox has inferior mailboxes, some of which *do* match the 
current selection criteria.


> Why do we need both \nonexistent and \noselect?
> 
> 
Yeah, the difference is pretty subtle.

Foo LIST "" "%"
* LIST (\NoSelect) "/" "Stuff"
Foo OK

Bar LIST (SUBSCRIBED) "" "%"
* LIST (\NonExistent \Subscribed) "/" "Other Stuff"
Bar OK

Neither Stuff nor Other Stuff exist. The difference is that a LIST of 
"Stuff/%" is pretty likely to give some responses, since the node 
exists in the mailbox heirarchy, as it were, whereas "Other Stuff/%" 
won't - if it would do, it'd have been returned in the first list.

FWIW, I rewrote these paragraphs several times with agreements that 
one implied the other before I realised that they have subtley 
different usages. I'm still not entirely sure whether this is the 
case, in fact.

Would:
* LIST (\NoSelect \Subscribed) "/" "Other Stuff"

be interpretable any other way, for the Bar command above?


> Why do we need all of \placeholder, \hassubmailboxes, \haschildren, 
> \hasnochildren and \noinferiors? And even if there's justification, 
> isn't it a little too subtle for J. Client Author?
> 
> 
\Placeholder makes sense to me. It implies that *this* mailbox 
doesn't match the criteria, but has inferior mailboxes that do.

\*Children merely indicate the mailbox definitely has, or definitely 
does not have, inferior mailboxes. It says nothing about whether they 
match the selection or not.

\HasSubmailboxes I find excessively confusing - it implies that this 
mailbox *does* match, but also that there are child mailboxes that, 
well, might. I would expect that a server should only return this 
when there *is* a child mailbox which matches the selection options, 
although potentially not the pattern[s].

Making \HasSubmailboxes and \Placeholder mutually exclusive confuses 
the hell out of me, to be honest - I'd expect \PlaceHolder to imply 
\HasSubmailboxes instead. (Flags already do imply one another, so no 
harm done.)

And finally, \NoInferiors implies an ongoing rule, not a current 
state.


> Oh, and why is the opposite of \noinferiors not called \inferiors?
> 
> 
There is no opposite to \NoInferiors. That would be called 
\InferiorsPossibleToCreateAndThereMightBeSomeAlready or something.


> This frustrates me. I guess you can tell. Some elucidation would be 
> great.
> 
> 
The above from my reading of the draft, not my reading of this list, 
and I'm certainly not any kind of authority.

Dave.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95GNHA8028562; Tue, 5 Oct 2004 09:23:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95GNHrf028561; Tue, 5 Oct 2004 09:23:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95GNDjU028546 for ; Tue, 5 Oct 2004 09:23:16 -0700 (PDT) (envelope-from leiba@watson.ibm.com)
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i95GMS787152 for ; Tue, 5 Oct 2004 12:22:28 -0400
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i95GN8s06178 for ; Tue, 5 Oct 2004 12:23:08 -0400
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i95GN8O37692 for ; Tue, 5 Oct 2004 12:23:08 -0400
Received: from sig-9-65-66-241.mts.ibm.com ([9.65.66.241]) by mars.watson.ibm.com ID IMFd1096993387.1; Tue, 05 Oct 2004 12:23:07 -0400
Date: Tue, 05 Oct 2004 12:23:07 -0400
From: Barry Leiba 
To: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
Message-ID: <69A380A06652B5882F6C0A69@[192.168.200.2]>
In-Reply-To: 
References:  
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i95GNGjU028556
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

I'll address one question here:

> 1. The children return option. Isn't that a noop? The server may
> ignore the option, and may (per RFC 3501/3348) send the \haschildren
> and \hasnochildren attributes even if children isn't present.

Here's the background:
1. For some servers, this information is always avaliable, and costs
nothing to return, whether or not the client wants it.
2. For some servers, this information is expensive to provide, and they
don't want to provide it if the client doesn't want it.
3. Some clients want this information, and if the server doesn't
provide it they will get it with a multiplicity of LIST commands, the
sum of which is likely to be more expensive than the work to return the
information in the first place.

And so...
The return option is there for the client to tell the server that it
wants the information.  A server for which this information is trivial
to obtain may actually return it always, either way.  A server for
which this information is expensive to obtain may skip that expense if
the client doesn't ask for it.  A server whose implemementer does not
want to do the work can refuse to return it even if the client DOES ask
for it.  We strongly discourage this, but have left the choice there
because some people have objected to making "children" support required.

Those of us who want to require it claim that clients that want it will
use the required list commands to get it anyway, ultimately at greater
expense.  Still, it does require programming effort, and a server
developer may choose to spend that effort elsewhere.  Et voilą.

Barry

--
Barry Leiba, Pervasive Computing Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95FgJZg024930; Tue, 5 Oct 2004 08:42:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95FgJF6024929; Tue, 5 Oct 2004 08:42:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95FgIPE024922 for ; Tue, 5 Oct 2004 08:42:19 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id C0B781A6C6; Tue,  5 Oct 2004 17:42:20 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 6CEB61A6BB for ; Tue,  5 Oct 2004 17:42:18 +0200 (CEST)
Message-Id: 
Date: Tue, 5 Oct 2004 17:42:17 +0200
From: Arnt Gulbrandsen 
To: IMAP extensions Mailing List 
Subject: One command or several...
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

AFAICT, there seems to be nothing mbox-or-pat and matchparent can do 
that cannot also be achieved using a series of simpler list commands. 
Correct?

If so, why? It seems to make life harder for servers just in case a 
client ever uses it. That sort of thing is a good tradeoff if many 
clients will use it, something I find hard to believe in this 
particular case.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95FQLZ7023210; Tue, 5 Oct 2004 08:26:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95FQLhf023209; Tue, 5 Oct 2004 08:26:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95FQKjL023185 for ; Tue, 5 Oct 2004 08:26:21 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 1992F1A6C1; Tue,  5 Oct 2004 17:26:18 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id A20B41A6BA for ; Tue,  5 Oct 2004 17:26:15 +0200 (CEST)
Message-Id: 
Date: Tue, 5 Oct 2004 17:26:15 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: listext: some things I can't understand
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

I like the ext part of listext. More flexible list command: good. 
Forgetting that rlist and lsub exist: Highly desirable.

Some of the specific extensions are difficult for a small little arnt to 
understand, though.

1. The children return option. Isn't that a noop? The server may ignore 
the option, and may (per RFC 3501/3348) send the \haschildren and 
\hasnochildren attributes even if children isn't present. The 'then' 
and 'else' parts of that test look more than a little similar to me.

2. The matchparent thingy. The draft goes to great lengths to describe 
the difference betweeen \hassubmailboxes and \placeholder, and I have 
problems understanding the point of either.

What does \placeholder convey that \noselect \haschildren does not?

Why do we need both \nonexistent and \noselect?

Why do we need all of \placeholder, \hassubmailboxes, \haschildren, 
\hasnochildren and \noinferiors? And even if there's justification, 
isn't it a little too subtle for J. Client Author?

Oh, and why is the opposite of \noinferiors not called \inferiors?

This frustrates me. I guess you can tell. Some elucidation would be great.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94JjUkJ003119; Mon, 4 Oct 2004 12:45:30 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94JjUoT003118; Mon, 4 Oct 2004 12:45:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94JjThR003106 for ; Mon, 4 Oct 2004 12:45:29 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08582; Mon, 4 Oct 2004 15:45:30 -0400 (EDT)
Message-Id: <200410041945.PAA08582@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: ietf-imapext@imc.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-10.txt
Date: Mon, 04 Oct 2004 15:45:30 -0400
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba, A. Melnikov
	Filename	: draft-ietf-imapext-list-extensions-10.txt
	Pages		: 10
	Date		: 2004-10-4
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions that have required specialized lists (see
[MboxRefer] for an example) we have had to expand the number of list
commands, since each extension must add its function to both LIST and
LSUB, and these commands are not, as they are defined, extensible.
If we've needed the extensions to work together, we've had to add a
set of commands to mix the different options, the set increasing in
size with each new extension.  This document describes an extension
to the base LIST command that will allow these additions to be done
with mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-10.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-list-extensions-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-list-extensions-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-10-4152621.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-list-extensions-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-list-extensions-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-10-4152621.I-D@ietf.org>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94Ftten046059; Mon, 4 Oct 2004 08:55:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94FttS3046058; Mon, 4 Oct 2004 08:55:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94Fttxu046052 for ; Mon, 4 Oct 2004 08:55:55 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i94Ftvj4027239 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 4 Oct 2004 08:55:57 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i94Ftvj4027239
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=WcteR8lYaBt3peF4Snh7jMLvKNL5gsnCooh9AZ11ONK0viIv/MIlyg8OOIbkblGsu 151rqf36TIWHszPhhZN8hVODuklSW5NjjxZBXN8EFDbsu3FMYMEFnZMvWhlJRMZ1XMj 9wePCSEYGb5Flsx5dGWaypGWF7Y5F9TgFi+LcFE=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i94FtvUu095801; Mon, 4 Oct 2004 08:55:57 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410041555.i94FtvUu095801@lab.smi.sendmail.com>
To: Alexey Melnikov 
Cc: IMAP Extensions WG 
From: Philip Guenther 
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09 
In-reply-to: <41616DC4.8080105@isode.com> 
References: <4140B37E.5000401@isode.com>  <200409130633.i8D6XMmj059087@lab.smi.sendmail.com> <4151B3B4.9090105@isode.com> <200409230341.i8N3f9gV048309@lab.smi.sendmail.com> <416049CF.8060905@isode.com> <200410041335.i94DZvIa086491@lab.smi.sendmail.com>  <41616DC4.8080105@isode.com> 
Date: Mon, 04 Oct 2004 08:55:56 -0700
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Alexey Melnikov  writes:
>Philip Guenther wrote:
...
>>** does an unsolicited "\Placeholder \Subscribed" response mean the
>>   named mailbox has subscribed submailboxes, or does it mean the named
>>   mailbox is subscribed and it has (possibly remote) submailboxes?
>>  
>>
>The former. The latter would be "\HasSubMailboxes \Subscribed" (or even 
>"\HasSubMailboxes \Subscribed" if CHILDREN was also specified).

Sorry, change my argument to consider "\Placeholder \Subscribed
\Nonexistent": that's a nonexistent mailbox that either
a) has subscribed submailboxes (), or
b) is itself subscribed and has (possibly remote) submailboxes
   ()

The same problem exists with "\Hassubmailboxes \Subscribed": it's not
clear from the response whether the \Hassubmailboxes means there's
subscribed submailboxes or simply submailboxes (possibly remote).


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94FZaYC044619; Mon, 4 Oct 2004 08:35:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94FZa7E044618; Mon, 4 Oct 2004 08:35:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94FZZkf044606 for ; Mon, 4 Oct 2004 08:35:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 4 Oct 2004 16:35:33 +0100
Message-ID: <41616DC4.8080105@isode.com>
Date: Mon, 04 Oct 2004 16:35:32 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philip Guenther 
CC: IMAP Extensions WG 
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
References: <4140B37E.5000401@isode.com>  <200409130633.i8D6XMmj059087@lab.smi.sendmail.com> <4151B3B4.9090105@isode.com> <200409230341.i8N3f9gV048309@lab.smi.sendmail.com> 	<416049CF.8060905@isode.com> <200410041335.i94DZvIa086491@lab.smi.sendmail.com>
In-Reply-To: <200410041335.i94DZvIa086491@lab.smi.sendmail.com>
Content-Type: multipart/alternative; boundary="------------070508010502020303070906"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--------------070508010502020303070906
Content-type: text/plain; charset="us-ascii"

Philip Guenther wrote:

>Alexey Melnikov  writes:
>...
>  
>
>>As per off list discussion with Philip, I've changed the document to say 
>>that \PlaceHolder/\HasSubMailboxes is only allowed when MATCHPARENT is 
>>specified. In particular, this means that they are not allowed in LIST 
>>responses not caused by the latest LIST command.
>>
>>Philip's suggestion is that the server will send
>>"\Placeholder \Subscribed" in response to
>>.
>>This will mean "the mailbox is not really sibscribed, but the 
>>\Placeholder flag was caused by SUBSCRIBED selection option.
>>
>>IMHO, this seems to be overly complex. I think my change detailed above 
>>would suffice, however if WG members feel otherwise, I would like to 
>>hear their comments.
>>    
>>
>
>My suggestion was not really sufficient to completely remove the
>ambiguity of an unsolicited \Placeholder response**, so I support this
>change.
>
>
>Philip Guenther
>
>** does an unsolicited "\Placeholder \Subscribed" response mean the
>   named mailbox has subscribed submailboxes, or does it mean the named
>   mailbox is subscribed and it has (possibly remote) submailboxes?
>  
>
The former. The latter would be "\HasSubMailboxes \Subscribed" (or even 
"\HasSubMailboxes \Subscribed" if CHILDREN was also specified).

>   I.e., should the response be treated as if there was an outstanding
>    command or as if there was an
>   outstanding  ?
>   Either way, if the server sends that response right before the client
>   sends the LIST command that doesn't match what the server did, the
>   client will have no way of knowing that it should not treat that
>   \Placeholder in that LIST response as working under the selection
>   criteria that the client sent.
>  
>
Alexey


--------------070508010502020303070906
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit




  
  


Philip Guenther wrote:



  
Alexey Melnikov <Alexey.Melnikov@isode.com> writes:
...
  

  

    
As per off list discussion with Philip, I've changed the document to say 
that \PlaceHolder/\HasSubMailboxes is only allowed when MATCHPARENT is 
specified. In particular, this means that they are not allowed in LIST 
responses not caused by the latest LIST command.

Philip's suggestion is that the server will send
"\Placeholder \Subscribed" in response to
<LIST (SUBSCRIBED MATCHPARENT) "" "%">.
This will mean "the mailbox is not really sibscribed, but the 
\Placeholder flag was caused by SUBSCRIBED selection option.

IMHO, this seems to be overly complex. I think my change detailed above 
would suffice, however if WG members feel otherwise, I would like to 
hear their comments.
    

  

  

My suggestion was not really sufficient to completely remove the
ambiguity of an unsolicited \Placeholder response**, so I support this
change.


Philip Guenther

** does an unsolicited "\Placeholder \Subscribed" response mean the
   named mailbox has subscribed submailboxes, or does it mean the named
   mailbox is subscribed and it has (possibly remote) submailboxes?
  



The former. The latter would be "\HasSubMailboxes \Subscribed" (or even
"\HasSubMailboxes \Subscribed" if CHILDREN was also specified).



  
   I.e., should the response be treated as if there was an outstanding
   <LIST (SUBSCRIBED MATCHPARENT) ...> command or as if there was an
   outstanding <LIST (REMOTE MATCHPARENT) ... RETURN (SUBSCRIBED)> ?
   Either way, if the server sends that response right before the client
   sends the LIST command that doesn't match what the server did, the
   client will have no way of knowing that it should not treat that
   \Placeholder in that LIST response as working under the selection
   criteria that the client sent.
  



Alexey






--------------070508010502020303070906--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94DZxfZ036252; Mon, 4 Oct 2004 06:35:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94DZxdl036251; Mon, 4 Oct 2004 06:35:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94DZwtl036244 for ; Mon, 4 Oct 2004 06:35:58 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i94DZvWH017241 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 4 Oct 2004 06:35:58 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i94DZvWH017241
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=UnR0MF5ZVgNkYjLwX3ivyI9uNHGPji9aqYaB9DKFUVnK3zYEI4EEa7HpQIRbEcwMh DwCPeLDGGHR4D86OuosGImEZBmeK1nywa08Azk50e7qw+3WcXjzW5dfqbfTGt1xuxO+ 5jlhwrHm9bpAe5Pyi9SbkIh9V1Yz3WIFRUCeRf4=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i94DZvIa086491; Mon, 4 Oct 2004 06:35:57 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410041335.i94DZvIa086491@lab.smi.sendmail.com>
To: Alexey Melnikov 
Cc: IMAP Extensions WG 
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09 
In-reply-to: <416049CF.8060905@isode.com> 
References: <4140B37E.5000401@isode.com>  <200409130633.i8D6XMmj059087@lab.smi.sendmail.com> <4151B3B4.9090105@isode.com> <200409230341.i8N3f9gV048309@lab.smi.sendmail.com>  <416049CF.8060905@isode.com> 
Date: Mon, 04 Oct 2004 06:35:57 -0700
From: Philip Guenther 
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Alexey Melnikov  writes:
...
>As per off list discussion with Philip, I've changed the document to say 
>that \PlaceHolder/\HasSubMailboxes is only allowed when MATCHPARENT is 
>specified. In particular, this means that they are not allowed in LIST 
>responses not caused by the latest LIST command.
>
>Philip's suggestion is that the server will send
>"\Placeholder \Subscribed" in response to
>.
>This will mean "the mailbox is not really sibscribed, but the 
>\Placeholder flag was caused by SUBSCRIBED selection option.
>
>IMHO, this seems to be overly complex. I think my change detailed above 
>would suffice, however if WG members feel otherwise, I would like to 
>hear their comments.

My suggestion was not really sufficient to completely remove the
ambiguity of an unsolicited \Placeholder response**, so I support this
change.


Philip Guenther

** does an unsolicited "\Placeholder \Subscribed" response mean the
   named mailbox has subscribed submailboxes, or does it mean the named
   mailbox is subscribed and it has (possibly remote) submailboxes?
   I.e., should the response be treated as if there was an outstanding
    command or as if there was an
   outstanding  ?
   Either way, if the server sends that response right before the client
   sends the LIST command that doesn't match what the server did, the
   client will have no way of knowing that it should not treat that
   \Placeholder in that LIST response as working under the selection
   criteria that the client sent.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i949NNNT087255; Mon, 4 Oct 2004 02:23:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i949NN52087254; Mon, 4 Oct 2004 02:23:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i949NJRT087177 for ; Mon, 4 Oct 2004 02:23:22 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 4 Oct 2004 10:23:20 +0100
Message-ID: <416068F7.1050503@isode.com>
Date: Sun, 03 Oct 2004 22:02:47 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IMAP Extensions WG 
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
References: <4140B37E.5000401@isode.com> 	 <200409130633.i8D6XMmj059087@lab.smi.sendmail.com> <416067E6.7010902@isode.com>
In-Reply-To: <416067E6.7010902@isode.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

 >P.S. I've just submitted revision 10 of LISTEXT. It addresses the 
issues mentioned in this message +
 > updates ABNF for the MATCHPARENT option + changes LISTEXT to only 
return \PlaceHolder/\HasSubmailboxes
 >only when MATCHPARENT is specified. It also includes some editorial 
suggestions from Arnt.

I've also fixed few minor bugs in examples (in one place \SubMailboxes 
was not accompanied by \Subscribed)




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i949NMh2087243; Mon, 4 Oct 2004 02:23:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i949NMul087241; Mon, 4 Oct 2004 02:23:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i949NJRS087177 for ; Mon, 4 Oct 2004 02:23:21 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 4 Oct 2004 10:23:15 +0100
Message-ID: <416067E6.7010902@isode.com>
Date: Sun, 03 Oct 2004 21:58:14 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IMAP Extensions WG 
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
References: <4140B37E.5000401@isode.com> 	 <200409130633.i8D6XMmj059087@lab.smi.sendmail.com>
In-Reply-To: <200409130633.i8D6XMmj059087@lab.smi.sendmail.com>
Content-Type: multipart/alternative; boundary="------------040709030105080803000603"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--------------040709030105080803000603
Content-type: text/plain; charset="us-ascii"

Arnt:
 >Might want to add a note to section 3.1 then, saying explicitly that 
if multiple wildcards match a given mailbox,
 >it is to be returned only once.
I've clarified this at the beginning of section 3.

Philip:

>- if an option is repeated in an option list, is the server required to,
>  permitted to, or forbidden from rejecting the command with a BAD
>  response?
>
IMHO, I think the server should allow this, but the client SHOULD NOT do 
this. I've clarified this.

>- The LIST command requires special processing when the pattern argument
>  is the empty string.  How does LISTEXT interact with that?  Is the
>  special processing skipped when SUBSCRIBED is used?  Should the server
>  be permitted to ignore the MATCHPARENT and/or CHILDREN options for the
>  response generated by the empty pattern?  Is there any special result
>  or change if the empty pattern is one of multiple patterns in a LIST
>  command?
>
I've added a section saying that "" mailbox name doesn't have any 
special meaning when used in an extended LIST command.

>- Is a folder that doesn't exist but that meets the selection criteria
>  sufficient to trigger a \HasSubmailboxes or \Placeholder responses?
>  If so, then \HasSubmailboxes and \Placeholder do _not_ imply
>  \HasChildren.  E.g., consider the following:
>	a1 LIST "" ("foo" "foo/*")
>	* LIST () "/" foo
>	a1 OK done
>	a2 LIST (SUBSCRIBED) "" "foo/*"
>	* LIST (\Subscribed \NonExistent) "/" foo/bar
>	a2 OK done
>	a3 LIST (SUBSCRIBED MATCHPARENT) "" foo RETURN (CHILDREN)
>	* LIST (\Subscribed \Placeholder \HasNoChildren) "/" foo
>	a3 OK done
>  
>
I've added this as a new example. I've also removed any mentioning of 
\HasSubmailboxes/\PlaceHolder implying \HasChildren.

Alexey

P.S. I've just submitted revision 10 of LISTEXT. It addresses the issues 
mentioned in this message + updates ABNF for the MATCHPARENT option + 
changes LISTEXT to only return \PlaceHolder/\HasSubmailboxes only when 
MATCHPARENT is specified. It also includes some editorial suggestions 
from Arnt.



--------------040709030105080803000603
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit




  
  












Arnt:

>Might want to add a note to section 3.1 then, saying explicitly
that
if multiple wildcards match a given mailbox,

>it is to be returned only
once.


I've clarified this at the beginning of section 3.



Philip:



  
- if an option is repeated in an option list, is the server required to,
  permitted to, or forbidden from rejecting the command with a BAD
  response?



IMHO, I think the server should allow this, but the client SHOULD NOT
do this. I've clarified this.



  
- The LIST command requires special processing when the pattern argument
  is the empty string.  How does LISTEXT interact with that?  Is the
  special processing skipped when SUBSCRIBED is used?  Should the server
  be permitted to ignore the MATCHPARENT and/or CHILDREN options for the
  response generated by the empty pattern?  Is there any special result
  or change if the empty pattern is one of multiple patterns in a LIST
  command?



I've added a section saying that "" mailbox name doesn't have any
special meaning when used in an extended LIST command.




  
- Is a folder that doesn't exist but that meets the selection criteria
  sufficient to trigger a \HasSubmailboxes or \Placeholder responses?
  If so, then \HasSubmailboxes and \Placeholder do _not_ imply
  \HasChildren.  E.g., consider the following:
	a1 LIST "" ("foo" "foo/*")
	* LIST () "/" foo
	a1 OK done
	a2 LIST (SUBSCRIBED) "" "foo/*"
	* LIST (\Subscribed \NonExistent) "/" foo/bar
	a2 OK done
	a3 LIST (SUBSCRIBED MATCHPARENT) "" foo RETURN (CHILDREN)
	* LIST (\Subscribed \Placeholder \HasNoChildren) "/" foo
	a3 OK done
  



I've added this as a new example. I've also removed any mentioning of
\HasSubmailboxes/\PlaceHolder implying
\HasChildren.



Alexey



P.S. I've just submitted revision 10 of LISTEXT. It addresses the
issues mentioned in this message + updates ABNF for the MATCHPARENT
option + changes LISTEXT to only return \PlaceHolder/\HasSubmailboxes
only when MATCHPARENT is specified. It also includes some editorial
suggestions from Arnt.








--------------040709030105080803000603--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i949NLd9087230; Mon, 4 Oct 2004 02:23:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i949NLLt087229; Mon, 4 Oct 2004 02:23:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i949NJRR087177 for ; Mon, 4 Oct 2004 02:23:20 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 4 Oct 2004 10:23:11 +0100
Message-ID: <416049CF.8060905@isode.com>
Date: Sun, 03 Oct 2004 19:49:51 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IMAP Extensions WG 
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
References: <4140B37E.5000401@isode.com>  <200409130633.i8D6XMmj059087@lab.smi.sendmail.com> 	<4151B3B4.9090105@isode.com> <200409230341.i8N3f9gV048309@lab.smi.sendmail.com>
In-Reply-To: <200409230341.i8N3f9gV048309@lab.smi.sendmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

>What does a response with \Placeholder or \HasSubmailboxes mean when
>MATCHPARENT is used with REMOTE but without SUBSCRIBED?  I see three
>possible answers:
>a) it means the mailbox has at least one submailbox that is remote
>b) is means the mailbox has at least one submailbox, local or remote
>c) (b), but that's the same as \HasChildren, so MATCHPARENT shouldn't be
>   allowed with just REMOTE: it should require SUBSCRIBED or some other
>   option that affects the selection criteria.
>
>IMO, the current text says (b).  Switching it to (a) would require a
>major rethink of the concept of "selected", or would effectively declare
>MATCHPARENT as having ad hoc interaction with each selection option.  I
>would just as soon go with (c) and can help with text to that effect.

I don't think interpretation c) is very useful. This seems to make
existing complex situation even more complex. Currently the draft says 
that b) is the case. If people think that a) is more appropriate, than 
the WG needs to reconsider what REMOTE selection option means.

>Depending on how that question is settled, I may have an argument that
>in response to , responses with
>the \Placeholder flag also need the \Subscribed flag to avoid
>ambiguity.

As per off list discussion with Philip, I've changed the document to say 
that \PlaceHolder/\HasSubMailboxes is only allowed when MATCHPARENT is 
specified. In particular, this means that they are not allowed in LIST 
responses not caused by the latest LIST command.


Philip's suggestion is that the server will send
"\Placeholder \Subscribed" in response to
.
This will mean "the mailbox is not really sibscribed, but the 
\Placeholder flag was caused by SUBSCRIBED selection option.

IMHO, this seems to be overly complex. I think my change detailed above 
would suffice, however if WG members feel otherwise, I would like to 
hear their comments.

Alexey




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92IwtMZ048629; Sat, 2 Oct 2004 11:58:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i92Iwti0048628; Sat, 2 Oct 2004 11:58:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from cz.mit.edu (STRATTON-FOUR-SIXTY-ONE.MIT.EDU [18.187.6.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92Iwssm048615; Sat, 2 Oct 2004 11:58:54 -0700 (PDT) (envelope-from hartmans@mit.edu)
Received: by cz.mit.edu (Postfix, from userid 8042) id C22AAE004F; Sat,  2 Oct 2004 14:58:59 -0400 (EDT)
To: Lyndon Nerenberg 
Cc: ietf-sasl@imc.org, ietf-imapext@imc.org, ietf@ietf.org
Subject: Re: CRAMing for last call
References: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net>
From: Sam Hartman 
Date: Sat, 02 Oct 2004 14:58:59 -0400
In-Reply-To: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> (Lyndon Nerenberg's message of "Fri, 01 Oct 2004 22:02:54 -0700")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

>>>>> "Lyndon" == Lyndon Nerenberg  writes:

    Lyndon> Finally, we need to address the issue of the MD5 "break."
    Lyndon> I have held off from commenting on this issue until the
    Lyndon> community has seen explicit evidence of the attack, and
    Lyndon> the implications of it. At this point, I don't know if the
    Lyndon> document deserves a writeup on the attack. Theory abounds,
    Lyndon> but I haven't yet seen a practical attack that works in
    Lyndon> the general case. We should at the least make mention of
    Lyndon> what has been discussed, and point to the literature, but
    Lyndon> I don't think the document deserves to discuss all the
    Lyndon> possible attacks. This doesn't mean to discourage anyone
    Lyndon> from contributing text to the Security Considerations
    Lyndon> section (please do).

The security area seems to believe that hmac-md5 is still OK, at least
for now.  Especially since cram-md5 does not require much structure
for the challenge, we should discuss the issue in the security
considerations section.

Will you need agenda time at the next meeting?  If so, can you give an
estimate of how much and what we want to cover?

Thanks,

--Sam



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9252wBJ083995; Fri, 1 Oct 2004 22:02:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9252wLI083993; Fri, 1 Oct 2004 22:02:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9252vOB083966; Fri, 1 Oct 2004 22:02:57 -0700 (PDT) (envelope-from lyndon@orthanc.ca)
Received: from d216-232-212-223.bchsia.telus.net (d216-232-212-223.bchsia.telus.net [216.232.212.223]) (authenticated bits=0) by orthanc.ca (8.13.1.Alpha0/8.13.1.Alpha0) with ESMTP id i9252sWc034166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2004 23:02:56 -0600 (MDT)
Date: Fri, 01 Oct 2004 22:02:54 -0700
From: Lyndon Nerenberg 
To: ietf-sasl@imc.org, ietf-imapext@imc.org, ietf@ietf.org
Subject: CRAMing for last call
Message-ID: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham  version=2.63
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Now that 2222bis is close to reality, I would like to push the final 
version of CRAM out as well. The two documents should be able to go 
through together, (I hope) making life easier for the RFC editor.

I have some non-substantive editorial changes that will make the 
document a bit easier to read, but these are not show stoppers. I think 
all of the last round of comments are addressed in the current draft. 
If not, I would like to hear from people, soon.

I would also like to solicit a few additional examples from anyone who 
has implemented CRAM in other than IMAP.

Finally, we need to address the issue of the MD5 "break." I have held 
off from commenting on this issue until the community has seen explicit 
evidence of the attack, and the implications of it. At this point, I 
don't know if the document deserves a writeup on the attack. Theory 
abounds, but I haven't yet seen a practical attack that works in the 
general case. We should at the least make mention of what has been 
discussed, and point to the literature, but I don't think the document 
deserves to discuss all the possible attacks. This doesn't mean to 
discourage anyone from contributing text to the Security Considerations 
section (please do).

The IMAP-EXT list has had recent discussion that points out the 
ambiguity of searching for the space (SP) separator (between the user 
id and the digest) as being the rightmost SP, so I will strengthen that 
text. Any other comments should come forth soon as I would like to run 
out the final draft at the end of next week (Oct. 8) if I can.

Cheers,

--lyndon (editor)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91Fd2Nk036671; Fri, 1 Oct 2004 08:39:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91Fd20m036670; Fri, 1 Oct 2004 08:39:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91Fd1PE036663 for ; Fri, 1 Oct 2004 08:39:01 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Message-Id: 
Date: Fri, 1 Oct 2004 17:39:12 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: IMAP,ACL,NAMESPACE,Mozilla,Outlook.
References: 
In-Reply-To: 
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i91Fd1PE036665
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

What happens if you specify the namespaces within the folder tree?

Richard Bang writes:
> O/OE doesn't understand namespaces so I cant move the shared folders 
> out of the folder tree.
>
> Currently:
> "/" inbox
> "/" drafts
> "/" shared/fred/inbox
> "/" "sent items"

... ie. you specify that / is personal and /shared/ is shared.

> How can I do these things? When I read the spec it strongly implies 
> (to me anyway) that personal, public and shared folders must all be 
> in separate namespaces. Am I misreading it?

AFAICR, the spec does not say nonoverlapping.

RFC 2342 example 5.3 seems to be rather similar to your case.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FcVsl036627; Fri, 1 Oct 2004 08:38:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91FcV7p036626; Fri, 1 Oct 2004 08:38:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from mx0.ftgate.com (mx0.ftgate.com [195.224.16.225]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FcT7h036620 for ; Fri, 1 Oct 2004 08:38:30 -0700 (PDT) (envelope-from richard@ftgate.com)
Message-Id: 
Received: from local-ip[x.x.x.x] by mx0.ftgate.com.; Fri, 01 Oct 2004 16:38:23 +0100
From: "Richard Bang" 
To: 
Subject: RE: IMAP,ACL,NAMESPACE,Mozilla,Outlook.
Date: Fri, 1 Oct 2004 16:38:46 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcSnsm2399d+x+kyQ8WVf5x4PXqY5wAF46hQAABjiyA=
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

 
Hi,

I just realised my previous post may imply that I believe there is something
wrong with the protocols themselves. This is not the case and implementing
any of the protocols per se does not "break" the client.

The problem is, as Mark has often commented, that a broken client usually
results in the server being blamed. As in Mozilla if you don't have ACL.

After implementing ACL I was able with my test platfrom to correct
manipluate the shares on all the folders using a non NAMESPACE system.

However, this results in Mozilla showing all the share status but not
letting you actually share anything. To get Mozilla to share things you need
to move the shared items into a separate namespace (a namespace of shared/
doesn't cut it unfortunatly). 

I would love to be able to just declare that the fault is the client, but
this is usually futile.

I guess the soution would be for a client to see ACL and assume that it can
(at least try) to share anything for which myrights includes a (SETACL) as
this is what it means.

Regard 
Richard.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FN5WZ035557; Fri, 1 Oct 2004 08:23:05 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91FN5BW035556; Fri, 1 Oct 2004 08:23:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from mx0.ftgate.com (mx0.ftgate.com [195.224.16.225]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FN2SE035546 for ; Fri, 1 Oct 2004 08:23:03 -0700 (PDT) (envelope-from richard@ftgate.com)
Message-Id: 
Received: from local-ip[x.x.x.x] by mx0.ftgate.com.; Fri, 01 Oct 2004 16:22:47 +0100
From: "Richard Bang" 
To: 
Subject: RE: IMAP,ACL,NAMESPACE,Mozilla,Outlook.
Date: Fri, 1 Oct 2004 16:22:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcSnsm2399d+x+kyQ8WVf5x4PXqY5wAF46hQ
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Hi,
> 
> Why does this break Outlook/OE?
> 
O/OE doesn't understand namespaces so I cant move the shared folders out of
the folder tree.

Currently:
"/" inbox
"/" drafts
"/" shared/fred/inbox
"/" "sent items"

But If I do:
"/" inbox
"/" drafts
"#" fred/inbox
"/" "sent items"

O/OE wont see them. Is there another way to do this that doesn't break O/OE?

Also. At any point I can share any of my folders, and there doesnt seem to
be a way to identify that the folders can be shared. So I want to be able to
have:

"/" inbox    <-mine
"/" drafts   <-mine
"/" shared/fred/inbox <- freds but I have read access
"/" "sent items" <- mine
"/" "important" <- mine but fred has read/write access

How can I do these things? When I read the spec it strongly implies (to me
anyway) that personal, public and shared folders must all be in separate
namespaces. Am I misreading it?

I guess this is only an issue because one of my beta testers declared that
shared folders was broken because Mozilla said "The server does not support
shared folders" (meaning ACL was not implemented but it doesn't say that
does it :( ).

Your help is greatly appreciated.

Regards

Richard.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91CQ642025023; Fri, 1 Oct 2004 05:26:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91CQ6Wq025022; Fri, 1 Oct 2004 05:26:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91CQ1mE025011 for ; Fri, 1 Oct 2004 05:26:05 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Message-Id: 
Date: Fri, 1 Oct 2004 14:26:11 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: IMAP,ACL,NAMESPACE,Mozilla,Outlook.
References: 
In-Reply-To: 
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Richard Bang writes:
> I have managed to get ACL and NAMESPACE to work with Mozilla, but this 
> forces me to use name spaces for shared items and this instantly 
> breaks Outlook (& Express).

Why does this break Outlook/OE?

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PK1DxR016714; Mon, 25 Oct 2004 13:01:13 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PK1DY8016713; Mon, 25 Oct 2004 13:01:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PK1CTl016707 for ; Mon, 25 Oct 2004 13:01:13 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28952; Mon, 25 Oct 2004 16:01:14 -0400 (EDT)
Message-Id: <200410252001.QAA28952@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: ietf-imapext@imc.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-imapext-annotate-11.txt
Date: Mon, 25 Oct 2004 16:01:14 -0400
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-11.txt
	Pages		: 39
	Date		: 2004-10-25
	
The ANNOTATE extension to the Internet Message Access Protocol
   permits clients and servers to maintain "metadata" for messages
   stored in an IMAP mailbox.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-11.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-annotate-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-annotate-11.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-10-25162034.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-annotate-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-annotate-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-10-25162034.I-D@ietf.org>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O08Yp8011277; Sat, 23 Oct 2004 17:08:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9O08Yh4011276; Sat, 23 Oct 2004 17:08:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9O08XAE011239 for ; Sat, 23 Oct 2004 17:08:34 -0700 (PDT) (envelope-from leiba@watson.ibm.com)
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i9O08V933160 for ; Sat, 23 Oct 2004 20:08:31 -0400
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id i9NML3I35514 for ; Sat, 23 Oct 2004 18:21:03 -0400
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id i9NML1i08976 for ; Sat, 23 Oct 2004 18:21:01 -0400
Received: from 9.2.249.2:6602 ([9.2.249.2]) by mars.watson.ibm.com ID IMFd1098570061.1; Sat, 23 Oct 2004 18:21:01 -0400
Date: Sat, 23 Oct 2004 18:21:00 -0400
From: Barry Leiba 
To: IMAP extensions Mailing List 
Subject: Re: WG meeting at IETF 61
Message-ID: 
In-Reply-To: <417A8E4C.2060706@isode.com>
References:  <417A8E4C.2060706@isode.com>
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

>> Great: the IMAPext meeting is scheduled for Tuesday afternoon,
>> conflicting with the FTC/NIST Email Signing Summit.  Is there any
>> chance of getting this moved to Monday?
> 
> An alternative (I prefer it slightly over the above), is to have it
> on Wednesday, so that IMAPEXT and Lemonade are on the same date.

The FTC/NIST meeting is all day Tuesday and Wednesday.  They planned it
to coincide with the IETF, but had to avoid Thursday because it's a
federal holiday (Veterans' Day).  A good many e-mail people will be
there, or will want to, so it'd be good to have all the e-mail-related
IETF things on Monday or Thursday.

Barry

--
Barry Leiba, Pervasive Computing Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NK8CKJ056494; Sat, 23 Oct 2004 13:08:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9NK8Cwd056492; Sat, 23 Oct 2004 13:08:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9NK8B6s056434 for ; Sat, 23 Oct 2004 13:08:11 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [213.116.52.185] (1Cust185.tnt102.lnd4.gbr.da.uu.net [213.116.52.185])  by rufus.isode.com via TCP (internal) with ESMTPA; Sat, 23 Oct 2004 21:07:56 +0100
Message-ID: <417A8E4C.2060706@isode.com>
Date: Sat, 23 Oct 2004 18:01:00 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Barry Leiba 
CC: IMAP extensions Mailing List 
Subject: Re: WG meeting at IETF 61
References: 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Barry Leiba wrote:

>Great: the IMAPext meeting is scheduled for Tuesday afternoon,
>conflicting with the FTC/NIST Email Signing Summit.  Is there any
>chance of getting this moved to Monday?
>  
>
That would be fine with me.

An alternative (I prefer it slightly over the above), is to have it on Wednesday, so that IMAPEXT and Lemonade are on the same date. Barry, does this work for you?





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MNL9oA037697; Fri, 22 Oct 2004 16:21:09 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MNL9TI037696; Fri, 22 Oct 2004 16:21:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.20.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MNL8rZ037652 for ; Fri, 22 Oct 2004 16:21:08 -0700 (PDT) (envelope-from leiba@watson.ibm.com)
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw3.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i9MNL5A63230 for ; Fri, 22 Oct 2004 19:21:05 -0400
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id i9MNL5I44576 for ; Fri, 22 Oct 2004 19:21:05 -0400
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id i9MNL4i44574 for ; Fri, 22 Oct 2004 19:21:04 -0400
Received: from 9.2.249.2:5937 ([9.2.249.2]) by mars.watson.ibm.com ID IMFd1098487264.1; Fri, 22 Oct 2004 19:21:04 -0400
Date: Fri, 22 Oct 2004 19:21:03 -0400
From: Barry Leiba 
To: IMAP extensions Mailing List 
Subject: WG meeting at IETF 61
Message-ID: 
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Great: the IMAPext meeting is scheduled for Tuesday afternoon,
conflicting with the FTC/NIST Email Signing Summit.  Is there any
chance of getting this moved to Monday?

Barry

--
Barry Leiba, Pervasive Computing Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JHfVmO008086; Tue, 19 Oct 2004 10:41:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JHfVsY008085; Tue, 19 Oct 2004 10:41:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JHfUB2008071 for ; Tue, 19 Oct 2004 10:41:30 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9JHfXwf023565; Tue, 19 Oct 2004 10:41:33 -0700
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9JHfWwA001240 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Oct 2004 10:41:33 -0700
Date: Tue, 19 Oct 2004 10:41:34 -0700 (Pacific Daylight Time)
From: Mark Crispin 
To: Alexey Melnikov 
cc: ietf-imapext@imc.org
Subject: Re: draft-melnikov-imap-search-res
In-Reply-To: <41753F59.30508@isode.com>
Message-ID: 
References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com>  <41753F59.30508@isode.com>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

On Tue, 19 Oct 2004, Alexey Melnikov wrote:
> One thing I wanted to do but hasn't: add a SEARCH option to "suppress" 
> untagged SEARCH responses. Something like
> a SEARCH 1:10,20:30,47 (NORESULT)

Parentheses already mean something in SEARCH.

Fortunately, there is a precedent for initial atoms, such as
 	tag SEARCH SILENT 1:10,20:30,47
etc.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JHfOpJ008053; Tue, 19 Oct 2004 10:41:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JHfOBq008052; Tue, 19 Oct 2004 10:41:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JHfMqb008022 for ; Tue, 19 Oct 2004 10:41:23 -0700 (PDT) (envelope-from tss@iki.fi)
Received: by danu.procontrol.fi (Postfix, from userid 106) id B280D1C386DA; Tue, 19 Oct 2004 20:41:14 +0300 (EEST)
Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 211D81C3531B; Tue, 19 Oct 2004 20:41:10 +0300 (EEST)
In-Reply-To: <417542E6.50902@isode.com>
References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com>  <417542E6.50902@isode.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-8--358615198"
Message-Id: <0F855184-21F6-11D9-8450-000393CC2E90@iki.fi>
Content-Transfer-Encoding: 7bit
Cc: IMAP Extensions WG 
From: Timo Sirainen 
Subject: Re: draft-melnikov-imap-search-res
Date: Tue, 19 Oct 2004 20:41:09 +0300
To: Alexey Melnikov 
X-Pgp-Agent: GPGMail 1.0.2
X-Mailer: Apple Mail (2.619)
X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on danu.procontrol.fi
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham  version=3.0.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--Apple-Mail-8--358615198
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 19.10.2004, at 19:37, Alexey Melnikov wrote:

>> If client sends SEARCH + FETCH << pipelined, nothing prevents server 
>> from giving all the FETCH replies before the SEARCH reply, right?
>
> The server shouldn't reorder the commands if there are any data 
> dependencies. "<<" is a very explicit indication that there are.

Reordering here wouldn't affect results, only the order in which the 
results are sent to client.

> Is there any particular reason why you think that a server should 
> return FETCH responses before the SEARCH response?

Mostly just performance benefits. Server could process the two commands 
simultaneously in one loop.

But you also mentioned (NORESULT) which would make this possible in any 
case.

--Apple-Mail-8--358615198
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBdVG1yUhSUUBViskRAieIAJ4nFMDIxgLOytaTeFe3P/Ur3mus6gCgg9Bi
CQrzAhdLcNhtLptSrX7Amuc=
=CgM6
-----END PGP SIGNATURE-----

--Apple-Mail-8--358615198--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGcALJ098420; Tue, 19 Oct 2004 09:38:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JGcAnw098419; Tue, 19 Oct 2004 09:38:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGc99H098411 for ; Tue, 19 Oct 2004 09:38:09 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 19 Oct 2004 17:37:59 +0100
Message-ID: <417542E6.50902@isode.com>
Date: Tue, 19 Oct 2004 17:37:58 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Timo Sirainen 
CC: IMAP Extensions WG 
Subject: Re: draft-melnikov-imap-search-res
References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com> 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Timo Sirainen wrote:

> On 19.10.2004, at 14:25, Alexey Melnikov wrote:
>
>> My guess is (at least from the times I was an IMAP client developer) 
>> that the result of a SEARCH command is usually used as input to a 
>> subsequent FETCH/COPY/STORE command. With the base IMAP protocol one 
>> has to wait for the result of SEARCH to feed it into the subsequent 
>> command.
>
> If client sends SEARCH + FETCH << pipelined, nothing prevents server 
> from giving all the FETCH replies before the SEARCH reply, right?

The server shouldn't reorder the commands if there are any data 
dependencies. "<<" is a very explicit indication that there are.

Is there any particular reason why you think that a server should return 
FETCH responses before the SEARCH response?

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGQw6a096031; Tue, 19 Oct 2004 09:26:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JGQwhK096030; Tue, 19 Oct 2004 09:26:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGQva5096005 for ; Tue, 19 Oct 2004 09:26:57 -0700 (PDT) (envelope-from tss@iki.fi)
Received: by danu.procontrol.fi (Postfix, from userid 106) id 961141C386DA; Tue, 19 Oct 2004 19:26:47 +0300 (EEST)
Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 1B7FF1C3531B; Tue, 19 Oct 2004 19:26:43 +0300 (EEST)
In-Reply-To: <4174F9C2.40304@isode.com>
References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-7--363081270"
Message-Id: 
Content-Transfer-Encoding: 7bit
Cc: IMAP Extensions WG 
From: Timo Sirainen 
Subject: Re: draft-melnikov-imap-search-res
Date: Tue, 19 Oct 2004 19:26:42 +0300
To: Alexey Melnikov 
X-Pgp-Agent: GPGMail 1.0.2
X-Mailer: Apple Mail (2.619)
X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on danu.procontrol.fi
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham  version=3.0.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--Apple-Mail-7--363081270
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 19.10.2004, at 14:25, Alexey Melnikov wrote:

> My guess is (at least from the times I was an IMAP client developer) 
> that the result of a SEARCH command is usually used as input to a 
> subsequent FETCH/COPY/STORE command. With the base IMAP protocol one 
> has to wait for the result of SEARCH to feed it into the subsequent 
> command.

If client sends SEARCH + FETCH << pipelined, nothing prevents server 
from giving all the FETCH replies before the SEARCH reply, right?

--Apple-Mail-7--363081270
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBdUBDyUhSUUBViskRAnAuAKCQCDZQeEWCW3Ka5/r7TOJojHho6QCfb4D0
LAfSw32K+KCyUPKqDTPYBcA=
=y3vw
-----END PGP SIGNATURE-----

--Apple-Mail-7--363081270--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGMsWC095438; Tue, 19 Oct 2004 09:22:54 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JGMrNR095437; Tue, 19 Oct 2004 09:22:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGMr2u095430 for ; Tue, 19 Oct 2004 09:22:53 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 19 Oct 2004 17:22:50 +0100
Message-ID: <41753F59.30508@isode.com>
Date: Tue, 19 Oct 2004 17:22:49 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Mark Crispin 
CC: ietf-imapext@imc.org
Subject: Re: draft-melnikov-imap-search-res
References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com> 
In-Reply-To: 
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Mark Crispin wrote:

> The problem is when the search result is long and sparse, meaning that 
> it can not be collapsed easily with range syntax.  With large enough 
> mailboxes, the result is a command which is larger than the maximum 
> command length, and thus the command needs to be broken up into 
> multiple commands (which in turn creates its own problems).

One thing I wanted to do but hasn't: add a SEARCH option to "suppress" 
untagged SEARCH responses. Something like

a SEARCH 1:10,20:30,47 (NORESULT)

I am not sure whether this should be a part of the SEARCHRES extension, 
or a more generic extension for SEARCH options. The latter might include 
other options like COUNT (return how many were found), MIN (minimal 
found message number/UID) & MAX.

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGIYtC094784; Tue, 19 Oct 2004 09:18:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JGIYKs094783; Tue, 19 Oct 2004 09:18:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JGIXCk094777 for ; Tue, 19 Oct 2004 09:18:33 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 19 Oct 2004 17:18:32 +0100
Message-ID: <41753E57.7020902@isode.com>
Date: Tue, 19 Oct 2004 17:18:31 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Mark Crispin 
CC: ietf-imapext@imc.org
Subject: Re: draft-melnikov-imap-search-res
References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com>  <4175371A.7030707@isode.com> 
In-Reply-To: 
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Mark Crispin wrote:

> On Tue, 19 Oct 2004, Alexey Melnikov wrote:
>
>> One can also OR it, e.g.
>> a SEARCH <<,90:120
>
>
> Ugh!  This is something that few implementors will get right!
>
> I don't think that we should allow $ in sequences; $ should be a 
> complete sequence by itself.  If the client really wants an OR, it can do
>     tag SEARCH OR $ 90:120

That is fine with me.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JG5fbe093037; Tue, 19 Oct 2004 09:05:41 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JG5fXk093036; Tue, 19 Oct 2004 09:05:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JG5f98093030 for ; Tue, 19 Oct 2004 09:05:41 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU)
Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout5.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9JG5eWx000913; Tue, 19 Oct 2004 09:05:41 -0700
Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9JG5egK022227; Tue, 19 Oct 2004 09:05:40 -0700
Date: Tue, 19 Oct 2004 09:05:40 -0700 (PDT)
From: Mark Crispin 
To: Alexey Melnikov 
cc: Arnt Gulbrandsen , ietf-imapext@imc.org
Subject: Re: draft-melnikov-imap-search-res
In-Reply-To: <4175371A.7030707@isode.com>
Message-ID: 
References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com>  <4175371A.7030707@isode.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

On Tue, 19 Oct 2004, Alexey Melnikov wrote:
> One can also OR it, e.g.
> a SEARCH <<,90:120

Ugh!  This is something that few implementors will get right!

I don't think that we should allow $ in sequences; $ should be a complete 
sequence by itself.  If the client really wants an OR, it can do
 	tag SEARCH OR $ 90:120

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JFljE5089807; Tue, 19 Oct 2004 08:47:45 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JFljwT089806; Tue, 19 Oct 2004 08:47:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JFli1K089792 for ; Tue, 19 Oct 2004 08:47:44 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 19 Oct 2004 16:47:39 +0100
Message-ID: <4175371A.7030707@isode.com>
Date: Tue, 19 Oct 2004 16:47:38 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Mark Crispin 
CC: Arnt Gulbrandsen , ietf-imapext@imc.org
Subject: Re: draft-melnikov-imap-search-res
References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com> 
In-Reply-To: 
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Mark Crispin wrote:

> The problem is when the search result is long and sparse, meaning that 
> it can not be collapsed easily with range syntax.  With large enough 
> mailboxes, the result is a command which is larger than the maximum 
> command length, and thus the command needs to be broken up into 
> multiple commands (which in turn creates its own problems).
>
> I don't particularly like "<<", since it implies some sort of UNIX 
> like piping (and implications can cause a lot of problems!), and 
> suggest something like "$" or even an atom (such as "LASTSEARCH") instead.

I will change it to "$", thanks.

> One possibly messy consequence is if this is allowed in a SEARCH 
> command; this would AND previous search results with addition criteria.

One can also OR it, e.g.

a SEARCH <<,90:120

>   I can see why people may want to do that.  However, with complex 
> SEARCHes, especially using IMAP4-style nesting, this can get extremely 
> complicated.

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JFgG0Y089017; Tue, 19 Oct 2004 08:42:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JFgGiY089016; Tue, 19 Oct 2004 08:42:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JFgB0N088992 for ; Tue, 19 Oct 2004 08:42:11 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU)
Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout6.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9JFg96I028896; Tue, 19 Oct 2004 08:42:09 -0700
Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9JFg99j020978; Tue, 19 Oct 2004 08:42:09 -0700
Date: Tue, 19 Oct 2004 08:42:09 -0700 (PDT)
From: Mark Crispin 
To: Alexey Melnikov 
cc: Arnt Gulbrandsen , ietf-imapext@imc.org
Subject: Re: draft-melnikov-imap-search-res
In-Reply-To: <4174F9C2.40304@isode.com>
Message-ID: 
References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com> <4174F9C2.40304@isode.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

The problem is when the search result is long and sparse, meaning that it 
can not be collapsed easily with range syntax.  With large enough 
mailboxes, the result is a command which is larger than the maximum 
command length, and thus the command needs to be broken up into multiple 
commands (which in turn creates its own problems).

I don't particularly like "<<", since it implies some sort of UNIX like 
piping (and implications can cause a lot of problems!), and suggest 
something like "$" or even an atom (such as "LASTSEARCH") instead.

One possibly messy consequence is if this is allowed in a SEARCH command; 
this would AND previous search results with addition criteria.  I can see 
why people may want to do that.  However, with complex SEARCHes, 
especially using IMAP4-style nesting, this can get extremely complicated.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JBQ1n6049028; Tue, 19 Oct 2004 04:26:01 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JBQ1IR049027; Tue, 19 Oct 2004 04:26:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JBQ0vG049021 for ; Tue, 19 Oct 2004 04:26:00 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Tue, 19 Oct 2004 12:25:56 +0100
Message-ID: <4174F9C2.40304@isode.com>
Date: Tue, 19 Oct 2004 12:25:54 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen 
CC: ietf-imapext@imc.org
Subject: Re: draft-melnikov-imap-search-res
References: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com>
In-Reply-To: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Arnt Gulbrandsen wrote:

> Hi,
>
> what motivates this extension?

My guess is (at least from the times I was an IMAP client developer) 
that the result of a SEARCH command is usually used as input to a 
subsequent FETCH/COPY/STORE command. With the base IMAP protocol one has 
to wait for the result of SEARCH to feed it into the subsequent command.

1). So the two commands can't be pipelined.
2). Some bandwidth is wasted (SEARCH untagged result and FETCH message 
sequence). Granted, this might not be much, but the same mechanism that 
addresses 1) also addresses 2). to some extend.

I've meant to write this document a long time ago, then I saw the 
following in the Lemonade Jabber log for the latest interim meeting:

 Mark says major problems are: no way to have client ask server 
to redo last search, sort, etc. and show only what has changed; also no 
way to get a sequence (such as the result of a search) and use it for 
something without sending the sequence back to the server.

The extension addresses the latter.

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JB1Nnn038208; Tue, 19 Oct 2004 04:01:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JB1NDG038206; Tue, 19 Oct 2004 04:01:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9JB1HYs038153 for ; Tue, 19 Oct 2004 04:01:22 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Received: by kalyani.oryx.com (Postfix, from userid 1005) id 1357B1BDE7A; Tue, 19 Oct 2004 13:01:18 +0200 (CEST)
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by kalyani.oryx.com (Postfix) with SMTP id 4964E1BDE7B; Tue, 19 Oct 2004 13:01:16 +0200 (CEST)
Message-Id: <7yoPjUFDAsyLma6mHUEDow.md5@libertango.oryx.com>
Date: Tue, 19 Oct 2004 13:02:42 +0200
From: Arnt Gulbrandsen 
To: Alexey.Melnikov@isode.com
Subject: draft-melnikov-imap-search-res
Cc: ietf-imapext@imc.org
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Hi,

what motivates this extension? Why would I (as client author) want to 
implement it? From where I sit, the client implementation looks like 
this, in pseudocode:

if ( extension present )
     do something
else
     do pretty much the same thing, only very slightly slower

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9II73kT074381; Mon, 18 Oct 2004 11:07:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9II732A074380; Mon, 18 Oct 2004 11:07:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9II73Ds074372 for ; Mon, 18 Oct 2004 11:07:03 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU)
Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.37.170]) by mxout1.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9II76hg011993 for ; Mon, 18 Oct 2004 11:07:06 -0700
Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.13.1+UW04.08/8.13.1+UW04.08) with ESMTP id i9II76mv007594 for ; Mon, 18 Oct 2004 11:07:06 -0700
Date: Mon, 18 Oct 2004 11:07:06 -0700 (PDT)
From: Mark Crispin 
To: IMAP Extensions WG 
Subject: about LISTEXT
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

I've been largely staying out of the discussions, but I'm getting worried 
about the problem of over-engineering.

Can we back up a bit and get a coherant statement as to the problems in 
the current LIST command that clients want solved?

As a start, I offer the following:

1) Too many LIST commands; LIST and LSUB was bad enough, and RLIST and
    RLSUB clearly identified a problem.  Need a unified command.

2) Need a way for the client to specify that it really needs something
    like children which may be a problem for the server to do.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGllQt058269; Mon, 18 Oct 2004 09:47:47 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IGll3Z058268; Mon, 18 Oct 2004 09:47:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9IGlksB058259 for ; Mon, 18 Oct 2004 09:47:47 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 2D51C1A6C5; Mon, 18 Oct 2004 18:47:49 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 92C661A6BB; Mon, 18 Oct 2004 18:47:44 +0200 (CEST)
Message-Id: 
Date: Mon, 18 Oct 2004 18:47:38 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
Cc: Alexey Melnikov , Timo Sirainen 
References:  <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com>  <416EA92C.3040706@isode.com>  <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com> <26A8C406-211C-11D9-A914-000393CC2E90@iki.fi> <4173EB50.4060703@isode.com>
In-Reply-To: <4173EB50.4060703@isode.com>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Alexey Melnikov writes:
> Timo Sirainen wrote:
>> What did you think about Dave Cridland's new syntax idea? You didn't 
>> reply to that message 
>> (<20041006093514.3678.27139.polymer@peirce.gestalt.entity.net>).
>>
>> I think using that would make MATCHPARENT much more simpler:
>>  - allows dropping \PlaceHolder and \HasSubmailboxes
>
> The proposal avoids introduction of \PlaceHolder/\HasSubmailboxes 
> (which is a good thing), but the complexity of implementing 
> MATCHPARENT in servers is still present.

Part of the complexity is still present, not all.

IMO, that proposal strikes a good balance. It makes MATCHPARENT powerful 
enough to completely replace LSUB, but doesn't require anything that 
really taxes my brain.

As language, how about this? "CHILDINFO is returned when the LIST 
command matches a child mailbox and the pattern matches only a parent 
of that child, not the child itself. CHILDINFO contains at least those 
flags of the child/children that caused the LIST response to be sent. 
It does not contain the name(s) of the child(ren)."

Hm. Not 100% good.

>> - drop \NonExistent (is there any real use for it?)
>
> I am personally Ok with this change (i.e. \NonExistent = \NoSelect), I 
> am just waiting for more people to confirm that there is no 
> difference for clients or give a useful* example when it is not true.
>
> * - I've recently shown an ACL example, that might not be very useful.

Personally I don't think the ACL example was useful enough to justify 
the added complication. It sounded unrealistic to my ears.

I cannot find a better example.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGOkcW053784; Mon, 18 Oct 2004 09:24:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IGOkGf053782; Mon, 18 Oct 2004 09:24:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGOjEp053724 for ; Mon, 18 Oct 2004 09:24:45 -0700 (PDT) (envelope-from tss@iki.fi)
Received: by danu.procontrol.fi (Postfix, from userid 106) id E74021C932AE; Mon, 18 Oct 2004 19:24:42 +0300 (EEST)
Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 411F61C386DA; Mon, 18 Oct 2004 19:24:37 +0300 (EEST)
In-Reply-To: <4173EB50.4060703@isode.com>
References:   <200410051911.i95JB0cG011324@lab.smi.sendmail.com>  <416E76F3.2020506@isode.com>    <416EA92C.3040706@isode.com>   <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com> <26A8C406-211C-11D9-A914-000393CC2E90@iki.fi> <4173EB50.4060703@isode.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-12--449607316"
Message-Id: <33FDDB02-2122-11D9-A914-000393CC2E90@iki.fi>
Content-Transfer-Encoding: 7bit
Cc: ietf-imapext@imc.org
From: Timo Sirainen 
Subject: Re: listext: some things I can't understand
Date: Mon, 18 Oct 2004 19:24:36 +0300
To: Alexey Melnikov 
X-Pgp-Agent: GPGMail 1.0.2
X-Mailer: Apple Mail (2.619)
X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on danu.procontrol.fi
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham  version=3.0.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--Apple-Mail-12--449607316
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 18.10.2004, at 19:12, Alexey Melnikov wrote:

>> And other ideas mentioned before that would make LISTEXT simpler:
>>  - drop CHILDREN and replace it with MATCHPARENT (which is now 
>> disallowed)
>
> IMHO, CHILDREN is probably more useful than MATCHPARENT, but I don't 
> have a strong opinion.

It is, but CHILDREN can be implemented with MATCHPARENT if you drop the 
requirement that it can't be the only selection option.

--Apple-Mail-12--449607316
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBc+5FyUhSUUBViskRAjbaAJ9UO98Aq6BR9YDEbgVlN1vPJR5VtQCfbLuH
wiZdayCcUJcLSNAi4EKJXVU=
=Wlq4
-----END PGP SIGNATURE-----

--Apple-Mail-12--449607316--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGDJnY051514; Mon, 18 Oct 2004 09:13:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IGDJX8051513; Mon, 18 Oct 2004 09:13:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGDI6J051501 for ; Mon, 18 Oct 2004 09:13:18 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 18 Oct 2004 17:13:18 +0100
Message-ID: <4173EB9D.20006@isode.com>
Date: Mon, 18 Oct 2004 17:13:17 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen 
CC: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
References:   <200410051911.i95JB0cG011324@lab.smi.sendmail.com>  <416E76F3.2020506@isode.com>    <416EA92C.3040706@isode.com>   <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com>  <4173C785.9090901@isode.com>   <4173EA9D.8030108@isode.com> 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> The requirement to return a mailbox information only once is a 
>> quality of implementation issue. I guess it can be relaxed to SHOULD.
>
> Good enough for me. In practice it shouldn't make a difference.

An IMAP server can return an unsolicited LIST response, so this 
shouldn't be an issue for clients anyway.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGCLR9051342; Mon, 18 Oct 2004 09:12:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IGCL8L051341; Mon, 18 Oct 2004 09:12:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9IGCJE3051334 for ; Mon, 18 Oct 2004 09:12:20 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 85E851A6C5; Mon, 18 Oct 2004 18:12:22 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 67DB01A6C2; Mon, 18 Oct 2004 18:12:18 +0200 (CEST)
Message-Id: 
Date: Mon, 18 Oct 2004 18:12:12 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
Cc: Alexey Melnikov , Philip Guenther 
References:  <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com>  <416EA92C.3040706@isode.com>  <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com> <200410181602.i9IG299b075457@lab.smi.sendmail.com>
In-Reply-To: <200410181602.i9IG299b075457@lab.smi.sendmail.com>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Philip Guenther writes:
> The CHILDINFO idea seemed to offer a means of simplifying the 
> description or logic some too, but interest in it didn't seem broad.

Disagreement didn't seem broad, I'd say.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGCBk0051305; Mon, 18 Oct 2004 09:12:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IGCBTr051304; Mon, 18 Oct 2004 09:12:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGCAjp051297 for ; Mon, 18 Oct 2004 09:12:10 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 18 Oct 2004 17:12:00 +0100
Message-ID: <4173EB50.4060703@isode.com>
Date: Mon, 18 Oct 2004 17:12:00 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Timo Sirainen 
CC: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
References:   <200410051911.i95JB0cG011324@lab.smi.sendmail.com>  <416E76F3.2020506@isode.com>    <416EA92C.3040706@isode.com>   <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com> <26A8C406-211C-11D9-A914-000393CC2E90@iki.fi>
In-Reply-To: <26A8C406-211C-11D9-A914-000393CC2E90@iki.fi>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Timo Sirainen wrote:

> On 18.10.2004, at 16:39, Alexey Melnikov wrote:
>
>> Part of the problem is that existing (non-extended) LIST command 
>> already complex as is. We can't do match about this.
>>
>> Another part of the problem is MATCHPARENT. Thinking more about how 
>> complex the thing is, maybe we should drop it entirely?
>> However, I am slightly reluctant to do this until several client 
>> authors say that MATCHPARENT is not that useful.
>
> What did you think about Dave Cridland's new syntax idea? You didn't 
> reply to that message 
> (<20041006093514.3678.27139.polymer@peirce.gestalt.entity.net>).
>
> I think using that would make MATCHPARENT much more simpler:
>  - allows dropping \PlaceHolder and \HasSubmailboxes

The proposal avoids introduction of \PlaceHolder/\HasSubmailboxes (which 
is a good thing), but the complexity of implementing MATCHPARENT in 
servers is still present.

>  - avoids confusion with unsolicited responses

I like that part, although I have some concerns about proposed syntax. I 
will try to formulate what my concerns are later on.

> And other ideas mentioned before that would make LISTEXT simpler:
>  - drop CHILDREN and replace it with MATCHPARENT (which is now 
> disallowed)

IMHO, CHILDREN is probably more useful than MATCHPARENT, but I don't 
have a strong opinion.

>  - drop \NonExistent (is there any real use for it?)

I am personally Ok with this change (i.e. \NonExistent = \NoSelect), I 
am just waiting for more people to confirm that there is no difference 
for clients or give a useful* example when it is not true.

Alexey

* - I've recently shown an ACL example, that might not be very useful.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGB6tQ051109; Mon, 18 Oct 2004 09:11:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IGB6jh051107; Mon, 18 Oct 2004 09:11:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9IGB5hC051100 for ; Mon, 18 Oct 2004 09:11:05 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 7A2441A6C1; Mon, 18 Oct 2004 18:11:07 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 710E91A6B6; Mon, 18 Oct 2004 18:11:03 +0200 (CEST)
Message-Id: 
Date: Mon, 18 Oct 2004 18:10:57 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
Cc: Alexey Melnikov 
References:  <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com>  <416EA92C.3040706@isode.com>  <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com>  <4173EA9D.8030108@isode.com>
In-Reply-To: <4173EA9D.8030108@isode.com>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Alexey Melnikov writes:
> The requirement to return a mailbox information only once is a quality 
> of implementation issue. I guess it can be relaxed to SHOULD.

Good enough for me. In practice it shouldn't make a difference.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IG93bI050727; Mon, 18 Oct 2004 09:09:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IG93he050726; Mon, 18 Oct 2004 09:09:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IG92Ri050714 for ; Mon, 18 Oct 2004 09:09:03 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 18 Oct 2004 17:09:02 +0100
Message-ID: <4173EA9D.8030108@isode.com>
Date: Mon, 18 Oct 2004 17:09:01 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen 
CC: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
References:   <200410051911.i95JB0cG011324@lab.smi.sendmail.com>  <416E76F3.2020506@isode.com>    <416EA92C.3040706@isode.com>   <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com>  <4173C785.9090901@isode.com> 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Arnt Gulbrandsen wrote:

>> Another part of the problem is MATCHPARENT. Thinking more about how 
>> complex the thing is, maybe we should drop it entirely?
>> However, I am slightly reluctant to do this until several client 
>> authors say that MATCHPARENT is not that useful.
>
> If MATCHPARENT is dropped and servers are allowed to return 
> /fruit/banana twice for 'LIST "" (*ban* *ana*)', then I think LISTEXT 
> becomes nice and simple.

The requirement to return a mailbox information only once is a quality 
of implementation issue. I guess it can be relaxed to SHOULD.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IG29av049364; Mon, 18 Oct 2004 09:02:09 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IG29pH049363; Mon, 18 Oct 2004 09:02:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IG28Fm049349 for ; Mon, 18 Oct 2004 09:02:08 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id i9IG29Hv004949 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 18 Oct 2004 09:02:09 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i9IG29Hv004949
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=FrVm2XP0b+MToth648Iz2uL5On+t9Vajs5nb/VJ9D/g0T2EbCfSj8A+eDNH4wGC7d NbLwfKkD7wvDSk2WP4HgOA+mLZ9GOGLUnpm04z2Y4kgrUl5Gz8RvuA0w8ytjlsVKL5D ldQ6q2KtpgjwkoIN7BsKuAJ7cCKe7FiqAQGujKA=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i9IG299b075457; Mon, 18 Oct 2004 09:02:09 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410181602.i9IG299b075457@lab.smi.sendmail.com>
To: Alexey Melnikov 
Cc: ietf-imapext@imc.org
From: Philip Guenther 
Subject: Re: listext: some things I can't understand 
In-reply-to: <4173C785.9090901@isode.com> 
References:  <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com>  <416EA92C.3040706@isode.com>  <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com>  <4173C785.9090901@isode.com> 
Date: Mon, 18 Oct 2004 09:02:09 -0700
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Alexey Melnikov  writes:
...
>Another part of the problem is MATCHPARENT. Thinking more about how 
>complex the thing is, maybe we should drop it entirely?

As mentioned in a previous post, it appears to me that some form
of \Placeholder is necessary for listing of subscribed** folders
via hierarchy levels using '%'.  If describing how MATCHPARENT works
in the general case makes it too complicated, then perhaps we should
draw back and simply describe how it operates when such a pattern
is used, i.e., _if_ the last hierarchical component of the pattern
is *just* '%', then .


The CHILDINFO idea seemed to offer a means of simplifying the
description or logic some too, but interest in it didn't seem broad.


** Actually, the logic applies to any situation where "foo/bar" may
be selected without "foo" also being selected.  This is true of
normal LIST on servers like Cyrus where DELETE may remove a mailbox
that has children, which makes me wonder how well clients handle
such hierarchies and whether the restriction on MATCHPARENT to when
there's another selection option should be removed.


>However, I am slightly reluctant to do this until several client authors 
>say that MATCHPARENT is not that useful.

Feedback from client authors about their use of '%' seems important
here, yes.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IFfZIM045230; Mon, 18 Oct 2004 08:41:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IFfZAh045229; Mon, 18 Oct 2004 08:41:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IFfXqm045180 for ; Mon, 18 Oct 2004 08:41:34 -0700 (PDT) (envelope-from tss@iki.fi)
Received: by danu.procontrol.fi (Postfix, from userid 106) id 932611C38778; Mon, 18 Oct 2004 18:41:22 +0300 (EEST)
Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id CF51C1C386DA; Mon, 18 Oct 2004 18:41:17 +0300 (EEST)
In-Reply-To: <4173C785.9090901@isode.com>
References:   <200410051911.i95JB0cG011324@lab.smi.sendmail.com>  <416E76F3.2020506@isode.com>    <416EA92C.3040706@isode.com>   <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-11--452206659"
Message-Id: <26A8C406-211C-11D9-A914-000393CC2E90@iki.fi>
Content-Transfer-Encoding: 7bit
Cc: ietf-imapext@imc.org, Arnt Gulbrandsen 
From: Timo Sirainen 
Subject: Re: listext: some things I can't understand
Date: Mon, 18 Oct 2004 18:41:17 +0300
To: Alexey Melnikov 
X-Pgp-Agent: GPGMail 1.0.2
X-Mailer: Apple Mail (2.619)
X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on danu.procontrol.fi
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham  version=3.0.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--Apple-Mail-11--452206659
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 18.10.2004, at 16:39, Alexey Melnikov wrote:

> Part of the problem is that existing (non-extended) LIST command 
> already complex as is. We can't do match about this.
>
> Another part of the problem is MATCHPARENT. Thinking more about how 
> complex the thing is, maybe we should drop it entirely?
> However, I am slightly reluctant to do this until several client 
> authors say that MATCHPARENT is not that useful.

What did you think about Dave Cridland's new syntax idea? You didn't 
reply to that message 
(<20041006093514.3678.27139.polymer@peirce.gestalt.entity.net>).

I think using that would make MATCHPARENT much more simpler:
  - allows dropping \PlaceHolder and \HasSubmailboxes
  - avoids confusion with unsolicited responses

And other ideas mentioned before that would make LISTEXT simpler:
  - drop CHILDREN and replace it with MATCHPARENT (which is now 
disallowed)
  - drop \NonExistent (is there any real use for it?)

--Apple-Mail-11--452206659
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBc+QdyUhSUUBViskRAk0NAJ9tNu0hV82SIRRATybCVRJEETvrvQCglcS/
Dz6cs/iiGDN9UMCjoIyYsKw=
=8OPv
-----END PGP SIGNATURE-----

--Apple-Mail-11--452206659--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IFTbYX042971; Mon, 18 Oct 2004 08:29:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IFTba5042970; Mon, 18 Oct 2004 08:29:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9IFTZDV042958 for ; Mon, 18 Oct 2004 08:29:36 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id C174F1A6C8; Mon, 18 Oct 2004 17:29:37 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id A76AA1A6C4; Mon, 18 Oct 2004 17:29:33 +0200 (CEST)
Message-Id: 
Date: Mon, 18 Oct 2004 17:29:26 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
Cc: Alexey Melnikov 
References:  <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com>  <416EA92C.3040706@isode.com>  <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com> <4173C785.9090901@isode.com>
In-Reply-To: <4173C785.9090901@isode.com>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Alexey Melnikov writes:
> Part of the problem is that existing (non-extended) LIST command 
> already complex as is. We can't do match about this.

Agreed.

> Another part of the problem is MATCHPARENT. Thinking more about how 
> complex the thing is, maybe we should drop it entirely?
> However, I am slightly reluctant to do this until several client 
> authors say that MATCHPARENT is not that useful.

If MATCHPARENT is dropped and servers are allowed to return 
/fruit/banana twice for 'LIST "" (*ban* *ana*)', then I think LISTEXT 
becomes nice and simple.

Keeping a simplified variety of MATCHPARENT may do, too.

> P.S. I don't think I will be able to produce a new revision before 
> October 25 (submission deadline). I will make one after the face to 
> face (+Jabber) meeting in Washington. I will post a list of LISTEXT 
> issues before the meeting.

OK.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IFG2KH039555; Mon, 18 Oct 2004 08:16:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IFG2KR039554; Mon, 18 Oct 2004 08:16:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IFFvF3039538 for ; Mon, 18 Oct 2004 08:15:57 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 18 Oct 2004 16:15:39 +0100
Message-ID: <4173C785.9090901@isode.com>
Date: Mon, 18 Oct 2004 14:39:17 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen 
CC: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
References:   <200410051911.i95JB0cG011324@lab.smi.sendmail.com>  <416E76F3.2020506@isode.com>    <416EA92C.3040706@isode.com>   <4172AC1D.8010006@isode.com> <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com>
In-Reply-To: <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Arnt Gulbrandsen wrote:

> But perhaps the best way is to simplify LISTEXT to the point where, 
> ah, non-experts like me don't have a problem understanding it. Are you 
> simplifying LISTEXT much in -11?

Part of the problem is that existing (non-extended) LIST command already 
complex as is. We can't do match about this.

Another part of the problem is MATCHPARENT. Thinking more about how 
complex the thing is, maybe we should drop it entirely?
However, I am slightly reluctant to do this until several client authors 
say that MATCHPARENT is not that useful.

Alexey

P.S. I don't think I will be able to produce a new revision before 
October 25 (submission deadline). I will make one after the face to face 
(+Jabber) meeting in Washington. I will post a list of LISTEXT issues 
before the meeting.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ID8ONU015239; Mon, 18 Oct 2004 06:08:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ID8OJg015238; Mon, 18 Oct 2004 06:08:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9ID8IT5015190 for ; Mon, 18 Oct 2004 06:08:23 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 4F6C51A6C1; Mon, 18 Oct 2004 15:08:14 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 174E01A6B6; Mon, 18 Oct 2004 15:08:10 +0200 (CEST)
Message-Id: <07fKTVpOgKOFTMs/fRSrJw.md5@prosecco.oryx.com>
Date: Mon, 18 Oct 2004 15:08:09 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
Cc: Alexey Melnikov 
References:  <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com>  <416EA92C.3040706@isode.com>  <4172AC1D.8010006@isode.com>
In-Reply-To: <4172AC1D.8010006@isode.com>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Alexey Melnikov writes:
> One way to address this is to say that LISTEXT capability is just 
> support for extended LIST command and responses, with no default 
> options. Another capability string can advertise support for 
> SUBSCIBED+REMOTE+CHILDREN and maybe MATCHPARENT.

Another would be to say that any server that advertises e.g. POSTADDRESS 
support has to implement the necessary syntax, even if that server does 
not advertise LISTEXT.

But perhaps the best way is to simplify LISTEXT to the point where, ah, 
non-experts like me don't have a problem understanding it. Are you 
simplifying LISTEXT much in -11?

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9HHUGRr026222; Sun, 17 Oct 2004 10:30:16 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9HHUGEu026221; Sun, 17 Oct 2004 10:30:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9HHUFOU026175 for ; Sun, 17 Oct 2004 10:30:16 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Sun, 17 Oct 2004 18:30:07 +0100
Message-ID: <4172AC1D.8010006@isode.com>
Date: Sun, 17 Oct 2004 18:30:05 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen 
CC: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
References:   <200410051911.i95JB0cG011324@lab.smi.sendmail.com>  <416E76F3.2020506@isode.com>    <416EA92C.3040706@isode.com> 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> I don't think that for the POSTADDRESS extension it would make any 
>> difference.
>
> Certainly it would.

Hmm, I was thinking about different thing. I wanted to say that 
POSTADDRESS didn't interact with MATCHPARENT, as it was a return option.

> Can't implement POSTADDRESS without the extended list syntax. Can't 
> advertise support for the extended list syntax without handling 
> MATCHPARENT. Can't implement that without understanding \placeholder 
> and \hassubmailboxes.

You are right, of course.
One way to address this is to say that LISTEXT capability is just 
support for extended LIST command and responses, with no default 
options. Another capability string can advertise support for 
SUBSCIBED+REMOTE+CHILDREN and maybe MATCHPARENT.

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EKC7if048106; Thu, 14 Oct 2004 13:12:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EKC7vd048105; Thu, 14 Oct 2004 13:12:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9EKC21n048087 for ; Thu, 14 Oct 2004 13:12:07 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 6351F1A6C3; Thu, 14 Oct 2004 22:12:04 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 25B591A6B8; Thu, 14 Oct 2004 22:11:58 +0200 (CEST)
Message-Id: 
Date: Thu, 14 Oct 2004 22:11:57 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
Cc: Alexey Melnikov 
References:  <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com>  <416EA92C.3040706@isode.com>
In-Reply-To: <416EA92C.3040706@isode.com>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Alexey Melnikov writes:
> I don't think that for the POSTADDRESS extension it would make any 
> difference.

Certainly it would.

Can't implement POSTADDRESS without the extended list syntax. Can't 
advertise support for the extended list syntax without handling 
MATCHPARENT. Can't implement that without understanding \placeholder 
and \hassubmailboxes.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EGSVQL015086; Thu, 14 Oct 2004 09:28:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EGSV8b015085; Thu, 14 Oct 2004 09:28:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EGSUFF015077 for ; Thu, 14 Oct 2004 09:28:30 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 14 Oct 2004 17:28:29 +0100
Message-ID: <416EA92C.3040706@isode.com>
Date: Thu, 14 Oct 2004 17:28:28 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen 
CC: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
References:   <200410051911.i95JB0cG011324@lab.smi.sendmail.com>  <416E76F3.2020506@isode.com> 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> Mark has proposed to have a single capability for all options 
>> mentioned in LISTEXT. He has justified his proposal by saying that 
>> IMAP had already too many options.
>
> The price of that is that whoever wants to implement POSTADDRESS must 
> understand the subtleties of \placeholder and \hassubmailboxes.

(When answering the questions I was only thinking about the CHILDREN 
option.)
I don't think that for the POSTADDRESS extension it would make any 
difference.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ED7Bd3081280; Thu, 14 Oct 2004 06:07:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ED7Bft081279; Thu, 14 Oct 2004 06:07:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ED77vk081264 for ; Thu, 14 Oct 2004 06:07:11 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Message-Id: 
Date: Thu, 14 Oct 2004 15:08:17 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
Cc: Alexey Melnikov , Philip Guenther 
References:  <200410051911.i95JB0cG011324@lab.smi.sendmail.com> <416E76F3.2020506@isode.com>
In-Reply-To: <416E76F3.2020506@isode.com>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Alexey Melnikov writes:
> Mark has proposed to have a single capability for all options 
> mentioned in LISTEXT. He has justified his proposal by saying that 
> IMAP had already too many options.

The price of that is that whoever wants to implement POSTADDRESS must 
understand the subtleties of \placeholder and \hassubmailboxes.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ECsM3K079732; Thu, 14 Oct 2004 05:54:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9ECsM5S079731; Thu, 14 Oct 2004 05:54:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9ECsLUI079719 for ; Thu, 14 Oct 2004 05:54:21 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 14 Oct 2004 13:54:12 +0100
Message-ID: <416E76F3.2020506@isode.com>
Date: Thu, 14 Oct 2004 13:54:11 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philip Guenther 
CC: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
References:  <200410051911.i95JB0cG011324@lab.smi.sendmail.com>
In-Reply-To: <200410051911.i95JB0cG011324@lab.smi.sendmail.com>
Content-Type: multipart/alternative; boundary="------------040605040005040601030104"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--------------040605040005040601030104
Content-type: text/plain; charset="us-ascii"

Philip Guenther wrote:

>Arnt Gulbrandsen  writes:
>...
>  
>
>>1. The children return option. Isn't that a noop? The server may ignore 
>>the option, and may (per RFC 3501/3348) send the \haschildren and 
>>\hasnochildren attributes even if children isn't present. The 'then' 
>>and 'else' parts of that test look more than a little similar to me.   
>>
>
>I vaguely recall (but may be hallucinating) that someone proposed making
>the CHILDREN option a separate capability with support implying that
>when requested, every response would have \haschildren or
>\hasnochildren.  Scanning the list archive, it appears that was
>kinda-sorta decided against based on the fact that the current children
>support (RFC 3348) doesn't have a capability associated with it, but
>that doesn't make logical sense as _that_ decision stems from the lack
>of a way to request the info.
>
>Can anyone point to a reason for the decision to not make CHILDREN a
>separate capability, perhaps a thread in the archive that I missed?
>  
>
As far as I remember:
Mark has proposed to have a single capability for all options mentioned 
in LISTEXT. He has justified his proposal by saying that IMAP had 
already too many options.
Originally Mark has been against inclusion of the CHILDREN extension, 
but he has changed his mind later on when the WG has agreed that the 
server was not required to return \HasChildren/\HasNoChildren unless 
explicitly asked by the client.

Does this answer your question?

Alexey


--------------040605040005040601030104
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit




  
  






Philip Guenther wrote:



  
Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> writes:
...
  

  

    
1. The children return option. Isn't that a noop? The server may ignore 
the option, and may (per RFC 3501/3348) send the \haschildren and 
\hasnochildren attributes even if children isn't present. The 'then' 
and 'else' parts of that test look more than a little similar to me.   

  

  

I vaguely recall (but may be hallucinating) that someone proposed making
the CHILDREN option a separate capability with support implying that
when requested, every response would have \haschildren or
\hasnochildren.  Scanning the list archive, it appears that was
kinda-sorta decided against based on the fact that the current children
support (RFC 3348) doesn't have a capability associated with it, but
that doesn't make logical sense as _that_ decision stems from the lack
of a way to request the info.

Can anyone point to a reason for the decision to not make CHILDREN a
separate capability, perhaps a thread in the archive that I missed?
  



As far as I remember:

Mark has proposed to have a single capability for all options mentioned
in LISTEXT. He has justified his proposal by saying that IMAP had
already too many options.

Originally Mark has been against inclusion of the CHILDREN extension,
but he has changed his mind later on when the WG has agreed that the
server was not required to return \HasChildren/\HasNoChildren unless
explicitly asked by the client.



Does this answer your question?



Alexey






--------------040605040005040601030104--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EBjPcl070717; Thu, 14 Oct 2004 04:45:25 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EBjPVA070716; Thu, 14 Oct 2004 04:45:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EBjOtC070709 for ; Thu, 14 Oct 2004 04:45:25 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Message-Id: 
Date: Thu, 14 Oct 2004 13:46:34 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
Cc: Alexey Melnikov 
References:  <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>  <416E6482.20304@isode.com>
In-Reply-To: <416E6482.20304@isode.com>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Alexey Melnikov writes:
> As I understand it, it wasn't the intention of the section 5.5 to list 
> all commands that [may] have dependencies. The server will just have 
> to process the extended LIST commands in the order received. Is this 
> sufficient?

Sufficient, perhaps, but the requirement hardly seems justified.

> I can come up only with a single strained example: If the server also 
> implements ACL extension, it may return \NoSelect if the current user 
> has the "l" right (i.e. can LIST), but doesn't have the "r" right 
> (i.e. can't SELECT). Although I am not aware of any server that 
> actually does this.
>
> But for all intensive purposes I can't come up with a reason why a  
> client would care about the difference between "mailbox doesn't 
> exist" and "mailbox exists but can't be selected".

Agreed. It's just something that causes people like me to think, "this 
is too complex to implement - forget it."

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EBZeeX069225; Thu, 14 Oct 2004 04:35:40 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EBZeO5069224; Thu, 14 Oct 2004 04:35:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EBZYow069198 for ; Thu, 14 Oct 2004 04:35:34 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 14 Oct 2004 12:35:31 +0100
Message-ID: <416E6482.20304@isode.com>
Date: Thu, 14 Oct 2004 12:35:30 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Arnt Gulbrandsen 
CC: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
References:   <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030601010801060603070704"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--------------030601010801060603070704
Content-type: text/plain; charset="KOI8-R"; format="flowed"
Content-transfer-encoding: 7bit

Arnt Gulbrandsen wrote:

>> \Placeholder implies that:
>>
>> 1) The mailbox *does* exist, but doesn't match the current criteria.
>> 2) The mailbox has inferior mailboxes, some of which *do* match the 
>> current selection criteria.
>
> I see what you're saying now, but in order to make sense of it, I have 
> to think in terms of a command. More like a tagged response than an 
> untagged one.
>
> In fact, this requires an addition to RFC 3501 section 5.5, specifying 
> that two list commands cannot be issued concurrently when one uses 
> matchparent.

As I understand it, it wasn't the intention of the section 5.5 to list 
all commands that [may] have dependencies.
The server will just have to process the extended LIST commands in the 
order received. Is this sufficient?

>>> Why do we need both \nonexistent and \noselect?
>>
>> Yeah, the difference is pretty subtle.
>>
>> Foo LIST "" "%"
>> * LIST (\NoSelect) "/" "Stuff"
>> Foo OK
>>
>> Bar LIST (SUBSCRIBED) "" "%"
>> * LIST (\NonExistent \Subscribed) "/" "Other Stuff"
>> Bar OK
>>
>> Neither Stuff nor Other Stuff exist. The difference is that a LIST of 
>> "Stuff/%" is pretty likely to give some responses, since the node 
>> exists in the mailbox heirarchy, as it were, whereas "Other Stuff/%" 
>> won't - if it would do, it'd have been returned in the first list.
>>
>> FWIW, I rewrote these paragraphs several times with agreements that 
>> one implied the other before I realised that they have subtly 
>> different usages. I'm  still not entirely sure whether this is the 
>> case, in fact.
>>
>> Would:
>> * LIST (\NoSelect \Subscribed) "/" "Other Stuff"
>>
>> be interpretable any other way, for the Bar command above?
>
> Optimism knows no bounds. A client author who trusts every server 
> author to understand the subtleties perfectly could read from that 
> response that Other Stuff might have child mailboxes.
>
> This seems to be the same as your \nonexistent response above:
>
> * LIST (\noselect \hasnochildren \subscribed) "/" "Other Stuff"

I can come up only with a single strained example: If the server also 
implements ACL extension, it may return \NoSelect if the current user 
has the "l" right (i.e. can LIST), but doesn't have the "r" right (i.e. 
can't SELECT). Although I am not aware of any server that actually does 
this.

But for all intensive purposes I can't come up with a reason why a 
client would care about the difference between "mailbox doesn't exist" 
and "mailbox exists but can't be selected".


--------------030601010801060603070704
Content-type: text/html; charset="KOI8-R"
Content-transfer-encoding: 8bit




  
  






Arnt Gulbrandsen wrote:



  
\Placeholder implies that: 

    

1) The mailbox *does* exist, but doesn't match the current criteria. 

2) The mailbox has inferior mailboxes, some of which *do* match the
current selection criteria. 

  

I see what you're saying now, but in order to make sense of it, I have
to think in terms of a command. More like a tagged response than an
untagged one. 

  

In fact, this requires an addition to RFC 3501 section 5.5,
specifying that two list commands cannot be issued concurrently when
one uses matchparent. 



As I understand it, it wasn't the intention of the section 5.5 to list
all commands that [may] have dependencies.

The server will just have to process the extended LIST commands in the
order received. Is this sufficient?



  

    
Why do we need both \nonexistent and
\noselect? 

    

Yeah, the difference is pretty subtle. 

    

Foo LIST "" "%" 

* LIST (\NoSelect) "/" "Stuff" 

Foo OK 

    

Bar LIST (SUBSCRIBED) "" "%" 

* LIST (\NonExistent \Subscribed) "/" "Other Stuff" 

Bar OK 

    

Neither Stuff nor Other Stuff exist. The difference is that a LIST of
"Stuff/%" is pretty likely to give some responses, since the node
exists in the mailbox heirarchy, as it were, whereas "Other Stuff/%"
won't - if it would do, it'd have been returned in the first list. 

    

FWIW, I rewrote these paragraphs several times with agreements that one
implied the other before I realised that they have subtly different
usages. I'mš still not entirely sure whether this is the case, in fact.
    

    

Would: 

* LIST (\NoSelect \Subscribed) "/" "Other Stuff" 

    

be interpretable any other way, for the Bar command above? 

  

Optimism knows no bounds. A client author who trusts every server
author to understand the subtleties perfectly could read from that
response that Other Stuff might have child mailboxes. 

  

This seems to be the same as your \nonexistent response above: 

  

* LIST (\noselect \hasnochildren \subscribed) "/" "Other Stuff"

I can come up only with a single strained example: If the server also
implements ACL extension, it may return \NoSelect if the current user
has the "l" right (i.e. can LIST), but doesn't have the "r" right (i.e.
can't SELECT). Although I am not aware of any server that actually does
this.



But for all intensive purposes I can't come up with a reason why a client
would care about the difference between "mailbox doesn't exist" and
"mailbox exists but can't be selected".








--------------030601010801060603070704--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EB3o4N061791; Thu, 14 Oct 2004 04:03:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EB3okN061790; Thu, 14 Oct 2004 04:03:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EB3nWn061768 for ; Thu, 14 Oct 2004 04:03:49 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Thu, 14 Oct 2004 12:02:34 +0100
Message-ID: <416E5CC9.9050800@isode.com>
Date: Thu, 14 Oct 2004 12:02:33 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Cridland 
CC: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
References:  <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>
In-Reply-To: <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>
Content-Type: multipart/alternative; boundary="------------070800080806010008030807"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--------------070800080806010008030807
Content-type: text/plain; charset="us-ascii"

Dave Cridland wrote:

>> 1. The children return option. Isn't that a noop? The server may 
>> ignore the option, and may (per RFC 3501/3348) send the \haschildren 
>> and \hasnochildren attributes even if children isn't present. The 
>> 'then' and 'else' parts of that test look more than a little similar 
>> to me.
>
> It gets worse, actually. The server "MAY ignore" it, but "SHOULD 
> return" the information, which seems to give me two levels of 
> requirement for the same thing.
>
> One thing that CHILDREN (The new and improved LISTEXT return option, I 
> mean) gives me, the client author, is a way of saying "Look, I could 
> do with this information, but don't sweat it, I can always issue 
> another LIST to find out later." If you prefer, it's a useful method 
> of being nice to the server.

Exactly.


--------------070800080806010008030807
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit




  
  






Dave Cridland wrote:



  
1. The children return option. Isn't that a
noop? The server may ignore the option, and may (per RFC 3501/3348)
send the \haschildren and \hasnochildren attributes even if children
isn't present. The 'then' and 'else' parts of that test look more than
a little similar to me. 

  

It gets worse, actually. The server "MAY ignore" it, but "SHOULD
return" the information, which seems to give me two levels of
requirement for the same thing. 

  

One thing that CHILDREN (The new and improved LISTEXT return option, I
mean) gives me, the client author, is a way of saying "Look, I could do
with this information, but don't sweat it, I can always issue another
LIST to find out later." If you prefer, it's a useful method of being
nice to the server. 



Exactly.






--------------070800080806010008030807--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9BJe2Xg032602; Mon, 11 Oct 2004 12:40:03 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9BJe2vg032601; Mon, 11 Oct 2004 12:40:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9BJe1k7032590 for ; Mon, 11 Oct 2004 12:40:02 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09062; Mon, 11 Oct 2004 15:39:58 -0400 (EDT)
Message-Id: <200410111939.PAA09062@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: ietf-imapext@imc.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-imapext-i18n-04.txt
Date: Mon, 11 Oct 2004 15:39:58 -0400
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: Internet Message Access Protocol Internationalization
	Author(s)	: C. Newman, A. Gulbrandsen
	Filename	: draft-ietf-imapext-i18n-04.txt
	Pages		: 16
	Date		: 2004-10-11
	
Internet Message Access Protocol (IMAP) version 4rev1 has basic
    support for non-ASCII characters in mailbox names and search
    substrings.  It also supports non-ASCII message headers and content
    encoded as specified by Multipurpose Internet Mail Extensions
    (MIME).  This specification defines a collection of IMAP extensions
    which improve international support including comparator negotiation
    for search, sort and thread, language negotiation for international
    error text, and translations for namespace prefixes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-i18n-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-i18n-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-10-11155343.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-i18n-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-i18n-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-10-11155343.I-D@ietf.org>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98FXpC6046800; Fri, 8 Oct 2004 08:33:51 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i98FXpOU046799; Fri, 8 Oct 2004 08:33:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98FXok2046786 for ; Fri, 8 Oct 2004 08:33:51 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [192.168.2.79] (64.221.254.66.ptr.us.xo.net [64.221.254.66])  by rufus.isode.com via TCP (internal) with ESMTPA; Fri, 8 Oct 2004 16:32:43 +0100
Message-ID: <4166B314.7000708@isode.com>
Date: Fri, 08 Oct 2004 16:32:36 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Cridland 
CC: IMAP extensions Mailing List 
Subject: Re: One command or several...
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com> 	<20041006154011.3678.64504.polymer@peirce.gestalt.entity.net>	<200410061616.i96GGDqS097315@lab.smi.sendmail.com> <20041006164309.3678.28353.polymer@peirce.gestalt.entity.net>
In-Reply-To: <20041006164309.3678.28353.polymer@peirce.gestalt.entity.net>
Content-Type: multipart/alternative; boundary="------------000000050908090900050204"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--------------000000050908090900050204
Content-type: text/plain; charset="us-ascii"

Dave Cridland wrote:

>> 
>> >Moreover, it introduces extra complexity into the syntax, especially 
>> >because it introduces special handling of the empty list-mailbox - 
>> or >more accurately, special handling of the special handling... As 
>> >wonderfully ironic as that is, I can't see the point in persuing that.
>>
>> Even if multiple patterns are removed, the empty pattern will have
>> to be mentioned to say what happens if you use options with it...even
>> if all it was to say was "the behavior of the empty pattern is
>> unspecified if list options are used".
>
>
> Not really. It's specified per-option, if at all. In principle, an 
> empty pattern used with REMOTE could tell you whether the entire 
> heirarchy was rooted remotely or not, for instance - that's 
> potentially useful information.

I think you are trying to attach a specific meaning to the empty mailbox 
path for the REMOTE option. How would you define what is the meaning of 
"" when both REMOTE and SUBSCRIBED are specified?

Alexey


--------------000000050908090900050204
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit




  
  


Dave Cridland wrote:



  
<regarding mbox-or-pat>
    

>Moreover, it introduces extra complexity into the syntax,
especially >because it introduces special handling of the empty
list-mailbox - or >more accurately, special handling of the special
handling... As >wonderfully ironic as that is, I can't see the point
in persuing that.
    

    

Even if multiple patterns are removed, the empty pattern will have
    

to be mentioned to say what happens if you use options with it...even
    

if all it was to say was "the behavior of the empty pattern is
    

unspecified if list options are used".
    

  

  

Not really. It's specified per-option, if at all. In principle, an
empty pattern used with REMOTE could tell you whether the entire
heirarchy was rooted remotely or not, for instance - that's potentially
useful information.
  



I think you are trying to attach a specific meaning to the empty
mailbox path for the REMOTE option. How would you define what is the
meaning of "" when both REMOTE and SUBSCRIBED are specified?



Alexey







--------------000000050908090900050204--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96MAoke008595; Wed, 6 Oct 2004 15:10:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96MAoED008594; Wed, 6 Oct 2004 15:10:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96MAkcV008575 for ; Wed, 6 Oct 2004 15:10:46 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.6) with ESMTP id i96M9qK4021320 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 6 Oct 2004 15:09:53 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i96M9qK4021320
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=cNuiM3w1E6Um5RhXxq+hu6KopuV5jgUVn5aEeEKeFZEy8+jT2bKyU5kqqy+kCe95V YA+LR/rBZ1/lNAGI0i0dB0MB7WDrA/mYJgdnLjXK/zra+bRadJsjmgIfUPdxCcDvXPK X+EqrYF/G92h3O4saje142b5zCrUf+1mML9sKRU=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i96M9pdx024488; Wed, 6 Oct 2004 15:09:51 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410062209.i96M9pdx024488@lab.smi.sendmail.com>
From: Philip Guenther 
To: Arnt Gulbrandsen 
cc: ietf-imapext@imc.org, Timo Sirainen , Dave Cridland 
Subject: Re: listext: some things I can't understand 
Date: Wed, 06 Oct 2004 15:09:51 -0700
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

I wrote:
>	* LIST () "/" "Veg" ((CHILDINFO ("\Subscribed")))

Oops.  As pointed out by Jutta, the backslash has to be doubled,
so that should be:
	* LIST () "/" "Veg" ((CHILDINFO ("\\Subscribed")))

and similar through the rest of the examples.

Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96KVFJh099516; Wed, 6 Oct 2004 13:31:15 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96KVF1H099515; Wed, 6 Oct 2004 13:31:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96KVAQp099497 for ; Wed, 6 Oct 2004 13:31:10 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.6) with ESMTP id i96KUuHZ019941 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 6 Oct 2004 13:30:56 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i96KUuHZ019941
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=cVnFAbfHCxWPG9UCefdCAHyOSPXUN7nH/6Y5rtcBbpUxt7Xud8LayqoeWMMHMeM1j f37xPMvpuZbEv7dl20A4aLRewVNASrWU9P4dwQujIG1CHBwWYImrUszI/q88PQtApoW iJI2+La/4tqOezWNqAYaE1UWWkGw8rXWUeyvZBk=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i96KUtIN016879; Wed, 6 Oct 2004 13:30:56 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410062030.i96KUtIN016879@lab.smi.sendmail.com>
To: Arnt Gulbrandsen 
Cc: ietf-imapext@imc.org, Timo Sirainen , Dave Cridland 
From: Philip Guenther 
Subject: Re: listext: some things I can't understand 
In-reply-to: <6HX949UaRSb7CKtb+zSNAQ.md5@libertango.oryx.com> 
References:  <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>  <20041006093514.3678.27139.polymer@peirce.gestalt.entity.net>   <6HX949UaRSb7CKtb+zSNAQ.md5@libertango.oryx.com> 
Date: Wed, 06 Oct 2004 13:30:55 -0700
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Arnt Gulbrandsen  writes:
>Timo Sirainen writes:
>> On 6.10.2004, at 12:35, Dave Cridland wrote:
>>
>>>  A0004 LIST (SUBSCRIBED MATCHPARENT) "" "%"
>>>  * LIST (\Subscribed) "/" "Fruit"
>>>  * LIST () "/" "Veg" ((CHILDINFO (\Subscribed))
>>>  A0004 OK
>>
>> I like this. Makes it very clear what was intended with it.
>
>Agreed. This one's good.

This makes sense, but there are still some things to hammer out or fix.

On the syntax side, the above doesn't match the mbox-list-extended
syntax, and not just because a closing paren was left off: \subscribed
isn't an nstring, so it needs to be returned as a quoted string or
literal:
	* LIST () "/" "Veg" ((CHILDINFO ("\Subscribed")))

(Note that it isn't an atom either, so switching the grammar from
nstring to astring wouldn't help.)


On the semantics side, the handling of CHILDINFO when there are multiple
selection criteria _other_ than MATCHPARENT (e.g., both REMOTE and
SUBSCRIBED) needs to be stated.  I think it should always be a single
list that has the union of the 'selection flags' (\Remote and
\Subscribed) of the selected children.  That is, if there are multiple
selected children with different flags (one's remote, the other isn't)
you _don't_ get multiple blocks of childinfo.

For example, given the following hierarchy:
	1 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
	* LIST () "/" "projects"
	* LIST (\Subscribed \Remote) "/" "projects/clients"
	* LIST (\Subscribed) "/" "projects/servers"
	* LIST () "/" "projects/servers/imap"
	1 OK

I think the following should be correct:
	2 LIST (SUBSCRIBED MATCHPARENT) "" "%"
	* LIST () "/" "projects" ((CHILDINFO ("\Subscribed")))
	2 OK
	3 LIST (REMOTE MATCHPARENT) "" "%"
	* LIST () "/" "projects" ((CHILDINFO ("\Remote")))
	3 OK
	4 LIST (REMOTE SUBSCRIBED MATCHPARENT) "" "%"
	* LIST () "/" "projects" ((CHILDINFO ("\Remote" "\Subscribed")))
	4 OK
	5 LIST (REMOTE MATCHPARENT) "" "projects/%"
	* LIST (\Remote) "/" "projects/clients"
	* LIST () "/" "projects/servers" ((CHILDINFO ()))
	5 OK


So, that would make the syntax of CHILDINFO be:

childinfo = "CHILDINFO" SP "(" [string *(SP string)] ")"
	     ; matches a subset of the mbox-list-extended-item-data syntax


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96HC4p4078598; Wed, 6 Oct 2004 10:12:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96HC4sU078597; Wed, 6 Oct 2004 10:12:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96HC3OI078583 for ; Wed, 6 Oct 2004 10:12:03 -0700 (PDT) (envelope-from daboo@isamet.com)
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i96GmUo3007591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2004 12:48:30 -0400
Date: Wed, 06 Oct 2004 13:12:00 -0400
From: Cyrus Daboo 
To: Dave Cridland 
cc: IMAP extensions Mailing List , Arnt Gulbrandsen , Philip Guenther 
Subject: Re: One command or several... 
Message-ID: 
In-Reply-To: <20041006165725.3678.93012.polymer@peirce.gestalt.entity.net>
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com> <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net> <278BADDE17C67F56F230ACD4@ninevah.cyrusoft.com> <20041006165725.3678.93012.polymer@peirce.gestalt.entity.net>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Hi Dave,

--On Wednesday, October 6, 2004 5:57 PM +0100 Dave Cridland 
 wrote:

>> However, at this point I wouldn't mind if we went back to just a
>> single list-mailbox syntax and left mbox-or-pat for a future
>> extension.
>
> I'm not wildly against the syntax, I'm just not convinced it's actually
> needed right now.
>
> Actually, I think the scenario you describe above could be better handled
> with arbitrary mailbox attributes - which, IIRC, ANNOTATEMORE introduces
> (Of course, you'd know that better than me). Then the client can simply
> define its mailbox sets on the server, effectively, by 'tagging'
> mailboxes, and then search for that tag, by using some
> ANNOTATEMORE+LISTEXT extension.
>
> This also has the benefit that mailbox 'sets' can be standardized
> themselves, and made interoperable.

Certainly I would like to see both an ANNOTATION selection option and a 
return option. However, I worry that that may encourage more use of "*" 
wildcard matching as likely clients would want to match mailboxes at any 
depth in the hierarchy.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96Gxkw8077510; Wed, 6 Oct 2004 09:59:46 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96GxkF2077509; Wed, 6 Oct 2004 09:59:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GxjK1077502 for ; Wed, 6 Oct 2004 09:59:45 -0700 (PDT) (envelope-from dave@cridland.net)
Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id C4210154009; Wed,  6 Oct 2004 16:59:47 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline; xpolymertype="coverletter"
From: Dave Cridland 
To: Cyrus Daboo 
Cc: IMAP extensions Mailing List , Arnt Gulbrandsen , Philip Guenther 
Subject: Re: One command or several... 
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com> <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net> <278BADDE17C67F56F230ACD4@ninevah.cyrusoft.com>
In-Reply-To: <278BADDE17C67F56F230ACD4@ninevah.cyrusoft.com>
Message-ID: <20041006165725.3678.93012.polymer@peirce.gestalt.entity.net>
X-Mailer: Infotrope Polymer/0.0.3
Date: Wed, 06 Oct 2004 17:57:25 +0100
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

On Wed Oct  6 17:19:30 2004, Cyrus Daboo wrote:
> --On Wednesday, October 6, 2004 4:40 PM +0100 Dave Cridland 
>  wrote:
> 
>> As for mbox-or-pat, I agree with Philip that there doesn't seem to 
>> be
>> much point - pipelining the LIST commands acheives the same goal 
>> in -
>> almost certainly - the same number of TCP packets, and only a small
>> increased data transfer cost.
> 
> That's not necessarily true - it depends on how large the 
> mbox-or-pat list is. Remember for each pipelined command, in 
> addition to the unsolicited responses there is always the tagged OK 
> - one for each command - and those do add overhead to the pipelined 
> approach that is not present in the single command approach.
> 
> 
Well, it does depend on the size of mbox-or-pat, and the contents, 
true.

It you have, say, twenty mailboxes you're tracking, and you use 
mbox-or-pat syntax to individually specify them, then you're saving 
quite a bit, I'll grant you. Also it makes a big difference whether 
the server flushes its output buffer on every command completion.


>> Moreover, it introduces extra complexity into the syntax, 
>> especially
>> because it introduces special handling of the empty list-mailbox - 
>> or
>> more accurately, special handling of the special handling... As
>> wonderfully ironic as that is, I can't see the point in persuing 
>> that.
>> 
>> Is there any implementor who really wants this syntax in?
> 
> I guess I was one person requesting it. As more and more people use 
> server-side filtering and plus-addressing techniques, users often 
> need to operate on 'discrete' sets of mailboxes - i.e. ones that 
> cannot be represented by a simple % or * LIST pattern. Being able 
> to get information on those sets in one go is useful. Really the 
> benefit of this comes if we look to potential extensions to LISTEXT 
> - e.g. being able to specify SEARCH criteria to do multi-mailbox 
> searches, or being able to request STATUS-like information.
> 
> However, at this point I wouldn't mind if we went back to just a 
> single list-mailbox syntax and left mbox-or-pat for a future 
> extension.

I'm not wildly against the syntax, I'm just not convinced it's 
actually needed right now.

Actually, I think the scenario you describe above could be better 
handled with arbitrary mailbox attributes - which, IIRC, ANNOTATEMORE 
introduces (Of course, you'd know that better than me). Then the 
client can simply define its mailbox sets on the server, effectively, 
by 'tagging' mailboxes, and then search for that tag, by using some 
ANNOTATEMORE+LISTEXT extension.

This also has the benefit that mailbox 'sets' can be standardized 
themselves, and made interoperable.

Dave.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96Gqb5E077020; Wed, 6 Oct 2004 09:52:37 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96Gqbgn077019; Wed, 6 Oct 2004 09:52:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GqaRV077011 for ; Wed, 6 Oct 2004 09:52:36 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Message-Id: <6HX949UaRSb7CKtb+zSNAQ.md5@libertango.oryx.com>
Date: Wed, 6 Oct 2004 18:53:12 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
Cc: Timo Sirainen , Dave Cridland 
References:  <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>  <20041006093514.3678.27139.polymer@peirce.gestalt.entity.net> 
In-Reply-To: 
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Timo Sirainen writes:
> On 6.10.2004, at 12:35, Dave Cridland wrote:
>
>>  A0004 LIST (SUBSCRIBED MATCHPARENT) "" "%"
>>  * LIST (\Subscribed) "/" "Fruit"
>>  * LIST () "/" "Veg" ((CHILDINFO (\Subscribed))
>>  A0004 OK
>
> I like this. Makes it very clear what was intended with it.

Agreed. This one's good.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GjTCg076172; Wed, 6 Oct 2004 09:45:29 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96GjTk7076171; Wed, 6 Oct 2004 09:45:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GjSfG076163 for ; Wed, 6 Oct 2004 09:45:28 -0700 (PDT) (envelope-from dave@cridland.net)
Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 30296154009; Wed,  6 Oct 2004 16:45:31 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline; xpolymertype="coverletter"
From: Dave Cridland 
To: Philip Guenther 
Cc: IMAP extensions Mailing List , Arnt Gulbrandsen 
Subject: Re: One command or several... 
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com>  <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net> <200410061616.i96GGDqS097315@lab.smi.sendmail.com>
In-Reply-To: <200410061616.i96GGDqS097315@lab.smi.sendmail.com>
Message-ID: <20041006164309.3678.28353.polymer@peirce.gestalt.entity.net>
X-Mailer: Infotrope Polymer/0.0.3
Date: Wed, 06 Oct 2004 17:43:09 +0100
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

On Wed Oct  6 17:16:13 2004, Philip Guenther wrote:
> 
> Dave Cridland  writes:
> >On Tue Oct  5 21:15:38 2004, Philip Guenther wrote:
> >> Arnt Gulbrandsen  writes:
> >> >AFAICT, there seems to be nothing mbox-or-pat and matchparent 
> can >> do >that cannot also be achieved using a series of simpler 
> list >> commands. >Correct?
> >> >> Yep.  Ditto for CHILDREN.
> >
> >Not exactly "Ditto", IMHO.
> 
> Given that you quoted my description of how a client can do CHILDREN
> with unextended LIST commands, I'm not sure what you mean by "Not
> exactly 'Ditto'"
> 
> 
Possibly a language issue: I read "Ditto" as meaning "Precisely the 
same".

I agreed with what you said, which implies that there is significant 
overhead in emulating CHILDREN by using multiple LISTs, unlike the 
mbox-or-pat syntax, for which the overhead is (I think) slight.

So "Ditto" is a little strong - it's possible to workaround the 
missing data, but it's definitely a workaround, unlike working around 
lack of mbox-or-pat, which is virtually no overhead at all, and 
produces precisely the same results for *almost* precisely the same 
data transfer.


> <...>
> >> Duplicating matchparent on the client side is even worse, as to 
> get
> >> placeholder info you have to add "*" to the end of the original
> >> pattern.
> >
> >% rather than *, presumably, but I largely agree with you, and the 
> >argument in general.
> 
> If you think that adding "%" (or "/%") to the end of a list command
> will get you matchparent info, then you forgot that \placeholder
> is returned if _any_ children are selected, even ones multiple
> levels of hierarchy down:

Yep, that had slipped my mind. Or at least, it had when I wrote 
that...

This further suggests that MATCHPARENT/CHILDREN are not exactly a 
"Ditto", see above. :-)


> 
> >Moreover, it introduces extra complexity into the syntax, 
> especially >because it introduces special handling of the empty 
> list-mailbox - or >more accurately, special handling of the special 
> handling... As >wonderfully ironic as that is, I can't see the 
> point in persuing that.
> 
> Even if multiple patterns are removed, the empty pattern will have
> to be mentioned to say what happens if you use options with 
> it...even
> if all it was to say was "the behavior of the empty pattern is
> unspecified if list options are used".

Not really. It's specified per-option, if at all. In principle, an 
empty pattern used with REMOTE could tell you whether the entire 
heirarchy was rooted remotely or not, for instance - that's 
potentially useful information.

Dave.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GgYxQ075944; Wed, 6 Oct 2004 09:42:34 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96GgYCP075943; Wed, 6 Oct 2004 09:42:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GgX6Y075898 for ; Wed, 6 Oct 2004 09:42:33 -0700 (PDT) (envelope-from tss@iki.fi)
Received: by danu.procontrol.fi (Postfix, from userid 106) id 046221C350C9; Wed,  6 Oct 2004 19:42:25 +0300 (EEST)
Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 1F6371C27E5D; Wed,  6 Oct 2004 19:42:20 +0300 (EEST)
In-Reply-To: <20041006093514.3678.27139.polymer@peirce.gestalt.entity.net>
References:  <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>  <20041006093514.3678.27139.polymer@peirce.gestalt.entity.net>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-46-662137989"
Message-Id: 
Content-Transfer-Encoding: 7bit
Cc: , Arnt Gulbrandsen 
From: Timo Sirainen 
Subject: Re: listext: some things I can't understand
Date: Wed, 6 Oct 2004 19:42:18 +0300
To: Dave Cridland 
X-Pgp-Agent: GPGMail 1.0.2
X-Mailer: Apple Mail (2.619)
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on danu.procontrol.fi
X-Spam-Level: 
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham  version=2.63
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--Apple-Mail-46-662137989
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 6.10.2004, at 12:35, Dave Cridland wrote:

> A0004 LIST (SUBSCRIBED MATCHPARENT) "" "%"
> * LIST (\Subscribed) "/" "Fruit"
> * LIST () "/" "Veg" ((CHILDINFO (\Subscribed))
> A0004 OK

I like this. Makes it very clear what was intended with it.

> A0005 LIST (SUBSCRIBED) "" "%" RETURN (CHILDREN)
> * LIST (\Subscribed) "/" "Fruit" (CHILDREN (\HasNoChildren))
> * LIST () "/" "Veg" (CHILDREN (\HasChildren \Subscribed))
> A0006 OK

\HasChildren and \HasNoChildren seems redundant here.

> Assuming that this syntax existed, would this:
> a) Remove the confusion over MATCHPARENT / \PlaceHolder / 
> \HasSubmailboxes ?

Yes, \PlaceHolder and \HasSubmailboxes could be dropped entirely then I 
think.

> b) Solve Philip's problem of parsing unsolicited responses (and Arnt's 
> problem of treating all responses as unsolicited.)?

I think this is the first solution where it would be easy for clients 
to parse mixed solicited/unsolicited LIST replies.

--Apple-Mail-46-662137989
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBZCBqyUhSUUBViskRAk0KAJ9HpLQXPLMpPEEv5pPLDc8ldA6eBQCfbpGX
yyUCykPEvqOuTb8G8MYHtWI=
=ei6l
-----END PGP SIGNATURE-----

--Apple-Mail-46-662137989--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GKBMc073951; Wed, 6 Oct 2004 09:20:11 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96GKBVj073950; Wed, 6 Oct 2004 09:20:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GKBNb073944 for ; Wed, 6 Oct 2004 09:20:11 -0700 (PDT) (envelope-from daboo@isamet.com)
Received: from ninevah.cyrusoft.com (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id i96Fu0o3006116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2004 11:56:01 -0400
Date: Wed, 06 Oct 2004 12:19:30 -0400
From: Cyrus Daboo 
To: Dave Cridland , Philip Guenther 
cc: IMAP extensions Mailing List , Arnt Gulbrandsen 
Subject: Re: One command or several... 
Message-ID: <278BADDE17C67F56F230ACD4@ninevah.cyrusoft.com>
In-Reply-To: <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net>
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com> <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net>
X-Mailer: Mulberry/4.0.0d1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Hi Dave,

--On Wednesday, October 6, 2004 4:40 PM +0100 Dave Cridland 
 wrote:

> As for mbox-or-pat, I agree with Philip that there doesn't seem to be
> much point - pipelining the LIST commands acheives the same goal in -
> almost certainly - the same number of TCP packets, and only a small
> increased data transfer cost.

That's not necessarily true - it depends on how large the mbox-or-pat list 
is. Remember for each pipelined command, in addition to the unsolicited 
responses there is always the tagged OK - one for each command - and those 
do add overhead to the pipelined approach that is not present in the single 
command approach.

> Moreover, it introduces extra complexity into the syntax, especially
> because it introduces special handling of the empty list-mailbox - or
> more accurately, special handling of the special handling... As
> wonderfully ironic as that is, I can't see the point in persuing that.
>
> Is there any implementor who really wants this syntax in?

I guess I was one person requesting it. As more and more people use 
server-side filtering and plus-addressing techniques, users often need to 
operate on 'discrete' sets of mailboxes - i.e. ones that cannot be 
represented by a simple % or * LIST pattern. Being able to get information 
on those sets in one go is useful. Really the benefit of this comes if we 
look to potential extensions to LISTEXT - e.g. being able to specify SEARCH 
criteria to do multi-mailbox searches, or being able to request STATUS-like 
information.

However, at this point I wouldn't mind if we went back to just a single 
list-mailbox syntax and left mbox-or-pat for a future extension.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GHiSQ073672; Wed, 6 Oct 2004 09:17:44 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96GHi41073671; Wed, 6 Oct 2004 09:17:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96GHinH073665 for ; Wed, 6 Oct 2004 09:17:44 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.6) with ESMTP id i96GGF6i029763 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 6 Oct 2004 09:16:18 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i96GGF6i029763
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=m520JHjkuHGirDx+P8XL204/lybyYVkeEh37Umcv1kAV4KqI172PHE01FjEIjfOvk W4yPiuESxgam4EzKuI9bIhEnBQ2eectsbJmyxvUv3j5WErkf0PHM3P3M4htny1qaUl8 5l4fm9yYUfYhCvtum5YZVIH0Yd7laKmAfw1IQ7U=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i96GGDqS097315; Wed, 6 Oct 2004 09:16:13 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410061616.i96GGDqS097315@lab.smi.sendmail.com>
To: Dave Cridland 
From: Philip Guenther 
Cc: IMAP extensions Mailing List , Arnt Gulbrandsen 
Subject: Re: One command or several... 
In-reply-to: <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net> 
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com>  <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net> 
Date: Wed, 06 Oct 2004 09:16:13 -0700
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Dave Cridland  writes:
>On Tue Oct  5 21:15:38 2004, Philip Guenther wrote:
>> Arnt Gulbrandsen  writes:
>> >AFAICT, there seems to be nothing mbox-or-pat and matchparent can 
>> do >that cannot also be achieved using a series of simpler list 
>> commands. >Correct?
>> 
>> Yep.  Ditto for CHILDREN.
>
>Not exactly "Ditto", IMHO.

Given that you quoted my description of how a client can do CHILDREN
with unextended LIST commands, I'm not sure what you mean by "Not
exactly 'Ditto'"

<...>
>> Duplicating matchparent on the client side is even worse, as to get
>> placeholder info you have to add "*" to the end of the original
>> pattern.
>
>% rather than *, presumably, but I largely agree with you, and the 
>argument in general.

If you think that adding "%" (or "/%") to the end of a list command
will get you matchparent info, then you forgot that \placeholder
is returned if _any_ children are selected, even ones multiple
levels of hierarchy down:
	10 LIST "" * RETURN (SUBSCRIBED)
	* LIST (\NoInferiors \Subscribed) "/" INBOX
	* LIST (\Subscribed) "/" bar/blip
	* LIST () "/" foo
	* LIST () "/" foo/bar
	* LIST (\Subscribed) "/" foo/bar/baz
	* LIST (\Subscribed) "/" quux
	10 OK Completed
	11 LIST (SUBSCRIBED MATCHPARENT) "" %
	* LIST (\NoInferiors \Subscribed) "/" INBOX
	* LIST (\NonExistent \PlaceHolder \HasChildren) "/" bar
	* LIST (\PlaceHolder \HasChildren) "/" foo
	* LIST (\Subscribed) "/" quux
	11 OK Completed
	12 LIST (SUBSCRIBED) "" %
	* LIST (\NoInferiors \Subscribed) "/" INBOX
	* LIST (\Subscribed) "/" quux
	12 OK Completed
	13 LIST (SUBSCRIBED) "" %/%                                         
	* LIST (\Subscribed) "/" bar/blip
	13 OK Completed

Neither of those last two returned anything to indicate that "foo"
has a subscribed mailbox below it.


Without matchparent in some form, there is no way to both efficiently
and completely list subscribed folders by hierarchical level.  Wave
goodbye to '%', say hello to '*'.  (The special handling of \Noselect
in LSUB was put there for a reason, folks!)



>Moreover, it introduces extra complexity into the syntax, especially 
>because it introduces special handling of the empty list-mailbox - or 
>more accurately, special handling of the special handling... As 
>wonderfully ironic as that is, I can't see the point in persuing that.

Even if multiple patterns are removed, the empty pattern will have
to be mentioned to say what happens if you use options with it...even
if all it was to say was "the behavior of the empty pattern is
unspecified if list options are used".


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96G5xUM072286; Wed, 6 Oct 2004 09:05:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96G5xNT072285; Wed, 6 Oct 2004 09:05:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96G5sf6072273 for ; Wed, 6 Oct 2004 09:05:54 -0700 (PDT) (envelope-from dave@cridland.net)
Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id AFA3B154009; Wed,  6 Oct 2004 16:05:56 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline; xpolymertype="coverletter"
From: Dave Cridland 
To: Arnt Gulbrandsen 
Cc: 
Subject: Re: One command or several...
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com> <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net> 
In-Reply-To: 
Message-ID: <20041006160334.3678.58915.polymer@peirce.gestalt.entity.net>
X-Mailer: Infotrope Polymer/0.0.3
Date: Wed, 06 Oct 2004 17:03:34 +0100
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

On Wed Oct  6 16:51:09 2004, Arnt Gulbrandsen wrote:
> Dave Cridland writes:
>> Worth noting that the existing CHILDREN extension, 3348, doesn't 
>> help ascertain whether clients are actually using it or not, so 
>> Arnt's suggestion that it's little used is difficult to assert. 
>> FWIW, a quick survey of IMAP clients on my machine suggested:
> 
> I did not mean to suggest so, and apologize for any 
> misunderstanding. I can easily imagine that RFC 3348 is fairly 
> widely used - it's easy for a client, and often comes in handy.
> 
> I believe I was trying to talk about matchparent's likelihood of 
> seeing wide use.

Ah... Sorry, I mentally lump them together. To me, they're the same 
functionality, but with different filters. (I'm thinking in terms of 
performing something like 'tag LIST "" "%" RETURN (REMOTE SUBSCRIBED 
CHILDREN)' as my 'usual' list command.)

FWIW, looks like I was wrong about Thunderbird - I can't find any 
evidence of it handling RFC3348, and it looks from 
http://lxr.mozilla.org/mozilla1.7/source/mailnews/imap/src/nsImapServerResponseParser.cpp#865 
as if it doesn't, to me.

Dave.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96Fohoo070277; Wed, 6 Oct 2004 08:50:43 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96FohS1070276; Wed, 6 Oct 2004 08:50:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [212.125.101.207]) by above.proper.com (8.12.11/8.12.9) with SMTP id i96Fof0l070269 for ; Wed, 6 Oct 2004 08:50:42 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Received: by kalyani.oryx.com (Postfix, from userid 1005) id 6A6901BDE88; Wed,  6 Oct 2004 17:50:43 +0200 (CEST)
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by kalyani.oryx.com (Postfix) with SMTP id C92551BDE7F; Wed,  6 Oct 2004 17:50:41 +0200 (CEST)
Message-Id: 
Date: Wed, 6 Oct 2004 17:51:09 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: One command or several...
Cc: Philip Guenther , Dave Cridland 
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com> <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net>
In-Reply-To: <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Dave Cridland writes:
> Worth noting that the existing CHILDREN extension, 3348, doesn't help 
> ascertain whether clients are actually using it or not, so Arnt's 
> suggestion that it's little used is difficult to assert. FWIW, a 
> quick survey of IMAP clients on my machine suggested:

I did not mean to suggest so, and apologize for any misunderstanding. I 
can easily imagine that RFC 3348 is fairly widely used - it's easy for 
a client, and often comes in handy.

I believe I was trying to talk about matchparent's likelihood of seeing 
wide use.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96FgWWS068981; Wed, 6 Oct 2004 08:42:32 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96FgWR6068980; Wed, 6 Oct 2004 08:42:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96FgVnJ068973 for ; Wed, 6 Oct 2004 08:42:31 -0700 (PDT) (envelope-from dave@cridland.net)
Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id 6D691154009; Wed,  6 Oct 2004 15:42:33 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline; xpolymertype="coverletter"
From: Dave Cridland 
To: Philip Guenther 
Cc: IMAP extensions Mailing List , Arnt Gulbrandsen 
Subject: Re: One command or several... 
References: <200410052015.i95KFcmx016253@lab.smi.sendmail.com>
In-Reply-To: <200410052015.i95KFcmx016253@lab.smi.sendmail.com>
Message-ID: <20041006154011.3678.64504.polymer@peirce.gestalt.entity.net>
X-Mailer: Infotrope Polymer/0.0.3
Date: Wed, 06 Oct 2004 16:40:11 +0100
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

On Tue Oct  5 21:15:38 2004, Philip Guenther wrote:
> 
> Arnt Gulbrandsen  writes:
> >AFAICT, there seems to be nothing mbox-or-pat and matchparent can 
> do >that cannot also be achieved using a series of simpler list 
> commands. >Correct?
> 
> Yep.  Ditto for CHILDREN.

Not exactly "Ditto", IMHO.


> >If so, why? It seems to make life harder for servers just in case 
> a >client ever uses it. That sort of thing is a good tradeoff if 
> many >clients will use it, something I find hard to believe in this 
> >particular case.
> 
> The argument is that for some of the info, the server can do the 
> test
> much more efficiently than the client.  For example, the children 
> info
> can be obtained by a client by doing  for each 
> name
> returned by the previous command; if the client just wants the 
> boolean
> "has some/no children", then listing all the children is way 
> overkill.
> 
> Duplicating matchparent on the client side is even worse, as to get
> placeholder info you have to add "*" to the end of the original
> pattern.

% rather than *, presumably, but I largely agree with you, and the 
argument in general.

In addition, the use of multiple LIST commands in this case 
introduces a higher latency, as you've at least two round-trips to 
wait.

Worth noting that the existing CHILDREN extension, 3348, doesn't help 
ascertain whether clients are actually using it or not, so Arnt's 
suggestion that it's little used is difficult to assert. FWIW, a 
quick survey of IMAP clients on my machine suggested:

Evolution (Ximian): Apparently recognizes RFC3348 (based on output of 
strings)
Balsa: Likewise.
mutt: Appears to recognize \HasNoChildren, but treats it equivalently 
with \NoInferiors. (Whether that means it treats \NoInferiors as 
\HasNoChildren ought to be treated, or the other way around, I have 
no idea.) Checked by reading source.
Mine handles it fine. (And in fact assumes there are children unless 
told otherwise, and removes the "child" flag if subsequent expansion 
proves there are none, so it's actually ignoring \HasChildren, and 
only using \HasNoChildren and \NoInferiors.)

I read, but haven't checked, that Thunderbird and Apple's Mail 
program both support it - I couldn't actually find any evidence of 
Thunderbird supporting it from "strings", though, but Google 
suggested that Thunderbird fails to find submailboxes if \HasChildren 
isn't present in some versions... (Even when the server isn't 
advertising CHILDREN)

I'm guessing that Outlook and Outlook Express support it, given that 
it's a Microsoft initiated standard.

This suggests quite widespread use of the information, but not always 
correctly.


As for mbox-or-pat, I agree with Philip that there doesn't seem to be 
much point - pipelining the LIST commands acheives the same goal in - 
almost certainly - the same number of TCP packets, and only a small 
increased data transfer cost.

Moreover, it introduces extra complexity into the syntax, especially 
because it introduces special handling of the empty list-mailbox - or 
more accurately, special handling of the special handling... As 
wonderfully ironic as that is, I can't see the point in persuing that.

Is there any implementor who really wants this syntax in?

Dave.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i969bekV008407; Wed, 6 Oct 2004 02:37:40 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i969beSU008405; Wed, 6 Oct 2004 02:37:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i969bZMD008363 for ; Wed, 6 Oct 2004 02:37:36 -0700 (PDT) (envelope-from dave@cridland.net)
Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id BEAE6154009; Wed,  6 Oct 2004 09:37:35 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline; xpolymertype="coverletter"
From: Dave Cridland 
To: Arnt Gulbrandsen 
Cc: 
Subject: Re: listext: some things I can't understand
References:  <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net> 
In-Reply-To: 
Message-ID: <20041006093514.3678.27139.polymer@peirce.gestalt.entity.net>
X-Mailer: Infotrope Polymer/0.0.3
Date: Wed, 06 Oct 2004 10:35:14 +0100
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Since we're in a mood to try new syntaxes again...

On Tue Oct  5 18:24:50 2004, Arnt Gulbrandsen wrote:
> 
> I understand now why some of this is so hard on my brain: Part of 
> the listext response is about the mailboxes, and another part is 
> about the command.
> 
> My gut feeling is that IMAP works best when untagged responses can 
> be parsed independently of the command that caused them. This is 
> not currently the case for listext.
> 
> 
Agreed. As I was writing my last confused missive, I "got" what 
Philip has been saying, largely.


> Dave Cridland writes:
>> My head hurts quite a bit with some of the subtleties, too.
> 
> I'm sad to hear that. Makes it seem even less likely that clients 
> authors will be able to make use of this stuff.
> 
> 
Bear in mind I'm a client author of little brain. On the other hand, 
most IMAP client authors are.

> In fact, this requires an addition to RFC 3501 section 5.5, 
> specifying that two list commands cannot be issued concurrently 
> when one uses matchparent.
> 
> 
There's an argument here for proposing that extended LIST commands 
should actually have tagged intermediates, like ACAP does. (Actually, 
having them in lots of places would be handy. Perhaps a 
command-a-like similar to UID would be handy here.)

The trouble is that I suspect this'd really confuse a lot of existing 
parsers. (Depends on whether you look at the response or the tag 
first. If you look at the tag, see it's not "*", and assume command 
completion, you'd have a rewrite on your hands. My parser does not, 
because it's written around ACAP as well.)

So while I'd personally love to see tagged intermediates for LIST and 
SEARCH/SORT/THREAD, I doubt it'd be popular.

>> \Placeholder makes sense to me. It implies that *this* mailbox 
>> doesn't match the criteria, but has inferior mailboxes that do.
> ...
>> \HasSubmailboxes I find excessively confusing - it implies that 
>> this mailbox *does* match, but also that there are child mailboxes 
>> that, well, might. I would expect that a server should only return 
>> this when there *is* a child mailbox which matches the selection 
>> options, although potentially not the pattern[s].
> 
> These are the two that confused me so much. Still do, but now I 
> know why: Because they're not actually attributes of the mailbox, 
> they're attributes of the search being processed.

Yeah, \HasSubmailboxes is really \AlsoHasMatchingSubmailboxes.

So, alternative strategy:

For an extended LIST, we stick the child mailbox information 
somewhere else:

Given:

A0002 LIST "" "*"
* LIST () "/" "Fruit"
* LIST () "/" "Veg"
* LIST () "/" "Veg/Cabbage"
A0002 OK

And:

A0003 LIST "" "*" RETURN (SUBSCRIBED)
* LIST (\Subscribed) "/" "Fruit"
* LIST () "/" "Veg"
* LIST (\Subscribed) "/" "Veg/Cabbage"
A0003 OK

Then we could do:

A0004 LIST (SUBSCRIBED MATCHPARENT) "" "%"
* LIST (\Subscribed) "/" "Fruit"
* LIST () "/" "Veg" ((CHILDINFO (\Subscribed))
A0004 OK

The last tagged response can be parsed independently of the child. 
I've stuck with MATCHPARENT, but this could be, arguably, a RETURN 
(CHILDINFO) instead.

You could even:

A0005 LIST (SUBSCRIBED) "" "%" RETURN (CHILDREN)
* LIST (\Subscribed) "/" "Fruit" (CHILDREN (\HasNoChildren))
* LIST () "/" "Veg" (CHILDREN (\HasChildren \Subscribed))
A0006 OK

Again, this is semantically understandable outside of the command, I 
think, and means:

* LIST {A subscribed mailbox called "Fruit", which has no children.}
* LIST {An unsubscribed mailbox called "Veg", which has children, 
some of which are subscribed.}

Assuming that this syntax existed, would this:
a) Remove the confusion over MATCHPARENT / \PlaceHolder / 
\HasSubmailboxes ?
b) Solve Philip's problem of parsing unsolicited responses (and 
Arnt's problem of treating all responses as unsolicited.)?

Dave.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95LrOiO061454; Tue, 5 Oct 2004 14:53:24 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95LrOY8061453; Tue, 5 Oct 2004 14:53:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95LrNjm061443 for ; Tue, 5 Oct 2004 14:53:23 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.6) with ESMTP id i95LrF03013219 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 5 Oct 2004 14:53:15 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i95LrF03013219
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=AAIQyN8FL68A6usWsj8DDzx2x9iLvDGYri0Tx7c8p829PSl//JYeoLZYZbhyv1EFX fbl/unyq1iF1cwcvyhwfVHYFFEZ4hfY73Sld00bYlCSqdbEwOoD7y7I3oRvy+SnkhPQ mBar9o8oHKAajMsWg9QOb2V+Y0VQKdUvdlU95+Y=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i95LrFEx023504; Tue, 5 Oct 2004 14:53:15 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410052153.i95LrFEx023504@lab.smi.sendmail.com>
To: Timo Sirainen 
Cc: IMAP Extensions WG 
From: Philip Guenther 
Subject: Re: Listext 
In-reply-to: <21665028-1708-11D9-B9A0-000393CC2E90@iki.fi> 
References: <21665028-1708-11D9-B9A0-000393CC2E90@iki.fi> 
Date: Tue, 05 Oct 2004 14:53:15 -0700
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Timo Sirainen  writes:
>>Note that return options MUST NOT cause the server to report
>>information about additional mailbox names. If the client has not
>>specified any return option, only information about attributes should
>>be returned by the server.
>
>I don't understand at all what this is trying to say.

The first sentence says that adding a return option (e.g., CHILDREN)
can't make the server return more responses than it would without the
return option.  Adding a return option can only affect the flags
included in the responses.

The second sentence is trying to say that if you don't specify any
return options, the server should still send the stuff that it would
have for unextended LIST, such as \noselect, \noinferiors, \marked,
etc.


> >   The server MAY return data in the extended fields that was not 
>solicited
> >   by the client. The client MUST ignore all extended fields it doesn't
> >   recognize.
>
>But only after client has indicated it supports LISTEXT by sending 
>extended LIST command?

Hmm, yeah, the server should be forbidden from sending extended
information until the client does something to indicate it understands
the syntax, be it an extended LIST command or some other extension that
documents that it may trigger extended information.

...
>>However, absence of both \PlaceHolder and \HasSubMailboxes doesn't
>>tell whether there are any children that meet the selection criteria
>>and match the canonical LIST pattern.
>
>How about changing the last sentence to something like:
>
>However the mailbox may still have children that match the selection 
>criteria and canonical LIST pattern, they are then guaranteed to be 
>returned in a different LIST response so \HasSubMailboxes isn't needed.

Change the comma to a semicolon, and change "needed" to "required" and
it looks right.


...
>I'd actually recommend changing the meaning of \PlaceHolder to simply 
>mean that the mailbox didn't match the selection criteria and it's 
>listed there for some other reason. There would be two reasons:
>
>1) It also contains \HasSubMailboxes flag
>
>2) All unilateral LIST responses sent by server would have that flag, 
>which would make it easy for clients to detect.
>
>Their names could then be:
>
>\PlaceHolder -> \UnMatched
>\HasSubMailboxes -> \ChildMatched

Those should be something like \NotSelected and \ChildSelected, because
the named mailboxes _does_ match the pattern and the child(ren) in
question _doesn't_ match the pattern but _is_ selected.

So, you're suggesting approximately:

OLD			NEW
-----------------------------------------------------------
\HasSubMailboxes	\ChildSelected			(1)
\PlaceHolder		\ChildSelected \NotSelected	(2)

(1) named mailbox is both matched and selected, there exists a child
    that's selected
(2) named mailbox is matched but not selected, there exists a child
    that's selected


Do people find this easier to understand?

(I'm not convinced the "all unilateral LIST responses need flag '\foo'"
idea is a wise path to follow, partly because it's a change in the
'social contract' and partly because someone will try to extend the idea
to other types of server responses, which I think is a Bad Idea.)


...
>I find the MATCHPARENT naming a bit strange too, to me it seems more 
>like it's matching children, especially in \HasSubmailboxes case.

The child is _not_ matched (by the pattern), but rather meets the
selection criterium.


>Is \PlaceHolder LIST replies required at all if MATCHPARENT isn't 
>given? ie. is this right:
>
>1 LIST (SUBSCRIBED) "" *
>* LIST (\Subscribed) "/" "box/subscribed"
>1 OK
>2 LIST (SUBSCRIBED) "" %
>2 OK
>3 LIST (SUBSCRIBED MATCHPARENT) "" %
>* LIST (\PlaceHolder) "/" box
>3 OK

That's correct.  The observant may note that LSUB is closest to  except you drop the \hassubmailboxes flag
and the normal \noselect flag and translate \placeholder to \noselect.


>Should something here be said also about the order in which LIST 
>replies may come from server? ie. is this allowed or not:
>
>* LIST () "/" foo/bar
>* LIST () "/" foo

It's allowed.  Neither the base-spec nor the LISTEXT draft state any
requirements on the server for sorting of LIST replies.  Any
specification of that would require a means for the client to specify a
comparator to handle the i18n aspect.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95KFeJ3049110; Tue, 5 Oct 2004 13:15:40 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95KFdcw049109; Tue, 5 Oct 2004 13:15:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95KFdRo049103 for ; Tue, 5 Oct 2004 13:15:39 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i95KFcag012401 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 5 Oct 2004 13:15:38 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i95KFcag012401
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=pQU/XUVvX4FuwQNo1tDErOO7DtRLkfrVlXaiZHQI8nWbCSfEqE3mOMAPVrrop2Dvu y0US8B8/vE5+1jI7gXX0tZnD48x1ql/t1Dqq6F1AlSYSiplUg3a+DV3MsEVMTj45YJh GZyXo3ScC8Zd8qWBxdupyUgrZa6bEU1oiPr22Mw=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i95KFcmx016253; Tue, 5 Oct 2004 13:15:38 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410052015.i95KFcmx016253@lab.smi.sendmail.com>
From: Philip Guenther 
To: Arnt Gulbrandsen 
cc: IMAP extensions Mailing List 
Subject: Re: One command or several... 
Date: Tue, 05 Oct 2004 13:15:38 -0700
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Arnt Gulbrandsen  writes:
>AFAICT, there seems to be nothing mbox-or-pat and matchparent can do 
>that cannot also be achieved using a series of simpler list commands. 
>Correct?

Yep.  Ditto for CHILDREN.


>If so, why? It seems to make life harder for servers just in case a 
>client ever uses it. That sort of thing is a good tradeoff if many 
>clients will use it, something I find hard to believe in this 
>particular case.

The argument is that for some of the info, the server can do the test
much more efficiently than the client.  For example, the children info
can be obtained by a client by doing  for each name
returned by the previous command; if the client just wants the boolean
"has some/no children", then listing all the children is way overkill.

Duplicating matchparent on the client side is even worse, as to get
placeholder info you have to add "*" to the end of the original
pattern.


As for the multiple pattern bit, well, I can't say I'm completely
convinced that it should be there.  Indeed, my implementation** simply
does each pattern one after the other with no duplicate suppression.


Philip Guenther

** if you want to throw some commands at a server implementing draft-10,
   fire me a note.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95KET81049020; Tue, 5 Oct 2004 13:14:29 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95KETRa049019; Tue, 5 Oct 2004 13:14:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95KETxj049009 for ; Tue, 5 Oct 2004 13:14:29 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i95KEMit012021 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 5 Oct 2004 13:14:22 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i95KEMit012021
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=s6KdiIYi7EXzNwDuxHZoXYIOuPpxZK4I03/XPIEJ/PxdND3fx7rdgvT1z2nJw379Z My3DV8FbPzNmr4L1Ov5P2QSK/X5NyoU2JvnD/xFV5f3upa4YwcHP+beHRl5EfpoBqEt mekGOezJHvWrXuyupowP4NxhnEc+XIgEX311XiM=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i95KELo8015900; Tue, 5 Oct 2004 13:14:22 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410052014.i95KELo8015900@lab.smi.sendmail.com>
To: Arnt Gulbrandsen 
Cc: IMAP extensions Mailing List 
Subject: Re: One command or several... 
In-reply-to:  
References:  
Date: Tue, 05 Oct 2004 13:14:21 -0700
From: Philip Guenther 
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Arnt Gulbrandsen  writes:
>AFAICT, there seems to be nothing mbox-or-pat and matchparent can do 
>that cannot also be achieved using a series of simpler list commands. 
>Correct?

Yep.  Ditto for CHILDREN.


>If so, why? It seems to make life harder for servers just in case a 
>client ever uses it. That sort of thing is a good tradeoff if many 
>clients will use it, something I find hard to believe in this 
>particular case.

The argument is that for some of the info, the server can do the test
much more efficiently than the client.  For example, the children info
can be obtained by a client by doing  for each name
returned by the previous command; if the client just wants the boolean
"has some/no children", then listing all the children is way overkill.

Duplicating matchparent on the client side is even worse, as to get
placeholder info you have to add "*" to the end of the original
pattern.


As for the multiple pattern bit, well, I can't say I'm completely
convinced that it should be there.  Indeed, my implementation** simply
does each pattern one after the other with no duplicate suppression.


Philip Guenther

** if you want to throw some commands at a server implementing draft-10,
   fire me a note.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Jr2k3047408; Tue, 5 Oct 2004 12:53:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95Jr2UT047407; Tue, 5 Oct 2004 12:53:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Jr0ci047388 for ; Tue, 5 Oct 2004 12:53:01 -0700 (PDT) (envelope-from tss@iki.fi)
Received: by danu.procontrol.fi (Postfix, from userid 106) id EAFE81C35337; Tue,  5 Oct 2004 22:52:52 +0300 (EEST)
Received: from [192.168.10.217] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id E97141C3531B for ; Tue,  5 Oct 2004 22:52:47 +0300 (EEST)
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <21665028-1708-11D9-B9A0-000393CC2E90@iki.fi>
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-27-587166595"
To: IMAP Extensions WG 
From: Timo Sirainen 
Subject: Listext
Date: Tue, 5 Oct 2004 22:52:47 +0300
X-Pgp-Agent: GPGMail 1.0.2
X-Mailer: Apple Mail (2.619)
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on danu.procontrol.fi
X-Spam-Level: 
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham  version=2.63
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--Apple-Mail-27-587166595
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

 > Note that return options MUST NOT cause the server to report
 >   information about additional mailbox names. If the client has not 
specified
 >   any return option, only information about attributes should be 
returned by
 >   the server.

I don't understand at all what this is trying to say.

 >   The server MAY return data in the extended fields that was not 
solicited
 >   by the client. The client MUST ignore all extended fields it doesn't
 >   recognize.

But only after client has indicated it supports LISTEXT by sending 
extended LIST command?

 >   When the MATCHPARENT selection option was specified by the client,
 >   the absence of both \PlaceHolder and \HasSubMailboxes means that the
 >   mailbox meets the selection criteria, but doesn't have any children 
that
 >   also meets the selection criteria and doesn't match the canonical 
LIST
 >   pattern. However, absence of both \PlaceHolder and \HasSubMailboxes 
doesn't
 >   tell whether there are any children that meet the selection 
criteria and
 >   match the canonical LIST pattern.

How about changing the last sentence to something like:

However the mailbox may still have children that match the selection 
criteria and canonical LIST pattern, they are then guaranteed to be 
returned in a different LIST response so \HasSubMailboxes isn't needed.

 >   The "\PlaceHolder" and the "\HasSubMailboxes" attributes are 
mutually
 >   exclusive.

I agree Dave's comment here that "mutually exclusive" is a bit 
confusing because they are quite similiar.

I'd actually recommend changing the meaning of \PlaceHolder to simply 
mean that the mailbox didn't match the selection criteria and it's 
listed there for some other reason. There would be two reasons:

1) It also contains \HasSubMailboxes flag

2) All unilateral LIST responses sent by server would have that flag, 
which would make it easy for clients to detect.

Their names could then be:

\PlaceHolder -> \UnMatched
\HasSubMailboxes -> \ChildMatched

Or actually, alternative to \PlaceHolder or \UnMatched would be to just 
return \Matched to all matched replies. Then server could keep sending 
old style LIST replies unilaterally without making it ambiguous to 
client that they are unilateral. Of course, it also means 8 bytes more 
for each requested LIST reply.

I find the MATCHPARENT naming a bit strange too, to me it seems more 
like it's matching children, especially in \HasSubmailboxes case.

Is \PlaceHolder LIST replies required at all if MATCHPARENT isn't 
given? ie. is this right:

1 LIST (SUBSCRIBED) "" *
* LIST (\Subscribed) "/" "box/subscribed"
1 OK
2 LIST (SUBSCRIBED) "" %
2 OK
3 LIST (SUBSCRIBED MATCHPARENT) "" %
* LIST (\PlaceHolder) "/" box
3 OK

 > 3.1. General principles for returning LIST responses

Are these a MUST? Especially the "don't return mailbox more than once" 
rule?

Should something here be said also about the order in which LIST 
replies may come from server? ie. is this allowed or not:

* LIST () "/" foo/bar
* LIST () "/" foo

--Apple-Mail-27-587166595
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBYvuPyUhSUUBViskRAjN/AJ4jco+WlqbYjfU6i0vEqa325JyIMgCfXLED
4JyAkwZjmI3ZEJ/YutOPNQA=
=tVOS
-----END PGP SIGNATURE-----

--Apple-Mail-27-587166595--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95JBCms043998; Tue, 5 Oct 2004 12:11:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95JBCqg043997; Tue, 5 Oct 2004 12:11:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95JB7KL043989 for ; Tue, 5 Oct 2004 12:11:07 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i95JB0WT024906 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 5 Oct 2004 12:11:01 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i95JB0WT024906
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=lroMjgHTf3TzMi7AMzj7peHWLdMRdghSw1lV8daSq2b/JhZhudOAV4SrnK98yOoDA c+C2xCZRo675fhMrfX0Uh3StK+BHC2R+Hk8k/kLZh8b6MstdpJhT9LIFiE7vQ0c/096 bR0aG51nf51/qd/VdtPdnfTg4Fip/KSJ+l+w/r0=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i95JB0cG011324; Tue, 5 Oct 2004 12:11:00 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410051911.i95JB0cG011324@lab.smi.sendmail.com>
To: Arnt Gulbrandsen 
Cc: ietf-imapext@imc.org
From: Philip Guenther 
Subject: Re: listext: some things I can't understand 
In-reply-to:  
References:  
Date: Tue, 05 Oct 2004 12:11:00 -0700
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Arnt Gulbrandsen  writes:
...
>1. The children return option. Isn't that a noop? The server may ignore 
>the option, and may (per RFC 3501/3348) send the \haschildren and 
>\hasnochildren attributes even if children isn't present. The 'then' 
>and 'else' parts of that test look more than a little similar to me.

I vaguely recall (but may be hallucinating) that someone proposed making
the CHILDREN option a separate capability with support implying that
when requested, every response would have \haschildren or
\hasnochildren.  Scanning the list archive, it appears that was
kinda-sorta decided against based on the fact that the current children
support (RFC 3348) doesn't have a capability associated with it, but
that doesn't make logical sense as _that_ decision stems from the lack
of a way to request the info.

Can anyone point to a reason for the decision to not make CHILDREN a
separate capability, perhaps a thread in the archive that I missed?


>2. The matchparent thingy. The draft goes to great lengths to describe 
>the difference betweeen \hassubmailboxes and \placeholder, and I have 
>problems understanding the point of either.

A quick summary of the history as I understand it: the MATCHPARENT
option and its flags stem from LSUB's odd-ball \noselect handling.
Initially, there was only \placeholder, modelled directly on LSUB's
\noselect: it would be returned if there was a selected child that
didn't match the pattern.

\hassubmailboxes came about after a discussion about whether LSUB could
and should return the same mailbox twice, once with \noselect and once
without, if the mailbox is subscribed and also has subscribed children
that don't match the pattern.  This was felt to be more confusing than
having a single flag that conveyed those bits in one response.



>What does \placeholder convey that \noselect \haschildren does not?

\placeholder does not imply that the mailbox cannot be the target of
SELECT.  It says that it doesn't meet the selection criteria, e.g., it
isn't subscribed.


>Why do we need both \nonexistent and \noselect?

So, overload \noselect to mean that the mailbox might not exist at all?
That's a question for the client authors.  Is the distinction useful
enough to them that servers need to make it?


>Why do we need all of \placeholder, \hassubmailboxes, \haschildren, 
>\hasnochildren and \noinferiors?

I asked this question (why both MATCHPARENT and CHILDREN?) at the San
Diego meeting and the response by the room was that they're both
useful.  Sure, but are they both useful enough to be worth inflicting on
every server?

Note that the _main_ difference between MATCHPARENT and CHILDREN is what
happens in the SUBSCRIBED case, as they would be practically the same in
the sans SUBSCRIBED case: if it wasn't directly banned by the draft,
	tag LIST (MATCHPARENT) ref pat
would be effectively the same as
	tag LIST ref pat RETURNS (CHILDREN)
in that you could derive the children flags from the matchparent flags
(of the lack there of).

So, they're redundant when SUBSCRIBED isn't used (or would if that ban
wasn't there).  That makes the main question, in my opinion, whether
they're both useful where they differ, in the SUBSCRIBED case.  CHILDREN
tells you whether the mailbox has submailboxes that exist, subscribed or
not; MATCHPARENT tells you whether the mailbox has submailboxes that are
subscribed, whether they exist or not.  I'm not a client maintainer, but
I would expect the latter to be significantly more useful than the
former.

Is there consensus that both these are useful enough to require server
support?  If not, let's pick one to require and one to completely drop.


>Oh, and why is the opposite of \noinferiors not called \inferiors?

\noinferiors	-> can't have children
\hasnochildren	-> can have children, but doesn't (..that you can see...)
(nothing)	-> can have children, may or may not
\haschildren	-> can have children, and does

Which of those would be \inferiors?

Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HOu7O034417; Tue, 5 Oct 2004 10:24:56 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95HOuHi034416; Tue, 5 Oct 2004 10:24:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95HOohT034392 for ; Tue, 5 Oct 2004 10:24:55 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 7E1271A6BC; Tue,  5 Oct 2004 19:24:53 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 1C5FF1A6C2 for ; Tue,  5 Oct 2004 19:24:51 +0200 (CEST)
Message-Id: 
Date: Tue, 5 Oct 2004 19:24:50 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
References:  <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>
In-Reply-To: <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i95HOuhT034411
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

I understand now why some of this is so hard on my brain: Part of the 
listext response is about the mailboxes, and another part is about the 
command.

My gut feeling is that IMAP works best when untagged responses can be 
parsed independently of the command that caused them. This is not 
currently the case for listext.

Dave Cridland writes:
> My head hurts quite a bit with some of the subtleties, too.

I'm sad to hear that. Makes it seem even less likely that clients 
authors will be able to make use of this stuff.

...
> \Placeholder implies that:
>
> 1) The mailbox *does* exist, but doesn't match the current criteria.
> 2) The mailbox has inferior mailboxes, some of which *do* match the 
> current selection criteria.

I see what you're saying now, but in order to make sense of it, I have 
to think in terms of a command. More like a tagged response than an 
untagged one.

In fact, this requires an addition to RFC 3501 section 5.5, specifying 
that two list commands cannot be issued concurrently when one uses 
matchparent.

>> Why do we need both \nonexistent and \noselect?
>
> Yeah, the difference is pretty subtle.
>
> Foo LIST "" "%"
> * LIST (\NoSelect) "/" "Stuff"
> Foo OK
>
> Bar LIST (SUBSCRIBED) "" "%"
> * LIST (\NonExistent \Subscribed) "/" "Other Stuff"
> Bar OK
>
> Neither Stuff nor Other Stuff exist. The difference is that a LIST of 
> "Stuff/%" is pretty likely to give some responses, since the node 
> exists in the mailbox heirarchy, as it were, whereas "Other Stuff/%" 
> won't - if it would do, it'd have been returned in the first list.
>
> FWIW, I rewrote these paragraphs several times with agreements that 
> one implied the other before I realised that they have subtly 
> different usages. I'm  still not entirely sure whether this is the 
> case, in fact.
>
> Would:
> * LIST (\NoSelect \Subscribed) "/" "Other Stuff"
>
> be interpretable any other way, for the Bar command above?

Optimism knows no bounds. A client author who trusts every server author 
to understand the subtleties perfectly could read from that response 
that Other Stuff might have child mailboxes.

This seems to be the same as your \nonexistent response above:

* LIST (\noselect \hasnochildren \subscribed) "/" "Other Stuff"

>> Why do we need all of \placeholder, \hassubmailboxes, \haschildren, 
>> \hasnochildren and \noinferiors? And even if there's justification, 
>> isn't it a little too subtle for J. Client Author?
>
> \Placeholder makes sense to me. It implies that *this* mailbox doesn't 
> match the criteria, but has inferior mailboxes that do.
...
> \HasSubmailboxes I find excessively confusing - it implies that this 
> mailbox *does* match, but also that there are child mailboxes that, 
> well, might. I would expect that a server should only return this 
> when there *is* a child mailbox which matches the selection options, 
> although potentially not the pattern[s].

These are the two that confused me so much. Still do, but now I know 
why: Because they're not actually attributes of the mailbox, they're 
attributes of the search being processed.

(Thanks, Barry and Dave.)

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Gs4BI030739; Tue, 5 Oct 2004 09:54:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95Gs4HK030738; Tue, 5 Oct 2004 09:54:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from gw2.gestalt.entity.net (dsl-217-155-137-62.zen.co.uk [217.155.137.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Grxpv030691 for ; Tue, 5 Oct 2004 09:53:59 -0700 (PDT) (envelope-from dave@cridland.net)
Received: from peirce (dsl-217-155-137-61.zen.co.uk [217.155.137.61]) by gw2.gestalt.entity.net (Postfix) with ESMTP id B0CB0154009; Tue,  5 Oct 2004 16:53:51 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline; xpolymertype="coverletter"
From: Dave Cridland 
To: Arnt Gulbrandsen 
Cc: 
Subject: Re: listext: some things I can't understand
References: 
In-Reply-To: 
Message-ID: <20041005165131.3678.63755.polymer@peirce.gestalt.entity.net>
X-Mailer: Infotrope Polymer/0.0.3
Date: Tue, 05 Oct 2004 17:51:31 +0100
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Hiya Arnt,

On Tue Oct  5 16:26:15 2004, Arnt Gulbrandsen wrote:
> 
> I like the ext part of listext. More flexible list command: good. 
> Forgetting that rlist and lsub exist: Highly desirable.
> 
> Some of the specific extensions are difficult for a small little 
> arnt to understand, though.
> 
> 
My head hurts quite a bit with some of the subtleties, too.


> 1. The children return option. Isn't that a noop? The server may 
> ignore the option, and may (per RFC 3501/3348) send the 
> \haschildren and \hasnochildren attributes even if children isn't 
> present. The 'then' and 'else' parts of that test look more than a 
> little similar to me.
> 
> 
It gets worse, actually. The server "MAY ignore" it, but "SHOULD 
return" the information, which seems to give me two levels of 
requirement for the same thing.

One thing that CHILDREN (The new and improved LISTEXT return option, 
I mean) gives me, the client author, is a way of saying "Look, I 
could do with this information, but don't sweat it, I can always 
issue another LIST to find out later." If you prefer, it's a useful 
method of being nice to the server.


> 2. The matchparent thingy. The draft goes to great lengths to 
> describe the difference betweeen \hassubmailboxes and \placeholder, 
> and I have problems understanding the point of either.
> 
> What does \placeholder convey that \noselect \haschildren does not?
> 
> 
\NoSelect \HasChildren implies that:

1) The mailbox cannot be the subject of a SELECT command - basically, 
it doesn't exist.
2) The mailbox has inferior mailboxes. It says nothing about whether 
those match the current selection criteria.

\Placeholder implies that:

1) The mailbox *does* exist, but doesn't match the current criteria.
2) The mailbox has inferior mailboxes, some of which *do* match the 
current selection criteria.


> Why do we need both \nonexistent and \noselect?
> 
> 
Yeah, the difference is pretty subtle.

Foo LIST "" "%"
* LIST (\NoSelect) "/" "Stuff"
Foo OK

Bar LIST (SUBSCRIBED) "" "%"
* LIST (\NonExistent \Subscribed) "/" "Other Stuff"
Bar OK

Neither Stuff nor Other Stuff exist. The difference is that a LIST of 
"Stuff/%" is pretty likely to give some responses, since the node 
exists in the mailbox heirarchy, as it were, whereas "Other Stuff/%" 
won't - if it would do, it'd have been returned in the first list.

FWIW, I rewrote these paragraphs several times with agreements that 
one implied the other before I realised that they have subtley 
different usages. I'm still not entirely sure whether this is the 
case, in fact.

Would:
* LIST (\NoSelect \Subscribed) "/" "Other Stuff"

be interpretable any other way, for the Bar command above?


> Why do we need all of \placeholder, \hassubmailboxes, \haschildren, 
> \hasnochildren and \noinferiors? And even if there's justification, 
> isn't it a little too subtle for J. Client Author?
> 
> 
\Placeholder makes sense to me. It implies that *this* mailbox 
doesn't match the criteria, but has inferior mailboxes that do.

\*Children merely indicate the mailbox definitely has, or definitely 
does not have, inferior mailboxes. It says nothing about whether they 
match the selection or not.

\HasSubmailboxes I find excessively confusing - it implies that this 
mailbox *does* match, but also that there are child mailboxes that, 
well, might. I would expect that a server should only return this 
when there *is* a child mailbox which matches the selection options, 
although potentially not the pattern[s].

Making \HasSubmailboxes and \Placeholder mutually exclusive confuses 
the hell out of me, to be honest - I'd expect \PlaceHolder to imply 
\HasSubmailboxes instead. (Flags already do imply one another, so no 
harm done.)

And finally, \NoInferiors implies an ongoing rule, not a current 
state.


> Oh, and why is the opposite of \noinferiors not called \inferiors?
> 
> 
There is no opposite to \NoInferiors. That would be called 
\InferiorsPossibleToCreateAndThereMightBeSomeAlready or something.


> This frustrates me. I guess you can tell. Some elucidation would be 
> great.
> 
> 
The above from my reading of the draft, not my reading of this list, 
and I'm certainly not any kind of authority.

Dave.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95GNHA8028562; Tue, 5 Oct 2004 09:23:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95GNHrf028561; Tue, 5 Oct 2004 09:23:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95GNDjU028546 for ; Tue, 5 Oct 2004 09:23:16 -0700 (PDT) (envelope-from leiba@watson.ibm.com)
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i95GMS787152 for ; Tue, 5 Oct 2004 12:22:28 -0400
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i95GN8s06178 for ; Tue, 5 Oct 2004 12:23:08 -0400
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/8.11.7-01-14-2004) with ESMTP id i95GN8O37692 for ; Tue, 5 Oct 2004 12:23:08 -0400
Received: from sig-9-65-66-241.mts.ibm.com ([9.65.66.241]) by mars.watson.ibm.com ID IMFd1096993387.1; Tue, 05 Oct 2004 12:23:07 -0400
Date: Tue, 05 Oct 2004 12:23:07 -0400
From: Barry Leiba 
To: ietf-imapext@imc.org
Subject: Re: listext: some things I can't understand
Message-ID: <69A380A06652B5882F6C0A69@[192.168.200.2]>
In-Reply-To: 
References:  
X-Mailer: Mulberry/3.1.6 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i95GNGjU028556
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

I'll address one question here:

> 1. The children return option. Isn't that a noop? The server may
> ignore the option, and may (per RFC 3501/3348) send the \haschildren
> and \hasnochildren attributes even if children isn't present.

Here's the background:
1. For some servers, this information is always avaliable, and costs
nothing to return, whether or not the client wants it.
2. For some servers, this information is expensive to provide, and they
don't want to provide it if the client doesn't want it.
3. Some clients want this information, and if the server doesn't
provide it they will get it with a multiplicity of LIST commands, the
sum of which is likely to be more expensive than the work to return the
information in the first place.

And so...
The return option is there for the client to tell the server that it
wants the information.  A server for which this information is trivial
to obtain may actually return it always, either way.  A server for
which this information is expensive to obtain may skip that expense if
the client doesn't ask for it.  A server whose implemementer does not
want to do the work can refuse to return it even if the client DOES ask
for it.  We strongly discourage this, but have left the choice there
because some people have objected to making "children" support required.

Those of us who want to require it claim that clients that want it will
use the required list commands to get it anyway, ultimately at greater
expense.  Still, it does require programming effort, and a server
developer may choose to spend that effort elsewhere.  Et voilą.

Barry

--
Barry Leiba, Pervasive Computing Technology  (leiba@watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95FgJZg024930; Tue, 5 Oct 2004 08:42:19 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95FgJF6024929; Tue, 5 Oct 2004 08:42:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95FgIPE024922 for ; Tue, 5 Oct 2004 08:42:19 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id C0B781A6C6; Tue,  5 Oct 2004 17:42:20 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 6CEB61A6BB for ; Tue,  5 Oct 2004 17:42:18 +0200 (CEST)
Message-Id: 
Date: Tue, 5 Oct 2004 17:42:17 +0200
From: Arnt Gulbrandsen 
To: IMAP extensions Mailing List 
Subject: One command or several...
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

AFAICT, there seems to be nothing mbox-or-pat and matchparent can do 
that cannot also be achieved using a series of simpler list commands. 
Correct?

If so, why? It seems to make life harder for servers just in case a 
client ever uses it. That sort of thing is a good tradeoff if many 
clients will use it, something I find hard to believe in this 
particular case.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95FQLZ7023210; Tue, 5 Oct 2004 08:26:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95FQLhf023209; Tue, 5 Oct 2004 08:26:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id i95FQKjL023185 for ; Tue, 5 Oct 2004 08:26:21 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 1992F1A6C1; Tue,  5 Oct 2004 17:26:18 +0200 (CEST)
Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id A20B41A6BA for ; Tue,  5 Oct 2004 17:26:15 +0200 (CEST)
Message-Id: 
Date: Tue, 5 Oct 2004 17:26:15 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: listext: some things I can't understand
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

I like the ext part of listext. More flexible list command: good. 
Forgetting that rlist and lsub exist: Highly desirable.

Some of the specific extensions are difficult for a small little arnt to 
understand, though.

1. The children return option. Isn't that a noop? The server may ignore 
the option, and may (per RFC 3501/3348) send the \haschildren and 
\hasnochildren attributes even if children isn't present. The 'then' 
and 'else' parts of that test look more than a little similar to me.

2. The matchparent thingy. The draft goes to great lengths to describe 
the difference betweeen \hassubmailboxes and \placeholder, and I have 
problems understanding the point of either.

What does \placeholder convey that \noselect \haschildren does not?

Why do we need both \nonexistent and \noselect?

Why do we need all of \placeholder, \hassubmailboxes, \haschildren, 
\hasnochildren and \noinferiors? And even if there's justification, 
isn't it a little too subtle for J. Client Author?

Oh, and why is the opposite of \noinferiors not called \inferiors?

This frustrates me. I guess you can tell. Some elucidation would be great.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94JjUkJ003119; Mon, 4 Oct 2004 12:45:30 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94JjUoT003118; Mon, 4 Oct 2004 12:45:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94JjThR003106 for ; Mon, 4 Oct 2004 12:45:29 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08582; Mon, 4 Oct 2004 15:45:30 -0400 (EDT)
Message-Id: <200410041945.PAA08582@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: i-d-announce@ietf.org
Cc: ietf-imapext@imc.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-10.txt
Date: Mon, 04 Oct 2004 15:45:30 -0400
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba, A. Melnikov
	Filename	: draft-ietf-imapext-list-extensions-10.txt
	Pages		: 10
	Date		: 2004-10-4
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions that have required specialized lists (see
[MboxRefer] for an example) we have had to expand the number of list
commands, since each extension must add its function to both LIST and
LSUB, and these commands are not, as they are defined, extensible.
If we've needed the extensions to work together, we've had to add a
set of commands to mix the different options, the set increasing in
size with each new extension.  This document describes an extension
to the base LIST command that will allow these additions to be done
with mutually compatible options to the LIST command, avoiding the
exponential increase in specialized list commands.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-10.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-list-extensions-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-list-extensions-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2004-10-4152621.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-list-extensions-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-list-extensions-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2004-10-4152621.I-D@ietf.org>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94Ftten046059; Mon, 4 Oct 2004 08:55:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94FttS3046058; Mon, 4 Oct 2004 08:55:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94Fttxu046052 for ; Mon, 4 Oct 2004 08:55:55 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i94Ftvj4027239 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 4 Oct 2004 08:55:57 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i94Ftvj4027239
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=WcteR8lYaBt3peF4Snh7jMLvKNL5gsnCooh9AZ11ONK0viIv/MIlyg8OOIbkblGsu 151rqf36TIWHszPhhZN8hVODuklSW5NjjxZBXN8EFDbsu3FMYMEFnZMvWhlJRMZ1XMj 9wePCSEYGb5Flsx5dGWaypGWF7Y5F9TgFi+LcFE=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i94FtvUu095801; Mon, 4 Oct 2004 08:55:57 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410041555.i94FtvUu095801@lab.smi.sendmail.com>
To: Alexey Melnikov 
Cc: IMAP Extensions WG 
From: Philip Guenther 
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09 
In-reply-to: <41616DC4.8080105@isode.com> 
References: <4140B37E.5000401@isode.com>  <200409130633.i8D6XMmj059087@lab.smi.sendmail.com> <4151B3B4.9090105@isode.com> <200409230341.i8N3f9gV048309@lab.smi.sendmail.com> <416049CF.8060905@isode.com> <200410041335.i94DZvIa086491@lab.smi.sendmail.com>  <41616DC4.8080105@isode.com> 
Date: Mon, 04 Oct 2004 08:55:56 -0700
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Alexey Melnikov  writes:
>Philip Guenther wrote:
...
>>** does an unsolicited "\Placeholder \Subscribed" response mean the
>>   named mailbox has subscribed submailboxes, or does it mean the named
>>   mailbox is subscribed and it has (possibly remote) submailboxes?
>>  
>>
>The former. The latter would be "\HasSubMailboxes \Subscribed" (or even 
>"\HasSubMailboxes \Subscribed" if CHILDREN was also specified).

Sorry, change my argument to consider "\Placeholder \Subscribed
\Nonexistent": that's a nonexistent mailbox that either
a) has subscribed submailboxes (), or
b) is itself subscribed and has (possibly remote) submailboxes
   ()

The same problem exists with "\Hassubmailboxes \Subscribed": it's not
clear from the response whether the \Hassubmailboxes means there's
subscribed submailboxes or simply submailboxes (possibly remote).


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94FZaYC044619; Mon, 4 Oct 2004 08:35:36 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94FZa7E044618; Mon, 4 Oct 2004 08:35:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94FZZkf044606 for ; Mon, 4 Oct 2004 08:35:35 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 4 Oct 2004 16:35:33 +0100
Message-ID: <41616DC4.8080105@isode.com>
Date: Mon, 04 Oct 2004 16:35:32 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Philip Guenther 
CC: IMAP Extensions WG 
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
References: <4140B37E.5000401@isode.com>  <200409130633.i8D6XMmj059087@lab.smi.sendmail.com> <4151B3B4.9090105@isode.com> <200409230341.i8N3f9gV048309@lab.smi.sendmail.com> 	<416049CF.8060905@isode.com> <200410041335.i94DZvIa086491@lab.smi.sendmail.com>
In-Reply-To: <200410041335.i94DZvIa086491@lab.smi.sendmail.com>
Content-Type: multipart/alternative; boundary="------------070508010502020303070906"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--------------070508010502020303070906
Content-type: text/plain; charset="us-ascii"

Philip Guenther wrote:

>Alexey Melnikov  writes:
>...
>  
>
>>As per off list discussion with Philip, I've changed the document to say 
>>that \PlaceHolder/\HasSubMailboxes is only allowed when MATCHPARENT is 
>>specified. In particular, this means that they are not allowed in LIST 
>>responses not caused by the latest LIST command.
>>
>>Philip's suggestion is that the server will send
>>"\Placeholder \Subscribed" in response to
>>.
>>This will mean "the mailbox is not really sibscribed, but the 
>>\Placeholder flag was caused by SUBSCRIBED selection option.
>>
>>IMHO, this seems to be overly complex. I think my change detailed above 
>>would suffice, however if WG members feel otherwise, I would like to 
>>hear their comments.
>>    
>>
>
>My suggestion was not really sufficient to completely remove the
>ambiguity of an unsolicited \Placeholder response**, so I support this
>change.
>
>
>Philip Guenther
>
>** does an unsolicited "\Placeholder \Subscribed" response mean the
>   named mailbox has subscribed submailboxes, or does it mean the named
>   mailbox is subscribed and it has (possibly remote) submailboxes?
>  
>
The former. The latter would be "\HasSubMailboxes \Subscribed" (or even 
"\HasSubMailboxes \Subscribed" if CHILDREN was also specified).

>   I.e., should the response be treated as if there was an outstanding
>    command or as if there was an
>   outstanding  ?
>   Either way, if the server sends that response right before the client
>   sends the LIST command that doesn't match what the server did, the
>   client will have no way of knowing that it should not treat that
>   \Placeholder in that LIST response as working under the selection
>   criteria that the client sent.
>  
>
Alexey


--------------070508010502020303070906
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit




  
  


Philip Guenther wrote:



  
Alexey Melnikov <Alexey.Melnikov@isode.com> writes:
...
  

  

    
As per off list discussion with Philip, I've changed the document to say 
that \PlaceHolder/\HasSubMailboxes is only allowed when MATCHPARENT is 
specified. In particular, this means that they are not allowed in LIST 
responses not caused by the latest LIST command.

Philip's suggestion is that the server will send
"\Placeholder \Subscribed" in response to
<LIST (SUBSCRIBED MATCHPARENT) "" "%">.
This will mean "the mailbox is not really sibscribed, but the 
\Placeholder flag was caused by SUBSCRIBED selection option.

IMHO, this seems to be overly complex. I think my change detailed above 
would suffice, however if WG members feel otherwise, I would like to 
hear their comments.
    

  

  

My suggestion was not really sufficient to completely remove the
ambiguity of an unsolicited \Placeholder response**, so I support this
change.


Philip Guenther

** does an unsolicited "\Placeholder \Subscribed" response mean the
   named mailbox has subscribed submailboxes, or does it mean the named
   mailbox is subscribed and it has (possibly remote) submailboxes?
  



The former. The latter would be "\HasSubMailboxes \Subscribed" (or even
"\HasSubMailboxes \Subscribed" if CHILDREN was also specified).



  
   I.e., should the response be treated as if there was an outstanding
   <LIST (SUBSCRIBED MATCHPARENT) ...> command or as if there was an
   outstanding <LIST (REMOTE MATCHPARENT) ... RETURN (SUBSCRIBED)> ?
   Either way, if the server sends that response right before the client
   sends the LIST command that doesn't match what the server did, the
   client will have no way of knowing that it should not treat that
   \Placeholder in that LIST response as working under the selection
   criteria that the client sent.
  



Alexey






--------------070508010502020303070906--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94DZxfZ036252; Mon, 4 Oct 2004 06:35:59 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94DZxdl036251; Mon, 4 Oct 2004 06:35:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from foon.sendmail.com (tls.sendmail.com [209.246.26.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94DZwtl036244 for ; Mon, 4 Oct 2004 06:35:58 -0700 (PDT) (envelope-from guenther@sendmail.com)
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id i94DZvWH017241 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 4 Oct 2004 06:35:58 -0700
X-DomainKeys: Sendmail DomainKeys Filter v0.2.2 foon.sendmail.com i94DZvWH017241
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=UnR0MF5ZVgNkYjLwX3ivyI9uNHGPji9aqYaB9DKFUVnK3zYEI4EEa7HpQIRbEcwMh DwCPeLDGGHR4D86OuosGImEZBmeK1nywa08Azk50e7qw+3WcXjzW5dfqbfTGt1xuxO+ 5jlhwrHm9bpAe5Pyi9SbkIh9V1Yz3WIFRUCeRf4=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.12.11/8.12.11) with ESMTP id i94DZvIa086491; Mon, 4 Oct 2004 06:35:57 -0700 (PDT) (envelope-from guenther@lab.smi.sendmail.com)
Message-Id: <200410041335.i94DZvIa086491@lab.smi.sendmail.com>
To: Alexey Melnikov 
Cc: IMAP Extensions WG 
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09 
In-reply-to: <416049CF.8060905@isode.com> 
References: <4140B37E.5000401@isode.com>  <200409130633.i8D6XMmj059087@lab.smi.sendmail.com> <4151B3B4.9090105@isode.com> <200409230341.i8N3f9gV048309@lab.smi.sendmail.com>  <416049CF.8060905@isode.com> 
Date: Mon, 04 Oct 2004 06:35:57 -0700
From: Philip Guenther 
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Alexey Melnikov  writes:
...
>As per off list discussion with Philip, I've changed the document to say 
>that \PlaceHolder/\HasSubMailboxes is only allowed when MATCHPARENT is 
>specified. In particular, this means that they are not allowed in LIST 
>responses not caused by the latest LIST command.
>
>Philip's suggestion is that the server will send
>"\Placeholder \Subscribed" in response to
>.
>This will mean "the mailbox is not really sibscribed, but the 
>\Placeholder flag was caused by SUBSCRIBED selection option.
>
>IMHO, this seems to be overly complex. I think my change detailed above 
>would suffice, however if WG members feel otherwise, I would like to 
>hear their comments.

My suggestion was not really sufficient to completely remove the
ambiguity of an unsolicited \Placeholder response**, so I support this
change.


Philip Guenther

** does an unsolicited "\Placeholder \Subscribed" response mean the
   named mailbox has subscribed submailboxes, or does it mean the named
   mailbox is subscribed and it has (possibly remote) submailboxes?
   I.e., should the response be treated as if there was an outstanding
    command or as if there was an
   outstanding  ?
   Either way, if the server sends that response right before the client
   sends the LIST command that doesn't match what the server did, the
   client will have no way of knowing that it should not treat that
   \Placeholder in that LIST response as working under the selection
   criteria that the client sent.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i949NNNT087255; Mon, 4 Oct 2004 02:23:23 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i949NN52087254; Mon, 4 Oct 2004 02:23:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i949NJRT087177 for ; Mon, 4 Oct 2004 02:23:22 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 4 Oct 2004 10:23:20 +0100
Message-ID: <416068F7.1050503@isode.com>
Date: Sun, 03 Oct 2004 22:02:47 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IMAP Extensions WG 
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
References: <4140B37E.5000401@isode.com> 	 <200409130633.i8D6XMmj059087@lab.smi.sendmail.com> <416067E6.7010902@isode.com>
In-Reply-To: <416067E6.7010902@isode.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

 >P.S. I've just submitted revision 10 of LISTEXT. It addresses the 
issues mentioned in this message +
 > updates ABNF for the MATCHPARENT option + changes LISTEXT to only 
return \PlaceHolder/\HasSubmailboxes
 >only when MATCHPARENT is specified. It also includes some editorial 
suggestions from Arnt.

I've also fixed few minor bugs in examples (in one place \SubMailboxes 
was not accompanied by \Subscribed)




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i949NMh2087243; Mon, 4 Oct 2004 02:23:22 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i949NMul087241; Mon, 4 Oct 2004 02:23:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i949NJRS087177 for ; Mon, 4 Oct 2004 02:23:21 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 4 Oct 2004 10:23:15 +0100
Message-ID: <416067E6.7010902@isode.com>
Date: Sun, 03 Oct 2004 21:58:14 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IMAP Extensions WG 
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
References: <4140B37E.5000401@isode.com> 	 <200409130633.i8D6XMmj059087@lab.smi.sendmail.com>
In-Reply-To: <200409130633.i8D6XMmj059087@lab.smi.sendmail.com>
Content-Type: multipart/alternative; boundary="------------040709030105080803000603"
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

--------------040709030105080803000603
Content-type: text/plain; charset="us-ascii"

Arnt:
 >Might want to add a note to section 3.1 then, saying explicitly that 
if multiple wildcards match a given mailbox,
 >it is to be returned only once.
I've clarified this at the beginning of section 3.

Philip:

>- if an option is repeated in an option list, is the server required to,
>  permitted to, or forbidden from rejecting the command with a BAD
>  response?
>
IMHO, I think the server should allow this, but the client SHOULD NOT do 
this. I've clarified this.

>- The LIST command requires special processing when the pattern argument
>  is the empty string.  How does LISTEXT interact with that?  Is the
>  special processing skipped when SUBSCRIBED is used?  Should the server
>  be permitted to ignore the MATCHPARENT and/or CHILDREN options for the
>  response generated by the empty pattern?  Is there any special result
>  or change if the empty pattern is one of multiple patterns in a LIST
>  command?
>
I've added a section saying that "" mailbox name doesn't have any 
special meaning when used in an extended LIST command.

>- Is a folder that doesn't exist but that meets the selection criteria
>  sufficient to trigger a \HasSubmailboxes or \Placeholder responses?
>  If so, then \HasSubmailboxes and \Placeholder do _not_ imply
>  \HasChildren.  E.g., consider the following:
>	a1 LIST "" ("foo" "foo/*")
>	* LIST () "/" foo
>	a1 OK done
>	a2 LIST (SUBSCRIBED) "" "foo/*"
>	* LIST (\Subscribed \NonExistent) "/" foo/bar
>	a2 OK done
>	a3 LIST (SUBSCRIBED MATCHPARENT) "" foo RETURN (CHILDREN)
>	* LIST (\Subscribed \Placeholder \HasNoChildren) "/" foo
>	a3 OK done
>  
>
I've added this as a new example. I've also removed any mentioning of 
\HasSubmailboxes/\PlaceHolder implying \HasChildren.

Alexey

P.S. I've just submitted revision 10 of LISTEXT. It addresses the issues 
mentioned in this message + updates ABNF for the MATCHPARENT option + 
changes LISTEXT to only return \PlaceHolder/\HasSubmailboxes only when 
MATCHPARENT is specified. It also includes some editorial suggestions 
from Arnt.



--------------040709030105080803000603
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit




  
  












Arnt:

>Might want to add a note to section 3.1 then, saying explicitly
that
if multiple wildcards match a given mailbox,

>it is to be returned only
once.


I've clarified this at the beginning of section 3.



Philip:



  
- if an option is repeated in an option list, is the server required to,
  permitted to, or forbidden from rejecting the command with a BAD
  response?



IMHO, I think the server should allow this, but the client SHOULD NOT
do this. I've clarified this.



  
- The LIST command requires special processing when the pattern argument
  is the empty string.  How does LISTEXT interact with that?  Is the
  special processing skipped when SUBSCRIBED is used?  Should the server
  be permitted to ignore the MATCHPARENT and/or CHILDREN options for the
  response generated by the empty pattern?  Is there any special result
  or change if the empty pattern is one of multiple patterns in a LIST
  command?



I've added a section saying that "" mailbox name doesn't have any
special meaning when used in an extended LIST command.




  
- Is a folder that doesn't exist but that meets the selection criteria
  sufficient to trigger a \HasSubmailboxes or \Placeholder responses?
  If so, then \HasSubmailboxes and \Placeholder do _not_ imply
  \HasChildren.  E.g., consider the following:
	a1 LIST "" ("foo" "foo/*")
	* LIST () "/" foo
	a1 OK done
	a2 LIST (SUBSCRIBED) "" "foo/*"
	* LIST (\Subscribed \NonExistent) "/" foo/bar
	a2 OK done
	a3 LIST (SUBSCRIBED MATCHPARENT) "" foo RETURN (CHILDREN)
	* LIST (\Subscribed \Placeholder \HasNoChildren) "/" foo
	a3 OK done
  



I've added this as a new example. I've also removed any mentioning of
\HasSubmailboxes/\PlaceHolder implying
\HasChildren.



Alexey



P.S. I've just submitted revision 10 of LISTEXT. It addresses the
issues mentioned in this message + updates ABNF for the MATCHPARENT
option + changes LISTEXT to only return \PlaceHolder/\HasSubmailboxes
only when MATCHPARENT is specified. It also includes some editorial
suggestions from Arnt.








--------------040709030105080803000603--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i949NLd9087230; Mon, 4 Oct 2004 02:23:21 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i949NLLt087229; Mon, 4 Oct 2004 02:23:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i949NJRR087177 for ; Mon, 4 Oct 2004 02:23:20 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com)
Received: from [172.16.0.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (internal) with ESMTPA; Mon, 4 Oct 2004 10:23:11 +0100
Message-ID: <416049CF.8060905@isode.com>
Date: Sun, 03 Oct 2004 19:49:51 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IMAP Extensions WG 
Subject: Re: Major changes in draft-ietf-imapext-list-extensions-09
References: <4140B37E.5000401@isode.com>  <200409130633.i8D6XMmj059087@lab.smi.sendmail.com> 	<4151B3B4.9090105@isode.com> <200409230341.i8N3f9gV048309@lab.smi.sendmail.com>
In-Reply-To: <200409230341.i8N3f9gV048309@lab.smi.sendmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

>What does a response with \Placeholder or \HasSubmailboxes mean when
>MATCHPARENT is used with REMOTE but without SUBSCRIBED?  I see three
>possible answers:
>a) it means the mailbox has at least one submailbox that is remote
>b) is means the mailbox has at least one submailbox, local or remote
>c) (b), but that's the same as \HasChildren, so MATCHPARENT shouldn't be
>   allowed with just REMOTE: it should require SUBSCRIBED or some other
>   option that affects the selection criteria.
>
>IMO, the current text says (b).  Switching it to (a) would require a
>major rethink of the concept of "selected", or would effectively declare
>MATCHPARENT as having ad hoc interaction with each selection option.  I
>would just as soon go with (c) and can help with text to that effect.

I don't think interpretation c) is very useful. This seems to make
existing complex situation even more complex. Currently the draft says 
that b) is the case. If people think that a) is more appropriate, than 
the WG needs to reconsider what REMOTE selection option means.

>Depending on how that question is settled, I may have an argument that
>in response to , responses with
>the \Placeholder flag also need the \Subscribed flag to avoid
>ambiguity.

As per off list discussion with Philip, I've changed the document to say 
that \PlaceHolder/\HasSubMailboxes is only allowed when MATCHPARENT is 
specified. In particular, this means that they are not allowed in LIST 
responses not caused by the latest LIST command.


Philip's suggestion is that the server will send
"\Placeholder \Subscribed" in response to
.
This will mean "the mailbox is not really sibscribed, but the 
\Placeholder flag was caused by SUBSCRIBED selection option.

IMHO, this seems to be overly complex. I think my change detailed above 
would suffice, however if WG members feel otherwise, I would like to 
hear their comments.

Alexey




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92IwtMZ048629; Sat, 2 Oct 2004 11:58:55 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i92Iwti0048628; Sat, 2 Oct 2004 11:58:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from cz.mit.edu (STRATTON-FOUR-SIXTY-ONE.MIT.EDU [18.187.6.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92Iwssm048615; Sat, 2 Oct 2004 11:58:54 -0700 (PDT) (envelope-from hartmans@mit.edu)
Received: by cz.mit.edu (Postfix, from userid 8042) id C22AAE004F; Sat,  2 Oct 2004 14:58:59 -0400 (EDT)
To: Lyndon Nerenberg 
Cc: ietf-sasl@imc.org, ietf-imapext@imc.org, ietf@ietf.org
Subject: Re: CRAMing for last call
References: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net>
From: Sam Hartman 
Date: Sat, 02 Oct 2004 14:58:59 -0400
In-Reply-To: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net> (Lyndon Nerenberg's message of "Fri, 01 Oct 2004 22:02:54 -0700")
Message-ID: 
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

>>>>> "Lyndon" == Lyndon Nerenberg  writes:

    Lyndon> Finally, we need to address the issue of the MD5 "break."
    Lyndon> I have held off from commenting on this issue until the
    Lyndon> community has seen explicit evidence of the attack, and
    Lyndon> the implications of it. At this point, I don't know if the
    Lyndon> document deserves a writeup on the attack. Theory abounds,
    Lyndon> but I haven't yet seen a practical attack that works in
    Lyndon> the general case. We should at the least make mention of
    Lyndon> what has been discussed, and point to the literature, but
    Lyndon> I don't think the document deserves to discuss all the
    Lyndon> possible attacks. This doesn't mean to discourage anyone
    Lyndon> from contributing text to the Security Considerations
    Lyndon> section (please do).

The security area seems to believe that hmac-md5 is still OK, at least
for now.  Especially since cram-md5 does not require much structure
for the challenge, we should discuss the issue in the security
considerations section.

Will you need agenda time at the next meeting?  If so, can you give an
estimate of how much and what we want to cover?

Thanks,

--Sam



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9252wBJ083995; Fri, 1 Oct 2004 22:02:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9252wLI083993; Fri, 1 Oct 2004 22:02:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9252vOB083966; Fri, 1 Oct 2004 22:02:57 -0700 (PDT) (envelope-from lyndon@orthanc.ca)
Received: from d216-232-212-223.bchsia.telus.net (d216-232-212-223.bchsia.telus.net [216.232.212.223]) (authenticated bits=0) by orthanc.ca (8.13.1.Alpha0/8.13.1.Alpha0) with ESMTP id i9252sWc034166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2004 23:02:56 -0600 (MDT)
Date: Fri, 01 Oct 2004 22:02:54 -0700
From: Lyndon Nerenberg 
To: ietf-sasl@imc.org, ietf-imapext@imc.org, ietf@ietf.org
Subject: CRAMing for last call
Message-ID: <7191026797F6AC787A2C240A@d216-232-212-223.bchsia.telus.net>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham  version=2.63
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on orthanc.ca
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Now that 2222bis is close to reality, I would like to push the final 
version of CRAM out as well. The two documents should be able to go 
through together, (I hope) making life easier for the RFC editor.

I have some non-substantive editorial changes that will make the 
document a bit easier to read, but these are not show stoppers. I think 
all of the last round of comments are addressed in the current draft. 
If not, I would like to hear from people, soon.

I would also like to solicit a few additional examples from anyone who 
has implemented CRAM in other than IMAP.

Finally, we need to address the issue of the MD5 "break." I have held 
off from commenting on this issue until the community has seen explicit 
evidence of the attack, and the implications of it. At this point, I 
don't know if the document deserves a writeup on the attack. Theory 
abounds, but I haven't yet seen a practical attack that works in the 
general case. We should at the least make mention of what has been 
discussed, and point to the literature, but I don't think the document 
deserves to discuss all the possible attacks. This doesn't mean to 
discourage anyone from contributing text to the Security Considerations 
section (please do).

The IMAP-EXT list has had recent discussion that points out the 
ambiguity of searching for the space (SP) separator (between the user 
id and the digest) as being the rightmost SP, so I will strengthen that 
text. Any other comments should come forth soon as I would like to run 
out the final draft at the end of next week (Oct. 8) if I can.

Cheers,

--lyndon (editor)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91Fd2Nk036671; Fri, 1 Oct 2004 08:39:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91Fd20m036670; Fri, 1 Oct 2004 08:39:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91Fd1PE036663 for ; Fri, 1 Oct 2004 08:39:01 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Message-Id: 
Date: Fri, 1 Oct 2004 17:39:12 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: IMAP,ACL,NAMESPACE,Mozilla,Outlook.
References: 
In-Reply-To: 
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i91Fd1PE036665
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

What happens if you specify the namespaces within the folder tree?

Richard Bang writes:
> O/OE doesn't understand namespaces so I cant move the shared folders 
> out of the folder tree.
>
> Currently:
> "/" inbox
> "/" drafts
> "/" shared/fred/inbox
> "/" "sent items"

... ie. you specify that / is personal and /shared/ is shared.

> How can I do these things? When I read the spec it strongly implies 
> (to me anyway) that personal, public and shared folders must all be 
> in separate namespaces. Am I misreading it?

AFAICR, the spec does not say nonoverlapping.

RFC 2342 example 5.3 seems to be rather similar to your case.

Arnt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FcVsl036627; Fri, 1 Oct 2004 08:38:31 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91FcV7p036626; Fri, 1 Oct 2004 08:38:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from mx0.ftgate.com (mx0.ftgate.com [195.224.16.225]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FcT7h036620 for ; Fri, 1 Oct 2004 08:38:30 -0700 (PDT) (envelope-from richard@ftgate.com)
Message-Id: 
Received: from local-ip[x.x.x.x] by mx0.ftgate.com.; Fri, 01 Oct 2004 16:38:23 +0100
From: "Richard Bang" 
To: 
Subject: RE: IMAP,ACL,NAMESPACE,Mozilla,Outlook.
Date: Fri, 1 Oct 2004 16:38:46 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcSnsm2399d+x+kyQ8WVf5x4PXqY5wAF46hQAABjiyA=
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

 
Hi,

I just realised my previous post may imply that I believe there is something
wrong with the protocols themselves. This is not the case and implementing
any of the protocols per se does not "break" the client.

The problem is, as Mark has often commented, that a broken client usually
results in the server being blamed. As in Mozilla if you don't have ACL.

After implementing ACL I was able with my test platfrom to correct
manipluate the shares on all the folders using a non NAMESPACE system.

However, this results in Mozilla showing all the share status but not
letting you actually share anything. To get Mozilla to share things you need
to move the shared items into a separate namespace (a namespace of shared/
doesn't cut it unfortunatly). 

I would love to be able to just declare that the fault is the client, but
this is usually futile.

I guess the soution would be for a client to see ACL and assume that it can
(at least try) to share anything for which myrights includes a (SETACL) as
this is what it means.

Regard 
Richard.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FN5WZ035557; Fri, 1 Oct 2004 08:23:05 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91FN5BW035556; Fri, 1 Oct 2004 08:23:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from mx0.ftgate.com (mx0.ftgate.com [195.224.16.225]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FN2SE035546 for ; Fri, 1 Oct 2004 08:23:03 -0700 (PDT) (envelope-from richard@ftgate.com)
Message-Id: 
Received: from local-ip[x.x.x.x] by mx0.ftgate.com.; Fri, 01 Oct 2004 16:22:47 +0100
From: "Richard Bang" 
To: 
Subject: RE: IMAP,ACL,NAMESPACE,Mozilla,Outlook.
Date: Fri, 1 Oct 2004 16:22:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcSnsm2399d+x+kyQ8WVf5x4PXqY5wAF46hQ
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Hi,
> 
> Why does this break Outlook/OE?
> 
O/OE doesn't understand namespaces so I cant move the shared folders out of
the folder tree.

Currently:
"/" inbox
"/" drafts
"/" shared/fred/inbox
"/" "sent items"

But If I do:
"/" inbox
"/" drafts
"#" fred/inbox
"/" "sent items"

O/OE wont see them. Is there another way to do this that doesn't break O/OE?

Also. At any point I can share any of my folders, and there doesnt seem to
be a way to identify that the folders can be shared. So I want to be able to
have:

"/" inbox    <-mine
"/" drafts   <-mine
"/" shared/fred/inbox <- freds but I have read access
"/" "sent items" <- mine
"/" "important" <- mine but fred has read/write access

How can I do these things? When I read the spec it strongly implies (to me
anyway) that personal, public and shared folders must all be in separate
namespaces. Am I misreading it?

I guess this is only an issue because one of my beta testers declared that
shared folders was broken because Mozilla said "The server does not support
shared folders" (meaning ACL was not implemented but it doesn't say that
does it :( ).

Your help is greatly appreciated.

Regards

Richard.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91CQ642025023; Fri, 1 Oct 2004 05:26:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91CQ6Wq025022; Fri, 1 Oct 2004 05:26:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f
Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91CQ1mE025011 for ; Fri, 1 Oct 2004 05:26:05 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no)
Message-Id: 
Date: Fri, 1 Oct 2004 14:26:11 +0200
From: Arnt Gulbrandsen 
To: ietf-imapext@imc.org
Subject: Re: IMAP,ACL,NAMESPACE,Mozilla,Outlook.
References: 
In-Reply-To: 
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Sender: owner-ietf-imapext@mail.imc.org
Precedence: bulk
List-Archive: 
List-ID: 
List-Unsubscribe: 

Richard Bang writes:
> I have managed to get ACL and NAMESPACE to work with Mozilla, but this 
> forces me to use name spaces for shared items and this instantly 
> breaks Outlook (& Express).

Why does this break Outlook/OE?

Arnt