Received: by ns.secondary.com (8.9.3/8.9.3) id DAA06074 for ietf-imapext-bks; Mon, 26 Jun 2000 03:45:55 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA06070 for ; Mon, 26 Jun 2000 03:45:53 -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 GAA29330; Mon, 26 Jun 2000 06:46:26 -0400 (EDT) Message-Id: <200006261046.GAA29330@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-03.txt Date: Mon, 26 Jun 2000 06:46:26 -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 Filename : draft-ietf-imapext-sort-03.txt Pages : 10 Date : 23-Jun-00 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-03.txt 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-03.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-03.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: <20000623134934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000623134934.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id NAA03419 for ietf-imapext-bks; Sat, 24 Jun 2000 13:15:53 -0700 (PDT) Received: from episteme-software.com (resnick1.qualcomm.com [63.250.90.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03415 for ; Sat, 24 Jun 2000 13:15:51 -0700 (PDT) Received: from mtdsl-25.mcleodusa.net (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.1a1) for ; Sat, 24 Jun 2000 15:15:29 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 4.3.1b20-05.00] Date: Sat, 24 Jun 2000 15:15:28 -0500 To: ietf-imapext@imc.org From: Pete Resnick Subject: WG drafts Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: During the "lack of working-group-ness", several drafts were submitted that didn't get on the WG page. Currently, SORT and ACL are on the WG page, but others are not. Here's my list of what I will ask Natalia to move there: draft-crispin-imapext-thread-01.txt (as draft-ietf-imapext-thread-00.txt) draft-daboo-imapext-annotate-00.txt (as draft-ietf-imapext-annotate-00.txt) draft-daboo-imapext-view-02.txt (as draft-ietf-imapext-view-00.txt) draft-gellens-imapext-regex-00.txt (as draft-ietf-imapext-regex-00.txt) Are there others? Specifically, should the following be WG drafts? draft-crispin-imap-multiappend-01.txt draft-daboo-imap-commandplus-01.txt Any others I'm missing? pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA29367 for ietf-imapext-bks; Tue, 13 Jun 2000 10:01:56 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29363 for ; Tue, 13 Jun 2000 10:01:54 -0700 (PDT) Received: from sardis.cyrusoft.com (sardis.cyrusoft.com [206.31.218.203]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA10423 for ; Tue, 13 Jun 2000 13:00:34 -0400 (EDT) Date: Tue, 13 Jun 2000 13:01:22 -0400 From: Cyrus Daboo To: IMAP Extensions WG Subject: VIEW draft futures Message-ID: <578737.3169890082@sardis.cyrusoft.com> X-Mailer: Mulberry/2.0.1b1 (MacOS) 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 folks, At the recent IMC MailConnect event there was a discussion of the VIEW draft, specifically in relation to the dynamic vs se,i-dynamic behaviour. There was generally consensus among the folks there that the most recently proposed approach of using a new \VIEW flag was well worth considering and that a new draft should be drawn up along those lines. If there are no general objections to this from other people on this list then I'm going to go ahead and produce a new draft in the next day or two describing the new approach. It would be nice to get this whole debate wrapped up before the Pittsburgh IETF so we can move on to other contentious issues ;-) -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id JAA29075 for ietf-imapext-bks; Tue, 13 Jun 2000 09:44:08 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (dmt@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29071 for ; Tue, 13 Jun 2000 09:44:07 -0700 (PDT) Date: Tue, 13 Jun 2000 09:30:36 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) To: John Haxby cc: Dimrub@icomverse.com, ietf-imapext@imc.org In-Reply-To: <3945F0EC.C6187644@pwd.hp.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, 13 Jun 2000 09:29:32 +0100, John Haxby wrote: > There is some merit in stripping "re:" from the front of a subject, but the > variability of indicating forwarded messages (I can think of three distinct > conventions off hand) not to mention trying to decide whether the indicator > is "fwd", "fw", "fyi", "whatever-the-russion-for-fwd-is" make this > particular task somewhat difficult. True. The SORT specification recognizes fwd:, fw:, [fwd:...], fwd[...]:, and fw[...]:. This definitely covers most of the cases. Yes, Netscape-style [fwd:...] is going into the next revision... :-( > The 98% of cases that Tony mentions may well apply for "re:" but I doubt it > even comes close for forwarded message indicators, even in the English > speaking world. Hmm. Let me put it this way. If I had my druthers, I would not have done subject extraction for forwarded messages. However, I did not have my druthers, it has been done (in both UW and Cyrus), and we would have an angry mob of users if we tried to remove it now. I hope that we can (however reluctantly) let this matter stand and move on to the next issue. Received: by ns.secondary.com (8.9.3/8.9.3) id BAA01361 for ietf-imapext-bks; Tue, 13 Jun 2000 01:30:12 -0700 (PDT) Received: from bbnrel4.net.external.hp.com (bbnrel4.net.external.hp.com [155.208.254.68]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA01356 for ; Tue, 13 Jun 2000 01:30:09 -0700 (PDT) Received: from hpopd.pwd.hp.com (hpopd.pwd.hp.com [15.145.205.59]) by bbnrel4.net.external.hp.com (Postfix) with ESMTP id 7D498A14A; Tue, 13 Jun 2000 10:29:35 +0200 (METDST) Received: from pwd.hp.com (ilex.pwd.hp.com [15.145.204.106]) by hpopd.pwd.hp.com (8.9.3/8.9.3 SMKit7.01 OpenMail) with ESMTP id JAA20045; Tue, 13 Jun 2000 09:29:33 +0100 (BST) Message-ID: <3945F0EC.C6187644@pwd.hp.com> Date: Tue, 13 Jun 2000 09:29:32 +0100 From: John Haxby Organization: OpenMail R&D X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dimrub@icomverse.com Cc: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) References: <479518ED4F21D411B46D0030480035BC2FFEF5@unity-mail.icomverse.co> Content-Type: multipart/mixed; boundary="------------F409ACDB615328DEA7288169" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F409ACDB615328DEA7288169 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimrub@icomverse.com wrote: > anything but the "re" and "fwd?" prefixes. The ones I know of (russian and > german) are quite popular in the respective locations. Also, there is no > mentioning of the de-facto standard for mailing-lists e-mails (a subject > starting with the name of the ml in a square brackets). Even worse, some mailers allow the user to customise these prefixes to suit their own purposes. There is some merit in stripping "re:" from the front of a subject, but the variability of indicating forwarded messages (I can think of three distinct conventions off hand) not to mention trying to decide whether the indicator is "fwd", "fw", "fyi", "whatever-the-russion-for-fwd-is" make this particular task somewhat difficult. The 98% of cases that Tony mentions may well apply for "re:" but I doubt it even comes close for forwarded message indicators, even in the English speaking world. (Of course, I could be talking complete garbage, I've only lightly skimmed the draft. Please just ignore me if I'm talking nonsense.) jch --------------F409ACDB615328DEA7288169 Content-Type: text/x-vcard; charset=us-ascii; name="jch.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for John Haxby Content-Disposition: attachment; filename="jch.vcf" begin:vcard n:Haxby;John tel;fax:+44 1344 763686 tel;work:+44 1344 763711 x-mozilla-html:FALSE url:https://ecardfile.com/id/jch org:Hewlett Packard;OpenMail R&D adr:;;Nine Mile Ride;Wokingham;Berks;RG40 3LL;England version:2.1 email;internet:john_haxby@hp.com x-mozilla-cpt:;-11552 fn:John Haxby end:vcard --------------F409ACDB615328DEA7288169-- Received: by ns.secondary.com (8.9.3/8.9.3) id OAA15833 for ietf-imapext-bks; Mon, 12 Jun 2000 14:10:50 -0700 (PDT) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15829 for ; Mon, 12 Jun 2000 14:10:48 -0700 (PDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id OAA32158; Mon, 12 Jun 2000 14:10:14 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (trungt@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id OAA22480; Mon, 12 Jun 2000 14:10:14 -0700 Date: Mon, 12 Jun 2000 14:06:52 -0700 (PDT) From: Mark Crispin Subject: Re: LAST CALL: I-D ACTION:draft-crispin-imap-multiappend-01.txt (fwd) To: Pete Maclean cc: IMAP Interest List , IMAP Extensions WG In-Reply-To: <4.3.1.2.20000612135220.00d086a0@pop.webcom.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 Mon, 12 Jun 2000 13:54:24 -0700, Pete Maclean wrote: > Maybe I am missing something simple and obvious but it is not clear to me > how the client indicates the end of a batch to the server. It does so by completing the command (with the command-terminating CRLF) instead of sending another append-message. Remember that a single APPEND is tag "APPEND" mailbox append-message CRLF So, a two message multiappend is tag "APPEND" mailbox append-message append-message CRLF a three message multiappend is tag "APPEND" mailbox append-message append-message append-message CRLF etc. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA15437 for ietf-imapext-bks; Mon, 12 Jun 2000 13:55:33 -0700 (PDT) Received: from loviatar.webcom.com (loviatar.webcom.com [209.1.28.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15432 for ; Mon, 12 Jun 2000 13:55:32 -0700 (PDT) Received: from kigal (kigal.webcom.com [209.1.28.57]) by loviatar.webcom.com (8.9.1/8.9.1) with SMTP id NAA23619; Mon, 12 Jun 2000 13:54:28 -0700 Received: from [63.197.16.166] by inanna.webcom.com (WebCom SMTP 1.2.1) with SMTP id 2605521; Mon Jun 12 13:52 PDT 2000 Message-Id: <4.3.1.2.20000612135220.00d086a0@pop.webcom.com> X-Sender: aaddict@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 12 Jun 2000 13:54:24 -0700 To: Mark Crispin , IMAP Interest List , IMAP Extensions WG From: Pete Maclean Subject: Re: LAST CALL: I-D ACTION:draft-crispin-imap-multiappend-01.txt (fwd) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Maybe I am missing something simple and obvious but it is not clear to me how the client indicates the end of a batch to the server. Pete Maclean At 09:29 AM 6/12/2000 -0700, Mark Crispin wrote: >I wish to issue a LAST CALL on the MULTIAPPEND specification. MULTIAPPEND >is implemented in both UW imapd and Cyrus imapd. It will also be used in >the next version of Pine and imap-utils. > >---------- Forwarded message ---------- >Date: Mon, 12 Jun 2000 06:42:55 -0400 >From: Internet-Drafts@ietf.org >To: IETF-Announce: ; >Subject: I-D ACTION:draft-crispin-imap-multiappend-01.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND > EXTENSION > Author(s) : M. Crispin > Filename : draft-crispin-imap-multiappend-01.txt > Pages : 6 > Date : 09-Jun-00 > >This document describes the multiappending extension to the [IMAP] >protocol. This extension provides substantial performance >improvements for IMAP clients which upload multiple messages at a >time to a mailbox on the server. >A server which supports this extension indicates this with a >capability name of 'MULTIAPPEND'. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-crispin-imap-multiappend-01.txt > >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-crispin-imap-multiappend-01.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-crispin-imap-multiappend-01.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-Draf > Received: by ns.secondary.com (8.9.3/8.9.3) id MAA14197 for ietf-imapext-bks; Mon, 12 Jun 2000 12:50:41 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (tarigan@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14188 for ; Mon, 12 Jun 2000 12:50:36 -0700 (PDT) Date: Mon, 12 Jun 2000 12:18:25 -0700 (PDT) From: Mark Crispin Subject: RE: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) To: "Rubinstein, Dmitry" cc: IMAP Extensions WG In-Reply-To: <479518ED4F21D411B46D0030480035BC2FFEF5@unity-mail.icomverse.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 Mon, 12 Jun 2000 22:03:21 +0300, Rubinstein, Dmitry wrote: > As I did about a year ago, when this draft first appeared, I'd like to > object to the way the subject is extracted. I think that you missed the support for the mailing list convention of mailing list name in square brackets; it is fully supported now, albeit with the unpleasant name "subj-blob". I would not be at all unhappy about using a better term than blob, as long as that term is suitable for use in the grammer (that's why I can't use the obvious phrases). I understand, and sympathize, with your objections to "re" and "fwd". Nevertheless, I content that this is the case of "perfection being the enemy of getting the job done." There is a strong expectation among Pine users, who use SORT heavily, that "the right thing" happen. The subject extraction rules are implemented by both the UW and Cyrus servers because the functionality is next to useless without them. "re:" is an internationally recognized convention. Contrary to popular rumor, it is not an abbreviation of the English word "regarding"; it is Latin ("res" as in the legal term "in re"). There are well-known problems associated with localized versions of "re:"; most notoriously the impossibility of fixing the infamous "cascading re: problem" when other tokens are used. Most software developers have accepted the alternative of using "re:" in actual messages, but localizing it for the display. "fwd" is unfortunate, but is commonly-used enough to be necessary. Received: by ns.secondary.com (8.9.3/8.9.3) id MAA14066 for ietf-imapext-bks; Mon, 12 Jun 2000 12:40:38 -0700 (PDT) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14061 for ; Mon, 12 Jun 2000 12:40:37 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id PAA19959 for ; Mon, 12 Jun 2000 15:39:31 -0400 (EDT) Received: from att.com ([135.197.86.174]) by maillennium.att.com (labmail) with SMTP id <2000061219370709904600d6e>; Mon, 12 Jun 2000 19:37:07 +0000 Message-ID: <39453C32.F88090C6@att.com> Date: Mon, 12 Jun 2000 15:38:26 -0400 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.73 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Rubinstein, Dmitry" CC: IMAP Extensions WG Subject: Re: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) References: <479518ED4F21D411B46D0030480035BC2FFEF5@unity-mail.icomverse.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: There is most definitely a standard for reply subjects. Mailers should be using Re:, from the latin word 'res', for replies - there is no further "localization" necessary; this is even mentioned in rfc822bis. The lack of a recommended standard for forwarded messages is unfortunate. This doesn't mean that we can't also pick the prevailing practice and codifing it. The use of [ml] is a fairly recent practice and is anything but universal, but I don't have a problem with adding support for it. Handling 98% of the cases is better than none. Tony Hansen tony@att.com "Rubinstein, Dmitry" wrote: > > As I did about a year ago, when this draft first appeared, I'd like to > object to the way the subject is extracted. I beleive there was no > convincing counterargument then, so here it goes again. > > There are no provisions whatsoever to localized mailers that use > anything but the "re" and "fwd?" prefixes. The ones I know of (russian and > german) are quite popular in the respective locations. Also, there is no > mentioning of the de-facto standard for mailing-lists e-mails (a subject > starting with the name of the ml in a square brackets). > > I suggest to drop the topic of subject extraction until there is a > standard for response/forward subject (or any other way to learn the > original subject). The rules presented in the draft seem to be an arbitrary > choice (even though I understand that they probably are good for the > majority of the mailers/users). > > -- > Dmitry Rubinstein > > > -----Original Message----- > > From: Mark Crispin [mailto:mrc@cac.washington.edu] > > Sent: Monday, June 12, 2000 7:33 PM > > To: IMAP Extensions WG > > Subject: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) > > > > > > This is a close to final version of the SORT specification. > > This is the > > non-extended form of SORT; work hasn't really started on the > > extended form > > and can't until the non-extended form is done and out of the way. > > > > The changes are to the descriptions of some of the SORT > > criteria, and to > > the subject extraction rules. There are a few more tweaks > > yet to be made > > to the subject extraction rules, most notably support for > > Netscape-style > > "[Fwd: ...]". Received: by ns.secondary.com (8.9.3/8.9.3) id MAA13545 for ietf-imapext-bks; Mon, 12 Jun 2000 12:08:40 -0700 (PDT) Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13541 for ; Mon, 12 Jun 2000 12:08:37 -0700 (PDT) Received: from ismailout.icomverse.com (Efrat-FR3.ser.netvision.net.il [199.203.174.65]) by alpha.netvision.net.il (8.9.3/8.8.6) with ESMTP id WAA15899 for ; Mon, 12 Jun 2000 22:06:56 +0300 (IDT) Received: from unity-mail.icomverse.com (unity-mail.icomverse.com [89.119.41.3]) by ismailout.icomverse.com (8.10.1/8.10.1) with ESMTP id e5CK3G813641 for ; Mon, 12 Jun 2000 23:03:21 +0300 Received: by unity-mail.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 22:03:22 +0300 Message-ID: <479518ED4F21D411B46D0030480035BC2FFEF5@unity-mail.icomverse.com> From: "Rubinstein, Dmitry" To: IMAP Extensions WG Subject: RE: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) Date: Mon, 12 Jun 2000 22:03:21 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1251" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As I did about a year ago, when this draft first appeared, I'd like to object to the way the subject is extracted. I beleive there was no convincing counterargument then, so here it goes again. There are no provisions whatsoever to localized mailers that use anything but the "re" and "fwd?" prefixes. The ones I know of (russian and german) are quite popular in the respective locations. Also, there is no mentioning of the de-facto standard for mailing-lists e-mails (a subject starting with the name of the ml in a square brackets). I suggest to drop the topic of subject extraction until there is a standard for response/forward subject (or any other way to learn the original subject). The rules presented in the draft seem to be an arbitrary choice (even though I understand that they probably are good for the majority of the mailers/users). -- Dmitry Rubinstein > -----Original Message----- > From: Mark Crispin [mailto:mrc@cac.washington.edu] > Sent: Monday, June 12, 2000 7:33 PM > To: IMAP Extensions WG > Subject: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) > > > This is a close to final version of the SORT specification. > This is the > non-extended form of SORT; work hasn't really started on the > extended form > and can't until the non-extended form is done and out of the way. > > The changes are to the descriptions of some of the SORT > criteria, and to > the subject extraction rules. There are a few more tweaks > yet to be made > to the subject extraction rules, most notably support for > Netscape-style > "[Fwd: ...]". Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12471 for ietf-imapext-bks; Mon, 12 Jun 2000 10:59:20 -0700 (PDT) Received: from exchange2.activevoice.com (sea-gateway1.activevoice.com [198.207.218.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12467 for ; Mon, 12 Jun 2000 10:59:19 -0700 (PDT) Received: by exchange2.activevoice.com with Internet Mail Service (5.5.2448.0) id ; Mon, 12 Jun 2000 10:58:39 -0700 Message-ID: <61B452CEA1F9D11195A600A024C65C6902814FCE@exchange2.activevoice.com> From: Rohit Sehgal To: IMAP Interest List , IMAP Extensions WG Subject: IMAP Voice Extensions Date: Mon, 12 Jun 2000 10:58:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Some time back I saw draft for "IMAP Voice Extensions". Does any body know if it was approved or abandoned. On IMAP.org it says that draft is expired. thanks Rohit Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA08518 for ietf-imapext-bks; Mon, 12 Jun 2000 09:33:25 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (wwoodf@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08514 for ; Mon, 12 Jun 2000 09:33:24 -0700 (PDT) Date: Mon, 12 Jun 2000 09:32:48 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG Subject: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: This is a close to final version of the SORT specification. This is the non-extended form of SORT; work hasn't really started on the extended form and can't until the non-extended form is done and out of the way. The changes are to the descriptions of some of the SORT criteria, and to the subject extraction rules. There are a few more tweaks yet to be made to the subject extraction rules, most notably support for Netscape-style "[Fwd: ...]". ---------- Forwarded message ---------- Date: Mon, 12 Jun 2000 06:43:34 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: ietf-imapext@imc.org Subject: I-D ACTION:draft-ietf-imapext-sort-02.txt 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 Filename : draft-ietf-imapext-sort-02.txt Pages : 10 Date : 09-Jun-00 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-02.txt 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-02.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-02.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 Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-ietf-imapext-sort-02.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA08332 for ietf-imapext-bks; Mon, 12 Jun 2000 09:29:55 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (stuart@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08327 for ; Mon, 12 Jun 2000 09:29:53 -0700 (PDT) Date: Mon, 12 Jun 2000 09:29:16 -0700 (PDT) From: Mark Crispin To: IMAP Interest List , IMAP Extensions WG Subject: LAST CALL: I-D ACTION:draft-crispin-imap-multiappend-01.txt (fwd) Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: I wish to issue a LAST CALL on the MULTIAPPEND specification. MULTIAPPEND is implemented in both UW imapd and Cyrus imapd. It will also be used in the next version of Pine and imap-utils. ---------- Forwarded message ---------- Date: Mon, 12 Jun 2000 06:42:55 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-crispin-imap-multiappend-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION Author(s) : M. Crispin Filename : draft-crispin-imap-multiappend-01.txt Pages : 6 Date : 09-Jun-00 This document describes the multiappending extension to the [IMAP] protocol. This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of 'MULTIAPPEND'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imap-multiappend-01.txt 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-crispin-imap-multiappend-01.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-crispin-imap-multiappend-01.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 Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-crispin-imap-multiappend-01.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id DAA00533 for ietf-imapext-bks; Mon, 12 Jun 2000 03:44:13 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00529 for ; Mon, 12 Jun 2000 03:44: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 GAA27775; Mon, 12 Jun 2000 06:43:34 -0400 (EDT) Message-Id: <200006121043.GAA27775@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-02.txt Date: Mon, 12 Jun 2000 06:43:34 -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 Filename : draft-ietf-imapext-sort-02.txt Pages : 10 Date : 09-Jun-00 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-02.txt 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-02.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-02.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: <20000609131425.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000609131425.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id JAA28707 for ietf-imapext-bks; Thu, 8 Jun 2000 09:08:44 -0700 (PDT) Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28671 for ; Thu, 8 Jun 2000 09:08:40 -0700 (PDT) From: zainprov@swbell.net Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00D3BFA52U@mta5.rcsntx.swbell.net> for ietf-imapext@imc.org; Thu, 8 Jun 2000 11:05:09 -0500 (CDT) Date: Thu, 08 Jun 2000 11:05:09 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: ietf-imapext@imc.org Message-id: <0FVU00DF0FCJ2U@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA13616 for ietf-imapext-bks; Tue, 6 Jun 2000 13:30:15 -0700 (PDT) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13612 for ; Tue, 6 Jun 2000 13:30:14 -0700 (PDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id NAA04605; Tue, 6 Jun 2000 13:38:31 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (smj@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id NAA25408; Tue, 6 Jun 2000 13:38:31 -0700 Date: Tue, 6 Jun 2000 12:32:35 -0700 (PDT) From: Mark Crispin Subject: re: ACL inheritance (was Re: I-D ACTION:draft-ietf-imapext-acl-00.txt) To: Chris Newman cc: ietf-imapext@imc.org In-Reply-To: <1344264.3169270113@localhost> 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, 06 Jun 2000 08:48:33 -0700, Chris Newman wrote: > > [Using "+" to indicate inheritance.] > (1) The identifier namespace for ACL is user-visible and has direct impact > on the UI. This makes it too complex. Then perhaps you would consider my alternative proposal, which is to remove inheritance and negative rights from the specification entirely. You only need negative rights if you have inheritance, and IMHO this is a rathole. > (2) I've been using AFS-style ACLs in production for over ten years and > have never seen a situation like the one Mark described. I don't know if AFS permits this or not; but AFS should not be the determinant as to what is permitted (as opposed to required) in IMAP ACLs. An existing access control mechanism used for mail offers it; IMAP ACLs should have a means to express it. > (3) The situation Mark postulates can also be addressed by using a more > sophisticated group management system. Right now, IMAP ACLs don't have any group management system, and what we're talking about is something that prohibits a group management system that already exists. Instead of adding complexity, we should be deleting it if it's breaking something that's already there. > (4) I'm aware of two widely deployed ACL systems that can be considered > successful -- AFS-style and NT-style. > There is also one ACL system > which can be considered a failure -- the Posix ACL system. Others come to mind: VMS, MULTICS, TOPS-10 FILDAE. However, the danger in applying lessons from other environments is that it can lead you to incorrect conclusions. > Although Mark's recommendation doesn't include the full > complexity of Posix ACLs, it's clearly moving in that direction. I don't see how that follows. The primary aspects of my proposal are: 1) deleting inheritance and negative rights; all identifiers have independent rights. This is a simplification. 2) a definition of groups (which is lacking now) and allowing groups to include other groups. This is basically a simple macro mechanism. 3) an optional definition of a few conventions to say "if you are going to do the thing called `owner' on UNIX, call it such-and-such." This is definitely optional, and is intended solely to make the user interface more consistant. But if it causes people to be hung up on the example of POSIX ACLs, then I'll drop it. > (5) The operational experience I've had with AFS-style ACLs and 2086 style > ACLs with inheritance suggests that not only is mandatory inheritance a > good idea, but it's intuitive to end-users. I don't know enough about AFS to comment intelligently, but RFC 2086 does not provide any mechanism for groups. Groups are what cause the problem with inheritance. How is it intuitive for fred, who has explicit "lr" rights, not to be able to select a mailbox because some group that fred is in has negative "lr" rights? > (6) When I explicitly deny someone or some group rights to a given mailbox, > it is almost always for security reasons (indeed I can't think of an > exception at the moment). So I consider it an important security feature > that negative rights overide everything else with no exceptions. Otherwise > an administrator might not realize there was some other entry in some > random ACL which might create an unintended exception to his security > policy. This isn't "some random ACL". It is one of the identifier/rights pairs in the ACL that the administrator is overriding. With inheritance and negative rights, the interactions are somewhat magical once groups are in the picture. fred may be listed as having certain rights, but he actually doesn't because of some group; and to make things worse fred gains or loses those rights by an event (group membership manipulation) that happens completely outside of ACL. Without inheritance and negative rights, it is clear and unambiguous. If an identifier is listed as having certain rights, it has those rights; if it is not so listed, then it does not have those rights. I believe that it is much simpler and easier to document without inheritance; and once inheritance is out of the picture than negative rights are no longer necessary either. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13314 for ietf-imapext-bks; Tue, 6 Jun 2000 13:10:22 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13310 for ; Tue, 6 Jun 2000 13:10:21 -0700 (PDT) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id QAA26567; Tue, 6 Jun 2000 16:17:25 -0400 (EDT) Date: Tue, 06 Jun 2000 16:18:14 -0400 From: Cyrus Daboo To: Chris Newman , Mark Crispin cc: ietf-imapext@imc.org Subject: re: Server says "NO" (was Re: I-D ACTION:draft-ietf-imapext-acl-00.txt) Message-ID: <26530000.960322694@socrates.cyrusoft.com> In-Reply-To: <2265149.3169285487@nifty-jr.west.sun.com> X-Mailer: Mulberry/2.0.1a1 (LinuxPPC) 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 06/06/00 13:04:47 -0700 Chris Newman wrote: >> There's no way in the >> current ACL specification to list what identifiers are valid; or to >> indicate what combinations of identifiers (or identifier/rights) are >> valid. You can just find out what rights one single identifier can have, >> separate from any other context. > > I concur. As I said in a separate message, I'd like to see the > identifier namespace specified to a degree that it's possible for a > client to implement identifier completion in the UI. Actually what's more important for clients is to be able to map between identifiers and real names. I'd much rather present real names to a user rather than obscure identifiers. Plus users are going to want to add acls when they know the name of the person they want to add but not necessarily their identifier. I suspect adding some kind of identifier<->name lookup to IMAP ACL is out of scope here, but it would be nice if the server could at least return a URI indicating where the client might go to get such information (e.g. an ldap or acap server URL). -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id MAA13105 for ietf-imapext-bks; Tue, 6 Jun 2000 12:59:07 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13101 for ; Tue, 6 Jun 2000 12:59:06 -0700 (PDT) Received: from westmail1.west.sun.com ([129.153.100.31]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12483 for ; Tue, 6 Jun 2000 13:07:23 -0700 (PDT) Received: from elephant.West.Sun.COM (elephant.West.Sun.COM [129.153.12.10]) by westmail1.west.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA00183 for ; Tue, 6 Jun 2000 13:07:22 -0700 (PDT) Received: from elvira.west.sun.com (elvira [129.153.12.13]) by elephant.West.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id NAA01569 for ; Tue, 6 Jun 2000 13:05:42 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.west.sun.com by elvira.west.sun.com (PMDF V6.0-24 #43970) id <0FVR00B0117EZZ@elvira.west.sun.com> for ietf-imapext@imc.org; Tue, 06 Jun 2000 13:06:50 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by elvira.west.sun.com (PMDF V6.0-24 #43970) with ESMTPA id <0FVR0041717E19@elvira.west.sun.com>; Tue, 06 Jun 2000 13:06:50 -0700 (PDT) Date: Tue, 06 Jun 2000 13:04:47 -0700 From: Chris Newman Subject: re: Server says "NO" (was Re: I-D ACTION:draft-ietf-imapext-acl-00.txt) In-reply-to: To: Mark Crispin Cc: ietf-imapext@imc.org Message-id: <2265149.3169285487@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) 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 Tuesday, June 6, 2000 12:08 -0700 Mark Crispin wrote: > There's no way in the > current ACL specification to list what identifiers are valid; or to > indicate what combinations of identifiers (or identifier/rights) are > valid. You can just find out what rights one single identifier can have, > separate from any other context. I concur. As I said in a separate message, I'd like to see the identifier namespace specified to a degree that it's possible for a client to implement identifier completion in the UI. > These problems exist, whether or not a "replaceacl" operation also > exists. I don't think that this is a good argument against replaceacl. I wasn't arguing against replaceacl -- I was pointing out that if the server can't support an ACL with three users each with independent rights, then the client needs to know that in advance. > Nor do I think that it's feasible to cover all possible cases where the > server would say NO. At some point, you have to fall back on "server said > NO and explained why." Agreed. Sometimes protocol simplicity is more important than UI quality, but we should attempt to maximize both. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12679 for ietf-imapext-bks; Tue, 6 Jun 2000 12:24:11 -0700 (PDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12675 for ; Tue, 6 Jun 2000 12:24:10 -0700 (PDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id MAA31767; Tue, 6 Jun 2000 12:32:27 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (dhack@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id MAA14864; Tue, 6 Jun 2000 12:32:27 -0700 Date: Tue, 6 Jun 2000 12:25:15 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: Chris Newman cc: ietf-imapext@imc.org In-Reply-To: <545560.3169225616@localhost> 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 Mon, 05 Jun 2000 20:26:56 -0700, Chris Newman wrote: > We should at least attempt to come up with a common set of commands and > rights if we can with out too much complexity. Agreed. > I suspect that if we try to unify the AFS ACL inheritance/identifer > semantics and Mark's Unix-style inheritance/identifier semantics the result > will be as vague about semantics as RFC 2086 (and the IMAP mailbox > namespace). I certainly am NOT proposing "Unix-style inheritance/identifier semantics"! Please don't categorize my proposal as such. Yes, I purpose to have a general specification that is implementable with UNIX semantics, but that is something completely different. I hope that the intent for IMAP ACLs is not "AFS inheritance/identifier semantics" either. IMAP ACLs should be what makes sense for IMAP. A general specification should not preclude AFS; two wrongs don't make a right. But the fact that AFS does something in a particular way doesn't mean that it is unconditionally the only way for IMAP. Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12570 for ietf-imapext-bks; Tue, 6 Jun 2000 12:15:59 -0700 (PDT) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12566 for ; Tue, 6 Jun 2000 12:15:57 -0700 (PDT) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id MAA24584; Tue, 6 Jun 2000 12:24:14 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (yfong@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id MAA32654; Tue, 6 Jun 2000 12:24:13 -0700 Date: Tue, 6 Jun 2000 12:08:49 -0700 (PDT) From: Mark Crispin Subject: re: Server says "NO" (was Re: I-D ACTION:draft-ietf-imapext-acl-00.txt) To: Chris Newman cc: ietf-imapext@imc.org In-Reply-To: <575400.3169226112@localhost> 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 would be willing to conceed this point, except for one problem: the current ACL specification has the same deficiency. There's no way in the current ACL specification to list what identifiers are valid; or to indicate what combinations of identifiers (or identifier/rights) are valid. You can just find out what rights one single identifier can have, separate from any other context. These problems exist, whether or not a "replaceacl" operation also exists. I don't think that this is a good argument against replaceacl. Nor do I think that it's feasible to cover all possible cases where the server would say NO. At some point, you have to fall back on "server said NO and explained why." On Mon, 05 Jun 2000 20:35:12 -0700, Chris Newman wrote: > > The server can always say NO to any client request. Isn't that > > sufficient? > > In general, that's not sufficient. In order to present a high quality UI, > the client also needs to know in advance if a particular request will > always fail with a particular server implementation. > > For example, if a "replaceacl" operation listing different rights for three > different users will always fail with a particular server implementation, > then the client needs to know in advance so it can constain user input so > the user won't be able to ask for something the server will never grant. Received: by ns.secondary.com (8.9.3/8.9.3) id IAA05965 for ietf-imapext-bks; Tue, 6 Jun 2000 08:49:59 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05961 for ; Tue, 6 Jun 2000 08:49:58 -0700 (PDT) Received: from westmail1.west.sun.com ([129.153.100.31]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13384 for ; Tue, 6 Jun 2000 08:58:14 -0700 (PDT) Received: from elephant.West.Sun.COM (elephant.West.Sun.COM [129.153.12.10]) by westmail1.west.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA22633 for ; Tue, 6 Jun 2000 08:58:13 -0700 (PDT) Received: from elvira.west.sun.com (elvira [129.153.12.13]) by elephant.West.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id IAA27349 for ; Tue, 6 Jun 2000 08:56:30 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.west.sun.com by elvira.west.sun.com (PMDF V6.0-24 #43970) id <0FVQ00901PO275@elvira.west.sun.com> for ietf-imapext@imc.org; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by elvira.west.sun.com (PMDF V6.0-24 #43970) with ESMTPA id <0FVQ0040FPNX19@elvira.west.sun.com> for ietf-imapext@imc.org; Tue, 06 Jun 2000 08:57:37 -0700 (PDT) Date: Mon, 05 Jun 2000 20:26:56 -0700 From: Chris Newman Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt In-reply-to: <392EBA1A.91074F4F@netscape.com> To: ietf-imapext@imc.org Message-id: <545560.3169225616@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) 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 Friday, May 26, 2000 10:53 -0700 John Gardiner Myers wrote: > After much thought, confirmed by discussion at Adelaide, I've concluded > that Mark's concerns are best addressed by his pursuing a separate > extension. The models of access control are sufficiently different that > an extension trying to address both (or all) models will necessarily be > over complex and difficult to implement on the client side. > > Better each model have its own extension. Then the client will know > which world the server is in and will not have to deal with hybrid > models that don't exist in practice. We should at least attempt to come up with a common set of commands and rights if we can with out too much complexity. I suspect that if we try to unify the AFS ACL inheritance/identifer semantics and Mark's Unix-style inheritance/identifier semantics the result will be as vague about semantics as RFC 2086 (and the IMAP mailbox namespace). In that case, having different IMAP extensions for the different semantics would be a preferable idea in my book. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id IAA05931 for ietf-imapext-bks; Tue, 6 Jun 2000 08:49:42 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05924 for ; Tue, 6 Jun 2000 08:49:40 -0700 (PDT) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13174 for ; Tue, 6 Jun 2000 08:57:55 -0700 (PDT) Received: from elephant.West.Sun.COM (elephant.West.Sun.COM [129.153.12.10]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA28006 for ; Tue, 6 Jun 2000 08:57:55 -0700 (PDT) Received: from elvira.west.sun.com (elvira [129.153.12.13]) by elephant.West.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id IAA27352 for ; Tue, 6 Jun 2000 08:56:30 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.west.sun.com by elvira.west.sun.com (PMDF V6.0-24 #43970) id <0FVQ00901PO276@elvira.west.sun.com> for ietf-imapext@imc.org; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by elvira.west.sun.com (PMDF V6.0-24 #43970) with ESMTPA id <0FVQ0040FPNX19@elvira.west.sun.com>; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Date: Mon, 05 Jun 2000 20:35:12 -0700 From: Chris Newman Subject: Server says "NO" (was Re: I-D ACTION:draft-ietf-imapext-acl-00.txt) In-reply-to: To: Mark Crispin Cc: ietf-imapext@imc.org Message-id: <575400.3169226112@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) 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 Friday, June 2, 2000 16:05 -0700 Mark Crispin wrote: > The server can always say NO to any client request. Isn't that > sufficient? In general, that's not sufficient. In order to present a high quality UI, the client also needs to know in advance if a particular request will always fail with a particular server implementation. For example, if a "replaceacl" operation listing different rights for three different users will always fail with a particular server implementation, then the client needs to know in advance so it can constain user input so the user won't be able to ask for something the server will never grant. - Chris Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA05936 for ietf-imapext-bks; Tue, 6 Jun 2000 08:49:42 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05932 for ; Tue, 6 Jun 2000 08:49:41 -0700 (PDT) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13189 for ; Tue, 6 Jun 2000 08:57:57 -0700 (PDT) Received: from elephant.West.Sun.COM (elephant.West.Sun.COM [129.153.12.10]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA28015 for ; Tue, 6 Jun 2000 08:57:56 -0700 (PDT) Received: from elvira.west.sun.com (elvira [129.153.12.13]) by elephant.West.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id IAA27368 for ; Tue, 6 Jun 2000 08:56:31 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.west.sun.com by elvira.west.sun.com (PMDF V6.0-24 #43970) id <0FVQ00901PO27A@elvira.west.sun.com> for ietf-imapext@imc.org; Tue, 06 Jun 2000 08:57:39 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by elvira.west.sun.com (PMDF V6.0-24 #43970) with ESMTPA id <0FVQ0040FPNX19@elvira.west.sun.com>; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Date: Tue, 06 Jun 2000 08:48:33 -0700 From: Chris Newman Subject: ACL inheritance (was Re: I-D ACTION:draft-ietf-imapext-acl-00.txt) To: Mark Crispin Cc: ietf-imapext@imc.org Message-id: <1344264.3169270113@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) Content-type: text/plain; charset=us-ascii; format=flowed; 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, May 25, 2000 19:46 -0700 Mark Crispin wrote: > PROBLEM: Unlike RFC 2086, this new draft requires rights inheritance; > that is, an identifier automatically has the rights of "anyone" unless > these are specifically denied as negative rights. RFC 2086 allowed > implementations to decide if rights were inherited or not. > > Although removing the ambiguity is a good idea, I question whether it's > really such a good idea to insist upon inheritance. In particular, the > inheritance of negative rights is problematic. > > RECOMMENDATION: The draft should be modified to indicate whether or not an > identifier has inheritance semantics. I suggest using + for this > purpose. In other words: > +anyone lr > means that all users can list and read the mailbox unless specifically > denied by a - identifier, whereas: > anyone lr > means that all users who aren't otherwise listed by an identifier can > read and list the mailbox. Also, + and - can be combined to cause > negative rights inheritance. I am strongly opposed to this recommendation for the following reasons: (1) The identifier namespace for ACL is user-visible and has direct impact on the UI. This makes it too complex. Were I writing a GUI client, I'd stick "+" on every identifier, because I can't think of any way to express the semantics of an optional "+" to an end user in a GUI. (2) I've been using AFS-style ACLs in production for over ten years and have never seen a situation like the one Mark described. This is an uncommon borderline case at best. (3) The situation Mark postulates can also be addressed by using a more sophisticated group management system. If I can construct a new group that consists of the original group and an exceptions list, that solves the problem without complicating the end-user ACL GUI. (4) I'm aware of two widely deployed ACL systems that can be considered successful -- AFS-style and NT-style. I'm unsure of the field experience with NT-style ACLs. I am sure of the field experience with AFS ACLs -- it's a very successful system, and the inheritance model John proposes comes directly from that successful system. There is also one ACL system which can be considered a failure -- the Posix ACL system. It is almost always mentioned in the short list of reasons why DFS failed. The Posix ACL system was complicated enough that nobody understood it, largely because it was attempting to be backwards compatible with Unix owner/group semantics. Although Mark's recommendation doesn't include the full complexity of Posix ACLs, it's clearly moving in that direction. (5) The operational experience I've had with AFS-style ACLs and 2086 style ACLs with inheritance suggests that not only is mandatory inheritance a good idea, but it's intuitive to end-users. I've pointed other administrators at AFS and 2086 style ACLs with inheritance and I never had to explain the semantics to them -- they just understood. (6) When I explicitly deny someone or some group rights to a given mailbox, it is almost always for security reasons (indeed I can't think of an exception at the moment). So I consider it an important security feature that negative rights overide everything else with no exceptions. Otherwise an administrator might not realize there was some other entry in some random ACL which might create an unintended exception to his security policy. This is another reason why I believe (3) is the correct solution to the situation Mark postulates. - Chris Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA27127 for ietf-imapext-bks; Fri, 2 Jun 2000 16:51:25 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (stud@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA27123 for ; Fri, 2 Jun 2000 16:51:23 -0700 (PDT) Date: Fri, 2 Jun 2000 16:05:08 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: Steve Hole 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 Fri, 2 Jun 2000 14:46:27 -0600, Steve Hole wrote: > Sounds OK. The devil is in the details. I hope to keep the details as minimal as possible. :) > I think that it is very important that the definition of an identifier can > orginate "out-of-band" of IMAP itself, and have an ACL extended client be > able to get that information. "Out-of-band" definition of identifiers > will be the situation for server implementors in the case of a mapping to > other identifier sources. It must be possible for a server do reject > definition of an identifier if it is not "authoritative" for the > identifier namespace. I'm not sure what you mean by this. Could you give an example? My idea is a relatively simple "macro" type mechanism, where an identifier can expand to other identifiers; and certain semantics to indicate whether this "macro" identifier is global, per-mailbox, or possibly per-user. The server can always say NO to any client request. Isn't that sufficient? > Do you have some text (even outline) that specs this so that we can see > what it would look like? I have an outline. I'm not sure that it makes sense to anyone other than me as it stands now. > You can emulate the "change owner" and "change group" by > changing what we would call the "default" ACL set on an entry. It is > not something that we allow in our server (it doesn't really make sense), > but you could do it and that is all that is needed. "Change owner" is probably not something that would normally be done in any case. But "change group" would be done by changing the definition of a certain per-mailbox macro identifier (as opposed to deleting the existing ACL and creating a new one) which on UNIX would be defined as a global macro identifier. For example, suppose $M$group is a per-mailbox identifier meaning "group access for this mailbox". It's defined as $G$cs123, a global identifier which happens to be the UNIX "cs123" group. We can change the definition of $M$group to be $G$cs432 without changing the rights of $M$group. Nor do we ever need to enumerate the membership of $G$cs123 or $G$cs432. Any of these things can be defined, but it's up to the server whether or not a user is allowed to alter the definition (or create) of any identifier. > > I also don't think that it's necessary for the specification to enshrine > > "owner" or "group" in the UNIX sense, but perhaps it may be good to > > document a particular convention for per-mailbox nomenclature of defined > > identifiers of these two. > Hmm ... I'm having trouble parsing this. Do you mean that we should > defiine a convention for representing these concepts based on the generic > model? That would involve some description on the semantics of rights > calculation as well would it not? Sorry for being dense, but I'm not > sure that I'm getting what you want to say here. No, all I mean is something like "if you have something like UNIX mailbox owner, you should call it $M$owner; if you have something like single group access, you should call it $M$group". That way, multiple UNIX mailbox implementations would use the same names. It's just a convention. But absolutely, we don't want to enshrine the UNIX semantics. As far as IMAP is concerned, these are just macro names. They have no magical properties. It's like the "#news." namespace. We all know what it means, but nothing in IMAP says that it means that. As far as IMAP is concerned, it's just a name. > Where I always run into trouble is trying to map the semantics of rights > calculations for an "owner" and "group" IFF you allow negative rights. Exactly. Negative rights imply inheritance. I'd rather not have inheritance at all, and instead say that the first applicable identifier is the one that is used. IMHO, inheritance is a rathole, and we'd be better off without it. Although the absence of inheritance does create certain limitations if a user is a member of multiple groups with different access levels, the result is nonetheless much better than the current definition. Plus, it's much simpler without negative rights and inheritance. If we must have inheritance, then the existing mechanism isn't good enough. It needs to be much more complex. There needs to be inheritance levels to control how negative rights are inherited; a positive right from a higher level overrides a negative right from a lower level. There's probably other considerations that I've overlooked. My mind boggles just thinking about it. > Am I correct that you are suggesting that a server would disallow setting > negative rights if it is mapping to the UNIX "owner" and "group" models? > In other words, just setting things that don't map to the underlying > access control model? If so, then that seems OK to me. Well, not quite. If there's mandatory inheritance (as proposed by the draft), then it is desirable to have negative rights to group. The problem is that those negative rights would then inherit to owner if owner is a member of the group. I want owner's rights to override group. Consider the behavior of the 604 protection code on UNIX. For a non-UNIX example, consider cs123-teacher rwipslda $cs123 -rl anyone rpl With mandatory inheritance, cs123-teacher can't lookup or read the mailbox because he's in $cs123. I don't think that's right. > Why is excluding anonymous the normal case? If I create a "wide open" > ACL for "everyone", why wouldn't I include anonymous in that? My sample of site administrators indicates that they differentiate between anonymous access and authorized user access. This is certainly the case on FTP servers. As a user, I would think twice about making my data world-accessible if I knew that anonymous could get at it as opposed to the other authorized users of the system. In my server, I have the #shared/ namespace which is not permitted to anonymous vs. the #public/ namespace which is permitted to anonymous. > I can see an exmaple where a server might want to partition a namespace by > domain, and then provide anonymous access within a domain. That means that a user in another domain can't grant anonymous access; he would have to copy/move the data to the domain which has anonymous access. Having a global right which means "everybody except anonymous" doesn't preclude doing this. It just makes it unnecessary unless you want to do it that way. Received: by ns.secondary.com (8.9.3/8.9.3) id QAA27025 for ietf-imapext-bks; Fri, 2 Jun 2000 16:35:13 -0700 (PDT) Received: from mail.mirapoint.com (IDENT:mirapoint@mail.mirapoint.com [208.48.74.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA27020 for ; Fri, 2 Jun 2000 16:35:09 -0700 (PDT) Received: from tim-bsd.mirapoint.com (tim-bsd.mirapoint.com [192.168.0.117]) by mail.mirapoint.com (Mirapoint) with SMTP id AAC54817; Fri, 2 Jun 2000 16:43:03 -0700 (PDT) X-Spook: Ft. Knox Ft. Meade militia ammunition COSCO Qaddafi FBI To: Steve Hole Cc: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt References: From: Tim Showalter Date: 02 Jun 2000 16:47:10 -0700 In-Reply-To: Steve Hole's message of "Fri, 2 Jun 2000 15:01:09 -0600" Message-ID: <7dvgzrodc1.fsf@tim-bsd.mirapoint.com> Lines: 12 User-Agent: Gnus/5.0806 (Gnus v5.8.6) XEmacs/21.1 (Canyonlands) 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: Steve Hole writes: > The problem will be with old clients that expect "c" to give you "create" > and "delete" mailbox rights. Is it important? Cyrus (and presumably all of its derivatives at some point) assigned that permission to the `d' bit. FWIW, I also prefer adding a new bit. Overloading anything seems gross to me. Tim Received: by ns.secondary.com (8.9.3/8.9.3) id NAA25423 for ietf-imapext-bks; Fri, 2 Jun 2000 13:53:31 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA25418 for ; Fri, 2 Jun 2000 13:53:30 -0700 (PDT) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e52L1FJ17918; Fri, 2 Jun 2000 15:01:15 -0600 From: Steve Hole Date: Fri, 2 Jun 2000 15:01:09 -0600 To: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Cc: John Gardiner Myers , ietf-imapext@imc.org In-Reply-To: References: Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) 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, 31 May 2000 16:04:50 -0700 (PDT) Mark Crispin wrote: > On Mon, 29 May 2000, Steve Hole wrote: > > (1) The interpretation of various rights identifiers. > > (2) The definition/management of identifiers. > > (3) Rights inheritance. > > I think that this is a good summary. Add a fourth issue: > > (4) Structure of ACL commands and (especially) responses. > > This relates to things such as issuing automatic ACL responses at SELECT > time; the ability to have wildcards in mailbox names; the ability to > replace the entire ACL and/or redefine ACL for multiple identifiers; the > ability to query potential rights for multiple identifiers. Sounds good. I would propose a simple table of "what is there now" vs a "what we propose to have". That way we can compare the value of each and get a nice "deprecate" and "add" set to work with after we have debated the differences. I think that we want to put aside the things that are OK and get to the differences. > > We have had trouble with (1) > > ourselves and I think that it should be fairly easy to come to concensus > > on. > > I hope so. Since rights tying exists, it would be better to add a new > right rather than to overload existing rights with semantics that may not > necessarily make sense to tie together. I'm thinking here about the "c" > right, which should not be overloaded with "delete mailbox". I pretty much agree with this. From a server standpoint, it is easy enough to do. The problem will be with old clients that expect "c" to give you "create" and "delete" mailbox rights. Is it important? The other thing to remember is that I don't think there are that many clients that have implemented ACL support yet. This being the case, it may not be that big a deal to change the semantics. In fact, I think now is the time take the pain to do this based on what the few implementations have learned. As one such implementor, I would support this. Once again, I would propose a table comparing the existing rights to the proposed new rights. That way we can get to the differences right away. Any possibility that you could put something like that together Mark? Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA25258 for ietf-imapext-bks; Fri, 2 Jun 2000 13:38:42 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA25254 for ; Fri, 2 Jun 2000 13:38:40 -0700 (PDT) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e52KkaJ17734; Fri, 2 Jun 2000 14:46:36 -0600 From: Steve Hole Date: Fri, 2 Jun 2000 14:46:27 -0600 To: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Cc: ietf-imapext@imc.org In-Reply-To: References: Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) 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, 31 May 2000 16:37:57 -0700 (PDT) Mark Crispin wrote: > On Mon, 29 May 2000, Steve Hole wrote: > By general, I mean "a mechanism whose ideal state is full implementation" > as opposed to "flexible" which means "a mechanism which expresses > contradictory models, and therefore would never be fully implemented." > > Hierarchy is "flexible"; what I propose for identifiers is "general". Exactly. This sounds like a good definition to me. > My idea basically boils down to this: > 1) a mechanism to define identifiers: global, per-mailbox, and perhaps > also per-user (I don't need the last one, but perhaps other people > do). Defined identifiers can be defined in terms of other > defined identifiers. > 2) a system of naming that makes the type of identifier unambiguous. > 3) a mechanism to look up (expands) the definition of a defined > identifier. > > The impact of this is: > . definition of identifier nomenclature > . command to define an identifier > . command to get the definition of an identifier Sounds OK. The devil is in the details. I think that it is very important that the definition of an identifier can orginate "out-of-band" of IMAP itself, and have an ACL extended client be able to get that information. "Out-of-band" definition of identifiers will be the situation for server implementors in the case of a mapping to other identifier sources. It must be possible for a server do reject definition of an identifier if it is not "authoritative" for the identifier namespace. Tricky. Do you have some text (even outline) that specs this so that we can see what it would look like? > Note that there is no specific "change group" or "change owner"; however, > the necessary functionality is there. The semantics of other existing ACL > mechanisms can be done the same way. I think so too. You can emulate the "change owner" and "change group" by changing what we would call the "default" ACL set on an entry. It is not something that we allow in our server (it doesn't really make sense), but you could do it and that is all that is needed. Assuming convergence on identifier definition, you should be able to do this using the existing model. > I also don't think that it's necessary for the specification to enshrine > "owner" or "group" in the UNIX sense, but perhaps it may be good to > document a particular convention for per-mailbox nomenclature of defined > identifiers of these two. Hmm ... I'm having trouble parsing this. Do you mean that we should defiine a convention for representing these concepts based on the generic model? That would involve some description on the semantics of rights calculation as well would it not? Sorry for being dense, but I'm not sure that I'm getting what you want to say here. > At the specification level, all that should matter is that these > per-mailbox identifiers have ACLs; the per-mailbox identifier that > corresponds to UNIX owner expands to one or more RFC 2086 user name > identifiers, and the per-mailbox identifier that corresponds to UNIX group > expands to a global defined identifier (which in turn expands to one or > more RFC 2086 user name identifiers). > > Of course, the server is always permitted to respond NO to an operation > which it does not agree to do. The semantics of group permissions and membership and the semantics of "owner" permissions are fairly straightforward in isolation. Where I always run into trouble is trying to map the semantics of rights calculations for an "owner" and "group" IFF you allow negative rights. Am I correct that you are suggesting that a server would disallow setting negative rights if it is mapping to the UNIX "owner" and "group" models? In other words, just setting things that don't map to the underlying access control model? If so, then that seems OK to me. > A separate issue is the lack of an identifier that includes everybody > except for anonymous. Since excluding anonymous is the normal case, it > doesn't really work well to have negative rights for anonymous on all > ACLs. Why is excluding anonymous the normal case? If I create a "wide open" ACL for "everyone", why wouldn't I include anonymous in that? I can see an exmaple where a server might want to partition a namespace by domain, and then provide anonymous access within a domain. If the namespace is not truly separate (separated at the root), then you would want "everyone" to map to "everyone in this" domain, and that would not include anonymous. That's about the best example that I can think of, and I would address something like that differently (as we did in our server). > > It was collosal mistake to > > select in favour of the "what the server is able to express" model for > > hierarchy and we should not make the same mistake for ACL identifiers. > > I don't think that the example of hierarchy really applies here. In > hierarchy, two models which were fundamentally hostile to each other were > shoehorned together. In this case, we're talking about extensions to the > existing framework that everybody can implement, and probably would want > to implement. OK. My goal was to make sure that we didn't try to engineer a compromise between incompatible semantic models and it looks like we have concensus on that. I'm happy. We will want to monitor our design from time to time to make sure that we don't run off that road at some point. Treat this a basic design requirement. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA22446 for ietf-imapext-bks; Fri, 2 Jun 2000 10:15:47 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22440 for ; Fri, 2 Jun 2000 10:15:45 -0700 (PDT) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e52HNSJ15903; Fri, 2 Jun 2000 11:23:28 -0600 From: Steve Hole Date: Fri, 2 Jun 2000 11:23:23 -0600 To: David Harris Subject: Re: QUIET option for FETCH Cc: imap@u.washington.edu, ietf-imapext@imc.org In-Reply-To: <39363F0A.23556.2B576D7D@localhost> References: <39363F0A.23556.2B576D7D@localhost> <39352309.18265.2701E1B2@localhost> Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) 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, 1 Jun 2000 11:51:25 +1200 David Harris wrote: > I think you've misunderstood the scope of what I mean. What I want to > be able to do is reduce the bulk of the exchange with the server... I > want to be able to send this - > > A1 FETCH 1 BODY.PEEK[HEADERS ($PMSET)] > > and have the server respond with: > > * 1 FETCH BODY[HEADERS ($PMSET)] > > - but actually act as though I had sent it my list of required headers. > > This is, in fact, exactly how I've done it in Mercury/Pegasus Mail. I've > declared an X- extension via CAPABILITY that tells Pegasus Mail it > can use a new MACRO command at the start of the session to create > a macro for the list of headers it wants. This macro can then be used > in a FETCH command. In my case, this saves something like 350 > completely superfluous bytes per header fetch. I felt this would be a > generally useful addition, since header fetching is something that most > mail clients will need to do extensively. What smoking idea! I love this. David, you have renewed my opinion that you are chap with a head on his shoulders. I see no reason why this should be restricted to header sets. It would be very nice to make it a general feature for any set of commands. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA10377 for ietf-imapext-bks; Thu, 1 Jun 2000 16:12:14 -0700 (PDT) Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.2.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA10373 for ; Thu, 1 Jun 2000 16:12:13 -0700 (PDT) Received: from [207.87.51.142] (vpnap-g1-012016.qualcomm.com [10.13.12.16]) by illyana.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id QAA28194 for ; Thu, 1 Jun 2000 16:20:05 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: QUALCOMM Eudora v4.3 for Macintosh Date: Thu, 1 Jun 2000 16:20:02 -0700 To: ietf-imapext@imc.org From: Randall Gellens Subject: Single-letter codes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > alphabet soup of one letter codes. I think it would be more clear if the rights were longer than single-letters, and less likely to be confused with Unix or other rights. But 2086 already defined them that way. It also means bundling would need another method, perhaps "-", as in "list-adm read seen-write-ins-create-del" instead of "la r swicd" Received: by ns.secondary.com (8.9.3/8.9.3) id DAA06074 for ietf-imapext-bks; Mon, 26 Jun 2000 03:45:55 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA06070 for ; Mon, 26 Jun 2000 03:45:53 -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 GAA29330; Mon, 26 Jun 2000 06:46:26 -0400 (EDT) Message-Id: <200006261046.GAA29330@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-03.txt Date: Mon, 26 Jun 2000 06:46:26 -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 Filename : draft-ietf-imapext-sort-03.txt Pages : 10 Date : 23-Jun-00 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-03.txt 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-03.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-03.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: <20000623134934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000623134934.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id NAA03419 for ietf-imapext-bks; Sat, 24 Jun 2000 13:15:53 -0700 (PDT) Received: from episteme-software.com (resnick1.qualcomm.com [63.250.90.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03415 for ; Sat, 24 Jun 2000 13:15:51 -0700 (PDT) Received: from mtdsl-25.mcleodusa.net (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.1a1) for ; Sat, 24 Jun 2000 15:15:29 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 4.3.1b20-05.00] Date: Sat, 24 Jun 2000 15:15:28 -0500 To: ietf-imapext@imc.org From: Pete Resnick Subject: WG drafts Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: During the "lack of working-group-ness", several drafts were submitted that didn't get on the WG page. Currently, SORT and ACL are on the WG page, but others are not. Here's my list of what I will ask Natalia to move there: draft-crispin-imapext-thread-01.txt (as draft-ietf-imapext-thread-00.txt) draft-daboo-imapext-annotate-00.txt (as draft-ietf-imapext-annotate-00.txt) draft-daboo-imapext-view-02.txt (as draft-ietf-imapext-view-00.txt) draft-gellens-imapext-regex-00.txt (as draft-ietf-imapext-regex-00.txt) Are there others? Specifically, should the following be WG drafts? draft-crispin-imap-multiappend-01.txt draft-daboo-imap-commandplus-01.txt Any others I'm missing? pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA29367 for ietf-imapext-bks; Tue, 13 Jun 2000 10:01:56 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29363 for ; Tue, 13 Jun 2000 10:01:54 -0700 (PDT) Received: from sardis.cyrusoft.com (sardis.cyrusoft.com [206.31.218.203]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA10423 for ; Tue, 13 Jun 2000 13:00:34 -0400 (EDT) Date: Tue, 13 Jun 2000 13:01:22 -0400 From: Cyrus Daboo To: IMAP Extensions WG Subject: VIEW draft futures Message-ID: <578737.3169890082@sardis.cyrusoft.com> X-Mailer: Mulberry/2.0.1b1 (MacOS) 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 folks, At the recent IMC MailConnect event there was a discussion of the VIEW draft, specifically in relation to the dynamic vs se,i-dynamic behaviour. There was generally consensus among the folks there that the most recently proposed approach of using a new \VIEW flag was well worth considering and that a new draft should be drawn up along those lines. If there are no general objections to this from other people on this list then I'm going to go ahead and produce a new draft in the next day or two describing the new approach. It would be nice to get this whole debate wrapped up before the Pittsburgh IETF so we can move on to other contentious issues ;-) -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id JAA29075 for ietf-imapext-bks; Tue, 13 Jun 2000 09:44:08 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (dmt@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29071 for ; Tue, 13 Jun 2000 09:44:07 -0700 (PDT) Date: Tue, 13 Jun 2000 09:30:36 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) To: John Haxby cc: Dimrub@icomverse.com, ietf-imapext@imc.org In-Reply-To: <3945F0EC.C6187644@pwd.hp.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, 13 Jun 2000 09:29:32 +0100, John Haxby wrote: > There is some merit in stripping "re:" from the front of a subject, but the > variability of indicating forwarded messages (I can think of three distinct > conventions off hand) not to mention trying to decide whether the indicator > is "fwd", "fw", "fyi", "whatever-the-russion-for-fwd-is" make this > particular task somewhat difficult. True. The SORT specification recognizes fwd:, fw:, [fwd:...], fwd[...]:, and fw[...]:. This definitely covers most of the cases. Yes, Netscape-style [fwd:...] is going into the next revision... :-( > The 98% of cases that Tony mentions may well apply for "re:" but I doubt it > even comes close for forwarded message indicators, even in the English > speaking world. Hmm. Let me put it this way. If I had my druthers, I would not have done subject extraction for forwarded messages. However, I did not have my druthers, it has been done (in both UW and Cyrus), and we would have an angry mob of users if we tried to remove it now. I hope that we can (however reluctantly) let this matter stand and move on to the next issue. Received: by ns.secondary.com (8.9.3/8.9.3) id BAA01361 for ietf-imapext-bks; Tue, 13 Jun 2000 01:30:12 -0700 (PDT) Received: from bbnrel4.net.external.hp.com (bbnrel4.net.external.hp.com [155.208.254.68]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA01356 for ; Tue, 13 Jun 2000 01:30:09 -0700 (PDT) Received: from hpopd.pwd.hp.com (hpopd.pwd.hp.com [15.145.205.59]) by bbnrel4.net.external.hp.com (Postfix) with ESMTP id 7D498A14A; Tue, 13 Jun 2000 10:29:35 +0200 (METDST) Received: from pwd.hp.com (ilex.pwd.hp.com [15.145.204.106]) by hpopd.pwd.hp.com (8.9.3/8.9.3 SMKit7.01 OpenMail) with ESMTP id JAA20045; Tue, 13 Jun 2000 09:29:33 +0100 (BST) Message-ID: <3945F0EC.C6187644@pwd.hp.com> Date: Tue, 13 Jun 2000 09:29:32 +0100 From: John Haxby Organization: OpenMail R&D X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dimrub@icomverse.com Cc: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) References: <479518ED4F21D411B46D0030480035BC2FFEF5@unity-mail.icomverse.co> Content-Type: multipart/mixed; boundary="------------F409ACDB615328DEA7288169" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------F409ACDB615328DEA7288169 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimrub@icomverse.com wrote: > anything but the "re" and "fwd?" prefixes. The ones I know of (russian and > german) are quite popular in the respective locations. Also, there is no > mentioning of the de-facto standard for mailing-lists e-mails (a subject > starting with the name of the ml in a square brackets). Even worse, some mailers allow the user to customise these prefixes to suit their own purposes. There is some merit in stripping "re:" from the front of a subject, but the variability of indicating forwarded messages (I can think of three distinct conventions off hand) not to mention trying to decide whether the indicator is "fwd", "fw", "fyi", "whatever-the-russion-for-fwd-is" make this particular task somewhat difficult. The 98% of cases that Tony mentions may well apply for "re:" but I doubt it even comes close for forwarded message indicators, even in the English speaking world. (Of course, I could be talking complete garbage, I've only lightly skimmed the draft. Please just ignore me if I'm talking nonsense.) jch --------------F409ACDB615328DEA7288169 Content-Type: text/x-vcard; charset=us-ascii; name="jch.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for John Haxby Content-Disposition: attachment; filename="jch.vcf" begin:vcard n:Haxby;John tel;fax:+44 1344 763686 tel;work:+44 1344 763711 x-mozilla-html:FALSE url:https://ecardfile.com/id/jch org:Hewlett Packard;OpenMail R&D adr:;;Nine Mile Ride;Wokingham;Berks;RG40 3LL;England version:2.1 email;internet:john_haxby@hp.com x-mozilla-cpt:;-11552 fn:John Haxby end:vcard --------------F409ACDB615328DEA7288169-- Received: by ns.secondary.com (8.9.3/8.9.3) id OAA15833 for ietf-imapext-bks; Mon, 12 Jun 2000 14:10:50 -0700 (PDT) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15829 for ; Mon, 12 Jun 2000 14:10:48 -0700 (PDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id OAA32158; Mon, 12 Jun 2000 14:10:14 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (trungt@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id OAA22480; Mon, 12 Jun 2000 14:10:14 -0700 Date: Mon, 12 Jun 2000 14:06:52 -0700 (PDT) From: Mark Crispin Subject: Re: LAST CALL: I-D ACTION:draft-crispin-imap-multiappend-01.txt (fwd) To: Pete Maclean cc: IMAP Interest List , IMAP Extensions WG In-Reply-To: <4.3.1.2.20000612135220.00d086a0@pop.webcom.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 Mon, 12 Jun 2000 13:54:24 -0700, Pete Maclean wrote: > Maybe I am missing something simple and obvious but it is not clear to me > how the client indicates the end of a batch to the server. It does so by completing the command (with the command-terminating CRLF) instead of sending another append-message. Remember that a single APPEND is tag "APPEND" mailbox append-message CRLF So, a two message multiappend is tag "APPEND" mailbox append-message append-message CRLF a three message multiappend is tag "APPEND" mailbox append-message append-message append-message CRLF etc. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA15437 for ietf-imapext-bks; Mon, 12 Jun 2000 13:55:33 -0700 (PDT) Received: from loviatar.webcom.com (loviatar.webcom.com [209.1.28.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15432 for ; Mon, 12 Jun 2000 13:55:32 -0700 (PDT) Received: from kigal (kigal.webcom.com [209.1.28.57]) by loviatar.webcom.com (8.9.1/8.9.1) with SMTP id NAA23619; Mon, 12 Jun 2000 13:54:28 -0700 Received: from [63.197.16.166] by inanna.webcom.com (WebCom SMTP 1.2.1) with SMTP id 2605521; Mon Jun 12 13:52 PDT 2000 Message-Id: <4.3.1.2.20000612135220.00d086a0@pop.webcom.com> X-Sender: aaddict@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 12 Jun 2000 13:54:24 -0700 To: Mark Crispin , IMAP Interest List , IMAP Extensions WG From: Pete Maclean Subject: Re: LAST CALL: I-D ACTION:draft-crispin-imap-multiappend-01.txt (fwd) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Maybe I am missing something simple and obvious but it is not clear to me how the client indicates the end of a batch to the server. Pete Maclean At 09:29 AM 6/12/2000 -0700, Mark Crispin wrote: >I wish to issue a LAST CALL on the MULTIAPPEND specification. MULTIAPPEND >is implemented in both UW imapd and Cyrus imapd. It will also be used in >the next version of Pine and imap-utils. > >---------- Forwarded message ---------- >Date: Mon, 12 Jun 2000 06:42:55 -0400 >From: Internet-Drafts@ietf.org >To: IETF-Announce: ; >Subject: I-D ACTION:draft-crispin-imap-multiappend-01.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND > EXTENSION > Author(s) : M. Crispin > Filename : draft-crispin-imap-multiappend-01.txt > Pages : 6 > Date : 09-Jun-00 > >This document describes the multiappending extension to the [IMAP] >protocol. This extension provides substantial performance >improvements for IMAP clients which upload multiple messages at a >time to a mailbox on the server. >A server which supports this extension indicates this with a >capability name of 'MULTIAPPEND'. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-crispin-imap-multiappend-01.txt > >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-crispin-imap-multiappend-01.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-crispin-imap-multiappend-01.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-Draf > Received: by ns.secondary.com (8.9.3/8.9.3) id MAA14197 for ietf-imapext-bks; Mon, 12 Jun 2000 12:50:41 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (tarigan@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14188 for ; Mon, 12 Jun 2000 12:50:36 -0700 (PDT) Date: Mon, 12 Jun 2000 12:18:25 -0700 (PDT) From: Mark Crispin Subject: RE: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) To: "Rubinstein, Dmitry" cc: IMAP Extensions WG In-Reply-To: <479518ED4F21D411B46D0030480035BC2FFEF5@unity-mail.icomverse.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 Mon, 12 Jun 2000 22:03:21 +0300, Rubinstein, Dmitry wrote: > As I did about a year ago, when this draft first appeared, I'd like to > object to the way the subject is extracted. I think that you missed the support for the mailing list convention of mailing list name in square brackets; it is fully supported now, albeit with the unpleasant name "subj-blob". I would not be at all unhappy about using a better term than blob, as long as that term is suitable for use in the grammer (that's why I can't use the obvious phrases). I understand, and sympathize, with your objections to "re" and "fwd". Nevertheless, I content that this is the case of "perfection being the enemy of getting the job done." There is a strong expectation among Pine users, who use SORT heavily, that "the right thing" happen. The subject extraction rules are implemented by both the UW and Cyrus servers because the functionality is next to useless without them. "re:" is an internationally recognized convention. Contrary to popular rumor, it is not an abbreviation of the English word "regarding"; it is Latin ("res" as in the legal term "in re"). There are well-known problems associated with localized versions of "re:"; most notoriously the impossibility of fixing the infamous "cascading re: problem" when other tokens are used. Most software developers have accepted the alternative of using "re:" in actual messages, but localizing it for the display. "fwd" is unfortunate, but is commonly-used enough to be necessary. Received: by ns.secondary.com (8.9.3/8.9.3) id MAA14066 for ietf-imapext-bks; Mon, 12 Jun 2000 12:40:38 -0700 (PDT) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14061 for ; Mon, 12 Jun 2000 12:40:37 -0700 (PDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id PAA19959 for ; Mon, 12 Jun 2000 15:39:31 -0400 (EDT) Received: from att.com ([135.197.86.174]) by maillennium.att.com (labmail) with SMTP id <2000061219370709904600d6e>; Mon, 12 Jun 2000 19:37:07 +0000 Message-ID: <39453C32.F88090C6@att.com> Date: Mon, 12 Jun 2000 15:38:26 -0400 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.73 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Rubinstein, Dmitry" CC: IMAP Extensions WG Subject: Re: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) References: <479518ED4F21D411B46D0030480035BC2FFEF5@unity-mail.icomverse.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: There is most definitely a standard for reply subjects. Mailers should be using Re:, from the latin word 'res', for replies - there is no further "localization" necessary; this is even mentioned in rfc822bis. The lack of a recommended standard for forwarded messages is unfortunate. This doesn't mean that we can't also pick the prevailing practice and codifing it. The use of [ml] is a fairly recent practice and is anything but universal, but I don't have a problem with adding support for it. Handling 98% of the cases is better than none. Tony Hansen tony@att.com "Rubinstein, Dmitry" wrote: > > As I did about a year ago, when this draft first appeared, I'd like to > object to the way the subject is extracted. I beleive there was no > convincing counterargument then, so here it goes again. > > There are no provisions whatsoever to localized mailers that use > anything but the "re" and "fwd?" prefixes. The ones I know of (russian and > german) are quite popular in the respective locations. Also, there is no > mentioning of the de-facto standard for mailing-lists e-mails (a subject > starting with the name of the ml in a square brackets). > > I suggest to drop the topic of subject extraction until there is a > standard for response/forward subject (or any other way to learn the > original subject). The rules presented in the draft seem to be an arbitrary > choice (even though I understand that they probably are good for the > majority of the mailers/users). > > -- > Dmitry Rubinstein > > > -----Original Message----- > > From: Mark Crispin [mailto:mrc@cac.washington.edu] > > Sent: Monday, June 12, 2000 7:33 PM > > To: IMAP Extensions WG > > Subject: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) > > > > > > This is a close to final version of the SORT specification. > > This is the > > non-extended form of SORT; work hasn't really started on the > > extended form > > and can't until the non-extended form is done and out of the way. > > > > The changes are to the descriptions of some of the SORT > > criteria, and to > > the subject extraction rules. There are a few more tweaks > > yet to be made > > to the subject extraction rules, most notably support for > > Netscape-style > > "[Fwd: ...]". Received: by ns.secondary.com (8.9.3/8.9.3) id MAA13545 for ietf-imapext-bks; Mon, 12 Jun 2000 12:08:40 -0700 (PDT) Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13541 for ; Mon, 12 Jun 2000 12:08:37 -0700 (PDT) Received: from ismailout.icomverse.com (Efrat-FR3.ser.netvision.net.il [199.203.174.65]) by alpha.netvision.net.il (8.9.3/8.8.6) with ESMTP id WAA15899 for ; Mon, 12 Jun 2000 22:06:56 +0300 (IDT) Received: from unity-mail.icomverse.com (unity-mail.icomverse.com [89.119.41.3]) by ismailout.icomverse.com (8.10.1/8.10.1) with ESMTP id e5CK3G813641 for ; Mon, 12 Jun 2000 23:03:21 +0300 Received: by unity-mail.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 22:03:22 +0300 Message-ID: <479518ED4F21D411B46D0030480035BC2FFEF5@unity-mail.icomverse.com> From: "Rubinstein, Dmitry" To: IMAP Extensions WG Subject: RE: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) Date: Mon, 12 Jun 2000 22:03:21 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1251" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As I did about a year ago, when this draft first appeared, I'd like to object to the way the subject is extracted. I beleive there was no convincing counterargument then, so here it goes again. There are no provisions whatsoever to localized mailers that use anything but the "re" and "fwd?" prefixes. The ones I know of (russian and german) are quite popular in the respective locations. Also, there is no mentioning of the de-facto standard for mailing-lists e-mails (a subject starting with the name of the ml in a square brackets). I suggest to drop the topic of subject extraction until there is a standard for response/forward subject (or any other way to learn the original subject). The rules presented in the draft seem to be an arbitrary choice (even though I understand that they probably are good for the majority of the mailers/users). -- Dmitry Rubinstein > -----Original Message----- > From: Mark Crispin [mailto:mrc@cac.washington.edu] > Sent: Monday, June 12, 2000 7:33 PM > To: IMAP Extensions WG > Subject: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) > > > This is a close to final version of the SORT specification. > This is the > non-extended form of SORT; work hasn't really started on the > extended form > and can't until the non-extended form is done and out of the way. > > The changes are to the descriptions of some of the SORT > criteria, and to > the subject extraction rules. There are a few more tweaks > yet to be made > to the subject extraction rules, most notably support for > Netscape-style > "[Fwd: ...]". Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12471 for ietf-imapext-bks; Mon, 12 Jun 2000 10:59:20 -0700 (PDT) Received: from exchange2.activevoice.com (sea-gateway1.activevoice.com [198.207.218.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12467 for ; Mon, 12 Jun 2000 10:59:19 -0700 (PDT) Received: by exchange2.activevoice.com with Internet Mail Service (5.5.2448.0) id ; Mon, 12 Jun 2000 10:58:39 -0700 Message-ID: <61B452CEA1F9D11195A600A024C65C6902814FCE@exchange2.activevoice.com> From: Rohit Sehgal To: IMAP Interest List , IMAP Extensions WG Subject: IMAP Voice Extensions Date: Mon, 12 Jun 2000 10:58:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Some time back I saw draft for "IMAP Voice Extensions". Does any body know if it was approved or abandoned. On IMAP.org it says that draft is expired. thanks Rohit Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA08518 for ietf-imapext-bks; Mon, 12 Jun 2000 09:33:25 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (wwoodf@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08514 for ; Mon, 12 Jun 2000 09:33:24 -0700 (PDT) Date: Mon, 12 Jun 2000 09:32:48 -0700 (PDT) From: Mark Crispin To: IMAP Extensions WG Subject: I-D ACTION:draft-ietf-imapext-sort-02.txt (fwd) Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: This is a close to final version of the SORT specification. This is the non-extended form of SORT; work hasn't really started on the extended form and can't until the non-extended form is done and out of the way. The changes are to the descriptions of some of the SORT criteria, and to the subject extraction rules. There are a few more tweaks yet to be made to the subject extraction rules, most notably support for Netscape-style "[Fwd: ...]". ---------- Forwarded message ---------- Date: Mon, 12 Jun 2000 06:43:34 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: ietf-imapext@imc.org Subject: I-D ACTION:draft-ietf-imapext-sort-02.txt 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 Filename : draft-ietf-imapext-sort-02.txt Pages : 10 Date : 09-Jun-00 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-02.txt 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-02.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-02.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 Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-ietf-imapext-sort-02.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA08332 for ietf-imapext-bks; Mon, 12 Jun 2000 09:29:55 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (stuart@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08327 for ; Mon, 12 Jun 2000 09:29:53 -0700 (PDT) Date: Mon, 12 Jun 2000 09:29:16 -0700 (PDT) From: Mark Crispin To: IMAP Interest List , IMAP Extensions WG Subject: LAST CALL: I-D ACTION:draft-crispin-imap-multiappend-01.txt (fwd) Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: I wish to issue a LAST CALL on the MULTIAPPEND specification. MULTIAPPEND is implemented in both UW imapd and Cyrus imapd. It will also be used in the next version of Pine and imap-utils. ---------- Forwarded message ---------- Date: Mon, 12 Jun 2000 06:42:55 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-crispin-imap-multiappend-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION Author(s) : M. Crispin Filename : draft-crispin-imap-multiappend-01.txt Pages : 6 Date : 09-Jun-00 This document describes the multiappending extension to the [IMAP] protocol. This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of 'MULTIAPPEND'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imap-multiappend-01.txt 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-crispin-imap-multiappend-01.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-crispin-imap-multiappend-01.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 Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-crispin-imap-multiappend-01.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id DAA00533 for ietf-imapext-bks; Mon, 12 Jun 2000 03:44:13 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00529 for ; Mon, 12 Jun 2000 03:44: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 GAA27775; Mon, 12 Jun 2000 06:43:34 -0400 (EDT) Message-Id: <200006121043.GAA27775@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-02.txt Date: Mon, 12 Jun 2000 06:43:34 -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 Filename : draft-ietf-imapext-sort-02.txt Pages : 10 Date : 09-Jun-00 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-02.txt 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-02.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-02.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: <20000609131425.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000609131425.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id JAA28707 for ietf-imapext-bks; Thu, 8 Jun 2000 09:08:44 -0700 (PDT) Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28671 for ; Thu, 8 Jun 2000 09:08:40 -0700 (PDT) From: zainprov@swbell.net Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00D3BFA52U@mta5.rcsntx.swbell.net> for ietf-imapext@imc.org; Thu, 8 Jun 2000 11:05:09 -0500 (CDT) Date: Thu, 08 Jun 2000 11:05:09 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: ietf-imapext@imc.org Message-id: <0FVU00DF0FCJ2U@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA13616 for ietf-imapext-bks; Tue, 6 Jun 2000 13:30:15 -0700 (PDT) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13612 for ; Tue, 6 Jun 2000 13:30:14 -0700 (PDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id NAA04605; Tue, 6 Jun 2000 13:38:31 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (smj@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id NAA25408; Tue, 6 Jun 2000 13:38:31 -0700 Date: Tue, 6 Jun 2000 12:32:35 -0700 (PDT) From: Mark Crispin Subject: re: ACL inheritance (was Re: I-D ACTION:draft-ietf-imapext-acl-00.txt) To: Chris Newman cc: ietf-imapext@imc.org In-Reply-To: <1344264.3169270113@localhost> 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, 06 Jun 2000 08:48:33 -0700, Chris Newman wrote: > > [Using "+" to indicate inheritance.] > (1) The identifier namespace for ACL is user-visible and has direct impact > on the UI. This makes it too complex. Then perhaps you would consider my alternative proposal, which is to remove inheritance and negative rights from the specification entirely. You only need negative rights if you have inheritance, and IMHO this is a rathole. > (2) I've been using AFS-style ACLs in production for over ten years and > have never seen a situation like the one Mark described. I don't know if AFS permits this or not; but AFS should not be the determinant as to what is permitted (as opposed to required) in IMAP ACLs. An existing access control mechanism used for mail offers it; IMAP ACLs should have a means to express it. > (3) The situation Mark postulates can also be addressed by using a more > sophisticated group management system. Right now, IMAP ACLs don't have any group management system, and what we're talking about is something that prohibits a group management system that already exists. Instead of adding complexity, we should be deleting it if it's breaking something that's already there. > (4) I'm aware of two widely deployed ACL systems that can be considered > successful -- AFS-style and NT-style. > There is also one ACL system > which can be considered a failure -- the Posix ACL system. Others come to mind: VMS, MULTICS, TOPS-10 FILDAE. However, the danger in applying lessons from other environments is that it can lead you to incorrect conclusions. > Although Mark's recommendation doesn't include the full > complexity of Posix ACLs, it's clearly moving in that direction. I don't see how that follows. The primary aspects of my proposal are: 1) deleting inheritance and negative rights; all identifiers have independent rights. This is a simplification. 2) a definition of groups (which is lacking now) and allowing groups to include other groups. This is basically a simple macro mechanism. 3) an optional definition of a few conventions to say "if you are going to do the thing called `owner' on UNIX, call it such-and-such." This is definitely optional, and is intended solely to make the user interface more consistant. But if it causes people to be hung up on the example of POSIX ACLs, then I'll drop it. > (5) The operational experience I've had with AFS-style ACLs and 2086 style > ACLs with inheritance suggests that not only is mandatory inheritance a > good idea, but it's intuitive to end-users. I don't know enough about AFS to comment intelligently, but RFC 2086 does not provide any mechanism for groups. Groups are what cause the problem with inheritance. How is it intuitive for fred, who has explicit "lr" rights, not to be able to select a mailbox because some group that fred is in has negative "lr" rights? > (6) When I explicitly deny someone or some group rights to a given mailbox, > it is almost always for security reasons (indeed I can't think of an > exception at the moment). So I consider it an important security feature > that negative rights overide everything else with no exceptions. Otherwise > an administrator might not realize there was some other entry in some > random ACL which might create an unintended exception to his security > policy. This isn't "some random ACL". It is one of the identifier/rights pairs in the ACL that the administrator is overriding. With inheritance and negative rights, the interactions are somewhat magical once groups are in the picture. fred may be listed as having certain rights, but he actually doesn't because of some group; and to make things worse fred gains or loses those rights by an event (group membership manipulation) that happens completely outside of ACL. Without inheritance and negative rights, it is clear and unambiguous. If an identifier is listed as having certain rights, it has those rights; if it is not so listed, then it does not have those rights. I believe that it is much simpler and easier to document without inheritance; and once inheritance is out of the picture than negative rights are no longer necessary either. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13314 for ietf-imapext-bks; Tue, 6 Jun 2000 13:10:22 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13310 for ; Tue, 6 Jun 2000 13:10:21 -0700 (PDT) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id QAA26567; Tue, 6 Jun 2000 16:17:25 -0400 (EDT) Date: Tue, 06 Jun 2000 16:18:14 -0400 From: Cyrus Daboo To: Chris Newman , Mark Crispin cc: ietf-imapext@imc.org Subject: re: Server says "NO" (was Re: I-D ACTION:draft-ietf-imapext-acl-00.txt) Message-ID: <26530000.960322694@socrates.cyrusoft.com> In-Reply-To: <2265149.3169285487@nifty-jr.west.sun.com> X-Mailer: Mulberry/2.0.1a1 (LinuxPPC) 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 06/06/00 13:04:47 -0700 Chris Newman wrote: >> There's no way in the >> current ACL specification to list what identifiers are valid; or to >> indicate what combinations of identifiers (or identifier/rights) are >> valid. You can just find out what rights one single identifier can have, >> separate from any other context. > > I concur. As I said in a separate message, I'd like to see the > identifier namespace specified to a degree that it's possible for a > client to implement identifier completion in the UI. Actually what's more important for clients is to be able to map between identifiers and real names. I'd much rather present real names to a user rather than obscure identifiers. Plus users are going to want to add acls when they know the name of the person they want to add but not necessarily their identifier. I suspect adding some kind of identifier<->name lookup to IMAP ACL is out of scope here, but it would be nice if the server could at least return a URI indicating where the client might go to get such information (e.g. an ldap or acap server URL). -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id MAA13105 for ietf-imapext-bks; Tue, 6 Jun 2000 12:59:07 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13101 for ; Tue, 6 Jun 2000 12:59:06 -0700 (PDT) Received: from westmail1.west.sun.com ([129.153.100.31]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12483 for ; Tue, 6 Jun 2000 13:07:23 -0700 (PDT) Received: from elephant.West.Sun.COM (elephant.West.Sun.COM [129.153.12.10]) by westmail1.west.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA00183 for ; Tue, 6 Jun 2000 13:07:22 -0700 (PDT) Received: from elvira.west.sun.com (elvira [129.153.12.13]) by elephant.West.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id NAA01569 for ; Tue, 6 Jun 2000 13:05:42 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.west.sun.com by elvira.west.sun.com (PMDF V6.0-24 #43970) id <0FVR00B0117EZZ@elvira.west.sun.com> for ietf-imapext@imc.org; Tue, 06 Jun 2000 13:06:50 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by elvira.west.sun.com (PMDF V6.0-24 #43970) with ESMTPA id <0FVR0041717E19@elvira.west.sun.com>; Tue, 06 Jun 2000 13:06:50 -0700 (PDT) Date: Tue, 06 Jun 2000 13:04:47 -0700 From: Chris Newman Subject: re: Server says "NO" (was Re: I-D ACTION:draft-ietf-imapext-acl-00.txt) In-reply-to: To: Mark Crispin Cc: ietf-imapext@imc.org Message-id: <2265149.3169285487@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) 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 Tuesday, June 6, 2000 12:08 -0700 Mark Crispin wrote: > There's no way in the > current ACL specification to list what identifiers are valid; or to > indicate what combinations of identifiers (or identifier/rights) are > valid. You can just find out what rights one single identifier can have, > separate from any other context. I concur. As I said in a separate message, I'd like to see the identifier namespace specified to a degree that it's possible for a client to implement identifier completion in the UI. > These problems exist, whether or not a "replaceacl" operation also > exists. I don't think that this is a good argument against replaceacl. I wasn't arguing against replaceacl -- I was pointing out that if the server can't support an ACL with three users each with independent rights, then the client needs to know that in advance. > Nor do I think that it's feasible to cover all possible cases where the > server would say NO. At some point, you have to fall back on "server said > NO and explained why." Agreed. Sometimes protocol simplicity is more important than UI quality, but we should attempt to maximize both. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12679 for ietf-imapext-bks; Tue, 6 Jun 2000 12:24:11 -0700 (PDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12675 for ; Tue, 6 Jun 2000 12:24:10 -0700 (PDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id MAA31767; Tue, 6 Jun 2000 12:32:27 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (dhack@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id MAA14864; Tue, 6 Jun 2000 12:32:27 -0700 Date: Tue, 6 Jun 2000 12:25:15 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: Chris Newman cc: ietf-imapext@imc.org In-Reply-To: <545560.3169225616@localhost> 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 Mon, 05 Jun 2000 20:26:56 -0700, Chris Newman wrote: > We should at least attempt to come up with a common set of commands and > rights if we can with out too much complexity. Agreed. > I suspect that if we try to unify the AFS ACL inheritance/identifer > semantics and Mark's Unix-style inheritance/identifier semantics the result > will be as vague about semantics as RFC 2086 (and the IMAP mailbox > namespace). I certainly am NOT proposing "Unix-style inheritance/identifier semantics"! Please don't categorize my proposal as such. Yes, I purpose to have a general specification that is implementable with UNIX semantics, but that is something completely different. I hope that the intent for IMAP ACLs is not "AFS inheritance/identifier semantics" either. IMAP ACLs should be what makes sense for IMAP. A general specification should not preclude AFS; two wrongs don't make a right. But the fact that AFS does something in a particular way doesn't mean that it is unconditionally the only way for IMAP. Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12570 for ietf-imapext-bks; Tue, 6 Jun 2000 12:15:59 -0700 (PDT) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12566 for ; Tue, 6 Jun 2000 12:15:57 -0700 (PDT) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id MAA24584; Tue, 6 Jun 2000 12:24:14 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (yfong@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id MAA32654; Tue, 6 Jun 2000 12:24:13 -0700 Date: Tue, 6 Jun 2000 12:08:49 -0700 (PDT) From: Mark Crispin Subject: re: Server says "NO" (was Re: I-D ACTION:draft-ietf-imapext-acl-00.txt) To: Chris Newman cc: ietf-imapext@imc.org In-Reply-To: <575400.3169226112@localhost> 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 would be willing to conceed this point, except for one problem: the current ACL specification has the same deficiency. There's no way in the current ACL specification to list what identifiers are valid; or to indicate what combinations of identifiers (or identifier/rights) are valid. You can just find out what rights one single identifier can have, separate from any other context. These problems exist, whether or not a "replaceacl" operation also exists. I don't think that this is a good argument against replaceacl. Nor do I think that it's feasible to cover all possible cases where the server would say NO. At some point, you have to fall back on "server said NO and explained why." On Mon, 05 Jun 2000 20:35:12 -0700, Chris Newman wrote: > > The server can always say NO to any client request. Isn't that > > sufficient? > > In general, that's not sufficient. In order to present a high quality UI, > the client also needs to know in advance if a particular request will > always fail with a particular server implementation. > > For example, if a "replaceacl" operation listing different rights for three > different users will always fail with a particular server implementation, > then the client needs to know in advance so it can constain user input so > the user won't be able to ask for something the server will never grant. Received: by ns.secondary.com (8.9.3/8.9.3) id IAA05965 for ietf-imapext-bks; Tue, 6 Jun 2000 08:49:59 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05961 for ; Tue, 6 Jun 2000 08:49:58 -0700 (PDT) Received: from westmail1.west.sun.com ([129.153.100.31]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13384 for ; Tue, 6 Jun 2000 08:58:14 -0700 (PDT) Received: from elephant.West.Sun.COM (elephant.West.Sun.COM [129.153.12.10]) by westmail1.west.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA22633 for ; Tue, 6 Jun 2000 08:58:13 -0700 (PDT) Received: from elvira.west.sun.com (elvira [129.153.12.13]) by elephant.West.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id IAA27349 for ; Tue, 6 Jun 2000 08:56:30 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.west.sun.com by elvira.west.sun.com (PMDF V6.0-24 #43970) id <0FVQ00901PO275@elvira.west.sun.com> for ietf-imapext@imc.org; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by elvira.west.sun.com (PMDF V6.0-24 #43970) with ESMTPA id <0FVQ0040FPNX19@elvira.west.sun.com> for ietf-imapext@imc.org; Tue, 06 Jun 2000 08:57:37 -0700 (PDT) Date: Mon, 05 Jun 2000 20:26:56 -0700 From: Chris Newman Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt In-reply-to: <392EBA1A.91074F4F@netscape.com> To: ietf-imapext@imc.org Message-id: <545560.3169225616@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) 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 Friday, May 26, 2000 10:53 -0700 John Gardiner Myers wrote: > After much thought, confirmed by discussion at Adelaide, I've concluded > that Mark's concerns are best addressed by his pursuing a separate > extension. The models of access control are sufficiently different that > an extension trying to address both (or all) models will necessarily be > over complex and difficult to implement on the client side. > > Better each model have its own extension. Then the client will know > which world the server is in and will not have to deal with hybrid > models that don't exist in practice. We should at least attempt to come up with a common set of commands and rights if we can with out too much complexity. I suspect that if we try to unify the AFS ACL inheritance/identifer semantics and Mark's Unix-style inheritance/identifier semantics the result will be as vague about semantics as RFC 2086 (and the IMAP mailbox namespace). In that case, having different IMAP extensions for the different semantics would be a preferable idea in my book. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id IAA05931 for ietf-imapext-bks; Tue, 6 Jun 2000 08:49:42 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05924 for ; Tue, 6 Jun 2000 08:49:40 -0700 (PDT) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13174 for ; Tue, 6 Jun 2000 08:57:55 -0700 (PDT) Received: from elephant.West.Sun.COM (elephant.West.Sun.COM [129.153.12.10]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA28006 for ; Tue, 6 Jun 2000 08:57:55 -0700 (PDT) Received: from elvira.west.sun.com (elvira [129.153.12.13]) by elephant.West.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id IAA27352 for ; Tue, 6 Jun 2000 08:56:30 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.west.sun.com by elvira.west.sun.com (PMDF V6.0-24 #43970) id <0FVQ00901PO276@elvira.west.sun.com> for ietf-imapext@imc.org; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by elvira.west.sun.com (PMDF V6.0-24 #43970) with ESMTPA id <0FVQ0040FPNX19@elvira.west.sun.com>; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Date: Mon, 05 Jun 2000 20:35:12 -0700 From: Chris Newman Subject: Server says "NO" (was Re: I-D ACTION:draft-ietf-imapext-acl-00.txt) In-reply-to: To: Mark Crispin Cc: ietf-imapext@imc.org Message-id: <575400.3169226112@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) 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 Friday, June 2, 2000 16:05 -0700 Mark Crispin wrote: > The server can always say NO to any client request. Isn't that > sufficient? In general, that's not sufficient. In order to present a high quality UI, the client also needs to know in advance if a particular request will always fail with a particular server implementation. For example, if a "replaceacl" operation listing different rights for three different users will always fail with a particular server implementation, then the client needs to know in advance so it can constain user input so the user won't be able to ask for something the server will never grant. - Chris Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA05936 for ietf-imapext-bks; Tue, 6 Jun 2000 08:49:42 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05932 for ; Tue, 6 Jun 2000 08:49:41 -0700 (PDT) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13189 for ; Tue, 6 Jun 2000 08:57:57 -0700 (PDT) Received: from elephant.West.Sun.COM (elephant.West.Sun.COM [129.153.12.10]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA28015 for ; Tue, 6 Jun 2000 08:57:56 -0700 (PDT) Received: from elvira.west.sun.com (elvira [129.153.12.13]) by elephant.West.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id IAA27368 for ; Tue, 6 Jun 2000 08:56:31 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.west.sun.com by elvira.west.sun.com (PMDF V6.0-24 #43970) id <0FVQ00901PO27A@elvira.west.sun.com> for ietf-imapext@imc.org; Tue, 06 Jun 2000 08:57:39 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by elvira.west.sun.com (PMDF V6.0-24 #43970) with ESMTPA id <0FVQ0040FPNX19@elvira.west.sun.com>; Tue, 06 Jun 2000 08:57:38 -0700 (PDT) Date: Tue, 06 Jun 2000 08:48:33 -0700 From: Chris Newman Subject: ACL inheritance (was Re: I-D ACTION:draft-ietf-imapext-acl-00.txt) To: Mark Crispin Cc: ietf-imapext@imc.org Message-id: <1344264.3169270113@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) Content-type: text/plain; charset=us-ascii; format=flowed; 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, May 25, 2000 19:46 -0700 Mark Crispin wrote: > PROBLEM: Unlike RFC 2086, this new draft requires rights inheritance; > that is, an identifier automatically has the rights of "anyone" unless > these are specifically denied as negative rights. RFC 2086 allowed > implementations to decide if rights were inherited or not. > > Although removing the ambiguity is a good idea, I question whether it's > really such a good idea to insist upon inheritance. In particular, the > inheritance of negative rights is problematic. > > RECOMMENDATION: The draft should be modified to indicate whether or not an > identifier has inheritance semantics. I suggest using + for this > purpose. In other words: > +anyone lr > means that all users can list and read the mailbox unless specifically > denied by a - identifier, whereas: > anyone lr > means that all users who aren't otherwise listed by an identifier can > read and list the mailbox. Also, + and - can be combined to cause > negative rights inheritance. I am strongly opposed to this recommendation for the following reasons: (1) The identifier namespace for ACL is user-visible and has direct impact on the UI. This makes it too complex. Were I writing a GUI client, I'd stick "+" on every identifier, because I can't think of any way to express the semantics of an optional "+" to an end user in a GUI. (2) I've been using AFS-style ACLs in production for over ten years and have never seen a situation like the one Mark described. This is an uncommon borderline case at best. (3) The situation Mark postulates can also be addressed by using a more sophisticated group management system. If I can construct a new group that consists of the original group and an exceptions list, that solves the problem without complicating the end-user ACL GUI. (4) I'm aware of two widely deployed ACL systems that can be considered successful -- AFS-style and NT-style. I'm unsure of the field experience with NT-style ACLs. I am sure of the field experience with AFS ACLs -- it's a very successful system, and the inheritance model John proposes comes directly from that successful system. There is also one ACL system which can be considered a failure -- the Posix ACL system. It is almost always mentioned in the short list of reasons why DFS failed. The Posix ACL system was complicated enough that nobody understood it, largely because it was attempting to be backwards compatible with Unix owner/group semantics. Although Mark's recommendation doesn't include the full complexity of Posix ACLs, it's clearly moving in that direction. (5) The operational experience I've had with AFS-style ACLs and 2086 style ACLs with inheritance suggests that not only is mandatory inheritance a good idea, but it's intuitive to end-users. I've pointed other administrators at AFS and 2086 style ACLs with inheritance and I never had to explain the semantics to them -- they just understood. (6) When I explicitly deny someone or some group rights to a given mailbox, it is almost always for security reasons (indeed I can't think of an exception at the moment). So I consider it an important security feature that negative rights overide everything else with no exceptions. Otherwise an administrator might not realize there was some other entry in some random ACL which might create an unintended exception to his security policy. This is another reason why I believe (3) is the correct solution to the situation Mark postulates. - Chris Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA27127 for ietf-imapext-bks; Fri, 2 Jun 2000 16:51:25 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (stud@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA27123 for ; Fri, 2 Jun 2000 16:51:23 -0700 (PDT) Date: Fri, 2 Jun 2000 16:05:08 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: Steve Hole 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 Fri, 2 Jun 2000 14:46:27 -0600, Steve Hole wrote: > Sounds OK. The devil is in the details. I hope to keep the details as minimal as possible. :) > I think that it is very important that the definition of an identifier can > orginate "out-of-band" of IMAP itself, and have an ACL extended client be > able to get that information. "Out-of-band" definition of identifiers > will be the situation for server implementors in the case of a mapping to > other identifier sources. It must be possible for a server do reject > definition of an identifier if it is not "authoritative" for the > identifier namespace. I'm not sure what you mean by this. Could you give an example? My idea is a relatively simple "macro" type mechanism, where an identifier can expand to other identifiers; and certain semantics to indicate whether this "macro" identifier is global, per-mailbox, or possibly per-user. The server can always say NO to any client request. Isn't that sufficient? > Do you have some text (even outline) that specs this so that we can see > what it would look like? I have an outline. I'm not sure that it makes sense to anyone other than me as it stands now. > You can emulate the "change owner" and "change group" by > changing what we would call the "default" ACL set on an entry. It is > not something that we allow in our server (it doesn't really make sense), > but you could do it and that is all that is needed. "Change owner" is probably not something that would normally be done in any case. But "change group" would be done by changing the definition of a certain per-mailbox macro identifier (as opposed to deleting the existing ACL and creating a new one) which on UNIX would be defined as a global macro identifier. For example, suppose $M$group is a per-mailbox identifier meaning "group access for this mailbox". It's defined as $G$cs123, a global identifier which happens to be the UNIX "cs123" group. We can change the definition of $M$group to be $G$cs432 without changing the rights of $M$group. Nor do we ever need to enumerate the membership of $G$cs123 or $G$cs432. Any of these things can be defined, but it's up to the server whether or not a user is allowed to alter the definition (or create) of any identifier. > > I also don't think that it's necessary for the specification to enshrine > > "owner" or "group" in the UNIX sense, but perhaps it may be good to > > document a particular convention for per-mailbox nomenclature of defined > > identifiers of these two. > Hmm ... I'm having trouble parsing this. Do you mean that we should > defiine a convention for representing these concepts based on the generic > model? That would involve some description on the semantics of rights > calculation as well would it not? Sorry for being dense, but I'm not > sure that I'm getting what you want to say here. No, all I mean is something like "if you have something like UNIX mailbox owner, you should call it $M$owner; if you have something like single group access, you should call it $M$group". That way, multiple UNIX mailbox implementations would use the same names. It's just a convention. But absolutely, we don't want to enshrine the UNIX semantics. As far as IMAP is concerned, these are just macro names. They have no magical properties. It's like the "#news." namespace. We all know what it means, but nothing in IMAP says that it means that. As far as IMAP is concerned, it's just a name. > Where I always run into trouble is trying to map the semantics of rights > calculations for an "owner" and "group" IFF you allow negative rights. Exactly. Negative rights imply inheritance. I'd rather not have inheritance at all, and instead say that the first applicable identifier is the one that is used. IMHO, inheritance is a rathole, and we'd be better off without it. Although the absence of inheritance does create certain limitations if a user is a member of multiple groups with different access levels, the result is nonetheless much better than the current definition. Plus, it's much simpler without negative rights and inheritance. If we must have inheritance, then the existing mechanism isn't good enough. It needs to be much more complex. There needs to be inheritance levels to control how negative rights are inherited; a positive right from a higher level overrides a negative right from a lower level. There's probably other considerations that I've overlooked. My mind boggles just thinking about it. > Am I correct that you are suggesting that a server would disallow setting > negative rights if it is mapping to the UNIX "owner" and "group" models? > In other words, just setting things that don't map to the underlying > access control model? If so, then that seems OK to me. Well, not quite. If there's mandatory inheritance (as proposed by the draft), then it is desirable to have negative rights to group. The problem is that those negative rights would then inherit to owner if owner is a member of the group. I want owner's rights to override group. Consider the behavior of the 604 protection code on UNIX. For a non-UNIX example, consider cs123-teacher rwipslda $cs123 -rl anyone rpl With mandatory inheritance, cs123-teacher can't lookup or read the mailbox because he's in $cs123. I don't think that's right. > Why is excluding anonymous the normal case? If I create a "wide open" > ACL for "everyone", why wouldn't I include anonymous in that? My sample of site administrators indicates that they differentiate between anonymous access and authorized user access. This is certainly the case on FTP servers. As a user, I would think twice about making my data world-accessible if I knew that anonymous could get at it as opposed to the other authorized users of the system. In my server, I have the #shared/ namespace which is not permitted to anonymous vs. the #public/ namespace which is permitted to anonymous. > I can see an exmaple where a server might want to partition a namespace by > domain, and then provide anonymous access within a domain. That means that a user in another domain can't grant anonymous access; he would have to copy/move the data to the domain which has anonymous access. Having a global right which means "everybody except anonymous" doesn't preclude doing this. It just makes it unnecessary unless you want to do it that way. Received: by ns.secondary.com (8.9.3/8.9.3) id QAA27025 for ietf-imapext-bks; Fri, 2 Jun 2000 16:35:13 -0700 (PDT) Received: from mail.mirapoint.com (IDENT:mirapoint@mail.mirapoint.com [208.48.74.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA27020 for ; Fri, 2 Jun 2000 16:35:09 -0700 (PDT) Received: from tim-bsd.mirapoint.com (tim-bsd.mirapoint.com [192.168.0.117]) by mail.mirapoint.com (Mirapoint) with SMTP id AAC54817; Fri, 2 Jun 2000 16:43:03 -0700 (PDT) X-Spook: Ft. Knox Ft. Meade militia ammunition COSCO Qaddafi FBI To: Steve Hole Cc: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt References: From: Tim Showalter Date: 02 Jun 2000 16:47:10 -0700 In-Reply-To: Steve Hole's message of "Fri, 2 Jun 2000 15:01:09 -0600" Message-ID: <7dvgzrodc1.fsf@tim-bsd.mirapoint.com> Lines: 12 User-Agent: Gnus/5.0806 (Gnus v5.8.6) XEmacs/21.1 (Canyonlands) 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: Steve Hole writes: > The problem will be with old clients that expect "c" to give you "create" > and "delete" mailbox rights. Is it important? Cyrus (and presumably all of its derivatives at some point) assigned that permission to the `d' bit. FWIW, I also prefer adding a new bit. Overloading anything seems gross to me. Tim Received: by ns.secondary.com (8.9.3/8.9.3) id NAA25423 for ietf-imapext-bks; Fri, 2 Jun 2000 13:53:31 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA25418 for ; Fri, 2 Jun 2000 13:53:30 -0700 (PDT) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e52L1FJ17918; Fri, 2 Jun 2000 15:01:15 -0600 From: Steve Hole Date: Fri, 2 Jun 2000 15:01:09 -0600 To: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Cc: John Gardiner Myers , ietf-imapext@imc.org In-Reply-To: References: Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) 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, 31 May 2000 16:04:50 -0700 (PDT) Mark Crispin wrote: > On Mon, 29 May 2000, Steve Hole wrote: > > (1) The interpretation of various rights identifiers. > > (2) The definition/management of identifiers. > > (3) Rights inheritance. > > I think that this is a good summary. Add a fourth issue: > > (4) Structure of ACL commands and (especially) responses. > > This relates to things such as issuing automatic ACL responses at SELECT > time; the ability to have wildcards in mailbox names; the ability to > replace the entire ACL and/or redefine ACL for multiple identifiers; the > ability to query potential rights for multiple identifiers. Sounds good. I would propose a simple table of "what is there now" vs a "what we propose to have". That way we can compare the value of each and get a nice "deprecate" and "add" set to work with after we have debated the differences. I think that we want to put aside the things that are OK and get to the differences. > > We have had trouble with (1) > > ourselves and I think that it should be fairly easy to come to concensus > > on. > > I hope so. Since rights tying exists, it would be better to add a new > right rather than to overload existing rights with semantics that may not > necessarily make sense to tie together. I'm thinking here about the "c" > right, which should not be overloaded with "delete mailbox". I pretty much agree with this. From a server standpoint, it is easy enough to do. The problem will be with old clients that expect "c" to give you "create" and "delete" mailbox rights. Is it important? The other thing to remember is that I don't think there are that many clients that have implemented ACL support yet. This being the case, it may not be that big a deal to change the semantics. In fact, I think now is the time take the pain to do this based on what the few implementations have learned. As one such implementor, I would support this. Once again, I would propose a table comparing the existing rights to the proposed new rights. That way we can get to the differences right away. Any possibility that you could put something like that together Mark? Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA25258 for ietf-imapext-bks; Fri, 2 Jun 2000 13:38:42 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA25254 for ; Fri, 2 Jun 2000 13:38:40 -0700 (PDT) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e52KkaJ17734; Fri, 2 Jun 2000 14:46:36 -0600 From: Steve Hole Date: Fri, 2 Jun 2000 14:46:27 -0600 To: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Cc: ietf-imapext@imc.org In-Reply-To: References: Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) 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, 31 May 2000 16:37:57 -0700 (PDT) Mark Crispin wrote: > On Mon, 29 May 2000, Steve Hole wrote: > By general, I mean "a mechanism whose ideal state is full implementation" > as opposed to "flexible" which means "a mechanism which expresses > contradictory models, and therefore would never be fully implemented." > > Hierarchy is "flexible"; what I propose for identifiers is "general". Exactly. This sounds like a good definition to me. > My idea basically boils down to this: > 1) a mechanism to define identifiers: global, per-mailbox, and perhaps > also per-user (I don't need the last one, but perhaps other people > do). Defined identifiers can be defined in terms of other > defined identifiers. > 2) a system of naming that makes the type of identifier unambiguous. > 3) a mechanism to look up (expands) the definition of a defined > identifier. > > The impact of this is: > . definition of identifier nomenclature > . command to define an identifier > . command to get the definition of an identifier Sounds OK. The devil is in the details. I think that it is very important that the definition of an identifier can orginate "out-of-band" of IMAP itself, and have an ACL extended client be able to get that information. "Out-of-band" definition of identifiers will be the situation for server implementors in the case of a mapping to other identifier sources. It must be possible for a server do reject definition of an identifier if it is not "authoritative" for the identifier namespace. Tricky. Do you have some text (even outline) that specs this so that we can see what it would look like? > Note that there is no specific "change group" or "change owner"; however, > the necessary functionality is there. The semantics of other existing ACL > mechanisms can be done the same way. I think so too. You can emulate the "change owner" and "change group" by changing what we would call the "default" ACL set on an entry. It is not something that we allow in our server (it doesn't really make sense), but you could do it and that is all that is needed. Assuming convergence on identifier definition, you should be able to do this using the existing model. > I also don't think that it's necessary for the specification to enshrine > "owner" or "group" in the UNIX sense, but perhaps it may be good to > document a particular convention for per-mailbox nomenclature of defined > identifiers of these two. Hmm ... I'm having trouble parsing this. Do you mean that we should defiine a convention for representing these concepts based on the generic model? That would involve some description on the semantics of rights calculation as well would it not? Sorry for being dense, but I'm not sure that I'm getting what you want to say here. > At the specification level, all that should matter is that these > per-mailbox identifiers have ACLs; the per-mailbox identifier that > corresponds to UNIX owner expands to one or more RFC 2086 user name > identifiers, and the per-mailbox identifier that corresponds to UNIX group > expands to a global defined identifier (which in turn expands to one or > more RFC 2086 user name identifiers). > > Of course, the server is always permitted to respond NO to an operation > which it does not agree to do. The semantics of group permissions and membership and the semantics of "owner" permissions are fairly straightforward in isolation. Where I always run into trouble is trying to map the semantics of rights calculations for an "owner" and "group" IFF you allow negative rights. Am I correct that you are suggesting that a server would disallow setting negative rights if it is mapping to the UNIX "owner" and "group" models? In other words, just setting things that don't map to the underlying access control model? If so, then that seems OK to me. > A separate issue is the lack of an identifier that includes everybody > except for anonymous. Since excluding anonymous is the normal case, it > doesn't really work well to have negative rights for anonymous on all > ACLs. Why is excluding anonymous the normal case? If I create a "wide open" ACL for "everyone", why wouldn't I include anonymous in that? I can see an exmaple where a server might want to partition a namespace by domain, and then provide anonymous access within a domain. If the namespace is not truly separate (separated at the root), then you would want "everyone" to map to "everyone in this" domain, and that would not include anonymous. That's about the best example that I can think of, and I would address something like that differently (as we did in our server). > > It was collosal mistake to > > select in favour of the "what the server is able to express" model for > > hierarchy and we should not make the same mistake for ACL identifiers. > > I don't think that the example of hierarchy really applies here. In > hierarchy, two models which were fundamentally hostile to each other were > shoehorned together. In this case, we're talking about extensions to the > existing framework that everybody can implement, and probably would want > to implement. OK. My goal was to make sure that we didn't try to engineer a compromise between incompatible semantic models and it looks like we have concensus on that. I'm happy. We will want to monitor our design from time to time to make sure that we don't run off that road at some point. Treat this a basic design requirement. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA22446 for ietf-imapext-bks; Fri, 2 Jun 2000 10:15:47 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22440 for ; Fri, 2 Jun 2000 10:15:45 -0700 (PDT) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e52HNSJ15903; Fri, 2 Jun 2000 11:23:28 -0600 From: Steve Hole Date: Fri, 2 Jun 2000 11:23:23 -0600 To: David Harris Subject: Re: QUIET option for FETCH Cc: imap@u.washington.edu, ietf-imapext@imc.org In-Reply-To: <39363F0A.23556.2B576D7D@localhost> References: <39363F0A.23556.2B576D7D@localhost> <39352309.18265.2701E1B2@localhost> Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) 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, 1 Jun 2000 11:51:25 +1200 David Harris wrote: > I think you've misunderstood the scope of what I mean. What I want to > be able to do is reduce the bulk of the exchange with the server... I > want to be able to send this - > > A1 FETCH 1 BODY.PEEK[HEADERS ($PMSET)] > > and have the server respond with: > > * 1 FETCH BODY[HEADERS ($PMSET)] > > - but actually act as though I had sent it my list of required headers. > > This is, in fact, exactly how I've done it in Mercury/Pegasus Mail. I've > declared an X- extension via CAPABILITY that tells Pegasus Mail it > can use a new MACRO command at the start of the session to create > a macro for the list of headers it wants. This macro can then be used > in a FETCH command. In my case, this saves something like 350 > completely superfluous bytes per header fetch. I felt this would be a > generally useful addition, since header fetching is something that most > mail clients will need to do extensively. What smoking idea! I love this. David, you have renewed my opinion that you are chap with a head on his shoulders. I see no reason why this should be restricted to header sets. It would be very nice to make it a general feature for any set of commands. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 Received: by ns.secondary.com (8.9.3/8.9.3) id QAA10377 for ietf-imapext-bks; Thu, 1 Jun 2000 16:12:14 -0700 (PDT) Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.2.83]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA10373 for ; Thu, 1 Jun 2000 16:12:13 -0700 (PDT) Received: from [207.87.51.142] (vpnap-g1-012016.qualcomm.com [10.13.12.16]) by illyana.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id QAA28194 for ; Thu, 1 Jun 2000 16:20:05 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: QUALCOMM Eudora v4.3 for Macintosh Date: Thu, 1 Jun 2000 16:20:02 -0700 To: ietf-imapext@imc.org From: Randall Gellens Subject: Single-letter codes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > alphabet soup of one letter codes. I think it would be more clear if the rights were longer than single-letters, and less likely to be confused with Unix or other rights. But 2086 already defined them that way. It also means bundling would need another method, perhaps "-", as in "list-adm read seen-write-ins-create-del" instead of "la r swicd"