Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBU8Ojib011662 for ; Tue, 30 Dec 2003 00:24:45 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBU8OjSi011660 for ietf-imapext-bks; Tue, 30 Dec 2003 00:24:45 -0800 (PST) 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.10/8.12.8) with ESMTP id hBU8Oiib011648 for ; Tue, 30 Dec 2003 00:24:44 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBU8Ob9n019176; Tue, 30 Dec 2003 00:24:43 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBU8ObCh012455; Tue, 30 Dec 2003 00:24:37 -0800 Date: Tue, 30 Dec 2003 00:24:37 -0800 (PST) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Mon, 29 Dec 2003, Rob Siemborski wrote: > What if the client is accessing two servers -- one which does not support > ACL? Well, then, presumably he has no choice but to use PERMISSIONS on that server. But he wouldn't be using PERMISSIONS and ACL simultaneously on the same server. -- 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.10/8.12.8) with ESMTP id hBTMd1ib017417 for ; Mon, 29 Dec 2003 14:39:01 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTMd1RS017416 for ietf-imapext-bks; Mon, 29 Dec 2003 14:39:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTMd0ib017410 for ; Mon, 29 Dec 2003 14:39:00 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBTMcxl4008881; Mon, 29 Dec 2003 17:38:59 -0500 Date: Mon, 29 Dec 2003 17:38:59 -0500 (EST) From: Rob Siemborski To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Mon, 29 Dec 2003, Mark Crispin wrote: > Well, you saw an explanation about how that can be done in Timo's message. Yes -- I'm pretty sure now I misunderstood what you meant. > But there aren't any such protocols! And once you go down that path, then > you get into the obvious question of why IMAP is even in the ACL business. LDAP, atleast, has been used for group management. Certainly a directory makes more sense to store this information in than a mail store. > > I'd also call it a disadvantage that now a server that wants to implement > > ACL has to implement another orthogonal scheme which is similar to ACL in > > complexity. > > No, PERMISSIONS is much smaller. [snip] Ok, we were talking about two entirely different PERMISSIONS descriptions. Now I have a clear(er) picture of yours. I'm going to think this over now. > A user who normally manipulates access control would typically use either > PERMISSIONS or ACL, but would not use both. Or, put another way, anyone > who does use both deserves to lose as punishment for his foolishness. What if the client is accessing two servers -- one which does not support ACL? -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+++ X- R@ tv-- b+ DI+++ D++ 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.10/8.12.8) with ESMTP id hBTMYAib017215 for ; Mon, 29 Dec 2003 14:34:10 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTMYABv017214 for ietf-imapext-bks; Mon, 29 Dec 2003 14:34:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTMY8ib017208 for ; Mon, 29 Dec 2003 14:34:09 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBTMY4lo023623; Mon, 29 Dec 2003 14:34:09 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBTMY4NY029221; Mon, 29 Dec 2003 14:34:04 -0800 Date: Mon, 29 Dec 2003 14:34:04 -0800 (PST) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Mon, 29 Dec 2003, Rob Siemborski wrote: > But here we're not talking about ACL2 -- we're talking about the upgrade > path from ACL to ACL2. We're currently *in* a world where there are > deployments with different groups with different rights on a folder, and > that needs to be dealt with. If that means we need to have both UNION and > MOST-SPECIFIC, that's fine with me. Well, you saw an explanation about how that can be done in Timo's message. > I don't think that it is reasonable to expect the IMAP server to be even > capable of manipulating groups -- leave that to protocols that have been > designed for that sort of thing. But there aren't any such protocols! And once you go down that path, then you get into the obvious question of why IMAP is even in the ACL business. > I'd also call it a disadvantage that now a server that wants to implement > ACL has to implement another orthogonal scheme which is similar to ACL in > complexity. No, PERMISSIONS is much smaller. Think of there being only four identifiers (in the RFC 2086 sense): owner, group, world, and anonymous. The anonymous user is stuck in anonymous. Otherwise, if your userid is in the owner list, then you get owner rights. Otherwise, if your userid is a member of a group that is in the group list, then you get group rights. Otherwise, you get world rights. There are tools to manager the owner list, group list, and membership within a group. Some of these tools may be restricted to admins. > Clients then have to interpret both of these unrelated > schemes to figure out what is going on. No. Not normally, anyway. A client would not normally be using the ACL commands if the user is not someone who normally manipulates ACLs for that mailbox (the "owner" in the PERMISSIONS world). A user who normally manipulates access control would typically use either PERMISSIONS or ACL, but would not use both. Or, put another way, anyone who does use both deserves to lose as punishment for his foolishness. The missing piece of the equation is "how does a non-owner" know whether or not he can do something? *That* is done in one of two ways: either by trying it to see if it works, *OR* by doing an access control CHECK operation. The access control check operation ("can I do t to such-and-such mailbox") is something that is common to both PERMISSIONS and ACL. Fortunately, access control check is less complicated than trying to represent PERMISSIONS in ACL or ACL in PERMISSIONS, since access control check is merely a binary "yes or no" to the question "will such-and-such win?". -- 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.10/8.12.8) with ESMTP id hBTM88ib015801 for ; Mon, 29 Dec 2003 14:08:08 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTM88jZ015800 for ietf-imapext-bks; Mon, 29 Dec 2003 14:08:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTM86ib015793 for ; Mon, 29 Dec 2003 14:08:07 -0800 (PST) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 487AA238AD; Tue, 30 Dec 2003 00:08:00 +0200 (EET) Received: from [192.168.10.209] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 8D85D23866; Tue, 30 Dec 2003 00:07:26 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-7--60835413" Message-Id: <621DD0CF-3A4B-11D8-9E05-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit Cc: Mark Crispin , ietf-imapext@imc.org From: Timo Sirainen Subject: Re: Yet another ACL Strawman Date: Tue, 30 Dec 2003 00:07:25 +0200 To: Rob Siemborski X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.609) X-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-7--60835413 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Dec 29, 2003, at 11:24 PM, Rob Siemborski wrote: > On Mon, 29 Dec 2003, Mark Crispin wrote: > >> And it seems that the problem is brought about *not* by most-specific >> between user vs. group vs. world identifiers, but rather by >> most-specific >> between groups with different rights. That's a design wart in ACL2 >> that >> bears looking into. > > But here we're not talking about ACL2 -- we're talking about the > upgrade > path from ACL to ACL2. We're currently *in* a world where there are > deployments with different groups with different rights on a folder, > and > that needs to be dealt with. If that means we need to have both UNION > and > MOST-SPECIFIC, that's fine with me. I'm not sure if you really understood what Mark said.. It anyway sounds to me like a quite workable solution. You'd have MOST-SPECIFIC behaviour but if there's multiple groups, you'd get union of them. Wouldn't that make it possible to quite easily convert old ACLs to ACL2? You can keep your old groups, only problems are if you have combined user, group and world rights. Then you'd have to do something like: user + world: merge world rights directly to user user + group(s): merge group rights directly to user group(s) + world: create a new "world" group and give world rights to world group Other combinations would work the same way as they did with ACL. --Apple-Mail-7--60835413 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/8KWdyUhSUUBViskRAp6vAKCkbwFHYfubMYDNo/r66MoiNWUHtACfWdXc aizq8mBkYBU99chj0CuKOB4= =hQS6 -----END PGP SIGNATURE----- --Apple-Mail-7--60835413-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTLOmib012863 for ; Mon, 29 Dec 2003 13:24:50 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTLOmJo012862 for ietf-imapext-bks; Mon, 29 Dec 2003 13:24:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTLOkib012857 for ; Mon, 29 Dec 2003 13:24:47 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBTLOkl4008825; Mon, 29 Dec 2003 16:24:46 -0500 Date: Mon, 29 Dec 2003 16:24:46 -0500 (EST) From: Rob Siemborski To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Mon, 29 Dec 2003, Mark Crispin wrote: > And it seems that the problem is brought about *not* by most-specific > between user vs. group vs. world identifiers, but rather by most-specific > between groups with different rights. That's a design wart in ACL2 that > bears looking into. But here we're not talking about ACL2 -- we're talking about the upgrade path from ACL to ACL2. We're currently *in* a world where there are deployments with different groups with different rights on a folder, and that needs to be dealt with. If that means we need to have both UNION and MOST-SPECIFIC, that's fine with me. The proposal was more or less an attempt to try an alternative/minimal approach. It seems that in order to keep everyone happy feature-wise we are better off (however bad it is) with ACL2 and some sort of way to announce how identifiers interact. > Perhaps matters would be easier if you discuss how you implement groups in > RFC 2086. As I read RFC 2086, it's a complete crapshoot how groups work > in ACL, so a client really has no idea what a "group" is. In our implementation, group management isn't done internally, instead we pull group membership from one of any number of sources (UNIX groups, AFS ptserver, LDAP, etc). This tends to work well since it ensures that group management is located in a single place for any given enterprise, and many applications can share the same groups. I don't think that it is reasonable to expect the IMAP server to be even capable of manipulating groups -- leave that to protocols that have been designed for that sort of thing. > No. I mean that PERMISSIONS is a separate layer. If you have PERMISSIONS > access, you get it. ACLs are only consulted if you don't have PERMISSIONS > access. The implication of this is that the use of ACLs requires denial > of all permissions (setting PERMISSIONS rights to none). Ok -- I understand what you are saying now. > The disadvantage of this is that a PERMISSIONS only client won't show > anything reasonable with server mailboxes that use ACL. I consider this > to be a small price to pay to gain the simplicity. I'd also call it a disadvantage that now a server that wants to implement ACL has to implement another orthogonal scheme which is similar to ACL in complexity. Clients then have to interpret both of these unrelated schemes to figure out what is going on. This is far from ideal from a management perspective. This is far worse than even the complicated scheme using regular expressions that the most recent ACL2 thread came up with. -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+++ X- R@ tv-- b+ DI+++ D++ 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.10/8.12.8) with ESMTP id hBTL9kib011983 for ; Mon, 29 Dec 2003 13:09:46 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTL9kD7011982 for ietf-imapext-bks; Mon, 29 Dec 2003 13:09:46 -0800 (PST) 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.10/8.12.8) with ESMTP id hBTL9jib011977 for ; Mon, 29 Dec 2003 13:09:45 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBTL9jsr014894; Mon, 29 Dec 2003 13:09:45 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBTL9jJf024021; Mon, 29 Dec 2003 13:09:45 -0800 Date: Mon, 29 Dec 2003 13:09:45 -0800 (PST) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Mon, 29 Dec 2003, Rob Siemborski wrote: > Which has a similar problem for ongoing manageability (I want to remove a > user from my admins group -- now I have to go through and fix ALL of these > folders? You've got to be kidding me!). And having an admins group *is* > used in practice. Uh, excuse me. I did say something about the need to be able to manage the membership of a group. And it seems that the problem is brought about *not* by most-specific between user vs. group vs. world identifiers, but rather by most-specific between groups with different rights. That's a design wart in ACL2 that bears looking into. Perhaps matters would be easier if you discuss how you implement groups in RFC 2086. As I read RFC 2086, it's a complete crapshoot how groups work in ACL, so a client really has no idea what a "group" is. > > Who said anything about limiting PERMISSIONS to only one user? I > > certainly never thought that "owner" equated to a single user; rather, > > owner equates to one or more users with owner rights. > The most recent strawman linked it to a single user identifier in the ACL > realm. That's not my strawman, and a single user identifier is not good enough. > Unless you're saying my position is that "PERMISSIONS is a strict subset > of ACL" which I *do* think is a good thing, because it ensures that > servers that implement ACL can implement PERMISSIONS as well (as > PERMISSIONS exists to enable servers that cannot implement ACL to still > have a rights management scheme). I think that your making PERMISSIONS a strict subset of ACL is what is causing the confusion. See next paragraph. > > If necessary, I'd be ameniable to a compromise in which use of ACL > > requires that all PERMISSIONS be denied. That's been done before. > I'm not sure what you mean here. Do you mean an ACL server refuses to > support any PERMISSIONS commands, or something else? No. I mean that PERMISSIONS is a separate layer. If you have PERMISSIONS access, you get it. ACLs are only consulted if you don't have PERMISSIONS access. The implication of this is that the use of ACLs requires denial of all permissions (setting PERMISSIONS rights to none). The disadvantage of this is that a PERMISSIONS only client won't show anything reasonable with server mailboxes that use ACL. I consider this to be a small price to pay to gain the simplicity. > No, I'm worried that the complexity of multiple users/groups will just > make PERMISSIONS "ACL with less bits" which is more or less useless, since > the "less bits" problem can be equally well solved with adequately defined > tied rights. A PERMISSIONS model which does less than the most limited access controls of the 1960s is also more or less useless. -- 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.10/8.12.8) with ESMTP id hBTJxZib007618 for ; Mon, 29 Dec 2003 11:59:35 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTJxZQJ007617 for ietf-imapext-bks; Mon, 29 Dec 2003 11:59:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTJxXib007612 for ; Mon, 29 Dec 2003 11:59:34 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from ASG1.WEB.cmu.edu (ASG1.WEB.cmu.edu [128.2.11.38]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBTJxXl4008748; Mon, 29 Dec 2003 14:59:33 -0500 Date: Mon, 29 Dec 2003 14:59:33 -0500 (EST) From: Rob Siemborski X-X-Sender: rjs3@asg1.web.cmu.edu To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Mon, 29 Dec 2003, Mark Crispin wrote: > On Mon, 29 Dec 2003, Rob Siemborski wrote: > > For example, let's say I have three groups: g1, g2, and g3. > > g1: u1, u2 ("readers") > > g2: u2, u3 ("writers") > > g3: u3, u4 ("baddies") > > And an ACL(1) on a folder of: > > g1: rls > > g2: wipcda > > g3: -rlswipcda > > Is a group of specifically restricted users (with a large set of negative > rights that denies world access) really in deployment today? Does CMU use > it? While I was using negative rights in the example, a similar problem exists with positive rights: g1: u1, u2 ("readers") g2: u2, u3 ("writers") g3: u1, u3, u4 ("admins") And an ACL(1) on a folder of: g1: rls g2: wipcd g3: a Results in a most-specific acl of: g1: rls g2: lwipcd g3: la u1: rlsa u3: lwipcda Which has a similar problem for ongoing manageability (I want to remove a user from my admins group -- now I have to go through and fix ALL of these folders? You've got to be kidding me!). And having an admins group *is* used in practice. I can't see anyone who uses groups heavily to want to upgrade from ACL to ACL2 if it meant that their ACLs would be destroyed in a non-backwards-compatible manner. > > If a PERMISSIONS server can support any number of groups, then you haven't > > created something "lightweight" you've reinvented ACL2 with only two (or > > three?) bits, and only one user arguments about PERMISSIONS as we're > > currently having about ACL2, only with far fewer features in the protocol. > > If you feel that ACL was over-engineered, I won't dispute that. Actually -- I feel it was under-engineered, given the problems it has with identifiers and the delete right. > > If its somehow ok to limit PERMISSIONS to only one user, it should also be > > OK to limit PERMISSIONS to no groups. > > Who said anything about limiting PERMISSIONS to only one user? I > certainly never thought that "owner" equated to a single user; rather, > owner equates to one or more users with owner rights. The most recent strawman linked it to a single user identifier in the ACL realm. > I am dismayed by the notion that the capabilities of PERMISSIONS are to be > dictated by ACL. Among other things, this opens the door to charges that > PERMISSIONS was deliberately sabotaged. I certainly feel that way when > you tell me what I can or can not have in PERMISSIONS. I don't think that PERMISSIONS is being sabotaged -- rather, I think we are conceding one sort of complexity (two rights management schemes) for reducing complexity in ACL (communicating a server's capability). Unless you're saying my position is that "PERMISSIONS is a strict subset of ACL" which I *do* think is a good thing, because it ensures that servers that implement ACL can implement PERMISSIONS as well (as PERMISSIONS exists to enable servers that cannot implement ACL to still have a rights management scheme). > If necessary, I'd be ameniable to a compromise in which use of ACL > requires that all PERMISSIONS be denied. That's been done before. I'm not sure what you mean here. Do you mean an ACL server refuses to support any PERMISSIONS commands, or something else? > > We certainly don't need to > > make the situation even worse by intrducing two extensions to do the same > > thing, except that one has fewer bits than the other. > > Are you worried that PERMISSIONS would be good enough that nobody would > implement ACL? No, I'm worried that the complexity of multiple users/groups will just make PERMISSIONS "ACL with less bits" which is more or less useless, since the "less bits" problem can be equally well solved with adequately defined tied rights. -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+++ X- R@ tv-- b+ DI+++ D++ 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.10/8.12.8) with ESMTP id hBTJjAib006904 for ; Mon, 29 Dec 2003 11:45:10 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTJjA72006903 for ietf-imapext-bks; Mon, 29 Dec 2003 11:45:10 -0800 (PST) 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.10/8.12.8) with ESMTP id hBTJj9ib006898 for ; Mon, 29 Dec 2003 11:45:09 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBTJj4sr006085; Mon, 29 Dec 2003 11:45:09 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBTJj4gk020477; Mon, 29 Dec 2003 11:45:04 -0800 Date: Mon, 29 Dec 2003 11:45:04 -0800 (PST) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Mon, 29 Dec 2003, Rob Siemborski wrote: > For example, let's say I have three groups: g1, g2, and g3. > g1: u1, u2 ("readers") > g2: u2, u3 ("writers") > g3: u3, u4 ("baddies") > And an ACL(1) on a folder of: > g1: rls > g2: wipcda > g3: -rlswipcda Is a group of specifically restricted users (with a large set of negative rights that denies world access) really in deployment today? Does CMU use it? RFC 2086 is very vague about groups. I don't see how you can hope to have something that's interoperable across all clients with RFC 2086. We put restricted users on restricted servers. > If a PERMISSIONS server can support any number of groups, then you haven't > created something "lightweight" you've reinvented ACL2 with only two (or > three?) bits, and only one user arguments about PERMISSIONS as we're > currently having about ACL2, only with far fewer features in the protocol. If you feel that ACL was over-engineered, I won't dispute that. > If its somehow ok to limit PERMISSIONS to only one user, it should also be > OK to limit PERMISSIONS to no groups. Who said anything about limiting PERMISSIONS to only one user? I certainly never thought that "owner" equated to a single user; rather, owner equates to one or more users with owner rights. I am dismayed by the notion that the capabilities of PERMISSIONS are to be dictated by ACL. Among other things, this opens the door to charges that PERMISSIONS was deliberately sabotaged. I certainly feel that way when you tell me what I can or can not have in PERMISSIONS. > If groups are necessary in a "lightweight" system, then this particular > strawman has basicly already lost, since that's the level of complexity > that is causing all sorts of trouble in ACL2. I disagree. PERMISSIONS should split the access control problem into two separate mechanisms, one of which is more featureful and the other of which is more likely to be universally implemented. It isn't as if this hasn't been done before, and successfully. The problem seems to come in when access control lists are proposed to be the only solution to the access control problem, and then everybody gets sidetracked on how ACLs are to be subsetted. If necessary, I'd be ameniable to a compromise in which use of ACL requires that all PERMISSIONS be denied. That's been done before. > We certainly don't need to > make the situation even worse by intrducing two extensions to do the same > thing, except that one has fewer bits than the other. Are you worried that PERMISSIONS would be good enough that nobody would implement ACL? -- 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.10/8.12.8) with ESMTP id hBTHopib000851 for ; Mon, 29 Dec 2003 09:50:51 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTHop2I000850 for ietf-imapext-bks; Mon, 29 Dec 2003 09:50:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTHonib000844 for ; Mon, 29 Dec 2003 09:50:50 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBTHoll4008620; Mon, 29 Dec 2003 12:50:47 -0500 Date: Mon, 29 Dec 2003 12:50:48 -0500 (EST) From: Rob Siemborski To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Wed, 24 Dec 2003, Mark Crispin wrote: > > > . I contend that MOST-SPECIFIC should be the *only* access calculation > > > rule > > This makes it very hard or even impossible for a server to upgrade from > > ACL (using UNION). To do so, you would need to calculate the rights at a > > given moment in time, and then re-advertise them. > > I don't think that's really the case. The server should be able to > calculate the ACL2 equivalent of ACL rights fairly easily. Backwards > calculation will be harder to do reversibly, but the point is that we're > not trying to make that be perfect. Sure, you can calculate the rights quickly at any instant of time, but this fails if an organization has a long-standing use of union ACLs, and has allocated their groups accordingly. *Especially* if they manage them for other purposes. For example, let's say I have three groups: g1, g2, and g3. Their contents: g1: u1, u2 ("readers") g2: u2, u3 ("writers") g3: u3, u4 ("baddies") And an ACL(1) on a folder of: g1: rls g2: wipcda g3: -rlswipcda In ACL(2)/MOST-SPECIFIC [disregarind the d right], the server would upgrade this to: g1: rls g2: wipcda u2: rlswipcda u3: '' If you apply this across many folders, this can create a sudden management nightmare, since every user can suddenly have their own acl on every folder, destroying a standing group management policy (and effectively rendering the groups, which were designed with UNION style rights in mind, entirely useless). No, If ACL2 is to be adopted by current ACL sites, it needs to support *atleast* the current semantics. > > > 4) The design of the lightweight mechanism should not preclude a server > > > implementation being able to support both lightweight and ACL2. > > I would hope that any server implementing ACL2 would be able to trivially > > implement any sort of "lightweight" system. > > The difficulty would be expressing more complex ACL2 patterns in > lightweight. My answer is not to try to make it perfect. I offered a simple, unambiguous method to express this: an all-or-nothing approach. > > > 6) Precise mapping details, such as the lightweight mapping of "s" or "t", > > > will be left up to the server implementation. > > I think some rights are inherently tied though -- you wouldn't want a > > server that uses 'r' as a READ-WRITE right. > > Yes, of course. My point is that implementations should have latitude of > how they interpret lightweight WRITE in the context of "s", "t", and "w". This worries me somewhat, but I don't see any immediate problems with it from either a PERMISSIONS-only server (no concept of acl bits) or an ACL/PERMISSIONS shared server (you can always find out the real story by looking at the ACL). > > However, I fear that the use of groups in a "lightweight" system will just > > recreate the current ACL2 situation -- loads of complexity to deal with > > the fact that the lightweight system may not be able to handle more than > > one group. > > I don't think that there's a problem. A server, whether ACL2 or > lightweight, has the freedom to decide how many groups it supports; and > that number can be 1. If a PERMISSIONS server can support any number of groups, then you haven't created something "lightweight" you've reinvented ACL2 with only two (or three?) bits, and only one user arguments about PERMISSIONS as we're currently having about ACL2, only with far fewer features in the protocol. If its somehow ok to limit PERMISSIONS to only one user, it should also be OK to limit PERMISSIONS to no groups. If groups are necessary in a "lightweight" system, then this particular strawman has basicly already lost, since that's the level of complexity that is causing all sorts of trouble in ACL2. We certainly don't need to make the situation even worse by intrducing two extensions to do the same thing, except that one has fewer bits than the other. -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+++ X- R@ tv-- b+ DI+++ D++ 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.10/8.12.8) with ESMTP id hBSLEmib070678 for ; Sun, 28 Dec 2003 13:14:48 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBSLEmOo070677 for ietf-imapext-bks; Sun, 28 Dec 2003 13:14:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBSLElib070670 for ; Sun, 28 Dec 2003 13:14:47 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [10.0.2.4] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3) for ; Sun, 28 Dec 2003 15:14:44 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.1a7] Date: Sun, 28 Dec 2003 15:14:41 -0600 To: ietf-imapext@imc.org From: Pete Resnick Subject: Shall we meet in Seoul? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Who is going to be able to make it to Seoul? Do we have items about which we need to meet? Would a multicast session make a difference? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBSLCIib070448 for ; Sun, 28 Dec 2003 13:12:18 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBSLCIaX070447 for ietf-imapext-bks; Sun, 28 Dec 2003 13:12:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBSLCHib070442 for ; Sun, 28 Dec 2003 13:12:17 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [10.0.2.4] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3) for ; Sun, 28 Dec 2003 15:12:15 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.1a7] Date: Sun, 28 Dec 2003 15:12:12 -0600 To: ietf-imapext@imc.org From: Pete Resnick Subject: IMAP URL update? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On the LEMONADE list, Alexey mentioned that some folks had been talking about an update to the IMAP URL spec (RFC 2192) which would, perhaps among other things, add syntax to allow byte ranges for partial messages. Is anyone currently working on that or planning to work on it? I would like to refer to it in a document I am working on for LEMONADE. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBOMcxib026277 for ; Wed, 24 Dec 2003 14:38:59 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBOMcxEv026276 for ietf-imapext-bks; Wed, 24 Dec 2003 14:38:59 -0800 (PST) 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.10/8.12.8) with ESMTP id hBOMcwib026270 for ; Wed, 24 Dec 2003 14:38:58 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBOMcrK4015791; Wed, 24 Dec 2003 14:38:58 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBOMcre1003238; Wed, 24 Dec 2003 14:38:53 -0800 Date: Wed, 24 Dec 2003 14:38:53 -0800 (PST) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Sat, 20 Dec 2003, Rob Siemborski wrote: > > Also, just as eliminating the need to support non-ACL access control > > models in ACL2 would simplify ACL2, so would the elimination of RFC 2086 > > compatibility. > I'm not convinced that this "simplifies" ACL2 much, other than eliminating > the need to tie the 'd' right. If we have PERMISSIONS as a separate entity from ACL2, we can eliminate tied rights in ACL2. That is, a server that implements ACL2 must implement all ACL2 rights as discreet entities. Given that ACL2 is "all or not at all", it can be made much simpler; and given that PERMISSIONS exists as a lighter-weight model, it's alright that ACL2 be "all or not all all". > > . I contend that MOST-SPECIFIC should be the *only* access calculation > > rule > This makes it very hard or even impossible for a server to upgrade from > ACL (using UNION). To do so, you would need to calculate the rights at a > given moment in time, and then re-advertise them. I don't think that's really the case. The server should be able to calculate the ACL2 equivalent of ACL rights fairly easily. Backwards calculation will be harder to do reversibly, but the point is that we're not trying to make that be perfect. > > 4) The design of the lightweight mechanism should not preclude a server > > implementation being able to support both lightweight and ACL2. > I would hope that any server implementing ACL2 would be able to trivially > implement any sort of "lightweight" system. The difficulty would be expressing more complex ACL2 patterns in lightweight. My answer is not to try to make it perfect. > > 6) Precise mapping details, such as the lightweight mapping of "s" or "t", > > will be left up to the server implementation. > I think some rights are inherently tied though -- you wouldn't want a > server that uses 'r' as a READ-WRITE right. Yes, of course. My point is that implementations should have latitude of how they interpret lightweight WRITE in the context of "s", "t", and "w". > However, I fear that the use of groups in a "lightweight" system will just > recreate the current ACL2 situation -- loads of complexity to deal with > the fact that the lightweight system may not be able to handle more than > one group. I don't think that there's a problem. A server, whether ACL2 or lightweight, has the freedom to decide how many groups it supports; and that number can be 1. Of greater concern is that some lightweight implementations may wish to support multiple groups, but have all groups have the same rights. I don't think that we really need to address this as long as the server announces the result of any changes. > If I change the group with the lightweight interface -- what happens in > the ACL/ACL2 representation? What if the ACL contains multiple groups? > What does the lightweight system report? I would do an end run around all of this and say that *any* lightweight changes immediately resets all ACL2 settings to reflect the lightweight setting. If you don't want this to happen to your acls, then don't use a lightweight interface to manipulate them ("doctor, it hurts when I do this"/"so don't do it!"). If you just access ACL2 settings through lightweight, then you'll get a "reasonable approximation". The presumption here is that a user will be lightweight or ACL2, but not both except for an upgrade of a lightweight user to an ACL2 user. So, we concentrate our attention on making upgrade be correct, but we don't worry too much about downgrade. -- 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.10/8.12.8) with ESMTP id hBKH7Oib098094 for ; Sat, 20 Dec 2003 09:07:24 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBKH7OsE098093 for ietf-imapext-bks; Sat, 20 Dec 2003 09:07:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBKH7Mib098088 for ; Sat, 20 Dec 2003 09:07:23 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBKH7Nk5009461 for ; Sat, 20 Dec 2003 12:07:23 -0500 Date: Sat, 20 Dec 2003 12:07:23 -0500 (EST) From: Rob Siemborski To: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Wed, 10 Dec 2003, Mark Crispin wrote: > I agree with the desire to "do the minimum required to fix ACL". I don't > think that it's quite as small as you'd like. In particular I don't think > that a "fix" to ACL would leave UNION as the only access calculation rule. I'm willing to discuss this, the initial proposal didn't address it at all, really. > Also, just as eliminating the need to support non-ACL access control > models in ACL2 would simplify ACL2, so would the elimination of RFC 2086 > compatibility. I'm not convinced that this "simplifies" ACL2 much, other than eliminating the need to tie the 'd' right. > 1) We all agree that RFC 2086 is broken. ACL is dead, long live ACL2 and > PERMISSIONS. I think we all agree that 2086 is broken now, or we wouldn't be talking about ACL2. > 2) ACL2 will not attempt to be compatible with RFC 2086. It should be a > redesign, and do what's right: > . I contend that MOST-SPECIFIC should be the *only* access calculation > rule, on the grounds that it makes ACLs easier for clients and users to > understand, and allows the removal of negative rights from the > specification. This makes it very hard or even impossible for a server to upgrade from ACL (using UNION). To do so, you would need to calculate the rights at a given moment in time, and then re-advertise them. If we needs MOST-SPECIFIC semantics in ACL2 for adoption, then we have to deal with having two rulesets -- not one. > . no "t" right. Redefine "d" instead. As long as we have tied rights, I don't think this is a serious concern. > 3) ACL2 will not attempt to support any other existing access control > models either [this is my big concession]; this is unnecessary since there > will be a separate lightweight access control mechanism [this is your big > concession]. Ok. > 4) The design of the lightweight mechanism should not preclude a server > implementation being able to support both lightweight and ACL2. I would hope that any server implementing ACL2 would be able to trivially implement any sort of "lightweight" system. > Conceivably, a server might be able to support ACL too. This is very desirable, but as long as a direct upgrade of existing ACLs could be made, it isn't a showstopper. > 5) There should be some guidelines for mappings right from one to the > other, but it should be understood from the onset that the mapping is > focused on: > . users who use one form exclusively > . users upgrading from lightweight (or ACL) to ACL2 > In particular, a downgrade *will* be lossy. Life is tough. I *think* the original proposal accepted this. (i.e. in PERMISSIONS+ACL2 there was a loss of information if you only looked at the PERMISSIONS data [no groups + tied rights], likewise with ACL+ACL2 [the d right was lossy]. > 6) Precise mapping details, such as the lightweight mapping of "s" or "t", > will be left up to the server implementation. I think some rights are inherently tied though -- you wouldn't want a server that uses 'r' as a READ-WRITE right. > 7) Lightweight will have read/write/list rights. It will also have > groups. Details to be determined. What you proposed was too minimal. I'm fine with r/w/l rights in the lightweight system. However, I fear that the use of groups in a "lightweight" system will just recreate the current ACL2 situation -- loads of complexity to deal with the fact that the lightweight system may not be able to handle more than one group. If I change the group with the lightweight interface -- what happens in the ACL/ACL2 representation? What if the ACL contains multiple groups? What does the lightweight system report? I think there are far too many questions if we do this, and if this is necessary, going to a PERMISSIONS+ACL2 system gains us nothing, and loses a LOT in on interoperability and complexity of the spec. I'd rather see ACL2 as it is now (modulo the recent round of comments) than see this system. The main benefit of the PERMISSIONS proposal is that it holds PERMISSIONS as a subset (owner, anyone) of the ACL -- there's no complicated mapping between the identifiers in the two systems for a server that implements both. -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+++ X- R@ tv-- b+ DI+++ D++ 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.10/8.12.8) with ESMTP id hBB3aNib079408 for ; Wed, 10 Dec 2003 19:36:23 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBB3aNw7079407 for ietf-imapext-bks; Wed, 10 Dec 2003 19:36:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBB3aMib079402 for ; Wed, 10 Dec 2003 19:36:22 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBB3aI4l023031; Wed, 10 Dec 2003 19:36:23 -0800 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.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBB3aHvo024012 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 10 Dec 2003 19:36:18 -0800 Date: Wed, 10 Dec 2003 19:34:15 -0800 (Pacific Standard Time) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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: Hi Rob - I've meant to answer your message, but I've kept on putting it off. I observed some time ago that the issue isn't about ACL (access control lists) but rather about access control. Your proposal is a variation of something that I suggested quite some time ago, which is to have a lightweight form of access control (which you call PERMISSIONS), and ACL as a heavyweight form. A server could support both, so there would need to be some set of mapping and conflict resolution rules. At the time, this was opposed on the grounds that for many people, lightweight would be good enough and it would preclude the widespread deployment of ACL. I am willing to revisit the issue. However, I think that the people who want a lightweight form should define what is in (and more importantly, what is absent from!!) the lightweight form. I agree with the desire to "do the minimum required to fix ACL". I don't think that it's quite as small as you'd like. In particular I don't think that a "fix" to ACL would leave UNION as the only access calculation rule. Also, just as eliminating the need to support non-ACL access control models in ACL2 would simplify ACL2, so would the elimination of RFC 2086 compatibility. With this in mind, here's what I would consider a good alterative to the current ACL2 document: 1) We all agree that RFC 2086 is broken. ACL is dead, long live ACL2 and PERMISSIONS. 2) ACL2 will not attempt to be compatible with RFC 2086. It should be a redesign, and do what's right: . I contend that MOST-SPECIFIC should be the *only* access calculation rule, on the grounds that it makes ACLs easier for clients and users to understand, and allows the removal of negative rights from the specification. . no "t" right. Redefine "d" instead. . etc. etc. 3) ACL2 will not attempt to support any other existing access control models either [this is my big concession]; this is unnecessary since there will be a separate lightweight access control mechanism [this is your big concession]. 4) The design of the lightweight mechanism should not preclude a server implementation being able to support both lightweight and ACL2. Conceivably, a server might be able to support ACL too. 5) There should be some guidelines for mappings right from one to the other, but it should be understood from the onset that the mapping is focused on: . users who use one form exclusively . users upgrading from lightweight (or ACL) to ACL2 In particular, a downgrade *will* be lossy. Life is tough. 6) Precise mapping details, such as the lightweight mapping of "s" or "t", will be left up to the server implementation. 7) Lightweight will have read/write/list rights. It will also have groups. Details to be determined. What you proposed was too minimal. -- 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.10/8.12.8) with ESMTP id hBAMJcib063365 for ; Wed, 10 Dec 2003 14:19:38 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBAMJcsc063364 for ietf-imapext-bks; Wed, 10 Dec 2003 14:19:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAMJbib063359 for ; Wed, 10 Dec 2003 14:19:37 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBAMJb6s001106 for ; Wed, 10 Dec 2003 17:19:37 -0500 Date: Wed, 10 Dec 2003 17:19:37 -0500 (EST) From: Rob Siemborski To: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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: I realize I probably originally posted this at a bad time, directly after everyone was returning from the IETF meeting... But are there further comments/compliments/flames? Is this something we are interested in pursuing or are we too far down our current path already? -Rob On Fri, 14 Nov 2003, Rob Siemborski wrote: > > After the IMAPext meeting I spoke with some people and got to thinking if > there was a way we could come up with a way to do IMAP sharing that will > satisfy both the enterprise people who need detailed ACL support, and those > who feel the need to implement permissions with limited backend support > (e.g. UNIX file permissions). Ideally, such a mechanism would be simple to > implement and not have complexity problems getting past the IESG. > > I'd like to propose the following as a strawman INSTEAD of the > current ACL2 draft (or whatever ACL2 became after the last round of > comments): > > Create an ACL+ capability that does the following: > > * Can only be advertised if ACL is advertised > * adds the x (DELETE mailbox), t (set \Deleted), and e (EXPUNGE) > bits to ACL, and redefines the 'd' bit to "x && t && e" (like ACL2) > > There may be other changes from ACL2 that I missed here, but the general > goal is "do the minimum required to fix ACL". This may imply changing how > the namespace of identifiers are treated as well (e.g. user=foo, > group=bar), but I'd really like to keep the changes as minimal as possible > here if we can. > > Create a new PERMISSIONS capability that works along the lines of the > following: > > * Define four bits you can set on a mailbox: owner read/write and > anyone read/write. Have a command other than the ACL manipulation > commands that can manipulate/report these. > > If a server advertises *both* PERMISSIONS and ACL, then it must also > advertise ACL+. Also, the PERMISSIONS bits are tied as follows to ACL > bits for the *owner* of a mailbox and for the "anyone" identifier (in the > ACL): > > On a mailbox that can contain messages: > read: lr > write: wite > > (I'm not sure how to tie 's' -- maybe Mark can answer that). > > On a mailbox that can contain mailboxes: > read: l > write: cx > > "Dual-use" mailboxes get the union of the applicable above sets of bits. > > Identifiers in the ACL that correspond to entities other than the > owner and 'anyone' are not advertised through the permissions extension. > > Note that in a ACL+PERMISSIONS system, the rights advertised through the > PERMISSIONS extension are exactly the rights that match the owner's identifier > and the "anyone" identifier. Negative rights are not advertised through, > the PERMISSIONS system. When resolving actual rights, the ACL must be fully > calculated (i.e. the PERMISSIONS interface is just an alternate way to get > to *some* of the functionality of ACL). > > Note also that this does not tie 'a' or 'p' to anything, > I would expect the PERMISSIONS extension to honor 'a', and I would expect > 'p' to only be manipulatable through the ACL extension, though perhaps that > isn't quite the right thing. > > If a server implements *only* PERMISSIONS and does not implement ACL, then it > should keep the semantics that would be provided by the ACL bits as > defined above for each PERMISSIONS bit (and implicitly grant 'a' to the owner). > However, in this case, the bits advertised through PERMISSIONS *are* > authoritative. > > I think that this setup is significantly simpler than having to bend over > backwards to force ACLs onto unix filesystem semantics just to allow simple > folder sharing, and it still allows enterprise servers to continue to > support the flexibility provided by the ACL extension. > > I've intentionally left some things open here: specifically interaction > with LISTEXT and the exact syntax of how PERMISSIONS would look on the wire. > I have also left open the question of interpreting the ACL (rather, I left > it as it was in 2086). The syntax question, at least, could be worked out when > a formal draft was issued. > > I will note that this does not provide for groups to be used through the > PERMISSIONS mechanism. However, it seems to me that the large demand > is "share folders globally", and this provides for that. > > This would also provide a simple standard mapping for "read" and "write" > acls to mailboxes, which sees to also have been in demand. > > Comments? > > -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----- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.10/8.12.8) with ESMTP id hB8J4uib051551 for ; Mon, 8 Dec 2003 11:04:56 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8J4ufH051548 for ietf-imapext-bks; Mon, 8 Dec 2003 11:04:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8J4sib051530 for ; Mon, 8 Dec 2003 11:04:55 -0800 (PST) (envelope-from apache@asgard.ietf.org) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1ATQee-0008QP-ID; Mon, 08 Dec 2003 14:02:48 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Subject: Protocol Action: 'IMAP Extension for Conditional STORE operation' to Proposed Standard Message-Id: Date: Mon, 08 Dec 2003 14:02:48 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved following document: - 'IMAP Extension for Conditional STORE operation ' as a Proposed Standard This document is the product of the Internet Message Access Protocol Extension Working Group. The IESG contact persons are Ned Freed and Ted Hardie. Technical Summary Often, multiple IMAP clients need to coordinate changes to a common IMAP mailbox. Examples include different clients for the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags or annotations) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. Working Group Summary This document is a product of the imapext working group. Protocol Quality Ned Freed reviewed the specification for the IESG. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5KT9ib064916 for ; Fri, 5 Dec 2003 12:29:09 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5KT90t064915 for ietf-imapext-bks; Fri, 5 Dec 2003 12:29:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5KT7ib064910 for ; Fri, 5 Dec 2003 12:29:08 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23584; Fri, 5 Dec 2003 15:28:54 -0500 (EST) Message-Id: <200312052028.PAA23584@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Cc: ietf-imapext@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-siemborski-imap-sasl-initial-response-02.txt Date: Fri, 05 Dec 2003 15:28:53 -0500 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. Title : IMAP Extension for SASL Initial Client Response Author(s) : R. Siemborski Filename : draft-siemborski-imap-sasl-initial-response-02.txt Pages : 8 Date : 2003-12-5 To date, the Internet Message Access Protocol (IMAP) has used a Simple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round trip costs are high. This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-siemborski-imap-sasl-initial-response-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-siemborski-imap-sasl-initial-response-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-siemborski-imap-sasl-initial-response-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: <2003-12-5150709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-siemborski-imap-sasl-initial-response-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-siemborski-imap-sasl-initial-response-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-5150709.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4Kchib022594 for ; Thu, 4 Dec 2003 12:38:43 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB4Kch2q022593 for ietf-imapext-bks; Thu, 4 Dec 2003 12:38:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4Kcbib022586 for ; Thu, 4 Dec 2003 12:38:40 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13368; Thu, 4 Dec 2003 15:38:24 -0500 (EST) Message-Id: <200312042038.PAA13368@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-14.txt Date: Thu, 04 Dec 2003 15:38:23 -0500 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 AND THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-sort-14.txt Pages : 19 Date : 2003-12-4 This document describes the base-level server-based sorting and threading extensions to the [IMAP] protocol. These extensions provide substantial performance improvements for IMAP clients which offer sorted and threaded views. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-14.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-sort-14.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-14.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: <2003-12-4154756.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-4154756.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1KTUib005935 for ; Mon, 1 Dec 2003 12:29:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1KTUZ3005934 for ietf-imapext-bks; Mon, 1 Dec 2003 12:29:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1KTSib005929 for ; Mon, 1 Dec 2003 12:29:29 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27140; Mon, 1 Dec 2003 15:29:16 -0500 (EST) Message-Id: <200312012029.PAA27140@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-condstore-05.txt Date: Mon, 01 Dec 2003 15:29:16 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP Extension for Conditional STORE operation Author(s) : A. Melnikov, S. Hole Filename : draft-ietf-imapext-condstore-05.txt Pages : 16 Date : 2003-12-1 Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalfof the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags or annotations) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. This document defines an extension to IMAP (RFC 3501). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-condstore-05.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-condstore-05.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: <2003-12-1152204.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-condstore-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-condstore-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-1152204.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBU8Ojib011662 for ; Tue, 30 Dec 2003 00:24:45 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBU8OjSi011660 for ietf-imapext-bks; Tue, 30 Dec 2003 00:24:45 -0800 (PST) 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.10/8.12.8) with ESMTP id hBU8Oiib011648 for ; Tue, 30 Dec 2003 00:24:44 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBU8Ob9n019176; Tue, 30 Dec 2003 00:24:43 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBU8ObCh012455; Tue, 30 Dec 2003 00:24:37 -0800 Date: Tue, 30 Dec 2003 00:24:37 -0800 (PST) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Mon, 29 Dec 2003, Rob Siemborski wrote: > What if the client is accessing two servers -- one which does not support > ACL? Well, then, presumably he has no choice but to use PERMISSIONS on that server. But he wouldn't be using PERMISSIONS and ACL simultaneously on the same server. -- 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.10/8.12.8) with ESMTP id hBTMd1ib017417 for ; Mon, 29 Dec 2003 14:39:01 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTMd1RS017416 for ietf-imapext-bks; Mon, 29 Dec 2003 14:39:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTMd0ib017410 for ; Mon, 29 Dec 2003 14:39:00 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBTMcxl4008881; Mon, 29 Dec 2003 17:38:59 -0500 Date: Mon, 29 Dec 2003 17:38:59 -0500 (EST) From: Rob Siemborski To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Mon, 29 Dec 2003, Mark Crispin wrote: > Well, you saw an explanation about how that can be done in Timo's message. Yes -- I'm pretty sure now I misunderstood what you meant. > But there aren't any such protocols! And once you go down that path, then > you get into the obvious question of why IMAP is even in the ACL business. LDAP, atleast, has been used for group management. Certainly a directory makes more sense to store this information in than a mail store. > > I'd also call it a disadvantage that now a server that wants to implement > > ACL has to implement another orthogonal scheme which is similar to ACL in > > complexity. > > No, PERMISSIONS is much smaller. [snip] Ok, we were talking about two entirely different PERMISSIONS descriptions. Now I have a clear(er) picture of yours. I'm going to think this over now. > A user who normally manipulates access control would typically use either > PERMISSIONS or ACL, but would not use both. Or, put another way, anyone > who does use both deserves to lose as punishment for his foolishness. What if the client is accessing two servers -- one which does not support ACL? -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+++ X- R@ tv-- b+ DI+++ D++ 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.10/8.12.8) with ESMTP id hBTMYAib017215 for ; Mon, 29 Dec 2003 14:34:10 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTMYABv017214 for ietf-imapext-bks; Mon, 29 Dec 2003 14:34:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTMY8ib017208 for ; Mon, 29 Dec 2003 14:34:09 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout6.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBTMY4lo023623; Mon, 29 Dec 2003 14:34:09 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBTMY4NY029221; Mon, 29 Dec 2003 14:34:04 -0800 Date: Mon, 29 Dec 2003 14:34:04 -0800 (PST) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Mon, 29 Dec 2003, Rob Siemborski wrote: > But here we're not talking about ACL2 -- we're talking about the upgrade > path from ACL to ACL2. We're currently *in* a world where there are > deployments with different groups with different rights on a folder, and > that needs to be dealt with. If that means we need to have both UNION and > MOST-SPECIFIC, that's fine with me. Well, you saw an explanation about how that can be done in Timo's message. > I don't think that it is reasonable to expect the IMAP server to be even > capable of manipulating groups -- leave that to protocols that have been > designed for that sort of thing. But there aren't any such protocols! And once you go down that path, then you get into the obvious question of why IMAP is even in the ACL business. > I'd also call it a disadvantage that now a server that wants to implement > ACL has to implement another orthogonal scheme which is similar to ACL in > complexity. No, PERMISSIONS is much smaller. Think of there being only four identifiers (in the RFC 2086 sense): owner, group, world, and anonymous. The anonymous user is stuck in anonymous. Otherwise, if your userid is in the owner list, then you get owner rights. Otherwise, if your userid is a member of a group that is in the group list, then you get group rights. Otherwise, you get world rights. There are tools to manager the owner list, group list, and membership within a group. Some of these tools may be restricted to admins. > Clients then have to interpret both of these unrelated > schemes to figure out what is going on. No. Not normally, anyway. A client would not normally be using the ACL commands if the user is not someone who normally manipulates ACLs for that mailbox (the "owner" in the PERMISSIONS world). A user who normally manipulates access control would typically use either PERMISSIONS or ACL, but would not use both. Or, put another way, anyone who does use both deserves to lose as punishment for his foolishness. The missing piece of the equation is "how does a non-owner" know whether or not he can do something? *That* is done in one of two ways: either by trying it to see if it works, *OR* by doing an access control CHECK operation. The access control check operation ("can I do t to such-and-such mailbox") is something that is common to both PERMISSIONS and ACL. Fortunately, access control check is less complicated than trying to represent PERMISSIONS in ACL or ACL in PERMISSIONS, since access control check is merely a binary "yes or no" to the question "will such-and-such win?". -- 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.10/8.12.8) with ESMTP id hBTM88ib015801 for ; Mon, 29 Dec 2003 14:08:08 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTM88jZ015800 for ietf-imapext-bks; Mon, 29 Dec 2003 14:08:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from danu.procontrol.fi (kone17.procontrol.vip.fi [212.149.71.178]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTM86ib015793 for ; Mon, 29 Dec 2003 14:08:07 -0800 (PST) (envelope-from tss@iki.fi) Received: by danu.procontrol.fi (Postfix, from userid 106) id 487AA238AD; Tue, 30 Dec 2003 00:08:00 +0200 (EET) Received: from [192.168.10.209] (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189]) by danu.procontrol.fi (Postfix) with ESMTP id 8D85D23866; Tue, 30 Dec 2003 00:07:26 +0200 (EET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v609) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-7--60835413" Message-Id: <621DD0CF-3A4B-11D8-9E05-000393CC2E90@iki.fi> Content-Transfer-Encoding: 7bit Cc: Mark Crispin , ietf-imapext@imc.org From: Timo Sirainen Subject: Re: Yet another ACL Strawman Date: Tue, 30 Dec 2003 00:07:25 +0200 To: Rob Siemborski X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.609) X-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_APPLEMAIL autolearn=ham version=2.54 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-7--60835413 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Dec 29, 2003, at 11:24 PM, Rob Siemborski wrote: > On Mon, 29 Dec 2003, Mark Crispin wrote: > >> And it seems that the problem is brought about *not* by most-specific >> between user vs. group vs. world identifiers, but rather by >> most-specific >> between groups with different rights. That's a design wart in ACL2 >> that >> bears looking into. > > But here we're not talking about ACL2 -- we're talking about the > upgrade > path from ACL to ACL2. We're currently *in* a world where there are > deployments with different groups with different rights on a folder, > and > that needs to be dealt with. If that means we need to have both UNION > and > MOST-SPECIFIC, that's fine with me. I'm not sure if you really understood what Mark said.. It anyway sounds to me like a quite workable solution. You'd have MOST-SPECIFIC behaviour but if there's multiple groups, you'd get union of them. Wouldn't that make it possible to quite easily convert old ACLs to ACL2? You can keep your old groups, only problems are if you have combined user, group and world rights. Then you'd have to do something like: user + world: merge world rights directly to user user + group(s): merge group rights directly to user group(s) + world: create a new "world" group and give world rights to world group Other combinations would work the same way as they did with ACL. --Apple-Mail-7--60835413 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/8KWdyUhSUUBViskRAp6vAKCkbwFHYfubMYDNo/r66MoiNWUHtACfWdXc aizq8mBkYBU99chj0CuKOB4= =hQS6 -----END PGP SIGNATURE----- --Apple-Mail-7--60835413-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTLOmib012863 for ; Mon, 29 Dec 2003 13:24:50 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTLOmJo012862 for ietf-imapext-bks; Mon, 29 Dec 2003 13:24:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTLOkib012857 for ; Mon, 29 Dec 2003 13:24:47 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBTLOkl4008825; Mon, 29 Dec 2003 16:24:46 -0500 Date: Mon, 29 Dec 2003 16:24:46 -0500 (EST) From: Rob Siemborski To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Mon, 29 Dec 2003, Mark Crispin wrote: > And it seems that the problem is brought about *not* by most-specific > between user vs. group vs. world identifiers, but rather by most-specific > between groups with different rights. That's a design wart in ACL2 that > bears looking into. But here we're not talking about ACL2 -- we're talking about the upgrade path from ACL to ACL2. We're currently *in* a world where there are deployments with different groups with different rights on a folder, and that needs to be dealt with. If that means we need to have both UNION and MOST-SPECIFIC, that's fine with me. The proposal was more or less an attempt to try an alternative/minimal approach. It seems that in order to keep everyone happy feature-wise we are better off (however bad it is) with ACL2 and some sort of way to announce how identifiers interact. > Perhaps matters would be easier if you discuss how you implement groups in > RFC 2086. As I read RFC 2086, it's a complete crapshoot how groups work > in ACL, so a client really has no idea what a "group" is. In our implementation, group management isn't done internally, instead we pull group membership from one of any number of sources (UNIX groups, AFS ptserver, LDAP, etc). This tends to work well since it ensures that group management is located in a single place for any given enterprise, and many applications can share the same groups. I don't think that it is reasonable to expect the IMAP server to be even capable of manipulating groups -- leave that to protocols that have been designed for that sort of thing. > No. I mean that PERMISSIONS is a separate layer. If you have PERMISSIONS > access, you get it. ACLs are only consulted if you don't have PERMISSIONS > access. The implication of this is that the use of ACLs requires denial > of all permissions (setting PERMISSIONS rights to none). Ok -- I understand what you are saying now. > The disadvantage of this is that a PERMISSIONS only client won't show > anything reasonable with server mailboxes that use ACL. I consider this > to be a small price to pay to gain the simplicity. I'd also call it a disadvantage that now a server that wants to implement ACL has to implement another orthogonal scheme which is similar to ACL in complexity. Clients then have to interpret both of these unrelated schemes to figure out what is going on. This is far from ideal from a management perspective. This is far worse than even the complicated scheme using regular expressions that the most recent ACL2 thread came up with. -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+++ X- R@ tv-- b+ DI+++ D++ 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.10/8.12.8) with ESMTP id hBTL9kib011983 for ; Mon, 29 Dec 2003 13:09:46 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTL9kD7011982 for ietf-imapext-bks; Mon, 29 Dec 2003 13:09:46 -0800 (PST) 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.10/8.12.8) with ESMTP id hBTL9jib011977 for ; Mon, 29 Dec 2003 13:09:45 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBTL9jsr014894; Mon, 29 Dec 2003 13:09:45 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBTL9jJf024021; Mon, 29 Dec 2003 13:09:45 -0800 Date: Mon, 29 Dec 2003 13:09:45 -0800 (PST) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Mon, 29 Dec 2003, Rob Siemborski wrote: > Which has a similar problem for ongoing manageability (I want to remove a > user from my admins group -- now I have to go through and fix ALL of these > folders? You've got to be kidding me!). And having an admins group *is* > used in practice. Uh, excuse me. I did say something about the need to be able to manage the membership of a group. And it seems that the problem is brought about *not* by most-specific between user vs. group vs. world identifiers, but rather by most-specific between groups with different rights. That's a design wart in ACL2 that bears looking into. Perhaps matters would be easier if you discuss how you implement groups in RFC 2086. As I read RFC 2086, it's a complete crapshoot how groups work in ACL, so a client really has no idea what a "group" is. > > Who said anything about limiting PERMISSIONS to only one user? I > > certainly never thought that "owner" equated to a single user; rather, > > owner equates to one or more users with owner rights. > The most recent strawman linked it to a single user identifier in the ACL > realm. That's not my strawman, and a single user identifier is not good enough. > Unless you're saying my position is that "PERMISSIONS is a strict subset > of ACL" which I *do* think is a good thing, because it ensures that > servers that implement ACL can implement PERMISSIONS as well (as > PERMISSIONS exists to enable servers that cannot implement ACL to still > have a rights management scheme). I think that your making PERMISSIONS a strict subset of ACL is what is causing the confusion. See next paragraph. > > If necessary, I'd be ameniable to a compromise in which use of ACL > > requires that all PERMISSIONS be denied. That's been done before. > I'm not sure what you mean here. Do you mean an ACL server refuses to > support any PERMISSIONS commands, or something else? No. I mean that PERMISSIONS is a separate layer. If you have PERMISSIONS access, you get it. ACLs are only consulted if you don't have PERMISSIONS access. The implication of this is that the use of ACLs requires denial of all permissions (setting PERMISSIONS rights to none). The disadvantage of this is that a PERMISSIONS only client won't show anything reasonable with server mailboxes that use ACL. I consider this to be a small price to pay to gain the simplicity. > No, I'm worried that the complexity of multiple users/groups will just > make PERMISSIONS "ACL with less bits" which is more or less useless, since > the "less bits" problem can be equally well solved with adequately defined > tied rights. A PERMISSIONS model which does less than the most limited access controls of the 1960s is also more or less useless. -- 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.10/8.12.8) with ESMTP id hBTJxZib007618 for ; Mon, 29 Dec 2003 11:59:35 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTJxZQJ007617 for ietf-imapext-bks; Mon, 29 Dec 2003 11:59:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTJxXib007612 for ; Mon, 29 Dec 2003 11:59:34 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from ASG1.WEB.cmu.edu (ASG1.WEB.cmu.edu [128.2.11.38]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBTJxXl4008748; Mon, 29 Dec 2003 14:59:33 -0500 Date: Mon, 29 Dec 2003 14:59:33 -0500 (EST) From: Rob Siemborski X-X-Sender: rjs3@asg1.web.cmu.edu To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Mon, 29 Dec 2003, Mark Crispin wrote: > On Mon, 29 Dec 2003, Rob Siemborski wrote: > > For example, let's say I have three groups: g1, g2, and g3. > > g1: u1, u2 ("readers") > > g2: u2, u3 ("writers") > > g3: u3, u4 ("baddies") > > And an ACL(1) on a folder of: > > g1: rls > > g2: wipcda > > g3: -rlswipcda > > Is a group of specifically restricted users (with a large set of negative > rights that denies world access) really in deployment today? Does CMU use > it? While I was using negative rights in the example, a similar problem exists with positive rights: g1: u1, u2 ("readers") g2: u2, u3 ("writers") g3: u1, u3, u4 ("admins") And an ACL(1) on a folder of: g1: rls g2: wipcd g3: a Results in a most-specific acl of: g1: rls g2: lwipcd g3: la u1: rlsa u3: lwipcda Which has a similar problem for ongoing manageability (I want to remove a user from my admins group -- now I have to go through and fix ALL of these folders? You've got to be kidding me!). And having an admins group *is* used in practice. I can't see anyone who uses groups heavily to want to upgrade from ACL to ACL2 if it meant that their ACLs would be destroyed in a non-backwards-compatible manner. > > If a PERMISSIONS server can support any number of groups, then you haven't > > created something "lightweight" you've reinvented ACL2 with only two (or > > three?) bits, and only one user arguments about PERMISSIONS as we're > > currently having about ACL2, only with far fewer features in the protocol. > > If you feel that ACL was over-engineered, I won't dispute that. Actually -- I feel it was under-engineered, given the problems it has with identifiers and the delete right. > > If its somehow ok to limit PERMISSIONS to only one user, it should also be > > OK to limit PERMISSIONS to no groups. > > Who said anything about limiting PERMISSIONS to only one user? I > certainly never thought that "owner" equated to a single user; rather, > owner equates to one or more users with owner rights. The most recent strawman linked it to a single user identifier in the ACL realm. > I am dismayed by the notion that the capabilities of PERMISSIONS are to be > dictated by ACL. Among other things, this opens the door to charges that > PERMISSIONS was deliberately sabotaged. I certainly feel that way when > you tell me what I can or can not have in PERMISSIONS. I don't think that PERMISSIONS is being sabotaged -- rather, I think we are conceding one sort of complexity (two rights management schemes) for reducing complexity in ACL (communicating a server's capability). Unless you're saying my position is that "PERMISSIONS is a strict subset of ACL" which I *do* think is a good thing, because it ensures that servers that implement ACL can implement PERMISSIONS as well (as PERMISSIONS exists to enable servers that cannot implement ACL to still have a rights management scheme). > If necessary, I'd be ameniable to a compromise in which use of ACL > requires that all PERMISSIONS be denied. That's been done before. I'm not sure what you mean here. Do you mean an ACL server refuses to support any PERMISSIONS commands, or something else? > > We certainly don't need to > > make the situation even worse by intrducing two extensions to do the same > > thing, except that one has fewer bits than the other. > > Are you worried that PERMISSIONS would be good enough that nobody would > implement ACL? No, I'm worried that the complexity of multiple users/groups will just make PERMISSIONS "ACL with less bits" which is more or less useless, since the "less bits" problem can be equally well solved with adequately defined tied rights. -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+++ X- R@ tv-- b+ DI+++ D++ 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.10/8.12.8) with ESMTP id hBTJjAib006904 for ; Mon, 29 Dec 2003 11:45:10 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTJjA72006903 for ietf-imapext-bks; Mon, 29 Dec 2003 11:45:10 -0800 (PST) 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.10/8.12.8) with ESMTP id hBTJj9ib006898 for ; Mon, 29 Dec 2003 11:45:09 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBTJj4sr006085; Mon, 29 Dec 2003 11:45:09 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBTJj4gk020477; Mon, 29 Dec 2003 11:45:04 -0800 Date: Mon, 29 Dec 2003 11:45:04 -0800 (PST) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Mon, 29 Dec 2003, Rob Siemborski wrote: > For example, let's say I have three groups: g1, g2, and g3. > g1: u1, u2 ("readers") > g2: u2, u3 ("writers") > g3: u3, u4 ("baddies") > And an ACL(1) on a folder of: > g1: rls > g2: wipcda > g3: -rlswipcda Is a group of specifically restricted users (with a large set of negative rights that denies world access) really in deployment today? Does CMU use it? RFC 2086 is very vague about groups. I don't see how you can hope to have something that's interoperable across all clients with RFC 2086. We put restricted users on restricted servers. > If a PERMISSIONS server can support any number of groups, then you haven't > created something "lightweight" you've reinvented ACL2 with only two (or > three?) bits, and only one user arguments about PERMISSIONS as we're > currently having about ACL2, only with far fewer features in the protocol. If you feel that ACL was over-engineered, I won't dispute that. > If its somehow ok to limit PERMISSIONS to only one user, it should also be > OK to limit PERMISSIONS to no groups. Who said anything about limiting PERMISSIONS to only one user? I certainly never thought that "owner" equated to a single user; rather, owner equates to one or more users with owner rights. I am dismayed by the notion that the capabilities of PERMISSIONS are to be dictated by ACL. Among other things, this opens the door to charges that PERMISSIONS was deliberately sabotaged. I certainly feel that way when you tell me what I can or can not have in PERMISSIONS. > If groups are necessary in a "lightweight" system, then this particular > strawman has basicly already lost, since that's the level of complexity > that is causing all sorts of trouble in ACL2. I disagree. PERMISSIONS should split the access control problem into two separate mechanisms, one of which is more featureful and the other of which is more likely to be universally implemented. It isn't as if this hasn't been done before, and successfully. The problem seems to come in when access control lists are proposed to be the only solution to the access control problem, and then everybody gets sidetracked on how ACLs are to be subsetted. If necessary, I'd be ameniable to a compromise in which use of ACL requires that all PERMISSIONS be denied. That's been done before. > We certainly don't need to > make the situation even worse by intrducing two extensions to do the same > thing, except that one has fewer bits than the other. Are you worried that PERMISSIONS would be good enough that nobody would implement ACL? -- 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.10/8.12.8) with ESMTP id hBTHopib000851 for ; Mon, 29 Dec 2003 09:50:51 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBTHop2I000850 for ietf-imapext-bks; Mon, 29 Dec 2003 09:50:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTHonib000844 for ; Mon, 29 Dec 2003 09:50:50 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBTHoll4008620; Mon, 29 Dec 2003 12:50:47 -0500 Date: Mon, 29 Dec 2003 12:50:48 -0500 (EST) From: Rob Siemborski To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Wed, 24 Dec 2003, Mark Crispin wrote: > > > . I contend that MOST-SPECIFIC should be the *only* access calculation > > > rule > > This makes it very hard or even impossible for a server to upgrade from > > ACL (using UNION). To do so, you would need to calculate the rights at a > > given moment in time, and then re-advertise them. > > I don't think that's really the case. The server should be able to > calculate the ACL2 equivalent of ACL rights fairly easily. Backwards > calculation will be harder to do reversibly, but the point is that we're > not trying to make that be perfect. Sure, you can calculate the rights quickly at any instant of time, but this fails if an organization has a long-standing use of union ACLs, and has allocated their groups accordingly. *Especially* if they manage them for other purposes. For example, let's say I have three groups: g1, g2, and g3. Their contents: g1: u1, u2 ("readers") g2: u2, u3 ("writers") g3: u3, u4 ("baddies") And an ACL(1) on a folder of: g1: rls g2: wipcda g3: -rlswipcda In ACL(2)/MOST-SPECIFIC [disregarind the d right], the server would upgrade this to: g1: rls g2: wipcda u2: rlswipcda u3: '' If you apply this across many folders, this can create a sudden management nightmare, since every user can suddenly have their own acl on every folder, destroying a standing group management policy (and effectively rendering the groups, which were designed with UNION style rights in mind, entirely useless). No, If ACL2 is to be adopted by current ACL sites, it needs to support *atleast* the current semantics. > > > 4) The design of the lightweight mechanism should not preclude a server > > > implementation being able to support both lightweight and ACL2. > > I would hope that any server implementing ACL2 would be able to trivially > > implement any sort of "lightweight" system. > > The difficulty would be expressing more complex ACL2 patterns in > lightweight. My answer is not to try to make it perfect. I offered a simple, unambiguous method to express this: an all-or-nothing approach. > > > 6) Precise mapping details, such as the lightweight mapping of "s" or "t", > > > will be left up to the server implementation. > > I think some rights are inherently tied though -- you wouldn't want a > > server that uses 'r' as a READ-WRITE right. > > Yes, of course. My point is that implementations should have latitude of > how they interpret lightweight WRITE in the context of "s", "t", and "w". This worries me somewhat, but I don't see any immediate problems with it from either a PERMISSIONS-only server (no concept of acl bits) or an ACL/PERMISSIONS shared server (you can always find out the real story by looking at the ACL). > > However, I fear that the use of groups in a "lightweight" system will just > > recreate the current ACL2 situation -- loads of complexity to deal with > > the fact that the lightweight system may not be able to handle more than > > one group. > > I don't think that there's a problem. A server, whether ACL2 or > lightweight, has the freedom to decide how many groups it supports; and > that number can be 1. If a PERMISSIONS server can support any number of groups, then you haven't created something "lightweight" you've reinvented ACL2 with only two (or three?) bits, and only one user arguments about PERMISSIONS as we're currently having about ACL2, only with far fewer features in the protocol. If its somehow ok to limit PERMISSIONS to only one user, it should also be OK to limit PERMISSIONS to no groups. If groups are necessary in a "lightweight" system, then this particular strawman has basicly already lost, since that's the level of complexity that is causing all sorts of trouble in ACL2. We certainly don't need to make the situation even worse by intrducing two extensions to do the same thing, except that one has fewer bits than the other. -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+++ X- R@ tv-- b+ DI+++ D++ 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.10/8.12.8) with ESMTP id hBSLEmib070678 for ; Sun, 28 Dec 2003 13:14:48 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBSLEmOo070677 for ietf-imapext-bks; Sun, 28 Dec 2003 13:14:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBSLElib070670 for ; Sun, 28 Dec 2003 13:14:47 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [10.0.2.4] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3) for ; Sun, 28 Dec 2003 15:14:44 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.1a7] Date: Sun, 28 Dec 2003 15:14:41 -0600 To: ietf-imapext@imc.org From: Pete Resnick Subject: Shall we meet in Seoul? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Who is going to be able to make it to Seoul? Do we have items about which we need to meet? Would a multicast session make a difference? pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBSLCIib070448 for ; Sun, 28 Dec 2003 13:12:18 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBSLCIaX070447 for ietf-imapext-bks; Sun, 28 Dec 2003 13:12:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBSLCHib070442 for ; Sun, 28 Dec 2003 13:12:17 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [10.0.2.4] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3) for ; Sun, 28 Dec 2003 15:12:15 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.1a7] Date: Sun, 28 Dec 2003 15:12:12 -0600 To: ietf-imapext@imc.org From: Pete Resnick Subject: IMAP URL update? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On the LEMONADE list, Alexey mentioned that some folks had been talking about an update to the IMAP URL spec (RFC 2192) which would, perhaps among other things, add syntax to allow byte ranges for partial messages. Is anyone currently working on that or planning to work on it? I would like to refer to it in a document I am working on for LEMONADE. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBOMcxib026277 for ; Wed, 24 Dec 2003 14:38:59 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBOMcxEv026276 for ietf-imapext-bks; Wed, 24 Dec 2003 14:38:59 -0800 (PST) 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.10/8.12.8) with ESMTP id hBOMcwib026270 for ; Wed, 24 Dec 2003 14:38:58 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBOMcrK4015791; Wed, 24 Dec 2003 14:38:58 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBOMcre1003238; Wed, 24 Dec 2003 14:38:53 -0800 Date: Wed, 24 Dec 2003 14:38:53 -0800 (PST) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Sat, 20 Dec 2003, Rob Siemborski wrote: > > Also, just as eliminating the need to support non-ACL access control > > models in ACL2 would simplify ACL2, so would the elimination of RFC 2086 > > compatibility. > I'm not convinced that this "simplifies" ACL2 much, other than eliminating > the need to tie the 'd' right. If we have PERMISSIONS as a separate entity from ACL2, we can eliminate tied rights in ACL2. That is, a server that implements ACL2 must implement all ACL2 rights as discreet entities. Given that ACL2 is "all or not at all", it can be made much simpler; and given that PERMISSIONS exists as a lighter-weight model, it's alright that ACL2 be "all or not all all". > > . I contend that MOST-SPECIFIC should be the *only* access calculation > > rule > This makes it very hard or even impossible for a server to upgrade from > ACL (using UNION). To do so, you would need to calculate the rights at a > given moment in time, and then re-advertise them. I don't think that's really the case. The server should be able to calculate the ACL2 equivalent of ACL rights fairly easily. Backwards calculation will be harder to do reversibly, but the point is that we're not trying to make that be perfect. > > 4) The design of the lightweight mechanism should not preclude a server > > implementation being able to support both lightweight and ACL2. > I would hope that any server implementing ACL2 would be able to trivially > implement any sort of "lightweight" system. The difficulty would be expressing more complex ACL2 patterns in lightweight. My answer is not to try to make it perfect. > > 6) Precise mapping details, such as the lightweight mapping of "s" or "t", > > will be left up to the server implementation. > I think some rights are inherently tied though -- you wouldn't want a > server that uses 'r' as a READ-WRITE right. Yes, of course. My point is that implementations should have latitude of how they interpret lightweight WRITE in the context of "s", "t", and "w". > However, I fear that the use of groups in a "lightweight" system will just > recreate the current ACL2 situation -- loads of complexity to deal with > the fact that the lightweight system may not be able to handle more than > one group. I don't think that there's a problem. A server, whether ACL2 or lightweight, has the freedom to decide how many groups it supports; and that number can be 1. Of greater concern is that some lightweight implementations may wish to support multiple groups, but have all groups have the same rights. I don't think that we really need to address this as long as the server announces the result of any changes. > If I change the group with the lightweight interface -- what happens in > the ACL/ACL2 representation? What if the ACL contains multiple groups? > What does the lightweight system report? I would do an end run around all of this and say that *any* lightweight changes immediately resets all ACL2 settings to reflect the lightweight setting. If you don't want this to happen to your acls, then don't use a lightweight interface to manipulate them ("doctor, it hurts when I do this"/"so don't do it!"). If you just access ACL2 settings through lightweight, then you'll get a "reasonable approximation". The presumption here is that a user will be lightweight or ACL2, but not both except for an upgrade of a lightweight user to an ACL2 user. So, we concentrate our attention on making upgrade be correct, but we don't worry too much about downgrade. -- 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.10/8.12.8) with ESMTP id hBKH7Oib098094 for ; Sat, 20 Dec 2003 09:07:24 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBKH7OsE098093 for ietf-imapext-bks; Sat, 20 Dec 2003 09:07:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBKH7Mib098088 for ; Sat, 20 Dec 2003 09:07:23 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBKH7Nk5009461 for ; Sat, 20 Dec 2003 12:07:23 -0500 Date: Sat, 20 Dec 2003 12:07:23 -0500 (EST) From: Rob Siemborski To: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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 Wed, 10 Dec 2003, Mark Crispin wrote: > I agree with the desire to "do the minimum required to fix ACL". I don't > think that it's quite as small as you'd like. In particular I don't think > that a "fix" to ACL would leave UNION as the only access calculation rule. I'm willing to discuss this, the initial proposal didn't address it at all, really. > Also, just as eliminating the need to support non-ACL access control > models in ACL2 would simplify ACL2, so would the elimination of RFC 2086 > compatibility. I'm not convinced that this "simplifies" ACL2 much, other than eliminating the need to tie the 'd' right. > 1) We all agree that RFC 2086 is broken. ACL is dead, long live ACL2 and > PERMISSIONS. I think we all agree that 2086 is broken now, or we wouldn't be talking about ACL2. > 2) ACL2 will not attempt to be compatible with RFC 2086. It should be a > redesign, and do what's right: > . I contend that MOST-SPECIFIC should be the *only* access calculation > rule, on the grounds that it makes ACLs easier for clients and users to > understand, and allows the removal of negative rights from the > specification. This makes it very hard or even impossible for a server to upgrade from ACL (using UNION). To do so, you would need to calculate the rights at a given moment in time, and then re-advertise them. If we needs MOST-SPECIFIC semantics in ACL2 for adoption, then we have to deal with having two rulesets -- not one. > . no "t" right. Redefine "d" instead. As long as we have tied rights, I don't think this is a serious concern. > 3) ACL2 will not attempt to support any other existing access control > models either [this is my big concession]; this is unnecessary since there > will be a separate lightweight access control mechanism [this is your big > concession]. Ok. > 4) The design of the lightweight mechanism should not preclude a server > implementation being able to support both lightweight and ACL2. I would hope that any server implementing ACL2 would be able to trivially implement any sort of "lightweight" system. > Conceivably, a server might be able to support ACL too. This is very desirable, but as long as a direct upgrade of existing ACLs could be made, it isn't a showstopper. > 5) There should be some guidelines for mappings right from one to the > other, but it should be understood from the onset that the mapping is > focused on: > . users who use one form exclusively > . users upgrading from lightweight (or ACL) to ACL2 > In particular, a downgrade *will* be lossy. Life is tough. I *think* the original proposal accepted this. (i.e. in PERMISSIONS+ACL2 there was a loss of information if you only looked at the PERMISSIONS data [no groups + tied rights], likewise with ACL+ACL2 [the d right was lossy]. > 6) Precise mapping details, such as the lightweight mapping of "s" or "t", > will be left up to the server implementation. I think some rights are inherently tied though -- you wouldn't want a server that uses 'r' as a READ-WRITE right. > 7) Lightweight will have read/write/list rights. It will also have > groups. Details to be determined. What you proposed was too minimal. I'm fine with r/w/l rights in the lightweight system. However, I fear that the use of groups in a "lightweight" system will just recreate the current ACL2 situation -- loads of complexity to deal with the fact that the lightweight system may not be able to handle more than one group. If I change the group with the lightweight interface -- what happens in the ACL/ACL2 representation? What if the ACL contains multiple groups? What does the lightweight system report? I think there are far too many questions if we do this, and if this is necessary, going to a PERMISSIONS+ACL2 system gains us nothing, and loses a LOT in on interoperability and complexity of the spec. I'd rather see ACL2 as it is now (modulo the recent round of comments) than see this system. The main benefit of the PERMISSIONS proposal is that it holds PERMISSIONS as a subset (owner, anyone) of the ACL -- there's no complicated mapping between the identifiers in the two systems for a server that implements both. -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+++ X- R@ tv-- b+ DI+++ D++ 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.10/8.12.8) with ESMTP id hBB3aNib079408 for ; Wed, 10 Dec 2003 19:36:23 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBB3aNw7079407 for ietf-imapext-bks; Wed, 10 Dec 2003 19:36:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBB3aMib079402 for ; Wed, 10 Dec 2003 19:36:22 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBB3aI4l023031; Wed, 10 Dec 2003 19:36:23 -0800 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.10+UW03.09/8.12.10+UW03.09) with ESMTP id hBB3aHvo024012 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 10 Dec 2003 19:36:18 -0800 Date: Wed, 10 Dec 2003 19:34:15 -0800 (Pacific Standard Time) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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: Hi Rob - I've meant to answer your message, but I've kept on putting it off. I observed some time ago that the issue isn't about ACL (access control lists) but rather about access control. Your proposal is a variation of something that I suggested quite some time ago, which is to have a lightweight form of access control (which you call PERMISSIONS), and ACL as a heavyweight form. A server could support both, so there would need to be some set of mapping and conflict resolution rules. At the time, this was opposed on the grounds that for many people, lightweight would be good enough and it would preclude the widespread deployment of ACL. I am willing to revisit the issue. However, I think that the people who want a lightweight form should define what is in (and more importantly, what is absent from!!) the lightweight form. I agree with the desire to "do the minimum required to fix ACL". I don't think that it's quite as small as you'd like. In particular I don't think that a "fix" to ACL would leave UNION as the only access calculation rule. Also, just as eliminating the need to support non-ACL access control models in ACL2 would simplify ACL2, so would the elimination of RFC 2086 compatibility. With this in mind, here's what I would consider a good alterative to the current ACL2 document: 1) We all agree that RFC 2086 is broken. ACL is dead, long live ACL2 and PERMISSIONS. 2) ACL2 will not attempt to be compatible with RFC 2086. It should be a redesign, and do what's right: . I contend that MOST-SPECIFIC should be the *only* access calculation rule, on the grounds that it makes ACLs easier for clients and users to understand, and allows the removal of negative rights from the specification. . no "t" right. Redefine "d" instead. . etc. etc. 3) ACL2 will not attempt to support any other existing access control models either [this is my big concession]; this is unnecessary since there will be a separate lightweight access control mechanism [this is your big concession]. 4) The design of the lightweight mechanism should not preclude a server implementation being able to support both lightweight and ACL2. Conceivably, a server might be able to support ACL too. 5) There should be some guidelines for mappings right from one to the other, but it should be understood from the onset that the mapping is focused on: . users who use one form exclusively . users upgrading from lightweight (or ACL) to ACL2 In particular, a downgrade *will* be lossy. Life is tough. 6) Precise mapping details, such as the lightweight mapping of "s" or "t", will be left up to the server implementation. 7) Lightweight will have read/write/list rights. It will also have groups. Details to be determined. What you proposed was too minimal. -- 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.10/8.12.8) with ESMTP id hBAMJcib063365 for ; Wed, 10 Dec 2003 14:19:38 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hBAMJcsc063364 for ietf-imapext-bks; Wed, 10 Dec 2003 14:19:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAMJbib063359 for ; Wed, 10 Dec 2003 14:19:37 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id hBAMJb6s001106 for ; Wed, 10 Dec 2003 17:19:37 -0500 Date: Wed, 10 Dec 2003 17:19:37 -0500 (EST) From: Rob Siemborski To: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman 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: I realize I probably originally posted this at a bad time, directly after everyone was returning from the IETF meeting... But are there further comments/compliments/flames? Is this something we are interested in pursuing or are we too far down our current path already? -Rob On Fri, 14 Nov 2003, Rob Siemborski wrote: > > After the IMAPext meeting I spoke with some people and got to thinking if > there was a way we could come up with a way to do IMAP sharing that will > satisfy both the enterprise people who need detailed ACL support, and those > who feel the need to implement permissions with limited backend support > (e.g. UNIX file permissions). Ideally, such a mechanism would be simple to > implement and not have complexity problems getting past the IESG. > > I'd like to propose the following as a strawman INSTEAD of the > current ACL2 draft (or whatever ACL2 became after the last round of > comments): > > Create an ACL+ capability that does the following: > > * Can only be advertised if ACL is advertised > * adds the x (DELETE mailbox), t (set \Deleted), and e (EXPUNGE) > bits to ACL, and redefines the 'd' bit to "x && t && e" (like ACL2) > > There may be other changes from ACL2 that I missed here, but the general > goal is "do the minimum required to fix ACL". This may imply changing how > the namespace of identifiers are treated as well (e.g. user=foo, > group=bar), but I'd really like to keep the changes as minimal as possible > here if we can. > > Create a new PERMISSIONS capability that works along the lines of the > following: > > * Define four bits you can set on a mailbox: owner read/write and > anyone read/write. Have a command other than the ACL manipulation > commands that can manipulate/report these. > > If a server advertises *both* PERMISSIONS and ACL, then it must also > advertise ACL+. Also, the PERMISSIONS bits are tied as follows to ACL > bits for the *owner* of a mailbox and for the "anyone" identifier (in the > ACL): > > On a mailbox that can contain messages: > read: lr > write: wite > > (I'm not sure how to tie 's' -- maybe Mark can answer that). > > On a mailbox that can contain mailboxes: > read: l > write: cx > > "Dual-use" mailboxes get the union of the applicable above sets of bits. > > Identifiers in the ACL that correspond to entities other than the > owner and 'anyone' are not advertised through the permissions extension. > > Note that in a ACL+PERMISSIONS system, the rights advertised through the > PERMISSIONS extension are exactly the rights that match the owner's identifier > and the "anyone" identifier. Negative rights are not advertised through, > the PERMISSIONS system. When resolving actual rights, the ACL must be fully > calculated (i.e. the PERMISSIONS interface is just an alternate way to get > to *some* of the functionality of ACL). > > Note also that this does not tie 'a' or 'p' to anything, > I would expect the PERMISSIONS extension to honor 'a', and I would expect > 'p' to only be manipulatable through the ACL extension, though perhaps that > isn't quite the right thing. > > If a server implements *only* PERMISSIONS and does not implement ACL, then it > should keep the semantics that would be provided by the ACL bits as > defined above for each PERMISSIONS bit (and implicitly grant 'a' to the owner). > However, in this case, the bits advertised through PERMISSIONS *are* > authoritative. > > I think that this setup is significantly simpler than having to bend over > backwards to force ACLs onto unix filesystem semantics just to allow simple > folder sharing, and it still allows enterprise servers to continue to > support the flexibility provided by the ACL extension. > > I've intentionally left some things open here: specifically interaction > with LISTEXT and the exact syntax of how PERMISSIONS would look on the wire. > I have also left open the question of interpreting the ACL (rather, I left > it as it was in 2086). The syntax question, at least, could be worked out when > a formal draft was issued. > > I will note that this does not provide for groups to be used through the > PERMISSIONS mechanism. However, it seems to me that the large demand > is "share folders globally", and this provides for that. > > This would also provide a simple standard mapping for "read" and "write" > acls to mailboxes, which sees to also have been in demand. > > Comments? > > -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----- > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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.10/8.12.8) with ESMTP id hB8J4uib051551 for ; Mon, 8 Dec 2003 11:04:56 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB8J4ufH051548 for ietf-imapext-bks; Mon, 8 Dec 2003 11:04:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB8J4sib051530 for ; Mon, 8 Dec 2003 11:04:55 -0800 (PST) (envelope-from apache@asgard.ietf.org) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1ATQee-0008QP-ID; Mon, 08 Dec 2003 14:02:48 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Subject: Protocol Action: 'IMAP Extension for Conditional STORE operation' to Proposed Standard Message-Id: Date: Mon, 08 Dec 2003 14:02:48 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved following document: - 'IMAP Extension for Conditional STORE operation ' as a Proposed Standard This document is the product of the Internet Message Access Protocol Extension Working Group. The IESG contact persons are Ned Freed and Ted Hardie. Technical Summary Often, multiple IMAP clients need to coordinate changes to a common IMAP mailbox. Examples include different clients for the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags or annotations) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. Working Group Summary This document is a product of the imapext working group. Protocol Quality Ned Freed reviewed the specification for the IESG. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5KT9ib064916 for ; Fri, 5 Dec 2003 12:29:09 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB5KT90t064915 for ietf-imapext-bks; Fri, 5 Dec 2003 12:29:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5KT7ib064910 for ; Fri, 5 Dec 2003 12:29:08 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23584; Fri, 5 Dec 2003 15:28:54 -0500 (EST) Message-Id: <200312052028.PAA23584@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Cc: ietf-imapext@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-siemborski-imap-sasl-initial-response-02.txt Date: Fri, 05 Dec 2003 15:28:53 -0500 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. Title : IMAP Extension for SASL Initial Client Response Author(s) : R. Siemborski Filename : draft-siemborski-imap-sasl-initial-response-02.txt Pages : 8 Date : 2003-12-5 To date, the Internet Message Access Protocol (IMAP) has used a Simple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round trip costs are high. This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-siemborski-imap-sasl-initial-response-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-siemborski-imap-sasl-initial-response-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-siemborski-imap-sasl-initial-response-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: <2003-12-5150709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-siemborski-imap-sasl-initial-response-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-siemborski-imap-sasl-initial-response-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-5150709.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4Kchib022594 for ; Thu, 4 Dec 2003 12:38:43 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB4Kch2q022593 for ietf-imapext-bks; Thu, 4 Dec 2003 12:38:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4Kcbib022586 for ; Thu, 4 Dec 2003 12:38:40 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13368; Thu, 4 Dec 2003 15:38:24 -0500 (EST) Message-Id: <200312042038.PAA13368@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-14.txt Date: Thu, 04 Dec 2003 15:38:23 -0500 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 AND THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-sort-14.txt Pages : 19 Date : 2003-12-4 This document describes the base-level server-based sorting and threading extensions to the [IMAP] protocol. These extensions provide substantial performance improvements for IMAP clients which offer sorted and threaded views. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-14.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-sort-14.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-14.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: <2003-12-4154756.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-4154756.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1KTUib005935 for ; Mon, 1 Dec 2003 12:29:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hB1KTUZ3005934 for ietf-imapext-bks; Mon, 1 Dec 2003 12:29:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1KTSib005929 for ; Mon, 1 Dec 2003 12:29:29 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27140; Mon, 1 Dec 2003 15:29:16 -0500 (EST) Message-Id: <200312012029.PAA27140@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-condstore-05.txt Date: Mon, 01 Dec 2003 15:29:16 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP Extension for Conditional STORE operation Author(s) : A. Melnikov, S. Hole Filename : draft-ietf-imapext-condstore-05.txt Pages : 16 Date : 2003-12-1 Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalfof the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags or annotations) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. This document defines an extension to IMAP (RFC 3501). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-condstore-05.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-condstore-05.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: <2003-12-1152204.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-condstore-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-condstore-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-1152204.I-D@ietf.org> --OtherAccess-- --NextPart--