Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPJDTib096403 for ; Tue, 25 Nov 2003 11:13:29 -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 hAPJDTVc096402 for ietf-imapext-bks; Tue, 25 Nov 2003 11:13:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mauve.mrochek.com ([209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPJDSib096343 for ; Tue, 25 Nov 2003 11:13:28 -0800 (PST) (envelope-from ned+imapext@innosoft.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L39N9OKIAO00HOW2@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Mon, 24 Nov 2003 10:41:29 -0800 (PST) Date: Mon, 24 Nov 2003 10:35:12 -0800 (PST) From: ned+imapext@innosoft.com Subject: AD review comments on draft-ietf-imapext-sort-13.txt In-reply-to: "Your message dated Sat, 15 Nov 2003 10:51:20 -0600" <2147483647.1068893480@[10.0.1.5]> To: ietf-imapext@imc.org Message-id: <01L3ENYV8XBA00HOW2@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This documents defines two threading algorithms, ORDEREDSUBJECT and REFERENCES, and the IANA considerations section makes it sound like there's a registry for threading algorithms with these as the two initial entries. However, this document doesn't actually define such a registry. I see two possibilities here: There are only two threading algorithms, end of story, no registry needed and hence the text about this in the IANA considerations section needs to be removed (unlikely), or else this document creates a new registry for threading algorithms with these two as the initial entries. If it is the latter there needs to be text added to define the registry and explain what the registration procedures are (RFC required, first come first serve, etc.). In the "Sent Date" section, the procedure implied by "adjusted by time zone" needs to be spelled out in a little more detail lest we end up with some "creative" interpretations and corresponding implementations. It might also make sense to discuss how to handle a date field with an invalid time zone specification. In the discussion of the charset argument for SORT and THREAD, reference is made to the charset argument to SEARCH defined in the base specification, but this document doesn't actually come out and specify that the semantics of SORT and THREAD's charset argument are the same as that for SEARCH's. I suggest adding a sentence along the lines of "The charset argument indicates the [CHARSET] of the strings that appear in the {sort|thread} criteria." to the relevant sections. The [CHARSET] reference would also need to be added to the normative references. The section containing the ABNF needs to state that it employs ABNF productions defined in RFC 3501. In the ABNF, change "; CHARSET argument to MUST be registered with IANA" to read "; CHARSET values MUST be registered with IANA" The RFC Editor views abstracts as essentially separate from the document propoer. As such, it is usually necessary to have both an Abstract describing the document as a whole very tersely and a separate introduction to the specification that describes its purpose in a bit more detail. The paragraph on MUST/SHOULD/MAY/etc. conventions needs to be moved to a section of its own separate from the abstract. The paragraph discussing capability announcment of the SORT and THREAD extensions also needs to be moved to a separate section. This document doesn't contain either the copyright or the IPR boilerplate required by RFC 2026. The section numbering in this document is, well, strange. Most sections aren't numbered, but then near the end up pops a section 12 and appendix A. I understand the desire to want to use section numbers to align the command and response material with RFC 3501, but I don't think this obviates the need for the rest of the document to have sensible section numbers. Here's an alternate suggestion: For the sections intended to be "inserted" into RFFC 3501, preface the section numbers with "BASE." or something similar. Then number the various other sections of this document normally. That's it! Ned Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAFGpMkT076134 for ; Sat, 15 Nov 2003 08:51: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 hAFGpMOM076133 for ietf-imapext-bks; Sat, 15 Nov 2003 08:51:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAFGpKkT076127 for ; Sat, 15 Nov 2003 08:51:21 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.5] (pool-151-201-224-88.pitt.east.verizon.net [151.201.224.88]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hAFGf3EG012539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2003 11:41:07 -0500 Date: Sat, 15 Nov 2003 10:51:20 -0600 From: Cyrus Daboo To: Rob Siemborski , ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman Message-ID: <2147483647.1068893480@[10.0.1.5]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Friday, November 14, 2003 18:41 -0500 Rob Siemborski wrote: | Comments? As a general comment I would support a split to two ACL mechanisms: a simple one and a complex one (the later being based on the existing ACL). I think ACL2 has become too unwieldy in trying to support arbitrary ACL models and will ultimately prove to be a huge hurdle to implementation on the client (which is the end that potentially has to support the multitude of server models that can exist). It was pointed out in the meeting that WebDAV seems to suffer from that problem - the server's model is over generalized and its hard for a client to get all the possible options right - interop is poor. So I think Rob is on the right track - we need an ACL+ to update the existing ACL spec. Then a simple Read-Only/Read-Write ACL model extension. The two need to co-exist, but a server may support only one, though I think we should recommend an ACL+ server also support PERMISSIONS. Of course this does mean writing off the current ACL2 spec (though much of the work for ACL+ has been done in ACL2). There are also other extensions that have a dependency on ACL and those would need to be held up until we can decide what to do (I'm primarily thinking about ANNOTATE here). That's probably not something Pete wants to hear - but I think we can get ACL+PERMISSIONS done quickly - and it would probably be faster than trying to resolve all the issues with ACL2's arbitrary models. It also means effectively having two ACL extensions rather than one. The question is whether the IESG would push-back on that - we need to get input from the ADs on that matter before we can decide whether to go ahead with this. Clearly we would pitch this as a simplification of this work - cutting down an arbitrary ACL model implementation (with many possible models) to two fixed models, which should make implementations and security analysis etc much easier to accomplish. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF3QWkT057577 for ; Fri, 14 Nov 2003 19:26:32 -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 hAF3QWe8057576 for ietf-imapext-bks; Fri, 14 Nov 2003 19:26:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF3QUkT057571 for ; Fri, 14 Nov 2003 19:26:30 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hAF3QVhu008429; Fri, 14 Nov 2003 19:26:32 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hAF3QVcf032102; Fri, 14 Nov 2003 19:26:31 -0800 Date: Fri, 14 Nov 2003 19:26:31 -0800 (PST) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob - This is an interesting idea. Give me some time to mull it over. This may be the way out! -- 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 hAENfEkT045219 for ; Fri, 14 Nov 2003 15:41:16 -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 hAENfEum045218 for ietf-imapext-bks; Fri, 14 Nov 2003 15:41:14 -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 hAENfCkT045210 for ; Fri, 14 Nov 2003 15:41:13 -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 hAENfE5G022948 for ; Fri, 14 Nov 2003 18:41:14 -0500 Date: Fri, 14 Nov 2003 18:41:14 -0500 (EST) From: Rob Siemborski To: ietf-imapext@imc.org Subject: Yet another ACL Strawman Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: After the IMAPext meeting I spoke with some people and got to thinking if there was a way we could come up with a way to do IMAP sharing that will satisfy both the enterprise people who need detailed ACL support, and those who feel the need to implement permissions with limited backend support (e.g. UNIX file permissions). Ideally, such a mechanism would be simple to implement and not have complexity problems getting past the IESG. I'd like to propose the following as a strawman INSTEAD of the current ACL2 draft (or whatever ACL2 became after the last round of comments): Create an ACL+ capability that does the following: * Can only be advertised if ACL is advertised * adds the x (DELETE mailbox), t (set \Deleted), and e (EXPUNGE) bits to ACL, and redefines the 'd' bit to "x && t && e" (like ACL2) There may be other changes from ACL2 that I missed here, but the general goal is "do the minimum required to fix ACL". This may imply changing how the namespace of identifiers are treated as well (e.g. user=foo, group=bar), but I'd really like to keep the changes as minimal as possible here if we can. Create a new PERMISSIONS capability that works along the lines of the following: * Define four bits you can set on a mailbox: owner read/write and anyone read/write. Have a command other than the ACL manipulation commands that can manipulate/report these. If a server advertises *both* PERMISSIONS and ACL, then it must also advertise ACL+. Also, the PERMISSIONS bits are tied as follows to ACL bits for the *owner* of a mailbox and for the "anyone" identifier (in the ACL): On a mailbox that can contain messages: read: lr write: wite (I'm not sure how to tie 's' -- maybe Mark can answer that). On a mailbox that can contain mailboxes: read: l write: cx "Dual-use" mailboxes get the union of the applicable above sets of bits. Identifiers in the ACL that correspond to entities other than the owner and 'anyone' are not advertised through the permissions extension. Note that in a ACL+PERMISSIONS system, the rights advertised through the PERMISSIONS extension are exactly the rights that match the owner's identifier and the "anyone" identifier. Negative rights are not advertised through, the PERMISSIONS system. When resolving actual rights, the ACL must be fully calculated (i.e. the PERMISSIONS interface is just an alternate way to get to *some* of the functionality of ACL). Note also that this does not tie 'a' or 'p' to anything, I would expect the PERMISSIONS extension to honor 'a', and I would expect 'p' to only be manipulatable through the ACL extension, though perhaps that isn't quite the right thing. If a server implements *only* PERMISSIONS and does not implement ACL, then it should keep the semantics that would be provided by the ACL bits as defined above for each PERMISSIONS bit (and implicitly grant 'a' to the owner). However, in this case, the bits advertised through PERMISSIONS *are* authoritative. I think that this setup is significantly simpler than having to bend over backwards to force ACLs onto unix filesystem semantics just to allow simple folder sharing, and it still allows enterprise servers to continue to support the flexibility provided by the ACL extension. I've intentionally left some things open here: specifically interaction with LISTEXT and the exact syntax of how PERMISSIONS would look on the wire. I have also left open the question of interpreting the ACL (rather, I left it as it was in 2086). The syntax question, at least, could be worked out when a formal draft was issued. I will note that this does not provide for groups to be used through the PERMISSIONS mechanism. However, it seems to me that the large demand is "share folders globally", and this provides for that. This would also provide a simple standard mapping for "read" and "write" acls to mailboxes, which sees to also have been in demand. Comments? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAD2R4kT058011 for ; Wed, 12 Nov 2003 18:27:04 -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 hAD2R4wq058010 for ietf-imapext-bks; Wed, 12 Nov 2003 18:27:04 -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 hAD2R2kT058004 for ; Wed, 12 Nov 2003 18:27:02 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [130.129.68.236] (130.129.133.140) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b1) for ; Wed, 12 Nov 2003 20:27:04 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.1a2] Date: Wed, 12 Nov 2003 19:08:04 -0600 To: ietf-imapext@imc.org From: Pete Resnick Subject: Bad chair - No blue sheet Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have shirked one of my responsibilities: I forgot to get the blue sheet for the IMAPEXT meeting. :-( I remember everyone there who said something. I know there were at least three people (and probably a couple more) that were in the room that I missed. Please add to this list if you can help me: Mark Crispin Cyrus Daboo Lisa Dusseault Randy Gellens Larry Greenfield Philip Guenther Ted Hardie John Klensin Chris Newman Rob Siemborski Thanks. 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 hABIdlkT014909 for ; Tue, 11 Nov 2003 10:39:47 -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 hABIdlAp014908 for ietf-imapext-bks; Tue, 11 Nov 2003 10:39:47 -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 hABIdfkT014902 for ; Tue, 11 Nov 2003 10:39:46 -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; Tue, 11 Nov 2003 18:41:13 +0000 Message-ID: <3FB12CEA.2030900@isode.com> Date: Tue, 11 Nov 2003 18:39:38 +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: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: ANNOTATE/ANNOTATEMORE issues References: <2147483647.1068461809@dyn131-202.ietf58.ietf.org> In-Reply-To: <2147483647.1068461809@dyn131-202.ietf58.ietf.org> 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: Cyrus Daboo wrote: > ANNOTATE issues for discussion on Wednesday: > > - No comments after last draft. Currently no open issues... Is it > ready for last call? Most likely. > ANNOTATEMORE issues: > > - SETANNOTATION on multiple mailboxes - how to handle partial > failures. Some solutions: > > * Fail entire annotation change on all mailboxes. Requires server > to rollback all changes across all mailboxes. > * Allow partial failure/success untagged response to indicate which > changes succeeded or failed, if some of them fail. > * Don't allow multi-mailbox SETANNOTATION. I think the first choice is non practical. The second is already suggested by ACL2. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAGufkT081781 for ; Mon, 10 Nov 2003 08:56:41 -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 hAAGufOx081780 for ietf-imapext-bks; Mon, 10 Nov 2003 08:56:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAGuekT081775 for ; Mon, 10 Nov 2003 08:56:40 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from dyn131-202.ietf58.ietf.org (dyn131-202.ietf58.ietf.org [130.129.131.202]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hAAGlCEG012109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Nov 2003 11:47:13 -0500 Date: Mon, 10 Nov 2003 10:56:49 -0600 From: Cyrus Daboo To: IMAP Extensions WG Subject: ANNOTATE/ANNOTATEMORE issues Message-ID: <2147483647.1068461809@dyn131-202.ietf58.ietf.org> X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ANNOTATE issues for discussion on Wednesday: - No comments after last draft. Currently no open issues... Is it ready for last call? ANNOTATEMORE issues: - SETANNOTATION on multiple mailboxes - how to handle partial failures. Some solutions: * Fail entire annotation change on all mailboxes. Requires server to rollback all changes across all mailboxes. * Allow partial failure/success untagged response to indicate which changes succeeded or failed, if some of them fail. * Don't allow multi-mailbox SETANNOTATION. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5HSukT091248 for ; Wed, 5 Nov 2003 09:28:56 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5HSu3i091247 for ietf-imapext-bks; Wed, 5 Nov 2003 09:28:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5HSqkT091241 for ; Wed, 5 Nov 2003 09:28:52 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA5HSnaZ003935; Wed, 5 Nov 2003 09:28:49 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA5HSm3e002581; Wed, 5 Nov 2003 09:28:49 -0800 Date: Wed, 5 Nov 2003 09:28:48 -0800 (PST) From: Mark Crispin To: Arnt Gulbrandsen cc: ietf-imapext@imc.org, Abhijit Menon-Sen Subject: Re: Selective removal of attachments in a message In-Reply-To: <+8uJlfkF0Blwx//JPO3p6Q.md5@libertango.oryx.com> Message-ID: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> <9050000.1067985982@socrates.cyrusoft.com> <20031105104606.A14643@lustre.dyn.wiw.org> <+8uJlfkF0Blwx//JPO3p6Q.md5@libertango.oryx.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, 5 Nov 2003, Arnt Gulbrandsen wrote: > No. The argument goes: If you can't prevent from being in > IMAP anyway, cave in and at least avoid having it in two places. But the ability to delete attachments is very different from composing new messages or editing an existing message. Some implementations *may* accomplish this by similar means, but that is implementation rather than concept. Furthermore, if compose is placed in IMAP, then composition is stuck with using IMAP forever. POP and NNTP clients will now have to have IMAP client code in order to do compose with those protocols (you could add compose to POP and NNTP. Now you have compose in three places). Time and time again, I hear "IMAP is a lousy design, IMAP is too weak to do anything useful, IMAP is going to have to be completely redesigned and replaced from the ground up." Why then do you want to create long-term dependencies upon IMAP? The superior solution is to have compose as a separate service, independent of any particular message access protocol, and thus equally usable with all message access mechanisms. This requires mechanisms and profiles, such as URLAUTH, to allow the compose service access to message data in IMAP, POP, NNTP, and future protocols. If building monoliths is so good, what is the point of having multiple protocols in the IETF suite? Why not have a single protocol for everything, such as the videotex systems of the 1970s? -- 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 hA5GLnkT086918 for ; Wed, 5 Nov 2003 08:21:49 -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 hA5GLnbv086917 for ietf-imapext-bks; Wed, 5 Nov 2003 08:21:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5GLmkT086912 for ; Wed, 5 Nov 2003 08:21:49 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: <+8uJlfkF0Blwx//JPO3p6Q.md5@libertango.oryx.com> From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: Selective removal of attachments in a message Cc: ietf-imapext@imc.org, Abhijit Menon-Sen References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> <9050000.1067985982@socrates.cyrusoft.com> <20031105104606.A14643@lustre.dyn.wiw.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed MIME-Version: 1.0 Date: Wed, 5 Nov 2003 17:21:50 +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA5GLnkT086913 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Wed, 5 Nov 2003, Abhijit Menon-Sen wrote: >> If we're going down that road, perhaps we should consider >> implementing a more flexible mechanism $B`(B la URLAUTH/COMPOSE, >> which allows more than just removing (why this corruption?) >> attachments. It seems inevitable that users will want to recompose >> messages in other ways, and I'm worried about having several >> mechanisms doing vaguely the same (set of) things. > > This doesn't make sense to me. The extreme form of that argument leads > to the conclusion that SMTP should be in IMAP because you can delete > and expunge messages in IMAP. No. The argument goes: If you can't prevent from being in IMAP anyway, cave in and at least avoid having it in two places. "Unavoidable" is very different from "good". > It seems to me that people who ask for this really don't want IMAP; > they want Exchange. That could be. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5G2ZkT086053 for ; Wed, 5 Nov 2003 08:02:35 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5G2ZNO086052 for ietf-imapext-bks; Wed, 5 Nov 2003 08:02:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5G2XkT086046 for ; Wed, 5 Nov 2003 08:02:33 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA5G2UaZ023321; Wed, 5 Nov 2003 08:02:30 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA5G2UJA029899; Wed, 5 Nov 2003 08:02:30 -0800 Date: Wed, 5 Nov 2003 08:02:30 -0800 (PST) From: Mark Crispin To: Abhijit Menon-Sen cc: ietf-imapext@imc.org Subject: Re: Selective removal of attachments in a message In-Reply-To: <20031105104606.A14643@lustre.dyn.wiw.org> Message-ID: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> <9050000.1067985982@socrates.cyrusoft.com> <20031105104606.A14643@lustre.dyn.wiw.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 5 Nov 2003, Abhijit Menon-Sen wrote: > If we're going down that road, perhaps we should consider implementing > a more flexible mechanism $B`(B la URLAUTH/COMPOSE, which allows more than > just removing attachments. It seems inevitable that users will want to > recompose messages in other ways, and I'm worried about having several > mechanisms doing vaguely the same (set of) things. This doesn't make sense to me. The extreme form of that argument leads to the conclusion that SMTP should be in IMAP because you can delete and expunge messages in IMAP. If you want to *edit* a message (something which I personally believe is morally wrong -- it is taking a real message from someone else and creating a forgery), then some form of COMPOSE mechanism is necessary. Editing is different from a mechanism that merely removes some attachments but leaves the message itself intact. Nor does having a COMPOSE functionality necessitate it being in IMAP. COMPOSE takes IMAP far afield from its mission of message access. We have numerous examples of server implementations that don't get the in-mission tasks of IMAP right. How then can anyone believe that further bloating IMAP with extraneous tasks will result in better-working servers? It seems to me that people who ask for this really don't want IMAP; they want Exchange. IMAP is designed to be small tool among a set of small tools, each of which does its own job well; Exchange is designed to be a monolith that does everything. I hope that people aren't still being mislead by the long-standing myth that "TCP connections are expensive." -- 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 hA5DjZkT080180 for ; Wed, 5 Nov 2003 05:45:35 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5DjZfP080179 for ietf-imapext-bks; Wed, 5 Nov 2003 05:45:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5DjYkT080174 for ; Wed, 5 Nov 2003 05:45:34 -0800 (PST) (envelope-from mganesh@india.hp.com) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel11.hp.com (Postfix) with ESMTP id E9FE21C02736; Wed, 5 Nov 2003 05:45:31 -0800 (PST) Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id TAA14935; Wed, 5 Nov 2003 19:14:13 +0530 (IST) From: "Madan Ganesh Velayudham" To: "'Mark Crispin'" , "'Pete Maclean'" Cc: "'IMAP Extensions WG'" Subject: RE: Selective removal of attachments in a message Date: Wed, 5 Nov 2003 19:15:26 +0530 Organization: Hewlett-Packard STSD Message-ID: <009d01c3a3a3$14722ed0$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, Pete, Thank you for your comments. Yes, I have totally agree with your comments and would work on the solution part and would send the completed draft. > remove data anywhere. This is a guaranteed (and useful) > property of IMAP, but it does preclude the more > straightforward scheme of "selective removal of attachments" > that Madan Ganesh suggested. Pls help me in understanding this statement. As I described in the draft-draft version, I've been working on how we would remove the attachment and have not disclosed how IMAP could achieve this. As you suggested, the REMOVE should do an atomic operation : Copy the message with modification to the end of the mailbox + Expunge the original message. Please let me know your comments. Thanks and Regards, MG > -----Original Message----- > From: owner-ietf-imapext@mail.imc.org > [mailto:owner-ietf-imapext@mail.imc.org] On Behalf Of Mark Crispin > Sent: Wednesday, November 05, 2003 6:25 AM > To: Pete Maclean > Cc: Madan Ganesh Velayudham; 'IMAP Extensions WG' > Subject: Re: Selective removal of attachments in a message > > > > On Tue, 4 Nov 2003, Pete Maclean wrote: > > >It would be a nice feature to have; however, it violates > the IMAP UID > > >model which guarantees that a UID refers to an immutable object. > > Why does it have to violate the model? Surely if the spec > says that > > on processing a REMOVE, the server MUST assign the message > a new UID > > then it would be okay. The old UID would be expunged and > the new UID > > would be reported in the REMOVE response. > > I'm not sure if we're loudly agreeing or not. Let's see if > this explanation helps: > > A message on the server can not be altered. The UID refers > to an immutable object. > > UIDs are strictly ascending. Thus for any pair of messages > m1 and m2, one of the following relations is true: > (UID(m1) > UID(m2)) && (msgno(m1) > msgno(m2)) > or > (UID(m1) < UID(m2)) && (msgno(m1) < msgno(m2)) > > Consequently, the only way to have the functionality of > "remove an attachment from a message" is to append a new copy > of the message to the mailbox (with the attachment deleted) > and possibly also delete+expunge the original copy. The new > copy will have a new UID *and* a new relative position (using > sequence numbers) in the mailbox. > > We are talking about a possible functionality by which the > current multistep process could be atomic. I agree that this > would be desirable, and support it; but I also pointed out > some pitfalls that need to be addressed. > > > Is the problem that other clients would not be able to > relate the new > > version of the message to the old? > > This isn't the issue. Any relationship will have to be with > whatever mechanisms are already being used, e.g. Message-ID. > > What is the issue is that data in the middle of the mailbox > can not be altered or added. You can add data at the end, or > remove data anywhere. This is a guaranteed (and useful) > property of IMAP, but it does preclude the more > straightforward scheme of "selective removal of attachments" > that Madan Ganesh suggested. > > So we need a little bit of creativity to do something that > IMAP will tolerate. > > -- 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 hA55GPkT089024 for ; Tue, 4 Nov 2003 21:16: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 hA55GP14089023 for ietf-imapext-bks; Tue, 4 Nov 2003 21:16:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from miranda.org (IDENT:qmailr@miranda.org [209.58.150.153]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA55GOkT089018 for ; Tue, 4 Nov 2003 21:16:24 -0800 (PST) (envelope-from ams@wiw.org) Received: (qmail 22479 invoked from network); 5 Nov 2003 05:16:08 -0000 Received: from miranda.org (HELO lustre.dyn.wiw.org) (ams@209.58.150.153) by miranda.org with SMTP; 5 Nov 2003 05:16:08 -0000 Received: from ams by lustre.dyn.wiw.org with local (Exim 4.20) id 1AHG1W-0005UB-Vm for ietf-imapext@imc.org; Wed, 05 Nov 2003 10:46:06 +0530 Date: Wed, 5 Nov 2003 10:46:06 +0530 From: Abhijit Menon-Sen To: ietf-imapext@imc.org Subject: Re: Selective removal of attachments in a message Message-ID: <20031105104606.A14643@lustre.dyn.wiw.org> References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> <9050000.1067985982@socrates.cyrusoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 2003-11-04 14:55:07 -0800, MRC@CAC.Washington.EDU wrote: > > > Then we're back to the 'copy without attachments' approach... > > Yes. I think that such an extension is potentially a very good idea, > and I would support it. If we're going down that road, perhaps we should consider implementing a more flexible mechanism à la URLAUTH/COMPOSE, which allows more than just removing attachments. It seems inevitable that users will want to recompose messages in other ways, and I'm worried about having several mechanisms doing vaguely the same (set of) things. I supported hitherto the idea of having a separate submission server, but if an IMAP extension is inevitable, I'd rather have just one that addresses all of these requirements. -- ams Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA52FskT082874 for ; Tue, 4 Nov 2003 18:15: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 hA52Fs8D082873 for ietf-imapext-bks; Tue, 4 Nov 2003 18:15:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from larry.webcom.com (larry.webcom.com [192.220.116.41]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA52FrkT082868 for ; Tue, 4 Nov 2003 18:15:53 -0800 (PST) (envelope-from aaddict@maclean.com) Received: from kigal (kigal.webcom.com [192.220.116.57]) by larry.webcom.com (8.11.6/8.9.3) with SMTP id hA52HS809713; Tue, 4 Nov 2003 18:17:28 -0800 Received: from [216.207.178.10] by inanna (WebCom SMTP 2.0) with SMTP id 117926636; Tue Nov 04 18:14 PST 2003 Message-Id: <5.1.1.6.2.20031104210524.036f4968@pop.webcom.com> X-Sender: aaddict@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 04 Nov 2003 21:17:21 -0500 To: Mark Crispin From: Pete Maclean Subject: Re: Selective removal of attachments in a message Cc: Madan Ganesh Velayudham , "'IMAP Extensions WG'" In-Reply-To: References: <5.1.1.6.2.20031104191100.121d6d50@pop.webcom.com> <000601c3a305$19b2ad50$3ce62a0f@nt23060> <000601c3a305$19b2ad50$3ce62a0f@nt23060> <5.1.1.6.2.20031104191100.121d6d50@pop.webcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mimeheaders-Plugin-Info: v2.03.00 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:54 PM 11/4/2003 -0800, Mark Crispin wrote: >On Tue, 4 Nov 2003, Pete Maclean wrote: > > >It would be a nice feature to have; however, it violates the IMAP UID > > >model which guarantees that a UID refers to an immutable object. > > Why does it have to violate the model? Surely if the spec says that on > > processing a REMOVE, the server MUST assign the message a new UID then it > > would be okay. The old UID would be expunged and the new UID would be > > reported in the REMOVE response. > >I'm not sure if we're loudly agreeing or not. I think we are agreeing. But I should perhaps have paid more attention to subsequent messages in this thread before responding since, I realize now, that what I am suggesting is equivalent to a COPY-with-modifications (restricted to the same mailbox) followed by an expunge -- but all done as an atomic operation. I like the idea of having this as an atomic operation. I think it is easier to express it in terms of REMOVE rather than COPY-with-modifications. However it might be effectively redundant in light of the proposed COMPOSE. And, yes, I understand your points about possible difficulties in implementation (as for a MOVE) although I have little experience with quota issues in particular. Pete Maclean Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA50tkkT080427 for ; Tue, 4 Nov 2003 16:55: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 hA50tk96080425 for ietf-imapext-bks; Tue, 4 Nov 2003 16:55:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA50tjkT080419 for ; Tue, 4 Nov 2003 16:55:45 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA50tgaZ011996; Tue, 4 Nov 2003 16:55:42 -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 hA50tfx0009741 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Nov 2003 16:55:41 -0800 Date: Tue, 4 Nov 2003 16:54:50 -0800 (Pacific Standard Time) From: Mark Crispin To: Pete Maclean cc: Madan Ganesh Velayudham , "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message In-Reply-To: <5.1.1.6.2.20031104191100.121d6d50@pop.webcom.com> Message-ID: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <000601c3a305$19b2ad50$3ce62a0f@nt23060> <5.1.1.6.2.20031104191100.121d6d50@pop.webcom.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 4 Nov 2003, Pete Maclean wrote: > >It would be a nice feature to have; however, it violates the IMAP UID > >model which guarantees that a UID refers to an immutable object. > Why does it have to violate the model? Surely if the spec says that on > processing a REMOVE, the server MUST assign the message a new UID then it > would be okay. The old UID would be expunged and the new UID would be > reported in the REMOVE response. I'm not sure if we're loudly agreeing or not. Let's see if this explanation helps: A message on the server can not be altered. The UID refers to an immutable object. UIDs are strictly ascending. Thus for any pair of messages m1 and m2, one of the following relations is true: (UID(m1) > UID(m2)) && (msgno(m1) > msgno(m2)) or (UID(m1) < UID(m2)) && (msgno(m1) < msgno(m2)) Consequently, the only way to have the functionality of "remove an attachment from a message" is to append a new copy of the message to the mailbox (with the attachment deleted) and possibly also delete+expunge the original copy. The new copy will have a new UID *and* a new relative position (using sequence numbers) in the mailbox. We are talking about a possible functionality by which the current multistep process could be atomic. I agree that this would be desirable, and support it; but I also pointed out some pitfalls that need to be addressed. > Is the problem that other clients would not be able to relate the new > version of the message to the old? This isn't the issue. Any relationship will have to be with whatever mechanisms are already being used, e.g. Message-ID. What is the issue is that data in the middle of the mailbox can not be altered or added. You can add data at the end, or remove data anywhere. This is a guaranteed (and useful) property of IMAP, but it does preclude the more straightforward scheme of "selective removal of attachments" that Madan Ganesh suggested. So we need a little bit of creativity to do something that IMAP will tolerate. -- 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 hA50JNkT079203 for ; Tue, 4 Nov 2003 16:19: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 hA50JNBd079202 for ietf-imapext-bks; Tue, 4 Nov 2003 16:19:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from moe.webcom.com (moe.webcom.com [192.220.116.141]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA50JMkT079197 for ; Tue, 4 Nov 2003 16:19:22 -0800 (PST) (envelope-from aaddict@maclean.com) Received: from kigal (kigal.webcom.com [192.220.116.57]) by moe.webcom.com (8.11.6/8.11.6) with SMTP id hA50P9C05511; Tue, 4 Nov 2003 16:25:09 -0800 Received: from [216.207.178.10] by banana (WebCom SMTP 2.0) with SMTP id 255598410; Tue Nov 04 16:20 PST 2003 Message-Id: <5.1.1.6.2.20031104191100.121d6d50@pop.webcom.com> X-Sender: aaddict@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 04 Nov 2003 19:21:06 -0500 To: Mark Crispin , Madan Ganesh Velayudham From: Pete Maclean Subject: Re: Selective removal of attachments in a message Cc: "'IMAP Extensions WG'" In-Reply-To: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <000601c3a305$19b2ad50$3ce62a0f@nt23060> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mimeheaders-Plugin-Info: v2.03.00 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >It would be a nice feature to have; however, it violates the IMAP UID >model which guarantees that a UID refers to an immutable object. It isn't >going to happen Why does it have to violate the model? Surely if the spec says that on processing a REMOVE, the server MUST assign the message a new UID then it would be okay. The old UID would be expunged and the new UID would be reported in the REMOVE response. Is the problem that other clients would not be able to relate the new version of the message to the old? This might be undesirable but consider that, for any mailstore for which access is available by alternate means (in addition to IMAP), such an event might well be possible anyway. Pete Maclean Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4NKokT076935 for ; Tue, 4 Nov 2003 15:20:50 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4NKoG2076934 for ietf-imapext-bks; Tue, 4 Nov 2003 15:20:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4NKnkT076929 for ; Tue, 4 Nov 2003 15:20:49 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA4NKfMk030862; Tue, 4 Nov 2003 15:20:47 -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 hA4NKfx0032499 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Nov 2003 15:20:41 -0800 Date: Tue, 4 Nov 2003 15:20:04 -0800 (Pacific Standard Time) From: Mark Crispin To: Cyrus Daboo cc: "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message In-Reply-To: <19890000.1067986886@socrates.cyrusoft.com> Message-ID: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> <9050000.1067985982@socrates.cyrusoft.com> <19890000.1067986886@socrates.cyrusoft.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 4 Nov 2003, Cyrus Daboo wrote: > can > 'copy-without-attachments' be implemented as an atomic operation that will > not be impacted by quota limits? Certainly it "can". It depends upon how it is defined. This sounds like a case has finally been made for a MOVE command; that is, it would not just be a COPY+DELETE, it would also include an expunge single message. The problem that I see here is that it may be difficult for an implementation to do the operation safely. Suppose it has to do the EXPUNGE step before writing the new message, and then finds that it can't actually do the write. It now is unable to undo the operation, and the message has been lost. What highlights this problem is that the stated purpose is to get around quota problems. Some operating systems are so fascistic in enforcing quotas that they won't let you even do a write() on top of existing data, which in turn renders EXPUNGE in a flat file format impossible. I think that along with the specification for this extension some implementation recommendations are needed. Even servers which control their own quota enforcement (and thus can waive it) still have the problem with a disk full condition. Given that the server is unable to make the copy without first expunging the original (quotas beyond its control, disk full), how should it proceed? If the answer is "punt", then this extension can't be used to fix a "quota exceeded"/"disk full" condition. If the answer is "try and hope for the best", then this extension has a risk of losing the message. -- 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 hA4NDWkT076704 for ; Tue, 4 Nov 2003 15:13:32 -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 hA4NDW2O076703 for ietf-imapext-bks; Tue, 4 Nov 2003 15:13:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4NDVkT076698 for ; Tue, 4 Nov 2003 15:13:31 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA4M9thu003624; Tue, 4 Nov 2003 14:09:59 -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 hA4M9tx0024540 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Nov 2003 14:09:55 -0800 Date: Tue, 4 Nov 2003 14:09:29 -0800 (Pacific Standard Time) From: Mark Crispin To: Cyrus Daboo cc: "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message In-Reply-To: <137500000.1067973772@socrates.cyrusoft.com> Message-ID: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 4 Nov 2003, Cyrus Daboo wrote: > 3) A client that has cached the MIME structure but not the content: > provided the client does not rely on the bodystructure size indicators (and > of course it should not) ^^^^^^^^^^^^^^^^^^^^^^^ I strongly disagree. If you can't rely upon bodystructure size indicators then there is no reasonable way to implement partial fetching. Your proposal also breaks RFC822.SIZE. -- 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 hA4ND1kT076679 for ; Tue, 4 Nov 2003 15:13:01 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4ND1eI076678 for ietf-imapext-bks; Tue, 4 Nov 2003 15:13:01 -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 hA4ND0kT076673 for ; Tue, 4 Nov 2003 15:13:00 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA4MtfC2024962; Tue, 4 Nov 2003 14:55:46 -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 hA4MtfSS023987 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Nov 2003 14:55:41 -0800 Date: Tue, 4 Nov 2003 14:55:07 -0800 (Pacific Standard Time) From: Mark Crispin To: Cyrus Daboo cc: "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message In-Reply-To: <9050000.1067985982@socrates.cyrusoft.com> Message-ID: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> <9050000.1067985982@socrates.cyrusoft.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 4 Nov 2003, Cyrus Daboo wrote: > OK, good point. Then we're back to the 'copy without attachments' > approach... Yes. I think that such an extension is potentially a very good idea, and I would support it. -- 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 hA4N1TkT076238 for ; Tue, 4 Nov 2003 15:01:29 -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 hA4N1TtA076237 for ietf-imapext-bks; Tue, 4 Nov 2003 15:01:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4N1SkT076231 for ; Tue, 4 Nov 2003 15:01:29 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hA4MqrEG030754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Nov 2003 17:52:53 -0500 Date: Tue, 04 Nov 2003 18:01:26 -0500 From: Cyrus Daboo To: Mark Crispin cc: "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message Message-ID: <19890000.1067986886@socrates.cyrusoft.com> In-Reply-To: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> <9050000.1067985982@socrates.cyrusoft.com> X-Mailer: Mulberry/3.1.0b9 (Linux/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Tuesday, November 04, 2003 02:55:07 PM -0800 Mark Crispin wrote: | On Tue, 4 Nov 2003, Cyrus Daboo wrote: |> OK, good point. Then we're back to the 'copy without attachments' |> approach... | | Yes. I think that such an extension is potentially a very good idea, and | I would support it. The question is can we do this in a way that is 'quota' friendly. Specifically, users most often need the 'remove attachments' command when they run over quota (or close to the limit) and need to get back down. The 'copy-with-attachments/delete/expunge-original' isn't going to work in that case because quota will not allow the copy (this is the same as the 'copy-to-trash' problem that often comes up). So, can 'copy-without-attachments' be implemented as an atomic operation that will not be impacted by quota limits? -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4MkVkT075844 for ; Tue, 4 Nov 2003 14:46:31 -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 hA4MkVmX075843 for ietf-imapext-bks; Tue, 4 Nov 2003 14:46:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4MkTkT075834 for ; Tue, 4 Nov 2003 14:46:30 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hA4MbnEG030591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Nov 2003 17:37:49 -0500 Date: Tue, 04 Nov 2003 17:46:22 -0500 From: Cyrus Daboo To: Mark Crispin cc: "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message Message-ID: <9050000.1067985982@socrates.cyrusoft.com> In-Reply-To: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> X-Mailer: Mulberry/3.1.0b9 (Linux/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Tuesday, November 04, 2003 02:09:29 PM -0800 Mark Crispin wrote: |> 3) A client that has cached the MIME structure but not the content: |> provided the client does not rely on the bodystructure size indicators |> (and of course it should not) | ^^^^^^^^^^^^^^^^^^^^^^^ | | I strongly disagree. | | If you can't rely upon bodystructure size indicators then there is no | reasonable way to implement partial fetching. | | Your proposal also breaks RFC822.SIZE. OK, good point. Then we're back to the 'copy without attachments' approach... -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JN4kT068680 for ; Tue, 4 Nov 2003 11:23:04 -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 hA4JN4qr068679 for ietf-imapext-bks; Tue, 4 Nov 2003 11:23:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JN2kT068671 for ; Tue, 4 Nov 2003 11:23:03 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hA4JEKEG027515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Nov 2003 14:14:24 -0500 Date: Tue, 04 Nov 2003 14:22:52 -0500 From: Cyrus Daboo To: Mark Crispin cc: "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message Message-ID: <137500000.1067973772@socrates.cyrusoft.com> In-Reply-To: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> X-Mailer: Mulberry/3.1.0b9 (Linux/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Tuesday, November 04, 2003 11:00:46 AM -0800 Mark Crispin wrote: | It would be a nice feature to have; however, it violates the IMAP UID | model which guarantees that a UID refers to an immutable object. It isn't | going to happen | | A way to work around the problem (and something that some people would | probably like) would be a "copy message without listed attachments" | command. So, while you can't delete the attachment from the original | message, you can make a copy of the message without the attachment and | delete the original message. The benefit of the new command would be that | the client wouldn't have to download the message just to append it back; | currently that's the only way to do "delete attachment". That sounds a little like the 'compose on the server' extension for lemonade! Actually, there is one potential way to get around the immutable message situation without caching problems with disconnected clients. Rather than delete the actual MIME part, the delete command would instead remove the MIME part content, but leave the MIME structure intact - i.e. fetching the MIME body returns nothing. Removal would also change the content-disposition on the removed parts to a new type of 'removed' with some ancillary parameters to indicate when it was removed etc. How would this affect clients: 1) A client that has never seen the message before will not be affected, except for the fact that the user will see empty parts. The content-disposition can be used to show that the part content was deleted at some point in the past. 2) A client that has cached the entire message (mime structure and content) will not be affected as it will retrieve the mime content from its local cache. 3) A client that has cached the MIME structure but not the content: provided the client does not rely on the bodystructure size indicators (and of course it should not) there should be no problem about the fact that the client gets back zero bytes for the MIME body. The user may be surprised by this (as in situation 1) and it may be hard to determine exactly what happened as the cached bodystructure won't include the new content-disposition: removed indicator. I think this is as close as you can get to an in-place attachment removal mechanism without causing caching problems for clients - however, the unexpected case in situation (3) may not be tolerable. Perhaps there are other issues I've not considered that would make this inappropriate? -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4J0xkT067683 for ; Tue, 4 Nov 2003 11:00: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 hA4J0xJY067682 for ietf-imapext-bks; Tue, 4 Nov 2003 11:00:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4J0wkT067677 for ; Tue, 4 Nov 2003 11:00:58 -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 hA4J0jhu001192; Tue, 4 Nov 2003 11:00:50 -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 hA4J0jSS030502 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Nov 2003 11:00:45 -0800 Date: Tue, 4 Nov 2003 11:00:46 -0800 (Pacific Standard Time) From: Mark Crispin To: Madan Ganesh Velayudham cc: "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message In-Reply-To: <000601c3a305$19b2ad50$3ce62a0f@nt23060> Message-ID: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> 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: It would be a nice feature to have; however, it violates the IMAP UID model which guarantees that a UID refers to an immutable object. It isn't going to happen A way to work around the problem (and something that some people would probably like) would be a "copy message without listed attachments" command. So, while you can't delete the attachment from the original message, you can make a copy of the message without the attachment and delete the original message. The benefit of the new command would be that the client wouldn't have to download the message just to append it back; currently that's the only way to do "delete attachment". -- 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 hA4IsekT067505 for ; Tue, 4 Nov 2003 10:54:40 -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 hA4IseXp067504 for ietf-imapext-bks; Tue, 4 Nov 2003 10:54:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4IsdkT067499 for ; Tue, 4 Nov 2003 10:54:39 -0800 (PST) (envelope-from mganesh@india.hp.com) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel13.hp.com (Postfix) with ESMTP id 0812D1C016FB for ; Tue, 4 Nov 2003 10:54:40 -0800 (PST) Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id AAA00880; Wed, 5 Nov 2003 00:23:26 +0530 (IST) From: "Madan Ganesh Velayudham" To: "'IMAP Extensions WG'" Cc: "'Madan Ganesh Velayudham'" Subject: Selective removal of attachments in a message Date: Wed, 5 Nov 2003 00:24:39 +0530 Organization: Hewlett-Packard STSD Message-ID: <000601c3a305$19b2ad50$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01C3A333.336AE950" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C3A333.336AE950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please share your thoughts on the attached document. Sincerely, MG ************************** Madan Ganesh Velayudham madan-ganesh.v@hp.com +91-80-205-3108 ************************** +HP/STSD/Internet Services Bangalore, India Everything is possible ------=_NextPart_000_0007_01C3A333.336AE950 Content-Type: text/plain; name="madanganeshv-remove-attachment-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="madanganeshv-remove-attachment-00.txt" REMOVE: Selective removal of attachments from a Message ========================================================= Abstract Clients could want to remove attachments selectively from a message in the mailbox. Currently there is no mechanism by which a IMAP client can achieve this. Overview : [RFC 3501] defines DELETE command to delete a mailbox and store \Deleted + EXPUNGE sequence to permanently delete a message in a mailbox. There is no way by which a client can selectively delete/ remove attachments or message parts from a message in a mailbox. As decribed in the Section 6.4.5 of [RFC 3501], every message has at least one part number. Non-[MIME-IMB] messages, and non -multipart messages with no encapsulated message, only have a part 1. Multipart messages are assigned consecutive part numbers, as they occur in the message. If a particular part is of type message or multipart, its parts MUST be indicated by a period followed by the part number within that nested multipart part. A part of type MESSAGE/RFC822 also has nested part numbers, referring to parts of the MESSAGE part's body. Clients can use REMOVE command to remove part(s) of message(s) in a mailbox. CAPABILITY identification IMAP4 servers that support this extension MUST include an REMOVE capability response in teh response list to the CAPABILITY command. REMOVE Command Arguments: sequence set message data item names Responses: untagged responses: REMOVE Result: OK - Remove completed NO - Remove error BAD - Command Unknown The REMOVE command removes part associated with a message in the mailbox. Return codes and other issues WORK IN PROGRESS Security considerations WORK IN PROGRESS Author Madan Ganesh Velayudham Hewlett-Packard madan-ganesh.v@hp.com +91-80-205-3108 ------=_NextPart_000_0007_01C3A333.336AE950-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4GhakT062408 for ; Tue, 4 Nov 2003 08:43:37 -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 hA4GhaEk062407 for ietf-imapext-bks; Tue, 4 Nov 2003 08:43:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4GhZkT062402 for ; Tue, 4 Nov 2003 08:43:35 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA4GhVaZ021091; Tue, 4 Nov 2003 08:43:36 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA4GhU93006799; Tue, 4 Nov 2003 08:43:30 -0800 Date: Tue, 4 Nov 2003 08:43:30 -0800 (PST) From: Mark Crispin To: Pete Resnick cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Proposed agenda? In-Reply-To: Message-ID: References: <3FA3C5DF.4060602@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 Tue, 4 Nov 2003, Pete Resnick wrote: > >Probably URLAUTH needs at least a glance. > I don't necessarily object to our discussing it (if we've got time), > but aren't all of the "usual suspects" going to be in LEMONADE anyway? Agreed, but an "IMAPEXT point of view" would be useful. -- 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 hA4GB6kT061151 for ; Tue, 4 Nov 2003 08:11:06 -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 hA4GB6Cq061150 for ietf-imapext-bks; Tue, 4 Nov 2003 08:11:06 -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 hA4GB5kT061144 for ; Tue, 4 Nov 2003 08:11:05 -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.3b1); Tue, 4 Nov 2003 10:11:03 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: <3FA3C5DF.4060602@isode.com> X-Mailer: Eudora [Macintosh version 6.1a2] Date: Tue, 4 Nov 2003 10:11:01 -0600 To: Mark Crispin From: Pete Resnick Subject: Re: Proposed agenda? Cc: Alexey Melnikov , IMAP Extensions WG 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 11/3/03 at 11:04 PM -0800, Mark Crispin wrote: >Probably URLAUTH needs at least a glance. I don't necessarily object to our discussing it (if we've got time), but aren't all of the "usual suspects" going to be in LEMONADE anyway? 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 hA474ekT097558 for ; Mon, 3 Nov 2003 23:04:40 -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 hA474e5J097557 for ietf-imapext-bks; Mon, 3 Nov 2003 23:04:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA474YkT097517 for ; Mon, 3 Nov 2003 23:04:34 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA474Vmw022337; Mon, 3 Nov 2003 23:04:37 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA474VnL025919; Mon, 3 Nov 2003 23:04:31 -0800 Date: Mon, 3 Nov 2003 23:04:31 -0800 (PST) From: Mark Crispin To: Pete Resnick cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Proposed agenda? In-Reply-To: Message-ID: References: <3FA3C5DF.4060602@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 Mon, 3 Nov 2003, Pete Resnick wrote: > I'd very much like to hear from Chris Newman and Cyrus and/or Randy > about what we will be discussing re: their documents. Anyone else > have stuff to talk about? Probably URLAUTH needs at least a glance. -- 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 hA436wkT063213 for ; Mon, 3 Nov 2003 19:06:58 -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 hA436wdF063212 for ietf-imapext-bks; Mon, 3 Nov 2003 19:06:58 -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 hA436okT063202 for ; Mon, 3 Nov 2003 19:06:53 -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.3b1); Mon, 3 Nov 2003 21:06:48 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <3FA3C5DF.4060602@isode.com> References: <3FA3C5DF.4060602@isode.com> X-Mailer: Eudora [Macintosh version 6.1a2] Date: Mon, 3 Nov 2003 21:06:46 -0600 To: Alexey Melnikov From: Pete Resnick Subject: Re: Proposed agenda? Cc: IMAP Extensions WG 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 11/1/03 at 2:40 PM +0000, Alexey Melnikov wrote: >I still haven't heard any agenda proposals for Minneapolis IMAPEXT meeting. I'd very much like to hear from Chris Newman and Cyrus and/or Randy about what we will be discussing re: their documents. Anyone else have stuff to talk about? 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 hA1FnGkT016002 for ; Sat, 1 Nov 2003 07:49:16 -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 hA1FnGDT016001 for ietf-imapext-bks; Sat, 1 Nov 2003 07:49:16 -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 hA1FnAkT015994 for ; Sat, 1 Nov 2003 07:49:15 -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; Sat, 1 Nov 2003 15:49:50 +0000 Message-ID: <3FA3D5F4.7050704@isode.com> Date: Sat, 01 Nov 2003 15:49:08 +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: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: Proposed agenda? References: <3FA3C5DF.4060602@isode.com> <720249994.1067681943@[10.0.1.12]> In-Reply-To: <720249994.1067681943@[10.0.1.12]> 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: Cyrus Daboo wrote: > Hi Alexey, > > --On Saturday, November 1, 2003 14:40 +0000 Alexey Melnikov > wrote: > > | > | I still haven't heard any agenda proposals for Minneapolis IMAPEXT > | meeting. > | As I am not attending this meeting, I would like to know in advance > what > | I am going to miss. > | > | Is there any point for doing a draft revision of ACL2 for people to > | discuss in Minneapolis? > | (I am a bit busy at work right now, so this is a selfish question. > But I > | will produce something > | if people think it is necessary/beneficial to discuss the document in > | Minneapolis) > > How about the current document authors summarize the outstanding > issues with their docs on the list early next week and that can form > the basis for the agenda (or perhaps we can even resolve the issues on > the list before the meeting). Ok. CONDSTORE: I've sent private email to Application Area ADs with some clarifications. I got no response yet. Hopefully the answer would be that I need to do a minor revision to the document and no Last Call would be required. ACL2: I've done nothing since August. I was reading various discussion threads, but I have yet to summarize required changes. No changes to Keywords so far. I mostly agree with Mark on silly states and complicated dependencies, but I personally would like to keep certain keywords that he and Lyndon proposed to remove. Revision of "disconnected clients" will come shortly after the Minneapolis meeting. I've requested Ned/Ted to Last Call UNSELECT. I've done almost nothing on QUOTA plus (draft-cridland-imap-quota-00.txt) Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1FIskT014754 for ; Sat, 1 Nov 2003 07:18: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 hA1FIscV014753 for ietf-imapext-bks; Sat, 1 Nov 2003 07:18:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1FIrkT014748 for ; Sat, 1 Nov 2003 07:18:53 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.12] (pool-151-201-242-89.pitt.east.verizon.net [151.201.242.89]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hA1FAjEG002163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Nov 2003 10:10:48 -0500 Date: Sat, 01 Nov 2003 10:19:03 -0500 From: Cyrus Daboo To: Alexey Melnikov , IMAP Extensions WG Subject: Re: Proposed agenda? Message-ID: <720249994.1067681943@[10.0.1.12]> In-Reply-To: <3FA3C5DF.4060602@isode.com> References: <3FA3C5DF.4060602@isode.com> X-Mailer: Mulberry/3.1.0b9 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Saturday, November 1, 2003 14:40 +0000 Alexey Melnikov wrote: | | I still haven't heard any agenda proposals for Minneapolis IMAPEXT | meeting. | As I am not attending this meeting, I would like to know in advance what | I am going to miss. | | Is there any point for doing a draft revision of ACL2 for people to | discuss in Minneapolis? | (I am a bit busy at work right now, so this is a selfish question. But I | will produce something | if people think it is necessary/beneficial to discuss the document in | Minneapolis) How about the current document authors summarise the outstanding issues with their docs on the list early next week and that can form the basis for the agenda (or perhaps we can even resolve the issues on the list before the meeting). -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1EiwkT013726 for ; Sat, 1 Nov 2003 06:44:58 -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 hA1Eiv7o013724 for ietf-imapext-bks; Sat, 1 Nov 2003 06:44:58 -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 hA1EiukT013715 for ; Sat, 1 Nov 2003 06:44:57 -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; Sat, 1 Nov 2003 14:41:13 +0000 Message-ID: <3FA3C5DF.4060602@isode.com> Date: Sat, 01 Nov 2003 14:40:31 +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: IMAP Extensions WG Subject: Proposed agenda? 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 still haven't heard any agenda proposals for Minneapolis IMAPEXT meeting. As I am not attending this meeting, I would like to know in advance what I am going to miss. Is there any point for doing a draft revision of ACL2 for people to discuss in Minneapolis? (I am a bit busy at work right now, so this is a selfish question. But I will produce something if people think it is necessary/beneficial to discuss the document in Minneapolis) Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1DSCkT010288 for ; Sat, 1 Nov 2003 05:28:12 -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 hA1DSCvR010287 for ietf-imapext-bks; Sat, 1 Nov 2003 05:28:12 -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 hA1DS6kT010280 for ; Sat, 1 Nov 2003 05:28:11 -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; Sat, 1 Nov 2003 13:28:39 +0000 Message-ID: <3FA3B4DD.60702@isode.com> Date: Sat, 01 Nov 2003 13:27:57 +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: Cyrus Daboo , ietf-imapext@imc.org, Lyndon Nerenberg Subject: Re: Jabbering - imapext@ietf.xmpp.org References: <2147483647.1067597124@[10.0.1.10]> 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: > On 10/31/03 at 10:45 AM -0500, Cyrus Daboo wrote: > >> If serious discussions are going to take place on the jabber list, is >> it possible to have some summary of those posted to the email list > > Absolutely, though my feeling is that serious discussions should *not* > take place in jabber at this point. Jabber might be a nice way, if > someone happens to be around, to ask a quick "Hey, what's the status > of my draft?" or "I don't understand a piece of this draft. Can > someone explain what I'm missing, or should I bring this to the author > as a problem?" kind of question. I expect serious issue discussions to > always be on the list. IMHO, Jabber is a very useful tool for real time communication with people who are unable to attend. And, IMHO, partial feedback is better than no feedback. Of course it doesn't replace mailing list discussions. Selecting a good scribe is a non trivial task (and makes a big difference). Maybe we should bribe well- known-good-scribes (e.g. Marshall Rose) ;-)? Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPJDTib096403 for ; Tue, 25 Nov 2003 11:13:29 -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 hAPJDTVc096402 for ietf-imapext-bks; Tue, 25 Nov 2003 11:13:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mauve.mrochek.com ([209.55.107.55]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAPJDSib096343 for ; Tue, 25 Nov 2003 11:13:28 -0800 (PST) (envelope-from ned+imapext@innosoft.com) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01L39N9OKIAO00HOW2@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf-imapext@imc.org; Mon, 24 Nov 2003 10:41:29 -0800 (PST) Date: Mon, 24 Nov 2003 10:35:12 -0800 (PST) From: ned+imapext@innosoft.com Subject: AD review comments on draft-ietf-imapext-sort-13.txt In-reply-to: "Your message dated Sat, 15 Nov 2003 10:51:20 -0600" <2147483647.1068893480@[10.0.1.5]> To: ietf-imapext@imc.org Message-id: <01L3ENYV8XBA00HOW2@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Content-transfer-encoding: 7BIT Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This documents defines two threading algorithms, ORDEREDSUBJECT and REFERENCES, and the IANA considerations section makes it sound like there's a registry for threading algorithms with these as the two initial entries. However, this document doesn't actually define such a registry. I see two possibilities here: There are only two threading algorithms, end of story, no registry needed and hence the text about this in the IANA considerations section needs to be removed (unlikely), or else this document creates a new registry for threading algorithms with these two as the initial entries. If it is the latter there needs to be text added to define the registry and explain what the registration procedures are (RFC required, first come first serve, etc.). In the "Sent Date" section, the procedure implied by "adjusted by time zone" needs to be spelled out in a little more detail lest we end up with some "creative" interpretations and corresponding implementations. It might also make sense to discuss how to handle a date field with an invalid time zone specification. In the discussion of the charset argument for SORT and THREAD, reference is made to the charset argument to SEARCH defined in the base specification, but this document doesn't actually come out and specify that the semantics of SORT and THREAD's charset argument are the same as that for SEARCH's. I suggest adding a sentence along the lines of "The charset argument indicates the [CHARSET] of the strings that appear in the {sort|thread} criteria." to the relevant sections. The [CHARSET] reference would also need to be added to the normative references. The section containing the ABNF needs to state that it employs ABNF productions defined in RFC 3501. In the ABNF, change "; CHARSET argument to MUST be registered with IANA" to read "; CHARSET values MUST be registered with IANA" The RFC Editor views abstracts as essentially separate from the document propoer. As such, it is usually necessary to have both an Abstract describing the document as a whole very tersely and a separate introduction to the specification that describes its purpose in a bit more detail. The paragraph on MUST/SHOULD/MAY/etc. conventions needs to be moved to a section of its own separate from the abstract. The paragraph discussing capability announcment of the SORT and THREAD extensions also needs to be moved to a separate section. This document doesn't contain either the copyright or the IPR boilerplate required by RFC 2026. The section numbering in this document is, well, strange. Most sections aren't numbered, but then near the end up pops a section 12 and appendix A. I understand the desire to want to use section numbers to align the command and response material with RFC 3501, but I don't think this obviates the need for the rest of the document to have sensible section numbers. Here's an alternate suggestion: For the sections intended to be "inserted" into RFFC 3501, preface the section numbers with "BASE." or something similar. Then number the various other sections of this document normally. That's it! Ned Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAFGpMkT076134 for ; Sat, 15 Nov 2003 08:51: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 hAFGpMOM076133 for ietf-imapext-bks; Sat, 15 Nov 2003 08:51:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAFGpKkT076127 for ; Sat, 15 Nov 2003 08:51:21 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.5] (pool-151-201-224-88.pitt.east.verizon.net [151.201.224.88]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hAFGf3EG012539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2003 11:41:07 -0500 Date: Sat, 15 Nov 2003 10:51:20 -0600 From: Cyrus Daboo To: Rob Siemborski , ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman Message-ID: <2147483647.1068893480@[10.0.1.5]> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob, --On Friday, November 14, 2003 18:41 -0500 Rob Siemborski wrote: | Comments? As a general comment I would support a split to two ACL mechanisms: a simple one and a complex one (the later being based on the existing ACL). I think ACL2 has become too unwieldy in trying to support arbitrary ACL models and will ultimately prove to be a huge hurdle to implementation on the client (which is the end that potentially has to support the multitude of server models that can exist). It was pointed out in the meeting that WebDAV seems to suffer from that problem - the server's model is over generalized and its hard for a client to get all the possible options right - interop is poor. So I think Rob is on the right track - we need an ACL+ to update the existing ACL spec. Then a simple Read-Only/Read-Write ACL model extension. The two need to co-exist, but a server may support only one, though I think we should recommend an ACL+ server also support PERMISSIONS. Of course this does mean writing off the current ACL2 spec (though much of the work for ACL+ has been done in ACL2). There are also other extensions that have a dependency on ACL and those would need to be held up until we can decide what to do (I'm primarily thinking about ANNOTATE here). That's probably not something Pete wants to hear - but I think we can get ACL+PERMISSIONS done quickly - and it would probably be faster than trying to resolve all the issues with ACL2's arbitrary models. It also means effectively having two ACL extensions rather than one. The question is whether the IESG would push-back on that - we need to get input from the ADs on that matter before we can decide whether to go ahead with this. Clearly we would pitch this as a simplification of this work - cutting down an arbitrary ACL model implementation (with many possible models) to two fixed models, which should make implementations and security analysis etc much easier to accomplish. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF3QWkT057577 for ; Fri, 14 Nov 2003 19:26:32 -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 hAF3QWe8057576 for ietf-imapext-bks; Fri, 14 Nov 2003 19:26:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAF3QUkT057571 for ; Fri, 14 Nov 2003 19:26:30 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hAF3QVhu008429; Fri, 14 Nov 2003 19:26:32 -0800 Received: from localhost (mrc@localhost) by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hAF3QVcf032102; Fri, 14 Nov 2003 19:26:31 -0800 Date: Fri, 14 Nov 2003 19:26:31 -0800 (PST) From: Mark Crispin To: Rob Siemborski cc: ietf-imapext@imc.org Subject: Re: Yet another ACL Strawman In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Rob - This is an interesting idea. Give me some time to mull it over. This may be the way out! -- 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 hAENfEkT045219 for ; Fri, 14 Nov 2003 15:41:16 -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 hAENfEum045218 for ietf-imapext-bks; Fri, 14 Nov 2003 15:41:14 -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 hAENfCkT045210 for ; Fri, 14 Nov 2003 15:41:13 -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 hAENfE5G022948 for ; Fri, 14 Nov 2003 18:41:14 -0500 Date: Fri, 14 Nov 2003 18:41:14 -0500 (EST) From: Rob Siemborski To: ietf-imapext@imc.org Subject: Yet another ACL Strawman Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: After the IMAPext meeting I spoke with some people and got to thinking if there was a way we could come up with a way to do IMAP sharing that will satisfy both the enterprise people who need detailed ACL support, and those who feel the need to implement permissions with limited backend support (e.g. UNIX file permissions). Ideally, such a mechanism would be simple to implement and not have complexity problems getting past the IESG. I'd like to propose the following as a strawman INSTEAD of the current ACL2 draft (or whatever ACL2 became after the last round of comments): Create an ACL+ capability that does the following: * Can only be advertised if ACL is advertised * adds the x (DELETE mailbox), t (set \Deleted), and e (EXPUNGE) bits to ACL, and redefines the 'd' bit to "x && t && e" (like ACL2) There may be other changes from ACL2 that I missed here, but the general goal is "do the minimum required to fix ACL". This may imply changing how the namespace of identifiers are treated as well (e.g. user=foo, group=bar), but I'd really like to keep the changes as minimal as possible here if we can. Create a new PERMISSIONS capability that works along the lines of the following: * Define four bits you can set on a mailbox: owner read/write and anyone read/write. Have a command other than the ACL manipulation commands that can manipulate/report these. If a server advertises *both* PERMISSIONS and ACL, then it must also advertise ACL+. Also, the PERMISSIONS bits are tied as follows to ACL bits for the *owner* of a mailbox and for the "anyone" identifier (in the ACL): On a mailbox that can contain messages: read: lr write: wite (I'm not sure how to tie 's' -- maybe Mark can answer that). On a mailbox that can contain mailboxes: read: l write: cx "Dual-use" mailboxes get the union of the applicable above sets of bits. Identifiers in the ACL that correspond to entities other than the owner and 'anyone' are not advertised through the permissions extension. Note that in a ACL+PERMISSIONS system, the rights advertised through the PERMISSIONS extension are exactly the rights that match the owner's identifier and the "anyone" identifier. Negative rights are not advertised through, the PERMISSIONS system. When resolving actual rights, the ACL must be fully calculated (i.e. the PERMISSIONS interface is just an alternate way to get to *some* of the functionality of ACL). Note also that this does not tie 'a' or 'p' to anything, I would expect the PERMISSIONS extension to honor 'a', and I would expect 'p' to only be manipulatable through the ACL extension, though perhaps that isn't quite the right thing. If a server implements *only* PERMISSIONS and does not implement ACL, then it should keep the semantics that would be provided by the ACL bits as defined above for each PERMISSIONS bit (and implicitly grant 'a' to the owner). However, in this case, the bits advertised through PERMISSIONS *are* authoritative. I think that this setup is significantly simpler than having to bend over backwards to force ACLs onto unix filesystem semantics just to allow simple folder sharing, and it still allows enterprise servers to continue to support the flexibility provided by the ACL extension. I've intentionally left some things open here: specifically interaction with LISTEXT and the exact syntax of how PERMISSIONS would look on the wire. I have also left open the question of interpreting the ACL (rather, I left it as it was in 2086). The syntax question, at least, could be worked out when a formal draft was issued. I will note that this does not provide for groups to be used through the PERMISSIONS mechanism. However, it seems to me that the large demand is "share folders globally", and this provides for that. This would also provide a simple standard mapping for "read" and "write" acls to mailboxes, which sees to also have been in demand. Comments? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * rjs3@andrew.cmu.edu * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAD2R4kT058011 for ; Wed, 12 Nov 2003 18:27:04 -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 hAD2R4wq058010 for ietf-imapext-bks; Wed, 12 Nov 2003 18:27:04 -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 hAD2R2kT058004 for ; Wed, 12 Nov 2003 18:27:02 -0800 (PST) (envelope-from presnick@qualcomm.com) Received: from [130.129.68.236] (130.129.133.140) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b1) for ; Wed, 12 Nov 2003 20:27:04 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 6.1a2] Date: Wed, 12 Nov 2003 19:08:04 -0600 To: ietf-imapext@imc.org From: Pete Resnick Subject: Bad chair - No blue sheet Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have shirked one of my responsibilities: I forgot to get the blue sheet for the IMAPEXT meeting. :-( I remember everyone there who said something. I know there were at least three people (and probably a couple more) that were in the room that I missed. Please add to this list if you can help me: Mark Crispin Cyrus Daboo Lisa Dusseault Randy Gellens Larry Greenfield Philip Guenther Ted Hardie John Klensin Chris Newman Rob Siemborski Thanks. 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 hABIdlkT014909 for ; Tue, 11 Nov 2003 10:39:47 -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 hABIdlAp014908 for ietf-imapext-bks; Tue, 11 Nov 2003 10:39:47 -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 hABIdfkT014902 for ; Tue, 11 Nov 2003 10:39:46 -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; Tue, 11 Nov 2003 18:41:13 +0000 Message-ID: <3FB12CEA.2030900@isode.com> Date: Tue, 11 Nov 2003 18:39:38 +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: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: ANNOTATE/ANNOTATEMORE issues References: <2147483647.1068461809@dyn131-202.ietf58.ietf.org> In-Reply-To: <2147483647.1068461809@dyn131-202.ietf58.ietf.org> 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: Cyrus Daboo wrote: > ANNOTATE issues for discussion on Wednesday: > > - No comments after last draft. Currently no open issues... Is it > ready for last call? Most likely. > ANNOTATEMORE issues: > > - SETANNOTATION on multiple mailboxes - how to handle partial > failures. Some solutions: > > * Fail entire annotation change on all mailboxes. Requires server > to rollback all changes across all mailboxes. > * Allow partial failure/success untagged response to indicate which > changes succeeded or failed, if some of them fail. > * Don't allow multi-mailbox SETANNOTATION. I think the first choice is non practical. The second is already suggested by ACL2. Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAGufkT081781 for ; Mon, 10 Nov 2003 08:56:41 -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 hAAGufOx081780 for ietf-imapext-bks; Mon, 10 Nov 2003 08:56:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAAGuekT081775 for ; Mon, 10 Nov 2003 08:56:40 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from dyn131-202.ietf58.ietf.org (dyn131-202.ietf58.ietf.org [130.129.131.202]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hAAGlCEG012109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Nov 2003 11:47:13 -0500 Date: Mon, 10 Nov 2003 10:56:49 -0600 From: Cyrus Daboo To: IMAP Extensions WG Subject: ANNOTATE/ANNOTATEMORE issues Message-ID: <2147483647.1068461809@dyn131-202.ietf58.ietf.org> X-Mailer: Mulberry/3.1.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ANNOTATE issues for discussion on Wednesday: - No comments after last draft. Currently no open issues... Is it ready for last call? ANNOTATEMORE issues: - SETANNOTATION on multiple mailboxes - how to handle partial failures. Some solutions: * Fail entire annotation change on all mailboxes. Requires server to rollback all changes across all mailboxes. * Allow partial failure/success untagged response to indicate which changes succeeded or failed, if some of them fail. * Don't allow multi-mailbox SETANNOTATION. -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5HSukT091248 for ; Wed, 5 Nov 2003 09:28:56 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5HSu3i091247 for ietf-imapext-bks; Wed, 5 Nov 2003 09:28:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5HSqkT091241 for ; Wed, 5 Nov 2003 09:28:52 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA5HSnaZ003935; Wed, 5 Nov 2003 09:28:49 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA5HSm3e002581; Wed, 5 Nov 2003 09:28:49 -0800 Date: Wed, 5 Nov 2003 09:28:48 -0800 (PST) From: Mark Crispin To: Arnt Gulbrandsen cc: ietf-imapext@imc.org, Abhijit Menon-Sen Subject: Re: Selective removal of attachments in a message In-Reply-To: <+8uJlfkF0Blwx//JPO3p6Q.md5@libertango.oryx.com> Message-ID: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> <9050000.1067985982@socrates.cyrusoft.com> <20031105104606.A14643@lustre.dyn.wiw.org> <+8uJlfkF0Blwx//JPO3p6Q.md5@libertango.oryx.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, 5 Nov 2003, Arnt Gulbrandsen wrote: > No. The argument goes: If you can't prevent from being in > IMAP anyway, cave in and at least avoid having it in two places. But the ability to delete attachments is very different from composing new messages or editing an existing message. Some implementations *may* accomplish this by similar means, but that is implementation rather than concept. Furthermore, if compose is placed in IMAP, then composition is stuck with using IMAP forever. POP and NNTP clients will now have to have IMAP client code in order to do compose with those protocols (you could add compose to POP and NNTP. Now you have compose in three places). Time and time again, I hear "IMAP is a lousy design, IMAP is too weak to do anything useful, IMAP is going to have to be completely redesigned and replaced from the ground up." Why then do you want to create long-term dependencies upon IMAP? The superior solution is to have compose as a separate service, independent of any particular message access protocol, and thus equally usable with all message access mechanisms. This requires mechanisms and profiles, such as URLAUTH, to allow the compose service access to message data in IMAP, POP, NNTP, and future protocols. If building monoliths is so good, what is the point of having multiple protocols in the IETF suite? Why not have a single protocol for everything, such as the videotex systems of the 1970s? -- 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 hA5GLnkT086918 for ; Wed, 5 Nov 2003 08:21:49 -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 hA5GLnbv086917 for ietf-imapext-bks; Wed, 5 Nov 2003 08:21:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from libertango.oryx.com (libertango.oryx.com [195.30.94.163]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5GLmkT086912 for ; Wed, 5 Nov 2003 08:21:49 -0800 (PST) (envelope-from arnt@gulbrandsen.priv.no) Message-Id: <+8uJlfkF0Blwx//JPO3p6Q.md5@libertango.oryx.com> From: Arnt Gulbrandsen To: Mark Crispin Subject: Re: Selective removal of attachments in a message Cc: ietf-imapext@imc.org, Abhijit Menon-Sen References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> <9050000.1067985982@socrates.cyrusoft.com> <20031105104606.A14643@lustre.dyn.wiw.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed MIME-Version: 1.0 Date: Wed, 5 Nov 2003 17:21:50 +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hA5GLnkT086913 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mark Crispin writes: > On Wed, 5 Nov 2003, Abhijit Menon-Sen wrote: >> If we're going down that road, perhaps we should consider >> implementing a more flexible mechanism $B`(B la URLAUTH/COMPOSE, >> which allows more than just removing (why this corruption?) >> attachments. It seems inevitable that users will want to recompose >> messages in other ways, and I'm worried about having several >> mechanisms doing vaguely the same (set of) things. > > This doesn't make sense to me. The extreme form of that argument leads > to the conclusion that SMTP should be in IMAP because you can delete > and expunge messages in IMAP. No. The argument goes: If you can't prevent from being in IMAP anyway, cave in and at least avoid having it in two places. "Unavoidable" is very different from "good". > It seems to me that people who ask for this really don't want IMAP; > they want Exchange. That could be. --Arnt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5G2ZkT086053 for ; Wed, 5 Nov 2003 08:02:35 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5G2ZNO086052 for ietf-imapext-bks; Wed, 5 Nov 2003 08:02:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5G2XkT086046 for ; Wed, 5 Nov 2003 08:02:33 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA5G2UaZ023321; Wed, 5 Nov 2003 08:02:30 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA5G2UJA029899; Wed, 5 Nov 2003 08:02:30 -0800 Date: Wed, 5 Nov 2003 08:02:30 -0800 (PST) From: Mark Crispin To: Abhijit Menon-Sen cc: ietf-imapext@imc.org Subject: Re: Selective removal of attachments in a message In-Reply-To: <20031105104606.A14643@lustre.dyn.wiw.org> Message-ID: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> <9050000.1067985982@socrates.cyrusoft.com> <20031105104606.A14643@lustre.dyn.wiw.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, 5 Nov 2003, Abhijit Menon-Sen wrote: > If we're going down that road, perhaps we should consider implementing > a more flexible mechanism $B`(B la URLAUTH/COMPOSE, which allows more than > just removing attachments. It seems inevitable that users will want to > recompose messages in other ways, and I'm worried about having several > mechanisms doing vaguely the same (set of) things. This doesn't make sense to me. The extreme form of that argument leads to the conclusion that SMTP should be in IMAP because you can delete and expunge messages in IMAP. If you want to *edit* a message (something which I personally believe is morally wrong -- it is taking a real message from someone else and creating a forgery), then some form of COMPOSE mechanism is necessary. Editing is different from a mechanism that merely removes some attachments but leaves the message itself intact. Nor does having a COMPOSE functionality necessitate it being in IMAP. COMPOSE takes IMAP far afield from its mission of message access. We have numerous examples of server implementations that don't get the in-mission tasks of IMAP right. How then can anyone believe that further bloating IMAP with extraneous tasks will result in better-working servers? It seems to me that people who ask for this really don't want IMAP; they want Exchange. IMAP is designed to be small tool among a set of small tools, each of which does its own job well; Exchange is designed to be a monolith that does everything. I hope that people aren't still being mislead by the long-standing myth that "TCP connections are expensive." -- 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 hA5DjZkT080180 for ; Wed, 5 Nov 2003 05:45:35 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA5DjZfP080179 for ietf-imapext-bks; Wed, 5 Nov 2003 05:45:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA5DjYkT080174 for ; Wed, 5 Nov 2003 05:45:34 -0800 (PST) (envelope-from mganesh@india.hp.com) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel11.hp.com (Postfix) with ESMTP id E9FE21C02736; Wed, 5 Nov 2003 05:45:31 -0800 (PST) Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id TAA14935; Wed, 5 Nov 2003 19:14:13 +0530 (IST) From: "Madan Ganesh Velayudham" To: "'Mark Crispin'" , "'Pete Maclean'" Cc: "'IMAP Extensions WG'" Subject: RE: Selective removal of attachments in a message Date: Wed, 5 Nov 2003 19:15:26 +0530 Organization: Hewlett-Packard STSD Message-ID: <009d01c3a3a3$14722ed0$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, Pete, Thank you for your comments. Yes, I have totally agree with your comments and would work on the solution part and would send the completed draft. > remove data anywhere. This is a guaranteed (and useful) > property of IMAP, but it does preclude the more > straightforward scheme of "selective removal of attachments" > that Madan Ganesh suggested. Pls help me in understanding this statement. As I described in the draft-draft version, I've been working on how we would remove the attachment and have not disclosed how IMAP could achieve this. As you suggested, the REMOVE should do an atomic operation : Copy the message with modification to the end of the mailbox + Expunge the original message. Please let me know your comments. Thanks and Regards, MG > -----Original Message----- > From: owner-ietf-imapext@mail.imc.org > [mailto:owner-ietf-imapext@mail.imc.org] On Behalf Of Mark Crispin > Sent: Wednesday, November 05, 2003 6:25 AM > To: Pete Maclean > Cc: Madan Ganesh Velayudham; 'IMAP Extensions WG' > Subject: Re: Selective removal of attachments in a message > > > > On Tue, 4 Nov 2003, Pete Maclean wrote: > > >It would be a nice feature to have; however, it violates > the IMAP UID > > >model which guarantees that a UID refers to an immutable object. > > Why does it have to violate the model? Surely if the spec > says that > > on processing a REMOVE, the server MUST assign the message > a new UID > > then it would be okay. The old UID would be expunged and > the new UID > > would be reported in the REMOVE response. > > I'm not sure if we're loudly agreeing or not. Let's see if > this explanation helps: > > A message on the server can not be altered. The UID refers > to an immutable object. > > UIDs are strictly ascending. Thus for any pair of messages > m1 and m2, one of the following relations is true: > (UID(m1) > UID(m2)) && (msgno(m1) > msgno(m2)) > or > (UID(m1) < UID(m2)) && (msgno(m1) < msgno(m2)) > > Consequently, the only way to have the functionality of > "remove an attachment from a message" is to append a new copy > of the message to the mailbox (with the attachment deleted) > and possibly also delete+expunge the original copy. The new > copy will have a new UID *and* a new relative position (using > sequence numbers) in the mailbox. > > We are talking about a possible functionality by which the > current multistep process could be atomic. I agree that this > would be desirable, and support it; but I also pointed out > some pitfalls that need to be addressed. > > > Is the problem that other clients would not be able to > relate the new > > version of the message to the old? > > This isn't the issue. Any relationship will have to be with > whatever mechanisms are already being used, e.g. Message-ID. > > What is the issue is that data in the middle of the mailbox > can not be altered or added. You can add data at the end, or > remove data anywhere. This is a guaranteed (and useful) > property of IMAP, but it does preclude the more > straightforward scheme of "selective removal of attachments" > that Madan Ganesh suggested. > > So we need a little bit of creativity to do something that > IMAP will tolerate. > > -- 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 hA55GPkT089024 for ; Tue, 4 Nov 2003 21:16: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 hA55GP14089023 for ietf-imapext-bks; Tue, 4 Nov 2003 21:16:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from miranda.org (IDENT:qmailr@miranda.org [209.58.150.153]) by above.proper.com (8.12.10/8.12.8) with SMTP id hA55GOkT089018 for ; Tue, 4 Nov 2003 21:16:24 -0800 (PST) (envelope-from ams@wiw.org) Received: (qmail 22479 invoked from network); 5 Nov 2003 05:16:08 -0000 Received: from miranda.org (HELO lustre.dyn.wiw.org) (ams@209.58.150.153) by miranda.org with SMTP; 5 Nov 2003 05:16:08 -0000 Received: from ams by lustre.dyn.wiw.org with local (Exim 4.20) id 1AHG1W-0005UB-Vm for ietf-imapext@imc.org; Wed, 05 Nov 2003 10:46:06 +0530 Date: Wed, 5 Nov 2003 10:46:06 +0530 From: Abhijit Menon-Sen To: ietf-imapext@imc.org Subject: Re: Selective removal of attachments in a message Message-ID: <20031105104606.A14643@lustre.dyn.wiw.org> References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> <9050000.1067985982@socrates.cyrusoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 2003-11-04 14:55:07 -0800, MRC@CAC.Washington.EDU wrote: > > > Then we're back to the 'copy without attachments' approach... > > Yes. I think that such an extension is potentially a very good idea, > and I would support it. If we're going down that road, perhaps we should consider implementing a more flexible mechanism à la URLAUTH/COMPOSE, which allows more than just removing attachments. It seems inevitable that users will want to recompose messages in other ways, and I'm worried about having several mechanisms doing vaguely the same (set of) things. I supported hitherto the idea of having a separate submission server, but if an IMAP extension is inevitable, I'd rather have just one that addresses all of these requirements. -- ams Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA52FskT082874 for ; Tue, 4 Nov 2003 18:15: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 hA52Fs8D082873 for ietf-imapext-bks; Tue, 4 Nov 2003 18:15:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from larry.webcom.com (larry.webcom.com [192.220.116.41]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA52FrkT082868 for ; Tue, 4 Nov 2003 18:15:53 -0800 (PST) (envelope-from aaddict@maclean.com) Received: from kigal (kigal.webcom.com [192.220.116.57]) by larry.webcom.com (8.11.6/8.9.3) with SMTP id hA52HS809713; Tue, 4 Nov 2003 18:17:28 -0800 Received: from [216.207.178.10] by inanna (WebCom SMTP 2.0) with SMTP id 117926636; Tue Nov 04 18:14 PST 2003 Message-Id: <5.1.1.6.2.20031104210524.036f4968@pop.webcom.com> X-Sender: aaddict@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 04 Nov 2003 21:17:21 -0500 To: Mark Crispin From: Pete Maclean Subject: Re: Selective removal of attachments in a message Cc: Madan Ganesh Velayudham , "'IMAP Extensions WG'" In-Reply-To: References: <5.1.1.6.2.20031104191100.121d6d50@pop.webcom.com> <000601c3a305$19b2ad50$3ce62a0f@nt23060> <000601c3a305$19b2ad50$3ce62a0f@nt23060> <5.1.1.6.2.20031104191100.121d6d50@pop.webcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mimeheaders-Plugin-Info: v2.03.00 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 04:54 PM 11/4/2003 -0800, Mark Crispin wrote: >On Tue, 4 Nov 2003, Pete Maclean wrote: > > >It would be a nice feature to have; however, it violates the IMAP UID > > >model which guarantees that a UID refers to an immutable object. > > Why does it have to violate the model? Surely if the spec says that on > > processing a REMOVE, the server MUST assign the message a new UID then it > > would be okay. The old UID would be expunged and the new UID would be > > reported in the REMOVE response. > >I'm not sure if we're loudly agreeing or not. I think we are agreeing. But I should perhaps have paid more attention to subsequent messages in this thread before responding since, I realize now, that what I am suggesting is equivalent to a COPY-with-modifications (restricted to the same mailbox) followed by an expunge -- but all done as an atomic operation. I like the idea of having this as an atomic operation. I think it is easier to express it in terms of REMOVE rather than COPY-with-modifications. However it might be effectively redundant in light of the proposed COMPOSE. And, yes, I understand your points about possible difficulties in implementation (as for a MOVE) although I have little experience with quota issues in particular. Pete Maclean Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA50tkkT080427 for ; Tue, 4 Nov 2003 16:55: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 hA50tk96080425 for ietf-imapext-bks; Tue, 4 Nov 2003 16:55:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA50tjkT080419 for ; Tue, 4 Nov 2003 16:55:45 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA50tgaZ011996; Tue, 4 Nov 2003 16:55:42 -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 hA50tfx0009741 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Nov 2003 16:55:41 -0800 Date: Tue, 4 Nov 2003 16:54:50 -0800 (Pacific Standard Time) From: Mark Crispin To: Pete Maclean cc: Madan Ganesh Velayudham , "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message In-Reply-To: <5.1.1.6.2.20031104191100.121d6d50@pop.webcom.com> Message-ID: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <000601c3a305$19b2ad50$3ce62a0f@nt23060> <5.1.1.6.2.20031104191100.121d6d50@pop.webcom.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 4 Nov 2003, Pete Maclean wrote: > >It would be a nice feature to have; however, it violates the IMAP UID > >model which guarantees that a UID refers to an immutable object. > Why does it have to violate the model? Surely if the spec says that on > processing a REMOVE, the server MUST assign the message a new UID then it > would be okay. The old UID would be expunged and the new UID would be > reported in the REMOVE response. I'm not sure if we're loudly agreeing or not. Let's see if this explanation helps: A message on the server can not be altered. The UID refers to an immutable object. UIDs are strictly ascending. Thus for any pair of messages m1 and m2, one of the following relations is true: (UID(m1) > UID(m2)) && (msgno(m1) > msgno(m2)) or (UID(m1) < UID(m2)) && (msgno(m1) < msgno(m2)) Consequently, the only way to have the functionality of "remove an attachment from a message" is to append a new copy of the message to the mailbox (with the attachment deleted) and possibly also delete+expunge the original copy. The new copy will have a new UID *and* a new relative position (using sequence numbers) in the mailbox. We are talking about a possible functionality by which the current multistep process could be atomic. I agree that this would be desirable, and support it; but I also pointed out some pitfalls that need to be addressed. > Is the problem that other clients would not be able to relate the new > version of the message to the old? This isn't the issue. Any relationship will have to be with whatever mechanisms are already being used, e.g. Message-ID. What is the issue is that data in the middle of the mailbox can not be altered or added. You can add data at the end, or remove data anywhere. This is a guaranteed (and useful) property of IMAP, but it does preclude the more straightforward scheme of "selective removal of attachments" that Madan Ganesh suggested. So we need a little bit of creativity to do something that IMAP will tolerate. -- 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 hA50JNkT079203 for ; Tue, 4 Nov 2003 16:19: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 hA50JNBd079202 for ietf-imapext-bks; Tue, 4 Nov 2003 16:19:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from moe.webcom.com (moe.webcom.com [192.220.116.141]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA50JMkT079197 for ; Tue, 4 Nov 2003 16:19:22 -0800 (PST) (envelope-from aaddict@maclean.com) Received: from kigal (kigal.webcom.com [192.220.116.57]) by moe.webcom.com (8.11.6/8.11.6) with SMTP id hA50P9C05511; Tue, 4 Nov 2003 16:25:09 -0800 Received: from [216.207.178.10] by banana (WebCom SMTP 2.0) with SMTP id 255598410; Tue Nov 04 16:20 PST 2003 Message-Id: <5.1.1.6.2.20031104191100.121d6d50@pop.webcom.com> X-Sender: aaddict@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 04 Nov 2003 19:21:06 -0500 To: Mark Crispin , Madan Ganesh Velayudham From: Pete Maclean Subject: Re: Selective removal of attachments in a message Cc: "'IMAP Extensions WG'" In-Reply-To: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <000601c3a305$19b2ad50$3ce62a0f@nt23060> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mimeheaders-Plugin-Info: v2.03.00 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >It would be a nice feature to have; however, it violates the IMAP UID >model which guarantees that a UID refers to an immutable object. It isn't >going to happen Why does it have to violate the model? Surely if the spec says that on processing a REMOVE, the server MUST assign the message a new UID then it would be okay. The old UID would be expunged and the new UID would be reported in the REMOVE response. Is the problem that other clients would not be able to relate the new version of the message to the old? This might be undesirable but consider that, for any mailstore for which access is available by alternate means (in addition to IMAP), such an event might well be possible anyway. Pete Maclean Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4NKokT076935 for ; Tue, 4 Nov 2003 15:20:50 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4NKoG2076934 for ietf-imapext-bks; Tue, 4 Nov 2003 15:20:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4NKnkT076929 for ; Tue, 4 Nov 2003 15:20:49 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA4NKfMk030862; Tue, 4 Nov 2003 15:20:47 -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 hA4NKfx0032499 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Nov 2003 15:20:41 -0800 Date: Tue, 4 Nov 2003 15:20:04 -0800 (Pacific Standard Time) From: Mark Crispin To: Cyrus Daboo cc: "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message In-Reply-To: <19890000.1067986886@socrates.cyrusoft.com> Message-ID: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> <9050000.1067985982@socrates.cyrusoft.com> <19890000.1067986886@socrates.cyrusoft.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 4 Nov 2003, Cyrus Daboo wrote: > can > 'copy-without-attachments' be implemented as an atomic operation that will > not be impacted by quota limits? Certainly it "can". It depends upon how it is defined. This sounds like a case has finally been made for a MOVE command; that is, it would not just be a COPY+DELETE, it would also include an expunge single message. The problem that I see here is that it may be difficult for an implementation to do the operation safely. Suppose it has to do the EXPUNGE step before writing the new message, and then finds that it can't actually do the write. It now is unable to undo the operation, and the message has been lost. What highlights this problem is that the stated purpose is to get around quota problems. Some operating systems are so fascistic in enforcing quotas that they won't let you even do a write() on top of existing data, which in turn renders EXPUNGE in a flat file format impossible. I think that along with the specification for this extension some implementation recommendations are needed. Even servers which control their own quota enforcement (and thus can waive it) still have the problem with a disk full condition. Given that the server is unable to make the copy without first expunging the original (quotas beyond its control, disk full), how should it proceed? If the answer is "punt", then this extension can't be used to fix a "quota exceeded"/"disk full" condition. If the answer is "try and hope for the best", then this extension has a risk of losing the message. -- 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 hA4NDWkT076704 for ; Tue, 4 Nov 2003 15:13:32 -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 hA4NDW2O076703 for ietf-imapext-bks; Tue, 4 Nov 2003 15:13:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4NDVkT076698 for ; Tue, 4 Nov 2003 15:13:31 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA4M9thu003624; Tue, 4 Nov 2003 14:09:59 -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 hA4M9tx0024540 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Nov 2003 14:09:55 -0800 Date: Tue, 4 Nov 2003 14:09:29 -0800 (Pacific Standard Time) From: Mark Crispin To: Cyrus Daboo cc: "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message In-Reply-To: <137500000.1067973772@socrates.cyrusoft.com> Message-ID: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 4 Nov 2003, Cyrus Daboo wrote: > 3) A client that has cached the MIME structure but not the content: > provided the client does not rely on the bodystructure size indicators (and > of course it should not) ^^^^^^^^^^^^^^^^^^^^^^^ I strongly disagree. If you can't rely upon bodystructure size indicators then there is no reasonable way to implement partial fetching. Your proposal also breaks RFC822.SIZE. -- 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 hA4ND1kT076679 for ; Tue, 4 Nov 2003 15:13:01 -0800 (PST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4ND1eI076678 for ietf-imapext-bks; Tue, 4 Nov 2003 15:13:01 -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 hA4ND0kT076673 for ; Tue, 4 Nov 2003 15:13:00 -0800 (PST) (envelope-from MRC@CAC.Washington.EDU) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA4MtfC2024962; Tue, 4 Nov 2003 14:55:46 -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 hA4MtfSS023987 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Nov 2003 14:55:41 -0800 Date: Tue, 4 Nov 2003 14:55:07 -0800 (Pacific Standard Time) From: Mark Crispin To: Cyrus Daboo cc: "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message In-Reply-To: <9050000.1067985982@socrates.cyrusoft.com> Message-ID: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> <9050000.1067985982@socrates.cyrusoft.com> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 4 Nov 2003, Cyrus Daboo wrote: > OK, good point. Then we're back to the 'copy without attachments' > approach... Yes. I think that such an extension is potentially a very good idea, and I would support it. -- 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 hA4N1TkT076238 for ; Tue, 4 Nov 2003 15:01:29 -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 hA4N1TtA076237 for ietf-imapext-bks; Tue, 4 Nov 2003 15:01:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4N1SkT076231 for ; Tue, 4 Nov 2003 15:01:29 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hA4MqrEG030754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Nov 2003 17:52:53 -0500 Date: Tue, 04 Nov 2003 18:01:26 -0500 From: Cyrus Daboo To: Mark Crispin cc: "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message Message-ID: <19890000.1067986886@socrates.cyrusoft.com> In-Reply-To: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> <9050000.1067985982@socrates.cyrusoft.com> X-Mailer: Mulberry/3.1.0b9 (Linux/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Tuesday, November 04, 2003 02:55:07 PM -0800 Mark Crispin wrote: | On Tue, 4 Nov 2003, Cyrus Daboo wrote: |> OK, good point. Then we're back to the 'copy without attachments' |> approach... | | Yes. I think that such an extension is potentially a very good idea, and | I would support it. The question is can we do this in a way that is 'quota' friendly. Specifically, users most often need the 'remove attachments' command when they run over quota (or close to the limit) and need to get back down. The 'copy-with-attachments/delete/expunge-original' isn't going to work in that case because quota will not allow the copy (this is the same as the 'copy-to-trash' problem that often comes up). So, can 'copy-without-attachments' be implemented as an atomic operation that will not be impacted by quota limits? -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4MkVkT075844 for ; Tue, 4 Nov 2003 14:46:31 -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 hA4MkVmX075843 for ietf-imapext-bks; Tue, 4 Nov 2003 14:46:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4MkTkT075834 for ; Tue, 4 Nov 2003 14:46:30 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hA4MbnEG030591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Nov 2003 17:37:49 -0500 Date: Tue, 04 Nov 2003 17:46:22 -0500 From: Cyrus Daboo To: Mark Crispin cc: "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message Message-ID: <9050000.1067985982@socrates.cyrusoft.com> In-Reply-To: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> <137500000.1067973772@socrates.cyrusoft.com> X-Mailer: Mulberry/3.1.0b9 (Linux/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Tuesday, November 04, 2003 02:09:29 PM -0800 Mark Crispin wrote: |> 3) A client that has cached the MIME structure but not the content: |> provided the client does not rely on the bodystructure size indicators |> (and of course it should not) | ^^^^^^^^^^^^^^^^^^^^^^^ | | I strongly disagree. | | If you can't rely upon bodystructure size indicators then there is no | reasonable way to implement partial fetching. | | Your proposal also breaks RFC822.SIZE. OK, good point. Then we're back to the 'copy without attachments' approach... -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JN4kT068680 for ; Tue, 4 Nov 2003 11:23:04 -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 hA4JN4qr068679 for ietf-imapext-bks; Tue, 4 Nov 2003 11:23:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4JN2kT068671 for ; Tue, 4 Nov 2003 11:23:03 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [63.163.82.24]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hA4JEKEG027515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Nov 2003 14:14:24 -0500 Date: Tue, 04 Nov 2003 14:22:52 -0500 From: Cyrus Daboo To: Mark Crispin cc: "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message Message-ID: <137500000.1067973772@socrates.cyrusoft.com> In-Reply-To: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> X-Mailer: Mulberry/3.1.0b9 (Linux/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mark, --On Tuesday, November 04, 2003 11:00:46 AM -0800 Mark Crispin wrote: | It would be a nice feature to have; however, it violates the IMAP UID | model which guarantees that a UID refers to an immutable object. It isn't | going to happen | | A way to work around the problem (and something that some people would | probably like) would be a "copy message without listed attachments" | command. So, while you can't delete the attachment from the original | message, you can make a copy of the message without the attachment and | delete the original message. The benefit of the new command would be that | the client wouldn't have to download the message just to append it back; | currently that's the only way to do "delete attachment". That sounds a little like the 'compose on the server' extension for lemonade! Actually, there is one potential way to get around the immutable message situation without caching problems with disconnected clients. Rather than delete the actual MIME part, the delete command would instead remove the MIME part content, but leave the MIME structure intact - i.e. fetching the MIME body returns nothing. Removal would also change the content-disposition on the removed parts to a new type of 'removed' with some ancillary parameters to indicate when it was removed etc. How would this affect clients: 1) A client that has never seen the message before will not be affected, except for the fact that the user will see empty parts. The content-disposition can be used to show that the part content was deleted at some point in the past. 2) A client that has cached the entire message (mime structure and content) will not be affected as it will retrieve the mime content from its local cache. 3) A client that has cached the MIME structure but not the content: provided the client does not rely on the bodystructure size indicators (and of course it should not) there should be no problem about the fact that the client gets back zero bytes for the MIME body. The user may be surprised by this (as in situation 1) and it may be hard to determine exactly what happened as the cached bodystructure won't include the new content-disposition: removed indicator. I think this is as close as you can get to an in-place attachment removal mechanism without causing caching problems for clients - however, the unexpected case in situation (3) may not be tolerable. Perhaps there are other issues I've not considered that would make this inappropriate? -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4J0xkT067683 for ; Tue, 4 Nov 2003 11:00: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 hA4J0xJY067682 for ietf-imapext-bks; Tue, 4 Nov 2003 11:00:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4J0wkT067677 for ; Tue, 4 Nov 2003 11:00:58 -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 hA4J0jhu001192; Tue, 4 Nov 2003 11:00:50 -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 hA4J0jSS030502 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Nov 2003 11:00:45 -0800 Date: Tue, 4 Nov 2003 11:00:46 -0800 (Pacific Standard Time) From: Mark Crispin To: Madan Ganesh Velayudham cc: "'IMAP Extensions WG'" Subject: Re: Selective removal of attachments in a message In-Reply-To: <000601c3a305$19b2ad50$3ce62a0f@nt23060> Message-ID: References: <000601c3a305$19b2ad50$3ce62a0f@nt23060> 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: It would be a nice feature to have; however, it violates the IMAP UID model which guarantees that a UID refers to an immutable object. It isn't going to happen A way to work around the problem (and something that some people would probably like) would be a "copy message without listed attachments" command. So, while you can't delete the attachment from the original message, you can make a copy of the message without the attachment and delete the original message. The benefit of the new command would be that the client wouldn't have to download the message just to append it back; currently that's the only way to do "delete attachment". -- 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 hA4IsekT067505 for ; Tue, 4 Nov 2003 10:54:40 -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 hA4IseXp067504 for ietf-imapext-bks; Tue, 4 Nov 2003 10:54:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4IsdkT067499 for ; Tue, 4 Nov 2003 10:54:39 -0800 (PST) (envelope-from mganesh@india.hp.com) Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel13.hp.com (Postfix) with ESMTP id 0812D1C016FB for ; Tue, 4 Nov 2003 10:54:40 -0800 (PST) Received: from nt23060 (nt23060.india.hp.com [15.42.230.60]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id AAA00880; Wed, 5 Nov 2003 00:23:26 +0530 (IST) From: "Madan Ganesh Velayudham" To: "'IMAP Extensions WG'" Cc: "'Madan Ganesh Velayudham'" Subject: Selective removal of attachments in a message Date: Wed, 5 Nov 2003 00:24:39 +0530 Organization: Hewlett-Packard STSD Message-ID: <000601c3a305$19b2ad50$3ce62a0f@nt23060> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01C3A333.336AE950" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C3A333.336AE950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please share your thoughts on the attached document. Sincerely, MG ************************** Madan Ganesh Velayudham madan-ganesh.v@hp.com +91-80-205-3108 ************************** +HP/STSD/Internet Services Bangalore, India Everything is possible ------=_NextPart_000_0007_01C3A333.336AE950 Content-Type: text/plain; name="madanganeshv-remove-attachment-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="madanganeshv-remove-attachment-00.txt" REMOVE: Selective removal of attachments from a Message ========================================================= Abstract Clients could want to remove attachments selectively from a message in the mailbox. Currently there is no mechanism by which a IMAP client can achieve this. Overview : [RFC 3501] defines DELETE command to delete a mailbox and store \Deleted + EXPUNGE sequence to permanently delete a message in a mailbox. There is no way by which a client can selectively delete/ remove attachments or message parts from a message in a mailbox. As decribed in the Section 6.4.5 of [RFC 3501], every message has at least one part number. Non-[MIME-IMB] messages, and non -multipart messages with no encapsulated message, only have a part 1. Multipart messages are assigned consecutive part numbers, as they occur in the message. If a particular part is of type message or multipart, its parts MUST be indicated by a period followed by the part number within that nested multipart part. A part of type MESSAGE/RFC822 also has nested part numbers, referring to parts of the MESSAGE part's body. Clients can use REMOVE command to remove part(s) of message(s) in a mailbox. CAPABILITY identification IMAP4 servers that support this extension MUST include an REMOVE capability response in teh response list to the CAPABILITY command. REMOVE Command Arguments: sequence set message data item names Responses: untagged responses: REMOVE Result: OK - Remove completed NO - Remove error BAD - Command Unknown The REMOVE command removes part associated with a message in the mailbox. Return codes and other issues WORK IN PROGRESS Security considerations WORK IN PROGRESS Author Madan Ganesh Velayudham Hewlett-Packard madan-ganesh.v@hp.com +91-80-205-3108 ------=_NextPart_000_0007_01C3A333.336AE950-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4GhakT062408 for ; Tue, 4 Nov 2003 08:43:37 -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 hA4GhaEk062407 for ietf-imapext-bks; Tue, 4 Nov 2003 08:43:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4GhZkT062402 for ; Tue, 4 Nov 2003 08:43:35 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA4GhVaZ021091; Tue, 4 Nov 2003 08:43:36 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA4GhU93006799; Tue, 4 Nov 2003 08:43:30 -0800 Date: Tue, 4 Nov 2003 08:43:30 -0800 (PST) From: Mark Crispin To: Pete Resnick cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Proposed agenda? In-Reply-To: Message-ID: References: <3FA3C5DF.4060602@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 Tue, 4 Nov 2003, Pete Resnick wrote: > >Probably URLAUTH needs at least a glance. > I don't necessarily object to our discussing it (if we've got time), > but aren't all of the "usual suspects" going to be in LEMONADE anyway? Agreed, but an "IMAPEXT point of view" would be useful. -- 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 hA4GB6kT061151 for ; Tue, 4 Nov 2003 08:11:06 -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 hA4GB6Cq061150 for ietf-imapext-bks; Tue, 4 Nov 2003 08:11:06 -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 hA4GB5kT061144 for ; Tue, 4 Nov 2003 08:11:05 -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.3b1); Tue, 4 Nov 2003 10:11:03 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: References: <3FA3C5DF.4060602@isode.com> X-Mailer: Eudora [Macintosh version 6.1a2] Date: Tue, 4 Nov 2003 10:11:01 -0600 To: Mark Crispin From: Pete Resnick Subject: Re: Proposed agenda? Cc: Alexey Melnikov , IMAP Extensions WG 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 11/3/03 at 11:04 PM -0800, Mark Crispin wrote: >Probably URLAUTH needs at least a glance. I don't necessarily object to our discussing it (if we've got time), but aren't all of the "usual suspects" going to be in LEMONADE anyway? 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 hA474ekT097558 for ; Mon, 3 Nov 2003 23:04:40 -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 hA474e5J097557 for ietf-imapext-bks; Mon, 3 Nov 2003 23:04:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA474YkT097517 for ; Mon, 3 Nov 2003 23:04:34 -0800 (PST) (envelope-from mrc@CAC.Washington.EDU) Received: from shiva0.cac.washington.edu (shiva0.cac.washington.edu [140.142.100.200]) by mxout4.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA474Vmw022337; Mon, 3 Nov 2003 23:04:37 -0800 Received: from localhost (mrc@localhost) by shiva0.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id hA474VnL025919; Mon, 3 Nov 2003 23:04:31 -0800 Date: Mon, 3 Nov 2003 23:04:31 -0800 (PST) From: Mark Crispin To: Pete Resnick cc: Alexey Melnikov , IMAP Extensions WG Subject: Re: Proposed agenda? In-Reply-To: Message-ID: References: <3FA3C5DF.4060602@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 Mon, 3 Nov 2003, Pete Resnick wrote: > I'd very much like to hear from Chris Newman and Cyrus and/or Randy > about what we will be discussing re: their documents. Anyone else > have stuff to talk about? Probably URLAUTH needs at least a glance. -- 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 hA436wkT063213 for ; Mon, 3 Nov 2003 19:06:58 -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 hA436wdF063212 for ietf-imapext-bks; Mon, 3 Nov 2003 19:06:58 -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 hA436okT063202 for ; Mon, 3 Nov 2003 19:06:53 -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.3b1); Mon, 3 Nov 2003 21:06:48 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <3FA3C5DF.4060602@isode.com> References: <3FA3C5DF.4060602@isode.com> X-Mailer: Eudora [Macintosh version 6.1a2] Date: Mon, 3 Nov 2003 21:06:46 -0600 To: Alexey Melnikov From: Pete Resnick Subject: Re: Proposed agenda? Cc: IMAP Extensions WG 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 11/1/03 at 2:40 PM +0000, Alexey Melnikov wrote: >I still haven't heard any agenda proposals for Minneapolis IMAPEXT meeting. I'd very much like to hear from Chris Newman and Cyrus and/or Randy about what we will be discussing re: their documents. Anyone else have stuff to talk about? 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 hA1FnGkT016002 for ; Sat, 1 Nov 2003 07:49:16 -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 hA1FnGDT016001 for ietf-imapext-bks; Sat, 1 Nov 2003 07:49:16 -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 hA1FnAkT015994 for ; Sat, 1 Nov 2003 07:49:15 -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; Sat, 1 Nov 2003 15:49:50 +0000 Message-ID: <3FA3D5F4.7050704@isode.com> Date: Sat, 01 Nov 2003 15:49:08 +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: Cyrus Daboo CC: IMAP Extensions WG Subject: Re: Proposed agenda? References: <3FA3C5DF.4060602@isode.com> <720249994.1067681943@[10.0.1.12]> In-Reply-To: <720249994.1067681943@[10.0.1.12]> 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: Cyrus Daboo wrote: > Hi Alexey, > > --On Saturday, November 1, 2003 14:40 +0000 Alexey Melnikov > wrote: > > | > | I still haven't heard any agenda proposals for Minneapolis IMAPEXT > | meeting. > | As I am not attending this meeting, I would like to know in advance > what > | I am going to miss. > | > | Is there any point for doing a draft revision of ACL2 for people to > | discuss in Minneapolis? > | (I am a bit busy at work right now, so this is a selfish question. > But I > | will produce something > | if people think it is necessary/beneficial to discuss the document in > | Minneapolis) > > How about the current document authors summarize the outstanding > issues with their docs on the list early next week and that can form > the basis for the agenda (or perhaps we can even resolve the issues on > the list before the meeting). Ok. CONDSTORE: I've sent private email to Application Area ADs with some clarifications. I got no response yet. Hopefully the answer would be that I need to do a minor revision to the document and no Last Call would be required. ACL2: I've done nothing since August. I was reading various discussion threads, but I have yet to summarize required changes. No changes to Keywords so far. I mostly agree with Mark on silly states and complicated dependencies, but I personally would like to keep certain keywords that he and Lyndon proposed to remove. Revision of "disconnected clients" will come shortly after the Minneapolis meeting. I've requested Ned/Ted to Last Call UNSELECT. I've done almost nothing on QUOTA plus (draft-cridland-imap-quota-00.txt) Alexey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1FIskT014754 for ; Sat, 1 Nov 2003 07:18: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 hA1FIscV014753 for ietf-imapext-bks; Sat, 1 Nov 2003 07:18:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1FIrkT014748 for ; Sat, 1 Nov 2003 07:18:53 -0800 (PST) (envelope-from daboo@cyrusoft.com) Received: from [10.0.1.12] (pool-151-201-242-89.pitt.east.verizon.net [151.201.242.89]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id hA1FAjEG002163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Nov 2003 10:10:48 -0500 Date: Sat, 01 Nov 2003 10:19:03 -0500 From: Cyrus Daboo To: Alexey Melnikov , IMAP Extensions WG Subject: Re: Proposed agenda? Message-ID: <720249994.1067681943@[10.0.1.12]> In-Reply-To: <3FA3C5DF.4060602@isode.com> References: <3FA3C5DF.4060602@isode.com> X-Mailer: Mulberry/3.1.0b9 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Alexey, --On Saturday, November 1, 2003 14:40 +0000 Alexey Melnikov wrote: | | I still haven't heard any agenda proposals for Minneapolis IMAPEXT | meeting. | As I am not attending this meeting, I would like to know in advance what | I am going to miss. | | Is there any point for doing a draft revision of ACL2 for people to | discuss in Minneapolis? | (I am a bit busy at work right now, so this is a selfish question. But I | will produce something | if people think it is necessary/beneficial to discuss the document in | Minneapolis) How about the current document authors summarise the outstanding issues with their docs on the list early next week and that can form the basis for the agenda (or perhaps we can even resolve the issues on the list before the meeting). -- Cyrus Daboo Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1EiwkT013726 for ; Sat, 1 Nov 2003 06:44:58 -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 hA1Eiv7o013724 for ietf-imapext-bks; Sat, 1 Nov 2003 06:44:58 -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 hA1EiukT013715 for ; Sat, 1 Nov 2003 06:44:57 -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; Sat, 1 Nov 2003 14:41:13 +0000 Message-ID: <3FA3C5DF.4060602@isode.com> Date: Sat, 01 Nov 2003 14:40:31 +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: IMAP Extensions WG Subject: Proposed agenda? 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 still haven't heard any agenda proposals for Minneapolis IMAPEXT meeting. As I am not attending this meeting, I would like to know in advance what I am going to miss. Is there any point for doing a draft revision of ACL2 for people to discuss in Minneapolis? (I am a bit busy at work right now, so this is a selfish question. But I will produce something if people think it is necessary/beneficial to discuss the document in Minneapolis) Alexey __________________________________________ Isode Limited, http://www.isode.com IETF standard related pages: http://www.melnikov.ca/mel/devel/Links.html __________________________________________ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA1DSCkT010288 for ; Sat, 1 Nov 2003 05:28:12 -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 hA1DSCvR010287 for ietf-imapext-bks; Sat, 1 Nov 2003 05:28:12 -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 hA1DS6kT010280 for ; Sat, 1 Nov 2003 05:28:11 -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; Sat, 1 Nov 2003 13:28:39 +0000 Message-ID: <3FA3B4DD.60702@isode.com> Date: Sat, 01 Nov 2003 13:27:57 +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: Cyrus Daboo , ietf-imapext@imc.org, Lyndon Nerenberg Subject: Re: Jabbering - imapext@ietf.xmpp.org References: <2147483647.1067597124@[10.0.1.10]> 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: > On 10/31/03 at 10:45 AM -0500, Cyrus Daboo wrote: > >> If serious discussions are going to take place on the jabber list, is >> it possible to have some summary of those posted to the email list > > Absolutely, though my feeling is that serious discussions should *not* > take place in jabber at this point. Jabber might be a nice way, if > someone happens to be around, to ask a quick "Hey, what's the status > of my draft?" or "I don't understand a piece of this draft. Can > someone explain what I'm missing, or should I bring this to the author > as a problem?" kind of question. I expect serious issue discussions to > always be on the list. IMHO, Jabber is a very useful tool for real time communication with people who are unable to attend. And, IMHO, partial feedback is better than no feedback. Of course it doesn't replace mailing list discussions. Selecting a good scribe is a non trivial task (and makes a big difference). Maybe we should bribe well- known-good-scribes (e.g. Marshall Rose) ;-)? Alexey