Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5SB54i07461 for ietf-imapext-bks; Fri, 28 Jun 2002 04:05:04 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SB52w07450 for ; Fri, 28 Jun 2002 04:05:02 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5SB52d17644; Fri, 28 Jun 2002 05:05:02 -0600 Message-ID: <3D1C42DD.EC41DF67@messagingdirect.com> Date: Fri, 28 Jun 2002 05:05:01 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Re: ACL2: rights required for different IMAP command References: <3CFF2F53.AFD74026@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I haven't heard any public comments on this topic! (See some comments below) Alexey Melnikov wrote: > As you will see in the new revision, I've added a new section that > describes in details which rights should be checked to implement > different IMAP commands, which rights are mandatory and which are > optional. > Here is what left unresolved: > > SUBSCRIBE - "l" right is required only if the server checks for > mailbox existence > when performing SUBSCRIBE. > > Allow if the user has "r" right? > > GETACL - "a" right on the mailbox. > > CDC IntraStore: "a". > CMU: "r", "a", admin or owner. > MD: "r" or "a" or owner. > > No consensus if "r" should be allowed. John would prefer not to use "r", > but he is fine if somebody insists on using it. The main argument > against allowing "r" for GETACL is that in this case GETACL can > possibly disclose some identifiers existing on the mail system to an > authenticated user with read access. > On the other hand "r" is used for a mailbox metadata and seems > appropriate. > > LISTRIGHTS - Same as GETACL? or just "r"? > > GETQUOTA - no rights required > CMU server checks if the user belongs to administrators, I don't know > why > > SETQUOTA - "a" right > Some implementations allows to set quota when the user has "r" right as > well. Should we allow that? As a result of my private exchange with Vladimir, I am going to remove the requirement to use "a" for SETQUOTA, because it operates on a quota root, that is not necessary a mailbox. Instead this will be "implementation dependent". Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5PB4MD11887 for ietf-imapext-bks; Tue, 25 Jun 2002 04:04:22 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PB4Mw11883 for ; Tue, 25 Jun 2002 04:04:22 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29679; Tue, 25 Jun 2002 07:03:39 -0400 (EDT) Message-Id: <200206251103.HAA29679@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-thread-11.txt Date: Tue, 25 Jun 2002 07:03:39 -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 - THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-thread-11.txt Pages : 14 Date : 24-Jun-02 This document describes the server-based threading extension to the IMAP4rev1 protocol. This extension provides substantial performance improvements for IMAP clients which offer threaded views. A server which supports this extension indicates this with more or more capability names consisting of 'THREAD-' followed by a supported threading algorithm name as described in this document. This provides for future upwards-compatible extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-thread-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-thread-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-thread-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: <20020624144059.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-thread-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-thread-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020624144059.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id g5PB4J111877 for ietf-imapext-bks; Tue, 25 Jun 2002 04:04:19 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PB4Hw11870 for ; Tue, 25 Jun 2002 04:04:18 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29658; Tue, 25 Jun 2002 07:03:35 -0400 (EDT) Message-Id: <200206251103.HAA29658@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-sort-10.txt Date: Tue, 25 Jun 2002 07:03:35 -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 - SORT EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-sort-10.txt Pages : 10 Date : 24-Jun-02 This document describes an experimental server-based sorting extension to the IMAP4rev1 protocol, as implemented by the University of Washington's IMAP toolkit. This extension provides substantial performance improvements for IMAP clients which offer sorted views. A server which supports this extension indicates this with a capability name of 'SORT'. Client implementations SHOULD accept any capability name which begins with 'SORT' as indicating support for the extension described in this document. This provides for future upwards-compatible extensions. At the time of this document was written, the IMAP Extensions Working Group (IETF-IMAPEXT) was considering upwards-compatible additions to the SORT extension described in this document, tenatively called the SORT2 extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sort-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-sort-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: <20020624144050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020624144050.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5OBnC414252 for ietf-imapext-bks; Mon, 24 Jun 2002 04:49:12 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OBnBw14248 for ; Mon, 24 Jun 2002 04:49:11 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00639; Mon, 24 Jun 2002 07:48:29 -0400 (EDT) Message-Id: <200206241148.HAA00639@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-thread-10.txt Date: Mon, 24 Jun 2002 07:48:28 -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 - THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-thread-10.txt Pages : 14 Date : 21-Jun-02 This document describes the server-based threading extension to the IMAP4rev1 protocol. This extension provides substantial performance improvements for IMAP clients which offer threaded views. A server which supports this extension indicates this with more or more capability names consisting of 'THREAD-' followed by a supported threading algorithm name as described in this document. This provides for future upwards-compatible extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-thread-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-thread-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-thread-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: <20020621122018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-thread-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-thread-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020621122018.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5IMSYm24520 for ietf-imapext-bks; Tue, 18 Jun 2002 15:28:34 -0700 (PDT) Received: from atg.aciworldwide.com ([139.142.180.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IMS9n24498; Tue, 18 Jun 2002 15:28:09 -0700 (PDT) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g5IMSBgS052380; Tue, 18 Jun 2002 16:28:11 -0600 (MDT) Message-Id: <200206182228.g5IMSBgS052380@atg.aciworldwide.com> To: IMAP Interest Groups: ; Subject: IMAP Channel Draft version 2 released X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! Organization: ACI Worldwide - Advanced Technology Group X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Tue, 18 Jun 2002 16:28:11 -0600 From: Lyndon Nerenberg Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've pushed version 02 of the Channel draft to the ID editor. Early access can be had at: http://atg.aciworldwide.com/draft-nerenberg-imap-channel-02.txt Diffs from version 01: Changed to use instead of . This allows retrieval of headers and MIME structure. returns a , not (to match syntax). Add missing SP tokens to grammar. Grammar fix to allow foo: as a valid URI in a request. Add UID CHANNEL. Clarify response when client issues a command with an unsupported scheme. Add section on command sequencing. Note arbitrary ordering of untagged responses. Replace URI-reference with absoluteURI. The IMAP server can't maintain the state required to deal with relative URIs. This also solves an ambiguity between parsing "NIL" as or as a relative URI. --lyndon _ 12 + 144 + 20 + 3(\/4) 2 ---------------------- + 5(11) = 9 + 0 7 A dozen, a gross and a score, Plus three times the square root of four, Divided by seven, Plus five times eleven, Equals nine squared plus zero, no more! Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EDeZo05390 for ietf-imapext-bks; Fri, 14 Jun 2002 06:40:35 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EDeYn05386 for ; Fri, 14 Jun 2002 06:40:34 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5EDeSd06965; Fri, 14 Jun 2002 07:40:28 -0600 Message-ID: <3D09F24A.B40CC2A2@messagingdirect.com> Date: Fri, 14 Jun 2002 07:40:26 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lyndon Nerenberg CC: Rob Siemborski , Mark Crispin , IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" References: <200206131737.g5DHbdgS023085@atg.aciworldwide.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lyndon Nerenberg wrote: > > My experience with writing parsers in non-blocking or asynchronous IO model > > (i.e. when read from the socket may return that literal was not completely > > received by TCP stack) tells that it is a pain in the ass to write a parser for > > any command that uses literals. Why? Because you have to save state if there is > > not enough data. > > This argument doesn't hold. You can get a short read anywhere, not > just inside a literal. Well, I guess I should have explained our architecture in the first place. In our IMAP server we have two levels of parsing. The low level parser always guaranties that the server has a full text line till CRLF before it hands over the line to the high level parser. This is based on one very good property of IMAP protocol: any protocol line is terminated with CRLF, whether it is CRLF at the end of the command, after "}" in literals or in the middle of a RFC822 message. Thus, in our architecture low level parser always guaranties that we never get a short read while parsing a quoted string. That is not true for literals. So, after this clarification, my argument still holds. (I know of no other sane way of parsing IMAP with non blocking IO that doesn't use something like our low level parser). > And I would argue that literals are the > *easiest* string form to deal with: you already know how much data to > read therefore you don't need to keep any state on the data stream > itself, just a counter that you decrement as you read in the bytes. Not just this state. Counter is the least of the problems. I was talking about the current state of the command parser. For example, when parsing arguments of a SEARCH (or a FETCH) command, the parser can be several levels down parsing nested SEARCH criteria when it encounters a literal. Now there are couple choices how to deal with this: 1). throw away already constructed search state and reparse SEARCH command as soon as the literal is fully received or 2). save the current search state and switch to literal receiving mode. Both cases will require saving some non-trivial state, but 1) , IMHO, is inefficient, especially if there are several literals. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EArC527715 for ietf-imapext-bks; Fri, 14 Jun 2002 03:53:12 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EArBn27707 for ; Fri, 14 Jun 2002 03:53:11 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5EAr3d05609; Fri, 14 Jun 2002 04:53:04 -0600 Message-ID: <3D09CB0C.FA8D7BC1@messagingdirect.com> Date: Fri, 14 Jun 2002 04:53:01 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Showalter CC: ietf-imapext@imc.org Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights associated with READ-WRITE response code) References: <1023999339.91332.23.camel@funhouse.mirapoint.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tim Showalter wrote: > > How about a single ACL command with subcommands? > > Not a bad idea; better than SETACL2. That is fine with me. What about the syntax after ACL ? Are people happy with my proposal. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DKH6Q08834 for ietf-imapext-bks; Thu, 13 Jun 2002 13:17:06 -0700 (PDT) Received: from fp.mirapoint.com (fp.mirapoint.com [63.107.133.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DKH4n08830 for ; Thu, 13 Jun 2002 13:17:04 -0700 (PDT) Received: from alpo.mirapoint.com (alpo.mirapoint.com [192.168.0.19]) by fp.mirapoint.com (Mirapoint Messaging Server MOS 3.2.0.40 FastPath) with ESMTP id AAH06984; Thu, 13 Jun 2002 13:17:02 -0700 (PDT) Received: from funhouse.mirapoint.com (funhouse.mirapoint.com [192.168.0.92]) by alpo.mirapoint.com (Mirapoint Messaging Server MOS 3.2.0.40) with ESMTP id ADK00685; Thu, 13 Jun 2002 13:17:02 -0700 (PDT) Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) From: Tim Showalter To: ietf-imapext@imc.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 13 Jun 2002 14:15:39 -0600 Message-Id: <1023999339.91332.23.camel@funhouse.mirapoint.com> Mime-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > How about a single ACL command with subcommands? Not a bad idea; better than SETACL2. Tim Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DJpdH08353 for ietf-imapext-bks; Thu, 13 Jun 2002 12:51:39 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (suave@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DJpbn08349 for ; Thu, 13 Jun 2002 12:51:38 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id MAA07514; Thu, 13 Jun 2002 12:51:36 -0700 (PDT) Date: Thu, 13 Jun 2002 12:40:01 -0700 (PDT) From: Mark Crispin Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) To: Tim Showalter cc: IMAP Extensions WG In-Reply-To: <1023995067.91332.6.camel@funhouse.mirapoint.com> Message-ID: 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: On 13 Jun 2002 13:04:27 -0600, Tim Showalter wrote: > I like the proposed identifier format; it's cleaner than what we had > before. If I were implementing an ACL server from scratch I would want > to use something like that. Great! > But there's running ACL code out there that doesn't work that way. In > order for a sane upgrade path for Cyrus (and its progeny) the ACL2 > commands will have to be supported seperately; in order to make these > work in some sane way, we'll need some seperate syntax. In case it was unclear; I have no objection whatsoever to a different set of commands for ACL2. I always felt that instead of the current GETACL, LISTRIGHTS, and MYRIGHTS commands, we should use an extended form of LIST. But LIST extensions seems to have fallen by the wayside, sigh. How about a single ACL command with subcommands? SETACL => ACL STORE DELETEACL => ACL DELETE REPLACEACL => ACL SET GETACL => ACL GET LISTRIGHTS => ACL LIST MYRIGHTS => ACL FETCH ACL FETCH is slightly different than MYRIGHTS in that it takes an identifier as an argument and returns the rights for that identifier (?? is this desirable??). Or perhaps there could be an ACL CHECK that, given an identifier and a set of right, returns whether or not that identifier has those rights. I suspect that ACL CHECK may be more useful. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DJQ1d06584 for ietf-imapext-bks; Thu, 13 Jun 2002 12:26:01 -0700 (PDT) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DJQ0n06580 for ; Thu, 13 Jun 2002 12:26:00 -0700 (PDT) Received: from [172.16.36.239] ([206.187.69.206]) (user=leg mech=KERBEROS_V4 (0 bits)) by smtp6.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) with ESMTP id g5DJPrTK027475; Thu, 13 Jun 2002 15:25:57 -0400 Date: Thu, 13 Jun 2002 11:21:24 -0700 From: Lawrence Greenfield To: Alexey Melnikov cc: Mark Crispin , Cyrus Daboo , IMAP Extensions WG Subject: Re: ACL2: set of rights associated with READ-WRITE response code Message-ID: <340646994.1023967284@localhost> In-Reply-To: <3D088017.B4E5B315@messagingdirect.com> References: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> <2147483647.1023542206@[10.0.1.4]> <200206081726.g58HQQNo007436@lin2.andrew.cmu.edu> <3D088017.B4E5B315@messagingdirect.com> X-Mailer: Mulberry/3.0.0a2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Thursday, June 13, 2002 5:20 AM -0600 Alexey Melnikov wrote: > Lawrence Greenfield wrote: > >> Another possibility is for ACL to recommend that servers implementing >> ACL just not return either READ-ONLY or READ-WRITE in response to a >> SELECT. > > I think this breaks compliance with RFC 2060. No, the RFC merely says "SHOULD prefix the text" with "[READ-WRITE]". So it's clearly legal to not return either READ-ONLY or READ-WRITE. So my proposal is that EXAMINE must return "[READ-ONLY]". SELECT must not return "[READ-WRITE]"; may return "[READ-ONLY]" if all rights are off. Larry Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DJ5su05334 for ietf-imapext-bks; Thu, 13 Jun 2002 12:05:54 -0700 (PDT) Received: from fp.mirapoint.com (fp.mirapoint.com [63.107.133.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DJ5rn05330 for ; Thu, 13 Jun 2002 12:05:53 -0700 (PDT) Received: from alpo.mirapoint.com (alpo.mirapoint.com [192.168.0.19]) by fp.mirapoint.com (Mirapoint Messaging Server MOS 3.2.0.40 FastPath) with ESMTP id AAH06953; Thu, 13 Jun 2002 12:05:50 -0700 (PDT) Received: from funhouse.mirapoint.com (funhouse.mirapoint.com [192.168.0.92]) by alpo.mirapoint.com (Mirapoint Messaging Server MOS 3.2.0.40) with ESMTP id ADK00548; Thu, 13 Jun 2002 12:05:49 -0700 (PDT) Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) From: Tim Showalter To: IMAP Extensions WG In-Reply-To: <3D087A02.723560BF@messagingdirect.com> References: <3D070AD5.51168DAE@messagingdirect.com> <200206130246.g5D2kDNo019084@lin2.andrew.cmu.edu> <3D087A02.723560BF@messagingdirect.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 13 Jun 2002 13:04:27 -0600 Message-Id: <1023995067.91332.6.camel@funhouse.mirapoint.com> Mime-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2002-06-13 at 04:54, Alexey Melnikov wrote: > > Lawrence Greenfield wrote: > > > If you feel the need to deprecate the old ACL commands, can we just > > name them something else? > > Does it really matter? Syntax is almost identical and the difference can > be codified with the couple if statements. We *will* confuse people, almost immediately. Certainly no one here, as we read the specs; but there are a lot of people that don't, and there are a lot of people that like to leave mandatory () off of lists. I like the proposed identifier format; it's cleaner than what we had before. If I were implementing an ACL server from scratch I would want to use something like that. But there's running ACL code out there that doesn't work that way. In order for a sane upgrade path for Cyrus (and its progeny) the ACL2 commands will have to be supported seperately; in order to make these work in some sane way, we'll need some seperate syntax. > > I don't see the need to be so cute about > > our upgrades when we have an infinite number of bits that will make it > > blatantly obvious what versions we're using. I agree with this. Tim Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DHbmX02898 for ietf-imapext-bks; Thu, 13 Jun 2002 10:37:48 -0700 (PDT) Received: from atg.aciworldwide.com ([139.142.180.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DHbkn02889 for ; Thu, 13 Jun 2002 10:37:46 -0700 (PDT) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g5DHbdgS023085; Thu, 13 Jun 2002 11:37:39 -0600 (MDT) Message-Id: <200206131737.g5DHbdgS023085@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: Alexey Melnikov cc: Rob Siemborski , Mark Crispin , IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" In-Reply-To: Message from Alexey Melnikov of "Wed, 12 Jun 2002 20:49:49 BST." <3D07A5DD.2D9BAF46@messagingdirect.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Thu, 13 Jun 2002 11:37:39 -0600 From: Lyndon Nerenberg Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > My experience with writing parsers in non-blocking or asynchronous IO model > (i.e. when read from the socket may return that literal was not completely > received by TCP stack) tells that it is a pain in the ass to write a parser for > any command that uses literals. Why? Because you have to save state if there is > not enough data. This argument doesn't hold. You can get a short read anywhere, not just inside a literal. And I would argue that literals are the *easiest* string form to deal with: you already know how much data to read therefore you don't need to keep any state on the data stream itself, just a counter that you decrement as you read in the bytes. --lyndon I think 3B2 code deserves its own place in hell. Poring over the ESS#5 code, someone found that there were lots of strcmp(p, "f(") == 0 checks (I may have gotten the exact string wrong but it's close). It took us a while to figure out why. Apparently, location 0 on the 3b had the 3 bytes 'f' '(' '\0', someone noticed that when programs blew up they were pointing to "f(", and the worlds most amazing kludge for detecting nil pointers was born. -- Dave Presotto Received: by above.proper.com (8.11.6/8.11.3) id g5DEfxe22293 for ietf-imapext-bks; Thu, 13 Jun 2002 07:41:59 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DEfwn22289 for ; Thu, 13 Jun 2002 07:41:58 -0700 (PDT) Received: from PLATO (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id KAA23034; Thu, 13 Jun 2002 10:39:10 -0400 (EDT) Date: Thu, 13 Jun 2002 10:43:30 -0400 From: Cyrus Daboo To: Mark Crispin , "Vladimir A. Butenko" cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights associated with READ-WRITE response code) Message-ID: <778813404.1023965010@PLATO> In-Reply-To: References: X-Mailer: Mulberry/3.0.0a2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On Mark Crispin wrote: | I could understand you making a distinction between web mail programs that | only do local mail, and web mail programs that only do IMAP. But we have | at least one example (WebPine) of a program that (at least in theory) can | do both, and I doubt that WebPine is the only (or even the first) such | program. There are a number of webmail solutions that use PHP scripting on the webserver. In most cases they will use the IMAP implementation in PHP which is c-client based, so all of those fall into the same category - they can do both native mailstore access and IMAP mailstore access if desired. -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DEADP21432 for ietf-imapext-bks; Thu, 13 Jun 2002 07:10:13 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DEACn21428 for ; Thu, 13 Jun 2002 07:10:12 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DEA6d28051; Thu, 13 Jun 2002 08:10:07 -0600 Message-ID: <3D08A7BD.CA4628C2@messagingdirect.com> Date: Thu, 13 Jun 2002 08:10:05 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: Lawrence Greenfield , IMAP Extensions WG Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rightsassociated with READ-WRITE response code) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Thu, 13 Jun 2002 04:59:25 -0600, Alexey Melnikov wrote: > > Also as Vladimir pointed out in his private email to me, ACL2 implementation > > can treat as user=, if the implementation prohibits > > the creation of users with special names or names with "=". > > What does this mean? > > Would an identifier such as xxx be canonicalized to user=xxx form? Yes, unless it is one of the "specials". > If not, how is a client to know what xxx means? If an identifier is not allowed to have "=", then each identifier without "=" in it is automatically treated equal to user=xxx form. If an identifier contains "=", it must be either "user=yyy" or "group=zzz", otherwise it is illegal. > Also, wouldn't this conflict with > future assignment of special identifiers? Of course it will. But the server is not required to implement a future revision. I am not saying that this is the perfect solution (maybe not even recommended). Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DDric20680 for ietf-imapext-bks; Thu, 13 Jun 2002 06:53:44 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DDrhn20674 for ; Thu, 13 Jun 2002 06:53:43 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25675631; Thu, 13 Jun 2002 06:50:23 -0700 From: "Vladimir A. Butenko" Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights associated with READ-WRITE response code) To: Mark Crispin Cc: Alexey Melnikov , "Vladimir A. Butenko" , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Thu, 13 Jun 2002 06:50:23 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 13 Jun 2002 06:21:32 -0700 (PDT) Mark Crispin wrote: > On Thu, 13 Jun 2002 06:08:37 -0700, Vladimir A. Butenko wrote: > > I have seen a small util that implements POP3 via an IMAP server. Should > >we > > ALWAYS think about POP3 server as "a gateway from POP3 protocol to an > >IMAP > > server"? I hope not. Please note that not only CGatePro WebMail, but many > > other products implement WebMail "natively" - i.e. as yet another service > > working with the mailstore, alongside POP3 and IMAP services. > > That distinction does not always make sense. > > WebPine software uses IMAP as a back end. But there is no reason why it > has to. It uses the c-client library, which supports IMAP, POP, NNTP, and > local mail stores. A small change to the string supplied in a mail_open() > call transforms it from a "non-native" to a "native" system. > > So I don't see how you can say that CGatePro WebMail is "real" and WebPine > is "not real" web mail. Do you always ignore the ":-)" signs? If I have to, I will explain - I was joking/teasing/kidding. Anything that starts is "real". Anything that fails to start is "real", too. I was talking (seriously) about the difference of "native" implementations and "gateway"-type implementations. If there are several "native" applications (i.e. serveral applications directly addressing something - mailstore in our case), then there is a need to document the functionality and semantics of that "something". Then, even if there were ONE application (protocol) and other applications (protocols) would be implemented as "gateways", STILL there is a need to document the semantics of that underlying "something". And as a sample I used the current state of the LDAP protocol - which is still the only available protocol for Directory store, but w/o a doc describing directory store semantics, all implementations ended up being "slightly different". > Can CGatePro WebMail be configured to use an IMAP back end? If so, how is > it any different from WebPine? Does the default configuration magically > change a program from "real" to "not real"? It's irrelevant - see above, please. A sense of humor is not a sin, and it can be used sometimes, don't you think so? > If not (CGatePro WebMail can not be configured to use an IMAP back end), > than > are you arguing that a "real" web mail program is one that is a restricted > subset of a "not real" web mail program? :-) > I could understand you making a distinction between web mail programs that > only do local mail, and web mail programs that only do IMAP. But we have > at > least one example (WebPine) of a program that (at least in theory) can do > both, and I doubt that WebPine is the only (or even the first) such > program. :-)) Mark, there was no attempt to say that something is better and something is worse. That was a JOKE!!! Please look at this sign carefully: ":-)" It means - I'm kidding, I'm joking, I'm making (trying to make) you smile, it does not mean "Mark, you stuff does not fly". It does. Sincerely, Vladimir Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DDZLX18594 for ietf-imapext-bks; Thu, 13 Jun 2002 06:35:21 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (stuart@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DDZKn18587 for ; Thu, 13 Jun 2002 06:35:20 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id GAA07146; Thu, 13 Jun 2002 06:35:16 -0700 (PDT) Date: Thu, 13 Jun 2002 06:21:32 -0700 (PDT) From: Mark Crispin Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights associated with READ-WRITE response code) To: "Vladimir A. Butenko" cc: Alexey Melnikov , "Vladimir A. Butenko" , IMAP Extensions WG In-Reply-To: Message-ID: 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: On Thu, 13 Jun 2002 06:08:37 -0700, Vladimir A. Butenko wrote: > I have seen a small util that implements POP3 via an IMAP server. Should we > ALWAYS think about POP3 server as "a gateway from POP3 protocol to an IMAP > server"? I hope not. Please note that not only CGatePro WebMail, but many > other products implement WebMail "natively" - i.e. as yet another service > working with the mailstore, alongside POP3 and IMAP services. That distinction does not always make sense. WebPine software uses IMAP as a back end. But there is no reason why it has to. It uses the c-client library, which supports IMAP, POP, NNTP, and local mail stores. A small change to the string supplied in a mail_open() call transforms it from a "non-native" to a "native" system. So I don't see how you can say that CGatePro WebMail is "real" and WebPine is "not real" web mail. Can CGatePro WebMail be configured to use an IMAP back end? If so, how is it any different from WebPine? Does the default configuration magically change a program from "real" to "not real"? If not (CGatePro WebMail can not be configured to use an IMAP back end), than are you arguing that a "real" web mail program is one that is a restricted subset of a "not real" web mail program? I could understand you making a distinction between web mail programs that only do local mail, and web mail programs that only do IMAP. But we have at least one example (WebPine) of a program that (at least in theory) can do both, and I doubt that WebPine is the only (or even the first) such program. Received: by above.proper.com (8.11.6/8.11.3) id g5DDC1V16290 for ietf-imapext-bks; Thu, 13 Jun 2002 06:12:01 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DDBvn16279 for ; Thu, 13 Jun 2002 06:11:57 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25675576; Thu, 13 Jun 2002 06:08:37 -0700 From: "Vladimir A. Butenko" Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights associated with READ-WRITE response code) To: Alexey Melnikov , "Vladimir A. Butenko" Cc: Mark Crispin , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Thu, 13 Jun 2002 06:08:37 -0700 Message-ID: In-Reply-To: <3D087B54.747A0BC4@messagingdirect.com> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 13 Jun 2002 05:00:36 -0600 Alexey Melnikov wrote: > > > Oh, and I don't "dislike WebMail". After all, UW has a WebMail product > >of > > > its own (WebPine). WebMail done right! :-) > > > > If it's done via IMAP, it's not WebMail :-) > > We are just disagreeing on terms. I though about WebMail as IMAP to HTTP > gateway. I have seen a small util that implements POP3 via an IMAP server. Should we ALWAYS think about POP3 server as "a gateway from POP3 protocol to an IMAP server"? I hope not. Please note that not only CGatePro WebMail, but many other products implement WebMail "natively" - i.e. as yet another service working with the mailstore, alongside POP3 and IMAP services. On the other hand, it is possible to abandon the concept of "mailstore" completely, and express everything in terms of IMAP - even if the protocol does NOT use IMAP. I.e. the POP3 standard whould say: RETR operation that retrieves message body (that same thing that is retrieved with the IMAP BODY[] command) and sends it to the client in the same format that is used in the IMAP APPEND command literal parameter, ending with a dot and "escaped" in the same manner as it is escaped in SMTP... True, it can be done - but does it make sense? A perfect example of such an approach is the LDAP standards. Thanks God, mail things are in much better shape, but LDAP presents a perfect example of the mess created with that "misture" of protocol description and "store/object" semantics. The semantics of Directory database/store has to be retrieved from various parts of the LDAP protocol description, and is not clearly specified ANYWHERE (in the RFC tree, I'm not talking about X.500). The result - you CANNOT find any 2 LDAP servers that use the store with the same semantics. That's why I'd always vote for separate standards that explain the object store semantics (mail, directory, whatever) - and separate standards that specify communication protocol used to access those objects/store elements. > Regards, > Alexey Melnikov Sincerely, Vladimir Received: by above.proper.com (8.11.6/8.11.3) id g5DDAn316216 for ietf-imapext-bks; Thu, 13 Jun 2002 06:10:49 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (rossi@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DDAjn16211 for ; Thu, 13 Jun 2002 06:10:45 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id GAA07121; Thu, 13 Jun 2002 06:10:32 -0700 (PDT) Date: Thu, 13 Jun 2002 06:08:58 -0700 (PDT) From: Mark Crispin Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rightsassociated with READ-WRITE response code) To: Alexey Melnikov cc: Lawrence Greenfield , Mark Crispin , IMAP Extensions WG In-Reply-To: <3D087B0D.C333CE63@messagingdirect.com> Message-ID: 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: On Thu, 13 Jun 2002 04:59:25 -0600, Alexey Melnikov wrote: > Also as Vladimir pointed out in his private email to me, ACL2 implementation > can treat as user=, if the implementation prohibits > the creation of users with special names or names with "=". What does this mean? Would an identifier such as xxx be canonicalized to user=xxx form? If not, how is a client to know what xxx means? Also, wouldn't this conflict with future assignment of special identifiers? Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DBMsm11958 for ietf-imapext-bks; Thu, 13 Jun 2002 04:22:54 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DBMqn11952 for ; Thu, 13 Jun 2002 04:22:52 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DBMmd26530; Thu, 13 Jun 2002 05:22:48 -0600 Message-ID: <3D088087.62E6B066@messagingdirect.com> Date: Thu, 13 Jun 2002 05:22:47 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cyrus Daboo CC: Lawrence Greenfield , Mark Crispin , IMAP Extensions WG Subject: Re: ACL2: set of rights associated with READ-WRITE response code References: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> <2147483647.1023542206@[10.0.1.4]> <200206081726.g58HQQNo007436@lin2.andrew.cmu.edu> <2147483647.1023543615@[10.0.1.4]> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > Hi, > > --On Saturday, June 8, 2002 1:26 PM -0400 Lawrence Greenfield > wrote: > > | This is fine with me, though this doesn't appear to totally agree with > | the text in the IMAP draft (section 6.3.1): > | > | Read-only access through SELECT differs from the EXAMINE command > | in that certain read-only mailboxes MAY permit the change of > | permanent state on a per-user (as opposed to global) basis. > | Netnews messages marked in a server-based .newsrc file are an > | example of such per-user permanent state that can be modified > | with read-only mailboxes. This seems to imply that a server that implements only per-user system flags, must ignore "swt" for the purpose of deciding if READ-WRITE should be returned? What is the sane way of describing this? Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DBLJF11911 for ietf-imapext-bks; Thu, 13 Jun 2002 04:21:19 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DBLIn11906 for ; Thu, 13 Jun 2002 04:21:18 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DBKud26497; Thu, 13 Jun 2002 05:20:56 -0600 Message-ID: <3D088017.B4E5B315@messagingdirect.com> Date: Thu, 13 Jun 2002 05:20:55 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Greenfield CC: Mark Crispin , Cyrus Daboo , IMAP Extensions WG Subject: Re: ACL2: set of rights associated with READ-WRITE response code References: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> <2147483647.1023542206@[10.0.1.4]> <200206081726.g58HQQNo007436@lin2.andrew.cmu.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lawrence Greenfield wrote: > Another possibility is for ACL to recommend that servers implementing > ACL just not return either READ-ONLY or READ-WRITE in response to a > SELECT. I think this breaks compliance with RFC 2060. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DB1Qp11164 for ietf-imapext-bks; Thu, 13 Jun 2002 04:01:26 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DB1Pn11159 for ; Thu, 13 Jun 2002 04:01:25 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DB0rd26348; Thu, 13 Jun 2002 05:00:58 -0600 Message-ID: <3D087B54.747A0BC4@messagingdirect.com> Date: Thu, 13 Jun 2002 05:00:36 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vladimir A. Butenko" CC: Mark Crispin , IMAP Extensions WG Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights associated with READ-WRITE response code) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Oh, and I don't "dislike WebMail". After all, UW has a WebMail product of > > its own (WebPine). WebMail done right! :-) > > If it's done via IMAP, it's not WebMail :-) We are just disagreeing on terms. I though about WebMail as IMAP to HTTP gateway. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DB0E111139 for ietf-imapext-bks; Thu, 13 Jun 2002 04:00:14 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DB0Cn11135 for ; Thu, 13 Jun 2002 04:00:12 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DAxgd26312; Thu, 13 Jun 2002 04:59:46 -0600 Message-ID: <3D087B0D.C333CE63@messagingdirect.com> Date: Thu, 13 Jun 2002 04:59:25 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Greenfield CC: Mark Crispin , IMAP Extensions WG Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rightsassociated with READ-WRITE response code) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > I also am amazed by the argument that the new system of identifiers > "throws away a large amount of interoperable code". > > char *acl_to_acl2 (char *id) > { > char *ret; > if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id); > else { > ret = (char *) malloc (5 + strlen (id) + 1); > sprintf (ret,"user=%s",id); > } > return ret; > } > > char *acl2_to_acl (char *id) > { > char *ret; > if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id); > else if (strncmp (id,5,"user=") > strcpy (ret = (char *) malloc (strlen (id + 5) + 1),id + 5) > else ret = 0; > return ret; > } > > OK, I admit this is a bit too simple-minded, but it makes the point. Exactly. Also as Vladimir pointed out in his private email to me, ACL2 implementation can treat as user=, if the implementation prohibits the creation of users with special names or names with "=". Larry, our ACL implementations are almost identical, I don't believe there will be so match work. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DAt4I10562 for ietf-imapext-bks; Thu, 13 Jun 2002 03:55:04 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DAt2n10555 for ; Thu, 13 Jun 2002 03:55:02 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DAsxd26280; Thu, 13 Jun 2002 04:54:59 -0600 Message-ID: <3D087A02.723560BF@messagingdirect.com> Date: Thu, 13 Jun 2002 04:54:58 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Greenfield CC: IMAP Extensions WG , "Vladimir A. Butenko" , Mark Crispin Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) References: <3D070AD5.51168DAE@messagingdirect.com> <200206130246.g5D2kDNo019084@lin2.andrew.cmu.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lawrence Greenfield wrote: > If you feel the need to deprecate the old ACL commands, can we just > name them something else? Does it really matter? Syntax is almost identical and the difference can be codified with the couple if statements. > I don't see the need to be so cute about > our upgrades when we have an infinite number of bits that will make it > blatantly obvious what versions we're using. Just for the record, I don't care if ACL2 uses same command names with slightly modified syntax or we just give these new commands new names. I will be very reluctant to change command syntax further (remember, our server also implements ACL and we have exactly the same set of issues), unless it give a real benefit. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DAjke09708 for ietf-imapext-bks; Thu, 13 Jun 2002 03:45:46 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DAjin09703 for ; Thu, 13 Jun 2002 03:45:44 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DAjXd26192; Thu, 13 Jun 2002 04:45:34 -0600 Message-ID: <3D0877CC.56872347@messagingdirect.com> Date: Thu, 13 Jun 2002 04:45:32 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Greenfield CC: Simon Josefsson , IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" References: <3D0744F8.F062C28@messagingdirect.com> <3D074582.428AB17F@messagingdirect.com> <200206130236.g5D2aNNo019075@lin2.andrew.cmu.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lawrence Greenfield wrote: > From: Simon Josefsson > Date: Wed, 12 Jun 2002 20:52:11 +0200 > > Alexey Melnikov writes: > > > I've noticed yesterday that ABNF for "rights" was defined as "astring", > > not just "quoted". > > Anybody objects to changing this to quoted, because I don't see that > > "rights" will ever contain control or 8bit characters. > > Sounds fine. I've always disliked having different ways of expressing > the same thing, making things simpler is a good idea. Atom is perhaps > even better. > > No, atoms aren't sufficient. "rights" can be the empty string. Atoms > can't express the empty string. Oops, you are right. However my argument about non blocking parser stands. See my other reply. > I see no reason to constain rights to quoted strings. I think having > them as strings makes sense---they are strings---and in IMAP we have > up to three ways of expressing a string. Instead of simplifying > things, it'll complicated the lexical and syntatic levels of IMAP even > more. Not really. Instead of writing one function that accept any kind of string, you can write a new function that allows only quoted strings and make the first call the second. A particular implementation (;-)) may choose to accept both types of strings when only quoted is allowed and this is fine. > If you want to remove all ways of expressing strings in IMAP besides > literals, well, fine, but that's a different argument. Cheers, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DAdWV09523 for ietf-imapext-bks; Thu, 13 Jun 2002 03:39:32 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DAdUn09519 for ; Thu, 13 Jun 2002 03:39:30 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DAdSd26123; Thu, 13 Jun 2002 04:39:28 -0600 Message-ID: <3D08765F.64823F6A@messagingdirect.com> Date: Thu, 13 Jun 2002 04:39:27 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pete Resnick CC: ietf-imapext@imc.org Subject: Re: Meeting? References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Pete Resnick wrote: > Well, life is back to this list. Do we have enough to discuss and > have enough people going that I should set up a session in Yokohama? > (I will be there.) I suggest we don't meet this time, but we meet in November. Neither myself, nor Mark, nor Larry will be there. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DAVnD08494 for ietf-imapext-bks; Thu, 13 Jun 2002 03:31:49 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DAVln08489 for ; Thu, 13 Jun 2002 03:31:47 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DAVkd26010; Thu, 13 Jun 2002 04:31:46 -0600 Message-ID: <3D07A632.19371E80@messagingdirect.com> Date: Wed, 12 Jun 2002 20:51:14 +0100 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: SETACL/DELETEACL questions (was Re: ACL2: set of rights associated with READ-WRITE response code) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Tue, 11 Jun 2002 15:21:49 -0600, Alexey Melnikov wrote: > > > What should a server do if it receives a SETACL which can not be performed > > > without doing a DELETEACL of some other identifier/rights pair? [Think of > > > what would become a "chgrp" in UNIX] > > Server is allowed to do that. It must return new ACL in an unsolicited ACL > > response anyway. > > How is it indicated to the client that this will happen *before* doing the > SETACL? I don't know any way currently. > We're talking about client and end user surprise here. Such surprises will > generate complaints. We don't have too many choices really. Either the server says NO to an operation or it says OK, but updates client's view with unsolicited ACL response. Am I missing anything? Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DAVmv08490 for ietf-imapext-bks; Thu, 13 Jun 2002 03:31:48 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DAVkn08484 for ; Thu, 13 Jun 2002 03:31:46 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DAVgd26006; Thu, 13 Jun 2002 04:31:42 -0600 Message-ID: <3D07A5DD.2D9BAF46@messagingdirect.com> Date: Wed, 12 Jun 2002 20:49:49 +0100 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: Mark Crispin , IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Wed, 12 Jun 2002 12:23:52 -0400 (EDT), Rob Siemborski wrote: > > Is there a compelling reason for this? > > Simplicity. Why allow in the syntax something that is meaningless? Correct. Also see my comment below. > > Unless I'm missing something, > > nothing in the IMAP base spec that can be a quoted string is disallowed > > from being a literal > > You missed the internaldate argument to APPEND. string = quoted / literal ANNOTATATE extension, for example, uses "quoted" instead of "astring" for entry names. See below why it is a very good thing, IMHO. > > Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but > > why be different? I could easily see implementations that make heavy use > > of literals missing this special case. It is not about the bandwidth, but about simplicity of implementation. My experience with writing parsers in non-blocking or asynchronous IO model (i.e. when read from the socket may return that literal was not completely received by TCP stack) tells that it is a pain in the ass to write a parser for any command that uses literals. Why? Because you have to save state if there is not enough data. Dealing with "quoted" or atoms is a bit easier. So, for a server implementing only ACL2 and using async IO, this change will help. If a server also implements ACL it has to accept "astring" anyway. So CMU implementation doesn't have to change. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DAVfi08472 for ietf-imapext-bks; Thu, 13 Jun 2002 03:31:41 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DAVen08466 for ; Thu, 13 Jun 2002 03:31:40 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DAVad25987; Thu, 13 Jun 2002 04:31:37 -0600 Message-ID: <3D07A00F.5C742048@messagingdirect.com> Date: Wed, 12 Jun 2002 20:25:03 +0100 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Wed, 12 Jun 2002 06:58:42 -0600, Alexey Melnikov wrote: > > I've noticed yesterday that ABNF for "rights" was defined as "astring", > > not just "quoted". > > Anybody objects to changing this to quoted, because I don't see that > > "rights" will ever contain control or 8bit characters. > > By that argument, rights should be an atom instead of quoted. It is possible > to restrict from astring to atom, but not from quoted to atom, so if atom is > the right thing this has to be done now. That is even better. Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5D3FEu27673 for ietf-imapext-bks; Wed, 12 Jun 2002 20:15:14 -0700 (PDT) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5D3FCn27669 for ; Wed, 12 Jun 2002 20:15:12 -0700 (PDT) Received: from mailscan-out3.cac.washington.edu (mailscan-out3.cac.washington.edu [140.142.32.18]) by mxout4.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g5D3FGgt005686 for ; Wed, 12 Jun 2002 20:15:16 -0700 Received: FROM smtp.washington.edu BY mailscan-out3.cac.washington.edu ; Wed Jun 12 20:15:16 2002 -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.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g5D3FGdf006820 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 Jun 2002 20:15:16 -0700 Date: Wed, 12 Jun 2002 20:15:18 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lawrence Greenfield cc: IMAP Extensions WG , Alexey Melnikov , "Vladimir A. Butenko" Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) In-Reply-To: <200206130246.g5D2kDNo019084@lin2.andrew.cmu.edu> Message-ID: Organization: Networks & Distributed Computing 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: On Wed, 12 Jun 2002, Lawrence Greenfield wrote: > I think defining new, entirely different identifiers throws away a > large amount of interoperable code that already exists. This is a > silly response to the fear that someone, somewhere, has usernames > starting with $ that they will need to use with IMAP ACLs. It isn't just user names starting with $. It's also the "anyone" user name. It is certainly not "silly" to worry that an extension to a protocol arbitarily establishes a limitation that is not in the base specification. RFC 2086 made a mistake by assuming that identifier == username. The new system of identifiers makes more sense than RFC 2086 (or the proposed $ kludge), and is a clean functional superset. The whole point of ACL2 is to fix the numerous deficiencies in RFC 2086. That entire effort would be wasted by a misguided effort to be "compatible". I also am amazed by the argument that the new system of identifiers "throws away a large amount of interoperable code". char *acl_to_acl2 (char *id) { char *ret; if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id); else { ret = (char *) malloc (5 + strlen (id) + 1); sprintf (ret,"user=%s",id); } return ret; } char *acl2_to_acl (char *id) { char *ret; if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id); else if (strncmp (id,5,"user=") strcpy (ret = (char *) malloc (strlen (id + 5) + 1),id + 5) else ret = 0; return ret; } OK, I admit this is a bit too simple-minded, but it makes the point. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5D2l4w26754 for ietf-imapext-bks; Wed, 12 Jun 2002 19:47:04 -0700 (PDT) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5D2l3n26747 for ; Wed, 12 Jun 2002 19:47:03 -0700 (PDT) Received: from mailscan-out2.cac.washington.edu (mailscan-out2.cac.washington.edu [140.142.33.17]) by mxout1.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g5D2l3SJ027105 for ; Wed, 12 Jun 2002 19:47:07 -0700 Received: FROM smtp.washington.edu BY mailscan-out2.cac.washington.edu ; Wed Jun 12 19:47:02 2002 -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.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g5D2l1df006496 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 Jun 2002 19:47:02 -0700 Date: Wed, 12 Jun 2002 19:47:04 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lawrence Greenfield cc: Alexey Melnikov , Simon Josefsson , IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" In-Reply-To: <200206130236.g5D2aNNo019075@lin2.andrew.cmu.edu> Message-ID: Organization: Networks & Distributed Computing 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: On Wed, 12 Jun 2002, Lawrence Greenfield wrote: > No, atoms aren't sufficient. "rights" can be the empty string. Atoms > can't express the empty string. OK, in that case, then it should remain astring. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5D2kDQ26734 for ietf-imapext-bks; Wed, 12 Jun 2002 19:46:13 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5D2kBn26730 for ; Wed, 12 Jun 2002 19:46:11 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g5D2kDNo019084; Wed, 12 Jun 2002 22:46:14 -0400 Date: Wed, 12 Jun 2002 22:46:13 -0400 Message-Id: <200206130246.g5D2kDNo019084@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: IMAP Extensions WG , Alexey Melnikov Cc: "Vladimir A. Butenko" , Mark Crispin In-reply-to: <3D070AD5.51168DAE@messagingdirect.com> Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) References: <3D070AD5.51168DAE@messagingdirect.com> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If you feel the need to deprecate the old ACL commands, can we just name them something else? I don't see the need to be so cute about our upgrades when we have an infinite number of bits that will make it blatantly obvious what versions we're using. I think defining new, entirely different identifiers throws away a large amount of interoperable code that already exists. This is a silly response to the fear that someone, somewhere, has usernames starting with $ that they will need to use with IMAP ACLs. Larry Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5D2aRM26512 for ietf-imapext-bks; Wed, 12 Jun 2002 19:36:27 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5D2aOn26508 for ; Wed, 12 Jun 2002 19:36:24 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g5D2aNNo019075; Wed, 12 Jun 2002 22:36:23 -0400 Date: Wed, 12 Jun 2002 22:36:23 -0400 Message-Id: <200206130236.g5D2aNNo019075@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Alexey Melnikov , Simon Josefsson Cc: IMAP Extensions WG In-reply-to: Subject: Re: ACL2: Proposal to change ABNF for "rights" References: <3D0744F8.F062C28@messagingdirect.com> <3D074582.428AB17F@messagingdirect.com> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Simon Josefsson Date: Wed, 12 Jun 2002 20:52:11 +0200 Alexey Melnikov writes: > I've noticed yesterday that ABNF for "rights" was defined as "astring", > not just "quoted". > Anybody objects to changing this to quoted, because I don't see that > "rights" will ever contain control or 8bit characters. Sounds fine. I've always disliked having different ways of expressing the same thing, making things simpler is a good idea. Atom is perhaps even better. No, atoms aren't sufficient. "rights" can be the empty string. Atoms can't express the empty string. I see no reason to constain rights to quoted strings. I think having them as strings makes sense---they are strings---and in IMAP we have up to three ways of expressing a string. Instead of simplifying things, it'll complicated the lexical and syntatic levels of IMAP even more. If you want to remove all ways of expressing strings in IMAP besides literals, well, fine, but that's a different argument. Larry Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CLrOT20622 for ietf-imapext-bks; Wed, 12 Jun 2002 14:53:24 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLrNn20618 for ; Wed, 12 Jun 2002 14:53:23 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674686; Wed, 12 Jun 2002 14:50:05 -0700 From: "Vladimir A. Butenko" Subject: Re: New topic: Extensions to impove IMAP scalability To: Cyrus Daboo , Lyndon Nerenberg Cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 14:50:05 -0700 Message-ID: In-Reply-To: <2147483647.1023903818@socrates.cyrusoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 17:43:38 -0400 Cyrus Daboo wrote: > Hi, [skipped] > | Yes, right. But the fact that many clients need to open many connections > | to the server forces you to set that limit pretty high. Our docs suggest > | 5-10. That's why reducing the number of IMAP connections each client > | requires can also improve system protection. > > Right - but your solution requires a change to the protocol with support > from both servers AND clients. If clients choose not to use the new > mechanism then it won't be of any benefit. So why not try and get clients > to change their existing usage pattern first - what justifications have > you had from client writers as to why so many connections are needed? If > we can understand what demands exist on the client that justify this, we > can make sure that any protocol changes really will make a difference. Sure. Imagine a client that ALWAYS works via its own cache. It's a requirement and just take it so. I do understand that it is possible to create clients that do not use local cache (and your client is a very good sample), but there are OTHER clients and other approaches. Either we have to say now - "clients that use local caches are BAD and must be killed", or we have to think about supporting them more effectively. If you think about a client that provides you access to your entire mailstore - with a cache or without, you can come to the same requirement. "3-pane clients" are not the only clients that exist. And clients that can open a separate window for each mailbox are not the only clients that need to know about several mailboxes at the same time. You either say that those clients do not and should not exist, or you may want to agree that they a right to exist and in this case the proposed extension (actually designed to support such a client) makes some sense. > -- > Cyrus Daboo Sincerely, Vladimir Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CLkvt20427 for ietf-imapext-bks; Wed, 12 Jun 2002 14:46:57 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLktn20423 for ; Wed, 12 Jun 2002 14:46:55 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674673; Wed, 12 Jun 2002 14:43:37 -0700 From: "Vladimir A. Butenko" Subject: Re: New topic: Extensions to impove IMAP scalability To: Lyndon Nerenberg , "Vladimir A. Butenko " Cc: Cyrus Daboo , Mark Crispin , Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 14:43:37 -0700 Message-ID: In-Reply-To: <200206122140.g5CLe4gS013754@atg.aciworldwide.com> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 15:40:04 -0600 Lyndon Nerenberg wrote: > > Also, if a client does not complain when a server drops its "IDLE" > > connection, but instead reconnects, selects the same mailbox and > >re-enters > > the IDLE state - what will be the difference (besides even bigger load on > > the server)? > > "idle" and "IDLE" are not the same thing. I was specifically talking > about "idle" sessions. An IMAP session doing "IDLE" is not "idle." From the very beginning I was talking about not the BROKEN clients (that just forget to open some connections - as it happened a lot in Netscape Messenger), but about clients that NEED to keep those connections open, because they need to "stay in synch" with several mailboxes. It implies that there is an IDLE command pending there or that those clients send NOOP or something to get the updates. And the proposed extension targets exactly this situation - it allows to get rid of "synching" connections and get that same information in one, "main" connection that can be used to perform "active actions". > --lyndon Sincerely, Vladimir Received: by above.proper.com (8.11.6/8.11.3) id g5CLhq520365 for ietf-imapext-bks; Wed, 12 Jun 2002 14:43:52 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLhpn20361 for ; Wed, 12 Jun 2002 14:43:51 -0700 (PDT) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA18182; Wed, 12 Jun 2002 17:40:55 -0400 (EDT) Date: Wed, 12 Jun 2002 17:43:38 -0400 From: Cyrus Daboo To: "Vladimir A. Butenko" , Lyndon Nerenberg cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG Subject: Re: New topic: Extensions to impove IMAP scalability Message-ID: <2147483647.1023903818@socrates.cyrusoft.com> In-Reply-To: References: X-Mailer: Mulberry/3.0.0a2 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On "Vladimir A. Butenko" wrote: |> I've come across a number of servers that d have that option. Its |> probably a good idea to have something like that just from a security |> standpoint - if I know I can attack your server by opening lots of |> connections on it from my machine, that becomes an interesting denial |> of service possibility. | | Yes, right. But the fact that many clients need to open many connections | to the server forces you to set that limit pretty high. Our docs suggest | 5-10. That's why reducing the number of IMAP connections each client | requires can also improve system protection. Right - but your solution requires a change to the protocol with support from both servers AND clients. If clients choose not to use the new mechanism then it won't be of any benefit. So why not try and get clients to change their existing usage pattern first - what justifications have you had from client writers as to why so many connections are needed? If we can understand what demands exist on the client that justify this, we can make sure that any protocol changes really will make a difference. -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CLh0720349 for ietf-imapext-bks; Wed, 12 Jun 2002 14:43:00 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLgwn20345 for ; Wed, 12 Jun 2002 14:42:58 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674662; Wed, 12 Jun 2002 14:39:40 -0700 From: "Vladimir A. Butenko" Subject: Re: New topic: Extensions to impove IMAP scalability To: Cyrus Daboo , Lyndon Nerenberg Cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 14:39:40 -0700 Message-ID: In-Reply-To: <2147483647.1023903369@socrates.cyrusoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 17:36:09 -0400 Cyrus Daboo wrote: > Hi, > > --On "Vladimir A. Butenko" wrote: > > | This would be called a "broken server". The client has all rights to > | assume that the server would not break a connection unless a server has > a > | non-client related problem. A server that closes connections because it > | is just "too busy" falls in the category of the servers that simply > | "cannot be used under this type of load". > > Then you need to be clearer about specifying the load capability of the > server when using IMAP - in your case specify the load in terms of the > number of allowed IMAP connections rather than the total number of users. That's what we always do in our responses to various large-scale RFPs. Those who compose the RFPs tend to put "we need a server to handle X users" and it takes a lot of time to explain that the pure number of users does not mean much, that we must look at the avg user profile, etc. We have a customer that has 4.5mln users on a single server - so what? On the other end, we often have to deploy a 4-10 server cluster to handle some sites with just 100,000 users. BTW, in both cases the IMAP is the main protocol. The # of concurrent IMAP connections is just one thing, of course, there are many others - but it is an important thing, and whatever can be done to decrease the # of connections each user needs is a Good Thing. > -- > Cyrus Daboo Sincerely, Vladimir Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CLe6w20277 for ietf-imapext-bks; Wed, 12 Jun 2002 14:40:06 -0700 (PDT) Received: from atg.aciworldwide.com ([139.142.180.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLe4n20273 for ; Wed, 12 Jun 2002 14:40:04 -0700 (PDT) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g5CLe4gS013754; Wed, 12 Jun 2002 15:40:04 -0600 (MDT) Message-Id: <200206122140.g5CLe4gS013754@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: "Vladimir A. Butenko" cc: Cyrus Daboo , Mark Crispin , Alexey Melnikov , IMAP Extensions WG Subject: Re: New topic: Extensions to impove IMAP scalability In-Reply-To: Message from "Vladimir A. Butenko" of "Wed, 12 Jun 2002 14:28:27 PDT." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 12 Jun 2002 15:40:04 -0600 From: Lyndon Nerenberg Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Also, if a client does not complain when a server drops its "IDLE" > connection, but instead reconnects, selects the same mailbox and re-enters > the IDLE state - what will be the difference (besides even bigger load on > the server)? "idle" and "IDLE" are not the same thing. I was specifically talking about "idle" sessions. An IMAP session doing "IDLE" is not "idle." --lyndon Pieces of eight, pieces of eight, pieces of nine. Parroty error. Received: by above.proper.com (8.11.6/8.11.3) id g5CLaFF20181 for ietf-imapext-bks; Wed, 12 Jun 2002 14:36:15 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLaEn20177 for ; Wed, 12 Jun 2002 14:36:14 -0700 (PDT) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA18108; Wed, 12 Jun 2002 17:33:26 -0400 (EDT) Date: Wed, 12 Jun 2002 17:36:09 -0400 From: Cyrus Daboo To: "Vladimir A. Butenko" , Lyndon Nerenberg cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG Subject: Re: New topic: Extensions to impove IMAP scalability Message-ID: <2147483647.1023903369@socrates.cyrusoft.com> In-Reply-To: References: X-Mailer: Mulberry/3.0.0a2 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On "Vladimir A. Butenko" wrote: | This would be called a "broken server". The client has all rights to | assume that the server would not break a connection unless a server has a | non-client related problem. A server that closes connections because it | is just "too busy" falls in the category of the servers that simply | "cannot be used under this type of load". Then you need to be clearer about specifying the load capability of the server when using IMAP - in your case specify the load in terms of the number of allowed IMAP connections rather than the total number of users. -- Cyrus Daboo Received: by above.proper.com (8.11.6/8.11.3) id g5CLZwS20164 for ietf-imapext-bks; Wed, 12 Jun 2002 14:35:58 -0700 (PDT) Received: from atg.aciworldwide.com ([139.142.180.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLZvn20160 for ; Wed, 12 Jun 2002 14:35:57 -0700 (PDT) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g5CLZugS013519; Wed, 12 Jun 2002 15:35:56 -0600 (MDT) Message-Id: <200206122135.g5CLZugS013519@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: Cyrus Daboo cc: "Vladimir A. Butenko" , Mark Crispin , Alexey Melnikov , IMAP Extensions WG Subject: Re: New topic: Extensions to impove IMAP scalability In-Reply-To: Message from Cyrus Daboo of "Wed, 12 Jun 2002 17:28:24 EDT." <2147483647.1023902904@socrates.cyrusoft.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 12 Jun 2002 15:35:56 -0600 From: Lyndon Nerenberg Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > How do you then deal with clients that have an 'automatically re-connect > when server connection dies' mode? By swearing a lot. > In that mode the client will simply > re-connect as soon as you kill their connection. Most clients these days will hopefully defer that open until they have actual work to do. In general, clients that cache intelligently also tend to use connections intelligently. I'm all for "natural selection" here. > Another solution is to have a server admin configurable option to limit the > maximum number of connections from any one client machine. Provided you > ensure that the admin can't set this below, say 3, that might help. I've > come across a number of servers that d have that option. Its probably a > good idea to have something like that just from a security standpoint - if > I know I can attack your server by opening lots of connections on it from > my machine, that becomes an interesting denial of service possibility. If the client is "smart" (see above) this will have little overall impact (compared to LRUing idle connections). If the client is stupid, this will just increase the thrash level as the client closes existing connections to (needlessly) open a new connection to grab something that could have been obtained over one of the existing connections. It will then close the new connection to make room to re-open the old connection. This constant thrashing of TCP sessions tends to put a much higher load on server OSes than just maintaining existing idle connections. --lyndon Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CLZpC20152 for ietf-imapext-bks; Wed, 12 Jun 2002 14:35:51 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLZon20147 for ; Wed, 12 Jun 2002 14:35:50 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674652; Wed, 12 Jun 2002 14:32:32 -0700 From: "Vladimir A. Butenko" Subject: Re: New topic: Extensions to impove IMAP scalability To: Cyrus Daboo , Lyndon Nerenberg , "Vladimir A. Butenko" Cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 14:32:32 -0700 Message-ID: In-Reply-To: <2147483647.1023902904@socrates.cyrusoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 17:28:24 -0400 Cyrus Daboo wrote: > Hi, > > --On Lyndon Nerenberg wrote: > > | If your server can't scale to 100K+ connections then you should have > | it close down old connections on an LRU basis to cap the total > | connection count at something the server *can* handle. You don't > | need protocol modifications to solve this problem. (Especially > | since, as you stated earlier, "most of the connections are idle.") > > How do you then deal with clients that have an 'automatically re-connect > when server connection dies' mode? In that mode the client will simply > re-connect as soon as you kill their connection. Exactly. > Another solution is to have a server admin configurable option to limit > the maximum number of connections from any one client machine. Provided > you ensure that the admin can't set this below, say 3, that might help. We do have this option. So, if the client mailer NEEDS 4 connections and the server rejects it - what do we get? Yes, right - a call to the support center. Then imagine a customer like Charter that has more than 1mln users and you get the idea that "or, it's your client fault" would not be an acceptable answer for those sites. > I've come across a number of servers that d have that option. Its probably > a good idea to have something like that just from a security standpoint - > if I know I can attack your server by opening lots of connections on it > from my machine, that becomes an interesting denial of service > possibility. Yes, right. But the fact that many clients need to open many connections to the server forces you to set that limit pretty high. Our docs suggest 5-10. That's why reducing the number of IMAP connections each client requires can also improve system protection. > -- > Cyrus Daboo Sincerely, Vladimir Received: by above.proper.com (8.11.6/8.11.3) id g5CLVlg20030 for ietf-imapext-bks; Wed, 12 Jun 2002 14:31:47 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLVjn20023 for ; Wed, 12 Jun 2002 14:31:45 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674644; Wed, 12 Jun 2002 14:28:27 -0700 From: "Vladimir A. Butenko" Subject: Re: New topic: Extensions to impove IMAP scalability To: Lyndon Nerenberg , "Vladimir A. Butenko " Cc: Cyrus Daboo , Mark Crispin , Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 14:28:27 -0700 Message-ID: In-Reply-To: <200206122119.g5CLJZgS012764@atg.aciworldwide.com> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 15:19:35 -0600 Lyndon Nerenberg wrote: > If your server can't scale to 100K+ connections then you should have > it close down old connections on an LRU basis to cap the total > connection count at something the server *can* handle. You don't > need protocol modifications to solve this problem. (Especially > since, as you stated earlier, "most of the connections are idle.") This would be called a "broken server". The client has all rights to assume that the server would not break a connection unless a server has a non-client related problem. A server that closes connections because it is just "too busy" falls in the category of the servers that simply "cannot be used under this type of load". Also, if a client does not complain when a server drops its "IDLE" connection, but instead reconnects, selects the same mailbox and re-enters the IDLE state - what will be the difference (besides even bigger load on the server)? > --lyndon Sincerely, Vladimir Received: by above.proper.com (8.11.6/8.11.3) id g5CLSXw19937 for ietf-imapext-bks; Wed, 12 Jun 2002 14:28:33 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLSVn19932 for ; Wed, 12 Jun 2002 14:28:32 -0700 (PDT) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA18022; Wed, 12 Jun 2002 17:25:43 -0400 (EDT) Date: Wed, 12 Jun 2002 17:28:24 -0400 From: Cyrus Daboo To: Lyndon Nerenberg , "Vladimir A. Butenko" cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG Subject: Re: New topic: Extensions to impove IMAP scalability Message-ID: <2147483647.1023902904@socrates.cyrusoft.com> In-Reply-To: <200206122119.g5CLJZgS012764@atg.aciworldwide.com> References: <200206122119.g5CLJZgS012764@atg.aciworldwide.com> X-Mailer: Mulberry/3.0.0a2 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On Lyndon Nerenberg wrote: | If your server can't scale to 100K+ connections then you should have | it close down old connections on an LRU basis to cap the total | connection count at something the server *can* handle. You don't | need protocol modifications to solve this problem. (Especially | since, as you stated earlier, "most of the connections are idle.") How do you then deal with clients that have an 'automatically re-connect when server connection dies' mode? In that mode the client will simply re-connect as soon as you kill their connection. Another solution is to have a server admin configurable option to limit the maximum number of connections from any one client machine. Provided you ensure that the admin can't set this below, say 3, that might help. I've come across a number of servers that d have that option. Its probably a good idea to have something like that just from a security standpoint - if I know I can attack your server by opening lots of connections on it from my machine, that becomes an interesting denial of service possibility. -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CLJkS19746 for ietf-imapext-bks; Wed, 12 Jun 2002 14:19:46 -0700 (PDT) Received: from atg.aciworldwide.com ([139.142.180.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLJin19742 for ; Wed, 12 Jun 2002 14:19:44 -0700 (PDT) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g5CLJZgS012764; Wed, 12 Jun 2002 15:19:35 -0600 (MDT) Message-Id: <200206122119.g5CLJZgS012764@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: "Vladimir A. Butenko" cc: Cyrus Daboo , Mark Crispin , Alexey Melnikov , IMAP Extensions WG Subject: Re: New topic: Extensions to impove IMAP scalability In-Reply-To: Message from "Vladimir A. Butenko" of "Wed, 12 Jun 2002 13:39:16 PDT." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 12 Jun 2002 15:19:35 -0600 From: Lyndon Nerenberg Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If your server can't scale to 100K+ connections then you should have it close down old connections on an LRU basis to cap the total connection count at something the server *can* handle. You don't need protocol modifications to solve this problem. (Especially since, as you stated earlier, "most of the connections are idle.") --lyndon Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CKgaF18822 for ietf-imapext-bks; Wed, 12 Jun 2002 13:42:36 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CKgYn18818 for ; Wed, 12 Jun 2002 13:42:34 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674554; Wed, 12 Jun 2002 13:39:16 -0700 From: "Vladimir A. Butenko" Subject: Re: New topic: Extensions to impove IMAP scalability To: Cyrus Daboo , Mark Crispin Cc: Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 13:39:16 -0700 Message-ID: In-Reply-To: <712211245.1023898408@PLATO> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 16:13:28 -0400 Cyrus Daboo wrote: > Hi, > > --On "Vladimir A. Butenko" wrote: > > | The main problem with MANY IMAP clients is the number of IMAP > connections > | they keep open. While it may be not the case with the non-GUI clients, > | GUI clients tend to keep an open connection for each mailbox the user > | opened. Thus, a 10,000 active users often open 100,000 connections to a > | server, and this is not good, because: a) each connection require a > | socket on the server, and many systems "do not work very well" when they > | need to handle 100,000 open sockets. But we often meet a req to support > | 30,000 concurrent users - and 300,000 connections is definitely "too > | many". > > I think you are overstating this - are you really saying that an IMAP > client typically has 10 connections open to a single server when the user > is logged in? It all depends on your interpretation of the word "typically" :-). We did see that sometimes clients (I do not want to point fingers right now) that ended up with many open connections after you copy/move messages, and there are also clients where "keeping the cache current for all mailboxes" is a must and the authors use it as the explanation why so many connections need to be opened. While right now we definitely do not see that 1:10 ration I mentioned, the fact that we saw those things and the fact that we do not believe that those clients become less popular, and the fact that more and more people put most of their docs on mail servers, ending up with dozens of mailboxes in each account - makes us try to find a solution BEFORE it becomes a unsolvable problem. > Lets face it, most clients with the typical three-pane view > limit the number of mailboxes the user has open. Even with our client that > allows multiple windows for mailboxes, I very much doubt anyone gets close > to 10. Remember, that connections are costly on the client-side too. OK. Just try Netscape Messenger. It's not a client we worry about, but you will get the idea :-( > | b) in many server implementations each connection reequires a > | thread (at least, if not a process), and each thread needs a stack, and > | if 100K stacks are used, 10,000 connections would require 1GB of VRAM > for > | stacks (not tha bad), but 100,000 connections would require 10GB of VRAM > | - and this makes the server life "difficult" - when deployed on a 32-bit > | system. > > This is a server design issue. For this kind of scalability simply use a > fixed thread pool, and service connections with that. You don't have to > have one thread per connection. Given that an IMAP connection is idle for > significant periods of time, this is a reasonable thing to do. That's true. But thread stacks can be solved this way, while excessive number of connections will still be there. Try this test: make a simple test program that measures the performance of basic OS operations, then make that program open 100,000 sockets and measure the same things again. You can get very interesting results under Solaris 7, for example (they did address this in Solaris 8). > | of the implementations should only benefit: the client should use may > | "SELECT" commands to switch between mailboxes (instead of using many > | connections), but since the "WATCH" command would keep the mailbox in > the > | "parsed" stage, the price for those additional "SELECTs" should be > | virtually zero. > > This approach will effectively deprecate the use of sequence numbers and > require clients to maintain full UID caches for all messages in all the > mailboxes it is watching. The watched responses will have to return > message info using UIDs. This approach can be used EXACTLY for those clients that ALREADY do this. While I understand that this is not what IMAP authors and "good IMAP" client authors (like yourself) had in their minds, many popular clients DO MAINTAIN those caches, and this is a fact of live. If a client does not maintain the caches and does not care about synching them - it won't use those extensions, that's it. But if it does, it will work much more effectively with those extensions. > I think a better approach (if you really want to force one connection to > handle multiple mailboxes) is to introduce a MULTISELECT command that lets > you have more than one mailbox selected - in that mode all of the > responses from the server would include the mailbox name as part of the > response, so it would be possible to correlate responses with each > selected mailbox. This would allow sequence number access for all > mailboxes as well as using UIDs. I've mentioned this in my previous letter. I think that this is a much more radical change of the protocol. We can implement it easily, but it will unlikely have any real usage: a client that relies on such functionality would need a completely different code to support "old" IMAP servers. While the proposed extension adds only few things to the protocol, and it won't take a lot of additional code to support servers that do not have this extension (that code would just open a separate connection, do SELECT, then IDLE and get all updates) Again, my letter was just to see if anyone is interested. We now have that extension in any case, I just wanted to know if it makes sense to document it so other vendors can implement it, too - and if the client vendors find it useful. If not - then it's less work for us :-) > Cyrus Daboo Sincerely, Vladimir Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CKGsh18292 for ietf-imapext-bks; Wed, 12 Jun 2002 13:16:54 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CKGqn18288 for ; Wed, 12 Jun 2002 13:16:52 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674530; Wed, 12 Jun 2002 13:13:33 -0700 From: "Vladimir A. Butenko" Subject: Re: New topic: Extensions to impove IMAP scalability To: Mark Crispin Cc: Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 13:13:33 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 11:23:28 -0700 (PDT) Mark Crispin wrote: > Without deprecating Vladimir's efforts, he is not the only one who is > working > on "push" type technology for mailbox updates. > > I'd rather not say too much about my efforts at this point since I only > have a toy implementation. The basic idea is that it is a notification > mechanism in which a client (not necessarily an IMAP client) asks a > notification server to be delivered events on a certain object identifier, > and event generators for the particular object identifier spam the > notification server with events. > Of course, it's actually a lot more complicated than this. > > It is not impossible to implement an IMAP extension that uses an interface > very much like Vladimir's (or even identical), if in the long run it is > determined to be desirable to have access to the mechanism via IMAP. I think we look at this issue from different points of view. The proposed extension, indeed, can be viewed as a particular case of a more generic "Notification service", but I was talking about the IMAP protocol itself and the changes/extensions that we may have to implement in that protocol to meet the modern requirements. The IMAP protocol fits well when a "single-view" client is used. There the concept of "going from one mailbox to a different one" is well addressed by the use of the SELECT command. Modern, "multiple-view" clients use a different concept. They often use "one window-one session-one SELECT" approach and have to maintain many connections to work with many "views". While the current IMAP protocol can be (and is) successfully used by those clients, it causes scalability problems that I've mentioned. And because most clients are used by mortals that still have just two hands (at max) and one single-threaded brain (at max), most of those connections are sitting idle, with all action taking place at only one connection at any given moment. This leads to the idea to support those multiple-view clients with just one connection. One method would be to get rid of the "Selected" state at all, giving the client ability to work with any message in any mailbox at any time - but this would definitely result in a completely new protocol that would just use many IMAP portions. What we are using is a much more moderate change - those "WATCH" extensions. I cannot say now how well they work for multiple-view clients, but we hope that in 3-4 months the installed base of those clients will be well in hundred thousands, so we hope to have more "reallife" experience with it (it would be too bold to estimate that a new client will get such an audience so quickly, but that client is not a real one - it's a MAPI connector for MS OUTLOOK, thus this conservative estimate - less than 1% of our current users). Please note that there is no NEW "push" technology proposed here. All used technologies already exist in IMAP - with or without the IDLE extension. But in the basic IMAP the server reports updates only for one, "selected" mailbox, while with the proposed extension updates are reported for any set of mailboxes (besides the currently selected mailbox). So, the proposed thing is a much less generic one than your "notification server", and it is completely IMAP-specific, and uses the already existing technologies and the IMAP ideology. The message actions (read/copy/store) still can be used only from the "selected state", but the client can stay in sync with all mailboxes without keeping those "watching" connections. Depending on the type of mailbox store used, the extension may be very easily implemented. In CommuniGate Pro it took about 100 lines of code - total. Sincerely, Vladimir Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CKC6x17882 for ietf-imapext-bks; Wed, 12 Jun 2002 13:12:06 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CKC5n17878 for ; Wed, 12 Jun 2002 13:12:05 -0700 (PDT) Received: from PLATO (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id QAA17562; Wed, 12 Jun 2002 16:09:09 -0400 (EDT) Date: Wed, 12 Jun 2002 16:13:28 -0400 From: Cyrus Daboo To: "Vladimir A. Butenko" , Mark Crispin cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: New topic: Extensions to impove IMAP scalability Message-ID: <712211245.1023898408@PLATO> In-Reply-To: References: X-Mailer: Mulberry/3.0.0a2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On "Vladimir A. Butenko" wrote: | The main problem with MANY IMAP clients is the number of IMAP connections | they keep open. While it may be not the case with the non-GUI clients, | GUI clients tend to keep an open connection for each mailbox the user | opened. Thus, a 10,000 active users often open 100,000 connections to a | server, and this is not good, because: a) each connection require a | socket on the server, and many systems "do not work very well" when they | need to handle 100,000 open sockets. But we often meet a req to support | 30,000 concurrent users - and 300,000 connections is definitely "too | many". I think you are overstating this - are you really saying that an IMAP client typically has 10 connections open to a single server when the user is logged in? Lets face it, most clients with the typical three-pane view limit the number of mailboxes the user has open. Even with our client that allows multiple windows for mailboxes, I very much doubt anyone gets close to 10. Remember, that connections are costly on the client-side too. | b) in many server implementations each connection reequires a | thread (at least, if not a process), and each thread needs a stack, and | if 100K stacks are used, 10,000 connections would require 1GB of VRAM for | stacks (not tha bad), but 100,000 connections would require 10GB of VRAM | - and this makes the server life "difficult" - when deployed on a 32-bit | system. This is a server design issue. For this kind of scalability simply use a fixed thread pool, and service connections with that. You don't have to have one thread per connection. Given that an IMAP connection is idle for significant periods of time, this is a reasonable thing to do. | It looks like this extension allows to design a client that can open only | one IMAP connection to the server, but still "stay in synch" with several | mailboxes. This should decrease the server load for large sites, and most | of the implementations should only benefit: the client should use may | "SELECT" commands to switch between mailboxes (instead of using many | connections), but since the "WATCH" command would keep the mailbox in the | "parsed" stage, the price for those additional "SELECTs" should be | virtually zero. This approach will effectively deprecate the use of sequence numbers and require clients to maintain full UID caches for all messages in all the mailboxes it is watching. The watched responses will have to return message info using UIDs. I think a better approach (if you really want to force one connection to handle multiple mailboxes) is to introduce a MULTISELECT command that lets you have more than one mailbox selected - in that mode all of the responses from the server would include the mailbox name as part of the response, so it would be possible to correlate responses with each selected mailbox. This would allow sequence number access for all mailboxes as well as using UIDs. -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CK2fZ16900 for ietf-imapext-bks; Wed, 12 Jun 2002 13:02:41 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CK2en16894 for ; Wed, 12 Jun 2002 13:02:40 -0700 (PDT) Received: from PLATO (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id PAA17509; Wed, 12 Jun 2002 15:59:50 -0400 (EDT) Date: Wed, 12 Jun 2002 16:04:09 -0400 From: Cyrus Daboo To: Mark Crispin cc: IMAP Extensions WG Subject: re: New topic: Extensions to impove IMAP scalability Message-ID: <711652311.1023897849@PLATO> In-Reply-To: References: X-Mailer: Mulberry/3.0.0a2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On Mark Crispin wrote: | Without deprecating Vladimir's efforts, he is not the only one who is | working on "push" type technology for mailbox updates. | | I'd rather not say too much about my efforts at this point since I only | have a toy implementation. The basic idea is that it is a notification | mechanism in which a client (not necessarily an IMAP client) asks a | notification server to be delivered events on a certain object | identifier, and event generators for the particular object identifier | spam the notification server with events. Of course, it's actually a lot | more complicated than this. Oh great - yet another notification protocol proposal! All previous efforts in this area seem to have failed. I hope your solution can survive! To be honest with you, at this point I strongly believe that this type of notification should be integrated into presence protocols - I'd like my 'buddy' list to also tell me when new mail is present in a mailbox, and for the mailbox to send me an instant message with a summary of the new mail content. So why not piggy back this on impp? -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CJgJd16306 for ietf-imapext-bks; Wed, 12 Jun 2002 12:42:19 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (wml@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CJgHn16302 for ; Wed, 12 Jun 2002 12:42:17 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id MAA06195; Wed, 12 Jun 2002 12:42:05 -0700 (PDT) Date: Wed, 12 Jun 2002 12:24:14 -0700 (PDT) From: Mark Crispin Subject: re: Meeting? To: Pete Resnick cc: ietf-imapext@imc.org In-Reply-To: Message-ID: 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: On Wed, 12 Jun 2002 14:12:53 -0500, Pete Resnick wrote: > Well, life is back to this list. Do we have enough to discuss and > have enough people going that I should set up a session in Yokohama? > (I will be there.) Yokohama is just 4 1/2 weeks from now. The likelihood of getting reasonably priced airfare ($500) and lodging (6000 - 8000 yen/night) for Japan is vanishing this close to the travel date. For the next IETF, can we discuss the go/no-go question a bit earlier, such as when the first announcements are made? Our state government has a major budget crisis, and we're a state university. Non-essential travel for any of us is out of the question. Given that I have personal business in Japan, and that nothing else at the Yokohama IETF seems related to anything that I'm doing, any travel request from me to go to Yokohama will be picked over with a fine-toothed comb. So, (with considerable regret) I ask that there NOT be an IMAPEXT meeting at Yokohama. Received: by above.proper.com (8.11.6/8.11.3) id g5CJD3d14701 for ietf-imapext-bks; Wed, 12 Jun 2002 12:13:03 -0700 (PDT) Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CJD1n14697 for ; Wed, 12 Jun 2002 12:13:01 -0700 (PDT) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.1.3) for ; Wed, 12 Jun 2002 14:12:57 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 5.1.1r] Date: Wed, 12 Jun 2002 14:12:53 -0500 To: ietf-imapext@imc.org From: Pete Resnick Subject: Meeting? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well, life is back to this list. Do we have enough to discuss and have enough people going that I should set up a session in Yokohama? (I will be there.) pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: by above.proper.com (8.11.6/8.11.3) id g5CJ7Nw14352 for ietf-imapext-bks; Wed, 12 Jun 2002 12:07:23 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (trungt@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CJ7Ln14347 for ; Wed, 12 Jun 2002 12:07:21 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id MAA06176; Wed, 12 Jun 2002 12:07:08 -0700 (PDT) Date: Wed, 12 Jun 2002 12:01:52 -0700 (PDT) From: Mark Crispin Subject: re: ACL2 backwards compatibility To: Simon Josefsson cc: ietf-imapext@imc.org In-Reply-To: Message-ID: 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: On Wed, 12 Jun 2002 20:59:38 +0200, Simon Josefsson wrote: > Can a server support both ACL and ACL2? The latest draft indicate > that ACL and ACL2 is incompatible. How do the server know whether the > client is using ACL or ACL2? Alexey's latest proposals (basically a superset of what I proposed) will accomplish a server being able to do both ACL and ACL2. There is different command syntax for ACL and ACL2 commands, and that can be used by the server to determine ACL vs. ACL2 semantics. An ACL server should be able to add ACL2 support without too much difficulty. An ACL2 server may find it difficult or impossible to add ACL. I purpose to implement ACL2 only. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CJ26K14204 for ietf-imapext-bks; Wed, 12 Jun 2002 12:02:06 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CJ24n14197 for ; Wed, 12 Jun 2002 12:02:04 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674461; Wed, 12 Jun 2002 11:58:47 -0700 From: "Vladimir A. Butenko" Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) To: Arnt Gulbrandsen Cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 11:58:47 -0700 Message-ID: In-Reply-To: <20020612202807.D6597@melkebalanse.gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 20:28:07 +0200 Arnt Gulbrandsen wrote: > I have the impression that today, a "mailstore" is something that talks > IMAP, LMTP and often a few other protocols. You can think of it as you want. I prefer to call the "mailstore" some internal mail server component that implements certain functions, in the same way as the Directory is some database - with some well-defined semantics. If you want to include the components that implement various protocols into what you call "mailstore" - it's OK, but that internal component is still there. In the same way as the Directory semantics is always there, while LDAP is just a protocol that allows you to access that store, with its semantics - and there can be other ways to access the same store. Even if you use some legacy design and your IMAP, POP, SMTP, etc. components all have their own code, so they use just the same file system (or a database) - LOGICALLY, there is still a "mailstore" - something that stores the messages and allows certain operations with them - and that semantics DOES NOT DEPEND on the protocol used to access that mailstore. CommuniGate Pro (and, I'm sure some other servers) allow you to open any mailbox via POP3 using some special "username". For example, you can specify "mailbox#username" and open that mailbox in your POP3 session. Make one more step - if you access "foreign mailbox" in IMAP using ~username/mailboxname "mailbox" name, then it would be logical (though not required, of course) to allow the POP server to access the same mailbox if you specify the "~username/mailboxname#youraccount" and "yourpassword". Definitely you need to have access rights for that ~username/mailboxname to open that mailbox. Most likely - the "r" right in the IMAP ACL terms. And to delete messages there - also some right. And the POP3 server must mark those messages as "read" (or \Seen) on RETR - if you have the "s" right. Does it have anything to do with the IMAP *protocol*? No. There is a much less exotic sample - WebMail. The *NATIVE* WebMail that works directly with the mailstore, not a "WebMail GUI" on top of IMAP or POP. It needs to deal with all those things - and it has nothing to do with IMAP. > IMHO that's a good state of affairs. I'm sure there are arguments for > adding more stuff, but doing that makes me think of RFC 1925. There is already a draft for Server-side Rules (or, probably, it has already become an RFC?). If my Rule specifies that the message that meets this and that criteria should be stored in the ~secretary/ImportantNotes mailbox - what should be my rights for that mailbox? Should that standard refer to the IMAP ACL RFC? Why - it has nothing to do with IMAP *protocol*? Message UIDs should be generated by those components that store messages in mailboxes. The UIDs must be numbers in the strict ascending order. Where is the standard that tells delivery agent developers to implement it that way? The same applies to the requirement to store the INTERNALDATE values there. Yes, it is mentioned in the IMAP standard, but why should Delivery Agent developers look into any IMAP standard? Result - the POP3 also has UIDs, but they are "completely different UIDs" - they may be non-numeric, and they may be non-ascending, so all POP3 clients implementing the "leave on server" options must remember all UIDs that they have "seen" in the mailbox (instead of remembering UIDValidity and the last UID or UIDNEXT in the IMAP terms). You do not want the IMAP standard to talk about the details of the TCP implementation, right? And it would be very strange if the FTP RFC would refer to the IMAP RFC for the details of the TCP semantics, right? The TCP is the "backbone", it's some thing that many higher-level protocols use and it is documented separately. The fact that an IMAP client built into a cell phone may implement IMAP and TCP in one piece of code does not make a difference. The fact that many existing IMAP, POP3, SMTP servers implement certain mailstore semantics inside their protocol-specific code does not make that semantics "tied up" to a certain protocol or service. It should be documented separately. > --Arnt Sincerely, Vladimir Received: by above.proper.com (8.11.6/8.11.3) id g5CIxbD14100 for ietf-imapext-bks; Wed, 12 Jun 2002 11:59:37 -0700 (PDT) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CIxZn14095 for ; Wed, 12 Jun 2002 11:59:35 -0700 (PDT) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.4/8.12.4) with ESMTP id g5CIxam1024117 for ; Wed, 12 Jun 2002 20:59:37 +0200 To: ietf-imapext@imc.org Subject: ACL2 backwards compatibility From: Simon Josefsson Date: Wed, 12 Jun 2002 20:59:38 +0200 Message-ID: Lines: 6 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) 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: Can a server support both ACL and ACL2? The latest draft indicate that ACL and ACL2 is incompatible. How do the server know whether the client is using ACL or ACL2? Perhaps this is already taken care of in the document, if so I'm sorry to have read it sloppily. Received: by above.proper.com (8.11.6/8.11.3) id g5CIqFN13830 for ietf-imapext-bks; Wed, 12 Jun 2002 11:52:15 -0700 (PDT) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CIqCn13825 for ; Wed, 12 Jun 2002 11:52:13 -0700 (PDT) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.4/8.12.4) with ESMTP id g5CIq9m1024064; Wed, 12 Jun 2002 20:52:10 +0200 To: Alexey Melnikov Cc: IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" References: <3D0744F8.F062C28@messagingdirect.com> <3D074582.428AB17F@messagingdirect.com> From: Simon Josefsson Date: Wed, 12 Jun 2002 20:52:11 +0200 In-Reply-To: <3D074582.428AB17F@messagingdirect.com> (Alexey Melnikov's message of "Wed, 12 Jun 2002 06:58:42 -0600") Message-ID: Lines: 10 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) 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: Alexey Melnikov writes: > I've noticed yesterday that ABNF for "rights" was defined as "astring", > not just "quoted". > Anybody objects to changing this to quoted, because I don't see that > "rights" will ever contain control or 8bit characters. Sounds fine. I've always disliked having different ways of expressing the same thing, making things simpler is a good idea. Atom is perhaps even better. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CIW0h13310 for ietf-imapext-bks; Wed, 12 Jun 2002 11:32:00 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (pat@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CIVwn13304 for ; Wed, 12 Jun 2002 11:31:58 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA06112; Wed, 12 Jun 2002 11:31:48 -0700 (PDT) Date: Wed, 12 Jun 2002 11:23:28 -0700 (PDT) From: Mark Crispin Subject: re: New topic: Extensions to impove IMAP scalability To: "Vladimir A. Butenko" cc: Alexey Melnikov , IMAP Extensions WG In-Reply-To: Message-ID: 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: Without deprecating Vladimir's efforts, he is not the only one who is working on "push" type technology for mailbox updates. I'd rather not say too much about my efforts at this point since I only have a toy implementation. The basic idea is that it is a notification mechanism in which a client (not necessarily an IMAP client) asks a notification server to be delivered events on a certain object identifier, and event generators for the particular object identifier spam the notification server with events. Of course, it's actually a lot more complicated than this. It is not impossible to implement an IMAP extension that uses an interface very much like Vladimir's (or even identical), if in the long run it is determined to be desirable to have access to the mechanism via IMAP. Received: by above.proper.com (8.11.6/8.11.3) id g5CIQ2v13171 for ietf-imapext-bks; Wed, 12 Jun 2002 11:26:02 -0700 (PDT) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CIQ0n13167 for ; Wed, 12 Jun 2002 11:26:01 -0700 (PDT) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g5CIS7706641; Wed, 12 Jun 2002 20:28:07 +0200 Date: Wed, 12 Jun 2002 20:28:07 +0200 From: Arnt Gulbrandsen To: "Vladimir A. Butenko" Cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) Message-ID: <20020612202807.D6597@melkebalanse.gulbrandsen.priv.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have the impression that today, a "mailstore" is something that talks IMAP, LMTP and often a few other protocols. IMHO that's a good state of affairs. I'm sure there are arguments for adding more stuff, but doing that makes me think of RFC 1925. --Arnt Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CHS2k11028 for ietf-imapext-bks; Wed, 12 Jun 2002 10:28:02 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CHS1n11023 for ; Wed, 12 Jun 2002 10:28:01 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674255; Wed, 12 Jun 2002 10:24:38 -0700 From: "Vladimir A. Butenko" Subject: New topic: Extensions to impove IMAP scalability To: Mark Crispin Cc: Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 10:24:38 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We are about to release the new version of CommuniGate Pro that will inlcude several extensions that have not been discussed anywhere: they will be used by our own client. But at least one of those extensions may be of some general interest, since we implemented it to improve the scalability. We now deploy more and more systems (both single-server and clustered) in Universities and corporations where IMAP is the main access method (WebMail is great, Mark, do not forget that! - but IMAP is great, too :-). The main problem with MANY IMAP clients is the number of IMAP connections they keep open. While it may be not the case with the non-GUI clients, GUI clients tend to keep an open connection for each mailbox the user opened. Thus, a 10,000 active users often open 100,000 connections to a server, and this is not good, because: a) each connection require a socket on the server, and many systems "do not work very well" when they need to handle 100,000 open sockets. But we often meet a req to support 30,000 concurrent users - and 300,000 connections is definitely "too many". b) in many server implementations each connection reequires a thread (at least, if not a process), and each thread needs a stack, and if 100K stacks are used, 10,000 connections would require 1GB of VRAM for stacks (not tha bad), but 100,000 connections would require 10GB of VRAM - and this makes the server life "difficult" - when deployed on a 32-bit system. So, our goal was to make minimal additions to the IMAP protocol - additions that would make it possible to "keep in sync" with many mailboxes, while still using just one IMAP connection. There is no formal document for that, so I'm trying to provide informal description: Commands: WATCH ON This command sets a "watcher" on the specified mailbox. ACL: must be the same as for the EXAMINE command, and for synching puposes, the command should be sent when the mailbox is selected by this IMAP session. WATCH OFF This command removes the watcher from the specified mailbox. When the session ends, all watchers are removed automatically, so this command is useful mostly for mailbox removing/renaming operations on the servers that do not allow you to move/delete a mailbox if is being "opened" by anyone. Responses. Whenever an untagged response can be returned, the following responses can appear: * WATCH * WATCH Where the and responses are the same responses as used in the "normal" IMAP session. For example: * WATCH Trash 10 EXPUNGE * WATCH Trash 11 EXPUNGE * WATCH Trash 12 EXPUNGE If the current mailbox name (name specified in the "Select" command) is the same as the name in one of the WATCH commands, "WATCH" responses for that mailbox are not sent (to avoid duplicates, since they are sent as regular IMAP untagged reponses). If the names are different (but in reality they point to the same mailbox), the responses are sent. It looks like this extension allows to design a client that can open only one IMAP connection to the server, but still "stay in synch" with several mailboxes. This should decrease the server load for large sites, and most of the implementations should only benefit: the client should use may "SELECT" commands to switch between mailboxes (instead of using many connections), but since the "WATCH" command would keep the mailbox in the "parsed" stage, the price for those additional "SELECTs" should be virtually zero. If there is any interest in such an extension, we can try to create a formal draft. Sincerely, Vladimir Received: by above.proper.com (8.11.6/8.11.3) id g5CH3ZE08178 for ietf-imapext-bks; Wed, 12 Jun 2002 10:03:35 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CH3Xn08173 for ; Wed, 12 Jun 2002 10:03:33 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674216; Wed, 12 Jun 2002 10:00:14 -0700 From: "Vladimir A. Butenko" Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) To: Mark Crispin Cc: Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 10:00:14 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 09:53:09 -0700 (PDT) Mark Crispin wrote: > I have a great deal of sympathy for many of Vladimir's arguments, > particularly > from an architectural point of view. I have argued many of these things > myself for many years. > > >From a practical point of view, however, I don't think that any of these > should delay ACL2. Let's be realistic. Even if someone would agree to create such a "mailstore" standard, it would take at least 1-2 months to create the first draft. Then it will take at least 3-6 months to discuss it, since it definitely should agree (at least, in main points) with the current, popular implementations. So, if this standard is to appear, it will take at least 9 months (as usual). And if it appears, many standards has to be rewritten to remove the parts that would be included into the new standard. Rewriting the new ACL standard would be a very small part of that job. So - I do not see any reason to delay the ACL2 release either. > Oh, and I don't "dislike WebMail". After all, UW has a WebMail product of > its own (WebPine). WebMail done right! :-) If it's done via IMAP, it's not WebMail :-) Sincerely, Vladimir Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CGtss06953 for ietf-imapext-bks; Wed, 12 Jun 2002 09:55:54 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (gibb@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CGtqn06945 for ; Wed, 12 Jun 2002 09:55:52 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id JAA05997; Wed, 12 Jun 2002 09:55:45 -0700 (PDT) Date: Wed, 12 Jun 2002 09:53:09 -0700 (PDT) From: Mark Crispin Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) To: "Vladimir A. Butenko" cc: Alexey Melnikov , IMAP Extensions WG In-Reply-To: Message-ID: 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: I have a great deal of sympathy for many of Vladimir's arguments, particularly from an architectural point of view. I have argued many of these things myself for many years. >From a practical point of view, however, I don't think that any of these should delay ACL2. Oh, and I don't "dislike WebMail". After all, UW has a WebMail product of its own (WebPine). WebMail done right! :-) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CGntH06406 for ietf-imapext-bks; Wed, 12 Jun 2002 09:49:55 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CGnsn06402 for ; Wed, 12 Jun 2002 09:49:54 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674183; Wed, 12 Jun 2002 09:46:29 -0700 From: "Vladimir A. Butenko" Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) To: Mark Crispin , Alexey Melnikov Cc: IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 09:46:29 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 08:42:28 -0700 (PDT) Mark Crispin wrote: > It should be obvious, but I support Alexey's proposal. > > This will make it possible to implement both ACL and ACL2 in a > straighforward > manner, while not leaving ACL2 hampered with warts from needless ACL > compatibility. I have just sent my comments on the new draft to Alexey, hopefully he will have time to remove the most foolish of my remarks and share it with the group. I strongly support this new, more mature ACL standard, but I'd like to bring up the issue that I have already mentioned in my previous letter to Alexey: Most of those things have NOTHING to do with IMAP. Both the IMAP basic standard and some of its standard extensions are talking about 2 different things: about the "mailbox store" and its semantics (that has nothing to do with the IMAP as the protocol) and the IMAP itself - the protocol that provides access to that mailbox store and its functions, but should not care about many "behind the scene" details of the mailbox store functionality. I do understand that it's a big work to do, but - IMHO - all of us will benefit from a new, additional set of standards, the "mailbox store" standards that will address many issues that originated in the first IMAP implementations, but have nothing to do with the protocol itself: * concept of a mailbox * concept of a mailbox heirarchy * concept of message UIDs and mailbox UIDVALIDITY settings * concept of message flags * concept of mailbox operations ("append", "remove marked") * concept of "foreign mailbox" access * concept of mailbox ACLs * concept of concurrent mailbox usage * etc. The IMAP standards can just ref to those standards, specifying only the syntax and IMAP-specific details, and not touching the "backend", mailstore specific details. This would allow us to rewrite the POP3 standard, too - since most modern implementations use the same mailstore for POP3 and IMAP, and there is no standard that specifies how these two interact (messages retrieved with POP3 RETR are marked with the \SEEN flag, while message retrieved with TOP are not marked, if POP3 QUIT does "EXPUNGE" or deletes only those messages that this POP3 session marked as "DELETED", how POP3 should deal with messages that have been deleted in a concurrent session, etc.). While SMTP standard won't gain much from such a "mailstore" standard, "delivery agents" may gain a lot, especially those that provide Automated Rules - those Rules can store message in different mailboxes in the the mailstore, add flags, etc. In spite of the fact that I know how Mark dislikes WebMail :-), I have to mention it, too: WebMail has become a de-facto standard - and it must use the same mailstore as IMAP/POP/maildelivery agents use. W/o the mailstore standard, there can be no "standard" for WebMail, but if we require that WebMail must use the "standard-based" mailstore, interaction between WebMail and IMAP becomes a no-brainer, and it becomes obvious what this or that WebMail operation does and how it will be seen in an IMAP session opened to the same mailstore, and vice versa. Not that I feel myself able to create such a standard, but I'd definitely support and help anyone who is brave enough to invest his/her time and talent into such a beast. Sincerely, Vladimir Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CGZgv06171 for ietf-imapext-bks; Wed, 12 Jun 2002 09:35:42 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CGZen06166 for ; Wed, 12 Jun 2002 09:35:40 -0700 (PDT) Received: from GOBO.ANDREW.CMU.EDU (GOBO.ANDREW.CMU.EDU [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g5CGZdNp018685; Wed, 12 Jun 2002 12:35:39 -0400 Date: Wed, 12 Jun 2002 12:35:39 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" In-Reply-To: Message-ID: 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: On Wed, 12 Jun 2002, Mark Crispin wrote: > > Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but > > why be different? I could easily see implementations that make heavy use > > of literals missing this special case. > > I agree that changing from astring to quoted may seem silly, but what about > from astring to atom? Restricting from astring to atom is fine by me (since the I agree that the likelyhood of control characters is low). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 235 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ UBLS++++$ P+++$ L++(+++) E W+ N- o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-- b++ DI+++ G e h r y? ------END GEEK CODE BLOCK----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CGU0K05937 for ietf-imapext-bks; Wed, 12 Jun 2002 09:30:00 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (cni@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CGTwn05933 for ; Wed, 12 Jun 2002 09:29:58 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id JAA05969; Wed, 12 Jun 2002 09:29:49 -0700 (PDT) Date: Wed, 12 Jun 2002 09:28:02 -0700 (PDT) From: Mark Crispin Subject: Re: ACL2: Proposal to change ABNF for "rights" To: Rob Siemborski cc: Alexey Melnikov , IMAP Extensions WG In-Reply-To: Message-ID: 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: On Wed, 12 Jun 2002 12:23:52 -0400 (EDT), Rob Siemborski wrote: > Is there a compelling reason for this? Simplicity. Why allow in the syntax something that is meaningless? > Unless I'm missing something, > nothing in the IMAP base spec that can be a quoted string is disallowed > from being a literal You missed the internaldate argument to APPEND. > Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but > why be different? I could easily see implementations that make heavy use > of literals missing this special case. I agree that changing from astring to quoted may seem silly, but what about from astring to atom? Received: by above.proper.com (8.11.6/8.11.3) id g5CGRTR05865 for ietf-imapext-bks; Wed, 12 Jun 2002 09:27:29 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (bwi@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CGRRn05861 for ; Wed, 12 Jun 2002 09:27:28 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id JAA05957; Wed, 12 Jun 2002 09:27:24 -0700 (PDT) Date: Wed, 12 Jun 2002 09:25:20 -0700 (PDT) From: Mark Crispin Subject: re: ACL2: Proposal to change ABNF for "rights" To: Alexey Melnikov cc: IMAP Extensions WG In-Reply-To: <3D074582.428AB17F@messagingdirect.com> Message-ID: 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: On Wed, 12 Jun 2002 06:58:42 -0600, Alexey Melnikov wrote: > I've noticed yesterday that ABNF for "rights" was defined as "astring", > not just "quoted". > Anybody objects to changing this to quoted, because I don't see that > "rights" will ever contain control or 8bit characters. By that argument, rights should be an atom instead of quoted. It is possible to restrict from astring to atom, but not from quoted to atom, so if atom is the right thing this has to be done now. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CGNsH05797 for ietf-imapext-bks; Wed, 12 Jun 2002 09:23:54 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CGNqn05791 for ; Wed, 12 Jun 2002 09:23:52 -0700 (PDT) Received: from GOBO.ANDREW.CMU.EDU (GOBO.ANDREW.CMU.EDU [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g5CGNrNp018679; Wed, 12 Jun 2002 12:23:53 -0400 Date: Wed, 12 Jun 2002 12:23:52 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" In-Reply-To: <3D074582.428AB17F@messagingdirect.com> Message-ID: 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: On Wed, 12 Jun 2002, Alexey Melnikov wrote: > Anybody objects to changing this to quoted, because I don't see that > "rights" will ever contain control or 8bit characters. > Effectively this will prohibit the following: > > C: A001 SETACL ~/Mail/saved smith {2} > C: cp > > Comments? Is there a compelling reason for this? Unless I'm missing something, nothing in the IMAP base spec that can be a quoted string is disallowed from being a literal (e.g. nothing is just a quoted, it's always atleast a string). Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but why be different? I could easily see implementations that make heavy use of literals missing this special case. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 235 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ UBLS++++$ P+++$ L++(+++) E W+ N- o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-- b++ DI+++ G e h r y? ------END GEEK CODE BLOCK----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CG6Wr04956 for ietf-imapext-bks; Wed, 12 Jun 2002 09:06:32 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CG6Un04949 for ; Wed, 12 Jun 2002 09:06:30 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5CG6Vd17073; Wed, 12 Jun 2002 10:06:31 -0600 Message-ID: <3D074582.428AB17F@messagingdirect.com> Date: Wed, 12 Jun 2002 06:58:42 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: ACL2: Proposal to change ABNF for "rights" References: <3D0744F8.F062C28@messagingdirect.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've noticed yesterday that ABNF for "rights" was defined as "astring", not just "quoted". Anybody objects to changing this to quoted, because I don't see that "rights" will ever contain control or 8bit characters. Effectively this will prohibit the following: C: A001 SETACL ~/Mail/saved smith {2} C: cp Comments? Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CFic503369 for ietf-imapext-bks; Wed, 12 Jun 2002 08:44:38 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (stud@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CFian03365 for ; Wed, 12 Jun 2002 08:44:37 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id IAA05888; Wed, 12 Jun 2002 08:44:31 -0700 (PDT) Date: Wed, 12 Jun 2002 08:42:28 -0700 (PDT) From: Mark Crispin Subject: re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) To: Alexey Melnikov cc: IMAP Extensions WG , "Vladimir A. Butenko" In-Reply-To: <3D070AD5.51168DAE@messagingdirect.com> Message-ID: 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: It should be obvious, but I support Alexey's proposal. This will make it possible to implement both ACL and ACL2 in a straighforward manner, while not leaving ACL2 hampered with warts from needless ACL compatibility. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CFduN03227 for ietf-imapext-bks; Wed, 12 Jun 2002 08:39:56 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (rossi@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CFdsn03223 for ; Wed, 12 Jun 2002 08:39:55 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id IAA05863; Wed, 12 Jun 2002 08:39:29 -0700 (PDT) Date: Wed, 12 Jun 2002 08:37:46 -0700 (PDT) From: Mark Crispin Subject: re: SETACL/DELETEACL questions (was Re: ACL2: set of rights associated with READ-WRITE response code) To: Alexey Melnikov cc: IMAP Extensions WG In-Reply-To: <3D0669ED.61104915@messagingdirect.com> Message-ID: 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: On Tue, 11 Jun 2002 15:21:49 -0600, Alexey Melnikov wrote: > > What should a server do if it receives a SETACL which can not be performed > > without doing a DELETEACL of some other identifier/rights pair? [Think of > > what would become a "chgrp" in UNIX] > Server is allowed to do that. It must return new ACL in an unsolicited ACL > response anyway. How is it indicated to the client that this will happen *before* doing the SETACL? We're talking about client and end user surprise here. Such surprises will generate complaints. Received: by above.proper.com (8.11.6/8.11.3) id g5C9eJ612488 for ietf-imapext-bks; Wed, 12 Jun 2002 02:40:19 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5C9eHn12484 for ; Wed, 12 Jun 2002 02:40:17 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5C9eFd13589; Wed, 12 Jun 2002 03:40:16 -0600 Message-ID: <3D07157E.B9328C44@messagingdirect.com> Date: Wed, 12 Jun 2002 03:33:50 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: SETACL and tied-rights References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > [...] If rights are tied in an > implementation, the implementation must be conservative in granting > rights in response to SETACL commands--unless all rights in a tied > set are specified, none of that set should be included in the ACL > entry for that identifier. A client may discover the set of rights > which may be granted to a given identifier in the ACL for a given > mailbox by using the LISTRIGHTS command. > > This was in RFC 2086 as well. > > Do we really want these semantics? > > The effect of this is that it is mandatory to do a LISTRIGHTS prior to any > SETACL (and multiple LISTRIGHTS prior to any REPLACEACL), since otherwise > there is no way for a client to know how to grant a particular right to an > identifier. > > Presumably, the reason for these semantics is so a client can review the > impact of granting a particular right if it's tied to another. But will > any client actually do this? Or will clients just blindly do the > LISTRIGHTS to get the necessary incantation for SETACL? > > What I see is no savings of work for a client which cares about any side > effects due to tied-rights, but a lot of extra work for clients which do > not care. I tend to agree. I would rather have a new response code LISTRIGHTS that is returned in NO response to SETACL command. Imagine that the client wants to grant "cp" rights to a user "smith". The client instead of doing: C: A001 LISTRIGHTS ~/Mail/saved smith S: * LISTRIGHTS ~/Mail/saved smith la r swi cdext S: A001 OK Listrights completed C: A002 SETACL ~/Mail/saved smith cdextp S: A002 OK Setacl complete will do the following (this assumes that the server doesn't want to grant a right unless all tied rights are specified by the client): C: A001 SETACL ~/Mail/saved smith cp S: A001 NO [LISTRIGHTS la r swi cdext] No some rights are tied, specify both C: A002 SETACL ~/Mail/saved smith cdextp S: A002 OK Setacl complete C: A002 LISTRIGHTS ~/Mail/saved smith and if the server sets all tied rights automatically if at least one of them is specified (not recommended by the document but still possible): C: A001 SETACL ~/Mail/saved smith cp S: * ACL ~/Mail/saved smith cdextp S: A001 OK Setacl complete Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5C8mQ508011 for ietf-imapext-bks; Wed, 12 Jun 2002 01:48:26 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5C8mOn08005 for ; Wed, 12 Jun 2002 01:48:24 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5C8mMd13140; Wed, 12 Jun 2002 02:48:22 -0600 Message-ID: <3D070AD5.51168DAE@messagingdirect.com> Date: Wed, 12 Jun 2002 02:48:21 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG CC: Mark Crispin , "Vladimir A. Butenko" Subject: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > Alexey sent me a copy of his latest group. This document has some truly > amazing progress, and Alexey deserves to be congratulated. > > A suggestion, and some questions: > > The $ stuff is getting complicated. How about this instead: > > Eliminate $ entirely, and define "identifier" as one of: > anyone > authuser > owner > administrators > user= > group= > All other identifier names are reserved for future definition in an > extension or revision to the ACL2 specification. As Larry pointed out, this will break existing ACL implementations that treat these identifiers differently (probably all of them). However we can achieve this if we change syntax of ACL2 commands. Personally I am reluctant to change syntax drastically, I would very match like to keep existing parser as is. However, in Minneapolis we agreed to do another change: support multiple mailboxes in an ACL command (allow for mailboxes with wildcards or even several mailboxes). [Please, speak up now if you don't agree with this!!!] So, I need to tweak the syntax for ACL2 commands anyway in order to achieve this. So, I propose: 1). We change syntax of ACL commands (and possibly responses) a little bit: In all ACL commands mailbox is replaced with mailbox_list that is enclosed in "(" and ")". This will allow to unambiguously distinguish between ACL and ACL2. And this is a small change in an ACL parser, IMHO. acl_data = "ACL" SPACE mailbox_list *(SPACE identifier SPACE rights) deleteacl = "DELETEACL" SPACE mailbox_list SPACE identifier getacl = "GETACL" SPACE mailbox_list listrights = "LISTRIGHTS" SPACE mailbox_list SPACE identifier replaceacl = "REPLACEACL" SPACE mailbox_list *(SPACE identifier SPACE rights) setacl = "SETACL" SPACE mailbox_list SPACE identifier SPACE mod_rights mailbox_list = "(" 1*mailbox ")" ;; mailbox may contain pattern matching characters * and % ACL and LISTRIGHTS responses must be replaced with ACL2 and LISTRIGHTS2: acl_data = "ACL2" SPACE mailbox *(SPACE identifier SPACE rights) listrights_data = "LISTRIGHTS2" SPACE mailbox SPACE identifier SPACE rights *(SPACE rights) These responses have exactly the same syntax as ACL and LISTRIGTHS, but "identifier" here has ACL2 syntax as proposed by Mark. 2). Go with Mark's proposal In order to do that, I want to hear from people who've implemented ACL and willing to implement ACL that they agree to go along. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: by above.proper.com (8.11.6/8.11.3) id g5C8FJA00338 for ietf-imapext-bks; Wed, 12 Jun 2002 01:15:19 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5C8FHn00331 for ; Wed, 12 Jun 2002 01:15:17 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5C8F9d12907; Wed, 12 Jun 2002 02:15:11 -0600 Message-ID: <3D0669ED.61104915@messagingdirect.com> Date: Tue, 11 Jun 2002 15:21:49 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: SETACL/DELETEACL questions (was Re: ACL2: set of rights associated with READ-WRITE response code) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > What should a server do if it receives a SETACL which can not be performed > without doing a DELETEACL of some other identifier/rights pair? [Think of > what would become a "chgrp" in UNIX] Server is allowed to do that. It must return new ACL in an unsolicited ACL response anyway. > What should a server do if it receives a DELETEACL but the identifier can > not be deleted? Is it alright to treat it as a SETACL with server-defined > default rights? The server can either fail with NO (for example, in our implementation we don't allow to delete the last ACL entry on a mailbox) response or do as you describe (i.e. modify some other ACL(s) as well and return OK). > In particular, on UNIX I would probably treat a DELETEACL > of $anyone to mean "set $anyone to empty rights", of $group= to mean > "set $group= to same as $anyone", and of $owner to "all rights of > $anyone and $group= plus a". Is this alright? Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: by above.proper.com (8.11.6/8.11.3) id g5BKbjM26138 for ietf-imapext-bks; Tue, 11 Jun 2002 13:37:45 -0700 (PDT) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BKbhn26134 for ; Tue, 11 Jun 2002 13:37:43 -0700 (PDT) Received: from mailscan-out1.cac.washington.edu (mailscan-out1.cac.washington.edu [140.142.32.17]) by mxout3.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g5BKbh9L003972 for ; Tue, 11 Jun 2002 13:37:43 -0700 Received: FROM smtp.washington.edu BY mailscan-out1.cac.washington.edu ; Tue Jun 11 13:37:40 2002 -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.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g5BKbddf013634 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 11 Jun 2002 13:37:39 -0700 Date: Tue, 11 Jun 2002 13:37:42 -0700 (Pacific Daylight Time) From: Mark Crispin To: IMAP Extensions WG Subject: SETACL and tied-rights Message-ID: Organization: Networks & Distributed Computing 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: [...] If rights are tied in an implementation, the implementation must be conservative in granting rights in response to SETACL commands--unless all rights in a tied set are specified, none of that set should be included in the ACL entry for that identifier. A client may discover the set of rights which may be granted to a given identifier in the ACL for a given mailbox by using the LISTRIGHTS command. This was in RFC 2086 as well. Do we really want these semantics? The effect of this is that it is mandatory to do a LISTRIGHTS prior to any SETACL (and multiple LISTRIGHTS prior to any REPLACEACL), since otherwise there is no way for a client to know how to grant a particular right to an identifier. Presumably, the reason for these semantics is so a client can review the impact of granting a particular right if it's tied to another. But will any client actually do this? Or will clients just blindly do the LISTRIGHTS to get the necessary incantation for SETACL? What I see is no savings of work for a client which cares about any side effects due to tied-rights, but a lot of extra work for clients which do not care. Received: by above.proper.com (8.11.6/8.11.3) id g5ABJOS26041 for ietf-imapext-bks; Mon, 10 Jun 2002 04:19:24 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ABJNn26037 for ; Mon, 10 Jun 2002 04:19:23 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28588; Mon, 10 Jun 2002 07:18:49 -0400 (EDT) Message-Id: <200206101118.HAA28588@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-acl-04.txt Date: Mon, 10 Jun 2002 07:18:49 -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 ACL extension Author(s) : A. Melnikov Filename : draft-ietf-imapext-acl-04.txt Pages : 9 Date : 06-Jun-02 The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-acl-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-acl-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: <20020607140110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-acl-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-acl-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607140110.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g58I1P611801 for ietf-imapext-bks; Sat, 8 Jun 2002 11:01:25 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (wwoodf@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g58I1Mn11797 for ; Sat, 8 Jun 2002 11:01:22 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA00848; Sat, 8 Jun 2002 11:00:42 -0700 (PDT) Date: Sat, 8 Jun 2002 10:45:43 -0700 (PDT) From: Mark Crispin Subject: Re: ACL2: set of rights associated with READ-WRITE response code To: Lawrence Greenfield cc: Alexey Melnikov , Cyrus Daboo , IMAP Extensions WG In-Reply-To: <200206081743.g58HhiNo007448@lin2.andrew.cmu.edu> Message-ID: 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: On Sat, 8 Jun 2002 13:43:44 -0400, Lawrence Greenfield wrote: > Do we know of any existing clients that use READ-ONLY/READ-WRITE for > anything? What do they use them for? What's the benefit of sending > this back to the client? Pine checks the READ-ONLY flag in quite a few places. The best way to think about READ-ONLY is that it means you can't do anything to the mailbox that someone else would see. You can, however, alter any flags listed as PERMANENTFLAGS. I think matching that to the i and e bits sounds right, although the swt bits may affect things if they are PERMANENTFLAGS. By the way, the definition of the w right should be called "write flags" instead of "write". It's too late to change it now, but the i right should really be the w right, and the current w right should be something like f. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g58HhkW11068 for ietf-imapext-bks; Sat, 8 Jun 2002 10:43:46 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g58Hhjn11062 for ; Sat, 8 Jun 2002 10:43:45 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g58HhiNo007448; Sat, 8 Jun 2002 13:43:44 -0400 Date: Sat, 8 Jun 2002 13:43:44 -0400 Message-Id: <200206081743.g58HhiNo007448@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Alexey Melnikov , Mark Crispin , Cyrus Daboo Cc: IMAP Extensions WG In-reply-to: <2147483647.1023543615@[10.0.1.4]> Subject: Re: ACL2: set of rights associated with READ-WRITE response code References: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> <2147483647.1023542206@[10.0.1.4]> <200206081726.g58HQQNo007436@lin2.andrew.cmu.edu> <2147483647.1023543615@[10.0.1.4]> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Sat, 08 Jun 2002 13:40:15 -0400 From: Cyrus Daboo [...] OK, this implies then that READ-ONLY should be returned if both the 'i' and 'e' bits are off, irrespective of the 's', 'w' and 't' bits which only control flag state. 'i' and 'e' actually control the content of the mailbox. So how about this: The server MUST include a READ-ONLY prefix in the tagged OK response to a SELECT command if both the 'i' and 'e' ACL rights are off for the current user. The server SHOULD include a READ-WRITE prefix in the tagged OK response if either the 'i' or 'e' ACL rights is on for the current user. This fits in with the base-spec requirement of SHOULD for READ-WRITE and MUST for READ-ONLY. Do we know of any existing clients that use READ-ONLY/READ-WRITE for anything? What do they use them for? What's the benefit of sending this back to the client? Larry Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g58HeXq11025 for ietf-imapext-bks; Sat, 8 Jun 2002 10:40:33 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g58HeWn11021 for ; Sat, 8 Jun 2002 10:40:32 -0700 (PDT) Received: from [10.0.1.4] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA22728; Sat, 8 Jun 2002 13:37:34 -0400 (EDT) Date: Sat, 08 Jun 2002 13:40:15 -0400 From: Cyrus Daboo To: Lawrence Greenfield , Mark Crispin , Alexey Melnikov cc: IMAP Extensions WG Subject: Re: ACL2: set of rights associated with READ-WRITE response code Message-ID: <2147483647.1023543615@[10.0.1.4]> In-Reply-To: <200206081726.g58HQQNo007436@lin2.andrew.cmu.edu> References: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> <2147483647.1023542206@[10.0.1.4]> <200206081726.g58HQQNo007436@lin2.andrew.cmu.edu> X-Mailer: Mulberry/3.0.0a2 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On Saturday, June 8, 2002 1:26 PM -0400 Lawrence Greenfield wrote: | This is fine with me, though this doesn't appear to totally agree with | the text in the IMAP draft (section 6.3.1): | | Read-only access through SELECT differs from the EXAMINE command | in that certain read-only mailboxes MAY permit the change of | permanent state on a per-user (as opposed to global) basis. | Netnews messages marked in a server-based .newsrc file are an | example of such per-user permanent state that can be modified | with read-only mailboxes. | | Another possibility is for ACL to recommend that servers implementing | ACL just not return either READ-ONLY or READ-WRITE in response to a | SELECT. OK, this implies then that READ-ONLY should be returned if both the 'i' and 'e' bits are off, irrespective of the 's', 'w' and 't' bits which only control flag state. 'i' and 'e' actually control the content of the mailbox. So how about this: The server MUST include a READ-ONLY prefix in the tagged OK response to a SELECT command if both the 'i' and 'e' ACL rights are off for the current user. The server SHOULD include a READ-WRITE prefix in the tagged OK response if either the 'i' or 'e' ACL rights is on for the current user. This fits in with the base-spec requirement of SHOULD for READ-WRITE and MUST for READ-ONLY. -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g58HQTf10785 for ietf-imapext-bks; Sat, 8 Jun 2002 10:26:29 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g58HQSn10781 for ; Sat, 8 Jun 2002 10:26:28 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g58HQQNo007436; Sat, 8 Jun 2002 13:26:27 -0400 Date: Sat, 8 Jun 2002 13:26:26 -0400 Message-Id: <200206081726.g58HQQNo007436@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Mark Crispin , Alexey Melnikov , Cyrus Daboo Cc: IMAP Extensions WG In-reply-to: <2147483647.1023542206@[10.0.1.4]> Subject: Re: ACL2: set of rights associated with READ-WRITE response code References: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> <2147483647.1023542206@[10.0.1.4]> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Sat, 08 Jun 2002 13:16:47 -0400 From: Cyrus Daboo [...] Therefore I argue that READ-WRITE status should appear whenever any ACL bit that controls a change in the masilbox content is on. i.e. read_write = 's' || 'w' || 'i' || 't' || 'e'; If all of those are off then the mailbox is READ-ONLY. This is fine with me, though this doesn't appear to totally agree with the text in the IMAP draft (section 6.3.1): Read-only access through SELECT differs from the EXAMINE command in that certain read-only mailboxes MAY permit the change of permanent state on a per-user (as opposed to global) basis. Netnews messages marked in a server-based .newsrc file are an example of such per-user permanent state that can be modified with read-only mailboxes. Another possibility is for ACL to recommend that servers implementing ACL just not return either READ-ONLY or READ-WRITE in response to a SELECT. Larry Received: by above.proper.com (8.11.6/8.11.3) id g58HH8M10649 for ietf-imapext-bks; Sat, 8 Jun 2002 10:17:08 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g58HH6n10645 for ; Sat, 8 Jun 2002 10:17:06 -0700 (PDT) Received: from [10.0.1.4] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA22624; Sat, 8 Jun 2002 13:14:05 -0400 (EDT) Date: Sat, 08 Jun 2002 13:16:47 -0400 From: Cyrus Daboo To: Lawrence Greenfield , Alexey Melnikov , Mark Crispin cc: IMAP Extensions WG Subject: Re: ACL2: set of rights associated with READ-WRITE response code Message-ID: <2147483647.1023542206@[10.0.1.4]> In-Reply-To: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> References: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> X-Mailer: Mulberry/3.0.0a2 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On Friday, June 7, 2002 2:50 PM -0400 Lawrence Greenfield wrote: | What Alexey is referring to here is a fairly minor problem, the | [READ-ONLY] and [READ-WRITE] status responses. These responses are | basically useless since they don't convey any information to the | client. Does "READ-WRITE" mean "able to modify everything"? "able | to modify at least one thing"? ACL gives the client a much better | notion of what operations are likely to succeed. | | ACL2 should just recommend one interpretation and tie READ-WRITE to a | particular right. It's not a big deal. You need to consider READ-WRITE/READ-ONLY in the context of non-ACL aware clients. A non-ACL client will likely use that indicator to determine what commands to enable in its UI when that mailbox is open. e.g. for a READ-ONLY mailbox the client will disable flag changing commands, expunge, prevent drag and drop of messages into the mailbox pane etc. The problem arises when some ACL bits are on and others are not. For example if 'w' is off, but 'i' is on, and 'w' controls the R-W/R-O status, then the mailbox will appear as READ-ONLY. Non-ACL clients might then disable the ability to copy into or append to that mailbox, even though that is allowed by the ACL 'i' bit. This is bad as it prevents the user from being able to do a valid operation. If the status were reported as READ-WRITE, then copy/append would be enabled for the user and would work fine. In this case the 'negative' aspect is that the flag change commands would be enabled but fail with a NO response when the user attempts it. I regard this as the lesser of two evils in that valid commands can at least be executed and there is a reasonable failure mode for non-valid commands. Therefore I argue that READ-WRITE status should appear whenever any ACL bit that controls a change in the masilbox content is on. i.e. read_write = 's' || 'w' || 'i' || 't' || 'e'; If all of those are off then the mailbox is READ-ONLY. -- Cyrus Daboo Received: by above.proper.com (8.11.6/8.11.3) id g57KWF018636 for ietf-imapext-bks; Fri, 7 Jun 2002 13:32:15 -0700 (PDT) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g57KWDn18632 for ; Fri, 7 Jun 2002 13:32:13 -0700 (PDT) Received: from mailscan-out3.cac.washington.edu (mailscan-out3.cac.washington.edu [140.142.32.18]) by mxout1.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g57KWBSJ025280 for ; Fri, 7 Jun 2002 13:32:16 -0700 Received: FROM smtp.washington.edu BY mailscan-out3.cac.washington.edu ; Fri Jun 07 13:32:10 2002 -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.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g57KWAPT000515 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Jun 2002 13:32:10 -0700 Date: Fri, 7 Jun 2002 13:32:10 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lawrence Greenfield cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: ACL2: set of rights associated with READ-WRITE response code In-Reply-To: <200206071855.g57ItBNo004596@lin2.andrew.cmu.edu> Message-ID: Organization: Networks & Distributed Computing 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: On Fri, 7 Jun 2002, Lawrence Greenfield wrote: > Such a change would be completely incompatible with existing ACL > implementations, which already have widespread adaption and good > interoperability. We are talking about ACL2, not ACL. I can assure you that if I implemented ACL in UW imapd (and c-client/Pine) in the way that made the most sense for us, the result would be completely non-interoperable. It would break existing implementations which expect the Cyrus type of interpretation, and create an incredible mess. It would also be completely compliant with RFC 2086. Fortunately, I am not the sort of person who deliberately does harmful things to break a specification. I have put off implementing ACL in UW imapd in the hope of having a fixed specification. The whole point of ACL2 is to create an interoperable specification that we can all live with, and give it a different name so that we won't have interoperability problems with ACL. It may be necessary to have a switch (or different commands) so a client of a server that supports both ACL and ACL2 can say "I want ACL2 semantics." That's fine. But, please!!, let's get it right this time. Or we will end up with multiple compliant non-interoperable implementations. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: by above.proper.com (8.11.6/8.11.3) id g57ItDY16720 for ietf-imapext-bks; Fri, 7 Jun 2002 11:55:13 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g57ItCn16715 for ; Fri, 7 Jun 2002 11:55:12 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g57ItBNo004596; Fri, 7 Jun 2002 14:55:11 -0400 Date: Fri, 7 Jun 2002 14:55:11 -0400 Message-Id: <200206071855.g57ItBNo004596@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Alexey Melnikov , Mark Crispin Cc: IMAP Extensions WG In-reply-to: Subject: Re: ACL2: set of rights associated with READ-WRITE response code References: User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Thu, 6 Jun 2002 13:24:42 -0700 (Pacific Daylight Time) From: Mark Crispin Eliminate $ entirely, and define "identifier" as one of: anyone authuser owner administrators user= group= All other identifier names are reserved for future definition in an extension or revision to the ACL2 specification. Such a change would be completely incompatible with existing ACL implementations, which already have widespread adaption and good interoperability. Larry Received: by above.proper.com (8.11.6/8.11.3) id g57IoYf16257 for ietf-imapext-bks; Fri, 7 Jun 2002 11:50:34 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g57IoXn16253 for ; Fri, 7 Jun 2002 11:50:33 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g57IoWNo004588; Fri, 7 Jun 2002 14:50:32 -0400 Date: Fri, 7 Jun 2002 14:50:32 -0400 Message-Id: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Alexey Melnikov , Mark Crispin Cc: IMAP Extensions WG In-reply-to: Subject: Re: ACL2: set of rights associated with READ-WRITE response code References: User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Thu, 6 Jun 2002 05:53:18 -0700 (PDT) From: Mark Crispin On Thu, 06 Jun 2002 03:46:14 -0600, Alexey Melnikov wrote: > Cyrus, Communigate and CDC IntraStore are completely different > implementations of the ACL RFC and they all behave differently! Yes, and if UW imapd implemented RFC 2086 there would have been a fourth completely different implementation that would have been even more different than the other three. What Alexey is referring to here is a fairly minor problem, the [READ-ONLY] and [READ-WRITE] status responses. These responses are basically useless since they don't convey any information to the client. Does "READ-WRITE" mean "able to modify everything"? "able to modify at least one thing"? ACL gives the client a much better notion of what operations are likely to succeed. ACL2 should just recommend one interpretation and tie READ-WRITE to a particular right. It's not a big deal. Larry Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g57Huvg15410 for ietf-imapext-bks; Fri, 7 Jun 2002 10:56:57 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (trungt@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g57Hutn15405 for ; Fri, 7 Jun 2002 10:56:55 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id KAA29107; Fri, 7 Jun 2002 10:56:50 -0700 (PDT) Date: Fri, 7 Jun 2002 10:52:04 -0700 (PDT) From: Mark Crispin Subject: Re: ACL2: set of rights associated with READ-WRITE response code To: Steve Hole cc: Alexey Melnikov , IMAP Extensions WG In-Reply-To: Message-ID: 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: On Fri, 7 Jun 2002 11:47:16 -0700, Steve Hole wrote: > > Eliminate $ entirely, and define "identifier" as one of: > > anyone > > authuser > > owner > > administrators > > user= > > group= > > All other identifier names are reserved for future definition in an > > extension or revision to the ACL2 specification. > This is precisely what we arrived at in the "authid" acap dataset class as > well. As I wrote authid, I think it's a good idea. Cool! We're starting to get convergence! This would indeed remove many of the problems that I have with RFC 2086. I would be happy to withdraw my earlier proposal (in Alexey's draft) in favor of this one. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g57Hnn715303 for ietf-imapext-bks; Fri, 7 Jun 2002 10:49:49 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g57Hnmn15299 for ; Fri, 7 Jun 2002 10:49:48 -0700 (PDT) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g57Hnnd03425; Fri, 7 Jun 2002 11:49:49 -0600 From: Steve Hole Date: Fri, 7 Jun 2002 11:47:16 -0700 To: Mark Crispin Subject: Re: ACL2: set of rights associated with READ-WRITE response code Cc: Alexey Melnikov , IMAP Extensions WG In-Reply-To: References: <3CFF64FD.6942854E@messagingdirect.com> Message-ID: X-Mailer: Execmail for Linux Phoenix a1 Build (5) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g57Hnmn15300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 6 Jun 2002 13:24:42 -0700 (Pacific Daylight Time) Mark Crispin wrote: > Eliminate $ entirely, and define "identifier" as one of: > anyone > authuser > owner > administrators > user= > group= > All other identifier names are reserved for future definition in an > extension or revision to the ACL2 specification. This is precisely what we arrived at in the "authid" acap dataset class as well. As I wrote authid, I think it's a good idea. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g56KOd006109 for ietf-imapext-bks; Thu, 6 Jun 2002 13:24:39 -0700 (PDT) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g56KOcn06105 for ; Thu, 6 Jun 2002 13:24:38 -0700 (PDT) Received: from mailscan-out1.cac.washington.edu (mailscan-out1.cac.washington.edu [140.142.32.17]) by mxout3.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g56KOe9L002434 for ; Thu, 6 Jun 2002 13:24:40 -0700 Received: FROM smtp.washington.edu BY mailscan-out1.cac.washington.edu ; Thu Jun 06 13:24:39 2002 -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.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g56KOdPT014156 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Jun 2002 13:24:39 -0700 Date: Thu, 6 Jun 2002 13:24:42 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: ACL2: set of rights associated with READ-WRITE response code In-Reply-To: <3CFF64FD.6942854E@messagingdirect.com> Message-ID: Organization: Networks & Distributed Computing 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: Alexey sent me a copy of his latest group. This document has some truly amazing progress, and Alexey deserves to be congratulated. A suggestion, and some questions: The $ stuff is getting complicated. How about this instead: Eliminate $ entirely, and define "identifier" as one of: anyone authuser owner administrators user= group= All other identifier names are reserved for future definition in an extension or revision to the ACL2 specification. What should a server do if it receives a SETACL which can not be performed without doing a DELETEACL of some other identifier/rights pair? [Think of what would become a "chgrp" in UNIX] What should a server do if it receives a DELETEACL but the identifier can not be deleted? Is it alright to treat it as a SETACL with server-defined default rights? In particular, on UNIX I would probably treat a DELETEACL of $anyone to mean "set $anyone to empty rights", of $group= to mean "set $group= to same as $anyone", and of $owner to "all rights of $anyone and $group= plus a". Is this alright? -- Mark -- Received: by above.proper.com (8.11.6/8.11.3) id g56CvaQ03612 for ietf-imapext-bks; Thu, 6 Jun 2002 05:57:36 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (paul@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g56CvYn03607 for ; Thu, 6 Jun 2002 05:57:34 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id FAA27393; Thu, 6 Jun 2002 05:57:19 -0700 (PDT) Date: Thu, 6 Jun 2002 05:53:18 -0700 (PDT) From: Mark Crispin Subject: re: ACL2: set of rights associated with READ-WRITE response code To: Alexey Melnikov cc: IMAP Extensions WG In-Reply-To: <3CFF2F66.67508CC9@messagingdirect.com> Message-ID: 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: On Thu, 06 Jun 2002 03:46:14 -0600, Alexey Melnikov wrote: > Cyrus, Communigate and CDC IntraStore are completely different > implementations of the ACL RFC and they all behave differently! Yes, and if UW imapd implemented RFC 2086 there would have been a fourth completely different implementation that would have been even more different than the other three. I'm worried that we've still not solved the fundamental problems in RFC 2086. Received: by above.proper.com (8.11.6/8.11.3) id g569kEG21209 for ietf-imapext-bks; Thu, 6 Jun 2002 02:46:14 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g569kDn21200 for ; Thu, 6 Jun 2002 02:46:13 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g569kAd20065; Thu, 6 Jun 2002 03:46:10 -0600 Message-ID: <3CFF2F66.67508CC9@messagingdirect.com> Date: Thu, 06 Jun 2002 03:46:14 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: ACL2: set of rights associated with READ-WRITE response code Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I did a bit of research and found out the following: Cyrus and MessagingDirect server: if either "w" or "t" are allowed for the current user, server reports READ-WRITE Communigate: when the user has "s" right. CDC IntraStore: when the user has "w" right. Cyrus, Communigate and CDC IntraStore are completely different implementations of the ACL RFC and they all behave differently! Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: by above.proper.com (8.11.6/8.11.3) id g569jrA21136 for ietf-imapext-bks; Thu, 6 Jun 2002 02:45:53 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g569jqn21129 for ; Thu, 6 Jun 2002 02:45:52 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g569jpd20050; Thu, 6 Jun 2002 03:45:51 -0600 Message-ID: <3CFF2F53.AFD74026@messagingdirect.com> Date: Thu, 06 Jun 2002 03:45:55 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: ACL2: rights required for different IMAP command Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As you will see in the new revision, I've added a new section that describes in details which rights should be checked to implement different IMAP commands, which rights are mandatory and which are optional. Here is what left unresolved: SUBSCRIBE - "l" right is required only if the server checks for mailbox existence when performing SUBSCRIBE. Allow if the user has "r" right? GETACL - "a" right on the mailbox. CDC IntraStore: "a". CMU: "r", "a", admin or owner. MD: "r" or "a" or owner. No consensus if "r" should be allowed. John would prefer not to use "r", but he is fine if somebody insists on using it. The main argument against allowing "r" for GETACL is that in this case GETACL can possibly disclose some identifiers existing on the mail system to an authenticated user with read access. On the other hand "r" is used for a mailbox metadata and seems appropriate. LISTRIGHTS - Same as GETACL? or just "r"? GETQUOTA - no rights required CMU server checks if the user belongs to administrators, I don't know why SETQUOTA - "a" right Some implementations allows to set quota when the user has "r" right as well. Should we allow that? Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g569h3S20845 for ietf-imapext-bks; Thu, 6 Jun 2002 02:43:03 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g569h2n20839 for ; Thu, 6 Jun 2002 02:43:02 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g569h1d20010; Thu, 6 Jun 2002 03:43:01 -0600 Message-ID: <3CFF2EA9.D7882939@messagingdirect.com> Date: Thu, 06 Jun 2002 03:43:05 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: ACL2: escape character for special identifiers and groups. Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a list of comments on the issue I've got during IMAPEXT lunch at Minneapolis IETF (in no particular order, I hope it is not too intricate to understand): Could use "$$" prefix for user names beginning "$" and "$-" for user names beginning from "-". Escape or reject? No group starting with "$-" or "$$" (John). Use "\" as escape character for leading "$" or "-"? Alternatively we can change syntax of all ACL commands (Chris) Chris objects to escape mechanism, he prefers to reject. We couldn't reach any consensus on the matter and I was asked to post a question to the mailing list if any existing server ACL implementation is using "$" as a leading character in usernames. The only thing was clear that the participants were reluctant to change syntax of ACL commands, as they would rather reuse existing IMAP ACL parsers. As Jutta pointed out in her recent post we can use "/" instead of "$". This might work, as probably none of the existing ACL implementations will accept usernames with "/" character. Alexey Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g569bmD19899 for ietf-imapext-bks; Thu, 6 Jun 2002 02:37:48 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g569bln19891 for ; Thu, 6 Jun 2002 02:37:47 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g569bjd19911; Thu, 6 Jun 2002 03:37:46 -0600 Message-ID: <3CFF2D6A.5E6470B0@messagingdirect.com> Date: Thu, 06 Jun 2002 03:37:46 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: New revision of ACL2 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've submitted a new revision of ACL2 to the draft editor. There are four major groups of open issues left in the document. These issues can be shortly described as follows: 1). escape character for special identifiers and groups. 2). rights required for different IMAP commands. 3). set of rights associated with READ-WRITE response code. 4). changing ACLs for a list of mailboxes. I will post a separate message for each group of issues. Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53Egmp28462 for ietf-imapext-bks; Mon, 3 Jun 2002 07:42:48 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53Egkg28458 for ; Mon, 3 Jun 2002 07:42:46 -0700 (PDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g53EggO08568 for ; Mon, 3 Jun 2002 10:42:42 -0400 Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with SMTP id g53Eggk64694 for ; Mon, 3 Jun 2002 10:42:42 -0400 Message-ID: <07e601c20b0c$ea644c70$40280209@watson.ibm.com> From: "Barry Leiba" To: "IMAP extensions Mailing List" Subject: Re: Stalled? Date: Mon, 3 Jun 2002 10:42:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I will get a List Extensions update out within the next couple of days. Barry -- Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5SB54i07461 for ietf-imapext-bks; Fri, 28 Jun 2002 04:05:04 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5SB52w07450 for ; Fri, 28 Jun 2002 04:05:02 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5SB52d17644; Fri, 28 Jun 2002 05:05:02 -0600 Message-ID: <3D1C42DD.EC41DF67@messagingdirect.com> Date: Fri, 28 Jun 2002 05:05:01 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Re: ACL2: rights required for different IMAP command References: <3CFF2F53.AFD74026@messagingdirect.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I haven't heard any public comments on this topic! (See some comments below) Alexey Melnikov wrote: > As you will see in the new revision, I've added a new section that > describes in details which rights should be checked to implement > different IMAP commands, which rights are mandatory and which are > optional. > Here is what left unresolved: > > SUBSCRIBE - "l" right is required only if the server checks for > mailbox existence > when performing SUBSCRIBE. > > Allow if the user has "r" right? > > GETACL - "a" right on the mailbox. > > CDC IntraStore: "a". > CMU: "r", "a", admin or owner. > MD: "r" or "a" or owner. > > No consensus if "r" should be allowed. John would prefer not to use "r", > but he is fine if somebody insists on using it. The main argument > against allowing "r" for GETACL is that in this case GETACL can > possibly disclose some identifiers existing on the mail system to an > authenticated user with read access. > On the other hand "r" is used for a mailbox metadata and seems > appropriate. > > LISTRIGHTS - Same as GETACL? or just "r"? > > GETQUOTA - no rights required > CMU server checks if the user belongs to administrators, I don't know > why > > SETQUOTA - "a" right > Some implementations allows to set quota when the user has "r" right as > well. Should we allow that? As a result of my private exchange with Vladimir, I am going to remove the requirement to use "a" for SETQUOTA, because it operates on a quota root, that is not necessary a mailbox. Instead this will be "implementation dependent". Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5PB4MD11887 for ietf-imapext-bks; Tue, 25 Jun 2002 04:04:22 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PB4Mw11883 for ; Tue, 25 Jun 2002 04:04:22 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29679; Tue, 25 Jun 2002 07:03:39 -0400 (EDT) Message-Id: <200206251103.HAA29679@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-thread-11.txt Date: Tue, 25 Jun 2002 07:03:39 -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 - THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-thread-11.txt Pages : 14 Date : 24-Jun-02 This document describes the server-based threading extension to the IMAP4rev1 protocol. This extension provides substantial performance improvements for IMAP clients which offer threaded views. A server which supports this extension indicates this with more or more capability names consisting of 'THREAD-' followed by a supported threading algorithm name as described in this document. This provides for future upwards-compatible extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-thread-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-thread-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-thread-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: <20020624144059.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-thread-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-thread-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020624144059.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id g5PB4J111877 for ietf-imapext-bks; Tue, 25 Jun 2002 04:04:19 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PB4Hw11870 for ; Tue, 25 Jun 2002 04:04:18 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29658; Tue, 25 Jun 2002 07:03:35 -0400 (EDT) Message-Id: <200206251103.HAA29658@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-sort-10.txt Date: Tue, 25 Jun 2002 07:03:35 -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 - SORT EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-sort-10.txt Pages : 10 Date : 24-Jun-02 This document describes an experimental server-based sorting extension to the IMAP4rev1 protocol, as implemented by the University of Washington's IMAP toolkit. This extension provides substantial performance improvements for IMAP clients which offer sorted views. A server which supports this extension indicates this with a capability name of 'SORT'. Client implementations SHOULD accept any capability name which begins with 'SORT' as indicating support for the extension described in this document. This provides for future upwards-compatible extensions. At the time of this document was written, the IMAP Extensions Working Group (IETF-IMAPEXT) was considering upwards-compatible additions to the SORT extension described in this document, tenatively called the SORT2 extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sort-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-sort-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: <20020624144050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020624144050.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5OBnC414252 for ietf-imapext-bks; Mon, 24 Jun 2002 04:49:12 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5OBnBw14248 for ; Mon, 24 Jun 2002 04:49:11 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00639; Mon, 24 Jun 2002 07:48:29 -0400 (EDT) Message-Id: <200206241148.HAA00639@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-thread-10.txt Date: Mon, 24 Jun 2002 07:48:28 -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 - THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-thread-10.txt Pages : 14 Date : 21-Jun-02 This document describes the server-based threading extension to the IMAP4rev1 protocol. This extension provides substantial performance improvements for IMAP clients which offer threaded views. A server which supports this extension indicates this with more or more capability names consisting of 'THREAD-' followed by a supported threading algorithm name as described in this document. This provides for future upwards-compatible extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-thread-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-thread-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-thread-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: <20020621122018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-thread-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-thread-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020621122018.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5IMSYm24520 for ietf-imapext-bks; Tue, 18 Jun 2002 15:28:34 -0700 (PDT) Received: from atg.aciworldwide.com ([139.142.180.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IMS9n24498; Tue, 18 Jun 2002 15:28:09 -0700 (PDT) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g5IMSBgS052380; Tue, 18 Jun 2002 16:28:11 -0600 (MDT) Message-Id: <200206182228.g5IMSBgS052380@atg.aciworldwide.com> To: IMAP Interest Groups: ; Subject: IMAP Channel Draft version 2 released X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! Organization: ACI Worldwide - Advanced Technology Group X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Tue, 18 Jun 2002 16:28:11 -0600 From: Lyndon Nerenberg Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've pushed version 02 of the Channel draft to the ID editor. Early access can be had at: http://atg.aciworldwide.com/draft-nerenberg-imap-channel-02.txt Diffs from version 01: Changed to use instead of . This allows retrieval of headers and MIME structure. returns a , not (to match syntax). Add missing SP tokens to grammar. Grammar fix to allow foo: as a valid URI in a request. Add UID CHANNEL. Clarify response when client issues a command with an unsupported scheme. Add section on command sequencing. Note arbitrary ordering of untagged responses. Replace URI-reference with absoluteURI. The IMAP server can't maintain the state required to deal with relative URIs. This also solves an ambiguity between parsing "NIL" as or as a relative URI. --lyndon _ 12 + 144 + 20 + 3(\/4) 2 ---------------------- + 5(11) = 9 + 0 7 A dozen, a gross and a score, Plus three times the square root of four, Divided by seven, Plus five times eleven, Equals nine squared plus zero, no more! Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EDeZo05390 for ietf-imapext-bks; Fri, 14 Jun 2002 06:40:35 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EDeYn05386 for ; Fri, 14 Jun 2002 06:40:34 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5EDeSd06965; Fri, 14 Jun 2002 07:40:28 -0600 Message-ID: <3D09F24A.B40CC2A2@messagingdirect.com> Date: Fri, 14 Jun 2002 07:40:26 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lyndon Nerenberg CC: Rob Siemborski , Mark Crispin , IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" References: <200206131737.g5DHbdgS023085@atg.aciworldwide.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lyndon Nerenberg wrote: > > My experience with writing parsers in non-blocking or asynchronous IO model > > (i.e. when read from the socket may return that literal was not completely > > received by TCP stack) tells that it is a pain in the ass to write a parser for > > any command that uses literals. Why? Because you have to save state if there is > > not enough data. > > This argument doesn't hold. You can get a short read anywhere, not > just inside a literal. Well, I guess I should have explained our architecture in the first place. In our IMAP server we have two levels of parsing. The low level parser always guaranties that the server has a full text line till CRLF before it hands over the line to the high level parser. This is based on one very good property of IMAP protocol: any protocol line is terminated with CRLF, whether it is CRLF at the end of the command, after "}" in literals or in the middle of a RFC822 message. Thus, in our architecture low level parser always guaranties that we never get a short read while parsing a quoted string. That is not true for literals. So, after this clarification, my argument still holds. (I know of no other sane way of parsing IMAP with non blocking IO that doesn't use something like our low level parser). > And I would argue that literals are the > *easiest* string form to deal with: you already know how much data to > read therefore you don't need to keep any state on the data stream > itself, just a counter that you decrement as you read in the bytes. Not just this state. Counter is the least of the problems. I was talking about the current state of the command parser. For example, when parsing arguments of a SEARCH (or a FETCH) command, the parser can be several levels down parsing nested SEARCH criteria when it encounters a literal. Now there are couple choices how to deal with this: 1). throw away already constructed search state and reparse SEARCH command as soon as the literal is fully received or 2). save the current search state and switch to literal receiving mode. Both cases will require saving some non-trivial state, but 1) , IMHO, is inefficient, especially if there are several literals. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5EArC527715 for ietf-imapext-bks; Fri, 14 Jun 2002 03:53:12 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5EArBn27707 for ; Fri, 14 Jun 2002 03:53:11 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5EAr3d05609; Fri, 14 Jun 2002 04:53:04 -0600 Message-ID: <3D09CB0C.FA8D7BC1@messagingdirect.com> Date: Fri, 14 Jun 2002 04:53:01 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Showalter CC: ietf-imapext@imc.org Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights associated with READ-WRITE response code) References: <1023999339.91332.23.camel@funhouse.mirapoint.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tim Showalter wrote: > > How about a single ACL command with subcommands? > > Not a bad idea; better than SETACL2. That is fine with me. What about the syntax after ACL ? Are people happy with my proposal. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DKH6Q08834 for ietf-imapext-bks; Thu, 13 Jun 2002 13:17:06 -0700 (PDT) Received: from fp.mirapoint.com (fp.mirapoint.com [63.107.133.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DKH4n08830 for ; Thu, 13 Jun 2002 13:17:04 -0700 (PDT) Received: from alpo.mirapoint.com (alpo.mirapoint.com [192.168.0.19]) by fp.mirapoint.com (Mirapoint Messaging Server MOS 3.2.0.40 FastPath) with ESMTP id AAH06984; Thu, 13 Jun 2002 13:17:02 -0700 (PDT) Received: from funhouse.mirapoint.com (funhouse.mirapoint.com [192.168.0.92]) by alpo.mirapoint.com (Mirapoint Messaging Server MOS 3.2.0.40) with ESMTP id ADK00685; Thu, 13 Jun 2002 13:17:02 -0700 (PDT) Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) From: Tim Showalter To: ietf-imapext@imc.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 13 Jun 2002 14:15:39 -0600 Message-Id: <1023999339.91332.23.camel@funhouse.mirapoint.com> Mime-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > How about a single ACL command with subcommands? Not a bad idea; better than SETACL2. Tim Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DJpdH08353 for ietf-imapext-bks; Thu, 13 Jun 2002 12:51:39 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (suave@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DJpbn08349 for ; Thu, 13 Jun 2002 12:51:38 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id MAA07514; Thu, 13 Jun 2002 12:51:36 -0700 (PDT) Date: Thu, 13 Jun 2002 12:40:01 -0700 (PDT) From: Mark Crispin Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) To: Tim Showalter cc: IMAP Extensions WG In-Reply-To: <1023995067.91332.6.camel@funhouse.mirapoint.com> Message-ID: 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: On 13 Jun 2002 13:04:27 -0600, Tim Showalter wrote: > I like the proposed identifier format; it's cleaner than what we had > before. If I were implementing an ACL server from scratch I would want > to use something like that. Great! > But there's running ACL code out there that doesn't work that way. In > order for a sane upgrade path for Cyrus (and its progeny) the ACL2 > commands will have to be supported seperately; in order to make these > work in some sane way, we'll need some seperate syntax. In case it was unclear; I have no objection whatsoever to a different set of commands for ACL2. I always felt that instead of the current GETACL, LISTRIGHTS, and MYRIGHTS commands, we should use an extended form of LIST. But LIST extensions seems to have fallen by the wayside, sigh. How about a single ACL command with subcommands? SETACL => ACL STORE DELETEACL => ACL DELETE REPLACEACL => ACL SET GETACL => ACL GET LISTRIGHTS => ACL LIST MYRIGHTS => ACL FETCH ACL FETCH is slightly different than MYRIGHTS in that it takes an identifier as an argument and returns the rights for that identifier (?? is this desirable??). Or perhaps there could be an ACL CHECK that, given an identifier and a set of right, returns whether or not that identifier has those rights. I suspect that ACL CHECK may be more useful. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DJQ1d06584 for ietf-imapext-bks; Thu, 13 Jun 2002 12:26:01 -0700 (PDT) Received: from smtp6.andrew.cmu.edu (SMTP6.andrew.cmu.edu [128.2.10.86]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DJQ0n06580 for ; Thu, 13 Jun 2002 12:26:00 -0700 (PDT) Received: from [172.16.36.239] ([206.187.69.206]) (user=leg mech=KERBEROS_V4 (0 bits)) by smtp6.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) with ESMTP id g5DJPrTK027475; Thu, 13 Jun 2002 15:25:57 -0400 Date: Thu, 13 Jun 2002 11:21:24 -0700 From: Lawrence Greenfield To: Alexey Melnikov cc: Mark Crispin , Cyrus Daboo , IMAP Extensions WG Subject: Re: ACL2: set of rights associated with READ-WRITE response code Message-ID: <340646994.1023967284@localhost> In-Reply-To: <3D088017.B4E5B315@messagingdirect.com> References: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> <2147483647.1023542206@[10.0.1.4]> <200206081726.g58HQQNo007436@lin2.andrew.cmu.edu> <3D088017.B4E5B315@messagingdirect.com> X-Mailer: Mulberry/3.0.0a2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Thursday, June 13, 2002 5:20 AM -0600 Alexey Melnikov wrote: > Lawrence Greenfield wrote: > >> Another possibility is for ACL to recommend that servers implementing >> ACL just not return either READ-ONLY or READ-WRITE in response to a >> SELECT. > > I think this breaks compliance with RFC 2060. No, the RFC merely says "SHOULD prefix the text" with "[READ-WRITE]". So it's clearly legal to not return either READ-ONLY or READ-WRITE. So my proposal is that EXAMINE must return "[READ-ONLY]". SELECT must not return "[READ-WRITE]"; may return "[READ-ONLY]" if all rights are off. Larry Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DJ5su05334 for ietf-imapext-bks; Thu, 13 Jun 2002 12:05:54 -0700 (PDT) Received: from fp.mirapoint.com (fp.mirapoint.com [63.107.133.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DJ5rn05330 for ; Thu, 13 Jun 2002 12:05:53 -0700 (PDT) Received: from alpo.mirapoint.com (alpo.mirapoint.com [192.168.0.19]) by fp.mirapoint.com (Mirapoint Messaging Server MOS 3.2.0.40 FastPath) with ESMTP id AAH06953; Thu, 13 Jun 2002 12:05:50 -0700 (PDT) Received: from funhouse.mirapoint.com (funhouse.mirapoint.com [192.168.0.92]) by alpo.mirapoint.com (Mirapoint Messaging Server MOS 3.2.0.40) with ESMTP id ADK00548; Thu, 13 Jun 2002 12:05:49 -0700 (PDT) Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) From: Tim Showalter To: IMAP Extensions WG In-Reply-To: <3D087A02.723560BF@messagingdirect.com> References: <3D070AD5.51168DAE@messagingdirect.com> <200206130246.g5D2kDNo019084@lin2.andrew.cmu.edu> <3D087A02.723560BF@messagingdirect.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 13 Jun 2002 13:04:27 -0600 Message-Id: <1023995067.91332.6.camel@funhouse.mirapoint.com> Mime-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 2002-06-13 at 04:54, Alexey Melnikov wrote: > > Lawrence Greenfield wrote: > > > If you feel the need to deprecate the old ACL commands, can we just > > name them something else? > > Does it really matter? Syntax is almost identical and the difference can > be codified with the couple if statements. We *will* confuse people, almost immediately. Certainly no one here, as we read the specs; but there are a lot of people that don't, and there are a lot of people that like to leave mandatory () off of lists. I like the proposed identifier format; it's cleaner than what we had before. If I were implementing an ACL server from scratch I would want to use something like that. But there's running ACL code out there that doesn't work that way. In order for a sane upgrade path for Cyrus (and its progeny) the ACL2 commands will have to be supported seperately; in order to make these work in some sane way, we'll need some seperate syntax. > > I don't see the need to be so cute about > > our upgrades when we have an infinite number of bits that will make it > > blatantly obvious what versions we're using. I agree with this. Tim Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DHbmX02898 for ietf-imapext-bks; Thu, 13 Jun 2002 10:37:48 -0700 (PDT) Received: from atg.aciworldwide.com ([139.142.180.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DHbkn02889 for ; Thu, 13 Jun 2002 10:37:46 -0700 (PDT) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g5DHbdgS023085; Thu, 13 Jun 2002 11:37:39 -0600 (MDT) Message-Id: <200206131737.g5DHbdgS023085@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: Alexey Melnikov cc: Rob Siemborski , Mark Crispin , IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" In-Reply-To: Message from Alexey Melnikov of "Wed, 12 Jun 2002 20:49:49 BST." <3D07A5DD.2D9BAF46@messagingdirect.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Thu, 13 Jun 2002 11:37:39 -0600 From: Lyndon Nerenberg Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > My experience with writing parsers in non-blocking or asynchronous IO model > (i.e. when read from the socket may return that literal was not completely > received by TCP stack) tells that it is a pain in the ass to write a parser for > any command that uses literals. Why? Because you have to save state if there is > not enough data. This argument doesn't hold. You can get a short read anywhere, not just inside a literal. And I would argue that literals are the *easiest* string form to deal with: you already know how much data to read therefore you don't need to keep any state on the data stream itself, just a counter that you decrement as you read in the bytes. --lyndon I think 3B2 code deserves its own place in hell. Poring over the ESS#5 code, someone found that there were lots of strcmp(p, "f(") == 0 checks (I may have gotten the exact string wrong but it's close). It took us a while to figure out why. Apparently, location 0 on the 3b had the 3 bytes 'f' '(' '\0', someone noticed that when programs blew up they were pointing to "f(", and the worlds most amazing kludge for detecting nil pointers was born. -- Dave Presotto Received: by above.proper.com (8.11.6/8.11.3) id g5DEfxe22293 for ietf-imapext-bks; Thu, 13 Jun 2002 07:41:59 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DEfwn22289 for ; Thu, 13 Jun 2002 07:41:58 -0700 (PDT) Received: from PLATO (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id KAA23034; Thu, 13 Jun 2002 10:39:10 -0400 (EDT) Date: Thu, 13 Jun 2002 10:43:30 -0400 From: Cyrus Daboo To: Mark Crispin , "Vladimir A. Butenko" cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights associated with READ-WRITE response code) Message-ID: <778813404.1023965010@PLATO> In-Reply-To: References: X-Mailer: Mulberry/3.0.0a2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On Mark Crispin wrote: | I could understand you making a distinction between web mail programs that | only do local mail, and web mail programs that only do IMAP. But we have | at least one example (WebPine) of a program that (at least in theory) can | do both, and I doubt that WebPine is the only (or even the first) such | program. There are a number of webmail solutions that use PHP scripting on the webserver. In most cases they will use the IMAP implementation in PHP which is c-client based, so all of those fall into the same category - they can do both native mailstore access and IMAP mailstore access if desired. -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DEADP21432 for ietf-imapext-bks; Thu, 13 Jun 2002 07:10:13 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DEACn21428 for ; Thu, 13 Jun 2002 07:10:12 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DEA6d28051; Thu, 13 Jun 2002 08:10:07 -0600 Message-ID: <3D08A7BD.CA4628C2@messagingdirect.com> Date: Thu, 13 Jun 2002 08:10:05 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: Lawrence Greenfield , IMAP Extensions WG Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rightsassociated with READ-WRITE response code) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Thu, 13 Jun 2002 04:59:25 -0600, Alexey Melnikov wrote: > > Also as Vladimir pointed out in his private email to me, ACL2 implementation > > can treat as user=, if the implementation prohibits > > the creation of users with special names or names with "=". > > What does this mean? > > Would an identifier such as xxx be canonicalized to user=xxx form? Yes, unless it is one of the "specials". > If not, how is a client to know what xxx means? If an identifier is not allowed to have "=", then each identifier without "=" in it is automatically treated equal to user=xxx form. If an identifier contains "=", it must be either "user=yyy" or "group=zzz", otherwise it is illegal. > Also, wouldn't this conflict with > future assignment of special identifiers? Of course it will. But the server is not required to implement a future revision. I am not saying that this is the perfect solution (maybe not even recommended). Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DDric20680 for ietf-imapext-bks; Thu, 13 Jun 2002 06:53:44 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DDrhn20674 for ; Thu, 13 Jun 2002 06:53:43 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25675631; Thu, 13 Jun 2002 06:50:23 -0700 From: "Vladimir A. Butenko" Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights associated with READ-WRITE response code) To: Mark Crispin Cc: Alexey Melnikov , "Vladimir A. Butenko" , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Thu, 13 Jun 2002 06:50:23 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 13 Jun 2002 06:21:32 -0700 (PDT) Mark Crispin wrote: > On Thu, 13 Jun 2002 06:08:37 -0700, Vladimir A. Butenko wrote: > > I have seen a small util that implements POP3 via an IMAP server. Should > >we > > ALWAYS think about POP3 server as "a gateway from POP3 protocol to an > >IMAP > > server"? I hope not. Please note that not only CGatePro WebMail, but many > > other products implement WebMail "natively" - i.e. as yet another service > > working with the mailstore, alongside POP3 and IMAP services. > > That distinction does not always make sense. > > WebPine software uses IMAP as a back end. But there is no reason why it > has to. It uses the c-client library, which supports IMAP, POP, NNTP, and > local mail stores. A small change to the string supplied in a mail_open() > call transforms it from a "non-native" to a "native" system. > > So I don't see how you can say that CGatePro WebMail is "real" and WebPine > is "not real" web mail. Do you always ignore the ":-)" signs? If I have to, I will explain - I was joking/teasing/kidding. Anything that starts is "real". Anything that fails to start is "real", too. I was talking (seriously) about the difference of "native" implementations and "gateway"-type implementations. If there are several "native" applications (i.e. serveral applications directly addressing something - mailstore in our case), then there is a need to document the functionality and semantics of that "something". Then, even if there were ONE application (protocol) and other applications (protocols) would be implemented as "gateways", STILL there is a need to document the semantics of that underlying "something". And as a sample I used the current state of the LDAP protocol - which is still the only available protocol for Directory store, but w/o a doc describing directory store semantics, all implementations ended up being "slightly different". > Can CGatePro WebMail be configured to use an IMAP back end? If so, how is > it any different from WebPine? Does the default configuration magically > change a program from "real" to "not real"? It's irrelevant - see above, please. A sense of humor is not a sin, and it can be used sometimes, don't you think so? > If not (CGatePro WebMail can not be configured to use an IMAP back end), > than > are you arguing that a "real" web mail program is one that is a restricted > subset of a "not real" web mail program? :-) > I could understand you making a distinction between web mail programs that > only do local mail, and web mail programs that only do IMAP. But we have > at > least one example (WebPine) of a program that (at least in theory) can do > both, and I doubt that WebPine is the only (or even the first) such > program. :-)) Mark, there was no attempt to say that something is better and something is worse. That was a JOKE!!! Please look at this sign carefully: ":-)" It means - I'm kidding, I'm joking, I'm making (trying to make) you smile, it does not mean "Mark, you stuff does not fly". It does. Sincerely, Vladimir Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DDZLX18594 for ietf-imapext-bks; Thu, 13 Jun 2002 06:35:21 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (stuart@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DDZKn18587 for ; Thu, 13 Jun 2002 06:35:20 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id GAA07146; Thu, 13 Jun 2002 06:35:16 -0700 (PDT) Date: Thu, 13 Jun 2002 06:21:32 -0700 (PDT) From: Mark Crispin Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights associated with READ-WRITE response code) To: "Vladimir A. Butenko" cc: Alexey Melnikov , "Vladimir A. Butenko" , IMAP Extensions WG In-Reply-To: Message-ID: 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: On Thu, 13 Jun 2002 06:08:37 -0700, Vladimir A. Butenko wrote: > I have seen a small util that implements POP3 via an IMAP server. Should we > ALWAYS think about POP3 server as "a gateway from POP3 protocol to an IMAP > server"? I hope not. Please note that not only CGatePro WebMail, but many > other products implement WebMail "natively" - i.e. as yet another service > working with the mailstore, alongside POP3 and IMAP services. That distinction does not always make sense. WebPine software uses IMAP as a back end. But there is no reason why it has to. It uses the c-client library, which supports IMAP, POP, NNTP, and local mail stores. A small change to the string supplied in a mail_open() call transforms it from a "non-native" to a "native" system. So I don't see how you can say that CGatePro WebMail is "real" and WebPine is "not real" web mail. Can CGatePro WebMail be configured to use an IMAP back end? If so, how is it any different from WebPine? Does the default configuration magically change a program from "real" to "not real"? If not (CGatePro WebMail can not be configured to use an IMAP back end), than are you arguing that a "real" web mail program is one that is a restricted subset of a "not real" web mail program? I could understand you making a distinction between web mail programs that only do local mail, and web mail programs that only do IMAP. But we have at least one example (WebPine) of a program that (at least in theory) can do both, and I doubt that WebPine is the only (or even the first) such program. Received: by above.proper.com (8.11.6/8.11.3) id g5DDC1V16290 for ietf-imapext-bks; Thu, 13 Jun 2002 06:12:01 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DDBvn16279 for ; Thu, 13 Jun 2002 06:11:57 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25675576; Thu, 13 Jun 2002 06:08:37 -0700 From: "Vladimir A. Butenko" Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights associated with READ-WRITE response code) To: Alexey Melnikov , "Vladimir A. Butenko" Cc: Mark Crispin , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Thu, 13 Jun 2002 06:08:37 -0700 Message-ID: In-Reply-To: <3D087B54.747A0BC4@messagingdirect.com> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 13 Jun 2002 05:00:36 -0600 Alexey Melnikov wrote: > > > Oh, and I don't "dislike WebMail". After all, UW has a WebMail product > >of > > > its own (WebPine). WebMail done right! :-) > > > > If it's done via IMAP, it's not WebMail :-) > > We are just disagreeing on terms. I though about WebMail as IMAP to HTTP > gateway. I have seen a small util that implements POP3 via an IMAP server. Should we ALWAYS think about POP3 server as "a gateway from POP3 protocol to an IMAP server"? I hope not. Please note that not only CGatePro WebMail, but many other products implement WebMail "natively" - i.e. as yet another service working with the mailstore, alongside POP3 and IMAP services. On the other hand, it is possible to abandon the concept of "mailstore" completely, and express everything in terms of IMAP - even if the protocol does NOT use IMAP. I.e. the POP3 standard whould say: RETR operation that retrieves message body (that same thing that is retrieved with the IMAP BODY[] command) and sends it to the client in the same format that is used in the IMAP APPEND command literal parameter, ending with a dot and "escaped" in the same manner as it is escaped in SMTP... True, it can be done - but does it make sense? A perfect example of such an approach is the LDAP standards. Thanks God, mail things are in much better shape, but LDAP presents a perfect example of the mess created with that "misture" of protocol description and "store/object" semantics. The semantics of Directory database/store has to be retrieved from various parts of the LDAP protocol description, and is not clearly specified ANYWHERE (in the RFC tree, I'm not talking about X.500). The result - you CANNOT find any 2 LDAP servers that use the store with the same semantics. That's why I'd always vote for separate standards that explain the object store semantics (mail, directory, whatever) - and separate standards that specify communication protocol used to access those objects/store elements. > Regards, > Alexey Melnikov Sincerely, Vladimir Received: by above.proper.com (8.11.6/8.11.3) id g5DDAn316216 for ietf-imapext-bks; Thu, 13 Jun 2002 06:10:49 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (rossi@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DDAjn16211 for ; Thu, 13 Jun 2002 06:10:45 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id GAA07121; Thu, 13 Jun 2002 06:10:32 -0700 (PDT) Date: Thu, 13 Jun 2002 06:08:58 -0700 (PDT) From: Mark Crispin Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rightsassociated with READ-WRITE response code) To: Alexey Melnikov cc: Lawrence Greenfield , Mark Crispin , IMAP Extensions WG In-Reply-To: <3D087B0D.C333CE63@messagingdirect.com> Message-ID: 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: On Thu, 13 Jun 2002 04:59:25 -0600, Alexey Melnikov wrote: > Also as Vladimir pointed out in his private email to me, ACL2 implementation > can treat as user=, if the implementation prohibits > the creation of users with special names or names with "=". What does this mean? Would an identifier such as xxx be canonicalized to user=xxx form? If not, how is a client to know what xxx means? Also, wouldn't this conflict with future assignment of special identifiers? Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DBMsm11958 for ietf-imapext-bks; Thu, 13 Jun 2002 04:22:54 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DBMqn11952 for ; Thu, 13 Jun 2002 04:22:52 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DBMmd26530; Thu, 13 Jun 2002 05:22:48 -0600 Message-ID: <3D088087.62E6B066@messagingdirect.com> Date: Thu, 13 Jun 2002 05:22:47 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cyrus Daboo CC: Lawrence Greenfield , Mark Crispin , IMAP Extensions WG Subject: Re: ACL2: set of rights associated with READ-WRITE response code References: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> <2147483647.1023542206@[10.0.1.4]> <200206081726.g58HQQNo007436@lin2.andrew.cmu.edu> <2147483647.1023543615@[10.0.1.4]> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Cyrus Daboo wrote: > Hi, > > --On Saturday, June 8, 2002 1:26 PM -0400 Lawrence Greenfield > wrote: > > | This is fine with me, though this doesn't appear to totally agree with > | the text in the IMAP draft (section 6.3.1): > | > | Read-only access through SELECT differs from the EXAMINE command > | in that certain read-only mailboxes MAY permit the change of > | permanent state on a per-user (as opposed to global) basis. > | Netnews messages marked in a server-based .newsrc file are an > | example of such per-user permanent state that can be modified > | with read-only mailboxes. This seems to imply that a server that implements only per-user system flags, must ignore "swt" for the purpose of deciding if READ-WRITE should be returned? What is the sane way of describing this? Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DBLJF11911 for ietf-imapext-bks; Thu, 13 Jun 2002 04:21:19 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DBLIn11906 for ; Thu, 13 Jun 2002 04:21:18 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DBKud26497; Thu, 13 Jun 2002 05:20:56 -0600 Message-ID: <3D088017.B4E5B315@messagingdirect.com> Date: Thu, 13 Jun 2002 05:20:55 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Greenfield CC: Mark Crispin , Cyrus Daboo , IMAP Extensions WG Subject: Re: ACL2: set of rights associated with READ-WRITE response code References: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> <2147483647.1023542206@[10.0.1.4]> <200206081726.g58HQQNo007436@lin2.andrew.cmu.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lawrence Greenfield wrote: > Another possibility is for ACL to recommend that servers implementing > ACL just not return either READ-ONLY or READ-WRITE in response to a > SELECT. I think this breaks compliance with RFC 2060. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DB1Qp11164 for ietf-imapext-bks; Thu, 13 Jun 2002 04:01:26 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DB1Pn11159 for ; Thu, 13 Jun 2002 04:01:25 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DB0rd26348; Thu, 13 Jun 2002 05:00:58 -0600 Message-ID: <3D087B54.747A0BC4@messagingdirect.com> Date: Thu, 13 Jun 2002 05:00:36 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vladimir A. Butenko" CC: Mark Crispin , IMAP Extensions WG Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights associated with READ-WRITE response code) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > > Oh, and I don't "dislike WebMail". After all, UW has a WebMail product of > > its own (WebPine). WebMail done right! :-) > > If it's done via IMAP, it's not WebMail :-) We are just disagreeing on terms. I though about WebMail as IMAP to HTTP gateway. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DB0E111139 for ietf-imapext-bks; Thu, 13 Jun 2002 04:00:14 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DB0Cn11135 for ; Thu, 13 Jun 2002 04:00:12 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DAxgd26312; Thu, 13 Jun 2002 04:59:46 -0600 Message-ID: <3D087B0D.C333CE63@messagingdirect.com> Date: Thu, 13 Jun 2002 04:59:25 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Greenfield CC: Mark Crispin , IMAP Extensions WG Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rightsassociated with READ-WRITE response code) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > I also am amazed by the argument that the new system of identifiers > "throws away a large amount of interoperable code". > > char *acl_to_acl2 (char *id) > { > char *ret; > if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id); > else { > ret = (char *) malloc (5 + strlen (id) + 1); > sprintf (ret,"user=%s",id); > } > return ret; > } > > char *acl2_to_acl (char *id) > { > char *ret; > if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id); > else if (strncmp (id,5,"user=") > strcpy (ret = (char *) malloc (strlen (id + 5) + 1),id + 5) > else ret = 0; > return ret; > } > > OK, I admit this is a bit too simple-minded, but it makes the point. Exactly. Also as Vladimir pointed out in his private email to me, ACL2 implementation can treat as user=, if the implementation prohibits the creation of users with special names or names with "=". Larry, our ACL implementations are almost identical, I don't believe there will be so match work. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DAt4I10562 for ietf-imapext-bks; Thu, 13 Jun 2002 03:55:04 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DAt2n10555 for ; Thu, 13 Jun 2002 03:55:02 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DAsxd26280; Thu, 13 Jun 2002 04:54:59 -0600 Message-ID: <3D087A02.723560BF@messagingdirect.com> Date: Thu, 13 Jun 2002 04:54:58 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Greenfield CC: IMAP Extensions WG , "Vladimir A. Butenko" , Mark Crispin Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) References: <3D070AD5.51168DAE@messagingdirect.com> <200206130246.g5D2kDNo019084@lin2.andrew.cmu.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lawrence Greenfield wrote: > If you feel the need to deprecate the old ACL commands, can we just > name them something else? Does it really matter? Syntax is almost identical and the difference can be codified with the couple if statements. > I don't see the need to be so cute about > our upgrades when we have an infinite number of bits that will make it > blatantly obvious what versions we're using. Just for the record, I don't care if ACL2 uses same command names with slightly modified syntax or we just give these new commands new names. I will be very reluctant to change command syntax further (remember, our server also implements ACL and we have exactly the same set of issues), unless it give a real benefit. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DAjke09708 for ietf-imapext-bks; Thu, 13 Jun 2002 03:45:46 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DAjin09703 for ; Thu, 13 Jun 2002 03:45:44 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DAjXd26192; Thu, 13 Jun 2002 04:45:34 -0600 Message-ID: <3D0877CC.56872347@messagingdirect.com> Date: Thu, 13 Jun 2002 04:45:32 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Greenfield CC: Simon Josefsson , IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" References: <3D0744F8.F062C28@messagingdirect.com> <3D074582.428AB17F@messagingdirect.com> <200206130236.g5D2aNNo019075@lin2.andrew.cmu.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lawrence Greenfield wrote: > From: Simon Josefsson > Date: Wed, 12 Jun 2002 20:52:11 +0200 > > Alexey Melnikov writes: > > > I've noticed yesterday that ABNF for "rights" was defined as "astring", > > not just "quoted". > > Anybody objects to changing this to quoted, because I don't see that > > "rights" will ever contain control or 8bit characters. > > Sounds fine. I've always disliked having different ways of expressing > the same thing, making things simpler is a good idea. Atom is perhaps > even better. > > No, atoms aren't sufficient. "rights" can be the empty string. Atoms > can't express the empty string. Oops, you are right. However my argument about non blocking parser stands. See my other reply. > I see no reason to constain rights to quoted strings. I think having > them as strings makes sense---they are strings---and in IMAP we have > up to three ways of expressing a string. Instead of simplifying > things, it'll complicated the lexical and syntatic levels of IMAP even > more. Not really. Instead of writing one function that accept any kind of string, you can write a new function that allows only quoted strings and make the first call the second. A particular implementation (;-)) may choose to accept both types of strings when only quoted is allowed and this is fine. > If you want to remove all ways of expressing strings in IMAP besides > literals, well, fine, but that's a different argument. Cheers, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DAdWV09523 for ietf-imapext-bks; Thu, 13 Jun 2002 03:39:32 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DAdUn09519 for ; Thu, 13 Jun 2002 03:39:30 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DAdSd26123; Thu, 13 Jun 2002 04:39:28 -0600 Message-ID: <3D08765F.64823F6A@messagingdirect.com> Date: Thu, 13 Jun 2002 04:39:27 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pete Resnick CC: ietf-imapext@imc.org Subject: Re: Meeting? References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Pete Resnick wrote: > Well, life is back to this list. Do we have enough to discuss and > have enough people going that I should set up a session in Yokohama? > (I will be there.) I suggest we don't meet this time, but we meet in November. Neither myself, nor Mark, nor Larry will be there. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DAVnD08494 for ietf-imapext-bks; Thu, 13 Jun 2002 03:31:49 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DAVln08489 for ; Thu, 13 Jun 2002 03:31:47 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DAVkd26010; Thu, 13 Jun 2002 04:31:46 -0600 Message-ID: <3D07A632.19371E80@messagingdirect.com> Date: Wed, 12 Jun 2002 20:51:14 +0100 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: SETACL/DELETEACL questions (was Re: ACL2: set of rights associated with READ-WRITE response code) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Tue, 11 Jun 2002 15:21:49 -0600, Alexey Melnikov wrote: > > > What should a server do if it receives a SETACL which can not be performed > > > without doing a DELETEACL of some other identifier/rights pair? [Think of > > > what would become a "chgrp" in UNIX] > > Server is allowed to do that. It must return new ACL in an unsolicited ACL > > response anyway. > > How is it indicated to the client that this will happen *before* doing the > SETACL? I don't know any way currently. > We're talking about client and end user surprise here. Such surprises will > generate complaints. We don't have too many choices really. Either the server says NO to an operation or it says OK, but updates client's view with unsolicited ACL response. Am I missing anything? Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DAVmv08490 for ietf-imapext-bks; Thu, 13 Jun 2002 03:31:48 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DAVkn08484 for ; Thu, 13 Jun 2002 03:31:46 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DAVgd26006; Thu, 13 Jun 2002 04:31:42 -0600 Message-ID: <3D07A5DD.2D9BAF46@messagingdirect.com> Date: Wed, 12 Jun 2002 20:49:49 +0100 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: Mark Crispin , IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Wed, 12 Jun 2002 12:23:52 -0400 (EDT), Rob Siemborski wrote: > > Is there a compelling reason for this? > > Simplicity. Why allow in the syntax something that is meaningless? Correct. Also see my comment below. > > Unless I'm missing something, > > nothing in the IMAP base spec that can be a quoted string is disallowed > > from being a literal > > You missed the internaldate argument to APPEND. string = quoted / literal ANNOTATATE extension, for example, uses "quoted" instead of "astring" for entry names. See below why it is a very good thing, IMHO. > > Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but > > why be different? I could easily see implementations that make heavy use > > of literals missing this special case. It is not about the bandwidth, but about simplicity of implementation. My experience with writing parsers in non-blocking or asynchronous IO model (i.e. when read from the socket may return that literal was not completely received by TCP stack) tells that it is a pain in the ass to write a parser for any command that uses literals. Why? Because you have to save state if there is not enough data. Dealing with "quoted" or atoms is a bit easier. So, for a server implementing only ACL2 and using async IO, this change will help. If a server also implements ACL it has to accept "astring" anyway. So CMU implementation doesn't have to change. Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5DAVfi08472 for ietf-imapext-bks; Thu, 13 Jun 2002 03:31:41 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5DAVen08466 for ; Thu, 13 Jun 2002 03:31:40 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5DAVad25987; Thu, 13 Jun 2002 04:31:37 -0600 Message-ID: <3D07A00F.5C742048@messagingdirect.com> Date: Wed, 12 Jun 2002 20:25:03 +0100 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Wed, 12 Jun 2002 06:58:42 -0600, Alexey Melnikov wrote: > > I've noticed yesterday that ABNF for "rights" was defined as "astring", > > not just "quoted". > > Anybody objects to changing this to quoted, because I don't see that > > "rights" will ever contain control or 8bit characters. > > By that argument, rights should be an atom instead of quoted. It is possible > to restrict from astring to atom, but not from quoted to atom, so if atom is > the right thing this has to be done now. That is even better. Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5D3FEu27673 for ietf-imapext-bks; Wed, 12 Jun 2002 20:15:14 -0700 (PDT) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5D3FCn27669 for ; Wed, 12 Jun 2002 20:15:12 -0700 (PDT) Received: from mailscan-out3.cac.washington.edu (mailscan-out3.cac.washington.edu [140.142.32.18]) by mxout4.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g5D3FGgt005686 for ; Wed, 12 Jun 2002 20:15:16 -0700 Received: FROM smtp.washington.edu BY mailscan-out3.cac.washington.edu ; Wed Jun 12 20:15:16 2002 -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.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g5D3FGdf006820 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 Jun 2002 20:15:16 -0700 Date: Wed, 12 Jun 2002 20:15:18 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lawrence Greenfield cc: IMAP Extensions WG , Alexey Melnikov , "Vladimir A. Butenko" Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) In-Reply-To: <200206130246.g5D2kDNo019084@lin2.andrew.cmu.edu> Message-ID: Organization: Networks & Distributed Computing 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: On Wed, 12 Jun 2002, Lawrence Greenfield wrote: > I think defining new, entirely different identifiers throws away a > large amount of interoperable code that already exists. This is a > silly response to the fear that someone, somewhere, has usernames > starting with $ that they will need to use with IMAP ACLs. It isn't just user names starting with $. It's also the "anyone" user name. It is certainly not "silly" to worry that an extension to a protocol arbitarily establishes a limitation that is not in the base specification. RFC 2086 made a mistake by assuming that identifier == username. The new system of identifiers makes more sense than RFC 2086 (or the proposed $ kludge), and is a clean functional superset. The whole point of ACL2 is to fix the numerous deficiencies in RFC 2086. That entire effort would be wasted by a misguided effort to be "compatible". I also am amazed by the argument that the new system of identifiers "throws away a large amount of interoperable code". char *acl_to_acl2 (char *id) { char *ret; if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id); else { ret = (char *) malloc (5 + strlen (id) + 1); sprintf (ret,"user=%s",id); } return ret; } char *acl2_to_acl (char *id) { char *ret; if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id); else if (strncmp (id,5,"user=") strcpy (ret = (char *) malloc (strlen (id + 5) + 1),id + 5) else ret = 0; return ret; } OK, I admit this is a bit too simple-minded, but it makes the point. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5D2l4w26754 for ietf-imapext-bks; Wed, 12 Jun 2002 19:47:04 -0700 (PDT) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5D2l3n26747 for ; Wed, 12 Jun 2002 19:47:03 -0700 (PDT) Received: from mailscan-out2.cac.washington.edu (mailscan-out2.cac.washington.edu [140.142.33.17]) by mxout1.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g5D2l3SJ027105 for ; Wed, 12 Jun 2002 19:47:07 -0700 Received: FROM smtp.washington.edu BY mailscan-out2.cac.washington.edu ; Wed Jun 12 19:47:02 2002 -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.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g5D2l1df006496 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 Jun 2002 19:47:02 -0700 Date: Wed, 12 Jun 2002 19:47:04 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lawrence Greenfield cc: Alexey Melnikov , Simon Josefsson , IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" In-Reply-To: <200206130236.g5D2aNNo019075@lin2.andrew.cmu.edu> Message-ID: Organization: Networks & Distributed Computing 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: On Wed, 12 Jun 2002, Lawrence Greenfield wrote: > No, atoms aren't sufficient. "rights" can be the empty string. Atoms > can't express the empty string. OK, in that case, then it should remain astring. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5D2kDQ26734 for ietf-imapext-bks; Wed, 12 Jun 2002 19:46:13 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5D2kBn26730 for ; Wed, 12 Jun 2002 19:46:11 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g5D2kDNo019084; Wed, 12 Jun 2002 22:46:14 -0400 Date: Wed, 12 Jun 2002 22:46:13 -0400 Message-Id: <200206130246.g5D2kDNo019084@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: IMAP Extensions WG , Alexey Melnikov Cc: "Vladimir A. Butenko" , Mark Crispin In-reply-to: <3D070AD5.51168DAE@messagingdirect.com> Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) References: <3D070AD5.51168DAE@messagingdirect.com> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If you feel the need to deprecate the old ACL commands, can we just name them something else? I don't see the need to be so cute about our upgrades when we have an infinite number of bits that will make it blatantly obvious what versions we're using. I think defining new, entirely different identifiers throws away a large amount of interoperable code that already exists. This is a silly response to the fear that someone, somewhere, has usernames starting with $ that they will need to use with IMAP ACLs. Larry Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5D2aRM26512 for ietf-imapext-bks; Wed, 12 Jun 2002 19:36:27 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5D2aOn26508 for ; Wed, 12 Jun 2002 19:36:24 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g5D2aNNo019075; Wed, 12 Jun 2002 22:36:23 -0400 Date: Wed, 12 Jun 2002 22:36:23 -0400 Message-Id: <200206130236.g5D2aNNo019075@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Alexey Melnikov , Simon Josefsson Cc: IMAP Extensions WG In-reply-to: Subject: Re: ACL2: Proposal to change ABNF for "rights" References: <3D0744F8.F062C28@messagingdirect.com> <3D074582.428AB17F@messagingdirect.com> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: From: Simon Josefsson Date: Wed, 12 Jun 2002 20:52:11 +0200 Alexey Melnikov writes: > I've noticed yesterday that ABNF for "rights" was defined as "astring", > not just "quoted". > Anybody objects to changing this to quoted, because I don't see that > "rights" will ever contain control or 8bit characters. Sounds fine. I've always disliked having different ways of expressing the same thing, making things simpler is a good idea. Atom is perhaps even better. No, atoms aren't sufficient. "rights" can be the empty string. Atoms can't express the empty string. I see no reason to constain rights to quoted strings. I think having them as strings makes sense---they are strings---and in IMAP we have up to three ways of expressing a string. Instead of simplifying things, it'll complicated the lexical and syntatic levels of IMAP even more. If you want to remove all ways of expressing strings in IMAP besides literals, well, fine, but that's a different argument. Larry Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CLrOT20622 for ietf-imapext-bks; Wed, 12 Jun 2002 14:53:24 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLrNn20618 for ; Wed, 12 Jun 2002 14:53:23 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674686; Wed, 12 Jun 2002 14:50:05 -0700 From: "Vladimir A. Butenko" Subject: Re: New topic: Extensions to impove IMAP scalability To: Cyrus Daboo , Lyndon Nerenberg Cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 14:50:05 -0700 Message-ID: In-Reply-To: <2147483647.1023903818@socrates.cyrusoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 17:43:38 -0400 Cyrus Daboo wrote: > Hi, [skipped] > | Yes, right. But the fact that many clients need to open many connections > | to the server forces you to set that limit pretty high. Our docs suggest > | 5-10. That's why reducing the number of IMAP connections each client > | requires can also improve system protection. > > Right - but your solution requires a change to the protocol with support > from both servers AND clients. If clients choose not to use the new > mechanism then it won't be of any benefit. So why not try and get clients > to change their existing usage pattern first - what justifications have > you had from client writers as to why so many connections are needed? If > we can understand what demands exist on the client that justify this, we > can make sure that any protocol changes really will make a difference. Sure. Imagine a client that ALWAYS works via its own cache. It's a requirement and just take it so. I do understand that it is possible to create clients that do not use local cache (and your client is a very good sample), but there are OTHER clients and other approaches. Either we have to say now - "clients that use local caches are BAD and must be killed", or we have to think about supporting them more effectively. If you think about a client that provides you access to your entire mailstore - with a cache or without, you can come to the same requirement. "3-pane clients" are not the only clients that exist. And clients that can open a separate window for each mailbox are not the only clients that need to know about several mailboxes at the same time. You either say that those clients do not and should not exist, or you may want to agree that they a right to exist and in this case the proposed extension (actually designed to support such a client) makes some sense. > -- > Cyrus Daboo Sincerely, Vladimir Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CLkvt20427 for ietf-imapext-bks; Wed, 12 Jun 2002 14:46:57 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLktn20423 for ; Wed, 12 Jun 2002 14:46:55 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674673; Wed, 12 Jun 2002 14:43:37 -0700 From: "Vladimir A. Butenko" Subject: Re: New topic: Extensions to impove IMAP scalability To: Lyndon Nerenberg , "Vladimir A. Butenko " Cc: Cyrus Daboo , Mark Crispin , Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 14:43:37 -0700 Message-ID: In-Reply-To: <200206122140.g5CLe4gS013754@atg.aciworldwide.com> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 15:40:04 -0600 Lyndon Nerenberg wrote: > > Also, if a client does not complain when a server drops its "IDLE" > > connection, but instead reconnects, selects the same mailbox and > >re-enters > > the IDLE state - what will be the difference (besides even bigger load on > > the server)? > > "idle" and "IDLE" are not the same thing. I was specifically talking > about "idle" sessions. An IMAP session doing "IDLE" is not "idle." From the very beginning I was talking about not the BROKEN clients (that just forget to open some connections - as it happened a lot in Netscape Messenger), but about clients that NEED to keep those connections open, because they need to "stay in synch" with several mailboxes. It implies that there is an IDLE command pending there or that those clients send NOOP or something to get the updates. And the proposed extension targets exactly this situation - it allows to get rid of "synching" connections and get that same information in one, "main" connection that can be used to perform "active actions". > --lyndon Sincerely, Vladimir Received: by above.proper.com (8.11.6/8.11.3) id g5CLhq520365 for ietf-imapext-bks; Wed, 12 Jun 2002 14:43:52 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLhpn20361 for ; Wed, 12 Jun 2002 14:43:51 -0700 (PDT) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA18182; Wed, 12 Jun 2002 17:40:55 -0400 (EDT) Date: Wed, 12 Jun 2002 17:43:38 -0400 From: Cyrus Daboo To: "Vladimir A. Butenko" , Lyndon Nerenberg cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG Subject: Re: New topic: Extensions to impove IMAP scalability Message-ID: <2147483647.1023903818@socrates.cyrusoft.com> In-Reply-To: References: X-Mailer: Mulberry/3.0.0a2 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On "Vladimir A. Butenko" wrote: |> I've come across a number of servers that d have that option. Its |> probably a good idea to have something like that just from a security |> standpoint - if I know I can attack your server by opening lots of |> connections on it from my machine, that becomes an interesting denial |> of service possibility. | | Yes, right. But the fact that many clients need to open many connections | to the server forces you to set that limit pretty high. Our docs suggest | 5-10. That's why reducing the number of IMAP connections each client | requires can also improve system protection. Right - but your solution requires a change to the protocol with support from both servers AND clients. If clients choose not to use the new mechanism then it won't be of any benefit. So why not try and get clients to change their existing usage pattern first - what justifications have you had from client writers as to why so many connections are needed? If we can understand what demands exist on the client that justify this, we can make sure that any protocol changes really will make a difference. -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CLh0720349 for ietf-imapext-bks; Wed, 12 Jun 2002 14:43:00 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLgwn20345 for ; Wed, 12 Jun 2002 14:42:58 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674662; Wed, 12 Jun 2002 14:39:40 -0700 From: "Vladimir A. Butenko" Subject: Re: New topic: Extensions to impove IMAP scalability To: Cyrus Daboo , Lyndon Nerenberg Cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 14:39:40 -0700 Message-ID: In-Reply-To: <2147483647.1023903369@socrates.cyrusoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 17:36:09 -0400 Cyrus Daboo wrote: > Hi, > > --On "Vladimir A. Butenko" wrote: > > | This would be called a "broken server". The client has all rights to > | assume that the server would not break a connection unless a server has > a > | non-client related problem. A server that closes connections because it > | is just "too busy" falls in the category of the servers that simply > | "cannot be used under this type of load". > > Then you need to be clearer about specifying the load capability of the > server when using IMAP - in your case specify the load in terms of the > number of allowed IMAP connections rather than the total number of users. That's what we always do in our responses to various large-scale RFPs. Those who compose the RFPs tend to put "we need a server to handle X users" and it takes a lot of time to explain that the pure number of users does not mean much, that we must look at the avg user profile, etc. We have a customer that has 4.5mln users on a single server - so what? On the other end, we often have to deploy a 4-10 server cluster to handle some sites with just 100,000 users. BTW, in both cases the IMAP is the main protocol. The # of concurrent IMAP connections is just one thing, of course, there are many others - but it is an important thing, and whatever can be done to decrease the # of connections each user needs is a Good Thing. > -- > Cyrus Daboo Sincerely, Vladimir Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CLe6w20277 for ietf-imapext-bks; Wed, 12 Jun 2002 14:40:06 -0700 (PDT) Received: from atg.aciworldwide.com ([139.142.180.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLe4n20273 for ; Wed, 12 Jun 2002 14:40:04 -0700 (PDT) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g5CLe4gS013754; Wed, 12 Jun 2002 15:40:04 -0600 (MDT) Message-Id: <200206122140.g5CLe4gS013754@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: "Vladimir A. Butenko" cc: Cyrus Daboo , Mark Crispin , Alexey Melnikov , IMAP Extensions WG Subject: Re: New topic: Extensions to impove IMAP scalability In-Reply-To: Message from "Vladimir A. Butenko" of "Wed, 12 Jun 2002 14:28:27 PDT." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 12 Jun 2002 15:40:04 -0600 From: Lyndon Nerenberg Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Also, if a client does not complain when a server drops its "IDLE" > connection, but instead reconnects, selects the same mailbox and re-enters > the IDLE state - what will be the difference (besides even bigger load on > the server)? "idle" and "IDLE" are not the same thing. I was specifically talking about "idle" sessions. An IMAP session doing "IDLE" is not "idle." --lyndon Pieces of eight, pieces of eight, pieces of nine. Parroty error. Received: by above.proper.com (8.11.6/8.11.3) id g5CLaFF20181 for ietf-imapext-bks; Wed, 12 Jun 2002 14:36:15 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLaEn20177 for ; Wed, 12 Jun 2002 14:36:14 -0700 (PDT) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA18108; Wed, 12 Jun 2002 17:33:26 -0400 (EDT) Date: Wed, 12 Jun 2002 17:36:09 -0400 From: Cyrus Daboo To: "Vladimir A. Butenko" , Lyndon Nerenberg cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG Subject: Re: New topic: Extensions to impove IMAP scalability Message-ID: <2147483647.1023903369@socrates.cyrusoft.com> In-Reply-To: References: X-Mailer: Mulberry/3.0.0a2 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On "Vladimir A. Butenko" wrote: | This would be called a "broken server". The client has all rights to | assume that the server would not break a connection unless a server has a | non-client related problem. A server that closes connections because it | is just "too busy" falls in the category of the servers that simply | "cannot be used under this type of load". Then you need to be clearer about specifying the load capability of the server when using IMAP - in your case specify the load in terms of the number of allowed IMAP connections rather than the total number of users. -- Cyrus Daboo Received: by above.proper.com (8.11.6/8.11.3) id g5CLZwS20164 for ietf-imapext-bks; Wed, 12 Jun 2002 14:35:58 -0700 (PDT) Received: from atg.aciworldwide.com ([139.142.180.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLZvn20160 for ; Wed, 12 Jun 2002 14:35:57 -0700 (PDT) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g5CLZugS013519; Wed, 12 Jun 2002 15:35:56 -0600 (MDT) Message-Id: <200206122135.g5CLZugS013519@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: Cyrus Daboo cc: "Vladimir A. Butenko" , Mark Crispin , Alexey Melnikov , IMAP Extensions WG Subject: Re: New topic: Extensions to impove IMAP scalability In-Reply-To: Message from Cyrus Daboo of "Wed, 12 Jun 2002 17:28:24 EDT." <2147483647.1023902904@socrates.cyrusoft.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 12 Jun 2002 15:35:56 -0600 From: Lyndon Nerenberg Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > How do you then deal with clients that have an 'automatically re-connect > when server connection dies' mode? By swearing a lot. > In that mode the client will simply > re-connect as soon as you kill their connection. Most clients these days will hopefully defer that open until they have actual work to do. In general, clients that cache intelligently also tend to use connections intelligently. I'm all for "natural selection" here. > Another solution is to have a server admin configurable option to limit the > maximum number of connections from any one client machine. Provided you > ensure that the admin can't set this below, say 3, that might help. I've > come across a number of servers that d have that option. Its probably a > good idea to have something like that just from a security standpoint - if > I know I can attack your server by opening lots of connections on it from > my machine, that becomes an interesting denial of service possibility. If the client is "smart" (see above) this will have little overall impact (compared to LRUing idle connections). If the client is stupid, this will just increase the thrash level as the client closes existing connections to (needlessly) open a new connection to grab something that could have been obtained over one of the existing connections. It will then close the new connection to make room to re-open the old connection. This constant thrashing of TCP sessions tends to put a much higher load on server OSes than just maintaining existing idle connections. --lyndon Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CLZpC20152 for ietf-imapext-bks; Wed, 12 Jun 2002 14:35:51 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLZon20147 for ; Wed, 12 Jun 2002 14:35:50 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674652; Wed, 12 Jun 2002 14:32:32 -0700 From: "Vladimir A. Butenko" Subject: Re: New topic: Extensions to impove IMAP scalability To: Cyrus Daboo , Lyndon Nerenberg , "Vladimir A. Butenko" Cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 14:32:32 -0700 Message-ID: In-Reply-To: <2147483647.1023902904@socrates.cyrusoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 17:28:24 -0400 Cyrus Daboo wrote: > Hi, > > --On Lyndon Nerenberg wrote: > > | If your server can't scale to 100K+ connections then you should have > | it close down old connections on an LRU basis to cap the total > | connection count at something the server *can* handle. You don't > | need protocol modifications to solve this problem. (Especially > | since, as you stated earlier, "most of the connections are idle.") > > How do you then deal with clients that have an 'automatically re-connect > when server connection dies' mode? In that mode the client will simply > re-connect as soon as you kill their connection. Exactly. > Another solution is to have a server admin configurable option to limit > the maximum number of connections from any one client machine. Provided > you ensure that the admin can't set this below, say 3, that might help. We do have this option. So, if the client mailer NEEDS 4 connections and the server rejects it - what do we get? Yes, right - a call to the support center. Then imagine a customer like Charter that has more than 1mln users and you get the idea that "or, it's your client fault" would not be an acceptable answer for those sites. > I've come across a number of servers that d have that option. Its probably > a good idea to have something like that just from a security standpoint - > if I know I can attack your server by opening lots of connections on it > from my machine, that becomes an interesting denial of service > possibility. Yes, right. But the fact that many clients need to open many connections to the server forces you to set that limit pretty high. Our docs suggest 5-10. That's why reducing the number of IMAP connections each client requires can also improve system protection. > -- > Cyrus Daboo Sincerely, Vladimir Received: by above.proper.com (8.11.6/8.11.3) id g5CLVlg20030 for ietf-imapext-bks; Wed, 12 Jun 2002 14:31:47 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLVjn20023 for ; Wed, 12 Jun 2002 14:31:45 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674644; Wed, 12 Jun 2002 14:28:27 -0700 From: "Vladimir A. Butenko" Subject: Re: New topic: Extensions to impove IMAP scalability To: Lyndon Nerenberg , "Vladimir A. Butenko " Cc: Cyrus Daboo , Mark Crispin , Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 14:28:27 -0700 Message-ID: In-Reply-To: <200206122119.g5CLJZgS012764@atg.aciworldwide.com> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 15:19:35 -0600 Lyndon Nerenberg wrote: > If your server can't scale to 100K+ connections then you should have > it close down old connections on an LRU basis to cap the total > connection count at something the server *can* handle. You don't > need protocol modifications to solve this problem. (Especially > since, as you stated earlier, "most of the connections are idle.") This would be called a "broken server". The client has all rights to assume that the server would not break a connection unless a server has a non-client related problem. A server that closes connections because it is just "too busy" falls in the category of the servers that simply "cannot be used under this type of load". Also, if a client does not complain when a server drops its "IDLE" connection, but instead reconnects, selects the same mailbox and re-enters the IDLE state - what will be the difference (besides even bigger load on the server)? > --lyndon Sincerely, Vladimir Received: by above.proper.com (8.11.6/8.11.3) id g5CLSXw19937 for ietf-imapext-bks; Wed, 12 Jun 2002 14:28:33 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLSVn19932 for ; Wed, 12 Jun 2002 14:28:32 -0700 (PDT) Received: from socrates.cyrusoft.com (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA18022; Wed, 12 Jun 2002 17:25:43 -0400 (EDT) Date: Wed, 12 Jun 2002 17:28:24 -0400 From: Cyrus Daboo To: Lyndon Nerenberg , "Vladimir A. Butenko" cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG Subject: Re: New topic: Extensions to impove IMAP scalability Message-ID: <2147483647.1023902904@socrates.cyrusoft.com> In-Reply-To: <200206122119.g5CLJZgS012764@atg.aciworldwide.com> References: <200206122119.g5CLJZgS012764@atg.aciworldwide.com> X-Mailer: Mulberry/3.0.0a2 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On Lyndon Nerenberg wrote: | If your server can't scale to 100K+ connections then you should have | it close down old connections on an LRU basis to cap the total | connection count at something the server *can* handle. You don't | need protocol modifications to solve this problem. (Especially | since, as you stated earlier, "most of the connections are idle.") How do you then deal with clients that have an 'automatically re-connect when server connection dies' mode? In that mode the client will simply re-connect as soon as you kill their connection. Another solution is to have a server admin configurable option to limit the maximum number of connections from any one client machine. Provided you ensure that the admin can't set this below, say 3, that might help. I've come across a number of servers that d have that option. Its probably a good idea to have something like that just from a security standpoint - if I know I can attack your server by opening lots of connections on it from my machine, that becomes an interesting denial of service possibility. -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CLJkS19746 for ietf-imapext-bks; Wed, 12 Jun 2002 14:19:46 -0700 (PDT) Received: from atg.aciworldwide.com ([139.142.180.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CLJin19742 for ; Wed, 12 Jun 2002 14:19:44 -0700 (PDT) Received: from atg.aciworldwide.com (atg.aciworldwide.com [139.142.180.33]) by atg.aciworldwide.com (8.12.0/8.12.0) with ESMTP id g5CLJZgS012764; Wed, 12 Jun 2002 15:19:35 -0600 (MDT) Message-Id: <200206122119.g5CLJZgS012764@atg.aciworldwide.com> Organization: ACI Worldwide - Advanced Technology Group X-URL: http://www.aciworldwide.com/ X-Notes-Item: Just say NO to Notes! To: "Vladimir A. Butenko" cc: Cyrus Daboo , Mark Crispin , Alexey Melnikov , IMAP Extensions WG Subject: Re: New topic: Extensions to impove IMAP scalability In-Reply-To: Message from "Vladimir A. Butenko" of "Wed, 12 Jun 2002 13:39:16 PDT." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 12 Jun 2002 15:19:35 -0600 From: Lyndon Nerenberg Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If your server can't scale to 100K+ connections then you should have it close down old connections on an LRU basis to cap the total connection count at something the server *can* handle. You don't need protocol modifications to solve this problem. (Especially since, as you stated earlier, "most of the connections are idle.") --lyndon Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CKgaF18822 for ietf-imapext-bks; Wed, 12 Jun 2002 13:42:36 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CKgYn18818 for ; Wed, 12 Jun 2002 13:42:34 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674554; Wed, 12 Jun 2002 13:39:16 -0700 From: "Vladimir A. Butenko" Subject: Re: New topic: Extensions to impove IMAP scalability To: Cyrus Daboo , Mark Crispin Cc: Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 13:39:16 -0700 Message-ID: In-Reply-To: <712211245.1023898408@PLATO> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 16:13:28 -0400 Cyrus Daboo wrote: > Hi, > > --On "Vladimir A. Butenko" wrote: > > | The main problem with MANY IMAP clients is the number of IMAP > connections > | they keep open. While it may be not the case with the non-GUI clients, > | GUI clients tend to keep an open connection for each mailbox the user > | opened. Thus, a 10,000 active users often open 100,000 connections to a > | server, and this is not good, because: a) each connection require a > | socket on the server, and many systems "do not work very well" when they > | need to handle 100,000 open sockets. But we often meet a req to support > | 30,000 concurrent users - and 300,000 connections is definitely "too > | many". > > I think you are overstating this - are you really saying that an IMAP > client typically has 10 connections open to a single server when the user > is logged in? It all depends on your interpretation of the word "typically" :-). We did see that sometimes clients (I do not want to point fingers right now) that ended up with many open connections after you copy/move messages, and there are also clients where "keeping the cache current for all mailboxes" is a must and the authors use it as the explanation why so many connections need to be opened. While right now we definitely do not see that 1:10 ration I mentioned, the fact that we saw those things and the fact that we do not believe that those clients become less popular, and the fact that more and more people put most of their docs on mail servers, ending up with dozens of mailboxes in each account - makes us try to find a solution BEFORE it becomes a unsolvable problem. > Lets face it, most clients with the typical three-pane view > limit the number of mailboxes the user has open. Even with our client that > allows multiple windows for mailboxes, I very much doubt anyone gets close > to 10. Remember, that connections are costly on the client-side too. OK. Just try Netscape Messenger. It's not a client we worry about, but you will get the idea :-( > | b) in many server implementations each connection reequires a > | thread (at least, if not a process), and each thread needs a stack, and > | if 100K stacks are used, 10,000 connections would require 1GB of VRAM > for > | stacks (not tha bad), but 100,000 connections would require 10GB of VRAM > | - and this makes the server life "difficult" - when deployed on a 32-bit > | system. > > This is a server design issue. For this kind of scalability simply use a > fixed thread pool, and service connections with that. You don't have to > have one thread per connection. Given that an IMAP connection is idle for > significant periods of time, this is a reasonable thing to do. That's true. But thread stacks can be solved this way, while excessive number of connections will still be there. Try this test: make a simple test program that measures the performance of basic OS operations, then make that program open 100,000 sockets and measure the same things again. You can get very interesting results under Solaris 7, for example (they did address this in Solaris 8). > | of the implementations should only benefit: the client should use may > | "SELECT" commands to switch between mailboxes (instead of using many > | connections), but since the "WATCH" command would keep the mailbox in > the > | "parsed" stage, the price for those additional "SELECTs" should be > | virtually zero. > > This approach will effectively deprecate the use of sequence numbers and > require clients to maintain full UID caches for all messages in all the > mailboxes it is watching. The watched responses will have to return > message info using UIDs. This approach can be used EXACTLY for those clients that ALREADY do this. While I understand that this is not what IMAP authors and "good IMAP" client authors (like yourself) had in their minds, many popular clients DO MAINTAIN those caches, and this is a fact of live. If a client does not maintain the caches and does not care about synching them - it won't use those extensions, that's it. But if it does, it will work much more effectively with those extensions. > I think a better approach (if you really want to force one connection to > handle multiple mailboxes) is to introduce a MULTISELECT command that lets > you have more than one mailbox selected - in that mode all of the > responses from the server would include the mailbox name as part of the > response, so it would be possible to correlate responses with each > selected mailbox. This would allow sequence number access for all > mailboxes as well as using UIDs. I've mentioned this in my previous letter. I think that this is a much more radical change of the protocol. We can implement it easily, but it will unlikely have any real usage: a client that relies on such functionality would need a completely different code to support "old" IMAP servers. While the proposed extension adds only few things to the protocol, and it won't take a lot of additional code to support servers that do not have this extension (that code would just open a separate connection, do SELECT, then IDLE and get all updates) Again, my letter was just to see if anyone is interested. We now have that extension in any case, I just wanted to know if it makes sense to document it so other vendors can implement it, too - and if the client vendors find it useful. If not - then it's less work for us :-) > Cyrus Daboo Sincerely, Vladimir Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CKGsh18292 for ietf-imapext-bks; Wed, 12 Jun 2002 13:16:54 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CKGqn18288 for ; Wed, 12 Jun 2002 13:16:52 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674530; Wed, 12 Jun 2002 13:13:33 -0700 From: "Vladimir A. Butenko" Subject: Re: New topic: Extensions to impove IMAP scalability To: Mark Crispin Cc: Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 13:13:33 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 11:23:28 -0700 (PDT) Mark Crispin wrote: > Without deprecating Vladimir's efforts, he is not the only one who is > working > on "push" type technology for mailbox updates. > > I'd rather not say too much about my efforts at this point since I only > have a toy implementation. The basic idea is that it is a notification > mechanism in which a client (not necessarily an IMAP client) asks a > notification server to be delivered events on a certain object identifier, > and event generators for the particular object identifier spam the > notification server with events. > Of course, it's actually a lot more complicated than this. > > It is not impossible to implement an IMAP extension that uses an interface > very much like Vladimir's (or even identical), if in the long run it is > determined to be desirable to have access to the mechanism via IMAP. I think we look at this issue from different points of view. The proposed extension, indeed, can be viewed as a particular case of a more generic "Notification service", but I was talking about the IMAP protocol itself and the changes/extensions that we may have to implement in that protocol to meet the modern requirements. The IMAP protocol fits well when a "single-view" client is used. There the concept of "going from one mailbox to a different one" is well addressed by the use of the SELECT command. Modern, "multiple-view" clients use a different concept. They often use "one window-one session-one SELECT" approach and have to maintain many connections to work with many "views". While the current IMAP protocol can be (and is) successfully used by those clients, it causes scalability problems that I've mentioned. And because most clients are used by mortals that still have just two hands (at max) and one single-threaded brain (at max), most of those connections are sitting idle, with all action taking place at only one connection at any given moment. This leads to the idea to support those multiple-view clients with just one connection. One method would be to get rid of the "Selected" state at all, giving the client ability to work with any message in any mailbox at any time - but this would definitely result in a completely new protocol that would just use many IMAP portions. What we are using is a much more moderate change - those "WATCH" extensions. I cannot say now how well they work for multiple-view clients, but we hope that in 3-4 months the installed base of those clients will be well in hundred thousands, so we hope to have more "reallife" experience with it (it would be too bold to estimate that a new client will get such an audience so quickly, but that client is not a real one - it's a MAPI connector for MS OUTLOOK, thus this conservative estimate - less than 1% of our current users). Please note that there is no NEW "push" technology proposed here. All used technologies already exist in IMAP - with or without the IDLE extension. But in the basic IMAP the server reports updates only for one, "selected" mailbox, while with the proposed extension updates are reported for any set of mailboxes (besides the currently selected mailbox). So, the proposed thing is a much less generic one than your "notification server", and it is completely IMAP-specific, and uses the already existing technologies and the IMAP ideology. The message actions (read/copy/store) still can be used only from the "selected state", but the client can stay in sync with all mailboxes without keeping those "watching" connections. Depending on the type of mailbox store used, the extension may be very easily implemented. In CommuniGate Pro it took about 100 lines of code - total. Sincerely, Vladimir Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CKC6x17882 for ietf-imapext-bks; Wed, 12 Jun 2002 13:12:06 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CKC5n17878 for ; Wed, 12 Jun 2002 13:12:05 -0700 (PDT) Received: from PLATO (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id QAA17562; Wed, 12 Jun 2002 16:09:09 -0400 (EDT) Date: Wed, 12 Jun 2002 16:13:28 -0400 From: Cyrus Daboo To: "Vladimir A. Butenko" , Mark Crispin cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: New topic: Extensions to impove IMAP scalability Message-ID: <712211245.1023898408@PLATO> In-Reply-To: References: X-Mailer: Mulberry/3.0.0a2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On "Vladimir A. Butenko" wrote: | The main problem with MANY IMAP clients is the number of IMAP connections | they keep open. While it may be not the case with the non-GUI clients, | GUI clients tend to keep an open connection for each mailbox the user | opened. Thus, a 10,000 active users often open 100,000 connections to a | server, and this is not good, because: a) each connection require a | socket on the server, and many systems "do not work very well" when they | need to handle 100,000 open sockets. But we often meet a req to support | 30,000 concurrent users - and 300,000 connections is definitely "too | many". I think you are overstating this - are you really saying that an IMAP client typically has 10 connections open to a single server when the user is logged in? Lets face it, most clients with the typical three-pane view limit the number of mailboxes the user has open. Even with our client that allows multiple windows for mailboxes, I very much doubt anyone gets close to 10. Remember, that connections are costly on the client-side too. | b) in many server implementations each connection reequires a | thread (at least, if not a process), and each thread needs a stack, and | if 100K stacks are used, 10,000 connections would require 1GB of VRAM for | stacks (not tha bad), but 100,000 connections would require 10GB of VRAM | - and this makes the server life "difficult" - when deployed on a 32-bit | system. This is a server design issue. For this kind of scalability simply use a fixed thread pool, and service connections with that. You don't have to have one thread per connection. Given that an IMAP connection is idle for significant periods of time, this is a reasonable thing to do. | It looks like this extension allows to design a client that can open only | one IMAP connection to the server, but still "stay in synch" with several | mailboxes. This should decrease the server load for large sites, and most | of the implementations should only benefit: the client should use may | "SELECT" commands to switch between mailboxes (instead of using many | connections), but since the "WATCH" command would keep the mailbox in the | "parsed" stage, the price for those additional "SELECTs" should be | virtually zero. This approach will effectively deprecate the use of sequence numbers and require clients to maintain full UID caches for all messages in all the mailboxes it is watching. The watched responses will have to return message info using UIDs. I think a better approach (if you really want to force one connection to handle multiple mailboxes) is to introduce a MULTISELECT command that lets you have more than one mailbox selected - in that mode all of the responses from the server would include the mailbox name as part of the response, so it would be possible to correlate responses with each selected mailbox. This would allow sequence number access for all mailboxes as well as using UIDs. -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CK2fZ16900 for ietf-imapext-bks; Wed, 12 Jun 2002 13:02:41 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CK2en16894 for ; Wed, 12 Jun 2002 13:02:40 -0700 (PDT) Received: from PLATO (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id PAA17509; Wed, 12 Jun 2002 15:59:50 -0400 (EDT) Date: Wed, 12 Jun 2002 16:04:09 -0400 From: Cyrus Daboo To: Mark Crispin cc: IMAP Extensions WG Subject: re: New topic: Extensions to impove IMAP scalability Message-ID: <711652311.1023897849@PLATO> In-Reply-To: References: X-Mailer: Mulberry/3.0.0a2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On Mark Crispin wrote: | Without deprecating Vladimir's efforts, he is not the only one who is | working on "push" type technology for mailbox updates. | | I'd rather not say too much about my efforts at this point since I only | have a toy implementation. The basic idea is that it is a notification | mechanism in which a client (not necessarily an IMAP client) asks a | notification server to be delivered events on a certain object | identifier, and event generators for the particular object identifier | spam the notification server with events. Of course, it's actually a lot | more complicated than this. Oh great - yet another notification protocol proposal! All previous efforts in this area seem to have failed. I hope your solution can survive! To be honest with you, at this point I strongly believe that this type of notification should be integrated into presence protocols - I'd like my 'buddy' list to also tell me when new mail is present in a mailbox, and for the mailbox to send me an instant message with a summary of the new mail content. So why not piggy back this on impp? -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CJgJd16306 for ietf-imapext-bks; Wed, 12 Jun 2002 12:42:19 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (wml@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CJgHn16302 for ; Wed, 12 Jun 2002 12:42:17 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id MAA06195; Wed, 12 Jun 2002 12:42:05 -0700 (PDT) Date: Wed, 12 Jun 2002 12:24:14 -0700 (PDT) From: Mark Crispin Subject: re: Meeting? To: Pete Resnick cc: ietf-imapext@imc.org In-Reply-To: Message-ID: 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: On Wed, 12 Jun 2002 14:12:53 -0500, Pete Resnick wrote: > Well, life is back to this list. Do we have enough to discuss and > have enough people going that I should set up a session in Yokohama? > (I will be there.) Yokohama is just 4 1/2 weeks from now. The likelihood of getting reasonably priced airfare ($500) and lodging (6000 - 8000 yen/night) for Japan is vanishing this close to the travel date. For the next IETF, can we discuss the go/no-go question a bit earlier, such as when the first announcements are made? Our state government has a major budget crisis, and we're a state university. Non-essential travel for any of us is out of the question. Given that I have personal business in Japan, and that nothing else at the Yokohama IETF seems related to anything that I'm doing, any travel request from me to go to Yokohama will be picked over with a fine-toothed comb. So, (with considerable regret) I ask that there NOT be an IMAPEXT meeting at Yokohama. Received: by above.proper.com (8.11.6/8.11.3) id g5CJD3d14701 for ietf-imapext-bks; Wed, 12 Jun 2002 12:13:03 -0700 (PDT) Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CJD1n14697 for ; Wed, 12 Jun 2002 12:13:01 -0700 (PDT) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.1.3) for ; Wed, 12 Jun 2002 14:12:57 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 5.1.1r] Date: Wed, 12 Jun 2002 14:12:53 -0500 To: ietf-imapext@imc.org From: Pete Resnick Subject: Meeting? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Well, life is back to this list. Do we have enough to discuss and have enough people going that I should set up a session in Yokohama? (I will be there.) pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: by above.proper.com (8.11.6/8.11.3) id g5CJ7Nw14352 for ietf-imapext-bks; Wed, 12 Jun 2002 12:07:23 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (trungt@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CJ7Ln14347 for ; Wed, 12 Jun 2002 12:07:21 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id MAA06176; Wed, 12 Jun 2002 12:07:08 -0700 (PDT) Date: Wed, 12 Jun 2002 12:01:52 -0700 (PDT) From: Mark Crispin Subject: re: ACL2 backwards compatibility To: Simon Josefsson cc: ietf-imapext@imc.org In-Reply-To: Message-ID: 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: On Wed, 12 Jun 2002 20:59:38 +0200, Simon Josefsson wrote: > Can a server support both ACL and ACL2? The latest draft indicate > that ACL and ACL2 is incompatible. How do the server know whether the > client is using ACL or ACL2? Alexey's latest proposals (basically a superset of what I proposed) will accomplish a server being able to do both ACL and ACL2. There is different command syntax for ACL and ACL2 commands, and that can be used by the server to determine ACL vs. ACL2 semantics. An ACL server should be able to add ACL2 support without too much difficulty. An ACL2 server may find it difficult or impossible to add ACL. I purpose to implement ACL2 only. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CJ26K14204 for ietf-imapext-bks; Wed, 12 Jun 2002 12:02:06 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CJ24n14197 for ; Wed, 12 Jun 2002 12:02:04 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674461; Wed, 12 Jun 2002 11:58:47 -0700 From: "Vladimir A. Butenko" Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) To: Arnt Gulbrandsen Cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 11:58:47 -0700 Message-ID: In-Reply-To: <20020612202807.D6597@melkebalanse.gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 20:28:07 +0200 Arnt Gulbrandsen wrote: > I have the impression that today, a "mailstore" is something that talks > IMAP, LMTP and often a few other protocols. You can think of it as you want. I prefer to call the "mailstore" some internal mail server component that implements certain functions, in the same way as the Directory is some database - with some well-defined semantics. If you want to include the components that implement various protocols into what you call "mailstore" - it's OK, but that internal component is still there. In the same way as the Directory semantics is always there, while LDAP is just a protocol that allows you to access that store, with its semantics - and there can be other ways to access the same store. Even if you use some legacy design and your IMAP, POP, SMTP, etc. components all have their own code, so they use just the same file system (or a database) - LOGICALLY, there is still a "mailstore" - something that stores the messages and allows certain operations with them - and that semantics DOES NOT DEPEND on the protocol used to access that mailstore. CommuniGate Pro (and, I'm sure some other servers) allow you to open any mailbox via POP3 using some special "username". For example, you can specify "mailbox#username" and open that mailbox in your POP3 session. Make one more step - if you access "foreign mailbox" in IMAP using ~username/mailboxname "mailbox" name, then it would be logical (though not required, of course) to allow the POP server to access the same mailbox if you specify the "~username/mailboxname#youraccount" and "yourpassword". Definitely you need to have access rights for that ~username/mailboxname to open that mailbox. Most likely - the "r" right in the IMAP ACL terms. And to delete messages there - also some right. And the POP3 server must mark those messages as "read" (or \Seen) on RETR - if you have the "s" right. Does it have anything to do with the IMAP *protocol*? No. There is a much less exotic sample - WebMail. The *NATIVE* WebMail that works directly with the mailstore, not a "WebMail GUI" on top of IMAP or POP. It needs to deal with all those things - and it has nothing to do with IMAP. > IMHO that's a good state of affairs. I'm sure there are arguments for > adding more stuff, but doing that makes me think of RFC 1925. There is already a draft for Server-side Rules (or, probably, it has already become an RFC?). If my Rule specifies that the message that meets this and that criteria should be stored in the ~secretary/ImportantNotes mailbox - what should be my rights for that mailbox? Should that standard refer to the IMAP ACL RFC? Why - it has nothing to do with IMAP *protocol*? Message UIDs should be generated by those components that store messages in mailboxes. The UIDs must be numbers in the strict ascending order. Where is the standard that tells delivery agent developers to implement it that way? The same applies to the requirement to store the INTERNALDATE values there. Yes, it is mentioned in the IMAP standard, but why should Delivery Agent developers look into any IMAP standard? Result - the POP3 also has UIDs, but they are "completely different UIDs" - they may be non-numeric, and they may be non-ascending, so all POP3 clients implementing the "leave on server" options must remember all UIDs that they have "seen" in the mailbox (instead of remembering UIDValidity and the last UID or UIDNEXT in the IMAP terms). You do not want the IMAP standard to talk about the details of the TCP implementation, right? And it would be very strange if the FTP RFC would refer to the IMAP RFC for the details of the TCP semantics, right? The TCP is the "backbone", it's some thing that many higher-level protocols use and it is documented separately. The fact that an IMAP client built into a cell phone may implement IMAP and TCP in one piece of code does not make a difference. The fact that many existing IMAP, POP3, SMTP servers implement certain mailstore semantics inside their protocol-specific code does not make that semantics "tied up" to a certain protocol or service. It should be documented separately. > --Arnt Sincerely, Vladimir Received: by above.proper.com (8.11.6/8.11.3) id g5CIxbD14100 for ietf-imapext-bks; Wed, 12 Jun 2002 11:59:37 -0700 (PDT) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CIxZn14095 for ; Wed, 12 Jun 2002 11:59:35 -0700 (PDT) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.4/8.12.4) with ESMTP id g5CIxam1024117 for ; Wed, 12 Jun 2002 20:59:37 +0200 To: ietf-imapext@imc.org Subject: ACL2 backwards compatibility From: Simon Josefsson Date: Wed, 12 Jun 2002 20:59:38 +0200 Message-ID: Lines: 6 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) 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: Can a server support both ACL and ACL2? The latest draft indicate that ACL and ACL2 is incompatible. How do the server know whether the client is using ACL or ACL2? Perhaps this is already taken care of in the document, if so I'm sorry to have read it sloppily. Received: by above.proper.com (8.11.6/8.11.3) id g5CIqFN13830 for ietf-imapext-bks; Wed, 12 Jun 2002 11:52:15 -0700 (PDT) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CIqCn13825 for ; Wed, 12 Jun 2002 11:52:13 -0700 (PDT) Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.4/8.12.4) with ESMTP id g5CIq9m1024064; Wed, 12 Jun 2002 20:52:10 +0200 To: Alexey Melnikov Cc: IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" References: <3D0744F8.F062C28@messagingdirect.com> <3D074582.428AB17F@messagingdirect.com> From: Simon Josefsson Date: Wed, 12 Jun 2002 20:52:11 +0200 In-Reply-To: <3D074582.428AB17F@messagingdirect.com> (Alexey Melnikov's message of "Wed, 12 Jun 2002 06:58:42 -0600") Message-ID: Lines: 10 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2.90 (i686-pc-linux-gnu) 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: Alexey Melnikov writes: > I've noticed yesterday that ABNF for "rights" was defined as "astring", > not just "quoted". > Anybody objects to changing this to quoted, because I don't see that > "rights" will ever contain control or 8bit characters. Sounds fine. I've always disliked having different ways of expressing the same thing, making things simpler is a good idea. Atom is perhaps even better. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CIW0h13310 for ietf-imapext-bks; Wed, 12 Jun 2002 11:32:00 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (pat@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CIVwn13304 for ; Wed, 12 Jun 2002 11:31:58 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA06112; Wed, 12 Jun 2002 11:31:48 -0700 (PDT) Date: Wed, 12 Jun 2002 11:23:28 -0700 (PDT) From: Mark Crispin Subject: re: New topic: Extensions to impove IMAP scalability To: "Vladimir A. Butenko" cc: Alexey Melnikov , IMAP Extensions WG In-Reply-To: Message-ID: 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: Without deprecating Vladimir's efforts, he is not the only one who is working on "push" type technology for mailbox updates. I'd rather not say too much about my efforts at this point since I only have a toy implementation. The basic idea is that it is a notification mechanism in which a client (not necessarily an IMAP client) asks a notification server to be delivered events on a certain object identifier, and event generators for the particular object identifier spam the notification server with events. Of course, it's actually a lot more complicated than this. It is not impossible to implement an IMAP extension that uses an interface very much like Vladimir's (or even identical), if in the long run it is determined to be desirable to have access to the mechanism via IMAP. Received: by above.proper.com (8.11.6/8.11.3) id g5CIQ2v13171 for ietf-imapext-bks; Wed, 12 Jun 2002 11:26:02 -0700 (PDT) Received: from melkebalanse.gulbrandsen.priv.no (melkebalanse.gulbrandsen.priv.no [217.19.171.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CIQ0n13167 for ; Wed, 12 Jun 2002 11:26:01 -0700 (PDT) Received: (from arnt@localhost) by melkebalanse.gulbrandsen.priv.no (8.11.6/8.11.6) id g5CIS7706641; Wed, 12 Jun 2002 20:28:07 +0200 Date: Wed, 12 Jun 2002 20:28:07 +0200 From: Arnt Gulbrandsen To: "Vladimir A. Butenko" Cc: Mark Crispin , Alexey Melnikov , IMAP Extensions WG Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) Message-ID: <20020612202807.D6597@melkebalanse.gulbrandsen.priv.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have the impression that today, a "mailstore" is something that talks IMAP, LMTP and often a few other protocols. IMHO that's a good state of affairs. I'm sure there are arguments for adding more stuff, but doing that makes me think of RFC 1925. --Arnt Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CHS2k11028 for ietf-imapext-bks; Wed, 12 Jun 2002 10:28:02 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CHS1n11023 for ; Wed, 12 Jun 2002 10:28:01 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674255; Wed, 12 Jun 2002 10:24:38 -0700 From: "Vladimir A. Butenko" Subject: New topic: Extensions to impove IMAP scalability To: Mark Crispin Cc: Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 10:24:38 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We are about to release the new version of CommuniGate Pro that will inlcude several extensions that have not been discussed anywhere: they will be used by our own client. But at least one of those extensions may be of some general interest, since we implemented it to improve the scalability. We now deploy more and more systems (both single-server and clustered) in Universities and corporations where IMAP is the main access method (WebMail is great, Mark, do not forget that! - but IMAP is great, too :-). The main problem with MANY IMAP clients is the number of IMAP connections they keep open. While it may be not the case with the non-GUI clients, GUI clients tend to keep an open connection for each mailbox the user opened. Thus, a 10,000 active users often open 100,000 connections to a server, and this is not good, because: a) each connection require a socket on the server, and many systems "do not work very well" when they need to handle 100,000 open sockets. But we often meet a req to support 30,000 concurrent users - and 300,000 connections is definitely "too many". b) in many server implementations each connection reequires a thread (at least, if not a process), and each thread needs a stack, and if 100K stacks are used, 10,000 connections would require 1GB of VRAM for stacks (not tha bad), but 100,000 connections would require 10GB of VRAM - and this makes the server life "difficult" - when deployed on a 32-bit system. So, our goal was to make minimal additions to the IMAP protocol - additions that would make it possible to "keep in sync" with many mailboxes, while still using just one IMAP connection. There is no formal document for that, so I'm trying to provide informal description: Commands: WATCH ON This command sets a "watcher" on the specified mailbox. ACL: must be the same as for the EXAMINE command, and for synching puposes, the command should be sent when the mailbox is selected by this IMAP session. WATCH OFF This command removes the watcher from the specified mailbox. When the session ends, all watchers are removed automatically, so this command is useful mostly for mailbox removing/renaming operations on the servers that do not allow you to move/delete a mailbox if is being "opened" by anyone. Responses. Whenever an untagged response can be returned, the following responses can appear: * WATCH * WATCH Where the and responses are the same responses as used in the "normal" IMAP session. For example: * WATCH Trash 10 EXPUNGE * WATCH Trash 11 EXPUNGE * WATCH Trash 12 EXPUNGE If the current mailbox name (name specified in the "Select" command) is the same as the name in one of the WATCH commands, "WATCH" responses for that mailbox are not sent (to avoid duplicates, since they are sent as regular IMAP untagged reponses). If the names are different (but in reality they point to the same mailbox), the responses are sent. It looks like this extension allows to design a client that can open only one IMAP connection to the server, but still "stay in synch" with several mailboxes. This should decrease the server load for large sites, and most of the implementations should only benefit: the client should use may "SELECT" commands to switch between mailboxes (instead of using many connections), but since the "WATCH" command would keep the mailbox in the "parsed" stage, the price for those additional "SELECTs" should be virtually zero. If there is any interest in such an extension, we can try to create a formal draft. Sincerely, Vladimir Received: by above.proper.com (8.11.6/8.11.3) id g5CH3ZE08178 for ietf-imapext-bks; Wed, 12 Jun 2002 10:03:35 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CH3Xn08173 for ; Wed, 12 Jun 2002 10:03:33 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674216; Wed, 12 Jun 2002 10:00:14 -0700 From: "Vladimir A. Butenko" Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) To: Mark Crispin Cc: Alexey Melnikov , IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 10:00:14 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 09:53:09 -0700 (PDT) Mark Crispin wrote: > I have a great deal of sympathy for many of Vladimir's arguments, > particularly > from an architectural point of view. I have argued many of these things > myself for many years. > > >From a practical point of view, however, I don't think that any of these > should delay ACL2. Let's be realistic. Even if someone would agree to create such a "mailstore" standard, it would take at least 1-2 months to create the first draft. Then it will take at least 3-6 months to discuss it, since it definitely should agree (at least, in main points) with the current, popular implementations. So, if this standard is to appear, it will take at least 9 months (as usual). And if it appears, many standards has to be rewritten to remove the parts that would be included into the new standard. Rewriting the new ACL standard would be a very small part of that job. So - I do not see any reason to delay the ACL2 release either. > Oh, and I don't "dislike WebMail". After all, UW has a WebMail product of > its own (WebPine). WebMail done right! :-) If it's done via IMAP, it's not WebMail :-) Sincerely, Vladimir Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CGtss06953 for ietf-imapext-bks; Wed, 12 Jun 2002 09:55:54 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (gibb@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CGtqn06945 for ; Wed, 12 Jun 2002 09:55:52 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id JAA05997; Wed, 12 Jun 2002 09:55:45 -0700 (PDT) Date: Wed, 12 Jun 2002 09:53:09 -0700 (PDT) From: Mark Crispin Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) To: "Vladimir A. Butenko" cc: Alexey Melnikov , IMAP Extensions WG In-Reply-To: Message-ID: 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: I have a great deal of sympathy for many of Vladimir's arguments, particularly from an architectural point of view. I have argued many of these things myself for many years. >From a practical point of view, however, I don't think that any of these should delay ACL2. Oh, and I don't "dislike WebMail". After all, UW has a WebMail product of its own (WebPine). WebMail done right! :-) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CGntH06406 for ietf-imapext-bks; Wed, 12 Jun 2002 09:49:55 -0700 (PDT) Received: from mail.stalker.com (euro.stalker.com [209.1.58.249]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CGnsn06402 for ; Wed, 12 Jun 2002 09:49:54 -0700 (PDT) Received: from [213.33.180.10] (account ) by mail.stalker.com (CommuniGate Pro WebUser 4.0b2) with HTTP id 25674183; Wed, 12 Jun 2002 09:46:29 -0700 From: "Vladimir A. Butenko" Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) To: Mark Crispin , Alexey Melnikov Cc: IMAP Extensions WG X-Mailer: CommuniGate Pro Web Mailer v.4.0b2 Date: Wed, 12 Jun 2002 09:46:29 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 12 Jun 2002 08:42:28 -0700 (PDT) Mark Crispin wrote: > It should be obvious, but I support Alexey's proposal. > > This will make it possible to implement both ACL and ACL2 in a > straighforward > manner, while not leaving ACL2 hampered with warts from needless ACL > compatibility. I have just sent my comments on the new draft to Alexey, hopefully he will have time to remove the most foolish of my remarks and share it with the group. I strongly support this new, more mature ACL standard, but I'd like to bring up the issue that I have already mentioned in my previous letter to Alexey: Most of those things have NOTHING to do with IMAP. Both the IMAP basic standard and some of its standard extensions are talking about 2 different things: about the "mailbox store" and its semantics (that has nothing to do with the IMAP as the protocol) and the IMAP itself - the protocol that provides access to that mailbox store and its functions, but should not care about many "behind the scene" details of the mailbox store functionality. I do understand that it's a big work to do, but - IMHO - all of us will benefit from a new, additional set of standards, the "mailbox store" standards that will address many issues that originated in the first IMAP implementations, but have nothing to do with the protocol itself: * concept of a mailbox * concept of a mailbox heirarchy * concept of message UIDs and mailbox UIDVALIDITY settings * concept of message flags * concept of mailbox operations ("append", "remove marked") * concept of "foreign mailbox" access * concept of mailbox ACLs * concept of concurrent mailbox usage * etc. The IMAP standards can just ref to those standards, specifying only the syntax and IMAP-specific details, and not touching the "backend", mailstore specific details. This would allow us to rewrite the POP3 standard, too - since most modern implementations use the same mailstore for POP3 and IMAP, and there is no standard that specifies how these two interact (messages retrieved with POP3 RETR are marked with the \SEEN flag, while message retrieved with TOP are not marked, if POP3 QUIT does "EXPUNGE" or deletes only those messages that this POP3 session marked as "DELETED", how POP3 should deal with messages that have been deleted in a concurrent session, etc.). While SMTP standard won't gain much from such a "mailstore" standard, "delivery agents" may gain a lot, especially those that provide Automated Rules - those Rules can store message in different mailboxes in the the mailstore, add flags, etc. In spite of the fact that I know how Mark dislikes WebMail :-), I have to mention it, too: WebMail has become a de-facto standard - and it must use the same mailstore as IMAP/POP/maildelivery agents use. W/o the mailstore standard, there can be no "standard" for WebMail, but if we require that WebMail must use the "standard-based" mailstore, interaction between WebMail and IMAP becomes a no-brainer, and it becomes obvious what this or that WebMail operation does and how it will be seen in an IMAP session opened to the same mailstore, and vice versa. Not that I feel myself able to create such a standard, but I'd definitely support and help anyone who is brave enough to invest his/her time and talent into such a beast. Sincerely, Vladimir Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CGZgv06171 for ietf-imapext-bks; Wed, 12 Jun 2002 09:35:42 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CGZen06166 for ; Wed, 12 Jun 2002 09:35:40 -0700 (PDT) Received: from GOBO.ANDREW.CMU.EDU (GOBO.ANDREW.CMU.EDU [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g5CGZdNp018685; Wed, 12 Jun 2002 12:35:39 -0400 Date: Wed, 12 Jun 2002 12:35:39 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" In-Reply-To: Message-ID: 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: On Wed, 12 Jun 2002, Mark Crispin wrote: > > Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but > > why be different? I could easily see implementations that make heavy use > > of literals missing this special case. > > I agree that changing from astring to quoted may seem silly, but what about > from astring to atom? Restricting from astring to atom is fine by me (since the I agree that the likelyhood of control characters is low). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 235 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ UBLS++++$ P+++$ L++(+++) E W+ N- o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-- b++ DI+++ G e h r y? ------END GEEK CODE BLOCK----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CGU0K05937 for ietf-imapext-bks; Wed, 12 Jun 2002 09:30:00 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (cni@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CGTwn05933 for ; Wed, 12 Jun 2002 09:29:58 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id JAA05969; Wed, 12 Jun 2002 09:29:49 -0700 (PDT) Date: Wed, 12 Jun 2002 09:28:02 -0700 (PDT) From: Mark Crispin Subject: Re: ACL2: Proposal to change ABNF for "rights" To: Rob Siemborski cc: Alexey Melnikov , IMAP Extensions WG In-Reply-To: Message-ID: 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: On Wed, 12 Jun 2002 12:23:52 -0400 (EDT), Rob Siemborski wrote: > Is there a compelling reason for this? Simplicity. Why allow in the syntax something that is meaningless? > Unless I'm missing something, > nothing in the IMAP base spec that can be a quoted string is disallowed > from being a literal You missed the internaldate argument to APPEND. > Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but > why be different? I could easily see implementations that make heavy use > of literals missing this special case. I agree that changing from astring to quoted may seem silly, but what about from astring to atom? Received: by above.proper.com (8.11.6/8.11.3) id g5CGRTR05865 for ietf-imapext-bks; Wed, 12 Jun 2002 09:27:29 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (bwi@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CGRRn05861 for ; Wed, 12 Jun 2002 09:27:28 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id JAA05957; Wed, 12 Jun 2002 09:27:24 -0700 (PDT) Date: Wed, 12 Jun 2002 09:25:20 -0700 (PDT) From: Mark Crispin Subject: re: ACL2: Proposal to change ABNF for "rights" To: Alexey Melnikov cc: IMAP Extensions WG In-Reply-To: <3D074582.428AB17F@messagingdirect.com> Message-ID: 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: On Wed, 12 Jun 2002 06:58:42 -0600, Alexey Melnikov wrote: > I've noticed yesterday that ABNF for "rights" was defined as "astring", > not just "quoted". > Anybody objects to changing this to quoted, because I don't see that > "rights" will ever contain control or 8bit characters. By that argument, rights should be an atom instead of quoted. It is possible to restrict from astring to atom, but not from quoted to atom, so if atom is the right thing this has to be done now. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CGNsH05797 for ietf-imapext-bks; Wed, 12 Jun 2002 09:23:54 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CGNqn05791 for ; Wed, 12 Jun 2002 09:23:52 -0700 (PDT) Received: from GOBO.ANDREW.CMU.EDU (GOBO.ANDREW.CMU.EDU [128.2.120.172]) (user=rjs3 mech=KERBEROS_V4 (0 bits)) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g5CGNrNp018679; Wed, 12 Jun 2002 12:23:53 -0400 Date: Wed, 12 Jun 2002 12:23:52 -0400 (EDT) From: Rob Siemborski To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: ACL2: Proposal to change ABNF for "rights" In-Reply-To: <3D074582.428AB17F@messagingdirect.com> Message-ID: 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: On Wed, 12 Jun 2002, Alexey Melnikov wrote: > Anybody objects to changing this to quoted, because I don't see that > "rights" will ever contain control or 8bit characters. > Effectively this will prohibit the following: > > C: A001 SETACL ~/Mail/saved smith {2} > C: cp > > Comments? Is there a compelling reason for this? Unless I'm missing something, nothing in the IMAP base spec that can be a quoted string is disallowed from being a literal (e.g. nothing is just a quoted, it's always atleast a string). Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but why be different? I could easily see implementations that make heavy use of literals missing this special case. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 235 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ UBLS++++$ P+++$ L++(+++) E W+ N- o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-- b++ DI+++ G e h r y? ------END GEEK CODE BLOCK----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CG6Wr04956 for ietf-imapext-bks; Wed, 12 Jun 2002 09:06:32 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CG6Un04949 for ; Wed, 12 Jun 2002 09:06:30 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5CG6Vd17073; Wed, 12 Jun 2002 10:06:31 -0600 Message-ID: <3D074582.428AB17F@messagingdirect.com> Date: Wed, 12 Jun 2002 06:58:42 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: ACL2: Proposal to change ABNF for "rights" References: <3D0744F8.F062C28@messagingdirect.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've noticed yesterday that ABNF for "rights" was defined as "astring", not just "quoted". Anybody objects to changing this to quoted, because I don't see that "rights" will ever contain control or 8bit characters. Effectively this will prohibit the following: C: A001 SETACL ~/Mail/saved smith {2} C: cp Comments? Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CFic503369 for ietf-imapext-bks; Wed, 12 Jun 2002 08:44:38 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (stud@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CFian03365 for ; Wed, 12 Jun 2002 08:44:37 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id IAA05888; Wed, 12 Jun 2002 08:44:31 -0700 (PDT) Date: Wed, 12 Jun 2002 08:42:28 -0700 (PDT) From: Mark Crispin Subject: re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) To: Alexey Melnikov cc: IMAP Extensions WG , "Vladimir A. Butenko" In-Reply-To: <3D070AD5.51168DAE@messagingdirect.com> Message-ID: 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: It should be obvious, but I support Alexey's proposal. This will make it possible to implement both ACL and ACL2 in a straighforward manner, while not leaving ACL2 hampered with warts from needless ACL compatibility. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5CFduN03227 for ietf-imapext-bks; Wed, 12 Jun 2002 08:39:56 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (rossi@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CFdsn03223 for ; Wed, 12 Jun 2002 08:39:55 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id IAA05863; Wed, 12 Jun 2002 08:39:29 -0700 (PDT) Date: Wed, 12 Jun 2002 08:37:46 -0700 (PDT) From: Mark Crispin Subject: re: SETACL/DELETEACL questions (was Re: ACL2: set of rights associated with READ-WRITE response code) To: Alexey Melnikov cc: IMAP Extensions WG In-Reply-To: <3D0669ED.61104915@messagingdirect.com> Message-ID: 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: On Tue, 11 Jun 2002 15:21:49 -0600, Alexey Melnikov wrote: > > What should a server do if it receives a SETACL which can not be performed > > without doing a DELETEACL of some other identifier/rights pair? [Think of > > what would become a "chgrp" in UNIX] > Server is allowed to do that. It must return new ACL in an unsolicited ACL > response anyway. How is it indicated to the client that this will happen *before* doing the SETACL? We're talking about client and end user surprise here. Such surprises will generate complaints. Received: by above.proper.com (8.11.6/8.11.3) id g5C9eJ612488 for ietf-imapext-bks; Wed, 12 Jun 2002 02:40:19 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5C9eHn12484 for ; Wed, 12 Jun 2002 02:40:17 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5C9eFd13589; Wed, 12 Jun 2002 03:40:16 -0600 Message-ID: <3D07157E.B9328C44@messagingdirect.com> Date: Wed, 12 Jun 2002 03:33:50 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: SETACL and tied-rights References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > [...] If rights are tied in an > implementation, the implementation must be conservative in granting > rights in response to SETACL commands--unless all rights in a tied > set are specified, none of that set should be included in the ACL > entry for that identifier. A client may discover the set of rights > which may be granted to a given identifier in the ACL for a given > mailbox by using the LISTRIGHTS command. > > This was in RFC 2086 as well. > > Do we really want these semantics? > > The effect of this is that it is mandatory to do a LISTRIGHTS prior to any > SETACL (and multiple LISTRIGHTS prior to any REPLACEACL), since otherwise > there is no way for a client to know how to grant a particular right to an > identifier. > > Presumably, the reason for these semantics is so a client can review the > impact of granting a particular right if it's tied to another. But will > any client actually do this? Or will clients just blindly do the > LISTRIGHTS to get the necessary incantation for SETACL? > > What I see is no savings of work for a client which cares about any side > effects due to tied-rights, but a lot of extra work for clients which do > not care. I tend to agree. I would rather have a new response code LISTRIGHTS that is returned in NO response to SETACL command. Imagine that the client wants to grant "cp" rights to a user "smith". The client instead of doing: C: A001 LISTRIGHTS ~/Mail/saved smith S: * LISTRIGHTS ~/Mail/saved smith la r swi cdext S: A001 OK Listrights completed C: A002 SETACL ~/Mail/saved smith cdextp S: A002 OK Setacl complete will do the following (this assumes that the server doesn't want to grant a right unless all tied rights are specified by the client): C: A001 SETACL ~/Mail/saved smith cp S: A001 NO [LISTRIGHTS la r swi cdext] No some rights are tied, specify both C: A002 SETACL ~/Mail/saved smith cdextp S: A002 OK Setacl complete C: A002 LISTRIGHTS ~/Mail/saved smith and if the server sets all tied rights automatically if at least one of them is specified (not recommended by the document but still possible): C: A001 SETACL ~/Mail/saved smith cp S: * ACL ~/Mail/saved smith cdextp S: A001 OK Setacl complete Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g5C8mQ508011 for ietf-imapext-bks; Wed, 12 Jun 2002 01:48:26 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5C8mOn08005 for ; Wed, 12 Jun 2002 01:48:24 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5C8mMd13140; Wed, 12 Jun 2002 02:48:22 -0600 Message-ID: <3D070AD5.51168DAE@messagingdirect.com> Date: Wed, 12 Jun 2002 02:48:21 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG CC: Mark Crispin , "Vladimir A. Butenko" Subject: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > Alexey sent me a copy of his latest group. This document has some truly > amazing progress, and Alexey deserves to be congratulated. > > A suggestion, and some questions: > > The $ stuff is getting complicated. How about this instead: > > Eliminate $ entirely, and define "identifier" as one of: > anyone > authuser > owner > administrators > user= > group= > All other identifier names are reserved for future definition in an > extension or revision to the ACL2 specification. As Larry pointed out, this will break existing ACL implementations that treat these identifiers differently (probably all of them). However we can achieve this if we change syntax of ACL2 commands. Personally I am reluctant to change syntax drastically, I would very match like to keep existing parser as is. However, in Minneapolis we agreed to do another change: support multiple mailboxes in an ACL command (allow for mailboxes with wildcards or even several mailboxes). [Please, speak up now if you don't agree with this!!!] So, I need to tweak the syntax for ACL2 commands anyway in order to achieve this. So, I propose: 1). We change syntax of ACL commands (and possibly responses) a little bit: In all ACL commands mailbox is replaced with mailbox_list that is enclosed in "(" and ")". This will allow to unambiguously distinguish between ACL and ACL2. And this is a small change in an ACL parser, IMHO. acl_data = "ACL" SPACE mailbox_list *(SPACE identifier SPACE rights) deleteacl = "DELETEACL" SPACE mailbox_list SPACE identifier getacl = "GETACL" SPACE mailbox_list listrights = "LISTRIGHTS" SPACE mailbox_list SPACE identifier replaceacl = "REPLACEACL" SPACE mailbox_list *(SPACE identifier SPACE rights) setacl = "SETACL" SPACE mailbox_list SPACE identifier SPACE mod_rights mailbox_list = "(" 1*mailbox ")" ;; mailbox may contain pattern matching characters * and % ACL and LISTRIGHTS responses must be replaced with ACL2 and LISTRIGHTS2: acl_data = "ACL2" SPACE mailbox *(SPACE identifier SPACE rights) listrights_data = "LISTRIGHTS2" SPACE mailbox SPACE identifier SPACE rights *(SPACE rights) These responses have exactly the same syntax as ACL and LISTRIGTHS, but "identifier" here has ACL2 syntax as proposed by Mark. 2). Go with Mark's proposal In order to do that, I want to hear from people who've implemented ACL and willing to implement ACL that they agree to go along. Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: by above.proper.com (8.11.6/8.11.3) id g5C8FJA00338 for ietf-imapext-bks; Wed, 12 Jun 2002 01:15:19 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5C8FHn00331 for ; Wed, 12 Jun 2002 01:15:17 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g5C8F9d12907; Wed, 12 Jun 2002 02:15:11 -0600 Message-ID: <3D0669ED.61104915@messagingdirect.com> Date: Tue, 11 Jun 2002 15:21:49 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: SETACL/DELETEACL questions (was Re: ACL2: set of rights associated with READ-WRITE response code) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > What should a server do if it receives a SETACL which can not be performed > without doing a DELETEACL of some other identifier/rights pair? [Think of > what would become a "chgrp" in UNIX] Server is allowed to do that. It must return new ACL in an unsolicited ACL response anyway. > What should a server do if it receives a DELETEACL but the identifier can > not be deleted? Is it alright to treat it as a SETACL with server-defined > default rights? The server can either fail with NO (for example, in our implementation we don't allow to delete the last ACL entry on a mailbox) response or do as you describe (i.e. modify some other ACL(s) as well and return OK). > In particular, on UNIX I would probably treat a DELETEACL > of $anyone to mean "set $anyone to empty rights", of $group= to mean > "set $group= to same as $anyone", and of $owner to "all rights of > $anyone and $group= plus a". Is this alright? Regards, Alexey Melnikov __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: by above.proper.com (8.11.6/8.11.3) id g5BKbjM26138 for ietf-imapext-bks; Tue, 11 Jun 2002 13:37:45 -0700 (PDT) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BKbhn26134 for ; Tue, 11 Jun 2002 13:37:43 -0700 (PDT) Received: from mailscan-out1.cac.washington.edu (mailscan-out1.cac.washington.edu [140.142.32.17]) by mxout3.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g5BKbh9L003972 for ; Tue, 11 Jun 2002 13:37:43 -0700 Received: FROM smtp.washington.edu BY mailscan-out1.cac.washington.edu ; Tue Jun 11 13:37:40 2002 -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.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g5BKbddf013634 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 11 Jun 2002 13:37:39 -0700 Date: Tue, 11 Jun 2002 13:37:42 -0700 (Pacific Daylight Time) From: Mark Crispin To: IMAP Extensions WG Subject: SETACL and tied-rights Message-ID: Organization: Networks & Distributed Computing 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: [...] If rights are tied in an implementation, the implementation must be conservative in granting rights in response to SETACL commands--unless all rights in a tied set are specified, none of that set should be included in the ACL entry for that identifier. A client may discover the set of rights which may be granted to a given identifier in the ACL for a given mailbox by using the LISTRIGHTS command. This was in RFC 2086 as well. Do we really want these semantics? The effect of this is that it is mandatory to do a LISTRIGHTS prior to any SETACL (and multiple LISTRIGHTS prior to any REPLACEACL), since otherwise there is no way for a client to know how to grant a particular right to an identifier. Presumably, the reason for these semantics is so a client can review the impact of granting a particular right if it's tied to another. But will any client actually do this? Or will clients just blindly do the LISTRIGHTS to get the necessary incantation for SETACL? What I see is no savings of work for a client which cares about any side effects due to tied-rights, but a lot of extra work for clients which do not care. Received: by above.proper.com (8.11.6/8.11.3) id g5ABJOS26041 for ietf-imapext-bks; Mon, 10 Jun 2002 04:19:24 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ABJNn26037 for ; Mon, 10 Jun 2002 04:19:23 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28588; Mon, 10 Jun 2002 07:18:49 -0400 (EDT) Message-Id: <200206101118.HAA28588@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-acl-04.txt Date: Mon, 10 Jun 2002 07:18:49 -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 ACL extension Author(s) : A. Melnikov Filename : draft-ietf-imapext-acl-04.txt Pages : 9 Date : 06-Jun-02 The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-acl-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-acl-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: <20020607140110.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-acl-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-acl-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607140110.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g58I1P611801 for ietf-imapext-bks; Sat, 8 Jun 2002 11:01:25 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (wwoodf@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g58I1Mn11797 for ; Sat, 8 Jun 2002 11:01:22 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id LAA00848; Sat, 8 Jun 2002 11:00:42 -0700 (PDT) Date: Sat, 8 Jun 2002 10:45:43 -0700 (PDT) From: Mark Crispin Subject: Re: ACL2: set of rights associated with READ-WRITE response code To: Lawrence Greenfield cc: Alexey Melnikov , Cyrus Daboo , IMAP Extensions WG In-Reply-To: <200206081743.g58HhiNo007448@lin2.andrew.cmu.edu> Message-ID: 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: On Sat, 8 Jun 2002 13:43:44 -0400, Lawrence Greenfield wrote: > Do we know of any existing clients that use READ-ONLY/READ-WRITE for > anything? What do they use them for? What's the benefit of sending > this back to the client? Pine checks the READ-ONLY flag in quite a few places. The best way to think about READ-ONLY is that it means you can't do anything to the mailbox that someone else would see. You can, however, alter any flags listed as PERMANENTFLAGS. I think matching that to the i and e bits sounds right, although the swt bits may affect things if they are PERMANENTFLAGS. By the way, the definition of the w right should be called "write flags" instead of "write". It's too late to change it now, but the i right should really be the w right, and the current w right should be something like f. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g58HhkW11068 for ietf-imapext-bks; Sat, 8 Jun 2002 10:43:46 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g58Hhjn11062 for ; Sat, 8 Jun 2002 10:43:45 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g58HhiNo007448; Sat, 8 Jun 2002 13:43:44 -0400 Date: Sat, 8 Jun 2002 13:43:44 -0400 Message-Id: <200206081743.g58HhiNo007448@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Alexey Melnikov , Mark Crispin , Cyrus Daboo Cc: IMAP Extensions WG In-reply-to: <2147483647.1023543615@[10.0.1.4]> Subject: Re: ACL2: set of rights associated with READ-WRITE response code References: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> <2147483647.1023542206@[10.0.1.4]> <200206081726.g58HQQNo007436@lin2.andrew.cmu.edu> <2147483647.1023543615@[10.0.1.4]> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Sat, 08 Jun 2002 13:40:15 -0400 From: Cyrus Daboo [...] OK, this implies then that READ-ONLY should be returned if both the 'i' and 'e' bits are off, irrespective of the 's', 'w' and 't' bits which only control flag state. 'i' and 'e' actually control the content of the mailbox. So how about this: The server MUST include a READ-ONLY prefix in the tagged OK response to a SELECT command if both the 'i' and 'e' ACL rights are off for the current user. The server SHOULD include a READ-WRITE prefix in the tagged OK response if either the 'i' or 'e' ACL rights is on for the current user. This fits in with the base-spec requirement of SHOULD for READ-WRITE and MUST for READ-ONLY. Do we know of any existing clients that use READ-ONLY/READ-WRITE for anything? What do they use them for? What's the benefit of sending this back to the client? Larry Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g58HeXq11025 for ietf-imapext-bks; Sat, 8 Jun 2002 10:40:33 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g58HeWn11021 for ; Sat, 8 Jun 2002 10:40:32 -0700 (PDT) Received: from [10.0.1.4] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA22728; Sat, 8 Jun 2002 13:37:34 -0400 (EDT) Date: Sat, 08 Jun 2002 13:40:15 -0400 From: Cyrus Daboo To: Lawrence Greenfield , Mark Crispin , Alexey Melnikov cc: IMAP Extensions WG Subject: Re: ACL2: set of rights associated with READ-WRITE response code Message-ID: <2147483647.1023543615@[10.0.1.4]> In-Reply-To: <200206081726.g58HQQNo007436@lin2.andrew.cmu.edu> References: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> <2147483647.1023542206@[10.0.1.4]> <200206081726.g58HQQNo007436@lin2.andrew.cmu.edu> X-Mailer: Mulberry/3.0.0a2 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On Saturday, June 8, 2002 1:26 PM -0400 Lawrence Greenfield wrote: | This is fine with me, though this doesn't appear to totally agree with | the text in the IMAP draft (section 6.3.1): | | Read-only access through SELECT differs from the EXAMINE command | in that certain read-only mailboxes MAY permit the change of | permanent state on a per-user (as opposed to global) basis. | Netnews messages marked in a server-based .newsrc file are an | example of such per-user permanent state that can be modified | with read-only mailboxes. | | Another possibility is for ACL to recommend that servers implementing | ACL just not return either READ-ONLY or READ-WRITE in response to a | SELECT. OK, this implies then that READ-ONLY should be returned if both the 'i' and 'e' bits are off, irrespective of the 's', 'w' and 't' bits which only control flag state. 'i' and 'e' actually control the content of the mailbox. So how about this: The server MUST include a READ-ONLY prefix in the tagged OK response to a SELECT command if both the 'i' and 'e' ACL rights are off for the current user. The server SHOULD include a READ-WRITE prefix in the tagged OK response if either the 'i' or 'e' ACL rights is on for the current user. This fits in with the base-spec requirement of SHOULD for READ-WRITE and MUST for READ-ONLY. -- Cyrus Daboo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g58HQTf10785 for ietf-imapext-bks; Sat, 8 Jun 2002 10:26:29 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g58HQSn10781 for ; Sat, 8 Jun 2002 10:26:28 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g58HQQNo007436; Sat, 8 Jun 2002 13:26:27 -0400 Date: Sat, 8 Jun 2002 13:26:26 -0400 Message-Id: <200206081726.g58HQQNo007436@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Mark Crispin , Alexey Melnikov , Cyrus Daboo Cc: IMAP Extensions WG In-reply-to: <2147483647.1023542206@[10.0.1.4]> Subject: Re: ACL2: set of rights associated with READ-WRITE response code References: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> <2147483647.1023542206@[10.0.1.4]> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Sat, 08 Jun 2002 13:16:47 -0400 From: Cyrus Daboo [...] Therefore I argue that READ-WRITE status should appear whenever any ACL bit that controls a change in the masilbox content is on. i.e. read_write = 's' || 'w' || 'i' || 't' || 'e'; If all of those are off then the mailbox is READ-ONLY. This is fine with me, though this doesn't appear to totally agree with the text in the IMAP draft (section 6.3.1): Read-only access through SELECT differs from the EXAMINE command in that certain read-only mailboxes MAY permit the change of permanent state on a per-user (as opposed to global) basis. Netnews messages marked in a server-based .newsrc file are an example of such per-user permanent state that can be modified with read-only mailboxes. Another possibility is for ACL to recommend that servers implementing ACL just not return either READ-ONLY or READ-WRITE in response to a SELECT. Larry Received: by above.proper.com (8.11.6/8.11.3) id g58HH8M10649 for ietf-imapext-bks; Sat, 8 Jun 2002 10:17:08 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g58HH6n10645 for ; Sat, 8 Jun 2002 10:17:06 -0700 (PDT) Received: from [10.0.1.4] (localhost [127.0.0.1]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA22624; Sat, 8 Jun 2002 13:14:05 -0400 (EDT) Date: Sat, 08 Jun 2002 13:16:47 -0400 From: Cyrus Daboo To: Lawrence Greenfield , Alexey Melnikov , Mark Crispin cc: IMAP Extensions WG Subject: Re: ACL2: set of rights associated with READ-WRITE response code Message-ID: <2147483647.1023542206@[10.0.1.4]> In-Reply-To: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> References: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> X-Mailer: Mulberry/3.0.0a2 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, --On Friday, June 7, 2002 2:50 PM -0400 Lawrence Greenfield wrote: | What Alexey is referring to here is a fairly minor problem, the | [READ-ONLY] and [READ-WRITE] status responses. These responses are | basically useless since they don't convey any information to the | client. Does "READ-WRITE" mean "able to modify everything"? "able | to modify at least one thing"? ACL gives the client a much better | notion of what operations are likely to succeed. | | ACL2 should just recommend one interpretation and tie READ-WRITE to a | particular right. It's not a big deal. You need to consider READ-WRITE/READ-ONLY in the context of non-ACL aware clients. A non-ACL client will likely use that indicator to determine what commands to enable in its UI when that mailbox is open. e.g. for a READ-ONLY mailbox the client will disable flag changing commands, expunge, prevent drag and drop of messages into the mailbox pane etc. The problem arises when some ACL bits are on and others are not. For example if 'w' is off, but 'i' is on, and 'w' controls the R-W/R-O status, then the mailbox will appear as READ-ONLY. Non-ACL clients might then disable the ability to copy into or append to that mailbox, even though that is allowed by the ACL 'i' bit. This is bad as it prevents the user from being able to do a valid operation. If the status were reported as READ-WRITE, then copy/append would be enabled for the user and would work fine. In this case the 'negative' aspect is that the flag change commands would be enabled but fail with a NO response when the user attempts it. I regard this as the lesser of two evils in that valid commands can at least be executed and there is a reasonable failure mode for non-valid commands. Therefore I argue that READ-WRITE status should appear whenever any ACL bit that controls a change in the masilbox content is on. i.e. read_write = 's' || 'w' || 'i' || 't' || 'e'; If all of those are off then the mailbox is READ-ONLY. -- Cyrus Daboo Received: by above.proper.com (8.11.6/8.11.3) id g57KWF018636 for ietf-imapext-bks; Fri, 7 Jun 2002 13:32:15 -0700 (PDT) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g57KWDn18632 for ; Fri, 7 Jun 2002 13:32:13 -0700 (PDT) Received: from mailscan-out3.cac.washington.edu (mailscan-out3.cac.washington.edu [140.142.32.18]) by mxout1.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g57KWBSJ025280 for ; Fri, 7 Jun 2002 13:32:16 -0700 Received: FROM smtp.washington.edu BY mailscan-out3.cac.washington.edu ; Fri Jun 07 13:32:10 2002 -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.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g57KWAPT000515 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Jun 2002 13:32:10 -0700 Date: Fri, 7 Jun 2002 13:32:10 -0700 (Pacific Daylight Time) From: Mark Crispin To: Lawrence Greenfield cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: ACL2: set of rights associated with READ-WRITE response code In-Reply-To: <200206071855.g57ItBNo004596@lin2.andrew.cmu.edu> Message-ID: Organization: Networks & Distributed Computing 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: On Fri, 7 Jun 2002, Lawrence Greenfield wrote: > Such a change would be completely incompatible with existing ACL > implementations, which already have widespread adaption and good > interoperability. We are talking about ACL2, not ACL. I can assure you that if I implemented ACL in UW imapd (and c-client/Pine) in the way that made the most sense for us, the result would be completely non-interoperable. It would break existing implementations which expect the Cyrus type of interpretation, and create an incredible mess. It would also be completely compliant with RFC 2086. Fortunately, I am not the sort of person who deliberately does harmful things to break a specification. I have put off implementing ACL in UW imapd in the hope of having a fixed specification. The whole point of ACL2 is to create an interoperable specification that we can all live with, and give it a different name so that we won't have interoperability problems with ACL. It may be necessary to have a switch (or different commands) so a client of a server that supports both ACL and ACL2 can say "I want ACL2 semantics." That's fine. But, please!!, let's get it right this time. Or we will end up with multiple compliant non-interoperable implementations. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Received: by above.proper.com (8.11.6/8.11.3) id g57ItDY16720 for ietf-imapext-bks; Fri, 7 Jun 2002 11:55:13 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g57ItCn16715 for ; Fri, 7 Jun 2002 11:55:12 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g57ItBNo004596; Fri, 7 Jun 2002 14:55:11 -0400 Date: Fri, 7 Jun 2002 14:55:11 -0400 Message-Id: <200206071855.g57ItBNo004596@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Alexey Melnikov , Mark Crispin Cc: IMAP Extensions WG In-reply-to: Subject: Re: ACL2: set of rights associated with READ-WRITE response code References: User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Thu, 6 Jun 2002 13:24:42 -0700 (Pacific Daylight Time) From: Mark Crispin Eliminate $ entirely, and define "identifier" as one of: anyone authuser owner administrators user= group= All other identifier names are reserved for future definition in an extension or revision to the ACL2 specification. Such a change would be completely incompatible with existing ACL implementations, which already have widespread adaption and good interoperability. Larry Received: by above.proper.com (8.11.6/8.11.3) id g57IoYf16257 for ietf-imapext-bks; Fri, 7 Jun 2002 11:50:34 -0700 (PDT) Received: from lin2.andrew.cmu.edu (LIN2.andrew.cmu.edu [128.2.6.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g57IoXn16253 for ; Fri, 7 Jun 2002 11:50:33 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.121.100]) by lin2.andrew.cmu.edu (8.12.3-SASLv2.Beta4/8.12.3.Beta2) with ESMTP id g57IoWNo004588; Fri, 7 Jun 2002 14:50:32 -0400 Date: Fri, 7 Jun 2002 14:50:32 -0400 Message-Id: <200206071850.g57IoWNo004588@lin2.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.3 To: Alexey Melnikov , Mark Crispin Cc: IMAP Extensions WG In-reply-to: Subject: Re: ACL2: set of rights associated with READ-WRITE response code References: User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory?= =?ISO-8859-4?Q?=F2mae?=) Emacs/21.2 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Thu, 6 Jun 2002 05:53:18 -0700 (PDT) From: Mark Crispin On Thu, 06 Jun 2002 03:46:14 -0600, Alexey Melnikov wrote: > Cyrus, Communigate and CDC IntraStore are completely different > implementations of the ACL RFC and they all behave differently! Yes, and if UW imapd implemented RFC 2086 there would have been a fourth completely different implementation that would have been even more different than the other three. What Alexey is referring to here is a fairly minor problem, the [READ-ONLY] and [READ-WRITE] status responses. These responses are basically useless since they don't convey any information to the client. Does "READ-WRITE" mean "able to modify everything"? "able to modify at least one thing"? ACL gives the client a much better notion of what operations are likely to succeed. ACL2 should just recommend one interpretation and tie READ-WRITE to a particular right. It's not a big deal. Larry Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g57Huvg15410 for ietf-imapext-bks; Fri, 7 Jun 2002 10:56:57 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (trungt@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g57Hutn15405 for ; Fri, 7 Jun 2002 10:56:55 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id KAA29107; Fri, 7 Jun 2002 10:56:50 -0700 (PDT) Date: Fri, 7 Jun 2002 10:52:04 -0700 (PDT) From: Mark Crispin Subject: Re: ACL2: set of rights associated with READ-WRITE response code To: Steve Hole cc: Alexey Melnikov , IMAP Extensions WG In-Reply-To: Message-ID: 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: On Fri, 7 Jun 2002 11:47:16 -0700, Steve Hole wrote: > > Eliminate $ entirely, and define "identifier" as one of: > > anyone > > authuser > > owner > > administrators > > user= > > group= > > All other identifier names are reserved for future definition in an > > extension or revision to the ACL2 specification. > This is precisely what we arrived at in the "authid" acap dataset class as > well. As I wrote authid, I think it's a good idea. Cool! We're starting to get convergence! This would indeed remove many of the problems that I have with RFC 2086. I would be happy to withdraw my earlier proposal (in Alexey's draft) in favor of this one. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g57Hnn715303 for ietf-imapext-bks; Fri, 7 Jun 2002 10:49:49 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g57Hnmn15299 for ; Fri, 7 Jun 2002 10:49:48 -0700 (PDT) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g57Hnnd03425; Fri, 7 Jun 2002 11:49:49 -0600 From: Steve Hole Date: Fri, 7 Jun 2002 11:47:16 -0700 To: Mark Crispin Subject: Re: ACL2: set of rights associated with READ-WRITE response code Cc: Alexey Melnikov , IMAP Extensions WG In-Reply-To: References: <3CFF64FD.6942854E@messagingdirect.com> Message-ID: X-Mailer: Execmail for Linux Phoenix a1 Build (5) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g57Hnmn15300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 6 Jun 2002 13:24:42 -0700 (Pacific Daylight Time) Mark Crispin wrote: > Eliminate $ entirely, and define "identifier" as one of: > anyone > authuser > owner > administrators > user= > group= > All other identifier names are reserved for future definition in an > extension or revision to the ACL2 specification. This is precisely what we arrived at in the "authid" acap dataset class as well. As I wrote authid, I think it's a good idea. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g56KOd006109 for ietf-imapext-bks; Thu, 6 Jun 2002 13:24:39 -0700 (PDT) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g56KOcn06105 for ; Thu, 6 Jun 2002 13:24:38 -0700 (PDT) Received: from mailscan-out1.cac.washington.edu (mailscan-out1.cac.washington.edu [140.142.32.17]) by mxout3.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with SMTP id g56KOe9L002434 for ; Thu, 6 Jun 2002 13:24:40 -0700 Received: FROM smtp.washington.edu BY mailscan-out1.cac.washington.edu ; Thu Jun 06 13:24:39 2002 -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.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g56KOdPT014156 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Jun 2002 13:24:39 -0700 Date: Thu, 6 Jun 2002 13:24:42 -0700 (Pacific Daylight Time) From: Mark Crispin To: Alexey Melnikov cc: IMAP Extensions WG Subject: Re: ACL2: set of rights associated with READ-WRITE response code In-Reply-To: <3CFF64FD.6942854E@messagingdirect.com> Message-ID: Organization: Networks & Distributed Computing 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: Alexey sent me a copy of his latest group. This document has some truly amazing progress, and Alexey deserves to be congratulated. A suggestion, and some questions: The $ stuff is getting complicated. How about this instead: Eliminate $ entirely, and define "identifier" as one of: anyone authuser owner administrators user= group= All other identifier names are reserved for future definition in an extension or revision to the ACL2 specification. What should a server do if it receives a SETACL which can not be performed without doing a DELETEACL of some other identifier/rights pair? [Think of what would become a "chgrp" in UNIX] What should a server do if it receives a DELETEACL but the identifier can not be deleted? Is it alright to treat it as a SETACL with server-defined default rights? In particular, on UNIX I would probably treat a DELETEACL of $anyone to mean "set $anyone to empty rights", of $group= to mean "set $group= to same as $anyone", and of $owner to "all rights of $anyone and $group= plus a". Is this alright? -- Mark -- Received: by above.proper.com (8.11.6/8.11.3) id g56CvaQ03612 for ietf-imapext-bks; Thu, 6 Jun 2002 05:57:36 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (paul@ikkoku-kan.panda.com [206.124.149.114] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g56CvYn03607 for ; Thu, 6 Jun 2002 05:57:34 -0700 (PDT) Received: from Ikkoku-Kan.Panda.COM (Ikkoku-Kan.Panda.COM [192.107.14.50]) by Ikkoku-Kan.Panda.COM id FAA27393; Thu, 6 Jun 2002 05:57:19 -0700 (PDT) Date: Thu, 6 Jun 2002 05:53:18 -0700 (PDT) From: Mark Crispin Subject: re: ACL2: set of rights associated with READ-WRITE response code To: Alexey Melnikov cc: IMAP Extensions WG In-Reply-To: <3CFF2F66.67508CC9@messagingdirect.com> Message-ID: 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: On Thu, 06 Jun 2002 03:46:14 -0600, Alexey Melnikov wrote: > Cyrus, Communigate and CDC IntraStore are completely different > implementations of the ACL RFC and they all behave differently! Yes, and if UW imapd implemented RFC 2086 there would have been a fourth completely different implementation that would have been even more different than the other three. I'm worried that we've still not solved the fundamental problems in RFC 2086. Received: by above.proper.com (8.11.6/8.11.3) id g569kEG21209 for ietf-imapext-bks; Thu, 6 Jun 2002 02:46:14 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g569kDn21200 for ; Thu, 6 Jun 2002 02:46:13 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g569kAd20065; Thu, 6 Jun 2002 03:46:10 -0600 Message-ID: <3CFF2F66.67508CC9@messagingdirect.com> Date: Thu, 06 Jun 2002 03:46:14 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: ACL2: set of rights associated with READ-WRITE response code Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I did a bit of research and found out the following: Cyrus and MessagingDirect server: if either "w" or "t" are allowed for the current user, server reports READ-WRITE Communigate: when the user has "s" right. CDC IntraStore: when the user has "w" right. Cyrus, Communigate and CDC IntraStore are completely different implementations of the ACL RFC and they all behave differently! Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: by above.proper.com (8.11.6/8.11.3) id g569jrA21136 for ietf-imapext-bks; Thu, 6 Jun 2002 02:45:53 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g569jqn21129 for ; Thu, 6 Jun 2002 02:45:52 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g569jpd20050; Thu, 6 Jun 2002 03:45:51 -0600 Message-ID: <3CFF2F53.AFD74026@messagingdirect.com> Date: Thu, 06 Jun 2002 03:45:55 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: ACL2: rights required for different IMAP command Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As you will see in the new revision, I've added a new section that describes in details which rights should be checked to implement different IMAP commands, which rights are mandatory and which are optional. Here is what left unresolved: SUBSCRIBE - "l" right is required only if the server checks for mailbox existence when performing SUBSCRIBE. Allow if the user has "r" right? GETACL - "a" right on the mailbox. CDC IntraStore: "a". CMU: "r", "a", admin or owner. MD: "r" or "a" or owner. No consensus if "r" should be allowed. John would prefer not to use "r", but he is fine if somebody insists on using it. The main argument against allowing "r" for GETACL is that in this case GETACL can possibly disclose some identifiers existing on the mail system to an authenticated user with read access. On the other hand "r" is used for a mailbox metadata and seems appropriate. LISTRIGHTS - Same as GETACL? or just "r"? GETQUOTA - no rights required CMU server checks if the user belongs to administrators, I don't know why SETQUOTA - "a" right Some implementations allows to set quota when the user has "r" right as well. Should we allow that? Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g569h3S20845 for ietf-imapext-bks; Thu, 6 Jun 2002 02:43:03 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g569h2n20839 for ; Thu, 6 Jun 2002 02:43:02 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g569h1d20010; Thu, 6 Jun 2002 03:43:01 -0600 Message-ID: <3CFF2EA9.D7882939@messagingdirect.com> Date: Thu, 06 Jun 2002 03:43:05 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: ACL2: escape character for special identifiers and groups. Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a list of comments on the issue I've got during IMAPEXT lunch at Minneapolis IETF (in no particular order, I hope it is not too intricate to understand): Could use "$$" prefix for user names beginning "$" and "$-" for user names beginning from "-". Escape or reject? No group starting with "$-" or "$$" (John). Use "\" as escape character for leading "$" or "-"? Alternatively we can change syntax of all ACL commands (Chris) Chris objects to escape mechanism, he prefers to reject. We couldn't reach any consensus on the matter and I was asked to post a question to the mailing list if any existing server ACL implementation is using "$" as a leading character in usernames. The only thing was clear that the participants were reluctant to change syntax of ACL commands, as they would rather reuse existing IMAP ACL parsers. As Jutta pointed out in her recent post we can use "/" instead of "$". This might work, as probably none of the existing ACL implementations will accept usernames with "/" character. Alexey Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g569bmD19899 for ietf-imapext-bks; Thu, 6 Jun 2002 02:37:48 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g569bln19891 for ; Thu, 6 Jun 2002 02:37:47 -0700 (PDT) Received: from messagingdirect.com (gagarin.isode.com [193.133.227.138]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id g569bjd19911; Thu, 6 Jun 2002 03:37:46 -0600 Message-ID: <3CFF2D6A.5E6470B0@messagingdirect.com> Date: Thu, 06 Jun 2002 03:37:46 -0600 From: Alexey Melnikov Organization: ACI WorldWide / MessagingDirect X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: New revision of ACL2 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've submitted a new revision of ACL2 to the draft editor. There are four major groups of open issues left in the document. These issues can be shortly described as follows: 1). escape character for special identifiers and groups. 2). rights required for different IMAP commands. 3). set of rights associated with READ-WRITE response code. 4). changing ACLs for a list of mailboxes. I will post a separate message for each group of issues. Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Richmond, Surrey, UK Phone: +44 20 8332 4508 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g53Egmp28462 for ietf-imapext-bks; Mon, 3 Jun 2002 07:42:48 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g53Egkg28458 for ; Mon, 3 Jun 2002 07:42:46 -0700 (PDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g53EggO08568 for ; Mon, 3 Jun 2002 10:42:42 -0400 Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with SMTP id g53Eggk64694 for ; Mon, 3 Jun 2002 10:42:42 -0400 Message-ID: <07e601c20b0c$ea644c70$40280209@watson.ibm.com> From: "Barry Leiba" To: "IMAP extensions Mailing List" Subject: Re: Stalled? Date: Mon, 3 Jun 2002 10:42:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I will get a List Extensions update out within the next couple of days. Barry -- Barry Leiba, Internet Messaging Technology (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba