Received: by ns.secondary.com (8.9.3/8.9.3) id NAA25874 for ietf-imapext-bks; Thu, 28 Sep 2000 13:15:37 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA25868 for ; Thu, 28 Sep 2000 13:15:31 -0700 (PDT) Received: from messagingdirect.com (gagarin.esys.ca [198.161.92.84]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e8SKIxn15711; Thu, 28 Sep 2000 14:18:59 -0600 Message-ID: <39D3A7B2.1AAA290@messagingdirect.com> Date: Thu, 28 Sep 2000 14:18:58 -0600 From: Alexey Melnikov X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: COPY/APPEND and ACLs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > s - keep seen/unseen information across sessions (STORE \SEEN flag) > w - write (STORE flags other than \SEEN and \DELETED) > d - delete messages (STORE \DELETED flag, perform EXPUNGE) When doing COPY/APPEND should a server check for "s", "w" or "d" when it tries to set \Seen, \Deleted or other flags and drop the flags for which a client has no rights? Or should the server ignore these rights and copy all flags unconditionally? Alexey Received: by ns.secondary.com (8.9.3/8.9.3) id DAA28976 for ietf-imapext-bks; Fri, 22 Sep 2000 03:43:25 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA28972 for ; Fri, 22 Sep 2000 03:43:24 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05039; Fri, 22 Sep 2000 06:46:19 -0400 (EDT) Message-Id: <200009221046.GAA05039@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-thread-03.txt Date: Fri, 22 Sep 2000 06:46:19 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-thread-03.txt Pages : 13 Date : 21-Sep-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-ietf-imapext-thread-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-thread-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-thread-03.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: <20000921133636.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-thread-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-thread-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000921133636.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA00949 for ietf-imapext-bks; Fri, 15 Sep 2000 12:42:43 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (thwang@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00944 for ; Fri, 15 Sep 2000 12:42:42 -0700 (PDT) Date: Fri, 15 Sep 2000 12:10:47 -0700 (PDT) From: Mark Crispin Subject: re: Rationale for address sorting algorithm in SORT To: Lyndon Nerenberg cc: Chris Adie , ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 15 Sep 2000 13:01:12 -0600 (MDT), Lyndon Nerenberg wrote: > What about adding a FROMDOMAIN sort specifier that would sort on the > domain component of the from address. This allows for (FROMDOMAIN > FROM) which (for me at least) would be a very useful operation. > (And add the complementary TODOMAIN and CCDOMAIN.) Something on this line has already been suggested by Cyrus Daboo in the context of "SORT2". If SORT2 happens, there's no doubt in my mind that this type of functionality must be part of it. Received: by ns.secondary.com (8.9.3/8.9.3) id LAA29741 for ietf-imapext-bks; Fri, 15 Sep 2000 11:59:10 -0700 (PDT) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA29736 for ; Fri, 15 Sep 2000 11:59:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (Postfix) with ESMTP id A5D579936C; Fri, 15 Sep 2000 13:01:12 -0600 (MDT) Date: Fri, 15 Sep 2000 13:01:12 -0600 (MDT) From: Lyndon Nerenberg X-Sender: lyndon@gollum.esys.ca To: Mark Crispin Cc: Chris Adie , ietf-imapext@imc.org Subject: re: Rationale for address sorting algorithm in SORT In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What about adding a FROMDOMAIN sort specifier that would sort on the domain component of the from address. This allows for (FROMDOMAIN FROM) which (for me at least) would be a very useful operation. (And add the complementary TODOMAIN and CCDOMAIN.) --lyndon Received: by ns.secondary.com (8.9.3/8.9.3) id JAA26851 for ietf-imapext-bks; Fri, 15 Sep 2000 09:52:39 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (chj@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26847 for ; Fri, 15 Sep 2000 09:52:37 -0700 (PDT) Date: Fri, 15 Sep 2000 09:35:08 -0700 (PDT) From: Mark Crispin Subject: re: Rationale for address sorting algorithm in SORT To: Chris Adie cc: ietf-imapext@imc.org In-Reply-To: <031601c01ef0$de0b7110$c8c8d781@ucs.ed.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 15 Sep 2000 09:42:22 +0100, Chris Adie wrote: > I'm interested in the rationale behind the address sorting algorithm in > draft-ietf-imapext-sort-05.txt. > [snip] > Why was the local-part chosen instead of the addr-spec? This is a good question. Many people have multiple email addresses, although they tend to use the same local-part for their multiple email addresses. This is particularly true in an academic environment Absent a dictionary of equivalances, it's not possible to determine if smith@aaa.com and smith@zzz.com are the same person or different. As you noted, matching just a local-part of "smith" would tend to yield false positives. On the other hand, failure to match local-part of "mrc" would tend to yield false negatives. False negatives turned out to be a big problem. Fuzzy matching of the domain turns out to be a rathole. It helps with multiple addresses within an organization, but not with external addresses. For example, many people here have both an UW address and an external address at some ISP (e.g. mrc@cac.washington.edu and mrc@panda.com). In the past decade with Pine, we've found that the user community is much more tolerant of false positives than false negatives when sorting by FROM. The rule of matching by local-part only is inherited by this. It's not laziness; it's what generates the fewest bug reports. Also, consider a (SUBJECT FROM) sort. With false positives, you'll get someone else's messages on the subject interspersed -- something that everybody lives with all the time in reading email. But with false negatives, you'll have the same guy's messages out of order! Fortunately, FROM sorting, not to mention something like (FROM SUBJECT) sorting, isn't done all that often. Most people choose threading instead. This doesn't mean that I'm happy with the status quo; it's just that the other choices have all been proven worse. -- Mark -- Received: by ns.secondary.com (8.9.3/8.9.3) id BAA28583 for ietf-imapext-bks; Fri, 15 Sep 2000 01:54:39 -0700 (PDT) Received: from tirrik.ucs.ed.ac.uk (tirrik.ucs.ed.ac.uk [129.215.200.182]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA28579 for ; Fri, 15 Sep 2000 01:54:37 -0700 (PDT) Received: from foula (foula.ucs.ed.ac.uk [129.215.200.200]) by tirrik.ucs.ed.ac.uk (Rockliffe SMTPRA 3.4.5) with SMTP id for ; Fri, 15 Sep 2000 09:54:18 +0100 Message-ID: <031601c01ef0$de0b7110$c8c8d781@ucs.ed.ac.uk> From: "Chris Adie" To: Subject: Rationale for address sorting algorithm in SORT Date: Fri, 15 Sep 2000 09:42:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm interested in the rationale behind the address sorting algorithm in draft-ietf-imapext-sort-05.txt. The CC, FROM and TO criteria are sorted on the RFC822 local-part of the first address, rather than on the local-part@domain. I believe this has bad effects. For instance, suppose I have three messages: Message 1 from smith@aaa.com subject Aardvarks Message 2 from smith@aaa.com subject Zip drives Message 3 from smith@zzz.com subject Middleware If I sort on (FROM SUBJECT), the resulting order according to the spec is 1 3 2, which is bad. Most people would expect that sorting by the FROM field should group all the messages from a single person together. If the sort algorithm worked on local-part@domain (ie addr-spec in RFC822 terms) instead, then the order would be 1 2 3, which seems much more natural. Why was the local-part chosen instead of the addr-spec? Chris Adie Received: by ns.secondary.com (8.9.3/8.9.3) id GAA16367 for ietf-imapext-bks; Thu, 14 Sep 2000 06:18:14 -0700 (PDT) Received: from mail.kpnqwest.ch (mail.eunet.ch [146.228.10.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16359 for ; Thu, 14 Sep 2000 06:18:12 -0700 (PDT) From: sdjfsdjkfnu@tpntms.anjes.com.tw Received: from oettinger.davidoff.ch ([195.49.110.243]) by mail.kpnqwest.ch (8.9.3/1.34) via ESMTP id NAA15722 for ; Thu, 14 Sep 2000 13:19:58 GMT env-from (sdjfsdjkfnu@tpntms.anjes.com.tw) Received: from mail.mindspring.com by oettinger.davidoff.ch via SMTP id smtp\t9eegkd4.in; 14 Sep 2000 14:52:00 +0200 To: Date: Thu, 14 Sep 2000 05:18:16 Message-Id: <206.256854.190787@mail.mindspring.com> Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO OUR OFFICE. YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! FRONT PAGE EXTENSIONS are FULLY SUPPORTED. A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 Webhosting International Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA21837 for ietf-imapext-bks; Wed, 13 Sep 2000 13:32:02 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (johnbill@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA21828 for ; Wed, 13 Sep 2000 13:31:58 -0700 (PDT) X-Received: via tmail-4.1(12) (invoked by user mailnull) for mrc+ietf; Wed, 13 Sep 2000 05:10:57 -0700 (PDT) X-Received: from newman.cac.washington.edu (newman.cac.washington.edu [140.142.10.143]) by tupperware.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with SMTP id FAA31493 for ; Wed, 13 Sep 2000 05:10:56 -0700 (PDT) X-Received: FROM mx2.cac.washington.edu BY newman.cac.washington.edu ; Wed Sep 13 05:10:56 2000 -0700 X-Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mx2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id FAA22783; Wed, 13 Sep 2000 05:10:54 -0700 X-Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA26914 for ietf-123-outbound.07@ietf.org; Wed, 13 Sep 2000 08:05:02 -0400 (EDT) X-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 GAA26524 for ; Wed, 13 Sep 2000 06:55:38 -0400 (EDT) X-Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03996 for ; Wed, 13 Sep 2000 06:55:39 -0400 (EDT) Message-Id: <200009131055.GAA03996@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-imapv-10.txt Date: Wed, 13 Sep 2000 06:55:39 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 Author(s) : M. Crispin Filename : draft-crispin-imapv-10.txt Pages : 93 Date : 12-Sep-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]). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imapv-10.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-10.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-10.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: <20000912130916.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-crispin-imapv-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-crispin-imapv-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000912130916.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id UAA06648 for ietf-imapext-bks; Fri, 8 Sep 2000 20:25:07 -0700 (PDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA06644 for ; Fri, 8 Sep 2000 20:25:06 -0700 (PDT) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id UAA08169; Fri, 8 Sep 2000 20:26:51 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (chj@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id UAA30741; Fri, 8 Sep 2000 20:26:51 -0700 Date: Fri, 8 Sep 2000 19:06:38 -0700 (PDT) From: Mark Crispin Subject: Re: Summary: SORT/THREAD/VIEW debate To: Chris Newman cc: IMAP Extensions WG In-Reply-To: <2190087.3177423944@nifty-jr.west.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 08 Sep 2000 17:45:44 -0700, Chris Newman wrote: > I haven't seen any comments on my attempt at a summary of the debate. Can > I presume the summary was largely accurate? That is quite presumptious. A summary of a debate is produced by an impartial third party, who secures the agreement of the advocates that their positions are fairly represented. I do not wish to review or comment on your representation of my position. > While the points of contention listed below were discussed briefly at the > WG meeting in Pittsburgh, I do not believe all ramifications were > considered and all positions adequately presented. Therefore, barring a > rough concensus on the list prior to that time, I believe these points of > contention should be considered unresolved and discussed at the IETF > meeting in San Jose. Although I do not disagree that the points of contention are unresolved, neither you nor I should make statements such as the above. Advocates can not simultaneously be moderators. It may be necessary for someone to lead this debate, but that someone is neither you nor I. Received: by ns.secondary.com (8.9.3/8.9.3) id RAA03752 for ietf-imapext-bks; Fri, 8 Sep 2000 17:46:05 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA03748 for ; Fri, 8 Sep 2000 17:46:04 -0700 (PDT) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA29041 for ; Fri, 8 Sep 2000 17:47:52 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA09362 for ; Fri, 8 Sep 2000 17:47:51 -0700 (PDT) Date: Fri, 08 Sep 2000 17:45:44 -0700 From: Chris Newman To: IMAP Extensions WG Subject: Re: Summary: SORT/THREAD/VIEW debate Message-ID: <2190087.3177423944@nifty-jr.west.sun.com> In-Reply-To: <2632257.3176193910@nifty-jr.west.sun.com> X-Mailer: Mulberry/2.0.4 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I haven't seen any comments on my attempt at a summary of the debate. Can I presume the summary was largely accurate? While the points of contention listed below were discussed briefly at the WG meeting in Pittsburgh, I do not believe all ramifications were considered and all positions adequately presented. Therefore, barring a rough concensus on the list prior to that time, I believe these points of contention should be considered unresolved and discussed at the IETF meeting in San Jose. --On Friday, August 25, 2000 12:05 -0700 Chris Newman wrote: > The points of contention are: > ... > (1) Whether it is desirable to standardize a one-shot SORT/THREAD facility > given a persistant SORT/THREAD facility will also be standardized. > ... > (2) Desire for scalability on the basis of mailbox size (Windowing). > ... > (3) Desire to collapse related functionality into a minimal number of > capability items. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id NAA25874 for ietf-imapext-bks; Thu, 28 Sep 2000 13:15:37 -0700 (PDT) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA25868 for ; Thu, 28 Sep 2000 13:15:31 -0700 (PDT) Received: from messagingdirect.com (gagarin.esys.ca [198.161.92.84]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id e8SKIxn15711; Thu, 28 Sep 2000 14:18:59 -0600 Message-ID: <39D3A7B2.1AAA290@messagingdirect.com> Date: Thu, 28 Sep 2000 14:18:58 -0600 From: Alexey Melnikov X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-imapext@imc.org Subject: COPY/APPEND and ACLs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > s - keep seen/unseen information across sessions (STORE \SEEN flag) > w - write (STORE flags other than \SEEN and \DELETED) > d - delete messages (STORE \DELETED flag, perform EXPUNGE) When doing COPY/APPEND should a server check for "s", "w" or "d" when it tries to set \Seen, \Deleted or other flags and drop the flags for which a client has no rights? Or should the server ignore these rights and copy all flags unconditionally? Alexey Received: by ns.secondary.com (8.9.3/8.9.3) id DAA28976 for ietf-imapext-bks; Fri, 22 Sep 2000 03:43:25 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA28972 for ; Fri, 22 Sep 2000 03:43:24 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05039; Fri, 22 Sep 2000 06:46:19 -0400 (EDT) Message-Id: <200009221046.GAA05039@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-imapext@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-imapext-thread-03.txt Date: Fri, 22 Sep 2000 06:46:19 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF. Title : INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-thread-03.txt Pages : 13 Date : 21-Sep-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-ietf-imapext-thread-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-imapext-thread-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-imapext-thread-03.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: <20000921133636.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-thread-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-thread-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000921133636.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA00949 for ietf-imapext-bks; Fri, 15 Sep 2000 12:42:43 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (thwang@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA00944 for ; Fri, 15 Sep 2000 12:42:42 -0700 (PDT) Date: Fri, 15 Sep 2000 12:10:47 -0700 (PDT) From: Mark Crispin Subject: re: Rationale for address sorting algorithm in SORT To: Lyndon Nerenberg cc: Chris Adie , ietf-imapext@imc.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 15 Sep 2000 13:01:12 -0600 (MDT), Lyndon Nerenberg wrote: > What about adding a FROMDOMAIN sort specifier that would sort on the > domain component of the from address. This allows for (FROMDOMAIN > FROM) which (for me at least) would be a very useful operation. > (And add the complementary TODOMAIN and CCDOMAIN.) Something on this line has already been suggested by Cyrus Daboo in the context of "SORT2". If SORT2 happens, there's no doubt in my mind that this type of functionality must be part of it. Received: by ns.secondary.com (8.9.3/8.9.3) id LAA29741 for ietf-imapext-bks; Fri, 15 Sep 2000 11:59:10 -0700 (PDT) Received: from gollum.esys.ca (dhcp198-59.esys.ca [198.161.92.59]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA29736 for ; Fri, 15 Sep 2000 11:59:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (Postfix) with ESMTP id A5D579936C; Fri, 15 Sep 2000 13:01:12 -0600 (MDT) Date: Fri, 15 Sep 2000 13:01:12 -0600 (MDT) From: Lyndon Nerenberg X-Sender: lyndon@gollum.esys.ca To: Mark Crispin Cc: Chris Adie , ietf-imapext@imc.org Subject: re: Rationale for address sorting algorithm in SORT In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What about adding a FROMDOMAIN sort specifier that would sort on the domain component of the from address. This allows for (FROMDOMAIN FROM) which (for me at least) would be a very useful operation. (And add the complementary TODOMAIN and CCDOMAIN.) --lyndon Received: by ns.secondary.com (8.9.3/8.9.3) id JAA26851 for ietf-imapext-bks; Fri, 15 Sep 2000 09:52:39 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (chj@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26847 for ; Fri, 15 Sep 2000 09:52:37 -0700 (PDT) Date: Fri, 15 Sep 2000 09:35:08 -0700 (PDT) From: Mark Crispin Subject: re: Rationale for address sorting algorithm in SORT To: Chris Adie cc: ietf-imapext@imc.org In-Reply-To: <031601c01ef0$de0b7110$c8c8d781@ucs.ed.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 15 Sep 2000 09:42:22 +0100, Chris Adie wrote: > I'm interested in the rationale behind the address sorting algorithm in > draft-ietf-imapext-sort-05.txt. > [snip] > Why was the local-part chosen instead of the addr-spec? This is a good question. Many people have multiple email addresses, although they tend to use the same local-part for their multiple email addresses. This is particularly true in an academic environment Absent a dictionary of equivalances, it's not possible to determine if smith@aaa.com and smith@zzz.com are the same person or different. As you noted, matching just a local-part of "smith" would tend to yield false positives. On the other hand, failure to match local-part of "mrc" would tend to yield false negatives. False negatives turned out to be a big problem. Fuzzy matching of the domain turns out to be a rathole. It helps with multiple addresses within an organization, but not with external addresses. For example, many people here have both an UW address and an external address at some ISP (e.g. mrc@cac.washington.edu and mrc@panda.com). In the past decade with Pine, we've found that the user community is much more tolerant of false positives than false negatives when sorting by FROM. The rule of matching by local-part only is inherited by this. It's not laziness; it's what generates the fewest bug reports. Also, consider a (SUBJECT FROM) sort. With false positives, you'll get someone else's messages on the subject interspersed -- something that everybody lives with all the time in reading email. But with false negatives, you'll have the same guy's messages out of order! Fortunately, FROM sorting, not to mention something like (FROM SUBJECT) sorting, isn't done all that often. Most people choose threading instead. This doesn't mean that I'm happy with the status quo; it's just that the other choices have all been proven worse. -- Mark -- Received: by ns.secondary.com (8.9.3/8.9.3) id BAA28583 for ietf-imapext-bks; Fri, 15 Sep 2000 01:54:39 -0700 (PDT) Received: from tirrik.ucs.ed.ac.uk (tirrik.ucs.ed.ac.uk [129.215.200.182]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA28579 for ; Fri, 15 Sep 2000 01:54:37 -0700 (PDT) Received: from foula (foula.ucs.ed.ac.uk [129.215.200.200]) by tirrik.ucs.ed.ac.uk (Rockliffe SMTPRA 3.4.5) with SMTP id for ; Fri, 15 Sep 2000 09:54:18 +0100 Message-ID: <031601c01ef0$de0b7110$c8c8d781@ucs.ed.ac.uk> From: "Chris Adie" To: Subject: Rationale for address sorting algorithm in SORT Date: Fri, 15 Sep 2000 09:42:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm interested in the rationale behind the address sorting algorithm in draft-ietf-imapext-sort-05.txt. The CC, FROM and TO criteria are sorted on the RFC822 local-part of the first address, rather than on the local-part@domain. I believe this has bad effects. For instance, suppose I have three messages: Message 1 from smith@aaa.com subject Aardvarks Message 2 from smith@aaa.com subject Zip drives Message 3 from smith@zzz.com subject Middleware If I sort on (FROM SUBJECT), the resulting order according to the spec is 1 3 2, which is bad. Most people would expect that sorting by the FROM field should group all the messages from a single person together. If the sort algorithm worked on local-part@domain (ie addr-spec in RFC822 terms) instead, then the order would be 1 2 3, which seems much more natural. Why was the local-part chosen instead of the addr-spec? Chris Adie Received: by ns.secondary.com (8.9.3/8.9.3) id GAA16367 for ietf-imapext-bks; Thu, 14 Sep 2000 06:18:14 -0700 (PDT) Received: from mail.kpnqwest.ch (mail.eunet.ch [146.228.10.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16359 for ; Thu, 14 Sep 2000 06:18:12 -0700 (PDT) From: sdjfsdjkfnu@tpntms.anjes.com.tw Received: from oettinger.davidoff.ch ([195.49.110.243]) by mail.kpnqwest.ch (8.9.3/1.34) via ESMTP id NAA15722 for ; Thu, 14 Sep 2000 13:19:58 GMT env-from (sdjfsdjkfnu@tpntms.anjes.com.tw) Received: from mail.mindspring.com by oettinger.davidoff.ch via SMTP id smtp\t9eegkd4.in; 14 Sep 2000 14:52:00 +0200 To: Date: Thu, 14 Sep 2000 05:18:16 Message-Id: <206.256854.190787@mail.mindspring.com> Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO OUR OFFICE. YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! FRONT PAGE EXTENSIONS are FULLY SUPPORTED. A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 Webhosting International Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA21837 for ietf-imapext-bks; Wed, 13 Sep 2000 13:32:02 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (johnbill@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA21828 for ; Wed, 13 Sep 2000 13:31:58 -0700 (PDT) X-Received: via tmail-4.1(12) (invoked by user mailnull) for mrc+ietf; Wed, 13 Sep 2000 05:10:57 -0700 (PDT) X-Received: from newman.cac.washington.edu (newman.cac.washington.edu [140.142.10.143]) by tupperware.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with SMTP id FAA31493 for ; Wed, 13 Sep 2000 05:10:56 -0700 (PDT) X-Received: FROM mx2.cac.washington.edu BY newman.cac.washington.edu ; Wed Sep 13 05:10:56 2000 -0700 X-Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by mx2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id FAA22783; Wed, 13 Sep 2000 05:10:54 -0700 X-Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA26914 for ietf-123-outbound.07@ietf.org; Wed, 13 Sep 2000 08:05:02 -0400 (EDT) X-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 GAA26524 for ; Wed, 13 Sep 2000 06:55:38 -0400 (EDT) X-Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03996 for ; Wed, 13 Sep 2000 06:55:39 -0400 (EDT) Message-Id: <200009131055.GAA03996@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-imapv-10.txt Date: Wed, 13 Sep 2000 06:55:39 -0400 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 Author(s) : M. Crispin Filename : draft-crispin-imapv-10.txt Pages : 93 Date : 12-Sep-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]). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crispin-imapv-10.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-10.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-10.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: <20000912130916.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-crispin-imapv-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-crispin-imapv-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000912130916.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id UAA06648 for ietf-imapext-bks; Fri, 8 Sep 2000 20:25:07 -0700 (PDT) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA06644 for ; Fri, 8 Sep 2000 20:25:06 -0700 (PDT) Received: from mailhost1.u.washington.edu (mailhost1.u.washington.edu [140.142.32.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id UAA08169; Fri, 8 Sep 2000 20:26:51 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (chj@tomobiki-cho.cac.washington.edu [128.95.135.58]) by mailhost1.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id UAA30741; Fri, 8 Sep 2000 20:26:51 -0700 Date: Fri, 8 Sep 2000 19:06:38 -0700 (PDT) From: Mark Crispin Subject: Re: Summary: SORT/THREAD/VIEW debate To: Chris Newman cc: IMAP Extensions WG In-Reply-To: <2190087.3177423944@nifty-jr.west.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 08 Sep 2000 17:45:44 -0700, Chris Newman wrote: > I haven't seen any comments on my attempt at a summary of the debate. Can > I presume the summary was largely accurate? That is quite presumptious. A summary of a debate is produced by an impartial third party, who secures the agreement of the advocates that their positions are fairly represented. I do not wish to review or comment on your representation of my position. > While the points of contention listed below were discussed briefly at the > WG meeting in Pittsburgh, I do not believe all ramifications were > considered and all positions adequately presented. Therefore, barring a > rough concensus on the list prior to that time, I believe these points of > contention should be considered unresolved and discussed at the IETF > meeting in San Jose. Although I do not disagree that the points of contention are unresolved, neither you nor I should make statements such as the above. Advocates can not simultaneously be moderators. It may be necessary for someone to lead this debate, but that someone is neither you nor I. Received: by ns.secondary.com (8.9.3/8.9.3) id RAA03752 for ietf-imapext-bks; Fri, 8 Sep 2000 17:46:05 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA03748 for ; Fri, 8 Sep 2000 17:46:04 -0700 (PDT) Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA29041 for ; Fri, 8 Sep 2000 17:47:52 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA09362 for ; Fri, 8 Sep 2000 17:47:51 -0700 (PDT) Date: Fri, 08 Sep 2000 17:45:44 -0700 From: Chris Newman To: IMAP Extensions WG Subject: Re: Summary: SORT/THREAD/VIEW debate Message-ID: <2190087.3177423944@nifty-jr.west.sun.com> In-Reply-To: <2632257.3176193910@nifty-jr.west.sun.com> X-Mailer: Mulberry/2.0.4 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I haven't seen any comments on my attempt at a summary of the debate. Can I presume the summary was largely accurate? While the points of contention listed below were discussed briefly at the WG meeting in Pittsburgh, I do not believe all ramifications were considered and all positions adequately presented. Therefore, barring a rough concensus on the list prior to that time, I believe these points of contention should be considered unresolved and discussed at the IETF meeting in San Jose. --On Friday, August 25, 2000 12:05 -0700 Chris Newman wrote: > The points of contention are: > ... > (1) Whether it is desirable to standardize a one-shot SORT/THREAD facility > given a persistant SORT/THREAD facility will also be standardized. > ... > (2) Desire for scalability on the basis of mailbox size (Windowing). > ... > (3) Desire to collapse related functionality into a minimal number of > capability items. - Chris