Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67CQwqt062462 for ; Mon, 7 Jul 2003 05:26:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h67CQwrL062461 for ietf-imapext-bks; Mon, 7 Jul 2003 05:26:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (lampin@panda.com [206.124.149.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67CQuqt062455 for ; Mon, 7 Jul 2003 05:26:57 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id FAA11689; Mon, 7 Jul 2003 05:26:50 -0700 (PDT) Date: Mon, 7 Jul 2003 05:26:49 -0700 (PDT) From: Mark Crispin To: Michael Fair cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: another question about ACL -08 In-Reply-To: <029601c34463$12cbc0e0$d1d07b43@cocacola> Message-ID: References: <3F02F518.39BE6FD@isode.com> <3F073A0E.34FE07D@isode.com> <020901c3444b$a85fea40$d1d07b43@cocacola> <029601c34463$12cbc0e0$d1d07b43@cocacola> 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, 7 Jul 2003, Michael Fair wrote: > Won't this make writing generic IMAPv4 management clients > that manipulate ACLs difficult because it has to figure > out what semantics it has... I agree that there should be some means for the client to learn the semantics in advance. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h678c7qt040649 for ; Mon, 7 Jul 2003 01:38:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h678c7AN040648 for ietf-imapext-bks; Mon, 7 Jul 2003 01:38:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h678c6qt040643 for ; Mon, 7 Jul 2003 01:38:06 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 0066581AB70; Mon, 7 Jul 2003 01:38:05 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id AAB3581AB6F; Mon, 7 Jul 2003 01:38:04 -0700 (PDT) Message-ID: <029601c34463$12cbc0e0$d1d07b43@cocacola> From: "Michael Fair" To: "Mark Crispin" Cc: "Alexey Melnikov" , "IMAP Extensions WG" References: <3F02F518.39BE6FD@isode.com> <3F073A0E.34FE07D@isode.com> <020901c3444b$a85fea40$d1d07b43@cocacola> Subject: Re: another question about ACL -08 Date: Mon, 7 Jul 2003 01:38:00 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On Sun, 6 Jul 2003, Michael Fair wrote: > > Does this mean that only one group will be allowed to have an > > entry in the ACL? Or that an individual server might opt to use those > > semantics and so ACL semantics will vary from one server to the next? > > The latter > > > If there can be more than one group or user associated in the ACL > > how do you delete/change just one of them without having to fetch the whole > > list and restore it without the intended target? > > ACL STORE and ACL DELETE act on a single identifier/rights pair. > > In a server that only allows one group, ACL STORE with a different > group identifer will replace the existing group identifer. In one which > has multiple groups, it will add a new identifier/rights pair. Thanks for the explanation. > This overloading of functionality concerns me, but apparently the > alternative is not acceptable. Won't this make writing generic IMAPv4 management clients that manipulate ACLs difficult because it has to figure out what semantics it has... Or is it just the case that any client wanting to be portable always does a DELETE then STORE regardless of server (or the most savvy clients actually trying to determine behavior based on server). -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h676tCqt022493 for ; Sun, 6 Jul 2003 23:55:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h676tCt0022491 for ietf-imapext-bks; Sun, 6 Jul 2003 23:55:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (ajohnson@panda.com [206.124.149.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h676t6qt022456 for ; Sun, 6 Jul 2003 23:55:06 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id XAA11258; Sun, 6 Jul 2003 23:54:58 -0700 (PDT) Date: Sun, 6 Jul 2003 23:54:24 -0700 (PDT) From: Mark Crispin To: Michael Fair cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: another question about ACL -08 In-Reply-To: <020901c3444b$a85fea40$d1d07b43@cocacola> Message-ID: References: <3F02F518.39BE6FD@isode.com> <3F073A0E.34FE07D@isode.com> <020901c3444b$a85fea40$d1d07b43@cocacola> 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 Sun, 6 Jul 2003, Michael Fair wrote: > Does this mean that only one group will be allowed to have an > entry in the ACL? Or that an individual server might opt to use those > semantics and so ACL semantics will vary from one server to the next? The latter > If there can be more than one group or user associated in the ACL > how do you delete/change just one of them without having to fetch the whole > list and restore it without the intended target? ACL STORE and ACL DELETE act on a single identifier/rights pair. In a server that only allows one group, ACL STORE with a different group identifer will replace the existing group identifer. In one which has multiple groups, it will add a new identifier/rights pair. This overloading of functionality concerns me, but apparently the alternative is not acceptable. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h675oZqt009553 for ; Sun, 6 Jul 2003 22:50:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h675oZhd009552 for ietf-imapext-bks; Sun, 6 Jul 2003 22:50:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h675oXqt009547 for ; Sun, 6 Jul 2003 22:50:33 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 2166F81AB70; Sun, 6 Jul 2003 22:50:35 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 8022D81AB6F; Sun, 6 Jul 2003 22:50:23 -0700 (PDT) Message-ID: <020901c3444b$a85fea40$d1d07b43@cocacola> From: "Michael Fair" To: "Alexey Melnikov" , "Mark Crispin" Cc: "IMAP Extensions WG" References: <3F02F518.39BE6FD@isode.com> <3F073A0E.34FE07D@isode.com> Subject: Re: another question about ACL -08 Date: Sun, 6 Jul 2003 22:50:22 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Mark Crispin wrote: > > > On Wed, 2 Jul 2003, Alexey Melnikov wrote: > > > > I don't see this as a significant benefit for clients (I doubt I'd ever > > > > want to 'rename' an ACL identifier) and only increases implementation > > > > complexity for ACL systems that don't use 'chgrp' or 'chown'. > > > I tend to agree. This is one of "nice to have" features and I have a list of 4-5 > > > other commands I've refused to put into the document. > > > > You still need to say explicitly that ACL STORE can do an implicit ACL > > DELETE of some other identifer/rights pair; > > I've added the text you proposed. Also the following example: > > C: B001 LIST (ACL) "" INBOX > S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") ( > "group=Devel" "rwipslt")))) > S: B001 OK List with acl info completed > C: B002 ACL STORE Inbox group=PSO rwipslte > S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") ( > "group=PSO" "rwipslte")))) > S: B002 OK Setacl complete > > > and there ought to be a way > > for the client to know that such a thing would happen in advance. > > Suggestions are welcome. > > I was thinking that this should be part of ACL model description. Does this mean that only one group will be allowed to have an entry in the ACL? Or that an individual server might opt to use those semantics and so ACL semantics will vary from one server to the next? If there can be more than one group or user associated in the ACL how do you delete/change just one of them without having to fetch the whole list and restore it without the intended target? -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h66MBoqt095513 for ; Sun, 6 Jul 2003 15:11:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h66MBorV095512 for ietf-imapext-bks; Sun, 6 Jul 2003 15:11:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h66MBjqt095504 for ; Sun, 6 Jul 2003 15:11:50 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust52.tnt29.lnd3.gbr.da.uu.net [62.188.120.52]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h66MFEV07996; Sun, 6 Jul 2003 16:15:15 -0600 Message-ID: <3F073A0E.34FE07D@isode.com> Date: Sat, 05 Jul 2003 14:50:22 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: another question about ACL -08 References: <3F02F518.39BE6FD@isode.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Wed, 2 Jul 2003, Alexey Melnikov wrote: > > > I don't see this as a significant benefit for clients (I doubt I'd ever > > > want to 'rename' an ACL identifier) and only increases implementation > > > complexity for ACL systems that don't use 'chgrp' or 'chown'. > > I tend to agree. This is one of "nice to have" features and I have a list of 4-5 > > other commands I've refused to put into the document. > > You still need to say explicitly that ACL STORE can do an implicit ACL > DELETE of some other identifer/rights pair; I've added the text you proposed. Also the following example: C: B001 LIST (ACL) "" INBOX S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") ( "group=Devel" "rwipslt")))) S: B001 OK List with acl info completed C: B002 ACL STORE Inbox group=PSO rwipslte S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") ( "group=PSO" "rwipslte")))) S: B002 OK Setacl complete > and there ought to be a way > for the client to know that such a thing would happen in advance. Suggestions are welcome. I was thinking that this should be part of ACL model description. Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62HoRFK072253 for ; Wed, 2 Jul 2003 10:50:27 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62HoRQk072252 for ietf-imapext-bks; Wed, 2 Jul 2003 10:50:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (ittai@panda.com [206.124.149.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62HoPFK072243 for ; Wed, 2 Jul 2003 10:50:26 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id KAA04129; Wed, 2 Jul 2003 10:50:19 -0700 (PDT) Date: Wed, 2 Jul 2003 10:50:18 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov cc: Rob Siemborski , IMAP Extensions WG Subject: Re: another question about ACL -08 In-Reply-To: <3F02F518.39BE6FD@isode.com> Message-ID: References: <3F02F518.39BE6FD@isode.com> 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, 2 Jul 2003, Alexey Melnikov wrote: > > I don't see this as a significant benefit for clients (I doubt I'd ever > > want to 'rename' an ACL identifier) and only increases implementation > > complexity for ACL systems that don't use 'chgrp' or 'chown'. > I tend to agree. This is one of "nice to have" features and I have a list of 4-5 > other commands I've refused to put into the document. You still need to say explicitly that ACL STORE can do an implicit ACL DELETE of some other identifer/rights pair; and there ought to be a way for the client to know that such a thing would happen in advance. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62F7EFK062014 for ; Wed, 2 Jul 2003 08:07:14 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62F7ELH062013 for ietf-imapext-bks; Wed, 2 Jul 2003 08:07:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62F7DFK062008 for ; Wed, 2 Jul 2003 08:07:14 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (82-43-138-23.cable.ubr01.newm.blueyonder.co.uk [82.43.138.23]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Wed, 2 Jul 2003 16:07:05 +0100 Message-ID: <3F02F518.39BE6FD@isode.com> Date: Wed, 02 Jul 2003 09:07:04 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: IMAP Extensions WG Subject: Re: another question about ACL -08 References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > On Tue, 1 Jul 2003, Mark Crispin wrote: > > > There should be an ACL RENAME command which will change the identifier of > > a particular identifier,rights pair while preserving the rest of the ACL. > > > > E.g., given an mailbox foo with an ACL of > > owner lrswipxtea group=devel lrs anyone "" > > the command > > ACL RENAME foo group=devel group=test > > should result in an ACL of > > owner lrswipxtea group=test lrs anyone "" > > > > This translates into a chown or chgrp in UNIX, and on other systems is a > > a simple alternative form of ACL SET. > > > > Otherwise, the "chgrp" type operation would require an ACL SET echoing > > what is already there. > > Is there a serious functionality gain here? > > I don't see this as a significant benefit for clients (I doubt I'd ever > want to 'rename' an ACL identifier) and only increases implementation > complexity for ACL systems that don't use 'chgrp' or 'chown'. I tend to agree. This is one of "nice to have" features and I have a list of 4-5 other commands I've refused to put into the document. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62ER4FK060453 for ; Wed, 2 Jul 2003 07:27:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62ER4YA060451 for ietf-imapext-bks; Wed, 2 Jul 2003 07:27:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62ER3FK060446 for ; Wed, 2 Jul 2003 07:27:03 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (82-43-138-23.cable.ubr01.newm.blueyonder.co.uk [82.43.138.23]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Wed, 2 Jul 2003 15:26:48 +0100 Message-ID: <3F02EBA7.4B11D46C@isode.com> Date: Wed, 02 Jul 2003 08:26:47 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: acl-08: questions References: <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Fri, 20 Jun 2003, Lawrence Greenfield wrote: > > . Why is there no 'anonymous' identifier in addition to 'anyone' and > > 'authuser'? > > Is there a reason that we would want anonymous to have rights different > from anyone, given that authuser now exists? No. But I think Larry suggests to add 'anonymous' as a synonym for 'anyone'. Personally, I don't care either way. 'anonymous' is an implementation specific thing for Cyrus-based servers. > The only use would be to grant anonymous rights that some authorized users > don't have. Seems silly to me. > > I also noted this text: > > [...] For example, > in an implementation that uses unix mode bits, the rights "wisd" are > tied, the "a" right is always granted to the owner of a mailbox and > is never granted to another user. > > "wisd" should be replaced with "swite". Fixed. Thanks. Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h623FlFK098419 for ; Tue, 1 Jul 2003 20:15:47 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h623FlBX098418 for ietf-imapext-bks; Tue, 1 Jul 2003 20:15:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h623FjFK098412 for ; Tue, 1 Jul 2003 20:15:45 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 9B2BB5C896A2; Wed, 2 Jul 2003 06:15:47 +0300 (EEST) Subject: Re: ACL2 rule identifiers From: Timo Sirainen To: Mark Crispin Cc: ietf-imapext@imc.org In-Reply-To: References: <1057110774.7582.828.camel@hurina> Content-Type: text/plain Message-Id: <1057115747.8172.858.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 02 Jul 2003 06:15:47 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2003-07-02 at 05:23, Mark Crispin wrote: > On Tue, 2 Jul 2003, Timo Sirainen wrote: > > Preferrably there shouldn't need to be multiple rules. Make one that > > works with all cases. > > That would be desirable, but I don't think that it is possible. If one is > implementing IMAP on a pre-existing mail store, the mail store's existing > means of access control constrains what can be done in IMAP. I think it would be possible with enough thinking. You only have to be able to describe the existing limited ACLs with the new flexible one, not the other way around. Changing the ACLs would of course need some rules what to do if underlying store has more limited ACL support. BTW. Has anyone checked how Posix filesystem ACLs work? How well would it work with current rules? > So I think that hopes for a server implementing multiple rules with > clients being able to pick and choose is a pipe-dream. More likely, the > server will dictate and the client must comply. Clients can make it easier to use different rules, but users will still need to learn how to use them. I can easily imagine all the cries when the new IMAP server works differently than old one.. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h622hQFK097418 for ; Tue, 1 Jul 2003 19:43:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h622hQQQ097417 for ietf-imapext-bks; Tue, 1 Jul 2003 19:43:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h622hPFK097411 for ; Tue, 1 Jul 2003 19:43:25 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h622hQkI025835; Tue, 1 Jul 2003 19:43:26 -0700 Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h622gJ4A026680 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Jul 2003 19:43:22 -0700 Date: Tue, 1 Jul 2003 19:41:54 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: IMAP Extensions WG Subject: Re: another question about ACL -08 In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If that is what it is intended, it should be explicitly stated in the specification. Effectively deleting an existing ACL as a side effect of storing an ACL seems to me to be stretching the definition of "modification", and unless it is explicitly stated that this is expected and acceptable behavior there are bound to be flames if a server does that. I'll drop my request for ACL RENAME if this explicit statement is added, perhaps with an example, e.g. "in some mail stores, a mailbox can be a member of only one group. Thus, doing an ACL STORE that sets a different group from what is already in the ACL may have the effect of doing an implicit ACL DELETE of the existing group's identifier/rights pair." On Tue, 1 Jul 2003, Rob Siemborski wrote: > > Either that, or allow ACL STORE with a new identifier to arbitrarily do an > > implicit ACL DELETE of some other identifier, and *document* it in the > > specification that a server may do this. > This is significantly more palatable to me, especially given this text in > the ACL STORE definition: > An ACL2 server MAY modify one or more ACL for one or more identifier > as a side effect of modifying the ACL specified in ACL STORE. If the > server does that it MUST send untagged LIST response with ACL information > (see section 5.1) to notify the client about the changes made. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h622ZHFK097243 for ; Tue, 1 Jul 2003 19:35:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h622ZHRX097242 for ietf-imapext-bks; Tue, 1 Jul 2003 19:35:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h622ZFFK097236 for ; Tue, 1 Jul 2003 19:35:16 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from BBOARD.andrew.cmu.edu (BBOARD.andrew.cmu.edu [128.2.10.89]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h622ZFuO010314; Tue, 1 Jul 2003 22:35:15 -0400 Date: Tue, 1 Jul 2003 22:35:16 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: IMAP Extensions WG Subject: Re: another question about ACL -08 In-Reply-To: Message-ID: References: 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, 1 Jul 2003, Mark Crispin wrote: > Adding ACL RENAME makes this quite a bit easier. But it seems to be functionality that already exists (see below). > Either that, or allow ACL STORE with a new identifier to arbitrarily do an > implicit ACL DELETE of some other identifier, and *document* it in the > specification that a server may do this. This is significantly more palatable to me, especially given this text in the ACL STORE definition: An ACL2 server MAY modify one or more ACL for one or more identifier as a side effect of modifying the ACL specified in ACL STORE. If the server does that it MUST send untagged LIST response with ACL information (see section 5.1) to notify the client about the changes made. Which seems to do exactly what you want here. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h622QAFK096994 for ; Tue, 1 Jul 2003 19:26:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h622QAm5096993 for ietf-imapext-bks; Tue, 1 Jul 2003 19:26:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h622Q9FK096988 for ; Tue, 1 Jul 2003 19:26:09 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h622Q22Z013202; Tue, 1 Jul 2003 19:26:07 -0700 Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h622NqXa028172 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Jul 2003 19:25:54 -0700 Date: Tue, 1 Jul 2003 19:23:44 -0700 (Pacific Daylight Time) From: Mark Crispin To: Timo Sirainen cc: ietf-imapext@imc.org Subject: Re: ACL2 rule identifiers In-Reply-To: <1057110774.7582.828.camel@hurina> Message-ID: References: <1057110774.7582.828.camel@hurina> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2 Jul 2003, Timo Sirainen wrote: > Preferrably there shouldn't need to be multiple rules. Make one that > works with all cases. That would be desirable, but I don't think that it is possible. If one is implementing IMAP on a pre-existing mail store, the mail store's existing means of access control constrains what can be done in IMAP. The whole reason we got into this mess was that RFC 2086 turned out to be unimplementable in any reasonable way with one rather important form of pre-existing mail store. "First rule wins" with no inheritance would be fine for me (and would allow the deletion of negative rights), but I don't know if it would be suitable for people from other environments (e.g. Cyrus). So I think that hopes for a server implementing multiple rules with clients being able to pick and choose is a pipe-dream. More likely, the server will dictate and the client must comply. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h621r2FK095850 for ; Tue, 1 Jul 2003 18:53:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h621r2Wt095849 for ietf-imapext-bks; Tue, 1 Jul 2003 18:53:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h621r0FK095844 for ; Tue, 1 Jul 2003 18:53:00 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id DB7205C896A2 for ; Wed, 2 Jul 2003 04:52:54 +0300 (EEST) Subject: ACL2 rule identifiers From: Timo Sirainen To: ietf-imapext@imc.org Content-Type: text/plain Message-Id: <1057110774.7582.828.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 02 Jul 2003 04:52:54 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think multiple rule identifiers are a very bad idea. Clients will most likely get some of the details wrong in rules they haven't been tested against. Servers will probably have to implement multiple rules so admin can choose his preferred one. Worst of all, they confuse users. Suppose a user has gone through all the trouble to figure out how one rule works. Then he switches to another IMAP server (another ISP) that uses different rule. He might not realize that the rule changed. He might not even know that different rules exist. So he happily uses the old way to do things, and ends up sharing mailboxes to wrong people. At the very least server should be able to advertise multiple rules and client should be able to choose which one it wants to use. Preferrably there shouldn't need to be multiple rules. Make one that works with all cases. Maybe just add ordering into the rules with first matching rule wins logic, just like firewall rules usually have. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h620URFK093327 for ; Tue, 1 Jul 2003 17:30:27 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h620UROZ093326 for ietf-imapext-bks; Tue, 1 Jul 2003 17:30:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h620UQFK093321 for ; Tue, 1 Jul 2003 17:30:26 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h620UQ6S010625; Tue, 1 Jul 2003 17:30:26 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h620UQXa025144 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Jul 2003 17:30:26 -0700 Date: Tue, 1 Jul 2003 17:30:26 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: IMAP Extensions WG Subject: Re: another question about ACL -08 In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 1 Jul 2003, Rob Siemborski wrote: > > There should be an ACL RENAME command > Is there a serious functionality gain here? Yes. chgrp is a fairly important part of the UNIX filesystem access control model, and without a way to represent it (even with ACL SET) a server using the filesystem access control model is crippled. > I don't see this as a significant benefit for clients (I doubt I'd ever > want to 'rename' an ACL identifier) and only increases implementation > complexity for ACL systems that don't use 'chgrp' or 'chown'. A mailbox has an ACL for group=sys. You want it to have group=devel isntead. One obvious means of implementation (ACL DELETE + ACL STORE) won't work, since you can't ACL STORE a new identifier or ACL DELETE an existing identifier. The only way is by ACL SET, which does quite a bit more than just the chgrp (even if it's a big no-op). How is the client supposed to know this? > > How is ACL DELETE implemented if it is not actually possible to delete an > > identifier? > In the MOST-SPECIFIC case I'd expect this to set the rights to > those of anyone. > In the UNION case I'd expect this to set the rights to"". > But I'd probably expect the server to say NO if it couldn't actually > delete the identifier. Well, I agree about saying NO to ACL DELETE and to ACL STORE that tries to add an identifier. But I don't see how the client is supposed to know how to do this. Adding ACL RENAME makes this quite a bit easier. Either that, or allow ACL STORE with a new identifier to arbitrarily do an implicit ACL DELETE of some other identifier, and *document* it in the specification that a server may do this. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62096FK092620 for ; Tue, 1 Jul 2003 17:09:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62096qK092619 for ietf-imapext-bks; Tue, 1 Jul 2003 17:09:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62095FK092613 for ; Tue, 1 Jul 2003 17:09:05 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from BBOARD.andrew.cmu.edu (BBOARD.andrew.cmu.edu [128.2.10.89]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h62097uO007170 for ; Tue, 1 Jul 2003 20:09:07 -0400 Date: Tue, 1 Jul 2003 20:09:06 -0400 (EDT) From: Rob Siemborski To: IMAP Extensions WG Subject: Re: another question about ACL -08 In-Reply-To: Message-ID: References: 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, 1 Jul 2003, Mark Crispin wrote: > There should be an ACL RENAME command which will change the identifier of > a particular identifier,rights pair while preserving the rest of the ACL. > > E.g., given an mailbox foo with an ACL of > owner lrswipxtea group=devel lrs anyone "" > the command > ACL RENAME foo group=devel group=test > should result in an ACL of > owner lrswipxtea group=test lrs anyone "" > > This translates into a chown or chgrp in UNIX, and on other systems is a > a simple alternative form of ACL SET. > > Otherwise, the "chgrp" type operation would require an ACL SET echoing > what is already there. Is there a serious functionality gain here? I don't see this as a significant benefit for clients (I doubt I'd ever want to 'rename' an ACL identifier) and only increases implementation complexity for ACL systems that don't use 'chgrp' or 'chown'. > How is ACL DELETE implemented if it is not actually possible to delete an > identifier? I'm not sure if it should set the rights to "" or to those of > anyone. In the MOST-SPECIFIC case I'd expect this to set the rights to those of anyone. In the UNION case I'd expect this to set the rights to"". But I'd probably expect the server to say NO if it couldn't actually delete the identifier. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61NY7FK091833 for ; Tue, 1 Jul 2003 16:34:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61NY7Br091832 for ietf-imapext-bks; Tue, 1 Jul 2003 16:34:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61NY6FK091827 for ; Tue, 1 Jul 2003 16:34:06 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h61NY3kI010329 for ; Tue, 1 Jul 2003 16:34:08 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h61NY24A020739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 1 Jul 2003 16:34:03 -0700 Date: Tue, 1 Jul 2003 16:34:03 -0700 (Pacific Daylight Time) From: Mark Crispin To: IMAP Extensions WG Subject: another question about ACL -08 Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There should be an ACL RENAME command which will change the identifier of a particular identifier,rights pair while preserving the rest of the ACL. E.g., given an mailbox foo with an ACL of owner lrswipxtea group=devel lrs anyone "" the command ACL RENAME foo group=devel group=test should result in an ACL of owner lrswipxtea group=test lrs anyone "" This translates into a chown or chgrp in UNIX, and on other systems is a a simple alternative form of ACL SET. Otherwise, the "chgrp" type operation would require an ACL SET echoing what is already there. How is ACL DELETE implemented if it is not actually possible to delete an identifier? I'm not sure if it should set the rights to "" or to those of anyone. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61NH2FK091399 for ; Tue, 1 Jul 2003 16:17:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61NH2a4091398 for ietf-imapext-bks; Tue, 1 Jul 2003 16:17:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61NH1FK091393 for ; Tue, 1 Jul 2003 16:17:01 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h61NGv6S000429 for ; Tue, 1 Jul 2003 16:17:03 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h61NGvXa021259 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 1 Jul 2003 16:16:57 -0700 Date: Tue, 1 Jul 2003 16:16:57 -0700 (Pacific Daylight Time) From: Mark Crispin To: IMAP Extensions WG Subject: Re: acl-08: questions In-Reply-To: <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> Message-ID: References: <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 20 Jun 2003, Lawrence Greenfield wrote: > . Why is there no 'anonymous' identifier in addition to 'anyone' and > 'authuser'? Is there a reason that we would want anonymous to have rights different from anyone, given that authuser now exists? The only use would be to grant anonymous rights that some authorized users don't have. Seems silly to me. I also noted this text: [...] For example, in an implementation that uses unix mode bits, the rights "wisd" are tied, the "a" right is always granted to the owner of a mailbox and is never granted to another user. "wisd" should be replaced with "swite". -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67CQwqt062462 for ; Mon, 7 Jul 2003 05:26:58 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h67CQwrL062461 for ietf-imapext-bks; Mon, 7 Jul 2003 05:26:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (lampin@panda.com [206.124.149.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67CQuqt062455 for ; Mon, 7 Jul 2003 05:26:57 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id FAA11689; Mon, 7 Jul 2003 05:26:50 -0700 (PDT) Date: Mon, 7 Jul 2003 05:26:49 -0700 (PDT) From: Mark Crispin To: Michael Fair cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: another question about ACL -08 In-Reply-To: <029601c34463$12cbc0e0$d1d07b43@cocacola> Message-ID: References: <3F02F518.39BE6FD@isode.com> <3F073A0E.34FE07D@isode.com> <020901c3444b$a85fea40$d1d07b43@cocacola> <029601c34463$12cbc0e0$d1d07b43@cocacola> 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, 7 Jul 2003, Michael Fair wrote: > Won't this make writing generic IMAPv4 management clients > that manipulate ACLs difficult because it has to figure > out what semantics it has... I agree that there should be some means for the client to learn the semantics in advance. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h678c7qt040649 for ; Mon, 7 Jul 2003 01:38:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h678c7AN040648 for ietf-imapext-bks; Mon, 7 Jul 2003 01:38:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h678c6qt040643 for ; Mon, 7 Jul 2003 01:38:06 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 0066581AB70; Mon, 7 Jul 2003 01:38:05 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id AAB3581AB6F; Mon, 7 Jul 2003 01:38:04 -0700 (PDT) Message-ID: <029601c34463$12cbc0e0$d1d07b43@cocacola> From: "Michael Fair" To: "Mark Crispin" Cc: "Alexey Melnikov" , "IMAP Extensions WG" References: <3F02F518.39BE6FD@isode.com> <3F073A0E.34FE07D@isode.com> <020901c3444b$a85fea40$d1d07b43@cocacola> Subject: Re: another question about ACL -08 Date: Mon, 7 Jul 2003 01:38:00 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > On Sun, 6 Jul 2003, Michael Fair wrote: > > Does this mean that only one group will be allowed to have an > > entry in the ACL? Or that an individual server might opt to use those > > semantics and so ACL semantics will vary from one server to the next? > > The latter > > > If there can be more than one group or user associated in the ACL > > how do you delete/change just one of them without having to fetch the whole > > list and restore it without the intended target? > > ACL STORE and ACL DELETE act on a single identifier/rights pair. > > In a server that only allows one group, ACL STORE with a different > group identifer will replace the existing group identifer. In one which > has multiple groups, it will add a new identifier/rights pair. Thanks for the explanation. > This overloading of functionality concerns me, but apparently the > alternative is not acceptable. Won't this make writing generic IMAPv4 management clients that manipulate ACLs difficult because it has to figure out what semantics it has... Or is it just the case that any client wanting to be portable always does a DELETE then STORE regardless of server (or the most savvy clients actually trying to determine behavior based on server). -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h676tCqt022493 for ; Sun, 6 Jul 2003 23:55:12 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h676tCt0022491 for ietf-imapext-bks; Sun, 6 Jul 2003 23:55:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (ajohnson@panda.com [206.124.149.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h676t6qt022456 for ; Sun, 6 Jul 2003 23:55:06 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id XAA11258; Sun, 6 Jul 2003 23:54:58 -0700 (PDT) Date: Sun, 6 Jul 2003 23:54:24 -0700 (PDT) From: Mark Crispin To: Michael Fair cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: another question about ACL -08 In-Reply-To: <020901c3444b$a85fea40$d1d07b43@cocacola> Message-ID: References: <3F02F518.39BE6FD@isode.com> <3F073A0E.34FE07D@isode.com> <020901c3444b$a85fea40$d1d07b43@cocacola> 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 Sun, 6 Jul 2003, Michael Fair wrote: > Does this mean that only one group will be allowed to have an > entry in the ACL? Or that an individual server might opt to use those > semantics and so ACL semantics will vary from one server to the next? The latter > If there can be more than one group or user associated in the ACL > how do you delete/change just one of them without having to fetch the whole > list and restore it without the intended target? ACL STORE and ACL DELETE act on a single identifier/rights pair. In a server that only allows one group, ACL STORE with a different group identifer will replace the existing group identifer. In one which has multiple groups, it will add a new identifier/rights pair. This overloading of functionality concerns me, but apparently the alternative is not acceptable. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h675oZqt009553 for ; Sun, 6 Jul 2003 22:50:35 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h675oZhd009552 for ietf-imapext-bks; Sun, 6 Jul 2003 22:50:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from DrPepper (adsl-67-123-208-213.dsl.lsan03.pacbell.net [67.123.208.213]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h675oXqt009547 for ; Sun, 6 Jul 2003 22:50:33 -0700 (PDT) (envelope-from michael@daclubhouse.net) Received: by DrPepper (Postfix, from userid 65534) id 2166F81AB70; Sun, 6 Jul 2003 22:50:35 -0700 (PDT) Received: from cocacola (adsl-67-123-208-209.dsl.lsan03.pacbell.net [67.123.208.209]) by DrPepper (Postfix) with ESMTP id 8022D81AB6F; Sun, 6 Jul 2003 22:50:23 -0700 (PDT) Message-ID: <020901c3444b$a85fea40$d1d07b43@cocacola> From: "Michael Fair" To: "Alexey Melnikov" , "Mark Crispin" Cc: "IMAP Extensions WG" References: <3F02F518.39BE6FD@isode.com> <3F073A0E.34FE07D@isode.com> Subject: Re: another question about ACL -08 Date: Sun, 6 Jul 2003 22:50:22 -0700 Organization: DaClubhouse MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Mark Crispin wrote: > > > On Wed, 2 Jul 2003, Alexey Melnikov wrote: > > > > I don't see this as a significant benefit for clients (I doubt I'd ever > > > > want to 'rename' an ACL identifier) and only increases implementation > > > > complexity for ACL systems that don't use 'chgrp' or 'chown'. > > > I tend to agree. This is one of "nice to have" features and I have a list of 4-5 > > > other commands I've refused to put into the document. > > > > You still need to say explicitly that ACL STORE can do an implicit ACL > > DELETE of some other identifer/rights pair; > > I've added the text you proposed. Also the following example: > > C: B001 LIST (ACL) "" INBOX > S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") ( > "group=Devel" "rwipslt")))) > S: B001 OK List with acl info completed > C: B002 ACL STORE Inbox group=PSO rwipslte > S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") ( > "group=PSO" "rwipslte")))) > S: B002 OK Setacl complete > > > and there ought to be a way > > for the client to know that such a thing would happen in advance. > > Suggestions are welcome. > > I was thinking that this should be part of ACL model description. Does this mean that only one group will be allowed to have an entry in the ACL? Or that an individual server might opt to use those semantics and so ACL semantics will vary from one server to the next? If there can be more than one group or user associated in the ACL how do you delete/change just one of them without having to fetch the whole list and restore it without the intended target? -- Michael -- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h66MBoqt095513 for ; Sun, 6 Jul 2003 15:11:50 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h66MBorV095512 for ietf-imapext-bks; Sun, 6 Jul 2003 15:11:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h66MBjqt095504 for ; Sun, 6 Jul 2003 15:11:50 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (1Cust52.tnt29.lnd3.gbr.da.uu.net [62.188.120.52]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id h66MFEV07996; Sun, 6 Jul 2003 16:15:15 -0600 Message-ID: <3F073A0E.34FE07D@isode.com> Date: Sat, 05 Jul 2003 14:50:22 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: another question about ACL -08 References: <3F02F518.39BE6FD@isode.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Wed, 2 Jul 2003, Alexey Melnikov wrote: > > > I don't see this as a significant benefit for clients (I doubt I'd ever > > > want to 'rename' an ACL identifier) and only increases implementation > > > complexity for ACL systems that don't use 'chgrp' or 'chown'. > > I tend to agree. This is one of "nice to have" features and I have a list of 4-5 > > other commands I've refused to put into the document. > > You still need to say explicitly that ACL STORE can do an implicit ACL > DELETE of some other identifer/rights pair; I've added the text you proposed. Also the following example: C: B001 LIST (ACL) "" INBOX S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") ( "group=Devel" "rwipslt")))) S: B001 OK List with acl info completed C: B002 ACL STORE Inbox group=PSO rwipslte S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") ( "group=PSO" "rwipslte")))) S: B002 OK Setacl complete > and there ought to be a way > for the client to know that such a thing would happen in advance. Suggestions are welcome. I was thinking that this should be part of ACL model description. Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62HoRFK072253 for ; Wed, 2 Jul 2003 10:50:27 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62HoRQk072252 for ietf-imapext-bks; Wed, 2 Jul 2003 10:50:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from Ikkoku-Kan.Panda.COM (ittai@panda.com [206.124.149.114]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62HoPFK072243 for ; Wed, 2 Jul 2003 10:50:26 -0700 (PDT) (envelope-from mrc@CAC.Washington.EDU) Received: from localhost (mrc@localhost) by Ikkoku-Kan.Panda.COM id KAA04129; Wed, 2 Jul 2003 10:50:19 -0700 (PDT) Date: Wed, 2 Jul 2003 10:50:18 -0700 (PDT) From: Mark Crispin To: Alexey Melnikov cc: Rob Siemborski , IMAP Extensions WG Subject: Re: another question about ACL -08 In-Reply-To: <3F02F518.39BE6FD@isode.com> Message-ID: References: <3F02F518.39BE6FD@isode.com> 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, 2 Jul 2003, Alexey Melnikov wrote: > > I don't see this as a significant benefit for clients (I doubt I'd ever > > want to 'rename' an ACL identifier) and only increases implementation > > complexity for ACL systems that don't use 'chgrp' or 'chown'. > I tend to agree. This is one of "nice to have" features and I have a list of 4-5 > other commands I've refused to put into the document. You still need to say explicitly that ACL STORE can do an implicit ACL DELETE of some other identifer/rights pair; and there ought to be a way for the client to know that such a thing would happen in advance. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62F7EFK062014 for ; Wed, 2 Jul 2003 08:07:14 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62F7ELH062013 for ietf-imapext-bks; Wed, 2 Jul 2003 08:07:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62F7DFK062008 for ; Wed, 2 Jul 2003 08:07:14 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (82-43-138-23.cable.ubr01.newm.blueyonder.co.uk [82.43.138.23]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Wed, 2 Jul 2003 16:07:05 +0100 Message-ID: <3F02F518.39BE6FD@isode.com> Date: Wed, 02 Jul 2003 09:07:04 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Siemborski CC: IMAP Extensions WG Subject: Re: another question about ACL -08 References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rob Siemborski wrote: > On Tue, 1 Jul 2003, Mark Crispin wrote: > > > There should be an ACL RENAME command which will change the identifier of > > a particular identifier,rights pair while preserving the rest of the ACL. > > > > E.g., given an mailbox foo with an ACL of > > owner lrswipxtea group=devel lrs anyone "" > > the command > > ACL RENAME foo group=devel group=test > > should result in an ACL of > > owner lrswipxtea group=test lrs anyone "" > > > > This translates into a chown or chgrp in UNIX, and on other systems is a > > a simple alternative form of ACL SET. > > > > Otherwise, the "chgrp" type operation would require an ACL SET echoing > > what is already there. > > Is there a serious functionality gain here? > > I don't see this as a significant benefit for clients (I doubt I'd ever > want to 'rename' an ACL identifier) and only increases implementation > complexity for ACL systems that don't use 'chgrp' or 'chown'. I tend to agree. This is one of "nice to have" features and I have a list of 4-5 other commands I've refused to put into the document. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62ER4FK060453 for ; Wed, 2 Jul 2003 07:27:04 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62ER4YA060451 for ietf-imapext-bks; Wed, 2 Jul 2003 07:27:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from usergg026.dsl.pipex.com (usergg026.dsl.pipex.com [62.190.174.26]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62ER3FK060446 for ; Wed, 2 Jul 2003 07:27:03 -0700 (PDT) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (82-43-138-23.cable.ubr01.newm.blueyonder.co.uk [82.43.138.23]) by usergg026.dsl.pipex.com via TCP (with SMTP (internal)) with ESMTP; Wed, 2 Jul 2003 15:26:48 +0100 Message-ID: <3F02EBA7.4B11D46C@isode.com> Date: Wed, 02 Jul 2003 08:26:47 -0600 From: Alexey Melnikov Organization: Isode Limited X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Crispin CC: IMAP Extensions WG Subject: Re: acl-08: questions References: <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin wrote: > On Fri, 20 Jun 2003, Lawrence Greenfield wrote: > > . Why is there no 'anonymous' identifier in addition to 'anyone' and > > 'authuser'? > > Is there a reason that we would want anonymous to have rights different > from anyone, given that authuser now exists? No. But I think Larry suggests to add 'anonymous' as a synonym for 'anyone'. Personally, I don't care either way. 'anonymous' is an implementation specific thing for Cyrus-based servers. > The only use would be to grant anonymous rights that some authorized users > don't have. Seems silly to me. > > I also noted this text: > > [...] For example, > in an implementation that uses unix mode bits, the rights "wisd" are > tied, the "a" right is always granted to the owner of a mailbox and > is never granted to another user. > > "wisd" should be replaced with "swite". Fixed. Thanks. Alexey __________________________________________ Home Page: http://orthanc.ab.ca/mel IETF standard related pages: http://orthanc.ab.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h623FlFK098419 for ; Tue, 1 Jul 2003 20:15:47 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h623FlBX098418 for ietf-imapext-bks; Tue, 1 Jul 2003 20:15:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h623FjFK098412 for ; Tue, 1 Jul 2003 20:15:45 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id 9B2BB5C896A2; Wed, 2 Jul 2003 06:15:47 +0300 (EEST) Subject: Re: ACL2 rule identifiers From: Timo Sirainen To: Mark Crispin Cc: ietf-imapext@imc.org In-Reply-To: References: <1057110774.7582.828.camel@hurina> Content-Type: text/plain Message-Id: <1057115747.8172.858.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 02 Jul 2003 06:15:47 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 2003-07-02 at 05:23, Mark Crispin wrote: > On Tue, 2 Jul 2003, Timo Sirainen wrote: > > Preferrably there shouldn't need to be multiple rules. Make one that > > works with all cases. > > That would be desirable, but I don't think that it is possible. If one is > implementing IMAP on a pre-existing mail store, the mail store's existing > means of access control constrains what can be done in IMAP. I think it would be possible with enough thinking. You only have to be able to describe the existing limited ACLs with the new flexible one, not the other way around. Changing the ACLs would of course need some rules what to do if underlying store has more limited ACL support. BTW. Has anyone checked how Posix filesystem ACLs work? How well would it work with current rules? > So I think that hopes for a server implementing multiple rules with > clients being able to pick and choose is a pipe-dream. More likely, the > server will dictate and the client must comply. Clients can make it easier to use different rules, but users will still need to learn how to use them. I can easily imagine all the cries when the new IMAP server works differently than old one.. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h622hQFK097418 for ; Tue, 1 Jul 2003 19:43:26 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h622hQQQ097417 for ietf-imapext-bks; Tue, 1 Jul 2003 19:43:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h622hPFK097411 for ; Tue, 1 Jul 2003 19:43:25 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h622hQkI025835; Tue, 1 Jul 2003 19:43:26 -0700 Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h622gJ4A026680 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Jul 2003 19:43:22 -0700 Date: Tue, 1 Jul 2003 19:41:54 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: IMAP Extensions WG Subject: Re: another question about ACL -08 In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If that is what it is intended, it should be explicitly stated in the specification. Effectively deleting an existing ACL as a side effect of storing an ACL seems to me to be stretching the definition of "modification", and unless it is explicitly stated that this is expected and acceptable behavior there are bound to be flames if a server does that. I'll drop my request for ACL RENAME if this explicit statement is added, perhaps with an example, e.g. "in some mail stores, a mailbox can be a member of only one group. Thus, doing an ACL STORE that sets a different group from what is already in the ACL may have the effect of doing an implicit ACL DELETE of the existing group's identifier/rights pair." On Tue, 1 Jul 2003, Rob Siemborski wrote: > > Either that, or allow ACL STORE with a new identifier to arbitrarily do an > > implicit ACL DELETE of some other identifier, and *document* it in the > > specification that a server may do this. > This is significantly more palatable to me, especially given this text in > the ACL STORE definition: > An ACL2 server MAY modify one or more ACL for one or more identifier > as a side effect of modifying the ACL specified in ACL STORE. If the > server does that it MUST send untagged LIST response with ACL information > (see section 5.1) to notify the client about the changes made. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h622ZHFK097243 for ; Tue, 1 Jul 2003 19:35:17 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h622ZHRX097242 for ietf-imapext-bks; Tue, 1 Jul 2003 19:35:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h622ZFFK097236 for ; Tue, 1 Jul 2003 19:35:16 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from BBOARD.andrew.cmu.edu (BBOARD.andrew.cmu.edu [128.2.10.89]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h622ZFuO010314; Tue, 1 Jul 2003 22:35:15 -0400 Date: Tue, 1 Jul 2003 22:35:16 -0400 (EDT) From: Rob Siemborski To: Mark Crispin cc: IMAP Extensions WG Subject: Re: another question about ACL -08 In-Reply-To: Message-ID: References: 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, 1 Jul 2003, Mark Crispin wrote: > Adding ACL RENAME makes this quite a bit easier. But it seems to be functionality that already exists (see below). > Either that, or allow ACL STORE with a new identifier to arbitrarily do an > implicit ACL DELETE of some other identifier, and *document* it in the > specification that a server may do this. This is significantly more palatable to me, especially given this text in the ACL STORE definition: An ACL2 server MAY modify one or more ACL for one or more identifier as a side effect of modifying the ACL specified in ACL STORE. If the server does that it MUST send untagged LIST response with ACL information (see section 5.1) to notify the client about the changes made. Which seems to do exactly what you want here. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h622QAFK096994 for ; Tue, 1 Jul 2003 19:26:10 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h622QAm5096993 for ietf-imapext-bks; Tue, 1 Jul 2003 19:26:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h622Q9FK096988 for ; Tue, 1 Jul 2003 19:26:09 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h622Q22Z013202; Tue, 1 Jul 2003 19:26:07 -0700 Received: from Shimo-Tomobiki.Panda.COM (mes128085095.airdata.net [166.128.85.95]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h622NqXa028172 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Jul 2003 19:25:54 -0700 Date: Tue, 1 Jul 2003 19:23:44 -0700 (Pacific Daylight Time) From: Mark Crispin To: Timo Sirainen cc: ietf-imapext@imc.org Subject: Re: ACL2 rule identifiers In-Reply-To: <1057110774.7582.828.camel@hurina> Message-ID: References: <1057110774.7582.828.camel@hurina> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 2 Jul 2003, Timo Sirainen wrote: > Preferrably there shouldn't need to be multiple rules. Make one that > works with all cases. That would be desirable, but I don't think that it is possible. If one is implementing IMAP on a pre-existing mail store, the mail store's existing means of access control constrains what can be done in IMAP. The whole reason we got into this mess was that RFC 2086 turned out to be unimplementable in any reasonable way with one rather important form of pre-existing mail store. "First rule wins" with no inheritance would be fine for me (and would allow the deletion of negative rights), but I don't know if it would be suitable for people from other environments (e.g. Cyrus). So I think that hopes for a server implementing multiple rules with clients being able to pick and choose is a pipe-dream. More likely, the server will dictate and the client must comply. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h621r2FK095850 for ; Tue, 1 Jul 2003 18:53:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h621r2Wt095849 for ietf-imapext-bks; Tue, 1 Jul 2003 18:53:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from oma.irssi.org (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h621r0FK095844 for ; Tue, 1 Jul 2003 18:53:00 -0700 (PDT) (envelope-from tss@iki.fi) Received: from localhost.kpnqwest.fi (localhost [127.0.0.1]) by oma.irssi.org (Postfix) with ESMTP id DB7205C896A2 for ; Wed, 2 Jul 2003 04:52:54 +0300 (EEST) Subject: ACL2 rule identifiers From: Timo Sirainen To: ietf-imapext@imc.org Content-Type: text/plain Message-Id: <1057110774.7582.828.camel@hurina> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 02 Jul 2003 04:52:54 +0300 Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think multiple rule identifiers are a very bad idea. Clients will most likely get some of the details wrong in rules they haven't been tested against. Servers will probably have to implement multiple rules so admin can choose his preferred one. Worst of all, they confuse users. Suppose a user has gone through all the trouble to figure out how one rule works. Then he switches to another IMAP server (another ISP) that uses different rule. He might not realize that the rule changed. He might not even know that different rules exist. So he happily uses the old way to do things, and ends up sharing mailboxes to wrong people. At the very least server should be able to advertise multiple rules and client should be able to choose which one it wants to use. Preferrably there shouldn't need to be multiple rules. Make one that works with all cases. Maybe just add ordering into the rules with first matching rule wins logic, just like firewall rules usually have. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h620URFK093327 for ; Tue, 1 Jul 2003 17:30:27 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h620UROZ093326 for ietf-imapext-bks; Tue, 1 Jul 2003 17:30:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h620UQFK093321 for ; Tue, 1 Jul 2003 17:30:26 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h620UQ6S010625; Tue, 1 Jul 2003 17:30:26 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h620UQXa025144 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Jul 2003 17:30:26 -0700 Date: Tue, 1 Jul 2003 17:30:26 -0700 (Pacific Daylight Time) From: Mark Crispin To: Rob Siemborski cc: IMAP Extensions WG Subject: Re: another question about ACL -08 In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 1 Jul 2003, Rob Siemborski wrote: > > There should be an ACL RENAME command > Is there a serious functionality gain here? Yes. chgrp is a fairly important part of the UNIX filesystem access control model, and without a way to represent it (even with ACL SET) a server using the filesystem access control model is crippled. > I don't see this as a significant benefit for clients (I doubt I'd ever > want to 'rename' an ACL identifier) and only increases implementation > complexity for ACL systems that don't use 'chgrp' or 'chown'. A mailbox has an ACL for group=sys. You want it to have group=devel isntead. One obvious means of implementation (ACL DELETE + ACL STORE) won't work, since you can't ACL STORE a new identifier or ACL DELETE an existing identifier. The only way is by ACL SET, which does quite a bit more than just the chgrp (even if it's a big no-op). How is the client supposed to know this? > > How is ACL DELETE implemented if it is not actually possible to delete an > > identifier? > In the MOST-SPECIFIC case I'd expect this to set the rights to > those of anyone. > In the UNION case I'd expect this to set the rights to"". > But I'd probably expect the server to say NO if it couldn't actually > delete the identifier. Well, I agree about saying NO to ACL DELETE and to ACL STORE that tries to add an identifier. But I don't see how the client is supposed to know how to do this. Adding ACL RENAME makes this quite a bit easier. Either that, or allow ACL STORE with a new identifier to arbitrarily do an implicit ACL DELETE of some other identifier, and *document* it in the specification that a server may do this. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62096FK092620 for ; Tue, 1 Jul 2003 17:09:06 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h62096qK092619 for ietf-imapext-bks; Tue, 1 Jul 2003 17:09:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from smtp5.andrew.cmu.edu (SMTP5.andrew.cmu.edu [128.2.10.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62095FK092613 for ; Tue, 1 Jul 2003 17:09:05 -0700 (PDT) (envelope-from rjs3@andrew.cmu.edu) Received: from BBOARD.andrew.cmu.edu (BBOARD.andrew.cmu.edu [128.2.10.89]) (user=rjs3 mech=GSSAPI (0 bits)) by smtp5.andrew.cmu.edu (8.12.9/8.12.3.Beta2) with ESMTP id h62097uO007170 for ; Tue, 1 Jul 2003 20:09:07 -0400 Date: Tue, 1 Jul 2003 20:09:06 -0400 (EDT) From: Rob Siemborski To: IMAP Extensions WG Subject: Re: another question about ACL -08 In-Reply-To: Message-ID: References: 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, 1 Jul 2003, Mark Crispin wrote: > There should be an ACL RENAME command which will change the identifier of > a particular identifier,rights pair while preserving the rest of the ACL. > > E.g., given an mailbox foo with an ACL of > owner lrswipxtea group=devel lrs anyone "" > the command > ACL RENAME foo group=devel group=test > should result in an ACL of > owner lrswipxtea group=test lrs anyone "" > > This translates into a chown or chgrp in UNIX, and on other systems is a > a simple alternative form of ACL SET. > > Otherwise, the "chgrp" type operation would require an ACL SET echoing > what is already there. Is there a serious functionality gain here? I don't see this as a significant benefit for clients (I doubt I'd ever want to 'rename' an ACL identifier) and only increases implementation complexity for ACL systems that don't use 'chgrp' or 'chown'. > How is ACL DELETE implemented if it is not actually possible to delete an > identifier? I'm not sure if it should set the rights to "" or to those of > anyone. In the MOST-SPECIFIC case I'd expect this to set the rights to those of anyone. In the UNION case I'd expect this to set the rights to"". But I'd probably expect the server to say NO if it couldn't actually delete the identifier. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61NY7FK091833 for ; Tue, 1 Jul 2003 16:34:07 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61NY7Br091832 for ietf-imapext-bks; Tue, 1 Jul 2003 16:34:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61NY6FK091827 for ; Tue, 1 Jul 2003 16:34:06 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h61NY3kI010329 for ; Tue, 1 Jul 2003 16:34:08 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h61NY24A020739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 1 Jul 2003 16:34:03 -0700 Date: Tue, 1 Jul 2003 16:34:03 -0700 (Pacific Daylight Time) From: Mark Crispin To: IMAP Extensions WG Subject: another question about ACL -08 Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There should be an ACL RENAME command which will change the identifier of a particular identifier,rights pair while preserving the rest of the ACL. E.g., given an mailbox foo with an ACL of owner lrswipxtea group=devel lrs anyone "" the command ACL RENAME foo group=devel group=test should result in an ACL of owner lrswipxtea group=test lrs anyone "" This translates into a chown or chgrp in UNIX, and on other systems is a a simple alternative form of ACL SET. Otherwise, the "chgrp" type operation would require an ACL SET echoing what is already there. How is ACL DELETE implemented if it is not actually possible to delete an identifier? I'm not sure if it should set the rights to "" or to those of anyone. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61NH2FK091399 for ; Tue, 1 Jul 2003 16:17:02 -0700 (PDT) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61NH2a4091398 for ietf-imapext-bks; Tue, 1 Jul 2003 16:17:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61NH1FK091393 for ; Tue, 1 Jul 2003 16:17:01 -0700 (PDT) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h61NGv6S000429 for ; Tue, 1 Jul 2003 16:17:03 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.9+UW03.06/8.12.9+UW03.06) with ESMTP id h61NGvXa021259 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 1 Jul 2003 16:16:57 -0700 Date: Tue, 1 Jul 2003 16:16:57 -0700 (Pacific Daylight Time) From: Mark Crispin To: IMAP Extensions WG Subject: Re: acl-08: questions In-Reply-To: <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> Message-ID: References: <200306181153.HAA28125@ietf.org> <200306201737.h5KHbTnw021727@smtp6.andrew.cmu.edu> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 20 Jun 2003, Lawrence Greenfield wrote: > . Why is there no 'anonymous' identifier in addition to 'anyone' and > 'authuser'? Is there a reason that we would want anonymous to have rights different from anyone, given that authuser now exists? The only use would be to grant anonymous rights that some authorized users don't have. Seems silly to me. I also noted this text: [...] For example, in an implementation that uses unix mode bits, the rights "wisd" are tied, the "a" right is always granted to the owner of a mailbox and is never granted to another user. "wisd" should be replaced with "swite". -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.