Received: by ns.secondary.com (8.9.3/8.9.3) id TAA16756 for ietf-imapext-bks; Wed, 31 May 2000 19:53:54 -0700 (PDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA16746 for ; Wed, 31 May 2000 19:53:53 -0700 (PDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id UAA03189; Wed, 31 May 2000 20:01:36 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (ken@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id UAA16795; Wed, 31 May 2000 20:01:36 -0700 Date: Wed, 31 May 2000 19:48:09 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: Cyrus Daboo cc: ietf-imapext@imc.org In-Reply-To: <984053.3168775009@ip108.imc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 31 May 2000 15:16:49 -0700, Cyrus Daboo wrote: > >> 'The server SHOULD issue an untagged MYRIGHTS response > > I agree completely, but you can't do this in the RFC 2086 framework, > > because a base level IMAP client would complain about getting a MYRIGHTS > > response. > Not if its a resp-cond-state: > * OK [MYRIGHTS lrwia] myrights ACL response Well, yes and no. Yes, that is certainly valid in the base spec. No, because a resp-cond-status of MYRIGHTS is different from an RFC 2086 MYRIGHTS response. That seems to be splitting hairs, but it means we'd have two ways of doing the same response forever, unless the untagged MYRIGHTS response is deprecated in favor of the resp-cond-state. That might be a good idea, actually; it could be carried in the tagged OK response for the MYRIGHTS command and not use an untagged response at all. However, I still contend that leveraging off the LIST response would be a better idea. It could be useful for the client to get \NoInferiors state at SELECT time; and there's a lot more that could be delivered as well. There's another reason why I advocate a LIST response; I think that the current GETACL, LISTRIGHTS, and MYRIGHTS commands should be deprecated in favor of an extended form of LIST. That way, we could use wildcards, and avoid the current situation where a client does a LIST then a MYRIGHTS for each returned mailbox. PS: Ofhand observation: the interesting rights at SELECT time are lipca. The client can infer r from being able to select, and swd from PERMANENTFLAGS. Received: by ns.secondary.com (8.9.3/8.9.3) id TAA14085 for ietf-imapext-bks; Wed, 31 May 2000 19:38:41 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA14072 for ; Wed, 31 May 2000 19:38:39 -0700 (PDT) Received: from ip108.imc.org (host1.108.sjccnet.com [207.87.51.108]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id WAA14738; Wed, 31 May 2000 22:45:32 -0400 (EDT) Date: Wed, 31 May 2000 15:16:49 -0700 From: Cyrus Daboo To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Message-ID: <984053.3168775009@ip108.imc.org> In-Reply-To: X-Mailer: Mulberry/2.0.1b1 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, May 31, 2000 3:10 PM -0700 Mark Crispin wrote: >> 'The server SHOULD issue an untagged MYRIGHTS response (as a >> response-cond-state [IMAP4] response) when a client issues the SELECT or >> EXAMINE command for a mailbox when the ACL extension is present' > > I agree completely, but you can't do this in the RFC 2086 framework, > because a base level IMAP client would complain about getting a MYRIGHTS > response. Not if its a resp-cond-state: a SELECT INBOX ... ... * OK [MYRIGHTS lrwia] myrights ACL response a OK >From what I see in RFC2060 'resp_text_code' is designed so clients should accept data not defined in the base-spec. -- Cyrus Daboo Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA20282 for ietf-imapext-bks; Wed, 31 May 2000 16:30:16 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (jjs@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20278 for ; Wed, 31 May 2000 16:30:14 -0700 (PDT) Date: Wed, 31 May 2000 16:37:57 -0700 (PDT) From: Mark Crispin To: Steve Hole cc: John Gardiner Myers , ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt In-Reply-To: Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 29 May 2000, Steve Hole wrote: > I think that (2) (identifier theory) is where we are going to run aground. > A flexible identifier theory and semantic strikes me as being a strategy > much like flexible hierarchy notation. This scares me. Let's be clear on this. I don't intend that "UNIX owner" or "UNIX group" be defined as such in ACL. Rather, it should be possible to express these concepts as part of a general (not flexible!) mechanism. By general, I mean "a mechanism whose ideal state is full implementation" as opposed to "flexible" which means "a mechanism which expresses contradictory models, and therefore would never be fully implemented." Hierarchy is "flexible"; what I propose for identifiers is "general". My idea basically boils down to this: 1) a mechanism to define identifiers: global, per-mailbox, and perhaps also per-user (I don't need the last one, but perhaps other people do). Defined identifiers can be defined in terms of other defined identifiers. 2) a system of naming that makes the type of identifier unambiguous. 3) a mechanism to look up (expands) the definition of a defined identifier. The impact of this is: . definition of identifier nomenclature . command to define an identifier . command to get the definition of an identifier Note that there is no specific "change group" or "change owner"; however, the necessary functionality is there. The semantics of other existing ACL mechanisms can be done the same way. I also don't think that it's necessary for the specification to enshrine "owner" or "group" in the UNIX sense, but perhaps it may be good to document a particular convention for per-mailbox nomenclature of defined identifiers of these two. At the specification level, all that should matter is that these per-mailbox identifiers have ACLs; the per-mailbox identifier that corresponds to UNIX owner expands to one or more RFC 2086 user name identifiers, and the per-mailbox identifier that corresponds to UNIX group expands to a global defined identifier (which in turn expands to one or more RFC 2086 user name identifiers). Of course, the server is always permitted to respond NO to an operation which it does not agree to do. A separate issue is the lack of an identifier that includes everybody except for anonymous. Since excluding anonymous is the normal case, it doesn't really work well to have negative rights for anonymous on all ACLs. > It was collosal mistake to > select in favour of the "what the server is able to express" model for > hierarchy and we should not make the same mistake for ACL identifiers. I don't think that the example of hierarchy really applies here. In hierarchy, two models which were fundamentally hostile to each other were shoehorned together. In this case, we're talking about extensions to the existing framework that everybody can implement, and probably would want to implement. It is possible to implement RFC 2086 ACL in UNIX now (inheritance and the "c" right in the draft is a different matter). The problem is that the result isn't very useful and/or would give clients unpleasant surprises (e.g. implicit DELETEACL). I don't think that you want that. With these extensions, the only differences would be in what the server will say OK or NO to. You wouldn't have the \NoSelect or \NoInferiors which are specific to how a particular model works. There would be no "chgrp" operator, but there would be an operator that I would implement with chgrp() (and some other server would do it some other way). Received: by ns.secondary.com (8.9.3/8.9.3) id PAA19749 for ietf-imapext-bks; Wed, 31 May 2000 15:58:11 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (groves@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19745 for ; Wed, 31 May 2000 15:58:10 -0700 (PDT) Date: Wed, 31 May 2000 16:05:54 -0700 (PDT) From: Mark Crispin To: Steve Hole cc: John Gardiner Myers , ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt In-Reply-To: Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Inheritance (3) will be a very interesting discussion, but because > formalization of it is a "new thing" we *should* be able to converge on > that as well. My position is that it is better not to have inheritance at all rather than the definition in the draft. If you have inheritance, it is relatively simple to work around a lack of inheritance in the ACL specification. Otherwise, you need a complex specification of how inheritance works; either by being able to stipulate when inheritance happens or by having a priority mechanism which indicates when inheritance applies. The problem comes in with negative rights. Consider this example: a particular mailbox is open to anyone except those who are members of a particular group (overriding anyone inheritance with a negative right) but user fred who is in that group has access (overriding the group negative right). This is something that people want to do, and it's easy to do in UNIX. The draft makes it impossible; once a negative right is acquired through inheritance there's no way to lose it. I identified some missing functionality in inheritance, but I wouldn't be at all surprised if someone else finds other missing functionality. I don't think that it's possible to make a simple definition of inheritance that is going to have long-term viability. I contend that inheritance is a rathole, and an unnecessary one at that. If, on the other hand, there is no inheritance, then the problem doesn't exist. Even better, negative rights can also be deleted from the specification since all you need to do the equivalent is add an ACL for the identifier without that right. Received: by ns.secondary.com (8.9.3/8.9.3) id PAA19734 for ietf-imapext-bks; Wed, 31 May 2000 15:57:21 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (eon@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19730 for ; Wed, 31 May 2000 15:57:20 -0700 (PDT) Date: Wed, 31 May 2000 16:04:50 -0700 (PDT) From: Mark Crispin To: Steve Hole cc: John Gardiner Myers , ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt In-Reply-To: Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 29 May 2000, Steve Hole wrote: > (1) The interpretation of various rights identifiers. > (2) The definition/management of identifiers. > (3) Rights inheritance. I think that this is a good summary. Add a fourth issue: (4) Structure of ACL commands and (especially) responses. This relates to things such as issuing automatic ACL responses at SELECT time; the ability to have wildcards in mailbox names; the ability to replace the entire ACL and/or redefine ACL for multiple identifiers; the ability to query potential rights for multiple identifiers. > We have had trouble with (1) > ourselves and I think that it should be fairly easy to come to concensus > on. I hope so. Since rights tying exists, it would be better to add a new right rather than to overload existing rights with semantics that may not necessarily make sense to tie together. I'm thinking here about the "c" right, which should not be overloaded with "delete mailbox". Received: by ns.secondary.com (8.9.3/8.9.3) id PAA18578 for ietf-imapext-bks; Wed, 31 May 2000 15:02:49 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (trebor@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA18573 for ; Wed, 31 May 2000 15:02:47 -0700 (PDT) Date: Wed, 31 May 2000 15:10:30 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo cc: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt In-Reply-To: <483912.3168421931@groats115.ppp.andrew.cmu.edu> Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 27 May 2000, Cyrus Daboo wrote: > What I would like to see is a new REPLACEACL command that takes a mailbox > spec, similar to the LIST command, and a list of identifier-rights pairs. > This command would remove all the existing rights on the matching mailboxes > and then add all the rights specified in the command. This effectively > 'propagates' a set of rights to a group of mailboxes in a single command. Yes! This is one of the important operations I feel is missing in RFC 2086; the current SETACL is actually a "modify ACL" or "add ACL" as opposed to a "set ACL". It's one of the things that I want to do in ACLPLUS. > 'The server SHOULD issue an untagged MYRIGHTS response (as a > response-cond-state [IMAP4] response) when a client issues the SELECT or > EXAMINE command for a mailbox when the ACL extension is present' I agree completely, but you can't do this in the RFC 2086 framework, because a base level IMAP client would complain about getting a MYRIGHTS response. My idea in ACLPLUS is to deprecate all the existing RFC 2086 responses (basically, only in response to one of the RFC 2086 commands) in favor of extensions to the LIST response. The advantage with using the LIST response is that the base level specification already has the framework in place for such extensions; all you have to do are a few minor tweaks to the ACL responses to make them comply with that framework. Here's how the RFC 2086 response examples would look in ACLPLUS * ACL INBOX Fred rwipslda => * LIST (\NoInferiors \ACL:Fred=rwipslda) "" INBOX * LISTRIGHTS ~/Mail/saved smith la r swicd => * LIST (\NoInferiors \RIGHTS:smith=la_r_swicd) "" INBOX * MYRIGHTS INBOX => * LIST (\NoInferiors \MYRIGHTS=rwipslda) "" INBOX Of course, these could be combined in a single LIST response. This opens up the other pending issue of LIST command extensions, but I think that LIST responses can be extended independently. Received: by ns.secondary.com (8.9.3/8.9.3) id XAA14979 for ietf-imapext-bks; Mon, 29 May 2000 23:18:17 -0700 (PDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA14975 for ; Mon, 29 May 2000 23:18:15 -0700 (PDT) Received: from [192.168.124.95] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id IAA03096; Tue, 30 May 2000 08:24:37 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net Message-Id: In-Reply-To: References: Date: Tue, 30 May 2000 08:20:10 +0200 To: Pete Resnick , Mark Crispin From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: On the nature of WG discussion (Was: I-D ACTION:draft-ietf-imapext-acl-00.txt) Cc: ietf-imapext@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 00.25 -0500 00-05-30, Pete Resnick wrote: >Again, if the WG consensus is that we'd get more done if 2086 were >made Historic (and you may choose to try to convince the WG of >this), I'm perfectly happy to go to the IESG. Personally, at this >point I think it's a waste of time to pursue and we'd be better off >concentrating on what we want in the current ACL document. An RFC doesn't have to be made historic for "errors to be corrected". One can publish a new RFC which updates the older one, or replaces it. As Pete states, we have the IETF wide last call and the appeals process for exactly the reasons mentioned. FWIW: I do agree with Pete when he states that looking at the current document is what you should do. Patrik Area Director, Applications Area Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA12197 for ietf-imapext-bks; Mon, 29 May 2000 22:18:16 -0700 (PDT) Received: from episteme-software.com (resnick1.qualcomm.com [63.250.90.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA12187 for ; Mon, 29 May 2000 22:18:13 -0700 (PDT) Received: from resnick2.qualcomm.com (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.1d10); Tue, 30 May 2000 00:25:21 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 4.3.1b20-05.00] Date: Tue, 30 May 2000 00:25:20 -0500 To: Mark Crispin From: Pete Resnick Subject: On the nature of WG discussion (Was: I-D ACTION:draft-ietf-imapext-acl-00.txt) Cc: ietf-imapext@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think Steve Hole's last message is a good starting place for discussion of ACL issues; I hope discussion continues from there. However, there were some process points in Mark's message that I wanted to address: Though I thought about not saying anything, I think the answers are worth everyone's time so that we all understand how the work in this WG should go. On 5/26/00 at 11:40 AM -0700, Mark Crispin wrote: >Are you unaware that there is a team of people here at UW working on >email development? I'm speaking about the concerns of the entire >team. [...and...] >I don't think that you really mean to say that you go along with >whichever organization packs the meeting room with the most number >of its employees. First things first: Nobody in the WG can make claims to speak on behalf of larger entities. We are a gathering of individuals and we speak as such. That doesn't mean that you can't say things like "The folks I work with would really have an easier time implementing if the document did A instead of B" or "I've talked to some folks at XYZ company or university and they are really not going to like implementing A in their client." That's interesting information. However, talking about "our opinion of X" or saying "we think Y" without saying how you came to the conclusion that you are all of this one mind just isn't going to fly. On the flip side, organizations who try to pack the meeting room with employees aren't going to accomplish too much either. If I ask for the consensus of the room and I hear a lot of humming but not a lot of explanation of why a particular position is correct, and that humming all comes from a bunch of people working on the same implementation, I take it for what its worth, which amounts to about 1 person. This is about a consensus of technical opinion, not a count of heads. Of course, if two well reasoning people are disagree and one has done a widely deployed implementation and the other hasn't written a line of code, the former person will have a little more weight behind them. I hope both of these points are obvious, but I wanted to make sure that people understood where I am at. >>We have by no means had sufficient discussion IN THIS WORKING GROUP >>to determine whether your concerns *won't* be addressed. > >The past three and a half years worth of discussion is to be started >over from the beginning? No, but the content of previous discussions need to be brought into this WG and we need to see whether this particular gathering of folks (some of whom are new to the discussion) will turn in a different direction from the one that does not address your concerns. I think a very short period of time will tell. Now, a few things on this last section: >Will you request IESG to withdraw RFC 2086 from Proposed Standard >status, so that a clean start can be made? I won't request anything of the IESG at this point. First of all, I'm in no position personally to do that; I speak for the WG in this capacity. To that end, so far it seems that the WG wants the ACL draft to correct problems in 2086 and advance it. I have not heard from the WG that they want to move 2086 to Historical and start again with a new Proposed Standard. If I start to hear that, I will of course take that feedback to the IESG. >UW did not approve RFC 2086. It should never have gotten on standards-track. As far as I know, UW has no standing to approve or disapprove anything. Certainly no single person has approval power in the IETF, and organizations have no formal standing whatsoever. This kind of statement holds no weight with me at all. Now, certainly there was an IESG last call on 2086 before its release. If you and other folks you work with at UW thought that 2086 did not belong on the standards track for technical reasons, you had an opportunity to voice your opinion at that time. If you felt that your opinions were unjustly disregarded by the IESG, or that the approval was ram-rodded without having an opportunity to make your opinions known, there is a clear appeals process in the IETF. I do not think, however, that rehashing a 3 1/2-year old decision in this forum does anything to advance our work. Again, if the WG consensus is that we'd get more done if 2086 were made Historic (and you may choose to try to convince the WG of this), I'm perfectly happy to go to the IESG. Personally, at this point I think it's a waste of time to pursue and we'd be better off concentrating on what we want in the current ACL document. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA06341 for ietf-imapext-bks; Mon, 29 May 2000 13:54:29 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06337 for ; Mon, 29 May 2000 13:54:23 -0700 (PDT) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e4TL1pJ21750; Mon, 29 May 2000 15:01:51 -0600 From: Steve Hole Date: Mon, 29 May 2000 15:01:47 -0600 To: John Gardiner Myers Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Cc: ietf-imapext@imc.org In-Reply-To: <392EBA1A.91074F4F@netscape.com> References: <392EBA1A.91074F4F@netscape.com> Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 26 May 2000 10:53:30 -0700 John Gardiner Myers wrote: > > After much thought, confirmed by discussion at Adelaide, I've concluded > that Mark's concerns are best addressed by his pursuing a separate > extension. The models of access control are sufficiently different that > an extension trying to address both (or all) models will necessarily be > over complex and difficult to implement on the client side. Having read through the thead, I think Mark's proposals could be broken into three areas: (1) The interpretation of various rights identifiers. (2) The definition/management of identifiers. (3) Rights inheritance. I say think, because the discussion rolled out over several messages and it was hard to pull it together. I am sorry Mark if I have misrepresented or forgotten something. I would say the (1) and (3) are very germane to any ACL model and bear serious discussion for the draft at hand. We have had trouble with (1) ourselves and I think that it should be fairly easy to come to concensus on. Inheritance (3) will be a very interesting discussion, but because formalization of it is a "new thing" we *should* be able to converge on that as well. I think that (2) (identifier theory) is where we are going to run aground. A flexible identifier theory and semantic strikes me as being a strategy much like flexible hierarchy notation. This scares me. Putting on my client developer hat, I would opt for the "one true semantic" for identifiers. It just seems so much easier to implement and to create UI for. It is easier to explain to users. Of course, the definition for the "one true semantic" is up for discussion. We should not settle for a compromise the way we did last time, because it clearly led to interoperability problems. If the chain of events for folder hierarchy design repeats itself with ACL identifiers, then I expect that we will very quickly get to a discussion on what the "service is able to express" versus what the "client wants to see". I will be very clear about this. It was collosal mistake to select in favour of the "what the server is able to express" model for hierarchy and we should not make the same mistake for ACL identifiers. We should select for ease of use in the client in this situation. The model to be chosen can be debated, but there must be only one in the end. If may be true that there is a simple representation that has the flexibility required -- great! We won't know that until we have seen the various options. Mark. I encourage you to post the fragments of your proposal to the working group mailing list prior to posting a draft. It would be very useful to look at the specifics without waiting for the process. As you have noted, it has been too long already. I for one would be very interested in seeing the identifier model in some detail. I would also like to see the detailed discussion these three areas (or more if there are more) broken into separate threads. It is a little taxing to try to deal with the conceptual issues behind all three at once. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA05221 for ietf-imapext-bks; Mon, 29 May 2000 12:38:43 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05217 for ; Mon, 29 May 2000 12:38:41 -0700 (PDT) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e4TJjmJ21169; Mon, 29 May 2000 13:46:01 -0600 From: Steve Hole Date: Mon, 29 May 2000 13:45:44 -0600 To: Cyrus Daboo Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Cc: ietf-imapext@imc.org In-Reply-To: <483912.3168421931@groats115.ppp.andrew.cmu.edu> References: <483912.3168421931@groats115.ppp.andrew.cmu.edu> <200005251035.GAA02908@ietf.org> Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 27 May 2000 13:12:11 -0400 Cyrus Daboo wrote: > 9) One other behaviour that I would like to see added as a SHOULD > requirement on the server: > > 'The server SHOULD issue an untagged MYRIGHTS response (as a > response-cond-state [IMAP4] response) when a client issues the SELECT or > EXAMINE command for a mailbox when the ACL extension is present' This would be a *very* nice thing to do. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA26127 for ietf-imapext-bks; Sat, 27 May 2000 10:04:26 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26113 for ; Sat, 27 May 2000 10:04:17 -0700 (PDT) Received: from groats115.ppp.andrew.cmu.edu (GROATS115.PPP.ANDREW.CMU.EDU [128.2.61.115]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA06697 for ; Sat, 27 May 2000 13:10:52 -0400 (EDT) Date: Sat, 27 May 2000 13:12:11 -0400 From: Cyrus Daboo To: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Message-ID: <483912.3168421931@groats115.ppp.andrew.cmu.edu> In-Reply-To: <200005251035.GAA02908@ietf.org> X-Mailer: Mulberry/2.0.1b1 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here are some issues related to the ACL draft: 1) [IMAP4] reference points to RFC1730 but should point to RFC2060. 2) In section 3, the 'r' right should also be tied to the STATUS command. 3) Does not having the 'l' right mean that any mailbox operations are denied? For example if the 'l' right is missing, but the 'r' right is present, can a client still issue a SELECT on the mailbox? It might not 'see' the mailbox but it might know it exists. I think this needs to be made clear. Also how do the SUBSCRIBE and UNSUBSCRIBE commands tie in with this? Are they tied to the 'l' right or the 'r' right? 4) Since its possible to set flags in the APPEND command there needs to be a discussion of how the 'w' and 'i' bits interact, or at least the description for 'w' should also indicate that setting the flag via APPEND is also controlled via that right. 5) Right now 2060 mandates that a server send [READ-ONLY] or (optionally) [READ-WRITE] responses during a SELECT or EXAMINE. Which rights are these tied to? For example, if the 'w' write exists (i.e can change flags other than delete) but the 'd' right does not exist (can't delete or expunge) is the mailbox read-only or read-write? This actually affects the behaviour of non-ACL aware clients. ACL-aware clients are going to be smart enought to figure out the correct behaviour based on what the current users rights are to a mailbox, but non-ACL clients can only base their behaviour from the read-only/read-write responses. 6) As a reminder to implemetors, I think there needs to be a statement that the FLAGS and PERMANENTFLAGS responses as part of the SELECT command should accurately reflect the current user's rights. 7) I think the behaviour of the 'l' with respect to mailbox hierarchies needs to be explained more. Specifically what happens in the case where a user has the 'l' right to mailbox 'A/A' but not to mailbox 'A'? Should 'A/A' be returned in LIST or should the absence of the 'l' right on the parent mailbox allow a server to not bother looking for 'l' rights on the child mailboxes. 8) One thing that has come from our (now three years of) experience of doing ACLs in Mulberry is that users frequently want to take a set of ACLs on one mailbox and apply those to another mailbox, or mailboxes, e.g. 'propagation' of rights from one mailbox to its child hierarchy. Right now a client has to do this by issuing multiple DELETEACL and SETACL commands for each mailbox in the list. This is very inefficient. What I would like to see is a new REPLACEACL command that takes a mailbox spec, similar to the LIST command, and a list of identifier-rights pairs. This command would remove all the existing rights on the matching mailboxes and then add all the rights specified in the command. This effectively 'propagates' a set of rights to a group of mailboxes in a single command. 9) One other behaviour that I would like to see added as a SHOULD requirement on the server: 'The server SHOULD issue an untagged MYRIGHTS response (as a response-cond-state [IMAP4] response) when a client issues the SELECT or EXAMINE command for a mailbox when the ACL extension is present' I don't know about other clients, but we always issue a MYRIGHTS command after doing a SELECT or EXAMINE in order to figure out what UI items need to be enabled or disabled on the newly opened mailbox, e.g. enabling/disabling or certain flag commands based on the 'w' right. Having MYRIGHTS sent as an untagged response to SELECT or EXAMINE would remove the need for the extra command from the client. I would suggest that most ACL-aware clients are going to want MYRIGHTs on mailboxes they select so this would be a welcome change. -- Cyrus Daboo Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA13773 for ietf-imapext-bks; Fri, 26 May 2000 13:52:26 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (tbl@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13769 for ; Fri, 26 May 2000 13:52:25 -0700 (PDT) Date: Fri, 26 May 2000 11:40:53 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: Pete Resnick cc: ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 26 May 2000 13:18:13 -0500, Pete Resnick wrote: > As you no doubt know, the working group was only recently chartered. > There have been several things delayed because of that. I now fully > believe that we are moving along with work. I remain skeptical. I was extremely disappointed by the lack of progress in Oslo and DC. Not to mentioned being told, over and over again, that RFC 2086 is cast in stone, and that the only problem was my environment is "obsolete" and not worth worrying about. > >We were promised over a year ago that our concerns with ACL would be > >addressed. > Who is "we"? Are you unaware that there is a team of people here at UW working on email development? I'm speaking about the concerns of the entire team. > To date, the only person I have heard on these issues is > you. I don't think that you really mean to say that you go along with whichever organization packs the meeting room with the most number of its employees. > There was consensus in the room at Australia that requiring ACLs to > strictly conform to Unix semantics was potentially damaging to the > protocol and that we should stick to solving the problems in the > currently deployed base. Nobody ever said "require ACLs to strictly conform to Unix semantics". That's a strawman with no purpose other than to be burned down. If you want me to take this discussion seriously, don't use such strawmen. > We have by no means had sufficient > discussion IN THIS WORKING GROUP to determine whether your concerns > *won't* be addressed. The past three and a half years worth of discussion is to be started over from the beginning? > As far as we should all be concerned, the clock has only > now started ticking. Will you request IESG to withdraw RFC 2086 from Proposed Standard status, so that a clean start can be made? UW did not approve RFC 2086. It should never have gotten on standards-track. I've heard the excuse of "RFC 2086 is standards-track and it's too late to change the framework now" too many times in the past three years. There's no point in further discussion as long as that excuse remains. > I look forward to discussion of these items. If there are more > issues, bring them up now. OK: Other than inheritance and the problem with the "c" right, the system of rights is more or less acceptable. To recap: 1) there needs to be a "+" prefix (or suffix, I don't really care) which stipulates that the rights are to be inherited as described in the new I-D. Otherwise, another applicable identifier (e.g. the user name) can override the rights. Actually, the "+" means "mandatory application without override". The I-D insists that mandatory application is the only way, which means that there is no way to "disable access for everybody in a group except for one user". 2) Delete and rename mailbox needs to be separate; perhaps an "x" right since it insists upon this alphabet soup of one letter codes. A minor nit is the "d" right; it should not specify "perform EXPUNGE". But I think that I can just ignore that part without breaking things. Given that IMAP is so chatty otherwise and the ACL commands don't allow wildcards, the alphabet soup makes little sense; but since I plan to allow wildcards in ACLPLUS I'm willing to leave this alone. The primary problem with RFC 2086 is that the system of identifiers in ACLs is inflexible. We don't need a specific "change owner" and "change group" operation. We just need identifier semantics that can represent those operations. This is best done by a general purpose mechanism to define certain forms of identifiers, and to query the definition of an identifier. This new theory of identifiers is the beating heart of ACLPLUS. It defines the semantics of $xxx identifiers, and it adds two operators: one to define a $xxx identifier, and one to query its definition. Less important is a redesign of the commands and responses, with the RFC 2086 commands/responses retained for compatibility. The new commands and responses are considerably more powerful than RFC 2086. However, this is a completely secondary agenda; although it's a better design it's not crucial for the functionality. > Let's start with trying to address the issues in > the current framework and move on from there. The current framework is broken. I do not purpose to create a framework that is hopelessly biased towards another model. Instead, I purpose to create a framework that encompasses both models in a clean and well-defined manner. I've been told repeatedly that it is not possible, and shouldn't be done. It seems that the only way that I can prove otherwise is by doing it. > You releasing a competing draft at this point will > inevitably slow our work down, and potentially lead to the above > horrors. I'm sorry that's it's come to this, but I have yet to hear anything that will change it. > So, may > I assume that you put your work on hold until we have had some > further discussion in the WG? Unfortunately, the answer is no. It's been held off for three and a half years. That's long enough. I've been very patient. Unfortunately, it seems that the only way to make progress happen is for me to proceed. Until/unless there is concrete progress towards addressing our issues, , my work will proceed. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA12310 for ietf-imapext-bks; Fri, 26 May 2000 12:19:05 -0700 (PDT) Received: from netscape.com ([205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12306 for ; Fri, 26 May 2000 12:19:03 -0700 (PDT) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by netscape.com (8.8.5/8.8.5) with ESMTP id MAA21755 for ; Fri, 26 May 2000 12:18:58 -0700 (PDT) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (980427.SGI.8.8.8/8.8.5) with SMTP id MAA92219 for ; Fri, 26 May 2000 12:25:53 -0700 (PDT) To: ietf-imapext@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-imapext Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Date: Fri, 26 May 2000 12:25:42 -0700 Organization: Netscape Communications Corporation Lines: 78 Message-ID: <392ECFB6.6C28FBDE@netscape.com> References: <392EBA1A.91074F4F@netscape.com> NNTP-Posting-Host: 192.18.126.70 Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms076459EEC1E6830A8B1F22CE" X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms076459EEC1E6830A8B1F22CE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pete Resnick wrote: > Having 2 ACL extensions does not enhance interoperability. In this case, having two extensions can enhance interoperability. Part of the reason the ACL draft has been delayed is that Mark had comments I did not know how to address without creating an overcomplicated mess. Mark has stated that he wants to expose all semantics of Unix file permissions, including the "change owner" and "change group" operations. An extension that allows servers to expose all of the Unix file permission semantics and also allows servers to expose all of the ACL semantics implemented by the Cyrus server will also allow a whole range of intermediate semantics, with some aspects from Unix and some aspects from the original ACL. A conforming client would be required to be able to deal with all of these and would have a difficult time figuring out what the rules are on any particular server. Two extensions would cut out all of the intermediate states, simplifying clients and allowing them to know which type of server they are talking to. --------------ms076459EEC1E6830A8B1F22CE Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIQOjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05OTEyMTQwMDMxMTNaFw0wMDA2MTEwMDMxMTNa MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA pX1zWvGAZgDcMU3cID5cDySLcRzNT1eSwrBtUr42rYUra0h9yNeM5/1sTQ/w/dxCCD9uYYfq gIvDsbp37fH08MGDVHFStxvDDfkHApXjfQZeO/cocO/Is1RiNqh8rFab8IsyX7+enxrHA114 4MYJtJE39ykWfxys94/Raw4UfhMCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAFqbshBJHm+e8x8AZKU0v1WL01ws4lmvbNezMn/E6sgWW5F6vxH1JxceBlTI FgYmhlxCi7EUluFtL2P9ebVb1J2zfxNAgfmAGg4s9abErf1Zn3X/7kQgH8bO10QjLh7XjYpk I2z49gVR9IY/t0HE5qK5DEDamUyodBAivlTyq9W0MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIQOjAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDUyNjE5MjU0M1owIwYJKoZIhvcNAQkEMRYEFI/xeENA/A++ DyGaRvNKah73i/zOMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAKGls4BjZnVH7D/FZ5/iCYVKgLbyA0RAAITajp25W6k/s 9ZCSUzVudtgvGPbRo9OsOMov2MOj9CTlfUmIX9K2XMdpnZ2sQ0OhS5LR1chxKD9f5IHghCpM Q9SqEkv3q2JBr9RDZ8To87WypJOLOXnapoAY/2x0R6pLoGgYi6JPzXc= --------------ms076459EEC1E6830A8B1F22CE-- Received: by ns.secondary.com (8.9.3/8.9.3) id LAA11496 for ietf-imapext-bks; Fri, 26 May 2000 11:33:14 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (dchap@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11492 for ; Fri, 26 May 2000 11:33:13 -0700 (PDT) Date: Fri, 26 May 2000 11:28:24 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: John Gardiner Myers cc: ietf-imapext@imc.org In-Reply-To: <392EBA1A.91074F4F@netscape.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 26 May 2000 10:53:30 -0700, John Gardiner Myers wrote: > After much thought, confirmed by discussion at Adelaide, I've concluded > that Mark's concerns are best addressed by his pursuing a separate > extension. Thank you, John. Given that I purpose to create an upwards-compatible extension to RFC 2086, would you give careful consideration to the following in your I-D: 1) The two issues that I addressed in your latest I-D which will break compatibility (inheritance and the "c" right). I think that the change to inheritance in the I-D is a bad enough move that, if unfixed, it would accellerate the withering away of ACL in favor of ACLPLUS. The "c" right issue is less serious, but it would be a needless incompatibility. 2) Changing the defintion of $xxx to be "reserved" instead of the current poorly-defined "group". 3) Maintaining compatibility otherwise, so as not to preclude the possibility of a reunification. 4) Possible wording in your document that says that any capability that starts with ACL is compatible with ACL (e.g. what is done with SORT) to promote interoperability. > The models of access control are sufficiently different that > an extension trying to address both (or all) models will necessarily be > over complex and difficult to implement on the client side. As you should know by now, I strongly disagree with this conclusion. However, the only way that I can prove my position is by delivering the goods, and I shall proceed to do so. I believe that presently you'll find that the additions in ACLPLUS are sufficient desirable that you will decide to implement it after all. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA11082 for ietf-imapext-bks; Fri, 26 May 2000 11:11:24 -0700 (PDT) Received: from episteme-software.com (resnick1.qualcomm.com [63.250.90.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11077 for ; Fri, 26 May 2000 11:11:22 -0700 (PDT) Received: from resnick2.qualcomm.com (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.1d10); Fri, 26 May 2000 13:18:16 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 4.3.1b20-05.00] Date: Fri, 26 May 2000 13:18:13 -0500 To: Mark Crispin From: Pete Resnick Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Cc: ietf-imapext@imc.org 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 5/26/00 at 12:19 AM -0700, Mark Crispin wrote: >The working group has been ineffective up to now. The lack of >progress has been remarkable. As you no doubt know, the working group was only recently chartered. There have been several things delayed because of that. I now fully believe that we are moving along with work. Indeed, at each of the face-to-face meetings we have had as a BOF, we have made great progress on resolving many issues. >So have some rather crude politics; I'll remind you that IMAPEXT has >not even permitted the SORT and THREAD I-D's to come out with a >"draft-ietf-imapext" file name. Mark, as you full well know, given my message to you (which you replied to) of 8/18/99, message id , there were no crude politics involved here at all: As I explained, I was away on vacation when Natalia sent me the message asking whether these drafts could be under the working group. When I returned (the day I sent you the message), I sent her a message asking her to rename the drafts. I am quite sure that she would be happy to put them under the working group name if you resubmitted the documents. I think you should follow the general guideline that ad hominem attacks like this should be kept out of the working group discussions. If you want to accuse me of doing something malicious, take it to private mail. In this case, you are wrong in your assessment. >We were promised over a year ago that our concerns with ACL would be >addressed. Who is "we"? To date, the only person I have heard on these issues is you. One person does not a consensus make. If there are others involved here, I would like their comments to appear on the mailing list as well. >Yet, at the last IETF in Australia, the document editor stated that >those concerns weren't going to be addressed by ACL. There was consensus in the room at Australia that requiring ACLs to strictly conform to Unix semantics was potentially damaging to the protocol and that we should stick to solving the problems in the currently deployed base. However, if you have specific issues that you want addressed, either post them to the list or send them directly to the document editor. We have by no means had sufficient discussion IN THIS WORKING GROUP to determine whether your concerns *won't* be addressed. >The current document editor has stonewalled for three years. Time has run out. Nonsense. (1) I do not want these personal attacks in the working group. (2) The current document editor has only now gotten out the -00 draft. As far as we should all be concerned, the clock has only now started ticking. Now, you have identified two issues that the working group should address: >...mandatory rights inheritance, with no way to override an >inherited negative right >...overloading of "c" to mean "can create inferiors" and "can delete >this mailbox"... >I have offered suggestions for how these problems in the new I-D can >be resolved. I look forward to discussion of these items. If there are more issues, bring them up now. >Doing so would maintain some semblance of compatibility between ACL >and ACLPLUS. It would also keep the door open for a reunification. "Reunification" is not a desirable goal. The premise is "disunification". Let's start with trying to address the issues in the current framework and move on from there. >The design of ACLPLUS is almost finished. It will happen. I prefer >that IMAPEXT be willing to adopt these extensions into a single ACL >specification as optional ACL facilities. > >If not, there will be two specifications. This is exactly the kind of hostile stonewalling you are arguing we should not be doing. You are one voice among many. Make your voice heard and convince others that your concerns are valid. Do not attempt to strongarm people. It is destructive and has no place in this discussion. >If, on the other hand, the hostile stonewalling continues, we'll end >up with interoperability problems. We'll have egg on our collective >faces. The trade rags will have a field day. I agree. So let's stop. John has released his first draft. You have made comments. Both of those are constructive moves in the correct direction. You releasing a competing draft at this point will inevitably slow our work down, and potentially lead to the above horrors. Let's do some work over these next 2 months and see where we are, not change direction when we're barely out of the gate. >Even at this stage, it isn't too late; but time is running out. I'm glad to hear that at least you believe it isn't too late. So, may I assume that you put your work on hold until we have had some further discussion in the WG? >If there is a serious intention to resolve these differences >constructively, I am willing to arrange a face-to-face meeting with >the interested parties here in Seattle. Let's go on the assumption that there is a serious intention to resolve these differences constructively. We only have 2 months until we meet in Pittsburgh. Let us try to work through these issues on the list. If we cannot, we can use the face-to-face meeting in Pittsburgh to resolve differences. Is that acceptable? I have been on the road 5 of the past 9 weeks and I (and my significant other) would really prefer that I not travel between now and then. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA11078 for ietf-imapext-bks; Fri, 26 May 2000 11:11:22 -0700 (PDT) Received: from episteme-software.com (resnick1.qualcomm.com [63.250.90.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11073 for ; Fri, 26 May 2000 11:11:20 -0700 (PDT) Received: from resnick2.qualcomm.com (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.1d10); Fri, 26 May 2000 13:18:10 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <392EBA1A.91074F4F@netscape.com> References: <392EBA1A.91074F4F@netscape.com> X-Mailer: Eudora [Macintosh version 4.3.1b20-05.00] Date: Fri, 26 May 2000 13:18:08 -0500 To: John Gardiner Myers From: Pete Resnick Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Cc: ietf-imapext@imc.org 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 5/26/00 at 10:53 AM -0700, John Gardiner Myers wrote: >I've concluded that Mark's concerns are best addressed by his >pursuing a separate extension. I would like to hear further discussion on this point from other members of the working group. Having 2 ACL extensions does not enhance interoperability. My inclination is to try to get something that will satisfy both sets of concerns rather than have competing documents. If that can't be done to either side's satisfaction, we can revisit the issue later. However, Mark has made some comments on the document; I encourage him (and others) to make more. Let's see if there is consensus (either positively or negatively) on what to do about them before we start making decisions about new extensions. I can almost assure you that the IESG will not accept two ACL documents from this WG; my guess is that they won't accept any document while there are two competing documents in existence. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA10808 for ietf-imapext-bks; Fri, 26 May 2000 10:47:59 -0700 (PDT) Received: from netscape.com ([205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10804 for ; Fri, 26 May 2000 10:47:58 -0700 (PDT) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA09328 for ; Fri, 26 May 2000 10:46:54 -0700 (PDT) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (980427.SGI.8.8.8/8.8.5) with SMTP id KAA91719 for ; Fri, 26 May 2000 10:53:49 -0700 (PDT) To: ietf-imapext@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-imapext Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Date: Fri, 26 May 2000 10:53:30 -0700 Organization: Netscape Communications Corporation Lines: 64 Message-ID: <392EBA1A.91074F4F@netscape.com> References: NNTP-Posting-Host: 192.18.126.70 Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7F155AEDA087592CCD3AAFC5" X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms7F155AEDA087592CCD3AAFC5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit After much thought, confirmed by discussion at Adelaide, I've concluded that Mark's concerns are best addressed by his pursuing a separate extension. The models of access control are sufficiently different that an extension trying to address both (or all) models will necessarily be over complex and difficult to implement on the client side. Better each model have its own extension. Then the client will know which world the server is in and will not have to deal with hybrid models that don't exist in practice. --------------ms7F155AEDA087592CCD3AAFC5 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIQOjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05OTEyMTQwMDMxMTNaFw0wMDA2MTEwMDMxMTNa MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA pX1zWvGAZgDcMU3cID5cDySLcRzNT1eSwrBtUr42rYUra0h9yNeM5/1sTQ/w/dxCCD9uYYfq gIvDsbp37fH08MGDVHFStxvDDfkHApXjfQZeO/cocO/Is1RiNqh8rFab8IsyX7+enxrHA114 4MYJtJE39ykWfxys94/Raw4UfhMCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAFqbshBJHm+e8x8AZKU0v1WL01ws4lmvbNezMn/E6sgWW5F6vxH1JxceBlTI FgYmhlxCi7EUluFtL2P9ebVb1J2zfxNAgfmAGg4s9abErf1Zn3X/7kQgH8bO10QjLh7XjYpk I2z49gVR9IY/t0HE5qK5DEDamUyodBAivlTyq9W0MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIQOjAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDUyNjE3NTMzOVowIwYJKoZIhvcNAQkEMRYEFAu95Y51ldqR lq+Q57VNK2+Zs53EMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAbleK/VxoVuUFzjW4juH7ky96kYmRMi4kfcUoylcfsdGn zexibFEpvD4KtF3/bct39xbXTKzav5SDjIOuN0N9xIJZShM3Qink51s4dSV9qF3KBbj3+oBa Cu/l5eOMENtpYeCrjY3jQKKmghoQznv2wpM+wVYtcnhP0nlj8wr6i6A= --------------ms7F155AEDA087592CCD3AAFC5-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA11479 for ietf-imapext-bks; Fri, 26 May 2000 02:04:56 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (clane@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA11475 for ; Fri, 26 May 2000 02:04:55 -0700 (PDT) Date: Fri, 26 May 2000 00:19:01 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: Pete Resnick cc: Simon Josefsson , ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 26 May 2000 01:17:06 -0500, Pete Resnick wrote: > To do > so would undermine the effectiveness of the working group and would > leave the potential for huge interoperability problems in the future. Unfortunately, the time to have worried about this has passed. The working group has been ineffective up to now. The lack of progress has been remarkable. So have some rather crude politics; I'll remind you that IMAPEXT has not even permitted the SORT and THREAD I-D's to come out with a "draft-ietf-imapext" file name. We were promised over a year ago that our concerns with ACL would be addressed. Yet, at the last IETF in Australia, the document editor stated that those concerns weren't going to be addressed by ACL. > However, I strongly suggest that you not produce a different document > unless and until *both* (a) there is no sign of coming to an > agreement with the current document editor *and* (b) the working > group decides that we need another document to compare to. Unfortunately, this is no longer possible. The current document editor has stonewalled for three years. Time has run out. The working group can take the lead on our effort; it can follow our effort; or it can ignore our effort; but it can no longer stand in the way. I know what I would counsel, but it's your decision. The new I-D is much worse than RFC 2086. The requirement in the new I-D for mandatory rights inheritance, with no way to override an inherited negative right, is a non-starter and (in my opinion) a terrible idea. I can't believe that it is seriously proposed. It doesn't affect Cyrus; Cyrus doesn't have groups. It affects me to the point that it blocks my implementation. Similarly, overloading of "c" to mean "can create inferiors" and "can delete this mailbox" is also a non-starter. These are independent rights in my world. I can't implement this overloading. I have offered suggestions for how these problems in the new I-D can be resolved. Doing so would maintain some semblance of compatibility between ACL and ACLPLUS. It would also keep the door open for a reunification. The design of ACLPLUS is almost finished. It will happen. I prefer that IMAPEXT be willing to adopt these extensions into a single ACL specification as optional ACL facilities. If not, there will be two specifications. Even then, the situation can still be salvaged, with face-saving for all. It just requires a sincere effort to maintain upwards compatibility from ACL to ACLPLUS: ACL must not do anything that breaks ACLPLUS, and ACLPLUS must remain a proper superset of ACL. There are no technical barriers; it just requires will. If there's a lack of will, it isn't on my part. If, on the other hand, the hostile stonewalling continues, we'll end up with interoperability problems. We'll have egg on our collective faces. The trade rags will have a field day. If that happens, so be it. I'm sorry that it has come to this. I did not want it. I've spent three years trying to resolve this, and getting repeatedly rebuffed. I still do not want it. There are positive steps that you can take to remedy the situation. I have seen no sign yet. All I've seen are endless delays on everything we want, while certain other agendas are rammed through. Even at this stage, it isn't too late; but time is running out. I hope to hear a positive answer. If there is a serious intention to resolve these differences constructively, I am willing to arrange a face-to-face meeting with the interested parties here in Seattle. -- Mark -- Received: by ns.secondary.com (8.9.3/8.9.3) id XAA01445 for ietf-imapext-bks; Thu, 25 May 2000 23:10:32 -0700 (PDT) Received: from episteme-software.com (resnick1.qualcomm.com [63.250.90.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA01441 for ; Thu, 25 May 2000 23:10:30 -0700 (PDT) Received: from resnick2.qualcomm.com (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.1d10); Fri, 26 May 2000 01:17:08 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 4.3.1b20-05.00] Date: Fri, 26 May 2000 01:17:06 -0500 To: Mark Crispin From: Pete Resnick Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Cc: Simon Josefsson , ietf-imapext@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In my role as chair: On 5/25/00 at 7:46 PM -0700, Mark Crispin wrote: >I am working on an upwards-compatible replacement for ACL called ACLPLUS which >addresses these (and other) deficiencies. Any RFC 2086 implementation will be >able to talk to an ACLPLUS implementation, although the function set will be >limited to what RFC 2086 supports. > >I urge that action be deferred until I have a chance to produce an Internet >Draft containing my ACLPLUS specification. I'm sorry, but I don't find this course of action acceptable. The working group has identified a document editor, and that document editor has produced a -00 version for this draft. In my mind, -00 means this is a first cut. Mark, you (and others) have made some comments, and I expect the editor to address those comments, either by making changes to the document to satisfy you (or more importantly a rough consensus of the working group with or without you), or to convince us that the current text is sufficient. In either case, this is something that the working group's designated editor needs to do without the threat of someone running off and writing some other competing document outside of the scope of this working group. To do so would undermine the effectiveness of the working group and would leave the potential for huge interoperability problems in the future. If you wish to submit suggested text to the document editor for how you think these issues should be addressed, I encourage you to do so. However, I strongly suggest that you not produce a different document unless and until *both* (a) there is no sign of coming to an agreement with the current document editor *and* (b) the working group decides that we need another document to compare to. Neither of those criteria are currently satisfied. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA24096 for ietf-imapext-bks; Thu, 25 May 2000 21:42:15 -0700 (PDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA24091 for ; Thu, 25 May 2000 21:42:13 -0700 (PDT) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id VAA31417; Thu, 25 May 2000 21:49:32 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (death@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id VAA25777; Thu, 25 May 2000 21:49:32 -0700 Date: Thu, 25 May 2000 21:25:30 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: Lawrence Greenfield cc: ietf-imapext@imc.org In-Reply-To: <200005260409.AAA18941@smtp1.andrew.cmu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 26 May 2000 00:09:55 -0400 (EDT), Lawrence Greenfield wrote: > Why should group management be part of IMAP? That's like asking "why should ACL management be part of IMAP?". First of all, it's wrong to think in terms of groups. Think in terms of defined identifier sets. A "group" is simply one type of defined identifier set. > What is problematic about it? It's a straightforward algorithm to > implement in deciding whether to grant or deny rights. It is problematic because it does not express an existing valid access configuration, in which an identifier (containing a user) is exempted from a negative right applied to another identifer (also containing that user). > The proposed modification complicates semantics significantly. Is > there operational experience that this level of flexibility is needed? Yes. Existing protection codes which I have today behave this way. > I think this draft fixes a number of known problems with the current > ACL extension in a compatible, straightforward way. This draft contains a set of four trivial changes. One change is mandated by IAB; one change is a handwave; and the last two changes are bugs. Yes, the overloading of the "c" right for mailbox deletion is also a bug. First, it is ambiguous about what can be deleted: it should be the mailbox itself (not inferiors) but that needs to be stated. Also, the ability to create inferiors does not necessarily mean the ability to delete the mailbox. We need a separate "x" right for mailbox deletion. It doesn't really matter now, since ACLPLUS is going to happen. After three years of being stonewalled, time has run out. Received: by ns.secondary.com (8.9.3/8.9.3) id VAA22592 for ietf-imapext-bks; Thu, 25 May 2000 21:02:43 -0700 (PDT) Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA22587 for ; Thu, 25 May 2000 21:02:41 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp1.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id AAA18941; Fri, 26 May 2000 00:09:55 -0400 (EDT) Date: Fri, 26 May 2000 00:09:55 -0400 (EDT) Message-Id: <200005260409.AAA18941@smtp1.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: Mark Crispin Cc: ietf-imapext@imc.org In-reply-to: Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Thu, 25 May 2000 19:46:45 -0700 (PDT) From: Mark Crispin [...] PROBLEM: The group facility doesn't address the problem, and in fact creates more problems than it solves; it completely swallows the entire $ syntax for a functionality that isn't otherwise specified (e.g. how do you manage groups?). Why should group management be part of IMAP? Groups logically come from an authorization server; whether that's an LDAP server sitting somewhere, or (unfortunately) an AFS PTS server somewhere else, it really doesn't matter---it's the authorization server's decision whether an authorization identifier is included in a group. [...] Although removing the ambiguity is a good idea, I question whether it's really such a good idea to insist upon inheritance. In particular, the inheritance of negative rights is problematic. What is problematic about it? It's a straightforward algorithm to implement in deciding whether to grant or deny rights. The proposed modification complicates semantics significantly. Is there operational experience that this level of flexibility is needed? I think this draft fixes a number of known problems with the current ACL extension in a compatible, straightforward way. Larry Received: by ns.secondary.com (8.9.3/8.9.3) id UAA17486 for ietf-imapext-bks; Thu, 25 May 2000 20:13:12 -0700 (PDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA17479 for ; Thu, 25 May 2000 20:13:10 -0700 (PDT) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id UAA27893; Thu, 25 May 2000 20:20:24 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tonyb@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id UAA22227; Thu, 25 May 2000 20:20:24 -0700 Date: Thu, 25 May 2000 19:46:45 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: Simon Josefsson cc: ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have reviewed the subject Internet Draft. It's completely inadequate for the task at hand. It looks like all the discussion of the past three years has gone in one ear and out the other. PROBLEM: The group facility doesn't address the problem, and in fact creates more problems than it solves; it completely swallows the entire $ syntax for a functionality that isn't otherwise specified (e.g. how do you manage groups?). RECOMMENDATION: The draft be modified to reserve names beginning with $ for use by an extension to ACL. PROBLEM: Unlike RFC 2086, this new draft requires rights inheritance; that is, an identifier automatically has the rights of "anyone" unless these are specifically denied as negative rights. RFC 2086 allowed implementations to decide if rights were inherited or not. Although removing the ambiguity is a good idea, I question whether it's really such a good idea to insist upon inheritance. In particular, the inheritance of negative rights is problematic. RECOMMENDATION: The draft should be modified to indicate whether or not an identifier has inheritance semantics. I suggest using + for this purpose. In other words: +anyone lr means that all users can list and read the mailbox unless specifically denied by a - identifier, whereas: anyone lr means that all users who aren't otherwise listed by an identifier can read and list the mailbox. Also, + and - can be combined to cause negative rights inheritance. For example fred lr -$G$students lr anyone lr means that everybody except for members of the students group can read and list; however fred can also read and list even though he's a member of students. On the other hand +-anyone lr means that nobody can read or list the file, no matter who (this is what - is defined to do in the draft). I am working on an upwards-compatible replacement for ACL called ACLPLUS which addresses these (and other) deficiencies. Any RFC 2086 implementation will be able to talk to an ACLPLUS implementation, although the function set will be limited to what RFC 2086 supports. I urge that action be deferred until I have a chance to produce an Internet Draft containing my ACLPLUS specification. Received: by ns.secondary.com (8.9.3/8.9.3) id FAA07403 for ietf-imapext-bks; Thu, 25 May 2000 05:47:06 -0700 (PDT) Received: from badis.pdc.kth.se (IDENT:root@badis.pdc.kth.se [130.237.221.45]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07398 for ; Thu, 25 May 2000 05:47:04 -0700 (PDT) Received: (from jas@localhost) by badis.pdc.kth.se (8.10.0/8.10.0) id e4PCsSF13535; Thu, 25 May 2000 14:54:28 +0200 To: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt References: <200005251035.GAA02908@ietf.org> In-Reply-To: Internet-Drafts@ietf.org's message of "Thu, 25 May 2000 06:35:17 -0400" From: Simon Josefsson Date: 25 May 2000 14:54:27 +0200 Message-ID: Lines: 15 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.6 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: Two little thoughts . If identifiers starting with dollar signs are reserved for groups, why don't describe what "groups" are and how they work too? I'd really like IMAP ACLs on groups of users, but I'm not sure there is enough detail to implement it server-independently. . Perhaps it should be noted in the security considerations that the ACL evaluation now required might breach security if rfc2086-ACL's are used in a server implementing this draft? I dunno much about the draft, or anything, at all, so feel free to ignore my comments if they doesn't make sense. (Wasn't there talk of a major re-design of IMAP ACLs?) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA02277 for ietf-imapext-bks; Thu, 25 May 2000 03:28:04 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02273 for ; Thu, 25 May 2000 03:28:03 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02908; Thu, 25 May 2000 06:35:17 -0400 (EDT) Message-Id: <200005251035.GAA02908@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-acl-00.txt Date: Thu, 25 May 2000 06:35:17 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP4 ACL extension Author(s) : J. Myers Filename : draft-ietf-imapext-acl-00.txt Pages : 9 Date : 24-May-00 The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-acl-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-acl-00.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: <20000524122335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-acl-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-acl-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000524122335.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23705 for ietf-imapext-bks; Tue, 9 May 2000 10:44:52 -0700 (PDT) Received: from scooby.lineone.net ([194.75.152.224]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23285; Tue, 9 May 2000 10:36:53 -0700 (PDT) Received: from ukd ([195.171.177.9]) by scooby.lineone.net (8.9.3/8.9.3) with SMTP id QAA21977; Tue, 9 May 2000 16:27:42 +0100 (BST) Message-ID: <013c01bfb9cc$8f482480$09b1abc3@ukd> From: "Charlie Fletcher - www.ukdata.com" To: "Finance Director" Subject: Instant On-Line Credit Reports Date: Tue, 9 May 2000 16:34:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Do you need fast accurate information to assist you when appraising potential customers, and suppliers? The UK Data internet website www.ukdata.com contains 28 million pages of data with full information on every UK company! Credit Reports-Director Searches-Accounts-Annual Returns All of these products and many more are available to you immediately, and can be downloaded to and printed from your personal computer. Free samples of all reports are available at www.ukdata.com. Please also visit www.formacompany.co.uk the on-line company formation website Thank You Charles Fletcher www.ukdata.com an instant report on every UK business www.formacompany.co.uk the on-line company formation site www.irishdata.ie - instant reports on all Irish companies Received: by ns.secondary.com (8.9.3/8.9.3) id TAA16756 for ietf-imapext-bks; Wed, 31 May 2000 19:53:54 -0700 (PDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA16746 for ; Wed, 31 May 2000 19:53:53 -0700 (PDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id UAA03189; Wed, 31 May 2000 20:01:36 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (ken@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id UAA16795; Wed, 31 May 2000 20:01:36 -0700 Date: Wed, 31 May 2000 19:48:09 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: Cyrus Daboo cc: ietf-imapext@imc.org In-Reply-To: <984053.3168775009@ip108.imc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 31 May 2000 15:16:49 -0700, Cyrus Daboo wrote: > >> 'The server SHOULD issue an untagged MYRIGHTS response > > I agree completely, but you can't do this in the RFC 2086 framework, > > because a base level IMAP client would complain about getting a MYRIGHTS > > response. > Not if its a resp-cond-state: > * OK [MYRIGHTS lrwia] myrights ACL response Well, yes and no. Yes, that is certainly valid in the base spec. No, because a resp-cond-status of MYRIGHTS is different from an RFC 2086 MYRIGHTS response. That seems to be splitting hairs, but it means we'd have two ways of doing the same response forever, unless the untagged MYRIGHTS response is deprecated in favor of the resp-cond-state. That might be a good idea, actually; it could be carried in the tagged OK response for the MYRIGHTS command and not use an untagged response at all. However, I still contend that leveraging off the LIST response would be a better idea. It could be useful for the client to get \NoInferiors state at SELECT time; and there's a lot more that could be delivered as well. There's another reason why I advocate a LIST response; I think that the current GETACL, LISTRIGHTS, and MYRIGHTS commands should be deprecated in favor of an extended form of LIST. That way, we could use wildcards, and avoid the current situation where a client does a LIST then a MYRIGHTS for each returned mailbox. PS: Ofhand observation: the interesting rights at SELECT time are lipca. The client can infer r from being able to select, and swd from PERMANENTFLAGS. Received: by ns.secondary.com (8.9.3/8.9.3) id TAA14085 for ietf-imapext-bks; Wed, 31 May 2000 19:38:41 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA14072 for ; Wed, 31 May 2000 19:38:39 -0700 (PDT) Received: from ip108.imc.org (host1.108.sjccnet.com [207.87.51.108]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id WAA14738; Wed, 31 May 2000 22:45:32 -0400 (EDT) Date: Wed, 31 May 2000 15:16:49 -0700 From: Cyrus Daboo To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Message-ID: <984053.3168775009@ip108.imc.org> In-Reply-To: X-Mailer: Mulberry/2.0.1b1 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Wednesday, May 31, 2000 3:10 PM -0700 Mark Crispin wrote: >> 'The server SHOULD issue an untagged MYRIGHTS response (as a >> response-cond-state [IMAP4] response) when a client issues the SELECT or >> EXAMINE command for a mailbox when the ACL extension is present' > > I agree completely, but you can't do this in the RFC 2086 framework, > because a base level IMAP client would complain about getting a MYRIGHTS > response. Not if its a resp-cond-state: a SELECT INBOX ... ... * OK [MYRIGHTS lrwia] myrights ACL response a OK >From what I see in RFC2060 'resp_text_code' is designed so clients should accept data not defined in the base-spec. -- Cyrus Daboo Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA20282 for ietf-imapext-bks; Wed, 31 May 2000 16:30:16 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (jjs@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20278 for ; Wed, 31 May 2000 16:30:14 -0700 (PDT) Date: Wed, 31 May 2000 16:37:57 -0700 (PDT) From: Mark Crispin To: Steve Hole cc: John Gardiner Myers , ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt In-Reply-To: Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 29 May 2000, Steve Hole wrote: > I think that (2) (identifier theory) is where we are going to run aground. > A flexible identifier theory and semantic strikes me as being a strategy > much like flexible hierarchy notation. This scares me. Let's be clear on this. I don't intend that "UNIX owner" or "UNIX group" be defined as such in ACL. Rather, it should be possible to express these concepts as part of a general (not flexible!) mechanism. By general, I mean "a mechanism whose ideal state is full implementation" as opposed to "flexible" which means "a mechanism which expresses contradictory models, and therefore would never be fully implemented." Hierarchy is "flexible"; what I propose for identifiers is "general". My idea basically boils down to this: 1) a mechanism to define identifiers: global, per-mailbox, and perhaps also per-user (I don't need the last one, but perhaps other people do). Defined identifiers can be defined in terms of other defined identifiers. 2) a system of naming that makes the type of identifier unambiguous. 3) a mechanism to look up (expands) the definition of a defined identifier. The impact of this is: . definition of identifier nomenclature . command to define an identifier . command to get the definition of an identifier Note that there is no specific "change group" or "change owner"; however, the necessary functionality is there. The semantics of other existing ACL mechanisms can be done the same way. I also don't think that it's necessary for the specification to enshrine "owner" or "group" in the UNIX sense, but perhaps it may be good to document a particular convention for per-mailbox nomenclature of defined identifiers of these two. At the specification level, all that should matter is that these per-mailbox identifiers have ACLs; the per-mailbox identifier that corresponds to UNIX owner expands to one or more RFC 2086 user name identifiers, and the per-mailbox identifier that corresponds to UNIX group expands to a global defined identifier (which in turn expands to one or more RFC 2086 user name identifiers). Of course, the server is always permitted to respond NO to an operation which it does not agree to do. A separate issue is the lack of an identifier that includes everybody except for anonymous. Since excluding anonymous is the normal case, it doesn't really work well to have negative rights for anonymous on all ACLs. > It was collosal mistake to > select in favour of the "what the server is able to express" model for > hierarchy and we should not make the same mistake for ACL identifiers. I don't think that the example of hierarchy really applies here. In hierarchy, two models which were fundamentally hostile to each other were shoehorned together. In this case, we're talking about extensions to the existing framework that everybody can implement, and probably would want to implement. It is possible to implement RFC 2086 ACL in UNIX now (inheritance and the "c" right in the draft is a different matter). The problem is that the result isn't very useful and/or would give clients unpleasant surprises (e.g. implicit DELETEACL). I don't think that you want that. With these extensions, the only differences would be in what the server will say OK or NO to. You wouldn't have the \NoSelect or \NoInferiors which are specific to how a particular model works. There would be no "chgrp" operator, but there would be an operator that I would implement with chgrp() (and some other server would do it some other way). Received: by ns.secondary.com (8.9.3/8.9.3) id PAA19749 for ietf-imapext-bks; Wed, 31 May 2000 15:58:11 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (groves@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19745 for ; Wed, 31 May 2000 15:58:10 -0700 (PDT) Date: Wed, 31 May 2000 16:05:54 -0700 (PDT) From: Mark Crispin To: Steve Hole cc: John Gardiner Myers , ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt In-Reply-To: Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Inheritance (3) will be a very interesting discussion, but because > formalization of it is a "new thing" we *should* be able to converge on > that as well. My position is that it is better not to have inheritance at all rather than the definition in the draft. If you have inheritance, it is relatively simple to work around a lack of inheritance in the ACL specification. Otherwise, you need a complex specification of how inheritance works; either by being able to stipulate when inheritance happens or by having a priority mechanism which indicates when inheritance applies. The problem comes in with negative rights. Consider this example: a particular mailbox is open to anyone except those who are members of a particular group (overriding anyone inheritance with a negative right) but user fred who is in that group has access (overriding the group negative right). This is something that people want to do, and it's easy to do in UNIX. The draft makes it impossible; once a negative right is acquired through inheritance there's no way to lose it. I identified some missing functionality in inheritance, but I wouldn't be at all surprised if someone else finds other missing functionality. I don't think that it's possible to make a simple definition of inheritance that is going to have long-term viability. I contend that inheritance is a rathole, and an unnecessary one at that. If, on the other hand, there is no inheritance, then the problem doesn't exist. Even better, negative rights can also be deleted from the specification since all you need to do the equivalent is add an ACL for the identifier without that right. Received: by ns.secondary.com (8.9.3/8.9.3) id PAA19734 for ietf-imapext-bks; Wed, 31 May 2000 15:57:21 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (eon@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19730 for ; Wed, 31 May 2000 15:57:20 -0700 (PDT) Date: Wed, 31 May 2000 16:04:50 -0700 (PDT) From: Mark Crispin To: Steve Hole cc: John Gardiner Myers , ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt In-Reply-To: Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 29 May 2000, Steve Hole wrote: > (1) The interpretation of various rights identifiers. > (2) The definition/management of identifiers. > (3) Rights inheritance. I think that this is a good summary. Add a fourth issue: (4) Structure of ACL commands and (especially) responses. This relates to things such as issuing automatic ACL responses at SELECT time; the ability to have wildcards in mailbox names; the ability to replace the entire ACL and/or redefine ACL for multiple identifiers; the ability to query potential rights for multiple identifiers. > We have had trouble with (1) > ourselves and I think that it should be fairly easy to come to concensus > on. I hope so. Since rights tying exists, it would be better to add a new right rather than to overload existing rights with semantics that may not necessarily make sense to tie together. I'm thinking here about the "c" right, which should not be overloaded with "delete mailbox". Received: by ns.secondary.com (8.9.3/8.9.3) id PAA18578 for ietf-imapext-bks; Wed, 31 May 2000 15:02:49 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (trebor@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA18573 for ; Wed, 31 May 2000 15:02:47 -0700 (PDT) Date: Wed, 31 May 2000 15:10:30 -0700 (PDT) From: Mark Crispin To: Cyrus Daboo cc: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt In-Reply-To: <483912.3168421931@groats115.ppp.andrew.cmu.edu> Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 27 May 2000, Cyrus Daboo wrote: > What I would like to see is a new REPLACEACL command that takes a mailbox > spec, similar to the LIST command, and a list of identifier-rights pairs. > This command would remove all the existing rights on the matching mailboxes > and then add all the rights specified in the command. This effectively > 'propagates' a set of rights to a group of mailboxes in a single command. Yes! This is one of the important operations I feel is missing in RFC 2086; the current SETACL is actually a "modify ACL" or "add ACL" as opposed to a "set ACL". It's one of the things that I want to do in ACLPLUS. > 'The server SHOULD issue an untagged MYRIGHTS response (as a > response-cond-state [IMAP4] response) when a client issues the SELECT or > EXAMINE command for a mailbox when the ACL extension is present' I agree completely, but you can't do this in the RFC 2086 framework, because a base level IMAP client would complain about getting a MYRIGHTS response. My idea in ACLPLUS is to deprecate all the existing RFC 2086 responses (basically, only in response to one of the RFC 2086 commands) in favor of extensions to the LIST response. The advantage with using the LIST response is that the base level specification already has the framework in place for such extensions; all you have to do are a few minor tweaks to the ACL responses to make them comply with that framework. Here's how the RFC 2086 response examples would look in ACLPLUS * ACL INBOX Fred rwipslda => * LIST (\NoInferiors \ACL:Fred=rwipslda) "" INBOX * LISTRIGHTS ~/Mail/saved smith la r swicd => * LIST (\NoInferiors \RIGHTS:smith=la_r_swicd) "" INBOX * MYRIGHTS INBOX => * LIST (\NoInferiors \MYRIGHTS=rwipslda) "" INBOX Of course, these could be combined in a single LIST response. This opens up the other pending issue of LIST command extensions, but I think that LIST responses can be extended independently. Received: by ns.secondary.com (8.9.3/8.9.3) id XAA14979 for ietf-imapext-bks; Mon, 29 May 2000 23:18:17 -0700 (PDT) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA14975 for ; Mon, 29 May 2000 23:18:15 -0700 (PDT) Received: from [192.168.124.95] (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id IAA03096; Tue, 30 May 2000 08:24:37 +0200 (MET DST) Mime-Version: 1.0 X-Sender: paf@nix.swip.net Message-Id: In-Reply-To: References: Date: Tue, 30 May 2000 08:20:10 +0200 To: Pete Resnick , Mark Crispin From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: On the nature of WG discussion (Was: I-D ACTION:draft-ietf-imapext-acl-00.txt) Cc: ietf-imapext@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 00.25 -0500 00-05-30, Pete Resnick wrote: >Again, if the WG consensus is that we'd get more done if 2086 were >made Historic (and you may choose to try to convince the WG of >this), I'm perfectly happy to go to the IESG. Personally, at this >point I think it's a waste of time to pursue and we'd be better off >concentrating on what we want in the current ACL document. An RFC doesn't have to be made historic for "errors to be corrected". One can publish a new RFC which updates the older one, or replaces it. As Pete states, we have the IETF wide last call and the appeals process for exactly the reasons mentioned. FWIW: I do agree with Pete when he states that looking at the current document is what you should do. Patrik Area Director, Applications Area Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA12197 for ietf-imapext-bks; Mon, 29 May 2000 22:18:16 -0700 (PDT) Received: from episteme-software.com (resnick1.qualcomm.com [63.250.90.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA12187 for ; Mon, 29 May 2000 22:18:13 -0700 (PDT) Received: from resnick2.qualcomm.com (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.1d10); Tue, 30 May 2000 00:25:21 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 4.3.1b20-05.00] Date: Tue, 30 May 2000 00:25:20 -0500 To: Mark Crispin From: Pete Resnick Subject: On the nature of WG discussion (Was: I-D ACTION:draft-ietf-imapext-acl-00.txt) Cc: ietf-imapext@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think Steve Hole's last message is a good starting place for discussion of ACL issues; I hope discussion continues from there. However, there were some process points in Mark's message that I wanted to address: Though I thought about not saying anything, I think the answers are worth everyone's time so that we all understand how the work in this WG should go. On 5/26/00 at 11:40 AM -0700, Mark Crispin wrote: >Are you unaware that there is a team of people here at UW working on >email development? I'm speaking about the concerns of the entire >team. [...and...] >I don't think that you really mean to say that you go along with >whichever organization packs the meeting room with the most number >of its employees. First things first: Nobody in the WG can make claims to speak on behalf of larger entities. We are a gathering of individuals and we speak as such. That doesn't mean that you can't say things like "The folks I work with would really have an easier time implementing if the document did A instead of B" or "I've talked to some folks at XYZ company or university and they are really not going to like implementing A in their client." That's interesting information. However, talking about "our opinion of X" or saying "we think Y" without saying how you came to the conclusion that you are all of this one mind just isn't going to fly. On the flip side, organizations who try to pack the meeting room with employees aren't going to accomplish too much either. If I ask for the consensus of the room and I hear a lot of humming but not a lot of explanation of why a particular position is correct, and that humming all comes from a bunch of people working on the same implementation, I take it for what its worth, which amounts to about 1 person. This is about a consensus of technical opinion, not a count of heads. Of course, if two well reasoning people are disagree and one has done a widely deployed implementation and the other hasn't written a line of code, the former person will have a little more weight behind them. I hope both of these points are obvious, but I wanted to make sure that people understood where I am at. >>We have by no means had sufficient discussion IN THIS WORKING GROUP >>to determine whether your concerns *won't* be addressed. > >The past three and a half years worth of discussion is to be started >over from the beginning? No, but the content of previous discussions need to be brought into this WG and we need to see whether this particular gathering of folks (some of whom are new to the discussion) will turn in a different direction from the one that does not address your concerns. I think a very short period of time will tell. Now, a few things on this last section: >Will you request IESG to withdraw RFC 2086 from Proposed Standard >status, so that a clean start can be made? I won't request anything of the IESG at this point. First of all, I'm in no position personally to do that; I speak for the WG in this capacity. To that end, so far it seems that the WG wants the ACL draft to correct problems in 2086 and advance it. I have not heard from the WG that they want to move 2086 to Historical and start again with a new Proposed Standard. If I start to hear that, I will of course take that feedback to the IESG. >UW did not approve RFC 2086. It should never have gotten on standards-track. As far as I know, UW has no standing to approve or disapprove anything. Certainly no single person has approval power in the IETF, and organizations have no formal standing whatsoever. This kind of statement holds no weight with me at all. Now, certainly there was an IESG last call on 2086 before its release. If you and other folks you work with at UW thought that 2086 did not belong on the standards track for technical reasons, you had an opportunity to voice your opinion at that time. If you felt that your opinions were unjustly disregarded by the IESG, or that the approval was ram-rodded without having an opportunity to make your opinions known, there is a clear appeals process in the IETF. I do not think, however, that rehashing a 3 1/2-year old decision in this forum does anything to advance our work. Again, if the WG consensus is that we'd get more done if 2086 were made Historic (and you may choose to try to convince the WG of this), I'm perfectly happy to go to the IESG. Personally, at this point I think it's a waste of time to pursue and we'd be better off concentrating on what we want in the current ACL document. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA06341 for ietf-imapext-bks; Mon, 29 May 2000 13:54:29 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06337 for ; Mon, 29 May 2000 13:54:23 -0700 (PDT) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e4TL1pJ21750; Mon, 29 May 2000 15:01:51 -0600 From: Steve Hole Date: Mon, 29 May 2000 15:01:47 -0600 To: John Gardiner Myers Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Cc: ietf-imapext@imc.org In-Reply-To: <392EBA1A.91074F4F@netscape.com> References: <392EBA1A.91074F4F@netscape.com> Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 26 May 2000 10:53:30 -0700 John Gardiner Myers wrote: > > After much thought, confirmed by discussion at Adelaide, I've concluded > that Mark's concerns are best addressed by his pursuing a separate > extension. The models of access control are sufficiently different that > an extension trying to address both (or all) models will necessarily be > over complex and difficult to implement on the client side. Having read through the thead, I think Mark's proposals could be broken into three areas: (1) The interpretation of various rights identifiers. (2) The definition/management of identifiers. (3) Rights inheritance. I say think, because the discussion rolled out over several messages and it was hard to pull it together. I am sorry Mark if I have misrepresented or forgotten something. I would say the (1) and (3) are very germane to any ACL model and bear serious discussion for the draft at hand. We have had trouble with (1) ourselves and I think that it should be fairly easy to come to concensus on. Inheritance (3) will be a very interesting discussion, but because formalization of it is a "new thing" we *should* be able to converge on that as well. I think that (2) (identifier theory) is where we are going to run aground. A flexible identifier theory and semantic strikes me as being a strategy much like flexible hierarchy notation. This scares me. Putting on my client developer hat, I would opt for the "one true semantic" for identifiers. It just seems so much easier to implement and to create UI for. It is easier to explain to users. Of course, the definition for the "one true semantic" is up for discussion. We should not settle for a compromise the way we did last time, because it clearly led to interoperability problems. If the chain of events for folder hierarchy design repeats itself with ACL identifiers, then I expect that we will very quickly get to a discussion on what the "service is able to express" versus what the "client wants to see". I will be very clear about this. It was collosal mistake to select in favour of the "what the server is able to express" model for hierarchy and we should not make the same mistake for ACL identifiers. We should select for ease of use in the client in this situation. The model to be chosen can be debated, but there must be only one in the end. If may be true that there is a simple representation that has the flexibility required -- great! We won't know that until we have seen the various options. Mark. I encourage you to post the fragments of your proposal to the working group mailing list prior to posting a draft. It would be very useful to look at the specifics without waiting for the process. As you have noted, it has been too long already. I for one would be very interested in seeing the identifier model in some detail. I would also like to see the detailed discussion these three areas (or more if there are more) broken into separate threads. It is a little taxing to try to deal with the conceptual issues behind all three at once. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA05221 for ietf-imapext-bks; Mon, 29 May 2000 12:38:43 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA05217 for ; Mon, 29 May 2000 12:38:41 -0700 (PDT) Received: from kepler (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e4TJjmJ21169; Mon, 29 May 2000 13:46:01 -0600 From: Steve Hole Date: Mon, 29 May 2000 13:45:44 -0600 To: Cyrus Daboo Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Cc: ietf-imapext@imc.org In-Reply-To: <483912.3168421931@groats115.ppp.andrew.cmu.edu> References: <483912.3168421931@groats115.ppp.andrew.cmu.edu> <200005251035.GAA02908@ietf.org> Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 27 May 2000 13:12:11 -0400 Cyrus Daboo wrote: > 9) One other behaviour that I would like to see added as a SHOULD > requirement on the server: > > 'The server SHOULD issue an untagged MYRIGHTS response (as a > response-cond-state [IMAP4] response) when a client issues the SELECT or > EXAMINE command for a mailbox when the ACL extension is present' This would be a *very* nice thing to do. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA26127 for ietf-imapext-bks; Sat, 27 May 2000 10:04:26 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA26113 for ; Sat, 27 May 2000 10:04:17 -0700 (PDT) Received: from groats115.ppp.andrew.cmu.edu (GROATS115.PPP.ANDREW.CMU.EDU [128.2.61.115]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id NAA06697 for ; Sat, 27 May 2000 13:10:52 -0400 (EDT) Date: Sat, 27 May 2000 13:12:11 -0400 From: Cyrus Daboo To: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Message-ID: <483912.3168421931@groats115.ppp.andrew.cmu.edu> In-Reply-To: <200005251035.GAA02908@ietf.org> X-Mailer: Mulberry/2.0.1b1 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here are some issues related to the ACL draft: 1) [IMAP4] reference points to RFC1730 but should point to RFC2060. 2) In section 3, the 'r' right should also be tied to the STATUS command. 3) Does not having the 'l' right mean that any mailbox operations are denied? For example if the 'l' right is missing, but the 'r' right is present, can a client still issue a SELECT on the mailbox? It might not 'see' the mailbox but it might know it exists. I think this needs to be made clear. Also how do the SUBSCRIBE and UNSUBSCRIBE commands tie in with this? Are they tied to the 'l' right or the 'r' right? 4) Since its possible to set flags in the APPEND command there needs to be a discussion of how the 'w' and 'i' bits interact, or at least the description for 'w' should also indicate that setting the flag via APPEND is also controlled via that right. 5) Right now 2060 mandates that a server send [READ-ONLY] or (optionally) [READ-WRITE] responses during a SELECT or EXAMINE. Which rights are these tied to? For example, if the 'w' write exists (i.e can change flags other than delete) but the 'd' right does not exist (can't delete or expunge) is the mailbox read-only or read-write? This actually affects the behaviour of non-ACL aware clients. ACL-aware clients are going to be smart enought to figure out the correct behaviour based on what the current users rights are to a mailbox, but non-ACL clients can only base their behaviour from the read-only/read-write responses. 6) As a reminder to implemetors, I think there needs to be a statement that the FLAGS and PERMANENTFLAGS responses as part of the SELECT command should accurately reflect the current user's rights. 7) I think the behaviour of the 'l' with respect to mailbox hierarchies needs to be explained more. Specifically what happens in the case where a user has the 'l' right to mailbox 'A/A' but not to mailbox 'A'? Should 'A/A' be returned in LIST or should the absence of the 'l' right on the parent mailbox allow a server to not bother looking for 'l' rights on the child mailboxes. 8) One thing that has come from our (now three years of) experience of doing ACLs in Mulberry is that users frequently want to take a set of ACLs on one mailbox and apply those to another mailbox, or mailboxes, e.g. 'propagation' of rights from one mailbox to its child hierarchy. Right now a client has to do this by issuing multiple DELETEACL and SETACL commands for each mailbox in the list. This is very inefficient. What I would like to see is a new REPLACEACL command that takes a mailbox spec, similar to the LIST command, and a list of identifier-rights pairs. This command would remove all the existing rights on the matching mailboxes and then add all the rights specified in the command. This effectively 'propagates' a set of rights to a group of mailboxes in a single command. 9) One other behaviour that I would like to see added as a SHOULD requirement on the server: 'The server SHOULD issue an untagged MYRIGHTS response (as a response-cond-state [IMAP4] response) when a client issues the SELECT or EXAMINE command for a mailbox when the ACL extension is present' I don't know about other clients, but we always issue a MYRIGHTS command after doing a SELECT or EXAMINE in order to figure out what UI items need to be enabled or disabled on the newly opened mailbox, e.g. enabling/disabling or certain flag commands based on the 'w' right. Having MYRIGHTS sent as an untagged response to SELECT or EXAMINE would remove the need for the extra command from the client. I would suggest that most ACL-aware clients are going to want MYRIGHTs on mailboxes they select so this would be a welcome change. -- Cyrus Daboo Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA13773 for ietf-imapext-bks; Fri, 26 May 2000 13:52:26 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (tbl@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13769 for ; Fri, 26 May 2000 13:52:25 -0700 (PDT) Date: Fri, 26 May 2000 11:40:53 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: Pete Resnick cc: ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 26 May 2000 13:18:13 -0500, Pete Resnick wrote: > As you no doubt know, the working group was only recently chartered. > There have been several things delayed because of that. I now fully > believe that we are moving along with work. I remain skeptical. I was extremely disappointed by the lack of progress in Oslo and DC. Not to mentioned being told, over and over again, that RFC 2086 is cast in stone, and that the only problem was my environment is "obsolete" and not worth worrying about. > >We were promised over a year ago that our concerns with ACL would be > >addressed. > Who is "we"? Are you unaware that there is a team of people here at UW working on email development? I'm speaking about the concerns of the entire team. > To date, the only person I have heard on these issues is > you. I don't think that you really mean to say that you go along with whichever organization packs the meeting room with the most number of its employees. > There was consensus in the room at Australia that requiring ACLs to > strictly conform to Unix semantics was potentially damaging to the > protocol and that we should stick to solving the problems in the > currently deployed base. Nobody ever said "require ACLs to strictly conform to Unix semantics". That's a strawman with no purpose other than to be burned down. If you want me to take this discussion seriously, don't use such strawmen. > We have by no means had sufficient > discussion IN THIS WORKING GROUP to determine whether your concerns > *won't* be addressed. The past three and a half years worth of discussion is to be started over from the beginning? > As far as we should all be concerned, the clock has only > now started ticking. Will you request IESG to withdraw RFC 2086 from Proposed Standard status, so that a clean start can be made? UW did not approve RFC 2086. It should never have gotten on standards-track. I've heard the excuse of "RFC 2086 is standards-track and it's too late to change the framework now" too many times in the past three years. There's no point in further discussion as long as that excuse remains. > I look forward to discussion of these items. If there are more > issues, bring them up now. OK: Other than inheritance and the problem with the "c" right, the system of rights is more or less acceptable. To recap: 1) there needs to be a "+" prefix (or suffix, I don't really care) which stipulates that the rights are to be inherited as described in the new I-D. Otherwise, another applicable identifier (e.g. the user name) can override the rights. Actually, the "+" means "mandatory application without override". The I-D insists that mandatory application is the only way, which means that there is no way to "disable access for everybody in a group except for one user". 2) Delete and rename mailbox needs to be separate; perhaps an "x" right since it insists upon this alphabet soup of one letter codes. A minor nit is the "d" right; it should not specify "perform EXPUNGE". But I think that I can just ignore that part without breaking things. Given that IMAP is so chatty otherwise and the ACL commands don't allow wildcards, the alphabet soup makes little sense; but since I plan to allow wildcards in ACLPLUS I'm willing to leave this alone. The primary problem with RFC 2086 is that the system of identifiers in ACLs is inflexible. We don't need a specific "change owner" and "change group" operation. We just need identifier semantics that can represent those operations. This is best done by a general purpose mechanism to define certain forms of identifiers, and to query the definition of an identifier. This new theory of identifiers is the beating heart of ACLPLUS. It defines the semantics of $xxx identifiers, and it adds two operators: one to define a $xxx identifier, and one to query its definition. Less important is a redesign of the commands and responses, with the RFC 2086 commands/responses retained for compatibility. The new commands and responses are considerably more powerful than RFC 2086. However, this is a completely secondary agenda; although it's a better design it's not crucial for the functionality. > Let's start with trying to address the issues in > the current framework and move on from there. The current framework is broken. I do not purpose to create a framework that is hopelessly biased towards another model. Instead, I purpose to create a framework that encompasses both models in a clean and well-defined manner. I've been told repeatedly that it is not possible, and shouldn't be done. It seems that the only way that I can prove otherwise is by doing it. > You releasing a competing draft at this point will > inevitably slow our work down, and potentially lead to the above > horrors. I'm sorry that's it's come to this, but I have yet to hear anything that will change it. > So, may > I assume that you put your work on hold until we have had some > further discussion in the WG? Unfortunately, the answer is no. It's been held off for three and a half years. That's long enough. I've been very patient. Unfortunately, it seems that the only way to make progress happen is for me to proceed. Until/unless there is concrete progress towards addressing our issues, , my work will proceed. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA12310 for ietf-imapext-bks; Fri, 26 May 2000 12:19:05 -0700 (PDT) Received: from netscape.com ([205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12306 for ; Fri, 26 May 2000 12:19:03 -0700 (PDT) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by netscape.com (8.8.5/8.8.5) with ESMTP id MAA21755 for ; Fri, 26 May 2000 12:18:58 -0700 (PDT) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (980427.SGI.8.8.8/8.8.5) with SMTP id MAA92219 for ; Fri, 26 May 2000 12:25:53 -0700 (PDT) To: ietf-imapext@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-imapext Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Date: Fri, 26 May 2000 12:25:42 -0700 Organization: Netscape Communications Corporation Lines: 78 Message-ID: <392ECFB6.6C28FBDE@netscape.com> References: <392EBA1A.91074F4F@netscape.com> NNTP-Posting-Host: 192.18.126.70 Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms076459EEC1E6830A8B1F22CE" X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms076459EEC1E6830A8B1F22CE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pete Resnick wrote: > Having 2 ACL extensions does not enhance interoperability. In this case, having two extensions can enhance interoperability. Part of the reason the ACL draft has been delayed is that Mark had comments I did not know how to address without creating an overcomplicated mess. Mark has stated that he wants to expose all semantics of Unix file permissions, including the "change owner" and "change group" operations. An extension that allows servers to expose all of the Unix file permission semantics and also allows servers to expose all of the ACL semantics implemented by the Cyrus server will also allow a whole range of intermediate semantics, with some aspects from Unix and some aspects from the original ACL. A conforming client would be required to be able to deal with all of these and would have a difficult time figuring out what the rules are on any particular server. Two extensions would cut out all of the intermediate states, simplifying clients and allowing them to know which type of server they are talking to. --------------ms076459EEC1E6830A8B1F22CE Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIQOjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05OTEyMTQwMDMxMTNaFw0wMDA2MTEwMDMxMTNa MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA pX1zWvGAZgDcMU3cID5cDySLcRzNT1eSwrBtUr42rYUra0h9yNeM5/1sTQ/w/dxCCD9uYYfq gIvDsbp37fH08MGDVHFStxvDDfkHApXjfQZeO/cocO/Is1RiNqh8rFab8IsyX7+enxrHA114 4MYJtJE39ykWfxys94/Raw4UfhMCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAFqbshBJHm+e8x8AZKU0v1WL01ws4lmvbNezMn/E6sgWW5F6vxH1JxceBlTI FgYmhlxCi7EUluFtL2P9ebVb1J2zfxNAgfmAGg4s9abErf1Zn3X/7kQgH8bO10QjLh7XjYpk I2z49gVR9IY/t0HE5qK5DEDamUyodBAivlTyq9W0MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIQOjAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDUyNjE5MjU0M1owIwYJKoZIhvcNAQkEMRYEFI/xeENA/A++ DyGaRvNKah73i/zOMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAKGls4BjZnVH7D/FZ5/iCYVKgLbyA0RAAITajp25W6k/s 9ZCSUzVudtgvGPbRo9OsOMov2MOj9CTlfUmIX9K2XMdpnZ2sQ0OhS5LR1chxKD9f5IHghCpM Q9SqEkv3q2JBr9RDZ8To87WypJOLOXnapoAY/2x0R6pLoGgYi6JPzXc= --------------ms076459EEC1E6830A8B1F22CE-- Received: by ns.secondary.com (8.9.3/8.9.3) id LAA11496 for ietf-imapext-bks; Fri, 26 May 2000 11:33:14 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (dchap@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11492 for ; Fri, 26 May 2000 11:33:13 -0700 (PDT) Date: Fri, 26 May 2000 11:28:24 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: John Gardiner Myers cc: ietf-imapext@imc.org In-Reply-To: <392EBA1A.91074F4F@netscape.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 26 May 2000 10:53:30 -0700, John Gardiner Myers wrote: > After much thought, confirmed by discussion at Adelaide, I've concluded > that Mark's concerns are best addressed by his pursuing a separate > extension. Thank you, John. Given that I purpose to create an upwards-compatible extension to RFC 2086, would you give careful consideration to the following in your I-D: 1) The two issues that I addressed in your latest I-D which will break compatibility (inheritance and the "c" right). I think that the change to inheritance in the I-D is a bad enough move that, if unfixed, it would accellerate the withering away of ACL in favor of ACLPLUS. The "c" right issue is less serious, but it would be a needless incompatibility. 2) Changing the defintion of $xxx to be "reserved" instead of the current poorly-defined "group". 3) Maintaining compatibility otherwise, so as not to preclude the possibility of a reunification. 4) Possible wording in your document that says that any capability that starts with ACL is compatible with ACL (e.g. what is done with SORT) to promote interoperability. > The models of access control are sufficiently different that > an extension trying to address both (or all) models will necessarily be > over complex and difficult to implement on the client side. As you should know by now, I strongly disagree with this conclusion. However, the only way that I can prove my position is by delivering the goods, and I shall proceed to do so. I believe that presently you'll find that the additions in ACLPLUS are sufficient desirable that you will decide to implement it after all. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA11082 for ietf-imapext-bks; Fri, 26 May 2000 11:11:24 -0700 (PDT) Received: from episteme-software.com (resnick1.qualcomm.com [63.250.90.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11077 for ; Fri, 26 May 2000 11:11:22 -0700 (PDT) Received: from resnick2.qualcomm.com (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.1d10); Fri, 26 May 2000 13:18:16 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 4.3.1b20-05.00] Date: Fri, 26 May 2000 13:18:13 -0500 To: Mark Crispin From: Pete Resnick Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Cc: ietf-imapext@imc.org 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 5/26/00 at 12:19 AM -0700, Mark Crispin wrote: >The working group has been ineffective up to now. The lack of >progress has been remarkable. As you no doubt know, the working group was only recently chartered. There have been several things delayed because of that. I now fully believe that we are moving along with work. Indeed, at each of the face-to-face meetings we have had as a BOF, we have made great progress on resolving many issues. >So have some rather crude politics; I'll remind you that IMAPEXT has >not even permitted the SORT and THREAD I-D's to come out with a >"draft-ietf-imapext" file name. Mark, as you full well know, given my message to you (which you replied to) of 8/18/99, message id , there were no crude politics involved here at all: As I explained, I was away on vacation when Natalia sent me the message asking whether these drafts could be under the working group. When I returned (the day I sent you the message), I sent her a message asking her to rename the drafts. I am quite sure that she would be happy to put them under the working group name if you resubmitted the documents. I think you should follow the general guideline that ad hominem attacks like this should be kept out of the working group discussions. If you want to accuse me of doing something malicious, take it to private mail. In this case, you are wrong in your assessment. >We were promised over a year ago that our concerns with ACL would be >addressed. Who is "we"? To date, the only person I have heard on these issues is you. One person does not a consensus make. If there are others involved here, I would like their comments to appear on the mailing list as well. >Yet, at the last IETF in Australia, the document editor stated that >those concerns weren't going to be addressed by ACL. There was consensus in the room at Australia that requiring ACLs to strictly conform to Unix semantics was potentially damaging to the protocol and that we should stick to solving the problems in the currently deployed base. However, if you have specific issues that you want addressed, either post them to the list or send them directly to the document editor. We have by no means had sufficient discussion IN THIS WORKING GROUP to determine whether your concerns *won't* be addressed. >The current document editor has stonewalled for three years. Time has run out. Nonsense. (1) I do not want these personal attacks in the working group. (2) The current document editor has only now gotten out the -00 draft. As far as we should all be concerned, the clock has only now started ticking. Now, you have identified two issues that the working group should address: >...mandatory rights inheritance, with no way to override an >inherited negative right >...overloading of "c" to mean "can create inferiors" and "can delete >this mailbox"... >I have offered suggestions for how these problems in the new I-D can >be resolved. I look forward to discussion of these items. If there are more issues, bring them up now. >Doing so would maintain some semblance of compatibility between ACL >and ACLPLUS. It would also keep the door open for a reunification. "Reunification" is not a desirable goal. The premise is "disunification". Let's start with trying to address the issues in the current framework and move on from there. >The design of ACLPLUS is almost finished. It will happen. I prefer >that IMAPEXT be willing to adopt these extensions into a single ACL >specification as optional ACL facilities. > >If not, there will be two specifications. This is exactly the kind of hostile stonewalling you are arguing we should not be doing. You are one voice among many. Make your voice heard and convince others that your concerns are valid. Do not attempt to strongarm people. It is destructive and has no place in this discussion. >If, on the other hand, the hostile stonewalling continues, we'll end >up with interoperability problems. We'll have egg on our collective >faces. The trade rags will have a field day. I agree. So let's stop. John has released his first draft. You have made comments. Both of those are constructive moves in the correct direction. You releasing a competing draft at this point will inevitably slow our work down, and potentially lead to the above horrors. Let's do some work over these next 2 months and see where we are, not change direction when we're barely out of the gate. >Even at this stage, it isn't too late; but time is running out. I'm glad to hear that at least you believe it isn't too late. So, may I assume that you put your work on hold until we have had some further discussion in the WG? >If there is a serious intention to resolve these differences >constructively, I am willing to arrange a face-to-face meeting with >the interested parties here in Seattle. Let's go on the assumption that there is a serious intention to resolve these differences constructively. We only have 2 months until we meet in Pittsburgh. Let us try to work through these issues on the list. If we cannot, we can use the face-to-face meeting in Pittsburgh to resolve differences. Is that acceptable? I have been on the road 5 of the past 9 weeks and I (and my significant other) would really prefer that I not travel between now and then. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA11078 for ietf-imapext-bks; Fri, 26 May 2000 11:11:22 -0700 (PDT) Received: from episteme-software.com (resnick1.qualcomm.com [63.250.90.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11073 for ; Fri, 26 May 2000 11:11:20 -0700 (PDT) Received: from resnick2.qualcomm.com (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.1d10); Fri, 26 May 2000 13:18:10 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <392EBA1A.91074F4F@netscape.com> References: <392EBA1A.91074F4F@netscape.com> X-Mailer: Eudora [Macintosh version 4.3.1b20-05.00] Date: Fri, 26 May 2000 13:18:08 -0500 To: John Gardiner Myers From: Pete Resnick Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Cc: ietf-imapext@imc.org 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 5/26/00 at 10:53 AM -0700, John Gardiner Myers wrote: >I've concluded that Mark's concerns are best addressed by his >pursuing a separate extension. I would like to hear further discussion on this point from other members of the working group. Having 2 ACL extensions does not enhance interoperability. My inclination is to try to get something that will satisfy both sets of concerns rather than have competing documents. If that can't be done to either side's satisfaction, we can revisit the issue later. However, Mark has made some comments on the document; I encourage him (and others) to make more. Let's see if there is consensus (either positively or negatively) on what to do about them before we start making decisions about new extensions. I can almost assure you that the IESG will not accept two ACL documents from this WG; my guess is that they won't accept any document while there are two competing documents in existence. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA10808 for ietf-imapext-bks; Fri, 26 May 2000 10:47:59 -0700 (PDT) Received: from netscape.com ([205.217.237.46]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10804 for ; Fri, 26 May 2000 10:47:58 -0700 (PDT) Received: from continuity.mcom.com (continuity.mcom.com [205.217.237.112]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA09328 for ; Fri, 26 May 2000 10:46:54 -0700 (PDT) Received: from continuity.mcom.com (localhost [127.0.0.1]) by continuity.mcom.com (980427.SGI.8.8.8/8.8.5) with SMTP id KAA91719 for ; Fri, 26 May 2000 10:53:49 -0700 (PDT) To: ietf-imapext@imc.org Path: not-for-mail From: John Gardiner Myers Newsgroups: mcom.list.ietf-imapext Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Date: Fri, 26 May 2000 10:53:30 -0700 Organization: Netscape Communications Corporation Lines: 64 Message-ID: <392EBA1A.91074F4F@netscape.com> References: NNTP-Posting-Host: 192.18.126.70 Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7F155AEDA087592CCD3AAFC5" X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms7F155AEDA087592CCD3AAFC5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit After much thought, confirmed by discussion at Adelaide, I've concluded that Mark's concerns are best addressed by his pursuing a separate extension. The models of access control are sufficiently different that an extension trying to address both (or all) models will necessarily be over complex and difficult to implement on the client side. Better each model have its own extension. Then the client will know which world the server is in and will not have to deal with hybrid models that don't exist in practice. --------------ms7F155AEDA087592CCD3AAFC5 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIXwYJKoZIhvcNAQcCoIIIUDCCCEwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BlkwggMMMIICdaADAgECAgIQOjANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRswGQYDVQQKExJBbWVyaWNhIE9u bGluZSBJbmMxGTAXBgNVBAsTEEFPTCBUZWNobm9sb2dpZXMxJzAlBgNVBAMTHkludHJhbmV0 IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05OTEyMTQwMDMxMTNaFw0wMDA2MTEwMDMxMTNa MIGCMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIbmV0c2NhcGUxIzAh BgkqhkiG9w0BCQEWFGpnbXllcnNAbmV0c2NhcGUuY29tMRMwEQYDVQQDEwpKb2huIE15ZXJz MRcwFQYKCZImiZPyLGQBARMHamdteWVyczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA pX1zWvGAZgDcMU3cID5cDySLcRzNT1eSwrBtUr42rYUra0h9yNeM5/1sTQ/w/dxCCD9uYYfq gIvDsbp37fH08MGDVHFStxvDDfkHApXjfQZeO/cocO/Is1RiNqh8rFab8IsyX7+enxrHA114 4MYJtJE39ykWfxys94/Raw4UfhMCAwEAAaN+MHwwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1Ud DwEB/wQEAwIEsDAfBgNVHSMEGDAWgBSiO2Uy9/cbifxVDQcBvIdIWv2QPTA2BggrBgEFBQcB AQQqMCgwJgYIKwYBBQUHMAGGGmh0dHA6Ly9uc29jc3AubmV0c2NhcGUuY29tMA0GCSqGSIb3 DQEBBAUAA4GBAFqbshBJHm+e8x8AZKU0v1WL01ws4lmvbNezMn/E6sgWW5F6vxH1JxceBlTI FgYmhlxCi7EUluFtL2P9ebVb1J2zfxNAgfmAGg4s9abErf1Zn3X/7kQgH8bO10QjLh7XjYpk I2z49gVR9IY/t0HE5qK5DEDamUyodBAivlTyq9W0MIIDRTCCAq6gAwIBAgIBJzANBgkqhkiG 9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk5MDYwMzIyMDAzNFoXDTAxMDYwMjIyMDAzNFowgZMxCzAJBgNVBAYTAlVTMQsw CQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1lcmljYSBP bmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5JbnRyYW5l dCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOLv Xyx2Q4lLGl+z5fiqb4svgU1n/71KD2MuxNyF9p4sSSYg/wAX5IiIad79g1fgoxEZEarW3Lzv s9IVLlTGbny/2bnDRtMJBYTlU1xI7YSFmg47PRYHXPCzeauaEKW8waTReEwG5WRB/AUlYybr 7wzHblShjM5UV7YfktqyEkuNAgMBAAGjaTBnMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBEGCWCGSAGG+EIBAQQEAwIBAjAfBgNVHSMEGDAW gBRyScJzNMZV9At2coF+d/SH58ayDjANBgkqhkiG9w0BAQQFAAOBgQC6UH38ALL/QbQHCDkM IfRZSRcIzI7TzwxW8W/oCxppYusGgltprB2EJwY5yQ5+NRPQfsCPnFh8AzEshxDVYjtw1Q6x ZIA0Tln6xlnmRt5OaAh1QPUdjCnWrnetyT1p5ECNRJdGb756wFiksR9qpw8pUYqBDSmOneQP MwuPjSQ97DGCAc4wggHKAgEBMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAU BgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIEluYzEZMBcG A1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlmaWNhdGUg QXV0aG9yaXR5AgIQOjAJBgUrDgMCGgUAoIGKMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAwMDUyNjE3NTMzOVowIwYJKoZIhvcNAQkEMRYEFAu95Y51ldqR lq+Q57VNK2+Zs53EMCsGCSqGSIb3DQEJDzEeMBwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCSqGSIb3DQEBAQUABIGAbleK/VxoVuUFzjW4juH7ky96kYmRMi4kfcUoylcfsdGn zexibFEpvD4KtF3/bct39xbXTKzav5SDjIOuN0N9xIJZShM3Qink51s4dSV9qF3KBbj3+oBa Cu/l5eOMENtpYeCrjY3jQKKmghoQznv2wpM+wVYtcnhP0nlj8wr6i6A= --------------ms7F155AEDA087592CCD3AAFC5-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA11479 for ietf-imapext-bks; Fri, 26 May 2000 02:04:56 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (clane@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA11475 for ; Fri, 26 May 2000 02:04:55 -0700 (PDT) Date: Fri, 26 May 2000 00:19:01 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: Pete Resnick cc: Simon Josefsson , ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 26 May 2000 01:17:06 -0500, Pete Resnick wrote: > To do > so would undermine the effectiveness of the working group and would > leave the potential for huge interoperability problems in the future. Unfortunately, the time to have worried about this has passed. The working group has been ineffective up to now. The lack of progress has been remarkable. So have some rather crude politics; I'll remind you that IMAPEXT has not even permitted the SORT and THREAD I-D's to come out with a "draft-ietf-imapext" file name. We were promised over a year ago that our concerns with ACL would be addressed. Yet, at the last IETF in Australia, the document editor stated that those concerns weren't going to be addressed by ACL. > However, I strongly suggest that you not produce a different document > unless and until *both* (a) there is no sign of coming to an > agreement with the current document editor *and* (b) the working > group decides that we need another document to compare to. Unfortunately, this is no longer possible. The current document editor has stonewalled for three years. Time has run out. The working group can take the lead on our effort; it can follow our effort; or it can ignore our effort; but it can no longer stand in the way. I know what I would counsel, but it's your decision. The new I-D is much worse than RFC 2086. The requirement in the new I-D for mandatory rights inheritance, with no way to override an inherited negative right, is a non-starter and (in my opinion) a terrible idea. I can't believe that it is seriously proposed. It doesn't affect Cyrus; Cyrus doesn't have groups. It affects me to the point that it blocks my implementation. Similarly, overloading of "c" to mean "can create inferiors" and "can delete this mailbox" is also a non-starter. These are independent rights in my world. I can't implement this overloading. I have offered suggestions for how these problems in the new I-D can be resolved. Doing so would maintain some semblance of compatibility between ACL and ACLPLUS. It would also keep the door open for a reunification. The design of ACLPLUS is almost finished. It will happen. I prefer that IMAPEXT be willing to adopt these extensions into a single ACL specification as optional ACL facilities. If not, there will be two specifications. Even then, the situation can still be salvaged, with face-saving for all. It just requires a sincere effort to maintain upwards compatibility from ACL to ACLPLUS: ACL must not do anything that breaks ACLPLUS, and ACLPLUS must remain a proper superset of ACL. There are no technical barriers; it just requires will. If there's a lack of will, it isn't on my part. If, on the other hand, the hostile stonewalling continues, we'll end up with interoperability problems. We'll have egg on our collective faces. The trade rags will have a field day. If that happens, so be it. I'm sorry that it has come to this. I did not want it. I've spent three years trying to resolve this, and getting repeatedly rebuffed. I still do not want it. There are positive steps that you can take to remedy the situation. I have seen no sign yet. All I've seen are endless delays on everything we want, while certain other agendas are rammed through. Even at this stage, it isn't too late; but time is running out. I hope to hear a positive answer. If there is a serious intention to resolve these differences constructively, I am willing to arrange a face-to-face meeting with the interested parties here in Seattle. -- Mark -- Received: by ns.secondary.com (8.9.3/8.9.3) id XAA01445 for ietf-imapext-bks; Thu, 25 May 2000 23:10:32 -0700 (PDT) Received: from episteme-software.com (resnick1.qualcomm.com [63.250.90.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA01441 for ; Thu, 25 May 2000 23:10:30 -0700 (PDT) Received: from resnick2.qualcomm.com (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.1d10); Fri, 26 May 2000 01:17:08 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 4.3.1b20-05.00] Date: Fri, 26 May 2000 01:17:06 -0500 To: Mark Crispin From: Pete Resnick Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt Cc: Simon Josefsson , ietf-imapext@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In my role as chair: On 5/25/00 at 7:46 PM -0700, Mark Crispin wrote: >I am working on an upwards-compatible replacement for ACL called ACLPLUS which >addresses these (and other) deficiencies. Any RFC 2086 implementation will be >able to talk to an ACLPLUS implementation, although the function set will be >limited to what RFC 2086 supports. > >I urge that action be deferred until I have a chance to produce an Internet >Draft containing my ACLPLUS specification. I'm sorry, but I don't find this course of action acceptable. The working group has identified a document editor, and that document editor has produced a -00 version for this draft. In my mind, -00 means this is a first cut. Mark, you (and others) have made some comments, and I expect the editor to address those comments, either by making changes to the document to satisfy you (or more importantly a rough consensus of the working group with or without you), or to convince us that the current text is sufficient. In either case, this is something that the working group's designated editor needs to do without the threat of someone running off and writing some other competing document outside of the scope of this working group. To do so would undermine the effectiveness of the working group and would leave the potential for huge interoperability problems in the future. If you wish to submit suggested text to the document editor for how you think these issues should be addressed, I encourage you to do so. However, I strongly suggest that you not produce a different document unless and until *both* (a) there is no sign of coming to an agreement with the current document editor *and* (b) the working group decides that we need another document to compare to. Neither of those criteria are currently satisfied. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA24096 for ietf-imapext-bks; Thu, 25 May 2000 21:42:15 -0700 (PDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA24091 for ; Thu, 25 May 2000 21:42:13 -0700 (PDT) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id VAA31417; Thu, 25 May 2000 21:49:32 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (death@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id VAA25777; Thu, 25 May 2000 21:49:32 -0700 Date: Thu, 25 May 2000 21:25:30 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: Lawrence Greenfield cc: ietf-imapext@imc.org In-Reply-To: <200005260409.AAA18941@smtp1.andrew.cmu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 26 May 2000 00:09:55 -0400 (EDT), Lawrence Greenfield wrote: > Why should group management be part of IMAP? That's like asking "why should ACL management be part of IMAP?". First of all, it's wrong to think in terms of groups. Think in terms of defined identifier sets. A "group" is simply one type of defined identifier set. > What is problematic about it? It's a straightforward algorithm to > implement in deciding whether to grant or deny rights. It is problematic because it does not express an existing valid access configuration, in which an identifier (containing a user) is exempted from a negative right applied to another identifer (also containing that user). > The proposed modification complicates semantics significantly. Is > there operational experience that this level of flexibility is needed? Yes. Existing protection codes which I have today behave this way. > I think this draft fixes a number of known problems with the current > ACL extension in a compatible, straightforward way. This draft contains a set of four trivial changes. One change is mandated by IAB; one change is a handwave; and the last two changes are bugs. Yes, the overloading of the "c" right for mailbox deletion is also a bug. First, it is ambiguous about what can be deleted: it should be the mailbox itself (not inferiors) but that needs to be stated. Also, the ability to create inferiors does not necessarily mean the ability to delete the mailbox. We need a separate "x" right for mailbox deletion. It doesn't really matter now, since ACLPLUS is going to happen. After three years of being stonewalled, time has run out. Received: by ns.secondary.com (8.9.3/8.9.3) id VAA22592 for ietf-imapext-bks; Thu, 25 May 2000 21:02:43 -0700 (PDT) Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA22587 for ; Thu, 25 May 2000 21:02:41 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp1.andrew.cmu.edu (8.9.3/8.9.3) with ESMTP id AAA18941; Fri, 26 May 2000 00:09:55 -0400 (EDT) Date: Fri, 26 May 2000 00:09:55 -0400 (EDT) Message-Id: <200005260409.AAA18941@smtp1.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: Mark Crispin Cc: ietf-imapext@imc.org In-reply-to: Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Thu, 25 May 2000 19:46:45 -0700 (PDT) From: Mark Crispin [...] PROBLEM: The group facility doesn't address the problem, and in fact creates more problems than it solves; it completely swallows the entire $ syntax for a functionality that isn't otherwise specified (e.g. how do you manage groups?). Why should group management be part of IMAP? Groups logically come from an authorization server; whether that's an LDAP server sitting somewhere, or (unfortunately) an AFS PTS server somewhere else, it really doesn't matter---it's the authorization server's decision whether an authorization identifier is included in a group. [...] Although removing the ambiguity is a good idea, I question whether it's really such a good idea to insist upon inheritance. In particular, the inheritance of negative rights is problematic. What is problematic about it? It's a straightforward algorithm to implement in deciding whether to grant or deny rights. The proposed modification complicates semantics significantly. Is there operational experience that this level of flexibility is needed? I think this draft fixes a number of known problems with the current ACL extension in a compatible, straightforward way. Larry Received: by ns.secondary.com (8.9.3/8.9.3) id UAA17486 for ietf-imapext-bks; Thu, 25 May 2000 20:13:12 -0700 (PDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA17479 for ; Thu, 25 May 2000 20:13:10 -0700 (PDT) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id UAA27893; Thu, 25 May 2000 20:20:24 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (tonyb@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id UAA22227; Thu, 25 May 2000 20:20:24 -0700 Date: Thu, 25 May 2000 19:46:45 -0700 (PDT) From: Mark Crispin Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt To: Simon Josefsson cc: ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have reviewed the subject Internet Draft. It's completely inadequate for the task at hand. It looks like all the discussion of the past three years has gone in one ear and out the other. PROBLEM: The group facility doesn't address the problem, and in fact creates more problems than it solves; it completely swallows the entire $ syntax for a functionality that isn't otherwise specified (e.g. how do you manage groups?). RECOMMENDATION: The draft be modified to reserve names beginning with $ for use by an extension to ACL. PROBLEM: Unlike RFC 2086, this new draft requires rights inheritance; that is, an identifier automatically has the rights of "anyone" unless these are specifically denied as negative rights. RFC 2086 allowed implementations to decide if rights were inherited or not. Although removing the ambiguity is a good idea, I question whether it's really such a good idea to insist upon inheritance. In particular, the inheritance of negative rights is problematic. RECOMMENDATION: The draft should be modified to indicate whether or not an identifier has inheritance semantics. I suggest using + for this purpose. In other words: +anyone lr means that all users can list and read the mailbox unless specifically denied by a - identifier, whereas: anyone lr means that all users who aren't otherwise listed by an identifier can read and list the mailbox. Also, + and - can be combined to cause negative rights inheritance. For example fred lr -$G$students lr anyone lr means that everybody except for members of the students group can read and list; however fred can also read and list even though he's a member of students. On the other hand +-anyone lr means that nobody can read or list the file, no matter who (this is what - is defined to do in the draft). I am working on an upwards-compatible replacement for ACL called ACLPLUS which addresses these (and other) deficiencies. Any RFC 2086 implementation will be able to talk to an ACLPLUS implementation, although the function set will be limited to what RFC 2086 supports. I urge that action be deferred until I have a chance to produce an Internet Draft containing my ACLPLUS specification. Received: by ns.secondary.com (8.9.3/8.9.3) id FAA07403 for ietf-imapext-bks; Thu, 25 May 2000 05:47:06 -0700 (PDT) Received: from badis.pdc.kth.se (IDENT:root@badis.pdc.kth.se [130.237.221.45]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07398 for ; Thu, 25 May 2000 05:47:04 -0700 (PDT) Received: (from jas@localhost) by badis.pdc.kth.se (8.10.0/8.10.0) id e4PCsSF13535; Thu, 25 May 2000 14:54:28 +0200 To: ietf-imapext@imc.org Subject: Re: I-D ACTION:draft-ietf-imapext-acl-00.txt References: <200005251035.GAA02908@ietf.org> In-Reply-To: Internet-Drafts@ietf.org's message of "Thu, 25 May 2000 06:35:17 -0400" From: Simon Josefsson Date: 25 May 2000 14:54:27 +0200 Message-ID: Lines: 15 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.6 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: Two little thoughts . If identifiers starting with dollar signs are reserved for groups, why don't describe what "groups" are and how they work too? I'd really like IMAP ACLs on groups of users, but I'm not sure there is enough detail to implement it server-independently. . Perhaps it should be noted in the security considerations that the ACL evaluation now required might breach security if rfc2086-ACL's are used in a server implementing this draft? I dunno much about the draft, or anything, at all, so feel free to ignore my comments if they doesn't make sense. (Wasn't there talk of a major re-design of IMAP ACLs?) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA02277 for ietf-imapext-bks; Thu, 25 May 2000 03:28:04 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA02273 for ; Thu, 25 May 2000 03:28:03 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02908; Thu, 25 May 2000 06:35:17 -0400 (EDT) Message-Id: <200005251035.GAA02908@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-acl-00.txt Date: Thu, 25 May 2000 06:35:17 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : IMAP4 ACL extension Author(s) : J. Myers Filename : draft-ietf-imapext-acl-00.txt Pages : 9 Date : 24-May-00 The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imapext-acl-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-acl-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-acl-00.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: <20000524122335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-acl-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-acl-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000524122335.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23705 for ietf-imapext-bks; Tue, 9 May 2000 10:44:52 -0700 (PDT) Received: from scooby.lineone.net ([194.75.152.224]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23285; Tue, 9 May 2000 10:36:53 -0700 (PDT) Received: from ukd ([195.171.177.9]) by scooby.lineone.net (8.9.3/8.9.3) with SMTP id QAA21977; Tue, 9 May 2000 16:27:42 +0100 (BST) Message-ID: <013c01bfb9cc$8f482480$09b1abc3@ukd> From: "Charlie Fletcher - www.ukdata.com" To: "Finance Director" Subject: Instant On-Line Credit Reports Date: Tue, 9 May 2000 16:34:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Do you need fast accurate information to assist you when appraising potential customers, and suppliers? The UK Data internet website www.ukdata.com contains 28 million pages of data with full information on every UK company! Credit Reports-Director Searches-Accounts-Annual Returns All of these products and many more are available to you immediately, and can be downloaded to and printed from your personal computer. Free samples of all reports are available at www.ukdata.com. Please also visit www.formacompany.co.uk the on-line company formation website Thank You Charles Fletcher www.ukdata.com an instant report on every UK business www.formacompany.co.uk the on-line company formation site www.irishdata.ie - instant reports on all Irish companies