Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TLZZqn064509; Thu, 29 Jan 2004 13:35:35 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TLZZ0V064508; Thu, 29 Jan 2004 13:35:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TLZWg0064482 for ; Thu, 29 Jan 2004 13:35:34 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0TLZWTZ025024; Thu, 29 Jan 2004 13:35:32 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0TLZVS6016305 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Jan 2004 13:35:32 -0800 Date: Thu, 29 Jan 2004 13:33:28 -0800 (Pacific Standard Time) From: Mark Crispin To: Rob Siemborski cc: Pete Resnick , ietf-imapext@imc.org, Charlie Kaufman Subject: Re: Fwd: Request for security review In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 29 Jan 2004, Rob Siemborski wrote: > > As we've discussed already, UNION-based ACL semantics is incapable of > > representing filesystem semantics. > I didn't say *only* union of course. The current ACL2 draft addresses > this issue just fine. OK with me. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TLUQEl063476; Thu, 29 Jan 2004 13:30:26 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TLUQLL063475; Thu, 29 Jan 2004 13:30:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TLUOV3063468 for ; Thu, 29 Jan 2004 13:30:25 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i0TLUNdk003651; Thu, 29 Jan 2004 16:30:23 -0500 Date: Thu, 29 Jan 2004 16:30:23 -0500 (EST) From: Rob Siemborski To: Mark Crispin cc: Pete Resnick , ietf-imapext@imc.org, Charlie Kaufman Subject: Re: Fwd: Request for security review In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 29 Jan 2004, Mark Crispin wrote: > As we've discussed already, UNION-based ACL semantics is incapable of > representing filesystem semantics. I didn't say *only* union of course. The current ACL2 draft addresses this issue just fine. > > b) some way to represent the "large enough but not too large" mechanism > > within the ACL2 semantics. > > That's fine with me, but wouldn't it be simpler to do my idea of saying > that the way to enable ACL is to set the "large enough but not too large" > to deny-all? This would, of course, depend somewhat on whatever "large enough but not too large" became in the long run. I can see models where there is no distinction and models where there is. However, I'd prefer us following up on (a) before we decide we definately need a second non-trivial model. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TLQb1B062741; Thu, 29 Jan 2004 13:26:37 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TLQbP3062738; Thu, 29 Jan 2004 13:26:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TLQapk062718 for ; Thu, 29 Jan 2004 13:26:36 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0TLQZGN031123; Thu, 29 Jan 2004 13:26:36 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0TLQZS6015091 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Jan 2004 13:26:35 -0800 Date: Thu, 29 Jan 2004 13:24:32 -0800 (Pacific Standard Time) From: Mark Crispin To: Rob Siemborski cc: Pete Resnick , ietf-imapext@imc.org, Charlie Kaufman Subject: Re: Fwd: Request for security review In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 29 Jan 2004, Rob Siemborski wrote: > I suspect doing the modifications to ACL2 so as to advertise the semantics > of how identifiers are handled (as we discussed in the middle of last > year) might be the way to go. I agree to this. > > 2) Adopt a simplified ACL2 and a separate "large enough but not too large" > > mechanism for compatibility. If the latter turns out to be the only > > one that is widely implemented, that's life. > If we want to go this way instead, I'd want to make sure we see the > following: > a) backwards compatibility (or atleast a sane upgrade path that doesn't > result in the interpretation of ACLs being changed -- this is NOT the same > as a server being able to advertise both ACL and ACL2 at the same time) > for UNION-based ACL implementations. As we've discussed already, UNION-based ACL semantics is incapable of representing filesystem semantics. > b) some way to represent the "large enough but not too large" mechanism > within the ACL2 semantics. That's fine with me, but wouldn't it be simpler to do my idea of saying that the way to enable ACL is to set the "large enough but not too large" to deny-all? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TKqiGg055119; Thu, 29 Jan 2004 12:52:44 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TKqibc055118; Thu, 29 Jan 2004 12:52:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TKqg6p055079 for ; Thu, 29 Jan 2004 12:52:42 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from d154-5-112-162.bchsia.telus.net (d154-5-112-162.bchsia.telus.net [154.5.112.162]) (authenticated bits=0) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id i0TKqRTh027790; Thu, 29 Jan 2004 13:52:28 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Thu, 29 Jan 2004 12:52:22 -0800 From: Lyndon Nerenberg To: ietf-imapext@imc.org cc: Charlie Kaufman Subject: Re: Fwd: Request for security review Message-ID: <2147483647.1075380742@d154-5-112-162.bchsia.telus.net> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on orthanc.ca Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-1-29 3:21 PM -0500 Rob Siemborski wrote: > I suspect doing the modifications to ACL2 so as to advertise the > semantics of how identifiers are handled (as we discussed in the > middle of last year) might be the way to go. I don't think we have any other choice. "Hope and pray" security semantics simply don't cut it. The result of a security operation *must* be deterministic, otherwise you can't call it "secure" in any sense of the word. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TKLGx6048131; Thu, 29 Jan 2004 12:21:16 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TKLGVn048130; Thu, 29 Jan 2004 12:21:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TKLE4t048123 for ; Thu, 29 Jan 2004 12:21:15 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i0TKLDdk003567; Thu, 29 Jan 2004 15:21:13 -0500 Date: Thu, 29 Jan 2004 15:21:13 -0500 (EST) From: Rob Siemborski To: Mark Crispin cc: Pete Resnick , ietf-imapext@imc.org, Charlie Kaufman Subject: Re: Fwd: Request for security review In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 29 Jan 2004, Mark Crispin wrote: > I see the acceptable solutions as: > > 1) Adopt ACL2, declare victory, and go home. If it's a lot of work for > everybody, that's life. Since the major objection (that I know of) to doing this is that "clients can't understand what's about to happen", and one of Charlie's comments is: >> Going back to my first inclination, I would urge the designers to put something in the protocol whereby a client can ask a server for a name and version of its implementation so that clients that want to be agile can figure out what's going on rather than poking and guessing. << I suspect doing the modifications to ACL2 so as to advertise the semantics of how identifiers are handled (as we discussed in the middle of last year) might be the way to go. > 2) Adopt a simplified ACL2 and a separate "large enough but not too large" > mechanism for compatibility. If the latter turns out to be the only > one that is widely implemented, that's life. If we want to go this way instead, I'd want to make sure we see the following: a) backwards compatibility (or atleast a sane upgrade path that doesn't result in the interpretation of ACLs being changed -- this is NOT the same as a server being able to advertise both ACL and ACL2 at the same time) for UNION-based ACL implementations. b) some way to represent the "large enough but not too large" mechanism within the ACL2 semantics. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TI7K8Q033037; Thu, 29 Jan 2004 10:07:20 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TI7JgO033036; Thu, 29 Jan 2004 10:07:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TI7IkX033030 for ; Thu, 29 Jan 2004 10:07:18 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0TI7JMM004527; Thu, 29 Jan 2004 10:07:19 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0TI7JrF025304; Thu, 29 Jan 2004 10:07:19 -0800 Date: Thu, 29 Jan 2004 10:07:19 -0800 (PST) From: Mark Crispin To: Pete Resnick cc: ietf-imapext@imc.org, Charlie Kaufman Subject: Re: Fwd: Request for security review In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thank you Charlie for your security review. Tndeed, your observation that RFC 2086 "impl[ies] that there is no one correct behavior and that a client that wants to know the exact semantics of the server will have to experiment to figure it out." This is one of the bugs of RFC 2086 that needs to be fixed. Here's some background: You are correct in identifying a conflict between "backwards compatibility" and "doing it right". There is another conflict, this one between "ideal" (at least in some viewpoints) and "compatible with (and implementable on) existing mail stores." The "ideal" camp once claimed that "compatible" was a proper subset of "ideal". In RFC 2086, it provably isn't; not only are some valid access controls in "ideal" not expressible in "compatible", but some valid access controls in "compatible" are not expressible in "ideal". ACL2 is an attempt, first to resolve the ambiguities in RFC 2086 and to ensure that "compatible" is a proper subset. Doing this made ACL2 quite a bit more complicated than RFC 2086. The "ideal" camp is unhappy about this. The "compatible" camp, on the other hand, sees that it's being put through a great deal of complexity anyway, so they don't sympathize; rather, they see it as necessary for ACL to be implementable at all. Rob's strawman was an attempt to reduce the complexity for the "ideal" camp by providing a smaller mechanism for the "compatible" camp. Unfortunately, the smaller mechanism is too small for the "compatible" camp, but with a few minor extensions it would be fine -- "large enough but not too large." There is a suspicion, held by both camps, that the "large enough but not too large" mechanism desired by the "compatible" camp will be "good enough" for almost all users. The resulting positions taken by the players are obvious. :-) I see the acceptable solutions as: 1) Adopt ACL2, declare victory, and go home. If it's a lot of work for everybody, that's life. 2) Adopt a simplified ACL2 and a separate "large enough but not too large" mechanism for compatibility. If the latter turns out to be the only one that is widely implemented, that's life. I see the following as unacceptable: 1) Retain RFC 2086. 2) Simplify ACL2 without any attempt to support compatible access control. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TGukj0028208; Thu, 29 Jan 2004 08:56:46 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TGukB2028207; Thu, 29 Jan 2004 08:56:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TGuiZQ028201 for ; Thu, 29 Jan 2004 08:56:45 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b4); Thu, 29 Jan 2004 10:56:42 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.1a9] Date: Thu, 29 Jan 2004 10:56:42 -0600 To: ietf-imapext@imc.org From: Pete Resnick Subject: Fwd: Request for security review Cc: Charlie Kaufman Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Below is the security review of ACL that I asked Charlie Kaufman to do for us. I've Cc'ed Charlie on this; please reply to all if you have questions or comments on this review. --- begin forwarded text Subject: RE: Request for security review - IMAPEXT Date: Sun, 25 Jan 2004 20:35:34 -0800 From: "Charlie Kaufman" To: "Pete Resnick" I read RFC 2086, draft-ietf-imapext-acl-09.txt, Rob Siemborski's 14 Nov email "Yet another ACL Strawman", and his email of 7 Jan questioning the wisdom of layering two subtly different security systems. I couldn't get from that the full set of proposals and arguments, but I think I get the gist. This effort is clearly dealing with problems to standards groups: backwards compatibility vs. "doing it right", different opinions as to what "doing it right" means, and the temptation to compromise by having the standard allow many variations so that everyone can do their own thing at the expense of interoperability. While my first inclination is to jump in and try to propose my version of "doing it right", first let me respond to the question you asked: are any of these proposals unacceptable from a security standpoint (which could help narrow the decision space). My answer, sadly, is 'no'. While it is particularly dangerous to allow ambiguity in a spec with respect to security semantics, RFC 2086 set the bar on the bottom of page 2 with "An implementation may tie rights together or may force rights to always or never be granted to particular identifiers" and on the top of page 3 with "How these rights are combined to determine the user's access is implementation-defined". These imply that there is no one correct behavior and that a client that wants to know the exact semantics of the server will have to experiment to figure it out. None of the proposed revisions (that I looked at) make this situation substantially worse. So I don't think anyone can make any strong security arguments for or against the layering. Going back to my first inclination, I would urge the designers to put something in the protocol whereby a client can ask a server for a name and version of its implementation so that clients that want to be agile can figure out what's going on rather than poking and guessing. --- end forwarded text -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0OLZUib066737; Sat, 24 Jan 2004 13:35:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0OLZUAg066733; Sat, 24 Jan 2004 13:35:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from [63.202.92.156] (adsl-63-202-92-156.dsl.snfc21.pacbell.net [63.202.92.156]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0OLZMic066706; Sat, 24 Jan 2004 13:35:22 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Sat, 24 Jan 2004 13:35:24 -0800 To: (various IETF lists) From: Paul Hoffman / IMC Subject: New mail-ng mailing list open for sign-ups Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings again. There seems to be more discussion these days about replacing SMTP and/or RFC 2822 and/or POP/IMAP for a variety of reasons. The discussion seems to pop up on a few different lists and in a few different hallways, and it might be good to have a single list where folks can congregate. Thus, I have set up a mail-ng mailing list. The first task probably is to determine what the next generation of mail should do, and how that is different than what SMTP/2822/POP-or-IMAP or instant messaging does. It is safe to say that we can ignore actual protocol proposals for many months (if not years) until we figure out what is needed. Once we do that, there are plenty of protocol people who can attack the decided-on requirements. There is no expectation that there will be significant agreement on the list. It is likely that over time the discussion will split into camps of like-minded design goals. The list might then spawn different lists for the folks of the different camps (mail-ng-shoe, mail-ng-sandal, ...). The list is explicitly not yet meant to be an IETF working group yet (if at all), and is probably more akin to the IRTF. But at the beginning, it will most likely be talking, not research. See for information on how to subscribe. The list is taking subscriptions now, and will probably go live for discussions within a week. Having some discussion on a mailing list now should make the dinners and bar gatherings at Seoul more interesting. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NJ6Eib014607; Fri, 23 Jan 2004 11:06:14 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0NJ6EJL014606; Fri, 23 Jan 2004 11:06:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NJ6Dib014600 for ; Fri, 23 Jan 2004 11:06:13 -0800 (PST) (envelope-from apache@asgard.ietf.org) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1Ak6d0-0007i7-25; Fri, 23 Jan 2004 14:06:02 -0500 X-test-idtracker: no To: IETF-Announce :; From: The IESG Subject: Last Call: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Fri, 23 Jan 2004 14:06:02 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Internet Message Access Protocol Extension WG to consider the following document: - 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-02-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-14.txt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0L0bhib098823; Tue, 20 Jan 2004 16:37:43 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0L0bhRC098822; Tue, 20 Jan 2004 16:37:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0L0bfib098815 for ; Tue, 20 Jan 2004 16:37:42 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [129.46.76.186] (129.46.76.186) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b4) for ; Tue, 20 Jan 2004 18:37:40 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.1a9] Date: Tue, 20 Jan 2004 16:37:39 -0800 To: ietf-imapext@imc.org From: Pete Resnick Subject: Re: Yet another ACL Strawman 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 1/7/04 at 1:03 PM -0600, I wrote: >On 1/7/04 at 1:46 PM -0500, Rob Siemborski wrote: > >>It may help to get IESG/Security area comments on: >> >>a) the current ACL2 draft >>b) ACL2 with the behavior description announcement (as discussed >> by the most recent thread) >>c) Layering of two systems > >I'll try to find a security person with enough mail-clue to help us out. Charlie Kaufman has kindly accepted my request to have a gander. -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FDu2ib045430; Thu, 15 Jan 2004 05:56:02 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0FDu24s045429; Thu, 15 Jan 2004 05:56:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FDtuib045423 for ; Thu, 15 Jan 2004 05:55:56 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (69-161-93-210.bflony.adelphia.net [69.161.93.210]) (authenticated bits=0) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id i0FDtmTN020538 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 15 Jan 2004 08:55:51 -0500 (EST) Message-ID: <40069BE3.4070803@oceana.com> Date: Thu, 15 Jan 2004 08:55:47 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031020 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> <40059A94.3000700@oceana.com> <4005CBB7.2090308@isode.com> In-Reply-To: <4005CBB7.2090308@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Ken Murchison wrote: > >> Ken Murchison wrote: >> >>> I just starting working on a CONDSTORE implementation in Cyrus, and I >>> wanted to make a few comments/suggestions before the document gets >>> too far along in the queue. >>> >>> Here is what I have come up with over the last day. I might have >>> more as I get further into my implementation. >> >> >> >> Section 3.6: The phrase in the first sentence "to include >> mod-sequence" should be changed to read "to include the highest >> mod-sequence". > > > Correct (as per your explanation below) > >> Since the mod-sequence being returned in the untagged SEARCH, SORT and >> possibly THREAD responses is the *highest* of the messages in the >> response, shouldn't the extended response tag be HIGHESTMODSEQ instead >> of MODSEQ? This seems more intuitive, unless you think it conflicts >> with the HIGHESTMODSEQ response code. > > > I would like not to change syntax at this point. Once again, the draft > is already approved as RFC. Right, I understand. I'd also like to see SEARCH MODSEQ changed to SEARCH CHANGEDSINCE if we had the time. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FBSOib038404; Thu, 15 Jan 2004 03:28:24 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0FBSOcS038402; Thu, 15 Jan 2004 03:28:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FBSCib038388 for ; Thu, 15 Jan 2004 03:28:19 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 15 Jan 2004 11:27:53 +0000 Message-ID: <4005CBB7.2090308@isode.com> Date: Wed, 14 Jan 2004 23:07:35 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Murchison CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> <40059A94.3000700@oceana.com> In-Reply-To: <40059A94.3000700@oceana.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > Ken Murchison wrote: > >> I just starting working on a CONDSTORE implementation in Cyrus, and I >> wanted to make a few comments/suggestions before the document gets >> too far along in the queue. >> >> Here is what I have come up with over the last day. I might have >> more as I get further into my implementation. > > > Section 3.6: The phrase in the first sentence "to include > mod-sequence" should be changed to read "to include the highest > mod-sequence". Correct (as per your explanation below) > Since the mod-sequence being returned in the untagged SEARCH, SORT and > possibly THREAD responses is the *highest* of the messages in the > response, shouldn't the extended response tag be HIGHESTMODSEQ instead > of MODSEQ? This seems more intuitive, unless you think it conflicts > with the HIGHESTMODSEQ response code. I would like not to change syntax at this point. Once again, the draft is already approved as RFC. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FBSOib038405; Thu, 15 Jan 2004 03:28:24 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0FBSOSh038403; Thu, 15 Jan 2004 03:28:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FBSCic038388 for ; Thu, 15 Jan 2004 03:28:20 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 15 Jan 2004 11:27:54 +0000 Message-ID: <4005CC5E.4080600@isode.com> Date: Wed, 14 Jan 2004 23:10:22 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Murchison CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> <4005945E.5070508@oceana.com> In-Reply-To: <4005945E.5070508@oceana.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > Ken Murchison wrote: > >> I just starting working on a CONDSTORE implementation in Cyrus, and I >> wanted to make a few comments/suggestions before the document gets >> too far along in the queue. >> >> Here is what I have come up with over the last day. I might have >> more as I get further into my implementation. > > The first two examples in section 3.5 are reversed (the first shows > the MODSEQ sort crit, and the second shows the MODSEQ search crit). Good catch. Fixed. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EJahib022803; Wed, 14 Jan 2004 11:36:43 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EJahEO022802; Wed, 14 Jan 2004 11:36:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EJafib022796 for ; Wed, 14 Jan 2004 11:36:41 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id i0EJabTM010713; Wed, 14 Jan 2004 14:36:37 -0500 (EST) Message-ID: <40059A94.3000700@oceana.com> Date: Wed, 14 Jan 2004 14:37:56 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> In-Reply-To: <40007395.10403@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > > I just starting working on a CONDSTORE implementation in Cyrus, and I > wanted to make a few comments/suggestions before the document gets too > far along in the queue. > > Here is what I have come up with over the last day. I might have more > as I get further into my implementation. Section 3.6: The phrase in the first sentence "to include mod-sequence" should be changed to read "to include the highest mod-sequence". Since the mod-sequence being returned in the untagged SEARCH, SORT and possibly THREAD responses is the *highest* of the messages in the response, shouldn't the extended response tag be HIGHESTMODSEQ instead of MODSEQ? This seems more intuitive, unless you think it conflicts with the HIGHESTMODSEQ response code. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EJADib021837; Wed, 14 Jan 2004 11:10:13 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EJAD5w021836; Wed, 14 Jan 2004 11:10:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EJABib021829 for ; Wed, 14 Jan 2004 11:10:12 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id i0EJA8TM010402; Wed, 14 Jan 2004 14:10:08 -0500 (EST) Message-ID: <4005945E.5070508@oceana.com> Date: Wed, 14 Jan 2004 14:11:26 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> In-Reply-To: <40007395.10403@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > > I just starting working on a CONDSTORE implementation in Cyrus, and I > wanted to make a few comments/suggestions before the document gets too > far along in the queue. > > Here is what I have come up with over the last day. I might have more > as I get further into my implementation. The first two examples in section 3.5 are reversed (the first shows the MODSEQ sort crit, and the second shows the MODSEQ search crit). -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EIPNib020171; Wed, 14 Jan 2004 10:25:23 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EIPNdv020170; Wed, 14 Jan 2004 10:25:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EIPMib020165 for ; Wed, 14 Jan 2004 10:25:22 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 14 Jan 2004 18:25:10 +0000 Message-ID: <40058982.8080201@isode.com> Date: Wed, 14 Jan 2004 18:25:06 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Hole CC: Ken Murchison , IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40057D4B.8080501@oceana.com> <40055571.8050008@oceana.com> <40007395.10403@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve Hole wrote: >On Wed, 14 Jan 2004 12:32:59 -0500 Ken Murchison wrote: > > >>So, assume the client is CONDSTORE enabled, and then sends: >> >>FETCH 1:* ENVELOPE >> >>We should return the MODSEQ for each message? That seems >>counter-intuitive. First, the client didn't ask for it, and second, any >>meta-data changes would be sent in the form of unsolicited FETCH >>responses anyways. >> >> > >Ah ... I see what you're after. > >You would include any changed MODSEQ as unsolicited data. You don't need >to include the MODSEQ for unchanged items as along with the ENVELOPE >response. > I agree, but the document has to clarify this. >A more interesting question is something like: > > FETCH 2:4 ENVELOPE > >and there is a changed MODSEQ for message 7 -- should you issue and >unsolicited MODSEQ for it triggered by the FETCH even though it is >outside the fetch set. The answer is yes because you want to learn about >the state change as soon as possible in the application (just like FLAGS). >The client can always ignore the data. > > >>Am I missing something? >> >> >No. I just didn't get what you were asking. Sorry about that. > >Cheers. > > Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EIKUib019983; Wed, 14 Jan 2004 10:20:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EIKUti019982; Wed, 14 Jan 2004 10:20:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EIKKib019974 for ; Wed, 14 Jan 2004 10:20:25 -0800 (PST) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id i0EIJqG19231; Wed, 14 Jan 2004 11:19:52 -0700 From: Steve Hole Date: Wed, 14 Jan 2004 11:19:57 -0700 To: Ken Murchison Subject: Re: draft-ietf-imapext-condstore-05 Cc: Alexey Melnikov , IMAP Extensions WG In-Reply-To: <40057D4B.8080501@oceana.com> References: <40057D4B.8080501@oceana.com> <40055571.8050008@oceana.com> <40007395.10403@oceana.com> Message-ID: X-Mailer: Execmail for Linux 6.0.0 beta Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0EIKPib019976 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 14 Jan 2004 12:32:59 -0500 Ken Murchison wrote: > So, assume the client is CONDSTORE enabled, and then sends: > > FETCH 1:* ENVELOPE > > We should return the MODSEQ for each message? That seems > counter-intuitive. First, the client didn't ask for it, and second, any > meta-data changes would be sent in the form of unsolicited FETCH > responses anyways. Ah ... I see what you're after. You would include any changed MODSEQ as unsolicited data. You don't need to include the MODSEQ for unchanged items as along with the ENVELOPE response. A more interesting question is something like: FETCH 2:4 ENVELOPE and there is a changed MODSEQ for message 7 -- should you issue and unsolicited MODSEQ for it triggered by the FETCH even though it is outside the fetch set. The answer is yes because you want to learn about the state change as soon as possible in the application (just like FLAGS). The client can always ignore the data. > Am I missing something? No. I just didn't get what you were asking. Sorry about that. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EHVkib018000; Wed, 14 Jan 2004 09:31:46 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EHVk2c017999; Wed, 14 Jan 2004 09:31:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EHVjib017994 for ; Wed, 14 Jan 2004 09:31:45 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id i0EHVfTM009402; Wed, 14 Jan 2004 12:31:41 -0500 (EST) Message-ID: <40057D4B.8080501@oceana.com> Date: Wed, 14 Jan 2004 12:32:59 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Steve Hole CC: Alexey Melnikov , IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40055571.8050008@oceana.com> <40007395.10403@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve Hole wrote: > On Wed, 14 Jan 2004 09:42:57 -0500 Ken Murchison wrote: > > >>Ken Murchison wrote: > >>Other issue: The end of section 2 says that once a CONDSTORE enabling >>command is used by the client, that *all* FETCH responses must include >>MODSEQ. Is this also the case with responses to a FETCH command, or is >>this still controlled by whether or not the MODSEQ fetch data item is >>used? I'm assuming the latter, but if the former, what's the point of >>having the MODSEQ data item? > > > Once you use a MODSEQ modifier in any command, including FETCH, then you > have to return MODSEQ data in any FETCH response whether solicited or not. > This is because the client will be (presumably) caching and using the > modseq data advisory "locking". So, assume the client is CONDSTORE enabled, and then sends: FETCH 1:* ENVELOPE We should return the MODSEQ for each message? That seems counter-intuitive. First, the client didn't ask for it, and second, any meta-data changes would be sent in the form of unsolicited FETCH responses anyways. Am I missing something? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EH6Mib017076; Wed, 14 Jan 2004 09:06:22 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EH6MRX017075; Wed, 14 Jan 2004 09:06:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EH6Gib017069 for ; Wed, 14 Jan 2004 09:06:16 -0800 (PST) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id i0EH5vG16937; Wed, 14 Jan 2004 10:05:57 -0700 From: Steve Hole Date: Wed, 14 Jan 2004 10:06:02 -0700 To: Ken Murchison Subject: Re: draft-ietf-imapext-condstore-05 Cc: Alexey Melnikov , IMAP Extensions WG In-Reply-To: <40055571.8050008@oceana.com> References: <40055571.8050008@oceana.com> <40007395.10403@oceana.com> Message-ID: X-Mailer: Execmail for Linux 6.0.0 beta Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0EH6Gib017071 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 14 Jan 2004 09:42:57 -0500 Ken Murchison wrote: > Ken Murchison wrote: > > > > > I just starting working on a CONDSTORE implementation in Cyrus, and I > > wanted to make a few comments/suggestions before the document gets too > > far along in the queue. > > > > Here is what I have come up with over the last day. I might have more > > as I get further into my implementation. > > General question: Do the MODSEQ for each message have to be unique, or > can multiple messages have the same MODSEQ? For instance, if I do: > > FETCH 1:* +FLAGS (\Seen) > > can all of the messages have the same MODSEQ? I'd like to think yes. Yes, they can have the same MODSEQ. The MODSEQ is strictly ascending for any change to a particular message. > Other issue: The end of section 2 says that once a CONDSTORE enabling > command is used by the client, that *all* FETCH responses must include > MODSEQ. Is this also the case with responses to a FETCH command, or is > this still controlled by whether or not the MODSEQ fetch data item is > used? I'm assuming the latter, but if the former, what's the point of > having the MODSEQ data item? Once you use a MODSEQ modifier in any command, including FETCH, then you have to return MODSEQ data in any FETCH response whether solicited or not. This is because the client will be (presumably) caching and using the modseq data advisory "locking". Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EEfsib088867; Wed, 14 Jan 2004 06:41:54 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EEfstV088866; Wed, 14 Jan 2004 06:41:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EEfiib088853 for ; Wed, 14 Jan 2004 06:41:44 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id i0EEfdTM007865; Wed, 14 Jan 2004 09:41:39 -0500 (EST) Message-ID: <40055571.8050008@oceana.com> Date: Wed, 14 Jan 2004 09:42:57 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> In-Reply-To: <40007395.10403@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > > I just starting working on a CONDSTORE implementation in Cyrus, and I > wanted to make a few comments/suggestions before the document gets too > far along in the queue. > > Here is what I have come up with over the last day. I might have more > as I get further into my implementation. General question: Do the MODSEQ for each message have to be unique, or can multiple messages have the same MODSEQ? For instance, if I do: FETCH 1:* +FLAGS (\Seen) can all of the messages have the same MODSEQ? I'd like to think yes. Other issue: The end of section 2 says that once a CONDSTORE enabling command is used by the client, that *all* FETCH responses must include MODSEQ. Is this also the case with responses to a FETCH command, or is this still controlled by whether or not the MODSEQ fetch data item is used? I'm assuming the latter, but if the former, what's the point of having the MODSEQ data item? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0BJNBib064505; Sun, 11 Jan 2004 11:23:11 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0BJNAOM064504; Sun, 11 Jan 2004 11:23:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0BJN9ib064498 for ; Sun, 11 Jan 2004 11:23:10 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 11 Jan 2004 19:23:08 +0000 Message-ID: <4001A29A.6090400@isode.com> Date: Sun, 11 Jan 2004 19:23:06 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Murchison CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> <40009847.9000006@oceana.com> In-Reply-To: <40009847.9000006@oceana.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > Ken Murchison wrote: > >> I just starting working on a CONDSTORE implementation in Cyrus, and I >> wanted to make a few comments/suggestions before the document gets >> too far along in the queue. >> >> Here is what I have come up with over the last day. I might have >> more as I get further into my implementation. > > The grammar doesn't seem to include the extension of SELECT/EXAMINE > for the CONDSTORE parameter. If I remember correctly the generic syntax for SELECT/EXAMINE parameters is defined in ANNOTATE document, which is a normative reference for CONDSTORE. > Is this supposed to be a generic extension and CONDSTORE is one such > parameter, or the only valid parameter is CONDSTORE? The former. > If the latter, is there a reason why the parameter is in the form of > a list? Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0BJMPib064486; Sun, 11 Jan 2004 11:22:25 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0BJMP9i064485; Sun, 11 Jan 2004 11:22:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0BJMFib064470 for ; Sun, 11 Jan 2004 11:22:19 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 11 Jan 2004 19:22:04 +0000 Message-ID: <4001A259.1010600@isode.com> Date: Sun, 11 Jan 2004 19:22:01 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Murchison CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> In-Reply-To: <40007395.10403@oceana.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > I just starting working on a CONDSTORE implementation in Cyrus, and I > wanted to make a few comments/suggestions before the document gets too > far along in the queue. > > Here is what I have come up with over the last day. I might have more > as I get further into my implementation. > > - As a general note, should the STORE/FETCH modifier syntax be broken > out into a separate draft and then referenced by CONDSTORE? I thought about this as well. I don't remember now, but I thought I've asked this question on the mailing list. Anyway, CONDSTORE is approved as RFC now and I fear it will take another 3 years before updated CONDSTORE and that separate document get published. > Any subsequent draft which introduces a new modifier will have to > reference CONDSTORE, which seems a bit awkward. > > - Section 2 doesn't mention STATUS (HIGHESTMODSEQ) as a CONDSTORE > enabling command? Is this by design or an oversight? An oversight. > - Section 3.1.1 leads me to believe that HIGHESTMODSEQ is *always* > returned for SELECT/EXAMINE. That is correct. > Why is this necessary when we explicitly have CONSTORE enabling > commands which require that we return HIGHESTMODSEQ? It seems > redundant that weShould we just return HIGHESTMODSEQ for > SELECT/EXAMINE CONDSTORE? would return this on SELECT/EXAMINE and then > again on the first CONDSTORE-specific STORE/FETCH. You are probably right, but I don't see a problem with returning HIGHESTMODSEQ on the first CONDSTORE-aware STORE/FETCH. If Ned agrees that just returning HIGHESTMODSEQ on SELECT/EXAMINE CONDSTORE is not a substantial change to the document, I can try to modify it. > - Section 3.2, first example: the MODSEQ value of UID 6 is less than > UNCHANGEDSINCE Good catch. > - Section 3.3.1 leaves out "OPTIONAL fetch modifiers" as the last > argument. Corrected in my copy, thanks. > - Section 4. The grammar for the STORE and FETCH modifiers seem > inconsistent with one another. The STORE grammar defines > UNCHANGEDSINCE as the only modifier, where FETCH defines the modifier > in general terms, and has the chgsince-fetch-mod terminal unused. The latter approach is probably better. chgsince-fetch-mod is not really unused. There is a comment that it conforms to fetch-modifier syntax. > - Does the MODSEQ search criterion also apply to THREAD in the same > way that it does to SORT? Yes, search criterion applies to all commands that make use of it. > - Grammatical nits: > > Section 2, paragraph 3, sentence 2: perhaps replacing both instances > of "and before" with "where previously" would read better. > > Section 3.1, paragraph 1, sentence 2: "SELECT and EXAMINE commands" > should probably read "SELECT or EXAMINE command" I've changed this in my copy, thanks. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0B0R2ib042015; Sat, 10 Jan 2004 16:27:02 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0B0R2b8042014; Sat, 10 Jan 2004 16:27:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0B0Qvib042005 for ; Sat, 10 Jan 2004 16:26:57 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (69-161-93-210.bflony.adelphia.net [69.161.93.210]) (authenticated bits=0) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id i0B0QrTN003701 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 10 Jan 2004 19:26:54 -0500 (EST) Message-ID: <40009847.9000006@oceana.com> Date: Sat, 10 Jan 2004 19:26:47 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov , Steve.Hole@MessagingDirect.com CC: IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> In-Reply-To: <40007395.10403@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > > I just starting working on a CONDSTORE implementation in Cyrus, and I > wanted to make a few comments/suggestions before the document gets too > far along in the queue. > > Here is what I have come up with over the last day. I might have more > as I get further into my implementation. The grammar doesn't seem to include the extension of SELECT/EXAMINE for the CONDSTORE parameter. Is this supposed to be a generic extension and CONDSTORE is one such parameter, or the only valid parameter is CONDSTORE? If the latter, is there a reason why the parameter is in the form of a list? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0ALoaib036035; Sat, 10 Jan 2004 13:50:36 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0ALoa7N036034; Sat, 10 Jan 2004 13:50:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0ALoSib036025 for ; Sat, 10 Jan 2004 13:50:28 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (69-161-93-210.bflony.adelphia.net [69.161.93.210]) (authenticated bits=0) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id i0ALoITN001141 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 10 Jan 2004 16:50:19 -0500 (EST) Message-ID: <40007395.10403@oceana.com> Date: Sat, 10 Jan 2004 16:50:13 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov , Steve.Hole@MessagingDirect.com CC: IMAP Extensions WG Subject: draft-ietf-imapext-condstore-05 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I just starting working on a CONDSTORE implementation in Cyrus, and I wanted to make a few comments/suggestions before the document gets too far along in the queue. Here is what I have come up with over the last day. I might have more as I get further into my implementation. - As a general note, should the STORE/FETCH modifier syntax be broken out into a separate draft and then referenced by CONDSTORE? Any subsequent draft which introduces a new modifier will have to reference CONDSTORE, which seems a bit awkward. - Section 2 doesn't mention STATUS (HIGHESTMODSEQ) as a CONDSTORE enabling command? Is this by design or an oversight? - Section 3.1.1 leads me to believe that HIGHESTMODSEQ is *always* returned for SELECT/EXAMINE. Why is this necessary when we explcitly have CONSTORE enabling commands which require that we return HIGHESTMODSEQ? It seems redundant that we would return this on SELECT/EXAMINE and then again on the first CONDSTORE-specific STORE/FETCH. Should we just return HIGHESTMODSEQ for SELECT/EXAMINE CONDSTORE? - Section 3.2, first example: the MODSEQ value of UID 6 is less than UNCHANGEDSINCE - Section 3.3.1 leaves out "OPTIONAL fetch modifiers" as the last argument. - Section 4. The grammar for the STORE and FETCH modifiers seem inconsistent with one another. The STORE grammar defines UNCHANGEDSINCE as the only modifier, where FETCH defines the modifier in general terms, and has the chgsince-fetch-mod terminal unused. - Does the MODSEQ search criterion also apply to THREAD in the same way that it does to SORT? - Grammatical nits: Section 2, paragraph 3, sentence 2: perhaps replacing both instances of "and before" with "where previously" would read better. Section 3.1, paragraph 1, sentence 2: "SELECT and EXAMINE commands" should probably read "SELECT or EXAMINE command" -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07J3xib068178 for ; Wed, 7 Jan 2004 11:03:59 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07J3xkR068177 for ietf-imapext-bks; Wed, 7 Jan 2004 11:03:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07J3wib068172 for ; Wed, 7 Jan 2004 11:03:58 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3); Wed, 7 Jan 2004 13:03:53 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.1a7] Date: Wed, 7 Jan 2004 13:03:51 -0600 To: Rob Siemborski From: Pete Resnick Subject: Re: Yet another ACL Strawman Cc: Mark Crispin , 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 1/7/04 at 1:46 PM -0500, Rob Siemborski wrote: >It may help to get IESG/Security area comments on: > >a) the current ACL2 draft >b) ACL2 with the behavior description announcement (as discussed > by the most recent thread) >c) Layering of two systems I'll try to find a security person with enough mail-clue to help us out. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07IkUib067419 for ; Wed, 7 Jan 2004 10:46:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07IkU2A067418 for ietf-imapext-bks; Wed, 7 Jan 2004 10:46:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07IkSib067413 for ; Wed, 7 Jan 2004 10:46:28 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i07IkSdL001671; Wed, 7 Jan 2004 13:46:28 -0500 Date: Wed, 7 Jan 2004 13:46:27 -0500 (EST) From: Rob Siemborski To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 29 Dec 2003, Rob Siemborski wrote: > Ok, we were talking about two entirely different PERMISSIONS > descriptions. Now I have a clear(er) picture of yours. > > I'm going to think this over now. After some consideration, I'm still forced to believe that having two distinct permissions systems where one is not a full and proper subset of the other is a poor long-term design choice. However, I am not a security expert, and thus cannot judge the implications of layering PERMISSIONS on top of UNION ACL (or even a MOST-SPECIFIC ACL, which is certainly a better fit). My gut is telling me that this will lead to a very complicated specification that will lead to implementation and interoperability problems. It may help to get IESG/Security area comments on: a) the current ACL2 draft b) ACL2 with the behavior description announcement (as discussed by the most recent thread) c) Layering of two systems -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07Icrib067070 for ; Wed, 7 Jan 2004 10:38:53 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07IcrSb067069 for ietf-imapext-bks; Wed, 7 Jan 2004 10:38:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07Icqib067063 for ; Wed, 7 Jan 2004 10:38:52 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i07IcndL001664; Wed, 7 Jan 2004 13:38:49 -0500 Date: Wed, 7 Jan 2004 13:38:48 -0500 (EST) From: Rob Siemborski To: Timo Sirainen cc: Mark Crispin , ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman In-Reply-To: <621DD0CF-3A4B-11D8-9E05-000393CC2E90@iki.fi> Message-ID: References: <621DD0CF-3A4B-11D8-9E05-000393CC2E90@iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 30 Dec 2003, Timo Sirainen wrote: > I'm not sure if you really understood what Mark said.. It anyway sounds > to me like a quite workable solution. You'd have MOST-SPECIFIC > behaviour but if there's multiple groups, you'd get union of them. > Wouldn't that make it possible to quite easily convert old ACLs to > ACL2? You can keep your old groups, only problems are if you have > combined user, group and world rights. Then you'd have to do something > like: > > user + world: merge world rights directly to user > user + group(s): merge group rights directly to user > group(s) + world: create a new "world" group and give world rights to > world group After consideration, I don't think this is an acceptable upgrade path. Merging rights down to users (especially in the user+groups situation) is a very poor solution for deployments with extensive usage of both groups and users in UNION based ACLs. While it is true that in many cases it will probably be good enough to munge ACLs in this way, once the upgrade is done enterprises that may be used to managing groups in one way (and may be unable to change!) will now have to deal with the fact that removing a user from a group will not necessarily remove the rights that this group once granted to that user. IMAP servers may also not be able to create arbitrary groups (such as a 'world' group), unless this means "create a virtual world group outside of the local group management system" which would only create more problems: Imagine an ACL of: anyone lrs group=anyone lrs When I change the ACL of 'anyone' to lrsp, should the phantom group just track it and become group=anyone lrsp? Is it reasonable for the client to predict this sort of behavior? These problems will have the effect of prohibiting existing ACL servers from upgrading to ACL2 -- this should be just as unacceptable to the working group as forbidding a unix-filesystem based system from having any sort of rights management (especially if, as I have been told, the ACL2 draft started as an attempt to fix the 'd' right situation in ACL and nothing more). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07HOFib062016 for ; Wed, 7 Jan 2004 09:24:15 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07HOFnj062015 for ietf-imapext-bks; Wed, 7 Jan 2004 09:24:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07HO9ib061997 for ; Wed, 7 Jan 2004 09:24:09 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i07HO4nA016154; Wed, 7 Jan 2004 09:24:09 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i07HO4Sh029037; Wed, 7 Jan 2004 09:24:04 -0800 Date: Wed, 7 Jan 2004 09:24:04 -0800 (PST) From: Mark Crispin To: Alexey Melnikov cc: Pete Resnick , ietf-imapext@imc.org Subject: Re: Shall we meet in Seoul? In-Reply-To: <3FFBEEBB.7050807@isode.com> Message-ID: References: <3FFBEEBB.7050807@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 7 Jan 2004, Alexey Melnikov wrote: > > Who is going to be able to make it to Seoul? Do we have items about which we > > need to meet? Would a multicast session make a difference? > I am planning to attend. But I don't have tickets yet, so I can't give any > guaranty. I am not going to be there. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07BYXib042091 for ; Wed, 7 Jan 2004 03:34:33 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07BYXkT042090 for ietf-imapext-bks; Wed, 7 Jan 2004 03:34:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07BYSib042081 for ; Wed, 7 Jan 2004 03:34:32 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 7 Jan 2004 11:34:21 +0000 Message-ID: <3FFBEEBB.7050807@isode.com> Date: Wed, 07 Jan 2004 11:34:19 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Resnick CC: ietf-imapext@imc.org Subject: Re: Shall we meet in Seoul? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Pete Resnick wrote: > Who is going to be able to make it to Seoul? Do we have items about > which we need to meet? Would a multicast session make a difference? I am planning to attend. But I don't have tickets yet, so I can't give any guaranty. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TLZZqn064509; Thu, 29 Jan 2004 13:35:35 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TLZZ0V064508; Thu, 29 Jan 2004 13:35:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TLZWg0064482 for ; Thu, 29 Jan 2004 13:35:34 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0TLZWTZ025024; Thu, 29 Jan 2004 13:35:32 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0TLZVS6016305 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Jan 2004 13:35:32 -0800 Date: Thu, 29 Jan 2004 13:33:28 -0800 (Pacific Standard Time) From: Mark Crispin To: Rob Siemborski cc: Pete Resnick , ietf-imapext@imc.org, Charlie Kaufman Subject: Re: Fwd: Request for security review In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 29 Jan 2004, Rob Siemborski wrote: > > As we've discussed already, UNION-based ACL semantics is incapable of > > representing filesystem semantics. > I didn't say *only* union of course. The current ACL2 draft addresses > this issue just fine. OK with me. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TLUQEl063476; Thu, 29 Jan 2004 13:30:26 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TLUQLL063475; Thu, 29 Jan 2004 13:30:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TLUOV3063468 for ; Thu, 29 Jan 2004 13:30:25 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i0TLUNdk003651; Thu, 29 Jan 2004 16:30:23 -0500 Date: Thu, 29 Jan 2004 16:30:23 -0500 (EST) From: Rob Siemborski To: Mark Crispin cc: Pete Resnick , ietf-imapext@imc.org, Charlie Kaufman Subject: Re: Fwd: Request for security review In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 29 Jan 2004, Mark Crispin wrote: > As we've discussed already, UNION-based ACL semantics is incapable of > representing filesystem semantics. I didn't say *only* union of course. The current ACL2 draft addresses this issue just fine. > > b) some way to represent the "large enough but not too large" mechanism > > within the ACL2 semantics. > > That's fine with me, but wouldn't it be simpler to do my idea of saying > that the way to enable ACL is to set the "large enough but not too large" > to deny-all? This would, of course, depend somewhat on whatever "large enough but not too large" became in the long run. I can see models where there is no distinction and models where there is. However, I'd prefer us following up on (a) before we decide we definately need a second non-trivial model. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TLQb1B062741; Thu, 29 Jan 2004 13:26:37 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TLQbP3062738; Thu, 29 Jan 2004 13:26:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TLQapk062718 for ; Thu, 29 Jan 2004 13:26:36 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0TLQZGN031123; Thu, 29 Jan 2004 13:26:36 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated bits=0) by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0TLQZS6015091 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Jan 2004 13:26:35 -0800 Date: Thu, 29 Jan 2004 13:24:32 -0800 (Pacific Standard Time) From: Mark Crispin To: Rob Siemborski cc: Pete Resnick , ietf-imapext@imc.org, Charlie Kaufman Subject: Re: Fwd: Request for security review In-Reply-To: Message-ID: References: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 29 Jan 2004, Rob Siemborski wrote: > I suspect doing the modifications to ACL2 so as to advertise the semantics > of how identifiers are handled (as we discussed in the middle of last > year) might be the way to go. I agree to this. > > 2) Adopt a simplified ACL2 and a separate "large enough but not too large" > > mechanism for compatibility. If the latter turns out to be the only > > one that is widely implemented, that's life. > If we want to go this way instead, I'd want to make sure we see the > following: > a) backwards compatibility (or atleast a sane upgrade path that doesn't > result in the interpretation of ACLs being changed -- this is NOT the same > as a server being able to advertise both ACL and ACL2 at the same time) > for UNION-based ACL implementations. As we've discussed already, UNION-based ACL semantics is incapable of representing filesystem semantics. > b) some way to represent the "large enough but not too large" mechanism > within the ACL2 semantics. That's fine with me, but wouldn't it be simpler to do my idea of saying that the way to enable ACL is to set the "large enough but not too large" to deny-all? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TKqiGg055119; Thu, 29 Jan 2004 12:52:44 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TKqibc055118; Thu, 29 Jan 2004 12:52:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TKqg6p055079 for ; Thu, 29 Jan 2004 12:52:42 -0800 (PST) (envelope-from lyndon@orthanc.ca) Received: from d154-5-112-162.bchsia.telus.net (d154-5-112-162.bchsia.telus.net [154.5.112.162]) (authenticated bits=0) by orthanc.ca (8.12.9p1/8.12.9) with ESMTP id i0TKqRTh027790; Thu, 29 Jan 2004 13:52:28 -0700 (MST) (envelope-from lyndon@orthanc.ca) Date: Thu, 29 Jan 2004 12:52:22 -0800 From: Lyndon Nerenberg To: ietf-imapext@imc.org cc: Charlie Kaufman Subject: Re: Fwd: Request for security review Message-ID: <2147483647.1075380742@d154-5-112-162.bchsia.telus.net> In-Reply-To: References: X-Mailer: Mulberry/3.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on orthanc.ca Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2004-1-29 3:21 PM -0500 Rob Siemborski wrote: > I suspect doing the modifications to ACL2 so as to advertise the > semantics of how identifiers are handled (as we discussed in the > middle of last year) might be the way to go. I don't think we have any other choice. "Hope and pray" security semantics simply don't cut it. The result of a security operation *must* be deterministic, otherwise you can't call it "secure" in any sense of the word. --lyndon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TKLGx6048131; Thu, 29 Jan 2004 12:21:16 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TKLGVn048130; Thu, 29 Jan 2004 12:21:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TKLE4t048123 for ; Thu, 29 Jan 2004 12:21:15 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i0TKLDdk003567; Thu, 29 Jan 2004 15:21:13 -0500 Date: Thu, 29 Jan 2004 15:21:13 -0500 (EST) From: Rob Siemborski To: Mark Crispin cc: Pete Resnick , ietf-imapext@imc.org, Charlie Kaufman Subject: Re: Fwd: Request for security review In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 29 Jan 2004, Mark Crispin wrote: > I see the acceptable solutions as: > > 1) Adopt ACL2, declare victory, and go home. If it's a lot of work for > everybody, that's life. Since the major objection (that I know of) to doing this is that "clients can't understand what's about to happen", and one of Charlie's comments is: >> Going back to my first inclination, I would urge the designers to put something in the protocol whereby a client can ask a server for a name and version of its implementation so that clients that want to be agile can figure out what's going on rather than poking and guessing. << I suspect doing the modifications to ACL2 so as to advertise the semantics of how identifiers are handled (as we discussed in the middle of last year) might be the way to go. > 2) Adopt a simplified ACL2 and a separate "large enough but not too large" > mechanism for compatibility. If the latter turns out to be the only > one that is widely implemented, that's life. If we want to go this way instead, I'd want to make sure we see the following: a) backwards compatibility (or atleast a sane upgrade path that doesn't result in the interpretation of ACLs being changed -- this is NOT the same as a server being able to advertise both ACL and ACL2 at the same time) for UNION-based ACL implementations. b) some way to represent the "large enough but not too large" mechanism within the ACL2 semantics. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TI7K8Q033037; Thu, 29 Jan 2004 10:07:20 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TI7JgO033036; Thu, 29 Jan 2004 10:07:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TI7IkX033030 for ; Thu, 29 Jan 2004 10:07:18 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0TI7JMM004527; Thu, 29 Jan 2004 10:07:19 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i0TI7JrF025304; Thu, 29 Jan 2004 10:07:19 -0800 Date: Thu, 29 Jan 2004 10:07:19 -0800 (PST) From: Mark Crispin To: Pete Resnick cc: ietf-imapext@imc.org, Charlie Kaufman Subject: Re: Fwd: Request for security review In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thank you Charlie for your security review. Tndeed, your observation that RFC 2086 "impl[ies] that there is no one correct behavior and that a client that wants to know the exact semantics of the server will have to experiment to figure it out." This is one of the bugs of RFC 2086 that needs to be fixed. Here's some background: You are correct in identifying a conflict between "backwards compatibility" and "doing it right". There is another conflict, this one between "ideal" (at least in some viewpoints) and "compatible with (and implementable on) existing mail stores." The "ideal" camp once claimed that "compatible" was a proper subset of "ideal". In RFC 2086, it provably isn't; not only are some valid access controls in "ideal" not expressible in "compatible", but some valid access controls in "compatible" are not expressible in "ideal". ACL2 is an attempt, first to resolve the ambiguities in RFC 2086 and to ensure that "compatible" is a proper subset. Doing this made ACL2 quite a bit more complicated than RFC 2086. The "ideal" camp is unhappy about this. The "compatible" camp, on the other hand, sees that it's being put through a great deal of complexity anyway, so they don't sympathize; rather, they see it as necessary for ACL to be implementable at all. Rob's strawman was an attempt to reduce the complexity for the "ideal" camp by providing a smaller mechanism for the "compatible" camp. Unfortunately, the smaller mechanism is too small for the "compatible" camp, but with a few minor extensions it would be fine -- "large enough but not too large." There is a suspicion, held by both camps, that the "large enough but not too large" mechanism desired by the "compatible" camp will be "good enough" for almost all users. The resulting positions taken by the players are obvious. :-) I see the acceptable solutions as: 1) Adopt ACL2, declare victory, and go home. If it's a lot of work for everybody, that's life. 2) Adopt a simplified ACL2 and a separate "large enough but not too large" mechanism for compatibility. If the latter turns out to be the only one that is widely implemented, that's life. I see the following as unacceptable: 1) Retain RFC 2086. 2) Simplify ACL2 without any attempt to support compatible access control. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TGukj0028208; Thu, 29 Jan 2004 08:56:46 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TGukB2028207; Thu, 29 Jan 2004 08:56:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TGuiZQ028201 for ; Thu, 29 Jan 2004 08:56:45 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b4); Thu, 29 Jan 2004 10:56:42 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.1a9] Date: Thu, 29 Jan 2004 10:56:42 -0600 To: ietf-imapext@imc.org From: Pete Resnick Subject: Fwd: Request for security review Cc: Charlie Kaufman Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Below is the security review of ACL that I asked Charlie Kaufman to do for us. I've Cc'ed Charlie on this; please reply to all if you have questions or comments on this review. --- begin forwarded text Subject: RE: Request for security review - IMAPEXT Date: Sun, 25 Jan 2004 20:35:34 -0800 From: "Charlie Kaufman" To: "Pete Resnick" I read RFC 2086, draft-ietf-imapext-acl-09.txt, Rob Siemborski's 14 Nov email "Yet another ACL Strawman", and his email of 7 Jan questioning the wisdom of layering two subtly different security systems. I couldn't get from that the full set of proposals and arguments, but I think I get the gist. This effort is clearly dealing with problems to standards groups: backwards compatibility vs. "doing it right", different opinions as to what "doing it right" means, and the temptation to compromise by having the standard allow many variations so that everyone can do their own thing at the expense of interoperability. While my first inclination is to jump in and try to propose my version of "doing it right", first let me respond to the question you asked: are any of these proposals unacceptable from a security standpoint (which could help narrow the decision space). My answer, sadly, is 'no'. While it is particularly dangerous to allow ambiguity in a spec with respect to security semantics, RFC 2086 set the bar on the bottom of page 2 with "An implementation may tie rights together or may force rights to always or never be granted to particular identifiers" and on the top of page 3 with "How these rights are combined to determine the user's access is implementation-defined". These imply that there is no one correct behavior and that a client that wants to know the exact semantics of the server will have to experiment to figure it out. None of the proposed revisions (that I looked at) make this situation substantially worse. So I don't think anyone can make any strong security arguments for or against the layering. Going back to my first inclination, I would urge the designers to put something in the protocol whereby a client can ask a server for a name and version of its implementation so that clients that want to be agile can figure out what's going on rather than poking and guessing. --- end forwarded text -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0OLZUib066737; Sat, 24 Jan 2004 13:35:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0OLZUAg066733; Sat, 24 Jan 2004 13:35:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from [63.202.92.156] (adsl-63-202-92-156.dsl.snfc21.pacbell.net [63.202.92.156]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0OLZMic066706; Sat, 24 Jan 2004 13:35:22 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Sat, 24 Jan 2004 13:35:24 -0800 To: (various IETF lists) From: Paul Hoffman / IMC Subject: New mail-ng mailing list open for sign-ups Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings again. There seems to be more discussion these days about replacing SMTP and/or RFC 2822 and/or POP/IMAP for a variety of reasons. The discussion seems to pop up on a few different lists and in a few different hallways, and it might be good to have a single list where folks can congregate. Thus, I have set up a mail-ng mailing list. The first task probably is to determine what the next generation of mail should do, and how that is different than what SMTP/2822/POP-or-IMAP or instant messaging does. It is safe to say that we can ignore actual protocol proposals for many months (if not years) until we figure out what is needed. Once we do that, there are plenty of protocol people who can attack the decided-on requirements. There is no expectation that there will be significant agreement on the list. It is likely that over time the discussion will split into camps of like-minded design goals. The list might then spawn different lists for the folks of the different camps (mail-ng-shoe, mail-ng-sandal, ...). The list is explicitly not yet meant to be an IETF working group yet (if at all), and is probably more akin to the IRTF. But at the beginning, it will most likely be talking, not research. See for information on how to subscribe. The list is taking subscriptions now, and will probably go live for discussions within a week. Having some discussion on a mailing list now should make the dinners and bar gatherings at Seoul more interesting. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NJ6Eib014607; Fri, 23 Jan 2004 11:06:14 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0NJ6EJL014606; Fri, 23 Jan 2004 11:06:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NJ6Dib014600 for ; Fri, 23 Jan 2004 11:06:13 -0800 (PST) (envelope-from apache@asgard.ietf.org) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1Ak6d0-0007i7-25; Fri, 23 Jan 2004 14:06:02 -0500 X-test-idtracker: no To: IETF-Announce :; From: The IESG Subject: Last Call: 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Fri, 23 Jan 2004 14:06:02 -0500 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Internet Message Access Protocol Extension WG to consider the following document: - 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-02-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-14.txt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0L0bhib098823; Tue, 20 Jan 2004 16:37:43 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0L0bhRC098822; Tue, 20 Jan 2004 16:37:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0L0bfib098815 for ; Tue, 20 Jan 2004 16:37:42 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [129.46.76.186] (129.46.76.186) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b4) for ; Tue, 20 Jan 2004 18:37:40 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.1a9] Date: Tue, 20 Jan 2004 16:37:39 -0800 To: ietf-imapext@imc.org From: Pete Resnick Subject: Re: Yet another ACL Strawman 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 1/7/04 at 1:03 PM -0600, I wrote: >On 1/7/04 at 1:46 PM -0500, Rob Siemborski wrote: > >>It may help to get IESG/Security area comments on: >> >>a) the current ACL2 draft >>b) ACL2 with the behavior description announcement (as discussed >> by the most recent thread) >>c) Layering of two systems > >I'll try to find a security person with enough mail-clue to help us out. Charlie Kaufman has kindly accepted my request to have a gander. -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FDu2ib045430; Thu, 15 Jan 2004 05:56:02 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0FDu24s045429; Thu, 15 Jan 2004 05:56:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com ([208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FDtuib045423 for ; Thu, 15 Jan 2004 05:55:56 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (69-161-93-210.bflony.adelphia.net [69.161.93.210]) (authenticated bits=0) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id i0FDtmTN020538 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 15 Jan 2004 08:55:51 -0500 (EST) Message-ID: <40069BE3.4070803@oceana.com> Date: Thu, 15 Jan 2004 08:55:47 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031020 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> <40059A94.3000700@oceana.com> <4005CBB7.2090308@isode.com> In-Reply-To: <4005CBB7.2090308@isode.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexey Melnikov wrote: > Ken Murchison wrote: > >> Ken Murchison wrote: >> >>> I just starting working on a CONDSTORE implementation in Cyrus, and I >>> wanted to make a few comments/suggestions before the document gets >>> too far along in the queue. >>> >>> Here is what I have come up with over the last day. I might have >>> more as I get further into my implementation. >> >> >> >> Section 3.6: The phrase in the first sentence "to include >> mod-sequence" should be changed to read "to include the highest >> mod-sequence". > > > Correct (as per your explanation below) > >> Since the mod-sequence being returned in the untagged SEARCH, SORT and >> possibly THREAD responses is the *highest* of the messages in the >> response, shouldn't the extended response tag be HIGHESTMODSEQ instead >> of MODSEQ? This seems more intuitive, unless you think it conflicts >> with the HIGHESTMODSEQ response code. > > > I would like not to change syntax at this point. Once again, the draft > is already approved as RFC. Right, I understand. I'd also like to see SEARCH MODSEQ changed to SEARCH CHANGEDSINCE if we had the time. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FBSOib038404; Thu, 15 Jan 2004 03:28:24 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0FBSOcS038402; Thu, 15 Jan 2004 03:28:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FBSCib038388 for ; Thu, 15 Jan 2004 03:28:19 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 15 Jan 2004 11:27:53 +0000 Message-ID: <4005CBB7.2090308@isode.com> Date: Wed, 14 Jan 2004 23:07:35 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Murchison CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> <40059A94.3000700@oceana.com> In-Reply-To: <40059A94.3000700@oceana.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > Ken Murchison wrote: > >> I just starting working on a CONDSTORE implementation in Cyrus, and I >> wanted to make a few comments/suggestions before the document gets >> too far along in the queue. >> >> Here is what I have come up with over the last day. I might have >> more as I get further into my implementation. > > > Section 3.6: The phrase in the first sentence "to include > mod-sequence" should be changed to read "to include the highest > mod-sequence". Correct (as per your explanation below) > Since the mod-sequence being returned in the untagged SEARCH, SORT and > possibly THREAD responses is the *highest* of the messages in the > response, shouldn't the extended response tag be HIGHESTMODSEQ instead > of MODSEQ? This seems more intuitive, unless you think it conflicts > with the HIGHESTMODSEQ response code. I would like not to change syntax at this point. Once again, the draft is already approved as RFC. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FBSOib038405; Thu, 15 Jan 2004 03:28:24 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0FBSOSh038403; Thu, 15 Jan 2004 03:28:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FBSCic038388 for ; Thu, 15 Jan 2004 03:28:20 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Thu, 15 Jan 2004 11:27:54 +0000 Message-ID: <4005CC5E.4080600@isode.com> Date: Wed, 14 Jan 2004 23:10:22 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Murchison CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> <4005945E.5070508@oceana.com> In-Reply-To: <4005945E.5070508@oceana.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > Ken Murchison wrote: > >> I just starting working on a CONDSTORE implementation in Cyrus, and I >> wanted to make a few comments/suggestions before the document gets >> too far along in the queue. >> >> Here is what I have come up with over the last day. I might have >> more as I get further into my implementation. > > The first two examples in section 3.5 are reversed (the first shows > the MODSEQ sort crit, and the second shows the MODSEQ search crit). Good catch. Fixed. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EJahib022803; Wed, 14 Jan 2004 11:36:43 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EJahEO022802; Wed, 14 Jan 2004 11:36:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EJafib022796 for ; Wed, 14 Jan 2004 11:36:41 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id i0EJabTM010713; Wed, 14 Jan 2004 14:36:37 -0500 (EST) Message-ID: <40059A94.3000700@oceana.com> Date: Wed, 14 Jan 2004 14:37:56 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> In-Reply-To: <40007395.10403@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > > I just starting working on a CONDSTORE implementation in Cyrus, and I > wanted to make a few comments/suggestions before the document gets too > far along in the queue. > > Here is what I have come up with over the last day. I might have more > as I get further into my implementation. Section 3.6: The phrase in the first sentence "to include mod-sequence" should be changed to read "to include the highest mod-sequence". Since the mod-sequence being returned in the untagged SEARCH, SORT and possibly THREAD responses is the *highest* of the messages in the response, shouldn't the extended response tag be HIGHESTMODSEQ instead of MODSEQ? This seems more intuitive, unless you think it conflicts with the HIGHESTMODSEQ response code. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EJADib021837; Wed, 14 Jan 2004 11:10:13 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EJAD5w021836; Wed, 14 Jan 2004 11:10:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EJABib021829 for ; Wed, 14 Jan 2004 11:10:12 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id i0EJA8TM010402; Wed, 14 Jan 2004 14:10:08 -0500 (EST) Message-ID: <4005945E.5070508@oceana.com> Date: Wed, 14 Jan 2004 14:11:26 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> In-Reply-To: <40007395.10403@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > > I just starting working on a CONDSTORE implementation in Cyrus, and I > wanted to make a few comments/suggestions before the document gets too > far along in the queue. > > Here is what I have come up with over the last day. I might have more > as I get further into my implementation. The first two examples in section 3.5 are reversed (the first shows the MODSEQ sort crit, and the second shows the MODSEQ search crit). -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EIPNib020171; Wed, 14 Jan 2004 10:25:23 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EIPNdv020170; Wed, 14 Jan 2004 10:25:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EIPMib020165 for ; Wed, 14 Jan 2004 10:25:22 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 14 Jan 2004 18:25:10 +0000 Message-ID: <40058982.8080201@isode.com> Date: Wed, 14 Jan 2004 18:25:06 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Hole CC: Ken Murchison , IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40057D4B.8080501@oceana.com> <40055571.8050008@oceana.com> <40007395.10403@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve Hole wrote: >On Wed, 14 Jan 2004 12:32:59 -0500 Ken Murchison wrote: > > >>So, assume the client is CONDSTORE enabled, and then sends: >> >>FETCH 1:* ENVELOPE >> >>We should return the MODSEQ for each message? That seems >>counter-intuitive. First, the client didn't ask for it, and second, any >>meta-data changes would be sent in the form of unsolicited FETCH >>responses anyways. >> >> > >Ah ... I see what you're after. > >You would include any changed MODSEQ as unsolicited data. You don't need >to include the MODSEQ for unchanged items as along with the ENVELOPE >response. > I agree, but the document has to clarify this. >A more interesting question is something like: > > FETCH 2:4 ENVELOPE > >and there is a changed MODSEQ for message 7 -- should you issue and >unsolicited MODSEQ for it triggered by the FETCH even though it is >outside the fetch set. The answer is yes because you want to learn about >the state change as soon as possible in the application (just like FLAGS). >The client can always ignore the data. > > >>Am I missing something? >> >> >No. I just didn't get what you were asking. Sorry about that. > >Cheers. > > Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EIKUib019983; Wed, 14 Jan 2004 10:20:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EIKUti019982; Wed, 14 Jan 2004 10:20:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EIKKib019974 for ; Wed, 14 Jan 2004 10:20:25 -0800 (PST) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id i0EIJqG19231; Wed, 14 Jan 2004 11:19:52 -0700 From: Steve Hole Date: Wed, 14 Jan 2004 11:19:57 -0700 To: Ken Murchison Subject: Re: draft-ietf-imapext-condstore-05 Cc: Alexey Melnikov , IMAP Extensions WG In-Reply-To: <40057D4B.8080501@oceana.com> References: <40057D4B.8080501@oceana.com> <40055571.8050008@oceana.com> <40007395.10403@oceana.com> Message-ID: X-Mailer: Execmail for Linux 6.0.0 beta Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0EIKPib019976 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 14 Jan 2004 12:32:59 -0500 Ken Murchison wrote: > So, assume the client is CONDSTORE enabled, and then sends: > > FETCH 1:* ENVELOPE > > We should return the MODSEQ for each message? That seems > counter-intuitive. First, the client didn't ask for it, and second, any > meta-data changes would be sent in the form of unsolicited FETCH > responses anyways. Ah ... I see what you're after. You would include any changed MODSEQ as unsolicited data. You don't need to include the MODSEQ for unchanged items as along with the ENVELOPE response. A more interesting question is something like: FETCH 2:4 ENVELOPE and there is a changed MODSEQ for message 7 -- should you issue and unsolicited MODSEQ for it triggered by the FETCH even though it is outside the fetch set. The answer is yes because you want to learn about the state change as soon as possible in the application (just like FLAGS). The client can always ignore the data. > Am I missing something? No. I just didn't get what you were asking. Sorry about that. Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EHVkib018000; Wed, 14 Jan 2004 09:31:46 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EHVk2c017999; Wed, 14 Jan 2004 09:31:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EHVjib017994 for ; Wed, 14 Jan 2004 09:31:45 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id i0EHVfTM009402; Wed, 14 Jan 2004 12:31:41 -0500 (EST) Message-ID: <40057D4B.8080501@oceana.com> Date: Wed, 14 Jan 2004 12:32:59 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Steve Hole CC: Alexey Melnikov , IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40055571.8050008@oceana.com> <40007395.10403@oceana.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve Hole wrote: > On Wed, 14 Jan 2004 09:42:57 -0500 Ken Murchison wrote: > > >>Ken Murchison wrote: > >>Other issue: The end of section 2 says that once a CONDSTORE enabling >>command is used by the client, that *all* FETCH responses must include >>MODSEQ. Is this also the case with responses to a FETCH command, or is >>this still controlled by whether or not the MODSEQ fetch data item is >>used? I'm assuming the latter, but if the former, what's the point of >>having the MODSEQ data item? > > > Once you use a MODSEQ modifier in any command, including FETCH, then you > have to return MODSEQ data in any FETCH response whether solicited or not. > This is because the client will be (presumably) caching and using the > modseq data advisory "locking". So, assume the client is CONDSTORE enabled, and then sends: FETCH 1:* ENVELOPE We should return the MODSEQ for each message? That seems counter-intuitive. First, the client didn't ask for it, and second, any meta-data changes would be sent in the form of unsolicited FETCH responses anyways. Am I missing something? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EH6Mib017076; Wed, 14 Jan 2004 09:06:22 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EH6MRX017075; Wed, 14 Jan 2004 09:06:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EH6Gib017069 for ; Wed, 14 Jan 2004 09:06:16 -0800 (PST) (envelope-from steve.hole@messagingdirect.com) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) (authenticated) by rembrandt.esys.ca (8.11.6/8.11.0.Beta0) with ESMTP id i0EH5vG16937; Wed, 14 Jan 2004 10:05:57 -0700 From: Steve Hole Date: Wed, 14 Jan 2004 10:06:02 -0700 To: Ken Murchison Subject: Re: draft-ietf-imapext-condstore-05 Cc: Alexey Melnikov , IMAP Extensions WG In-Reply-To: <40055571.8050008@oceana.com> References: <40055571.8050008@oceana.com> <40007395.10403@oceana.com> Message-ID: X-Mailer: Execmail for Linux 6.0.0 beta Build (1) MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0EH6Gib017071 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 14 Jan 2004 09:42:57 -0500 Ken Murchison wrote: > Ken Murchison wrote: > > > > > I just starting working on a CONDSTORE implementation in Cyrus, and I > > wanted to make a few comments/suggestions before the document gets too > > far along in the queue. > > > > Here is what I have come up with over the last day. I might have more > > as I get further into my implementation. > > General question: Do the MODSEQ for each message have to be unique, or > can multiple messages have the same MODSEQ? For instance, if I do: > > FETCH 1:* +FLAGS (\Seen) > > can all of the messages have the same MODSEQ? I'd like to think yes. Yes, they can have the same MODSEQ. The MODSEQ is strictly ascending for any change to a particular message. > Other issue: The end of section 2 says that once a CONDSTORE enabling > command is used by the client, that *all* FETCH responses must include > MODSEQ. Is this also the case with responses to a FETCH command, or is > this still controlled by whether or not the MODSEQ fetch data item is > used? I'm assuming the latter, but if the former, what's the point of > having the MODSEQ data item? Once you use a MODSEQ modifier in any command, including FETCH, then you have to return MODSEQ data in any FETCH response whether solicited or not. This is because the client will be (presumably) caching and using the modseq data advisory "locking". Cheers. --- Steve Hole Chief Technology Officer - Billing and Payment Systems ACI Worldwide Phone: 780-424-4922 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EEfsib088867; Wed, 14 Jan 2004 06:41:54 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EEfstV088866; Wed, 14 Jan 2004 06:41:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EEfiib088853 for ; Wed, 14 Jan 2004 06:41:44 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id i0EEfdTM007865; Wed, 14 Jan 2004 09:41:39 -0500 (EST) Message-ID: <40055571.8050008@oceana.com> Date: Wed, 14 Jan 2004 09:42:57 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> In-Reply-To: <40007395.10403@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > > I just starting working on a CONDSTORE implementation in Cyrus, and I > wanted to make a few comments/suggestions before the document gets too > far along in the queue. > > Here is what I have come up with over the last day. I might have more > as I get further into my implementation. General question: Do the MODSEQ for each message have to be unique, or can multiple messages have the same MODSEQ? For instance, if I do: FETCH 1:* +FLAGS (\Seen) can all of the messages have the same MODSEQ? I'd like to think yes. Other issue: The end of section 2 says that once a CONDSTORE enabling command is used by the client, that *all* FETCH responses must include MODSEQ. Is this also the case with responses to a FETCH command, or is this still controlled by whether or not the MODSEQ fetch data item is used? I'm assuming the latter, but if the former, what's the point of having the MODSEQ data item? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0BJNBib064505; Sun, 11 Jan 2004 11:23:11 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0BJNAOM064504; Sun, 11 Jan 2004 11:23:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0BJN9ib064498 for ; Sun, 11 Jan 2004 11:23:10 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 11 Jan 2004 19:23:08 +0000 Message-ID: <4001A29A.6090400@isode.com> Date: Sun, 11 Jan 2004 19:23:06 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Murchison CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> <40009847.9000006@oceana.com> In-Reply-To: <40009847.9000006@oceana.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > Ken Murchison wrote: > >> I just starting working on a CONDSTORE implementation in Cyrus, and I >> wanted to make a few comments/suggestions before the document gets >> too far along in the queue. >> >> Here is what I have come up with over the last day. I might have >> more as I get further into my implementation. > > The grammar doesn't seem to include the extension of SELECT/EXAMINE > for the CONDSTORE parameter. If I remember correctly the generic syntax for SELECT/EXAMINE parameters is defined in ANNOTATE document, which is a normative reference for CONDSTORE. > Is this supposed to be a generic extension and CONDSTORE is one such > parameter, or the only valid parameter is CONDSTORE? The former. > If the latter, is there a reason why the parameter is in the form of > a list? Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html Personal Home Page: http://www.melnikov.ca __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0BJMPib064486; Sun, 11 Jan 2004 11:22:25 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0BJMP9i064485; Sun, 11 Jan 2004 11:22:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0BJMFib064470 for ; Sun, 11 Jan 2004 11:22:19 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Sun, 11 Jan 2004 19:22:04 +0000 Message-ID: <4001A259.1010600@isode.com> Date: Sun, 11 Jan 2004 19:22:01 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Murchison CC: Steve.Hole@MessagingDirect.com, IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> In-Reply-To: <40007395.10403@oceana.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > I just starting working on a CONDSTORE implementation in Cyrus, and I > wanted to make a few comments/suggestions before the document gets too > far along in the queue. > > Here is what I have come up with over the last day. I might have more > as I get further into my implementation. > > - As a general note, should the STORE/FETCH modifier syntax be broken > out into a separate draft and then referenced by CONDSTORE? I thought about this as well. I don't remember now, but I thought I've asked this question on the mailing list. Anyway, CONDSTORE is approved as RFC now and I fear it will take another 3 years before updated CONDSTORE and that separate document get published. > Any subsequent draft which introduces a new modifier will have to > reference CONDSTORE, which seems a bit awkward. > > - Section 2 doesn't mention STATUS (HIGHESTMODSEQ) as a CONDSTORE > enabling command? Is this by design or an oversight? An oversight. > - Section 3.1.1 leads me to believe that HIGHESTMODSEQ is *always* > returned for SELECT/EXAMINE. That is correct. > Why is this necessary when we explicitly have CONSTORE enabling > commands which require that we return HIGHESTMODSEQ? It seems > redundant that weShould we just return HIGHESTMODSEQ for > SELECT/EXAMINE CONDSTORE? would return this on SELECT/EXAMINE and then > again on the first CONDSTORE-specific STORE/FETCH. You are probably right, but I don't see a problem with returning HIGHESTMODSEQ on the first CONDSTORE-aware STORE/FETCH. If Ned agrees that just returning HIGHESTMODSEQ on SELECT/EXAMINE CONDSTORE is not a substantial change to the document, I can try to modify it. > - Section 3.2, first example: the MODSEQ value of UID 6 is less than > UNCHANGEDSINCE Good catch. > - Section 3.3.1 leaves out "OPTIONAL fetch modifiers" as the last > argument. Corrected in my copy, thanks. > - Section 4. The grammar for the STORE and FETCH modifiers seem > inconsistent with one another. The STORE grammar defines > UNCHANGEDSINCE as the only modifier, where FETCH defines the modifier > in general terms, and has the chgsince-fetch-mod terminal unused. The latter approach is probably better. chgsince-fetch-mod is not really unused. There is a comment that it conforms to fetch-modifier syntax. > - Does the MODSEQ search criterion also apply to THREAD in the same > way that it does to SORT? Yes, search criterion applies to all commands that make use of it. > - Grammatical nits: > > Section 2, paragraph 3, sentence 2: perhaps replacing both instances > of "and before" with "where previously" would read better. > > Section 3.1, paragraph 1, sentence 2: "SELECT and EXAMINE commands" > should probably read "SELECT or EXAMINE command" I've changed this in my copy, thanks. Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0B0R2ib042015; Sat, 10 Jan 2004 16:27:02 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0B0R2b8042014; Sat, 10 Jan 2004 16:27:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0B0Qvib042005 for ; Sat, 10 Jan 2004 16:26:57 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (69-161-93-210.bflony.adelphia.net [69.161.93.210]) (authenticated bits=0) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id i0B0QrTN003701 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 10 Jan 2004 19:26:54 -0500 (EST) Message-ID: <40009847.9000006@oceana.com> Date: Sat, 10 Jan 2004 19:26:47 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov , Steve.Hole@MessagingDirect.com CC: IMAP Extensions WG Subject: Re: draft-ietf-imapext-condstore-05 References: <40007395.10403@oceana.com> In-Reply-To: <40007395.10403@oceana.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ken Murchison wrote: > > I just starting working on a CONDSTORE implementation in Cyrus, and I > wanted to make a few comments/suggestions before the document gets too > far along in the queue. > > Here is what I have come up with over the last day. I might have more > as I get further into my implementation. The grammar doesn't seem to include the extension of SELECT/EXAMINE for the CONDSTORE parameter. Is this supposed to be a generic extension and CONDSTORE is one such parameter, or the only valid parameter is CONDSTORE? If the latter, is there a reason why the parameter is in the form of a list? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0ALoaib036035; Sat, 10 Jan 2004 13:50:36 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0ALoa7N036034; Sat, 10 Jan 2004 13:50:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0ALoSib036025 for ; Sat, 10 Jan 2004 13:50:28 -0800 (PST) (envelope-from ken@oceana.com) Received: from oceana.com (69-161-93-210.bflony.adelphia.net [69.161.93.210]) (authenticated bits=0) by eagle.oceana.com (8.12.10/8.12.10) with ESMTP id i0ALoITN001141 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 10 Jan 2004 16:50:19 -0500 (EST) Message-ID: <40007395.10403@oceana.com> Date: Sat, 10 Jan 2004 16:50:13 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en,pdf MIME-Version: 1.0 To: Alexey Melnikov , Steve.Hole@MessagingDirect.com CC: IMAP Extensions WG Subject: draft-ietf-imapext-condstore-05 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I just starting working on a CONDSTORE implementation in Cyrus, and I wanted to make a few comments/suggestions before the document gets too far along in the queue. Here is what I have come up with over the last day. I might have more as I get further into my implementation. - As a general note, should the STORE/FETCH modifier syntax be broken out into a separate draft and then referenced by CONDSTORE? Any subsequent draft which introduces a new modifier will have to reference CONDSTORE, which seems a bit awkward. - Section 2 doesn't mention STATUS (HIGHESTMODSEQ) as a CONDSTORE enabling command? Is this by design or an oversight? - Section 3.1.1 leads me to believe that HIGHESTMODSEQ is *always* returned for SELECT/EXAMINE. Why is this necessary when we explcitly have CONSTORE enabling commands which require that we return HIGHESTMODSEQ? It seems redundant that we would return this on SELECT/EXAMINE and then again on the first CONDSTORE-specific STORE/FETCH. Should we just return HIGHESTMODSEQ for SELECT/EXAMINE CONDSTORE? - Section 3.2, first example: the MODSEQ value of UID 6 is less than UNCHANGEDSINCE - Section 3.3.1 leaves out "OPTIONAL fetch modifiers" as the last argument. - Section 4. The grammar for the STORE and FETCH modifiers seem inconsistent with one another. The STORE grammar defines UNCHANGEDSINCE as the only modifier, where FETCH defines the modifier in general terms, and has the chgsince-fetch-mod terminal unused. - Does the MODSEQ search criterion also apply to THREAD in the same way that it does to SORT? - Grammatical nits: Section 2, paragraph 3, sentence 2: perhaps replacing both instances of "and before" with "where previously" would read better. Section 3.1, paragraph 1, sentence 2: "SELECT and EXAMINE commands" should probably read "SELECT or EXAMINE command" -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07J3xib068178 for ; Wed, 7 Jan 2004 11:03:59 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07J3xkR068177 for ietf-imapext-bks; Wed, 7 Jan 2004 11:03:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07J3wib068172 for ; Wed, 7 Jan 2004 11:03:58 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3); Wed, 7 Jan 2004 13:03:53 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 6.1a7] Date: Wed, 7 Jan 2004 13:03:51 -0600 To: Rob Siemborski From: Pete Resnick Subject: Re: Yet another ACL Strawman Cc: Mark Crispin , 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 1/7/04 at 1:46 PM -0500, Rob Siemborski wrote: >It may help to get IESG/Security area comments on: > >a) the current ACL2 draft >b) ACL2 with the behavior description announcement (as discussed > by the most recent thread) >c) Layering of two systems I'll try to find a security person with enough mail-clue to help us out. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07IkUib067419 for ; Wed, 7 Jan 2004 10:46:30 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07IkU2A067418 for ietf-imapext-bks; Wed, 7 Jan 2004 10:46:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07IkSib067413 for ; Wed, 7 Jan 2004 10:46:28 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i07IkSdL001671; Wed, 7 Jan 2004 13:46:28 -0500 Date: Wed, 7 Jan 2004 13:46:27 -0500 (EST) From: Rob Siemborski To: Mark Crispin cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 29 Dec 2003, Rob Siemborski wrote: > Ok, we were talking about two entirely different PERMISSIONS > descriptions. Now I have a clear(er) picture of yours. > > I'm going to think this over now. After some consideration, I'm still forced to believe that having two distinct permissions systems where one is not a full and proper subset of the other is a poor long-term design choice. However, I am not a security expert, and thus cannot judge the implications of layering PERMISSIONS on top of UNION ACL (or even a MOST-SPECIFIC ACL, which is certainly a better fit). My gut is telling me that this will lead to a very complicated specification that will lead to implementation and interoperability problems. It may help to get IESG/Security area comments on: a) the current ACL2 draft b) ACL2 with the behavior description announcement (as discussed by the most recent thread) c) Layering of two systems -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07Icrib067070 for ; Wed, 7 Jan 2004 10:38:53 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07IcrSb067069 for ietf-imapext-bks; Wed, 7 Jan 2004 10:38:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from lin1.andrew.cmu.edu (LIN1.andrew.cmu.edu [128.2.6.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07Icqib067063 for ; Wed, 7 Jan 2004 10:38:52 -0800 (PST) (envelope-from rjs3@andrew.cmu.edu) Received: from SOURCEFOUR.andrew.cmu.edu (SOURCEFOUR.andrew.cmu.edu [128.2.122.8]) (user=rjs3 mech=GSSAPI (0 bits)) by lin1.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i07IcndL001664; Wed, 7 Jan 2004 13:38:49 -0500 Date: Wed, 7 Jan 2004 13:38:48 -0500 (EST) From: Rob Siemborski To: Timo Sirainen cc: Mark Crispin , ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman In-Reply-To: <621DD0CF-3A4B-11D8-9E05-000393CC2E90@iki.fi> Message-ID: References: <621DD0CF-3A4B-11D8-9E05-000393CC2E90@iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 30 Dec 2003, Timo Sirainen wrote: > I'm not sure if you really understood what Mark said.. It anyway sounds > to me like a quite workable solution. You'd have MOST-SPECIFIC > behaviour but if there's multiple groups, you'd get union of them. > Wouldn't that make it possible to quite easily convert old ACLs to > ACL2? You can keep your old groups, only problems are if you have > combined user, group and world rights. Then you'd have to do something > like: > > user + world: merge world rights directly to user > user + group(s): merge group rights directly to user > group(s) + world: create a new "world" group and give world rights to > world group After consideration, I don't think this is an acceptable upgrade path. Merging rights down to users (especially in the user+groups situation) is a very poor solution for deployments with extensive usage of both groups and users in UNION based ACLs. While it is true that in many cases it will probably be good enough to munge ACLs in this way, once the upgrade is done enterprises that may be used to managing groups in one way (and may be unable to change!) will now have to deal with the fact that removing a user from a group will not necessarily remove the rights that this group once granted to that user. IMAP servers may also not be able to create arbitrary groups (such as a 'world' group), unless this means "create a virtual world group outside of the local group management system" which would only create more problems: Imagine an ACL of: anyone lrs group=anyone lrs When I change the ACL of 'anyone' to lrsp, should the phantom group just track it and become group=anyone lrsp? Is it reasonable for the client to predict this sort of behavior? These problems will have the effect of prohibiting existing ACL servers from upgrading to ACL2 -- this should be just as unacceptable to the working group as forbidding a unix-filesystem based system from having any sort of rights management (especially if, as I have been told, the ACL2 draft started as an attempt to fix the 'd' right situation in ACL and nothing more). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O- M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07HOFib062016 for ; Wed, 7 Jan 2004 09:24:15 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07HOFnj062015 for ietf-imapext-bks; Wed, 7 Jan 2004 09:24:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07HO9ib061997 for ; Wed, 7 Jan 2004 09:24:09 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i07HO4nA016154; Wed, 7 Jan 2004 09:24:09 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id i07HO4Sh029037; Wed, 7 Jan 2004 09:24:04 -0800 Date: Wed, 7 Jan 2004 09:24:04 -0800 (PST) From: Mark Crispin To: Alexey Melnikov cc: Pete Resnick , ietf-imapext@imc.org Subject: Re: Shall we meet in Seoul? In-Reply-To: <3FFBEEBB.7050807@isode.com> Message-ID: References: <3FFBEEBB.7050807@isode.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 7 Jan 2004, Alexey Melnikov wrote: > > Who is going to be able to make it to Seoul? Do we have items about which we > > need to meet? Would a multicast session make a difference? > I am planning to attend. But I don't have tickets yet, so I can't give any > guaranty. I am not going to be there. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07BYXib042091 for ; Wed, 7 Jan 2004 03:34:33 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07BYXkT042090 for ietf-imapext-bks; Wed, 7 Jan 2004 03:34:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07BYSib042081 for ; Wed, 7 Jan 2004 03:34:32 -0800 (PST) (envelope-from Alexey.Melnikov@isode.com) Received: from isode.com (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (with SMTP (internal)) with ESMTPA; Wed, 7 Jan 2004 11:34:21 +0000 Message-ID: <3FFBEEBB.7050807@isode.com> Date: Wed, 07 Jan 2004 11:34:19 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Resnick CC: ietf-imapext@imc.org Subject: Re: Shall we meet in Seoul? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Pete Resnick wrote: > Who is going to be able to make it to Seoul? Do we have items about > which we need to meet? Would a multicast session make a difference? I am planning to attend. But I don't have tickets yet, so I can't give any guaranty. Alexey