Received: by ns.secondary.com (8.9.3/8.9.3) id VAA29115 for ietf-imapext-bks; Fri, 18 Feb 2000 21:51:23 -0800 (PST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA29109 for ; Fri, 18 Feb 2000 21:51:21 -0800 (PST) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id VAA11360; Fri, 18 Feb 2000 21:55:05 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (smith@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id VAA00938; Fri, 18 Feb 2000 21:55:05 -0800 Date: Fri, 18 Feb 2000 20:59:29 -0800 (PST) From: Mark Crispin Subject: Re: LAST CALL: I-D ACTION:draft-crispin-imapv-09.txt (fwd) To: Tony Hansen cc: IMAP Interest List , IMAP Extensions WG In-Reply-To: <38AE20C9.4D9ED73C@att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 18 Feb 2000 23:49:13 -0500, Tony Hansen wrote: > Should it be named "Version 4rev2"? 2060 didn't have to be named 4rev1, > but was. Since we've started down the path of using "revX", shouldn't it > be continued? There were incompatible changes between RFC 1730 and RFC 2060. Specifically, poorly-designed RFC 1730 features relating to partial fetching were deleted from the IMAP specification, and much better features added in RFC 2060. A vendor insisted that it had to be possible to distinguish between RFC 1730 and RFC 2060 servers. It's a long story, but my arm was severely twisted to create "IMAP4rev1" (what an ugly name!). No, it was not the Evil Empire. Of course, nobody actually depended upon the broken features of RFC 1730 (if you tried to implement them, you'd find out why...) and everybody thinks that RFC 2060 is the one true IMAP (as they should). But we're apparently stuck with that "rev1" suffix forever. This is not the case with the new draft. The vast majority of the draft consists of clarifications of what is in RFC 2060. There's a small handful of new status codes. Nevertheless, there's no reason for a strict RFC 2060 implementation to have any problem with an implementation that supports the new draft or vice versa. Received: by ns.secondary.com (8.9.3/8.9.3) id UAA26579 for ietf-imapext-bks; Fri, 18 Feb 2000 20:48:07 -0800 (PST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA26574 for ; Fri, 18 Feb 2000 20:48:04 -0800 (PST) Received: from dns.maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id XAA02520 for ; Fri, 18 Feb 2000 23:51:25 -0500 (EST) Received: from att.com ([135.197.86.38]) by maillennium.att.com (labmail) with SMTP id <2000021904490209925300fte>; Sat, 19 Feb 2000 04:49:03 +0000 Message-ID: <38AE20C9.4D9ED73C@att.com> Date: Fri, 18 Feb 2000 23:49:13 -0500 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Interest List , IMAP Extensions WG Subject: Re: LAST CALL: I-D ACTION:draft-crispin-imapv-09.txt (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Should it be named "Version 4rev2"? 2060 didn't have to be named 4rev1, but was. Since we've started down the path of using "revX", shouldn't it be continued? Tony Hansen tony@att.com Mark Crispin wrote: > > I would like to make a last call on the IMAPV document, which is > essentially a bugfix update to RFC 2060. Please read and review it, > since I would like to submit it as an RFC as the new standards-track > bas IMAP specification. > > ---------- Forwarded message ---------- > Subject: I-D ACTION:draft-crispin-imapv-09.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 > Author(s) : M. Crispin > Filename : draft-crispin-imapv-09.txt Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA14352 for ietf-imapext-bks; Fri, 18 Feb 2000 18:29:53 -0800 (PST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA14348 for ; Fri, 18 Feb 2000 18:29:51 -0800 (PST) Received: from microdol1.cac.washington.edu (microdol1.cac.washington.edu [140.142.112.196]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id SAA05513; Fri, 18 Feb 2000 18:33:34 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (localhost [127.0.0.1]) (authenticated as mrc@u.washington.edu with GSSAPI) by microdol1.cac.washington.edu (8.10.0.Beta12/8.10.0.Beta12/UW99.11) with ESMTP id e1J2XXG06207; Fri, 18 Feb 2000 18:33:33 -0800 Date: Fri, 18 Feb 2000 18:33:32 -0800 (PST) From: Mark Crispin To: IMAP Interest List , IMAP Extensions WG Subject: LAST CALL: I-D ACTION:draft-crispin-imapv-09.txt (fwd) Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: I would like to make a last call on the IMAPV document, which is essentially a bugfix update to RFC 2060. Please read and review it, since I would like to submit it as an RFC as the new standards-track bas IMAP specification. ---------- Forwarded message ---------- Date: Thu, 17 Feb 2000 06:27:25 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-crispin-imapv-09.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 Author(s) : M. Crispin Filename : draft-crispin-imapv-09.txt Pages : 93 Date : 16-Feb-00 The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]). IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; [RFC-822] and [MIME-IMB] parsing; searching; and selective fetching of message attributes, texts, and numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in [ACAP]. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP]. IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and unpublished IMAP2bis protocols. In the course of the evolution of IMAP4rev1, some aspects in the earlier protocol have become obsolete. Obsolete commands, responses, and data formats which an IMAP4rev1 implementation can encounter when used with an earlier implementation are described in [IMAP-OBSOLETE]. Other compatibility issues with IMAP2bis, the most common variant of the earlier protocol, are discussed in [IMAP-COMPAT]. A full discussion of compatibility issues with rare (and presumed extinct) variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is primarily of historical interest. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imapv-09.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-crispin-imapv-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-crispin-imapv-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-crispin-imapv-09.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id MAA11814 for ietf-imapext-bks; Wed, 16 Feb 2000 12:29:46 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (bcn@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11808 for ; Wed, 16 Feb 2000 12:29:45 -0800 (PST) Date: Wed, 16 Feb 2000 12:23:11 -0800 (PST) From: Mark Crispin Subject: Re: IMAPEXT Chartering To: Pete Resnick cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , IMAP Extensions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For what it's worth, I had not planned to go to Adelaide. I made multiple inquiries to see if anything IMAP-relevant would go on there, with no answer. Even if I make arrangements to do, I can not get to Adelaide until Tuesday at the swiftest due to other commitments. I don't think that there is a controversy. I haven't heard of anybody in IMAP or IMAPEXT who wants to charter IMAPEXT with base spec work on its agenda. IESG should be told that the unanimous opinion of the IMAP community is a rejection of this notion. On Wed, 16 Feb 2000 11:22:18 -0600, Pete Resnick wrote: > Unless this round of discussion on the list has convinced the people > in question, I think there has been enough indication of controversy > that a WG/BOF meeting be scheduled at Adelaide at which time we > should work this out. Members of the IAB/IESG who think the base spec > work item should be added to the charter ought to be present. Received: by ns.secondary.com (8.9.3/8.9.3) id JAA08055 for ietf-imapext-bks; Wed, 16 Feb 2000 09:19:09 -0800 (PST) Received: from episteme-software.com (resnick1.qualcomm.com [63.250.90.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08051 for ; Wed, 16 Feb 2000 09:19:05 -0800 (PST) Received: from resnick2.qualcomm.com (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0b7); Wed, 16 Feb 2000 11:22:19 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <4121501.3158924958@[192.168.124.51]> References: <4121501.3158924958@[192.168.124.51]> X-Mailer: Eudora [Macintosh version 4.3a?] Date: Wed, 16 Feb 2000 11:22:18 -0600 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Pete Resnick Subject: Re: IMAPEXT Chartering Cc: IMAP Extensions Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I promised not to make a comment on this topic, but it seems that most folks who are going to chime in have done so. So, first with my chairman hat off: On 2/7/00 at 3:09 PM +0100, Patrik Fältström wrote: >How, when, where would you suggest a review of the base spec is done? The base spec is being worked on right now and may be about to go to last call. It can get review during this time, and if there are folks who think that progressing it should be held up until an informational document is produced, they can hold up this rev of the base spec. If a working group is required to get that job done, one can be formed. This can be done independently and in parallel with IMAPEXT. >If that is done in parallell, do you think other people will work >with base spec than IMAPEXT issues? There will clearly be a huge intersection of people. That's irrelevant. Combining the two activities almost guarantees leakage between the two topics. I can hear it now: "Oh, that problem with the base spec can be solved with an extension; let's just add that to our charter." Or even better, "That extension will work if we make one little change to the base spec; let's do that during the base spec review." This has disaster written all over it. Keeping the activities separate forces the extensions to be clean and independent of base spec changes and forces base spec cleanups (if needed) to not be kludges. Now, with my chairman hat on: Unless this round of discussion on the list has convinced the people in question, I think there has been enough indication of controversy that a WG/BOF meeting be scheduled at Adelaide at which time we should work this out. Members of the IAB/IESG who think the base spec work item should be added to the charter ought to be present. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA05284 for ietf-imapext-bks; Wed, 16 Feb 2000 07:23:43 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05280 for ; Wed, 16 Feb 2000 07:23:42 -0800 (PST) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id KAA10891; Wed, 16 Feb 2000 10:26:33 -0500 (EST) Date: Wed, 16 Feb 2000 10:26:59 -0500 From: Cyrus Daboo To: Mark Crispin cc: IMAP Extensions Subject: Re: IMAPEXT Chartering Message-ID: <1509047217.950696819@ephesus.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.0.0b9 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, February 15, 2000 7:20 PM -0800 Mark Crispin wrote: > I agree. But I dread making a last call. The silence in the past several > months (years, actually) of various imapv drafts frightens me. I just > know that there won't be any feedback until there's a last call, then > suddenly will come vehement demands for massive rewrites or new text. > > OK, I am sending out draft 09 today. The only changes from 08 are > pointing out how % works with LSUB and clarify the "don't use STATUS on > the selected mailbox rule." > > PS: I didn't call it "imapv", the I-D editor did for reasons which are > still unclear to me...ours is not to question why, ours is but to do or... Well given the negative response on this list to the idea of revising the base-spec as a whole I don't see how there could be major objections to "imapv" and resulting rewrites of "imapv". So personally I think you should last call it. -- Cyrus Received: by ns.secondary.com (8.9.3/8.9.3) id TAA13215 for ietf-imapext-bks; Tue, 15 Feb 2000 19:35:13 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (strider@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13210 for ; Tue, 15 Feb 2000 19:35:12 -0800 (PST) Date: Tue, 15 Feb 2000 19:20:54 -0800 (PST) From: Mark Crispin Subject: Re: IMAPEXT Chartering To: Cyrus Daboo cc: IMAP Extensions In-Reply-To: <1436388333.950624160@ephesus.cyrusoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 15 Feb 2000 14:16:00 -0500, Cyrus Daboo wrote: > Agreed. But should we not pursue making the current 'imapv' draft an RFC? I agree. But I dread making a last call. The silence in the past several months (years, actually) of various imapv drafts frightens me. I just know that there won't be any feedback until there's a last call, then suddenly will come vehement demands for massive rewrites or new text. OK, I am sending out draft 09 today. The only changes from 08 are pointing out how % works with LSUB and clarify the "don't use STATUS on the selected mailbox rule." PS: I didn't call it "imapv", the I-D editor did for reasons which are still unclear to me...ours is not to question why, ours is but to do or... Received: by ns.secondary.com (8.9.3/8.9.3) id LAA00406 for ietf-imapext-bks; Tue, 15 Feb 2000 11:12:57 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00399 for ; Tue, 15 Feb 2000 11:12:56 -0800 (PST) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA09217 for ; Tue, 15 Feb 2000 14:15:35 -0500 (EST) Date: Tue, 15 Feb 2000 14:16:00 -0500 From: Cyrus Daboo To: IMAP Extensions Subject: Re: IMAPEXT Chartering Message-ID: <1436388333.950624160@ephesus.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.0.0b9 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, February 15, 2000 10:48 AM -0800 Mark Crispin wrote: > For what it's worth, I agree with all of the comments which oppose a > refresh of the base IMAP spec, for the reasons given. > > If people have a problem with reading ABNF and want to implement from > examples, then the obvious solution is to flush all the examples from the > base spec. ;-) Agreed. But should we not pursue making the current 'imapv' draft an RFC? There are quite a few corrections (minor) and some additions (also minor) making a total of 61 changes in the -08 draft that would be nice to see as a 'proper' RFC, updating 2060. I've come across some people that are reluctant to make these changes in their products because they are not in a 'proper' RFC. -- Cyrus Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA29697 for ietf-imapext-bks; Tue, 15 Feb 2000 10:49:35 -0800 (PST) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29693 for ; Tue, 15 Feb 2000 10:49:34 -0800 (PST) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout1.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id KAA12842; Tue, 15 Feb 2000 10:52:59 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (s564146@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW99.09/8.9.3+UW00.01) with ESMTP id KAA17948; Tue, 15 Feb 2000 10:52:59 -0800 Date: Tue, 15 Feb 2000 10:48:14 -0800 (PST) From: Mark Crispin Subject: Re: IMAPEXT Chartering To: Steve Hole cc: Pete Resnick , IMAP Extensions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For what it's worth, I agree with all of the comments which oppose a refresh of the base IMAP spec, for the reasons given. If people have a problem with reading ABNF and want to implement from examples, then the obvious solution is to flush all the examples from the base spec. ;-) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA26390 for ietf-imapext-bks; Tue, 15 Feb 2000 08:04:37 -0800 (PST) Received: from demo.esys.ca ([207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26385 for ; Tue, 15 Feb 2000 08:04:36 -0800 (PST) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id JAA26116; Tue, 15 Feb 2000 09:07:49 -0700 From: Steve Hole Date: Mon, 14 Feb 2000 22:10:28 -0700 To: Pete Resnick Subject: Re: IMAPEXT Chartering Cc: IMAP Extensions In-Reply-To: References: Message-ID: X-Mailer: Execmail for Linux 5.3 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA26387 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 6 Feb 2000 14:05:18 -0600 Pete Resnick wrote: > Return-Path: > Date: Sun, 06 Feb 2000 20:41:33 +0100 > From: Patrik Fältström > To: Pete Resnick > cc: Ned Freed , Keith Moore > Subject: Re: IMAPEXT progress? > > --On 2000-02-03 16.41 -0600, Pete Resnick wrote: > > > Anything going on with regard to the chartering of IMAPEXT? > > After discussing this for some time among some IESG and IAB members, we > have agreed that this is a go _IF_ you add to the charter a refreshment of > the base IMAP spec. > > Yes, we know you don't like it, and we don't normally do it this way. I.e. > a wg working with extensions should not also do the base spec. It is also > the case that we normally (as you know personally ;-) want people to first > do the boring stuff, and then get to the dessert. > > But, in the case of IMAP, we feel that many people work really hard, and > the same people would work on the extensions _and_ the base spec. Because > of this, we don't see any need for two working groups. I cannot believe that this is a good idea. (1) it implies that there is a lot of work to do on the base specification, which is not true, and (2) it will delay the extension work substantially. I suspect that I know where much of this request originated. The bottom line is that, with the exception of the NAMESPACE extension, interoperability is pretty decent these days. Some people still have a problem reading ABNF and want to implement from the examples, but that is not a problem for IMAP in particular. Frankly, we seem to have a lot more problem with MIME and S/MIME interoperability than we do with IMAP. There are some things that can be done to improve the capability and useability of IMAP. Most of these can be addressed as extensions. I really see no reason to take on this work. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA20531 for ietf-imapext-bks; Tue, 15 Feb 2000 03:59:54 -0800 (PST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA20527 for ; Tue, 15 Feb 2000 03:59:52 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id MAA15212; Tue, 15 Feb 2000 12:03:15 GMT Message-ID: Date: Tue, 15 Feb 2000 12:00:31 +0000 To: ietf-imapext@imc.org, imap@u.washington.edu From: Paul Overell Subject: Re: I-D ACTION:draft-crispin-imap-multiappend-00.txt (fwd) References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.00 alpha 3M Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The formal syntax used in draft-crispin-imap-multiappend-00.txt seems to have fallen between two stools, it follows neither RFC2234 nor RFC2060. Assuming that the syntax is supposed to conform to RFC2234 (as does draft-crispin-imapv-08.txt) then replace SPACE with SP and _ with - throughout > >Modification to IMAP4rev1 Base Protocol Formal Syntax > > append = "APPEND" SPACE mailbox 1*append_message > > append-message = [SPACE flag_list] [SPACE date_time] SPACE literal > > >MULTIAPPEND Interaction with UIDPLUS Extension > > Servers which support both MULTIAPPEND and [UIDPLUS] will have the > "resp-code-apnd" rule modified as follows: > > resp-code-apnd = "APPENDUID" SPACE nz_number 1*(SPACE uniqueid) > Becomes Modification to IMAP4rev1 Base Protocol Formal Syntax append = "APPEND" SP mailbox 1*append-message append-message = [SP flag-list] [SP date-time] SP literal MULTIAPPEND Interaction with UIDPLUS Extension Servers which support both MULTIAPPEND and [UIDPLUS] will have the "resp-code-apnd" rule modified as follows: resp-code-apnd = "APPENDUID" SP nz-number 1*(SP uniqueid) On the other hand if it is not intended to conform to RFC2234 but to follow RFC2060 then replace = with ::= and - with _ throughout. Regards -- Paul Overell T U R N P I K E Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA09260 for ietf-imapext-bks; Mon, 14 Feb 2000 08:18:44 -0800 (PST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09256 for ; Mon, 14 Feb 2000 08:18:43 -0800 (PST) Received: from microdol1.cac.washington.edu (microdol1.cac.washington.edu [140.142.112.196]) by mxout2.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id IAA01424; Mon, 14 Feb 2000 08:21:55 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (localhost [127.0.0.1]) (authenticated as mrc@u.washington.edu with GSSAPI) by microdol1.cac.washington.edu (8.10.0.Beta12/8.10.0.Beta12/UW99.11) with ESMTP id e1EGLtG12379; Mon, 14 Feb 2000 08:21:55 -0800 Date: Mon, 14 Feb 2000 08:21:54 -0800 (PST) From: Mark Crispin To: IMAP Extensions WG cc: IMAP Interest List Subject: I-D ACTION:draft-crispin-imap-multiappend-00.txt (fwd) Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: As promised, here is the specification for MULTIAPPEND. Preliminary testing of the c-client implementation shows that it is a major winner, and much less kludgy than streaming appends! -- Mark -- * RCW 19.190 notice: This email address is located in Washington State. * * Unsolicited commercial email may be billed $500 per message. * Science does not emerge from voting, party politics, or public debate. ---------- Forwarded message ---------- Date: Mon, 14 Feb 2000 06:44:26 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-crispin-imap-multiappend-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION Author(s) : M. Crispin Filename : draft-crispin-imap-multiappend-00.txt Pages : 5 Date : 11-Feb-00 This document describes the multiappending extension to the [IMAP] protocol. This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of 'MULTIAPPEND'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imap-multiappend-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-crispin-imap-multiappend-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-crispin-imap-multiappend-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-crispin-imap-multiappend-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA17788 for ietf-imapext-bks; Tue, 8 Feb 2000 11:42:27 -0800 (PST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA17782 for ; Tue, 8 Feb 2000 11:42:24 -0800 (PST) Received: from microdol1.cac.washington.edu (microdol1.cac.washington.edu [140.142.112.196]) by mxout2.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id LAA23694 for ; Tue, 8 Feb 2000 11:45:15 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (localhost [127.0.0.1]) (authenticated as mrc@u.washington.edu with GSSAPI) by microdol1.cac.washington.edu (8.10.0.Beta12/8.10.0.Beta12/UW99.11) with ESMTP id e18JjEG23545 for ; Tue, 8 Feb 2000 11:45:15 -0800 Date: Tue, 8 Feb 2000 11:45:13 -0800 (PST) From: Mark Crispin To: IMAP Extensions WG Subject: 2 forwarded messages... Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="16819560-1488665461-950039113=:29569" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --16819560-1488665461-950039113=:29569 Content-Type: TEXT/PLAIN; charset=US-ASCII I've re-posted the SORT and THREAD drafts, since the old ones are expiring. There are no changes in either other than the obvious editorial ones. Since it's been 6 months, I would like to call a "last call" for the SORT draft to be submitted to the IESG for publication as an Informational or Experimental RFC. Once that has been done, I will reconstitute the SORT draft as a working document of IMAPEXT (called SORT+ or SORTrev1 or whatever) and then we can talk about the addressions to go into it. I would like group input on what to do about THREAD. I suggest that we should just go and publish THREAD as a Proposed Standard, on the grounds that THREAD can be extended arbitrarily (ala SASL) and, as in SASL, it makes no sense to block advancement of the framework just because some of the algorithms aren't fully specified yet. In any case, I agree that we have add the missing algorithms (for In-Reply-To and References threading) prior to it getting beyond Proposed, either in the THREAD document or as auxillary documents. Bottom line on my recommendations: 1) Push SORT to informational/experimental RFC now. 2) Start standards-track SORTxxx draft, with SORT RFC as its basis. 3) Push THREAD to proposed standard RFC now, even though THREAD=ORDEREDSUBJECT is the only algorithm defined as yet. 4) Start THREAD=INREPLYTO and THREAD=REFERENCES draft. The documents in (2) and (4) would be IMAPEXT WG documents. --16819560-1488665461-950039113=:29569 Content-Type: MULTIPART/Digest; BOUNDARY="16819560-719432153-950039113=:29569" Content-ID: Content-Description: Digest of 2 messages This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --16819560-719432153-950039113=:29569 Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII Content-ID: Content-Description: I-D ACTION:draft-crispin-imapext-sort-01.txt (fwd) Return-Path: Received: via tmail-4.1(11) (invoked by user mailnull) for mrc; Tue, 8 Feb 2000 04:46:39 -0800 (PST) Return-Path: Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by tupperware.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id EAA04211; Tue, 8 Feb 2000 04:46:36 -0800 (PST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mx1.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id EAA04977; Tue, 8 Feb 2000 04:46:34 -0800 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA25191 for ietf-123-outbound.07@ietf.org; Tue, 8 Feb 2000 07:45:04 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA24265 for ; Tue, 8 Feb 2000 06:31:30 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13553 for ; Tue, 8 Feb 2000 06:31:31 -0500 (EST) Message-Id: <200002081131.GAA13553@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-crispin-imapext-sort-01.txt Date: Tue, 08 Feb 2000 06:31:30 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION Author(s) : M. Crispin Filename : draft-crispin-imapext-sort-01.txt Pages : 9 Date : 07-Feb-00 This document describes an experimental server-based sorting extension to the IMAP4rev1 protocol, as implemented by the University of Washington's IMAP toolkit. This extension provides substantial performance improvements for IMAP clients which offer sorted views. A server which supports this extension indicates this with a capability name of 'SORT'. Client implementations SHOULD accept any capability name which begins with 'SORT' as indicating support for the extension described in this document. This provides for future upwards-compatible extensions. At the time of this document was written, the IMAP Extensions Working Group (IETF-IMAPEXT) was considering upwards-compatible additions to the SORT extension described in this document, tenatively called the SORT2 extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imapext-sort-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-crispin-imapext-sort-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-crispin-imapext-sort-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000207125523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-crispin-imapext-sort-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-crispin-imapext-sort-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207125523.I-D@ietf.org> --OtherAccess-- --NextPart-- --16819560-719432153-950039113=:29569 Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII Content-ID: Content-Description: I-D ACTION:draft-crispin-imapext-thread-01.txt (fwd) Return-Path: Received: via tmail-4.1(11) (invoked by user mailnull) for mrc; Tue, 8 Feb 2000 06:36:26 -0800 (PST) Return-Path: Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by tupperware.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id GAA29489; Tue, 8 Feb 2000 06:36:23 -0800 (PST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mx1.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id GAA06754; Tue, 8 Feb 2000 06:36:21 -0800 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA27129 for ietf-123-outbound.07@ietf.org; Tue, 8 Feb 2000 09:35:02 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA24342 for ; Tue, 8 Feb 2000 06:32:51 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13741 for ; Tue, 8 Feb 2000 06:32:52 -0500 (EST) Message-Id: <200002081132.GAA13741@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-crispin-imapext-thread-01.txt Date: Tue, 08 Feb 2000 06:32:52 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION Author(s) : M. Crispin Filename : draft-crispin-imapext-thread-01.txt Pages : 7 Date : 07-Feb-00 This document describes the server-based threading extension to the IMAP4rev1 protocol. This extension provides substantial performance improvements for IMAP clients which offer threaded views. A server which supports this extension indicates this with more or more capability names consisting of 'THREAD-' followed by a supported threading algorithm name as described in this document. This provides for future upwards-compatible extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imapext-thread-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-crispin-imapext-thread-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-crispin-imapext-thread-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000207142509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-crispin-imapext-thread-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-crispin-imapext-thread-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207142509.I-D@ietf.org> --OtherAccess-- --NextPart-- --16819560-719432153-950039113=:29569-- --16819560-1488665461-950039113=:29569-- Received: by ns.secondary.com (8.9.3/8.9.3) id RAA10810 for ietf-imapext-bks; Mon, 7 Feb 2000 17:07:09 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (tanner@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA10806 for ; Mon, 7 Feb 2000 17:07:07 -0800 (PST) Date: Mon, 7 Feb 2000 16:50:36 -0800 (PST) From: Mark Crispin Subject: Re: IMAPEXT Chartering To: Mike Gahrns cc: Lyndon Nerenberg , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , IMAP Extensions In-Reply-To: <000b01bf71cb$3cfe6cf0$9bff3b9d@redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree completely with Mike Gahrns' comments. It is not clear to me that WG action is required on the base spec. We may want to draw up a list of which points from Barry's document should go in the base spec, but those should be held to clarifications (or possibly prohibitions). The only extension which *may* belong in the base spec is STARTTLS. None of the other extensions are of such vital importance that a server must have it or be considered broken. At least one of the extensions (NAMESPACE) has been known to create problems with certain (we all know which) clients. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA10370 for ietf-imapext-bks; Mon, 7 Feb 2000 16:39:29 -0800 (PST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA10365 for ; Mon, 7 Feb 2000 16:39:27 -0800 (PST) Received: from 172.30.236.230 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 07 Feb 2000 16:26:10 -0800 (Pacific Standard Time) Received: from MIKEGA9 ([157.59.255.155]) by popdog.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 12F8AQ7W; Mon, 7 Feb 2000 16:26:15 -0800 Message-ID: <000b01bf71cb$3cfe6cf0$9bff3b9d@redmond.corp.microsoft.com> From: "Mike Gahrns" To: "Lyndon Nerenberg" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: "IMAP Extensions" References: <200002071511.e17FBCj98114@zappa.esys.ca> Subject: Re: IMAPEXT Chartering Date: Mon, 7 Feb 2000 16:27:10 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01BF7188.2EC42280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01BF7188.2EC42280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: IMAPEXT CharteringI agree with Lyndon and others to do the review of = the base spec after any extensions are done. (Assuming that a review of = the base spec needs to be in the IMAPEXT charter, which I don't think is = the case). I also wonder if the perceived need of doing a review of the base spec = is based upon the state of IMAP interoperability a fews ago. My personal opinion is that IMAP interoperability is now good. = Admittedly there are some implementations that may not do things in the = most efficient manner, and may not take full advantage of the protocol, = but I think we are at a point now where interop between various vendor's = IMAP client's and servers is decent. I think the results from the = various IMC mail connects bear this out. The group definitely did iron = out some kink in some implementations as a result of these events, and = the group also worked quite hard on the "implementor's guide" that barry = leiba put together. As a result, IMAP interop today is probably better = than some people may perceive it to be. ------=_NextPart_000_0008_01BF7188.2EC42280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: IMAPEXT Chartering
I agree with Lyndon and others to do = the review of=20 the base spec after any extensions are done.  (Assuming that a = review of=20 the base spec needs to be in the IMAPEXT charter, which I don't think is = the=20 case).
 
I also wonder if the perceived need of = doing a=20 review of the base spec is based upon the state of IMAP interoperability = a fews=20 ago.
 
My personal opinion is that IMAP=20 interoperability is now good.  Admittedly there are some=20 implementations that may not do things in the most efficient manner, and = may not=20 take full advantage of the protocol, but I think we are at a point now = where=20 interop between various vendor's IMAP client's and servers = is decent. =20 I think the results from the various IMC mail connects bear this = out. =20 The group definitely did iron out some kink in some = implementations as a=20 result of these events, and the group also worked quite hard on the=20 "implementor's guide" that barry leiba put together.  As a result, = IMAP=20 interop today is probably better than some people may perceive it to=20 be.
------=_NextPart_000_0008_01BF7188.2EC42280-- Received: by ns.secondary.com (8.9.3/8.9.3) id HAA27455 for ietf-imapext-bks; Mon, 7 Feb 2000 07:09:01 -0800 (PST) Received: from zappa.esys.ca (zappa.esys.ca [198.161.92.28]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27446 for ; Mon, 7 Feb 2000 07:08:59 -0800 (PST) Received: (from lyndon@localhost) by zappa.esys.ca (8.10.0.Beta8/8.10.0.Beta8) id e17FBCj98114; Mon, 7 Feb 2000 08:11:12 -0700 (MST) Message-Id: <200002071511.e17FBCj98114@zappa.esys.ca> From: Lyndon Nerenberg To: Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?= cc: IMAP Extensions Subject: Re: IMAPEXT Chartering In-reply-to: Your message of "Mon, 07 Feb 2000 15:09:18 +0100." <4121501.3158924958@[192.168.124.51]> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 07 Feb 2000 08:11:11 -0700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA27449 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Patrik" == Patrik Fältström writes: Patrik> How, when, where would you suggest a review of the base Patrik> spec is done? Do the base review after the extensions work is done. Patrik> If that is done after IMAPEXT work is done, do you see a Patrik> problem with delaying that review? No. Patrik> If that is done in parallell, do you think other people Patrik> will work with base spec than IMAPEXT issues? I think everyone working on extensions will also work on the base review. The outcome of the extensions work will affect things when we review the base, so the extensions group really has to wrap up first. Also, if we do both at once, our time will become too fragmented to do a good job on either one. Also, if a review of 2060 *is* necessary, I think the IMAP development community is capable of deciding the time and place for that to happen. Having third-parties dictate the need for a base review is out of line (even if some of them are area directors). --lyndon Received: by ns.secondary.com (8.9.3/8.9.3) id GAA26341 for ietf-imapext-bks; Mon, 7 Feb 2000 06:09:22 -0800 (PST) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26336 for ; Mon, 7 Feb 2000 06:09:20 -0800 (PST) Received: from 192.168.124.51 (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id PAA14353; Mon, 7 Feb 2000 15:09:19 +0100 (MET) Date: Mon, 07 Feb 2000 15:09:18 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lyndon Nerenberg , IMAP Extensions Subject: Re: IMAPEXT Chartering Message-ID: <4121501.3158924958@[192.168.124.51]> In-Reply-To: <200002071359.e17Dxr572809@zappa.esys.ca> X-Mailer: Mulberry/2.0.0b8 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2000-02-07 06.59 -0700, Lyndon Nerenberg wrote: > I am completely opposed to incorporating a base spec review into > the working group charter. We need to get the things identified > in the original charter dealt with -- this year. Adding a base spec > review by fiat like this is completely unacceptable. How, when, where would you suggest a review of the base spec is done? If that is done after IMAPEXT work is done, do you see a problem with delaying that review? If that is done in parallell, do you think other people will work with base spec than IMAPEXT issues? paf Received: by ns.secondary.com (8.9.3/8.9.3) id FAA26155 for ietf-imapext-bks; Mon, 7 Feb 2000 05:57:47 -0800 (PST) Received: from zappa.esys.ca (zappa.esys.ca [198.161.92.28]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA26151 for ; Mon, 7 Feb 2000 05:57:46 -0800 (PST) Received: (from lyndon@localhost) by zappa.esys.ca (8.10.0.Beta8/8.10.0.Beta8) id e17Dxr572809; Mon, 7 Feb 2000 06:59:53 -0700 (MST) Message-Id: <200002071359.e17Dxr572809@zappa.esys.ca> From: Lyndon Nerenberg to: IMAP Extensions Subject: Re: IMAPEXT Chartering In-reply-to: Your message of "Sun, 06 Feb 2000 14:05:18 CST." Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Mon, 07 Feb 2000 06:59:52 -0700 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am completely opposed to incorporating a base spec review into the working group charter. We need to get the things identified in the original charter dealt with -- this year. Adding a base spec review by fiat like this is completely unacceptable. --lyndon Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00916 for ietf-imapext-bks; Sun, 6 Feb 2000 12:55:19 -0800 (PST) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00911; Sun, 6 Feb 2000 12:55:17 -0800 (PST) Received: from 192.168.111.25 (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id VAA22613; Sun, 6 Feb 2000 21:55:18 +0100 (MET) Date: Sun, 06 Feb 2000 21:55:12 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Paul Hoffman / IMC" , IMAP Extensions Subject: Re: IMAPEXT Chartering Message-ID: <2248904.3158862912@[192.168.111.25]> In-Reply-To: <4.2.1.20000206121306.00a5d100@mail.imc.org> X-Mailer: Mulberry/2.0.0b8 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2000-02-06 12.16 -0800, "Paul Hoffman / IMC" wrote: > This seems like a straightforward layer 8 question. If the IESG wants it > that way, let's do it that way. If we stumble and scrape our knees on the > way, we can blame them. :-) Writing documents about "existing" protocols like the IMAP base protocol will always be painful. The point here is though that IESG belive (tell us if we are wrong): - It is about time it is done - People that have the knowledge and can do it, will be in this wg anyways ...and yes, I am the one which have to buy band-aid... Whether it is an update of the old one (which Pete said he had talked with Keith about) or a new document, that doesn't matter for me. You know better than me what gives the most bang for the buck. It is not the case that IESG _tell_ you to do it (at this point in time ;-). We just belive it would be the cheapest way of going forward. paf Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00449 for ietf-imapext-bks; Sun, 6 Feb 2000 12:13:19 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00445 for ; Sun, 6 Feb 2000 12:13:18 -0800 (PST) Message-Id: <4.2.1.20000206121306.00a5d100@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Sun, 06 Feb 2000 12:16:09 -0800 To: IMAP Extensions From: Paul Hoffman / IMC Subject: Re: IMAPEXT Chartering In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This seems like a straightforward layer 8 question. If the IESG wants it that way, let's do it that way. If we stumble and scrape our knees on the way, we can blame them. :-) --Paul Hoffman, Director --Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00316 for ietf-imapext-bks; Sun, 6 Feb 2000 12:02:37 -0800 (PST) Received: from episteme-software.com (resnick1.qualcomm.com [63.250.90.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00312 for ; Sun, 6 Feb 2000 12:02:35 -0800 (PST) Received: from resnick2.qualcomm.com (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0b6); Sun, 6 Feb 2000 14:05:41 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 4.3a?] Date: Sun, 6 Feb 2000 14:05:18 -0600 To: IMAP Extensions From: Pete Resnick Subject: IMAPEXT Chartering Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I forward the following message to the working group (bcc'ing the Keith, Patrik, and Ned) unedited. My only comment is that Keith originally brought to me privately the suggestion that we "add another milestone to the charter to write an informational rfc" on "interoperability problems resulting from ambiguities in the specs - and then to get consensus on an approach to solving those problems, before working on actual extensions". I objected to Keith (again, privately) on the grounds that we wanted to limit the scope of this WG to extensions only. Below is Patrik's message. I will make no further comments to the ADs on this topic until I hear from the list on this. Please make comments to the list. (Keith, Patrik, and Ned: Please see ietf-imapext@imc.org if you want to read the comments for yourselves.) --- begin forwarded text Return-Path: Date: Sun, 06 Feb 2000 20:41:33 +0100 From: Patrik Fältström To: Pete Resnick cc: Ned Freed , Keith Moore Subject: Re: IMAPEXT progress? --On 2000-02-03 16.41 -0600, Pete Resnick wrote: > Anything going on with regard to the chartering of IMAPEXT? After discussing this for some time among some IESG and IAB members, we have agreed that this is a go _IF_ you add to the charter a refreshment of the base IMAP spec. Yes, we know you don't like it, and we don't normally do it this way. I.e. a wg working with extensions should not also do the base spec. It is also the case that we normally (as you know personally ;-) want people to first do the boring stuff, and then get to the dessert. But, in the case of IMAP, we feel that many people work really hard, and the same people would work on the extensions _and_ the base spec. Because of this, we don't see any need for two working groups. Let us know what you feel about it. Regards, Patrik --- end forwarded text -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA29115 for ietf-imapext-bks; Fri, 18 Feb 2000 21:51:23 -0800 (PST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA29109 for ; Fri, 18 Feb 2000 21:51:21 -0800 (PST) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id VAA11360; Fri, 18 Feb 2000 21:55:05 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (smith@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id VAA00938; Fri, 18 Feb 2000 21:55:05 -0800 Date: Fri, 18 Feb 2000 20:59:29 -0800 (PST) From: Mark Crispin Subject: Re: LAST CALL: I-D ACTION:draft-crispin-imapv-09.txt (fwd) To: Tony Hansen cc: IMAP Interest List , IMAP Extensions WG In-Reply-To: <38AE20C9.4D9ED73C@att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 18 Feb 2000 23:49:13 -0500, Tony Hansen wrote: > Should it be named "Version 4rev2"? 2060 didn't have to be named 4rev1, > but was. Since we've started down the path of using "revX", shouldn't it > be continued? There were incompatible changes between RFC 1730 and RFC 2060. Specifically, poorly-designed RFC 1730 features relating to partial fetching were deleted from the IMAP specification, and much better features added in RFC 2060. A vendor insisted that it had to be possible to distinguish between RFC 1730 and RFC 2060 servers. It's a long story, but my arm was severely twisted to create "IMAP4rev1" (what an ugly name!). No, it was not the Evil Empire. Of course, nobody actually depended upon the broken features of RFC 1730 (if you tried to implement them, you'd find out why...) and everybody thinks that RFC 2060 is the one true IMAP (as they should). But we're apparently stuck with that "rev1" suffix forever. This is not the case with the new draft. The vast majority of the draft consists of clarifications of what is in RFC 2060. There's a small handful of new status codes. Nevertheless, there's no reason for a strict RFC 2060 implementation to have any problem with an implementation that supports the new draft or vice versa. Received: by ns.secondary.com (8.9.3/8.9.3) id UAA26579 for ietf-imapext-bks; Fri, 18 Feb 2000 20:48:07 -0800 (PST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA26574 for ; Fri, 18 Feb 2000 20:48:04 -0800 (PST) Received: from dns.maillennium.att.com ([135.25.114.99]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id XAA02520 for ; Fri, 18 Feb 2000 23:51:25 -0500 (EST) Received: from att.com ([135.197.86.38]) by maillennium.att.com (labmail) with SMTP id <2000021904490209925300fte>; Sat, 19 Feb 2000 04:49:03 +0000 Message-ID: <38AE20C9.4D9ED73C@att.com> Date: Fri, 18 Feb 2000 23:49:13 -0500 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Interest List , IMAP Extensions WG Subject: Re: LAST CALL: I-D ACTION:draft-crispin-imapv-09.txt (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Should it be named "Version 4rev2"? 2060 didn't have to be named 4rev1, but was. Since we've started down the path of using "revX", shouldn't it be continued? Tony Hansen tony@att.com Mark Crispin wrote: > > I would like to make a last call on the IMAPV document, which is > essentially a bugfix update to RFC 2060. Please read and review it, > since I would like to submit it as an RFC as the new standards-track > bas IMAP specification. > > ---------- Forwarded message ---------- > Subject: I-D ACTION:draft-crispin-imapv-09.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 > Author(s) : M. Crispin > Filename : draft-crispin-imapv-09.txt Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA14352 for ietf-imapext-bks; Fri, 18 Feb 2000 18:29:53 -0800 (PST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA14348 for ; Fri, 18 Feb 2000 18:29:51 -0800 (PST) Received: from microdol1.cac.washington.edu (microdol1.cac.washington.edu [140.142.112.196]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id SAA05513; Fri, 18 Feb 2000 18:33:34 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (localhost [127.0.0.1]) (authenticated as mrc@u.washington.edu with GSSAPI) by microdol1.cac.washington.edu (8.10.0.Beta12/8.10.0.Beta12/UW99.11) with ESMTP id e1J2XXG06207; Fri, 18 Feb 2000 18:33:33 -0800 Date: Fri, 18 Feb 2000 18:33:32 -0800 (PST) From: Mark Crispin To: IMAP Interest List , IMAP Extensions WG Subject: LAST CALL: I-D ACTION:draft-crispin-imapv-09.txt (fwd) Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: I would like to make a last call on the IMAPV document, which is essentially a bugfix update to RFC 2060. Please read and review it, since I would like to submit it as an RFC as the new standards-track bas IMAP specification. ---------- Forwarded message ---------- Date: Thu, 17 Feb 2000 06:27:25 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-crispin-imapv-09.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 Author(s) : M. Crispin Filename : draft-crispin-imapv-09.txt Pages : 93 Date : 16-Feb-00 The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]). IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; [RFC-822] and [MIME-IMB] parsing; searching; and selective fetching of message attributes, texts, and numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in [ACAP]. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP]. IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and unpublished IMAP2bis protocols. In the course of the evolution of IMAP4rev1, some aspects in the earlier protocol have become obsolete. Obsolete commands, responses, and data formats which an IMAP4rev1 implementation can encounter when used with an earlier implementation are described in [IMAP-OBSOLETE]. Other compatibility issues with IMAP2bis, the most common variant of the earlier protocol, are discussed in [IMAP-COMPAT]. A full discussion of compatibility issues with rare (and presumed extinct) variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is primarily of historical interest. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imapv-09.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-crispin-imapv-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-crispin-imapv-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-crispin-imapv-09.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id MAA11814 for ietf-imapext-bks; Wed, 16 Feb 2000 12:29:46 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (bcn@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11808 for ; Wed, 16 Feb 2000 12:29:45 -0800 (PST) Date: Wed, 16 Feb 2000 12:23:11 -0800 (PST) From: Mark Crispin Subject: Re: IMAPEXT Chartering To: Pete Resnick cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , IMAP Extensions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For what it's worth, I had not planned to go to Adelaide. I made multiple inquiries to see if anything IMAP-relevant would go on there, with no answer. Even if I make arrangements to do, I can not get to Adelaide until Tuesday at the swiftest due to other commitments. I don't think that there is a controversy. I haven't heard of anybody in IMAP or IMAPEXT who wants to charter IMAPEXT with base spec work on its agenda. IESG should be told that the unanimous opinion of the IMAP community is a rejection of this notion. On Wed, 16 Feb 2000 11:22:18 -0600, Pete Resnick wrote: > Unless this round of discussion on the list has convinced the people > in question, I think there has been enough indication of controversy > that a WG/BOF meeting be scheduled at Adelaide at which time we > should work this out. Members of the IAB/IESG who think the base spec > work item should be added to the charter ought to be present. Received: by ns.secondary.com (8.9.3/8.9.3) id JAA08055 for ietf-imapext-bks; Wed, 16 Feb 2000 09:19:09 -0800 (PST) Received: from episteme-software.com (resnick1.qualcomm.com [63.250.90.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08051 for ; Wed, 16 Feb 2000 09:19:05 -0800 (PST) Received: from resnick2.qualcomm.com (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0b7); Wed, 16 Feb 2000 11:22:19 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <4121501.3158924958@[192.168.124.51]> References: <4121501.3158924958@[192.168.124.51]> X-Mailer: Eudora [Macintosh version 4.3a?] Date: Wed, 16 Feb 2000 11:22:18 -0600 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Pete Resnick Subject: Re: IMAPEXT Chartering Cc: IMAP Extensions Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I promised not to make a comment on this topic, but it seems that most folks who are going to chime in have done so. So, first with my chairman hat off: On 2/7/00 at 3:09 PM +0100, Patrik Fältström wrote: >How, when, where would you suggest a review of the base spec is done? The base spec is being worked on right now and may be about to go to last call. It can get review during this time, and if there are folks who think that progressing it should be held up until an informational document is produced, they can hold up this rev of the base spec. If a working group is required to get that job done, one can be formed. This can be done independently and in parallel with IMAPEXT. >If that is done in parallell, do you think other people will work >with base spec than IMAPEXT issues? There will clearly be a huge intersection of people. That's irrelevant. Combining the two activities almost guarantees leakage between the two topics. I can hear it now: "Oh, that problem with the base spec can be solved with an extension; let's just add that to our charter." Or even better, "That extension will work if we make one little change to the base spec; let's do that during the base spec review." This has disaster written all over it. Keeping the activities separate forces the extensions to be clean and independent of base spec changes and forces base spec cleanups (if needed) to not be kludges. Now, with my chairman hat on: Unless this round of discussion on the list has convinced the people in question, I think there has been enough indication of controversy that a WG/BOF meeting be scheduled at Adelaide at which time we should work this out. Members of the IAB/IESG who think the base spec work item should be added to the charter ought to be present. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA05284 for ietf-imapext-bks; Wed, 16 Feb 2000 07:23:43 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA05280 for ; Wed, 16 Feb 2000 07:23:42 -0800 (PST) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id KAA10891; Wed, 16 Feb 2000 10:26:33 -0500 (EST) Date: Wed, 16 Feb 2000 10:26:59 -0500 From: Cyrus Daboo To: Mark Crispin cc: IMAP Extensions Subject: Re: IMAPEXT Chartering Message-ID: <1509047217.950696819@ephesus.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.0.0b9 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, February 15, 2000 7:20 PM -0800 Mark Crispin wrote: > I agree. But I dread making a last call. The silence in the past several > months (years, actually) of various imapv drafts frightens me. I just > know that there won't be any feedback until there's a last call, then > suddenly will come vehement demands for massive rewrites or new text. > > OK, I am sending out draft 09 today. The only changes from 08 are > pointing out how % works with LSUB and clarify the "don't use STATUS on > the selected mailbox rule." > > PS: I didn't call it "imapv", the I-D editor did for reasons which are > still unclear to me...ours is not to question why, ours is but to do or... Well given the negative response on this list to the idea of revising the base-spec as a whole I don't see how there could be major objections to "imapv" and resulting rewrites of "imapv". So personally I think you should last call it. -- Cyrus Received: by ns.secondary.com (8.9.3/8.9.3) id TAA13215 for ietf-imapext-bks; Tue, 15 Feb 2000 19:35:13 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (strider@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13210 for ; Tue, 15 Feb 2000 19:35:12 -0800 (PST) Date: Tue, 15 Feb 2000 19:20:54 -0800 (PST) From: Mark Crispin Subject: Re: IMAPEXT Chartering To: Cyrus Daboo cc: IMAP Extensions In-Reply-To: <1436388333.950624160@ephesus.cyrusoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, 15 Feb 2000 14:16:00 -0500, Cyrus Daboo wrote: > Agreed. But should we not pursue making the current 'imapv' draft an RFC? I agree. But I dread making a last call. The silence in the past several months (years, actually) of various imapv drafts frightens me. I just know that there won't be any feedback until there's a last call, then suddenly will come vehement demands for massive rewrites or new text. OK, I am sending out draft 09 today. The only changes from 08 are pointing out how % works with LSUB and clarify the "don't use STATUS on the selected mailbox rule." PS: I didn't call it "imapv", the I-D editor did for reasons which are still unclear to me...ours is not to question why, ours is but to do or... Received: by ns.secondary.com (8.9.3/8.9.3) id LAA00406 for ietf-imapext-bks; Tue, 15 Feb 2000 11:12:57 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00399 for ; Tue, 15 Feb 2000 11:12:56 -0800 (PST) Received: from ephesus.cyrusoft.com (ephesus.cyrusoft.com [206.31.218.204]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA09217 for ; Tue, 15 Feb 2000 14:15:35 -0500 (EST) Date: Tue, 15 Feb 2000 14:16:00 -0500 From: Cyrus Daboo To: IMAP Extensions Subject: Re: IMAPEXT Chartering Message-ID: <1436388333.950624160@ephesus.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.0.0b9 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, February 15, 2000 10:48 AM -0800 Mark Crispin wrote: > For what it's worth, I agree with all of the comments which oppose a > refresh of the base IMAP spec, for the reasons given. > > If people have a problem with reading ABNF and want to implement from > examples, then the obvious solution is to flush all the examples from the > base spec. ;-) Agreed. But should we not pursue making the current 'imapv' draft an RFC? There are quite a few corrections (minor) and some additions (also minor) making a total of 61 changes in the -08 draft that would be nice to see as a 'proper' RFC, updating 2060. I've come across some people that are reluctant to make these changes in their products because they are not in a 'proper' RFC. -- Cyrus Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA29697 for ietf-imapext-bks; Tue, 15 Feb 2000 10:49:35 -0800 (PST) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29693 for ; Tue, 15 Feb 2000 10:49:34 -0800 (PST) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout1.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id KAA12842; Tue, 15 Feb 2000 10:52:59 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (s564146@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost2.u.washington.edu (8.9.3+UW99.09/8.9.3+UW00.01) with ESMTP id KAA17948; Tue, 15 Feb 2000 10:52:59 -0800 Date: Tue, 15 Feb 2000 10:48:14 -0800 (PST) From: Mark Crispin Subject: Re: IMAPEXT Chartering To: Steve Hole cc: Pete Resnick , IMAP Extensions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: For what it's worth, I agree with all of the comments which oppose a refresh of the base IMAP spec, for the reasons given. If people have a problem with reading ABNF and want to implement from examples, then the obvious solution is to flush all the examples from the base spec. ;-) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA26390 for ietf-imapext-bks; Tue, 15 Feb 2000 08:04:37 -0800 (PST) Received: from demo.esys.ca ([207.167.22.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26385 for ; Tue, 15 Feb 2000 08:04:36 -0800 (PST) Received: from kepler.esys.ca (kepler.esys.ca [198.161.92.108]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id JAA26116; Tue, 15 Feb 2000 09:07:49 -0700 From: Steve Hole Date: Mon, 14 Feb 2000 22:10:28 -0700 To: Pete Resnick Subject: Re: IMAPEXT Chartering Cc: IMAP Extensions In-Reply-To: References: Message-ID: X-Mailer: Execmail for Linux 5.3 b1 Build (1) -- Evaluation Copy MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA26387 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sun, 6 Feb 2000 14:05:18 -0600 Pete Resnick wrote: > Return-Path: > Date: Sun, 06 Feb 2000 20:41:33 +0100 > From: Patrik Fältström > To: Pete Resnick > cc: Ned Freed , Keith Moore > Subject: Re: IMAPEXT progress? > > --On 2000-02-03 16.41 -0600, Pete Resnick wrote: > > > Anything going on with regard to the chartering of IMAPEXT? > > After discussing this for some time among some IESG and IAB members, we > have agreed that this is a go _IF_ you add to the charter a refreshment of > the base IMAP spec. > > Yes, we know you don't like it, and we don't normally do it this way. I.e. > a wg working with extensions should not also do the base spec. It is also > the case that we normally (as you know personally ;-) want people to first > do the boring stuff, and then get to the dessert. > > But, in the case of IMAP, we feel that many people work really hard, and > the same people would work on the extensions _and_ the base spec. Because > of this, we don't see any need for two working groups. I cannot believe that this is a good idea. (1) it implies that there is a lot of work to do on the base specification, which is not true, and (2) it will delay the extension work substantially. I suspect that I know where much of this request originated. The bottom line is that, with the exception of the NAMESPACE extension, interoperability is pretty decent these days. Some people still have a problem reading ABNF and want to implement from the examples, but that is not a problem for IMAP in particular. Frankly, we seem to have a lot more problem with MIME and S/MIME interoperability than we do with IMAP. There are some things that can be done to improve the capability and useability of IMAP. Most of these can be addressed as extensions. I really see no reason to take on this work. Cheers. --- Steve Hole Messaging Direct Mailto:Steve.Hole@MessagingDirect.com Phone: 780-424-4922 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA20531 for ietf-imapext-bks; Tue, 15 Feb 2000 03:59:54 -0800 (PST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA20527 for ; Tue, 15 Feb 2000 03:59:52 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id MAA15212; Tue, 15 Feb 2000 12:03:15 GMT Message-ID: Date: Tue, 15 Feb 2000 12:00:31 +0000 To: ietf-imapext@imc.org, imap@u.washington.edu From: Paul Overell Subject: Re: I-D ACTION:draft-crispin-imap-multiappend-00.txt (fwd) References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.00 alpha 3M Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The formal syntax used in draft-crispin-imap-multiappend-00.txt seems to have fallen between two stools, it follows neither RFC2234 nor RFC2060. Assuming that the syntax is supposed to conform to RFC2234 (as does draft-crispin-imapv-08.txt) then replace SPACE with SP and _ with - throughout > >Modification to IMAP4rev1 Base Protocol Formal Syntax > > append = "APPEND" SPACE mailbox 1*append_message > > append-message = [SPACE flag_list] [SPACE date_time] SPACE literal > > >MULTIAPPEND Interaction with UIDPLUS Extension > > Servers which support both MULTIAPPEND and [UIDPLUS] will have the > "resp-code-apnd" rule modified as follows: > > resp-code-apnd = "APPENDUID" SPACE nz_number 1*(SPACE uniqueid) > Becomes Modification to IMAP4rev1 Base Protocol Formal Syntax append = "APPEND" SP mailbox 1*append-message append-message = [SP flag-list] [SP date-time] SP literal MULTIAPPEND Interaction with UIDPLUS Extension Servers which support both MULTIAPPEND and [UIDPLUS] will have the "resp-code-apnd" rule modified as follows: resp-code-apnd = "APPENDUID" SP nz-number 1*(SP uniqueid) On the other hand if it is not intended to conform to RFC2234 but to follow RFC2060 then replace = with ::= and - with _ throughout. Regards -- Paul Overell T U R N P I K E Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA09260 for ietf-imapext-bks; Mon, 14 Feb 2000 08:18:44 -0800 (PST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09256 for ; Mon, 14 Feb 2000 08:18:43 -0800 (PST) Received: from microdol1.cac.washington.edu (microdol1.cac.washington.edu [140.142.112.196]) by mxout2.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id IAA01424; Mon, 14 Feb 2000 08:21:55 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (localhost [127.0.0.1]) (authenticated as mrc@u.washington.edu with GSSAPI) by microdol1.cac.washington.edu (8.10.0.Beta12/8.10.0.Beta12/UW99.11) with ESMTP id e1EGLtG12379; Mon, 14 Feb 2000 08:21:55 -0800 Date: Mon, 14 Feb 2000 08:21:54 -0800 (PST) From: Mark Crispin To: IMAP Extensions WG cc: IMAP Interest List Subject: I-D ACTION:draft-crispin-imap-multiappend-00.txt (fwd) Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: As promised, here is the specification for MULTIAPPEND. Preliminary testing of the c-client implementation shows that it is a major winner, and much less kludgy than streaming appends! -- Mark -- * RCW 19.190 notice: This email address is located in Washington State. * * Unsolicited commercial email may be billed $500 per message. * Science does not emerge from voting, party politics, or public debate. ---------- Forwarded message ---------- Date: Mon, 14 Feb 2000 06:44:26 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-crispin-imap-multiappend-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION Author(s) : M. Crispin Filename : draft-crispin-imap-multiappend-00.txt Pages : 5 Date : 11-Feb-00 This document describes the multiappending extension to the [IMAP] protocol. This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of 'MULTIAPPEND'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imap-multiappend-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-crispin-imap-multiappend-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-crispin-imap-multiappend-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-crispin-imap-multiappend-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA17788 for ietf-imapext-bks; Tue, 8 Feb 2000 11:42:27 -0800 (PST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA17782 for ; Tue, 8 Feb 2000 11:42:24 -0800 (PST) Received: from microdol1.cac.washington.edu (microdol1.cac.washington.edu [140.142.112.196]) by mxout2.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id LAA23694 for ; Tue, 8 Feb 2000 11:45:15 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (localhost [127.0.0.1]) (authenticated as mrc@u.washington.edu with GSSAPI) by microdol1.cac.washington.edu (8.10.0.Beta12/8.10.0.Beta12/UW99.11) with ESMTP id e18JjEG23545 for ; Tue, 8 Feb 2000 11:45:15 -0800 Date: Tue, 8 Feb 2000 11:45:13 -0800 (PST) From: Mark Crispin To: IMAP Extensions WG Subject: 2 forwarded messages... Message-ID: Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="16819560-1488665461-950039113=:29569" Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --16819560-1488665461-950039113=:29569 Content-Type: TEXT/PLAIN; charset=US-ASCII I've re-posted the SORT and THREAD drafts, since the old ones are expiring. There are no changes in either other than the obvious editorial ones. Since it's been 6 months, I would like to call a "last call" for the SORT draft to be submitted to the IESG for publication as an Informational or Experimental RFC. Once that has been done, I will reconstitute the SORT draft as a working document of IMAPEXT (called SORT+ or SORTrev1 or whatever) and then we can talk about the addressions to go into it. I would like group input on what to do about THREAD. I suggest that we should just go and publish THREAD as a Proposed Standard, on the grounds that THREAD can be extended arbitrarily (ala SASL) and, as in SASL, it makes no sense to block advancement of the framework just because some of the algorithms aren't fully specified yet. In any case, I agree that we have add the missing algorithms (for In-Reply-To and References threading) prior to it getting beyond Proposed, either in the THREAD document or as auxillary documents. Bottom line on my recommendations: 1) Push SORT to informational/experimental RFC now. 2) Start standards-track SORTxxx draft, with SORT RFC as its basis. 3) Push THREAD to proposed standard RFC now, even though THREAD=ORDEREDSUBJECT is the only algorithm defined as yet. 4) Start THREAD=INREPLYTO and THREAD=REFERENCES draft. The documents in (2) and (4) would be IMAPEXT WG documents. --16819560-1488665461-950039113=:29569 Content-Type: MULTIPART/Digest; BOUNDARY="16819560-719432153-950039113=:29569" Content-ID: Content-Description: Digest of 2 messages This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --16819560-719432153-950039113=:29569 Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII Content-ID: Content-Description: I-D ACTION:draft-crispin-imapext-sort-01.txt (fwd) Return-Path: Received: via tmail-4.1(11) (invoked by user mailnull) for mrc; Tue, 8 Feb 2000 04:46:39 -0800 (PST) Return-Path: Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by tupperware.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id EAA04211; Tue, 8 Feb 2000 04:46:36 -0800 (PST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mx1.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id EAA04977; Tue, 8 Feb 2000 04:46:34 -0800 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA25191 for ietf-123-outbound.07@ietf.org; Tue, 8 Feb 2000 07:45:04 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA24265 for ; Tue, 8 Feb 2000 06:31:30 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13553 for ; Tue, 8 Feb 2000 06:31:31 -0500 (EST) Message-Id: <200002081131.GAA13553@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-crispin-imapext-sort-01.txt Date: Tue, 08 Feb 2000 06:31:30 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION Author(s) : M. Crispin Filename : draft-crispin-imapext-sort-01.txt Pages : 9 Date : 07-Feb-00 This document describes an experimental server-based sorting extension to the IMAP4rev1 protocol, as implemented by the University of Washington's IMAP toolkit. This extension provides substantial performance improvements for IMAP clients which offer sorted views. A server which supports this extension indicates this with a capability name of 'SORT'. Client implementations SHOULD accept any capability name which begins with 'SORT' as indicating support for the extension described in this document. This provides for future upwards-compatible extensions. At the time of this document was written, the IMAP Extensions Working Group (IETF-IMAPEXT) was considering upwards-compatible additions to the SORT extension described in this document, tenatively called the SORT2 extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imapext-sort-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-crispin-imapext-sort-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-crispin-imapext-sort-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000207125523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-crispin-imapext-sort-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-crispin-imapext-sort-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207125523.I-D@ietf.org> --OtherAccess-- --NextPart-- --16819560-719432153-950039113=:29569 Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII Content-ID: Content-Description: I-D ACTION:draft-crispin-imapext-thread-01.txt (fwd) Return-Path: Received: via tmail-4.1(11) (invoked by user mailnull) for mrc; Tue, 8 Feb 2000 06:36:26 -0800 (PST) Return-Path: Received: from mx1.cac.washington.edu (mx1.cac.washington.edu [140.142.32.1]) by tupperware.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id GAA29489; Tue, 8 Feb 2000 06:36:23 -0800 (PST) Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mx1.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id GAA06754; Tue, 8 Feb 2000 06:36:21 -0800 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA27129 for ietf-123-outbound.07@ietf.org; Tue, 8 Feb 2000 09:35:02 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA24342 for ; Tue, 8 Feb 2000 06:32:51 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13741 for ; Tue, 8 Feb 2000 06:32:52 -0500 (EST) Message-Id: <200002081132.GAA13741@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-crispin-imapext-thread-01.txt Date: Tue, 08 Feb 2000 06:32:52 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION Author(s) : M. Crispin Filename : draft-crispin-imapext-thread-01.txt Pages : 7 Date : 07-Feb-00 This document describes the server-based threading extension to the IMAP4rev1 protocol. This extension provides substantial performance improvements for IMAP clients which offer threaded views. A server which supports this extension indicates this with more or more capability names consisting of 'THREAD-' followed by a supported threading algorithm name as described in this document. This provides for future upwards-compatible extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imapext-thread-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-crispin-imapext-thread-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-crispin-imapext-thread-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000207142509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-crispin-imapext-thread-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-crispin-imapext-thread-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207142509.I-D@ietf.org> --OtherAccess-- --NextPart-- --16819560-719432153-950039113=:29569-- --16819560-1488665461-950039113=:29569-- Received: by ns.secondary.com (8.9.3/8.9.3) id RAA10810 for ietf-imapext-bks; Mon, 7 Feb 2000 17:07:09 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (tanner@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA10806 for ; Mon, 7 Feb 2000 17:07:07 -0800 (PST) Date: Mon, 7 Feb 2000 16:50:36 -0800 (PST) From: Mark Crispin Subject: Re: IMAPEXT Chartering To: Mike Gahrns cc: Lyndon Nerenberg , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , IMAP Extensions In-Reply-To: <000b01bf71cb$3cfe6cf0$9bff3b9d@redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree completely with Mike Gahrns' comments. It is not clear to me that WG action is required on the base spec. We may want to draw up a list of which points from Barry's document should go in the base spec, but those should be held to clarifications (or possibly prohibitions). The only extension which *may* belong in the base spec is STARTTLS. None of the other extensions are of such vital importance that a server must have it or be considered broken. At least one of the extensions (NAMESPACE) has been known to create problems with certain (we all know which) clients. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA10370 for ietf-imapext-bks; Mon, 7 Feb 2000 16:39:29 -0800 (PST) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA10365 for ; Mon, 7 Feb 2000 16:39:27 -0800 (PST) Received: from 172.30.236.230 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 07 Feb 2000 16:26:10 -0800 (Pacific Standard Time) Received: from MIKEGA9 ([157.59.255.155]) by popdog.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 12F8AQ7W; Mon, 7 Feb 2000 16:26:15 -0800 Message-ID: <000b01bf71cb$3cfe6cf0$9bff3b9d@redmond.corp.microsoft.com> From: "Mike Gahrns" To: "Lyndon Nerenberg" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: "IMAP Extensions" References: <200002071511.e17FBCj98114@zappa.esys.ca> Subject: Re: IMAPEXT Chartering Date: Mon, 7 Feb 2000 16:27:10 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01BF7188.2EC42280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01BF7188.2EC42280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: IMAPEXT CharteringI agree with Lyndon and others to do the review of = the base spec after any extensions are done. (Assuming that a review of = the base spec needs to be in the IMAPEXT charter, which I don't think is = the case). I also wonder if the perceived need of doing a review of the base spec = is based upon the state of IMAP interoperability a fews ago. My personal opinion is that IMAP interoperability is now good. = Admittedly there are some implementations that may not do things in the = most efficient manner, and may not take full advantage of the protocol, = but I think we are at a point now where interop between various vendor's = IMAP client's and servers is decent. I think the results from the = various IMC mail connects bear this out. The group definitely did iron = out some kink in some implementations as a result of these events, and = the group also worked quite hard on the "implementor's guide" that barry = leiba put together. As a result, IMAP interop today is probably better = than some people may perceive it to be. ------=_NextPart_000_0008_01BF7188.2EC42280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: IMAPEXT Chartering
I agree with Lyndon and others to do = the review of=20 the base spec after any extensions are done.  (Assuming that a = review of=20 the base spec needs to be in the IMAPEXT charter, which I don't think is = the=20 case).
 
I also wonder if the perceived need of = doing a=20 review of the base spec is based upon the state of IMAP interoperability = a fews=20 ago.
 
My personal opinion is that IMAP=20 interoperability is now good.  Admittedly there are some=20 implementations that may not do things in the most efficient manner, and = may not=20 take full advantage of the protocol, but I think we are at a point now = where=20 interop between various vendor's IMAP client's and servers = is decent. =20 I think the results from the various IMC mail connects bear this = out. =20 The group definitely did iron out some kink in some = implementations as a=20 result of these events, and the group also worked quite hard on the=20 "implementor's guide" that barry leiba put together.  As a result, = IMAP=20 interop today is probably better than some people may perceive it to=20 be.
------=_NextPart_000_0008_01BF7188.2EC42280-- Received: by ns.secondary.com (8.9.3/8.9.3) id HAA27455 for ietf-imapext-bks; Mon, 7 Feb 2000 07:09:01 -0800 (PST) Received: from zappa.esys.ca (zappa.esys.ca [198.161.92.28]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA27446 for ; Mon, 7 Feb 2000 07:08:59 -0800 (PST) Received: (from lyndon@localhost) by zappa.esys.ca (8.10.0.Beta8/8.10.0.Beta8) id e17FBCj98114; Mon, 7 Feb 2000 08:11:12 -0700 (MST) Message-Id: <200002071511.e17FBCj98114@zappa.esys.ca> From: Lyndon Nerenberg To: Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?= cc: IMAP Extensions Subject: Re: IMAPEXT Chartering In-reply-to: Your message of "Mon, 07 Feb 2000 15:09:18 +0100." <4121501.3158924958@[192.168.124.51]> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 07 Feb 2000 08:11:11 -0700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA27449 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Patrik" == Patrik Fältström writes: Patrik> How, when, where would you suggest a review of the base Patrik> spec is done? Do the base review after the extensions work is done. Patrik> If that is done after IMAPEXT work is done, do you see a Patrik> problem with delaying that review? No. Patrik> If that is done in parallell, do you think other people Patrik> will work with base spec than IMAPEXT issues? I think everyone working on extensions will also work on the base review. The outcome of the extensions work will affect things when we review the base, so the extensions group really has to wrap up first. Also, if we do both at once, our time will become too fragmented to do a good job on either one. Also, if a review of 2060 *is* necessary, I think the IMAP development community is capable of deciding the time and place for that to happen. Having third-parties dictate the need for a base review is out of line (even if some of them are area directors). --lyndon Received: by ns.secondary.com (8.9.3/8.9.3) id GAA26341 for ietf-imapext-bks; Mon, 7 Feb 2000 06:09:22 -0800 (PST) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26336 for ; Mon, 7 Feb 2000 06:09:20 -0800 (PST) Received: from 192.168.124.51 (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id PAA14353; Mon, 7 Feb 2000 15:09:19 +0100 (MET) Date: Mon, 07 Feb 2000 15:09:18 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lyndon Nerenberg , IMAP Extensions Subject: Re: IMAPEXT Chartering Message-ID: <4121501.3158924958@[192.168.124.51]> In-Reply-To: <200002071359.e17Dxr572809@zappa.esys.ca> X-Mailer: Mulberry/2.0.0b8 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2000-02-07 06.59 -0700, Lyndon Nerenberg wrote: > I am completely opposed to incorporating a base spec review into > the working group charter. We need to get the things identified > in the original charter dealt with -- this year. Adding a base spec > review by fiat like this is completely unacceptable. How, when, where would you suggest a review of the base spec is done? If that is done after IMAPEXT work is done, do you see a problem with delaying that review? If that is done in parallell, do you think other people will work with base spec than IMAPEXT issues? paf Received: by ns.secondary.com (8.9.3/8.9.3) id FAA26155 for ietf-imapext-bks; Mon, 7 Feb 2000 05:57:47 -0800 (PST) Received: from zappa.esys.ca (zappa.esys.ca [198.161.92.28]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA26151 for ; Mon, 7 Feb 2000 05:57:46 -0800 (PST) Received: (from lyndon@localhost) by zappa.esys.ca (8.10.0.Beta8/8.10.0.Beta8) id e17Dxr572809; Mon, 7 Feb 2000 06:59:53 -0700 (MST) Message-Id: <200002071359.e17Dxr572809@zappa.esys.ca> From: Lyndon Nerenberg to: IMAP Extensions Subject: Re: IMAPEXT Chartering In-reply-to: Your message of "Sun, 06 Feb 2000 14:05:18 CST." Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Mon, 07 Feb 2000 06:59:52 -0700 Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am completely opposed to incorporating a base spec review into the working group charter. We need to get the things identified in the original charter dealt with -- this year. Adding a base spec review by fiat like this is completely unacceptable. --lyndon Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00916 for ietf-imapext-bks; Sun, 6 Feb 2000 12:55:19 -0800 (PST) Received: from nix.swip.net (nix.swip.net [192.71.220.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00911; Sun, 6 Feb 2000 12:55:17 -0800 (PST) Received: from 192.168.111.25 (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id VAA22613; Sun, 6 Feb 2000 21:55:18 +0100 (MET) Date: Sun, 06 Feb 2000 21:55:12 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Paul Hoffman / IMC" , IMAP Extensions Subject: Re: IMAPEXT Chartering Message-ID: <2248904.3158862912@[192.168.111.25]> In-Reply-To: <4.2.1.20000206121306.00a5d100@mail.imc.org> X-Mailer: Mulberry/2.0.0b8 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On 2000-02-06 12.16 -0800, "Paul Hoffman / IMC" wrote: > This seems like a straightforward layer 8 question. If the IESG wants it > that way, let's do it that way. If we stumble and scrape our knees on the > way, we can blame them. :-) Writing documents about "existing" protocols like the IMAP base protocol will always be painful. The point here is though that IESG belive (tell us if we are wrong): - It is about time it is done - People that have the knowledge and can do it, will be in this wg anyways ...and yes, I am the one which have to buy band-aid... Whether it is an update of the old one (which Pete said he had talked with Keith about) or a new document, that doesn't matter for me. You know better than me what gives the most bang for the buck. It is not the case that IESG _tell_ you to do it (at this point in time ;-). We just belive it would be the cheapest way of going forward. paf Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00449 for ietf-imapext-bks; Sun, 6 Feb 2000 12:13:19 -0800 (PST) Received: from laptop (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00445 for ; Sun, 6 Feb 2000 12:13:18 -0800 (PST) Message-Id: <4.2.1.20000206121306.00a5d100@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Sun, 06 Feb 2000 12:16:09 -0800 To: IMAP Extensions From: Paul Hoffman / IMC Subject: Re: IMAPEXT Chartering In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This seems like a straightforward layer 8 question. If the IESG wants it that way, let's do it that way. If we stumble and scrape our knees on the way, we can blame them. :-) --Paul Hoffman, Director --Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00316 for ietf-imapext-bks; Sun, 6 Feb 2000 12:02:37 -0800 (PST) Received: from episteme-software.com (resnick1.qualcomm.com [63.250.90.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00312 for ; Sun, 6 Feb 2000 12:02:35 -0800 (PST) Received: from resnick2.qualcomm.com (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0b6); Sun, 6 Feb 2000 14:05:41 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 4.3a?] Date: Sun, 6 Feb 2000 14:05:18 -0600 To: IMAP Extensions From: Pete Resnick Subject: IMAPEXT Chartering Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-imapext@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I forward the following message to the working group (bcc'ing the Keith, Patrik, and Ned) unedited. My only comment is that Keith originally brought to me privately the suggestion that we "add another milestone to the charter to write an informational rfc" on "interoperability problems resulting from ambiguities in the specs - and then to get consensus on an approach to solving those problems, before working on actual extensions". I objected to Keith (again, privately) on the grounds that we wanted to limit the scope of this WG to extensions only. Below is Patrik's message. I will make no further comments to the ADs on this topic until I hear from the list on this. Please make comments to the list. (Keith, Patrik, and Ned: Please see ietf-imapext@imc.org if you want to read the comments for yourselves.) --- begin forwarded text Return-Path: Date: Sun, 06 Feb 2000 20:41:33 +0100 From: Patrik Fältström To: Pete Resnick cc: Ned Freed , Keith Moore Subject: Re: IMAPEXT progress? --On 2000-02-03 16.41 -0600, Pete Resnick wrote: > Anything going on with regard to the chartering of IMAPEXT? After discussing this for some time among some IESG and IAB members, we have agreed that this is a go _IF_ you add to the charter a refreshment of the base IMAP spec. Yes, we know you don't like it, and we don't normally do it this way. I.e. a wg working with extensions should not also do the base spec. It is also the case that we normally (as you know personally ;-) want people to first do the boring stuff, and then get to the dessert. But, in the case of IMAP, we feel that many people work really hard, and the same people would work on the extensions _and_ the base spec. Because of this, we don't see any need for two working groups. Let us know what you feel about it. Regards, Patrik --- end forwarded text -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102